RES: about SPARC_HAS_FPU = 1

[Joel Sherrill]

Fabrício de Novaes Kucinskis wrote:
> Maybe I'm missing something, but I looked at my erc32.cfg file (RTEMS
> 4.8.1), and there is no -msoft-float flag on CPU_FLAGS. Only "CPU_FLAGS =
> -mcpu=cypress".
>
> So I have two questions:
>
> 1) If I understood it correctly, currently (I'm not talking about a future
> patch here) we should set the -msoft-float flag to avoid the use of the
> floating point registers in integer operations by gcc. Is it right?
>
>   
Yes but it also avoids the use of the FPU when you do have
FPU instructions and can lead to trying to link FPU and
non-FPU libraries.
> 2) Reading a 2006 discussion
> [http://www.rtems.com/ml/rtems-users/2006/may/msg00007.html] I noticed that
> the flag was on the 1.27.4.1 version of erc32.cfg (RTENS 4.6.6). Why it was
> removed?
>
>   
Because this did not follow the pattern of how this problem
has been addressed on other ports.  The best solution is
to address it in GCC as Jiri says below.  A somewhat
acceptable solution is to have all tasks always be FP if the
hardware has an FPU.  But on the ERC32, this is a HUGE
performance hit.


Most importantly though, no one demonstrated the situation(s)
where gcc would  emit fp instructions for integer only code.
The FPU is supposed to be disabled on integer only tasks so
a fault would occur.  I don't recall anyone reporting that occurring.

This is technically a concern on any CPU with an FPU for integer
only tasks.  We wait until it is a demonstrated problem before
making all tasks FP.

At this point, Jiri has proven it is an issue by identifying the
place in GCC that does it and by fixing it, he has implemented
the optimal solution from an RTEMS perspective.
> Fabrício.
>
>
>
> -----Mensagem original-----
> De: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] Em
> nome de Jiri Gaisler
> Enviada em: sábado, 25 de outubro de 2008 18:54
> Para: rtems-users at rtems.com
> Assunto: Re: about SPARC_HAS_FPU = 1
>
>
> There has been some new development on this issue. We have
> made a small patch to gcc to avoid emitting FPU instructions for
> integer code. This was actually done in the frame of using gcc for a
> SPARC/LEON port of VxWorks-6.x, but is applicable to RTEMS as well.
>
> I would suggest that we include this patch to the rtems-gcc tool chain,
> and then we can compile the kernel using the regular (multi-lib) flags
> rather than always using -msoft-float.
>
>   
Can you post the patch?  It would be good to file a GCC PR
with this and attach the patch.  Then Ralf can get it in the
RPMs and we can push to get it reviewed and into the official
GCC source.
> Jiri.
>
>   
>>> 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.
>>>
>>>       
>> [snip]
>>
>> As Jiri said, SPARC_HAS_FPU should be always set, and this is
>> currently not true. I guess someone should change/review that.
>>
>> Aleix
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985