Odd assembler error
Phil Pilgrim (PhiPi)
Posts: 23,514
Can someone explain why I get an assembly error from the following?
What's flagged is the here in the line labeled there, with the error, "Expected a constant, unary operator, or '('." As far as I can see here is a constant that should have been resolved by the time there is assembled. In fact, if I leave off the res 16 after here, the program assembles just fine.
-Phil
[b]CON[/b] [b]_clkmode[/b] = [b]xtal[/b]1 + [b]pll[/b]16x [b]_xinfreq[/b] = 5_000_000 [b]PUB[/b] start [b]cognew[/b](@enter, 0) [b]DAT[/b] enter [b]org[/b] 0 here [b]res[/b] 16 there [b]org[/b] here + 16
What's flagged is the here in the line labeled there, with the error, "Expected a constant, unary operator, or '('." As far as I can see here is a constant that should have been resolved by the time there is assembled. In fact, if I leave off the res 16 after here, the program assembles just fine.
-Phil
Comments
Intriguing. If someone at Parallax can explain this behavior I'll try to conform in propasm, but it seems like a bug to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
No trouble. Thanks for looking into it!
-Phil
The Propeller gets better and better...
Seriously Chip, we *REALLY* appreciate the support you guys give to people working with the Propeller.
Bill
Operand-type data is now usable in ORG, RES, and FIT directives.
There is a new ORGX directive which holds the cog address counter at 0, so that large-model asm programs can be laid down in hub memory without causing an eventual error by hitting the $1F0 limit. RES's are not allowed after an ORGX because they make no sense in that context. A regular ORG will get you back to normal mode. ORGX has no argument:
···· ORGX······· 'start of large-model code
···· mov·· r0,r7
···· jmp···#cache
···· long· @cblk
···· etc...
cblk ORG·· $80·· 'here's a block to be cached...
···· mov·· dira,#$FF
···· etc...
···· long· 0···· 'end of cached block
Cliff, remember how you made propasm error out if an instruction was encountered after a RES? If you'll look in that latest VGA tile driver, you'll see that I actually used such a structure to advantage. It's probably better to allow such formations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Actually, I said I was considering doing that. My experience on PropellerForth has convinced me otherwise.
propasm's handling of RES is as follows:
- The specified number of longs are reserved.
- If the RES is at the end of the image, it doesn't do anything.
- If the RES is followed by any initialized data (such as a long directive or an instruction), it generates zero-padding.
This is not ideal. I'm thinking about adhering to the PropellerTool behavior for RES and introducing two propasm-specific dot-directives to handle the two separate cases RES covers:
1. Reserving space within the image, so zero-padding makes sense;
2. Indicating that some amount of uninitialized space will be needed in a Cog (generally between an ORG and FIT directive), where zero-padding doesn't make sense.
I'd love to work with you to make sure that propasm and PropellerTool behave the same in these cases. Can you specify ORGX in more detail?
That will help me immensely; just one change to your example:
·········· orgx
start··· mov·· dira,#0······ ' i hope spin can get at [url=mailto:'@start']'@start'[/url] so it can start a kernal with par pointing at it!
·········· ' lots of code
·········· jmp··· #fcache
cblk ···· org··· $80·········· ' the block to be cached follows the 'jmp #fcache', the 'pc' register points at it already [noparse]:)[/noparse]
·········· mov·· dira,#$ff
·········· ... more code
···········long 0
·········· orgx
·········· ' even more code
Thanks again!
Bill
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/15/2006 6:35:54 AM GMT
After, determining that RES wasn't reserving the space, I searched the forum and found the answer. ( Just shows I should have done that at the start......)
I'm NOT complaining, it really has been a very educational exercise to work through the problem, but the suggestion of a "sticky thread' of issues, problems and work arounds, could help all. ( Especially if some-one is just picking up the propeller.)
The assembler code I'm working on, is going in the opposite to the "large memory model". It is a minimal, but extensible "FORTH", totally with-in a COG, with CALL (JSR) threaded code (non-reenterant). "miniForth" based tasks into other COGs. Seperate COG running the fullduplexserial handler. ASM routines in the "miniForth" to interface to serial via main memory. This problem showed itself defining the push/pop stack code. ( 32bit stack using words.). Once it becomes more developed I will open it to the world and see if others will find it useful.
Mike
Is there other information that is not included in the manual or errata? (In other words, append it here...)
the Prop Tool version 1.05.5 supports the ORGX directive, you can try it.
Thomas
This version shows label 1.04 ?
this was the first version that was providing this functionality. It was an unsupported test version. All official published versions afterwards containing also this functionality.
Thomas