DE19737658A1 - Befehlsdecoder für einen Mikroprozessor - Google Patents

Description

Die Erfindung betrifft einen Befehlsdecoder für einen Mikro­ prozessor nach dem Oberbegriff des Anspruchs.

Moderne Mikroprozessoren verwenden Pipeline-Techniken, die es ermöglichen, mehrere aufeinanderfolgende Befehle vorabzurufen, zu deco­ dieren und in getrennten Stufen gleichzeitig abzuarbeiten. In irgend­ einem Taktzyklus kann demgemäß ein erster Befehl abgearbeitet werden, während der nächste (zweite) Befehl gleichzeitig decodiert wird und der Befehl nach jenem (ein dritter Befehl) gleichzeitig vorabgerufen wird. Da weniger Verarbeitung an jedem Befehl pro Zyklus ausgeführt wird, kann die Zykluszeit kürzer gewählt werden. Während zwar mehrere Taktzyklen für einen einzelnen Befehl benötigt werden, um vorabgerufen, decodiert und abgearbeitet zu werden, ist es möglich, daß ein Prozessor bis zu einem Befehl pro Zyklus mit einer sehr kurzen Zyklusperiode verarbeiten kann, weil mehrere aufeinanderfolgende Befehle sich in verschiedenen Stufen gleichzeitig befinden.

Typischerweise werden Puffer für das zeitweilige Halten von Daten verwendet, um die Grenze zwischen aufeinanderfolgenden Stufen einer Mikroprozessor-Pipeline zu definieren. Die Daten, die in einer bestimmten Stufe berechnet werden, werden in diese Puffer vor dem Ende des Zyklus eingeschrieben. Wenn die Pipeline bei Beginn eines neuen Zyklus fortschreitet, werden die Daten aus den Begrenzungspuffern in die nächste Stufe übergeschrieben, wo die Daten weiter während des nächsten Zyklus bearbeitet werden.

Die meisten Mikroprozessor-Pipeline-Architekturen haben min­ destens vier Stufen, nämlich in der Reihenfolge des Datenflusses eine Vorabrufstufe, eine Decodierstufe, eine Verarbeitungsstufe und eine Rückschreibstufe. In der Vorabrufstufe werden Befehle aus Speicher aus­ gelesen (beispielsweise einem Befehls-Cache-Speicher) und in einem Puf­ fer gespeichert. Abhängig von dem jeweiligen Mikroprozessor kann der Vorabrufpuffer einen oder mehrere Befehle in irgendeinem Zyklus empfan­ gen.

In der Decodierstufe liest der Prozessor einen Befehl aus dem Vorabrufpuffer und setzt ihn in ein internes Befehlsformat um, das von dem Mikroprozessor benutzt werden kann, um eine oder mehrere Operationen wie arithmetische oder logische Operationen auszuführen. In der Verar­ beitungsstufe erfolgen die eigentlichen Operationen. Schließlich wird in der Rückschreibstufe das Ergebnis der Operationen in zugeordnete Regi­ ster und/oder andere Speicherstellen eingeschrieben.

In aufwendigeren Mikroprozessoren kann eine oder können meh­ rere der vier Basisstufen weiter in kleinere Stufen aufgeteilt sein, um jede Einzelstufe zu vereinfachen und die Befehlsbeendigungsgeschwindigkeit weiter zu verbessern.

Die Hardware in einer Befehlsvorabrufstufe umfaßt einen Vorab­ rufpuffer, der zeitweilig Befehle erhalten kann. In jedem Zyklus kann die Decodierstufe die Bytes eines Befehls, gehalten in der Vorabrufstu­ fe, für die Decodierung während des betreffenden Zyklus übernehmen.

Die Hardware in einer Decodierstufe umfaßt zumindest einen Programmzähler und Hardware für das Umsetzen der Befehle in Steuerlei­ tungen für das Steuern der Hardware in der Abarbeitungsstufe. Alternativ kann die Decodierstufe ein Mikrocode-ROM enthalten. Der einlaufende Be­ fehl definiert einen Eingabepunkt (d. h. eine Adresse) in dem Mikrocode-ROM, bei welchem die gespeicherten Daten die richtigen Bedingungen für die Verarbeitungsstufen-Steuerleitungen definieren. Die Verarbeitungs­ stufen-Steuerdaten für den jeweiligen Befehl können ausschließlich unter einer einzigen adressierbaren Speicherstelle auf dem Mikrocode-ROM exi­ stieren oder können mehrere sequentiell adressierbare Speicherstellen einnehmen. Die Anzahl von adressierbaren Speicherstellen in dem Mikroco­ de-ROM, auf die für einen gegebenen Befehl zugegriffen werden muß, kön­ nen in dem Befehl selbst codiert enthalten sein. Alternativ können ein oder mehrere Datenbits in den Speicherstellen in dem Mikrocode-ROM ange­ ben, ob auf eine andere Speicherstelle zugegriffen werden soll oder nicht.

Der Steuerdatenausgang von dem Mikrocode-ROM wird in Puffer­ register für die Übertragung zu der Verarbeitungsstufe beim nächsten Zyklusübergang eingeschrieben. Die Decodierstufe enthält auch Hardware für das Extrahieren der Operanden, falls solche vorliegen, aus dem Be­ fehl oder aus Registern oder Speicherstellen und für das Präsentieren der Operanden zu der entsprechenden Hardware in der Verarbeitungsstufe.

Einige Mikroprozessor-Architekturen verwenden sogenannte Be­ fehlssätze variabler Breite. In solchen Architekturen haben die Befehle nicht sämtlich dieselbe Breite. Beispielsweise kann in dem Befehlssatz für die 16/32-bit-Klasse x86 von Mikroprozessoren der Firma Intel Corpo­ ration, Santa Clara, Kalifornien, ein Befehl zwischen 1 und 16 Bytes breit sein.

Einige Mikroprozessor-Architekturen verwenden einen segmen­ tierten Adreßraum, in welchem der gesamte Speicherraum in eine Mehrzahl von unabhängigen geschützten Adreßräumen unterteilt ist. Jedes Segment wird durch eine Basisadresse und einer Segmentgrenze definiert. Die Basisadresse kann beispielsweise die niedrigste numerische Adresse in dem Segmentraum sein. Die Segmentgrenze definiert die Größe des Seg­ ments. Demgemäß wird die Endbegrenzung des Segments durch die Summe der Basisadresse und der Segmentgrenze definiert. Alternativ kann die Basis­ adresse die höchste Adresse sein, und die Endbegrenzung des Segments wä­ re die Differenz zwischen der Basisadresse und der Segmentgrenze.

Um eine lineare Adresse entsprechend der x86-Architektur zu erzeugen, werden zumindest zwei Größen addiert. Im einzelnen müssen die Basisadresse des jeweiligen Segments, wie durch den Segmentdeskriptor angegeben, und ein Versatz addiert werden, der die Distanz der gewünsch­ ten Daten (d. h. Befehl) von der Basis des Segments angibt. Der Versatz selbst kann bis zu drei mehr Teile umfassen, eine Basis, einen Index und eine Verlagerung. Wenn dies so ist, müssen jene Größen addiert werden, um den Versatz zu erzeugen, bevor der Versatz zu der Segmentbasis ad­ diert werden kann. Eine detaillierte Offenbarung der segmentierten Adressierung in der x86-Architektur wird nachstehend, soweit für die Er­ findung wesentlich, wiedergegeben, doch ist eine umfangreiche Offenba­ rung in Intel486™ Microprocessor Family Programmer's Reference Manual, 1995, enthalten, das von der Firma Intel Corporation erhältlich ist. Zur näheren Information wird auf diese Druckschrift verwiesen.

Bekannte Befehlsdecoder in Mikroprozessoren empfangen Befehle von der Befehlsvorabrufeinheit und übersetzen sie in einen zweistufigen Prozeß in Steuersignale und Mikrocodeeingabepunkte. Viele, jedoch nicht alle Befehle können mit einer Rate von einem pro Taktzyklus decodiert werden. Die Stufe 1 der Decodierung initialisiert einen Speicherzugriff. Dies ermöglicht die Verarbeitung einer Sequenz von zwei Befehlen, welche in Zweitaktzyklen laden und bearbeiten. Die Decodiereinheit verarbeitet gleichzeitig Befehlspräfixbytes, Betriebscodes, MODR/M-Bytes und Verla­ gerungen. Die Ausgänge umfassen festverdrahtete Mikrobefehle zu der Seg­ mentation, Zahlen und Fließkommaeinheiten. Die Decodiereinheit wird ge­ leert immer dann, wenn die Befehlsvorabrufeinheit geleert wird.

