Code Generation & Parameter Passing

Code Generation & Parameter Passing Lecture Outline 1. Allocating temporaries in the activation record Let s optimie our code generator a bit 2. A deeper look into calling sequences Caller/Callee responsibilities. Parameter passing mechanisms call-b-value, call-b-reference, call-b-value-result, call-b-name and call-b-need Compiler Design I (211) 2 Etra Material in the Appendi (not covered in lecture) 4. Code generation for OO languages Object memor laout Dnamic dispatch 5. Code generation of data structure references Address calculations Arra references 6. Code generation for logical epressions Short-circuiting An Optimiation: Temporaries in the Activation Record Topic 1 Compiler Design I (211)

Revie The stack machine has activation records and intermediate results interleaved on the stack The code generator must assign a location in the AR for each temporar Revie (Cont.) Advantage: Simple code generation Disadvantage: Slo code Storing/loading temporaries requires a store/load and $sp adjustment AR Temporaries AR Temporaries These get put here hen e evaluate compound epressions like e 1 + e 2 (need to store e 1 hile evaluating e 2 ) cgen(e 1 + e 2 ) = cgen(e 1 ) ; eval e 1 s $a ($sp) ; save its value addiu $sp $sp-4 ; adjust $sp (!) cgen(e 2 ) ; eval e 2 l $t1 4($sp) ; get e 1 add $a $t1 $a ; $a = e 1 + e 2 addiu $sp $sp-4 ; adjust $sp (!) Compiler Design I (211) 5 Compiler Design I (211) 6 An Optimiation Improved Code Idea: Predict ho $sp ill move at run time Do this prediction at compile time Move $sp to its limit, at the beginning The code generator must staticall assign a location in the AR for each temporar Old method cgen(e 1 + e 2 ) = cgen(e 1 ) s $a ($sp) addiu $sp $sp-4 cgen(e 2 ) l $t1 4($sp) add $a $t1 $a addiu $sp $sp-4 Ne idea cgen(e 1 + e 2 ) = cgen(e 1 ) s $a?($fp) staticall allocate cgen(e 2 ) l $t1?($fp) add $a $t1 $a Compiler Design I (211) 7 Compiler Design I (211) 8

Eample add(,,,) begin + ( + ( + ( + 42))) end What intermediate values are placed on the stack? Ho man slots are needed in the AR to hold these values? Ho Man Stack Slots? Let NS(e) = # of slots needed to evaluate e Includes slots for arguments to functions E.g: NS(e 1 + e 2 ) Needs at least as man slots as NS(e 1 ) Needs at least one slot to hold e 1, plus as man slots as NS(e 2 ), i.e. 1 + NS(e 2 ) Space used for temporaries in e 1 can be reused for temporaries in e 2 Compiler Design I (211) 9 Compiler Design I (211) 1 The Equations for Mini Bar NS(e 1 + e 2 ) = ma(ns(e 1 ), 1 + NS(e 2 )) NS(e 1 -e 2 ) = ma(ns(e 1 ), 1 + NS(e 2 )) NS(if e 1 = e 2 then e else e 4 ) = ma(ns(e 1 ), 1 + NS(e 2 ), NS(e ), NS(e 4 )) NS(f(e 1,,e n )) = ma(ns(e 1 ), 1 + NS(e 2 ), 2 + NS(e ),, (n-1) + NS(e n ), n) NS(int) = NS(id) = Rule for f(e 1,, e n ): Each time e evaluate an argument, e put it on the stack. The Revised Activation Record For a function definition f( 1,, n ) begin e end the AR has 2 + NS(e) elements Return address Frame pointer NS(e) locations for intermediate results Note that f s arguments are no considered to be part of its caller s AR Compiler Design I (211) 11 Compiler Design I (211) 12

Picture: Activation Record Revised Code Generation popped b callee FP FP 4 increasing values of addresses n... 1 Old FP Return Addr. Temp NS(e)... Temp 1 direction of stack groth pushed b caller saved b callee (this diagram disagrees slightl ith lecture 12: here, the callee saves FP) Code generation must kno ho man slots are in use at each point Add a ne argument to code generation: the position of the net available slot Compiler Design I (211) 1 Compiler Design I (211) 14 Improved Code Notes Old method cgen(e 1 + e 2 ) = cgen(e 1 ) s $a ($sp) addiu $sp $sp -4 cgen(e 2 ) l $t1 4($sp) add $a $t1 $a addiu $sp $sp 4 Ne method cgen(e 1 + e 2, ns) = cgen(e 1, ns) s $a ns($fp) static allocation cgen(e 2, ns+4) l $t1 ns($fp) add $a $t1 $a compile-time prediction The slots for temporar values are still used like a stack, but e predict usage at compile time This saves us from doing that ork at run time Allocate all needed slots at start of a function Eerc. Write some code hich runs sloer after performing the optimiation just presented Hint: Think about memor usage (& caches, etc.) Compiler Design I (211) 15 Compiler Design I (211) 16

