csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (05/25/90)
harrison@necssd.NEC.COM (Mark Harrison) writes: >> microprocessor revelations, '286, '386 (2, right?), and now I wonder >> -- will there be a bug in the '486? >You've already lost. There was a bug when a trig function followed >a sequence of integer instructions. Does anybody still have a copy >of the article that described this? Is Intel unique in having bugs >in their newly released chips? Motorola's 68000 had a kind of quirk that caused a clr command to first read the addressed location and then clear it. This led to numerous difficulties when clearing I/O registers. This one, however, has always been documented by Motorola, so it's more a feature than a bug. Subsequent 680x0s perform a clr operation as God intended. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Stolen from unknown.) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
raob@mullian.ee.mu.oz.au (richard oxbrow) (05/26/90)
In article <2813@medusa.informatik.uni-erlangen.de> csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: >harrison@necssd.NEC.COM (Mark Harrison) writes: >>> microprocessor revelations, '286, '386 (2, right?), and now I wonder >>> -- will there be a bug in the '486? > >>You've already lost. There was a bug when a trig function followed >>a sequence of integer instructions. Does anybody still have a copy >>of the article that described this? Is Intel unique in having bugs >>in their newly released chips? > IEEE Spectrum, April 1990 (pages 10-11) gives a short article about Intel's problems with the i486. In addition to the trig bug (see above) which Compaq Computer Corp. (Houston TX) found, another bug was found in a prototype EISA bus setup. In this case a "A particular sequence of bus instructions from the i486 would trigger the error, causing a prototype extended-industry-standard-architecture (EISA) chip to hang up. The problem would not occur in products using other architectures, such as the ISA, or in the products using the production EISA chip." (Extracted from the afore mentioned IEEE article) The article is worth a quick look (they claim other bugs have been found and how the EISA problem found its way into the papers) richard .. #ps Does anyone want to shed some light on the stories about manufacture of the VIPER cpu (UK) <The viper cpu was designed to be mathematically-logically correct>, but did all the prototypes work ? ;-) And while we are on it what about some of the (mil) 1750 A chips ! or whatever the americans put in their cruise missiles. richard oxbrow | ee eng, uni of melbourne |Internet raob@mullian.ee.mu.OZ.AU parkville 3052 australia | fax +[061][03]344 6678 |Uunet ..!uunet!munnari!mullian!raob
carr@gandalf.UUCP (Dave Carr) (05/29/90)
> > You've already lost. There was a bug when a trig function followed > a sequence of integer instructions. Does anybody still have a copy > of the article that described this? Is Intel unique in having bugs > in their newly released chips? > -- > Mark Harrison harrison@necssd.NEC.COM Ever use the WD2511? True, it's only a microcoded controller, but so full of bugs that some X.25 networks won't certify any boxes with one in it! And, if they couldn't get it right the first time, then they came out with the WD2511A, the WD2512, and then the WD2512A. It's been 5 years, and we still don't have a bug free chip. Intel may not be the best at releasing bug free silicon, but there are certainly worse vendors out there. -- Dave Carr | carr@e.gandalf.ca | If you don't know where Gandalf Data Limited | TEL (613) 723-6500 | you are going, you will Nepean, Ontario, Canada | FAX (613) 226-1717 | never get there.
cooper@hpsrad.enet.dec.com (cooper in the shadows) (06/28/90)
In article <2813@medusa.informatik.uni-erlangen.de>, csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes... >Motorola's 68000 had a kind of quirk that caused a clr command to >first read the addressed location and then clear it. This led >to numerous difficulties when clearing I/O registers. This one, >however, has always been documented by Motorola, so it's more >a feature than a bug. Subsequent 680x0s perform a clr operation >as God intended. This was not unique to the 68000. The clr instruction on certain PDP-11'S used to do the same thing. If you wanted to clear an IO register you had to write a zero out rather than do a clr location. Also there have been innumerable (ie i don't know how many) machies that didn't even have a clear instruction but had you xor the location with itself. The 360/370s where like this. shades