[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sparc erc32 FPU confusion
- Date: Wed, 31 May 2006 09:38:33 -0700
- From: Kenneth.J.Peters at jpl.nasa.gov (Kenneth J. Peters)
- Subject: sparc erc32 FPU confusion
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 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 220.127.116.11 (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
>>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
>>>2003-09-04 20:47:40.000000000 +0200
>>>2005-09-12 10:56:58.000000000 +0200
>>>@@ -66,11 +66,7 @@
>>>-#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 (18.104.22.168) or the current CVS version of sparc.h
>>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.