Run-time Environments Chapter 7 1 Compiler Construction Run-time - - PowerPoint PPT Presentation

Run-time Environments

Chapter 7

Compiler Construction Run-time Environments

1

Run-time Environment

• The static source code requires considerable support to be executed
• n a computer

– Data objects must be created and destroyed – Variables with the same name in different parts of the program may refer to different data objects – The data corresponding to a variable in one context must be copied to a new data

• bject in another context when a method call is performed

– Data objects of different types may require different memory representations – A data type may map directly to a data element supported by the hardware (integers usually do), or it may be more complicated and require a custom layout

Compiler Construction Run-time Environments

2

Programs and Procedures

Modern programs consist of procedures

• Typically a main procedure begins executing first, and it may invoke
• ther procedures to accomplish the task of the program
• These procedures are specified by the programmer in the program

– Methods in OO languages are really just old-fashioned procedures (this is the secret parameter in instance methods)

Compiler Construction Run-time Environments

3

Basic Terminology

• Procedure definition

An element of the source code where the procedure is fully specified:

– It is given a name – Its parameters (if any) are specifi ed – Its return type is specifi ed – Its body (statements to execute) is defi ned

• Formal parameters (formals)

Parameters specified in the procedure definition

• Actual parameters (actuals)

Parameters passed by the calling environment when the procedure is invoked (or activated)

Compiler Construction Run-time Environments

4

Control Flow Among Procedures

• 1. Control flows sequentially—a sequence of steps

Control is at some specific point in the program at each step

• 2. Each execution of a procedure starts at the beginning of the procedure

body and eventually returns control to the point immediately following the place where the procedure was called

Compiler Construction Run-time Environments

5

Procedure Activation

• Each execution of a procedure body is known as its activation
• The lifetime of an activation of a procedure is the sequence of steps

between the first and last steps (inclusive) in the execution of the procedure’s body

• If p1 and p2 are two procedure activations, their lifetimes are either non-
• verlapping or nested.

If control enters p2 before p1 is left, then control must leave p2 before it leaves

p1

• This is assuming single execution threads

Compiler Construction Run-time Environments

6

Recursion

• In a recursive procedure a new activation of the same procedure can

begin before an earlier activation has ended activation

• A recursive method need not call itself directly

Compiler Construction Run-time Environments

7

Control Stacks

• The flow of control in a program corresponds to a depth-first traversal
• f an activation tree
• See the Java version of Figure 7.1 in the Dragon Book and its ensuing
• utput
• A control stack keeps track of the procedure activations

– Push the node for an activation onto the control stack when the activation begins and pop it off when the activation ends – The contents of the control stack corresponds to a path to the root of the activation tree – When node n is on the top of the control stack, the stack contains the nodes along a path from n to the root

Compiler Construction Run-time Environments

8

Scope

• A declaration associates a name with a component of the program

– Variable (data) – Procedure

• The same name may be used in independent declarations in different

parts of a program

• Scope rules determine which declaration of a name applies when a

name appears in the program text

• Our sort program declared the variable i multiple times, and the

variable i was used in various places within the program

• Variables declared within procedures are local to those procedures;

variables declared outside of procedures are nonlocal variables

Compiler Construction Run-time Environments

9

Scope and Symbol Tables

At compile time, a symbol table is used to find the declaration that applies to an occurrence of a name

• A symbol table entry is created when a declaration is seen by the

compiler

• As long as we are within the scope of a declaration, a name’s entry is

returned when it is looked up in the symbol table

Compiler Construction Run-time Environments

10

Bindings of Names

l −value r−value Program text Name Storage Environment Value State

Static Notion Dynamic Counterpart Procedure definition Procedure activation Name declaration Name bindings Scope declaration Lifetime of binding

Compiler Construction Run-time Environments

11

Questions to Ask

How a compiler organizes its storage and binds names is decided by answering the following questions:

• 1. May procedures be recursive?
• 2. What happens to the values of local names when control returns from

an activation of a procedure?

• 3. May a procedure refer to nonlocal names?
• 4. How are parameters passed when a procedure is invoked?
• 5. May procedures be passed as parameters?
• 6. May procedures be returned as results?
• 7. May storage be allocated dynamically under program control?
• 8. May storage be explicitly deallocated?

The answers to these questions affect the run-time support required for a programming language

Compiler Construction Run-time Environments

12

Run-time Memory

An executing program requires storage for its instructions and data objects

• Fixed-size requirements:

– Code – Static data (e.g.: Java static (class) fi elds; C/C++ global variables, class variables, and static locals)

The compiler can compute the space required for these parts of an executing program which remain fixed throughout the program’s execution

• Variable-size requirements:

– Space required for the data in each procedure activation – Space required for objects dynamically allocated

