CST305 System Software

Module 4 (Loader and Linker)

Basic Loader functions - Design of absolute loader, Simple bootstrap Loader, Machine
dependent loader features- Relocation, Program Linking, Algorithm and data structures of two
pass Linking Loader.

Machine Independent loader features – Automatic Library Search, Loader Options. Loader
Design Options.

Overview

Loaders and Linkers

An object program contains translated instructions and data values from the source program and
specifies addresses in memory where these items are to be loaded.

1. Loading : brings the object program into memory for execution

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 1

 CST305 System Software

2. Relocation : modifies the object program so that it can be loaded at an address different
from the location originally specified
3. Linking : combines two or more separate object programs and supplies the information
needed to allow references between them

A loader is a system program that performs the loading function. Many loaders also support
program linking and relocation. Some systems have a linker(or a linkage editor) to perform the
linking operations and a separate loader to handle relocation and loading. In most cases all
program translators (ie., assemblers and compilers) on a particular system produces object
programs in the same format. Thus one system loader or linker can be used regardless of the
original source programming languages. There exist a close connection between program
translation and loading.

Basic Loader Functions

The major functions performed by loader are:

– Allocation

– Linking

– Relocation

- Loading

Allocation: The function performed by loader to determine and allocate the required memory
space for the program to execute faithfully

Linking: It is a function performed by the loader to analyze and resolve the symbolic references
made in the object modules. It is also possible to combine two or more separate object programs
and supply the information needed to allow references between them

Relocation: Compilers and assemblers generally create each file of the object code with the
program address, starting at zero. But only few computers let to load the program at the location
zero. If a program is created from multiple subprograms, all subprograms have to be loaded at
non-overlapping addresses. Relocation is the process of assigning load addresses to the various

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 2

 CST305 System Software

parts of the program, adjusting the code and data in the program to reflect the assigned addresses.
In many systems relocation happens more than once.

Loading: It is also defined as the process of copying a program from a secondary storage into
main memory so it is ready to run. In some cases loading just involves copying the data from the
disk to memory, in others it involves allocating storage, setting protection bits or arranging
virtual memory to map virtual addresses to disk pages

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 3

 CST305 System Software

Design of an Absolute Loader

Absolute Loader is a primitive type of loader, which does only the loading function. It does not
perform linking and program relocation. All functions are accomplished in a single pass:

• The loader is provided with:

• Text of the object program, which has already been linked
• The address of the location, where the first word of the object program is to be
loaded
• Length of the object program

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 4

 CST305 System Software

The absolute loader reads the header record and check to verify that the correct program has been
presented for loading( and that it will fit into the available memory). When the end record is
encountered the loader jumps to the specified address to begin execution of the loader program

The contents of the memory locations for which there is no Text Record are shown as xxxx. This
indicates that the previous contents of these locations remained unchanged.

The algorithm for an absolute loader

In the object program, each byte of assembled code is given using the hexadecimal
representation in character form. For example, the machine operation code for STL instruction
would be represented by the pair of the characters “1” and “4”. When these are read by loader as
part of object program, they will occupy two bytes of memory. In the instruction as loaded for
execution, however this operation code must be stored in a single byte with the hexadecimal
value 14. Thus each pair of bytes from the object program record must be packed together into

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 5

 CST305 System Software

one byte during loading. Note: In fig(a) each printed character represents one byte of the object
program record. In fig (b) each printed character represents one hex-decimal digit in
memory(ie,half-byte). This method of representing an object program is inefficient in terms of
both space and execution time. Therefore, most machines store object program in a binary form,
with each byte of object code stored as a single byte in the object program. In this type of
representations, a byte may contain any binary value. We must ensure that our file and device
conventions do not cause some of the object program bytes to be interpreted as control
characters. For example- the convention indicating the end of the record with a byte containing
hexadecimal 00 – would clearly be unsuitable for use with a binary object program.

A Simple Bootstrap Loader

When a computer is first turned on or restarted a special type of absolute loader called bootstrap
loader is executed. This bootstrap loader loads the first program to be run by the computer-
usually an operating system. A bootstrap loader for SIC/XE

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 6

 CST305 System Software

