Unregisterised GHC 6.4.2 on the ARM success -- now what?
jeremy.shaw at linspireinc.com
Tue May 9 17:28:42 EDT 2006
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:
I built it with --prefix=/opt/ghc-6.4.2, so I think it has to be
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
So, I think the next step is to start the Registerising process. Are
there any wiki pages or documents about this yet?
Running 'make fast' for the testsuite only returns these unexpected failures:
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 ****
--- 4,11 ----
*** 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:
#define L 1
#define H 0
#define L 0
#define H 1
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.
More information about the Glasgow-haskell-users