Update Summary
--------------
The testsuite indicates that the first-pass ghc arm build is in pretty
good shape -- I think it now does everything that can be expected
without porting the rts, etc. I have uploaded a tarball for anyone who
wants to try it:
http://www.n-heptane.com/nhlab/projects/ghc-arm/ghc-6.4.2-arm-unknown-linux-bin.tar.bz2I built it with --prefix=/opt/ghc-6.4.2, so I think it has to be
installed there.
I only had to make a one-bit hack to get floating point (mostly)
working. I can submit a patch -- but I need a question answered below
first.
So, I think the next step is to start the Registerising process. Are
there any wiki pages or documents about this yet?
Testsuite Results
-----------------
Running 'make fast' for the testsuite only returns these unexpected failures:
cg034(normal)
cg044(normal)
fed001(normal)
ffi006(normal)
ffi007(normal)
ffi008(normal)
ffi010(normal)
ffi011(normal)
ffi013(normal)
ffi014(threaded)
I believe all the ffi/fed failures are because Adjustor.c has not been
ported, so "wrapper" and "export dynamic" do not work.
The cg034/cg044 failures seem to be related to non-IEEE floating point
conformance at extremes:
Actual stdout output differs from expected:
*** ./should_run/cg034.stdout Wed Jun 20 08:11:18 2001
--- ./should_run/cg034.run.stdout Tue May 9 12:11:48 2006
***************
*** 4,11 ****
3.4028235e38
2.2250738585072014e-308
2.2250738585072014e-308
! 1.7976931348623157e308
! 1.7976931348623157e308
0.0
1.821736912876398e-300
0.0
--- 4,11 ----
3.4028235e38
2.2250738585072014e-308
2.2250738585072014e-308
! NaN
! NaN
0.0
1.821736912876398e-300
0.0
*** unexpected failure for cg034(normal)
Floating Point on the Nokia 770
-------------------------------
The maemo distribution (aka, the linux distro on the nokia 770), uses
the in-kernel netwinder floating point emulation to emulate the arm
floating point unit (FPA11). This is the 'standard' way of doing
things on arm-linux.
The NWPFE seems to be *mostly* IEEE compliant. As the above tests
indicate -- there appear to be some errors at the extremes. I think
this is probably a nwfpe bug, not a ghc bug.
The other difference is the word order for doubles (and extended
precision doubles -- but I do not think ghc uses those). The nokia 770
is a little-endian system -- but in, ghc/rts/StgPrimFloat.c, I had to
hack this #ifdef:
#ifdef WORDS_BIGENDIAN
#define L 1
#define H 0
#else
#define L 0
#define H 1
#endif
so that it used the WORDS_BIGENDIAN defines. I think that NWFPE always
uses the WORDS_BIGENDIAN ordering for doubles, so on a big-endian arm
system, it probably works ok out-of-the-box -- but I do not have a way
to test that.
What would be a suitable way to patch this in the source? I think the
only other place that WORDS_BIGENDIAN is used to manipulate a double
is in the testsuite in the cg044 test.
Should we define a new variable, such as DOUBLES_WORD_ORDER? Or just
hack the existing #defines to something like,
#ifdef WORDS_BIGENDIAN || NWFPE
I think the first option is better, because then people do not have to
know about architecture specific hacks.
j.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Locked
