Contradictory information in Propeller Manual?

Wossname

I'm confused about how PASM code is loaded into a Cog. The manual seems to contradict itself

Page 292 of Propeller Manual v1.2 wrote:

This code was artificially pushed into upper Cog RAM space by the ORG statement, causing the code to overlap the first special purpose register ($1F0) and causing the FIT directive to cause a compile-time error when the code is compiled.

Page 328 of Propeller Manual v1.2 wrote:

ORG only affects symbol references; it does not affect the position of assembly code in the cog itself. When assembly code is launched via a COGNEW or COGINIT command, the destination cog always loads the code into its RAM starting at address 0.

Huh?

Can someone draw a picture for me? In crayon preferably.

Duane Degn

I think you're right. It looks contradictory to me.

I think the first quote should have been worded "The assembly pointer for this code was artificially adjusted, causing the pointer to indicate a Cog RAM location that would overlap the first special purpose register ($1F0) and . . ."

ericball

No, the two statements are not contradictory. First, except under very special circumstances your PASM code should start with ORG 0 and be immediately followed by the label used as the first parameter in the SPIN COGINIT/COGNEW command and the first instruction to be executed.

Now, let's look at the first example:

	DAT
	ORG 	492
Toggle 	mov 	dira, Pin	' stored in register 492
:Loop 	mov 	outa, Pin	' 493
	mov 	outa, #0	' 494
	jmp 	#:Loop		' 495
	Pin 	long $1000	' stored in register 496 (PAR)
	FIT

Now, if you were foolish enough to use ORG 492 (without the FIT) and do a coginit( @Toggle, 0 ), then the mov dira, Pin would get stored in register 0 and be executed first. But the source value would be retrieved from register 496 (PAR), not Pin which would be stored in register 4. The code would execute until it hit the jmp #:Loop and then it would continue execution with register 493, which would be loaded with whatever data was in HUB RAM 495 longs after Toggle.

SRLM

In other words, ORG only affects the calculation of symbol addresses at assembly time. If you choose to move things around at run time then you're on your own...

Duane Degn

Thanks for clarifying Eric.

I almost wrote a post (I actually just wrote it but I didn't submit it) asking for a second opinion.

So the Prop Tool uses the "ORG" to fill in the appropriate cog address for the labels within the PASM code?

But the code is loaded starting in long #0 no mater what value is used with "ORG"?

Turbosupra's thread about direct addressing has recently got me thinking about this.

Jeff Martin

Thanks for posting this. Certainly, the way I wrote it can be misleading and I'll make note of it to make it more clear.

ORG only affects the symbol address pointer used by the assembler during source code processing. It does not affect where the code actually gets loaded into the cog, as it mistakenly implies; PASM code launched with COGINIT or COGNEW always get's loaded into Cog RAM starting with address 0. The code example wouldn't do anything useful if the ORG was other than 0, unless the developer had specific reason, and took specific measures in the way it was written, to make it take advantage of the non-0 symbol-addressing created by ORG >0.

Duane: Yes, the Propeller Tool uses ORG to determine where the next assembled symbol address will be logically placed in Cog RAM (but does not affect the actual placement of executable code, symbolically defined longs, or reserved longs. And, yes, the code is loaded starting at long #0 regardless. The developer can use ORG other than 0 for some advanced uses, such as assembling code that will be physically moved into the correct registers during run-time, for instance.

ericball

Hi Jeff,

Yes, non-zero ORGs probably require some additional clarification, including when it would be used. I think part of the problem is assemblers for other processors use the ORG (and RES) directive to change where code is stored in memory so that's what people expect.

Jeff Martin

ericball wrote: »

Hi Jeff,

Yes, non-zero ORGs probably require some additional clarification, including when it would be used. I think part of the problem is assemblers for other processors use the ORG (and RES) directive to change where code is stored in memory so that's what people expect.

Right, and indeed it stumped me at first when I was testing it out for the first (or second) time.

Sapieha

Hi Eric.

One of nice things that Org can use other address that 0 is possibility to write code blocks for on fly loading in desired address.

ericball wrote: »

Hi Jeff,

Yes, non-zero ORGs probably require some additional clarification, including when it would be used. I think part of the problem is assemblers for other processors use the ORG (and RES) directive to change where code is stored in memory so that's what people expect.

Cluso99

I use the ORG statement for overlays in cog. Another use can be to redefine code as variable use after the code has executed. i.e. Its an attractive way of re-using (redefining) initialisation code for use as variables.