RES: AW: GCC SPARC FPU issue status

Jiri Gaisler jiri at gaisler.com
Tue Sep 1 14:35:36 UTC 2009


This was my initial though as well. After discussing it
with Daniel the original patch might be the best one
if we want to push it to the main gcc distribution. The other
targets (e.g. intel) might not want to disable the use of float
registers in this case.

Jiri.

Wendell Pereira da Silva wrote:
> Hi,
> 
> Nice patch.
> 
> What if the flag "int flag_ffloat_int_mode = 1" instead of "int flag_ffloat_int_mode = 0" by
> default? So, updating in the makefiles is not need.
> 
> Regards,
> 
> 
> Wendell Pereira da Silva
> 
> COMPSIS... Computadores e Sistemas Ind. e Com. Ltda. Aerospace Systems Site:
> www.compsisnet.com.br E-mail: wendell.silva at compsis.com.br Phone: +55 12-2139-3966, ext. 977
> 
> 
> 
> 
> -----Mensagem original----- De: rtems-users-bounces at rtems.org
> [mailto:rtems-users-bounces at rtems.org] Em nome de Daniel Hellstrom Enviada em: terça-feira, 1 de
> setembro de 2009 11:04 Para: Detlev Schümann Cc: rtems-users at rtems.org Assunto: Re: AW: GCC SPARC
> FPU issue status
> 
> Hi,
> 
> In the Aeroflex Gaisler toolchain for RTEMS we have added the attached patch, written by Konrad
> Eisele (konrad at gaisler.com), to avoid the problem. The patch adds an optional -ffloat_int_mode
> flag to GCC which disables the strange GCC Floating point behaviour. Function calls with more
> arguments than the argument registers and the low globals are fixed.
> 
> The attached patch works for GCC 4.3.3. We are not GCC gurus, I hope that someone could rewrite
> this patch if needed and insert it into GCC main line in a clean way.
> 
> Please let me know what you think about this patch.
> 
> Best Regards, Daniel Hellstrom Aeroflex Gaisler
> 
> 
> 
> Detlev Schümann wrote:
> 
>> Hi,
>> 
>> I would say that the RTEMS needs to be compiled with -msoft-float. Also all ISRs should be
>> compiled with -msoft-float. If the ISR and the RTEMS kernel does not make use of any floating
>> point operations, this should not be a problem with lib variants.
>> 
>> The application code can still be compiled without -msoft-float, especially when it relies on
>> using the FPU due to performance reasons. The task in my applications have to be flagged RTEMS
>> FP of course.
>> 
>> That's the way I want to do it at OHB.
>> 
>> Regards
>> 
>> Detlev
>> 
>> 
>> 
>>> -----Ursprüngliche Nachricht----- Von: rtems-users-bounces at rtems.org [mailto:rtems-users- 
>>> bounces at rtems.org] Im Auftrag von Joel Sherrill Gesendet: Dienstag, 1. September 2009 15:07 
>>> An: Manuel Coutinho Cc: rtems-users at rtems.org Betreff: Re: GCC SPARC FPU issue status
>>> 
>>> Manuel Coutinho wrote:
>>> 
>>> 
>>>> Hi
>>>> 
>>>> 
>>>> 
>>>> Was checking some mails exchanged in this mailing list a while ago (2006)
>>>> (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html) and would like to know if the
>>>> issue concerning GCC and SPARC floating point registers is now solved or not. Does anybody
>>>> know the status of this issue? Is there a bug in GCC bugzilla so that we can track this? 
>>>> try to find but with no luck :(
>>>> 
>>>> 
>>>> 
>>>> Briefly, the problem, as far as I understood, occurs when a function receives multiple
>>>> arguments: GCC might store some arguments on FPU registers, which could cause all sort of
>>>> problems, like an invalid
>>>> 
>>>> 
>>> FPU
>>> 
>>> 
>>>> trap, or an erroneous result on a thread that uses FPU (because the register was changed).
>>>> 
>>>> This problem could be solved by compiling RTEMS with -msoft-float
>>>> 
>>>> 
>>> flag
>>> 
>>> 
>>>> and the application without this flag (for the sections that want to use floating point).
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> This is fundamentally an incorrect thing to do and why this solution has never been merged.
>>> You should never never never mix multilib variants in the same executable.
>>> 
>>> If GCC is generating FPU instructions in unexpected places, then there are two solutions:
>>> 
>>> + Fix GCC.  This is (in general) a cross target issue which may end up having to be fixed in
>>> a target specific manner.  I don't know of a PR or anyone who is interested in working on
>>> this.  It is an issue on at least the PowerPC as well and that hasn't attracted any coders
>>> willing to address it.
>>> 
>>> + Make all tasks in RTEMS FP.  We have resisted this solution because it takes time to save
>>> the FP state and increases the context switch time. But on PowerPC's with FPU, this is how
>>> this problem is solved.
>>> 
>>> So the proper solution until GCC is fixed is to turn on the cpu.h define that says all tasks
>>> are floating point.
>>> 
>>> 
>>>> It also seams that ERC32 has a different behavior than Leon2 and Leon3: for Leon2 and
>>>> Leon3, RTEMS does not save/restore hardware FPU during a context switch. Is this correct?
>>>> Shouldn't the 3 BSPs have the same behavior? Shouldn't leon2 and leon3 save/restore the FPU
>>>>  hardware during a context switch?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> I don't see how they could be different.  They use the same context switch code. Unless you
>>> are using some patches we won't merge.
>>> 
>>> 
>>>> (I'm looking at RTEMS 4.8.0)
>>>> 
>>>> 
>>>> 
>>>> Thanks in advance
>>>> 
>>>> Kind regards
>>>> 
>>>> Manuel Coutinho
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> -- 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
>>> 
>>> 
>>> _______________________________________________ rtems-users mailing list 
>>> rtems-users at rtems.org http://www.rtems.org/mailman/listinfo/rtems-users
>>> 
>>> 
>> _______________________________________________ rtems-users mailing list rtems-users at rtems.org 
>> http://www.rtems.org/mailman/listinfo/rtems-users
>> 
>> 
>> 
>> 
> 
> _______________________________________________ rtems-users mailing list rtems-users at rtems.org 
> http://www.rtems.org/mailman/listinfo/rtems-users
> 
> 



More information about the users mailing list