lecture 24 - department of computer science and engineering

Microsoft PowerPoint - lecture24-27-LinkingLoadersComputer Science and Engineering College of Engineering The Ohio State University
Loaders
Again?
Haven’t we done this already? We built one in lab 1!
Our programming model then was simplistic:
Source Program
Object File
Recall: “Big” Picture
HEG1 34000040 T340032A2 ...
Problems With This Model
Programmer is responsible for putting absolute addresses in code Error prone calculation Brittle: Change in program entails change
of addresses
Assembly File
Object File
HEG1 34000040 T340032A2 ...
Problems (II)
Programmer decides where in memory to load the object code Better to give OS control Dynamic scheduling, concurrent jobs
Assembly File
Object File
HEG1 34000040 T340032A2 ...
Problems (III)
Program must be self-contained No guarantees on what is in memory
outside of loaded segment Entire program is contained in a single
object file Better: Allow separate assembly One program is split between multiple files Each source file can be assembled
independently from the others Loader is responsible for stitching the
multiple object files together
Separate Assembly: Advantages
Modularity: Make one change in source, do not need to recompile entire program
Libraries: Support external libraries for common bits of code; e.g., strcpy(), sqrt(), sin()…
Language neutrality: Write different parts in different source languages Some languages are better suited to certain
tasks than others Library functions can be written in a single
language (rather than rewriting for every possible source language)
Computer Science and Engineering The Ohio State University
More General View of Compilation and Loading
10
General Loaders
This approach requires standardizing the format of the object file
Each source language translator then follows this same standard
11
Steps Before Execution
4. Linking Combine multiple object files
5. Loading Initialize memory with segment contents
Types of Loaders
Distinguish different types of loaders based on strategy used Compile-and-go Absolute Relocating Linking Dynamic loading Dynamic linking
Types of Loaders
Compile-And-Go
Observation: A translator is, itself, a program Loaded in memory, executing Lab 4: Write lab 2 assembler in assembly
Reserve memory at the end of the translator’s segment as destination of compiled machine code
As source is compiled, load machine code directly into this reserved memory
Combines loader with the compiler Example: WATFOR compiler
Translate and Load
Compile-And-Go: Responsibility
1. Translation
2. Allocation
3. Relocation
4. Linking
5. Loading
Tradeoffs
(I/O is always slow) Speed (vs interpreted): runs compiler-
optimized machine code Low start-up cost: Translator remains
resident in memory Disadvantages: Program must be recompiled to run every
time Libraries must be source language-based Memory must be conservatively reserved
Types of Loaders
Absolute Loaders
Familiar loader from Lab 1 Consider responsibility for each task: Translate: Allocate: Determine length of segment: Determine load location:
Relocate: Link: Load:
Tradeoffs
Advantages Simple, small, fast Affords high degree of control to
programmer Disadvantages Lack of flexibility in load location means
wasted memory Small change in source requires
recompiling everything Generally: Too error-prone and
wasteful for most cases
Special Case
Observation: a loader is a program Resides in memory, executes
Q: How did it get there? Ie what loads the loader? A: The OS. Wait, then what loads the OS?
From an idle machine, we need a way to start things up Solution:
Bootstrap Loader
Store a special program in ROM This program is automatically executed
at power-up This program is an absolute loader Reads records from an input device Puts them in a predetermined (absolute)
memory location Control is then transferred to loaded
program (which can load other things, etc)
Types of Loaders
Relocating Loader
The assembler does 2 things to support relocation: Produces size-of-segment information Flags relative value (modification records)
Loader works with OS to determine load location at load/run time
Loader patches (appropriate) text records by adding loading location
Q. How many passes (over the object file) are required? A.
Tradeoffs
efficient memory allocation Disadvantages Program must be self-contained (no
external subroutines or libraries)
Time for a slight detour, as a motivational aside for remaining loader types…
Subroutine Linkage
Example: Implementing Connect Four Game board .BLKW #7*#6 ;0/1/2 empty/red/yellow
Problem: Given column for next move, calculate row in which piece would end up
Idea 1: Who Needs Branching?
Embed the code for this calculation right in “main”
Advantages: Branching can be slow (ha ha)
Disadvantages: No code reuse if this calculation is needed
in multiple places Even if the calculation is needed in just
one place, monolithic programs are hard to read and debug
Idea 2: A Function/Method
Problem: There are no functions or methods in assembly language
Write code, add a label From “main”, need to jump to this
code
.ORIG . . .
Branching Want to branch two times: First, to CRow Later, back to caller
Why does this not work? main …
BRNZP CRow Cllr ;etc…
;etc… BRNZP Cllr .END main
Solution: Jump-To-Subroutine
Q: What is the value of R7 after JSR? A:
Q: What restriction exists on target of branch? A:
Solution: Jump-To-Subroutine
LEA R3,CRow ;x3F0C: E61B JSRR R3,#0 ;x3F0D: C8C0
Loads R3 with value of symbol CRow Loads the PC into R7 Branches to location R3
Q: Does this approach remove the restriction on target of branch? A:
Summary
loading Absolute: Programmer control, useful for
bootstrapping Relocating: Dynamic load location for
efficient memory use Subroutine linkage JSR/JSRR affords linking to reusable
subroutines Working towards: Separate

lecture 24 - department of computer science and engineering

Documents