RISC oder CISC - Was ist besser?

Fragen, die so einfach ins Blaue hinein gehen, haben wenig Sinn.

Sammle ein wenig Programmiererfahrung, dann weißt du wenigstens,
worüber du redest.

www.gidf.de gibt dir die Antwort. Einfach "RISC CISC" eingeben.

>Fragen, die so einfach ins Blaue hinein gehen, haben wenig Sinn.

Was heisst da ins blaue hinein??

Ich hab noch nie gehört, dass jemand seien uP nach RISC oder CISC 
ausgesucht hat. Deshalb frag ich obs überhaupt draufan kommt!

Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht 
erfolgreich zu sein. Zumindest bei MS-Maustreibern.

>Beim Programmieren musst Du gar nichts beachte, solange Du eine höhere
>Programmiersprache benutzt. RISC hat eben einen Reduzierten Istruction
>Set, arbeitet dafür Befehe meist in einem Takt ab. CISC hat mächtigere
>Befehle, die dafür öfter gerne einige Takte brauchen. Ich hoffe das
>reicht erst mal. Wikipedia hat sicher mehr dazu zu sagen.

Ja danke, ich weiss schon was RISC und CISC ist. Ich frag mich nur was 
unter dem Strich besser ist.


>Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht
>erfolgreich zu sein.

Das x86 erfolgreich ist muss doch überhaupt nichts damit zu tun haben ob 
RISC oder CISC besser ist. Hat ich einfach als Standard durchgesetzt.

>Was heisst da ins blaue hinein??

Auf diese Frage gibts eine gute Antwort:

>Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht
>erfolgreich zu sein. Zumindest bei MS-Maustreibern.

Hier kommt das "ins Blaue hinein" sehr deutlich zum Ausdruck.

>Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht
>erfolgreich zu sein. Zumindest bei MS-Maustreibern.

Erstens ist ein großer Teil der Transistoren Cache, hat also mit 
CISC/RISC erstmal nichts zu tun. Zweitens kann man heutige x86er nicht 
genau einordnen, weil sie nur noch die ISA (Instruction Set 
Architecture) mit ihren CISC Vorfahren gemeinsam haben. Intern läuft es 
dann doch wieder RISC-artig ab. Wie so oft sind die Übergänge fließend.

der trend geht klar richtung risc... somit dürfte die frage wohl 
beantwortet sein...

--> der x86 stammt ursprünglich von einem cisc ab und wurde richtung 
risc vergewaltigt... sprich sie haben gebastelt, weil sie die kosten für 
eine kommplete risc neuentwicklung scheuten...

Kann man so wirklich nicht sagen. Nur schon die Definition von 'besser' 
ist schwer. Rechenleistung? Stromverbrauch? Leichter Vorteil
Einfachheit beim Design? Einfachheit in der Produktion? Flexibilität?

Und definiere mir dann mal RISC* und CISC* präziser. Wie vergangene 
Diskussionen zeigen, kann man hier nach verschiedenen Gesichtspunkten 
die Grenze ziehen, moderne PC-Prozessoren sind teilweise kaum 
einzuordnen.

Grundsätzlich ist jedes CISC* auch ein bisschen RISC*, wobei halt noch 
der Mikrocode dazwischen steht.


* Ich definiere für mich RISC und CISC rein nur über die 
Hardware-Implementierung, nicht über den Instruktionssatz. RISC: Daten 
rutschen nach einem vorgegebenen Schema durch die CPU, insbesondere sind 
die einzelnen Komponenten direkt und eigenständig verdrahtet, so dass 
Pipelining möglich wird. CISC: Daten werden vom Mikrocode Schritt für 
Schritt an die verschiedenen Komponenten angelegt, wobei insbesondere 
allgemeine Bus-Strukturen vorkommen können und erst der Mikrocode 
bestimmt, welche Prozessorkomponente ihre Daten anlegt bzw. übernimmt.

> Kann man generell sagen das entweder RISC oder CISC - Architektur besser
> ist?

Hängt von der Anwendung ab. Bei CISC hat man meist bessere Codedichte, 
RISC ist üblicherweise schneller, da die Decoder- und 
Ausführungseinheiten einfacher zu realisieren sind.

Im Mikrocontrollerbereich sind echte RISCs selten, da die meisten immer 
noch die Möglichkeit haben irgendwie direkt die Portpins zu 
manipulieren, was dem RISC-Konzept komplett widerspricht.

Es ist aber klar, daß alle heutigen Prozessoren, wenn sie auch nur 
annähernd in der Geschwindigkeit mithalten, intern immer eine 
RISC-ähnliche Implementierung haben, ganz gleich wie CISC-mäßig die 
Architekur sein mag. Das gilt vor allem für die CPUs von Intel und AMD, 
denn wenn die nicht RISC-Know-How für ihre Prozessorkerne übernommen 
hätten (und etwas später noch sehr viel Optimierungswissen in Form von 
ehemaligen Alpha-Designern eingekauft hätten), wären sie schon vor 
Jahren im Desktop- und Server-Bereich von den RISC-Prozessoren abgehängt 
worden.
Da sich x86 aber aufgrund der etablierten Architektur sehr gut verkauft, 
war wohl genug Geld für Investitionen und den Aufwand der Übersetzung 
einer verkorksten ISA in RISC-ähnliche Code für den Kern vorhanden.

