SPARC Floating Point Context
sebastian.huber at embedded-brains.de
Thu Mar 6 08:54:01 UTC 2014
On 2014-03-06 08:54, Sebastian Huber wrote:
> On 2014-03-05 17:35, Cláudio Silva wrote:
>> 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):
> yes, this is why I ask. I think the current implementation is extremely
> dangerous. The GCC at least on ARM and PowerPC is pretty aggressive in its use
> of floating point registers for integer only tasks. For the SPARC, I don't know.
>> 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?
> My proposal is this:
> 1. Disable the FPU on interrupt entry, before the high-level code is called.
> 2. Compile RTEMS with -msoft-float.
> 3. Remove the FPU context from the thread context.
> 4. In an interrupt initiated thread dispatch check the PSR_EF bit and in this
> case save/restore the floating point registers.
> 5. Add a BSP implemented method which tells the RTEMS kernel if the processor
> has an FPU. If it has an FPU enable the PSR_EF bit in
> _CPU_Context_initialize() for floating point tasks.
> * In case the GCC uses the FPU in interrupt handlers, you get a trap and know
> right now what is wrong and not later if FPU register corruption is noticed.
> * Interrupt entry is fast since no FPU context needs to be saved.
> * One library set for a BSP supports FP/non-FP applications.
> * Works on SMP.
> * No deferred floating point context switch.
There is one problem with the -msoft-float for RTEMS approach. At link time a
multi-lib must be selected to provide the libc, libm, libgcc, etc. In case the
floating-point enabled variant is selected, then RTEMS will use e.g. memcpy()
compiled with floating-points enabled. So it is possible that the integer only
RTEMS library will use floating-point instructions indirectly via library calls.
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.
More information about the users