Der 8051 ist ein CISC und Akkumulatorbasiert. Aber was heißt das letztere? Ist der Akkumulator ein spezielles Register in dem alle Operationen ausgeführt werden? Welche Architektur ist in Assembler aufwendiger zu programmieren?
Hallo Maxim, akkumulatorbasierend heißt, das alle wichtigen Befehle (mathematische Operationen Transferbefehle) meistens über das Register A (accumulator) laufen. Es gibt auch Registerbasierende Controller. So war das früher beim Commodore16 mit dem 6502 (Reg XY). Aus heutiger Sicht gesehen, ist der 8051 auch ein RISC, Prozessor, wenn man sich mal den Befehlsumfang eines Pentium oder PowerPC anschaut. Wieder zum Thema Assembler, wo mich schon viele kritisiert haben. Wenn man Assembler richtig versteht, kann man auf diesen Systemen schnelle und Code-Effektive Programme schreiben.
Dirk Hofmann wrote: > Wieder zum Thema Assembler, wo mich schon viele kritisiert haben. > Wenn man Assembler richtig versteht, kann man auf diesen Systemen > schnelle > und Code-Effektive Programme schreiben. Das stimmt. Der 8051 ist speziell für Steuerungen optimiert. Nur für pure Berechnungen (+,-,/,*) braucht man den ACCU. Vergleichen, Zählen, AND, OR, EXOR läßt sich auch mit den Registern und dem direkten SRAM machen. Außerdem hat er noch leistungsfähige Bitbefehle, man kann Logikgleichungen sehr einfach hinschreiben. Auch Tabellen und kleine Datenfelder lassen sich gut bearbeiten (9 Datenpointer, 2 Codepointer). Peter
Hallo Peter, schau Dir doch mal bitte den Beitrag an: Beitrag "reihenfolge der bits in einem byte umdrehen" Verstehst, was ich kürlich mal meinte ???
@Dirk: Ein paar Fehler sind Dir da unterlaufen: >Es gibt auch Registerbasierende Controller. So war das früher >beim Commodore16 mit dem 6502 (Reg XY). Falsch. Der 6502 ist ein typischer Akkumulator-Prozessor. X und Y sind Hilfsregister, z.B. für indizierte Adressierung. >Aus heutiger Sicht gesehen, ist der 8051 auch ein RISC, Prozessor, >wenn man sich mal den Befehlsumfang eines Pentium oder PowerPC >anschaut. Der Pentium ist auch ein RISC-Prozessor. Die alten x86-Befehle werden intern in Mikroops dekodiert.
Wenn man das hier so liest, könnte man meinen alle Prozessoren seien RISC. Dem ist nicht so. Die X86-Linie ist ein typisches CISC (Complex Instruction Set Computer) Design. Die Tatsache, daß eine ganze Reihe Befehle per Firmware modelliert sind, macht keinen RISC-Prozessor! Ebenso ist der 8051 kein RISC, genausowenig, wie die 8080-Linie, oder AVR. Wer den Unterschied zwischen einem RISC- und einem CISC-µC studieren will, der vergleiche einfach die Befehlssätze von msp430 und 8051 oder AVR.
Hallo, heute wird sich oft darum gestritten, ob ein Prozessor RISC oder CISC ist. Bei manchen P. gibt es bestimmte Merkmale die sowohl auf R. als auch auf C. hinweisen. RISC heißt nicht immer wenige befehle und CISC viele, sondern es kommt darauf an wieviel ein Befehl kann, was wiederum bedeuten würde, dass man weniger Befehle braucht. Wenn der Prozessor aber noch mehr kann, dann hat man wieder mehr befehle. Bei RISC wird so häufiger über spezialfunctionregister gearbeitet als bei CISC. Bei RISC ist (fast) jeder Befehl gleich lang (z. B.: 2 Byte), bei CISC gibt es dagegen unterschiedlich lange Befehle(1,2,3,4 Byte). Nicht die Anzahl der Befehle im Befehlssatz entscheidet, sondern die Komplexität des Befehlssatzes und der Befehle selbst. Bei RISC ähneln sich die Befehle untereinander mehr als bei CISC. RISC-Befehle brauchen (fast) jeder die gleiche Ausführungszeit. Es gibt Prozessoren, die sowohl RISC- als auch CISC-Merkmale haben, z. B. der ARM-Prozessor (aber eher RISC). Der 8051 ist da schon eher CISC, denn seine Befehle können 1,2 oder 3 Byte in anspruch nehmen, die Division dauert drei mal so lang wie ein MOV-Befehl, statt ein FSR (File-Select-Register) gibt es unterschiedliche Befehle zur direkten, indirekten und unmittelbaren Adressierung.
Nochmal ein Beitrag von mir. Anhand des 6502 wollte ich nur etwas demonstrieren. Natürlich hat der nen Akku. Mann kann die gleichen Dinge aber auch mit X und Y erledigen. Da A auch ein Register ist, sind die Befehle nicht nur von A Abhängig. Zu RISC und CISC: RISC = eigentlich, wenn sich Befehle nicht mehr weiter in Ausführungsgruppen runterteilen lassen. So zum Beispiel kann ein Linksschiebebefehl auch über einen ADD A,A realisiert werden. Eintypischer Vertreter dafür ist der ST6 von ST. Hab füher viel damit gemacht. Der 8051 ist aus heutiger Sicht ein "RISC" aber kein wahrer, da das sowieso bloss relativ ist. Der Vorteil vom RISC, er nimmt nur ne relativ kleine Chipfläche ein, da nur die elementaren Funktionen realisiert werden. Über den Geschwindigkeitsvorteil gegenüber CISC lääst sich streiten. Da ich auch hier RISC Befehle zu CISC Befehlen zusammensetzen muß. Erzeuge meinen Microcode sozusagen von Hand. Gibt es nen Preisvorteil ???? Keine Ahnung CISC ist eben das Gegenteil und oft für Hochsprachen optimiert, was auch die Stackprozeduren angeht. Welchen Prozessor oder MCU man einsetzt ist denke ich oft Geschmackssache, wobei das nicht heissen soll, daß ihr die Dinger in den Mund nehmen soll. Hat sich schon mal jemand mit TMS470 beschäftigt??? Dirk
In der Tat sind die Übergänge fließend und mir scheint, die Unterscheidung RISC/CISC hat eigentlich wenig praktische Bedeutung. Meine Faustregel: Wenn ich für einen neuen Prozessor lange brauche, um mit seinem Maschinenbefehlssatz einigermaßen effizient umgehen zu können, ist es eher ein RISC. Den MSP430 hatte ich ~ 15 Minuten so weit begriffen, daß ich damit Assemblerprogramme schreiben konnte. Beim X86 ist das mit Sicherheit nicht drin - selbst wenn man viel Erfahrung mit anderen Architekturen hat.
Uhuu hat völlig recht, außerdem bin ich der Meinung, wenn man sein System ordentlich beherrscht, brauch man nicht ständig den Core zu wechslen, weil man an Grenzen kommt
@Dirk: >Anhand des 6502 wollte ich nur etwas demonstrieren. >Natürlich hat der nen Akku. Mann kann die gleichen >Dinge aber auch mit X und Y erledigen. Da A auch >ein Register ist, sind die Befehle nicht nur >von A Abhängig." Nein, eben nicht. Fängt schon beim Rechnen an: ADC. Ist nur mit Akku möglich. Der 6502 ist eine echte Akkumulator-Architektur! Man kann eben nicht alles mit X und Y erledigen. >Dem ist nicht so. Die X86-Linie ist ein typisches CISC (Complex >Instruction Set Computer) Design. Die Tatsache, daß eine ganze Reihe >Befehle per Firmware modelliert sind, macht keinen RISC-Prozessor! Das ist auch falsch! Es wird nichts modelliert. Eher emuliert. Die Rechenwerke eines aktuellen x86-Prozessors, sei es AMD oder Intel, sind reine Risc-Maschinen. Aus Compilersicht ist der Prozessor natürlich wieder eine CISC-Maschine.
Daniel, weißt Du was das I in RISC und CISC bedeutet. Es bedeutet Instruction soviel wie Befehl. Und es geht um die Seite des Programmierers. Man sagt zum Auto auch nicht rollendes Objekt mit 5 Rädern, was zu 80& aus Metall besteht
Leider falsch. Es geht darum, welche Instruktionen die Rechenwerke des Prozessors ausführen. Und das sind RISC-Instruktionen. Nur, daß da noch ein Dekoder vorgesetzt ist, der x86-Befehler entsprechend umsetzt. Was das Ganze mit einem Auto zu tun haben soll, ist mir allerdings schleierhaft.
Daniel, der 8086 ist ein reiner CISC Prozessor.
Der 80386 ist CISC und abwärtskompatibel zum 8086, usw.
Wie soll auf diesem Weg aus dem CISC plötzlich ein RISC werden? Durch
unbefleckte Empfängnis?
> Es wird nichts modelliert. Eher emuliert.
Befehlssatzemulation ist nichts anderes als Modellierung eines
Befehlssatzes durch einen anderen. Ob die Microprogrammier-Ebene der
aktuellen 80X86-Maschinen RISC ist, weiß keiner, außer den
Prozessorherstellern.
Die Entscheidung, ob eine Maschine mehr RISC, oder mehr CISC ist, wird
ausschließlich anhand des Befehlssatzes gefällt, den der Programmierer
zu sehen bekommt.
Auf Microprogrammebene ist alles möglich: von RISC-Extrem (alle
Befehlsworte gleich kurz, ein Befehl pro Maschinenzyklus) bis 'wide
instruction word' in der Größenordung von 1 Kilobit pro Instruktionswort
- jedes Bit steuert einen Datenpfad im Prozessor, dadurch entfällt der
Befehlsdecodierer im Steuerwerk.
Wenn damit ein CISC-Befehlssatz emuliert wird, dann haben wir eine
CISC-Maschine vor uns - es sei denn, die Microprogrammierebene ist
zugänglich - aber dann wirds eigentlich nur noch eine Nummer
akademischer...
Mir scheint, diese RISC/CISC-Debatte war nichts weiter als ein PR-Furz.
Als die ersten Schwaden verraucht waren, stellte sich heraus, daß
extreme RISC-Architekturen nicht die erhoffte Leistung brachten. Der
Grund: Komplexe Befehle, die auf längeren Pipelines überlappend und ggf.
spekulativ ausgeführt werden, bringen höheren Durchsatz, als viele
kleine Fitzel, die nur wenig überlappend abgearbeitet werden können.
Das Hauptmerkmal ist doch die Frage, wie der Prozessor den Befehl ausführt. Kann der Befehl direkt in die Logik gegeben und ausgeführt werden, so ist es ein RISC. Muss der Befehl hingegen zuerst noch in Microcode zerlegt werden, so ist es ein CISC. Complex steht in diesem Fall also nicht unbedingt für "komplex" an sich, sondern eher für komplex im Sinn von "zusammengesetzt". Und das Reduced hat dann wohl eher historische Gründe, als nur sehr einfache Befehle mit der damaligen Technologie direkt in Logik umgesetzt werden konnten. IMHO macht die Unterscheidung für viele Prozessoren keinen Sinn mehr, da gerade leistungsfähige PC-CPUs beispielsweise komplexe Befehle in einfache zerlegen und dann aber wie ein RISC ausführen - oder aber es werden lange Pipelines benutzt, und dann hat man wieder CISC-Aspekte etc. Jedenfalls: Der AVR ist ein RISC, kommt ja (je nach Spekulation) schon im Namen vor. Die Befehle werden normalerweise in einem Takt abgearbeitet, da bleibt also keine Zeit für Mikrocode-Zerlegung.
> Jedenfalls: Der AVR ist ein RISC, kommt ja (je nach Spekulation) > schon im Namen vor. Die Befehle werden normalerweise in einem > Takt abgearbeitet, da bleibt also keine Zeit für Mikrocode-Zerlegung. Dafür sind es mir einfach zu viele und zu spezialisierte - aber das ist letztlich wohl Ermessenssache. Nimm Dir einfach mal den MSP430 mit seinen paarunddreißig Befehlen zum Vergleich vor... Daß keine Zeit für Microcode-Zerlegung bleibt, ist ein Irrtum: Niemand sagt, daß ein Befehl in einem Takt ausgeführt werden muß und in der Tat sind es meistens mehrere - man redet dann etwas hinterhältig von Maschinenzyklen. Befehlsdecodierung heißt im einfachsten Fall, daß aus dem Befehlswort sowas wie ein 'wide instruction word' (per lookup) erzeugt wird, um damit die Datenpfade im Prozessor zu schalten. Das benötigt natürlich Zeit.
> Dafür sind es mir einfach zu viele und zu spezialisierte So viele Befehle hat der AVR gar nicht... Die meisten Befehle sind nur mnemonics für andere Befehle, die einem ein bisschen Schreibarbeit ersparen sollen. Ich habe noch nicht nachgezählt, wie viele "Grundbefehle" rauskommen, wenn man alles, was einen identischen Opcode hat, rausschmeißt (und das sind gerade die Befehle, die sehr "spezialisiert" erscheinen, z.B. die Lösch- und Setzbefehle für die einzelnen Bits im SREG, die sich alle vom selben "Grundbefehl" ableiten und lediglich die Nummer des Bits bereits enthalten; und es gibt noch eine ganze Reihe anderer Beispiele...). Ich vermute zwar, es sind insgesamt noch mehr als die "paarunddreißig" vom MSP430, aber vermutlich nicht viel mehr.
Über die genaue Definition kann man ziemlich gut streiten ;-) Eine Unterscheidung ist z.B. der Aufbau des Befehlssatzes Orthogonal (CISC) vs. Load/Store (RISC). Orthogonal im Sinne von: Jeder Befehl kann mit allen Adressierungsarten kombiniert werden. Beispiel CISC: 68020/30/40 move.l ([1234, a0], d0.l * 4, 5678), ([2345, a1], d1.l * 8, 6789)
1 | mem[mem[a1 + 2345] + d1 * 8 + 6789] = mem[mem[a0 + 1234] + d0 * 4 + 5678] |
> Das Hauptmerkmal ist doch die Frage, wie der Prozessor den Befehl > ausführt. Kann der Befehl direkt in die Logik gegeben und ausgeführt > werden, so ist es ein RISC. Muss der Befehl hingegen zuerst noch in > Microcode zerlegt werden, so ist es ein CISC. Je höher der Takt, umso mehr muss auch bei einem RISC der Befehl aufgeteilt werden. > Nimm Dir einfach mal den MSP430 mit > seinen paarunddreißig Befehlen zum Vergleich vor... Der MSP430 hat zwar wenige Befehle, dafür ist der Befehlssatz sehr orthogal und unterstützt (im Vergleich zu echten RICSs) relativ viele Adressierungsarten was ihn eigentlich zu einem CISC macht.
Falls es jemanden interessiert: Hab grad mal auf die Schnelle den AVR-Befehlssatz überflogen und schon mal 36 mnemonics (also fast ein Drittel des kompletten Befehlssatzes) gefunden, die nur alternative Schreibweisen für andere Befehle sind. Darunter fallen die ganzen Branch-Befehle, die sich alle von brbs und brbc ableiten, die Set- und Clear-Befehle für die SREG-Flags (das sind allein schon 16 Stück!), die identisch mit den entsprechenden "bset" bzw. "bclr" sind, "clr rX" (Clear Register) als alternative für "eor rX, rX", "cbr" und "sbr" (Clear und Set Bits in Register) als Varianten von "ori" bzw. "andi" und noch einige mehr. Bei genauerer Suche findet man vermutlich noch ein paar...
arc wrote:
> Über die genaue Definition kann man ziemlich gut streiten ;-)
Bloß wozu ?
Um mich und andere zu belustigen ?
Peter
Eben, anstatt zu Programmieren und auszuwählen, mit was man arbeiten will. Denke, das Forum sollte sich kein Beispiel am Bundestag nehmen oder ?
> Dafür sind es mir einfach zu viele und zu spezialisierte - aber das ist > letztlich wohl Ermessenssache. Nimm Dir einfach mal den MSP430 mit > seinen paarunddreißig Befehlen zum Vergleich vor... Ich habe bereits angemerkt, dass das Complex in CISC nicht unbedingt auf die Menge, sondern auf den Aufbau - nämlich "zusammengesetzt" - anspielt. Naja, die Diskussion ist sehr akademisch und zu allem Übel noch sehr chaotisch. Wir streiten uns noch über die Definition von CISC/RISC und diskutieren gleichzeitig, welcher Prozessor jetzt CISC und RISC ist... :-)
Letztendlich läufts immer auf das gleiche hinaus: Viele Wege führen zum Ziel. Ich benutze z.B. die AVRs für kleine Aufgaben, den 8051 für mittlere und den LPC-ARM7 für größere (d.h. das LPC-Proggen macht mein Kollege). Trotzdem kann ich alles effektiv machen und werde nie einen PIC und warscheinlich auch nie einen MSP benutzen. Man sucht sich einfach 1..3 MCs für sein Aufgabengebiet aus und gut is. Peter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.