[modeless]

Looks cool! Disappointed that there's no option to trap on integer overflow. Languages don't support it because processors don't support it, and processors don't support it because languages don't require it; a vicious cycle that someone needs to break.

[thesz]

Most of the time you don't need integer overflow. When you need it, you can insert a check.

I consider integer addition commands in MIPS a mistake. They take up CPU real estate, they slow down design and in the end they are not even used!

The handling of division overflow in MIPS is more fair. If you can have a division that may iverflow, compiler inserts a check. Resources are wasted only here, not everywhere.

[modeless]

I'm going to assume you meant "most of the time you don't need integer overflow checks", because that makes more sense with the rest of your comment.

I couldn't disagree more. If you look at real programs, overflow would be a bug for the vast majority of the integer arithmetic instructions. Therefore overflow checking should be the default. Wraparound overflow is sometimes useful and should be available but it should not be the default.

For example, http://www.cs.utah.edu/~regehr/papers/overflow12.pdf finds that there are ~200 instances of overflowing integer arithmetic instructions in all of SPEC CINT2000 (many of which are bugs). Every other integer arithmetic instruction in SPEC CINT2000 (orders of magnitude more than 200, of course) should never overflow; overflow would definitely be a bug and overflow checks would be useful in catching such bugs.

See http://blog.regehr.org/archives/1154 for a more complete argument. I really hope that if an ISA really does become "the standard ISA for all computing devices" as RISC-V aspires to, that it supports integer overflow traps.