sparc erc32 FPU confusion
jiri at gaisler.com
Wed May 31 08:51:52 UTC 2006
Kenneth J. Peters wrote:
> I noticed that running some of the tests (sp19, tm26) on RTEMS 4.6.6
> erc32 that floating point was not tested. Digging in, I see that
> make/custom/erc32.cfg changed from 1.27 to 188.8.131.52 (current version) as
>> -CPU_CFLAGS = -mcpu=cypress
>> +CPU_CFLAGS = -mcpu=cypress -msoft-float
>> # optimize flag: typically -0, could use -O4 or -fast
>> # -O4 is ok for RTEMS
> and this seems to be from the PR827 patch file. However, that same patch
> file has:
>> diff -Naurb rtems-4.6.4/cpukit/score/cpu/sparc/rtems/score/sparc.h
>> --- rtems-4.6.4/cpukit/score/cpu/sparc/rtems/score/sparc.h
>> 2003-09-04 20:47:40.000000000 +0200
>> +++ rtems-4.6.4-1.0.2/cpukit/score/cpu/sparc/rtems/score/sparc.h
>> 2005-09-12 10:56:58.000000000 +0200
>> @@ -66,11 +66,7 @@
>> -#if defined(_SOFT_FLOAT)
>> -#define SPARC_HAS_FPU 0
>> #define SPARC_HAS_FPU 1
>> #if SPARC_HAS_FPU
>> #define CPU_MODEL_NAME "w/FPU"
> and this change is NOT reflected in either the 4.6.6 release version of
> sparc.h (184.108.40.206) or the current CVS version of sparc.h (1.12)!
> QUESTION 1: Should sparc.h be changed to always define SPARC_HAS_FPU
> according to the patch?
> QUESTION 2: If so, are there other parts of the patch that have not made
> it into the current RTEMS package? I have not tried to figure this out yet.
I provided a patch to Joel with modifications of the FPU
handling for SPARC targets. It was my understanding that
it was fully merged. Joel ..?
> QUESTION 3: Why the change to less optimization and -msoft-float? I
> don't see any explanation. Were there bugs found? Or can I optimize
> fully and ditch soft-float? If so, should this be changed back in the
> CVS tree and releases?
Newer versions of gcc can generate FPU instructions even if
no floating point operations are made in the C code. The
compiler uses FPU registers for load/store operations of
integers, if it is running out of available integer registers.
Tasks that are not marked as FPU tasks could therefore trap
unless they are compiled with lower optimization effort,
OR with -msoft-float.
We have modified the kernel to always contain FPU context
save/restore code (in assembler), and the decision to
activate this code is made at run-time after probing if
an FPU is present and enabled. The kernel can (and must)
therefore always be compiled with -msoft-float to avoid
spurious FPU instructions due to gcc optimizations. If
your application uses the FPU, these parts should be
compiled without -msoft-float. If you share code between
FPU tasks and non-FPU tasks, you must decrease the
optimization level to avoid unexpected FPU instructions
as explained above.
More information about the users