Where is the stack?

Kye

Okay, so, I was thinking about how to implement a dynamic memory object of my own that would manage a heap growing from the bottom of the memory up when I realized that I don't know what·spin is doing with that empty memory.

That said, where is the call stack that is referenced in spin documentation? Does it float around in that empty memory after variable space? And is you how do I know how big it will grow?

Because if I want to make a heap I need to know what the call stack is doing.·Is their any documentation on this anywhere?

Thanks,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

hippy

The stack comes after all variables in the program and heads upwards towards $7FFF. It's locked in place ( the program header indicates where it starts ) and simply grows and shrinks as necessary.

The SP isn't exposed to Spin programs but there is a trick to peek inside a running Cog from Spin to see what the SP contains. Some details are towards the end of this thread and there may be more specific details in other threads, and threads on Zero-Footprint Debugging holds details of a lot of the trickery ...

http://forums.parallax.com/showthread.php?p=739430

It's all quite complicated, and it's been a while since I've used the Prop at that level of tinkering.

Kye

Hmm, so what happens when you run out of stack space? I'm assuming that you can't have recursive explosion right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

hippy

I don't recall there being any upper limit checking on SP so once you get above $7FFF it tries to write to $8000 where ROM is, data accessed will not be as expected, and a return will probably shoot the program off into outer space.

That's for the main program, top-level object. Sub-objects will have their stack in whatever array was used for them in CogNew/CogInit. When their SP gets too large it will start writing on other data.

4Alex

@Kye:

I experienced out-of-stack space (up to yesterday, actually) while trying to solve a serial comms problem. It's not nice: the propeller "lost-it" and transmitted a lot of junk through the serial port and then stopped (at least transmitting). Would do the same thing each time I reset the processor. Increasing the stack variable (_STACK) until the problem disappeared. Not very scientific approach but it worked. Over nesting was part of the problem.

Cheers,

4Alex