Unregisterised GHC 6.4.2 on the ARM success -- now what?

[Jeremy Shaw]

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.bz2

I 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.