DE69521461T2

DE69521461T2 - Vorrichtung und Verfahren zur Abtastung einer Befehlswarteschlange

Info

Publication number: DE69521461T2
Application number: DE69521461T
Authority: DE
Inventors: Michael D. Goddard; Nathan L. Yao
Original assignee: Advanced Micro Devices Inc
Current assignee: Advanced Micro Devices Inc
Priority date: 1994-08-18
Filing date: 1995-07-17
Publication date: 2002-04-18
Anticipated expiration: 2015-07-18
Also published as: KR960008542A; EP0697650B1; JPH08190482A; JP3714999B2; KR100354324B1; DE69521461D1; US5896518A; EP0697650A3; ATE202644T1; US5630082A; EP0697650A2

Description

Die vorliegende Erfindung betrifft den Gegenstand unserer mitanhängigen Europäischen Patentanmeldung 04 306 884.1 (0651/320).
Die Erfindung betrifft das Befehlsdekodieren und insbesondere das Abtasten einer Warteschlange von Befehlen mit variabler Länge zum Identifizieren von Befehlselementen zu Dekodierzwecken.
Universalprozessoren basieren typischerweise auf skalaren Befehlssätzen. Prozessorarchitekturen arbeiten entweder auf RISC- (Reduced Instruction Set Computer = Computer mit vermindertem Befehlsvorrat) oder CISC- (Complex Instruction Set Computer = Computer mit komplexem Befehlsvorrat) Basis. Jeder Typ hat seine Vorteile und Nachteile, wie in der Literatur ausführlich dargestellt.
RISC-Architekturen werden in superskalaren Computer-Konfigurationen eingesetzt. Der Ausdruck "superskalar" beschreibt eine Computer-Implementierung, die die Leistung durch gleichzeitige Ausführung skalarer Befehle verbessert. Bei der Implementierung superskalarer RISC-Architekturen wurden gute Fortschritte erzielt. Skalare RISC-Architekturen werden typischerweise unter Berücksichtigung einer Pipeline-Implementierung ausgeführt und weisen zahlreiche Merkmale auf, die die superskalare Implementierung erleichtern. Diese Merkmale umfassen Befehle mit einem festgelegten Format und festgelegter Länge, explizite Befehlsoperanden und eine Lade-/Speicherarchitektur. Superskalare RISC-Architekturen sind bei Johnson, Superscalar Microprocessor Design, Prentice Hall, Englewood Cliffs, New Jersey, 1991, beschrieben.
Obwohl Interesse an der Realisierung supersklarer CISC-Architekturen geäußert worden ist, wurde der Fortschritt teilweise dadurch behindert, dass einige CISC-Architekturen unter Berücksichtigung einer superskalaren Implementierung ausgeführt worden sind. CISC-Architekturen wurden zu einer Zeit ausgeführt, in der die wichtigste Implementiertechnik die Mikrokode-Interpretation des Befehlssatzes war, wobei der Schwerpunkt auf der Entscheidung lag, welche Operationen zu Befehlen zusammengefasst werden sollten, statt auf der Auslegung von Operationen, so dass Überlappungen auftreten konnten. Eine äußerst vielseitige Mikrokode-Interpretation erleichtert nicht die Entwicklung von Pipeline-Architekturen oder superskalaren Architekturen. Es treten Schwierigkeiten aufgrund zahlreicher Aspekte herkömmlicher CISC- Architekturen auf, einschließlich der Befehlsformatkomplexität. Ein Aspekt der Befehlsformatkomplexität ist die Veränderbarkeit der Befehlslänge.
Ein Beispiel eines CICS-Befehlsformats ist das Befehlsformat des Mikroprozessors 80486 und des PentiumTM-Mikroprozessors, erhältlich bei Intel Corporation, Santa Clara, Kalifornien. Bei diesem Befehlsformat, das Charakteristiken früherer Intel-Befehlssätze enthält und generell als Format x86 bekannt ist, kann ein Befehl einen Operationskode ("opcode") aus einem oder mehreren opcode-Bytes, einem Modifikationsregister oder -speicher- ("mod r/m"-) Byte, einem Skalen-Index-Basis- ("sib"-) Byte, Verschiebe-Bytes und Direktdaten- Bytes enthalten. Der opcode spezifiziert den Operationskode und kann ferner eine Registerkennung enthalten. Das mod r/m-Byte spezifiziert, ob ein Operand in einem Register oder Speicher vorhanden ist. Wenn der Operand im Speicher ist, spezifizieren Felder im mod r/m-Byte den anzuwendenden Adressiermodus. Bestimmte Kodierungen des mod r/m-Bytes zeigen an, dass ein zweites Byte, das sib-Byte, zur vollständigen Spezifizierung des Adressiermodus folgt. Das sib-Byte weist ein 2-Bit-Skalenfeld, ein 3-Bit-Indexfeld und ein 3-Bit-Basisfeld auf. Diese Felder werden zum Spezifizieren der Durchführung der Adressenberechnung in Komplexspeicheradressiermoden verwandt. Das Verschiebe-Byte wird bei der Adressenberechnung verwandt. Das Direktdaten-Byte wird für einen Befehlsoperanden verwandt. Eine oder mehrere zusätzliche Bytes, die als Präfix-Bytes bekannt sind, können vor dem opcode- Byte erscheinen. Das Präfix-Byte verändert die Interpretation des Befehls und fügt eine zusätzliche Komplexität hinzu.
Aus dem oben Gesagten geht hervor, dass die Länge eines Befehls im Format x86 stark veränderbar ist. Der Minimalbefehl weist ein einzelnes opcode-Byte auf und ist 8 Bits lang. Ein langer Befehl, der ein Präfix-Byte umfasst, kann 104 Bits lang sein. Längere Befehle mit mehr als einem einzelnen Präfix-Byte sind ebenfalls möglich.
Der Befehl mit variabler Länge und andere komplizierte Merkmale des Befehlsformats x86 haben zu komplexen und somit relativ langsamen Dekodierschaltungen geführt. Langsame Dekodierschaltungen können zwar in langsamen Mikroprozessoren und in einigen CICS-Mikroprozessoren, die Komplexbefehle verarbeiten, akzeptabel sein, sie beeinträchtigen jedoch die Leistung von Mikroprozessoren mit Architekturen, bei denen jedes Funktionselement hinsichtlich der Geschwindigkeit optimiert ist.
WO-A-9320507 beschreibt ein System und ein Verfahren zum Extrahieren komplexer Computerbefehle mit variabler Länge aus einem Strom von Komplexbefehlen, die jeweils in eine variable Anzahl von Befehls-Bytes unterteilt sind, und zum Ausrichten der Befehlsbytes der einzelnen Befehle aus den Komplexbefehlen. Das System empfängt einen Teil des Stroms von Komplexbefehlen und extrahiert einen ersten Satz Befehls-Bytes, beginnend mit den ersten Befehls-Bytes, mittels einer Extrahier-Verschiebeeinrichtung. Der Satz Befehls-Bytes wird dann an ein Ausrichtungs-Latch weitergeleitet, wo er ausgerichtet und an einen Detektor für den nächsten Befehl ausgegeben wird. Der Detektor für den nächsten Befehl bestimmt das Ende des ersten Befehls anhand des Satzes Befehl-Bytes. Eine Extrahier-Verschiebeeinrichtung dient zum Extrahieren und Übermitteln des nächsten Satzes Befehls-Bytes an eine Ausrichtungs-Verschiebeeinrichtung, die den nächsten Befehl ausrichtet und ausgibt. Der Prozess wird dann für die übrigen Befehls-Bytes im Strom von Komplexbefehlen wiederholt. Die isolierten Komplexbefehle werden in Nanobefehle dekodiert, die von einem RISC-Prozessorkern verarbeitet werden.
Es werden ein Verfahren und eine Vorrichtung beschrieben, die einem schnellen Abtasten einer Befehlswarteschlange eines superskalaren Prozessors zum Steuern der Richtung eines oder mehrerer Befehle zu den Dispatch-Positionen im superskalaren Prozessor dienen.
Erfindungsgemäß ist eine Vorrichtung zum Abtasten einer Befehlswarteschlange eines superskalaren Prozessors mit mehreren Dispatch-Positionen vorgesehen, wobei die Befehlswarteschlange vordekodierte Primärbefehle mit variabler Länge enthält, die auf Sekundärbefehle übertragen werden, und wobei die Primärbefehle an von jeweiligen Identifikationselementen identifizierten Plätzen opcodes aufweisen, dadurch gekennzeichnet, dass die Vorrichtung aufweist: eine erste Stufe für eine erste Dispatch-Position des superskalaren Prozessors, wobei die erste Stufe mehrere Maskierlogikgruppen mit mit den Identifikationselementen gekoppelten Eingängen aufweist, einen Look-ahead- Generator zum Reduzieren von Ausbreitungsverzögerungen in der ersten Stufe aufweist, wobei der Look-ahead-Generator einen mit den Identifikationselementen gekoppelten Eingang und mit Maskierlogikgruppen höherer Ordnung der ersten Stufe gekoppelte Ausgänge und einen mit Ausgängen der Maskierlogikgruppen der ersten Stufe gekoppelten Bild-Befehlsinformationsgenerator aufweist; und eine zweite Stufe für eine zweite Dispatch-Position des superskalaren Prozessors, wobei die zweite Stufe mehrere Maskierlogikgruppen mit mit Ausgängen entsprechender Maskierlogikgruppen der ersten Stufe gekoppelten Eingängen und einen Look-ahead-Generator zum Reduzieren von Ausbreitungsverzögerungen in der zweiten Stufe aufweist, wobei der Look-ahead-Generator mit Ausgängen der Maskierlogikgruppen der ersten Stufe gekoppelte Eingänge und mit den Maskierlogikgruppen höherer Ordnung der zweiten Stufe gekoppelte Ausgänge aufweist.
Bei einer Ausführungsform sind die Befehle in der Befehlswarteschlange x86- Befehle und die abgebildeten Befehle RISC-Operationen (ROPs), wobei die abgebildeten Befehlsinformationen ein binäres Signal enthalten, das die Nummer der nächsten zum Dispatch anstehenden abgebildeten ROP anzeigt.
Erfindungsgemäß wird ferner ein Verfahren zum Abtasten einer Warteschlange von Primärbefehlen in einem superskalaren Prozessor bereitgestellt, wobei das Verfahren in Anspruch 13 der beigefügten Ansprüche beschrieben ist.
Die beiliegenden Zeichnungen zeigen beispielhaft:
Fig. 1 ein Blockschaltbild auf Architekturebene eines Prozessors für die Realisierung einer superskalaren Ausführung eines CISC-Befehlssatzes;
Fig. 2 eine bildliche Darstellung eines vordekodierten x86-Befehls, der zur Speicherung in einer Byte-Warteschlange des in Fig. 1 gezeigten Prozessors geeignet ist;
Fig. 3 eine bildliche Darstellung eines Elements des in Fig. 2 gezeigten vordekodierten x86-Befehls;
Fig. 4 ein Blockschaltbild auf Architekturebene des in Fig. 1 gezeigten Befehlsdekodierers;
Fig. 5A, 5B und 5C Flussdiagramme mit Darstellung eines von dem in Fig. 4 gezeigten ROP-Multiplexer implementierten Verfahrens;
Fig. 6A und 6B Teile eines Blockschaltbilds auf Architekturebene einer Byte- Warteschlangen-ROP-Selektions-Abtastlogik des in Fig. 4 gezeigten ROP-Multiplexers;
Fig. 7A, 7B, 7C und 7D Teile eines Blockschaltbilds mit genauerer Darstellung bestimmter Elemente der in Fig. 6A und 6B gezeigten Byte-Warteschlangen-ROP-Selektions-Abtastlogik;
Fig. 8 bis 51 schematische Darstellungen auf Gatterebene einer Ausführungsform der in Fig. 6A und 6B gezeigten Byte-Warteschlangen- ROP-Selektions-Abtastlogik; und
Fig. 52 ein Blockschaltbild der Beziehung zwischen der Byte-Warteschlangen-ROP-Selektions-Abtastlogik und einer Byte-Warteschlangen-SE-Abtastlogik des in Fig. 4 gezeigten ROP-Multiplexers.
Die Architektur eines Prozessors 100 zum Realisieren einer superskalaren Ausführung eines CISC-Befehlssatzes ist in Fig. 1 dargestellt. Der Prozessor 100 basiert auf einem superskalaren RISC-Kern 110 und weist verschiedene Elemente auf, die CISC-Befehle zwecks Verarbeitung durch den Kern 110 in RISC-Operationen, oder ROPs, konvertieren. ROPS weisen eine Anzahl von nützlichen Charakteristiken auf, einschließlich einer "Quelle A - Operation - Quelle B → Ziel-"Struktur, eines festen Platzes des opcodes und der Quellenoperanden, einer Lade-/Speicherarchitektur und direkter Berechnung der Lade-/Speicheradressiermoden. Bei den ROPs für den Kern 110 handelt es sich um drei Operandenbefehle: zwei Quellenoperanden A und B und einen Zieloperanden.
Die CICS-Adressen, Daten und Steuertransfers zwischen den Hauptfunktionsblöcken des Prozessors 100 sowohl zum als auch vom externen Speicher werden auf einen internen Adressen- und Daten- ("IAD"-) Bus 102 übertragen, der über eine Bus-Interface-Einheit ("BIU") 160 zusammen mit einem reellen Markierungsspeicher 162 und einer Speicherverwaltungseinheit 164 an einen (nicht gezeigten) externen Bus angeschlossen ist. Der IAD-Bus 102 ist ein 64- Bit-Bus. Ein Transfer-Targetbus, oder XTARGET-Bus 103, ist ein 32-Bit-Bus, der unterschiedlich priorisierten Anwendungen dient, einschließlich dem Aktualisieren des IDECODE 108 vom Verzweigungsabschnitt BRNSEC 135 im Falle einer falschen Vorhersage, Ausnahmen und Rücksetzungen hinsichtlich der Mikroverzweigung, und Aktualisieren eines Verzweigungs-FIFO im BRNSEC 135 vom IDECODE.
Die verschiedenen Elemente, die CISC-Befehle in ROPs konvertieren, umfassen einen Befehls-Cache-Speicher oder ICACHE 104, eine Byte-Warteschlange oder BYTEQ 106 und einen Befehlsdekodierer oder IDECODE 108. Die CISC- Befehle, d. h. Befehle, die von x86-Mikroprozessoren verwendet werden (nachstehend x86-Befehle genannt), werden im ICACHE 104 geparst und vordekodiert. Der ICACHE 104 ist ein Befehls-Cache-Speicher der ersten Ebene, der die Start- und Endpunkte unverarbeiteter x86-Befehle identifiziert und markiert und "vordekodierte" Informationen kodiert. Die vordekodierten x86- Befehle werden in die BYTEQ106 kopiert, die konzeptionell eine Warteschlange mit bis zu sechzehn Eingaben ist, die null, eine oder mehrere vordekodierte x86-Befehle im "vorhergesagten ausgeführten" Zustand darstellen. Jeder vordekodierte x86-Befehl beginnt an einem Befehlsstart und endet an einem Befehlsende und weist ein oder mehrere Elemente auf. Jedes Element umfasst ein gültiges Bit, ein x86-Befehls-Byte, vordekodierte Informationen im vorhergesagten ausgeführten Zustand und Informationen über eine falsche Vorhersage bezüglich der Verzweigung. Wenn x86-Befehle aus der BYTEQ 106 ausgegeben werden und nachfolgend x86-Befehle an den Anfang der Warteschlange vorrücken, werden die vordekodierten x86-Befehle in Plätze der BYTEQ 106 kopiert, wenn Platz vorhanden ist. Die vordekodierten x86-Befehle aus der BYTEQ 106 werden in den Befehlsdekodierer ("IDECODE") 108 auf jeweilige Sequenzen von ROPs übertragen. Der IDECODE 108 erzeugt den Typ, den opode und die Zeigerwerte für sämtliche auf den vordekodierten x86-Befehlen in der BYTEQ 106 basierende ROPs und bestimmt die Nummer eines möglichen x86-Befehls-Dispatch zur Verschiebung der BYTEQ 106. Der IDECODE 108 hält ferner die Programmzählerwerte spekulativer ROPs und spekulatives Abbilden von Gleitkommazeigern für spekulative Gleitkommaausführung aufrecht. Je nach der Anzahl von ROPs, auf die die x86-Befehle übertragen werden, können bis zu vier x86-Befehle gleichzeitig ausgegeben werden.
Obwohl die BYTEQ 106 zwischen dem ICACHE 104 und dem IDECODE 108 dargestellt ist, kann sie auch in eine der beiden Einheiten integriert, auf beide verteilt oder als separate Einheit implementiert sein.
Die ROP-Befehle werden über verschiedene Busse an den Kern 110 übermittelt. Der Kern 110 trägt vier ROP-Ausgaben, fünf ROP-Resultate und bis zu sechzehn spekulativ ausgeführt ROPs. Bis zu vier Sätze von Zeigern auf die A- und B-Quellenoperanden werden vom IDECODE 108 über jeweilige Busse zu einer Registerdaten ("REGF") 112 und zu einem Neuordnungspuffer (ROB) 114 im Kern 110 geliefert. Die REGF 112 ist eine reelle Registerdatei, die die Bild-x86-Register für die ganzzahligen und Gleitkomma-Befehle enthält. Der ROB 114 ist eine Ring-FIFO-Einrichtung mit vorderen und hinteren Warteschlangenzeigern zur Verfolgung der relativen Reihenfolge spekulativ ausgeführter ROPs. Die Speicherplätze werden den Befehlsresultaten dynamisch zugewiesen. Operanden im Zustand der spekulativen Ausführung werden über einen Rückschreibebus 113 vom ROB 114 in die REGF 112 gesandt.
Die REGF 112 und der ROB 114 führen die entsprechenden "ausgeführten" und "vorhergesagten ausgeführten" Versionen der RISC-Operanden A und B über einen A- & B-Quellenoperandenbus 116 verschiedenen Funktionseinheiten im Kern 110 zu. Bei den verschiedenen Funktionseinheiten im Kern 110 handelt es sich um eine erste arithmetische Logikeinheit ("ALU0") 131, eine zweite arithmetische Logik- und Verschiebeeinheit ("ALU1 & SHF") 132, einen Spezial-Registerblock ("SRB") 133, einen Lade-/Speicherabschnitt ("LSSEC") 134, einen Verzweigungsabschnitt ("BRNSEC") 135 und eine Gleitkommaeinheit ("FPU") 136. Die Funktionseinheiten 131, 132, 133, 134, 135 und 136 umfassen jeweils Reservierungsstationen 121, 122, 124, 125 UND 126 mit mit dem Operandenbus 116 und dem TAD-Bus 118 gekoppelten Eingängen. RISC-opcode-Informationen werden vom IDECODE 108 über einen Typen- und Dispatch-Informations- ("TAD"-) Bus 118 übermittelt. Wenn Resultate über die Beendigung der Ausführung in den Funktionseinheiten 131-136 vorliegen, werden die Resultate und ihre jeweiligen Resultatsmarkierungen über eine Resultatmarkierung mit einer Breite von vier Bussen und einen Resultatbus 140 zu dem ROB 114 sowie den Reservierungsstationen 121-122 und 124-126 geliefert.
Der DCACHE 150 ist eng mit dem LSSEC 134 ausgerichtet, der sowohl ganzzahlige als auch Gleitkomma-Lade- und Speicheroperationen verarbeitet. Bis zu zwei Ladeoperationen greifen gleichzeitig auf den DCACHE 150 zu und übersenden ihre Operationen an den Resultatbus 140. Eine Cache-Speicher- Hit-/Miss-Prüfung auf im DCACHE 150 gespeicherte Daten erfolgt ebenfalls durch den LSSEC 134.
Der Prozessor 100 weist ferner den reellen Markierungsspeicher 162, die Speicherverwaltungseinheit 164 und eine Bus-Interface-Einheit 160 auf, wobei letztere an einen mit einem herkömmlichen externen Speicher 166 gekoppelten herkömmlichen externen Bus angeschlossen ist. Der reelle Markierungsspeicher 162 enthält Markierungen, die sich auf den Inhalt des ICACHE 104 und des DCACHE 150 beziehen. Die Speicherverwaltungseinheit 164 führt Speicheradressenkonvertierungen durch. Die Bus-Interface-Einheit 160 übernimmt Anforderungen bezüglich Lese-/Schreibzyklen aus dem reellen Markierungsspeicher 162 und überwacht Lese-/Schreibzyklen auf dem externen Bus zwecks Sicherstellung der Cache-Speicher-Übereinstimmung im reellen Markierungsspeicher 162, dem ICACHE 104 und dem DCACHE 150 und, bei Detektierung, zwecks Aktualisierung, Invalidierung oder Übermittelung von Daten.
Der in Fig. 1 dargestellte Prozessor 100 arbeitet als fünfstufige Pipeline mit einer Abrufstufe, zwei Dekodierstufen DECODE1 und DECODE2, einer Ausführungsstufe, einer Resultatstufe und einer Rückzugsstufe.
Der ICACHE 104 ist in unserer mitanhängigen europäischen Anmeldung 94306870.0 (0651 322) genauer beschrieben. Die BYTEQ 106 ist in unserer mitanhängigen europäischen Anmeldung 94306873.4 (0651 324) genauer beschrieben. Der IDECODE 108 ist in unserer vorgenannten mitanhängigen europäischen Anmeldung 94306884.1 (0651 320) genauer beschrieben. Eine geeignete Einheit für den Kern 110 ist in unserer mitanhängigen europäischen Anmeldung 94306869.9 (0651 321) offenbart. Weitere geeignete superskalare RISC-Kerne sowie geeignete RISC-Befehlssätze sind auf dem Gebiet bekannt. Der DCACHE 150 und der LSSEC 134 sind in unserer mitanhängigen europäischen Anmeldung 94306885.8 (0651 332) genauer beschrieben. Der reelle Markierungsspeicher 162 und der LSSEC 134 sind in unserer mitanhängigen europäischen Patentanmeldung 94306872.6 (0651 323) genauer beschrieben.
Eine generelle Darstellung eines vordekodierten x86-Befehls aus der Verarbeitung eines x86-Befehls im ICACHE 104 ist in Fig. 2 zu sehen. Der vordekodierte x86-Befehl kann bis zu sechs Befehlselemente aufweisen. Wenn ein Präfix oder mehrere Präfixe in dem unverarbeiteten x86-Befehl vorhanden sind, enthält der vordekodierte x86-Befehl ein Präfixelement oder mehrere Präfixelemente. Das letzte Präfixelement ist ein konsolidiertes Präfixelement mit kompletten Präfixinformationen für den IDECODE 108, während die anderen Präfixelemente rekodierte Präfixelemente mit Teilinformationen sind und nicht vom IDECODE 108 verwendet werden. Fig. 2 zeigt ein rekodiertes Präfixelement 202 und ein konsolidiertes Präfixelement 204. Ein OPCODE- Element 210 mit einem x86-Befehls-opcode-Byte folgt den Präfixelementen 202 und 204. Wenn der unverarbeitete x86-Befehl eine spezielle Speicheradressierung durchführt, enthält der vordekodierte x86-Befehl ein mod r/m- Element, z. B. ein mod r/m-Element 212. Wenn der unverarbeitete x86-Befehl bestimmte Adressiermoden erfordert, enthält der vordekodierte x86-Befehl ein sib-Element, z. B. ein sib-Element 214. Wenn der unverarbeitete x86-Befehl Verschiebeinformationen für eine Adressenberechnung erfordert oder Direktdaten enthält, weist der vordekodierte x86-Befehl ein Verschiebe-/Direktdatenelement auf, z. B. ein Verschiebe-/Direktdatenelement 216.
Vordekodierinformationen werden von verschiedenen Bits befördert, die von den Kodes v, s, e, rop und op identifiziert werden. Bit "v" ist ein gültiges Bit, das anzeigt, ob ein bestimmtes Element Teil eines gültigen Befehls ist, Bit "s" ist ein Startbit, das das erste Element des vordekodierten x86-Befehls identifiziert, Bits "rop" zeigen die Anzahl von für den x86-Befehl erforderlichen ROPs an, Bits "op" identifizieren das x86-Befehls-opcode-Element und Bit "e" ist ein Endbit, das das letzte Element des vordekodierten x86-Befehls identifiziert.
Fig. 2 zeigt aktivierte Vordekodierinformationsbits. Sämtliche Elemente in dem in Fig. 2 dargestellten vordekodierten x86-Befehl sind gültig, wie durch ein aktiviertes "v"-Bit angezeigt. Das erste Element des in Fig. 2 dargestellten vordekodierten x86-Befehls, das rekodierte Präfix 202, wird von einem aktivierten "s"-Bit identifiziert. Bits "rop" sind nicht als im rekodierten Präfixelement 202 aktiviert dargestellt, da die Rekodieroperationen möglicherweise keine gültigen rop-Informationen ergeben. Da die rop-Bits in der letzten Rekodieroperation jedoch gültig sind, enthalten das konsolidierte Präfix 204 und sämtliche nachfolgenden Elemente des vordekodierten x86-Befehls verwendbare rop-Bits. Bits "op" identifizieren das x86-Befehls-opcode-Element 210. Das Verschiebe-Direktelement 216 wird von einem aktivierten "e"-Bit als letztes Element des vordekodierten x86-Befehls markiert.
Die BYTEQ 106 wird in mehreren Arrays aufrechterhalten, wie für das repräsentative Byte-Warteschlangenelement "x" aus Fig. 3 dargestellt. Das Array BYTEQ enthält Bytes, die aus Bytes des unverarbeiteten x86-Befehls ausgewählt oder von diesen abgeleitet worden sind, einschließlich Informationen über rekodierte Präfixe, Informationen über konsolidierte Präfixe, opcode-Informationen, mod r/m-Informationen, sib-Informationen oder Informationen über Verschiebe- oder Direktdaten. Somit enthält das in Fig. 3 dargestellte repräsentative Byte-Warteschlangenelement "x" Bits BYTEQx[7 : 0]. Das Array BYTEQV enthält die gültigen Bits. Somit weist das in Fig. 3 dargestellte Byte- Warteschlangenefement "x" Bit BYTEQV[x] auf, das anzeigt, ob das x. Element gültig ist. Informationen über eine falsche Byte-Vorhersage enthält BYTEQNS[x], BYTEQCLMO[x] und BYTEQCLM1[x].
Die Vordekodierinformationsbits s, e, op und rop sind in dem s-Bit-Array BYTEQS, dem e-Bit-Array BYTEQE, dem op-Bit-Array BYTEQP2 und den rop- Bit-Arrays BYTEQP1 und BYTEQPO für die zwei Bits der rop-Informationen enthalten, wobei jeder Eintrag einem Platz in der BYTEQ 106 entspricht. In Fig. 3 enthalten die Vordekodierinformationen für das x. Element BYTEQP2[x], das im Falle einer logischen 1 anzeigt, dass das begleitende unverarbeitete Byte ein opcode-Byte ist, BYTEQP1[x] und BYTEQPO[x], die die Anzahl von für die Ausführung des x-86-Befehls erforderlichen ROPs anzeigen, BYTEQS[x], das anzeigt, ob das begleitende unverarbeitete Byte das erste Byte des x86- Befehls ist, und BYTEQE[x], das anzeigt, ob das begleitende unverarbeitete Byte das letzte Byte des x86-Befehls ist.
Der IDECODE 108, der in Fig. 4 genauer dargestellt ist, ist ein zweistufiger Pipeline-Dekodierer, der vordekodierte x86-Befehls-Bytes von der BYTEQ 106 empfängt, diese jeweils in ROP-Sequenzen übersetzt und ROPs schnell von mehreren Dispatch-Positionen weiterleitet. Zur Maximierung der Gelegenheit zur Ausgabe mehrerer Befehle wird die Übersetzung in einem festverdrahteten schnellen Konvertierungspfad für einfachste Befehle verarbeitet, die sich bei der in Fig. 4 dargestellten Ausführungsform auf x86-Befehle bezieht, die auf drei ROPs oder weniger übertragen werden. Befehle, die mehr als drei ROPs benötigen, und selten benutzte Befehle werden von Mikrokodesequenzen im Mikrokode-ROM verarbeitet. Unabhängig davon, ob ein x86-Befehl auf mehrere ROP-Befehle oder den Mikrokode-ROM übertragen werden, werden Informationen über vordekodierte x86-Befehle an mehreren Dispatch-Positionen dupliziert, so dass jede Dispatch-Position unabhängig und parallel zu anderen Dispatch-Positionen arbeiten kann.
Im IDECODE 108 leitet ein ROP-Multiplexer ROPMUX 400 Eingaben der BYTEQ 106 zu vier Dispatch-Positionen 410, 420, 430 und 440. In jeder Dispatch-Position führt ein schneller Konverter (z. B. FASTCONVO 412, FASTCONV1 422, FASTCONV2 432 oder FASTCONV3 442) eine schnelle Konvertierung eines "einfachen" x86-Befehls (d. h. eines Befehls, der auf maximal 3 ROPSs übertragen wird) in eine der ROPs in der Sequenz, auf die der x86-Befehl übertragen wird, durch. Jede Dispatch-Position weist ferner einen Mikrokode- ROM (z. B. MROM0 416, MROM1 426, MROM2 436 oder MROM3 446) auf, der einen Mikrokode-ROM zum Konvertieren von selten benutzten x86-Befehlen und x86-Befehlen, die ROP-Sequenzen von mehr als drei ROPs benötigen, in eine der ROPs in der Sequenz, auf die der x86-Befehl übertragen wird, verwendet. Die gemeinsamen Stufen ICOMMONO 414, ICOMMON1 424, ICOMMON2 434 und ICOMMON3 444 führen eine Pipeline-Verarbeitung von Teilen der Operationen zum Konvertieren der x86-Befehle durch, die effektiv auf eine bestimmte Weise verarbeitet werden können, und zwar ungeachtet der Tatsache, ob der Befehl ein Fastpath- oder Mikrokode-ROM-Befehl ist. ROPSELECTO 418, ROPSELECT1 428, ROPSELECT2 438 und ROPSELECT3 448 selektieren jeweils entweder die Ausgänge des jeweils zugeordneten schnellen Konverters und der gemeinsamen Pfade oder die Ausgänge des jeweils zugeordneten Speichers ROM und der gemeinsamen Pfade und erzeugen Dispatch- Informationen. ROPSHARED 490 spricht auf Informationen von ROPSELECTO 418, ROPSELECT1 428, ROPSELECT2 438 und ROPSELECT3 448 an zwecks Erzeugung von Dispatch-Informationen für Resourcen, die von sämtlichen Dispatch-Positionen gemeinsam genutzt werden. Der IDECODE 108 wird von IDECCNTL 460 gesteuert.
ROPMUX 400 ist für das Zuweisen eines kompletten vordekodierten x86-Befehls in der BYTEQ 106 auf eine oder mehrere der Dispatch-Positionen 410, 420, 430 und 440 im IDECODE 108 zuständig. Eine oder mehrere vordekodierte x86-Befehle werden gleichzeitig von der BYTEQ 106 zu verfügbaren Dispatch-Positionen 410, 420, 430 und 440 geleitet, beginnend mit dem x86- Befehl am Anfang der BYTEQ 106. Wenn z. B. davon ausgegangen wird, dass sämtliche Dispatch-Positionen verfügbar sind, wenn jeder der ersten vier vordekodierten x86-Befehle in der BYTEQ 106 auf eine ROP übertragen wird, wird der erste vordekodierte x86-Befehl am Anfang der BYTEQ 106 im Multiplexbetrieb auf die Dispatch-Position 0 geführt, der zweite vordekodierte x86-Befehl im Multiplexbetrieb auf die Dispatch-Position 1 geführt, der dritte vordekodierte x86-Befehl im Multiplexbetrieb auf die Dispatch-Position 2 geführt und der vierte vordekodierte x86-Befehl im Multiplexbetrieb auf die Dispatch-Position 3 geführt. Alternativ wird, wenn der zweite vordekodierte x86-Befehl in der BYTEQ 106 auf zwei ROPs übertragen wird, der erste vordekodierte x86-Befehl im Multiplexbetrieb auf die Dispatch-Position 0 geführt, der zweite vordekodierte x86-Befehl im Multiplexbetrieb auf die Dispatch-Positionen 1 und 2 geführt und der dritte vordekodierte x86-Befehl im Multiplexbetrieb auf die Dispatch-Position 3 geführt.
Einem vordekodierten x86-Befehl, der nicht auf den Mikrokode-ROM übertragen wird und nicht vollständig in das Dispatch-Fenster passt, werden so viele Dispatch-Positionen 410, 420, 430 und 440 zugewiesen, wie im ersten Dispatch-Fenster zur Verfügung stehen. Die IDECCNTRL 460 verwendet ein Signal PARTIALDISP[1 : 0] zur Anzeige der Nummer der als nächstes zum Dispatch anstehenden ROP für den vordekodierten x86-Befehl am Anfang der Warteschlange im nächsten Zyklus, so dass den bereits zugeteilten ROPS keine Dispatch-Positionen zugewiesen werden.
PARTIALDISP[1 : 0] wird in der IDECCNTRL 460 aus dem Signal ROPxDIFF[1 : 0] erhalten, das für jede Dispatch-Position "x" (x = 0, 1, 2, 3) die Nummer der nächsten noch zum Dispatch anstehenden ROP anzeigt. Die erste ROP in einer Sequenz trägt die Nummer 0, die zweite die Nummer 1 und so weiter. Insbesondere wird PARTIALDISP[1 : 0] für den nächsten Zyklus aus einem der ROPxDIFF-Signale, das anhand der Anzahl vorhergesagter und vom aktuellen Dispatch-Fenster weiter zu leitender ROPs ausgewählt wird, zwischengespeichert. Wenn z. B. sowohl der Befehl am Anfang der Warteschlange als auch der nächste Befehl auf drei ROPs übertragen werden, entsprechen ROP0DIFF und ROP1DIFF dem Befehl am Anfang der Warteschlange, während ROP2DIFF und ROP3DIFF dem nächsten Befehl entsprechen. ROP0DIFF ist 1, ROP1DIFF ist 2, ROP2DIFF ist 0 und ROP3DIFF ist 1. Wenn die IDECCNTRL 460 bestimmt, dass alle vier ROPs im Dispatch-Fenster zum Dispatch anstehen, wird ROP3DIFF ausgewählt und als PARTIALDISP zwischengespeichert. Der Wert von PARTIALDISP für das nächste Dispatch-Fenster ist daher Eins.
Die Operation des ROPMUX 400 ist in Fig. 5 dargestellt, in der ein Flussdiagramm einer auf der BYTEQ 106 ausgeführten Abtastfunktion gezeigt ist. Wenn die BYTEQ 106 nach einer Verschiebeoperation gültig wird, "tastet" der ROPMUX 400 schnell die BYTEQ 106 ab, um bestimmte Informationen über komplette vordekodierte x86-Befehle und die Anzahl von ROPs, auf die sie übertragen werden, zu identifizieren und zu erhalten. Ein schnelles Abtasten bietet mehr Zeit für die Konvertierungsprozesse, die im Prozessor 100 schnell abgeschlossen werden müssen. Zur Vermeidung unnötiger Verzögerungen erfolgt das Abtasten vorzugsweise im wesentlichen gleichzeitig unter Verwendung der in Fig. 8 bis 51 gezeigten und anderer, ähnlich ausgeführter Schaltungen, obwohl andere logische Schaltungen zur Durchführung der in der Architektur aus Fig. 6 und 7 dargestellten Funktionen möglich sind. Das in Fig. 5 dargestellte Flussdiagramm zeigt die verschiedenen durchgeführten Abtastoperationen und darf nicht als sequentielle Ordnung dieser verschiedenen Operationen interpretiert werden.
Bei Operation 502 beginnt die Byte-Warteschlangen-Abtastfunktion am Anfang der BYTEQ 106, wobei sämtliche gültigen und kompletten Befehle, die gemeinsam auf vier ROPs übertragen werden, identifiziert werden. Wenn das Ende der Warteschlange vor der Detektion von vier ROPs erreicht ist, identifiziert die Byte-Warteschlangen-Abtastfunktion sämtliche gültigen und kompletten Befehle in der BYTEQ 106. Die Befehle werden durch Detektieren ihrer jeweiligen Startbits im Array BYTEQS und gültigen Bits im Array BYTEQV identifiziert. Das Identifizieren kompletter Befehle erfolgt durch Bestimmen, dass das Startbit des Befehls ein gegenüber liegendes Endbit im Array BYTEQE aufweist.
Bei der Operation 502 erzeugt der ROPMUX 400 ferner die Steuersignale ROPxNUM[1 : 0] und ROPxDIFF[1 : 0], die jeweils für die Dispatch-Position "x" die Nummer in der ROP-Sequenz anzeigen, in der sie Teil der aktuellen zum Dispatch anstehenden ROP ist, und die Nummer in der ROP-Sequenz anzeigen, in der sie Teil der nächsten zum Dispatch anstehenden ROP ist. Wenn z. B. sowohl der Befehl im vorderen Teil der Warteschlange als auch der nächste Befehl auf drei ROPs übertragen werden, ist ROP0NUM 0, ROPiNUM 1, ROP2NUM 2 und ROP3NUM 0; wohingegen ROP0DISP 1, ROP1DISP 2, ROP2DISP 0 und ROP3DISP 1 ist.
Der ROPMUX 400 erzeugt ferner ein Steuersignal PGNXT[x], das anzeigt, ob die ROP in der Dispatch-Position "x" die letzte ROP in der ROP-Sequenz ist, die von dem entsprechenden x86-Befehl übertragen wird. Wenn ROPxDIFF 00 ist, wodurch angezeigt wird, dass die nächste Dispatch-Position die erste von einem neuen x86-Befehl übertragene ROP weiterleiten wird, ist PGNXT[x] 0; andernfalls ist PGNXT[x] 1. PGNXT[x] wird zu anderen Byte-Warteschlangen- Abtastlogikschaltungen geliefert, die solche Informationen benötigen, wie die in Fig. 52 dargestellte Byte-Warteschlangen-SE-Abtastlogik 5200.
Bei Operation 504 wird die Position der opcodes in jedem in Operation 502 identifizierten Befehl identifiziert und in Arrays ISEL0, ISEL1, ISEL2 und ISEL3 gemeldet.
Bei Operation 506 erfolgt die Bestimmung, ob der vordekodierte x86-Befehl am Anfang der BYTEQ 106 ein auf einen Mikrokode-ROM übertragener Befehl ist, der angezeigt wird, wenn BYTEQP1[x], BYTEQPO[x] 11 ist. Die Bestimmung wird im ROPMUX 400 durchgeführt, und die Meldung erfolgt als Signal ROPMROM. Die in Fig. 5B dargestellten Operationen werden durchgeführt, wenn der vordekodierte x86-Befehl am Anfang der BYTEQ 106 ein auf einen Mikrokode-ROM übertragener Befehl ist. Die in Fig. 5C dargestellten Operationen werden ausgeführt, wenn der vordekodierte x86-Befehl am Anfang der BYTEQ 106 kein auf einen Mikrokode-ROM übertragener Befehl ist.
Wenn der vordekodierte x86-Befehl am Anfang der BYTEQ 106 kein auf einen Mikrokode-ROM übertragener Befehl ist, werden die Dispatch-Positionen 410, 420, 430, und 440 bei Operation 532 (Fig. 5C) vordekodierten x86-Befehlen zugewiesen, und zwar abhängig von der Anzahl der ROPs, auf die jeder vordekodierte x86-Befehl übertragen wird, und der Anzahl der zur Verfügung stehenden Dispatch-Positionen. ROPxNUM für die auf diese Weise zugewiesenen Dispatch-Positionen erhalten ihre jeweiligen Werte, Steuersignal ROPROM wird nicht aktiviert und MUXVAL[x] für jede Dispatch-Position wird aktiviert.
Es sei z. B. angenommen, dass sich der opcode für Befehl 11 am Anfang der Warteschlange in der Position 0 in der BYTEQ 106 befindet. Der Wert von BYTEQP1[0] und BYTEQPO[x0] für den Befehl 11 ist 10, wodurch angezeigt wird, dass der Befehl 11 auf drei ROPs übertragen wird. Die ersten drei Dispatch-Positionen 0, 1 und 2 sind verfügbar und werden dem Befehl 11 zugewiesen. Es sei ferner angenommen, dass sich der opcode für den nächsten Befehl 12 in der Position 5 in der BYTEQ 106 befindet. Der Wert von BYTEQP1[5] und BYTEQPO[5] ist ebenfalls 10, wodurch angezeigt wird, dass der Befehl 12 auf drei ROPs übertragen wird. Da nur eine Dispatch-Position verfügbar ist, wird sie dem Befehl 12 zugewiesen, Es sei darauf hingewiesen, dass die Dispatch-Positions-Resourcen in der vorliegenden Dekodierstufe nicht für die vollständige Zuweisung an den Befehl 12 zur Verfügung stehen. Die übrigen zwei benötigten Dispatch-Positionen werden dem Befehl 12 im nächsten Zyklus zugewiesen, nachdem der Befehl 12 entsprechend dem Steuersignal PARTIALDISP, das zum Anzeigen der Nummer der nächsten zum Dispatch anstehenden ROP auf Eins gesetzt ist, zum Anfang der BYTEQ 106 verschoben worden ist. Wenn einer der auf das aktuelle Dispatch-Fenster wartenden und nicht am Anfang der BYTEQ 106 befindlichen x86-Befehle auf einen Mikrokode-ROM übertragen wird, werden Dispatch-Positionen weiterhin zugewiesen. ROPxNUM für auf diese Weise zugewiesene Dispatch-Positionen lautet jedoch "Ignorieren", da das Steuersignal ROPMROM nicht aktiviert ist und ROPs, die von Dispatch-Positionen weitergeleitet worden sind, die x86-Befehlen zugewiesen sind, welche auf einen Mikrokode-ROM übertragen werden, sich jedoch nicht am Anfang der Warteschlange befinden, nicht als gültig (MUXVAL[x] für Dispatch-Position x nicht aktiviert) markiert sind. Ungültige ROPs werden nicht in den nachfolgenden Pipeline-Stufen des Prozessors 100 verarbeitet.
Bei Operation 534 empfängt jede Dispatch-Position vier Elemente von einem in der BYTEQ 106 gespeicherten vordekodierten x86-Befehl. Die vier Elemente bilden ein konsolidiertes Präfix-Datenelement am Byte-Warteschlangenplatz Y-1, ein opcode-Element am Byte-Warteschlangenplatz Y, ein mod r/m-Element am Byte-Warteschlangenplatz Y+1 und ein sib-Element am Platz Y+2, wobei Y der Platz des opcode-Elements des Befehl in der BYTEQ 106 ist.
Bei Operation 536 werden die nächsten Anfänge für eine, zwei, drei und vier weitergeleitete ROPs bestimmt. Diese Informationen werden zum ICACHE 104 geliefert, wo sie für das Verschieben der BYTEQ 106 verwendet werden.
Wenn der vordekodierte x86-Befehl am Anfang der BYTEQ 106 ein auf einen Mikrokode-ROM übertragener Befehl ist, werden alle vier Dispatch-Positionen dem auf den Mikrokode-ROM übertragenen Befehl zugewiesen. Für einen auf einen Mikrokode-ROM übertragenen Befehl ist die Wert von BYTEQP1 und BYTEQPO 11, wodurch angezeigt wird, dass der Befehl auf einen Mikrokode- ROM übertragen ist. Wenn die Zuweisung von vier Dispatch-Positions-Resourcen für die Beendigung der Weiterleitung der ROP-Sequenz, auf die der x86-Befehl übertragen wird, nicht ausreicht, werden die vier Dispatch-Positions-Resourcen im nächsten Zyklus erneut dem auf einen Mikrokode-ROM übertragenen Befehl zugewiesen. ROPxNUM für die auf diese Weise zugewiesenen Dispatch-Positionen ist "Ignorieren", da sie nicht benötigt wird, die Dispatch-Positionen werden als gültig (MUXVAL[3 : 0]-Bits sind aktiviert) markiert und das Steuersignal ROPMROM wird aktiviert, da sich der auf einen Mikrokode-ROM übertragene x86-Befehl am Anfang der Warteschlange befindet.
Bei Operation 522 bildet IDECCNTRL 460 eine Eintrittsstelle eines Mikrokode- ROMs und greift auf eine ROP-Sequenz in MROM0 416, MROM1 426, MROM2 436 und MROM3 446 zu.
Bei Operation 524 werden das konsolidierte Präfix-Datenelement, das opcode- Element, das mod r/m-Element und das sib-Element vom auf einen Mikrokode übertragenen x86-Befehl am Anfang der BYTEQ 106 als Signale ROPxPRE-, ROPxOP-, ROPxMODRM- und ROPxSIB-Elemente zu sämtlichen Dispatch- Positionen zwecks Verwendung durch ICOMMONx geliefert. Das konsolidierte Präfix-Datenelement befindet sich am Byte-Warteschlangenplatz Y-1, das opcode-Element befindet sich am Byte-Warteschlangenplatz Y, das mod r/m- Element befindet sich am Byte-Warteschlangenplatz Y+1 und das sib-Element befindet sich am Platz Y+2, wobei in der BYTEQ 106 Y der Platz des opcode- Elements des Befehls am Anfang der Warteschlange ist. Wenn ein Element nicht im vordekodierten x86-Befehl vorhanden ist, wie von den Start- und Endbits des Befehls festgelegt, werden die an der Dispatch-Position entsprechend dem nicht vorhandenen Element empfangenen Informationen als "Ignorieren"-Informationen behandelt.
Bei Operation 526 werden die nächsten Anfänge der Warteschlange für eine, zwei, drei und vier weitergeleitete ROPs festgelegt. Diese Informationen dienen dem Verschieben der BYTEQ 106, falls der auf einen Mikrokode übertragene x86-Befehl vollständig weitergeleitet ist.
Eine für den Einsatz im ROPMUX 440 geeignete schnelle Byte-Warteschlangen-Abtastlogikarchitektur 690 zum Verarbeiten der opcode- und ROP-Nummer-Arrays BYTEQP2, BYTEQP1 und BYTEQPO ist in Fig. 6A und 6B dargestellt. Die Abtastlogikarchitektur 690 weist vier Stufen 600, 610, 620 und 630 auf, die jeweils den Dispatch-Positionen 0, 1, 2, und 3 entsprechen, obwohl eine kleinere oder größere Anzahl von Stufen möglich ist, falls gewünscht. Einer der Eingänge in die Abtastlogikarchitektur 690 ist der Ausgang des Arrays BYTEQP2[15 : 0], bei dem es sich um einen 16-Bit-Bus handelt, der die Plätze der opcode-Bytes in der BYTEQ 106 anzeigt. Ausgänge der Stufen 600, 610, 620 und 630 der Abtastlogikarchitektur 690 umfassen jeweils ISEL0, ISEL1, ISEL2 und ISEL3. Ausgangsbits ISEL0[15 : 0] bilden einen 16-Bit-Ausgangsbus, der den Platz des opcode-Bytes für die erste Dispatch-Position anzeigt. Bits ISEL1[15 : 0] bilden einen 16-Bit-Ausgangsbus, der den Platz des opcode-Bytes für die zweite Dispatch-Position anzeigt. Bits ISEL2[15 : 0] bilden einen 16-Bit-Ausgangsbus, der den Platz des opcode-Bytes für die dritte Dispatch-Position anzeigt. Bits ISEL3[15 : 0] bilden einen 16-Bit-Ausgangsbus, der den Platz des opcode-Bytes für die vierte Dispatch-Position anzeigt. Diese Ausgänge gelten für die Steuerlogik, wie einem (nicht gezeigten) 16 : 1-Multiplexer im ROPMUX 400 zum Leiten der Befehls-opcodes von der BYTEQ 106 in die jeweiligen Verarbeitungspfade FASTCONVO 412 und ICOMMONO 414, FASTCONV1 422 und ICOMMON1 424, FASTCONV2 432 und ICOMMON 434 und FASTCONV3 442 und ICOMMON 444.
Die folgenden Beispiele dienen der Erläuterung der Beziehung zwischen den Bits des Eingangsbusses BYTEQP2[15 : 0] und den Bits der Ausgangsbusse ISEL0[15 : 0], ISEL1[15 : 0], ISEL2[15 : 0] und ISEL3[15 : 0]. Es sei z. B. angenommen, dass das Signal BYTEQP2[15 : 0] binär 1010-0100-0000-1001 ist, wodurch angezeigt wird, dass sich das erste opcode-Byte des ersten Befehls am Byte-Warteschlangenplatz 0 befindet, sich das erste opcode-Byte des zweiten Befehls am Byte-Warteschlangenplatz 3 befindet, sich das erste opcode-Byte des dritten Befehls am Byte-Warteschlangenplatz 10 befindet und sich das erste opcode-Byte des vierten Befehls am Byte-Warteschlangenplatz 13 befindet. Beim ersten Beispiel sei angenommen, dass sowohl der Befehl am Anfang der Warteschlange als auch der unmittelbar darauf folgende Befehl auf drei ROPs übertragen werden. In diesem Fall sind die Ausgänge ISEL0[15 : 0], ISEL1[15 : 0], ISEL2[15 : 0] und ISEL3[15 : 0] der Abtastlogik 1700 in Tabelle 1 dargestellt. TABELLE 1
Es sei darauf hingewiesen, dass ISEL0, ISEL1 und ISEL2 identisch sind, da der gleiche opcode zu den ersten drei Dispatch-Positionen geleitet worden ist. Beim zweiten Beispiel sei zu Vergleichszwecken angenommen, dass die ersten vier Befehle in der BYTEQ 106 jeweils auf eine ROP übertragen werden. In diesem Fall sind die Ausgänge ISEL0[15 : 0], ISEL1[15 : 0], ISEL2[15 : 0] und ISEL3[15 : 0] der Abtastlogik 1700 nachstehend in Tabelle 2 aufgeführt. TABELLE 2
Es sei darauf hingewiesen, dass sich ISEL0, ISEL1, ISEL2 und ISEL3 voneinander unterscheiden, da unterschiedliche opcodes zu den vier Dispatch-Positionen geleitet werden.
Vorteilhafterweise verwendet die Abtastlogikarchitektur 690 eine Look-ahead- Logik zwecks Realisierung einer Hochgeschwindigkeitsabtastung. Jede der vier Stufen 600, 610, 620 und 630 umfasst vier Bitverarbeitungslogikgruppen zur Vereinfachung des Look-ahead, obwohl eine kleinere oder größere Anzahl von Gruppen möglich ist, falls gewünscht. So weist z. B. die Stufe 600 für die Dispatch-Position 0 eine erste Gruppe GP(0,0) und eine mit den Gruppen GP(1,0), GP(2,0) und GP(3,0) verbundene Look-ahead-Signalerzeugungslogik LAG(0) sowie eine Teil-Dispatch-Signalerzeugungslogik PDG(0) und eine Erstopode-Identifikations-Signalerzeugungslogik FOG(0) auf; weist die Stufe 610 für die Dispatch-Position 1 eine erste Gruppe GP(0,1) und eine mit den Gruppen GP(1, 1), GP(2,1) und GP(3,1) verbundene Look-ahead-Signalerzeugungslogik LAG(1) sowie eine Erst-opcode-Identifikations-Signalerzeugungslogik FOG(1) auf; weist die Stufe 620 für die Dispatch-Position 2 eine erste Gruppe GP(0,2) und eine mit den Gruppen GP(1, 2), GP(2, 2) und GP(3,2) verbundene Look-ahead-Signalerzeugungslogik LAG(2) sowie eine Erst-opcode-Identifikations-Signalerzeugungslogik FOG(2) auf; und weist die Stufe 630 für die Dispatch-Position 3 eine erste Gruppe GP(0,3) und eine mit den Gruppen GP(1,3), GP(2, 3) und GP(3, 3) verbundene Look-ahead-Signalerzeugungslogik LAG(3) sowie eine Erst-opcode-Identifikations-Signalerzeugungslogik FOG(3) auf.
Die Ausgangssignale jeder Gruppe werden an drei verschiedene Bestimmungsorte geliefert. Man nehme z. B. die Ausgangssignale der Gruppe(0,0). Ein erster Satz Ausgangssignale 602 gehört zu der ROP-Nummer der ROP, der die nächste Dispatch-Position zugewiesen wird, und wird an eine ROP-Nummer-Signalerzeugungslogik RNG(0) geliefert; siehe z. B. XDISPO[x] und XDSP0[x+16] in Fig. 7B. RNG(0) empfängt Eingangssignale von sämtlichen Gruppen GP(0,0), GP(0,1), GP(0,2) und GP(0,3) in der ersten Stufe 600 und erzeugt die ROP-Nummer-Signale ROP0DIFF[1 : 0], ROP1NUM[1 : 0] und PGNXT[0]. Ein zweiter Satz Ausgangssignale 604 dient der Identifikation von opcode-Plätzen für Befehle, denen die Dispatch-Positionen noch nicht vollständig zugewiesen worden sind, und wird an FOG(1) und LAG(1) in der zweiten Stufe 610 geliefert; siehe z. B. XN1[x] in Fig. 7B. FOG(1) und LAG(1) empfangen Eingangssignale von sämtlichen Gruppen GP(0,0), GP(0,1), GP(0,2) und GP(0,3) in der ersten Stufe 600 und erzeugen erste opcode- Identifikationssignale bzw. Look-ahead-Signale für die Gruppen der zweiten Stufe 610. Ein dritter Satz Ausgangssignale 606 gehört zu der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und der Nummer von ROPs, auf die der zugeordnete x86-Befehl übertragen wird, und wird zu der Gruppe (0,1) in der zweiten Stufe 610 geliefert; siehe z. B. DIN1[x], NBQP1[x], NBQP0[x] (es sei darauf hingewiesen, dass das Signal XN1[x] ebenfalls Teil dieses dritten Satzes ist).
Die zu der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und der Nummer der ROPs, auf die der zugeordnete x86-Befehl übertragen wird, gehörenden Signale breiten sich in den Stufen 600, 610, 620 und 630 aus und werden, wie nachstehend in Tabelle 3 gezeigt, verarbeitet, wobei: sowohl der Befehl am Anfang der Warteschlange als auch der unmittelbar darauf folgende Befehl auf drei ROPs übertragen werden, sämtliche folgende ROPs auf eine ROP übertragen werden und die ROP-Sequenz, auf die der ursprünglich am Anfang der Warteschlange befindliche Befehl übertragen wird, nicht teilweise weitergeleitet worden ist. TABELLE 3
Im ersten Dispatch-Fenster ist PARTIALDISP[1 : 0] 00. In der ersten Stufe werden, da der erste Byte-Warteschlangenplatz 0 einen opcode enthält, die Daten bezüglich der "Nummer der ROPs" der Position 0 des "Nummer der ROPs"-Arrays entnommen und mit der von PARTIALDISP[1 : 0] abgeleiteten ROP-Nummer verglichen. Es ist keine Übereinstimmung feststellbar, und die ROP-Nummer wird um Eins inkrementiert und zusammen mit einem unveränderten "opcode-Platz"-Array an die zweite Stufe geliefert. In der zweiten Stufe werden die Daten bezüglich der "Nummer der ROPs" von der Position 0 des "Nummer der ROPs"-Arrays entnommen und mit der von der ersten Stufe gelieferten ROP-Nummer verglichen. Es ist keine Übereinstimmung feststellbar, und die ROP-Nummer wird um Eins inkrementiert und zusammen mit einem unveränderten "opcode-Platz"-Array an die dritte Stufe geliefert. In der dritten Stufe werden Daten bezüglich der "Nummer der ROPs" von der Position 0 des "Nummer der ROPs"-Arrays entnommen und mit der von der zweiten Stufe gelieferten ROP-Nummer verglichen. Es ist eine Übereinstimmung feststellbar, und die ROP-Nummer wird auf 00 zurück gesetzt und an die vierte Stufe geliefert. Das "opcode-Platz"-Array wird durch Ausblenden des den opcode, für den die Dispatch-Positionen vollständig zugewiesen worden sind, identifizierenden Bits modifiziert und an die vierte Stufe geliefert. In der vierten Stufe werden Daten bezüglich der "Nummer der ROPs" von der Position 3 des "Nummer der ROPs"-Arrays entnommen und mit der von der dritten Stufe gelieferten ROP-Nummer verglichen. Es ist keine Übereinstimmung feststellbar, und PARTIALDISP[1 : 0] wird auf 01 gesetzt, wodurch angezeigt wird, dass eine der drei von dem als nächstes am Anfang der Warteschlange anstehenden Befehl übertragenen ROPs weitergeleitet worden ist.
Zur Erzeugung des nächsten Dispatch-Fensters wird der zweite Befehl an den Anfang der Warteschlange verschoben. PARTIALDISP[1 : 0] ist jetzt 01. In der ersten Stufe werden, da der ersten Byte-Warteschlangenplatz 0 wieder einen opcode enthält, die Daten bezüglich der "Nummer der ROPs" der Position 0 des "Nummer der ROPs"-Arrays entnommen und mit der von PARTIALDISP [1 : 0] abgeleiteten ROP-Nummer verglichen. Es ist keine Übereinstimmung feststellbar, und die ROP-Nummer wird um Eins inkrementiert und zusammen mit einem unveränderten "opcode-Platz"-Array an die zweite Stufe geliefert. In der zweiten Stufe werden die Daten bezüglich der "Nummer der ROPs" der Position 0 des "Nummer der ROPs"-Arrays entnommen und mit der von der ersten Stufe gelieferten ROP-Nummer verglichen. Es ist eine Übereinstimmung feststellbar, und die ROP-Nummer wird auf 00 zurück gesetzt und an die dritte Stufe geliefert. Das "opcode-Platz"-Array wird durch Ausblenden des den opcode, für den die Dispatch-Positionen vollständig zugewiesen worden sind, identifizierenden Bits modifiziert und an die dritte Stufe geliefert. In der dritten Stufe werden die Daten bezüglich der "Nummer der ROPs" der Position 7 des "Nummer der ROPs"-Arrays entnommen und mit der von der zweiten Stufe gelieferten ROP-Nummer verglichen. Es ist eine Übereinstimmung feststellbar, und die ROP-Nummer wird auf 00 zurück gesetzt und an die vierte Stufe geliefert. Das "opcode-Platz"-Array wird durch Ausblenden des den opcode, für den die Dispatch-Positionen vollständig zugewiesen worden sind, identifizierenden Bits modifiziert und an die vierte Stufe geliefert. In der vierten Stufe werden die Daten bezüglich der "Nummer der ROPs" der Position 10 des "Nummer der ROPs"-Arrays entnommen und mit der von der dritten Stufe gelieferten ROP-Nummer verglichen. Es ist eine Übereinstimmung feststellbar, und PARTIALDISP[1 : 0] wird auf 00 gesetzt, wodurch angezeigt wird, dass keine der von dem als nächstes am Anfang der Warteschlange anstehenden Befehl übertragenen ROPs weitergeleitet worden ist.
Fig. 7A-7D zeigen eine genauere Darstellung einiger Elemente der Abtastlogikarchitektur 690, die für entsprechende Elemente in anderen Dispatch-Positionen repräsentativ, jedoch nicht mit diesen identisch sind; es sei darauf hingewiesen, dass einige der in Fig. 7 gezeigten Elemente aus Gründen der Klarheit in Fig. 6 nicht dargestellt sind. So zeigt Fig. 7A z. B. FOG(0), die FOG(1), FOG(2) und FOG(3) entspricht, und LAG(0}, die LAG(1), LAG(2) und LAG(3) entspricht; Fig. 7A zeigt auch PDG(0). Fig. 7B zeigt ein Detail von GP(0,0) mit Darstellung von vier Bitverarbeitungslogikschaltungen F7(0,0), F7(1,0), F7(2,0) und F7(3,0), die ähnlichen Bitverarbeitungslogikschaltungen in den Gruppen GP(0,1), GP(0,2) und GP(0,3) entsprechen. Fig. 7B zeigt ferner ROP- Nummer-Signalerzeugungsschaltungen F8(0,0), F9(0,0) und F10(0,0). Fig. 7C zeigt ein Detail von GP(1,0) mit Darstellung von vier Bitverarbeitungslogikschaltungen F11(4,0), F11(5,0), F11(6,0) und F11(7,0), die ähnlichen Bitverarbeitungslogikschaltungen in den Gruppen GP(1, 1), GP(1, 2), GP(1,3), GP(2,O), GP(2,1), GP(2, 2), GP(2, 3), GP(3,0}, GP(3,1), GP(3,2) und GP(3, 3) entsprechen. Fig. 7C zeigt ferner ROP-Informationserzeugungsschaltungen F12(1,0) und F13(1,0). Fig. 7D zeigt die vier Bitverarbeitungslogikschaltungen F14(4,1), F14(5,1), F14(6,1) und F14(7,1) in der Gruppe GP(1, 1). Fig. 7D zeigt ferner ROP-Informationserzeugungsschaltungen F15(1, 1) und F16(1, 1). In der in Fig. 7 dargestellten Architektur wird die Abtastfunktion für jede Dispatch-Position durch Zusammenfassung zahlreicher Teilschaltungen in Gruppen von vier Bits beschleunigt; wobei die Look-ahead-Teilschaltungen Eingangssignale an Gruppen höherer Ordnung für diese Dispatch-Position übermitteln.
Die Operation der Abtastlogikarchitektur 690 für die Dispatch-Position 0 erfolgt bei der in Fig. 7A, 7B, 7C und 7D dargestellten Ausführungsform wie nachstehend beschrieben. Siehe Fig. 7A. PDG(0) weist Elemente F1 und F2 auf, die die binäre Größe PDISP1, PDISPO erzeugen, die für den vordekodierten x86-Befehl am Anfang der Warteschlange die Nummer der als nächstes zum Dispatch anstehenden ROP anzeigt. Bei den Ausführungsformen der in Fig. 8 und 9 dargestellten Elemente F1 und F2 wird die Größe PDISP1, PDISPO über Inverter direkt von PARTIALDISP[1 : 0] erhalten. Die Größe PDISP1, PDISPO wird an jede der vier Gruppen GP(0,0), GP(1,0), GP(2,0) und GP(3,0) in der ersten Stufe geliefert. Für jede Gruppe von vier Bits aus dem BYTEQP2-Array identifiziert FOG(0) das zuerst aktivierte Bit der Gruppe. FOG(0) weist Elemente F3 und F4 auf, deren Ausführungsformen in Fig. 10, 11 bzw. 12 dargestellt sind. Die jeweiligen Anzeigen werden an jede der vier Gruppen GP(0,0), GP(1,0), GP(2,0) und GP(3,0) in Stufe 0 geliefert. Für jede Gruppe von vier Bits, mit Ausnahme der ersten Gruppe aus dem BYTEQP2-Array, zeigt LAG(0) an, ob das zuerst aktivierte Bit in einer der der Gruppe vorangehenden Gruppen erscheint. LAG(0) weist Elemente F5 und F6 auf, deren Ausführungsformen in Fig. 13 bzw. 14 dargestellt sind. Das Element F6 empfängt ein Signal ASKMROM[0] von einer weiteren Schaltung im ROPMUX 400, wie der Byte-Warteschlangen-SE-Abtastlogik 5200 (Fig. 52). ASKMROM[0] zeigt an, dass sich ein Speicher-ROM-Befehl am Anfang der Warteschlange befindet. Die jeweiligen Anzeigen, aus denen hervorgeht, ob das zuerst aktivierte Bit in einer der einer Gruppe vorangehenden Gruppen erscheint, werden an jede der drei Gruppen GP(1,0), GP(2,0) und GP(3,0) in Stufe 0 geliefert.
Fig. 7B zeigt die Bitverarbeitungslogikschaltungen F7(0,0), F7(1,0), F7(2,0) und F7(3,0) für die Gruppe GP(0,0). Zusätzlich zu dem Ausgang ISEL0[x] weist das Element F7 einen Ausgang XN1[x] auf; das Signal BYTEQP2[x] durchläuft entweder das Element F7 in invertierter Form oder wird maskiert. Das Element F7 erzeugt ferner einen Vorgabewert, wie 00, für die Größe DIN1, DON1, es sei denn, dass sein XSEL0[x]-Ausgang aktiviert wird zwecks Anzeige, dass BYTEQP2[x] das zuerst aktivierte Bit in der Bitgruppe ist. In diesem Fall kann eine von zwei Bedingungen eintreten: (a) die ROP, der eine Dispatch-Position zugewiesen wird, ist nicht die letzte ROP in der Sequenz; oder (b) die ROP, der eine Dispatch-Position zugewiesen wird, ist die letzte ROP in der Sequenz. Im Fall (a) aktiviert das Element F7 seinen ISEL0[x]-Ausgang, inkrementiert die Größe PDISP1[x], PDISPO[x] um Eins und liefert das Resultat als DIN1, DON1 an die nächste Stufe und durchläuft das Bit BYTEQP2[x] in invertierter Form. Im Fall (b) aktiviert das Element F7 seinen ISEL0[x]-Ausgang, setzt die Größe PDISP1[x], PDISPO[x] auf Null zurück und liefert das Resultat als Größe DIN1, DON1 an die nächste Stufe und maskiert das Bit BYTEQP2[x] am Ausgang XN1[x].
Die Signale DIN1 und DON1 werden invertiert und als Signale XDSP0[x] und XDSP0[x+16] an die Element F8 bzw. F9 geliefert. In kombinierter Form erzeugen die Elemente F8 und F9 Signale PIFF0[0] und P0FF0[0], die den um Eins inkrementierten Wert PARTIALDISP[1,0] repräsentieren, wenn ein zuerst aktiviertes Bit des Arrays BYTEQP2in der Gruppe GP(0,0) auftritt und die ROP in der Dispatch-Position nicht die letzte ROP in der ROP-Sequenz ist. Andernfalls haben die Signale PIFF0[0] und P0FF0[0] einen Vorgabewert.
Signale PIFF0 und P0FF0 von sämtlichen Gruppen in Stufe 0 sind im Element F10 zusammengefasst. Diese Signale haben alle einen Vorgabewert, außer in dem Fall, in dem ein zuerst aktiviertes Bit des Arrays BYTEQP2 in Stufe 0 auftritt. In diesem Fall repräsentiert ein aus den Signalen PIFF0 und P0FF0 gebildetes Paar den Wert PARTIALDISP[1,0] in modifizierter Form, und dieser Wert wird zum Ableiten der Größen ROP0DIFF[1 : 0] und ROP1NUM[1 : 0] und des Signals PGNXT[0] verwendet.
Fig. 7C zeigt die Bitverarbeitungslogikschaltungen F11(4,0), F11(5,0), F11(6,0) und FI1(7,0) für die Gruppe GP(1,0). Das Element Fll ist ähnlich ausgeführt wie das Element F7, mit Ausnahme der Wirkung seines Ausgangs SEL0[x], das dem XSEL0[x]-Eingang des Elements F7 entspricht. SEL0[x] wird aktiviert, so dass angezeigt wird, dass BYTEQP2[x] das zuerst aktivierte Bit in der Bitgruppe ist. Ein Eingang PO[x] blockiert jedoch SEL0[x], es sei denn, PO[x] wird aktiviert, so dass angezeigt wird, dass ein zuerst aktiviertes Bit des Arrays BYTEQP2 in der vorhergehenden Bitgruppe der Stufe 0 nicht vorhanden ist.
Die Signale DIN1 und DON1 werden invertiert und als Signale XDSP[x] und XDSP0[x+16] an die Element F12 bzw. F13 geliefert. In kombinierter Form erzeugen die Elemente F12 und F13 die Signale PIFF0[0] und P0FF0[0], die den um Eins inkrementierten Wert PARTIALDISP[1,0] repräsentieren, wenn ein zuerst aktiviertes Bit des Arrays BYTEQP2 in der Gruppe GP(1,0) auftritt und die ROP in der Dispatch-Position nicht die letzte ROP in der ROP-Sequenz ist. Andernfalls haben die Signale PIFF0[0] und P0FF0[0] einen Vorgabewert. Die Signale PIFF0 und P0FF0 von den Elementen F12 und F13 werden zum Element F10 geleitet.
Fig. 7D zeigt die Bitverarbeitungslogikschaltungen FI4(4,1), FI4(5,1), F14(6,1) und F14(7,1) für die Gruppe GP(1, 1). Das Element F14 ist im wesentlichen identisch mit dem Element F11, obwohl die Eingangs- und Ausgangssignalnamen unterschiedlich sind.
Signale DIN2 und DON2 werden invertiert und als Signale XDSP1[x] und XDSP1[x+16] an die Elemente F15 bzw. F16 geliefert. Die Elemente F15 und F16 sind im wesentlichen identisch mit den Elementen F12 und F13, obwohl die Eingangs- und Ausgangssignalnamen unterschiedlich sind.
Ausführungsformen der Elemente in der Abtastlogikarchitektur 690 sind in Fig. 8-51 dargestellt. Bei einigen der in Fig. 8-51 gezeigten Gatter ist ein Eingang mit einem Punkt markiert, wodurch angezeigt wird, dass dieser Eingang mit einem schnellen Transistor verbunden sein sollte. Bei den anderen der in Fig. 8-51 dargestellten Gatter ist ein Eingang mit "CK" markiert, wodurch angezeigt wird, dass zum Implementieren der Logikfunktion Durchgangsgatter verwendet werden. Die Stufe 0 für die erste Dispatch-Position ist in Fig. 8-21 dargestellt, wobei die PDG in Fig. 8 (F1) und 9 (F2) gezeigt ist; die FOG(0) in Fig. 10 (F3), 11 (F4A) und 12 (F4B) gezeigt ist; die LAG(0) in Fig. 13 (F5) und 14 (F6) gezeigt ist; Gruppe GP(0,0) in Fig. 15 (F7), 16 (F8) und 17 (F9) gezeigt ist; Gruppen GP(1,0), GP(2,0) und GP(3,0) in Fig. 19 (F11), 20 (F12) und 21 (F13) gezeigt ist; und die ROP-Nummer-Signalerzeugungslogik RNG(0) der Stufe 0 in Fig. 18 (F10) gezeigt ist. Die Stufe 1 für die zweite Dispatch-Position ist in Fig. 22-31 dargestellt, wobei die FOG(1) in Fig. 22 und 23 gezeigt ist; die LAG(1) in Fig. 24 gezeigt ist; die Gruppe GP(0,1) in Fig. 25, 26 und 27 gezeigt ist; die Gruppen GP(1, 1), GP(2,1) und GP(3,1) in Fig. 29, 30 und 31 gezeigt sind; und die ROP-Nummer-Signalerzeugungslogik RNG(1) der Stufe 1 in Fig. 28 gezeigt ist. Die Stufe 2 für die dritte Dispatch-Position ist in Fig. 32-41 dargestellt, wobei die FOG(2) in Fig. 32 und 33 gezeigt ist; die LAG(2) in Fig. 34 gezeigt ist; die Gruppe GP(0,2) in Fig. 35, 36 und 37 gezeigt ist; die Gruppen GP(1, 2), GP(2, 2) und GP(3,2) in Fig. 39, 40 und 41 gezeigt sind; und die ROP-Nummer-Signalerzeugungslogik RNG(2) der Stufe 2 in Fig. 38 gezeigt ist. Die Stufe 3 für die vierte Dispatch-Position ist in Fig. 42-51 dargestellt, wobei die FOG(3) in Fig. 42 und 43 gezeigt ist; die LAG(3) in Fig. 44 gezeigt ist; die Gruppe GP(0,3) in Fig. 45, 46 und 47 gezeigt ist; die Gruppen GP(1,3), GP(2, 3) und GP(3, 3) in Fig. 49, 50 und 51 gezeigt sind; und die ROP-Nummer-Signalerzeugungslogik RNG(3) der Stufe 3 in Fig. 48 gezeigt ist.
Viele der in Fig. 8-51 dargestellten Gatterebenenschaltungen weisen Gatterstrukturen auf, die denen anderer Schaltungen in den Gruppen GP(0,0), GP(1,0) und GP(1, 1) ähnlich oder vereinfachte Varianten dieser Schaltungen sind. Entsprechend konzentriert sich die folgende Beschreibung der Schaltungsoperation um der Kürze des Textes willen auf Schaltungen in den Gruppen GP(0,0), GP(1,0) und GP(1, 1). Die Operation der anderen in Fig. 8-51 dargestellten Schaltungen wird anhand der Figuren und der folgenden Beschreibung ersichtlich.
Eine Ausführungsform einer Logikschaltung für das Element F1 ist in Fig. 8 dargestellt. Das Signal PARTIALDISP[1] wird zur Erzeugung von PDISP1[0] von Invertern 802 und 804 gepuffert, zur Erzeugung von PDISP1[1] von Invertern 802 und 806 gepuffert, zur Erzeugung von PDISP1[2] von Invertern 802 und 808 gepuffert, zur Erzeugung von PDISP1[3] von Invertern 802 und 810 gepuffert und zur Erzeugung von ROP0NUM[1] von Invertern 802 und 812 gepuffert.
Eine Ausführungsform einer Logikschaltung für das Element F2 ist in Fig. 9 dargestellt. Das Signal PARTIALDISP[0] wird zur Erzeugung von PDISPO[0] von Invertern 902 und 904 gepuffert, zur Erzeugung von PDISPO[1] von Invertern 902 und 906 gepuffert, zur Erzeugung von PDISPO[2] von Invertern 902 und 908 gepuffert, zur Erzeugung von PDISPO[3] von Invertern 902 und 910 gepuffert und zur Erzeugung von ROP0NUM[0] von Invertern 902 und 912 gepuffert.
Eine Ausführungsform einer Logikschaltung für das Element F3 ist in Fig. 10 dargestellt. Array BYTEQP2[15 : 0] wird zur Erzeugung von Array XIN[15 : 0] von einem Satz aus sechzehn Invertern bitweise invertiert.
Eine Ausführungsform einer Logikschaltung für das Element F4 ist in Fig. 11 und 12 dargestellt. Wie in Fig. 11 gezeigt, wird Bit XIN[0] zur Erzeugung von Signal XSEL0[0] von der Gattergruppe 1102 gepuffert, die zwei in Serie geschaltete Inverter aufweist. XSEL0[0] ist im wesentlichen eine invertierte Version von BYTEQP2[0]. Bits XIN[1 : 0] werden zur Erzeugung des Signals XSEL0[1] an Gattergruppe 1104 angelegt, die ein NAND-Gatter aufweist, das XIN[1] über einen Inverter und XIN[0] direkt empfängt. Das Signal XSEL0[1] ist im wesentlichen eine invertierte Version von BYTEQP2[1], vorausgesetzt, dass XIN[0] nicht aktiviert ist (logische 1) und andernfalls eine logische 1 ist. Bits XIN[2 : 0] werden zur Erzeugung des Signals XSEL0[2] an Gattergruppe 1106 angelegt, die ein NAND-Gatter aufweist, das XIN[2]über einen Inverter und XIN[1 : 0] direkt empfängt. Das Signal XSEL0[2] ist im wesentlichen eine invertierte Version von BYTEQP2[2], vorausgesetzt, dass XIN[1] und XIN[0] nicht aktiviert sind (logische 1) und andernfalls eine logische 1 ist. Bits XIN[3 : 0] werden zur Erzeugung des Signals XSEL0[3] an Gattergruppe 1108 angelegt, die ein NAND-Gatter aufweist, das XIN[3] über einen Inverter und XIN[2 : 0] direkt empfängt. Das Signal XSEL0[3] ist im wesentlichen eine invertierte Version von BYTEQP2[3], vorausgesetzt, dass XIN[2], XIN[1] und XIN[0] nicht aktiviert sind (logische 1), und andernfalls eine logische 1 ist.
Fig. 12 zeigt die Funktion F4 für Bitgruppen XIN[7 : 4], XIN[11 : 8] und XIN[15 : 12]. Die Funktion F4 sei z. B. an die Bitgruppe XIN[7 : 4] angelegt. Bit XIN[4] wird zur Erzeugung des Signals SEL0[4] von Gattergruppe 1202 gepuffert, die einen einzelnen Inverter aufweist. SEL0[4] ist im wesentlichen BYTEQP2[4]. Bits XIN[5 : 4] werden an Gattergruppe 1204 angelegt, die ein NAND-Gatter aufweist, das XIN[5] über einen Inverter und XIN[4] direkt empfängt, gefolgt von einem Inverter zur Erzeugung des Signals SEL0[5]. Das Signal SEL0[5] ist im wesentlichen BYTEQP2[5], vorausgesetzt, dass XIN[4] nicht aktiviert ist (logische 1), und andernfalls eine logische 0 ist. Bits XIN[6 : 4] werden zur Erzeugung des Signals SEL0[6] an Gattergruppe 1206 angelegt, die ein NAND-Gatter aufweist, das XIN[6] über einen Inverter und XIN[5 : 4] direkt empfängt. Das Signal XSEL0[6] ist im wesentlichen eine invertierte Version von BYTEQP2[6], vorausgesetzt, dass XIN[5] und XIN[4] nicht aktiviert sind (logische 1), und andernfalls eine logische 0 ist. Bits XIN[7 : 4] werden zur Erzeugung des Signals SEL0[7] an Gattergruppe 1208 angelegt, die ein NAND-Gatter aufweist, das XIN[7] über einen Inverter und XIN[6 : 4] direkt empfängt. Das Signal SEL0[7] ist im wesentlichen eine invertierte Version von BYTEQP2[7], vorausgesetzt, dass XIN[6], XIN[S] und XIN[4] nicht aktiviert sind (logische 1), und andernfalls eine logische 0 ist.
Eine Ausführungsform einer logischen Schaltung für das Element F5 ist in Fig. 13 dargestellt. Bits BYTEQP2[3 : 0] werden von einem NOR-Gatter 1302, dem ein Inverter 1303 folgt, durch logisches OR verknüpft, Bits BYTEQP2[7 : 4] werden von einem NOR-Gatter 1304, dem ein Inverter 1305 folgt, durch logisches OR verknüpft, Bits BYTEQP2[11 : 8] werden von einem NOR-Gatter 1306, dem ein Inverter 1307 folgt, durch ein logisches OR verknüpft und Bits BYTEQP2[15 : 12] werden von einem NOR-Gatter 1308, dem ein Inverter 1309 folgt, durch ein logisches OR verknüpft.
Eine Ausführungsform einer logischen Schaltung für das Element F6 ist in Fig. 14 dargestellt. Das Look-ahead-Signal PO[1] für die Gruppe GP[1,0] ist das in Gattergruppe 1402 invertierte Signal BQP20R[0]. Das Look-ahead-Signal PO[2] für die Gruppe GP(2,Q) ist das NOR (BQP20R[1], BQP20R[0]) in Gattergruppe 1404. Das Look-ahead-Signal PO[3] für die Gruppe GP(3,0) ist das NOR (BQP20R[2], BQP20R[1], BQP20R[0)) in Gattergruppe 1406. Das Lookahead-Signal PO[4] ist das INV(NAND((INV(BQP20R[3]), PO[3])) in Gattergruppe 1408. FASTVAL[0] ist das von zwei Invertern in Gattergruppe 1410 gepufferte NOR(ASKMROM[0], PO[4]).
Ausführungsformen der logischen Schaltungen für die Elemente F7 und F11 sind in Fig. 15 bzw. 19 dargestellt. ISEL0[I] in F7 ist direkt von XSEL0[I] über Inverter 1506 abgeleitet, und ISEL0[4*J+I] in F11 ist von SEL0[4*J+I] und PO[J] über NAND-Gatter 1904 und Inverter 1906 abgeleitet. Die Position des ersten Auftretens eines aktivierten opcode-Bits in der BYTEQ 106 wird durch die Position der logischen 1 im ISEL0-Array angezeigt. Das Signal XSEL0[I] in F7 und das Ausgangssignal des NAND-Gatters 1904 in F11 werden ebenfalls jeweils an Gattergruppen 1502 und 1902, Gattergruppen 1512 und 1912 und Gattergruppen 1518 und 1918 angelegt.
Wenn das Signal XSEL0[I] in F7 und das Ausgangssignal des NAND-Gatters 1904 in F11 an die OR-NAND-Gatter 1502 bzw. 1902 angelegt sind, werden diese Signale zum Maskieren des Arrays BYTEQP2 zwecks Eliminierung des ersten Auftretens eines aktivierten opcode-Bits von der Bitposition x verwendet, vorausgesetzt, dass BYTEQP1[x], BYTEQPO[x] gleich PDISP1[x], PDISPO[x] ist. Diese Bedingung, mit der festgestellt wird, dass eine Dispatch-Position der letzten ROP in der Sequenz zugewiesen ist, wird von Gattergruppen 1500 und 1900 detektiert. Das maskierte Array wird der nächsten Stufe 610 als opcode- Platz-Array XN1 präsentiert.
Wenn das Signal XSEL[I] in F7 und das Ausgangssignal des NAND-Gatters 1904 in F11 an die Gattergruppen 1512 bzw. 1912 angelegt sind, werden diese Signale zur Aktivierung der Ausgänge von Gattergruppen 1508 und 1908 verwendet, von denen das Signal DON1 abgeleitet und zur nächsten Stufe geliefert wird. Wenn das Signal XSEL0[I] in F7 und das Ausgangssignal des NAND-Gatters 1904 in F11 an die Gattergruppen 1518 bzw. 1918 angelegt sind, werden diese Signale zur Aktivierung der Ausgänge von Gattergruppen 1516 und 1916 verwendet, von denen das Signal DIN1 abgeleitet und an die nächste Stufe geliefert wird. Die Gattergruppen 1508 und 1516 von F7 und die Gattergruppen 1908 und 1916 von F11 inkrementieren PDISP1[x], PDISPO[x] um Eins, es sei denn, dass BYTEQP1[x], BYTEQPO[x] und PDISP1[x], PDISPO[x] gleich sind. In diesem Fall wird DIN1[x], DON1[x] zwangsweise auf 00 gesetzt.
Die Elemente FT und F11 verlaufen als XN1 entlang des Arrays BYTEQP2, mit Ausnahme eines maskierten Bits, und verlaufen als NBQP1 bzw. NBQP0 entlang der Arrays BYTEQP1 und BYTEQPO.
Die Elemente F8, F9, F10, F12 und F13, die jeweils in Fig. 16, 17, 18, 20 bzw. 21 dargestellt, sind; erhalten die ROP-Nummer-Signale ROP0DIFF[1 : 0] und PGNXT[0] für Stufe 0 und das ROP-Nummer-Signal ROP1NUM[1 : 0] für Stufe 1. Bei den Elementen F8, F9, F12 und F13 handelt es sich um 4-Bit- UND-Operationen unter Verwendung eines NAND-Gatters, dem ein Inverter folgt. Das Element F9 arbeitete auf Bits XDISP[3 : 0]. Das Element F9 arbeitet auf Bits XDIPS[1.9 : 16]. Das Element F20 arbeitet auf Elementen XDISP[7 : 4], XDISP[11 : 8] und XDISP[15 : 12]. Das Element F21 arbeitet auf Elementen XDISP[23 : 20], XIDISP[27 : 24] und XDISP[31 : 28]. Die Ausgänge PIFF0[3 : 0] und P0FF0[3 : 0] der Elemente F8, F9, F20 und F21 werden an das Element F10 angelegt. PIFF0[3 : 0] wird an NAND-Gatter 1802 angelegt, dessen Ausgangssignal zur Erzeugung von Bit ROP0DIFF[1] von Invertern 1804 und 1806 gepuffert wird und zur Erzeugung von Bit ROP1NUM[1] von Invertern 1804 und 1808 gepuffert wird. P0FF0[3 : 0] wird an NAND-Gatter 1814 angelegt, dessen Ausgangssignal zur Erzeugung von Bit ROP0DIFF[0] von Invertern 1816 und 1818 gepuffert wird und zur Erzeugung von Bit ROP1NUM[0] von Invertern 1816 und 1820 gepuffert wird. Die Ausgangssignale der NAND-Gatter 1802 und 1814 werden auch an NOR-Gatter 1810 angelegt, dessen Ausgangssignal von Inverter 1812 invertiert und als Signal PGNXT[0] geliefert wird.
Die Architektur 690 der schnellen Byte-Warteschlangen-Abtastlogik ist für andere schnelle Abtastanwendungen geeignet. Fig. 52 zeigt z. B. eine schnelle Byte-Warteschlangen-Abtasteinrichtung 5200, die für den Einsatz in der ROP- MUX 400 zum Verarbeiten der Start- und Endbit-Arrays BYTEQS und BYTEQE sowie der opcode- und rop-Nummer-Arrays BYTEQP2, BYTEQP1 und BYTEQPO geeignet ist. In der Byte-Warteschlangen-Abtasteinrichtung 5200 wird die Abtastlogik 690 mit einer zweiten Abtastlogik 5210, die zur Herstellung eines aus vier Elementen bestehenden Ausgangs-Arrays ESEL0[15 : 0], ESEL1[15 : 0], ESEL2[15 : 0] und ESEL3[15 : 0] die Start- und Endbit-Arrays BYTEQS und BYTEQE verarbeitet, kombiniert, wobei jedes Element für die ROP, der die entsprechende Dispatch-Position zugewiesen worden ist, den Platz des Endbits des x86-Befehls, von dem die ROP übertragen worden ist, identifiziert. Die Identifikation erfolgt durch erste Erzeugung eines Arbeits-Arrays aus vier Elementen, die jeweils den Platz des Endbits für die ersten vier Befehle in der BYTEQ 106 identifizieren. Eine Fehlerprüfung wird ebenfalls durchgeführt; z. B. erfolgt die Prüfung zur Sicherstellung, dass jedem Startbit (mit Ausnahme des ersten, das als das erste Bit im Array BYTEQS angesehen wird) ein Endbit unmittellbar voraus geht. Dann wird das Signal PGNXT[3 : 0], das, wie oben gesagt, von der Abtastlogik 690 stammt und anzeigt, ob die ROP in der Dispatch-Position "x" die letzte von dem entsprechenden x86-Befehl übertragene ROP in der ROP-Sequenz ist, als Multiplexersteuersignal zum Leiten des ersten Elements des Arbeitsarrays zu so vielen Elementen des Ausgangs-Arrays, wie dem Befehl am Anfang der Warteschlange zugewiesene Dispatch- Positionen vorhanden sind, zum Leiten des nächsten Elements des Arbeits-Arrays zu so vielen der verfügbaren Elemente des Ausgangs-Arrays, wie dem nächsten Befehl in der BYTEQ 106 zugewiesene Dispatch-Positionen vorhanden sind etc., verwendet.
Die Abtastlogik 5210 benutzt eine Gruppierungs- und Look-ahead-Technik ähnlich der in der in Fig. 6A und 6B dargestellten Architektur der zweiten, dritten und vierten Stufe angewandten Technik. Die erste Stufe braucht nicht auf diese Weise verarbeitet zu werden, da angenommen wird, dass sich ein Startbit in der Bitposition am Anfang der Warteschlange befindet. Für die zweite, dritte und vierte Stufe in der Abtasteinrichtung 5210 wird eine Logik, die der Erst-opcode-Identifikations-Signalerzeugungslogik FOG ähnlich ist, zum Identifizieren des zuerst auftretenden Endbits vom Array BYTEQE in jeder aus vier Bits bestehenden Gruppe verwendet. Eine Logik ähnlich der Look- ahead-Signalerzeugungslogik LAG dient der Bestimmung, ob eine vorhergehende Gruppe in der Stufe ein zuerst auftretendes Endbit enthält. Jede Stufe weist, wie in der Abtastlogik 690, vier Gruppen auf.
Das Vorhandensein eines Speicher-ROM-Befehls wird in der ersten Stufe durch Überwachen von BYTEQP1, BYTEQPO detektiert. Wenn ein Speicher- ROM-Befehl detektiert wird, wird ein Signal ASKMROM[0] aktiviert und an die Abtastlogik 690 angelegt.
Obwohl die Erfindung anhand verschiedener Ausführungsformen beschrieben worden ist, sei darauf hingewiesen, dass diese Ausführungsformen nur der Erläuterung dienen und der Umfang der Erfindung nicht auf diese beschränkt ist. Änderungen, Modifikationen, Hinzufügungen und Verbesserungen der beschriebenen Ausführungsformen sind möglich. Die Anzahl von Stufen und die Anzahl von Gruppen in jeder Stufe sind variabel. Ferner ist die Erfindung auf andere Abtast-Warteschlangen als die BYTEQ 106 anwendbar. Diese und andere Änderungen, Modifikationen, Hinzufügungen und Verbesserungen können in den Umfang der Erfindung, wie er in den folgenden Patentansprüchen definiert ist, fallen.

Claims

1. Vorrichtung zum Abtasten einer Befehlswarteschlange eines superskalaren Prozessors mit mehreren Dispatch-Positionen, wobei die Befehlswarteschlange vordekodierte Primärbefehle mit variabler Länge enthält, die auf Sekundärbefehle übertragen werden, und wobei die Primärbefehle an von jeweiligen Identifikationselementen identifizierten Plätzen Operationskodes enthalten,

dadurch gekennzeichnet, dass die Vorrichtung aufweist:

eine erste Stufe (600) für eine erste Dispatch-Position des superskalaren Prozessors, wobei die erste Stufe mehrere Maskierlogikgruppen (GP(x,y)) mit mit den Identifikationselementen gekoppelten Eingängen aufweist, einen Look-ahead-Generator (LAG(0)) zum Reduzieren von Ausbreitungsverzögerungen in der ersten Stufe aufweist, wobei der Look-ahead-Generator einen mit den Identifikationselementen gekoppelten Eingang und mit Maskierlogikgruppen höherer Ordnung der ersten Stufe gekoppelte Ausgänge und einen mit Ausgängen der Maskierlogikgruppen der ersten Stufe gekoppelten Bild-Befehlsinformationsgenerator (RNG(0)) aufweist; und

eine zweite Stufe (610) für eine zweite Dispatch-Position des superskalaren Prozessors, wobei die zweite Stufe mehrere Maskierlogikgruppen (GP(x,y)) mit mit Ausgängen entsprechender Maskierlogikgruppen der ersten Stufe gekoppelten Eingängen und einen Look-ahead-Generator (LAG(1)) zum Reduzieren von Ausbreitungsverzögerungen in der zweiten Stufe aufweist, wobei der Look-ahead-Generator mit Ausgängen der Maskierlogikgruppen der ersten Stufe gekoppelte Eingänge und mit den Maskierlodikgruppen höherer Ordnung der zweiten Stufe gekoppelte Ausgänge aufweist.

2. Vorrichtung nach Anspruch 1, bei der die zweite Stufe ferner einen mit Ausgängen der Maskierlogikgruppe der zweiten Stufe gekoppelten Bild- Befehlsinformationsgenerator (RNG(1)) aufweist und die Vorrichtung ferner eine dritte Stufe (620) für eine dritte Dispatch-Position des superskalaren Prozessors aufweist, wobei die dritte Stufe mehrere Maskierlogikgruppen mit mit Ausgängen der entsprechenden Bit-Maskierlogikgruppen der zweiten Stufe gekoppelte Eingänge und einen Look- ahead-Generator (LAG(3)) mit mit den Maskierlogikgruppen der zweiten Stufe gekoppelten Eingängen und mit Maskierlogikgruppen höherer Ordnung der dritten Gruppe gekoppelten Eingängen umfasst.

3. Vorrichtung nach Anspruch 1, bei dem die Befehle in der Befehlswarteschlange x86-Befehle und die abgebildeten Befehle RISC-Operationen ("ROPs") amd, wobei die abgebildeten Befehlsinformationen ein binäres Signal enthalten, das die Nummer der nächsten zum Dispatch anstehenden abgebildeten ROP anzeigt.

4. Vorrichtung nach Anspruch 3, die ferner ein Signal enthält, das anzeigt, ob die ROP in der Stufe die letzte ROP in einer von dem entsprechenden x86-Befehl abgebildeten ROP-Sequenz ist.

5. Vorrichtung nach Anspruch 1, bei der die Sekundärbefehle RISC- Operationen ("ROPs") sind und jeder Primärbefehl einen Operationskode und eine Operationskodekennung umfasst, die den Platz des Operationskodes in der Befehlswarteschlange identifiziert, wobei die Gruppe von Maskierschaltungen in jeder Stufe (609, 610) eine erste Gruppe von Operationskodekennungs-Maskierschaltungen (GP(0,0)) aufweist, von denen jede folgendes umfasst:

Eingänge zum Empfangen von Operationskodekennungen, die Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und die Nummer der ROPs, auf die die Primärbefehle übertragen werden; und

Ausgänge zum Weiterleiten von maskierten/unmaskierten Operationskodekennungen, eine inkrementierte Version der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und die Nummer von ROPs, auf die die Primärbefehle übertragen werden; und

eine zweite Gruppe von Operationskodekennungs-Maskier- und Blockierschaltungen (GP(1,0)), jeweils mit:

Eingängen zum Empfangen von Operationskodekennungen, der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und der Nlummer der ROPs, auf die die Primärbefehle übertragen werden, und ferner mit einem mit dem ersten Ausgang der Look-ahead- Signalerzeugungslogik verbundenen Eingang; und

Ausgängen zum Weiterleiten von maskierten/unmaskierten Operationskodekennungen, einer inkrementierten Version der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und der Nummer der ROPs, auf die die Primärbefehle übertragen werden.

6. Vorrichtung nach Anspruch 5, bei der die Look-ahead-Signalerzeugungslogik einen zweiten Ausgang aufweist, wobei die Vorrichtung ferner aufweist:

eine dritte Gruppe von Operationskodekennungs-Maskier- und Blockierschaltungen (GP(2,0), jeweils mit:

Eingängen zum Empfangen von Operationskodekennungen, der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und der Nummer der ROPs, auf die die Primärbefehle übertragen werden, und ferner mit einem mit dem zweiten Ausgang der Look-ahead- Signalerzeugungslogik verbundenen Eingang; und

Ausgängen zum Weiterleiten von maskierten/unmaskierten Operationskodekennungen, einer inkrementierten Version der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und der Nummer der ROPs, auf die der Primärbefehl übertragen wird.

7. Vorrichtung nach Anspruch 1, bei der jeder Befehl auf eine oder mehrere RISG-Operationen ("ROP") übertragen wird, wobei die Vorrichtung ferner aufweist:

eine Einrichtung zum Zuweisen der Dispatch-Positionen an die Befehle in Abhängigkeit von der Nummer der ROPs, auf die jeder Befehl übertragen wird, und der Nummer der zur Verfügung stehenden Dispatch- Position; und

mehrere Stufen, einschließlich der ersten und zweiten Stufen, die jeweils den Dispatch-Positionen entsprechen, zum Identifizieren der jeweiligen Dispatch-Positionen und zum Benachrichtigen der jeweiligen Dispatch-Positionen über die Plätze der Operationskodes in der Befehlswarteschlange bezüglich Befehlen, denen in der Zuweisungseinrichtung die Dispatch-Positionen zugewiesen worden sind;

wobei jede Stufe ein Eingangs-Array von Operationskodekennungen und ein Ausgangs-Array von Operationskodekennungen umfasst und folgendes aufweist:

eine Einrichtung zum Identifizieren eines Platzes des ersten Operationskodes im Eingangs-Array; und

eine Einrichtung zum Ausbreiten eines Arrays vom Eingangs-Array zum Ausgangs-Array, wobei bei dem Ausbreitungs-Array der in der Identifizierungseinrichtung identifizierte Platz maskiert ist, wenn die entsprechende Dispatch-Position der einem bestimmten Befehl zuletzt zugewiesenen Dispatch-Position entspricht;

wobei die Stufen seriell miteinander gekoppelt sind, wobei bei einer vorderen Stufe das Eingangs-Array mit den Operationskodekennungen in der Befehlswarteschlange gekoppelt ist und bei jeder anderen Stufe das Eingangs-Array mit dem Ausgangs-Array einer unmittelbar vorhergehenden Stufe gekoppelt ist.

8. Vorrichtung nach Anspruch 7, bei der die Zuweisungseinrichtung über die Stufen verteilt ist.

9. Vorrichtung nach Anspruch 7, bei der die Befehlswarteschlange mehrere komplette vordekodierte x86-Befehle enthält, einschließlich eines kompletten vordekodierten x86-Befehls am vorderen Ende der Warteschlange.

10. Vorrichtung nach Anspruch 7, bei der die ROPs, auf die jeder Befehl übertragen wird, eine geordnete Sequenz bilden und mit jeweiligen Nummern in der geordneten Sequenz versehen sind, wobei jede Stufe ferner aufweist:

ein der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, zugehöriges Ausgangs-Array; und

ein der Nummer der ROPs, auf die der zugeordnete x86-Befehl übertragen wird, zugehöriges Ausgangs-Array, wobei jede Stufe ferner aufweist:

eine mit dem Ausgangs-Array von Operationskodekennungen der unmittelbar vorhergehenden Stufe gekoppelte Einrichtung zum Erzeugen erster Operationskode-Identifikationssignale bzw. Look-ahead-Signale für die Gruppen der Stufe;

eine Einrichtung, die mit dem der Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, zugehörigen Ausgangs-Array der unmittelbar vorhergehenden Stufe und mit dem der Nummer der ROPs, auf die der zugeordnete x86-Befehl übertragen wird, zugehörigen Ausgangs-Array der unmittelbar vorhergehenden Stufe gekoppelt ist, zum Maskieren des Ausgangs-Arrays von Operationskodekennungen der unmittelbar vorhergehenden Stufe, wenn die Nummer der ROP, der zuletzt eine Dispatch-Position zugewiesen worden ist, und die Nummer der ROPs, auf die der zugeordnete x86-Befehl übertragen worden ist, gleich sind.

11. Vorrichtung nach Anspruch 10, bei der jede Stufe ferner ein drittes Ausgangs-Array aufweist, das die ROP-Nummer der ROP, der die nächste Dispatch-Position zuzuweisen ist, identifiziert.

12. Vorrichtung nach Anspruch 1, bei der jeder Befehl in der Befehlswarteschlange auf eine oder mehrere RISC-Operationen ("ROPs") übertragen wird und die erste Stufe ferner aufweist:

eine erste Operationskodekennungs-Signalerzeugungslogik mit einem mit Operationskodebits und Operationskodekennungsbits der Befehlswarteschlange gekoppelten Eingang;

eine Teil-Dispatch-Signalerzeugungslogik mit einem Ausgang zum Empfangen eines Teil-Dispatch-Signals;

den ersten Look-ahead-Signalgenerator mit einem mit den Operationskodebits und den Operationskodekennungsbits der Befehlswarteschlange gekoppelten Eingang;

eine erste Maskierlogikgruppe mit mit einem ersten Feldausgang der ersten ersten Operationskodekennungs-Signalerzeugungslogik und der Teil-Dispatch-Signalerzeugungslogik gekoppelten Eingängen und einem Ausgang zum Identifizieren eines Platzes des als erstes erscheinenden Operationskodekennungsbits im ersten Feld der Befehlswarteschlange;

eine zweite Maskierlogikgruppe mit mit einem zweiten Feldausgang der ersten ersten Operationskodekennungs-Signalerzeugungslogik, einem Ausgang der Teil-Dispatch-Signalerzeugungsiogik und einem Ausgang der ersten Look-ahead-Signalerzeugungslogik gekoppelten Eingängen und einem Ausgang zum Identifizieren eines Platzes des als erstes erscheinenden Operationskodekennungsbits im zweiten Feld der Befehlswarteschlange;

und wobei der die zweite Stufe ferner aufweist:

eine zweite erste Operationskode-Identifikationssignal-Erzeugungslogik mit einem mit einem Operationskodebitausgang und einem Operationskodekennungsbitausgang der ersten und zweiten Bit-Maskierlogikgruppen gekoppelten Eingang;

den zweiten Look-ahead-Signalgenerator mit einem mit den Operationskodebits und den Operationskodekennungsbits der Befehlswarteschlange gekoppelten Eingang;

eine erste Maskierlogikgruppe mit mit einem ersten Feldausgang der zweiten ersten Operationskodekennungs-Signalerzeugungslogik und einem Operationskodebitausgang und einem Operationskennungsbitausgang der ersten Maskierlogikgruppe der ersten Stufe gekoppelten Eingängen; und

einer zwei en Maskierlogikgruppe mit mit einem zweiten Feldausgang der zweiten ersten Operationskodekennungs-Signalerzeugungslogik und einem Operationskodebitausgang und einem Operationskodekennungsbitausgang der zweiten Maskierlogikgruppe der ersten Stufe gekoppelten Eingängen.

13. Verfahren zum Abtasten einer Warteschlange von Primärbefehlen in einem superskalaren Prozessor, wobei die Warteschlange von Primär> jefehlen ein oder mehrere Operationskode-Bytes an jeweiligen Plätzen in der Warteschlange aufweist, die jeweils durch aktivierte Bits in einem ersten Array identifiziert werden, wobei jeder Primärbefehl auf eine Sequenz aus einer oder mehreren Sekundärbefehlen übertragen wird und das Verfahren folgende Schritte umfasst:

Identifizieren erster und zweiter Teilsätze von Bits im ersten Array;

Erzeugen eines zweiten Arrays mit ersten und zweiten Bit-Teilsätzen für eine erste Dispatch-Position in dem superskalaren Prozessor, wobei die Bit-Teilsätze zuerst aktivierte Bits jeweils in den ersten und zweiten Bit- Teilsätzen des ersten Arrays anzeigen;

Erzeugen eines Look-ahead-Signals für die erste Dispatch-Position, wenn der erste Bit-Teilsatz im ersten Array kein aktiviertes Bit enthält;

Anlegen des Look-ahead-Signals für die erste Dispatch-Position an den zweiten Bit-Teilsatz des zweiten Arrays zum Erzeugen eines für die erste Dispatch-Position vorgesehenen dritten Bit-Arrays aus dem zweiten Array, wobei das dritte Bit-Array ein erstes aktiviertes Bit im ersten Array und keine sukzessiv aktivierten Bits im ersten Array anzeigt;

Ableiten eines vierten Arrays aus dem ersten Array; Identifizieren der ersten und zweiten Bit-Teilsätze im vierten Array;

Erzeugen eines fünften Arrays für eine zweite Dispatch-Position im superskalaren Prozessor, wobei das fünfte Array erste und zweite Bit- Teilsätze aufweist, die die zuerst aktivierten Bits jeweils in den ersten und zweiten Bit-Teilsätzen des vierten Arrays anzeigen;

Erzeugen eines Look-ahead-Signals für die zweite Dispatch-Position, wenn der erste Bit-Teilsatz im vierten Array kein aktiviertes Bit enthält;

Anlegen des Look-ahead-Signals für die zweite Dispatch-Position an den zweiten Bit-Teilsatz des fünften Arrays zum Erzeugen eines für die zweite Dispatch-Position vorgesehenen sechsten Bit-Arrays aus dem fünften Array, wobei das sechste Bit-Array ein erstes aktiviertes Bit im vierten Array und keine sukzessiv aktivierten Bits im vierten Array anzeigt.

14. Verfahren nach Anspruch 13, bei dem der Schritt des Ableitens eines vierten Arrays das Maskieren des ersten Arrays zum Blockieren des zuerst aktivierten Bits im ersten Array umfasst, wenn die erste Bit-Position einen letzten Sekundärbefehl in der Sequenz von Sekundärbefehlen enthält, und andernfalls das Ausbreiten des zuerst aktivierten Bits im ersten Array umfasst.

15. Verfahren nach Anspruch 14, ferner mit folgenden Schritten vor dem Ableiten eines vierten Arrays:

Erzeugen eines Teil-Dispatch-Werts für die erste Dispatch-Position, der die Sequenznummer des Sekundärbefehls in der ersten Dispatch-Position anzeigt; und

Vergleichen des Teil-Dispatch-Werts mit einem vollen Dispatch-Wert für die erste Dispatch-Position, wobei der volle Dispatch-Wert für die erste Dispatch-Position die Nummer der von dem Primärbefehl, von dem der Sekundärbefehl in der ersten Dispatch-Position übertragen worden ist, übertragenen Sekundärbefehle ist;

wobei der Ableitschritt für die erste Dispatch-Position ferner das Maskieren des ersten aktivierten Bits im ersten Array umfasst, wenn der Teil-Dispatch-Wert dem vollen Dispatch-Wert für die erste Dispatch-Position gleich ist, und andernfalls das Ausbreiten des zuerst aktivierten Bits im ersten Array umfasst.

16. Verfahren nach Anspruch 13, ferner mit folgenden Schritten:

Ableiten eines siebten Arrays vom vierten Array;

Identifizieren von ersten und zweiten Bit-Teilsätzen im siebten Array;

Erzeugen eines achten Arrays für eine dritte Dispatch-Position im superskalaren Prozessor, wobei das achte Array erste und zweite Bit- Teilsätze aufweist, die die zuerst aktivierten Bits jeweils in den ersten und zweiten Bit-Teilsätzen des siebten Arrays anzeigt;

Erzeugen eines Look-ahead-Signals für die dritte Dispatch-Position, wenn der erste Bit-Teilsatz im siebten Array kein aktiviertes Bit enthält;

Anlegen des Look-ahead-Signals für die dritte Dispatch-Position an den zweiten Bit-Teilsatz des achten Arrays zum Erzeugen eines für die dritte Position vorgesehenen neunten Bit-Arrays aus dem achten Array, wobei das neunte Bit-Array ein zuerst aktiviertes Bit im siebten Array und keine sukzessiv aktivierten Bits im sieben Array anzeigt.

17. Verfahren nach Anspruch 16, bei dem der Schritt des Ableitens eines siebten Arrays das Maskieren des vierten Arrays zum Blockieren des zuerst aktivierten Bits im vierten Array umfasst, wenn die zweite Dispatch-Position einen letzten Sekundärbefehl in der Sequenz von Sekundärbefehlen enthält, und andernfalls ein Ausbreiten des zuerst aktivierten Bits im vierten Array umfasst.

18. Verfahren nach Anspruch 17, ferner mit folgenden Schritten vor dem Schritt des Ableitens eines siebten Arrays:

Ableiten eines Dispatch-Werts für die zweite Dispatch-Position aus dem Teil-Dispatch-Wert, wobei der abgeleitete Dispatch-Wert eine inkrementierte Version des Teil-Dispatch-Werts ist, wenn die Sequenznummer des Sekundärbefehls in der zweiten Dispatch-Position niedriger ist als der volle Dispatch-Wert für die zweite Dispatch-Position, der volle Dispatch-Wert für die zweite Dispatch-Position die Nummer der von dem Primärbefehl, von dem der Sekundärbefehl in der zweiten Dispatch-Position übertragen worden ist, übertragenen Sekundärbefehle ist und andernfalls ein Standardwert ist; und

Vergleichen des abgeleiteten Dispatch-Werts mit dem vollen Dispatch- Wert für die zweite Dispatch-Position,

wobei der Ableitschritt für die zweite Dispatch-Position ferner das Maskieren des zuerst aktivierten Bits im vierten Array umfasst, wenn der abgeleitete Dispatch-Wert dem vollen Dispatch-Wert für die zweite Dispatch-Position gleich ist, und andernfalls das Ausbreiten des zuerst aktivierten Bits im vierten Array umfasst.

19. Verfahren nach Anspruch 13, bei dem:

der Schritt des Identifizierens der ersten und zweiten Bit-Teilsätze im ersten Array ferner das Identifizieren eines dritten Bit-Teilsatzes im ersten Array umfasst;

der Schritt des Erzeugens eines zweiten Arrays ferner das Aufnehmen eines dritten Bit-Teilsatzes in das zweite Array umfasst, wobei der dritte Bit-Teilsatz ein zuerst aktiviertes Bit im dritten Bit-Teilsatz des ersten Arrays anzeigt;

der Schritt des Erzeugens eines Look-ahead-Signals für die erste Dispatch-Position ferner das Erzeugen eines zusätzlichen Look-ahead- Signals für die erste Dispatch-Position umfasst, wenn weder der erste noch der zweite Bit-Teilsatz im ersten Array ein zuerst aktiviertes Bit enthält;

der Schritt des Anlegens eines Look-ahead-Signals für die erste Dispatch-Position ferner das Erzeugen des dritten Arrays durch Anlegen des zusätzlichen Look-ahead-Signals für die erste Dispatch-Position an den dritten Bit-Teilsatz im zweiten Array umfasst.

20. Verfahren nach Anspruch 13, bei dem die Primärbefehle vordekodierte x86-Befehle und die Sekundärbefehle RISC-Operationen sind.

21. Verfahren nach Anspruch 13, bei dem die Warteschlange von Primärbefehlen Einen oder mehrere Operationskodes an jeweiligen Plätzen in der Wartschlange enthält, die von einem ersten Satz Operationskodeplatzkennungen ("OLI") identifiziert werden, wobei das Verfahren folgende Schritte umfasst:

Identifizieren erster und zweiter Teilsätze im ersten Satz OLIs;

Erzeugen eines zweiten Satzes OLIs für die erste Dispatch-Position, mit ersten und zweiten Teilsätzen, in denen zuerst aktivierte OLIs identifiziert werden, wobei die ersten und zweiten Teilsätze des zweiten Satzes OLIs den ersten und zweiten Teilsätzen des ersten Satzes OLIs entsprechen; das Look-ahead-Signal für die erste Dispatch-Position erzeugt wird, wenn der erste Teilsatz des ersten Satzes OLIs keine aktivierten OLIs enthält; das Look-ahead-Signal zum Erzeugen eines für die erste Dispatch-Position vorgesehenen dritten Satzes OLIs aus dem zweiten Satz OLIs an den zweiten Teilsatz des zweiten Satzes OLIs angelegt wird, wobei der dritte Satz OLIs ein erstes aktiviertes OLI im ersten Satz und keine sukzessiv aktivierten OLIs im ersten Satz anzeigt;

Ableiten eines vierten Satzes OLIs aus dem ersten Satz;

Erzeugen eines fünften Satzes OLIs für die zweite Dispatch-Position, mit ersten und zweiten Teilsätzen, in denen zuerst aktivierte OLIs identifiziert werden, wobei die ersten und zweiten Teilsätze des fünften Satzes OLIs den ersten und zweiten Teilsätzen des vierten Satzes OLIs entsprechen; das Look-ahead-Signal erzeugt wird, wenn der erste Teilsatz des vierten Satzes OLIs keine aktivierten OLIs enthält; das Look-ahead- Signal zum Erzeugen eines für die zweite Dispatch-Position vorgesehenen sechsten Satzes OLIs aus dem fünften Satz OLIs an den zweiten Teilsatz des fünften Satzes OLIs angelegt wird, wobei der sechste Satz OLIs ein zuerst aktiviertes OLI im vierten Satz und keine sukzessiv aktivierten OLIs im vierten Satz anzeigt.

22. Verfahren nach Anspruch 21, bei dem der Schritt des Ableitens eines vierten Satzes OLIs das Blockieren des ersten aktivierten OLI im ersten Satz OLIs umfasst, wenn die erste Dispatch-Position einen letzten Sekundärbefehl in der Sequenz von Sekundärbefehlen enthält, und andernfalls das Ausbreiten des zuerst aktivierten OLI im ersten Satz OLIs umfasst.

23. Verfahren nach Anspruch 13, bei dem jeder Primärbefehl einen Operationskode und eine Operationskodekennung aufweist, die den Platz des Operationskodes in der Befehlswarteschlange identifiziert, und bei dem die Sekundärbefehle RISC-Operationen ("ROPs") sind, wobei das Verfahren ferner folgend Schritte umfasst:

Zuweisen der Dispatch-Positionen an die Befehle in Abhängigkeit von der Nummer von ROPs, auf die jeder Befehl übertragen wird, und der Nummer zur Verfügung stehender Dispatch-Positionen;

Identifizieren von Operationskodeplätzen in der Befehlswarteschlange, denen die Dispatch-Positionen zugewiesen worden sind; und

Melden der im Identifizierungsschritt identifizierten Operationskodeplätze an die jeweiligen Dispatch-Positionen;

wobei auf einer stufenweisen Basis, bei der jede Stufe ein Eingangs- Array von Operationskodekennungen und ein Ausgangs-Array von Operationskodekennungen umfasst, folgende Schritte ausgeführt werden:

Identifizieren eines Platzes des ersten Operationskodes im Eingangs- Array; und Ausbreiten eines Arrays vom Eingangs-Array zum Ausgangs- Array, wobei bei dem Ausbreitungs-Array der in der Identifizierungseinrichtung identifizierte Platz maskiert ist, wenn die entsprechende Dispatch-Position einer einem bestimmten Befehl zuletzt zugewiesenen Dispatch-Position entspricht;

wobei die Stufen seriell miteinander gekoppelt sind und bei einer vorderen Stufe das Eingangs-Array mit den Operationskodekennungen in der Befehlswarteschlange gekoppelt ist und bei jeder anderen Stufe das Eingangs-Array mit dem Ausgangs-Array einer unmittelbar vorhergehenden Stufe gekoppelt ist.

24. Verfahren nach Anspruch 23, bei dem die Primärbefehle x86-Befehle sind und bei dem die ROPs, auf die jeder Befehl übertragen wird, eine geordnete Sequenz bilden und mit jeweiligen Nummern in der geordneten Sequenz versehen sind, wobei jede Stufe ferner aufweist:

ein der Nummer des ROP, dem zuletzt eine Dispatch-Position zugewiesen worden ist, zugehöriges Ausgangs-Array; und

ein der Nummer der ROPs, auf die die zugeordneten x86-Befehle übertragen werden, zugehöriges Ausgangs-Array, ferner mit folgenden Schritten:

Erzeugen erster Operationskode-Identifikationssignale bzw. Look- ahead-Signale für die Gruppen der Stufe; und

Maskieren des Ausgangs-Arrays von Operationskodekennungen der unmittelbar vorhergehenden Stufe, wenn die Nummer des ROP, dem zuletzt eine Dispatch-Position zugewiesen worden ist, und die Nummer der ROPs, auf die der zugeordnete x86-Befehl übertragen wird, gleich sind.