The figure shows the source code of our bootstrap loader. The bootstrap itself begins at address 0
in the memory. It loads the OS or some other program starting at address 80. Each byte of object
code to be loaded is represented on device F1 as two Hex digits (by GETC subroutines). No
header record, end record or control information (such as addresses or lengths). The object code
from device F1 is always loaded into consecutive bytes of memory, starting at address 80. After
all of the object code from device F1 has been loaded the bootstrap jumps to address 80, which

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 7

 CST305 System Software

begins the execution of program that was loaded. Much of the work of bootstrap loader is
performed by the subroutine GETC.

This subroutine reads one character from the device F1 and converts it from the ASCII character
code to the value of the hexadecimal digit that is represented by that characterThe ASCII code
for the character 0 (Hex 30) is converted to the numeric value 0. Likewise, the ASCII code for
“1” through “9” (hex 31 through 39) are converted to the numeric values 1 through 9 and the
codes for “A” through “F” (hex 41 through 46) are converted to the values 10 through 15. This is
accomplished by subtracting 48(hex30) from the character codes for “0” through “9” and
subtracting 55 (hex 37) from the codes for “A” through “F”. The subroutine GETC jumps to
address 80 when an end of the file (hex 04) is read from device F1. It skips all other input
characters that have ASCII code less than hexadecimal 30. This causes the bootstrap to ignore
any control bytes (such as end-of-line) that are used. The main loop of the bootstrap keeps the
address of the next memory location to be loaded in register X.

GETC is used to read and convert a pair of characters from device F1 representing 1 byte of
object code to be loaded. These two hexadecimal digit values are combined into a single byte by
shifting the first one left 4 bit positions and adding the second to it. The resulting byte is stored at
the address currently in the register X, using STCH instruction that refers to location 0 using
indexed addressing. The TIXR instruction is then used to add 1 to the value in register X. The
register X is also used as the second operand for this instruction

Drawback of absolute loaders

1. Programmer needs to specify the actual address at which it will be loaded into memory.
2. Difficult to run several programs concurrently, sharing memory between them.
3. Difficult to use subroutine libraries.
Machine Dependent Loader Features
• Solution:
• A more complex loader that provides
– Program relocation
– Program linking
Program Relocation

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 8

 CST305 System Software

The need for program relocation is an indirect consequence of the change to larger and more
powerful computers. The way relocation is implemented in loader is also dependent upon
machine characteristics. Loader that allow program relocation are called relocating loaders or
relative loaders. A modification record is used to describe each part of the object code that must
be changed when the program is relocated. Format of the modification record we have studied in
mod.2. Here we are taking the same example studied in mod.2

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 9

 CST305 System Software

Most of the instructions in this program use relative addressing or immediate addressing. The
only portion of the assembled program that contains actual addresses are the extended format
instructions(line 15,35 and 65). So these are get affected with relocation. Note that one
modification record for each value that must be changed during relocation. Each modification
record specifies the starting address and the length of the field whose value is to be altered. It
describes the modification to be performed. In this example, all modifications add the value of
the symbol COPY, which represents the starting address of the program. Later in this module we
will study the algorithm which loader uses to perform these modifications. Modification record
scheme is convenient for machines with small architecture. It is not well suited to use this for
complex architectures. So we are considering the relocatable program written for SIC

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 10

 CST305 System Software

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 11

 CST305 System Software

If a machine primarily uses direct addressing and has a fixed instruction format. There are many
addresses needed to be modified. It is often more efficient to specify relocation using relocation
bit. There are no modification records, the text records are same as before except that there is a
relocation bit associated with each word of the object code. All SIC instructions occupy one
word, this means that there is one relocation bit for each possible instruction. For second Text
record, mask E00, specifies that the first three words are to be modified. The remainder of the
object code in this record is represented data constants, RSUB instruction and thus do not require
modification. Other text record follows the same pattern. Note that: the object code generated for
the LDX instruction on line 210 begins a new Text record even though there is room for it in the
preceding record. This occurs because each relocation bit is associated with a 3-byte segment of
object code in the Text Record.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 12

 CST305 System Software

Some computers provide hardware relocation capability that eliminates some of the need for the
loader to perform program relocation. For example, some such machines consider all memory
references to be relative to the beginning of the user’s assigned area of memory. The conversion
of these relative addresses to actual addresses is performed as the program is executed.

Program Linking

