GP2X Software Floating Points

[Feeg]

I hacked together a really quick and nasty raycaster one night a week or so back, using SDL.

It was basically just a test to see if my toolchain was working, so I was pretty slack. Gratuitous use of glibc's math functions, totally inefficient line drawing algorithm and about 20 float local vars.

Compiled it with -msoft-float and to my surprise, the thing didn't just run, but it seemed to run at a decent speed, all things considered.

I had originally intended to start real development by writing my own software floating point library, but I'm not sure whether it's worth it. Does anyone have an opinion? Is gcc's inbuilt software float reasonably well optimised, or can it be beaten with a little effort?

At this point I realise I should hop on Google and do some more research, but from the people who have actually been working with the GP2x for a while I'd like to hear any opinions..

 

[Parkydr]

I don't think there's any point writing a floating point library (except you might find it fun! ) as you say soft-float is generally good enough. I would have thought it would be pretty optimised by now with the number of ARM developers out there. If you need extra performance, fixed point is a better bet, but even then I wouldn't bother doing it until I had a problem.

 

[woogal]

Is gcc's inbuilt software float reasonably well optimised, or can it be beaten with a little effort?

The arm soft-float patches that were first added in gcc 3.4 are fantastic (5-10 times quicker than previous versions), so I don't think you could produce something better with just a little effort . The only way you could easily get something running quicker is to switch to fixed point.

 

[Feeg]

Alright, thanks for the opinions. I was coming to the same conclusion, re: fixed point.

I think I'll start with the soft-floats and see how it goes. If I keep my code modular enough I shouldn't paint myself into a corner.. much.