IA-64
IA-64 (Intel Architecture 64-Bit) ist eine 64-Bit-Architektur und ein EPIC-Befehlssatz, welche gemeinsam von Hewlett-Packard und Intel für die Itanium Prozessorgenerationen (Merced, Itanium 2, …, Tukwila) entwickelt wurde. Die IA-64-Architektur unterscheidet sich deutlich von der Intel-64-Architektur, die sich als IA-32-Erweiterung versteht und kompatibel zur AMD64-Architektur ist. Intel-64 und AMD64 sind mittlerweile auch wesentlich weiter verbreitet als die IA-64-Architektur.
Inhaltsverzeichnis |
[Bearbeiten] Funktionsweise
Das Design basiert auf einem Konzept mit dem Namen Explicitly Parallel Instruction Computing (EPIC), das dem althergebrachten VLIW (Very Long Instruction Word) ähnelt, jedoch eine Reihe von Verbesserungen enthält. Bei EPIC werden die Prozessorbefehle, die keine Abhängigkeiten 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 feststellt, wie viel Parallelität 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 für jeden Datentyp 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.
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.
[Bearbeiten] 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 hardwaremäßig 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 hardwarebasierende 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.
[Bearbeiten] Fortschritt oder Abwärtskompatibilität
Der Fluch der auf den Entwicklern von Computerarchitekturen lastet ist die Forderung, dass die Software die für ältere Architekturen geschrieben wurde, uneingeschränkt auch auf den Nachfolgearchitekturen laufen soll, genannt Abwärtskompatibilität. So ist die IA-32 Architektur abwärtskompatibel bis zur Architektur des Intel 8080-Prozessors aus dem Jahre 1974. 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 von Konkurrent 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, dass bestehende 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.[1]
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 aufwändig gewesen, selbst im optimistischen, problemfreien Falle wäre immer noch eine Neukompilierung und Auslieferung der Software notwendig. Im schlimmsten Fall wäre aufwändige Fehlerbehebungen, Anpassungen oder vollständige Neuerstellung von Software notwendig, z.B. da nicht immer der Quellcode für Software zur Verfügung steht, beispielsweise im Falle das 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.
AMD verfolgte mit dem AMD64 das pragmatischere Konzept der Abwärtskompatibilität auch über die 32-Bit/64-Bit Grenze hinweg, durch eine um einen 64-Bit-Modus erweiterte Variante der IA-32 Architektur.[1] AMD war hiermit am Markt erfolgreich und konnte Intel damit Marktanteile abjagen. Intel folgte letztendlich AMD architektonisch, auch unter dem Druck von Betriebssystemhersteller Microsoft, welcher ankündigte langfristig nur eine 64-Bit Architektur in Windows unterstützen zu wollen. Intel veröffentlichte daraufhin die Intel-64 Architektur, die weitgehend mit AMD64 übereinstimmt, aber eben auch weiterhin alle Altlasten aus 25 Jahren mit schleppt (was sich bei heutigen Prozessoren aber hauptsächlich im Befehlssatz äußert, da "intern" ohnehin in andere Strukturen dekodiert wird, siehe Mikrocode).
[Bearbeiten] Siehe auch
[Bearbeiten] Weblinks
- Beschreibung vom Hersteller Intel (englisch)
[Bearbeiten] Einzelnachweise
- ↑ a b Michael Kanellos (21. April 2003): AMD rolls dice on Opteron chip (englisch). CNET News. Abgerufen am 10. Mai 2012.
