COMP421 Week9 10 11

COMP-421 Compiler Design
Presented by
Dr Ioanna Dionysiou
Lecture Outline
[ALSU07] Chapter 6 Intermediate Code
Representation
Section 6.2
[ALSU07] Chapter 7 Run-Time Environments

Sections 7.1, 7.2, 7.3
Copy right (c) 2011 Ioanna Diony siou
Chapter 6 Lecture Outline

Intermediate Code Representation
3-address code essentials
3-address code implementation techniques
Intermediate Code Representation
Parsing
Type-checking
Syntax tree
Intermediate
Form
Generation
Assumption: Source code is parsed and type-checked
Intermediate Languages
So far, we have seen one kind of intermediate
representation
Syntax trees (2nd week of classes)
Natural hierarchical structure of program
A new kind
3-address code
Abstract form
3-address code
It is a sequence of statements of the general
form
Arithmetic operator
Logical operator
x := y op z
Names
Constants
temporaries
3-address code
/* source language expression */
/* 3-address statements */
x+y*z
t1 := y * z
t2 := x + t1
Where t1, t2 are compilergenerated temporary names
Variable names can appear
directly in 3-address
statements
3-address code
/* source language expression */
/* 3-address statements */
a := b * -c + b * -c
t1 := -c
t2 := b * t1
t3 := -c
t4 := b * t3
t5 := t2 + t4
a := t5
:=
+
a
*
In other words, for each

interior node in the syntax
tree we create a new
temporary variable
unimus
unimus
Types of 3-address statements

Procedural call
Assignment statement
p(x1,x2,,xn)
param x1
param x2
param xn
call p, n
x := y op z
Assignment instruction
x := op z
Copy statement
x := y
Indexed assignments
Unconditional jump
x := y[i] , x[i] := y
goto L
Address and pointer

assignments
Conditional jump
if x relop y goto L
x := &y, x := *y, *x := y
Implementation of 3-address
3-address statement is an abstract form of
intermediate code
Need a concrete form
Records with fields for operator and operands
Quadruples
Triples
Indirect triples
Quadruples
It is a record structure with 4 fields
Operator
Argument 1
Argument 2
Result
a:= b * -c + b * -c
t1 := -c
t2 := b * t1
t3 := -c
t4 := b * t3
t5 := t2 + t4
a := t5
op
arg1
unimus
unimus
t3
t4
t2
t4
t5
:=
t5
arg2
result
t1
t1
t2
t3
Triples
Operator
Argument 1 (pointer to symbol table or triple)
Idea
avoid entering temporary names to symbol table
Refer to a temp value by the position of that statement that
computes it
a:= b * -c + b * -c
t1 := -c
t2 := b * t1
t3 := -c
t4 := b * t3
t5 := t2 + t4
a := t5
op
arg1
arg2
unimus
unimus
(2)
(1)
(3)
assign
(4)
(0)
Indirect Triples
Operator
Idea
List pointers to triples instead listing triples
statement
op
arg1
(0)
(14)
unimus
(1)
(15)
(2)
(16)
unimus
(3)
(17)
(16)
(4)
(18)
(15)
(17)
(5)
(19)
assign
(18)
arg2
(14)
In-class Exercise
Show the 3-address code for the following
statements:
a := 5 + 6
c := a + 3
Try to optimize the 3-address code generated
Chapter 7 Lecture Outline

Chapter 7
Source language issues
Activation trees, control stacks, scope of declaration,
bindings
Storage Organization
Activation records
Storage Allocation Strategies

Static allocation, stack allocation, heap allocation
Source Language Issues

Before considering code generation
Need to relate static program source to actions
that must take place at runtime to implement this
program
Relationship between names and data objects
Allocation and deallocation of data objects is managed
by runtime support package
Routines loaded with the generated target code
Depending on the language, the runtime environment

may be
Fully static, stack-based or dynamic
Type of environment determines the need to use stack, heap
or both
Program and Procedures

Procedure definition
procedure name
associated with
procedure body
Procedure call
PROGRAMsort(input,output);
VARa:array[0..10]ofInteger;
PROCEDUREreadarray;
VARi:Integer;
BEGIN
fori:=1to9doread(a[i]);
END;
FUNCTIONpartition(y,z:Integer):Integer;
VARi,j,x,v:Integer;
BEGIN
END;
PROCEDUREquicksort(m,n:Integer);
VARi:Integer;
Formal parameters
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Actual parameters
Program and Procedures

