UNIT 5

Runtime Environment
Prepared by:
Dr.R.I.Minu
Associate Professor

1
 Run-Time Environments
• A compiler must accurately implement the abstractions
embodied in the source language definition.
• These abstractions typically include names, scopes,
bindings, data types, operators, procedures,
parameters, and flow-of-control constructs.
• The compiler must cooperate with the operating
system and other systems software to support these
abstractions on the target machine.
• To do so, the compiler creates and manages a run-time
environment in which it assumes its target programs
are being executed.
 Run-Time Environments
This environment deals with a variety of issues
such as
• The layout and allocation of storage locations
for the objects named in the source program
• The mechanisms used by the target program to
access variables,
• The linkages between procedures,
• The mechanisms for passing parameters, and
• The interfaces to the operating system,
input/output devices, and other programs.
 Source language issues
• Does the source language allow
recursion - There will be several
instances for a recursive procedure
thus the memory allocation can be
determined only at runtime
• How the parameters are passed to
the procedure - allocation strategies
for call by value and call by reference
are different
 Storage Organization
• The executing target program runs in its own
logical address space in which each program
value has a location.
• The management and organization of this logical
address space is shared between the compiler,
operating system, and target machine.
• The operating system maps the logical
addresses into physical addresses, which are
usually spread throughout memory.
• The run-time representation of an object
program in the logical address space consists
of data and program areas
 Runtime Environment
• Relationship between names and data objects (of
target machine)

• Allocation & de-allocation is managed by run time

support package

• Each execution of a procedure is an activation of

the procedure. If procedure is recursive, several
activations may be alive at the same time.

• If a and b are activations of two procedures then their

lifetime is either non overlapping or nested

• A procedure is recursive if an activation can begin

before an earlier activation of the same procedure has
ended
6
 Procedure
• A procedure definition is a declaration that
associates an identifier with a statement
(procedure body)

• When a procedure name appears in an

executable statement, it is called at that
point

• Formal parameters are the one that appear

in declaration. Actual Parameters are the
one that appear in when a procedure is
called
7
 Activation tree
• Control flows sequentially

• Execution of a procedure starts at the beginning of body

• It returns control to place where procedure was called from

• A tree can be used, called an activation tree, to depict the

way control enters and leaves activations

• The root represents the activation of main program

• Each node represents an activation of procedure

• The node a is parent of b if control flows from a to b

• The node a is to the left of node b if lifetime of a occurs

before b
8
 Example
program sort; procedure quicksort (m, n
var a : array[0..10] of integer; :integer);
var i :integer;
procedure readarray; :
i:= partition (m,n);
var i :integer;
quicksort (m,i-1);
: quicksort(i+1, n);
function partition (y, z :
:integer) :integer; begin{main}
var i, j ,x, v :integer; readarray;
: quicksort(1,9)
end.

9
 Activation Tree
Sort

r q(1,9)

p(1,9) q(1,3) q(5,9)

returns 4

p(1,3) q(1,0) q(2,3) p(5,9) q(5,5) q(7,9)

returns 1 returns 6

p(2,3) q(2,1) q(3,3) p(7,9) q(7,7) q(9,9)

returns 2 returns 8

10
 Possible
Activati
on

Quick
sort prg
Activati
on Tree
 Control stack
• Flow of control in program corresponds to
depth first traversal of activation tree

• Use a stack called control stack to keep

track of live procedure activations

• Push the node when activation begins and

pop the node when activation ends

• When the node n is at the top of the stack

the stack contains the nodes along the
path from n to the root
12
 Scope of declaration
• A declaration is a syntactic construct associating
information with a name

– Explicit declaration :Pascal (Algol class of languages)

var i : integer

– Implicit declaration: Fortran

i is assumed to be integer

• There may be independent declarations of same name in a

program.

• Scope rules determine which declaration applies to a name

• Name binding
environment state
name storage value
13
 Storage organization
• The runtime storage
might be subdivided into code

– Target code static data

stack
– Data objects

– Stack to keep track of

procedure activation
heap
– Heap to keep all other
information

14
 Activation Record
