Hacker News Reader

Comment by maggit | Hacker News Reader

The entire premise of the linked article is that doing it the way you suggest is too expensive for the common case, where no overflow happens. Further, it implicitly asserts that the cost of a hardware trap/exception, while great, will be offset by the savings from the common case.

Now, it doesn't back these assertions with much data, but neither do you :)

View on HN

Exactly -- the premise would be that non-overflowing arithmetic would be the "fast path" and overflow would be truly exceptional.

This is similar to null-reference protection in various languages and runtimes, where null dereferences are caught by mapping guard pages at the beginning of memory. Dereferencing a pointer is optimistic and assumes that it will succeed, the same as arithmetic operations would in this proposal.

The problem is that potentially-overflowing integer instructions make a real mess out of things like out-of-order execution and speculative execution.

For data to back this, see your favorite computer architecture reference, particularly anything that discusses the consequences of highly-complex instructions in things like the VAX.

Citing stuff from the 80s RISC movement is pretty outdated nowadays, especially in this specific case where quintessential RISC architectures such as MIPS implemented trapping arithmetic instructions from the start.

To the contrary, out-of-order execution and speculative execution make precise exceptions trivial to support. As long as exceptions are not frequent, there is no performance pentalty either. It's the older in-order pipelines who struggle with precise exceptions. But there are well-known tricks to work around that too...

The problem with a hardware implementation is that you break algorithms and coding systems for which integer overflow, or rather integer wrapping, is a necessary piece rather than an exception case. You could, in theory, add an instruction that disables integer exceptions, but that would make the hardware more complicated. You could also redesign the aforementioned algorithms and systems to not rely on the implicit wrapping, but then you make them more expensive.

No one is advocating eliminating modulo arithmetic - the trapping instructions would be different ops, just like on architectures that already implement this such as MIPS.

OK, so then its on the compiler to use the non-exception-generating instructions when generating the assembly.

Reply on news.ycombinator.com