The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Dave Horsfall <dave@horsfall.org>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format)
Date: Sat, 25 Feb 2023 10:30:25 -0500	[thread overview]
Message-ID: <CAC20D2NO7fnzV5Ux2cTfD6-9y+BZ30458Pd9_V+rEnZ3zC4WwQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.BSF.2.21.9999.2302251302070.56283@aneurin.horsfall.org>

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

On Fri, Feb 24, 2023 at 9:07 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Thu, 23 Feb 2023, Paul Winalski wrote:
>
> > a.out was, as object file formats go, a throwback to the stone age from
> > the get-go.  Even the most primitive of IBM's link editors for
> > System/360 supported arbitrary naming of object file sections and the
> > ability for the programmer to arrange them in whatever order they
> > wished.  a.out's restriction to three sections (.text, .data, .bss) did
> > manage to get the job done, and even (with ZMAGIC) could support
> > demand-paged virtual memory, but only just.
>
> That may be so, but those guys didn't exactly have the resources of
> IBM behind them...
>
A reasonable point, but it was more Ken, Dennis, and the team did what
>>they needed<< and it was good enough for a long time.  The IBM link
editors needed all that back in the day.  As more and more "modern"
languages came into being, it was not until about 6th editions that
difficulties of not having an expandable object format and better linker
began to show, and as Paul says, until the support for demand paging that
a.out was really stressed.

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).   So he
lived the difficulties/shortcomings.  A valid argument is Tanndenbaum's
compiler toolkit survived with a.out, and he supported many of the same
language targets that DEC did.  Andy and crew did their own assemblers,
does anyone remember if they supplied a new linker and object format? That
would make Paul's point more powerful -> the languages people wanted
something more.

My point, the UNIX developers built what they needed and built that well.
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.

But as Matt has discussed in his digging through things, it does look like
as the AT&T languages team started to run into some of the same barriers,
they started to move to a new format.


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.  🍺
ᐧ

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

  reply	other threads:[~2023-02-25 15:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 20:16 [TUHS] " segaloco via TUHS
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 [this message]
2023-02-25 17:29         ` Paul Winalski
2023-02-23 15:13 Noel Chiappa
2023-02-23 21:37 Paul Ruizendaal
2023-02-23 22:11 ` segaloco via TUHS
2023-02-24  0:07   ` segaloco via TUHS
2023-02-25 20:14 Brian Walden
2023-02-26 15:51 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=CAC20D2NO7fnzV5Ux2cTfD6-9y+BZ30458Pd9_V+rEnZ3zC4WwQ@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=dave@horsfall.org \
    --cc=tuhs@tuhs.org \
    /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).