PDA

View Full Version : Odd assembler error



Phil Pilgrim (PhiPi)
11-13-2006, 03:49 AM
Can someone explain why I get an assembly error from the following?




CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

PUB start

cognew(@enter, 0)

DAT

enter org 0
here res 16
there org 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

Cliff L. Biffle
11-13-2006, 04:29 AM
It also works fine if you change res to long or any other initialized data directive.

Intriguing. If someone at Parallax can explain this behavior I'll try to conform in propasm, but it seems like a bug to me.

cgracey
11-14-2006, 07:18 AM
It turns out that the assembler was not allowing operand-type data in the RES, ORG, FIT, and BYTE/WORD/LONG value[repeatcount] fields. I'm going to fix this and have a new version available tomorrow. Sorry for the trouble, guys.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Phil Pilgrim (PhiPi)
11-14-2006, 07:20 AM
Hey Chip,

No trouble. Thanks for looking into it!

-Phil

Bill Henning
11-14-2006, 08:01 AM
:-)

The Propeller gets better and better...

Seriously Chip, we *REALLY* appreciate the support you guys give to people working with the Propeller.

Bill

cgracey
11-15-2006, 10:37 AM
Okay, here is the new Propeller Tool with some assembler changes (rename Propeller.ex_ to Propeller.exe):

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.

Cliff L. Biffle
11-15-2006, 11:44 AM
Chip Gracey said...
Cliff, remember how you made propasm error out if an instruction was encountered after a RES?


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?

Bill Henning
11-15-2006, 01:44 PM
Thanks chip!

That will help me immensely; just one change to your example:

·········· orgx

start··· mov·· dira,#0······ ' i hope spin can get at '@start' (mailto:'@start') 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 :)

·········· mov·· dira,#$ff

·········· ... more code

···········long 0

·········· orgx

·········· ' even more code

Thanks again!

Bill


Chip Gracey (Parallax) said...

Okay, here is the new Propeller Tool with some assembler changes (rename Propeller.ex_ to Propeller.exe):

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.

cgracey
11-15-2006, 02:27 PM
Cliff L. Biffle said...
Actually, I said I was considering doing that. My experience on PropellerForth has convinced me otherwise.
Sorry about misunderstanding, Jeff and I were just talking tonight about how are minds are becoming·like iron sieves.
Can you specify ORGX in more detail?
All ORGX does is pin the origin to $000 until an ORG is encountered.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 11/15/2006 6:35:54 AM GMT

mike101video
11-29-2006, 03:38 AM
Could we have a "stick thread" with errors/issues posted? I have just re-discovered this same problem - I spent some time as I assumed that it was my bad asm programming that caused the problem. Time well spent learning how the binary format is laidout, and decoding instructions from binary back to assembler........

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

Fred Hawkins
07-06-2007, 09:50 AM
Does the tool 1.05.5 include the ORGX directive?

Is there other information that is not included in the manual or errata? (In other words, append it here...)

Kaio
07-06-2007, 06:33 PM
Fred,

the Prop Tool version 1.05.5 supports the ORGX directive, you can try it. http://forums.parallax.com/images/smilies/wink.gif

Thomas

ErNa
07-06-2007, 07:35 PM
Chip Gracey (Parallax) said...
Okay, here is the new Propeller Tool with some assembler changes (rename Propeller.ex_ to Propeller.exe):



This version shows label 1.04 ?

Kaio
07-06-2007, 09:13 PM
ErnNa,

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