Frage zu CISC/RISC

Hallo,
ich hoffe ich bin hier im richtigen Unterforum.
Für meine fünfte Prüfungskomponente im Abitur
beschäftige ich mich mit mit den Unterschieden in Leistung und Effizienz zwischen mobilen ARM und klassischeren x86 Prozessoren. Dabei bin ich gerade am Teilthema RISC /CISC und suche ein geeignetes Beispiel um den Unterschied zwischen reduziertem und erweitertem Befehlssatz darzustellen. Jetzt hatte ich an einer Stelle gelesen, dass der CISC Befehlssatz es erlaubt eine simple Addition in einem Befehl durchzuführen, während es beim RISC Befehlssatz dafür mehrere Schritte benötigt.
Meine Frage ist jetzt:
stimmt das so und wenn ja wie lauten die konkreten Assemblerbefehle für dieses Beispiel?

wirklich ?
lernt man how2google nicht schon viel früher ?

http://www.bernd-leitenberger.de/cisc-risc.shtml
http://www.elektronik-kompendium.de/sites/com/0412281.htm
http://www.weblearn.hs-bremen.de/risse/RST/assign02/Intel/risccisc.html
http://www.heise.de/ct/artikel/RISC-CISC-MISC-1425837.html
http://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/
http://de.pdf24.org/document/13/RISC-und-CISC/1
http://www.administrator.de/frage/unterschiede-cisc-risc-10730.html

zumal ist das hier ja auch kein hausaufgabenforum

Danke, aber die Links kenne ich schon.
Leider haben sie absolut nichts mit meiner Frage zu tun...

Mir geht es vielmehr darum, ob jemand eventuell so weitreichende Kenntnisse von Assemblersprache hat, dass er mir den konkreten Sammelbefehl im CISC Befehlssatz verraten könnte.

Beispielsweise weiß ich dass es auf RISC Seite wohl (vereinfacht) so aussieht:
mov r1
mov r2
add r1, r1,r2
bx lr

Also Additionen sollte doch auch ein RISC in einem Takt können. Selbst ein atmega16 kann das. Guck mal nach wie lange der dafür braucht

link lesen:

Üblicherweise arbeiten die meisten Befehle mit mehreren Registern schrieb:

MOV R1,R2 ; Bewege Inhalt von R1 nach R2
ADD R1,R3 ; Addiere R1 und R3, Ergebnis in R1: 2 Register Architektur
ADD R1,R2,R3 ; Addiere R1 und R2, Ergebnis in R3: 2 Register Architektur

Zum Vergrößern anklicken....

CISC ist nicht CISC und RISC ist nicht RISC. So pauschale Aussagen zu treffen ist schwer.
ein ARM verhält sich anders als MSP430 oder ein Atmega obwohl es alle RISC CPUs sind.

Eine Addition sollte aber jeder in einem Takt schaffen. Es kann sein, dass es für CISC Erweiterungen gibt, die direkt in einem Behfel aus dem RAM laden und dort wieder speichern, das hat dann aber nix direkt mit der Addition zu tun.

En3rg1eR1egel schrieb:

link lesen:

Zum Vergrößern anklicken....

meinen Post lesen???

Nilson schrieb:

CISC ist nicht CISC und RISC ist nicht RISC. So pauschale Aussagen zu treffen ist schwer.
eCISC ist nicht CISC und RISC ist nicht RISC. So pauschale Aussagen zu treffen ist schwer.
ein ARM verhält sich anders als MSP430 oder ein Atmega obwohl es alle RISC CPUs sind.

Zum Vergrößern anklicken....

Danke

sucrax schrieb:

Mir geht es vielmehr darum, ob jemand eventuell so weitreichende Kenntnisse von Assemblersprache hat, dass er mir den konkreten Sammelbefehl im CISC Befehlssatz verraten könnte.

Zum Vergrößern anklicken....

dir ist aber schon klar dass es nicht einfach DIE Assembler-Sprache für RISC und CISC gibt? Es gibt dutzende CISC und RISC Prozessoren mit anderen Befehlssätzen. RISC und CISC sind einfach nur ein Konzept.

Z.B. kann eine CISC Architektur eine Speicherstelle zu einem Register addieren:

add eax,[ebx]

während ein RISC Rechner diese Speicherstelle erst in ein Register laden muß und dann erst addiert

mov r1,[12345678]
add r1,r2

