Lecture 14 run time environment

Run-Time Environment
Lecture 14

Run-time Environment
• Compiler must cooperate with OS and other system
software to support implementation of different
abstractions (names, scopes, bindings, data types,
operators, procedures, parameters, flow-of-control) on
the target machine
• Compiler does this by Run-Time Environment in
which it assumes its target programs are being
executed
• Run-Time Environment deals with
– Layout and allocation of storage
– Access to variable and data
– Linkage between procedures
– Parameter passing
– Interface to OS, I/O devices etc

Storage Organization
Code
Static
Heap
Free Memory
Stack
• Compiler deals with logical address space
• OS maps the logical addresses to physical addresses
Memory locations for code are determined at compile
time. Usually placed in the low end of memory
Size of some program data are known at compile time –
can be placed another statically determined area
Dynamic space areas – size changes during
program execution.
• Heap
• Grows towards higher address
• Stores data allocated under program control
• Stack
• Grows towards lower address
• Stores activation records
Typical subdivision of run-time memory

Run-Time Environments
• How do we allocate the space for the generated target
code and the data object of our source programs?
• The places of the data objects that can be determined at
compile time will be allocated statically.
• But the places for the some of data objects will be
allocated at run-time.
• The allocation and de-allocation of the data objects is
managed by the run-time support package.
– run-time support package is loaded together with the
generated target code.
– the structure of the run-time support package depends on the
semantics of the programming language (especially the
semantics of procedures in that language).

Procedure Activations
• Each execution of a procedure is called as activation of
that procedure.
• An execution of a procedure P starts at the beginning of
the procedure body;
• When a procedure P is completed, it returns control to the
point immediately after the place where P was called.
• Lifetime of an activation of a procedure P is the sequence of
steps between the first and the last steps in execution of P
(including the other procedures called by P).
• If A and B are procedure activations, then their lifetimes
are either non-overlapping or are nested.
• If a procedure is recursive, a new activation can begin
before an earlier activation of the same procedure has
ended.

A call graph is a directed multi-graph where:
• the nodes are the procedures of the program and
• the edges represent calls between these procedures.
Used in optimization phase.
Acyclic € no recursion in the program Can
be computed statically.
Call Graph

var a: array [0 .. 10] of integer;
procedure main
begin readarray(); quicksort(1,9); end
procedure readarray
var i: integer
begin … a[i] … end
function partition(y,z: integer): integer
var i,j,x,v: integer
begin … end
procedure quicksort(m,n: integer)
var i: integer
begin i := partition(m,n); quicksort(m,i-1); quicksort(i+1,n) end
Main
quicksort
readarray
partition
Example: Call Graph

Activation Tree/ Call Tree
• We can use a tree (called activation tree) to show
the way control enters and leaves activations.
• In an activation tree:
– Each node represents an activation of a procedure.
– The root represents the activation of the main program.
– The node A is a parent of the node B iff the control
flows from A to B.
– The node A is left to to the node B iff the lifetime of A
occurs before the lifetime of B.

Activation Tree (cont.)
program main;
procedure s;
begin ... end;
procedure p;
procedure q;
begin ... end;
begin q; s; end;
begin p; s; end;
enter main
enter p
enter q
exit q
enter s
exit s
exit p
enter s
exit s
exit main
A Nested Structure

Activation Tree (cont.)
main
p s
q s

• Activation Tree - cannot be computed statically
• Dynamic – may be different every time the
program is run
main
r() q (1,9)
p (1,9) q(1,3) q (5,9)
p (1,3) q(1,0) q (2,3) p (5,9) q(5,5) q (7,9)
p (2,3) q(2,1) q (3,3) p (7,9) q(7,7) q (9,9)
Activation Tree

Paths in the activation tree from root to some node
represent a sequence of active calls at runtime
main
r() q (1,9)
p (1,9) q(1,3) q (5,9)
p (1,3) q(1,0) q (2,3) p (5,9) q(5,5) q (7,9)
p (2,3) q(2,1) q (3,3) p (7,9) q(7,7) q (9,9)
Run-time Control Flow

• Procedure call/return – when a procedure
activation terminates, control returns to the
caller of this procedure.
• Parameter/return value – values are passed
into a procedure activation upon call. For a
function, a value may be returned to the caller.
• Variable addressing – when using an
identifier, language scope rules dictate the
binding.
Implementing Run-time control flow

