From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11003 invoked from network); 25 Feb 2023 17:29:32 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 25 Feb 2023 17:29:32 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 6AFCD4324C; Sun, 26 Feb 2023 03:29:27 +1000 (AEST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by minnie.tuhs.org (Postfix) with ESMTPS id 370264228B for ; Sun, 26 Feb 2023 03:29:17 +1000 (AEST) Received: by mail-pj1-x102d.google.com with SMTP id y2so2144613pjg.3 for ; Sat, 25 Feb 2023 09:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4b3HehGEoQF+bvNSlpn9JqvNj12pDvL2z57Mkzy6WzI=; b=aP41+u+oBxH5vYsKO/39vGZkHkRERGQ/QLW0RVKq7MRwDhxUa0J8PjcC63Pe4itGx9 kfQD00NX/cBZl9s1KzbrQBFlEqyiX6lnRQ8SVjXLchgtQZU2d+1AyP2mXin4U//k5XAo vG7Ov2XI8WgvXf4zzp1k87f+fNwx9SS9Dh5maz1d8oYAxg+lGFDZORiaUryWc/pFihGs 8F6Ho0zBxFLFdYEvkN5fthY0ZdRLHAaDM0FCvxuGO+tLm23IEEqWHyChaZZtdmKBw/F1 M/7As03FhuR9ynqWQ/IzGSnFMcl9Nj46XRvUHfYGcUUUvrviegHaLZ4au3VUhiwzwZZc D3iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4b3HehGEoQF+bvNSlpn9JqvNj12pDvL2z57Mkzy6WzI=; b=NSddPxlJhcJkFZ3KshOCnZldZFp3iSNF/RVjcAonL+UvwbpgBgQ1ZN/E9y1akBJu2N A+O3VzZIk3aLGyIXQhT7kXWsw7X6QEut0ZU2mqLTqrNZRHTVrSlCWRwu6Ta043L0sQvt T6zLSzRHByyCgpkwAU0VKFk+92bMh/XbMbtTrjjdoi4SugjR6XuHPOPaokcJwbQ4zs9Y a8S6/On1q4SZcN3TJrGzGI/WW7wjR54QrtJHQ1KD4JbinFvxjF0XUZSe/0waIGRGavZd 2/5IM5vU5STIpVeCdrgF21XVqRwEn7AEK+AqrdrvpraoKjaUF4FtMluMrgx8Y6aaXU8v c58w== X-Gm-Message-State: AO0yUKXYQQ50VH3dr1WCkbDMG7F9f+Ea6mq9bv+wfm4m0Tk8T92vXmux 7HyC2dAgZUJ+sALbZY8kq32/T+25pQPyrTHWBGmKd/UB X-Google-Smtp-Source: AK7set9erZVNGYNXMeg2KeEU/ploZ7cbdo/QoJnrR6mwTMWCRJ17Hh/B5HjqIZyyFrvjcV91+g19M9FQq+wwCvbD+d8= X-Received: by 2002:a17:90a:f692:b0:234:b29d:3319 with SMTP id cl18-20020a17090af69200b00234b29d3319mr3052040pjb.8.1677346156542; Sat, 25 Feb 2023 09:29:16 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6a11:3dc7:b0:412:8124:c58f with HTTP; Sat, 25 Feb 2023 09:29:15 -0800 (PST) In-Reply-To: References: From: Paul Winalski Date: Sat, 25 Feb 2023 12:29:15 -0500 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: VGI2EDBZGIIGHHKGFOTG2YEQU6F4YJKA X-Message-ID-Hash: VGI2EDBZGIIGHHKGFOTG2YEQU6F4YJKA X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2/25/23, Clem Cole 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 mo= re > 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 spe= c. 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" magi= c >> number? >> > Today, few and fewer I fear. For those do not, please see page 4-33 of t= he > 1975/76 DEC PDP-11 Processor Handbook and think about boot blocks. =F0= =9F=8D=BA > =E1=90=A7 Cute. -Paul W.