Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!mtxinu!taniwha!paul
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MacsBug crash when interrupting 68881 operations
Keywords: MacsBug 68881 float math-chip
Message-ID: <386@taniwha.UUCP>
Date: 25 Jun 89 21:08:54 GMT
References: <4168@uhccux.uhcc.hawaii.edu>
Reply-To: paul@taniwha.UUCP (Paul Campbell)
Organization: Taniwha Systems Design, Oakland
Lines: 64

In article <4168@uhccux.uhcc.hawaii.edu> mikem@uhccux.uhcc.hawaii.edu (Mike Morton) writes:
>
>When I press the interrupt switch, I get:
>    Spurious Interrupt or Uninitialized Interrupt Vector at 003ED970.
>    *** MacsBug caused the exception ***
>

> ....

>My guess is that when there's a lot of traffic between the math chip
>and memory, interrupts can leave the chip in a state which doesn't
>like FMOVEMs.  Any comments from MacsBug folks at Apple?  From '881
>hackers?

Boy does this sound familiar ..... when a 680X0 (X = 2,3} takes an interrupt
it stops processing between instructions (ie it completes one and jumps
to the interrupt vector before executing the next), not so the floating
point chips, (remember they can actually be doing their thing while the
main integer processor is executing other things), the FP chips, at the time
of an interrupt can be HALFWAY THROUGH AN OPERATION, if this is the case it
is the job of the interrupt handler to save all the internal context of
the FPU if it wants to use the FPU before returning to the interrupted code,
if it doesn't the FPU gives an exception when the next FPU instruction is
started (instructions for saving/restoring state etc don't count) from
memory I think that it is a 'Coprocessor Protocol Violation' exception (13).

So what's happening here? You press the button, MacsBug takes the NMI and
doesn't save the chip's state, or let it run its current instruction to
completion. Then it reads the FP registers from the chip so it can show
them to you, because the chip isn't in a safe state it causes another trap
(the one you see), at this point MacsBug's whole world probably falls apart ...

How can it be fixed? The first thing that can be done is MacsBug can
save and restore the chips state on its way in/out of its faulting entry/exit
points. This at least would stop the nasty traps, however its probably not
a good idea for a debugger, ideally all the registers ought to be in a sane
state from the point of view of the person actually using it (ie you shouldn't
have to see the half done instruction). This means that at the entry point
MacsBug has to get the FPU to run the instruction to completion, how does it do
this? It recognizes the half-done state, and at this point it saves the SR
of the stack, sets the trace bit on the on-stack copy and returns from the 
interrupt, one integer instruction is completed, at the same time the FPU's
completion is done before the resulting trace trap. Of course this means that
at NMI an extra integer instruction is executed - but then if you can push that button with such timing that you can get it to stop at a particular instruction
you are probably not human :-) ie it doesn't matter.

OK - so I didn't solve your problem, but then let's hope that the MacsBug
people are listening (and the MacOS people for when they do preemptive
multitasking, and 3rd parties who might be tempted to do things that use
the FPU from interrupt service routines etc etc), if not could some kind soul
from Apple please pass this on ...


	thanks

	Paul



-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: D3213
"Free Market": n. (colloq.) a primitive fertility goddess worshipped by an
obscure cult in the late 20th C. It's chief priest 'Dow Jones' was eventually
lynched by an enraged populace during an economic downturn (early 21st C).