SPARC Floating Point Context

Zandin Johan RUAG Johan.Zandin at
Wed Mar 5 15:16:57 UTC 2014

My guess is that this was done to minimize the timing impact of a interrupt, since you usually don't need to do any floating point operations in an interrupt handler anyway. But I don't remember from the top of my head if there is something stopping a SPARC RTEMS application developer from using floating point code in an interrupt handler, or if this constraint is properly documented.

Johan Zandin
Computer Engineer

SE-405 15 Göteborg · Sweden 
Tel. +46 31 735 41 47
johan.zandin at

>-----Original Message-----
>From: rtems-users-bounces at [mailto:rtems-users-
>bounces at] On Behalf Of Sebastian Huber
>Sent: onsdag den 5 mars 2014 15:26
>Subject: SPARC Floating Point Context
>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-users mailing list
>rtems-users at

More information about the users mailing list