• temporaries: used in expression
evaluation
Temporaries
• local data: field for local data
local data

• saved machine status: holds info machine status

about machine status before
procedure call
Access links
• access link : to access non local data
Control links

• control link :points to activation Parameters

record of caller
Return value
• actual parameters: field to hold
actual parameters

• returned value: field for holding value

to be returned 15
 Issues to be addressed
• Can procedures be recursive?

• What happens to locals when procedures return from an

activation?

• Can procedure refer to non local names?

• How to pass parameters?

• Can procedure be parameter?

• Can procedure be returned?

• Can storage be dynamically allocated?

• Can storage be de-allocated?

16
 Layout of local data
• Assume byte is the smallest unit

• Multi-byte objects are stored in consecutive bytes

and given address of first byte

• The amount of storage needed is determined by

its type

• Memory allocation is done as the declarations are

processed

• Data may have to be aligned (in a word) padding is

done to have alignment.
– Complier may pack the data so no padding is left
– Additional instructions may be required to execute
packed data 17
 Storage Allocation Strategies
• Static allocation: lays out storage at
compile time for all data objects

• Stack allocation: manages the runtime

storage as a stack

• Heap allocation :allocates and de-

allocates storage as needed at
runtime from heap
18
 Static allocation
• Names are bound to storage as the
program is compiled

• No runtime support is required

• Bindings do not change at run time

• On every invocation of procedure names

are bound to the same storage

• Values of local names are retained across

activations of a procedure
19
• Type of a name determines the amount of storage
to be set aside

• Address of a storage consists of an offset from

the end of an activation record

• Compiler decides location of each activation

• All the addresses can be filled at compile time

• Constraints

– Size of all data objects must be known at compile time

– Recursive procedures are not allowed

– Data structures cannot be created dynamically

20
 Stack Allocation

Sort Sort

Sort Sort
readarray readarray

Sort Sort
qsort(1,9)
readarray qsort(1,9)

Sort Sort
readarray qsort(1,9) qsort(1,9)

partition(1,9) qsort(1,3) qsort(1,3) 21

 Calling Sequence
• A call sequence
allocates an Parameter and
Return value
activation record and Control link Caller’s
Activation
enters information Links and saved values record
into its field Space for temporaries
And local data
Caller’s
responsibility Parameter and
Return value
• A return sequence Control link Callee’s
Activation
restores the state of Links and saved values record
Callee’s
the machine so that responsibility
Space for temporaries
And local data
calling procedure can
continue execution
22
 Call Sequence
• Caller evaluates the actual parameters

• Caller stores return address and other

values (control link) into callee’s
activation record

• Callee saves register values and other

status information

• Callee initializes its local data and begins

execution

23
 Return Sequence
• Callee places a return value next to
activation record of caller

• Restores registers using information in

status field

• Branch to return address

• Caller copies return value into its own

activation record
24
Long Length Data
ptr to A
ptr to B activation of P
ptr to C

array A

array B
Long length
data
array C

activation of Q

arrays of Q

25
 Variable-Length Data on
the Stack
• The run-time
memory-
management
system must deal
frequently with
the allocation of
space for objects
the sizes of which
are not known at
 Dangling references
Referring to locations which have been deallocated
main()
{int *p;
p = dangle(); /* dangling reference */
}

int *dangle();
{
int i=23;
return &i;
}
27
 Heap Allocation
• Stack allocation cannot be used if:
– The values of the local variables must be retained when
an activation ends
– A called activation outlives the caller

• In such a case de-allocation of activation

record cannot occur in last-in first-out
fashion

• Heap allocation gives out pieces of

contiguous storage for activation records
28
 Heap Allocation …
• Pieces may be de-allocated in any order

• Over time the heap will consist of alternate areas

that are free and in use

• Heap manager is supposed to make use of the free

space

• For efficiency reasons it may be helpful to handle

small activations as a special case

• For each size of interest keep a linked list of free

blocks of that size
29
 Heap Allocation …
• Fill a request of size s with block of size s′
where s′ is the smallest size greater than
or equal to s

• For large blocks of storage use heap

manager

