Documented Intel 64 processors begin from a reset state associated with the 8086’s real-address mode; AMD’s processor documentation likewise says CPUs initially enter real mode after reset, as reported by XDA Developers. That inherited starting point matters because firmware—and, through a separate startup mechanism, operating systems bringing up additional cores—must move on from it. Intel describes the Intel 64 reset state as the same state as the original 8086 in its official X86S paper.
What real mode means at startup
In the conventional real-mode address calculation, a segment value shifted left four bits is added to an offset: (segment << 4) + offset. With 16-bit segment and offset values, that gives a nominal 20-bit address space of 1 MiB. It is a useful model of familiar real-mode addressing, but it does not describe every detail of a modern processor’s reset state.
For example, XDA Developers reports that Intel and AMD processor manuals specify a reset fetch address of FFFFFFF0h, just 16 bytes below 4 GiB. The processor’s hidden code-segment base is part of this special reset state, so the initial fetch is not simply an 8086-style address produced by the conventional formula. UEFI does not change the processor’s reset architecture: firmware starts from the reset state and moves into later operating modes. An operating-system bootloader on a UEFI-only system need not itself run in real mode.
Real mode is not a complete 8086 emulation
The 8086 comparison is about an inherited execution state, not a modern CPU impersonating every detail of that processor. As the OS/2 Museum’s technical explanation of real-mode segmentation describes, segment registers have hidden attributes as well as visible values. Loading a segment register changes its selector and hidden base, while limits and other attributes can remain tied to descriptor state. That makes the boundary between real and protected mode more involved than flipping a mode bit.
The practical wrinkle appears when software tries to return to real mode. In an OSDev.org discussion of a specific QEMU operating-system project, participant nullplan explained that a far jump alone does not clear the segment attributes retained from protected mode. The response recommends loading suitable 16-bit code and data descriptors while still in protected mode before completing that transition. It is a detail worth tracking when debugging low-level startup code: the visible segment value is not the whole processor state.
Why additional cores can still use 16-bit startup code
The first processor core and the others have different startup jobs. Under the traditional mechanism, an operating system sends an INIT signal and then a Startup Inter-Processor Interrupt (SIPI) to an additional core. The SIPI vector points to startup code below 1 MiB, where that core begins in real mode. Intel’s X86S paper says a mode-only design would need a 64-bit replacement for this startup mechanism.
Adam Conway’s reported tests and code inspection at XDA Developers show how the legacy path persists in particular systems. In a QEMU/OVMF test, Conway counted 18 distinct real-mode instruction addresses on the ordinary firmware path before it switched to protected mode. In a separate QEMU test of Linux 6.18 starting a second core, he counted 67 16-bit instructions in the startup sequence. Those figures describe different paths and tests, not a universal instruction count. Conway also identified real-mode startup stubs in Windows 11 build 10.0.28000.3086.
What Intel’s X86S proposal would change
Intel proposed X86S as a simplified, 64-bit-only architecture. The proposal called for direct startup in 64-bit paged mode and a replacement for traditional SIPI-based startup. That would remove legacy transition steps from the proposed startup design, while requiring new mechanisms for starting additional cores and accommodating compatibility needs.
| Startup design | Initial state | Starting additional cores | Status |
| Documented x86 startup | Reset state associated with 8086 real mode | Traditional INIT/SIPI sequence with a real-mode startup trampoline | Intel documents the reset behavior; the traditional mechanism remains relevant to firmware and operating-system startup code |
| Intel X86S proposal | Direct 64-bit paged mode | A proposed 64-bit replacement for SIPI startup | Intel chose not to pursue the proposal |
Intel says it chose not to pursue X86S based on input from the ecosystem. The company also describes a longstanding commitment to software compatibility and a broad installed software ecosystem; those statements provide Intel’s published context for the proposal, not a more specific stated cause for ending it. Its paper explains that a legacy 64-bit operating system could be supported through virtualization, while the proposed CPU and secondary-core startup paths would need replacements.
