6.2 Prozessorarchitekturen - x86-64, Arm und RISC-V

Drei Ebenen auseinanderhalten

Die Begriffe ISA, Mikroarchitektur und SoC werden häufig vermischt. Die ISA legt fest, welchen Maschinencode Software verwenden darf. Die Mikroarchitektur entscheidet, wie ein Kern diese Befehle intern mit Pipeline, Caches, Ausführungseinheiten und Sprungvorhersage verarbeitet. Ein SoC oder Prozessor-Package kombiniert anschließend einen oder mehrere Kerne mit Speichercontrollern, Grafik, I/O, Beschleunigern und weiteren Funktionsblöcken.

Kompatibler Maschinencode setzt nicht automatisch identische Leistung voraus. Zwei Prozessoren können dieselbe ISA unterstützen, aber unterschiedliche Befehlserweiterungen, Kernzahlen, Cachegrößen und Leistungsgrenzen besitzen. Umgekehrt kann Quellcode für verschiedene ISAs neu übersetzt werden, wenn Betriebssystem, Compiler und Bibliotheken das jeweilige Ziel unterstützen.

Was 32 Bit und 64 Bit tatsächlich bedeuten

Die Bitangabe kann sich auf mehrere Eigenschaften beziehen: Breite der allgemeinen Register, Größe virtueller Adressen, unterstützte Datentypen oder Breite einzelner Rechenwerke. Bei einer 32-Bit-Adresse ergeben sich rechnerisch 2³² unterschiedliche Byteadressen, also 4 GiB Adressraum. Das ist nicht automatisch identisch mit nutzbarem Arbeitsspeicher: Gerätebereiche, Betriebssystemaufteilung und Erweiterungen wie PAE beeinflussen die praktische Nutzung.

Eine 64-Bit-ISA bedeutet nicht, dass heutige Prozessoren alle 64 Adressbits physisch implementieren oder 16 EiB RAM ansprechen. Virtuelle und physische Adressbreiten sind begrenzt und modellabhängig. Der Wechsel zu 64 Bit brachte bei x86-64 zusätzlich mehr allgemeine Register, neue Betriebsmodi und modernisierte Aufrufkonventionen. Ein 64-Bit-Betriebssystem und passende Treiber sind nötig, damit 64-Bit-Anwendungen die Architektur vollständig nutzen.

Architekturfamilien im Überblick

Die folgende Grafik ordnet die behandelten Familien ein. IA-64 ist bewusst als historischer Sonderweg dargestellt. x86-64, Arm und RISC-V werden aktiv weiterentwickelt, unterscheiden sich jedoch bei Lizenzmodell, Kompatibilitätsgeschichte und Erweiterungsstruktur. Keine der Spalten beschreibt automatisch ein vollständiges Produkt.

IA-32, x86 und x86-64

IA-32 bezeichnet Intels 32-Bit-x86-Architektur, die mit dem 80386 eingeführt wurde. x86 entwickelte sich aus den 16-Bit-Vorgängern und bewahrte umfangreiche Abwärtskompatibilität. Dieser Softwarebestand und die große Auswahl kompatibler Betriebssysteme, Anwendungen und Hardware wurden zum entscheidenden Erfolgsfaktor. Die Kompatibilität ist dennoch nicht grenzenlos: Betriebsmodus, Betriebssystem, Treiber, Befehlserweiterungen und alte Hardwareannahmen können Programme begrenzen.

AMD64 erweiterte x86 auf 64 Bit und fügte unter anderem zusätzliche allgemeine Register sowie einen 64-Bit-Modus hinzu. Intel implementierte eine kompatible Variante, die heute Intel 64 genannt wird. Der gemeinsame Oberbegriff x86-64 beziehungsweise x64 ist daher treffender als die Gleichsetzung mit einem einzelnen Hersteller. 32-Bit-Anwendungen können auf vielen x86-64-Systemen über Kompatibilitätsmechanismen laufen; Betriebssysteme können diese Unterstützung jedoch einschränken oder entfernen.

IA-64 und EPIC - der historische Itanium-Weg

IA-64 war eine eigenständige 64-Bit-Architektur von Intel und HP für Itanium-Systeme und keine 64-Bit-Erweiterung von x86. Ihr EPIC-Konzept - Explicitly Parallel Instruction Computing - ließ den Compiler unabhängige Operationen in Bündeln kennzeichnen. Prädikation sollte Verzweigungen reduzieren, Spekulation Latenzen überdecken und eine große Registermenge parallele Arbeit bereitstellen.

