From owner-freebsd-questions@FreeBSD.ORG Wed Jun 14 00:02:29 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440B616A41A for ; Wed, 14 Jun 2006 00:02:29 +0000 (UTC) (envelope-from mdw@umich.edu) Received: from quince.ifs.umich.edu (quince.ifs.umich.edu [141.213.229.138]) by mx1.FreeBSD.org (Postfix) with SMTP id A31BC43D49 for ; Wed, 14 Jun 2006 00:02:28 +0000 (GMT) (envelope-from mdw@umich.edu) Received: from sisyphus.ifs.umich.edu (sisyphus.ifs.umich.edu [141.211.14.215]) by quince.ifs.umich.edu (8.6.13/8.6.12) with ESMTP id UAA15593; Tue, 13 Jun 2006 20:01:42 -0400 Message-Id: <200606140001.UAA15593@quince.ifs.umich.edu> To: Johnny Billquist In-reply-to: Your message of "Wed, 14 Jun 2006 00:50:53 +0200." <448F414D.7090302@update.uu.se> Date: Tue, 13 Jun 2006 20:01:42 -0400 From: Marcus Watts X-Mailman-Approved-At: Wed, 14 Jun 2006 00:24:52 +0000 Cc: John Nemeth , misc@openbsd.org, Otto Moerbeek , Ted Unangst , Ted Mittelstaedt , Marcus Watts , =?ISO-8859-1?Q?Per_Fogelstr=F6m?= , =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= , rmk@rmkhome.com, netbsd-users@netbsd.org, freebsd-questions@freebsd.org, Nikolas Britton Subject: Re: wikipedia article X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 00:02:29 -0000 Various wrote: > Message-ID: <448F414D.7090302@update.uu.se> > Date: Wed, 14 Jun 2006 00:50:53 +0200 > From: Johnny Billquist > 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?= > CC: rmk@rmkhome.com, Marcus Watts , > Otto Moerbeek , > Ted Mittelstaedt , > John Nemeth , > Nikolas Britton , > Ted Unangst , > =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= , > 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