AW: GCC SPARC FPU issue status
schuemann at ohb-system.de
Tue Sep 1 13:35:17 UTC 2009
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.
> -----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
> > 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
> > 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
> 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
> 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
> takes time to save the FP state and increases the context switch
> 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
> 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? Shouldnt the 3 BSPs have
> > the same behavior? Shouldnt 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.
> > (Im 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
More information about the users