[kaffe] Re: Classpath's doubleToLongBits

[Dalibor Topic]

Christian Thalinger schrieb:
> On Fri, 2008-02-08 at 12:25 +0100, Dalibor Topic wrote:
>   
>> Yeah, that's why I'd like to go step by step, and first slash the VM 
>> interface methods I can slash, and
>> then implement it with ieee754.h as an option, (adding a #define 
>> BIG_ENDIAN __BIG_ENDIAN
>> for the broken glibc versions). I'll make sure to post the native 
>> patches for comments first, as I don't
>> have access to a VFP box.
>>     
>
> OK, I hope I still have access to this box, but I'll try to test them.
>   
This one turned out to be a lot more fun to track down.

It's pretty easy to rewrite the test whether to swap words in a jdouble: 
put -0.0 into a jvalue's
jdouble element, and if the correspoding jlong bitstream is > 0, you 
have to swap the words.
It's a way of dynamically doing what the fdlibm #defines do, but it 
works out the same way:
swap on arm-debian-oabi.

But that didn't fix the breakage.

So I played around some more, and eventually, it turned out that kaffe's 
classfile constant parser
was working fine, and I was reading in doubles the way arm's FPU 
expected them laid out, it
turned out the interpreter was working ok, too, and so on.

But the breakage was still there.

Turning the way, for example, the double constants were parsed around, 
and doing it the 'wrong' way,
fixed some regression tests, but broke others. Similarly, reassembling 
doubles in the interpreter
from words the 'wrong' way had the same effect with other tests.

So I had to examine things a bit more closely with jcf-dump. It turned 
out that, since I was using a
glibj.zip compiled on an x86-linux host, the constant in the class 
java.lang.Double were laid out
correctly. But in the tests classes compiled on the arm-oabi-linux 
platform using ecj on gcj-4.3,
double constants were laid out incorrectly, with their words swapped, as 
a comparison with the
tests compiled on x86-linux with ecj on gcj showed.

So, current Kaffe CVS head interpreter works on arm-oabi-linux without 
regressions. The regressions
Kiyo-san has seen are caused by buggy compilers (jikes / ecj on gcj). 
And I'll move on to comitting the
jit patches for arm-linux next.

cheers,
dalibor topic