letzter Beitrag von Heiko am
Und dass so viele Adressierungsarten für fast alle Befehle zur Verfügung stehen ("orthogonaler Befehlssatz") ergibt sich ebenfalls daraus, dass die Adressierunsart hardwaremäßig per Gattertechnik verschaltet ist?
"Orthogonal", weil quasi in der Opcode-Tabelle ( https://www.c64-wiki.de/wiki/Opcode ) die Adressierungsarten rechtwinklig zu den Befehlen aufgetragen sind (fast / teilweise, nicht durchgängig)?
Alles anzeigenWhat zrs1 sez.....
Ich meine nicht CISC gegen RISC. Ich meinte, was haben die Forscher damals gemacht, um RISC zu entwickeln. Welche Intension hatten sie, was war ihr Ausganspunkt. Wie gesagt, die ENTSTEHUNG von RISC.
Die Infos stammen aus gefilmten Interviews mit Forschern, die wohl bei der Entwicklung mitgearbeitet haben.
Wie gesagt, Quellen immer gerne.
Gleich der erste Link bei google:
In dem Link wird beschrieben, wie es HEUTE gesehen wird. Nicht wie es DAMALS entstand. Das ist ein riesen Unterschied.
Aber ich wollte MiC nicht seinen thread kaputt machen. @MiC Entschudige.
In dem Link wird beschrieben, wie es HEUTE gesehen wird. Nicht wie es DAMALS entstand. Das ist ein riesen Unterschied.
Aber ich wollte MiC nicht seinen thread kaputt machen. @MiC Entschudige.
Meine Güte jetzt lass' mal gut sein: Die Ansicht von damals zu heute hat sich nicht geändert und wie berreits zrs1 völlig korrekt
gesagt hat: Da wird nix gesucht. 
Aber das ist ein Thema für Leute, die besser wissen, wie es innerhalb eines Prozessors aussieht, als ich.
Vielleicht hast Du die Erklärungen nur falsch in Erinnerung!?
WAS passiert genau, wenn der 6502 über den Datenbus den Opcode eingelesen hat? Wohin wird der geladen - ja wohl nicht in A, X, Y, S, PC ... sondern in ein "Befehlsregister", schätze ich. Was passiert dann, wenn der Befehl da drin steht - ist dem Befehlsregister quasi direkt eine logische Schaltung nachgeschaltet, die anhand der 8 Bits, die der Opcode hat direkt verschiedene Aktionen auslöst?
Ich könnte mit das z. B. so vorstellen (sehr primitiv ausgedrückt, man verzeihe mir):
- Geladen wird der Befehl "LDX $ll" (opcode $A6) ins Befehlsregister.
- Die Logik hinter dem Befehlsregister schaltet ...
- den PC um eines hoch, um das Argument zu holen;
- das X-Register "auf den Datenbus durch", um den Wert direkt da hin zu laden;
- der nächste Speicherzugriff befüllt das X-Register mit dem Wert.
Und ich nehme an, das ist "in Hardware verdrahtet" [EDIT] (= "primitive" Gatterschaltung) [/EDIT] , da muss nichts in einer Befehlstabelle nachgeschaut werden, wie damit umzugehen ist - ansonsten kann ich mir die wenigen Takte, die der Befehl braucht nicht erklären.
Völlig richtig... der aktuelle Befehl landet im Instruction-register.
Vereinfacht wird der aktuelle Befehl und die Info, der wievielte Taktzyklus in diesem Befehl ausgeführt wird auf eine
festverdrahtete Logik (ähnlich PLA) gegeben:
Rechts sieht man das IR (Instruction Register).
Von links kommen Steuersignale T2-T5 und rechts zusätzlich noch T0-T1 als Info zum Taktzyklus des Befehls.
Dadurch werden dann keine, eine oder mehrere der Steuerleitungen (nach unten) aktiv.
Davon hängt dann ab, was der Datenpfad macht....
PS: Zwischen Datenpfad und dem Decode-Rom liegt noch ein bischen Logik. Aber das verschweige ich jetzt mal.
Hier noch das bekannte Blockschaltbild des 6502:
Zwischen Datenpfad und dem Decode-Rom liegt noch ein bischen Logik. Aber das verschweige ich jetzt mal.
Ist ja nur etwas mehr als eine halbe A0-Seite 
Zwischen Datenpfad und dem Decode-Rom liegt noch ein bischen Logik. Aber das verschweige ich jetzt mal.
Ist ja nur etwas mehr als eine halbe A0-Seite
A0? Je nachdem auf welche Größe man das Original eindampft. Ich hab's mir auf ein Whiteboard drucken lassen.... das hatte aber keine A0.
Endlich mal eine vernünftige Anwendung für die Tafel meiner Kinder! 
In dem Link wird beschrieben, wie es HEUTE gesehen wird.
Der Artikel ist nicht besonders gut und streckenweise komplett falsch... Hier wird mit mehr Fachwissen auf das Thema eingegangen, aber leider sind viele der Detailartikel in dem Wiki nicht im Archiv gelandet.
Nicht wie es DAMALS entstand. Das ist ein riesen Unterschied.
Was man unter RISC versteht hat sich im Laufe der Zeit immer wieder geändert: "the statement in the 70s about (801/)RISC was that it could be done in a single chip. later in the 80s, (801/)RISC was instructions that could be executed in single machine cycle. Over the decades, the definition of RISC has been somewhat fluid ... especially as the number of circuits in a chip has dramatically increased" (Zitat von Lynn Wheeler aus obigem Artikel)
Vielleicht hast Du die Erklärungen nur falsch in Erinnerung!?
Nein, die Erläuterung ist richtig.
Habe inzwischen folgendes gefunden:
"Es gibt verschiedene Befehle in einem Prozessor. Manche benötigen Daten, andere keine. Bei einem CISC Prozessor wie dem 80386 kann ein Befehl z.B. so aussehen:
Das macht das Dekodieren kompliziert. Man kann nicht einfach jedes Byte dekodieren, denn es könnte sich auch um Daten oder den zweiten Teil eines Befehles handeln. Das Problem existiert prinzipiell auch bei RISC. Doch versucht man es dort zu minieren, indem man den Code so macht, das man zumindest Vorhersagen über das Ende des Befehles machen kann. Ich möchte dies an einem hypothetischen Beispiel erläutern:
(https://www.bernd-leitenberger.de/cisc-risc.shtml)
Kann sein, daß der Ingenieur es extrem vereinfacht und eben für Laien dargestellt hat, aber so fürchterlich falsch ist es wohl nicht gewesen.
Wenn ich das richtig verstehe schaut der Prozessor zuerst, ob der Befehl nur im ersten Byte steht. Wenn ja führt er ihn aus. Wenn nicht, schaut er ins zweite Byte nach dem Rest des Befehls. Das dauert schonmal länger als wenn alle Befehle vorhersehbar gleich lang sind. Schon allein die Feststellung, wie lang der Befehl ist, ist bei RISC ziemlich überflüssig, da (fast) alle Befehle gleich lang sind.
Falls der Befehl Daten benötigt muß der Prozessor erst feststellen, ob und ob es ein 8, 16 oder 32-Bit-Wert ist, welchen er sich dann holt. Auch das dauert länger als wenn alle Werte IMMER 32 Bit lang sind. Abarbeitung einer Bibliothek nicht, stimmt. Aber einfach "Befehl bekommen, Befehl ausführen" ist wohl auch nicht richtig.
Sage ich ja: Du hast es inkorrekt wiedergegeben:
Zitat von HeikoEin Normaler Prozessor (CISC) hat eine relativ große Befehlsbibliothek, welche teilweise sehr spezialisierte Befehle enthält. Der Prozessor erhält einen Befehl, schaut sich den ersten Befehl seiner Bibliothek an und vergleicht ihn. Ist es nicht der, den er erhalten hat, geht er zum nächsten u.s.w. bis er den passenden Befehl gefunden hat, und dann die damit verbundene Aktion ausführt.
Das deckt sich NICHT mit der Erklärung oben. Der Fetch eines weiteren Instruction- oder Datenbytes ist keine Befehlsbibliothek die durchsucht wird.
Nicht wie es DAMALS entstand. Das ist ein riesen Unterschied.
Was man unter RISC versteht hat sich im Laufe der Zeit immer wieder geändert: "the statement in the 70s about (801/)RISC was that it could be done in a single chip. later in the 80s, (801/)RISC was instructions that could be executed in single machine cycle. Over the decades, the definition of RISC has been somewhat fluid ... especially as the number of circuits in a chip has dramatically increased" (Zitat von Lynn Wheeler aus obigem Artikel)
Zu Kenntnis über etwas gehört halt nunmal auch die Kenntnis über die Entstehung. Im 19ten Jahrundert verstand man unter einem Coupé auch etwas anderes als heute. Dennoch ist es zum Verstehen von alten Texten oder Filmen oder von Historienfilmen auch heute noch wichtig zu wissen, wie es vorher war.
Sage ich ja: Du hast es inkorrekt wiedergegeben:
Zitat von HeikoEin Normaler Prozessor (CISC) hat eine relativ große Befehlsbibliothek, welche teilweise sehr spezialisierte Befehle enthält. Der Prozessor erhält einen Befehl, schaut sich den ersten Befehl seiner Bibliothek an und vergleicht ihn. Ist es nicht der, den er erhalten hat, geht er zum nächsten u.s.w. bis er den passenden Befehl gefunden hat, und dann die damit verbundene Aktion ausführt.
Das deckt sich NICHT mit der Erklärung oben. Der Fetch eines weiteren Instruction- oder Datenbytes ist keine Befehlsbibliothek die durchsucht wird.
Nicht ich, sondern der Ingenieur der es im Interview erklärt hat.
Wobei, eine größere Bibliothek hat ein CISC ja. Und die Befehle sind weniger abstrakt.
Nein, die Erläuterung ist richtig.
Kopf -> Tisch.
Also durch eine (versehentliche) Falschaussage, eventuell sogar aufgrund einer falschen Quelle, macht man sich nicht zum Affen .... da gehört mehr dazu
Also durch eine (versehentliche) Falschaussage, eventuell sogar aufgrund einer falschen Quelle, macht man sich nicht zum Affen .... da gehört mehr dazu
Durch permanentes Wiederholen der Falschaussage vielleicht?
nachdem ich den thread grad schmunzelnd überflogen habe, finde ich es interessant, dass dieselbe frage nach Jahrzehnten immer wieder hochkommt:
wie vergleicht man unterschiedliche (cpu) architekturen ?
Ich selbst habe dies bereits in den auslaufenden 70ern gesehen, den 80ern sowieso, bei 'Supercomputern' und bei 'Workstations' der 90er, bei intel/amd seitdem
und jetzt hier wieder zurück zu historischen vergleichen.
Die Antwort ist immer notwendigerweise sehr technisch und meist anwendungsabhängig, was die häufig nicht-technischen Frager nicht befriedigt.
zudem kann ein technischer idiot auch heute noch ziemlich sicher einen heutigen prozessor ineffizienter programmieren wie ein guter auf einem
8-bit prozessor mit einem tausendstel der Frequenz, also hängt es auch noch davon ab. Aber das subsumiere ich auch unter 'anwendungsabhängig'..
Nein, die Erläuterung ist richtig.
Kopf -> Tisch.
Ich meinte damit, daß ich die Erläuterung so wiedergegeben habe, wie sie in dem Interview von dem Ingenieur gegeben wurde.
Mal eine Frage:
Wie viele Takte braucht der Befehl eines i8086 der am meisten Takte zur Durchführung braucht und was macht der Prozessor in den einzelnen Takten?
Also durch eine (versehentliche) Falschaussage, eventuell sogar aufgrund einer falschen Quelle, macht man sich nicht zum Affen .... da gehört mehr dazu
Durch permanentes Wiederholen der Falschaussage vielleicht?
Ich sage es mal so:
Das Interview damals wurde mit einem der Ingenieure geführt, der zur Entwicklung beigetragen hat. (Ist zu lange her, als daß ich jetzt noch sagen könnte, bei welchem Sender) Die Beschreibung konnte ich mir wegen der Bildhaftigkeit gut merken. Er ist für mich erstmal glaubwürdig.
Ihr sagt jetzt was anderes, schön. Aber ihr verlangt von mir, daß ich euch das jetzt einfach ungesehen glaube, ohne mir eine Quelle zu nennen, mit der ich eure Aussagen nachvollziehen kann. (Da mein Englisch nicht sehr gut ist möglichst deutsch.)
Was tätet ihr an meiner Stelle in dieser Situation? Aner nachgewiesen glaubwürdigen Quelle vertrauen oder denen, die sagen, diese Quelle wäre falsch?
(Wobei ich aber irgendwie den Eindruck habe, daß wir eher aneinander vorbei reden.)
Was tätet ihr an meiner Stelle in dieser Situation?
Nichts, außer die Bandbreite an Wissen und Meinungen zur Kenntnis zu nehmen und
dass Dinge, aus verschiedenen Winkeln gesehen, widersprüchlich erscheinen mögen.
Heiko
Du redest meines Erachtens von was ganz anderem, nämlich der Abbildung einer CISC-CPU auf einen RISC-Kern, wie Intel das seit 486/586 macht. Das wird dort mit einer Microcode-Architektur erledigt, die CISC-Befehle auf RISC-Befehlsstrukturen umsetzt. Da wird ggf. auch in "Tabellen" gewühlt und diese "Firmware" (der Microcode eben) kann auch aktualisiert werden.
Weder eine reine RISC-CPU noch eine reine CISC-CPU machen so etwas, wenn ich das richtig verstanden habe.
Schaut euch doch mal den 8051 an... der ist besonders "schnell"!
Da ist ein Z80 noch ein richtiger Turbo dagegen.
