How much stack/free space is really needed.

TJHJ

Is there a way to tell how much stack/free space is needed in order for the program to run correctly?
I am getting very close to the limit with only 100 longs left over in the Stack/Free.

Thanks
TJ

Paul Baker

Yes Phil Pilgrim (PhiPi) created a Stack monitor utility·that will tell you how much stack you have consumed: http://forums.parallax.com/showthread.php?p=577317

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

TJHJ

Sorry I should have clarified more, maybe I am missing part of the concept here.

I view the info (F8) on the current object and I have 138 longs of stack/free left.

This is a represntation of the Main ram in my mind. Objects that I call into new cogs are free to use as much of the 2k as they would like? So their stack is not an issue as the new cogs I generate are very small.

There is a VGA driving object present which takes a killer 22k of ram. Creating my space issue, With the limit of the 2k per cog, the vga driver is writing back to the main ram in order to deal with the large ram size. Are any of the cogs using Main Ram to perform calculations or are they only using there 2k? So the vga cog performs its calculation then dumps it back to the main ram to be delt with. If this is the case there is no problem that I only have 138 longs left?

The stack monitor only looks at the left over stack in each cog? Not looking at the main ram?

Thanks again, I hope this makes more sense.

TJ

Mike Green

First of all, cog programs (assembly language) don't use stacks. The 2K of cog ram is simply used for both instructions and data in any way that the program needs / uses. If you start a Spin interpreter as the program running in a cog, this uses hub memory (main ram) for storage for the Spin program being interpreted one piece of which is the Spin program's stack space.

Most of the memory used by the VGA object is used for a screen buffer. This consists of an array of "tile pointers" plus the tiles themselves that make up the image shown on the display. Tiles are just small square areas on the screen, usually 16 pixels by 16 pixels or 16 by 32. The cog providing the VGA signal goes through the tile pointers and bitmap and extracts a display line at a time which is stored in the cog's memory where it's used to generate the video signal. For VGA, usually there are at least two cogs involved. One is buffering up the next scan line while the other is producing the video signal, then they shift roles.

The 138 longs is potentially a problem. That's all the memory available to the main Spin cog for return addresses and local variables. The stack monitor only looks at the main cog as far as I remember.

Erik Friesen

My understanding on this issue has been kind of vague also. I understand that each cog has its own ram that is loaded with the spin interpreter when you run a new spin cog.?

Where exactly are local variables located and why will they initialize with data at times?

What else uses this extra ram?

How many longs will the return addresses use typically?

I ask these questions because I have an 8 cog program that is approaching the upper limits also.

Mike Green

1) Yes
2) Local variables are allocated in the stack above the method parameters
3) Temporary values are pushed onto the stack until they're used (a + b becomes push a, push b, add)
4) Each method call ("stack frame") requires something like 4 longs which includes the result value, return address, address of previous "stack frame" and some other stuff.