Warum sollte jemand CISC wollen?

In unserer Vorlesung über Computersysteme wurde uns der MIPS-Prozessor vorgestellt. Es wurde im Laufe des Begriffs (neu) entwickelt und war in der Tat recht einfach zu verstehen. Es verwendet ein RISC- Design, dh , die elementaren Befehle werden regelmäßig codiert und es gibt nur wenige, um die Drähte einfach zu halten.

Es wurde erwähnt, dass die CISC einer anderen Philosophie folgt. Ich schaute kurz auf den x86-Befehlssatz und war schockiert. Ich kann mir nicht vorstellen, wie jemand einen Prozessor bauen möchte, der einen so komplexen Befehlssatz verwendet!

Es muss also gute Argumente geben, warum große Teile des Prozessormarkts CISC-Architekturen verwenden. Was sind Sie?

Es gibt einen allgemeinen historischen Trend.

In den alten Tagen waren die Erinnerungen klein, und so waren die Programme zwangsläufig klein. Außerdem waren Compiler nicht sehr schlau und viele Programme wurden in Assembler geschrieben. Es wurde daher als eine gute Sache angesehen, ein Programm mit wenigen Anweisungen schreiben zu können. Anweisungs-Pipelines waren einfach, und die Prozessoren griffen nacheinander nach einer Anweisung, um sie auszuführen. Die Maschinerie im Prozessor war ohnehin recht komplex. Dekodierungsanweisungen wurden nicht als große Belastung empfunden.

In den 1970er Jahren erkannten CPU- und Compiler-Designer, dass solch komplexe Anweisungen doch nicht so hilfreich waren. Es war schwierig, Prozessoren zu entwerfen, in denen diese Anweisungen wirklich effizient waren, und es war schwierig, Compiler zu entwerfen, die diese Anweisungen wirklich ausnutzten. Die Komplexität der Chipfläche und des Compilers wurde besser für allgemeinere Zwecke wie allgemeinere Register eingesetzt. Der Wikipedia-Artikel zu RISC erklärt dies genauer.

MIPS ist die ultimative RISC-Architektur, weshalb sie so oft gelehrt wird.

Die x86- Familie ist ein bisschen anders. Es war ursprünglich eine CISC-Architektur, die für Systeme mit sehr kleinem Speicher gedacht war (kein Platz für große Anweisungen) und die viele aufeinanderfolgende Versionen durchlaufen hat. Der heutige x86-Befehlssatz ist nicht nur deshalb kompliziert, weil es sich um CISC handelt, sondern weil es sich tatsächlich um einen 8088 mit einem 80386 mit einem Pentium handelt, möglicherweise mit einem x86_64-Prozessor.

In der heutigen Welt sind RISC und CISC nicht mehr die Schwarz-Weiß-Unterscheidung, die sie einst gewesen sein könnten. Die meisten CPU-Architekturen haben sich zu unterschiedlichen Graustufen entwickelt.

Auf der RISC-Seite haben einige moderne MIPS-Varianten Multiplikations- und Divisionsbefehle mit einer nicht einheitlichen Codierung hinzugefügt. ARM- Prozessoren sind komplexer geworden: Viele von ihnen haben zusätzlich zu den „ursprünglichen“ 32-Bit-Befehlen einen 16-Bit-Befehlssatz namens Thumb , ganz zu schweigen von Jazelle , mit dem JVM-Befehle auf der CPU ausgeführt werden. Moderne ARM-Prozessoren verfügen auch über SIMD- Anweisungen für Multimedia-Anwendungen: Einige komplexe Anweisungen zahlen sich schließlich aus.

Auf der CISC-Seite sind alle neueren Prozessoren teilweise RISC-fähig. Sie haben Mikrocode , um all diese komplexen Makrobefehle zu definieren. Die schiere Komplexität des Prozessors macht das Design jedes Modells mehrere Jahre lang, selbst bei einem RISC-Design, was mit der großen Anzahl von Komponenten, mit Pipelining und vorausschauender Ausführung und so weiter zu tun ist.

Warum bleiben die schnellsten Prozessoren CISC draußen? Ein Teil davon ist im Fall der x86-Familie (32-Bit und 64-Bit) die historische Kompatibilität. Aber das ist noch nicht alles. In den frühen 2000er Jahren versuchte Intel, die Itanium- Architektur voranzutreiben . Itanium ist ein extremer Fall komplexer Anweisungen (allerdings nicht wirklich CISC: sein Design wurde EPIC genannt ). Es beseitigt sogar die altmodische Idee, Befehle nacheinander auszuführen: Alle Befehle werden bis zur nächsten Barriere parallel ausgeführt. Einer der Gründe, die Itanium nicht in Kauf nahm, ist, dass niemand, ob bei Intel oder anderswo, einen anständigen Compiler dafür schreiben konnte. Nun, ein guter alter, größtenteils sequentieller Prozessor wie x86_64, das verstehen wir.

Der x86-Befehlssatz ist ein Sonderfall. Ich denke, dass der 68K von Motorola und der VAX von DEC etwas bessere Beispiele für CISC sind. In den Tagen vieler Assembler-Codes hielten die Leute eine sehr regelmäßige, sehr umfassende ISA für besser: Ich glaube, sie nannten den Unterschied zwischen Assembler-Code und der Art und Weise, wie die Leute die " semantische Lücke " dachten . Theoretisch wollten Sie einen Befehlssatz, der Ihren Vorstellungen entspricht.

Der andere große Entwurfstreiber für CISC scheint "Orthogonalität" zu sein: Jeder Befehl würde mit jedem Adressierungsmodus (Register, absolute Adresse, relativer Versatz usw. usw.) funktionieren. Sie können sehen, dass der falsche Mann der Orthogonalität im API-Design in Distributed Computing Environment (DCE) und in CORBA angezeigt wird. Diese Idee ist nicht auf das Design von Befehlssätzen beschränkt.

Ein Grund für CISC war die dichte Kodierung der Anweisungen (Speicher war teuer)). Die gesamte RISC-Idee bestand darin, die CPU zu beschleunigen, indem ständig Anweisungen gleicher Größe abgerufen wurden (kein komplexer, langsamer Schritt zum Ermitteln der Anweisungsgröße). . Speicher war billig. Dieser befreite Schaltungsbereich auf der CPU für andere Dinge (mehr Register, mehr Verarbeitungseinheiten, so dass mehrere Anweisungen parallel ausgeführt werden könnten, wenn sie unabhängig wären). Da die CPU viel langsamer als der Arbeitsspeicher war, hat sich dies ausgezahlt. Aber CPUs wurden schneller (und leisteten mehr parallel und ...), während RAM nicht schneller wurde (zumindest nicht mit der gleichen Geschwindigkeit wie der Datenverbrauch der CPU aufgrund der erhöhten Parallelität). Treffen Sie Cache-Speicher, schnell wie die CPU, aber klein. Jetzt ist der Speicher nicht mehr nur aus Kostengründen, sondern auch aus Gründen der Geschwindigkeit wieder in Gefahr. CISC-Wiederbelebungszeit. Inzwischen sind die CPUs komplexer geworden, Bis zu dem Punkt, an dem der heutige Mikroprozessor viel von dem leistet, was ein RISC-Compiler getan hat: Zerlegen Sie Operationen in elementare Teile, ordnen Sie interne RISCy-Anweisungen neu, damit sie, wann immer möglich, gleichzeitig ausgeführt werden können. RISC wurde aus einem Grund als "Relieve Important Stuff to Compiler" missbilligt ...

Der eigentliche Vorteil von CISC ist die Reduzierung des Speicher- und Cache-Drucks. Dies allein macht es für anspruchsvolle Hochleistungsanwendungen besser, da die Speicherbandbreite ein wesentlicher Engpass in solchen Systemen ist. Bei gleich großem Cache-Speicher können CISC-Prozessoren mehr Informationen beschreiben als RISC. Da CISC-Anweisungen mehrere Mikrooperationen umfassen, sind möglicherweise architektonische Verbesserungen möglich, die den schnellsten Ausführungspfad für diese Anweisung bereitstellen, den das Ausschreiben einzelner Anweisungen jemals bereitstellen könnte. Kurz gesagt, CISC-Prozessoren sind effizienter bei der Nutzung der Speicherbandbreite, was häufig zu Leistungssteigerungen bei speicherintensiven Anwendungen führt.

Um beispielsweise R1 = R2 + R3 + R4 + R5 + R6das Ergebnis auszuführen und auf den Stapel zu verschieben, wird der RISC-Code wie folgt geschrieben:

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

Aus diesem Grund sind 16 Byte Speicherplatz erforderlich.

In CISC können aufgrund der Möglichkeit unterschiedlicher Codierungsstile dieselben Informationen wie folgt dargestellt werden ...

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

Das braucht nur 12 Bytes Speicher. Somit wird die Speicherauslastung verbessert, wodurch der Prozessor mehr Befehle sehen und somit Leerlaufzyklen reduzieren kann.

Ein wichtiger Aspekt, den niemand angesprochen hat, ist, dass fast alle CISC-CPUs mikrocodierte Architekturen sind. Ein Mikrosequenzer und ein Kontrollspeicher verbrauchen viel weniger Platz als ein festverdrahteter Controller, und der Befehlssatz kann geändert werden, ohne dass die Hardware geändert werden muss.

