Transcript No Slide Title

Chap 7: Runtime Organization
CSE
4100
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Way, Unit 2155
Storrs, CT 06269-3155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
Material for course thanks to:
Laurent Michel
Aggelos Kiayias
Robert LeBarre
CH7.1
Overview
CSE
4100


Runtime Environment Focuses on the wayt hat a
Program is Managed/Controlled During its Execution
We’ll Focus on
 Basic Definitions and Concepts
 A First Look at Activation Records
 Memory Allocation Strategies
 Revisiting Activation Records
 Impact of Parameter Passing Mechanisms
 Data Layout and Scoping of Declarations
 Memory Manager and Compilation Process
 Concluding Remarks/Looking Ahead
CH7.2
Basic Definitions and Concepts
CSE
4100




Procedure Definition
 Declaration that has a Name and has a Body
 If Returns a value, then Function
Procedure Definition Contains a Sequence of
Identifiers Called the Formal Parameters
Procedure Call Contains a List of Arguments passed to
the Procedure or the Actual Parameters
Information in Program can be Characterized
 Environment: Maps Name to Storage Loc (l-value)
 Store: Maps Location to Value it Contains
(l-value to an r-value)
Compile
Time
Environment
Name
Storage
State
Run
Time
Value
CH7.3
Program Organization
CSE
4100


Purpose
 Define what constitutes a Program
 Review overall OS Structure
 Examine Process Structure
 Present and Understand Memory Management
issues
Remember, a Compiler Must:
 Target a Specific Operating System
 Interact within that Operating System
 Provide Access at Machine Level to Operating
System Components
CH7.4
The Basic Abstractions
CSE
4100



Processes
 Unit of Computation
 Program/Application Composed of One or More
Interacting Processes
 Processes Interact with and Utilize Resources
Files
 Unit of Information Storage
 Classic, Default Utilized to Support Programs
 Read, Write, and Transfer via Files
Other Resources
 CPU, Printer, Memory, etc.
 Network, Display, etc.
CH7.5
Program, Processes & Resources
CSE
4100
Resources
Processes
Operating System
Data
Program
CPU
Memory
Device
Device
Device
Device
Hardware
CH7.6
What are Executables?
CSE
4100

Executable
 File Containing Machine Code
 Examples
 A bash script, a perl script, a ‘compiled’ java program, a
compiled C program, ...
 Java Bytecode and JVM
CH7.7
Java Virtual Machine (JVM)
CSE
4100


JVM is a Platform Specific Program which Interprets
and Executes Java Code
JVM Interprets and Executes Bytecodes
CA FE BA BE 00 03 00 2D 00 3E
08 00 3B 08 00 01 08 00 20 08


JVM Targeted as Small/Efficient - Embeddable within
Consumer Electronics
JVM Stack Based Machine - Simulates Real Processor
CH7.8
Java Visualization
CSE
4100
CH7.9
What are Executables?
CSE
4100

Native Executable
 File Containing Machine Code that the CPU
understands without any intervening “layers” of
abstractions
 Examples
 A compiled C program
 A Java program compiled natively with Gnu Compiler
for Java
CH7.10
From Code to Loaded Program
CSE
4100
ORIGINAL SOURCE
RELOCATABLE OBJECT MODULE
static int gVar;
. . .
int proc_a (int arg){
. . .
gVar = 7;
put_record(gVar);
. . .
}
0000
. . .
0008
. . .
0036
. . .
0220
0224
0228
0232
. . .
0400
0404
. . .
0500
0540
0600
0799
. . .
entry
proc_a
[Space for gVar]
load
store
push
call
=7, R1
R1, 0036
0036
‘put_record’
External Reference Table
‘put_record’ 0232
External Definition Table
‘proc_a’
0008
(optional symbol table)
(last location in module)
CH7.11
From Code to Loaded Program
CSE
4100
THE ABSOLUTE PROGRAM
0000
. . .
1008
. . .
1036
. . .
1220
1224
1228
1232
1399
. . .
2334
. . .
2670
2999
(Other Modules)
PROGRAM AT LOCATION 4000
0000
4000
entry proc_a
. . .
5008
[Space for gVar]
. . .
5036
load
=7, R1
. . .
store R1, 1036
5220
push
1036
5224
call
2334
5228
(end of proc_a)
5232
(Other Modules)
5399
entry put_record
. . .
6334
(opt. symbol table)
. . .
(last loc. in module) 6670
6999
7000
(Other Processes)
(Other Modules)
entry
proc_a
[Space for gVar]
load
=7, R1
store R1, 5036
push
5036
call
6334
(end of proc_a)
(Other Modules)
entry put_record
(opt. symbol table)
(last loc. in module)
(Other Processes)
CH7.12
What is a Process?
CSE
4100



An Executable with its Execution Context and State
Consists of:
 Executable (.exe, a.out, etc.)
 Loaded into main memory
 All of the resources currently committed
 With the value of all the CPU registers
Computers can Run Multiple Processes at Same Time
CH7.13
What is a Process?
CSE
4100




