Memory Management and Run-Time Systems

Similar documents
Run-time Environments -Part 1

Example. program sort; var a : array[0..10] of integer; procedure readarray; : function partition (y, z :integer) :integer; var i, j,x, v :integer; :

G Programming Languages - Fall 2012

Concepts Introduced in Chapter 7

Run Time Environment. Activation Records Procedure Linkage Name Translation and Variable Access

Run Time Environment. Procedure Abstraction. The Procedure as a Control Abstraction. The Procedure as a Control Abstraction

Run Time Environments

Informatica 3 Marcello Restelli

Attributes of Variable. Lecture 13: Run-Time Storage Management. Lifetime. Value & Location

Programming Languages Third Edition. Chapter 10 Control II Procedures and Environments

Implementing Subprograms

G Programming Languages Spring 2010 Lecture 4. Robert Grimm, New York University

Principles of Programming Languages Topic: Scope and Memory Professor Louis Steinberg Fall 2004

G Programming Languages - Fall 2012

Module 27 Switch-case statements and Run-time storage management

Chapter 10. Implementing Subprograms

Programming Languages

CSE 504. Expression evaluation. Expression Evaluation, Runtime Environments. One possible semantics: Problem:

Run-Time Environments

CS 314 Principles of Programming Languages

System Software Assignment 1 Runtime Support for Procedures

Programming Languages

CSc 520 Principles of Programming Languages

CSc 520 Principles of Programming Languages. ameter Passing Reference Parameter. Call-by-Value Parameters. 28 : Control Structures Parameters

Chapter 9. Def: The subprogram call and return operations of a language are together called its subprogram linkage

SE352b: Roadmap. SE352b Software Engineering Design Tools. W3: Programming Paradigms

Names, Scopes, and Bindings. CSE 307 Principles of Programming Languages Stony Brook University

Chapter 10. Implementing Subprograms ISBN

Procedure and Function Calls, Part II. Comp 412 COMP 412 FALL Chapter 6 in EaC2e. target code. source code Front End Optimizer Back End

Programming Languages: Lecture 12

Names, Scopes, and Bindings. CSE 307 Principles of Programming Languages Stony Brook University

! Those values must be stored somewhere! Therefore, variables must somehow be bound. ! How?

Run-time Environments - 2

CSc 520 Principles of Programming Languages

Chap. 8 :: Subroutines and Control Abstraction

Chapter 8 :: Subroutines and Control Abstraction. Final Test. Final Test Review Tomorrow

Run-time Environments

Design Issues. Subroutines and Control Abstraction. Subroutines and Control Abstraction. CSC 4101: Programming Languages 1. Textbook, Chapter 8

Run-time Environments

CS 314 Principles of Programming Languages. Lecture 13

Principles of Programming Languages

Implementing Subprograms

CSc 520 Principles of Programming Languages. Questions. rocedures as Control Abstractions... 30: Procedures Introduction

12/4/18. Outline. Implementing Subprograms. Semantics of a subroutine call. Storage of Information. Semantics of a subroutine return

Chapter 5. Names, Bindings, and Scopes

Weeks 6&7: Procedures and Parameter Passing

NOTE: Answer ANY FOUR of the following 6 sections:

Chapter 10 Implementing Subprograms

Compilers. 8. Run-time Support. Laszlo Böszörmenyi Compilers Run-time - 1

Run-time Environment

Chapter 9 :: Subroutines and Control Abstraction

Control Abstraction. Hwansoo Han

Chapter 3:: Names, Scopes, and Bindings (cont.)

Chapter 3:: Names, Scopes, and Bindings (cont.)

Lecture 11: Subprograms & their implementation. Subprograms. Parameters

6. Names, Scopes, and Bindings

Separate compilation. Topic 6: Runtime Environments p.1/21. CS 526 Topic 6: Runtime Environments The linkage convention

LECTURE 14. Names, Scopes, and Bindings: Scopes

Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore

Lecture 7: Binding Time and Storage

COP4020 Programming Languages. Names, Scopes, and Bindings Prof. Robert van Engelen

CIT Week13 Lecture

Chapter 5 Names, Binding, Type Checking and Scopes

CS558 Programming Languages Winter 2018 Lecture 4a. Andrew Tolmach Portland State University

Scope. CSC 4181 Compiler Construction. Static Scope. Static Scope Rules. Closest Nested Scope Rule

Runtime Environments I. Basilio B. Fraguela

LECTURE 19. Subroutines and Parameter Passing

CS558 Programming Languages

Lecture 9: Parameter Passing, Generics and Polymorphism, Exceptions

INF5110 Compiler Construction. Spring 2017

Run-time Environments - 3

Typical Runtime Layout. Tiger Runtime Environments. Example: Nested Functions. Activation Trees. code. Memory Layout

Memory Management. Memory Management... Memory Management... Interface to Dynamic allocation

Binding and Variables

Topic IV. Block-structured procedural languages Algol and Pascal. References:

CS 345. Functions. Vitaly Shmatikov. slide 1

Run-time Environments. Lecture 13. Prof. Alex Aiken Original Slides (Modified by Prof. Vijay Ganesh) Lecture 13

Names and Abstractions: What s in a Name?

Topic 7: Activation Records

CS 314 Principles of Programming Languages. Lecture 11

Topic IV. Parameters. Chapter 5 of Programming languages: Concepts & constructs by R. Sethi (2ND EDITION). Addison-Wesley, 1996.

1 Lexical Considerations

Informal Semantics of Data. semantic specification names (identifiers) attributes binding declarations scope rules visibility

CSc 520 final exam Wednesday 13 December 2000 TIME = 2 hours

Lecture08: Scope and Lexical Address

Imperative Programming

Chapter 3:: Names, Scopes, and Bindings

Runtime management. CS Compiler Design. The procedure abstraction. The procedure abstraction. Runtime management. V.

CMa simple C Abstract Machine

Topic 3-a. Calling Convention 2/29/2008 1

Scope, Functions, and Storage Management

UNIT V Sub u P b ro r g o r g a r m a s

The compilation process is driven by the syntactic structure of the program as discovered by the parser

Informatica 3 Syntax and Semantics

COMP 303 Computer Architecture Lecture 3. Comp 303 Computer Architecture

CS 314 Principles of Programming Languages

Semantic Analysis and Type Checking

Lecture 9: Procedures & Functions. CS 540 George Mason University

Subroutines and Control Abstraction. CSE 307 Principles of Programming Languages Stony Brook University

CSC 533: Organization of Programming Languages. Spring 2005

Transcription:

TDDD55 Compilers and Interpreters TDDB44 Compiler Construction Memory Management and Run-Time Systems Part of the Attribute Grammar Material Presented at the Beginning of this Lecture Peter Fritzson IDA, Linköpings universitet, 2011. Run-Time Systems Support Program Execution Memory management of a program during execution. This includes allocation and de-allocation of memory cells. Address calculation for variable references. For references to non-local data, finding the right object taking scope into consideration. Recursion, which means that several instances of the same procedure are active (activations of a procedure) at the same time during execution. Dynamic language constructs, such as dynamic arrays, pointer structures, etc. Different sorts of parameter transfer Two different memory management strategies: static and dynamic memory management, determined by the language to be executed. 2 TDDD55/TDDB44 Compiler Construction, 2011 Static Memory Management All data and its size must be known during compilation, i.e. the memory space needed during execution is known at compile-time. The underlying language has no recursion. Fixed Data is referenced to by absolute addresses. Program Data Area Dynamic Memory Management (1) Data size is not known at compiler time (e.g. dynamic arrays, pointer structures) There is recursion Examples of such languages are: Pascal, C, Algol, Java, Static memory management needs no run-time support, because everything about memory management can be decided during compilation. An example of such a language is FORTRAN77, whereas FORTRAN90 has recursion. 3 TDDD55/TDDB44 Compiler Construction, 2011 4 TDDD55/TDDB44 Compiler Construction, 2011 Dynamic Memory Management (2) Run-Time Support A Stack Frame with Frame and Stack Pointers Run-Time support is needed for languages with dynamic memory management: Previous stack frame Decreasing memory addresses Stack grows The call chain must be stored somewhere and references to non-local variables must be dealt with. fp (old sp) Variables can not be referenced by absolute addresses, but by <blockno, offset>. All data belonging to a block (procedure) is gathered together in an activation record (stack frame). At a procedure call memory is allocated on the stack and each call involves constructing an activation record. sp Current stack frame Variable A Offset of variable A from fp fp frame pointer sp stack pointer 5 TDDD55/TDDB44 Compiler Construction, 2011 6 TDDD55/TDDB44 Compiler Construction, 2011 1

