DE69613586T2

DE69613586T2 - Befehlsdekoder mit emulation durch indirektspezifizierer

Info

Publication number: DE69613586T2
Application number: DE69613586T
Authority: DE
Inventors: G. Favor
Original assignee: Advanced Micro Devices Inc
Current assignee: GlobalFoundries Inc
Priority date: 1995-10-06
Filing date: 1996-10-04
Publication date: 2002-04-25
Anticipated expiration: 2016-10-05
Also published as: JPH11510288A; WO1997013195A1; EP0853782A1; EP0853782B1; DE69613586D1; AU7246496A

Description

Technischer Bereich

Diese Erfindung betrifft Prozessoren. Die Erfindung betrifft insbesondere Prozessoren mit einem Instruktionsdekodierer, der ein Emulations-ROM für eine Emulationsdekodierlogik enthält.

Stand der Technik

EP-A-0 651 320 offenbart einen bekannten superskalaren Instruktionsdekodierer dieses Anmelders.
IEEE MICRO, vol. 15, No. 5, 1. Oktober 1995, Seiten 22 bis 30, XP000527879 Segars et al mit dem Titel "Embedded control problems, thumb, and the ARN7TDMI" betrifft relevanten Stand der Technik.
COMPCOM '78, Februar 1978, IEEE, New York, USA, Seiten 81 bis 87, XP002021090 John R. Mick mit dem Titel "Microprogramming techniques using the AM 2910 sequencer" betrifft ebenfalls relevanten Stand der Technik.
Fortschrittliche Mikroprozessoren, wie beispielsweise X86-Prozessoren der P6-Klasse, sind durch einen allgemeinen Satz von Eigenschaften definiert. Diese Eigenschaften umfassen eine superskalare Architektur und Leistungsfähigkeit, das Dekodieren von mehreren X86-Instruktionen pro Takt und die Umwandlung dieser mehreren X86-Instruktionen in RISC-ähnliche Operationen. Die RISC-ähnlichen Operationen werden außer der Reihe in einem Kern vom RISC-Typ ausgeführt, der von der Dekodierung entkoppelt ist. Diese fortschrittlichen Mikroprozessoren unterstützen große Instruktionsfenster zum Umordnen von Instruktionen und zum Unordnen von Speicherverweisen.
Die Leistungsfähigkeit eines fortschrittlichen superskalaren Mikroprozessors hängt im höchsten Maße von der Leistungsfähigkeit der Dekodierung ab, welche die Dekodiergeschwindigkeit, die Anzahl der in einem einzelnen Takt dekodierbaren X86-Instruktionen und die Leistungsfähigkeit und die Handhabung der Sprungvorhersage umfasst. Instruktionsdekodierer in fortschrittlichen superskalaren Mikroprozessoren enthalten oftmals einen oder mehrere Dekodierlaufwege, in welchen X86-Instruktionen mittels einer hardwaremäßig ausgeführten Logiktranslation dekodiert werden, und einen separaten Dekodierlaufweg, welcher einen ROM-Speicher zum Holen einer RISC-Operationssequenz, die einer X86-Instruktion entspricht, benutzt. Im allgemeinen sind die X86-Instruktionen, welche von einer Hardwarelogik übersetzt werden, einfache X86-Instruktionen. Das Nachschlag-ROM wird benutzt, um komplexere X86-Instruktionen zu dekodieren.
Ein wesentliches Problem in einem Prozessor, der ein Mikrocode-ROM zum Ausführen der direkten Instruktionen benutzt, ist die Größe des ROM-Speichers.
Ein weiteres Problem bei der Benutzung eines Nachschlag-ROMs für Dekodierinstruktionen ist der Verwaltungsaufwand, der entsteht, bei der Bestimmung einer vektoriellen ROM-Adresse und bei dem Erlangen von Operationen (Ops) aus dem ROM. Dieser Verwaltungsaufwand verursacht typischerweise einen Verlust im Durchsatz des Dekodierers für Instruktionen, welche unter Benutzung des ROMs dekodiert werden. Diese Durchsatzverringerung senkt die Leistungsfähigkeit des Dekodierens.
Ein weiteres Problem mit der Benutzung eines Nachschlag-ROMs zum Dekodieren von X86-Instruktionen ist das Vorhandensein einer großen Anzahl von verschiedenen Instruktionen vom CISC-Typ, welche der Standard für einen X86-Prozessor sind. Da eine beträchtliche Anzahl von Instruktionen implementiert sind, ist eine große ROM-Schaltung auf den Prozessorchip zum Konvertieren der Instruktionen in RISC-ähnliche Operationen notwendig. Die große Anzahl der implementierten Instruktionen geht einher mit einer ansteigenden Komplexität der Schaltung zum Ableiten von Zeigern auf das ROM und zum Anwenden der abgeleiteten Zeiger auf das ROM. Diese angestiegene Komplexität der Schaltung hängt direkt mit dem angestiegenen Verwaltungsaufwand zusammen, welcher den Durchsatz der Instruktionsdekodierung reduziert.
En großes Nachschlag-ROM lässt die Größe der integrierten Schaltung des Prozessors ansteigen und reduziert dadurch die Herstellungsausbeute der Schaltungen und erhöht die Produktionskosten. Ein Merkmal eines Nachschlag-ROMs ist, dass viele Instruktionssequenzen gemeinsame Ähnlichkeiten und nur sehr geringe Unterschiede aufweisen. Entsprechend hat ein Nachschlag-ROM-Speicher typischerweise einen hohen Grad von Redundanz zwischen verschiedenen Instruktionen.
Was gebraucht wird, ist ein Rom-basierter Dekodierer in einem superskalaren Instruktionsdekodierer mit reduzierter Größe und reduzierter Komplexität.

Beschreibung der Erfindung

In Übereinstimmung mit der vorliegenden Erfindung nutzt ein ROM-basierter Dekodierer den Grad der Redundanz zwischen den Instruktionen aus, um einige Operationsstrukturen zu teilen und die Speichergröße erheblich zu reduzieren. Der Dekodierer beinhaltet eine Schaltung, welche gemeinsame ROM-Sequenzen zusammenführt und teilt, um die ROM-Größe zu reduzieren.
In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung umfasst ein superskalarer Mikroprozessor einen Instruktionsdekoder mit einer Emu- Ilationscode-Steuerschaltung und einem Emulations-ROM, welches die Funktion eines logischen Instruktionsdekodierer emuliert. Ein Instruktionsregister wird geladen mit einer aktuellen Instruktion und hat verschiedene Bit-Felder, die dem Zustand des Prozessors entsprechend erneuert werden. Eine Eintrittpunktschaltung leitet den Eintrittspunkt eines Emulations-ROMs von den in dem Instruktionsregister abgelegten Instruktionen ab. Der Eintrittspunkt des Emulations-ROMs wird benutzt, um das Emulations-ROM zu adressieren, von welchem eine Operation (Op) oder eine Gruppe von Ops gelesen wird. Verschiedene Felder in der Op werden selektiv durch das Instruktionsregister ersetzt.
In Übereinstimmung mit einem ersten Ausführungsbeispiel der vorliegenden Erfindung umfasst eine Instruktionsdekodier-Emulationsschaltung in einem Prozessor ein Instruktionsregister zum Halten eines Instruktionscodes und eine Eintrittspunktschaltung, die mit dem Instruktionsregister verbunden ist, zum Empfangen eines Instruktionscodes. Das Instruktionsregister hat mehrere Felder für codierte Bits innerhalb des Instruktionscodes. Die Eintrittspunktschaltung leitet einen Eintrittspunkt aus dem Instruktionscode ab. Die Instruktionsdekodier-Emulationsschaltung umfasst des weiteren einen zum Empfang des abgeleiteten Eintrittspunkts mit der Eintrittspunktschaltung verbundenen Emulationscode-Sequenzierer und einen mit dem Emulaitionscode-Sequenzer verbundenen Emulationscode-Speicher zum Empfangen der Führungssignal. Der Emulationscode-Sequenzierer führt eine Sequenz von Operationen (Ops) und erzeugt Führungssignale in Übereinstimmung mit der geführten Sequenz. Der Emulationscode-Speicher speichert eine Vielzahl von Op-Sequenzen und Sequenzsteuercodes. Der Emulationscode-Speicher hat einen ersten Ausgangsanschluss zum Ausgeben von Op-Sequenzen und einen zweiten Ausgangsanschluss zum Ausgeben von Sequenzsteuercodes. Der Sequenzsteuercode-Ausgangsanschluss ist mit dem Emulationscode-Sequenzierer verbunden. Die Instruktionsdekodier-Emulationsschaltung enthält auch eine Operations-(Op- )Substitutionsschaltung, die zum Empfang einer Op-Sequenz mit dem ersten Ausgangsanschluss des Emulationscode-Speichers verbunden und zum Empfang gewählter Instruktionscode-Felder für kodierte Bits mit dem Instruktionsregister verbunden ist. Die Op-Substitutionsschaltung ersetzt ausgewählte Felder der Instruktionscode-Bit-Felder in der Op-Sequenz.
Das Instruktionsregister hält Instruktions-Bytes, welche von einem vektorisierenden Dekodierer dekodiert werden. Während einer vektorisierenden Instruktionsdekodierung erzeugt der vektorisierende Dekodierer ein anfängliches Vektor-Quadrupel und eine Eintrittspunkt-Adresse, basierend auf den Inhalten des Instruktionsregisters. Zur selben Zeit initialisiert der vektorisierende Dekodierer die Variablen der Emulationsumgebung, auch Emulationsumgebungs-Register genannt, aus verschiedenen Informationen, die auf Feldern des Instruktionsregisters basieren und von anderen Informationen ausgehen. Information aus dem Emulationsumgebungs-Register wird an die Op-Substitutionslogik weitergegeben, welche die Substitutionsoperation ausführt.
In Übereinstimmung mit einem weiteren Ausführungsbeispiel der vorliegenden Erfindung umfasst ein Verfahren zum Betätigen einer Instruktionsdekodier-Emulationsschaltung in einem Prozessor die Schritte des Empfangens eines Instruktionscodes in ein Instruktionsregister, das mehrere Felder für codierte Bits innerhalb des Instruktionscodes aufweist, und das selektive Aktualisieren verschiedener der mehreren Felder für codierte Bits dem Zustand des Prozessors entsprechen. Das Verfahren enthält ferner die Schritte des Ableitens eines Eintrittspunkts aus dem Instruktionscode und des Adressierens eines Emulationscode-Speichers entsprechend dem abgeleiteten Eintrittspunkt. Der Emulationscode-Speicher speichert mehrere Op- Sequenzen. Die Methode umfasst auch die Schritte des Ausgebens einer adressierten Operation aus dem Emulationscode-Speicher und das Substituieren gewählter Felder für codierte Bits des Instruktionscodes in der adressierten Operation.
Durch den beschriebenen Dekodierer werden viele Vorteile gewonnen. Die Verwendung der Emulationsmodus-Substitution erzielt das Kodieren von CISC-Funktionalität bei wesentlicher Reduktion der Größe des Emulationscode-ROMs, was vorteilhafterweise die Größe und den Preis einer integrierten Schaltung mit Prozessor reduziert. Die Emulationsmodus-Substitution ermöglicht das Teilen von ROM-Sequenzen durch ähnliche Instruktionen.

Kurzbeschreibung der Zeichnungen

Diejenigen Merkmale der Erfindung, welche als neu angesehen werden, werden insbesondere in den beigefügten Ansprüchen erläutert. Jedoch kann die Erfindung selbst sowohl bezüglich ihrer Struktur als auch das Verfahren zur Ausführung am besten verstanden werden unter Bezugnahme auf die folgende Beschreibung und die beigefügten Zeichnungen.
Fig. 2 ist ein Blockdiagramm, welches ein Computersystem in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung erläutert.
Fig. 2 ist ein Blockdiagramm, das ein Ausführungsbeispiel eines Prozessors zur Benutzung in dem in Fig. 1 gezeigten Computersystem darstellt.
Fig. 3 ist ein Zeitablaufdiagramm, das das Timing der Pipeline für ein Ausführungsbeispiel des in Fig. 2 gezeigten Prozessors veranschaulicht.
Fig. 4 ist ein schematisches Blockdiagramm, das ein Ausführungsbeispiel eines Instruktionsdekodierers zeigt, der in dem in Fig. 2 gezeigten Prozessor benutzt wird.
Fig. 5 ist ein schematisches Blockdiagramm, welches eine Struktur eines Emulationscode-Sequenzierers und eine Emulationscode-Speichers des in Fig. 4 dargestellten Instruktionsdekodierers zeigt.
Fig. 6A bis 6E sind bildliche Darstellungen, die mehrere Operations-(Op-)Formate zeigen, welche von dem in Fig. 4 gezeigten Instruktionsdekodierer erzeugt wurden.
Fig. 7 ist eine bildliche Darstellung eines OpSeq-Feldformats, das in dem in Fig. 5 gezeigten Emulationscode-Speicher zur Verwendung kommt.
Fig. 8 ist eine bildliche Darstellung einer beispielhaften Instruktions-Substitution.
Fig. 9 ist ein Blockdiagramm eines Personal Computers mit einem Prozessor, der einen Instruktionsdekodierer eine Emulation beinhaltend aufweist, die in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung indirekte Spezifikatoren benutzt.

Wege zur Ausführung der Erfindung