Compiler Construction Run-time Environments

13

Program Memory Layout

Static Data Code Stack Heap

Compiler Construction Run-time Environments

14

Program Memory Layout

Static Data Code Stack Heap

• Code does not (or should not!) change during

program execution

• Static data’s storage location or size need not

change during program execution

• The stack holds

– local variables – return value (maybe) – return address (maybe) – temporaries used in expression evaluation

• The heap holds the data for dynamically created

data (typically objects in an OO language)

Compiler Construction Run-time Environments

15

Stack vs. Heap

• Both the stack and the heap can grow and shrink dynamically as a

program executes

• The stack grows and shrinks in a very regular fashion (LIFO)
• The heap can become fragmented as earlier allocated space is freed

up before later allocated space

• Often the stack and heap grow towards each each other from opposite

memory addresses

Compiler Construction Run-time Environments

16

Activation Record

• AKA frame
• Created on the stack for a procedure activation

Local data Temporaries Access link Control link Actual parameters Return value Saved machine status

Compiler Construction Run-time Environments

17

Activation Record Details 1

Local data Temporaries Access link Control link Actual parameters Return value Saved machine status

• Return value—value to be returned by the

procedure

A register is often used instead (quicker)

• Actual parameters—values pushed by the caller

Registers may be used in some instances

• Control link—points to the activation record of

the caller

• Access link—points to non-local data

– Required for langauges like Pascal which allows nested procedures and enclosed procedures have access to the local data in enclosing procedures – In Decaf, could be used to refer to the object in which the method was called (this)

Compiler Construction Run-time Environments

18

Activation Record Details 2

Local data Temporaries Access link Control link Actual parameters Return value Saved machine status

• Saved machine status—the contents of the

instruction pointer (program counter) and any registers the procedure will modify

• Local data—variables local to the procedure
• Temporaries—values that arise from the

evaluation of expressions The sizes of which of these fields can be determined at compile time?

Compiler Construction Run-time Environments

19

Compile-time Local Data Layout

• The amount of storage required for a name depends on its type
• The local data field in the activation record (AR) can be computed at

compile time:

