The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: segaloco via TUHS <tuhs@tuhs.org>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format)
Date: Wed, 22 Feb 2023 20:16:29 +0000	[thread overview]
Message-ID: <EWB9ZgWtwHriU8xyY3jJDHH4RaBRsX3CsucTWSp3__lMMqOYqA9UXcgi0pyTNfaLZI3EJ6UurR8NZM1bC6fYHR4Meyj4-8YKxKxIsryBtdI=@protonmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4711 bytes --]

Good day all, figured I'd start a thread on this matter as I'm starting to piece enough together to articulate the questions arising in my research.

So based on my analysis of the 3B20S UNIX 4.1 manual I've been working through, all evidence points to the formalized SGS package and COFF originating tightly coupled to the 3B-20 line, then growing legs to support VAX, but never quite absorbing PDP-11 in entirety. That said, there are bits and pieces of the manual pages for the object format libraries that suggest there was some providence for PDP-11 in the development of COFF as well.

Where this has landed though is a growing curiosity regarding:

- Whether SGS and COFF were tightly coupled to one another from the outset, with SGS being supported by the general library routines being developed for the COFF format
- Whether COFF was envisioned as a one-size-fits-all object format from its inception or started as an experiment in 3B-20 development that wound up being general enough for other platforms

- If, prior to this format, there were any other efforts to produce a unifying binary format and set of development tools, or if COFF was a happy accident from what were a myriad of different architectural toolset streams

One of the curious things is how VAX for a brief moment did have its own set of tools and a.out particulars before SGS/COFF. For instance, many of the VAX-targeted utilities in 3.0/System III bear little in common option/manual-wise with the general common SGS utilities in System V. The "not on PDP-11" pages for various SGS components in System V much more closely resemble the 3B-20 utilities in 4.1 than any of the non PDP-11/VAX-only bits in System III.

Some examples:

- The VAX assembler in System III contains a -dN option indicating the number of bytes to set aside for forward/external references for the linker to fill in.
- The VAX assembler in System V contains among others the -n and -m options from 4.1 which indicate to disable address optimization and use m4 respectively
- The System V assembler goes on to also include -R (remove input file after completion) -r (VAX only, add .data contents to .text instead) and options -b, -w, and -l to replace the -d1, -d2, and -d4 options indicated in the previous VAX assembler
- System V further adds a -V to all the SGS software indicating the version of the software. This is new circa 5.0, absent from the 4.1 manual like the R, r, b, w, and l options

- The 4.1 manual's singular ar(1) entry still agrees with the System III version. No arcv(1) is listed, implying the old ar format never made it to 3B-20
- The System V manual has both this ar(1) version as well as the new COFF-supporting version. Not sure if this implies the VAX ar format was expanded to support the COFF stuff for a little while until they decided on a new one or what.

- The System III ld (which is implied to support PDP and VAX) survives in System V, but is cut down to supporting PDP-11 only
- The COFF-ish ld shows up in 4.1, is then extended to VAX presumably in the same breath as the other COFF-supporting bits by Sys V, leading to two copies like many others, PDP-11-specific stuff and then COFF-specific stuff

The picture that starts to form in the context of all of this is, for a little while in the late 70s/early 80s, the software development environments for PDP-11, VAX-11, and 3B-20 were interplaying with each other in often times inconsistent ways. Taking a peek at the 32V manuals, the VAX tools in System III appear to originate with that project, which makes sense. If I'm understanding the timeline, COFF starts to emerge from the 3B-20 project and USG probably decides that's the way to go, a unified format, but with PDP-11 pretty much out the door support wise already, there was little reason to apply that to PDP-11 as well, so the PDP-11 tools get their swan song in System V, original VAX-11 tools from 32V are likely killed off in 4.x, and the stuff that started with the 3B-20 group goes on to dominate the object file format and development software stuff until ELF comes along some time later.

I guess other questions this raises are:

- Were the original VAX tools built with any attention to compatibility with the PDP-11 bits Ken and Dennis wrote many years prior (based on some option discrepancies, possibly not?)
- Do the VAX utilities derive from the Interdata 8/32 work or if there was actually another stream of tools as part of that project?
- Was there any interplay between the existing tool streams (original PDP-11, 32V's VAX utilities, possibly Interdata 8/32) and the eventual COFF/SGS stuff, or was the latter pretty well siloed in 3B-20 land until deployment with 4.1?

- Matt G.

[-- Attachment #2: Type: text/html, Size: 6440 bytes --]

             reply	other threads:[~2023-02-22 20:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 20:16 segaloco via TUHS [this message]
2023-02-22 22:20 ` [TUHS] " Clem Cole
2023-02-23  0:17   ` segaloco via TUHS
2023-02-23  6:30   ` Lars Brinkhoff
2023-02-23 14:25     ` KenUnix
2023-02-23 19:37     ` Warner Losh
2023-02-24 17:01       ` Rich Salz
2023-02-23 16:49   ` Paul Winalski
2023-02-23 18:38     ` segaloco via TUHS
2023-02-23 20:40       ` Paul Winalski
2023-02-24 12:45     ` arnold
2023-02-24 13:13       ` Arno Griffioen via TUHS
2023-02-25 19:28         ` arnold
2023-02-25 19:34           ` Steffen Nurpmeso
2023-02-24 14:01       ` Harald Arnesen
2023-02-25  2:07     ` Dave Horsfall
2023-02-25 15:30       ` Clem Cole
2023-02-25 17:29         ` Paul Winalski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='EWB9ZgWtwHriU8xyY3jJDHH4RaBRsX3CsucTWSp3__lMMqOYqA9UXcgi0pyTNfaLZI3EJ6UurR8NZM1bC6fYHR4Meyj4-8YKxKxIsryBtdI=@protonmail.com' \
    --to=tuhs@tuhs.org \
    --cc=segaloco@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).