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

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.