> if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans,
I don't think there was ever any serious thought about replacing x86 with i960 (at least nothing publicly). There was a serious plan to replace x86 with the iAPX 432, which is the predecessor to the i960, but those plans all predated x86 becoming a run-away success when the IBM PC became an industry standard. And "replace" is kind of over stating it, there was no plan for any compatibility, not even source compatibility. It's more that they were planning for iAPX 432 to take the "workstation CPU" spot on their product chart that was currently occupied by the 8086.
By the time the i960 was in development, x86 was so entrenched that I really doubt there could have been any serious thoughts of replacing x86 with something that wasn't fully backwards compatible.
And we know that when Intel did try to replace x86 with Itanium, they went with a hardware backwards compatibility mode.
> I was actually commenting on the need to support aspect being a myth.
Yes, you have a point that it should have been possible to replace x86 with a software emulation approach.
But the only person who can really do that is the platform owner. Apple were quite successful with their 68k to PowerPC transition. And the PowerPC to x86 transition. And the x86 to Aarch64 transition. But that transition really needs to be done by the platform owner.
But the PC didn't really have an owner. IBM had lost control of it. You could argue that Microsoft had control, but they didn't have enough control (especially with DOS. Most DOS programs were bypassing DOS to some extent or another and directly accessed hardware). Intel certainly didn't have enough control to transition to another arch.
(The PC had such high demands for backwards compatibility that even the Pentium Pro ran into issue. It worked, but it simply wasn't fast enough when executing instructions with 16-bit operands. Attempting to run DOS or win95 apps would be slower than a 486. So the Pentium Pro was limited to the market of Windows NT workstations running Apps with full 32-bit code. Intel had to fix this with the Pentium II before they could sell the P6 arch outside of the workstation market.)
Intel didn't even have control over x86 itself. Other companies were already making competing CPU designs that were faster than Intel's own. If Intel didn't keep releasing faster x86 designs, then someone else would steal all of their market share. Intel were more or less forced to keep releasing faster native x86 designs, or they would lose what little control they did have.
I can't readily find the original reference where I read it, but one source[0] does allude that it was a real possibility:
«At the time, the 386 team felt that they were treated as the "stepchild" while the P7 [80960] project was the focus of Intel's attention. This would change as the sales of x86-based personal computers climbed and money poured into Intel. The 386 team would soon transform from stepchild to king».
And, yes, the histories of iAPX 432 and 80960 are so closely intertwined, that in many ways the 960 can be considered a design successor of the 432.
> But the only person who can really do that is the platform owner. Apple were quite successful with their 68k to PowerPC transition. And the PowerPC to x86 transition. And the x86 to Aarch64 transition. But that transition really needs to be done by the platform owner.
I wholeheartedly and vehemently agree with you on this – full platform ownership and the control of the entire vertical is key to being able to successfully execute an ISA transition. Another success story is, of course, IBM with iSeries (nèe AS/400) and zSeries (nèe 360/370/390), albeit their approach is rather different.
> but one source[0] does allude that it was a real possibility
That doesn't really suggest an intention to replace. To me that seems more of a hope that x86 would fade into irrelevance on its own, beaten down by superior RISC ISAs.
--------------
It is interesting to consider what a transition away from x86 would have looked like.
I think the best chance would have been something lead by Microsoft in the early 90s. The 386 version of Windows 3.0 was already virtualising both DOS and Win16 code into their own isolated VMs. If you added a translation layer for 16-bit x86 code to those VMs, then you could probably port windows to any host CPU arch.
I think we are talking about a world where 486 class CPUs never arrived, or they preformed horribly and the pentium was canceled.
But it's a small window. In 1990, it was very rare to see 32bit x86 code. 32-bit DOS extenders were only just starting to be a thing. Windows didn't support 32-bit userspace until 1993. The main 32-bit code anyone was running in 1990 was the windows 3.0 kernel itself. By 1992, it was common for DOS games to use DOS Extenders, and the transition would have required a 32-bit x86 translation layer too.
These RISC PC compatibles would lost the ability to boot directly into real-mode DOS, but would have run DOS just fine inside a windows DOS VM.
It should have been possible to get good hardware compatibility too. Windows 3.0 can already run DOS drivers inside a DOS VM, adding cpu translation shouldn't have caused issues. With motherboard support, it should have been possible to support most existing ISA/EISA/VLB cards.
I don't think there was ever any serious thought about replacing x86 with i960 (at least nothing publicly). There was a serious plan to replace x86 with the iAPX 432, which is the predecessor to the i960, but those plans all predated x86 becoming a run-away success when the IBM PC became an industry standard. And "replace" is kind of over stating it, there was no plan for any compatibility, not even source compatibility. It's more that they were planning for iAPX 432 to take the "workstation CPU" spot on their product chart that was currently occupied by the 8086.
By the time the i960 was in development, x86 was so entrenched that I really doubt there could have been any serious thoughts of replacing x86 with something that wasn't fully backwards compatible.
And we know that when Intel did try to replace x86 with Itanium, they went with a hardware backwards compatibility mode.
> I was actually commenting on the need to support aspect being a myth.
Yes, you have a point that it should have been possible to replace x86 with a software emulation approach.
But the only person who can really do that is the platform owner. Apple were quite successful with their 68k to PowerPC transition. And the PowerPC to x86 transition. And the x86 to Aarch64 transition. But that transition really needs to be done by the platform owner.
But the PC didn't really have an owner. IBM had lost control of it. You could argue that Microsoft had control, but they didn't have enough control (especially with DOS. Most DOS programs were bypassing DOS to some extent or another and directly accessed hardware). Intel certainly didn't have enough control to transition to another arch.
(The PC had such high demands for backwards compatibility that even the Pentium Pro ran into issue. It worked, but it simply wasn't fast enough when executing instructions with 16-bit operands. Attempting to run DOS or win95 apps would be slower than a 486. So the Pentium Pro was limited to the market of Windows NT workstations running Apps with full 32-bit code. Intel had to fix this with the Pentium II before they could sell the P6 arch outside of the workstation market.)
Intel didn't even have control over x86 itself. Other companies were already making competing CPU designs that were faster than Intel's own. If Intel didn't keep releasing faster x86 designs, then someone else would steal all of their market share. Intel were more or less forced to keep releasing faster native x86 designs, or they would lose what little control they did have.