Some Concepts (Rep.) Activation Each call (execution) of a procedure is known as activation of the procedure. Life span of an activation The life span of an activation of a procedure p lasts from the execution s first statement to the last statement in p s procedure body. Recursive procedure A procedure is recursive if it can be activated again during the life span of the previous activation. Activation tree An activation tree shows how procedures are activated and terminated during an execution of a program. Note that a program can have different activation trees in different executions. Call chain All current activations (ordered by activation time) - a path in the activation tree - a sequence of procedure frames on the run-time stack 7 TDDD55/TDDB44 Compiler Construction, 2011 Example of Activation Tree (Rep.) program p; procedure q; end (* q *); procedure r; q; end d(* r *); (* p *) read(x); if x = 0 then q; else r; end (* p *); Two different activation trees for the program: Activation tree when x=0 p read q Activation tree when x 0 read p r q 8 TDDD55/TDDB44 Compiler Construction, 2011 Formal and Actual Parameters (Rep.) Arguments declared in the head of a procedure declaration are its formal and arguments in the procedure call are its actual. In the example below: i: is a formal parameter k: is an actual parameter procedure A(i: integer); (* A *) A(k); end (* A *); 9 TDDD55/TDDB44 Compiler Construction, 2011 Activation Record All information which is needed for an activation of a procedure is put in a record which is called an activation record. The activation record remains on the stack during the life span of the procedure. An activation record contains: Local data Temporary data Return address Parameters procedure var A: procecure p2 reference A end (* p2 *) end (* *) Pointers to previous activation records (dynamic link, control link) Static link (access link) or display for finding the correct references to non-local data (e.g. in enclosing scopes) Dynamically allocated data (dope vectors) Space for a return value (where needed) Space for saving the contents of registers 10 TDDD55/TDDB44 Compiler Construction, 2011 Typical Memory Organization (Pascal/Java-like language) Static data The memory requirement for data objects must be known at compile time and the address to these objects is not changed during Stack execution, so the addresses can be hard-coded in the object code. Space for activation records is allocated for each new activation of procedures. Heap Allocation when necessary. Stack grows Heap grows upwards Object code Static data Stack Free Space Heap Global data Activation records Dynamic data Memory fragmentation 11 TDDD55/TDDB44 Compiler Construction, 2011 How are non-local variables referenced? Static link (access link) Display Example: program prog; (* Block B0,predefined vars) var a,b,c: integer; (* Block B1, Globals*) procedure ; var b, c: real; (* Block B2 *) procedure p2; var c: real; (* Block B3 *) c := b+a; (* B3.c := B2.b + B1.a *) end (* p2 *); p2; end (* ); ; end (* prog *). In the procedures the variables are referenced using <blockno, offset>: B3.c := B2.b + B1.a or by using relative blocknumber: 0.c := 1.b + 2.a (0: current block, 1: nearest surrounding block, etc.) 12 TDDD55/TDDB44 Compiler Construction, 2011 2

