CS 334
Programming Languages
Spring 2000

Lecture 10

Type completeness principle:

No operation should be arbitrarily restricted in the types of the values involved.

Avoid second-class types.

Ex. in Pascal: Restrictions on return values of functions, lack of procedure variables, etc.

ML comes much closer to satisfying.

Summary of types so far:

postpone ADT's until later

Modern tendency to strengthen static typing and avoid implicit holes in types system.

- usually explicit (dangerous ) means for bypassing types system, if desired

Try to push as many errors to compile time as possible by:

Requiring overspecification through typing
Distinguishing btn diff. uses of same types (name equiv.)
Mandating constructs designed to eliminate typing holes
Minimizing or eliminating use of explicit pointers (esp. user-controlled deallocation of ptrs).

Problem: loss of flexibility which obtainable from dynamic typing or lack of any typing.

Important direction of current research in computer science:

Provide type safety, but increase flexibility.

Important progress over last 20 years:

Polymorphism, ADT's, Subtyping & other aspects of object-oriented languages.

STORAGE

What are storable values of language? Those that cannot be selectively updated.

Varies between languages.

Pascal: primitive (integer, real, char, boolean), sets, pointers

ML: primitive, records, tuples, lists, function abstractions, ref's to vbles.

Examine how variables allocated and lifetime.

Program Units:

Separate segments of code - usually allow separate declaration of local variables.

E.g. Procedures, functions, and blocks (from ALGOL 60 & C, like parameterless procedures located in-line.)

Program unit represented during execution by unit instance, composed of code segment and activation record (gives info on parameters and local variables, and where to return after execution).

Activation Record Structure:

Return address
Access info on parameters
Space for local variables

Units often need access to non-local variables.

How is procedure call made?

To call:

Make parameters available to callee.
Save state of caller (register, prog. counter).
Make sure callee knows how to find where to return to.
Enter callee at 1st instruction.

To return:

Get return address and transfer execution to that point.
Caller restores state.
If fcn, make sure result value left in accessible location (register, on top of stack, etc.)

Memory allocation

Three types of languages:

Static: E.g. FORTRAN and COBOL.
Stack-Based: E.g. ALGOL-like languages (including Pascal and C).
Dynamic: LISP, PROLOG, APL, ML, Miranda, Eiffel, etc. as well as aspects of Pascal, Ada, etc.

Static using FORTRAN as example

Units: Main program, Subroutines, and Functions.

All storage (local and global) known at translation time (hence static).

Activation records can be associated with each code segment.

Structure:

Return address
Access info on parameters
Space for local variables

At compile time, both instructions and vbles can be accessed by

(unit name, offset)

At link time can resolve to absolute addresses.

Global info shared via common statement:

	COMMON/NAME1/A,B,S(25)

Statement must occur in all units wishing to share information. Name of the block must be identical, though can give different names to variables. (Gives rise to holes in typing) Identifiers are matched in order w/ no checking of types across unit boundaries.

Space for all common blocks allocated and available globally.

Procedure call and return straightforward

Stack-based languages using ALGOL 60/Pascal

Problem during procedure activation

Static (e.g. scope) vs.
Dynamic (e.g. return address) Environments

Stack reflects dynamic environment.

Activation record pushed onto stack each time there is a procedure call.

Popped off after return.

Ex.

Program main;
    type array_type = array [1..10] of real;
    var a : integer;
         b : array_type;
    Procedure x (var c : integer; d : array_type);
        var e : array_type;
        procedure y (f : array_type);
            var g : integer;
            begin
                    :
                z(a+c);
                    :
            end; {y}
        begin {x}
             : ..... := b[6].......
            y(e);
             :
        end; {x}
    Procedure z (h : integer);
        var a : array_type;
        begin 
                :
            x (h,a);
                :
        end;
    begin {main}
            :
        x (a,b);
            :
    end. {main}

Draw static scopes.

Dynamic calling sequences:

	Main => x =>  y => z => x => y ....

Look at picture of run-time stack after x calls y 2nd time.

How do we get reference to b in x? to a in y? Where can these variables be held?

Dynamic link (called control link in text) provides pointer to beginning (usually) of caller's activation record.

Static link provides pointer to beginning of activation record of statically containing program unit.

How do find location of variable? Easy in FORTRAN! Not here!

Must keep track of the static nesting level of each variable and procedure.

When access vble or procedure, subtract static nesting level of definition from static nesting level of the definition.

Tells how far down static chain to environment of definition.

Example:

Name     Level          Name     Level

main            0           y           2
    a           1               f       3
    b           1               g       3
    x           1       z               1
        c       2           h           2
        d       2           a           2
        e       2

Notes:

Length of static chain from any fixed procedure to main program is always same length (doesn't depend on which activation we are in).
Any non-local vble will be found after some fixed number of static links (doesn't depend on which activation we are in).
This # of links is a constant determinable at compile time! (Difference between nesting level of call and callee.)

Thus represent identifier references in program as pair:

<chain position, offset>

Eg: from within y represent d as <1,nx+2> where nx is size of activation record of x before parameters. Similarly a is represented as <2, nmain+1>.

often called semi-dynamic

Sol'n: Space for vble descriptors allocated at fixed offset.

Location of local vbles and parameters may have to be calculated from this info at each invocation (e.g., store starting location on stack and use indirection).