4 ms·

ISA certainly isn't the most important factor, but your ISA has to be a good enough baseline. History is littered with ISAs that made bad enough choices that we

ISA certainly isn't the most important factor, but your ISA has to be a good enough baseline. History is littered with ISAs that made bad enough choices that were limiting at the time (VLIW, Itanium) or handicapped future generations couldn't (MIPS delay slots). Arguably x86 and arm are the "RISCiest CISC" and "CISCiest RISC" architectures, and have succeeded due to ISA pragmatism (and having the flexibility to be pragmatic without breaking compatibility) as much as anything else.

ajross 3y ago
Itanium and MIPS were... just fine though. Both architectures have parts that were very competitive along essentially all metrics the market cares about. ia64 failed for compatibility reasons, and because it wasn't "faster enough" than x86_64. No one saw much of a reason to run it, but Intel made them well and they made them fast. And MIPS failed for the same reason ARM pulled ahead: in the late 90's Intel took a huge (really, huge) lead over the rest of the industry in process and MIPS failed along with basically every other CPU architecture of the era Amusingly the reason ARM survived this bottleneck is because it was an "embedded" architecture in a market Intel wasn't targetting. But there's absolutely nothing technical that would prevent us from running very performant MIPS Macs or whatever in the modern world.
- cpgxiii 3y ago
  Itanium failed in the market because it wasn't fast enough running general purpose code (HPC workloads were a different story). As a consequence, it's ability to run existing x86 code was poor (both in hardware and software emulation). At the root, Itanium's poor performance was a direct consequence of the design assumption that a sufficiently smart compiler could extract sufficient instruction-level parallelism. While the ISA didn't prohibit later improvements like OoO execution, it always required a better compiler (and more specific workloads) than real users would have.
  - pjmlp 3y ago
    Itanium failed in the market because AMD was allowed to come up with AMD64, that is all. Had it not been the case, the market would have been driven to Itanium no matter what.
- ghaff 3y ago
  Itanium was never really "just fine." The performance (or complete lack thereof) of x86 compatibility mode was one problem. But VLIW's reliance on software to do the right thing (with compilers etc.) was another big thing even for native IA64 code. And a decent-performing Itanium was delayed enough to arrive during dot-bomb vs. dot-com. If Itanium had really been the only 64-bit chip available for use in systems from multiple vendors maybe it would have succeeded by dint of an Intel monopoly position. But once x86_64 arrived from AMD and Intel ended up following suit, it was pretty much game over for Itanium.
  - ajross 3y ago
    That's kinda revisionist. In fact ia64 owned the FP benchmark space for almost a decade, taking over from Alpha and only falling behind P6 derivatives once those started getting all the high end process slots (itself because Intel was demolishing other manufacturers in the high-margin datacenter market). The point was that ia64 was certainly not an "inferior" ISA, It did just fine by any circuit-design measure you want. Like every other ISA, it failed in the market for reasons other than logic design.
    - ghaff 3y ago
      Itanium had some specific performance strong points. FP was one. Certain types of security code was another. In fact (and I may have the details somewhat wrong) but an HP CTO co-founded a security startup, Secure64?, on the back of Itanium security code performance. But logic design is irrelevant beyond a certain point. Intel certainly had the process chops at the time and knew how to design microprocessors given a certain set of parameters. It's just the parameters were wrong (see Intel's late step-down from frequency on x86 above all else as well--driven I was told at a very high level by Microsoft's nervousness around multicore).
    - jandrese 3y ago
      FP benchmarks are just about the most synthetic benchmarks there are though. They mostly matter to people doing HPC, and those kinds of workloads are often in the realm of supercomputers. Which I think means everybody is saying basically the same thing, ia64 was overly specialized and had far too small of a market niche to survive.
- aleph_minus_one 3y ago
  Beside the mentioned points concerning the Itanium, there was another one that is important to consider: the Itanium was simply too expensive for many customers/applications (think: "typical" companies who buy PCs so that their employees can use them for office work; private PC users who might be enthusists, but are not that deep-pocketed; ...).
- lstodd 3y ago
  ARM owned the mobile market with ARM7 TDMI cores/socs back then. That's what allowed them to survive. Itanium on the other hand was killed by x86_64, yes.
dietrichepp 3y ago
Definitely agreed. Digging through Usenet archives, I found a post from John Mashey discussing the RISC-CISC spectrum. I found a copy here: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html The M68K gets called out as having some really complicated instructions in it, > We thought that adding more addressing modes was the way you made a machine more powerful https://www.computerhistory.org/collections/catalog/102658164 https://www.computerhistory.org/collections/catalog/10265816... People get caught up in intuitive notions of “complex” or “reduced” when talking about RISC and CISC, so it’s very helpful to have specific ideas about what of problems you’re creating for yourself years down the line, when you’re designing an architecture in the 1970s or 1980s. The M68K has instructions that can do these complicated copies from memory to memory, through layers of indirection, and that creates a lot of implementation complexity even though the instruction encoding itself is orthogonal. Meanwhile, the x86 instructions are less orthogonal, but the instructions that operate on memory only operate on one memory location, and the other operands must be in registers. That turned out to be the better tradeoff, long-term, IMO.
- jabl 3y ago
  In modern x86 we have things like the avx scatter gather instructions, which implement indirect addressing as well as accessing potentially lots of pages in a single instruction. Of course nowadays we have the transistor budgets to make even complicated instructions work.
