Page 3 of 4
The Function Stack
LIFO stacks seem fun but do they have any real value in computing?
There are so many applications it is difficult to know where to begin but the factor that unites them all is the way that a LIFO stack alters the order of things in a regular way.
For example, when a programmer writes a subroutine or function call:
Then control is passed to the part of the program labelled Sub1 and when Sub1 is complete it executes a Return which passes control back to the instruction following the call.
This allows programmers to break a program down into modules, which can be called as and when needed.
Now how do you think that this valuable facility is implemented?
You could just keep the return address stored in a fixed location and when the “Return” instruction is given all that happens is that the fixed location is used to get the return address.
Fine but what if the programmer writes another Call within Sub1?
Of course. it is legal and useful to allow a subroutine to call a subroutine and so on. You can’t cope with this using a single location to store the return address – you have to store all the return addresses.
The clue as to how this should be done comes from a consideration of how the “Return” instruction should work.
If you call Sub1, and it then calls Sub2 which then calls Sub3 then the first return should take us back to the instruction following call Sub2, and the second return takes us back to the instruction following call Sub1.
That is, the returns work in the opposite order to the calls – now you should be thinking “stack!”
The subroutine facility is usually implemented using a stack.
When a call is made the return address is pushed onto the stack and the return simply pops the latest return address from the top of the stack. It all takes care of itself and as long as we don’t run out of stack space you can call as many subroutines as you like.
Stack oriented languages
This use of stacks to implement subroutine/function call and return has proved so useful that it has more or less taken over our approach to programming languages.
Almost all modern languages have become so stack oriented that their entire structure is based on the use of a stack.
For example, many languages make use of parameters which can be passed to a subroutine or function.
These are usually pushed onto the stack before the function is called. They are accessible to the subroutine as items on the stack along with the return address.
The called subroutine cleans the stack up by removing all the parameters before it ends. It can also leave results on the stack for the calling program to make use of. In other words functions communicate with each other by storing data on the stack.
In other words the LIFO property allows function calls to be correctly nested and for parameters and results to be passed.
In addition functions generally create all their variables on the stack – so called local variables because they exist for as long as the subroutine is active and then they are gone.In other words all of a functions local variables are erased when the function returns and the stack is cleaned up.
This is the reason why function local variables have function scope and why they override variables declared in the calling programming.
The use of the stack to implement all of these facilities has had a radical effect on the design or programming languages and made things that were once seen as difficult very easy indeed.
The first language to be “stack oriented” was Algol, but all of the block structured modern languages – Pascal, Modula, C, C++, C#, VB, Java and so on - owe it and the LIFO stack a debt.
However, as with all good things it is very possible to take things too far. There was a time when the stack was thought to be so important that machines and languages were based on it and nothing but it!
The reason is due to the simple fact that a stack can be used to evaluate an arithmetic expression or any expression that uses operators.