Chap 7: Runtime Organization

Chap 7: Runtime Organization
Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Way, Unit 2155 Storrs, CT (860) Material for course thanks to: Laurent Michel Aggelos Kiayias Robert LeBarre

Overview 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

Basic Definitions and Concepts
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) Environment State Compile Time Run Time Name Storage Value

Program Organization 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

The Basic Abstractions
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.

Program, Processes & Resources
Operating System Data CPU Device Device Program Device Memory Device Hardware

What are Executables? Executable File Containing Machine Code Examples
A bash script, a perl script, a ‘compiled’ java program, a compiled C program, ... Java Bytecode and JVM

Java Virtual Machine (JVM)
JVM is a Platform Specific Program which Interprets and Executes Java Code JVM Interprets and Executes Bytecodes JVM Targeted as Small/Efficient - Embeddable within Consumer Electronics JVM Stack Based Machine - Simulates Real Processor CA FE BA BE D 00 3E B

Java Visualization

What are Executables? 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

From Code to Loaded Program
ORIGINAL SOURCE static int gVar; . . . int proc_a (int arg){ gVar = 7; put_record(gVar); } RELOCATABLE OBJECT MODULE . . . 0008 entry proc_a 0036 [Space for gVar] 0220 load =7, R1 0224 store R1, 0036 0228 push 0036 0232 call ‘put_record’ 0400 External Reference Table 0404 ‘put_record’ 0232 0500 External Definition Table 0540 ‘proc_a’ 0008 0600 (optional symbol table) 0799 (last location in module)

THE ABSOLUTE PROGRAM 0000 (Other Modules) . . . 1008 entry proc_a 1036 [Space for gVar] 1220 load =7, R1 1224 store R1, 1036 1228 push 1036 1232 call 2334 1399 (end of proc_a) . . . (Other Modules) 2334 entry put_record 2670 (opt. symbol table) 2999 (last loc. in module) PROGRAM AT LOCATION 4000 0000 (Other Processes) 4000 (Other Modules) . . . 5008 entry proc_a 5036 [Space for gVar] 5220 load =7, R1 5224 store R1, 5036 5228 push 5036 5232 call 6334 5399 (end of proc_a) . . . (Other Modules) 6334 entry put_record 6670 (opt. symbol table) 6999 (last loc. in module) 7000 (Other Processes)

What is a Process? 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

What is a Process? 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

A Process Resources Code Data Process Status
Abstract Machine Environment (OS)

UNIX Process Resources Resources Data Text Stack Process Status File
UNIX kernel

More on UNIX Processes 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) USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND wangz pts/16 O Aug :26 /apps/matlab/bin/s manish ? O Jul :34 /apps/matlab/bin/s marios pts/6 S 13:22:23 0:24 mailtool steve pts/18 S 17:41:11 0:00 -csh root pts/18 O 17:41:53 0:00 ps -aux

Multiprogramming Load and Execute Multiple Programs into Space-Multiplexed 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”

How Multiprogramming Works
Process 1 Process 2 CPU Space-Multiplexed Memory Process 3 Time-Multiplexed Process 4

Batch Processing 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

Timesharing 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

How Timesharing Works Timesharing Still Pervasive in Computing
Engineering Network Still Time-Shared in Some Respects Access to User Files /Web Server Download Software Terminals Replaced by Unix Workstations and PCs Example of Network File System/OS Timesharing OS VM Terminal Multiplexor

Personal Computers 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

Process Control & Real-Time
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

Evolution of Modern OS Timesharing Network OS PC & Wkstation Batch
Memory Mgmt PC & Wkstation Client-Server Model Scheduling Protection System Software Protocols Batch Human- Computer Interface Memory Mgmt Real-Time Protection Scheduling Scheduling Files Devices Modern OS Java/JINI/JavaOS

Virtual Address Space 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.

Virtual Memory 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”

Names, Virtual Addresses, Physical Addresses
Distinguish Between Symbolic Names vs. Virtual Addrs. vs. Physical Addrs. Source Program Absolute Module Executable Image Name Space Virtual Address Space Physical Address Space Compile and Link Tools Yt: Virtual Address Space  Physical Address Space  {}

Virtual Address Space Traditional Organization Code Area at the bottom
Static Data above Constants Static strings Static variables Heap Grows upward Stack Grows downward Lot’s of free VM in between 0xffffffff 0x0

OS Conventions 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.

Zooming In. Close look on the code area

Loading 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:

Loading and Execution 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

A First Look at Activation Records
Storage Organization for Program Execution Code Referenced by PC Global/Local Variables Static Data Area Stack Contains Set of Activation Records All Active Procedures and Functions Heap for Dynamic Memory Allocation Code Static Data Stack Heap

A General Activation Record
To the Calling Procedure Passed in to Procedure To Act. Record of Caller Referenced Non-Local Data Needed to Restart Caller Local Variables for Scope Compiler Generated Returned Value Actual Parameters Optional Control Link Temporaries Saved Machine Status Local Data Optional Access Link

An Activation Record in C
Actual Parameters Supplied by Caller Needed to Restart Caller Local Variables for Scope If Callee Calls Another Procedure/Function Etc. Incoming Param 2 Incoming Param 1 Saved State Info Local Variables Temporary Storage Outgoing Parameters

Activation Records 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

What are Possible Activations?
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

Activation Tree Graphical Representation of Activations over Time

How is Tree Interpreted?
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

Relationship to Environment and State
Recall: Assignments Change State Declarations Change Environment Differentiation also Possible from Static and Dynamic Levels Procedure Definition vs. Procedure Activation Name Declaration vs. Name Binding Scope of Declaration vs. Lifetime of Binding Environment State Compile Time Run Time Name Storage Value Environment State

Issues Impacting Runtime Environment
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!

Memory Allocation Strategies
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 Sizes of Data Known at Compile Time Parameters during Calls Heap – Run Time Allocate and Deallocate Memory (malloc) Programmatic Needs Code Static Stack (Automatic) Heap (Dynamic)

Memory Pools Where does memory comes from ? Three pools Static
Automatic (Stack) Dynamic Automatic (Stack) Dynamic Static

Static Pool 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

Static Allocation Binding Names to Storage Location at Compile Time
Program and Procedure/Function Variables Consider C Program: int xyz; char c[20]; int abc () { static int x; . . . static int y; } Global vars known at compile time Static means to allocate at compile Data values persist over multiple calls to abc() x, y: retain values in successive calls to abc!

Static Allocation 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[ ]; . . . } main() { static int x[ ]; . . . }

Automatic Pool (Stack Allocation)
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

Automatic Pool (Stack Allocation)
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?

Caller and Callee

Caller vs. Callee 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

What are Possible Problems
Passing Arrays by Value int x [10000]; char c[20]; abc (t: -----) { . . . zzz(t); . . . } xyz (a: -----) abc(a); xyz(x); What Happens to Stack During these multiple calls? What’s the Problem Here? What are two Possible Solutions?

What are Possible Problems
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?

Heap (Dynamic) Allocation
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?

Dynamic Pool Content Anything allocated by the program at runtime
Allocation Depends on the language C malloc C++/Java/C# new ML/Lisp/Scheme implicit Deallocation C free C++ delete Java/C#/ML/Lisp/Scheme Garbage collection

Revisiting Activation Records
Focus on Execution Environment for Imperative Language (C, C++, Java, Pascal, etc.) Code Reference by Program Counter Stack Contains Activation Records (Grows Down) Snapshot of Activations Status of Execution Heap for Dynamic Memory (Grows Up) Code Static Data Stack Heap

What Activation Record Contains?

Recall Activation Record in C
Actual Parameters Supplied by Caller Needed to Restart Caller Local Variables for Scope If Callee Calls Another Procedure/Function Etc. Incoming Param 2 Incoming Param 1 Saved State Info Local Variables Temporary Storage Outgoing Parameters When Callee Invokes/Activates Another Procedure, Outgoing Parameters of One Record are Incoming Parameters of Another Activation Record

Activation Records Also known as “Frames”
A record pushed on the execution stack

Creating the Frame Three actors The caller The CPU The callee
int foo(int x,int y) { ... } bar() { x = foo(3,y);

int foo(int x,int y) { ... } bar() { x = foo(3,y); Actual Function Call

int foo(int x,int y) { ... } bar() { x = foo(3,y);

Closeup on Management Data
Links Allow Callee to Refer to Non-Local Scopes

Returning From a Call Easy The RET instruction simply
Access MGMT Area from FP Restores SP Restores FP Transfer control to return address

Variations This is architecture dependent On Intel: On PPC
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)

Impact of Parameter Passing Mechanisms
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

Call By Value 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); var temp: integer; begin temp := x; x := y; y := temp; end; . . . int a, b; swap (a, b) Print(a, b) x y x and y are in callee’s activation record (scope) a and b are in caller’s a b Do a and b Change?

Call By Reference 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); var temp: integer; begin temp := x; x := y; y := temp; end; . . . int a, b; swap (a, b) Print(a, b) a and b are in caller’s activation record (scope) x y a b

C is Call by Value ONLY! Swap Will NOT Change a and b
Values are Unchanged! 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? main() { int x=5, y=10; swap (x, y); } void swap (int x, y); int temp; temp := x; x := y; y := temp;

