Why do you need a FAQ?
This compilation of frequently asked questions, is more than
just answers to your questions. This compilation is also a
rebuttal to all of the accusations hurled my way by the obvious
sources, but also from people that obviously haven't read a
single word of any article on my web site.
Mission statement
The Intel Secrets home page is
dedicated to providing information about the Intel Architecture
processors. Most of the information concerns productivity
enhancement, and not Intel's Secrets. The Intel Secrets articles
are the culmination of research I started many years ago, and
continue to do. Contrary to what one might perceive from reading
some of these pages, I don't hate Intel, nor do I even fault them
for keeping any information secret (it's their right). I publish
this material because I have just as much right to disclose it,
as Intel has in keeping it secret. I believe some of this
material can be invaluable to those engaged in research projects,
and wishing to investigate the degree of current processor
compatibilities. As new information becomes available, I will
continue to update these pages.
My views on transferring NDA material
If you have information which you would like see posted here,
feel free to email me. Do not email me
with confidential information which you may be privy to. Do not
send me a copy of Appendix H. To do so would be unethical, and
most likely illegal. However, if you disagree with Intel's policy
of withholding information which could be useful to you (like
that in Appendix H), or you would like to make that determination
for yourself (instead of Intel telling you that you don't need
it), email
Intel and tell them what you think.
My views on using undocumented
processor behavior
If you use any of the information from these pages, you do so
at your own risk. Remember that Intel has kept this information
secret for a reason; and the reason wasn't just to frustrate you
(though sometimes I wonder). I always discourage the
incorporation of undocumented behavior into an application's
source code. This is a very bad idea, and you should never do it.
I only provide these pages to publicize information which should
have been public -- in the first place.
Why are you disclosing NDA
material?
There are two ways to look at the information on these web
pages:
- Either you believe that knowledge itself is proprietary,
or
- You believe that the media which contains the knowledge
is proprietary.
Let me explain. If the knowledge itself is a trade secret,
then once you reverse-engineer something, you are automatically
bound by non-disclosure. This is obviously ludicrous. Therefore
it is the media which contains the knowledge which is
proprietary. If the media is illegally transferred from one party
to another, then that would be a violation of NDA.
As another example, consider the following: Years ago, you
were subject to an NDA agreement with Intel, and had access to
some proprietary Intel documents. Years ago, when you quit your
job, you returned the proprietary documents, and never had access
to them again. You can't remember what was included, or excluded
from those documents. But someday, you discover how some
undocumented feature of the microprocessor behaves, and you
publish it. As it turns out, this feature was in those documents,
and Intel decides to sue you for breach of NDA. Is their lawsuit
legitimate, or harassment? Their lawsuit can only be legitimate
if the knowledge itself is proprietary, and not the means which
you discovered it.
A final example. As above, you had an NDA with Intel years
ago, but revoked that relationship when you quit your job.
Intel's view is that you can never disclose that information, as
you were permanently bound by NDA from disclosing it. Later you
discover that the information bound by NDA is in a data sheet
from another unrelated Intel microprocessor. You decide to write
a magazine article. Intel sues you, citing breach of NDA. Their
lawsuit is only legitimate if the knowledge is bound by NDA, not
the means by which you obtained the knowledge.
In conclusion. I've never signed an Intel NDA in my life. I
have never seen Appendix H in my life - not even an illegitimate
copy of it. I do not believe that knowledge itself is
proprietary. Therefore, I'm not bound by Intel NDA, and am free
to publish whatever I wish.
Why are you disclosing Intel trade secrets?
What am I doing? Many people think that I dedicate this site
to disclosing Intel trade secrets. This is not true. There is not
a single piece of ill-gotten material on this web site. In fact,
very little of this material has anything to do with Intel
secrets at all! Of all the material on this web site, less than
10% has anything to do with Intel Secrets. If you look very
closely, this web site has a few major categories of information:
- Books and magazine articles. This section includes
article reprints, articles I've written, and books and
reference material which you might have a hard time
finding elsewhere on the Internet.
- New P6 opcodes. When it comes to this subject,
I've heard it all. I've had a few sources from Intel (I
believe two, to be exact) contact me and were very concerned
about these articles. One of those sources acknowledged
that my publishing of advance P6 information was the
source of most concern within Intel regarding my web
site. I've also had people send me email and flatly
accuse me of illegally disclosing this information in a
breach of my Intel NDA (he made the incorrect assumption
that I had an Intel NDA on the P6). What this guy didn't
realize (because he hadn't read a single article on my
web site), and the Intel representatives didn't realize
is that Intel was giving the information away on their P6
CD-ROM - to anybody that wanted it, without NDA, and for
FREE! There was nothing secret about it. So again, no
Intel Secrets in this section.
- Undocumented opcodes. There are six undocumented
opcodes discussed in this section, and in reality only
two of them are truly undocumented. More people have read
me the riot act on this subject, than I care to think
about. Most people defend Intel on the grounds that they
kept these opcodes secrets because they hadn't been fully
tested. Think again, pal, and read this…
AAM and AAD have been in existence since the 8086 and
were documented. What most don't realize that AAM and AAD are
both one-byte opcodes, with its second byte as its operand. OK,
so Intel didn't test them well enough to release information on
them. I can accept that story for the 8086 and 8088. But what
about the 80186, 80286, Intel386 and Intel486? Should I also
believe the same story for the next four generations of
processors? Not until the Pentium, did Intel document the
existence of the second-byte operand. Even though the second
operand is now documented, I include these articles because I
don't assume that everybody has the most current Pentium
documentation, nor do I assume that everybody noticed the two
sentences in the Pentium documentation that mentions this
heretofore undocumented use.
SALC has also been existence since the 8086. Should I
also believe it wasn't tested well enough to release its
description (regardless of its blatant simplicity)? OK, I'll give
Intel the benefit of the doubt on the 8086/8088. But what about
the 80186, 80286, Intel386, Intel486, and Pentium? Should I
really believe that Intel hasn't tested this instruction by now?
If I did, what would that say about their competence? (More on
that later.) The P6 CD-ROM, implies that this instruction will be
fully documented in the P6 documentation.
ICEBP. Truly one of the most useful opcodes I've ever
come across. This little gem has saved me tens, maybe hundreds of
hours of development time. Like SALC, the P6 CDROM indicates this
opcode will be documented on P6.
UMOV. Completely useless to anybody, except those
developing an 80386 or 80486 in-circuit-emulator.
LOADALL. My magazine article was the first to crack the
386 LOADALL story, over 4 years ago (written nearly 5 years ago).
So in reality, there isn't much here that is truly
undocumented. Four out of six of these opcodes are either
documented, or to be documented soon. So that leaves two
undocumented opcodes, one of which is useless to anybody that
isn't designing an ICE, and the other which is so complicated
that it took 15-pages of Intel (confidential) information to
describe (for the 80286, that is).
- Advanced programming techniques. Most people don't
know half of this stuff. This is the culmination of many
years of my experience in the computer industry. This
knowledge can profoundly make a person more productive,
if they not only know it, but fully comprehend it.
Nothing discussed in these sections is an Intel
secret.
- Undocumented processor behavior. These are hardly
design artifacts. Somebody went to great pain to design
and implement these pieces of the processor. I'm sure the
designers would not want their work being called a bug,
or design artifact. This category only boasts very few
articles (but could include many more):
- Microprocessor bugs. This is hardly the windfall
of bugs of the processor which you might have expected.
In fact, it only dominates a few articles.
- MR BIOS mirror home page. What can I say, this has
nothing to do with undocumented processor behavior.
Why are you breaking the law?
Can you believe it, some guy emailed me and tried to tell me
that reverse engineering was against the law. I don't know what
country he lived in, but he certainly didn't have a grip on US
laws. In fact, he said that ever since the 8086 was introduced in
1978, reverse engineering Intel processors has been against the
law. If I didn't believe him, I could just go to the Intel FTP
site, and check out their copyright notice. (He obviously didn't
understand the lack of relationship between copyright laws and
reverse engineering.) But I complied with his request and looked
in vain for the document he alluded to. After searching in vain,
I return his email and asked him to kindly point me to the Intel
copyright notice that indicated reverse engineering was illegal.
He never responded. (Things like this happen all of the time,
when I ask for proof, they never return my email.)
Why do you hate Intel?
I don't hate Intel. Some people are very confused. They think
that simply because I have a web page called "Intel
Secrets" that I hate Intel. I do disagree with many of
Intel's business practices. I disagree with their method of
cornering the market (which is most likely illegal too). I
disagree with their strong-arm tactics of forcing all of their
best customers to buy only from Intel, or they would be put out
of business. I disagree with their strong-arm tactics of going
into a well-known independent software developer's office and
telling him he had better abandon his $300,000/year product and
work for Intel, or they would put him out of business in six
months.
Were you fired from Intel?
No. I've never worked for Intel. Therefore I'm not some
disgruntled ex-Intel employee, out for revenge. Besides, just
think for a minute, and you'll realize why such a suggestion is
totally illogical. If I had worked for Intel and was now
disclosing flaws in their microprocessors, they could sue me for
a breach of contract which I would have signed when I started
working for them. In 1991 I was verbally offered a job at Intel.
I turned them down because their "total compensation
package" (which includes bonuses, profit sharing,
sabbatical, vacation, and employer 401k contributions) couldn't
even match my current base salary. Then early in 1995 a friend at
VLSI told me that Intel had called him, and wanted to hire me.
Did he know where I could be located? He declined their
invitation to help them out.
Why do you think Intel is part of a
massive cover-up to hide details of their architecture?
People ask me this all of the time. Somehow they think I'm
some kind of conspiracy nut. I am (how did they know that?), but
that has nothing to do with the Intel Secrets home page. There is
no doubt in my mind that Intel intentionally prints
misinformation in their manuals. This is a common business
practice to protect yourself against copyright violation. I
have absolutely nothing against Intel for doing this.
However, just because I understand it, and even condone it,
doesn't mean I shouldn't try and find out those intentional
pieces of misinformation and publish them. Consider these
examples:
- Suppose someone you know had seen advanced copies of a
new Intel microprocessor programmer's reference manual.
In that manual, they describe how to use some of the new
features in their new microprocessor. Most importantly
they describe the side effects of using those new
features. Six months later when the official manual is
released, this person notices that the description of the
new feature is omitted, but is available via
non-disclosure agreement. But those side effects
mentioned are very relevant to previous processor
compatibility, and must be mentioned in the manual. Close
inspection of the manual reveals that the above-mentioned
side effects aren't described in the same manner as they
were in the pre-release copy of the manual. By comparing
a word-for-word description of the side effects, it is
clear that the text is the same exact text, but with the
two most important sentences omitted. Ironically, the
omission of those two sentences turns the compatibility
statement into false information. What do you believe?
The inclusion of those two sentences would reveal
information which they've reserved for non-disclosure
agreements, but the omission of the sentences makes the
statement false. Intentional misinformation, or not?
- Suppose you write some software that depends upon
behavior described in official Intel documentation.
During the course of your development, you have the very
sophisticated means to test your software, and in turn
the documented Intel behavior. In the course of testing
you discover that the Intel microprocessor doesn't even
behave anything close to what their printed documentation
states. So knowing the answer in advance, you contact
Intel technical support and ask them for clarification of
their documentation. (You don't tell them you already
know the answer.) They give you a very detailed response
of how the microprocessor behaves in this regard. Upon
seeing their answer, you know the microprocessor doesn't
behave anything like they describe. Due to the technical
nature of their response, complete with software
algorithms, you immediately recognize they had to ask
questions of the engineering staff (possibly the
designers themselves) to get the answers. But the answers
are wrong, and are consistent with their printed
documentation. So you realize that they went to great
pain to propagate incorrect information. Is this
intentional misinformation, or just a mistake?
- One day you're browsing the newly released Pentium errata
documentation. You notice an erratum that concerns the
same subject as the above-mentioned documentation errors.
The erratum has nothing to do with the error in the
documentation, but only concerns the same subject matter.
To console you that this bug isn't as that big of a deal,
the erratum mentions a work-around. Coincidentally, the
work-around is the precise bogus processor behavior
mentioned in the official documentation. In the back of
your mind, you know how rigorous Intel's erratum
verification process is, and how precisely they select a
work-around. But the work-around is bogus, and you know
it. You've already contacted their technical support, and
know that they stand by the work-around, but you've got
proof the work-around doesn't work. Even though you can't
explain what Intel is trying to hide, you know they are
publishing incorrect information. The only question is,
whether or not it's intentional.
- There is a huge difference between a design artifact and
a design decision. Undocumented opcodes are not design
artifacts, they are design decisions. Many people believe
that Intel hasn't published these opcodes because they
haven't been fully tested. But these protagonists don't
realize that these opcodes have been in production since
1978. That theory just doesn't hold true for the past
seventeen years. Of course Intel's omission in
documenting these very simple instructions is
intentional.
Why do you think Intel engineers
are so incompetent?
I've heard this in email before. This is ludicrous. Some
people obviously don't have the mental capacity to distinguish
the difference between motives, beliefs, and the first amendment.
They never once bothered to ask me if I thought Intel engineers
were incompetent. These people automatically assumed that I
believe Intel engineers are totally incompetent because I run the
Intel Secrets home page. Well, let me set the record straight
(and then I'll probably still be called a liar):
Intel designs the best and most sophisticated x86 processors
on the market. The process technology that enables them to
continuously increase their clock frequency to nose-bleed levels
is unmatched in the industry. The inside stories I've heard about
the P6 design team, and their design verification process is
spectacularly impressive. You don't accomplish all of these
things with incompetent engineers. I have no doubt that Intel's
principle engineers are some of the best in the world. These
people are *NOT* incompetent.
What are some of your funniest
stories?
A story from an Intel Employee
One day an Intel engineer contacted me, and was trying to
lessen the significance of some of my articles. (That's a polite
way of saying he was mocking me.) He decided to educate
me regarding the history of a few things. This is an excerpt of
the email message:
I was browing (sic) through your webpage and would like to
make some personal comments about the new p6 opcode section.
I would like to remind you that Intel classified all
conditional moves(CMOV or FCMOV etc) as one class of opcodes.
He is referring to my mention that Intel can't count, just
like they can't FDIV. Intel claims that there are only two new
opcodes on the P6, but I count many more.
INT01 (ICEBP) and SALC has been around long before P6 was
even conceived. These are not new.
UD2 is not an instruction. If you ever
try to execute any undefined instruction, all
x86 processor(s) will fault with invalid opcode
(exception).
To which I responded (this is not an excerpt of my response, I
don't have it any more):
Even if you put all of the CMOV and FCMOV variants into two
opcodes (which I'll admit they do belong), and excluded the newly-documented
INT01 and SALC, there is still FCOMI and RDPMC. No matter how you
manipulate the opcode count, there are more than two new opcodes
on P6. Besides (I told him), I could have listed all of the
CMOVccc conditions as separate opcodes, but I didn't.
I'm sure I knew much more about the history of INT01 (ICEBP)
and SALC than he did. So I took the opportunity to educate him on
the history of these instructions. That was worth about two pages
of text.
I never called UD2 an instruction, I called it an opcode. I
forcefully substantiated my use of calling UD2 an opcode, based
on the definition of what an opcode is. Then I admitted that
there is one occurrence of calling UD2 an instruction on my web
page - when I was quoting official Intel documentation! So I told
him to fault his employer for calling it an instruction, not me.
Lastly I noticed that he said "If you ever
try to execute any undefined instruction, all
x86 processor(s) will fault with invalid opcode
(exception)." So I told him he was totally wrong. The
8086/8088 didn't have an invalid opcode exception. This feature
wasn't introduced until the 80186/80188. Then I pointed out how
ironic it was that an Intel employee, while trying to educate me
about the history of the x86 architecture was so grotesquely
incorrect about the very history he was trying to educate me on.
He never responded again (probably went away with his tail
between his legs).
A story from a guy that didn't have a clue
I'll keep it short:
You seem like a fairly knowledgable (sic) guy, and so I ask
myself, "Why does this guy, who can find bugs in 486s quite
easily, not have any idea why these bugs occur, and why they
should not be documented."
And I gave myself 2 answers:
- This guy has never in his life actually designed an
IC, or a complicated circuit, and therefore doesn't
understand any of the processes which result in
undocumented "features" being present in
large-scale production devices.
- You have some queer desire to propagate a positive
attitude towards the use/discovery of undocumented
features/bugs, and to propagate a negative attitude
towards Intel, and more specifically Intel engineers.
I don't (and have never) work for Intel, but you really
sound like someone who they fired! :) What's the story?
It was pretty obvious that this guy never read a single
article from my web page. So I took the time to respond in a very
polite manner telling him that he was totally mistaken, and he
responded with this message:
FOR A BIG, ENORMOUS, HUGE EXPLANATION OF MY PREVIOUS
MESSAGE, PLEASE READ THE FOLLOWING CAREFULLY: (your quote)
> - The undocumented TR4 register on the 80386.
See the above line. Read it DAMN carefully. Done? Now go
on...
> - Undocumented bits in DR7.
>* Microprocessor bugs. This is hardly the windfall of
bugs of the processor
> which you might have expected. In fact, it only
dominates two articles:
> - TR4 bug on the 80486.
Now read the line above this. CAREFULLY, now. Do you SEE
THE COMMON LINK? The words BUG AND UNDOCUMENTED are linked by the
word TR4. And you'll note the line referring to BUG came after
that referring to UNDOCUMENTED.
This guy didn't seem to notice that one article described an
undocumented register in the Intel386, and the other article
described a bug in the Intel486 - two completely different
processors. He thought I was writing an article on an
undocumented register (TR4), and then in another article calling
it a bug (an actual bug in TR4). It was quite obvious that this
guy hadn't read a word in any of my articles before he spouted
off with his keyboard.
Releasing information in breach of an NDA (such as the P6
information) is not very professional. In fact, its (sic)
illegal.
Again it was quite obvious that this guy hadn't read a word of
any article on my web site. If he had, he would have found out
that my P6 articles were based on public information distributed
by Intel. Anybody could call an 1-800 phone number and request
the CD-ROM containing this information. Instead of coming to the
debate with facts, obviously this guy was not mentally equipped.
Reverse-engineering Intel products is illegal, and has been
since 1978.
Whoa cowboy! What planet did this guy grow up on? Next this
guy is going to tell me that taking apart an internal combustion
engine for the purposes of figuring out how it works is illegal
too. It's too bad that some people just don't have a clue.
If Intel says something is true then you should accept it
as true! This (while sounding silly) is because if you don't then
you (sic) furthering activity that may later on lead to
compatability (sic) problems etc...
What this guy is really saying, is that I should write
software based on this information, and not even bother to test
it. Because if I do test it, and find out the documentation is
wrong, then Intel will eventually change their microprocessor to
match the documentation. In this way, I can avoid a compatibility
problem in the future. So when Intel just released their new
Pentium documents, complete with the test register descriptions
(formerly in Appendix H), I immediately noticed that the picture
described as the parity reversal register showed a picture of
TR12. Likewise the description of TR12 showed a picture of the
parity reversal register. Is this guy really suggesting that I
should rely on this incorrect information, in the mistaken belief
that the documentation is correct and the microprocessor is
wrong, and therefore eventually Intel will change the
microprocessor to match the documentation? (I know this isn't the
guy's point, but that's the ramification of his point. So it
should be obvious how ludicrous his point is.)
IT IS ILLEGAL! FOR GOD'S SAKE GO TO FTP.INTEL.COM and grab
a copy of their copyrights!
I took him up on this challenge. (I didn't mention to him that
copyrights pertain to printed material and software, and have
nothing to do with a microprocessor which is made of silicon.) I
looked in Intel's comprehensive index of every file on their FTP
server. There wasn't a single file which indicated it pertained
to copyrights regarding anything (I searched for anything that
had the word "copy" in its filename.) This didn't
surprise me that there wasn't a copyright notice on their FTP
site which told me reverse engineering their microprocessors was
illegal. So in return, I gave him a challenge: tell me the
filename which contains the purported copyright notice. He must
be too busy these days…he never responded to my request.
Spelling errors and incompetence
Once I sent out a general announcement of my web site, and I
misspelled a word. This started a flame war the likes of which
I've never seen before. There were a rash of postings on usenet,
and I received *many* email letters to this effect:
You are obviously incompetent. Spelling correctness is
directly related to the technical competence needed to perform an
engineering job. If you can't spell, then you're a pretty bad
engineer. And if you're a pretty bad engineer, then why should I
believe a word of any article on your web site?
These are obviously my own words. If I wanted to, I could have
printed clips of the original email letters and usenet postings.
But these flames literally went on for 2-3 weeks. These guys
tried to convince me that because I misspelled that one word, any
article on my entire Intel Secrets home page shouldn't be
trusted. Maybe someday, I'll post those email letters, in the
"Intel Secrets email hall-of-fame." That would promise
to be a best-seller.
What are some of your scariest
moments?
I'm still not brave enough to tell you the trouble Intel tried
to cause for me. Let's just say, that should their legal
department find out what happened, the person at Intel would
probably be fired, and I would have a rock-solid basis for suing
them for millions of dollars - should I find my self unexpectedly
unemployed.
And people trust you?
I've never understood why somebody would suggest that I'm
untrustworthy simply because I run the Intel Secrets home page.
In fact, I don't even see a relationship between honesty,
integrity, and running this web site. If you disagree, send me
email, it might make for good fodder for this web site.
Most of your information
concerns design artifacts
An undocumented opcode is not a design artifact. An
undocumented register is not a design artifact. People who say
this, obviously don't know much about silicon design. Registers
and opcodes don't just appear when the designers compile the
silicon. I doubt that some engineer who worked very hard to
design that hidden register, would like his work to be called a
bug, or design artifact.
What is Appendix H?
Appendix H is really the Supplement to the Pentium Processor
User's Manual. This document contains information which can
substantially enhance the ability of programs to run faster.
Anybody writing high performance assembly language code could
take advantage of the information contained in this document. Yet
Intel forced the recipients to sign a 15-year NDA as a condition
to receiving it.
Aren't you afraid of Intel?
Yes. They've already tried to cause trouble for me with my
employer. The only thing that really saves me from their wrath,
is that I'm not doing anything illegal. They know that my Intel
Secrets web pages receives up to 88,000 accesses a day. At the
first hint of trouble, I could provide links to the real
stories of what's happened, and the trouble they've tried to
cause. This is my insurance, which I hope to never have to use.
But I believe we are all too mature for that…right?
© 1991-1999 Intel Secrets Web Site and Robert Collins. PGP
key available.
Make no mistake!
This web site is proud to provide superior information and service
without any affiliation to Intel Corporation.
"Intel Secrets", "What
Intel doesn't want you to know" and
anything with a dropped e in it, are phrases that infuriate
Intel Corporation.
Pentium, Intel, and the letter "I" are registered trademarks of Intel Corporation. 386, 486, 586, P6,
all other letters, and all other numbers are not!
All other trademarks are those of their respective companies.
See Trademarks and Disclaimers
for more info.
Robert Collins works somewhere in the United States of America. Robert
may be reached via email or telephone.
