Diskussion:Reduced Instruction Set Computer

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 21 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

RISC schneller als CISC?

Hallo Leute, ich bin kein Fachmann, darum stelle ich mal diese provokante Frage an die fachkundigen Leser. Ist ein RISC-Prozessor wirklich schneller als ein CISC-Prozessor? Und ich meine nicht die theoretische Geschwindigkeit, wenn der Prozessor nur NOPs ausführt, sondern die praktische Geschwindigkeit im realen Einsatz. Gibt es dazu irgendwelche Zahlen, die die eine oder andere Behauptung stützen?

>RISC-Prozessoren sind vor allem in der Praxix erheblich schneller! Beispielsweise ist der MEGA8 von Atmel nach eigenen Messungen etwa 20-mal schneller als der 8085 von Intel. Beides sind 8-Bit-Prozessoren mit 8 MHz Taktfrequenz.

Dadurch, dass die Befehle sehr primitiv sind, kann ein Befehl pro Taktzyklus gemacht werden (außer beim Speicherzugriff). Bei CISC-Prozessoren werden i.d.R. mehrere Taktzyklen (Typ. 4-8) benötigt, so dass ein RISC-Prozessor bei gleicher Anzahl an Befehlen und gleicher Taktfrequenz etwa 4-8 mal schneller ist. Durch die geringere Anzahl an Transistoren (Beispiel: ARM gegen 680x0: Faktor 3-10) kann der RISC-Prozessor auch schneller getaktet werden, da die Chipfläche kleiner ist und dadurch die internen Leiterbahnen kürzer sind. Da für einen RISC-Prozessor mehr Befehle benötigt werden als für einen CISC-Prozessor, verlangsamt sich die Ausführung eines Programms wieder etwas, allerdings ist die Geschwindigkeit immer noch höher als bei CISC. --Mr1278 (Diskussion) 18:54, 27. Jun. 2013 (CEST)

Der Befehlssatz von RISC-Prozessor ist ja vor allem eines: primitiv.

>Das hat die Folge, dass man mehr Befehl schreiben muss, um die gleiche Aufgabe zu erledigen. In Assemblersprache ist das lästig, bei einem C-Compiler erledigt das ein Programm und man merkt nichts davon.

Während ein moderner CICS-Prozessor allerlei Funktionen für das Arbeiten mit Gleitkommazahlen bereitstellt, muss man das beim RISC-Prozessor alles von Hand programmieren. Nun weiss ich zwar so spontan nicht, wie man eine Logarithmusfunktion in Assembler programmiert, aber es fällt mir schwer zu glauben, dass das Ergebnis schneller sein soll als der entsprechende Befehl einer CISC-FPU. Das gleiche gilt analog für alle anderen Gleitkommaoperationen.

Die FPU ist bei den meisten Prozessoren außerhalb des CPU-Kerns angesiedelt. Daher stellen streng genommen weder RISC- noch CISC-CPUs irgendwelche Gleitkommabefehle zur Verfügung. Beide CPU-Typen reichen die Gleitkommabefehle lediglich an die FPU weiter. Die ARM-Architektur (RISC) verfügt über die Möglichkeit der Anbindung einer FPU. --Mr1278 (Diskussion) 18:54, 27. Jun. 2013 (CEST)

>Dafür gibt es fertige Bibliotheken, damit nicht jeder das Rad neu erfinden muss. Da wird ein ganzer Programmblock aus etwa 10000 Befehlen eingesetzt. Unabhängig davon gilt: Diese sehr vielen Befehle werden deutlich schneller durchlaufen als bei einem CISC von Intel.

Jetzt braucht man vielleicht nicht ständig Gleitkommaoperationen, aber auch bei allen anderen Kommandos gilt doch: wofür ein CISC-Prozessor ein komplexes und zugegebenermassen etwas langsameres Kommando hat, muss man beim RISC-Prozessor meist mehrere Kommandos verwenden, um den gleichen Zweck zu erreichen. Kann das tatsächlich effektiver sein?

>Das IST effektiver! Ich programmiere seit Jahren - in letzter Zeit nur noch RISK.

Soll das wirklich bedeuten, dass es die Entwickller von CISC-CPUs nicht schaffen, ein komplexes Kommando mindestens genauso effektiv in Hardware zu giessen, wie dies jeder beliebige Programmierer einer RISC-CPU in seinem Programm kann? Ich kann mir das ehrlich gesagt nur schwer vorstellen. Kann das vielleicht irgendjemand mit Zahlen und Fakten untermauern?

>Das "in hardware giessen" hat den sehr großen Nachteil, dass dann EIN Befehl entsteht, der nicht unterbrochen werden kann. Wenn dieser Befehl 1 ms dauert, können während dieser Zeit keine Interrupts erledigt werden. Bei praktischen Anwendungen warten dann beispielweise fünf Interrupts viel zu lange und der gesamte Zeitplan kommt durcheinander (Die Maschine reagiert nicht oder zu spät). Bei RISK gibt es keinen Befehl, der länger als 0,0005 ms dauert. Da wird jeder Interrupt ohne nennenswerte Verzögerung behandelt. Herbertweidner 13:06, 27. Nov. 2007 (CET)

Die Antwort auf "was ist schneller" ist schwieriger als man denkt. RISC wurde 1970 "erfunden", und 40 Jahre später gibt es im Prozessormarkt zwar keinen einzigen CISC-Chip mehr (Intels x86/Pentiums/Cores sind RISC-Kerne mit umgebender CISC-Emulations-Hülle, AMD genauso, PowerPC ist RISC, Arm auch, ...), aber die CISCs sind wieder stark am Kommen: MPeg-Dekodierung in Hardware, festverdrahtete Grafikroutinen auf "General Purpose Graphics Processing Units" soll man via CUDA/OpenCL zum Rechnen verwenden, jedes Handy hat 'nen Grafikbeschleuniger mit Festverdrahtung komplexer Operationen - der Kampf ist nicht entschieden *g* --arilou 15:55, 11. Mai 2011 (CEST)

"Festverdrahtete" Routinen deuten eher auf RISC hin als auf CISC, denn eines der Merkmale von RISC ist das Fehlen von Microcode (Ein Befehl pro Zyklus). Allerdings hört sich für mich "festverdrahtet" eher wie mit HDL entworfene ASICs an, die mit Prozessoren nichts zu tun haben (weder CISC noch RISC). Bei vielen Videoprozessoren weiß ich, dass es sich eigentlich nicht um Prozessoren, sondern um ASICs handelt. --Mr1278 (Diskussion) 18:54, 27. Jun. 2013 (CEST)

RISC und CISC sind abstrakte Konzepte und als solche weder schnell noch langsam. Wenn überhaupt kann man nur spezielle Prozessoren miteinander vergleichen, aber auch das ist komplizierter als man vielleicht annehmen sollte. Ich denke auf solche Diskussionen sollten wir uns hier daher gar nicht erst einlassen. Die Wikipedia ist ein Nachschlagewerk und wir sollten uns daher auf belegbare Fakten beschränken und alles andere weglassen.

PS: Nicht alle x86-Kerne haben einen RISC-Kern. AMDs Opteron und Intels Atom haben z.B. keinen. Also Vorsicht mit Verallgemeinerungen!

--Stefan B 00:10, 12. Mai 2011 (CEST)

Ähm, gemäß [1] :

• Intel Atom, S.128: "pipeline has sixteen stages", "Instructions of the read-modify or read-modify-write type are handled as a single µop. Only more complex instructions are split into µops."
• AMD (auch Opteron), S.141ff: "Each read-modify macro-instruction is split into a read and a modify micro-instruction in the execution stage", "A 'macrooperation' in AMD terminology is somewhat similar to a 'fused micro-operation' in Intel terminology.", "Read-modify and read-modify-write macrooperations are split into micro-operations that go to different units and at different times in the out-of-order core."

Soweit ich das überflogen hab', ist AMD zwar nicht richtig deutlich RISC, aber noch viel weiter von einem CISC-Design entfernt;

Beim Intel Atom sind "mehrere µOPs" näher an RISC als an CISC-Microcode, der ja Schleifen, Sprünge, Unterprogramme kennt.

Also, soweit ich das sehe, sind weder Atom noch Opteron CISC, wenn auch wohl beide keinen "reinen" RISC-Kern besitzen.

--arilou 11:50, 12. Mai 2011 (CEST)

Beide haben interne Befehlsformate, die ganz klar kein RISC sind. (u.a. keine Load-Store-Architektur und komplexe Adressmodi) Bei AMD heißen sie nicht umsonst Macro-operations. Siehe z.B. diesen Beitrag von Mitch Alsup. (Mitch Alsup war der Chefentwickler von Motorolas RISC-Linie und hat 2004 für AMD gearbeitet, der Mann weiß also, wovon er spricht.)

RISC ist, wie der Name schon sagt, zuallererst eine Klassifikation von Befehlssätzen.

--Stefan B 13:51, 12. Mai 2011 (CEST)

balanced

Schon in der Einleitung wird von "balancierter Pipeline" geredet - meine OMA hat keine Ahnung, was bei Maschinencode "balanciert" bedeuten soll - vielleicht 'n kleines Nebensätzchen zur Verdeutlichung? --arilou 15:59, 11. Mai 2011 (CEST)

Ich habe es herausgenommen. In der Einführung geht es ja gerade darum Leute, die nichts mit dem Begriff anfangen können, eine kurze Einordnung zu geben. Die Vorzüge der balancierten Pipeline werden ja weiter unten noch erläutert. --Stefan B 23:45, 11. Mai 2011 (CEST)

Praktische Bedeutung – Systeme mit RISC CPU

Ich denke dieser Abschnitt sollte drastisch gekürzt werden. Er nimmt fast die Hälfte des ganzen Artikels ein! Es ist einfach nicht sinnvoll, hier alle Geräte mit RISC-Prozessoren aufzuzählen. Beim Dieselmotor werden schließlich auch keine Automodelle aufgeführt. Wenn die Geräte so wichtig sind, dass sie unbedingt in der Wikipedia erwähnt werden müssen, dann in einem eigenen Artikel oder im Artikel des jeweiligen Prozessors. Das wird sonst einfach zu lang und unübersichtlich. --Stefan B 00:15, 12. Mai 2011 (CEST)

Ich hoff' mal, die Liste getrennt nach RISC-Familien und die Beispiele im Anhang gefällt jetzt deutlich besser ;-) --arilou 10:52, 13. Mai 2011 (CEST)

Na und ob! Jetzt kann man es tatsächlich lesen!

Was machen wir mit dem vorherigen Abschnitt Vergleich zu CISC? Tatsächlich steht da ja gar nichts (!) zum Vergleich mit CISC, sondern eher etwas zur praktischen Bedeutung. Das ist jetzt irgendwie doppelt. Meinetwegen können wir den ganzen Abschnitt löschen... --Stefan B 15:39, 16. Mai 2011 (CEST)

PS: Und die Prozessoren, die nicht mehr hergestellt werden, erwähnen wir besser in der Rubrik Geschichte. ;-) --Stefan B 15:49, 16. Mai 2011 (CEST)

Abbildung entfernt

Ich habe die Abbildung wieder rausgeschmissen, weil:

• Sie offenbar von hier geklaut ist?!?!
• Die Qualität sehr schlecht ist, man kann selbst bei bestem Willen kaum etwas erkennen! JPEG ist einfach nicht das richtige Format für Diagramme.
• Das Diagramm zu komplex ist, und im Artikel auch nicht weiter erwähnt oder erläutert wird. So werden die Leute nur unnötig verwirrt.
• Der abgebildete Prozessor (ein PA8800 von 2003) ein hochkomplexer, superskalarer Out-of-Order-Prozessor ist, bei dem es kaum noch eine Rolle spielt, ob er nun einen RISC-Befehlssatz besitzt, oder nicht. Wenn schon eine Abbildung, dann eine einfache Pipeline mit fünf Stufen, und einer entsprechenden Erläuterung im Text.

Die Idee eine Abbildung einzufügen ist natürlich sehr gut. Aber dann sollte man sich die Zeit nehmen, es richtig zu machen. Also nichts für ungut... --Stefan B 23:13, 29. Aug. 2011 (CEST)

Verbesserungspotential

Hab' mir mal alle Änderungen seit meiner letzten angeschaut:

• "Registersätze/Fenster" - gibt es nicht auch sowas wie "Hyper-Threading", dass mehrere (z.B. 8) Threads/Prozesse getrennte Registersätze haben, so dass der Prozessor(kern) beim Prozesswechsel nur den Satz umschalten muss? Dieser Aspekt ist bei obiger Bearbeitung rausgeflogen - ein Unterprogramm-Call ist kein Prozesswechsel.

--arilou 08:55, 30. Aug. 2011 (CEST)

Es geht um typische Eigenschaften von RISC-Prozessoren, nicht darum was theoretisch möglich wäre. In diesem Abschnitt sollte also nur aufgeführt werden, was auch wirklich in mehr als einem RISC-Prozessor umgesetzt wurde.

Hyper-threading ist Intels Version von SMT (Simultaneous Multi-Threading), dabei werden a) keine Registersätze umgeschaltet und b) ist es transparent für die Software, denn die sieht nur mehrere (virtuelle) Prozessoren. SMT hat also nichts mit dem Befehlssatz zu tun. --Stefan B 13:38, 30. Aug. 2011 (CEST)

1. Ich denke mich zu erinnern, dass es SPARCs gab mit hardwareseitigem Multithreading, was aber noch nicht(!) SMT war. Dazu hatten sie zusätzlich zu ihrer Technik "24-Register-Fenster-auf-128-Register" mehrere 128-Register-Sätze, damit das Betriebssystem zwischen verschiedenen Prozessen schnell umschalten kann, ohne Register umladen zu müssen. Dafür braucht das OS natürlich (protected mode) Befehle. Und wenn mehr Prozesse rechnen wollten, als die (waren's 8 ?) vorhandene Anzahl Registersätze, dann musste eben doch umgeladen werden.

Möglich, dass das nicht "typisch" für RISCs ist, und nur in wenigen implementiert war. Aber auch SMT ist RISC-typisch, und wurde durch deine Änderung ebenfalls ausgeschlossen.

2. Ähm, erklär' mir bitte mal, wie Intels Hyperthreading, bei dem 1 CPU-Kern zwei Prozesse(!) gleichzeitig bearbeitet, diese beiden Prozesse ohne zwei getrennte Registersätze bearbeiten will. Es muss für jeden Befehl mitgeführt werden, für welchen Prozess/Registersatz er gilt, und das Rechenergebnis muss auch wieder im richtigen Satz abgelegt werden. Irgendwo muss da, bei (fast) jedem Befehl, umgeschaltet werden, gelt?

3. Zum Punkt "hat nichts mit Befehlssatz zu tun" - nja, hardwareseitiges Multithreading bzw. SMT direkt nicht - trotzdem muss seltener Register<->Ram Umladen (Prozesswechsel) gemacht werden, je mehr Registersätze vorhanden sind. Das spürt das OS auch ohne explizite SMT-Befehle, und v.a. ob es überhaupt nur einen oder mehrerer Registersätze gibt, hat durchaus Änderungen im OS-Scheduler zur Folge, gelt?

Außerdem wurde in dem angesprochenen Absatz vor deiner Änderung nichts vom Befehlssatz gesagt, sondern dass dies Hardware-Eigenschaften seien (da gibt's auch solche, die sich nicht in Befehlen niederschlagen...) .

--arilou 08:57, 31. Aug. 2011 (CEST)

Diese Art der Diskussion führt zu nichts. Informiere Dich bitte, mach konkrete, ausformulierte Änderungsvorschläge und führe entsprechende Quellen an, dann sparen wir uns beide diese endlosen Diskussionen und können unsere Zeit in den Artikel investieren, z.B. in eine brauchbare Abbildung mit einer kurzen Erläuterung. --Stefan B 15:43, 31. Aug. 2011 (CEST)

• "Compiler-Verbesserungen" - die hinzugefügten Compiler-Verbesserungen sind alle(!) solche, die gerade auch auf CISCs gut funktionieren, und damit eher ungeeignet als Beispiel-Argumente pro-RISC. Ich plädiere für: wieder weg damit.

--arilou 08:55, 30. Aug. 2011 (CEST)

Das ist nicht richtig. Lies einfach mal "George Radin: The 801 Minicomputer". Wenn Du keine Uni-Bibliothek in der Nähe hast, kann ich Dir den Artikel auch gerne per Email schicken.--Stefan B 13:38, 30. Aug. 2011 (CEST)

• "Windows 8 gibt's auch für ARM" - was hat das jetzt mit RISC zu tun? Es gibt alle möglichen Betriebssysteme für alle möglichen Prozessoren...

--arilou 08:55, 30. Aug. 2011 (CEST)

Dieser Eintrag ist nicht von mir. Es geht dabei aber um die Zukunftschancen von ARM (und RISC) auf dem Desktop. Es ist also nicht irrelevant. --Stefan B 13:38, 30. Aug. 2011 (CEST)

Ich kritisier' ja auch nicht dich, sondern die Änderung ;-)

Zukunftschancen von ARM bitte im dortigen Artikel; unterstützte Prozessor(architekturen) von Win8 bitte im Win8-Artikel; wenn's um "RISC auf dem Desktop" geht, dann muss der Satz das (deutlich) anders ansprechen, evtl. wär' dann ein ganzer Abschnitt "RISC-Technologie im Arbeitsplatz-PC" o.ä. sinnvoll.

--arilou 08:57, 31. Aug. 2011 (CEST)

Quellen zur OpenRISC-Architektur

Hier noch eine Quelle zur OpenRISC-Architektur (für einen möglichen eigenständigen WP-Artikel):

• Die Neuerungen von Linux 3.1: Architektur und Infrastruktur – Artikel (Seite 2) bei Heise open, vom 24.10.2011
• Linux: Kernel 3.1 erhält NFC-Subsystem – Artikel bei Golem.de, vom 24.10.2011

Das sind zwar auch nur ein paar Mosaiksteinchen, aber immerhin.. :-) MfG, 92.231.186.164 13:34, 25. Okt. 2011 (CEST)

Ein eigener Artikel zu OpenRISC und OpenCores wäre sehr schön, ich selbst habe im Moment aber leider keine Zeit. Die englische Wikipedia hat schon Einträge zu OpenRISC, OpenRISC 1200 und OpenCores. Dort sind die wichtigsten Daten und Links zu finden. Zur Not könnte man die Seite auch erstmal einfach ins Deutsche übersetzen. --Stefan B 07:47, 27. Okt. 2011 (CEST)

Irgendwie ist der aktuelle Link auf OpenRISC (de:) murksig, da er via Weiterleitung wieder hier im Artikel landet. Ich bin kein Wiki-Profi, koennte mir aber vorstellen, dass solche Linkschleifen eher unerwuenscht sind. Dass ich draufgeclickt habe, laesst zu Recht vermuten, dass ich mir auch einen solchen Artikel wuensche ;-) -- BromeliaBorealis (Diskussion) 03:30, 8. Apr. 2012 (CEST)

Hab' den Link erst mal gelöscht. Wer was über OpenRISC wissen will, muss im <ref> suchen, eine WP-Artikel gibt's nicht. --arilou (Diskussion) 09:57, 10. Apr. 2012 (CEST)

Behauptung "Komplizierter Compiler"

Lieber Benutzer:Shaddim!

In diesem Revert bestehst du darauf, dass RISC bedeute:

1. bzgl. Compiler:
   1. "größerer Aufwand und Komplexität in den Software-Compilern"
   2. "die die fehlenden komplexeren Instruktionen aus den vereinfachten CPU-Befehlssätze selbst effizient nachbilden müssen."
   3. "Dies ist eine Herausforderung für die (statische) Compiler da z.B. diese im Gegensatz zu den CPUs den aktuellen Laufzeitkontext zur Kompilezeit nicht kennen."
2. Sowie die Aussage

"Bei RISC-Prozessoren sind die einzelnen Befehle fest verdrahtet, der Befehlssatz von CISC-Prozessoren ist dagegen heute meist in Form von Microcode implementiert und setzt intern auf RISC-artige Befehle auf, die nicht nicht nach außen sichtbar sind."

Das Nicht-Vorhandensein komplexer Befehle bedeutet nicht, dass diese "nachgebaut werden müssen". Mitunter muss ähnliche/dieselbe Funktionalität ebenfalls implementiert werden, was aber i.A. kein explizites "Nachbauen" darstellt.

Zu 1): Das genaue Gegenteil ist der Fall. Das Nicht-Vorhandensein komplexer Befehle macht den Compiler sogar sehr viel einfacher, da dadurch viel weniger Wechselwirkungen zu berücksichtigen sind. Dadurch, dass nur einfache Befehle zur Verfügung stehen, kann auch viel leichter optimiert werden. Ein Compiler-Programmierer kann einfach viel leichter den Überblick über 100 Befehle und deren Wechselwirkung behalten (und im Compiler berücksichtigen), als die Wechselwirkungen von 1500 Befehlen.

Zu 1.2): Es wird gar nichts nachgebildet. Die gewünschte Funktionalität wird mit den vorhandenen einfachen Befehlen implementiert, was i.A. viel einfacher ist, als "genau den richtigen komplexen CISC-Befehl" zu finden, und dessen evtl. komplexe Randbedingungen zu erfüllen.

Zu 1.3): "da z.B. diese im Gegensatz zu den CPUs den aktuellen Laufzeitkontext zur Kompilezeit nicht kennen." ~ hä? Bitte nochmal genauer erklären, was du damit meinst. Und warum das bei RISCs ein größeres Problem darstellen soll, als bei CISCs.

Zu 2): Deine Aussage ist nicht wirklich falsch, aber missverständlich. Der RISC-Satzteil ist ok. Reine CISC-Prozessoren sind heute selten (mir fällt gerade keiner ein), und ja, ein reiner CISC hätte Microcode bestehend aus Micro-Operationen. Aber - wie gesagt - reine Ciscs gibt's kaum welche. Verbreitet sind RISC/CISC-Kombinationen (Intel x86-Reihe, AMDs Prozessoren für PCs), deren Cisc-Befehle in Micro-Ops zerlegt werden ~ die aber meist auch "Befehlen von außen" entsprechen.

--arilou (Diskussion) 11:01, 11. Apr. 2014 (CEST)

Hi Arilou,

1.) Grundpunkt ist: RISC bedeutet primär eine vereinfachung des CPU designs. Es werden weniger komplexe Befehle den höheren (Software-) Ebenen zur verfügung gestellt. Gut für die CPU-Bauer. Da es jedoch so etwas wie die Erhaltung der Komplexität/Aufwand etc im Engineering gibt... wird diese vereinfachung sich irgendwo anders niederschlagen. Nämlich beim Compiler der die Anforderungen der Hochsprache, typischerweise komplexe instruktionen die auch Speicherzugriffe beinhalten, auf die simplen RISC befehle runterbrechen muss. Dies muss er aber zusätzlich mit weniger infromation tun als der (CISC-)Prozessor hätte...nämlich zur Kompilezeit. Ein moderner Prozessor dagegen wird laufzeitabhängig information für out-of-order execution etc verwenden und kann damit auch komplexere Konstrukte (CISC!) auf die hardwareressourcen effizient abbilden. Summa-summarum, die verschiebung der Abbildung komplexer Programmiersprachkonstrukte von der Hardware nach oben zum Kompiler geschah unter dem nun vielfach widerlegten aber gerne re-iterierten Axiom das wir den unendlich schlauen Kompiler bereits haben. Auch widerspricht die Verschiebung von unten nach oben dem Konzept von maximaler Lokalität (dem Kompiler fehlen damit die Laufzeit informationen) als auch dem prinzipiellen Trend mehr Komplexität nach unten zu vershcieben also in die Hardware zu integrieren. RISC in seiner Reinform ist damit in der Praxis gescheitert, z.B. sichtbar an der notorisch mässigen Kompilerergebnissen für ARM oder damals für Itanium.

2.) Das die Differnzierung RISC vs CISC heute nur noch wenig sinn mach sieht man an aktuellen Prozessoren die Architektureigenschaften von beiden vereinen und damit eigentlich Hybride sind: grunddesign der internen µOPs eher RISC (Pipeline etc), exponierte API aber CISC (die insturktionsanzahl wächst fleissig weiter, gerne auch immer komplexer) gruss Shaddim (Diskussion) 12:57, 11. Apr. 2014 (CEST)

1. "eine Vereinfachung des CPU-Designs" - und genau deswegen wird es auch einfacher, einen Compiler zu programmieren! (So einfach ist das.)
2. "Compiler, der die Anforderungen der Hochsprache [...] auf die simplen RISC befehle runterbrechen muss." - das macht nicht "der Compiler", sondern derjenige Programmierer, der den Compiler erstellt, genau 1* beim Programmieren des Compilers. Das "Runterbrechen" beim Compilieren eines Programms ist dann ein simples Suchen-und-Ersetzen: Suche in der Liste der Hochsprachenbefehle den gegebenen, ersetze ihn durch die zugehörige Liste von Assemblerbefehlen. Mehr macht kaum ein Compiler (zumindest nicht für "richtige" Hochsprachen jenseits von C). Lediglich bei den absoluten Basics (Addition zweier Integers o.ä.) wird etwas mehr Aufwand getrieben, z.B. dafür Register zu verwenden, die gerade sowieso verfügbar sind. Erst anschließend wird optimiert, was übrigens viel einfacher geht, wenn nicht hunderte von Befehlen mit tausenden Randbedingungen in Frage kommen. Du nennst das "Information steht zur Verfügung", ich nenne das "hoch-komplexe Aufgabe".
3. Sowohl ein RISC- wie auch ein CISC-Compiler haben zur Compilezeit exakt dieselben Informationen, nämlich das Hochsprachenprogramm. Und beide kennen den Prozessor, für den sie compilieren sollen. Und genau hier wird's für den CISC-Compiler viel komplexer und komplizierter als für den RISC-Compiler - die RISC-Maschine hat keine Unmassen komplizierter Randbedingungen und Zustände für die vielen Befehle, die es sehr schwierig machen, abzuschätzen, wann welche Kombination aus Maschinencodes optimal ist. Der RISC-Compiler kann auf den orthogonalen, schlanken RISC-Befehlssatz aufbauen - wie soll das komplizierter und komplexer sein?
4. "Ein moderner Prozessor dagegen wird laufzeitabhängig information für out-of-order execution etc verwenden und kann damit auch komplexere Konstrukte (CISC!) auf die hardwareressourcen effizient abbilden." - was hat das mit der Komplexität des Compilers zu tun? Wenn der Compiler auch noch vorhersagen muss, wie (vermutlich!) der Prozessor unter welchen Umständen out-of-order execution einsetzen wird, und welche Ressourcen (vermutlich!) dann frei sind, wird er doch eher noch komplexer!

Schlussendlich: Dein "Summa-summarum" ist leider "Thema verfehlt". Wir diskutieren nicht um Erfolg oder Scheitern von RISC, sondern darum, ob ein RISC-Compiler einfacher oder komplexer ist als ein CISC-Compiler. Und von letzterem hast du mich noch nicht überzeugt.

--arilou (Diskussion) 16:18, 15. Apr. 2014 (CEST)

1. ähmm... nein? Wenn sagen wir Beispielsweise wenn die CPU keine square root Operation mehr zur verfügung stellt oder keine Floating point operationen, steht der Kompilerbauer vor der schwierigen frage wie zu substituieren. Und das ist sehr architekturabhängig wenn es um effizienz geht. Wenn die CPU selbst eine SQRT implementierugn zur Verfügugn stellt, ist es wahrscheinlicher das dies mit Wissen um die interna geschehen ist also halbwegs effizient auf die internen Strukturen abgebildet ist.
2. hunderte von effizienten CISC operationen ist deutlicher weniger als zehntausende von möglichen implementierungsvarianten auf basis von wenigen simplen RISC aus denen der der Compiler (oder dessen schreiber) die beste Variante (ohne wirklich informatioen zu haben, da Compilezeit) erraten muss.
3. exakt. Für eine effiziente RISC umsetzung brächte man aber MEHR informationen als bei CISC. CISC nimmt dem Compiler die umsetzung auf primitive grundoperatioen ab, der CPU bauer weiss am besten wie umsetzten + die CPU selbst hat auch noch den laufzeitkontext.
4. ne, der compiler kann das net und kriegt das prinzipiell net hin. Die CPU kriegt das aber in der praxis selsbt ganz gut hin und susbstituiert fehlende compilerintelligenz ganz gut wenn ihr mit CISC befehlen die Chance dazu gegen wird.
5. Der im Artikel unterschwellige Grundtenor, RISC sei CISC überlegen ("mehr performance trotz einafcher CPUS und compiler"), ist nicht belegt. Es geht nicht darum ob CISC Kompiler einfacher sind, sondern darum das in der Praxis RISC compiler komplexer sein müssen um wirklich mit CISC architekturen mithalten zu können, also RISC nicht hält was es verspricht. Und so wie ich die aktuelle Forschungslage kenne (lasse mich da gerne überzeugen) gibt es keinen Hinweis darauf das sich die vollmundigen Versprechungen von RISC erfüllt haben, daher meine Neutralisierungen einiger Marketingsprech-Versprechungen im Artikel. schönen Gruss Shaddim (Diskussion) 20:06, 15. Apr. 2014 (CEST)

1. Nette Annahme (SQRT); und genau in Aussagen wie "habwegs effizient" steckt dann, warum es so kompliziert ist, einen CISC-Compiler zu schreiben. Viele CISC-Befehle sind (oft) nur aus Kompatibilitätsgründen (noch) vorhanden und nur sehr langsam implementiert. Andere haben so komplizierte Randbedingungen, dass kein Compiler sie einsetzt. Wieder andere sind je nach Anwendungsfall geeignet (Bspl: Integer-Multiplikation (x86, 32 Bit), wenn Register*Register; jedoch (zu) langsam bei Register*Konstante). Und das alles muss man a) wissen und überblicken b) ändert sich evtl. mit der nächsten CPU-Version c) kann auch noch in Wechselwirkung geraten.
2. Bzgl. "architekturabhängig": Gerade bei RISC ändert sich von einer CPU-Version zur nächsten eher wenig an der eigentlichen Architektur - was gut "durchdesignt" ist, ändert sich eben auch nur geringfügig.
3. "hunderte von effizienten CISC operationen" - das ist ein Aprilscherz, oder? Ein großer Teil davon ist i.A. weit entfernt von "effizient". Beispiel x86: Mitunter rät Intel selbst bei vielen CISC-Befehlen davon ab, sie zu verwenden, weil's mit anderen einfachen (sic!) Befehlen (viel) schneller geht.
4. "zehntausende von möglichen implementierungsvarianten" - Da RISC-Befehlssätze sich meist sehr ähneln, kann man i.A. in einem Buch aus den 1980ern nachlesen, welcher Algorithmus der effizienteste ist.
5. Bzgl. deinem Pkt 3): In diesem Punkt muss ich dir Recht geben; in den komplexeren CISC-Befehlen stecken entsprechend mehr Informationen; ein RISC-Chip müsste dafür z.B. mehrere Befehle zusammen als "übliches Bündel" erkennen. Das wird aber tatsächlich mitunter gemacht: Micro-Op-Fusion / Makro-Op-Fusion ist genau solch eine Technik.

Soweit zum Thema "Compiler für RISC sind komplexer als für CISC".

Was den Punkt angeht "RISC ist besser/schlechter als CISC, hat seine Versprechen nicht gehalten, ..." ~ nuja, heutzutage gibt's eigentlich kaum noch reine RISCs, es werden doch immer Zusatz-Komponenten/Befehle dazugepackt, oft als "Spezial-Hardware". Andererseits sind CISC-Designs eher "noch toter" - so ziemlich alles, was mal CISC war, hat heute deutliche RISC-Anlehnungen.

Ich denke, wir sind uns einig, dass die Aussage

"Compiler für RISC-Architekturen sind komplexer als für CISC"

umstritten ist. Sie (oder ihr Gegenteil) sollte durch Fachbuch-Belege untermauert werden.

Sofern die Aussage nicht belegt wird, sollte hierzu besser gar keine Aussage im Artikel stehen.

--arilou (Diskussion) 12:04, 28. Apr. 2014 (CEST)

Hallo Arilou, zu Belegpflicht ich seh das anderherum: ich würde gerne Belege sehen die zeigen das dass RISC konzept/versprechen (CPUs einfacher, simpler, primitiver) zu bauen zu schnellerem Code/Codeausführung in der Praxis(!) (nicht theoretische minimal snippets) führt. Ansonsten würde ich auf die bekannten Schwächen zB des GCC bei ARM code verweisen oder Designs die am Markt nicht eingschlagen haben... oder papers wie dieses: http://research.cs.wisc.edu/vertical/papers/2013/isa-power-struggles-tr.pdf

Conclusion: "Our methodical investigation demonstrates the role of ISA in modern microprocessors’ performance and energy efficiency. We find that ARM and x86 processors are simply engineering design points optimized for different levels of performance, and there is nothing fundamentally more energy efficient in one ISA class or the other. The ISA being RISC or CISC seems irrelevant." Heisst CISC is kein nachteil und risc kein vorteil.

oder http://ctuning.org/dissemination/grow10-03.pdf "A case study: optimizing GCC on ARM for performance of libevas rasterization library" "At this stage, the compilerdoesn't know whether const is a valid immediate constant for ARM or it needs splitting into two separate instructions and proceeds with merge anyway." "GCC features autovectorization for many SIMD architectures [8], including NEON vfpu that is available in Cortex-A8. We studied how well this feature works with libevas code. After enabling autovectorizer (-ftree-vectorize -mfpu=neon -mfloat-abi=softfp ), we were surprized to observe performance regression."

