Perhaps it is possible to run the Coprocessor in another Task and
trigger an exception exactly when the current task tries to use
the cp. This way You only would have to switch the cp context,
if more than one task actually uses the cp.
[
What I mean is s.th. like this (i'm not sure, wether it can
be done with the 80x87:
* When You switch between processes, just 'lock' the
80x87, that an exception occurs, the next time, it
is used.
* If an exception of this kind occurs, ask, wether the context
in the 80x87 belongs to the task, which triggered the exception
(the currently running task). If yes, just unlock it and resume.
If no, the save the context. Load the float point context of the
current task (if any) and resume.
I'd like to call that 'lazy coprocessor context switch'. It amounts
to not switching/saving/restoring the coprocessor context,
if no or just one process uses the coprocessor, and else
the context needs only switched, (n-1) times per scheduling
, if n processes use the coprocessor. A lot of procs don't use it.
]
Regards -- Markus
-------------------------------------------------------------
On Fri, 30 Jul 1999, Eric J. Korpela wrote:
> > ELKS doesn't yet support floating point. The bcc compiler libraries have
> > support for 32 bit floating point though. All ELKS float support will have
> > to come from bcc primarily, unless you're talking about OS support of math
> > coprocessors...
>
> On machines with coprocessors the the coprocessor state needs to be saved
> with the rest of the process context. Isn't being done now. Problem is it
> makes the context bigger and the swap longer. How long is an FSAVE on an
> 8087?
>
> Eric
>
