The headline is a useful analogy and not a literal claim. Your Ryzen or Core chip is not an 8086. The architecture keeps an initial reset state, and a startup path, that were defined for backward compatibility. Several stages are involved: the CPU's reset state, firmware's early execution, the operating system's boot path, and the waking of additional cores. Keeping them apart avoids most of the confusion on this topic.
What real mode is
Real mode, which Intel calls real-address mode, is the 8086's execution environment. According to the XDA report:
- Registers are 16 bits wide.
- There is no memory protection and no paging.
- Addresses are built by shifting a 16-bit segment value left by four bits and adding a 16-bit offset. That gives a nominal 1MB address space.
Intel's own X86S white paper confirms the core point. Intel says its 64-bit architecture designs come out of reset in the same state as the original 8086 and need a series of code transitions to reach 64-bit mode. The XDA report adds that AMD's documentation says its processors always enter real mode first.
Modern real mode is not a perfect 8086, though. The report notes that current chips support extra segment registers such as FS and GS and 32-bit register prefixes. It also says Intel's current manual states that the A20M# signal, once used for the old address-wrap compatibility behaviour, "may be absent" on newer processors.
The reset address is the odd part
The original 8086 fetched its first instruction from FFFF0h, 16 bytes below 1MB. The 286 moved this up to the top of its 16MB space by using a hidden segment base. According to the report, modern processors extend the same trick to the top of 4GB. The first instruction comes from FFFFFFF0h, an address the report notes Intel says is beyond real mode's 1MB range.
Open-source firmware shows this in practice. The Gentoo wiki's reset vector table lists the same pattern across generations. It gives 0xffff0 for the 8086, 0xfffff0 for the 286 and 0xfffffff0 for the 386. It also says x86-64 chips do not have a 64-bit reset vector and reuse the 386 location.
EDK II, the open-source UEFI reference code, shows the same pattern. Its reset-vector file is labelled as the first code executed after reset and is written as 16-bit code. In the 32-bit build it starts with two no-ops and a jump into the early startup routine. In the 64-bit build the code first checks a bit in CR0. If that bit is clear, it takes the real-mode path. If it is set, as in an Intel TDX guest, it jumps to 32-bit code. So not every UEFI implementation or environment starts identically, and virtualised confidential guests can start differently.
The report also explains that the hidden base lasts only until firmware reloads the code segment register. Intel therefore warns that startup code must avoid far jumps, far calls and interrupts until it is ready.
Where Windows and Linux come in
On a normal boot, the operating system never sees real mode on the first core. The XDA report says UEFI-only systems no longer need a real-mode bootloader. Windows 11 is 64-bit only, and Intel's white paper notes it stopped shipping a 32-bit Windows 11. The legacy shows up when additional cores are started.
The traditional method is an INIT signal followed by a startup interprocessor interrupt (SIPI). The SIPI vector sets a start address of the form 000VV000h, below 1MB, and the woken core begins in 16-bit mode. Intel's white paper says as much: booting CPUs with SIPI starts in real-address mode today and would need a 64-bit replacement.
Conway's findings, which are his own experiments:
- Firmware (QEMU): QEMU's UEFI firmware ran 18 distinct real-mode instructions on the boot core. With two virtual cores, the firmware reset the second core five times.
- Linux: On a stock Linux 6.18 kernel in QEMU, the second core began in real mode at 99000h and ran 67 16-bit instructions before entering protected mode. The code lives in trampoline_64.S.
- Windows: In Windows 11 build 10.0.28000.3086, he used Microsoft's public symbols to find HalpRMStub, HalpPMStub and HalpLMStub. They correspond to real, protected and long mode. He says HalpRMStub performs the same segment-shifting arithmetic as the 8086. He also credits security researcher Satoshi Tanda with documenting this path in Windows 10 in 2020.
These are single-author tests of specific configurations. I have not been able to reproduce them independently, so treat them as one researcher's observations. They are not a universal rule for every machine. Startup paths also vary. The report says some firmware supports a newer mailbox mechanism that hands cores to the OS already in 64-bit mode, and that Linux supports one.
X86S: the fix that wasn't
In 2023 Intel published X86S, a draft 64-bit-mode-only architecture. Intel's white paper argues that certain legacy modes have little use in modern operating systems beyond bootstrapping the CPU into 64-bit mode. It says a direct 64-bit reset state could eliminate the several stages of trampoline code needed to enter 64-bit operation. The paper also lists removing rings 1 and 2, 16-bit addressing and legacy 8259 interrupt controller support.
Then it stopped. Intel's page now says that, based on inputs from the ecosystem, it has chosen not to pursue X86S. Tom's Hardware reported in December 2024 that an Intel spokesperson confirmed the company had pivoted away from X86S. That came after the x86 Ecosystem Advisory Group was formed with AMD and others.
Intel has never published a detailed reason. Tom's Hardware offered its own view that a change this large would need AMD's cooperation and wider ecosystem support. Intel's layoffs and restructuring might also have played a role. That is the outlet's analysis. It is not an Intel statement, and no source here shows AMD vetoed anything.
The mystery 64-bit-only chip
The most striking claim in the XDA report is unverified. On September 7, 2026, x86 expert Christian Ludloff, who runs Sandpile, reportedly posted to the Linux kernel and binutils mailing lists. He described an unnamed company's processor that he was asked to document. It was said to be 64-bit-protected-mode-only and five-level-paging-only, with FRED and APX support, and to have been used at scale for more than a year.
Treat this with caution. Per the report:
- The vendor is unidentified, and there is no public vendor documentation.
- Phoronix speculated about Zhaoxin, Hygon and RosaicLabs, but none is confirmed.
- No commercially available processor using the design has been identified.
- Ludloff's reset-state annotations imply a direct 64-bit paged start, but they give no new reset address.
Ludloff is a respected x86 authority, but this is still a single-source claim. It does not show that a 64-bit-only x86 chip has shipped.
What this means for Windows users
For everyday users, very little. The XDA report says the legacy code is tiny and has no meaningful effect on everyday performance, and I found nothing contradicting that. Nothing here needs patching or changing.
The practical value is for developers, firmware engineers, virtualisation users and anyone wondering why a 2026 kernel contains 16-bit stubs. Backward compatibility is the reason. Removing real mode would need coordinated changes to the CPU, firmware and operating systems, and the industry has so far preferred not to take that risk.
- Intel and AMD still document real-mode startup.
- Windows 11 still ships a 16-bit startup stub, per the XDA analysis.
- Linux has no feature flag for X86S-style 64-bit startup.
- The advisory group's first-year work (FRED, AVX10, ACE, ChkTag) did not address removing real mode.
For now, the 1978 handshake survives, even if it lasts only a few instructions each time.