6 ms·

What does that even mean? It has an integer add instruction, surely, and integer add can overflow. Do you mean you get no exception? or no status flag to chec

What does that even mean? It has an integer add instruction, surely, and integer add can overflow. Do you mean you get no exception? or no status flag to check?

sgtnoodle 6y ago
I vaguely recall risc-v having no status flags, instead preferring explicit instructions to check for such things. The idea is that, instead of implicitly paying for the checks on every operation whether or not you need it, you explicitly pay for it when you need it. At the hardware level, there's less interconnects and so all operations can be implemented simpler or faster. Integer overflow on addition of two unsigned values can be detected by comparing the result to one of the operands to see if it's smaller, which can probably be done in one additional instruction. I'm sure there's suitably clever tricks for signed addition as well as subtraction. All stuff that a compiler can implement appropriately. Maybe this limits the relative usefulness of risc-v silicon for programming languages that do a lot of safety checking. If your CPU spends 10% of its time doing additional runtime "safety" instructions vs. other architectures, but takes up 10% less space or runs 10% faster due to the simplicity, it seems like a wash though. Programs that don't need the runtime safety can then run 10% faster. Additionally, nothing is stopping someone from designing hardware that accelerates common instruction sequences. A CPU could still internally implement status flags and decode common compiler instruction sequences faster than otherwise.
- andrekandre 6y ago
  i think for integer operations, there are no status flags, but for floating point you can check the fcsr register for exceptions [0] [0] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20200727-8088ba4/riscv-spec.pdf https://github.com/riscv/riscv-isa-manual/releases/download/... EXCERPT Overflow checking for unsigned addition requires only a single additional branch instruction after the addition: add t0, t1, t2; bltu t0, t1, overflow. For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition: addi t0, t1, +imm; blt t0, t1, overflow. This covers the common case of addition with an immediate operand. FLOATING POINT As allowed by the standard, we do not support traps on floating-point exceptions in the base ISA, but instead require explicit checks of the flags in software. We considered adding branches controlled directly by the contents of the floating-point accrued exception flags, but ultimately chose to omit these instructions to keep the ISA simple.
- nullc 6y ago
  > paying for the checks on every operation whether or not you need it the actual overflow check is just the carry out... it's pretty cheap. putting it in a flags register creates dependencies. But there are presumably other approaches possible-- optional trapping, additional bits per output register, etc.
  - Taniwha 6y ago
    Status flags are a bit of a nightmare if you're building a massively superscalar implementation, every instruction has an explicit dependency on the one before - there have been a bunch of different solutions which often cost instruction decode space. RISC-V says "usually we don't care, let's only take the cost when we really need it" which is a very RISCish sort of thing to do. For those who haven't dabbled RISC-V has compare-and-branch instructions rather than branch on condition instructions
    - jabl 6y ago
      Doesn't arm have another set of arithmetic instructions that don't update the flags register, to avoid the dependency when it's not needed?
ncmncm 6y ago
RISC-V is designed to the momentarily fashionable idea that status flags are a big hurdle in optimizing instruction sequencing. Modern cores rename status flags along with all the other registers, making them cheap. The tortuous workarounds in RISC-V are worse than useless -- they are a tax on all users, but particularly on resource-constrained users who don't get instruction reordering anyway. In the future we will sneer at RISC-V's lack of implicit zero and overflow checks the way we sneer at SPARC's delay slots today.
- avianes 6y ago
  > RISC-V is designed to the momentarily fashionable idea that status flags are a big hurdle in optimizing instruction sequencing. > Modern cores rename status flags along with all the other registers, making them cheap. The RISC-V is designed in particular for superscalar processors. Renaming status registers does not make them cheap in superscalar microarchitecture. Just as delay slots make superscalar microarchitectures even more complex. All the microarchitectural states exposed by ISA, which allows optimization on scalar pipelined microarchitecture, make the implementation of superscalar microarchitectures more complex. Since these microarchitectural states do not represent what is actually happening in the hardware. This explains why MIPS is so unpopular today, it is fundamentally incompatible with the superscalar microarch. And this explains why RISC-V has chosen not to expose any microarchitectural states.
  - ncmncm 6y ago
    I see that you missed the point. People working on current x86 and POWER say status flags are no longer considered the problem they used to be. If you are investing the real estate to be superscalar, they are a trivial complication. If you are not, then the workarounds for their lack cost.
    - avianes 6y ago
      You are right, I didn't answer to your point. So I'm going to complete my thought. I explain that RISC-V removes unnecessary complexity from the hardware and puts this unnecessary complexity on the software. All they did was move a problem from the hardware to the software. And that's a good thing here, because overflow checks are (almost) never in the critical path of the application, it's (almost) only used for error handling. As these checks are almost (always) out of the critical path, it doesn't matter, this can be handled in parallel. And when they are on the critical path, the cost is definitely marginal. This simplifies the hardware because it removes an implicit dependency between all instructions, leaving only the explicit register names as the dependency. It is because of this kind of factors that RISC-V cores are smaller than X86 cores, for example. Which leaves more room for optimization. But if for some applications this becomes mandatory (an hardware overflow detection or a bound checker), RISC-V can in the future also add an extension to handle it. They could, for example, add a global status flag, or a status flag per register (which would remove the implicit dependency). But for now this is not necessary. You also talk about "tortuous workarounds". But the risc-v manual talks about "single instruction" in most cases. > they are a tax on all users, but particularly on resource-constrained users who don't get instruction reordering anyway. If they have made this CPU choice it is because they don't need performance, so it's not a real issue.

