1 Lecture 9 Runtime Environment. 2 Outline Basic computer execution model Procedure abstraction...
-
date post
20-Dec-2015 -
Category
Documents
-
view
217 -
download
1
Transcript of 1 Lecture 9 Runtime Environment. 2 Outline Basic computer execution model Procedure abstraction...
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
Basic Execution Model MIPS as an example CPU
» ALU Unit» Registers» Control Unit
Memory» program» data
Memory
Registers
Control
ALU
4
Arithmetic and Logic Unit 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])
Memory
Registers
Control
ALU
5
Arithmetic and Logic Unit 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)
Memory
Registers
Control
ALU
6
Control 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
Memory
Registers ALU
Control
7
Control Unconditional Branches
» Fetch the next instruction from a different location
» Unconditional jump to a given addressj 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
8
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
9
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
10
Memory Flat Address Space
» composed of words» byte addressable
Need to store» Program» Local variables» Global variables and data» Stack» Heap
Memory
Registers ALU
Control
11
Memory
Memory
Registers ALU
Control
Stack
Generated Code
HeapObjects
Arrays
locals(parameters)
12
Registers 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
ALU
Control
Memory
Registers
13
Registers (of MIPS processors)
0 zero hard-wired to zero1 at Reserved for asm
2 - 3 v0 - v1 expr. eval and return of results4 - 7 a0 - a3 arguments 1 to 48-15 t0 - t7 caller saved temporary
16 - 23 s0 - s7 calliee saved temporary24, 25 t8, t9 caller saved temporary
28 gp pointer to global area29 sp stack pointer30 fp frame pointer31 ra return address
14
Other interactions 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
ALU
Control
Memory
Registers
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 abstractionsThe 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)
0 zero hard-wired to zero1 at Reserved for asm
2 - 3 v0 - v1 expr. eval and return of results4 - 7 a0 - a3 arguments 1 to 48-15 t0 - t7 caller saved temporary
16 - 23 s0 - s7 calliee saved temporary24, 25 t8, t9 caller saved temporary
28 gp pointer to global area29 sp stack pointer30 fp frame pointer31 ra return address
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 Start of the stack Heap management
» free lists starting location in
the text segment
Stack
Text segment
HeapObjectsArrays
locals(parameters)
0x7fffffff
0x400000
Reserved
Data segment
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
Memory Layout
Low Address
High Address
Memory
Code
Other Space
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
1. Execution is sequential; control moves from one point in a program to another in a well-defined order
2. 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 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
30
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
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
ExampleClass Main {
void g() { return ; }
void f() { g() ; }
void m() { g(); f(); };
} m
fg
g
m enter
g enter
g return
f enter
g enter
g return
f return
m return
activation tree for m() Lifetime of invocations
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 2m() 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) returnf(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
ExampleClass Main {
g() { return; };
f() { g() };
m() { g(); f(); };
}m Stack
m
37
ExampleClass Main {
g() { return; }
f(): Int { g() }
m() { g(); f(); }
} m
g
Stack
m
g
38
ExampleClass Main {
g() { return }
f() { g() }
m() { g(); f(); }
}m
g f
Stack
m
f
39
ExampleClass Main {
g() { return; }
f() { g(); }
m(){ g(); f(); }
} m
fg
g
Stack
m
f
g
40
Revised Memory Layout
Low Address
High Address
Memory
Code
Stack
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) or frame
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:result
argument
control link
return address
45
Stack After Two Calls to f
main result
3
(**)
f(3)
result
2
(*)
f(2)
Stack
fp for f(1)
fp for f(2)
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 generator must 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
51
Memory Layout with Static Data
Low Address
High Address
Memory
Code
Stack
Static Data
52
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
53
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
54
Notes (Cont.) Both the heap and the stack grow
Must take care that they don’t grow into each other
Solution: start heap and stack at opposite ends of memory and let the grow towards each other
55
Memory Layout with Heap
Low Address
High Address
Memory
Code
Heap
Static Data
Stack
56
Data Layout Low-level details of machine architecture are
important in laying out data for correct code and maximum performance
Chief among these concerns is alignment
57
Alignment Most modern machines are (still) 32 bit
» 8 bits in a byte» 4 bytes in a word» Machines are either byte or word addressable
Data is word aligned if it begins at a word boundary
Most machines have some alignment restrictions» Or performance penalties for poor alignment
58
Alignment (Cont.) Example: A string
“Hello”
Takes 5 characters (without a terminating \0)
To word align next datum, add 3 “padding” characters to the string
The padding is not part of the string, it’s just unused memory
59
Procedure Linkage and Activation Records
60
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
61
Procedure LinkagesStandard procedure linkage
procedure p
prolog
epilog
pre-call
post-return
procedure q
prolog
epilog
Procedure has
• standard prolog
• standard epilog
Each call involves a
• pre-call sequence
• post-return sequence
62
return addressold frame pointerStack
Local variables
Calliee savedregisters
Stack temporaries
... argument 5argument 4
Dynamic area
Caller saved registers arguments
fp
sp
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
Pre-Call
63
return addressold frame pointer
return addressold frame pointer
Stack
Local variables
Callee savedregisters
Stack temporaries
... argument 5argument 4
Dynamic area
Local variables
Callee savedregisters
Caller saved registers arguments
Dynamic area
fp
sp
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...
Prolog
stack frame
64
return addressold frame pointer
Stack
Local variables
Callee savedregisters
Stack temporaries
... argument 5argument 4
Dynamic area
Caller saved registers arguments
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
fp
sp
Epilog
65
Stack On return from a procedure
call, the caller:» Update $sp to ignore
arguments» pop the caller saved
registers» Continue...
return addressold frame pointer
Local variables
Calliee savedregisters
Stack temporaries
... argument 5argument 4
Dynamic area
fp
sp
Post-call
66
Argument 5: bx (0)
Example Programclass 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);
return addressold frame pointer
Dynamic area
Caller saved registers
Argument 7: bz (-1)
fp
sp
Argument 6: by (1)
Local variable dx (??) Local variable dy (??) Local variable dz (??)
v0 ??v1 ??a0 thisa1 ax (10)a2 ay (20)a3 az (30)v0 ??v1 ??t0 ??t1 ??
67
Caller/Callee Responsibility Caller Callee pre-call sequence prolog code allocate basic frame save registers,
state evaluate & store params. extend basic frameCall store return address (for local data) store FP find static data area set FP for child initialize locals jump to child fall through to code post-return sequence epilog code copy return value store return valueReturn deallocate basic frame restore state restore params.(?) unextend basic
frame (call-by-value-save) restore parent's FP jump to return address