Wrong results with hardware FP

[jarekl]

When I compile my code with

Code: Select all

        USE_OPT +=  -mthumb -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16

I get completely wrong results. Example,

Code: Select all

  mlaFL = (float)sqrt((float)10.0f);
  mlaFL = (float)sqrt(mlaFL);
  mlaFL = (float)sqrt(mlaFL);
  mlaFL = (float)sqrt(mlaFL);
  mlaFL = (float)sqrt(mlaFL);
  mlaFL = (float)sqrt(mlaFL);

Returns 3.16227 when using softfp the results are correct.
I'm using the gnu-arm toolchain https://launchpad.net/gcc-arm-embedded which is supposed to have support for hardware-fp.
The compiler issues a library call to sqrt, not the assembler instruction. How does one make it to issue the assembler instruction?

I'v spent days on this. Tried the summon toolchain, x86_64 version of the gcc-arm toolchain, and finally the i386-version distributed by
launchpad. Any help is really appreciated.

[Giovanni]

It is possible that complex functions like sqrt are not implemented as single flu instructions so a library call is generated. Libraries should be compiled to use the fpu anyway.

Giovanni

[jarekl]

It is possible that complex functions like sqrt are not implemented as single flu instructions so a library call is generated. Libraries should be compiled to use the fpu anyway.

Giovanni

I will have to look into the library question, but how come the result only reflects the first call (sqrt(10)) and not the remaining calls are ignored?

I added this code because the application in question returns completely wrong results when using hard-fp and I just wanted to see early if hardware floating point is working correctly or not.

[Giovanni]

I know the FPU is enabled and working because the scheduler is able to save/restore the FPU registers. Probably this is more a compiler-related issue.

Note that the FPU only supports single floats (32 bits), if you use float/double types then you are using an sw implementation.

Giovanni

[jarekl]

I know the FPU is enabled and working because the scheduler is able to save/restore the FPU registers. Probably this is more a compiler-related issue.

Note that the FPU only supports single floats (32 bits), if you use float/double types then you are using an sw implementation.

Giovanni

Yes, I know. My guess is that libm in newlib is not compiled with hard-fp. There is an option in the configure script for newlib (--enable-newlib-hw-fp) which is not enabled in the build-toolchain.sh-script. My attempt to rebuild the toolchain with --enable-newlib-hw-fp fails due to tex-related issued.
I will probably skip it altogether and try CMSIS because I will need it anyway. Thanks.