Fig. 8 ist ein Blockdiagramm, das generell die verschiedenen Pipeline-Stufen eines konventionellen Mikroprozessors illustriert. Der Mikroprozessor ist in eine Pipeline von fünf Stufen unterteilt, nämlich eine Vorabrufstufe, eine Decodierstufe, eine Verarbeitungsstufe, eine Rückschreibstufe und eine zweite Rückschreibstufe. Die Vorabrufstufe um­ faßt zwei Vorabrufpuffer 112 und 114. Der Vorabrufpuffer 112 ist der Leitungspuffer, von welchem die Decodierstufe Befehlsbytes abruft. Es handelt sich hier um die einzige Datenschnittstelle zwischen der Vorab­ ruf- und der Decodierstufe. Die Vorabrufstufe umfaßt auch einen Befehls- Cache-Speicher 116 von einem kByte und einen Cache-Markierungsspeicher 118 für die Speicherung von Markierungsdaten bezüglich der Daten im Be­ fehls-Cache-Speicher 116. Der Befehls-Cache-Speicher ist direkt tabel­ liert mit einer Zeilengröße von 8 Byte Breite. Beide Vorabrufpuffer sind ebenfalls 8 Byte breit; sie enthalten Bytepositionen 0 (niedrigststelli­ ges Byte) bis Byteposition 7 (höchststelliges Byte). Die Vorabrufstufe kann auch Vorabruflogik 120 für das Ausführen verschiedener Funktionen bezüglich der Steuerung des Ladens der Vorabrufpuffer mit Befehlen ent­ halten.

Gemäß Fig. 9 und 10 werden alle Befehle in dem Befehlssatz des x86-Prozessors als aus bis zu drei Unterfeldern bestehend angesehen, wobei jedes Unterfeld mehrere mögliche Bytebreiten hinzufügt. Die drei möglichen Unterfelder sind das Präfixunterfeld, das Betriebscodeunter­ feld und das Konstantenunterfeld. Jeder Befehl umfaßt zumindest ein Betriebscodeunterfeld. Das Betriebscodeunterfeld definiert die Funktion, welche von der Verarbeitungsstufe bezüglich des betreffenden Befehls auszuführen ist (beispielsweise Addition, Subtraktion, Multiplikation, EXKLUSIV-ODER-Verknüpfung, Datenverschiebung, etc.). Das Betriebscode­ unterfeld kann ein, zwei oder drei Bytes Länge haben. Das Betriebscode­ unterfeld wird immer ein Betriebscodebyte enthalten, das die auszufüh­ rende Funktion definiert. Es kann außerdem ein ModR/M-Byte enthalten. Dabei handelt es sich um eine Adreßmodusspezifikation. Sie gibt an, ob ein Operand in einem Register oder in einer Speicherstelle ist, und wenn in einem Speicher, gibt sie an, ob eine Versetzung, ein Basisregister, ein Indexregister und/oder Skalierung zu verwenden sind. Wenn das ModR/M-Byte angibt, daß ein Indexregister zu verwenden ist, um die Adresse eines Operanden zu berechnen, kann der Befehl ein drittes Byte umfassen, das als Skalierindexbyte (SIB) bezeichnet wird. Das SIB-Byte wird in dem Befehl aufgenommen, um das Basisregister, das Indexregister und einen Skalierungsfaktor zu codieren.

Bestimmte Befehle enthalten ein drittes Unterfeld, das als Konstantdatenunterfeld bezeichnet wird und das einen oder zwei von dem Befehl zu verwendende Operanden spezifizieren kann. Im einzelnen kann das Konstantdatenunterfeld einen Verlagerungsdatenoperanden, einen Un­ mittelbardatenoperanden, einen Verlagerungsdatenoperanden und einen Un­ mittelbardatenoperanden oder zwei Unmittelbaroperanden umfassen. Wenn der Adressiermodus ein solcher ist, bei dem eine Verlagerung verwendet wird, um die Adresse eines Operanden zu berechnen, umfaßt der Befehl ei­ nen Verlagerungsdatenoperanden als Teil des Konstantenunterfelds. Ein Verlagerungsdatenoperand kann ein, zwei oder vier Bytes Länge aufweisen. Ein Unmittelbaroperand liefert direkt den Wert eines Operanden. Ein Un­ mittelbaroperand kann ein, zwei oder vier Bytes Länge aufweisen.

Falls ein Konstantenunterfeld vorhanden ist, kann es demgemäß ein bis acht Byte breit sein. Bestimmte Parameter wie das von den Befeh­ len zu verwendende Segmentregister, die Adreßgröße und die Operanden­ größe werden auf Vorzugsbedingungen in der Verarbeitungs- und/oder De­ codierstufe gesetzt. Diese Parameter können jedoch durch Präfixbytes in dem Präfixunterfeld eines Befehls überholt werden. Es gibt vier grund­ sätzliche Typen von Präfixbytes, nämlich einen Adreßpräfix für die Auswahl zwischen 16- oder 32-Byte-Adressierung, ein Operandengrößenprä­ fixbyte für die Auswahl zwischen Datengrößen von 16 oder 32 Bytes, ein Segmentüberholbyte, das das Segmentregister angibt, welches ein Befehl verwenden soll, einen Befehlspräfix, der zwischen zwei Zuständen kippen kann, welche die Tabelle bestimmen, aus der das Betriebscodebyte deco­ diert wird.

Demgemäß verdoppelt die Verwendung des Befehlspräfix die mög­ liche Anzahl von Befehlen. Da ein populärer Typ von Präfixbyte, zum Bei­ spiel ein Adreßpräfix, mehr als einmal in einem einzigen Befehl er­ scheinen kann, können zwischen 0 und 14 Präfixbytes in einem Befehl ent­ halten sein. Decoder können ein Maximum von sieben Befehlsbytes pro Zy­ klus von dem Leitungspuffer 112 abrufen. Im einzelnen decodiert eine konventionelle Decoderstufe pro Zyklus (1) ein Präfixbyte oder (2) ein Betriebscodeunterfeld (von bis zu drei Bytes) und dem ersten Operanden in dem Konstantdatenunterfeld (von bis zu vier Bytes), falls vorhanden, oder (3) den zweiten Operanden in dem Konstantdatenunterfeld (von bis zu vier Bytes). Bei Verwendung eines konventionellen Decoders benötigt dem­ gemäß ein Befehl, der zwei Operanden in seinem Konstantdatenunterfeld hat, mindestens zwei Zyklen, um abgearbeitet zu werden, und möglicher­ weise mehr, falls der Befehl irgendwelche Präfixbytes hat.

Die in einem Befehl codierte Information umfaßt eine Spezifi­ kation der auszuführenden Operation, den Typ der zu manipulierenden Operanden und die Fundstelle dieser Operanden. Wenn ein Operand sich in einem Speicher befindet, muß der Befehl auch das Segment, das den Ope­ randen enthält, explizit oder implizit anwenden.

Ein Befehl kann verschiedene Teile und Formate haben. Das exakte Format von Befehlen findet sich im Anhang A der oben genannten Druckschrift. Die Teile eines Befehls werden nachstehend beschrieben. Von diesen Teilen ist nur der Betriebscode immer vorhanden. Die anderen Teile können vorhanden sein oder auch nicht, abhängig von der betreffen­ den Operation und der Fundstelle und dem Typ des Operanden. Die Teile eines Befehls sind in der Reihenfolge ihres Auftretens:
Präfixe: ein oder mehrere Bytes, die einem Befehl vorangehen und die die Operation des Befehls modifizieren. Die folgenden Präfixe können durch Anwenderprogramme verwendet werden:

• 1. Segmentüberholung - spezifiziert explizit, welches Segmentregister einen Befehl verwenden sollte anstelle des Vorrangsegmentregi­ sters.
• 2. Adreßgröße - schaltet zwischen 16-bit- und 32-bit-Adressierung um. Eine der Größen kann Vorrang haben; dieser Präfix wählt die Größe, die nicht Vorrang hat.
• 3. Operandengröße - schaltet zwischen 16-bit- und 32-bit-Datengröße um. Eine der Größen kann Vorrang haben; dieser Präfix wählt die Größe ohne Vorrang.
• 4. Wiederholen - verwendet mit einem Strangbefehl, um zu bewirken, daß der Befehl für jedes Element des Stranges wiederholt wird.

Betriebscode: spezifiziert die von dem Befehl auszuführende Operation. Einige Operationen haben mehrere unterschiedliche Be­ triebscodes, von denen jeder eine unterschiedliche Form der Operation angibt.

Registerspezifikation: Ein Befehl kann ein oder zwei Registeroperanden spezifizieren. Registerspezifikationen treten entweder in demselben Byte wie der Betriebscode oder in demselben Byte wie die Adressiermodusspezifikation auf.

Adressiermodespezifikation: spezifiziert, falls vorhanden, ob ein Ope­ rand in einem Register oder einer Speicherstelle ist; falls im Speicher, wird spezifiziert, ob eine Verlage­ rung, ein Basisregister, ein Indexregister und Skalierung zu verwenden sind.

SIB (Skalierung, Index, Basis) Byte: wenn die Adreßmodusspezifikation ein Indexregister angibt, das zu verwenden ist, um die Adresse eines Operanden zu berechnen, wird ein SIB-Byte in den Befehl eingefügt, um das Basisregister, das Indexregister und einen Skalierungsfaktor zu codieren.

Verlagerung: Wenn die Adreßmodusspezifikation angibt, daß eine Ver­ lagerung zu verwenden ist, um die Adresse eines Operanden zu berechnen, wird die Verlagerung in dem Befehl codiert. Eine Verlagerung ist eine vorzeichenbehaftete ganze Zahl von 32, 16 oder 8 bits. Die 8-bit-Form wird in dem gewöhnlichen Fall verwendet, wenn die Verlagerung hinreichend klein ist. Der Prozessor erstreckt eine 8-bit-Verlagerung auf 16 oder 32 bit unter Berücksichti­ gung des Vorzeichens.

