> 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:pdero...@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