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-ow...@ecos.sourceware.org
[mailto:ecos-discuss-ow...@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: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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