• For large amount of storage computation

may take some time to use up memory so
that time taken by the manager may be
negligible compared to the computation
time

30
 Access to non-local names

• Scope rules determine the treatment

of non-local names

• A common rule is lexical scoping or

static scoping (most languages use
lexical scoping)

31
 Block
• A block statement contains its own data declarations

• Blocks can be nested

• The property is referred to as block structured

• Scope of the declaration is given by most closely nested rule

– The scope of a declaration in block B includes B
– If a name X is not declared in B
then an occurrence of X is in the scope of declarator X in B′
such that
• B′ has a declaration of X
• B′ is most closely nested around B

32
 Example
main()
{ BEGINNING of B0
int a=0 Scope B0, B1, B3
int b=0 Scope B0
{ BEGINNING of B1
int b=1 Scope B1, B2
{ BEGINNING of B2
int a=2 Scope B2
print a, b
} END of B2

{ BEGINNING of B3
int b=3 Scope B3
print a, b
} END of B3
print a, b
} END of B1
print a, b
} END of B0
33
 Blocks …
• Blocks are simpler to handle
than procedures
a0

• Blocks can be treated as b0

parameter less procedures
b1

• Use stack for memory a2,b3

allocation

• Allocate space for complete

procedure body at one time

34
 Lexical scope without nested
procedures
• A procedure definition cannot occur within another

• Therefore, all non local references are global and can be

allocated at compile time

• Any name non-local to one procedure is non-local to all

procedures

• In absence of nested procedures use stack allocation

• Storage for non locals is allocated statically

• A non local name must be local to the top of the stack

• Stack allocation of non local has advantage:

– Non locals have static allocations
– Procedures can be passed/returned as parameters
35
 Scope with nested procedures
Program sort; procedure quicksort(m,n:integer);
var k,v : integer;
var a: array[1..n] of integer;
x: integer; function partition(y,z:integer):
procedure readarray; integer;
var i: integer; var i,j: integer;
begin begin

end; end;
procedure exchange(i,j:integer) begin
begin .
end;
begin
end;
.
end.

36
 Nesting Depth
• Main procedure is at depth 1

• Add 1 to depth as we go from

enclosing to enclosed procedure

Access to non-local names

• Include a field ‘access link’ in the activation record

• If p is nested in q then access link of p points to

the access link in most recent activation of q

37
 sort

quicksort(1,9)

quicksort(1,3)

Stack
partition(1,3)

exchange(i,j)

38
 Access to non local names …
• Suppose procedure p at depth np refers to
a non-local a at depth na, then storage for
a can be found as
– follow (np-na) access links from the record at
the top of the stack
– after following (np-na) links we reach procedure
for which a is local

• Therefore, address of a non local a in

procedure p can be stored in symbol table
as
(np-na, offset of a in record of activation having a )

39
 How to setup access links?
• suppose procedure p at depth np calls procedure x
at depth nx.

• The code for setting up access links depends upon

whether the called procedure is nested within the
caller.
– np < nx
Called procedure is nested more deeply than p.
Therefore, x must be declared in p. The access link in
the called procedure must point to the access link of the
activation just below it

– np ≥ nx
From scoping rules enclosing procedure at the depth
1,2,… ,nx-1 must be same. Follow np-(nx-1) links from the
caller, we reach the most recent activation of the
procedure that encloses both called and calling procedure
40
 Displays
• Faster access to
non locals d[1]
d[2] s
d[3]
• Uses an array of
q(1,9)

pointers to
saved d[2]

activation records q(1,3)

saved d[2]

• Non locals at
p(1,3)
saved d[3]
depth i is in the
activation record e(1,3)

pointed to by d[i]
saved d[2]

44
 Justification for Displays
• Suppose procedure at depth j calls procedure at
depth i

• Case j < i then i = j + 1

– called procedure is nested within the caller

– first j elements of display need not be changed
– set d[i] to the new activation record

• Case j ≥ i

– enclosing procedure at depthes 1…i-1 are same and are

left un-disturbed
– old value of d[i] is saved and d[i] points to the new record
– display is correct as first i-1 records are not disturbed 45
 Dynamic Scope
