sparc erc32 FPU confusion

[Kenneth J. Peters]

Thanks for the clear explanation, Jiri. I will adjust my sparc.h 
according to the patch; I'm not sure I have an easy way to determine 
if any other parts of the patch seem to be missing.

A separate email follows with another issue I may have found in the erc32 BSP.

Ken Peters
Ken.Peters at jpl.nasa.gov

At 10:51 AM +0200 5/31/06, Jiri Gaisler wrote:
>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 1.27.4.1 (current 
>>version) as follows:
>>
>>>-CPU_CFLAGS = -mcpu=cypress
>>>+CPU_CFLAGS = -mcpu=cypress -msoft-float
>>>
>>>  # optimize flag: typically -0, could use -O4 or -fast
>>>  # -O4 is ok for RTEMS
>>>-CFLAGS_OPTIMIZE_V=-O4
>>>+CFLAGS_OPTIMIZE_V=-O2
>>>
>>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-1.0.2/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
>>>-#else
>>>  #define SPARC_HAS_FPU 1
>>>-#endif
>>>
>>>  #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 (1.6.4.1) 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?
>
>Yes.
>
>>
>>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.
>
>Jiri Gaisler.
>
>Gaisler Research.