Supporting 64-bit ARM systems

They implemented ia32 emulation, but so slowly that they'd have been better off not doing so and requiring software emulation with a few helper instructions from the outset.

Because of the big-end-of-town focus, most of the commercial software for Itanium only came in special price-gouging editions, further inflating its already uncompetitive costs.

More importantly, they were really expensive parts to make and were based on a completely new very long instruction word design that turned out not to perform half as well in reality as it did in theory. It also relied on compilers to do a huge amount of work, but the compilers just weren't ready for it. They had huge caches (esp. for the time), low yields, and insanely expensive packaging with complex daughterboards. There was no such thing as a low-cost, entry-level Itanium system; the whole thing was a push-it-down-from-the-top big iron and big clusters concept.

'cos, y'know, that's exactly how ia32 came to dominance over SPARC, PPC, Alpha, etc, right?

It sounds like ARM64 is closer to "pure" x86_64 than Itanium/IA64; it's a major cleanup and extension of ARM32, but recognisably related.

I doubt ARM will screw this up, not least because they will've learned from the Itanium fiasco. They're sure to have low cost entry-level parts available directly or via licensees from the beginning. They'll be be focused on keeping costs low, yields high, and porting relatively easy. I'd be surprised if some of the changes in ARM64 weren't to get rid of hard- or expensive- to implement instructions and other simplifications for easier manufacturing.

ARM also have another advantage: there isn't much of a legacy base of binary software that people expect to be portable to new arches. It's the norm to have to rebuild binaries for different ARM sub-arches. They don't have Intel's problem of people expecting to be able to run their 1981 copy of QBase on their new Itanium server.