4 ms·

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.
    - throwaway81523 6y ago
      As I remember it takes 3 extra instructions to check for arithmetic overflow after, say, an ADD instruction. Spewing those extra instructions all over the place sounds like severe code bloat to me, though I'll try to get around to checking examples sometime (gcc trapv vs wrapv). Yes, Risc-V is unable to trap on overflow and yes that was an intentional design decision. It can trap on invalid memory references and various other things, it can set flags on floating point overflow if it implements IEEE FP properly, but integer overflow is unchecked. Whether that limitation is wise or unwise is a matter of opinion, but that it is part of the architecture is just a fact.
sprash 6y ago
By using a CISC instead of RISC. But this time instead of designing it for easy human assembly programming like the VAX use instructions that drastically improve memory density, make the life of the branch predictor easier and promote memory locality. Also introduce branchless instructions like cmov.
- throwaway81523 6y ago
  RISC-V has the C extension (compressed opcodes, similar to Thumb-2) and code density then is comparable to x86 which is the main CISC in use these days.
  - sprash 6y ago
    The code density of x86 is not particular great.
    - throwaway81523 6y ago
      Well ok, I'd be interested in seeing a code density comparison between Riscv-IMC and whatever you want to compare it with. Vax density wasn't that great either, though maybe compilers back then weren't as good as now.
      - sprash 6y ago
        RISC-V doesn't even match ARM's levels when pulling extra tricks and extensions designed to improved code density. Other ISA's like AVR32 beat ARM by 50% which means it is more than possible to beat ARM. As I said, RISC-V is designed like a typical early 90s ISA when memory latency was not a concern. It will never be used in high performance general computing for that reason alone.
        brucehoult 6y ago
        32 bit RISC-V code density is slightly worse than Thumb2, but better than any other 32 bit ISA I'm aware of with similar performance. I don't know much about AVR32 except that it is very dead. Some ISAs designed explicitly for microcontroller use have denser code than RISC-V and Thumb2 on things such as manipulating GPIOs, but not on algorithmic code which makes up the vast majority of any application over a few KB in size. 64 bit RISC-V code density is far better than 64 bit ARM code density, which is similar to AMD64 (i.e. quite a bit bigger than i386) Other than a few extra instructions to zero-extend 32 bit values to 64 bits at times, 64 bit RISC-V and 32 bit RISC-V code are identical in size. High performance general computing these days means 64 bit, and RISC-V has by far the highest code density of any 64 bit ISA.

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.
  - throwaway81523 6y ago
    As I remember it takes 3 extra instructions to check for arithmetic overflow after, say, an ADD instruction. Spewing those extra instructions all over the place sounds like severe code bloat to me, though I'll try to get around to checking examples sometime (gcc trapv vs wrapv). Yes, Risc-V is unable to trap on overflow and yes that was an intentional design decision. It can trap on invalid memory references and various other things, it can set flags on floating point overflow if it implements IEEE FP properly, but integer overflow is unchecked. Whether that limitation is wise or unwise is a matter of opinion, but that it is part of the architecture is just a fact.

sprash 6y ago

By using a CISC instead of RISC. But this time instead of designing it for easy human assembly programming like the VAX use instructions that drastically improve memory density, make the life of the branch predictor easier and promote memory locality. Also introduce branchless instructions like cmov.

throwaway81523 6y ago
RISC-V has the C extension (compressed opcodes, similar to Thumb-2) and code density then is comparable to x86 which is the main CISC in use these days.
- sprash 6y ago
  The code density of x86 is not particular great.
  - throwaway81523 6y ago
    Well ok, I'd be interested in seeing a code density comparison between Riscv-IMC and whatever you want to compare it with. Vax density wasn't that great either, though maybe compilers back then weren't as good as now.
    - sprash 6y ago
      RISC-V doesn't even match ARM's levels when pulling extra tricks and extensions designed to improved code density. Other ISA's like AVR32 beat ARM by 50% which means it is more than possible to beat ARM. As I said, RISC-V is designed like a typical early 90s ISA when memory latency was not a concern. It will never be used in high performance general computing for that reason alone.
      - brucehoult 6y ago
        32 bit RISC-V code density is slightly worse than Thumb2, but better than any other 32 bit ISA I'm aware of with similar performance. I don't know much about AVR32 except that it is very dead. Some ISAs designed explicitly for microcontroller use have denser code than RISC-V and Thumb2 on things such as manipulating GPIOs, but not on algorithmic code which makes up the vast majority of any application over a few KB in size. 64 bit RISC-V code density is far better than 64 bit ARM code density, which is similar to AMD64 (i.e. quite a bit bigger than i386) Other than a few extra instructions to zero-extend 32 bit values to 64 bits at times, 64 bit RISC-V and 32 bit RISC-V code are identical in size. High performance general computing these days means 64 bit, and RISC-V has by far the highest code density of any 64 bit ISA.