What does that even mean? It has an integer add instruction, surely, and integer add can overflow. Do you mean you get no exception? or no status flag to check?

sgtnoodle 6y ago

I vaguely recall risc-v having no status flags, instead preferring explicit instructions to check for such things. The idea is that, instead of implicitly paying for the checks on every operation whether or not you need it, you explicitly pay for it when you need it. At the hardware level, there's less interconnects and so all operations can be implemented simpler or faster. Integer overflow on addition of two unsigned values can be detected by comparing the result to one of the operands to see if it's smaller, which can probably be done in one additional instruction. I'm sure there's suitably clever tricks for signed addition as well as subtraction. All stuff that a compiler can implement appropriately. Maybe this limits the relative usefulness of risc-v silicon for programming languages that do a lot of safety checking. If your CPU spends 10% of its time doing additional runtime "safety" instructions vs. other architectures, but takes up 10% less space or runs 10% faster due to the simplicity, it seems like a wash though. Programs that don't need the runtime safety can then run 10% faster. Additionally, nothing is stopping someone from designing hardware that accelerates common instruction sequences. A CPU could still internally implement status flags and decode common compiler instruction sequences faster than otherwise.

andrekandre 6y ago
i think for integer operations, there are no status flags, but for floating point you can check the fcsr register for exceptions [0] [0] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20200727-8088ba4/riscv-spec.pdf https://github.com/riscv/riscv-isa-manual/releases/download/... EXCERPT Overflow checking for unsigned addition requires only a single additional branch instruction after the addition: add t0, t1, t2; bltu t0, t1, overflow. For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition: addi t0, t1, +imm; blt t0, t1, overflow. This covers the common case of addition with an immediate operand. FLOATING POINT As allowed by the standard, we do not support traps on floating-point exceptions in the base ISA, but instead require explicit checks of the flags in software. We considered adding branches controlled directly by the contents of the floating-point accrued exception flags, but ultimately chose to omit these instructions to keep the ISA simple.
nullc 6y ago
> paying for the checks on every operation whether or not you need it the actual overflow check is just the carry out... it's pretty cheap. putting it in a flags register creates dependencies. But there are presumably other approaches possible-- optional trapping, additional bits per output register, etc.
- Taniwha 6y ago
  Status flags are a bit of a nightmare if you're building a massively superscalar implementation, every instruction has an explicit dependency on the one before - there have been a bunch of different solutions which often cost instruction decode space. RISC-V says "usually we don't care, let's only take the cost when we really need it" which is a very RISCish sort of thing to do. For those who haven't dabbled RISC-V has compare-and-branch instructions rather than branch on condition instructions
  - jabl 6y ago
    Doesn't arm have another set of arithmetic instructions that don't update the flags register, to avoid the dependency when it's not needed?

ncmncm 6y ago

RISC-V is designed to the momentarily fashionable idea that status flags are a big hurdle in optimizing instruction sequencing. Modern cores rename status flags along with all the other registers, making them cheap. The tortuous workarounds in RISC-V are worse than useless -- they are a tax on all users, but particularly on resource-constrained users who don't get instruction reordering anyway. In the future we will sneer at RISC-V's lack of implicit zero and overflow checks the way we sneer at SPARC's delay slots today.

avianes 6y ago
> RISC-V is designed to the momentarily fashionable idea that status flags are a big hurdle in optimizing instruction sequencing. > Modern cores rename status flags along with all the other registers, making them cheap. The RISC-V is designed in particular for superscalar processors. Renaming status registers does not make them cheap in superscalar microarchitecture. Just as delay slots make superscalar microarchitectures even more complex. All the microarchitectural states exposed by ISA, which allows optimization on scalar pipelined microarchitecture, make the implementation of superscalar microarchitectures more complex. Since these microarchitectural states do not represent what is actually happening in the hardware. This explains why MIPS is so unpopular today, it is fundamentally incompatible with the superscalar microarch. And this explains why RISC-V has chosen not to expose any microarchitectural states.
- ncmncm 6y ago
  I see that you missed the point. People working on current x86 and POWER say status flags are no longer considered the problem they used to be. If you are investing the real estate to be superscalar, they are a trivial complication. If you are not, then the workarounds for their lack cost.
  - avianes 6y ago
    You are right, I didn't answer to your point. So I'm going to complete my thought. I explain that RISC-V removes unnecessary complexity from the hardware and puts this unnecessary complexity on the software. All they did was move a problem from the hardware to the software. And that's a good thing here, because overflow checks are (almost) never in the critical path of the application, it's (almost) only used for error handling. As these checks are almost (always) out of the critical path, it doesn't matter, this can be handled in parallel. And when they are on the critical path, the cost is definitely marginal. This simplifies the hardware because it removes an implicit dependency between all instructions, leaving only the explicit register names as the dependency. It is because of this kind of factors that RISC-V cores are smaller than X86 cores, for example. Which leaves more room for optimization. But if for some applications this becomes mandatory (an hardware overflow detection or a bound checker), RISC-V can in the future also add an extension to handle it. They could, for example, add a global status flag, or a status flag per register (which would remove the implicit dependency). But for now this is not necessary. You also talk about "tortuous workarounds". But the risc-v manual talks about "single instruction" in most cases. > they are a tax on all users, but particularly on resource-constrained users who don't get instruction reordering anyway. If they have made this CPU choice it is because they don't need performance, so it's not a real issue.