x86-64

x86-64 (auch bekannt als x86_64 , AMD64 , Intel 64 und x64 ) ^{[ Anmerkung 1 ]} ist eine 64-Bit -Erweiterung des x86- Befehlssatzes. Er wurde 1999 angekündigt und war erstmals 2003 in der AMD Opteron- Familie verfügbar. Er führt zwei neue Betriebsmodi ein: den 64-Bit-Modus und den Kompatibilitätsmodus, sowie einen neuen vierstufigen Paging- Mechanismus.

Im 64-Bit-Modus unterstützt x86-64 deutlich größere Mengen an virtuellem und physischem Speicher als seine 32-Bit- Vorgänger, wodurch Programme mehr Speicher nutzen können. Die Architektur erweitert die Anzahl der Allzweckregister von 8 auf 16, die alle vollwertige Register sind, und vergrößert deren Breite auf 64 Bit.

Gleitkommaarithmetik wird im 64-Bit-Modus durch obligatorische SSE2- Befehle unterstützt . Die älteren x87 -FPU- und MMX-Register sind zwar weiterhin verfügbar, werden aber im Allgemeinen durch sechzehn 128-Bit -Vektorregister (XMM-Register) ersetzt. Jedes dieser Vektorregister kann eine oder zwei Gleitkommazahlen doppelter Genauigkeit , bis zu vier Gleitkommazahlen einfacher Genauigkeit oder verschiedene Integer-Formate speichern.

Im 64-Bit-Modus werden die Befehle so modifiziert, dass sie 64-Bit- Operanden und den 64-Bit -Adressierungsmodus unterstützen .

Die x86-64-Architektur definiert einen Kompatibilitätsmodus, der es ermöglicht, 16-Bit- und 32-Bit- Benutzeranwendungen unverändert neben 64-Bit-Anwendungen auszuführen, sofern das 64-Bit-Betriebssystem dies unterstützt. ^{[ 11 ] [ Anmerkung 2 ]} Da die vollständigen x86-32-Befehlssätze weiterhin in Hardware implementiert sind und keine Emulation erforderlich ist, können diese älteren ausführbaren Dateien mit geringen oder gar keinen Leistungseinbußen ausgeführt werden. ^{[ 13 ]} Neuere oder modifizierte Anwendungen können hingegen die neuen Funktionen des Prozessordesigns nutzen, um Leistungsverbesserungen zu erzielen. Prozessoren, die x86-64 unterstützen, starten weiterhin im Realmodus , um die Abwärtskompatibilität mit dem ursprünglichen 8086-Prozessor zu gewährleisten , wie es bei x86-Prozessoren seit der Einführung des geschützten Modus mit dem 80286 der Fall ist .

Die ursprüngliche Spezifikation, die von AMD im Jahr 2000 entwickelt und veröffentlicht wurde, wurde von AMD, Intel und VIA implementiert . Die AMD K8- Mikroarchitektur , die in den Opteron- und Athlon-64 -Prozessoren zum Einsatz kam, implementierte sie als erste. Dies war die erste bedeutende Erweiterung der x86 -Architektur durch ein anderes Unternehmen als Intel. Intel sah sich gezwungen, nachzuziehen und führte eine modifizierte NetBurst- Familie ein, die softwarekompatibel mit AMDs Spezifikation war. VIA Technologies führte x86-64 mit ihrer VIA-Isaiah-Architektur und dem VIA Nano ein .

Die x86-64-Architektur wurde schnell für Desktop- und Laptop-PCs sowie Server übernommen, die üblicherweise mit 16  GB Arbeitsspeicher oder mehr ausgestattet waren. Sie hat die eingestellte Intel Itanium -Architektur (ehemals IA-64 ) effektiv abgelöst, die ursprünglich die x86-Architektur ersetzen sollte. x86-64 und Itanium sind auf Ebene des nativen Befehlssatzes nicht kompatibel, und Betriebssysteme und Anwendungen, die für die eine Architektur kompiliert wurden, können nicht nativ auf der anderen ausgeführt werden.

Im Oktober 2024 wurde die x86 Ecosystem Advisory Group gemeinsam von Intel und AMD gegründet. Zu den Zielen gehörten die Verbesserung der Softwarekonsistenz und die Standardisierung von x86-Schnittstellen und -Funktionen. ^{[ 14 ]}

AMD64 (von AMD in ihren Publikationen und Dokumentationen auch als „AMD 64-Bit-Technologie“ und „AMD x86-64-Architektur“ bezeichnet) wurde als Alternative zur radikal anderen IA-64- Architektur von Intel und Hewlett-Packard entwickelt, die nicht abwärtskompatibel mit IA-32 , der 32-Bit-Erweiterung der x86- Architektur, war . AMD kündigte AMD64 ursprünglich 1999 an ^{[ 15 ]} , die vollständigen Spezifikationen waren im August 2000 verfügbar ^{[ 16 ]} . Da AMD nie zur Mitarbeit an der IA-64-Architektur eingeladen wurde und eine Lizenzierung unwahrscheinlich erschien, positionierte AMD die AMD64-Architektur von Anfang an als evolutionären Weg, die bestehende x86-Architektur um 64-Bit- Rechenleistung zu erweitern und gleichzeitig älteren 32-Bit-x86 -Code zu unterstützen . Dies stand im Gegensatz zu Intels Ansatz, mit IA-64 eine völlig neue, vollständig x86-inkompatible 64-Bit-Architektur zu entwickeln.

Der erste auf AMD64 basierende Prozessor, der Opteron , wurde im April 2003 veröffentlicht.

Zu den AMD-Prozessoren, die die AMD64-Architektur implementieren, gehören Opteron , Athlon 64 , Athlon 64 X2 , Athlon 64 FX , Athlon II (gefolgt von „X2“, „X3“ oder „X4“, um die Anzahl der Kerne anzugeben, sowie XLT-Modelle), Turion 64 , Turion 64 X2 , Sempron (Palermo E6-Stepping und alle „Manila“-Modelle), Phenom (gefolgt von „X3“ oder „X4“, um die Anzahl der Kerne anzugeben), Phenom II (gefolgt von „X2“, „X3“, „X4“ oder „X6“, um die Anzahl der Kerne anzugeben), FX , Fusion/APU und Ryzen / Epyc .

Das Hauptmerkmal von AMD64 ist die Verfügbarkeit von 64-Bit-Allzweck- Prozessorregistern (z. B. rax ), 64-Bit- Ganzzahlarithmetik und logischen Operationen sowie 64-Bit -virtuellen Adressen . ^{[ 17 ]} Die Entwickler nutzten die Gelegenheit, um auch weitere Verbesserungen vorzunehmen.

Zu den bemerkenswerten Änderungen in den 64-Bit-Erweiterungen gehören:

64-Bit-Ganzzahlfähigkeit

Alle Allzweckregister (GPRs) wurden von 32 Bit auf 64 Bit erweitert  , und alle arithmetischen und logischen Operationen, Speicher-zu-Register- und Register-zu-Speicher-Operationen usw. können direkt mit 64-Bit-Ganzzahlen durchgeführt werden. Das Hinzufügen und Entfernen von Elementen vom Stack erfolgt standardmäßig in 8-Byte-Schritten, und Zeiger sind 8 Byte breit.

Zusätzliche Register

Neben der Vergrößerung der Allzweckregister wurde auch die Anzahl der benannten Allzweckregister von acht (d. h. eax , ebx , ecx , edx , esi , edi , esp , ebp ) in x86 auf 16 (d. h. rax , rbx , rcx , rdx , rsi , rdi , rsp , rbp , r8 , r9 , r10 , r11 , r12 , r13 , r14 , r15 ) erhöht. Dadurch können mehr lokale Variablen in Registern anstatt auf dem Stack gespeichert und häufig verwendete Konstanten in Registern abgelegt werden. Auch Argumente für kleine und schnelle Unterprogramme lassen sich nun vermehrt in Registern übergeben.

AMD64 verfügt zwar immer noch über weniger Register als viele RISC- Befehlssätze (z. B. Power ISA mit 32 GPRs; 64-Bit-ARM , RISC-V I, SPARC , Alpha , MIPS und PA-RISC mit 31) oder VLIW -ähnliche Maschinen wie der IA-64 (mit 128 Registern). Eine AMD64-Implementierung kann jedoch deutlich mehr interne Register besitzen als die Anzahl der durch den Befehlssatz bereitgestellten Architekturregister (siehe Registerumbenennung ). (Beispielsweise verfügen AMD Zen-Kerne über 168 64-Bit-Integer- und 160 128-Bit-Vektor-Gleitkomma-Register.)

Zusätzliche XMM (SSE)-Register

In ähnlicher Weise wurde auch die Anzahl der 128-Bit-XMM-Register (die für Streaming-SIMD- Befehle verwendet werden) von 8 auf 16 erhöht.

Der traditionelle x87-FPU-Registerstapel wird im 64-Bit-Modus nicht in die Registerdateierweiterung einbezogen, im Gegensatz zu den von SSE2 verwendeten XMM-Registern, deren Größe erweitert wurde. Der x87- Registerstapel ist keine einfache Registerdatei, obwohl er durch kostengünstige Austauschoperationen den direkten Zugriff auf einzelne Register ermöglicht.

Größerer virtueller Adressraum

