[TUHS] Unix use of VAX protection modes

[Clem Cole via TUHS]

Thanks, Jonathan - yes, it was COMPCON to Asilimar.

On Wed, Jan 21, 2026 at 5:32 PM Clem Cole <clemc at ccc.com> wrote:

> 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.
>