Cooper K.Engineering a compiler

Figure 7.3: Name Space Structure of Di erent Languages

Pascal and pl/i have simple Algol-like scoping rules. As with Fortran, they have a global name space that holds procedures and variables. As with Fortran, each procedure creates its own local name space. Unlike Fortran, a procedure can contain the declarations of other procedures, with their own name spaces. This creates a set of nested lexical scopes. The example in Figure 7.1 does this, nesting Fee and Fie in Main, and Fum inside Foe inside Fie. Section 7.3.5 examines nested scopes in more detail.

7.3.2Activation Records

The creation of a new, separate, name space is a critical part of the procedure abstraction. Inside a procedure, the programmer can declare named variables that are not accessible outside the procedure. These named variables may be initialized to known values. In Algol-like languages, local variables have lifetimes that match the procedures that declare them. Thus, they require storage during the lifetime of the invocation and their values are of interest only while the invocation that created them is active.

To accommodate this behavior, the compiler arranges to set aside a region of memory, called an activation record (ar), for each individual call to a procedure. The ar is allocated when the procedure is invoked; under most circumstances, it is freed when control returns from the procedure back to the point in the

parameters

register save area

return value

return address arp access link

caller arp

locals

Figure 7.4: A typical activation record

program that called it. The ar includes all the storage required for the procedure’s local variables and any other data needed to maintain the illusion of the procedure. Unless a separate hardware mechanism supports call and return, this state information includes the return address for this invocation of the procedure. Conveniently, this state information has the same lifetime as the local variables.

When p calls q, the code sequence that implements the call must both preserve p’s environment and create a new environment for q. All of the information required to accomplish this is stored in their respective ars. Figure 7.4 shows how the contents of an ar might be laid out. It contains storage space for local variables, the ar pointer of the calling procedure, a pointer to provide access to variables in surrounding lexical scopes, a slot for the return address in the calling procedure, a slot for storing the returned value (or a pointer to it), an area for preserving register values on a call, and an area to hold parameter values. The entire record is addressed through an activation record pointer, denoted arp. Taken together, the return address and the caller’s arp form a control link that allows the code to return control to the appropriate point in the calling procedure.

7.3.3Local Storage

The activation record must hold all of the data and state information required for each invocation of a procedure p. A typical ar might be laid out as shown in Figure 7.4. The procedure accesses it ar through the arp. (By convention, the arp usually resides in a fixed register. In the iloc examples, r0 holds the arp.) The arp points to a designated location in the ar so that all accesses to the ar can be made relative to the arp.

Items that need space in the ar include the arp of the calling procedure, a return address, any registers saved in calls that the current procedure will make, and any parameters that will be passed to those procedures. The ar may also include space for a return value, if the procedure is a function, and an access link that can be used to find local variables of other active procedures.

Space for Local Data Each local data item may need space in the ar. The compiler should assign each location an appropriately-sized area, and record in the symbol table its o set from the arp. Local variables can then be accessed as o sets from the arp. In iloc, this is accomplished with a loadAO instruction. The compiler may need to leave space among the local variables for pointers to variable-sized data, such as an array whose size is not known at compile time.

Space for Variable-length Data Sometimes, the compiler may not know the size of a data item at compile time. Perhaps its size is read from external media, or it must grow in response to the amount of data presented by other procedures. To accommodate such variable-sized data, the compiler leaves space for a pointer in the ar, and then allocates space elsewhere (either in the heap or on the end of the current ar) for the data once its size is known. If the register allocator is unable to keep the pointer in a register, this introduces an extra level of indirection into any memory reference for the variable-length data item. If the compiler allocates space for variable-length data in the ar, it may need to reserve an extra slot in the ar to hold a pointer to the end of the ar.

