10/29/2008 Run-time storage layout Representation of int, bool, - PDF document

10/29/2008 Run-time storage layout • Representation of – int, bool, etc. – arrays, records, etc. The Backend (continued) – procedures • Placement of – global variables David Notkin – local variables Autumn 2008 – parameters – results CSE401 Au08 2 Storage allocation strategies Run-time memory • Given layout of data structure, where in memory to • Code/Read-only data area allocate space for each instance? stack – Shared across processes running same program • Key issue: what is the lifetime (dynamic extent) of a • Static data area variable/data structure? – Can start out initialized or – Whole execution of program (e.g., global zeroed variables) • Heap heap • Static allocation – Can expand upwards through – Execution of a procedure activation (e.g., locals) (e.g. sbrk) system call static data • Stack allocation • Stack – Variable (dynamically allocated data) – Expands/contracts code/RO data downwards automatically • Heap allocation CSE401 Au08 3 Static allocation Stack allocation • Statically allocate variables/data structures with • Stack-allocate variables/data structures with LIFO global lifetime lifetime – Machine code – Data doesn’t outlive previously allocated data on the same stack – Compile-time constant scalars, strings, arrays, etc. • Stack-allocate procedure activation records – Global variables – Frame includes formals, locals, temps – static locals in C, all variables in FORTRAN – And housekeeping: static link, dynamic link, … • Compiler uses symbolic addresses • Fast to allocate and de-allocate storage • Linker assigns exact address, patches compiled code • Good memory locality 1

10/29/2008 Stack allocation II Stack allocation: constraints I proc foo(x:int): • What about procedure P() { • No references to stack- proctype(int):int; int x; allocated data allowed variables local to proc bar(y:int):int; for(int i=0; i<10; i++){ after returns begin nested scopes return x + y; double x; • This is violated by within one end bar; … general first-class begin procedure? } return bar; functions for(int j=0; j<10; j++){ end foo; double y; var f:proctype(int):int; … var g:proctype(int):int; } f := foo(3); } g := foo(4); output := f(5); output := g(6); Stack allocation: constraints II Heap allocation • Also violated if proc foo (x:int): *int; • For data with unknown lifetime var y:int; – new/malloc to allocate space pointers to locals begin y := x * 2; – delete/free or garbage collection to de-allocate are allowed return &y; • Heap-allocate activation records of first-class end foo; functions var w,z:*int; • Relatively expensive to manage • Can have dangling reference, storage leaks z := foo(3); – Garbage collection reduces (but may not w := foo(4); eliminate) these classes of errors output := *z; output := *w; Stack frame layout Key property • Formals, locals, housekeeping • All data in stack frame is at a fixed, statically computed offset from the FP – Dynamic and static link • This makes it easy to generate fast code to access – Saved registers, … the data in the stack frame • Dedicate registers to support stack access – And lexically enclosing stack frames – FP - frame pointer: ptr to start of stack frame • Can compute these offsets solely from the symbol (fixed) tables – SP - stack pointer: ptr to end of stack (can move) – Based also on the chosen layout approach 2

10/29/2008 Stack Layout Accessing locals high ...caller's frame... addresses formal N • If a local is in the same stack frame then formal N-1 – t := *(fp + local_offset) ... • If in lexically-enclosing stack frame formal 1 – t := *(fp + static_link_offset) one stack frame static link t := *(t + local_offset) return address • If in a further enclosing block dynamic link stack – t := *(fp + static_link_offset) grows saved registers down t := *(t + static_link_offset) local N … local N-1 t := *(t + local_offset) ... low FP addresses local 1 At compile-time need to calculate Calling conventions • Difference in nesting depth of use and definition • Define responsibilities of caller and callee • Offset of local in defining stack frame – To make sure the stack frame is properly set up and torn down • Offsets of static links in intervening frames • Some things can only be done by the caller • Other things can only be done by the callee • Some can be done by either • So, we need a protocol Typical calling sequence Typical return sequence Callee Caller Caller Callee • • • Deallocate space for • Deallocate space for Evaluate actual args Save bookkeeping information – Order? on stack callee’s static link, args local, other data • • Push onto stack Allocates space for locals, – sp := sp + – sp := fp other data – Order? size_of_locals + • Continue execution in – sp := sp - – Alternative: First k args in other_data caller after call size_of_locals - registers • Restore caller’s frame other_data • Push callee's static link pointer, return address & – Locals stored in what order? – Or in register? Before or after • other regs, all without Set up new frame pointer stack arguments? ( fp := sp ) • losing addresses of stuff Execute call instruction • Start executing callee’s code still needed in stack – Hardware puts return address in a register • Execute return instruction 3