Function Compiler Baojian Hua bjhuaustc edu cn Function

Function Compiler Baojian Hua bjhua@ustc. edu. cn

Function, or Procedure, or method, or … n High-level abstraction of code n n Good for many things: n n logically-grouped design and abstraction develop, testing, maintain and evolve … Implementation? n we start with C-style functions, and deal with more advanced forms later

API & ABI n Application Programming Interface n n interfaces between source programs Application Binary Interface n n interfaces between binary programs conventions on low-level details: n n n how to pass arguments? how to return values? how to make use of registers? … we posted the x 86 ABI document on course page

Address Space n Address space is the way how programs use memory n n highly architecture and OS dependent right is the typical layout of 32 -bit x 86/Linux OS 0 xffff 0 xc 0000 stack heap data text BIOS, VGA 0 x 08048000 0 x 00100000 0 x 0000

Stack n n n Two dedicated regs Stack grows down to lower address Frame also called activation record high address frame 0 frame 1 %ebp frame 2 %esp low address

Stack Frame int f (int arg 0, int arg 1, …) { int local 1; int local 2; …; } … arg 1 arg 0 ret addr old ebp %ebp local 1 local 2 %esp …

Register usage n ABI also specifies the caller-save and calleesave registers n caller-save: Callee is free to destroy these registers n n n eax, ecx, edx, eflags, fflags [and also all FP registers] callee-save: Callee must restore these registers before returning to caller n n ebp, esp, ebx, esi, edi [and also FP register stack top]

Put these together // C code int main(void) { return f(8)+1; } int f(int x) { return g(x); } int g(int x) { return x+3; } // x 86 code main: push ebp mov ebp, esp push 8 call f inc eax leave ret

Put these together // C code int main(void) { return f(8)+1; } int f(int x) { return g(x); } int g(int x) { return x+3; } // x 86 code f: push ebp mov ebp, esp push [ebp+8] call g leave ret

Put these together // C code int main(void) { return f(8)+1; } int f(int x) { return g(x); } int g(int x) { return x+3; } // x 86 code g: push ebp mov ebp, esp mov add leave ret eax, [ebp+8] eax, 3

Register usage n Should value reside in caller-save or calleesave registers? n not so easy to determine and no general rules must be veryyyyy careful with language features such as longjmp, goto or exceptions n n we’d come back to this later We’d also come back to this issue later in register allocation part

Escape variables n A variable is said to be escape if: n n & operator accessed in inner functions call-by-reference Escape variables should be put in memory, not in register n n better in heap see the next example

Escape variables // C code int *f () { int x; return &x; } // gcc happily accepts // this, and outputs: f: push ebp mov ebp, esp leave ret // : -( eax, [ebp-4]

Implementation n Design a frame (activation record) data structure n n n the frame size detailed layout, etc. Thus, hide the machine-related details n good to retarget the compiler

Interface signature FRAME = sig type t (* allocate space for a variable in frame *) val alloc. Var: unit -> unit val new: unit -> t (* current size of the frame *) val size: unit -> int end

Parameter Passing

Parameter passing n C uses a strategy called call-by-value n n n caller copies arguments to callee is free to modify these copies Other strategies: n n call-by-reference call-by-name call-by-need …

Call-by-reference n In languages such as C++ n arguments are escape n n so can not be constants? actual arguments and formal parameters are aliases // C++ style reference: int f (int &x, int y) { x = 3; y = 4; return 0; } // a call f (a, b);

Simulating call-by-reference // original C++ code: int f (int &x, int y) { x = 3; y = 4; return 0; } // simulated: int f (int *x, int y) { *x = 3; y = 4; return 0; } // a call f (a, b); // the call becomes: f (&a, b);

Moral n Call-by-reference is widely considered a wrong design of C++ n n the code is inherently inefficient! simply, the code is ambiguous n n x = 4; (? ) A direct modification is the so-called call -by-value/result n looks like call-by-value, but with effect

Call-by-value/result n n Upon call, the actual arguments is copies But callee only modifies a local version Upon exit, callee copies the local version to actual arguments and formal parameters are aliases // code: int f (int @x, int y) { x = 3; y = 4; return 0; } // a call f (a, b);

Simulating call-by-value/result // original code: int f (int @x, int y) { x = 3; y = 4; return 0; } // a call f (a, b); // simulated: int f (int *x, int y) { int temp = *x; temp = 3; y = 4; *x = temp; return 0; } // the call becomes: f (&a, b);

