RES: AW: GCC SPARC FPU issue status

Wendell Pereira da Silva wendell.silva at compsisnet.com.br
Tue Sep 1 14:18:12 UTC 2009


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
>
>
>  
>




More information about the users mailing list