4 ms·

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.

by zik 6y ago

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.

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.

by 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.