Using cog RAM for the stack?

RobertDyer

I am somewhat new to the Propeller (and this forum!!), so I may be asking a question that has previously been answered. I didn't find it, but if so just point me there.
I have a question about how the Hub functions, and the use of global RAM.
My observations:
1.) In a Spin program, the VAR block defines variables in global RAM, and the DAT block uses cog RAM.
2.) The Spin objects I’ve seen use the VAR block for definition of cog variables and stack space.
My assumptions:
1.) The global RAM is a mutually-exclusive, shared system resource, which makes it subject to the operations and limitations of the Hub, including the round-robin access timing windows.
My conclusions:
1.) Every assignment operation to global RAM variables, every stack operation which include intermediate result storage, method calls and returns, etc., are all subject to waiting for that cog’s round-robin access window to the global RAM from the Hub.
My questions:
1.) Aren’t Spin programs that use global RAM for these things "bottle-necked" by operation of the Hub, even if they only use one cog?
2.) Wouldn't Spin code execute faster if variables that are only used locally within the object were defined in the local cog RAM DAT block, and only use the global RAM VAR block for global variables that are needed for inter-cog communication? (I know cog RAM is limited, so this would require judicious use of that resource, probably using the _FREE constant and/or FIT directive.)
3.) Wouldn't using VAR for global variables, and DAT for local variables and stack space, also produce cleaner, more encapsulated code?
Thanks!

kwinn

RobertDyer wrote: »

I am somewhat new to the Propeller (and this forum!!), so I may be asking a question that has previously been answered. I didn't find it, but if so just point me there.
I have a question about how the Hub functions, and the use of global RAM.
My observations:
1.) In a Spin program, the VAR block defines variables in global RAM, and the DAT block uses cog RAM.

The VAR and DAT blocks both use cog RAM for variables. The DAT block is only transferred to cog RAM if a cognew instruction is executed.

2.) The Spin objects I’ve seen use the VAR block for definition of cog variables and stack space.
My assumptions:
1.) The global RAM is a mutually-exclusive, shared system resource, which makes it subject to the operations and limitations of the Hub, including the round-robin access timing windows.
My conclusions:
1.) Every assignment operation to global RAM variables, every stack operation which include intermediate result storage, method calls and returns, etc., are all subject to waiting for that cog’s round-robin access window to the global RAM from the Hub.
My questions:
1.) Aren’t Spin programs that use global RAM for these things "bottle-necked" by operation of the Hub, even if they only use one cog?
2.) Wouldn't Spin code execute faster if variables that are only used locally within the object were defined in the local cog RAM DAT block, and only use the global RAM VAR block for global variables that are needed for inter-cog communication? (I know cog RAM is limited, so this would require judicious use of that resource, probably using the _FREE constant and/or FIT directive.)
3.) Wouldn't using VAR for global variables, and DAT for local variables and stack space, also produce cleaner, more encapsulated code?
Thanks!

Spin programs cannot access cog ram. Spin programs consist of bytecodes in hub ram that are read, interpreted, and executed by a PASM (machine language) program running in a cog. A spin program that is executed by another cog is executed by another copy of the PASM bytecode interpreter that is loaded into that other cog.