Path: utzoo!attcan!uunet!husc6!cs.utexas.edu!oakhill!tomj
From: tomj@oakhill.UUCP (Tom Johnson)
Newsgroups: comp.sys.mac
Subject: Re: When will MacOS get virtual memory?
Summary: NO MICROCODE "BUGS" IN THE 68000
Keywords: 68000 Virtual Memory Microcode Bus Errors
Message-ID: <1529@oakhill.UUCP>
Date: 6 Oct 88 14:42:54 GMT
References: <5624@zodiac.UUCP> <76000293@p.cs.uiuc.edu>
Reply-To: tomj@oakhill.UUCP (Tom Johnson)
Organization: Motorola Inc., Austin Tx.
Lines: 50

In article <76000293@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>
>/* Written  1:11 pm  Oct  4, 1988 by jellinghaus-robe@CS.YALE.EDU */
>>In article <76000290@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>>>The sad thing is, the vast majority of Macintoshes in this world
>>>cannot support virtual memory.  This is because the 68000 chip has a
>>>design flaw that doesn't allow virtual memory to be implemented.
>>
>>Someone really should tell Sun or Apollo.  They've produced many workstations
>>with 68000's running UNIX, which DOES support virtual memory and page 
>>swapping.  Gosh, wonder how they do it?
>
>I believe that a microcode bug leaves the CPU in a corrupt state if
                  ^^^^^^^^^^^^^
>you take a page fault on a certain memory reference by the 68000 CPU.
>... I think this is the main reason why Motorola designed the 68010
>-- to fix this microcode bug.
>
>I once heard that someone implemented VM on the 68000 by using two
>CPU's, one executing a few cycles behind the other...
>
>I wasn't trying to malign the 68000, which I have a lot of respect for.
>
>Don Gillies, Dept. of Computer Science, University of Illinois
>1304 W. Springfield, Urbana, Ill 61801      
>ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies

One and for all...there is NOT  A MICROCODE BUG IN THE 68000. The processor
was not DESIGNED to allow for virtual memory!!!  As far as the two processor
support, you are more or less correct.  Actually, the "2nd" processor (called
the "fault" processor) simply waits for page faults. The bus error line from
memory is tied to its interrupt lines and NOT to the "main" processor's bus
error line.  When a page fault (or any other memory fault for that matter)
occurs, the main processor is in the midst of a bus cycle, awaiting a DTACK
or BUS ERROR (or VPA).  The fault processor, by intercepting Bus Error leaves
the main processor STILL awaiting termination of the bus cycle.  The fault
processor then issues a RELINQUISH and RETRY (by asserting BUS ERROR, HALT,
and BUS REQUEST simultaneously).  This terminates the main processor's bus
cycle, but assures us that 1) the fault processor will get control of the
bus for as long as needed, and 2) the next bus cycle the main processor will
run will be that SAME cycle that was "faulted".  The fault processor fixes
memory and releases BUS REQUEST and waits for another fault.  The main
processor re-runs the EXACT bus cycle that "faulted". QED virtual memory on
a 68000.

|Disclaimer:  The views presented above are my own, and do not necessarily
|             reflect the views of Motorola.
|
| tomj@oakhill.UUCP	Tom Johnson, High End Technical Marketing
|			Motorola, Austin, TX