Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!crdgw1!sunroof!hammondr
From: hammondr@sunroof.crd.ge.com (richard a hammond)
Newsgroups: comp.arch
Subject: Re: Claimed bug in 80286
Message-ID: <1473@crdgw1.crd.ge.com>
Date: 3 Aug 89 13:25:23 GMT
References: <1717@brwa.inmos.co.uk> <15963@vail.ICO.ISC.COM> <852@scaup.cl.cam.ac.uk>
Sender: news@crdgw1.crd.ge.com
Reply-To: hammondr@sunroof.crd.ge.com (richard a hammond)
Organization: General Electric Corp. R&D, Schenectady, NY
Lines: 30

In article <852@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>"Computing", another UK trade rag, treats this somewhat more rationally. ...
>From the issue of 27 July '89, page >>6<<:
>...
>  Ian Wilson, product marketting manager at Intel said Alsys was
>using a non-Intel emulator.  `Alsys is running a 286 which is over 
>4 years old.  Errors were cured years ago.'  
>...

Note several things:

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?

3) Seems fair to say that the bug cost them time - whether the project would
   have been late for other reasons or not.

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.

Rich Hammond