Run-Time Environments

Acknowledgement
• Alfred V Aho, Monica S. Lam, Ravi Sethi, Jeffrey D Ullman-
“Compilers- Principles, Techniques and Tools”

Dr. Girish Kumar Patnaik 2

 Run-Time Environments
• Compiler creates and manages a ‘run-time environment in
which it assumes its target programs are being executed.
• This environment deals with a variety of issues such as
– layout and allocation of storage locations for the objects named
in the source program,
– mechanisms used by the target program to access variables,
– linkages between procedures,
– mechanisms for passing parameters,
– interfaces to the operating system, input/output devices, and
other programs

Dr. Girish Kumar Patnaik 3

 Storage Organization
• From the perspective of the compiler writer, 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.

Dr. Girish Kumar Patnaik 4

 Storage Organization
• subdivision of run-time memory into code and data areas

Dr. Girish Kumar Patnaik 5

 Storage Organization
• The size of the generated code is fixed at compile time, so
the compiler can place the executable target code in a
statically determined area Code, usually in the low end of
memory.
• The size of some program data objects, such as global
constants, and data generated by the compiler, such as
information to support garbage collection, may be known
at compile time, and these data objects can be placed in
another statically determined area called Static.

Dr. Girish Kumar Patnaik 6

 Storage Organization
• Stack grows towards lower addresses, the heap
towards higher.
• These areas are dynamic; their size can change as the
program executes.
• The stack is used to store data structures called
activation records that get generated during procedure
calls
• The heap is used to manage allocatation and
deallocatation data under program control
Dr. Girish Kumar Patnaik 7
 Static Versus Dynamic Storage
Allocation
• Storage-allocation decision is static, if it can be made by the
compiler looking only at the text of the program
• A decision is dynamic if it can be decided only while the
program is running
• Two strategies for dynamic storage allocation:
– Stack storage: Names local to a procedure are allocated space
on a stack.
– Heap storage: Data that may outlive the call to the procedure
that created it is usually allocated on a "heap" of reusable
storage.

Dr. Girish Kumar Patnaik 8

 Stack Allocation of Space
• Each time a procedure is called, space for its local variables
is pushed onto a stack, and when the procedure
terminates, that space is popped off the stack.
• Allows space to be shared by procedure calls whose
durations do not overlap in time, but it allows us to
compile code for a procedure in such a way that the
relative addresses of its nonlocal variables are always the
same, regardless of the sequence of procedure calls.

Dr. Girish Kumar Patnaik 9

 Activation Tree
• An activation tree is a tree that depicts the
way control enters and leaves activations
– Each node represents an activation
– The root represents the main program
– Node for a is parent of node for b iff control flows
from activation a to b
– Node for a is to the left of node for b iff the
lifetime of a occurs before that of b
Dr. Girish Kumar Patnaik 10
 Procedure Activations: Example
program sort(input, output)
var a : array [0..10] of integer; Activations:
procedure readarray; begin sort
var i : integer;
begin enter readarray
for i := 1 to 9 do read(a[i]) leave readarray
end;
function partition(y, z : integer) : integer enter quicksort(1,9)
var i, j, x, v : integer; enter partition(1,9)
begin …
end
leave partition(1,9)
procedure quicksort(m, n : integer); enter quicksort(1,3)
var i : integer;
begin
…
if (n > m) then begin leave quicksort(1,3)
i := partition(m, n); enter quicksort(5,9)
quicksort(m, i - 1);
quicksort(i + 1, n) …
end leave quicksort(5,9)
end;
begin leave quicksort(1,9)
a[0] := -9999; a[10] := 9999; end sort.
readarray;
quicksort(1, 9) Dr. Girish Kumar Patnaik 11
end.
 Activation Trees: Example
s
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 for the sort program

Note: also referred to as the dynamic call graph
Dr. Girish Kumar Patnaik 12
 Run-Time Stack
• At run-time, function calls behave in a stack-like manner
– when you call, you push the return address onto the run-time
stack
– when you return, you pop the return address from the stack
– reason: a function may be recursive
• When you call a function, inside the function body, you
want to be able to access
– formal parameters
– variables local to the function
– variables belonging to an enclosing function (for nested
functions)
Dr. Girish Kumar Patnaik 13
 Activation Records (Frames)
