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


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."
	}

Christophe

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Paul D.
DeRocco
Sent: 15. november 2010 21:59
To: 'eCos Discuss'
Subject: RE: [ECOS] Re: libm use in kernel

> 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


--
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]