Status Run-time Environments • We have so far covered the front-end phases – Lexical analysis – Parsing – Semantic analysis • Next come the back-end phases – Code generation – Optimization – Register allocation – Instruction scheduling • We will examine code generation first . . . 2 Run-time environments Outline • Before discussing code generation, we need to • Management of run-time resources understand what we are trying to generate • Correspondence between static (compile-time) • There are a number of standard techniques and dynamic (run-time) structures for structuring executable code that are widely used • Storage organization 3 4
Run-time Resources Memory Layout • Execution of a program is initially under the control of the operating system (OS) Low Address Code • When a program is invoked: Memory – The OS allocates space for the program – The code is loaded into part of this space – The OS jumps to the entry point of the program (i.e., to the beginning of the “main” function) Other Space High Address 5 6 Notes Organization of Code Space • By tradition, pictures of run-time memory • Usually, code is generated one function at a organization have: time. The code area thus is of the form: – Low addresses at the top entry point Code for function 1 – High addresses at the bottom entry point Code for function 2 – Lines delimiting areas for different kinds of data ... entry point Code for function n • These pictures are simplifications • Careful layout of code within a function can improve – E.g., not all memory need be contiguous i-cache utilization and give better performance • Careful attention in the order in which functions are processed can also improve i-cache utilization 7 8
What is Other Space? Code Generation Goals • Holds all data needed for the program’s • Two goals: execution – Correctness • Other Space = Data Space – Speed • Most complications in code generation come • Compiler is responsible for: from trying to be fast as well as correct – Generating code – Orchestrating the use of the data area 9 10 Assumptions about Flow of Control Language Issues that affect the Compiler (1) Execution is sequential; at each step, control • Can procedures be recursive? is at some specific program point and moves • What happens to the values of the locals on return from a procedure? from one point to another in a well-defined • Can a procedure refer to non-local variables? order • How are parameters to a procedure passed? • Can procedures be passed as parameters? (2) When a procedure is called, control eventually returns to the point immediately • Can procedures be returned as results? following the place where the call was made • Can storage be allocated dynamically under program control? • Must storage be deallocated explicitly? Do these assumptions always hold? 11 12
Activations Lifetimes of Variables • An invocation of procedure P is an activation • The lifetime of a variable x is the portion of of P execution in which x is defined • The lifetime of an activation of P is • Note that: – All the steps to execute P – Lifetime is a dynamic (run-time) concept – Including all the steps in procedures P calls – Scope is (usually) a static concept 13 14 Activation Trees Example 1 • Assumption (2) requires that when P calls Q, g(): int { return 42; } then Q returns before P does f(): int { return g(); } main() { g(); f(); } • Lifetimes of procedure activations are thus either disjoint or properly nested main • Activation lifetimes can be depicted as a tree g f g 15 16
Example 2 Notes • The activation tree depends on run-time behavior g(): int { return 42; } • The activation tree may be different for f(x:int): int { every program input if x = 0 then return g(); else return f(x - 1); Since activations are properly nested, a (control) } stack can track currently active procedures main() { f(3); } – push info about an activation at the procedure entry – pop the info when the activation ends; i.e., at the return from the call What is the activation tree for this example? 17 18 Example Example g(): int { return 42; } g(): int { return 42; } f(): int { return g(); } f(): int { return g(); } main() { g(); f(); } main() { g(); f(); } main Stack main Stack main main g g 19 20
Example Example g(): int { return 42; } g(): int { return 42; } f(): int { return g(); } f(): int { return g(); } main() { g(); f(); } main() { g(); f(); } main main Stack Stack main main g g f f 21 22 Example Revised Memory Layout g(): int { return 42; } Low Address f(): int { return g(); } Code main() { g(); f(); } Memory Stack main Stack main g f f High Address g g 23 24
Activation Records What is in G’s AR when F calls G? • The information needed to manage a single • F is “suspended” until G completes, at which procedure activation is called an activation point F resumes. G’s AR contains information record (AR) or a stack frame needed to resume execution of F. • If a procedure F calls G, then G’s activation • G’s AR may also contain: record contains a mix of info about F and G – G’s return value (needed by F) – Actual parameters to G (supplied by F) – Space for G’s local variables 25 26 The Contents of a Typical AR for G Example 2, Revisited • Space for G’s return value g(): int { return 42; } • Actual parameters f(x:int): int { Pointer to the previous activation record • (optional) if x=0 then return g(); – The control link; points to the AR of caller of G else return f(x - 1);(**) (optional) Access link for access to non-local names • } – Points to the AR of the function that statically contains G main() { f(3);(*) } • Machine status prior to calling G result AR for f: – Return address, values of registers & program counter argument – Local variables • Other temporary values used during evaluation control link return address 27 28
Stack After Two Calls to f Notes has no argument or local variables and main() • returns no result; its AR is uninteresting main • (*) and (**) are return addresses (continuation f (result) points) of the invocations of f() 3 – The return address is where execution resumes after a procedure call finishes (*) f (result) • This is only one of many possible AR designs 2 – Would also work for C, Pascal, FORTRAN, etc. (**) 29 30 The Main Point Example 2, continued The picture shows the state after the call to the 2nd invocation of f() returns • The compiler must determine, at compile-time, the layout of activation records and generate main code that correctly accesses locations in the f (result) activation record (as displacements from sp ) 3 Thus, the AR layout and the code generator (*) must be designed together! f 42 2 (**) 31 32
Discussion Discussion (Cont.) • The advantage of placing the return value 1st • Real compilers hold as much of the frame as in a frame is that the caller can find it at a possible in registers fixed offset from its own frame – Especially the function result and (some of) the arguments • There is nothing magical about this run-time organization – Can rearrange order of frame elements – Can divide caller/callee responsibilities differently – An organization is better if it improves execution speed or simplifies code generation 33 34 Storage Allocation Strategies for Activation Storage Allocation Strategies for Activation Records (1) Records (2) Static Allocation (Fortran 77) Stack Allocation (Pascal, C) – Storage for all data objects laid out at compile – Storage organized as a stack time – Activation record pushed when activation begins and popped when it ends – Can be used only if size of data objects and – Cannot be used if the values of local names must be constraints on their position in memory can be retained when the evaluation ends or if the called resolved at compile time ⇒ no dynamic structures invocation outlives the caller – Recursive procedures are restricted, since all Heap Allocation (Lisp, ML) activations of a procedure must share the same – Activation records may be allocated and locations for local names deallocated in any order – Some form of garbage collection is needed to reclaim free space 35 36
Recommend
More recommend
