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.
This is a welcome new addition to the Intel Secrets home page. As new and interesting things are discovered about the P6, this is where you can look to read the latest P6 information. Right now, the information is rather sparse, as the P6 has just been released.
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.