• Historically, the first approach to solve the run-
time control flow problem (Fortran)
• All space allocated at compile time
– Code area – machine instructions for each
procedure
– Static area / procedure call frame/ activation
record
• single data area allocated for each procedure.
– local vars, parameters, return value, saved registers
• return address for each procedure.
Static Allocation

Code area
Data area
for procedure
A
Data area
for procedure
BCode
generated
for A
Code
generated
for B
return addr return addr
Local data,
parameters,
return
value,
registers
for A
Local data,
parameters,
return
value,
registers
for B
Static Allocation

• When A calls B:
– in A: evaluate actual parameters and place into B’s
data area, place RA in B’s data area, save any
registers or status data needed, update the program
counter (PC) to B’s code
• When the call returns
– in B: move return value to known place in data area,
update PC to value in RA
– in A: get return value, restore any saved registers or
status data
Call/Return processing in Static Allocation

Code area Activation
for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
…
return
PC
Call tree:
A
Local data,
parameters,
return
value,
registers
for A
Local data,
parameters,
return
value,
registers
for B
Static Allocation

Static Allocation
for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
…
return
L1
dataLocal
for A
Local data
for B
PC
Call tree:
A
B

Static Allocation
Code area Activation Activation
A:
call B
L1:
B:
…
return
for pro
A
cedure for procedure
B
L1
Local
for A
data Local data
for B
PC
Call tree:
A

Activation
for procedure
A
Code area
A:
call B
return addr
dataLocal
for A
Activation
for procedure
B
return addr
Local data
for B
B:
call B
L2:
What happens???
Static Allocation: Recursion?

for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
call B
L2:
return
dataLocal
for A
Local data
for B
PC
Call tree:
A
Static Allocation: Recursion

for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
call B
L2:
return
dataLocal
for A
Local data
for B
PC L1
Call tree:
A
B

for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
call B
L2:
return
dataLocal
for A
Local data
for B
PC L2
Call tree:
A
B
B

for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
call B
L2:
return
dataLocal
for A
Local data
for B
PC L2
Call tree:
A
B

for procedure
A
Activation
for procedure
B
A:
call B
L1:
B:
call B
L2:
return
dataLocal
for A
dataLocal
for B
PC L2
Call tree:
A
B
We’ve lost
the L1 label
so we can’t
get back to
A

• Variable addresses hard-coded, usually as
offset from data area where variable is
declared.
addr(x) = start of x's local scope + x's offset
Runtime Addressing in Static Allocation

Need a different approach to handle recursion.
• Code area – machine code for procedures
• Static data – often not associated with
procedures
• Stack (Control Stack) – runtime information
Stack Allocation

Control Stack
• The flow of the control in a program corresponds to a
depth-first traversal of the activation tree that:
– starts at the root,
– visits a node before its children, and
– recursively visits children at each node an a left-to-right
order.
• A stack (called control stack) can be used to keep track
of live procedure activations.
– An activation record is pushed onto the control stack as the
activation starts.
– That activation record is popped when that activation ends.
– Dynamic – grows and shrinks
• When node n is at the top of the control stack, the stack
contains the nodes along the path from n to the root.

Variable Scopes
• The same variable name can be used in the different parts of
the program.
• The scope rules of the language determine which declaration of
a name applies when the name appears in the program.
• An occurrence of a variable (a name) is:
– local: If that occurrence is in the same procedure in
which that name is declared.
– non-local: Otherwise (ie. it is declared outside of that
procedure)
a is local
b is non-local
procedure p;
var b:real;
procedure q;
var a: integer;
begin a := 1; b := 2; end;
begin ... end;

Activation Records
• Information needed by a single execution of a
procedure is managed using a contiguous block of
storage called activation record.
• An activation record is allocated when a procedure is
entered, and it is de-allocated when that procedure
exited.
• Size of each field can be determined at compile
time (Although actual location of the activation
record is determined at run-time).
– Except that if the procedure has a local variable
and its size depends on a parameter, its size is
determined at the run time.

