Hallo Besucher, der Thread wurde 6,6k mal aufgerufen und enthält 48 Antworten

letzter Beitrag von RalphE am

Ist der 6502 RISC oder CISC? [OT aus: Was, wenn Commodore nie pleite gegangen ...]

    Zitat von SID Spieler

    Währe Commodore noch da und hätte da mit gemischt könnte da so eine Technik verbaut sein,
    es geht ja hier um was währe wenn.
    Und die Power-CPU Technik ist wohl näher dran am 68000er und 6510 als die x86 Architektur.


    Nein, 6510 und 680x0 sind CISC-Designs, während PPC wie ARM RISC sind. Das sind ganz andere Philosophien. Allerdings hat Intel es geschafft, beides miteinander zu vereinbaren, innen RISC (Microcode), außen tut es so als wäre es CISC, um eben x86-kompatibel zu bleiben. An den RISC-Microcode kommt man allerdings nicht dran.

    Zitat von Mac Bacon

    Wäre er RISC, hätte er z.B. keinen Dezimalmodus und keine X-indiziert-indirekte Adressierung.


    Bitte mal die Definition lesen: CISC


    "...and the 6502 and 6809 have both been described as 'RISC-like', although they have complex addressing modes as well as arithmetic instructions that access memory, contrary to the RISC-principles."


    Also CISC ist der 6502 auf keinen Fall, denn keiner der Befehle ist wirklich "mächtig". Viele verschiedene Befehle hat der 6502 auch nicht, würde man die Befehle heutzutage benennen, so würden die Befehle LDA, STA, LDX, STX, LDY, STY, TAX, TXA, TAY, TYA, TSX, TXS, PLA, PHA, PLP und PHP alle nur noch "MOVE" bzw "MOV" heissen.


    Was den BCD-Modus angeht: Der führt exakt 0 neue Befehle ein.

    Zitat von Fröhn

    Bitte mal die Definition lesen: CISC
    "...and the 6502 and 6809 have both been described as 'RISC-like', although they have complex addressing modes as well as arithmetic instructions that access memory, contrary to the RISC-principles."

    Du hältst Dein Sarkasmus-Schild hoch, oder? Auf der Seite finden sich

    • Eine CISC-Definition, die den 6502 implizit einschließt
    • Eine Erklärung, dass aufgrund des technischen Fortschritts "Komplexität" allein kein Kriterium ist (was das entsprechende Gegenargument entkräftet)
    • Ein einfaches Unterscheidungsmerkmal, das implizit den 6502 zu CISC erklärt
    • Eine Reihe von Beispielen für CISC-Architekturen, in der explizit auch die 6502-Familie genannt wird
    • Und schließlich die Information, dass "some writers" "some designs" als "borderline cases" betrachten, woran sich der von Dir zitierte Satz anschließt

    Ergo: Wenn eine Wikiseite überhaupt als Argument durchgeht, dann in diesem Fall eindeutig für "Der 6502 ist CISC". Andernfalls könnten die VTler auch die Wikiseite zu Apollo 11 verlinken, weil darauf ja "Moon landing conspiracy theories" zumindest erwähnt werden...

    Zitat von Fröhn

    Also CISC ist der 6502 auf keinen Fall, denn keiner der Befehle ist wirklich "mächtig".

    Man zeige mir einen modernen RISC, der ein Äquivalent zur Mächtigkeit von "ROR $1234, X" oder "EOR ($80, X)" hat. Letztes Kommando ist sogar so mächtig, dass nie jemand diesen Befehl überhaupt eingesetzt hat... :D

    Zitat von Fröhn

    Viele verschiedene Befehle hat der 6502 auch nicht, würde man die Befehle heutzutage benennen, so würden die Befehle LDA, STA, LDX, STX, LDY, STY, TAX, TXA, TAY, TYA, TSX, TXS, PLA, PHA, PLP und PHP alle nur noch "MOVE" bzw "MOV" heissen.

    ...und wären ein Paradebeispiel für die Abwesenheit von Befehlssatz-Orthogonalität und Load/Store-Architektur.


    Die Designer des 6502 haben wirklich verdammt viel verdammt richtig gemacht. Aber das macht den 6502 nicht RISC, echt jetz.

    Ich vermute, die RISC-Vermutung beim 6502 fusst darauf, dass dieser sehr wenig Zyklen pro Befehl braucht - besonders wenn man ihn mit dem Z80 vergleicht. Das und der sparsamere Befehlsvorrat erwecken schon den Eindruck, dass der 6502 der flotte RISC-Vertreter mit schlankem Befehlssatz ist (flott bezogen auf wenig Zyklen/Befehl) und der Z80 der funktional üppigere und dafür gemütlichere CISC-Vertreter.


    Außerdem hat der 6502 keinen Mikrocode, der die Maschinensprache verarbeitet/interpretiert, sondern die Befehle sind - salopp formuliert - hart verdrahtet im Chip. Auch ein Merkmal, dass den 6502 RISC-artig erscheinen lässt. Wobei ich noch einen drauf setze und mal frage: wieso ist eine CPU mit dem zentralen RISC-Merkmal des fehlenden Mikrocodes keine RISC CPU?

    Zitat von MGR3SA

    Ich glaube der 65816 ist zwar nicht so leistungsfähig wie der 68000 jedoch müssten bei den meisten Spiele die Custom Chips das raus reissen (wie beim SNES).

    Aua.
    Der 65816 ist ein notdürftig auf 16-Bit-Register und 24-Bit-Adressraum erweiterter 8-Bitter mit ein bis drei Registern (je nach Lesart).
    Der 68000 ist ein auf einen 16-Bit-Bus heruntergedrosselter 32-Bitter mit acht oder sechzehn Registern (je nach Lesart).
    Von technischer Seite gesehen war also klar, was zukunftsträchtiger ist und wo die Reise hingeht.


    Bereits der C64 mit seinem doppelt und dreifach belegten Adressraum war eine Frickellösung, die die Ära der 8-Bit-CPUs sehr deutlich für "gehört eigentlich schon lange beendet" erklärt hat.

    Zitat von Tale-X

    Wobei ich noch einen drauf setze und mal frage: wieso ist eine CPU mit dem zentralen RISC-Merkmal des fehlenden Mikrocodes keine RISC CPU?

    Aus dem gleichen Grund, aus dem ein Orca mit dem zentralen Fisch-Merkmal des im-Wasser-lebens kein Fisch ist: Weil es nun mal eine ganze Menge verdammt gute Gründe gibt, die dieser Behauptung widersprechen. Mit dem Fuß aufzustampfen und "ich will aber!" rufen ändert nichts an den Definitionen.


    Woher kommt eigentlich dieser verzweifelte Versuch, den 6502 zum RISC verklären zu wollen?!

    Zitat von Mac Bacon

    Aus dem gleichen Grund, aus dem ein Orca mit dem zentralen Fisch-Merkmal des im-Wasser-lebens kein Fisch ist: Weil es nun mal eine ganze Menge verdammt gute Gründe gibt, die dieser Behauptung widersprechen. Mit dem Fuß aufzustampfen und "ich will aber!" rufen ändert nichts an den Definitionen.
    Woher kommt eigentlich dieser verzweifelte Versuch, den 6502 zum RISC verklären zu wollen?!


    Der "verzweifelte Versuch" kommt daher, dass es nie eine wirklich eindeutige Definition von RISC bzw CISC gab. Es sind zwei Begriffe aus den Markettingabteilungen und der 6502 wurde wegen seines beschränkten Befehlssatzes und eben auch durch den fehlenden Microcode eher RISC zugerechnet, wenn auch nicht "komplett".

    Keine Ahnung... aber wenn der Orca Kiemen statt Lungen hat, darf man doch mal hinterfragen, ob das Exemplar vielleicht doch eher den Fischen zugerechnet werden kann. Genauso sehe ich die Abwesenheit des Mikrocodes und die sehr niedrige Taktzahl pro Befehl als Indiz für RISC. Wobei ich das jetzt nicht als Verklärung des 6502 betrachte, sondern als Abgrenzung, was einen RISC-Prozessor kennzeichnet. Ich gehe davon aus, dass zu Zeiten der 6502-Entwicklung niemand sich Gedanken um RISC vs. CISC gemacht hat, so dass er irgendein Zwischending ist. Die echten RISCs gab's glaube ich erst Mitte/Ende der 80er bzw. waren da angesagt, von daher...

    Zitat von Fröhn

    Der "verzweifelte Versuch" kommt daher, dass es nie eine wirklich eindeutige Definition von RISC bzw CISC gab.

    Jetzt ist die Wikipedia-Seite auf einmal doch nicht mehr gut genug?

    Zitat von Fröhn

    der 6502 wurde [...] eher RISC zugerechnet

    Warum auf einmal die Passivkonstruktion? Wer hat das denn getan; "some writers"? Dass es solche Leute gibt, steht außer Frage, aber warum deren Meinung über die Fakten stellen?


    Das Thema wurde hier und anderswo schon öfters durchgekaut, und wenn jemand neue Argumente bringt, würde ich sie wirklich gerne hören. Schade, dass es bisher immer auf "ich will aber!" hinauslief... :whistling:

    Zitat von Mac Bacon

    Jetzt ist die Wikipedia-Seite auf einmal doch nicht mehr gut genug?Warum auf einmal die Passivkonstruktion? Wer hat das denn getan; "some writers"? Dass es solche Leute gibt, steht außer Frage, aber warum deren Meinung über die Fakten stellen?


    Die Wikipedia-Seite ist auch nur eine von vielen "Interpretationen". Die Diskussion was RISC oder CISC ist gab es damals schon, und wie ich schon sagte: So eindeutig ist das meist nicht, denn in vielen Fällen ist eine CPU ein bischen von beidem und man kann sich endlos lange drüber streiten, ob nun mehr RISC oder CISC Kriterien erfüllt sind.

    Zitat von Tale-X

    Außerdem hat der 6502 keinen Mikrocode, der die Maschinensprache verarbeitet/interpretiert, sondern die Befehle sind - salopp formuliert - hart verdrahtet im Chip. Auch ein Merkmal, dass den 6502 RISC-artig erscheinen lässt.

    Wenn man sich Die-Fotos vom 6502 ansieht, dann findet man darauf typischerweise oben einen ziemlich grossen, relativ regelmässig aussehenden Block: Das ist die PLA, die die Befehlsausführung steuert. Das ist nicht weit von Mikrocode entfernt, insbesondere weil es daneben noch einen Zähler gibt, der die Takte des Befehls durchzählt um über die PLA die gerade nötigen Teile des Prozessors zu "aktivieren".


    Der ARM1 hat eine ähnliche PLA drin, hier hat jemand das mal genauer beschrieben.


    Zitat

    Wobei ich noch einen drauf setze und mal frage: wieso ist eine CPU mit dem zentralen RISC-Merkmal des fehlenden Mikrocodes keine RISC CPU?

    MIPS wird ja gerne als das ganz klassische Beispiel für einen RISC-Prozessor herangezogen. Wäre eine MIPS-Implementierung, die Mikrocode verwendet, auf einmal ein CISC-Prozessor, obwohl der Befehlssatz beider Implementierungen identisch ist?

    Zitat von Mac Bacon

    Der 65816 ist ein notdürftig auf 16-Bit-Register und 24-Bit-Adressraum erweiterter 8-Bitter

    Der 65816 ist die logische Weiterentwicklung des 6502 Konzepts in Richtung 16 Bit. Da gibt es viele Parallelen zum 8088-8086-80286. Hier von "notdürftig" zu sprechen tut den Entwicklern unrecht.


    Der 68000er hat sicherlich gegenüber dem 65816 mehr zu bieten - ein schneller 8 Bit Modus sowie Block-Move-Befehle fehlen ihm aber meines Wissens nach. Im C128 wäre ein 65816 jedenfalls wesentlich sinnvoller gewesen als ein 68000. :)

    Zitat von Tale-X

    Ich vermute, die RISC-Vermutung beim 6502 fusst darauf, dass dieser sehr wenig Zyklen pro Befehl braucht - besonders wenn man ihn mit dem Z80 vergleicht. Das und der sparsamere Befehlsvorrat erwecken schon den Eindruck, dass der 6502 der flotte RISC-Vertreter mit schlankem Befehlssatz ist (flott bezogen auf wenig Zyklen/Befehl) und der Z80 der funktional üppigere und dafür gemütlichere CISC-Vertreter.


    Außerdem hat der 6502 keinen Mikrocode, der die Maschinensprache verarbeitet/interpretiert, sondern die Befehle sind - salopp formuliert - hart verdrahtet im Chip. Auch ein Merkmal, dass den 6502 RISC-artig erscheinen lässt. Wobei ich noch einen drauf setze und mal frage: wieso ist eine CPU mit dem zentralen RISC-Merkmal des fehlenden Mikrocodes keine RISC CPU?

    Schon damals, als mit z.B. dem ARM V1/V2 die erste RISC-CPU im Massenmarkt aufschlug, gab es eine einfache Unterscheidung zwischen RISC und CISC
    CISC: Viele Maschinenbefehle, die überwiegend nicht innerhalb eines Taktzyclusses ausgeführt werden. Das ist auch beim 6502 so, die 1Takt-Befehle kann man wahrscheinlich an einer Hand ablesen, z.B. NOP
    RISC: Nur die nötigsten Maschinenbefehle, mit denen man aber komplexe operationen "nachbauen" kann. Wichtigestes Merkmal: Alle Maschinenbefehle können in einem Takt abgearbeitet werden. 1 Takt für alles bedeutet aber auch, dass der Datenbus so breit sein muss, dass der Befehl und der/die Operanden in einem Rutsch aus dem Speicher gelesen werden können, das ist bei 8 Bit außer bei NOP und anderen einfachen Befehlen garnicht möglich, ein Add (byte aus speicherzelle 1, byte speicherzelle 2) braucht schon schon alleine 3 Takte bis der Befehl mit seinen Operanden über einen 8-Bit-Bus eingelesen ist.

    Zitat von Fröhn

    Der "verzweifelte Versuch" kommt daher, dass es nie eine wirklich eindeutige Definition von RISC bzw CISC gab. Es sind zwei Begriffe aus den Markettingabteilungen und der 6502 wurde wegen seines beschränkten Befehlssatzes und eben auch durch den fehlenden Microcode eher RISC zugerechnet, wenn auch nicht "komplett".

    Nein, es gab von Anfang an die Unterscheidung: RISC hat sehr einfache Befehle und kann jeden davon in 1 Takt abbarbeiten. Das verwusch erst später, heute gehen RISC-Prozessoren immer mehr in Richting CISC, und CISC-Prozessoren sind im Inneren ("Microcode") RISC-CPUs, das heißt komplexe X86-Befehle werden in viele einzelne Microcode-Befehle "zerlegt" (eine Integer-Multiplikation lässt sich z.B. als eine Reihe von Additionen mit immer der selben Zahl abbilden, also 4*5 wird in 4+4+4+4+4 übersetzt) und dann ausgeführt.

    Zitat von Tale-X

    Ich gehe davon aus, dass zu Zeiten der 6502-Entwicklung niemand sich Gedanken um RISC vs. CISC gemacht hat, so dass er irgendein Zwischending ist.

    RISC gab es zur 6502-Entwicklung noch nicht. Der 6502 gehört ja zu den ältesten CPUs überhaupt, nur wenn man die Bekannteren von damals nimmt: 4004, 8080, 8085, Z80, 6800, 6502. Das ist auch ungefähr die Entstehungsreihenfolge. Der 6502 (und etwas weniger der 6800) hat gegenüber der 8080/8085/Z80-Schiene mehr RISC-Ansätze als diese, ist aber trotzdem keiner, weil es beim 6502 eine ganze Reihe Befehle gibt, die 3 oder mehr Taktzyklen brauchen. Außerdem gibt es z.B. Multiplikationsbefehle usw, die man durchaus durch einfache RISC-Befehle (Addition, Shift, siehe obiges Beispiel) ersetzen kann.


    Man kann aber all diese CPUs nicht als RISC ansehen, nur wieil sie maximal 256 verschiedene Befehle kennen, das ist einfach durch die 8-Bit-Architektur gegeben. Grundsätzlich ist aber ein Z80 ganz ähnlich dem 6502 aufgebaut, die Anzahl der Register und dass ein Z80 für die Befehlsdecodierung meist doppelt so viele Takte braucht wie ein 6502, spielt da keine Rolle.

    Zitat von Unseen

    Wenn man sich Die-Fotos vom 6502 ansieht, dann findet man darauf typischerweise oben einen ziemlich grossen, relativ regelmässig aussehenden Block: Das ist die PLA, die die Befehlsausführung steuert. Das ist nicht weit von Mikrocode entfernt, insbesondere weil es daneben noch einen Zähler gibt, der die Takte des Befehls durchzählt um über die PLA die gerade nötigen Teile des Prozessors zu "aktivieren".

    Ich wüsste nicht, was eine "PLA" in der CPU ist. Das Ding was die CPU steuert, nennt sich Befehlsdecoder. Der schaufelt dann die Daten in die Register oder dort wieder raus in den Adressraum, steuert die ALU-Funktionen an, schickt Registerdaten über den Adressbus nach Draußen, erhöht und beschreibt (JMP,JSR,RTS) den Programmzähler, verwaltet den Stackpointer, und solche Sachen. Das ist ein Moore- (taktgesteuert) oder Mealy-Zustands-Automat (taktlos), der die Befehle anhand ihrer Bitmuster den Funktionseinheiten zuordnet. Ich habe sowas mal ganz primitiv als 4-Bit-Befehlsdecoder in einem TTL-Simulator nachgebaut, und das Ding funktionierte wunderbar, konnte zwei Register aus dem Speicher laden und Additionen mit beiden Registern und Bit Shift durchführen. Diese Automaten verhalten sich je nach gerade gültigem Ausgangszustand bei einem neuen Eingangswert anders als mit anderen Ausgangszuständen, ein ziemlich komplexes Thema. Und auch der Microcode in Intel-CPUs wird von solchen Befehlsdecodern ausgeführt. Die x86-CISC-Befehl werden von einem Art Just-in-Time-Compiler in RISC-Microcode übersetzt unbd dann vom Befehlsdecoder ausgeführt, Transmeta waren da die Ersten, die das mit x86-Befehlen gemacht haben. Dieser Befehlsdecoder arbeitet übrigens mit einem höheren Takt, als der offiziell von Intell angegebenen Taktfrequenz des Chips, soweit ich mal mitbekommen habe, doppelt so hoch wie der angegebene CPU-Takt.


    Was zu Moore-Automat als Steuerung eines Befehlsdecoders:
    - https://de.wikipedia.org/wiki/Moore-Automat
    Und hier der Mealy-Automat
    - https://de.wikipedia.org/wiki/Mealy-Automat
    Man sieht anhand der Artikelkategorien wo das einsortiert ist. Das Thema ist recht abstrakt und bringt einen schnell zum kapitulieren.




    Etwas ähnliches findet man auch im Interpreter- und Compilerbau, also auf Software-Seite:
    - https://de.wikipedia.org/wiki/Automatentheorie

    Zitat von 1st1

    Schon damals, als mit z.B. dem ARM V1/V2 die erste RISC-CPU im Massenmarkt aufschlug (...)
    RISC: Nur die nötigsten Maschinenbefehle, mit denen man aber komplexe operationen "nachbauen" kann. Wichtigestes Merkmal: Alle Maschinenbefehle können in einem Takt abgearbeitet werden.

    Dieses Merkmal schliesst den ARM1 aus der RISC-Kategorie aus - LDM/STM brauchen mehr als einen Taktzyklus.


    Zitat

    RISC gab es zur 6502-Entwicklung noch nicht.

    IBM hat zeitgleich an was gebastelt, was heutzutage als RISC-Vorläufer gilt: IBM 801


    Zitat

    Der 6502 gehört ja zu den ältesten CPUs überhaupt

    Öööhm... Nein. Nicht mal entfernt - der richtige Begriff wäre hier Mikroprozessor.


    Zitat

    Ich wüsste nicht, was eine "PLA" in der CPU ist.

    Manchmal wird es als PLA bezeichnet, manchmal als Decode-ROM. Gemeint ist auf jeden Fall das Ding, welches zB hier beschrieben ist.


    Zitat

    Das Ding was die CPU steuert, nennt sich Befehlsdecoder.

    Vielleicht sollte man sich mal den Aufbau eines 6502 anschauen um zu sehen was ich meine, bevor man hier mit Allgemeinplätzen versucht, Eindruck zu schinden...


    Zitat

    Die x86-CISC-Befehl werden von einem Art Just-in-Time-Compiler in RISC-Microcode übersetzt unbd dann vom Befehlsdecoder ausgeführt, Transmeta waren da die Ersten, die das mit x86-Befehlen gemacht haben.

    Transmeta waren die ersten, die einen x86-kompatiblen Chip gebaut haben, indem sie per Interpreter und dynamischem Binärübersetzer x86-Code auf einem VLIW-Prozessor ausgeführt haben - das würde man aber üblicherweise nicht als "Microcode" bezeichnen.


    Wenn man wirklich CISC-Ausführung mit RISC-artigen Microops betrachten will, sollte man sich eh lieber den Nx586 von 1994 anschauen (Crusoe kam 2000 auf den Markt) - der wird üblicherweise als erstes Beispiel dafür bezeichnet und war so gut, dass AMD gleich den ganzen Laden aufgekauft hat um ihren K5 einzustampfen und den K6 mit NexGen-Technologie zu bauen. Zum K6 gibts übrigens nett detailierte Beschreibungen im Buch "The Anatomy of a High-Performance Microprocessor - A Systems Perspective" (B. Shriver, B. Smith; IEEE Computer Society Press 1998, ISBN 0818684003).


    Zitat

    Dieser Befehlsdecoder arbeitet übrigens mit einem höheren Takt, als der offiziell von Intell angegebenen Taktfrequenz des Chips, soweit ich mal mitbekommen habe, doppelt so hoch wie der angegebene CPU-Takt.

    "Doppelter Takt" war die ALU im Pentium 4