Da der Begriff RISC gerne nicht vollkommen korrekt ausgelegt wird, hier 
noch eine genauere Definition:
"RISC" steht zwar für "Reduced Instruction Set Computer", aber ganz so 
wörtlich darf man dieses Akronym von David Patterson doch nicht 
auslegen, da seine Definition doch deutlich anders aussieht.
(In einem Buch habe ich die alternative Interpretation "Reduced 
Instruction Set Complexity" gefunden.)

* Load/Store-Architektur, d.h. nur spezielle Load/Store-Instruktionen 
sind für den Datenaustausch zuständig. Alle Datenmanipulationen finden 
ausschließlich auf Registern statt. Hier unterscheiden sich einige 
Embedded-RISC (beispielsweise SuperH kann Bitoperationen auf 
Speicherstellen durchführen), damit man direkt auf Ports zugreifen kann.

* Eine große Zahl an Universalregistern. Groß ist dabei relativ, 
üblicherweise aber ab 16 aufwärts, die meisten Desktop-RISCs haben 32 
Register, von denen aber häufig eines immer Null ist. Universalregister 
heißt dabei, daß sie gleichermaßen für Daten und Adressen und von allen 
Instruktionen verwendet werden können. Zugunsten der Codedichte machen 
einige Embedded-RISC hier auch Eingeständnisse.

* Uniforme und einfache Instruktionscodierung. D.h. alle Instruktionen 
haben die gleiche Länge und es gibt nur sehr wenige Instruktionsformate. 
Ein "typischer" RISC käme beispielsweise mit drei Formaten aus: Opcode 
mit drei Registern, Opcode mit zwei Registern und einer Konstante, 
Opcode und Adresse.
In der Praxis sieht das gelegentlich auch etwas anders aus. ARM hat 
erstaunlich viele unterschiedliche Formate und bei der Länge ist man 
auch nicht immer einheitlich. ARM schaltet zumindest zwischen Modi mit 
unterschiedlichen Längen um (32-Bit ARM / 16-Bit Thumb), andere wie 
TriCore können auch verschieden lange Instruktionen mischen.

* Die meisten Instruktionen sind primitiv genug, daß mittels Pipelining 
eine Instruktion pro Zyklus fertiggestellt werden kann. Aus diesem Grund 
hatte der erste SPARC übrigens auch keine Multiplikation und Division, 
was aber später aus Performanzgründen nachgeflickt wurde.
Hierbei ist wichtig, daß keine CPU eine Instruktion in einem Taktzyklus 
ausführen kann; es sind immer mehrere Schritte nötig. Wenn man aber 
nicht alle Instruktionen nacheinander ausführt, sondern die einzelnen 
Schritte jeder Instruktion um eins versetzt in einer Art Fließband 
(Fachausdruck "Pipeline") berabeiten, kann man im Idealfall eine 
Instruktion pro Taktzyklus abschließen. Das setzt allerdings voraus, daß 
die Instruktionen alle eine ähnliche Anzahl an Einzelschritten haben, 
weswegen sie möglichst primitiv sein sollten.
Ein typisches Gegenbeispiel hierfür ist der PowerPC, der für RISC einige 
viel zu komplexe Instruktionen hat. Das Laden und Speichern von mehr als 
einem Register in einer Instruktion ist allerdings auch in ARM 
vorhanden. Aus diesem Grund arbeitet übrigens die Implementierung des 
PPC970, der im Vergleich zu den anderen PowerPCs eine deutlich tiefere 
Pipeline hat, intern mir "cracked instructions", d.h. komplexe 
Instruktionen werden in zwei oder mehr primitivere zerlegt. Das Konzept 
erinnert natürlich sehr stark an die Micro-Ops von Intel.

* In der Originaldefinition von David Patterson war auch noch die 
Implementierung von sog. Registerfenstern vorhanden, aber abgesehen von 
SPARC, die von diesem Berkeley-RISC-Projekt abgeleitet wurde, hat das 
eigentlich keine andere Architektur übernommen.

Es handelt sich also hierbei im rein architektonische Vorgaben, die eine 
möglichst effiziente Implementierung erleichtern sollen. Ein Verzicht 
auf Mikrocode wird in keinster Form gefordert, mir ist aber auch kein 
RISC bekannt, der nicht überwiegend hardcodiert wäre.

Ein x86 fällt aus architektonischer Sicht definitiv nicht ins 
RISC-Raster. Instruktionslängen die zwischen 1 und 16 Byte schwanken und 
teilweise äußerst komplex codiert sind. Immer noch keine echten 
Universalregister, da EAX als ehemaliger Akkumulator codierungstechnisch 
bevorzugt wird, variable Shiftweiten nur in CL stehen dürfen, 
Multiplikation/Division implizit EAX/EDX verwenden, etc. pp.
Beim Pentium werden die 8 Pseudo-Universalregister intern auf 40 
Register umverteilt und die Instruktionen in Micro-Ops zerlegt, damit 
sie einigermaßen effizient in einer Pipeline ausgeführt werden können.

Rein von der Geschwindigkeit hat RISC aus meiner Sicht deutliche 
Vorteile gegenüber einem reinen CISC, was sich alleine daran zeigt, daß 
die wirklich schnellen Prozessoren intern alle auf eine Form von RISC 
zurückgreifen.
Für den Embedded-Bereich ergeben sich Nachteile bezüglich der Codedichte 
oder dem direkten Zugriff auf Ports, weswegen hier meist gewisse 
Abweichungen von der originalen RISC-Definition finden lassen.

Was ist besser - Apfel oder Birne?

Pflaume!

...ist besser.