Sequential Program for Execution
 Object Program (a.out) to Execute
 Data on Which Program will Execute
 Resources Required During Execution
 Status of the Process’ Execution (ps -aux)
Program is “Static Source Code/Executable
Statements” which Lacks Data Set
Process is “Dynamic Entity Executing on Actual Data
Set”
For Example, Multiple Unix Users Can Execute emacs,
Latex, vi, grep, at same Time
 Shared Program Executable emacs
 Dedicated Process for Each User of emacs
CH7.14
A Process
CSE
4100
Code
Data
Resources
Resources
Resources
Process Status
Abstract Machine Environment (OS)
CH7.15
UNIX Process
CSE
4100
Text
Resources
Resources
Data
Stack
Process Status
File
File
UNIX kernel
CH7.16
More on UNIX Processes
CSE
4100




USER
wangz
manish
marios
steve
root
Each Process Has its Own Address Space
 Subdivided into Text, Data, & Stack Segment
 a.Out File Describes the Address Space
OS Creates Descriptor to Manage Process
Process Identifier (PID) is Integer: User Handle for the
Process (Descriptor)
Try “ps” and “Ps aux” (Read Man Page)
PID %CPU %MEM
SZ RSS TT
25150 26.1 15.33048019308 pts/16
7590 25.1 0.821436 964 ?
29536 0.6 3.5 5156 4376 pts/6
29893 0.2 0.8 1080 980 pts/18
29905 0.2 0.7 1040 888 pts/18
S
START TIME COMMAND
O
Aug 05 6318:26 /apps/matlab/bin/s
O
Jul 22 24628:34 /apps/matlab/bin/s
S 13:22:23 0:24 mailtool
S 17:41:11 0:00 -csh
O 17:41:53 0:00 ps -aux
CH7.17
Multiprogramming
CSE
4100




Load and Execute Multiple Programs into SpaceMultiplexed Mem. while Time-Multiplexing CPU
Technique for Sharing the CPU Among Runnable
Processes
 Process May Be Blocked on I/O
 What is Deadlock and How can it Occur?
 Process May Be Blocked Waiting for Other
Resources to Complete
 What is Starvation and How is it Prevented?
While One Process is Blocked, Another Should Be
Able to Run
Multiprogramming OS Accomplishes CPU Sharing
“Automatically”
CH7.18
How Multiprogramming Works
Space-Multiplexed Memory
CSE
4100
Process 1
Process 2
CPU
Process 3
Time-Multiplexed
Process 4
CH7.19
Batch Processing
CSE
4100









Uses Multiprogramming
Job (File of OS Commands) Prepared Offline
Batch of Jobs Given to OS at One Time
OS Processes Jobs One-After-the-Other
No Human-Computer Interaction
OS Optimizes Resource Utilization
Batch Processing (as an Option) Still Used Today
Batch Files in DOS/Unix to Repetitively Execute Same
Set of Commands
ASIDE: Using Batch Processing
 1978/79 First Two Computer Courses at BC
 Keypunch IBM Cards
 Run Batch Job: Return 1-2hrs Later for Output
CH7.20
Timesharing
CSE
4100






Uses Multiprogramming
Support Interactive Computing Model (Illusion of
Multiple Consoles)
Different Scheduling & Memory Allocation Strategies
Than Batch
Tends to Propagate Processes
Considerable Attention to Resource Isolation (Security
& Protection)
Tend to Optimize Response Time
CH7.21
How Timesharing Works
CSE
4100




Timesharing Still
Pervasive in Computing
Engineering Network Still
Time-Shared in Some
Respects
 Access to User Files
 Email/Web Server
 Download Software
Terminals Replaced by
Unix Workstations and
PCs
Example of Network File
System/OS
Terminal Multiplexor
VM
VM
VM
Timesharing OS
CH7.22
Personal Computers
CSE
4100



CPU Sharing Among One Person’s Processes
Ability of Only One Active Process at One Time
 Early Apple/Mac: Only do 1 Action at Time
 Same for Win 3.1 and Win 95
 Improved with Win 98 and NT
 Today’s Apple and Windows MS – Multi-Process!
Increased Power of Computing for Personal Tasks
 Graphics - Two-D, Three-D, Real-Time
 Multimedia - CDs and DVDs
CH7.23
Process Control & Real-Time
CSE
4100





Computer is Dedicated to a Single Purpose
Classic Embedded System
Must Respond to External Stimuli in Fixed Time
Continuous Media Popularizing Real-time Techniques
An Area of Growing Interest
 Embedded Computing Estimated as one of Key
Technologies for 21st Century
 Pervasiveness: Consumer Products/Electronics
 Cars, Refrigerators, Phones, Microwaves, etc.
 Elevators, “Smart” Products and Buildings, etc.


Embedded Java
Microsoft CE
CH7.24
Evolution of Modern OS
CSE
4100
Timesharing
Batch
Memory Mgmt
Scheduling
Protection
Memory Mgmt
Protection
Scheduling
Files
Devices
Network OS
PC & Wkstation
System
Software
HumanComputer
Interface
Client-Server Model
Protocols
Real-Time
Scheduling
Modern OS
Java/JINI/JavaOS
CH7.25
Virtual Address Space
CSE
4100



An Abstraction provided by the Operating System
Essentially
 A sandbox for the process
Practically
 A Contiguous Memory area that





Starts at offset 0
Ends at offset 232-1
Entirely devoted to a single process
Is transparently managed by the O.S.
Has a layout imposed by the O.S.
CH7.26
Virtual Memory
CSE
4100



Components of Program (Identifiers, Labels, variables,
etc.) Define Name Space
Language Translation
 Converts Name Space Elements to Virtual
Addresses
 Binds Symbolic Names to Virtual Addresses
Virtual Memory System
 Dynamically Binds Virtual Addresses to Physical
Addresses
 Defers Binding Decision to During Program
Execution
 Perform Binding “As Needed”
CH7.27
Names, Virtual Addresses, Physical Addresses
CSE
4100
Distinguish Between
Symbolic Names vs. Virtual Addrs. vs. Physical Addrs.
Source
Program
Absolute
Module
Executable
Image
Name Space
Compile and
Link Tools
Virtual
Address Space
Physical
Address Space
Yt: Virtual Address Space  Physical Address Space  {}
CH7.28
Virtual Address Space

CSE
4100
Traditional Organization
 Code Area at the
bottom
 Static Data above
0xffffffff
 Constants
 Static strings
 Static variables

Heap
 Grows upward

Stack
 Grows downward

0x0
Lot’s of free VM in
between
CH7.29
OS Conventions
CSE
4100


Layout is dictated by the OS
 Specifically by the “Loader”
Loader
 The OS module responsible for
 Allocating a virtual address space
 Bringing the content of the executable file into the
address space
 Bringing any dependent shared library into the address
space
 Performing any required relocation
 Transferring control to the entry point of the program.
CH7.30
Zooming In.
CSE
4100

Close look on the code area
CH7.31
Loading
CSE
4100


Loader extracts the information from the executable
Executable holds a header with
 Offset and size of code (blue area)
 Offset of entry point (main) within blue box
 Offset and size of constant data (green area)
 List of needed shared library (optional)
Program
Executable:
CH7.32
Loading and Execution
CSE
4100


Loader
 Grabs file zones and move them in virtual memory
 Relocate the code as necessary
 Sets up the execution stack
 Transfer control to the entry point with a jump
Execution Stack
 A memory area at the top of the VM
 Grows downward
 Grows on demand (with OS collaboration)

Purpose
 Automatic storage for local variables
CH7.33
A First Look at Activation Records
CSE
4100

Storage Organization for
Program Execution

Code Referenced by PC
Code

Global/Local Variables
Static Data



Static Data Area
Stack Contains

Set of Activation
Records

All Active Procedures
and Functions
Heap for Dynamic Memory
Allocation
Stack
Heap
CH7.34
A General Activation Record
CSE
4100
Returned Value

To the Calling Procedure

Passed in to Procedure

To Act. Record of Caller

Referenced Non-Local Data
Optional Access Link

Needed to Restart Caller
Saved Machine Status

Local Variables for Scope
Local Data

Compiler Generated
Temporaries
Actual Parameters
Optional Control Link
CH7.35
An Activation Record in C
CSE
4100

Actual Parameters
Supplied by Caller
Etc.
Incoming Param 2
Incoming Param 1

Needed to Restart Caller
Saved State Info

Local Variables for Scope
Local Variables
Temporary Storage

If Callee Calls Another
Procedure/Function
Outgoing Parameters
CH7.36
Activation Records
CSE
4100


Procedure Activation Represents the Actions that Must
Occur when a Caller Invokes a Callee:
 Transfer of Actuals into Formals by the Language’s
Parameter Passing Mechanism
 Modification of Environment and State by Alloc of
Memory for Variables that are Local to Callee
 Identification of the Control Return Point of Caller
After Callee Complets
Every Procedure Activation has Lifetime which is the
Sequence of Steps (Code) of Procedure Body of
Callee
CH7.37
What are Possible Activations?
CSE
4100




Nested
 A calls B calls C
Non-Overlapping
 A calls B
 B calls C
Recursive
 A calls itself
Concurrent
 A calls B (spawns process)
 A calls C (spawns process)
 B, C: execute in parallel and compete for Resources
CH7.38
Activation Tree
CSE
4100

Graphical Representation of Activations over Time
CH7.39
How is Tree Interpreted?
CSE
4100






Each Node is a Specific Procedure Call
Root Node is Start of Program
Parent Node
 Flow from Parent to Child
 Caller to Callee
Sibling Node
 All Nodes to Left have Completed
Parent Comples when All Children Complete
Utilize Control Stack to Represent Current State of an
Activation
 s, q(1,9), q(1,3), q(2,3)
 Where is this on Prior Slide?
 Represents “state” at Point in Time
CH7.40
Relationship to Environment and State
CSE
4100

Recall:
Compile
Time
Environment
Name
State
Storage
Run
Time
Value
Assignments Change State
 Declarations Change Environment
