Nah. Intel tried several times to quit the x86. They couldn't because the market rejected anything that wasn't backwards compatible.

The market rejected it for desktops and servers. But not in other markets. Which is why Intel is still selling in the hundreds of millions of CPUs, while ARM licensees are selling in the billions, and MIPS and PPC licensees are also selling in the hundreds of millions (but reap far less revenue than Intel, as more of are low price units going into embedded systems).

I have a feeling that the market rejected it because rewriting a ton of software didn't make sense for a negligible performance "upgrade", not because it wasn't backwards compatible. There were also emulators available to run x86 code.

> When first released in 2001, Itanium's performance was disappointing compared to better-established RISC and CISC processors. - Wikipedia

I think the backwards compatibility problem wasn't that it lacked backwards compatibility, but rather that the proposition was to pay more to run your existing binaries slower. I recall Pentium Pro having a similar problem with 16-bit code.

well, did they try it for the mobile or the HPC market?

You mean with XScale and Itanium? Yes they tried.

From what I've read, it seems that the Itanium was Intel's attempt to get away from x86 but it didn't work out as they had hoped. It seems to me that it is market-forces that have kept x86 as the incumbent instruction set.

People keep bringing this up when talking about Intel's botched mobile strategy, but IMO it just doesn't apply. Itanium was marketed based on features for servers that frankly weren't really popular. People always wanted one of the following things:

* performance per dollar

* performance per watt

* highest single threaded performance

* lowest possible power draw

Itanium AFAIK improved neither of these, or it did so only for very narrow usecases. What Intel needed was either (a) an ARM competitor and/or (b) a processor with large vectors and a SIMT-like parallelisation model (i.e. a Tesla competitor). In both of these cases they didn't think twice before just throwing x86 at the problem until the pain goes away... which it never did.

Just because the Itanium was a failure doesn't change the fact that Intel have tried several times to get away from x86. So it's unfair to claim that Intel have relied purely on x86 in order to shut out competition. Of course, they're not going to quit x86 until another instruction set has been proven more popular to the market and they have made attempts to create that instruction set.

Agreed, some people just don't realize how many arches were tried at Intel, i432, i860, i960 etc...

Still missing the point. Which non-x86 architectures targeted at low power or HPC - if you count computer graphics as a subset the main growth markets - were tried in the last 15 years?

Why trying to win people over on compatibility if they have to rewrite their software anyways for other reasons, especially after ARM took the largest market share in mobile?

I think you look at it the other way round -- it is not so much Intel who wanted to win customers over compatibility, but rather the customers who had to port their software, and suddenly saw a possibility to not do that.

It took a while to Intel to accept that the mobile-app providers won't invest the same effort in porting their apps from ARM to x86 given the market penetration, but I don't believe it was a suprising outcome to them.

Is the x86 architecture itself limited in its adaptability compared to others such as ARM? If yes, why and if no, why are Intel's mobile/low-power attempts failing?

The way I understand it, x86 does quite a lot in hardware what could be done in Software (compiler) just as well. That includes backwards compatibility to a whole host of instruction sets / extensions. All this seems closely linked to the IBM PC standard and Microsofts software strategy. All of this costs power. The result is that you can either have a mobile x86 that's competitive on power or on performance, but not both.

Hmm, I don't believe that's true. The power budget of the backwards compatibility is very small.

Intel's problem is a case of optimization I think - their design teams have been optimizing towards producing a processor with an effective power budget of whatever the cooler could dissipate, rather than optimizing for low power, and that's a very different task.

There's no one processor that will fit all workloads.

I think compatibility to IBM PC has lots of hidden costs. One is that it seems to make Intel much less nimble at producing SoCs with features that are specific for each usecase. It's not just the ISA, it's basically the whole ecosystem around PC that's not well adapted. That's why we don't have Dell, HP and Intel phones and hardly any Microsoft ones today. x86 may not be the only reason, but from what I can see it's at least one of the major ones.