4 ms·

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 runn

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.
    - snvzz 4y ago
      >It has nothing whatsoever to do with the actual ISA RISC-V doesn't have a flags register. This is an actual advantage: Superscalar microarchitecture implementations do not need to keep track of who set what flag. This was a very conscious, carefully weighted decision, which presents a net win. One decision of many RISC-V designers had to make. There's better and worse ways for an ISA to do something. For every ISA decision, implementations (small and large) will either benefit or have to work around. You'll hear a lot of people insist that ISA doesn't matter; they're provably clueless.
      - tux3 4y ago
        >You'll hear a lot of people insist that ISA doesn't matter; they're provably clueless. One of them being Torvalds, the transmeta guy (also known for Git, and a couple other hobby projects) Now I tend to fall on your side of this argument, but I have to say I'd like to see the formal proof of cluelessness :) Having read previous iterations of the same arguments, I've yet to see anything quite that decisive.
        snvzz 4y ago
        >One of them being Torvalds, the transmeta guy (also known for Git, and a couple other hobby projects) A very capable person no doubt, but also one that's well-known to be wrong[0] about topics he is not an expert at. 0. https://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal.html https://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal....
        znwu 4y ago
        On ISA design, it is just so wrong to endorse the opinion of a single person. ISA design has three significant parties of interest: IC designers, compiler authors, and software developers. No one can master these three fields all at once. No one. Not even Linus (who would be a master software developer + a decent compiler specialist).
- howinteresting 4y ago
  Rust checks buffer overflows by default. It doesn't check integer overflows in release mode but that can be turned on as a compiler flag for a 10-20% performance hit on most programs.
  - moonchild 4y ago
    I am curious where you get 10-20%. Dan luu measures <1% at https://danluu.com/integer-overflow/ https://danluu.com/integer-overflow/
    - howinteresting 4y ago
      Those are figures I've heard second hand on a real project from some people I trust. My understanding is that a lot of optimizations become more complicated that way. I could be wrong though.
    - throwaway81523 4y ago
      1) it looks a lot worse than 1%, 2) it is on x86 not risc-v, 3) code bloat. Meanwhile risc-v and everything else checks overflow for floating point arithmetic because it is mandated by the IEEE standard. That doesn't seem to cause slowdowns. There is a code sequence in the risc-v docs someplace for doing a checked integer addition and it takes 3 or 4 instructions in the general case. Blecch. Better to set a flag like the FPU does, and check it at the end of a basic block.
      - zozbot234 4y ago
        That's only the suggested overflow checking for a single operation. When you have multiple add/sub/mul/compare operations in a row, checking for actual overflow becomes quite non-trivial and is not something that can be done by the hardware. Floating point has no equivalent to this, which is why it makes sense to have overflow checking as part of the instruction.
        throwaway81523 4y ago
bjourne 4y ago
It's a problem because if you are a vendor creating shrink-wrapped software you will have a hard time ensuring that your software supports all plausible extension combinations. Thus you will not bother just like most gaming companies does not bother porting their software to GNU/Linux. Sun basically did the same thing in the early 2000's with all their Java editions and profiles. It didn't work out well.
- jhgkjhlkhjkljk 4y ago
  The software makers will settle on a given subset of extensions most likely. The extensions here are meant for microcontrollers that won't run Linux. I think this will all sort itself out.

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.
  - snvzz 4y ago
    >It has nothing whatsoever to do with the actual ISA RISC-V doesn't have a flags register. This is an actual advantage: Superscalar microarchitecture implementations do not need to keep track of who set what flag. This was a very conscious, carefully weighted decision, which presents a net win. One decision of many RISC-V designers had to make. There's better and worse ways for an ISA to do something. For every ISA decision, implementations (small and large) will either benefit or have to work around. You'll hear a lot of people insist that ISA doesn't matter; they're provably clueless.
    - tux3 4y ago
      >You'll hear a lot of people insist that ISA doesn't matter; they're provably clueless. One of them being Torvalds, the transmeta guy (also known for Git, and a couple other hobby projects) Now I tend to fall on your side of this argument, but I have to say I'd like to see the formal proof of cluelessness :) Having read previous iterations of the same arguments, I've yet to see anything quite that decisive.
      - snvzz 4y ago
        >One of them being Torvalds, the transmeta guy (also known for Git, and a couple other hobby projects) A very capable person no doubt, but also one that's well-known to be wrong[0] about topics he is not an expert at. 0. https://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal.html https://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal....
      - znwu 4y ago
        On ISA design, it is just so wrong to endorse the opinion of a single person. ISA design has three significant parties of interest: IC designers, compiler authors, and software developers. No one can master these three fields all at once. No one. Not even Linus (who would be a master software developer + a decent compiler specialist).
howinteresting 4y ago
Rust checks buffer overflows by default. It doesn't check integer overflows in release mode but that can be turned on as a compiler flag for a 10-20% performance hit on most programs.
- moonchild 4y ago
  I am curious where you get 10-20%. Dan luu measures <1% at https://danluu.com/integer-overflow/ https://danluu.com/integer-overflow/
  - howinteresting 4y ago
    Those are figures I've heard second hand on a real project from some people I trust. My understanding is that a lot of optimizations become more complicated that way. I could be wrong though.
  - throwaway81523 4y ago
    1) it looks a lot worse than 1%, 2) it is on x86 not risc-v, 3) code bloat. Meanwhile risc-v and everything else checks overflow for floating point arithmetic because it is mandated by the IEEE standard. That doesn't seem to cause slowdowns. There is a code sequence in the risc-v docs someplace for doing a checked integer addition and it takes 3 or 4 instructions in the general case. Blecch. Better to set a flag like the FPU does, and check it at the end of a basic block.
    - zozbot234 4y ago
      That's only the suggested overflow checking for a single operation. When you have multiple add/sub/mul/compare operations in a row, checking for actual overflow becomes quite non-trivial and is not something that can be done by the hardware. Floating point has no equivalent to this, which is why it makes sense to have overflow checking as part of the instruction.
      - throwaway81523 4y ago

bjourne 4y ago

It's a problem because if you are a vendor creating shrink-wrapped software you will have a hard time ensuring that your software supports all plausible extension combinations. Thus you will not bother just like most gaming companies does not bother porting their software to GNU/Linux. Sun basically did the same thing in the early 2000's with all their Java editions and profiles. It didn't work out well.

jhgkjhlkhjkljk 4y ago
The software makers will settle on a given subset of extensions most likely. The extensions here are meant for microcontrollers that won't run Linux. I think this will all sort itself out.