| Call Stack |
Article Index for Call |
Website Links For Call |
Information AboutCall Stack |
| CATEGORIES ABOUT CALL STACK | |
| control flow | |
|
In Computer Science , a call stack is a special Stack which stores information about the active Subroutine s 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 shortened 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 where to return. 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 or Thread 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 Language s, 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 Language s 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:
A call stack may serve additional functions, depending on the language, operating system, and machine environment. Among them can be:
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 Forths 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 (where the stack is growing towards the top):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 stack is 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. USE Call site processing Usually the call stack manipulation needed at the site of a call to a subroutine is minimal (which is good since there can be many call sites for each subroutine to be called). The values for the actual arguments are evaluated at the call site, since they are specific to the particular call, and either pushed onto the stack or placed into registers, as determined by the Calling Convention being used. The actual call instruction, such as "Branch and Link," is then typically executed to transfer control to the code of the target subroutine. Callee processing In the called subroutine, the first code executed is usually termed the Subroutine Prologue , since it does the necessary housekeeping before the code for the statements of the routine is begun. The prologue will commonly save the return address left in a register by the call instruction by pushing the value onto the call stack. Similarly, the current stack pointer and/or frame pointer values may be pushed. Alternatively, some instruction set architectures automatically provide comparable functionality as part of the action of the call instruction itself, and in such an environment the prologue need not do this. If frame pointers are being used, the prologue will typically set the new value of the frame pointer register from the stack pointer. Space on the stack for local variables can then be allocated by incrementally changing the stack pointer. The Forth Programming Language allows explicit winding of the call stack (called there the "return stack"). The Scheme Programming Language allows the winding of special frames on the stack through a " Dynamic Wind ". Return processing When a subroutine is ready to return, it executes an epilogue that undoes the steps of the prologue. This will typically restore saved register values (such as the frame pointer value) from the stack frame, pop the entire stack frame off the stack by changing the stack pointer value, and finally branch to the instruction at the return address. Under many calling conventions the items popped off the stack by the epilogue include the original argument values, in which case there usually are no further stack manipulations that need to be done by the caller. With some calling conventions, however, it is the caller's responsibility to remove the arguments from the stack after the return. Unwinding Returning from the called function will pop the top frame off of the stack, perhaps leaving a return value. Some languages (such as Pascal ) allow a global Goto statement to transfer control out of a nested function and into a previously invoked outer function. This operation requires the stack to be unwound, removing as many stack frames as necessary to restore the proper context to transfer control to the target statement within the enclosing outer function. Such transfers of control are generally used only for error handling. Other languages (such as Object Pascal ) provide Exception Handling , which also requires unwinding of the stack. The stack frame of a function contains one or more entries specifying exception handlers. When an exception is thrown, the stack is unwound until an exception handler is found that is prepared to handle (catch) the exception. Common Lisp allows control of what happens when the stack is unwound by using the unwind-protect special operator.When applying a Continuation , the stack is unwound and then rewound with the stack of the continuation. This is not the only way to implement continuations; for example, using multiple, explicit stacks, application of a continuation can simply activate its stack and wind a value to be passed. PERFORMANCE ANALYSIS Taking random-time samples of the call stack can be very useful in optimizing performance of programs. The reason is if a subroutine call instruction appears on the call stack for a certain fraction of execution time, its possible removal would save that much time. See Performance Analysis . SECURITY The mixing of control flow data affecting the execution of code (return addresses, saved frame pointers) and simple program data (parameters, return values) in a call stack is a security risk, possibly Exploit able through Buffer Overflow s (in which article the risk and exploitation are explained). SEE ALSO EXTERNAL LINKS |
|
|