

Better debugger - CapitalistCartr
http://newsoffice.mit.edu/2015/integer-overflow-debugger-outperforms-predecessors-0324

======
hga
Amusing. Over at Berkeley, they developed a new, open CPU design that is
intended to be useful for pretty much everything from education to industry,
and to keep it simple it has no support for integer errors beyond making it
cheap to detect divide by zero: [http://riscv.org/](http://riscv.org/)

~~~
renox
Given that the MIPS (introduced in __1981 __) had integer operations with
traps on overflow, I find very strange this reasoning.

~~~
hga
In part, perhaps this is Worse is Better AKA the New Jersey way. One part is
that this makes it simpler for education, but I'm not convinced, especially by
their rationalizations in the published ISA, that this is acceptable for
"industry", which they claim to also be aiming for. The long integer
cryptography people certainly are distressed.

~~~
renox
I think that we're talking about different things:

you're talking cryptography people who need carry bit and integer instructions
with carry to efficiently implement long integers

I'm talking about programmers who likes when their programs core dump instead
of returning them garbage (could also be useful for security maybe) and 'trap
on integer overflow' instructions help here.

~~~
hga
Actually I'm _meaning_ to talk about both; I wanted to bring up the long
integer folks because that's a less obvious need to embed integer overflow
machinery in your CPU.

------
rdc12
If this is being run on a binary only (for C anyway), then this won't be able
to detect signed integer overflow if the compiler optimizes it away

