1

Run-Time Administration: Implementation

of simple stack allocation scheme, storage
allocation in block structured language
 Run-time Storage
2

Run-Time Environment
Storage Organization
Storage Allocation Strategies
Dynamic Storage Allocation
 Run-Time Environments
3

 The compiler must implement various abstractions in the source

language definition such as
□ Names used in a program

□ Define the scope of variables

□ Data types

□ Operators

□ Procedures

□ Parameters and

□ Flow of control constructs.

 The compiler must co-operate with operating system and other

systems software to support the implementation of these
abstractions on the target machine. This can be done by the
compiler by creating run-time environment.
 Run-Time Environments
4

What is run-time environment in compiler design?

 A run-time environment in compiler design deals variety of issues

such as:
1. Managing the processor stack.
2. Layout and allocation of memory for various variables used in the
source program.
3. Instructions to copy the actual parameters on top of the stack
when a function is called.
4. Allocating and de-allocating the memory dynamically with the
help of operating system.
5. The mechanism used by the target program to access variables.
6. The mechanism to pass parameters.
7. The interfaces to the operating system, input/output devices and
other programs.
 Run-Time Environments
5

 A lot has to happen at run time to get your program running.

 At run time, we need a system to map NAMES (in the source
program) to STORAGEon the machine.
 Allocation and deallocation of memory is handled by a RUN-
TIMESUPPORTSYSTEMtypically linked and loaded along
with the compiled target code.
 One of the primary responsibilities of the run-time system is to
manage ACTIVATIONS of procedures.
 Run-Time Environments
6

 For allocating memory to data items, the following information

is required:
1. Size of data item
2. The type of data item
3. Dimensions of the data item
4. Scope of the data item
 Run-Time Environments
7

 The organization of data objects in memory depends on the

source language features:
1. Recursion
2. Parameter passing mechanism
3. Local names
4. Non-local names
5. Dynamic data structures
 Run-time Storage
8

Run-Time Environment
Storage Organization
Storage Allocation Strategies
Dynamic Storage Allocation
 Storage Organization
9

 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
10

 PASCALand C use extensions of the

code for function 1 control stack to manage activations of
code for function 2
procedures
. ..
code for function n
 Stack contains information about register
values, value of program counter and
global / static area
data objects whose lifetimes are
contained in that of an activation
stack  Heap holds all other information. For
example, activations that cannot be
represented as a tree.
free space
 By convention, stack grows down and the
top of the stack is drawn towards the
bottom of this slide (value of top is usually
heap
kept in a register)
 Runtime Memory
11

code for function 1 code for function 1

code for function 2 code for function 2

. .. . ..

code for function n code for function n

global / static area global / static area

stack stack
Stack grows
free space free space

heap heap
 Activation Record
12

 Information needed by a single

execution of a procedure is managed
returned value
using an activation record or frame
 Not all compilers use all of the actual parameters
fields optional control link
 Pascal and C push activation record
on the runtime stack when procedure optional access link
is called and pop the activation saved machine status
record off the stack when control
returns to the caller local data

temporaries

Fig: A typical Activation Record

 Activation Record
13

1) Temporary values returned value

Ex. those arising in the evaluation of
expressions actual parameters
2) Local data optional control link
Data that is local to an execution of the
procedure optional access link
3) Saved machine status
saved machine status
State of the machine info before
procedure is called. Values of program local data
counter and machine registers that have
to be restored when control returns from temporaries
the procedure
 Activation Record
14

4) Access Link
refer to non-local data held in other returned value
activation records actual parameters
5) Control link
optional control link
points to the activation record of the caller
6) Actual parameters optional access link
used by the calling procedure to supply
saved machine status
parameters to the called procedure
(in practice these are passed in registers) local data
7) Returned value temporaries
used by the called procedure to return a
value to the calling procedure
(in practice it is returned in a register)
 Local data
15

 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
 Run-time Storage
16

Run-Time Environment
Storage Organization
Storage Allocation Strategies
Dynamic Storage Allocation
 Organization of storage
17

 Fixed-size objects can be

placed in predefined
locations.
 The heap and the stack
need room to grow,
however.
 Run-time stack and heap
18

 The STACK is used to store:

 Procedure activations.

 The status of the machine just before calling a procedure, so

that the status can be restored when the called procedure
returns.
 The HEAPstores data allocated under program control
 Storage Allocation Strategies
19

 The various storage allocation strategies to allocate storage in

