Compile-Time Decisions

Run-Time Information

Unit Activation

Activation Records

Language Issues

Static Storage Allocation

Activation Records for Languages that Support Recursion

Activation Records for Languages that Support Block Structure

Activation Records Whose Size Is Known at Unit Activation

Activation Records with Dynamically Varying Size

Activation Records for Concurrent Units

Storage Allocation for Lisp-like Languages

Storage Allocation for Arrays

12.3 Run-Time Storage Management

The previous sections of these modules presume that assembly language code is to be generated by our compiler. When this is done, we need not worry about allocating space for program quantities. The assembler and other system software take care of this. Production-quality compilers (usually) do not put out assembly language code. Instead, they emit object code directly. This section does not discuss object code formats for particular machines. Instead, we discuss how the compiler facilitates the storage of information that is to take place at run-time. All of these actions could be considered as part of either the semantic analysis phase or as preparation for code generation.

Values are assigned to variables at execution time, but it is the compiler, at compile time, which performs the necessary bookkeeping so that this happens smoothly.

If we consider a program as a sequence of "unit" calls (with the main program being the first unit), then we can see immediately some of the issues. Suppose a variable, declared to be of type integer, is assigned an integer-sized space in the machine. What happens if this unit is a procedure called recursively? Clearly, there must be more than one such space allocated for such a variable.