3 ms·
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 n
by 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 agoAs 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.