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" -mepeter@guardian.UUCP (peter) (06/23/89)
All right, all right!! I suppose no one noticed the portion of my original posting which noted I had _no_ connection with the silicon people (you remember, the guys who designed the chips with/without the alleged instruction?). I'm a _software_ person. Believe it or not, I wasn't aware that Intel may/may not have tried to limit the availability of info on the alleged instruction. So now I've been educated. I can trust all of you to give me the straight scoop, right? You wouldn't withhold information, would you? ;-) Seriously, assuming info on the alleged instruction wasn't freely available, what's the big deal? From what I've heard, the instruction was intended for the testing of the component and was never intended for general use. So someone figured out it exists, or some large customer wanted to do their own in-coming testing and the info leaked out. How does that put an obligation on Intel to provide that info to anyone who asks? (If an unnamed computer company were to buy a substantial chunk of Intel and then ask for "inside info", you've got to expect they'd get something for their money -- do the flamers in the audience own Intel stock?). (Now I'm really asking for it...) There's clearly a difference between not documenting the MOV instruction, not documenting the alleged LOADALL, and giving design details to the Japanese. Where would _you_ draw the line? ------------------------------------------------------------------------------- Peter Plamondon, Intel Corp, 5200 NE Elam Young Pkwy, Hillsboro, OR 97124-6497 Internet: peter@langlab1.hf.intel.com +1 503-696-5219 UUNET : uunet!littlei!langlab1!peter "I speak for myself, as best I can." UUCP : tektronix!psu-cs!foobar!langlab1.hf.intel.com!peter -------------------------------------------------------------------------------
mslater@cup.portal.com (Michael Z Slater) (06/24/89)
>Seriously, assuming info on the alleged instruction wasn't freely available, >what's the big deal? From what I've heard, the instruction was intended for >the testing of the component and was never intended for general use. So >someone figured out it exists, or some large customer wanted to do their own >in-coming testing and the info leaked out. How does that put an obligation >on Intel to provide that info to anyone who asks? The instruction was designed for testing, but because of the limitations of the 286 architecture, it turned out to be genuinely useful for operating system code and certain utilities, such as ram disks and ems emulators. Microsoft uses it in their RAMdrive program and in OS/2, and I've been told that it is used in some ROM bios code and in several ems emulators. Thus, if I am a vendor of RAM emulators and haven't been given this info, then I can't compete with Microsoft on a fair basis. I understand Intel's concern that they don't want to make something a part of the architecture that they don't intend to support in future products. The solution to this is simple; the documentation just states that this is an implementation-specific function, is not part of the architecture, and should be used with great care and only after testing for processor type. Michael Slater, Microprocessor Report
philba@microsoft.UUCP (Phil Barrett) (06/30/89)
In article <19820@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: >>Seriously, assuming info on the alleged instruction wasn't freely available, >>what's the big deal? From what I've heard, the instruction was intended for >>the testing of the component and was never intended for general use. So >>someone figured out it exists, or some large customer wanted to do their own >>in-coming testing and the info leaked out. How does that put an obligation >>on Intel to provide that info to anyone who asks? > > ... > >I understand Intel's concern that they don't want to make something a part >of the architecture that they don't intend to support in future products. >The solution to this is simple; the documentation just states that this >is an implementation-specific function, is not part of the architecture, and >should be used with great care and only after testing for processor type. > >Michael Slater, Microprocessor Report This suggestion has problems in that whether you say `implementation-specific' or not and add copious disclaimers and warnings, people will use the feature and then complain bitterly (repleat with character assasinations) when it gets removed. The experience with MS-DOS is instructive here: there are undocumented `features' that are impossible to remove because somebody groveled through the code, figured out what was going on and took advantage of it in a popular piece of SW. If it gets changed they scream loud and long in public. I've heard such statements like `you have no right to do this' and `you are trying to put me out of business' and `typical arrogant SOBs'. How does one improve a product with these kind of constraints?. And, yes, loadall eats microcode store big time. Intel is doing exactly the right thing in trying to prevent widespread use of loadall. Phil Barrett of course, the above opinions are mine and not those of Microsoft.
peter@ficc.uu.net (Peter da Silva) (08/08/89)
In article <6203@microsoft.UUCP>, philba@microsoft.UUCP (Phil Barrett) writes: > `you are trying to put me out of business' and `typical arrogant SOBs'. How > does one improve a product with these kind of constraints?. You stand your ground. Microsoft can't do that because MS-DOS was so inadequate that there was no alternative to breaking the rules, but Commodore regularly breaks badly-behaved software with new releases of the Amiga O/S with only the mildest of whimpers. And Microsoft has less need to kowtow to developers than Commodore, seeing as it has so many more of them. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.