1 / 67

Lecture 9

Lecture 9. Runtime Environment. Outline . Basic computer execution model Procedure abstraction run-time storage management Procedure linkage We need to understand how a program executes at run time before we can generate code for it. Memory. Registers. ALU. Control.

renate
Download Presentation

Lecture 9

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 9 Runtime Environment

  2. Outline • Basic computer execution model • Procedure abstraction • run-time storage management • Procedure linkage We need to understand how a program executes at run time before we can generate code for it

  3. Memory Registers ALU Control Basic Execution Model • MIPS as an example • CPU • ALU Unit • Registers • Control Unit • Memory • program • data

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

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

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

  7. Control Memory • Unconditional Branches • Fetch the next instruction from a different location • Unconditional jump to a given addressj label • Unconditional jump to an address in a registerjr rsrc • To handle procedure calls, do an unconditional jump, but save the next address in the current stream in a registerjal label [jump and link]jalr rsrc Registers ALU Control

  8. Control Memory • 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’ Registers ALU Control

  9. Control Memory • 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 Registers ALU Control

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

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

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

  13. Registers (of MIPS processors)

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

  15. The MIPS ISA and MIPS Processor • One of the earliest RISC processors • Has evolved from 1980’s • ISA has also evolved • Always backward compatible, I.e. add more to the ISA • MIPS-I, MIPS-II….MIPS-V • Many processor incarnation • From a simple 5-stage pipeline to an out-of-order superscalar • R2000, R4000, R8000, R10000 …..

  16. Procedure Abstraction • Decomposition of programs into callable procedures. • Issues: • calling /returning mechanism • parameter passing • local variables (scope) • private execution context • private storage for each procedure invocation • Encapsulate information about control flow & data abstractions The procedure abstraction is a social contract.

  17. Benefits of procedure abstraction 1. control abstraction • well defined entry, exits • mechanism to pass parameters, return values 2. name space • new name space within procedure • local names are protected from outside 3. external interface • accessed by procedure name, parameters • protection for both caller and callee • enables software libraries, systems 4. separate compilation • compile procedures independently • keeps compile times reasonable • allows us to build large programs

  18. Procedure Abstraction • procedure abstraction leads ... • multiple procedures • library calls • compiled by many compilers, written in different languages, hand-written assembly • For a compiler, we need to worry about • Memory layout • Registers • Stack

  19. Registers (of MIPS processors)

  20. Parameter passing disciplines • Many different methods • call by reference • call by value • call by value-result • How do you pass the parameters? • via. the stack • via. the registers • or a combination

  21. Homes for Variables? • A Simplistic model • Allocate a data area for each distinct scope • One data area per “sheaf” in scoped table • What about recursion? • Need a data area per invocation (or activation) of a scope • We call this the scope’s activation record • The compiler can also store control information there ! • More complex scheme • One activation record (AR) per procedure instance • All the procedure’s scopes share a single AR • Use a stack to keep the activation records

  22. Memory Layout 0x7fffffff Stack • Start of the stack • Heap management • free lists • starting location in the text segment locals (parameters) Objects Heap Arrays Data segment Text segment 0x400000 Reserved

  23. Run-time Resources • Execution of a program is initially under the control of the operating system • When a program is invoked: • The OS allocates space for the program • The code is loaded into part of the space • The OS jumps to the entry point (i.e., “main”)

  24. Code Memory Layout High Address Other Space Memory Low Address

  25. Notes • Our pictures of machine organization have: • Low address at the bottom • High address at the top • Lines delimiting areas for different kinds of data • These pictures are simplifications • E.g., not all memory need be contiguous • In some textbooks Higher addresses are at bottom

  26. What is Other Space? • Holds all data for the program • Other Space = Data Space • Compiler is responsible for: • Generating code • Orchestrating use of the data area

  27. Code Generation Goals • Two goals: • Correctness • Speed • Most complications in code generation come from trying to be fast as well as correct

  28. Assumptions about Execution • Execution is sequential; control moves from one point in a program to another in a well-defined order • When a procedure is called, control eventually returns to the point immediately after the call Do these assumptions always hold?

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

  30. Lifetimes of Variables • The lifetimeof 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

  31. Activation Trees • Assumption (2) requires that when P calls Q, then Q returns before P does • Lifetimes of procedure activations are properly nested • Activation lifetimes can be depicted as a tree

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

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

  34. Example 2 m() enter f(3) enter f(2) enter f(1) enter f(0) enter 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()

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

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

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

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

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

  40. Code Revised Memory Layout High Address Stack Memory Low Address

  41. 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) orframe • If procedure F calls G, then G’s activation record contains a mix of info about F and G.

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

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

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

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

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

  47. 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 generatormust be designed together!

  48. Discussion • The advantage of placing the return value 1st in a frame is that the caller can find it at a fixed offset from its own frame • There is nothing magic about this 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

  49. Discussion (Cont.) • Real compilers hold as much of the frame as possible in registers • Especially the method result and arguments

  50. Globals • All references to a global variable point to the same object • Can’t store a global in an activation record • Globals are assigned a fixed address once • Variables with fixed address are “statically allocated” • Depending on the language, there may be other statically allocated values

More Related