cognew DAT and multiple assembly declarations on multiple cogs

TransistorToaster

Hello,
For my application, I intend to use several cogs, some with different assembly code, some with the same code. I'd appreciate a little extra detail on the exact mechanics of the DAT declarations. Suppose the folloowing pseudocode:

cog1:=cognew(@asmprog1,@param1)
cog2:=cognew(@asmprog1,@param2)
cog3:=cognew(@asmprog2,@param3)
cog4:=cognew(@asmprog3,@param4)

DAT
ORG 0
asmprog1
...
RES VAR1 1
ORG 0
asmprog2
...
RES VAR2 1
ORG 0
asmprog3
...
RES VAR3 1

I don't quite understand how the compiler is going to allocate all the program memory and varaiable memory for each cog. The compiler probably doesn't take into accont the cognew commands and I don't see in the documentation if it COPIES the code under the DAT declaration into each new cogs private 512 longs memory space. I would think that would make sense. Is that the case?

If the cognew works under the COPYING hypothesis in the above paragraph, then each cog's 512 longs space would have initially the intended code followed by code destined for another cog. Is that right? Do I need to worry about stack space in each individual cog?

I just typed in the ORG statements in my above pseudocode. That command would not make sense for the copy mechanism. Do I need it at all?

Frank

Jasper_M

transistortoaster said...
Hello,
For my application, I intend to use several cogs, some with different assembly code, some with the same code. I'd appreciate a little extra detail on the exact mechanics of the DAT declarations. Suppose the folloowing pseudocode:

cog1:=cognew(@asmprog1,@param1)
cog2:=cognew(@asmprog1,@param2)
cog3:=cognew(@asmprog2,@param3)
cog4:=cognew(@asmprog3,@param4)

DAT
ORG 0
asmprog1
...
RES VAR1 1
ORG 0
asmprog2
...
RES VAR2 1
ORG 0
asmprog3
...
RES VAR3 1

I don't quite understand how the compiler is going to allocate all the program memory and varaiable memory for each cog. The compiler probably doesn't take into accont the cognew commands and I don't see in the documentation if it COPIES the code under the DAT declaration into each new cogs private 512 longs memory space. I would think that would make sense. Is that the case?

If the cognew works under the COPYING hypothesis in the above paragraph, then each cog's 512 longs space would have initially the intended code followed by code destined for another cog. Is that right? Do I need to worry about stack space in each individual cog?

I just typed in the ORG statements in my above pseudocode. That command would not make sense for the copy mechanism. Do I need it at all?

Frank

Yes, cognew and coginit do copy the 512 longs (Actually, t is 496, there are 16 special registers like INA, OUTA and so onthat are of course not copied).
The code for other cogs is also copied.

The orgs are however required - they tell what instructiion will be the first one in Cog memory. Otherwise jumps and using cog memory wouldn't work, they are used to translate labels into memory addresses by the compiler.

EDIT: Stack space has nothing to do with ASM programming, it is used only by SPIN (If I understood what you meant).

TransistorToaster

>EDIT: Stack space has nothing to do with ASM programming, it is used only by SPIN (If I understood what you meant).
I thought there might have been a stack usage for the return address of a call. I just read from p360 in the propellor manual that that the return address was done via modifying the return instruction.

Is the only stack usage occurence is at the call of a spin function with the extra variables after the function name (| )?

Jasper_M

All SPIN calls use stack. Calls in ASM are done with self modifying, but SPIN calls push the return pointer into stack.