gruesse Shaddim (Diskussion) 14:22, 28. Apr. 2014 (CEST)

Die Quellen muss ich mir erst anschauen (und ggf. eigene recherchieren). Bis dahin hab' ich erst mal alle (unbelegten) Aussagen dazu, ob Compiler bei RISC oder CISC komplexer sind, aus dem Artikel genommen. Belegte Beiträge dürfen natürlich stets aufgenommen werden, aber unbelegtes ist jetzt erst mal gekillt.

--arilou (Diskussion) 10:57, 5. Mai 2014 (CEST)

Bitte Diskussionende abwarten! :( "bitte nur _belegte_ Aussagen dazu; b) CISC-'mü-Ops' "nicht nach außen sichtbar" ist i.A. falsch." was bitte ist daran falsch das die µOps nach aussen nicht sichtbar sind? Bzgl. des unbelegten, werde dann ebenfalls unbelegtes Formulierungen/Andeutungen aus dem Artikel enfernen. Shaddim (Diskussion) 10:37, 6. Mai 2014 (CEST)

1. Bei Änderungen an einem Artikel, die sofort umstritten sind, ist der Artikelzustand vor der entsprechenden Änderung maßgebend. Deine Artikeländerung(en) mit "Bitte Diskussionsende abwarten!" durchdrücken zu wollen, ist missbräuchlich.
2. Bzgl. µOps: Sowohl bei einem reinen CISC als auch bei einem RISC/CISC-Kombi (wie praktisch alle aktuellen x86 (intel/amd)) sind manche µOps identisch mit den Opcodes der "einfachen" (RISC-like) Maschinenbefehle. Theoretisch könnten natürlich alle µOps nur-intern sein, das ist aber sehr selten (könnt' ich mir vorstellen bei diesen Mikrokontrollern, die man direkt in der Sprache "BASIC" programmieren kann).
3. "Bzgl. des unbelegten, werde dann ebenfalls unbelegtes Formulierungen/Andeutungen aus dem Artikel enfernen." - es ist das gute Recht jedes WP-Autors, für unbelegte Artikelinhalte auch nach Jahren Belege einzufordern. Beachte dabei bitte, dass Beiträge auch via Zusammenfassungs-Zeile belegt worden sein können anstatt durch Einzelnachweis.
   Bei Artikelinhalten, die bereits länger (unkritisiert) im Artikel stehen, ist es "guter Ton", zugehörige Belege erst auf der Diskussionsseite einzufordern, bevor man weglöscht. Bei umfangreichen Problemstellen sollte auch {{Belege}} gesetzt werden, und den anderen Autoren ausreichend Zeit eingeräumt werden für das Belegen der Aussagen.

--arilou (Diskussion) 11:31, 6. Mai 2014 (CEST)

1. Durchdrücken? Trotz gegebner Quellen von mir beendest du die die Diskussion vorzeitig mit einem edit nach deinem gusto. Das durchdrücken sehe ich gerade auf anderer Seite.
2. Das zufälligerweise die nach aussen zur verfügugn gestellte Instruktion gleich der internen ist, reduziert nicht die Korrekheit der Aussage das dies bei modernen Befehldesigns entkoppelt ist, im gegensatz zu ursprünlgichen RISC oder echt CISC, und damit diesen dualistische Terminologie eigentlich überwindet. Moderner CISC hat die vorteile beider welten, während auch moderner RISC weiter mit nur mässiger Performance kämpft und die vollmundigen versprechungen nicht erfüllt.
3. Dies ist ein allgmeinplatz, es geht konkret um diesen Artikel der eine völlig veraltete Sichtweise präsentiert, dessen Stand du scheinbar gerade blockieren glaubst zu muessen. Auch habe ich nicht gelöscht sondern erweitert, verallgemeinert und neutralisiert. Shaddim (Diskussion) 11:39, 12. Mai 2014 (CEST)

1. Absatz, 3. Satz: Designziel

Dieser Satz ist unübersichtlich und schwer zu lesen. Das Designziel kam damals von der Hardware-Seite. Man wollte die Prozessoren, die damals eine (oder mehrere) Leiterplatten umfaßte(n) in möglichst einem (oder wenigen) IC integrieren. Damals waren die technischen Möglichkeiten noch nicht wie heute. Aus diesem Grunde wurde zurück auf einfaches Prozessordesign, IC-Design, gegriffen. Diese IC konnten dann schneller getaktet werden als eine ganze Platine. Die Verarbeitungseinheiten sind ja auch direkt abhängig von der Komplexität der Befehle, welche doch hardwaremäßig verwirklicht werden. Damit ein Befehl, bei z.B. einem Taktzyklus (meistens waren 5 Takte notwendig - gegenüber 20+Takte wenn Microcode verarbeitet wurden), abgearbeitet werden kann muß eine entsprechende Schaltung realisiert sein. Mit der Weiterentwicklung der IC-Fertigung wurden folglich auch wieder komplexere Schaltungen und damit umfangreichere Befehle implementiert. Auch ist es eine Frage der Ausbildung und Erfahrung von den Programmierern ob er 50 oder 250 Befehle beherrscht in allen ihren Möglichkeiten. Bei 50 Befehlen ist die Möglichkeit von Programmierfehlern doch geringer und die Möglichkeit die Software auf mehrere Plattformen zu übertragen leichter.

Benchmark-Test ? Müßte für jeden Prozessor einen eigenen Test programmieren um seine Vorteile ausspielen zu können. - Vergleichbarkeit ?

Die RISC Rechner waren eine Weiterentwicklung von leistungsstarken Midrange Computern. Größe eines Eisschrankes (von - bis). Durch die RISC Prozessoren konnten diese dann doch erheblich verkleinert werden.

PS.: Weiter unten schreiben Sie: "Es sind viele Register verfügbar, die weitgehend identisch genutzt werden können. Klassische RISC-Prozessoren haben 16 oder 32 Register."

Die die ich kannte hatten doch meist nur 12 Register. Wenige 16. Selber ist es mir nicht gelungen einen Prozessor mit 24 Register zu finden. Gelesen, daß es solche mit über 20 Register geben soll habe ich schon - aber keine Datenblätter bzw. Betriebsbücher gefunden. ?? 188.23.44.252 02:59, 27. Apr. 2015 (CEST)

1. Ob der "Designziel-Satz" schwer zu lesen ist ~ ich finde, es geht noch (hab' schon deutlich blöder verschachtelte, längere Bandwurmsätze in der WP gelesen).
2. Die SPARC-Architektur hat 128 (Universal-)Register, davon zumindest 24 im direkten Zugriff. (Mehrkern-Sparcs haben dann 128 Register pro Kern.)
   Der AMD Am29000 hat 64 globale Register und 128 'lokale' Register (via ein Registerfenster 2..128)
   Intel i960: 32 Register, davon 28 "general purpose".
   PowerPC: 32 general purpose
3. Haben Sie für Ihre Aussagen bzgl. "Designziel" Belege? Dann könnte man diese zumindest auch im Artikel nennen.

--arilou (Diskussion) 15:04, 28. Apr. 2015 (CEST)

Was sind denn Verarbeitungseinheiten ?

> Die Hauptfläche der Chips nehmen mittlerweile Verarbeitungseinheiten ein, die erst seit Anfang der 1990er Jahre in Prozessoren auftauchen.

Was sollen denn diese Verarbeitungseinheiten sein? In einem anderen Wiki-Artikel steht, dass die CPU auch Verarbeitungseinheit genannt wird, aber sonst finde ich nichts dazu. Vielleicht sollte jemand diesen Begriff im Artikel besser erklären oder einen Verweis hinzufügen.

// IP 94.217.63.183 , 11.7.2017

Eine Verarbeitungseinheit ist ein logisch zusammenhängendes Gebilde ("Einheit"), das etwas verarbeitet. In einem Prozessor kann das vieles sein, je nach dem, von welchem Detaillierungs-Kontext man gerade redet.

• Eine "gesamtheitliche, oberflächliche" Unterteilung würde wohl den Prozessor aufteilen in CPU-Kerne, Cache+MMU, ggf. Grafikeinheit, und Uncore-Logik (Busanbindung, IO, sonstiges).
• Betrachtet man nur einen CPU-Kern, wären 'Verarbeitungseinheiten' eher ALU, FPU, Steuer- & Adresswerk, Registersatz, Cache, TLB, evtl. eine Vektor-Gleitkommaeinheit, ein Videokodier-/dekodierblock.
• Betrachtet man z.B. die ALU en detail, dann meint "Verarbeitungseinheit" z.B. einen CLA-Addierer, ein Multiplizierwerk o.ä.
• Betrachtet man einen CLA-Addierer en Detail, kann "Verarbeitungseinheit" z.B. ein Halbaddierer sein.

Im Artikel ist wohl am ehesten der zweite Kontext gemeint.

--arilou (Diskussion) 15:34, 3. Jul. 2017 (CEST)

MISC, ZISC und OISC

Wir folgen der englischen Wikipedia nur mit dem Faustkeil an der Höllenwand. Aber vielleicht kann man etwas davon ja auch mal hier einbauen?

en:Minimal instruction set computer
en:Zero instruction set computer
en:One instruction set computer

--Senius (Diskussion) 22:42, 7. Sep. 2018 (CEST)

Sollte das mal eine Überschrift werden?

Berücksichtigung von damals neuen Erkenntnissen beim Compilerbau.

Im Abschnitt RISC-Designphilosophie

-- CleveresKerlchen • Nachricht senden • Wikiliebe 23:10, 29. Jun. 2019 (CEST)

@CleveresKerlchen: Leider lässt sich Deine Frage nicht mehr an den Benutzer stellen, der die Wörter eingefügt hat, weil es sich bei ihm um eine IP handelt:

• Der Text kam am 10. Oktober 2015, 15:59 Uhr durch diesen Edit von 2003:4f:4c25:3800:acc0:ac6a:5230:6f09 in den Artikel und hatte damals schon einen Zeilenumbruch danach.
• Benutzer:Arilou hat am 4. November 2015, 16:42 Uhr mit diesem Edit Text davor eingefügt, seitdem gibt es auch einen Zeilenumbruch davor.
• [https://de.wikipedia.org/w/index.php?title=Reduced_Instruction_Set_Computer&diff=next&oldid=160574032 Bei diesem Edit von Benutzer:Trustable am 20. Januar 2017, 22:13 Uhr, wurde nur noch ein Leerzeichen am Zeilenende entfernt.

Im Sinne Deiner Fragestellung: Ja, ich stimme Dir zu, dass das ganz danach aussieht, als ob das wie "Hintergrund der Entwicklung von RISC-Architekturen waren:" eine Aufzählung einleiten sollte, dass also davor eine Leerzeile fehlt und der Text danach mit * hätte beginnen sollen. Ich ändere das gerade mal ab. --Dogbert66 (Diskussion) 11:36, 30. Jun. 2019 (CEST)

Hallo Dogbert66.

Danke für die aufwendige Recherche, das ist ja wirklich zum lachen, da wurde um den Satz herum bearbeitet, ohne diesen als irgendwie fehlerhaft wahrzunehmen. XD

Beste Grüße -- CleveresKerlchen • Nachricht senden • Wikiliebe 17:39, 30. Jun. 2019 (CEST)