- gallier2 3y ago
  Yes, and that was exactly my point (yes, I wrote that SO answer). The indirect addressing mode that were introduced with 68020 are insane. Most people don't know them, as they didn't exist in 68000/68010/68008 and most compilers did not implement them as they were slower to use than using simpler composed addressings. It is interesting to see what Motorola cut from the instruction set when they defined the Coldfire subset (for those who don't know, the coldfire family of CPU used the same instruction set as 68000 but radically simplified, the indirect addressing methods, the BCD mode, a lot of RMW instructions, etc. were removed. The first coldfire after 68060 which was limited to 75Mhz, ran at up to 300MHz).
sitkack 3y ago
You aren’t talking about the same thing. Not making a horrendous mistake isnt the same as making a good choice. MIPS delay slots are a non issue. Whatever ISA pragmatism can mean whatever you happen to define it as.

ajross 3y ago

Itanium and MIPS were... just fine though. Both architectures have parts that were very competitive along essentially all metrics the market cares about. ia64 failed for compatibility reasons, and because it wasn't "faster enough" than x86_64. No one saw much of a reason to run it, but Intel made them well and they made them fast. And MIPS failed for the same reason ARM pulled ahead: in the late 90's Intel took a huge (really, huge) lead over the rest of the industry in process and MIPS failed along with basically every other CPU architecture of the era Amusingly the reason ARM survived this bottleneck is because it was an "embedded" architecture in a market Intel wasn't targetting. But there's absolutely nothing technical that would prevent us from running very performant MIPS Macs or whatever in the modern world.

cpgxiii 3y ago
Itanium failed in the market because it wasn't fast enough running general purpose code (HPC workloads were a different story). As a consequence, it's ability to run existing x86 code was poor (both in hardware and software emulation). At the root, Itanium's poor performance was a direct consequence of the design assumption that a sufficiently smart compiler could extract sufficient instruction-level parallelism. While the ISA didn't prohibit later improvements like OoO execution, it always required a better compiler (and more specific workloads) than real users would have.
- pjmlp 3y ago
  Itanium failed in the market because AMD was allowed to come up with AMD64, that is all. Had it not been the case, the market would have been driven to Itanium no matter what.
ghaff 3y ago
Itanium was never really "just fine." The performance (or complete lack thereof) of x86 compatibility mode was one problem. But VLIW's reliance on software to do the right thing (with compilers etc.) was another big thing even for native IA64 code. And a decent-performing Itanium was delayed enough to arrive during dot-bomb vs. dot-com. If Itanium had really been the only 64-bit chip available for use in systems from multiple vendors maybe it would have succeeded by dint of an Intel monopoly position. But once x86_64 arrived from AMD and Intel ended up following suit, it was pretty much game over for Itanium.
- ajross 3y ago
  That's kinda revisionist. In fact ia64 owned the FP benchmark space for almost a decade, taking over from Alpha and only falling behind P6 derivatives once those started getting all the high end process slots (itself because Intel was demolishing other manufacturers in the high-margin datacenter market). The point was that ia64 was certainly not an "inferior" ISA, It did just fine by any circuit-design measure you want. Like every other ISA, it failed in the market for reasons other than logic design.
  - ghaff 3y ago
    Itanium had some specific performance strong points. FP was one. Certain types of security code was another. In fact (and I may have the details somewhat wrong) but an HP CTO co-founded a security startup, Secure64?, on the back of Itanium security code performance. But logic design is irrelevant beyond a certain point. Intel certainly had the process chops at the time and knew how to design microprocessors given a certain set of parameters. It's just the parameters were wrong (see Intel's late step-down from frequency on x86 above all else as well--driven I was told at a very high level by Microsoft's nervousness around multicore).
  - jandrese 3y ago
    FP benchmarks are just about the most synthetic benchmarks there are though. They mostly matter to people doing HPC, and those kinds of workloads are often in the realm of supercomputers. Which I think means everybody is saying basically the same thing, ia64 was overly specialized and had far too small of a market niche to survive.
aleph_minus_one 3y ago
Beside the mentioned points concerning the Itanium, there was another one that is important to consider: the Itanium was simply too expensive for many customers/applications (think: "typical" companies who buy PCs so that their employees can use them for office work; private PC users who might be enthusists, but are not that deep-pocketed; ...).
lstodd 3y ago
ARM owned the mobile market with ARM7 TDMI cores/socs back then. That's what allowed them to survive. Itanium on the other hand was killed by x86_64, yes.

dietrichepp 3y ago

Definitely agreed. Digging through Usenet archives, I found a post from John Mashey discussing the RISC-CISC spectrum. I found a copy here: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html The M68K gets called out as having some really complicated instructions in it, > We thought that adding more addressing modes was the way you made a machine more powerful https://www.computerhistory.org/collections/catalog/102658164 https://www.computerhistory.org/collections/catalog/10265816... People get caught up in intuitive notions of “complex” or “reduced” when talking about RISC and CISC, so it’s very helpful to have specific ideas about what of problems you’re creating for yourself years down the line, when you’re designing an architecture in the 1970s or 1980s. The M68K has instructions that can do these complicated copies from memory to memory, through layers of indirection, and that creates a lot of implementation complexity even though the instruction encoding itself is orthogonal. Meanwhile, the x86 instructions are less orthogonal, but the instructions that operate on memory only operate on one memory location, and the other operands must be in registers. That turned out to be the better tradeoff, long-term, IMO.

jabl 3y ago
In modern x86 we have things like the avx scatter gather instructions, which implement indirect addressing as well as accessing potentially lots of pages in a single instruction. Of course nowadays we have the transistor budgets to make even complicated instructions work.
gallier2 3y ago
Yes, and that was exactly my point (yes, I wrote that SO answer). The indirect addressing mode that were introduced with 68020 are insane. Most people don't know them, as they didn't exist in 68000/68010/68008 and most compilers did not implement them as they were slower to use than using simpler composed addressings. It is interesting to see what Motorola cut from the instruction set when they defined the Coldfire subset (for those who don't know, the coldfire family of CPU used the same instruction set as 68000 but radically simplified, the indirect addressing methods, the BCD mode, a lot of RMW instructions, etc. were removed. The first coldfire after 68060 which was limited to 75Mhz, ran at up to 300MHz).

sitkack 3y ago

You aren’t talking about the same thing. Not making a horrendous mistake isnt the same as making a good choice. MIPS delay slots are a non issue. Whatever ISA pragmatism can mean whatever you happen to define it as.