DE69333630T2

DE69333630T2 - System und Verfahren zur Übersetzung eines fremden Befehlsstroms zur Ausführung in einem Gastgeberprozessor

Info

Publication number: DE69333630T2
Application number: DE69333630T
Authority: DE
Inventors: Brett Coon; Le Trong Nguyen; Yoshiyuki Miyayama; Johannes Wang
Original assignee: Seiko Epson Corp
Current assignee: Seiko Epson Corp
Priority date: 1992-03-31
Filing date: 1993-03-30
Publication date: 2005-09-22
Anticipated expiration: 2013-03-31
Also published as: DE69329644D1; US7664935B2; JP2000215051A; US5619666A; US20080162880A1; KR100343530B1; EP1028370A2; JP2000215050A; US20050251653A1; JP3547052B2; US6954847B2; EP0636257B1; EP1028370B1; US5438668A; US6263423B1; DE69329644T2; US20030084270A1; EP1028370A3; KR100371929B1; KR950701100A

Description

HINTERGRUND DER ERFINDUNG
1. Erfindungsgebiet
Die vorliegende Erfindung betrifft allgemein superskalare RISC-Mikroprozessoren und insbesondere eine CISC-in-RISC-Mikroprozessor-Befehls-Abgleicheinheit und -Decodiereinheit, um komplexen Befehlen zu gestatten, auf RISC-basierter Hardware zu laufen.
2. Stand der Technik
Alle Computer mit komplexem Befehlssatz (CISC-Computer), die Befehle variabler Länge verwenden, stehen dem Problem gegenüber, die Länge jedes Befehls, der in dem Befehlsstrom angetroffen wird, zu bestimmen. Befehle werden als aufeinanderfolgende Bytes von Daten in den Speicher gepackt, sodass, wenn die Adresse eines Befehls gegeben ist, es möglich ist, die Anfangsadresse des nächsten Befehls zu bestimmen, wenn die Länge des ersten Befehls bekannt ist.
Für einen herkömmlichen Prozessor hat diese Längenbestimmung keinen wesentlichen Leistungseinfluss verglichen mit anderen Stufen in der Verarbeitung eines Befehlsstromes, z. B. die tatsächliche Ausführung jedes Befehls. Als Folge werden typischerweise recht einfache Schaltungen verwendet. Andererseits können superskalare Computer mit reduziertem Befehlssatz (RISC-Computer) Befehle bei einer viel höheren Rate verarbeiten, wobei Befehle viel schneller aus dem Speicher extrahiert werden müssen, um mit der parallelen Ausführung von mehrfachen Befehlen Schritt zu halten. Dieser durch die Rate, mit der Befehle aus dem Speicher extrahiert werden können, auferlegte Begrenzungsfaktor wird als 'Flynn Bottleneck' bezeichnet.
Die Aufgabe des Bestimmens der Länge jedes Befehls und Extrahierens dieses Befehls aus dem Befehlsstrom wird von einer Funktionseinheit durchgeführt, die Befehls-Abgleicheinheit (IAU) genannt wird. Dieser Block muss Decoderlogik enthalten, um die Befehlslänge zu be stimmen, und einen Schieber, um die Befehlsdaten mit der Decoderlogik abzugleichen.
Für den Intel 80386 Mikroprozessor kann das erste Byte eines Befehls zahlreiche Auswirkungen auf die Gesamtbefehlslänge haben und kann erfordern, dass zusätzliche Bytes zu prüfen sind, bevor die endgültige Länge bekannt ist. Außerdem können die zusätzlichen Bytes andere zusätzliche Bytes spezifizieren. Es ist daher äußerst schwer, schnell die Länge des X86-Befehls zu bestimmen, weil der Prozess inhärent sequenziell ist.
Basierend auf der in dem i486 Programmer's Reference Guide bereitgestellten Information können mehrere Folgerungen bezüglich der in dem i486 vorhandenen Abgleicheinheit gezogen werden. Die IAU des i486 ist bestimmt, nur auf die ersten paar Bytes des Befehls zu schauen. In Fällen, wo diese Bytes die Länge nicht voll spezifizieren, werden diese Anfangsbytes extrahiert, und der Prozess wird auf den restlichen Bytes wiederholt. Jede Wederholung dieses Prozesses benötigt einen vollen Zyklus, sodass es im schlimmsten Fall mehrere Zyklen dauern kann, um einen Befehl ganz abzugleichen.
Situationen, die zusätzliche Zyklen für den i486 erfordern, umfassen das Vorhandensein von vorangestellten und entwichenen (2 Byte) Opcodes. Beide sind in i486 Programmen üblich. Außerdem können komplexe Befehle Verschiebungs- und Sofort-Daten umfassen. Der i486 benötigt zusätzliche Zeit, um diese Daten zu extrahieren.
Ein Beispielformat für einen CISC-Prozessorbefehl wird in 1 gezeigt. Dieses Beispiel stellt die möglichen Bytes eines i486 CISC-Befehls variabler Länge dar. Die Befehle werden im Speicher auf Bytegrenzen gespeichert. Die Mindestlänge eines Befehls ist 1 Byte, und die Maximallänge eines Befehls, einschließlich Präfixen, beträgt 15 Bytes. Die Gesamtlänge des Befehls wird durch die Präfixe Opcode-, ModR/M- und SIB-Bytes bestimmt.
EP 0 459 232 beschreibt einen Mikroprozessor, der aus einem Hauptspeicher durch eine Ladereinheit rückgewonnene Befehle teilweise decodiert und sie dann in den integrierten Befehls-Zwischenspeicher legt. Zwei Schlitze des Befehls-Zwischenspeichereintrags werden entsprechend ihren Funktionen mit Zusatzinformation verwendet, um die parallele Ausführung sowie die Emulation von komplexen Befehlen zu steuern. Ein einzelnes Bit in jedem Befehls-Zwischenspeichereintrag wird verwendet, um anzugeben, ob Befehle parallel ausgegeführt werden können oder sequenziell ausgeführt werden müssen.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung, wie in den Ansprüchen 1 und 6 dargelegt, ist ein Untersystem und Verfahren eines Mikroprozessors mit einem superskalaren Computer-Prozessor mit reduziertem Befehlssatz (RISC), der bestimmt ist, einen Computer mit komplexem Befehlssatz (CISC), z. B. einen Intel 80 × 86 Mikroprozesor oder andere CISC-Prozesoren, zu emulieren.
Der CISC-in-RISC-Übersetzungsvorgang der vorliegenden Erfindung umfasst zwei Grundschritte. CISC-Befehle müssen zuerst aus dem Befehlsstrom extrahiert werden und dann decodiert werden, um Nano-Befehle zu erzeugen, die von dem RISC-Prozessor verarbeitet werden können. Diese Schritte werden von einer Befehls-Abgleicheinheit (IAU) bzw. einer Befehls-Decodiereinheit (IDU) durchgeführt.
Die IAU extrahiert einzelne CISC-Befehle aus dem Befehlsstrom, indem sie auf die ältesten 23 Bytes von Befehlsdaten schaut. Die IAU extrahiert 8 fortlaufende Bytes beginnend mit einem Byte in einer Bodenlinie eines Befehls-FIFO. Während jeder Taktphase bestimmt die IAU die Länge des gegenwärtigen Befehls und benutzt diese Information, um zwei Schieber zu steuern, um den gegenwärtigen Befehl auszuschieben, wobei der nächste folgende Befehl in dem Strom gelassen wird. Die IAU gibt daher einen abgeglichenen Befehl während jeder Taktphase bei einer Spitzenrate von zwei Befehlen pro Zyklus aus. Ausnahmen von dieser bestmöglichen Leistung werden unten in Abschnitten 2.0 und 2.1 erörtert.
Nachdem CISC-Befehle aus dem Speicher extrahiert sind, wandelt die IAU diese abgeglichenen Befehle in gleichwertige Folgen von RISC-Befehlen, genannt Nano-Befehle, um. Die IDU schaut auf jeden abgeglichenen Befehl, wenn er von der IAU ausgegeben wird, und decodiert ihn, um verschiedene Faktoren zu bestimmen, z. B. die benötigte Zahl und Art von Nano-Befehlen, die Größe der Datenoperanden, und ob ein Speicherzugriff nötig ist, um den abgeglichenen Befehl zu vervollständigen. Einfache Befehle werden durch Decoder-Hardware direkt in Nano-Befehle übersetzt, während komplexere CISC-Befehle durch Unterroutinen in einem speziellen Befehlssatz, genannt Mikrocode-Routinen, emuliert werden, die dann in Nano-Befehle decodiert werden. Diese Information wird für zwei Befehle während eines vollständigen Zyklus gesammelt und dann miteinander kombiniert, um einen Informationsbehälter zu bilden, der die Nano-Befehle enthält, die beiden Quellenbefehlen entsprechen. Dieser Behälter wird dann an eine Befehls-Ausführungseinheit (IEU) zur Ausführung durch einen RISC-Prozessor übergeben. Die Ausführung des Nano-Befehls-Behälters liegt außerhalb des Umfangs der vorliegenden Erfindung.
Das Vorangehende und andere Merkmale und Vorteile der Erfindung werden aus der folgen genden ausführlicheren Beschreibung von bevorzugten Ausführungen der Erfindung, wie in den anliegenden Zeichnungen veranschaulicht, ersichtlich werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung wird besser verstanden werden, wenn auf die begleitenden Zeichnungen Bezug genommen wird.
1 zeigt ein Datenstrukturformat eines herkömmlichen CISC-Befehls.
2 zeigt ein Blockschaltbild des Befehls-Vorholpuffers der vorliegenden Erfindung.
3 zeigt ein Blockschaltbild der Befehls-Abgleicheinheit der vorliegenden Erfindung.
4 zeigt ein repräsentatives Flussdiagramm der Befehlsextraktions- und Abgleichverfahrens der vorliegenden Erfindung.
5 zeigt ein mit dem Blockschaltbild von 3 und dem Flussdiagramm von 4 verbundenes vereinfachtes Timing-Diagramm.
6 ist ein Blockschaltbild des STACK der vorliegenden Erfindung.
7A ist ein Blockschaltbild des Nächster-Befehl-Decoders (NID) der vorliegenden Erfindung.
7B ist ein Blockschaltbild des Restlicher-Nächster-Befehl-Decoders (RNID) der vorliegenden Erfindung.
8 ist ein Blockschaltbild des Sofortdaten- und Versetzungs-Decoders (IDDD) der vorligenden Erfindung.
9 ist ein Blockschaltbild des Präfix-Decoders (PD) der vorliegenden Erfindung.
10 ist ein Blockschaltbild des Präfix-Nummer-Decoders (PRFX_NO) der vorliegenden Erfindung.
11 ist ein Blockschaltbild eines Nano-Befehls-Behälters der vorliegenden Erfindung.
12 ist ein repräsentatives Blockschaltbild der Befehls-Decodiereinheit (IDU) der vorliegenden Erfindung.
13A–13C zeigen Befehls-Bitmaps der vorliegenden Erfindung.
14 zeigt ein Beispiel-Blockschaltbild des Befehls-Decoderabschnitts des IDDD der vorliegenden Erfindung.
15 zeigt ein repräsentatives Block- und Logikschaltbild eines Satzes von Decodern des in 14 gezeigten Befehlsdecoders.
16A–16C zeigen ein begriffliches Blockschaltbild des Decodier-FIFO der vorliegenden Erfindung.
17 zeigt Beispiele des Nanobefehlsfeldformats der vorliegenden Erfindung.
Inhaltsverzeichnis
Ausführliche Beschreibung der bevorzugten Ausführungen 8

1.0 Die Befehls-Holeinheit 8
2.0 Übersicht der Befehls-Abgleicheinheit 9
2.1 Blockschaltbilder der Befehls-Abgleicheinheit 12
3.0 Übersicht der Befehls-Decodiereinheit 33
3.1 Mikrocode-Dispatch-Logik 36
3.2 Mailboxen 39
3.3 Nanobefehlsformat 40
3.4 Spezielle Befehle
3.5 Blockschaltbilder der Befehls-Decodiereinhert 43
4.0 FIFO für decodierte Befehle 54

AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGEN
1.0 Die Befehls-Holeinheit
Eine Befehls-Holeinheit (IFU) der vorliegenden Erfindung wird verwendet, um Befehlsbytes aus einem Befehlsstrom, der in einem Befehlsspeicher, Befehlszwischenspeicher oder dergleichen gespeichert ist, zu holen und die Befehlsbytes einem Decoderabschnitt zur Ausführung bereitzustellen. Befehle, die von der Befehls-Abgleicheinheit abzugleichen sind, werden daher von der IFU geliefert. 2 zeigt ein Blockschaltbild von drei Befehls-Vorholpuffern 200 in der IFU, die umfassen: Einen Hauptbefehlspuffer (MBUF) 204, einen Emulations-Befehlspuffer (EBUF) 202 und einen Ziel-Befehlspuffer (TBUF) 206. Die Vorhol-Befehlspuffer können 128 Bits (16 Bytes) eines Befehlsstromes von einem Befehlszwischenspeicher in einem einzelnen Zyklus laden. Diese Daten werden in einem der drei Puffer zur Verwendung durch die IAU gehalten.
Während normaler Programmausführung wird der MBUF 202 benutzt, um Befehlsbytes an die IAU zu liefern. Wenn ein bedingter Steuerfluss (d. h. ein bedingter Verzweigungsbefehl) angetroffen wird, werden Befehle, die der Verzweigungszieladresse entsprechen, in dem TBUF 206 gespeichert, während die Ausführung aus dem MBUF 202 weitergeht. Sobald die Verzweigungsentscheidung aufgelöst ist, wird der TBUF 206 entweder weggeworfen, wenn die Verzweigung nicht genommen wird, oder der TBUF 206 wird in MBUF übertragen, wenn die Verzweigung genommen wird. In jedem Fall geht die Ausführung von dem MBUF weiter.
Der EBUF 204 arbeitet in einer etwas anderen Weise. Wenn der Emulationsmodus betreten wird, sei es infolge eines Emulationsbefehls oder einer Ausnahme, werden sowohl die Befehlsholung als auch -Ausführung auf den EBUF 204 übertragen. (Emulationsmodus und Ausnahmebehandlung werden unten im Detail erörtert.) Die Ausführung geht aus dem EBUF 204 werter, solange sich der Prozessor im Emulationsmodus befindet. Wenn die Emulationsroutine endet, wird die Ausführung aus den in dem MBUF 202 verbleibenden Befehlsdaten fortgesetzt. Dies beseitigt die Notwendigkeit, die Hauptbefehlsdaten nach Ausführen der Emulationsroutine erneut zu holen.
2.0 Übersicht der Befehls-Abgleicheinheit
Ein Befehls-Abgleicheinheit-Untersystem in Kombination mit der vorliegenden Erfindung benutzt die RISC-Strategie, um schnell mit dem gewöhnlichen Fall umzugehen, indem der überlegene Pro-Zyklus-Befehlsdurchsatz eines superskalaren Prozessors benutzt wird.
Im Kontext der vorliegenden Erfindung bedeutet der Begriff "Abgleichen", die Bytes eines Befehls so zu positionieren, dass sie zur späteren Decodierung von angrenzenden Bytes in dem Befehlsstrom unterschieden werden können. Die IAU unterscheidet das Ende des gegenwärtigen Befehls vom Anfang des nächsten Befehls durch Bestimmen der Zahl von Bytes in dem gegenwärtigen Befehl. Die IAU gleicht dann den gegenwärtigen Befehl so ab, dass das der IDU präsentierte geringstwertige Byte das erste Byte des gegenwärtigen Befehls ist. Eine andere Folge der Bytes wie sie der IDU präsentiert werden ist auch möglich.
Das IAU-Untersystem der vorliegenden Erfindung ist imstande, die gebräuchlichsten Befehle mit einer Rate von zwei pro Zyklus bei allen Taktraten abzugleichen, und stellt die Fähigkeit bereit, die meisten anderen Befehle mit dieser gleichen Rate bei reduzierten Taktgeschwindigkeiten abzugleichen. Befehle, die Präfixe enthalten, benötigen einen zusätzlichen Halbzyklus zum Abgleichen. Sofort-Daten und Verschiebungsfelder werden parallel extrahiert und benötigten daher keine zusätzliche Zeit.
Außerdem beträgt die ungünstigste Abgleichzeit der IAU nur 2.0 Zyklen für einen Befehl, was weniger ist als die Zeit, die benötigt wird, um viele gebräuchliche Befehle in herkömmlichen CISC-Prozessoren abzugleichen. Der ungünstigste Fall tritt auf, wenn der Befehl aus dem Satz ist, der einen vollen Zyklus benötigt, um die Länge zu bestimmen, und der Befehl (ohne die Präfixe) größer als acht Bytes in der Länge ist (was einen zusätzlichen Halbzyklus, somit 2 volle Zyklen, benötigt).
Diese Leistung wird durch mehrere Architektur-Merkmale erzielt. Erstens, die IAU ist bestimmt, einen vollständigen Abgleichvorgang während jeder Phase des Taktes durch Verwenden von Wechselphasen-Latches und Multiplexern in den Abgleichschaltungen durchzuführen. Zweitens, die Decodierlogik teilt CISC-Befehle in zwei Kategorien basierend auf der Zahl von Bits, die in Betracht gezeogen werden muss, um die Länge jedes Befehls zu bestimmen: Befehle mit einer durch eine kleine Zahl von Bits spezifizierten Länge werden in einer einzigen Phase (Halbzyklus) abgeglichen, wogegen andere Befehle typischerweise eine zusätzliche Taktphase benötigen. Schließlich, die IAU extrahiert in einer einzigen Verschiebung bis zu acht Bytes aus dem Befehlsstrom, was es erlaubt, lange Befehle (bis zu 15 Bytes für i486) in einer kleinen Zahl von Schiebeoperationen und die meisten Befehle mit einer einzigen Verschiebung abzugleichen.
Die folgenden Aufgaben werden von der IAU durchgeführt, um einen CISC-Befehl schnell und genau zu decodieren.
Erfassen des Vorhandenseins und der Länge von Präfix-Bytes;
Isolieren der Opcode-, ModR/M- und SIB- (Skala, Index, Basis) Bytes;
Erfassen der Länge von Befehlen (was die Stelle des nächsten Befehls angibt) und
Senden der folgenden Information an die Befehls-Decodiereinheit (IDU):