Handling Procedure Calls and Returns A Deeper Look into Calling Sequences Topic 2 Calling sequence: a code sequence that sets up a procedure call allocates an activation record (model-dependent) loads actual parameters saves machine state (return address, etc.) transfers control to callee Return sequence: a code sequence that handles the return from a procedure call deallocates the activation record sets up return value (if an) restores machine state (stack pointer, PC, etc.) Compiler Design I (211) 18 Calling Sequences: Division of Responsibilities The code in a calling sequence is often divided up beteen the caller and the callee Calling sequence code caller callee If there are m calls to a procedure, the instructions in the caller s part of the calling sequence is repeated m times, hile the callee s part is repeated eactl once This suggests that e should tr to put as much of the calling sequence as possible in the callee Hoever, it ma be possible to carr out more callspecific optimiation b putting more of the code into the caller instead of the callee Calling Sequences: Laout Issues General rule of thumb: Fields that are fied earl, are placed near the middle of the activation record The caller has to evaluate the actual parameters, and retrieve the return value these fields should be located near the caller s activation record The callee has to fill in machine status fields so that the callee can restore state on return the caller should have eas access to this part of the callee s activation record Compiler Design I (211) 19 Compiler Design I (211) 2

Calling/Return Sequences: Tpical Actions Eample Activation Record: The SPARC Tpical calling sequence: 1. caller evaluates actuals; pushes them on the stack 2. caller saves machine status on the stack (in the callee s AR) and updates the stack pointer. caller transfers control to the callee 4. callee saves registers, initialies local data, and begins eecution Tpical return sequence: 1. callee stores return value in the appropriate place 2. callee restores registers and old stack pointer. callee branches to the return address Registers g-g7 global registers o-o7 outgoing args l-l7 local registers i-i7 incoming args function return address caller s o7/callee s i7 high addresses current fp caller s sp stack groth current sp callee s fp lo addresses caller s frame locals and temporaries outgoing args not in o-o5 space to save o-5 if necessar addr of return value space to save i-i7 and l-l7 if necessar callee s frame varies varies 6 ords 1 ord 16 ords Compiler Design I (211) 21 Compiler Design I (211) 22 Eample Activation Record: Intel 86 Eample Activation Record: MIPS R high addresses caller s frame incoming arguments high addresses caller s frame incoming arguments frame ptr ebp return address saved registers saved ebp stack groth locals and temporaries callee-save registers stack groth stack ptr locals and temporaries stack ptr outgoing arguments esp callee s frame $sp callee s frame lo addresses lo addresses Compiler Design I (211) 2 Compiler Design I (211) 24

Parameter Passing Mechanisms Parameter Passing Mechanisms There are man semantic issues in programming languages centering on hen values are computed, and the scopes of names Evaluation is the heart of computation Names are most primitive abstraction mechanism Topic We ill focus on parameter passing When are arguments of function calls evaluated? What are formal parameters bound to? Compiler Design I (211) 26 Parameter Passing Mechanisms (Cont.) First, an issue not discussed much Order of argument evaluation - Usuall not important for the eecution of a program Hoever, in languages that permit side-effects in call arguments, different evaluation orders ma give different results e.g. a call f(++,) in C A standard evaluation order is then specified C compilers tpicall evaluate their arguments right-to-left. Wh? Compiler Design I (211) 27 Call-b-value C uses call-b-value everhere (ecept macros...) Default mechanism in Pascal and in Ada callbvalue(int ) = + 1; print(); main() int = 42; callbvalue(); output: = 42 = 4 = 42 s value does not change hen s value is changed Compiler Design I (211) 28

Call-b-reference Call-b-reference can be faked ith pointers Available in C++ ith the & tpe constructor (and in Pascal ith the var keord) callbref(int &) = + 1; print(); main() int = 42; callbref(); output: = 42 = 4 = 4 s value changes hen s value is changed C++: C: callbref(int &) = + 1; print(); main() int = 42; callbref(); fakecallbref(int *) * = * + 1; print(*); must eplicitl pass the address of a local variable main() int = 42; fakecallbref(&); Compiler Design I (211) 29 Compiler Design I (211) Pointers to fake call-b-reference (cont.) It s not quite the same A pointer can be reassigned to point at something else; a C++ reference cannot The pointer itself as passed b value This is ho ou pass arras (the are implicitl pointers) and structures in C Call-b-value-result Available in Ada for in out parameters (code belo in C snta) callbvalueresult(int, int ) = + 1; = + 1; print(); print(); main() int = 42; callbvalueresult(, ); output: = 42 = 4 = 4 = 4 Note that s value is different from both using call-b-value and call-b-reference Compiler Design I (211) 1 Compiler Design I (211) 2

