> I've been looking at the arm32 FP lib code with an eye towards tuning it.
> 
> But before I start ripping it up, I figured I'd better do some reality checks.
> 
> Is the software floating point provided by EGCS sufficiently crappier that
> we should not try to use it?
> 
> Would it cause problems if I were to split up the FP library into lots of
> little .o's so that only the actually used functions are linked in?
> 
> Is there a provision for machine-dependent versions of math.h so I could
> stuff in some inline functions if that made sense?

I did some thinging about this some years ago. (The project was canceled
due to uncompilable gcc)

I have this idea for almost maximally fast floating point math.
32 bit mantissa, and 32 bit exponent, signed int that is.

To multiply, first mulitply the mantissas, and while the StrongARM does
that, add the exponents. Then shift mantissa and incrase exponent if
necessary to make the number normalized, which will happen
about half of the time.

To add, Just shift one mantissa the difference between the exponents,
and add.

These should be implementable as inline code in gcc, or multiple word
instructions.

0 can be all exponents with 0, or with mantissa >0.5.
NAN can be all exponents greater than say 2^16.

Anyway, these 64 bits should have accuracy like 48 bits, but
it is much faster to split it in words on an ARM.

Kim0