Intel - hiding the unpleasant truths

That's an article on a 486 bug, but the Intel's practice of hiding CPU bugs from developers still goes on today. When the Pentium first came out, I discovered one of its "secret" errata almost instantly with a little instruction set test case that dated back to the 80286 chip. It had to do with the exception behavior of the BOUND instruction in protected mode. Pentium behaved differently than its docs claimed and 286/386/486 silicon actually operated. I reported it and it was never listed in the Pentium errata. Trivially reproducible too, a few instructions could induce it, and it happened every time.

I never trusted the bastards after that. Over the years I grew that little CPU validation test suite and I suppose its up around 100KLOC of mixed C and assembler code these days, but I haven't updated it with all the new junk that appeared after the Pentium. CPU's are damned complicated things, but testing to make sure the documented behaviors of things, like exceptions, actually works - particularly when the behavior dated back to the 80286 shouldn't be too hard. Yet apparently it is...

DDJ

I immediately reported this bug to Intel, along with a software work around. And even though I had regular access to the Intel486 errata documents, I never saw this bug listed in the errata. This omission was in spite of my submission of source code which faithfully reproduced this bug. I have no idea whether or not Intel ever fixed this bug, as it never was listed in the Intel486 errata, and I had a sufficient work-around. I found another bug in the Intel386 and Intel486 which had suffered the same fate -- it never showed up in the errata documents, even though it could be faithfully reproduced with source code I had provided. And now that the Pentium errata is public, I always look at it as though there are many bugs which are never listed, even though their founders have reported them, and spent many man-hours debugging them.