Grundlagen zu Intels Itanium (Teil I)

Nachdem andere 64-Bit-Prozessoren wie etwa MIPS, Alpha oder UltraSparc schon seit zehn Jahren auf dem Markt waren, stellte Intel im Jahre 2001 mit dem Itanium seinen ersten 64-Bit-Prozessor vor. Trotz vieler innovativer Konzepte überwogen bei der ersten Itanium-Generation die Schwächen des neuen Designs. Zudem waren auch die Compiler noch nicht ausgereift, so dass der neue Prozessor leistungsmäßig sogar von gängigen 32-Bit-CPUs überholt wurde.

Mit einem radikalen Redesign und unter dem neuen Namen Itanium 2 (Codename McKinley) hat Intel 2002 viele Schwachpunkte behoben. Seit Mitte 2003 ist nun schon die dritte Version des Itanium mit dem so genannten Madison-Core auf dem Markt. Da er Hardware-kompatibel zu McKinley ist, lässt ihn Intel aber unter der alten Itanium-2-Flagge segeln.

Durch den Übergang zur 0,13-µm-Fertigung konnte Intel die früheren Schwachstellen wie zu kleine Caches oder eine zu geringe Taktfrequenz überwinden. Die offizielle Intel-Roadmap zeigt mindestens bis 2005 immer schneller getaktete Itanium-Modelle mit bis zu 24 MByte Cache und mehreren Cores auf einem Die. Dabei verspricht Intel, Hard- und Software-kompatibel zum aktuellen Itanium 2 zu bleiben. Speziell bei großen Servern ist dieser Investitionsschutz ein entscheidendes Kaufkriterium. So ausgestattet kann sich der Itanium nun endlich anschicken, den 64-Bit-Markt in gewohnter Intel-Manier zu erobern.

In diesem ersten Teil des Artikels werden die speziellen Fähigkeiten des Itaniums, sein Registersatz und die Besonderheiten des EPIC-Befehlssatzes behandelt. Der zweite Teil beschreibt die Pipeline und Cache-Stufen im Detail und geht auf die Kompatibilität und die Performance ein.

Eckwerte

Der Itanium ist keine reinrassige Intel-Entwicklung. Bereits im Mai 1994 gaben die Firmen HP und Intel ihre Zusammenarbeit zur Entwicklung eines neuen 64-Bit-Prozessors bekannt. Das Resultat dieser Kooperation, die unter dem Codenamen Merced entwickelte Itanium Architecture IA, früher Intel Architecture 64, IA-64), wurde im Mai 2000 von beiden Konzernen vorgestellt. Die Eckdaten dieser Architektur sind 128 allgemeine Register, 128 Register zur Gleitkommaverarbeitung, 64 Predicate-Register und eine 64-Bit-Speicheradressierung.

Damit sind 2^64 Bytes an Speicherplatz direkt und linear adressierbar, dies sind 16 Exabyte oder 16 Mega-Mega-Megabyte. Eine solche Speichermenge wird sicherlich in den nächsten Jahren noch nicht benötigt werden. Physikalisch nutzt Intel daher nur 50 Bit, genug für 1024 Terabyte (TByte). Die Beschränkungen von Intels 32-Bit-Architektur (IA-32), die nur eine direkte Adressierung von 4 Gigabyte an Speicher erlaubt, ist damit langfristig überwunden. Sie erschwert den Einsatz des "kleinen" Server-Prozessors Xeon in Highend-Computern spürbar.

Stammbaum

Während der erste der Itanium-Prozessoren, Merced, noch mit 25 Millionen Transistoren auskam, erhöhte sich diese Zahl mit dem Itanium 2 McKinley auf 220 Millionen Transistoren. Für diesen Sprung ist vor allem die direkte Integration des L3-Cache auf dem Die verantwortlich.

