Path: utzoo!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!crdgw1!sungod!davidsen From: davidsen@sungod.crd.ge.com (ody) Newsgroups: comp.arch Subject: Re: Claimed bug in 80286 Message-ID: <1596@crdgw1.crd.ge.com> Date: 9 Aug 89 13:08:13 GMT References: <1717@brwa.inmos.co.uk> <15963@vail.ICO.ISC.COM> <852@scaup.cl.cam.ac.uk> <1473@crdgw1.crd.ge.com> Sender: news@crdgw1.crd.ge.com Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: General Electric Corp. R&D, Schenectady, NY Lines: 32 In article <1473@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (richard a hammond) writes: | 1) Intel did not claim that there were NO chips in the field with the bug! | Just that NEW chips didn't have the bug. Pretty shady attitude if you | ask me. This means that if you're writing software for a '286 then you | need to know about the bug, as Martyn said, people assume it is the | your software's fault. | | 2) As pointed out in the elided part of the article and Dick Dunn's comments, | the bug has been known for a while by some people, but I assume that it | isn't documented by Intel? My recollection is that the bug was documented by Intel at the time they were selling the chip, and that they gave up a fix which was 4-5 gates (or so, 1 chip did it as I recall). | | 3) Seems fair to say that the bug cost them time - whether the project would | have been late for other reasons or not. Seems fair to say that they didn't have the bug list which matched their CPU. It undoubtedly did cost them time. | | 4) Is there a way to get a list of known (and suspected?) bugs for exisiting | chips. As a compiler writer it would be useful to know what to avoid. | Note that compiler writers often aren't in the hardware design area that | might have long known about a bug. Intel has been resonably good about that, at least if you're a larger organization than a garage. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me