Die AMD64-Architektur definiert ein 64-Bit-Format für virtuelle Adressen, von dem in aktuellen Implementierungen die niederwertigen 48 Bit verwendet werden. ^{[ 11 ] : 120} Dies ermöglicht einen virtuellen Adressraum von bis zu 256  TiB (2^⁴⁸ Byte ). Die Architekturdefinition erlaubt es, dieses Limit in zukünftigen Implementierungen auf die vollen 64 Bit anzuheben, ^{[ 11 ] : 2 : 3 : 13 : 117 : 120} wodurch der virtuelle Adressraum auf 16  EiB (2 ^⁶⁴ Byte) erweitert wird. ^{[ 18 ]} Zum Vergleich: x86 bietet lediglich 4  GiB (2^{³² Byte). [ 19 ]}

Dies bedeutet, dass sehr große Dateien bearbeitet werden können, indem die gesamte Datei in den Adressraum des Prozesses abgebildet wird (was oft viel schneller ist als die Arbeit mit Dateilese-/Schreibaufrufen), anstatt Bereiche der Datei in den Adressraum hinein- und wieder herauszubilden.

Größerer physischer Adressraum

Die ursprüngliche Implementierung der AMD64-Architektur nutzte 40-Bit- Physikalische Adressen und konnte somit bis zu 1 TiB (2^⁴⁰ Byte) RAM adressieren. ^{[ 11 ] : 24} Aktuelle Implementierungen der AMD64-Architektur (beginnend mit der AMD 10h-Mikroarchitektur ) erweitern dies auf 48-Bit-Physikalische Adressen ^{[ 20 ]} und können daher bis zu 256 TiB (2 ^⁴⁸ Byte) RAM adressieren. Die Architektur erlaubt zukünftig eine Erweiterung auf 52 Bit ^{[ 11 ] : 24 [ 21 ]} (begrenzt durch das Seitentabelleneintragsformat); ^{[ 11 ] : 131} dies würde die Adressierung von bis zu 4 PiB RAM ermöglichen. Zum Vergleich: 32-Bit-x86-Prozessoren sind im PAE-Modus ( Physical Address Extension ) auf 64 GiB RAM ^{[ 22 ]} bzw. ohne PAE-Modus auf 4 GiB RAM beschränkt. ^{[ 11 ] : 4}

Größerer physischer Adressraum im Legacy-Modus

Im Legacy-Modus unterstützt die AMD64-Architektur , wie die meisten aktuellen x86-Prozessoren, den Physical Address Extension (PAE)-Modus. AMD64 erweitert PAE jedoch von 36 Bit auf ein architektonisches Limit von 52 Bit physikalischer Adresse. Jede Implementierung ermöglicht daher dasselbe Limit für die physikalische Adresse wie im Long-Modus . ^{[ 11 ] : 24}

relativer Datenzugriff über den Befehlszeiger

Befehle können nun Daten relativ zum Befehlszeiger (RIP-Register) referenzieren. Dies macht positionsunabhängigen Code , wie er häufig in gemeinsam genutzten Bibliotheken und zur Laufzeit geladenem Code verwendet wird, effizienter.

SSE-Anweisungen

Die ursprüngliche AMD64-Architektur nutzte Intels SSE- und SSE2- Befehlssätze als Kernbefehle. Diese Befehlssätze ergänzen die skalare x87- FPU um Vektoroperationen für einfach- und doppeltgenaue Datentypen. SSE2 bietet zudem Vektoroperationen für ganzzahlige Datentypen mit einer Genauigkeit von 8 bis 64 Bit. Dadurch erreichte die Architektur in puncto Vektorleistung das Niveau der fortschrittlichsten x86-Prozessoren ihrer Zeit. Diese Befehle können auch im 32-Bit-Modus verwendet werden. Die Verbreitung von 64-Bit-Prozessoren hat diese Vektorleistung in Heimcomputern weit verbreitet und die Standards von 32-Bit-Anwendungen verbessert. Die 32-Bit-Version von Windows 8 beispielsweise benötigt SSE2-Befehle. ^{[ 23 ]} SSE3 -Befehle und spätere Streaming-SIMD-Erweiterungen gehören nicht zur Standardausstattung der Architektur.

No-Execute-Bit

Das No-Execute-Bit ( NX-Bit , Bit 63 des Seitentabelleneintrags) ermöglicht es dem Betriebssystem, festzulegen, welche Seiten des virtuellen Adressraums ausführbaren Code enthalten dürfen und welche nicht. Der Versuch, Code von einer mit „no execute“ gekennzeichneten Seite auszuführen, führt zu einer Speicherzugriffsverletzung, ähnlich dem Versuch, auf eine schreibgeschützte Seite zu schreiben. Dies erschwert es Schadcode, über Pufferüberlauf- oder ungeprüfte Pufferangriffe die Kontrolle über das System zu erlangen. Eine ähnliche Funktion ist bei x86-Prozessoren seit dem 80286 als Attribut von Segmentdeskriptoren verfügbar ; sie funktioniert jedoch jeweils nur auf ein gesamtes Segment.

Segmentierte Adressierung gilt seit Langem als veraltete Betriebsweise und wird von allen aktuellen PC-Betriebssystemen praktisch umgangen, indem alle Segmente auf eine Basisadresse von Null und (in ihrer 32-Bit-Implementierung) auf eine Größe von 4 GiB gesetzt werden. AMD war der erste Hersteller der x86-Familie, der die No-Execute-Funktion im linearen Adressierungsmodus implementierte. Diese Funktion ist auch im Legacy-Modus auf AMD64-Prozessoren und neueren Intel x86-Prozessoren verfügbar, sofern PAE verwendet wird.

Entfernung älterer Funktionen

Einige Systemprogrammierungsmerkmale der x86-Architektur wurden in modernen Betriebssystemen entweder nicht oder nur unzureichend genutzt und sind auf AMD64 im 64-Bit- und Kompatibilitätsmodus entweder gar nicht oder nur eingeschränkt verfügbar. Dazu gehören die segmentierte Adressierung (obwohl die Segmente FS und GS rudimentär als Zeiger auf Betriebssystemstrukturen außerhalb der Basis beibehalten werden) ^{[ 11 ] : 70,} der Task-Status- Umschaltmechanismus und der virtuelle 8086-Modus . Diese Merkmale sind im Legacy-Modus vollständig implementiert, sodass diese Prozessoren 32-Bit- und 16-Bit-Betriebssysteme ohne Änderungen ausführen können. Einige Befehle, die sich als selten nützlich erwiesen haben, werden im 64-Bit-Modus nicht unterstützt, darunter das Speichern/Wiederherstellen von Segmentregistern auf dem Stack, das Speichern/Wiederherstellen aller Register (PUSHA/POPA), Dezimalarithmetik, die Befehle BOUND und INTO sowie „weite“ Sprünge und Aufrufe mit unmittelbaren Operanden.

Kanonische Adressraum-Implementierungen (Diagramme nicht maßstabsgetreu)

Aktuelle 48-Bit-Implementierung

57-Bit-Implementierung

64-Bit-Implementierung

Obwohl virtuelle Adressen im 64-Bit-Modus 64 Bit breit sind, erlauben aktuelle Implementierungen (und alle bekannten Chips in Planung) nicht die Nutzung des gesamten virtuellen Adressraums von 2^⁶⁴ Byte (16¹⁰ EiB ). Dies entspräche etwa dem Vier-Milliardenfachen der Größe des virtuellen Adressraums auf 32-Bit-Systemen. Die meisten Betriebssysteme und Anwendungen benötigen in absehbarer Zeit keinen so großen Adressraum. Die Implementierung solch breiter virtueller Adressen würde daher lediglich die Komplexität und die Kosten der Adressübersetzung erhöhen, ohne einen wirklichen Nutzen zu bringen. AMD entschied sich daher, in den ersten Implementierungen der Architektur nur die niedrigstwertigen 48 Bit einer virtuellen Adresse für die Adressübersetzung ( Seitentabellenabfrage ) zu verwenden. ^{[ 11 ] : 120}

Darüber hinaus schreibt die AMD-Spezifikation vor, dass die höchstwertigen 16 Bits jeder virtuellen Adresse (Bits 48 bis 63) Kopien von Bit 47 sein müssen (ähnlich einer Vorzeichenerweiterung ). Wird diese Anforderung nicht erfüllt, löst der Prozessor eine Ausnahme aus. ^{[ 11 ] : 131} Adressen, die dieser Regel entsprechen, werden als „kanonische Form“ bezeichnet. ^{[ 11 ] : 130} Kanonische Adressen reichen von 0 bis 00007FFF'FFFFFFFF und von FFFF8000'00000000 bis FFFFFFFF'FFFFFFFF, was insgesamt 256  TiB nutzbaren virtuellen Adressraum ergibt. Dies ist immer noch 65.536-mal größer als der virtuelle 4-GiB-Adressraum von 32-Bit-Maschinen.

Diese Funktion erleichtert die spätere Skalierung auf echte 64-Bit-Adressierung. Viele Betriebssysteme (darunter die Windows NT- Familie) nutzen die höher adressierte Hälfte des Adressraums (den sogenannten Kernel-Adressraum ) für sich und überlassen die niedriger adressierte Hälfte ( den Benutzer-Adressraum ) Anwendungscode, Benutzermodus-Stacks, Heaps und anderen Datenbereichen. ^{[ 24 ]} Das Design mit der „kanonischen Adresse“ stellt sicher, dass jede AMD64-kompatible Implementierung effektiv zwei Speicherhälften besitzt: Die untere Hälfte beginnt bei 00000000'000000000 und wächst nach oben, sobald weitere virtuelle Adressbits verfügbar sind, während die obere Hälfte am oberen Rand des Adressraums angedockt ist und nach unten wächst. Darüber hinaus verhindert die Durchsetzung der "kanonischen Form" von Adressen durch Überprüfung der ungenutzten Adressbits, dass diese vom Betriebssystem in getaggten Zeigern als Flags, Privilegienmarkierungen usw. verwendet werden, da eine solche Verwendung problematisch werden könnte, wenn die Architektur erweitert wird, um mehr virtuelle Adressbits zu implementieren.

