Re: The History of the ALGOL Effort

(the moderator said)


> [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.


Well, the LINK macro instruction does what I would call dynamic
linking. It is used extensively in the PL/I (F) compiler instead of
static overlay as used by Fortran H.


Also, the OS itself does a lot of dynamic linking, though the SVC
transient areas aren't so dynamic.


> 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.


That must be Link Editor E, which I never used. Many of the standard
utilities I believe used LINK, though others may have been static
overlays. There is the well known problem of doing an IEBCOPY
compress of SYS1.LINKLIB, and having it fail when loading the
next overlay from a non-existent location. I believe that is
dynamic (LINK), but I am not 100% sure.


> 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]


With VS systems it was recommended to remove overlays.


I believe I have the PLM (program logic manual) for IEWL, which might
explain its structure.


-- glen
[I see your point. LINK does load, relocate, and run a program, but
it isn't dynamic linking in the modern sense because there isn't
symbol resolution between the loaded program and what's already in
memory. I hadn't realized that PL/I F did its overlays with LINK.
Ewww. -John]

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