Unmittelbaroperand: liefert, wenn vorhanden, direkt den Wert eines Ope­ randen. Unmittelbaroperanden können Bytes, Worte oder Doppelworte sein. In Fällen, wo ein 8-bit-Unmittelbar­ operand mit einem 16- oder 32-bit-Operanden verwendet wird, erstreckt der Prozessor den 8-bit-Operanden auf eine ganze Zahl gleichen Vorzeichens und gleichen Wertes in einer vergrößerten Abmessung. Auf demselben Wege wird ein 16-bit-Operand auf 32 bit ausgedehnt.

Ein Befehl wirkt auf null oder mehr Operanden. Ein Beispiel eines Null-Operandenbefehls ist der NOP-Befehl (keine Operation). Ein Operand kann unterschiedlich plaziert sein: in dem Befehl selbst (ein Unmittelbaroperand), in einem Register (im Falle von 32-bit-Operanden, EAX, EBX, ECX, EDX, ESI, EDI, ESP oder EBP; im Falle von 16-bit-Operanden AX, BX, CX, DX, SI, DI, SP oder BP; im Falle von 8-bit-Operanden AH, AL, BH, BL, CH, CL, DH oder DL; in Segmentregistern oder EFLAGS-Register für Flagoperationen). Die Verwendung von 16-bit-Registeroperanden erfordert die Verwendung des 16-bit-Operandengrößepräfix (ein Byte mit dem Wert 67H, das dem Befehl vorangeht) im Speicher oder in einem Eingangs-/Ausgangsport.

Der Zugriff auf die Operanden ist sehr schnell. Register- und Unmittelbaroperanden sind auf dem Prozessorchip verfügbar, die letzteren, weil sie als Teil der Interpretation des Befehls vorabgerufen werden. Speicheroperanden, die in dem auf dem Prozessorchip befindlichen Cache-Speicher abgelegt sind, können ebenso schnell erreicht werden.

Von den Befehlen, welche Operanden haben, spezifizieren einige die Operanden implizit, andere explizit, und noch andere verwenden eine Kombination beider. Zum Beispiel:

Impliziter Operand: AAM

Definitionsgemäß arbeitet er an den Inhalten des AX-Registers (im ASCII-Code).

Expliziter Operand: XCHG EAX, EBX

Die auszutauschenden Operanden werden im Befehl mit dem Be­ triebscode codiert.

Implizite und explizite Operanden: PUSH COUNTER

Die Speichervariable COUNTER (der explizite Operand) wird auf die Oberseite des Stapels (den impliziten Operanden) kopiert. Die meisten Befehle haben implizite Operanden. Beispielsweise werden mit allen arithmetischen Befehlen die EFLAGS-Register aufge­ frischt.

Ein Befehl kann explizit auf ein oder zwei Operanden Bezug nehmen. Zwei Operandenfehle, wie MOV, ADD und XOR, überschreiben im all­ gemeinen einen der beiden teilnehmenden Operanden mit dem Ergebnis. Dies ist der Unterschied zwischen dem Quellenoperanden (der von der Operation unbeeinflußt bleibt) und dem Zieloperanden, die von dem Result über­ schrieben wird.

Für die meisten Befehle kann einer beiden explizit spezifi­ zierten Operanden, entweder Quelle oder Ziel, entweder in einem Register oder in einem Speicher sein. Der andere Operand muß in einem Register sein, oder es muß sich um einen Unmittelbarquellenoperand handeln. Dies bringt die expliziten zwei Operandenbefehle in die folgenden Gruppen:
Register an Register, Register an Speicher, Speicher an Register, unmit­ telbar an Register und unmittelbar an Speicher.

Bestimmte Strangbefehle und Stapelmanipulationsbefehle trans­ ferieren jedoch Daten von Speicher zu Speicher. Beide Operanden einiger Strangbefehle sind im Speicher und werden implizit spezifiziert. Auf- und Ab-Stapeloperationen erlauben Transfer zwischen Speicheroperanden und dem speicherbasierten Stapel.

Mehrere Dreioperandenbefehle sind vorgesehen, wie IMUL, SHRD und SHLD. Zwei der drei Operanden werden explizit spezifiziert, wie bei den Zweioperandenbefehlen, während ein dritter aus dem ECX-Register ent­ nommen wird oder als Unmittelbaroperand bereitgestellt wird. Andere Drei-Operandenbefehle, wie Strangbefehle, wenn sie mit einem Wiederho­ lungspräfix verwendet werden, entnehmen alle ihre Operanden aus Regi­ stern.

