X86-64: Difference between revisions

With 64-bit mode and the new paging mode, it supports vastly larger amounts of [[virtual memory]] and [[physical memory]] than was possible on its [[32-bit computing|32-bit]] predecessors, allowing programs to store larger amounts of data in memory. x86-64 also expands [[general-purpose register]]s to 64-bit, and expands the number of them from 8 (some of which had limited or fixed functionality, e.g. for stack management) to 16 (fully general), and provides numerous other enhancements. [[Floating-point arithmetic]] is supported via mandatory [[SSE2]]-like instructions{{Citation needed|reason=The AMD64 Architecture’s Programmers Manual Volume 1 pg 276f recommends that the programmer checks for SSE2 support, The Xeon Phi claims that it only supports AVX/AVX2/AVX512 and not SSE|date=August 2024}}, and [[x87]]/[[MMX (instruction set)|MMX]] style registers are generally not used (but still available even in 64-bit mode); instead, a set of 16 [[vector registers]], 128 bits each, is used. (Each register can store one or two [[Double-precision floating-point format|double-precision]] numbers or one to four [[Single-precision floating-point format|single-precision]] numbers, or various integer formats.) In 64-bit mode, instructions are modified to support 64-bit [[operands]] and 64-bit [[addressing mode]].

The compatibility mode defined in the architecture allows 16-bit and 32-bit [[user space|user applications]] to run unmodified, coexisting with 64-bit applications if the 64-bit operating system supports them.<ref name="amd-24593">{{cite web|url = http://support.amd.com/TechDocs/24593.pdf|title = Volume 2: System Programming|author = AMD Corporation|date = December 2016|work = AMD64 Architecture Programmer's Manual|publisher = AMD Corporation|access-date = March 25, 2017|archive-date = July 13, 2018|archive-url = https://web.archive.org/web/20180713145424/https://support.amd.com/TechDocs/24593.pdf|url-status = live}}</ref>{{refn|group=note|In practice, 64-bit operating systems generally do not support 16-bit applications, although modern versions of Microsoft Windows contain a limited workaround that effectively supports 16-bit [[InstallShield]] and Microsoft ACME installers by silently substituting them with 32-bit code.<ref>{{cite web|url=https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=2783|title=If there is no 16-bit emulation layer in 64-bit Windows, how come certain 16-bit installers are allowed to run?|author=Raymond Chen|date=October 31, 2013|access-date=July 14, 2021|archive-date=July 14, 2021|archive-url=https://web.archive.org/web/20210714084610/https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=2783|url-status=live}}</ref>}} As the full x86 16-bit and 32-bit instruction sets remain implemented in hardware without any intervening emulation, these older [[executable]]s can run with little or no performance penalty,<ref name="x86-compat-perf">{{cite web|url = ftphttps://ftppublic.softwaredhe.ibm.com/software/webserver/appserv/was/64bitPerf.pdf|title = IBM WebSphere Application Server 64-bit Performance Demystified|page = 14|quote = "Figures 5, 6 and 7 also show the 32-bit version of WAS runs applications at full native hardware performance on the POWER and x86-64 platforms. Unlike some 64-bit processor architectures, the POWER and x86-64 hardware does not emulate 32-bit mode. Therefore applications that do not benefit from 64-bit features can run with full performance on the 32-bit version of WebSphere running on the above mentioned 64-bit platforms."|publisher = IBM Corporation|date = September 6, 2007|access-date = April 9, 2010|archive-date = January 25, 2022|archive-url = https://web.archive.org/web/20220125121650/ftp://ftp.software.ibm.com/software/webserver/appserv/was/64bitPerf.pdf|url-status = live}}</ref> while newer or modified applications can take advantage of new features of the processor design to achieve performance improvements. Also, a processor supporting x86-64 still powers on in [[real mode]] for full [[backward compatibility]] with the [[Intel 8086|8086]], as x86 processors supporting [[protected mode]] have done since the [[Intel 80286|80286]].

The x86-64 architecture was quickly adopted for desktop and laptop personal computers and servers which were commonly configured for 16GB16&nbsp;GiB ([[gibibyte]]s) of memory or more. It has effectively replaced the discontinued Intel [[Itanium]] architecture (formerly [[IA-64]]), which was originally intended to replace the x86 architecture. x86-64 and Itanium are not compatible on the native instruction set level, and operating systems and applications compiled for one architecture cannot be run on the other natively.

}}</ref> As AMD was never invited to be a contributing party for the IA-64 architecture and any kind of licensing seemed unlikely, the AMD64 architecture was positioned by AMD from the beginning as an evolutionary way to add [[64-bit computing]] capabilities to the existing x86 architecture while supporting legacy 32-bit x86 [[computermachine code|code]], as opposed to Intel's approach of creating an entirely new, completely x86-incompatible 64-bit architecture with IA-64.

The primary defining characteristic of AMD64 is the availability of 64-bit general-purpose [[processor register]]s (for example, {{mono|rax}}), 64-bit [[Integer (computer science)|integer]] arithmetic and logical operations, and 64-bit [[Protected Virtual Address Mode|virtual addresses]].<ref><nowiki>{{cite book |url=https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24592.pdf</nowiki> [page|title=AMD64 1Architecture sectionProgrammer's Manual |page=1.1.1]}}</ref> The designers took the opportunity to make other improvements as well.

: AMD64 still has fewer registers than many [[RISC]] [[instruction set]]s (e.g. [[PA-RISC]], [[Power ISA]], andhas 32 GPRs; [[MIPSARM architecture#64/32-bit architecture|MIPS64-bit ARM]], have[[RISC-V]] 32I, GPRs;[[SPARC]], [[DEC Alpha|Alpha]], [[ARM architecture#64/32-bitMIPS architecture|64-bit ARMMIPS]], and [[SPARCPA-RISC]] have 31) or [[VLIW]]-like machines such as the [[IA-64]] (which has 128&nbsp;registers). However, an AMD64 implementation may have far more internal registers than the number of architectural registers exposed by the instruction set (see [[register renaming]]). (For example, AMD Zen cores have 168 64-bit integer and 160 128-bit vector floating-point physical internal registers.)

: The AMD64 architecture defines a 64-bit virtual address format, of which the low-order 48 bits are used in current implementations.<ref name="amd-24593"/>{{rp|page=120|date=November 2012}} This allows up to 256&nbsp;[[TerabyteTebibyte|TBTiB]] (2⁴⁸ [[byte]]s) of virtual address space. The architecture definition allows this limit to be raised in future implementations to the full 64 bits,<ref name="amd-24593"/>{{rp|page=2|date=November 2012}}{{rp|page=3|date=November 2012}}{{rp|page=13|date=November 2012}}{{rp|page=117|date=November 2012}}{{rp|page=120|date=November 2012}} extending the virtual address space to 16&nbsp;[[ExabyteExbibyte|EBEiB]] (2⁶⁴ bytes).<ref>Mauerer, W. (2010). Professional Linux kernel architecture. John Wiley & Sons.</ref> This is compared to just 4&nbsp;[[GigabyteGibibyte|GBGiB]] (2³² bytes) for the x86.<ref name="intel-253668">{{cite web

: This means that very large files can be operated on by [[Memory-mapped file|mapping]] the entire file into the process's address space (which is often much faster than working with file read/write calls), rather than having to map regions of the file into and out of the address space.

: The original implementation of the AMD64 architecture implemented 40-bit [[physical address]]es and so could address up to 1&nbsp;TBTiB (2⁴⁰ bytes) of RAM.<ref name="amd-24593" />{{rp|page=24|date=November 2012}} Current implementations of the AMD64 architecture (starting from [[AMD K10|AMD 10h microarchitecture]]) <!--- it's "10h", as in 10 hex, not 10th as in tenth. Please see the reference named amd10h, immediately following. Please do not change this back to "10th" ---> extend this to 48-bit physical addresses<ref name="amd10h">{{cite web |url=http://developer.amd.com/wordpress/media/2012/10/31116.pdf |title=BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors |access-date=February 27, 2016 |page=24 |quote=Physical address space increased to 48 bits. |archive-date=April 18, 2016 |archive-url=https://web.archive.org/web/20160418185513/http://developer.amd.com/wordpress/media/2012/10/31116.pdf |url-status=live }}</ref> and therefore can address up to 256&nbsp;TBTiB (2⁴⁸ bytes) of RAM. The architecture permits extending this to 52 bits in the future<ref name="amd-24593" />{{rp|page=24|date=November 2012}}<ref>

}}</ref> (limited by the page table entry format);<ref name="amd-24593" />{{rp|page=131|date=November 2012}} this would allow addressing of up to 4&nbsp;PBPiB of RAM. For comparison, 32-bit x86 processors are limited to 64&nbsp;GBGiB of RAM in [[Physical Address Extension]] (PAE) mode,<ref name="shanley-ppro">{{cite book |title = Pentium Pro and Pentium II System Architecture

}}</ref> or 4&nbsp;GBGiB of RAM without PAE mode.<ref name="amd-24593" />{{rp|page=4|date=November 2012}}

: [[x86 memory segmentation|Segmented addressing]] has long been considered an obsolete mode of operation, and all current PC operating systems in effect bypass it, setting all segments to a base address of zero and (in their 32-bit implementation) a size of 4 GB&nbsp;GiB. AMD was the first x86-family vendor to implement no-execute in linear addressing mode. The feature is also available in legacy mode on AMD64 processors, and recent Intel x86 processors, when PAE is used.

Although virtual addresses are 64&nbsp;bits wide in 64-bit mode, current implementations (and all chips that are known to be in the planning stages) do not allow the entire virtual address space of 2⁶⁴ bytes (16&nbsp;[[ExabyteExbibyte|EBEiB]]) to be used. This would be approximately four billion times the size of the virtual address space on 32-bit machines. Most operating systems and applications will not need such a large address space for the foreseeable future, so implementing such wide virtual addresses would simply increase the complexity and cost of address translation with no real benefit. AMD, therefore, decided that, in the first implementations of the architecture, only the least significant 48&nbsp;bits of a virtual address would actually be used in address translation ([[page table]] lookup).<ref name="amd-24593"/>{{rp|page=120|date=November 2012}}

In addition, the AMD specification requires that the most significant 16 bits of any virtual address, bits 48 through 63, must be copies of bit 47 (in a manner akin to [[sign extension]]). If this requirement is not met, the processor will raise an exception.<ref name="amd-24593"/>{{rp|page=131|date=November 2012}} Addresses complying with this rule are referred to as "canonical form."<ref name="amd-24593"/>{{rp|page=130|date=November 2012}} Canonical form addresses run from 0 through 00007FFF'FFFFFFFF, and from FFFF8000'00000000 through FFFFFFFF'FFFFFFFF, for a total of 256&nbsp;[[TerabyteTebibyte|TBTiB]] of usable virtual address space. This is still 65,536 times larger than the virtual 4 GB&nbsp;GiB address space of 32-bit machines.

The first versions of Windows for x64 did not even use the full 256&nbsp;TBTiB; they were restricted to just 8&nbsp;TBTiB of user space and 8&nbsp;TBTiB of kernel space.<ref name="win-lim-msdn">{{cite web |url=http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits |title=Memory Limits for Windows Releases |website=[[MSDN]] |publisher=[[Microsoft]] |date=November 16, 2013 |access-date=January 20, 2014 |archive-date=January 6, 2014 |archive-url=https://web.archive.org/web/20140106195757/http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits |url-status=live }}</ref> Windows did not support the entire 48-bit address space until [[Windows&nbsp;8.1]], which was released in October 2013.<ref name="win-lim-msdn"/> <!--- it would be good to include other OS's limits here. --->

The 64-bit addressing mode ("[[long mode]]") is a superset of [[Physical Address Extension]]s (PAE); because of this, [[paging|page]] sizes may be 4&nbsp;[[KilobyteKibibyte|KBKiB]] (2¹² bytes) or 2&nbsp;[[MegabyteMebibyte|MBMiB]] (2²¹ bytes).<ref name="amd-24593"/>{{rp|page=120|date=November 2012}} Long mode also supports page sizes of 1&nbsp;[[GigabyteGibibyte|GBGiB]] (2³⁰ bytes).<ref name="amd-24593"/>{{rp|page=120|date=November 2012}} Rather than the three-level [[page table]] system used by systems in PAE mode, systems running in [[long mode]] use four levels of page table: PAE's ''Page-Directory Pointer Table'' is extended from four entries to 512, and an additional ''Page-Map Level&nbsp;4 (PML4) Table'' is added, containing 512 entries in 48-bit implementations.<ref name="amd-24593"/>{{rp|page=131|date=November 2012}} A full mapping hierarchy of 4&nbsp;KBKiB pages for the whole 48-bit space would take a bit more than 512&nbsp;[[GigabyteGibibyte|GBGiB]] of memory (about 0.195% of the 256&nbsp;TBTiB virtual space).

Intel has implemented a scheme with a [[Intel 5-level paging|5-level page table]], which allows Intel 64 processors to support a 57-bit virtual address space.<ref>{{cite web|url=https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf|title=5-Level Paging and 5-Level EPT|publisher=Intel|date=May 2017|access-date=June 17, 2017|archive-date=December 5, 2018|archive-url=https://web.archive.org/web/20181205041235/https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf|url-status=live}}</ref> Further extensions may allow full 64-bit virtual address space and physical memory bywith expanding the12-bit page table entrydescriptors sizeand to16- 128or 21-bit, memory offsets for 64&nbsp;KiB and reduce2&nbsp;MiB page walksallocation insizes; the 5-levelpage hierarchytable byentry usingwould abe largerexpanded 64&nbsp;KBto page128 allocationbits sizeto thatsupport stilladditional supportshardware 4&nbsp;KBflags for page operationssize forand backwardvirtual compatibilityaddress space size.<ref>{{cite patent | country = US | number = 9858198 | status = patent | title = 64KB page system that supports 4KB page operation | pridate = 2015-06-26 | fdate = 2015-06-26 | pubdate = 2016-12-29 | gdate = 2018-01-02 | invent1 = Larry Seiler | assign1 = Intel Corp.}}</ref>

Current AMD64 processors support a physical address space of up to 2⁴⁸ bytes of RAM, or 256&nbsp;[[TerabyteTebibyte|TBTiB]].<ref name="amd10h"/> However, {{as of|2020|lc=1}}, there were no known x86-64 [[motherboard]]s that support 256&nbsp;TBTiB of RAM.<ref>{{cite web

Legacy mode is the mode that the processor is in when it is not in long mode.<ref name="amd-24593" />{{rp|page=14|date=March 2021}} In this mode, the processor acts like an older x86 processor, and only 16-bit and 32-bit code can be executed. Legacy mode allows for a maximum of 32&nbsp;bit virtual addressing which limits the virtual address space to 4&nbsp;GBGiB.<ref name="amd-24593"/>{{rp|page=14|date=November 2012}}{{rp|page=24|date=November 2012}}{{rp|page=118|date=November 2012}} 64-bit programs cannot be run from legacy mode.

Intel's name for this instruction set has changed several times. The name used at the IDF was ''CT''<ref>{{cite web |last1=Lapedus |first1=Mark |title=Intel to demo 'CT' 64-bit processor line at IDF |url=https://www.edn.com/intel-to-demo-ct-64-bit-processor-line-at-idf/ |website=EDN |date=February 6, 2004 |publisher=AspenCore Media |access-date=25 May 2021 |archive-date=May 25, 2021 |archive-url=https://web.archive.org/web/20210525031727/https://www.edn.com/intel-to-demo-ct-64-bit-processor-line-at-idf/ |url-status=live }}</ref> (presumably{{Original research inline|date=August 2017}} for ''Clackamas Technology'', another codename from an [[Clackamas River|Oregon river]]); within weeks they began referring to it as ''IA-32e'' (for [[IA-32]] extensions) and in March 2004 unveiled the "official" name ''EM64T'' (Extended Memory 64 Technology). In late 2006 Intel began instead using the name ''Intel&nbsp;64'' for its implementation, paralleling AMD's use of the name AMD64.<ref>{{cite web

In 2020, through a collaboration between AMD, Intel, [[Red Hat]], and [[SUSE S.A.|SUSE]], three microarchitecture levels (or feature levels) on top of the x86-64 baseline were defined: x86-64-v2, x86-64-v3, and x86-64-v4.<ref>{{cite mailing list |first=Florian |last=Weimer |title=New x86-64 micro-architecture levels |url=https://lists.llvm.org/pipermail/llvm-dev/2020-July/143289.html |mailing-list=llvm-dev|date=10 July 2020 |access-date=March 11, 2021 |archive-date=April 14, 2021 |archive-url=https://web.archive.org/web/20210414100705/https://lists.llvm.org/pipermail/llvm-dev/2020-July/143289.html |url-status=live }}</ref><ref>{{cite web |first=Florian |last=Weimer |title=Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level |url=https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level |work=Red Hat developer blog |date=5 January 2021 |access-date=March 22, 2022 |archive-date=February 20, 2022 |archive-url=https://web.archive.org/web/20220220155150/https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level |url-status=live }}</ref> These levels define specific features that can be targeted by programmers to provide compile-time optimizations. The features exposed by each level are as follows:<ref>{{Cite web |title=System V Application Binary Interface Low Level System Information |url=https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex |website=x86-64 psABI repo |date=29 January 2021 |via=[[GitLab]] |access-date=March 11, 2021 |archive-date=February 2, 2021 |archive-url=https://web.archive.org/web/20210202215134/https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex |url-status=live }}</ref>

!Level&nbsp;name

| rowspan=9 | x86-64(baseline)<br>also as:<br>{{nowrap|(''x86-64-v1)''}}

baseline for all x86-64 CPUs<br>

| rowspan=7 | ''x86-64-v2''

Intel [[Nehalem (microarchitecture)|''Nehalem'']] and newer Intel "big" cores<br>

AMD [[Bulldozer (microarchitecture)|''Bulldozer'']] and newer AMD "big" cores<br>

AMD [[Jaguar (microarchitecture)|''Jaguar'']]<br>

[[VIA Technologies|VIA]] ''Nano'' and ''Eden "C"''<br>

<br>featurefeatures level matchesmatch the 2008 Intel Nehalem architecture, (excluding Intel-specific instructions)

| SSSE3 || phadddpshufb

| rowspan=9 | ''x86-64-v3''

Intel [[Haswell (microarchitecture)|''Haswell'']] and newer Intel "big" cores (AVX2 enabled models only)<br>

AMD [[Excavator (microarchitecture)|''Excavator'']] and newer AMD "big" cores<br>

<br>featurefeatures level matchesmatch the 2013 Intel Haswell architecture, (excluding Intel-specific instructions)

| rowspan=5 | ''x86-64-v4''

Intel [[Skylake (microarchitecture)|''Skylake'']] and newer Intel "big" cores (AVX512 enabled models only)<br>

AMD [[Zen_4|''Zen 4'']] and newer AMD cores<br>

<br>featurefeatures level matchesmatch the 2017 Intel Skylake-X architecture, (excluding Intel-specific instructions)

* The AMD64 processors prior to Revision F<ref>{{cite web |title=Live Migration with AMD-V™ Extended Migration Technology |url=http://developer.amd.com/wordpress/media/2012/10/43781-3.00-PUB_Live-Virtual-Machine-Migration-on-AMD-processors.pdf |website=developer.amd.com |access-date=June 30, 2022 |archive-date=December 6, 2022 |archive-url=https://web.archive.org/web/20221206025751/http://developer.amd.com/wordpress/media/2012/10/43781-3.00-PUB_Live-Virtual-Machine-Migration-on-AMD-processors.pdf |url-status=live }}</ref> (distinguished by the switch from [[DDR SDRAM|DDR]] to [[DDR2 SDRAM|DDR2]] memory and new sockets [[Socket AM2|AM2]], [[Socket F|F]] and [[Socket S1|S1]]) of 2006 lacked the <code>CMPXCHG16B</code> instruction, which is an extension of the <code>CMPXCHG8B</code> instruction present on most post-[[80486]] processors. Similar to <code>CMPXCHG8B</code>, <code>CMPXCHG16B</code> allows for [[atomic operation]]s on octa-words (128-bit values). This is useful for parallel algorithms that use [[compare and swap]] on data larger than the size of a pointer, common in [[lock-free and wait-free algorithms]]. Without <code>CMPXCHG16B</code> one must use workarounds, such as a [[critical section]] or alternative lock-free approaches.<ref>{{cite web|url=http://www.research.ibm.com/people/m/michael/disc-2004.pdf|title=Practical Lock-Free and Wait-Free LL/SC/VL Implementations Using 64-Bit CAS|author=Maged M. Michael|publisher=IBM|access-date=January 21, 2014|archive-date=May 2, 2013|archive-url=https://web.archive.org/web/20130502033436/http://www.research.ibm.com/people/m/michael/disc-2004.pdf|url-status=live}}</ref> Its absence also prevents 64-bit [[Microsoft Windows|Windows]] prior to Windows 8.1 from having a [[user-mode]] address space larger than 8&nbsp;[[terabytetebibyte|TBTiB]].<ref>{{cite web|url=https://blogs.msdn.microsoft.com/oldnewthing/20040817-00/?p=38153#comment-204583|title=Why is the virtual address space 4GB anyway?|website=The Old New Thing|author=darwou|date=August 20, 2004|publisher=Microsoft|access-date=March 25, 2017|archive-date=March 26, 2017|archive-url=https://web.archive.org/web/20170326140218/https://blogs.msdn.microsoft.com/oldnewthing/20040817-00/?p=38153#comment-204583|url-status=live}}</ref> The 64-bit version of [[Windows 8.1]] requires the instruction.<ref name="CPUinsts8.1">{{cite web

* Early Intel&nbsp;64 implementations had a 36-bit (64&nbsp;GBGiB) physical addressing of memory while original AMD64 implementations had a 40-bit (1&nbsp;[[TerabyteTebibyte|TBTiB]]) physical addressing. Intel used the 40-bit physical addressing first on Xeon MP ([[Xeon#Cranford and Potomac|Potomac]]), launched on 29 March 2005.<ref>{{cite web |url=https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/64-bit-xeon-mp-8mb-l3-cache-datasheet.pdf |title=64-bit Intel® Xeon™ Processor MP with up to 8MB L3 Cache Datasheet |access-date=November 17, 2022 |archive-date=November 17, 2022 |archive-url=https://web.archive.org/web/20221117025116/https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/64-bit-xeon-mp-8mb-l3-cache-datasheet.pdf |url-status=live }}</ref> The difference is not a difference of the user-visible ISAs. In 2007 [[AMD 10h]]-based Opteron was the first to provide a 48-bit (256&nbsp;TBTiB) physical address space.<ref>{{cite web |title=Justin Boggs's at Microsoft PDC 2008 |url=https://zbook.org/read/70903_justin-boggs-isv-engineering-developer-relations-manager.html |page=5 |access-date=November 17, 2022 |archive-date=November 17, 2022 |archive-url=https://web.archive.org/web/20221117025143/https://zbook.org/read/70903_justin-boggs-isv-engineering-developer-relations-manager.html |url-status=live }}</ref><ref>{{cite web |last1=Waldecker |first1=Brian |title=AMD Opteron Multicore Processors |url=https://www.nersc.gov/assets/Uploads/AMDMultiCoreCrayNersc020110.pdf |page=13 |access-date=November 17, 2022 |archive-date=December 13, 2022 |archive-url=https://web.archive.org/web/20221213095258/https://www.nersc.gov/assets/Uploads/AMDMultiCoreCrayNersc020110.pdf |url-status=live }}</ref> Intel 64's physical addressing was extended to 44 bits (16&nbsp;TBTiB) in Nehalem-EX in 2010<ref>{{cite web |url=https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-processor-7500-series-vol-2-datasheet.pdf |title=Intel® Xeon® Processor 7500 Series Datasheet, Volume 2 |access-date=November 17, 2022 |archive-date=November 17, 2022 |archive-url=https://web.archive.org/web/20221117025118/https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-processor-7500-series-vol-2-datasheet.pdf |url-status=live }}</ref> and to 46 bits (64&nbsp;TBTiB) in Sandy Bridge E in 2011.<ref>{{cite web |quote=Intel 64 architecture increases the linear address space for software to 64 bits and supports physical address space up to 46 bits. |volume=1 |page=2{{hyp}}21 |url=http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html |title=Intel 64 and IA-32 Architectures Software Developer's Manual |date=September 2014 |archive-url=https://web.archive.org/web/20190514124207/https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html |archive-date=May 14, 2019 |url-status=dead}}</ref><ref>{{cite web |last1=Logan |first1=Tom |title=Intel Core i7-3960X Review |url=https://overclock3d.net/reviews/cpu_mainboard/intel_core_i7-3960x_review/2 |access-date=1 July 2022 |date=14 November 2011 |archive-date=March 28, 2016 |archive-url=https://web.archive.org/web/20160328235235/http://overclock3d.net/reviews/cpu_mainboard/intel_core_i7-3960x_review/2 |url-status=live }}</ref> With the Ice Lake 3rd gen Xeon Scalable processors, Intel increased the virtual addressing to 57 bits (128&nbsp;[[PetabytePebibyte|PBPiB]]) and physical to 52 bits (4&nbsp;PBPiB) in 2021, necessitating a [[Intel 5-level paging|5-level paging]].<ref>{{cite web |last1=Ye |first1=Huaisheng |title=Introduction to 5-Level Paging in 3rd Gen Intel Xeon Scalable Processors with Linux |url=https://lenovopress.lenovo.com/lp1468.pdf |publisher=Lenovo |access-date=1 July 2022 |archive-date=May 26, 2022 |archive-url=https://web.archive.org/web/20220526220222/https://lenovopress.lenovo.com/lp1468.pdf |url-status=live }}</ref> The following year AMD64 added the same in 4th generation [[EPYC]] (Genoa).<ref>{{cite web |last1=Kennedy |first1=Patrick |title=AMD EPYC Genoa Gaps Intel Xeon in Stunning Fashion |url=https://www.servethehome.com/amd-epyc-genoa-gaps-intel-xeon-in-stunning-fashion/2/ |website=ServeTheHome |page=2 |date=November 10, 2022 |access-date=November 17, 2022 |archive-date=November 17, 2022 |archive-url=https://web.archive.org/web/20221117025115/https://www.servethehome.com/amd-epyc-genoa-gaps-intel-xeon-in-stunning-fashion/2/ |url-status=live }}</ref> Non-server CPUs retain smaller address spaces for longer.

{{As of|20202023}}, a [[FujitsuHewlett Packard Enterprise|HPE]] [[Fujitsu A64FXEpyc|A64FXEPYC]]-based supercomputer called [[FugakuFrontier (supercomputer)|FugakuFrontier]] is number one. The first ARM-based supercomputer appeared on the list in 2018<ref>{{Cite web|url=https://www.top500.org/statistics/sublist/|title=Sublist Generator {{!}} TOP500 Supercomputer Sites|website=www.top500.org|access-date=2018-12-06|archive-date=December 7, 2018|archive-url=https://web.archive.org/web/20181207200508/https://www.top500.org/statistics/sublist/|url-status=live}}</ref> and, in recent years, non-CPU architecture co-processors ([[General-purpose computing on graphics processing units|GPGPU]]) have also played a big role in performance. Intel's [[Xeon Phi#Knights Corner|Xeon Phi "Knights Corner"]] coprocessors, which implement a subset of x86-64 with some vector extensions,<ref>{{cite web|url=https://software.intel.com/sites/default/files/forum/278102/327364001en.pdf|title=Intel® Xeon PhiTM Coprocessor Instruction Set Architecture Reference Manual|at=section B.2 Intel Xeon Phi coprocessor 64 bit Mode Limitations|publisher=Intel|date=September 7, 2012|access-date=May 21, 2014|archive-date=May 21, 2014|archive-url=https://web.archive.org/web/20140521050107/https://software.intel.com/sites/default/files/forum/278102/327364001en.pdf|url-status=live}}</ref> are also used, along with x86-64 processors, in the [[Tianhe-2]] supercomputer.<ref>{{cite web|url=http://newsroom.intel.com/community/intel_newsroom/blog/2013/06/17/intel-powers-the-worlds-fastest-supercomputer-reveals-new-and-future-high-performance-computing-technologies|title=Intel Powers the World's Fastest Supercomputer, Reveals New and Future High Performance Computing Technologies|access-date=June 21, 2013|archive-date=June 22, 2013|archive-url=https://web.archive.org/web/20130622162239/http://newsroom.intel.com/community/intel_newsroom/blog/2013/06/17/intel-powers-the-worlds-fastest-supercomputer-reveals-new-and-future-high-performance-computing-technologies|url-status=live}}</ref>

Though this limits the program to a virtual address space of 4&nbsp;GBGiB it also decreases the memory footprint of the program and in some cases can allow it to run faster.<ref name="x32ABIHOnline"/><ref name="x32ABILinuxPlumbers"/><ref name="x32ABIDevelopmentGroup"/>

64-bit Linux allows up to 128&nbsp;[[TerabyteTebibyte|TBTiB]] of virtual address space for individual processes, and can address approximately 64&nbsp;TBTiB of physical memory, subject to processor and system limitations,<ref name="DebianAMD64">{{cite news

}}</ref> or up to 128PB128&nbsp;PiB (virtual) and 4PB4&nbsp;PiB (physical) with 5-level paging enabled.<ref name="Kernel5LevelPaging">

The 64-bit kernel, like the 32-bit kernel, supports 32-bit applications; both kernels also support 64-bit applications. 32-bit applications have a virtual address space limit of 4&nbsp;GBGiB under either kernel.<ref name="arstechnicaMacOSX64bit">{{cite web

* 8&nbsp;TBTiB of virtual address space per process, accessible from both user mode and kernel mode, referred to as the user mode address space. An x64 program can use all of this, subject to backing store limits on the system, and provided it is linked with the "large address aware" option, which is present by default.<ref name="VSdocLAA">{{cite web

}}</ref> This is a 4096-fold increase over the default 2&nbsp;GBGiB user-mode virtual address space offered by 32-bit Windows.<ref name="Pietrek64BitWindowsProgramming">{{cite web

* 8&nbsp;TBTiB of kernel mode virtual address space for the operating system.<ref name="Pietrek64BitWindowsProgramming"/> As with the user mode address space, this is a 4096-fold increase over 32-bit Windows versions. The increased space primarily benefits the file system cache and kernel mode "heaps" (non-paged pool and paged pool). Windows only uses a total of 16&nbsp;TBTiB out of the 256&nbsp;TBTiB implemented by the processors because early AMD64 processors lacked a <code>CMPXCHG16B</code> instruction.<ref>{{cite web

Under Windows 8.1 and Windows Server 2012 R2, both user mode and kernel mode virtual address spaces have been extended to 128&nbsp;TBTiB.<ref name="win-lim-msdn"/> These versions of Windows will not install on processors that lack the <code>CMPXCHG16B</code> instruction.

* Ability to run existing 32-bit applications (<code>.exe</code> programs) and dynamic link libraries (<code>.dll</code>s) using [[WoW64]] if WoW64 is supported on that version. Furthermore, a 32-bit program, if it was linked with the "large address aware" option,<ref name="VSdocLAA"/> can use up to 4&nbsp;GBGiB of virtual address space in 64-bit Windows, instead of the default 2&nbsp;GBGiB (optional 3&nbsp;GBGiB with <code>/3GB</code> boot option and "large address aware" link option) offered by 32-bit Windows.<ref name="64-bitProgrammingGameDevelopers">{{cite web

* Both 32- and 64-bit applications, if not linked with "large address aware", are limited to 2&nbsp;GBGiB of virtual address space.

* Ability to use up to 128&nbsp;GBGiB (Windows XP/Vista), 192&nbsp;GBGiB (Windows&nbsp;7), 512&nbsp;GBGiB (Windows&nbsp;8), 1&nbsp;TBTiB (Windows Server 2003), 2&nbsp;TBTiB (Windows Server 2008/Windows 10), 4&nbsp;TBTiB (Windows Server 2012), or 24&nbsp;TBTiB (Windows Server 2016/2019) of physical random access memory (RAM).<ref>{{cite web

Both the [[PlayStation 4]] and [[Xbox One]], and all variants of those consoles, incorporate AMD x86-64 processors, based on the [[Jaguar (microarchitecture)|Jaguar]] [[microarchitecture]].<ref name=XboxOneMay2013Anandtechcomparison>{{cite news |title= The Xbox&nbsp;One: Hardware Analysis & Comparison to PlayStation&nbsp;4 |author= Anand Lal Shimpi |publisher= Anandtech |url= http://www.anandtech.com/show/6972/xbox-one-hardware-compared-to-playstation-4/2 |date= May 21, 2013 |access-date= May 22, 2013 |archive-date= June 7, 2013 |archive-url= https://web.archive.org/web/20130607031844/http://www.anandtech.com/show/6972/xbox-one-hardware-compared-to-playstation-4/2 |url-status= live }}</ref><ref name=XboxOneMay2013SpecGameinformer>{{cite web |url= http://www.gameinformer.com/b/news/archive/2013/05/21/the-tech-spec-test-xbox-one-vs-playstation-4.aspx |title= The Tech Spec Test: Xbox&nbsp;One Vs. PlayStation&nbsp;4 |publisher= Game Informer |date= May 21, 2013 |access-date= May 22, 2013 |archive-date= June 7, 2013 |archive-url= https://web.archive.org/web/20130607180640/http://www.gameinformer.com/b/news/archive/2013/05/21/the-tech-spec-test-xbox-one-vs-playstation-4.aspx |url-status= livedead }}</ref> Firmware and games are written in x86-64 code; no legacy x86 code is involved.

x86-64/AMD64 was solely developed by AMD. Until April 2021 when the relevant patents expired, AMD holdsheld patents on techniques used in AMD64;<ref>{{patent|US|6877084}}</ref><ref>{{patent|US|6889312}}</ref><ref>{{patent|US|6732258}}</ref> those patents musthad to be licensed from AMD in order to implement AMD64. Intel entered into a cross-licensing agreement with AMD, licensing to AMD their patents on existing x86 techniques, and licensing from AMD their patents on techniques used in x86-64.<ref>{{cite web