x86-64 is the 64-bit extension of the x86 instruction set architecture, the contract that defines which instructions, registers and memory addressing modes a processor exposes to software. In hardware terms, it is the architecture implemented by the mainstream desktop, laptop and server processors from Intel and AMD, and it remains fully able to run older 32-bit and 16-bit x86 code.
AMD introduced the extension under the name AMD64 in the early 2000s, and Intel later adopted a compatible version called Intel 64. Operating systems and compilers use neutral names such as x86-64, x64 and amd64 for the same architecture. Within the Processors topic, it is the main counterpart to ARM64, the other dominant instruction set in modern computing.
How x86-64 extends the original x86 design
x86-64 extends the 32-bit IA-32 architecture by widening the general-purpose registers to 64 bits, doubling their number from 8 to 16, and adding a new execution mode called long mode. Existing instructions keep their encodings, and a new REX prefix byte selects 64-bit operands and the additional registers R8 to R15.
The extension also made SSE2 a mandatory baseline, so every x86-64 processor can perform scalar and vector floating-point math in the 16 XMM registers instead of relying on the old x87 stack. This single change gave compilers a predictable floating-point model and noticeably cleaner code generation.
Another important addition is RIP-relative addressing, which lets code reference data relative to the current instruction pointer. It makes position-independent code cheap, which matters for shared libraries and for address space layout randomization, a common security hardening technique.
The following table summarizes the main architectural differences between the 32-bit and 64-bit generations of the instruction set.
| Feature | IA-32 (32-bit x86) | x86-64 |
|---|---|---|
| General-purpose registers | 8 registers of 32 bits | 16 registers of 64 bits |
| Vector registers | 8 XMM registers (with SSE) | 16 XMM registers, 32 with AVX-512 |
| Virtual address space | 4 GiB per process | 48-bit (256 TiB) or 57-bit (128 PiB) |
| Physical addressing | Up to 64 GiB with PAE | Up to 52 bits defined by the architecture |
| Floating-point baseline | x87 stack, SSE optional | SSE2 guaranteed |
| Data addressing | Absolute addresses common | RIP-relative addressing available |
Operating modes and memory addressing
An x86-64 processor can run in several operating modes, and the operating system chooses which one applies at a given moment. This layered design is the reason a 64-bit system can still execute decades-old 32-bit applications without emulation.
| Mode | Sub-mode | What runs there |
|---|---|---|
| Long mode | 64-bit mode | 64-bit operating system kernels and applications |
| Long mode | Compatibility mode | 32-bit applications on a 64-bit operating system |
| Legacy mode | Protected mode | 32-bit operating systems such as older Windows releases |
| Legacy mode | Real mode | 16-bit boot code and early firmware stages |
Although registers are 64 bits wide, current processors do not use all 64 address bits. Most implementations support 48-bit virtual addresses with four-level paging, while newer server and client chips offer five-level paging with 57-bit addresses. Addresses must be canonical, meaning the unused upper bits copy the highest implemented bit, and a non-canonical address triggers a fault.
Physical memory limits depend on the specific processor and platform, not only on the architecture. A desktop chip and its motherboard may support 128 GiB to 256 GiB of RAM, whereas server platforms address several terabytes per socket.
Instruction set extensions and microarchitecture levels
x86-64 is not a fixed instruction set but a base architecture with optional extensions that software detects at run time with the CPUID instruction. Vector extensions such as SSE4.2, AVX, AVX2 and AVX-512 add wider registers and new operations that speed up media, compression, cryptography and scientific workloads.
To simplify software targeting, compiler and operating system vendors agreed on microarchitecture levels that bundle common extensions. A program built for a higher level runs faster on modern chips but fails with an illegal instruction error on processors that lack the required features.
| Level | Main additions | Typical hardware |
|---|---|---|
| x86-64 (baseline) | SSE, SSE2, CMPXCHG8B | Every 64-bit x86 processor |
| x86-64-v2 | SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT | Most processors from about 2009 onward |
| x86-64-v3 | AVX, AVX2, FMA, BMI1, BMI2, MOVBE | Mainstream processors from about 2013 to 2015 onward |
| x86-64-v4 | AVX-512 foundation and common subsets | Selected server and workstation processors |
Beyond the instruction set, the microarchitecture decides real performance. Modern x86-64 cores decode variable-length instructions into internal micro-operations, execute them out of order, and keep frequently used micro-operations in a dedicated cache. Two processors that share the same architecture can therefore differ widely in instructions per clock, clock speed and power draw.
x86-64 compared with ARM64
The most relevant comparison in the Processors topic is with ARM64, also called AArch64. Both are 64-bit architectures, but they follow different design philosophies and business models, which shapes where each one dominates.
| Aspect | x86-64 | ARM64 |
|---|---|---|
| Instruction encoding | Variable length, 1 to 15 bytes | Fixed length, 4 bytes |
| Design heritage | Complex instruction set (CISC) | Reduced instruction set (RISC) |
| General-purpose registers | 16 (32 with APX extensions) | 31 |
| Memory ordering model | Relatively strong (TSO-like) | Weakly ordered |
| Licensing model | Designed by Intel and AMD | Architecture licensed to many chip designers |
| Main strongholds | Desktops, workstations, many servers | Phones, tablets, many laptops, growing in servers |
The common claim that CISC is inherently slower than RISC is largely outdated. Internally, x86-64 cores translate instructions into simple micro-operations, so the differences now show mostly in decoder complexity and power efficiency, while the software ecosystem and compatibility often decide platform choice more than raw architecture.
Practical considerations and common pitfalls
For buyers and administrators, x86-64 compatibility is a given on any current PC, so the practical questions concern supported extensions, core counts and platform limits. For developers and packagers, the choice of target level and the handling of legacy code matter far more.
- Choosing too high a target level produces binaries that crash on older but still common processors; ship a baseline build or use runtime dispatch.
- Pointer size doubles to 8 bytes, so pointer-heavy data structures consume more memory and cache than in 32-bit builds.
- Data models differ by operating system: Linux and macOS use LP64 with 64-bit long, while Windows uses LLP64 with 32-bit long.
- Calling conventions differ as well: the System V ABI passes six integer arguments in registers, the Windows x64 convention passes four.
- 64-bit operating systems cannot run 16-bit applications directly in long mode; virtualization or emulation is required.
Another pitfall is assuming that AVX-512 is universally available. Its support varies between product lines and generations, and code that relies on it must always check CPUID flags first and fall back to AVX2 or SSE paths when the feature is absent.
Explained without jargon
Every processor understands a specific language of basic commands. x86-64 is the language spoken by the processors in most Windows PCs, many Linux machines and a large share of servers. It is an upgraded version of an older language that could handle numbers and memory only in 32-bit chunks.
The upgrade made the chip’s working slots twice as wide and twice as numerous, so it can juggle more data at once and use far more memory than 4 GB. Crucially, it still understands the old language, which is why older programs keep working on new computers. Phones and many newer laptops use a different language, ARM64, so software must be built separately for each.
A typical use case
A software team distributes a video conversion tool for Windows and Linux desktops. Its encoding loops are heavy on vector math, so building for x86-64-v3 with AVX2 and FMA speeds up conversions considerably on modern machines. However, support tickets show that some customers still run office PCs with processors that lack AVX2.
The team therefore compiles the core encoding functions twice, once for the baseline x86-64 level and once for v3, and uses CPUID at startup to select the faster path when it is available. Users with recent processors get the full vector speedup, while older machines still run the tool correctly instead of crashing with an illegal instruction error. The outcome is one installer that works everywhere and performs well where the hardware allows it.