– Opcode, 8 Bits plus 3 optionale Erweiterungsbits. Für 2-Byte Opcodes ist das erste Byte immer 0F Hex, sodass das zweite Bytes als der Opcode gesendet wird.
– ModR/M-Byte, SIB-Byte und Verschiebungs- und Sofort-Daten und
– Information bezüglich der Zahl und Art von Präfixen.

Das oder die Opcode-Bytes spezifizieren die durch den Befehl durchgeführte Operation. Das ModR/M-Byte spezifiziert die zu verwendende Adressenform, wenn der Befehl auf einen Operanden im Speicher verweist. Das ModR/M-Byte kann auch auf ein zweites Adressierungsbyte, das SIB- (Skala, Index, Basis) Byte, verweisen, das benötigt werden kann, um die Adressierungsform vollständig zu spezifizieren.
2.1 Blockschaltbilder der Befehls-Abgleicheinheit
3 zeigt ein Blockschaltbild der IAU. Das Schaltbild ist in zwei Abschnitte geteilt: Einen Hauptdatenpfad 302 (angegeben durch den gestrichelten Kasten) und einen Vordercoder 304 (angegeben durch den gestrichelten Kasten). Befehls-Verschiebung und -Extraktion finden in dem Hauptdatenpfad 302 statt, während die Längenbestimmung und Datenpfadsteuerung durch den Vordecoder 304 gehandhabt werden.
Der Hauptdatenpfad 302 umfasst mehrere Register, Latches und Multiplexer. Ein Extrakt-Schieber 306 empfängt in Bytes angeordnete Befehlsdaten von der IFU. Zwei Busse (allgemein bei 303 gezeigt) IFI0b_Bus [127:0] und IFI1b_Bus [55:0] stellen Befehlsdatenausgänder IFU dar. Die IFU aktualisiert diese Befehlsinformation als Reaktion auf Anfordenrungen von der IAU auf einer DAVance BUFfer REQuest (ADVBUFREQ) Leitung 308. Acht Bytes von Daten, die dem gegenwärtigen Befehl entsprechen, werden von dem Extrakt-Schieber ausgegeben und auf einem Bus 307 an den Abgleich-Schieber 310 gesendet. Der Abgleich-Schieber hält insgesamt 16 Bytes an Befehlsdaten und kann bis zu 8 Bytes pro Phase schieben. Der Abgleich-Schieber wird benutzt, um Präfixe von ihrem Befehl zu trennen, wenn sie erfasst werden, indem sie ausgeschoben werden. Der Abgleich-Schieber wird auch verwendet, um den Befehl auf seine niederwertigen Bytes abzugleichen und den ganzen Befehl auszuschieben, nachdem er abgeglichen ist.
Die 8 Bytes werden auch über einen Bus 309 an einen Sofortdaten-Schieber (IMM-Schieber) 312 gesendet, der Sofortdaten aus dem gegenwärtigen Befehl extrahiert, und an einen Versetzungs-Schieber (DISP-Schieber) 314, der Versetzungsdaten aus dem gegenwärtigen Befehl extrahiert. Daten an diese zwei Schieber werden durch ein Omega-Zyklus-Verzögerungselement 316 verzögert, um sie mit dem abgeglichenen Befehl synchronisiert zu haften.
Der Abgleich-Schieber 310 gibt den nächsten abgeglichenen Befehl auf einem Bus 311 an zwei ALIGN_IR-Latches 318 oder 320 aus. Diese Latches arbeiten auf entgegengesetzten Phasen des Systemtaktes, was es erlaubt, zwei Befehle pro Zyklus zu verriegeln. Die Latches ALIGN_IR 318 und 320 geben abgeglichene Befehlsbytes auf zwei Ausgangsbussen 321 aus. Während der Phase, in der eines der Latches einen neuen Wert empfängt, wird der Ausgang des anderen Latchs (der der gegenwärtige abgeglichene Befehl ist) durch einen Multiplexer (MUX 322) ausgewählt. Der MUX 322 gibt den gegenwärtigen abgeglichenen Befehl auf einem Bus 323 für abgeglichene Befehle aus. Der Ausgang 323 ist der primäre Ausgang der IAU. Dieser Ausgang wird vom Vordecoder 304 benutzt, um die Länge des gegenwärtigen Befehls zu bestimmen, und er wird in den Abgleich-Schieber 310 als Daten zurückgeführt, aus denen der nächste Befehl extrahiert wird. Der gegenwärtige abgeglichene Befehl wird über den Bus 325, einen Stark 334 und einen werteren Bus 336 zu dem Abgleich- Schieber 310 zurückgeführt. Der Bus 336 sendet auch die gegenwärtige abgeglichene Befehlsinformation an die Omega-Zyklus-Datenverzögerung 316. Die Schieber IMM und DISP 312 bzw. 314 können daher die Sofortdaten und die Versetzungsdaten schieben, weil sie auch insgesamt 16 Bytes zum Schieben benötigen. Die Omega-Zyklus-Datenverzögerung 316 gibt Befehlsbytes auf einem Bus an die Schieber aus. Der IMM-Schieber 312 gibt Sofortdaten, die dem gegenwärtigen Befehl entsprechen, auf einem Sofortdaten-Bus 340 aus. Der DISP-Schieber 314 gibt Versetzungsdaten, die dem gegenwärtigen Befehl entsprechen, auf einem Versetzungsdaten-Bus 342 aus.
Der Vordecoder 304 umfasst drei Decoderblöcke: Einen Nächster-Befehl-Detektor (NID) 324, einen Sofortdaten- und Versetzungs-Detektor (IDDD) 326 und einen Präfix-Detektor (PD) 328. Der NID und PD steuern den Abgleich-Schieber und den Extrakt-Schieber, während der IDDD den IMM-Schieber 312 und den DISP-Schieber 314 steuert.
Der PD 328 ist bestimmt, die Anwesenheit von Präfixbytes in einem Befehl zu erfassen. Er bestimmt die Zahl vorhandener Präfixe und liefert Schiebesteuersignale an den Abgleich-Schieber 310 und den Zähler-Schieber 308 über eine Leitung 331, einen MUX 330 und eine Leitung 333 zur Extraktion der Präfixe aus dem Befehlsstrom in dem nächsten Halbzyklus. Außerdem decodiert der PD 328 die Präfixe selbst und liefert diese Präfixinformation auf einer Ausgangsleitung 329 an die IDU.
Der Grundaufbau des PD 328 besteht aus vier identischen Präfix-Detektionseinheiten (um bis zu vier Präfixe zu erfassen), und einem zweiten Logikblock, um die Präfixe selbst zu decodieren. Das CISC-Format definiert die Reihenfolge, in der Präfixe vorkommen können, aber die vorliegende Erfindung prüft die Anwesenheit aller Präfixe in jeder der ersten vier Bytepositionen. Des Werteren sind die Funktionen des Erfassens der Anwesenheit von Präfixen und Decodierens der Präfixe getrennt, um Vorteil aus den reduzierten Geschwindigkeitsanforderungen für den Decoder zu ziehen. Eine ausführlichere Beschreibung des Aufbaus des PD 328 erfolgt unten.
Der IDDD 326 ist bestimmt, Sofortdaten und Versetzungsdaten aus jedem Befehl zu extrahieren. Der IDDD versucht immer, beide Felder zu extrahieren, seien sie vorhanden oder nicht. Der IDDD 326 steuert den IMM-Schieber 312 und den DISP-Schieber 314 auf einem Paar Leitungen 344 bzw. 346. Die IDU benötigt einen Halbzyklus, um den abgeglichenen Befehl zu verarbeiten, hat aber keine Verwendung für die Sofortdaten und die Versetzungsdaten. Die Sofort- und Versetzungsdaten werden daher durch die Omega-Zyklus-Datenverzögerung 316 verzögert, um dem IDDD 326 mehr Zeit zu geben, um Schiebebeträge zu be rechnen, weil das Schieben während der folgenden Phase stattfindet, anders als der NID 324, der in der gleichen Phase decodiert und schiebt.
Der NID 324 ist das Herz des Vordecoders. Der NID 324 bestimmt die Länge jedes Befehls, sobald die Präfixe entfernt sind. Der NID 324 steuert den Abgleich-Schieber 310 und einen Zähler-Schieber 308 über eine Steuerlietung 325, den MUX 330 und die Leitung 333. Der NID umfasst zwei Unterblöcke, einen Untermengen-Nächster-Befehl-Detektor (SNID 702) und eine Restlichen-Nächster-Befehl-Detektor (RNID 704) die in Verbindung mit 7A und 7B erörtert werden.
Der SNID 702 bestimmt, wie sein Name sagt, die Längen einer Untermenge des CISC-Befehlssatzes. Befehle in der Untermenge können durch den SNID mit einer Rate von zwei pro Zyklus abgeglichen werden.
Der RNID bestimmt die Längen aller verbleibenden Befehle und beötigt einen zusätzlichen Halbzyklus, der seine Gesamt-Decodierzeit auf einen vollen Zyklus bringt. Die Feststellung, ob ein Befehl in der Untermenge ist oder nicht, wird durch den SNID getroffen, und dieses Signal wird in dem NID verwendet, um entweder den Ausgang des SNID oder des RNID zu wählen.
Wenn ein neuer Befehl abgeglichen wird, wird zu Anfang angenommen, dass er sich in der Untermenge befindet, und daher wird der Ausgang des SNID gewählt. Wenn der SNID (währen des gleichen Halbzyklusses) feststellt, dass der Befehl von dem RNID gehandhabt werden muss, wird ein Signal geltend gemacht, und die IAU schleift den gegenwärtigen Befehl, um ihn für einen weiteren Halbzyklus zu halten. Während dieses zweiten Halbzyklusses wird der RNID-Ausgang gewählt, und der Befehl wird richtig abgeglichen.
Dieser Aufbau der NID hat mehrere Vorteile. Einer, der früher erwähnt wurde, ist, dass die Wahl zwischen dem SNID und dem RNID während eines einzigen Halbzyklusses erfolgen kann, wenn die Zykluszeit ausreichend lang ist, was es erlaubt, alle Befehle in einer einzigen Phase abzugleichen (ausgenommen die Zeit, um Präfixe und Befehle länger als acht Bytes zu extrahieren). Dies ergibt eine Erhöhung der Pro-Zyklus-Leistung bei niedrigeren Zyklusraten ohne zusätzliche Hardware.
Ein zweiter Vorteil ist, dass das Auswählsignal als ein Abgleich-Aufheben-Signal benutzt werden kann, weil es die IAU veranlasst, die SNID-Schiebeausgänge zu ignorieren und den gegenwärtigen Befehl für einen zusätzlichen Halbzyklus zu halten. Der SNID könnte ausge legt sein, bestimmte Befehlskombinationen oder Längen vorherzusagen und dann das Aufhebungssignal zu erzeugen, wenn diese Vorhersagen falsch waren. Dies könnte benutzt werden, um z. B. mehrfache Befehle in einem einzigen Halbzyklus abzugleichen, was die Leistung weiter steigern würde.
Die IAU umfasst auch einen Zähler-Schieber 332. Der Zähler-Schieber 332 wird benutzt, um den Schiebebetrag für den Extrakt-Schieber 306 über eine Leitung 335 zu bestimmen und mittels der ADVBUFREQ-Leitung 308 zusätzliche Befehlsbytes von der IFU anzufordern. Die Funktionalität des Zähler-Schiebers 332 wird am besten verstanden, indem das folgende Flussdiagramm der IAU-Arbeitsweise und ein Zeitdiagrammbeispiel durchgesehen werden.
4 zeigt ein allgemeines Flussdiagramm der Befehlsbyte-Extraktion und des Abgleichs, die von der IAU der vorliegenden Erfindung durchgeführt werden. Wenn neue Daten auf die unterste Leitung 205 des MBUF 204 der IFU (genannt BUCKET_#0) gelangen, extrahiert der Extrakt-Schieber 306 8 Bytes beginnend mit dem ersten Befehl, wie in Schritt 402 gezeigt. Die 8 Befehlsbytes werden zu den ALIGN_IR-Latches 318 und 320 geleitet, während der Abgleich-Schieber 310 umgangen wird, wie in Schritt 404 gezeigt. Die IAU wartet dann auf die nächste Taktphase, während sie den abgeglichenen Befehl in dem ALIGN_IR-Latch hält, wie in Schritt 406 gezeigt.
Während der nächsten Taktphase gibt die IAU den abgeglichenen Befehl an die IDU, den STACK 334, den IDDD 326, den NID 324 den PD 328 und die Omega-Zyklus-Datenverzögerung 316 aus. Die Sofortdaten- und Versetzungsinformation wird dann auf Bussen 340 und 342 an die IDU ausgegeben. Diese Daten entsprechen dem während der vorherigen Phase abgeglichenen Befehl, wenn es einen gab. Diese Operationen werden allgemein in Schritt 408 von 4 gezeigt.
Ein bedingter Befehl 409 wird dann in die IAU eingegeben, um festzustellen, ob ein oder mehr Präfixe vorhanden sind. Diese Feststellung wird durch den PD (Präfix-Decoder) 326 getroffen. Wenn ein oder mehr Präfixe durch den PD erfasst werden, wie durch den "JA"-Pfeil, der den bedingten Befehl 409 verlässt, angegeben, geht der Prozess zu einem Schritt 410, wo die IAU den Ausgang des PD mit dem MUX 330 wählt. Die decodierte Präfix-Information wird dann verriegelt, um während der nächsten Phase mit dem entsprechenden abgeglichenen Befehl an die IDU gesendet zu werden, wie in einem Schritt 412 gezeigt. Wenn keine Präfix-Befehlsbytes erfasst wurden, wie durch einen "NEIN"-Pfeil, der den bedingten Befehl 409 verlässt, angegeben, wird der Ausgang des NID 324 mit dem MUX 330 gewählt, wie in einem Schritt 414 gezeigt.
Sobald die Schritte 412 oder 414 vollendet sind, wird der momentane Ausgang des Zähler-Schiebers 332 verwendet, um den EXTRAKT-Schieber 306 zu steuern, um die nächsten 8 Bytes von Befehlsdaten an den Abgleich-Schieber 310 und die Omega-Zyklus-Verzögerung 316 zu liefern, wie in einem Block 416 gezeigt. Dann benutzt die IAU den Ausgang des MUX 330 als eine Variable, genannt SHIFT_A, die benutzt wird, um den Abgleich-Schieber 310 zu steuern, um den nächsten Befehl abzugleichen. Die SHIFT_A wird auch zu dem momentanen Extrakt-Schieber-Schiebebetrag (genannt BUF_COUNT) addiert, um den Schiebebetrag zur Verwendung während der nächsten Phase zu berechnen. Diese Addition wird in dem Zähler-Schieber 308 durchgeführt, wie in einem Schritt 418 gezeigt.
Der nächste von der IAU durchgeführte Operationsschritt ist das Verriegeln des Ausgangs des Abgleich-Schiebers in dem ALIGN_IR-Latch, wie in Schritt 420 gezeigt. Die Position der Sofortdaten und Versetzungsdaten in dem IDDD 326 wird dann berechnet, und dieser Schiebebetrag wird um einem Omega-Zyklus verzögert, wie in Schritt 422 gezeigt. Dann benutzt die IAU den während des vorherigen Halbzyklusses berechneten Schiebebetrag, um die Daten zu schieben, die momentan in den IMM-Schieber 322 und DISP-Schieber 314 gelangen, wie in Schritt 424 gezeigt. Schließlich wiederholt sich der Prozess beginnend in Schritt 406, um auf die nächste Taktphase zu warten. Die Schritte 408 bis 424 werden für die restlichen Befehlsbytes in dem Befehlsstrom wiederholt.
5 zeigt ein mit der IAU von 3 verbundenes Timing-Diagramm. Zwei Befehlskübel werden oben in 5 gezeigt. Diese Befehlskübel, bezeichnet BUCKET_#0 und BUCKET_#1, umfassen je 16 Befehlsbytes, die von der IFU (aus einem nicht gezeigten Befehlsspeicher) an die IAU in 3 geliefert werden. Der Befehlsabgleich erfolgt immer von rechts aus BUCKET_#0 (d. h. der untere Kübel). In diesem Beispiel sind BUCKET_#0 und BOCKET_#1 die unteren zwei Kübel des MBUF 204 der IFU. Andere Anordnungen sind auch möglich.
In diesem Beispiel sind die ersten drei an die IAU gesendeten Befehle OP0, OP1 und OP2, die Längen von 5 Bytes, 3 Bytes bzw. 11 Bytes aufweisen. Man beachte, dass nur die ersten 8 Bytes des Befehls OP2 in BUCKET_#0 passen. Die restlichen 3 Bytes gehen an den Anfang von BUCKET_#1. Um dieses Beispiel zu vereinfachen, wird angenommen, das diese drei Befehle keine Präfix-Bytes haben. Eine zusätzliche Phase wäre für den Abgleich eines Befehls erforderlich, wenn Präfixe erfasst werden.
Befehle können an jeder Stelle eines Kübels beginnen. Befehle werden bis zu 8 Bytes zu einer Zeit aus dem unteren Kübel beginnend mit irgendeinem Befehl in diesem Kübel extrahiert. Die IAU schaut auf zwei Kübel, um Befehle zu akkommodieren, die sich in den zwei ten Kübel erstrecken, z. B. OP2 in dem vorliegenden Beispiel.
Spur "1" in dem Timing-Diagramm ist einer von zwei Systemtakten CLK0. In diesem Beispiel hat der Systemtakt einen 6-Nanosekunden- (ns) Halbzyklus. CLK0, der verglichen mit dem anderen Systemtakt CLK1 entgegengesetzte Phase hat, steigt bei T6 und fällt bei T0, wo T0 die steigende Flanke von CLK1 ist und T6 die steigende Flanke von CLK0 ist. Die drei Haupttaktphasen von 5 sind _1, _2 und _3 bezeichnet, um dieser Erörterung zu helfen.
Spuren "2" und 3" in dem Timing-Diagramm stellen Befehlsdaten auf den Eingangsbussen IFI1B und IFI0B dar. Ein neuer BUCKET_#0 wird auf dem Bus IFI0B am Beginn von _1 verfügbar, wie bei 502 gezeigt. Eine kurze Zeit später werden die ersten 8 Bytes beginnend mit OP0 (B#0;7–0) durch den Extrakt-Schieber 306 bei 504 extrahiert. BUCKET_#0-Bytes 7–0 sind als gültig gezeigt. Das Timing des Extrakt-Schiebers wird in einer Spur "4" gezeigt.
Wenn die CISC-in-RISC-Decodierung eines Befehlsstromes beginnt, steuert der Zähler-Schieber 332 den Extrakt-Schieber 306, um die ersten 8 Bytes aus BUCKET_#0 zu extrahieren. Der Zähler-Schieber signalisiert dem Extrakt-Schieber, weitere Bytes der Kübel zu schieben und zu extrahieren, wenn der Abgleich von Befehlen voranschreitet. Wenn BUCKET_#0 von Befehlsbytes entleert ist, wird der Inhalt von BUCKET_#1 in BUCKET_#0 geschoben, und BUCKET_#0 wird aus dem Befehlsstrom neu gefüllt. Nach dem anfänglichen Extrahieren von 8 Bytes extrahiert und schiebt der Extrakt-Schieber Bytes unter der Steuerung des Zähler-Schiebers auf der Leitung 335 basierend auf Befehlslänge, Präfix-Länge und vorheriger Schiebeinformation.
Für dieses Beispiel signalisiert jedoch der Zähler-Schieber dem Extrakt-Schieber, null zu schieben, um den ersten Befehl abzugleichen. Der Extrakt-Schieber schiebt daher die ersten 8 Bytes des ersten Befehls in den Abgleich-Schieber 310 aus. Das Timing von Signalen im Abgleich-Schieber wird in Spur "5" des Timing-Diagramms gezeigt. Diese 8 Bytes werden in dem Abgleich-Schieber während _1 in der durch Verweisnummer 506 gezeigten Zeitperiode gültig.
Die ersten 8 Bytes von BUCKET_#0 umgehen den Abgleich-Schieber und werden in den zwei ALIGN_IR-Latches 318 oder 320 gespeichert, wie in Spuren "6" und "7" in 5 gezeigt. Die ALIGN_IR-Latches empfangen die Befehlsbytes in einer alternierenden Weise basierend auf dem Timing der Taktsignale CLK0 und CLK1. ALIGN_IR0 318 ist ein Taktsignal-CLK0-Latch, was bedeutet, dass es verriegelt wird, während das Taktsignal CLK0 hoch ist. ALIGN_IR1 320 ist ein Taktsignal-CLK1-Latch, das verriegelt, wenn das Taktsignal CLK1 hoch ist. Die ersten 8 Bytes werden in dem ALIGN_IR0 vor dem Ende der ersten Taktsignal-CLK0-Phase gültig, wie durch Verweisnummer 508 in Richtung des Ende von _1 gezeigt.
Der MUX 322 wählt das Latch aus, das während der vorherigen Phase verriegelt hat. In diesem Beispiel gibt daher der MUX 322 die ersten 8 Bytes von OP0 während der zweiten vollen Phase, _2, aus.
Die ersten 8 Bytes von OP0 fließen dann in den NID 324 und den STACK 334. Der NID 324 erfasst, dass der erste Befehl 5 Byte lang ist und sendet diese Information über die Leitung 325, den MUX 330 und die Leitung 333 an den Abgleich-Schieber und den Zähler-Schieber. Zur gleichen Zeit fließen die ersten 8 Bytes durch den Stack und werden zu dem Abgleich-Schieber zurückgeführt, wie oben erörtert. Der Abgleich-Schieber empfängt daher Befehlsbytes von dem Extrakt-Schieber und indirekt von sich selbst. Der Grund ist, dass der Abgleich-Schieber 16 Bytes an Eingabe benötigt, um ein Maximum von 8 Bytes pro Zyklus zu schieben. Wenn der Abgleich-Schieber eine Zahl von X Bytes rechts schiebt, wirft er die geringstwertigen X Bytes weg und leitet die nächsten 8 Bytes von Daten an die Latches 318 und 320. In diesem Fall liefert der STACK 334 die Bytes 0–7 an den Abgleich-Schieber 310.
Ein Bypass 336 um den Abgleich-Schieber herum wird in den anfänglichen Fall verwendet, wenn der Extrakt-Schieber den ersten Befehl aus dem Befehlsstrom extrahiert. Für den Abgleich-Schieber ist es nicht erforderlich, in dem Anfangsfall zu schieben, weil, Präfix-Bytes ausgenommen, der erste Befehl abgeglichen ist.
Während _2 des Timing-Diagramms schiebt der Extrakt-Schieber 8 Bytes aus, Bytes 15–8 von BUCKET_#0. Siehe 510 in 5. Diese Bytes werden an den Abgleich-Schieber gesendet, der nun insgesamt 16 aufeinanderfolgende Bytes hat, um damit zu arbeiten. Der Abgleich-Schieber schaut während _2 auf den Ausgang des Extrakt-Schiebers und den gültigen Ausgang der Latches 318 und 320.
Gegen Ende von _2 schiebt der Abgleich-Schieber die Bytes 12–5 von BUCKET_#0 in seine Ausgänge, basierend auf dem Signal von dem NID, das dem Abgleich-Schieber anzeigte, 5 Bytes nach rechts zu schieben, um dadurch die 5 geringstwertigen Bytes, die Befehl OP0 entsprechen, wegzuwerfen. Siehe das Signal Shift_5_byte 512 in Spur "8" des Timing-Diagramms. Die 8 Bytes von restlichen Befehlsdaten, Bytes 12–5, fließen dann durch den Abgleich-Schieber. Man beachte, dass Byte 5 das erste Byte des nächsten Befehls OP1 ist.
Der Zähler-Schieber 332 schiebt dann die 8 Bytes des Extrakt-Schiebers 306, weil die ers ten 8 Bytes nun von den ALIGN_IR-Latches zur Verfügung stehen, sodass die nächsten Bytes benötigt werden. Beginnend in Phase 3 wird der Zähler-Schieber dem Extrakt-Schieber signalisieren, seinen Schiebebetrag um die Zahl von Bytes zu erhöhen, die während der vorherigen Phase durch den Abgleich-Schieber 310 ausgeschoben wurde. Der Zähler-Schieber muss deshalb Logik umfassen, um den vorherigen Schiebebetrag des Extrakt-Schiebers zu speichern und den Schiebebetrag des Abgleich-Schiebers zu diesem Wert zu addieren.
Jedes Mal, wenn es einen neuen Wert für den Abgleich-Schieber gibt, addiert der Zähler-Schieber diesen Betrag zu seinem alten Schiebebetrag. In diesem Beispiel schob er während _2 8 Bytes. In _3 muss er daher dem Extrakt-Schieber sagen, 8 + 5 oder 13 Bytes zu schieben. Die von dem Extrakt-Schieber ausgegebenen Bytes sind Bytes 20–13. Man beachte, dass die ALIGN_IR-Latches Bytes 12–5 während _3 ausgeben werden, und daher werden Bytes 20–5 am Abgleich-Schieber zur Verfügung stehen.
Während _3 wird der Extrakt-Schieber Bytes 20–13 ausgeben. Der BUCKET_#0 enthält jedoch nur Bytes 15–0, daher müssen Bytes 20–16 von dem BUCKET_#1 genommen werden. Wie bei 514 in dem Timing-Diagramm gezeigt, wird der BUCKET_#1 am Beginn von _3 gültig. Der Extrakt-Schieber schiebt dann Bytes 4–0 von BUCKET_#1 und Bytes 15–13 von BUCKET_#0, wie bei 516 gezeigt. Wenn BUCKET_#1 zu dieser Zeit nicht gültig war, hätte die IAU warten müssen, bis er gültig wird.
Wie oben erwähnt, wurde das Signal Shift_5_byte während _2 von dem NID erzeugt. Basierend auf diesem Signal werden Bytes 12–5 von BUCKET_#0 durch den Abgleich-Schieber ausgeschoben, wie bei 518 gezeigt, und kurz danach in das ALIGN_IR1 verriegelt, wie bei 520 gezeigt.
Am Beginn von _3 werden Bytes 12–5 durch den MUX 322 an den STACK 334 und den NID 324 gesendet. Der STACK führt die Bytes 12–5 zurück zu dem Abgleich-Schieber, wie bei 336 gezeigt, und der NID bestimmt die Länge von OP1 als 3 Bytes und gibt das Signal Shift_5_bytes während der letzten Hälfte von _3 aus, wie in Spur "9" bei 522 gezeigt. Der Abgleich-Schieber schiebt 3 Bytes (15–8), und dieser Betrag wird zu dem Zähler-Schieber addiert.
Dann wiederholt sich der obige Prozess. Sobald ein Befehl über BUCKET_#0 hinausgeht (d. h. BUCKET_#0 ist vollständig benutzt), wird BUCKET_#1 BUCKET_#0 werden, und ein neuer BUCKET_#1 wird später gültig werden.
Spur "10" in dem Timing-Diagramm zeigt das Timing für die Extraktion von Bytes aus dem Befehlsstrom. Die Buf_Count#0-Blöcke stellen den gespeicherten Extrakt-Schiebebetrag dar. Während jeder Phase wird der abgeglichene Schiebebetrag zu Buf_Count#0 addiert, und das Ergebnis wird der Extrakt-Schiebebetrag während der nächsten Phase (siehe die mit COUNTER_SHIFT bezeichneten Blöcke).
Spur "11" in dem Timing-Diagramm zeigt das Befehlsabgleich-Timig. Die mit IR_Latch_#0 und IF_Latch_#1 bezeichneten Blöcke stellen das Timing dar, während dem die Befehle in dem entsprechenden ALIGN_IR-Latch gültig werden. Die mit MUX1 bezeichneten kleinen Blöcke stellen die Zeit dar, wenn der MUX 322 beginnt, das gültige Abgleich-Latch auszuwählen. Die mit MUX2 bezeichnten kleinen Blöcke stellen die Zeit dar, wenn der MUX 330 beginnt, den durch den NID 324 bestimmten Schiebebetrag auszuwählen. Schließlich stellen die mit ALIGN_SCHIFT bezeichneten Blöcke die Zeit dar, wenn der Abgleich-Schieber beginnt, den Befehl auszugeben.
Präfixe werden mit dem gleichen Verfahren extrahiert, mit dem Befehle abgeglichen werden, aber der Ausgang von PD 328 wird anstelle des Ausgangs von NID 324 durch den MUX 330 ausgewählt.
Ein Blockschaltbild eines Abschnitts des STACK 334 wird in 6 gezeigt. Der STACK umfasst 64 1-Bit Stacks, die parallel angeordnet sind. Jeder 1-Bit Stack 600 umfasst zwei Latches 602 und 604 und einen Dreieingang-MUX 606. Die abgeglichenen Befehle werden auf einem mit IN bezeichneten Bus 607 in die Latches und den MUX eingegeben. Das Laden der zwei Latches kann unabhängig auf jeder Taktphase erfolgen. Außerdem hat der MUX 606 drei MUX-Steuerleitungen 608, um den Ausgang von jedem Latch zu wählen oder die IN-Daten direkt an einen mit OUT bezeichneten Ausgang 610 umzuleiten.
IAU kann periodisch an einen verschiedenen Befehlsstrom übertragen. Der STACK erlaubt der IAU, zwei Sätze von 8 Bytes von Informationsdaten von dem MUX 322 zu speichern. Dieses Merkmal wird allgemein während der CISC-Befehlsemulation benutzt. Wenn die IAU verzweigen muss, um eine Mikrocode-Routine zur Emulation eines komplexen CISC-Befehls zu verarbeiten, kann der Status der IAU gespeichert und wiederhergestellt werden, sobald die Emulation des CISC-Befehls vollendet ist.
Die Omega-Zyklus-Datenverzögerung wird verwendet, um die Sofortdaten und Versetzungsinformation zu verzögern. Die Verzögerung wird in die IAU gelegt, bevor die Schieber die Sofortdaten und Versetzungdaten weiterleiten, um das Schieben während der folgenden Phase vorzunehmen, anstatt die Befehlslänge und das Schieben in dem gleichen Halbzyklus zu bestimmen. Die Operationen können über den Zyklus gespreizt werden, um es so der Timing-Anforderung leichter zu machen, dieser Logik zu entsprechen. Der IDDD-Block 326 steuert den IMM-Schieber 312 und den DISP-Schieber 314, um die Sofortdaten und die Versetzungsdaten aus den Befehlen zu extrahieren. Wenn z. B. die ersten 3 Bytes des Befehls Opcode sind, gefolgt von 4 Bytes von Versetzung und 4 Bytes von Sofortdaten, würde den Schiebern ermöglicht werden, die geeigneten Bytes auszuschieben.
Die Schieber 312 und 314 geben immer 32 Bits aus, ob die tatsächliche Datengröße 8, 16 oder 32 Bits ist, wobei die Sofort- und Versetzungsdaten geeignet auf die niederwertigen Bits des 32-Bit Ausgangs abgeglichen sind. Die IDU bestimmt, ob die Sofort- und Versetzungsdaten gültig sind, und wenn ja, wie viele der Daten gültig sind.
Das Bestimmen der Länge aller Präfixe, Sofortdaten, Versetzungsdaten und der tatsächlichen Länge der Befehle ist eine Funktion des wirklichen CISC-Befehlssatzes, der abgeglichen und decodiert wird. Diese Information kann von einer in der Technik erfahrenen Person durch Studieren des CISC-Befehlssatzes selbst, der Benutzerhandbücher des Herstellers oder anderem üblichen Verweismaterial erlangt werden. Die Fachleute in der Technik werden ohne weiteres erkennen, wie dies zu erreichen ist und wie die Information in Zufallslogik umzuwandeln ist, um das oben beschriebene IAU-Untersystem, das unten beschriebene IDU-Untersystem zu implementieren, und wie die Steuerlogik und Signale, die zum Steuern des Datenflusses benutzt werden, zu erzeugen sind.
Außerdem, sobald solche Zufallslogik erzeugt ist, können käufliche Entwicklungs-Softwareanwendungen (z. B. Verilog, hergestellt von Cadence Design Systems, Inc, San Jose, California) verwendet werden, um die Logik zu verifizieren, und können beim Definieren des Timings und Erzeugen der Steuersignale und zugehöriger Zufallslogik helfen. Andere käufliche Entwicklungs-Softwareanwendungen sind verfügbar, um Gatter- und Zellen-Layouts zu erzeugen, um die Implementierung des Funktionsblöcke und Steuerlogik zu optimieren.
Der i486 Befehlssatz unterstützt 11 Präfixe, die eine definierte Reihenfolge haben, wenn sie zusammen in einem Befehl benutzt werden. Das Format definiert, dass bis zu vier Präfixe in einem einzelnen Befehl enthalten sein können. Der Präfix-Detektor 328 der vorliegenden Erfindung umfasst daher vier identische Präfix-Detektorschaltungen. Jede Schaltung sucht nach jedem der 11 Präfix-Codes. Die ersten vier an den Präfix-Detektor geleiteten Bytes werden bewertet, und die Ausgänge der vier Präfix-Detektorschaltungen werden kombiniert, um die Gesamtzahl vorhandener Präfixe zu bestimmen. Das Ergebnis wird als der Schiebebetrag verwendet, der durch den MUX 330 geleitet wird.
7A zeigt ein Blockschaltbild des NID. Die folgende Erörterung des NID ist spezifisch für den Abgleich von i486-Befehlen. Der Abgleich von anderen CISC-Befehlen würde wahrscheinlich eine andere NID-Architektur einsetzen. Die unten erörterten Techniken sollen daher den Fachleuten als ein Führer dienen, sollten aber nicht als den Umfang der vorliegenden Erfindung begrenzend angesehen werden.
Nur vier 4 Bytes werden benötigt, um die Länge eines Befehls zu bestimmen. (Wie oben erwähnt, umfassen die 4 Bytes zwei Opcode-Bytes, ein optionales ModR/M-Byte und ein SIB-Byte.)
7A zeigt einen 4-Byte (32 Bit) Bus 701, der die ersten vier Bytes eines von dem MUX 322 empfangenen Befehls darstellt. Die ersten 2 Bytes werden auf einem Bus 703 an den SNID 702 gesendet. Der SNID bestimmt die Länge einer ersten Untermenge von Befehlen, die per Definition basierend auf den ersten 2 Bytes identifizierbar sind. Der SNID kann die Länge dieser Untermenge von Befehlen in einem Halbzyklus bestimmen. Die Länge der Untermengenbefehle wird durch den SNID auf einem Bus 705 ausgegeben. Die Breite des Busses kann der Maximalzahl von durch den SNID erfassten Befehlsbytes entsprechen. Der SNID hat auch eine 1-Bit MODDETect- (MOD_DET) Ausgangsleitung 707, um anzugeben, ob ein ModR/M-Byte in dem Befehl vorhanden ist. Außerdem hat der SNID eine 1-Bit NID_WAIT-Leitung 709, um der Steuerlogik mitzuteilen, dass der Befehl nicht in der Untermenge ist (d. h. stattdessen den Ausgang des RNID verwenden). Die IAU muss daher einen Halbzyklus auf den RNID warten, um den Befehl zu decodieren, wenn NID_WATT wahr ist.
Die durch den SNID decodierte Untermenge von Befehlen sind die CISC Befehle, die in einem Halbzyklus mittels eines Minimums an 1-, 2- und 3-Eingangs-Gattern (NANDs, NORs und Inverter) mit einem Maximum von 5 Gatterverzögerungen basierend auf einem 16 × 16 Karnaugh-Plan von 256 Befehlen decodiert werden können. Blöcke des Plans, die die meisten 1-Byte Opcode Befehle enthalten, können in dieser Weise implementiert werden. Die restlichen Befehle werden durch den RNID mittels einer Logik-Anordnung mit einer längeren Gatterverzögerung decodiert.
Der RNID 704 empfängt die ersten vier Bytes auf dem Bus 701. Der RNID führt die Längenbestimmungs-Decodierung für die restlichen Befehle durch, die mehr als eine Phase zum Decodieren benötigen. Der RNID besitzt Ausgänge, die den Ausgängen des SNID ähnlich sind.
Der RNID erfasst Befehlslängen und gibt das Ergebnis auf einem Bus 711 aus. Ein 1-Bit OVER8-Ausgang 712 zeigt an, dass die Länge des Befehls über 8 Bits beträgt. Der RNID hat auch einen 1-Bit MOD_DET-Ausgang 714, der angibt, ob der Befehl ein ModR/M-Byte enthält.
Die durch entweder den SNID oder den RNID decodierte Länge wird durch einen MUX 706 ausgewählt. Eine Steuerleitung 708 für den MUX 706, genannt SELect_DECoder für die gegenwärtige InstRuction (SELDECIR), schaltet den MUX 706 zwischen zwei Decodern um, um die tatsächliche Länge, die 1 bis 11 Bytes beträgt, zu erlangen. Ein 11 Byte langer Befehl würde z. B. den RNID veranlassen, das OVER8-Signal und eine 3 auf dem Bus 711 auszugeben. Die Befehlslänge (In) wird auf einem Bus 716 an den MUX 330 gesendet und wird von dem Abgleich-Schieber 310 und dem Zähler-Schieber 332 benutzt. Die von dem MUX 706 ausgegebenen 8 Bits werden als Schiebesteuerungen (Freigaben) für den Abgleich- und den Zähler-Schieber verwendet.
Die ModR/M-Bytes werden auch in einer ähnlichen Weise ausgewählt. Das SELDECIR-Signal 708 steuert einen zweiten MUX 710, um die passende MOD-Leitung zu wählen, um anzugeben, ob ein ModR/M-Byte vorhanden ist. Der MOD-Leitungsausgang 718 wird von dem IDDD benutzt.
Das SELDECIR-Signal 708 wird basierend auf dem NID_WAIT-Signal 709 erzeugt. Der Ausgang des SNID wird während der ersten Taktphase ausgewählt, weil diese Ergebnisse vollständig sein werden. Wenn das NID_WAIT-Signal 709 angibt, dass der Befehl nicht decodiert wurde, werden der MUX 706 und der MUX 710 umgeschaltet, um den Ausgang 711 des RNID auszuwählen, der am Beginn der nächsten Taktphase verfügbar werden wird.
Der RNID 704 umfasst im Wesentlichen zwei parallele Decoder, einer decodiert die Befehle, als ob es einen 1-Byte Opcode gibt, und der andere decodiert, als ob es einen 2-Byte Opcode gibt. Ein ESCape DETect (ESC_DET) Eingangssignal gibt an, ob der Opcode 1 Byte oder 2 Bytes lang ist. Zum Beispiel hat in dem i486 Befehlssatz das erste Byte in allen 2-Byte Opcodes (genannt das ESCAPE-Byte) einen Wert 0F Hex, der angibt, dass der Befehl einen 2-Byte Opcode hat. Der RNID gibt eine gültige Befehlslänge basierend auf dem ESC_DET-Signal aus. Dieses Signal gibt an, dass das erste Opcode-Byte ein ESCAPE (0F Hex) ist, das einen 2-Byte Opcode angibt, um dadurch die Decodierung des zweiten Bytes zu ermöglichen. Decodierungslogik zum Erzeugen des ESC_DET-Signals sollte für die Fachleute klar ersichtlich sein.
7B zeigt ein Blockschaltbild des RNID. Der RNID umfasst einen RNID_1OP-Decoder 752, der das erste Opcode-Byte decodiert, einen RNID_2OP-Decoder 754, der das zweite Opcode-Byte decodiert, zwei identische RNID MOD-Decoder 756 und 758, die die ModR/M-Bytes in jeder der zwei durch die Zahl vorhandener Opcode-Bytes bestimmten Positionen decodieren, und einen RNID_SUM-Summierer 760. Basierend auf den Ausgängen der vier RNID-Decoder 752–758 gibt der RNID_SUM-Summierer 760 die Gesamtlänge des Befehls auf einem Bus 762 aus. Der RNID_SUM-Summierer 760 hat eine zusätzliche Ausgangsleitung 764, bezeichnet OVER8, um anzugeben, dass die Länge des Befehls über 8 Bytes beträgt.
Das erste Opcode-Byte des Befehls und 3 Bits (Bits [5:3], genannt Erweiterungsbits) des ModR/M-Bytes werden auf einem Bus 766 in den RNID_1OP 752 eingegeben. Eine weitere Eingangsleitung, genannt DATA_SZ, in den RNID_1OP zeigt an, ob die Operandengröße des Befehls 16 oder 32 Bits beträgt. Die Datengröße wird auf der Basis des verwendeten Speicherschutzschemas und ob Präfixe vorhanden sind, um die Vorgabe-Datengröße aufzuheben bestimmt. Der RNID_1OP nimmt an, dass der Befehl einen 1-Byte Opcode hat, und basierend auf dieser Information und den 3 Erweiterungsbits versucht der RNID_1OP, die Länge des Befehls zu bestimmen.
Der RNID_MOD-Decoder 754 decodiert das ModR/M-Byte des auf einem Bus 770 eingegebenen Befehls. Der RNID_MOD-Decoder hat einen zusätzlichen Eingangsbus 772, bezeichnet ADD_SZ, der angibt, ob die Adressengröße 16 oder 32 Bits beträgt. Die Adressengröße ist unabhängig von der Datengröße.
Das ESC_DET-Signal 774 wird auch in den Block 760 eingegeben. Wenn das ESC_DET-Signal logisch hoch ist, weiß z. B. der RNID_SUM, dass der Opcode tatsächlich in dem zweiten Byte liegt.
Der RNID_2OP-Decoder 754 nimmt an, dass der Opcode 2 Bytes ist und decodiert daher das zweite Byte (s. Bus 776) des Opcodes. Der RNID_2OP-Decoder hat ebenfalls den Eingang 768, der die Datengröße identifiziert.
Da die Decoder selbst die Länge des Opcodes nicht kennen, d. h. 1 oder 2 Bytes, und da das ModR/M-Byte immer dem Opcode folgt, wird der zweite RNID_MOD-Decoder 758 verwendet, um das dem 2-Byte Opcode folgende Byte (s. Bus 778) zu decodieren, wieder angenommen, dass es vorhanden ist. Die zwei RNID_MOD-Decoder sind identisch, decodieren aber verschiedene Bytes in dem Befehlsstrom.
Basierend wieder auf dem ESC_DET-Signal 774 wählt der RNID_SUM 760 die Ausgänge der geeigneten Opcode- und ModR/M-Byte-Decoder aus und gibt die Länge des Befehls auf dem Bus 762 aus. Der mit OVER8 bezeichnete Ausgang 764 zeigt an, ob der Befehl über 8 Bytes ist. Wenn die Länge des Befehls über 8 Bytes ist, zeigt der IR_NO[7:0] Bus 762 die Zahl von Befehlsbytes über 8 an.
Der RNID_1OP-Decoder 752 hat einen Ausgangsbus 780, der 9 Bits breit ist. Eine Leitung gibt an, ob der Befehl 1 Byte lang ist. Die zweite Leitung gibt an, dass der Befehl 1 Byte lang ist und dass ein ModR/M-Byte vorhanden ist, und daher sollte Information von dem ModR/M-Decoder bei der Bestimmung des Länge des Befehls eingeschlossen werden. Desgleichen geben die restlichen Ausgangsleitungen von Bus 780 die folgende Zahl von Bytes an: 2, 2/MOD, 3, 3/MOD, 4, 5 und 5/MOD an. Wenn der Befehl 4 Bytes lang ist, kann es kein ModR/M-Byte geben; dies ist inhärent in dem i486 Befehlssatz. Die vorliegende Erfindung ist jedoch in keiner Weise auf einen spezifischen CISC-Befehlssatz begrenzt. Die Fachleute in der Technik werden in der Lange sein, die Merkmale der vorliegenden Erfindung anzuwenden, um jeden CISC-Befehlssatz abzugleichen und zu decodieren.
Der RNID_2OP-Decoder 754 hat einen Ausgangsbus 782, der 6 Bits breit ist. Eine Leitung gibt an, ob der Befehl 1 Byte lang ist. Die zweite Leitung gibt an, dass der Befehl 1 Byte lang ist und ein ModR/M-Byte einschließt, das bei der Bestimmung der Länge des Befehls eingeschlossen werden soll. Desgleichen geben die restlichen Ausgangsleitungen von Bus 782 an, dass 2, 2/Mod, 3 und 5/Mod vorhanden sind. Es gibt keine anderen möglichen Befehlslängen, die der i486 Befehlssatz unterstützt, wenn der Opcode 2 Bytes lang ist.
Ausgänge 784 und 786 der zwei RNID_MOD-Decoder 756 und 758 geben dem RNID_SUM 760 die fünf möglichen zusätzlichen Längen an, die durch das ModR/M-Byte spezifiziert werden können. Jeder RNID MOD-Decoder hat einen 5 Bit breiten Ausgangsbus. Die fünf möglichen zusätzlichen Längen sind 1, 2, 3, 5 und 6 Bytes. Das ModR/M-Byte selbst ist in der Gesamtlängenbestimmung enthalten. Alle restlichen Bytes umfassen Sofort- oder Versetzungsdaten.
8 zeigt ein Blockschaltbild des IDDD 326. Der IDDD bestimmt die Schiebebeträge für den IMM-Schieber 312 und den DISP-Schieber 314. Der Schiebebetrag wird durch das ModR/M-Byte des Befehls bestimmt.
Der i486 Befehlssatz enthält zwei spezielle Befehle: enter_detect und jump_call_detect. Der IDDD hat daher einen Block, der Immediate Special Detector (ISD) 802 genannt wird, um die Decodierung dieser Befehle zu handhaben. Ein Eingang 803 zu dem ISD ist das erste Byte des Befehls. Zwei Ausgangsleitungen EN_DET und JMP_CL_DET (820 bzw. 822) geben an, ob einer der entsprechenden Befehle erfasst wird.
MOD_DEC-Decoder 804 und 806 sind identisch und decodieren Sofort- und Versetzungsdaten. Basierend auf ADD_SZ 722 schaut der Decoder 804 auf das ModR/M-Byte einen 1-Byte Opcode annehmend, und der Decoder 806 schaut auf das ModR/M-Byte einen 2-Byte Opcode annehmend. Das Befehlsbyteeingänge in MOD_DEC 804 und 806 sind 805 bzw. 807. Diese Decoder bestimmen die Versetzungsposition und die Sofortdatenposition in dem Befehlsstrom. Zwei Siebenleitung-Ausgänge 824 und 826 geben an, an welcher Position die Versetzung und die Sofortdaten beginnen. Die Versetzung kann an Position 2 oder Position 3 beginnen, und die Sofortdaten können an Position 2, 3, 4, 6 oder 7 beginnen.
Die MOD_DET-Leitungen 707 und 714 werden auch in den Selekt-Block 812 eingegeben. Der Selekt-Block 812 kombiniert die EN_DET- und JMP_CL_DET-Signale, die MOD_DET- und MOD_DEC-Ergebnisse und das ADD_SZ und gibt seine Ergebnisse auf vier Bussen 832–838 aus. Eine Versetzung 1 (DISP_1) Bus 832 gibt die Versetzungsschiebeergebnisse in der Annahme eines 1-Byte Opcodes aus. Eine Versetzung 2 (DISP_2) Bus 834 gibt die Versetzungsschiebeergebnisse in der Annahme eines 2-Byte Opcodes aus. IMMediate 1 und 2 (IMM_1 und IMM_2) Busse 836 und 838 geben die Sofortdaten-Schiebeinformation in der Annahme eines 1-Byte bzw. 2-Byte Opcodes aus.
Ein letzter Block 814, bezeichnet MOD_SEL/DLY, wählt tatsächlich die geeigneten Schiebebeträge aus und verzögert diese Ergebnisse um einen Halbzyklus. Die von dem MOD_SEL_DLY 814 durchgeführte Halbzyklus-Verzögerung stellt die in 3 gezeigte Verzögerung 316 dar. Das oben beschriebene Signal ESC_DET 774 wird durch den MOD_DEL_DLY-Block benutzt, um die Schiebeauswahl durchzuführen. Die Ergebnisse werden durch die Taktsignale CLK0 und CLK1 nach einer Halbzyklus-Verzögerung aus dem MOD_SEL_DLY 814 ausgetaktet. Das Sofortdaten-Schiebesteuersignal und das Versetzungs-Schiebesteuersignal werden über einen SHIFT_D[3:0] Bus 840 und einen SHIFT_I[7:0] Bus 842 an den DISP-Schieber und den IMM-Schieber gesendet. Die Zahl der möglichen Positionen der Sofort- und Versetzungsdaten in dem CISC-Befehl definiert die Zahl von Bits, die nötig ist, um den Betrag der Verschiebung zu spezifizieren.
9 zeigt ein Blockschaltbild des Präfix-Detektors 328. Der Präfix-Detektor 328 umfasst einen Präfixnummer-Decoder (PRFX_NO) 902, vier Präfixdetektor-Decoder (PRFX_DECs 904–910) und einen Präfix-Decoder (PRFX_SEL) 912.
Der i486 Befehlssatz umfasst z. B. 11 mögliche Präfixe. Insgesamt vier Präfixe können in einem Befehl enthalten sein, weil es mehrere ungültige Präfix-Kombinationen gibt. Die Reihenfolge der vier Präfixe wird auch durch den Befehlssatz definiert. Antstatt nur die legitimen Präfix-Permutationen zu erfassen, benutzt der Präfix-Detektor jedoch die vier Präfix-Detektoren 904–910, um jedes der ersten 4 Bytes des Befehls zu decodieren. Die ersten 4 Bytes des Befehls werden auf einem Bus 901 in den Präfix-Decoder eingegeben. Jeder Detektor 904–910 hat einen Ausgangsbus (905, 907, 909 und 911), der 12 Bits breit ist. Die 12 Ausgänge geben an, welche Präfixe vorhanden sind, wenn überhaupt welche tatsächlich dedodiert werden. Das zwölfte Präfix wird UNLOCK genannt, was das funktionale Gegenstück des i486 LOCK-Präfixes ist, und steht nur Mikrocode-Routinen während des Emulationsmodus zur Verfügung.
Ein ALIGN_RUN-Steuersignal 920 kann eingeschlossen sein, um den Präfix-Decoder freizugeben bzw. zu sperren, und kann benutzt werden, um alle Präfixe auszumaskieren. Ein HOLD_PRFX-Steuersignal 922 wird benutzt, um die Präfix-Information zu verriegeln und zu halten. Generell muss zum Abgleich eines Befehls, wenn der Präfix-Detektor 328 angibt, dass Präfixe vorhanden sind, die Steuerlogik die Präfix-Information verriegeln. Die Präfix-Information wird von dem Abgleich-Schieber 310 verwendet, um die Präfixe auszuschieben. Im folgenden Zyklus bestimmt die IAU die Länge des Befehls, gleicht ihn ab und übergibt ihn an die IDU.
Der PRFX_NO-Decoder 902 gibt an, wo und wie viele Präfixe vorhanden sind, durch Decodieren der ersten 4 Bytes des Opcodes. 10 zeigt ein Logikdiagramm des PRFX_NO-Decoders 902. Der PRFX_NO-Decoder umfasst vier identische Decoder 1002–1008 und einen Satz von Logikgattern 1010. Die vier Decoder 1002–1008 schauen je auf eines der ersten 4 Bytes (1010–1013) und stellen fest, ob ein Präfix vorhanden ist. Da es möglich ist, dass ein Präfix-Byte einem Opcode-Byte folgt, werden die Logikgatter 1010 verwendet, um ein Ergebenis auszugeben, das der Gesamtzahl von Präfixen vor dem ersten Opcode-Byte darstellt, weil Präfixe, die einem Opcode folgen, nur auf den Opcode des nächsten Befehls zutreffen.
Die Gesamtzahl von Präfixen ist eins, wenn das erste Byte (Position) ein Präfix ist und es in der zweiten Position kein Präfix gibt. Als werteres Beispiel macht ein Präfix in der vierten Position nichts aus, sofern es keine Präfixe in den ersten drei Positionen gibt. Ein von dem unteren NAND-Gatter 1014 ausgegebenes logisches Hoch (1) gibt an, dass vier Präfixe vorhanden sind; ein von dem zweitletzten NAND-Gatter 1015 ausgebenes Hoch gibt an, dass es drei Präfixe gibt, usw. Die Ausgänge der vier NAND-Gatter werden kombiniert, um einen PREFIX_NO Bus 1018 zu bilden, um die Gesamtzahl von gültigen Präfixen anzugeben, die dem ersten Opcode-Byte vorangehen, d. h. der Schiebebetragsausgang des Präfix-Detektors 328.
Der PRFX_NO-DEcoder 902 enthält auch einen Prefix_Present (PRFX_P) Ausgangsbus 1020, der auch 4 Bits breit ist. Vier PRFX_P-Ausgangsleitungen 1020–1023 geben an, ob es ein Präfix in der gegebenen Position gibt oder nicht, ungeachtet, was die anderen Positionen ausgeben. Die PRFX_P-Ausgänge werden direkt von den vier Decoder- (1002–1008) Ausgängen abgegriffen.
Die PRFX_NO-Decoderergebnisse (in Verbindung mit 10 zu erörtern) und die Information von den PRFX_DEC-Detektoren 904–910 werden durch den PRFX_SEL-Decoder 912 kombiniert. Die Präfix-Information wird kombiniert, um einen 13-Bit Ausgangsbus 924 zu bilden, der angibt, ob es Präfix-Signale gibt und welche Präfixe vorhanden sind.
3.0 Übersicht der Decodiereinheit
Alle Befehle werden von der IAU an eine Befehlsdecodiereinheit (IDU) übergeben und werden direkt in RISC-Befehle übersetzt. Alle von der IEU auszuführenden Befehle werden durch die IDU verarbeitet. Die IDU stellt fest, ob jeder Befehl ein emulierter Befehl oder ein Grundbefehl ist. Wenn er emuliert ist, wird die Mikrocode-Emulationsroutine, die ganz aus Grundbefehlen besteht, ausgeführt. Wenn es ein Grundbefehl ist, wird er direkt durch Hardware in 1 bis 4 Nanobefehle übersetzt und an die IEU gesendet. Es sind diese Nanobefehle und nicht die ursprünglichen CISC- oder Mikrocode-Befehle, die die IEU tatsächlich ausführt.
Die Aufteilung von Befehlen hat zwei wesentliche Vorteile: Die Hardware wird klein gehalten, weil sie nur einfache Operationen unterstützen muss, und Fehler sind weniger mühsam, weil sie wahrscheinlicher in den komplexen Mikrocode-Routinen auftreten, die leicht geändert werden können.
Die Mikrocode-Routinen-Unterstützungshardware der IDU in Verbindung mit der vorliegenden Erfindung hat verschiedene Merkmale, die sie einmalig machen. Typischerweise bestehen Mikrocode-Befehle aus Steuerbits für die verschiedenen in einem Prozessor vorhandenen Datenwege, mit wenig oder keiner Codierung. Der Mikrocode der vorliegenden Erfindung ist dagegen eine vergleichbar hochstufige Maschinensprache, die bestimmt ist, einen spezifischen komplexen Befehlssatz zu emulieren. Während typischer Mikrocode direkt zu den Funktionseinheiten eines Prozessors geleitet wird, wird der Mikrocode der vorliegen den Erfindung durch die gleiche Decoderlogik verarbeitet, die für die Ziel-CISC- (z. B. 80 × 86) Befehle benutzt wird. Dies gibt dem Mikrocode der vorliegenden Erfindung eine viel bessere Codedichte als sie mit typischem Mikrocode erreicht werden kann, und macht den Mikrocode infolge seiner Ähnlichkeit mit dem Ziel-CISC-Befehlssatz leichter zu entwickeln. Außerdem stellt die vorliegende Erfindung Hardwareunterstützung für Mikrocode-Revisionen bereit: Ein Teil oder der ganze On-Chip-ROM-basierte Mikrocode kann unter Softwaresteuerung durch externen RAM-basierten Mikrocode ersetzt werden. (siehe gemeinsam besessene, mitanhängige Anmeldung betitelt "A ROM With RAM Cell und Cyclic Redundancy Check Circuit", Seriennummer 07/802, 816, eingereicht 12/6/91, Anwalts-Aktenzeichen Nr. SP024; deren Offenbarung hierin durch Verweis eingeschlossen ist.)
Die Mikrocode-Maschinensprache ist bestimmt, ein Satz von Befehlen zu sein, der durch den RISC-Kern ausgeführt werden kann, um die von allen komplexen, emulierten Befehlen verlangten Funktionen durchzuführen, plus die verschiedenen Steuer- und Wartungsfunktionen, die mit der Ausnahme-Behandlung verbunden sind. Obwohl emulierte Befehle typischerweise weniger leistungsempfindlich als nicht emulierte (Grund) Befehle sind, und Ausnahmen (die durch Mikrocode-Routinen behandelt werden) selten vorkommen, ist es noch immer für den Gesamtsystemdurchsatz wichtig, dass beide effizient gehandhabt werden. Dieses Ziel wird durch die Verwendung verschiedener Formen von Hardware-Unterstützung für die Mikrocode-Routinen erreicht. Die vorliegende Erfindung umfasst vier Bereiche von Hardware-Unterstützung für Mikrocode: Dispatch-Logik, Mailboxen, ein Nanobefehlsformat und spezielle Befehle.
Die Mikrocode-Dispatch-Logik steuert die effiziente Übertragung der Programmsteuerung von dem Ziel-CISC-Befehlsstrom auf eine Mikrocode-Routine und zurück auf den Ziel-Befehlsstrom. Dies wird mit einer kleinen Menge an Hardware und in einer Weise gehandhabt, die für die Befehlsausführungseinheit (IEU) des RISC-Kerns transparent ist. (Die IEU führt die RISC-Befehle aus. Der vorerwähnte "RISC-Kern" ist synonym mit der IEU. Die Einzelheiten der IEU sind für eine in der Technik erfahrene Person nicht erforderlich, um die vorliegende Erfindung zu praktizieren. Die Merkmale der vorliegenden Erfindung sind auf RISC-Prozessoren im Allgemeinen anwendbar.)
Die Mailboxen umfassen ein System von Registern, die benutzt werden, um Information von der Befehlsdecodier-Hardware in einer systematischen Weise auf Mikrocode-Routinen zu übertragen. Dies erlaubt der Hardware, Befehlsoperanden und ähnliche Daten an die Mikrocode-Routinen zu übergeben, was ihnen die Aufgabe erspart, diese Daten aus dem Befehl zu extrahieren.
Das Nonobefehlsformat beschreibt die Information, die von der IDU zu der IEU fließt. Dieses Format wurde gewählt, um ihm zu erlauben, effizient aus den Quellen-CISC-Befehlen extrahiert zu werden, aber noch angemessene Information an die IEU zur Abhängigkeitsprüfung und Funktioneinheitssteuerung liefert.
Schließlich, die speziellen Befehle sind ein Satz von zusätzlichen Befehlen, der bereitgestellt wird, um eine vollständige Steuerung der RISC-Hardware zu erlauben und bestimmte einmalige Emulationsaufgaben in Hardware zu unterstützen, und sind spezifisch für den CISC-Befehlssatz.
3.1 Mikrocode-Dispatch-Logik
Der erste Schritt beim Befördern von Mikrocode ist, die Adresse der Mikrocode-Routine zu bestimmen. Dieser Schritt hat wichtige Anforderungen: Jede Mikrocode-Routine muss eine einmalige Startadresse haben, und diese Adresse muss schnell erzeugt werden. Für Ausnahme-Behandlungsroutinen ist dies recht einfach zu erreichen, da es die kleine Zahl von Fällen, die behandelt werden muss, der Hardware erlaubt, die Adressen als Konstanten zu speichern und lediglich zwischen ihnen auszuwählen. Das Bestimmen der Adressen für emulierte Befehle ist jedoch schwieriger, weil es zu viele gibt, um das Speichern aller Adressen möglich zu machen.
Die Mikrocode-Dispatch-Logik erfüllt diese Forderungen, indem sie die Dispatch-Adresse jedes Befehls direkt auf seinen Opcode gründet. Zum Beispiel werden 1-Byte Opcodes direkt in den Adressraum von OH bis 1FFFH abgebildet, was erfordert, dass die oberen 3 Bits der 16-Bit Dispatch-Adresse nullen sind. Diese Mikrocode-Einsprungpunkte sind 64 Bytes voneinander beabstandet, was erfordert, dass die sechs niedrigstwertigen Bits jeder Einsprungpunktadresse nullen sind. Dies lässt 7 Bits unbestimmt, und sie können direkt von sieben der Opcode-Bits genommen werden. Das Erzeugen der Adressen in dieser Weise benötigt sehr wenig Logik, wie die Fachleute erkennen werden. Zum Beispiel kann ein Multiplexer allein benutzt werden, um die richtigen Bits aus dem Opcode auszuwählen.
Sobald die Dispatch-Adesse für eine Mikrocode-Routine bestimmt ist, muss der Mikrocode aus dem Speicher geholt werden. Typisch liegt der Mikrocode in einem On-Chip-ROM, aber dies ist nicht unbedingt der Fall. Wie in der oben erwähnten Anmeldung Nr. 07/802,818 angeführt, ist jeder Einsprungpunkt mit einem ROM-Ungültig-Bit verbunden, das angibt, ob die ROM-Routine richtig ist oder nicht. Dieses Bit wird parallel mit dem ROM-Zugriff geholt und funktioniert ähnlich einem herkömmlichen Cache-Bit-Indikator. Wenn dieses Bit angibt, dass der ROM-Eintrag gültig ist, wird das Holen der Mikrocode-Routine aus dem ROM fortgesetzt, und sie wird normal ausgeführt. Wenn das Bit angibt, dass das ROM ungültig ist, wird der Mikrocode aus einem externen Speicher, z. B. einem RAM oder dergleichen, geholt.
Die Adressierung von On-Chip-Mikrocode-Routinen wird durch die IDU selbst gehandhabt. Die IDU erzeugt 16-Bit Adressen für Zugriffe auf des Mikrocode-ROM. Wenn das ROM-Ungültig-Bit, das dem grade adressierten ROM-Eintrag entspricht, angibt, dass der Mikrocode ungültig ist, wird die Adresse von externem Mikrocode berechnet, der außerhalb des Chips im Hauptspeicher liegt. Ein U_Base-Register hält die oberen 16 Adressbits (genannt Startadresse) des externen Mikrocodes, der in Hauptspeicher liegt. Die von der IDU decodierte 16-Bit Adresse wird mit den oberen 16 Bits in dem U_Base-Register verkettet, um auf den im Hauptspeicher liegenden externen Mikrocode zuzugreifen. Wenn die Stelle des im Hauptspeicher liegenden externen Mikrocodes geändert wird, kann der Inhalt des U_Base-Registers modifiziert werden, um die neue Hauptspeicherstelle widerzuspiegeln.
Dises Merkmal erlaubt es, Mikrocode-Aktualisierungen durch Ersetzen bestimmter Routinen durch Alternative im externen Speicher durchzuführen, ohne den ganzen Mikrocode zu zwingen, unter der reduzierten Leistung von Externspeicherzugriffen zu leiden. Es macht es auch möglich, das ganze ROM aus dem RISC-Chip zu entfernen und den ganzen Mikrocode in ein externes RAM zu legen, um den Flächenbedarf des RISC-Chips zu verringern oder bei der Entwicklung von Mikrocode zu helfen.
Die Dispatch-Logik ist auch verantwortlich für das Bereitstellen einer Einrichtung für die Mikrocode-Routine, um zu dem Hauptbefehlsstrom zurückzukehren, wenn ihre Aufgabe beendet ist. Um dies zu handhaben, werden getrennte Programmzähler (PCs) und Befehlspuffer unterhalten. Während des normalen Betriebs bestimmt der Haupt-PC die Adresse jedes CISC-Befehls im externen Speicher. Ein Speicherabschnitt, der diese Befehle enthält, wird von der IFU geholt und in dem MBUF gespeichert.
Wenn ein emulierter Befehl oder eine Ausnahme erfasst wird, werden der PC-Wert und die Länge des gegenwärtigen Befehls in einem Zwischenpuffer gespeichert, während die Mikrocode-Dispatch-Adresse wie oben beschrieben berechnet wird und Befehle aus dieser Adresse in den EBUF geholt werden. Der Mikrocode wird aus dem EBUFausgeführt, bis ein Mikrocode-Rückkehr-Befehl erfasst wird, zu welcher Zeit der bewahrte PC-Wert zurückgeladen wird, und die Ausführung geht aus dem EBUF weiter. Da der EBUF und alle anderen betroffenen Register währen der Übergabe der Steuerung an die Mikrocode-Routine bewahrt werden, geschieht die Rückübergabe an das CISC-Programm sehr schnell.
Es gibt zwei Rückkehr-Befehle, die von Mikrocode-Routinen benutzt werden, um die Unterschiede zwischen Befehls-Emulationsroutinen und Ausnahme-Behandlungsroutinen zu unterstützen. Wenn die Mikrocode-Routine zum Zweck des Behandelns einer Ausnahme betreten wird, ist es wichtig, dass, nachdem die Routine beendet ist, der Prozessor genau zu dem Zustand zurückkehren soll, in dem er unterbrochen wurde. Wenn die Mikrocode-Routine zum Zweck des Emulierens eines Befehls betreten wird, wird jedoch die Routine zu dem Befehl zurückkehern, der dem emulierten Befehl folgt. Andernfalls wird die Emulationsroutine ein zweites Mal ausgeführt. Diese zwei Funktionen werden durch die Verwendung von zwei Rückkehr-Befehlen gehandhabt: aret und eret. Der Befehl aret bringt den Prozessor in den Zustand zurück, als der Mikrocode betreten wurde, während der Befehl eret bewirkt, dass der PC aktualisiert wird und die Steuerung zu dem nächsten Befehl in dem Zielstrom zurückkehrt.
3.2 Mailboxen
Damit Emulationsroutinen die Funktionen eines komplexen CISC-Befehls erfolgreich durchführen, ist es nötig, dass der Mikrocode einen bequemen Zugriff auf die von dem emulierten Befehl benannten Operanden hat. Bei der vorliegenden Erfindung wird dies durch die Verwendung von Mailbox-Registern durchgeführt. Diese Register sind nur in ihrem Gebrauch einmalig. Sie sind als die ersten vier eines Satzes von 16 Zwischenregistern in der Ganzzahl-Registerdatei, die dem Mikrocode zur Verfügung stehen. Jede Emulationsroutine, die Operanden oder andere Information von dem ursprünglichen Befehl benötigt, kann erwarten, diese Werte in einem oder mehr der Mailbox-Register beim Eintreten in die Routine gespeichert zu finden. Wenn die IDU einen emulierten Befehl erfasst, erzeugt sie Befehle, die von der IEU benutzt werden, um die Register mit den Werten zu laden, die der Mikrocode erwartet, bevor die Ausführung der Mikrocode-Routine selbst beginnt.
Man betrachte z. B. die Emulation des Befehls 'Load Machine Status Word' (Imsw), der eines der allgemeinen Register als einen Operanden spezifiziert. Angenommen, der zu emulierende spezifische Befehl ist Imsw ax, der ein 16-Bit Statuswort aus dem Register "ax" lädt. Die gleiche Mikrocode-Routine wird ungeachtet des tatsächlich in dem Befehl spezifizierten Registers benutzt, sodass für diesen Befehl Mailbox#0 mit dem Statuswort vor Eintritt in den Mikrocode geladen wird. Wenn die IDU diesen Befehl erfasst, wird sie einen Befehl mov u0, ax für die IEU erzeugen, um das Statuswort aus dem Register "ax" in das Register "u0" zu schieben, das als Mailbox#0 definiert ist. Nachdem dieser mov-Befehl an die IEU gesendet ist, wird die Mikrocode-Routine geholt und gesendet werden. Der Mikrocode kann daher geschrieben werden, als ob der emulierte Befehl Imsw u0 wäre, und er wird alle möglichen O peranden, die in dem ursprünglichen CISC-Befehl spezifiziert sein können, richtig behandeln.
3.3 Nano-Befehlsformat
Wie oben erwähnt, werden CISC-Befehle durch die IDU in Nanobefehle decodiert, die durch den RISC-Prozessorkern, als IEU bezeichnet, verarbeitet werden. Nanobefehle werden von der IDU in Gruppen von vier, genannt "Kübel", an die IEU übergeben. 11 zeigt einen einzelnen Kübel. Jeder Kübel besteht aus zwei Paketen plus allgemeiner Information, die zu dem ganzen Kübel gehört. Paket #0 enthält immer drei Nanobefehle, die in Reihenfolge ausgeführt werden: Ein LOAD-Befehl 1102, ein ALU-Typ Befehl 1104 und ein STORE-Befehl 1106. Paket #1 besteht aus einem einzelnen ALU-Typ Befehl 1108.
Die IEU kann Kübel von der IDU bei einer Spitzenrate von einem pro Zyklus annehmen. Die IDU verarbeitet Grundbefehle bei einer Spitzenrate von zwei pro Zyklus. Da die meisten Grundbefehle in ein einziges Paket übersetzt werden, können gewöhnlich zwei Grundbefehle in einen Kübel gelegt und zusammen an die IEU übergeben werden. Die Haupteinschränkung dieser Rate besteht darin, dass die Grunbefehle der Anforderungan eines Kübels entsprechen müssen:
Nur einer der zwei Grundbefehle kann auf einen Speicheroperanden verweisen (es gibt nur eine Laden/Speichern-Operation pro Kübel), und beide Befehle müssen aus einer einzigen ALU-Typ Operation bestehen (im Gegensatz zu einem Befehl, der zwei ALU-Typ Operationen benötigt).
Wenn eine oder beide dieser Einschränkungen verletzt werden, wird der Kübel an die IEU mit Nanobefehlen gesendet, die nur einem der Grundbefehle entsprechen, und der restliche Befehl wird in einem späteren Kübel gesendet. Diese Anforderungen spiegeln nahe die Fähigkeiten der IEU, d. h. eine IEU mit zwei ALUs und einer Laden/Speichern-Einheit, so dass sie in Wirklichkeit keine Einschränkung der Leistung darstellen. Ein Beispiel dieses Typs von IEU wird in gemeinsam besessenen, mitanhängigen Anmeldungen betitelt "High Performance RISC Microprocessor Architecture", Seriennummer 07/817,810, eingereicht 1/8/92, (Aktenzeichen Nr. SP015/1397.0280001) und "Extensible RISC Microprocessor Architecture", Seriennummer 07/817,809, eingereicht 1/8/92, (Aktenzeichen Nr. SP021/1397.0300001) offenbart, deren Offenbarungen hierin durch Verweis eingeschlossen sind.
3.4 Spezielle Befehle
Es gibt viele Befehle, die durch Mikrocode-Routinen ausgeführt werden müssen, die mit Uni versalbefehlen schwer oder uneffizient durchzuführen sind. Des Weiteren sind infolge der erweiterten Architektur des vorliegenden RISC-Prozessors verglichen mit herkömmlichen Prozessoren bestimmte Funktionen hilfreich, während solche Funktionen für einen CISC-Prozessor unbedeutend sein würden, und daher mittels irgendeiner Kombination von CISC-Befehlen nicht ausgeführt werden können. Gemeinsam führten diese Gegebenheiten zur Schaffung von "speziellen Befehlen".
Ein Beispiel der ersten Kategorie von Spezialbefehlen ist der Befehl extract_desc_base. Dieser Befehl extrahiert verschiedene Bitfelder aus zweien der Mikrocode-Universalregister, verkettet sie und legt das Ergebnis in das dritte Universalregister zur Verwendung durch Mikrocode. Um die gleiche Operation ohne den Nutzen dieses Befehls durchzuführen, müsste der Mikrocode mehrere Maskier- und Schiebeoperationen durchführen und müsste zusätzliche Register verwenden, um Zwischenwerte zu halten. Der Spezialbefehl erlaubt es, die gleiche Funktionalität mit nur einem Befehl während eines einzigen Zyklusses und ohne Verwendung irgendeines Scratch-Registers durchzuführen.
Zwei Beispiele der zweiten Kategorie von Spezialbefehlen wurden bereits präsentiert: Die zwei Rückkehr-Befehle aret und erst, die zum Beenden von Mikrocode-Routinen benutzt werden. Diese Befehle sind nur in der Mikrocode-Umgebung von Bedeutung und haben daher keine gleichwertigen Befehle oder Befehlsfolgen in der CISC-Archtektur. In diesem Fall wären Spezialbefehle zur richtigen Funktionalität, nicht nur aus Gründen der Leistung, erforderlich.
Da die Spezialbefehle nur den Mikrocode-Routinen zur Verfügung stehen und emulierte Befehle nur in dem Ziel-CISC-Befehlsstrom angetroffen werden können, werden die Opcodes von emulierten Befehlen im Mikrocode-Modus für die Spezialbefehle wiederverwendet. Wenn daher einer dieser Opcodes in dem Ziel-CISC-Befehlsstrom angetroffen wird, gibt er lediglich an, dass die Mikrocode-Emulationsroutine für diesen Befehl ausgeführt werden soll. Wenn aber der gleiche Opcode in dem Mikrocode-Befehlsstrom angetroffen wird, hat er eine vollständig andere Funktion als einer der Spezialbefehle. Um diese Opcode-Wiederverwendung zu unterstützen, verfolgt die IDU den momentanen Prozessorstatus und decodiert die Befehle geeignet. Diese Wiederverwendung von Opcodes ist für die IEU transparent.
Die IDU decodiert jeden CISC-Befehl (z. B. des i486 Befehlssatzes) und übersetzt jeden Befehl in mehrere RISC-Prozessor-Nanobefehle. Wie oben beschrieben, wird jeder CISC-Befehl in 0 bis 4 Nanobefehle, abhängig von seiner Komplexität und Funktionalität, übersetzt. Die IDU decodiert und übersetzt bestenfalls zwei CISC-Befehle pro Zyklus. Die Grundfunk tionen der IDU können wie folgt zusammengefasst werden, sie funktioniert um:

– Einen CISC-Befehl pro Halbzyklus zu decodieren;
– den ersten CISC-Befehl in einer ersten Phase zu decodieren;
– die decodierten Ergebnisse des ersten CISC-Befehls durch die zweite Phase als gültig zu halten;
– den zweiten CISC-Befehl in der zweiten Phase zu decodieren; die Ausgänge von zwei Befehlen, wenn möglich, in der dritten Phase zu kombinieren, und
– einen Kübel auszugeben, der vier Nanobefehle pro Zyklus enthält.

3.5 Blockschaltbilder der Decodiereinheit
12 zeigt ein Blockschaltbild der IDU. Abgeglichene Befehle von der IAU treffen an der IDU auf einem Bus 1201 ein, der 32 Bits breit ([31:0] oder 4 Bytes) ist. Die abgeglichenen Befehle werden durch einen Befehlsdecoder 1202 empfangen. Der IDU 1202 schaut nur auf die ersten 4 Bytes eines abgeglichenen Befehls, um die CISC-RISC-Übersetzung durchzuführen.
Der Befehlsdecoder 1202 arbeitet in einer Taktphase (ein Halbzyklus) Der abgeglichene Befehl durchläuft den Decoder, und die decodierte Informtation, die austritt, wird gemultiplext und über einen Bus 1203 in ein Halbzyklus-Verzögerungs-Latch 1204 geführt. Die decodierte Information erfährt daher das Äquivalent zu einer Phasen-Pipeline-Verzögerung.
Nach der Halbzyklus-Verzögerung wird die decodierte Information über einen Bus 1205 an einen MUX 1206 gesendet, um die tetsächlich benutzten Registercodes zu bestimmen. In dieser Stufe der Decodierung wird die decodierte Information in dem Nanobefehlsformat angeordnet. Der Nanobefehl wird dann verriegelt. Pro Zyklus werden zwei vollständige Nano-Befehlskübel verriegelt. Das Verriegeln von zwei Nanobefehlskübeln wird schematisch durch den ersten IR-Kübel 1208 und den zweiten IR-Kübel 1210 gezeigt.
Die IDU versucht, die Behälter 1208 und 1210 in einen einzigen Kübel 1212 zusammenzusetzen. Dieses Zusammensetzen wird durch einen Satz von Steuergattern 1214 durchgeführt. Die IDU schaut zuerst auf den Typ jedes Nanobefehls und stellt fest, ob die Typen so sind, dass sie kombiniert werden können. Man beachte, dass jede LoaD (LD) Operation der zwei verriegelten Befehle in eine LD-Stelle 1216 des einzelnen Kübels 1212 gelegt werden kann; jede STore (ST) Operation der verriegelten Befehle in eine ST-Stelle 1218 des einzelnen Kübels gelegt werden kann; jede A0-Operation in eine A0-Stelle 1220 gelegt werden kann, und jede A0- oder A1-Operation in eine A1-Stelle 1222 gelegt werden kann.
Die IDU behandelt die Befehle als Ganzes. Wenn die IDU die zwei Befehle nicht in einen Kübel packen kann, wird sie einen vollständigen Befehl zurücklassen. Wenn z. B. das erste IR-Latch nur eine A0-Operation enthält und das zweite IR-Latch alle vier Operationen enthält, wird die IFU die A1 nicht aus dem zweiten IR-Latch nehmen und sie mit der A0-Operation verschmelzen. Die A0-Operation wird durch sich selbst gesendet werden, und der Satz von Operationen des zweiten IR-Latchs wird an das erste IR-Latch übertragen und in der nächsten Phase gesendet, während welcher Zeit das zweite IR-Latch neu geladen wird. Mit anderen Worten, die in dem ersten IR-Latch gespeicherten Operationen werden immer gesendet, und die in dem zweiten IR-Latch gespeicherten Operationen werden, wenn möglich, mit den Operationen des ersten IR-Latchs kombiniert. Die vorherigen Pipeline-Stufen der IDU und IAU müssen in dem Fall warten, dass das erste und zweite IR nicht kombiniert werden können. Die folgenden Situationen erlauben der IDU, die Operationen des ersten und zweiten IR-Latchs zu kombinieren:

1. beide verwenden nur A0 oder
2. nur eines verwendet A0 und das andere verwendet nur A0, LD und ST.

Kombinationslogik kann von den Fachleuten in der Technik ohne werteres entworfen wer den, um die nötigen Steuersignale für die Steuergatter zu erzeugen, um den Inhalt des ersten und zweiten IR-Latchs zu verschmelzen, basierend auf der oben erörterten Funktionalität und der Grundlogik-Entwurfspraxis.
Der Emulationsmodus wird betreten, wenn die IDU einen Befehl identifiziert, der zu der Untermenge von Befehlen gehört, die Emulation erfordern. Ein EMULation MODE Steuersignal (EMUL_MODE) wird an die Decoder der IDU gesendet, sobald der Emulationsmodus betreten ist. Die direkte Decodierung des CISC-Befehls hält an, und die Mikrocode-Routine, die diesem identifizierten Befehl entspricht, wird zur Decodierung an die IDU gesendet. Die IDU-Decoder kehren in den Grundmodus zur Decodierung weiterer CISC-Befehle zurück, wenn die Mikrocode-Routine mit der Emulation des Untermengen-Befehls fertig ist. Grundsätzlich werden CISC-Befehle und Mikrocode-Befehle durch die IDU in der gleichen Weise gehandhabt. Nur die Interpretation der Opcodes ändert sich.
Karnaugh-Pläne des Vorgabe- (Grund) Modus für 1-Byte und 2-Byte Opcode-Befehle werden in 13A–13C gezeigt. Die Zahlen auf den linken Seite und oben auf den Karnaugh-Plänen stellen die Opcode-Bits dar. Zum Beispiel entspricht ein als Hex 0F codierter Einbyte-Opcode der ersten Reihe und elften Spalte, was der "2 Byte Escape" Befehl ist.
Die Befehlskästen, die in dem Karnaugh-Plan von 13A–C grau schattiert sind, stellen Grundbefehle dar, und die weißen Kästen sind die Befehle, die emuliert werden werden müssen.
14 zeigt ein Blockdiagramm des Befehlsdecoders 1202 der IDU. Der Befehlsdecoder 1202 umfasst eine Vielzahl von Decodern, die benutzt werden, um die CISC-Befehle und Mikrocode-Routinen zu decodieren.
Ein TYPE GENerator (TYPE_GEN) Decoder 1402 empfängt die ersten voll abgeglichenen Befehle auf dem ALIGN_IR-Bus und decodiert Befehle einen zu einer Zeit, um das TYPE-Feld des Befehls zu identifizieren.
Das identifizierte TYPE-Feld entspricht den oben in Verbindung mit der IDU erörterten Nanobefehlen. Der Typ wird durch ein 4-Bit Feld bezeichnet, das jede Operation in einem Kübel (Load, ALU0, Store und ALU1) darstellt. Der TYPE_GEN-Decoder 1402 spezifiziert, welche dieser vier Operationen zum Ausführen des Befehls benötigt werden. Anhängig von dem empfangen Befehl kann jede Zahl von 1 bis 4 der Operationen benötigt werden, um dem CISC-Befehl zu genügen.
Zum Beispiel erfordert eine add-Operation, die den Inhalt eines Registers mit dem Inhalt eines anderen Registers summiert, nur eine ALU-Nanobefehls-Operation. Alternativ würde ein Befehl, der die Addition des Inhalts eines Register mit einer Speicherstelle verlangt, eine Load-Operation, eine ALU-Operation und dann eine Store-Operation benötigen, was insgesamt drei Nanobefehls-Operationen ergibt. (Die Daten müssen aus dem Speicher gelesen, zu dem Register addiert und dann in den Speicher zurückgespeichert werden). Kompliziertere CISC-Befehle können alle vier Nanobefehle benötigen.
Der TYPE_GEN-Decoder 1402 umfasst drei TYPE-Decoder. Ein erster Decoder TYPE1 nimmt an, dass der Befehl einen 1-Byte Opcode hat, gefolgt von dem ModR/M-Byte, und berechnet den Typ basierend auf dieser Annahme. Ein zweiter Decoder TYPE2 nimmt an, dass der Befehl einen 2-Byte Opcode hat. Wobei das erste Byte das ESCAPE-Byte ist, gefolgt von dem zweiten Byte, das der Opcode ist, und dem dritten Byte, das das ModR/M-Byte ist. Ein dritter Decoder TYPEF nimmt an, dass der Befehl ein Gleitpunkt-Befehl ist, und decodiert den Befehl basierend auf dieser Annahme.
Der TYPE_GEN-DEcoder hat drei 4 Bit breite TYPE-Befehlsausgabebusse (TYPE1, TYPE2 und TYPEF). Jedes Bit entspricht einer der vier Nanobefehls-Operation in einem Kübel. Das spezifische TYPE-Feld spezifiziert, welche Nanobefehls-Operation nötig sind, um den CISC-Befehl auszuführen. Wenn z. B. alle 4 Bits logisch hoch sind, benötigt des CISC-Befehl eine Laod-Operation, eine Store-Operation und zwei ALU-Operationen.
Die restlichen Decoder in 14, die mit 1, 2 und F bezeichnete Abschnitte umfassen, nehmen einen 1-Byte Opcode, einen 2-Byte Opcode bzw. eine Gleitpunkt-Operation an. Die ungültigen Ergebnisse werden einfach nicht ausgewählt. Ein Multiplexer wählt den Ausgang des richtigen Decoders aus.
Die zwei ALU-Operationen (ALU0 und ALU1) haben je ein Opcode-Feld, das 11 Bits lang ist. Die 11 Bits umfassen die 8 Bits des Opcodes und drei Opcode-Erweiterungsbits von dem angrenzenden ModR/M-Byte. Für die meisten von der IDU verarbeiteten CISC-Befehle werden die Opcode-Bits direkt in die Nanobefehls-Operation kopiert. Einige CISC-Befehle können jedoch Substitution erfordern, hier filtert die IDU nicht einfach den CISC-Opcode an die Befehls-Ausführungseinheit (IEU). Dies wird für die Fachleute in der Technik ersichtlich sein, weil der Typ und die Zahl von Funktionseinheiten in der IEU diktieren wird, ob eine Opcode-Ersetzung in der IDU für spezifische CISC-Befehle erforderlich ist oder nicht.
Damit die IEU ALU-Operationen verarbeitet, muss sie Information dahin gehend empfangen, welche Funktionseinheit benötigt wird, um die spezifizierte ALU-Operation zu verarbeiten. Die IDU enthält daher einen Functional-Null-UNIT (F_0UNIT) DEcoder 1410, der Decoder F_0UNIT1, F_0UNIT2 unf F_0UNITF umfasst. Die Ausgänge der Decoder sind Mehrbit-Felder, die angeben, welche Funktionseinheit zum Verarbeiten der A0-ALU-Operation benötigt wird. Die Funktionseinheit zum Decodieren der A1-ALU-Operation ist identisch, wird aber von einem getrennten Decoder F_1UNIT 1412 gehandhabt.
Viele CISC-Befehle führen Operationen unter Verwendung von Registern aus, die durch den Opcode zu verstehen gegeben werden. Zum Beispiel können viele Befehle zu verstehen geben, dass das AX-Register als ein Akkumulator zu verwenden ist. Ein ConSTant GENerator (CST_GEN) Decoder 1414 ist daher eingeschlossen, um Register-Indizes basierend auf dem Opcode des CISC-Befehls zu erzeugen. Der CST_GEN-Decoder spezifiziert basierend auf dem spezifischen Opcode, welche Register inbegriffen sind. Das Multiplexen zum Erzeugen der richtigen Quellen- und Ziel-Registerindizes für die Nanobefehle wird unten in Verbindung mit 15 erörtert.
Ein zusätzliches 2-Bit Steuersignal TempCount (TC) wird in den CST_GEN-Decoder eingegeben. Das TC-Steuersignal ist ein 2-Bit Zähler, der vier Zwischenregister darstellt, die zur Verwendung als Dummy-Register durch die IEU zyklisch durchlaufen werden können. Die Zwischen- (Dummy) Register stellen zusätzlich zu den inbegriffenen Registern einen anderen Wert von Register dar, der durch den CST_GEN-Decoder übergeben werden kann. Der Konstant-Generator-Decoder übergibt vier konstante Felder, weil es 2 ALU-Operationen mit 2 Registern pro Operation gibt. Jeder Konstant-Register-Bus ist 20 Bits breit, wobei jede Konstante insgesamt 5 Bits sind, um dadurch die Auswahl von einem der 32 Register in der IEU zu erlauben.
Ein SELect GENerator (SEL_GEN) Decoder, allgemein bei Block 1416 gezeigt, wird nun erörtert. Der SEL_GEN-Decoder umfasst einen FlaG Need Modify (FG_NM) Decoder 1418. Der FG_NM-Decoder decodiert für einen 1-Byte Opcode, einen 2-Byte Opcode und einen Gleitpunkt-Befehl. Im i486 Befehlssatz gibt es z. B. insgesamt 6 Flags. Diese Flags müssen gültig sein, bevor die Ausführung einiger Befehle beginnt, wobei die Flags von einigen Befehlen modifiziert werden können. Der FG_NM-Decoder gibt zwei Signale pro Flag aus, ein Bit gibt an, ob das Flag zur Ausführung dieses Befehls benötigt wird, und das andere gibt an, ob dieser Befehl das Flag wirklich modifiziert oder nicht.
Register INValiDation Information betreffend die ALU0- und ALU1-Operationen wird durch einen INVD1- und einen INVD2-Decoder, gezeigt bei 1420 bzw. 1422, decodiert. Die Decoder INVD1 und INVD1 sind auch Teil des SEL_GEN-Decoders 1416. INVD1 und INVD2 erzeugen Steuersignale für die IEU. Diese Signale geben an, ob die ALU-Register benutzt werden sollen oder nicht. Drei mögliche Register-Indizes können durch jede ALU-Operation spezifiziert werden. Einer kann als ein Quellen- und/oder Zielregister verwendet werden, und die restlichen zwei sind auf das Spezifizieren von Quellenregistern beschränkt. Ein 4-Bit Feld wird benutzt, um zu spezifizieren, welches Register von der Operation benötigt wird.
Der SEL_GEN-Decoder 1416 umfasst weiter einen FLD_CNT-Decoder 1424, der angibt, welches der Registerfelder für den CISC-Befehl benötigt wird. Der FLD_CNT-Decoder spezifiziert, welches der zwei Felder das Quellenregister und welches das Zielregister ist.
Ein Nano-InstRuction GENerator (NIR_GEN) Decoder wird allgemein als Block 1426 gezeigt. Die Datengrößen- (DATA_SZ) und Adressgrößen- (ADDR_SZ) Eingangssteuersignale entsprechen dem Vorgabemodus, in dem das System arbeitet. Um die endgültige Adresse und Operandengröße zu decodieren, muss der Vorgabemodus bekannt sein, und die Anwesenheit irgendwelcher Präfixe (oben in Verbindung mit der IAU erörtert) muss bekannt sein. Das EMUL_MODE-Steuersignal wird auch in den NIR_GEN-Decoder eingegeben, aber es wird auch von den anderen Decodern verwendet.
Das ESCape DETect (ESD_DET) Eingangssteuersignal wird in den NIR_GEN-Decoder geführt, um anzugeben, ob der Befehl einen 2-Byte Opcode hat. Außerdem wird ein SELect OPcode EXTension (SEL_OP_EXT) Eingangssteuersignal verwendet, um das Laden der Mailboxen zu erzeugen, wenn ein Emulationsbefehl erfasst wird.
Ein Floating Point REGister (FP_REG) Eingangssteuersignal leitet den übersetzten Gleitpunkt-Registerindex an die IDU. Das Gleitpunktformat des i486 hat z. B. 8 Register für Gleitpunkzahlen, aber auf die Register wird wie ein Stack zugegriffen. Das Zugreifen auf diese Register wird mittels eines Stack-Zugriffsschemas durchgeführt: Register 0 ist das höchste Register des Stacks, Register 1 ist das zweithöchste Register usw. Dieser Register-Stack wird unter Verwendung von 8 linearen Registern mit festen Indizes ernuliert. Wenn der Eingangsbefehl Register 0 spezifiziert, übersetzt ein Übersetzungsblock (nicht gezeigt) den relativen Stackregisterindex in den Registerindex für die linearen Register in einer bekannten Weise. Dies erlaubt der IDU, zu verfolgen, welches Register sich oben auf dem Stack befindet.
Wenn das System in den Emulationsmodus verzweigt, bewahrt die IDU Information über den Befehl, der emuliert wird. Die IDU bewahrt die Datengröße (EM_DSIZE) und Adressgröße (EM_ASIZE) des Befehls sowie den Registerindex des DESTination (EM_RDEST), die Quelle (EM_RDEST2) und die Basis InDeX Information (EM_BSIDX). Diese bewahrte Information wird von der Mikrocode-Routine verwendet, um den Befehl richtig zu emulieren. Man nehme z. B. die Emulation eines add-Befehls. Die Mikrocode-Routine kann EM_ASIZE prüfen, um die Adressgröße des add-Befehls zu bestimmen, sodass sie weiß, welche Adressgröße zu emulieren ist.
Der NIR_GEN-Decoder 1426 enthält einen SIZE-Decoder 1428. Die durch den SIZE-Decoder (d. h. SIZE 1, SIZE 2 und SIZEF) erzeugten Felder geben die Adressgröße, Operandgröße und Sofortdatengröße des Befehls an. Eine Adressgröße von 16 oder 32 Bit, eine Operandgröße von 8, 16 oder 32 Bits und ein Sofortdatenfeldgröße von 18, 16 oder 32 Bits werden für jeden Befehl extrahiert.
Ein anderer NIR_GEN-Decoder wird ein LoaD INFormation (LD_INF) Decoder 1430 genannt. Der LD_INF-Decoder decodiert Information, die den Laod- und Store-Operationen entspricht. Die Load-Information wird für effektive Adressrechnung verwendet. Die Laod-Informationsfelder (LD_INF1, LD_INF2 und LD_INFF) können benutzt werden, um zu spezifizieren, welcher Adressierungsmodus durch den CISC-Befehle verwendet wird, da CISC-Befehlssätze gewöhnlich viele verschiedene Adressierungsmodi unterstützen.
Der i486 Grundadressierungsmodus enthält ein Segmentfeld und ein Offsetfeld, die zusammenaddiert werden, um die Adresse zu bestimmen. Ein Indexregister kann spezifiziert werden sowie eine Skala für das Indexregister (z. B., wenn die Indexregister Elemente in einem Feld sind). Die Elemente können als 1, 2, 4 oder 8 Bytes in der Länge spezifiziert werden, sodass das Indexregister mit 1, 2, 4 oder 8 skaliert werden kann, um die Adresse zu bestimmen. Die Basis und der Index werden auch durch die LD_INF-Felder spezifiziert.
Ein Nano-InstRuction OPCode (NIR_OPC) Decoder 1432 überträgt den Opcode für die A1-Operation (Paket 1). Die decodierten Felder (NIR_OPC1, NIR_OPC2 und NIR_OPCF) umfassen das erste Befehlsbayte (8 Bits) plus drei Erweiterungsbits von dem zweiten Byte.
Ein MIScellaneous OPCoder (MISC_OPC) Decoder 1434 gibt an, ob der Befehl ein Gleitpunktbefehl ist und ob ein Load-Befehl tatsächlich vorhanden ist. Das durch den MISC_OPC-Decoder erzeugte Feld wird angeben, ob eine Umwandlung der Gleitpunktdaten er forderlich ist. Multiplexen ist für diesen Decoder nicht nötig, da diese Information ungeachtet des Formats des Befehls leicht extrahiert wird.
Der Opcode für die A0-Operation von Paket 0 wird durch einen OP_CODE-Decoder 1436 spezifiziert. Der A0-Opcode wird gewöhnlich direkt aus dem i486 Eingangs-Opcode kopiert, aber für einige Befehle wird der Opcode durch einen alternativen Opcode ersetzt. (Wie oben erwähnt, ist die Funktionalität der durch den NIR_GEN-Decoder erzeugten Signale spezifisch für den CISC-Befehlssatz, der decodiert wird, und sollte daher den Fachleuten bei Durchsicht des CISC-Befehlssatzes und des Nanobefehlsformats der vorliegenden Erfindung ersichtlich sein.)
Ein EXT_CODE-Decoder 1440 extrahiert die 3-Bit Opcodeerweiterung aus dem ModR/M-Byte.
Ein ORDER-Decoder 1442 decodiert den Befehl, um festzustellen, ob der Befehl "in Reihenfolge" ausgeführt werdem muss. Dies befiehlt der IEU, mit diesem Befehl erst etwas zu tun, wenn alle vorherigen Befehle ausgeführt wurden. Sobald die Ausführung des Befehls vollendet ist, wird die Ausführung von nachfolgenden Befehlen begonnen.
Ein Control Flow Jump Size Decoder 1444 gibt die Versetzungsgröße für Sprünge an, die eine Adresse spezifizieren. Dieses Feld, bezeichnet CF_JV_SIZE, spezifiziert die Größe der Adresse für den Sprung. Dies ist spezifisch für den Typ des von dem CISC-Befehlssatz eingesetzten Adressierungsschemas.
Ein 1-Bit Decoder, bezeichnet DEC_MDEST 1446, gibt an, ob das Ziel des Befehls eine Speicheradresse ist oder nicht.
Schließlich enthält der Befehlsdecoder drei Registercode-Decoder 1438, um die Registercodes (Indizes) auszuwählen. Das i486 Befehlsformat codiert den Index der Registerfelder an verschiedenen Stellen in dem Befehl. Die Indizes dieser Felder werden durch den RC-Decoder extrahiert. Das ModR/M-Byte hat ebenfalls zwei Registerindizes, die als Ziel/Quelel benutzt werden, wie in den Opcode selbst spezifiziert. Der Registercode-Decoder 1438 erzeugt drei RC-Felder RC1, RC2 und RC3. RC1 und RC2 werden aus dem ModR/M-Byte wie folgt extrahiert. Wenn der Prozessor nicht im Emulationsmodus ist und dieser Befehl kein Gleitpunktbefehl ist: RC1 = Bits [2:0] des ModR/M-Bytes; RC2 = Bits [5:3] des ModR/M-Bytes und RC3 = Bits [2:0] des Opcodes. Für Gleitpunktbefehle im Grundmodus (keine Emulation) werden RC1, RC2 und RC3 wie folgt zugewiesen:
RC1: ST(0) = Spitze des Stacks;
RC2: ST(1) = zweites Element auf Stack = nächst der Spitze des Stacks, und
RC3: ST(i) = das i-te Element aus dem Stack, wo i im Opcode spezifiziert wird.
Im Emulationsmodus werden RC1, RC2 und RC3 wie folgt zugewiesen:
RC1: Bits [4:0] von Byte 3;
RC2: Bits [1:0] von Byte 2 und Bits [5:7] von Byte 3, und
RC3: Bits [6:1] von Byte 2.
15 zeigt ein repräsentatives Blockschaltbild und Logikgatter-Diagramm für die Decoder CST_GEN, NIR_GEN und SEL_GEN (1414, 1438 bzw. 1424). Man sollte verstehen, dass 15 ein Beispiel ist, wie 1-Byte Opcode, 2-Byte Opcode und Gleitpunkt decodierte Ergebnisse ausgewählt, verzögert und kombiniert werden, um Quellen- und Ziel-Registerindizes für Nanobefehls-Operationen A0 und A1 und den Zielregisterindex für den Load-Befehl zu erzeugen. Die Methodologie des Auswählens, Verzögerns und Multiplexens gilt für alle von dem Befehlsdecoder 1202 erzeugten Signale mit Ausnahme derjenigen Signale, die keine getrennten 1-Byte Opcode-, 2-Byte Opcode- und Gleitpunkt-Ergebnisse erzeugen. Ferner sind die durch dieses Beispiel erzeugten Ergebnisse anwendungsspezifisch, d. h. sie gelten für die Decodierung von i486 Befehlen in das Nanobefehlsformat der vorliegenden Erfindung. Die in diesen Beispielen erörterten Prinzipien sind jedoch grundsätzlich auf jeden CISC-in-RISC-Befehlsabgleich und Decodierung anwendbar.
Wie oben erörtert, erzeugt der CST_GEN-Decoder 1414 drei Ausgänge, CST1, CST2 und CSTF, von denen jeder vier 5-Bit Konstanten-Registerfelder (20 Bits total) umfasst. Der SEL_GEN erzeugt Registerfeld-Steuersignale FLD1, FLD2 und FLD3 für das Auswählen der Multiplexer in einem werteren Abschnitt MUX 1512. Die Auswahl der CST1-, CST2- oder CSTF-Ergebnisse und der FLD1-, FLD2- und FLDF-Ergebnisse wird allgemein im Multiplexerblock 1502 gezeigt. Eine 3-Bit MUX-Auswählleitung 1504 wird benutzt, um die Ergebnisse abhängig davon auszuwählen, ob der Befehl einen 1-Byte Opcode, einen 2-Byte Opcode hat oder ein Gleitpunktbefehl ist.
Ein Omega-Zyklus-Pipeline-Verzögerungs-Latch 1504 wird benutzt, um die durch den Multiplexer 1502 ausgewählten Ergebnisse und die drei Registersteuertelder RC1, RC2 und RC3 zu verzögern. Jeder Eingang zu der Omega-Pipeline-Verzögerung 1504 wird an ein Paar von entgegengesetzt getakteten Latches 1508 gesendet. Die Inhalte der Latches werden durch einen Multiplexer 1510 ausgewählt. Diese Anordnung ist ähnlich der oben in Verbindung mit der IAU erörterten Omega-Zyklus-Verzögerung 316.
Eine wertere Multiplexerstufe wird in Block 1512 gezeigt. Die durch den Multiplexer 1502 ausgewählten Konstanten-Registerfelder werden in den Multiplexer 1512 als vier getrennte Felder regc1 bis regc4 eingegeben, wie allgemein bei 1514 gezeigt. Auch als Eingänge des Blocks 1512 gezeigt sind die Extrakt-Register-Felder RC1, RC2 und RC3 von den Opcode- und den ModR/M-Bytes. Die regc-Felder und RC-Felder werden durch Logik im Block 1512 unter Steuerung eines FLD-Steuersignals 1520 kombiniert, um die Quellen- und Ziel-Registerindizes a0_rd und a0_rs für die Operation A0, die allgemein bei 1516 gezeigt werden, sowie die Quellen- und Ziel-Registerindizes a1_rd und a1_rs für die Operation A1, die allgemein bei 1518 gezeigt werden, zu erzeugen. Ein Index 1d_rd, der der Zielregisterindex für den Laod-Befehl ist, wird auch im Block 1512 ausgewählt.
4.0 FIFO für decodierte Befehle
16A zeigt ein Blockdiagramm eines Decodier-FIFO (DFIFO) in Verbindung mit der vorliegenden Erfindung. Der DFIFO halt vier vollständige Kübel, von denen jeder vier Nanobefehle, zwei Sofortdatenfelder und ein Versetzungsfeld enthält. Jeder Kübel entspricht einer Stufe des Pipeline-Registers im DFIFO. Diese Kübel werden in der IDU erzeugt und während jedes Zyklusses, in dem die IEU einen neuen Kübel anfordert, in den DFIFO geschoben. Die Nanobefehle in einem Kübel werden in zwei Gruppen, genannt Paket0 und Paket1, geteilt. Paket0 besteht aus einer Load-, ALU- und/oder Store-Operation, die ein, zwei oder drei Nanobefehlen entsprechen. Paket1 kann nur eine ALU-Operation sein, die einem Nanobefehl entspricht. Als Folge dieser Teilung kann ein Kübel nur zwei ALU-Operationen enthalten, und nur eine von ihnen kann auf den Speicher verweisen. Wenn nachfolgende Befehle Speicher operanden benötigen, müssen sie in getrennte Kübel gelegt werden.
Wie aus 16B zu sehen ist, gibt es nur eine leidliche Menge an allgemeiner Information, die mit jedem Paket und mit dem Kübel als Ganzes verbunden ist. Diese Information wird in einem Allgemein-Informations-FIFO gespeichert. Durch Vorgabe werden die vier Nonobefehle in einem Kübel in der Reihenfolge von NIR0 bis NIR3 ausgeführt. Eines der Allgemein-Informationsbits des Kübles kann gesetzt werden, um anzugeben, dass NIR3 vor NIR0-NIR2 ausgeführt werden soll. Dieses Merkmal macht es viel leichter, nachfolgende Pakete in einen einzigen Kübel zu kombinieren, weil ihre Reihenfolge ihre Fähigkeit, die Kübelanforderungen zu erfüllen, nicht länger beeinflusst.
16C zeigt ein Sofortdaten- und Versetzungs-FIFO für die Kübel 0–4. IMM0 stellt die Sofortdaten dar, die Paket0 entsprechen, und IMM1 stellt die Softdaten dar, die Paket1 entsprechen. DISP stellt die Versetzung dar, die Paket0 entspricht. Paket1 benutzt keine DISP-Information, weil die DISP-Felder nur als ein Teil der Adressrechnung verwendet werden.
17 zeigt ein spezifisches Beispiel der oben beschriebenen drei Arten von Nanobefehlen. Die Feldbeschreibungen und Definitionen werden auch in Anlage A, Seiten 1–10, beschrieben. Diese Tabellen liefern detaillierte Informationen über den Inhalt jedes Kübels.
Während verschiedene Ausführungen der vorliegenden Erfindung oben beschrieben wurden, sollte verstanden werden, dass sie als Beispiel und nicht als Einschränkung präsentiert wurden. Die Breite und der Umfang der vorliegenden Erfindung sollen daher nicht durch eine der oben beschriebenen exemplarischen Ausführung begrenzt werden, sondern sollen nur entsprechend den folgenden Ansprüchen und ihren Gleichwertigkeiten definiert werden.

Claims

Superskalarer Mikroprozessor, der umfasst: eine Einrichtung (200), die auszuführende CISC-Befehle abruft, wobei wenigstens einer der CISC-Befehle einen Register-Verweis enthält: eine Einrichtung (1202), die die CISC-Befehle zu RISC-Befehlen mit einer vorgegebenen Sequenz dekodiert; und eine Ausführeinrichtung, die wenigstens zwei RISC-Befehle gleichzeitig und außerhalb der vorgegebenen Sequenz ausführt, wobei erste und zweite CISC-Befehle durch die Dekodiereinrichtung zu einem oder mehreren ersten RISC-Befehlen bzw. einem oder mehreren zweiten RISC-Befehlen pro Taktzyklus dekodiert werden, gekennzeichnet durch eine Einrichtung, die Daten in einer Vielzahl von Registern speichert, die durch Register-Verweise identifiziert werden können, wobei die Vielzahl von Registern ein vorgegebenes Register und ein temporäres Register enthält; wobei die Ausführeinrichtung eine Einrichtung enthält, die das temporäre Register auswählt, und die Ausführung des Befehls den Register-Verweis zum Auswählen des vorgegebenen Registers für die Speicherung von Daten erzeugt, und die Ausführeinrichtung ein erstes sowie ein zweites Register umfasst, die jeweils RISC-Befehlsspeicherstellen umfassen, und die ersten RISC-Befehle sowie die zweiten RISC-Befehle in dem ersten Register gespeichert werden.
Superskalarer Mikroprozessor nach Anspruch 1, wobei das erste und das zweite Register jeweils vier RISC-Befehlsspeicherstellen umfassen.
Superskalarer Mikroprozessor nach Anspruch 1 oder 2, wobei der Mikroprozessor umfasst: eine Abrufschaltung (200), die eine Vielzahl von CISC-Befehlen aus einem Befehlsspeicher abruft, wobei die Vielzahl von CISC-Befehlen in Programmreihenfolge sind.
Superskalarer Mikroprozessor nach einem der Ansprüche 1 bis 3, der eine Abfertigungsschaltung zum gleichzeitigen Abfertigen mehr als eines der Vielzahl durch den Dekodierer dekodierter RISC-Befehle umfasst.
Superskalarer Mikroprozessor nach einem der Ansprüche 1 bis 4, der umfasst: eine Ausführeinheit, die umfasst: eine Vielzahl funktioneller Einheiten, wobei jede der Vielzahl funktioneller Einheiten einen der Vielzahl durch die Abfertigungsschaltung abgefertigter RISC-Befehle außerhalb der vorgegebenen Sequenz ausführt; und eine Register-Datei, die Daten von der Vielzahl funktioneller Einheiten in einer Vielzahl von Registern speichert, und wobei die Register-Datei mit der Vielzahl funktioneller Einheiten über eine Vielzahl von Datenleitwegen kommuniziert, um gleichzeitig Daten mehr als einer der funktionellen Einheiten zur Verfügung zu stellen und somit gleichzeitige Ausführung mehr als eines der Vielzahl von Befehlen durch die Vielzahl funktioneller Einheiten zu ermöglichen.
Verarbeitungsverfahren, das die folgenden Schritte beinhaltet: Abrufen auszuführender CISC-Befehle, wobei wenigstens einer der CISC-Befehle einen Register-Verweis enthält; Dekodieren der CISC-Befehle zu RISC-Befehlen mit einer vorgegebenen Sequenz; und gleichzeitiges Ausführen wenigstens zwei der RISC-Befehle außerhalb der vorgegebenen Sequenz; und Dekodieren erster und zweiter CISC-Befehle zu einem oder mehreren ersten RISC-Befehlen und einem oder mehreren zweiten RISC-Befehlen pro Taktzyklus, Speichern von Daten in einer Vielzahl von Registern, die durch Register-Verweise identifiziert werden können, wobei die Vielzahl von Registern ein vorgegebenes Register und ein temporäres Register enthält; und Auswählen des temporären Registers, wobei die Ausführung des Befehls den Register-Verweis zum Auswählen des vorgegebenen Registers für die Speicherung von Daten erzeugt, Speichern des ersten RISC-Befehls und des zweiten RISC-Befehls in einem ersten Register, das in einer Ausführeinrichtung enthalten ist, die ein erstes und ein zweites Register umfasst, die jeweils RISC-Befehlsspeicherstellen umfassen.