different data areas of memory are:
1. Static Allocation
• Storage is allocated for all data objects at compile time
2. Stack Allocation
• The storage is managed as a stack
3. Heap Allocation (It is one of Dynamic Storage Allocation)
• The storage is allocated and deallocated at runtime from a
data area known as heap
 Static Allocation
20

 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
21

 Statically allocated names are bound to relocatable storage

at compile time.
 Storage bindings of statically allocated names never change.
 The compiler usesthe type of a name (retrieved from the
symbol table) to determine storage size required.
 The required number of bytes (possibly aligned) is set aside
for the name.
 The relocatable address of the storage is fixed at compile
time.
 Static Allocation
22

int i = 10;
code for function 1
int f(int j) code main() code for function 2
{ . ..
int k; code f() code for function n
int m;
… i (int)
} global / static area
main() stack
main() Activation
{ record k (int)
int k;
f(k); free space
} f()
Activation
record k (int)
m (int)
heap
 Static allocation
23

 Limitations:
□ The size required must be known at compile time.

□ Recursive procedures cannot be implemented statically.

□ No data structure can be created dynamically as all data is

static.
 Stack-based Allocation
24

 In a stack-based allocation, the previous restrictions are lifted

(Pascal, C, etc)
 procedures are allowed to be called recursively
o Need to hold multiple activation records for the same
procedure
o 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
 Stack-dynamic allocation
25

 Storage is organized as a stack.

 Activation records are pushed and popped.
 Locals and parameters are contained in the activation records
for the call.
 This means locals are bound to fresh storage on every call.
 We just need a stack_top pointer.
 Toallocate a new activation record, we just increase stack_top.
 Todeallocate an existing activation record, we just decrease
stack_top.
 Address generation in stack allocation
31

 The position of the activation record on the stack cannot be

determined statically.
 Therefore the compiler must generate addresses RELATIVEto
the activation record.
 We generate addresses of the form
stack_top + offset
 Calling Sequences
32

 Procedure calls are implemented by

returned value
generating calling sequences in the target
code actual parameters

□ Call sequence: allocates activation optional control link

record and enters information into fields
optional access link
□ Return sequence: restores the state of
the machine so that the calling saved machine status
procedure can continue execution local data

temporaries
 Calling Sequences
33

 Why placing returned value and returned value

actual parameters next to the actual parameters

optional control link
activation record of the caller?
optional access link caller
□ Caller can access these values saved machine status

using offsets from its own local data

activation record temporaries

returned value
□ No need to know the middle part
actual parameters
of the callee’s activation record
optional control link
optional access link callee
saved machine status

local data

temporaries
 Calling Sequences
34

 How do we calculate offset? returned value

□ Maintain a register that actual parameters

points to the end of the optional control link

machine status field in an optional access link caller

saved machine status
activation record
local data
□ Top_sp is known to the caller,
temporaries
so it can be responsible for returned value
setting it before control flows actual parameters
to the called procedure optional control link
□ Callee can access its optional access link callee
temporaries and local data top_sp saved machine status
using offsets from top_sp local data

temporaries
 Call Sequence
35

 The caller evaluates actuals

 The caller
□ stores a return address and the old value of top_sp into the
callee’s activation record
□ increments top_sp; that is moved past the caller’s local
data and temporaries and the callee’s parameter and
status fields
 The callee
□ saves register values and other status information
 The callee
□ initializes its local data and begins execution
 Return Sequence
36

 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 caller’s 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
 Example of variable- length data
38

 All variable-length data is

pointed to from the local data
area.
 Stack Allocation Advantages and Disadvantages
39

Advantages:
 It supports recursion as memory is always allocated on block

entry.
 It allows to create data structures dynamically.

 It allows an array declaration like A(I, J), since actual

allocation is made only at execution time. The dimension

bounds need not be known at compile time.
Disadvantages:
 Memory addressing has to be effected through pointers and

index registers which may be store them, static allocation

especially in case of array reference.
 Heap Allocation
40

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
 Heap Allocation
41

There are two aspects of dynamic allocation :

 Runtime allocation and de-allocation of data structures

 Languages like Algol have dynamic data structures and it

reserves some part of memory for it.

If a procedure wants to put a value that is to be used after its activation