Das ist jetzt sehr vereinfacht und die Befehle sind höchstens Pseudocode aber die Idee ist da: RISC hat viele kleine, dafür schnelle Befehle die jeweils sehr wenig tun. D.h. RISC braucht mehrere Befehle um das zu tun was ein CISC Prozessor in einer Zeile macht.
Exemplarisch sind Befehle wie movsb der X86 Architektur welches praktisch ein memcpy ist. Ein RISC Proz müsste da:
Speicher in Reg, Reg in speicher, Zählreg inkrementieren, Quellspeicheraddresse inkrementieren, Zielspeicheraddresse inkrementieren. Also mind. 5 Befehle wo CISC nur einen braucht.

@HominiLupus
vielen Dank!

Ein klassisches Beispiel, als die Leute noch fleissig in Assembler programmiert haben, ist der Vergleich Commodore Amiga (Motorola 68000 - eher CISC) und Acorn Archimedes(ARM2 eher RISC).

Prinzipiell ist es so, dass man für eine komplexe Rechenoperation bei einem RISC Prozessor mehr einzelne Assemblerbefehle benötigt als bei einem eher CISC lastigen Prozessor.

Schlaue Zeitgenossen entwickelten nicht nur deshalb Makro Assembler, mit deren Makros sich Befehlsgruppen zusammenfassen lassen, um nicht dauernd komplexe Rechenoperationen neu und mit schon wunden Fingern in den eh schon unübersichtlichen "Spaghetti" Code zu implementieren.
Bei einem RISC Prozessor ist solch ein Makro Assembler noch mehr wert, als bei einem CISC Prozessor.

Ja, die gute alte Zeit, war schön. Damals war sowieso Alles besser

Nach den Assemblern und Makro Assemblern wurden bei schleunigst wachsender Hardwareleistung mehr und mehr Compiler samt Linker entwickelt. Ich kam bei der Entwicklung für einfache Desktop Anwendungen locker 10 mal so schnell vorwärts wie mein bester Zeitgenosse, der noch in Assembler unterwegs war.

Wenn man allerdings mal son Compiler+Linker Build disassembliert, dann fragt man sich ernsthaft auf fast jeder Bildschirmseite, ob die Compilerbauer was im Tee hatten Das ist die schiere Verschwendung von Massenspeicher, Arbeitsspeicher und auch Rechenleistung.

Es kann sein, dass es für CISC Erweiterungen gibt, die direkt in einem Behfel aus dem RAM laden und dort wieder speichern, das hat dann aber nix direkt mit der Addition zu tun.

Zum Vergrößern anklicken....

Aber genau das ist ja so etwas, was man bei einer RISC-Architektur wohl kaum finden wird.

Gibt auch noch einen Haufen anderer x86-Befehle, die mehrere Dinge auf einmal machen sollen, zum Beispiel den tollen LOOP-Befehl - den aber aus guten Gründen keiner mehr benutzt, weil ein SUB+JNZ sowohl flexibler als auch (zumindest auf dem K10) um einiges schneller ist.

Wenn man sich jetzt mal die Befehle schnappt, die auf aktuellen x86-CPUs wirklich effizient sind und davon mal die Load-Compute-Befehle abzieht, dürfte man schon so eine Art RISC-Befehlssatz erhalten. Die anderen Befehle generieren in aller Regel mehrere µops, weil sie nicht direkt in Hardware implementiert sind (Extrembeispiel: REP MOVSB).

Wenn man allerdings mal son Compiler+Linker Build disassembliert, dann fragt man sich ernsthaft auf fast jeder Bildschirmseite, ob die Compilerbauer was im Tee hatten

Zum Vergrößern anklicken....

Wobei ich manchmal überrascht bin, wie guten und intuitiven Code Clang manchmal ausspuckt - mich wundert es ja doch, dass GCC im Durchschnitt dann doch noch meist flotter ist.

Flott ist das, was wie auf einer Autobahn in die mehrstufigen Pipelines des Prozessors läuft, um dort mit so wenig "Mautstellen" wie notwendig hinten mit maximaler Geschwindigkeit rauskommt. Deshalb hat man früher und wahrscheinlich auch noch heute für konstante FPS, den sauberen Code, womöglich auch noch Rekursiv, also Schleifenbildung und schönen Code vermieden, sondern keine Branches, wir brauchen keinen Stackpointer, Supervisor Stack Pointer braucht nur das lahme ROM, das eh ins RAM kopiert wird und dort via Memory Management Unit beschützt wird. Weg vom Scrollfreien Ruckeln hin zu flüssiger Grafik.

RAM haben wir genügend, los gehts Prozessor, gib GAS !

