What is Appendix H?
Mike Goelzer
that everyone keeps talking about? As best I can gauge, its some
top-secret document published by Intel that contains some undoc'd
info about their processors. So what's so great about it, and why
are folks around here always talking about it?
-mike
Mike Goelzer
<mgoe...@us.net>
Sean Werkema
>that everyone keeps talking about? As best I can gauge, its some
>top-secret document published by Intel that contains some undoc'd
>info about their processors. So what's so great about it, and why
>are folks around here always talking about it?
Appendix H is an ultra-top-secret document on the Pentium processor which
contains a whole bunch of information which allows programmers to
*drastically* speed up interrupts, extend the address space (or they could
until Intel disabled it), and other goodies. It lists undocumented fields in
CR4, CR0 (I think), and EFLAGS (I think), as well as just about every other
juicy goody you want to know about the Pentium chip.
Unfortunately, you pretty much need to sign away your first-born son to get a
copy.
There is a Web site, Undocumented Intel, which contains much of the info
(though probably not all of it - I haven't actually *seen* Appendix H, and nor
have most other people):
http://fohnix.metronet.com/~rcollins/undoc/UndocumentedIntel.html
Appendix H is pretty useless unless you're coding for Pentiums in protected
mode, in which case it's the holy grail (or a reasonable facsimile thereof).
--------------------------------------------------------------------
Program Manager Dialog Box: "Please press Ctrl-Alt-Del to continue."
stw...@psu.edu (Sean Werkema) BCNU :)
Robert Collins
: I guess I'm pretty out of it, but what is this Appendix H
: that everyone keeps talking about? As best I can gauge, its some
: top-secret document published by Intel that contains some undoc'd
: info about their processors. So what's so great about it, and why
: are folks around here always talking about it?
I've never seen it, so I can't say what's so great about it. But you
are correct in your impression of what it is, and what's in it. As
for the rest of the story? Well, Intel has stated that you can get it
on a need-to-know basis. They also say that anybody who needs it, will
never be denied it. But this is patently untrue. There is one BIOS
vendor, who has never received it, despite being promised it three times
by Intel. So for all others, non BIOS people, and non O/S people, you
don't need to know, and therefore you can't get the information. The
controversy surrounding this issue is that Intel won't give it to you,
nor even let you make the determination for yourself, whether or not
you need it. So there are many people who disagree with this position,
and the attitude which it is based upon.
Another issue of the controversy is the anti-competetive nature which
Intel uses to determine who gets the information. If you are their friend,
then you obviously get the information. But if you are this one BIOS
vendor, who by Intel's own definition, meets the criteria of who needs
the information, you can't seem to get it. Is this fair? It doesn't
matter, too much does it?
--
(((--------------------------------------------------------------------------)))
((( "Intel Secrets -- What Intel doesn't want you to know" )))
((( http://www.metronet.com/~rcollins/undoc )))
(((--------------------------------------------------------------------------)))
((( Robert Collins | "Boom, Boom. Ain't it great to be Crazy?")))
((( mailto:rcol...@metronet.com | -- Barney )))
((( work: (214) 997-3923 | (Foot stomp) "Crazy?" )))
((( home: (214) 517-1128 | -- My son Daniel (19 months) )))
(((--------------------------------------------------------------------------)))
Mike Goelzer
>
> Mike Goelzer (mgoe...@us.net) wrote:
> : I guess I'm pretty out of it, but what is this Appendix H
> : that everyone keeps talking about? As best I can gauge, its some
> : top-secret document published by Intel that contains some undoc'd
> : info about their processors. So what's so great about it, and why
> : are folks around here always talking about it?
>
> Intel uses to determine who gets the information. If you are their friend,
> then you obviously get the information. But if you are this one BIOS
> vendor, who by Intel's own definition, meets the criteria of who needs
> the information, you can't seem to get it. Is this fair? It doesn't
> matter, too much does it?
Wait, I don't get it. It seems to me that it would be in
Intel's best interest to distribute Appendix H to everybody - it
would make the Pentium an even more powerful device. Suppose I
designed and built a car that was capable of going at 150mph, if
you press a certain button hidden in the engine. Now suppose I
sold that car, but didn't tell anyone about the button. This would
mean that all the hard work and money spend on perfecting the
button and associated engine features would go to waste, since
consumers wouldn't know about this feature. But if I did tell
folks about the button, my cars would sell a lot better.
So can anyone tell me why Intel thinks that it is a *good idea* to
keep this stuff secret? Seems really dumb to me.
-mike
Mike Schmit
Someone at Intel (marketing and/or legal department would be my guess)
decided that if this info got out, then AMD, Cyrix, NexGen, IBM, etc
would all use it to more easily clone the Pentium. Then they said that
the fe people that need to know this could be under NDA and everything
would be fine.
The problem is that these bean-counting bozos and legal techno-idiots
don't realize that there are 1000's of people who need to know this
stuff and Intel doesn't know who exactly they are. It's some one
working on some program no one knows about or someone at a small
startup that know one knows about, etc. It's not just Microsoft,
Borland, etc.
Mike Schmit
-------------------------------------------------------------------
msc...@ix.netcom.com author:
408-244-6826 Pentium Processor Programming Tools
800-765-8086 ISBN: 0-12-627230-1
-------------------------------------------------------------------
Mark Wignall
>rcol...@metronet.com (Robert Collins) wrote:
[some stuff deleted]
>So can anyone tell me why Intel thinks that it is a *good idea* to
>keep this stuff secret? Seems really dumb to me.
So nobody else like your competetors knows about your secret little button, and
therefore can't replicate it's functionality.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Wignall : What the fool does in the end,
Computer Equipment Technician IV : the wise man does in the beginning.
Tektronix Inc. :
Color Printint & Imaging Division :
:
email: Mark.T....@tek.com :
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Patrick Chase
|> As the mere existance of the lawsuits Intel has filed has demonstrated to us,
|> it's no problem for Cyrix, AMD, etc. to reverse engineer anything they want.
|> So any perceived benefit which Intel gains in keeping the information secret,
|> is only that ... perceived benefit. All of the new features inside Pentium
|> have been documented in one form or another: Mike Schmidt, Christian
|> Ludloff, Dr. Dobbs, etc. And you might be quite surprised at how much is
|> available inside official Intel documents -- just not necessarily the Pentium
|> documents. So far, I haven't described anything that is available through
|> non-disclosure.
|>
|> Now that leaves testability features. Testability features are highly
|> implementation-specific. A cache, TLB, or BTB set of test registers
|> obviously wouldn't be implemented the same on Intel, AMD, and Cyrix. These
|> are specific to the implementation of the cache, TLB, or BTB itself. There
|> is no competetive advantage in keeping this secret. This information doesn't
|> do AMD or Cyrix any good at all.
|>
|> So why does Intel keep it secret? Low on my list, is competetive
|> advantage.
High on the list is preventing people from using them in a manner that would
force Intel to support the same features in future processors. If you look
at the history of computing (PC, Macs, mainframes, minis, supers, etc. etc.)
it's littered with examples of features which were designated as
"implementation specific" and "unsupported" by the manufacturers, but that
programmers used anyway. If you have a really large installed base, like
Intel does, this becomes a huge issue, because you suddenly have to support
these features in future design in order to avoid breaking existing
software. The only way to avoid this is to keep the implementation-dependent
stuff secret, or at least prevent it from leaking into mainstream
software. The Appendix H NDA provides a means for Intel to supply the
knowledge to those who need it, like compiler writers, without making
their interfaces public such that they can be used in shipping software.
While Pentium's debug and test interfaces would seem to be fairly immune
to this (after all, what possible place to they have in mainstream
software?) I can guaranteee you that someone(s) somewhere will use them
and will get burned when Intel changes them. At least this way Intel can
say "well, we didn't tell you about those, so it's your problem, not
ours". It does become a competitive advantage issue when you have to
kludge a future design in order to support a previous one's implementation-
specific "features". I suspect that Intel knows this better than most
companies, given the heritage they're already dealing with in x86 :-)
In general, very few companies document their D&T interfaces, whether in
processors, printers, digitally controlled toaster-ovens, or whatever.
That stuff is strictly unsupported and not meant to be mucked about with.
Even among current CPU manufacturers, Intel is not alone: some won't even
give it to you under NDA.
-----------------------------------------------------------------------------
Patrick Chase Not speaking for Hewlett-Packard...
H-P San Diego
Paul Burgin
>>So can anyone tell me why Intel thinks that it is a *good idea* to
>>keep this stuff secret? Seems really dumb to me.
>So nobody else like your competetors knows about your secret little button,
and
>therefore can't replicate it's functionality.
I can imagine lots of reasons. For instance if you thought you might like
to discard the button from future releases without causing compatibility
problems. Or what if the button hadn't been tested thoroughly - if they
don't make a public claim that it works then no-one can complain when it
doesn't. Or perhaps they don't want the expense of providing tech. support
for it. Or there may be side effects which are unknown or unpredictable.
Or if it's possible to mis-use the button you might want to discourage
this. Or...
Paul
---
Paul Burgin | My opinions, not my employers! | http://catalog.com/sjr/www/pb
sl...@cc.usu.edu
> So can anyone tell me why Intel thinks that it is a *good idea* to
> keep this stuff secret? Seems really dumb to me.
>
I can name one...
MOTOROLA and their power PC chips... :) (not to mention AMD, and the chip
builders in the copying business... (and I don't mean Xerox ;) :)
wReam...
Pixel_Cat...,
bur...@logica.com (Paul Burgin) said:
>I can imagine lots of reasons. For instance if you thought you might like
>to discard the button from future releases without causing compatibility
>problems. Or what if the button hadn't been tested thoroughly - if they
>don't make a public claim that it works then no-one can complain when it
>doesn't. Or perhaps they don't want the expense of providing tech. support
>for it. Or there may be side effects which are unknown or unpredictable.
>Or if it's possible to mis-use the button you might want to discourage
>this. Or...
Which merely begs the question of why they'd include it in the first place.
Most people try *not* to air their dirty laundry in public: if I had an
untested feature, you can be damn sure I'd have it thoroughly disabled for
public release.
--
Richard Cooley Extraordinaire --=*=-- Linux Linux Linux Linux Linux Linux Linux
pi...@gnu.ai.mit.edu | pi...@usa1.com | These are my opinions, not MIT's
Daisemi'in rhhaensuriuu meillunsiateve rh'e Mnhei'sahe yie ahr'en:
Mnahe afw'ein qiuu; rh'e hweithnaef mrht Heis'he ehl'ein qiuu.
Brian Jonnes
wrote:
>Mike Goelzer <mgoe...@us.net> wrote:
>>rcol...@metronet.com (Robert Collins) wrote:
>[some stuff deleted]
>>So can anyone tell me why Intel thinks that it is a *good idea* to
>>keep this stuff secret? Seems really dumb to me.
>So nobody else like your competetors knows about your secret little button, and
>therefore can't replicate it's functionality.
But then nobody can use it and you might as well throw it away!!??!!!
Just a crazy thought.
--
Brian Jonnes
jon...@lia.co.za
Robert Krawitz
Chase) writes:
The Appendix H NDA provides a
means for Intel to supply the knowledge to those who need it, like
compiler writers, without making their interfaces public such that
they can be used in shipping software.
Why would compiler writers need this kind of information? Compilers
shouldn't care about internal D&T interfaces any more than any other
application software would. Indeed, compiler writers should be
careful not to embed unnecessary dependencies into their compilers, or
the compilers would generate nonportable code.
If we're talking about optimization type information, this is material
that is of use to the general public. People do have valid reasons
for writing assembly language code that's carefully tuned.
--
Robert Krawitz <r...@tiac.net>
Member of the League for Programming Freedom -- mail l...@uunet.uu.net
Tall Clubs International -- tci-r...@think.com or 1-800-521-2512
Mike Schmit
>
>In article <3vm1jj$c...@news.sdd.hp.com> pat...@sdd.hp.com (Patrick
>Chase) writes:
>
> The Appendix H NDA provides a
> means for Intel to supply the knowledge to those who need it, like
> compiler writers, without making their interfaces public such that
> they can be used in shipping software.
>
>Why would compiler writers need this kind of information? Compilers
>shouldn't care about internal D&T interfaces any more than any other
>application software would. Indeed, compiler writers should be
>careful not to embed unnecessary dependencies into their compilers, or
>the compilers would generate nonportable code.
>
>If we're talking about optimization type information, this is material
>that is of use to the general public. People do have valid reasons
>for writing assembly language code that's carefully tuned.
>--
What if compiler writers (and/or assembly language programmers)
just wanted to use this info to "profile" their code, make a few
tweaks, then profile it again. I think that this is what Intel
really intended. They just messed up when they thought that
there were only a few dozen interested programmers when there
are thousands.
Mike Schmit
>
>While prying the lemmings from hir ankles,
>bur...@logica.com (Paul Burgin) said:
>
>>I can imagine lots of reasons. For instance if you thought you might like
>>to discard the button from future releases without causing compatibility
>>problems. Or what if the button hadn't been tested thoroughly - if they
>>don't make a public claim that it works then no-one can complain when it
>>doesn't. Or perhaps they don't want the expense of providing tech. support
>>for it. Or there may be side effects which are unknown or unpredictable.
>>Or if it's possible to mis-use the button you might want to discourage
>>this. Or...
>
>Which merely begs the question of why they'd include it in the first
place.
>Most people try *not* to air their dirty laundry in public: if I had
an
>untested feature, you can be damn sure I'd have it thoroughly disabled
for
>public release.
>--
Maybe the feature is needed for QA testing, but they didn't test it
under all conditions, just under the conditions of their QA tests.
Robert R. Collins
>
>High on the list is preventing people from using them in a manner that would
>force Intel to support the same features in future processors. If you look
>at the history of computing
Correct, history of the past. It is now generally unacceptable (un-PC)
to use undocumented features in source code. Intel has every right to
stand up to thugs that insist on forward-compatibility of implementation-
specific behavior. If Intel can stand up to IBM on the interrupt
vector numbering (transition from 8086 to 80286) and win, then they can
stand up to you, who might write some renegade software. Sorry, I see this
as an issue of the past (10 years in the past), not relevant to today. I
don't think this argument holds much water today. There are many software
companies - Microsoft included - that refuse to use any implementation-
specific feature if it isn't publically documented, simply because they
don't want to get burned by Intel changing things.
So what about the small-time BIOS guy, who Intel won't give the NDA to.
He surely needs the information to write his BIOS (it's implementation-
specific code). But he can't get it.
>If you have a really large installed base, like
>Intel does, this becomes a huge issue, because you suddenly have to support
>these features in future design in order to avoid breaking existing
>software.
Sure, that's the party-line. But do you? If somebody uses an implementation-
specific feature, or an undocumented opcode, then they do so at their own
risk. I believe they know that. Here are a few examples which would seem to
contradict your assertions:
1) The early 80386 contained two (publically documented) instructions --
IBTS and XBTS. These instructions were removed in a later stepping
of the 80386. OS/2 used these instructions to determine whether or
not the processor was this early 80386. Intel didn't keep these
instructions, even though they were publically documented.
2) The 80486 contained other (publically documented) instructions --
MOV TRn, move to test registers. The Pentium doesn't have these
opcodes, in spite of them being publically documented.
3) IBM mapped IRQ0-7 as INT8-15, in spite of the 8086 manual saying not to
do such a thing, as these interrupt vectors are "reserved" for future
processors. IBM did it anyways. The rumor is, that IBM tried to bully
Intel into moving the processor exceptions that map into these locations,
as it created a conflict with the best-selling PC in history. Intel
said "get lost, we told you not to do it in the first place."
So the forward support argument, just doesn't hold muster. These three
examples are GIANT exposure to Intel, which they removed functionality
anyways. I cannot accept that Intel would bow to some renegade software
writer, which uses some undocumented feature, and be forced to maintain
forward compatibility. History just doesn't support this viewpoint.
>The only way to avoid this is to keep the implementation-dependent
>stuff secret, or at least prevent it from leaking into mainstream
>software.
I completely disagree. The best way to avoid this, is to mark it as
implementation-specific. If Intel removes it, and somebody gets burned,
they will *NEVER* rely on an implemenation-specific feature again. So
it's not the "only way" in fact, it's not even the best way.
>The Appendix H NDA provides a means for Intel to supply the
>knowledge to those who need it, like compiler writers, without making
>their interfaces public such that they can be used in shipping software.
But as it's already been pointed out, people that legitimately need the
information, Intel won't give it to. Small BIOS writers, people writing
real-time applications all need this information, but can't get it.
>While Pentium's debug and test interfaces would seem to be fairly immune
>to this (after all, what possible place to they have in mainstream
>software?)
And isn't it ironic, that most appendix H features are documented in
other Intel manuals -- you just need to know where to look. So that
leaves the testability features under NDA. And you, yourself said
they don't do anybody, any good. So what good is appendix h?
Why NDA?
>I can guaranteee you that someone(s) somewhere will use them
>and will get burned when Intel changes them.
And once they get burned, they'll never do it again. That's the best
cure for the problem, not keeping it secret.
>At least this way Intel can
>say "well, we didn't tell you about those, so it's your problem, not
>ours".
No, they say "we told you not to depend on the feature, it's your
problem." That's what they did with test registers. Why can't they do
it with 4M pages, VME, et al?
--
http://www.metronet.com/~rcollins/undoc
-----------------------------------------------------------------------------
Robert Collins mailto:rcol...@metronet.com 214.997.3923(w) 214.491.7718(h)
Robert R. Collins
>
>In article <3vicsn$1...@news.us.net>, Mike Goelzer <mgoe...@us.net> wrote:
>>rcol...@metronet.com (Robert Collins) wrote:
>
>>> vendor, who by Intel's own definition, meets the criteria of who needs
>>> the information, you can't seem to get it. Is this fair? It doesn't
>>> matter, too much does it?
>
>Alread Making scaDs of money off clone chips? :) :)
Nope. You are incorrect. I said BIOS vendor, not CHIP vendor. As far as
I know, AMD is not in the BIOS business. The BIOS vendor I'm referring to,
is independant, and has *NO* affiliation with any of Intel's competitors.
>
>>So can anyone tell me why Intel thinks that it is a *good idea* to
>>keep this stuff secret? Seems really dumb to me.
>
>'Cos you don't think like Intel. Watch:
>
> 3) Don't let your CPU clone competitors (AMD, Cyrix, IBM, etc.) get
> the info about that instruction. If they don't implement that
> instruction, they can't run the OS.
First of all, IBM has (had?) rights to use the Intel masks. So IBM's out of the
question. It is so easy to write a program which scans for undocumented
opcodes. Once you find one, then you go to work. This won't even make AMD
or Cyrix flinch.
--
(((--------------------------------------------------------------------)))
((( http://www.metronet.com/~rcollins
(((--------------------------------------------------------------------)))
((( Robert Collins
((( mailto:rcol...@ti.com |
((( work: (214) 997-3923 | (Foot stomp) "Crazy?"
((( home: (214) 491-7718 |
(((--------------------------------------------------------------------)))
Pixelated!
>rcol...@metronet.com (Robert Collins) wrote:
>> then you obviously get the information. But if you are this one BIOS
>> vendor, who by Intel's own definition, meets the criteria of who needs
>> the information, you can't seem to get it. Is this fair? It doesn't
>> matter, too much does it?
Gee, I'd hate to guess at a name, but I don't suppose their initials are
Alread Making scaDs of money off clone chips? :) :)
>So can anyone tell me why Intel thinks that it is a *good idea* to
>keep this stuff secret? Seems really dumb to me.
'Cos you don't think like Intel. Watch:
1) Have a super-powered, incredibly useful instruction (or not so)
that works *real* *well* for OS desgin.
2) Don't document that instruction *except* to OS designers. Make 'em
sign a non-disclusure agreement. Try to get 'em to *all* use that
instruction.
3) Don't let your CPU clone competitors (AMD, Cyrix, IBM, etc.) get
the info about that instruction. If they don't implement that
instruction, they can't run the OS.
4) They can try to revierse-engineer it, but it'll cost them BIG BUCKS
to do, and delay them for months.
5) Rake in the cash you get from being the only person making the CPU.
This may be an exaggeration, but it explains some of why undocumented features
exist.
--
Richard Cooley Extraordinaire | Linux Linux Linux | My opinions, not MIT's.
pi...@gnu.ai.mit.edu | rcoo...@dgl.ssc.mass.edu | pi...@usa1.com
Christian Ludloff
Because the features which may help you to optimize code for the iPentium
are described in the Appendix H only -- unfortunately!
_CL_
Christian Ludloff TEL ++49-371-242091 eMail c...@box.in-chemnitz.de
Ludwig-Kuehn-Str.15 FAX ++49-371-242091 eMail c...@vgasoft.com (new!)
D-09123 CHEMNITZ FIDO 2:2426/2240.14 Please, try the 4P package!
http://fohnix.metronet.com/~rcollins/4p/4p_v310.zip
http://fohnix.metronet.com/~rcollins/4p/80x86.cpu.toc.html
## CrossPoint v3.02 ##