Light on PPC interrupt management requested

[joel at OARcorp.com (joel at OARcorp.com)]

On Tue, 9 Feb 1999, Thomas Doerfler wrote:

> Well I think there is one problem: If the context switch is modified 
> depending on the flags of the related tasks, then any 
> missconfiguration might lead to strange hidden errors. 

This has always been the case.  RTEMS tries to help in this regard by
turning off the FPU if possible so an exception will take place.

> In another mail, Joel stated that printf will access floating point 
> instructions, even if no float output is required. This means, if I 
> look at a given task code, find out it is NOT using float, (but some 
> printf's), and I start this task with task attribute "NOFLOAT", then 
> the context switch might take a shortcut, not to switch FPU context. 
> Although the FPU registers are touched in printf functions.

This type of behavior is scary.  Tony Bennett and I spent days debugging
the HPPA port because integer multiplies automatically used the FPU and we
were using "lazy FP saves".  

> I think the "easy-to-calculate" deterministic way for PPC context 
> switching would be to switch FPU context ALWAYS.

And this number is provided by tm26.

> The other proper solution is the one Eric Valette asked for: Only 
> switch FPU context, when neccesary. Even in that case, the "Worst 
> case context switch time" will be deterministic, although it will not 
> be used always....

This is a good technical solution and safe since the HW catches the
access.  It is likely that the exceeption handler can be not many more
instructions than a straight FP save/restore.

--joel