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