[TUHS] Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format)

[Paul Winalski <paul.winalski@gmail.com>]

On 2/25/23, Clem Cole <clemc@ccc.com> wrote:
>
> The IBM link
> editors needed all that back in the day.

One of the complications of executable images was the address space
layout for OS/360.  There was no virtual memory.  The low part of the
address space was where the operating system kernel (supervisor, in
IBM-speak) lived.  Each of what we now call processes was assigned a
contiguous portion of the remaining address space (this was called a
partition).  As executable program retained the relocations that had
been applied by the linker so that the program loader could adjust the
addresses in the executable depending on which partition it was being
loaded into.  This made things more complicated for the link editor.

The OS/360 link editor also doubled as a patch tool.  The link editor
was capable of taking an executable and a set of new versions for some
object modules, un-linking those modules, and replacing them with the
new versions, adjusting all relocations accordingly.

> Please correct me if I'm misinformed, but Paul, of course, had to support
> the DEC language tools on Unix, which had come from systems that had a more
> flexible format (the solution for Ultrix IICR was to move a flavor of the
> VMS linker to UNIX for object file and just a.out for execution).

VAX Fortran for Ultrix was a port of the VAX/VMS Fortran compiler and
runtime to Ultrix.  There were two big problems, object-file-wise.
First, VAX Fortran used many of the advanced features of the VMS
object language.  To generate a.out directly, those chores would have
to be done in the compiler's code generator.  The runtime library had
an even worse problem.  One innovative feature of VMS was that it had
a very robust ABI that could support every programming language then
known, and the compiler development teams were required to adhere to
this ABI and to provide language extensions were necessary to support
all of the ABI's features.  The result was that calling subroutines
written in a different language was dead easy.  It didn't matter which
programming language you used.  The developers of the Fortran runtime
took full advantage of that, and it contained routines written in
several languages.  This meant that we would either need to add a.out
support to the code generators of all of those compilers (there was no
common back end in those days) or write a VMS .obj-to-a.out
translator.  In the end we decided that the easiest solution to both
problems was to add a.out support to the VMS linker and to port it to
Ultrix.  The result was lk(1), a linker that accepted either VMS .obj
or a.out as input and generated an a.out executable.

> My point, the UNIX developers built what they needed and built that well.

Amen to that.  That observation applies to a lot of the design of Unix.

> Their format worked with their development primary language/tool (a.k.a. C)
> and they even made it work with an f77 implementation. So it is a little
> hard to knock them too much -- it was not part of the original design spec.

They did what was right given their circumstances and resources.  I
know of two major operating system development efforts at DEC, OFIS
and MICA, that illustrate what happens if you try to take the opposite
tack.  Their thinking was, "Gee, we have a lot to do and a short
schedule.  I know--let's invent a new programming language and write a
compiler for it."  Both ended up being disastrous examples of Second
System Syndrome.

> And I wonder how many people here know the significance of the "407" magic
>> number?
>>
> Today, few and fewer I fear.  For those do not, please see page 4-33 of the
> 1975/76 DEC PDP-11 Processor Handbook and think about boot blocks.  🍺
> ᐧ
Cute.

-Paul W.