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