What about Java? Primitive tpes (int, boolean, etc.) are alas passed b value Objects are not quite -b-value nor -b-reference: If ou reassign an object reference, the caller s argument does not get reassigned (like -b-value) But if the object referred-to is modified, that modification is visible to the caller (like -breference) It s reall ordinar call-b-value ith pointers, but the pointers are not sntacticall obvious Compiler Design I (211) Implementing Parameter Passing Call-b b-value value (eas, no special compiler effort) The arguments are evaluated at the time of the call and the value parameters are copied and either behave as constant values during the eecution of the procedure (i.e., cannot be assigned to as in Ada), or are vieed as initialied local variables (in C or in Pascal) Call-b b-reference The arguments must have allocated memor locations The compiler passes the address of the variable, and the parameter becomes an alias for the argument Local accesses to the parameter are turned into indirect accesses Compiler Design I (211) 4 Implementing Parameter Passing (Cont.) Call-b b-value-result The arguments are evaluated at call time and the value parameters are copied (as in call-b-value) and used as a local variables The final values of these variables are copied back to the location of the arguments hen the procedure eits (note that the activation record cannot be freed b the callee!) Issues left unspecified: the order in hich the results are copied back hether the locations of the arguments are calculated onl on entr and stored, or hether the are recalculated on eit Compiler Design I (211) 5 Call-b-name Whole different ballgame: it s like passing the tet of the argument epression, unevaluated The tet of the argument is vieed as a function in its on right Also passes the environment, so free variables are still bound according to rules of static scoping The argument is not evaluated until it is actuall used, inside the callee Might not get evaluated at all! An optimied version of call-b-name is used in some functional languages (e.g. Haskell, Miranda, La-ML) under the names la evaluation (or call-b-need) Compiler Design I (211) 6

Call-b-name eample (in C++-Etra ) code + environment (env has just here) callbname(int closure ) eval print(); print(); // => print( = +1) both evals main() have side effects int = 42; callbname( [[ = +1 ]] ); closure output: = 42 = 4 = 44 = 44 s value changes hen is evaluated Code Generation for OO Languages Topic 4 (probabl not covered in lecture) Compiler Design I (211) 7 Object Laout Object-Oriented (OO) code generation and memor laout OO Slogan: If C (child) is a subclass of P (parent), then an instance of class C can be used herever an instance of class P is epected To Issues Ho are objects represented in memor? Ho is dnamic dispatch implemented? This means that P s methods should ork ith an instance of class C Compiler Design I (211) 9 Compiler Design I (211) 4

Object Representation Subclass Representation class P : Int <- ; : String <- "Hi"; : Int ; : Bool <- true; : String ; ; Wh method pointers? Wh the tag? self 1 2 4 5 tag: P dnamic dispatch case Hi P.f: return self [1] true P.g: return self [2] self To call f: l $t1 12($s) jalr $t1 class P.. (same).. ; self class C inherits P : Int <- 42; // ne P : Int ; // override h( ) : Bool ; // ne ; C Idea: Append ne fields 1 2 4 5 6 7 h( ) Hi overridden C.f: return self [6] true P.g: return self [2] 42 To call f: l $t1 12($s) jalr $t1 C.h: return self [4] inherited Compiler Design I (211) 41 Compiler Design I (211) 42 Subclasses (Cont.) The offset for an attribute is the same in a class and all of its subclasses An method for an A 1 can be used on a subclass A 2 Consider laout for A n < < A < A 2 < A 1 Header A 1 attrs A 2 attrs A attrs... A 1 object A 2 object A object What about multiple inheritance? What s the point? Simple Just append subclass fields Efficient Code can ignore dnamic tpe -- just act as if it is the static tpe Supports overriding of methods Just replace the appropriate dispatch pointers We implement tpe conformance (compile-time concept) ith representation conformance (run-time concept) Compiler Design I (211) 4 Compiler Design I (211) 44

An optimiation: Dispatch Tables Observation Consider instances of class C: C.f: return self [6] Ever instance of a given class has the same values for all of its method pointers h( ) h( ) h( ) Space optimiation: Put all method pointers for a given class into a common table, called the dispatch table Each instance has a pointer to the dispatch table C.h: return self [4] P.g: return self [2] Compiler Design I (211) 45 Compiler Design I (211) 46 Picture ith Dispatch Table Subclassing Again Consider again instances of C: 1 2 4 5 dispptr Objects are smaller Dispatch is sloer dispptr dispptr C.f: return self [5] P.g: return self [] h( ) C.h: return self [4] minor point: the offsets have changed since e removed the method ptrs P.f: return self [2] call f: l $t1 4($s) l $t1 ($t1) jalr $t1 1 2 4 1 tag: P dispptr dispptr P.g: return self [] 1 2 4 5 C.f: return self [5] h( ) C.h: return self [4] Compiler Design I (211) 47 Compiler Design I (211) 48

Real Object Laout Actuall, the first ords of objects contain header information: Needed for garbage collector Class Tag Object Sie Dispatch Ptr Attribute 1 Attribute 2... Offset (in btes) 4 8 12 16 Summar of Dispatch Tables Pulled method pointers out, into separate table Makes objects smaller Makes (dnamic) dispatch sloer Q: Wh don t e do this for attributes? Eerc. Write some code that is sloer ith dispatch tables (instead of embedded method pointers) Eerc. Write some code that is faster ith dispatch tables Compiler Design I (211) 49 Compiler Design I (211) 5