Itanium-Architektur

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Itanium)
Wechseln zu: Navigation, Suche
Die Artikel IA-64, Intel Itanium und Intel Itanium 2 überschneiden sich thematisch. Hilf mit, die Artikel besser voneinander abzugrenzen oder zusammenzuführen (→ Anleitung). Beteilige dich dazu an der betreffenden Redundanzdiskussion. Bitte entferne diesen Baustein erst nach vollständiger Abarbeitung der Redundanz und vergiss nicht, den betreffenden Eintrag auf der Redundanzdiskussionsseite mit {{Erledigt|1=~~~~}} zu markieren. Liliana 12:17, 23. Jan. 2016 (CET)

Itanium ist eine 64‑Bit-Architektur mit EPIC-Befehlssatz, welche gemeinsam von Hewlett-Packard und Intel für die Itanium-Prozessoren (Codename Merced) entwickelt wurde. Ende der 1990er Jahre wurde die Befehlssatzarchitektur von Intel auch IA‑64 (für englisch Intel Architecture 64‑Bit) genannt, da sie die damals 32‑Bit-x86-Architektur, von Intel IA‑32 genannt, vollständig hätte ersetzen sollen. IA‑32 (x86) ist eine CISC-Architektur während IA‑64 (Itanium) mit dem VLIW-Paradigma EPIC eine Beschleunigung der Ausführung bringen sollte. Die Itanium-Architektur unterscheidet sich jedoch wesentlich von der x86-Architektur und bestehende Software war nur über eine langsame Emulation lauffähig. Auch Betriebssysteme mussten für IA‑64 neu geschrieben werden.

Die Itanium-Architektur (IA‑64) wurde von Intel nur 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 – doch auch diese ist mittlerweile nicht mehr verfügbar, da Windows Server 2008 R2 (Oktober 2009) die letzte Itanium-Version blieb.[1][2]

Abgrenzung[Bearbeiten | Quelltext bearbeiten]

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. Die x86-Architektur „IA-32“ blieb dabei – im Gegensatz zur Itanium-Architektur „IA-64“ – zu bestehender Software kompatibel. Bereits seit dem Pentium Pro 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).

Da IA-32 (x86-Architektur) und IA-64 (Itanium-Architektur) keine klare Trennung zwischen 32- und 64‑Bit bieten, werden zur eindeutigeren Unterscheidung 64‑Bit-x86-Prozessoren mit x64 (in Anlehnung an x86) bezeichnet – diese sind mittlerweile wesentlich weiter verbreitet als die Itanium-Architektur.

Funktionsweise[Bearbeiten | Quelltext bearbeiten]

Architektur des Itanium

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 dem 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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Itanium-Prozessoren gibt es unter folgenden Bezeichnungen:

Betriebssysteme[Bearbeiten | Quelltext bearbeiten]

Für die Itanium-Architektur (IA‑64) verfügbare Betriebssysteme waren und sind u. a.:

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. 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.
  2. a b Christof Windeck: Microsoft programmiert keine neue Itanium-Software mehr. In: Heise online. 6. April 2010. Abgerufen am 25. Februar 2017.
  3. Michael Kanellos: AMD rolls dice on Opteron chip (englisch) CNET News. 21. April 2003. Abgerufen am 10. Mai 2012.
  4. Andy Patrizio: Why Intel can't seem to retire the x86. ITworld, 4. März 2013; abgerufen am 15. April 2013 (englisch).
  5. 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).
  6. FreeBSD/ia64 5.0-DP2 Hardware Notes. The FreeBSD Documentation Project, 7. November 2002; abgerufen am 5. März 2017 (englisch).
  7. 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.“
  8. NetBSD/ia64. In: NetBSD Wiki/ports/. The NetBSD Foundation, Inc.; abgerufen am 5. März 2017 (englisch).