Differentiation also Possible from Static and Dynamic
Levels
Environment
State
Procedure Definition vs. Procedure Activation


Name Declaration
vs.
Scope of Declaration vs.
Name Binding
Lifetime of Binding
CH7.41
Issues Impacting Runtime Environment
CSE
4100









Are Procedure/Functions Recursive?
What happens to Values of Local names after the
Procedure Activation Completes?
Can a Procedure Refer to Non-Local Names?
What are Parameter Passing Mechanisms?
How are Results Returned from Functions?
Can Proc/Func be Returned as a Result? Passed as
Parameters?
Can Programmer Dynamically Allocate Storage?
How is Deallocation Handled?
These are:
 Rules of the Game
 What Every Software Engineer Should Know!
CH7.42
Memory Allocation Strategies
CSE
4100



Details the way that Memory
is Managed within OS
Crucial for Activation Records
Different Allocation Strategies
Used by Each Area
 Static – Compile Time
 Stack – Run Time
Code
Static
Stack (Automatic)
 Sizes of Data Known at
Compile Time
 Parameters during Calls

Heap – Run Time
 Allocate and Deallocate
Memory (malloc)
 Programmatic Needs
Heap (Dynamic)
CH7.43
Memory Pools
CSE
4100
Where does memory comes from ?
 Three pools
 Static
 Automatic (Stack)
Automatic (Stack)
 Dynamic

Dynamic
Static
CH7.44
Static Pool
CSE
4100

Content
 All the static “strings” that appear in the program
 All the static constants used in the program
 All the static variables declared in the program





static int
static arrays
static records
static ....
Allocation ?
 Well... it is static, i.e.,
 All the sizes are determined at compile time.
 Cannot grow or shrink
CH7.45
Static Allocation
CSE
4100



Binding Names to Storage Location at Compile Time
Program and Procedure/Function Variables
Consider C Program:
int xyz;
char c[20];
Global vars known at compile time
int abc ()
{
Static means to allocate at compile
static int x;
. . .
{
Data values persist over multiple
static int y;
calls to abc()
. . .
}
x, y: retain values in successive
. . .
calls to abc!
}
CH7.46
Static Allocation
CSE
4100



Static Allocation is Limited and Programming
Language Specific
 In Pascal, Global Program Variables Only
 In C, Global Variables and Specific Static
What are Implications to Compilation Process?
Are these two Programs Same? Why? Different?
How?
main()
{
int x[1000000];
. . .
}
main()
{
static int
. . .
}
x[1000000];
CH7.47
Automatic Pool (Stack Allocation)
CSE
4100




Content
 Local variables
 Actuals (arguments to
methods/functions/procedures)
Allocation
 Automatic when calling a
method/function/procedure
Deallocation
 Automatic when returning from a
method/function/procedure
Management policy
 Stack-like
CH7.48
Automatic Pool (Stack Allocation)
CSE
4100




Tightly Coupled with Procedure Activation
Parameters, Local Variables, Temporary Variables
 Allocated as Each Procedure/Function Called
 Stack Expands for Nested (and Recursive) Calls
Two Step Process
 Call Sequence: Allocation Activation Record and
Enter Data into its Fields
 Return Sequence: Restores State of Program to
Caller to Continue Execution
What Does Caller vs. Callee Do?
CH7.49
Caller and Callee
CSE
4100
CH7.50
Caller vs. Callee
CSE
4100


Call Sequence
 Caller Evaluates Actuals
 Caller Stores Return Address and “old” Value of
top_sp in Callee’s Activation Record
 Callee Saves Register Values and other Status Info.
 Callee Inits its Local data and Begins Execution
Return Sequence
 Callee Places a Return value Adjacent to Activation
Record of Caller
 Using Status Info, callee Restores top_sp and
Registers, and Jumps to Return Addres iN caller
 Caller Copies Return Value into its Own Activation
Record for Subsequent Usage
CH7.51
What are Possible Problems
CSE
4100

Passing Arrays by Value
int x [10000];
char c[20];
abc (t: -----)
{ . . .
zzz(t);
. . .
}
What Happens to Stack During
these multiple calls?
What’s the Problem Here?
What are two Possible Solutions?
xyz (a: -----)
{ . . .
abc(a);
. . .
}
xyz(x);
CH7.52
What are Possible Problems
CSE
4100

Dangling References
main()
{
int *p;
p = call_it();
}
int *call_it ()
{
int i = 23;
return &i
}
Is there a Problem?
What is it?
How is it Solved?
CH7.53
Heap (Dynamic) Allocation
CSE
4100


Allows for the Management of Dynamic Storage:
 Allow Local Names to Persist When Procedure
Activation Completes
 When a Called Activation Outlives Caller (Fork off
a Process )
Important Issues Include:
 How Does Allocation Occur?
 Is Garbage Collection Available for Programmer
Initiated Deallocation?
 Or, does Deallocation Occur Automatically?
CH7.54
Dynamic Pool
CSE
4100


Content
 Anything allocated by the program at runtime
