Im Legacy-Modus, in dem sich der Prozessor auch nach einem Reset befindet, verhält sich die CPU wie ein Athlon oder P4, der zusätzlich über SSE2 verfügt. Verfügbar sind der RealMode und der ProtectedMode mit 16 Bit, 32 Bit und V86, auch alle Instruktionen und Register entsprechen denen der entsprechenden x86-CPU. Auch die Geschwindigkeit ist vergleichbar.
Erst im neuen Long-Mode kann der Hammer richtig zuschlagen. Nur hier ist x86-64-Code ausführbar, nur hier kann der volle Adressbereich angesprochen werden. Zur Kompatibilität sind 16- und 32-Bit ProtectedMode-Codesegmente weiterhin verfügbar, so daß ältere 16- und 32-bit Software weiterhin ungehindert weiterverwendet werden kann. Den V86-Modus gibt es hier allerdings nicht mehr, für DOS-Boxen müßte also eine aufwändigere Emulation, evtl. auf 16-Bit-ProtectedMode-Segmenten basierend, verwendet werden. Herkömmlicher 16- und 32-Bit-Code kann zwar im gesamten physikalischen Addreßbereich gespeichert werden, 64-Bit-Addressen und -Operanden sowie die zusätzlichen Register und Addressmodi bleiben jedoch reinen x86-64-Segmenten vorbehalten.
Um Probleme mit anderen x86-CPUs aus dem Weg zu gehen, hat AMD das Bit zur Aktivierung der Long Modes in ein MSR (Machine Specific Register) gesteckt. Um den Long-Mode wirklich zu aktivieren, muß allerdings auch die Abbildung linearer zu physikalischen Addressen per Paging verwendet werden. Dies liegt darin begründet, daß der Long-Mode sämtlichen Speicherschutz (ebenso wie alle aktuelle Betriebsysteme) allein über das Paging realisiert. Da stellt sich die Frage: Was machen denn nun die...
Der Speicherschutz über Deskriptoren und Segmentregister ist wie gewohnt in x86-16- und 32-Bit Segmenten verfügbar, aber nicht im x86-64-Code. Da x86-64 nur ein flaches Speichermodell unterstützt, werden DS, ES und SS vollständig ignoriert, bei FS und GS werden nur die entsprechenden Basisaddressen berücksichtigt, so daß diese beiden als zusätzliches Basisregister dienen (Grund: Win32 u.a. verwenden sie, dadurch soll wohl die Portierung nach x86-64 beschleunigt werden). Bei CS werden zuerst die Zugriffsrechte überprüft, sowie 2 Bits, die angeben, ob es sich um 16,32 oder x86-64-Code handelt. Bei 16- und 32-Bit-Code wird die komplette Segmentierung wie bisher üblich aktiviert, bei x86-64-Code dagegen ignoriert. Das Deskriptor-Bit für die Operandengröße ist im x86-64-Modus bis jetzt auf "0" gesetzt, der Wert "1" wird als reserviert bezeichnet. Ob da ein echter 64-Bit-Addressen UND -Operanden-Modus geplant ist?
Die linearen Addressen (bei x86-64-Code identisch mit den logischen Addressen, bei 16- und 32-bit-Code zuerst per Deskriptoren umgesetzt) werden per 4KB oder 2MB-Seitentabellen umgesetzt, ähnlich wie seit dem PPro. Der derzeit implementierte physikalische Addreßbereich beträgt 40bit signed, der derzeit implementierte virtuelle Addreßbereich 48bit signed. Maximal möglich sind 52bit physikalischer und virtueller Addreßbereich, die auch im normalen x86-Modus verfügbar sind. Zum Vergleich: Üblich ab dem PPro sind 36bit physikalisch und virtuell, also nur ein 65536-tel davon.
Damit spätere x86-64 - Prozessoren den Addreßbereich ohne Kompatibilitätsprobleme erweitern können testet die CPU immer, ob derzeit noch unbenutzte Addressbits mit dem vorzeichenbehaftet erweitert sind. Falls dies nicht der Fall ist, haut der Hammer dem fehlerhaft implementierten Programm erstmal per Exception kräftig eines auf die Rübe. Das Betriebsystem kann es dann entweder rausschmeißen oder die Addresse korrigieren.
Ein paar kleine Neuigkeiten bei den Interrupts gibt es im Long-Mode auch noch:
Als Hauptvorteile von x86-64 ergeben sich:
Ob sich mit x86-64 ein neuer Standard festnageln kann oder ob die neue CPU ein Schlag ins Wasser wird, hängt letztendlich von der Unterstützung der CPU ab. Bis 64-Bit-Programme und -Betriebssysteme 32-Bit-Code weitgehend ersetzt haben wird es noch eine Weile dauern.
Im Gegensatz zu Intels IA-64 (IntelArchitecture 64bit) kommt AMDs Vorschlag(-hammer) mit bestehender Software genausogut zurecht wie mit neu zu schreibender, bestehende Betriebsysteme und Compiler können dank der weitgehenden Identität mit x86-Code in kurzer Zeit nach x86-64 portiert werden und profitieren zudem von in 15 Jahren angesammeltem x86-Know-How.
IA-64 dagegen hat mit seinem völlig neuem Ansatz (explizit parallele Verarbeitung, gleichförmiges Format der Instruktionen) sein Potential in der Praxis erst noch zu beweisen. Für höhere Taktfrequenzen dürfte IA-64 eventuell besser geeignet sein, letztendlich kann dies aber nur die Zukunft zeigen (falls überhaupt beide Ansätze solange überleben, der Markt wird kaum beide unterstützen). Es kann durchaus sein, daß auch langfristig genug Potential in x86-64 steckt, um IA-64 umzunageln.
Derzeit interressant ist auf jedem Fall schon mal SSE2, da damit endlich ein einheitlicher Befehlssatz zur schnellen Berechnung großer Datenmassen existiert. Auch der größere physikalische Addreßbereich dürfte schnell von den Betriebsystemen unterstützt werden.
Für den Long-Mode, der x86-64-Code ermöglicht, werden zuerstmal passende Betriebssysteme benötigt, was noch etwas dauern dürfte. Dann allerdings kann man sich schon mal auf die zusätzlichen Register freuen, daß diese auch 64 Bit groß sind ist eher nebensächlich. Schon in 32-Bit-Code werden die Bits eher selten vollständig verwendent, zumal deren Verwendung für parallele Verarbeitung von Daten durch MMX und SSE besser durchgeklopft wird.
Für heute ist jedenfalls Schluß mit blöden Wortspielen, oder glaubt etwa jemand ernsthaft, ich hätte den ganzen Text nur in die Tasten gehämmert, um etwas über ein Stück Silizium zu schreiben, daß noch von keinem Händler verklopft (upps, ich hab´s schon wieder getan ;-) wird? *g*