4 ms·

> It was one ISA, and a terrible one at that Except, you know, the whole point of VLIW designs was that by offloading complexity to the compiler and runtime yo

> It was one ISA, and a terrible one at that Except, you know, the whole point of VLIW designs was that by offloading complexity to the compiler and runtime you'd be less limited by hardware design decisions and be able to improve with time. Provide real examples of how Itanium could have been done better. > You're missing my point, which is about rewriting the world No, I'm not. "Compatibility with standard C code" means memory allocations and branches. That's it. Most "real" OSs need an MMU, but there are a few research systems that don't. You should also keep in mind that lots of different models have been tried. Compiled machine code? Done. JIT-recompiled machine code? Done. GC'd Lisp on hardware? Done. GC'd ada on hardware? Done. GC'd JVM on hardware? Done. Binary translation to "better" hardware? Done, lots of different times. "Rewrite the world" has been tried a fair number of times before, and it didn't win out. You're also totally missing the point that several architectures, x86/x86_64 most notably, have succeeded because ISA and hardware implementation aren't locked together tightly. Processor designers and users are not nearly as constrained together as you believe.

Veedrac 6y ago
> Except, you know, the whole point of VLIW It's really indicative of the problem I'm talking about that so many people think the options are either a standard, Intel Core-style OoO or Itanium-style VLIW. Not only is VLIW a massive range of potential things, and Itanium is not the natural implementation of it, but I never even said we should go with VLIWs! I'm personally more enamoured with CG-OoO style hierarchical reordering, though were rewriting the world possible I'd do something that exposed more of that to software (probably microthread style). > Provide real examples of how Itanium could have been done better. Although Itanium seems like a dead-end strategy to me, three things it got really wrong were: * software data misprediction recovery, * overly large register files, * compiler target locks in uarch decisions. (Please mind that it's been a while since I looked at the Itanium ISA.) The Mill is sort of what Itanium would be with all the rough edges sanded over, though it's sort of a moot point since the Mill will never exist outside of talks. Again, static schedules aren't the approach I'd advocate for, since there are some things they just can't do.
renox 6y ago
> it didn't win out. It didn't win because 1) making a top performing CPU is very expensive 2) you can only only recoup your investment by selling a lot of CPUs. So you need to be very efficient with the installed base of software.. While in the past this favored x86 / x86-64 compatibility, this is shifting towards ARM compatibility.. Maybe this will favour experimentations? ARM ISA is far less complex to implement so from a technical POV this could help companies trying to experiment.
- cpgxiii 6y ago
  > So you need to be very efficient with the installed base of software That's only somewhat true. Until the modern era of cloud hyperscalers, fairly weird architectures with poor compatibility were quite successful, especially in HPC and defense markets. Cell and its derivatives were successful for their time. Any number of quirky microcontroller architectures were successful before the Cortex-M family came to dominate (and some still are). Yes, the startup costs are always going to be high, but success in the broader market isn't necessary for a performant architecture to survive. > Maybe this will favour experimentations? I don't think so, if anything the high performance aarch64 designs like Apple's M1 are more similar to x86_64 designs than previous generations. Large caches, wide execution, serious OoO, stronger-than-expected memory ordering. I think more experimentation will come from the RISC-V community targeting more specific applications.
  - renox 6y ago
    >if anything the high performance aarch64 designs like Apple's M1 are more similar to x86_64 designs than previous generations. And? If an 'exotic ISA' can really offer some improvement, it must be able to compete with 'the best of the best' implementation of current ISA..
    - cpgxiii 6y ago
      The point is that if you're looking for distinctly different approaches than the currently dominant x86_64, aarch64 implementations are not where to look.

Veedrac 6y ago

> Except, you know, the whole point of VLIW It's really indicative of the problem I'm talking about that so many people think the options are either a standard, Intel Core-style OoO or Itanium-style VLIW. Not only is VLIW a massive range of potential things, and Itanium is not the natural implementation of it, but I never even said we should go with VLIWs! I'm personally more enamoured with CG-OoO style hierarchical reordering, though were rewriting the world possible I'd do something that exposed more of that to software (probably microthread style). > Provide real examples of how Itanium could have been done better. Although Itanium seems like a dead-end strategy to me, three things it got really wrong were: * software data misprediction recovery, * overly large register files, * compiler target locks in uarch decisions. (Please mind that it's been a while since I looked at the Itanium ISA.) The Mill is sort of what Itanium would be with all the rough edges sanded over, though it's sort of a moot point since the Mill will never exist outside of talks. Again, static schedules aren't the approach I'd advocate for, since there are some things they just can't do.

renox 6y ago

> it didn't win out. It didn't win because 1) making a top performing CPU is very expensive 2) you can only only recoup your investment by selling a lot of CPUs. So you need to be very efficient with the installed base of software.. While in the past this favored x86 / x86-64 compatibility, this is shifting towards ARM compatibility.. Maybe this will favour experimentations? ARM ISA is far less complex to implement so from a technical POV this could help companies trying to experiment.

cpgxiii 6y ago
> So you need to be very efficient with the installed base of software That's only somewhat true. Until the modern era of cloud hyperscalers, fairly weird architectures with poor compatibility were quite successful, especially in HPC and defense markets. Cell and its derivatives were successful for their time. Any number of quirky microcontroller architectures were successful before the Cortex-M family came to dominate (and some still are). Yes, the startup costs are always going to be high, but success in the broader market isn't necessary for a performant architecture to survive. > Maybe this will favour experimentations? I don't think so, if anything the high performance aarch64 designs like Apple's M1 are more similar to x86_64 designs than previous generations. Large caches, wide execution, serious OoO, stronger-than-expected memory ordering. I think more experimentation will come from the RISC-V community targeting more specific applications.
- renox 6y ago
  >if anything the high performance aarch64 designs like Apple's M1 are more similar to x86_64 designs than previous generations. And? If an 'exotic ISA' can really offer some improvement, it must be able to compete with 'the best of the best' implementation of current ISA..
  - cpgxiii 6y ago
    The point is that if you're looking for distinctly different approaches than the currently dominant x86_64, aarch64 implementations are not where to look.