Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #7709

Re: Arithmetic overflow checking

Cross-posted to 2 groups.

Show all headers | View raw

Am Sun, 10 Jul 2011 01:47:25 -0700 (PDT)
schrieb tm <thomas.mertes@gmx.at>:

> A CPU could (in theory) easily recognize the overflow
> and generate an interrupt. This way normal computations
> (without overflow) would have no extra cost.

Interrupts are extremely expensive. They require the OS kernel into a
full blown context switch, registers must be saved and restored. And
finally the process needs to be signaled. Nobody sane in his mind would
it be done that way.

> AFAIK commonly used CPUs do not have this possibility. They
> have some FLAG, which is set when an overflow occurred.

And checking a flag is how difficult? It's a simple, cheap conditional
jump. And the execution prediction system works very efficient on
flags, because they're integral CPU state.

> But there is no possibility to cause an interrupt, when
> the overflow FLAG is set. So code, which checks for
> overflow, must check this flag after every computation.

So? Checks are not expensive. Heck, some architectures, like ARM,
execute instructions conditionally, depending on a flag. Reacting on a
overflow flag comes with NO EXTRA COST there.

> Needless to say: Normal computations (without overflow)
> are slowed down by this checks.

No, they are not. Modern pipelined CPUs have codepath prediction and
out-of-order-operations, where some codepaths are executed proactively
and their results are kept on-hold. The instructions reacting upon the
overflow flag check may have been finished, even before the offending
operation may have been.

> Because of this slow down most compilers and virtual
> machines (AFAIK inluding the JVM) have no overflow
> checking.

Almost every new language designed implement overflow checks. Also
every generic container library does so. Overflow checks cost NOTHING
these days.

> In other words: A missing hardware feature:
> 
>   Trigger interupt when overflow flag is set.
> 
> Causes compilers and JVMs to omit overflow checks.

Did you ever think about the kind of infrastructure that's required for
this? This goes down into the bowels of the OS kernel. Interrupts
always cause context switches, which are expensive. Checking a flag
comes practically for free. Especially if the execution prediction can
determine, that a certain codepath depends on a certain flag only.

To give you some figures: Processing an interrupt takes Linux about 1 to
10µs. On a 3GHz CPU that amounts to 30000 clockcycles, and most
modern, pipelined CPUs finish at least 1 instruction per clock cycle;
on a Intel Pentium or Core for the majority of instructions have a up
to 8 finished instructions per clock cycle. In the time your proposed
overflow-check interrupt is processed you can do about 200000 flag
checks.


Wolfgang

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar

Thread

Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 21:02 +0200
  Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 21:12 +0200
    Re: Arithmetic overflow checking Willem <willem@toad.stack.nl> - 2011-09-08 19:15 +0000
      Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 22:24 +0200

csiph-web