Bestimmte Befehle verwenden Daten aus dem Befehl selbst als einen (und manchmal zwei-der Operanden. Ein solcher Operand wird ein Unmittelbaroperand genannt. Es kann sich um ein Byte, ein Wort oder ein Doppelwort handeln. Beispielsweise:

SHR PATTERN 2

Ein Byte des Befehls hält den Wert 2, die Zahl von Bits, um die die Variable PATTERN zu verschieben ist.

TEST PATTERN, OFFFFOOf FH

Ein Doppelwort des Befehls hält die Maske, die für den Test der Variablen PATTERN verwendet wird.

IMUL CX, MEMWORD 3

Ein Wort im Speicher wird mit einem unmittelbar 3 multipli­ ziert und in dem CX-Register gespeichert.

Alle arithmetischen Befehle mit Ausnahme der Division ermögli­ chen, daß der Quellenoperand ein Unmittelbarwert ist. Wenn das Ziel das EAX- or AL-Register ist, ist der Befehlscode um ein Byte kürzer als mit den anderen Generalregistern.

Operanden können in einem der 32-bit-Generalregister (EAX, EBC, ECX, EDX, ESI, EDI, ESP oder EBP), in einem der 16-bit-Generalregi­ ster (AX, BX, CX, DX, SI, DI, SP oder BP) oder in einem der 8-bit-Gene­ ralregister (AH, BH, CH, DH, AL, BL, CL oder DL) lokalisiert sein. Der Prozessor hat Befehle für die Bezugnahme auf Segmentregister (CS, DS, ES, SS, FS und GS). Diese Befehle werden nur dann durch Anwenderprogram­ me verwendet, wenn das System mit einem segmentierten Speichermodell ausgestattet ist.

Der Prozessor hat auch Befehle für die Änderung des Zustands einzelner Flags in dem EFLAGS-Register. Befehle sind für das Setzen und Löschen von Flags vorgesehen worden, auf die häufig zugegriffen werden muß. Die anderen Flags, auf die nicht so oft zuzugreifen ist, können ve­ rändert werden, indem man den Inhalt des EFLAGS-Registers auf den Sta­ pel schiebt, der Änderungen vornimmt, während er im Stapel ist, und zu­ rückverlagert in das Register.

Befehle mit expliziten Operanden im Speicher müssen Segmente angeben, welche den Operanden enthalten und den Versatz gegenüber dem Beginn des Segments bis zu dem Operanden. Segmente werden unter Verwen­ dung eines Segmentüberholpräfix spezifiziert, bei dem es sich um Byte handelt, das am Beginn eines Befehls plaziert ist. Wenn kein Segment spezifiziert wird, ordnen einfache Regeln das Segment durch Vorzugsbele­ gung zu. Der Versatz wird in einer der folgenden Weisen spezifiziert:
Die meisten Befehle, die auf Speicher zugreifen, enthalten ein Byte für das Spezifizieren des Adressierverfahrens des Operanden. Dieses Byte, das als ModR/M-Byte bezeichnet wird, kommt nach dem Betriebscode und spezifiziert, ob der Operand sich in einem Register oder im Speicher befindet. Wenn der Operand im Speicher ist, wird die Adresse aus einem Segmentregister und einem der folgenden Werte berechnet: Ein Basisregi­ ster, ein Indexregister, ein Skalierungsfaktor und eine Verlagerung. Wenn ein Indexregister verwendet wird, folgt dem ModR/M-Byte auch ein anderes Byte, um das Indexregister und den Skalierungsfaktor zu spezifi­ zieren. Diese Form der Adressierung ist die flexibelste.

Einige wenige Befehle verwenden implizierte Adressiermoden: Ein MOV-Befehl mit dem AL- oder dem EAX-Register als entweder Quelle oder Ziel kann Speicher mit einem in dem Befehl codierten Doppelwort adressieren. Diese spezielle Form des MOV-Befehls ermöglicht es, weder Basisregister, Indexregister noch Skalierfaktor zu verwenden. Diese Form ist um ein Byte kürzer als die Allgemeinzweckform.

Strangoperationen adressieren Speicher in dem DS-Segment unter Verwendung des ESI-Registers (die MOVS-, CMPS-, OUTS- und LODS-Befehle) oder verwenden das ES-Segment und EDI-Register (die MOVS-, CMPS, INS-, SCAS- und STOS-Befehle).

Stapeloperationen adressieren Speicher in dem SS-Segment unter Verwendung des ESP-Registers (the PUSH-, POP-, PUSHA-, PUSHAD-, POPA-, POPAD-, PUSHf-, PUSHFD-, POPF-, POPFD-, CALL-, LEAVE-, RET-, IRET- und IRETD-Befehle, Ausnahmen und Interrupts).

Das ModR/M-Byte liefert die flexibelste Form der Adressierung. Befehle, welche ein ModR/M-Byte nach dem Betriebscode haben, sind die häufigsten in dem Befehlssatz. Für durch ein ModR/M-Byte spezifizierte Speicheroperanden ist der Versatz innerhalb des ausgewählten Segments die Summe von drei Komponenten: Verlagerung, Basisregister, Indexregi­ ster (das Indexregister kann um einen Faktor von 2, 4 oder 8 multipli­ ziert sein).

Der Versatz, der aus der Addition dieser Komponenten resul­ tiert, wird als effektive Adresse bezeichnet. Jede dieser Komponenten kann entweder einen positiven oder negativen Wert haben. Die Verlage­ rungskomponente ist, da sie in dem Befehl codiert ist, geeignet für re­ lative Adressierung um feste Größen, wie Lokalisierung von einfachen skalaren Operanden, Beginn einer statisch zugeordneten Matrix und Ver­ satz zu einem Feld innerhalb einer Aufzeichnung.

Die Basis- und Indexkomponenten haben ähnliche Funktionen.

Beide verwenden denselben Satz von Generalregistern. Beide können für die Adressierung verwendet werden, die sich während der Programmabarbei­ tung ändert, wie Lokalisieren von Prozedurparametern und lokalen Varia­ blen auf dem Stapel, Beginn einer Aufzeichnung unter mehreren des selben Aufzeichnungstyps oder in einer Matrix von Aufzeichnungen, Beginn einer eindimensionalen oder mehrdimensionalen Matrix oder Beginn einer dyna­ misch zugeordneten Matrix.

Die Anwendung von Generalregistern als Basis- oder Indexkompo­ nente unterscheidet sich im folgenden: Das ESP-Register kann nicht als ein Indexregister verwendet werden. Wenn das ESP- oder EBP-Register als Basis verwendet wird, ist das ESS-Segment die Vorrangauswahl. In allen anderen Fällen ist das DS-Segment die Vorrangauswahl.

Der Skalierungsfaktor ermöglicht die effiziente Indexierung in einer Matrix, wenn die Matrixelemente 2, 4 oder 8 Byte sind. Die Skalie­ rung des Indexregisters erfolgt hardwaremäßig zu dem Zeitpunkt, wenn die Adresse evaluiert wird. Dies eliminiert eine Extraverschiebung oder ei­ nen Multiplizierbefehl.

Die Basis-, Index- und Verlagerungskomponenten können in irgendeiner Kombination verwendet werden, wobei jede dieser Komponenten null sein kann. Ein Skalierungsfaktor kann nur verwendet werden, wenn auch ein Index verwendet wird. Jede mögliche Kombination ist brauchbar für Datenstrukturen, wie sie üblicherweise von Programmierern in Pro­ grammiersprachen hohen Niveaus und Assembly-Sprache verwendet werden. Empfohlene Anwendungen für einige Kombinationen von Adreßkomponenten sind unten beschrieben.

Die Verlagerung allein indiziert den Versatz des Operanden. Diese Form der Adressierung wird verwendet, um auf einen statisch zuge­ ordneten skalaren Operanden zuzugreifen. Eine Byte-, Wort- oder Doppel­ wortverlagerung kann verwendet werden. Der Versatz zu dem Operanden wird indirekt in einem der Generalregister spezifiziert, wie für "basierte" Variable.

Ein Register und eine Verlagerung können gemeinsam für zwei getrennte Zwecke verwendet werden: (1) Der Index in statische Matrix, wenn die Elementengröße nicht 2, 4 oder 8 Bytes ist. Die Verlagerungs­ komponente codiert den Versatz des Beginns der Matrix. Das Register hält die Resultate einer Berechnung zum Bestimmen des Versatzes zu einem spe­ zifischen Element innerhalb der Matrix. (2) Zugriff auf ein Feld einer Aufzeichnung. Das Basisregister hält die Adresse des Beginns der Auf­ zeichnung, während die Verlagerung ein Versatz zu dem Feld ist.

Ein wichtiger Spezialfall dieser Kombination ist Zugriff auf Parameter in einer Prozeduraktivierungsaufzeichnung. Eine Prozedurakti­ vierungsaufzeichnung ist der Stapelrahmen, der erzeugt wird, wenn eine Subroutine eingegeben wird. In diesem Fall ist das EBP-Register die be­ ste Wahl für das Basisregister, weil es automatisch das Stapelsegment auswählt. Dies stellt eine kompakte Codierung für diese übliche Funktion dar.

(INDEX.SKALIERUNG)+VERLAGERUNG. Diese Kombination ist ein ef­ fizienter Weg, in eine statische Matrix zu indexieren, wenn die Elemen­ tengröße 2, 4 oder 8 Bytes ist. Die Verlagerung adressiert den Beginn der Matrix, das Indexregister hält das Subskript des gewünschten Matrix­ elements, und der Prozessor wandelt automatisch das Subskript in einen Index durch Einwirkenlassen des Skalierungsfaktors um.

BASIS+INDEX+VERLAGERUNG. Zwei gemeinsam benutzte Register stützen entweder eine zweidimensionale Matrix (die Verlagerung hält die Adresse des Beginns der Matrix) oder einen von mehreren Zeitpunkten ei­ ner Matrix von Aufzeichnungen (die Verlagerung ist ein Versatz gegenüber dem Feld innerhalb der Aufzeichnung).

BASIS+(INDEX.SKALIERUNG)+VERLAGERUNG. Diese Kombination lie­ fert eine effiziente Indexierung einer zweidimensionalen Matrix, wenn die Elemente der Matrix eine Größe von 2, 4 oder 8 Bytes haben.

Alle Befehlscodierungen sind Untersätze des generellen Be­ fehlsformats, das in Fig. 9 gezeigt ist. Befehle bestehen aus optionalen Befehlspräfixen, einem oder zwei Primärbetriebscodebytes, möglicherweise einer Adreß-Spezifikation, bestehend aus dem ModR/M-Byte und dem SIB-(Skalierindexbasis)-Byte einer Verlagerung, falls erforderlich, und ei­ nem Unmittelbardatenfeld, falls erforderlich.

Kleinere Codierfelder können innerhalb des Primärbetriebscodes oder der Betriebscodes definiert sein. Diese Felder definieren die Rich­ tung der Operation, die Größe der Verlagerung, die Registercodierung oder die Vorzeichenerstreckung; Codierfelder sind variabel, abhängig von der Klasse von Operationen.

Die meisten Befehle die sich auf einen im Speicher befindli­ chen Operanden beziehen können, haben ein Adressierformbyte nach dem (den) Primärbetriebscodebyte(s). Dieses als ModR/M-Byte bezeichnete Byte spezifiziert die anzuwendende Adressierform. Bestimmte Codierungen des ModR/M-Byte indizieren ein zweites Adressierbyte, das SIB-(Skalierindex­ basis)-Byte, das dem ModR/M-Byte folgt und benötigt wird, um vollständig die Adressierungsform zu spezifizieren.

Adressierformen können eine Verlagerung enthalten, die unmit­ telbar entweder dem ModR/M- oder SIB-Byte folgt. Wenn eine Verlagerung vorhanden ist, kann sie 8, 16 oder 32 bit sein.

Wenn der Befehl einen Unmittelbaroperanden spezifiziert, folgt dieser immer irgendwelchen Verlagerungsbytes. Der Unmittelbaroperand, wenn spezifiziert, bildet immer das letzte Feld des Befehls.

Nachstehend die zulässigen Befehlspräfixcodes:

F3H REP-Präfix (nur mit Strangbefehlen verwendet)
F3H REPE/REPZ-Präfix (nur dem Strangbefehlen verwendet)
F2H REPNE/REPNZ-Präfix (nur mit Strangbefehlen verwendet)
FOH LOCK-Präfix

Nachstehend die Segmentüberholpräfixe:

2EH CS-Segmentüberholpräfix
36H SS-Segmentüberholpräfix
3EH DS-Segmentüberholpräfix
26H ES-Segmentüberholpräfix
64H FS-Segmentüberholpräfix
65H GS-Segmentüberholpräfix
66H Operandengrößenüberholung
67H Adressengrößeüberholung

Die ModR/M- und SIB-Bytes folgen den Betriebscodebyte(s) in vielen Prozessorbefehlen. Sie enthalten die folgende Information:

• - Den Indexiertyp oder die Registernummer, die in dem Befehl zu verwenden, ist.
• - Das zu verwendende Register oder mehr Information, um den Befehl zu wählen.
• - Die Basis-, Index- und Skalierinformation.

Das ModR/M-Byte enthält drei Informationsfelder:

• - Das mod-Feld, das zwei höchststellige Bits des Bytes belegt, kombiniert mit dem R/M-Feld zur Bildung von 32 möglichen Werten: Acht Registern und 24 Indexiermoden.
• - Das reg-Feld, das die nächsten drei Bits nach dem mod-Feld belegt, spezifiziert entweder eine Registernummer oder drei zusätzliche Bits der Betriebscodeinformation. Die Bedeutung des reg-Felds wird durch das erste (Betriebscode-) Byte des Befehls festgelegt.
• - Das R/M-Feld, das die drei niedrigststelligen Bits des Bytes belegt, kann ein Register als Lokalisierung eines Operanden spezifizie­ ren oder kann einen Teil der Adressiermoduscodierung in Kombination mit dem mod-Feld bilden, wie oben beschrieben.

Die basiert indexierten und skaliert indexierten Formen der 32-bit-Adressierung benötigen das SIB-Byte. Das Vorhandensein des SIB-Bytes wird durch bestimmte Codierungen des ModR/M-Byte indiziert. Das SIB-Byte enthält dann die folgenden Felder:

• - Das ss-Feld, das die zwei höchststelligen Bits des Bytes be­ legt, spezifiziert den Skalierungsfaktor.
• - Das index-Feld, das die nächsten drei Bits nach dem ss-Feld belegt, spezifiziert die Registernummer des Index-Registers.
• - Das base-Feld, das die drei niedrigststelligen Bits des By­ tes belegt, belegt die Registernummer des Basisregisters.

Fig. 10 zeigt die Formate des ModR/M- und des SIB-Bytes. Die Werte und die entsprechenden Adressierformen sind in der oben genannten Veröffentlichung tabellarisch aufgelistet.

Fig. 11 ist ein detaillierteres Diagramm der Decodierstufe ei­ nes konventionellen Mikroprozessors. Der Leitungspuffer 112 ist auf der Kopfseite des Diagramms gezeigt. Die Decodierstufe entnimmt Befehle für die Decodierung nur aus dem Leitungspuffer 112. Demgemäß stellt dieser die Datenschnittstelle zwischen der Vorabrufstufe und der Decodierstufe dar. Der Vorabrufpuffer ist ein 16-Byte-Kreispuffer. Die Decodierstufe entnimmt Befehlsbytes aus den Bytepositionen im Leitungspuffer 112, wie durch eine Serie von Befehlszeigern vorgegeben, die von den Befehlszei­ gererzeugungsschaltkreisen 1100 erzeugt werden.

Die Befehlszeiger umfassen einen Anforderungsbefehlszeiger (DIP), einen temporären Befehlszeiger (TIP), einen Betriebscodelängen­ zeiger (TIPOPLEN) und einen Verschiebezeiger-(TIPSHIFT). Der DIP wird bei jedem Taktzyklus erzeugt, um auf die lineare Adresse des ersten Byte des gerade von der Decodierstufe bearbeiteten Befehls zu verweisen. Die drei niedrigststelligen Bytes des DIP identifizieren die jeweilige Byte­ position im Leitungspuffer, unter welcher jenes erste Befehlsbyte exi­ stiert (weil die Pufferbreite 8 oder 2³ Bytes beträgt).

Der TIP wird bei jedem Zyklus erzeugt, um auf das erste Byte des Befehls zu verweisen, das von der Decodierstufe noch nicht ver­ braucht worden ist. Die niedrigststelligen Bits des TIP verweisen auf die Byteposition in dem Leitungspuffer 112 des ersten Bytes des Befehls, der noch nicht verbraucht worden ist. Der TIP wird gleich mit dem DIP zu Beginn eines Befehls. Der TIPOPLEN-Zeiger wird gesetzt auf die Summe des TIP-Zeigers und der Betriebscodelänge, so daß er auf das erste Byte von Konstantdaten verweist. Die drei niedrigststelligen Bits des DIPOLEN verweisen auf die Byteposition im Leitungspuffer 112 des ersten Bytes von Konstantdaten, falls solche in dem Befehl enthalten sind.

Der TIPSHIFT-Zeiger verweist auf die Adresse, auf die der TIP aufzufrischen ist, wenn die Decodierstufe Bytes verbraucht. Die drei niedrigststelligen Bits des TIPSHIFT verweisen auf eine Byteposition in dem Leitungspuffer des Bytes, auf welchen der TIP aufgefrischt wird. TIPSHIFT wird von einer der folgenden Bedingungen gesteuert, abhängig von dem Abschnitt des Befehls, der gerade von der Decodierstufe bearbei­ tet wird. TIPSHIFT wird 1) 1, 2) TIP-Zeiger plus Länge des Betriebscode­ unterfels in dem ersten Operanden, falls vorhanden, des gerade in der Decodierung befindlichen Befehls oder 3) TIP-Zeiger plus Länge des zwei­ ten Operanden des Befehls, der gerade decodiert wird.

