On 2014-03-06 08:54, Sebastian Huber wrote:
Hello,
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):
http://www.rtems.org/ml/rtems-users/2006/may/msg00040.htm
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:
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?
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.
Advantages:
* 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.
Disadvantages:
* 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.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
