Architekturunterschiede RISC und 8051

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 ???

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.

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

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

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.

> 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.

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 ?

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