As noted above, the primary purpose of a call stack is to
store the return addresses. When a subroutine is called, the location (address) of the instruction at which the calling routine can later resume must be saved somewhere. Using a stack to save the return address has important advantages over some alternative
calling conventions, such as saving the return address before the beginning of the called subroutine or in some other fixed location. One is that each task can have its own stack, and thus the subroutine can be
thread-safe, that is, able to be active simultaneously for different tasks doing different things. Another benefit is that by providing
reentrancy,
recursion is automatically supported. When a function calls itself recursively, a return address needs to be stored for each activation of the function so that it can later be used to return from the function activation. Stack structures provide this capability automatically. Depending on the language, operating system, and machine environment, a call stack may serve additional purposes, including, for example: ; Local data storage : A subroutine frequently needs memory space for storing the values of
local variables, the variables that are known only within the active subroutine and do not retain values after it returns. It is often convenient to allocate space for this use by simply moving the top of the stack by enough to provide the space. This is very fast when compared to
dynamic memory allocation, which uses the
heap space. Note that each separate activation of a subroutine gets its own separate space in the stack for locals. : Similarly, an
inline block may allocate a stack frame for local variables. As with a call frame, the values are lost when the block exits. ; Parameter passing : Subroutines often require that values for
parameters be supplied to them by the code which calls them, and it is not uncommon that space for these parameters may be laid out in the call stack. Generally if there are only a few small parameters,
processor registers will be used to pass the values, but if there are more parameters than can be handled this way, memory space will be needed. The call stack works well as a place for these parameters, especially since each call to a subroutine, which will have differing values for parameters, will be given separate space on the call stack for those values. In
object-oriented languages such as
C++, the list of parameters may also include the
this pointer. ; Evaluation stack : Operands for arithmetic or logical operations are most often placed into registers and operated on there. However, in some situations the operands may be stacked up to an arbitrary depth, which means something more than registers must be used (this is the case of
register spilling). The stack of such operands, rather like that in an
RPN calculator, is called an evaluation stack, and may occupy space in the call stack. ; Enclosing subroutine context : Some programming languages (e.g.,
Pascal and
Ada) support declaration of
nested subroutines, which are allowed to access the context of their enclosing routines, i.e., the parameters and local variables within the scope of the outer routines. Such static nesting can repeat (a function declared within a function declared within a function…). The implementation must provide a means by which a called function at any given static nesting level can reference the enclosing frame at each enclosing nesting level. This reference is commonly implemented by a pointer to the frame of the most recently activated instance of the enclosing function, called a "downstack link" or "static link", to distinguish it from the "dynamic link" that refers to the immediate caller (which need not be the static parent function). : Instead of a static link, the references to the enclosing static frames may be collected into an array of pointers known as a
display which is indexed to locate a desired frame. The depth of a routine's lexical nesting is a known constant, so the size of a routine's display is fixed. Also, the number of containing scopes to traverse is known, the index into the display is also fixed. Usually, a routine's display is located in its own stack frame, but the
Burroughs B6500 implemented such a display in hardware which supported up to 32 levels of static nesting. : The display entries denoting containing scopes are obtained from the appropriate prefix of the caller's display. An inner routine which recurses creates separate call frames for each invocation. In this case, all of the inner routine's static links point to the same outer routine context. ; Enclosed block context : In some languages, e.g.,
ALGOL 60,
PL/I, a block within a procedure may have its own local variables, allocated on block entry and freed on block exit. Similarly, the block may have its own exception handlers, deactivated at block exit. ; Other return state : Beside the return address, in some environments there may be other machine or software states that need to be restored when a subroutine returns. This might include things like privilege level, exception-handling information, arithmetic modes, and so on. If needed, this may be stored in the call stack just as the return address is. The typical call stack is used for the return address, locals, and parameters (known as a
call frame). In some environments there may be more or fewer functions assigned to the call stack. In the
Forth programming language, for example, ordinarily only the return address, counted loop parameters and indexes, and possibly local variables are stored on the call stack (which in that environment is named the
return stack), although any data can be temporarily placed there using special return-stack handling code so long as the needs of calls and returns are respected; parameters are ordinarily stored on a separate
data stack or
parameter stack, typically called
the stack in Forth terminology even though there is a call stack since it is usually accessed more explicitly. Some Forths also have a third stack for
floating-point parameters. == Structure ==