4 ms·

I think the product was mis-conceived from the start. The approach was that 64-bit should only be for workstation and servers, and not at all about how customer

I think the product was mis-conceived from the start. The approach was that 64-bit should only be for workstation and servers, and not at all about how customers would benefit. Only about how much more they would pay for the extra memory, and it placed all of the burden on the customer and software vendors, e.g. the impractical path of working around no binary compatibility in silicon.

mlyle 3y ago
64 bits for workstations and servers as near to intermediate term targets for Itanium made a lot of sense. It was basically a decade before any real consumer adoption of 64 bit began. The big problem was that AMD's 64 bit architecture did backwards compatibility a whole lot better than Itanium. > e.g. the impractical path of working around no binary compatibility in silicon. Early Itanium SKUs could run IA32 instructions. This was dropped after dynamic binary translation in software performed better.
- simtel20 3y ago
  But no shared libraries due to this. Iirc the silicon ia32 compat was gone by the time early systems were being built, so it's not like they really tried to provide a workable upgrade path, more like they shield away from the hard work and bet that ia32 would disappear
  - mlyle 3y ago
    > Iirc the silicon ia32 compat was gone by the time early systems were being built, Itanium first shipped in 2002 with silicon for the purpose-- it just was not very good. The software compat layer showed up in late 2004 with Madison, and was far superior in every way to the ia32e silicon in earlier processors-- it had near-parity with Xeons for a couple of generations. But-- why pay tons more for near-parity with a cheaper processor? > But no shared libraries due to this. Using shared libraries from a different ISA is hard; x86-64 OSes didn't try to do this, nor did Apple's Rosetta in 2006 or Rosetta 2 in 202. Generally (not always) your user space program is made entirely of code for one architecture. It's hard to deal with different pointer widths, calling conventions, etc.

mlyle 3y ago

64 bits for workstations and servers as near to intermediate term targets for Itanium made a lot of sense. It was basically a decade before any real consumer adoption of 64 bit began. The big problem was that AMD's 64 bit architecture did backwards compatibility a whole lot better than Itanium. > e.g. the impractical path of working around no binary compatibility in silicon. Early Itanium SKUs could run IA32 instructions. This was dropped after dynamic binary translation in software performed better.

simtel20 3y ago
But no shared libraries due to this. Iirc the silicon ia32 compat was gone by the time early systems were being built, so it's not like they really tried to provide a workable upgrade path, more like they shield away from the hard work and bet that ia32 would disappear
- mlyle 3y ago
  > Iirc the silicon ia32 compat was gone by the time early systems were being built, Itanium first shipped in 2002 with silicon for the purpose-- it just was not very good. The software compat layer showed up in late 2004 with Madison, and was far superior in every way to the ia32e silicon in earlier processors-- it had near-parity with Xeons for a couple of generations. But-- why pay tons more for near-parity with a cheaper processor? > But no shared libraries due to this. Using shared libraries from a different ISA is hard; x86-64 OSes didn't try to do this, nor did Apple's Rosetta in 2006 or Rosetta 2 in 202. Generally (not always) your user space program is made entirely of code for one architecture. It's hard to deal with different pointer widths, calling conventions, etc.