Es gibt da eine Sache, die mir schon länger Kopfzerbrechen bereitet. Vielleicht weiß einer von Euch Näheres darüber.
Oft wird gesagt, der 6502 verfüge bereits über so etwas wie einen simplen Code-Prefetch, eine Vorstufe einer Pipeline. Doch in den Datenblättern von WDC finde ich keine Angaben darüber. (Es findet sich leider keine Darstellung der inneren Verarbeitungsschritte innerhalb eines Taktzyklus.) So beträgt die Anzahl der Taktzyklen für die Befehle INX, DEY, TAX, CLC, SEI, ASL etc bekanntlich 2. Laut des Datenblatts von WDC teilen sich diese Zyklen auf wie folgt:
1.) Buszugriff: Opcode holen von Adresse (PC)
2.) Buszugriff: Byte holen von Adresse (PC + 1) (idle Zugriff)
Sollte der 6502 über so etwas wie einen Opcode-Prefetch verfügen, müßte er entweder in Taktzyklus 1 oder 2 den nächsten Opcode vorausschauend laden. Vergleicht man diese Befehlsgruppe mit den anderen Befehlen, so wird jedoch klar, daß dies laut Datenblatt nicht der Fall ist. So gilt für LDA #
1.) Buszugriff: Opcode holen von Adresse (PC)
2.) Buszugriff: Immediate-Wert holen von Adresse (PC + 1)
Es wird also in Taktzyklus 1 stets der aktuelle Opcode geladen, nicht bereits der nächste.
In Taktzyklus 2 bei INX etc gäbe es nun die Möglichkeit, anstelle des Idle-Zugriffs schon mal den nächsten Befehl zu laden, um so die effektive Taktanzahl von 2 auf 1 zu senken, doch findet dies nicht statt. Die Frage ist: Warum? Kann es vielleicht daran liegen, daß Teile der (vereinfacht dargestellt) dreistufigen Befehlsbearbeitung (1. ALU mit Register laden, 2.) ALU rechnen lassen, 3.) Wert in Register zurückschreiben) in den Taktzyklus des nächsten Befehlladens verschoben werden?
Wäre es von daher (rein theoretisch) überhaupt sinnvoll, einen Opcode-Puffer zu ergänzen, der immer dann aktiv wird, wenn der 6502 einen Idle-Zugriff macht, um schon einmal den nächsten Befehl vorab zu laden? Also indem z. B. ein Flag ergänzt wird, das festhält, ob ein Opcode vorliegt oder nicht. (Und das natürlich bei einem Sprung stets gelöscht werden müßte.) Und falls ja, wäre so etwas (rein theoretisch, weil inkompatibel zum Original) auch auf einem FPGA möglich oder würde dies die Logik nur unnötig erschweren?