SPARC Floating Point Context

[Cláudio Silva]

I agree with your proposal. Detecting the fault immediately is very important.
An alternative approach would be to run all tasks with EF set. This
would enable integer tasks and libs to freely use FP registers. To
spare the memory overhead of allocating all tasks with a FP context,
only the FP tasks get their FP context saved.

Anyway, it should be documented very explicitly that interrupt
handlers, including any calls (libc, user handlers) they make, shall
be analyzed in search for accesses to FPU registers.

On Thu, Mar 6, 2014 at 8:54 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.