Die ersten Windows-Versionen für x64 nutzten nicht einmal die vollen 256 TiB; sie waren auf lediglich 8 TiB Benutzerspeicher und 8 TiB Kernelspeicher beschränkt. ^{[ 24 ]} Windows unterstützte den gesamten 48-Bit-Adressraum erst ab Windows 8.1 , das im Oktober 2013 veröffentlicht wurde. ^{[ 24 ]}

Der 64-Bit-Adressierungsmodus („ Langmodus “) ist eine Erweiterung der Physical Address Extensions (PAE). Daher können  Seitengrößen 4 KiB (2^¹² Byte) oder 2  MiB (2^²¹ Byte) betragen. ^{[ 11 ] : 120} Der Langmodus unterstützt auch Seitengrößen von 1  GiB (2 ^³⁰ Byte). ^{[ 11 ] : 120} Anstelle des dreistufigen Seitentabellensystems , das von Systemen im PAE-Modus verwendet wird, nutzen Systeme im Langmodus vier Ebenen: Die Page-Directory Pointer Table (PDL) von PAE wird von vier auf 512 Einträge erweitert, und eine zusätzliche Page-Map Level 4 (PML4)-Tabelle mit 512 Einträgen in 48-Bit-Implementierungen wird hinzugefügt. ^{[ 11 ] : 131} Eine vollständige Mapping-Hierarchie von 4 KiB Seiten für den gesamten 48-Bit-Speicher würde etwas mehr als 512  GiB Speicherplatz beanspruchen (etwa 0,195 % des virtuellen Speichers von 256 TiB).

64-Bit-Seitentabelleneintrag

Bits:	63	62 ... 52											51 ... 32
Inhalt:	NX	reserviert											Bit 51…32 der Basisadresse
Bits:	31 ... 12																				11 ... 9			8	7	6	5	4	3	2	1	0
Inhalt:	Bit 31…12 der Basisadresse																				ign.			G	KLOPFEN	D	A	PCD	PWT	UNS	R/W	P

Intel hat ein Schema mit einer 5-stufigen Seitentabelle implementiert , das es Intel-64-Prozessoren ermöglicht, 57-Bit-Adressen und damit einen  virtuellen Adressraum von 128 PiB zu unterstützen. ^{[ 25 ]} Weitere Erweiterungen könnten einen vollständigen 64-Bit-Adressraum und physischen Speicher mit 12-Bit-Seitentabellendeskriptoren und 16- oder 21-Bit-Speicher-Offsets für Seitenzuordnungsgrößen von 64 KiB und 2 MiB ermöglichen; der Seitentabelleneintrag würde auf 128 Bit erweitert, um zusätzliche Hardware-Flags für die Seitengröße und die Größe des virtuellen Adressraums zu unterstützen. ^{[ 26 ]}

Das Betriebssystem kann auch den virtuellen Adressraum einschränken. Einzelheiten hierzu finden sich gegebenenfalls im Abschnitt „ Kompatibilität und Eigenschaften des Betriebssystems “.

Aktuelle AMD64-Prozessoren unterstützen einen physischen Adressraum von bis zu 2 ^⁴⁸ Byte RAM bzw. 256  TiB . ^{[ 20 ]} Allerdings waren im Jahr 2020 keine x86-64- Mainboards bekannt , die 256 TiB RAM unterstützten. ^{[ 27 ] [ 28 ] [ 29 ] [ 30 ]} Das Betriebssystem kann zusätzliche Beschränkungen für die nutzbare oder unterstützte RAM-Menge festlegen. Details hierzu finden Sie im Abschnitt „ Betriebssystemkompatibilität und -eigenschaften “ dieses Artikels.

Die Architektur verfügt über zwei primäre Betriebsmodi: den Langzeitmodus und den Legacy-Modus.

Der Langmodus ist der primäre Betriebsmodus der Architektur. Er kombiniert den nativen 64-Bit-Modus des Prozessors mit einem 32-Bit- und einem 16-Bit-Kompatibilitätsmodus. Er wird von 64-Bit-Betriebssystemen verwendet. Unter einem 64-Bit-Betriebssystem laufen 64-Bit-Programme im 64-Bit-Modus, während 32-Bit- und 16-Bit-Anwendungen im geschützten Modus (die weder den Realmodus noch den virtuellen 8086-Modus benötigen) im Kompatibilitätsmodus ausgeführt werden. Realmodus-Programme und Programme, die den virtuellen 8086-Modus nutzen, können nicht im Langmodus ausgeführt werden, es sei denn, diese Modi werden softwareseitig emuliert. ^{[ 11 ] : 11} Solche Programme können jedoch von einem Betriebssystem im Langmodus auf Prozessoren mit VT-x- oder AMD-V- Unterstützung gestartet werden , indem ein virtueller Prozessor im gewünschten Modus erstellt wird.

Da der grundlegende Befehlssatz identisch ist, entstehen beim Ausführen von x86-Code im geschützten Modus praktisch keine Leistungseinbußen. Dies unterscheidet sich von Intels IA-64 , wo Unterschiede im zugrundeliegenden Befehlssatz bedeuten, dass 32-Bit-Code entweder in x86-Emulation (was den Prozess verlangsamt) oder mit einem dedizierten x86-Coprozessor ausgeführt werden muss. Auf der x86-64-Plattform können jedoch viele x86-Anwendungen von einer 64-Bit- Neukompilierung profitieren , da 64-Bit-Code zusätzliche Register und garantierte SSE2-basierte FPU-Unterstützung bietet, die ein Compiler zur Optimierung nutzen kann. Anwendungen, die regelmäßig mit mehr als 32 Bit breiten Ganzzahlen arbeiten, wie beispielsweise kryptografische Algorithmen, benötigen jedoch eine Überarbeitung des Codes zur Verarbeitung dieser großen Ganzzahlen, um die 64-Bit-Register nutzen zu können.

Der Legacy-Modus ist der Betriebsmodus des Prozessors, wenn er sich nicht im Langzeitmodus befindet. ^{[ 11 ] : 14} In diesem Modus verhält sich der Prozessor wie ein älterer x86-Prozessor, und es können nur 16-Bit- und 32-Bit-Code ausgeführt werden. Der Legacy-Modus erlaubt eine virtuelle Adressierung von maximal 32 Bit, wodurch der virtuelle Adressraum auf 4 GiB begrenzt ist. ^{[ 11 ] : 14 : 24 : 118} 64-Bit-Programme können nicht im Legacy-Modus ausgeführt werden.

Der geschützte Modus ist ein Untermodus des Legacy-Modus. ^{[ 11 ] : 14} Er ist der Untermodus, in dem 32-Bit-Betriebssysteme und 16-Bit-Betriebssysteme im geschützten Modus auf einer x86-64-CPU ausgeführt werden. ^{[ 11 ] : 14}

Der Realmodus ist der anfängliche Betriebsmodus des Prozessors und ein Untermodus des Legacy-Modus. Er ist abwärtskompatibel zu den ursprünglichen Intel 8086- und Intel 8088 -Prozessoren. Der Realmodus wird heute hauptsächlich von den Bootloadern des Betriebssystems verwendet, die aufgrund der Architektur erforderlich sind, um die Details des virtuellen Speichers vor dem Übergang in höhere Modi zu konfigurieren. Dieser Modus wird auch von jedem Betriebssystem verwendet, das über eine herkömmliche BIOS -ähnliche Schnittstelle mit der Systemfirmware kommunizieren muss . ^{[ 31 ]}

Intel 64 ist Intels Implementierung von x86-64, die in verschiedenen von Intel hergestellten Prozessoren verwendet und implementiert wird.

Historisch gesehen hat AMD Prozessoren mit Befehlssätzen entwickelt und produziert, die den ursprünglichen Entwürfen von Intel nachempfunden waren. Bei x86-64 haben sich die Rollen jedoch umgekehrt: Intel sah sich gezwungen, die von AMD geschaffene Befehlssatzarchitektur als Erweiterung der eigenen x86-Prozessorlinie zu übernehmen.

Intels Projekt trug ursprünglich den Codenamen Yamhill ^{[ 32 ]} (nach dem Yamhill River im Willamette Valley in Oregon). Nachdem Intel die Existenz des Projekts mehrere Jahre lang geleugnet hatte, gab das Unternehmen im Februar 2004 auf der IDF bekannt , dass es tatsächlich lief. Der damalige Intel-Vorsitzende Craig Barrett räumte ein, dass dies eines ihrer am schlechtesten gehüteten Geheimnisse gewesen sei. ^{[ 33 ] [ 34 ]}

Intels Bezeichnung für diesen Befehlssatz hat sich mehrmals geändert. Auf der IDF-Konferenz wurde er als CT ^{[ 35 ]} (vermutlich für Clackamas Technology , ein weiterer Codename, der von einem Fluss in Oregon stammt) bezeichnet. Im März 2004 wurde dann die „offizielle“ Bezeichnung EM64T (Extended Memory 64 Technology) bekanntgegeben . Ende 2006 begann Intel stattdessen die Bezeichnung Intel 64 für seine Implementierung zu verwenden, analog zu AMDs Verwendung der Bezeichnung AMD64. ^{[ 36 ]}

