On 09/07/2011 02:25 PM, Charles Oliver Nutter wrote:
> On Wed, Sep 7, 2011 at 2:00 AM, Per Bothner<p...@bothner.com> wrote:
>> Kawa's gnu.math.IntNum already does this. It has only two fields:
>
> Yeah, I think I remember you mentioning this in one of the
> arbitrary-precision math threads on JVM-L. I assume you could use an
> intrinsic optimization for overflow checks too, yes?
That seem likely. Right now the code path is a bit complex,
but in the case of adding two array-less IntNum we convert
to long, and do a long addition. Then we check if the result
is in the range [minFixNum..maxFixNum] of pre-allocated IntNums.
Then we check if result==(int)result - i.e. if we got an actual
overflow.
So in addition to a fast overflow check it would be helpful
to have a fast test that the result is in range of the
preallocated "fixnums". If we had a cheap overflow test
then I'd presumably change the code patch to use int arithmetic
(instead of long), but it might still be too much to inline.
I think a fast overflow check is most helpful when you want to
detect overflow and throw an exception; it's less of a win
when you also need to allocate a BigInteger/IntNum.
--
--Per Bothner
p...@bothner.com http://per.bothner.com/
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
