KR editions 69 to 71
KR-69: Loader
So far we've seen compiling, linking a code; and memories. What next? At the end of linking we have a load module (executable) but can we execute it directly?
When running an exe you may feel that there is nothing else involved but another important system software is the loader (it lies hidden from the user within the OS). The question arises what does a loader do? First we'll take a look at the end product of linking.
As you are aware, in computers everything needs to be stored in memory (data, instructions etc). For example: let's say we wrote a piece of code:
MOVE 65 TO WS-VAR
After compiling and linking the equivalent code would be:
MOVE 65 TO MEMORY-LOCATION 1500.
And the linker would have assigned 1500 initially as the memory address for WS-VAR (variables are nothing but named memory locations; we can't use addresses in our programs and so we give names).
Our instructions also need to be placed at some memory location. But where? Where should the first instruction of our program be placed?
Remember: The linker's output (load module) will be stored in the hard-disk but the CPU needs the program to be in main memory.
And the loader comes to the rescue!
KR-70: Compiler, Linker, Loader
A short one to recap what we've covered so far in the last few editions:
Compiler- produces object code which is present in hard-disk (secondary memory).
Linker- produces executable which is again in hard-disk.
So we need someone (called the loader) to do this job of copying from hard-disk to main memory.
When should the loader activate? A program is executed (Assuming windows), when we double click on an EXE filename; in DOS it is executed when we type the name of the file at the command prompt and hit enter. When this is done, the loader comes into action.
The loader's task is simple: it has to put the program into some available space in main memory (when many programs are simultaneously running on the PC, they are all occupying bits and pieces of main memory; when a new program wants to run, the loader has to locate some free space to copy this program).
The problem is "how does the linker know where the loader is going to copy the program?" The answer is it doesn't! Usually linkers will assume that their load module will be placed at a particular memory location.
Did u know that CCID stands for "Change Control Identifier"?
KR-71: Loader - concluding part
This is the concluding episode on loaders.
The problem we faced: Linkers don't know the memory location which will be occupied by the program at run-time; so what memory locations should they use?
Some solutions:
1.) Have a provision that the programmer can decide the memory address where he/she wants the program to be placed. For example: the programmer might say "I want the program to start from location 2000". Linker will faithfully obey and write the code as if it is starting from 2000 location in main memory. Then (at run-time) the loader will attempt to load the program at memory location 2000 if the place is free; if it isn't it'll wait or it may abort with an error. This is called an absolute loader.
2.) Linker might assume the main memory location to be 0. All other statements and data within the program will be placed at locations with respect to 0 (i.e. relative to position 0). During loading, the loader will search for free main memory. Suppose location 5000 is free, then the loader will offset every instruction by 5000 (i.e. every memory reference will be offset by 5000). This type of loader is a relocatable loader.
3.) Relocatable loaders seem good but they have their own problems; imagine the overhead on the loader to read each and every instruction and then convert the references. Added to this is the problem posed by modern operating systems: the concept of virtual memory (where a program is broken into small pieces and loaded into main memory as and when required). This requires the loader to be smarter in operating systems which use virtual memory.
Go back to the main contents page
Copyright © 2020 Sethu Subramanian All rights reserved. Reach me via email at ssbell @ gmail.com