Call stack and stack frame

Call stack

Jump to: navigation, search

In computer science, a call stack is a special stack which stores information about the active subroutines of a computer program. (The active subroutines are those which have been called but have not yet completed execution by returning.) This kind of stack is also known as an execution stack, control stack, function stack, or run-time stack, and is often abbreviated to just "the stack".

A call stack is often used for several related purposes, but the main reason for having one is to keep track of the point to which each active subroutine should return control when it finishes executing. If, for example, a subroutine DrawSquare calls a subroutine DrawLine from four different places, the code of DrawLine must have a way of knowing which place to return to. This is typically done by code for each call within DrawSquare putting the address of the instruction after the particular call statement (the "return address") into the call stack.

Since the call stack is organized as a stack, the caller pushes the return address onto the stack, and the called subroutine, when it finishes, pops the return address off the call stack (and transfers control to that address). If a called subroutine calls on to yet another subroutine, it will push its return address onto the call stack, and so on, with the information stacking up and unstacking as the program dictates. If the pushing consumes all of the space allocated for the call stack, an error called a stack overflow occurs. Adding a subroutine's entry to the call stack is sometimes called winding; conversely, removing entries is unwinding.

There is usually exactly one call stack associated with a running program (or more accurately, with each task of a process), although additional stacks may be created for signal handling or cooperative multitasking (as with setcontext). Since there is only one in this important context, it can be referred to as the stack (implicitly, "of the task").

In high-level programming languages, the specifics of the call stack are usually hidden from the programmer. They are given access only to the list of functions, and not the memory on the stack itself. Most assembly languages on the other hand, require programmers to be involved with manipulating the stack. The actual details of the stack in a programming language depend upon the compiler, operating system, and the available instruction set.

 

Functions of the call stack

As noted above, the primary purpose of a call stack is:

  Storing the return address – When a subroutine is called, the location of the instruction to return to needs to be saved somewhere. Using a stack to save the return address has important advantages over alternatives. One is that each task has its own stack, and thus the subroutine can be reentrant, that is, can be active simultaneously for different tasks doing different things. Another benefit is that 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. This capability is automatic with a stack.

A call stack may serve additional functions, depending on the language, operating system, and machine environment. Among them can be:

  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 to do compared with, say, a heap allocation. Note that each separate activation of a subroutine gets its own separate space in the stack for locals.

  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.

  Evaluation stack – Operands for arithmetic or logical operations are most often placed into register 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. 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.

  Pointer to current instance - Some object-oriented languages (e.g., C++), store the this pointer along with function arguments in the call stack when invoking methods. The this pointer points to the object instance to which the method to be invoked to is associated with. The this pointer is an essential part of the execution context in object oriented languages, since it provides access to private data owned by the current object. The this pointer links layers used in object-oriented design with layers (types of stack frames) of the run-time call stack.

  Enclosing subroutine context - Some programming languages (e.g., Pascal and Ada) support nested subroutines, allowing an inner routine to access the context of its outer enclosing routine, i.e., the parameters and local variables within the scope of the outer routine. Such languages typically allow inner routines to call themselves recursively, resulting in multiple call stacks for the inner routines invocations, all of which point to the same outer routine context. This type of call frame is also known as a display.

  Other return state – Besides 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, only the return address and local variables are stored on the call stack (which in that environment is named the return stack); parameters are stored on a separate data stack. Most Forth's also have a third stack for floating point parameters.

Structure

A call stack is composed of stack frames (sometimes called activation records). Each stack frame corresponds to a call to a subroutine which has not yet terminated with a return. For example, if a subroutine named DrawLine is currently running, having just been called by a subroutine DrawSquare, the top part of the call stack might be laid out like this:

The stack frame at the top of the stack is for the currently executing routine. In the most common approach the stack frame includes space for the local variables of the routine, the return address back to the routine's caller, and the parameter values passed into the routine. The memory locations within a frame are often accessed via a register called the stack pointer, which also serves to indicate the current top of the stack. Alternatively, memory within the frame may be accessed via a separate register, often termed the frame pointer, which typically points to some fixed point in the frame structure, such as the location for the return address.

Stack frames are not all the same size. Different subroutines have differing numbers of parameters, so that part of the stack frame will be different for different subroutines, although usually fixed across all activations of a particular subroutine. Similarly, the amount of space needed for local variables will be different for different subroutines. In fact, some languages support dynamic allocations of memory for local variables on the stack, in which case the size of the locals area will vary from activation to activation of a subroutine, and is not known when the subroutine is compiled. In the latter case, access via a frame pointer, rather than via the stack pointer, is usually necessary since the offsets from the stack top to values such as the return address would not be known at compile time.

In many systems a stack frame has a field to contain the previous value of the frame pointer register, the value it had while the caller was executing. For example, in the diagram above, the stack frame of DrawLine would have a memory location holding the frame pointer value that DrawSquare uses. The value is saved upon entry to the subroutine and restored for the return. Having such a field in a known location in the stack frame allows code to access each frame successively underneath the currently executing routine's frame.

Programming languages that support nested subroutines have a field in the call frame that points to the call frame of the outer routine that invoked the inner (nested) routine. This is also called a display. This pointer provides the inner routine (as well as any other inner routines it may invoke) access to the parameters and local variables of the outer invoking routine.

For some purposes, the stack frame of a subroutine and that of its caller can be considered to overlap, the overlap consisting of the area where the parameters are passed from the caller to the callee. In some environments, the caller pushes each argument onto the stack, thus extending its stack frame, then invokes the callee. In other environments, the caller has a preallocated area at the top of its stack frame to hold the arguments it supplies to other subroutines it calls. This area is sometimes termed the outgoing arguments area or callout area. Under this approach, the size of the area is calculated by the compiler to be the largest needed by any called subroutine.