4 ms·

RISC-V gets more and more complicated all the time. N different extensions of which almost any subset is a valid combo, so 2**N variants. Meanwhile, nothing

RISC-V gets more and more complicated all the time. N different extensions of which almost any subset is a valid combo, so 2**N variants. Meanwhile, nothing about fast integer overflow detection.

Jtsummers 4y ago
2^N (I'm guessing you typed two *s, you need to type 4 to get two to show up). ** => * **** => **
- throwaway81523 4y ago
  Thanks, fixed.
wyldfire 4y ago
I think the RISC-V committees/foundation realized the problem and is endorsing specific combinations of extensions.
- snvzz 4y ago
  Rather than "realized the problem", it would be more accurate to say that they understood the ramifications of extensions from the very beginning, took adequate steps, and never allowed it to become a problem.
brucehoult 4y ago
It's not a problem because: - if you're compiling your own software you just tell the compiler what extensions the hardware you're using has. - if you're running shrink-wrapped software today then you currently know exactly that RV64GC is supported, and next year you'll know there are 2.5 possibilities: RVA20 (RV64GC renamed), and RVA22 with or without V extension. I expect the next one (RVA24 or RVA25 or something) will make V compulsory. If you actually genuinely care about fast integer overflow detection on RISC-V then make a proposal, analysing the costs and benefits. As far as most people are concerned, there isn't a problem there in the first place.
- throwaway81523 4y ago
  > As far as most people are concerned, there isn't a problem there [fast overflow detection] in the first place. See, that is the problem. They try to be an architecture for the future but they are only concerned about performance of legacy code that doesn't check overflow either. The result is a zillion CVE's from overflow bugs, to go with the buffer overflows. Idk whether Rust is supposed to check overflow. Ada is supposed to check unless you suppress the check with a pragma, but GNAT sets the pragma by default because doing the check costs too much performance even on x86. The Ada designers were not being fools when they specified that these checks should be done all the time. So an architecture of the future should support doing that efficiently, just like the CHERI(?) extension supports checking pointers efficiently. As for the many combinations of features: it will be like x86 I guess, where it is a hassle but ultimately not a crushing one. Usually people just give up some performance by using lowest common denominator (or should that be greatest common factor) executables.
  - brucehoult 4y ago
    Not having dedicated overflow checking instructions doesn't mean that you can't check overflows. You can. There is no problem because checking overflows doesn't in practice cause significant overhead, especially in the kinds of superscalar CPUs that are in mobile devices and laptops and PCs and servers these days. Most of the time those wide OoO CPUs are looking in vain for more parallelism. Adding a few overflow-checking instructions just gives them something to do with execution slots they otherwise often can't use. If there is a actual problem -- which needs to be PROVEN not just hand-waved -- then analyse it in the real world, document it, propose an ISA extension that would actually make things better in real-world applications, not just some hand-picked tiny loop or function.
    - zozbot234 4y ago
      Indeed, the overhead of checking overflow (which generally amounts to a few percentage points) is all about missed optimization opportunities due to the need for precise reporting of overflow errors. It has nothing whatsoever to do with the actual ISA, at least assuming a reasonable compiler.
rwmj 4y ago
Have you tried this recently? grep ^flags /proc/cpuinfo
dzaima 4y ago
Mentioning 2^N variants on this specific proposal is probably the worst place to do so - Zca, Zcf, Zcd are all subsets of the 'c' extension, and Zcmp is incompatible with the 'c' extension, which severely cuts down the combinations - having the 'c' extension, which Linux expects, makes all (but Zcb I think?) extensions here either implicitly supported, or incompatible. And, given the scope & purpose of these extensions, most things (distributed binary programs, OSes, all but a few compilers) won't need to use nor care about these. The alternative to these extensions, to those that need them, would be either suffering decreased performance/increased ROM size, choosing a different architecture, or making proprietary extensions (at which point you could have multiple vendors with incompatible extensions doing the same thing) - all of which are bad alternatives.

RISC-V gets more and more complicated all the time. N different extensions of which almost any subset is a valid combo, so 2**N variants. Meanwhile, nothing about fast integer overflow detection.

Jtsummers 4y ago

2^N (I'm guessing you typed two *s, you need to type 4 to get two to show up). ** => * **** => **

throwaway81523 4y ago
Thanks, fixed.

wyldfire 4y ago

I think the RISC-V committees/foundation realized the problem and is endorsing specific combinations of extensions.

snvzz 4y ago
Rather than "realized the problem", it would be more accurate to say that they understood the ramifications of extensions from the very beginning, took adequate steps, and never allowed it to become a problem.

brucehoult 4y ago

It's not a problem because: - if you're compiling your own software you just tell the compiler what extensions the hardware you're using has. - if you're running shrink-wrapped software today then you currently know exactly that RV64GC is supported, and next year you'll know there are 2.5 possibilities: RVA20 (RV64GC renamed), and RVA22 with or without V extension. I expect the next one (RVA24 or RVA25 or something) will make V compulsory. If you actually genuinely care about fast integer overflow detection on RISC-V then make a proposal, analysing the costs and benefits. As far as most people are concerned, there isn't a problem there in the first place.

throwaway81523 4y ago
> As far as most people are concerned, there isn't a problem there [fast overflow detection] in the first place. See, that is the problem. They try to be an architecture for the future but they are only concerned about performance of legacy code that doesn't check overflow either. The result is a zillion CVE's from overflow bugs, to go with the buffer overflows. Idk whether Rust is supposed to check overflow. Ada is supposed to check unless you suppress the check with a pragma, but GNAT sets the pragma by default because doing the check costs too much performance even on x86. The Ada designers were not being fools when they specified that these checks should be done all the time. So an architecture of the future should support doing that efficiently, just like the CHERI(?) extension supports checking pointers efficiently. As for the many combinations of features: it will be like x86 I guess, where it is a hassle but ultimately not a crushing one. Usually people just give up some performance by using lowest common denominator (or should that be greatest common factor) executables.
- brucehoult 4y ago
  Not having dedicated overflow checking instructions doesn't mean that you can't check overflows. You can. There is no problem because checking overflows doesn't in practice cause significant overhead, especially in the kinds of superscalar CPUs that are in mobile devices and laptops and PCs and servers these days. Most of the time those wide OoO CPUs are looking in vain for more parallelism. Adding a few overflow-checking instructions just gives them something to do with execution slots they otherwise often can't use. If there is a actual problem -- which needs to be PROVEN not just hand-waved -- then analyse it in the real world, document it, propose an ISA extension that would actually make things better in real-world applications, not just some hand-picked tiny loop or function.
  - zozbot234 4y ago
    Indeed, the overhead of checking overflow (which generally amounts to a few percentage points) is all about missed optimization opportunities due to the need for precise reporting of overflow errors. It has nothing whatsoever to do with the actual ISA, at least assuming a reasonable compiler.

rwmj 4y ago

Have you tried this recently? grep ^flags /proc/cpuinfo

dzaima 4y ago

Mentioning 2^N variants on this specific proposal is probably the worst place to do so - Zca, Zcf, Zcd are all subsets of the 'c' extension, and Zcmp is incompatible with the 'c' extension, which severely cuts down the combinations - having the 'c' extension, which Linux expects, makes all (but Zcb I think?) extensions here either implicitly supported, or incompatible. And, given the scope & purpose of these extensions, most things (distributed binary programs, OSes, all but a few compilers) won't need to use nor care about these. The alternative to these extensions, to those that need them, would be either suffering decreased performance/increased ROM size, choosing a different architecture, or making proprietary extensions (at which point you could have multiple vendors with incompatible extensions doing the same thing) - all of which are bad alternatives.