RES: AW: GCC SPARC FPU issue status

Tue Sep 1 14:28:41 UTC 2009

Hi,

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
>  
>
Note that this would change the behaviour of multiple platforms.

Daniel

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