4rst@unmvax.cs.unm.edu (Forrest Black) (12/28/89)
Hello! I'm looking for information on the undocumented 80[2,3]86 LOADALL
instruction. I think maybe the information I'm looking for passed by on
the net a while back, but that must have been before I started reading news.
I have had a hard time getting any concrete information on this matter, so
it's time to turn to all you netlanders for help! Here's what I do know:
o The instruction is encoded (0fh 05h) on 286, and (0fh 07h) on 386.
o The instruction is supposed to load some or all of the machine state
from a table in low memory (0080h:0000h).
- I have verified the above. I put a tell-tale pattern at 80:0, and some
of the registers had pieces of the pattern in them when I managed to
regain control (I put a handler on the illegal instruction trap).
o The instruction is reportedly a diagnostic tool reserved by Intel, but
some software houses have used it in applications (rumor).
What I would like to know:
? The format of this table in low memory.
? Whether a complementary instruction STOREALL exists.
? The real purpose behind this bizarre instruction.
If anybody out there can help me, it would be greatly appreciated!
Thanks in advance. Please e-mail:
4rst@doc.cs.unm.edu or ...{ucbvax,gatech,rice}!unmvax!4rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Hello, 4rst! Welcome to Asidonhopo's Panamanian Party Shoppe! %
% ------- %
% ---------- ######################### 4rst@doc.cs.unm.edu |!]%/%| %
% |.{......| # # aka Forrest Black |)!=??| %
% |........+#### I speak for myself ## ...unmvax!4rst |.@..1| %
% |........| and my little dogg #### ----@-- %
% --+------- Toto only. We are # ############################d %
% ############ guests of the Wiz. ## # + + + # %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%ts@cup.portal.com (Tim W Smith) (12/30/89)
One good(?) use for LoadAll is to allow real mode access to memory above 1 meg on a 286 in real mode. This works because the 286, even in real mode, uses the base registers associated with DS and ES. These are normally zero in real mode, and there is no normal way to change them ( in protected mode, they are updated whenever DS or ES are changed ). This comes in real handy for 286 boot code that wants to load a protected mode operating system, such as Unix, that might not fit into the first meg, when the boot code must run in real mode because it wants to use ROM BIOS code that would freak out if the 286 were in protected mode. On the 386, this is not a problem, since you can simply switch between real and protected mode in the boot code. Tim Smith
mmm@cup.portal.com (Mark Robert Thorson) (01/01/90)
What Tim implied, but didn't say explicitly, was that switching to protected mode on a 286 is a one-way trapdoor. Can't get back to real-address mode. This is why MS-DOS on the 286 must run in real mode (8086 compatibility mode) because it needs to run 8086/8 binaries. On the 386, this isn't a problem, because you can switch back to real-mode after loading the "invisible" part of the segment registers. This lets you set up addressing beyond the first 1 Mbytes of address space.
rob@prism.TMC.COM (01/02/90)
Another use for LOADALL is in DOS software that accesses extended memory. The more standard method of switching to protected mode and then resetting the CPU to re-enter real mode is too slow for some purposes. LOADALL, though hardly elegant, allows access to memory above the 1Mb line without having to switch modes. Microsoft's ramdisk and disk-caching programs use LOADALL for accessing extended memory on a 286. As has been noted, the 386 and 486 can switch much more easily between real and protected modes, making LOADALL less useful. In protected mode, LOADALL could theoretically be used to get around the CPU protection, since it allows you to directly set the 'shadow' segment registers. In practice, the problem of setting up a table at an absolute address under protected mode, plus the fact that LOADALL is supposedly a priviledged instruction, would make this difficult. Intel is pretty adamant about avoiding LOADALL, and guards information about it closely. I've never seen any 'official' documentation of it, though such documentation undoubtedly exists.
aland@infmx.UUCP (Dr. Scump) (01/08/90)
In article <25528@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >What Tim implied, but didn't say explicitly, was that switching to protected >mode on a 286 is a one-way trapdoor. Can't get back to real-address mode. >This is why MS-DOS on the 286 must run in real mode (8086 compatibility mode) >because it needs to run 8086/8 binaries. You *can* switch back to real mode on the 286 -- it's possible, though not trivial. The basic strategy is to save off the registers, etc. and then trigger a reset of the '286 via the keyboard controller (which makes the 286 start up in real mode). Then, restore the registers, etc. and away you go! (over-simplified, but this is the gist of it). PS/2s have some other method of resetting the 8086 to real mode, but I'm not sure how it is done. This is how protected-mode DOS extenders work, e.g. DOS/16M (which is used in Informix's DOS products and in Lotus 1-2-3 Release 3.0). As you indicated, the 386 has instructions to switch between each of the four(?) modes: real, protected (286), native, and virtual 8086. -- Alan S. Denney @ Informix Software, Inc. "We're homeward bound {pyramid|uunet}!infmx!aland ('tis a damn fine sound!) -------------------------------------------- with a good ship, taut & free Disclaimer: These opinions are mine alone. We don't give a damn, If I am caught or killed, the secretary when we drink our rum will disavow any knowledge of my actions. with the girls of old Maui."
rob@prism.TMC.COM (01/11/90)
aland@infmx.UUCP writes: >You *can* switch back to real mode on the 286 -- it's possible, though >not trivial. The basic strategy is to save off the registers, etc. >and then trigger a reset of the '286 via the keyboard controller (which >makes the 286 start up in real mode). Then, restore the registers, >etc. and away you go! (over-simplified, but this is the gist of it). This is the method that's been aptly described as 'turning off the car to change gears.' It, along with 64K segments, is something Intel may never live down. In fairness, the 286 was designed before the DOS invasion, and before anyone realized that jumping between real and protected mode would be important. The 286 manuals contain amusing (in retrospect) statements saying, roughly, 'Real mode is used primarily to set the 80286 up for protected mode operation.' I wonder which CPU will _really_ be the first to be used mostly in protected mode. >This is how protected-mode DOS extenders work, e.g. DOS/16M (which >is used in Informix's DOS products and in Lotus 1-2-3 Release 3.0). It's also used by OS/2 to run the DOS compatibility box on a 286, and by 286 BIOSes. RAM disks and disk caches using extended memory often use this method, though some use LOADALL. >the 386 has instructions to switch between each of >the four(?) modes: real, protected (286), native, and virtual 8086. In a way, the 386 still has only two modes - real and protected. 386 protected mode has 'sub-modes', selectable on a task-by-task basis, that let it handle 16 or 32 bit code, and, based on a bit in the flags register, adjust its segment arithmetic to run real mode code ('Virtual 86'). And, it can switch back to real mode fairly easily.
james@bigtex.cactus.org (James Van Artsdalen) (01/15/90)
In <208300003@prism>, rob@prism.TMC.COM wrote: > As has been noted, the 386 and 486 can switch much more easily > between real and protected modes, making LOADALL less useful. LOADALL generates an illegal opcode exception (INT 6) on a 386. I haven't tried a 486, but I assume it does the same thing. > Intel is pretty adamant about avoiding LOADALL, and guards > information about it closely. I've never seen any 'official' > documentation of it, though such documentation undoubtedly exists. I've never understood that secrecy. The instruction IS used by software, notably some versions of OS/2, so a BIOS supplier for a 386 does have to know enough about it to emulate it. I don't see what Intel has to gain from not documenting it - lack of documentation just slows compatible 386 BIOS development. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789