[kaffe] [Fwd: Patch for: Kaffe doesn't work with GMP on x86_64]

[Dalibor Topic]

Alan Eliasen wrote:

Hi Alan,

I am sorry for taking so long to reply, I had some trouble finding time 
to dig down, and reproduce the the problem. Thanks a lot for being 
persistent about fixing the bug, and providing a very useful patch!

>    I think that I have a patch for this problem.  (See below.)  It
> appears that all of the steps in Java_java_math_BigInteger_assignLong0
> in the file can simply be replaced with a single call to mpz_set_si(res,
> v) which sets a GMP integer from a signed long int. 

That's correct. On architectures where sizeof(jlong) == sizeof(long), 
that's much faster than doing three gmp calls, as the existing method does.

>    I think that this code should be simpler and faster than the original
> code, if a jlong is an unsigned long, but I haven't checked it on all
> architectures, only on x86_64 where the problem originally occurred.
> 

For architectures where sizeof(jlong) > sizeof(long) (i.e. platforms 
with a 64bit long long), we still need the old algorithm to break the 
number in two 32 bit pieces, and shuffle the bits into the gmp number.

There was a bug in the way it was done, though, since the downcasting to 
a jint seems to have produced bad results. The updated code now uses a 
bitmask to do the masking before the shifting.

>    This works and passes my regression tests.
> 

Indeed, same for me on x86-64. I've also fixed it on 32bit platforms as 
well, and confirmed that your test returns the correct result on x86.

> this is a patch to libraries/clib/math/BigInteger.c .  Please let me
> know if I can produce this patch in a better format, and what I can do
> to get this fixed in Kaffe.

I personally find patches in unified diff format to be more readable 
(diff -u), but for short patches, anything is fine for me.

You've mentioned further problems on amd64, if you are interested in 
tracking them down, I'd be happy to merge further patches in.

cheers,
dalibor topic