SPARC Floating Point Context

Cláudio Silva claudiodcsilva at
Wed Mar 5 16:35:13 UTC 2014

Hello Sebastian,

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> wrote:
> Hello,
> I just noticed that the SPARC floating point unit (FPU) support is a bit
> odd:
> 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
> registers.
> 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
> PGP     : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at

More information about the users mailing list