RE: [ECOS] Re: libm use in kernel

["Paul D. DeRocco" <pderocco at ix dot netcom dot com>]

> From: Christophe Coutand
> 
> What you are mentioning about 
> deferring context swapping until a FP instruction is 
> completed is puzzling me. Does not all HW handle this? I will 
> check that for the processor architecture I use.

Going all the way back to the 286, the x86 chips have decoupled the FP
context from the rest of the machine context, under the assumption that most
code doesn't use FP, so context switches could be much faster if they didn't
include the FP context. They accomplished this by having a TS (task
switched) bit in the MSW (machine status word), which is automatically set
whenever the hardware TR (task register) is changed, and which generates a
fault if an attempt is made to execute an FP instruction while TS is set.
This gives the OS the opportunity to ask, "Is the FP context owned by the
currently executing task?" and if the answer is yes, simply clear the TS bit
and return to the program. Only if the answer is no, would it have to save
the FP context and swap in the one for the current task. This makes task
switching (thread switching) much faster for the common case in which no
thread or only one thread is doing any FP operations.

So if the eCos x86 HAL relies on this mechanism, but only does it for thread
switches, not DSR entry/exit, then DSR code that uses FP would have to
explicitly save the FP state, reinitialize it, use the FP, and then restore
the FP state before exiting. It's entirely possible, though, that eCos
doesn't do any of this at all, and merely always includes the FP state as
part of the thread state, in which case none of this would be an issue.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss