Befehlssatzarchitektur

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Instruction Set Architecture)

Als Befehlssatzarchitektur, Befehlsarchitektur oder auch Programmiermodell,[1] englisch Instruction Set Architecture bzw. als Akronym ISA, wird die gesamte nach außen sichtbare Architektur eines Prozessors verstanden.[2] Sie erlaubt als Schnittstelle zwischen Software und Hardware eine vollständige Abstraktion der Hardware, da sie sich auf die Funktionalität des Prozessors beschränkt. Während also die Mikroarchitektur die Implementierung in Hardware definiert, spezifiziert die ISA das Verhalten des Prozessors für die Software.[3]

Die durch Prozessorarchitekturen implementierten Befehlssätze werden als Teil der Architektur verstanden und erhalten daher in der Regel deren Namen, z. B. die x86-Architektur. Befehlssatzarchitekturen entwickeln sich mit der Prozessorarchitektur weiter. Werden die Neuerungen als Befehlssatzerweiterungen implementiert ohne den bisherigen Befehlssatz zu verändern, bleibt die ISA rückwärtskompatibel, wie dies beispielsweise bei x86 der Fall ist: Mit IA-32 ist die 32-Bit-Erweiterung der ursprünglichen 16-Bit-ISA definiert und mit x64 ist ein 64-Bit-Befehlssatz und ein 64-Bit-Betriebsmodus dazugekommen.

Da die Befehlssatzarchitektur als formale Beschreibung spezifiziert ist, gibt sie vor allem Assemblersprache-Programmierern die Möglichkeit, das einheitliche Verhalten von Maschinencode für verschiedene Implementierungen einer bestimmten ISA (Mikroarchitekturen oder virtuelle Maschinen) in Bezug auf Register, Datentypen etc. nachzuvollziehen. Damit kann er oder sie binärkompatible Programme für verschiedene Prozessoren erstellen, wenn sie dieselbe Befehlssatzarchitektur verwenden.

Formale Spezifikation

Zur formalen Spezifikation einer Befehlssatzarchitektur gehören die Beschreibung des Befehlssatzes und dessen binärer Kodierung ebenso wie eine Beschreibung der Verhaltensweise der CPU während bestimmter Betriebszustände und beim Eintreten bestimmter Ereignisse: Zu nennen wäre in diesem Zusammenhang beispielsweise das Verhalten der CPU bei einer Unterbrechungsanforderung, die Startadresse der Befehlsabarbeitung und die Initialisierung der Register nach einem Reset, aber auch der Aufbau wichtiger Datenstrukturen (bspw. der verschiedenen Deskriptortabellen im Protected Mode der x86-Architektur). Diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit und soll nur verdeutlichen, dass die Spezifikation einer Befehlssatzarchitektur mehr ist als die Beschreibung der Einzelbefehle ihres Befehlssatzes.

Formen der Implementierung

Mikroprozessor

Man spricht davon, dass ein Mikroprozessor eine Befehlssatzarchitektur implementiert bzw. unterstützt, wenn er alle im Sinne der Regeln dieser Befehlssatzarchitektur gültigen Programme in der vorgesehenen Art und Weise ausführen kann. Viele real existierende Befehlssatzarchitekturen sind aber historisch gewachsen und haben niemals eine formale Spezifikation erfahren. Das ist auch häufig gar nicht erwünscht, würde eine exakte Spezifizierung einen Konkurrenten doch möglicherweise in die Lage versetzen, selbst CPUs mit dieser Befehlssatzarchitektur zu bauen und ihm die Aufgabe abnehmen, selbst herauszufinden, welche Eigenschaften einer nur vage beschriebenen Befehlssatzarchitektur es nun sind, die bspw. die Wahrung der Rückwärtskompatibilität zu einem historisch gewachsenen Bestand an Software erlauben. Die Geschichte x86-kompatibler CPUs zeigt das sehr eindrucksvoll: Insbesondere die Neuentwicklungen von Intel-Konkurrenten wiesen in der ersten Hälfte der 1990er-Jahre immer wieder mehr oder weniger bedeutende Inkompatibilitäten zum Intel-Vorbild auf. In der Praxis werden also häufig auch manche in den Datenblättern nicht dokumentierte Eigenschaften oder vermeintlich unbedeutende Details einer konkreten CPU zum Bestandteil einer Befehlssatzarchitektur.

Virtuelle Maschine