Allocation
 Depends on the language
C
 C++/Java/C#
 ML/Lisp/Scheme

malloc
new
implicit
Deallocation
 Depends on the language
C
 C++
 Java/C#/ML/Lisp/Scheme
free
delete
Garbage collection
CH7.55
Revisiting Activation Records
CSE
4100




Focus on Execution Environment for Imperative
Language (C, C++, Java, Pascal, etc.)
Code Reference by Program
Code
Counter
Stack Contains Activation
Static Data
Records (Grows Down)
Stack
 Snapshot of Activations
 Status of Execution
Heap for Dynamic Memory
(Grows Up)
Heap
CH7.56
What Activation Record Contains?
CSE
4100
CH7.57
Recall Activation Record in C
CSE
4100

Actual Parameters
Supplied by Caller
Etc.
Incoming Param 2
Incoming Param 1

Needed to Restart Caller
Saved State Info

Local Variables for Scope
Local Variables
Temporary Storage

If Callee Calls Another
Procedure/Function
Outgoing Parameters
When Callee Invokes/Activates Another Procedure,
Outgoing Parameters of One Record are Incoming Parameters
of Another Activation Record
CH7.58
Activation Records
CSE
4100

Also known as “Frames”
 A record pushed on the execution stack
CH7.59
Creating the Frame
CSE
4100

Three actors
 The caller
 The CPU
 The callee
int foo(int x,int y) {
...
}
bar() {
...
x = foo(3,y);
...
}
CH7.60
Creating the Frame
CSE
4100

Three actors
 The caller
 The CPU
 The callee
int foo(int x,int y) {
...
}
bar() {
...
x = foo(3,y);
...
}
Actual Function Call
CH7.61
Creating the Frame
CSE
4100

Three actors
 The caller
 The CPU
 The callee
int foo(int x,int y) {
...
}
bar() {
...
x = foo(3,y);
...
}
CH7.62
Closeup on Management Data
CSE
4100
Links Allow Callee
to Refer to
Non-Local Scopes
CH7.63
Returning From a Call
CSE
4100

Easy
 The RET instruction
simply
Access MGMT Area from
FP
Restores SP
Restores FP
Transfer control to return
address
CH7.64
Returning From a Call
CSE
4100

Easy
 The RET instruction
simply
Access MGMT Area from
FP
Restores SP
Restores FP
Transfer control to return
address
CH7.65
Returning From a Call
CSE
4100

Easy
 The RET instruction
simply
Access MGMT Area from
FP
Restores SP
Restores FP
Transfer control to return
address
CH7.66
Returning From a Call
CSE
4100

Easy
 The RET instruction
simply
Access MGMT Area from
FP
Restores SP
Restores FP
Transfer control to return
address
CH7.67
Variations
CSE
4100

This is architecture dependent
 On Intel:
 The arguments are on the stack
 The return address is on the stack
 The return value is always in the accumulator (eax
register)

On PPC





The first 8 arguments are in registers
Remaining arguments are on the stack
Space is reserved for all arguments anyway
The return address is in the LINK register
The return value is left in R1 (register 1)
CH7.68
Impact of Parameter Passing Mechanisms
CSE
4100



Different Parameter Passing Mechanisms all have
Different Techniques for Handling Formal and Actual
Parameters
We’ll Consider Four Approaches
 Call By Value
 Call By Reference
 Copy Restore
 Call By Name
In Process…
 Consider Impact on Environment and State
 Identify Which Languages Use Each Approach
CH7.69
Call By Value
CSE
4100

Environment and State of Actual/Formals is Different
 Push on the stack a copy of the argument
 Size depends on argument type
 Any write operation overwrites the copy
 Copy automatically discarded on exit
swap (x, y: integer);
x
y
var temp: integer;
begin
temp := x;
x and y are in callee’s
x := y;
activation record (scope)
y := temp;
a and b are in caller’s
end;
activation record (scope)
. . .
int a, b;
. . .
a
b
swap (a, b)
Print(a, b)
Do a and b Change?
CH7.70
Call By Reference
CSE
4100


Actuals and Formals Refer to Same Storage Location
 Place the address of the actual on the stack
 A write operation simply follows the pointer
 Locations are Passed!
Advantages?
swap (var x, y: integer); a and b are in caller’s
activation record (scope)
var temp: integer;
begin
x
y
temp := x;
x := y;
y := temp;
end;
. . .
int a, b;
. . .
a
b
swap (a, b)
Print(a, b)
CH7.71
C is Call by Value ONLY!
CSE
4100


Swap Will NOT Change a
and b
Values are Unchanged!
main()
{
int x=5, y=10;
swap (x, y);
}
void swap (int x, y);
{
int temp;
temp := x;
x := y;
y := temp;
}

Fake “Call by Reference”
main()
{
int x=5, y=10;
swap (&x, &y);
}
void swap (int *px, *py);
{
int temp;
temp := *px;
*px := *py;
*py := temp;
}
What is Effect of Call?
CH7.72
Copy Restore
CSE
4100