• Binding of non local names to storage
do not change when new activation is
set up

• A non local name a in the called

activation refers to same storage
that it did in the calling activation

46
 Dynamic Scoping: Example
• Consider the following program

program dynamic (input, output);

var r: real;

procedure show;
begin write(r) end;

procedure small;
var r: real;
begin r := 0.125; show end;

begin
r := 0.25;
show; small; writeln;
show; small; writeln;
end.
47
 Example …
• Output under lexical scoping
0.250 0.250
0.250 0.250

• Output under dynamic scoping

0.250 0.125
0.250 0.125
48
 Implementing Dynamic Scope
• Deep Access
– Dispense with access links
– use control links to search into the stack
– term deep access comes from the fact that
search may go deep into the stack

• Shallow Access
– hold current value of each name in static
memory
– when a new activation of p occurs a local name n
in p takes over the storage for n
– previous value of n is saved in the activation
record of p

49
 Parameter Passing
• Call by value

– actual parameters are evaluated and their

rvalues are passed to the called procedure

– used in Pascal and C

– formal is treated just like a local name

– caller evaluates the actual parameters and

places rvalue in the storage for formals

– call has no effect on the activation record of

caller
50
 Parameter Passing …
• Call by reference (call by address)

– the caller passes a pointer to each

location of actual parameters

– if actual parameter is a name then lvalue

is passed

– if actual parameter is an expression then

it is evaluated in a new location and the
address of that location is passed
51
 Parameter Passing …
• Copy restore (copy-in copy-out, call
by value result)

– actual parameters are evaluated, rvalues

are passed by call by value, lvalues are
determined before the call

– when control returns, the current

rvalues of the formals are copied into
lvalues of the locals
52
 Parameter Passing …
• Call by name (used in Algol)

– names are copied

– local names are different from names of

calling procedure

swap(i,a[i])
temp = i
i = a[i]
a[i] = temp
53
 Language Facility for
Dynamic Storage Allocation
• Storage is usually taken from heap

• Allocated data is retained until deallocated

• Allocation can be either explicit or implicit

– Pascal : explicit allocation and de-allocation by

new() and dispose()

– Lisp : implicit allocation when cons is used, and

de-allocation through garbage collection
54
 Dynamic Storage Allocation
new(p); p^.key:=k; p^.info:=i;

head 76 3 4 2 7 9 nil

Garbage : unreachable cells

•Lisp does garbage collection
•Pascal and C do not

head^.next := nil;
Dangling reference
dispose(head^.next )
55
 Explicit Allocation of Fixed
Sized Blocks
• Link the blocks in a list

• Allocation and de-allocation can be done with very

little overhead
available

allocated

available

allocated

56
 Explicit Allocation of Fixed
Sized Blocks …
• blocks are drawn from contiguous area of storage

• An area of each block is used as pointer to the next block

• A pointer available points to the first block

• Allocation means removing a block from the available list

• De-allocation means putting the block in the available list

• Compiler routines need not know the type of objects to be

held in the blocks

• Each block is treated as a variant record

57
 Explicit Allocation of Variable
Size Blocks
• Storage can become fragmented
• Situation may arise
• If program allocates five blocks
• then de-allocates second and fourth block

free free free

• Fragmentation is of no consequence if blocks

are of fixed size
• Blocks can not be allocated even if space is
available
58
 First Fit Method
• When a block of size s is to be
allocated
– search first free block of size f ≥ s
– sub divide into two blocks of size s and
f-s
– time overhead for searching a free block
• When a block is de-allocated
– check if it is next to a free block
– combine with the free block to create a
larger free block
59
 Implicit De-allocation
• Requires co-operation
between user program Block size

and run time system

Reference count

• Run time system needs mark

to know when a block

Pointers to blocks
is no longer in use

• Implemented by fixing User info

the format of storage
blocks

60
Recognizing Block boundaries
• If block size is fixed then position information can be used

• Otherwise keep size information to determine the block

boundaries

Whether Block is in Use

• References may occur through a pointer or a sequence of
pointers