The control sections could be assembled together (ie., in the same invocation of the assembler)
or they could be assembled independently of one another. In either case they would appear as
separate segments of object code after assembly. The loader has to link, relocate and load the
control section. The loader does not know which control sections were assembled at the same
time. Consider the three separately assembled programs in Fig. Each consists of a single control
section. Each program contains a list of items, LISTA, LISTB, LIST C; and it ends with
ENDA,ENDB,ENDC. LISTA---ENDA, LISTB---ENDB, LISTC---ENDC. The labels on the
beginnings and ends of the lists are external symbols(they are available for linking). Note: Each

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 13

 CST305 System Software

program contains exactly the same set of references to these external symbols.REF1, REF2,
REF3 for Instruction operands. REF4, REF5, REF6, REF7, REF8 are the values of data words.
Omitted the instructions which do not involve linking and relocation.

• What are the different ways these identical expressions are handled within three
programs?

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 14

 CST305 System Software

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 15

 CST305 System Software

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 16

 CST305 System Software

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 17

 CST305 System Software

The fig. (a) shows that three programs might look like this after being linking and loading.
PROGA has been loaded at starting address 4000, PROGB and PROGC are following. Note:
each of REF4 through REF8 has resulted (after relocation and linking is performed) in the same
value in each of the three programs because the same source expression appeared in each
program.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 18

 CST305 System Software

Relocation and Linking operations performed on REF4 from PROG A

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 19

 CST305 System Software

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 20

 CST305 System Software

In PROGA, the reference REF1 is a program counter relative with displacement 01D . When this
instruction is executed, the program counter contains the value 4023(the actual address of the
next instruction). The resulting target address is 4040.

Algorithm and Data Structures for a two-pass linking loader

The input to a two-pass linking loader consists of a set of object programs (ie., control sections)
that are to be linked together. It is possible (and common) for a control section to make an
external reference to a symbol whose definition does not appear until later in this input stream. In
such a case, the required linking operation cannot be performed until an address is assigned to
the external symbol involved (ie., until the later control section is read). Thus a linking loader
usually makes two passes over its input, just as an assembler does.

• In Pass1: assign addresses to all external symbols

• In Pass 2: perform the actual linking, relocating and loading

Data Structures

• ESTAB

• PROGADDR

• CSADDR

• CSLTH :Control section length

ESTAB

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 21

 CST305 System Software

The main data structure needed for our linking loader is an external symbol table ESTAB.
Analogous to SYMTAB. It is used to store the name and address of each external symbol in the
set of control section being loaded. The table indicates in which control section the symbol is
defined A table has hashed organisation.

PROGADDR

Is a variable. Program load Address. Is the beginning address in memory where the linked
program is to be loaded. Its value is supplied to the loader by the operating system.

CSADDR

Is a variable. Control Section address. It contains the starting address assigned to the control
section currently being scanned by the loader. This value is added to all relative addresses within
the control section to convert them to actual addresses. During Pass 1, the loader is concerned
only with the header and define record types in the control sections. The beginning load address
for linked program (PROGADDR) is obtained from the operating system. This becomes the
starting address (CSADDR) for the first control section in the input sequence. The control
section name from the header record is entered into ESTAB, with the value given by CSADDR.
All external symbols appearing in the Define Record for the control section are also entered into
ESTAB. Their addresses are obtained by adding the value specified in the define record to
CSADDR. When the end record is read, the control section length CSLTH (which is saved in
header record) is added to CSADDR. This calculation gives the starting address for the next
control section in sequence.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 22

 CST305 System Software

At the end of pass 1, ESTAB contains all external symbols defined in the set of control sections
together with the address assigned to each. Many loaders include the ability to print a load map
that shows these symbols and their addresses as an option. This information is useful in program
debugging.

The pass 2 of the loader performs actual loading, relocation and linking of the program. In pass 2
also CSADDR is used, as it always contains the actual starting address of the control section
currently being loaded. As each text record is read, the object code is moved to the specified
address (plus the current value of CSADDR). When modification record is encountered, the
symbol whose value is to be used for modification is looked up in ESTAB. This value is then
added to or subtracted from the indicated memory location in memory. The last step performed
by loader is usually the transferring of control to the loaded program to begin execution. On
some systems, the address where execution begins is simply passed back to the operating system.
The user must enter a separate execute command

