Separating the "Stack" and "Free" regions in the "View Info" window of

epmoyer

It would be very useful if the IDE separately accounted for and displayed the "stack" and "free" memory regions in the "View Info" window. When developing applications which allocate large blocks of memory as "stack" (such as for double buffered video) one often finds oneself having to convert the video buffer size (2 * 0x3000 = 0x6000 in my case) to decimal, then subtract it (plus the additional stack utilization which is truly for stack space) from the (decimal) Stack/Free size to figure out how much code space you really have available. In situations where you are pushing the available code space to its limits this can be frustrating. By separating the two, programmers would immediately be able to see how much free space was remaining.

I'd live to see:
1) "Stack" and "Free" shown as separate line items
2) "Stack" and "Free" shown in different colors on the memory utilization bar (and memory dump)
3) The size of all regions (Program, Variable, Stack, and Free) shown in both Hex and decimal

Paul Baker

The way the Propeller is organized, there is no difference between Stack and Free. The stack for the main process is set to the first unused long and grows upward. It is the only process which has an unbounded stack. Since that stack is unbounded and run-time there is no means for the compiler to determine it's extent.

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

Parallax, Inc.

epmoyer

Yes, I didn't mean the runtime stack and free usage, I meant the requested _stack and _free allocations. The Spin compiler provides access to variables "_stack" and "_free", which according to manual are designed to allow a programmer to specify ahead of time how much stack and free space will be required, minimum. The intent, again according to manual, is that the compile will fail if you exceed the available code space.

What I have seen people doing in practice (in, for example, the sample code in the Hydra development kit) is using "_stack" to specify both the stack space and large fixed buffer space their program will require. For instance, in a double buffered video application using 12K video pages, the program would set _stack to (12K + 12K + 64) / 4. That way you tell the compiler that you need 24K for video pages and 64 bytes for stack, and if your code gets bigger than 32K - (12K + 12K + 64) then the compile fails. It is probably more appropriate to set _free to (12K + 12K) / 4, and to set _stack to 64/4, but I believe the effect is the same.

In practice, what happens is that the "View Info" screen shows you (in decimal, and in longs) that you have some amount of stack/free space available, but if you really want to know how close you are to running out of the space you requested then you have to subtract your _stack and _free settings (converted to decimal, and to longs) from the reported stack/free value. It seems a shame that after going to the trouble of telling the compiler how much space you need it won't tell you clearly how close you are to running out.

I'd love to see the requested _stack and _free regions shown graphically in the memory utilization bar, and to see a number somewhere for the remaining "free" space after _stack and _free have been subtracted. Maybe show _stack beginning at the end of code, show _free ending at 0x7FFF, and show the space between them as the available "remaining" space. If all of that is too confusing or misleading for most users then at the very least being able to see the calculated "remaining" space would be terrific.