Der aktuelle Itanium Madison besteht aus 410 Millionen Transistoren auf dem Die, bis 2005 soll die erste CPU mit mehr als einer Milliarde Transistoren und 24 MByte Cache erscheinen. Zum Vergleich: Der Pentium 4 Northwood benötigt 55 Millionen Transistoren. Seit 2003 spaltet sich mit dem Deerfield ein neuer Ast aus dem Itanium-Stammbaum ab. Deerfield arbeitet mit einer geringen Versorgungsspannung und besitzt nur 1,5 MByte L3-Cache. Dadurch sinkt seine Leistungsaufnahme gegenüber dem Madison von 130 Watt auf 62 Watt. Zudem hat Intel das Design etwas vereinfacht, so dass der Deerfield maximal noch als Dualprozessor laufen kann. Als Zielmarkt für den kleinen Itanium-Bruder sieht Intel Workstations und kompakte Blade-Server. Die wesentlichen Unterschiede zwischen den einzelnen Itanium-CPUs fasst die Tabelle zusammen.

Itanium-Generationen

	Takt	L1-/ L2-/ L3-Cache	Systembus	Prozess
Merced (2001)	733 MHz, 800 MHz	32 KByte / 96 KByte / 4 MByte extern	266 MHz	0,18 µm
McKinley (2002)	900 MHz, 1 GHz	32KByte / 256KByte / 3 MByte intern	400 MHz	0,18 µm
Madison (2003)	1,3 GHz, 1,4 GHz, 1,5 GHz	32 KByte / 256 KByte / max. 6 MByte intern	400 MHz	0,13 µm
Deerfield (2003)	1 GHz	32 KByte / 256 KByte / 1,5 MByte	400 MHz	0,13 µm

Die Prozessoren Merced und McKinley sind in einem 0,18-µm-Prozess gefertigt, Madison und Deerfield hingegen in einem 0,13-µm-Prozess. Aus diesem Grund konnte Intel trotz der erhöhten Zahl an Transistoren die Chipfläche von 410 mm² beim McKinley auf 354 mm² beim Madison verkleinern. Während aber der Pentium 4 (Prescott) seit Anfang 2004 mit 90 nm gefertigt wird, steht dieser Struktur-Shrink für den Itanium erst 2005 an. Denn im Verhältnis zum Verkaufspreis fallen die Fertigungs- und Siliziumkosten bei Server-Prozessoren weniger ins Gewicht, und Intel kann so die "alten" Fabs noch Gewinn bringend auslasten.

Register-Features

Die IA-64 definiert 128 Allzweckregister mit einer Breite von 64 Bit, 128 Floatingpoint-Register und 64 so genannte Predicate-Register (dazu später mehr). Außerdem besitzt die IA-64 noch eine Anzahl weiterer Spezialregister wie 128 Applikationsregister für den Kernel und die Stack Engine, acht Branch-Register und verschiedene ID- sowie Performance-Monitor-Register.

Die ersten 32 Allzweckregister werden statisch, die restlichen 96 Register hingegen dynamisch verwaltet. Das erste der statischen Register r0 ist fest auf den häufig benötigten Wert 0 gelegt. Die übrigen 127 Register können als Operand oder als Zielregister bei der Abarbeitung von Instruktionen dienen.

Jedes Allzweckregister kann auch als ein Bündel von acht 8-Bit-, vier 16-Bit- oder zwei 32-Bit-Registern aufgefasst werden, die sich mit einem einzelnen Befehl bearbeiten lassen. Ein solches Vorgehen bezeichnet man als SIMD (Single Instruction Multiple Data), es entspricht den MMX-Befehlen der Pentium-Prozessoren. SIMD-Befehle eignen sich gut für Multimedia-Anwendungen oder auch für sonstige 8-Bit-Aufgaben wie String-Verarbeitung. Als nettes Feature kann die IA-64 Registerinhalte beim Abspeichern ohne zusätzlichen Rechenschritt inkrementieren. Dies korrespondiert mit dem Postinkrement-Operator der Programmiersprache C und wird in der Programmierung vielfach verwendet.

Rotation mit dynamischen Registern

Die dynamischen Register bieten gegenüber der IA-32 zahlreiche Besonderheiten. Zum einen kann die Register Stack Engine (RSE) den Inhalt der 96 so genannten stacked/rotating Register bei Bedarf in den Cache-Speicher auslagern. Dadurch können Unterprogramme dieselben Register verwenden wie die aufrufenden Routinen und bis zu 127 lokale Integer-Variablen in den schnellen Registern halten. Die langwierigen push- und pop-Befehlssequenzen, die bei IA-32 nötig sind, um Register in Unterprogrammen erst einmal frei zu räumen, vermeidet die IA-64 so durch eine entsprechende Prozessor-Hardware.

Zum anderen bieten die 96 dynamischen Allzweckregister (und ebenso die 96 dynamischen Floatingpoint-Register) auch eine so genannte Rotation. Zunächst ordnet der Itanium dabei den physikalischen Registern virtuelle zu. Diese Zuordnung wird dann typischerweise in den Iterationen einer Schleife pro Durchlauf jeweils um eine Position verschoben. Ist beispielsweise das virtuelle Register v33 auf das physikalische Register r52 abgebildet, so enthält es in der nächsten Iteration den Inhalt von Register r53 - ohne dass die CPU dafür zeitaufwendig Daten physikalisch kopieren muss.

Beispiele für Schleifenstrukturen, die sich durch diese Rotation optimieren lassen, sind Filterfunktionen für die Bildbearbeitung. Hier wertet man für jeden Bildpunkt die benachbarten Bildpunkte aus und berechnet daraus den Farbwert des neuen Punkts. Typischerweise läuft eine Schleife dafür über alle Bildpunkte, die Berechnungen sind unabhängig voneinander. Beim ersten Bildpunkt bringt Rotating noch keine Vorteile: Die Schleife lädt alle benötigten alten Bildwerte in die virtuellen und die entsprechend zugeordneten physikalischen Register und berechnet den ersten neuen Bildpunkt. Beim zweiten Bildpunkt zeigt sich der Vorteil: Rotating verschiebt alle virtuellen Registerinhalte um eine Position, ohne dafür Rechenleistung zu verbrauchen. Jetzt muss die CPU nur noch einen der ursprünglichen Farbwerte neu einlesen und findet alle anderen bereits in den passenden virtuellen Registern vor.

Besonders effizient wird dies, wenn man auch das so genannte Software-Pipe- lining mit berücksichtigt. Da ein superskalarer Prozessor wie der Itanium 2 sechs Befehle gleichzeitig ausführen kann, laufen mehrere Iterationen einer Schleife gleichzeitig ab. Besteht wie im obigen Fall keine Abhängigkeit der Ausgangsdaten, greifen die Iterationen über dieselben virtuellen Register auf unterschiedliche physikalische Register zu, wodurch sich ein zeitaufwendiges Kopieren der Daten von Register zu Register vermeiden lässt.

Floatingpoint-Register

Die Fließkommaeinheit ist eine der herausragenden Funktionseinheiten der IA-64. Für Berechnungen stehen 128 Fließkommaregister mit einer Breite von 82 Bit zur Verfügung. Lediglich die Register f0 und f1 sind fest auf die häufig benötigten Werte 0 beziehungsweise 1 gelegt. Alle Register sind nach dem Schema Ergebnis = Operand1 x Operand2 ansprechbar. Dies ist eine wesentliche Verbesserung gegenüber der IA-32, die alle Fließkommaoperanden über einen Stack übergibt. Die 128 Fließkommaregister sind ebenso wie die Allzweckregister in 32 statische und in 96 dynamische Register aufgeteilt.

Die IA-64 bietet wie die IA-32 die Möglichkeit, 80-Bit-Fließkommaberechnungen durchzuführen. Die zusätzlichen Bits der 82 Bit breiten Register nutzt der Itanium intern für Zwischenergebnisse. Durch die höhere Genauigkeit verringern sich Rundungs- und Verfahrensfehler bei komplexen Berechnungen.

