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