Robert Collins writes about low-level x86 internals, including LOADALL, protected mode, system management mode and the Pentium F00F bug, from his Dr. Dobb's articles.
HN links it as a reference on undocumented x86 instructions and CPU quirks, such as LOADALL, ICEBP and 80186 detection.
Related:
"Intel's System Management Mode by Robert R. Collins" Dr. Dobbs Journal, Jan 1997 (apparently):
http://www.rcollins.org/ddj/Jan97/Jan97.html
>"When comparing ICE mode to System Management Mode,
you could easily conclude that SMM was derived from ICE mode because their similarities are striking.
Certainly, they have more similarities than differences. In reality, SMM appears to be both a subset and a superset of ICE mode. For the purposes of this comparison, I'll contrast 80386 ICE mode with Pentium SMM. Consider the following similarities:
o Both modes use a microprocessor input pin to trigger invocation. On the 80386 DX, this undocumented pin is located at position B6. On SL-enhanced Intel microprocessors, this pin is named SMI#.
o Both modes use a microprocessor output pin to indicate when in ICE or SMM mode. On the 80386 DX, this undocumented pin is located at position C7. On SL-enhanced Intel microprocessors, this pin is named SMIACT#.
o Both modes may be entered from any processor mode at any time by asserting the applicable input pin.
o Both modes have the ability to resume to any processor mode and to any CPL upon completion.
o Both modes save the entire microprocessor state to a state-save map upon entrance.
o The state-save map area is in a protected memory space, isolated from user memory.
o Both modes restore the entire microprocessor state from the state-save map. Neither LOADALL nor the SMM- equivalent RSM instruction sanity check the data…
I was informally referring to the insert and the much later lookup as "2 lookups."
> I'm not sure what you refer to with "huge pages" though. Can you elaborate or provide some info?
CPUs for servers and desktops made within my lifetime (?) use what's called a translation lookaside buffer (TLB) to cache some of the most recently used mappings from virtual pages to physical pages. Page sizes on commonly used CPUs are 4KB except for Apple Silicon which uses 16KB pages. Since at least 1996[0], consumer CPUs have shipped with the ability to use 2MB (or larger) pages in addition the default page size. This capability is awkwardly exposed on Linux. Linux users can either use transparent huge pages, which will slowly replace 2MB-aligned 2MB regions allocated by long-running programs with huge pages, or they can use hugetlbfs to directly request huge pages when calling mmap. Windows nominally supports this feature and calls it "large pages," but in practice users can either run their program as administrator right after booting the machine and then never close it or give up. macOS supports this feature since 2016 and calls it "superpages." I haven't used that so I can't comment on how usable it is in practice.
A lot of the runtime of a program like this is TLB misses. So you can just have way, way fewer TLB misses, like >99% fewer, if you use 2MB pages instead of 4KB pages. The mmap man page[1] says how to ask for huge pages when you call mmap. Here are some other[2] pages[3]…
From hands-on experience, I've learned that v86 initially had some severe, ugly warts, which made writing a v86 "hypervisor" way more tedious, and make it run slower, than what seemed reasonable. These limitations were addressed in much later CPUs in the so called "VME" extensions, for which there was apparently quite some drama related to NDAs, and subsequent reverse engineering: https://www.rcollins.org/articles/vme1/
My (long abandoned) toy OS used virtual 8086 to provide "DOS services" support. The idea was that I could focus on the interesting parts of the OS, and outsource everything that I either hadn't gotten to yet, or that I didn't want to get to, to DOS.
That included several devices, the filesystem, an entire shell (command.com isn't great, but better than nothing), even networking through packet drivers if needed. The OS was a "modern" and full protected mode true multitasking OS, but one of its task was the DOS instance you started it from, transplanted as a v86 task, and my OS could just call into that (and vice versa, so you could run DOS programs that call into my OS). Initially, even allocating memory would just ask DOS to do the bookkeeping!
(I never got to implement VME since I made v86 work on itself, and I dropped this toy project once my work fully shifted to working on real OSes at that level anyway.)
Preemptive multitasking is easy; you just hook the timer interrupt and switch stacks in the interrupt handler. The only tricky part is ensuring that your task queues are modified in such a way that an interrupt at the wrong time can't crash the system.
But it's true that, without memory protection, a bug in one program can corrupt all the other programs, too. The 286 did have memory protection, FWIW, and arguably an on-chip MMU: https://en.wikipedia.org/wiki/Intel_80286#Protected_mode https://retrocomputing.stackexchange.com/questions/7683/how-do-you-put-a-286-in-protected-mode http://www.rcollins.org/articles/pmbasics/tspec_a1_doc.html
EUMEL and Oberon handled this by implementing memory protection in the compiler, but obviously that doesn't help with existing MS-DOS applications unless your compiler's source language is 8086 machine code. That's more or less the approach VMWare and QEMU used to virtualize non-virtualizable hardware. Not sure about Soft-ICE.
Also, btw, the 80386 came out in 01985, and DESQview/X came out 7 years later, in 01992.
Does that include all the secret documentation for stuff like LOADALL, ICEBP etc?
http://www.drdobbs.com/undocumented-corner/184410285
http://www.rcollins.org/articles/loadall/tspec_a3_doc.html
You will love this paragraph:
"Unlike the 286 LOADALL, the 386 LOADALL is still an Intel top secret. l do not know of any document that describes its use, format, or acknowledges its existence. Very few people at Intel wil1 acknowledge that LOADALL even exists in the 80386 mask. The official Intel line is that, due to U.S. Military pressure, LOADALL was removed from the 80386 mask over a year ago. However, running the program in Listing-2 demonstrates that LOADALL is alive, well, and still available on the latest stepping of the 80386."
Just imagine whats in Intel chips now due to NSA pressure :/
> But there’s a nuance in that OS/2 1.x used 286 protected mode the way Intel had intended it, by booting into it and never returning to real mode (
OS/2 had the ability to run DOS programs in a DOS box. my recollection was that OS/2 had to switch back to real mode to do this (thereby suspending all the OS/2 native processes.)
Windows 3.0 in standard (286) mode did something similar.
All this was done with triple faulting, iirc: http://www.rcollins.org/Productivity/TripleFault.html
> Steven Sinofsky writes about it in his personal Microsoft history:
You might like Larry Osterman's recollection of this, if you haven't already seen it:
https://www.landley.net/history/mirror/ms/davidweise.html