• Compiler needs to know position of all the pointers in the

storage

• Pointers are kept in fixed positions and user area does not
contain any pointers
61
 Reference Count
• Keep track of number of blocks which point
directly to the present block

• If count drops to 0 then block can be de-

allocated

• Maintaining reference count is costly

– assignment p:=q leads to change in the reference counts

of the blocks pointed to by both p and q

• Reference counts are used when pointers do not

appear in cycles
62
 Marking Techniques
• Suspend execution of the user program

• use frozen pointers to determine which blocks are in use

• This approach requires knowledge of all the pointers

• Go through the heap marking all the blocks unused

• Then follow pointers marking a block as used that is

reachable

• De-allocate a block still marked unused

• Compaction: move all used blocks to the end of heap. All

the pointers must be adjusted to reflect the move 63
Run Time Storage Management
• Run time allocation and de-allocation of activations
occurs as part of procedure call and return
sequences

• Assume four kind of statements:

call, return, halt and action

0: return address
/ *code for c */ 0: return address
action –1 8: 4:
call p
arr buf
action -2
halt
j
/ *code for p */ 56:
action –3 60: i
84: n
return
Activation record for c Activation record for
(64 bytes) p (88 bytes)
Three address code 64
 Static Allocation
• A call statement is implemented by a
sequence of two instructions

• A move instruction saves the return

address

• A goto transfers control to the target

code

• The instruction sequence is

MOV #here+20, callee.static-area
GOTO callee.code-area 65
 Static Allocation …
• callee.static-area and callee.code-area are
constants referring to address of the
activation record and the first address of
called procedure respectively.

• #here+20 in the move instruction is the

return address; the address of the
instruction following the goto instruction

• A return from procedure callee is

implemented by

GOTO *callee.static-area
66
 Example
• Assume each action 100: ACTION-l
block takes 20 bytes 120: MOV 140, 364
of space 132: GOTO 200
140: ACTION-2
• Start address of 160: HALT
code for c and p is :
100 and 200 200: ACTION-3
220: GOTO *364
:
• The activation 300:
records are statically 304:
allocated starting at :
addresses 300 and 364:
364. 368:

67
 Stack Allocation
• Position of the activation record is not known until
run time

• Position is stored in a register at run time, and

words in the record are accessed with an offset
from the register

• The code for the first procedure initializes the

stack by setting up SP to the start of the stack
area

MOV #Stackstart, SP
code for the first procedure
HALT

68
 Stack Allocation …
• A procedure call sequence increments
SP, saves the return address and
transfers control to the called
procedure

ADD #caller.recordsize, SP
MOVE #here+ 16, *SP
GOTO callee.code_area

69
 Stack Allocation …
• The return sequence consists of two parts.

• The called procedure transfers control to the return

address using

GOTO *0(SP)

0(SP) is the address of the first word in the activation

record and *0(SP) is the return address saved there.

• The second part of the return sequence is in caller which

decrements SP

SUB #caller.recordsize, SP

70
 Example
• Consider the quicksort action-l /* code for s * /
program
call q
• Assume activation action-2
records for procedures halt
s, p and q are ssize, psize
and qsize respectively
(determined at compile action-3 /* code for p * /
time) return

• First word in each action-4 /* code for q * /

activation holds the
return address call p
action-5
• Code for the procedures call q
start at 100, 200 and action-6
300 respectively, and call q
stack starts at 600.
return
71
100: MOVE #600, SP 300: action-4
108: action-1 320: ADD #qsize, SP
128: ADD #ssize, SP 328: MOVE 344, *SP
136: MOVE 152, *SP 336: GOTO 200
144: GOTO 300 344: SUB #qsize, SP
152: SUB #ssize, SP 352: action-5
160: action-2 372 ADD #qsize, SP
180: HALT 380: MOVE 396, *SP
... 388: GOTO 300
396 SUB #qsize, SP
200: action-3 404: action-6
220: GOTO *0(SP) 424: ADD #qsize, SP
... 432: MOVE 448, *SP
440: GOTO 300
448: SUB #qsize, SP
456: GOTO *0(SP)

72