Static allocation can become stack allocation by using relative addresses for storage in activation records. The position of the record for an activation of a procedure is not known until run time. In stack allocation, this position is usually stored in a register, so words in the activation record can be accessed as offsets from the value in this register. The indexed address mode of our target machine is convenient for this purpose.
Relative addresses in an activation record can be taken as offsets from any known position in the activation record. For convenience, we shall use positive offsets by maintaining in a register SP a pointer to the beginning of the activation record on top of the stack. When a procedure call occurs, the calling procedure increments SP and transfers control to the called procedure. After control returns to the caller, it decrements SP, thereby de-allocating the activation record of the called procedure.
The code for the 1st procedure initializes the stack by setting SP to the start of the stack area in memory.
MOV #stackstart, SP /*initialize the stack*/
code for the first procedure
HALT /*terminate execution*/
A procedure call sequence increments SP, saves the return address, and transfers control to the called procedure:
ADD #caller.recordsize, SP
MOV #here+16, SP /* save return address*/
GOTO callee.code_area
The attribute caller.recordsize represents the size of an activation record, so the ADD instruction leaves SP pointing to the beginning of the next activation record. The source #here+16 in the MOV instruction is the address of the instruction following the GOTO; it is saved in the address pointed to by SP.
The return sequence consists of two parts. The called procedure transfers control to the return address using
GOTO *0(SP) /*return to caller*/
The reason for using *0(SP) in the GOTO instruction is that we need two levels of indirection: 0(SP) is the address of the first word in the activation record and *0(SP) is the return address saved there.
The second part of the return sequence is in the caller, which decrements SP, thereby restoring SP to its previous value. That is, after the subtraction SP points to the beginning of the activation record of the caller:
SUB #caller.recordsize, SP
Example 2
The program in fig .6 is a condensation of the three-address code for the Pascal program for reading and sorting integers. Procedure q is recursive, so more than one activation of q can be alive at the same time.
|
*code for s*/
action1
call q
action2
halt
|
|
/*code for p*/
action3
return
|
|
/*code for q*/
action4
call p
action5
call q
action6
call q
return
|
fig.6 Three-address code to illustrate stack allocation
Suppose that the sizes of the activation records for procedures s, p, and q have been determined at compile time to be ssize, psize, and qsize, respectively. The first word in each activation record will hold a return address. We arbitrarily assume that the code for these procedures starts at addresses 100,200 and 300 respectively, and that the stack starts at 600. The target code for the program in
fig. 6 is as follows:
/*code for s*/
100: MOV #600, SP /*initialize the stack*/
108: ACTION1
128: ADD #ssize, SP /*call sequence begins*/
136: MOV #152, *SP /*push return address*/
144: GOTO 300 /*call q*/
152: SUB #ssize, SP /*restore SP*/
160: ACTION2
180: HALT
���
/*code for p*/
200: ACTION3
220: GOTO *0(SP) /*return*/
���
/*code for q*/
300: ACTION4 /*conditional jump to 456*/
320: ADD #qsize, SP
328: MOV #344, *SP /*push return address*/
336: GOTO 200 /*call p*/
344: SUB #qsize, SP
352: ACTION5
372: ADD #qsize, SP
380: MOV #396, *SP /*push return address*/
388: GOTO 300 /*call q*/
396: SUB #qsize, SP
404: ACTION6
424: ADD #qsize, SP
432: MOV #448, *SP /*push return address*/
440: GOTO 300 /*call q*/
448: SUB #qsize, SP
456: GOTO *0(SP) /*return*/
���
600: /*stack starts here*/
We assume that ACTION4 contains a conditional jump to the address 456of the return sequence from q; otherwise, the recursive procedure q is condemned to call itself forever. In an example below, we consider an execution of the program in which the first call of q does not return immediately, but all subsequent calls do.
If ssize, psize, and qsize are 20,40, and 60, respectively, then SP is initialized to 600, the starting address of the stack, by the first instruction at address 100. SP holds 620 just before control transfers from s to q, because ssize is 20. Subsequently, when q calls p, the instruction at address 320 increments SP to 680, where the activation record for p begins; SP reverts to 620 after control returns to q. If the next two recursive calls of q return immediately, the maximum value of SP during this execution is 680. However, the last stack location used is 739, since the activation record for q starting at location 680 extends for 60 bytes.
RUN-TIME ADDRESSES FOR NAMES
The storage allocation strategy and the layout of local data in an activation record for a procedure determine how the storage for names is accessed.
If we assume that a name in a three-address statement is really a pointer to a symbol-table entry for the name; it makes the compiler more portable, since the front end need not be changed even if the compiler is moved to a different machine where a different run-time organization is needed. On the other hand, generating the specific sequence of access steps while generating intermediate code can be of significant advantage in an optimizing compiler, since it lets the optimizer take advantage of details it would not even see in the simple three-address statement.
In either case, names must eventually be replaced by code to access storage locations. We thus consider some elaborations of the simple three-address statement x := 0. After the declarations in a procedure are processed, suppose the symbol-table entry for x contains a relative address 12 for x. First consider the case in which x is in a statically allocated area beginning at address static. Then the actual run-time address for x is static+12. Although, the compiler can eventually determine the value of static+12 at compile time, the position of the static area may not be known when intermediate code to access the name is generated. In that case, it makes sense to generate three-address code to �compute� static+12, with the understanding that this computation will be carried out during the code-generation phase, or possibly by the loader, before the program runs. The assignment x := 0 then translates into
static[12] := 0
If the static area starts at address 100, the target code for this statement is
MOV #0, 112
On the other hand, suppose our language is one like Pascal and that a display is used to access non-local names. Suppose also that the display is kept in registers, and that x is local to an active procedure whose display pointer is in register R3. Then we may translate the copy x := 0 into the three-address statements
t1 := 12+R3
*t1 := 0
in which t1 contains the address of x. This sequence can be implemented by the single machine instruction
MOV #0, 12 (R3)
The value in R3 cannot be determined at compile time.
