powerpc fptask issue again

[Joel Sherrill]

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.

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