Various wrote:
> Message-ID: <448F414D.7090302@update.uu.se>
> Date: Wed, 14 Jun 2006 00:50:53 +0200
> From: Johnny Billquist <bqt@update.uu.se>
> Organization: Update Computer Club
> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: =?ISO-8859-1?Q?Per_Fogelstr=F6m?= <pefo@opsycon.se>
> CC: rmk@rmkhome.com, Marcus Watts <mdw@umich.edu>,
>         Otto Moerbeek <otto@drijf.net>,
>         Ted Mittelstaedt <tedm@toybox.placo.com>,
>         John Nemeth <jnemeth@victoria.tc.ca>,
>         Nikolas Britton <nikolas.britton@gmail.com>,
>         Ted Unangst <ted.unangst@gmail.com>,
>         =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= <balihb@ogyi.hu>,
>         misc@openbsd.org, freebsd-questions@freebsd.org,
>         netbsd-users@netbsd.org
> Subject: Re: wikipedia article
> 
> Per Fogelstr=F6m wrote:
> > On Tuesday 13 June 2006 14:23, Rick Kelly wrote:
> >=20
> >>Johnny Billquist said:
> >>
> >>>>There's actually a cheesy way to do demand paging with microprocessor=
> s
> >>>>that don't support demand paging (such as the original 68000--another
> >>>>"16 bit" machine).  The way to do this is to run two processors in
> >>>>parallel but skewed by one instruction.  If the first one does a bad
> >>>>memory fetch, then the second one will not have fetched the instructi=
> on
> >>>>causing the fault so contains restartable machine state.  Masscomp so=
> ld
> >>>>a machine like this once.
> >>>
> >>>Didn't the first Apollos do this?
> >>
> >>And also the Sun 1.
> >=20
> >=20
> > IIRC it was simpler than that. When the first cpu caused a 'miss' it wa=
> s put
> > in wait and cpu 2 handled the pagein and then released cpu 1. Keeping t=
> he two
> > cpus synched, one instruction apart would have been too complicated if =
> not
> > impossible...
> 
> Your idea will not work, as far as I can tell.
> If the first CPU instruction execution causes a miss, the end result in=20
> the CPU will be pretty undefined, and you cannot restart. That's the=20
> whole point in why you'd have a second CPU shadowing the first one. So=20
> that you'd be able to restore the state as it were before the illegal=20
> memory access.
> And that was the problem with the original 68000. On an illegal memory=20
> reference, you would not know what state the CPU was in before the=20
> instruction, so you could not back it up, and re-execute the instruction=20
> after a page fault.
> 
> 	Johnny

Several clarifications.  The sun-1 did not have a dual CPU page fault
arrangement.  It used a slightly higher clock speed version of the
same CPU board used previously used by codata & 4 other vendors,
originally designed by stanford university.  Instead of using the
motorola MMU which was late to market, expensive, & slow, or industry
standard MMU cache logic ("TLB"), they used a very clever generic chip
implementation that used the CPU alternate space instructions to manage
dedicated high speed RAM which provided all the mapping.  This managed
a page addressed space, but did NOT do demand paging.  Another exciting
low-cost feature of the sun-1 CPU was "software" dynamic ram refresh-
every 2 ms, the CPU was interrupted by the refresh interrupt and would
execute 127 nop instructions.  The sun-2 was very similiar to the sun-1,
but upgraded the 68000 to a 68010 (which could do instruction restarts
and hence demand paging), deleted the onboard RAM, and instead added
the ability to use DMA via an IOMMU to private bus RAM.  The sun-1 ran
unisoft version 7 unix, complete with swapping.  The sun-2 ran "4.2bsd".
I've got an actual physical "codata" processor manual (complete with
schematics) but I believe I've seen a sun-1 processor manual in pdf
somewhere on the web recently.

I'm not 100% sure how masscomp or apollo handled page faults.  The
impression I had is that the first CPU got "reset", and the second was
interrupted on the instruction boundary and saved its CPU state first
thing in the interrupt handler.  While the user register state in the first is
"undefined", the CPU itself is still good - it can take an interrupt,
transition into kernel mode and recover machine state from somewhere
else (like the 2nd CPU) just fine.  That seems to me to be the most
sane way it could have been handled.  I suppose it's possible the 2nd
CPU could have been instead paused, while the first CPU processed the
segmentation violation, trashed its non-recoverable machine state,
handled the exception, and ?somehow? reloaded machine state from the
2nd paused CPU.  Switching to a different process while the 2nd CPU was
paused waiting for a page to come in off disk might have been a bit
awkward.  So while I think this might have been made to work, I doubt
it could have performed as well.

So far as the "2 cpu synchronization logic" goes - either of these
would have required such a beast.  The 68000 used "address spaces" to
distinguish between instruction and data references, so instruction
synchronization was no problem.  It might have been necessary to decode
instructions to sort out operands & other instruction stream
references, including logic to sort out page faults in the middle of an
instruction fetch.  Between instruction references there could have
been a variable # of data references - there would have had to be a
memory pipeline capable of caching the maximal number of data
references between instructions -- 6?  10?  You'd also have to handle
memory writes.  If I remember right, the 68000 always did all memory
writes at the end of an instruction, so it *probably* wasn't necessary
to buffer memory writes until after the instruction was complete.  I
believe the logic to do all of this took up a fairly large board in
the masscomp and was *way* more complicated than the entire sun-1 MMU
design.  As I think on this, I don't think the 2nd CPU needs to be
exactly one instruction behind -- it just has to be at *least* one
instruction behind.

Now, if you think Masscomp is strange, wait until you learn about
Morrow System's Micronix.  If I remember right, this was a Z80 on
an S100 board full of MMU logic, including logic to implement kernel
vs. user mode.

					-Marcus Watts