9.3 THE USE OF A THIRD STACK

An often proposed design alternative for stack machines is the use of a
third hardware stack. The purposes given for adding a third hardware stack are
usually for storage of loop counters and local variables.

Loop counters on the current stack machines are generally kept as the top
element of the return address stack. This is because subroutines and loops are
mutually well nested, and it is considered bad programming style for a
subroutine to attempt to access the loop index of its parent procedure. So,
while there is some conceptual merit to having loop indices in their own stack
to avoid cluttering the return stack with non-address data, the performance and
program effectiveness gains are not sufficient to justify the hardware
expense.

Local variable storage is another issue. Even when using the Forth
language, programmers have found that the concept of compiler-managed local
variables can make some programs easier to create and maintain. In order to do
this efficiently, the hardware needs access to a stack that is allocated in
frames, with random access to locations with in the frame. This is a
requirement that is very like that for supporting conventional languages. So,
in fact, the best solution is probably not to have a third hardware stack at
all. Rather, stack machines should support a frame pointer into a
software-managed program memory stack that is used both for conventional
language support and for support for local variables in Forth.