From coff at tuhs.org Wed Apr 1 13:20:47 2026 From: coff at tuhs.org (Warren Toomey via COFF) Date: Wed, 1 Apr 2026 13:20:47 +1000 Subject: [COFF] Problems with TUHS and COFF mailing lists Message-ID: Hi all, I'm back from a 3 1/2 week overseas holiday. Of course, partway through the trip the TUHS server "minnie" decided to hit 0% free disk space. I was able to clean things out remotely using a tablet and Bluetooth keyboard. However, since then I've had a few e-mails saying that submissions to TUHS and COFF have gone to /dev/null. I haven't deduced the issue yet. So, if in the next few weeks you post to TUHS or COFF and you don't see your posting, please e-mail with as much details as you can provide; a copy of the logs from your mail server would be wonderful! Thanks, Warren From coff at tuhs.org Sat Apr 4 23:41:35 2026 From: coff at tuhs.org (Douglas McIlroy via COFF) Date: Sat, 4 Apr 2026 09:41:35 -0400 Subject: [COFF] GE-635 GECOS? Message-ID: Clem wrote > Check out > https://www.multicians.org/ge635.html > From what I can tell GCOS has been lost to time The Multicians timeline shows Bell Labs joining the project after GE was chosen as the vendor. This may be the date of some formal agreement. However, the Labs was in on the final confirmation of GE. IBM had been ruled out over the issue of virtual memory. GE was happy to offer a VM variant of the 635. In contrast, IBM's chief architect, Gene Amdahl, adamantly maintained that VM was unacceptably inefficient. When it became clear that GE was winning, IBM revealed Gerrit Blaauw's 360 model 67 with VM, which had been kept under wraps. The option was considered, but found to offer no advantage from a programming standpoint. Nevertheless, time-sharing on the IBM machine made it into the field well before Multics; MTS, the Michigan Terminal System, went live in 1967. the same year that GE delivered the 645. A completely unsung project at Bell Labs during the Multics era was Joel Sturman's GUTS, GE User Time Sharing on the 635. Joel built this without any specific kernel support. I'm sorry I don't know more about it, in particular how it did scheduling. Way off topic, but apropos of the 360 vs contemporary 36-bit machines, a member of the design team for the Apollo mission once told me that it was fortunate they were using IBM 700/7000 equipment rather than the new-fangled 360s. 36-bit floating-point precision was just enough to calculate trajectories to the moon without resorting to slow software double precision. The 32-bit floating point of the 360 would have forced the slow alternative. I suspect also that hex rounding would have exacerbated the difference. Doug From coff at tuhs.org Sun Apr 5 02:35:05 2026 From: coff at tuhs.org (Paul Winalski via COFF) Date: Sat, 4 Apr 2026 12:35:05 -0400 Subject: [COFF] GE-635 GECOS? In-Reply-To: References: Message-ID: On Sat, Apr 4, 2026 at 9:42 AM Douglas McIlroy via COFF wrote: > IBM had been ruled out over the issue of virtual memory. GE was happy > to offer a VM variant of the 635. In contrast, IBM's chief architect, > Gene Amdahl, adamantly maintained that VM was unacceptably > inefficient. > Gene Amdahl was a notorious opponent of the concept of virtual memory. He famously stated that virtual memory merely magnified the need for real memory. Amdahl also had big fights with Fred Brooks over the word size for S/360. Brooks insisted that the machine word size be a power of two. Amdahl favored a 24-bit design. They eventually compromised: the word size, registers, and arithmetic operations on S/360 would be 32-bit but the addressing would be 24-bit (16 MB). Given that the biggest main storage ever shipped on a S/360 was 8 MB, 24-bit address circuitry was more than adequate and reduced the manufacturing costs for the machines significantly. -Paul W. From coff at tuhs.org Sun Apr 5 04:59:03 2026 From: coff at tuhs.org (Clem Cole via COFF) Date: Sat, 4 Apr 2026 14:59:03 -0400 Subject: [COFF] GE-635 GECOS? In-Reply-To: References: Message-ID: First, a side note. Seymour felt the same way WRT to VM. The truth is, VM lets the OS and HW *manage the program overlays automatically,* so the programmer doesn't have to think about it. For generations of programmers who have never used overlays and thunks, it seems strange not to have a VM. But supporting VMs takes a lot of resources (in both the HW and the OS), and to many people like Gene and Seymour, it seems like sloppy programming to rely on them. Remember, in 1965 dollars, the price per bit was $2.52 ($25.26 in 2026), whereas modern DRAM is $0.000000007 per bit. Also, a Model 65 installation was often 512 KB or sometimes 1 MB. Wikipedia suggests that configurations exceeding 1 MB were considered "unusual" during the mid-to-late 1960s. CMU's 67 (that I used to program) had 4M, and I think many university sites like Stanford, Michigan, Cornell, and Princeton were likely similar. And to scale the size, a 1M core box was multiple cabinets and about the size of the later DEC 11/780 cabinet. WRT the S/360 architecture, my friend Russ Robelen led the Model 50 hardware team (and was also the guy who convinced Amdahl and Brooks to use microcode for the S/360 project). Some years ago, Russ told me the story of how bytes and words were defined for the S/360. The core of what Paul says is true, but the full facts are even more interesting, and I think it makes a great story. While we think of Brooks for his impact on the software, he was the lead of everything on the project, both hardware and software. Gene led the hardware team. Gene made it clear that he felt anything larger than a 6-bit byte and 24 bits for words and addresses was "a waste of hardware" and would add unreasonable cost and complexity for no real reason. As Paul mentioned, Brooks believed that bytes and words needed to be powers of two "because anything else is just too difficult to program." From what I understand, Gene was not handling that choice well. Russ says, every time Gene brought it up, he got tossed out of Brooks' office and told not to come back. Again, as Paul reported, Fred did relent on the address being 24 bits, but told Gene, "to make damned sure you store them a full word." So, except for the Model 67 [which was a Model 65 plus the VM hardware called "DAT box" [Data Address and Translation], plus some new microcode, all had 8-bit bytes, 16-bit ½ words, and 32-bit full words]. But because the 24-bit addresses were stored and primarily passed as 32-bit words, the 67 could run code targeted for the other models with straightforward changes [67 had a couple of new user space instructions - Branch and Store (BAS), Branch and Store Register (BASR)†, and some new privileged operations specific to the data translation hardware.] Years later, Gordon Bell would state that the #1 issue limiting the longevity of an ISA was too few address bits. IBM started System 370 with the same 24 bits, but by the 370-XA, it finally made everything 32 bits. That architecture survived from 1964-1978 as S/360, 1970-1990 as S/370, and 1990-2000 as S/390. It was not until the zSeries 900 that IBM broke stride and introduced a 64-bit variant, but they do have a level of compatibility that allows 60-year-old binaries to continue running. † Have spent much of my youth moving OS/360 code to TSS. Besides things like different OS Service interfaces and system control blocks, the ugliest thing you had to deal with was how programming used the "wasted" high-order byte when manipulating or storing an address. Because TSS/360 and MTS/360 used 32-bit virtual addresses, some programs that performed manual address arithmetic or "dirty" pointer tricks (like using the high-order byte of a 32-bit register for flags) often broke because the system might need to use those bits for extended addressing. On Sat, Apr 4, 2026 at 12:35 PM Paul Winalski via COFF wrote: > On Sat, Apr 4, 2026 at 9:42 AM Douglas McIlroy via COFF > wrote: > > > IBM had been ruled out over the issue of virtual memory. GE was happy > > to offer a VM variant of the 635. In contrast, IBM's chief architect, > > Gene Amdahl, adamantly maintained that VM was unacceptably > > inefficient. > > > > Gene Amdahl was a notorious opponent of the concept of virtual memory. He > famously stated that virtual memory merely magnified the need for real > memory. > > Amdahl also had big fights with Fred Brooks over the word size for S/360. > Brooks insisted that the machine word size be a power of two. Amdahl > favored a 24-bit design. They eventually compromised: the word size, > registers, and arithmetic operations on S/360 would be 32-bit but the > addressing would be 24-bit (16 MB). Given that the biggest main storage > ever shipped on a S/360 was 8 MB, 24-bit address circuitry was more than > adequate and reduced the manufacturing costs for the machines > significantly. > > -Paul W. >