Neben dem 80-Bit-Format sind Floatingpoint-Operationen im 64-Bit-Double-Precision-Format und im 32-Bit-Single-Precision-Format möglich. Bei Single Precision kann der Itanium gleich zwei Werte parallel in einem Floatingpoint-Register halten und bearbeiten. Der Fließkommabefehlssatz enthält unter anderem eine Multiply and Accumulate (MAC) Instruction, die eine Multiplikation und eine Addition in einem Taktzyklus gemeinsam durchführt. Durch die SIMD-Fähigkeit des Prozessors kann man bei einfacher Genauigkeit sogar zwei MAC-Operationen gleichzeitig erledigen. Diese Funktion ist die Grundlage vieler Filter- algorithmen und üblicherweise nur bei Signalprozessoren vorhanden.

Erstaunlich ist, dass die Itanium Architektur keine Befehle zur Berechnung transzendenter Funktionen wie der Quadratwurzel oder des Tangens zur Verfügung stellt. Selbst die einfache Division ist ihr unbekannt. All diese Funktionen bildet der Compiler als Software-Algorithmen nach. Dabei kann er aber die Eigenschaften des Prozessors wie etwa das Software-Pipelining mit Register-Rotation sowie die parallele Ausführung von Programmteilen durch mehrere Fließkommarecheneinheiten optimal ausnutzen. Dadurch ist die Fließkommaberechnung des Itanium meist deutlich schneller als die anderer Prozessoren, die diese Aufgaben fest in Hardware verdrahtet haben.

Predication: Erst rechnen, dann entscheiden

Neben den Allzweck- und den Fließkommaregistern definiert die IA-64 noch 64 Predicate-Register von je einem Bit Breite. Die ersten 16 dieser Register sind statisch, die übrigen werden dynamisch verwaltet und unterstützen das Software-Pipelining durch Rotation. Test- und Vergleichsbefehle setzen die Predicate-Register. Sie berechnen dabei jeweils zwei Predicate-Register, wobei eines für eine erfüllte und das andere für eine nicht erfüllte Bedingung steht.

Bei fast jedem Befehl der IA-64 kann man ein Predicate-Register als Bedingung mit angeben. Ist das Predicate-Register wahr, führt der Itanium den Befehl aus und berechnet das Ergebnis, ansonsten verwirft er es. Der Clou ist nun, dass man zwei Befehle, die sich eventuell wiedersprechen und auch auf dieselben Register zugreifen können, mit zwei komplementären Predicate-Registern versieht. Der Itanium kann dann in seinen Pipelines beide Befehle gleichzeitig abarbeiten, liefert aber am Ende nur das passende Ergebnis.

Durch die Predication kann man einfache Fallunterscheidungen viel eleganter lösen als bei der IA-32. Obwohl bei der IA-64 beide Zweige tatsächlich berechnet werden, ist dieses Vorgehen vielfach schneller als die Verwendung eines bedingten Sprunges. Dieser verursacht nämlich eine massive Störung der Pipeline, falls die Sprungvorhersage sich geirrt hat.

Deutlich wird dies im obigen Beispiel der Berechnung der absoluten Differenz zweier Zahlen. Die IA-32 ermittelt mit dem Befehl cmpGE, welcher der beiden Werte in den Registern r2 und r3 größer ist. Abhängig davon führt sie einen bedingten Sprung zum passenden Codeblock aus. Dieser Sprung bringt jedoch die Pipeline des Prozessors ins Stocken und kostet daher sehr viele Taktzyklen.

Die IA-64 wertet ebenfalls die Bedingung aus und setzt aber damit nur zwei Predicate-Register (p1 und p2) entsprechend. Beide Möglichkeiten der Berechnung werden im Code nun mit Predicate-Registern versehen und auch tatsächlich berechnet. Auf Grund der sechs parallelen Pipelines berechnet die CPU aber sowohl die Werte der Predicate-Register als auch beide Ergebnisse zeitgleich. Am Ende trägt sie jedoch nur den Wert mit passendem Predicate-Flag in das Register r4 zur späteren Weiterverarbeitung ein. Ohne einen einzigen Sprung wird hierbei also das Ergebnis der Fallunterscheidung in nur einem Taktzyklus ermittelt, ohne die Pipeline zu gefährden.