Der erste Prozessor mit Intel 64 war der Multi-Socket-Prozessor Xeon mit dem Codenamen Nocona im Juni 2004. Im Gegensatz dazu unterstützten die ersten Prescott-Chips (Februar 2004) diese Funktion nicht. Intel begann anschließend mit dem Verkauf von Intel 64-fähigen Pentium 4-Prozessoren, die auf der E0-Revision des Prescott-Kerns basierten und als Pentium 4 Modell F auf dem OEM-Markt vertrieben wurden. Die E0-Revision führte außerdem eXecute Disable (XD) (Intels Bezeichnung für das NX-Bit ) in Intel 64 ein und war bereits im damaligen Xeon mit dem Codenamen Irwindale enthalten . Intels offizielle Markteinführung von Intel 64 (damals unter der Bezeichnung EM64T) in Mainstream-Desktop-Prozessoren erfolgte mit dem N0-Stepping-Prozessor Prescott-2M im Februar 2005. ^{[ 37 ]}

Der erste mobile Intel-Prozessor mit Intel 64-Architektur war der Merom Core 2 , der am 27. Juli 2006 auf den Markt kam. Keiner der früheren Notebook-Prozessoren von Intel ( Core Duo , Pentium M , Celeron M , Mobile Pentium 4 ) implementierte Intel 64.

Zu den Intel-Prozessoren mit Intel64-Architektur gehören die Pentium 4 F-Serie/5x1-Serie, 506 und 516, die Celeron D- Modelle 3x1, 3x6, 355, 347, 352, 360 und 365 sowie alle späteren Celeron -Modelle, alle Xeon- Modelle seit „ Nocona “, alle Pentium Dual-Core -Prozessoren seit „ Merom-2M “, die Atom -Prozessoren 230, 330, D410, D425, D510, D525, N450, N455, N470, N475, N550, N570, N2600 und N2800, alle Pentium D- , Pentium Extreme Edition- , Core 2- , Core i9- , Core i7- , Core i5- und Core i3 -Prozessoren sowie der Xeon Phi. Prozessoren der Serie 7200.

VIA Technologies stellte 2008 nach fünfjähriger Entwicklungszeit durch seine CPU-Abteilung Centaur Technology die erste Implementierung der x86-64-Architektur vor . ^{[ 38 ]} Die unter dem Codenamen „Isaiah“ entwickelte 64-Bit-Architektur wurde am 24. Januar 2008 vorgestellt ^{[ 39 ]} und am 29. Mai unter dem Markennamen VIA Nano auf den Markt gebracht. ^{[ 40 ]}

Der Prozessor unterstützt eine Reihe von VIA-spezifischen x86-Erweiterungen, die die Effizienz in Geräten mit geringem Stromverbrauch steigern sollen. Vor der Markteinführung gab VIA an, dass die Isaiah-Architektur bei gleicher Taktfrequenz die doppelte Integer- und die vierfache Gleitkomma-Leistung der Vorgängergeneration VIA Esther erreichen sollte . Auch der Stromverbrauch sollte mit dem der vorherigen VIA-CPU-Generation vergleichbar sein, mit einer TDP zwischen 5 W und 25 W. ^{[ 41 ]} Als komplett neue Architektur bietet die Isaiah Unterstützung für Funktionen wie den x86-64-Befehlssatz und x86-Virtualisierung , die bei den Vorgängern der VIA C7- Serie nicht verfügbar waren , während die Verschlüsselungserweiterungen erhalten blieben.

Im Jahr 2020 wurden in Zusammenarbeit von AMD, Intel, Red Hat und SUSE drei Mikroarchitekturebenen (oder Feature-Ebenen) auf Basis der x86-64-Architektur definiert: x86-64-v2, x86-64-v3 und x86-64-v4. ^{[ 42 ] [ 43 ]} Diese Ebenen definieren spezifische Features, die Programmierer gezielt nutzen können, um Optimierungen zur Kompilierzeit zu erzielen. Die von jeder Ebene bereitgestellten Features sind wie folgt: ^{[ 44 ]}

Die Feature-Level der x86-64-Mikroarchitektur finden sich auch als AMD64-v1, AMD64-v2 usw. oder AMD64_v1 usw. in Umgebungen, in denen die Bezeichnung „AMD64“ verwendet wird. Diese werden synonym mit der x86-64-vX-Bezeichnung verwendet und sind daher funktional identisch. Beispiele hierfür sind die Dokumentation der Programmiersprache Go und die Linux-Distribution Fedora.

Alle Stufen beinhalten die Funktionen der vorherigen Stufen. Befehlssatzerweiterungen, die nicht für allgemeine Berechnungen relevant sind, einschließlich AES-NI und RDRAND , sind von den Stufenanforderungen ausgenommen.

Bei den meisten aktuellen x86_64-Linux-Distributionen lassen sich alle von einer CPU unterstützten x86_64-Funktionsebenen mit folgendem Befehl überprüfen: /lib64/ld-linux-x86-64.so.2 --help(verfügbar ab glibc 2.33 ^{[ 45 ]} ). Das Ergebnis wird am Ende der Befehlsausgabe angezeigt.

Unterverzeichnisse der glibc-hwcaps-Verzeichnisse, in Prioritätsreihenfolge:  x86-64-v4  x86-64-v3 (unterstützt, durchsucht)  x86-64-v2 (unterstützt, durchsucht)

Hier wird die x86-64-v4-Funktionsebene von der CPU nicht unterstützt, x86-64-v3 und x86-64-v2 hingegen schon, was bedeutet, dass diese CPU AVX512, das auf der v4-Ebene erforderlich ist, nicht unterstützt.

Obwohl die beiden Befehlssätze nahezu identisch sind, gibt es Unterschiede in der Semantik einiger selten verwendeter Maschinenbefehle (oder Situationen), die hauptsächlich für die Systemprogrammierung genutzt werden . ^{[ 46 ]} Sofern nicht anders konfiguriert -march, erzeugen Compiler in der Regel ausführbare Dateien (d. h. Maschinencode ), die diese Unterschiede – zumindest für gewöhnliche Anwendungsprogramme – vermeiden . Dies ist daher vor allem für Entwickler von Compilern, Betriebssystemen und ähnlichen Systemen relevant, die mit individuellen und speziellen Systembefehlen arbeiten müssen.

