Run time vs. Compile time

1. Run time vs. Compile time • The compiler must generate code to handle issues that arise at run time • Representation of various data types • Procedure linkage • Storage organization

2. Data representation • Fundamental types are supported directly by machine operations • Enumerated types? • Booleans? • Arrays? • Strings? • Records? • packed • unpacked

3. Control abstraction • A procedure is a control abstraction • it associates a name with a chunk of code • that piece of code is regarded in terms of its purpose and not of its implementation. • Big issue #1: Allow separate compilation • Without it we can't build large systems • Saves compile time • Saves development time • We must establish conventions on memory layout, calling sequences, procedure entries and exits, interfaces, etc.

4. Control abstraction • Procedures must have a well defined call mechanism • In Algol-like languages: • a call creates an instance (activation) of the procedure • on exit, control returns to the call site, to the point right after the call. • Use a call graph to see set of potential calls

5. Control abstraction • Generated code must be able to • preserve current state • save variables that cannot be saved in registers • save specific register values • establish procedure environment on entry • map actual to formal parameters • create storage for locals • restore previous state on exit • This can be modeled with a stack • Allocate a memory block for each activation • Maintain a stack of such blocks • This mechanism can handle recursion

6. Name space • A procedure creates its own name space • It can declare local variables • Local declarations may hide non-local ones • Local names cannot be seen from outside. • The scope of a variable is the area in which it is active • Scope rules determine how declarations are mapped to names.

7. Storage allocation • Static allocation • object is allocated address during compile time • location is retained during execution • Stack allocation • objects are allocated in LIFO order • Heap allocation • objects may be allocated and deallocated at any time.

8. Static allocation • Objects that are allocated statically include: • globals • explicitly declared static variables • instructions • string literals • compiler-generated tables used during run time.

9. Stack allocation • Follows stack model for procedure activation • A procedure's memory block associated with an activation of the procedure is called an activation record or stack frame • Local variables are stored in the stack frame • The stack frame is pushed on the stack when the procedure is called and popped (and destroyed) when the procedure terminates • What can we determine at compile time? • We cannot determine the address of the stack frame • But we can determine the size of the stack frame and the offsets of various objects within a frame

10. Heap allocation • Used for dynamically allocated/resized objects • Managed by special algorithms • General model • maintain list of free blocks • allocate block of appropriate size • handle fragmentation • handle garbage collection

11. Scope rules • Static scoping • determined at compile time • Algol languages: resolve conflicts by using "closest nested scope" rule • We must come up with a mechanism to access enclosing scopes (later)

12. Scope rules • Dynamic scoping • depends on flow of control at run time • resolve conflicts using "most recently executed" rule • type checking deferred until run time • complicates program • any advantages?

13. Scope rules • Dynamic scoping example run 1 : a is positive one() is called. The x in one() is bound to the most recent declaration which is the global one. The global x is given the value of 1 and the program prints 1 in the end. procedure main x, a: int; procedure one() begin x := 1; end procedure two() begin x:int; one(); end begin x := 2; read(a); if a>0 then one() else two(); print(x); end. run 2 : a is negative two() is called. It declares a local x. Then it calls one(). The x in one() is bound to the most recent declaration which is the local declaration in two(). That local x is given the value of 1. one() exits. two() exits and the local x dies. The global x is still 2. The program prints 2 in the end.

14. Scope rules • Dynamic scoping -- why bother? • It allows us to customize procedures. • Consider a procedure print_integer that can print its argument in base 8, 10 or 16. Furthermore, we usually want to print it in base 10. We can use a global variable (such as x in the example) which is set to 10. Then, if we want a different base, we can declare a local x, set it to 8 or 16, and call print_integer. Once we exit the current scope, the local x dies and we are back to the default value. • Is there another way to do this? • Yes, we could have passed x as a parameter • Yes, we could have made x a statically allocated variable (e.g. global), initialized it to 10 and, if necessary, reset its value right before and after a call to print_integer • bad idea: we might forget to restore it after the call.

15. Storage organization • Stack layout • each procedure is given a stack frame at the top of the stack • stack grows towards lower addresses • at any time the stack pointer points to the current top of the stack (first available location) • at any time, the frame pointer points to the beginning of the current frame • the stack frame size and the offsets are determined at compile time! • stack frame contents are accessed as offsets relative to the stack pointer or frame pointer • Do we need both?

16. Storage organization • Stack frames. What's in them? • arguments • return value • local variables • temporary values • stack pointer • frame pointer • return address • dynamic link? • static link? • etc.

17. The stack frame • Dynamic link = • a reference to the frame of the caller • needed to be able to restore the stack • can we use it to access non-locals? • Some languages allow nested procedures • In order to implement the "closest nested scope" rule we need access to the frame of the lexically enclosing procedure • Example: A() { B(); C(); } • C can call B, but B is lexically enclosed in A

18. Handling nested procedures • Method 1 : static (access) links • Reference to the frame of the lexically enclosing procedure • Static chains of such links are created. • How do we use them to access non-locals? • The compiler knows the scope s of a variable • The compiler knows the current scope t • Follow s-t links

19. Handling nested procedures • Method 1 : static (access) links • Setting the links: • if the callee is nested directly within the caller, set its static link to point to the caller's frame pointer (or stack pointer) • if the callee has the same nesting level as the caller, set its static link to point to wherever the caller's static link points to

20. Handling nested procedures • Method 2 : Displays • A Display encodes the static link info in an array. • The ith element of the array points to the frame of the most recent procedure at scope level i • How? • When a new stack frame is created for a procedure at nesting level i, • save the current value of D[i] in the new stack frame (to be restored on exit) • set D[i] to the new stack frame

21. Stack maintenance • Calling sequence : • code executed by the caller before and after a call • code executed by the callee at the beginning • code executed by the callee at the end

22. Stack maintenance • A typical calling sequence : • Caller assembles arguments and transfers control • evaluate arguments • place arguments in stack frame and/or registers • save caller-saved registers • save return address • jump to callee's first instruction

23. Stack maintenance • A typical calling sequence : • Callee saves info on entry • allocate memory for stack frame, update stack pointer • save callee-saved registers • save old frame pointer • update frame pointer • Callee executes

24. Stack maintenance • A typical calling sequence : • Callee restores info on exit and returns control • place return value in appropriate location • restore callee-saved registers • restore frame pointer • pop the stack frame • jump to return address • Caller restores info • restore caller-saved registers