dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/19/89)
The following little program crashes an XT clone with an 8086/8087. The crash
seems to occur in the start-up code where the run-time library is trying to
determine the coprocessor type, and goes away if I single-step or if I
link in more library routines by referencing something like the NAG random
number generator. Can anyone suggest any fix for this?
external Eval, Cube
real*8 Cube,x
x = 1.0
x = Cube(x)
stop
end
c
subroutine Eval(Fn,N,X,Value)
real*8 Fn
integer N
real*8 X(N),Value
Value = Fn(N,X)
return
end
c
real*8 function Cube(X)
real*8 X
Cube = X**3
return
end
Duncan Murdochdmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/20/89)
In article <863@maytag.waterloo.edu> I wrote: > >The following little program crashes an XT clone with an 8086/8087. It turned out to be a bug in the run-time library routine __init80x87. It had the sequence FSTCW [BP-4] FNINIT MOV CX,01Eh LOOP in place What happens on an 8087 is that the FNINIT aborts the FSTCW instruction, and the control word never got stored. Later on a garbage control word was loaded and the system crashed. A fix that seems to work is to put the delay loop before the FNINIT. I'm not sure what the original programmer would have been thinking of writing it this way; the next instruction is an arithmetic one that is preceded by a WAIT anyways. To patch the library LLIBFOR7.LIB, search for the original bytes 9B D9 7E FC DB E3 B9 1E 00 E2 FE and replace them with 9B D9 7E FC ; no change B9 1E 00 ; line 3 above E2 FE ; line 4 above DB E3 ; line 2 above In my copy of the library the first 6 bytes of the original gave a unique search string. I'd guess it's safe to do the same patch on any other library; the original code would never make sense. Duncan Murdoch
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/20/89)
Whoops! As one correspondent pointed out, I forgot to say which version of Fortran had the bug in either the original report or my suggested patch. It's MS Fortran 5.0 that you have to watch out for. Duncan Murdoch
br0w+@andrew.cmu.edu (Bruno W. Repetto) (11/21/89)
Duncan Murdoch's message regarding a MS Fortran bug: >In article <863@maytag.waterloo.edu> I wrote: >> >>The following little program crashes an XT clone with an 8086/8087. > >It turned out to be a bug in the run-time library routine __init80x87. >It had the sequence > FSTCW [BP-4] > FNINIT > MOV CX,01Eh > LOOP in place >What happens on an 8087 is that the FNINIT aborts the FSTCW instruction, and >the control word never got stored. Later on a garbage control word was loaded >and the system crashed. A fix that seems to work is to put the delay loop >before the FNINIT. I'm not sure what the original programmer would have >been thinking of writing it this way; the next instruction is an arithmetic >one that is preceded by a WAIT anyways. > >To patch the library LLIBFOR7.LIB, search for the original bytes > > 9B D9 7E FC > DB E3 > B9 1E 00 > E2 FE > >and replace them with > > 9B D9 7E FC ; no change > B9 1E 00 ; line 3 above > E2 FE ; line 4 above > DB E3 ; line 2 above > >In my copy of the library the first 6 bytes of the original gave a unique search >string. I'd guess it's safe to do the same patch on any other library; the >original code would never make sense. > >Duncan Murdoch This is all ok, but: what version of MS Fortran are you talking about? Bruno Bruno Wiener Repetto Department of Operations Research Graduate School of Industrial Administration (GSIA) Carnegie-Mellon University Schenley Park Pittsburgh, PA 15213 GSIA Room 8b, x8730 [(412)CMU-8730] br0w+@andrew.cmu.edu