• Intel 64 erlaubt SYSCALL/ SYSRETnur im 64-Bit-Modus (nicht im Kompatibilitätsmodus) ^{[ 47 ]} und erlaubt SYSENTER/ SYSEXITin beiden Modi. ^{[ 48 ]} AMD64 fehlt SYSENTER/ SYSEXITin beiden Untermodi des Langmodus . ^{[ 11 ] : 33}
• Bei der Rückkehr zu einer nicht-kanonischen Adresse mittels SYSRET, führen AMD64-Prozessoren den allgemeinen Schutzfehlerbehandler auf Berechtigungsstufe 3 aus, ^{[ 49 ]} während er auf Intel 64-Prozessoren auf Berechtigungsstufe 0 ausgeführt wird. ^{[ 50 ]}
• Der SYSRETBefehl lädt auf Intel 64 einen Satz fester Werte in den versteckten Teil des SSSegmentregisters (Basisadresse, Limit, Attribute), lässt diesen aber SSauf AMD64 unverändert. ^{[ 51 ]}
• Auf Intel 64 setzt der Befehl die Berechtigungsstufe (RPL) des Segmentregisters SYSRETbedingungslos auf 3 (da der Befehl eine Rückkehr zur Berechtigungsstufe 3 bewirkt). ^{[ 52 ]} Auf AMD64 wird die RPL auf die entsprechenden Bits im STAR MSR ( modellspezifisches Register ) gesetzt, d. h. auf die Bits 49 und 48. ^{[ 53 ]}SS
• AMD64 benötigt ein anderes Mikrocode-Update-Format und andere Control-MSRs, während Intel 64 das Mikrocode- Update unverändert gegenüber seinen 32-Bit-Prozessoren implementiert.
• Intel 64 fehlen einige MSRs, die bei AMD64 als architektonisch gelten. Dazu gehören SYSCFG, TOP_MEM, und TOP_MEM2.
• Intel 64 fehlt die Fähigkeit, eine reduzierte (und damit schnellere) Version des Gleitkommazustands zu speichern und wiederherzustellen (unter Einbeziehung der Befehle FXSAVEund FXRSTOR).
• Auf AMD64 speichern und stellen die FXSAVE/ FXRSTOR-Befehle x87-Ausnahmezeiger (FCS/FIP, FDS/FDP, FOP) nur dann wieder her, wenn eine nicht maskierte, ausstehende x87-Ausnahme vorliegt. ^{[ 54 ] [ 55 ]} Auf Intel 64 werden diese Zeiger unabhängig vom Status der x87-Ausnahme immer gespeichert und wiederhergestellt.
• Im 64-Bit-Modus verhalten sich nahe Verzweigungen mit dem Präfix 66H (Operandengrößenüberschreibung) anders. Intel 64 ignoriert dieses Präfix: Der Befehl hat einen 32-Bit-Offset mit Vorzeichenerweiterung, und der Befehlszeiger wird nicht abgeschnitten. AMD64 verwendet ein 16-Bit-Offsetfeld im Befehl und löscht die oberen 48 Bit des Befehlszeigers.
• Auf Intel 64, nicht aber auf AMD64, kann das Präfix mit den Far-Pointer-Befehlen ( , , , , ) REX.Wverwendet werden , um die Größe ihres Far-Pointer -Arguments auf 80 Bit (64-Bit-Offset + 16-Bit-Segment) zu erhöhen.LFSLGSLSSJMP FARCALL FAR
• Wird der MOVSXDBefehl mit einem Speicherquellenoperanden und einer Operandengröße von 16 Bit ausgeführt, wird auf Intel 64 mit einem 16-Bit-Lesezugriff auf den Speicheroperanden zugegriffen, auf AMD64 jedoch mit einem 32-Bit-Lesezugriff.
• Wird der Befehl mit einem Segmentregister und einer Operandengröße von 32 Bit im Legacy-/Kompatibilitätsmodus PUSHverwendet , erweitert AMD64 das Register mit Nullen von 2 auf 4 Byte und legt diesen 4-Byte-Wert auf den Stack. Intel 64 dekrementiert den Stackpointer ebenfalls um 4, schreibt aber nur 2 Byte, wodurch eine 2-Byte-Lücke entsteht, die nicht beschrieben wird. ^{[ 56 ] [ 57 ]}
• Wird der POPBefehl mit einem Segmentregister und einer Operandengröße von 32 oder 64 Bit verwendet, führt AMD64 einen Speicherlesevorgang vom Stack durch, der so breit ist wie die Operandengröße, während Intel 64 einen 16-Bit-Speicherlesevorgang durchführt (aber den Stackpointer weiterhin entsprechend der Operandengröße inkrementiert). ^{[ 57 ]}
• Die FCOMI/ FCOMIP/ FUCOMI/ FUCOMIP(x87 Gleitkommavergleich) Befehle löschen die OF-, SF- und AF-Bits von EFLAGS auf Intel 64, lassen diese Flag-Bits aber auf AMD64 unverändert.
• Für die VMASKMOVPS/ VMASKMOVPD/ VPMASKMOVD/ VPMASKMOVQ(AVX/AVX2 maskierte Verschiebung in/aus dem Speicher) Befehle garantiert Intel 64 architektonisch, dass die Befehle keine Speicherfehler (z. B. Seitenfehler und Segmentierungsfehler) für Null-maskierte Lanes verursachen, während AMD64 eine solche Garantie nicht bietet.
• Falls die RDRANDAnweisung keine Zufallszahl erzeugen kann (wie durch angezeigt EFLAGS.CF=0), ist architektonisch garantiert, dass das Zielregister auf Intel 64 auf 0 gesetzt wird, nicht aber auf AMD64.
• Für die VPINSRDAVX VPEXTRD-Vektor-Einfüge-/Extraktionsbefehle (AVX Vector Lane Insert/Extract) außerhalb des 64-Bit-Modus verlangt AMD64, dass die Befehle mit kodiert werden VEX.W=0, während Intel 64 auch Kodierungen mit akzeptiert VEX.W=1. (Im 64-Bit-Modus benötigen sowohl AMD64 als auch Intel 64 VEX.W=0.)
• Wenn die Ausrichtungsprüfung aktiviert ist ( EFLAGS.AC=1), verursachen AVX-Befehle mit falsch ausgerichteten 128-Bit- oder 256-Bit-Speicheroperanden sowie die SSE4.2 PCMP*STR*-Befehle mit falsch ausgerichteten 128-Bit-Speicheroperanden #AC-Ausnahmen (Ausrichtungsprüfung) auf AMD64 ^{[ 58 ]} , jedoch nicht auf Intel 64. ^{[ 59 ]}
• Der 0F 0D /rOpcode, bei dem das Mod-Feld des ModR/M- Bytes auf einen Wert gesetzt ist, ist auf Intel 64 11bein reservierter NOP ^{[ 60 ]} , führt aber auf AMD64 zu einer #UD (Ungültiger-Opcode-Ausnahme) ^{[ 61 ] .}
• Die von einigen Speicherbelegungsanweisungen wie z LFENCE. B. bereitgestellten Reihenfolgegarantien MFENCEunterscheiden sich zwischen Intel 64 und AMD64:
  • LFENCEist auf Intel 64 dispatch-serialisierend (wodurch es als Spekulationsbarriere verwendet werden kann ), aber architektonisch nicht garantiert dispatch-serialisierend auf AMD64. ^{[ 62 ]}
  • MFENCEist eine vollständig serialisierende Anweisung (einschließlich Befehlsabrufsserialisierung) auf AMD64, aber nicht auf Intel 64.
  • Die Befehle MOVzu CR8 INVPCIDwerden auf AMD64 serialisiert, nicht aber auf Intel 64.
  • Der LMSWBefehl wird auf Intel 64 serialisiert, jedoch nicht auf AMD64.
  • WRMSRDer x2APIC ICR (Interrupt Command Register; MSR 830h) wird häufig verwendet, um einen IPI ( Interprocessor Interrupt ) zu erzeugen - auf Intel 64 ^{[ 63 ]} CPUs , aber nicht auf AMD64 ^{[ 64 ]} CPUs, kann ein solcher IPI vor einem älteren Speichervorgang neu angeordnet werden.
  • Bei neueren AMD64-Prozessoren ( Zen 4 und höher) erfolgt der Zugriff auf WRMSRdie MSRs nicht serialisiert. ^{[ 65 ]} Bei Intel64-Prozessoren sowie älteren AMD64-Prozessoren erfolgt der Zugriff auf diese MSRs serialisiert.FS_BASEGS_BASEKernelGSBaseWRMSR

• Die AMD64-Prozessoren vor Revision F ^{[ 66 ]} (erkennbar am Wechsel von DDR- zu DDR2 -Speicher und den Sockeln AM2 , F und S1 ) aus dem Jahr 2006 besaßen nicht die CMPXCHG16BAnweisung `std::column`, eine Erweiterung der CMPXCHG8BAnweisung, die auf den meisten Prozessoren nach dem 80486 vorhanden ist . Ähnlich wie CMPXCHG8B`std::column` CMPXCHG16Bermöglicht `std:: column` atomare Operationen auf Oktawörtern (128-Bit-Werten). Dies ist nützlich für parallele Algorithmen, die Vergleiche und Tauschvorgänge auf Daten durchführen, die größer als die Größe eines Zeigers sind, wie sie häufig bei sperrfreien und wartefreien Algorithmen vorkommen . Ohne ` CMPXCHG16Bstd::column` muss man auf Workarounds wie kritische Abschnitte oder alternative sperrfreie Ansätze zurückgreifen. ^{[ 67 ]} Das Fehlen dieser Anweisung verhindert außerdem, dass 64-Bit -Windows vor Windows 8.1 einen Benutzermodus- Adressraum von mehr als 8  TiB haben . ^{[ 68 ]} Alle 64-Bit-Versionen von Windows seit Windows 8.1 benötigen die Anweisung `std::column`. ^{[ 69 ]}
• Frühe AMD64- und Intel64-CPUs unterstützten die Befehle im 64-Bit-Modus nicht LAHF. SAHFAMD führte diese Befehle (ebenfalls im 64-Bit-Modus) mit seinen 90-nm- Prozessoren (Revision D) ein, beginnend mit dem Athlon 64 im Oktober 2004. ^{[ 70 ] [ 71 ]} Intel führte die Befehle im Oktober 2005 mit der 0F47h- und späteren Revisionen von NetBurst ein . ^{[ b ]} Alle 64-Bit-Versionen von Windows seit Windows 8.1 benötigen diese Funktion. ^{[ 69 ]}
• Frühe Intel-Prozessoren mit Intel 64 besaßen auch nicht das NX-Bit der AMD64-Architektur. Dieses wurde im Oktober 2004 mit dem Pentium 4 der Stepping-Version E0 (0F41h) hinzugefügt. ^{[ 77 ]} 64-Bit-Versionen von Windows ab Windows 8.1 benötigen diese Funktion. ^{[ 69 ]}
• Frühe Intel-64-Implementierungen nutzten eine 36-Bit-Speicheradressierung (64 GiB), während die ursprünglichen AMD64-Implementierungen eine 40-Bit-Speicheradressierung (1  TiB ) verwendeten. Intel setzte die 40-Bit-Speicheradressierung erstmals beim Xeon MP ( Potomac ) ein, der am 29. März 2005 auf den Markt kam. ^{[ 78 ]} Der Unterschied betrifft nicht die für den Benutzer sichtbaren Befehlssatzarchitekturen (ISAs). Im Jahr 2007 bot der auf AMD 10h basierende Opteron als erster Prozessor einen 48-Bit-Speicheradressraum (256 TiB). ^{[ 79 ] [ 80 ]} Die physische Adressierung von Intel 64 wurde 2010 mit Nehalem-EX auf 44 Bit (16 TiB) ^{[ 81 ]} und 2011 mit Sandy Bridge E auf 46 Bit (64 TiB) erweitert. ^{[ 82 ] [ 83 ]} Mit den Ice Lake Xeon Scalable Prozessoren der 3. Generation erhöhte Intel  2021 die virtuelle Adressierung auf 57 Bit (128 PiB ) und die physische auf 52 Bit (4 PiB), was ein 5-stufiges Paging erforderlich machte . ^{[ 84 ]} Im darauffolgenden Jahr führte AMD 64 die gleiche Funktion mit der 4. Generation EPYC (Genoa) ein. ^{[ 85 ]} Nicht-Server-CPUs behielten kleinere Adressräume länger bei.
• Bei allen AMD64-Prozessoren lassen die Befehle ` BSFand` BSRbei einem Quellwert von 0 das Zielregister unverändert. Dies gilt größtenteils auch für Intel 64-Prozessoren, mit der Ausnahme, dass bei einigen älteren Intel 64-CPUs die Ausführung dieser Befehle mit einer Operandengröße von 32 Bit die oberen 32 Bit des Zielregisters löscht, selbst bei einem Quellwert von 0 (wobei die unteren 32 Bit unverändert bleiben). ^{[ 86 ]}
• AMD64-Prozessoren seit Opteron Rev. E und Athlon 64 Rev. D führten die eingeschränkte Unterstützung für Segmentierung über das Long Mode Segment Limit Enable (LMSLE)-Bit wieder ein, um die Virtualisierung von 64-Bit-Gastsystemen zu vereinfachen. ^{[ 87 ] [ 88 ]} Die LMSLE-Unterstützung wurde im Zen-3-Prozessor entfernt. ^{[ 89 ]}
• Bei allen Intel 64-Prozessoren CLFLUSHist die Befehlsreihenfolge relativ zu den Befehlen festgelegt SFENCE– dies gilt auch für neuere AMD 64-Prozessoren (Zen 1 und höher). Bei älteren AMD 64-Prozessoren erforderte die Festlegung der CLFLUSHBefehlsreihenfolge stattdessen die Verwendung von MFENCE.
• Bei älteren AMD64-Prozessoren wurde das Speichern/Wiederherstellen von x87-Fehlerzeigern (FCS/FIP, FDS/FDP, FOP) durch die XSAVE/ XRSTOR-Anweisung nur dann verhindert, wenn eine nicht maskierte, ausstehende x87-Ausnahme vorlag. Bei Intel64-Prozessoren und neueren AMD64-Prozessoren (Zen 1 und höher) werden diese Fehlerzeiger hingegen immer gespeichert und wiederhergestellt. (Dieser Unterschied zwischen Intel und AMD besteht jedoch weiterhin für die FXSAVE/ FXRSTOR-Anweisung.)

