SPARC Floating Point Context
Zandin Johan RUAG
Johan.Zandin at ruag.com
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.
RUAG Space AB
SE-405 15 Göteborg · Sweden
Tel. +46 31 735 41 47
johan.zandin at ruag.com
>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
>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 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
More information about the users