64-Bit CPUs für's Wohnzimmer : Innovation oder Marketinggeblubber?

mj

Technische Administration, Dinosaurier, ,
Mitglied seit
17.10.2000
Beiträge
19.529
Renomée
272
Standort
Austin, TX
titel.jpg

Vorwort​

So langsam wird es Zeit, jeden zweiten Tag gibt es neue Meldungen über die Nachfolger der 32 Bit CPU und mit jeder weiteren Meldung scheint es, als würden die Heimanwender bereits seit Jahren auf 64 Bit CPUs warten, als wäre die 64 Bit CPU die Erlösung nach der alle Anwender sich sehnen.

Was die 64 Bit Architektur für den Heimanwender jedoch tatsächlich an Vorteilen bringt, oder gar wo die tatsächlichen theoretischen und praktischen Unterschiede zwischen einem 32 Bit System und einem 64 Bit System liegen wissen die wenigsten. Ziel dieses Artikels ist es dem Leser die Unterschiede aufzuzeigen und somit die aufkommende Euphorie ein wenig in vernünftige Bahnen zu lenken. Um dies zu erreichen ist jedoch ein historischer Exkurs in die Urtage der Mikroprozessortechnik notwendig, bis hin zur von-Neumann-Architektur.
[BREAK=Kurze Erläuterung der von-Neumann-Architektur]
Alle heutigen, gestrigen und auch zukünftigen Rechner basieren auf einem bestimmten Architekturmodell, nämlich dem von von-Neumann. Von-Neumann hat, zeitgleich und unabhängig von Konrad Zuse, in den 50er Jahren ein Modell entwickelt, welches die Architektur eines elektronischen Rechners beschreibt. Ein von-Neumann-Rechner weist bestimmte Merkmale auf, die im folgenden kurz erläutert werden.

<div class="newsfloatleft">
von-neumann.jpg
</div>Er besteht aus drei Funktionseinheiten: Der Zentraleinheit (Central Processing Unit, CPU,), dem Speicher (RAM/ROM) sowie dem Ein-Ausgabewerk (I/O). Die Verbindung zwischen den einzelnen Einheiten erfolgt über sog. Busse, oder auch Verbindungseinrichtungen. Die Zentraleinheit selber ist wiederum unterteilt in das Rechenwerk sowie das Steuerwerk.

Wesentliches Merkmal eines von-Neumann-Rechners ist seine universelle Verwendbarkeit. Der Rechner ist nicht auf ein spezielles Problem zugeschnitten, sondern universell einsetzbar, also programmierbar. Von daher kommt die Bezeichnung des „programmgesteuerten Universalrechners“.


Die entsprechenden Programme werden ebenso wie die zu verwendenden Daten im universellen Hauptspeicher des Rechners abgelegt. Er ist in Bereiche bestimmter Länge aufgeteilt (Intels x86-Architektur verwendet 8 Bit lange Speicherzellen), und aufsteigend nummeriert adressierbar.
Für das weitere Verständnis ist ebenfalls eine Betrachtung der Rechenweise eines von-Neumann-Rechners notwendig. Die Ausführung eines Maschinenbefehls erfolgt in zwei Phasen:

Interpretations – Phase:
Im Steuerwerk befindet sich ein Register bestimmter Länge, der sogenannte Befehlszähler (Kurz BZ, engl. Program Counter, PC). Der Wert dieses BZ zeigt auf eine Hauptspeicheradresse, die den nun folgenden auszuführenden Befehl beinhaltet. Dieser Befehl kann codiert sein und muss in diesem Falle vor der Ausführung zunächst decodiert werden. Man spricht in diesem Falle vom Befehlsformat: Ein horizontales Befehlsformat ist nicht codiert, ein vertikales Befehlsformat ist codiert. Der Mittelweg ist das sogenannte quasi-horizontale Befehlsformat. In der Interpretations-Phase wird der Inhalt der an der im BZ stehenden Adresse der Speicherzelle in das Instruktionsregister geladen. Der Befehl ist somit bereit zur Ausführung, es folgt die

Ausführungs – Phase:
Hier wird der eventuell notwendige zweite Operand (nicht jede Operation benötigt zwei Operanden, so benötigt die Negation nur einen Operanden) aus dem Hauptspeicher geladen. Es erfolgt die eigentliche Ausführung des Befehls, beispielsweise die Addition eines Operanden auf den Inhalt eines Registers, die Multiplikation eines Operanden mit dem Inhalt eines Registers oder weiteres.
Da der Programmablauf eines von-Neumann-Rechners streng sequentiell ist genügt es, den BZ nachdem der aktuelle Befehl geladen ist um Eins zu erhöhen, so dass er auf den nächsten zu ladenden Befehl im Hauptspeicher zeigt. Wird ein direkter Operand im Hauptspeicher verwendet genügt jedoch eine einfache Erhöhung nicht mehr. Im einfachsten Falle folgt der Operand im Hauptspeicher direkt auf den Befehl. Um den nächsten Befehl zu adressieren ist dann also eine Erhöhung um zwei notwendig.

So simpel dieses Prinzip auch klingt, so entscheidend war es für die folgende Entwicklung der Mikroprozessortechnik weltweit. Alle programmierbaren Rechner basieren auf exakt dieser von-Neumann-Architektur. Sie wird nur vom Hersteller des Mikroprozessors entsprechend erweitert, so dass das Produkt entsprechend schneller arbeitet.
[BREAK=Der 8086, die heutige Basis]
Auf exakt dieser Basis hat Intel seine Mikroprozessoren entwickelt, nur um einige Bereiche erweitert. Der 8086, das Urgestein der x86 - Architektur besitzt trotz seines Alters von 20 Jahren bis heute noch eine enorme Bedeutung für die EDV-Welt. Alle Nachfolgenden Prozessoren von Intel, AMD, Cyrix oder WinChip sind 100%ig kompatibel zum Befehlsformat des 8086 - Mikroprozessors.
Das bedeutet im Klartext, dass auf einer modernen CPU auch noch 20 Jahre alte Programme ausführbar sind. Diese zwingend notwendige Kompatibilität ist es, welche die Entwicklung der Prozessoren entscheidend beeinflusst hat.
Der Intel 8086 war für damalige Zeit ein erstaunlicher Mikroprozessor. Er arbeitet intern mit 16 Bit langen Registern und Datenpfaden, konnte jedoch dank eines Tricks stolze 1 MB Speicher adressieren (20 Bit Speichergate, A20). Der Prozessor verfügte über 14 Register, Acht Universalregister (GPR, General Purpose Register) sowie sechs spezialisierte.

Erklärung Register
<div class="newsfloatleft">
x86-register.jpg
</div>Register sind prozessorinterne Zwischenspeicher. Diese Zwischenspeicher besitzen Kapazitäten von bis zu 16 Bit im Falle eines 16 Bit Mikroprozessors, bis zu 32 Bit im Falle eines 32 Bit Mikroprozessors sowie bis zu 64 Bit im Falle eines 64 Bit Mikroprozessors. Auf diesen Zwischenregistern werden die Operationen eines Mikroprozessors durchgeführt, wie Addition oder Multiplikation. Aber auch logische Operationen wie logisches AND, XOR oder Schiebeoperationen werden auf diesen Registern durchgeführt.

