68060 has a reduced integer and floating point instruction set
( Motorola cut down some of the lesser used instructions in order to keep the die size under control. However, to remedy this they made available an ISP (Integer Support package) and FPSP (Floating point support package))
Bus error stack frames have been changed significantly
“Supervisor mode of the Motorola 68060 CPU differs from the 68040 due to changes in exception processing. User mode of the Motorola 68060 is object-compatible with MC68040, assuming that the CPU uses special software to simulate a few instructions that were present in 68040 CPU and are missing in MC68060.”
Big picture: Motorola's 68K architecture was a case study in Death by Feature Creep.
Short-term: The 68K was loved by assembly language programmers - a big thing, in the 80's. And it felt and sounded so cool for Motorola to add even more great features to each generation of the architecture.
Long-term: If you want your microprocessor architecture to stay a thing in higher-performance desktop/server use (vs. toaster ovens & thermostats & such) - then you need to have a few Senior Implementation Engineers looking a decade or so ahead, and saying "NO" to cool features that could turn into implementation hell.
The 68060 was where the long-term issues really caught up with the 68K architecture, and it hit the brick wall / grave stone. Which is why Motorola pretty much dumped their 68K for IBM's Power architecture, in the PowerPC.
They dropped them only much later, in Coldfire, not in 68030, which was completely compatible with 68020. MC68040 dropped some features, then MC68060 dropped more features, but for user programs they remained binary compatible with MC68020.
They have probably realized quickly that adding memory indirect addressing modes was a mistake, but they could not drop them because that would have broken all programs ported to MC68020.
With Coldfire, they were able to prune the unwanted addressing modes, because Coldfire was intended for embedded computers, where the software is recompiled for every new project and binary compatibility with legacy programs is not necessary.
Both the addressing modes of Intel 80386 (1985) and of Motorola MC68020 (1984) were inspired by the addressing modes of DEC VAX, but in a very rare event in the history of Intel processors the Intel designers have done the right thing by choosing the useful subset of the DEC VAX addressing modes, while the Motorola designers have made a mistake by choosing to implement an even more complex set of addressing modes than that of DEC VAX.
The 68030 really only dropped the Call Module and Return from Module instructions, which nobody used anyway since relatively few developers wanted to write code only for 68020 and higher around the time the 68020 and then 68030 shipped.
x86 is not nearly as bad as 68k, more by lucky accident than design. As it was a stop-gap project designed to hastily extend an earlier design to 16 bit and 20-bit addressing while the proper cpu of the future (iAPX432) needed a few extra months to bake, the designers didn't have enough time to properly fubar the core of the instruction set. This made x86 assembly much less nice to write than the nearly fully orthogonal 68k, but also made it much easier to make the subset of it that was in actual use faster later.
68k designers were not being dumb when they designed it. At that time pretty much the entire industry was deep in the weeds of "closing the semantic gap", or making CPUs directly run the operations that would be encoded in high-level languages. All CPUs designed to this paradigm were doomed, and how doomed they ended up being depended mainly on how well they managed to implement it.
IBM's 801 and Patterson's RISC would blow it all up in the early 80's.
A shame, really. 68k was (and is) much more approachable for those learning assembly. No need to deal with 64k segmented memory, for instance.
As an aside… National Semiconductor also had an ill-fated architecture in the NS32000, which I also wish took off. On paper, it really did a lot right (VAX-like design, flat memory model, 32-bit almost immediately out of the gate) yet NS was woefully incapable of producing masks without bugs. It took them many tries to get it right, and before then, they already were being beat to market by their competition.
Then to add insult to injury, NS’ own compiler for NS32000 chips was producing rather unoptimized code. It took GNU porting GCC to the platform in 1987 for them to fully realize their potential, years after they missed their chance.
If NS did have their act together… dare I say an IBM PC built around their CPU would have been possible and more interesting than the 8088 they ultimately went with.
AFAIK, NS used the Green Hills compiler; at least, my ns32532 dev system comes with it. It's not great, but not terrible. I personally don't remember the compiler being in the top 5 show-stopper issues with the 32k (the first 3 were 'cpu bugs', 'mmu bugs' and 'fpu bugs'). And it was slow, particularly if you used the MMU.
The 32000 line (like the 68000) found a very long life as an embedded processor, particularly in the printer/fax space (ns32cg16 and followons, ns32gx32).
The 32332 was a nice processor. The 32532 was very, very nice. Both way too late.
Given what IBM was trying to deliver with the PC, I doubt they'd have looked at the 32000. Single source, few i/o support chips, relatively expensive, etc., etc. Way more likely that a non-Intel IBM PC would have had a Z8000 inside (and not a 68k, for mostly IBM political reasons).
That said, I’d possibly contest you on the single source issue you brought up. IBM likely would have told NS… much like they told Intel back in the day… that if they wanted to do business with them, that they needed to ensure second sourcing was possible.
Judging by how desperate NS was willing to make deals, I’m quite sure that hurdle would have been overcome quite easily, with AMD or even MOS Technology stepping up to fill the void.
If we want to pick nits, NS had a second source: TI. But that was, afaik, just paperwork at that point (and I honestly don't know if TI ever produced a 32k processor). It takes time to bring a second source on-line. And given the trouble NS had building the chips themselves, if I was IBM, I'd have Questions.
That said...even if NS could wave a magic wand and produce a second source, there were plenty of other reasons to discount the 32k, and I've never seen the slightest evidence that IBM ever considered it.
Dream away. How much weirder a dream would it be if IBM had gone Zilog? Fanbois endlessly arguing the superiority of segmented over paged memory? Terrible marketing from an oil company? Wordstar still the standard? I sorta like that multiverse option.
I’m far from an expert, but it seems pretty common for new CPUs to be compatible with old ones at the application level, but not fully compatible with OSes. It seems like there’s a (reasonable, I’d say) assumption that vendors are willing to update the OS when they ship new hardware. Of course, this makes it hard to upgrade the CPU in a machine that hasn’t been supported for decades.
I’ve got a 68060 RC (MMU, no FPU) in my Amiga 1200 and it seems to work alright. The full 68060 is insanely expensive these days though, you could get a decent Ryzen for a lot less money.
That would be a 68LC060. And the 68EC060 was no MMU, no FPU. The RC just means it's a ceramic PGA package, so an MC68LC060RC50 would be a 68060 with MMU, without FPU, in a ceramic PGA206 package binned to run at 50MHz. If you have a 68060RCxx chip that doesn't have a (functioning) FPU, it's probably a relabled 'fake' LC, which is actually pretty common.
And, yeah, they're unfortunately crazy expensive, esp if you get stuck with one of those fakes.
In your specific case too, I believe there are options for soft emulation of the FPU if you needed support for one in a pinch. I can’t say how the performance is, but I’d imagine it would be insanely slow.