Initializing Variables A final part of ar maintenance involves initializing data. Many languages allow the programmer to specify a first, or initial, value for a variable. If the variable is allocated statically—that is, it has a lifetime that is independent of any procedure—the data can be inserted directly into the appropriate locations by the linker/loader. On the other hand, local variables must be initialized by executing instructions at run-time. Since a procedure may be invoked multiple times, and its ars may be placed at di erent addresses, the only feasible way to set initial values is to generate instructions that store the necessary values to the appropriate locations. This code must run before the procedure’s first executable statement.

Space for Saved Register Values When p calls q, either p or q must save the register values that p needs. This may include all the register values; it may be a subset of them. Whichever procedure saves these values must restore them after q’s body finishes executing. This requires space, in the ar, for the saved registers. If the caller saves its own registers, then p’s register save area will contain values related to its own execution. If the callee saves the caller’s registers, then the value of p’s registers will be preserved in q’s register save area.

7.3.4Allocating Activation Records

The compiler must arrange for an appropriately sized activation record for each invocation of a procedure. The activation record must be allocated space in memory. The space must be available when the calling procedure begins to execute the procedure call, so that it can fill in the various slots in the ar that contain information not known at compile-time, establishing both the control link and the access link. (Since a procedure can be called from many call sites, this information cannot, in general, be known before the invocation.) In general,

the compiler has several choices for how to allocate activation records.

Stack Allocation of Activation Records When the contents of an ar are limited to the lifetime of the procedure invocation that caused its creation, and a called procedure cannot outlive its caller, the compiler can allocate ars using a stack discipline. With these restrictions, calls and returns are balanced; each called procedure eventually returns, and any returns occurring between a procedure p’s invocation and p’s eventual return are the result (either directly or indirectly) of some procedure call made inside p. Stack allocation is attractive because the cost of both allocation and deallocation are small—a single arithmetic operation. (In contrast, general heap management schemes require much more work. See Section 7.7.)

Local variables whose sizes are not known at compile time can be handled within a stack allocation scheme. The compiler must arrange to allocate them at the end of the ar that matches the end of the stack. It must also keep an explicit pointer to the end of the stack. With these provisions, the running code can extend the ar and the stack to create space when the variable’s size becomes known. To simplify addressing, the compiler may need to set aside a slot in the local variable area that holds a pointer to the actual data. Figure 7.5 shows the lower portion of an activation record where a dynamically-sized array, A, has been allocated at the end of the ar. The top of stack position (tos) is shown both before and after the allocation of A.

With stack-allocated ars, the ar for the currently executing procedure always resides at the top of the stack. Unless the size of A exceeds the available stack space, it can be added to the current ar. This allocation is inexpensive; the code can simply store tos in the slot reserved for a pointer to A and increment tos by the size of A. (Compare this to the cost of heap allocation and deallocation in Section 7.7.) Of course, when it generates code for this allocation, the compiler can insert a test that checks the size of A against available

space. If insu cient stack space is available, it can either report an error or try another allocation mechanism. To allocate A on the heap would require the same pointer field for A in the ar. The code would simply use the standard heap management routines to allocate and free the space.

Heap Allocation of Activation Records If a procedure can outlive its caller, as in continuation-passing style, stack allocation is inappropriate because the caller’s activation record cannot be freed. If a procedure can return an object that includes, explicitly or implicitly, references to its local variables, stack allocation is inappropriate because it will leave behind dangling pointers. In these situations, ars can be kept in heap storage. This lets the code dismantle and free an ar when all the pointers to it have been discarded. Garbage collection is the natural technology for reclaiming ars in such an environment, since the collector will track down all the pointers and ensure safety. (See Section 7.7.)

Static Allocation of Activation Records If a procedure q calls no other procedures, then q can never have more than a single active invocation. We call q a leaf procedure since it terminates a path through a graph of the possible procedure calls. The compiler can statically allocate activation records for leaf procedures. If the convention requires a caller to save its own registers, q will not need the corresponding space in its ar. This saves the run-time cost of ar allocation.