Bei den von TOP500 erfassten Supercomputern ermöglichte das Aufkommen von 64-Bit-Erweiterungen für die x86-Architektur den 64-Bit-x86-Prozessoren von AMD und Intel, die meisten der zuvor in solchen Systemen verwendeten RISC-Prozessorarchitekturen (einschließlich PA-RISC , SPARC , Alpha und anderer) sowie 32-Bit-x86 zu ersetzen, obwohl Intel selbst zunächst erfolglos versucht hatte, x86 durch eine neue, inkompatible 64-Bit-Architektur im Itanium- Prozessor zu ersetzen.

Der HPE -EPYC- basierte Supercomputer Frontier belegte 2023 den ersten Platz. Der erste ARM-basierte Supercomputer tauchte 2018 in der Liste auf ^{[ 91 ]} , und in den letzten Jahren spielten auch Coprozessoren ohne CPU-Architektur ( GPGPU ) eine wichtige Rolle für die Leistung. Intels Xeon-Phi-„Knights-Corner“ -Coprozessoren, die eine Teilmenge von x86-64 mit einigen Vektorerweiterungen implementieren ^{[ 92 ]} , werden neben x86-64-Prozessoren auch im Supercomputer Tianhe-2 eingesetzt ^{[ 93 ] .}

Die folgenden Betriebssysteme und Versionen unterstützen die x86-64-Architektur im Langmodus .

Im Februar 2004 begannen die Vorarbeiten für die Infrastruktur einer x86-64-Portierung. ^{[ 94 ]} Diese Entwicklung kam später zum Erliegen. Im Juli 2007 wurde sie wieder aufgenommen ^{[ 95 ]} und im Rahmen des Google Summer of Code 2008 und des SoC 2009 fortgesetzt. ^{[ 96 ] [ 97 ]} Die erste offizielle Version mit x86-64-Unterstützung war Version 2.4 aus dem Jahr 2009. ^{[ 98 ]}

FreeBSD führte die x86-64-Unterstützung unter dem Namen „amd64“ als experimentelle Architektur in Version 5.1-RELEASE im Juni 2003 ein. Ab Version 5.2-RELEASE im Januar 2004 wurde sie als Standard-Distributionsarchitektur integriert. Seitdem gilt sie unter FreeBSD als Tier-1-Plattform. Version 6.0-RELEASE behob einige Probleme beim Ausführen von x86-Programmen unter amd64, und die meisten Treiber funktionieren wie auf der x86-Architektur. Aktuell wird an einer umfassenderen Integration der x86- Anwendungsschnittstelle (ABI) gearbeitet, analog zur bestehenden Linux-32-Bit-ABI-Kompatibilität.

Die Unterstützung für die x86-64-Architektur wurde erstmals am 19. Juni 2001 in den NetBSD- Quellcode aufgenommen. Seit NetBSD 2.0, veröffentlicht am 9. Dezember 2004, ist NetBSD/amd64 eine vollständig integrierte und unterstützte Portierung. 32-Bit-Code wird weiterhin im 64-Bit-Modus unterstützt, wobei eine NetBSD-32-Kernel-Kompatibilitätsschicht für 32-Bit-Systemaufrufe verwendet wird. Das NX-Bit dient dazu, nicht ausführbaren Stack und Heap seitenweise zu verwalten (auf 32-Bit-x86 wird segmentweise Verwaltung verwendet).

OpenBSD unterstützt AMD64 seit Version 3.5, die am 1. Mai 2004 veröffentlicht wurde. Die vollständige Integration der AMD64-Unterstützung in den OpenBSD-Quellcode erfolgte bereits vor der Markteinführung der Hardware, da AMD dem Projekt im Rahmen eines Hackathons in diesem Jahr mehrere Maschinen zur Verfügung gestellt hatte. OpenBSD-Entwickler schätzen die Plattform besonders wegen ihrer Unterstützung des NX-Bits , die eine einfache Implementierung der W^X- Funktion ermöglichte .

Der Code für die AMD64-Portierung von OpenBSD läuft auch auf Intel-64-Prozessoren und nutzt die AMD64-Erweiterungen. Da Intel jedoch bei frühen Intel-64-Prozessoren das NX-Bit der Seitentabelle weggelassen hat, fehlt diesen CPUs die W^X-Funktionalität. Spätere Intel-64-Prozessoren führten das NX-Bit unter der Bezeichnung „XD-Bit“ ein. Symmetrisches Multiprocessing (SMP) ist auf der AMD64-Portierung von OpenBSD ab Version 3.6 vom 1. November 2004 verfügbar.

Es ist möglich, unter DOS ohne DOS-Extender in den Langzeitmodus zu wechseln, ^{[ 99 ]} aber der Benutzer muss in den Realmodus zurückkehren, um BIOS- oder DOS-Interrupts aufrufen zu können.

Möglicherweise lässt sich der Langzeitmodus auch mit einem DOS-Extender ähnlich wie DOS/4GW aktivieren , allerdings ist dies komplexer, da x86-64 keinen virtuellen 8086-Modus besitzt . DOS selbst ist sich dessen nicht bewusst, und es sind keine Vorteile zu erwarten, es sei denn, DOS wird in einer Emulation mit einem geeigneten Virtualisierungstreiber-Backend ausgeführt, beispielsweise der Massenspeicherschnittstelle.

Linux war der erste Betriebssystemkernel, der die x86-64-Architektur im Langmodus unterstützte , beginnend mit Version 2.4 im Jahr 2001 (noch vor der Verfügbarkeit der Hardware). ^{[ 100 ] [ 101 ]} Linux bietet zudem Abwärtskompatibilität für die Ausführung von 32-Bit-Programmen. Dadurch können Programme im Langmodus neu kompiliert werden, während die Verwendung von 32-Bit-Programmen weiterhin möglich ist. Aktuelle Linux-Distributionen werden mit nativen x86-64-Kerneln und Benutzerumgebungen ausgeliefert . Einige, wie Arch Linux , ^{[ 102 ]} SUSE , Mandriva und Debian , ermöglichen es Benutzern, beim Installieren von einem 64-Bit-Medium einen Satz von 32-Bit-Komponenten und -Bibliotheken zu installieren. Dadurch können die meisten bestehenden 32-Bit-Anwendungen parallel zum 64-Bit-Betriebssystem ausgeführt werden.

Die in Linux 3.4 eingeführte x32-ABI (Application Binary Interface) ermöglicht es für die x32-ABI kompilierten Programmen, im 64-Bit-Modus von x86-64 ausgeführt zu werden, wobei ausschließlich 32-Bit-Zeiger und -Datenfelder verwendet werden. ^{[ 103 ] [ 104 ] [ 105 ]} Dies beschränkt zwar den virtuellen Adressraum des Programms auf 4 GiB, reduziert aber gleichzeitig dessen Speicherbedarf und kann in manchen Fällen zu einer höheren Ausführungsgeschwindigkeit führen. ^{[ 103 ] [ 104 ] [ 105 ]}

64-Bit-Linux ermöglicht bis zu 128  TiB virtuellen Adressraum für einzelne Prozesse und kann, abhängig von Prozessor- und Systembeschränkungen, etwa 64 TiB physischen Speicher adressieren ^{[ 106 ]} oder bis zu 128 PiB (virtuell) und 4 PiB (physisch) mit aktiviertem 5-stufigem Paging. ^{[ 107 ]}