Bezugnehmend auf Fig. 1 wird ein Computersystem 100 für verschiedene Anwendungen, eine Anwendung als Personal Computer eingeschlossen, genutzt. Das Computersystem 100 umfasst ein Computer-Motherboard 110, welches einen Prozessor 120 in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung enthält. Der Prozessor 120 ist eine monolithische integrierte Schaltung, welche ein komplexes Instruktionsset ausführt, so dass der Prozessor 120 als komplexer Instruktionssatz-Computer (CISC) bezeichnet werden kann. Beispiele von komplexen Instruktionssets sind die X86-Instruktionssets, welche bei der sehr bekannten 8086-Familie der Mikroprozessoren zum Einsatz kommen. Der Prozessor 120 ist mit einem Level-2-(L2)-Cache-Speicher 122, einer Speichersteuerung 124 und lokalen Bussteuerungen 126 und 128 verbunden. Die Speichersteuerung 124 ist an einen Hauptspeicher 130 angeschlossen, so dass die Speichersteuerung 124 ein Interface zwischen dem Prozessor 120 und dem Hauptspeicher 130 bildet. Die lokalen Bussteuerungen 126 und 128 sind mit Bussen verbunden, die einen PCI-Bus 132 und einen ISA-Bus 134 umfassen, so dass die lokalen Bussteuerungen 126 und 128 ein Interface zwischen dem PCI-Bus 132 und dem ISA-Bus 134 bilden.
Unter Bezugnahme auf Fig. 2 ist ein Blockdiagramm eines Ausführungsbeispiels des Prozessors 120 gezeigt. Der Kern des Prozessors 120 ist eine RISC superskalare Verarbeitungsmaschine. Übliche X86-Instruktionen werden von einer Instruktionsdekodier-Hardware in Operationen eines internen RISC-86-Instruktinssets konvertiert. Andere X86-Instruktionen, Ausnahmeberechnungen und andere verschiedene Funktionalitäten sind als in einem auf dem Chip befindlichen ROM RISC86-Operationssequenzen implementiert. Der Prozessor 120 hat Interfaces umfassend ein System-Interface 210 und eine L2-Cache-Speichersteuerlogik 212. Das System-Interface 210 verbindet den Prozessor 120 mit anderen Blöcken des Computersystems 100. Der Prozessor 120 greift mittels Lese- und Schreibzugriffen über das System-Interface 210 auf den Adressraum des Computers 100 zu, was den Hauptspeicher 130 und Geräte auf den lokalen Bussen 132 und 134 umfasst. Die L2-Cache-Speichersteuerlogik 212 bildet ein Interface zwischen einem externen Cache-Speicher, wie dem L2-Cache-Speicher 122, und dem Prozessor 120. Genauer gesagt verbindet die L2-Cache-Speichersteuerlogik 212 den L2-Cache-Speicher 122 und einen Instruktions-Cache-Speicher 214 und einen Daten-Cache-Speicher 216 in dem Prozessor 120. Der Instruktions-Cache-Speicher 214 und der Daten-Cache-Speicher 216 sind Level 1 (L1) Cache-Speicher, welche über den Level 2-Cache-Speicher 122 mit dem Adressraum des Computersystems 100 verbunden sind.
Instruktionen vom Hauptspeicher 130 werden in den Instruktions-Cache- Speicher 214 über einen Vordekodierer 270 zur erweiteten Ausführung geladen. Der Vordekodierer 270 erzeugt vordekodierte Bits, welche in Kombination mit Instruktions-Bits in dem Instruktions-Cache-Speicher 214 gespeichert werden. Die vordekodierten Bits, z.B. 3 Bits, werden zusammen mit einem zugehörigen Instruktionsbyte (8 Bits) gehalten und benutzt, um das Dekodieren mehrerer Instruktionen zu erleichtern und die Dekodierzeit zu verringern. 32 Bytes von Instruktionsbytes werden zu einer Zeit als Impulstransfer von vier 8 Byte-Größen in den Instruktions-Cache-Speicher 214 geladen. Die Logik des Vordekodierers 270 ist achtfach nachgebildet zur viermaligen Benutzung in einer Cache-Speicherleitung, so dass die vordekodierten Bits für alle acht Instruktionsbytes gleichzeitig berechnet werden, unmittelbar bevor sie in den Instruktions-Cache-Speicher 214 geschrieben werden. Eine Vordekodierungsoperation auf einem Byte basiert typischerweise auf Informationen in einem, zwei oder drei Bytes, so dass die Vordekodierungsinformation sich jenseits einer Acht-Byte-Gruppe erstrecken können. Entsprechend werden die letzten zwei Bytes einer Acht-Byte-Gruppe reserviert zum Bearbeiten mit der nächsten Acht-Byte-Gruppe in dem Fall, dass die Vordekodierungsinformation zwei Acht-Byte-Gruppen überlappt. Instruktionen in dem Instruktions-Cache-Speicher 214 sind CISC-Instruktionen, hier als Makro-Instruktionen bezeichnet. Ein Instruktionsdekodierer 220 konvertiert CISC-Instruktionen aus dem Instruktions-Cache-Speicher 214 in Operationen eines Instruktionssets für eine reduzierte Instruktionsset-Berechnungs-(RISC-)Architektur zur Ausführung auf einer Ausführungsmaschine 222. Eine einzelne Makroinstruktion aus dem Instruktions- Cache-Speicher 214 wird in eine oder mehrere Operationen für die Ausführungsmaschine 222 dekodiert.
Der Instruktionsdekodierer 220 hat Interface-Verbindungen zu dem Instruktions-Cache-Speicher 214 und zu einer Instruktionshaltesteuerschaltung (gezeigt in Fig. 4). Der Instruktionsdekoder 220 umfasst einen Makroinstruktions-Dekoder 230 zum Dekodieren der meisten Makroinstruktionen, eine Instruktionsemulationsschaltung 231, die ein Emulations-ROM 232 beinhaltet, zum Dekodieren eines Teilsatzes der Instruktionen, wie komplexer Instruktionen, und eine Sprungeinheit 234 zur Sprungvorhersage und Sprungbehandlung. Die Makroinstruktionen werden anhand des allgemeinen Typs der Operationen, in welche die Makroinstruktionen konvertiert werden, klassifiziert. Die allgemeinen Typen der Operationen sind Registeroperationen (RegOps), Ladespeicheroperationen (LdStOps), Lade-einen-Wert-unmittelbar-Operationen (LIMMOps), spezielle Operationen (SpecOps) und Gleitkommaoperationen (FpOps).
Die Ausführungsmaschine 222 hat eine Planungseinheit 260 und sechs Ausführungseinheiten umfassend eine Ladeeinheit 240, eine Speichereinheit 242, eine erste Registereinheit 244, eine zweite Registereinheit 246, eine Gleitkommaeinheit 248 und eine Multimediaeinheit 250. Die Planungseinheit 260 verteilt Operationen an geeignete Ausführungseinheiten und die Ausführungseinheiten arbeiten parallel. Jede Ausführungseinheit führt einen bestimmten Operationstypen aus. Genauer gesagt laden (lesen) oder speichern (schreiben) die Ladeeinheit 240 bzw. die Speichereinheit 242 Daten aus bzw. in den Daten-Cache-Speicher 216 (L1-Daten-Cache-Speicher), den L2-Cache-Speicher 122 und den Hauptspeicher 130 während der Ausführung einer Schreib-/Speicheroperation (LdStOp). Eine Speicherwarteliste 262 speichert zeitweise Daten von der Speichereinheit 242, so dass die Speichereinheit 242 und die Ladeeinheit 240 parallel arbeiten, ohne mit Konflikten auf den Daten-Cache-Speicher 216 zuzugreifen. Die Registereinheiten 244 und 246 führen Registeroperationen (RegOps) zum Zugriff auf eine Registerdatei 2190 aus. Die Gleitkommaeinheit 248 führt Gleitpunktoperationen (FpOps) aus. Die Multimediaeinheit 250 führt arithmetische Operationen für Multimediaanwendungen aus.
Die Planungseinheit 260 ist in eine Vielzahl von z.B. 24 Einträgen aufgeteilt, wobei jeder Eintrag Speicherraum und Logik umfasst. Die 24 Einträge sind in sechs Gruppen von vier Einträgen, Op-Quadrupel bezeichnet, gruppiert. Die Information in dem Speicherbereich eines Eintrages beschreibt eine Operation zur Ausführung unabhängig davon; ob die Ausführung anhängig oder beendet ist. Die Planungseinheit überwacht die Einträge und verteilt Informationen von den Einträgen an die der Information zugewiesenen Ausführungseinheiten.
Bezugnehmend auf Fig. 3 setzt der Prozessor 120 fünf- und sechsstufiges grundlegendes Pipeline-Timing ein. Der Instruktionsdekodierer 220 dekodiert zwei Instruktionen in einem einzelnen Taktzyklus. Während einer ersten Stufe 310 holt die Instruktionsholsteuerschaltung 218 CISC-Instruktionen in den Instruktions-Cache-Speicher 214. Die Vordekodierung der CISC-Instruktionen während der Stufe 310 reduziert die darauffolgende Dekodierungszeit. Während einer zweiten Stufe 320 dekodiert der Instruktionsdekoder 220 Instruktionen aus dem Instruktions-Cache-Speicher 214 und lädt einen Op-Quadrupel in die Planungseinheit 260. Während einer dritten Stufe 330 sieht die Planungsschaltung 260 die Einträge durch und gibt Operationen an die entsprechenden Ausführungseinheiten 240 bis 252 aus, wenn eine Operation für die entsprechenden Typen der Ausführungseinheiten vorhanden ist. Die während der Stufe 330 ausgegebenen Operanden für die Operationen werden in einer vierten Stufe 340 an die Ausführungseinheiten weitergeleitet. Für eine RegOp wird die Operation im allgemeinen im nächsten Taktzyklus, welcher Stufe 350 ist, abgeschlossen, aber LdStOps benötigen mehr Zeit für die Adressberechnung 352, den Datenzugriff und das Übertragen der Ergebnisse 362.
Für Sprungoperationen führt der Instruktionsdekodierer 220 eine Sprungvorhersage 324 während einer beginnenden Dekodierung einer Sprungoperation aus. Eine Sprungeinheit 252 bewertet die Bedingungen für den Sprung in einer späteren Stufe 364, um zu bestimmen, ob die Sprungvorhersage 324 korrekt war. Ein zweistufiger Sprungvorhersage-Algorithmus sagt eine Richtung des abhängigen Sprungs voraus und das Holen von CISC-Instruktionen in Stufe 310 und das Dekodieren der CISC-Instruktionen in Stufe 320 schließt sich in der vorhergesagten Sprungrichtung an. Die Planungseinheit 260 stellt fest, wenn alle Bedingungscodes, die für de Sprungsvorhersage benötigt werden, gültig sind und weist die Sprungeinheit 252 an, die Sprunginstruktion zu bewerten. Falls ein Sprung nicht korrekt vorhergesagt wurde, werden die Operationen in der Planungseinheit 260, welche nicht ausgeführt werden sollen, gelöscht und der Dekodierer 220 beginnt das Laden von neuen Op-Quadrupeln von der korrekten Adresse nach dem Sprung. Ein Zeitverlust tritt auf, wenn die Instruktionen für den korrekten Sprung geholt werden. Der Instruktionsdekodierer 220 liest entweder eine vorher gespeichert vorhergesagte Adresse oder berechnete eine Adresse unter Benutzung einer Anordnung von parallelen Addierern. Wenn eine vorher vorhergesagte Adresse gespeichert wird, wird die vorhergesagte Adresse in Stufe 326 geholt und Instruktionen, die an der vorhergesagten Adresse lokalisiert sind, werden in Stufe 328 ohne eine Verzögerung für die Addierer geholt. Ist dies nicht der Fall, berechnen die parallelen Addierer die vorhergesagte Adresse.
In der Sprungbewertungsstufe 364 stellt die Sprungeinheit 252 fest, ob die vorhergesagte Sprungrichtung richtig ist. Wenn ein vorhergesagter Sprung richtig ist, laufen die Schritte des Holens, Dekodierens und Ausführens der Instruktionen ohne Unterbrechung weiter. Für eine nicht richtige Vorhersage wird die Planungseinheit 260 geleert und der Instruktionsdekoder 220 fängt an, die Makroinstruktionen von dem korrekten Programmzähler, der auf den Sprung folgt, zu dekodieren.
Das in Fig. 4 gezeigte schematische Blockdiagramm stellt ein Ausführungsbeispiel einer Instruktionsvorbereitungsschaltung 400 dar, welche mit dem Hauptspeicher 130 verbunden ist. Die Instruktionsvorbereitungsschaltung 400 umfasst den Instruktions-Cache-Speicher 214, der über die Vordekodierung 270 mit dem Hauptspeicher 130 verbunden ist. Der Instruktionsdekodierer 220 ist angeschlossen, um Instruktionsbytes und Vordekodierungsbits von drei alternativen Quellen zu empfangen, nämlich dem Instruktions- Cache-Speicher 214, einem Sprungzielpufferspeicher (BTB) 456 und einem Instruktionspufferspeicher 408. Die Instruktionsbytes und Vordekodierungsbits werden an den Instruktionsdekodierer 220 über eine Vielzahl von Rotatoren 430,432 und 434 über Instruktionsregister 450,452 und 454 ausgegeben. Der Makroinstruktionsdekodierer 230 hat Eingangsverbindungen zu dem Instruktions-Cache-Speicher 214 und der Instruktionsholsteuerschaltung 218 zum Empfangen von Instruktionsbytes und dazugehörigen Vordekodierungsinformationen. Der Makroinstruktionsdekodierer 230 puffert geholte Instruktionsbytes in einem Instruktionspufferspeicher 408, der mit der Instruktionsholsteuerschaltung 218 verbunden ist. Der Instruktionspufferspeicher 408 ist ein 16-Byte-Puffer, welcher bis zu 16 Bytes oder vier ausgerichtete Worte von dem Instruktions-Cache-Speicher 214 empfängt und puffert, um dabei so viele Daten lädt, wie es der Umfang des freien Speicherplatzes in dem Instruktionspufferspeicher 408 erlaubt. Der Instruktionspufferspeicher 408 hält die nächsten Instruktionsbytes, die dekodiert werden sollen, und lädt kontinuierlich neue Instruktionsbytes nach, wenn alte von dem Makroinstruktionsdekodierer 230 verarbeitet werden. Die Instruktionen sowohl im Instruktions-Cache-Speicher 214 als auch in dem Instruktionspufferspeicher 408 werden in "erweiterten" Bytes gehalten, die sowohl Speicherbits (8) und vordekodierte Bits (5) umfassen, und werden in derselben Ausrichtung gehalten. Die vordekodierten Bits unterstützen den Makroinstruktionsdekodierer 230 bei der Ausführung des Dekodierens von mehreren Instruktionen innerhalb eines einzelnen Taktzyklus.
Instruktionsbytes, die unter Benutzung eines Dekodierungsprogrammzählers (PC) 420,422 oder 424 adressiert werden, werden von dem Instruktionspufferspeicher 408 zu dem Makroinstruktionsdekodierer 230 transferiert. Der Instruktionspufferspeicher 408 wird byteweise von den Kodierern in dem Makroinstruktionsdekodierer 230 angesprochen. Jedoch wird in jedem Dekodierungszyklus der Instruktionspufferspeicher wortweise gesteuert, um zu verfolgen, welche der Bytes in dem Instruktionspufferspeicher 408 gültig sind und welche mit neuen Bytes aus dem Instruktions- Cache-Speicher 214 zu ersetzen sind. Die Festlegung, ob ein Instruktionsbyte gültig ist, wird beibehalten, wenn das Instruktionsbyte dekodiert wird. Für ein ungültiges Instruktionsbyte setzt eine Dekodierungültigkeitslogik (nicht gezeigt), welche mit dem Makroinstruktionsdekodierer 230 verbunden ist, ein "Byte ungültig"-Signal. Die Steuerung des Aktualisierens des derzeitigen Hole-PC 426 ist eng mit der Gültigkeit von Instruktionsbytes in dem Instruktionspufferspeicher 408 und dem Verbrauch der Instruktionsbytes durch den Instruktionsdekodierer 220 synchronisiert.
Der Makroinstruktionsdekodierer 230 empfängt bis zu sechszehn Bytes oder vier ausgerichtete Worte von Instruktionsbytes, die am Ende eines Hol- Zyklus von der Instruktionshoisteuerschaltung 218 geholt werden. Die Instruktionsbytes aus dem Instruktions-Cache-Speicher 214 werden in einen Instruktionspufferspeicher 208 mit sechszehn Byte geladen. Der Instruktionspufferspeicher 408 puffert Instruktionsbyte sowie zusätzlich Vordekodierungsinformationen zugehörig zu jedem der Instruktionsbytes, wenn die Instruktionsbytes geholt und/oder dekodiert werden. Der Instruktionspufferspeicher 408 empfängt so viele Instruktionsbytes wie in dem freien Platz des instruktionspufferspeichers 408 untergebracht werden können, hält die nächsten zu dekodierenden Instruktionsbytes und lädt kontinuierlich neue Instruktionsbytes nach, wo vorherige Instruktionsbytes an individuelle Dekodierer innerhalb des Makroinstruktionsdekodierers 230 transferiert werden. Der Instruktionsvordekodierer 270 addiert Vordekodierungsinformationsbits zu den Instruktionsbytes, wenn die Instruktionsbytes an den Instruktions-Cache-Speicher 214 weitergegeben werden. Daher werden die in dem Instruktions-Cache-Speicher 214 gespeicherten und von ihm weitergegebenen Instruktionsbytes als erweiterte Bytes bezeichnet. Jedes erweiterte Byte umfasst acht Speicherbits plus fünf Vordekodierungsbits. Die fünf Vordekodierungsbits umfassen drei Bits, welche die Instruktionslänge kodieren, ein D-Bit, das festschreibt, ob die Instruktionslänge abhängig vom D-Bit ist, und ein HasModRM-Bit, das anzeigt, ob ein Instruktionscode ein modrm-Feld enthält. Die dreizehn Bits werden in dem Instruktionspufferspeicher 408 gespeichert und an die Dekodierer des Makroinstruktionsdekodierers 230 weitergegeben. Der Instruktionspufferspeicher 408 erweitert jeden Satz der fünf Vordekodierungsbits in sechs Vordekodierungsbits. Die Vordekodierungsbits ermöglichen den Dekodern eine schnelle Ausführung des Dekodierens von mehreren Instruktionen innerhalb eines Taktzyklus.
Der Instruktionspufferspeicher 408 empfängt Instruktionsbytes von dem Instruktions-Cache-Speicher 214 in dem Speicher ausgerichteten Worttyp des Instruktions-Cache-Speichers 214, so dass Instruktionen mit Wortgröße geladen und ersetzt werden. Daher hält die Bytestelle 0 des Instruktionspufferspeichers 408 immer Bytes, welche im Speicher mit einer Adresse 0 (mod 16) adressiert werden.
Instruktionsbytes werden von dem Instruktionspufferspeicher 408 an den Makroinstruktionsdekodierer 230 mit Bytegröße transferiert. Während jedes Dekodierungszyklus werden die sechszehn erweiterten Instruktionsbytes innerhalb des Instruktionspufferspeichers 408 inklusiv der dazugehörigen impliziten Wortgültigkeitbits an die Vielzahl der Dekodierer innerhalb des Makroinstruktionsdekodierers 230 transferiert. Diese Methode des Transferierens der Instruktionsbytes von dem Instruktions-Cache-Speicher 214 zu dem Makroinstruktionsdekodierer 230 über den Instruktionspufferspeicher 408 wird mit jedem Dekodierzyklus wiederholt, so lange die Instruktionen sequentiell dekodiert werden. Wenn ein Steuertransfer auftritt, z. B. wegen einer genommenen Sprungoperation, wird der Instruktionspufferspeicher 408 geleert und das Verfahren wird neu gestartet.
Der derzeitige Dekodierungs-PC hat dahingehend eine beliebige Byteausrichtung, dass der Instruktionspufferspeicher 408 eine Kapazität von sechszehn Bytes hat, aber auf einer Vier-Byte-Wortbasis betrieben wird, bei welcher alle vier Bytes eines Wortes verbraucht werden, bevor das Wort entfernt und mit vier neuen Bytes aus dem Instruktionspufferspeicher 408 ersetzt werden. Eine Instruktion hat eine Länge von einem bis elf Bytes und mehrere Bytes sind dekodiert, so dass die Ausrichtung einer Instruktion in dem Instruktionspufferspeicher 408 beliebig ist. Wenn Instruktionsbytes von dem Instruktionspufferspeicher 408 zu dem Makroinstruktionsdekodierer 230 weitergeleitet werden, wird der Instruktionspufferspeicher 408 aus dem Instruktions-Cache-Speicher 214 nachgeladen.
Instruktionsbytes in dem Instruktionspufferspeicher 408 werden eher in Speicherausrichtungen gespeichert als mit einer sequentiellen Byteausrichtung, welche für Applikationen von aufeinanderfolgenden Instruktionsbytes für den Makroinstruktionsdekodierer 230 geeignet ist. Daher ist ein Satz von Byterotatoren 430, 432 und 434 zwischen den Instruktionspufferspeicher 408 und jeden der Dekodierer des Makroinstruktionsdekodierers 230 geschaltet. Vier Instruktionsdekodierer umfassen drei kurze Dekodierer SDec0 410, SDec1 412 oder SDec2 414 und einen kombinierten Lang- und vektorisierenden Dekodierer 418 teilen die Byterotatoren 430, 432 und 434. Genauer gesagt teilen sich der Kurzdekodierer SDec0 410 und der kombinierte Dekodierer 418 den Byterotator 430. Der Kurzdekodierer SDec1 412 ist dem Byterotator 432 zugeordnet und der Kurzdekodierer SDec2 414 ist dem Byterotator 434 zugeordnet.
Eine Vielzahl von Pipeline-Registern, genauer gesagt Instruktionsregistern 450, 452 und 545 sind zwischen den Byterotatoren 430, 432 und 434 und dem Instruktionsdekodierer 220 angeordnet, um die Instruktionsbytes, die Vordekodierungsbits und andere Informationen zu halten, wodurch der Dekodierungstimingzyklus verkürzt wird. Die anderen in den Instruktionsregistern 450, 452 und 454 gehaltenen Informationen umfassen verschiedene Informationen zum Unterstützen des Dekodierens von Instruktionen umfassend einen Präfix-(z.B. 0F)Status, die unmittelbare Größe (8 Bit oder 32 Bit), versetzungs- und langdekodierbare Längenbezeichnungen.
Obwohl eine Schaltung gezeigt ist, welche drei Rotatoren und drei Kurzdekodierer benutzt, können in anderen Ausführungsbeispielen verschiedene Anzahl von Schaltungselementen eingesetzt werden. Beispielsweise enthält eine Schaltung zwei Rotatoren und zwei Kurzdekodierer.
Instruktionen in dem Instruktions-Cache-Speicher 214, dem Sprungzielpufferspeicher (BTB) 456 und in dem Instruktionspufferspeicher 408 werden in Speicherausrichtung und nicht in Instruktionsausrichtung gespeichert, so dass die Stelle des ersten Instruktionsbytes nicht bekannt ist. Die Byterotatoren 430, 432 und 434 finden das erste Byte einer Instruktion.
Der Makroinstruktionsdekodierer 230 führt des weiteren verschiedene Instruktionsdekodierungs- und Ausnahmedekodierungsoperationen durch umfassend die Validierung von Dekodierungsoperationen und die Auswahl zwischen verschiedenen Typen von Dekodierungsoperationen. Funktionen, die während der Dekodierungsoperationen ausgeführt werden, umfassen die Handhabung von Präfix-Bytes, die Unterstützung für das Vektorisieren zu dem Emulationscode-ROM 232 zum Emulieren von Instruktionen und die Unterstützung für Operationen der Sprungeinheit 234, das Ansprechen der Sprungeinheit und die Vorhersage der Rückadresse. Basierend auf den Instruktionsbytes und den zugehörigen Informationen erzeugt der Makroinstruktionsdekodierer 230 Operationsinformationen in Gruppen von vier Operationen entsprechend den Op-Quadrupeln. Der Makroinstruktionsdekodierer 230 erzeugt des weiteren Steuerinformationen für die Instruktionsvektorisierung und Steuerinformationen für den Emulationscode. Der Makroinstruktionsdekodierer 230 hat auch Ausgangsverbindungen mit der Planungseinheit 260 und mit dem Emulations-ROM 232 zum Ausgeben der Op-Quadrupel-Information, der Steuerinformation für die Instruktionsvektorisierung und der Steuerinformation für den Emulationscode. Der Makroinstruktionsdekodierer 230 dekodiert keine Instruktionen, wenn die Planungseinheit nicht fähig ist, Op-Quadrupel zu akzeptieren oder wenn die Op-Quadrupel von dem Emulationscode-ROM 232 annimmt.
Der Makroinstruktionsdekodierer 230 hat fünf ausgewiesene und getrennte Dekodierer, unter anderem drei "Kurz"-Dekodierer SDec0 410, SDec1 412 und SDec2 414, welche in Kombination arbeiten, um bis zu drei "Kurz"-Dekodierungsoperationen von Instruktionen, welche innerhalb eines Untersatzes von einfachen Instruktionen aus dem X86-Instruktionssatz definiert sind, zu dekodieren. Generell ist eine einfache Instruktion eine Instruktion, welche sich in weniger als drei Operationen übersetzt. Die Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 erzeugen jeweils typischerweise eine oder zwei Operationen, obwohl null Operationen in gewissen Fällen wie bei der Präfix-Dekodierung erzeugt werden. Entsprechend werden für drei Kurz- Dekodierungsoperationen zwei bis sechs Operationen in einem Dekodierungszyklus erzeugt. Die zwei bis sechs Operationen von diesen drei Kurzdekodierern werden nacheinander von einer Operationsverpackungslogik 438 zusammen in einen Op-Quadrupel verpackt, da ein Maximum von vier der sechs Operationen gültig ist. Genauer gesagt versucht jeder der drei Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 zwei Operationen zu dekodieren, wobei potentiell sechs Operationen erzeugt werden. Nur vier Operationen mögen zu einem Zeitpunkt hergestellt werden, so dass, falls mehr als vier Operationen bereitgestellt werden, die Operationen von dem Kurzdekodierer SDec2 414 ungültig gemacht werden. Die fünf Dekodierer umfassen des weiteren einen einzelnen "Lang"-Dekodierer 416 und einen einzelnen "vektorisierenden" Dekodierer 418. Der Langdekodierer 416 dekodiert Instruktionen oder Formen von Instruktionen, welche eine komplexere Adressmodusform haben, so dass mehr als zwei Operationen erzeugt werden und eine Kurz-Dekodierungshandhabung nicht verfügbar ist. Der vektorisierende Dekodierer 418 handhabt Instruktionen, welche nicht durch die Operation der Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 oder durch den Langdekodierer 416 bearbeitet werden können. Der vektorisierende Dekodierer 418 dekodiert nicht wirklich eine Instruktion, sondern eher Vektoren zu einer Stelle des Emulations-ROMs 232 für die Emulation der Instruktion. Verschiedene Ausnahmebedingungen, welche von dem Makroinstruktionsdekodierer 230 detektiert werden, werden auch als eine spezielle Form von vektorisierenden Dekodierungsoperationen behandelt. Bei Aktivierung erzeugen der Langdekoder 416 und der vektorisierende Dekodierer 418 jeder einen vollen Op-Quadrupel. Ein Op-Quadrupel, der von den Kurz-Dekodieren SDec0 410, SDec1 412 und SDec2 414 erzeugt worden ist, hat dasselbe Format als auch Op-Quadrupel, der von dem Langdekodierer 416 und dem vektorisierenden Dekodierer 418 erzeugt worden ist. Die Kurzdekodierer- und Langdekodierer-Op-Quadrupel beinhalten kein OpSeq-Feld. Der Makroinstruktionsdekodierer 230 wählt entweder den von den Kurzdekodierern 410, 412 und 414 erzeugten Op-Quadrupel oder den von dem Langdekodierer 416 oder dem vektorisierenden Dekodierer 418 erzeugten Op-Quadrupel bei jedem Dekodierungszyklus aus als ein Op- Quadrupel-Ergebnis des Makroinstruktionsdekodierers 230. Die Kurz-Dekodieroperation, die Lang-Dekodieroperation und die vektorisierende Dekodieroperation arbeiten parallel und unabhängig voneinander, obwohl die Ergebnisse lediglich eines Dekodierers zu einem Zeitpunkt benutzt werden.
Jeder der Kurzdekodierer 410,412 und 414 dekodiert bis zu sieben Instruktionsbytes, Angenommen, das erste Byte sei ein Operationscode- (opcode)Byte und die Instruktion sei eine Kurz-Dekodierungsinstruktion. Zwei Operationen (Ops) werden mit entsprechenden gültigen Bits erzeugt. Angemessene Werte für effektive Adressgröße, effektive Datengröße, das derzeitige X86-Standard-B-Bit und jegliche Override-Operanden-Segmeritregister werden für die Erzeugung von Operationen ausgegeben, in Abhängigkeit von diesen Parametern. Die logische Adresse der nächsten "sequentiellen" Instruktion, die hier zu dekodieren ist, wird ausgegeben zur Benutzung bei der Erzeugung der Operationen für eine CALL-Instruktion. Es ist hervorzuheben, dass das Wort "sequentiell" geschrieben worden ist, um anzuzeigen, dass, obwohl die "sequentielle" Adresse generell auf eine Instruktion zeigt, welche unmittelbar der aktuellen Instruktion vorsteht, die "sequentielle" Adresse auf jede adressierte Stelle gesetzt werden kann. Die derzeitige Sprungvorhersage wird ausgegeben zur Benutzung bei der Erzeugung der Operationen für die Steuerinstruktionen der bedingten Übertragungen. Eine kurze Dekodierung erzeugt Steuersignale, wie die Anzeige einer Transfersteuerinstruktion (z. B. Jcc, LOOP, JMP, CALL), einer bedingungslosen Transfersteuerinstruktion (z. B. JMP, CALL), eine CALL-Instruktion, ein Präfix-Byte, eine CC-abhängige RegOp und eine Feststellung, ob die Instruktionslänge von der Adresse oder der Datengröße abhängt. Typischerweise eine oder beide Operationen sind gültig, aber Präfix-Byte- und JMP-Dekodierungen erzeugen keine gültige Op. Ungültige Operationen erscheinen als gültige NOOP-Operationen, um einen Op-Quadrupel zu füllen.
Der erste Kurzdekodierer 410 erzeugt Operationen in Abhängigkeit von mehr als der Dekodierung der Instruktionsbytes. Der erste Kurzdekodierer 410 bestimmt auch das Vorhandensein von jeglichen Präfix-Bytes, welche während vorhergehenden Dekodierungszyklen dekodiert worden sind. Die verschiedenen Präfix-Bytes umfassen 0F, Adressengrößen-Override, Operandengröße-Override, sechs Segment-Override-Bytes, REP/REPE, REPNE und LOCK-Bytes. Jedes Präfix-Byte bewirkt eine darauffolgende Instruktionsdekodierung auf eine definierte Weise. Eine Zählung von Präfix-Bytes und eine Zählung von aufeinanderfolgenden Präfix-Bytes wird während des Dekodierens gesammelt und an den ersten Kurzdekodierer SDec0 410 und den Langdekodierer 416 ausgegeben. Der Zähler für die aufeinanderfolgenden Präfix-Bytes wird benutzt, um festzustellen, ob eine zu dekodierende Instruktion zu lang ist. Die Präfix-Byte-Zählerinformation wird ebenfalls genutzt, um aufeinanderfolgende Dekodierzyklen zu steuern, was das Überprüfen auf bestimmten Typen von instruktionsspezifischen Ausnahmebedingungen umfasst. Die Präfix-Zähler werden zurückgesetzt oder initialisiert an dem Ende eines jeden erfolgreichen Nicht-Präfix-Dekodierungszyklus in Vorbereitung für das Dekodieren der Präfix- und Opcode-Bytes der nächsten Instruktion. Die Präfix-Zähler werden auch reinitialisiert, wenn der Makroinstruktions-Dekoder 230 Sprungbedingungsoperationen und Schreibinstruktionszeiger-(WRIP)Operationen dekodiert.
Präfix-Bytes werden von dem ersten Kurzdekodierer 410 in der Art der einbytigen Kurzdekodierungsinstruktionen verarbeitet. Zumeist wird ein Präfix- Byte in einem Dekodierungszyklus dekodiert, eine Bedingung die erzwungen wird, durch die Ungültigkeit von allen Kurz-Dekodierungen, die auf die Dekodierung eines Präfix-Bytes folgen. Die effektive Adressgröße, Datengröße, Operandensegmentregisterwerte und das derzeitige B-Bit werden dem ersten Kurz-Dekodierer zugeführt, können aber gemeinsam mit vorhergehenden Opcodes dekodiert werden.
Der Adressgrößen-Präfix bewirkt eine Dekodierung von einer darauffolgenden Instruktion sowohl für das Dekodieren von Instruktionen, für welche die erzeugte Operation von der effektiven Adressgröße abhängt, also auch zum Dekodieren des Adressmodus und der Instruktionslänge von modr/m- Instruktionen. Die Standardadressgröße wird von dem derzeit bestimmten D-Bit bestimmt, welches effektiv mit dem Auftreten von einem oder mehreren Adressgrößen-Präfixen abhängig ist.
Der Operandengrößen-Präfix beeinflusst ebenfalls die Dekodierung von einer darauffolgenden Instruktion sowohl für das Dekodieren von Instruktionen, für welche die erzeugte Operation von der effektiven Datengröße abhängt, als auch für das Dekodieren der Instruktionslänge. Die Standardoperandengröße wird von dem derzeit bestimmten X86-Standard D-Bit bestimmt, welches effektiv von dem Auftreten von einem oder mehreren Operandengrößen-Präfixes abhängig ist.
Die Segment-Override-Präfixe beeinflussen das Dekodieren von einer darauffolgenden Instruktion nur für den Fall, dass die Erzeugung einer Lade- /Speicher-Operation (LdStOps) von dem effektiven Operandensegment der Instruktion abhängig ist. Das Standardsegment ist DS oder SS, abhängig von dem zugehörigen generellen Adressierungsmodus und wird von dem von dem letzten Segment-Override-Präfix angegebenen Segment ersetzt.
Die REP/REPE- und REPNE-Präfixe beeinflussen nicht das Dekodieren einer darauffolgenden Instruktion. Wenn die Instruktion von dem Makroinstruktionsdekodierer 230 dekodiert wird, anstatt durch das Emulationscode-ROM 232, dann werden alle vorangestellten REP-Präfixe ignoriert. Wenn jedoch die Instruktion vektorisiert ist, dann wird in einigen Fällen die Erzeugung der Vektoradresse geändert. Genauer gesagt werden, wenn eine Zeicheninstruktion oder spezielle angrenzende Opcodes vektorisiert werden, ein Hinweis auf das Auftreten von einem oder mehreren der REP-Präfixe und eine Bezeichnung des letzten angetroffenen REP-Präfixes in die Vektoradresse mit aufgenommen. Für alle anderen Instruktionen wird die Vektoradresse nicht modifiziert und der REP-Präfix wird ignoriert.
Ein LOCK-Präfix beinhaltet alle Kurz- und Lang-Dekodierungen bis auf das Dekodieren der Präfix-Bytes, was erzwingt, dass die darauffolgende Instruktion vektorisiert wird. Wenn der Vektordekodierungszyklus dieser darauffolgenden Instruktion erfolgt, wird das Opcode-Byte überprüft, so lange wie die darauffolgende Instruktion kein Präfix ist, um sicherzustellen, dass die Instruktion sich innerhalb eines "verschließbaren" Untersatzes der Instruktionen befindet. Wenn die Instruktion nicht eine verschließbare Operation ist, wird eine Ausnahmebedingung erkannt und die von dem vektorisierenden Dekodierer 418 erzeugte Vektoradresse wird durch eine Ausnahmeeintrittspunktadresse ersetzt.
Von den zweiten und dritten Kurzdekodierern 412 und 414 dekodierte Instruktionen haben keine Präfix-Bytes, so dass die Dekodierer 412 und 414 feste Vorgabewerte für die Adressgröße, die Datengröße und für die Operandensegmentregisterwerte annehmen.
Typischerweise erzeugen die drei Kurzdekodierer vier oder weniger Operationen, weil drei aufeinanderfolgende Kurz-Dekodierungen nicht immer ausgeführt werden und Instruktionen oftmals in lediglich eine einzelne Operation kurzdekodieren. Für das seltene Auftreten, wenn mehr als vier gültige Operationen erzeugt werden, verhindert die Operationsverpackungslogik 438 jedoch den dritten Kurz-Dekodierer 414 oder macht ihn ungültig, so dass lediglich zwei Instruktionen erfolgreich dekodiert werden und maximal vier Operationen zum Verpacken in einen Op-Quadrupel erzeugt werden.
Wenn der erste Kurz-Dekodierer 410 nicht erfolgreich ist, werden die Arbeiten des zweiten und des dritten Kurzdekodierers 412 und 414 ungültig gemacht. Wenn der zweite Kurz-Dekodierer 412 nicht erfolgreich ist, wird die Arbeit des dritten Kurzdekodierers 414 ungültig gemacht. Wenn sogar der erste Kurz-Dekodierer ungültig ist, wird der Dekodierzyklus ein langer oder vektorisierter Dekodierzyklus. Im allgemeinen versucht der Makroinstruktionsdekodierer 230 eine oder mehrere Kurzdekodierungen und wenn solche Kurzdekodierungen nicht erfolgreich sind, versucht er eine Langdekodierung. Wenn die Langdekodierung nicht erfolgreich ist, führt der Makroinstruktionsdekodierer 230 eine vektorisierte Dekodierung aus. Mehrere Bedingungen verursachen, dass die Kurz-Dekodierer 410, 412 und 414 ungültig gemacht werden. Ganz generell werden Kurzdekodierungen ungültig gemacht, wenn der Instruktionsoperationscode (Opcode) oder der zugewiesene Adressmodus einer modr/m-Instruktion nicht in einen definierten Kurzdekodierungs- oder "einfachen" Untersatz von Instruktionen fällt. Diese Bedingung beschränkt die Kurzdekodierungsinstruktionen auf diejenigen Operationen, welche zwei oder weniger Operationen erzeugen. Kurzdekodierungen werden ebenso ungültig, wenn nicht alle der Bytes in dem Instruktionspufferspeicher 408 für eine dekodierte Instruktion gültig sind. Auch werden "cc"-abhängige Operationen, das sind. von Zustandflags abhängige Operationen, nur von dem ersten Kurz-Dekodierer 410 erzeugt, um sicherzustellen, dass diese Operationen keine vorhergehenden "cc"-RegOps haben. Eine Kurzdekodierung wird ungültig für eine zweite von zwei aufeinanderfolgenden Kurzdekodierungen, wenn die unmittelbar vorlaufende Kurzdekodierung eine Dekodierung von einer Transfersteuerinstruktion war, unabhängig von der genommenen Richtung. Eine Kurzdekodierung wird ungültig für eine zweite von zwei aufeinanderfolgenden Kurzdekodierungen, wenn die erste Kurzdekodierung eine Dekodierung eines Präfix-Bytes war. Im allgemeinen verhindert ein Präfix-Code oder ein Transfersteuercode weiteres Dekodieren in einem Zyklus.
Darüber hinaus werden nicht mehr als sechszehn Instruktionsbytes von dem Makroinstruktionsdekodierer 230 verbraucht, da der Instruktionspufferspeicher 408 nur sechszehn Bytes zu einem Zeitpunkt hält. Auch können höchstens vier Operationen in einen Op-Quadrupel verpackt werden. Diese Beschränkungen betreffen lediglich den dritten Kurz-Dekodierer 414, da die Länge von jeder kurzdekodierten Instruktion höchstens sieben Bytes beträgt und nur über vier hinausgehende Operationen in dem dritten Kurz-Dekodierer 414 auftreten.
In einer damit zusammenhängenden Beschränkung kann eine Instruktion mit einer Länge, die adress- und/oder datenabhängig ist, nur von dem ersten Kurz-Dekodierer 410 bearbeitet werden, falls der aktuelle D-Bit-Wert eine 16-Bit-Adresse und eine Standarddatengröße angibt, da die Vordekodierungsinformation wahrscheinlich nicht korrekt ist. Auch ist es lediglich dem ersten Kurz-Dekodierer 410 erlaubt, Instruktionen und Präfix-Bytes erfolgreich zu dekodieren, wenn das Dekodieren von mehreren instruktionen nicht ermöglicht ist.
Tests zur Gültigkeit werden von einer Kurzdekodierungs-Gültigkeitslogik in dem Makroinstruktionsdekodierer 230 gesteuert und sind unabhängig von dem Betrieb der Kurz-Dekodierer 410, 412 und 414. Jedoch setzt jeder der Kurz-Dekodierer 410, 412 und 414 null, eins oder zwei gültige Bits, abhängig von der Anzahl der dekodierten Operationen. Diese gültigen Bits, eine Gesamtzahl von sechs für die drei Kurz-Dekodierer 410, 412 und 414 werden von der Operationsverpackungslogik 438 genutzt, um zu bestimmen, welche Operationen in einen Op-Quadrupel verpackt werden sollen und um ungültige Operationen zu zwingen, als NOOP-(keine Operation-) Operationen zu erscheinen. Die Operationsverpackungslogik 438 arbeitet ohne Kurzdekodierungs-Gültigkeitsinformationen, da den gültigen Kurzdekodierungen und dazugehörigen Operationen nur andere gültige Kurzdekodierungen oder zugehörige Operationen vorangehen.
Die Kurz-Dekodierer 410, 412 und 414 erzeugen auch eine Vielzahl von Signalen, welche verschiedene spezielle Code- oder modr/m-Adressmodusdekodierungen repräsentieren. Diese Signale zeigen an, ob eine bestimmte Form einer Instruktion derzeitig von dem Instruktionsdekodierer 220 dekodiert wird. Diese Signale werden von der Kurzdekodierungs-Gültigkeitslogik benutzt, um Kurzdekodierungs-Gültigkeitssituationen zu handhaben.
Die Instruktions-Bytes, welche unausgerichtet in dem Instruktionspufferspeicher 408 gespeichert werden, werden durch die Byterotatoren 430, 432 und 434 ausgerichtet, wenn die Instruktionsbytes an die Dekodierer 410 bis 418 weitergeleitet werden. Der erste Kurz-Dekodierer SDec0 410, der Langdekodierer 416 und der vektorisierende Dekodierer 418 teilen sich einen ersten Byterotator 430. Der zweite und dritte Kurz-Dekodierer SDec1 412 und SDec2 414 benutzen entsprechend zweite und dritte Byterotatoren 432 und 434. Während jedes Dekodierzyklus versuchen die drei Kurz-Dekodierer SDec0 410, SDec1 412 und SDec2 414 zu dekodieren, was höchst effizient drei Kurzdekodierungsoperationen sind, welche drei unabhängig voneinander arbeitende und parallele Byterotatoren 430, 432 und 434 benutzen. Obwohl das Multiplexen von geeigneten Bytes in dem Instruktionspufferspeicher 408 zu jedem entsprechenden Dekodierer SDECO 410, SDec1 412 und SDec2 414 durch die Byterotatoren 430, 432 und 434 konzeptuell abhängig von der vorhergehenden Instruktionsdekodieroperation ist, nutzt eine Instruktionslängenvorausschaulogik 436 die vorhergegangen Bits, um zu ermöglichen, dass die Dekodierer im wesentlichen parallel arbeiten.
Der Langdekoder 416 und der vektorisierende Dekoder 418 führen gemeinsam zwei parallele Dekodierungen von elf Instruktionsbytes aus, angenommen das erste Byte sei Opcode-Byte, und erzeugen entweder einen Langinstruktionsdekodierungs-Op-Quadrupel oder einen vektorisierten Dekodierungs-Op-Quadrupel. Von dem Langdekodierer 416 und dem vektorisierenden Dekodierer 418 analysierte Informationen umfasst die effektive Adressgröße, die effektive Datengröße, das derzeitige B-Bit und DF-Bit, jegliche Override-Operanden-Segmentregister und die logischen Adressen der nächsten zu dekodierenden sequentiellen und Zielinstruktionen. Der lange Dekoder 416 und der vektorisierende Dekoder 418 erzeugen Dekodierungssignale umfassend ein die Instruktionslänge ausnehmendes vorangehendes Präfix-Bit, eine Feststellung, ob die Instruktion sich innerhalb des Langdekodierungs-Untersatzes der Instruktionen befindet, eine RET-Instruktion und ein effektives Operandensegmentregister, und zwar basierend auf einem Vorgabewert, der in dem modr/m-Adressmodus und jeglichem Segment- Override enthalten ist.
Während eines Dekodierungszyklus, in welchem keiner der Kurz-Dekodierer SDec0 410, SDec1 412 und SDec2 414 eine Kurzinstruktion erfolgreich dekodiert, versucht der Makroinstruktionsdekodierer 230, eine lange Dekodierung mittels des Langdekodierers 416 auszuführen. Wenn eine lange Dekodierung nicht ausgeführt werden kann, wird eine vektorielle Dekodierung ausgeführt. In einigen Ausführungsbeispielen sind die Lang- und vektorisierenden Dekoder 416 und 418 konzeptuell getrennte und unabhängige Dekodierer, genau so wie die Lang- und vektorisierende Dekodierer 416 und 418 getrennt und unabhängig von den Kurzdekodierern 410, 412 und 414 sind. Physikalisch jedoch teilen die Lang- und vektorisierenden Dekoder 416 und 418 viel Logik und erzeugen ähnliche Operations-Quadrupel-Ausgänge. Von dem Langdekoder 416 dekodierte Instruktionen sind generell in dem Kurzdekodierungs-Untersatz von Instruktionen enthalten, mit Ausnahme einer Adressmodus-Beschränkung derart, dass die Instruktion nicht von einem Kurz-Dekodierer dekodiert werden kann, weil die Instruktionslänge größer ist als sieben Bytes oder weil die Adresse einen großen Versatz aufweist, der die Erzeugung einer dritten Operation zur Behandlung dieses Versatzes erfordern würde. Der Langdekodierer 416 dekodiert auch gewisse zusätzliche modr/m-Instruktionen, welche nicht in dem Kurzdekodierungs- Untersatz vorhanden sind, aber hinreichend üblich sind, um eine Hardware- Dekodierung sicherzustellen. Instruktionsbytes zur Benutzung oder zur Dekodierung durch den Langdekodierer 416 werden von dem Instruktionspufferspeicher 408 durch den ersten Byterotator 430 zugefügt, dies ist derselbe Instruktionsmultiplexer, der Instruktionsbytes an den ersten Kurz-Dekodierer SDec0 410 liefert. Während jedoch der erste Kurz-Dekodierer SDec0 410 nur sieben Bytes empfängt, empfängt der Langdekodierer 416 bis zu elf aufeinanderfolgende Instruktionsbytes, was der maximalen Länge einer modr/m-Instruktion ohne Präfix-Bytes entspricht. Daher hat der erste Byterotator 430 eine Breite von elf Bytes, obwohl lediglich die ersten sieben Bytes mit dem ersten Kurz-Dekodierer SDec0 410 verbunden sind. Der Langdekodierer 416 dekodiert nur eine Instruktion zu einem Zeitpunkt, so dass dazugehörige Vordekodierungsinformation innerhalb des Instruktionspufferspeichers 408 nicht benutzt wird und typischerweise ungültig ist.
Ein erstes Byte des ersten Byterotators 430 wird voll als ein Opcode-Byte dekodiert und in dem Fall einer modr/m-Instruktion werden das zweite Instruktionsbyte und möglicherweise das dritte voll als modr/m- bzw. sib- Bytes dekodiert. Die Existenz eines 0F-Präfixes wird berücksichtigt, indem das Opcode-Byte dekodiert wird. Das 0F-Präfix-Byte unterbindet alle Kurzdekodierungen, da alle Kurzdekodierungsinstruktionen keine 0F- oder "1-Byte"-Opcodes sind. Da alle Präfix-Bytes innerhalb des "1-Byte"-Opcode- Raums angeordnet sind, erzwingt das Dekodieren eines 0F-Präfixes den nächsten Dekodierungszyklus eine 2-Byte-Opcode-Instruktion zu sein, wie eine Lang- oder vektorisierte Dekodierungsinstruktion. Zusätzlich zur Erzeugung von Operationen, basierend auf der Dekodierung von modr/m- und sib-Bytes bestimmt der erste Byterotator 430 auch die Länge der Instruktion zur Benutzung durch verschiedene Programmzähler, ob die Instruktion eine modr/m-Instruktion zum Unterbinden oder Ungültigmachen der Langdekodierung ist und ob die Instruktion eine Instruktion innerhalb des Langdekodierungs-Untersatzes von Operationscodes (Opcodes) ist. Der Langdekoder 416 erzeugt immer vier Operationen und stellt, wie die Kurz-Dekodierer 410, 412 und 414, die Operationen in Form eines emulationscodeähnlichen Op-Quadrupels ohne ein OpSeq-Feld bereit. Der Langdekodierer 416 verarbeitet lediglich relativ einfache modr/m-Instruktionen. Ein Lang- Dekodierungs-Op-Quadrupel hat zwei mögliche Formen, die sich nur darin unterscheiden, ob die dritte Operation eine Ladeoperation (LdOp) oder eine Speicheroperation (StOp) ist und ob die vierte Operation eine RegOp oder eine NOOP ist. Ein erster Langdekodierungs-Op-Quadrupel hat die Form:
LIMM t2,< imm32>
LIMM t1,< disp32>
LD.b/d Fehler! Textmarke nicht definiert.
< RegOp> ...
Ein zweiter Langdekodierungs-Op-Quadrupel hat die Form:
LIMM t2,< imm32>
LIMM t1,< disp32>
ST.b/d @(< gam> ),t2L/t2,OS.a
NOO P
Die @(< gam> )-Adressmodusspezifikation repräsentiert eine Adressberechnung, welche derjenigen entspricht, die von den modr/m- und/oder sib- Bytes der Instruktion angegeben wird, beispielsweise @(AX + BX * 4 + LD). Die < imm32> und < disp32> -Werte sind vier Bytewerte, welche die unmittelbaren und versetzten Instruktionsbytes enthalten, wenn die dekodierte Instruktion solche Werte beinhaltet.
Der Langdekoder 416 erzeugt, wie der erste Kurzdekoder 410, Operationen unter Berücksichtigung des Vorhandenseins von jeglichen Präfix-Bytes, die von den Kurzdekodierern während der vorhergehenden Dekodierungszyklen dekodiert worden sind. Die effektive Adressgröße, die Datengröße, die Operandensegmentregisterwerte und die derzeitigen B-Bits werden an den Langdekoder 416 ausgegeben und werden benutzt, um Operationen zu erzeugen. Keine indirekten Größen oder Segmentregisterspezifikatoren sind in den von dem Langdekodierer 416 erzeugten letzten Operationen enthalten.
Lediglich wenige Bedingungen verhindern eine ansonsten erfolgreiche lange Dekodierung oder machen sie ungültig. Eine derartige Bedingung ist ein Instruktionsoperationscode (Opcode), der nicht in dem langen Dekodierungs-Untersatz von Instruktionen enthalten ist. Eine zweite Bedingung ist, dass nicht alle der Instruktionspufferspeicher 408 Bytes für die dekodierte Instruktion gültig sind.
Der vektorisierende Dekoder 418 handhabt Instruktionen, welche weder von den Kurzdekodierern noch von dem Langdekodierer 416 dekodiert worden sind. Vektorisierte Dekodierungen sind ein Standardfall, wenn keine kurzen oder langen Dekodierungen möglich sind und hinreichend gültige Bytes verfügbar sind. Typischerweise sind die von dem vektorisierten Dekodierer 418 gehandhabten Instruktionen nicht in den Kurzdekodierungs- oder Langdekodierungs-Untersätzen enthalten, sondern stammen von anderen Bedingungen, wie denen, dass die Dekodierung nicht ermöglicht ist oder der Detektion einer Ausnahmebedingung. Während des normalen Betriebs werden lediglich nicht-kurz- und nicht-lang-Instruktionen vektorisiert. Jedoch können alle Instruktionen vektorisiert werden. Nicht definierte Opcodes werden übervektorisiert. Nur Präfix-Bytes werden immer dekodiert. Präfix- Bytes werden immer von den Kurzdekodierern 410, 412 und 414 dekodiert.
Wenn eine Ausnahmebedingung während eines Dekodierungszyklus entdeckt wird, wird eine vektorisierte Dekodierung erzwungen, die generell den Vorrang hat, vor jeder anderen Form von Dekodierung ohne Berücksichtigung der Gültigkeit der Instruktionsbytes für die dekodierte Instruktion. Wenn eine entdeckte Ausnahmebedingung einen vektorisierten Dekodierzyklus erzwingt, ist der erzeugte Op-Quadrupel undefiniert und das Op- Quadrupel-Gültigkeitsbit zur Darstellung für die Planungseinheit 260 wird auf null gezwungen. Das Op-Quadrupel-Gültigkeitsbit informiert die Planungseinheit 260, dass keine Operationen in die Planungseinheit 260 zu laden sind. Als Ergebnis wird kein Operations-Quadrupel in die Planungseinheit 260 geladen während eines vektorisierten Dekodierungszyklus.
Wenige Bedingungen verhindern ein vektorisiertes Dekodieren oder machen es ungültig. Eine solche Bedingung ist es, dass nicht alle der Bytes in dem Instruktionspufferspeicher 408 gültig sind.
Wenn eine Instruktion vektorisiert wird, wird die Steuerung an einen Emulationscode-Eintrittspunkt übertragen. Ein Emulationscode-Eintrittspunkt ist entweder einem internen Emulationscode-ROM 232 oder in einem externen Emulationscode-RAM 236. Der von der Eintrittspunktadresse startende Emulationscode emuliert entweder eine Instruktion oder initiiert eine angemessene Ausnahmeberechnung.
Ein vektorisierender Dekodierungszyklus ist korrekt betrachtet ein Dekodierungszyklus eines Makroinstruktionsdekodierer 230. In diesem Fall einer vektorisierenden Dekodierung erzeugt der Makroinstruktionsdekodierer 230 den vektorisierenden Quadrupel und erzeugt die Emulationscode-Adresse in dem Emulationscode-ROM 232. Infolge auf den ersten vektorisierenden Dekodierungszyklus verbleibt der Makroinstruktionsdekodierer 230 inaktiv, während die Instruktionen von dem Emulationscode-ROM 232 oder dem Emulationscode-RAM 236 erzeugt werden, bis eine von der Emulation zurückkehrende (ERET)-OpSeq angetroffen wird. Die von der Emulation zurückkehrende (ERET) sequenzierende Aktion führt zurück zu der Dekodierung durch den Makroinstruktionsdekodierer 230. Während der Dekodierungszyklen, die auf den ersten vektorisierenden Dekodierzyklus folgen, verbleibt der Makroinstruktionsdekodierer 230 inaktiv, wobei er kontinuierlich versucht, die nächste "sequenzielle" Instruktion zu dekodieren, jedoch werden die Dekodierzyklen wiederholt ungültig gemacht, bis das ERET eintritt, so dass standardgemäß darauf gewartet wird, die nächste "sequentielle" Instruktion zu dekodieren.
Instruktionsbytes zur Benutzung oder Dekodierung durch den vektorisierenden Dekoder 418 werden von dem Instruktionspufferspeicher 408 durch den ersten Byterotator 430 zugeführt, demselben Instruktionsmultiplexer, der den ersten Kurz-Dekodierer SDec0 410 und den ersten Langdekodierer 416 mit Instruktionsbytes versorgt. Der vektorisierende Dekodierer 418 empfängt bis zu elf aufeinanderfolgende Instruktionsbits, was der maximalen Länge einer modr/m-Instruktion ohne Präfix-Bytes entspricht. Entsprechend wird die volle Elf-Byte-Breite des ersten Byterotators 430 sowohl an den Langdekodierer 416 als auch an den vektorisierenden Dekodierer 418 verteilt. Die Vordekodierungsinformation innerhalb des Instruktionspufferspeichers 408 wird von dem vektorisierenden Dekodierer 418 nicht genutzt.
Wie in dem Fall des Langdekodierers 416 wird das erste Byte des ersten Byterotators 430 vollständig als eine Opcode-Byte dekodiert und in dem Fall einer modr/m-Instruktion werden das zweite Instruktionsbyte und möglicherweise das dritte vollständig als modr/m- bzw. sib-Bytes dekodiert. Der vektorisierende Dekodierer 418 erzeugt Operationen unter Berücksichtigung des Vorhandenseins jeglicher Präfix-Bytes, die von den Kurzdekodierern während vorhergehender Dekodierungszyklen dekodiert wurden. Das Vorhandensein eines 0F-Präfixes wird durch die Dekodierung des Opcode-Bytes berücksichtigt. Zusätzlich zum Erzeugen von Operationen basierend auf dem Dekodieren auf modr/m- und sib-Bytes bestimmt der erste Byterotator 430 auch die Länge der Instruktion zur Benutzung durch verschiedene Programmzähler, ob die Instruktion eine modr/m-Instruktion zum Unterdrücken oder Ungültigmachen des Langdekodierens ist, und ob die Instruktion eine Instruktion innerhalb des langen Dekodierungs-Untersatzes der Operationscodes (Opcodes) ist. Falls nicht, wird eine vektorisierende Dekodierung gestartet. Die effektive Adressgröße, die Datengröße und Operandensegmentregisterwerte werden an den vektorisierenden Dekodierer 418 geleitet und werden zur Erzeugung von Operationen benutzt. Keine indirekten Größen oder Segmentregisterspezifikatoren sind in den von dem vektorisierenden Dekodierer 418 erzeugten letzten Operationen enthalten.
Während eines vektorisierenden Dekodierungszyklus erzeugt der vektorisierende Dekodierer 418 einen vektorisierenden Op-Quadrupel, erzeugt einen Emulationscode-Eintrittspunkt oder eine Vektoradresse und initialisiert eine Emulationsumgebung. Der vektorisierende Op-Quadrupel ist dazu bestimmt, verschiedene Informationen weiterzuleiten, um Emulationsumgebungs-Notizregister zu initialisieren.
Der Wert des Emulationscode-Eintrittspunkt oder der Vektoradresse basiert auf einer Dekodierung der ersten und zweiten Instruktionsbytes, z. B. der Opcode- und modr/m-Bytes, als auch anderen Informationen, wie dem Vorhandensein eines 0F-Präfixes, eines REP-Präfixes oder ähnlichem. Für den fall, dass das Vektorisieren durch eine Ausnahmebedingung veranlasst wurde, basiert der Eintrittspunkt oder die Vektoradresse auf einem einfachen kodierten Ausnahmeidentifikator.
Die Emulationsumgebung wird gespeichert, um Abhängigkeiten der Umgebung aufzulösen. Jeder der Kurz-Dekodierer 410, 412 und 414 und der Langdekoder 416 lösen direkt Abhängigkeiten der Umgebung auf, wie Abhängigkeiten von den effektiven Adress- und Datengrößen, wenn die Operationen erzeugt werden, so dass diese Operationen niemals indirekte Größen oder Registerspezifikatoren enthalten. Die Emulationscode-Operationen verweisen jedoch auf derartige effektive Adress- und Datengrößenwerte für einen bestimmten Fall, in dem die Instruktion emuliert werden soll. Die Emulationsumgebung wird benutzt, um diese zusätzliche Information zu speichern, die sich auf die bestimmte zu vektorisierende Instruktion bezieht. Diese Information umfasst generell Registernummern, effektive Adress- und Datengrößen, eine effektive Operandensegmentregisternummer, den Präfix-Byte-Zähler und eine Aufzeichnung des Vorhandenseins eines LOCK-Präfixes. Die Emulationsumgebung lädt auch ein modr/m-reg- Feld und ein modr/m-regm-Feld in Reg- und Regm-Register. Die Emulationsumgebung wird am Ende eines erfolgreichen vektorisierenden Dekodierungszyklus initialisiert und verbleibt in dem ursprünglichen Zustand im wesentlichen für die Dauer der Emulation einer Instruktion durch den Emulationscode bis ein ERET-Code auftritt.
IDer Vektorisierungsdekodierer 418 erzeugt vier Operationen eines Operations-Quadrupel in einer von vier Formen. Alle vier Formen umfassen drei LIMM-Operationen. Die vier Formen unterscheiden sich nur durch die unmittelbaren Werte der vier LIMM-Operationen und ob die dritte Operation eine LEA-Operation oder eine NOOP-Operation ist.
Ein erster vektorisierende Dekodier-Op-Quadrupel hat die Form:
LIMM t2,< imm32>
LIMM t1,< disp32>
LEA t6,@(< gam> )._.a
Ein zweiter vektorisierender Dekodier-Op-Quadrupel hat die Form:
LIMM t2,< imm32>
LIMM t1,< disp32>
NOOP
LIMM t7,LogSeqDecPC[31..0)
Ein dritter vektorisierender Dekodier-Op-Quadrupel hat die Form:
LIMM t2,< +/- 1/2/4> //äquivalent zu "LDK(D)S t2, +1/+2"
LIMM t1,< +/- 2/4/8> //äquivalent zu "LDK(D)S t1, +2/+4"
NOOP
LIMM t7,LogSeqDecPC[31..0]
Ein vierter vektorisierender Dekodier-Op-Quadrupel hat die Form:
Die ersten beiden Formen von vektorisierenden Op-Quadrupeln sind auf die meisten Opcodes anwendbar. Die ersten Form wird für speicherverweisende modr/m-Instruktionen benutzt, für welche die LEA-Operation genutzt wird, um eine effektive Operandenadresse in einem generellen Adressmodus zu berechnen und in ein t-Register zu laden. Die zweite Form wird benutzt für nicht-modr/m- und registerverweisende modr/m-Instruktionen. Für Instruktionen mit der zweiten Form ist es nicht notwendig eine Adresse zu berechnen, obwohl die < imm32> -und < disp32> -Werte insoweit nutzbar bleiben, als dass sie dem Opcode-Byte folgende Instruktionsbytes enthalten. Die dritte Form von vektorisierenden Op-Quadrupeln wird für eine Zeicheninstruktionen sowie einige benachbarte nicht-modr/m-Instruktionen genutzt. Eine vierte Form von vektorisierenden Op-Quadrupeln unterstützt spezielle vektorisierende und Emulationserfordernisse für nahe RET-Instruktionen.
Der Makroinstruktionsdekodierer 230 hat vier Programmzähler, umfassend drei Dekodierungsprogrammzähler 420, 422 und 424, und einen Holen-Programmzähler 426. Ein erster Dekodierungsprogrammzähler, als Instruktions-PC 420 bezeichnet, ist die logische Adresse des ersten Bytes inklusiv jeglicher Präfix-Bytes von entweder der zu dekodierenden Instruktion oder, falls derzeit keine Instruktion dekodiert wird, der nächsten zu dekodierenden Instruktion. Wenn die Dekodierungsoperation eine Dekodierung mit vielfachen Instruktionen ist, zeigt der Instruktions-PC 420 auf die erste Instruktion der zu dekodierenden Mehrfachinstruktionen. Der Instruktions- PC 420 entspricht der architekturalen Adresse einer Instruktion und wird nutzt, um Instruktions-Fehler-Programmzähler zur Behandlung von Ausnahmen zu erzeugen. Der Instruktions-PC 420 wird zusammen mit entsprechenden Op-Quadrupeln zu der Planungseinheit 260 weitergegeben und wird benutzt bei einer Operationsausführungseinheit (OCU) (nicht gezeigt) der Planungseinheit 260, um Instruktions-Fehler-Programmzähler zu erzeugen, die während der Ausnahmeberechnung gespeichert werden. Wenn ein Operations-Quadrupel von dem Makroinstruktionsdekodierer 230 erzeugt wird, wird der Wert des derzeitigen Instruktions-PC 420 an den Operations- Quadrupel angehangen und gemeinsam mit dem Operations-Quadrupel in den Operations-Quadrupel-Eintrag der Planungseinheit 260 geladen. Ein zweiter Dekodierungsprogrammzähler, bezeichnet als logischer Dekodierungs-PC 422, ist die logische Adresse der nächsten zu dekodierenden Instruktionsbytes und adressiert entweder ein Opcode-Byte oder ein Präfix- Byte. Ein dritter Dekodierprogrammzähler, genannt linearer Dekodier-PC 422, ist die lineare Adresse des nächsten zu dekodierenden Instruktionsbytes und adressiert entweder ein Opcode-Byte oder ein Präfix-Byte. Der logische Dekodier-PC 422 und der lineare Dekodier-PC 424 zeigen auf dasselbe Instruktionsbyte. Der lineare Dekodier-PC 424 bezeichnet die Adresse des Instruktionsbytes, das sich derzeit bei dem ersten Byterotator 430 befindet.
Die verschiedenen Dekodierer in dem Makroinstruktionsdekodierer 230 funktionieren auf der Basis des Dekodierens oder Verbrauchens von entweder Präfix-Bytes oder ganzen Instruktionen ohne Präfix-Bytes, so dass Präfixes im allgemeinen als 1-Byte-Instruktionen behandelt werden. Daher sind die Adressgrenzen zwischen Instruktion und Präfix-Byte-Dekodierungen wichtiger als alleinige Instruktionsgrenzen. Entsprechend ist beim Anfang von jedem Dekodierzyklus das nächste zu dekodierende Instruktionsbyte nicht notwendigerweise der wirkliche Beginn einer Instruktion.
Am Anfang eines Dekodierungszyklus enthalten der logische Dekodier-PC 422 und der lineare Dekodier-PC 424 die logischen und linearen Adressen der nächsten zu dekodierenden Instruktion, entweder eine Instruktion oder ein Präfix-Byte. Der lineare Dekodier-PC 424 ist ein primärer Programmzählerwert, der während des Dekodierungsprozesses genutzt wird, um auf den Instruktionspufferspeicher 408 zuzugreifen. Der lineare Dekodier-PC 424 repräsentiert den Startpunkt für die Dekodierung eines Zyklus und steuert insbesondere den Byterotator, der Bytes von dem Instruktionspufferspeicher 408 an den ersten Kurz-Dekodierer 410 und an den Lang- und vektorisierenden Dekodierer 416 bzw. 418 zuführt. Der lineare Dekodier-PC 424 ist auch der Referenzpunkt zur Bestimmung der Instruktionsadressen von jeglichen weiteren Kurzdekodierungsinstruktionen oder Präfix-Bytes, er erzeugt also Steuersignale für die Byterotatoren, welche den zweiten und dritten Kurz-Dekodierer 412 und 414 versorgen.
Der lineare Dekodier-PC 424 agiert auch sekundär, um während des ersten Dekodierungszyklus einer neuen Instruktion bevor die Präfix-Bytes dekodiert werden, nach Breakpointübereinstimmungen zu suchen und um Überläufe des Codesegments durch den Makroinstruktionsdekodierer 230 während erfolgreicher Instruktionsdekodierzyklen zu überprüfen.
Der logische Dekodier-PC 422 wird benutzt für Transfersteuerinstruktionen, die mit Programmzählern zusammenhängen, inklusive CALL-Instruktionen. Der logische Dekodier-PC 422 wird an die Sprungeinheit 234 ausgegeben, um zur Berechnung einer Sprungzieladresse mit dem Versetzungswert einer PC-bezogenen Transfersteuerinstruktion summiert zu werden. Der logische Dekodier-PC 422 unterstützt die Emulation von Instruktionen mit einem Emulationscode. Der nächste sequentielle logische Dekodierprogrammzähler (PC) 422 ist für die allgemeine Benutzung im Emulationscode verfügbar, aus dem Speicher in einen temporären Register des vektorisierenden Op-Quadrupels. Z. B. wird der nächste sequentielle logische Dekodier-PC 422 benutzt, um eine Rückkehradresse auszugeben, die eine CALL-Instruktion zurück auf einen Stapel bringt.
Ein nächster logischer Dekodier-PC 428 wird auf den nächsten sequentiellen logischen Dekodierprogrammzählerwert gesetzt und hat eine Funktionalität, die über die des logischen Dekodier-PC 422 hinausreicht. Der nächste logische Dekodier-PC 428 stellt die Rückkehradresse für CALL-Instruktionen, die von dem Makroinstruktionsdekodierer 230 dekodiert worden sind, direkt bereit. Der nächste logische Dekodier-PC 428 wird auch über eine der Operationen innerhalb des vektorisierenden Op-Quadrupels zu der Emulationscode-Logik weitergeleitet während eines vektorisierenden Dekodierzyklus.
Während eines Dekodierzyklus zeigt der lineare Dekodier-PC 424 auf die nächsten zu dekodierenden Instruktionsbytes. Die vier niedrigstwertigen Bits des linearen Dekodier-PC 424 zeigen auf das erste Instruktionsbyte innerhalb des Instruktionspufferspeichers 408 und zeigen dabei direkt den Betrag der Byterotation an, die notwenig ist, um die ersten und darauffolgenden Instruktionsbytes in dem Instruktions-Cache-Speicher 214 auszurichten. Der erste Byterotator 430 ist ein Instruktionsmultiplexer, insbesondere ein 16 : 1-Byte-Multiplexer, zum Zugreifen auf Bytes in dem Instruktionspufferspeicher 408, welche um den Betrag des linearen Dekodier-PC 424 versetzt sind. Der erste Byterotator 430 hat eine Breite von sieben Bytes für den ersten Kurz-Dekodierer SDec0 410 und eine gemeinsame Breite von elf Bytes für den Langdekodierer 416 und den vektorisierenden Dekodierer 418. Eine geteilte Logik in dem ersten Kurz-Dekodierer SDec0 410, dem Langdekodierer 416 und dem vektorisierenden Dekodierer 418 erzeugt einen ersten Instruktionslängenwert ILen0 für die erste Instruktion. Der zweite und dritte Byterotator 432 und 434 sind Instruktionsmultiplexer mit einer Breite von sieben Byte, insbesondere 16 : 1-Byte-Multiplexer. Der zweite Byterotator 432 greift auf Bytes in dem Instruktionspufferspeicher 408 zu, welche um die Summe des Betrages des linearen Dekodier-PC 424 und der ersten Instruktionslänge ILen0 versetzt sind. Eine Logik in dem zweiten Kurz-Dekodierer SDec0 412 erzeugt einen zweiten Instruktionslängenwert ILen1 für die zweite Instruktion. Der dritte Byterotator 434 greift auf Bytes in dem Instruktionspufferspeicher zu, welche um die Summe des Betrages des linearen Dekodier-PC 424 und der ersten und zweiten Instruktionslängen ILen0 und ILen1 versetzt sind. Die Byterotatoren 430, 432 und 434 multiplexen Instruktionsbytes, aber keine Vordekodierbits. Die Byterotatoren 430, 432 und 434 werden mittels Vordekodierinformationen gesteuert, in welchen die zu dem ersten Opcode-Byte oder zu dem ersten Byte der ersten Instruktion zugehörigen Vordekodierbits den zweiten Rotator 432 direkt steuern. Das erste Byte der zweiten Instruktion steuert direkt den dritten Rotator 434. Jeder Vordekodiercode beinhaltet eine Instruktionslänge, was jedoch auf den nächsten Rotator angewendet wird, ist ein Zeiger. Der Zeiger wird abgeleitet, indem die vier niedrigstwertigen Bits des Programmzählers bei der vorliegenden Instruktion und der Länge genommen, um den Programmzähler zu der nächsten Instruktion zu bringen.
Alle Programmzähler 420, 422, 424 und 428 in dem Makroinstruktionsdekodierer 230 werden während der Verarbeitung der Instruktion und Ausnahme initialisiert. Eine Mehrzahl von Signalquellen aktiviert diese Initialisierung. Zuerst gibt die Sprungeinheit 234 eine Zielsprungadresse aus, wenn eine PC-bezogene Transfersteuerinstruktion dekodiert wird und als genommen vorhergesagt wird. Zweitens gibt ein Rückkehradressstapel (nicht gezeigt) eine vorhergesagte Rückkehrzieladresse aus, wenn eine nahe RET-Instruktion dekodiert wird. Drittens erzeugt die Planungseinheit 260 eine korrekte und abwechselnde Sprungadresse, wenn der Makroinstruktionsdekodierer 230 zusammen mit den übrigen Schaltungen in dem Prozessor 120 von der Planungseinheit 260 auf Grund einer fehlvorhergesagten Sprungbedingungs- (BRCON)Operation neu startet. Viertens gibt die Registereinheit 244, die primäre RegOp-Ausführungseinheit, eine neue Dekodieradresse aus, wenn eine WRIP-RegOp ausgeführt wird. Die WRIP-RegOp-Ausführung erlaubt es dem Emulationscode, die Instruktionsdekodierung explizit umzulenken. In allen vier Fällen wird eine logische Adresse ausgegeben und benutzt, um die drei Dekodierprogrammzähler 420, 422 und 424 gleichzeitig neu zu initialisieren. Für den linearen Dekodier-PC 424 wird ein linearer Adresswert ausgegeben, indem die ausgegebene logische Adresse zu der aktuellen Basisadresse des Codesegments hinzu addiert wird, um die entsprechende lineare Adresse zum Laden in den linearen Dekodier-PC 424 zu erzeugen. Die logische Adresse wird in den derzeitigen Instruktions-PC 422 und den logischen Dekodier-PC 422 geladen. Für jeden Dekodierungszyklus erneuert der Makroinstruktionsdekodierer 230 bis zur nächsten Neuinitialisierung den aktuellen Instruktions-PC 420, den logischen Dekodier-PC 422 und den linearen Dekodier-PC 424 sequentiell und synchron, so lange die Instruktionsbytes von den individuellen Dekodierern des Makroinstruktionsdekodierers 230 erfolgreich dekodiert und verbraucht werden.
Die Erzeugung der Instruktionslängen Ilen0 und Ilen1 geschieht seriell. Um diesen seriellen Prozess durch Emulation einer parallelen Operation zu beschleunigen, bestimmt die Instruktionslängen-Vorausschaulogik 436 schnell die Instruktionslängen Ilen0 und Ilen1 unter Benutzung von vier Vordekodierbits, welche die Länge von jedem Instruktionsbyte in dem Instruktionspufferspeicher 408 angeben. Die zu dem Opcode-Byte des ersten Instruktionsbytes in dem Instruktionspufferspeicher 408 zugehörigen Vordekodierbits, wobei das Instruktionsbyte von dem ersten Kurz-Dekodierer SDec0 410 multiplext wird, bestimmen direkt einen Byteindex des Opcode- Bytes des zweiten Instruktionsbytes in dem Instruktionspufferspeicher 408. Die zu dem Opcode-Byte des zweiten Instruktionsbytes in dem Instruktionspufferspeicher 408 gehörenden Vordekodierbits, wobei das zweite Instruktionsbyte zu dem zweiten Kurz-Dekodierer SDec1 412 multiplext wird, geben direkt einen Byteindex des Opcode-Bytes des dritten Instruktionsbytes in dem Instruktionspufferspeicher 408 an. Die Instruktionslängen-Vorausschaulogik 436 umfasst zwei 16 : 1-Multiplexer mit einer Breite von vier Bit zum Erzeugen der Byteindizes der Opcode-Bytes der zweiten und dritten Instruktionsbytes in dem Instruktionspufferspeicher 408.
Die Instruktions-Vorausschaulogik 436 beinhaltet auch eine Logik zum Bestimmen der Gültigkeit der Sätze von Vordekodierbits. Vordekodierbits sind gültig, wenn das dazugehörige Instruktionsbyte der Beginn einer gültigen Kurzdekodierinstruktion ist. Speziell bestimmte die Instruktions-Vorausschaulogik 436, ob die Vordekodierbits für ein gegebenes Byte in dem Instruktionspuffer 408 auf dasselbe Byte zeigen, was eine Länge von null für eine an diesem Byte startende Instruktion bedeutet. Ist dies der Fall, dann ist das Byte nicht der Beginn einer Kurzdekodierinstruktion und kein weiteres Kurzdekodieren ist möglich. Ansonsten ist eine Kurzdekodieroperation möglich und die Vordekodierbits zeigen auf den Beginn der nächsten Instruktion.
Der zwischen dem Hauptspeicher 130 und dem Instruktions-Cache-Speicher 214 angeschlossene Vordekodierer 270 hat acht logische Einheiten, von denen jede seine dazugehörigen Instruktionsbytes untersucht und auch in einigen Fällen die folgenden ein oder zwei Instruktionsbytes. Das erste Instruktionsbyte wird als ein Opcode-Byte dekodiert und die zweiten und dritten Instruktionsbytes werden, falls das Opcode-Byte ein modr/m-Opcode ist, als modr/m- und sib-Bytes dekodiert. Basierend auf diesen drei Bytes wird die Länge einer Instruktion bestimmt und ob die Instruktion als eine "kurze" Instruktion klassifiziert ist. Die Länge der Instruktion wird zu einem Wert mit einer fixen Länge von vier Bit addiert, der der Position der Logikeinheit im Hinblick auf die sechszehn Logikeinheiten entspricht, um den von der Instruktionslängen-Vorausschaulogik 436 benutzten Byteindex zu bestimmen. Dieser Byteindex wird auf den Wert der Vordekodierbits gesetzt, wenn die Instruktion die Kriterien für eine kurze Instruktion erfüllt. Für Instruktionsbytes, welche die Kriterien der kurzen Instruktion nicht treffen, werden die Vordekodierungsbits auf den festen vier Bit-Wert, der der Position der Logikeinheit im Hinblick auf die sechszehn Logikeinheiten entspricht, ohne eine Erhöhung gesetzt, um die Instruktionslänge von null festzuschreiben. Eine angenommene Instruktionslänge von null zeigt an, dass die Instruktion keine kurze Instruktion ist. Die Vordekodierbits werden von vier Bits auf drei Bits abgeschnitten, weil Kurzdekodierinstruktionen niemals länger als sieben Bytes sind und das höchstwertige Bit leicht aus den drei Vordekodierbits und den dazugehörigen festen Byteadressen rekonstruiert werden kann. Die Expansion von drei auf vier Vordekodierbits wird von der Vordekodier-Expansionslogik 440 ausgeführt, welche sechszehn Logikeinheiten hat, entsprechend den sechszehn Instruktionsbytes des Instruktions-Cache-Speichers 214. Die sechszehn Logikeinheiten der Vordekodierungs-Expansionslogik 440 arbeiten unabhängig und gleichzeitig an den Vordekodierbits, wenn die Instruktionsbytes aus dem Instruktions- Cache-Speicher 214 zu dem Instruktionspufferspeicher 40 geholt werden.
Die letzten beiden der 32 Instruktionsbytes, welche vordekodiert und in den Instruktions-Cache-Speicher 214 geladen werden, haben lediglich ein oder zwei Bytes zur Untersuchung durch den Vordekodierer 270. Für modr/m- Opcodes kann die ganze Länge der Instruktion nicht bestimmt werden. Daher werden die Logikeinheiten für die Bytes 14 und 15 in dem Vordekodierer 270 modifiziert von den Logikeinheiten für die Bytes 0 bis 13. Für das Instruktionsbyte 15 erzwingt die Logikeinheit 15 des Vordekodierers 270 eine Instruktionslänge von null für alle modr/m-Opcodes und für nicht-kurze Dekodierinstruktionen. Für das Instruktionsbyte 14 wird eine effektive Instruktionslänge von null erzwungen, für modr/m-Opcodes mit einem Adressmodus, welche die Untersuchung eines sib-Bytes erfordert, um die Länge der Instruktion verlässlich zu bestimmen, dies ist auch der Fall für nicht-kurze Instruktionen.
Während jedes Dekodierzyklus überprüft der Makroinstruktionsdekodierer 230 auf verschiedene Ausnahmebedingungen, umfassend einen Breakpoint für eine Instruktion, einen anhängenden nicht maskierbaren Interrupt (NMI), einen anhängigen Interrupt (INTR), einen Überlauf eines Codesegments, einen Instruktionshol-Seitenfehler, eine Instruktionslänge größer als sechszehn Bytes, eine nicht festsetzbare Instruktion mit einem LOCK-Präfix, eine Bedingung, bei der ein Gleitkomma nicht verfügbar ist, und eine anhängige Gleitpunktfehlerbedingung. Einige Bedingungen werden nur während eines erfolgreichen Dekodierzyklus bewertet, andere Bedingungen werden unabhängig von jeglicher Dekodiertätigkeit werden des Zyklus bewertet. Wenn eine aktive Ausnahmebedingung detektiert wird, werden alle Instruktionsdekodierzyklen, umfassend kurze, lange und vektorisierende Dekodierzyklen, unterdrückt und eine "Ausnahme" vektorisierende Dekodierung wird erzwungen, in dem der Entdeckung der Ausnahme folgenden Dekodierzyklus. Die Erkennung einer Ausnahmebedingung wird nur aufgehoben oder unterdrückt durch Inaktivität des Makroinstruktionsdekodierers 230, wenn beispielsweise Op-Quadrupel mit Emulationscode von der Planungseinheit 260 angenommen werden, anstelle von Operations-Quadrupeln mit kurzer und langer oder vektorisierender Dekodierung. Dies bewirkt, dass die Erkennung und die Handhabung von jeglichen Ausnahmebedingungen verzögert wird, bis eine ERET Op Seq die Steuerung an den Makroinstruktionsdekodierer 230 zurückgibt.
Während des Dekodierungszyklus, der eine Ausnahmevektorisierung erzwingt, wird eine spezielle Emulationscode-Vektoradresse anstatt einer normalen Instruktions-Vektoradresse erzeugt. Das vektorisierende Op-Quadrupel, das von dem Lang- und vektorisierenden Dekodierer 416 und 418 erzeugt wird, ist undefiniert. Die Ausnahme-Vektoradresse ist ein fester Wert, bis auf die Bits mit niedrigem Rang, zum Identifizieren der bestimmten Ausnahmebedingungen, die erkannt und behandelt wird. Wenn mehrere Ausnahmebedingungen gleichzeitig detektiert werden, werden die Ausnahmen in einer Reihenfolge der Priorität geordnet und die Ausnahme mit der höchsten Priorität wird erkannt.
Die Instruktions-Breakpoint-Ausnahme, die Ausnahmebedingung mit der höchsten Priorität, wird erkannt, wenn der lineare Dekodier-PC 424 auf das erste Byte einer Instruktion mit Präfixes zeigt, der lineare Dekodier-PC 424 einer Breakpoint-Adresse entspricht, die als Instruktions-Breakpoint freigegeben ist, und keine der Instruktions-Breakpoint-Maskierungsflags frei sind. Eine Maskierungsfiag (RF) maskiert speziell die Erkennung eines Instruktions-Breakpoints. Eine andere Maskierungsfiag (BNTF) maskiert zeitweise NMI-Anfragen und Instruktions-Breakpoints.
Die anhängige NMI-Ausnahme, die Ausnahme mit der zweithöchsten Priorität, wird erkannt, wenn eine NMI-Anfrage anhängig ist und keine der NMI- Maskierungsflags frei sind. Eine Maske (NF) maskiert speziell nicht maskierbare Interrupts. Eine andere Maskierungsfiag (BNTF) maskiert NMI-Anfragen und Instruktions-Breakpoints temporär.
Die anhängige INTR-Ausnahme, die nächste Ausnahme, die der anhängigen NMI-Ausnahme in der Priorität folgt, wird erkannt, wenn eine INTR-Anfrage anhängig ist und die Interruptflag (IF) und die temporäre Interruptflag (ITF) frei sind.
Die Codesegment-Überlaufausnahme, die nächste Ausnahme, die in der Priorität der anhängigen INTR-Ausnahme folgt, wird erkannt, wenn der Makroinstruktionsdekodierer 230 versucht, einen Satz von Instruktionen erfolgreich zu dekodieren über ein derzeitiges Limit des Codesegments hinaus.
Die Instruktionshol-Seitenfehlerausnahme, die eine Priorität unmittelbar niedriger als die Codesegment-Überlaufausnahme hat, wird erkannt, wenn der Makroinstruktionsdekodierer 230 zusätzliche gültige Instruktionsbytes von dem Instruktionspuffer 4098 erfordert, bevor das Dekodieren eines weiteren Instruktions- oder Präfix-Bytes möglich ist, und der Instruktions- Übersetzungs-Seitenblickpuffer (ITB) anzeigt, dass eine Seitenfehler aufgetreten ist, bei dem derzeitigen Holen einer Instruktion. Eine fehlerhafte Bedingung bei der Instruktionsholsteuerschaltung 218 wird wiederholt versucht, so dass der ITB kontinuierlich einen Seitenfehler meldet, bis der Seitenfehler von dem Makroinstruktionsdekodierer 230 erkannt wird und die darauffolgende Ausnahme-Handhabungsberechnung das Holen der Instruktion stoppt und zu einer neuen Adresse umleitet. Die Fehleranzeige von dem ITB hat denselben Zeitpunkt wie die von dem Instruktions-Cache-Speicher 214 geladenen Instruktionen und wird daher in dem darauffolgenden Dekodierzyklus bemerkt. Der ITB signalisiert nicht notwendigerweise einen Fehler bei aufeinanderfolgenden Versuchen, eine Instruktion zu holen, so dass der Makroinstruktionsdekodierer 230 die Fehleranzeige hält, bis das Holen auf eine neue Instruktionsadresse umgeleitet ist. Auf die Erkennung eines Seitenfehlers hin wird eine zusätzliche Fehlerinformation in ein spezielles Registerfeld geladen.
Die Ausnahm, bei der die Instruktionslänge größer als sechszehn Bytes ist, welche eine Priorität gerade unterhalb der Instruktionshol-Seitenfehlerausnahme, wird erkannt, wenn der Makroinstruktionsdekodierer 230 versucht, eine Instruktion mit einer gesamten Länge inklusive der Präfix-Bytes von mehr als fünfzehn Bytes erfolgreich zu dekodieren. Die Ausnahme, bei der die Instruktionslänge größer als sechszehn Bytes ist, wird detektiert durch das Zählen der Anzahl der Präfix-Bytes bevor eine tatsächliche Instruktion dekodiert wird und durch das Berechnen der Länge des Rests der Instruktion, wenn diese dekodiert wird. Wenn die Summe der Präfix-Bytes und der verbleibenden Instruktionslänge größer ist als sechszehn Bytes wird ein Fehler erkannt.
Die Ausnahme einer nicht verschließbaren Instruktion mit einem LOCK-Präfix, welche eine Priorität unterhalb des Fehlers der Instruktionslänge hat, wird erkannt, wenn der Makroinstruktionsdekodierer 230 versucht, eine Instruktion mit einem LOCK-Präfix erfolgreich zu dekodieren, wobei die Instruktion nicht in dem verschließbaren Instruktions-Untersatz enthalten ist. Die Ausnahme der nicht verschließbaren LOCK-Instruktionsausnahme wird detektiert, basierend auf der Dekodierung eines Opcode-Bytes und dem Vorhandenseins eines 0F-Präfixes. Die nicht verschließbare LOCK-Instruktionsausnahme tritt nur auf während vektorisierender Dekodierzyklen, weil das LOCK-Präfix kurze und lange Dekodierungen unterdrückt.
Die Ausnahme, bei der ein Gleitkomma nicht verfügbar ist, hat die zweitniedrigste Priorität, wird erkannt, wenn der Makroinstruktionsdekodierer 230 versucht, eine WAIT-Instruktion oder eine ESC-Instruktion, was ein prozessorgesteuertes ESC ist, erfolgreich zu dekodieren und die Meldung eines Gleitkommafehlers anhängig ist. Der Makroinstruktionsdekodierer 230 detektiert die Ausnahme, bei der das Gleitkomma nicht verfügbar ist, basierend auf der Dekodierung eines Opcode- und modr/m-Bytes, zusätzlich zu dem Vorhandensein eines 0F-Präfixes.
Während jedes Dekodierungszyklus versucht der Makroinstruktionsdekoder 230 irgendeine Form der Instruktionsdekodierung von einer oder mehreren Instruktionen durchzuführen. Typischerweise ist der Makroinstruktionsdekodierer 230 erfolgreich in der Ausführung entweder einer einzelnen oder vielfachen Kurzdekodierung, einer Langdekodierung oder einer eine Instruktion vektorisierenden Dekodierung. Gelegentlich ist keine Dekodierung erfolgreich, auf Grund drei Typen von Bedingungen, umfassend die Detektion einer aktiven Ausnahmebedingung, dem Fehlen einer ausreichenden Anzahl von gültigen Bytes in dem Instruktionspufferspeicher 408 oder der Makroinstruktionsdekodierer 230 bewegt sich auf Grund eines externen Grundes nicht weiter.
Wenn eine aktive Ausnahmebedingung entdeckt worden ist, werden alle Formen der Instruktionsdekodierung unterdrückt und während des zweiten Dekodierzyklus nach der Detektion der Ausnahmebedingungen wird ein Ausnahme-Vektorisierungsdekodierungs-Zyklus erzwungen, der einen ungültigen Op-Quadrupel erzeugt.
Wenn eine nicht ausreichende Anzahl von gültigen Bytes in dem Instruktionspufferspeicher 408 verfügbar ist, werden entweder keine gültigen Bytes in dem Instruktionspufferspeicher 408 gehalten oder zumindest der erste Opcode ist gültig und einer der Dekoder dekodiert die Instruktion, jedoch erfordert die dekodierte Instruktionslänge weitere gültige Bytes aus dem Instruktionspufferspeicher 408, von denen zur Zeit nicht alle verfügbar sind.
Wenn ein externer Grund ein Weiterlaufen des Makroinstruktionsdekodierers 230 verhindert, ist entweder die Planungseinheit 260 voll und es ist ihr nicht möglich, einen zusätzlichen Op-Quadrupel während eines Dekodierzyklus zu akzeptieren, oder die Planungseinheit 260 akzeptiert zur Zeit Op-Quadrupel mit Emulationscode, so dass der Makroinstruktionsdekodierer 230 inaktiv ist, während er darauf wartet, zur Dekodierung zurückzukehren.
In den letzten beiden Fällen wird der Dekodierungszustand des Makroinstruktionsdekodierers 230 vom Weiterlaufen abgehalten und der Makroinstruktionsdekodierer 230 versucht einfach dieselben Dekodierungen in dem nächsten Dekodierungszyklus. Die Steuerung der Hemmung des Makroinstruktionsdekodierers 230 basiert auf der Erzeugung eines Satzes von Dekodierer-Gültig-Signalen mit einem Signal entsprechend für jeden der Dekoder. Für jeden Dekoder existieren mehrere Gründe, welche zu Dekodierer-Gültig-Signalen kombiniert werden, um zu bestimmen, ob der Dekoder fähig ist, eine Dekodierung erfolgreich auszuführen. Die Dekodierer-Gültig- Signale für alle der Dekodierer werden gemeinsam überwacht, um den Typ des auszuführenden Dekodierungszyklus festzustellen. Der Typ des Dekodierungszyklus gibt den bestimmten Dekoder an, der die Dekodierung ausführen soll. Die externen Betrachtungen werden auch abgeschätzt, um festzustellen, ob der ausgewählte Typ des Dekodierungszyklus zum Ziel führt. Signale, die den ausgewählten Typ des Dekodierungszyklus anzeigen, wählen zwischen verschiedenen von den verschiedenen Dekodierern erzeugten im Makroinstruktionsdekodierer 230 internen Signalen aus, wie alternativen nächste Dekodierung-PC-Werten und werden auch angewählt, um einen Op- Quadrupel-Multiplexer 444 zu steuern, welcher den Eingangs-Op-Quadrupel, der an die Planungseinheit 260 weitergegeben wird, aus den von den Kurzdekodierern, dem Langdekodierer 416 und dem vektorisierenden Dekodierer 418 erzeugten Op-Quadrupeln auswählt.
In dem Fall von vektorisierenden Dekodierzyklen erzeugt der Makroinstruktionsdekodierer auch Signale, welche das Vektorisieren zu einem Eintrittspunkt in entweder dem internen Emulationscode-ROM 232 oder dem externen Emulationscode-RAM 236 startet. Der Makroinstruktionsdekodierer 230 überwacht dann die aktive Dauer des Holens des Emulationscodes und des Ladens in die Planungseinheit 260.
Der Instruktionsdekodierer 220 enthält eine Sprungeinheit (nicht gezeigt) zum Ausführen von Sprungvorhersagen, so dass Operationen spekulativ ausgeführt werden. Die Leistungsfähigkeit eines Out-Of-Order-Prozessors wird gesteigert, wenn Sprünge schnell und akkurat gehandhabt werden, so dass die Pipeline-auszehrende Fehlvorhersagen vermieden werden. Der Prozessor 120 verwendet einen zweistufigen Sprungvorhersagealgorithmus, der detailliert beschrieben ist in US-Patent Nr. 5,454,117 mit dem Titel "CONFIGURABLE BRANCH PREDICTION FOR A PROCESSOR PERFORMING SPECULATIVE EXECUTION" (Puziol et al., 26. September 1995), US-Patent Nr. 5,327,547 mit dem Titel "TWO-LEVEL BRANCH PREDICTION CACHE" (Stiles et al. 5. Juli 1994), US-Patent Nr. 5,163,140, mit dem Titel "TWO- LEVEL BRANCH PREDICTION CACHE" (Stiles et al. 10. November 1992), US- Patent Nr. 5,093,778 mit dem Titel "INTEGRATED SINGLE STRUCTUR BRANCH PREDICTION CACHE" (Favor et al. 3. März 1993). Der Prozessor 120 benutzt weiterhin eine Sprung-Geschichte-Tabelle (BHT) mit 8.192 Einträgen (nicht gezeigt), welche indiziert wird durch die Kombination von vier Programmcounter-Bits mit neun Bits einer globalen Sprunggeschichte. Jeder BHT-Eintrag enthält zwei Geschichtsbits. Das BHT ist ein RAM mit zwei Anschlüssen, was sowohl einen Lese-/Nachschlagzugriff als auch einen Schreib-/Aktualisierungszugriff erlaubt. BHT-Nachschläge und -Aktualisierungen geraten nicht in Konflikt, da sie in entgegengesetzten Halbphasen des Taktzyklus stattfinden. Die große Anzahl von Einträgen in dem BHT wird 11n einem ansehnlichen Bereich der integrierten Schaltung bereitgestellt, weil die BHT nur bedingte Sprungrichtungen vorhersagt, so dass die Einträge nicht bezeichnet werden und vorhergesagte Sprung-Zieladressen werden nicht gespeichert, mit der Ausnahme für einen Rückkehradress-Stapel mit sechszehn Einträgen (nicht gezeigt). Entsprechend ist ein Zugriff auf die BHT ähnlich zu einem direkten Abbilden in eine Cache-Speicherähnliche Struktur, in welcher die BHT indiziert wird, um auf einen Eintrag in der BHT zuzugreifen, wobei angenommen wird, dass der angesprochene Eintrag eine Sprunginstruktion sein. Für Sprünge, die nicht zurückkehren, wird die Zieladresse während des Dekodierzyklus berechnet. Die Zieladresse wird mit ausreichender Geschwindigkeit berechnet unter Benutzung einer Mehrzahl von parallelen Addierern (nicht gezeigt), welche alle möglichen Zieladressen berechnen, bevor der Ort einer Sprunginstruktion bekannt ist. Am Ende des Dekodierungszyklus bestimmt die Sprungeinheit 234, welches, wenn überhaupt eines, der Zieladress-Ergebnisse gültig ist.
Wenn ein Sprung als genommen vorhergesagt wird, ist die Zieladresse unmittelbar bekannt und die Zielinstruktionen werden in dem folgenden Zyklus geholt, was eine Verzögerung von einem Takt für den genommenen Sprung verursacht. Die Verzögerung für den genommenen Sprung wird durch die Benutzung eines Sprungzielpufferspeichers (BTB) 456 verhindert. Der BTB 456 hat sechszehn Einträge und jeder Eintrag hat sechszehn Instruktionsbytes mit dazugehörigen Vordekodierungsbits. Der BTB 456 wird über die Sprungadresse indiziert und auf sie wird während des Dekodierungszyklus zugegriffen. Instruktionen aus dem BTB 456 werden an den Instruktionsdekodierer 220 gesendet, wodurch die Verzögerung für den genommenen Sprung für einen Cache-Speichertreffer des BTBs 456 eliminiert wird, wenn die BHT (nicht gezeigt) einen genommenen Sprung vorhersagt.
Während jedes Dekodierungszyklus wird der lineare Dekodier-PC 424 auf eine direkt abgebildete Weise benutzt, um den BTB 456 zu adressieren. Wenn ein Treffer, welcher vor dem Ende des Dekodierzyklus festgestellt wird, mit einem BTB-Eintrag auftritt, wird eine mit einem PC zusammenhängende bedingte Transfersteuerinstruktion von einem Kurz-Dekodierer dekodiert und der Steuertransfer wird als genommen vorhergesagt, dann treten zwei Aktionen auf. Erstens wird die auf den Instruktions-Cache-Speicher 214 gerichtete ursprüngliche Ziel-Linearhol-Adresse von der wirklichen Zieladresse zu einem Wert geändert, welcher auf ein Instruktionsbyte zeigt, welches den in dem BTB-Eintrag enthaltenen gültigen Zielbytes direkt folgt. Diese modifizierte Hol-Adresse ist in dem BTB-Eintrag enthalten und direkt von dem BTB-Eintrag angesprochen. Zweitens wird die Instruktionsbyte- und Vordekodierungsinformation aus dem Eintrag in den Instruktionspufferspeicher 408 am Ende des Dekodierungszyklus geladen. Wenn eine PC-bezogene bedingte Transfersteuerinstruktion von einem Kurz-Dekodierer dekodiert wird und der Steuertransfer als genommen vorhergesagt wird, aber nicht ins Ziel trifft, dann wird ein neuer BTB-Eintrag erzeugt, mit dem Ergebnis des Holens der Zielinstruktion. Genauer gesagt wird gleichzeitig mit dem ersten erfolgreichen Laden von Zielinstruktionsbytes aus dem Instruktions-Cache-Speicher 214 in den Instruktionspufferspeicher 408 die gleiche Information in einen ausgewählten BTB-Eintrag geladen, wodurch der vorherige Inhalt ersetzt wird. Ansonsten erfolgt das Holen des Ziels und das Laden des Instruktionspufferspeichers 408 auf normale Weise weiter.
Jeder Eintrag enthält einen Bezeichnungsteil und einen Datenteil. Der Datenteil hält sechszehn erweiterte Instruktionsbytes, umfassend ein Speicherbyte und drei dazugehörige Vordekodierungsbits. Die Übereinstimmung des Speicherbytes ist speicherausgerichtet mit der entsprechenden Stelle des Instruktionspufferspeichers 408. Der Bezeichnungsteil eines BTB-Eintrags hält einen Bezeichner von 30 Bit, umfassend den 32-Bit-Linear-Dekodierungs-PC 424, der der Transfersteuerinstruktion zugeordnet ist, mit einem Cache-gespeicherten Ziel, weniger Bits [4 : 1], ein Eintritt-Gültig-Bit und die 30-Bit reite modifizierte ursprüngliche Ziel-Linearinstruktionshol- Adresse. Keine bestimmten Instruktionswort-Gültig-Bits werden benutzt, da der Abstand zwischen der wirklichen Zieladresse und der modifizierten Zieladresse die Anzahl und Bestimmung der gültigen Instruktionsworte innerhalb des BTBs 456 direkt beinhaltet.
Der Zweck des BTBs 456 ist, Sprungziele innerhalb kleiner bis mittlere Schleifen für den Zeitraum zu erlangen, in dem eine Schleife oder ineinander verschlungene Schleifen aktiv ausgeführt werden. In Übereinstimmung mit diesem Zweck wird der gesamte BTB ungültig gemacht und geleert, wenn die kleinste Möglichkeit einer Inkonsistenz bekannt wird. Der BTB 456 wird ungültig gemacht und geleert bei einem Fehltreffer des Instruktions- Cache-Speichers 214, jeglicher Form des Ungültigmachens des Instruktions- Cache-Speichers 214, einem ITB-Fehltreffer oder jeglicher Form des Ungültigmachens des ITBs. Sprungziele außerhalb einem zeitlichen oder räumlichen Bereich werden nicht effektiv zwischengespeichert. Typischerweise enthält der BTB 456 nur eine kleine Anzahl von Einträgen, so dass die Komplexität reduziert wird, während das Beste des Leistungsgewinns eines idealen Zwischenspeicherns des Sprungziels erreicht wird.
Eine PC-bezogene Sprungziel-Adressberechnungs-Logik (nicht gezeigt) führt die Berechnung der Zieladresse durch. Die Sprungziel-Adressberechnungs- Logik wird nur benutzt für PC-bezogene Transfersteuerinstruktionen, welche von einem Kurz-Dekodierer SDec0 410, SDec1 414 oder SDec2 416 dekodiert wird. Genauer gesagt wird die Sprungziel-Adressberechnungs-Logik genutzt für die Sprunginstruktionen der Kurzdekodierung, umfassend Jcc disp8, LOOP disp8, JMP disp9, JMP displ6/32 und CALL displ6/32. Jeder Kurz-Dekodierer SDec0 410, SDec1 412 und SDec2 414 enthält eine Berechnungslogik für die logische und lineare Sprungzieladresse (nicht gezeigt). Alle drei Sätze der logischen und linearen Sprungziel-Adressberechnungs-Logik arbeiten parallel, während die Kurz-Dekodierer 410,412 und 414 bestimmen, ob eine der Operationen eine PC-bezogene Kurzdekodierungs-Sprunginstruktion ist. Die Berechnungslogik für die logische und lineare Sprungziel-Adresse summiert die logischen Programmzähler des Sprungs, die Länge der Sprunginstruktion und die vorzeichenerweiterte Verschiebung der Sprunginstruktion und maskiert bedingt die 16 Bits mit der höchsten Order dieser Summe in Abhängigkeit der Größe der Berechnung, um eine logische Zieladresse zu erstellen. Die Kalkulationslogik für die logische und lineare Sprungziel-Adresse summiert die logische Zieladresse mit der derzeitigen Basisadresse des Codesegments, um eine lineare Zieladresse zu erzielen. Wenn der Sprung genommen wird, entweder unbedingt oder als genommen vorhergesagt, dann werden die berechneten Adressen, welche der dekodierten Kurz-Dekodierungssprunginstruktion entsprechen, benutzt, um den logischen Dekodier-PC 422 und den linearen Dekodier-PC 424 neu zu initialisieren. Wenn der vorhergesagte Sprung nicht genommen wird, wird die logische Adresse zusammen mit der zugehörigen kurzdekodierten Sprunginstruktion (BRCOND Op) in einem Op-Quadrupel-Eintrag der Planungseinheit 260 gespeichert. Die logische Zieladresse wird mit dem derzeitigen Codesegment-Grenzwert zur Überwachung einer Grenzverletzung verglichen.
Wenn die Berechnungslogik für die logische und lineare Sprungzieladresse eine Grenzverletzung detektiert, egal ob der Sprung als genommen vorhergesagt oder als nicht genommen vorhergesagt gilt, dann wird ein spezielles Bezeichnungsbit, das die Grenzverletzung anzeigt, in dem Operations-Quadrupel-Eintrag der Planungseinheit 260 gesetzt, welche die von der Sprunginstruktion erzeugten Operationen hält. Nachfolgend wird, wenn die Operationsausführungseinheit (OCU) der Planungseinheit 260 versucht, diesen Op-Quadrupel auszuführen, der Op-Quadrupel als fehlerhaft behandelt und abgebrochen. Der Makroinstruktionsdekodierer 230 erzeugt Signale, die das Vektorisieren zu einem Fehlerhandhaber in dem Emulationscode-ROM 232 starten. Der Fehlerbehandler unterdrückt zeitweise das Dekodieren der Kurz- und Langdekodierer und springt zu der fehlerhaften PC-Adresse der verletzenden Instruktion, welche mit dem fehlerhaften Op-Quadrupel verbunden ist. Zum Schluss wird die Sprungvorhersage neu dekodiert und zum Instruktions-Emulationscode vektorisiert. Der Emulationscode erkennt die Grenzverletzung, wenn der Sprung tatsächlich genommen wird, und handhabt die Verletzung angemessen.
Der Prozessor 120 antwortet im allgemeinen auf eine Fehlerbedingung durch das Vektorisieren zu einem speziellen Fehlerbehandler in dem Emulationscode-ROM.232. Der Fehlerbehandler umfasst Operationen, die innerhalb des RISC-Instruktionssatzes definiert sind, welche eine Routine ausführen, die die Quelle des Fehlers bestimmt, angemessen auf den Fehler reagiert und Schritte zur angemessen Antwort einleitet. Als Alternative für angemessene Fälle enthält der Prozessor 120 auch eine spezielle "Lade alternativen Fehlerbehandler"-Operation, welche eine spezielle Fehlerantwort initiiert. Ausnahmen, welche während der Dekodierungszeit entdeckt werden, leiten die Ausführung zu einem festen Satz von Eintrittspunkten, wobei ein Eintrittspunkt für jede mögliche Ausnahmebedingung vorhanden ist, während der Operation des vektorisierenden Dekodierers 418, welcher den alternativen Fehlerbehandler aktiviert und eine Fehlerbehandler-Adresse bestimmt. Der alternative Fehlerbehandler ist vorteilhaft für das Erlauben von modifiziertem vollen Behandeln von speziellen Bedingungen. Die Lade alternativen Fehlerbehandler-Instruktion läuft durch die Pipeline des Instruktionsdekodierers 220, so wie es alle Instruktionen tun, aber veranlasst jede darauffolgende Ausnahmebedingung dazu, einen verschiedenen Vektorinstruktions-ROM-Eintrittspunkt aufzurufen. Der alternative Fehlerbehandler stoppt nach Beendigung der Ausführung der derzeitigen Makroinstru ktion.
Ein Beispiel für den Vorteil des alternativen Fehlerbehandlers tritt auf im Hinblick auf eine wiederholte Gewegezeicheninstruktion (REP MOVs). Um mehrfache Interaktionen sehr schnell auszuführen, ist die Fähigkeit, Sequenzen von Operationen umzuordnen, wichtig. Die Sequenz von Operationen umfasst typischerweise das Laden in eine von einem ersten Pointer zugewiesenen Adresse, ein Speichern in eine von einem zweiten Zeiger zugewiesene Adresse und, wenn sowohl das Laden und auch das Speichern erfolgreich waren, das Hochzählen des ersten und zweiten Zeigers und das Herunterzählen eines Zählers. Für zusätzliche Effizienz werden die Zähler hochgezählt und der Zähler heruntergezählt, bevor die Speicheroperation beendet ist. Wenn jedoch ein Fehler oder eine Ausnahme während der Sequenz von Operationen auftritt, wird die Sequenz abgebrochen, wobei die Zähler und Zeiger im falschen Zustand sind. Z.B. haben die SI-, DI- und CS- Register der X86-Architektur nicht den korrekten Wert. Der alternative Fehlerbehandler wird benutzt, indem er vor der Sequenz einen alternativer Fehlerbehandler spezifiziert, der ein Aufräumen nach einem wiederholten Bewegungsfehler durchführt. Die Sequenz läuft weiter ohne den Überbau von unmittelbaren Instruktionen zum Verfolgen der Zeiger und Zähler. Wenn keine Fehler auftreten, beendet der alternative Fehlerbehandler ohne Effekt. Wenn jedoch ein Fehler auftritt, wird der alternative Fehlerbehandler aufgerufen. Dieser alternative Fehlerbehandler ist spezifisch für die bestimmte Sequenz von Operationen und führt ein entsprechendes Aufräumen aus und springt zu dem voreingestellten Fehlerbehandler. Vorzugsweise verbessert ein höchsteffizienter Code die Geschwindigkeitsleistung ohne Behinderung durch den alternativen Fehlerbehandler bis ein Fehler auftritt, zu welcher Zeit der Fehler adressiert wird.
Die Sprung-Geschichts-Tabelle (BHT) speichert zurückliegende Geschichtsinformation, insbesondere Sprungrichtungsinformation, über bedingte Transfersteuerinstruktionen, welche in der Vergangenheit angetroffen worden sind. Wenn ein Sprung wiederholt wird, wird die zu dem Sprung gehörende gespeicherte Information analysiert, um die aktuelle Richtung des Sprunges vorherzusagen. Anschließend wird die gespeicherte Information in Abhängigkeit von der tatsächlich genommenen Richtung des Sprungs aktualisiert. Die gespeicherte Information wird abgeleitet von der Richtung eines bestimmten neu angetroffenen Sprungs, der letzten Richtungsgeschichte dieses bestimmten Sprungs und der letzten Richtungsgeschichte von anderen Sprüngen. Die gespeicherte Information basiert auf einer Vielzahl von Sätzen von 2-Bit-Zustandsmaschinen und auch auf der Richtungsgeschichte der letzten neun Sprungausführungen, unabhängig davon, ob die letzten neun Sprungausführungen zu dem speziellen Sprung oder zu anderen Sprüngen gehören. Die Instruktionsadresse dieses besonderen neu angetroffenen Sprungs wird benutzt, um eine aus der Vielzahl des Satzes der 2- Bit-Zustandsmaschinen auszuwählen. Die Richtungsgeschichte der letzten neun Sprungausführungen wird benutzt, um eine bestimmte 2-Bit-Zustandsmaschine in dem ausgewählten Satz der Zustandsmaschinen auszuwählen. Jede Zustandsmaschine ist ein 2-Bit-Sättigungszähler zum Zählen der von den allerjüngsten Sprüngen, welche auf diese bestimmte Zustandsmaschine zugegriffen haben, genommenen Richtungen. Typischerweise wird auf eine bestimmte Zustandsmaschine durch denselben statischen Sprung zugegriffen, obwohl andere Sprünge die gleiche Zustandsmaschine ansprechen können. Ein größerer Wert der Zustandsmaschine zeigt an, dass mehrere genommene Instanzen eines Sprungs vorhanden sind. Ein kleinerer Wert der Zustandsmaschine zeigt an, dass mehrere nicht genommene Instanzen eines Sprungs vorhanden sind. Nach der Auswahl der Zustandsmaschine wird auf die Zustandsmaschine zugegriffen. Wenn der vorhandene Gesamtzähler "größer" ist, dann wird ein Sprung als genommen vorhergesagt. Wenn der aktuelle Gesamtzähler "geringer" ist, dann wird ein Sprung als nicht genommen vorhergesagt. Die Richtungsgeschichte der letzten neun Sprungausführungen wird in einem Schieberegister mit neun Bit gehalten, welches jedes Mal getaktet oder geschoben wird, wenn eine Sprungsinstruktion erfolgreich dekodiert wurde. Die eben vorhergesagte unmittelbare Sprungrichtung ist der neue Wert der Richtungsgeschichte, der in das Schieberegister geschoben wird. Der Wert eines Geschichtsbits von 1 zeigt an, dass ein Sprung genommen wurde. Ein Wert eines Geschichtsbits von 0 zeigt an, dass ein Sprung nicht genommen wurde.
Während eines Dekodierungszyklus wird der lineare Dekodier-PC 424 benutzt, um einen Nachschlag in der BHT-Tabelle durchzuführen. Wenn eine PC-bezogene Sprungsinstruktion dekodiert wird, dann sagt die angesprochene Zustandsmaschine die Sprungrichtung unmittelbar voraus, obwohl die nachfolgend geholte und dekodierte aktuelle Instruktion am Ende des Dekodierungszyklus von dem Makroinstruktionsdekodierer 230 bestimmt wird, Nachfolgend wird die durch das Dekodieren der bedingten Sprunginstruktion erzeugte Sprungsbedingungs-(BRCOND)Operation durch Logik in der Planungseinheit 260 gelöst, zu welchem Zeitpunkt die Zustandsmaschine aufgefrischt wird. Wenn der Sprung wirklich genommen wird, wird die Zustandsmaschine heruntergezählt, es sei denn, sie befindet sich bereits bei dem maximalen Wert (3). Wenn der Sprung tatsächlich nicht genommen wurde, wird die Zustandsmaschine hochgezählt, es sei denn, sie ist bereits bei einem minimalen Wert (0). Entsprechend zeigt ein Wert der Zustandsmaschine von 0 bis 1 eine starke und eine schwache Vorhersage eines nicht genommenen Sprungs an. Ein Wert der Zustandsmaschine von 2 bzw. 3 zeigt eine schwache und Stärke-Vorhersage eines genommenen Sprungs an. Zur Unterstützung des Erneuerns von BHT-Einträgen werden eine Kopie der Sprungadress- und Richtungsgeschichts-Bits zum Zugreifen auf die BHT und eine Kopie des Werts der Zustandsmaschine zusammen mit der Sprungsbedingungs-(BRCOND)Operation an die Planungseinheit 260 geleitet. Da maximal eine BRCOND in einem Op-Quadrupel enthalten ist, wird die BHT-Unterstützungsinformation an den zu der Planungseinheit 260 zu liefernden Op-Quadrupel angehängt. Es ist vorteilhaft zur Reduzierung der Schaltungsgröße und Komplexität, dass die BHT keine Eintragsidentifizierungen (Adressen des linearen Dekodier-PC 424 zusammenhängend mit dekodierten bedingten Sprüngen) enthält, welche für Strukturen von Cache- Speichern üblich sind. Es ist weiterhin vorteilhaft, dass die BNT eine große Anzahl von Einträgen hat, so dass die Konfliktrate niedrig ist.
Die in einem Op-Quadrupel der Planungseinheit 260 gemeinsam mit einer dazugehörigen BRCOND-Operation gespeicherte Information hat eine Breite von fünfzehn Bits, umfassend vier Sprungadressbits, neun aktuelle Geschichtsbits und die unmittelbar angesprochenen zwei Bits der Zustandsmaschine, dessen oberes Bit auch die vorhergesagte Richtung für den unmittelbaren Sprung ist. Die ersten dreizehn Bits werden benutzt, wenn es erforderlich ist, um erneut auf die BHT zuzugreifen und um einen Wert der Zustandsmaschine zu erneuern. Die letzten beiden Bits werden modifiziert, um einen neuen Wert der Zustandsmaschine zu erzeugen.
Wenn ein Sprung fehlvorhergesagt wurde, wird der Satz der Geschichtswerte in dem neuen bitbreiten Sprunggeschichte-Schieberegister korrigiert, um die tatsächliche von dem Sprung genommene Richtung zu berücksichtigen. Darüber hinaus wird das Schieberegister "zurückgeschoben", um mit dem fehlvorhergesagten Sprung übereinzustimmen und dann in Abhängigkeit von der wirklichen Sprungrichtung und in Abhängigkeit, welche Sprungrichtung vorhergesagt war, aktualisiert.
Ein Rückkehradress-Stapel (RAS) (nicht gezeigt) ist ein Zieladress-Cache- Speicher für Rückkehr-(RET)Transfersteuerinstruktionen. Das RAS ist ein 32-Bit breites RAM mit acht Einträgen und einem Anschluss, welches als Ringpufferspeicher organisiert ist und einen einzelnen Zähler mit drei Bit benutzt. Während jedes Zyklus wird höchstens ein Zugriff, entweder ein Lesezugriff für eine RET-Dekodierung oder ein Schreibzugriff für eine CALL- Dekodierung, durchgeführt. Das RAS speichert die RET-Rückkehradressen zwischen und sagt Rückkehradressen voraus, welche inhärent eine Zieladresse auf indirekte Weise angeben, im Gegensatz zu anderen Transfersteuerinstruktionen, welche eine direkte Angabe der Zieladresse enthalten. Das RAS wird vorteilhafterweise benutzt, da eine bestimmte RET-Instruktion häufig die Zieladressen zwischen verschiedenen Ausführungen der Instruktion ändert. Das RAS entdeckt und nimmt den Wert der Zieladresse für jede RET-Instruktionsausführung vorweg, indem die von den CALL-Instruktionen durch Schieben auf einen Stapel gespeicherten Rückkehradressen überwacht werden. Die entsprechenden CALL- und RET-Instruktionen treten typischerweise dynamisch in Paaren und in Last-In-First-Out-LIFO-Reihenfolge im Hinblick auf andere CALL- und RET-Instruktionspaare auf.
Jedes Mal, wenn eine CALL-Instruktion erfolgreich dekodiert wurde, wird die logische Rückkehradresse in einem zirkularem Puffer, der als LIFO-Stapel organisiert ist, gespeichert (geschoben). Jedes Mal, wenn eine RET-Instruktion erfolgreich dekodiert wird, wird der sich derzeit an der Spitze des RAS befindliche Rückkehradresswert als die vorhergesagte Zieladresse für das RET verwendet und der Wert wird von dem RAS entfernt. Das RAS erzielt eine hohe Vorhersagerate, obwohl Fehlvorhersagen auftauchen, weil CALLs und RETs nicht immer in verbundenen Paare auftreten, nur nahe CALLs und RETs und keine weiteren CALLs und RETs unterstützt werden und Fehlvorhersagen treten auf Grund der begrenzten Tiefe des RAS auf. Wenn eine bedingte Sprungfehlvorhersage auftritt, versucht das RAS den Zustand vor der Fehlvorhersage wieder herzustellen, indem die Spitze des Stapelzeigers auf die vorherige Bedingung gesetzt wird, denn CALL- und RET-Instruktionen könnten spekulativ dekodiert worden sein, und der Zeiger der Spitze des Stapels dabei modifiziert. Der ursprüngliche, vor der Fehlvorhersage, Zeiger muss wieder hergestellt werden. Die auf eine Fehlvorhersage folgende Wiederherstellung wird von der Planungseinheit 260 unterstützt. Jeder Op-Quadrupel der Planungseinheit 260 ist mit einem aktuellen ursprünglichen zur Spitze des Stapels zeigenden Zeigerwert gekennzeichnet, der aktiviert ist während des Dekodierzyklus, in welchem der Op-Quadrupel erzeugt wurde. Wenn die für eine bedingte Sprunginstruktion erzeugte BRCOND-Op gelöst und als fehlvorhergesagt gefunden wurde, wird der an den Op-Quadrupel der Planungseinheit angehangene, auf die Spitze des Stapels zeigende Zeiger während eines Neustartszyklus an das RAS ausgegeben, wobei der Neustartzyklus von der Planungseinheit 260 erzeugt wird. Das RAS ersetzt den aktuellen auf die Spitze des Stapels zeigenden Wert mit der den auf die Spitze des Stapels zeigenden Zeiger enthaltenen Bezeichnung des Op-Quadrupels der Planungseinheit.
Bezugnehmend auf Fig. 5 stellt ein schematisches Blockdiagramm eine Instruktionsdekodier-Emulationsschaltung 231 dar mit einem Instruktionsregister 512, einer Eintrittspunktschaltung 514, einem Emulationsumgebungsregister 516, einem Emulationscode-Sequenzierer 510, einem Emulationscode-Speicher 520 und einer Op-Substitutionsschaltung 522. Die Instruktionsdekodier-Emulationsschaltung 231 ist eine Schaltung innerhalb des Instruktionsdekodierers 220. Die Instruktionsdekodier-Emulationsschaltung 231 empfängt Instruktionsbytes und dazugehörige Vordekodierinformation von dem Instruktionspufferspeicher 408, der mit der Instruktionshol-Steuerschaltung 218, dem BTB 456 oder dem Instruktions- Cache-Speicher 214 verbunden ist. Der Instruktionspufferspeicher 408 ist mit dem Instruktionsregister 512 verbunden und versorgt dieses mit X86- Instruktionen. Das Instruktionsregister 512 ist mit der Eintrittspunktschaltung 514 verbunden, um Emulationscode-ROM-Eintrittspunkte bereitzustellen. Die Eintrittspunktschaltung 514 empfängt die X86-Instruktionen und erzeugt aus dem X86-Instruktionsoperationscode (Opcode) eine Eintrittspunktadresse, also eine in den Emulationscode-Speicher 520 zeigende Startadresse. Auf diese Weise wird eine Adresse einer Instruktion in dem Emulationscode-Speicher 520 aus dem Opcode einer X86-Instruktion synthetisiert. Die Adresse wird in Abhängigkeit von dem X86-Instruktionsbyte abgeleitet, insbesondere dem ersten und zweiten Byte der X86-Instruktion, aber auch aus Information, wie dem mod/m-Byte, Präfixen REP und REPE, dem Protected-Mode-Bit und dem effektiven Datengrößenbit DSz. Im allgemeinen haben eng verwandte X86-Instruktionen ähnlich kodierte Bit-Felder, z.B. ist ein den Typ einer Instruktion anzeigendes Bit-Feld das gleiche bei verwandten X86-Instruktionen, so dass ein einzelner Eintrag in dem Emulationscode-Speicher 520 mehreren X86-Instruktionen entspricht. Generell werden Eintrittspunkte synthetisiert, indem die X86-Instruktionen gelesen werden und die Bits der Eintrittspunktadresse entsprechend den Werten von bestimmten Bit-Feldern der X86-Instruktion zu gewiesen werden. Das Instruktionsregister 512 ist mit dem Emulationscode-Sequenzierer 510 verbunden, welcher wiederum mit dem Emulationscode-Speicher 520 verbunden ist. Der Emulationscode-Sequenzierer 510 wendet den Eintrittspunkt auf den Emulationscode-Speicher 520 an und empfängt Sequenzinformation aus dem Emulationscode-Speicher 520. Der Emulationscode-Sequenzierer 510 steuert entweder das Sequenzieren von Instruktionen oder, falls eine neue Sequenz gestartet werden soll, wendet er einen Eintrittspunkt auf den Emulationscode-Speicher 520 an. In dem Emulationscode-Speicher 520 kodierte Operationen (Ops) werden von dem Emulationscode-Speicher 520 als Op-Quadrupel oder Op-Einheiten an die Op-Substitutionsschaltung ausgegeben. Die Ops entsprechen einer Tabelle für X86-Operationen vom RISC- Typ. Diese Tabelle umfasst eine Vielzahl von Feldern, in welchen Codes selektiv ersetzt werden. Der Emulationscode-Speicher 520 ist mit der Op- Substitutionsschaltung 522 verbunden, um Ops zuzuführen, in denen die verschiedenen Op-Felder selektiv ersetzt werden. Funktional berechnet die Eintrittspunktschaltung 514 einen Eintrittspunkt in das Emulationscode-ROM 232 oder das Emulationscode-RAM 236. Die Sequenz in dem Emulationscode-ROM 232 bestimmt die Funktionalität einer Instruktion.
Der Emulationscode-Speicher 520 umfasst ein Emulationscode-ROM 232, das sich auf dem Chip befindet, und ein externes Emulationscode-RAM 236. Der Emulationscode-Speicher 520 umfasst kodierte Operationen, welche festlegen, wie der Prozessor 120 funktioniert, und definiert, wie X86- Instruktionen ausgeführt werden. Sowohl das Emulationscode-ROM 232 und -RAM 236 enthalten eine Vielzahl von Kodierungen von Operations- (Op)Instruktionen, welche ein Op-Kodierformat haben, das das gleiche ist, wie in dem ROM 232 und dem RAM 236. Z.B. hat in einem Ausführungsbeispiel das Emulationscode-ROM 232 eine Kapazität von 4-K-Worten mit 64 Bit. Das Op-Kodierformat ist typischerweise ein Format, das beispielsweise in 30 bis 40 Bits definiert ist. In einem Ausführungsbeispiel ist ein in den Fig. 6A bis 6E gezeigtes 38-Bitformat definiert. Der Ort der Basisadresse des Emulationscode-ROM 232 innerhalb des Emulationsraumes ist fest. Das externe Emulationscode-RAM 236 ist im normalen Speicheradressraum innerhalb des zwischenspeicherbaren Speichers angeordnet. Der Ort der Basisadresse des Emulationscode-RAM 236 ist fest innerhalb des Emulationsraums. Die 32-Bit-Adresse des Emulationscode-RAM 236 wird gebildet aus der festen Basisadresse des Emulationscode-RAM 236, welches die fünfzehn höchstwertigen Bits < 31 : 17> ausgibt, und der Op-Adresse, welche vierzehn mit den Basisadressbits verknüpfte Bits < 16 : 3> bereitstellt. Die zwei niederwertigsten Bits < 1 : 0> der Adresse des Emulationscode-RAM werden auf null gesetzt. Die vierzehn Bit breite Op-Adresse im Emulationscode-RAM 236 ist dieselbe wie die Op-Adresse im Emulationscode-ROM 232. Operationen (Ops) werden im Op-Kodierformat gespeichert, beispielsweise 38 Bits, in dem externen Emulationscode-RAM 236 in Worten mit 64 Bit. Bits, die über die 64-Bits des Op-Kodierformats hinausgehen, werden genutzt, um Steuertransfer-(OpSeq)Information zu speichern. Das externe Emulationscode-RAM 236 wird typischerweise für Test- und Debug-Zwecke genutzt, was das Ausbessern von jeglichen in dem Emulationscode-ROM 232 kodierten Instruktionen und das Implementieren von Spezialfunktionen, wie einen Systemmanagementmodus (SMM) ermöglicht. Wenn beispielsweise herausgefunden wird, dass eine Instruktion in dem Emulationscode- ROM 232 nicht korrekt funktioniert, wird auf das externe Emulationscode- RAM 236 zugegriffen, um den fehlerhaft funktionierenden festen Code in dem Emulationscode-ROM 232 temporär oder permanent zu ersetzen. Der Zugriff auf das externe Emulationscode-RAM 236 wird typischerweise unter Benutzung von einer von zwei Techniken erreicht. Bei einer ersten Technik bestimmt ein Feld von einem Bit in einem OpSeq-Feld eines Elements des Emulationscode-Speichers 520, dass die nächste Adresse für das Holen von Instruktionen in dem externen Emulationscode-RAM 236 angesiedelt ist. Bei dieser ersten Technik startet das auf dem Chip befindliche Emulationscode- ROM 232 die Ausführung des externen Emulationscode-RAM 236. Bei einer zweiten Technik wird einfach eine Vektoradresse zum Vektorisieren zu einem Eintrittspunkt in dem Emulationscode-RAM 236 ausgegeben.
Der Instruktions-Cache-Speicher 214, die Instruktionshol-Steuerschaltung 218 und der Instruktionsdekodierer 220 arbeiten in drei Instruktionshol- und Dekodiermodi. In einem Modus holt der Instruktionsdekodierer Emulationscode-Op-Quadrupel von dem auf dem Chip befindlichen Emulationscode-ROM 232. Jeder Op-Quadrupel enthält vier Operationen (Ops) sowie Steuertransferinformation (OpSeq) zum Bestimmen des nächsten Zyklus von Hol- und Dekodierfunktionen. In einem zweiten Modus steuert die Instruktionshol-Steuerschaltung das Holen von X86-Makroinstruktionsbytes aus dem Instruktions-Cache-Speicher 214, welcher Teil des auf dem Chip befindlichen L1-Instruktions-Cache-Speicher 214 ist. Die X86-Makroinstruktionen werden von dem Makroinstruktionsdekodierer 230 dekodiert, welcher vier Operationen (Ops) erzeugt. Vier Ops sowie das OpSeq-Feld bilden ein volles Op-Quadrupel. Der Instruktionsdekodierer 220 führt jeden kodierten Steuertransfer durch, unter Benutzung der Sprungeinheit 234 und der vektorisierenden Funktionalität des Makroinstruktionsdekodierers 230. In einem dritten Modus steuert die Instruktionshol-Steuerschaltung 218 das Holen von Worten mit 64 Bit, welche Emulationscode im Op-Kodierformat enthalten, aus dem Instruktions-Cache-Speicher 214 mit einem 64 Bit-Wort pro Zyklus. Jedes 64 Bit-Wort entspricht einer einzelnen Operation (Op). In anderen Ausführungsbeispielen könnte auf eine Vielzahl von 64 Bit-Worten pro Zyklus zugegriffen werden. In einem Beispiel, bei dem auf vier 64 Bit- Worte zugegriffen wird, gibt das Emulationscode-RAM 236 einen kompletten Op-Quadrupel nach Art des auf dem Chip befindlichen Emulationscode-ROM 232 aus, so dass ein vollständig umprogrammierbarer Prozessor mit voller Effizienz geschaffen wird. Ein vollständig umprogrammierbarer Prozessor erlaubt vorteilhafterweise die sanfte Implementierung von sich stark unterscheidenden Prozessoren, z. B. eines X86-Prozessors und eines PowerPCO in einer einzigen Hardware-Anordnung.
Bei dem ersten und dritten der drei Betriebsmodi wird die Steuertransferinformation in ein operationssequenzierendes (OpSeq)-Feld des Op-Quadrupels formatiert. Unbedingt des Steuertransfers sowie Sprung-(BR)- und Rückkehr von der Emulation (ERET)-Operationen werden unter vollständiger Benutzung der OpSeq-Steuertransfer-Informationen gesteuert. Bedingte Transfere sowie der bedingte Sprung (BRcc) werden unter Benutzung einer Kombination des OpSeq-Feldes und einer Sprungsbedingungs- (BRCOND)Operation gesteuert. Eine Grafik eines OpSeq-Feldformats ist in Fig. 7 gezeigt. Das 16-Bit breite OpSeq-Feld 700 umfasst ein sequenzierendes Ausführungs-(ACT)Feld 710 mit zwei Bit, ein externes Emcode-Feld 712 mit einem Bit und ein Operations-(Op)Adressierfeld 714 mit dreizehn Bit. Vier sequenzierende Ausführungen sind in dem ACT-Feld 710 kodiert, wie folgt:
Ob eine sequenzierende Ausführung eines OpSeq unbedingt oder bedingt ist, hängt von dem Vorhandensein bzw. der Abwesenheit einer Sprungbedingungs-(BRCOND)Op an anderer Stelle innerhalb des Op-Quadrupels ab. Die BRCOND-Op innerhalb des Op-Quadrupels gibt die zu testende Bedingung und die wechselnde Emulationscode-Zieladresse an. Ein explizites statisches Sprungrichtung-Vorhersagebit existiert nicht. Stattdessen werden die vorhergesagte Aktion und die nächste Adresse immer von dem OpSeq- Feld 700 spezifiziert und die "nicht vorhergesagte" nächste Adresse wird immer von der BRCOND-Op spezifiziert. Eine BRCOND-Op ist immer gepaart mit einer BSR-sequenzierenden Aktion, welche unbedingte Aufrufe enthält. Für unbedingte und bedingte "als genommen vorhergesagte" Aufrufe spezifiziert die BRCOND-Op die zu speichernde Rückkehradresse.
Das externe Emcode-Feld 712 wird auf eins gesetzt, wenn der auszuführende Emulationscode sich im externen Emulationscode-RAM 236 befindet. Das externe Emcode-Feld 712 wird auf null gesetzt, wenn der auszuführende Emulationscode sich im internen Emulationscode-ROM 232 befindet. Das Op-Adressfeld 714 bestimmt die Adresse einer Ziel-Op innerhalb eines Op-Quadrupels ohne Eintrittspunkt.
Die OpSeq-Steuertransfer-Information steuert unbedingte Steuertransfere, wenn ein Op-Quadrupel oder ein Speicherwort mit 64 Bit geholt und arrangiert oder "sofort dekodiert" wird. Die Festlegung der nächsten zu dekodierenden Instruktion wird allein durch das OpSeq-Feld gesteuert. Das OpSeq- I = eld spezifiziert eine von drei alternativen Aktionen. Ersten leitet das OpSeq-Feld das Holen von Emulationscode aus dem Emulationscode-ROM 232 bei einer 14 Bit breiten Einzeloperation-Wortadresse, so dass ein Op- Quadrupel aus dem Emulationscode-ROM 232 geholt wird. Zweitens leitet das OpSeq-Feld das Holen von Emulationscode aus dem Emulationscode- RAM 236 bei einer angegebenen 14 Bit breiten Einzeloperation-Wortadresse, so dass ein 64 Bit breites Speicherwort aus dem Emulationscode-ROM 232 geholt wird. Drittens umfasst das OpSeq-Feld eine Rückkehr von der Emulations-(ERET)Anordnung, welche den Instruktionsdekodierer 230 anweist zu dem Dekodieren von X86-Mikroinstruktionen zurückzukehren.
Aus dem Emulationscode-ROM 232 geholter Emulationscode wird in der Form von ausgerichteten Op-Quadrupeln geholt. Ein Sprung zu einer unmittelbaren Stelle innerhalb eines Op-Quadrupels veranlasst, dass die vorhergehenden Operationen innerhalb des Quadrupels als ungültig behandelt werden, indem NOOPs anstelle der vorhergehenden Operationen geholt werden.
Die Byte-Speicheradressen zum Holen von Speicherworten mit 64 Bit aus dem Emulationscode-RAM 236 werden durch das Verketten von angegebenen 14 Bit breiten Operationsadressen mit drei auf null gesetzten minderwertigen Bits geschaffen, wodurch eine ausgerichtete 8 Bit breite Adresse entsteht. Die Byte-Speicheradressen zum Holen von Speicherworten mit 64 Bit sind 8 Bit-ausgerichtet, was dazu führt, dass das Voranschreiten des Speicher-Op-Dekodierens und Holens/Dekodierens konsistent und einfach ist.
Die OpSeq-Steuertransfer-Information steuert auch die Zuweisung der unmittelbar nächsten zu dekodierenden Instruktion für bedingte Steuertransfiere. Die Sprungbedingungs-(BRCOND)Operation gibt den zu testenden und zu bewertenden Bedingungscode an und gibt eine alternative 14 Bit breite Emulationscode-Hol- und Dekodieradresse an. Daher spezifiziert die OpSeq- Steuertransfer-Information für bedingte Steuertransfere den vorhergesagten Pfad des bedingten Sprungs. Die BRCOND-Adresse ist typischerweise entweder die 14 Bit breite Ziel-Op-Wortadresse oder die 14 Bit breite Op- Wortadresse der nächsten "sequentiellen" Operation (Op). Allgemeiner gesagt kann die BRCOND-Adresse einen ganz allgemeinen bedingten Sprung mit zwei Wegen bestimmen. Es ist festzustellen, dass das Wort sequentiell in Anführungsstrichen geschrieben worden ist, um anzuzeigen, dass, obwohl die "sequentielle" Adresse im allgemeinen auf eine Instruktion zeigt, welche der aktuellen Instruktion unmittelbar vorangestellt ist, die "sequentielle" Adresse auch auf jede andere adressierte Stelle gesetzt werden kann. Eine bedingte ERET-Operation wird implementiert, indem das OpSeq-Feld derart gesetzt wird, dass es eine ERET-Operation angibt, so dass die bedingte ERET als genommen vorhergesagt wird. Wenn die ERET-Operation im nachfolgenden als fehlvorhergesagt erkannt wird, dann wird der von der ERET geleitete X86-Makroinstruktionsstrom abgebrochen und der sequentielle Makroinstruktionsstrom, der von der BRCOND-Operation angegeben wird, wird wieder gestartet.
Die BRCOND-Operationen werden in unausgegebenem Zustand in die Planungseinheit 260 geladen. Die BRCOND-Operationen werden in ihrer Reihenfolge von der Sprungauflösungseinheit der Planungseinheit 260 bewertet. Wenn der Sprung korrekt vorhergesagt wurde, wird der Sprung als beendet markiert. Ansonsten wird der BRCOND-Zustand nicht ausgegeben und löst ein Sprungabbruchsignal aus, wenn es von der Op-Ausführungseinheit entdeckt wird.
Der Emulationscode-Speicher 520 unterstützt eine einstufige (nicht verschachtelte) Unterroutinen-Funktionalität, in der ein OpSeq-Feld gesetzt wird, um Alternativen zum Holen von Emulationscode anzugeben. Die Alternativen sind als typischer bedingter Sprung mit zwei Wegen strukturiert, mit der Ausnahme, dass eine 14 Bit breite Op-Wortadresse aus dem unmittelbaren Feld einer BRCOND-Op innerhalb des Op-Quadrupels oder das Speicher-Op in ein Unterroutinenrückkehr-Adressregister geladen wird. Das Unterroutinenrückkehr-Adressregister speichert die 14 Bit breite Op- Wortadresse sowie ein einzelnes Bit, welches anzeigt, ob die Rückkehradresse sich im Emulationscode-ROM 232 oder -RAM 236 befindet. Der von der BRCOND-Op angegebene Bedingungscode kann jegliche Alternative sein, auch TRUE, so dass sowohl unbedingte als auch bedingte (als genommen vorhergesagte) Unterroutinen benannt werden können. Die BRCOND- Op muss jedoch angegeben werden, um das Laden eines undefinierten Werts in das Unterroutinenrückkehr-Adressregister zu vermeiden.
Das ganze Management der Unterstützung und des Rückkehr-Adressregisters für die Emulationscode-Unterroutinen wird von dem sich am Anfang der Pipeline befindlichen per Emulationscode-Sequenzierer 510 ausgeführt. Daher ist das Laden und die Benutzung des Rückkehr-Adressregisters in voller Synchronität mit dem standardgemäßen Dekodier-Zeitablauf, so dass keine Verzögerungen eingeführt werden.

Zwei-Wege-Emulationscode-Sprünge

Das Emulationscode-ROM 232 ist Speicher für eine Vielzahl von Sequenzen von Operationen (Ops). Eine Operationssequenz beginnt bei einem definierten Eintrittspunkt, der in dem Emulationscode-ROM 232 hartkodiert ist, und erweitert sich zu einer Rückkehr von der Emulation-(ERET)OpSec-Anordnung, welche die Operationssequenz beendet. Die Anzahl der Operationen in einer Sequenz ist typischerweise variabel, wie es angemessen ist für die Ausführung von zahlreichen verschiedenen Funktionen. Einige einfache X86-Instruktionen haben lediglich einen einzelnen Op-Eintrag in dem Emulationscode-ROM 232, obwohl diese Instruktionen mit der Breite Op-Quadrupeln geholt werden. Andere komplexere X86-Instruktionen benutzten Operationen mit vielen Komponenten. Der Speicher des Emulationscode- ROM 232 ist als eine Vielzahl von Op-Quadrupeln strukturiert, die einen festen ROM-Adressraum programmiert sind. Jeder Op-Quadrupel umfasst vier RISC-Op-Felder und ein OpSeq-Feld. Die Operationssequenzen sind typischerweise nicht ausgerichtet innerhalb der Op-Quadrupel, so dass in Abwesenheit einiger Techniken zum Springen zu auseinanderliegenden Stellen dem Emulationscode-ROM 232, viele ROM-Einheiten in dem Emulationscode-ROM 232 unbenutzbar sind, wodurch kostbarer Raum in der integrierten Schaltung verschwendet wird. Darüber hinaus werden, weil die Eingangspunktadresse eine Instruktion im Emulationscode-ROM 232 aus dem Opcode einer X86-Instruktion synthetisiert wird, die Eingangspunktadressen oftmals in fixe durch den ROM-Adressraum verbreitete Positionen mit dazwischenliegenden Lücken gezwungen, was zu unbenutzten Bereichen des ROMs führt. Stellen des ROMs, welche ohne Zugriff über einen Eintrittspunkt geblieben sind, sind frei für andere Benutzungen, jedoch bequem sequentiell um einen Zugriff zu erlauben. Das OpSeq-Feld stellt eine Technik zum Sprung an diese verteilten Stellen bereit, wodurch der verschwendete Platz erheblich eliminiert wird.
Jedes der vier RISC-Op-Felder eines Op-Quadrupels speichert eine einfache RISC-ähnliche Operation. Das OpSeq-Feld speichert einen Steuercode, der an den Emulationscode-Sequenzierer 510 weitergegeben wird, und weist den Emulationscode-Sequenzierer 510 an, zu einer nächsten Stelle in dem Emulationscode-ROM 232 zu springen. Jedes der vier RISC-Op-Felder in dem Emulationscode-ROM 232 kann eine Sprungoperation entweder unbedingt oder bedingt speichern und gibt dabei eine Zieladresse an, so dass eine Vielzahl von Sprüngen in einem einzelnen Op-Quadrupel kodiert sein kann. In einigen Ausführungsbeispielen der Instruktionsdekodier-Emulationsschaltung 231 ist der Op-Quadrupel dahingehend begrenzt, dass er höchstens eine einzelne Sprungoperation hat zum Anleiten einer Op-Anordnung im Zusammenhang mit dem OpSeq-Feld. Die Kombination einer bedingten Sprung-Op in einer der vier RISC-Op-Felder und des OpSeq-Feldes in einem Op-Quadrupel schafft einen Op-Quadrupel mit zwei möglichen Ziel- oder nächsten Adressen.
Für eine Op-Quadrupel mit einer Vielzahl von Zieladressen leitet der Emulationscode-Sequenzierer 510 die Sequenz von Operationen durch das Auswählen einer hartkodierten vorhergesagten Zieladressen. Daher wählt der Emulationscode-Sequenzierer 510 für einen Op-Quadrupel, der einen bedingten Sprung enthält, eine hartkodierte OpSeq-Zieladresse mit Vorzug vor einem bedingten Sprung aus. Der unbedingte Sprung wird nachfolgend in Übereinstimmung mit der Sprungvorhersagefunktionalität des Prozessors 120 behandelt, so dass kein zusätzlicher Überbau zur Sprungbehandlung durch die Implementierung des Zwei-Wege-Emulationscode-Springens auftritt.
Der Emulationsmikrocode kann derart geschrieben werden, dass eine BRCOND-Op in einer der ersten drei Positionen des Op-Quadrupels angeordnet ist. Daher werden die der BRCOND-Op folgenden Ops innerhalb des Op-Quadrupels in Abhängigkeit von der vorhergesagten Richtung ausgeführt, unabhängig davon, ob der Sprung letztlich genommen wird. Wenn sich letztlich herausstellt, dass der Sprung korrekt vorhergesagt wurde, werden alle Ops des Op-Quadrupels und die Ops der darauffolgenden Op- Quadrupel an die Planungseinheit 260 übergeben. Wenn sich letztlich herausstellt, dass der Sprung fehlvorhergesagt ist, werden alle Ops, die der BRCOND-Op folgen sowie alle darauffolgenden Op-Quadrupel abgebrochen. Der Emulationscode wird ausgegeben, um die Sprungbedingungen, eine Zieladresse, eine "sequentielle" Adresse und auch die Vorhersage für die Sprungbedingung zu enthalten.
Für die meisten Instruktionen liefert das OpSeq-Feld allein die nächsten Holadressen, entweder eine Vektoradresse oder eine ERET-Rückkehr. Dies ist vorteilhaft, um die steuernde Hardware zu vereinfachen, die eine schnelle und einfache Steuerlogik unterstützt, welche das Holen der Operationen steuert, ohne die Analyse von bedingten Sprüngen oder Sprungvorhersagen. Für bedingte Sprunginstruktionen liefert das OpSeq-Feld eine vorhergesagte Sprungadresse und eine BRCOND-Operation in dem Quadrupel, gibt einen zu bewertenden Bedingungscode an und spezifiziert die wechselnde Holadresse im Fall einer Fehlvorhersage. Das Handhaben des Emulationscodes erzielt vorteilhafterweise die Flexibilität eines nicht sequentiellen Holens von Op-Quadrupeln, wobei die Instruktionssteuersequenz mit wenigen Hindernissen von dem Programm ausgewählt wird. Entsprechend wird das OpSeq-Feld vorteilhafterweise genutzt, um Op-Sequenzen effizient in nicht benutzte Bereiche des Emulationscode-ROM 232 einzupassen. Die Handhabung des Emulationscodes umfasst auch die Flexibilität von optionalen Zwei-Wege-Sprüngen für den Fall von bedingten Sprüngen und auch in dem Fall eines Unterroutinen-Aufrufs, der angewiesen sein kann, zu im wesentlichen jeder Stelle zurückzukehren, anstatt dazu gezwungen zu sein, zu der der aufrufenden Instruktion folgenden Instruktion zurückzukehren. Diese Benutzung des OpSeq-Feldes zum Springen zu einer Zieladresse erreicht vorteilhafterweise das unbedingte Springen, ohne dass eine Zeit- oder Zyklusstrafe hervorgerufen wird.

