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 p

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.