rob@conexch.UUCP (Robert Collins) (06/17/89)
+> Peter Plamondon from Intel writes: +>I assume you only give the information in "Microprocessor Report" to +>some companies and not others (like the ones who pay for it)? Do you +>suppose this creates an unfair situation? ;-> +>--------------------------------------------------------------------- +>Peter Plamondon, Intel Corp, 5200 NE Elam Young Pkwy, Hillsboro, OR + Doesn't this sound like a typically arrogant, typically Intel sort of attitude? C'mon guys, wake up and smell the roses! The computer industry does talk, and the prevailing attitude is that Intel is very unfair; nobody likes the discretionary information practices. + Michael Slater from Microprocessor Report writes: +Come now, you can't be serious? There is a world of difference between +making information available to anyone that will pay a modest fee, as +compared to refusing to provide the information at all (as Intel has done). + I'll second that! While attempting to gain information on the 80386 LOADALL instruction (Opcode 0f07), my Intel rep said: "We'd like to know who leaked the existence of the 80286 LOADALL instruction." After thinking about that statement, I responded: "It's obvious who leaked it out...Intel leaked it out. If Intel hadn't leaked it out, nobody would know about it." I think that pissed the guy off, the truth must have hurt. ------------------------------------------------------------------------------ Just so there is no confusion here, the 80286 has an undocumented instruction called LOADALL. It is Opcode 0F05. Executing Opcode 0F05 on a 80386 will produce an invalid opcode exception (Exception 6). BIOS programmers that want to maintain 80286 compatibility must trap this instruction and emulate it on the '386. This isn't hard to do. In fact Intel will even provide you with source code (though it isn't very well written, or efficient) on how to do this. What they won't give you is the description of the instruction. The formal description is a 15 page document that Intel gives out on a need-to-know basis. And so far, it seems that the number of company's that "need to know," is directly proportional to the relationship your company has with Intel. The 80386 has its own LOADALL. That is Opcode 0F07. The requirements for the '386 LOADALL are different from that of the '286 LOADALL. Thus the two instruction are incompatible. ------------------------------------------------------------------------------ We have seen it posted here that Intel is threatening to remove LOADALL on the next mask of the '386. This is VERY easy to verify. Simply set up a minimal INT6 handler, and execute opcode 0F07. If you land in your INT6 handler, then they removed it. Otherwise, they didn't. Rumor has it that Intel isn't going to remove LOADALL from the '386, they just want people to quit calling. So by merely threatening to remove it, people will give up on wanting the information. This same source of information has Opcode 0F07 in the '486 mask! This is also very easy to verify. Simply try the method listed above to trap the instruction. ------------------------------------------------------------------------------ I would urge everybody that wants the information to call your Intel rep and ask for it. This is what you can expect: 1) He will claim to know nothing about either instruction. At this point, tell him you know what the Opcodes are (0F05 for '286, 0F07 for '386). 2) He will say "Oh, those instructions," and promise to get back to you. 3) Don't expect him to get back to you. He won't. Call numerous times. 4) He finally gets the information, and is going to send it to you. (He actually had it all along, but was hoping you wouldn't be so persistent.) 5) He will send you the document on how to emulate '286 LOADALL on the '386. 6) You call him back and tell him he sent the wrong information, you wanted the official Intel 15 page document. 7) He will claim the document doesn't exist. 8) He will tell you, what he sent you, is all the information he has. 9) You notice on the source code he sent you, has the name of the engineer that wrote it. 10) You call that engineer and find he is too busy to talk to you, isn't at his desk, or can't be found. 11) You plead to talk to anybody in engineering. 12) The person you talk to gets rather disgusted with corporate politics, and immediately sends the 15 page document saying "I don't know what the big deal is anyways." That's what it takes to get the information. It took me over 4 months. In other words, the rep stroked me over 4 months. Was it a stroke? Look at the outline above, and come to your own conclusion. The irony lies in the ease of getting the document from the engineering department. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ucbvax!ucivax!icnvax!conexch!rob HOMENET: (805) 523-3205 UUCP: uunet!ccicpg!turnkey!conexch!rob WORKNET: (805) 378-7901
mike@relgyro.stanford.edu (Mike Macgirvin) (06/20/89)
In article <31249@conexch.UUCP> rob@conexch.UUCP (Robert Collins) writes: >Doesn't this sound like a typically arrogant, typically Intel sort of >attitude? C'mon guys, wake up and smell the roses! The computer >industry does talk, and the prevailing attitude is that Intel >is very unfair; nobody likes the discretionary information >practices. Intel advertisement seen recently: INTEL. We listen to the customer. (THE Customer == IBM). +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + These views are my own, and may not be correct. + + Mike Macgirvin + + - Systems Administrator Stanford Relativity Gyroscope Experiment + + - Internet: mike@relgyro.stanford.edu (36.64.0.50) + + - Bitnet: mike%relgyro.stanford.edu@forsythe.stanford + + - Uucp: uunet!relgyro.stanford.edu!mike + + "There must be some kind of way out of here." - Dylan (w/help from Jimi) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
davidsen@sungod.crd.ge.com (William Davidsen) (06/20/89)
I never cease to be amazed that some people find something which they
consider a feature in a CPU and then demand that it be documented. Back
in the CP/M days we had two sets of Z80 "secret" instructions and the
8085 "secret" instructions. This resulted in code which required an
Intel, Zilog, or Mostek CPU, and in the Mostek case, the "old" version,
since the instruction went away along with some other bugs in a later
stepping.
If Intel doesn't document it they have no need to keep it around in the
next stepping of the chip, or the 486, 586, etc. While it's fun to use
undocumented instructions, the gain in performance is seldom worth the
portability problems.
If you write for your machine and only your machine, then use what you
want, but I can't see writing any code I would ever share which uses an
undocumented feature. What happens is that it fails on someone's
machine and they blame the software. If you write for money you don't
need unhappy customers, and if you write for fun you don't need to see
people posting flames about your work.
Maybe someone can explain how the LOADALL instruction will change my
life, other than letting me reformat my disk if it doesn't work as
(un)documented. I checked to be sure that my 386 wasn't faking it, and I
don't have a list of programs which go out with trap6.
Sounds like a solution in search of a problem to me.
bill davidsen (davidsen@crdos1.crd.GE.COM)
{uunet | philabs}!crdgw1!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me