Ein Mikroprozessor kann Operationen auf Länge der Register durchführen, das bedeutet dass ein 32 Bit Mikroprozessor Operationen mit 32 Bit Zahlen durchführen kann. Jeder Operand bei mathematischen Operationen liegt also im Bereich von 0 bis 4294967296 (=232). Operationen mit Operanden größer als 4294967296, müssen sequentiell ausgeführt werden. Hierfür folgt eine Aufspaltung des Operanden vom niederwertigsten Bit aus in jeweils 32 Bit Teilen (Im Falle eines 16 Bit Mikroprozessors logischerweise in 16 Bit Teilen).

Weitere Informationen sowie Beispielrechnungen zum besseren Verständnis finden interessierte Leser im Zusatzartikel "64 Bit Addition". Auch ein 32 Bit Mikroprozessor kann also auf Zahlen größer als 4294967296 rechnen, benötigt hierfür jedoch entsprechend mehr Taktzyklen als ein 64 Bit Mikroprozessor.​
[BREAK=Der 8086 - die heutige Basis (Fortsetzung)]
Die vier Register AX, BX, CX sowie DX können für universelle Operationen verwendet werden. Eine Spezialaufgabe hat jedoch in Einzelfällen das AX - Register, welches als Akkumulator des von-Neumann-Rechners fungiert. Beispielsweise wird der Befehl

MUL CX
Folgendermaßen interpretiert:

MUL CX = CX * AX
Die vier folgenden Register dienen als Zeigerregister, weiterhin existiert noch ein Instruction Pointer (Befehlszäher) sowie vier Segmentregister.


Auf diese Register kann der Programmierer einer 8086 – Maschine zugreifen. Als Folge dessen müssen also alle Nachfolger dieses Mikroprozessors eben diese Register auch besitzen und deren Verwendung identisch handhaben.
So verlief auch die Entwicklung bis heute. Jeder Prozessor ist kompatibel zum 8086 und trägt diese Kompatibilität bereits im Namen: 8086, 80286, 80386, etc.

Der Schritt von 16 auf 32 Bit
Mit dem 80386 führte Intel im Jahre 1985 eine wesentliche Neuerung und Änderung der 8086 – Architektur ein: Die Register wuchsen an auf 32 Bit Datenlänge, ebenso wie die Datenpfade und die Hauptspeicher – Adresslänge. Die Vorteile dieser Architektur waren auf den Ersten Blick niemanden klar, dennoch hat sich die IA-32 – Architektur letztendlich durchgesetzt, und ist bis heute Grundlage jedes modernen Prozessors.
So wäre beispielsweise, wie wir heute wissen, der Adressraum des 80286, den Intel über den Protected Mode auf damals gigantische 16 MB anheben konnte relativ bald zu klein gewesen, so kam die Erweiterung von 16 MB auf 4 GB Adressraum grade Recht.
[BREAK=Der Schritt von 16 auf 32 Bit]
Speicheradressierung:
Der Adressraum berechnet sich aus der Registerlänge. Die Intel – Architektur adressiert den Speicher in jeweils 8 Bit großen Blöcken, also Byteweise. Bei 16 Bit breiten Registern ist der maximale adressierbare Speicher

2^16 Byte = 65536 Byte = 64 KB​

Beim 8086 konnte Intel dank einem Trick den Speicher mit 20 Bit adressieren:

2^20 Byte = 1048576 Byte = 1024 KB = 1 MB​

Beim 80286 ermöglichte ein weitere Trick die Adressierung mit 24 Bit Wortlänge:

2^24 = 16777216 Byte = 16384 KB = 16 MB

Die Erweiterung auf 32 Bit brachte nun einen gewaltigen Schritt:

2^32 = 4294967296 Byte = 4194304 KB= 4096 MB = 4 GB

Mit einem 32 Bit Prozessor können also 4 GB an Speicher adressiert werden. Wie heutige Speichergrößen von 256 MB zeigen sind wir in der Praxis noch weit von jenem Maximalwert entfernt.

Als der 80386 das Licht der Welt erblickte, konnte sich niemand vorstellen warum jemals ein Speicher von mehr als 16 MB adressiert werden muss. Die Firmen und Anwender waren mit der Performance des 80286 und dessen Maximalem Speicherbereich von 16 MB vollends zufrieden.
Was dem 80386 jedoch letztendlich zum Durchbruch verhalf und ihn als neuen Industriestandard etablierte war die Tatsache, dass er zu bisherigem 16 Bit Code vollständig kompatibel war, und bei dessen Ausführung einen enormen Geschwindigkeitsvorteil bieten konnte. In seinen Anfangstagen war der Mikroprozessor also weitestgehend damit beschäftigt, Operationen auf AX-DX, etc. durchzuführen, und EAX-EDX, etc. links liegen zu lassen.
Er führte 16 Bit Code aus, ermöglichte den Programmierern jedoch die Erweiterung ihrer Programme auf 32 Bit.
So war ein schleichender Architekturwechsel möglich, dessen Endprodukt bis heute noch den Stand der Technik bildet. Ein AMD Athlon XP ist 100%ig kompatibel zur IA-32 – Architektur, welche wiederum 100%ig kompatibel ist zur 8086 – Architektur.
[BREAK=Heutige Prozessoren und ihre Eckdaten]
Um nun zu verstehen inwiefern, oder besser gesagt ob der Heimanwender einen 64 Bit Mikroprozessor benötigt, ist es notwendig, die Eckdaten der aktuellen Mikroprozessoren zu untersuchen. Da es derzeit zwei konkurrierende Mikroprozessoren im Heimanwenderbereich gibt, den AMD Athlon XP sowie den Intel Pentium 4, und diese trotz der 100%iger x86 – Kompatibilität dennoch einige signifikante Unterschiede aufweisen, ist eine Differenzierung notwendig.

Generelle Eckdaten heutiger 32 Bit Prozessoren​

Die modernen 32 Bit Mikroprozessoren gehören zur Familie der Mikroprozessoren mit superskalarer Arbeitsweise. Intel hat dieses Prinzip mit dem Pentium eingeführt: Erstmals in der Geschichte der x86 – Prozessoren war es dem Mikroprozessor möglich, mehrere Befehle innerhalb eines Taktsignals auszuführen. Der Intel Pentium, oder kurz gesagt die P5 – Architektur kann im Gegensatz zu ihrer Vorgängerarchitektur (80486) zwei Befehle parallel ausführen, solange die zweite Operation nicht vom Ergebnis der ersten Operation abhängig ist. So kann beispielsweise

A = 10 + 10
B = A + 40

nicht parallel ausgeführt werden, da die zweite Operation das Ergebnis der ersten Operation als Operanden benötigt. Hier lag also zum ersten mal die Bürde der Optimierung beim Programmierer oder Compiler.

Mit der P6 – Architektur wurde die superskalare Arbeitsweise erweitert, auf insgesamt drei parallel ausführbare Befehle. Der Decoder konnte innerhalb eines Taktzyklus drei Befehle parallel decodieren und an die entsprechenden Befehlseinheiten weiterleiten. Bis zu diesem Punkt arbeiten Intel und AMD – Mikroprozessoren identisch, beim Pentium 4 und Athlon XP gibt es beim Decoder jedoch einen gravierenden Unterschied, weshalb hierauf später im Einzelnen eingegangen wird.

<div class="newsfloatleft">
386_register_b.gif
</div>Um volle Kompatibilität zu den Vorgängergenerationen zu wahren, haben alle modernen Mikroprozessoren die ursprünglichen Acht 16 Bit breiten Universal – Register behalten: AX, BX, CX, DX, DI, SI, BP sowie SP. Im Zuge der Umstellung auf 32 Bit wurden diese dann um 16 Bit erweitert: EAX, EBX, ECX, EDX, EDI, ESI, EBP sowie ESP.
Damit ein 32 Bit Mikroprozessor auch noch 16 Bit Code ausführen kann, ist also eine Einbettung des ehemaligen AX – Registers in das EAX Register nötig, ebenso gilt dies für alle weiteren auf 32 Bit erweiterten Register. Die folgende Grafik hierzu von Intel, entnommen aus dem Intel386(TM) DX Microprocessor 32-Bit Datasheet.
[BREAK=Heutige Prozessoren und ihre Eckdaten (Fortsetzung)]
Wie man erkennen kann sind sowohl die 16 Bit langen Register AX – SP vorhanden, als auch die jeweils 8 Bit langen Register AL, AH, BL, BH, etc. Mit diesem einfachen Trick war volle Code – Kompatibilität zu bestehendem 16 Bit Maschinencode gewährleistet. Die Adressierung des Speichers erfolgt, wie zuvor bereits errechnet mit vollen 32 Bit, was die Grenze des adressierbaren Speichers auf 4 GB anhebt.

Ein weiteres signifikantes Merkmal der Mikroprozessoren der 6. Generation (P6-Architektur von Intel und K7-Architektur von AMD) ist die Out-Of-Order Execution. Dies ist auf einfache Art und Weise folgendermaßen erklärbar: Der Befehl

<hr>
MOV EAX, [ESI]
<hr>

lädt den Inhalt der an der Adresse im ESI Register stehenden Speicherzelle in das EAX Register. Dieser Befehl benötigt aufgrund der im Vergleich zu Register-Transferoperationen (Eine Register-Transferoperation ist eine beliebige Operation auf Registern, welche den Inhalt mindestens eines der beteiligten Register verändert) hohen Latenzen und schwachen Performance des Hauptspeichers mehrere Taktzyklen (Gute Vorhersagelogik in einem Mikroprozessor kann diesen Schritt jedoch vorausahnen, und die entsprechenden Daten bereits vorzeitig in den L1-Cache, zum Abruf bereit ablegen). Während dieser Zeit steht der Mikroprozessor quasi still.
Die Out-Of-Order Execution erlaubt nun einen folgenden Befehl, der in keinerlei Abhängigkeit zum obigen Befehls stehen darf, auszuführen. So kann beispielsweise folgendes Befehlsschema an keiner Stelle Out-Of-Order ausgeführt werden:

<hr>
MOV EAX, [ESI]
ADD ESI, 00000004h
MOV EBX, [ESI]
ADD EAX, EBX

<hr>

Dieses kurze Code-Segment addiert zwei an aufeinanderfolgenden Hauptspeicheradressen liegende 32 Bit Zahlen, und speichert das Ergebnis im EAX – Register ab.
Der erste Befehl lädt wie zuvor den Inhalt der an der Adresse ESI stehenden Hauptspeicherzelle in das Register EAX. Da auf den Hauptspeicherzugriff eine gewisse Leerlaufzeit folgt, könnte in dieser Zeit der nächste Befehl ausgeführt werden. Dies ist jedoch nicht möglich, da die Addition von ESI und 00000004h (4 in Hexadezimal – Darstellung auf 32 Bit Länge) die Adresse der Hauptspeicherzelle verändern würde. Der darauffolgende Befehl kann ebenfalls nicht ausgeführt werden, da er eine Erhöhung des Wertes im Register ESI voraussetzt, so dass dieses auf die nächste 32 Bit lange Zahl im Hauptspeicher zeigt.
Ähnliches Szenario bei der zweiten Ladeoperation, in welcher der Inhalt der nun um Vier (Erhöhung um vier, da er erste Operand 32 Bit lang ist und der Speicher mit jeweils 8 Bit Länge angesprochen wird) erhöhten Adresse im ESI – Register des Hauptspeichers in das EBX – Register geladen wird. Auch hier folgt eine Leerlaufzeit, die mit einer Out-Of-Order Execution gefüllt werden könnte. Da der nächste Befehl jedoch eine Addition durchführt, und einer der Operanden das EBX – Register ist, ist dies nicht möglich.

Durch Optimierung des Programmcodes kann dieses Code–Segment jedoch ohne weiteres so umgeschrieben werden, dass eine Out-Of-Order Execution möglich wird. Dies würde jedoch den Umfang dieses Artikels sprengen, für Interessierte findet sich hier die kurze Beschreibung, wie der Programmierer oder gar der Prozessor obiges Beispiel durch Umschreiben des Codes oder Mappen der Register optimieren kann.
Eine Beispielrechnung inklusive Erläuterung ist im Zusatzartikel "Out of Order Execution" zu finden.

Ein Beispiel für erfolgreiche Out-Of-Order Execution bietet folgendes Code-Segment:

<hr>
MOV EAX, [ESI]
SHR EBX
ADD EBX, EDX

<hr>

Hier kann während der Leerlaufzeit des ersten Befehls der darauf folgende ausgeführt werden, da weder auf EAX noch auf ESI zugegriffen wird. Es erfolgt ein Shiften des EBX – Registers um Eins nach Rechts (SHR = Shift right, Schiebeoperation nach Rechts). Da der Athlon im Gegensatz zum Pentium 4 für die Shift – Operation nur einen Taktzyklus benötigt (mehr dazu später) ist hier bei entsprechend langer Leerlaufzeit beim Hauptspeicherzugriff sogar noch eine Ausführung des nächsten Befehls möglich, die Addition des EBX und EDX – Registers.
[BREAK=Heutige Prozessoren und ihre Eckdaten (Fortsetzung)]
Dies hat der P6 – Architektur einen gewaltigen Performanceschub gegenüber den Vorgängern gebracht, die Leerlaufzeiten der CPU konnten minimiert werden, die CPU ist bei vernünftiger Programmierung und Code – Optimierung vollständig und perfekt ausgelastet. Weitere Maßnahmen welche alle Prozessoren der 6. Generation aufweisen sind, ohne Spezifizierung auf Athlon XP oder Pentium 4:<ul> * Vergrößerter L1-Cache: Intel spendierte seinem Topmodell der P6-Architektur 32 KB L1-Cache, AMD spendierte seiner K7-Architektur gar 128 KB L1-Cache
* Vergrößerter L2-Cache: Hier ziehen Intel und AMD am gleichen Strang, bis zu 512 KB L2-Cache konnten die Mikroprozessoren aufweisen.
* Den Mikroprozessoren der 6. Generationen wurden mehrere Recheneinheiten spendiert, so weist die P6-Architektur beispielsweise 3 Integer-Einheiten auf, die K7-Architektur drei Fließkomma-Einheiten. Zusammen mit dem Prinzip der Out-Of-Order Execution stellt dies einen gewaltigen Performanceschub dar.
* Register Renaming: Sowohl die P6 als auch die K7-Architektur bilden die acht General Purpose Register auf bis zu 40 interne Register ab. Die bringt vor allem im Multitasking-Betrieb einen enormen Geschwindigkeitsvorteil.
* Dreistufiger Decoder: Die P6 als auch die K7 – Architektur weisen einen dreistufigen Decoder auf. So können drei µOps gleichzeitig decodiert werden, und an die Recheneinheiten weitergereicht werden. </ul>Generell lässt sich bei der Entwicklung der Architektur der Prozessoren der 6. Generationen ein deutlicher Trend erkennen: Wenn der Programmcode nicht optimiert ist, sich also der Programmierer oder Compiler nicht um Optimierung kümmert, so macht dies der Mikroprozessor von alleine. Dieses Prinzip haben Intel und AMD in ihren neuesten Top – Produkten unterschiedlich umgesetzt, weshalb eine Unterscheidung in diesem Fall nötig wird.
[BREAK=Intel Pentium 4 Northwood: Die Netburst – Architektur]
Intel führte den Pentium 4 zunächst mit dem Willamette – Kern ein, welcher im Gegensatz zum aktuellen Northwood – Kern (512KB L2-Cache, 0.13µm) nur über 256 KB L2-Cache verfügte, sowie in 0,18µm produziert wurde.

Weitere Eigenschaften des Pentium 4 Northwood/Willamette:
* Rapid Execution Engine: Intel spendierte dem Pentium 4 zwei Integer-Einheiten, welche mit doppelter Taktfrequenz laufen, sowie eine weitere Integer-Einheit mit einfacher Taktfrequenz. Somit kann der Pentium 4 rein theoretisch während eines Taktzyklus bis zu fünf Integer-Operationen durchführen
* 20 stufige Pipeline: Die übermäßig lange Pipeline des Pentium 4 ermöglicht hohe Taktfrequenzen sowie eine tiefe Out-of-Order Execution
* Veränderte Struktur des L1-Caches: Intel führt mit dem Pentium 4 den sogenannten Trace-Cache ein, welcher den den bisherigen L1-Code-Cache ersetzt. Der Trace-Cache speichert 12.000 bereits decodierte µOps, und beschleunigt somit die Ausführung speziell von Schleifen.
Zusätzlich stehen noch 8 KB L1-Data-Cache zur Verfügung
* 512 KB on-die L2-Cache puffern einen Großteil der Speicherzugriffe
* Neun Recheneinheiten stehen zur Ausführung von Befehlen bereit:
Zwei ALU-Einheiten mit doppelter Geschwindigkeit
Eine ALU-Einheit mit einfacher Taktfrequenz für Shift/Rotate - Operationen
Eine Einheit um aus dem Speicher zu lesen
Eine Einheit um in den Speicher zu schreiben
Eine FPU-Move Einheit, auch für Speicherzugriffe einsetzbar
Eine FPU-Einheit für Floating Point Rechnungen sowie MMX – Rechnungen​

Somit ergibt sich ein theoretisches Maximum von neun ausführbaren Befehlen gleichzeitig. Durch die Beschränkung des Trace-Caches auf drei µOps pro Taktzyklus liegt das praktische Maximum jedoch weit unter dem theoretischen
* 144 zusätzliche Streaming SIMD Extensions 2, SSE2 genannt
* Einstufiger Decoder, der im Gegensatz zur Vorgängerarchitektur nur eine Operation gleichzeitig decodieren kann.​

Man erkennt an den Änderungen die Intel am Pentium 4 vorgenommen hat, dass dieser Mikroprozessor vorhandenen Programmcode langsamer ausführt als sein Vorgänger. Zum Ersten mal seit dem Intel Pentium führt der Pentium 4 weniger Optimierungsarbeit selbständig durch als sein Vorgänger. Die Bürde der Optimierung wurde wieder dem Programmierer / Compiler aufgelegt. Im Gegensatz zur P6-Architektur benötigt der Pentium 4 im Schnitt somit teilweise deutlich mehr Taktzyklen zur Ausführung bestimmter Operationen. Intel macht dies jedoch mit deutlich erhöhter Taktfrequenz, tiefer Pipeline, sehr guter Sprungvorhersage sowie dem Trace-Cache-Prinzip größtenteils wieder wett.

Noch ein kurzes Schluss-Wort zur Shift – Operation wie zuvor angesprochen:
Intel hat bei der P7-Architektur den sog. Barrel-Shifter eliminiert. Dieser war zuvor für Shift/Rotate – Operationen zuständig, und konnte diese innerhalb eines Taktzyklus ausführen. Anstelle des Barrel-Shifters ist nun die ALU für Shift/Rotate – Operationen zuständig, benötigt hierfür jedoch weitaus mehr als einen Taktzyklus. AMD hat den Barrel – Shifter beibehalten, weswegen obiges Code-Segment auf einem K7-Mikroprozessor deutlich schneller abläuft als auf einem P7-Mikroprozessor.
[BREAK=AMD Athlon XP: Fortsetzung der K7-Architektur]
AMD hat beim Athlon XP, dem Nachfolger des äußerst erfolgreichen Athlon Thunderbirds, die K7-Architektur beibehalten, jedoch an einigen Punkten den Optimierungshebel angesetzt.


* Insgesamt neun Recheneinheiten:
Drei Integer – Einheiten, die jeweils nochmals aufgespaltet sind in IEU (Integer Execution Unit, auch ALU genannt) sowie AGU (Adress Generation Unit). Diese Einheiten verfügen über eine gemeinsame Integer-Pipeline​
Drei FPU – Einheiten, die über eine eigene FPU-Pipeline verfügen
* 10 / 15 stufige Pipeline. An dieser Stelle spalten sich die Aussagen, da die K7-Architektur de facto über zwei getrennte Pipelines verfügt, eine 10 stufige Integer-Pipeline sowie eine 15 stufige Fließkomma-Pipeline
* 128 KB L1-Cache, aufgeteilt in jeweils 64 KB Data- sowie Instruction-Cache
* 256 KB on-die L2-Cache
* Unterstützung für Intels SSE – Befehlssatz
* Dreistufiger Decoder: Der Decoder der K7-Architektur besitzt die Fähigkeit drei Operationen gleichzeitig zu decodieren, und arbeitet unabhängig von den Recheneinheiten.
* Data Prefetch Logik: Der Prozessor kann bei linearem Maschinencode bereits gut vorausahnen welche Daten demnächst benötigt werden. Diese werden dann vorsorglich aus dem langsamen Speicher in den schnellen Cache geladen.​


AMD hat im Prinzip die P6-Architektur übernommen, und an entscheidenden Stellen verbessert. So wurde beispielsweise der sog. Partial Register Stall behoben.

Man kann also erkennen das Intel und AMD getrennte Wege gehen, was die Zukunft ihrer 32 Bit Produkte angeht. Ironischerweise bilden sich diese Pläne und Unterschiede auch direkt auf die 64 Bit Produkte ab, welche im folgenden behandelt werden.

Die kommenden 64 Bit Architekturen

Sowohl Intel als auch AMD haben mittlerweile den Schritt von 32 Bit auf 64 Bit vollzogen, AMD seit gestern wie auch Intel bereits seit längerem auf Silizium.
Die beiden konkurrierenden Architekturen unterscheiden sich jedoch grundlegend, sowohl im geplanten Einsatzgebiet als auch in der Architektur. Auf beide Punkte wird im weiteren Verlauf des Artikels noch genauer eingegangen.

Trotzdem der fundamentalen Unterschiede besitzen beide Mikroprozessoren dennoch einige Gemeinsamkeiten:
* 64 Bit Speicheradressierung
* 64 Bit breite Register
* Volle Kompatibilität zu bisherigem 32 Bit Maschinencode, wobei sich hier jedoch die Implementierung bei beiden Mikroprozessoren unterscheidet

An dieser Stelle erfolgt ein kleiner Schnitt, um den Umfang des Artikels in vernünftigem Rahmen zu halten. Da Intels IA-64 eindeutig für den Servermarkt konzipiert wurde, ist eine genaue Untersuchung im Zuge dieses Artikels nicht von Relevanz in Bezug auf den Einsatz in Desktopsystemen.
Interessierte Leser muss ich an dieser Stelle deshalb an folgenden Teil-Artikel weiterverweisen:

Intel's Itanium: 64 Bit und neue Architektur für den Servermarkt

Im nun folgenden konzentriert sich der Artikel auf die 64 Bit Architektur, welche speziell für den Heimanwendermarkt konzipiert wurde: Die x86-64 Architektur von AMD.
[BREAK=AMD Hammer: x86-64]
AMD selber definiert die Notwendigkeit einer 64 Bit Architektur wie folgt:

Die Notwendigkeit einer 64 Bit Architektur ist hauptsächlich bestimmt durch Anwendungen die große Datenmengen verwalten und viel Speicher adressieren müssen. Solche Anwendungen sind beispielsweise High-Performance Server, Datenbanksysteme, CAD und Digital Content Creation Tools.​

Man sieht also für die nahe Zukunft auf dem Desktop – Bereich keine zwingende Notwendigkeit für 64 Bit Architekturen. Nichtsdestotrotz ist der zukünftige 64 Bit Prozessor von AMD speziell für den Einsatz auf dem Desktop konzipiert worden. Man möchte, so wie dies seitens Intel 1985 geschehen ist, einen sanften Übergang schaffen. Die alte Technik soll weiterhin vollständig ausführbar bleiben, während die neue Technik gleichzeitig zur Programmierung zur Verfügung steht, für zukünftige Produkte.

Aus diesem Grunde ist auch die K8 – Architektur sehr ähnlich zur sehr erfolgreichen K7-Architektur. Wäre die Erweiterung um 32 Bit nicht implementiert, würde der Hammer als direkter Nachfolger des Athlon XP durchgehen. Im Vergleich zu diesem bietet er jedoch nach Aussagen seitens AMD bessere Performance. Aufgrund der Tatsache dass bis heute noch kein ausführlicher Test des AMD Hammer möglich war, kann diese Aussage leider nicht auf ihren Wahrheitsgehalt geprüft werden. Tatsache ist jedoch das der Hammer einige interessante Features mit sich bringt, die ihn auch im 32 Bit Modus attraktiv machen.

<div class="newsfloatleft">
hammer_modi.png
</div>Der AMD Hammer verfügt über zwei Betriebsmodi: Den 32 Bit Legacy-Mode und den 64 Bit Long Mode. Dieser ist seinerseits aufgespalten in den 64 Bit Mode sowie den Compatibility Mode.
In welchem Betriebsmodus sich der Mikroprozessor befindet ist spezifiziert durch drei Statusbits im Statusregister. Je nachdem wie der Programmierer diese Bits setzt, ändert der Mikroprozessor seinen Betriebsmodus

Ein Wechsel vom 32 Bit Legacy-Mode in den 64 Bit Mode ist nicht ohne ein RESET# möglich, umgekehrt ebenfalls nicht. Ein Wechsel der Compatibility Mode im 64 Bit Betriebsmodus ist jedoch im laufenden Betrieb möglich.
[BREAK=AMD Hammer: x86-64 (Fortsetzung)]
Legacy Mode:
Im Legacy-Mode verhält sich der Mikroprozessor wie ein reiner 32 Bit Mikroprozessor. Das Betriebssystem sowie alle auszuführenden Programme müssen im 32 Bit Maschinencode vorliegen. Der Mikroprozessor verfügt über die Standard x86-Register (32 Bit), sowie die MMX, SSE und 3DNow Register (128 Bit). Die FPU-Register sind wie im Long Mode 80 Bit lang, der Befehlszähler 32 Bit.

Long Mode:
Der Long-Mode ist die Besonderheit am Hammer. Hierbei verhält sich der Mikroprozessor wie ein 64 Bit Mikroprozessor. Das Betriebssystem muss für diesen Betriebsmodus im 64 Bit Maschinencode vorliegen, da der Virtuelle Adressraum mit 64 Bit adressiert wird.

<div class="newsfloatleft">
hammer_register.png
</div>Dem Programmierer stehen acht zusätzliche GPRs zur Verfügung, mit jeweils 64 Bit Länge. Ebenso sind alle weiteren General Purpose Register 64 Bit lang.

Ein partieller Zugriff auf die Register ist weiterhin möglich, über EAX werden die untersten 32 Bit des RAX-Registers adressiert, über AX die untersten 16 Bit, über AH und AL die jeweils untersten 8 Bit.

Das besondere am Long Mode ist die Aufspaltung zwischen reinem 64 Bit Mode und dem Compatibility Mode. In diesem Modus führt der Mikroprozessor bei installiertem 64 Bit Betriebssystem weiterhin 32/16 Bit Maschinencode aus. Vom Standpunkt der Anwendung ist zwischen 32 Bit Legacy Mode und 32 Bit Compatibility Mode nicht zu unterscheiden.
Die 32 Bit langen Operanden und Befehle werden mit Nullen auf 64 Bit Länge verlängert, so dass beispielsweise aus dem 32 Bit Wert 4F8C(Hex) der 64 Bit Wert 00004F8C(Hex) wird. Ein Zugriff auf die zusätzlichen Register R8-R15 sowie XMM8-XMM15 ist im Compatibility Mode nicht möglich.
[BREAK=AMD Hammer: x86-64 (Fortsetzung)]
<div class="newsfloatleft">
hammer_core.png
</div>Das eigentliche Rechenwerk des Hammers ist prinzipiell identisch zum K7-Design. Der Mikroprozessor verfügt über drei Integer-Einheiten die ihrerseits aufgespalten sind in ALU und AGU (Adress Generation Unit), sowie drei Fließkomma Einheiten: FADD, FMUL und FMISC. Die FPU-Register sind unabhängig vom Betriebsmodus des Mikroprozessors 80 Bit lang.

Der L1-Cache wird nach bisherigen Informationen weiterhin 128 KB betragen, der on-die L2-Cache wird jedoch höchstwahrscheinlich um 256 KB auf 512 KB ansteigen.

Eine weitere Besonderheit des Hammers ist der integrierte DDR-RAM Controller. Dieser verfügt über ein 128 Bit, Dual-Channel DDR-RAM Interface, welches bis zu 8 DIMMs ansprechen kann. Die Anbindung des Hauptspeichers erfolgt nun nicht mehr über die Northbridge und den Bustakt, sondern Prozessorintern. Dies verringert die Latenzen sowie vergrößert die Übertragungsrate im Vergleich zu externem RAM-Interface.
Im Vergleich zu in die Northbridge ausgelagertem RAM-Interface, bei welchem sich alle verfügbaren Mikroprozessoren ein RAM-Interface teilen müssen, verfügt jeder einzelne Hammer – Mikroprozessor über ein eigenes RAM – Interface. Die Performance von Multiprozessorsystemen ist somit nicht mehr vom gemeinsamen RAM-Interface und dessen Skalierbarkeit abhängig.
[BREAK=Praktischer Nutzen der 64 Bit Technik und Fazit]
Für den durchschnittlichen Heim – PC ist ein 64 Bit Mikroprozessor unnötig, ebenso wie aktuelle Mikroprozessoren nahe der 2 GHz Grenze für solch einen Heimanwender unnötig sind. Für Heimarbeiten wie Office, Surfen im Internet, hin und wieder mal CD-Brennen und DVD schauen, sowie seltener Bildbearbeitung und Videobearbeitung sind - bis auf letzteren Punkt - heutige Mikroprozessoren vollkommen ausreichend.
Die Vorteile die generell ein 64 Bit Mikroprozessor gegenüber einem 32 Bit Mikroprozessor bietet, ohne Spezialisierung auf bestimmte Architekturen sind:

* 64 Bit Speicheradressierung
* 64 Bit breite Register für Operationen mit großen Zahlen​

Ein Heimanwender profitiert jedoch im Gegensatz zum High End Serversystem bisher von keinem der Vorteile.
Im Gegensatz zum Itanium, welcher von Intel speziell für den Servermarkt spezifiziert und konstruiert wurde, bietet der Hammer im Heimanwenderbereich jedoch gewisse Vorteile. Diese sind jedoch keineswegs auf die Erweiterung auf 64 Bit zurückzuführen. Die Verbesserungen in der Architektur des Hammers ermöglichen im Vergleich zum Vorgänger bei gleicher Taktfrequenz höhere Performance bei der Ausführung von 32 Bit Maschinencode. Diese verdankt der Hammer größtenteils dem größeren Cache, dem stark verbesserten und in den Mikroprozessor integrierten Speicher-Interface, der stark verbesserten Sprungvorhersage, sowie der kleineren Latenzen der Caches.

Die Strategie von AMD ist jedoch ein Angriff von der richtigen Seite: Der kommende 64 Bit Mikroprozessor ist vollständig kompatibel zum bestehende 32 Bit Standard, bietet jedoch eine Erweiterung auf einen neuen 64 Bit Standard. Somit ist ein schleichender Wechsel von 32 Bit auf 64 Bit möglich, so wie dies im Jahre 1985 von 16 Bit auf 32 Bit möglich war. Im Gegensatz zu AMD schreitet Intel auf einem anderen Pfad, verwirft die bisherigen Standards, und versucht einen neuen zu etablieren. In der Praxis krankt dieses prinzipiell nicht schlechte System bisher jedoch noch an mangelhafter Softwareunterstützung sowie generell schwacher Performance.
[BREAK=Praktischer Nutzen der 64 Bit Technik und Fazit (Fortsetzung)]
Dass sich der AMD Hammer durchsetzen wird ist beinahe schon fest voraussehbar. Nicht nur bietet er hervorragende und im Vergleich zum Vorgänger bessere Performance bei der Ausführung von 32 Bit Maschinencode, er ermöglicht es den Softwarehäusern ihre Produkte Stück für Stück auf 64 Bit Maschinencode umzustellen. Doch auch hier gibt es einen Haken: Der 64 Bit Mode des Hammers ist ausschließlich dann aktiv, wenn das Betriebssystem im 64 Bit Maschinencode vorliegt. Da im von AMD angepeilten Marktsegment in über 95% der Fälle das Betriebssystem aus Redmond stammt, ist hier demzufolge eine gravierende Abhängigkeit von Microsoft vorhanden: Solange Microsoft nicht ein auf den AMD Hammer angepasstes Betriebssystem anbietet, ist der 64 Bit Mode des Hammers zur Nutzlosigkeit verdammt. Ohne 64 Bit Betriebssystem wird kein Anwender Nutzen haben vom 64 Bit Mode des AMD Hammers, und ohne weite Verbreitung des x86-64 Standards ist kein entsprechender Markt für ein 64 Bit Windows vorhanden. Von welcher Seite dieser Teufelskreis gebrochen wird ist noch ungewiss.

Eine gewisse Chance wird an dieser Stelle vor allem Linux eingeräumt. Eine 64 Bit Version des Linux-Kernels ist bereits angekündigt, somit wird in den ersten Tagen, Wochen oder gar Monaten der Verfügbarkeit des Hammers höchstwahrscheinlich nur unter Linux der 64 Bit Mode verfügbar sein. Ob Linux jedoch eine große Zahl an Anwendern ansprechen wird bleibt zu bezweifeln, denn auch hier ist das angepeilte Marktsegment entscheidend. Spieler werden ebenso wenig zu Linux greifen wie der normale. Poweruser werden hiervon jedoch schnell profitieren, und bei guter und schneller Verfügbarkeit von 64 Bit Programmen hat Linux dennoch eine reelle Chance eine dicke Scheibe vom Windows – Kuchen abzuschneiden.

Eine ganz andere Situation würde sich ergeben, sollten die Gerüchte um Intel und eine x86-64 Lizenz sich als wahr herausstellen. Aufgrund der Tatsache, das AMD diesen Standard quasi allen zur Verfügung stellt (Vergleichbar mit Open Source) ist dies auch ohne weiteres möglich. Sollte sich dieses Gerücht als wahr herausstellen, wäre die Unterstützung aus Redmond gesichert: Wenn beide großen Hersteller im x86-Markt einen Prozessor nach x86-64 Standard anbieten, ist ein großer Markt für ein 64 Bit Betriebssystem aus Redmond vorhanden, und der 64 Bit Mode des Hammers würde sich als sehr schnell als neuer Standard etablieren. Zum Ersten Mal gäbe es dann die Situation, das ein neuer x86-Standard nicht von Intel, sondern vom ewigen Zweiten AMD eingeläutet wird.

Inwiefern Intel nun mit der IA-64 Schiene verfahren wird bleibt ungeklärt. Möglich wäre eine wie bisher erfolgte Konzentration der IA-64 auf den Servermarkt. Da jedoch auch hier der Hammer ein wohl durchdachtes Konzept für hochperformante Server bietet, (beispielsweise mit eigenen RAM-Interface für jede CPU), besteht zumindest die theoretische Wahrscheinlichkeit, dass sich der x86-64 Standard auch im Servermarkt etablieren wird. Wie diese Geschichte ausgehen wird liegt jedoch in ferner Zukunft.
[BREAK=Modul: Out of Order Execution - Optimierungsmöglichkeiten]
Ein Compiler hat die Aufgabe, ein Programm so zu optimieren, so dass dieses so schnell wie möglich abläuft. Im Falle des im Haupttext stehenden Beispiels würde die Optimierung folgendermaßen aussehen:

<hr>
MOV EAX, [ESI] ; EAX = Inhalt der an der Speicheradresse ESI stehenden Speicherzelle
ADD ESI, 00000004h ; Erhöhung des Wertes in ESI um vier
MOV EBX, [ESI] ; EBX = Inhalt der an der Speicheradresse ESI stehenden Speicherzelle
ADD EAX, EBX ; Addition der beiden Register, speichern des Ergebnisses in EAX
<hr>

Dies ist das Original – Codesegment. Es gibt nun zwei Möglichkeiten es zu optimieren: Der Programmierer / Compiler kann den Programmcode entsprechend ändern, oder der Mikroprozessor kann über Register Renaming eigenständig eine Optimierung durchführen.

Das optimierte Programmbeispiel könnte folgendermaßen aussehen:

<hr>
LEA EDI, [ESI, 4, 0] ; EDI = ESI + 4 + 0
MOV EAX, [ESI] ; EAX = Inhalt der an der Speicheradresse ESI stehenden Speicherzelle
MOV EBX, [EDI] ; EBX = Inhalt der an der Speicheradresse EDI stehenden Speicherzelle
ADD EAX, EBX ; Addition der beiden Register, speichern des Ergebnisses in EAX
<hr>

