Your CPU still boots up pretending to be a 1978 Intel chip, and Intel gave up on removing it

Regardless of whether you're on Intel or AMD, the first instruction your CPU executes runs in a mode designed for the 16-bit Intel 8086, released in June 1978. This is called "real mode," and despite everything that has changed about processors since then, this part of the startup process has remained remarkably similar. Intel itself acknowledges this, stating that "Intel 64 architecture designs come out of reset in the same state as the original 8086." AMD, meanwhile, says that after reset or boot, the processor "always initially enters real mode." It's a very brief part of the boot-up sequence: in my testing, QEMU's UEFI firmware ran just 18 distinct instructions in real mode before switching to 32-bit protected mode and eventually 64-bit long mode. The operating system never encounters real mode on the initial boot core, but both Windows and Linux still ship 16-bit code to initialise additional cores. Intel tried to eliminate this legacy with X86S, but abandoned the proposal in 2024 following industry feedback. Someone else might not have, though. Every x86 core starts in real mode Intel calls it 8086 emulation Real mode, or real-address mode as Intel calls it, is the execution environment of the original 8086. Intel says that "To an 8086 program, a processor operating in real-address mode behaves like a high-speed 8086 processor." In this mode, registers are 16 bits wide, there's no memory protection and no paging, and memory is addressed by taking a 16-bit segment value, shifting it left by four bits, and adding a 16-bit offset to it. That gives you a 20-bit address and a nominal 1MB address space, which was plenty in 1978 and is tiny by any modern standard. When an x86 processor powers up, or when its reset pin is asserted, its registers are set to a known state and the CPU goes into real mode. The reset table for Intel's current processors have the control register CR0 at 60000010h, meaning that protection is off and paging is off, and it's the same value used by AMD for its own chips as well. No matter how powerful your 64-bit CPU is, it's basically just a chip from 1978 at boot until it's told to switch out of it. Modern real mode isn't identical to the original 8086, though. Modern processors support additional segment registers like FS and GS, as well as instruction prefixes that allow access to 32-bit registers, although Intel warns against using these features when maintaining compatibility with the 8086 and 286. The 8086's 20-bit addressing caused addresses beyond 1MB to wrap around to zero, behaviour PCs preserved for decades through the A20 gate. However, Intel's current manual notes that the A20M# signal used to maintain that compatibility "may be absent" on newer processors. The reset address is the part that isn't really 8086 The 286 bent the rules to keep it Intel's 1979 user manual says the reset line sets the code segment register to FFFFh and the instruction pointer to zero, meaning that the first instruction comes from physical address FFFF0h, 16 bytes below the top of the chip's 1MB address space. With only 16 bytes available, that location typically contained a far jump to the actual startup code. The 80286 moved the reset address to 16 bytes below the top of its larger 16MB address space. This gave Intel room for a protected-mode bootstrap loader. The 286 resets with its code segment set to F000h and its instruction pointer at FFF0h, but it also loads a hidden base address of FF0000h into the part of the segment register software can't see; together, you get FFFFF0h. Intel's 1985 programmer's reference explains that a system with only 20 address bits doesn't use the top four bits, making it so the address comes out in exactly the same place as the 8086's reset location. Modern x86 processors extend the same mechanism to the top of the 4GB address space. Intel's and AMD's manuals define the same reset state, with a code segment selector of F000h, a hidden base of FFFF0000h, and an instruction pointer of FFF0h, making it so the first instruction comes from FFFFFFF0h, 16 bytes below 4GB. Intel also highlights that this is something an 8086 couldn't do, stating that "the address FFFFFFF0H is beyond the 1-MByte addressable range of the processor while in real-address mode." That hidden base only lasts until firmware reloads the code segment register, which replaces it with the normal real-mode base calculated by shifting the segment value left by four bits. Until then, Intel warns that startup code "must not contain a far jump or far call or allow an interrupt to occur," as any of those would change the code segment and drop the processor out of the top of memory. And the jump at the top of memory never went away, either. EDK2, the open-source reference implementation of UEFI firmware, places its reset vector at that address, and it's two no-op instructions followed by a jump to the rest of the 16-bit startup code. That's the manual from 1979 still just as applicable almost 50 years later. Modern PCs have largely moved away from legacy BIOS booting, too. Intel announced plans in 2017 to end legacy BIOS support by 2020, and Lenovo subsequently removed the option from many products launched that year. On UEFI-only systems, the operating system's bootloader doesn't need to run in real mode. That's more of a firmware change, though, rather than an architectural one, and the processor still starts in real mode. Every other core goes through it too, and so does your OS Windows and Linux both carry 16-bit code When an x86 system starts, a single core called the bootstrap processor runs the firmware while every other core waits for it to complete. To wake another core, software typically sends an INIT signal followed by a startup interprocessor interrupt (SIPI), which tells it where to begin executing code. Intel defines that starting address as 000VV000h, where VV is the SIPI vector, placing it below 1MB. As we've established, both AMD and Intel state that their cores start in 16-bit mode. Under this traditional startup sequence, additional cores can enter real mode multiple times, as firmware can initialise the cores before the operating system starts them again. In my QEMU test with two virtual cores, the firmware alone reset the second core five times, and each time it ran a short burst of 16-bit code at page-aligned addresses below 1MB before switching up into protected mode. Linux keeps the code for this in a file called trampoline_64.S, and a comment at the top of the file states that on entry "the processor is in real mode with 16-bit addressing and 16-bit data." I booted a stock Linux 6.18 kernel in QEMU with two cores, and after the kernel sent INIT, the second core began executing in real mode at 99000h. It disabled interrupts, flushed its cache, configured its segment registers, and ran verify_cpu before loading its descriptor tables and entering protected mode. That sequence executed 67 16-bit instructions. Linux also uses a separate real-mode stub when resuming from S3 sleep. Windows does the same thing: I examined the kernel from Windows 11 build 10.0.28000.3086 (September 2026) using Microsoft's public debugging symbols and found three functions: HalpRMStub, HalpPMStub, and HalpLMStub, corresponding to real mode, protected mode, and long mode. Disassembled as 16-bit code, HalpRMStub disables interrupts, copies the code segment into the data segment, and shifts its value left by four bits to calculate its physical address. That's the same math as the original 8086, except it's found in a 2026 Windows kernel. It then loads a descriptor table and sets the protected-mode bit. Security researcher Satoshi Tanda documented this startup path in Windows 10 in 2020, and it's still present in Windows 11. On a big server, this means that potentially hundreds of cores can go through this process multiple times, unless the firmware supports a newer mailbox mechanism that hands cores to the OS already in 64-bit mode (Linux supports one, and its code for it mentions Intel's TDX confidential virtual machines). Intel tried to kill real mode, and then it didn't X86S was supposed to be the fix In 2023, Intel proposed X86S, a simplified version of x86 that would eliminate legacy modes, including real mode, 16-bit addressing, and traditional SIPI-based core startup. Intel argued that these modes served little purpose beyond bootstrapping processors into 64-bit mode. The final specification, revision 1.2 from June 2024, proposed starting the CPU directly in 64-bit paged mode, using a four-level page table at a fixed address. The reset address would remain FFFFFFF0h, but execution would begin in 64-bit mode, bypassing real mode entirely. This would mean that additional cores would use a new 64-bit startup interrupt referencing a structure containing their initial state, rather than a SIPI vector pointing below 1MB. None of that happened, though. In December 2024, Intel confirmed to Tom's Hardware that it had abandoned X86S, shortly after forming the x86 Ecosystem Advisory Group with AMD. Intel later changed its X86S page to simply state that "Based on inputs from the ecosystem, Intel has chosen not to pursue X86S." The company never provided a detailed explanation, although Tom's Hardware noted that a change of this magnitude would likely require AMD's cooperation. The advisory group's first year produced initiatives including FRED, AVX10, ACE, and ChkTag, but none addressed removing real mode. Somebody may have already shipped a 64-bit-only x86 chip And nobody will say who The closest thing to X86S out in the wild might not come from Intel or AMD at all. On September 7, 2026, x86 expert Christian Ludloff, who runs Sandpile, shared details of an unnamed company's processor on the Linux kernel and binutils mailing lists. He claimed to have been asked to document a PM64-only, PML5-only implementation supporting FRED and APX that had been used at scale for over a year. PM64 refers to 64-bit protected mode, and PML5 is five-level paging. As Ludloff put it: "Poof! Legacy Mode? Gone! Compatibility Mode? Gone!" Although real mode is only mentioned as a point of comparison, Ludloff also annotated Sandpile's processor reset-state table with the proposed design's changes. Every segment register is marked as extinct, CR0 has protection and paging enabled, and EFER's long-mode bits are permanently enabled. If that's accurate, the chip comes out of reset directly in 64-bit paged mode, with no real mode at any point. However, the table doesn't specify a new reset address, leaving the exact entry point unclear. The manufacturer remains unidentified, there's no public vendor documentation, and the details come solely from Ludloff, albeit an established authority on x86 architecture. Phoronix has linked the disclosure to Ludloff's earlier advisories involving a third-party x86 developer and speculated about Zhaoxin, Hygon, and RosaicLabs, although none has been confirmed. There's also no identified commercially available processor using the design. For now, Intel and AMD still document real-mode startup, Linux has no feature flag for X86S-style 64-bit startup, and Windows 11 still ships a 16-bit startup stub so that everything can keep working as it should. Modern x86 processors spend an incredibly small fraction of their lives in real mode, but firmware and operating systems still have to account for it when initialising CPU cores. The amount of legacy code involved is genuinely tiny, with no meaningful effect on everyday performance. But still, Windows and Linux maintain 16-bit startup code because modern x86 processors continue to inherit a reset behaviour dating back to 1978.