Activation Records

Copyright c 2000 by Antony L. Hosking. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and full citation on the rst page. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specic permission and/or fee. Request permission to publish from hosking@cs.purdue.edu. 1

The procedure abstraction

Separate compilation: allows us to build large programs keeps compile times reasonable requires independent procedures The linkage convention: a social contract machine dependent division of responsibility The linkage convention ensures that procedures inherit a valid run-time environment and that they restore one for their parents Linkages execute at run time Code to make the linkage is generated at compile time
2

The procedure abstraction

The essentials: on entry, establish ps environment at a call, preserve ps environment on exit, tear down ps environment in between, addressability and proper lifetimes
!                   

Each system has a standard linkage

3

  

Procedure linkages
higher addresses incoming arguments argument n . . . argument 2 argument 1 local variables previous frame

Assume that each procedure activation has an associated activation record or frame (at run time) Assumptions: RISC architecture can always expand an allocated block locals stored in frame

frame pointer

return address current frame temporaries saved registers argument m . . . argument 2 argument 1 next frame

stack pointer

outgoing arguments

lower addresses

Procedure linkages
The linkage divides responsibility between caller and callee
Call Caller pre-call 1. allocate basic frame 2. evaluate & store params. 3. store return address 4. jump to child Callee prologue 1. save registers, state 2. store FP (dynamic link) 3. set new FP 4. store static link 5. extend basic frame (for local data) 6. initialize locals 7. fall through to code epilogue 1. store return value 2. restore state 3. cut back to basic frame 4. restore parents FP 5. jump to return address

Return

post-call 1. copy return value 2. deallocate basic frame 3. restore parameters (if copy out)

At compile time, generate the code to do this At run time, that code manipulates the frame & data areas
5

Run-time storage organization

To maintain the illusion of procedures, the compiler can adopt some conventions to govern memory use: Code space xed size statically allocated (link time) Data space xed-sized data may be statically allocated variable-sized data must be dynamically allocated some data is dynamically allocated in code Control stack dynamic slice of activation tree return addresses may be implemented in hardware
6

Run-time storage organization

Typical memory layout
high address stack

free memory

heap static data code low address

The classical scheme allows both stack and heap maximal freedom code and static data may be separate or intermingled
7

Run-time storage organization

Where do local variables go? When can we allocate them on a stack? Key issue is lifetime of local names Downward exposure: called procedures may reference my variables dynamic scoping lexical scoping Upward exposure: can I return a reference to my variables? functions that return functions continuation-passing style With only downward exposure, the compiler can allocate the frames on the run-time call stack
8

Storage classes
Each variable must be assigned a storage class address) Static variables: addresses compiled into code (usually ) allocated at compile-time limited to xed size objects control access with naming scheme Global variables: almost identical to static variables layout may be important naming scheme ensures universal access Link editor must handle duplicate denitions
9

(base

(relocatable)

(exposed)

Storage classes (cont.)

Procedure local variables Put them on the stack if sizes are xed if lifetimes are limited if values are not preserved Dynamically allocated variables Must be treated differently call-by-reference, pointers, lead to non-local lifetimes (usually ) an explicit allocation explicit or implicit deallocation
10

Access to non-local data

How does the code nd non-local data at run-time? Real globals visible everywhere naming convention gives an address initialization requires cooperation Lexical nesting view variables as (level,offset) pairs chain of non-local access links more expensive to nd (at run-time) (compile-time)

11

Access to non-local data

Two important problems arise How do we map a name into a (level,offset) pair? Use a block-structured symbol table (remember last lecture?) look up a name, want its most recent declaration declaration may be at current level or any lower level Given a (level,offset) pair, whats the address? Two classic approaches access links (or static links) displays

12

Access to non-local data

To nd the value specied by (l, o) need current procedure level, k k = l local value k > l nd ls activation record k < l cannot occur (static links )

Maintaining access links:

calling level k + 1 procedure 1. pass my FP as access link 2. my backward chain will work for lower levels calling procedure at level l < k 1. nd link to level l 1 and pass it 2. its access link will work for lower levels
13

The display
To improve run-time access costs, use a display : table of access links for lower levels lookup is index from known offset takes slight amount of time at call a single display or one per frame for level k procedure, need k 1 slots Access with the display Assume a value described by (l, o): nd slot as display[l] add offset to pointer from slot (display[l][o]) Setting up the basic frame now includes display manipulation
14

Display management
Single global display: Key insight: overallocate the display by 1 slot On entry to a procedure at level l save the level l display value push FP into level l display slot On return restore the level l display value simple method

Quick, simple, and foolproof!

15

Display management
Individual frame-based displays: Call from level k to level l if l k copy l 1 display entries into childs frame if l > k (l = k + 1) copy k 1 entries into childs frame copy own FP into kth slot in childs frame No work required on return display is deallocated with frame Display accessed by offset from FP one less register required
16

Display versus access links

How to make the trade-off? The cost differences are somewhat subtle frequency of non-local access average lexical nesting depth ratio of calls to non-local access (Sort of ) Conventional wisdom tight on registers use access links lots of registers use global display shallow average nesting frame-based display Your mileage will vary Making the decision requires understanding reality
17

Parameter passing
What about parameters? Call-by-value store values, not addresses never restore on return arrays, structures, strings are a problem Call-by-reference pass address access to formal is indirect reference to actual Call-by-value-result store values, not addresses always restore on return arrays, structures, strings are a problem Call-by-name build and pass thunk access to parameter invokes thunk all parameters are same size in frame!
18

Parameter passing
What about variable length argument lists? 1. if caller knows that callee expects a variable number (a) caller can pass number as 0th parameter (b) callee can nd the number directly 2. if caller doesnt know anything about it (a) callee must be able to determine number (b) rst parameter must be closest to FP Consider printf : number of parameters determined by the format string it assumes the numbers match

19

Calls: Saving and restoring registers

callee saves caller saves callers registers 1 2 callees registers 3 4 all registers 5 6

1. Call includes bitmap of callers registers to save/restore (best with save/restore instructions to interpret bitmap) 2. Caller saves and restores its own registers Unstructured returns (e.g., non-local gotos, exceptions) create some problems, since code to restore must be located and executed 3. Backpatch code to save callees registers on entry, restore on exit e.g., VAX places bitmap in callees stack frame for use on call/return/non-local goto/exception Non-local gotos/exceptions unwind dynamic chain restoring callee-saved registers 4. Bitmap in callees stack frame is used by caller to save/restore (best with save/restore instructions to interpret bitmap) Unwind dynamic chain as for 3 5. Easy: Non-local gotos/exceptions restore all registers from outermost callee 6. Easy (use utility routine to keep calls compact) Non-local gotos/exceptions restore original registers from caller Top-left is best: saves fewer registers, compact calling sequences 20

MIPS procedure call convention

Registers:
Number 0 1 2, 3 47 815 1623 24, 25 26, 27 28 29 30 31 Name zero at v0, v1 a0a3 t0t7 s0s7 t8, t9 k0, k1 gp sp s8 (fp) ra Usage Constant 0 Reserved for assembler Expression evaluation, scalar function results rst 4 scalar arguments Temporaries, caller-saved; caller must save to preserve across calls Callee-saved; must be preserved across calls Temporaries, caller-saved; caller must save to preserve across calls Reserved for OS kernel Pointer to global area Stack pointer Callee-saved; must be preserved across calls Expression evaluation, pass return address in calls
21

MIPS procedure call convention

Philosophy: Use full, general calling sequence only when necessary; omit portions of it where possible (e.g., avoid using fp register whenever possible) Classify routines as: non-leaf routines: routines that call other routines leaf routines: routines that do not themselves call other routines leaf routines that require stack storage for locals leaf routines that do not require stack storage for locals
22

MIPS procedure call convention

The stack frame
high memory argument n argument 1 frame offset static link locals framesize saved $ra temporaries other saved registers argument build stack pointer ($sp) low memory

virtual frame pointer ($fp)

23

MIPS procedure call convention

Pre-call: 1. Pass arguments: use registers $a0 . . . $a3; remaining arguments are pushed on the stack along with save space for $a0 . . . $a3 2. Save caller-saved registers if necessary 3. Execute a jal instruction: jumps to target address (callees rst instruction), saves return address in register $ra

24

MIPS procedure call convention

Prologue: 1. Leaf procedures that use the stack and non-leaf procedures: (a) Allocate all stack space needed by routine: local variables saved registers sufcient space for arguments to routines called by this routine subu $sp,framesize (b) Save registers ($ra, etc.): sw $31,framesize+frameoffset($sp) sw $17,framesize+frameoffset-4($sp) sw $16,framesize+frameoffset-8($sp) where framesize and frameoffset (usually negative) are compile-time constants 2. Emit code for routine
25

MIPS procedure call convention

Epilogue: 1. Copy return values into result registers (if not already there) 2. Restore saved registers lw reg,framesize+frameoffset-N($sp) 3. Get return address lw $31,framesize+frameoffset($sp) 4. Clean up stack addu $sp,framesize 5. Return j $31
26