In der hier verwendeten Terminologie werden Bytes von der De­ codierstufe "verbraucht", wenn sie die Datenbefehlskreise 1102 und 1104 zu der Betriebscodefügeschaltung 1106 und/oder Konstantdatenports 1108, 1110 und 1112 durchlaufen, wo sie entweder decodiert oder in Schattenre­ gistern gespeichert werden, wie vollständiger unten beschrieben. Wenn ein Befehl irgendwelche Präfixbytes hat, werden diese einmal pro Zyklus verbraucht. Alle Betriebscodebytes wie auch alle Bytes des ersten Operanden in dem konstanten Unterfeld, soweit vorhanden, werden gleich­ zeitig in einem Zyklus nach dem Decodieren des letzten Präfixbytes ver­ braucht. Wenn sich in dem konstanten Unterfeld ein zweiter Operand be­ findet, werden alle seine Bytes gleichzeitig in einem nachfolgenden Zy­ klus verbraucht.

Die konventionelle Decodierstufe umfaßt einen Betriebscodeda­ tenbefehlsschaltkreis 1102. Es handelt sich um eine 8-Byte- bis 3-Byte- Befehlsschaltkreisperiode. Er übernimmt alle acht Bytes von dem Leitungspuffer 12 und wählt die Byteposition in dem Leitungspuffer, auf die der TIP-Zeiger verweist und die nachfolgenden Bytes in einer Umlauf­ verarbeitung. Der konventionelle Betriebscodebetriebskreis 1102 enthält Schaltungen für die Bestimmung, ob das erste Byte, auf das der TIP-Zei­ ger verweist, ein Betriebscodebyte oder ein Präfixbyte ist. Wenn es sich um ein Präfixbyte handelt und es als gültig markiert ist, wird es der Betriebscodefügeschaltung 1106 zugeführt, wo es in den Präfixdecodierlo­ gikkreis 1116 eingegeben wird. Die Steuerdecodierlogik 1116 setzt ein Flag im Präfixflagregister 1114 entsprechend der von dem Präfixbyte übertragenen Information. Wenn die Byteposition in dem Leitungspuffer 112, auf die der TIP verweist, nicht als gültig markiert ist, läuft die Decodierstufe einfach bis zu einem nachfolgenden Zyklus leer, in welchem es als gültig markiert ist.

Aufgabe der Erfindung ist es, einen Befehlsdecoder für einen Mikroprozessor nach dem Oberbegriff des Anspruchs zu schaffen, der eine Erhöhung der Anzahl von pro Zyklus decodierten Befehlen ermöglicht.

Diese Aufgabe wird gemäß dem kennzeichnenden Teil des Anspruch gelöst.

Der Befehlsdecoder basiert auf einem Mikrocode. Der Decoder verwendet eine Schnellzugriffstabelle, um Befehle zu decodieren. Der Zeiger zu der Tabelle wird durch den Betriebscode, Gruppenbits und 2-By­ te-Betriebscodebit gegeben. Unter Verwendung dieses Zeigers erfolgt ein schneller Zugriff in der Tabelle. Die Schnellzugriffstabelle, die als Eingabe-ROM (eROM) bezeichnet wird, besteht aus einigen Informationsbits über den Betriebscode zusätzlich zu dem ersten Mikrobefehl. Diese bits werden der Tabelle zugefügt, und sie ermöglichen die schnellere Decodie­ rung des Befehls. Diese Bits zeigen auch, ob der Betriebscode ein ModR-M-Byte hat. In diesem Fall wird das ModR/M-Byte, extrahiert von dem By­ teextraktor, validiert, und dies ergibt eine Eingabe in eine andere Suchtabelle, die als ModR/M-Tabelle bezeichnet wird. Die ModR/M-Tabelle enthält die Adressiermodusinformation und indiziert, ob der jeweilige Befehl einen Speicherzugriff benötigt. Außerdem indiziert die ModR/M-Ta­ belle, ob der Befehl eine skalierte Indexierform des Adressiermodus ent­ hält. Bejahendenfalls validiert sie das SIB-Byte von dem Byteextraktor. Das SIB-Byte ergibt eine Eingabe in eine dritte Suchtabelle, die als SIB-Tabelle bezeichnet wird. Sobald der Befehl aus dem Vorabrufpuffer extrahiert worden ist, liefern die drei Tabellen eROM, ModR/M und SIB gemeinsam gleichzeitig die Befehlslänge, den Adressiermodus, das Quel­ len- und Zielregister und andere Information, und zwar direkt.

Die Eigenschaften von Befehlen, welche Speicheroperanden ver­ wenden, gegenüber jenen, die Registeroperanden verwenden, ist unter­ schiedlich. Dieser Unterschied liegt in dem ersten auszuführenden Mikro­ befehl, der für die meisten Befehle mit Speicheroperanden ähnlich ist. Ein besonders Merkmal des Decoders besteht darin, daß er es ermöglicht, daß durch Verwendung eines "generischen Mikrobefehls" Mikrobefehle mehr­ fach verwendbar sind. Der generische Mikrobefehl ist ein einzelner Mi­ krobefehl. Er macht wirkungsvoll von der Ähnlichkeit in den Eigenschaf­ ten der Befehle mit Speicheroperanden Gebrauch. Seine Anwendung wird von den Informationsbits in der eROM-Tabelle gesteuert.