Call by Value Result in Ada Programming Language
Three Types of Parameters in Ada:
 In: Corresponding to Value Parameters
 Out: Corresponding to Copy-Out Phase
(Final r-value of Formals Copied out to Actuals)
 Inout: Either
 Call by Reference
 True Call by Value Result (Compiler Dependent)

How Does this work?
CH7.73
Copy Restore
CSE
4100


Key Interpretation
 If an Actual has Just an r-value - Call By Value
 If an Actual has a l-value then Copy Out Formal to
Actual – Storage not Shared!
What Does Following Code do:
program copyout (input, output);
var a: integer;
procedure unsafe (var x: integer);
begin
x := 2; a := 0;
end;
begin
a := 1;
unsafe(a);
writeln(a);
end.
x
a
CH7.74
Call By Name
CSE
4100


Two Views of this Process
 Macro Expansion in C where a Substitution of
Procedure Code (the Callee) Occurs to Replace a
Call (in Caller)
 Substitution of the Actual Parameters (from Caller)
into the Procedure Itself (into Callee)
What are Implications of each Approach?
CH7.75
Version 1: Macro Expansion
CSE
4100
int x = MAXBUF + 1;
int m = 0;
void p(void) {m=(m+1)%x;}
int out (void)
{
int x;
x = buf[m];
p();
return x;
}
int x = MAXBUF + 1;
int m = 0;
void p(void) {m=(m+1)%x;}
int out (void)
{
int x;
x = buf[m];
{ m = (m+1) % x; }
return x;
}
What Happens when { m = (m+1) % x; }
is substituted for p()?
How Does Resulting Code Work?
CH7.76
Version 2: Actual Substitution
CSE
4100
Procedure Definition
Procedure Call
void q(int y)
{
int i;
i = 5;
y = y + 1;
}
main()
{
int i;
int A[10];
i = 6;
q (A[i]);
}
What is a result of this Call by Substitution
A[i] (actual) into y (formal)?
{
int i;
i = 5;
A[i]) = A[i]) + 1;
}
CH7.77
Parameter Passing - Synopsis
CSE
4100


Call by Value
 Environment and Store of Actuals and Formals are
Distinct
 Environment maps to Separate l-values and Store
Maps to Separate r-values
Call by Reference
 Formals and Actual MAY have Different Variable
Names
 However, Environment Maps those Different
Names to the Same l-Values
 NY City vs. Big Apple
 Boston vs. Beantown

CH7.78
Parameter Passing - Synopsis
CSE
4100

Call by Value Result
 Copy in Phase
 Formals have Separate l-values and contain r-values of
Actuals
 l-values of Actuals are Saved
Copy Out Phase: Copy Final values of Formals to
Saved l-values of Actuals
Call by Name: Textual Substitution
 Procedure Body of Code Replaces Call
 Actuals for Formals


 Formals Don’t have Own Environment and Store
 Locals have Own Environment and Store
 Environment and Store of Actuals are Used
CH7.79
Data Typing and Layout
CSE
4100



Basic and Advanced Data Types Play a Role in
Procedure Activation
Basic Types
 Compute Map, Relative Address, and Offsets at
Compile Time for Local Data in Act. Record
Two Important Concepts
 Alignment: Data Place at specific Positions in
Memory (Ints at Addresses Divisible by 4)
 Padding: Extra Space to Arrive at a Boundary
(Char(5) may allocate 6 or even 8 bytes)
CH7.80
Consider an Example in C
CSE
4100

What is a Possible Memory Layout?
main()
{
int i1;
. . .
for . . .
{int c;
if. . .
{int i2;
. . .
}
. . .
while
{int i3;
. . .
}
}
Need own l-value since
global scope
i1
c,i3
i2
Share l-value since
independent scopes
Need own l-value since
nested scope
CH7.81
Advanced Data Types
CSE
4100





Arrays, Records, Variable Records, Classes, etc. all
Have Sizes that are Known at Compile Time
Dynamic Types (Lists, Sets, etc.) have Fixed
Component Sizes (Size of List Element), but are
Allocated at Runtime
For Static Types
 Runt Time We must Compute Addresses of
Variable References
 Anticipate this Need at Compile Time to Simplify
and Speed Access
For Dynamic Types
 Consider their Definition and Usage
We’ll Briefly Review Arrays …
CH7.82
One Dimensional Arrays
CSE
4100

Data Stored in Consecutive Locations
A[0] A[1] A[2] A[3]




Slots each have Same Width w
1st Slot Begins at Location Base
Slots are:
 base, base + w, base +2w, etc.
 i*w + (base –low*w) where i is the index and low
is the lower bound of the array
Compiler Computes:
 c=(base – low*w)
 Runtime calculation is: i*w + c
CH7.83
Two Dimensional Arrays
CSE
4100

Stored in Row Major Order (row by row)
M[1,1] M[1,2] M[2,1] M[2,2] M[3,1] M[3,2]


Compute M[i,j] = i*r + j*e + (base – lowr*r – lowe*e)
where
 r and e are widths of rows and elements
 lowr and lowe are lower bounds of row and
element of a row
Simplify to d = (base – lowr*r – lowe*e)
with runtime calculation of:
 i*r + j*e + d
CH7.84
Scope of Declarations
CSE
4100




Recall Languages have Scoping Rules
Two variations
 Everything Declared up-front
 Scoped declarations
Pascal
 Local Scope within Procedure or Function
 Non-Local to Parent, Grandparent, etc.
 Proc/Func can be Defined within other Proc/Func
in Order to “Hide” their Existence (Scope)
C
 Local Scope within {}
 When Hit }, the Lifetime of the Identifiers End
 Non-Local within “File”
 Visibility within Blocks
