GCC SPARC FPU issue status

[Joel Sherrill]

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