Re: The History of the ALGOL Effort

glen herrmannsfeldt <gah@ugcs.caltech.edu>
12 Sep 2006 19:18:43 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: The History of the ALGOL Effort alexc@TheWorld.com (Alex Colvin) (2006-08-31)
Re: The History of the ALGOL Effort henry@spsystems.net (2006-09-11)
Re: The History of the ALGOL Effort Peter_Flass@Yahoo.com (Peter Flass) (2006-09-11)
Re: The History of the ALGOL Effort cbarron413@adelphia.net (Carl Barron) (2006-09-12)
Re: The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-12)
Re: The History of the ALGOL Effort ArarghMail609@Arargh.com (2006-09-12)
Re: The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-12)
Re: The History of the ALGOL Effort alewando@fala2005.com (A.L.) (2006-09-12)
Re: The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-13)
Re: The History of the ALGOL Effort H.T.de.Beer@gmail.com (HT de Beer) (2006-09-16)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 12 Sep 2006 19:18:43 -0400
Organization: Compilers Central
References: 06-08-082 06-08-086 06-08-105 06-08-138 06-09-050 06-09-053
Keywords: linker, history

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



Post a followup to this message

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