The end record for each control section may contain the address of the first instruction in that
control section to be executed. Here the loader takes this as the transfer point to begin
execution. If more than one control section specifies a transfer address, the loader arbitrarily uses
the last one encountered. Most commonly, if no control section contains a transfer address, the
loader uses the beginning of the linked program (ie., the PROGADDR) as the transfer point.
Normally, the transfer address would be placed in the End record for a main program, but not for

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 23

 CST305 System Software

a subroutine. Thus the correct execution address would be specified regardless of the order in
which the control sections were presented for loading.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 24

 CST305 System Software

The efficiency of the algorithm can be improved by making a slight change in the object program
format. This modification involves assigning a reference number to each symbol referred to in a
control section. This reference number is used (instead of the symbol name) in modification
record. Suppose we always assign the reference number 01 to the control section name. The
other external symbols may be assigned numbers as part of the Refer record for the control
section.

The common use of a technique such as reference numbers is one of the reason for including
refer records in the object programs. In algorithm we do not mention about the refer record. Main
advantage of reference numbers:

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 25

 CST305 System Software

Machine Independent Loader Features

Loader features that are not directly related to machine architecture and design

Loading and linking are often thought of as operating system service functions.

1. Automatic library search

2. Loader options

Automatic Library Search

Automatic Library Search for handling external references:

1. Allows programmers to use standard subroutines without explicitly including them in the
program to be loaded.
2. The routines are automatically retrieved from a library as they are needed during linking.

Many linking loaders can automatically incorporate routines from a subprogram library into the
program being loaded. There is a standard library for this purpose. Other libraries may be
specified by control statements or by parameters to the loader. This feature allows the
programmer to use the subroutines from one or more libraries. The subroutines called by the
program being loaded are automatically fetched from the library, linked with the main program,
and loaded. The programmer does not need to take any action beyond mentioning the

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 26

 CST305 System Software

subroutines name as external references in the source program. One some systems this feature is
called automatic library call. Linking loaders that support automatic library search must keep
track of external symbols that are referred to, but not defined, in the primary input to the loader.
One easy way to do this is to enter the symbols from each Refer record into ESTAB unless these
symbols are already present. These entries are marked to indicate that the symbol has not yet
been defined. When the definition is encountered, the address assigned to the symbol is filled in
to complete the entry. At the end of pass1, the symbols in ESTAB that remain undefined
represent unresolved external references. The loader searches the library or library specified for
routines that contain the definitions of these symbols, and processes the subroutine found by this
search exactly as if they had been part of primary input stream. Note: The subroutines fetched
from library in this way also themselves contain external references. It is therefore necessary to
repeat the library search process until all references are resolved. If unresolved external
references remain after the library search is completed, this must be treated as errors.

The process also allows the programmer to override the standard subroutines in the library by
supplying his or her own routines. For ex: The main program refers to a standard subroutine
named SQRT. Ordinarily, the subroutine with this name would automatically be included via the
library search function. A programmer who for some reason wanted to use a different version of
SQRT could do so simply by including it as input to the loader. By the end of pass1 of the
loader, SQRT would already be defined and it might not be included in automatic library search.
The libraries to be searched by the loader ordinarily contains assembled or compiled versions of
the subroutines (ie, object program). It is possible to search this libraries by scanning the define
records for all of the object programs on the library – it might be inefficient. In most cases a
special file structure is used for the libraries. This structure contains a directory that gives the
name of each subroutine and a pointer to its address within the file. If the subroutine is to be
callable by more than one name (using different entry points), both names are entered in to the
directory. The object program is stored only once. Both directory entries point to the same copy
of the routine. Thus the library search itself really involves a search of the directory followed by
reading the object programs indicated by this search. Some operating systems can keep the
directory for commonly used libraries permanently in memory. This can expedite the search
process if a large number of external references are to be resolved.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 27

 CST305 System Software

Loader Options

Common options that can be selected at the time of loading and linking.

Including capabilities such as specifying alternative sources of input, changing or deleting

