On Sat, Jul 4, 2015 at 6:42 PM, Diane Bruce <d...@db.net> wrote: > 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 mo...@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.
Sun did not do this. The Sun-1 CPU was indeed a 68000 to which was coupled a custom MMU in discreet logic. It didn't handle demand paging. Sun soon switched to the 68010. -Jon