Mac OS X 10.4.7 und höhere Versionen von Mac OS X 10.4 führen 64-Bit-Befehlszeilentools mithilfe der POSIX- und Mathematikbibliotheken auf 64-Bit-Intel-basierten Rechnern aus, analog zu allen Versionen von Mac OS X 10.4 und 10.5 auf 64-Bit-PowerPC-Rechnern. Andere Bibliotheken oder Frameworks sind mit 64-Bit-Anwendungen unter Mac OS X 10.4 nicht kompatibel. ^{[ 108 ]} Der Kernel und alle Kernel-Erweiterungen sind ausschließlich 32-Bit-kompatibel.

Mac OS X 10.5 unterstützt 64-Bit-GUI-Anwendungen mit Cocoa , Quartz , OpenGL und X11 auf 64-Bit-Intel-basierten Rechnern sowie auf 64-Bit -PowerPC- Rechnern. ^{[ 109 ]} Alle Nicht-GUI-Bibliotheken und -Frameworks unterstützen ebenfalls 64-Bit-Anwendungen auf diesen Plattformen. Der Kernel und alle Kernel-Erweiterungen sind ausschließlich 32-Bit-Anwendungen.

Mac OS X 10.6 ist die erste macOS- Version mit 64-Bit -Kernel -Unterstützung . Allerdings können nicht alle 64-Bit-Computer den 64-Bit-Kernel ausführen, und nicht alle 64-Bit-Computer, die ihn ausführen können, tun dies standardmäßig. ^{[ 110 ]} Der 64-Bit-Kernel unterstützt, wie der 32-Bit-Kernel, 32-Bit-Anwendungen; beide Kernel unterstützen auch 64-Bit-Anwendungen. 32-Bit-Anwendungen haben unter beiden Kerneln eine Beschränkung des virtuellen Adressraums auf 4 GiB. ^{[ 111 ] [ 112 ]} Der 64-Bit-Kernel unterstützt keine 32-Bit -Kernel-Erweiterungen , und der 32-Bit-Kernel unterstützt keine 64-Bit-Kernel-Erweiterungen.

OS X 10.8 enthält nur den 64-Bit-Kernel, unterstützt aber weiterhin 32-Bit-Anwendungen; 32-Bit-Kernel-Erweiterungen werden jedoch nicht unterstützt.

macOS 10.15 enthält ausschließlich den 64-Bit-Kernel und unterstützt keine 32-Bit-Anwendungen mehr. Diese fehlende Unterstützung stellte ein Problem für Wine (und die kommerzielle Version CrossOver ) dar, da es weiterhin 32-Bit-Windows-Anwendungen ausführen können muss. Die Lösung, wine32on64 genannt, bestand darin, Thunks hinzuzufügen , die die CPU in der nominell 64-Bit-Anwendung in den 32-Bit-Kompatibilitätsmodus versetzen und wieder herausnehmen. ^{[ 113 ] [ 114 ]}

macOS verwendet das universelle Binärformat (UBF), um 32-Bit- und 64-Bit-Versionen von Anwendungs- und Bibliothekscode in einer einzigen Datei zu bündeln; die jeweils passende Version wird beim Start automatisch ausgewählt. In Mac OS X 10.6 wird das UBF auch für den Kernel und für Kernel-Erweiterungen verwendet, die sowohl 32-Bit- als auch 64-Bit-Kernel unterstützen.

Solaris 10 und spätere Versionen unterstützen die x86-64-Architektur.

Für Solaris 10 gibt es, genau wie bei der SPARC -Architektur, nur ein einziges Betriebssystem-Image, das einen 32-Bit- und einen 64-Bit-Kernel enthält; dieses ist als „x64/x86“-DVD-ROM-Image gekennzeichnet. Standardmäßig wird ein 64-Bit-Kernel gestartet, sodass sowohl 64-Bit- als auch vorhandene oder neue 32-Bit-Programme ausgeführt werden können. Alternativ kann manuell ein 32-Bit-Kernel ausgewählt werden; in diesem Fall werden nur 32-Bit-Programme ausgeführt. Mit dem isainfoBefehl lässt sich feststellen, ob ein System mit einem 64-Bit-Kernel läuft.

Für Solaris 11 wird ausschließlich der 64-Bit-Kernel bereitgestellt. Dieser unterstützt jedoch sowohl 32-Bit- als auch 64-Bit-Programme, Bibliotheken und Systemaufrufe.

Die x64-Editionen von Microsoft Windows Client und Server – Windows XP Professional x64 Edition und Windows Server 2003 x64 Edition – wurden im März 2005 veröffentlicht. ^{[ 115 ]} Intern handelt es sich um dieselbe Build-Version (5.2.3790.1830 SP1). ^{[ 116 ] [ 117 ]} Da sie dieselbe Quellcodebasis und dieselben Betriebssystem-Binärdateien verwenden, werden selbst Systemupdates in einheitlichen Paketen veröffentlicht, ähnlich wie bei den x86-Editionen von Windows 2000 Professional und Server. Windows Vista , das ebenfalls in vielen verschiedenen Editionen erhältlich ist, wurde im Januar 2007 veröffentlicht. Windows 7 erschien im Juli 2009. Windows Server 2008 R2 wurde nur in einer x64- und einer Itanium-Edition angeboten; spätere Versionen von Windows Server sind nur noch als x64-Edition erhältlich.

Windows-Versionen für x64 vor Windows 8.1 und Windows Server 2012 R2 bieten Folgendes:

• Pro Prozess stehen 8 TiB virtueller Adressraum zur Verfügung, der sowohl im Benutzermodus als auch im Kernelmodus zugänglich ist und als Benutzermodus-Adressraum bezeichnet wird. Ein x86-64-Programm kann diesen gesamten Adressraum nutzen, sofern die Speicherkapazität des Systems begrenzt ist und die Option „large address aware“ aktiviert ist (standardmäßig vorhanden). ^{[ 118 ]} Dies entspricht einer 4096-fachen Steigerung gegenüber dem standardmäßigen virtuellen Benutzermodus-Adressraum von 2 GiB, der von 32-Bit-Windows bereitgestellt wird. ^{[ 119 ] [ 120 ]}
• 8 TiB virtueller Adressraum im Kernelmodus für das Betriebssystem. ^{[ 119 ]} Wie beim Adressraum im Benutzermodus entspricht dies einer 4096-fachen Steigerung gegenüber 32-Bit-Windows-Versionen. Der erweiterte Speicherplatz kommt primär dem Dateisystemcache und den Kernelmodus-„Heaps“ (nicht auslagerbarer und auslagerbarer Speicherbereich) zugute. Windows nutzt insgesamt nur 16 TiB der von den Prozessoren implementierten 256 TiB, da frühen AMD64-Prozessoren ein CMPXCHG16Bentsprechender Befehl fehlte. ^{[ 121 ]}

Unter Windows 8.1 und Windows Server 2012 R2 wurden sowohl der virtuelle Adressraum im Benutzermodus als auch im Kernelmodus auf 128 TiB erweitert. ^{[ 24 ]} Diese Windows-Versionen lassen sich nicht auf Prozessoren installieren, denen die CMPXCHG16Bentsprechende Anweisung fehlt.

Folgende zusätzliche Merkmale gelten für alle x64-Versionen von Windows:

• .exeDie Möglichkeit, bestehende 32-Bit-Anwendungen ( Programme) und dynamische Linkbibliotheken ( .dllDLLs) unter WoW64 auszuführen, sofern WoW64 von der jeweiligen Version unterstützt wird. Darüber hinaus kann ein 32-Bit-Programm, das mit der Option „large address aware“ ^{[ 118 ]} verknüpft wurde, in 64-Bit-Windows bis zu 4 GiB virtuellen Adressraum nutzen, anstatt der standardmäßigen 2 GiB (optional 3 GiB mit /3GBBoot-Option und Link-Option „large address aware“), die 32-Bit-Windows bietet. ^{[ 122 ]} Im Gegensatz zur Verwendung der /3GBBoot-Option unter x86 reduziert dies nicht den dem Betriebssystem zur Verfügung stehenden virtuellen Adressraum im Kernelmodus. 32-Bit-Anwendungen können daher von der Ausführung unter x64-Windows profitieren, selbst wenn sie nicht für x86-64 neu kompiliert wurden.
• Sowohl 32-Bit- als auch 64-Bit-Anwendungen sind, sofern sie nicht mit „large address aware“ verknüpft sind, auf 2 GiB virtuellen Adressraum beschränkt.
• Die Möglichkeit, bis zu 128 GiB (Windows XP/Vista), 192 GiB (Windows 7), 512 GiB (Windows 8), 1 TiB (Windows Server 2003), 2 TiB (Windows Server 2008/Windows 10), 4 TiB (Windows Server 2012) oder 24 TiB (Windows Server 2016/2019) physischen Arbeitsspeicher (RAM) zu nutzen. ^{[ 123 ]}
• LLP64- Datenmodell: In C/C++ sind die Datentypen "int" und "long" 32 Bit breit, "long long" ist 64 Bit breit, während Zeiger und von Zeigern abgeleitete Datentypen 64 Bit breit sind.
• Kernelmodus-Gerätetreiber müssen 64-Bit-Versionen sein; 32-Bit-Kernelmodus-Programme können nicht unter einem 64-Bit-Betriebssystem ausgeführt werden. Benutzermodus-Gerätetreiber können entweder 32-Bit oder 64-Bit sein.
• 16-Bit-Windows- (Win16) und DOS-Anwendungen laufen nicht auf x86-64-Versionen von Windows, da das virtuelle DOS-Maschinensubsystem (NTVDM) entfernt wurde, welches die Nutzung des virtuellen 8086-Modus erforderte. Der virtuelle 8086-Modus kann im Langmodus nicht aktiviert werden.
• Die NX- Seitenschutzfunktion (No Execute) ist vollständig implementiert. Sie ist auch in neueren 32-Bit-Versionen von Windows implementiert, wenn diese im PAE-Modus gestartet werden.
• Anstelle des FS-Segmentdeskriptors in x86-Versionen der Windows-NT- Familie wird der GS-Segmentdeskriptor verwendet, um auf zwei vom Betriebssystem definierte Strukturen zu verweisen: den Thread-Informationsblock (NT_TIB) im Benutzermodus und die Prozessorsteuerungsregion (KPCR) im Kernelmodus. So GS:0ist beispielsweise im Benutzermodus die Adresse des ersten Elements des Thread-Informationsblocks. Die Beibehaltung dieser Konvention vereinfachte die Portierung auf x86-64, erforderte jedoch von AMD, die Funktion der FS- und GS-Segmente im Langmodus beizubehalten – obwohl segmentierte Adressierung an sich von keinem modernen Betriebssystem mehr verwendet wird. ^{[ 119 ]}
• Frühe Berichte behaupteten, der Betriebssystem-Scheduler würde den x87 -FPU-Maschinenzustand bei Thread-Kontextwechseln nicht speichern und wiederherstellen. Beobachtungen zeigen jedoch, dass dies nicht der Fall ist: Der x87-Zustand wird gespeichert und wiederhergestellt, außer bei Threads, die ausschließlich im Kernelmodus ausgeführt werden (eine Einschränkung, die auch in der 32-Bit-Version besteht). Die aktuellste Dokumentation von Microsoft besagt, dass die x87/ MMX / 3DNow! -Befehle zwar im Langmodus verwendet werden können, aber als veraltet gelten und zukünftig Kompatibilitätsprobleme verursachen können. ^{[ 122 ]} (3DNow! ist auf AMD-Prozessoren nicht mehr verfügbar, mit Ausnahme der PREFETCHBefehle PREFETCHW[ 124 ], ^{die ab Broadwell} auch auf Intel-Prozessoren unterstützt werden . )
• Einige Komponenten wie die Jet-Datenbank-Engine und Datenzugriffsobjekte werden nicht auf 64-Bit-Architekturen wie x86-64 und IA-64 portiert. ^{[ 125 ] [ 126 ] [ 127 ]}
• Microsoft Visual Studio kann native Anwendungen entweder für die x86-64-Architektur kompilieren, die nur unter 64-Bit-Microsoft Windows ausgeführt werden kann, oder für die IA-32- Architektur, die als 32-Bit-Anwendung unter 32-Bit-Microsoft Windows oder im WoW64- Emulationsmodus unter 64-Bit-Microsoft Windows ausgeführt werden kann . Verwaltete Anwendungen können im IA-32-, x86-64- oder AnyCPU-Modus kompiliert werden. Software, die in den ersten beiden Modi erstellt wurde, verhält sich wie ihr jeweiliger nativer IA-32- bzw. x86-64-Code. Im AnyCPU-Modus hingegen laufen Anwendungen unter 32-Bit-Versionen von Microsoft Windows als 32-Bit-Anwendungen, während sie unter 64-Bit-Versionen von Microsoft Windows als 64-Bit-Anwendungen ausgeführt werden.

PlayStation 4 und Xbox One verwenden angepasste AMD- Prozessoren (APUs) auf Basis der Jaguar- Mikroarchitektur . ^{[ 128 ] [ 129 ]} Ebenso verwenden PlayStation 5 , Steam Deck und Xbox Series X/S angepasste AMD-Prozessoren auf Basis der Zen-2- Mikroarchitektur. ^{[ 130 ] [ 131 ] [ 132 ]} Firmware und Spiele sind in x86-64-Code geschrieben; es wird kein älterer 32-Bit-x86-Code verwendet.

Da AMD64 und Intel 64 weitgehend identisch sind, verwenden viele Software- und Hardwareprodukte eine herstellerneutrale Bezeichnung, um ihre Kompatibilität mit beiden Implementierungen zu kennzeichnen. AMDs ursprüngliche Bezeichnung für diese Prozessorarchitektur, „x86-64“, wird weiterhin zu diesem Zweck verwendet ^{[ 2 ]} , ebenso wie die Variante „x86_64“ ^{[ 3 ] [ 4 ]} . Andere Unternehmen, wie beispielsweise Microsoft ^{[ 6 ]} und Sun Microsystems / Oracle Corporation ^{[ 5 ]} , verwenden in ihren Marketingmaterialien die Abkürzung „x64“.

Der Begriff IA-64 bezieht sich auf den Itanium- Prozessor und sollte nicht mit x86-64 verwechselt werden, da es sich um einen völlig anderen Befehlssatz handelt.

Viele Betriebssysteme und Produkte, insbesondere solche, die x86-64-Unterstützung vor Intels Markteintritt eingeführt haben, verwenden den Begriff „AMD64“ oder „amd64“, um sowohl AMD64 als auch Intel 64 zu bezeichnen.

• amd64
  • Die meisten BSD- Systeme wie FreeBSD , MidnightBSD , NetBSD und OpenBSD bezeichnen sowohl AMD64 als auch Intel 64 unter der Architekturbezeichnung „amd64“.
  • Einige Linux-Distributionen wie Debian , Ubuntu und Gentoo bezeichnen sowohl AMD64 als auch Intel 64 unter der Architekturbezeichnung „amd64“.
  • Die x64-Versionen von Microsoft Windows verwenden intern die Bezeichnung AMD64, um verschiedene Komponenten zu kennzeichnen, die diese Architektur nutzen oder mit ihr kompatibel sind. Beispielsweise ist der Umgebungsvariablen PROCESSOR_ARCHITECTURE der Wert „AMD64“ zugewiesen, im Gegensatz zu „x86“ in 32-Bit-Versionen, und das Systemverzeichnis auf einer Installations-CD-ROM der Windows x64 Edition trägt den Namen „AMD64“, im Gegensatz zu „i386“ in 32-Bit-Versionen. ^{[ 133 ]}
  • Der Solaris- Befehl isalist von Sun identifiziert sowohl AMD64- als auch Intel64-basierte Systeme als „amd64“.
  • Java Development Kit (JDK): Der Name "amd64" wird in Verzeichnisnamen verwendet, die x86-64-Dateien enthalten.
• x86_64
  • Der Linux-Kernel ^{[ 134 ]} und die GNU Compiler Collection bezeichnen die 64-Bit-Architektur als „x86_64“.
  • Einige Linux-Distributionen, wie Fedora , openSUSE , Arch und Gentoo, bezeichnen diese 64-Bit-Architektur als „x86_64“.
  • Apple macOS bezeichnet die 64-Bit-Architektur als „x86-64“ oder „x86_64“, wie im Terminal-Befehl arch^{[ 3 ]} und in der Entwicklerdokumentation zu sehen ist. ^{[ 2 ] [ 4 ]}
  • Im Gegensatz zu den meisten anderen BSD-Systemen bezeichnet DragonFly BSD die 64-Bit-Architektur als „x86_64“.
  • Haiku bezeichnet die 64-Bit-Architektur als „x86_64“.

x86-64/AMD64 wurde ausschließlich von AMD entwickelt. Bis zum Auslaufen der entsprechenden Patente im April 2021 besaß AMD Patente auf die in AMD64 verwendeten Techniken; ^{[ 135 ] [ 136 ] [ 137 ]} diese Patente mussten von AMD lizenziert werden, um AMD64 implementieren zu können. Intel schloss mit AMD ein Cross-Lizenzabkommen ab, in dem Intel AMD seine Patente auf bestehende x86-Techniken und im Gegenzug AMDs Patente auf in x86-64 verwendete Techniken lizenzierte. ^{[ 138 ]} Im Jahr 2009 einigten sich AMD und Intel in mehreren Rechtsstreitigkeiten und Streitigkeiten über Cross-Lizenzen und verlängerten ihre Cross-Lizenzabkommen. ^{[ 139 ] [ 140 ] [ 141 ]}

• AGESA (AMD Generic Encapsulated Software Architecture)
• Sicherheitslücke bei der Ausführung vorübergehender CPU-Ausführung

• AMD-Entwicklerhandbücher, Anleitungen und ISA-Dokumente
• x86-64: Erweiterung der x86-Architektur auf 64 Bit – technischer Vortrag des Architekten von AMD64 ( Videoarchiv ) und zweiter Vortrag desselben Referenten ( Videoarchiv )
• AMDs „Verbesserter Virenschutz“
• Intel optimiert EM64T für volle AMD64-Kompatibilität
• Analyst: Intel hat AMD64 per Reverse Engineering analysiert
• Erster Bericht über Unterschiede zwischen Intel IA32e und AMD64
• Portierung auf 64-Bit-GNU/Linux-Systeme , von Andreas Jaeger vom GCC Summit 2003. Ein hervorragendes Paper, das nahezu alle praktischen Aspekte des Übergangs von 32-Bit zu 64-Bit erläutert.
• Intel 64-Architektur
• Intel Software Network: "64 Bit"
• Anleitungen auf TurboIRC.COM, einschließlich Beispielen, wie man über DOS auf die direkte Art und Weise in den geschützten und den Langmodus wechselt.
• Sieben Schritte zur Migration eines Programms auf ein 64-Bit-System
• Speichergrenzen für Windows-Versionen