© Kenneth C. Louden, 20031 Chapter 8 - Control II: Procedures and Environments Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.

© Kenneth C. Louden, 2003 1

Chapter 8 - Control II: Chapter 8 - Control II: Procedures and EnvironmentsProcedures and Environments

Programming Languages:

Principles and Practice, 2nd Ed.

Kenneth C. Louden

Chapter 8 K. Louden, Programming Languages 2

Three major parts of a runtime Three major parts of a runtime environment:environment: Static area allocated at load/startup time.

Examples: global/static variables and load-time constants.

Stack area for execution-time data that obeys a last-in first-out lifetime rule. Examples: nested declarations and temporaries.

Heap or dynamically allocated area for "fully dynamic" data, i.e. data that does not obey a LIFO rule. Examples: objects in Java, lists in Scheme.


Procedures/functions and the Procedures/functions and the environmentenvironment Local data in a procedure/function is typically

allocated in a contiguous area of the environment, called an activation record or frame ("activation" means "used during a call"):

© 2003 Brooks/Cole - Thomson Learning™


Languages and EnvironmentsLanguages and Environments Languages differ on where activation

records must go in the environment:– Fortran is static: all data, including activation

records, are statically allocated. (Each function has only one activation record—no recursion!)

– Functional languages (Scheme,ML) and some OO languages (Smalltalk) are heap-oriented: all (or almost all) data, including activation records, are allocated dynamically.

– Most languages are in between: data can go anywhere (depending on its properties); activation records go on the stack.


Simple stack-based allocationSimple stack-based allocation Described in Chapter 5. Nested declarations are added to the stack as their

code blocks are entered, and removed as their code blocks are exited.

Example: Stack at Point 1:{ int x; int y; { int z; } { int w; // Point 1 }}

x

y

w


Activation records and the stackActivation records and the stack Frames can be kept on the

stack (C, Java) if access to the local environment (frame) ends with the call.

To facilitate popping of frames, a control link is added to the activation record that records the position of the calling activation, so a pop can be done in one operation.


A pointer to the current frame is also kept, called the environment pointer, or ep (could be the stack pointer).

New piece


Example (C):Example (C):int x;

void p( int y)

{ int i = x;

char c; ...

}

void q ( int a)

{ int x;

p(1);

}

main()

{ q(2);

return 0;

}


Environment stack during exec of Environment stack during exec of pp::


Note: the ep in this picture actually points to the "bottom" of the frame, as do the control links (which are stored old ep values), so ep top of stack.


Local variable access using the epLocal variable access using the ep In a typical language with a stack-based runtime

environment, the local declarations in a procedure are fixed at compile-time, both in size and in sequence.

This information can be used to speed up accesses to local variables, by precomputing these locations as offsets from the ep.

Then the local frame need not have a name-based lookup operation (unlike the symbol table).

In fact, names can be dispensed with altogether. The next slide shows how that would look for the

procedure p of slide 7.


Activation record of Activation record of pp::



Non-local variable accessNon-local variable access Requires that the environment be able to identify

frames representing enclosing scopes. Using the control link results in dynamic scope

(and also kills the fixed-offset property). If procedures can't be nested (C, C++, Java), the

enclosing scope is always locatable by other means: it is either global/static (accessed directly) or belongs to the current object (accessed through the this pointer).

If procedures can be nested (Ada, Pascal), to maintain lexical scope a new link must be added to each frame: the access link, pointing to the activation of the defining environment of each procedure.


Example (Ada):Example (Ada):procedure q is

x: integer;

procedure p (y: integer) is

i: integer := x;

begin ...

end p;

procedure r is

x: float;

begin

p(1);...

end r;

begin

r;

end q;


Environment during exec of Environment during exec of pp::



Procedure values as pointer pairsProcedure values as pointer pairs With nested procedures in lexically scoped

languages requiring an access link, when a procedure is called, this access link must be available at the point of call. One way it can be is for the procedure itself to record its access link (necessary if procedures can be parameters).

Then each procedure becomes a pair of pointers: a code pointer (called the instruction pointer or ip in the text), and an environment pointer (ep in the text) pointing to the definition environment of the procedure (which will become the access link during a call).

Such an <ep,ip> pair is sometimes called a closure.


Example (Ada):Example (Ada):procedure lastex is

procedure p(n: integer) is

procedure show is

begin

if n > 0 then p(n - 1); end if;

put(n);

new_line;

end show;

begin -- p

show;

end p;

begin -- lastex

p(1);

end lastex;


Environment during 2nd call to Environment during 2nd call to showshow::

Note 2nd show has a different access link


Fully dynamic environmentsFully dynamic environments Languages with lambdas or where functions can

be created locally and returned from a call (ML, Scheme).

Activation records cannot in general be popped after a call. Thus, activations no longer behave as LIFO structures and must be allocated in the heap.

Control links make little sense, since each control link might have to point far back in the stack.

Access links and closures still make perfect sense, however.


Example (Scheme–simplified from Example (Scheme–simplified from Chapter 11, see also page 338):Chapter 11, see also page 338):

(define (makeNewBalance balance)

(define (withdraw amt)

(set! balance (- balance amt))

balance)

withdraw)

(define withdraw1 (makeNewBalance 500))

(define withdraw2 (makeNewBalance 100))


defining environment : makeNewBalance: <ep,ipm>

. . . withdraw1: withdraw2: <ep1,ipw> <ep2,ipw>

control link access link balance: 500 withdraw: <ep1,ipw>

control link access link balance: 100 withdraw: <ep2,ipw>

(activation record of 1st call to makeNewBalance)

(activation record of 2nd call to makeNewBalance)

Scheme example, continuedScheme example, continued Environment at end of previous code (see also

page 339):


defining environment : makeNewBalance: <ep,ipm>

. . . withdraw1: withdraw2: <ep1,ipw> <ep2,ipw>

access link balance: 300 withdraw: <ep1,ipw>

access link balance: 100 withdraw: <ep2,ipw>

access link amt: 200 (activation record of

call to withdraw1)

Scheme example, concludedScheme example, concluded Environment just before exiting the call

(withdraw1 200):

© Kenneth C. Louden, 20031 Chapter 8 - Control II: Procedures and Environments Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.

Documents