Unterschiede zwischen RISC und CISC

[Gast]

HI
Kann mir jemand den Unterschied zwischen den beiden architekturen
RISC und SISC näher bringen (wenn möglich in einfachen Sätzen^^)

ich habe mich schon auf anderen Seiten umgehört doch verstehe ich nicht wirklich was ich da lese.

also hoffe ich auf euch.

mfg

[BlackBirdSR]

HI
Kann mir jemand den Unterschied zwischen den beiden architekturen
RISC und SISC näher bringen (wenn möglich in einfachen Sätzen^^)

ich habe mich schon auf anderen Seiten umgehört doch verstehe ich nicht wirklich was ich da lese.

also hoffe ich auf euch.

mfg

Hab mal den Themennamen angepasst, damit nicht jeder hundertmal darauf hinweist, dass es CISC heisst.

CISC und RISC sind 2 verschiedene Herangehensweisen um eine Prozessor-Architektur herzustellen.
Zu Beginn gab es die beiden Begriffe nicht. Die CPUs wirden immer komplexer auf aufwändiger herzustellen.
Irgendwann kam man auf die Idee, die CPU simpler zu bauen.
Statt vielen mächtigen aber komplexen Befehlen, wollte man wenige aber schnell auszuführende Befehle.
Die komplexeren Befehle konnte man dann durch mehrere Simple ersetzen.

Neben der Sache mit den Befehlen galt es auch den Rest zu entschlacken. Wenige Register, keine FPU, so wenig Komplexität wie möglich eben. Der Compiler würde das schon richten.
Man nannte dieses Konzept RISC, und folglich nannten die Anderen ihres CISC ;)

Heute gibt es sowas eigentlich nicht mehr. heutige angebliche RISC CPUs sind inzwischen mit Features vollgestopft die völlig gegen das RISC Konzept geht.
Hunderte von Registern gigantische FPUs, Ausgeklügelte Arbeitsweisen,Vektorprozessoren in Form von SSE und Co.
Solche CPUs sind inzwischen so aufgebläht wie nie zuvor.
Die angeblichen CISCs (wie unsere AMD und Intel) arbeiten intern eigentlich fast genauso wie die vollgestopften angeblichen RISCs.
Nur nach Aussen hin, scheint es sich noch um CISC zu handeln. (Nehmen CISC Befehle an)

Ich tendiere dazu, nahezu alle heutigen CPUs als Post-RISC anzusehen. Also als Nachfolger der RISC/CISC Generationen, die es pur eigentlich nicht mehr gibt. (bis auf wenige Ausnahmen)

[Gast]

Also ist CISC dann das es komplex geblieben ist oder wie?

[Jackman]

wenn man einen komplexen Befehl durch mehrere simple ersetzt müssten es dann nicht mehr Befehle werden?

[Gast]

richtig, so wird ein 'komplexer' x86 befehl in einer modernen x86 cpu in mehrere micro-ops zerlegt (wie schon oben beschrieben...)

[Gast]

oops, ich glaube ich habe deine frage erst jetzt richtig verstanden... ;-)

nein, die komplexeren befehle bestehen IMMER aus einer kleinen menge an grundbefehlen die in einer bestimmten anzahl und vorallem reihenfolge den jeweiligen cisc befehl darstellen

[Jackman]

Ich meine weil BlackBirdSR geschrieben hat das man wenige aber schnelle Befehle haben wollten.

Aber meiner Meinung nach werden es mehr Befehle wenn man komplexe Befehle in mehrere simple austauscht

bitte berichtigt mich wenn ich falsch liege.

[RoKo]

Ist richtig, deswegen ist auch x86-Code kleiner als PowerPC-Code (Prozessor in den Macs).

[BlackBirdSR]

Ich meine weil BlackBirdSR geschrieben hat das man wenige aber schnelle Befehle haben wollten.

Aber meiner Meinung nach werden es mehr Befehle wenn man komplexe Befehle in mehrere simple austauscht

bitte berichtigt mich wenn ich falsch liege.

Hab mich da wohl unklar ausgedrückt, mein Fehler.
Es ging nicht darum, dass es weniger Befehle pro Operation werden, sondern weniger Befehle die eine CPU kennt.

[Gast]

kein Problem
bin dankbar für alle Antworten :D

[Gast]

Und wo liegen jetzt die Vorteile bzw. Nachteile der jeweiligen architektur?

[zeckensack]

Und wo liegen jetzt die Vorteile bzw. Nachteile der jeweiligen architektur?CISC hat kompakteren Code.
Alle anderen Unterschiede, die's irgendwann mal gab, sind inzwischen verschwunden, weil wie BlackBirdSR schon schrieb mittlerweile CPUs beider Glaubensrichtungen intern sehr ähnlich funktionieren.

Eine moderne "CISC"-CPU wie etwa die aktuellen x86-Geschmacksrichtungen von AMD und Intel zerlegt intern die "CISC"-Befehle in "RISC"-Befehle, und arbeitet sie auch in der Form ab.

Typische Verallgemeinerungen wie "RISC hat die bessere FPU" oder "RISC hat mehr Register" wirst du auch noch ab und an zu hören bekommen, die sind aber so einfach nicht richtig ...

[Gast]

danke

[GloomY]

Eine RISC Architektur vereinfacht die Implementation von z.B. Pipelines verglichen mit einem CISC Prozessor um ein Vielfaches. Das ist allgemein für einen geringen Logik-Aufwandt interessant. CISC Prozessoren müssen alleine schon auf Grund ihrer komplexeren Befehle sehr viel mehr Logik zur Kontrolle der Pipeline(s) und dessen korrekter Ausführung einsetzen.

Z.B. ist das Erhalten der "Precise Execution" - also der Abarbeitung der Exceptions (bei x86 auch Interrupts genannt) in Programm-Order - weitaus einfacher bei einer RISC CPU zu realisieren als bei einer CISC CPU. Precise Execution ist eine wichtige Anforderung an eine Pipeline bei jeder modernen CPU.


Man braucht überhaupt erstmal etwas Zeit, um die RISC Vorteile zu verstehen oder zu begreifen. Teilweise sehe ich das erst jetzt nach sehr langer Zeit. Als Lektüre kann ich dazu das Standardwerk "Hennessy & Patterson - Computer Architecture (3rd Edition)" empfehlen, besonders Kapitel 3 (alles über ILP) und Anhang A (über Pipelines, speziell ca. mindestens 30 Seiten nur über Exception Handling und Anforderungen zur korrekten Ausführung bei Pipelines). :)

[Haarmann]

Gast

Beginnen wir mal in einfachen Worten Vorne.

Vor langer Zeit hatten CPUs weit weniger Transistoren zur Verfügung denn Heute. Trotzdem konnten CPUs schon wirklich in etwa die gleichen Befehle wie Heute. Ich nehme mal keinen Intel, sondern einen Motorola 68k als Exempel hierfür. Ein klassischer CISC "Verteran". Das Teil konnte problemlos 32 Bit Register nutzen als Operanden. Allerdings würden alle Grundrechenarten "fest verdrahtet" bereits mehr Transistoren verbrauchen, denn der Chip hat. Nun führen bekanntlich viele Wege nach Rom und, ich nehme mal die Multiplikation hervor als Exempel, diese lässt sich z.B. darstellen als viele Additionen oder als Verkettung verschiedener Teilmultiplikationen implementieren, wenn ich Transitoren sparen muss, aber dadurch wird sie nicht schneller, sondern langsamer. Statt ner direkten Multiplikation arbeitet die CPU nun intern ein Program ab und am Ende kommt das Resultat auch raus. Ich könnte diese Aufteilung nun auch MicroOps oder so nennen...
Ich kann nun aber auch einfach keine komplizierten Befehle implementieren und alles in HW machen. Ich reduziere als den Befehlssatz - daher das R in RISC. Wenn ich nun multiplizieren will, dann muss ich das interne Program des CISC halt quasi nachbilden. Macht den Code grösser, aber hat eben, wie von anderen erwähnt auch seine Vorteile.

Heute kanns eigentlich keine RISC CPUs mehr geben, weil die Dinger in etwas den gleichen Befehlssatz haebn, wie die "CISC".