Mikroprozessoren waren neue Geräte, als ich das Feld betrat. In den siebziger und frühen achtziger Jahren war es üblich, eine CPU aus Bit-Slice-ALUs, einer Steuereinheit auf Mikrosequenzerbasis und einem Kontrollspeicher zusammenzusetzen, in den der mikrocodierte Befehlssatz entweder geladen oder eingeblasen wurde. Diese Computer basierten auf der Transistor-Transistor-Logik (TTL) der Serie 7400. Die 4-Bit-ALU 78181 wurde verwendet, um viele Prozessoren zu konstruieren, einschließlich der DEC PDP-11- und frühen VAX 11-Computer, des Data General Nova, Xerox Alto und des Wang-Desktop-Computers.

Es wird Ihnen schwer fallen, einen Desktop-Computer zu finden, der keinen x86-kompatiblen Prozessor verwendet. Dieser Befehlssatz hat MIPS geschlagen, er hat Sparc geschlagen, er hat Alpha geschlagen, er hat Titanic geschlagen (möglicherweise habe ich diesen Namen falsch geschrieben). MIPS hingegen gibt es heute kaum noch. Egal, was Sie heute denken, sehr clevere Leute hielten den x86-Befehlssatz für eine wirklich gute Idee, und sie haben eine Menge Geld damit verdient.

Computer begannen als RISC, weil ein komplexer Befehlssatz die Fähigkeiten von Implementierern überstieg. Wenn Sie einen RISC-Befehlssatz anzeigen möchten, lesen Sie den Befehlssatz CDC 6400-6600 und CDC Cyber ​​170-175. Das ist das richtige RISC. Vor ungefähr 10 Jahren habe ich einige Chipdesigner gefragt, wie viel Speicherplatz sie benötigen würden (in der Ecke eines vernünftigen fortschrittlichen GPU-Chips). Sie erzählten mir von 1 mm2 - einschließlich des Arbeitsspeichers der Maschine, der 99% dieses Speicherplatzes beanspruchen würde.

Wenn Menschen CISC-Maschinen bauen konnten , waren sie tatsächlich im Vorteil. Denken Sie daran, dass x86 lange vor MIPS 1978 im Vergleich zu 1985 veröffentlicht wurde. Zu dieser Zeit benötigten Sie Prozessorzyklen, um Anweisungen zu lesen, zu dekodieren und auszuführen. MIPS im Jahr 1978 hätte vier Zyklen pro Anweisung und pro Operation gedauert. Wenn Sie einen x86-Befehl wie "add register to memory" ausführen, dauert der Befehl möglicherweise 7 Zyklen, führt jedoch 3 Vorgänge aus. Das war ein großer Vorteil. Und je mehr verschiedene Anweisungen Sie haben und je mächtiger jede Anweisung ist, desto größer ist der Vorteil.

Und als der 64-Bit-Befehlssatz x86 mit seinen alptraumhaften Präfixcodes entwickelt wurde, spielte die Komplexität des Befehlssatzes keine Rolle mehr. CISC wird heutzutage nur in RISC übersetzt, und das gesamte Übersetzungsgeschäft macht vielleicht ein Prozent des Chips aus.

Diese Frage hat viel mit den jüngsten Computertrends zu tun, die eine massive Verlagerung hin zu Mobil- und Tablet-Computern begünstigen, wodurch der RISC-Prozessor begünstigt wird, und hat Intel (wahrscheinlich den größten CISC-Anbieter der Welt) bei einer sogenannten "Flexion" benachteiligt Punkt " genau wie die Art, auf die Grove aufmerksam machte und davor warnte. Die Kurzgeschichte besagt, dass CISC unter dem massiven Paradigmenwechsel / Gamechanging-Ansturm des Mobile Computing aufgrund seines anscheinend intrinsisch hohen Energieverbrauchs allmählich zu verschwinden scheint .

CISC wird voraussichtlich immer auf dem Desktop verfügbar sein, aber Mobile wird allgemein als die neue Zukunft des Computing angesehen. Viele Entwicklungsländer (mit einem großen Potenzial an Computernutzern) werden die Desktop-Phase in der Tat weitgehend überspringen. Siehe zum Beispiel Aufstieg und Fall des Desktop-Computing

Ein hervorragendes Beispiel für diese Frage ist Mike Bell, der für Intel in einer neuen Position arbeitet und versucht, Intel über die Atom-CPU mit einem "Skunkworks" -ähnlichen Projekt / einer Initiative mit einer sehr starken Führungskraft besser auf dem Mobilfunkmarkt zu positionieren Unterstützung. Der Mobilfunkmarkt ist stark an die RISC-Architektur und vor allem an ARM-Prozessoren gekoppelt. Dies ist vor allem auf die hohe Energieeffizienz (Stromverbrauch) zurückzuführen, ein neues Schlüsselkriterium für die Datenverarbeitung, auf das die Frage und keine anderen Antworten verweisen. Hier sind zwei aktuelle Artikel in dieser Richtung, die einen Großteil des internen Unternehmensdenkens (und der daraus resultierenden Verwirrung!) Zu diesem Thema enthüllen:

• Intel verzichtet auf "x86-Steuer", sieht keine Zukunft für ARM oder einen seiner Konkurrenten

• Ein Imperium schlägt zurück: Intel erobert den Mobilfunkmarkt

Ein in anderen Antworten nicht genannter Faktor ist wirtschaftlich. Es geht auch um Intel. Die CISC-Architektur wird hauptsächlich von den x86- und x64-Familien repräsentiert. Diese stammen alle vom bescheidenen 8088 ab, der im ursprünglichen IBM-PC verwendet wurde. Die frühe Marktbeherrschung dieser Computerserie bedeutete, dass Intel eine solide Einnahmequelle für F & E hatte. In Verbindung mit der Tatsache, dass Intel den Wettbewerb durch die Kündigung der Second-Source-Verträge eindämmen konnte, konnten die CPU-Preise auf ein extremes Niveau steigen und sehr reiche Bruttogewinnmargen erzielen.

Während andere CPU-Hersteller Probleme hatten, mitzuhalten, konnte Intel Milliarden von Dollar in die Entwicklung neuer, schnellerer Produkte stecken. Der RISC-Wettbewerb konnte nicht annähernd so viel Geld ausgeben. Viele RISC-Prozessoren wurden vom Markt genommen. Irgendwo:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, LEISTUNG (für PC), Hitachi SuperH ...

Ich erinnere mich an Experten aus dieser Zeit, die verkündeten, dass der RISC-gegen-CISC-Krieg vorbei war und die CISC gewonnen hatte. Das hatte es nicht. Es hat einfach alle anderen übertroffen.

Kann sich diese Dynamik jemals ändern? Ist es schon. Kein wirtschaftlicher Vorteil ist absolut.

Die einzige Achillesferse des x86 ist sein unersättlicher Appetit auf Power. Dies hat es einem kleineren, wendigeren Konkurrenten (ARM) ermöglicht, in Märkten (wie Handys / Tablets / usw.) zu gedeihen, in denen es auf Energiesparen ankam.

Ein großartiges Video dazu von einem Mitglied des ARM-Teams ist ARM Processor - Den Samen des Erfolgs säen - Computerphile um ca. 8:30 Uhr

Das zweite Problem für x86 ist der Erfolg der Intel-Strategie. Sie haben es geschafft, fast die gesamte Konkurrenz auszuschalten. Sie wurden langsamer. Seit Jahren liefern neue Intel-Prozessoren nur sehr bescheidene Verbesserungen. Schlimmer noch, super-reiche Margen sind eine harte Diät für jedes Unternehmen.

Heute machen ARM-basierte Systeme auf Chip (SOC) und konkurrierende x64-Chips von AMD den CPU-Markt wieder zu einem interessanten Ort. (MEINER BESCHEIDENEN MEINUNG NACH)

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.

Bevor es reduzierte Befehlssatzkonfigurationen gab, gab es Befehlssatzkonfigurationen. Sie haben ihre Anwendungen. insbesondere bei sehr großen Speicherblockübertragungen mit Chipsätzen mit hoher Kapazität, die nur 4-16 Bytes benötigen würden, um eine gesamte Videoseite zu übertragen, anstatt einer für immer langen Schleife. Das ändert sich und RISC wird zum Status Quo, da die Chipsätze immer ausgefeilter werden, wie die unglaublichen GPUs, die in den High-End-Grafikkarten zu finden sind.

CISC-CPU hat mehr Vorteile als RISC. Weil CISC oft weniger Hardware-Register und XNOR / XOR-Gatter als RISC verwendet !!!! Stellen Sie sich vor, die Befehlsbytes in CISC werden nacheinander ausgeführt, es gibt nur ein Logikgatter und das Register wird verwendet. Wenn 1 Milliarde Transistoren ungefähr 300 Millionen Logikgatter erzeugen können, können Sie 300 Millionen Operatoren oder Prozesse (IF, gleich, mathematisch, variabel, Adressierung usw.) verarbeiten und mehr Programme können in CISC ausgeführt werden. In RISC sind jedoch Dutzende von Logikgattern erforderlich, um ein Programm im Pipeline-Design auszuführen. Also 300 Millionen x 50 Mal (50 Anweisungen) + 15000000000 Bitzähler !!! im sogenannten RISC. CISC verwendet mehr Hardware, um Software-Algothrim zu reduzieren, was die CPU verlangsamt.