Copy Restore 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?

Copy Restore 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; a := 1; unsafe(a); writeln(a); end. x a

Call By Name 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?

Version 1: Macro Expansion
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; } 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; } What Happens when { m = (m+1) % x; } is substituted for p()? How Does Resulting Code Work?

Version 2: Actual Substitution
Procedure Definition void q(int y) { int i; i = 5; y = y + 1; } Procedure Call 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; }

Parameter Passing - Synopsis
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

Parameter Passing - Synopsis
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

Data Typing and Layout 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)

Consider an Example in C
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 Share l-value since independent scopes c,i3 i2 Need own l-value since nested scope

Advanced Data Types 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 …

One Dimensional Arrays
Data Stored in Consecutive Locations 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 A[0] A[1] A[2] A[3]

Two Dimensional Arrays
Stored in Row Major Order (row by row) 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 M[1,1] M[1,2] M[2,1] M[2,2] M[3,1] M[3,2]

Scope of Declarations 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

Declarations Ahead 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 = ...;

Declarations in Scopes
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 = ...;

Layout of Locals Problem Place locals in the frame Objective
Minimize frame size Satisfy alignment constraints int 4 bytes float 4 bytes pointer/ref 4 bytes bool 1 byte short 2 bytes double 8 bytes long long 8 bytes Can we improve ?

Further Improvements? 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

Fixed-sized Local Arrays
Fixed-sized means Size known at compile time e.g.int a[10]; Questions Is this a problem ? Storage comes from ? Size ?

What happens with nested procedures ?
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; ... a (* access the array a *) ... v (* use the pivoting element *) ... exchange(i,j); ... begin end

Difficulty 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

Solving Nested Scopes

Example 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; ... a (* access the array a *) ... v (* use the pivoting element *) ... exchange(i,j); ... begin end

Access Link & Frames To access a name Find out the lexical distance
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; ... a (* access the array a *) ... v (* use the pivoting element *) ... exchange(i,j); ... begin end To access a name Find out the lexical distance If distance is k, jump over k access links.

Memory Manager – Compilation View
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

Memory Manager 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

Address Space vs. Primary Memory
Process Address Space Mapped to object other than memory

Building the Address Space
Adjust Addresses Translation Time Load Time Source Code Translation Library code Other Objects Secondary Memory Process Address Space Loader Process Address Space Executable Memory Compose Elements Allocate Executable Memory Space

Unix Style Memory Layout for Process
Storage Organization for a Process “Code” Referenced by PC Global/Local Variables Other Variables Heap for Dynamic Memory Allocation For Activation Records Still Other Variables Text Segment Initialized Data Segment Un-initialized Data Segment Heap Storage Stack Segment Environment Variables, etc.

Recall Key Compilation Concepts
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

Recall: An Activation Record in C
Actual Parameters Supplied by Caller Needed to Restart Caller Local Variables for Scope If Callee Calls Another Procedure/Function Etc. Incoming Param 2 Incoming Param 1 Saved State Info Local Variables Temporary Storage Outgoing Parameters

Recall Key Compilation Concepts
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)

ORIGINAL SOURCE static int gVar; . . . int proc_a (int arg){ gVar = 7; put_record(gVar); } RELOCATABLE OBJECT MODULE . . . 0008 entry proc_a 0036 [Space for gVar] 0220 load =7, R1 0224 store R1, 0036 0228 push 0036 0232 call ‘put_record’ 0400 External Reference Table 0404 ‘put_record’ 0232 0500 External Definition Table 0540 ‘proc_a’ 0008 0600 (optional symbol table) 0799 (last location in module)

THE ABSOLUTE PROGRAM 0000 (Other Modules) . . . 1008 entry proc_a 1036 [Space for gVar] 1220 load =7, R1 1224 store R1, 1036 1228 push 1036 1232 call 2334 1399 (end of proc_a) . . . (Other Modules) 2334 entry put_record 2670 (opt. symbol table) 2999 (last loc. in module) PROGRAM AT LOCATION 4000 0000 (Other Processes) 4000 (Other Modules) . . . 5008 entry proc_a 5036 [Space for gVar] 5220 load =7, R1 5224 store R1, 5036 5228 push 5036 5232 call 6334 5399 (end of proc_a) . . . (Other Modules) 6334 entry put_record 6670 (opt. symbol table) 6999 (last loc. in module) 7000 (Other Processes)

Concluding Remarks/Looking Ahead
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

Chap 7: Runtime Organization

Similar presentations

Presentation on theme: "Chap 7: Runtime Organization"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chap 7: Runtime Organization

Similar presentations

Presentation on theme: "Chap 7: Runtime Organization"— Presentation transcript:

Similar presentations

About project

Feedback