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: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
