home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!mtxinu!taniwha!paul
- From: paul@taniwha.UUCP (Paul Campbell)
- Newsgroups: comp.sys.m68k
- Subject: Re: problems with m68882
- Keywords: m68882
- Message-ID: <1264@taniwha.UUCP>
- Date: 9 Sep 92 21:32:14 GMT
- References: <219@F_HOME.ahwau.ahold.nl> <92Sep08.184615.11893@acs.ucalgary.ca>
- Organization: Taniwha Systems Design
- Lines: 31
-
- In article <92Sep08.184615.11893@acs.ucalgary.ca> norm@enel.ucalgary.ca (Norm Bartley) writes:
- >In article <219@F_HOME.ahwau.ahold.nl> leo@ontnix2.ahwau.ahold.nl (Leo Weppelman) writes:
-
- >>I am getting coprocessor protocol violations at random but especially
- >>when a lot of interrupts occur (i.e. during disk accesses).
- >
- >I have had similar problems on my Amiga while trying to add 68882
- >support to Amiga Minix. I followed the exact same procedure as you for
- >saving/restoring/initializing the 68882 context. I would get coprocessor
- >protocol violations at random -- a process might bomb immediately, or it
- >might run for a few seconds and then bomb.
-
- This is a common 68k/FPU problem - the CPU can take an interrupt while the
- FPU is halfway through an instruction - if your ISR can cause an FP instruction
- to occur (even if your compiler generates fmovem.l instructions with null masks
- in procedure headers) in an ISR or by causing a process switch, you have to
- save the FPU's state and clear it then restore it as you return from the
- interrupt.
-
- It's called a coprocessor protocol violation because the FPU thinks it's
- stalled halfway through an instruction and the CPU will feed it a new
- instruction before it's done the one it's working on
-
- Paul
-
-
- --
- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P
-
- "Most American's day to day experience of 'Family Values' is found in
- brightly colored fliers from such organisations as Target and K-Mart."
-