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 • 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.