int position = address of start of the local data area within the AR; SymbolTable st = the symbol table for the procedure; for each declaration within the procedure of the form <type var> { st.insert(var, position); // Insert identifier and offset AR[position] is reserved to store the value of variable var; position = position + sizeof(type); }

Compiler Construction Run-time Environments

20

Architectural Constraints

• The actual layout of the data may be subject to

alignment constraints imposed by the processor

For example, 4-byte integers may have to begin at addresses divisible by 4 bytes

• For example, consider the C declarations

int counter; char letter; int result;

counter letter result 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2011 2024 (unused) (unused) (unused)

This extra space is called padding To save space compilers may pack data; this may require additional instructions to properly align the data at run time.

Compiler Construction Run-time Environments

21

Static Allocation

• Static allocation lays out storage for all data objects at compile time
• Thus, no run time support is required
• The names are bound to the same storage locations regardless of

which procedure is active

• If only static allocation were available:

– Recursive methods would be restricted since all activations of a procedure would use the same bindings for local variables – Dynamic data structures would be impossible without a run-time storage allocation mechanism Original FORTRAN used static storage allocation

Compiler Construction Run-time Environments

22

Stack Allocation

• Activation records are pushed and popped as activations begin and end
• Locals are bound to fresh storage during each activation

Previous values are lost when the activation ends

• Typically a register ($sp in MIPS) marks the top of the stack
• At run time an AR can be allocated and deallocated by incrementing

and decrementing $sp

Compiler Construction Run-time Environments

23

MIPS Calling Convention

(See the handout SPIM S20: A MIPS R2000 Simulator by James Larus)

• An AR (stack frame) consists of the memory between $fp and $sp
• $fp points to the word immediately after the last argument passed on

the stack

• $sp points to the last word in the frame

Compiler Construction Run-time Environments

24

Calling Sequence

• A compiler designer must formulate a calling sequence that callers and

callees (procedures) must follow when a procedure is to be activated

• Issues:

– Who is responsible for saving the machine status? – Who is responsible for cleaning up the activation record? – In what order are parameters stored in the AR?

Compiler Construction Run-time Environments

25

Caller’s Responsibility

To make the call:

• 1. Evaluate the actual parameters and push them onto the stack
• 2. Execute a jal instruction to the subroutine

Compiler Construction Run-time Environments

26

Callee’s Responsibility

When called:

• 1. Establishe the stack frame (AR) by

subtracting the frame size from $sp

• 2. Save in the frame any registers the

procedure will modify

• $fp for sure
• $ra if the routine itself make calls
• 3. Initialize local data (if appropriate)
• 4. Set $fp = $sp + frame size - 4

Dynamic area Local Variables Saved Registers Arguments High Memory Low Memory $sp $fp Compiler Construction Run-time Environments

27

Callee’s Cleanup Responsibility

When done:

• 1. Restore any registers saved upon entry
• 2. Pop the stack frame (AR):

$sp = $sp + frame size

• 3. Return by jumping to the address in $ra

Dynamic area Local Variables Saved Registers Arguments High Memory Low Memory $sp $fp Compiler Construction Run-time Environments

28

Caller’s Cleanup Responsibility

When procedure has returned: Copy the return value into local storage

Compiler Construction Run-time Environments

29

An Alternative

• The caller removes the parameters from the stack instead of the callee
• This allows a variable number of arguments (like C/C++ printf())

Compiler Construction Run-time Environments

30

Dangling References

• Beware of attempting access in stack frame once that procedure’s

activation has ended

• Consider the following C/C++ code:

int *dangle() { int i = 10; return &i; } main() { int *p; p = dangle(); }

gcc gives a warning:

dangling.c: In function ‘dangle’: dangling.c:4: warning: function returns address of local variable

Compiler Construction Run-time Environments

31

Heap Allocation

Stack allocation is a valuable strategy, but it has some limitations:

• The values of local names cannot be retained when an activation ends
• What if a called activation outlives its caller?

Compiler Construction Run-time Environments

32

Heap Allocation

• Allocation and deallocation is not done strictly in a LIFO fashion
• A heap manager parcels out storage from contiguous memory as

needed when objects must be created

• Objects can be deallocated in any order, so the heap can become

fragmented

• The heap manager is responsible for dealing with the leftover

deallocated fragments

Compiler Construction Run-time Environments

33

Dynamic Scope

With dynamic scope, a new activation inherits the existing bindings of non- local names to storage

public class DynamicScope { private static double r; private static void show() { System.out.print(r + " "); } private static void small() { double r; r = 0.125; show(); } public static void main(String[] args) { r = 0.25; show(); small(); System.out.println(); show(); small(); System.out.println(); } }

• What is printed under

lexical scoping rules?

• What is printed under

dynamic scoping rules?

Compiler Construction Run-time Environments

34

Parameter Passing Techniques

Actual values can be associated with formal parameters in various ways:

• Call-by-value
• Call-by-reference
• Copy-in, copy-out
• Call-by-name

The differences among parameter-passing techniques are based on whether an actual parameter is an r-value, l-value, or the text of the actual parameter itself

Compiler Construction Run-time Environments

35

Call-by-value

• Used in C, Java, and Decaf, among many other languages
• A formal parameter is treated like a local name, so storage for

parameters is in the callee’s AR

• The caller evaluates the actual parameters and places their r-values

into the storage for the formal parameters

• Operations on formal parameters do not affect values in the AR of the

caller

Compiler Construction Run-time Environments

36

Call-by-reference

• AKA call-by-address, call-by-location
• If the actual parameter is a name with an l-value, then the l-value itself

is passed

• If the actual parameter is an expression (like x + 2 or 2) that has no

l-value, then the expression is evaluated, and its result is stored in a

new location, and the address of that new location is passed

Compiler Construction Run-time Environments

37

Copy-in, Copy-out

• AKA Copy-restore, value-result
• Before control passes to the called procedure, the actual parameters

are evaluated; their r-values are passed to the procedure as in call-by- value the l-value itself is passed

• When control returns, the current r-values of the formal parameters are

copied to the l-values of the actuals

• Consider swap(i, a[i])

Compiler Construction Run-time Environments

38

Call-by-name

• Works like a C/C++ macro substitution
• The body of the procedure is substituted for the call in the caller; the

actual parameters are literally substituted for the formal parameters

• Any names local to the procedure are kept distinct from names in the

caller

• As with macros, actual parameters may need to be enclosed within

parentheses for things to work as expected

Compiler Construction Run-time Environments

39

Heap Management

• If an object is no longer referenced by any variables, it is garbage
• Garbage collection is the process that deallocates (reclaims) memory

that is no longer referenced

• There are a number of GC strategies; the most popular are reference

counting and mark/sweep algorithms

Compiler Construction Run-time Environments

40

Reference Counting

• Keep a count of the number of references to an object
• When the count reaches zero, deallocate the object
• Circular references are problematic
• Used in COM, Visual Basic, Python

Compiler Construction Run-time Environments

41

Mark/Sweep

• Suspend execution of the program
• Mark all objects on the heap
• Follow all active pointers into the heap
• Any object that is not marked can be reclaimed
• (Optional) compact memory
• Used in Java (compacting generational mark/sweep)

Compiler Construction Run-time Environments

42