The 68010 is sort of a "fixed" 68000. Restoring state after a page fault doesn't work right in the 68000.
If it had, 68000 machines with MMUs would have worked right, and the history of computing might have been more Motorola and less Intel. (The Lisa and the Apollo Domain did have 68000s with MMUs and horrible kludges to make them work.)
I'm a huge 68000 fan (I am happy it helped make the programmer I am today), but support for virtual memory was hardly the reason IBM selected the 8088 over the 68000 for the PC.
Looking back at the history of 68000 based computers in the 1980s, there were so many missed opportunities. Both Commodore and Apple could have shipped systems with higher clocked 68000s in 1985, but didn't. Commodore didn't ship a real 32 bit system (the Amiga 3000) with the 68030 until 1990, 3 years after the 68030 was released in 1987. Apple at least shipped the IIx in 1988, but it was priced so high as to not be a real option in the home market.
In contrast, anything Intel shipped was brought to market far more quickly thanks to the booming clone market. There was even quite a bit of innovation in external caches for 386 and 486 based systems - I remember reading reviews in Byte magazine in 1987 highlighting the performance differences of the same CPU in a wide variety of systems.
The 68000 series had so many architectural advantages over 8086/8088, but that one choice by IBM for the PC effectively doomed m68k to the dustbin of history. That still makes me sad to this day.
808x also had architectural consistency/continuity with the popular CP/M systems that already existed. 68000 had continuity with nothing.
Motorola had a habit of throwing away architectures when the new thing came out. 6809 was only assembly level compatible with the 6800. 68000 was completely different than the 6809 & 6800. They pushed the 88000 as the new hotness to Apple, NeXT, etc. but it was a total failure and the new hotness became PowerPC. At no point was there backwards compatibility. Apple had to engineer their own solution for 68k -> PowerPC migration, and it was crashy.
Intel just kept plodding along with the x86 instruction set forever, keeping customers in a constant -- if ugly -- upgrade chain, until they made the Motorola mistake with Itanium. They smartly backpedaled from that, though.
68k still had half a chance in the late 80s, early 90s -- not to own the whole market, but to have a crack at a segment of it but Motorola flubbed it. Coldfire is really good, but was too late, inconsistent with their PowerPC strategy, and targeted towards the embedded market.
When the decision was made you had the 8088 and the 68000. 8088 had an 8 bit bus and needed 8 DRAMs. 68000 had a 16 bit buss and needed 16. And memory was about half the cost of a PC. So the 8088 minimum BOM was cheaper.
Second I think the 8088's instruction set was designed to make porting 8080/Z80 assembler easy. I can't say that was important in practice once things were bootstrapped. But might have got them to market faster.
I also think partly the dominant OS in the late 70's was CPM which ran on Intel/Zilog processors. 8088 was of course the manufacturer of the 8080. And my experience with Motorola in the 80's is they weren't exactly eager to sell into smaller markets. Of course now Intel is far worse and has been for the last 35 years.
Not IBM. The Macintosh. The Macintosh came out with a good GUI bolted onto a DOS-type OS. No processes, no threads, no swapping, no paging, no hard drive. The Lisa had all of that, but cost too much. However, it was actually useful. The Mac was a money-losing toy until it got better hardware, especially a hard drive and more memory, in the form of the Macintosh SE. But then Apple was tied to an OS cut down to fit the original 128K floppy-only machine. Which they stayed with far too long.
It was IBM that built the IBM PC that lead to the market for Intel x86 CPUs in clones. The Mac, Amiga, Atari ST, Sun... all of these combined were not enough to support Motorola with the resources needed to keep developing the 68000 series.
Hard agree. 68010's few changes are minimal, but they add up and constitute what 68000 should have been but wasn't.
From the top of my head, besides the writing a proper stack frame for recovering from a bus error you describe, there's the vector base register so that the vectored interrupts and exceptions aren't forcibly defined at 0x0 anymore, an instruction that should have been privileged from the start (move from SR) is now privileged, an alternative that's not privileged (move from cr) is provided for specific cases where that's needed, and a hack to speed up short loops (one instruction + conditional branch) is implemented, saving instruction fetches in these cases and making it slightly faster than the 68000.
Wasn't the kludge in some Apollos that they had two 68000s arranged so they did exactly the same thing, but with one delayed? If the leading one hit a page fault, they would generate an NMI for the trailing one before it too hit the page fault? (I'm sure I heard of someone doing that if it wasn't Apollo).
Even after the 68K family got working page fault handling there was an important different between it and that on Intel processors. The Intel processors used "instruction restart". If the page fault happened somewhere in the middle or at the end of an instruction it discarded any work it had done to that point. After the fault is resolved, the instruction would restart from the beginning.
The 68K family used "instruction continuation". When it got a page fault it would include in the exception stack frame enough internal processor state so that when it returned from the exception processing it could continue from where it left off.
Continuation is presumably more efficient than restart because you aren't discarding any work--although with continuation you have to write a bigger stack frame (and later read a bigger stack frame) because of that internal state as opposed to restart which can use the same small stack frame that ordinary interrupts and exceptions use so I'm not sure that you actually come out ahead with continuation. We aren't talking a VAX here with instructions like "evaluate polynomial" that might do a lot of work before faulting.
We had a hard t track down problem with instruction continuation. I was working at a small 68K workstation company (Callan Data Systems) which ran a swapping version of Unix. I was hacking out the process and memory handling to replace with demand paged virtual memory code, and it was going quite well--except that occasionally when I would ^C a process the damn thing would hang hard.
What was happening was that sometimes a process would page fault, the kernel would handle it, and while that was going on the kernel would let some other user process run. By the time it finished getting the faulted page, and it was time to resume the first process (the one that had page faulted) I had hit ^C on that process and so there was a SIGINT to deliver.
The way it delivered signals to user process signal handlers was by diddling the user stack frame so that it looked like the user process itself had called the signal handler just before whatever interrupt or exception had caused the process to enter kernel mode. Then when the kernel returns to user space, it returns to the signal handler.
That turned out to not be a good thing if the exception stack frame was a continuation stack frame. The processor was very much not happy to try to continue an instruction that was not the instruction whose internal state was in the stack frame.
The fix: when the kernel has a signal to deliver, first check if the stack frame is a page fault frame. If it is, instead of delivering the signal right away set the trace flag and return to user mode. That returns to the interrupted instruction, continues it, and when it finishes generates a trace interrupt, which has a normal stack frame. The trace interrupt handler can then clear the trace flag, and just go ahead and do the normal return to user mode processing which will have no trouble delivering the signal now that we are only dealing with a normal stack frame.
Wasn't the kludge in some Apollos that they had two 68000s arranged so they did exactly the same thing, but with one delayed? If the leading one hit a page fault, they would generate an NMI for the trailing one before it too hit the page fault?
Wow, that's the kludgiest kludge and the stupidest clever thing I've ever heard. Wikipedia agrees with you so it seems you remember correctly.
"This system used two 68000 processors and implemented virtual memory (which the 68000 wasn't theoretically capable of) by stopping one processor when there was a page fault and having the other processor handle the fault, then release the primary processor when the page fault was handled."
The Lisa had an even worse kludge. The instruction continuation was broken for instructions which incremented registers in addition to doing a memory reference. The solution was to have the compiler not generate instructions with index register incrementation. Slower, of course.
When Motorola finally did come out with a MMU for the 68010, the 68541, it was terrible.[1] It was a segmented MMU. Sort of like the 80286, but worse. And on a 32-bit machine, which didn't need that approach just to address memory. The 68030, with an on-chip MMU, finally got it right. But that didn't come out until 1987. The Macintosh SE/30, which used it, came out in 1989. By then, the IBM PC was too far ahead.
If it had, 68000 machines with MMUs would have worked right, and the history of computing might have been more Motorola and less Intel. (The Lisa and the Apollo Domain did have 68000s with MMUs and horrible kludges to make them work.)