[zeckensack]

Eine RISC Architektur vereinfacht die Implementation von z.B. Pipelines verglichen mit einem CISC Prozessor um ein Vielfaches. Das ist allgemein für einen geringen Logik-Aufwandt interessant. CISC Prozessoren müssen alleine schon auf Grund ihrer komplexeren Befehle sehr viel mehr Logik zur Kontrolle der Pipeline(s) und dessen korrekter Ausführung einsetzen.

Z.B. ist das Erhalten der "Precise Execution" - also der Abarbeitung der Exceptions (bei x86 auch Interrupts genannt) in Programm-Order - weitaus einfacher bei einer RISC CPU zu realisieren als bei einer CISC CPU. Precise Execution ist eine wichtige Anforderung an eine Pipeline bei jeder modernen CPU.


Man braucht überhaupt erstmal etwas Zeit, um die RISC Vorteile zu verstehen oder zu begreifen. Teilweise sehe ich das erst jetzt nach sehr langer Zeit. Als Lektüre kann ich dazu das Standardwerk "Hennessy & Patterson - Computer Architecture (3rd Edition)" empfehlen, besonders Kapitel 3 (alles über ILP) und Anhang A (über Pipelines, speziell ca. mindestens 30 Seiten nur über Exception Handling und Anforderungen zur korrekten Ausführung bei Pipelines). :)Inwiefern?
Interrupts sind nicht so das Problem. Ein Sprung ist ein Sprung ist ein Sprung ;)

Meinst du exception handling? Könnte ich mir jedenfalls vorstellen, aber eigentlich kann man auch da Entwarnung geben. Zum Gedankengang:
Wir haben eine "CISC"-Instruktion, die eine exception verursacht. Da der "RISC"-Kern diese in mehrere Sub-Instruktionen aufspaltet, wird die Exception von einer dieser Sub-Instruktionen ausgelöst, muss aber der gesamten "CISC"-Instruktion zugerechnet werden. Die Ausführung der anderen Sub-Instruktionen, sofern bereits erfolgt, muss rückgängig gemacht werden.

Beispiele:
1)
;"CISC"
INC dword [invalid_address]

;=> "RISC"
MOV R0,dword [invalid_address]
ADD R0,1
MOV dword [invalid_address],R0

Btw ist die nach "RISC" übersetzte Instruktion zwingend in-order auszuführen. Es geht nicht anders. Jede Sub-Instruktion ist von der vorherigen abhängig.

Szenario 1.1: Die Adresse ist nicht verfügbar. Unkritisch. Die erste Sub-Instruktion wird bereits eine Exception verursachen.
Szenario 1.2: Die Adresse darf zwar geschrieben, aber nicht gelesen werden. Exotisch, und unkritisch. Gleiche Argumentation wie 1.1.
Szenario 1.2: Die Adresse darf gelesen werden, aber nicht geschrieben. Ebenfalls unkritisch. Die Exception erfolgt zwar erst "in Zeile 3", aber zu diesem Zeitpunkt wurde der externe Speicher noch nicht verändert.

Demzufolge gibt es bei dieser Instruktion, ganz egal was schiefläuft, keinerlei Bedarf für Wiederherstellungsmechanismen.

2)
;"CISC"
MOVSD

;=> "RISC"
MOV R0,dword [DS:ESI]
MOV dword [ES:EDI],R0
ADD ESI,1 ;der "Trick"
ADD EDI,1

Das ganze läuft hier ähnlich ab wie Beispiel 1.
Der Unterschied ist nun, dass Sub-Instruktion #3 nicht wirklich von Sub-Instruktion #2 abhängig ist. Ein OOOE-Core könnte auf die Idee kommen, die Sub-Instruktion #3 vor der #2 auszuführen. Wenn Sub-Instruktion #2 eine exception auslöst, dann gäbe es hierbei tatsächlich Bedarf für "roll back".

Die eleganteste Lösung dieses Problems ist es nun, einfach eine "falsche" Abhängigkeit zwischen #2 und #3 in den Microcode einzubasteln. Und der Prozessorkern, sofern er OOOE beherrscht, kann das auch, die Mechanismen dafür sind sowieso schon im Design verankert. Dadurch wird die Umsortierung verhindert, und es gibt keine Probleme durch eine evtl auftretende exception bei Sub-Instruktion 2.

