Dr. Dobb's Journal
Undocumented Corner
Intel
Inside --
The Errata Series
Productivity
Enhancements
and Programming Tricks
Intel
Secrets, Bugs and
Undocumented Opcodes
Intel Data
Sheets and
Programming Manuals
Dan-0411: Pentium II and Pentium Pro Floating Point Bug
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.
New P6 OpCodes
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.
Paging Extensions for the Pentium Pro Processor
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.
Collection of undocumented opcodes
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.
Move to and from Special Registers
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.
Undocumented bits in DR7
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.
Prefetch Queue
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).
Intel486 TR4 Bug
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.
Failure of Math Coprocessor to Trigger #GP Exception
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.