In diesem Programmbeispiel wird selbige Operation wie oben durchgeführt, mit dem Unterschied das die Ausführung deutlich schneller geht. Der angewandte Trick ist folgender:
Anstelle das ESI – Register zweifach zu verwenden für beide Ladeoperationen, wird gleich zu Beginn des Programmsegments mit Hilfe des LEA – Befehls eine Addition mit drei Operanden durchgeführt. Dank des dreistufigen Decoders der P6 als auch der K7-Architektur kann diese Operation innerhalb weniger Taktzyklen durchgeführt werden. Dadurch kann während der Leerlaufzeit der ersten Registertransfer – Operation die zweite eingeleitet werden. Die beiden werden quasi gleichzeitig ausgeführt und somit viel Zeit bei der Ausführung eingespart.

Diese Optimierungsarbeit liegt jedoch beim Programmierer oder Compiler. Eine zweite Möglichkeit ist seit der P6-Architektur gegeben: Das sog. Register Renaming, welches in obigem Beispiel jedoch nicht auftritt. Der Mikroprozessor kann intern die acht GPRs auf mehrere interne, für den Programmierer unsichtbare Register abbilden. Nach dem ersten Registerladebefehl kann der Mikroprozessor das ESI – Register intern auf ein unsichtbares Register abbilden und die Ausführung des nächsten Befehls einleiten. Diese Technik kann jedoch bei weiterer Verwendung des ESI – Registers einen Partial Register Stall bei der P6-Architektur auslösen, was den Geschwindigkeitsvorteil wieder egalisiert.
[BREAK=Modul: Partial Register Stall]
Die P6-Architektur hat einen schwerwiegenden Fehler: Den sog. <b>Partial Register Stall.</b> Durch diesen
Fehler kann es vorkommen, dass &auml;lterer Maschinencode langsamer ausgef&uuml;hrt wird auf einem Mikroprozessor
der 6. Generation als auf einem der 5. Generation.<br>
Durch verschiedene Ma&szlig;nahmen hat Intel es bewerkstelligt, dass generell die P6-Architektur sich um die Optimierung von Programmcode
k&uuml;mmert. Der dreistufige Decoder beispielsweise, oder das Register Renaming. Doch eben dieses hat einen schwerwiegenden Fehler:
Den Partial Register Stall. Der Fehler tritt in Erscheinung, wenn ein Unterregister (Partial Register) eines 32 Bit Registers
(also AL, AH, AX des EAX-Registers, BL, BH, BX des EBX-Registers, etc.) mit Hilfe von Register Renaming auf ein anderes internes
Register abgebildet wird.<br><br>
Um das ganze mit einem Beispiel zu erl&auml;utern: Folgende Programmsequenz vergleicht eine Byte auf Null
(Also pr&uuml;ft ob alle Bits einer 8 Bit Zahl gleich oder ungleich Null sind):

<hr><table border=0 cellpadding=2 cellspacing=2><tr><td colspan=2><font face="courier" size=2><u>Beispiel 1:</u></font></td></tr><tr><td width=300><font face="courier" size=2>cmp BYTE PTR _ch$[esp-4], 1</font></td><td><font face="arial,helvetica" size=1>; Initialisierung des Akkumulators</font></td></tr><tr><td><font face="courier" size=2>sbb EAX, EAX</font></td><td><font face="arial,helvetica" size=1>; Subtraktion: EAX = EAX - EAX</font></td></tr><tr><td><font face="courier" size=2>and EAX, 2</font></td>
<td><font face="arial,helvetica" size=1>; Logisches AND mit EAX und 00000002h</font></td></tr><tr><td><font face="courier" size=2>dec EAX</font></td><td><font face="arial,helvetica" size=1>; erniedrigen von EAX um 1</font></td></tr></table>
<hr>

<table border=1 cellpadding=10 cellspacing=0 bgcolor=#EBE9E9><tr><td><font face="arial,helvetica" size=2><b><u>Zusatzerkl&auml;rung:</b></u><br>
Das logische AND f&uuml;hrt einen Bitweisen Vergleich durch, bei der die 0 sich durchsetzt. Die Wertetabelle des logischen AND sieht wie folgt aus:<br><br><table border=0 cellpadding=0 cellspacing=0><tr><td colspan=3><hr></td></tr><tr><td width=40><u><b>AND</b></u></td><td width=20 align=center>0</td><td width=20 align=center>1</td></tr><tr><td align=center>0</td><td width=20 align=center>0</td><td width=20 align=center>0</td></tr><tr><td align=center>1</td><td width=20 align=center>0</td><td width=20 align=center>1</td></tr><tr><td colspan=3><hr></td></tr></table></font></td></tr></table><br><br>Genau diese Programmcode erzeugt der MS Visual C++ Compiler 4.2 mit voller Pentium – Optimierung.<br><br>Das folgende Programmst&uuml;ck erledigt dieselbige Aufgabe wie zuvor, ist jedoch das Ergebnis des MS Visual C++ 6.0 Compilers mit voller Pentium Pro Optimierung.<br><hr><table border=0 cellpadding=2 cellspacing=2>
<tr><td colspan=2><font face="courier" size=2><u>Beispiel 2:</u></font></td></tr><tr><td width=300><font face="courier" size=2>mov AL, BYTE PTR _ch$[esp-4]</font></td><td><font face="arial,helvetica" size=1>; Initialisierung des AL-Registers</font></td></tr><tr><td><font face="courier" size=2>neg AL</font></td>
<td><font face="arial,helvetica" size=1>; Negation des AL-Registers ins Zweierkomplement</font></td></tr><tr><td><font face="courier" size=2>sbb EAX, EAX</font></td><td><font face="arial,helvetica" size=1>; Subtraktion: EAX = EAX - EAX</font></td></tr><tr><td><font face="courier" size=2>and EAX, -2</font></td><td><font face="arial,helvetica" size=1>; Logisches AND mit EAX und 10000002h</font></td></tr><tr><td><font face="courier" size=2>inc EAX</font></td>
<td><font face="arial,helvetica" size=1>; Erh&ouml;hen von EAX um 1</font></td></tr></table><hr><br>Beide Instruktionen benutzen den Befehl SBB um das Register EAX vollst&auml;ndig auf 0 zu setzen,indem es das Register zun&auml;chst ausliest, von sich selber abzieht und das Ergebnis anschlie&szlig;end wieder zur&uuml;ckschreibt.<br>Da im Gegensatz zum zweiten Beispiel im ersten Beispiel nicht ersichtlich ist wann das Register EAX zuletzt benutzt wurde, kann man hier nicht automatisch davon ausgehen, dass ein Partial Register Stall auftritt. Im Zweiten Falle tritt dieser jedoch bei jeder Ausf&uuml;hrung auf.

Der Partial Register Stall tritt auf, weil der Prozessor direkt nach der neg-Operation auf dem AL-Register dieses auf ein anderes internes Register abbildet als das EAX - Register.
Sobald der Prozessor diesen Fehler jedoch bemerkt muss die gesamte Pipeline gel&ouml;scht werden, der Befehl neu decodiert werden und die Pipeline neu aufgef&uuml;llt werden. Ein Pentium Pro liegt an dieser Stelle ca. 12-15 Takte Pause ein, ein Pentium III nur noch 4-6 Takte. Ein Pentium, 80486 oder AMD Athlon legt an dieser Stelle keine Pause ein, die interne Register-Umbenennung agiert nicht voreilig, ein Partial Register Stall wird vermieden.<br><br>Es gibt jedoch auch bei der P6-Architektur eine M&ouml;glichkeit diesen Fehler zu vermeiden.Die einfachste Methode ist die Verwendung des logischen XOR anstelle des SBB. Dieser Befehl arbeitet zum einen schneller (Ben&ouml;tigt weniger Taktzyklen zur Ausf&uuml;hrung), und setzt ein Register
ebenso komplett auf 0. Die andere M&ouml;glichkeit ist die Subraktion des Registers von sich selber per SUB. In beiden F&auml;llen wird im Gegensatz zu SBB das Register als Clear markiert, also als leer, der Prozessor bildet das Register nicht auf ein anderes, Internes ab, das Problem tritt nicht auf. Ein im Sinne des Partial Register Stalls fehlerfreies Codebeispiel (handoptimiert) w&uuml;rde folgenderma&szlig;en aussehen:

<hr><table border=0 cellpadding=2 cellspacing=2><tr><td colspan=2><font face="courier" size=2><u>Beispiel 3:</u></font></td></tr><tr><td width=300><font face="courier" size=2>mov AL, BYTE PTR _ch$[esp-4]</font></td><td><font face="arial,helvetica" size=1>; Initialisierung des AL-Registers</font></td></tr><tr><td width=300><font face="courier" size=2>neg AL</font></td><td><font face="arial,helvetica" size=1>; Negation des AL-Registers</font></td></tr><tr><td><font face="courier" size=2>xor EAX, EAX</font></td><td><font face="arial,helvetica" size=1>; Logisches Bitweises XOR auf EAX mit EAX</font></td></tr><tr><td><font face="courier" size=2>and EAX, -2</font></td><td><font face="arial,helvetica" size=1>; Logisches AND mit EAX und 10000002h</font></td></tr><tr><td><font face="courier" size=2>inc EAX</font></td><td><font face="arial,helvetica" size=1>; Erh&ouml;hen von EAX um 1</font></td></tr></table><hr><br>Einen sehr &auml;hnlichen Programmcode erzeugt der MS C++ 7.0 Compiler:<br><br><hr><table border=0 cellpadding=2 cellspacing=2><tr><td colspan=2><font face="courier" size=2><u>Beispiel 4:</u></font></td></tr><tr><td width=300><font face="courier" size=2>mov CL, BYTE PTR _ch$[esp-4]</font></td><td><font face="arial,helvetica" size=1>; Initialisierung des CL-Registers</font></td></tr><tr><td width=300><font face="courier" size=2>xor EAX, EAX</font></td><td><font face="arial,helvetica" size=1>; Logisches Bitweises XOR auf EAX mit EAX</font></td></tr><tr><td><font face="courier" size=2>test CL, CL</font></td><td><font face="arial,helvetica" size=1>; Bitweiser Vergleich des CL-Registers</font></td></tr><tr><td><font face="courier" size=2>sete AL</font></td><td><font face="arial,helvetica" size=1>; Setzen des AL - Registers</font></td></tr><tr><td><font face="courier" size=2>lea EAX, DWORD PTR [EAX+EAX-1]</font></td><td><font face="arial,helvetica" size=1>Addition mit drei Operanden</font></td></tr></table><hr><br>Solange also nicht der gesamte Programmcode angepasst wird, kann es also vorkommen, dass ein Pentium III langsamer arbeitet bei bestimmten Code - Sequenzen als ein Pentium oder gar 80486.<br><br>
Die obigen Programmbeispiele sind teilweise entnommen aus dem Pentium 4: In Depth Artikel von <a href="http://www.emulators.com" target=_blank>www.emulators.com</a>
[BREAK=Modul: Intel Itanium: 64 Bit und neue Architektur für den Servermarkt]
Als der Intel Itanium, oder besser gesagt die IA-64 auf dem Intel Microprozessor Forum im
Jahre 1999 vorgestellt wurde, war sie nicht mehr als ein Papiertiger. Man konnte jedoch bereits anhand
der Spezifikationen erkennen welchen Markt Intel im Visier hat: Den Servermarkt. Intel zufolge sind 32 Bit
Mikroprozessoren für den Heimanwenderbereich noch vollkommen ausreichend, und da unter anderem Sun
bereits eine 64 Bit CPU im Servermarkt platziert hatte wollte Intel dem nicht nachstehen.
<br><br>
Der fundamentale Unterschied zwischen dem Intel Itanium und dem Intel Pentium 4 ist die nicht
mehr vorhandene vollständige x86-Kompatibilität. Im Gegensatz zum Pentium 4 hat Intel diese nicht
mehr im Visier und versucht mit dem Itanium einen neuen Industriestandard als Nachfolger des äußert
erfolgreichen x86 einzuführen.<br>
Wo sich bisher der Mikroprozessor um die Optimierung der Ausführung von Maschinencode kümmerte
wählt Intel nun einen anderen Weg: Die Optimierung durch den Compiler. Der Itanium ist ein sogenannter
VLIW - Prozessor, kein reiner superskalarer Mikroprozessor mehr.
<table border=0 cellpadding=10 cellspacing=0>
<tr>
<td valign=top><img src="http://www.planet3dnow.de/artikel/diverses/64bitpreview/module/itanium/images/vliw.png" border=0></td>
<td><font face="arial,helvetica" size=2>
Bei VLIW (Very Long Instruction Word) handelt es sich um eine Erweiterung der Superskalaren
Arbeitsweise. Der Mikroprozessor verfügt wie bei dieser auch über mehrere Recheneinheiten,
welche auf bestimmte Operationen spezialisiert sind (ALU, FPU, etc.). Im Gegensatz zur reinen
superskalaren Arbeitsweise erfolgt die Optimierung der Ausführung jedoch nicht im Leitwerk des
Mikroprozessors, sondern bereits im Voraus durch den Compiler. Das Leitwerk hat nun nur noch
die Aufgabe, die einzelnen Instruktionen an die einzelnen Recheneinheiten zu verteilen.
</font></td></tr></table><br><br>
Im obigen Beispielhaften VLIW - Kern eines Mikroprozessors verfügt dieser über sechs
Recheneinheiten, sowie eine Instruktionslänge von 32 Bit. Ein <b>Superskalarer</b>
Prozessor würde nun ein Instruktionsregister von 32 Bit Länge besitzen, das Leitwerk dieses lesen,
decodieren und anschließend an die entsprechende Recheneinheit weiterleiten.
Ein VLIW Prozessor besitzt hingegen ein Instruktionsregister von
<hr><font face="courier" size=2>Instruktionslänge * Anzahl der Recheneinheiten</font>
<hr>
also im obigen Fall 32 Bit * 6 Recheneinheiten = 192 Bit.
Eine Instruktion enthält also maximal sechs Sub-Instruktionen. Diese Einteilung erledigt der Compiler,
so dass der Programmcode <b>immer</b> optimal auf die Maschine abgestimmt ist.
Intel nennt diese Technik im Itanium <b>EPIC (Explicitly parallel Instruction Computer)</b>, ein Compiler für
IA64 muss somit EPIC-Kompatiblen Maschinencode erzeugen.
<br><br>
Im Falle der IA64 - Architektur werden drei Instruktionen im Instruktionsregister übergeben,
welche jeweils 41 Bit lang sind. Zusätzlich kommen noch 5 Kontrollbits im Instruktionsregister
hinzu, so dass sich eine Gesamtlänge von 128 Bit für das Instruktionsregister ergibt.
Eine genauere Beschreibung würde den Rahmen dieses Artikels bei weitem sprengen,
nicht umsonst hat der „Intel Software Developers Guide“ über 1700 Din A4 - Seiten. Zum weiteren Verständnis
reicht das Wissen über die VLIW - Technik und das EPIC-Prinzip von Intel.
 
Zurück
Oben Unten