runtime environments chapter 7 in textbook l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Runtime Environments Chapter 7 in textbook PowerPoint Presentation
Download Presentation
Runtime Environments Chapter 7 in textbook

Loading in 2 Seconds...

play fullscreen
1 / 45

Runtime Environments Chapter 7 in textbook - PowerPoint PPT Presentation


  • 182 Views
  • Uploaded on

Runtime Environments Chapter 7 in textbook. Run-Time Environments. 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 STORAGE on the machine.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Runtime Environments Chapter 7 in textbook' - julio


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
run time environments
Run-Time Environments
  • 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 STORAGE on the machine.
  • Allocation and deallocation of memory is handled by a RUN-TIME SUPPORT SYSTEM typically 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.
procedures
Procedures
  • We assume in this lecture that a program is no more than a collection of PROCEDURES.
  • A PROCEDURE DEFINTION associates an identifier with a statement (a statement could actually be a block of statements, of course).
  • The identifier is called the PROCEDURE NAME.
  • The statement is called the PROCEDURE BODY.
  • A PROCEDURE CALL is an invocation of a procedure within an executable statement.
  • Procedures that return values are normally called FUNCTIONS, but we’ll just use the name “procedure.”
example program
Example program
  • program sort( input, output );

var a: array [ 0..10 ] of integer;

procedure readarray;

      • var i: integer;
      • begin
      • for i := 1 to 9 do read( a[i] )
      • end;

function partition( y, z: integer ) : integer;

      • var i, j, x, v: integer;
      • begin …
      • end;

procedure quicksort( m, n: integer );

      • var i: integer;
      • begin
        • if ( n > m ) then begin
          • i := partition( m, n );
          • quicksort(m,i-1);
          • quicksort(i+1,n)
        • end
      • end;

begin

      • a[0] := -9999; a[10] := 9999;
      • readarray;
      • quicksort(1,9);

end.

parameters of procedures
Parameters of procedures
  • The FORMAL PARAMETERS are special identifiers declared in the procedure definition.
  • The formal parameters must correspond to the ACTUAL PARAMETERS in the function call.
  • E.g. m and n are formal parameters of the quicksort procedure. The actual parameters in the call to quicksort in the main program are 1 and 9.
  • Actual parameters can be a simple identifier, or more complex expressions.
control flow
Control flow
  • Let’s assume, as in most mainstream programming languages, that we have SEQUENTIAL program flow.
  • Procedure execution begins at the first statement of the procedure body.
  • When a procedure returns, execution returns to the instruction immediately following the procedure call.
activations
Activations
  • Every execution of a procedure is called an ACTIVATION.
  • The LIFETIME of an activation of procedure P is the sequence of steps between the first and last steps of P’s body, including any procedures called while P is running.
  • Normally, when control flows from one activation to another, it must (eventually) return to the same activation.
  • When activations are thusly nested, we can represent control flow with ACTIVATION TREES.
activation trees
Activation trees

Execution begins…

enter readarray

leave readarray

enter quicksort(1,9)

enter partition(1,9)

leave partition(1,9)

enter quicksort(1,3)

leave quicksort(1,3)

enter quicksort(5,9)

leave quicksort(5,9)

leave quicksort(1,9)

Execution terminated.

control stacks
Control stacks
  • We can use a stack to keep track of currently-active activations.
  • We push a record onto the stack when a procedure is called, and pop that record off the stack when the procedure returns.
  • At any point in time, the control stack represents a path from the root of the activation tree to one of the nodes.
example control stack
Example control stack

This partial activation tree corresponds to control stack (growing downward)

s

q(1,9)

q(1,3)

q(2,3)

declarations
Declarations
  • Every DECLARATION associates some information with a name.
  • In Pascal and C, declarations are EXPLICIT: var i : integer;
  • assocates the TYPE integer with the NAME i.
  • Some languages like Perl and Python have IMPLICIT declarations.
