mikem@uhccux.uhcc.hawaii.edu (Mike Morton) (06/24/89)
MacsBug seems to have problems interrupting certain math-chip operations.
I run this LightspeedC program with 68881 code enabled:
main ()
{ register float a = 0, b = 0;
while (1)
a += b;
}
When I press the interrupt switch, I get:
Spurious Interrupt or Uninitialized Interrupt Vector at 003ED970.
*** MacsBug caused the exception ***
The code which crashes looks like this (comments are my own, natch):
TST.B -$071B(A5) ; have a math-chip installed?
BEQ.S *+12 ; no: skip
LEA -$023A(A5), A0 ; yes: find a place to...
FMOVEM FP0-FP7, (A0) ; ...store the math registers
*LEA -$0246(A5), A0 ; and a place for...
FMOVEM FPCR/FPSR/FPIAR, (A0) ; ...weird regs
The crash is at the starred location. At this point I usually get Bus
Errors, etc., if I try to continue.
LSC doesn't put a and b into registers unless I declare them double,
in which case the problem goes away. The code LSC emits for the
float case looks like:
l: FMOVE.S -4(A6), FP0
FADD.S -8(A6), FP0
FMOVE.S FP0, -8(A6)
BRA.S l
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?
Boring details: SE/30m 4Mb, System 6.0.3, Macsbug 6.1, no inits.
Ever try to find anagrams for "MacsBug"?
-- Mike Morton // P.O. Box 11378, Honolulu, HI 96828, (808) 676-6966 HST
Internet: mikem@uhccux.uhcc.hawaii.edu
(anagrams): Mr. Machine Tool; Ethical Mormon; Chosen Immortal; etc.{paul@taniwha.UUCP (Paul Campbell) (06/26/89)
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).
shebanow@Apple.COM (Andrew Shebanow) (06/29/89)
This is a known bug in MacsBug 6.0 (and 6.1). It should be fixed
in MacsBug 6.2. For the curious, the problem is indeed that
MacsBug does not do the FSAVE and FRESTORE inside of all of its
exception handlers.
Andrew Shebanow
Chief PUGHead
Andrew Shebanow, Amway Representative
Developer Technical Support, Apple Computer, Inc.
------------------------------------------------------------------------------
INTERNET: shebanow@apple.com
UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!shebanow