Das Konzept war stark von Compilerqualität und planbarer Parallelität abhängig. Dynamische Laufzeiteffekte wie Cache-Misses und schwer vorhersagbare Abhängigkeiten begrenzten statische Planung. x86-Kompatibilität war langsamer und komplexer als native Ausführung. Intel stellte die letzten Itanium-9700-Produkte ein; der letzte reguläre Auslieferungstermin war laut Produktabkündigung der 29. Juli 2021. IA-64 ist deshalb heute historisch relevant, aber keine aktuelle allgemeine Plattformempfehlung.

CISC und RISC - nützliche Herkunft, unscharfe Gegenwart

CISC steht für Complex Instruction Set Computing, RISC für Reduced Instruction Set Computing. Klassisch besitzen CISC-ISAs viele unterschiedlich lange, leistungsfähige Befehle und Adressierungsarten. RISC-ISAs setzen eher auf regelmäßige Codierung, viele Register sowie ein Load/Store-Modell, bei dem Rechenbefehle überwiegend auf Registern arbeiten. Diese Merkmale erklären die historische Entwicklung, bilden aber keine einfache Leistungsrangliste.

Moderne x86-Kerne decodieren viele sichtbare Befehle in interne Mikrooperationen und führen sie parallel sowie Out-of-Order aus. Moderne Arm- und RISC-V-Kerne können ebenfalls breit, spekulativ und komplex aufgebaut sein und besitzen zahlreiche Erweiterungen. Aussagen wie „CISC braucht immer vier bis zehn Takte“ oder „RISC führt jeden Befehl in einem Takt aus“ sind daher falsch. Leistung entsteht aus Mikroarchitektur, Software, Speicherhierarchie und Leistungsbudget - nicht aus dem Etikett allein.

Arm-Architektur und Lizenzmodell

Arm entwickelt eine RISC-basierte Architektur und bietet Prozessor-IP wie Cortex, Neoverse und weitere Systembausteine zur Lizenzierung an. Partner können fertige Arm-Kerndesigns integrieren oder mit einer Architekturlizenz eigene kompatible Mikroarchitekturen entwickeln. Arm fertigt daher nicht pauschal die Endchips aller Geräte und ein Arm-Kern ist nicht automatisch ein vollständiges SoC.

Die Profile trennen Einsatzgebiete: A-Profile für komplexe Betriebssysteme und hohe Anwendungsleistung, R-Profile für Echtzeitaufgaben und M-Profile für Mikrocontroller. Armv9-A führt die A-Profile-Entwicklung fort und ergänzt unter anderem SVE2 sowie Sicherheitsfunktionen. Arm-basierte Systeme reichen heute von Mikrocontrollern und Smartphones über PCs bis zu Servern und Supercomputern; „wenig Rechenleistung und wenige Schnittstellen“ ist keine allgemeingültige Einordnung mehr.

System-on-Chip statt bloßer CPU

Ein SoC kombiniert CPU-Kerne mit weiteren Funktionsblöcken auf einem Chip oder in einem eng gekoppelten Package. Dazu können GPU, NPU, Speichercontroller, Display- und Medien-Engines, Sicherheitsmodule, Funkmodem, PCIe, USB und andere Schnittstellen gehören. Welche Blöcke enthalten sind, hängt vom Produkt ab - weder Arm noch x86 legt eine feste SoC-Ausstattung fest.

Die Integration verkürzt Verbindungen und kann Energie, Platz und Stückkosten sparen. Sie reduziert jedoch häufig die Austauschbarkeit einzelner Komponenten und bindet Treiber, Firmware und Betriebssystem stärker an das konkrete Produkt. Auch aktuelle Desktop- und Notebookprozessoren besitzen zahlreiche SoC-Eigenschaften; die klassische Trennung aus CPU, Northbridge und vielen Zusatzchips ist deshalb zunehmend unpassend.

