rob@conexch.UUCP (Robert Collins) (05/28/89)
Does anybody (besides me) have the complete '286 LOADALL (Opcode 0f05) document from INTEL? Is it appropriate to post this document? What about the 80386 version of LOADALL (Opcode 0f07). Does anybody have the document on that? Is it appropriate to post this document? Since I didn't get these documents by signing a non-disclosure agreement, would I be breaking any law, or implicit contract by posting them? -- "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
peter@guardian.UUCP (peter) (06/02/89)
In article <30105@conexch.UUCP> rob@conexch.UUCP (Robert Collins) writes: >What about the 80386 version of LOADALL (Opcode 0f07). Does anybody have >the document on that? >Is it appropriate to post this document? Although I don't speak for Intel and have no involvement with the chip designers, I've heard from a reliable source that future steppings of the Intel386(tm) will NOT recognize the LOADALL instruction. Intel is rewriting all 386 software which includes LOADALL; I suspect the gang in Redmond is doing the same, but that's pure speculation. I'd strongly encourage everyone to avoid using LOADALL on a 386. >Since I didn't get these documents by signing a non-disclosure agreement, >would I be breaking any law, or implicit contract by posting them? I'm specifically NOT responding to this question; I have no idea what restrictions, if any, were once or are now placed on the distribution of the LOADALL documentation.
schuster@dasys1.UUCP (Michael Schuster) (06/05/89)
In article <30105@conexch.UUCP> rob@conexch.UUCP (Robert Collins) writes: >Does anybody (besides me) have the complete '286 LOADALL (Opcode 0f05) >document from INTEL? >Is it appropriate to post this document? I don't have the document, but in case you missed the following, here is a repost of a summary article on the 80286 instruction. It was originally posted here by your organization: -------------------------------------------------------------------- From: root@conexch.UUCP (Larry Dighera) Newsgroups: comp.sys.intel Subject: Re: Returning the 80286 to Real Mode Summary: Have you heard about the LOADALL instruction? Message-ID: <11004@conexch.UUCP> Date: 31 Oct 88 14:05:04 GMT References: <1081@xenon.idec.stc.co.uk> Reply-To: root@conexch.UUCP (Larry Dighera) Organization: The Consultants' Exchange, Orange County, CA. (714) 842-6348 Lines: 198 In article <1081@xenon.idec.stc.co.uk> sanders@idec.stc.co.uk (Tom Sanders) writes: > > Rumour has it that it is possible to switch the 80286 back to real mode > once having gone protected. Can anyone advise me how this is done? > Here is a copy of an article that recently appeared in a periodical magazine. The information it contains and the opinions expressed in it are not mine. I'm sure you will find it useful and informitive. ------------------------ LOADALL DOCUMENTATION ------------------------- Secret 286 LOADALL instruction allows access to extended memory in real mode. In last month's article on the P9, we described the method used to access extended memory (memory beyond the lower 1 megabyte) from real-mode programs running on a 286. This method requires switching to protected mode to perform access, and then resetting the processor to return to real mode. We have since learned that there is another way. An undocumented 286 instruction, LOADALL, allows all of the processor's registers (including protected mode registers and hidden internal registers) to be loaded, even when operating in real mode. By changing the value of the descriptor cache base register, a program can select a segment beyond the lower 1 Mbyte. LOADALL also has other uses, as described later in this article. ---------------------------------------------------------------------- Physical Memory Address CPU register (hex) ====================================================================== 800-805 none 806-807 MSW (Machine Status Word) 808-815 None 816-817 TR (Task Register) 818-819 Flag Word 81A-81B IP (Instruction Pointer) 81C-81D LDT (Local Descriptor Table) 81E-81F DS (Data Segment Selector) 820-821 SS (Stack Segment Selector) 822-823 CS (Code Segment Selector) 824-825 ES (Extra Segment Selector) 826-827 DI (Destination Index) 818-829 SI (Source Index) 82A-82B BP (Base Pointer) 82C-82D SP (Stack Pointer) 82E-82F BX (Data Register B) 830-831 DX (Data Register D) 832-833 CX (Data Register C) 834-835 AX (Accumulator) 836-83B ES Descriptor Cache 83C-841 CS Descriptor Cache 842-847 SS Descriptor Cache 848-84D DS Descriptor Cache 84E-853 GDTR (Global Descriptor Table Register) 854-859 LDT Descriptor Cache 85A-85F IDTR (Interrupt Descriptor Table Register) 860-865 TSS (Task State Segment) Descriptor Cache ======================================================================= Table 1. LOADALL data area format ----------------------------------------------------------------------- Originally included by Intel for chip testing, Microsoft is now using this instruction in their RAM Drive program and in OS/2's compatibility box. While this instruction is probably appropriate only for use in operating systems and system-level utilities, it is important because it provides a set of capabilities that are not otherwise available in a 286-based system. We have received a copy of a document that describes LOADALL. No company name is shown, but it is almost surely written by Intel. The 15-page document describes in detail how to use the instruction, so calling it "undocumented" is not quite correct -- it is documented, but not in the data sheet. By restricting access to this documentation, Intel gives unfair advantage to Microsoft and other large customers. ---------------------------------------------------------------------- Descriptor Cache Format Bytes 0-2 24-bit segment base address Byte 3 Access rights byte. Format is the same as the access rights byte in a descriptor, except that the "present" bit becomes a "valid" bit. If a "valid" bit is not set, any memory reference using the descriptor will cause exception 13 with error code of 0. Bytes 4-5 16-bit segment size GDTR and IDTR Format Bytes 0-2 24-bit base address Byte 3 0 Bytes 4-5 16-bit segment limit ---------------------------------------------------------------------- Table 2. Descriptor Cache Formats Intel's position is that this instruction is not useful to most users, and can easily lead to machine crashes if not used properly. Intel says that they will provide documentation for the instruction on a "need-to-know" basis, presumably only after a non-disclosure agreement has been signed. Most developers, of course, would not know to ask. The information we are presenting here should be enough for you to evaluate the usefulness of the instruction; if you intend to use it in a product, you should contact Intel for the full documentation. The opcode for LOADALL is 0F05 hex. No operands follow the instruction; LOADALL gets its data from a 102-byte block of memory starting at the fixed address 800 hex, as shown in Table 1. Table 2 shows the format of the descriptor cache entries. These are hidden registers that cannot otherwise be modified by the programmer; they are set automatically when a descriptor is read from the descriptor table. ACCESSING EXTENDED MEMORY FROM REAL MODE The following sequence is required to access high memory from real mode using LOADALL: 1. Disable interrupts 2. Save the 102 (decimal) bytes starting at 800 hex. (MS-DOS uses this area for system code. OS/2 presumably leaves it free for LOADALL, but depends on application programs not to change it.) 3. Set up the 102-byte register image at 800. The base address in the data segment descriptor cache is set to select the desired high-memory area. 4. Execute the LOADALL instruction. The data segment now points to the new, high-memory segment. 5. Move data to or from high memory. 6. Restore the base address in the data segment descriptor cache in the image at 800, and execute another LOADALL. 7. Enable interrupts. <<< The next step is not in the article, but conspicuously absent. >>> 8. Restore the original 102 bytes to 800. Thus while it is appealing not to have to go to protected mode and back to access high memory from real mode, this isn't much better. LOADALL requires 195 clock cycles on a machine with no wait states, or 19.5 us at 10Mhz. LOADALL can also be used to allow programs to be executed in high memory, even though the processor is in real mode. A special paragraph ID (such as FFFF) is used to indicate when a program is running in extended memory. Interrupt service routines must check the segment register to see if any contain the special ID, and if so, they must reload the registers using LOADALL to restore the segment base addresses before returning from the interrupt. OTHER APPLICATIONS LOADALL has other uses as well. It can be used to switch back to a protected mode task from real mode, serving as a fast intermode context switch. OS/2 presumably uses it to return to protected mode from a real-mode task running in the compatibility box. LOADALL can also be used to emulate real mode from protected mode. By setting the privilege level of all local and global descriptor table entries lower than that of the current program, a protection violation occurs whenever the program attempts to load a segment register. (Actually, loading the segment register with a value of 0000 to 0003 does not cause an exception, and this case must be handled specially.) The exception handler then uses LOADALL to set the base address for the segment. There are many other complexities to this emulation, as described in the LOADALL document. The emulation is imperfect, and Microsoft apparently decided to use the "reset to real mode" technique (as described in our article last month on the P9), rather than trying to emulate real mode from within protected mode. RESTRICTIONS LOADALL performs no checking on the values loaded into the registers, so no exception will occur even if an illegal value is loaded. Thus, the processor can potential be put into a strange state. If an illegal descriptor value is set, no exception occurs from the execution of LOADALL. An exception will occur, however, when an access using that descriptor is attempted. LOADALL can be executed in protected mode, but only at the most privileged level (level 0). Thus it does not violate the protection. Unfortunately, LOADALL cannot be used to switch back to real mode from protected mode. Early versions of 286 (A1 and B1 steppings) have bugs which affect the use of LOADALL. Thus, the techniques described in this article may not work properly on older systems. LOADALL is not implemented on the 80386, so Microsoft has included code in OS/2 and in the current version of RAM Drive that tests for the processor type. If it's a 286, LOADALL is used, and if it's a 386, the native 386 mechanisms are used. If you use LOADALL, you should also perform this check, or your software will not run on 386-based machines. Using LOADALL is certainly fraught with peril, and requires careful program design and knowledge of all the implications. We have spoken with a number of software vendors that were aware of the instruction, and all had decided not to use it due to the risks and complexity involved. We don't recommend its use to most people, but we do feel that everyone should have access to the information so they can make their own choice about whether or not to use the instruction. -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root -- l\ /l' _ Mike Schuster ...!dasys1!schuster l \/ lll/(_ Big Electric Cat schuster@dasys1.UUCP l lll\(_ New York, NY USA DELPHI,GEnie:MSCHUSTER CIS:70346,1745
brian@apt.UUCP (Brian Litzinger) (06/05/89)
In article <213@guardian.UUCP>, peter@guardian.UUCP (peter) writes: > In article <30105@conexch.UUCP> rob@conexch.UUCP (Robert Collins) writes: > >What about the 80386 version of LOADALL (Opcode 0f07). Does anybody have > >the document on that? > > I've heard from a reliable source that future steppings of the > Intel386(tm) will NOT recognize the LOADALL instruction. Intel is rewriting > all 386 software which includes LOADALL; I suspect the gang in Redmond is > doing the same, but that's pure speculation. I'd strongly encourage everyone > to avoid using LOADALL on a 386. While the LOADALL instruction is, in fact, gone from the Intel386(tm), it is definitely not dead. In fact, on many 386 machines you can execute the 286 LOADALL opcode and exactly the right things will happen. Not because the particular 386 processor happens to have the instruction, but because the system BIOS vendor choose to emulation the instruction in the BIOS. Some BIOSes catch the invalid opcode interrupt, check for the 286 LOADALL instruction, and then emulate it it software. I do, however, agree with peter...Avoid the LOADALL instruction on the 386! <> Brian Litzinger @ APT Technology Inc., San Jose, CA <> UUCP: {apple,sun,pyramid}!daver!apt!brian brian@apt.UUCP <> VOICE: 408 370 9077 FAX: 408 370 9291
rob@conexch.UUCP (Robert Collins) (06/06/89)
In article <213@guardian.UUCP> peter@langlab1.hf.intel.com (Peter Plamondon) writes: > >Although I don't speak for Intel and have no involvement with the chip >designers, I've heard from a reliable source that future steppings of the >Intel386(tm) will NOT recognize the LOADALL instruction. Intel is rewriting I too have heard from reliable sources (very high sources) that Intel is speaking out of both sides of their mouth (so what's new about this from Intel?). While they are publicly saying they are going to remove the '386 loadall (opcode 0f07) in the next stepping, they in fact have no intension of removing it at all. They just want people to quit calling them asking about the instruction. So by threatening to remove it, people will be afraid to use it. Another source (not inside Intel) claims that the '386 Loadall (0f07) is also on the '486 mask. I don't have any '486's at work yet to verify this, so I make no claim to its validity. I have a written document from Intel stating their intension to remove the '386 loadall from the next mask...but that doesn't mean I believe it. In fact, to the contrary, I don't believe it. I subscribe to the theory that Intel is just tired of the phone calls. -- "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
mslater@cup.portal.com (Michael Z Slater) (06/06/89)
>Although I don't speak for Intel and have no involvement with the chip >designers, I've heard from a reliable source that future steppings of the >Intel386(tm) will NOT recognize the LOADALL instruction. Intel is rewriting >all 386 software which includes LOADALL; I suspect the gang in Redmond is >doing the same, but that's pure speculation. I'd strongly encourage everyone >to avoid using LOADALL on a 386. I've heard the same thing about the 386 LOADALL, and indeed, as I understand it, there is no good reason to use it anyway. The 286 LOADALL, on the other hand, is genuinely useful, and widely used. I think it is absurd that Intel has refused to publicly document it. Incidentally, I published full details on the 286 loadall in the Oct. 87 issue of Microprocessor Report. I'm working on a 386 LOADALL article, and would appreciate any input users may have. As I said above, my understanding at this point is that it should not be used, but I think programmers should be able to make their own decisions. Also, if Intel gives the info to some companies and not others, it creates an unfair situation. Michael Slater, Editor and Publisher, Microprocessor Report 550 California Ave., Suite 320, Palo Alto, CA 94306 mslater@cup.portal.com 415/494-2677 fax: 415/494-3718
jls@killer.DALLAS.TX.US (Jerome Schneider) (06/08/89)
In article <30480@conexch.UUCP>, rob@conexch.UUCP (Robert Collins) writes: > [,,,, edited...] > I have a written document from Intel stating their intension to remove > the '386 loadall from the next mask...but that doesn't mean I believe > it. In fact, to the contrary, I don't believe it. I subscribe to the > theory that Intel is just tired of the phone calls. Is the LOADALL instruction disabled except for core privilege level? If not, it would please me greatly for Intel to remove such a dastardly code from new *86 chips. How can a reliable multi-tasking system protect itself if some process executes garbage that happens to contain a LOADALL. Is this the new virus for 386/ix? -- Jerome Schneider UUCP: killer.DALLAS.TX.US!jls (guest account) Aspen Technology Group Ft. Collins, CO Voice: (303) 484-8466
peter@guardian.UUCP (peter) (06/13/89)
In article <19154@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes [edited]: >Incidentally, I published full details on the 286 loadall in the Oct. 87 >issue of Microprocessor Report. [...] Also, if Intel >gives the info to some companies and not others, it creates an unfair >situation. > >Michael Slater, Editor and Publisher, Microprocessor Report >550 California Ave., Suite 320, Palo Alto, CA 94306 >mslater@cup.portal.com 415/494-2677 fax: 415/494-3718 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 97124-6497 Internet: peter@langlab1.hf.intel.com +1 503-696-5219 UUNET : uunet!littlei!langlab1!peter UUCP : tektronix!psu-cs!foobar!langlab1.hf.intel.com!peter -------------------------------------------------------------------------------
mslater@cup.portal.com (Michael Z Slater) (06/15/89)
>>Incidentally, I published full details on the 286 loadall in the Oct. 87 >>issue of Microprocessor Report. [...] Also, if Intel >>gives the info to some companies and not others, it creates an unfair >>situation. >> >>Michael Slater, Editor and Publisher, Microprocessor Report >>550 California Ave., Suite 320, Palo Alto, CA 94306 >>mslater@cup.portal.com 415/494-2677 fax: 415/494-3718 > >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 97124-6497 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). Incidentally, the full text of my Sept. 87 article was posted to the net, although this was done without my permission and without attribution. I wouldn't really object if the poster had at least given credit. Michael Slater, Microprocessor Report mslater@cup.portal.com