Moral n n n What’s the difference between call-byvalue and call-by-value-result? Is call-by-value/result more efficient than call-by-reference? Why or why not? We’d come back to a more interesting optimization called register promotion n same idea to pull value into registers

Call-by-name n n n Some languages, such as Algo 60 and Haskell, use call-byname Arguments are not evaluated, until they are really needed in the callee For each argument, create a function, called a thunk // code: int f (int name x, int y) { if (y) return x; else return 0; } // a call f (a, b);

Simulating call-by-name // original code: int f (int name x, int y) { if (y) return x; else return 0; } // a call f (a, b); // simulated: int f (f. X: unit -> int, int y) { if (y) return f. X (); else return 0; } // the call becomes: f (fn () => a, b); this function is not closed!

Moral n n n A serious problem with call-by-name, is that the arguments may be evaluated many times A better solution is to memoize the evaluation result This method is called call-by-need, or sometimes lazy-evaluation

Simulating call-by-need // original code: int f (int need x, int y) { if (y) return x + x; else return 0; } // a call f (a, b); // simulated: int f (f. X: unit -> int, int y) { if (y) return f. X() + f. X(); else return 0; } // the call becomes: val x. Memoize = ref NONE f (fn () => case !x. Memoize of NONE => a; store | SOME i => i, b);

Nested Function

Nested Functions n Functions declared in the body of another function n n So the inner one could refer to the variables in the outer ones such kind of functions are called open int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; }

Nested Functions n n How to access variables in outer functions? Three classical methods: n n n lambda lifting static link display int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; }

Nested Functions n n How to access variables in outer functions? Three classical methods: n n n lambda lifting static link display int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; }

Lambda lifting n n In lambda lifting, the program is translated into a form such that all procedures are closed The translation process starts with the inner-most procedures and works its way outwards

Lambda lifting example int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; } int f (int x, int y) { int m; int g (int z) { int h (int &m, &z) { return m+z; } return 1; } return 0; }

Lambda lifting example int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; } int f (int x, int y) { int m; int g (int &m, int z) { int h (int &m, &z) { return m+z; } return 1; } return 0;

Lambda lifting example int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; } int f (int x, int y) { int m; return 0; } int g (int &m, int z) { return 1; } int h (int &m, &z) { return m+z; }

Moral n Pros: n easy to implement, source-to-source translations n n even before code generation Cons: n n variables are all escape extra arguments passing n on some architectures, more arguments are passed in memory, so it’s inefficient

Static links n n n An alternative approach is to add an additional piece of information to the activation records, called the static link The static link is a pointer to the activation record of the enclosing procedure Used in the Borland Turbo Pascal compiler

Static links example int f (int x, int y) { int m; int g (int z) { int h () { return m+z; } return 1; } return 0; } int f (link, int x, int y) { int m; int g (link, int z){ int h (link){ return link-> prev->m+ link->z; } return 1; } return 0; }

Pros and cons n Pros: n Little extra overhead on parameter passing n n the static link Cons: n Still there is the overhead to climb up a static link chain to access non-locals

Implementation details n n First, each function is annotated with its enclosing depth, hence its variables When a function at depth n accesses a variable at depth m n emit code to climb up n-m links to visit the appropriate activation record

Implementation details n When a procedure p at depth n calls a procedure q at depth m: n if n<m (ie, q is nested within p): n note: in first-order languages, n=m-1 q’s static link = q’s dynamic link if n m: n n q’s prelude must follow m-n static links, starting from the caller’s (p’s) static link the result is the static link for q

Moral n In theory, static links don’t seem very good n n n functions may be deeply nested However, real programs access mainly local/global variables, or occasionally variables just one or several static links away Still, experimentation shows that static links are inferior to the lambda-lifting approach n Personally, I believe static links are infeasible to optimizations

Display n n The 3 rd way to handle nest functions is to use a display A display is a small stack of pointers to activation records The display keeps track of the lexical nesting structure of the program Essentially, it points to the currently set of activation records that contain accessible variables

Higher-order functions n Functions may serve more than just being called n n n can be passed as arguments can return as results can be stored in data structures n n objects! we’d discuss later If functions don’t nest, then the implementation is simple n n a simple code address e. g. , the “function pointer” in C

Higher-order functions n But if functions do nest, it’s a little tricky to compile: n n n as found in Lisp, ML, Scheme even in recent version of C# and Java Next time, we’d cover more advanced techniques to handle this