Re: 5/0.0 = Infinity : NO error is thrown
Arne VajhHj wrote:
Mark Space wrote:
Roedy Green wrote:
But if the hardware does not support it? You then have the overhead
of checking after every operation, even when you are not interested.
There's lots of things that hardware supports today, which it didn't
ten years ago.
First make it correct, then make it fast.
We are talking every floating point division here.
And?
Seriously, maybe I need to explain a bit more, but I don't see the issue.
First I said the JIT compiler could be involved to emit code to check,
or not check, for divide by zero. That should involve setting or
clearing a flag on the floating point unit. Or checking one flag
afterwards. Not a big deal. If you don't care, emit code to ignore the
flag. Easy.
For byte-code, well you have to have the JVM check. But anything that
isn't compiled by the JIT compiler shouldn't be used very often, so
again the performance hit should be minimal. It might be worth while to
install a trap in the fpu if the fpu supports them, and just ignore
divides by zero when they happen, if that is the selected option. That
takes NO time, other than the initial poke-the-address-in-here at start
up. (Most of the time I'd expect the OS to do that for you.) I haven't
looked at Intel's or AMD's specs lately, but this is 1990 technology.
For ints, same deal. I think even the original 8086 had a hardware trap
for integer divide by zero. No time during execution of code was needed
to check for this error.
I don't think these concepts are that hard. Are they being taught in
school these days? Folks, hardware has always bent over backwards to
accommodate the software. This overflow stuff is old old news. There
are much more exciting issues with modern architecture than number overflow.