> Dave Daniels wrote:
> > In article <E14Xheb-0007Y8-00@chiark.greenend.org.uk>,
> >    Ben Harris <bjh21@netbsd.org> wrote:
> > > Did you compile it with -mhard-float?  Did you recompile libc (and libm)
> > > with -mhard-float as well?
> > 
> > I have tried compiling just the interpreter with -mhard-float and
> > that has done the trick! My test program now runs in 82 seconds
> > and so is clearly using the floating point hardware for the basic
> > arithmetic operators. Unfortunately it is not all good news as
> > 'PRINT COS(PI)' returns the result 3.14159265 and not -1. COS is
> > not the only function that returns the wrong result.
> 
> The reason might be that there are instructions like SIN/COS/TAN/LOG/EXP
> defined in the ARM floating point instruction set, but they have never been
> implemented in hardware, and have to be emulated even if there is a FPA
> present. (ARM does not recommend to use them anymore, as calling a function is
> cheaper than handling an exception and parsing the opcodes)
> 
> It might be that -mhard-float makes use of these instructions, and probably
> there is no FP emulator emulating them.

Nope, the compiler doesn't use them.  But -mhard-float changes the calling 
convention for floating point functions.  Code compiled -mhard-float 
expects a floating point result to be returned in a floating point 
register; code compiled -msoft-float expects it in r0(+r1 for doubles).  
So the problem is that you cannot link the system libraries into your 
program if you are expecting floating point results back.

The code I posted last night (for which there will be an update shortly to 
fix a few problems I've spotted) should enable you to compile your code 
with -msoft-float and still get much of the benefits of having the FPA 
fitted.  It works by replacing the low-level library calls with 
implementations that use the FPA to do the hard work.  This is 
significantly faster than doing it all in software.

R.