4 ms·

I never understood the hype around RISC-V. It is an ISA on the level of a mediocre early 90s design and does not address any of the problems we have today such

by sprash 6y ago

I never understood the hype around RISC-V. It is an ISA on the level of a mediocre early 90s design and does not address any of the problems we have today such as the memory latency bottleneck and the resulting topology challenges. Several completely open source designs are available that are vastly superior and real world battle tested such as OpenSPARC-T2. So why do we need RISC-V? Is it another case of NIHS?

duskwuff 6y ago
Off the top of my head: 1. RISC-V is completely unencumbered from an IP perspective. There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019). 2. RISC-V is legacy-free. It's an extremely "clean" design, free of weird quirks like the MIPS branch delay slot or SPARC register windows. 3. There are subsets of the RISC-V architecture defined for different sizes of systems, e.g. 32/64 bit versions, an embedded subset with fewer registers, etc. They all share an instruction set and a general architecture, and most compilers can target any subset. Some of the smaller subsets are well within the realm of what a single student can be taught to implement within a semester. 4. Numerous real implementations of RISC-V exist -- both as hardware and HDL -- are being maintained, and the hardware is available on the open market.
- MaxBarraclough 6y ago
  > There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019) What happened with MIPS in 2019? Shouldn't that kind of thing be impossible, the way it's impossible to revoke the GPL licence on software?
  - duskwuff 6y ago
    > What happened with MIPS in 2019? https://www.hackster.io/news/wave-computing-closes-its-mips-open-initiative-with-immediate-effect-zero-warning-e88b0df9acd0 https://www.hackster.io/news/wave-computing-closes-its-mips-...
    - musicale 6y ago
      Wow, they really wanted to kill off MIPS, burn their partners, and destroy any remaining credibility, didn't they? Astonishing.
      - murderfs 6y ago
        They saw the writing on the wall that MIPS was already dead.
        musicale 6y ago
        If this is true, it makes it even sadder that they killed open mips, which could have been a nice thing.
andrekandre 6y ago
memory latency bottleneck and the resulting topology challenges how can an isa solve those issues?
- zik 6y ago
  It can't. I don't think he know what he's talking about. Also saying it's like "a mediocre 90s design" is pure bias. It's a nice modern design.
  - throwaway81523 6y ago
    I'm not the one who called it that, it's nice in many ways, but being unable to trap integer overflow seems 90s to me. Integer overflow (like buffer overflow) is now recognized as a common source of bugs, but it takes several instructions to detect with risc-v. So your compiler has to generate those extra instructions after almost every integer operation to implement trapping (-ftrapv in GCC and maybe LLVM parlance). This is sort of like a cpu architecture where dereferencing a null pointer is required to return 0 rather than trap. So either you have to either generate a bunch of extra checking code, or let software bugs go undetected for much longer than necessary. I think MIPS had a similar issue but eventually fixed it. Maybe RISCV can do similar.
    - guerrilla 6y ago
      > generate those extra instructions Yeah, that's RISC.
      - saagarjha 6y ago
        Not on MIPS.
    - brucehoult 6y ago
      RISC-V is not "unable" to trap integer overflow. They made a deliberate decision not to. And divide by zero as well. Instructions that can trap -- but almost never do unless you have a program bug -- cause a large complication in pipelines, and especially in OoO implementations. Even a single-issue pipeline can run faster and be smaller without conditionally-trapping instructions, and as soon as you have even 2-wide execution it's just much better in every way to use explicit checks that use the same conditional branching facilities as the rest of the code. The code size penalty is very minor in practice.
MaxBarraclough 6y ago
edit I missed duskwuff's answer, which is better informed than mine. I'll leave this here anyway. How open is OpenSPARC? Are there patent concerns? RISC-V isn't aiming to revolutionise CPU architecture with a radical new design, it's aiming to offer a Free and Open, patent-unencumbered, fairly conventional RISC ISA. They're quite open about their emphasis on openness. [0] For a project that aims to turn CPU design on its head, there's the Mill processor, although it's broadly thought to be vaporware. [0] https://riscv.org/why-risc-v/ https://riscv.org/why-risc-v/
brucehoult 6y ago
A mediocre early 90s design that is totally unencumbered is a lot better than a mediocre late 70s design hacked beyond the limits of sanity. Or would be. The fact is RISC-V is a distinct improvement on early 90s designs such as MIPS III and has also learned lessons from Alpha, PowerPC, Itanium, and AMD64. In many ways RISC-V and Aarch64 (which were being designed in parallel unknown to each other) learned the same lessons from those earlier ISAs, though they made several trade-offs differently.

by sprash 6y ago

duskwuff 6y ago

Off the top of my head: 1. RISC-V is completely unencumbered from an IP perspective. There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019). 2. RISC-V is legacy-free. It's an extremely "clean" design, free of weird quirks like the MIPS branch delay slot or SPARC register windows. 3. There are subsets of the RISC-V architecture defined for different sizes of systems, e.g. 32/64 bit versions, an embedded subset with fewer registers, etc. They all share an instruction set and a general architecture, and most compilers can target any subset. Some of the smaller subsets are well within the realm of what a single student can be taught to implement within a semester. 4. Numerous real implementations of RISC-V exist -- both as hardware and HDL -- are being maintained, and the hardware is available on the open market.

MaxBarraclough 6y ago
> There is no possibility of a rightsholder reasserting rights on IP they had previously released (like what happened with MIPS in 2019) What happened with MIPS in 2019? Shouldn't that kind of thing be impossible, the way it's impossible to revoke the GPL licence on software?
- duskwuff 6y ago
  > What happened with MIPS in 2019? https://www.hackster.io/news/wave-computing-closes-its-mips-open-initiative-with-immediate-effect-zero-warning-e88b0df9acd0 https://www.hackster.io/news/wave-computing-closes-its-mips-...
  - musicale 6y ago
    Wow, they really wanted to kill off MIPS, burn their partners, and destroy any remaining credibility, didn't they? Astonishing.
    - murderfs 6y ago
      They saw the writing on the wall that MIPS was already dead.
      - musicale 6y ago
        If this is true, it makes it even sadder that they killed open mips, which could have been a nice thing.

andrekandre 6y ago

memory latency bottleneck and the resulting topology challenges how can an isa solve those issues?

zik 6y ago
It can't. I don't think he know what he's talking about. Also saying it's like "a mediocre 90s design" is pure bias. It's a nice modern design.
- throwaway81523 6y ago
  I'm not the one who called it that, it's nice in many ways, but being unable to trap integer overflow seems 90s to me. Integer overflow (like buffer overflow) is now recognized as a common source of bugs, but it takes several instructions to detect with risc-v. So your compiler has to generate those extra instructions after almost every integer operation to implement trapping (-ftrapv in GCC and maybe LLVM parlance). This is sort of like a cpu architecture where dereferencing a null pointer is required to return 0 rather than trap. So either you have to either generate a bunch of extra checking code, or let software bugs go undetected for much longer than necessary. I think MIPS had a similar issue but eventually fixed it. Maybe RISCV can do similar.
  - guerrilla 6y ago
    > generate those extra instructions Yeah, that's RISC.
    - saagarjha 6y ago
      Not on MIPS.
  - brucehoult 6y ago
    RISC-V is not "unable" to trap integer overflow. They made a deliberate decision not to. And divide by zero as well. Instructions that can trap -- but almost never do unless you have a program bug -- cause a large complication in pipelines, and especially in OoO implementations. Even a single-issue pipeline can run faster and be smaller without conditionally-trapping instructions, and as soon as you have even 2-wide execution it's just much better in every way to use explicit checks that use the same conditional branching facilities as the rest of the code. The code size penalty is very minor in practice.

MaxBarraclough 6y ago

edit I missed duskwuff's answer, which is better informed than mine. I'll leave this here anyway. How open is OpenSPARC? Are there patent concerns? RISC-V isn't aiming to revolutionise CPU architecture with a radical new design, it's aiming to offer a Free and Open, patent-unencumbered, fairly conventional RISC ISA. They're quite open about their emphasis on openness. [0] For a project that aims to turn CPU design on its head, there's the Mill processor, although it's broadly thought to be vaporware. [0] https://riscv.org/why-risc-v/ https://riscv.org/why-risc-v/

brucehoult 6y ago

A mediocre early 90s design that is totally unencumbered is a lot better than a mediocre late 70s design hacked beyond the limits of sanity. Or would be. The fact is RISC-V is a distinct improvement on early 90s designs such as MIPS III and has also learned lessons from Alpha, PowerPC, Itanium, and AMD64. In many ways RISC-V and Aarch64 (which were being designed in parallel unknown to each other) learned the same lessons from those earlier ISAs, though they made several trade-offs differently.