Related articles |
---|
[2 earlier articles] |
Re: The History of the ALGOL Effort Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-08-18) |
Re: The History of the ALGOL Effort p_ludemann@yahoo.com (Peter Ludemann) (2006-08-29) |
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: linking in OS/360, was The History of the ALGOL Effort Peter_Flass@Yahoo.com (Peter Flass) (2006-09-12) |
Re: linking in OS/360, was The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-12) |
Re: linking in OS/360, was The History of the ALGOL Effort p_ludemann@yahoo.com (Peter Ludemann) (2006-09-13) |
Re: linking in OS/360, was The History of the ALGOL Effort gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-16) |
OT: Delinking, was Re: linking in OS/360, was The History of the ALGOL Peter_Flass@Yahoo.com (Peter Flass) (2006-09-18) |
From: | Peter Ludemann <p_ludemann@yahoo.com> |
Newsgroups: | comp.compilers |
Date: | 13 Sep 2006 02:37:57 -0400 |
Organization: | SBC http://yahoo.sbc.com |
References: | 06-08-082 06-08-086 06-08-105 06-08-138 06-09-050 06-09-053 06-09-065 |
Keywords: | linker, comment |
Posted-Date: | 13 Sep 2006 02:37:57 EDT |
On 9/12/2006 4:19 PM, Peter Flass wrote:
[snip]
> ... 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.
Sorry to disagree with you on ancient history, especially when I don't
have any manuals, but I have done overlays on OS/370 entirely with
commands to the linkage-editor. The programmer did need to specify the
overlays; but the compiler didn't need to do anything at all. Also,
one could go as deep as desired in the overlay structure, although I
suspect that 3 was the practical limit.
You can see an example here: http://www.iecc.com/linker/linker08.html
... scan for "Defining overlays" and "Implementation of overlays". The
glue code wasn't LINK and XCTL; there were some other system macros that
were usually relegated to appendices because they weren't normally used
by programmers - the link-editor created all the glue code and system
macro calls.
One of the problems with the OS/360 linkage-editor was that it had an
unnecessarily complex executable format (the object format, however, was
fairly simple - the best documentation is in Gries). By comparison, the
MTS operating system used the same object file format as OS/360 but
didn't have a special executable format - instead, it had a program that
would combine object files into a single large object file, resolving
addresses wherever possible (and also making long TXT records instead of
the 80-byte object-format records), so it was about as space- and
time-efficient as the OS/360 executable format). The net effect was that
MTS had a fast linker that an undergrad could implement and which easily
supported incremental linking and incremental loading, something which
more "modern" OSes such as Un*x either can't do, or do with a lot of
pain. So, you could do something like this:
$RUN p1.o+p2.o+p3.o+*LIBC*
which is roughly the equivalent of this in Unix:
exec <(cat p1.o p2.o p3.o /lib/libc.so)
or, for convenience/efficiency:
$LINK p1.o+p2.o+p3.o+*LIBC* SINK=p.exe
$RUN p.exe
(*LIBC* would be in a shared segment, so it behaved more like a .so than
a .a library) (And for anyone who remembers MTS - yes, I'm making a few
small simplifications for pedagogic purposes)
And the MTS linker was seldom used because the incremental loader was
fast enough.
- peter ludemann
[I don't think the two of you are disagreeing. The OS linker let
(still lets) you do digital origami and fold up a single program into
overlays, with the creases at CSECT boundaries, each CSECT typically
being a subroutine. But for some reason PL/I F didn't use that, and
instead faked it by dividing up the compiler into a whole bunch of
little programs and using LINK and XCTL to glue them all together.
IBM puts an amazing amount of stuff on line. A 1991 edition of the
linkage editor manual, which isn't very different from a 1969 edition,
is here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGG3L100/CCONTENTS?SHELF=EZ2MV122&DN=SC26-4564-01&DT=19911220122242
Appendix C tells you not to use the overlay system, then tells you all
about how to use it if you do. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.