Procedure Activation
An execution of a
procedure body
Lifetime of Procedure
Activation
Sequence of steps between
the first and last statements
in the execution of the
procedure body, including
time spent executing other
procedures called by p
PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
Formal parameters
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Actual parameters
Flow of control
Assumptions about the flow of control among
procedures during program execution
Control flows sequentially
Execution of a procedure starts at the beginning
of procedure body and eventually returns control
to the point immediately following the place where
the procedure was called
In this case we can use trees to illustrate the flow of
control in a program
goto statement (transfers control to another point)
Procedure Activation
Each time control enters a procedure q from
procedure p, it eventually returns to p (if no
errors occur)
Activation of procedure p
Activation of procedure q
Return to activation of procedure p
Consider
lifetime(p) and lifetime(q)
Lifetime(p) and lifetime(q) are non-overlapping
Lifetime(p) and lifetime(q) are nested
See example above
Recursive Procedures
A recursive procedure is a procedure that
calls itself
A new activation begins before an earlier
activation of the same procedure has ended
Several activations for procedure p exist at time t
A recursive procedure is a procedure p that

calls another procedure q, which in turns calls
procedure p
Procedure p
Procedure q
Call to procedure q
Call to procedure p
Activation tree
We can use a tree (activation tree) to depict
the way control enters and leaves activations
How to build an activation tree
Each node represents an activation of a
procedure
The root represents the activation of the main program
The node for a is the parent of node b iff control flows
from activation a to b
The node for a is to the left of the node for b iff the
lifetime(a) occurs before lifetime(b)
Activation Tree for a program

PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Can you build the activation tree

for this program?
Use
s - activation of main program sort
r - activation of readarray
p - activation of partition
q(x,y) - activation of quicksort
Start with
s as the root of the tree
r and q(1,9) are its children, etc

PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
q(1,9)
p(1,9)
q(1,3)
p(1,3)
p(2,3)
q(1,0)
q(5,9)
q(2,3) p(5,9)
q(2,1)
q(3,3) p(7,9)
q(5,5)
q(7,9)
q(7,7)
q(9,9)
Control Stack and Activation Tree

Flow of control in a program
Depth-first traversal of the activation tree
Use a stack called control stack to keep track of
the live procedure activations
Push node for an activation onto the stack as the
activation begins
Pop node for an activation off the stack when the
activation ends
Control Stack contents
Node n is at top of the control stack
Stack contains the nodes along the path from n to the root

r, p(1,9), p(1,3) and q(1,0)
have executed to completion
(dashed lines)
p(1,9)
p(1,3)
q(1,9)
q(1,3)
q(1,0)
q(2,3)
Stack contains
q(2,3)
q(1,3)
q(1,9)
s
top
Scope of declaration
PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Scope of variables depends

on the language scope rules
(1) Local
(2) Nonlocal
Same name, different scope
Bindings of names
Environment
Function that maps a name to a storage location
f: name storage location
State
Function that maps a storage location to a value
g: storage location value
g( f(name) ) = value
Bindings of names
Consider storage location 100 is associated with
variable x and it currently holds value 0
Environment
x is bound to storage location 100
State
Value held is 0
Consider assignment statement x:=10

Environment
x is still bound to storage location 100
State
Value held is 10
Bindings of names
A binding is the dynamic counterpart of a declaration
Pascal local variable name in a procedure is bound to a different
storage location in each activation of a procedure
STATICNOTION
DYNAMICCOUNTERPART
Definitionofprocedure
Activationsoftheprocedure
Declarationofname
Bindingsofthename
Scopeofdeclaration
Lifetimeofbinding
Lecture Outline
Activation trees, control stacks, scope of
declaration, bindings
Activation records

Suppose that the compiler obtains memory
from the OS so that it can execute the
compiled program
Program gets loaded on a newly created process
This runtime storage must hold

Generated target code
Data objects
A counterpart of the control stack to keep track of
procedure activations
Runtime Memory
code for function 1
code for function 2
PASCAL and C use extensions of the control stack

to manage activations of procedures
...
code for function n
global / static area

