Indirect addressing etc.

Gennady

I think I've figured out what puzzles me the most at my attempts to get into assembly details.
It's an indirect addressing, including some quite clever and tricky ways of using JMPRET (and it's everywhere, and it's almost never explained·!).
There are very few explanations in a manual and accompanying materials, including forum.
I hope some questions/answers will come up in this discussion which will help me to completely figure it out.

If discussion like this already·had place before or there are some good places to look, please point me in a right direction.

1.
Program Counter - does it exists? And if yes, where does it reside·?
As strange as it sounds (to me), I haven't found anything about it except in·assembly flow control instructions.
And there it says, that·return address (PC+1) should be stored·at the address of either RET or JMP (depending on instruction).
So since·instructions are 32 bit, why is it PC+1 (where I would assume PC is an address of a current instruction), and not (PC+4) ?

2.
Example from the Phil Pilgrim's "Propeller Tricks and Traps". It's an exellent resourse for me, since it contains some staff hardly documented anywhere else (or very well hidden).

In 'Subroutine Parameter' Trick:

················· CALL··· #Subroutine
················· LONG··· Arg1
················· LONG··· Arg2
················· ..

Subroutine··· MOVS· :GetArg1, Subroutine_ret
················· ADD···· Subroutine_ret, #1
:GetArg1····· MOV···· :Arg1, 0-0
················· MOVS· :GetArg2, Subroutine_ret······················· 'I beleive there is a typo in the original it says GetArg2 without :
················· ADD···· Subroutine_ret, #1
:GetArg2····· MOV···· :Arg2, 0-0

················ ..
················ JMP····· Subroutine_ret

:Arg1········ LONG· 0-0
:Arg2········ LONG· 0-0

Subroutine_ret·· RET

I think I understand the purpose and how it works. If I get it right, after the CALL Subroutine_ret contains an address of Arg1,·first ADD gets an address of Arg2, and second ADD gets an address·for return.
Again, if instructions are 32-bit and Arg1 and Arg2 are LONG, why do we add #1, and not #4?

I don't want to overload a forum with questions which may·seem too basic for most, so I'm trying to·clarify just what I can't find anywhere else.

Thank you,
Gennady

Fred Hawkins

1. PC+1 gives a return address to the instruction following the jump to the routine. If you loaded the ret with PC, you would be looping to routine.
In Cog memory, all addresses are longs and none finer grained. So each address is direct to the long which are numbered sequentially. Each Cog address can be used as (or in fact, is) a register just as much as it is an executable code location.

2. the sample code is executing in Cog memory which is counted by longs, not bytes.

Mike Green

PC is a register internal to the cog that is only implicitly referenced in jump instructions where the source value gets copied to the PC if the jump is taken (after the cycle where the PC is incremented) and the incremented PC is used as the result value for any JMPRET instruction.

Gennady

I·beleive I see a source of my confusion - I forgot that cog (assembly) thinks only in terms of longs, and 9 bit Source / Destination fields of instructions call for sequential numbering instead of physical addresses.

deSilva

As Fred explained: COG memory is addressed LONG-wise. I always found it helpful to think of COG memory as of consisting of "registers", enumerated from 0 to 511.

CALL ist a "macro"!
CALL xxx ist expanded to

JMPRET xxx_RET, xxx

That means, JMPRET stores the "return address" into the lower 9 bits of "cell" xxx_RET. You can work with this scheme at your convenience. You most often want to jump back to this return address (but not always!) - in that case you can conveniently arrange your code so that xxx_RET consists of JMP# 0-0

There is another macro for this: RET!

Note in Phil Pilgrim's code that he returns by

JMP subroutine_RET

and not by

JMP# subroutine_RET

But you can do both!