PowerPC FP handling weakness.

[Sergei Organov]

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

  /*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?

Thanks in advance.

BR,
Sergei Organov.