| James Giles 2004-06-25, 7:43 pm |
| Richard Maine wrote:
> "James Giles" <jamesgiles@worldnet.att.net> writes:
>
>
> 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.
Oh, I agree. When machines were too small to do the
whole task in one go, they had two (or more) tools. And
indeed, one was the linkage editor and the other was the
loader. When it became possible (was always desirable)
to combine the two, the usual choice of name (in my experience
anyway) was some variant of "LOADER". I remember SEGLDR,
LOAD, ld, LDR, and several others. In fact, I can't remember
any variation of "link" being the name of either the tool or the
process in systems between the old IBM stuff and the advent
of PC (also IBM: maybe that's what it is - for a couple of
decades I didn't use IBM much - the gap was between OS/360
and PCs).
> 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.
Well, I started programming in 1967 and I frankly don't recall
what the tool was called in the first system I used (I was only
13). You seem to have a quite long timeline before admitting
something as "traditional". In a fast-changing field like
computing, a few decades of use seems sufficient to establish
a tradition.
> 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 [...]
The word loader doesn't refer to moving the code into memory,
but to loading the various components of a program into a single
executable file from their various libraries and object files. It
is during this step that the real work of the process occurs:
relocation (the adjustment of all addresses to reflect the actual
location of their referents). Perhaps the tool should be called
the "reloacator". But, I suppose in segmented architectures
the job of relocation is not necessarily so onerous (though a lot
of language implementations still tend to use only one or two
segments for everything).
> [...] (which us programmers
> normally don't have to deal very directly with, as it doesn't have
> as many issues that matter to us).
Again I agree. That's a component of the programming environment
that average users (even average application developers) needn't
even have a name for. Much less is it desirable to supplant the
legitimate use of a word that (for my professional life) has usually
had a different meaning.
The only reason I bring it up is that I tend to use the term "load"
(for both the process and the tool that performs it) by second
nature - having maintained and/or rewritten some in my time -
and I've been vehemently attacked for doing so. As a result,
I'm kind of interested in why the change in terminology was made,
and why anyone would be so vehement about it. So, I occasionally
ask (when the other participants are likely to remain civil).
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|