out-of-mainstream minis

Jon jlo at ludd.ltu.se
Sat Jul 4 12:45:12 CDT 2015


On Sat, Jul 4, 2015 at 6:42 PM, Diane Bruce <db at 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              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.

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


More information about the cctalk mailing list