PowerPC FP handling weakness.

[Jay Kulpinski]

Sergei Organov wrote:
> 
> Hello,
> 
> Here is text from 'c/src/lib/libcpu/powerpc/new_exception_processing/cpu.c':
> 
> <BEGIN>
>   /*
>    *  The FP bit of the MSR should only be enabled if this is a floating
>    *  point task.  Unfortunately, the vfprintf_r routine in newlib
>    *  ends up pushing a floating point register regardless of whether or
>    *  not a floating point number is being printed.  Serious restructuring
>    *  of vfprintf.c will be required to avoid this behavior.  At this
>    *  time (7 July 1997), this restructuring is not being done.
>    */
> 

A while back I sent Joel a patch for vfprintf_r which convinced the
compiler not to use a floating point register unless a floating
point value is printed.  I think he incorporated it.

That does not remove the need for PPC_MSR_FP as floating point
instructions are needed in the context switch code to save and/or
load the floating point registers.  Without this, a floating point
unavailable exception is generated when attempting to switch to a 
floating point tast from a non-FP task.  

>   /*if ( is_fp ) */
>     the_context->msr |= PPC_MSR_FP;
> <END>
> 
> Here is define from 'c/src/lib/libcpu/powerpc/new_exception_processing/cpu.h':
> 
> #define CPU_USE_DEFERRED_FP_SWITCH       TRUE
> 
> I think that enabling FP bit in MSR for non-FP tasks is mistake. It even
> doesn't solve 'printf' problem when deferred FP context switch is used (that
> is turned on by default). Actually the comment in the code is right, but the
> conclusion is wrong. The fact that 'printf' always use FP means that it is a
> mistake to call 'printf' from FP task, and doesn't mean that FP bit should be
> set for non-FP tasks. The right thing to do is to disable FP in MSR for non-FP
> tasks and use 'iprintf' and friends instead of 'printf' in non-FP tasks, I
> believe.
> 
> Below is example of trouble calling 'printf' from non-FP task.
> 
> For simplicity let's consider a system that has only two tasks. Task1 is FP
> task. Task2 is non-FP task with lower priority. If deferred switch of FP
> context is used, then FP context will never be saved/restored in such
> system because Task1 owns FP context exclusively. The following scenario is
> then possible:
> 
> 1. Task1 runs using FP unit and then waits on some resource.
> 
> 2. Task2 runs and calls 'printf' that stores some FP register on the
>    stack. Let's call this register fp0.
> 
> 3. Task1 is awakened and continues to run. It changes value of fp0 and then
>    waits again on a resource.
> 
> 4. Task2 continues to run and restores old fp0 value from stack.
> 
> 5. Task1 is awakened and continues to run with clobbered value of fp0!
> 
> Did I convince you there is no reason to enable FP bit in MSR for non-FP
> tasks?
> 

No.

> Thanks in advance.
> 
> BR,
> Sergei Organov.