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.

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

procedure main x, a: int;

procedure one() begin x := 1; end

procedure two() begin x:int; one(); endbegin x := 2; read(a); if a>0 then one() else two(); print(x);end.

run 1 : a is positiveone() is called. The x in one() is bound to themost recent declaration which is the globalone. The global x is given the value of 1 and the program prints 1 in the end.

run 2 : a is negativetwo() is called. It declares a local x. Then it calls one(). The x in one() is bound to themost recent declaration which is the localdeclaration in two(). That local x is given thevalue 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 : 1. 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 : 2. Callee saves info on entry

• allocate memory for stack frame, update stack pointer

• save callee-saved registers• save old frame pointer • update frame pointer

3. Callee executes

24

Stack maintenance

• A typical calling sequence : 4. 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

5. Caller restores info• restore caller-saved registers