At any point in the execution of the compiled code, only one leaf procedure can be active. (To have two such procedures active, the first one would need to call another procedure, so it would not be a leaf.) Thus, the compiler can allocate a single static ar for use by all of the leaf procedures. The static ar must be large enough to accommodate any leaf procedure. The static variables declared in any of the leaf procedures can be laid out together in that single ar. Using a single static ar for leaf procedures reduces the run-time space overhead of static ar allocation.

Coalescing Activation Records If the compiler discovers a set of procedures that are always invoked in a fixed sequence, it may be able to combine their activation records. For example, if a call from fee to fie always results in calls to foe and fum, the compiler may find it profitable to allocate the ars for fie, foe, and fum at the same time. If ars are allocated on the heap, the savings are obvious. For stack-allocated ars, the savings are minor.

If all the calls to fie cannot be changed to allocate the coalesced ar, then the calls to foe and fum become more complex. The calling sequence generated must recognize when to allocate a new ar and when one already exists. The compiler must either insert conditional logic in the calling sequence to handle this, or it can generate two copies of the code for the a ected procedures and call the appropriate routines. (The latter is a simple case of a transformation known as procedure cloning. See Chapter 14.)

7.3.5 Nested lexical scopes

Many Algol-like languages allow the programmer to define new name spaces, or lexical scopes, inside other scopes. The most common case is nesting procedure definitions inside one another; this approach is exemplified by Pascal. Any Pascal program that uses more than one procedure has nested scopes. C treats each new block, denoted by brackets { and }, as a distinct scope. Thus, the programmer can declare new variables inside each block.

Lexical scoping rules follow one general principle. Inside a given scope, names are bound to the lexically closest declaration for that name. Consider, again, our example Pascal program. It is shown, along with information about the nesting of lexical scopes, in Figure 7.6. It contains five distinct scopes, one corresponding to the program Main and one for each of the procedures Fee, Fie,

Foe, and Fum. Each procedure declares some set of variables drawn from the set of names x, y, and z. Pascal’s name scoping rules dictate that a reference to a variable is bound to the nearest declaration of that name, in lexical order. Thus, the statement x := 1; inside Fee refers to the integer variable x declared in Fee. Since Fee does not declare y, the next statement refers to the integer variable y declared in Main. In Pascal, a statement can only “see” variables declared in its procedure, or in some procedure that contains its procedure. Thus, the assignment to x in Fum refers to the integer variable declared in Main, which contains Fum. Similarly, the reference to z in the same statement refers to the variable declared in Foe. When Fum calls Fee, Fum does not have access to the value of x computed by Fee. These scoping relationships are detailed in the table on the right-hand side of Figure 7.6. The nesting relationships are depicted graphically immediately below the table. The bottom graph shows the sequence of procedure calls that occur as the program executes.

Most Algol-like languages implement multiple scopes. Some, like Pascal, pl/i, and Scheme, allow arbitrary nesting of lexical scopes. Others have a small, constant set of scopes. Fortran, for example, implements a global name space and a separate name space for each subroutine or function. (Features such as block data, statement functions, and multiple-entry procedures slightly complicate this picture.)

C implements nested scopes for blocks, but not for procedures. It uses the static scope, which occurs at the file-level, to create a modicum of the modularity and information hiding capabilities allowed by Pascal-style nested procedures. Since blocks lack both parameter binding and the control abstraction of procedures, the actual use of nested scopes is far more limited in c. One common use for the block-level scope is to create local temporary storage for code generated by expanding a pre-processor macro.

In general, each scope corresponds to a di erent region in memory, sometimes called a data area. Thus, the data area in a procedure’s activation record holds its locally-declared variables. Global variables are stored in a data-area that can be addressed by all procedures.

