The trouble is that rounding modes need to be dynamically specified in order to enable debugging of suspicious floating-point programs. See William Kahan's ran

The trouble is that rounding modes need to be dynamically specified in order to enable debugging of suspicious floating-point programs. See William Kahan's rants about debugging tools for floating-point arithmetic for a detailed explanation of it, which I will attempt to summarize. If you have in hand several algorithms A, B, and C, and one or two of them produce results that differ significantly from the other, how do you tell which one is more likely to be in error? Kahan has a tool that helps: The method which is more sensitive to roundoff error will have its results perturbed worse by directed roundings, and is more likely to be the method in error. So, you run each of the suspect codes in three modes: Round to nearest even (the default), round to +inf and round to -inf. The code whose results don't change the least under directed roundings is more likely to be correct than the others. In practice, the difference can be pretty dramatic. This method just helps to point the arrow of suspicion, it isn't foolproof. But it is a useful debugging tool. Static rounding modes don't help for a broad class of problems without recompilation. Good luck running some slice of a Python program rounded three ways, for example. It also requires the ability to control which portion of the program is affected, since decimal -> float parsing code only works correctly in the round to nearest even mode. That's the crux of my argument: IEEE754 requires dynamic rounding, the numerical analyst needs dynamic rounding, and dynamic rounding subsumes static rounding. Given all that, burning three bits per opcode is pretty damn expensive, especially when you're cramming FMA4 into 32-bit opcodes. Its a mistake at least as bad as branch delay slots. But since its hiding in the floating-point portion of the ISA, it isn't as obviously wrong to the common programmer.