• Qualcomm integriert eigene und lizenzierte IP in unterschiedliche SoC-Produkte.
• Apple entwickelt eigene Arm-kompatible CPU-Mikroarchitekturen und kombiniert sie mit weiteren Systemblöcken.
• NVIDIA verwendet Arm-Kerne oder eigene Arm-kompatible Designs zusammen mit GPU- und Beschleunigertechnik.
• AMD und Intel integrieren in Client- und Serverprodukten Speicher-, PCIe-, Grafik-, Medien- und Beschleunigerfunktionen in unterschiedlichem Umfang.
• Auftragsfertiger produzieren Chips nach den Designs ihrer Kunden; Entwurf, IP-Lizenzierung und Fertigung sind getrennte Rollen.

RISC-V - offene und modulare ISA

RISC-V ist eine offene Befehlssatzfamilie. Ein Implementierer kann eine standardisierte Basis-ISA mit ratifizierten Erweiterungen kombinieren und darauf eine eigene Mikroarchitektur entwickeln. Offen ist die ISA-Spezifikation - nicht automatisch jedes konkrete Chipdesign, jede Firmware oder jedes Entwicklungswerkzeug. RISC-V International pflegt Spezifikationen und Ökosystem; ein standardkonformer Kern benötigt weiterhin Entwicklung, Verifikation, Speicher- und I/O-Systeme sowie Fertigung.

Aktuelle Basisbezeichnungen beginnen unter anderem mit RV32I, RV32E, RV64I oder RV64E. Die nachfolgenden Buchstaben und Namen beschreiben Erweiterungen. G ist ein Kürzel für eine allgemeine Kombination, während zusätzliche Z-, S-, Sh-/Sm- oder herstellerspezifische X-Erweiterungen genauer benannt werden. Softwarekompatibilität verlangt daher ein definiertes ISA-Profil beziehungsweise eine exakt bekannte Erweiterungsmenge - „RISC-V“ allein genügt nicht.

Warum Offenheit nicht automatisch Sicherheit oder Kostenfreiheit bedeutet

Eine offene ISA reduziert Lizenzabhängigkeiten und ermöglicht Forschung, eigene Beschleuniger und anwendungsspezifische Prozessoren. Sie garantiert jedoch weder einen kostenlosen fertigen Chip noch fehlerfreie oder hintertürfreie Hardware. Entwicklung, Verifikation, EDA-Werkzeuge, IP-Blöcke, Packaging, Masken, Fertigung, Firmware, Compiler und langfristige Pflege verursachen weiterhin Aufwand und Kosten.

Sicherheit muss bei jeder Architektur durch überprüfbare Implementierung, dokumentierte Bootkette, Speicherisolation, Updatefähigkeit und Softwarepflege hergestellt werden. Proprietäre und offene Designs können jeweils sicher oder unsicher umgesetzt sein. Für kritische Systeme zählen Zertifizierung, Lieferkette, nachvollziehbarer Quellstand, Tests und Wartungszusagen stärker als ein einzelnes Lizenzetikett.

Softwarekompatibilität und Übersetzung

Binärprogramme sind normalerweise an ISA und ABI gebunden. Ein x86-64-Programm läuft nicht nativ auf Arm64 oder RV64, auch wenn der Quellcode portabel ist. Neuübersetzung erzeugt passenden Maschinencode; Emulation oder dynamische Binärübersetzung kann fremden Code ausführen, kostet aber zusätzliche Ressourcen und unterstützt nicht automatisch alle Treiber oder hardwarenahen Funktionen.

Vor einer Plattformwahl müssen Betriebssystem, Anwendungen, Bibliotheken, Container-Images, Gerätetreiber, Virtualisierung und Verwaltungswerkzeuge geprüft werden. Container teilen den Kernel des Hosts und ersetzen deshalb keine ISA-Kompatibilität. Multi-Architecture-Images können für mehrere Ziele getrennte Binärdateien enthalten.

Architektur sinnvoll auswählen

• Zuerst benötigte Betriebssysteme, Anwendungen, Treiber und Managementwerkzeuge festlegen.
• Erforderliche ISA-Erweiterungen, ABI und Mindestplattformprofile dokumentieren.
• Leistung mit anwendungsnahen Benchmarks statt mit RISC/CISC-Etiketten vergleichen.
• Energiebedarf, Kühlung, Speicherbandbreite, I/O und Beschleuniger gemeinsam betrachten.
• Langzeitverfügbarkeit, Sicherheitsupdates, Firmwarezugang und Lieferkette bewerten.
• Bei Eigenentwicklungen Lizenzbedingungen aller verwendeten IP-Blöcke und Werkzeuge prüfen - nicht nur die ISA.