Stack Overflow Sensing

[Garth Wilson]

(10-07-2014 07:56 PM)hansklav Wrote:  I suppose you're right that an extra Stack Overflow sensing register above the T register would not be necessary. The firmware would only have to watch for a state where a stack lift is done while the T register is "non-empty". But stack initialization with Stack Overflow Sensing ON would need more than zeroing a pointer, it would need to set at least Y, Z and T to the "empty" state. X could be left unchanged (maybe that is even more useful than setting it to zero for historical reasons).

Imagine this, per my earlier post: You have an 8-level stack, in memory addresses $F8 to $FF, ie, base address $F8 and a 3-bit index value 0 through 7 (7 being 111 in binary, so one more would wrap around). For the case of simplicity of discussion, if it's on a calculator, let's say these memory locations each consist of as many bits as the calculator's normal registers, like the HP-41's 56 bits. When the stack is empty, the index is 7, so the next location to be written is $F7. What's in Z? The index value has to be 4 or less to even have a Z, so you can consider Z to be empty, non-existent, or zero, however you like, and it won't matter what's in any of the addresses $F8 through $FF. The When you push something onto the stack, it goes in $F7, and the index is decremented to 6. The fact that the index is now 6 means the stack is now one cell deep. When the index gets down to 0, you have only one cell left to push something onto the stack with. After that push, any more will mean an overflow. Going the other direction, any attempt to drop a cell off the stack when the index is at 7 will mean an underflow. Unused registers don't have to be zeroed, because the index tells you that the stack is too shallow to use those memory spaces.

hansklav Wrote:Could you please show me a real world calculation leading to a stack overflow in an 8-level stack?

To quote an earlier (5/28/2004) post of mine: Ah, but now you're thinking of just one equation, done by hand. Think of a program where you're using let's say 3 levels on the stack, and you want to run a subroutine to get the next number to work with. Let's say that subroutine needs 3 levels as well, and futher, that subroutine calls another one that needs 2 or 3 or 4, etc.. As you're programming, you don't have to care what's beyond the few levels you're working with at the moment. Each routine is concerned with only its few stack levels, even if there are 23 other things on the stack below. It doesn't matter. You won't get confused. We do this in Forth all the time, and most things work the first time we try them, unlike the case with other languages. Stack comments in the code only mention the few things that are relevant to the particular routine, regardless of what else uses that routine and leaves other numbers pending on the stack. The maximum stack depth is deep enough that we never have to worry about overflowing it.

To further add to the stack space requirement, I've had control-timer interrupts on my 41cx, and I/O interrupts in other environments, which would hit at any time-- and you better have the stack depth to service them without fouling things up for the main program when the calculator or computer gets back to it. If you don't, then the interrupt needs extra overhead to store away the existing stack so it can restore it when it's ready to give control back to the main program.