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):
http://www.rtems.org/ml/rtems-users/2006/may/msg00040.htm Discussed Again in: http://www.rtems.org/ml/rtems-users/2009/september/msg00008.html 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? Regards, On Wed, Mar 5, 2014 at 2:26 PM, Sebastian Huber <sebastian.hu...@embedded-brains.de> 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 > > 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.hu...@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@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel