- Procedure calls and returns are managed by a runtime stack called control stack.
- Each live activation has an activation record (also called a frame) on the control stack, with the root of the activation tree at the bottom, and the entire sequence of activation records on the stack corresponding to the path in the activation tree to the activation where control currently resides.
- The later activation has its record at the top of the stack.
- We draw control stacks with the bottom of the stack higher than the top, so the element in an activation record that appears lowest on the page is actually closest to the top of the stack.
- The contents of activation records vary with the language being implemented.
Showing a list of kinds of data that might appear in an activation record.
- Temporary values, those arising from the evaluation expressions, in cases where those temporaries cannot be held in registers.
- Local data belonging to the procedure whose activation record this is.
- A saved machine status, with information about the state of the machine just before calling to the procedure. This information typically includes the return address and the contents of the registers that were used by the calling procedure and that must be restored when the return occurs.
- An “access link” may be needed to locate data needed by the called procedure but found elsewhere, e.g., in another activation record.
- A control link, pointing to the activation record of the caller.
- Space for the return value of the called function, if any. Not all procedures return a value, and if one does, we may prefer to place that value in a register for efficiency.
- The actual parameters used by the calling procedure. These values are not placed in the activation record but rather in registers, when possible, for greater efficiency.