Itanium-Architektur
Itanium ist eine 64‑Bit-Architektur mit EPIC-Befehlssatz, die gemeinsam von Hewlett-Packard und Intel für den gleichnamigen Itanium-Prozessor (Codename Merced) entwickelt wurde. Ende der 1990er Jahre wurde die Befehlssatzarchitektur auch unter der Bezeichnung englisch Intel Architecture 64‑Bit, kurz IA-64, eingeführt, weil sie die damals 32‑Bit-x86-Architektur IA‑32 vollständig hätte ersetzen sollen. IA‑32 (x86) ist eine CISC-Architektur – von der moderneren Architektur des Itanium, IA‑64, mit dem VLIW-Paradigma EPIC versprach man sich eine Beschleunigung der Ausführung. Dabei unterscheidet sich die Itanium-Architektur wesentlich von der x86-Architektur, was bestehende x86-Software anfangs nur über eine langsame Emulation lauffähig hielt. Um von der neuen Architektur wirklich zu profitieren mussten Betriebssysteme und Programme für IA‑64 neu geschrieben werden.
Die Itanium-Architektur (IA‑64) wurde von Intel exklusiv auf dem Server-Markt platziert. Betriebssysteme wie Windows XP von Microsoft wurden zwar auch auf IA‑64 portiert, geblieben ist nach 2005 jedoch nur die Server-Betriebssystemlinie – nach 2010 wird jedoch auch diese nicht mehr weiter entwickelt, da Windows Server 2008 R2 (Oktober 2009) die vorerst letzte Itanium-Version blieb.[1][2]
Abgrenzung
Intel wollte IA‑64 als Nachfolger der damals 32‑Bit-x86‑Architektur – von Intel „IA-32“ genannt – etablieren. Dabei versuchte Intel gemeinsam mit HP zuerst im bereits seit Anfang der 1990er-Jahre durchwegs 64-bittigen Server-Markt Fuß zu fassen. Im Desktop-Bereich blieb Intel mit x86 alias IA-32 vorerst bei 32‑Bit stehen.
IA‑64 alias Itanium war jedoch überhaupt nicht mit x86 kompatibel, für das es bereits eine große Menge an etablierter Software gab. So war es schließlich der x86-Konkurrent AMD, der mit der ab 1999 entwickelten und 2003 eingeführten 64‑Bit-Erweiterung AMD64 den x86-Befehlssatz IA‑32 ebenfalls zur 64‑Bit-Architektur machte. Diese x64-Architektur blieb dabei – im Gegensatz zur Itanium-Architektur „IA-64“ – zu bestehender „IA-32“-Software kompatibel. Bereits seit dem AMD K5 nutzten auch x86-Prozessoren intern RISC-Opcode (μOps), sodass dieser Vorteil bei der Itanium-Architektur nicht mehr gegeben war. Traditionell haben AMD und Intel x86-spezifische Lizenzabkommen, die es dem jeweils anderen erlauben, eingeführte Neuerungen im Befehlssatz ebenfalls zu nutzen. Um den x86-Markt nicht zu verlieren, folgte also auch Intel 2005 mit der zu AMD64 weitestgehend kompatiblen x86-Befehlssatzerweiterung Intel 64 (zuvor auch IA‑32e und EM64T genannt). AMD konnte mit den 2003 vorgestellten Opteron-Prozessoren mit AMD64 (64-Bit-x86) auf dem Server-Markt kostengünstige und gleichzeitig 64-Bit-fähige Server bereitstellen und war damit sehr erfolgreich. Intel selbst stand mit den eigenen nun ebenfalls 64-Bit-x86-Server-Prozessoren auf gleiche Weise in direkter Konkurrenz zu IA‑64 (Itanium). Diese hatte es damit weit schwerer, im Server-Markt Fuß zu fassen. Itanium- und Itanium‑2-Prozessoren wurden schließlich fast ausschließlich von Intel hergestellt. Von der Weiterentwicklung Itanium‑2 stammte dann nur ein Prozessortyp von HP.
Da IA-32 (x86-Architektur ab dem 32-Bit-i386) keine klare Trennung zwischen 32- und 64‑Bit bietet, werden zur eindeutigeren Unterscheidung 64‑Bit-x86-Prozessoren mit x64 (in Anlehnung an x86) bezeichnet – x64-Prozessoren waren bis 2010 bereits wesentlich weiter verbreitet als die 64-Bit-Itanium-Architektur (IA-64), die nach 2010 schließlich eingestellt wurde. 64-Bit-x86-Software (x64) hat sich bis 2020 vollständig durchgesetzt, IA-64/Itanium spielt keine Rolle mehr.
Funktionsweise
Das Design basiert auf einem Konzept mit dem Namen Explicitly Parallel Instruction Computing (EPIC), das dem althergebrachten Very Long Instruction Word (VLIW) ähnelt, jedoch eine Reihe von Verbesserungen enthält. Bei EPIC werden die Prozessorbefehle, die keine Abhängigkeiten voneinander haben und daher parallel ausgeführt werden können, anhand vordefinierter Muster in Instruction Groups aufgeteilt und so an den Prozessor weitergegeben, der dann anhand seiner eigenen Fähigkeiten entscheiden kann, wie viele der theoretisch möglichen Instruktionsgruppen tatsächlich parallel ausgeführt werden. Die Idee dahinter ist, dass bereits der Compiler oder auch der Assembler feststellt, wie viel Parallelität unter Berücksichtigung von Abhängigkeiten möglich ist, und dies entsprechend im Programmcode festhält, und der Prozessor die Pipelines später optimal auslasten kann, je nachdem, wie viele Anweisungen er tatsächlich parallel ausführen kann.
Die Architektur versucht, die Wartezeiten auf den Speicher zu verringern, indem eine große Zahl Register auf dem Prozessor vorhanden ist. So gibt es 128 64-Bit-Register für ganzzahlige Berechnungen, 128 82-Bit-Register speziell für Gleitkomma-Daten und 64 1-Bit-Vorhersageregister, über die die Befehle bedingt ausgeführt werden. Dies erlaubt es, mehr Informationen in den Registern zu halten, anstatt jedes Mal den langsamen Weg über Cache oder Arbeitsspeicher zu beschreiten, wenn Daten benötigt werden. Durch die bedingte Ausführbarkeit nahezu aller Anweisungen ergibt sich eine drastische Verringerung bedingter Sprunganweisungen.
Für das Ausführen von 32-Bit-Software nutzt der Prozessor einen Teil der IA-64-Register als IA-32-Register. Außerdem gibt es im IA-32 einen Sprungbefehl, mit dem in den IA-64-Modus (zurück) gewechselt wird. Nutzt man diesen auf einem IA-32-Prozessor, so erfolgt dort ein Invalid-Opcode-Interrupt.
Die Architektur verfügt über einen großen Befehlssatz mit teilweise hoher Komplexität. So gibt es unter anderem besondere Prozessorbefehle für Multimedia- und aufwendige Gleitkomma-Operationen.
In der Software werden bei einem Funktionsaufruf die aktuellen Registerinhalte auf den Stack geschrieben und nach Ablauf der Funktion wieder zurückgeholt. Dies verursacht Wartezeiten und bremst den Programmfluss aus. Das IA-64-Design reduziert diese Latenz, indem diese Stack-Operationen auf den Registern selbst ausgeführt werden. Die sogenannte Register Stack Engine (RSE) behandelt die Fälle, in denen die Register und der Speicher synchronisiert werden müssen.
IA-32-Emulation
Obwohl die Eigenständigkeit der IA-64-Architektur von Anfang an herausgestellt wurde, wollte man sich dennoch mit dem Prädikat IA-32-kompatibel schmücken. Ältere Itanium-Varianten unterstützen daher auch hardwareseitig IA-32-Befehle auf dem Stand eines Pentium III. Da es sich dabei nur um eine Emulationseinheit handelte, reicht die Leistung von 32-Bit-Software auf einem IA-64-System aber nicht an die Leistung derselben Software auf einem vergleichbaren x86-System heran. Außerdem sind Itanium-Prozessoren mit IA-32 nur bedingt kompatibel, da zum Beispiel das Paging über die IA-64-Architektur läuft und ein Versuch, das CR3 (Page Directory Base Register) mit einem Wert zu laden, von dieser abgefangen wird. Seit dem Itanium 2 wird eine softwarebasierte Variante der x86-Emulation namens IA-32 EL verwendet. Diese ist dank verschiedenster Optimierungen zwar schneller als die hardwarebasierte Variante, aber immer noch langsamer als ein vergleichbar getakteter x86-Prozessor. Generell hat aber die Fähigkeit, IA-32 emulieren zu können, ihre Bedeutung weitestgehend verloren, und alle für den Zielmarkt wichtigen Softwarepakete liegen mittlerweile auch in einer nativen IA-64-Version vor. Neben dem IA-32-Software-Emulator existiert zur Emulation der PA-RISC-Architektur das HP-UX ARIES (Automatic Re-translation and Integrated Environment Simulation)-Paket.
Fortschritt oder Abwärtskompatibilität
Die IA-32-Architektur ist abwärtskompatibel bis zur Architektur des Intel-8086-Prozessors aus dem Jahr 1978. Dies führt dazu, dass Altlasten aus Vorgängerarchitekturen auch in neue Designs übernommen werden müssen. Dadurch können zum einen moderne Gestaltungsansätze nicht bestmöglich umgesetzt werden, zum anderen ist es nicht möglich, eine in sich schlüssige Architektur (zum Beispiel hinsichtlich einheitlicher Operation-Code-Formate) zu erstellen. Der Vorteil der Abwärtskompatibilität ist die problemlose Weiterverwendbarkeit der existierenden Software ohne Anpassungsaufwand (Portierung) und Neukompilation.
Intel versuchte, mit den Altlasten aufzuräumen (auch um sich vom Konkurrenten AMD abzusetzen, welcher vor allem x86-Patente und -Kompetenzen besaß) und veröffentlichte mit der IA-64-Architektur eine eigenständige Architektur, die nicht eine Erweiterung des bestehenden IA-32-Befehlssatzes darstellt. Der Preis, der dafür zu zahlen ist, ist, dass für den IA-32-Befehlssatz geschriebene Software auf der neuen Architektur nur eingeschränkt ausführbar ist. Selbst der weiterhin ausführbare Code wird teilweise auf Software-Basis emuliert, was zu schlechter Leistungsfähigkeit von Software führt.[3]
Dieser gewagte Schritt der Firma Intel erwies sich auf dem freien Markt als nicht durchsetzbar, auch weil für den Endanwender-Markt weiterhin hauptsächlich IA-32-Prozessoren hergestellt wurden und der IA-32-Kompatibilitätsmodus im Itanium extrem langsam war. Auch die notwendige Anpassung zur Ausnutzung der Itaniumfähigkeiten für die enorme Masse der existierenden Software wäre sehr aufwendig gewesen, selbst im optimistischen, problemfreien Falle wäre immer noch eine Neukompilierung und Auslieferung der Software notwendig. Im schlimmsten Fall wären aufwendige Fehlerbehebungen, Anpassungen oder die vollständige Neuerstellung von Software notwendig, z. B. da nicht immer der Quellcode für Software zur Verfügung steht, beispielsweise im Falle, dass ein Hersteller zwischenzeitlich Konkurs gegangen ist. Ein weiteres Problem war eine anfänglich mäßige Leistungsfähigkeit auch von spezifisch angepasster Itaniumsoftware, da sowohl Softwareentwickler, als auch Compilerhersteller erst Erfahrung mit der neuen Itanium-Architektur sammeln mussten, um sie optimal unterstützen zu können, ein Wissen, das für die x86-Architektur bereits langjährig aufgebaut war.[4]
Die gegenüber der IA-32/AMD64 durch längere Anweisungen sowie auch schwer vermeidbare NOP-Füllanweisungen wesentlich schlechtere „Instruction set efficiency“ führte dazu, dass die IA-64-Architektur in vielen Benchmarks schlechtere Ergebnisse zeigt.
Prozessoren
Itanium-Prozessoren gibt es unter folgenden Bezeichnungen:
- Intel Itanium (2001–2002)
- Intel Itanium 2 (ab 2002)
- HP Itanium 2
Betriebssysteme
Für die Itanium-Architektur (IA‑64) verfügbare Betriebssysteme waren und sind u. a.:
Weblinks
- Beschreibung vom Hersteller Intel (englisch)
Einzelnachweise
- Jürgen Kuri: Microsoft stellt Windows XP für die 64‑Bit-CPU Itanium ein. In: Heise online. 6. Januar 2005. Abgerufen am 25. Februar 2017.
- Christof Windeck: Microsoft programmiert keine neue Itanium-Software mehr. In: Heise online. 6. April 2010. Abgerufen am 25. Februar 2017.
- Michael Kanellos: AMD rolls dice on Opteron chip (englisch) CNET News. 21. April 2003. Abgerufen am 10. Mai 2012.
- Andy Patrizio: Why Intel can't seem to retire the x86. ITworld, 4. März 2013, abgerufen am 15. April 2013 (englisch).
- Support for Multiple Architectures. 18.3. Tier 2: Developmental Architectures. In: Committer's Guide. The FreeBSD Documentation Project, abgerufen am 5. März 2017 (englisch).
- FreeBSD/ia64 5.0-DP2 Hardware Notes. The FreeBSD Documentation Project, 7. November 2002, abgerufen am 5. März 2017 (englisch).
- FreeBSD/ia64 Project. The FreeBSD Project, abgerufen am 5. März 2017 (englisch): „The ia64 port is considered a tier 2 platform through FreeBSD 10. After this it will no longer be supported.“
- NetBSD/ia64. In: NetBSD Wiki/ports/. The NetBSD Foundation, Inc., abgerufen am 5. März 2017 (englisch).