Das kostet natürlich ein wenig Performance, weil der Scheduler dadurch nicht alle Befehle so umsortieren kann, wie es im Falle ohne exceptions möglich wäre.

Diese Restriktion kann man umgehen, indem man MOVS* nicht benutzt, und stattdessen Loads und Stores diskret ausführt.
Dies wird btw auch von AMD empfohlen. MOVS* soll man nur für Blöcke mit maximal 64 Bytes einsetzen, für alles darüber werden eben diese "discrete moves" empfohlen.
Siehe im passenden AMD-Manual (PDF) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF) Kapitel 5.11.

Würde mich nicht wundern, wenn das uA auch an dem liegt, was ich hier ausgeführt habe.

[Vedek Bareil]

eine Frage in diesem Zusammenhang mal...

ich habe gelesen, man kann eine komplexe Operation (z.B. Addition oder Multiplikation zweier 32-bit-Zahlen) einerseits durch ein festverdrahtetes Schaltnetz realisieren und andererseits durch ein programmierbares logisches Array (PLA).

Der Nachteil des festverdrahteten Schaltnetzes ist, daß es nur eine ganz bestimmte Operation kann, und nichts anderes. Ein Prozessor, der viele unterschiedliche Operationen beherrschen soll, müßte demnach ganz viele solcher Schaltnetze enthalten, für jede Operation eines.

Das PLA dagegen hat den Vorteil, daß viele (alle?) Operationen mit einem einzigen Schaltnetz durchgeführt werden können, weil dieses eben programmierbar ist. Je nachdem, auf welche Operation es gerade programmiert ist, kann es die Funktionalität eines entsprechenden festverdrahteten Schaltnetzes realisieren (emulieren?). Dafür ist es dann aber ggf. langsamer als ein festverdrahtetes Schaltnetz.

Nun meine Frage: besteht das Konzept von CISC gerade in der massiven Verwendung von PLAs? Daß also für die Vielzahl der im Befehlssatz enthaltenen Operationen ein PLA eingesetzt wird, das je nach Programmierung jede der vielen Operationen ausführen kann? Weil aufgrund der schieren Vielzahl an Operationen ein festverdrahtetes Schalnetz pro Operation nicht realisierbar wäre, da die Chipfläche viel zu groß würde?

Und ist die Idee hinter RISC umgekehrt die, statt auf PLAs auf festverdrahtete Schaltnetze zu setzen? Und daß man die Zahl der im Befehlssatz enthaltenen Operationen deswegen auf ein Minimum reduziert, damit man für jede Operation ein eigenes Schaltnetz einbauen kann, ohne daß die Zahl der Schaltnetze und damit die Chipfläche aus allen Nähten platzen?

Oder hat CISC vs. RISC mit PLA vs. Festverdrahtung gar nichts zu tun, und das sind zwei völlig unterschiedliche Dinge? Irgendwie fand ich die Frage noch nirgendwo so recht beantwortet...

Ach ja, und ist die Programmierung eines PLAs eigentlich das, was man Mikroprogrammierung nennt? Oder ist das wieder was ganz anderes?

[zeckensack]

<...>
Oder hat CISC vs. RISC mit PLA vs. Festverdrahtung gar nichts zu tun, und das sind zwei völlig unterschiedliche Dinge? Irgendwie fand ich die Frage noch nirgendwo so recht beantwortet...Hat nichts damit zu tun ;)
Bei "großen" Prozessoren setzt man, der Geschwindigkeit wegen, auf festverdrahtete Logik und Microcode, um diese Logik flexibler einsetzen zu können. Integerdivision löst man zB idR mit Microcode, der dann die festverdrahteten Addierer und Bitshifter nutzt. So spart man sich dedizierte Divisionshardware. Für FP nutzt man gerne statt "komplexer" Ausführungseinheiten ROMs um Newton-Rhapson-Iterationen mit Parametern zu versorgen, etc.

