SPARC Floating Point Context
claudiodcsilva at gmail.com
Wed Mar 5 16:35:13 UTC 2014
Regarding this issue, there was also a old problem where "Newer
versions of gcc can generate FPU instructions even if
no floating point operations are made in the C code" (Paraphrasing Jiri):
Discussed Again in:
The threads includes other discussions about FP usage in SPARC/RTEMS.
I don't know if this is still applicable, but it is information that
has been circulating between SPARC/RTEMS users. Anyway the proposed
solution was that RTEMS should always be compiled with soft-float or
all tasks must be FP.
My only comment regarding saving/restoring the FPU context in every
interrupt is the performance penalty. How would you do it? Save it on
Executing Thread FPU context and then skip the save part if a Context
Switch is necessary? Further extend the ISF?
On Wed, Mar 5, 2014 at 2:26 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> I just noticed that the SPARC floating point unit (FPU) support is a bit
> 1. the context switch saves and restores all 32 floating point registers
> (%f0 up to %f31) and the FSR
> 2. the interrupt entry/exit doesn't save/restore the floating point
> Since we use the System V ABI, this makes no sense. Here all floating point
> registers are volatile.
> The SPARC V8 trap entry sequence doesn't disable the FPU via the PSR_EF bit.
> So it seems that interrupt handler using the FPU can destroy the FPU context
> of the interrupted thread?
> For a System V ABI conforming implementation it should be:
> 1. the interrupt entry/exit must save/restore the floating point registers
> to/from the stack of the interrupted thread
> 2. nothing more
> What was the reason for the existing implementation?
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the users