🚀 go-pugleaf

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