Fortran divide check crashes interactive '386
Heiko Blume
src at scuzzy.in-berlin.de
Thu Jan 3 23:42:45 AEST 1991
buhrt at sawmill.uucp (Jeffery A Buhrt) writes:
>>[signal handling stuff]
>Should work ... kind of...
>as long as you are not on a '386 (as the orignal article ask).
>The above code is very correct and works fine on all systems that I know
>of except a 386/387 system.
oh, well. at least it solves the original problem, that the
signal wasn't catched after the first occurence :-)
>The problem is probably not so much one divide by zero as it is
>8 and 9 (the 387 stack is 8 deap), after eight divide by zero calls
>the 387 stack is full and the next (or later) 387 call will die.
>I do NOT have ISC and can't say if maybe the user->kernel switch after the
>code exits doesn't reset his 387 stack (I assume if the system does
>panic it would not be an emulator doing it).
i tried your fpedie on interactive 2.2.1 without a 387:
eval_fpe called
eval_fpe called
eval_fpe called
eval_fpe called
eval_fpe called
eval_fpe called
eval_fpe called
eval_fpe called
quit_fpe() not called in EvalAll() (STACK TRASHED)
IOT trap (core dumped)
not a panic at least. the #define I386 failed because there is no
struct fpusave in the header files. i kludged around a bit with _fpstate
but got only segmentation faults. anyway, the <ieeefp.h> says
"When a signal handler catches a FPE, it will have a freshly initialized
coprocessor (really?). [...] it gets a single parameter of type struct
_fpustackframe. [...] By modifying it, the state of the
coprocessor (and emulator?) can be changed upon return to the main task."
since i don't know sh*t about the 387 innards i can't investigate this,
but it sounds like the right way to try.
--
Heiko Blume <-+-> src at scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
public source archive [HST V.42bis]:
scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
uucp scuzzy!/src/README /your/home
More information about the Comp.unix.programmer
mailing list