external references and controlling the automatic processing of external references. Many loaders
allow user to specify the options that modify the standard processing. Many uses a special
command language to specify the options. Sometimes there is a separate input file to the loader
that contains such control statements. Sometimes, the statements can be embedded in the primary
input stream between object programs.On a few systems the programmer can even include loader
control statements in the source program, and the assembler or compiler retains these commands
as a part of the object program. On some systems options are specified as a part of the job control
language that is processed by the operating system. When this approach is used, the operating
system incorporates the options specified into a control block that is made available on the loader
when it is invoked. One typical loader option allows the selection of alternative sources of input

• Eg: the command:

Might direct the loader to read the designated object program from a library and treat it as if it
were part of the primary loader input. Next command:

Allow users to delete external symbols or entire control sections. It may be possible to change
external references within the programs being loaded and linked. The command might instruct
the loader to delete the named control section(s) from the set of programs being loaded. Next
command,

Might cause the external symbol name1 to be changed to name2 wherever it appears in the object
program.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 28

 CST305 System Software

The command would direct the loader to include the control sections READ and WRITE from
the library UTLIB. The command to delete the control sections RDREC and WRREC from the
load. The first CHANGE command would cause all external references to symbol RDREC to be
changed to refer to symbol READ. Similarly, references to WRREC would be changed to
WRITE.

Next option, automatic inclusion of library routines for external reference(as we have discussed
in the previous class). Most loaders allow the user to specify alternative libraries to be searched
using a statement such as,

Such user-defined libraries are searched before the standard system libraries. This allows the user
to use special versions of the standard routines. Loaders that perform automatic library search to
satisfy external references often allow user to specify that some references not be resolved in this
way. Suppose for example, that a certain program has as its main function the gathering and
storing of data. However, the program can also perform an analysis of the data using the routines
STDDEV, PLOT and CORREL from a statistical library. The user may request this analysis at
the execution time. Since the program contains external references to these three routines, they
would ordinarily be loaded and linked with the program.

If it is known that the statistical analysis is not to be performed in a particular execution of this
program, the user could include a command such as:

It instruct the loader that these external references are to remain unresolved. This avoid the
overhead of loading and linking the unneeded routines and saves the memory space that would

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 29

 CST305 System Software

otherwise be required. Another option is that it is possible to specify that no external references
be resolved by library search. Of course this means an error will result if the program attempts to
make such an external reference during execution. This option is more useful when programs are
to be linked but not executed immediately. In such a case, it is often desirable to postpone the
resolution of external references. Linkage editor performs this task(we can discuss).

Another common option involves output from the loader. Loadmap might be generated during
the loading process. Through the control statements the user can specify whether or not such a
map is to be printed at all. If a map is desired, the level of detail can be selected. For example,
the map may include control section names and addresses only. It may also include external
symbol addresses or even a cross reference table that shows references to each symbol.

Another option, the loader has the ability to specify the location at which execution is to
begin(overridding any information given in the object program).

Another is the ability to control whether or not the loader should attempt to execute the program
if errors are detected during the load (for example unresolved external references)

Loader design Options

Alternatives for organizing the loading functions, including relocation and linking. We have
studied two pass linking loader algorithm, in that linking loaders perform all linking and
relocation at load time. As an alternative to this:

1. Linkage editors: perform linking prior to load time.

2. Dynamic linking: in which linking function is performed at execution time.

Linkage Editor

Are found in many computing system instead of or in addition to the linking loader. A linkage
editor performs linking and some relocation. However, the linked program is written to a file
instead of being immediately loaded into memory. This approach reduces the overhead when
the program is executed. All that is required at load time is a very simple form of relocation. The
essential differences between linkage editor and linkage loader is given in the figure:

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 30

 CST305 System Software

The source program is first assembled or compiled, producing an object program(which may
contain several different control sections). A linking loader performs all linking and relocation
operations including automatic library search if specified and loads the linked program directly
into the memory for execution. In Linkage editor, it produces a linked version of the program
called load module or an executable image, which is written to a file or library for later
execution. When a user is ready to run the linked program, a simple relocating loader can be
used to load program into memory. The only object code modification is necessary in the
addition of actual load address to relative values within the program.

