> Outputting a NaN is easier than raising an interrupt That's probably why the recent RISC-V architecture doesn't even give the option of raising an interrupt

> Outputting a NaN is easier than raising an interrupt That's probably why the recent RISC-V architecture doesn't even give the option of raising an interrupt on floating point errors ("As allowed by the standard, we do not support traps on floating-point exceptions in the base ISA, [...]"). Going even farther, it also doesn't raise an interrupt on integer divide by zero (https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf#section.6.2 https://content.riscv.org/wp-content/uploads/2017/05/riscv-s...). That probably simplifies out-of-order implementations, since the only things that can trap then are the instruction decoder (instruction fetch errors and invalid instructions), the load/store instructions, and special instructions (system calls, breakpoints, and like). (It also doesn't propagate NaN payloads, always returning the same canonical NaN whenever an operation produces a NaN).