Rechnen in epischer Breite

Die Itanium Architektur definiert eine superskalare Prozessorarchitektur. Eine solche Architektur besitzt mehrere Recheneinheiten (Arithmetic Logic Unit, ALU) und ist dadurch in der Lage, in jedem Taktschritt mehrere Befehle gleichzeitig abzuarbeiten. Entscheidend ist dabei, die ALUs immer mit unabhängigen, parallel ausführbaren Instruktionen zu füttern.

Die meisten superskalaren Prozessoren, nicht aber der Itanium, basieren dazu auf einer RISC-Architektur mit Out-of-Order Execution. Dabei werden mehrere Befehle in einem Puffer bereitgehalten, die der Prozessor in beliebiger Reihenfolge ausführt, sobald eine passende Berechnungseinheit frei ist und die benötigten Operanden vorhanden sind.

Die so berechneten Ergebnisse speichert die CPU dann wieder in der Reihenfolge ab, die durch die ursprüngliche Reihenfolge der Befehle im Befehlsstrom vorgegeben ist (Ergebnissequenzialität).

Für die Out-of-Order Execution muss der Prozessor Abhängigkeiten zwischen den Befehlen erkennen, die verwendeten Register umbenennen, Ergebnisse intern umsortieren und sich auch im Falle einer Unterbrechung durch einen Interrupt nach außen wie ein In-Order-Prozessor geben. All dies erfordert eine komplexe Hardware-Schaltung mit hohem Platzbedarf auf dem Die und sorgt für zusätzliche Stufen in der Bearbeitungs-Pipeline.

Mit EPIC (Explicit Parallel Instruction Computing) beschreitet Intel bei der IA-64 einen anderen Weg. EPIC basiert auf dem VLIW Very Long Instruction Word)-Prinzip. Hier wird ein sehr breites Befehlswort in mehrere Felder unterteilt, die einzelne unabhängige Instruktionen enthalten. Bei der Programmausführung liest die CPU das lange Befehlswort ein und leitet die darin enthaltenen Instruktionen an voneinander unabhängige Ausführungseinheiten weiter. Die Auswahl der parallel ausführbaren Befehle bleibt somit dem Compiler überlassen. Dieser hat beim Erzeugen des Codes einen sehr viel weiteren Blick für den Programmkontext als eine Hardware innerhalb der CPU zur Laufzeit. Deshalb kann der Compiler unabhängige Instruktionen viel effektiver zusammenstellen.

Drei Instruktionen pro Befehlswort

EPIC verwendet lange Befehlswörter von 128 Bit Breite. Diese Befehlswörter werden bei Intel als Bündel bezeichnet und können drei Instruktionen zu je 41 Bit Breite, die Silben, sowie ein so genanntes Template mit fünf Bit aufnehmen. Das Template kodiert die Befehlsart der Instruktionen des Bündels und legt die Ausführungseinheiten fest, die die drei Silben benötigen. So signalisiert etwa das Template-Mnemonic "MII", dass der erste Befehl im Bundle auf das Memory zugreift und die beiden anderen unabhängig je eine Integer-Pipeline belegen.

Die fünf Bit des Templates ermöglichen 32 verschiedene Kombinationen von Befehlsarten, derzeit unterstützt der Itanium jedoch nur 24 Kombinationen. Durch die Verwendung des Templates werden die Kombinationsmöglichkeiten von Befehlen in einem Bündel eingeschränkt. Dadurch kann die Schaltung, die die Instruktionen auf die Ausführungseinheiten verteilt, einfacher und schneller gehalten werden. Allerdings führen die Unverträglichkeiten von Befehlskombinationen auch oft dazu, dass der Compiler kein komplettes Bündel erzeugen kann. Fehlstellen füllt er dann mit NOP (No Operation)-Befehlen, die jedoch den Speicherbedarf für Programme anwachsen lassen.

Der Itanium verarbeitet aber nicht nur ein Bündel gleichzeitig. Er kann die Befehle zweier Bündel zeitgleich auf die Funktionseinheiten verteilen und so maximal sechs Befehle parallel ausführen. Allerdings sind die Kombinationsmöglichkeiten der zwei Bündel eingeschränkt. Während der Itanium-Prozessor mit dem Merced-Kern nur 28 Prozent aller Template-Paarungen parallel ausführen konnte, hat Intel diese Zahl beim Itanium 2 durch die größere Zahl von Ausführungseinheiten auf 75 Prozent gesteigert. Verboten sind die restlichen Kombinationen jedoch nicht. Treffen zwei unverträgliche Bündel aufeinander, so muss eines einen Taktzyklus in einem Pufferspeicher in der Pipeline warten. Bei realen Programmen kann man mit effektiv drei bis vier Befehlen pro Taktzyklus rechnen. In hoch optimierten Libraries soll der Itanium sogar fünf Befehle pro Takt erreichen.

Tipps für die CPU

EPIC erlaubt es, der CPU Informationen etwa über Datenabhängigkeiten oder die wahrscheinlichste Verzweigung bei Fallunterscheidungen mitzuteilen. Zur Optimierung lässt man die erste Codeversion in einem Profiler ablaufen, der den bei einer Verzweigung meist benutzten Weg ermittelt. Eine erneute Compilation baut diese Informationen dann über so genannte Hints in den optimierten Code ein.

Zur statistischenVorhersage von bedingten Sprüngen verwendet der Itanium-Prozessor ebenso wie die Pentium-Prozessoren das zweistufige dynamische PAs-Verfahren nach Yeh-Patt. Für jeden Sprung im Instruktions-Cache wird das Verhalten der letzten Sprünge mitprotokolliert. Ein aus diesem Protokoll ermittelter Wert steuert das Pattern History Memory an. Dieser liefert dann eine Vorhersage, ob der bedingte Sprung wahrscheinlich ist oder nicht.

Trotz der Hinweise und einer ausgefeilten Sprungvorhersage stellen bedingte Sprünge immer noch ein Problem aktueller Prozessordesigns dar, da bei einem falsch vorhergesagten Sprung die gesamte Pipeline mit den zum Teil bereits abgearbeiteten Befehlen verworfen und neu geladen werden muss. Der Itanium begegnet diesem Problem mit den bereits erwähnten Predicated Instructions, der spekulativen Ausführung ganzer Befehlspfade und der relativ kurzen Pipeline.

Vorausschauen ...

Da Speicherzugriffe eine verhältnismäßig lange Zeit benötigen, ist es sinnvoll, spezielle Vorab-Ladebefehle für Daten am Beginn einer Programmsequenz zu platzieren. Das Laden der später benötigten Daten findet dann parallel zur Bearbeitung anderer Befehle statt, die Daten sind aber bereits im Prozessor, wenn eine Berechnung sie später tatsächlich benötigt. Wird zwischen dem Vorab-Ladebefehl und der Stelle im Programmcode, an der die Daten benötigt werden, der betreffende Speicherbereich geändert, so sind die im voraus eingelesenen Daten nicht mehr gültig. Gründe dafür können ein Schreibzugriff des Prozessors selbst oder auch ein DMA-Zugriff eines I/O-Controllers sein. Die ursprünglich eingelesenen Werte werden dann verworfen und neu eingelesen.

