briel@sctc.com (Marc Briel ) (03/13/90)
A question on the 68882 Floating Point Coprocessor: The manual states that FSAVE/FRESTORE must be performed on entry/exit for any exception or interrupt regardless of whether it if FPU related or not. Is this an absolute requirement or just an easy way to solve an otherwise complex problem? I have performance concerns and would like to avoid time consuming FSAVE/FRESTORE operations wherever possible. Does anyone know the specific cases where save/restore are absolutely required? Thank you in advance for any replies, Marc Briel Briel@sctc.com
rbt@cernvax.UUCP (roberto divia) (03/13/90)
In article <1990Mar12.222857.19372@sctc.com> briel@sctc.com (Marc Briel ) writes: >The manual states that FSAVE/FRESTORE must be performed on entry/exit >for any exception or interrupt regardless of whether it if FPU related >or not. Is this an absolute requirement or just an easy way to solve >an otherwise complex problem? > >I have performance concerns and would like to avoid time consuming My opininion is that the FSAVE/FRESTORE is needed only if the interrupt service routine/exception handler uses the coprocessor. Also, you are forced to reset the coprocessor if the exception handler will not execute a "clean" return. For "normal" interrupt service routines, the coprocessor can be ignored. -- | Roberto Divia` | Love at first sight is one of the greatest | | ============= | labor-saving devices the world has ever seen | | CERN : European Laboratory for Particle Physics, 1211 Geneva 23 | | Switzerland (CH) |
paul@taniwha.UUCP (Paul Campbell) (03/14/90)
In article <1990Mar12.222857.19372@sctc.com> briel@sctc.com (Marc Briel ) writes: >A question on the 68882 Floating Point Coprocessor: >The manual states that FSAVE/FRESTORE must be performed on entry/exit >for any exception or interrupt regardless of whether it if FPU related >or not. Is this an absolute requirement or just an easy way to solve >an otherwise complex problem? >I have performance concerns and would like to avoid time consuming >FSAVE/FRESTORE operations wherever possible. Does anyone know the >specific cases where save/restore are absolutely required? Basicly you must restore the internal state if you are going to execute any FP coprocessor instructions (except for FSAVE/FRESTORE) even the FMOVEM instructions your C compiler may put in procedure prologs and epilogs (some compilers put these in with empty masks even if you use no FP in your program). The usual way of telling you have a problem is when you see coprocessor protocol violation traps. Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Remember 1990? that was the year the US government funded a Communist election victory in Nicaragua and claimed it a victory for Capitalism.
kdq@demott.COM (Kevin D. Quitt) (03/14/90)
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.
kdq
--
Kevin D. Quitt Manager, Software Development
DeMott Electronics Co. VOICE (818) 988-4975
14707 Keswick St. FAX (818) 997-1190
Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last
34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com
"Next time, Jack, write a God-damned memo!" - Jack Ryanbruce@heather.pooh.com (Bruce Robertson) (03/15/90)
> The manual states that FSAVE/FRESTORE must be performed on entry/exit > for any exception or interrupt regardless of whether it if FPU related > or not. Is this an absolute requirement or just an easy way to solve > an otherwise complex problem? That paragraph has been removed from Rev. 2 of the 68881/68882 manual (the one with the white cover). -- Bruce Robertson Hundred Acre Software, Reno, NV Domain: bruce@pooh.com UUCP: ...!uunet!tahoe.unr.edu!heather!bruce
jvkelley@watcgl.waterloo.edu (Jeff Kelley) (03/15/90)
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. 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? -- Jeff Kelley National Research Council of Canada, Ottawa uunet!watmath!watcgl!jvkelley tel: (613) 990-5924
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/15/90)
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
kdq@demott.COM (Kevin D. Quitt) (03/15/90)
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. > >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? In theory, you're correct. In practice, it's a little hard to guarantee someone won't slip a FP instruction in. kdq -- Kevin D. Quitt Manager, Software Development DeMott Electronics Co. VOICE (818) 988-4975 14707 Keswick St. FAX (818) 997-1190 Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last 34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com "Next time, Jack, write a God-damned memo!" - Jack Ryan - Hunt for Red Oct.
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/16/90)
In article <73@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: ]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. ]>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? ] In theory, you're correct. In practice, it's a little hard to ]guarantee someone won't slip a FP instruction in. Correct, although I think most OS processes don't require FP instructions, so at least they are candidates. -- 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