Unregisterised GHC 6.4.2 on the ARM success -- now what?
Hello, I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux. Details: ------- I only had to do a minor bit of hacking -- this bug contains the details of what went wrong: http://hackage.haskell.org/trac/ghc/ticket/762 My target platform is the nokia 770 which runs linux and has an arm9 processor. I compiled ghc using the standard nokia 770 cross-development tools. These consist of a debian-based distro named maemo running inside scratchbox using QEMU to emulate the ARM processor. I have successfully compiled a "hello, world!" program and run the executable on the real nokia 770 device. What Next? ---------- The next step appears to be to registerise the build. I found a document that describes the C calling conventions for the ARM: http://www.arm.com/miscPDFs/8031.pdf I think the next step is to add an ARM section to: ghc/includes/MachRegs.h Is there some sensible method for doing this and testing it before I tackle the other pieces ? Thanks! j.
Jeremy Good stuff! Often when you do something like this you learn a lot of things you wish you'd known at the outset. Do please consider adding anything you have learned to the GHC developer's Wiki http://hackage.haskell.org/trac/ghc That way you'd help someone else avoid the things that held you up. This'd be particularly useful at the moment, because my impression is that more people are setting about porting GHC. The obvious place would be under "Developer documentation". Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jeremy Shaw | Sent: 04 May 2006 06:06 | To: GHC Users Mailing List | Subject: Unregisterised GHC 6.4.2 on the ARM success -- now what? | | Hello, | | I believe I have successfully got an unregisterised version of ghc | 6.4.2 compiled for arm/linux. | | Details: | ------- | | I only had to do a minor bit of hacking -- this bug contains the | details of what went wrong: | | http://hackage.haskell.org/trac/ghc/ticket/762 | | My target platform is the nokia 770 which runs linux and has an arm9 | processor. I compiled ghc using the standard nokia 770 | cross-development tools. These consist of a debian-based distro named | maemo running inside scratchbox using QEMU to emulate the ARM | processor. | | I have successfully compiled a "hello, world!" program and run the | executable on the real nokia 770 device. | | What Next? | ---------- | | The next step appears to be to registerise the build. I found a | document that describes the C calling conventions for the ARM: | | http://www.arm.com/miscPDFs/8031.pdf | | I think the next step is to add an ARM section to: | | ghc/includes/MachRegs.h | | Is there some sensible method for doing this and testing it before I | tackle the other pieces ? | | Thanks! | j. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Wed, 2006-05-03 at 22:06 -0700, Jeremy Shaw wrote:
Hello,
I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux.
Cool! Well done. I know there are several people who wanted to use ghc on the 770. Previously hugs and yhc have been made to work on the 770. Now I start wondering if I can get your package working on Gentoo/Arm. It's one of the few arches we're missing. Duncan
Duncan Coutts wrote:
On Wed, 2006-05-03 at 22:06 -0700, Jeremy Shaw wrote:
Hello,
I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux.
Cool! Well done. I know there are several people who wanted to use ghc on the 770. Previously hugs and yhc have been made to work on the 770.
Now I start wondering if I can get your package working on Gentoo/Arm. It's one of the few arches we're missing.
Jeremy, perhaps you'd like to add an entry here: http://hackage.haskell.org/trac/ghc/wiki/Platforms I seem to recall there were floating point issues with ARM processors, what did you do about that? Cheers, Simon
At Wed, 03 May 2006 22:06:05 -0700, Jeremy Shaw wrote:
Hello,
I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux.
Updates: ------- 1) I turns out I only had a in-place build of ghc, I have now got a real build 'working'. 2) I have started putting my notes in the Wiki I added a section to the end of this page: http://hackage.haskell.org/trac/ghc/wiki/Platforms And started this page: http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc I will add the information about getting from an inplace .hc build to a normal build tomorrow. 3) It would appear that the floating point problem is still a problem. It did not cause any compile time errors. But ghc generates bogus answers, the one liner: main = print 1.0 prints: 5.299808824e-315 I found this thread from the last time it came up: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/007688.h... According to this page: http://wiki.tcl.tk/15408 The nokia 770 uses middle endian for floating point: http://www.catb.org/jargon/html/M/middle-endian.html I will do more research tomorrow and see what needs to be done. j.
Jeremy Shaw wrote:
At Wed, 03 May 2006 22:06:05 -0700, Jeremy Shaw wrote:
Hello,
I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux.
Updates: -------
1) I turns out I only had a in-place build of ghc, I have now got a real build 'working'.
2) I have started putting my notes in the Wiki
I added a section to the end of this page:
http://hackage.haskell.org/trac/ghc/wiki/Platforms
And started this page:
http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc
I will add the information about getting from an inplace .hc build to a normal build tomorrow.
3) It would appear that the floating point problem is still a problem. It did not cause any compile time errors. But ghc generates bogus answers, the one liner:
main = print 1.0
prints: 5.299808824e-315
If you want to get a picture of how much of your GHC build is working, it's useful to run the test suite. Check out the testsuite repository from darcs.haskell.org into your source tree, then $ cd testsuite $ make boot $ cd tests/ghc-regress then, to do a quick test run (~5 minutes): $ make stage=2 fast or a full test run (several hours, probably): $ make stage=2 Cheers, Simon
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.
Jeremy Shaw wrote:
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
nice find!
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.
The right way to fix this is to add an autoconf test, second best is to change the #define as you did above. If you can hack up an autoconf test and send a patch, we'll commit it. Cheers, Simon
participants (4)
-
Duncan Coutts -
Jeremy Shaw -
Simon Marlow -
Simon Peyton-Jones