Re: linking in OS/360, was The History of the ALGOL Effort

Peter Flass wrote:
>
> I finally just finally got around to reading _The Mythical Man-Month_,
> and Fred Brooks has some comments on the OS/360 Linkage Editor. His
> thesis is that it's the final culmination of the overlay linkers in
> previous systems, such as the 7094 -- whatever they would have wanted
> there got thrown into OS/360, making it very slow. At the same time
> OS/360 got, and made extensive use of, dynamic linking, that made most
> of the features of the Linkage Editor obsolete. Unfortunately, the
> two development groups didn't communicate too well...
>
> [That's not really what he said on page 56. OS didn't have dynamic
> linking in the modern sense. What it did have was the ability to
> allocate storage dynamically to each program. OS programs used static
> overlays extensively, probably too extensively. IEWL, the link editor,
> was heavily overlaid so it could run in a tiny amount of storage, like
> 8K bytes, at the cost of dreadful performance as it read in all those
> overlays. But in the 99% of the cases where it had a whole lot more
> than 8K available, since the overlay structure was fixed at link time,
> it still did all the overlays and was just as slow. One of the nicest
> things about virtual memory is that it automatically sizes to the
> amount of real storage you have, so if you attach more memory, your
> programs automatically run faster. -John]


John - I read his words that somewhat differently. If you look at
PL/I(F), for example, you find a huge program composed of many small
pieces, each linked separately into a small load module. The "overlays"
are done using OS/360 LINK and XCTL macros rather than via the Linkage
Editor. The execute loads a small root phase that links in turn to s
series of second-level modules, each of which links to a series of
third-level modules. I think three is it, but the important point is
that none of this is done with the help of the Linkage Editor, but
through dynamic allocation of storage and dynamic program loading.

Return to the comp.compilers page.
Search the comp.compilers archives again.