gantzm@gantz.bowlgreen.oh.us (gantzm) (05/09/91)
Could someone with more experience then I have, please explain how a math co-proc. is handled under any System V os??? What I want to know is, if two tasks want to use a 387 is the math unit treated as a resource that gets locked and unlocked? If not is the data in the math co-proc. switched during a task switch, and if this is true isn't this slow!!!!! ---- gantzm@gantz.bowlgreen.oh.us --- Michael L. Gantz
johnl@iecc.cambridge.ma.us (John R. Levine) (05/09/91)
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!johnlurban@cbnewsl.att.com (john.urban) (05/09/91)
In article <455m21w164w@gantz.bowlgreen.oh.us> gantzm@gantz.bowlgreen.oh.us (gantzm) writes: > > Could someone with more experience then I have, please explain >how a math co-proc. is handled under any System V os??? What I want >to know is, if two tasks want to use a 387 is the math unit treated >as a resource that gets locked and unlocked? If not is the data >in the math co-proc. switched during a task switch, and if this is >true isn't this slow!!!!! Slow? Well maybe, however, if you don't have a 387 chip, the 80387 emulator (/etc/emulator) runs at about 2% of speed of a 387 chip. Thus is you have a little math intensive program that takes 35.7 seconds to run with a 80387 chip, it will take about 14 minutes with the emulator. The 80387 (or emulator) is only locked into the processes when it is running. When the process is swapped out, the 387 is free for the next process. Just like the 80386. When the kernel changes processes, the states/registers of both the 80386 and the 80387 are saved, so they can be restored when the original process is swapped back in. Sincerely, John Urban