Why Do We Still Have 16-Bit 8086 Support Anymore?

A thread here poses the question: why do new CPUs still support 16-bit real mode when all of the operating systems are moving to 64-bit long mode. I had to stop and think about that, since I've been working in BIOS since 286s were news and 386s were revolutionary.  I remember I went to the seminar in Santa Clara, CA where Intel detailed the 386 architecture in front of a packed house.

So, here are my top 5 reasons why we still have 16-bit support in x86 CPUs:

#5. Can't Get Started Without It. When an x86 CPU is reset, it returns to 16-bit real mode and starts execution at 0xFFFFFFF0. Since this address is outside of the normal 16-bit address space (which, with segment registers, is limited to 1MB), the CPU folks play tricks with the CS selector cache. In x86 CPUs, the current instruction location is CS:IP, where CS is the code segment (real mode) or selector (protected mode) and IP is the instruction pointer. To calculate the linear address in real mode, you multiply CS by 16 and add IP. In protected mode, you use CS as an index into the descriptor table and look up the linear address before adding it to IP. Paging adds yet another level. So, rather than calculating or looking up the CS linear address each instruction, the CPU caches it and then only changes the cached value when you change the CS register or modify the descriptor table. So, in order to execute the code at 0xFFFFFFF0, the CPU designers set CS to FFFF, but set the cached version of CS to 0xFFFFFFF0. Normally the first instruction is a JMP FAR instruction, which forces a reload of CS (and thus, the cached CS), which causes execution to continue at an address under 1MB.

#4. Long Mode Requires Paging and Paging Requires RAM and RAM Requires Initialization. In order to enter 64-bit long mode, you need to enable paging. 64-bit long mode is actually an attribute of the page descriptors.  When the system resets, there are no page tables set up (since no one has created them) and no place to create them (since RAM has not been initialized yet). It is possible that future CPUs could cache a page table (similar to the CS descriptors above) or require that they be present at a pre-defined location. Until that time, the best you could do for CPU reset would be 32-bit protected mode.

#3. Operating Systems Still Use BIOS Real-Mode Services. Today's operating systems (or their commonly used drivers), including Linux 2.6.x and Vista SP1 still use 16-bit BIOS services. Linux video drivers still rely on INT 10h to handle mode switches, for the most part. Vista SP1 still needs INT 10h for the BSOD to reset the screen mode.

#2. Dos Lives! Some folks still run DOS, especially on manufacturing lines, and are loath to change.

And...the #1 reason why 16-bit real mode still exists today:

#1. Silicon Is Cheap. The 16-bit support is such a small portion of the overall transitor budget for modern CPUs. Removing the feature doesn't gain anything. So, if it ain't broken, don't fix it.

Trivia #1: The segment limits (64KB for real mode) are cached but are not reset when switching segment values, which can be used to allow real-mode data access >1MB. You switch to protected mode, load a selector with 4GB limits and then switch back to real mode. Voila! ds:[esi] can now get all the way to 4GB.  This is the form of real-mode used in System Management Mode, many BIOS' and various DOS utilties.

Trivia #2: The 286 processor's reset address was 0x00FFFFF0 (just below 16MB).

Tim

Comments

[Yuhong Bao]

"The segment limits (64KB for real mode) are cached but are not reset when switch CS"
Should be "switching mode". BTW, this is often called "unreal mode".