Die Erfindung wird nachstehend anhand der Beschreibung und von in den beigefügten Abbildungen dargestellten Ausführungsbeispielen näher erläutert.

Fig. 1 zeigt ein Blockdiagramm eines Mikroprozessors mit einem Decoder.

Fig. 2 zeigt ein Blockdiagramm des Decoders von Fig. 1.

Fig. 3 zeigt ein Blockdiagramm zur Darstellung des Adreßer­ zeugungsprozesses, der in dem Decoder verwendet wird.

Fig. 4 zeigt ein Blockdiagramm zur Darstellung der Ausgänge und Verknüpfungen der eROM-, ModR/M- und SIB-Tabellen des Decoders.

Fig. 5 zeigt ein detailliertes Diagramm der Bemessungslogik, die in dem Decoder verwendet wird.

Fig. 6 ist ein detailliertes Diagramm der ROM-Eingabeauswahl.

Fig. 7 ist ein Beispiel einer Codesequenz, in der die Funk­ tionsweise des Decoders gemäß der Erfindung mit der Funktionsweise eines bekannten Decoders verglichen wird.

Fig. 8 zeigt ein Blockdiagramm eines bekannten Pipeline-Mikro­ prozessors.

Fig. 9 zeigt ein Blockdiagramm mit den verschiedenen möglichen Unterfeldern und individuellen Bytes eines in einem Mikroprozessor ver­ wendeten Befehls.

Fig. 10 zeigt ein Blockdiagramm der ModR/M- und SIB-Unterfel­ der und individuellen Bits, die in einem Mikroprozessor verwendet wer­ den.

Fig. 11 ist ein Blockdiagramm einer bekannten Decodierstufe eines Mikroprozessors.

Fig. 1 zeigt die bevorzugte Ausführungsform. Sie umfaßt einen auf einem Mikrocode basierenden Decoderschaltkreis 8 für Mikroprozesso­ ren. Der Decoderschaltkreis 8 umfaßt einen Kreisvorabrufpuffer 10 mit 16 Byte, auf den mittels eines Betriebscodebyteextraktors 12 zugegriffen werden kann. Der Byteextraktor 12 ist mit der Registerstufe über drei Datenpfade verbunden. Die ersten beiden Datenpfade sind 32 bit weit und übertragen die Verlagerung bzw. die unmittelbaren Operanden zu der Regi­ sterstufe. Der dritte Datenpfad ist 16 bit breit und führt den Unmittel­ bar-2-Operanden. Der Betriebscodebyteextraktor 12 ist mit dem Decoder 14 über einen 24-bit-breiten Datenpfad verbunden. Der Decoderschaltkreis 8 umfaßt auch eine Schnellzugriffstabelle, um Befehle zu decodieren, die als Eingabe-ROM (eROM) 16 bezeichnet werden. Auf das eROM 16 wird unter Verwendung von 11 bit von dem Vorabrufpuffer 10 zugegriffen. Der Deco­ derschaltkreis 8 verwendet ein Mikro-ROM (µRom) 18, um einen Mikrose­ quenzer (µ-Sequenzer) 19 anzusteuern, um die verschiedenen Teile des Prozessors zu steuern.

Fig. 2 zeigt eine mehr in einzelne gehende Blockdarstellung der bevorzugten Ausführungsform des Decoders. Der Betriebscodebyteex­ traktor 22 verwendet einen Zeiger, um einen Befehl in dem runden Vorab­ rufpuffer 20 mit 16 Byte zu starten, um auf die ersten drei Bytes eines Befehls zuzugreifen. Demgemäß sind die ersten 24 Bits des Befehls, der zu decodieren ist, unmittelbar für die eROM-Tabelle 24 verfügbar, die ModR-M-Tabelle 26, die SIB-Tabelle 28 und den µROM 30. Der Decoder 14 aus Fig. 5 besteht aus der ModR/M-Tabelle 27, der SIB-Tabelle 28, der Wähllogik 34, der Bemessungslogik 36, der arithmetischen Logikeinheit (ALU) 38 und dem generischen Mikrobefehlsgenerator 32.

Unter Anwendung von Zeigern, die direkt aus nur den ersten drei Bytes der Befehlsdefinition erzeugt werden, erfolgen gleichzeitige Suchvorgänge in der eROM-Tabelle 24, der ModR/M-Tabelle 26 und der SIB-Tabelle 28, um schnell alles über den Befehl herauszufinden, den der Prozessor wissen muß, um die Befehlsfunktionen auszuführen und auf die Operanden des Befehls zuzugreifen. Über die Selektionslogik 34 und die Bemessungslogik 36 wird diese Information in Form von Informationsbits verwendet, um einen Mikrobefehl für ROM-Eingabe 40 zu kompilieren und um die Zeiger und die Längenparameter zu berechnen, die der Prozessor benö­ tigt, um den Mikrobefehl abzuarbeiten.

Der µROM 30, der die Mikrobefehle für alle möglichen Befehle enthält, hat auch gleichzeitigen Zugriff auf die ersten drei Bytes des Befehls. Die eROM-Tabelle 24 enthält auch den ersten Mikrobefehl für die möglichen Befehle, die decodiert werden, und kann einen Mikrobefehl für ROM-Eingabe 40 erzeugen, wenn das Informationsbit "use_µROM" niedrig liegt. Das generische ROM 32 ist ein Einzelmikrobefehl-breiter Speicher, der, wann immer dies möglich ist, als ein "Zwischenlager" für das Zusam­ menführen der bits verwendet wird, die mehreren Betriebscodes gemeinsam sind. Um einen breiteren Bereich von Betriebscodes abzudecken, werden einige der von der eROM-Tabelle 24 erzeugten Informationsbits verwendet, um dynamisch den generischen ROM-Befehl zu erzeugen.

Gemäß Fig. 3 wird der Zeiger zu der eROM-Tabelle 24 durch den Betriebscode 42, die Gruppenbits 46 und ein "Zwei-Byte-Betriebscode"-Bit 60 gegeben. Genauer gesagt, werden das erste Byte des Befehls (als Be­ triebscodebyte 42 bezeichnet), die drei Register- oder Betriebscodebits (Reg/Op-Bits) 46, bei denen es sich um das fünfte, vierte und dritte bit des nächsten Byte, nämlich das ModR/M-Byte 50 des Befehls, handelt und das "Zwei-Byte-Betriebscode-"Bit 60 als eine Adresse in der eROM-Tabelle 24 verwendet. Dies ermöglicht schnellen Zugriff der Tabelle. Das "Zwei-Byte-Betriebscode-"Signal 60 wird erzeugt, indem die Präfixbytes direkt aus dem Vorabrufpuffer 10 während des Taktzyklus gelesen werden, der un­ mittelbar dem Zyklus vorangeht, in welchem die Decodierung erfolgt. Wenn die Präfixbytes OFH sind, dann wird der Zwei-Byte-Betriebscode auf 1 ge­ setzt, was bedeutet, daß die Zwei-Byte-Betriebscodetabelle in dem eROM verwendet werden sollte anstatt der Ein-Byte-Betriebscodetabelle. Die Verwendung dieses Bits verdoppelt im wesentlichen die Anzahl von Be­ triebscodes, mit denen der Prozessor arbeiten kann.

