Long mode

From Wikipedia, the free encyclopedia

In the x86-64 computer architecture, long mode is the mode where a 64-bit operating system can access 64-bit instructions and registers. 64-bit programs are run in a sub-mode called 64-bit mode, while 32-bit programs and 16-bit protected mode programs are executed in a sub-mode called compatibility mode. Real mode or virtual 8086 mode programs cannot be natively run in long mode.


An x86-64 processor acts identically to an IA-32 processor when running in real mode or protected mode, which are supported modes when the processor is not in long mode.

A bit in the CPUID extended attributes field informs programs in real or protected modes if the processor can go to long mode, which allows a program to detect an x86-64 processor. This is similar to the CPUID attributes bit that Intel IA-64 processors use to allow programs to detect if they are running under IA-32 emulation.

With a computer running legacy BIOS, the BIOS and the boot loader run in real mode. After execution passes to an operating system kernel which supports x86-64, the kernel verifies CPU support for long mode and then executes the instructions to enter it. With a computer running UEFI, the UEFI firmware (except CSM and legacy Option ROM), any UEFI boot loader, and the operating system kernel all run in Long mode.

Memory limitations[edit]

While register sizes have increased to 64 bits from the previous x86 architecture, memory addressing has not yet been increased to the full 64 bits. For the time being, it is impractical to equip computers with sufficient memory to require a full 64 bits. As long as that remains the case, load/store unit(s), cache tags, MMUs and TLBs can be simplified without any loss of usable memory. Despite this limitation, software is programmed using full 64-bit pointers, and will therefore be able to use progressively larger address spaces as they become supported by future processors and operating systems.

Current limits[edit]

The first CPUs implementing the x86-64 architecture, namely the AMD Athlon 64 / Opteron (K8) CPUs, had 48-bit virtual[1]: 129–130  and 40-bit physical addressing.[1]: 4 

The virtual address space of these processors is divided into two 47-bit regions, one starting at the lowest possible address, the other extending down from the largest. Attempting to use addresses falling outside this range will cause a general protection fault.

The limit of physical addressing constrains how much installed RAM is able to be accessed by the computer. On a ccNUMA multiprocessor system (Opteron) this includes the memory which is installed in the remote nodes, because the CPUs can directly address (and cache) all memory regardless if it is on the home node or remote. The 1 TB limit (40-bit) for physical memory for the K8 is huge by typical personal computer standards, but might have been a limitation for use in supercomputers. Consequently, the K10 (or "10h") microarchitecture implements 48-bit physical addresses and so can address up to 256 TB of RAM.[2]

When there is need, the microarchitecture can be expanded step by step without side-effects from software and simultaneously save cost with its implementation. For future expansion, the architecture supports expanding virtual address space to 64 bits, and physical memory addressing to 52 bits (limited by the page table entry format).[3] This would allow the processor to address 264 bytes (16 exabytes) of virtual address space and 252 bytes (4 petabytes) of physical address space.

See also[edit]


  1. ^ a b "AMD64 Architecture Programmer's Manual Volume 2: System Programming" (PDF). 2016. Retrieved 2015-04-09.
  2. ^ "BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors" (PDF). p. 30. Retrieved 2015-04-09. Physical address space increased to 48 bits.
  3. ^ AMD 2016, p. 24: "The AMD64 architecture enhances this support to allow translation of 64-bit virtual addresses into 52-bit physical addresses, although processor implementations can support smaller virtual-address and physical-address spaces."

External links[edit]