SPARC Floating Point Context

[Zandin Johan RUAG]

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

RUAG Space AB
SE-405 15 Göteborg · Sweden 
Tel. +46 31 735 41 47
johan.zandin at ruag.com
www.ruag.se



>-----Original Message-----
>From: rtems-users-bounces at rtems.org [mailto:rtems-users-
>bounces at rtems.org] On Behalf Of Sebastian Huber
>Sent: onsdag den 5 mars 2014 15:26
>To: RTEMS; RTEMS
>Subject: SPARC Floating Point Context
>
>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
>
>http://git.rtems.org/rtems/tree/cpukit/score/cpu/sparc/rtems/score/cpu.h#
>n551
>
>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 embedded-brains.de
>PGP     : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>_______________________________________________
>rtems-users mailing list
>rtems-users at rtems.org
>http://www.rtems.org/mailman/listinfo/rtems-users