Robert Collins

It may be official, but relying on undefined flags can fail: http://www.rcollins.org/ddj/Sep96/Sep96.html http://www.rcollins.org/ddj/Nov96/Nov96.html For detecting the 80186, I'd recommend using a shift instruction with a count of 33. The 186 and later processors will mask it with 0x1F, resulting in a shift by 1 instead. A shift count of 32 would also behave differently, but not set any flags because a shift by 0 effectively becomes a NOP. This is true even on x86-64, only for 64 bit operands is the count masked with 0x3F.

Thanks! I wasn't aware of these, despite being a subscriber for a couple of years. This seems to be an online collection of these articles: http://www.rcollins.org/ddj/ddj.html

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 :/

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.)

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…

There's some info here: http://www.rcollins.org/secrets/ http://www.rcollins.org/ddj/ddj.html Notably things like undocumented opcodes, processor modes, undocumented registers, undocumented bits within registers, etc. It's not uncommon to release a specific set of documentation to trusted partners only. Back in the day intel called these "gold books".

Robert Collins' article lists some of these methods, mostly centered around flag bits behavior: http://www.rcollins.org/ddj/Sep96/Sep96.html

The descriptor cache is 96 bits per segment register (http://www.rcollins.org/ddj/Aug98/Aug98.html) so the 12 registers might be the bases and limits with the extra metadata stored somewhere else. It might also be that each limit is fewer than 32 bits since the encoding for segment limits uses 21 bits in memory.

> 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

> It was easy to measure the length of the prefetch queue by a self-modifying program It became hard on the 386, as linked in the article: http://www.rcollins.org/secrets/PrefetchQueue.html

This reminds me of how people used to use machine code which exposed and tested for slight differences in processors to detect x86 processor versions before CPUID: http://www.rcollins.org/ddj/Sep96/Sep96.html

> A team at IBM eventually figured out that with a well crafted dance of instructions this could be achieved by taking advantage of specific quirks within the chip. Details are described at [1], tl;dr: - store register values in RAM - set magic value in CMOS - cause triple fault to reset CPU - BIOS sees magic value and instead of resetting rest of the system, it resumes from your stored state in real mode So it's more like a BIOS quirk. A20 gate backward compatibility on the other hand ... [1] - http://rcollins.org/articles/pmbasics/tspec_a1_doc.html

MSRs are interesting. There are a lot more than are documented, and since they came into existence, people have been exploring them: http://archive.gamedev.net/archive/reference/articles/article213.html http://www.rcollins.org/Errata/Jan97/Bugs.html

Well, you could exit protected mode - but it was a bit hacky in some respects. See 'Exiting Protected Mode': http://rcollins.org/articles/pmbasics/tspec_a1_doc.html

XlogicX wasn’t complaining about the existence of the AAD and AAM instructions. He was complaining that they had useful variants that couldn’t be expressed in assembly. edit: See http://www.rcollins.org/secrets/opcodes/AAD.html

Has happened in the past... http://www.rcollins.org/secrets/opcodes/SALC.html

What about the infamous i386 LOADALL instruction? Certainly there is at least one that is kept secret. http://www.rcollins.org/articles/loadall/tspec_a3_doc.html

For the curious: http://www.rcollins.org/ddj/May98/F00FBug.html I'd be curious to know if this is was intentional, or a side-effect of the emulation.

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]…

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… 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.