3 ms·
Some of the early 68k workstations, including the original Sun and Apollo hardware simulated an MMU by using an extra 68k. IIRC, in the event of a trap, the sec
by ch_123 5y ago
Some of the early 68k workstations, including the original Sun and Apollo hardware simulated an MMU by using an extra 68k. IIRC, in the event of a trap, the second CPU would kick in, set up some mappings, and then hand control back to the main CPU.
- retrac 5y agoThose workstations still had custom MMUs, and the 68K had most of the signals to work with an MMU. The issue was instruction recovery on exception, particularly page fault. With an instruction like move (a2)+, (a3) the processor first loads the value from memory at the address in a2, increments a2, then goes to store it at the address in a3. If a3 holds an invalid address, the processor faults halfway through the instruction. The problem is the 68000 doesn't store enough state anywhere to tell you how to rollback and attempt the whole instruction again. (Was a2 incremented already or not?) The dual 68K approach would keep the whole instruction pending on the other processor, in case it needed to be restarted, after resolving the page fault. And it was still possible to implement classic base-and-bounds swapping with a single 68K.
- rjsw 5y agoSome C compilers for the 68000 added an instruction to do a dummy read before doing any stack operations to trigger a fault in a way that it didn't matter to the instructions doing real work.
- zozbot234 5y agoThis is still done today to guard against stack overflows, in combination with unmapped "guard" pages.