Es gibt viele Gründe, warum man sich für die Implementierung eines CISC entscheiden sollte. Der bekannteste Grund ist die Binärkompatibilität mit einem vorhandenen CISC-Befehlssatz. Während die Software-Binärübersetzungstechnologie verbessert wurde, hat die hardwarebasierte Kompatibilität einige technische Vorteile (sowie den Nachteil eines geringeren Übersetzungs-Cachings) und den weniger technischen Vorteil, zuverlässiger zu wirken.
Die Codedichte ist vielleicht der zweitwichtigste Grund für die Wahl von CISC. Der Renesas RX wurde als CISC speziell für die Codedichte entwickelt, da er auf Mikrocontroller abzielt, bei denen die Codespeichergröße ein wesentlicher Kostenfaktor ist. Befehle mit variabler Länge, komplexe Befehle (hauptsächlich mehr Adressierungsmodi), implizite Operanden und eine niedrigere Registerzahl tragen alle zur Codedichte bei.
Ein historischer (und meiner Meinung nach fehlgeleiteter) Grund für die Wahl von CISC bestand darin, die semantische Lücke zwischen Programmierern, die eine höhere Sprache verwenden, und dem Prozessor zu schließen. Da komplexe Anweisungen im Allgemeinen durch eine Folge einfacherer Anweisungen ersetzt werden können, muss die Komplexität eines übergeordneten Sprachkompilierers für einen RISC nicht viel komplexer sein als für einen CISC mit Sprachanpassung. RISC vermeidet "semantische Konflikte" (bei denen eine Prozessoranweisung mehr oder weniger Arbeit leistet als eine entsprechende Sprachanweisung) und erleichtert die Reduzierung der Stärke und die Optimierung der Zeitplanung. ( Weitere Informationen finden Sie unter "Was sind die Kompromisse zwischen CISC und RISC bei der Compiler-Entwicklung?" .)
Die Ausführung eines Befehls kann mit erheblichen Fixkosten verbunden sein. Dies regt die Verwendung relativ komplexer Anweisungen an, um diesen Overhead auf die tatsächlichere Arbeit zu verteilen. Durch Verringern der Anzahl dynamischer Befehle kann die Leistung verbessert werden. Wenn die Kosten für Logik und RAM viel höher waren als die Kosten für ROM, war der Anreiz für komplexe Befehle erheblich, da ein Befehl durch Nachschlagen des Mikrocodes decodiert wurde.
Ein Grund für die Verwendung von CISC, der möglicherweise durch historische Beweise widerlegt wird, besteht darin, dass der Mikrocode für jede Mikroarchitektur optimiert werden kann, während Standardbibliotheken die Funktionen einer neuen Implementierung möglicherweise nur langsam nutzen. Das Optimierungsniveau von Software-Implementierungen von memcopy im Vergleich zum Mikrocode für REP MOVSB impliziert, dass Bibliotheken mehr Aufmerksamkeit erhalten können als Mikrocode. Ein Teil davon kann vom Prozessorhersteller stammen, der eine breitere Anwenderbasis anstrebt, sodass die Rechtfertigung des Aufwands im Vergleich zu Open-Source- oder interner Software schwieriger sein kann, wenn lokalisierte Interessen von Entwicklern oder Anwendern den Implementierungsaufwand beeinflussen können.
Die Möglichkeit, eine optimierte Standardbibliothek mit dem Prozessor auszuliefern, hat erhebliche Vorteile. Die Speicherung und Ausführung einer Plattform-Standardbibliothek kann durch Software-Hardware-Codesign erheblich optimiert werden. Die Unterscheidung zwischen einer komplexen Anweisung und einem Platform Abstraction Layer-Aufruf kann subtil (oder nicht vorhanden) sein. Ein RISC-Entwurf könnte die gleichen Implementierungstechniken für die Behandlung von PAL-Aufrufen verwenden wie ein CISC für komplexe Befehle, einschließlich der Verwendung von Operationen, die nicht im allgemeinen Befehlssatz mit spezialisierter Hardware enthalten sind, durch geschickte Zwischenspeicherung und Dekodierung und durch Angabe von Registeroperanden (obwohl dies bei einem CISC der Fall wäre) häufig dedizierte Register verwenden, die einem funktionsbezogenen ABI ähneln. Das mit CISC verbundene mentale Modell kann solche Optimierungen fördern. Darüber hinaus werden Benutzer möglicherweise weniger durch die erzwungene Einbeziehung von "a" beleidigt.
Das Dekodieren relativ komplexer Befehle kann weniger Overhead haben (und bei der Erkennung von Absichten möglicherweise zuverlässiger korrekt sein) als die vergleichbare RISC-Technik der Spracherkennung, bei der eine Folge von Befehlen als semantische Einheit erkannt wird. Dieser Overheadunterschied würde in einer kleineren Implementierung am deutlichsten sein, aber der Overhead zur Verwendung dieser Informationen verringert die Bedeutung der Einsparungen bei der Dekodierung.
Zusätzliche Kontextinformationen können die Hardwareoptimierung erleichtern. Wenn zum Beispiel ein Wert im Speicher inkrementiert wird, kann die Hardware erkennen, dass die Speicheradresse zweimal verwendet wird (für das Laden und Speichern), was eine Möglichkeit für die Zwischenspeicherung und das Zwischenspeichern von Übersetzungen bietet. Komplexe Anweisungen können solche Informationen explizit bereitstellen. In einer komplexen Anweisung haben Zwischenwerte eine explizite Lebensdauer (die der Anweisung). Bei einem herkömmlichen RISC-Register müssen die Werte explizit überschrieben werden, um das Ende der Lebensdauer anzuzeigen. (Hinweis: Ein RISC könnte ein Register angeben, das nach jeder Verwendung immer auf Null gesetzt wird, wodurch ein Mittel zum Angeben eines temporären Werts für die einmalige Verwendung bereitgestellt wird. Solche Anweisungen wären etwas komplexer.)
Wenn Implementierungsdetails nicht hinter einer Abstraktionsschicht verborgen sind, wird es schwieriger, unterschiedliche Mikroarchitekturen zu verwenden, um sie für unterschiedliche Kompromisse zu optimieren. Die Offenlegung von Mikroarchitekturdetails als Architekturgarantien schließt die Mikroarchitektur in die Kompatibilitätsgarantie ein. Während PAL-Software genauso optimiert werden kann wie komplexe Anweisungen, erfordert dies Hardware-Software-Codesign. Die organisatorische Trennung und Vielfalt erschweren das Codesign.
Komplexe Anweisungen können einen geschützten Zugriff auf den privilegierten Status ermöglichen. Beispielsweise sind komplexe Anweisungen in Bezug auf Interrupts häufig atomar. Während ein RISC-Befehlssatz einen Mechanismus auf Benutzerebene zum vorübergehenden Unterbrechen von Interrupts bereitstellen könnte, möglicherweise sogar so etwas wie Linked-Load, so dass Software den Vorgang explizit wiederholt, wenn er unterbrochen wird, vorausgesetzt, dies ist nicht typisch für RISCs.
In ähnlicher Weise könnte ein komplexer Befehl einen kontrollierten Zugriff und / oder die Verwendung von privilegierten Informationen bereitstellen. Da die ausgeführte Operation eine kontrollierte Semantik aufweist, kann eine tatsächliche Verletzung von Berechtigungen vermieden werden. RISC-orientierte Alternativen umfassen PAL-Code (der normalerweise einen erheblichen Overhead hat) und maskierten Zugriff auf Konfigurationsregister (oder Schattenkopien von Registern), die einen privilegierten Status haben. Das Bereitstellen einer allgemeinen Lösung (RISC) ist schwieriger als das Bereitstellen einer Lösung für einen oder mehrere Sonderfälle (CISC), jedoch leistungsfähiger und weniger anfällig für die Anhäufung von Sonderfällen. Wenn man glaubt, dass es nur wenige wichtige Sonderfälle gibt, kann CISC attraktiver sein.
Komplexe Anweisungen können den Status auch vor der Software verbergen. Ein herausragender Vorteil davon wäre das Speichern und Wiederherstellen von Kontexten. Mit Anweisungen zum Speichern und Wiederherstellen des Zustands muss die Architektur nur die Kontextgröße an das Betriebssystem übermitteln, nicht die spezifischen Mechanismen zum Übertragen des Zustands in den Speicher. Auf diese Weise können Anwendungen, die auf einem älteren Betriebssystem ausgeführt werden, ISA-Erweiterungen verwenden, die den Status hinzufügen. (Auch hier könnte PAL-Software die gleiche Funktionalität bieten.)
Ein Großteil der Komplexität von x86 beruht auf der Kompatibilität vieler Erweiterungen. Mit komplexen und weniger orthogonalen Befehlen (nützlich für die Codedichte), Entfernen von Arbeit, die sich als nicht allgemein erforderlich herausstellte, Vermeiden unnötiger Abhängigkeitsketten (z. B. nur ein Übertragsbit, nur ein dynamisches Schiebebetragsregister), Hinzufügen von Arbeit, die gedreht wurde heraus, um allgemein verwendet zu werden und das kann innerhalb des komplexen Befehls optimiert werden - jeder von diesen würde das Hinzufügen eines neuen Befehls erfordern und den ISA weniger ästhetisch ansprechend machen.
In vielen Fällen würde ein RISC auf solche Probleme nicht stoßen, da Anweisungen stark orthogonal und primitiv sind. In einigen Fällen muss ein RISC möglicherweise neue Grundelemente hinzufügen, diese sind jedoch normalerweise für mehr als eine Verwendung anwendbar.
Sobald die Infrastruktur zur Unterstützung komplexer Anweisungen eingerichtet ist, werden die Hindernisse für zusätzliche komplexe Anweisungen verringert. Das heißt, ein Großteil der Kosten für komplexe Anweisungen fällt einmalig an. Stark RISC-ISAs leiden unter einer zusätzlichen Behinderung bei der Einführung von CISCy-Funktionen.
Die Häufigkeit der Erweiterung von x86 kann auch teilweise auf seine Beliebtheit für Allzweckcomputer und das Händlerprozessormodell zurückgeführt werden (dies erhöht auch die Bedeutung der Binärkompatibilität). RISC-ISAs wurden oft an Systemanbieter gebunden, was eine engere Konzentration auf Anwendungen und den fehlenden Wettbewerb für die Implementierung einer bestimmten RISC-ISA fördert und die Verwendung von Befehlssatzerweiterungen für das Marketing etwas abschreckt. Die Popularität verringert auch die Kosten für die Entwicklung neuer Erweiterungen (einmalige Ausgaben sind bei höherem Volumen weniger wichtig).
Die x86-Kompatibilitätsphilosophie tendiert wahrscheinlich auch dazu, vorhandene Mechanismen zu erweitern, anstatt eine sauberere Unterbrechung bereitzustellen, was bedeutet, dass neue Features stärker von vorhandenen Features beeinflusst werden. Eine höhere Häufigkeit der Ausdehnung fördert auch inkrementellere Änderungen, wodurch die Wiederverwendung von Mechanismen gefördert wird und die Orthogonalität tendenziell verringert wird.
Vergleich einer akademischen Darstellung von klassischem MIPS (das eine Teilmenge moderner Versionen von MIPS ist und verschiedene optionale ISA-Erweiterungen ausschließt) mit modernem x86 (das die Binärkompatibilität bis zum 16-Bit-8086 und die Quasi-Kompatibilität auf Assembly-Ebene noch weiter zurückverfolgt) mit all seinem historischen Gepäck ist weder der beste Fall für die CISC noch ein realistischer Fall für die RISC.