out-of-mainstream minis

Johnny Billquist bqt at update.uu.se
Sat Jul 4 18:26:11 CDT 2015


On 2015-07-04 18:33, Mouse wrote:
>> The problems revolve around the fact that instructions cannot be
>> properly restarted on the 68000.  Not enough context is saved.
>> [...]
>> (The tricks done by those who did fix this consists of having a
>> second processor which gets interrupted when you get a page fault,
>> and the second processor do all the work related to the page fault,
>> while the primary processor just stalls until the memory is
>> available, at which point it can continue. There is no limits to how
>> long the CPU can wait for memory to return data on a read.)
>
> I recall hearing of a company that build a machine with two 68000s, one
> running one instruction behind the other.  When the leading processor
> got a page fault, hardware interrupted the lagging processor (which had
> not yet encountered the faulting instruction) and there's a dance where
> the two processors switch roles, allowing useful page faults.
>
> Perhaps such a thing existed.  Perhaps my informant was misled - it
> sounds like a plausible corruption of what you describe.  Perhaps my
> own memory has bitrotted.  But it sounds to me as though it certainly
> _could_ work.

I've heard that one too, but I have never found any reliable information 
about such a system, so I suspect it might just be a corruption of the 
design with a second CPU taking handling page faults and stalling the 
primary processor.

The problem with having a second CPU shadowing the first one are plenty. 
First of all, not all instructions are the same number of cycles, making 
it really hard to actually stay one instruction behind. Second, since 
many operations depends on content in memory, this would require the 
second CPU to see the same memory content as the first CPU, which means 
any changes done by the first CPU in the last instruction must not be 
allowed to be visible to the second CPU. Third, any modifications of 
memory by the second CPU must actually not happen, or else you might 
modify memory in ways not intended. However, as soon as you hit an error 
in the primary CPU, from which it cannot recover, the secondary CPU 
suddenly must be allowed to actually change state and modify memory, and 
any relationship to the primary CPU cease. I honestly cannot see how you 
would actually implement this.

Having the primary CPU just stall, and have the second CPU normally just 
be idle until a page fault happens on the other hand is something I can 
see how it could be done.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


More information about the cctalk mailing list