powerpc fptask issue again

[Till Straumann]

Joel Sherrill wrote:

> Till Straumann wrote:
> >
> > Hi.
> >
> > I'm sure this does not appear on this list for the first time.
> >
> > Can somebody explain to me why enabling deferred/lazy
> > floating point context save/restore (as is currently the default
> > for the Powerpc/new_exception_processing) and NOT
> > disabling MSR_FP for integer tasks (current behavior)
> > is assumed to be safe ???
>
> In general, if you have the capability to disable the
> FPU for integer only tasks, you should do it.  You have
> to be careful to honor this in interrupts and context
> switches.
>

I couldn't agree more. However, currently the FPU (on ppc)
is _never_ disabled. There is a comment stating that it is
left enabled because newlibc vfprintf (around '97) behaved
just like my task 'B', i.e. it is not modifying but merely
saving/restoring FP regs.

My point is:

1) _only_ do lazy FPcontext save/restore if you
   switch the FPU off for integer tasks otherwise
   there is a risk of corruption that goes undetected.

2) if there are integer tasks who push/pop the FPregs
   without modifying them, you can leave the FPU enabled
   _but_ FPContext must be saved/restored at every context
   switch.

Note that powerpc-rtems currently violates 1), i.e. it uses
lazy FPsave/restore but does not disable the FPU for integer
tasks!

One more interesting thing: if you do 1) you will discover that
threaddispatch.c is actually incorrect. PR/patch is in preparation

-- Till

>
> If you have hardware to help protect you, use it. :)
>
> > How about this scenario:
> >
> > 1) task A (FP) holds the FP engine, fpr3 is e.g. 0.0
> > 2) task B (integer) preempts A, stores fpr3 on the stack
> > 3) task C (FP) is scheduled and does a lazy FP context save for A.
> >     C sets fpr3 to 3.14159
> > 4) task C is blocked, task B gets the CPU again
> > 5) task B's routine that does the fpr push/pop operation
> >     returns, i.e. fpr3 is popped from the stack, now 0.0
> >     again.
> > 6) task C gets the CPU. It realizes that it still holds
> >     the FPU and does nothing. However, fpr3 is now 0.0
> >     BUMMER.
>
> In this scenario, task B has violated his "contract" to
> be integer only.  If you can detect this in HW, trap it.
> If not, then we just frown as the system freaks out.
>
> This seems like a reasonable mod -- make MSP_FP follow
> the task FP attribute.
>
> I am surprised Greg Menke hasn't replied yet.  He has recently
> spent some time doing this same thing on the MIPS. :)
>
> > Thanks
> >
> > -- Till
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985