about SPARC_HAS_FPU = 1

pierre kestener pierre.kestener at cea.fr
Fri Oct 17 13:33:59 UTC 2008


Aleix Conchillo Flaqué a écrit :
> On Fri, Oct 17, 2008 at 13:41, Ralf Corsepius <ralf.corsepius at rtems.org> wrote:
>   
>> On Fri, 2008-10-17 at 12:37 +0200, pierre kestener wrote:
>>     
>>> Hello,
>>>
>>> i have read some messages in this list from Jiri Gaisler in March 2008 :
>>> http://www.rtems.com/ml/rtems-users/2008/march/msg00272.html
>>>
>>> stating that one should always have
>>> #define SPARC_HAS_FPU 1
>>>
>>> It seems that this patch has not been integrated in mainline RTEMS sources.
>>> Is there a reason or has this just been forgotten ?
>>>       
>> I don't recall the details, but to me this patch is simply wrong.
>>
>>     
>
> Which one? The one I proposed initially (before Jiri answers) is
> wrong, yes. I think Pierre is referring to the one from Jiri where
> SPARCH_HAS_FPU is always 1.
>
> Aleix
>   

Yes, i am referring to the statement
#define SPARC_HAS_FPU 1

My understanding is that if the kernel is compiled with -msoft-float 
then we have
#define SPARC_HAS_FPU 0 (from the header file 
cpukit/score/cpu/sparc/rtems/score/sparc.h)
and then both symbols CPU_HARDWARE_FP and CPU_SOFTWARE_FP are FALSE.

So now I don't understand how a user application using floating point 
computations (compiled without -msoft-float and with attribute 
RTEMS_FLOATING_POINT) can work on a target with a FPU.
Actually, i have such an application which does not work if I do not 
block SPARC_HAS_FPU to 1.
The same application compiled with -msoft-float is of course working well.

To me it looks like, a single flag (-msoft-float) triggers two things 
simultaneously:
- does the hardware has FPU ?
- do we want floating point emulation ?

Am I missing something ?

Pierre.




More information about the users mailing list