Light on PPC interrupt management requested

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

This discussion highlights the VERY hard real-time school of thought.  Any
variation that detracts from the ability to predct worst-case execution
times is bad when analyzing a hard real-time system.  Many factors are
hard to control -- caching has had entire articles written on it.  The
bottom line is caching makes your execution times unpredictable.

RTEMS can be used in systems where performance is the goal or where hard
real-time predictability is critical.  Force all tasks to be FP (see the
score/cpu macro for this one), disable lazy FP save/restore, and disable
caching.  It won't be a fast system but it will be predictable. :)


On Tue, 9 Feb 1999, VALETTE Eric wrote:

> >>>>> "Juan" == Juan Zamorano Flores <jzamora at avellano.datsi.fi.upm.es> writes:
> 
> >> 
>    
> Juan>    The above is not a benefit for a real time OS: Real time computing is not
> Juan> fast computing but predictable computing (J. Stankovic Missconceptions
> Juan> about Real-Time computing).
> 
> OK. Do you use a data cache. No I guess...
> 
> Juan>    In order to avoid context switching overload that approach will overload
> Juan> the estimate computation time of the task which uses the FPU. I think that
> Juan> approach raises the indeterminist of the OS services.
> 
> No as you can always add the time to the context swicth and the interrupt
> management but will get more throuput than what the pessimistic figures 
> will give.
> 
> Juan>    So I think that the simple approach (to save FPU register in context
> Juan> switch for a FP task) will produce better RT behaviour.
> 
> This is false...
> 
> --  eric
>