Für den TE mal das Siegervideo von The Silents, Hardwired, The Party in Aalborg Denmark. Beamer noch mit Roter, Grüner und Blauer Linse. Auf dem Beamer stand "Touch and Die" 1200 Coder dort:

https://www.youtube.com/watch?v=2CGOh-jb4QM


Damit Du auch Frauen siehst im Abitur, noch das von Spaceballs, schwer Denise und Agnus lastig. Copper und Blitter full Load bei Paula:

https://www.youtube.com/watch?v=5aXsrYI3S6g

@DigitalIllusion
Nicht zu vergessen, Copper und Blitter sind im Agnus! (um die Verwirrung zu steigern)
Ja und Paula rockt und ist auch noch ein super ‚Diskjockey‘.

Muss mal mein 500 und 1200 wieder aus der Kiste ziehen.

Beachte das jede Anweisung "Kosten" hat. Z.b. ist eine Addition teurer als eine Mulitplikation, da man bei letzterer die Bits nur shiften muss anstatt wirklich zu rechnen.

Manche Architekturen haben gewisse Rechenoperationen in der Hardware verbaut, andere basteln sie aus kleineren Befehlen zusammen. D.h. es gibt Einzeiler, die hinter der Bühne aber wesentlich mehr tun als du denkst !

Generell kannst sagen ARM > X86. Wirst aber Beispiele bringen müssen, da beides auf ihrem Gebiet schneller sein kann, ARM allerdings insgesamt besser abschneidet und auch Energie effizienter ist.

black90 schrieb:

Beachte das jede Anweisung "Kosten" hat. Z.b. ist eine Addition teurer als eine Mulitplikation, da man bei letzterer die Bits nur shiften muss anstatt wirklich zu rechnen.

Zum Vergrößern anklicken....

1. Shiften ist kein rechnen?
2. Wie bildest du eine Multiplikation lediglich durch Shiften ab?
3. Komischerweise waren bei mir Multiplikationen bisher immer teurer als Additionen

black90 schrieb:

Manche Architekturen haben gewisse Rechenoperationen in der Hardware verbaut, andere basteln sie aus kleineren Befehlen zusammen. D.h. es gibt Einzeiler, die hinter der Bühne aber wesentlich mehr tun als du denkst !

Zum Vergrößern anklicken....

Die Anzahl der Instructionsets sind ziemlich klein im Vergleich zu den Mikroarchitekturen. Hier ist intern praktisch jede CPU anders. Von außen sieht man in der Regel aber nicht, wie viele und welche micro-ops für einen Befehl genutzt werden. Allerdings ist es eher unwahrscheinlich, dass eine CPU plötzlich einen neuen Befehl eingebaut hat. So etwas wäre auch ziemlich unsinnig, da man hierfür wieder spezielle Compiler, so wie einen anderen Assembler benötigen würde. In den Fällen, wo es solche Erweiterungen gab (und gibt), wurden sie eher für alle Rechner zum Standard (zB SSE).

black90 schrieb:

Generell kannst sagen ARM > X86. Wirst aber Beispiele bringen müssen, da beides auf ihrem Gebiet schneller sein kann, ARM allerdings insgesamt besser abschneidet und auch Energie effizienter ist.

Zum Vergrößern anklicken....

Wie kommst du denn jetzt zu dem Ergebnis? Außerdem ist das ja jetzt auch kein wirklicher CISC/RISC-Vergleich. Bestimmte Strategien funktionieren bei CISC nicht so gut oder gar nicht wie bei RISC. So können Befehle sehr unterschiedlich lange in der Ausführung benötigen, weshalb Pipelining zB ein Problem werden kann. Bei kleinen Befehlen, die optimalerweise gleich lang brauchen, ist das aber wesentlich einfacher. Auch Rechner, die nach außen hin wie ein CISC aussehen, brechen die Befehle aus diversen Gründen in kleine Befehle runter.
Also könnte man sagen, dass RISC im Allgemeinen erstmal besser ist als CISC. Durch das interne Runterbrechen auf kleinere Befehle und dann auf micro-ops gibt es aber eigentlich keine reinen CISC-Rechner mehr. Deshalb ist ein solcher Vergleich auch nicht ohne Weiteres möglich.

Moderne Rechenmaschinen sind praktisch alle x86. Die ARM-Geräte gibt es vorwiegend im embedded systems Bereich und haben dort auch durchaus ihre Daseinsberechtigung. Aber warum soll ARM jetzt generell besser sein als x86? Ich gebe zu, dass ich mich mit ARM nicht auskenne, aber die Aussage erscheint mir doch erstmal etwas gewagt.