1. COP4020 Programming Languages Subroutines and Parameter Passing Prof. Xin Yuan

2. COP4020 Spring 2014 2 6/1/2016 Today’s topics Implementing routine calls  Calling sequences Hardware/language support for efficient execution of subroutines

3. COP4020 Spring 2014 3 6/1/2016 Subroutine frame (Activation record) Activation record (subroutine frame) is used to store all related information for the execution of a subroutine Before a subroutine is executed, the frame must be set up and some fields in the frame must be initialized  Formal arguments must be replaced with actual arguments This is done in the calling sequence, a sequence of instructions before and after a subroutine, to set-up the frame. Temporary storage (e.g. for expression evaluation) Local variables Bookkeeping (e.g. saved CPU registers) Return address Subroutine arguments and returns

4. Stack layout With stack allocation, the subroutine frame for the current frame is on top of the stack  sp: top of the stack  fp: an address within the top frame To access non-local variables, static link (for static scoping) or dynamic link (dynamic scoping) are maintained in the frame COP4020 Spring 2014 4 6/1/2016

5. COP4020 Spring 2014 5 6/1/2016 Calling sequences Maintaining the subroutine call stack Calling sequences in general have three components  The code executed by the caller immediately before and after a subroutine call.  Prologue: code executed at the beginning of the subroutine  Epilogue: code executed at the end of the subroutine …. foo(100+I, 20+j) … Calling sequence code Call foo Calling sequence code Prologue code foo body Epilogue code

6. COP4020 Spring 2014 6 6/1/2016 Calling sequences What needs to be done in the calling sequence?  Before the subroutine code can be executed (caller code before the routing + prologue) – set up the subroutine frame Compute the parameters and pass the parameters Saving the return address Save registers Changing sp, fp (to add a frame for the subroutine) Changing pc (start running the subroutine code) Execute initialization code when needed Temporary storage (e.g. for expression evaluation) Local variables Bookkeeping (e.g. saved CPU registers) Return address Subroutine arguments and returns

7. COP4020 Spring 2014 7 6/1/2016 Calling sequences What needs to be done in the calling sequence?  After the subroutine code is executed (caller code after the routine + epilogue) – remove the subroutine frame Passing return result or function value Finalization code for local objects Deallocating the stack frame (restoring fp and sp to their previous value) Restoring saved registers and PC Some of the operations must be performed by the caller, others can either be done by the caller or callee. Temporary storage (e.g. for expression evaluation) Local variables Bookkeeping (e.g. saved CPU registers) Return address Subroutine arguments and returns

8. COP4020 Spring 2014 8 6/1/2016 Saving and restoring registers: the problem Some registers such as sp and fp are clearly different in and out of a subroutine. For general purpose registers used in caller and/or callee. main() foo() { … R1= 20 R1 = 10 } … call foo(); … R2 = R1 }  To execute correctly, R1 need to be saved before foo() and restored after.

9. COP4020 Spring 2014 9 6/1/2016 Saving and restoring registers: the solution Solution 1: Save/restore in the calling sequence at caller main() { … R1=10 … T1 = R1 call foo(); R1 = T1 … R2 = R1 } Solution 2: Save/restore in prologue and epilogue at callee foo() { T1 = R1 … R1=20 … R1 = T1 return } Calling sequence prologue epilogue

10. COP4020 Spring 2014 10 6/1/2016 Saving and restoring registers The compiler should generate code only to save and restore registers that matters  If a subroutine does not use R3, R3 does not need to be saved in the calling sequence. Ideally, we should only save registers that is used in the caller and the callee.  Difficult due to separate compilation: no information of callee when compiling caller, and vice versa. Simple solution (with unnecessary save/restore):  Option 1: caller saves/restores all registers it uses  Option 2: callee saves/restores all registers it uses Compromised solution:  partition registers into two sets, one for caller save one for callee save.

11. COP4020 Spring 2011 11 6/1/2016 A typical calling sequence Caller before the call: 1. saves any caller-saves registers whose values will be needed after the call. 2. Computes the values of arguments and moves them into the stack or registers 3. Computes the static link, and passes it as an extra hidden argument 4. Use a special subroutine call instruction to jump to the subroutine, simultaneously passing the return address on the stack or in a register Prologue in the callee: 1. Allocates a frame (sp = sp – offset) 2. Save old fp into the stack, update the fp 3. Save callee-saves registers that may be overwritten in the routine. Epilogue in the callee: 1. Moves the return value into a register or a location in the stack 2. Restores callee-saves registers 3. Restore fp and sp 4. Jump back to the return address

12. COP4020 Spring 2014 12 6/1/2016 A typical calling sequence Caller after the call: 1. Moves the return value to wherever it is needed 2. Restores caller-saves registers.

13. A question Why local variables typically do not have a default value (while globals do)? Int I main() { int j; cout << I << j; } COP4020 Spring 2014 13 6/1/2016

14. Hardware support for efficient subroutine execution Calling sequences are overheads to running subroutines. Register windows  Introduced in Berkeley RISC machines  Also used in Sun SPARC and Intel Itanium processors  Basic idea: Maintain multiple sets (a window) of registers Using a new mapping (set) of registers when making subroutine calls  Set and reset a mapping is cheaper than saving and restoring registers New and old mapping registers overlaps to allow parameter passing COP4020 Spring 2014 14 6/1/2016

15. Language support for efficient subroutine execution In-line functions Inline int max(int a, int b) {return a> b ? a: b;} How is it different from ordinary functions?  Such functions are not real functions, the routine body is expanded in-line at the point of call. A copy of the routine body becomes a part of the caller No actual routine call occurs. Will inline function always improve performance?  Maybe, maybe not Many other factors: e.g. code size affecting cache/memory behavior COP4020 Spring 2014 15 6/1/2016