[TUHS] Bootstrapping UNIX - how was it done

[Dan Cross via TUHS]

On Tue, Mar 24, 2026 at 1:16 PM Clem Cole via TUHS <tuhs at tuhs.org> wrote:
> [snip]
> The 635/645 changes were bigger.  GE added new instructions for base
> register management, control/descriptor management, and support for its new
> ring-based security model.  They also made one major change to the
> instruction-word formats between the two models.  On the 635, bit-29 was
> not really used, so on the 645 if it was set a different layout [base
> register member format] was used to interpret the instructions.  I suspect
> the changes to the instruction fields are why Dan thinks they were
> different.

Yes, primarily. I'm sure there was much that was quite similar between
the two, and I don't mean to overstate it, but my sense was that the
changes made to the 645 to support Multics were substantial.

        - Dan C.

> >> Dan Cross wrote:
> >> > Despite the similarity in name, the 635 and 645 were very different
> >> machines
> >>
> > Be careful, that's not completely true.
> >
> > I always thought that approximately, the 645 = 635 + Multics stuff.
> >>
> > Exactly: the GE645 is a 635 plus what GE called the Appending Unit (APU) .
> > This was the same idea IBM used with the 360 models 65 and 67.  The 67 had
> > what IBM called the Data Address Translator (DAT) and some new microcode.
> >
> >> Is that not so?
> >>
> > The APU had the new hardware to:
> >
> >    - Paged Segmentation: Support for both paging and independent
> >    segments, which allowed for the "single-level store" abstraction central to
> >    Multics.
> >    - New Addressing Modes: The addition of an "Appending Mode" that used
> >    18-bit segment numbers and 18-bit offsets, effectively expanding the
> >    address space and simplifying virtual memory support.
> >    - Associative Memory: Implementation of what is now known as a Translation
> >    Lookaside Buffer (TLB) to speed up address translation.
> >    - Base Registers: Eight 24-bit address base registers (often used in
> >    pairs) to handle segmented addresses.
> >
> > Note that because of the changes to the addressing logic and the
> > instruction set, the GE-645 was not directly object-code compatible with
> > the GE-635. However, the 645 remained compatible enough with the 635 family
> > to run the standard GE operating system (GECOS) and memory controllers.  The
> > GE-645 featured a way to switch hardware (described as a "mode knob") — that
> > allowed it to operate in "GCOS mode".
> > So an object file written for the GE-635 GECOS could run a 645 running
> > GECOS with mode nob set.  But that same object could not run directly on
> > *Multics* as a native executable.  I don't have the details, but I
> > believe the 635 object can be run using a simulator or a specific command
> > that sets up a GECOS environment for the processing and runs that object.
> >
> > FWIW: TSS/360 worked the same way.  An OS/360 application could not
> > directly execute on a 67 running TSS/360, although it was basically
> > straightforward to modify the source [this is what my first paid
> > programming gig was - moving York/APL to TSS].  That said, CP-67
> > "Hypervisor" from IBM Cambridge allowed you to boot unmodified copies of
> > OS/360.  So a 67 could run those user binaries in a VM [this is like
> > running VMWare on my Intel Mac, so I can run Windows-11 applications in a
> > "hosted" Win11 instance].
> >