4 ms·

SPARC, PPC, and ARM can all run Linux just fine.

raverbashing 3y ago
Yes but why would you waste silicon implementing complicated stuff from the 90s when you can have something more modern like RISCV or ARM?
- guenthert 3y ago
  I'm confused about what is called modern here and why. In any case I (and I am sure the vast majority) of consumers and application developers (system developers are of course in a different position) doesn't care one bit about the inner workings until some inherent security flaw like SPECTRE arises.
- inkyoto 3y ago
  Register windows and register files are the same thing. Most RISC architectures have eschewed the register windows in favour of the register files coupled with the register renaming though. Silicon is «wasted» (debatable) in high-performance CPU designs employing the register files but can be saved in low-cost designs by not implementing a register file at the performance penalty cost. Same is true for the designs with register windows. The difference between the two is that with the register window the onus of tracking the dependencies in the data flow in registers is explicitly on the compiler (or on the developer) whereas with the register file the onus is on the CPU to track the dependencies, apply heuristics, allocate shadow registers from the register file, rename the in-use registers onto the shadow registers and vice versa. Modern high-performance CPU implementations that do not employ the register windows typically come with large or very large register files (100-300 circa registers are common).
  - deleted 3y ago
    [deleted]
  - gpderetta 3y ago
    Calling register files (or register renaming) the same as register windows, is a significant stretch. Renaming is important for OoO execution, register windows were used (in the original risc and sparc) to paper over the lack of a good register allocator. Later EPIC used a variant of it for software pipelining.
- OmarAssadi 3y ago
  Too new can be problematic sometimes. For pure performance per dollar, and even in terms of energy consumption, AMD64 CPUs are still doing great, and you don't have to worry about something not being ported yet because it's the defacto standard outside of phones and certain niches like automotive, etc; I couldn't care less about ARM in terms of compute for a workstation, gaming computer, or server, especially with things like QAT and various other accelerators. What I really do care about, though, is all modern x86/AMD64 platforms are super complex and super proprietary; I have no way to trust them. And while ARM may not be quite as crazy as x86, it is pretty much just as proprietary, and so it doesn't solve my issue of being able to trust the hardware and firmware, or tinker with design. RISC-V is cool. But going back to trust, it is a mountain of work to bootstrap from "bare metal" (UEFI or whatever else) on x86/AMD64 alone -- C++ has been my enemy; virtually everything ends up depending upon having a working C++ compiler at some point in the chain, including LLVM and any version of GCC not at least a decade old. This means either cross-compiling GCC/LLVM for RISC-V from another system [which is problematic if you don't have a way to cross-compile from something already trusted and reproducible], or backporting/implementing RISC-V support into a ton of software. Meanwhile, POWER has been around; it may not be as well supported as x86, but I think it's still far easier and significantly more realistic if you want to build a more-or-less trustable, reproducible system. Plus, outside of root of trust paranoia, again, it's just far more realistic IMO as a workstation, server, or whatever else because of that much larger existing catalog of working software; you can get your proprietary Nvidia drivers for POWER if you want them, but I don't think they have any intention of supporting RISC-V. Also, in general, I'm not totally convinced RISC-V offers significant enough improvements over POWER to really justify it. Maybe someone more familiar with RISC-V could offer compelling reasons that I'm not aware of, though. EDIT: Lastly, RE: wasting silicon, there is also the aspect of "wasting" money and R&D building competitive designs relative to existing stuff -- I don't know when I'll be able to get my hands on a fast RISC-V system.
  - raverbashing 3y ago
    Thanks for the answer, yes I guess it makes sense But yes I'm not complaining about POWER here, more about SPARC > C++ has been my enemy; virtually everything ends up depending upon having a working C++ compiler at some point in the chain Would be surprising if it hasn't been
- tssva 3y ago
  ARM originated in the early 80s.

Yes but why would you waste silicon implementing complicated stuff from the 90s when you can have something more modern like RISCV or ARM?

guenthert 3y ago
I'm confused about what is called modern here and why. In any case I (and I am sure the vast majority) of consumers and application developers (system developers are of course in a different position) doesn't care one bit about the inner workings until some inherent security flaw like SPECTRE arises.
inkyoto 3y ago
Register windows and register files are the same thing. Most RISC architectures have eschewed the register windows in favour of the register files coupled with the register renaming though. Silicon is «wasted» (debatable) in high-performance CPU designs employing the register files but can be saved in low-cost designs by not implementing a register file at the performance penalty cost. Same is true for the designs with register windows. The difference between the two is that with the register window the onus of tracking the dependencies in the data flow in registers is explicitly on the compiler (or on the developer) whereas with the register file the onus is on the CPU to track the dependencies, apply heuristics, allocate shadow registers from the register file, rename the in-use registers onto the shadow registers and vice versa. Modern high-performance CPU implementations that do not employ the register windows typically come with large or very large register files (100-300 circa registers are common).
- deleted 3y ago
  [deleted]
- gpderetta 3y ago
  Calling register files (or register renaming) the same as register windows, is a significant stretch. Renaming is important for OoO execution, register windows were used (in the original risc and sparc) to paper over the lack of a good register allocator. Later EPIC used a variant of it for software pipelining.
OmarAssadi 3y ago
Too new can be problematic sometimes. For pure performance per dollar, and even in terms of energy consumption, AMD64 CPUs are still doing great, and you don't have to worry about something not being ported yet because it's the defacto standard outside of phones and certain niches like automotive, etc; I couldn't care less about ARM in terms of compute for a workstation, gaming computer, or server, especially with things like QAT and various other accelerators. What I really do care about, though, is all modern x86/AMD64 platforms are super complex and super proprietary; I have no way to trust them. And while ARM may not be quite as crazy as x86, it is pretty much just as proprietary, and so it doesn't solve my issue of being able to trust the hardware and firmware, or tinker with design. RISC-V is cool. But going back to trust, it is a mountain of work to bootstrap from "bare metal" (UEFI or whatever else) on x86/AMD64 alone -- C++ has been my enemy; virtually everything ends up depending upon having a working C++ compiler at some point in the chain, including LLVM and any version of GCC not at least a decade old. This means either cross-compiling GCC/LLVM for RISC-V from another system [which is problematic if you don't have a way to cross-compile from something already trusted and reproducible], or backporting/implementing RISC-V support into a ton of software. Meanwhile, POWER has been around; it may not be as well supported as x86, but I think it's still far easier and significantly more realistic if you want to build a more-or-less trustable, reproducible system. Plus, outside of root of trust paranoia, again, it's just far more realistic IMO as a workstation, server, or whatever else because of that much larger existing catalog of working software; you can get your proprietary Nvidia drivers for POWER if you want them, but I don't think they have any intention of supporting RISC-V. Also, in general, I'm not totally convinced RISC-V offers significant enough improvements over POWER to really justify it. Maybe someone more familiar with RISC-V could offer compelling reasons that I'm not aware of, though. EDIT: Lastly, RE: wasting silicon, there is also the aspect of "wasting" money and R&D building competitive designs relative to existing stuff -- I don't know when I'll be able to get my hands on a fast RISC-V system.
- raverbashing 3y ago
  Thanks for the answer, yes I guess it makes sense But yes I'm not complaining about POWER here, more about SPARC > C++ has been my enemy; virtually everything ends up depending upon having a working C++ compiler at some point in the chain Would be surprising if it hasn't been
tssva 3y ago
ARM originated in the early 80s.