This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: libm use in kernel


"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

> > From: Christophe Coutand [mailto:ccoutand@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]