"Paul D. DeRocco" <pdero...@ix.netcom.com> writes: > > From: Christophe Coutand [mailto:ccout...@stmi.com] > > > > Thanks for the explanation. > > > > You are correct, eCos is making use of this mechanism in the i386 HAL: > > > > cdl_option CYGHWR_HAL_I386_FPU_SWITCH_LAZY { > > display "Use lazy FPU state switching" > > flavor bool > > default_value 1 > > > > description " > > This option enables lazy FPU state switching. > > The default behaviour for eCos is to save and > > restore FPU state on every thread > > switch, interrupt > > and exception. While simple and > > deterministic, this > > approach can be expensive if the FPU is > > not used by > > all threads. The alternative, enabled > > by this option, > > is to use hardware features that allow > > the FPU state > > of a thread to be left in the FPU after > > it has been > > descheduled, and to allow the state to > > be switched to > > a new thread only if it actually uses > > the FPU. Where > > only one or two threads use the FPU > > this can avoid a > > lot of unnecessary state switching." > > } > > Hmmm. It refers to thread switches, interrupts and exceptions. But what > about DSRs? A DSR isn't a thread, with a state that persists from one > invocation to another.
That part refers to the non-lazy option, when FPU state is saved alongside the normal CPU state. In that case I believe FP operations can be executed in DSRs, the combination of the kernel context save and compiler register save/restore should handle it correctly. However, with lazy switching turned on, FPU state is only saved and restored for thread contexts, and only when absolutely necessary. The additional complication of handling arbitrarily nested FP contexts was not thought worthwhile. So ISRs and DSRs cannot do FP operations. So the choice is either to slow down the whole system saving and restoring FPU state on every context switch, or avoid the FPU in ISRs and DSRs. Generally ISRs and DSRs should not be doing FP operations, they can be slow and non-deterministic. It makes much more sense to offload such calculations to a thread. DSRs should be fast and deterministic. If the code absolutely has to be in the DSR, perhaps the OP can look at re-writing the problem code in fixed point, or include sufficient FP emulation code to satisfy the function's requirements. Perhaps the combination of a pre-calculated lookup table and some runtime integer refinement might work. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss