johnw@astroatc.UUCP (John F. Wardale) (07/29/87)
I couple weeks ago, I asked about the infamous Intel 386 multiply bug... I got one reply which said: > From: -Mark Johnson {decvax,ucbvax,ihnp4}!decwrl!mips!mark > > It's sort of general knowlege among > Santa Clara Valley VLSI designers that the i386 muitiply problem is > ***very*** specifically tied to 2nd-order details of the exact polygon > layout of this circuit AND to the exact values of wafer processing > parameters used by Intel in fabricating the i386. > > the 386 is a pipelined machine with instruction prefetch; the multiplier's > operands can come from a variety of places and the result can be > routed to several different destinations, DEPENDING UPON THE STATE > OF THE MACHINE WHEN THE MULTIPLY BEGINS AND FINISHES. So the multiply > bug __may__ only appear when e.g. the multiplicand comes from a > register and the multiplier comes from memory and the result is > simultaneously written into a register and "bypassed" as an operand > into a subsequent ALU operation. There may also be some requirement > for pagefaults (or lack thereof) to make the multiply bug visible. I know that the bug ONLY happens in real-386 mode (many run in 286 emulation mode) Are the specifics really as involved as Mark suggests? Does anyone REALLY KNOW, or is the world in as much darkness as I am? Should I request the "test/demo" program and try to grok it? (I don't speak Intel assembler, but this may be the only way!) Can anyone shed any more light on this? We're involved in designing a large computer thru extensive use of simulation, as I'm sure Intel did. I have no ill feelings regarding Intel in this matter! I'm interested in the following: * i386 multiply bug details -- do all the failing parts ALWAYS fail the same way, or is it a transient failure * why the simulations missed it (tricky 2nd order effect???) * pitfalls of simulations (in general) John W - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Name: John F. Wardale UUCP: ... {seismo | harvard | ihnp4} !uwvax!astroatc!johnw arpa: astroatc!johnw@rsch.wisc.edu snail: 5800 Cottage Gr. Rd. ;;; Madison WI 53716 audio: 608-221-9001 eXt 110 To err is human, to really foul up world news requires the net!
tim@ism780c.UUCP (Tim Smith) (07/31/87)
In article <376@astroatc.UUCP> johnw@astroatc.UUCP (John F. Wardale) writes:
< Does anyone REALLY KNOW, or is the world in as much darkness as I am?
< Should I request the "test/demo" program and try to grok it? (I don't
< speak Intel assembler, but this may be the only way!)
It won't be too hard to grok. I have seen the program. I deleted my copy
after determining that all 386s I use don't have the problem, so I can't
get you the actual numbers, but the program was very simple.
It just multiplied two specific numbers and looked at the answer. If the
answer was wrong, it printed a message telling you that you have the
bug. If the answer was right, then you didn't have the bug.
--
Tim Smith, Knowledgian {sdcrdcf,seismo}!ism780c!timpeter@sugar.UUCP (Peter da Silva) (08/06/87)
> It just multiplied two specific numbers and looked at the answer. If the > answer was wrong, it printed a message telling you that you have the > bug. If the answer was right, then you didn't have the bug. Except that the bug is voltage, temperature, and frequency dependent. You might have the bug some times and not others, depending on how many cards you have plugged in, whether you're running in 6 MHZ compatibility mode, and whether it's summer or winter. If the answer is right, you may not have the bug... -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)