 |
This article needs additional citations for verification. Please help improve this articlebyadding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Long mode" – news · newspapers · books · scholar · JSTOR (September 2023) (Learn how and when to remove this message) |
| Part of a series on |
| Microprocessor modes for the x86 architecture |
|---|
|
| First supported platform shown in parentheses |
|
|
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 modeorvirtual 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.
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.
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 (16exabytes) of virtual address space and 252 bytes (4petabytes) of physical address space.
Physical address space increased to 48 bits.
A guide to the new features of long mode
