Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!Postmaster
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.unix.sysv386
Subject: Re: Math Co-Proc. usage
Message-ID: <9105081803.AA21692@iecc.cambridge.ma.us>
Date: 8 May 91 22:03:04 GMT
Sender: Postmaster@iecc.cambridge.ma.us
Organization: I.E.C.C.
Lines: 18
In-Reply-To: <455m21w164w@gantz.bowlgreen.oh.us>

The contents of the 387 are saved on demand as part of a process' context.
Since it is indeed slow to save and restore it (though there is so much
other gunk in the Unix process switch that slow is a relative term) there is
a special hack in the hardware.  Every time there is a context switch, the
387 context isn't saved, but the hardware sets a special "stale floating
state" bit.  The next time a process does any floating operation, there is a
trap to the kernel, so the kernel can save the context that is in the 387
and load up the appropriate one for the new process.  If it turns out that
it's the same process that was using the 387 before, the kernel need only
clear the stale bit and continue the process.

This means that if only two processes are using the 387, the floating
context need only be changed when one of those processes starts, and if only
one process is using the 387, there are no 387 saves or restores at all.

-- 
Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl