Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site spectrix.UUCP Path: utzoo!mnetor!spectrix!clewis From: clewis@spectrix.UUCP (Chris Lewis) Newsgroups: net.micro.atari16,net.micro.amiga,net.micro.68k Subject: Re: 68000 Memory Managment Message-ID: <122@spectrix.UUCP> Date: Thu, 21-Aug-86 17:08:12 EDT Article-I.D.: spectrix.122 Posted: Thu Aug 21 17:08:12 1986 Date-Received: Thu, 21-Aug-86 17:53:06 EDT References: <508@elmgate.UUCP> <767@ark.UUCP> <162@puff.UUCP> <753@oakhill.UUCP> Reply-To: clewis@.UUCP (Chris Lewis) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 66 Keywords: 68k mmu Xref: mnetor net.micro.atari16:1668 net.micro.amiga:4349 net.micro.68k:1149 In article <753@oakhill.UUCP> tomj@oakhill.UUCP (Tom Johnson) writes: >In article <162@puff.UUCP> scott@puff.UUCP (Scott Aschenbach) writes: >>In article <767@ark.UUCP>, gijs@ark.UUCP (Gijs Mos) writes: >>> In article <508@elmgate.UUCP> jdg@elmgate.UUCP writes: >>> ... >>> >If memory serves me correct the 68000 can not restart/resume a bus faulted >>> >instruction... >>... >>I though I heard of someone using pairs of 68000's before the 68010s >>came out. One was set to run just a bit ahead of the other, so that >>the first faulted, and the second was in the state the first one should >>be in when it was restarted. > >Close. Actually, one of the processors is set-up as the "run" processor, >and the other as the "fault" processor. The run processor executes all >normal program instructions, and has its bus cycles terminated with a >DTACK*. If a bus cycle faults, the BERR* signal goes only to the fault >processor. It then issues a "relinquish and retry" (BERR*, HALT*, BR*) to >the run processor which immediately terminates the "faulted" bus cycle, >saves the access address internally for later use, and issues a BG*. The >fault processor, upon receipt of the BG*, issues BGACK*, and releases BERR* >and HALT*. Then, with the aid of a little external glue (address latches, >etc), the fault processor fixes the memory image at the faulted address, and >releases the BGACK* line. The run processor will rerun the faulted cycle >using the same address, data, control signals, etc. As I remember the paper (though it may very well mean the same thing - I'm not an expert on 68k pins - this may be more understandable tho) - when the "run" processor attempts to perform a memory access that will fault, it is HALTED in the midst of the access instead of bus error'd. Then the "fault" processor wakes up, examines the state of the various control signals, and stuffs the proper page "underneath" where the "run" processor is accessing. Then the fault processor turns off HALT to the run processor, and goes back to sleep. The run processor then merely finishes the access (possibly a longggggg time later). The cycle wasn't interrupted at all. >Actually, with this method, even a very complex management scheme can be >designed. And, with the price (1000 pc qtys) of 8 MHz 68K's being about >1/4 that of 68451 MMU's, the price *disadvantage* of using a fault processor >is almost non-existant. (remember that all mapping circuitry will have >to be added). Also, assuming the mapping can be made sufficiently fast, this >method has some neat advantages. As I remember it there are two major disadvantages: 1) the circuitry is likely to use up an awful lot of board real-estate. And if you don't think that's a problem, take a look at a MVME117 or 131 or one of our CPU boards one day.... (talk about stuffed!) 2) During page fault handling, the run processor is hung. That means, for instance, while the fault processor is spending it's 50 some-odd milliseconds trying to read a page in, the run processor is missing all interrupts, unable to task switch, unable to do *anything*... In a paging system, being able to run another task while a page fault is being handled is essential for any reasonable level of performance. If you ever started to thrash, the run processor would hardly ever run. It was a neat idea, and a few machines were built, but I don't think that the result was very useful when compared to a machine with a "real" MMU (that is, *not* a '451). -- Chris Lewis UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis Phone: (416)-474-1955