[TUHS] Unix use of VAX protection modes

[Clem Cole via TUHS]

below

On Tue, Jan 20, 2026 at 9:08 PM Erik E. Fair via TUHS <tuhs at tuhs.org> wrote:

>
> Also, yeah, Bourne shell's ... interesting ... notions of memory
> management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000
> because it didn't keep enough state for restarting faulted instructions
> unlike the DEC PDP-11 (Clem, do you want to chime in here to describe
> MassComp's extravagant solution to that?). Asa Romberger recounted the tale
> of refactoring Bourne shell for mc68000 to me while I was working for Dual
> and visiting UniSoft relatively frequently. The mc68010 fixed that
> incomplete fault state bug, and made demand-paged virtual memory possible
> for mc68k-family-based systems.
>
To be fair, the idea originated with Forest Baskett's Asilmar paper in
1980, if I remember the date correctly.  Sadly, the paper appears to have
been lost to time, as far as I can tell.  As Erik mentioned, the problem is
that the instruction needs to be restarted and allowed to complete — after
the VM code makes the page available, it restarts the processor with the
original instruction that previously failed.

Without getting into too many HW details, there were several types of
memory available, each with different characteristics for accessing them.
Also, the processors of that day used a synchronous bus -* i.e.*, the
processor put an address onto the memory bus and waited for the resulting
read or write before the instruction that created the address "complete."
[1]  Since different memories have different timing characteristics, the
68000 has a "wait state" pin. Depending on how long it has been asserted,
it allows N clock cycles to go by while the processor waits for the memory
transaction to complete.

So the Masscomp MC500 CPU board had 2 68000s on it, called the "executor"
and the "fixer."  The fixer did just that.  It ran the code to fetch a new
page for a read or to create a copy of the page on a write, which was in
the address space assigned to the process executing on the processor.  When
an executor "faulted" instead of returning an error, the hardware just sent
wait states to it.  The fixer set the memory and released the wait pin on
the executor, which will complete the requested operation without faulting,
but at the expense of a very long time for that instruction to complete on
the executor.

When Motorola came out with the 68010, which did save enough "microcode"
state so the executor could fault and was free to do something else while
the fixer redid everything.  We swapped out the executor and changed a
small amount of logic on the CPU board.  The executor was free to do
something else while the fixed cared for the memory.  When the fixer gave
the ok, the executor would pick up where it left off in the process that
originally hit the fault.

A "fun" (undocumented) feature was discovered by us soon after the 68010
showed up.   Masscomp was the first UNIX vendor to build and sell an MP
machine (MC500/DP).  But we ran into a field issue with the 68010's.

 It turns out that different microcode was implemented in different "steps"
of the chip.   And what was saved on the stack was different between them.
 So the problem was, if a CPU board was made with a 68010 from batch A, and
its MP twin CPU board had a 68010 from batch B — thus having slightly
different microcode.   The issue we discovered was that when the
68010-based executor on CPU card A faulted, the microcode state was stored
on the stack per Motorola's specs, but when we tried to restart the process
by allowing the previous faulting instruction to be retried, batch B's
68010 executor could not grok the microcode state that had been stored from
executor A  (and vice versa).

After many complaints to our Motorola rep, to get them to make the
microstate saved identical even when they "stepped" the processor.  In the
meantime, manufacturing and field service made the "field replaceable unit"
(FRU) a matched set of processor cards.

Clem







1] The PDP-11 worked this way, but starting with the Vax and copied by more
modern processors is the idea of a "split transaction" bus. where the
processor makes a request of the memory system, and is free to do something
else.  The memory returns a bus transaction indicating whether data was
written or read, and the processor can retire the instructions.  This is
really useful when you start to break up instructions in a pipeline.