Runtime storage and Activation Records

Slides:



Advertisements
Similar presentations
1 Lecture 3: MIPS Instruction Set Today’s topic:  More MIPS instructions  Procedure call/return Reminder: Assignment 1 is on the class web-page (due.
Advertisements

The University of Adelaide, School of Computer Science
MIPS ISA-II: Procedure Calls & Program Assembly. (2) Module Outline Review ISA and understand instruction encodings Arithmetic and Logical Instructions.
ECE 232 L6.Assemb.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 6 MIPS Assembly.
10/6: Lecture Topics Procedure call Calling conventions The stack
1 Lecture 4: Procedure Calls Today’s topics:  Procedure calls  Large constants  The compilation process Reminder: Assignment 1 is due on Thursday.
Procedures in more detail. CMPE12cGabriel Hugh Elkaim 2 Why use procedures? –Code reuse –More readable code –Less code Microprocessors (and assembly languages)
Procedure Calls Prof. Sirer CS 316 Cornell University.
Lecture 6: MIPS Instruction Set Today’s topic –Control instructions –Procedure call/return 1.
CPS3340 COMPUTER ARCHITECTURE Fall Semester, /17/2013 Lecture 12: Procedures Instructor: Ashraf Yaseen DEPARTMENT OF MATH & COMPUTER SCIENCE CENTRAL.
Ch. 8 Functions.
The University of Adelaide, School of Computer Science
Prof. Necula CS 164 Lecture 141 Run-time Environments Lecture 8.
CPSC Compiler Tutorial 8 Code Generator (unoptimized)
1 Storage Registers vs. memory Access to registers is much faster than access to memory Goal: store as much data as possible in registers Limitations/considerations:
Procedures in more detail. CMPE12cCyrus Bazeghi 2 Procedures Why use procedures? Reuse of code More readable Less code Microprocessors (and assembly languages)
1 Chapter 7: Runtime Environments. int * larger (int a, int b) { if (a > b) return &a; //wrong else return &b; //wrong } int * larger (int *a, int *b)
CS 536 Spring Run-time organization Lecture 19.
The Procedure Abstraction Part III: Allocating Storage & Establishing Addressability Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all.
3/17/2008Prof. Hilfinger CS 164 Lecture 231 Run-time organization Lecture 23.
CS 536 Spring Code generation I Lecture 20.
1 Lecture 9 Runtime Environment. 2 Outline Basic computer execution model Procedure abstraction run-time storage management Procedure linkage We need.
Intro to Computer Architecture
Run time vs. Compile time
Run-time Environment and Program Organization
1 Run time vs. Compile time The compiler must generate code to handle issues that arise at run time Representation of various data types Procedure linkage.
Chapter 6 Activation Records. Local Variables, Instantiations int f(int x) { int y = x+x; if (y
7/13/20151 Topic 3: Run-Time Environment Memory Model Activation Record Call Convention Storage Allocation Runtime Stack and Heap Garbage Collection.
Activation Records Chapter 6. 2 Local Variables, Instantiations Ex: function f(x:int) : int = let var y := x + x in if y < 10 then f(y) else y – 1 end.
Chapter 8 :: Subroutines and Control Abstraction
Chapter 7: Runtime Environment –Run time memory organization. We need to use memory to store: –code –static data (global variables) –dynamic data objects.
Runtime Environments What is in the memory? Runtime Environment2 Outline Memory organization during program execution Static runtime environments.
13/02/2009CA&O Lecture 04 by Engr. Umbreen Sabir Computer Architecture & Organization Instructions: Language of Computer Engr. Umbreen Sabir Computer Engineering.
Runtime Environments Compiler Construction Chapter 7.
Compiler Run-time Organization Lecture 7. 2 What we have covered so far… We have covered the front-end phases –Lexical analysis –Parsing –Semantic analysis.
Programming Language Principles Lecture 24 Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Subroutines.
Compiler Construction
CSc 453 Runtime Environments Saumya Debray The University of Arizona Tucson.
Copyright © 2005 Elsevier Chapter 8 :: Subroutines and Control Abstraction Programming Language Pragmatics Michael L. Scott.
Activation Records CS 671 February 7, CS 671 – Spring The Compiler So Far Lexical analysis Detects inputs with illegal tokens Syntactic analysis.
Lecture 18: 11/5/2002CS170 Fall CS170 Computer Organization and Architecture I Ayman Abdel-Hamid Department of Computer Science Old Dominion University.
Procedures. Why use procedures? ? Microprocessors (and assembly languages) provide only minimal support for procedures Must build a standard form for.
Adapted from Computer Organization and Design, Patterson & Hennessy, UCB ECE232: Hardware Organization and Design Part 7: MIPS Instructions III
Activation Records (in Tiger) CS 471 October 24, 2007.
1 CIS 461 Compiler Design and Construction Winter 2012 Lecture-Module #16 slides derived from Tevfik Bultan, Keith Cooper, and Linda Torczon.
Lecture 4: MIPS Instruction Set
CSC 8505 Compiler Construction Runtime Environments.
Chapter 2 — Instructions: Language of the Computer — 1 Conditional Operations Branch to a labeled instruction if a condition is true – Otherwise, continue.
ISBN Chapter 10 Implementing Subprograms.
© G. Drew Kessler and William M. Pottenger1 Subroutines, Part 2 CSE 262, Spring 2003.
LECTURE 19 Subroutines and Parameter Passing. ABSTRACTION Recall: Abstraction is the process by which we can hide larger or more complex code fragments.
Code Generation Instruction Selection Higher level instruction -> Low level instruction Register Allocation Which register to assign to hold which items?
Computer structure: Procedure Calls
Run-time organization
Chapter 9 :: Subroutines and Control Abstraction
Instructions - Type and Format
Chap. 8 :: Subroutines and Control Abstraction
Chap. 8 :: Subroutines and Control Abstraction
The University of Adelaide, School of Computer Science
Lecture 5: Procedure Calls
10/4: Lecture Topics Overflow and underflow Logical operations
Program and memory layout
Operating Systems Run-time Organization
Procedures and Calling Conventions
Runtime Environments What is in the memory?.
Computer Architecture
Where is all the knowledge we lost with information? T. S. Eliot
Program and memory layout
Topic 2b ISA Support for High-Level Languages
Presentation transcript:

Runtime storage and Activation Records Chapter 6 Runtime storage and Activation Records

Outline Basic computer execution model run-time program layout activation record procedure linkage Frame in MiniJava

Basic Execution Model MIPS as an example Intro to mips assembly Programmed Intro To mips assembly. CPU ALU Unit Registers Control Unit Memory program data Memory Registers Control ALU

Arithmetic and Logic Unit Memory Performs most of the data operations Has the form: OP Rdest, Rsrc1, Rsrc2 Operations are: Arithmetic operations (add, sub, mulo [mult with overflow]) Logical operations (and, sll, srl) Comparison operations (seq, sge, slt [set to 1 if less than]) Registers ALU Control

Arithmetic and Logic Unit Memory Many arithmetic operations can cause an exception overflow and underflow Can operate on different data types 8, 16, 32 bits signed and unsigned arithmetic Floating-point operations (separate ALU) Instructions to convert between formats (cvt.s.d) Registers ALU Control

Control Handles the instruction sequencing Executing instructions Memory Handles the instruction sequencing Executing instructions All instructions are in memory Fetch the instruction pointed by the PC and execute it For general instructions, increment the PC to point to the next location in memory Registers ALU Control

Control Unconditional Branches Fetch the next instruction from a different location Unconditional jump to a given address j label Unconditional jump to an address in a register jr rsrc To handle procedure calls, do an unconditional jump, but save the next address in the current stream in a register jal label [jump and link] jalr rsrc Memory Registers ALU Control

Control Conditional Branches Perform a test, if successful fetch instructions from a new address, otherwise fetch the next instruction Instructions are of the form: brelop Rsrc1, Rsrc2, label ‘relop’ is of the form: ‘’, ‘eq’, ‘ne’, ‘gt’, ‘ge’, ‘lt’, ‘le’ Memory Registers ALU Control

Control Control transfer in special (rare) cases traps and exceptions Mechanism Save the next(or current) instruction location find the address to jump to (from an exception vector) jump to that location Memory Registers ALU Control

Memory Flat Address Space composed of words byte addressable Need to store Program Local variables Global variables and data Stack Heap Registers ALU Control

Memory Stack locals (parameters) Objects Heap Arrays Generated Code Registers ALU Heap Objects Control Arrays Generated Code

Registers Load/store architecture Memory Load/store architecture All operations are on register values Need to bring data in-to/out-of registers la Rdest, address [load address] lw Rdest, address [load word] li, Rdest, imm [load imm] sw Rsrc, address [store word ] mv Rdest, Rsrc [ move ] address has the from value(R) Important for performance limited in number Registers ALU Control

Other interactions Other operations Input/Output Memory Other operations Input/Output Privilege / secure operations Handling special hardware TLBs, Caches etc. Mostly via system calls hand-coded in assembly compiler can treat them as a normal function call Registers ALU Control

Registers (of MIPS processors)

Typical program layout 0x7fffffff Stack Start of the stack Heap management free lists starting location in the text segment locals (parameters) Heap Objects Arrays static Data segment Text segment 0x400000 Reserved

Procedure call and Stack Frame

Activations An invocation of procedure P is an activation of P The lifetime of an activation of P is All the steps to execute P Including all the steps in procedures that P calls

Lifetimes of Variables The lifetime of a variable x is the portion of execution in which x is defined Note that Lifetime is a dynamic (run-time) concept Scope is a static concept

Activation Trees When P calls Q, then Q returns before P does LIFO Stack Lifetimes of procedure activations are properly nested Activation lifetimes can be depicted as a tree

Example Class Main { void g() { return ; } void f() { g() ; } void m() { g(); f(); }; } m enter g enter g return f enter f return m return m f g Lifetime of invocations activation tree for m()

Example 2 Class Main { int g() { return 1; }; int f(int x){ if( x == 0) return g(); else return f(x - 1); } int m(){ return f(3) } } What is the activation tree for this example?

Example 2 m() enter f(3) enter f(2) enter f(1) enter f(0) enter m() g() enter g() return f(0) return f(1) return f(2) return f(3) return m() return m() f(3) f(2) f(1) g()

Notes The activation tree depends on run-time behavior The activation tree may be different for every program input Since activations are properly nested, a stack can track currently active procedures

Example Class Main { g() { return; }; f() { g() }; m() { g(); f(); }; Stack m

Example Class Main { g() { return; } f(): Int { g() } m() { g(); f(); } } m Stack m g g

Example Class Main { g() { return } f() { g() } m() { g(); f(); } } m Stack m f g f

Example Class Main { g() { return; } f() { g(); } m(){ g(); f(); } } m Stack m f g g f g

Revised Memory Layout High Address Stack Memory Code Low Address

Activation Records On many machine the stack starts at high-addresses and grows towards lower addresses The information needed to manage one procedure activation is called an activation record (AR) or (stack) frame If procedure F calls G, then G’s activation record contains a mix of info about F and G.

What is in G’s AR when F calls G? F is “suspended” until G completes, at which point F resumes. G’s AR contains information needed to resume execution of F. G’s AR may also contain: Actual parameters to G (supplied by F) G’s return value (needed by F) Space for G’s local variables

The Contents of a Typical AR for G Space for G’s return value Actual parameters Pointer to the previous activation record The control link; points to AR of caller of G Machine status prior to calling G Contents of registers & program counter Local variables Other temporary values

Example 2, Revisited Class Main { int g() { return 1; }; int f(int x) {if (x==0) return g(); else return f(x - 1); (**) }; void main() { f(3); (*)} AR for f: result argument control link return address

Stack After Two Calls to f main result Stack 3 f(3) (*) fp for f(2) result 2 f(2) (**) fp for f(1)

Notes main has no argument or local variables and its result is never used; its AR is uninteresting (*) and (**) are return addresses of the invocations of f The return address is where execution resumes after a procedure call finishes This is only one of many possible AR designs Would also work for C, Pascal, FORTRAN, etc.

Thus, the AR layout and the code generator must be designed together! The Main Point The compiler must determine, at compile-time, the layout of activation records and generate code that correctly accesses locations in the activation record Thus, the AR layout and the code generator must be designed together!

void foo(Foo f) { f.bar = new Bar(); } Heap Storage A value that outlives the procedure that creates it cannot be kept in the AR void foo(Foo f) { f.bar = new Bar(); } The Bar object must survive deallocation of foo’s AR Languages with dynamically allocated data use a heap to store dynamic data

Notes The code area contains object code For most languages, fixed size and read only The static area contains data (not code) with fixed addresses (e.g., global data) Fixed size, may be readable or writable The stack contains an AR for each currently active procedure. Each AR usually fixed size, contains locals Heap contains all other data In C, heap is managed by malloc and free

Stack Frames Push/pop frames prev frame arg n . arg 1 Static link incoming args Push/pop frames Access variables in deeper frames -> nonlocal variables Stack frame Local variables Parameters Return address Temporaries Register save area Usually has “standard” frame layout for several languages Depends on architecture frame pointer local variables return address temps saved registers lower memory addresses higher addresses current frame arg n . arg 1 static link outgoing args stack pointer next frame

Frame Pointer g(…) calls f(a1, a2, ………, an) : frame size arg n . arg 1 stack pointer arg n . arg 1 : frame size either fixed or varies => Can be determined very late frame pointer stack pointer

Registers register : local vars, temporary results… Can save load/store instructions general purpose vs. special purpose registers caller save vs. callee save register Ex: MIPS r16 - r23 are preserved across procedure calls (callee-save) r0 - r15 not preserved (caller-save) If we do interprocedure analysis, we can do fine register save scheduling If x is not needed after the call  caller-save but not save If x is need before and after the call  callee-save In general, register allocator (chapter 11)

Parameter Passing passing with stack (for machines designed in 1970s) passing some (k) in registers and others in stack k=6 or 4(mips: $a0~$a3) Need to save register when call another function To reduce memory traffic, need not save “argument registers” [into memory stack], when Leaf procedure – procedure does not call other procedures Interprocedural register allocation – analyze all functions Arguments become dead variables at the point where another function is called Register windows - each function call allocates a fresh set of registers

Parameter Passing (cont’d) argument passing in reg + stack Sometimes formal parameters are at consecutive addresses: register save area by callee call-by-reference Code for dereferencing formal parameter access no dangling reference int *f(int x) {return &x;} void f(int &y); arg k . arg 1 arg n arg k+1 frame pointer register save area

Return Address g calls f : f returns Need g’s address (resume point) -> return address Call instruction at address a -> return to a+1 (the next instruction) Can be saved On stack In special register In special memory location Hardware “call” instruction dependent Usually in designated registers Need to save (non-leaf proc) No need to save (leaf proc)

Frame-resident Variables Variables are written to memory only when necessary Variable will be passed by reference or & (address of) operator is applied Variable is accessed by a procedure nested inside the current one Value is too big to fit into a single register Variable is an array Register holding variable is needed for special purpose (parameter passing) Too many local variables (“spilled” into frame)

Escaped Variable A variable “escape”s if it is passed by reference, its address is taken, or it is accessed from a nested function. Variables are bound to register or memory in later phase in compiling. declarations vs. uses

Static Links prettyprint output write --output show n ident i,s --n Inner functions may use variables declared in outer functions Variable References Static Links Lambda lifting (passing all nonlocals as arguments) Display Procedure Calls prettyprint show ident ,

Static Link static link dynamic link return address parameter i a activation record contains a static link (pointer) that points to outer scope static link dynamic link return address parameter i b int a(int i) { int c() {return i+7;} int b(int i) {return i+c();} return b(2)- 3; } parameter i c static link dynamic link return address

Example Given the GNU C routine: void A(int a) { void B(int b) { void C(void) { printf(“C called, a = %d\n”, a); } if (b == 0) C() else B(b-1); B(a); draw the stack that results from the call A(2) how does C access the parameter (a) from A?

FP->static_link->static_link->param[#i] Answers dynamic links static links A 2 B 2 B 1 B 0 C FP->static_link->static_link->param[#i]

Lambda lifting outer-scope variables referencing: pass additional pointers int f() { int k = 5; int g(int t) { return k + t } return g(2); int g(int k, int t) { return k + t } int f() { int k = 5; return g(k, 2); Q: any idea what a closure is? A: record with a code address and argument pointers (to outer-scope variable). nested lifted

Lambda lifting out-of-scope variables referencing: pass additional pointers creating: heap (dynamic) allocation int aap(int *i) {return *i+7;} fptr mies(int i) { int *_i = malloc(sizeof(i)); *_i = i; return closure(aap,_i); } typedef int (*fptr)(); fptr mies(int i) { int aap() {return i+7;} return aap; } Q: any idea what a closure is? A: record with a code address and argument pointers (to outer-scope variable). nested lifted

Procedure linkages The linkage convention is the interface used for performing procedure calls on entry, establish p's environment at a call, preserve p's environment after a call, restore p’s environment on exit, tear down p's environment in between, handle addressability and lifetimes Ensures each procedure inherits from caller a valid run-time environment and also restores one for its caller

Procedure Linkages Standard procedure linkage Procedure has standard prolog standard epilog Each call involves a pre-call sequence post-return sequence procedure p prolog epilog pre-call post-return procedure q

Caller saved registers Stack Pre-Call When calling a new procedure, caller: push any t0-t9 that has a live value on the stack put arguments 1-4 on a0-a3 push rest of the arguments on the stack do a jal or jalr return address old frame pointer Local variables Calliee saved registers Stack temporaries ... argument 5 argument 4 Dynamic area Caller saved registers arguments fp sp

Caller saved registers Prolog Stack ... argument 5 argument 4 In a procedure call, the callee at the beginning: push $fp on the stack copy $sp+4 to $fp push $ra on the stack if any s0-s7 is used in the procedure save it on the stack create space for local variables on the stack execute the callee... old frame pointer return address Callee saved registers Local variables Stack temporaries Dynamic area Caller saved registers arguments fp stack frame old frame pointer return address Callee saved registers Local variables Dynamic area sp

Caller saved registers Epilog Stack ... argument 5 argument 4 fp In a procedure call, the callee at the end: put return values on v0,v1 update $sp using $fp ($fp-8) - ... Pop the callee saved registers from stack restore $ra from stack restore $fp from stack execute jr ra and return to caller old frame pointer return address Callee saved registers Local variables Stack temporaries Dynamic area Caller saved registers arguments sp

Stack Post-call On return from a procedure call, the caller: ... argument 5 argument 4 fp On return from a procedure call, the caller: Update $sp to ignore arguments pop the caller saved registers Continue... old frame pointer return address Calliee saved registers Local variables Stack temporaries Dynamic area sp

Caller saved registers Example Program class auxmath { int sum3d(int ax, int ay, int az, int bx, int by, int bz) { int dx, dy, dz; if(ax > ay) dx = ax - bx; else dx = bx - ax; … retrun dx + dy + dz; } int px, py, pz; px = 10; py = 20; pz = 30; auxmath am; am.sum3d(px, py, pz, 0, 1, -1); Dynamic area Caller saved registers Argument 7: bz (-1) Argument 6: by (1) Argument 5: bx (0) fp old frame pointer return address Local variable dx (??) Local variable dy (??) sp Local variable dz (??)

Frames in MiniJava Package Frame Frame.java Access.java AccessList.java Package Temp Temp.java, TempList.java, Label.java, LabelList.java Temp is used for temporary register Label is used for storage location Package Util BoolList.java Package T(Mips, Sparcs) T(Mips/Sparcs) Frame.java Inframe(), InReg(), newFrame(), allocLocal()

Package Frame Abstraction of Actual Frames package Frame; import Temp.Temp import Temp.Label; Public abstract class Access{ … } public class AccessList { public Access head; public AccessList tail; public AccessList(Access h, AccessList t) { head=h; tail=t;} }

Frame.java Hold information for parameters & local variables allocated in this frame public abstract class Frame { public abstract Frame newFrame(Temp.Label name, Util.BoolList formals); public Temp.Label name; //Function name public AccessList formals; //Parameters public abstract Access allocLocal(boolean escape); public abstract Temp.Temp FP(); //Frame Pointer public abstract Temp.Temp RV(); //Return Value /* ..other stuff, eventually … */ // public abstract int wordSize(); //Size of Word // public abstract Tree.Exp externalCall(String func, Tree.ExpList args); // public abstarct tree.Stm procEntryExit1(tree.Stm body ); }

TFrame : specific to Target Machine For T machine… package T; class Frame extends Frame.Frame { /* real definitions of Frame */ …. } In machine independent part of compiler // in class Main.Main: Frame.Frame frame = new T.Frame(…); To hide the identity of the target machine

Making new Frames Frame for function f with k formals newFrame(f, l) where f : Label l: BoolList Ex: a three-argument function named g with 1st argument escaped, i.e., needs to stay in memory frame.newFrame(g, new BoolList(true, new BoolList(false, new BoolList(false,null)))) (No parameters will be escapes in MiniJava.)

Class Access Access formal & local variables in the frame or in registers Abstract data type whose implementation is visible only inside the Frame module: package T class InFrame extends Frame.Access { int offset; InFrame (int o) {offset = o; } } class InReg extends Frame.Access { Temp.Temp temp; InReg(Temp.Temp t) {temp = t; }

Access and Allocate the Variables InFrame(X) : a memory location at offset X from the FP(frame pointer) InReg(t84) : in register t84 formals in Frame.java A list of k “accesses” denoting locations where the formal parameters will be kept at runtime , as seen from inside the callee May be seen differently by the caller and callee : “shift of view” View shift must be handled by “newFrame()”

Representation of Frame Descriptions Implementation of frame is an object holding: the location of all the formals instructions required to implement the “view shift” the number of locals allocated so far the “label” at which the function’s machine code is to begin See Table 6.4 on page 129

Local Variables To allocate a new local variable in a frame f f.allocLocal(true) // allocate in memory (stack) will return InFrame() access with an offset from FP ex) two local variables in Sparcs => InFrame(-4), InFrame(-8) f.allocLocal(false) // allocate in register will return InReg() ex) on register-allocated vars => InReg(t481) allocLocal(bool) Called when frame is create Called when nested block is entered

Allocating Local Storage in frame with the Same Name v function f() { var v1 := 6 print(v1); { var v2 := 7 print(v2); } { var v3 := 8 print(v3); allocLocal() Allocating Local Storage in frame with the Same Name v allocLocal() frame pointer v3 might use the same space of v1 or v2 v1 v2 v3 allocLocal() stack pointer

Escape Variables No variables escape in MiniJava, because there is no nesting of classes and methods it is not possible to take the address of a variable integers and booleans are passed by value object, including integer arrays, can be represented as pointers that are passed by value

Temporaries and Labels Temps are virtual registers May not be enough registers available to store all temporaries in a program Delay decision until later Labels are like labels in assembler, a location of a machine language instruction processing the declaration m(…) new Temp.Label(“C”+”$”+”m”) Classes Temp and Label in package Temp Packages Frame and Temp provide machine independent views of variables

Managing Static Links Static Link management is somewhat tedious? MiniJava does not have nested function declarations: thus Frame should not know anything about static links. It will be handled in the Translation phase. Static links may be passed to the callee by the 1st formal parameter.