Da eine Befehlssatzarchitektur lediglich eine formale Definition ist, muss sie nicht zwangsweise oder gar ausschließlich als Prozessor implementiert werden. Sie lässt sich auch in Software als eine so genannte virtuelle Maschine implementieren. Man spricht dann auch von einer Emulation. Auf diese Art lässt sich auch Software für eine Befehlssatzarchitektur ausführen und testen, bevor die zugehörige CPU überhaupt gebaut wurde. So wurden große Teile der IA-64-Unterstützung für den Betriebssystemkern Linux programmiert, bevor der erste Itanium Intels Fabriken verließ. Das ist auch der Grund, warum Linux bereits kurz nach Verfügbarkeit der ersten Testmuster auf der Itanium-CPU lauffähig war.

Charakteristische Eigenschaften

Befehlssatzarchitekturen werden unter anderem anhand der folgenden, charakteristischen Eigenschaften klassifiziert:

Im Folgenden wird kurz auf ein paar dieser Aspekte genauer eingegangen, wobei zumeist auf weiterführende Artikel verwiesen wird.

Typ des Befehlssatzes

Bei Befehlssatzarchitekturen werden die folgenden Grundtypen von Befehlssätzen unterschieden (in chronologischer Reihenfolge):

  • CISC – „Complex Instruction Set Computing“
  • RISC – „Reduced Instruction Set Computing“
  • VLIW – „Very Long Instruction Word“
  • EPIC – „Explicitly Parallel Instruction Computing“

Weitere charakteristische Eigenschaften von Befehlssätzen finden sich im Artikel Befehlssatz.

Bitbreite

Die Bitbreite einer Befehlssatzarchitektur äußert sich in der Bitbreite der für den Programmierer sichtbaren Daten- und Adressregister und die der Verarbeitungseinheiten. Zumeist wird die Breite der Datenregister als maßgeblich für die Bitbreite der Befehlssatzarchitektur angesehen.

Beispiele für die Bitbreiten der Befehlssatzarchitekturen am Beispiel der x86-kompatiblen Prozessoren, deren direkte Vorläufer und deren Konkurrenten:

Adressierungsarten und Register

Die Anzahl verfügbarer bzw. implementierbarer Register ist ein wichtiges Kriterium bei der Beurteilung einer Befehlssatzarchitektur. Ebenso wie die verschiedenen Adressierungsarten fließt auch sie unmittelbar in die binäre Kodierung eines Befehlssatzes mit ein.

Optionale Implementierungen

Die Anzahl der Register wird durch die Befehlssatzarchitektur nicht immer exakt vorgegeben. So ist durchaus denkbar, dass die binäre Kodierung des Befehlssatzes zwar eine maximale Anzahl von Registern vorsieht, aber für konkrete Implementierungen durchaus eine geringere Anzahl Register erlauben kann. Auf diese Art und Weise lässt sich ein und dieselbe Befehlssatzarchitektur für verschiedene Einsatzzwecke anpassen oder optimieren. Ähnliches gilt auch für optional implementierbare Befehle. Insbesondere bei Mikrocontroller-Familien ist diese Vorgehensweise beliebt, da sie einerseits eine für den Einsatzzweck einer CPU oder eines Mikrocontrollers optimierte Entwicklung bzw. Konfiguration des CPU-Kerns gestattet, andererseits aber sicherstellt, dass Entwicklungswerkzeuge und Dokumentation nicht ständig grundlegend modifiziert werden müssen. Zudem müssen die Entwickler nicht umgeschult werden oder umlernen.

Operandenanzahl

Ein grundsätzliches Charakteristikum einer CPU ist die Anzahl von Operanden, die ein einzelner Befehl maximal entgegennimmt. Gezählt werden dabei ausschließlich Operanden, die aus dem Arbeitsspeicher geladen werden, nicht jedoch Operanden, die vorher schon in interne Prozessorregister geladen wurden. Bei der Benennung der zugehörigen Architekturen spricht man aber statt von Operanden von Adressen.[4] Man unterscheidet:

  • Ein-Adress-Architektur: Ein Befehl holt maximal einen Operanden aus dem Arbeitsspeicher. Werden mehr Operanden benötigt, beispielsweise für eine Addition oder einen Vergleich, müssen diese vorab in interne Prozessorregister (meistens den Akkumulator) geladen worden sein. Diese findet bei den RISC-Prozessoren Anwendung.
  • Zwei-Adress-Architektur: Ein Befehl holt maximal zwei Operanden aus dem Arbeitsspeicher, beispielsweise die Summanden einer Addition. Es gibt danach noch die Unterscheidung in den Architekturen, ob das Ergebnis standardmäßig in einem internen Prozessorregister abgelegt wird (und dort für weitere Bearbeitungen und Abfragen zur Verfügung steht), oder ob das Ergebnis direkt wieder in eine der beiden Operandenadressen (beispielsweise die erste der beiden) zurückgespeichert wird. Die letztere Methode wurde bei CPUs benutzt, die keine internen Register aufwiesen.
  • Drei-Adress-Architektur: Ein Befehl holt maximal drei Operanden aus dem Arbeitsspeicher, typischerweise die beiden Operanden einer arithmetischen oder logischen Verknüpfung und als dritten Operanden die Adresse, wohin das Ergebnis zurückgespeichert werden soll.

