powerpc fptask issue again

[Joel Sherrill]

Till Straumann wrote:
> 
> 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.

And in the old exceptions port (from memory), all tasks are FP
because of this.

> 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.

On lower end CPUs, the benefits are relatively greater
from integer only tasks and the odds of being able to
disable an FPU are low.  On the PPC or any other CPU
with FPU disable, I agree totally.

> 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.

Exactly and this is why the old exceptions model declared
that all tasks were FP.

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

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

What is the problem?  I think you might be referring to the
same thing Greg Menke did.  The FP context save/restore code
must protect itself and enable the FPU.  But if there is
an easy way to get this as a side-effect, be our guest. :)

> -- 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

-- 
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