Emulationsumgebungssubstitution

Der Emulationscode-Sequenzierer 510 steuert zahlreiche Emulationsumgebungssubstitutionen, um die Anzahl der kodierten Operationen über die Anzahl der Operationseinträge in dem Emulationscode-ROM 232 erheblich zu erweitern. Der Emulationscode-Sequenzierer 510 enthält Logikschaltungen, welche die spezifischen typischerweise zugewiesenen Kodierungen eines Op- Feldes analysieren, um festzustellen, wann eine Substitution gemacht werden soll und welche Substitution ausgeführt werden soll. Die meisten Kodierungen spezifizieren direkt einen Feldwert. Andere Kodierungen spezifizieren indirekt einen Feldwert durch die Emulationsumgebungssubstitution. Die Benutzung der Emulationsumgebungssubstitution erzielt das Kodieren von CISC-Funktionalität, während die Größe des Emulationscode-ROMs 232 erheblich reduziert wird, was vorteilhafterweise die Größe und die Kosten einer integrierten Schaltung eines Prozessors reduziert. Das Op-Feld, umfassend das Registerfeld und einige der Größenfelder, gibt direkt ein Register an oder gibt einen indirekten Registerspezifikator, wie AX oder T1 an. Ähnlich kann ein Feld RegM auswählen, welches der Direktregister-Spezifikator ist. Die Op-Substitutionslogik analysiert die Kodierung für die indirekten Registerspezifikatoren, um nachfolgend die Registerkodierung anzugeben und die Registerkodierung mit dem aktuellen Register zu ersetzen. Die Größenfelder wählen ein Byte, zwei Bytes oder vier Bytes oder wählen eine D-Größe, so dass die aktuelle effektive Datengröße die ursprüngliche Kodierung ersetzt. Die Symbole so wie HReg repräsentieren bestimmte Kodierungen wie HReg T2, welches eine symbolische Darstellung der Kodierung für T2 ist. Illustrative Symbole umfassen Hreg, HDSz, HASz, HsegDecr, HspecOpType und andere.
Pseudo-RTL-Code, wie folgend, beschreibt spezielle die Emulationsumgebungssubstitutionsoperation:
Der Emulationscode-Sequenzierer 510 leitet zu einem nächsten Eintrittspunkt in dem Emulationscode-ROM 232 weiter und produziert dabei einen Op-Quadrupel, der vier Operations-(Ops) und ein OpSeq-Feld umfasst. Für jede der vier Operationen in einem Op-Quadrupel werden verschiedene Substitutionen gemacht, wobei der Typ der Substitution von dem bestimmten Operationstyp der fünf allgemeinen Operationstypen abhängt. Die fünf Operationstypen umfassen Registeroperationen (RegOps), Lade-/Speicher- Operationen (LdStOps), Lade-Unmittelbar-Operationen (LIMMOps), spezielle Operationen (SpecOps) und Gleitkomma-Operationen (FpOps). Op-Formate für die fünf Operationstypen sind in den Fig. 6A bis 6E dargestellt.
Die von Emulationscode-ROM 232 erzeugten Ops sind ihrer Natur nach allgemein. Insbesondere entsprechen die Ops den X86-Instruktionen nicht exakt. Stattdessen bilden die Ops des Emulationscode-ROMs 232 eine Struktur für eine X86-Instruktion. Verschiedene Bit-Felder innerhalb der Op- Tabelle werden unter Benutzung einer von dem Emulationscode-Sequenzierer 510 ausgeführten Substitutionsfunktion substituiert. Einfach gesagt ersetzt die Substitutionsfunktion einige Bits des Ops mit anderen ausgewählten Bits.
X86-Instruktionen enthalten typischerweise einen Opcode gefolgt von einem modr/m-Byte. Das modr/m-Byte bezeichnete einen indexierenden Typ oder eine Registernummer, die mit der Instruktion zu nutzen ist. Das modr/m- Byte hat drei Felder, umfassend ein Modusfeld mit 2 Bit (MSB), ein reg-Feld mit 3 Bit (mittleres) und ein r/m-Feld mit 3 Bit (LSB). Das Modusfeld in Kombination mit dem r/m-Feld bildet 32 mögliche Werte, die acht Register und 24 Indizierungsmodi angeben. Das reg-Feld spezifiziert entweder eine Registernummer oder drei weitere Bits von Opcode-Information. Das r/m- Feld gibt entweder ein Register als Ort eines Operanden an oder es wird in Verbindung mit dem Modusfeld benutzt, um Register und Indizierungsmodi zu definieren.
Fig. 6A ist eine Registeroperation-(RegOp)Feidkodierungsgrafik, die zahlreiche Felder in dem RegOp-Format darstellt. In dem RegOp-Feld 610 sind die höchstwertigen Bits 36 und 37 freigegeben, um die Operation als eine RegOp zu bezeichnen. Das RegOp-Feld 610 enthält ebenfalls ein 6 Bit breites Operationstyp-(TYPE)Feld 612 an den Bitstellen [25 : 30], ein 4 Bit Erweiterungs-(EXT)Feld 614 an den Bitstellen [29 : 26], ein Nur-RU1-(R1)-Bit 616 an der Bitstelle [25], ein 3 Bit breites Operations-/Datengröße-(DSz)- Feld 618 an den Bitstellen [24 : 22], ein 5 Bit breites Ziel- (DEST)Generalregisterfeld 620 an den Bitstellen [21 : 17] und ein 5 Bit breites Quellel-(SRC1)Generalregisterfeld 622 an den Bitstellen [16 : 12]. Das RegOp-Feld 610 umfasst auch ein 1 Bit breites Status-gesetzt-(SS)Feld 624 an der Bitstelle [9], ein 1 Bit breites Unmittelbare-Quelle2-(I)Feld 626 an der Bitstelle [8] und ein 8 Bit breites unmittelbares Daten- oder Generalregister für Quelle2-Operanden (IMM8/SRC2)-Feld 628 an den Bitstellen [7 : 0]. Das TYPE-Feld 612 der RegOp-Kodierungen enthält wie folgt:
Verschiedene RegOp-Kodierungen, insbesondere xx01x-Kodierungen, geben bedingte Code-Abhängigkeiten an. Die Routieren- und Schieben-Ops sind funktional äquivalent mit der Ausnahme, dass unterschiedliche statmod-Bits zugewiesen werden.
Das Erweiterungsfeld (EXT) 614 wird in Kombination mit dem Bit < 0> des TYPE-Feldes 612 benutzt, um für MOVcc-Operationen einen S Bit breiten Bedingungscode anzugeben. Das Erweiterungsfeld (EXT) 614 wird auch für RDxxx/WRxxx-Operationen benutzt, um eine 4 Bit breite spezielle Registernummer anzugeben. Das Status-gesetzt-(SS)Feld 624 wird in Verbindung mit dem EXT-Feld 614 benutzt, um die Statusflags zu bezeichnen, welche von einer Operation betroffen sind. Für Operationen, in welchen das Statusgesetzt-(SS)Feld 624 auf eins gesetzt ist, was anzeigt, dass diese Op-Flags modifiziert, gibt das Erweiterungsfeld (EXT) 614 vier Statusmodifizierungsbits an, welche die Gruppe von Flags, welche durch die Op modifiziert worden sind, angibt. Für RDSEG-Ops gibt das EXT-FeId 614 ein 4 Bit breites Segment-(selector)Register an. Für eine bedingte WRFLG-Op stimmt die spezielle Registerkodierung mit dem gewünschten StatMod-Wert überein, wenn das SS-Feld gesetzt ist. Das Status-gesetzt-(SS)Feld 624 und das EXT-Feld 614 sind RegOp-Felder.
Die Bedingungscodes sind in fünf Bits kodiert, wobei das Bit < 0> des 5 Bit breiten Bedingungscode-Feldes angibt, ob die Bedingung oder ihr Komplement auf Wahrheit oder Zuweisung getestet werden soll, z. B. wenn cc< 0> gleich eins ist dann invertiere die Bedingung. Die Bits < 4 : 1> des 5 Bit breiten Bedingungscodes-(CC)Feldes spezifizieren die zu untersuchende Bedingung wie folgt:
Das EXT-Feld 614 wird benutzt, um die Bedingungsflags zu aktualisieren, umfassend sechs Flags, die den X86-Flags entsprechen, und zwei Emulationsflags. Die acht Flags sind unterteilt in vier Gruppen unter Benutzung eines Statusmodifikationsbits pro Gruppe von Flags. Das EXT-Feld 614 definiert das Erneuern der verschiedenen Bedingungscodeflags im wesentlichen unabhängig von der TYPE 612-Spezifikation, so dass funktional zusammenführende Flags in einer Gruppe überwacht und erneuert werden. Das Erneuern von zusammenhängenden Flags in einer Gruppe erhält vorteilhafterweise Steuerlogik. Das EXT-Feld 614 definiert einen Satz von Bits, welche die zu erneuernden Flags für eine bestimmte Instruktion bestimmen. Das Entkoppeln der Handhabung des Bedingungscodes von dem Operationstype unter Benutzung des unabhängigen TYPE 612 und des Status-gesetzt(SS)Feldes 624 erlaubt es einigen Operationen, definiert zu werden, welche keine Flags erneuern. Entsprechend ist es für diese Umstände, in denen das Erneuern von Bedingungsflags nicht notwendig ist, höchst vorteilhaft, das Erneuern der Flags zu unterbinden, um unnötige Abhängigkeiten von vorhergehenden Flagwerten zu vermeiden.
Das Nur-RU1-Feid 616 ist die Anzeige für Ops, welche an die erste Registereinheit 244 und nicht an die zweite Registereinheit 246 ausgegeben wurden, so dass das R1-Feld 616 ein Bit zum Hartkodieren einer Ausführungseinheit-Spezifikation ist. Daher zeigt das Nur-RU1-Feld 616 an, dass eine bestimmte Operation nur auf einer bestimmten Ausführungseinheit ausführbar ist, im allgemeinen weil nur die spezielle Ausführungseinheit eine in dieser Einheit implementierte Funktion umfasst. Das Status-gesetzt- (SS)Feld 624 modifiziert Statusflags entsprechend den Einstellungen des EXT-Feldes 614. Das I-Feld 626 gibt an, ob der Quelle2-Operand unmittelbar oder ein Generalregister ist. Das IMM8/SRC&sub2;-Feld 628 gibt ein 5 Bit breites Generalregister an, wenn das I-Feld 626 null ist. Das IMM8/SRC2- Feld 628 gibt einen unmittelbaren Wert mit Vorzeichen an, der auf die Größe der Operation erweitert wird, die von der DSz-Feldgröße angegeben wird, wenn das I-Feld 626 eins ist.
Für den Fall einer Registeroperations-(RegOp)Substitution ist die Operation (Op) von dem Op-Quadrupel eine Registeroperation (RegOp). Das Instruktionsregister 512 hält Instruktionsbytes, welche von dem vektorisierenden Dekoder 418 dekodiert werden. Während einer vektorisierenden Instruktionsdekodierung erzeugt der vektorisierende Dekodierer 418 einen ursprünglichen vektorisierenden Quadrupel und eine Eintrittspunktadresse, die auf den Inhalten des Instruktionsregisters 512 basiert. Zur gleichen Zeit initialisiert der vektorisierende Dekodierer 418 die Variablen der Emulationsumgebung, auch Emulationsumgebungsregister 516 genannt, aus verschiedenen Informationen basierend auf den Feldern des Instruktionsregisters 512 und basierend auf anderen Informationen. Die Informationen aus dem Emulationsumgebungsregister 516 werden der Op-Substitutionslogik zugeführt, welche die Substitutionsoperation ausführt.
Für RegOp-Substitutionen werden in den in Fig. 6A gezeigten Feldern des RegOp-Formats 610 verschiedene Substitutionen gemacht. Für die Ziel- (DEST) 620- und Quellel-(SRC1) 622-Felder einer RegOp-Operation gibt eine 5 Bit breite Registerkodierung ein Register an, unter Benutzung von direkten Registerspezifikatoren (0 bis 15) oder indirekten Registerspezifikatoren (Reg und RegM). Die direkten Registerspezifikatoren benennen direkt eines der sechszehn Register. Die indirekten Spezifikatoren, Reg und RegM, werden zu der Op-Dekodierungszeit durch die derzeitigen Registernummern (0 bis 15) aus dem Emulationsumgebungsregister 516 ersetzt. Die Ersetzung findet statt, wenn der Instruktionsdekodierer 230 eine Instruktion dekodiert, an eine Emulationscode-Sequenz in dem Emulationscode-ROM 232 vektorisiert, das Emulationsumgebungsregister 516 mit verschiedenen Feldern aus der Instruktion und anderer Information initialisiert. Während des Betriebs einer Emulationscode-Sequenz enthalten die Ops in der Sequenz verschiedene Felder wie indirekte Registerspezifikatoren-Felder und Größendatenfelder, welche ersetzt werden in Abhängigkeit von den derzeitigen Werten des Emulationsumgebungsregisters 516. Die Op-Substitutionslogik bestimmt, ob die Kodierungen für ein Feld indikativ sind für ein ersetztes Feld. Eine Kodierung für ein Feld kann anzeigen, dass andere Felder ersetzt sind. Z. B. ist die Kodierung von indirekten Spezifikatoren Reg und RegM in den dest 520- und src1 622-Feldern indikativ dafür, dass das DSz-Feld 618 auch ersetzt wird.
Im Hinblick auf das DSz-Feld 618 arbeiten die Instruktionen des X86- Instruktionssatzes mit 8 Bit-, 16 Bit- oder 32-Bit-Daten, abhängig von der derzeitigen Vorgabebedingung des Prozessors 120. Das DSz-Feld 618 umfasst drei Bits, welche eine Datengröße von einem Byte, zwei Bytes oder drei Bytes anzeigen. Für Instruktionen, welche die Substitution der Datengröße angeben, bezeichnen die indirekten Größe-Spezifikatoren eine A- Größe, D-Größe oder S-Größe. Eine Datengrößensubstitution wird durch ein 1B-Bit und D-Bit bestimmt. Das B-Bit wird bestimmt durch das derzeitige Stapelsegmentregister (SS). Das D-Bit wird von dem Codesegmentregister (CS) spezifiziert. Für indirekte Größe-Spezifikatoren wird die S-Größe durch das B-Bit bestimmt. Die effektive Adress-(A)Größe und die effektive Daten- (D)Größe werden durch das D-Bit bestimmt, möglicherweise überstimmt durch Adress- oder Datengrößenüberschreib-Präfixe und in dem Emulationsumgebungsregister 516 gehalten. Im allgemeinen werden die indirekten Spezifikatoren der A-Größe, D-Größe und S-Größe durch die absolute Kodierung für die Bytes oder die vier Bytes substituiert oder ersetzt. Wenn z. B. eine D-Größe ausgewählt ist, wird die Datengröße in zwei Bytes oder vier Bytes aufgelöst, in Abhängigkeit von der effektiven Datengröße, wie sie durch ein Bit in dem Emulationsumgebungsregister 516 angegeben ist. Ähnlich wird die effektive Adressgröße durch ein Bit in dem Emulationsumgebungsregister 516 als entweder zwei Byte oder vier Byte angegeben, wenn ein indirekter Größenspezifikator die A-Größe kodiert. Wenn der indirekte Spezifikator die S-Größe auswählt, gibt ein B-Bit an, ob zwei Byte oder vier Byte ersetzt werden.
Die Substitution des Imm8/Src2-Feldes 628 wird nur ausgeführt, wenn der Quelle2-(src2)Operand ein indirekter Registerspezifikator anstatt eines unmittelbaren Wertes ist. Die Op-Substitutionslogik bestimmt, ob das Enkodieren für das unmittelbare (I) Feld 626 anzeigend ist für eine Ersetzung in dem imm8/src2-Feld 628 durch das Zugreifen auf das I-Feld-Bit 626 und ersetzt, falls ein indirekter Registerspezifikator ausgewählt ist, eine 5 Bit breite Generalregisterbestimmung in das imm8/src2-Feld 628 des RegOp- Formats 610. Für einen registergespeicherten src2-Operanden, der die speicherindizierte Adressform benutzt, findet keine Substitution statt und das imm8/src2-Feld 628 des RegOp-Formats 610 wird mit einem Indexwert geladen. Das RegOp-Format 610 ist ein Format vom RISC-Typ mit drei (zwei Quellen und einem Ziel) Operanden, umfassend das src1-Feld 622, das imm8/src2-Feld 628 und das dest-Feld 620. Ein standardgemäßes X86-Format ist ein Zwei-Operanden-Format. Das I-Feld 626 erlaubt es vorteilhafterweise, dass der Quelle2-Operand flexibel die Form entweder eines unmittelbaren Wertes oder eines Generalregisters annehmen kann.
Das RegOp-Feld 610 definiert eine Gruppe von spezielle Ops, umfassend vorzeichenbehaftetes Multiplexieren (MULIS), Multiplizieren ohne Vorzeichen (MULIU), Multiplizieren von hohen Daten (MULEH) und das Multiplizieren von niedrigen Daten (MULEL)-Ops, welche Teile von Multiplikations- und Entladeoperativnen ausführen, so dass eine Multiplikationsinstruktion aus einer Mehrzahl dieser spezifischer Multiplikations-Ops zusammengesetzt wird. Eine Divisionsoperation wird ähnlich ausgeführt durch einen Kombination einer Mehrzahl von spezifischen einfachen Divisions-Ops, umfassend 1- und 2-bitiges Dividieren (DIV1), stufenweises Dividieren (DIV2), Divisionsrest-Entladung (DIVER) und Divisionsquotienten-Entladung (DIVEQ) Ops, z.B. eine Iteration mit zwei Bit für eine Division ausführen.
Die WRIP-Op schreibt den X86-Programmzähler (PC) zur Änderung der Ausführungsadresse, wenn die WRIP-Op zurücktritt, was das Holen einer Instruktion an der gewünschten Adresse neu startet. Die WRIP-Op ist insbesondere für den Fall vorteilhaft, dass für mehrere Instruktionen das Dekodieren der Länge der Instruktion schwer oder unmöglich ist, so dass zur Vermeidung der Komplexität der Logik die implementierte Logik die Länge nicht korrekt dekodiert. Die Instruktion ist auch vorteilhaft zum Serialisieren der Instruktionsholoperationen und zum Emulieren von Sprüngen. Effizienz wird erreicht, indem der Logik erlaubt wird, die Instruktionslänge nicht korrekt zu dekodieren und den Programmzähler unter Benutzung der WRIP- Op zu setzen, so dass die nicht korrekt dekodierte Instruktionslänge ignoriert wird.
Die Selektorprüf-(CHKS)Op wird genutzt zum Handhaben von Segmentbeschreibern und Selektoren des X86-Instruktionssatzes. Die CHKS-Op initiiert einen Prozess des Ladens eines Segmentregisters, umfassend die Operationen zum Überprüfen für einen Null-Selektor und zum Erzeugen eines Adressversatzes in einer Beschreiber-Tabelle.
Fig. 6B ist eine Lade-/Speicher-Operations-(LdStOp)Feldenkodierungsgrafik, welche verschiedene Felder in dem LdStOp-Format darstellt. In dem LdStOp-Feld 630 sind die höchstwertigen Bits 36 und 37 auf eines bzw. null gesetzt, um die Operation als eine LdStOp zu bezeichnen. Das LdStOp-Feld 530 umfasst auch ein 4 Bit breites Operationstyp-(TYPE)Feld 632 an den Bitstellen [35 : 32], und ein 2 Bit breites Indexskalierungsfaktor-(ISF)Feld 634 an den Bitstellen [31 : 30], das die Faktoren 1x, 2x, 4x und 8 angibt. Das LdStOp-Feld 630 enthält ein 4 Bit breites Segmentregister-(SEG)Feld 636 an den Bitstellen [29 : 26] und ein 2 Bit breites Adressberechnungsgrößen-(ASz)Feld 638 an den Bitstellen [25 : 24], welches eine Auswahl zwischen der A-Größe, der S-Größe, der D-Größe und vier Bytes bestimmt. Die effektiven Daten- und Adressgrößen werden für LdStOps auf die gleiche Art wie bei der RegOp-Substitution ersetzt. Das LdStOp-Feld 630 enthält ein 2 Bit breites Datengröße-(DSz)Feld 640 an den Bitstellen [23 : 22], welches die Größen (1, 2, 4 und Dsize Bytes) für ganze Zahlen und Größen (2, 4 und 8 Bytes) für Gleitkommazahlen angibt, ein 5 Bit breites Daten-Quelle/Ziel- (DATA)Generalregisterfeld 642 an den Bitstellen [21 : 17] und ein 1 Bit großes Großes-Versetzungs-(LD)Bit 644 an der Bitstelle [16], welches eine große Versetzung angibt bei Benutzung der Disp8-Versetzung von einer vorhergehenden Op. Das LD-Bit 644 ist sinnvoll, da Ops lediglich 38 Bit breit sind, das ist ein Instruktionsformat, das nicht ausreichend ist, um eine komplette 32 Bit-Versetzung innerhalb einer Operation zu spezifizieren. Nur in 8 Bit kodierte Versetzungen sind möglich für ein einzelnes LdStOp-Feld 630. Das LD-Bit 644 zeigt, wenn es gesetzt ist, an, dass die unmittelbar vorhergehende Op eine komplette 32 Bit breite Versetzung liefert. Das LdStOp-Feld 630 enthält ein 4 Bit breites Basis-(BASE)Generalregisterfeld 646 an den Bitstellen [15 : 12]. Das LdStOp-Feld 630 enthält weiterhin ein 8 Bit breites mit Vorzeichen versehenes Verschiebungs-(DISP8)Feld 648 an den Bitstellen [11 : 4] und ein 4 Bit breites Index-(INDEX)Generalregister 649 an den Bitstellen [3 : 0]. Das TYPE-Feld 632 der LdStOp-Kodierungen enthält wie folgt:
Für den Fall einer Lade-/Speicher-Operation-(LdStOp)Ersetzung bestimmt der Emulationscode-Sequenzierer 510 zuerst, ob ein LOCK-Präfix während des Aufbaus der Emulationsumgebung quittiert worden ist. Wenn die bezeichnete LdStOp-Operation ein Lade ganze Zahl mit Speichertest(LDST) ist und der LOCK-Präfix quittiert ist, ersetzt der Emulationscode-Sequenzierer 510 den LDST-Opcode mit einem Lade ganze Zahl mit Speichertest, fest (LDSTL) Opcode.
Für LdStOp-Substitutionen werden verschiedene Ersetzungen in die Felder des in Fig. 6B gezeigten LdStOp-Format 630 vorgenommen. Für das Datenregister-(DataReg)Feld 642 einer LdStOp-Operation spezifiziert eine 5 Bit breite Registerkodierung ein Register, das einen direkten Registerspezifikator (0 bis 15) oder einen indirekten Registerspezifikator (Reg und RegM) benutzt. Die direkten Registerspezifikatoren bezeichnen direkt eines von sechszehn Registern. Die indirekten Spezifikatoren, Reg und RegM, werden zum Zeitpunkt der Op-Dekodierung von den aktuellen Registernummern (0 bis 15) aus dem Emulationsumgebungsregister 516 ersetzt. Die Ersetzung findet statt, wenn der Instruktionsdekodierer 230 eine Instruktion dekodiert, eine Emulationscode-Sequenz in das Emulationscode-ROM 232 führt, das Emulationsumgebungsregister 516 mit verschiedenen Feldern aus der Instruktion und anderer Information initialisiert. Während der Operation einer Emulationscode-Sequenz enthalten die Ops in der Sequenz verschiedene Felder, wie indirekte Registerspezifikatoren-Felder und Datengrößenfelder, welche basierend auf den aktuellen Werten des Emulationsumgebungsregisters 516 ersetzt werden. Die Op-Substitutionslogik bestimmt, ob die Kodierungen für ein Feld bezeichnend sind für ein ersetztes Feld. Eine Kodierung für ein Feld kann anzeigen, dass andere Felder substituiert werden. Die bestimmte Ersetzung hängt davon ab, ob das Datenregister (DataReg) 642 unter Benutzung der Registeradressierung oder der speicherindexierten Adressierung adressiert wird. Wenn die Form der Registeradressierung zugewiesen ist, wird das DataReg-Feld 642 des LdStOp- Formats 630 von dem indirekten Spezifikator Reg bestimmt. Wenn die speicherindizierte Adressierung zugewiesen ist, wird das DataReg-Feld 642 des LdStOp-Formats 630 durch den indirekten Spezifikator RegM bestimmt.
Im Hinblick auf das ASz-Feld 638 und das DSz-Feld 640 arbeiten die Instruktionen des X86-Instruktionssatzes auf 8 Bit, 16 Bit oder 32 Bit Daten, abhängig von der aktuellen Vorgabebedingung des Prozessors 120. Das ASz-Feld 638 und DSz-Feld 640 enthält jeweils 2 Bits, welche die Datengröße von einem Byte, zwei Bytes oder drei Bytes anzeigen. Für Instruktionen, welche die Substitution der Datengröße angeben, bestimmen die indirekten Größe-Spezifikatoren eine A-Größe, D-Größe oder S-Größe. Eine Datengrößensubstitution wird bestimmt von einem B-Bit und einem D-Bit. Das B-Bit wird von dem derzeitigen Stapelsegmentregister (SS) spezifiziert. Das D-Bit wird von dem Codesegmentregister (CS) spezifiziert. Für indirekte Größe-Spezifikatoren wird die S-Größe durch das B-Bit bestimmt. Die effektive Adress-(A)Größe und die effektive Daten-(D)Größe werden durch das D-Bit festgelegt, möglicherweise aufgehoben von den Adress- oder Datengrößenüberschreib-Präfixen, und in dem Emulationsumgebungsregister 516 gehalten. Im allgemeinen werden die indirekten Spezifikatoren der A-Größe, D-Größe und S-Größe durch den absoluten Code für die Bytes oder vier Bytes substituiert oder ersetzt. Falls z. B. eine D-Größe ausgewählt ist, wird die Datengröße in zwei Bytes oder vier Bytes aufgelöst, basierend auf der effektiven Datengröße, wie sie durch ein Bit in dem Emulationsumgebungsregister 516 angegeben ist. Ähnlich wird, falls ein indirekter Größespezifikator die A-Größe kodiert, die effektive Adressgröße durch ein Bit in dem Emulationsumgebungsregister 516 als entweder zwei Bytes oder vier Bytes angegeben. Wenn der indirekte Spezifikator die S-Größe auswählt, bestimmt ein B-Bit, ob zwei Byte oder vier Bytes ersetzt werden.
Die LdStOp-Operation wird überprüft, um festzustellen, ob ein 4 Bit breites Segmentregisterfeld 636 zu ersetzen ist. Wenn die Emulationsumgebung aufgebaut wird, werden Segmentübersteuerungs-Präfixe überwacht. Segmentübersteuerungs-Präfixe beeinflussen das Dekodieren einer nachfolgenden Instruktion, wenn die Erzeugung einer LdStOp von dem effektiven Operandensegment der Instruktion abhängt. Das Vorgabesegment ist DS oder SS, was von dem zugehörigen generellen Adressmodus abhängt, und wird durch das Segment ersetzt, welches in dem letzten Segment-Übersteuerungs-Präfix angegeben ist. Der Segmentregister-Adressraum wird von der konventionellen X86-Spezifikation auf 4 Bits erweitert, um die Unterstützung von zusätzlichen Spezialsegmentregistern zu erlauben. Das Segmentregister ist wie folgt kodiert:
Zum Zeitpunkt der Op-Dekodierung ersetzt der Emulationscode-Sequenzierer 510 das "OS"-Segmentregister mit der aktuellen 3 Bit breiten Segmentregisternummer aus der Emulationsumgebung. Somit ist ein Segmentregister alternativ in einem speziellen Segmentregister hartkodiert oder auf das Segment OS gesetzt, welches das aktuelle effektive Datensegmentregister bezeichnet, aber welches durch eine Segmentübersteuerung aufgehoben werden kann.
Das Emulationsspeichersegmentregister (MS) bezeichnet den Zugriff auf einen speziellen Emulationsspeicher zur Benutzung in der Emulationsumgebung. Die Beschreiber-Tabelle SegReg TS bezeichnet den Zugriff auf entweder die globale Beschreiber-Tabelle (GDT) oder die lokale Beschreiber-Tabelle (LDT).
Fig. 6C ist eine Lade unmittelbar Operations (LIMMOp) feldkodierte Grafik, welche verschiedene Felder in dem LIMMOp-Format zeigt. In dem LIMMOp- Feld 650 sind die höchstwertigsten Bits 36 und 37 beide auf eines gesetzt, um die Operation als eine LIMMOp zu bestimmen. Das LIMMOp-Feld 650 enthält auch einen 16 Bit breiten unmittelbar Hochteil (ImmHi) 652 an den Bitstellen [35 : 20], ein 5 Bit breites Ziel-(DEST)Generalregisterfeld 654 an den Bitstellen [19 : 16] und ein 16 Bit unmittelbar Niedrigteil (ImmLo) 656 an den Bitstellen [15 : 0]. ImmHi 652 und ImmLo 656 werden kombiniert, um einen 32 Bit-Wert anzugeben, der in das durch das DEST-Feld 654 angegebene Register geladen wird.
Fig. 6D ist eine Spezialoperation (SpecOp) feldkodierte Grafik, welche verschiedene Felder in dem SpecOp-Format darstellt. In dem SpecOp-Feld 660 sind die höchstwertigen Bits 35 bis 37 entsprechend zu 101 gesetzt, um die Operation als eine SpecOp zu bestimmen. Das SpecOp-Feld 660 enthält auch ein 4 Bit breites Operationstype-(TYPE)Feld 662 an den Bitstellen [34 : 31], ein 5 Bit breites Bedingungscode-(CC)Feld 664 an den Bitstellen [30 : 26] und ein 2 Bit breites Datengröße-(DSz)Feld 666 an den Bitstellen [23 : 22], welches die Größen von 1,4 und DSize-Bytes angibt. Das SpecOp- Feld 660 enthält ein 5 Bit breites Zielgeneralregister-(DEST)Feld 668 an den Bitstellen [21 : 17] und ein 17 Bitbreites unmittelbar konstant (Imm17) Feld 670 an den Bitstellen [16 : 0]. Das Imml7-Feld 670 hält entweder einen 17 Bit breiten unmittelbaren Wert mit Vorzeichen oder eine 14 Bit breite Op- Adresse. Das CC-Feld 664 wird nur von BRCOND-Ops genutzt. Das DSz-Feld 666 und das DEST-Feld 668 werden nur von LDKxx-Ops genutzt. Eine Standard-NOP-OP ist als "LIMM+0,< undefined> definiert. Das TYPE-Feld 662 der SpecOp-Kodierungen enthält wie folgt:
Für den Fall der Ersetzung von Spezialoperationen (SpecOp) wird die SpecOp überprüft, um festzustellen, ob ein Zielgeneralregister (DestReg) unter Benutzung des Registeradressierens oder Benutzung des speicherindizierten Adressierens adressiert wird. Wenn die Form des Registeradressierens zugewiesen ist, ersetzt der Emulationscode-Sequenzierer 510 ein vorher gespeichertes modr/m-reg-Feld aus dem Reg-Register in das DestReg- Feld 668 des in Fig. 6D gezeigten SpecOp-Formats 660. Wenn die form der speicherindizierten Adressierung zugewiesen ist, ersetzt der Emulationscode-Sequenzierer 510 ein vorher gespeichertes modr/m-regm-Feld aus dem Regm-Register in das DestReg-Feld 668 des SpecOp-Formats.
Die SpecOp wird auch überprüft, um festzustellen, ob das Datengröße- (DSz)Feld 666 ersetzt werden soll. Ein Substitutionswert für das DSz-Feld wird vor der Op-Behandlung durch den Emulationscode-Sequenzierer 510 bestimmt, wenn die Emulationsumgebung in Übereinstimmung mit der aktuellen Segmentvorgabeinformation, wie sie durch jegliche Operandengrößeübersteuerung definiert ist. Das DSz-Feld 666 ist auf eine Größe von 1 Byte, 4 Bytes oder einer alternativen definierten D-Größe gesetzt. Der Emulationscode-Sequenzierer 510 ersetzt einen zugewiesenen Substitutionswert in das DSz-Feld 666 des SpecOp-Fomats 660.
Wenn eine SpecOp eine Ladekonstante, Daten-(LDKD)Operation ist, passt der Emulationscode-Sequenzierer 510 Daten an oder skaliert sie in dem 16 Bit breiten unmittelbar (Imm17) Feld 670, basierend auf der aktuellen effektiven Datengröße, welche durch das Datengröße-(DSz)Feld 666 spezifiziert ist.

