| glen herrmannsfeldt 2004-06-25, 7:43 pm |
| Richard Maine wrote:
> "James Giles" <jamesgiles@worldnet.att.net> writes:
[color=darkred]
> You mentioned that terminology question before. but I'm not
> sure that the terminology has changed.
> My early memories recall IBM mainframes having two separate things, a
> linker and a loader. I don't recall the exact names. (Something like
> linkage editor perhaps instead of linker?). Seems to me that what I
> recall the linker (or linkage editor) from then doing is much like
> what we now call linking.
My understanding is that the program called LOADER came along
a little later in OS/360 evolution. The process of loading
load modules into memory is called program fetch.
There is a description on Brooks' "Mythical Man Month" about
the OS/360 linkage editor,
"Consider the linkage editor, designed to load separately compiled
programs and resolve their cross references. Beyond this basic
function it also handles program overlays. It is one of the
finest overlay facilities ever built. It allows overlay structuring
to be done externally, at linkage time, without being designed
into the source code. It allows the overlay structure to be
changed from run to run without recompilation. It furnishes
a rich variety of useful options and facilities. In a sense, it
is the culmination of years of development of static overlay
technique."
Continuing on...
"Yet it is also the last and finest of the dinosaurs, for it
belongs to a system in which multiprogramming is the normal
mode and dynamic core allocation the basic assumption. This
is in direct conflict with with the notion of using static
overlays. How much better the system would work if the efforts
devoted to overlay management had been spent on making the
dynamic core allocation and the dynamic cross referencing
facilities really fast!"
Well, Brooks likes PL/I, and Fortran with dynamic allocation
was still years away. But further on he mentions that one
point of the linker was to avoid recompilation, yet the linker
was bigger and slower than many of the compilers.
Anyway, the linkage editor does have the ability to read its
own output. One can, in fact, change one subroutine in an
already linked load module. That ability does not
work if the subroutine has been inlined, such that it
doesn't exist in the load module.
Changing the overlay structure of a compiled program is
not unusual. In a virtual storage system it is more
efficient to use paging than overlays, so the Fortran H
compiler was usually relinked to remove the overlays,
and run in 640K or more.
> Though I guess I also recall the name "loader" on other machines,
> as with CDC's segloader, but that terminology is newer than IBM's,
> so I'm not sure it has as good a claim to being "traditional".
> Being a youth of a mere 52 years, I wasn't programming much in
> the 50's or even most of the 60's, so I guess I can't claim
> much direct exposure to "traditional" terminology.
> I would say that the term "link" makes more sense to me for this
> operation. The "interesting" parts involve connecting the links
> between the parts. The linker doesn't actually load the program
> into memory - that would be the loader (which us programmers
> normally don't have to deal very directly with, as it doesn't have
> as many issues that matter to us).
I believe the term "linking loader" is also used. Unix uses
the link command, ln, to do links between files in directories,
so the link command ld is used.
As well as I remember TOPS-10, the LINK command loaded the
program into memory, and the SAVE command wrote the .SAV
file, the program image, to disk.
-- glen
|