CH7.85
Declarations Ahead
CSE
4100

Convention used by C
 Simplify the compiler
 After reading the declaration we know exactly the
frame size.
int foo(int x,int y) {
int a, i;
int* d;
float b;
bool c,e, g;
while (x < 100) {
d = alloca(sizeof(int)*y);
if (y > 0) {
...;
}
}
for(i=0;i<x;i++) {
g = ...;
}
}
CH7.86
Declarations in Scopes
CSE
4100


Convention used by C++/Java/....
 Get the declaration “close” to the code that uses it.
 Easier to read/track
Downside
 Look at entire code to know the frame size.
int foo(int x,int y) {
int a;
float b;
while (x < 100) {
bool c;
int* d = alloca(sizeof(int)*y);
if (y > 0) {
bool e = ....;
}
}
for(int i=0;i<x;i++) {
bool g = ...;
}
}
CH7.87
Layout of Locals
CSE
4100


Problem
 Place locals in the frame
Objective
 Minimize frame size
 Satisfy alignment constraints








int
float
pointer/ref
bool
short
double
long long
4 bytes
4 bytes
4 bytes
1 byte
2 bytes
8 bytes
8 bytes
Can we improve ?
CH7.88
Further Improvements?
CSE
4100

Exploit the nested declarations!
int foo(int x,int y) {
int a;
float b;
while (x < 100) {
bool c;
int* d = alloca(sizeof(int)*y);
if (y > 0) {
bool e = ....;
}
}
for(int i=0;i<x;i++) {
bool g = ...;
}
}
Overlay the storage for names whose scopes are disjoint
i and d share the same “area” of the frame
c and g as well
CH7.89
Fixed-sized Local Arrays
CSE
4100

Fixed-sized means
 Size known at compile time
 e.g.int a[10];

Questions
 Is this a problem ?
 Storage comes from ?
 Size ?
CH7.90
What happens with nested procedures ?
CSE
4100

Name in nested scopes must be visible (& accessible)
program sort(input,output);
var a: array[0..10] of integer;
x: integer;
procedure readarray;
var i : integer
begin .... end
procedure exchange(i,j : integer)
begin
x := a[i];a[i] := a[j];a[j] := x;
end
procedure quickSort(m,n : integer)
var k,v : integer;
function partition(y,z : integer) : integer
var i,j : integer;
begin
... a ...
(* access the array a *)
... v ...
(* use the pivoting element *)
... exchange(i,j); ...
end
begin
end
begin .... end
CH7.91
Difficulty
CSE
4100

Names come from
 Frames of different functions/procedures
 The reference is based on lexical scoping.
 Name refers to definition in deepest nested scope that
contains the scope the reference comes from

Solution
 In each Frame
 Add a reference to the frame of the parent scope

Note
 Book uses the terms
 Access link to refer to link to parent scope
 Control link to refer to link to previous frame along
invocations
CH7.92
Solving Nested Scopes
CSE
4100
CH7.93
Example
CSE
4100
program sort(input,output);
var a: array[0..10] of integer;
x: integer;
procedure readarray;
var i : integer
begin .... end
procedure exchange(i,j : integer)
begin
x := a[i];a[i] := a[j];a[j] := x;
end
procedure quickSort(m,n : integer)
var k,v : integer;
function partition(y,z : integer) : integer
var i,j : integer;
begin
... a ...
(* access the array a *)
... v ...
(* use the pivoting element *)
... exchange(i,j); ...
end
begin
end
begin .... end
CH7.94
Access Link & Frames
CSE
4100
program sort(input,output);
var a: array[0..10] of integer;
x: integer;
procedure readarray;
var i : integer
begin .... end
procedure exchange(i,j : integer)
begin
x := a[i];a[i] := a[j];a[j] := x;
end
procedure quickSort(m,n : integer)
var k,v : integer;
function partition(y,z : integer) : integer
var i,j : integer;
begin
... a ...
(* access the array a *)
... v ...
(* use the pivoting element *)
... exchange(i,j); ...
end
begin
end
begin .... end
To access a name
Find out the lexical distance
If distance is k, jump over k access links.
CH7.95
Memory Manager – Compilation View
CSE
4100

Management of Primary and Secondary Memory
 Automatic Movement Between Two
 From Secondary to Primary to Start or Restart
 From Primary to Secondary to Suspend
Capturing the “Executable” State to Secondary
Memory for Ease of Restart
 Strategies for Determining “When” Movement Will
