Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.sys.m68k
Subject: Re: 68882 Exception Handling
Keywords: 68882, exceptions, floating point
Message-ID: <682@ssp11.idca.tds.philips.nl>
Date: 15 Mar 90 08:25:35 GMT
References: <1641@cernvax.UUCP> <68@demott.COM> <13789@watcgl.waterloo.edu>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 36

In article <13789@watcgl.waterloo.edu> jvkelley@watcgl.waterloo.edu (Jeff Kelley) writes:
>In article <68@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes:
>>
>>    You must also use FSAVE/FRESTORE if, as a result of your activity in
>>the interrupt routine, a different process will be running than the one
>>when you entered. 
So generally speaking you only need to FSAVE/FRESTORE when a process switch
occurs, regardless whether this is due to normal scheduling, interrupt,
changing some process priority etc.

>Is this still the case if the "different process" will not be using
>the fp coprocessor?  That is, if we assume the operating system knows
>which processes will use the coprocessor and which will not, is it
>possible to perform an FSAVE/FRESTORE only when context switches
>occur (directly or indirectly) between processes using the coprocessor?
Yes this is correct. I know at least one OS (on a MC68020/MC68881) which
behaves like this. It remembers who is the owner of the MC68881.
There are 4 cases:
1. curr proc doesn't use FP, new proc doesn't use FP: no need to FSAVE/FRESTORE
2. curr proc uses FP,        new proc doesn't use FP: no need to FSAVE/FRESTORE
3. curr proc uses FP,        new proc uses FP       : always     FSAVE/FRESTORE
4. curr proc doesn't use FP, new proc uses FP       : 2 possibilities:
      a. new proc is already owner of FP: no need to FSAVE/FRESTORE
      b. new proc is not     owner of FP: always     FSAVE/FRESTORE
         (note that in this case the FSAVE is to be performed on the stack or
          in the process structure of the owner of the FP, NOT the curr proc)

The benefit is of course in cases 1 2 and 4a. But note also that due to the
delayed FSAVE/FRESTORE in case 4b it is possible that an IDLE state is saved
rather than a BUSY state, which in fact is also quite a win in the FSAVE and
next FRESTORE when the process becomes active again.
-- 
Dolf Grunbauer          Tel: +31 55 433233  Internet dolf@idca.tds.philips.nl
Philips Telecommunication and Data Systems  UUCP ....!mcvax!philapd!dolf
Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands         n   n   n
It's a pity my .signature is too small to show you my solution of  a + b = c