scope of a declaration
Scope of a declaration
  • The SCOPING RULES of a language determine where in a program a declaration applies.
  • The SCOPE of a declaration is the portion of the program where the declaration applies.
  • An occurrence of a name in a procedure P is LOCAL to P if it is in the scope of a declaration made in P.
  • If the relevant declaration is not in P, we say the reference is NON-LOCAL.
  • During compilation, we use the symbol table to find the right declaration for a given occurrence of a name.
  • The symbol table should return the entry if the name is in scope, or otherwise return nothing.
environments and states
Environments and states
  • The ENVIRONMENT is a function mapping from names to storage locations.
  • The STATE is a function mapping storage locations to the values held in those locations.
  • Environments map names to l-values.
  • States map l-values to r-values.
name binding
Name binding
  • When an environment maps name x to storage location s, we say “x is BOUND to s”. The association is a BINDING.
  • Assignments change the state, but NOT the environment:pi := 3.14
  • changes the value held in the storage location for pi, but does NOT change the location (the binding) of pi.
  • Bindings do change, however, during execution, as we move from activation to activation.
scope
Scope
  • Scope: the region of program text in which a binding holds.
  • Static binding is prevalent in most modern PLs.
    • New scope in each function.
      • Activate bindings for parameters and locals.
      • Deactivate bindings of globals obscured by locals.
      • Deactivate bindings upon function return.
example
Example

let Sqr x = x * x

in

let f a b = Sqr a + b

in

Print(f 4 3 + (let Sqr x = x+x in f 4 3)) )

  • In RPAL, this program prints 19 + 19 = 38.
  • If RPAL used dynamic scoping, the result would be 19 + 11 = 30.
terminology
Terminology
  • Referencing environment: the set of active bindings at a given point in a program's execution.
  • Deep binding: the reference environment of a fcn/proc is determined when the function is created.
  • Shallow binding: the reference environment of a fcn/proc is determined when the function is called.
structure of referencing environments
Structure of Referencing Environments
  • Normally, a stack suffices (C, C++, Java).
  • If a procedure (not merely a pointer) can be passed as a parameter, the referencing environments are organized as a tree.
types of static scope
Types of Static Scope
  • Flat: (BASIC, Cobol)
    • All name sin the same scope, all visible everywhere.
  • Local/global (Fortan, C, Prolog)
    • Only two referencing environments: current and global.
types of static scope cont d
Types of Static Scope (cont’d)
  • Nested procedures (Algol, Pascal, Ada, Modula, RPAL).
    • Each procedure has its own scope, visible to itself and all procedures nested within it.
types of static scope cont d21
Types of Static Scope (cont’d)
  • Modular scope (Modula, Ada, C++, Java).

Scopes defined by modules, which explicitly export names to:

    • The global scope (public)
    • The scopes of subclasses (protected)
    • Nowhere (private)
java scope modifier
Java scope modifier
  • A class always has access to its own members.
  • Y means classes in the same package as the class (regardless of their parentage) have access to the member.
  • Y means subclasses of the class, declared outside this package, have access to the member. 
  • Y means all classes have access to the member.
block scoping
Block Scoping
  • In the C language, execution blocks,delimited with{},define scopes.

{

int t;

t = a;

a = b;

{

float t=3.14;

printf("%f",t);

}

b = t;

}

block scoping cont d
Block Scoping (cont’d)
  • The variable's scope is limited to the{}block that contains its declaration.
  • Handled like ordinary local variables:
    • Space allocated in subroutine prologue (frame setup)
    • Deallocated in subroutine epilogue (frame destruction).
    • Compiler's symbol table keeps track of declarations.
modular scoping
Modular Scoping
  • First languages to incorporate information hiding.
  • Reduces "cognitive load" on programmers.
  • CIA principle: if a code segment doesn't need to know about an object, it shouldn't.
  • Tends to narrow (simplify) interfaces.
  • Aids in abstraction.
modular scoping cont d
Modular Scoping (cont’d)
  • Modules allow encapsulation of objects.
    • Objects inside the module are visible to each other.
    • Objects inside are only visible outside if explicitly exported.
    • Objects outside not visible inside unless imported.
modular scoping cont d27
Modular Scoping (cont’d)
  • Various terms for modules:
    • Clu: clusters
    • Modula, Ada, Java: packages
    • C++: namespaces