is over then we cannot use stack for that purpose. That is language like
Pascal allows data to be allocated under program control. Also in
certain language a called activation may outlive the caller procedure. In
such a case last-in-first-out queue will not work and we will require a
data structure like heap to store the activation. The last case is not true
for those languages whose activation trees correctly depict the flow of
control between procedures.
 Heap Allocation
42

 Some languages do not have tree-structured allocations.

 In these cases, activations have to be allocated on the heap.
 This allows strange situations, like callee activations that live
longer than their callers’ activations.
 This is not common.
 Heap Allocation
46

 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 useof 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
 Heap Allocation
47

 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
 Heap Allocation
48

 For efficiency reasons we can handle small activations and

activations of predictable size as a special case as follows:
1. For each size of interest, keep a linked list if free blocks of that
size
2. If possible, fill a request for size s with a block of size s', where s'
is the smallest size greater than or equal to s. When the block is
eventually de-allocated, it is returned to the linked list it came
from.
3. For large blocks of storage use the heap manger.
Heap manger will dynamically allocate memory. This will come with a
runtime overhead. As heap manager will have to take care of
defragmentation and garbage collection. But since heap manger saves
space otherwise we will have to fix size of activation at compile time,
runtime overhead is the price worth it.
 Access to non-local names
49

 Scope rules determine the treatment of non-local names

 A common rule is lexical scoping or static scoping (most
languages use lexical scoping)
 The scope rules of a language decide how to reference the
non-local variables. There are two methods that are commonly
used:
1. Static or Lexical scoping: It determines the declaration that
applies to a name by examining the program text alone. E.g.,
Pascal, C andADA.
2. Dynamic Scoping: It determines the declaration applicable to
a name at run time, by considering the current activations.
E.g., Lisp
 Lexical scope without nested procedures
55

 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

 Lexical scope without nested procedures
56

 In languages like C nested procedures are not allowed. That is, you
cannot define a procedure inside another procedure. So, if there is a
non- local reference to a name in some function then that variable must
be a global variable. The scope of a global variable holds within all the
functions except those in which the variables have been re- declared.
Storage for all names declared globally can be allocated statically. Thus
their positions will be known at compile time. In static allocation, we use
stack allocation. Any other name must be a local of the activation at the
top of the stack, accessible through the top pointer. Nested procedures
cause this scheme to fail because a non-local may then refer to a local of
parent variable which may be buried deep in the stack and not at the
top of stack. An important benefit of static allocation for non- locals is
that declared procedures can freely be passed as parameters and
returned as results (a function is passed in C by passing a pointer to it).
 Procedure Parameters
65
program param (input,output);
procedure b( function h(n:integer): integer);
begin
writeln (h(2))
end;
procedure c;
var m: integer;
function f(n: integer): integer;
begin
f := m + n
end;
begin
m :=0; b(f)
end;
begin
c
end.
 Dynamic Scope
70

 Binding of non local names to storage do not change when new

activation is setup
 A non local name a in the called activation refers to same
storage that it did in the calling activation

 In dynamic scope , a new activation inherits the existing

bindings of non local names to storage. A non local name a
in the called activation refers to the same storage that it did
in the calling activation. New bindings are set up for the
local names of the called procedure, the names refer to
storage in the new activation record.
 Dynamic Scoping: Example
71
 Dynamic Scoping: Example
72

 Output under lexical scoping

0.250 0.250
0.250 0.250
 Output under dynamic scoping
0.250 0.125
0.250 0.125
 The outputs under the lexical and the dynamic scoping are as
shown. Under dynamic scoping, when show is called in the main
program, 0.250 is written because the variable r local to the
main program is used. However, when show is called from within
small, 0.125 is written because the variable r local to small is
used.
 Implementing Dynamic Scope
73

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
 Implementing Dynamic Scope
74

We will discuss two approaches to implement dynamic scope. They bear

resemblance to the use of access links and displays, respectively, in the
implementation of the lexical scope.
1. Deep Access : Dynamic scope results if access links point to the same
activation records that control links do. A simple implementation is to
dispense with access links and use control links to search into the stack,
looking for the first activation record containing storage for the non- local
name. The term deep access comes from the fact that search may go
deep into the stack. The depth to which the search may go depends on the
input of the program and cannot be determined at compile time.
2. Shallow Access : Here the idea is to hold the current value of each name in
static memory. When a new activation of a procedure p occurs, a local
name n in p takes over the storage for n. The previous value of n is saved
in the activation record for p and is restored when the activation of p
ends.
 Parameter Passing