Activation Records (cont.)
return value
actual
parameters
optional control
link
optional access
link
saved machine
status
local data
temporaries
The returned value of the called procedure is returned
in this field to the calling procedure. In practice, we may
use a machine register for the return value.
The field for actual parameters is used by the calling
procedure to supply parameters to the called procedure.
The optional control link points to the activation record
of the caller.
The optional access link is used to refer to nonlocal data
held in other activation records.
The field for saved machine status holds information about
the state of the machine before the procedure is called.
The field of local data holds data that local to an execution
of a procedure..
Temporary variables is stored in the field of temporaries.

Activation Records (Ex1)
program main;
procedure p;
var a:real;
procedure q;
var b:integer;
begin ... end;
begin q; end;
procedure s;
var c:integer;
begin ... end;
begin p; s; end;
main
p
a:
q
b:
stack
main
p
q
s

Activation Records for Recursive Procedures
program main;
procedure p;
function q(a:integer):integer;
begin
if (a=1) then q:=1;
else q:=a+q(a-1);
end;
begin q(3); end;
begin p; end;
main
p
a: 3
q(3)
a:2
q(2)
a:1
q(1)

Stack (growing downward)Call Tree
Main
readarray
Main
a: array
readarray
i: integer
Stack Allocation for quicksort 1

Stack (growing downward)
Main
a: array
quick(1,9)
i: integer
Call Tree
Main
readarray quick(1,9)

Stack (growing downward)Call Tree
Main
readarray quick(1,9)
quick(1,3)
quick(1,0)
p(1,9)
p(1,9)
Main
a: array
quick(1,9)
i: integer
quick(1,3)
i: integer
quick(1,0)
i: integer

Frame pointer $fp:
points to the first
word of the frame,
Stack pointer ($sp):
points to the last
word of the frame.
The frame consists of
the memory between
locations pointed by
$fp and $sp
Layout of the stack frame

Creation of An Activation Record
• Who allocates an activation record of a procedure?
– Some part of the activation record of a procedure is
created by that procedure immediately after that
procedure is entered.
– Some part is created by the caller of that procedure
before that procedure is entered.
• Who deallocates?
– Callee de-allocates the part allocated by Callee.
– Caller de-allocates the part allocated by Caller.

Creation of An Activation Record (cont.)
return value
actual parameters
optional control link
optional access link
saved machine status
local data
temporaries
return value
actual parameters
optional control link
optional access link
saved machine status
local data
temporaries
Callee’s Responsibility
Caller’s Activation Record
Caller’s Responsibility
Callee’s Activation Record

Callee’s responsibilities before running
• Allocate memory for the activation record/frame by
subtracting the frame’s size from $sp
• Save callee-saved registers in the frame. A callee must save
the values in these registers ($s0–$s7, $fp, and $ra) before
altering them
[since the caller expects to find these registers unchanged after
the call.]
– Register $fp is saved by every procedure that allocates a new
stack frame.
– $ra only needs to be saved if the callee itself makes a call.
– The other callee-saved registers that are used also must be saved.
• Establish the frame pointer by adding the stack frame’s size
minus four to $sp and storing the sum in $fp.

• Pass arguments: By convention, the first four arguments
are passed in registers $a0–$a3.
Any remaining arguments are pushed on the stack and
appear at the beginning of the called procedure’s stack
frame.
• Save caller-saved registers: The called procedure can
use these registers ($a0–$a3 and $t0–$t9) without first
saving their value. If the caller expects to use one of these
registers after a call, it must save its value before the call.
• Execute a jal instructionwhich jumps to the callee’s first
instruction and saves the return address in register $ra.
Caller’s Responsibility

Call Processing: Callee
• Initializes local data, calculate the offset of each
variable from the start of the frame
• The executing procedure uses the frame pointer
to quickly access values in its stack frame.
For example, an argument in the stack frame can
be loaded into register $v0 with the instruction
lw $v0, 0($fp)
• Begins local execution

• If the callee is a function that returns a value, place
the returned value in a special register e.g. $v0.
• Restore all callee-saved registers that were saved
upon procedure entry.
• Pop the stack frame by adding the frame size to
$sp.
• Return by jumping to the address in register $ra.
Added at the ‘return’ point(s) of the function
Callee’s responsibilities on returning

• Restore registers and status
• Copy the return value (if any) from activation
• Continue local execution
Added after the point of the call
Return Processing: Caller

Lecture 14 run time environment

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Lecture 14 run time environment (20)

More from Iffat Anjum (20)

Recently uploaded (20)

Lecture 14 run time environment