Non-local references through Static Link Non-local references through Display The static link is a pointer to the most recent activation record for the textually surrounding block Example. Use relative block number for statement inside procedure p2: 0.c := 1.b + 2.a For variable a follow the static link 2 steps. This method is practical and uses little space. With deeply nested procedures it will be slow. p2 main Static Link Display is a table with pointers (addresses) to surrounding procedures activation records. The display can be stored in the activation records. Display is faster than static link for deep nesting, but requires more space. Display can be slightly slower than static link for very shallow nesting. Display Display p2 main 13 TDDD55/TDDB44 Compiler Construction, 2011 14 TDDD55/TDDB44 Compiler Construction, 2011 Dynamic Link, i.e., Control Link Dynamic link specifies the call chain, Not the same as static link if there is a recursive call chain,e.g program foo; procedure ; procedure p2 procedure p3; (* p3*) ; end (* p3 *); (* p2 *) p3; end (* p2 *) (* *) p2; ; end (* ) (* main *) ; end (* main *) (On return from we continue inside p3) The stack at 2nd call for Textual environment Static link p3 p2 main Dynamic link - Call chain 15 TDDD55/TDDB44 Compiler Construction, 2011 Heap Allocation (Rep.) In some languages data can dynamically be built during execution and its size is not known (e.g. strings of variable length, lists, tree structures, etc). Manual memory management De-allocation is not performed automatically as in stack allocation. Hard work, can lead to bugs. Pascal: new(p) (*allocation*) dispose(p) (* deallocation*) C: p=malloc() (*allocation*) free(p) (* deallocation*) Automatic memory management, with garbage collection (e.g. Lisp, Java) De-allocation is automatic. Resource-consuming, but avoids bugs. Free list released memory memory fragmentation After memory compaction: free used 16 TDDD55/TDDB44 Compiler Construction, 2011 Data Storage and Referencing Where is data stored and how is it referenced? (Semi-static) Static data can be allocated directly (consecutive in the activation record, data area). Data is referenced by <blockno, offset>. blockno is specified as nesting depth. Simple variables (boolean, integer, real ) These have a fixed size and are put directly into the activation record, or in registers. Static arrays Fixed number of elements, i.e. size is known at compile time. Example: A: array[1..100] of integer; Stored directly in the activation record. 17 TDDD55/TDDB44 Compiler Construction, 2011 Dynamic Arrays The size is unknown at compile time: Example: B: array[1..max] of integer; max not known at compile time. Dope vector (data descriptor) is used for dynamic arrays. Dope vectors are stored in the activation record. Dope vector: Lower limit Start address Upper limit Either above the stack + offset or in the heap 18 TDDD55/TDDB44 Compiler Construction, 2011 3

