[kaffe] Re: Classpath's doubleToLongBits
Dalibor Topic wrote: 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. Do we need a gcj fix somewhere? Andrew. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Classpath's doubleToLongBits
On Mon, 2008-02-18 at 04:03 +0100, Dalibor Topic wrote: 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. That sounds like it was a lot of work. Did you change anything new in GNU Classpath or should I test the current CVS version? - twisti ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Classpath's doubleToLongBits
On Mon, 2008-02-18 at 12:44 +0100, Dalibor Topic wrote: That sounds like it was a lot of work. Did you change anything new in GNU Classpath or should I test the current CVS version I wrote a patch using the -0.0d 0L hack described above to detect whether we should switch words in a double, but it turned out not to be necessary, so current CVS is fine (and contains no related changes). Perfect! :-) - twisti ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Classpath's doubleToLongBits
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 ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Classpath's doubleToLongBits
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. - twisti ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Classpath's doubleToLongBits
Christian Thalinger schrieb: On Fri, 2008-02-08 at 00:26 +0100, Dalibor Topic wrote: 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 0x7fef we get 0x7fef. 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? That sounds actually very good, if it works on all configurations. I can remember we had a lot of problems to get these functions right on an Arm system with VFP. For more problems see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22800 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. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
