Re: [ECOS] On demand FP context switch major problem.

[Nick Garnett <nickg at cygnus dot co dot uk>]

Sergei Organov <osv@javad.ru> writes:

> I agree with your (random) thoughts. However for me it seems that on-demand
> context switch is incompatible with ability to use of the floating point in
> ISRs/DSRs. I actually even didn't start to try to implement this capability
> when on-demand FP context switch is configured, but it seems that if
> implemented, then *any* interrupt could clear FP bit in MSR, and thus the fact 
> that scheduler is locked in the DSR code doesn't help :-(
>

The management of the memory for storing nested FP contexts is a
little involved but not impossible. The main problem is the management
of the FP enable bit. I think that the general approach here would be
to disable the FPU on interrupt entry, take FPU traps as normal during
interrupt processing and on interrupt return decide whether the FPU
had been used, and if not, clear the FP bit. The interrupt's FPU
context at this point is redundant, so it can just be overwritten.

> Is the capability to use FP in ISRs/DSRs significant enough to deny on-demand
> context switch implementation on the PowerPC?

I think we can expect writers of ISRs and DSRs to be reasonably
disciplined and to avoid any FP code. So banning FP use in these
contexts is not a major problem. The main area of worry is in the
alarm handler routines. At present these are called from a DSR and may
contain any user code. We can impose the same restrictions on these
functions as on DSRs, but it would be nice to lift it one day. One
approach to this is to move alarm handling to a proper thread
context, but this is still in the future.


-- 
Nick Garnett
Cygnus Solutions, a Red Hat Company
Cambridge, UK