Die eigentlichen Ausführungseinheiten sind aber alle festverdrahtete Logik. Btw, soo viele sind das garnicht. Wenn zB das (56kers beware) (http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html) ein verlässlicher Maßstab ist, dann belegen beim K8 die Ausführungseinheiten nur knapp 20% der Fläche (L2-Cache bereits rausgerechnet).

Rekonfigurierbare Gatter können hier höchstens Platz sparen, aber nur unter der Voraussetzung dass du insgesamt weniger "gleichzeitig verfügbare" Ausführungseinheiten vorsiehst. Aber möglichst schnell möglichst viele Instruktionen parallel auszuführen ist ja gerade das Motto!
Bei gleicher Menge an Ausführungsressourcen ist das kontraproduktiv, weil du dir durch die Konfigurierbarkeit weiteren Overhead in Form von Fläche einfängst. Bei kleinerer Menge ist es ebenfalls kontraproduktiv, weil du Durchsatz opferst.

Ach ja, und ist die Programmierung eines PLAs eigentlich das, was man Mikroprogrammierung nennt? Oder ist das wieder was ganz anderes?Mikroprogrammierung ist mir nicht geläufig. Microcode, evtl?
Microcode ersetzt einfach im Decoder einzelne Instruktionen aus dem (Instruktions-)Speicher durch mehrere andere Instruktionen. Letztere sind nur für "interne" Benutzung, haben als mit der nach außen sichtbaren ISA nicht zwingend etwas zu tun, können auf evtl vorhandene "unsichtbare" Scratch-Register zugreifen, brauchen keine Abwärtskompatibilität uä, und können dadurch modellspezifisch optimal gemacht werden.

Microcode wurde schon lange vor der aktuell laufenden "Post RISC"-Ära eingesetzt. IMO war zB spätestens der 486er der erste Intel-Desktop-Prozessor, der davon massiven Gebrauch machte. Dafür braucht man wenig mehr als ein ROM (das die internen Instruktionssequenzen vorhält) und eine kleine "Weiche"/Handbremse im Decoder.



Aber einen Gedankengang möchte ich noch aufgreifen:
Die ursprüngliche "RISC"-Idee war, möglichst wenig unterschiedliche Ausführungseinheiten zu haben. In letzter Konsequenz würde man zum Beispiel die Ausführungseinheit für Integermultiplikation rausschmeißen, und vom Compiler verlangen, sowas auf eine Serie von Bitshifts und Additionen abzubilden. So weit muss man natürlich nicht gehen, nur praktischere Beispiele wären mir jetzt zu subtil gewesen ;)

"CISC" dagegen -- und man kann es nur dagegen betrachten, weil es den Begriff ursprünglich garnicht gab, der wurde erst erschaffen damit die "RISC"-Fraktion ihren Gegenpol beim Namen nennen kann -- kann eben die wildesten Sachen in einer Instruktion darstellen, und hielt sich damit die Tür offen, diese wilden Sachen auch auf einer dedizierten Funktionseinheit zu erledigen.

ZB hat x86 einen ganzen Haufen Instruktionen für BCD<=>ASCII-Konvertierung, und anderes, ähnlich grenzwertiges Gerumpel.

[aths]

ZB hat x86 einen ganzen Haufen Instruktionen für BCD<=>ASCII-Konvertierung, und anderes, ähnlich grenzwertiges Gerumpel.Wenn man tatsächlich mal was kleines in ASM machen muss, findet man solche Befehle aber gut.

[mrdigital]

Du machst Stringverarbeitung in ASM?

[Coda]

Wenn man tatsächlich mal was kleines in ASM machen muss, findet man solche Befehle aber gut.
Also das BCD Zeugs kommt noch aus der Zeit als x86 in Taschenrechnern eingesetzt wurde und wird wirklich nur noch für sehr sehr esotherisches Zeugs verwendet.
Ich bin auch beim ASM schreiben nie auf die Idee gekommen das zu benützen, vor allem weil es beim Athlon eh alles Vectorinstructions sind (lahm) und beim P4 wird sich's ähnlich verhalten. Das geht bei dem sicher durch die Slow-ALU.
Im x86-64 Modus is das Zeug rausgeflogen.