stack
free space
Stack contains information about register values,

value of program counter and data objects whose
lifetimes are contained in that of an activation
Heap holds all other information. For example,
activations that cannot be represented as a tree.
By convention, stack grows down and the top of
the stack is drawn towards the bottom of this slide
(value of top is usually kept in a register)
heap
Runtime Memory
code for function 1
code for function 1
code for function 2
code for function 2

...
...
code for function n
code for function n
stack
stack
Stack grows
free space
free space
heap
heap
Activation Record
Information needed by a single
execution of a procedure is
managed using an activation
record or frame
Not all compilers use all of the
fields
Pascal and C push activation
record on the runtime stack
when procedure is called and
pop the activation record off the
stack when control returns to
the caller
returned value
actual parameters
optional control link
optional access link
saved machine status
local data
temporaries
Activation Record
1)
Temporary values
e.g. those arising in the evaluation of
expressions
2)
Local data
Data that is local to an execution of the
procedure
3)
Saved machine status

State of the machine info before procedure
is called. Values of program counter and
machine registers that have to be restored
when control returns from the procedure
returned value
actual parameters
local data
temporaries
Activation Record
4)
Access Link
refer to non-local data held in other activation records
5)
Control link
points to the activation record of the caller
6)
Actual parameters
actual parameters
used by the calling procedure to supply parameters to the

called procedure
(in practice these are passed in registers)
7)
returned value

Returned value
used by the called procedure to return a value to the
calling procedure
(in practice it is returned in a register)
local data
temporaries
Local data
The field for local data is set when
declarations in a procedure are examined
during compile time
Variable-length data is not stored here
Keep a count of the memory locations that have
been allocated so far
Determine a relative address (offset) of the
storage for a local with respect to some position
(e.g. beginning of the frame)
Multibyte objects are stored in consecutive bytes and
given the address of the first byte
Lecture Outline
Activation trees, control stacks, scope of
declaration, bindings
Activation records

Storage-allocation strategies
There are three storage allocation strategies:
Static allocation
Stack-based allocation
Dynamic (or heap-based) allocation
Static Allocation
In a static environment (Fortran 77) there are
a number of restrictions:
Size of data objects are known at compile time
No recursive procedures
No dynamic memory allocation
Only one copy of each procedure activation

record exists at time t
We can allocate storage at compile time
Bindings do not change at runtime
Every time a procedure is called, the same bindings
occur
Static Allocation
inti=10;
code for function 1
code main()
intf(intj)
{
intk;
intm;
}
main()
{
intk;
f(k);
}
code f()
i (int)
main()
Activation
record
f()
Activation
record
code for function 2

...
code for function n

stack
k (int)
free space
k (int)
m (int)
heap
Stack-based Allocation
In a stack-based allocation, the previous
restrictions are lifted (Pascal, C, etc)
procedures are allowed to be called recursively
Need to hold multiple activation records for the same
procedure
Created as required and placed on the stack
Each record will maintain a pointer to the record that activated
it
On completion, the current record will be deleted from the
stack and control is passed to the calling record
Dynamic memory allocation is allowed

Pointers to data locations are allowed
PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Position in
Activation Tree
Activation Records
On Stack
s
a (array)
PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Position in
Activation Tree
Activation Records
On Stack
s
s
r
a (array)
r
i (integer)
PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Position in
Activation Tree
Activation Records
On Stack
s
s
r
q(1,9)
a (array)
q(1,9)
i (integer)
PROCEDUREreadarray;
VARi:Integer;
BEGIN
END;
VARi,j,x,v:Integer;
BEGIN
END;
VARi:Integer;
BEGIN
if(n>m)thenBEGIN
i:=partition(m,n);
quicksort(m,i1);
quicksort(i+1,n)
END
END;
BEGIN/*ofmain*/
a[0]:=9999;a[10]:=9999;
readarray;
quicksort(1,9)
END.
Position in
Activation Tree
Activation Records
On Stack
s
s
r
q(1,9)
p(1,9) q(1,3)
a (array)
q(1,9)
i (integer)
q(1,3)
i (integer)
Calling Sequences
Procedure calls are
implemented by generating
calling sequences in the
target code
Call sequence: allocates
activation record and enters
information into fields
Return sequence: restores the
state of the machine so that
the calling procedure can
continue execution
returned value
actual parameters
local data
temporaries
Calling Sequences
returned value
Why placing returned value and

