AW: GCC SPARC FPU issue status

Detlev Schümann schuemann at ohb-system.de
Tue Sep 1 13:35:17 UTC 2009


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




More information about the users mailing list