GHC on Arm

[Seth Kurtzberg]

I recently did a port of linux to ARM, and the floating point issue came up.

What happens is that if you don't do anything other than the default gcc 
build, then every floating point call is converted to an O/S trap which 
then does the floating point computation with the fixed point hardware 
(because there is no floating point hardware).

There is a much more efficient floating point library that can be built 
and used with gcc; I'm sorry that I don't have the specifics at hand but 
hopefully a web search will find it; if not, email me and I'll dig out 
the info.

Along with this extra code (which is quite short), there are one or two 
flags required for the initial ./configure for gcc.  Again, if these are 
not apparent I can go through my absurdly disorganized filing system 
(known as "the box") and find the flags as well.  Actually, I'm 
exaggerating; I have a complete gcc build procedure written that 
describes building for arm with the separate floating point code and 
specifies all the flags; I just have to retrieve it from a backup disk.  
I'm in the midst of moving but I think I can get at the appropriate CD 
without unpacking anything.

The performance difference, if your application is in any way floating 
point intensive, is dramatic.  The project for which I did the port 
involved scaling and panning of geographical (map) data, which is 
floating point intensive.

If your issue is floating point functionality rather than floating point 
performance, the standard gcc build and linux software emulation of 
floating point hardware works fine.  You only need to do the more 
complex procedure if your concern is performance.  It is not necessary 
if your use of floating point is light.

Note that while the entire cross compilation is time consuming 
(fortunately, mostly machine time consuming), changing it from the 
default o/s trap floating point to the more efficient floating point 
library is not difficult and is quick.  You don't have to start from 
scratch.  So it is perfectly reasonable to take the default behavior, do 
performance testing and profiling of the specific application, and add 
in the more efficient floating point library if profiling shows that you 
actually need it.

Note also that the main reason for the increase in performance is not 
that the kernel's floating point implementation is not good; the library 
I downloaded and built was only (based on somewhat rough calculation) 
about 15% faster.  The performance killer is the extra context switches 
that occur each time a floating point instruction causes an O/S trap.  
What I mean is that even though the downloaded library is only 15% 
faster than the kernel library, the performance increase is closer to an 
order of magnitude because of the higher costs of calls to the kernel 
vs. a simple call to a function within a library that is already linked 
into your application.

Seth


John Goerzen wrote:

>Hello,
>
>I would like to port GHC to Arm so that I can compile Haskell programs
>for use on my Zaurus or in Debian's ARM port.
>
>I have talked to Ian Lynagh about this, and he believes that there was
>some sort of problems with floats.  I don't know exactly that was, if it
>was in gcc or ghc, or if it has been fixed.  Does anybody have some
>light to shed on this?
>
>Also, does anybody have any ARM binaries of ghc to ease the
>bootstrapping pain?
>
>Thanks!
>_______________________________________________
>Glasgow-haskell-users mailing list
>Glasgow-haskell-users at haskell.org
>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>!DSPAM:41f13d7e187601466359710!
>
>  
>