The linkage editor performs relocation of all the control sections relative to the start of the linked
program. Thus all items that need to be modified at load time have values that are relative to the
start of the linked program. This means that the loading can be accomplished in one pass with no
external symbol table required. This involves much less overhead than using a linking loader. If
a program is to be executed many times without being reassembled, the use of a linkage editor
substantially reduces the overhead required.Resolution of external references and library
searching are only performed once, (ie., when the program is link edited). In contrast, linking
loader searches libraries and resolves external references every time the program is executed.
Sometimes, a program is reassembled for nearly every execution. Situation occurs in a program
development and testing environment. Also occurs when a program is used so infrequently, it is
not worth to store the assembled versions in a library. In such case, it is more efficient to use a
linking loader , which avoids the steps of writing and reading the linked program.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 31

 CST305 System Software

The linked program produced by the linkage editor is generally in a form that is suitable for
processing by a relocating loader. All external references are resolved, and relocation is indicated
by some mechanism such as modification records or bit mask. Even though all linking has been
performed, information concerning external references is often retained in the linked program.
This allows subsequent re-linking of the program to replace control sections, modify external
references, etc. If this information is not retained, the linked program cannot be reprocessed by
the linkage editor, it can only loaded and executed. If the actual address at which the program
will be loaded is known in advance, the linkage editor can perform all of the needed relocation.
The result is a linked program that is an exact image of the way the program will appear in
memory during execution.

The content and processing of such an image are the same as for an absolute object program.
Normally, however the added flexibility of being able to load the program at any location is
easily worth, the slight additional overhead for performing relocation at load time.

Linkage editors can perform many useful functions besides simply preparing object program
for execution.For ex: Consider a program (PLANNER) that uses large number of subroutines

1. Suppose that one subroutine (PROJECT) used by the program is changed to correct
an error or to improve efficiency.

• After new version of PROJECT is assembled or compiled, the linkage editor can be
used to replace this subroutine in the linked version of PLANNER

• It is not necessary to go back to the original (separate)versions of all of the other

subroutines

• The following is a typical sequence of linkage editor commands used:

2. Linkage editors can also be used to build packages of subroutines or other control
sections that are generally used together

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 32

 CST305 System Software

• This can be useful when dealing with the subroutine libraries that support high-level
programming languages
• Ex: In FORTRAN, there are a large number of subroutines that are used to handle
formatted input and output
• These include routines to read and write data blocks, to block and de-block records, to
encode and decode data items according to format specifications
• There are a large number of cross reference between these subprograms because of
their closely related functions
• However it is desirable that they remain as separate control sections for reasons of
program modularity and maintainability
• If a program using formatted I/O were linked in the usual way, all of the cross-
reference between these library subroutines would have to be processed individually
• Exactly, the same set of cross-references would need to be processed for almost every
FORTRAN program linked
• This represents a substantial amount of overhead
• The linkage editor could be used to combine the appropriate subroutines into a
package with a command sequence :

• The linked module named FTNIO could be indexed in the directory SUBLIB under the
same names as the original subroutines.

• Thus a search of SUBLIB before FTNLIB would retrieve FTNIO instead of the separate
routines

• Since FTNIO already has all of the cross-reference between subroutines resolved, these
linkages would not be reprocessed when each user’s program is linked

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 33

 CST305 System Software

• The result would be much more efficient linkage editing operation for each program and
a considerable overall savings for the system

3. Linkage editors often allow the user to specify that external references are not to be
resolved by automatic library search

• Using commands, the user could specify that no library search be performed during
linkage editing

• Thus only user-written routines would be resolved

• A linking-loader could then be used to combine the linked user routines with linked
module at execution time

• Because this process involves two separate linking operations, it would require slightly
more overhead; however it would result in a large savings in library space

• Compared to linking loaders, linkage editors in general tend to offer more flexibility and
control with the corresponding increase in complexity and overhead

Dynamic Linking

Linkage editors perform linking operations before the program ids loaded for execution. Linking
loaders perform these same operations at load time. A scheme that postpones the linking function
until execution time; a subroutine is loaded and linked to the rest of the program when it is first
called. This type of function is usually called dynamic linking, dynamic loading or load on
call. Dynamic linking is often used to allow several executing programs to share one copy of a
subroutine or library. For ex: run-time support routines for a high level language like C could be
stored in a dynamic link library. A single copy of the routines in this library could be loaded into
the memory of the computer. All C programs currently in execution could be linked to the one
copy, instead of linking a separate copy into each object program. In object oriented system,
dynamic linking is often used for reference to software objects. This allows the
implementation of the object and its method to be determined at the time the program is run. The
implementation can be changed at any time, without affecting the program that makes use of the

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 34

 CST305 System Software