Registeradressraum und Emulationsschnittstelle

Der Prozessor 120 implementiert einen Registeradressraum, der im Vergleich zu einem konventionellen Adressraum eines X86-Registers erweitert ist. Der Adressraum des Prozessor 120 Registers wird durch 5 Bits adressiert, so dass 2&sup5; oder 32 Register definiert werden können. Acht Register entsprechen den X86-architekturalen Registern. Sechszehn zusätzliche temporäre Register sind hinzugefügt. Das Datengröße-(DSz)Feld bestimmt entweder direkt oder indirekt die Datengröße der Operation. Für eine Einzelbyte-Operation ist das von dem Registerkodierfeld festgeschriebene Register unterschiedlich von einem 2 oder 4 Byte-Register, das durch das gleiche Registerkodierfeld zugewiesen wird. Die Datengröße einer Operation kann entweder ein Byte (1B) oder zwei/vier Bytes (2B/4B) für RegOps, SpecOps und das Datenfeld 642 von LdStOps sein. Die Datengröße ist immer zwei/vier Bytes (2B/4B) für die Basis 646 und Index 649 Felder der LdStOps.
Die Prozessor 120 Registerfeldkodierung ist wie folgt:
Die unmittelbaren Datentemporärregister werden benutzt beginnend t8 zur Wertableitung oder endian-Bedeutung. Die "reg" und "regm" Registerzahlen werden zum Zeitpunkt der Op-Dekodierung von den aktuellen 3 Bit Registernummern aus der Emulationsumgebung ersetzt, insbesondere durch Ersetzen von Reg/RegM mit "00xxx". Die 3 Bits bestimmen ein Register aus den ersten acht Registern (AX bis DI).
Die Organisation des Op-Formats und des erweiterten Registeradressraums definiert einen flexiblen internen mikroarchitekturalen Zustand des Prozessors 120. Der X86-architekturale Zustand ist lediglich ein Untersatz des mikroarchitekturalen Zustands des Prozessors 120. Der erweiterte Registeradressraum enthält eine erweiterte Anzahl von temporären Registern im Vergleich zu dem Adressraum des X86-Registers. 24 Register werden von dem erweiterten Registeradressraum des Prozessors 120 unterstützt, nur 8 dieser Register korrespondieren mit X86-architekturalen Registern und 16 zusätzliche temporäre Register werden unterstützt. Ähnlich umfasst der Prozessor 120 eine erweiterte Anzahl an Flag-Registern, von denen lediglich einige den X86-Statusflags entsprechen.
In einem Ausführungsbeispiel des Prozessors 120 z. B. wird ein Emulationscarryflag definiert als Zusatz zu dem konventionellen Carryflag und wird der Emulationsumgebung zugeordnet. Also wird eine konventionell Additionsinstruktion definiert, welche das Carryflag setzt und den permanenten architekturalen Zustand des Prozessors 120 verändert. Eine Emulationsadditionsoperation ist definiert, welche das Emulationscarryflag setzt und nicht das konventionelle Carryflag. Verschiedene Instruktionen werden definiert, um in Abhängigkeit von dem Emulationscarryflag zu springen, während andere Instruktionen in Abhängigkeit von dem konventionellen Carryflag springen. Also ist der Prozessor 120 gleichzeitig betreibbar sowohl in einem konventionellen mikroarchitekturalen Zustand als auch in einem emulierten mikroarchitekturalen Zustand. Diese Operation in einer Emulationsumgebung erlaubt es dem Prozessor eine Emulationsmikrosequenz auszuführen und nicht in den sichtbaren mikroarchitekturalen Zustand zu wechseln.
Bezugnehmend auf Fig. 8 wird die Substitutionstechnik anhand eines speziellen Beispieles erläutert. Eine ADD-Registerinstruktion des X86-Instruktionssatzes ist kodiert als ein Opcode gefolgt von einem modr/m-Byte. Das 8 Bit breite Opcode-Feld der ADD-Instruktion wird im Zusammenhang mit der Angabe in dem modr/m-Byte, das die Instruktion eine Registerinstruktion ist, benutzt, um einen bestimmten ROM-Eintrittspunkt abzuleiten, der das Emulationscode-ROM 232 veranlasst, eine Op für eine ADD RegM zu Reg Operation zu erzeugen. Die Reg und RegM-Felder in dem Instruktionsregister 512 geben an, dass Reg zu AX wird bzw. RegM zu BX wird. Die Reg und RegM-Felder werden von dem Instruktionsregister 512 auf die Op-Substitutionsschaltung 522 angewandt, so dass eine Substitution erzielt wird. Das Emulationscode-ROM 232 enthält Op-Tabellen für lediglich eine limitierte Anzahl von Ops und die Op-Substitutionsschaltung 522 füllt die Tabellen verschiedenartig, um eine große Anzahl von verschiedenen Ops zu erzeugen.
Verweisend auf die aufgeführten Prozessor 120 Registerfeldkodierungen ist das Register AX durch einen reg-code, 0 0 0 0 0, hartspezifiziert. Alternativ spezifizieren vier mögliche reg-Kodierungen, 1 1 0 x x, die Ersetzung eines Registers. Die Ersetzung wird ausgeführt basierend auf der bestimmten emulierten Instruktion und dem derzeitigen Zustand des Prozessors 120 inklusive der derzeitigen Emulationsumgebung. Im allgemeinen wird die Ersetzung und die Ausführung einer Operation durchgeführt durch Ersetzen: (1) einer Kodierung für eine Reg in das dest-Feld 620, (2) einer Kodierung für ein Register Reg in das src1-Feld 622, (3) einer Kodierung für ein RegM in das ImmB/Src2-Feld 628, (4) einer null in das mittelbar (I) Feld 626 und (5) eines der durch die Datengröße bestimmten 1, 2 oder 4 Bytes in das DSz-Feld 618.

