Was macht die 8086-CPU mit den Daten, die von einer Adresse im RAM zurückgegeben werden?

Auch bei der 8086-CPU besteht der Programmcode nicht nur aus Datenbytes im Speicher, und die Bitzahl der Register hat fast nichts mit der Opcode-Länge zu tun, da Sie Bytes oder 16-Bit-Wörter verschieben und auch weit zu 32 springen können -Bit-Adresse (definiert durch Segment und Offset).

Da der 8086 eine CPU mit einem 16-Bit-Bus ist und die Opcodes 1 bis 6 Bytes lang sein können, können die Opcodes in irgendeiner Weise auf den Speicher ausgerichtet sein oder auch nicht. Eine typische Optimierung (manuell oder durch Compiler) besteht jedoch darin, 16-Bit-Variablen und Ziele für Codesprünge an geraden Adressen im Speicher zu platzieren.

Das liegt daran, dass der Bus 16 Bit breit ist, also muss er 16-Bit-Speicher an jeder geraden Speicheradresse haben, und alle ungeraden Speicheradressen sind einfach der obere 8-Bit-Teil des 16-Bit-Busses.

Wenn es also einen Befehl gibt, der die CPU anweist, Code bei 0x44AB auszuführen, was eine ungerade Adresse ist, liest die CPU-Busschnittstelleneinheit (BIU) zuerst ein 8-Bit-Byte von dieser Adresse in die Prefetch-Warteschlange und fährt fort Abrufen von 16-Bit-Wörtern auf einmal ab Adresse 0x44AC in die Prefetch-Warteschlange.

Die CPU-Ausführungseinheit (EU) nimmt einfach Bytes aus der Prefetch-Warteschlange oder wartet darauf, dass Bytes erscheinen, wenn sie leer ist, und decodiert dann die Opcodes und nimmt eine beliebige Menge an Bytes, die aus der Warteschlange erforderlich ist, um die Opcodes vollständig zu decodieren.

Wenn Sie auf ungerade Adressen lesend oder schreibend auf ein 16-Bit-Wort zugreifen möchten, muss die BIU zwei 8-Bit-Zugriffe durchführen. Es muss auf ein Byte im oberen Teil von 16 Bits einer Speicherstelle und auf das andere Byte im unteren Teil von 16 Bits der nächsten Speicherstelle zugreifen.

Beim Ausführen des Programms liest die CPU zuerst den Opcode ein und decodiert ihn dann, um zu entscheiden, wie viele weitere Bytes sie gegebenenfalls in aufeinanderfolgenden Zyklen abrufen muss, um die Anweisung zu erfüllen.

Das, was „entscheidet“, ist der CPU- Mikrocode , ein internes Programm / eine endliche Zustandsmaschine, die den Zyklus-für-Zyklus-Betrieb der CPU steuert. Der Mikrocode decodiert auch die Anweisung, um die von der Anweisung aufgerufenen Datenbewegungen auszuführen.

Die x86-Architektur hat Anweisungen mit variabler Länge und Operanden mit variabler Größe. Der x86-Mikrocode findet all dies heraus, wenn er den Opcode decodiert. Andere Maschinen, insbesondere RISC, können Operationscodes mit fester Länge verwenden, werden aber dennoch Operanden unterschiedlicher Größe handhaben. Dies vereinfacht die Befehlsdecodierung und erhöht die Geschwindigkeit, geht aber auf Kosten der Befehlsdichte.

RISC oder CISC (z. B. x86), der Compiler / Assembler / Linker stellt ein ausführbares Programm zusammen, so dass die Bytefolgen mit genauem Wissen darüber angeordnet sind, wie die CPU Opcodes und Operanden holt.

Die CPU, die das kompilierte Programm ausführt, geht somit davon aus, dass das, was sie liest, in der richtigen Reihenfolge und im richtigen Format ist; und solange das Programm korrekt gebaut wurde, wird dies der Fall sein. Die „richtige Reihenfolge“ wird durch den Befehlssatz definiert , wobei das Format und die Länge jeder Anweisung durch den anfänglichen Opcode bestimmt werden.

Andernfalls gibt es für eine laufende CPU keine Möglichkeit, explizit aus den Daten selbst zu erkennen, ob das eingelesene Opcode, Opcode-Erweiterung, Operand oder zufälliger Müll ist. Das weiß nur der CPU-Mikrocode.