Für das Vorabladen der Daten wird mittels des Befehls ld.a (Load Advanced) für eine Ladeoperation ein Eintrag in der Advanced Load Address Table (ALAT) vorgenommen. Im Beispiel erzeugt ld4.a einen entsprechenden Eintrag für das Register r4, das den Inhalt einer Speicheradresse erhalten soll, die in r3 steht. Jetzt hat die CPU genügend Zeit, diesen Wert bis zur eigentlichen Nutzung, der Addition von r4 und r5, aus dem langsamen Speicher zu holen. Werden bis dahin Daten an die betreffende Speicheradresse geschrieben, so löscht die CPU den zugehörigen Eintrag in der ALAT. Vor der Addition prüft der Compiler mit ld4.c.clr, ob der Wert noch gültig ist. Falls ja, erfolgt die Addition ohne Verzögerung. Andernfalls aktualisiert der Itanium den Wert durch einen Zeit raubenden Speicherzugriff.

... und Spekulieren

Neben dem Vorabladen von Daten kann der Itanium auch Sprüngen vorangestellte Ladeoperationen und Berechnungen spekulativ durchführen (Control Speculation). Beim Befehl ld.s (Load Speculative) versucht die CPU, Daten in ein Register zu laden. Das betreffende Register wird markiert, falls beim Laden ein Fehler oder eine Ausnahme aufgetreten sind. Eine solche Ausnahme kann zum Beispiel eine "Page not Present Exception" sein, falls das Betriebssystem die betreffende Seite noch nicht im Speicher eingeblendet hat.

Zur Markierung besitzen die Allzweckregister r0...r127 ein 65. Bit, welches Intel als Not a Thing (NaT) bezeichnet und das bei ungültigen Registerwerten gesetzt ist. Bei Fließkommaregistern wird dagegen ein Wert als Kennzeichnung verwendet, der als Fließkommazahl nicht definiert ist (Not a Value, NatVal).

Im weiteren Programmablauf rechnet man ungeniert mit den Registern und kümmert sich nicht darum, ob sie überhaupt einen sinnvollen Wert enthalten. Erst später prüft man mit dem Befehl chk.s (Check Speculation), ob das Ergebnis auf gültigen Daten beruhte. Ist beim Ergebnis einer Berechnung das NaT-Bit gesetzt oder enthält das Fließkommaregister den Wert NatVal, so führt man über den chk.s-Befehl einen Sprung auf eine Programmsequenz aus, die die Berechnung mit gültigen Daten erneut durchführt.

Im Beispiel rechts wird r3 spekulativ geladen und mit dem Inhalt von r5 nach r6 addiert. Falls die nachfolgende Bedingung durchlaufen wird und man das Ergebnis der Summe benötigt, prüft die CPU zunächst mit chk.s r6, recv, ob r6 einen gültigen Inhalt besitzt. War die Spekulation nicht erfolgreich, wird die Berechnung durch einen Sprung zu recv nachgeholt. Nach Abarbeitung des Korrekturcodes springt der Programmablauf wieder zum Befehl nach chk.s zurück.

Sinnvoll ist obiges Beispiel vor allem dann, wenn man die Summe in r6 nur innerhalb eines Zweiges der Bedingung benötigt. Hat man Glück, steht sie bereit, und der Itanium hat sie "nebenbei" schon im Vorfeld berechnet. Falls nicht, muss man eben noch einmal explizit die Berechnung starten. Und läuft man überhaupt nicht in die Bedingung, kann einem das Ergebnis sowieso egal sein.

Die Verwendung der spekulativen Ausführung von Ladebefehlen führt zwar meist zu einem schnelleren Programmablauf, bedeutet jedoch auch einen größeren Programmcode, da der Korrekturcode ebenfalls vorhanden sein muss. Zudem "verheizt" der Itanium Zeit und Energie mit der Bearbeitung von Befehlen, die eventuell auf ungültigen Daten beruhen.

In diesem ersten Teil des Artikels wurden die speziellen Fähigkeiten des Itaniums, sein Registersatz und die Besonderheiten des EPIC-Befehlssatzes behandelt. Der zweite Teil beschreibt die Pipeline und Cache-Stufen im Detail und geht auf die Kompatibilität und die Performance ein. (ala)