db at db.net
Sat Jul 4 11:42:13 CDT 2015
On Sat, Jul 04, 2015 at 12:33:05PM -0400, 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.
> /~\ The ASCII Mouse
> \ / Ribbon Campaign
> X Against HTML mouse at rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Both Apollo and SUN did this. The clocks were two phase so one ran
behind the other. It was a hack.
- db at FreeBSD.org db at db.net http://www.db.net/~db
More information about the cctalk