Various wrote:
> Message-ID: <[EMAIL PROTECTED]>
> Date: Wed, 14 Jun 2006 00:50:53 +0200
> From: Johnny Billquist <[EMAIL PROTECTED]>
> 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?= <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], Marcus Watts <[EMAIL PROTECTED]>,
> Otto Moerbeek <[EMAIL PROTECTED]>,
> Ted Mittelstaedt <[EMAIL PROTECTED]>,
> John Nemeth <[EMAIL PROTECTED]>,
> Nikolas Britton <[EMAIL PROTECTED]>,
> Ted Unangst <[EMAIL PROTECTED]>,
> =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= <[EMAIL PROTECTED]>,
> misc@openbsd.org, freebsd-questions@freebsd.org,
> [EMAIL PROTECTED]
> 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? relo