Architectural features

AMD’s x86-64 instruction set (later renamed AMD64) is an extension of Intel’s IA-32 (x86-32) architecture, created as an alternative to Intel and Hewlett Packard’s radically different IA-64 architecture which has received a relatively cool market reception in many market sectors, and which was protected from cloning by a number of patents. The primary defining characteristic of AMD64 is its support for 64-bit general purpose registers, 64-bit integer arithmetic and logical operations, and 64-bit virtual addresses. The designers took the opportunity to make other improvements as well. The most significant changes include:
Full support for 64-bit integers: All general-purpose registers (GPRs) are expanded from 32 bits to 64 bits, and all arithmetic and logical operations, memory-to-register and register-to-memory operations, etc., are now directly supported for 64-bit integers. Pushes and pops on the stack are always in eight-byte strides, and pointers are eight bytes wide.
Additional registers: In addition to increasing the size of the general-purpose registers, their number is increased from eight (i.e. eax,ebx,ecx,edx,ebp,esp,esi,edi) in x86-32 to 16. It is therefore possible to keep more local variables in registers rather than on the stack and to let registers hold frequently accessed constants — this should be a significant area of speed improvement for software with computationally-intensive deeply-nested loops; arguments for small and fast subroutines may also be passed in registers to a greater extent. However, more registers also involves more saving and restoring of register contents, and AMD64 still has fewer registers than many common RISC processors (which typically have 31-64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers).
Additional XMM registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16.
Larger virtual address space: Current processor models implementing the AMD64 architecture can address up to 256 tebibytes of virtual address space (248 bytes). This limit can be raised in future implementations to 16 exbibytes (264 bytes). This is compared to just 4 gibibytes for 32-bit x86. This means that very large files can be operated on by mapping the entire file into the process’s address space (which is generally faster than working with file read/write calls), rather than having to map regions of the file into and out of the address space.
Read the rest of this entry »