Dalibor Topic wrote:
Dalibor Topic wrote:
My plan would be to look at making the interpreter pass on arm-oabi
and arm-eabi without failures, and then
to move on to the jits. I'd also like to see if I can rip out all the
atomic* code in Kaffe's config dirs by using glib's
atomic functions instead, as that would be less low level code from
libc to keep around as copies in Kaffe.
Any volunteers for the arm-* interpreter failures?
3 failures on OABI, 5 on EABI, btw.
I've looked a bit closer at the 3 ARM OABI errors, in particular at the
errors in test/regression/DoubleConst.java . That test fails because we
get the bitstreams of the doubles being tested when we call
Double.doubleToLongbits with swapped words, i.e. instead of
0x7fefffffffffffff we get 0xffffffff7fefffff.
The current GNU Classpath implementation of
Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words,
whenever __ARMEL__ is defined. That makes the DoubleConst test fail for
Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of
time trying to get it right on his ARM systems, I didn't want to mess
with the corresponding file in fdlibm.
So I wrote another implementation of the function, using ieee754.h (part
of glibc). Basically, it boils down to shifting the bits from the
bitfields to the right places inside the jlong. Easy.
Unfortunately, that didn't work on arm OABI debian sid either. It turned
out that glibc has a bug in the iee754.h header file, that comes to bite
one on arm OABI. Filed as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch
attached.
Meanwhile, that still means that those 3 tests fail until glibc is
fixed. So ... I'll send in a couple of patches to the classpath patches
list to first rewrite the doubleToLongBits in Java (and the same for
Float), removing it from the VM interface, and then, I'll send in a
patch to add the ieee754.h way of dealing with fetching the bits to the
current way.
Does that sound useful?
cheers,
dalibor topic