• When we call a function, we push an entire frame onto the
stack A
• The frame contains
– the return address from the function B
– the values of the local variables
– temporary workspace
– ... C
• The size of a frame is not fixed top
– need to chain together frames into a list
(via dynamic link)
– need to be able to access the variables of
the enclosing functions efficiently

Dr. Girish Kumar Patnaik 14

 Activation Records
fp
(frame pointer) Returned value
Actual parameters
Caller’s
Optional control link responsibility
to initialize
Optional access link
Save machine status
Local data Callee’s
responsibility
Temporaries to initialize

Dr. Girish Kumar Patnaik 15

 Activation Records
• Temporaries: Temporary values, such as those
arising in the evaluation of expressions, are stored
• Local data: Holds data that is local to a procedure
• Saved Machine Status: Holds information about the
state of the machine just before the procedure is
called. Holds values of Program Counter and
machine registers that have to be restored when
control returns from the procedure.
Dr. Girish Kumar Patnaik 16
 Activation Records
• Optional Access Link: refer to nonlocal data held in
other activation records
• Optional Control Link: Points to the activation
record of the caller
• Actual Parameters: Calling procedure supply
parameters to the called procedure
• Returned Value: Called procedure return a value to
the calling procedure
Dr. Girish Kumar Patnaik 17
 Procedure Activations: Example
program sort(input, output)
var a : array [0..10] of integer; Activations:
procedure readarray;
var i : integer; begin sort
begin enter readarray
for i := 1 to 9 do read(a[i])
end; leave readarray
function partition(y, z : integer) : integer enter quicksort(1,9)
var i, j, x, v : integer;
begin … enter partition(1,9)
end leave partition(1,9)
procedure quicksort(m, n : integer);
var i : integer; enter quicksort(1,3)
begin …
if (n > m) then begin
i := partition(m, n); leave quicksort(1,3)
quicksort(m, i - 1); enter quicksort(5,9)
quicksort(i + 1, n)
end …
end; leave quicksort(5,9)
begin
a[0] := -9999; a[10] := 9999; leave quicksort(1,9)
readarray;
quicksort(1, 9)
end sort.
end.
Dr. Girish Kumar Patnaik 18
Dr. Girish Kumar Patnaik 19
 Calling Sequences
• Procedure calls are implemented by what are
known as calling sequences, which consists of
code that allocates an activation record on the
stack and enters information into its fields.
• A return sequence is similar code to restore the
state of the machine so the calling procedure can
continue its execution after the call
Dr. Girish Kumar Patnaik 20
 Calling Sequences
• Calling sequences and the layout of activation
records may differ greatly
• If a procedure is called from n different
points, then the portion of the calling
sequence assigned to the caller is generated n
times. However, the portion assigned to the
callee is generated only once.
Dr. Girish Kumar Patnaik 21
 Calling Sequences
• When designing calling sequences and the layout of
activation records, the following principles are helpful:
– Values communicated between caller and callee are generally
placed at the beginning of the callee's activation record, so
they are as close as possible to the caller's activation record.
– Fixed-length items are generally placed in the middle
– Items whose size may not be known early enough are placed at
the end of the activation record
– Locate the top-of-stack pointer to have it point to the end of
the fixed-length fields in the activation record.

Dr. Girish Kumar Patnaik 22

Calling Sequences

Dr. Girish Kumar Patnaik 23

 Variable-Length Data on the Stack
• For objects the sizes of which are not known at
compile time, but which are local to a procedure and
thus may be allocated on the stack.
• The reason to prefer placing objects on the stack if
possible is that we avoid the expense of garbage
collecting their space.
• Stack can be used only for an object if it is local to a
procedure and becomes inaccessible when the
procedure returns.
Dr. Girish Kumar Patnaik 24
Variable-Length
Data on the Stack
• A pointer to the
beginning of each
array appears in the
activation record
itself.
• Activation record for
q begins after the
arrays of p

Dr. Girish Kumar Patnaik 25