|
On 04/11/1997, "Dan" contacted me about
the existence of a floating point bug in the Intel Pentium Pro processor.
After writing some assembly language source code, I confirmed that the
behavior of Pentium II and Pentium Pro is inconsistent with the processors
of prior generations. I also discovered that the Dan-0411 bug is inconsistent
with the IEEE floating point standards and printed Intel documentation.
Read this article, download the source code, and make your own determination.
As I went searching high and low for P6 opcodes, I
kept coming across people from Intel saying that there were only two new
opcodes in the P6. So I tried and I tried to count up the opcodes that
I know about, to see if 1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1
+1 = 2. No matter how I tried to accumulate it, CMOV + FCMOVB + FCMOVE
+ FCMOVBE + FCMOVU + FCMOVNB + FCMOVNE + FCMOVNBE + FCMOVNU + FCOMI +
FCOMIP + FUCOMI + FUCOMIP + RDPMC + INT01 + SALC + UD2 didn't add up to
2. Now I see the FDIV bug in a completely different way.
Most people never knew that the Pentium Processor
was going to implement 36-bit addressing, and 2-Mbyte pages. As far as
I know, these features were implemented in beta silicon, but scrapped
for production. Well, they're back on the Pentium Pro Processor, with
some other page mode extensions.
This collection of opcodes was compiled many years
ago. In some cases, links are provided to source code which proves the
behavior described within. Descriptions and source code are provided for
an undocumented form of AAM and AAD. Other instructions discussed are
SALC (also known as SETALC), INT01 (also known as ICEBP) including Pentium
and P6 information, UMOV, and LOADALL.
It seems like a common theme in this web page, that
Intel has been hiding things. I know you're terribly disapointed in their
behavior. And believe me, they are terribly disappointed in my web page.
But once again, I've got some news about undocumented registers that you
can access with ordinary software (all you need is an ancient Intel386).
In this case, TR4 and TR5 are the source of my blabbering. Read this,
and see if you already knew it.
I know that you find it difficult to believe that
Intel hasn't documented everything in their processors. And just when
you began to accept this reality, somebody comes along and tells you that
Intel hid undocumented behavior in DR7. Even though most of this information
only applies to the Intel386 and Intel486, it is interesting none-the-less,
and migrated to the Pentium in a documented, but undocumented form.
How many times have you seen somebody ask about writing
an algorithm to determine the size of the prefetch queue? I've seen it
a lot. In fact, one book wrote an article on the subject, provided source
code, but acknowledged that writing an accurate algorithm was a little
more elusive than he had thought. This article will shed some light on
the elusivity of determining the size of the prefetch queue, and provide
source code which works (on the Intel386).
Bug, bugs, and more bugs. One day I decided to sit
down and write an Intel486 internal cache test. I was sick and tired of
looking at the feeble tests in the BIOS I was working with, so I thought
I'd write a more robust version. Much to my surprise, the test began crashing
my Intel486. I put it on the ICE, and this is what I found.
Back when the Intel486 was in its infancy, I found
an interesting bug in the Intel386. When I called my Intel representative,
he politely took the information, and I never heard back from him. After
weeks, I called him, and he told me that the Intel engineers had been
unable to reproduce the bug (even though I gave him the source code which
*ALWAYS* demonstrated the bug). So I called him a few weeks later, and
he said there was no interest within Intel to fix a bug on a processor
which was near obsolescence (the Intel386). Then I politely mentioned
that the bug also existed on their new flagship Intel486 processor. And
what do you know? I had a herd of Intel engineers out to see me within
a couple of days.
|
