Fast long overflow detection?

[Vitaly Davidovich]

Can't the overflow test be (value ^ result) & (otherValue ^ result) < 0? I
think that's what hacker's delight suggests and you don't need the negation
and the sign bit mask in that case.

Sent from my phone
On Feb 7, 2012 3:31 PM, "Charles Oliver Nutter" <headius at headius.com> wrote:

> The JRuby logic mimics what I think others are doing:
>
>    private IRubyObject addFixnum(ThreadContext context, RubyFixnum other) {
>        long otherValue = other.value;
>        long result = value + otherValue;
>        if (additionOverflowed(value, otherValue, result)) {
>            return addAsBignum(context, other);
>        }
>        return newFixnum(context.getRuntime(), result);
>    }
>
>    private static boolean additionOverflowed(long original, long
> other, long result) {
>        return (~(original ^ other) & (original ^ result) & SIGN_BIT) != 0;
>    }
>
> JRuby's invokedynamic paths have special casing for a few small fixnum
> operations by comparing with Long.MAX_VALUE and MIN_VALUE (e.g. a + 1
> overflowed if it's now == Long.MIN_VALUE).
>
> - Charlie
>
> On Tue, Feb 7, 2012 at 7:28 PM, Mark Roos <mroos at roos.com> wrote:
> > So I thought I could get away with 64bit ints and not implement the
> > Smalltalk automatic conversion
> > to BigIntegers.  Bad plan.
> >
> > So I went ahead and did it while I waited for the super bowl to start.
>  Not
> > too difficult.  Just wrappered
> > java BigInteger and added some simple overflow detection.
> >
> > But I am concerned about the impact on integer ops by adding a pretty
> > complex precalc overflow detection.
> > To help I decided to limit small ints to 62 bits and defer some checking
> > until after the op and cache lookup.
> >
> > Any suggestions on approaches that offer superior techniques?
> >
> > Seems like a methodHandle of guardOverflow would be handy someday.
> >
> > regards
> > mark
> > _______________________________________________
> > mlvm-dev mailing list
> > mlvm-dev at openjdk.java.net
> > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120207/629a3923/attachment.html