However, when AMD released AMD64 it killed this strategy. You could now buy a chip that natively ran x86 32 bit at full speed, plus be able to run code that could address more than 4 GB of RAM.
Once AMD64 came out, Itanium was a dead architecture.
[0] https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90...
This means that there is some hardware that checks condition that will not happen during normal course of events - compiler won't generate such code and write to register that reads zero is harmless.
That hardware stays there, occupies space (does not matter how little) and drains energy (no matter how little).
This part of hardware is utterly meaningless and shows how priorities were skewed during design phase. It also shows why Itanium was such a bad chip - features were piled up instead of being cut down.
RISC-V did cut down on features first (compare division overflow in RISC-V and OpenRISC) and has a process to add them. This is why RISC-V is easy to implement even in OoO variant and why it is being picked up by everyone and their dog.
You mean 64 GB limitations? 32-bit x86 could handle that much, and I'm sure it would have without AMD64.
All in all, not ideal, but I'm sure we would have managed with it a bit longer.
[0]: https://en.wikipedia.org/wiki/Address_Windowing_Extensions
The downfall of the Itanium had several reasons. They went beyond RISC with EPIC, a technology which had great theoretical promises, but had not been shown to yield those results in practise. Also, the project suffered from bad management and delays. Finally AMD pushed x86 just far enough forward to be a viable alternative.
In the beginning, the Itanium was an expensive, power-hungry monster, but it did perform quite well for heavy computations. It could have had a much better future, if Intel had not abandoned it - the software situation could have been much better, if for example Linux boards had been made available to all interested. The latest version only made it to a 32nm process, the transistor count being smaller than in a modern iPhone. So just redoing the same design in a cutting-edge process would make for a very interesting processor.
Intel misjudged both sides, for phones x86 compatibility was never necessary, for business machines, it absolutely is (for the largest number of customers, there have been exceptions).
HP saw the disaster coming and designed their own McKinley Itanium, but a bit later, and HP obviously didn't want Dell to have it.
The compiler support was not good outside HP-UX, if I remember correctly.
And then AMD64 happened, and Microsoft told Intel that there would be no further 64-bit PC instruction sets, and the market would choose between AMD and Itanium.
Cue the guillotine.
Non trivial amount of know-how and - if rumours to be belied[1] - direct design then went from Alpha team at Compaq to AMD, though Intel retained some of it (AMD already had been doing cooperation with Alpha, leading to the funky case of "jig it enough and an Athlon-MP motherboard might just run an Alpha and Athlon at the same time").
[1] - Once heard from semi-reputable source that an early K8 changelog entry contained "dropping support for VAX floating point formats". Unverifiable unless someone somehow publishes those docs, but it did fit with "That opteron looks suspiciously similar to EV7"
it sounds interesting
Intel should have known this, but you buy processors because they are faster or cheaper. These days the third rail is energy but it’s basically the same, if you pay more you want a lot more and “Different” costs. Itaniums where a whisker faster than their ia32 offerings at the time, they cost a lot more though, and they were different. Beyond that, it was like a geek designed the specs with out a market story, risc chips were coveted by x86 dorks because they had 32 registers to the x86’s 5 or 6, well ia64 had 128... If you’re just doing simple stack frame compiler work without full program optimization, how many functions need 32 registers? Let alone 128? everyone could see that you wanted to simplify things in order to put silicon where it mattered for longer term performance, mid to late 90s reordering conditionals for branch prediction was sort of hot in compiler dork and low level circles, well Merced fixed that by adding a lot of complex logic to take both branches and retire the wrong one. IBM, HP and Sun needed different reliability and serviceability features on their high end systems too, from the big enterprise metal perspective they were toy parts for PCs, but they cost more, didn’t run your existing software and weren’t 2x faster or anything like that. They didn’t take a holistic market view as they made it. Rather than work with ibm, sun and hp on those high end issues, they just went back to the lab and told them when the first parts would be out.
Not really sure what goes on inside intel, they have a lot of brilliant people. I suspect that they cannibalize themselves because nothing will ever be as successful as the x86 was when they owned every aspect of the part and package and things are decided to be a failure before they ship. With ia64 nobody asked why. Xeon phi, they gpu and machine learning stuff reflects that too.
As I understand it, these were influenced by SuperH, a 32-bit RISC design that uses 16-bit instructions, so two are always executing at once.
The busybox-armv7m Thumb2 binary is the smallest of all the compiled architectures.
Thumb2 appears to have been much more practical.
Itanium launched in 2001 (per Wikipedia); if anything, I'd say they overestimated how readily they could ditch x86. Of course, it might be that replacing x86 was a good idea and it was just that Itanium sucked (I'd accept that possibility, given the whole "needs a smarter compiler than exists" thing). But I do agree with the general feeling that Intel and MS both overestimated how solid/entrenched they were.