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" <head...@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 <mr...@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@openjdk.java.net
> > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
