| Gordon Sande 2004-06-25, 7:43 pm |
| On Fri, 18 Jun 2004 19:21:35 -0300, Richard Maine wrote
(in article <m18yekeccw.fsf@macfortran.local> ):
> "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.
>
> 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 had written (and deleted it before posting) a query on the previous
occasion as I had always understood the distinction to be that linking
was associated with the combining of the various object versions of
the programs, including their runtime support, into a single combined
whole. In the simple straightforward case this was mostly library
searching and sorting out of relocation information. This linking was
usually a separate utility. Loading was the action of bring the
whole thing into main memory, with some simple relocation, so it
could be executed. This is typically an operating system service.
Then things get murky as there are load-and-go systems where the
linker lays thing down directly in memory and then turns control
over to the result. And there is also dynamic loading which may
involve a fair bit of resolving symbolic names and sorting out
relocation which is much of the work of a linker. I have hazy
memories of some systems (Multics?) where this was actually
called dynamic linking.
On IBM/7090s for Fortran II there was a linker which included
knowing where the executable would be loaded (octal 400 as I
recall). Then there was a student faster turn around system
(Fastran) which had load and go as one feature and no
optimization as another. Fortran II did a lot of optimization
because it was guessed that the compiler had to produce good
to be accepted. IBM/360s had a linkage editor with loading
being an SVC. PCs with DOS had a linker with a fixed load
address (because Bill gates wondered why anyone would ever want
more than 640k long before things like my G5 Mac with 128M video
buffer). On Unix I recall something called ld. These all get
well hidden behind the standard compile-link-exececute command
file which seem to generate questions about how to indicate
additional libraries.
So my take on terminology would be compiler goes from .f90 to
..obj and then the linker goes from .obj to .exe and the operating
system load service executes the .exe in memory.
>
|