Die eROM-Tabelle 24 besteht aus einem Untersatz von Informa­ tionsbits bezüglich des Betriebscode 42 zusätzlich zu dem ersten Mikro­ befehl. Diese Informationsbits werden der Tabelle 24 ohne zusätzliche Kosten zugefügt, und sie ermöglichen eine schnellere Decodierung des Be­ fehls. Diese Informationsbits zeigen auch, ob der Betriebscode 42 ein ModR/M-Byte 50 hat. Falls es existiert, wird das ModR/M-Byte 50, das von dem Byteextraktor extrahiert wurde, validiert, und die ModR/M-Tabellen­ adresse 80 stellt eine Eingabe in eine Sekundärtabelle bereit, die in Fig. 2 als ModR/M-Tabelle 26 bezeichnet ist. Die ModR/M-Tabellenadresse 80 wird aus den beiden Mod-Bits 44 (dem siebenten und sechsten Bit in dem ModR/M-Byte), den drei R/M-bits 48 (das zweite, erste und nullte Bit in dem ModR-M-Byte, und einem mit a32 bezeichneten Signalbit 72 gebil­ det, das mit dem a32-Überschreibbit EXKLUSIV-ODER-verknüpft wird. Dem Decoder 14 wird ein als "Statusbit" auch als "a32-Bit" bezeichnetes Signal zugeführt. Dieses Signal definiert die Konfiguration des Prozes­ sors. Dieses Bit zeigt nämlich, ob der Prozessor programmiert worden ist, um in einem 16- oder 32-bit-Modus zu laufen. Befehle können Präfixe enthalten, die es der Prozessorkonfiguration ermöglichen, zeitweilig in einen gewünschten Modus verändert zu werden. Mit anderen Worten können Präfixe verwendet werden, um einem als 32-bit-Prozessor konfigurierten Prozessor zu ermöglichen, beispielsweise Befehle als 16-bit-Befehle ab­ zuarbeiten. Das Zustandsbit 72 ist eine vorprogrammierte Konstante, kann jedoch mittels EXKLUSIV-ODER-Verknüpfung mit dem a32-Überschreibbit mo­ difiziert werden, das in dem Präfixbyte enthalten ist, und direkt aus dem Vorabrufpuffer 10 während des Zyklus ausgelesen werden, der unmit­ telbar dem Zyklus vorangeht, in dem die Decodierung erfolgt. Die R/M-Ta­ belle 26 enthält die Adressiermodusinformation und zeigt an, ob der je­ weilige Befehl einen Speicherzugriff benötigt.

Die ModR/M-Tabelle 26 zeigt auch, ob der Befehl die Skalierin­ dexbasisform (SIB) des Adressiermodus enthält. Falls es existiert, wird das SIB-Byte 58, das von dem Byteextraktor extrahiert wurde, validiert und die SIB-Tabellenadresse 86 stellt eine Eingabe in eine Tertiärtabel­ le bereit, die in Fig. 2 als SIB-Tabelle 28 bezeichnet wird. Die drei Tabellen 24, 26 und 28 liefern zusammen die Befehlslänge, den Adressier­ modus, das Ursprungs- und Bestimmungsregister und andere Information, und zwar direkt.

In Fig. 4 sind die spezifischen Informationsbit gezeigt, die mittels programmierbarer Logikschaltungen erzeugt werden, wodurch die eROM-Tabelle 88, die ModR/M-Tabelle 90 und die SIB-Tabelle 92 implemen­ tiert werden. Die Ein-bit-Validierungssignale ModR/M und SIB sind mit den PLAs verbunden gezeichnet, deren Tabellenadresse sie validieren, um die Beziehung und Verknüpfung zwischen den Tabellen anzuzeigen. Das Elength-Signal, das IMM1len-Signal und das IMM2len-Signal zeigen die Längen in Bytes der verschiedenen korrespondierenden Operanden. Das zwei-bit-breite Disp-Signal in Kombination mit den Disp-Signalen der ModR/M- und SIB-Logiken zeigen, wie lang die Verlagerung in Bytes ist. Das drei- oder mehr bit-breite Signal mit der Bezeichnung "Generic me­ mop" wird verwendet, um dynamisch den variablen Teil der generischen In­ struktion in dem generischen ROM 32 zu erzeugen. Das "Use generic-bit- Signal" spezifiziert, wenn das generische ROM 32 ausgewählt ist, so daß der darin zusammengefügte generische Befehl verwendet wird. Dieses Signal wird für beinahe alle Betriebscodes aktiviert (mit einer geringen Anzahl von Ausnahmen), deren Operanden entweder in einem Register oder RAM ge­ halten sind. Beispielsweise können die Betriebscodes, wie BTC, BTR, INC und LLDT, entweder Register- oder Speicheroperanden verwenden. Wie oben erwähnt, ist das "Use_µrom"-Signal ein ein-bit-Signal, das spezifiziert, daß der Mikrobefehl für ROM-Eingabe 40, ausgegeben von dem µROM 30, an­ statt des Ausgangs vom eROM 24 zu verwenden ist.

Wie bei den oben beschriebenen Disp-Signalen indizieren die kombinierten Basissignale der ModR/M- und SIB-Logik und die beiden kom­ binierten Indexsignale der ModR/M- oder SIB-Logik die Länge in Bytes der Basis bzw. des Index. Die Reg1- und Reg2-Signale zeigen die Länge von Registeroperanden. Die "seg_base-override-"Signale der ModR/M- und SIB-Logiken zeigen in Kombination, ob es einen Segmentbasisvorrang gibt. Das dbix-Signal zeigt, ob der Befehlsadressiermodus die Form der Basis-plus- Index-Adressierung verwendet. Das mem_access-Signal zeigt, ob der Befehl einen Speicherzugriff involviert. Schließlich zeigt das scale-Signal die Länge des Skalierfaktors des Index.

Das Verhalten von Befehlen, die Speicheroperanden verwenden, ist unterschiedlich gegenüber jenem, das Registeroperanden verwendet. Für die meisten Befehle jedoch, die Speicheroperanden verwenden, besteht die Differenz nur in dem ersten auszuführen Mikrobefehl. Mit anderen Worten sind häufig alle bis auf wenige Bits des Mikrobefehls dieselben. Der Decoder macht mit Vorteil von dieser Charakteristik von Mikroprozes­ sorbefehlssätzen Gebrauch. Der Intel x86 Befehlssatz der bevorzugten Ausführungsform ist besonders geeignet, diesen Vorteil zur Geltung zu bringen. Gemäß Fig. 2 sieht eine bevorzugte Ausführungsform durch Anwen­ dung eines breiten ROM 32 zum Speichern eines einzelnen "generischen" Mikrobefehls für das ROM-Eingaberegister 40 eine Mehrfachnutzung von Mi­ krobefehlen vor, wo immer das möglich ist. Demgemäß macht ein einzelner generischer Mikrobefehl, der in einem ROM 32 gespeichert ist, wirkungs­ vollen Gebrauch von der Ähnlichkeit im Verhalten (oder Bitmustern) der Befehle, die Speicheroperanden verwenden. Mit anderen Worten ermöglicht die Verwendung dieses ROM 32 zum Bereitstellen des Mikrobefehls für das ROM-Eingaberegister 40 eine Mehrfachverwendung eines Mikrobefehls durch alle Befehle, die Speicheroperanden verwenden.

Die Inhalte des generischen ROM 32 werden unmittelbar durch den Ausgang der eROM-Tabelle 24 und die Auswahllogik 34 ausgewählt. Im einzelnen wird die Verwendung des generischen ROM 32k durch das "used generic"-Bit in der eROM-Tabelle 24 gesteuert. Dies vermeidet Redundanz und spart an Mikrocoderaum.

Wie oben erwähnt, sind viele speicherbasierte Befehle einander ähnlich. Um Vorsorge für jene zu treffen, für die das nicht zutrifft, wird gleichzeitig auf das eROM 24 und µROM 30 zugegriffen. Basierend auf den Informationsbits, die aus der eROM-Tabelle 24 erzeugt werden, wird nur der Mikrobefehl für ROM-Eingabe 40, ausgenommen von eROM-Tabelle 24, oder der Ausgang vom µROM 30 ausgewählt. Auch zeigt ein niedrigliegendes Informationsbit "use_generic"-Signal aus der eROM-Tabelle 24, wenn der generische Mikrobefehl nicht verwendet werden kann. Dieses Merkmal deckt den Rest der Befehle ab, die nicht ähnlich im Falle des Speicheroperan­ den aufgebaut sind. Demgemäß kann das vollständige Verhalten für jeden Befehl in dem Befehlssatz feinabgestimmt werden, um schnellere und effi­ zientere Decodierung des Befehls zu erzielen. Diese schnellere und effi­ zientere Decodierung des Befehls ist nur möglich, indem die prädecodier­ te Information in der eROM-24-Tabelle und ModR/M-24-Tabelle in Verbin­ dung mit der Ausnutzung von Ähnlichkeiten oder Redundanzen in den Bitmu­ stern der Befehlssätze und Erzeugung eines generischen Mikrobefehls er­ möglicht wird, der in dem generischen ROM 32 gespeichert ist.

Die im generischen ROM 32 abgelegten generischen Mikrobefehle ermöglichen, daß sich Befehle, die Speicheroperanden verwenden, einen Mikrobefehl teilen. Um dieses Konzept auf den gesamten Befehlssatz anzu­ wenden und nicht nur auf jene, die Speicheroperanden verwenden, würden mehrere unterschiedliche Versionen des generischen Mikrobefehls sowie zusätzliche Hardeware erforderlich sein, um die jeweilige Version auszu­ wählen, die für den laufenden Befehlstyp angemessen ist. Eine solche Lö­ sung stünde im Widerspruch mit dem Zweck des generischen Mikrobefehls und würde die Vorteile der Verwendung nur eines einzigen Mikrobefehls aufheben. Darüberhinaus würden sich, wenn mehrere Versionen des generi­ schen Mikrobefehls zu implementieren wären, diese sich nur durch ein Feld unterscheiden. Die Lösung bei der bevorzugten Ausführungsform ist die Verwendung eines "dynamischen" generischen Mikrobefehls.

Ein "dynamischer" generischer Mikrobefehl ist in der Lage, beinahe alle Befehle in dem Mikrobefehlssatz zu handhaben, indem Infor­ mationsbits verwendet werden, die als "generic_memop" aus der eROM-Ta­ belle 24 bezeichnet werden, um das korrekte Bitmuster für das eine un­ terschiedliche Feld zu bestimmen. Schnellerer Zugriff wird ermöglicht, indem man nur eine Eingabe in dem generischen ROM hat. Demgemäß wird der generische Mikrobefehl dynamisch unter Verwendung der Information von dem Eingabe-ROM 24 erzeugt.

Der Betriebscode eines Befehls verweist auf einen Eingabepunkt in dem eROM 24. Diese eROM-Tabelle 24 besteht nicht nur aus dem ersten abzuarbeitenden Mikrobefehl, sondern auch aus der prädecodierten Infor­ mation über den Betriebscode. Mit anderen Worten enthält die eROM-Tabel­ le 24 eine Liste aller möglichen ersten Mikrobefehle und prädecodierte Information über jeden Betriebscode. Eingeschlossen in dieser prädeco­ dierten Information ist das "use_generic"-Bit, das die Verwendung des generischen µROM 32 und seine dynamische Erzeugung eines Mikrobefehls für die ROM-Eingabe 40 steuert. Das "use_generic"-Bitsignal spezifi­ ziert, wann der generische ROM 32 ausgewählt wird, so daß der darin zu­ sammengefügte generische Befehl verwendet wird. Dieses Signal wird für beinahe alle Betriebscodes aktiviert (mit einer geringen Anzahl von Aus­ nahmen, deren Operanden entweder in einem Register oder im RAM sein kön­ nen. Beispielsweise können Betriebscodes, wie BTC, BTR, INC und LLDT, entweder Register- oder Speicheroperanden verwenden.

Einige Speicheroperandenbefehle verhalten sich ähnlich wie Re­ gisteroperandenbefehle, doch für einige gilt dies nicht. Um die Decodie­ rung für diesen Typ von Befehlen zu optimieren, wird der SplitµROM-Zu­ griff verwendet. SplitµROM-Zugriff bedeutet, daß auf beide ROMs, den µROM 30 und den eROM 24, gleichzeitig mit derselben Adresse zugegriffen wird. Die relevante Eingabe wird unter Verwendung eines Informationsbits von dem eROM 24 ausgewählt. Genauer gesagt kann die eROM-Tabelle 24 ein Bitsignal erzeugen, das als "use_µROM" bezeichnet wird, welches verwen­ det wird, um entweder den µROM 30 oder den eROM 24 als ROM-Eingabe 40 zu verwenden. Dieses Merkmal erlaubt die Skalierung des Systems, indem meh­ rere Paare von µROMs 30 und eROMs 24 zugefügt werden können, um das Ver­ halten zu optimieren, indem parallele Verarbeitung angewandt wird. Die Informationsbits werden ohne Zusatzkosten dem System zugefügt und ermög­ lichen die schnellere Decodierung, die oben beschrieben wurde, was zu einer Erhöhung der Effizienz führt.

Unter Bezugnahme auf Fig. 5 wird die Logik, die durch die Be­ messungslogik 36 in Fig. 2 für das Berechnen der gesamten Befehlslänge repräsentiert wird, im einzelnen beschrieben. Die Befehlslänge ist gege­ ben durch Σ (erom.elength,modrm,sib, displength, erom,imm1len, erom,imm2len), wobei displength gleich entweder dem eROM-disp, dem ModR-M-disp, dem SIB-disp oder null ist, gewählt basierend auf der Exi­ stenz und dem Typ der Verlagerung innerhalb des diskutierten Befehls. Demgemäß übernimmt der Addierer 95 die elength, imm1len und imm2len Si­ gnale von dem eROM 88, das SIB-Signal von der ModR/M-Tabelle 90 und sum­ miert sie mit dem Ausgang von mux 94, der die Länge der angemessenen Verlagerung repräsentiert. Die entsprechende Verlagerung wird ausge­ wählt, basierend auf den folgenden Logikgleichungen, die in üblicher Weise implementiert werden können:

Wenn (erom.modrm&), dann mux_sel=1;
wenn (erom.modrm&&!modrm.sib), dann mux_sel=2;
wenn (erom.disp), dann mux_sel = 3; und
anderenfalls mux_sel=0.

Der Ausgang dieser Logik, mux_sel, wird verwendet, um das an­ gemessene disp-Signal auszuwählen, das dem Addierer 95 zuzuführen ist.

Fig. 6 zeigt die Auswähllogik 34 aus Fig. 2 für das Auswählen des richtigen Mikrobefehls für die ROM-Eingabe 40. Die Auswähllogik um­ faßt einen Multiplexer 96, der gemäß den folgenden Logikregeln angesteu­ ert wird, die in üblicher Weise implementiert werden können:
Wenn (modrm.memaccess&), dann mux_sel2=0, use-lrom=1;
wenn (use_lrom), dann mux_sel=1,
wenn (use_erom), dann mux_sel=2, und
andernfalls mux_sel2=3.

Die mux_sel2 Logikgleichungen, die oben wiedergegeben sind, werden verwendet, um zwischen den Ausgängen des µROM 30, des eROM 24, des Latch-ROM (lROM) 98 und dem generischen ROM 32 auszuwählen. Das use erom-Signal, das äquivalent dem !use_urom ist, wird verwendet, um zwi­ schen den Ausgängen des µROM 30 und dem eROM 24 zu wählen, der dem lROM 98 zuzuführen ist. Wie man aus den obigen mux_sel2-Gleichungen entnimmt, wird, wenn der generische ROM 32 ausgewählt wird, der lROM 98 in dem un­ mittelbar folgenden Zyklus verwendet. Demgemäß ermöglicht diese Zwi­ schenspeicherung des µROM 30- oder eROM 24-Ausgangs, daß der erste Mi­ krobefehl, der nach einem generischen Mikrobefehl verfügbar ist, verwen­ det wird. Ohne die Zwischenspeicherung würde statt dessen der erste Mi­ krobefehl des nächsten Befehls mit dem generischen Mikrobefehl verwen­ det, was den Decoder aus der Synchronisation herausbringen würde.

In Fig. 7 wird ein Beispiel, wie die ROM-Eingabe 40 erzeugt wird, nach Art eines bisher üblichen Decoders derselben Funktion in dem Decoder der Erfindung gegenübergestellt, wobei der generische Befehl verwendet wird, um deutlich die Vorteile des generischen Befehls heraus­ zustellen. Der Decoder nach dem Stand der Technik erforderte zwei unter­ schiedliche Mikrocodeeingaben für einen einfachen Addierbefehl, einen für Befehle, welche Registeroperanden involvieren, und einen für jene mit Speicheroperanden.

Wenn in dem Decoder gemäß der Erfindung derselbe Addierbefehl Speicher involviert, führt der Decoder zunächst eine Belastung aus und dann den Addiervorgang. Der Decoder wird von der eROM-Tabelle 24 ange­ wiesen, den generischen Mikrobefehl für das Laden zu verwenden, indem das use_generic-Signal eingesetzt wird. Dies ist ein Beispiel für die Anwendung eines generischen Befehls, der eine Speicherbelastung ausführt und dann die Addition durchführt. Die Differenz zwischen dem Addiervor­ gang, der mit dem bekannten Mikroprozessor ausgeführt wird, und jenem gemäß dem erfindungsgemäßen Decoder, besteht darin, daß statt der Ver­ wendung des Registers 1 und des Registers 2 für das Halten der Operanden das Register 1 und das Register 2/temp verwenden werden, abhängig von dem mem_access-Signal von der ModR/M-Tabelle 90. Auf diese Weise ist es in Wirklichkeit derselbe Mikrobefehl. Mit dem generischen Mikrobefehl kann für beide Fälle derselbe Mikrobefehl verwendet werden.

Claims (1)

1. Befehlsdecoder für einen Mikroprozessor mit einem Vorabrufpuf­ fer (10), der zu decodierende Befehle enthält, und einem mit dem Vorab­ rufpuffer in Wirkverbindung stehenden Betriebscodeextraktor (12) zum Entnehmen von Befehlen, gekennzeichnet durch
   einen mit dem Extraktor in Wirkverbindung stehenden ersten ROM-Speicher (24) für Empfang einer Mehrzahl erster Befehls-Bytes und mit Mikrocode-Eingaben für Befehle sowie mit einer Mehrzahl von Aus­ gangssignalen, die Mikrobefehle, Informationsbits bezüglich des gerade decodierten Befehls, und das Vorhandensein eines ModR/M-Bytes in dem Be­ fehl indizieren,
   einen ModR/M-ROM-Speicher (26) in Wirkverbindung mit dem Be­ triebscode-Extraktor für den Empfang einer Mehrzahl erster Befehls-Bytes und mit einer Mehrzahl von Ausgangssignalen, die Informationsbits bezüg­ lich des Befehls und des Vorliegens eines SIB-Bytes in dem Befehl indi­ zieren,
   einen SIB-ROM-Speicher (28) in Wirkverbindung mit dem Be­ triebscode-Extraktor für den Empfang einer Mehrzahl der ersten Befehls- Bytes und mit einer Mehrzahl von Ausgangssignalen, die Information be­ züglich des Befehls indizieren,
   einen Auswahl-Logikschaltkreis (34) mit einem Ausgang und ei­ ner Mehrzahl von Eingängen, die mit einem Mikrobefehlsausgang des Einga­ be-ROM-Speichers verbunden sind, um unter den Eingängen einen Mikrobe­ fehl auszuwählen,
   einen mit einem Eingang des Auswahl-Logikschaltkreises verbun­ denen generischen ROM-Speicher (32),
   einen mit einem Eingang des Auswahl-Logikschaltkreises verbun­ denen Mikrocode-ROM-Speicher (30),
   ein mit einem Eingang des Auswahl-Logikschaltkreises verbunde­ nes Latch-Register,
   ein mit dem Ausgang des Auswahl-Logikschaltkreises verbundenes ROM-Eingaberegister (40), und
   einen Bemessungs-Logikschaltkreis (36) für das Berechnen der Länge des Befehls, verbunden mit den Informationsbit-Signalausgängen des Eingabe-ROM-Speichers, des ModR/M-ROM-Speichers und des SIB-ROM-Spei­ chers.