Assemblersprache und Mnemonics

Häufig wird im Zusammenhang mit der Spezifikation einer Befehlssatzarchitektur noch die Notwendigkeit zur Definition einer Assemblersprache genannt, die deren Instruktionen unter anderem so genannte Mnemonics zuordnet und das Format zugehöriger Operanden festlegt. Bei der Beurteilung verschiedener CPUs mit derselben Befehlssatzarchitektur spielt dieser Aspekt aber keine Rolle. So können Hersteller durchaus CPUs mit derselben Befehlssatzarchitektur implementieren, obwohl in deren Datenblättern verschiedene symbolische Darstellungen für deren Befehle genannt sind. So hat beispielsweise Intel in seinem Datenbuch von 1975 die mnemonische Darstellung seiner Assemblersprache für den 8008 gegenüber dem Datenbuch des Vorjahres grundlegend verändert. Trotz allem implementieren die 1974 und 1975 hergestellten 8008-Exemplare zweifelsohne dieselbe Befehlssatzarchitektur. Beim Vergleich der Befehlssatzarchitekturen zweier CPUs lässt sich dieser Aspekt deshalb nicht als vergleichendes Kriterium heranziehen.

Sonstige Eigenschaften

Darüber hinaus gibt es weitere Eigenschaften von Befehlssatzarchitekturen, die hier nur kurz erwähnt werden sollen.

Nicht zur Befehlssatzarchitektur gehörende Aspekte

Beispiele

Die IBM-S/360-Befehlssatzarchitektur

Die erste Befehlssatzarchitektur, die wiederholt mit unterschiedlichen Geschwindigkeiten, Komplexitätsgraden und Technologien reimplementiert und stetig erweitert wurde, ist die der IBM System/360. Deren Mikroarchitektur wurde u. a. auch in einer besonderen Variante des Motorola 68000, dem MC68000/360 reimplementiert. Dabei wurde das Mikroprogramm dieser CPU derart modifiziert, dass sie einen S/360-Befehlssatz ausführen konnte. Die S/360-Befehlssatzarchitektur ist heute aber lediglich eine Untermenge der Befehlssatzarchitekturen von IBMs S/370- und S/390-Serien und der heutigen System-z-Architektur.

Weitere Beispiele

Einzelnachweise

  1. Theo Ungerer: Mikrocontroller und Mikroprozessoren. Springer-Verlag, 2013, ISBN 978-3-662-08746-6, S. 16 (Volltext in der Google-Buchsuche).
  2. Klaus Wüst: Mikroprozessortechnik: Grundlagen, Architekturen, Schaltungstechnik und Betrieb von Mikroprozessoren und Mikrocontrollern. Springer-Verlag, 2009, ISBN 978-3-8348-0461-7, S. 107 (Volltext in der Google-Buchsuche): „Unter Instruction Set Architecture (ISA) versteht man die gesamte nach außen hin sichtbare Architektur: Den Befehlssatz, den Registersatz und das Speichermodell. … Die ISA ist genau das, was für die Erstellung von Maschinenprogrammen für diesen Prozessor bekannt sein muss. … Man kann die ISA deshalb auch als Schnittstelle zwischen Software und Hardware betrachten.“
  3. Wolfram Schiffmann: Technische Informatik 2: Grundlagen der Computertechnik. Springer-Verlag, 2006, ISBN 978-3-540-27249-6, S. 119 (Volltext in der Google-Buchsuche).
  4. Christian Schwidlinski, Andreas Streng, Stefan Voß: Rechnerstrukturen, Kapitel 4: Rechnerarchitektur. (Nicht mehr online verfügbar.) Fakultät für Informatik der Technischen Universität Dortmund, archiviert vom Original am 17. Januar 2019;.