actual parameters next to the
activation record of the caller?
Caller can access these values
using offsets from its own activation
record
No need to know the middle part of
the callees activation record
actual parameters
local data
temporaries
returned value
actual parameters
local data
temporaries
caller
callee
Calling Sequences
returned value
How do we calculate offset?
actual parameters
Maintain a register that points to

the end of the machine status
field in an activation record
Top_sp is known to the caller, so
it can be responsible for setting it
before control flows to the called
procedure
Callee can access its temporaites
and local data using offsets from
top_sp
top_sp

local data
temporaries
returned value
actual parameters
local data
temporaries
caller
callee
Call Sequence
The caller evaluates actuals
The caller
stores a return address and the old value of
top_sp into the callees activation record
increments top_sp; that is moved past the callers
local data and temporaries and the callees
parameter and status fields
The callee
saves register values and other status information
The callee
initializes its local data and begins execution
Return Sequence
The callee places a return value next to the
activation record of the caller
Using the information in the status field, the
callee
restores top_sp and other registers
braches to a return address in the callers code
Although top_sp has been decremented, the

caller can copy the returned value into its own
activation record and use it to evaluate an
expression
Dangling References
Whenever storage is deallocated, the
problem of dangling references arises
Occurs when there is a reference to storage that
has been deallocated
Logical error
Mysterious bugs can appear
Dangling References
Whats the problem?
int*dangle()
{
inti=23;
return&i;
}
main()
{
int*p;
p=dangle();
}
Dangling References
Local variable i only exists in
dangle()
int*dangle()
{
inti=23;
return&i;
}
main()
{
int*p;
p=dangle();
}
When procedure completes

execution and control is
transferred to main(), the space for
i does not exist anymore (pop
activation record for dangle off the
stack)
Pointer p is a dangling reference
Dynamic Allocation
Returning the address of a local variable is defined to be a
logical error (e.g. in C)
In a dynamic environment there is no such restriction
All variables and activation records must be maintained for as long as
there are references to them
Callee outlives the caller
It is also possible to return pointers to local functions

Must deallocate space when procedures and variables are no longer
needed (garbage collection)
Dynamic Allocation
Use a heap to maintain these records
Also called free store
Heap management is challenging

COMP421 Week9 10 11

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

COMP421 Week9 10 11

Caricato da

Copyright:

Formati disponibili

COMP-421 Compiler Design

[ALSU07] Chapter 7 Run-Time Environments

Copy right (c) 2011 Ioanna Diony siou

Chapter 6 Lecture Outline

Copy right (c) 2011 Ioanna Diony siou

Intermediate Code Representation

Assumption: Source code is parsed and type-checked

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

/* source language expression */

Copy right (c) 2011 Ioanna Diony siou

In other words, for each

Copy right (c) 2011 Ioanna Diony siou

Types of 3-address statements

Address and pointer

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Try to optimize the 3-address code generated

Copy right (c) 2011 Ioanna Diony siou

Chapter 7 Lecture Outline

Storage Allocation Strategies

Copy right (c) 2011 Ioanna Diony siou

Source Language Issues

Depending on the language, the runtime environment

Program and Procedures

Copy right (c) 2011 Ioanna Diony siou

Program and Procedures

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

A recursive procedure is a procedure p that

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Activation Tree for a program

Copy right (c) 2011 Ioanna Diony siou

Can you build the activation tree

Activation Tree for a program

Copy right (c) 2011 Ioanna Diony siou

Control Stack and Activation Tree

Copy right (c) 2011 Ioanna Diony siou

Activation Tree for a program

Copy right (c) 2011 Ioanna Diony siou

Scope of variables depends

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Consider assignment statement x:=10

Copy right (c) 2011 Ioanna Diony siou

Copy right (c) 2011 Ioanna Diony siou

Storage Allocation Strategies

Copy right (c) 2011 Ioanna Diony siou

This runtime storage must hold

Copy right (c) 2011 Ioanna Diony siou

PASCAL and C use extensions of the control stack

global / static area

Stack contains information about register values,

Copy right (c) 2011 Ioanna Diony siou

code for function 1

code for function 2

code for function 2

code for function n