overloading
Overloading
  • Multiple meanings for the same name, context dependent.
  • Most languages allow it in some limited fashion, e.g. arithmetic operators

(a+bfor ints and reals).

  • In C++, one can overload both functions and operators. Can only overload fcns in Java (may change, more later).
run time system design
Run-time system design

Static notionDynamic counterpart

definition of a procedure activations of the procedure

declarations of a name bindings of the name

scope of a declaration lifetime of a binding

  • The run-time system keeps track of a program’s dynamic components. There are many relevant criteria for its design:
  • Can procedures be recursive?
  • What happens to values of local names when control returns from the activations of a procedure?
  • Can a procedure refer to nonlocal names?
  • How are parameters passed when procedures are called?
  • Can procedures be passed as parameters?
  • Can procedures be returned from procedures?
  • Can programs dynamically allocate their own storage?
  • Does storage get deallocated explicitly or implicitly?
organization of storage
Organization of storage
  • Fixed-size objects can be placed in predefined locations.
  • The heap and the stack need room to grow, however.
run time stack and heap
Run-time stack and heap
  • 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 HEAP stores data allocated under program control
activation records
Activation records
  • Any information needed for a single activation of a procedure is stored in the ACTIVATION RECORD (sometimes called the STACK FRAME).
  • Today, we’ll assume the stack grows DOWNWARD, as on, e.g., the Intel architecture.
  • The activation record gets pushed for each procedure call and popped for each procedure return.

Acontrol linkfrom record A points to the previous record on the stack. The chain of control links traces the dynamic execution of the program.

Anaccess linkfrom record A points to the record of the closest enclosing block in the program. The chain of access links traces the static structure (think: scopes) of the program.

compile time layout of locals
Compile-time layout of locals
  • Usually the BYTE is the smallest addressable unit of storage.
  • We lay out locals in the order they are declared.
  • Each local has an OFFSET from the beginning of the activation record (or local data area of the record).
  • Some data objects require alignment with machine words.
  • Any resulting wasted space is called PADDING.
  • TypeSize (typical) Alignment (typical)
  • char 8 8
  • short 16 16
  • int 32 32
  • float 32 32
  • double 64 32
static allocation
Static allocation
  • Statically allocated names are bound to relocatable storage at compile time.
  • Storage bindings of statically allocated names never change.
  • The compiler uses the 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 allocation37
Static allocation
  • 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 dynamic allocation
Stack-dynamic allocation
  • 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.
  • To allocate a new activation record, we just increase stack_top.
  • To deallocate an existing activation record, we just decrease stack_top.
address generation in stack allocation
Address generation in stack allocation
  • The position of the activation record on the stack cannot be determined statically.
  • Therefore the compiler must generate addresses RELATIVE to the activation record.
  • We generate addresses of the form stack_top + offset
calling sequences
Calling sequences
  • The CALLING SEQUENCE for a procedure allocates an activation record and fills its fields in with appropriate values.
  • The RETURN SEQUENCE restores the machine state to allow execution of the calling procedure to continue.
  • Some of the calling sequence code is part of the calling procedure, and some is part of the called procedure.
  • What goes where depends on the language and machine architecture.
sample calling sequence
Sample calling sequence
  • Caller evaluates the actual parameters and places them into the activation record of the callee.
  • Caller stores a return address and old value for stack_top in the callee’s activation record.
  • Caller increments stack_top to the beginning of the temporaries and locals for the callee.
  • Caller branches to the code for the callee.
  • Callee saves all needed register values and status.
  • Callee initializes its locals and begins execution.
sample return sequence
Sample return sequence
  • Callee places the return value at the correct location in the activation record (next to caller’s activation record)
  • Callee uses status information previously saved to restore stack_top and the other registers.
  • Callee branches to the return address previously requested by the caller.
variable length data
Variable-length data
  • In some languages, array size can depend on a value passed to the procedure as a parameter.
  • This and any other variable-sized data can still be allocated on the stack, but BELOW the callee’s activation record.
  • In the activation record itself, we simply store POINTERS to the to-be-allocated data.