Stacked procedures – any limits?

Hugh

Trying to debug various problems with a chunk of code I'm working on I wondered whether there was any 'depth limit' as to how many procedures can be called by other procedures (without recursion)?

I.e., if the code goes too far down a limb of a 'procedure tree' can it lose sight of or 'forget' objects?

Or, am I perhaps talking complete rot?!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

RossH

@Hugh,

I don't think there is a limit - but you should make sure there is sufficient stack space allocated for the "worst case". See the explanation of _STACK in the Propeller manual (p202).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

MagIO2

The stack is the limit! Hence, functions having local variables and much parameters eat up the stack space very fast. The initial SPIN-COG has the whole not used HUB-RAM available as stack-space. So, the bigger your code is the less stack space you have. In smaller programs this is propably the COG with the biggest stack-space. For each other SPIN-COG that you start you are responsible for the stack space.

What happens in case you exceed the stack space depends on which COG is doing so. COG 0 stack space ends just before ROM. So, this one will most likely pass wrong parameters to the function as you can't overwrite ROM or forget where to go in case of return. Other COGs overwrite whatever variables are behind the stack array. And of course if these variables are written elsewhere the anything can go wrong.

Hugh

Aha, that might explain:

- The prop stopping and rebooting
- The prop freezing
- 'Garbled' variables
- Apparent 'interference' between objects

I only have·four parallel processes: one that is the initial (main) thread and three repetitive threads in dedicated cogs for things like switch monitoring. I had assumed that the main thread had access to to all the empty space in the RAM. I'll be a bit more generous with stack allocation and see what happens.

What with this and objects using the same variable names as each other, it takes a bit of management!

Thanks

Hugh

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

MagIO2

Hugh said...
What with this and objects using the same variable names as each other, it takes a bit of management!

I'm not sure if this is a new question. But here are my 2 cents about that:

If you have functions which are started in several COGs·the way of implementation·depends on what you want to do. Are they really allowed to access the same variables from the VAR section? If yes, then fine ... simply do a COGNEW calling this function.

If the same functions should work on separate variables, then simply put that code into an Object including the VAR. Then create several instances of the object. Each object then has it's own copy of the VAR section.

ObjectA.spin:
 
VAR
   long myData
 
PUB doSomething
   myData := cogid
 
 
Main.spin:
OBJ
   A1: "ObjectA"
   A2: "ObjectA"
 
PUB main
   A1.doSomething
   A2.doSomething

Of course then main has no direct access to both versions of the variables. If it needs to change the values you need to provide setter/getter functions in the object as well.

If you want to run the code in seperate COGs, you would provide a start/stop function which is doing the COGNEW for the main function.


Post Edited (MagIO2) : 10/29/2009 2:10:56 PM GMT