Runtime Environments Chapter 7 in textbook

1. Runtime EnvironmentsChapter 7 in textbook

2. 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.

3. 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.”

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. Example control stack This partial activation tree corresponds to control stack (growing downward) s q(1,9) q(1,3) q(2,3)

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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)

22. 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.

23. 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; }

24. 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.

25. 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.

26. 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.

27. Modular Scoping (cont’d) • Various terms for modules: • Clu: clusters • Modula, Ada, Java: packages • C++: namespaces

28. 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).

29. 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?

30. Storage allocation

31. Organization of storage • Fixed-size objects can be placed in predefined locations. • The heap and the stack need room to grow, however.

32. 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

33. 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.

34. 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

35. Storage allocation strategies

36. 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.

37. 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.

39. 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.

40. 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

41. 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.

42. 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.

43. 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.

44. 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.

45. All variable-length data is pointed to from the local data area. Example of variable- length data