Text für Offenbarung des Systems

Es ist an eine große Vielzahl von Konfigurationen der Computersysteme gedacht, wobei jedes einen Instruktionsdekoder mit einer Emulation hat, welche indirekte Spezifikatoren in Übereinstimmung mit der vorliegenden Erfindung benutzt. Z.B. enthält ein derartiges Computersystem (z. B. Computersystem 1000) einen Prozessor 120, der einen Instruktionsdekodierer bereitstellt, umfassend eine in Übereinstimmung mit der vorliegenden Erfindung indirekte Spezifikatoren benutzende Emulation, ein Speicheruntersystem (z.B. RAM 1020, eine Grafikkarte 1010, eine Laufwerkssteuerung/Anschluss 1030, verschiedene Eingangs-/Ausgangsanschlüsse und Adapter (z. B. parallele Schnittstelle 1009, serielle Schnittstelle 1008, Netzwerkadapter 1007, usw.) und entsprechende externe Geräte (z. B. Anzeige 1001, Drucker 1002, Modem 1003, Tastatur 1006 und Datenspeicher). Der Datenspeicher enthält derartige Geräte, wie eine Festplatte 1032, eine Diskette 1031, eine Bandeinheit, ein CD-ROM, eine Jukebox, ein redundantes Array von billigen Laufwerken (RAID), einen Flash-Speicher usw.
Obwohl die Erfindung im Hinblick auf verschiedene Ausführungsbeispiele beschrieben worden ist, ist klar, dass diese Ausführungsbeispiele erläuternd sind und dass der Umfang der Erfindung nicht auf diese limitiert ist. Zahlreiche Variationen, Modifikationen, Zusätze und Verbesserungen der beschriebenen Ausführungsbeispiele sind möglich. Des weiteren können Strukturen und Funktionalitäten, die in diesem exemplarischen Ausführungsbeispiel als Hardware dargestellt sind auch als Software, Firmware oder Microcode in alternativen Ausführungsbeispielen implementiert werden. Die Beschreibung stellt zum Beispiel einen Makroinstruktionsdekodierer dar, der Kurzdekodierpfade hat, umfassend drei Rotatoren 430, 432 und 434, drei Instruktionsregister 450, 452 und 545 und drei Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414. In anderen Ausführungsbeispielen wird eine unterschiedliche Anzahl von Kurzdekodiererpfaden verwirklicht. Ein Dekodierer, der zwei Dekodierpfade einsetzt, ist höchst geeignet. Diese und andere Variationen, Modifikationen, Zusätze und andere Verbesserungen mögen in den Bereich der Erfindung fallen, wie sie in den folgenden Ansprüchen definiert ist.

Claims

1. Instruktionsdekodier-Emulationsschaltung (231) für einen Prozessor (120), mit:

einem Instruktionsregister (512) zum Halten eines Instruktionscodes, wobei das Instruktionsregister mehrere Felder für kodierte Bits innerhalb des Instruktionscodes aufweist;

einer zwecks Empfangs des Instruktionscodes mit dem Instruktionsregister verbundenen Eintrittspunktschaltung (514) zum Ableiten eines Eintrittspunkts aus dem Instruktionscode;

einem zwecks Empfangs des abgeleiteten Eintrittspunkts mit der Eintrittspunkschaltung verbundenen Emulationscode-Sequenzierer (510) zum Erzeugen von Steuersignalen, die eine Sequenz von Operationen (Ops) steuern; und

einem zwecks Empfangs der Steuersignale mit dem Emulationscode- Sequenzierer (S10) verbundenen Emulationscodespeicher (520), der mehrere Op-Sequenzen und Sequenzsteuercodes speichert, wobei der Emulationscodespeicher (520) einen ersten Ausgangsanschluss zum Erzeugen von Op-Sequenzen und einen zweiten Ausgangsanschluss zum Erzeugen von Sequenzsteuercodes aufweist, und wobei der Sequenzsteuercode-Ausgangsanschluss mit dem Emulationscode- Sequenzierer (510) verbunden ist; gekennzeichnet durch:

einer Operations-(Op-)Substitutionsschaltung (522), die zwecks Empfangs einer Op-Sequenz mit dem ersten Ausgangsanschluss des Emulationscodespeichers (520) verbunden und zwecks Empfangs gewählter Instruktionscode-Felder für kodierte Bits mit dem Instruktionsregister (512) verbunden ist, wobei die Op-Substitutionsschaltung (522) zum Substituieren gewählter Felder der Instruktionscode-Bitfelder in der Op-Sequenz vorgesehen ist und die Substitution gemäß direkten Spezifikatoren und indirekten Spezifikatoren steuert, die durch Bit-Felder der Instruktion bezeichnet sind.

2. Instruktionsdekodier-Emulationsschaltung nach Anspruch 1, bei der das Instruktionsregister (512) mehrere Felder aufweist, wobei ein Feld basierend auf einer Kombination aus einer aktuellen Instruktion und einem aktuellen Zustand des Prozessors (120) einschließlich einer Emulationsumgebung gesetzt wird.

3. Instruktionsdekodier-Emulationsschaltung nach Anspruch 1, bei der die Emulationsumgebung ein modr/m reg-Feld in ein Reg-Register und ein modr/m regm-Feld in ein Regm-Register lädt und die Op-Substitutionsschaltung (522) die Reg- und RegM-Register in gewählten Feldern der Instruktionscode-Bitfelder der Op-Sequenz lädt, derart, dass der Emulationscodespeicher (520) einen einzelnen ROM-Eintrittspunkt zum Erzeugen von Ops aufweist, die entsprechend mehrerer unterschiedlicher Register-Spezifikationen arbeiten.

4. Instruktionsdekodier-Emulationsschaltung nach Anspruch 1, bei der die Emulationsumgebung eine Datengröße-Spezifikation lädt und die Op- Substitutionsschaltung (522) die Datengröße-Spezifikation in ein Datengröße-Feld der Instruktionscode-Bitfelder der Op-Sequenz lädt, derart, dass der Emulationscodespeicher (520) einen einzelnen ROM- Eintrittspunkt zum Erzeugen von Ops aufweist, die entsprechend mehrerer unterschiedlicher Register-Größen arbeiten.

5. Instruktionsdekodier-Emuiationsschaltung nach Anspruch 1, bei der die Emulationsumgebung einen Speichersegment-Deskriptor lädt und die Op-Substitutionsschaltung (522) den Speichersegment-Deskriptor in ein Segmentdeskriptor-Feld der Instruktionscode-Bitfelder der Op- Sequenz lädt, derart, dass der Emulationscodespeicher (520) einen einzelnen ROM-Eintrittspunkt zum Erzeugen von Ops aufweist, die in mehreren unterschiedlichen Speichersegmenten arbeiten.

6. Instruktionsdekodier-Emulationsschaltung nach Anspruch 1, bei der die Emulationsumgebung eine Adressgröße-Spezifikation lädt und die Op- Substitutionsschaltung (522) die Adressgröße-Spezifikation in einem ASz-Feld substituiert.

7. Instruktionsdekodier-Emulationsschaltung nach Anspruch 1, bei der die Emulationsumgebung eine Datengröße-Spezifikation lädt und die Op- Substitutionsschaltung (522) die Datengröße-Spezifikation in einem DSz-Feld substituiert.

8. Verfahren zum Betätigen einer Instruktionsdekodier-Emulationsschaltung (231) in einem Prozessor (120), mit den folgenden Schritten:

Eingeben eines Instruktionscodes in ein Instruktionsregister (512), das mehrere Felder für kodierte Bits innerhalb des Instruktionscodes aufweist;

selektives Aktualisieren verschiedener der mehreren Felder für kodierte Bits entsprechend dem Prozessor-Zustand;

Ableiten eines Eintrittspunkts aus dem Instruktionscode;

Adressieren eines Emulationscodespeichers (520) entsprechend dem abgeleiteten Eintrittspunkt, wobei der Emulationscodespeicher mehrere Op-Sequenzen speichert;

Ausgeben einer adressierten Operation aus dem Emulationscodespeicher (520);

Substituieren gewählter Felder für kodierte Bits des Instruktionscodes in der adressierten Operation; und

Steuern der Substitution entsprechend den direkten Spezifikatoren und den indirekten Spezifikatoren, die durch das Bit-Feld der Instruktion bezeichnet sind.

9. Verfahren zum Betätigen einer Instruktionsdekodier-Emulationsschaltung in einem Prozessor, gemäß Fig. 8, mit den folgenden Schritten:

Ableiten eines Eintrittspunkts aus dem Instruktionscode;

Empfangen des abgeleiteten Eintrittspunkts und Erzeugen von Steuersignalen zum Steuern einer Sequenz von Operationen (Ops);

Ausgeben von Op-Sequenzen aus dem Emulationscodespeicher;

Empfangen und Ausgeben der Sequenzsteuercodes aus dem Emulationscodespeicher;

Empfangen einer Op-Sequenz aus dem Emulationscodespeicher und Substituieren gewählter Felder für kodierte Bits des aus dem Instruktionsregister empfangenen Instruktionscodes in der adressierten Operation; und

Steuern der Substitution entsprechend den direkten Spezifikatoren und den indirekten Spezifikatoren, die durch Bit-Felder der Instruktion bezeichnet sind.

10. Instruktions-Decoder (220) für einen Superskalar-Prozessor, mit:

mehreren Makroinstruktions-Decodern (410,412, 414) eines ersten Typs zum gleichzeitigen Dekodieren mehrerer Instruktionen in einer vorbestimmten Gruppe von Instruktionen eines ersten Typs; und

einer Instruktionsdekodier-Emulationsschaltung (231) gemäß Anspruch 1.

11. Instruktions-Decoder für einen Superskalar-Prozessor nach Anspruch 10, wobei der Instruktions-Decoder zum Konvertieren von CISC-Typ- Instruktionen zu RISC-Typ-Operationen vorgesehen ist, und wobei die mehreren Makroinstruktions-Decoder des ersten Typs zum gleichzeitigen Dekodieren mehrerer CISC-Typ-Instruktionen in einer vorbestimmten Gruppe erster RISC-Typ-Instruktionen vorgesehen sind; wobei

der durch den Emulations-ROM-Decoder dekodierte Instruktionscode ein zweiter CISC-Typ-Instruktonscode ist.

12. Computersystem mit:

einem Speicher-Untersystem zum Speichern von Daten und Instruktionen; und

einem betriebsmäßig zum Zugreifen auf die in dem Speicher-Untersystem gespeicherten Daten und Instruktionen geschalteten Prozessor, der einen Instruktions-Decoder (220) gemäß Anspruch 10 enthält.

13. Decoder für einen Prozessor, mit einer Instruktionsdekodier-Emulationsschaltung (231) gemäß Anspruch 1.