3 ms·

I think AMD killed Itanium. I think Intel’s plan was to leave x86 forever stuck at 32- bit and have Itanium be the natural upgrade path as computers started run

I think AMD killed Itanium. I think Intel’s plan was to leave x86 forever stuck at 32- bit and have Itanium be the natural upgrade path as computers started running into the 4 GB limitations. I think it would have been a nice transition story. 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.

stuartd 6y ago
If anyone's interested, Raymond Chen did a series of posts on the idiosyncranies of the Itanium processor, starting here: [0] [0] https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90821 https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90...
- thesz 6y ago
  I read it and found that write to R0 (zero read register) triggered CPU fault. 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.
pjmlp 6y ago
That is also what I believe, had AMD not been allowed to produce x86 clones after their legal dispute, and we would eventually all be using Itanium nowadays.
vardump 6y ago
"...as computers started running into the 4 GB limitations..." You mean 64 GB limitations? 32-bit x86 could handle that much, and I'm sure it would have without AMD64.
- saagarjha 6y ago
  Didn’t that require PAE and all sorts of workarounds, all for a not-that-great experience?
  - vardump 6y ago
    No workarounds required if it's enough just to have a lot of up to 3 GB processes (arbitrary, upper 1 GB was typically reserved for the kernel and memory mapped peripherals/IO, like GPU, USB, SATA). Of course if a single process wanted to access more, that would have required remapping or multi-process approach. Or special hacks like Windows AWE [0]. 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 https://en.wikipedia.org/wiki/Address_Windowing_Extensions
- _ph_ 6y ago
  There is still the 4GB/process limit, even if with these extensions the total amount of memory in the computer could be larger.

stuartd 6y ago

If anyone's interested, Raymond Chen did a series of posts on the idiosyncranies of the Itanium processor, starting here: [0] [0] https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90821 https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90...

thesz 6y ago
I read it and found that write to R0 (zero read register) triggered CPU fault. 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.

pjmlp 6y ago

That is also what I believe, had AMD not been allowed to produce x86 clones after their legal dispute, and we would eventually all be using Itanium nowadays.

vardump 6y ago

"...as computers started running into the 4 GB limitations..." You mean 64 GB limitations? 32-bit x86 could handle that much, and I'm sure it would have without AMD64.

saagarjha 6y ago
Didn’t that require PAE and all sorts of workarounds, all for a not-that-great experience?
- vardump 6y ago
  No workarounds required if it's enough just to have a lot of up to 3 GB processes (arbitrary, upper 1 GB was typically reserved for the kernel and memory mapped peripherals/IO, like GPU, USB, SATA). Of course if a single process wanted to access more, that would have required remapping or multi-process approach. Or special hacks like Windows AWE [0]. 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 https://en.wikipedia.org/wiki/Address_Windowing_Extensions
_ph_ 6y ago
There is still the 4GB/process limit, even if with these extensions the total amount of memory in the computer could be larger.