Occur
Involves Management of
 Memory Hierarchy of Hardware
 Creation of Address Space for “Process”
 Mapping “Process” During Allocation


CH7.96
Memory Manager
CSE
4100

Requirements
 Minimize Primary Memory Access Time
 Registers vs. Cache vs. Primary Memory

Maximize Primary Memory Size
 Virtual Memory “Appearance” of Larger Memory

Primary Memory Must Be Cost-Effective
 Doubling of Capacity has Had Greatest Impact

Today’s Memory Manager:
 Allocates Primary Memory to Processes
 Maps Process Address Space to Primary Memory
 Minimizes Access Time Using Cost-effective
Memory Configuration
CH7.97
Address Space vs. Primary Memory
CSE
4100
Process Address Space
Primary Memory
Mapped to object
other than memory
CH7.98
Building the Address Space
CSE
4100
Source
Code
Library
code
Other
Objects
Adjust Addresses
Translation Time
Load Time
Secondary
Memory
Translation
Compose
Elements
Executable
Memory
Process
Address
Space
Loader
Allocate Executable
Memory Space
Process
Address
Space
CH7.99
Unix Style Memory Layout for Process
CSE
4100







Storage Organization for a
Process
“Code” Referenced by PC
Global/Local Variables
Other Variables
Heap for Dynamic Memory
Allocation
For Activation Records
Text Segment
Initialized Data
Segment
Un-initialized
Data Segment
Heap Storage
Stack Segment
Still Other Variables
Environment
Variables, etc.
CH7.100
Recall Key Compilation Concepts
CSE
4100


Compile: Produce Relocatable Object Module
 Static Variables Allocated at Compile
 Non-Static Variables via Run Time Stack
 Dynamic Variables via Heap
 Recall Activation Record in C (next slide)
Link Time: Produce Absolute (or Load) Module
 Collect and Combine Individual Relocatable
Modules
 Linkage Editor: Internal Organization of Processes
Address Space
 Absolute Module at Location 0000
 All Addresses w.r.t. Base Location
CH7.101
Recall: An Activation Record in C
CSE
4100

Actual Parameters
Supplied by Caller
Etc.
Incoming Param 2
Incoming Param 1

Needed to Restart Caller
Saved State Info

Local Variables for Scope
Local Variables
Temporary Storage

If Callee Calls Another
Procedure/Function
Outgoing Parameters
CH7.102
Recall Key Compilation Concepts
CSE
4100

Loader: Produce Executable Image for Primary
Memory
 Readjust Addresses for Execution
 Offset from Location 0000 Must be Changed
 Once Partition for Process Execution has Been
Chosen
 Bind Addresses to Physical Memory Locations
 Referencing Both Instructions and Data

Dynamic Memory for Data Structures
 Each Address Space of Process Contains “Unused”
Memory
 User Programs Utilize for Dynamic Memory
Allocation (e.g., malloc and new)
CH7.103
From Code to Loaded Program
CSE
4100
ORIGINAL SOURCE
RELOCATABLE OBJECT MODULE
static int gVar;
. . .
int proc_a (int arg){
. . .
gVar = 7;
put_record(gVar);
. . .
}
0000
. . .
0008
. . .
0036
. . .
0220
0224
0228
0232
. . .
0400
0404
. . .
0500
0540
0600
0799
. . .
entry
proc_a
[Space for gVar]
load
store
push
call
=7, R1
R1, 0036
0036
‘put_record’
External Reference Table
‘put_record’ 0232
External Definition Table
‘proc_a’
0008
(optional symbol table)
(last location in module)
CH7.104
From Code to Loaded Program
CSE
4100
THE ABSOLUTE PROGRAM
0000
. . .
1008
. . .
1036
. . .
1220
1224
1228
1232
1399
. . .
2334
. . .
2670
2999
(Other Modules)
PROGRAM AT LOCATION 4000
0000
4000
entry proc_a
. . .
5008
[Space for gVar]
. . .
5036
load
=7, R1
. . .
store R1, 1036
5220
push
1036
5224
call
2334
5228
(end of proc_a)
5232
(Other Modules)
5399
entry put_record
. . .
6334
(opt. symbol table)
. . .
(last loc. in module) 6670
6999
7000
(Other Processes)
(Other Modules)
entry
proc_a
[Space for gVar]
load
=7, R1
store R1, 5036
push
5036
call
6334
(end of proc_a)
(Other Modules)
entry put_record
(opt. symbol table)
(last loc. in module)
(Other Processes)
CH7.105
Concluding Remarks/Looking Ahead
CSE
4100






Runtime Environment is Complex and Complicated
Part of Compilation Process
Software Engineers Need Solid Understanding
Key Issue are Questions from Slide 7.XX
Once Answer Questions, know Assumptions and
Available Techniques to Solve Problems
Other Issues of Note:
 Activation, Scoping, Memory Allocation
 Parameter Passing, Layout, etc.
Looking Ahead:
 Intermediate and Machine Code Generation
 Optimization
CH7.106