Dynamic Arrays and Block Structures in ALGOL (1) PROCEDURE A(X,Y); INTEGER X, Y; L1: BEGIN REAL Z; ARRAY B[X:Y]; (block B1:) L2: BEGIN REAL D,E; L3: L4: BEGIN ARRAY A[1:X]; L5: BEGIN REAL E; L6: L7: L8: before L1 before L2 19 TDDD55/TDDB44 Compiler Construction, 2011 Dynamic Arrays and Block Structures in ALGOL (2) array B array B L2,L4,L8 D, E b2 STACKTOP L3 PROCEDURE A(X,Y); INTEGER X, Y; L1: BEGIN REAL Z; (block ARRAY B[X:Y]; L2:BEGIN REAL D,E; L3: L4:BEGIN ARRAY A[1:X]; L5:BEGIN REAL E; L6: L7: L8: 20 TDDD55/TDDB44 Compiler Construction, 2011 Dynamic Arrays and Block Structures in ALGOL (3) array A array B A dope v. b3 STACKTOP L5, L7 array A array B E b4 STACKTOP A dope v. b3 STACKTOP L6 PROCEDURE A(X,Y); INTEGER X, Y; L1: BEGIN REAL Z; (blo ARRAY B[X:Y]; L2:BEGIN REAL D,E; L3: L4:BEGIN ARRAY A[1:X]; L5:BEGIN REAL E; L6: L7: L8: Parameter Passing (1) (Rep.) Reference There are different ways of passing in different programming languages. Here are four of the most common methods: 1. reference ( location) The address to the actual parameter, l-value, is passed to the called routine s AR The actual parameter s value can be changed. Causes aliasing. The actual parameter must have an l-value. Example: Pascal s VAR, reference in C++. In Fortran, this is the only kind of parameter. 21 TDDD55/TDDB44 Compiler Construction, 2011 22 TDDD55/TDDB44 Compiler Construction, 2011 Parameter Passing (2) (Rep.) Value 2. value The value of the actual parameter is passed The actual parameter cannot change value Example: Pascal s non-var, found in most languages (e.g. C, C++, Java) Parameter Passing (3) (Rep.) value-result (hybrid) 3. value-result (hybrid) The value of the actual parameter is calculated by the calling procedure and is copied to AR for the called procedure. The actual parameter s value is not affected during execution of the called procedure. At return the value of the formal parameter is copied to the actual parameter, if the actual parameter has an l-value (e.g. is a variable). Found in Ada. 23 TDDD55/TDDB44 Compiler Construction, 2011 24 TDDD55/TDDB44 Compiler Construction, 2011 4

Parameter Passing (4) (Rep.) Name 4. name Similar to macro definitions No values calculated or passed The whole expression of the parameter is passed as a procedure without, a thunk. Calculating the expression is performed by evaluating the thunk each time there is a reference to the parameter. Some unpleasant effects, but also general/powerful. Found in Algol, Mathematica, Lazy functional languages Example of Using the Four Parameter Passing Methods: (Rep.) procedure swap(x, y : integer); var temp : integer; temp := x; x := y; y := temp; end (*swap*); i := 1; a[i]:=10; (* a: array[1..5] of integer *) print(i,a[i]); swap(i,a[i]); print(i,a[1]); Results from the 4 parameter passing methods Printouts from the print statements in the above example reference value value-result name 1 10 1 10 1 10 1 10 10 1 1 10 10 1 Error! 25 TDDD55/TDDB44 Compiler Construction, 2011 26 TDDD55/TDDB44 Compiler Construction, 2011 Reason for the Error in the Call-by-name Example The following happens: x = text( i ); y = text( a[i] ); temp := i; (* => temp:=1 *) i := a[i]; (* => i:=10 since a[i]=10 *) a[i] := temp; (* => a[10]:=1 => index out of bounds *) Note: This error does not occur in lazy functional languages using call-by-name since side-effects are not allowed. 27 TDDD55/TDDB44 Compiler Construction, 2011 Static Memory Management E.g. Fortran77 and (partly) CUDA/C on NVIDIA No procedure nesting, i.e., no block structure. References to variables locally or globally. No displays or static links needed. No recursion ( stack not needed). All data are static ( heap not needed). All memory is allocated statically variables are referenced by absolute address. The data area (i.e. the activation record) is often placed with the code. Inefficient for allocating space for objects which are perhaps used only a short time during execution. But execution is efficient in that all addresses are placed and ready in the object code 28 TDDD55/TDDB44 Compiler Construction, 2011 Static Memory Allocation and Procedure Call/Return for Fortran77 SUBROUTINE SUB(J) I = 1 J = I+3*J END Return address I J Temp Code for SUB At procedure call 1. Put the addresses (or values) of the actual in the data area. 2. Save register contents. 3. Put return address in the data area. 4. Execute the routine. On return: 1. Re-set the registers. 2. Jump back. Memory management in Algol, Pascal, C, C++, Java Language Properties: Nested procedures/blocks (PASCAL, ALGOL) Dynamic arrays (ALGOL, C++, Java, ) Recursion Heap allocation (PASCAL, C, C++, Java, ) Problems: References to non-local variables (solved by display or static link) Call-by-name (ALGOL, Lazy Functional Languages) Dynamic arrays (dope vector) Procedures as 29 TDDD55/TDDB44 Compiler Construction, 2011 30 TDDD55/TDDB44 Compiler Construction, 2011 5

Events when Procedure P Calls Q At call: P already has an AR (activation record) on the stack P's responsibility: Allocate space for Q's AR. Evaluate actual and put them in Q's AR. Save return address and dynamic links (i.e. top_sp) in new (Q's) AR. Update (increment) top_sp. Q's responsibility: Save register contents and other status info. Initialise own local data and start to execute. At return: Q's responsibility Save return value in own AR (NB! P can access the return value after the jump). Reset the dynamic link and register contents, Q finishes with return to P's code. P's Responsibility P collects the return value from Q, despite update of topsp. 31 TDDD55/TDDB44 Compiler Construction, 2011 At Calls Stack and Heap Stack grows Heap grows upwards AR for caller old top_sp new fp = old top_sp AR for callee, i.e. called proc new top_sp return value actual dynamic link () return address static link saved regs (if necessary) local variables temporary variables dynamic objects/arrays (if nec) return value actual dynamic link () return address static link saved regs (if necessary) local variables temporary variables dynamic objects/arrays (if nec) callers responsibility callee's responsibility stack grows 32 TDDD55/TDDB44 Compiler Construction, 2011 Procedure Call/Return in Algol, Pascal, C, At call: 1. Space for activation record is allocated on the stack. 2. Display / static link is set. 3. Move the actual. 4. Save implicit (e.g. registers). 5. Save return address. 6. Set dynamic link. 7. Execute the routine. At return: 1. Reset dynamic link. 2. Reset the registers 3. Reset display / static link 4. Jump back. 33 TDDD55/TDDB44 Compiler Construction, 2011 6