AW: GCC SPARC FPU issue status

Tue Sep 1 14:11:28 UTC 2009

I would suggest that the flag is enabled by default, by changing

+int flag_ffloat_int_mode = 0;

to

+int flag_ffloat_int_mode = 1;

In this way, we would not need to update the make scripts for SPARC.

Jiri.

Daniel Hellstrom wrote:
> 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