object. Dynamic linking also makes it possible for one object to be shared by several programs.
Dynamic linking –Advantages:

• For ex: a program contains subroutines that correct or clearly diagnose errors in the input
data during execution

• If such errors are rare, the correction and diagnostic routines may not be used at all
during most executions of the program

• However, if the program were completely linked before execution, these subroutines
would need to be loaded and linked every time the program is run

• Dynamic linking provides the ability to load the routines only when (and if) they are
needed

• If the subroutines involved are large, or have many external references, this can result in
substantial savings of time and memory space

• Similarly, suppose that in one execution a program uses only a few out of a large number
of possible subroutines, but the exact routines needed cannot be predicted until the
program examines its input

• This situation could occur with a program that allows its user to interactively, call any of
the subroutines of a large mathematical and statistical library

• The input data could be supplied by the user, and the result could be displayed at the
terminal

• In this case, all of the library subroutines could potentially be needed , but only few will
be actually be used in any one execution

• Dynamic linking avoids the necessity of loading the entire library for each execution

• Mechanism in which routines that are to be dynamically loaded must be called via, an
operating system service request

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 35

 CST305 System Software

• This method could also be thought of as a request to be a part of the loader that is kept in
memory during execution of the program

Instead of executing a JSUB instruction that

refers to an external symbol, program makes a
load-and-call service request to operating
system. The parameter of this request is the
symbolic name of the routine to be called (fig.a).
The operating system examines its internal
tables to determine whether or not the routine is
already loaded. If necessary, the routine is
loaded from the specified user or system
libraries (fig.b). Control is then passed from the operating system to the routine being called
(fig.c). When the called subroutine completes its processing, it returns to caller (ie., to the OS
routine that handles the load-and-call service request).

The OS then returns control to the program that issued the request (fig.d). It is important that
control be returned in this way so that the operating system knows when the called routine has
completed its execution. After the subroutine is completed, the memory that was allocated to
load it may be released and used for other purposes. However, it is not done immediately. It is
desirable; to retain the routine in memory for later use as long as the storage space is not needed
for other processing. If the subroutine is still in the memory, a second call to it may not require
another load operation. Control may simply be passed from the dynamic loader to the called
routine.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 36

 CST305 System Software

When dynamic linking is used, the association of an actual address with the symbolic name of
the called routine is not made until the call statement is executed. Another way of describing this
is to say that the binding of the name to an actual address is delayed from load time until
execution time. This delayed binding results in greater flexibility. It also requires more overhead
since the operating system must intervene in the calling process.

Bootstrap Loader

Given an idle computer with no program in memory, how do things get started? In this situation,
with the machine empty and idle, there is no need for program relocation. We can simply specify
the absolute address for whatever program is first loaded. Most often the program will be
operating system, which occupies a predefined location in memory. This means that we need
some means of accomplishing the functions of an absolute loader. Some early computers
required the operator to enter into memory the object code for an absolute loader, using switches
on the computer console. However, this process is much too in convenient and error-prone to be
a good solution to the problem. On some computers, an absolute loader program is permanently
resident in ROM (Read-only Memory). When some hardware signal occurs (for ex: operator
pressing a “system start “ switch), the machine begins to execute this ROM program. On some
computers the program is executed directly in the ROM. On others; the program is copied from
ROM to main memory and executed there. However, some systems do not have such read only
storage. In addition, it is inconvenient to change a ROM program if modifications in the absolute
loader are required. An intermediate solution is to have a built –in hardware function that reads a

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 37

 CST305 System Software

fixed-length record from some device into memory at fixed location. The particular device to be
used can often be selected via console switches. After the read operation is complete, the control
automatically gets transferred to the address in memory where the record was stored. This record
contains machine instructions that load the absolute program that follows. If the loading process
requires more instructions that can be read in a single record, this record causes reading of
others, and these in turn can cause the reading of still more records –hence the term Bootstrap.
The first record is generally referred to as a bootstrap loader. Such a loader is added to the
beginning of all object programs that are to be loaded into an empty and idle.

Ms. Anna N Kurian, Asst. Prof., Dept. of CSE, SJCET,Palai 38