But to have any chance in the marketplace, the new "iRISC64" architecture would have to actually ship working chips, with decent price/performance ratios, in a timely manner. The #1 reason for Itanium failing was Intel's disastrous inability to do that - https://en.wikipedia.org/wiki/Itanium#Design_and_delays:_199...
Meanwhile, actual x86 chips were shipping - in volume, with fast-improving price/performances ratios. And industry insiders, who were familiar with Intel's long history of great-sounding, non-x86 architectures - which turned out to be crap for ~99% of use cases - were quietly filing "Itanium" into the "another one of those" pigeonhole.
And that even with compiler support, it didn't manage to give Itanium systems a (big enough) edge over other systems?
Combined with product delays & other issues.
What makes more sense to me is Intel's proposal to drop some 16/32 bit legacy cruft from x86-64 ("x86-S"). Perhaps even drop user-mode 32 bit support? (depending on how much it simplifies implementations, and/or improves performance/W).
Haven't heard about this recently. But maybe it's up for introduction later on?
This would keep support for existing software (mostly) intact. But still cut out a nice chunk of x86 ugliness.
Had Intel said something like Apple has each time they have made a CPU change (68k to PPC to x86 to ARM): "here is the new thing; we will support a fat binary model for a 'while'; move to the new thing", Itanium (which, from a technical viewpoint should have blown the ever-loving PANTS off x86) would have [probably] 'won'
Or we would have an even-more splintered CPU space - x86-64 from AMD, ARM, POWER, Itanium, etc
But they did not
They release the Itanic as a side-by-side with their existing CPU lines, which encouraged AMD to develop AMD64, and more-or-less forever broke Intel's utter dominance of the desktop and server space