75

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

 This is, in a sense, the simplest possible method of passing

 Parameter Passing
76

Call by value
 This is, in a sense, the simplest possible method of passing

parameters. The actual parameters are evaluated and their r-

values are passed to the called procedure. Call-by-value is
used in C, and Pascal parameters are usually passed this way.
Call-by-Value can be implemented as follows:
1. A formal parameter is treated just like a local name, so the
storage for the formals is in the activation record of the called
procedure.
2. The caller evaluates the actual parameters and places their r-
values in the storage for the formals. A distinguishing feature
of call-by-value is that operations on the formal parameters
do not affect values in the activation record of the caller.
 Parameter Passing
77

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

 Parameter Passing
78

Call by reference (call by address)

 When the parameters are passed by reference (also known as

call-by-address or call-by location), the caller passes to the

called procedure a pointer to the storage address of each
actual parameter.
1. If an actual parameter is a name or an expression having an l-
value, then that l-value itself is passed.
2. However, if the actual parameter is an expression, like a + b
or 2, that has no l-value, then the expression is evaluated in a
new location, and the address of that location is passed.
 A reference to a formal parameter in the called procedure

becomes, in the target code, an indirect reference through the

pointer passed to the called procedure.
 Parameter Passing
79

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

 Parameter Passing
80

Copy restore (copy-in copy-out, call by value result)

 This is a hybrid form between call-by-value and call-by-

reference (also known as copy-in copy-out or value-result).

1. Before control flows to the called procedure, the actual
parameters are evaluated. The r-values of the actuals are
passed to the called procedure as in call-by-value. In
addition, however, the l-values of those actual parameters
having l-values are determined before the call.
2. When the control returns, the current r-values of the formal
parameters are copied back into the l-values of the actuals,
using the l-values computed before the call. Only the actuals
having l-values are copied.
 Parameter Passing
81

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
 Parameter Passing
82

Call by name (used in Algol)

 This is defined by the copy-rule as used in Algol.

1. The procedure is treated as if it were a macro; that is, its body

is substituted for the call in the caller, with the actual
parameters literally substituted for the formals. Such a literal
substitution is called macro-expansion or inline expansion.
2. The local names of the called procedure are kept distinct from
the names of the calling procedure. We can think of each local
of the called procedure being systematically renamed into a
distinct new name before macro-expansion is done.
3. The actual parameters are surrounded by parentheses if
necessary to preserve their integrity.
 Run-time Storage
83

Run-Time Environment
Storage Organization
Storage Allocation Strategies
Dynamic Storage Allocation
 Dynamic Allocation
84

 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 suchrestriction
□ 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
85

 Use a heap to maintain these records

□ Also called free store

□ Heap management is challenging

 Language Facility for Dynamic Storage Allocation
86

 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
 Dynamic Storage Allocation
89
 Dynamic Storage Allocation
90

Generally languages like Lisp and MLwhich do not allow for explicit de-allocation
of memory do garbage collection. A reference to a pointer that is no longer
valid is called a 'dangling reference'. For example, consider this C code:
int main (void)
{
int* a=fun();
}
int* fun()
{
int a=3;
int* b=&a;
return b;
}
Here, the pointer returned by fun() no longer points to a valid address in
memory as the activation of fun() has ended. This kind of situation is called
a 'dangling reference'. In case of explicit allocation it is more likely to
happen as the user can de-allocate any part of memory, even something
that has to a pointer pointing to a valid piece of memory.
 Dynamic Storage Allocation
91

Explicit Allocation of Fixed Sized Blocks

 Link the blocks in a list
 Allocation and de-allocation can be done with very little overhead
 The simplest form of dynamic allocation involves blocks of
a fixed size.
 By linking the blocks in a list, as shown in the figure, allocation
and de-allocation can be done quickly with little or no storage
overhead.
 Dynamic Storage Allocation
92

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
 Dynamic Storage Allocation
93

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

• Fragmentation is of no consequence if blocks are of fixed size

• Blocks can not be allocated even if space is available
 Dynamic Storage Allocation
94

First Fit Method

When a block of size sis to be allocated
- search first free block of size f ≥ s
- sub divide into two blocks of size sand 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
 Dynamic Storage Allocation
95

Implicit De-allocation
 Requires co-operation between user program and run
time system
 Runtime system needs to know when a block is no longer in use
 Implemented by fixing the format of storage blocks
 Implicit deallocation requires cooperation between the user
program and run time package,