To handle references in languages that use nested lexical scopes, the compiler translates each name that refers to a local variable of some procedure into a pairlevel,o set , where level is the lexical nesting level of the scope that declared the variable and o set is its memory location relative to arp. This pair is the variable’s static distance coordinate. The translation is typically done during parsing, using a lexically-scoped symbol table, described in Section 6.7.3. The static distance coordinate encodes all the information needed by the code generator to emit code that locates the value at run time. The code generator must establish a mechanism for finding the appropriate ar given level. It then emits code to load the value found at o set inside that ar. Section 7.5.2 describes two di erent run-time data structures that can accomplish this task.

Digression: Call-by-Name Parameter Binding

Algol introduced the notion of call-by-name parameter binding. Call-by- name has a simple meaning. A reference to the formal parameter behaves exactly as if the actual parameter had been textually substituted in place of the formal. This can lead to some complex and interesting behavior. Consider the following short example in Algol-60:

begin comment Call-by-Name example;

procedure zero(Arr,i,j,u1,u2); integer Arr;

integer i,j,u1,u2; begin;

for i := 1 step 1 until u1 do for j := 1 step 1 until u2 do

Arr := 0; end;

integer array Work[1:100,1:200]; integer p, q, x, y, z;

x := 100; y := 200;

zero(Work[p,q],p,q,x,y); end

The procedure zero assigns the value 0 to every element of the array Work. To see this, rewrite zero with the text of the actual parameters.

This elegant idea fell from use because it was di cult to implement. In general, each parameter must be compiled into a small function of the formal parameters that returns a pointer. These functions are called thunks. Generating competent thunks was complex; evaluating thunks for each access to a parameter raised the cost of parameter access. In the end, these disadvantages overcame any extra generality or transparency that the simple rewriting semantics o ered.

In a language that uses call-by-reference parameter passing, the calling procedure creates a location for a pointer to the formal parameter and fills that location with a pointer to the result of evaluating the expression. Inside the called procedure, references to the formal parameter involve an extra level of indirection to reach the value. This has two critical consequences. First, any redefinition of the call-by-reference formal parameter is reflected in the actual parameter, unless the actual parameter is an expression rather than a variable reference. Second, any call-by-reference formal parameter might be bound to a variable that is accessible by another name inside the called procedure.

The same example, rewritten in pl/i, produces di erent results because of

the call-by-reference parameter binding.

procedure fee(x,y) returns fixed binary;

c = fee(2,3);

declare x,y fixed binary;

a = 2;

begin;

b = 3;

x = 2 * x;

c = fee(a,b);

y = x + y;

a = 2;

return y;

b = 3;

end;

c = fee(a,a);

Pl/i’s call-by-reference parameter passing produces di erent results than the c code did.

Notice that the second call redefines both a and b; the behavior of call-by- reference is intended to communicate changes made in the called procedure back to the calling environment. The third call creates an alias between x and y in fee. The first statement redefines a to have the value 4. The next statement references the value of a twice, and adds the value of a to itself. This causes fee to return the value 8, rather than 6.

In both call-by-value and call-by-reference, the space requirements for representing parameters are small. Since the representation of each parameter must be copied into the ar of the called procedure on each call, this has an impact on the cost of the call. To pass a large object, most languages use call-by-reference for e ciency. For example, in c, the string representation passes a fixed-size pointer rather than the text. C programmers typically pass a pointer to the array rather than copying each element’s value on each call.

Some Fortran compilers have used an alternative binding mechanism known as call-by-value/result. The call operates as in call-by-value binding; on exit, values from the formal parameters are copied back to the actual parameters— except when the actual is an expression.

Call-by-value/result produces the same results as call-by-reference, unless the call site introduces an alias between two or more formal parameters. (See Chapter 13 for a deeper discussion of parameter-based aliasing.) The call- by-value/result binding scheme makes each reference in the called procedure cheaper, since it avoids the extra indirection. It adds the cost of copying values in and out of the called procedure on each call.

Our example, recoded in Fortran, looks like: