[TUHS] Bootstrapping UNIX - how was it done

[Clem Cole via TUHS]

Dragging hard into my own personal memory, with the 67; IBM added a mode to
the PSW and two new interrupts (Segment translation exception — Code
16 and Page
translation exception — Code 17 ).   The user programs got Branch and Store
(BAS), Branch and Store Register (BAS & BASR) [instead of using Branch and
Link and Branch and Link Register [BAL/BALR]; and three new
privileges instructions for the OS: Load Multiple Control (LMC),  Store
Multiple Control (SMC) which manipulated the registers for the segment
table and other stuff used in the DAT box; as well as Load Real Address
(LRA). LRA was used in the fault processing to ask the HW to perform a
virtual-to-real address translation.  It returned the corresponding actual
real memory address if it was in memory, or a failure code if the page
wasn't currently resident.

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.

On Tue, Mar 24, 2026 at 12:49 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Tue, Mar 24, 2026 at 1:50 AM Lars Brinkhoff via TUHS <tuhs at tuhs.org>
> wrote:
>
>> 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].
>