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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
!DSPAM:41f13d7e187601466359710!