DE69629383T2 - Superskalarer mikroprozessor mit risc86 befehlssatz - Google Patents

Superskalarer mikroprozessor mit risc86 befehlssatz Download PDF

Info

Publication number
DE69629383T2
DE69629383T2 DE69629383T DE69629383T DE69629383T2 DE 69629383 T2 DE69629383 T2 DE 69629383T2 DE 69629383 T DE69629383 T DE 69629383T DE 69629383 T DE69629383 T DE 69629383T DE 69629383 T2 DE69629383 T2 DE 69629383T2
Authority
DE
Germany
Prior art keywords
bit
instruction
operations
register
command
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69629383T
Other languages
English (en)
Other versions
DE69629383D1 (de
Inventor
G. John FAVOR
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GlobalFoundries Inc
Original Assignee
Advanced Micro Devices Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced Micro Devices Inc filed Critical Advanced Micro Devices Inc
Publication of DE69629383D1 publication Critical patent/DE69629383D1/de
Application granted granted Critical
Publication of DE69629383T2 publication Critical patent/DE69629383T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/74—Selecting or encoding within a word the position of one or more bits having a specified value, e.g. most or least significant one or zero detection, priority encoders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/30149—Instruction analysis, e.g. decoding, instruction word fields of variable length instructions
    • G06F9/30152—Determining start or end of instruction; determining instruction length
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016—Decoding the operand specifier, e.g. specifier format
    • G06F9/30167—Decoding the operand specifier, e.g. specifier format of immediate specifier, e.g. constants
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • G06F9/30174—Runtime instruction translation, e.g. macros for non-native instruction set, e.g. Javabyte, legacy code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30185—Instruction operation extension or modification according to one or more bits in the instruction, e.g. prefix, sub-opcode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/32—Address formation of the next instruction, e.g. by incrementing the instruction counter
    • G06F9/322—Address formation of the next instruction, e.g. by incrementing the instruction counter for non-sequential address
    • G06F9/324—Address formation of the next instruction, e.g. by incrementing the instruction counter for non-sequential address using program counter relative addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3804—Instruction prefetching for branches, e.g. hedging, branch folding
    • G06F9/3806—Instruction prefetching for branches, e.g. hedging, branch folding using address prediction, e.g. return stack, branch history buffer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3812—Instruction prefetching with instruction modification, e.g. store into instruction stream
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3816—Instruction alignment, e.g. cache line crossing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3818—Decoding for concurrent execution
    • G06F9/382—Pipelined decoding, e.g. using predecoding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3818—Decoding for concurrent execution
    • G06F9/3822—Parallel decoding, e.g. parallel decode units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824—Operand accessing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3853—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution of compound instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Executing Machine-Instructions (AREA)
  • Advance Control (AREA)

Description

  • Technisches Gebiet
  • Diese Erfindung betrifft Prozessoren. Insbesondere betrifft diese Erfindung Prozessoren, welche x86 Befehle für die Ausführung in einem Kern vom RISC Typ in Operationen vom RISC Typ umwandelt.
  • Stand der Technik
  • EP-A-0 651 320 offenbart einen superskalaren komplexen Befehlssatzcomputer (CISC) Prozessor, der einen reduzierten Befehlssatzcomputer (RISC) superskalaren Kern hat.
  • IEEE Micro, Vol. 14, Nr. 5, 1. Oktober 1997, Seiten 30–41, XP000476678 Diefendorff et al, mit dem Titel " The Power PC User Instruction Set Architecture" betrifft relevanten Stand der Technik.
  • Fortschrittliche Mikroprozessoren, so wie die x86 Prozessoren der P6 Klasse, werden von einem gemeinsamen Satz von Merkmalen definiert. Diese umfassen eine superskalare Architektur und Leistungsfähigkeit, die Dekodierung von mehreren x86 Befehlen pro Takt und Konvertierungen der mehreren x86 Befehle 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 Befehlsfenster zum Umordnen von Befehlen und zum Umordnen von Speicherbezügen.
  • Die Konvertierung oder Übersetzung der CISC ähnlichen Befehle in RISC ähnliche Befehle umfasst üblicherweise eine Abbildung von Befehlen, die vom gleichen Typ sein könnten, zum Beispiel viele Variationen von einem AAD Befehl, in einen oder mehrere eigene Befehle. Des weiteren werden eine sehr große Anzahl von Adressierungsarten eines bestimmten Befehls in eine Register zu Register Operation in Kombination mit Lade- und Speicheroperationen, welche auf den Speicher zugreifen, konvertiert. Die Leistungsfähigkeit von einem Mikroprozessor, der CISC ähnliche Befehle für die Ausführung in RISC ähnliche Befehle umwandelt, hängt erheblich von der Anzahl der Operationen vom RISC Typ ab, die von einem einzelnen Befehl vom CISC Typ produziert wurden.
  • Die Leistungsfähigkeit eines fortschrittlichen superskalaren Mikroprozessors hängt auch stark von der Leistungsfähigkeit der Dekodierung ab, einschließlich der Geschwindigkeit der Dekodierung, der Anzahl der in einem einzelnen Takt dekodierten x86 Befehle und der Leistungsfähigkeit und Behandlung der Verzweigungsvorhersage. Die Befehlsdekodierer in fortschrittlichen superskalaren Mikroprozessoren enthalten oftmals einen oder mehrere Dekodierungspfade, auf denen x86 Befehle von einer Hardware Logikübersetzung dekodiert werden, und einen separaten Dekodierpfad, welcher einen ROM Speicher zum Holen einer RISC Operationssequenz verwendet, die einem x86 Befehl entspricht. Im Allgemeinen sind x86 Befehle, die von einer Hardware Logik übersetzt werden, einfache x86 Befehle. Das Nachschlag ROM wird verwendet, um komplexere x86 Befehle zu dekodieren.
  • Ein Problem bei der Verwendung des Nachschlag ROM zum Dekodieren von x86 Befehlen ist, dass der Vorgang des Zugreifens auf einen Mikroprogramm Steuerspeicher angeboren langsamer und weniger effizient ist als die direkt verdrahtete Übersetzung von Befehlen. Ein weiteres Problem, das bei der Dekodierung von x86 Befehlen mittels des Nachschlag ROM auftritt, ist die sehr große Anzahl von verschiedenen Befehlen vom CISC Typ, welche der Standard für einen x86 Prozessor sind. Da eine erhebliche Anzahl von Befehlen implementiert ist, ist eine große ROM Schaltung auf dem Chip des Prozessors notwendig, um die Befehle in RISC ähnliche Operationen zu konvertieren. Die große Anzahl an implementierten Befehlen entspricht einer gestiegenen Komplexität der Schaltung zum Ableiten von Zeigern auf das ROM und die Anwendung der abgeleiteten Zeiger auf das ROM. Diese erhöhte Komplexität der Schaltung steht direkt in Relation zu einem erhöh ten Verwaltungsaufwand, der den Durchsatz in der Dekodierung der Befehle reduziert. Ein großes Nachschlag ROM erhöht die Größe der integrierten Schaltung des Prozessors und reduziert damit die Ausbeute bei der Herstellung des Prozessors und erhöht die Kosten der Produktion.
  • Es wird ein internes Befehlsformat benötigt, das die Übersetzung von einer sehr großen Anzahl von Befehlen vom CISC Typ in eine kleine Anzahl von Operationen vom RISC Typ vereinfacht. Weiter wird ein internes Befehlsformat benötigt, das die Konvertierung von Befehlen vom CISC Typ in eine minimale Anzahl von Operationen vom RISC Typ erleichtert. Des weiteren wird ein internes Befehlsformat benötigt, das erlaubt, mehr allgemeine Befehle vom CISC Typ unter Verwendung einer festverdrahteten Logik zu konvertieren als im Vergleich zu der Konvertierung mittels des Nachschlag ROM.
  • Offenbarung der Erfindung
  • In Übereinstimmung mit der vorliegenden Erfindung ist eine interne RISC Typ Befehlsstruktur mit einem Muster mit fester Bitlänge ausgestattet, das eine Vielzahl von definierten Bitfeldern für eine Vielzahl von Operations (Op) Formaten enthält. Ein Format umfasst ein Befehlstyp Bitfeld, zwei Quelloperanden Bitfelder und ein Zieloperanden Bitfeld zum Zuweisen einer Register zu Register Operation. Ein weiteres Format ist ein Lade-Speicher Format, das ein Befehlstyp Bitfeld, einen Identifizierer eines Quell- oder Zielregisters für die bestimmte Lade- oder Speicheroperation und Bitfelder zum Angeben der Segment-, Basis- und Indexparameter einer Adresse, eines Indexskalierungsfaktors und einer Versetzung umfasst.
  • In Übereinstimmung mit einem ersten Ausführungsbeispiel der vorliegenden Erfindung führt ein RISC ähnlicher interner Befehlssatz auf einem RISC ähnlichen Kern eines superskalaren Prozessors aus. Der RISC ähnliche interne Befehlssatz wird aus Befehlen eines CISC ähnlichen externen Befehlssatz übersetzt. Der Befehlssatz enthält eine Vielzahl von Befehlscodes, die in einer Struktur mit fester Bitlänge angeordnet sind. Die Struktur ist in eine Vielzahl von Bitfeldern für eine definierte Verwendung unterteilt. Die Befehlscodes haben eine Vielzahl von Operations (Op) Formaten der Vielzahl von Bitfeldern für eine definierte Verwendung. Ein Op Format ist ein erstes Register Op Format, aufweisend ein Format Bitfeld, welches den Befehlscode als einen Code vom ersten Register Op Format bestimmt, ein Typ Bitfeld, das einen Register Befehlstyp bestimmt, ein erstes Quelloperanden Bitfeld, das einen ersten Quelloperanden identifiziert, ein zweites Quelloperanden Bitfeld, das einen zweiten Quelloperanden identifiziert, ein Ziel Bitfeld, das einen Zieloperanden identifiziert, und ein Operandengröße Bitfeld, das eine Bytegröße des Operanden bestimmt. Ein zweites Op Format ist ein Lade-Speicher Op Format aufweisend ein Format Bitfeld, welches den Befehlscode als einen Lade-Speicher Op Format Code bestimmt, ein Typ Bitfeld, das einen Lade-Speicher Befehlstyp bestimmt, ein Daten Bitfeld, das eine Ziel-Quelle einer Lade-Speicher-Operation bestimmt, ein Index-Skalierungsfaktor Bitfeld zum Bestimmen eines Index-Skalierungsfaktors, ein Segment Bitfeld, das ein Segmentregister bestimmt, ein Basis Bitfeld, das eine Lade-Speicher Basisadresse bestimmt, ein Verschiebung Bitfeld, das eine Verschiebung einer Lade-Speicher Adresse bestimmt und ein Index Bitfeld, das einen Index einer Lade-Speicher Adresse bestimmt. Verschiedene Bitfelder der Befehlscodes werden mit dem ersetzten Bitfeld, das als eine Funktion der Prozessorumgebung bestimmt wird, in das Op Format eingesetzt.
  • Viele Vorteile werden durch den beschriebenen Befehlssatz und das Format des Befehlssatzes erzielt. Ein wesentlicher Vorteil ist, dass der beschriebene Befehlssatz sehr regulär ist mit einer festen Länge und Format von RISC Operationen. Im Vergleich dazu sind übliche x86 Befehle höchst irregulär mit sich erheblich unterscheidenden Längen und Formaten der Befehle. Eine reguläre Struktur reduziert die Komplexität und Größe der Schaltung und steigert die Effizienz erheblich. Ein weiterer Vorteil ist, dass Erweiterungen enthalten sind zum effizienten Abbilden von Operationen durch den Dekodierer. Die Erweiterungen unterstützen direktes Dekodieren und eine Emulation oder Abbildung von x86 Befehlen. Ein weiterer Vorteil ist, dass der beschriebene Befehlssatz in einer reduzierten ROM Speichergröße imple mentiert ist wegen der Wiederverwendung von Operationsstrukturen für mehrfache Variationen, die bei x86 Befehlen üblich sind. Die Benutzung der Ersetzung erreicht die Kodierung von CISC Funktionalität, während die Größe des Nachschlag Code ROM erheblich reduziert wird, was vorteilhafterweise die Größe und die Kosten einer integrierten Schaltung für einen Prozessor reduziert.
  • Kurze Beschreibung der Zeichnungen
  • Die Merkmale der Erfindung, von welchen geglaubt wird, dass sie neu sind, sind besonders in den beigefügten Ansprüchen ausgeführt. Jedoch kann die Erfindung selbst, sowohl hinsichtlich ihrer Struktur als auch des Verfahrens des Betriebs, am besten durch Verweis auf die folgende Beschreibung und die begleitenden Zeichnungen verstanden werden.
  • 1 ist ein Blockdiagramm, das ein Computersystem in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
  • 2 ist ein Blockdiagramm, das ein Ausführungsbeispiel eines Prozessors für die Verwendung in dem in 1 gezeigten Computersystem darstellt.
  • 3 ist ein Zeitablaufdiagramm, das ein Timing der Pipeline für ein Ausführungsbeispiel des in 2 gezeigten Prozessors darstellt.
  • 4 ist ein schematisches Blockdiagramm, das ein Ausführungsbeispiel eines Befehlsdekodierers zeigt, der in dem in 2 gezeigten Prozessor verwendet wird.
  • 5 ist ein schematisches Blockdiagramm, das eine Struktur eines Emulationscodesequenzers und eines Emulationscodespeichers des in 4 gezeigten Befehlsdekodierers zeigt.
  • 6A bis 6E sind bildliche Darstellungen, die eine Vielzahl von Operations (Op) Formaten zeigen, die von dem 4 gezeigten Befehlsdekodierer erzeugt sind.
  • 7 ist eine bildliche Darstellung eines Formats eines OpSeq Felds, das in dem in 5 gezeigten Emulationscodespeicher verwendet wird.
  • 8 ist eine bildliche Darstellung einer beispielhaften Befehlsersetzung.
  • 9 ist ein schematisches Blockdiagramm, das ein beispielhaftes Ausführungsbeispiel eines Ablaufplaners darstellt.
  • 10 ist ein Blockdiagramm eines Personal Computers einsetzend einen Prozessor mit einem Befehlsdekodierer, der einen RISC 86 Befehlssatz in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung implementiert.
  • Weg(e) zum Ausführen der Erfindung
  • Bezugnehmend auf 1 wird ein Computersystem 100 in einer Vielzahl von Anwendungen, einschließlich einer Personal Computer Anwendung, verwendet. Das Computersystem 100 enthält ein Computer Motherboard 110 umfassend einen Prozessor 120 in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung. Der Prozessor 120 ist eine monolithische integrierte Schaltung, die einen komplexen Befehlssatz ausführt, so dass der Prozessor 120 als ein komplexer Befehlssatz Computer (CISC) bezeichnet werden kann. Beispiele von komplexen Befehlssätzen sind die x86 Befehlssätze, die in der weit bekannten 8086 Familie von Mikroprozessoren implementiert sind. Der Prozessor 120 ist mit einem Level 2 (L2) Cachespeicher 122, einer Speichersteuerung 124 und Lokalbussteuerungen 126 und 128 verbunden. Die Speichersteuerung 124 ist mit einem Hauptspeicher 130 verbunden, so dass die Speichersteuerung 124 eine Schnittstelle zwischen dem Prozessor 120 und dem Hauptspeicher 130 bildet. Die Lokalbussteuerungen 126 und 128 sind mit Bussen verbunden, einschließlich eines PCI Busses 132 und eines ISA Busses 134, so dass die Lokalbussteuerungen 126 und 128 Schnittstellen zwischen dem PCI Bus 132 und dem ISA Bus 134 bilden.
  • Es wird auf 2 Bezug genommen, in der ein Blockdiagramm eines Ausführungsbeispiels des Prozessors 120 gezeigt ist. Der Kern des Prozessors 120 ist eine RISC superskalare Verarbeitungsmaschine. Übliche x86 Befehle werden von einer Befehlsdekodierungshardware zu Operationen in einem internen RSIC86 Befehlssatz konvertiert. Weitere x86 Befehle, die Ausnahmeverarbeitung und andere verschiedene Funktionalitäten sind als RISC86 Operationssequenzen implementiert, die in einem auf dem Chip befindlichen ROM gespeichert sind. Der Prozessor 120 hat Schnittstellen einschließlich einer Systemschnittstelle 210 und einer L2 Cachespeicher Steuerlogik 212. Die Systemschnittstelle 210 verbindet den Prozessor 120 mit anderen Blöcken des Computersystems 100. Der Prozessor 120 greift auf den Adressraum des Computersystems 100, einschließlich des Hauptspeichers 130 und Geräten auf den Lokalbussen 132 und 134, durch Lese- und Schreibzugriffe über die Systemschnittstelle 210 zu. Die L2 Cachespeicher Steuerlogik 212 bildet eine Schnittstelle zwischen einem externen Cachespeicher, wie dem L2 Cachespeicher 122, und dem Prozessor 120. Genauer gesagt bildet die L2 Cachespeicher Steuerlogik 212 eine Schnittstelle zu dem L2 Cachespeicher 122 und zu einem Befehls-Cachespeicher 214 und zu einem Daten-Cachespeicher 216 in dem Prozessor 120. Der Befehls-Cachespeicher 214 und der Daten-Cachespeicher 216 sind Level 1 (L1) Cachespeicher, welche über den L2 Cachespeicher 122 mit dem Adressraum des Computersystem 100 verbunden sind.
  • Befehle von dem Hauptspeicher 130 werden für eine erwartete Ausführung über einen Vordekodierer 270 in den Befehls-Cachespeicher 214 geladen. Der Vordekodierer 270 erzeugt Vordekodierungsbits, die zusammen mit den Befehlsbits in dem Befehls-Cachespeicher 214 gespeichert werden. Die Vordekodierungsbits, zum Beispiel 3 Bits, werden zusammen mit einem dazu gehörigen Befehlsbyte (8 Bits) geholt und benutzt, um die Dekodierung von mehreren Befehlen zu erleichtern und die Zeit für das Dekodieren zu reduzieren. Befehlsbytes werden mit zweiunddreißig Bytes gleichzeitig als Burst Transfer von vier acht Byte Quantitäten in den Befehls-Cachespeicher 214 geladen. Die Logik des Vordekodierers 270 ist achtfach nachgebildet für die vierfache Benutzung in einer Cachespeicherleitung, so dass Vordekodierungsbits für alle acht Befehlsbytes gleichzeitig, unmittelbar bevor sie in den Befehls-Cachespeicher 214 geschrieben werden, berechnet werden. Eine Vordekodierungsfunktion auf einem Byte basiert üblicherweise auf Information in einem, zwei oder drei Bytes, so dass die Vordekodierungsinformation sich jenseits einer acht Byte Gruppe erstrecken kann. Entsprechend werden die letzten zwei Bytes von einer acht Byte Gruppe für die Verarbeitung mit der nächsten acht Byte Gruppe für den Fall von Vordekodierungsinformation reserviert, die zwei acht Byte Gruppen überschneidet. Befehle in dem Befehls-Cachespeicher 214 sind CISC Befehle, die als Makrobefehle bezeichnet werden. Ein Befehlsdekodierer 220 konvertiert CISC Befehle von dem Befehls-Cachespeicher 214 in Operationen eines Befehlssatzes einer reduzierten Befehlssatzberechnung (RISC) Architektur für die Ausführung in einer Ausführungsmaschine 222. Ein einzelner Makrobefehl von dem Befehls-Cachespeicher 214 dekodiert sich zu einer oder mehreren Operationen für die Ausführungsmaschine 222.
  • Der Befehlsdekodierer 220 hat Schnittstellenverbindungen zu dem Befehls-Cachespeicher 214 und einer Befehl Hol Steuerschaltung 218 (gezeigt in 4). Der Befehlsdekodierer 220 umfasst einen Makrobefehlsdekodierer 230 zum Dekodieren der meisten Makrobefehle, eine Befehlsemulationsschaltung 231 umfassend ein Emulations ROM 232 zum Dekodieren eines Untersatzes von Befehlen, wie komplexen Befehlen, und eine Verzweigungseinheit 234 für die Vorhersage und die Behandlung von Verzweigungen. Makrobefehle werden entsprechend dem generellen Typ von Operationen, in welche die Makrobefehle konvertiert werden, klassifiziert. Die allgemeinen Typen von Operationen sind Register Operationen (RegOps), Lade-Speicher-Operationen (LdStOps), Lade unmittelbare Werte Operationen (LIMMOps), Spezial Operationen (SpecOps) und Gleitkomma Operationen (FpOps).
  • Die Ausführungsmaschine 222 hat einen Ablaufplaner 260 und sechs Ausführungseinheiten umfassend eine Ladeeinheit 240, eine Speichereinheit 242, eine erste Registereinheit 244, eine zweite Registereinheit 246, eine Gleitkomma Einheit 248 und eine Multimediaeinheit 250. Der Ablaufplaner 260 verteilt Operationen an geeignete Ausführungseinheiten und die Ausführungsmaschine arbeitet parallel. Jede Ausführungseinheit führt einen bestimmten Typ von Operation aus. Insbesondere lädt (liest) oder speichert (schreibt) die Ladeeinheit 240 beziehungsweise die Speichereinheit 242 Daten zu dem Daten-Cachespeicher 216 (L1 Daten-Cachespeicher), L2 Cachespeicher 122 und dem Hauptspeicher 130, während eine Lade/Speicher-Operation (LdStOp) ausgeführt wird. Eine Speicherwarteschlange 262 speichert Daten zeitweise von der Speichereinheit 242, so dass die Speichereinheit 242 und die Ladeeinheit 240 parallel arbeiten ohne in Konflikt tretende Zugriffe auf den Daten-Cachespeicher 216. Die Registereinheiten 244 und 246 führen Register Operationen (RegOps) für den Zugriff auf eine Registerdatei 290 aus. Die Gleitkomma Einheit 248 führt Gleitkomma Operationen (FpOps) durch. Die Multimediaeinheit 250 führt arithmetische Operationen für Multimedia Anwendungen aus.
  • Der Ablaufplaner 260 ist in eine Vielzahl von zum Beispiel 24 Einträgen unterteilt, wobei jeder Eintrag Speicherplatz und Logik enthält. Die 24 Einträge sind in sechs Gruppen von vier Einträge gruppiert, Op Quad genannt. Information in dem Speicherplatz eines Eintrags beschreibt eine Operation zur Ausführung, ob die Ausführung anhängig oder abgeschlossen ist oder nicht. Der Ablaufplaner überwacht die Einträge und verschickt Informationen von den Einträgen an den Informationen zugewiesene Ausführungseinheiten.
  • Bezugnehmend auf 3 verwendet der Prozessor 120 einen Basis Pipelinezeitablauf mit fünf und sechs Stufen. Der Befehlsdekodierer 220 dekodiert zwei Befehle in einem einzelnen Taktzyklus. Während einer ersten Stufe 310 holt die Befehl Hol Steuerschaltung 218 CISC Befehle in den Befehls- Cachespeicher 214. Die Vordekodierung der CISC Befehle während der Stufe 310 reduziert die nachfolgende Zeit für die Dekodierung. Während einer zweiten Stufe 320 dekodiert der Befehlsdekodierer 220 Befehle aus dem Befehls-Cachespeicher 214 und lädt einen Op Quad in den Ablaufplaner 260. Während einer dritten Stufe 330 tastet der Ablaufplaner 260 die Einträge ab und gibt Operationen an entsprechende Ausführungseinheiten 240 bis 252 aus, wenn eine Operation für die entsprechenden Typen von Ausführungseinheiten zur Verfügung steht. Operanden für die während der Stufe 330 ausgegebenen Operationen werden in einer vierten Stufe 340 an die Ausführungseinheiten weiter geleitet. Für eine RegOp schließt die Operation im Allgemeinen in dem nächsten Taktzyklus ab, der Stufe 350 ist, aber LdStOps erfordern mehr Zeit für die Adressberechnung 352, den Datenzugriff und den Transfer der Ergebnisse 362.
  • Für Verzweigungsoperationen führt der Befehlsdekodierer 220 eine Verzweigungsvorhersage 324 während einer anfänglichen Dekodierung von einer Verzweigungsoperation durch. Eine Verzweigungseinheit 252 bewertet Bedingungen für die Verzweigung in einer späteren Stufe 364, um zu bestimmen, ob die Verzweigungsvorhersage 324 korrekt war. Ein zweistufiger Algorithmus zur Verzweigungsvorhersage sagt eine Richtung von bedingten Verzweigungen voraus und das Holen von CISC Befehlen in der Stufe 310 und das Dekodieren der CISC Befehle in der Stufe 320 läuft in der vorhergesagten Richtung der Verzweigung weiter. Der Ablaufplaner 260 bestimmt, wann alle für die Bewertung der Verzweigung erforderlichen Bedingungscodes gültig sind und leitet die Verzweigungseinheit 252, um den Verzweigungsbefehl zu bewerten. Falls eine Verzweigung nicht korrekt vorher gesagt wurde, werden Operationen in dem Ablaufplaner 260, welche nicht ausgeführt werden sollten, ausgeworfen und der Dekodieren 220 beginnt, neue Op Quads von der korrekten Adresse nach der Verzweigung zu laden. Eine Zeitstrafe tritt auf, da Befehle für die korrekte Verzweigung geholt werden. Der Befehlsdekodierer 220 liest entweder eine zuvor gespeicherte vorher gesagte Adresse oder berechnet eine Adresse unter Benutzung eines Satzes von parallelen Addierern. Falls eine zuvor vorher gesagte Adresse gespeichert ist, wird die vorher gesagte Adresse in der Stufe 326 geholt und Befehle, die sich an der vorher gesagten Adresse befinden, werden in der Stufe 328 ohne eine Verzögerung durch die Addieren geholt. Anderenfalls berechnen die parallelen Addieren die vorher gesagte Adresse.
  • In der Stufe Verzweigungsvorhersage 364 bestimmt die Verzweigungseinheit 252, ob die Richtung der vorher gesagten Verzweigung richtig ist. Falls eine Richtung der vorher gesagten Verzweigung korrekt ist, laufen die Schritte des Holens, Dekodierens und Ausführens der Befehle ohne Unterbrechung weiter. Für eine nicht korrekte Vorhersage wird der Ablaufplaner 260 entleert und der Befehlsdekodierer 220 fängt an, Makrobefehle von dem korrekten Programmzähler nachfolgend zu der Verzweigung zu dekodieren.
  • Bezugnehmend auf 4 stellt ein schematisches Blockdiagramm ein Ausführungsbeispiel einer Schaltung zur Befehlsvorbereitung 400 dar, die mit dem Hauptspeicher 130 verbunden ist. Die Schaltung zur Befehlsvorbereitung 400 umfasst den Befehls-Cachespeicher 214, der über den Vordekodierer 270 mit dem Hauptspeicher 130 verbunden ist. Der Befehlsdekodierer 220 ist angeschlossen, um Befehlsbytes und Vordekodierungsbits von drei alternativen Quellen zu empfangen, dem Befehls-Cachespeicher 214, einem Verzweigungszielpuffer (BTB) 456 und einem Befehlspuffer 408. Die Befehlsbytes und Vordekodierungsbits werden dem Befehlsdekodierer 220 über eine Vielzahl von Rotatoren 430, 432 und 434 über Befehlsregister 450, 452 und 454 zugeführt. Der Makrobefehlsdekodierer 230 hat Eingangsverbindungen zu dem Befehls-Cachespeicher 214 und der Befehl Hol Steuerschaltung 218, um Befehlsbytes und dazu gehörige Vordekodierungsinformation zu empfangen. Der Makrobefehlsdekodierer 230 puffert geholte Befehlsbytes in einem Befehlspuffer 408, der mit der Befehl Hol Steuerschaltung 218 verbunden ist. Der Befehlspuffer 408 ist ein Puffer mit sechzehn Byte, der bis zu 16 Byte oder vier ausgerichtete Worte von dem Befehls-Cachespeicher 214 puffert, wobei so viele Daten wie durch den freien Platz in dem Befehlspuffer 408 erlaubt geladen werden. Der Befehlspuffer 408 hält die nächsten zu dekodierenden Befehlsbytes und lädt kontinuierlich mit neuen Befehlsbytes nach, wie ältere von dem Makrobefehlsdekodierer 230 verarbeitet werden. Befehle sowohl im Befehls-Cachespeicher 214 als auch in dem Befehlspuffer 408 werden in "erweiterten" Bytes gehalten, enthaltend sowohl Speicherbits (8) und Vordekodierungsbits (5) und werden in der gleichen Ausrichtung gehalten. Die Vordekodierungsbits unterstützen den Makrobefehlsdekodierer 230, um innerhalb eines einzelnen Taktzyklus mehrere Dekodierungen von Befehlen auszuführen.
  • Befehlsbytes, die unter Verwendung eines Dekodierungs Programmzählers (PC) 420, 422 oder 424 adressiert werden, werden von dem Befehlspuffer 408 zu dem Makrobefehlsdekodierer 230 transferiert. Auf den Befehlspuffer 408 wird byteweise von den Dekodierern in dem Makrobefehlsdekodierer 230 zugegriffen. Jedoch wird der Befehlspuffer 408 bei jedem Dekodierungszyklus auf einer Wortbasis betrieben, um nach zu verfolgen, welche der Bytes in dem Befehlspuffer 408 gültig sind und welche erneut mit neuen Bytes aus dem Befehls-Cachespeicher 214 geladen werden müssen. Die Zuweisung, ob ein Befehlsbyte gültig ist, wird bei behalten wenn das Befehlsbytes dekodiert wird. Für ein ungültiges Befehlsbyte setzt eine Logik zum Ungültigmachen des Dekodierers (nicht gezeigt), die mit dem Makrobefehlsdekodierer 230 verbunden ist, eine "Byte ungültig" Signal. Die Steuerung der Aktualisierung des aktuellen Hol PCs 426 ist eng mit der Gültigkeit der Befehlsbytes in dem Befehlspuffer 408 und dem Verbrauch der Befehlsbytes durch den Befehlsdekodierer 220 synchronisiert.
  • Der Makrobefehlsdekodierer 230 empfängt bis zu sechzehn Bytes oder vier ausgerichtete Worte von Befehlsbytes, die von der Befehl Hol Steuerschaltung 218 an dem Ende eines Holzyklus geholt werden. Befehlsbytes von dem Befehls-Cachespeicher 214 werden in den Befehlspuffer 408 mit 16 Byte geladen. Der Befehlspuffer 408 puffert Befehlsbytes sowie zu jedem der Befehlsbytes gehörige Vordekodierungsinformation, wenn die Befehlsbytes geholt und/oder dekodiert werden. Der Befehlspuffer 408 empfängt so viele Befehlsbytes wie in dem freien Platz des Befehlspuffers 408 untergebracht werden können, hält die nächsten zu dekodierenden Befehlsbytes und lädt kontinuierlich mit neuen Befehlsbytes nach, wie die vorherigen Befehlsbytes an individuelle Dekodieren in dem Makrobefehlsdekodierer 230 transferiert werden. Der Befehlsvordekodierer 270 fügt Vordekodierungsinformationsbits zu den Befehlsbytes hinzu, wenn die Befehlsbytes in den Befehls-Cachespeicher 214 transferiert werden. Daher werden die von dem Befehls-Cachespeicher 214 gespeicherten und transferierten Befehlsbytes erweiterte Bytes genannt. Jedes erweiterte Byte enthält acht Speicherbits sowie fünf Vordekodierungsbits. Die fünf Vordekodierungsbits umfassen drei Bits, welche die Länge des Befehls kodieren, ein D-Bit, das angibt, ob die Länge des Befehls von dem D-Bit abhängt und ein HasModRM Bit, das anzeigt, ob ein Befehlscode ein modrm Feld enthält. Die dreizehn Bits werden in dem Befehlspuffer 408 gespeichert und an die Dekodieren des Makrobefehlsdekodierers 230 weiter geleitet. Der Befehlspuffer 408 erweitert jeden Satz von fünf Vordekodierungsbits in sechs Vordekodierungsbits. Die Vordekodierungsbits ermöglichen es den Dekodierern, das Dekodieren von mehreren Befehlen schnell in einem Taktzyklus auszuführen.
  • Der Befehlspuffer 408 empfängt Befehlsbytes von dem Befehls-Cachespeicher 214 in der auf den Speicher ausgerichteten Wortbasis der Speicherung des Befehls-Cachespeichers 214, so dass Befehle mit der Auflösung eines Wortes geladen und ersetzt werden. Daher hält die Bytestelle 0 des Befehlspuffers 408 immer Bytes, die im Speicher bei einer Adresse von 0 (mod 16) adressiert werden.
  • Befehlsbytes werden von dem Befehlspuffer 408 mit einer Auflösung von einem Byte an den Makrobefehlsdekodierer 230 transferiert. Während jedes Dekodierungszyklus werden die sechzehn erweiterten Befehlsbytes in dem Befehlspuffer 408, einschließlich der dazu gehörigen impliziten Wordgültig Bits, an die Vielzahl der Dekodieren in dem Makrobefehlsdekodierer 230 transferiert. Diese Methode des Transferierens von Befehlsbytes von dem Befehls-Cachespeicher 214 zu dem Makrobefehlsdekodierer 230 über den Befehlspuffer 408 wird mit jedem Dekodierungszyklus so lange wiederholt, wie die Befehle nach einander dekodiert werden. Wenn ein Steuerungstransfer auftritt, zum Beispiel aufgrund einer genommenen Verzweigungsoperation, wird der Befehlspuffer 408 entleert und das Verfahren wird neu gestartet.
  • Der aktuelle Dekodierungs PC hat eine willkürliche Ausrichtung der Bytes dahingehend, dass der Befehlspuffer 408 eine Kapazität von sechzehn Bytes hat, aber auf einer Basis von vier Byte Worten verwaltet wird, in der alle vier Bytes eines Wortes verbraucht werden vor der Entfernung und der Ersetzung des Wortes mit vier neuen Bytes in dem Befehlspuffer 408. Ein Befehl hat eine Länge von einem bis elf Bytes und mehrere Bytes werden dekodiert, so dass die Ausrichtung eines Befehls in dem Befehlspuffer 408 willkürlich ist. Mit der Übertragung von Befehlsbytes von dem Befehlspuffer 408 zu dem Makrobefehlsdekodierer 230 wird der Befehlspuffer 408 aus dem Befehls-Cachespeicher 214 nach geladen.
  • Befehlsbytes werden in dem Befehlspuffer 408 eher mit einer Speicherausrichtung als mit einer sequentiellen Byteausrichtung gespeichert, die geeignet ist für die Anwendung von nach einander folgenden Befehlsbytes für den Makrobefehlsdekodierer 230. Daher ist ein Satz von Byterotatoren 430, 432 und 434 zwischen den Befehlspuffer 408 und jeden der Dekodieren in dem Makrobefehlsdekodierer 230 zwischen geschaltet. Vier Befehlsdekodierer, einschließlich drei Kurzdekodierern SDec0 410, SDec1 412 oder SDec2 414 und einem kombinierten Lang- und vektorisierenden Dekodierer 418, teilen sich die Byterotatoren 430, 432 und 434. Insbesondere teilen sich der Kurzdekodierer SDec0 410 und der kombinierte Lang- und vektorisierende Dekodieren 418 den Byterotator 430. Der Kurzdekodierer SDdec1 412 ist dem Byterotator 432 zugeordnet und der Kurzdekodierer SDec2 414 ist dem Byterotator 434 zugeordnet.
  • Eine Vielzahl von Pipelineregistern, insbesondere Befehlsregister 450, 452 und 454, sind zwischen die Byterotatoren 430, 432 und 434 und den Befehlsdekodierer 220 geschaltet, um die Befehlsbytes, die Vordekodierungsbits und weitere Information temporär zu halten, wodurch der Dekodierungszeitzyklus verkürzt wird. Die weiteren in den Befehlsregistern 450, 452 und 454 gehaltenen Informationen umfassen verschiedene Informationen zum Unterstützen der Dekodierung von Befehlen, einschließlich Präfix (zum Beispiel OF) Status, unmittelbare Größe (8 Bit oder 32 Bit), Verschiebung und lang dekodierbare Längenzuweisungen.
  • Obwohl eine Schaltung gezeigt ist, die drei Rotatoren und drei Kurzdekodierer verwendet, können in anderen Ausführungsbeispielen unterschiedliche Anzahlen von Schaltungselementen verwendet werden. Zum Beispiel kann eine Schaltung zwei Rotatoren und zwei Kurzdekodierer enthalten.
  • Befehle werden in dem Befehls-Cachespeicher 214, dem Verzweigungszielpuffer (BTB) 456 und dem Befehlspuffer 408 in Speicherausrichtung gespeichert, nicht in Befehlsausrichtung, so dass die Stelle des ersten Befehlsbytes nicht bekannt ist. Die Byterotatoren 430, 432 und 434 finden das erste Byte eines Befehls.
  • Der Makrobefehlsdekodierer 230 führt auch verschiedene Operationen zum Dekodieren von Befehlen und zum Dekodieren von Ausnahmen durch, einschließlich der Validierung von Dekodieroperationen und der Auswahl zwischen verschiedenen Typen von Dekodieroperationen. Während Dekodieroperationen ausgeführte Funktionen umfassen die Behandlung von Präfixbytes, die Unterstützung des Einspringens in das Emulationscode ROM 232 für die Emulation von Befehlen und für Operationen der Verzweigungseinheit 234 das Bilden einer Schnittstelle für die Verzweigungseinheit und die Vorhersage der Rückkehradresse. Basierend auf den Befehlsbytes und der dazu gehörigen Information erzeugt der Makrobefehlsdekodierer 230 Operationsinformation in Gruppen von vier Operationen, die Op Quads entsprechen. Der Makrobefehlsdekodierer 230 erzeugt des weiteren Steuerinformationen für das Einspringen von Befehlen und Steuerinformationen für den Emulationscode. Der Makrobefehlsdekodierer 230 hat auch Ausgangsverbindungen zu dem Ablaufplaner 260 und dem Emulationscode ROM 232 zum Ausgeben der Op Quad Informationen, der Steuerinformationen für das Einspringen von Befehlen und der Steuerinformationen für den Emulationscode. Der Makrobefehlsdekodierer 230 dekodiert keine Befehle wenn der Ablaufplaner 260 nicht fähig ist, Op Quads zu akzeptieren oder von dem Emulationscode ROM 232 Op Quads akzeptiert.
  • Der Makrobefehlsdekodierer 230 hat fünf bestimmte und einzelne Dekodieren, einschließlich drei "Kurz" Dekodierern SDec0 410, SDec1 412 und SDec2 414, welche zusammen funktionieren, um bis zu drei "Kurz" Dekodieroperationen von Befehlen zu dekodieren, die in einem Untersatz von einfachen Befehlen des x86 Befehlssatzes definiert sind. Die Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 erzeugen typischerweise jeweils eine oder zwei Operationen, obwohl in gewissen Fällen, wie Dekodierungen von Präfixen, Null Operationen erzeugt werden. Entsprechend für drei Kurzdekodieroperationen werden von zwei bis zu sechs Operationen in einem Dekodierungstakt erzeugt. Die zwei bis sechs Operationen von den drei Kurzdekodierern werden nachfolgend von einer Operationspacklogik 438 zusammen in einen Op Quad gepackt, weil ein Maximum von vier bis sechs Operationen gültig ist. Insbesondere versucht jeder der drei Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 zwei Operationen zu dekodieren, was potentiell sechs Operationen erzeugt. Nur vier Operationen können zu einem Zeitpunkt erzeugt werden, so dass, wenn mehr als vier Operationen erzeugt werden, die Operationen von dem Kurzdekodierer SDec2 414 ungültig gemacht werden. Die fünf Dekodieren umfassen auch einen einzelnen "Lang" Dekodieren 416 und einen einzelnen vektorisierenden Dekodieren 418. Der Lang Dekodieren 416 dekodiert Befehle oder Formen von Befehlen, die eine komplexere Form des Adressmodus haben, so dass mehr als zwei Operationen erzeugt werden und eine Behandlung der Kurzdekodierung nicht verfügbar ist. Der vektorisierende Dekodieren 418 behandelt Befehle, die nicht durch den Betrieb der Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 oder von dem Lang Dekodieren 416 behandelt werden können. Der vektorisierende Dekodieren 418 dekodiert nicht wirklich einen Befehl, sondern springt vielmehr zu einer Stelle in dem Emulationscode ROM 232, um einen Befehl zu emulieren. Verschiedene Ausnahmebedingungen, welche von dem Makrobefehlsdekodierer 230 detektiert werden, werden ebenfalls als eine spezielle Form einer Einsprungdekodierfunktion behandelt. Wenn aktiviert, erzeugen der Lang Dekodieren 416 und der vektorisierende Dekodieren 418 jeweils einen vollständigen Op Quad. Ein von den Kurzdekodierern SDec0 410, SDec1 412 und SDec2 414 erzeugter Op Quad hat das gleiche Format wie ein Op Quad, der von dem Lang und dem vektorisierenden Dekodieren 416 und 418 erzeugt wird. Die Kurz Dekodierer und Lang Dekodierer Op Quads enthalten kein OpSeq Feld. Der Makrobefehlsdekodierer 230 wählt entweder den von den Kurzdekodierern SDec0 410, SDec1 412 und SDec2 414 erzeugten Op Quad oder den von dem Lang Dekodieren 416 oder dem vektorisierenden Dekodieren 418 erzeugten Op Quad als ein Op Quad Ergebnis des Makrobefehlsdekodierers 230 für jeden Dekodierzyklus aus. Die Kurzdekodieroperation, Langdekodieroperation und Einsprungdekodieroperation arbeiten parallel zueinander und unabhängig voneinander, obwohl die Ergebnisse von nur einem Dekodieren zu einem Zeitpunkt verwendet werden.
  • Jeder der Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414 dekodiert bis zu sieben Befehlsbytes unter der Annahme, dass das erste Byte ein Operationscode (Opcode) Byte sein soll und der Befehl ein Kurzdekodierbefehl sein soll. Zwei Operationen (Ops) werden mit entsprechenden Gültig Bits erzeugt. Geeignete Werte für die effektive Größe der Adresse, die effektive Größe der Daten, das aktuelle x86 Standard B-Bit und jegliche Übersteuerungsoperanden Segmentregister werden für die Erzeugung von Operationen, die von diesen Parametern abhängen, zur Verfügung gestellt. Die logische Adresse für den nächsten "sequentielle" zu dekodierenden Befehl wird für die Verwendung bei der Erzeugung der Operationen für einen CALL Befehl zur Verfügung gestellt. Zu bemerken ist, dass das Wort sequentielle in Anführungszeichen platziert ist, um anzuzeigen, dass, obwohl die sequentielle Adresse im Allgemeinen auf einen Befehl zeigt, welcher dem aktuellen Befehl unmittelbar vorangeht, die "sequentielle" Adresse auf eine beliebige mit einer Adresse versehenen Stelle gesetzt sein kann. Die aktuelle Vorhersage für die Verzweigung wird für die Verwendung bei der Erzeugung der Operationen für bedingte Transfersteuerbefehle zur Verfügung gestellt. Eine Kurzdekodierung erzeugt Steuersignale einschließlich Hinweisen auf einen Transfersteuerbefehl (zum Beispiel Jcc, LOOP, JMP, CALL), einen nicht bedingten Transfersteuerbefehl (zum Beispiel JMP, CALL), einen CALL Befehl, ein Präfix Byte, eine cc abhängige RegOp und eine Zuweisung, ob die Länge des Befehls von der Adress- oder Datengröße abhängt. Typischerweise sind eine oder beide Operationen gültig, aber das Präfix Byte und JMP Dekodierungen erzeugen keine gültige Op. Ungültige Operationen erscheinen als gültige NOOP Operationen, um einen Op Quad auszufüllen.
  • Der erste Kurz Dekodieren 410 erzeugt Operationen basierend auf mehr als dem Dekodieren der Befehlsbytes. Der erste Kurz Dekodieren 410 stellt auch das Vorhandensein von jeglichen Präfix Bytes fest, die während voran gehenden Dekodiertakten dekodiert wurden. Verschiedene Präfix Bytes einschließlich OF, Übersteuerung der Adressgröße, Übersteuerung der Operandengröße, sechs Segmentübersteuerungsbytes, REP/REPE, REPNE und LOCK Bytes. Jedes Präfix Byte beeinflusst eine nachfolgende Dekodierung eines Befehls auf eine definierte Weise. Ein Zähler von Präfix Bytes und ein Zähler von aufeinander folgenden Präfix Bytes werden während des Dekodierens angesammelt und dem ersten Kurz Dekodieren SDec0 410 und dem Lang Dekodieren 416 zugeführt. Der nachfolgende Präfix Byte Zähler wird verwendet, um zu überprüfen, ob ein gerade dekodierter Befehl zu lang ist. Die Information des Präfix Byte Zählers wird ebenfalls für die Steuerung nachfolgender Dekodiertakte verwendet, einschließlich der Überprüfung auf gewisse Typen von befehlsspezifischen Ausnahmebedingungen. Die Präfix Zähler werden an dem Ende jedes erfolgreichen nicht Präfix Dekodiertaktes zurück gesetzt oder initialisiert in Vorbereitung auf die Dekodierung der Präfix und Opcode Bytes eines nächsten Befehls. Die Präfix Zähler werden auch neu initialisiert, wenn der Makrobefehlsdekodierer 230 Verzweigungsbedingungs- und Schreibbefehlzeiger (WRIP) Operationen dekodiert.
  • Präfix Bytes werden von dem ersten Kurz Dekodieren 410 auf die Art von ein Byte Kurzdekodier Befehlen verarbeitet. Höchstens ein Präfix Byte wird in einem Dekodierungstakt dekodiert, eine Bedingung, die durch das Ungültigmachen von allen Kurzdekodierungen, die der Dekodierung eines Präfix Bytes folgen, erzwungen wird. Die effektive Größe der Adresse, die Größe der Daten, die Werte der Operandensegmentregister und das derzeitige B-Bit werden dem ersten Kurz Dekodieren 410 zur Verfügung gestellt, aber können zusammen mit voran gehenden Opcodes dekodiert werden.
  • Der Adressgrößen Präfix beeinflusst eine Dekodierung von einem nachfolgenden Befehl sowohl für das Dekodieren von Befehlen, für welche die erzeugte Operation von der effektiven Größe der Adresse abhängt, als auch für das Dekodieren des Adressmodus und der Befehlslänge von modr/m Befehlen. Die vorgegebene Adressgröße wird von einem gegenwärtig angegebenen D-Bit bestimmt, das von dem Auftreten von einem oder mehreren Adressgrößen Präfixen effektiv umgeschaltet wird.
  • Der Präfix für die Operandengröße beeinflusst auch die Dekodierung von einem nachfolgenden Befehl sowohl für die Dekodierung von Befehlen, für welche die erzeugte Operation von der effektiven Größe der Daten abhängt, als auch für die Dekodierung der Länge des Befehls. Die voreingestellte Operandengröße wird von einem aktuell angegebenen x86 Standard D-Bit angegeben, das durch das Auftreten von einem oder mehreren Operandengrößen Präfixen effektiv umgeschaltet wird.
  • Die Segmentübersteuer Präfixe beeinflussen die Dekodierung eines nachfolgenden Befehls nur für den Fall, wenn die Erzeugung einer Lade-Speicher Operation (LdStOps) von dem effektiven Operandensegment des Befehls abhängig ist. Das voreingestellte Segment ist DS oder 55 abhängig von dem dazu gehörigen generellen Adressierungsmodus und wird ersetzt mit dem Segment, das von dem letzten Segmentübersteuer Präfix angegeben ist.
  • Die REP/REPE und REPNE Präfixe beeinflussen die Dekodierung eines nachfolgenden Befehls nicht. Falls der Befehl von dem Makrobefehlsdekodierer 230 dekodiert wird, statt von dem Emulationscode ROM 232, dann werden jegliche voran gehende REP Präfixe ignoriert. Jedoch wird, falls der Befehl vektorisiert wird, dann die Erzeugung der Einsprungadresse in einigen Fällen modifiziert. Insbesondere falls ein Stringbefehl oder ein bestimmter benachbarter Opcode vektorisiert wird, dann wird ein Hinweis auf das Auftreten von einem oder mehreren REP Präfixen und die Zuweisung des letzten angetroffenen REP Präfixes in die Einsprungadresse integriert. Für alle an deren Befehle wird die Einsprungadresse nicht verändert und der REP Präfix wird ignoriert.
  • Ein LOCK Präfix verhindert alle Kurz und Lang Dekodierungen bis auf die Dekodierung von Präfix Bytes, was einen nachfolgenden Befehl zwingt, vektorisiert zu werden. Wenn der Vektordekodierungstakt des nachfolgenden Befehls geschieht, wird, solange wie der nachfolgende Befehl kein Präfix ist, das Opcode Byte überprüft, um sicher zu stellen, dass der Befehl in einem " verriegelbaren" Untersatz der Befehle ist. Falls der Befehl kein verriegelbarer Befehl ist, wird eine Ausnahmebedingung erkannt und die von dem vektorisierenden Dekodieren 418 erzeugte Einsprungadresse wird von einer Adresse mit einem Ausnahmeeintrittspunkt ersetzt.
  • Von dem zweiten und dritten Kurz Dekodieren 412 und 414 dekodierte Befehle haben keine Präfix Bytes, so dass die Dekodieren 412 und 414 feste voreingestellte Werte für die Größe der Adresse, die Größe der Daten und die Werte des Operandensegmentregisters annehmen.
  • Typischerweise erzeugen die drei Kurz Dekodieren vier oder weniger Operationen, weil drei aufeinander folgende Kurz Dekodierungen nicht immer ausgeführt werden und Befehle oftmals nur in eine einzelne Operation kurz dekodieren. Jedoch verhindert die Operationspacklogik 438 den dritten Kurz Dekodieren 414 oder macht ihn ungültig für den seltenen Fall, wenn mehr als vier gültige Operationen erzeugt werden, so dass nur zwei Operationen erfolgreich dekodiert werden und höchstens vier Operationen zum Packen in einen Op Quad erzeugt werden.
  • Wenn der erste Kurz Dekodieren 410 nicht erfolgreich ist, werden die Aktionen des zweiten und des dritten Kurz Dekodierers 412 und 414 ungültig gemacht. Wenn der zweite Kurz Dekodieren 412 nicht erfolgreich ist, wird die Aktion des dritten Kurz Dekodierers 414 ungültig gemacht. Wenn sogar die erste Kurz Dekodierung ungültig ist, wird der Dekodierungstakt ein Lang oder vektorisierender Dekodierungstakt. Im Allgemeinen versucht der Makrobefehlsdekodierer 230 eine oder mehrere Kurz Dekodierungen und versucht, falls derartige Kurz Dekodierungen nicht erfolgreich sind, eine Lang Dekodierung. Falls die Lang Dekodierung nicht erfolgreich ist, führt der Makrobefehlsdekodierer 230 eine0 vektorisierende Dekodierung durch. Mehrere Bedingungen veranlassen, dass die Kurz Dekodieren 410, 412 und 414 ungültig gemacht werden. Ganz Allgemein werden Kurz Dekodierungen ungültig gemacht, wenn der Operationscode (Opcode) des Befehls oder der zugewiesene Adressmodus eines modr/m Befehls nicht in einen definierten Kurz Dekodierungs- oder "einfachen" Untersatz von Befehlen fällt. Diese Bedingung beschränkt üblicherweise Kurz Dekodierungsbefehle auf diejenigen Operationen, welche zwei oder weniger Operationen erzeugen. Kurz Dekodierungen werden ebenso ungültig gemacht, wenn nicht alle der Bytes des Befehlspuffers 408 für einen dekodierten Befehl gültig sind. Auch werden "cc abhängige" Operationen, Operationen, die abhängig sind von Status Flags, nur von dem ersten Kurz Dekodieren 410 erzeugt, um sicherzustellen, dass diesen Operationen nicht beliebige ".cc" RegOps vorstehen. Eine Kurz Dekodierung wird für eine zweite von aufeinander folgenden Kurz Dekodierungen ungültig gemacht, wenn die unmittelbar voran gehende Kurz Dekodierung eine Dekodierung eines Transfersteuerbefehls war, unabhängig von der genommenen Richtung. Im Allgemeinen verhindert ein Präfix Code oder ein Transfersteuer Code die weitere Dekodierung in einem Takt.
  • Des weiteren werden nicht mehr als sechzehn Befehlsbytes von dem Makrobefehlsdekodierer 230 verbraucht, weil der Befehlspuffer 408 lediglich sechzehn Bytes zu einem Zeitpunkt hält. Auch können höchstens vier Operationen in einen Op Quad gepackt werden. Diese Beschränkungen betreffen nur den dritten Kurz Dekodieren 414, da die Länge von jedem kurz dekodierten Befehl höchstens sieben Byte ist und über die vierte hinaus gehende Operationen nur in dem dritten Kurz Dekodieren 414 erscheinen.
  • Bei einer verwandten Beschränkung, falls der aktuelle Wert für das D-Bit eine 16 Bit Adresse und die Vorgabe für die Größe der Daten angibt, kann dann ein Befehl mit einer Länge, die von der Adresse und/oder den Daten abhängt, nur von dem ersten Kurz Dekodieren 410 behandelt werden, weil die Vordekodierungsinformation wahrscheinlich nicht korrekt ist. Ebenso ist es, wenn die Dekodierung von mehreren Befehlen nicht freigegeben ist, nur dem ersten Kurz Dekodieren 410 erlaubt, Befehle und Präfix Bytes erfolgreich zu dekodieren.
  • Tests hinsichtlich der Gültigkeit werden von einer Kurz Dekodier Gültigkeitslogik (nicht gezeigt) in dem Makrobefehlsdekodierer 230 gesteuert und sind unabhängig von dem Betrieb der Kurz Dekodieren 410, 412 und 414. Jedoch setzt jeder der Kurz Dekodieren 410, 412 und 414 Null, ein oder zwei Gültig Bits abhängig von der Anzahl der dekodierten Operationen. Diese Gültig Bits, eine Gesamtzahl von sechs für die drei Kurz Dekodieren 410, 412 und 414, werden von der Operationspacklogik 438 verwendet, um festzustellen, welche Operationen in einen Op Quad gepackt werden, und um ungültige Operationen zu zwingen, als NOOP (keine Operation) Operationen zu erscheinen. Die Operationspacklogik 438 arbeitet ohne Gültigkeitsinformationen der Kurz Dekodieren, da gültigen Kurz Dekodierungen und dazu gehörigen Operationen nur andere gültige Kurz Dekodierungen und dazu gehörige Operationen voraus gehen.
  • Die Kurz Dekodieren 410, 412 und 414 erzeugen auch eine Vielzahl von Signalen, die verschiedene Spezial Opcode oder modr/m Adressmodus Dekodierungen repräsentieren. Diese Signale zeigen an, ob eine gewisse Form eines Befehls derzeit von dem Befehlsdekodierer 220 dekodiert wird. Diese Signale werden von der Kurz Dekodier Gültigkeitslogik verwendet, um Gültigkeitssituationen der Kurz Dekodierung zu behandeln.
  • Die Befehlsbytes, welche nicht ausgerichtet in dem Befehlspuffer 408 gespeichert sind, werden von den Byterotatoren 430, 432 und 434 ausgerichtet, wenn die Befehlsbytes zu den Dekodierern 410–418 transferiert werden. Der erste Kurz Dekodieren SDec0 410, der Lang Dekodieren 416 und der vektorisierende Dekodieren 418 teilen sich einen ersten Byterotator 430. Der zweite und der dritte Kurz Dekodieren SDec1 412 und SDec2 414 verwenden jeweils den zweiten und dritten Byterotator 432 und 434. Während jedes Dekodierungstaktes versuchen die drei Kurz Dekodierer SDec0 410, SDec1 412 und SDec2 414 zu dekodieren, was bei größter Effizienz drei Kurz Dekodier Operationen sind, unter Verwendung von drei unabhängig arbeitenden und parallelen Byterotatoren 430, 432 und 434. Obwohl das Multiplexen der Byterotatoren 430, 432 und 434 von geeigneten Bytes in dem Befehlspuffer 408 an jeden entsprechenden Kurz Dekodieren SDec0 410, SDec1 412 und SDec2 414 konzeptuell von der vorher gehenden Befehlsdekodierungsoperation abhängig ist, verwendet die Vorausschaulogik für die Befehlslänge 436 Vordekodierungsbits, um es den Dekodierern zu ermöglichen, im wesentlichen parallel zu arbeiten.
  • Der Lang und der vektorisierende Dekodieren 416 und 418 führen in Kombination zwei parallel Dekodierungen von elf Befehlsbytes durch, wobei das erste Byte als ein Opcode Byte genommen wird und entweder ein Lang Befehlsdekodierung Op Quad oder ein vektorisierende Dekodierung Op Quad erzeugt wird. Von dem Lang und dem vektorisierenden Dekodieren 416 und 418 analysierte Informationen umfassen die effektive Größe der Adresse, die effektive Größe der Daten, das aktuelle B-Bit und DF-Bit, jegliches Übersteuerungsoperanden Segmentregister und logische Adressen der nächsten zu dekodierenden "sequentiellen" und Zielbefehle. Der Lang und der vektorisierende Dekodieren 416 und 418 erzeugen Dekodierungssignale einschließlich einer Befehlslänge mit der Ausnahme voran gehender Präfix Bits, einer Zuweisung, ob der Befehl innerhalb des Lang Dekodierung Untersatzes eines Befehls ist, eines RET Befehls und einem effektiven Operanden Segmentregister basierend auf einer Vorgabe, die impliziert wird von dem modr/m Adressmodus sowie jeglicher Segmentübersteuerung.
  • Während eines Dekodierungstaktes, in dem keiner der Kurz Dekodieren SDec0 410, SDec1 412 und SDec2 414 erfolgreich einen kurzen Befehl dekodiert, versucht der Makrobefehlsdekodierer 230 unter Verwendung des Lang Dekodierers 416 eine Lang Dekodierung durchzuführen. Falls eine Lang Dekodierung nicht durchgeführt werden kann, wird eine vektorisierende Dekodierung durchgeführt. In einigen Ausführungsbeispielen sind der Lang und der vektorisierende Dekodieren 416 und 418 konzeptuell getrennte und unabhängige Dekodieren, so wie der Lang und der vektorisierende Dekodieren 416 und 418 getrennt und unabhängig von den Kurz Dekodie rern 410, 412 und 414 sind. Physikalisch jedoch teilen sich der Lang und der vektorisierende Dekodieren 416 und 418 viel Logik und erzeugen ähnliche Op Quad Ausgaben. Von dem Lang Dekodieren 416 dekodierte Befehle sind im Allgemeinen in dem Kurz Dekodier Untersatz von Befehlen enthalten bis auf eine Beschränkung im Adressmodus, derart dass der Befehl nicht von einem Kurz Dekodieren dekodiert werden kann, weil die Länge des Befehls größer als sieben Byte ist oder weil die Adresse eine große Verschiebung hat, welche die Erzeugung einer dritten Operation erfordern würde, um die Verschiebung zu behandeln. Der Lang Dekodierer 416 dekodiert auch gewisse zusätzliche modr/m Befehle, die nicht in dem Kurz Dekodier Untersatz sind, aber allgemein genug sind, um eine Hardwaredekodierung zu rechtfertigen. Befehlsbytes für die Benutzung oder die Dekodierung durch den Lang Dekodieren 416 werden von dem ersten Byterotator 430 aus dem Befehlspuffer 408 zur Verfügung gestellt, dem gleichen Befehlsmultiplexer, der Befehlsbytes an den ersten Kurz Dekodieren SDec0 410 liefert. Jedoch empfängt, während der erste Kurz Dekodieren SDec0 410 nur sieben Byte empfängt, der Lang Dekodierer 416 bis zu elf aufeinander folgende Befehlsbytes, entsprechend der maximalen Länge eines modr/m Befehls ohne die Präfix Bytes. Daher ist der erste Byterotator 430 elf Byte breit, obwohl lediglich die ersten sieben Bytes zu dem ersten Kurz Dekodieren SDec0 419 verbunden werden. Der Lang Dekodieren 416 dekodiert nur einen Befehl zu einem Zeitpunkt, so dass dazu gehörige Vordekodierungsinformation in dem Befehlspuffer 408 nicht verwendet wird und üblicherweise ungültig ist.
  • Das erste Byte des ersten Byterotators 430 wird vollständig als ein Opcode Byte kodiert und für den Fall eines modr/m Befehls werden das zweite Befehlsbyte und möglicherweise das dritte vollständig als modr/m beziehungsweise sib Bytes dekodiert. Das Vorhandensein eines OF Präfixes wird berücksichtigt durch die Dekodierung des Opcode Bytes. Das OF Präfix Byte verhindert alle Kurz Dekodierungen, weil alle Kurz Dekodier Befehle nicht OF oder "ein Byte" Opcodes sind. Weil alle Präfix Bytes in dem "ein Byte" Opcode Raum angeordnet sind, zwingt die Dekodierung eines OF Präfixes den nächsten Dekodierungstakt, ein zwei Byte Opcode Befehl zu sein, wie einen Lang oder vektorisierenden Dekodierbefehl. Zusätzlich zu der Erzeugung von Operationen basierend auf der Dekodierung von modr/m und sib Bytes, bestimmt der erste Byterotator 430 auch die Länge des Befehls für die Verwendung von verschiedenen Programmzählern, ob der Befehl ein modr/m Befehl zur Verhinderung oder zum ungültig machen des Lang Dekodierers ist und ob der Befehl ein Befehl innerhalb des Lang Dekodier Untersatzes von Operationscodes (Opcodes) ist. Der Lang Dekodieren 416 erzeugt immer vier Operationen und präsentiert wie die Kurz Dekodieren 410, 412 und 414 die Operationen in der Form eines Emulationscode ähnlichen Op Quads mit der Ausnahme des OpSeq Feldes. Der Lang Dekodieren 416 behandelt nur relativ einfache modr/m Befehle. Ein Lang Dekodier Op Quad 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 NOOP ist. Ein erster Lang Dekodier Op Quad hat die Form:
    LIMM t2,<imm32>
    LIMM t1,<disp32>
    LD.b/d t8L/t8,@(<gam>)OS.a
    <RegOp>
  • Ein zweiter Lang Dekodier Op Quad hat die Form:
    LIMM t2,<imm32>
    LIMM t1,<disp32>
    LD.b/d @(<gam>),t2L/t2,OS.a
    NOOP
  • Die Beschreibung des @(<gam>) Adressmodus repräsentiert eine Adressberechnung entsprechend der durch die modr/m und sib Bytes des Befehls, zum Beispiel @(AX + BX*4 + LD), angegebenen. Die <imm32> und <disp32> Werte sind vier Byte Werte, welche die unmittelbaren und Verschiebungsbefehl Bytes enthalten, wenn der dekodierte Befehl derartige Bytes enthält.
  • Der Lang Dekodieren 416 erzeugt ähnlich wie der erste Kurz Dekodieren 410 Operationen unter Berücksichtigung der Präsenz von jeglichen Präfix Bytes, die von Kurz Dekodierern während vorher gehender Dekodiertakte dekodiert wurden. Die effektive Größe der Adresse, die Größe der Daten, die Werte der Operanden Segment Register und das aktuelle B-Bit werden dem Lang Dekodieren 416 zur Verfügung gestellt und werden zur Erzeugung von Operationen verwendet. Keine Angaben für die indirekte Größe oder Segmentregister sind in den letzten von dem Lang Dekodieren 416 erzeugten Operationen enthalten.
  • Nur einige wenige Bedingungen verhindern eine ansonsten erfolgreiche Lang Dekodierung oder machen sie ungültig. Eine derartige Bedingung ist ein Befehlsoperationscode (Opcode), der nicht in dem Lang Dekodier Untersatz der Befehle enthalten ist. Eine zweite Bedingung ist, dass nicht alle der Bytes des Befehlspuffers 408 für den dekodierten Befehl gültig sind.
  • Der vektorisierende Dekodieren 418 behandelt Befehle, die entweder nicht von den Kurz Dekodierern oder nicht von dem Lang Dekodieren 416 dekodiert worden sind. Vektorisierende Dekodierungen sind ein vorgegebener Fall, wenn keine kurze oder lange Dekodierung möglich ist und ausreichend gültige Bytes zur Verfügung stehen. Typischerweise sind die von dem vektorisierenden Dekodieren 418 behandelten Befehle nicht in den Kurz Dekodier oder Lang Dekodier Untersätzen enthalten, aber stammen von anderen Bedingungen her, wie wenn eine Dekodierung verhindert wird oder wenn eine Ausnahmebedingung detektiert wird. Während eines normalen Betriebs werden lediglich keine kurzen und keine langen Operationen vektorisiert. Jedoch können alle Befehle vektorisiert werden. Nicht definierte Opcodes werden immer vektorisiert. Lediglich Präfix Bytes werden immer dekodiert. Die Präfix Bytes werden immer von den Kurz Dekodierern 410, 412 und 414 dekodiert.
  • Wenn eine Ausnahmebedingung während eines Dekodierungstaktes detektiert wird, wird eine vektorisierende Dekodierung erzwungen, was im Allge meinen jegliche andere Form der Dekodierung übersteuert ohne Rücksicht auf die Gültigkeit von Befehlsbytes des dekodierten Befehls. Wenn eine detektierte Ausnahmebedingung einen vektorisierenden Dekodierungstakt erzwingt, ist der erzeugte Op Quad nicht definiert und das Gültig Bit des Op Quads zur Übergabe an den Ablaufplaner 260 wird auf Null gezwungen. Das Gültig Bit des Op Quads informiert den Ablaufplaner 260, dass keine Operationen in den Ablaufplaner 260 geladen werden. Als ein Ergebnis wird kein Op Quad während eines vektorisierenden Dekodierungstaktes bei einer Ausnahme in den Ablaufplaner 260 geladen.
  • Wenige Bedingungen verhindern eine vektorisierende Dekodierung oder machen sie ungültig. Eine derartige Bedingung ist, dass nicht alle der Bytes in dem Befehlspuffer 408 gültig sind.
  • Wenn ein Befehl vektorisiert wird, wird die Steuerung an einen Eintrittspunkt im Emulationscode übergeben. Ein Eintrittspunkt im Emulationscode ist entweder in einem internen Emulationscode ROM 232 oder ein in einem externen Emulationscode RAM 236. Der Emulationscode startet von der Adresse des Eintrittspunktes und emuliert entweder einen Befehl oder startet eine geeignete Verarbeitung der Ausnahme.
  • Ein vektorisierender Dekodierungstakt wird korrekt als ein Dekodierungstakt des Makrobefehlsdekodierers 230 betrachtet. Für den Fall einer vektorisierenden Dekodierung erzeugt der Makrobefehlsdekodierer 230 den vektorisierenden Quad und erzeugt die Adresse des Emulationscode in dem Emulationscode ROM 232. Folgend auf den anfänglichen vektorisierenden Dekodierungstakt verbleibt der Makrobefehlsdekodierer 230 inaktiv, während Befehle von dem Emulationscode ROM 232 oder dem Emulationscode ROM 236 erzeugt werden, bis eine OpSeq zur Rückkehr von der Emulation (E-RET) angetroffen wird. Die Sequenzaktion zur Rückkehr von der Emulation (ERET) geht über zurück zu der Dekodierung durch den Makrobefehlsdekodierer 230. Während der auf den anfänglichen vektorisierenden Dekodierungstakt folgenden Dekodierungstakte verbleibt der Makrobefehlsdekodierer 230 inaktiv, versucht kontinuierlich den nächsten "sequentiellen" Befehl zu dekodieren, bekommt die Dekodierungstakte wiederholt ungültig gemacht, bis nachdem eine ERET angetroffen wird, und wartet daher laut Vorgabe auf die Dekodierung des nächsten "sequentiellen" Befehls.
  • Die Befehlsbytes für die Verwendung oder Dekodierung durch den vektorisierende Dekodieren 418 werden von dem ersten Byterotator 430 aus dem Befehlspuffer 408 zur Verfügung gestellt, dem gleichen Befehlsmultiplexer, der dem ersten Kurz Dekodieren SDec0 410 und dem Lang Dekodieren 416 die Befehlsbytes zur Verfügung stellt. Der vektorisierende Dekodieren 418 empfängt bis zu elf aufeinander folgende Befehlsbytes, die der maximalen Länge eines modr/m Befehls mit Ausnahme der Präfix Bytes entsprechen. Daher wird die vollständige Breite von elf Byte des ersten Byterotators 430 sowohl an den Lang Dekodieren 416 als auch den vektorisierenden Dekodieren 418 weiter gegeben. Die Vordekodierungsinformation in dem Befehlspuffer 408 wird von dem vektorisierenden Dekodieren 418 nicht verwendet.
  • Wie in dem Fall des Lang Dekodierers 416 wird das erste Byte des ersten Byterotators 430 vollständig als ein Opcode Byte dekodiert und für den Fall eines modr/m Befehls werden das zweite Befehlsbyte und möglicherweise das dritte vollständig als modr/m beziehungsweise sib Bytes dekodiert. Der vektorisierende Dekodieren 418 erzeugt Operationen, welche die Präsenz von jeglichen Präfix Bytes berücksichtigen, die während voran gegangener Dekodierungstakte von den Kurz Dekodierern dekodiert wurden. Die Existenz von einem OF Präfix wird durch die Dekodierung der Opcode Bytes berücksichtigt. Zusätzlich zu der Erzeugung von Operationen basierend auf der Dekodierung von modr/m und sib Bytes bestimmt der ersten Byterotator 430 auch die Länge des Befehls für die Verwendung durch verschiedene Programmzähler, ob der Befehl ein modr/m Befehl zur Verhinderung oder zum ungültig machen des Lang Dekodierers ist und ob der Befehl ein Befehl in dem Lang Dekodier Untersatz von Operationscodes (Opcodes) ist. Falls nicht, wird eine vektorisierende Dekodierung eingeleitet. Die effektive Größe der Adresse, die Größe der Daten und die Werte des Operanden Segmentregisters werden dem vektorisierenden Dekodieren 418 zur Verfügung gestellt und werden für die Erzeugung von Operationen verwendet. Keine Spe zifizierer für indirekte Größe oder Segmentregister sind in den abschließenden von dem vektorisierenden Dekodieren 418 erzeugten Operationen enthalten.
  • Während eines vektorisierenden Dekodierungstaktes erzeugt der vektorisierende Dekodieren 418 einen vektorisierenden Op Quad, erzeugt einen Eintrittspunkt in dem Emulationscode oder eine Vektoradresse und initialisiert eine Emulationsumgebung. Der vektorisierende Op Quad wird spezifiziert, um verschiedene Informationen weiterzugeben, um die Arbeitsregister der Emulationsumgebung zu initialisieren.
  • Der Wert des Eintrittspunkts in dem Emulationscode oder der Vektoradresse basiert auf einer Dekodierung der ersten und zweiten Befehlsbytes, zum Beispiel der Opcode und modr/m Bytes, sowie anderen Informationen wie der Präsenz von einem OF Präfix, REP Präfix oder ähnlichem. Für den Fall einer durch eine Ausnahmebedingung veranlassten Vektorisierung basiert der Eintrittspunkt oder die Vektoradresse auf einem einfachen kodierten Ausnahmeidentifizierer.
  • Die Emulationsumgebung wird für die Auflösung von Abhängigkeiten der Umgebung gespeichert. Alle der Kurz Dekodieren 410, 412 und 414 und Lang Dekodierer 416 lösen Abhängigkeiten der Umgebung, wie Abhängigkeiten von den effektiven Größen der Adresse und der Daten, direkt auf, sobald Operationen erzeugt werden, so dass diese Operationen niemals Spezifizierer für indirekte Größen oder Register enthalten. Jedoch beziehen sich Operationen des Emulationscodes auf derartige effektive Werte für Adress- und Datengrößen für eine bestimmte Instanz des Befehls, der emuliert wird. Die Emulationsumgebung wird verwendet, um diese zusätzliche Information zu speichern, die sich auf die bestimmte Operation bezieht, welche vektorisiert wird. Diese Information umfasst allgemeine Registernummern, effektive Größen von Adressen und Daten, eine effektive Nummer des Operanden Segmentregisters, den Präfix Byte Zähler und eine Aufzeichnung von der Existenz eines LOCK Präfixes. Die Emulationsumgebung lädt auch ein modr/m reg Feld und ein modr/m regm Feld, welche in die Reg und Regm Register geladen werden. Die Emulationsumgebung wird an dem Ende eines erfolgreichen vektorisierenden Dekodierungstaktes initialisiert und verbleibt in dem anfänglichen Zustand für im wesentlichen die Dauer der Emulation eines Befehls durch den Emulationscode, bis ein ERET Code angetroffen wird.
  • Der vektorisierende Dekodieren 418 erzeugt vier Operationen von einem Op Quad in einer von vier Formen. Alle vier Formen enthalten drei LIMM Operationen. Die vier Formen unterscheiden sich nur in den unmittelbaren Werten der LIMM Operationen und darin, ob die dritte Operation eine LEA Operation oder eine NOOP Operation ist.
  • Ein erster vektorisierender Dekodierungs Op Quad hat die Form:
    LIMM t2,<imm32>
    LIMM t1,<disp32>
    LEA t6,@(<gam>),_.a
    LIMM t7,LogSqDecPC[31..0] //logisch seg. Nächster //Befehls PC
  • Ein zweiter vektorisierender Dekodierungs Op Quad hat die Form:
    LIMM t2,<imm32>
    LIMM t1,<disp32>
    NOOP
    LIMM t7,LogSqDecPC[31..0]
  • Ein dritter vektorisierender Dekodierungs Op Quad hat die Form:
    LIMM t2,<+/– 1/2/4> //gleich zu "LDK(d)S t2, + 1/+ 2"
    LIMM t1,<+/– 2/4/8> //gleich zu "LDK(d)S t1, + 2/+ 4"
    NOOP
    LIMM t7,LogSqDecPC[31..0]
  • Ein dritter vektorisierender Dekodierungs Op Quad hat die Form:
  • Figure 00310001
  • Die ersten beiden Formen von vektorisierenden Op Quads gelten für die meisten Opcodes. Die erste Form wird für auf Speicher verweisende modr/m Befehle verwendet, für die eine LEA Operation verwendet wird, um eine effektive Operandenadresse eines allgemeinen Adressmodus in ein Arbeitsregister zu berechnen und zu laden. Die zweite Form wird verwendet für nicht modr/m und auf Register verweisende modr/m Befehle. Für Befehle, welche die zweite Form haben, wird notwendigerweise keine Adresse berechnet, obwohl die <imm32> und <disp32> Werte insoweit verwendbar bleiben, wie sie dem Opcode Byte folgende Befehlsbytes enthalten. Eine dritte Form von vektorisierenden Op Quads wird verwendet für alle Zeichenfolge Befehle sowie einiger benachbarter nicht modr/m Befehle. Eine vierte Form von vektorisierenden Op Quads unterstützt Spezialvektorisierung und Erfordernisse der Emulation für nahe RET Befehle.
  • Der Makrobefehlsdekodierer 230 hat vier Programmzähler einschließlich drei Dekodier Programmzählern 420, 422 und 424 und einem Holprogrammzähler 426. Ein erster Dekodierungsprogrammzähler, ein Befehls PC 420 genannt, ist die logische Adresse des ersten Bytes einschließlich jeglicher Präfix Bytes von entweder dem derzeit dekodierten Befehl oder, falls derzeit kein Befehl dekodiert wird, dem nächsten zu dekodierenden Befehl. Falls die Dekodierungsoperation eine mehrfache Befehlsdekodierung ist, zeigt der Befehls PC 420 auf den ersten Befehl der mehreren zu dekodierenden Befehle. Der Befehls PC 420 entspricht der architekturalen Adresse eines Befehls und wird verwendet, um Befehlsfehler Programmzähler zum Behandeln von Ausnahmen zu erzeugen. Der Befehls PC 420 wird zusammen mit entsprechenden Op Quads runter zu dem Ablaufplaner 260 geleitet und wird von einer Operationsübergabeeinheit (OCU) (siehe 970, gezeigt in der 9) verwendet, um Befehlsfehler Programmzähler zu erzeugen, die während der Verarbeitung von Ausnahmen gespeichert werden. Wenn ein Op Quad von dem Makrobefehlsdekodierer 230 erzeugt wird, wird der aktuelle Wert des Befehls PC 420 an den Op Quad angeheftet und zusammen mit dem Op Quad in den Op Quad Eintrag in dem Ablaufplaner 260 geladen. Ein zweiter Dekodierprogrammzähler, ein logischer Dekodierungs PC 422 genannt, ist die logische Adresse der nächsten zu dekodierenden Befehlsbytes und adressiert entweder ein Opcode Byte oder ein Präfix Byte. Ein dritter Programmzähler, ein linearer Dekodierungs PC 424 genannt, ist die lineare Adresse der nächsten zu dekodierenden Befehlsbytes und adressiert entweder ein Opcode Byte oder ein Präfix Byte. Der logische Dekodierungs PC 422 und der lineare Dekodierungs PC 424 zeigen auf das gleiche Befehlsbyte. Der lineare Dekodierungs PC 424 bezeichnet die Adresse des Befehlsbytes, das derzeit in dem ersten Byterotator 430 ist.
  • Zwei verschiedene Dekodieren in dem Makrobefehlsdekodierer 230 funktionieren auf der Basis des Dekodierens oder des Verbrauchens von entweder Präfix Bytes oder ganzen Befehlen ohne jegliche Präfix Bytes, so dass Präfixe im allgemeinen als ein Byte Befehle behandelt werden. Daher sind die Adressgrenzen zwischen Befehls- und Präfix Byte Dekodierungen wichtiger als die Grenzen der Befehle allein. Konsequenterweise ist, an dem Anfang jedes Dekodierungstaktes, das nächste zu dekodierende Befehlsbyte nicht notwendigerweise der wahre Anfang eines Befehls.
  • An dem Anfang eines Dekodierungstaktes enthalten der logische Dekodierungs PC 422 und der lineare Dekodierungs PC 424 die logische und die lineare Adresse des nächsten zu dekodierenden Befehls, entweder ein Befehl oder ein Präfix Byte. Der lineare Dekodierungs PC 424 ist ein primärer Programmzählerwert, der während des Prozesses der Dekodierung verwendet wird, um auf den Befehlspuffer 408 zuzugreifen. Der lineare Dekodierungs PC 424 repräsentiert den Startpunkt für die Dekodierung eines Taktes und steuert insbesondere die Byterotator Zuführbytes von dem Befehlspuffer 408 für den ersten Kurz Dekodieren 410 und für den Lang und vektorisierenden Dekodieren 416 und 418. Der lineare Dekodierungs PC 424 ist auch der Referenzpunkt für die Bestimmung der Adresse des Befehls von jeglichen weiteren Kurzdekodierbefehlen oder Präfix Bytes, damit Steuersignale für die Byterotatoren erzeugend, welche den zweiten und den dritten Kurz Dekodieren 412 und 414 versorgen.
  • Der lineare Dekodierungs PC 424 agiert auch sekundär, um während des ersten Dekodierungstaktes von neuen Befehlen auf Übereinstimmungen bei Stopppunkten zu überprüfen, bevor Präfix Bytes dekodiert werden, und um während erfolgreicher Befehlsdekodiertakte auf Überläufe bei den Codesegmenten durch den Makrobefehlsdekodierer 230 zu überprüfen.
  • Der logische Dekodierungs PC 422 wird für mit dem Programmzähler zusammenhängende Transfersteuerbefehle, einschließlich CALL Befehlen, verwendet. Der logische Dekodierungs PC 422 wird der Verzweigungseinheit 234 zur Verfügung gestellt, um mit dem Verschiebungswert von einem mit dem PC zusammenhängenden Transfersteuerbefehl für die Berechnung einer Adresse für das Verzweigungsziel summiert zu werden. Der logische Dekodierungs PC 422 unterstützt auch die Emulation von Befehlen per Emulationscode. Der nächste sequentielle logische Dekodierungs Programmzähler (PC) 422 ist für den vektorisierenden Op Quad für allgemeine Verwendung im Emulationscode von der Speicherung in einem temporären Register verfügbar. Zum Beispiel wird der nächste sequentielle logische Dekodierungs PC 422 verwendet, um eine Rückkehradresse zur Verfügung zu stellen, die einen CALL Befehl auf den Stapel schiebt.
  • Ein nächster logischer Dekodierungs PC 428 wird auf den Wert des nächsten sequentiellen logischen Dekodierungs Programmzählers gesetzt und hat eine funktionale Verwendbarkeit, die über die des logischen Dekodierungs PC 422 hinaus geht. Der nächste logische Dekodierungs PC 428 liefert direkt die Rückkehradresse für CALL Befehle, die von dem Makrobefehlsdekodierer 230 dekodiert wurden. Der nächste logische Dekodierungs PC 428 wird auch während vektorisierender Dekodierungstakte zu der Emulationscodelogik über eine der Operationen in dem vektorisierenden Op Quad weiter geleitet.
  • Während eines Dekodierungstaktes zeigt der lineare Dekodierungs PC 424 auf die nächsten zu dekodierenden Befehlsbytes. Die vier niedrigstwertigen Bits des linearen Dekodierungs PC 424 zeigen auf das erste Befehlsbyte in dem Befehlspuffer 408 und zeigen damit direkt den Betrag der erforderlichen Byterotation an, um das erste und nach folgende Befehlsbytes in dem Befehls-Cachespeicher 214 auszurichten. Der erste Byterotator 430 ist ein Befehlsmultiplexer, insbesondere ein 16 : 1 Multiplexer, zum Zugreifen auf Bytes in dem Befehlspuffer 408, die um den Betrag des linearen Dekodierungs PC 424 versetzt sind. Der erste Byterotator 430 ist sieben Bytes breit für den ersten Kurz Dekodieren SDec0 410 und elf Bytes breit für den Lang Dekodieren 416 und den vektorisierende Dekodieren 418 in Kombination. Eine geteilte Logik in dem ersten Kurz Dekodieren SDec0 410, dem Lang Dekodieren 416 und dem vektorisierenden Dekodieren 418 erzeugt einen ersten Wert für die Befehlslänge Ilen0 für den ersten Befehl. Der zweite und dritte Byterotator 432 und 434 sind sieben Byte breite Befehlsmultiplexer, insbesondere 16 : 1 Multiplexer. Der zweite Byterotator 432 greift auf Bytes in dem Befehlspuffer 408 zu, die um die Summe des Betrags des linearen Dekodierungs PC 424 und der ersten Befehlslänge Ilen0 (Modulo 16) versetzt sind. Eine Logik in dem zweiten Kurz Dekodieren SDec0 412 erzeugt einen zweiten Wert für die Befehlslänge Ilen1 für den zweiten Befehl. Der dritte Byterotator 434 greift auf Bytes in dem Befehlspuffer 408 zu, die um die Summe des Betrags des linearen Dekodierungs PC 424 und der ersten und zweiten Befehlslänge Ilen0 und Ilen1 versetzt sind. Die Byterotatoren 430, 432 und 434 multiplexen Befehlsbytes, aber keine Vordekodierungsbits. Die Byterotatoren 430, 432 und 434 werden unter Verwendung von Vordekodierungsinformation gesteuert, in der die Vordekodierungsbits, die zu dem ersten Opcode Byte oder dem ersten Byte des ersten Befehls gehören, den zweiten Rotator 432 direkt steuern. Das erste Byte des zweiten Befehls steuert direkt den dritten Rotator 434. Jeder Vordekodierungscode enthält eine Befehlslänge, aber was dem nächsten Rotator zugeführt wird ist ein Zeiger. Der Zeiger wird abgeleitet, indem die vier niedrigstwertigen Bits des Programmzählers bei dem aktuellen Befehl plus der Länge genommen werden, um den Programmzähler zu dem nächsten Befehl zu erhalten.
  • Alle Programmzähler 420, 422, 424 und 428 in dem Makrobefehlsdekodierer 230 werden während der Verarbeitung von Befehlen und Ausnahmen initialisiert. Eine Vielzahl von Signalquellen aktivieren diese Initialisierung. Zuerst stellt die Verzweigungseinheit 234 eine Zielverzweigungsadresse zur Verfügung, wenn ein auf den PC bezogener Transfersteuerbefehl dekodiert und als genommen vorher gesagt wird. Zweitens stellt ein Rückkehradressenstapel (nicht gezeigt) eine vorher gesagte Rückkehrzieladresse zur Verfügung, wenn ein naher RET Befehl dekodiert wird. Drittens erzeugt der Ablaufplaner 260 eine korrekte und Ersatz Verzweigungsadresse, wenn der Makrobefehlsdekodierer 230 zusammen mit den verbleibenden Schaltungen in dem Prozessor 120, von dem Ablaufplaner 260 neu gestartet wird wegen einer falsch vorher gesagten Verzweigungsbedingungs (BRCOND) Operation. Viertens stellt die Registereinheit 244, die primäre RegOp Ausführungseinheit, eine neue Dekodierungsadresse zur Verfügung, wenn eine WRIP RegOp ausgeführt wird. Die Ausführung der WRIP RegOp erlaubt es dem Emulationscode, das Dekodieren eines Befehls explizit umzuleiten. In allen vier Fällen wird eine logische Adresse zur Verfügung gestellt und verwendet, um die drei Dekodierprogrammzähler 420, 422, 424 gleichzeitig neu zu initialisieren. Für den linearen Dekodierungs PC 424 wird ein Wert der linearen Adresse zur Verfügung gestellt durch die Addition der zur Verfügung gestellten logischen Adresse mit der derzeitigen Basisadresse des Codesegments, um die entsprechende lineare Adresse zum Laden in den linearen Dekodierungs PC 424 zu erzeugen. Die logische Adresse wird in den aktuellen Befehls PC 420 und den logischen Dekodierungs PC 422 geladen. Für jeden Dekodierungstakt bis zu einer nächsten Neuinitialisierung aktualisiert der Makrobefehlsdekodierer 230 sequentiell und synchron den aktuellen Befehls PC 420, den logischen Dekodierungs PC 422 und den linearen Dekodierungs PC 424, wie Befehlsbytes erfolgreich von den einzelnen Dekodierern des Makrobefehlsdekodierers 230 dekodiert und verbraucht werden.
  • Die Erzeugung der Befehlslängen Ilen0 und Ilen1 geschieht seriell. Um diesen Prozess durch die Emulation einer parallelen Operation zu beschleunigen, bestimmt die Befehlslängenvorausschaulogik 436 schnell die Befehlslängen Ilen0 und Ilen1 unter Verwendung von vier Vordekodierungsbits, welche die Länge von jedem Befehlsbyte in dem Befehlspuffer 408 angeben. Bei den Vordekodierungsbits, die dem Opcode Byte des ersten Befehlsbytes in dem Befehlspuffer 408 zugeordnet sind, gibt das erste Befehlsbyte, das zu dem ersten Kurz Dekodieren SDec0 410 multiplext wird, direkt einen Byteindex des Opcode Bytes des zweiten Befehlsbytes in dem Befehlspuffer 408 an. Bei den Vordekodierungsbits, die dem Opcode Byte des zweiten Befehlsbytes in dem Befehlspuffer 408 zugeordnet sind, gibt das zweite Befehlsbyte, das zu dem zweiten Kurz Dekodieren SDec1 412 multiplext wird, direkt einen Byteindex des Opcode Bytes des dritten Befehlsbytes in dem Befehlspuffer 408 an. Die Befehlslängenvorausschaulogik 436 enthält zwei vier Bit breite 16 : 1 Multiplexer zum Erzeugen des Byteindexe der Opcode Bytes der zweiten und dritten Befehlsbytes in dem Befehlspuffer 408.
  • Die Befehlslängenvorausschaulogik 436 enthält auch eine Logik zum Bestimmen der Gültigkeit des Satzes von Vordekodierungsbits. Die Vordekodierungsbits sind gültig, wenn das dazu gehörige Befehlsbyte der Start eines gültigen Kurzdekodierbefehls ist. Insbesondere bestimmt die Befehlslängenvorausschaulogik 436, ob Vordekodierungsbits für ein gegebenes Byte in dem Befehlspuffer 408 auf das gleiche Byte zeigen, was eine Länge von Null für einen Befehl, der bei diesem Byte startet, bedeutet. Falls dies so ist, ist dieses Byte nicht der Anfang eines Kurzdekodierbefehls und keine weitere Kurzdekodierung ist möglich. Anderenfalls ist eine Kurzdekodierungsoperation möglich und die Vordekodierungsbits zeigen auf den Anfang des nächsten Befehls.
  • Der zwischen den Hauptspeicher 130 und den Befehls-Cachespeicher 214 geschaltete Vordekodierer 270 hat acht logische Einheiten, von denen jede ihre dazu gehörigen Befehlsbytes sowie in einigen Fällen das folgende eine oder zwei Befehlsbytes untersucht. Das erste Befehlsbyte wird als ein Opcode Byte dekodiert und das zweite und dritte Befehlsbyte 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 eines Befehls bestimmt und ob der Befehl als ein "Kurz" Befehl klassifiziert wird. Die Länge des Befehls wird zu einem festen Wert mit vier Bit addiert, welcher der Position der logi schen Einheit im Hinblick auf die sechzehn logischen Einheiten entspricht, um den Byteindex zu bestimmen, der von der Befehlslängenvorausschaulogik 436 verwendet wird. Dieser Byteindex wird als ein Wert der Vordekodierungsbits gesetzt, falls der Befehl unter die Kriterien eines Kurzbefehls fällt. Für Befehlsbytes, die nicht die Kriterien eines Kurzbefehls erfüllen, werden die Vordekodierungsbits ohne hoch zu zählen auf den festen Wert mit vier Bit gesetzt, welcher der Position der logischen Einheit im Hinblick auf die sechzehn logischen Einheiten entspricht, um eine Länge des Befehls von Null zuzuweisen. Eine implizite Befehlslänge von Null ist ein Hinweis, dass der Befehl kein Kurzbefehl ist. Die Vordekodierungsbits werden von vier auf drei Bits abgeschnitten, da die Kurzdekodierbefehle niemals länger als sieben Bytes sind und das höchstwertige Bit leicht aus den drei Vordekodierungsbits und der dazu gehörigen festen Byteadresse rekonstruiert werden kann. Die Erweiterung von drei auf vier Vordekodierungsbits wird von einer Vordekodierungserweiterungslogik 440 durchgeführt, die sechzehn Logikeinheiten hat, welche den sechzehn Befehlsbytes des Befehls-Cachespeichers 214 entsprechen. Die sechzehn Logikeinheiten der Vordekodierungserweiterungslogik 440 arbeiten unabhängig und gleichzeitig an den Vordekodierungsbits, wenn die Befehlsbytes aus dem Befehls-Cachespeicher 214 in den Befehlspuffer 408 geholt werden.
  • Die letzten beiden der zweiunddreißig Befehlsbytes, die vordekodiert und in den Befehls-Cachespeicher 214 geladen werden, haben nur ein oder zwei Bytes für die Untersuchung durch den Vordekodierer 270. Für modr/m Opcodes kann die komplette Länge des Befehls nicht bestimmt werden. Daher sind 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 Befehlsbyte 15 erzwingt die Logikeinheit 15 des Vordekodierers 270 ein Befehlslänge von Null für alle modr/m Opcodes und für nicht Kurzdekodierbefehle. Für das Befehlsbyte 14 wird eine effektive Länge der Adresse von Null erzwungen sowohl für modr/m Opcodes mit einem Adressierungsmodus, der eine Untersuchung von einem sib Byte erfordert, um die Länge des Befehls zuverlässig zu bestimmen, als auch für alle nicht kurzen Befehle.
  • Während jedes Dekodierungstaktes überprüft der Makrobefehlsdekodierer 230 auf verschiedene Ausnahmebedingungen, einschließlich einem Befehlsstopppunkt, einem anhängigen nicht maskierbaren Interrupt (NMI), einem anhängigen Interrupt (INTR), einem Überlauf eines Codesegments, einem Seitenfehler bei dem Holen eines Befehls, einer Befehlslänge größer als sechzehn Bytes, einem nicht verriegelbaren Befehl mit einem LOCK Präfix, einer Bedingung mit nicht verfügbarem Gleitpunkt und einer anhängigen Gleitkommafehlerbedingung. Einige Bedingungen werden nur während eines erfolgreichen Dekodierungstaktes bewertet, andere Bedingungen werden unabhängig von jeglichen Dekodierungsvorgängen während des Taktes bewertet. Wenn eine aktive Ausnahmebedingung detektiert wird, werden alle Befehlsdekodierungstakte einschließlich Kurz, Lang und vektorisierenden Dekodierungstakten verhindert und eine vektorisierende "Ausnahme" Dekodierung wird in dem Dekodierungstakt, welcher der Detektierung der Ausnahme folgt, erzwungen. Die Erkennung einer Ausnahmebedingung wird nur übersteuert oder verhindert durch eine Inaktivität des Makrobefehlsdekodierers 230, zum Beispiel wenn Emulationscode Op Quads von dem Ablaufplaner 260 akzeptiert werden anstatt von Kurz und Lang oder Vektor Dekodierungs Op Quads. Dies führt dazu, dass die Erkennung und Behandlung jeglicher Ausnahmebedingungen verzögert wird, bis eine ERET Op Seq die Kontrolle an den Makrobefehlsdekodierer 230 zurück gibt.
  • Während des Dekodierungstaktes, der eine Ausnahmevektorisierung erzwingt, wird eine spezielle Emulationscode Vektoradresse anstelle einer normalen Befehlsvektoradresse erzeugt. Der vektorisierende Op Quad, der von dem Lang und dem vektorisierenden Dekodieren 416 und 418 erzeugt wird, ist nicht definiert. Die Ausnahmevektoradresse ist ein fester Wert, außer für niedrigwertige Bits zum Identifizieren der bestimmten Ausnahmebedingung, die erkannt und behandelt wird. Wenn mehrere Ausnahmebedingungen gleichzeitig detektiert werden, werden, die Ausnahmen in einer Prioritätsordnung sortiert und die Ausnahme mit der höchsten Priorität wird erkannt.
  • Die Ausnahme des Befehlsstopppunktes, die Ausnahmebedingung mit der höchsten Priorität, wird erkannt, wenn der lineare Dekodierungs PC 424 auf das erste Byte eines Präfixe enthaltenen Befehls zeigt, der lineare Dekodierungs PC 424 mit der Adresse eines Stopppunktes übereinstimmt, die als ein Befehlsstopppunkt freigegeben ist, und keines der Befehlsstopppunkt Maskierungsflags frei ist. Ein Maskierungsflag (RF) maskiert insbesondere die Erkennung eines Befehlsstopppunktes. Ein weiteres Maskierungsflag (BNTF) maskiert zeitweise NMI Anforderungen und Befehlsstopppunkte.
  • Die anhängige NMI Ausnahme, die Ausnahme mit der zweithöchsten Priorität, wird erkannt, wenn eine NMI Anforderung anhängig ist und keines der NMI Maskierungsflags frei ist. Eine Maskierung (NF) maskiert insbesondere nicht maskierbare Interrupts. Ein weiteres Maskierungsflag (BNTF) maskiert zeitweise NMI Anforderungen und Befehlsstopppunkte.
  • Die anhängige INTR Ausnahme, in der Priorität die nächste Ausnahme folgend auf die anhängige NMI Ausnahme, wird erkannt, wenn eine NMI Anforderung anhängig ist und das Interrupt Flag (IF) und das temporäre Interrupt Flag (ITF) frei sind.
  • Die Ausnahme des Codesegmentüberlaufs, in der Priorität die nächste Ausnahme folgend auf die anhängige INTR Ausnahme, wird erkannt, wenn der Makrobefehlsdekodierer 230 versucht, einen Satz von Befehlen jenseits einer derzeitigen Grenze des Codesegments erfolgreich zu dekodieren.
  • Die Ausnahme Seitenfehler beim Holen eines Befehls, die eine Priorität unmittelbar niedriger hat als die Ausnahme des Codesegmentüberlaufs, wird erkannt, wenn der Makrobefehlsdekodierer 230 von dem Befehlspuffer 408 zusätzliche gültige Befehlsbytes erfordert, bevor die Dekodierung eines weiteren Befehls oder eines Präfix Bytes möglich ist, und der Befehlsübersetzung-Seitenblickpuffer (ITB) signalisiert, dass ein Seitenfehler bei dem aktuellen Holen eines Befehls aufgetreten ist. Eine Fehlerbedingung der Befehl Hol Steuerschaltung 218 wird wiederholt erneut versucht, so dass der ITB kontinuierlich einen Seitenfehler meldet, bis der Seitenfehler von dem Makrobefehlsdekodierer 230 erkannt wird und die nachfolgende Bearbeitung der Ausnahmebehandlung stoppt und das Holen von Befehlen auf eine neue Adresse umleitet. Der Hinweis auf einen Fehler von dem ITB hat den gleichen Zeitablauf wie die aus dem Befehls-Cachespeicher 214 geladenen Befehle und wird daher in dem nachfolgenden Dekodierungstakt registriert. Der ITB signalisiert nicht notwendigerweise einen Fehler bei aufeinander folgenden Versuchen, einen Befehl zu holen, so dass der Makrobefehlsdekodierer 230 den Hinweis auf einen Fehler hält, bis das Holen auf eine neue Befehlsadresse umgeleitet ist. Auf die Erkennung eines Seitenfehlers wird zusätzliche Fehlerinformation in ein spezielles Registerfeld geladen.
  • Die Ausnahme für einen Befehl mit einer Länge größer als sechzehn Byte, welche eine Priorität gerade unterhalb der Ausnahme Seitenfehler beim Holen eines Befehls hat, wird erkannt, wenn der Makrobefehlsdekodierer 230 versucht, einen Befehl erfolgreich zu dekodieren, der eine gesamte Länge einschließlich der Präfix Bytes von mehr als fünfzehn Bytes hat. Die Ausnahme für einen Befehl mit einer Länge größer als sechzehn Bytes wird detektiert durch die Zählung der Anzahl der Präfix Bytes bevor ein aktueller Befehl dekodiert wird und durch die Berechnung der Länge des Rests des Befehls, wenn er dekodiert wird. Falls die Summe der Präfix Bytes und der verbleibenden Länge des Befehls größer als sechzehn Byte ist, wird ein Fehler erkannt.
  • Die Ausnahme für einen nicht verriegelbaren Befehl mit einem LOCK Präfix, die eine Priorität unterhalb der Ausnahme für die Befehlslänge hat, wird erkannt, wenn der Makrobefehlsdekodierer 230 versucht, einen Befehl erfolgreich zu dekodieren, der ein LOCK Präfix hat, wobei der Befehl nicht in dem verriegelbaren Befehlsuntersatz enthalten ist. Die Ausnahme für einen nicht verriegelbaren LOCK Befehl wird detektiert basierend auf der Dekodierung des Opcode Bytes und der Existenz eines OF Präfixes. Die Ausnahme für einen nicht verriegelbaren LOCK Befehl tritt nur während vektorisierender Dekodierungstakte auf, da der LOCK Präfix kurze und lange Dekodierungen verhindert.
  • Die Ausnahme nicht verfügbares Gleitkomma, welche die zweitniedrigste Priorität hat, wird erkannt, wenn der Makrobefehlsdekodierer 230 versucht, einen WAIT Befehl oder einen ESC Befehl, der auf einer Prozessorsteuerung ESC ist, erfolgreich zu dekodieren, und die Meldung eines Gleitkommafehlers anhängig ist. Der Makrobefehlsdekodierer 230 detektiert die Ausnahme nicht verfügbares Gleitkomma basierend auf der Dekodierung von einem Opcode und einem modr/m Byte, zusätzlich zu der Existenz eins OF Präfixes.
  • Während jedes Taktes versucht der Makrobefehlsdekodierer 230, irgendeine Form der Befehlsdekodierung eines oder mehrerer Befehle auszuführen. Typischerweise gelingt dem Makrobefehlsdekodierer 230 die Durchführung entweder einer oder mehrerer kurzer Dekodierungen, eine lange Dekodierung oder eine vektorisierende Dekodierung. Gelegentlich ist keine Dekodierung erfolgreich wegen drei Typen von Bedingungen, umfassend die Detektierung einer aktiven Ausnahmebedingung, das Fehlen einer ausreichenden Anzahl von gültigen Bytes in dem Befehlspuffer 408 oder der Makrobefehlsdekodierer 230 geht wegen eines externen Grundes nicht weiter.
  • Wenn eine aktive Ausnahmebedingung detektiert wird, werden alle Formen der Dekodierung eines Befehls verhindert und, während des zweiten Dekodierungstaktes nach der Detektierung der Ausnahmebedingung, wird ein vektorisierender Ausnahme Dekodierungstakt erzwungen; der einen ungültigen Op Quad erzeugt.
  • Wenn in dem Befehlspuffer 408 keine ausreichende Anzahl von gültigen Bytes zur Verfügung steht, werden entweder keine gültigen Bytes in dem Befehlspuffer 408 gehalten oder zumindest der erste Opcode ist gültig und einer der Dekodieren dekodiert den Befehl, aber die Länge des dekodierten Befehls erfordert weitere gültige Bytes in dem Befehlspuffer 408, von denen zur Zeit nicht alle zur Verfügung stehen.
  • Wenn ein externer Grund ein Fortschreiten des Makrobefehlsdekodierer 230 verhindert, ist entweder der Ablaufplaner 260 voll und kann während eines Dekodierungstaktes keinen weiteren Op Quads akzeptieren oder der Ablaufplaner 260 akzeptiert zur Zeit Emulationscode Op Quads, so dass der Makrobefehlsdekodierer 230 inaktiv ist, auf eine Rückkehr zur Dekodierung wartend.
  • In den letzten beiden Fällen wird der Zustand der Dekodierung des Makrobefehlsdekodierers 230 an dem Vorrücken gehindert und der Makrobefehlsdekodierer 230 versucht einfach die gleichen Dekodierungen in dem nächsten Dekodierungstakt. Die Steuerung der Verhinderung des Makrobefehlsdekodierers 230 basiert auf der Erzeugung eines Satzes von Dekodier Gültig Signalen, wobei ein Signal jedem der Dekodieren entspricht. Für jeden Dekodieren gibt es mehrere Gründe, die zu den Dekodier Gültig Signalen kombiniert sind, um festzustellen, ob dieser Dekodieren fähig ist, eine Dekodierung erfolgreich auszuführen. Die Dekodier Gültig Signale für alle der Dekodieren werden dann zusammen überwacht, um den Typ des durchzuführenden Dekodierungstaktes zu bestimmen. Der Typ des Dekodierungstaktes zeigt den bestimmten Dekodieren an, der die Dekodierung ausführen soll. Signale anzeigend den ausgewählten Typ von Dekodierungstakt wählen zwischen verschiedenen Signalen aus dem Makrobefehlsdekodierer 230 aus, die von den verschiedenen Dekodierern erzeugt wurden, wie alternativen nächsten Dekodierungs PC Werten, und werden auch angelegt, um einen Op Quad Multiplexer 444 zu steuern, der den dem Ablaufplaner 260 zugeführten Eingangs Op Quad auswählt aus den Op Quads, die von den Kurz Dekodierern, dem Lang Dekodieren 416 und dem vektorisierenden Dekodieren 418 erzeugt wurden.
  • Für den Fall von vektorisierenden Dekodierungstakten erzeugt der Makrobefehlsdekodierer 230 auch Signale, die ein Einspringen zu einem Eintrittspunkt in entweder dem internen Emulationscode ROM 232 oder dem externen Emulationscode RAM 236 einleiten. Der Makrobefehlsdekodierer 230 überwacht dann die aktive Dauer des Holens von dem Emulationscode und des Ladens in den Ablaufplaner 260.
  • Der Befehlsdekodierer 220 enthält eine Verzweigungseinheit (nicht gezeigt) zum Durchführen einer Verzweigungsvorhersage, so dass Operationen spekulativ ausgeführt werden. Die Leistungsfähigkeit eines außer der Reihe Prozessors wird verbessert, wenn Verzweigungen schnell und akkurat behandelt werden, so dass die Pipeline erschöpfende Fehlvorhersagen vermieden werden. Der Prozessor 120 verwendet einen zweistufigen Algorithmus für die Verzweigungsvorhersage, der detailliert offenbart ist in dem U.S. Patent mit der Nummer 5,454,117 mit dem Titel Configurable Branch Prediction For A Processor Performing Speculative Execution (Puziol et al., erteilt am 26. September 1995), dem U. S. Patent mit der Nummer 5,327,547 mit dem Titel Two-Level Branch Prediction Cache (Stiles et al., erteilt am 5. Juli 1994), dem U.S. Patent mit der Nummer 5,163,140 mit dem Titel Two-Level Branch Prediction Cache (Stiles et al., erteilt am 10. November 1992) und dem U. S. Patent mit der Nummer 5,093,778 mit dem Titel Integrated Single Structure Branch Prediction Cache (Favor et al., erteilt am 3. März 1993). Der Prozessor 120 verwendet des weiteren eine Verzweigungsverlaufstabelle (BHT) mit 8.192 Einträgen (nicht gezeigt), welche indiziert wird durch die Kombination von vier Programmzählerbits mit neun Bits der globalen Verlaufsgeschichte. Jeder Eintrag in der BHT enthält zwei Verlaufsbits. Die BHT ist ein RAM mit zwei Ports, was sowohl einen Lese/Nachschlag Zugriff und einen Schreib/Aktualisierungszugriff erlaubt. Nachschlagen und Aktualisieren in der BHT gerät in keinen Konflikt, weil sie an entgegengesetzten Halbphasen eines Taktzyklus stattfinden. Die große Anzahl an Einträgen in der BHT ist in einem angemessenen integrierten Schaltungsbereich untergebracht, weil die BHT nur die Richtungen von bedingten Verzweigungen vorhersagt, so dass Einträge nicht markiert werden und vorher gesagte Verzweigungszieladressen nicht gespeichert werden, außer für einen Rückkehradressstapel mit 16 Einträgen (nicht gezeigt). Entsprechend ist ein Zugriff auf die BHT dahingehend ähnlich zu einem direkten Abbilden in eine einem Cachespeicher ähnliche Struktur, dass die BHT indiziert wird, um auf einen Eintrag in der BHT zuzugreifen und von dem angesprochenen Eintrag wird angenommen, dass er ein Verzweigungsbefehl sei. Für andere Verzweigungen als Rückkehren wird die Zieladresse während des Dekodierungstaktes berechnet. Die Zieladresse wird mit hinreichender Geschwindigkeit berechnet unter Verwendung einer digkeit berechnet unter Verwendung einer Vielzahl von parallelen Addierern (nicht gezeigt), welche alle möglichen Zieladressen berechnen, bevor der Ort eines Verzweigungsbefehls bekannt ist. An dem Ende des Dekodierungstaktes bestimmt die Verzweigungseinheit 234 welches, falls überhaupt ein, Ergebnis für die Zieladresse gültig ist.
  • Falls eine Verzweigung als genommen vorher gesagt ist, ist die Zieladresse sofort bekannt und die Zielbefehle werden in dem folgenden Takt geholt, was eine Strafe für die genommene Verzweigung von einem Takt veranlasst. Die Strafe für die genommene Verzweigung wird verhindert mit der Verwendung eines Verzweigungsziel Puffers (BTB) 456. Der BTB 456 enthält sechzehn Einträge, wobei jeder Eintrag sechzehn Befehlsbytes mit dazu gehörigen Vordekodierungsbits hat. Der BTB 456 wird mit der Verzweigungsadresse indiziert und auf ihn wird während des Dekodierungstaktes zugegriffen. Befehle von dem BTB 456 werden an den Befehlsdekodierer 220 gesendet, was die Strafe für die genommene Verzweigung eliminiert, für einen Treffer im Cachespeicher des BTB 456 wenn der BHT eine genommene Verzweigung vorhersagt. Während jedes Dekodierungstaktes wird der lineare Dekodierungs PC 424 auf eine direkt abbildende Art verwendet, um den BTB 456 zu adressieren. Falls ein Treffer in einem BTB Eintrag geschieht, was vor dem Ende des Dekodierungstaktes realisiert wird, wird ein auf den PC bezogener bedingter Transfersteuerbefehl von einem Kurz Dekodieren dekodiert und der Steuertransfer wird als genommen vorher gesagt, dann geschehen zwei Aktionen. Erstens wird die an den Befehls-Cachespeicher 214 gerichtete lineare Holadresse für das anfängliche Ziel von der aktuellen Zieladresse auf einen Wert geändert, der auf ein Befehlsbyte zeigt, das den in dem BTB Eintrag enthaltenen gültigen Zielbytes unmittelbar folgt. Diese veränderte Holadresse ist in dem BTB Eintrag enthalten und auf sie wird direkt von dem BTB Eintrag zugegriffen. Zweitens wird das Befehlsbyte und Vordekodierungsinformation aus dem Eintrag an dem Ende des Dekodierungstaktes in den Befehlspuffer 408 geladen. Falls ein auf den PC bezogener bedingter Transfersteuerbefehl von einem Kurz Dekodieren dekodiert wird und der Steuertransfer als genommen vorher gesagt ist, aber ein Fehltreffer auftritt, wird dann ein neuer BTB Eintrag mit den Ergebnissen des Holens des Zielbefehls erzeugt. Insbesondere wird, zugleich mit dem ersten erfolgreichen Laden von Bytes des Zielbefehls aus dem Befehls-Cachespeicher 214 in den Befehlspuffer 408, die gleiche Information in einen ausgewählten BTB Eintrag geladen, wodurch die vorherigen Inhalte ersetzt werden. Das Holen des Ziels und das Laden des Befehlspuffers 408 verlaufen anderenfalls normal.
  • Jeder Eintrag enthält einen Markierungsteil und einen Datenteil. Der Datenteil hält sechzehn erweiterte Befehlsbytes einschließlich eines Speicherbytes und drei dazu gehörige Vordekodierungsbits. Die Entsprechung des Speicherbytes ist speicherausgerichtet mit der entsprechenden Stelle des Befehlspuffers 408. Der Markierungsteil eines BTB Eintrags hält eine 30 Bit Markierung einschließlich des 32 Bit lineare Dekodierungs PC 424, der zu dem Transfersteuerbefehl mit einem zwischen gespeicherten Ziel gehört, niedrigen Bits [4 : 1], einem Eintrag Gültig Bit und der 30 Bit linearen Befehlsholadresse für das anfängliche Ziel. Keine expliziten Befehlswort Gültig Bits werden verwendet, weil der Abstand zwischen der wahren Zieladresse und der geänderten Zieladresse direkt die Nummer und Bezeichnung der gültigen Befehlsworte in der BTB 456 impliziert.
  • Der Zweck der BTB 456 ist es, Verzweigungsziele in kleinen bis mittleren Schleifen für den Zeitraum, in dem eine Schleife und verschachtelte Schleifen aktiv ausgeführt werden, zu erfassen. In Übereinstimmung mit diesem Zweck wird bei der Detektierung einer geringsten Möglichkeit einer Inkonsistenz der gesamte BTB ungültig gemacht und entleert. Der BTB 456 wird ungültig gemacht und entleert auf einen Fehltreffer in dem Befehls-Cachespeicher 214, jeglicher Form von ungültig machen des Befehls-Cachespeichers 214, einem ITB Fehltreffer oder jeglicher Form vom ungültig machen des ITB. Verzweigungsziele außerhalb temporärer oder seitlicher Stellen werden nicht effektiv zwischen gespeichert. Typischerweise enthält der BTB 456 nur eine kleine Anzahl von Einträgen, so dass die Komplexität reduziert wird, während der größte Teil der Verbesserung der Leistungsfähigkeit durch ein ideales Zwischenspeichern des Verzweigungsziels erreicht wird.
  • Eine auf den PC bezogene Adressberechnungslogik für das Verzweigungsziel führt die Berechnung für die Zieladresse durch. Die Adressberechnungslogik für das Verzweigungsziel wird nur für auf den PC bezogene Transfersteuerbefehle verwendet, die von einem Kurz Dekodieren SDec0 410, SDec1 414 oder SDec2 416 dekodiert werden. Insbesondere wird die Adressberechnungslogik für das Verzweigungsziel für die Kurz Dekodier Verzweigungsbefehle einschließlich Jcc disp8, LOOP disp8, JMP disp8, JMP displ6/32 und CALL displ6/32 verwendet. Jeder Kurz Dekodieren SDec0 410, SDec1 412 und SDec2 414 enthält eine logische und lineare Adressberechnungslogik für das Verzweigungsziel (nicht gezeigt). Alle drei Sätze der logischen und linearen Adressberechnungslogik für das Verzweigungsziel arbeiten parallel, während die Kurz Dekodierer 410, 412 und 414 feststellen, ob irgendeine der Operationen ein auf den PC bezogener Kurz Dekodier Verzweigungsbefehl ist. Die logische und lineare Adressberechnungslogik für das Verzweigungsziel summiert den logischen Programmzähler der Verzweigung, die Länge des Verzweigungsbefehls und die um das Vorzeichen erweiterte Verschiebung des Verzweigungsbefehls auf und maskiert bedingt die obersten 16 Bits der Summe, abhängig von der Größe der Berechnung, um eine logische Zieladresse zu erzeugen. Die logische und lineare Adressberechnungslogik für das Verzweigungsziel addiert die logische Zieladresse zu der derzeitigen Basisadresse des Codesegments, um eine lineare Zieladresse zu erzeugen. Falls die Verzweigung genommen wird, entweder ohne Bedingung oder vorher gesagt genommen, dann werden die berechneten Adressen, die dem dekodierten Kurz Dekodier Verzweigungsbefehl entsprechen, verwendet, um den logische Dekodierungs PC 422 und den lineare Dekodierungs PC 424 erneut zu initialisieren. Falls die Verzweigung als nicht genommen vorher gesagt wird, wird die logische Adresse mit dem dazu gehörigen Kurz Dekodier Verzweigungsbefehl (BRCOND Op) in einem Op Quad Eintrag des Ablaufplaners 260 gespeichert. Die logische Zieladresse wird mit dem derzeitigen Grenzwert für das Codesegment verglichen, um eine Grenzverletzung zu überwachen.
  • Falls die logische und lineare Adressberechnungslogik für das Verzweigungsziel eine Grenzverletzung detektiert, ob die Verzweigung nun als genommen vorher gesagt oder nicht genommen vorher gesagt ist, wird dann ein spezielles Markierungsbit, das eine Grenzverletzung anzeigt, in dem Op Quad Eintrag des Ablaufplaners 260 gesetzt, der die von dem Verzweigungsbefehl erzeugten Operationen hält. Nachfolgend, wenn die Operationsübergabeeinheit (OCU) 970 oder der Ablaufplaner 260 versucht, diesen Op Quad zu übergeben, wird der Op Quad behandelt als enthält er einen Fehler und wird abgebrochen. Der Makrobefehlsdekodierer 230 erzeugt Signale, die einen Einsprung zu einem Fehlerbehandler in dem Emulationscode ROM 232 einleiten. Der Fehlerbehandler verhindert zeitweise die Dekodierung durch die Kurz und Lang Dekodieren und springt zu der fehlerhaften PC Adresse des verletzenden Befehls, der zu dem fehlerhaften Op Quad gehört. Schließlich wird der Verzweigungsbefehl erneut dekodiert und zu dem Befehlsemulationscode vektorisiert. Der Emulationscode erkennt die Grenzverletzung, wenn die Verzweigung tatsächlich genommen ist und behandelt die Verletzung entsprechend.
  • Der Prozessor 120 antwortet im Allgemeinen auf eine Fehlerbedingung durch das Einspringen zu einem bestimmten Fehlerbehandler in dem Emulationscode ROM 232. Der Fehlerbehandler umfasst innerhalb des RISC86 Befehlssatzes definierte Operationen, welche eine Routine ausführen, welche die Quelle des Fehlers, eine geeignete Antwort auf den Fehler und Schritte zur Einleitung einer geeigneten Antwort bestimmt. Als eine Alternative in geeigneten Fällen enthält der Prozessor 120 auch einen Befehl, der "lade Ersatz Fehlerbehandler" Befehl genannt wird, welcher eine spezielle Antwort auf den Fehler einleitet. Der Befehl zum Laden eines Ersatz Fehlerbehandlers passiert durch die Pipeline des Befehlsdekodierers 220 in der Art aller Befehle, aber veranlasst jegliche nachfolgende Ausnahmebedingung, einen anderen Eintrittspunkt in dem vektorisierenden Befehls ROM aufzurufen. Der Ersatz Fehlerbehandler beendet bei der Beendigung der Ausführung des derzeitigen Makrobefehls. Der Ersatz Fehlerbehandler sollte vorteilhafterweise die spezielle Behandlung von Fehlern nur für den Fall eines Fehlers erlauben und damit spezielle Einrichtungsarbeit vermeiden, wenn der Fehler auftritt.
  • Ein Beispiel des Vorteils des Ersatz Fehlerbehandlers tritt auf im Hinblick auf einen Befehl zum wiederholten Bewegen einer Zeichenkette (REP MOVs). Um mehrere Interaktionen sehr schnell auszuführen, ist eine Fähigkeit zum Umordnen der Reihenfolge von Operationen wichtig. Die Reihenfolge von Operationen umfasst üblicherweise einen Ladevorgang zu einer ersten durch einen Zeiger angegebenen Adresse, einen Speichervorgang zu einer zweiten von einem Zeiger angegebenen Adresse und, falls sowohl der Ladevorgang und der Speichervorgang erfolgreich sind, eine Erhöhung des ersten und zweiten Zeigers und eine Verringerung eines Zählers. Für zusätzliche Effizienz werden die Zeiger hoch gezählt und der Zähler runter gezählt, bevor die Speicheroperation beendet. Wenn jedoch ein Fehler oder eine Ausnahme auftritt während der Sequenz der Operationen, wird die Sequenz abgebrochen, wobei die Zähler und Zeiger in dem falschen Zustand sind. Zum Beispiel haben die architekturalen x86 SI, DI und CX Register keinen korrekten Wert. Der Ersatz Fehlerbehandler wird verwendet zum Angeben, vor dieser Sequenz, eines Ersatz Fehlerbehandlers, der nach einem wiederholten Move Fehler aufräumt. Die Sequenz fährt fort ohne die Belastung durch zwischenzeitige Befehle zum Verfolgen der Zeiger und Zähler. Falls kein Fehler auftritt, schließt der Ersatz Fehlerbehandler ohne Auswirkung ab. Falls jedoch ein Fehler auftritt, wird der Ersatz Fehlerbehandler aufgerufen. Dieser Ersatz Fehlerbehandler ist spezifisch für die bestimmte Sequenz von Operationen und führt entsprechend Aufräumarbeiten aus und springt zu dem Vorgabe Fehlerbehandler. Vorteilhafterweise verbessert höchst effizienter Code die Leistungsfähigkeit der Geschwindigkeit ohne ein Hindernis von dem Ersatz Fehlerbehandler bis ein Fehler auftritt, zu welchem Zeitpunkt der Fehler adressiert wird.
  • Die Verzweigungsverlaufstabelle (BHT) speichert jüngste Verlaufsinformation, insbesondere Information über die Richtung der Verzweigung, über bedingte Transfersteuerbefehle, die in der Vergangenheit angetroffen worden sind. Wenn eine Verzweigung wiederholt wird, wird die auf diese Verzwei gung bezogene gespeicherte Information analysiert, um die derzeitige Richtung der Verzweigung vorherzusagen. Nachfolgend wird die gespeicherte Information aktualisiert basierend auf der tatsächlichen Richtung, welche die Verzweigung genommen hat. Die gespeicherte Information wird abgeleitet von der Richtung einer bestimmten neu angetroffenen Verzweigung, des jüngsten Verlaufs der Richtung der bestimmten Verzweigung und des jüngsten Verlaufs der Richtung von anderen Verzweigungen. Die gespeicherte Information ist basiert auf einer Vielzahl von Sätzen von 2 Bit Zustandsmaschinen und auch auf einem Verlauf der Richtung der letzten neun Verzweigungsausführungen, ob die letzten neun Verzweigungsausführungen die bestimmte Verzweigung oder andere Verzweigungen betreffen. Die Adresse des Befehls der bestimmten neu angetroffenen Verzweigung wird verwendet, um einen aus der Vielzahl der Sätze von 2 Bit Zustandsmaschinen auszuwählen. Der Verlauf der Richtung der letzten neun Verzweigungsbefehle wird verwendet, um eine bestimmte 2 Bit Zustandmaschine in dem ausgewählten Satz von Zustandsmaschinen auszuwählen. Jede Zustandsmaschine ist ein 2 Bit saturierender Zähler zum Zählen der Richtungen, die von den meisten jüngsten Verzweigung genommen wurden, welche auf diese bestimmte Zustandsmaschine zugegriffen haben. Typischerweise wird auf eine bestimmte Zustandsmaschine von der gleichen statischen Verzweigung zugegriffen, obwohl andere Verzweigungen auf die gleiche Zustandsmaschine zugreifen können. Ein größerer Wert der Zustandsmaschine ist ein Hinweis auf mehr genommene Instanzen einer Verzweigung. Ein kleinerer Wert der Zustandsmaschine ist ein Hinweis auf mehr nicht genommene Instanzen einer Verzweigung. Nach der Auswahl einer Zustandsmaschine wird auf die Zustandsmaschine zugegriffen. Falls die vorhandene Gesamtzählung "größer" ist, dann ist die Verzweigung als genommen vorher gesagt. Falls die vorhandene Gesamtzählung "kleiner" ist, dann ist die Verzweigung als nicht genommen vorher gesagt. Der Verlauf der Richtung der letzten jüngsten neun Verzweigungsausführungen wird in einem neun Bit Schieberegister gehalten, das jedes Mal getaktet oder geschoben wird, wenn ein Verzweigungsbefehl erfolgreich dekodiert wird. Die unmittelbare, gerade vorher gesagte Richtung der Verzweigung ist der neue Wert für den Verlauf der Richtung, der in das Schieberegister geschoben wird. Ein Wert des Verlaufsbit von Eins ist ein Hinweis auf eine genommene Verzweigung. Ein Wert des Verlaufsbit von Null ist ein Hinweis auf eine nicht genommene Verzweigung.
  • Während eines Dekodierungstaktes wird der lineare Dekodierungs PC 424 verwendet, um ein Nachschlagen in der BHT Tabelle durchzuführen. Falls ein auf einen PC bezogener Verzweigungsbefehl dekodiert wird, sagt dann die Zustandsmaschine, auf die zugegriffen wurde, unmittelbar die Richtung der Verzweigung voraus, obwohl der tatsächliche Befehl, der nachfolgend geholt und dekodiert wird, an dem Ende des Dekodierungstaktes von dem Makrobefehlsdekodierer 230 bestimmt wird. Nachfolgend wird die Verzweigungsbedingungs (BRCOND) Operation, die durch das Dekodieren des bedingten Verzweigungsbefehls erzeugt wurde, durch eine Logik in dem Ablaufplaner 260 aufgelöst, zu welchem Zeitpunkt die Zustandsmaschine aktualisiert wird. Falls die Verzweigung tatsächlich genommen wird, wird die Zustandsmaschine runter gezählt, es sei denn sie ist bereits an dem maximalen Wert (3). Falls die Verzweigung tatsächlich nicht genommen wird, wird die Zustandsmaschine hoch gezählt, es sei denn sie ist bereits an dem minimalen Wert (0). Entsprechend zeigen Werte der Zustandsmaschine von 0 beziehungsweise 1 eine starke und eine schwache Vorhersage einer nicht genommenen Verzweigung an. Ein Wert der Zustandsmaschine von 2 beziehungsweise 3 zeigt eine starke und eine schwache Vorhersage einer genommenen Verzweigung an. Um die Aktualisierung der Einträge in der BHT zu unterstützen, werden eine Kopie der Bits für die Verzweigungsadresse und für den Verlauf der Richtung zum Zugreifen auf die BHT und eine Kopie der Werte der Zustandsmaschine zusammen mit der Verzweigungsbedingungs (BRCOND) Operation an den Ablaufplaner 260 weiter geleitet. Da ein Maximum von einer BRCOND in einem Op Quad enthalten ist, wird die BHT Unterstützungsinformation an den Op Quad angehangen, welcher dem Ablaufplaner 260 zugeführt wird. Es ist vorteilhaft für die Reduzierung der Größe und Komplexität der Schaltung, dass die BHT keine Eintragsmarkierungen (Adressen von lineare Dekodierungs PC 424, die zu dekodierten bedingten Verzweigungen gehören) enthält, die in Strukturen von Cachespeichern typisch sind. Es ist des weiteren vorteilhaft, dass die BHT eine große Anzahl von Einträgen hat, so dass die Rate der Konkurrenz niedrig ist.
  • Die in einem Op Quad des Ablaufplaners 260 gespeicherte Information hat zusammen mit einer dazu gehörigen BRCOND Operation eine Breite von fünfzehn Bits einschließlich vier Verzweigungsadressbits, neun aktuelle Verlaufsbits und die unmittelbar angesprochenen zwei Zustandsmaschinenbits, von denen das obere Bit auch die vorher gesagte Richtung für die unmittelbare Verzweigung ist. Die ersten fünfzehn Bits werden wenn notwendig verwendet, um erneut auf die BHT zuzugreifen und den Wert der Zustandsmaschine zu aktualisieren. Die letzten beiden Bits werden geändert, um den neuen Wert der Zustandsmaschine zu erzeugen.
  • Wenn eine Verzweigung falsch vorher gesagt wurde, wird der Satz von Verlaufswerten in dem neun Bit Schieberegister für den Verlauf der Verzweigung korrigiert, um die tatsächlich genommene Richtung der Verzweigung zu berücksichtigen. Des weiteren wird das Schieberegister "zurück geschoben", um der falsch vorher gesagten Verzweigung zu entsprechen, dann basierend auf der tatsächlichen Richtung der Verzweigung und darauf, welche Richtung der Verzweigung vorher gesagt wurde, aktualisiert.
  • Ein Rückkehradressenstapel (RAS) (nicht gezeigt) ist ein Cachespeicher für Zieladressen für Rückkehr (RET) Transfersteuerbefehle. Der RAS hat ein RAM mit acht Einträgen, 32 Bit Breite, einem Anschluss, das als ein Ringpuffer betrieben wird unter Verwendung eines einzelnen 3 Bit Zeigers. Während jedes Taktes wird höchstens ein Zugriff, entweder ein Lesezugriff für eine RET Dekodierung oder ein Schreibzugriff für eine CALL Dekodierung, durchgeführt. Der RAS speichert RET Rückkehradressen zwischen und sagt Rückkehradressen voraus, die inhärent eine Zieladresse indirekt angeben, im Gegensatz zu anderen Transfersteuerbefehlen, die eine direkte Angabe der Zieladresse enthalten. Der RAS wird vorteilhafterweise verwendet, da ein bestimmter RET Befehl oftmals seine Zieladresse zwischen verschiedenen Ausführungen eines Befehls wechselt. Der RAS entdeckt und sieht den Wert für die Zieladresse für jede Ausführung eines RET Befehls voraus durch die Überwachung der Rückkehradressen, die von CALL Befehlen gespeichert – auf einen Stapel geschoben – werden. Entsprechende CALL und RET Befehle treten üblicherweise in Paaren dynamisch und in zuletzt rein zuerst raus LIFO Ordnung auf im Hinblick auf andere Paare von CALL und RET Befehlen.
  • Jedes Mal wenn ein CALL Befehl erfolgreich dekodiert wird, wird die logische Rückkehradresse des CALL Befehls in einem Ringpuffer gespeichert (geschoben), der wie ein LIFO Stapel verwaltet wird. Jedes Mal wenn ein RET Befehl erfolgreich dekodiert wird, wird der Wert der Rückkehradresse, der zur Zeit an der Spitze des RAS ist, als die vorher gesagte Zieladresse für die RET verwendet und der Wert wird aus dem RAS ausgeworfen. Der RAS erreicht eine hohe Vorhersagerate obwohl Fehlvorhersagen auftreten, weil CALLs und RETs nicht immer in verschachtelten Paaren auftreten, nur nahe CALLs und RETs und keine entfernten CALLs und RETs unterstützt werden und Fehlvorhersagen auftreten wegen der begrenzten Tiefe des RAS. Wenn eine Fehlvorhersage einer bedingten Verzweigung auftritt, versucht der RAS den Zustand vor der Fehlvorhersage wiederherzustellen, indem die Spitze des Stapelzeigers auf die vorherige Bedingung gesetzt wird, weil CALL und RET Befehle spekulativ dekodiert und der Zeiger der Spitze des Stapels dabei geändert worden sein könnten. Der originale Zeiger, vor der Fehlvorhersage, muss wiederhergestellt werden. Die auf eine Fehlvorhersage folgende Wiederherstellung wird von dem Ablaufplaner 260 unterstützt. Jeder Op Quad in dem Ablaufplaner 260 wird mit einem derzeitigen Wert für den ursprünglichen Zeiger der Spitze des Stapels markiert, der während des Dekodierungstaktes wirksam ist, in dem der Op Quad erzeugt wurde. wenn die für einen bedingten Verzweigungsbefehl erzeugte BRCOND Op aufgelöst ist und als falsch vorher gesagt gefunden wurde, wird der an den Op Quad des Ablaufplaners geheftete Zeiger der Spitze des Stapels während eines Neustarttaktes, der von dem Ablaufplaner 260 erzeugt wird, dem RAS zur Verfügung gestellt. Der RAS ersetzt den derzeitigen Wert der Spitze des Stapels mit der Markierung für den Zeiger der Spitze des Stapels aus dem Op Quad des Ablaufplaners.
  • Bezugnehmend auf 5 stellt ein schematisches Blockdiagramm eine Emulationsschaltung für den Befehlsdekodierer 231 dar, enthaltend ein Be fehlsregister 512, eine Eintrittspunktschaltung 514, einen Emulationscodesequenzer 510, einen Emulationscodespeicher 520 und eine Op Ersetzungsschaltung 522. Die Emulationsschaltung für den Befehlsdekodierer 500 ist eine Schaltung in dem Befehlsdekodierer 220. Die Emulationsschaltung für den Befehlsdekodierer 231 empfängt Befehlsbytes und dazu gehörige Vordekodierungsinformation von dem Befehlspuffer 408, der mit der Befehl Hol Steuerschaltung 218, dem BTB 456 oder dem Befehls-Cachespeicher 214 verbunden ist. Der Befehlspuffer 408 ist an das Befehlsregister 512 angeschlossen und beliefert es mit x86 Befehlen. Das Befehlsregister 512 ist mit der Eintrittspunktschaltung 514 verbunden, um die Eintrittspunkte des Emulationscode ROM zu versorgen. Die Eintrittspunktschaltung 514 empfängt die x86 Befehle und erzeugt aus dem Operationscode (Opcode) der x86 Befehle eine Adresse des Eintrittpunktes, die eine in den Emulationscodespeicher 520 zeigende Startadresse ist. Auf diese Weise wird eine Adresse eines Befehls in dem Emulationscodespeicher 520 aus dem Opcode eines x86 Befehls geschaffen. Die Adresse wird abgeleitet auf Basis des x86 Befehlsbytes, insbesondere des ersten und zweiten Bytes des x86 Befehls, wie auch Information, wie das modern Byte, Präfixe REP und REPE, das Protected Mode Bit und das Bit DSz für die effektive Datengröße. Im Allgemeinen haben eng verwandte x86 Befehle ähnlich kodierte Bitfelder, zum Beispiel ist ein Bitfeld, das einen Befehlstyp anzeigt, das gleiche unter verwandten x86 Befehlen, so dass ein einzelner Eintrag in dem Emulationscodespeicher 520 mehreren x86 Befehlen entspricht. Eintrittspunkte werden generell geschaffen durch Lesen der x86 Befehle und Zuweisen von Bits der Adresse des Eintrittspunktes in Übereinstimmung mit den Werten der bestimmten Bitfelder des x86 Befehls. Das Befehlsregister 512 ist mit dem Emulationscodesequenzer 510 verbunden, der wiederum mit dem Emulationscodespeicher 520 verbunden ist. Der Emulationscodesequenzer 510 legt den Eintrittspunkt an den Emulationscodespeicher 520 an und empfängt Sequenzinformation von dem Emulationscodespeicher 520. Der Emulationscodesequenzer 510 steuert entweder das Sequenzen von Befehlen oder legt, wenn ein neuer Sequenz Taktzyklus zu starten ist, einen neuen Eintrittspunkt an den Emulationscodespeicher 520 an. In dem Emulationscodespeicher 520 kodierte Operationen (Ops) werden von dem Emulationscodespeicher 520 als Op Quads oder Op Einheiten an die Op als Op Quads oder Op Einheiten an die Op Ersetzungsschaltung ausgegeben. Die Ops entsprechen einer Vorlage für x86 Operationen vom RISC Typ. Diese Vorlage umfasst eine Vielzahl von Feldern, in welche Codes wahlweise eingesetzt werden. Der Emulationscodespeicher 520 ist mit der Op Ersetzungsschaltung 522 verbunden, um Ops zur Verfügung zu stellen, in denen die verschiedenen Op Felder wahlweise ersetzt werden. Funktional betrachtet, 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 eines Befehls.
  • Der Emulationscodespeicher 520 enthält ein auf dem Chip befindliches Emulationscode ROM 232 und ein externes Emulationscode RAM 236. Der Emulationscodespeicher 520 enthält kodierte Operationen, welche leiten, wie der Prozessor 120 funktioniert, und definiert, wie x86 Befehle ausgeführt werden. Sowohl das Emulationscode ROM 232 wie auch das Emulationscode RAM 236 umfassen eine Vielzahl von Kodierungen für Operations (Op) Befehle, mit einem Op Kodierformat, das das gleiche ist wie in dem ROM 232 und dem RAM 236. Zum Beispiel hat in einem Ausführungsbeispiel das Emulationscode ROM 232 eine Kapazität von 4 K Worten mit 64 Bit. Das Op Kodierungsformat ist üblicherweise in Format, das zum Beispiel in 30 bis 40 Bits definiert ist. In einem Ausführungsbeispiel ist ein 38 Bit Format, gezeigt in den 6A bis 6E, definiert. Die Stelle der Basisadresse des Emulationscode ROM 232 in dem Emulationsraum ist fest. Das Emulationscode RAM 236 ist fest in dem üblichen Speicheradressraum in zwischenspeicherbarem Speicher ansässig. Die Stelle der Basisadresse des Emulationscode RAM 236 in dem Emulationsraum ist fest. Die 32 Bit Adresse des Emulationscode RAM 236 wird gebildet aus der festen Basisadresse des Emulationscode RAM 236, welche die höchstwertigen fünfzehn Bits <31 : 17> zur Verfügung stellt, und der Op Adresse, welche vierzehn Bits <16 : 3> zur Verfügung stellt, welche mit den Bits der Basisadresse verknüpft werden. Die beiden niedrigstwertigen Bits <1 : 0> der Adresse des Emulationscode RAM werden auf Null gesetzt. Die Op Adresse mit vierzehn Bit in dem Emulationscode RAM 236 ist die gleiche wie die Op Adresse in dem Emulationscode ROM 232. Operationen (Ops) werden im Op Kodierformat gespeichert, zum Bei spiel 38 Bit, in dem externen Emulationscode RAM 236 in Worten von 64 Bit. Über die Bits der 64 Bit Worte des Op Kodierformats hinausgehende Bits werden verwendet, um Speichersteuertransfer (OpSeq) Information zu speichern. Das externe Emulationscode RAM 236 wird üblicherweise für Zwecke des Testens und Debuggens verwendet, was das Nachbessern von jeglichen in dem Emulationscode ROM 232 kodierten Befehlen erlaubt, und zum Implementieren von speziellen Funktionen, wie einem Systemverwaltungsmodus (SMM). Zum Beispiel wird, wenn ein Befehl in dem Emulationscode ROM 232 als nicht korrekt funktionierend aufgefunden wird, auf das externe Emulationscode RAM 236 zugegriffen, um den nicht korrekt funktionierenden festen Code in dem Emulationscode ROM 232 temporär oder permanent zu ersetzen. Der Zugriff auf das externe Emulationscode RAM 236 wird typischerweise gewonnen durch Verwendung von einer von zwei Techniken. Bei einer ersten Technik bezeichnet ein Bit Feld in einem OpSeq Feld von einem Element des Emulationscodespeichers 520, dass die nächste Adresse zum Holen von Befehlen sich in dem externen Emulationscode RAM 236 befindet. Bei dieser ersten Technik leitet das auf dem Chip befindliche Emulationscode ROM 232 die Ausführung des externen Emulationscode RAM 236 ein. Bei einer zweiten Technik wird einfach eine Einsprungadresse zum Einspringen an einen Eintrittspunkt in dem Emulationscode RAM 236 zur Verfügung gestellt.
  • Der Befehls-Cachespeicher 214, die Befehl Hol Steuerschaltung 218 und der Befehlsdekodierer 220 arbeiten in drei Modi zum Holen und Dekodieren von Befehlen. In einem ersten Modus holt der Befehlsdekodierer 220 Emulationscode Op Quads aus dem auf dem Chip befindlichen Emulationscode ROM 232. Jeder Op Quad enthält vier Operationen (Ops) sowie Steuertransferinformation (OpSeq) zum Bestimmen des nächsten Taktes von Hol- und Dekodierfunktion. In einem zweiten Modus steuert die Befehl Hol Steuerschaltung 218 das Holen von Bytes der x86 Makrobefehle aus dem Befehls-Cachespeicher 214, der Teil des auf dem Chip befindlichen Befehls-Cachespeichers 214 ist. Die x86 Makrobefehle sind von dem Makrobefehlsdekodierer 230 dekodiert, der vier Operationen (Ops) erzeugt. Vier Ops plus das OpSeq Feld bilden einen vollständigen Op Quad. Der Befehlsdekodierer 220 führt jegliche kodierte Steuertransfers unter Verwendung der Verzweigungseinheit 234 und der Einsprungfunktionalität des Makrobefehlsdekodierers 230 durch. In einem dritten Modus steuert die Befehl Hol Steuerschaltung 218 das Holen von Worten mit 64 Bit, welche Emulationscode in dem Op Kodierformat enthalten, aus dem Befehls-Cachespeicher 214, mit einem 64 Bit Wort pro Takt. Jedes 64 Bit Wort entspricht einer einzelnen Operation (Op). In weiteren Ausführungsbeispielen kann pro Takt auf eine Vielzahl von 64 Bit Worten zugegriffen werden. In einem Ausführungsbeispiel, in dem auf vier 64 Bit Worte zugegriffen wird, stellt das Emulationscode RAM 236 einen vollständigen Op Quad in der Art des auf dem Chip befindlichen Emulationscode ROM 232 zur Verfügung, so dass ein vollständig neu programmierbarer Prozessor mit voller Effizienz erzielt wird. Ein vollständig neu programmierbarer Prozessor erlaubt vorteilhafterweise eine weiche Implementierung von sich stark unterscheidenden Prozessoren, zum Beispiel einem x86 Prozessor und einem PowerPCTM in einer einzigen Hardware.
  • In dem ersten und dritten der drei Betriebsmodi wird die Steuertransferinformation in ein Operationssequenz (OpSeq) Feld des Op Quads formatiert. Nicht bedingte Steuertransfers, wie Verzweigungs- (BR) und Rückkehr von der Emulation (ERET) Operationen, werden vollständig unter Verwendung der OpSeq Steuertransferinformation gesteuert. Bedingte Transfers, wie eine Verzweigung auf einer Bedingung (BRcc), werden unter Verwendung einer Kombination des OpSeq Felds und einer Verzweigungsbedingungs(BRCOND) Operation gesteuert. Eine Darstellung von dem Format eines OpSeq Felds ist in 7 gezeigt. Das 16 Bit OpSeq Feld 700 enthält ein sequentialisierende Aktion (ACT) Feld 710 mit zwei Bit, ein externes Emcode Feld 712 mit einem einzelnen Bit und ein Operations (Op) Adressfeld 714 mit 13 Bit. Vier sequentialisierende Aktionen sind in dem ACT Feld wie folgt kodiert:
  • Figure 00560001
  • Figure 00570001
  • Ob eine sequentialisierende Aktion einer OpSeq nicht bedingt oder bedingt ist, hängt von dem Vorhandensein beziehungsweise der Abwesenheit einer Verzweigungsbedingung (BRCOND) Op irgendwo anders in dem Op Quad ab. Die BRCOND Op in dem Op Quad gibt die zu testende Bedingung und die Ersatzzieladresse des Emulationscodes an. Kein explizites Bit für die Vorhersage der statischen Verzweigungsrichtung existiert. Stattdessen werden die vorher gesagte Aktion und die nächste Adresse immer von dem OpSeq Feld 700 angegeben und die "nicht vorher gesagte" nächste Adresse wird immer von der BRCOND Op angegeben. Eine BRCOND Op ist immer mit einer BSR Sequenzaktion einschließlich nicht bedingter Calls gepaart. Für nicht bedingte und bedingte "genommen vorher gesagte" Calls, gibt die BRCOND Op die zu speichernde Rückkehradresse an.
  • Das externe Emcode Feld 712 wird auf Eins gesetzt, wenn auszuführender Emulationscode sich in dem externen Emulationscode RAM 236 befindet. Das externe Emcode Feld 712 wird auf Null gesetzt, wenn auszuführender Emulationscode sich in dem internen Emulationscode ROM 232 befindet. Das Op Adress Feld 714 bezeichnet eine Adresse einer Ziel Op in einem Op Quad, der sich nicht en einem Eintrittspunkt befindet.
  • Die OpSeq Steuertransferinformation steuert die nicht bedingten Steuertransfers, wenn ein Op Quad oder ein 64 Bit Speicherwort geholt und geordnet wird oder "sofort dekodiert". Die Zuweisung des nächsten Befehls, dekodiert zu werden, wird von dem OpSeq Feld allein gesteuert. Das OpSeq Feld gibt eine von drei alternativen Aktionen an. Erstens leitet das OpSeq Feld das Holen von Emulationscode aus dem Emulationscode ROM 232 bei einer angegebenen 14 Bit Adresse eines einzelnen Operationswortes, so dass ein Emulationscode ROM 232 Op Quad geholt wird. Zweitens leitet das OpSeq Feld das Holen von Emulationscode aus dem Emulationscode RAM 236 bei einer angegebenen 14 Bit Adresse eines einzelnen Operationswor tes, so dass ein Emulationscode RAM 236 64 Bit Speicherwort geholt wird. Drittens enthält das OpSeq Feld eine Anweisung zu der Rückkehr von der Emulation (ERET), welche den Makrobefehlsdekodierer 230 anleitet, zu der Dekodierung von x86 Makrobefehlen zurückzukehren.
  • Von dem Emulationscode ROM 232 geholter Emulationscode wird in der Form von ausgerichteten Op Quads geholt. Eine Verzweigung zu einer in der Mitte liegenden Stelle in dem Op Quad veranlasst die voran gehenden Operationen in dem Op Quad als ungültig behandelt zu werden, indem NOOPs an Stelle der voran gehenden Operationen geholt werden.
  • Die Speicheradressen der Bytes zum Holen von 64 Bit Speicherworten aus dem Emulationscode RAM 236 werden erzeugt durch die Verkettung einer angegebenen 14 Bit Operationsadresse mit drei niedrigstwertigen Bits, die auf Null gesetzt sind, wodurch eine ausgerichtete 8 Bit Adresse erzeugt wird. Die Speicheradressen der Bytes zum Holen von 64 Bit Speicherworten sind 8 Bit ausgerichtet, wodurch die Dekodierung der Speicher Op und der Fortschritt beim Holen/Dekodieren konsistent und einfach gemacht werden.
  • Die OpSeq Steuertransferinformation steuert auch die Zuweisung des unmittelbar nächsten Befehls, der dekodiert werden soll, für bedingte Speichertransfers. Die Verzweigungsbedingungs (BRCOND) Operation gibt den Bedingungscode an, der zu testen und zu bewerten ist, und gibt einen alternativen 14 Bit Emulationscode Adresse zum Holen und Dekodieren an. Daher gibt die OpSeq Steuertransferinformation für bedingte Speichertransfers den vorher gesagten Pfad der bedingten Verzweigung effektiv an. Die BRCOND Adresse ist typischerweise die 14 Bit Op Wort Adresse des Ziels oder die 14 Bit Op Wort Adresse der nächsten "sequentiellen" Operation (Op). Allgemeiner ausgedrückt kann eine BRCOND Adresse eine vollständige allgemeine bedingte Verzweigung mit zwei Wegen angeben. Eine bedingte ERET Operation wird implementiert durch Setzen des OpSeq Feldes, um eine ERET Operation anzugeben, so dass die bedingte ERET als genommen vorher gesagt ist. Falls die ERET Operation nachfolgend als falsch vorher gesagt befunden wird, wird dann der von der ERET geleitete Strom an x86 Makrobefehlen abgebrochen und der von der BRCOND angegebene sequentielle Strom an Makrobefehlen wird erneut gestartet.
  • BRCOND Operationen werden in nicht ausgegebenem Zustand in den Ablaufplaner 260 geladen. Die BRCOND Operationen werden in Reihenfolge von der Verzweigungsauflösungseinheit des Ablaufplaners 260 bewertet. Falls die Verzweigung korrekt vorher gesagt ist, wird die Verzweigung als Abgeschlossen markiert. Anderenfalls wird die BRCOND nicht ausgegeben belassen und löst ein Signal zum Abbrechen der Verzweigung aus, wenn sie von der Op Übergabeeinheit detektiert wird.
  • Der Emulationscodespeicher 520 unterstützt eine Subroutinenfunktionalität mit einem Level (kein Testen), in der ein OpSeq Feld gesetzt ist, um Alternativen für das Holen von Emulationscode anzugeben. Die Alternativen sind wie eine typische bedingte Verzweigung mit zwei Wegen strukturiert, mit der Ausnahme, dass eine 14 Bit Op Wort Adresse von dem unmittelbaren Feld einer BRCOND Op in dem Op Quad oder der Speicher Op in ein Adressregister zur Rückkehr aus der Subroutine geladen wird. Das Adressregister zur Rückkehr aus der Subroutine speichert die 14 Bit Op Wort Adresse sowie ein einzelnes Bit, das zuweist, ob sich die Rückkehradresse in dem Emulationscode ROM 232 oder dem RAM 236 befindet. Der von der BRCOND Op angegebene Bedingungscode kann jegliche Alternative, einschließlich TRUE, sein, so dass sowohl nicht bedingte als auch bedingte (als genommen vorher gesagt) Subroutinen angegeben werden können. Jedoch muss die BRCOND Op angegeben werden, um das Laden eines nicht definierten Werts in das Adressregister zur Rückkehr aus der Subroutine zu verhindern.
  • Jegliche Unterstützung von Emulationscode Subroutinen und Verwaltung von Rückkehradressregistern wird von dem Emulationscodesequenzer 510 an dem Anfang der Pipeline durchgeführt. Damit ist das Laden und die Benutzung des Rückkehradressregisters vollständig synchron mit dem normalen Zeitablauf der Dekodieren, so dass keine Verzögerungen eingeführt werden.
  • Zwei Wege Emulationscode Verzweigung
  • Das Emulationscode ROM 232 ist ein Speicher für eine Vielzahl von Sequenzen von Operationen (Ops). Eine Operationssequenz beginnt an einem definierten Eintrittspunkt, der in dem Emulationscode ROM 232 hart kodiert ist, und erstreckt sich zu einer OpSeq Anweisung zu der Rückkehr aus der Emulation (ERET), welche die Operationssequenz beendet. Die Anzahl der Operationen in einer Sequenz ist üblicherweise variabel, wie es angebracht ist zum Durchführen zahlreicher verschiedener Funktionen. Einige einfache x86 Befehle haben lediglich einen einzigen Op Eintrag in dem Emulationscode ROM 232, obwohl diese Befehle mit der Auflösung eines Op Quads geholt werden. Andere, komplexere x86 Befehle verwenden viele Teiloperationen. Der Speicher in dem Emulationscode ROM 232 ist als eine Vielzahl von Op Quads strukturiert, die in einen festen ROM Adressraum programmiert sind. Jeder Op Quad umfasst vier RISC Op Felder und ein OpSeq Feld. Die Operationssequenzen sind typischerweise nicht innerhalb der Op Quads ausgerichtet, so dass, ohne irgendeine Technik zum Verzweigen zu zwischengelagerten Stellen in dem Emulationscode ROM 232, viele ROM Einheiten in dem Emulationscode ROM 232 nicht benutzbar sind, was wertvollen Raum in der integrierten Schaltung verschwendet. Des weiteren werden, weil die Adresse des Eintrittspunktes von einem Befehl in dem Emulationscode ROM 232 aus dem Opcode eines x86 Befehls erschaffen wird, die Adressen der Eintrittspunkte oftmals in feste Positionen gezwungen, die über den ganzen Adressraum des ROM mit dazwischenliegenden Lücken verteilt sind, was zu nicht benutzten Bereichen des ROM führt. ROM Positionen, die ohne einen Zugriff über einen Eintrittspunkt belassen werden, sind frei für andere Verwendungen, sind aber nicht günstig sequentiell, um einen Zugriff zu erlauben. Das OpSeq Feld stellt eine Technik zum Verzweigen zu diesen Stellen zur Verfügung, wodurch verschwendeter Platz erheblich eliminiert wird.
  • Jedes der vier RISC Op Felder eines Op Quads speichert eine einfache RISC ähnliche Operation. Das OpSeq Feld speichert einen Steuercode, der dem Emulationscodesequenzer 510 mitgeteilt wird, und steuert den Emulations codesequenzer 510, um zu einer nächsten Stelle in dem Emulationscode ROM 232 zu verzweigen. Jedes der vier RISC Op Felder in dem Emulationscode ROM 232 kann eine Verzweigungsoperation speichern, entweder bedingt oder nicht bedingt, und dadurch eine Zieladresse angeben, so dass eine Vielzahl von Verzweigungen in einem einzelnen Op Quad kodiert sein können. In einigen Ausführungsbeispielen der Emulationsschaltung für den Befehlsdekodierer 231 ist der Op Quad limitiert, höchstens eine einzelne Verzweigungsoperation zu haben, um zusammen mit dem OpSeq Feld die Op Reihenfolge zu leiten. Die Kombination von einer bedingten Verzweigungs Op in einem der vier RISC Op Felder und dem OpSeq Feld in einem Op Quad führt zu einem Op Quad mit zwei möglichen Ziel- oder nächsten Adressen.
  • Für einen Op Quad mit einer Vielzahl von Zieladressen leitet der Emulationscodesequenzer 510 die Sequenz von Operationen durch Auswählen einer hart kodierten vorher gesagten Zieladresse. Daher wählt der Emulationscodesequenzer 510, für einen Op Quad umfassend eine bedingte Verzweigung, vorzugsweise eine hart kodierte OpSeq Zieladresse gegenüber der bedingten Verzweigung aus. Die nicht bedingte Verzweigung wird nachfolgend in Übereinstimmung mit der Funktionalität für die Verzweigungsvorhersage des Prozessors 120 behandelt, so dass kein zusätzlicher Verwaltungsaufwand für die Behandlung der Verzweigung erlitten wird durch die Implementierung einer zwei Wege Emulationscodeverzweigung.
  • Ein Emulationsmikrocode kann geschrieben werden, so dass eine BRCON Op in einer der ersten drei Positionen in dem Op Quad positioniert wird. Daher werden die Ops, welche der BRCOND Op in dem Op Quad folgen, basierend auf der vorher gesagten Richtung ausgeführt statt darauf, ob die Verzweigung letztendlich genommen wird. Falls die Verzweigung schließlich als korrekt vorher gesagt befunden wird, werden alle der Ops in dem Op Quad und die Ops von nachfolgenden Op Quads an den Ablaufplaner 260 übergeben. Falls die Verzweigung schließlich als falsch vorher gesagt befunden wird, werden alle der der BRCOND Op folgenden Ops sowie alle nachfolgenden Op Quads abgebrochen. Der Emulationscode wird zur Verfügung gestellt, um die Bedingungen der Verzweigung, eine Zieladresse, eine "sequentielle" Adresse und auch die Vorhersage für die Verzweigungsbedingung zu integrieren.
  • Für die meisten Befehle stellt das OpSeq Feld allein die nächste Holadresse zur Verfügung, entweder eine Einsprungadresse oder eine ERST Rückkehr. Dies ist vorteilhaft zur Vereinfachung der Steuerhardware, zum Bereitstellen einer schnellen und einfachen Steuerlogik, welche das Holen von Operationen steuert ohne Analyse von bedingter Verzweigung oder der Vorhersage von Verzweigungen. Für bedingte Verzweigungsoperationen stellt das OpSeq Feld eine vorher gesagte Verzweigungsadresse zur Verfügung und eine BRCOND Operation in dem Quad gibt einen zu bewertenden Bedingungscode an und gibt die Ersatzholadresse für den Fall einer Fehlvorhersage an. Die Behandlung des Emulationscode erreicht vorteilhafterweise die Flexibilität des Holens von nicht sequentiellen Op Quads, indem die Steuersequenz für die Befehle mit wenig Beschränkungen von dem Programm ausgewählt wird. Entsprechend wird das OpSeq Feld vorteilhafterweise verwendet, um Op Sequenzen effektiv in nicht benutzte Stellen in dem Emulationscode ROM 232 einzupassen. Die Behandlung des Emulationscodes umfasst auch die Flexibilität einer optionalen zwei Wege Verzweigung, für den Fall von bedingten Verzweigungen und auch für den Fall eines Aufrufs einer Subroutine, der gelenkt werden könnte, um im wesentlichen zu jeder Stelle zurückzukehren, anstatt darauf beschränkt zu sein, zu dem dem aufrufenden Befehl folgenden Befehl zurückzukehren. Diese Verwendung des OpSeq Felds, zu einer Zieladresse zu verzweigen, erzielt nicht bedingtes Verzweigen ohne ein Erleiden einer Zeit- oder Taktstrafe.
  • Ersetzung der Emulationsumgebuna
  • Der Emulationscodesequenzer 510 steuert verschiedene Ersetzungen der Emulationsumgebung, um die Anzahl von kodierten Operationen erheblich über die Anzahl von Einträgen für Operationen in dem Emulationscode ROM 232 zu erweitern. Der Emulationscodesequenzer 510 enthält Logikschaltun gen, welche bestimmte, üblicherweise zugewiesene Kodierungen eines Op Feldes analysieren, um festzustellen, wann eine Ersetzung zu machen ist und welche Ersetzung ausgeführt wird. Die meisten Kodierungen geben direkt einen Feldwert an. Andere Kodierungen geben einen Feldwert indirekt über eine Ersetzung der Emulationsumgebung an. Die Verwendung der Ersetzung der Emulationsumgebung erzielt eine Kodierung von CISC Funktionalität, während die Größe des Emulationscode ROM 232 erheblich reduziert wird, was vorteilhafterweise die Größe und die Kosten einer integrierten Schaltung für den Prozessor reduziert. Die Op Felder, einschließlich des Registerfeldes und einiger der Size Felder, geben ein Register direkt an oder geben einen indirekten Spezifizieren wie AX oder T1 an. Auf ähnliche Weise kann ein Feld RegM auswählen, was der direkte Registerspezifizierer ist. Die Op Ersetzungslogik analysiert die Kodierung für den indirekten Registerspezifizierer, um nachfolgend die Kodierung des Registers zu definieren und die Kodierung des Registers mit dem derzeitigen Register zu ersetzen. Die Size Felder wählen ein Byte, zwei Bytes oder vier Bytes aus oder wählen eine D Größe aus, so dass die derzeitige effektive Datengröße die originale Kodierung ersetzt. Die Symbole wie HReg repräsentieren bestimmte Kodierungen, wie HReg_T2, das eine symbolische Repräsentation der Kodierung für T2 ist. Beispielhafte Symbole umfassen Hreg, HDSz, HASz, HSegDescr, HSpecOpType und andere.
  • Pseudo RTL Code, wie folgt, beschreibt insbesondere den Betrieb der Emulationsumgebungsersetzung.
  • Figure 00630001
  • Figure 00640001
  • Figure 00650001
  • Der Emulationscodesequenzer 510 folgt zu einem nächsten Eintrittspunkt in dem Emulationscode ROM 232, erzeugt einen Op Quad, einschließlich vier Operationen (Ops) und einem OpSeq Feld. Für jede der vier Operationen in einem Op Quad werden verschiedene Ersetzungen gemacht, wobei der Typ der Ersetzung von dem bestimmten Typ der Operation aus den fünf generellen Operationstypen abhängt. Die fünf Operationstypen umfassen Registeroperationen (RegOps), Lade-Speicheroperationen (LDStOps), Operatio nen zum unmittelbaren Laden (LIMMOps), Spezialoperationen (SpecOps) und Gleitkomma Operationen (FpOps). Die Op Formate für die fünf Operationstypen sind in den 6A bis 6E dargestellt.
  • Die Ops, welche von dem Emulationscode ROM 232 erzeugt werden, sind allgemeiner Natur. Insbesondere entsprechen die Ops nicht exakt einem x86 Befehl. Stattdessen bilden die Ops von dem Emulationscode ROM 232 eine Struktur für einen x86 Befehl. Verschiedene Bitfelder in der Op Vorlage werden ersetzt unter Benutzung einer Ersetzungsfunktion, die von dem Emulationscodesequenzer 510 ausgeführt wird. Einfach beschrieben ersetzt die Ersetzungsfunktion einige Bits der Op mit anderen ausgewählten Bits.
  • X86 Befehle umfassen typischerweise einen Opcode gefolgt von einem modr/m Byte. Das modr/m Byte zeigt ein Indextyp oder eine Registernummer an, die in dem Befehl zu benutzen ist. Das modr/m Byte hat drei Felder einschließlich einem Mode Feld mit 2 Bit (MSB), einem reg Feld mit 3 Bit (Mitte) und einem r/m Feld mit 3 Bit (LSB). Das Mode Feld wird mit dem r/m Feld kombiniert, um 32 mögliche Werte zu bilden, die anzeigend sind für acht Register und 24 Indexmodi. Das reg Feld gibt entweder eine Registernummer oder drei weitere Bits an Opcode Information an. Das r/m Feld gibt entweder ein Register als die Stelle eines Operanden an oder wird zusammen mit dem Mode Feld verwendet, um Register und Indexmodi zu definieren.
  • 6A ist eine Grafik für die Kodierung eines Registeroperations (RegOp) Feldes, die verschiedene Felder in dem RegOp Format darstellt. In dem Re-gOp Feld 610 sind die höchstwertigen Bits 36 und 37 frei, um die Operation als eine RegOp zu bezeichnen. Das RegOp Feld 610 enthält auch ein 6 Bit Operationstyp (TYPE) Feld 612 an den Bitstellen [35 : 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 Operations/Daten Größe (DSz) Feld 618 an den Bitstellen [24 : 22], ein 5 Bit Ziel (DEST) allgemeines Registerfeld 620 an den Bitstellen [21 : 17] und ein 5 Bit Quelle 1 (SRC1) allgemeines Registerfeld 622 an den Bitstellen [16 : 12]. Das RegOp Feld 610 enthält auch ein Setze Status (55) Feld 624 mit einem einzigen Bit an der Bitstelle [9], ein unmittelbare Quelle 2 (I) Feld 626 mit einem einzigen Bit an der Bitstelle [8] und ein 8 Bit unmittelbare Daten oder allgemeines Register für Quelle 2 Operanden (IMM8/SRC2) Feld 628 an den Bitstellen [7 : 0]. Das TYPE Feld 612 der RegOp Kodierung enthält wie folgt:
  • Figure 00670001
  • Figure 00680001
  • Zahlreiche RegOp Kodierungen, insbesondere die xx01x Kodierungen, geben Abhängigkeiten von Bedingungscode an. Die Rotations- und Schiebe-Schiebe-RegOps sind funktional äquivalent mit der Ausnahme, dass unterschiedlich statmod Bits angelegt werden.
  • Das Erweiterungsfeld (EXT) 614 wird verwendet, in Verbindung mit dem Bit <0> des TYPE Feldes 612, um für MOVcc Operationen einen 5 Bit Bedingungscode anzugeben. Das Erweiterungsfeld (EXT) 614 wird auch verwendet, um für RDxxx/WRxxx Operationen eine 4 Bit Spezial Registernummer anzugeben. Das Setz Status (55) Feld 624 wird in Verbindung mit dem EXT Feld 614 verwendet, um die Status Flags zu bezeichnen, die von einer Operation betroffen sind. Für Ops, bei denen das Setz Status (SS) Feld 624 auf 1 gesetzt ist, was anzeigt, dass diese Op Flags verändert, gibt das Erweiterungsfeld (EXT) 614 vier Statusveränderungsbits an, welche die Gruppen von Flags bezeichnen, die von der Op geändert werden. Für RDSEG Ops gibt das EXT Feld 614 ein 4 Bit Segment (Auswahl) Register an. Für eine WRFLG bedingte Op stimmt die Kodierung des Spezial Registers mit dem gewünschten StatMod überein, wenn das 55 Feld gesetzt ist. Das Setz Status (SS) Feld 624 und das EXT Feld 614 sind RegOp Felder.
  • Bedingungscodes sind in fünf Bits kodiert, Bit <0> des 5 Bit Bedingungsco des Feldes gibt an, ob die Bedingung oder ihr Komplement auf Wahrheit oder Ausgabe getestet werden soll, zum Beispiel falls cc<0> gleich eins ist, wird dann die Bedingung invertiert. Die Bits <4 : 1> des 5 Bit Bedingungscode (CC) Feldes geben die zu bewertende Bedingung wie folgt an:
  • Figure 00690001
  • Das Bit cc[0] gibt an, ob die Bedingung oder das Komplement der Bedingung auf die Wahrheit untersucht wird.
  • In den Definitionen zeigt das Zeichen "~" eine logische NICHT Operation an, "." zeigt eine logische UND Operation an, "+" zeigt eine logische ODER Operation an und "^" zeigt eine logische EXKLUSIVES ODER Operation an. OF, SF, ZF, AF PF und CF sind übliche x86 Status Bits. EZF und ECF sind ein Emulation Nullflag beziehungsweise ein Emulation Übertragsflag, die der Emulationscode in Sequenzen verwendet, die x86 Befehle implementieren, wenn das architekturale Null Flag ZF und das Übertrag Flag CF nicht verändert werden. IP, DTF und SSTF sind Signale anzeigend, dass ein Interrupt anhängig ist, ein debuf Falle Flag beziehungsweise ein Einzelschrittfallen Flag.
  • Die Verzweigungsbedingungen STRZ und MSTRC sind logisch identisch und werden bei der Implementierung von x86 Befehlen verwendet, wie ein bewege Zeichenkette Befehl MOVs. Für diese x86 Befehle speichert der Emulationscode einen Index in einem Register und erzeugt eine Schleife, die mit einer BRCOND endet. Jeder Durchgang der Schleife bewegt einen Block von Daten und zählt den Index runter. Die Verzweigungsvorhersage sagt anfänglich voraus, dass die BRCOND zu dem Anfang dem Schleife verzweigt. Die Bedingung MSTRC zeigt an, dass die Logik für die Bewertung einer Verzweigung dabei ist, dem Befehlsdekodierer zu signalisieren, wann der Index einen vordefinierten Punkt nahe dem Abschluss des x86 Befehls erreicht. Der Dekodieren ändert dann die Verzweigungsvorhersage für die BRCOND, die in dem Ablaufplaner geladen wird. Entsprechend wird eine falsch vorher gesagte Verzweigung und der damit verbundene Abbruch vermieden, wenn das Durchlaufen der Schleife abgeschlossen ist. Die Effizienz des Prozessors wird auf diese Weise verbessert.
  • Das EXT Feld 614 wird verwendet, um Bedingungsflags zu aktualisieren, einschließlich sechs Flags, die x86 Flags entsprechen, und zwei Emulation Flags. Die acht Flags sind in vier Gruppen unterteilt, wobei ein Statusveränderungsbit pro Gruppe von Flags verwendet wird. Das EXT Feld 614 definiert die Aktualisierung von verschiedenen Bedingungscodeflags, die im wesentlichen unabhängig von der Spezifikation von TYPE 612 sind, so dass die funktional verwandten Flags als eine Gruppe gesteuert und aktualisiert werden. Die Aktualisierung von verwandten Flags als eine Gruppe spart vorteilhafterweise Steuerlogik ein. Das EXT Feld 614 definiert einen Satz von Bits, der die für einen bestimmten Befehl zu aktualisierenden Flags bestimmt. Die Entkopplung der Behandlung von Bedingungscode von dem Typ der Operation, unter Verwendung des unabhängigen TYPE 612 und dem Setze Status (SS) Feld 624, erlaubt es einigen Operationen, definiert zu werden, welche die Flags nicht aktualisieren. Entsprechend ist es, für diese Umstände, in denen eine Aktualisierung von Bedingungsflags nicht notwendig ist, höchst vorteilhaft, die Aktualisierung der Flags auszuschalten, um unnötige Abhängigkeiten von vorherigen Werten für die Flags zu vermeiden.
  • Das nur RU1 Feld 616 ist anzeigend für Ops, die an die erste Registereinheit 244 und nicht an die zweite Registereinheit 246 ausgegeben werden, so dass das R1 Feld 616 ein Bit für die harte Kodierung einer Angabe der Registereinheit ist. Daher zeigt das nur RU1 Feld 616 an, dass eine bestimmte Operation nur in einer bestimmten Ausführungseinheit ausführbar ist, im Allgemeinen weil nur die bestimmte Ausführungseinheit eine in dieser Einheit implementierte Funktion aufweist. Das Setze Status (55) Feld 624 verändert Status Flags in Übereinstimmung mit den Einstellungen des EXT Feldes 614. Das I Feld 626 gibt an, ob der Quelle 2 Operand unmittelbar ist oder ein allgemeines Register. Das IMM8/SRC2 Feld 628 gibt ein allgemeines 5 Bit Register an, falls 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 Größe des DSz Feldes angegeben ist, wenn das I Feld 626 eins ist.
  • Für den Fall einer Ersetzung einer Registeroperation (RegOp) ist die Operation (Op) aus dem Op Quad eine Registeroperation (RegOp). Das Befehlsregister 512 hält Befehlsbytes, die von dem vektorisierenden Dekodieren 418 dekodiert sind. Während einer vektorisierenden Befehlsdekodierung erzeugt der vektorisierende Dekodieren 418 einen anfänglichen vektorisierenden Quad und eine Eintrittspunktadresse basierend auf den Inhalten des Befehlsregisters 512. Zu der gleichen Zeit initialisiert der vektorisierende Dekodieren 418 die Variablen der Emulationsumgebung, auch Emulationsumgebungsregister 516 genannt, aus verschiedenen Informationen basierend auf Feldern des Befehlsregisters 512 und basierend auf anderen Informationen. Die Informationen aus dem Emulationsumgebungsregister 516 werden der Op Ersetzungslogik zur Verfügung gestellt, welche die Ersetzungsoperation durchführt.
  • Für die Ersetzung von RegOps werden in den Feldern des in 6A gezeigten RegOp Formats verschiedene Ersetzungen vorgenommen. Für die Ziel (DEST) 620 und Quelle 1 (SRC1) 622 Felder einer RegOp Operation gibt eine Kodierung eines fünf Bit Registers ein Register unter Verwendung direkter Registerspezifizierer (0–15) oder indirekter Registerspezifizierer (Reg und RegM) an. Die direkten Registerspezifizierer bezeichnen direkt eines der sechzehn Register. Die indirekten Registerspezifizierer Reg und RegM zu dem Zeitpunkt der Op Dekodierung durch die derzeitigen Registernummern (0–15) aus den Emulationsumgebungsregistern 516 ersetzt. Die Ersetzung findet statt, wenn der Makrobefehlsdekodierer 230 einen Befehl dekodiert, zu einer Sequenz von Emulationscode in dem Emulationscode ROM 232 einspringt, das Emulationsumgebungsregister 516 mit verschiedenen Feldern von dem Befehl und anderen Informationen initialisiert. Während des Betriebs einer Sequenz von Emulationscode enthalten die Ops in der Sequenz verschiedene Felder, wie Felder des indirekten Registerspezifizierer und Felder der Datengröße, welche basierend auf den derzeitigen Werten des Emulationsumgebungsregisters 516 ersetzt werden. Die Op Ersetzungslogik bestimmt, ob die Kodierungen für ein Feld ein ersetztes Feld anzeigen. Eine Kodierung für ein Feld kann anzeigen, dass andere Felder ersetzt werden. Zum Beispiel zeigt die Kodierung der indirekten Spezifizieren Reg und RegM in den dest 620 und src2 622 Feldern an, dass das DSz Feld 618 ebenfalls ersetzt wird.
  • Im Hinblick auf das DSz Feld 618, arbeiten Befehle des x86 Befehlssatzes mit Daten von 8 Bit, 16 Bit oder 32 Bit, abhängig von der derzeitigen Vorgabebedingung des Prozessors 120. Das DSz Feld 618 enthält drei Bits, die eine Datengröße von einem Byte, zwei Bytes oder drei Bytes anzeigen. Für Befehle, welche die Ersetzung der Datengröße angeben, bezeichnen die indirekten Spezifizieren eine A Größe, D Größe oder S Größe. Eine Ersetzung der Datengröße wird durch ein B Bit oder ein D Bit angegeben. Das B Bit wird von dem derzeitigen Stapel-Segmentregister (SS) angegeben. Das D Bit wird von dem Code-Segmentregister (CS) angegeben. Für indirekte Spezifizieren der Größe wird die S Größe durch das B Bit bestimmt. Die effektive Größe der Adresse (A) und die effektive Größe der Daten (D) werden von dem D Bit bestimmt, möglicherweise von Präfixen zum Überschreiben der Adress- und Datengrößen übersteuert und in dem Emulationsumge bungsregister 516 gehalten. Im Allgemeinen werden die indirekten Spezifizieren für die A Größe, D Größe und 5 Größe ersetzt oder ausgetauscht durch die absolute Kodierung für die Bytes oder vier Bytes. Zum Beispiel wird, wenn eine D Größe ausgewählt ist, die Datengröße in zwei Bytes oder vier Bytes aufgelöst, basierend auf der effektiven Datengröße, wie sie von einem Bit in dem Emulationsumgebungsregister 516 angegeben ist. Auf ähnliche Weise wird, wenn ein indirekter Spezifizieren für die Größe die A Größe kodiert, die effektive Adressgröße von einem Bit in dem Emulationsumgebungsregister 516 als entweder zwei Bytes oder vier Bytes seiend angegeben. Falls der indirekte Spezifizierer die S Größe auswählt, bestimmt das B Bit, ob zwei Byte oder vier Byte ersetzt werden.
  • Die Ersetzung des Imm8/Src2 Feldes 628 wird nur durchgeführt, wenn ein Quelle 2 (src2) Operand ein indirekter Registerspezifizierer ist, statt eines unmittelbaren Werts. Die Op Ersetzungslogik bestimmt, ob die Kodierung für das unmittelbare (I) Feld 626 anzeigend ist für eine Ersetzung in dem Imm8/Src2 Feld 628, durch Zugreifen auf das Bit des I Feldes 626 und, falls ein indirekter Registerspezifizierer ausgewählt ist, Ersetzen einer fünf Bit Bezeichnung des allgemeinen Registers in das imm8/src2 Feld 628 des RegOp Formats 610. Für einen im Register gespeicherten src2 Operanden, der eine den Speicher indizierende Form der Adressierung verwendet, findet keine Ersetzung statt und das imm8/src2 Feld 628 des RegOp Formats 610 wird mit einem Indexwert geladen. Das RegOp Format 610 ist ein drei (zwei Quellen und ein Ziel) Operanden Format vom RISC Typ, umfassend das src1 Feld 622, das imm8/src2 Feld 628 und das dest Feld 620. Ein übliches x86 Format ist ein zwei Operanden Format. Das I Feld 626 erlaubt es vorteilhafterweise dem Quelle 2 Operanden, flexibel die Form von entweder einem unmittelbaren Wert oder einem allgemeinen Register anzunehmen.
  • Das RegOp Feld 610 definiert eine Gruppe von bestimmten Ops, einschließlich Multiplizieren mit Vorzeichen (MUL1S), Multiplizieren ohne Vorzeichen (MUL1U), Multiplizieren von hohen Daten (MULEH) und Multiplizieren von niedrigen Daten (MULEL) Ops, die Teile von Multiplikations- und Entladeoperationen ausführen, so dass ein Multiplikationsbefehl aus einer Vielzahl von diesen bestimmten Multiplikation Ops gemacht ist. Eine Divisionsoperation wird auf ähnliche Weise von einer Kombination aus einer Vielzahl von bestimmten einfachen Division Ops ausgeführt, einschließlich ein und zwei Bit Division (DIV1), schrittweise Division (DIV2), Division, entladen Rest (DI-VER) und Division, entladen Quotient (DIVEQ) Ops, zum Beispiel ausführend eine zwei Bit Iteration bei einer Division.
  • Die WRIP Op schreibt den x86 Programmzähler, um die Ausführungsadresse zu ändern, wenn die WRIP Op zurück gezogen wird, was das Holen von Befehlen an einer gewünschten Adresse startet. Die WRIP Op ist besonders vorteilhaft für den Fall von verschiedenen Befehlen, für welche die Dekodierung der Länge des Befehls schwierig oder unmöglich ist, so dass, um eine Komplexität der Logik zu vermeiden, die implementierte Logik die Länge nicht korrekt dekodiert. Der Befehl ist also vorteilhaft für die Serialisierung von Operationen zum Holen von Befehlen und zur Emulierung von Verzweigungen. Die Effizienz wird erreicht, indem es der Logik erlaubt wird, die Länge des Befehls nicht korrekt zu dekodieren und den Programmzähler unter Verwendung der WRIP Op zu setzen, so dass die nicht korrekt dekodierte Länge des Befehls ignoriert wird.
  • Die Überprüfe Selektor (CHKS) Op wird verwendet zum Behandeln von Segmentdeskriptoren und -selektoren des x86 Befehlssatzes. Die CHKS Op leitet einen Prozess des Ladens der Segmentregister ein, einschließlich der Operationen des Überprüfens auf einen Nullselektor und des Erzeugens einer Adressverschiebung in eine Tabelle des Deskriptors.
  • Zahlreiche Schreibdeskriptor Ops (WRDH, WRDL, WRDR) sind definiert, um reale (WRDR) und Protected Mode (WRDH/WRDL) Segmentregister Ladevorgänge durchzuführen, wie sie in der Technik der Computer und insbesondere im Hinblick auf konventionelle x86 Operationen sehr bekannt sind. Die Schreibe Deskriptor real (WRDR) Op lädt das Segmentregister auf Art des Real Modes. Die Schreibe Deskriptor Protected Mode hoch und niedrig (WRDH/WRDL) Ops führen eine Abfolge von Überprüfungsoperationen in dem Protected Mode durch. In einer konventionellen x86 Architektur wird der Zugriff einer Aufgabe auf den Befehlscode und Datensegmente und den I/O Adressraum automatisch von Hardware des Prozessors überprüft, typischerweise als eine Zustandmaschine arbeitend. Bei dem hier offenbarten Prozessor werden die konventionellen Überprüfungen im Protected Mode stattdessen als eine Abfolge von Operationen als eine Emulationscodeabfolge von Hardware Primitiven durchgeführt.
  • 6B ist eine Grafik für die Kodierung eines Lade-Speicheroperations (LdStOp) Feldes, die verschiedene Felder in dem LdStOp Format darstellt. In dem LdStOp Feld 630 sind die höchstwertigen Bits 36 und 37 auf Eins beziehungsweise Null gesetzt, um die Operation als eine LdStOp zu bezeichnen. Das LdStOp Feld 630 enthält auch ein 4 Bit Operationstyp (TYPE) Feld 632 an den Bitstellen [35 : 32] und ein zwei Bit Indexskalierungsfaktor (ISF) Feld 634 an den Bitstellen [31 : 30], das Faktoren 1x, 2x 4x und 8 bezeichnet. Das LdStOp Feld 630 enthält ein 4 Bit Segmentregister (SEG) Feld 636 an den Bitstellen [29 : 26] und ein zwei Bit Adressberechnungsgröße (ASz) Feld 638 an den Bitstellen [25 : 24], bezeichnend eine Auswahl zwischen der A Größe, der 5 Größe, der D Größe und vier Bytes. Die effektiven Größen für die Daten und die Adressen werden für LdStOps auf die gleiche Weise ersetzt wie für RegOp Ersetzungen. Das LdStOp Feld 630 enthält ein 2 Bit Daten Größe (DSz) Feld 640 an den Bitstellen [23 : 22], das die Größen (1, 2, 4 und D Größe Bytes) für ganze Zahlen und Größen (2, 4 und 8 Bytes) für Gleitkomma angibt, ein 5 Bit Daten Quelle/Ziel (DATA) allgemeines Registerfeld 642 an den Bitstellen [21 : 17] und große Verschiebung (LD) Bit 644 mit einem einzigen Bit an der Bitstelle [16], das eine große Verschiebung angibt, welche die Disp8 Verschiebung von einer vorher gehenden Op verwendet. Das LD Bit 644 ist hilfreich, da Ops lediglich 38 Bits breit sind, ein Befehlsformat nicht ausreichend, um eine komplette 32 Bit Verschiebung in eine Operation anzugeben. Nur in acht Bits kodierte Verschiebungen sind möglich für ein einzelnes LdStOp Feld 630. Das LD Bit 644 zeigt, wenn angelegt, an, dass die unmittelbar voran gehende Op eine komplette 32 Bit Verschiebung zur Verfügung stellt. Das LdStOp Feld 630 enthält ein 4 Bit Basis (BASE) allgemeines Registerfeld 646 an den Bitstellen [15 : 12]. Das LdStOp Feld 630 enthält auch ein 8 Bit mit Vorzeichen verse hendes Verschiebungs (DISP8) Feld 648 an den Bitstellen [11 : 4] und ein 4 Bit Index (INDEX) allgemeines Register Feld 649 an den Bitstellen [3 : 0]. Das TYPE Feld 632 der LdStOp Kodierung enthält wie folgt:
    Figure 00760001
    Für den Fall einer Ersetzung einer Lade-Speicheroperation (LdStOp) bestimmt der Emulationscodesequenzer 510 zuerst, ob ein LOCK Präfix während der Einrichtung der Emulationsumgebung bestätigt worden ist. Falls die bezeichnete LdStOp Operation ein Ladevorgang für eine ganze Zahl mit Speicherüberprüfung (LDST) ist und der LOCK Präfix bestätigt ist, ersetzt der Emulationscodesequenzer 510 einen Ladevorgang für eine ganze Zahl mit Speicherüberprüfung, verriegelt (LDSTL) Opcode für den LDST Opcode. Für die Ersetzung einer LdStOp werden verschiedene Ersetzungen in Feldern des in der 6B gezeigten LdStOp Formats gemacht. Für das Datenregister (DataReg) Feld 642 einer RegOp Operation gibt eine Kodierung eines fünf Bit Registers ein Register unter Verwendung direkter Registerspezifizierer (0–15) oder indirekter Registerspezifizierer (Reg und RegM) an. Die direkten Registerspezifizierer bezeichnen direkt eines der sechzehn Register. Die indirekten Registerspezifizierer Reg und RegM zu dem Zeitpunkt der Op Dekodierung werden durch die derzeitigen Registernummern (0–15) aus den Emulationsumgebungsregistern 516 ersetzt. Die Ersetzung findet statt, wenn der Makrobefehlsdekodierer 230 einen Befehl dekodiert, zu einer Sequenz von Emulationscode in dem Emulationscode ROM 232 einspringt, das Emulationsumgebungsregister 516 mit verschiedenen Feldern von dem Befehl und anderen Informationen initialisiert. Während des Betriebs einer Sequenz von Emulationscode enthalten die Ops in der Sequenz verschiedene Felder, wie Felder des indirekten Registerspezifizierers und Felder der Datengröße, welche basierend auf den derzeitigen Werten des Emulationsumgebungsregisters 516 ersetzt werden. Die Op Ersetzungslogik bestimmt, ob die Kodierungen für ein Feld ein ersetztes Feld anzeigen. Eine Kodierung für ein Feld kann anzeigen, dass andere Felder ersetzt werden. Die bestimmte Ersetzung hängt davon ab, ob das Datenregister (DataReg) 642 unter Verwendung einer Registeradressierung oder einer speicherindizierten Adressierung adressiert wird. Falls die Form der Registeradressierung zugewiesen ist, wird das DataReg Feld 642 des LdStOp Formats 630 von dem indirekten Spezifizieren Reg bestimmt. Falls die Form der speicherindizierten Adressierung zugewiesen ist, wird das DataReg Feld 642 des LdStOp Formats 630 von dem direkten Spezifizieren RegM bestimmt.
  • Im Hinblick auf das ASz Feld 638 und das DSz Feld 640, arbeiten Befehle des x86 Befehlssatzes mit Daten von 8 Bit, 16 Bit oder 32 Bit, abhängig von der derzeitigen Vorgabebedingung des Prozessors 120. Das ASz Feld 638 und das DSz Feld 618 enthalten jeweils zwei Bits, die eine Datengröße von einem Byte, zwei Bytes oder drei Bytes anzeigen. Für Befehle, welche die Ersetzung der Datengröße angeben, bezeichnen die indirekten Spezifizieren eine A Größe, D Größe oder S Größe. Eine Ersetzung der Datengröße wird durch ein B Bit oder ein D Bit angegeben. Das B Bit wird von dem derzeitigen Stapel-Segmentregister (SS) angegeben. Das D Bit wird von dem Code-Segmentregister (CS) angegeben. Für indirekte Spezifizieren der Größe wird die S Größe durch das B Bit bestimmt. Die effektive Größe der Adresse (A) und die effektive Größe der Daten (D) werden von dem D Bit bestimmt, möglicherweise von Präfixen zum Überschreiben der Adress- und Datengrößen übersteuert und in dem Emulationsumgebungsregister 516 gehalten. Im Allgemeinen werden die indirekten Spezifizieren für die A Größe, D Größe und 5 Größe ersetzt oder ausgetauscht durch die absolute Kodierung für die Bytes oder vier Bytes. Zum Beispiel wird, wenn eine D Größe ausgewählt ist, die Datengröße in zwei Bytes oder vier Bytes aufgelöst, basierend auf der effektiven Datengröße, wie sie von einem Bit in dem Emulationsumgebungsregister 516 angegeben ist. Auf ähnliche Weise wird, wenn ein indirekter Spezifizieren für die Größe die A Größe kodiert, die effektive Adressgröße von einem Bit in dem Emulationsumgebungsregister 516 als entweder zwei Bytes oder vier Bytes seiend angegeben. Falls der indirekte Spezifizieren die 5 Größe auswählt, bestimmt ein B Bit, ob zwei Byte oder vier Byte ersetzt werden.
  • Die Ersetzung des Imm8/Src2 Feldes 628 wird nur durchgeführt, wenn ein Quelle 2 (src2) Operand ein indirekter Registerspezifizierer ist, statt eines unmittelbaren Werts. Die Op Ersetzungslogik bestimmt, ob die Kodierung für das unmittelbare (I) Feld 626 anzeigend ist für eine Ersetzung in dem Imm8/Src2 Feld 628, durch Zugreifen auf das Bit des I Feldes 626 und, falls ein indirekter Registerspezifizierer ausgewählt ist, Ersetzen einer fünf Bit Bezeichnung des allgemeinen Registers in das imm8/src2 Feld 628 des RegOp Formats 610. Für einen im Register gespeicherten src2 Operanden, der eine den Speicher indizierende Form der Adressierung verwendet, findet keine Ersetzung statt und das imm8/src2 Feld 628 des RegOp Formats 610 wird mit einem Indexwert geladen. Das RegOp Format 610 ist ein drei (zwei Quellen und ein Ziel) Operanden Format vom RISC Typ, umfassend das src1 Feld 622, das imm8/src2 Feld 628 und das dest Feld 620. Ein übliches x86 Format ist ein zwei Operanden Format. Das I Feld 626 erlaubt es vorteilhafterweise dem Quelle 2 Operanden, flexibel die Form von entweder einem unmittelbaren Wert oder einem allgemeinen Register anzunehmen.
  • Die LdStOp wird überprüft, um festzustellen, ob ein vier Bit Segmentregisterfeld 636 zu ersetzen ist. Wenn die Emulationsumgebung eingerichtet wird, werden die Präfixe für die Übersteuerung des Segments überwacht.
  • Die Präfixe für die Übersteuerung des Segments beeinflussen die Dekodierung eines nachfolgenden Befehls, wenn die Erzeugung einer LdStOp abhängig ist von dem effektiven Operandensegment des Befehls. Das Vorgabesegment ist DS oder 55, abhängig von dem dazu gehörigen allgemeinen Adressierungsmodus, und wird von dem Segment ersetzt, das von dem letzten Präfix für die Übersteuerung des Segments angegeben ist. Der Adressraum des Segmentregisters wird von der üblichen x86 Spezifikation auf vier Bits erweitert, um die Unterstützung von zusätzlichen speziellen Segmentregistern zu erlauben. Das Segmentregister ist wie folgt kodiert:
  • Figure 00790001
  • Zu der Zeit der Op Dekodierung, ersetzt der Emulationscodesequenzer 510 das "OS" Segmentregister mit der derzeitigen drei Bit Nummer des Segmentregisters von der Emulationsumgebung. Daher ist ein Segmentregister alternativ in einem bestimmten Segmentregister hart kodiert oder auf das Segment OS gesetzt, welches das derzeitige effektive Datensegmentregister bezeichnet, aber das von einer Segmentübersteuerung übersteuert werden kann.
  • Das Segmentregister für den Emulationsspeicher (MS) bezeichnet den Zugriff auf einen speziellen Emulationsspeicher zur Benutzung in der Emulationsumgebung. Die Deskriptortabelle SegReg TS bezeichnet den Zugriff auf entweder die globale Deskriptortabelle (GDT) oder die lokale Deskriptortabelle (LDT).
  • 6C ist eine Grafik für die Kodierung eines Lade unmittelbar (LIMMOp) Feldes, die verschiedene Felder in dem LIMMOp Format darstellt. In dem LIMMOp Feld 650 sind die höchstwertigen Bits 36 und 37 beide auf Eins gesetzt, um die Operation als eine LIMMOp zu bezeichnen. Das LIMMOp Feld 650 enthält auch ein 16 Bit unmittelbar hoch Teil (ImmHi) Feld 652 an den Bitstellen [35 : 20], ein 5 Bit Ziel (DEST) allgemeines Registerfeld 654 an den Bitstellen [19 : 16] und ein 16 Bit unmittelbar niedrig Teil (ImmLo) 656 an den Bitstellen [15 : 0]. ImmHi 652 und ImmLo 656 kombinieren sich, um einen Wert mit 32 Bit zu bezeichnen, der in das von dem DEST Feld 654 angegebene Register geladen wird.
  • 6D ist eine Grafik für die Kodierung eines Spezialoperations (SpecOp) Feldes, die verschiedene Felder in dem SpecOp Format darstellt. In dem SpecOp Feld 660 sind die höchstwertigen Bits 35 bis 37 jeweils auf 101 gesetzt, um die Operation als eine SpecOp zu bezeichnen. Das SpecOp Feld 660 enthält auch ein 4 Bit Operationstyp (TYPE) Feld 662 an den Bitstellen [35 : 31], ein 5 Bit Bedingungscode (CC) Feld 664 an den Bitstellen [30 : 26], ein 2 Bit Datengröße (DSz) Feld 666 an den Bitstellen [23 : 22], das Größen von 1, 4 und DSize Bytes bestimmt. Das SpecOp Feld 660 enthält: ein 5 Bit Ziel (DEST) allgemeines Registerfeld 668 an den Bitstellen [21 : 17] und ein 17 Bit unmittelbar konstant (Imm17) Feld 670 an den Bitstellen [16 : 0]. Das Imm17 Feld 670 hält entweder einen 17 Bit mit einem Vorzeichen versehenen unmittelbaren Wert oder eine 14 Bit Op Adresse. Das CC Feld 664 wird nur von BRCOND Ops verwendet. Das DSz Feld 666 und das DEST Feld 668 werden nur von LDKxx Ops benutzt. Eine übliche NOP Op wird definiert, eine "LIMM t0,<undefined> zu sein. Das TYPE Feld 662 der SpecOp Kodierung enthält wie folgt:
  • Figure 00800001
  • Figure 00810001
  • Für den Fall einer Spezialoperation (SpecOp) Ersetzung, wird die SpecOp überprüft, um festzustellen, ob ein Ziel allgemeines Register (DestReg) unter Verwendung einer Registeradressierung oder einer speicherindizierten Adressierung adressiert wird. Falls die Form der Registeradressierung zugewiesen ist, ersetzt der Emulationscodesequenzer 510 ein zuvor gespeichertes modr/m reg Feld von dem Reg Register in das DestReg Feld 668 des in 6D gezeigten SpecOp Formats 660. Falls die speicherindizierende Form zugewiesen ist, ersetzt der Emulationscodesequenzer 510 ein zuvor gespeichertes modr/m regm Feld von dem Regm Register in das DestReg Feld 668 des gezeigten SpecOp Formats 660. Das DestReg Feld 668 hält eine fünf Bit Registernummer, welche das Ziel einer Operation LDK oder LDKD ist.
  • Die SpecOp wird auch überprüft, um festzustellen, ob das Datengröße (DSz) Feld 666 zu ersetzen ist. Ein Ersetzungswert für das DSz Feld wird bestimmt vor der Op Behandlung durch den Emulationscodesequenzer 510, wenn die Emulationsumgebung in Übereinstimmung mit der derzeitigen Segmentvorgabeinformation wie übersteuert von beliebigen Operandengrößeübersteuerungen definiert wird. Das DSz Feld 666 wird auf eine Größe von 1 Byte, 4 Bytes oder eine alternativ definierte D Größe für die Lade konstant Operationen LDK und LDKD gesetzt. Der Emulationscodesequenzer 510 ersetzt einen bezeichneten Ersetzungswert in das DSz Feld 666 des SpecOp Formats 660.
  • Falls eine SpecOp eine Lade konstant, Daten (LDKD) Operation ist, passt oder skaliert der Emulationscodesequenzer 510 Daten in dem 17 Bit unmittelbar (Imm17) Feld 670 basierend auf der derzeitigen effektiven Datengröße an, welche von dem Datengröße (DSz) Feld 666 angegeben ist. Das 17 Bit unmittelbar (Imm17) Feld enthält eine 17 Bit konstante, eine 17 Bit mit einem Vorzeichen versehende unmittelbare oder eine 14 Bit Op Adresse.
  • Registeradressraum und Emulationsschnittstelle
  • Der Prozessor 120 implementiert einen Registeradressraum, der im Vergleich zu einem konventionellen x86 Registeradressraum erweitert ist. Der Registeradressraum des Prozessors 120 wird von fünf Bits adressiert, so dass 25 oder 32 Register definiert werden können. Acht Register entsprechen den x86 architekturalen Registern. Sechzehn zusätzliche temporäre Register werden hinzugefügt. Das Datengröße (DSz) Feld gibt die Datengröße für die Operation entweder direkt oder indirekt an. Für eine Operation von einem einzelnen Byte ist ein Register, das von dem Registerkodierungsfeld bezeichnet wird, unterschiedlich zu einem zwei oder vier Byte Register, das von dem gleichen Registerkodierungsfeld bezeichnet wird. Die Datengröße einer Operation kann entweder ein Byte (18) oder zwei/vier Byte (2B/4B) für RegOps, SpecOps und das Datenfeld 642 von LdStOps sein. Die Datengröße ist immer zwei/vier Byte (2B/4B) für die Basis 646 und Index 649 Felder von LdStOps.
  • Die Kodierung des Prozessor 120 Register Feldes ist wie folgt:
  • Figure 00820001
  • Figure 00830001
  • Die mnemonischen Zeichen "t0" und "_" sind Synonyme für ein Register, das geschrieben werden kann, aber stets eine Null beim Lesen zurück gibt. "_" wird typischerweise in einem Kontext verwendet, bei dem ein Operanden- oder Ergebniswert ein "don't care" ist.
  • Vierundzwanzig allgemeine Register werden zur Verfügung gestellt. Die ersten achtzehn Register entsprechen den allgemeinen x86 Registern AX bis DI. die verbleibenden sechzehn Register sind temporäre oder Arbeitsregister, die in mehreren Abfolgen von Operationen verwendet werden, die CISC Befehle implementieren. Operationen, welche 5 Bit Registernummern verwenden, greifen auf 32 Register zu und die verbleibenden Registernummern, die nicht für Ganzzahlregister verwendet werden, werden als Multimediaregister oder Platzhalter für die Ersetzung von Variablen der Emulationsumgebung verwendet.
  • Der Satz der x86 Ganzzahlregister unterstützt die Adressierung für Byteoperationen von jedem der unteren beiden Bytes von der Hälfte der Register (AX, CX, DX und BX). Basierend auf der Angabe der Registergröße werden die 3 Bit Registernummern in den x86 Befehlen entweder als hoch/niedrig Byte Register oder als Wort/Dwort Register interpretiert. Von einer operativen Sicht wird diese Größe entweder von dem ASz oder dem DSz Feld der Operation angegeben. (ASz für Basis- und Indexregister in LdStOps, und allgemein DSz für Daten/Ziel, src1 und src2 Register. Der Satz für Ganzzahlarbeitsregister unterstützt eine ähnliche Adressierung der unteren zwei Bytes von der Hälfte der Register (t1–t4 und t8 bis t11).
  • Die temporären Register für die unmittelbaren Daten werden verwendet, beginnend mit t8 in der Reigenfolge von einer Ableitung der Werte oder einer klein-endian Signifikanz. Die "reg" und "regm" Registernummern werden zu der Zeit der Op Kodierung von der derzeitigen drei Bit Registernummer von der Emulationsumgebung ersetzt, insbesondere durch ein Ersetzen von Reg/RegM durch "00xxx". Die drei Bits bezeichnen ein Register aus den ersten acht Registern (AX bis DI).
  • Die Organisation der Op Formate und des erweiterten Adressraums der Register definiert einen flexiblen internen mikroarchitekturalen Zustand des Prozessors 120. Der x86 architekturale Zustand ist lediglich ein Untersatz von dem mikroarchitekturalen Zustand des Prozessors 120. Der erweiterte Adressraum der Register enthält im Vergleich zu dem Adressraum der x86 Register eine erweiterte Anzahl an temporären Registern. Vierundzwanzig Register werden von dem erweiterten Registeradressraum des Prozessors 120 zur Verfügung gestellt, nur acht von diesen Registern entsprechen den x86 architekturalen Registern und sechzehn zusätzliche temporäre Register werden zur Verfügung gestellt. Auf ähnliche Weise enthält der Prozessor 120 eine erweiterte Anzahl von Flag Registern, von denen lediglich einige den x86 Status Flags entsprechen.
  • Zum Beispiel ist in einem Ausführungsbeispiel des Prozessors 120 zusätzlich zu dem üblichen Übertrag Flag ein Emulationsübertrag Flag definiert und mit der Emulationsumgebung verbunden. Damit wird ein konventioneller Additionsbefehl definiert, der das Übertrag Flag setzt und den permanenten architekturalen Zustand des Prozessors 120 ändert. Eine Emulationsadditionsoperation wird definiert, die das Emulationsübertrag Flag und nicht das konventionelle Übertrag Flag setzt. Verschiedene Befehle werden definiert, auf der Basis des Emulationsübertrag Flags zu verzweigen, während andere Befehle auf Basis des konventionellen Übertrag Flags verzweigen. Daher ist der Prozessor 120 gleichzeitig sowohl in einem konventionellen mikroarchitekturalen Zustand und in einem Emulation mikroarchitekturalen Zustand betreibbar. Diese Operation in einer emulierten Umgebung erlaubt es dem Prozessor 120, eine Emulationsmikrosequenz auszuführen und nicht den sichtbaren mikroarchitekturalen Zustand zu ändern.
  • Es wird nun auf 8 Bezug genommen, in der anhand eines bestimmten Beispiels eine Technik zur Ersetzung dargestellt ist. Ein ADD Registerbefehl in dem x86 Befehlssatz wird als ein Opcode kodiert, der von einem modr/m Byte gefolgt wird. Das 8 Bit Opcode Feld des ADD Befehls wird, in Kombination mit der Angabe in dem modr/m Byte, dass der Befehl ein Registerbefehl ist, verwendet, 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 Befehlsregister 512 geben an, dass reg zu AX beziehungsweise regm zu BX wird. Die reg und regm Felder werden von dem Befehlsregister 512 auf die Op Ersetzungsschaltung 522 angewandt, so dass die Ersetzung erreicht wird. Das Emulationscode ROM 232 umfasst Op Vorlagen nur für eine begrenzte Anzahl an Ops und die Op Ersetzungsschaltung 522 füllt die Vorlagen unterschiedlich auf, um eine große Anzahl an verschiedenen Ops zu erzeugen.
  • Bezugnehmend auf die aufgelisteten Kodierungen für die Registerfelder des Prozessors 120 wird das Register AX von einem Reg Code 0 0 0 0 0 hart angegeben. Alternativ geben vier mögliche reg Kodierungen, 1 1 0 x x, die Ersetzung eines Registers an. Die Ersetzung wird basierend auf dem bestimmten emulierten Befehl und dem derzeitigen Zustand des Prozessors 120, einschließlich der derzeitigen Emulationsumgebung, ausgeführt. Im Allgemeinen wird eine Ersetzung und Ausführung von einer Operation durchgeführt durch die Ersetzung: (1) einer Kodierung für eine Reg in das dest Feld 620, (2) einer Kodierung für eine Register Reg in das src1 Feld 622, (3) einer Kodierung für eine RegM in das Imm8/Src2 Feld 628, (4) einer Null in das unmittelbar (I) Feld 626 und (5) der entweder ein, zwei oder vier Bytes, die von der Datengröße angegeben werden, in das DSz Feld 618.
  • Es wird auf 9 Bezug genommen, in der ein beispielhaftes Ausführungsbeispiel eines Ablaufplaners 260 gezeigt ist. Der Ablaufplaner 260 enthält 24 Einträge, welchen bis zu 24 Operationen zugeordnet sind. Jeder Eintrag enthält einen Satz von Speicherelementen (namentlich Flip-Flops) in einem Reservoir des Ablaufplaners 940 und Bereiche von Logik 931 bis 936, die dem Eintrag zugeordnet sind. Die Speicherstelle enthält Information hinsichtlich einer Operation (Op), welche auf die Ausführung wartet, in dem Prozess ist ausgeführt zu werden oder abgeschlossen ist. Die meisten der Speicherelemente werden geladen/initialisiert, wenn der Befehlsdekodierer 220 einen neuen Befehl in das Reservoir des Ablaufplaners 940 lädt. Einige Speicherelemente werden später geladen oder erneut geladen, wie wenn die Operation die Ausführung abschließt. Die Speicherfelder, welche einen Wert von dem Zeitpunkt, an dem die Operation in das Reservoir des Ablaufplaners 940 geladen wird, beibehalten bis die Operation aus dem Ablaufplaner 260 zurückgezogen wird, werden hier als "statische Felder" bezeichnet. Felder, die mit neuen Werten erneut geladen werden können, werden als "dynamische Felder" bezeichnet.
  • Einzeln betrachtet kann ein Speicherelement eines Eintrags als ein frei gegebenes Flip-Flop angesehen werden. In Kombination ist die Vielzahl von Speicherelementen, im Hinblick auf den Ablaufplaner 260, ein Schieberegister, das vier Einträge breit ist und sechs Reihen (Op Quad Einträge) tief ist. Zu den dynamischen Feldern gehörende Speicherelemente werden von einer Datenquelle oder einem voran gehenden Speicherelement geladen. Daten werden in ein Speicherelement geladen und gleichzeitig und unabhängig in ein anderes Speicherelement geschoben.
  • Der Ablaufplaner 260 steuert die RU, LU und SZ Pipelines, die von den Registereinheiten 244 und 246, der Ladeeinheit 240 und der Speichereinheit 242 gebildet werden. Jede RU Pipeline hat drei Stufen, die als die Stufe Ausgabe, die Stufe Holen Operanden oder Stufe 0 und Stufe 1 bezeichnet werden. Die vier Stufen der LU und SU Pipelines werden als die Stufe Ausgabe, die Stufe Holen Operanden oder Stufe 0, Stufe 1 und Stufe 2 bezeichnet. Wie oben beschrieben repräsentiert das State Feld die fünf Zustände unter Verwendung der Kodierung "Schieben/Erhöhen des Feldes von Einsen", um die derzeitige Pipelinestufe der dazu gehörigen Operation anzuzeigen oder um anzuzeigen, dass die Operation ihre Pipeline abgeschlossen hat.
  • Die statischen Felder sind wie folgt definiert und alle Wert sind aktiv hoch:
    Figure 00870001
    Figure 00880001
    Figure 00890001
  • Dynamische Felder sind wie folgt definiert, wobei alle Werte aktiv hoch sind:
  • State [3 : 0] Zeigt den aktuelle Ausführungszustand einer Operation an, (S3, S2,S1,S0 sind alternativ Signalnamen für State [3 :0].) Fünf mögliche Zustände sind kodiert durch ein schiebendes Feld von Einsen über die vier Bits:
    0000 Nicht ausgegeben
    0001 Stufe 0
    0011 Stufe 1
    0111 Stufe 2
    1111 Abgeschlossen
  • Die unmittelbaren Zustände entsprechen der derzeitigen Ausführungsstufe der Op. Die Bits werden aktualisiert (tatsächlich verschoben) wenn die Ope- ration erfolgreich ausgegeben ist oder aus einer Stufe weiter vorrückt. Bemerkung: einige Operationen (zum Beispiel LDK) werden mit einem anfänglichen Zustand 1111 in den Ablaufplaner geladen und sind daher bereits "abgeschlossen". State [3 : 0] wird ebenfalls während Abbruchzyklen auf 1111 gesetzt. if (S0Enb1) S0 = ~BumpEntry + SC_Abort if (S1Enb1) S1 = (S0 ~BumpEntry) + SC_Abort if (S2Enb1) S2 = S1 + SC_Abort if (S3Enb1) S3 = S2 + S1 RU + SC_Abort
  • Figure 00900001
  • Figure 00910001
  • Exec1 Falls die Operation eine RegOp ist, dann führt RUX (nicht RUY) die Operation aus. Exec1 wird geladen, wenn die Operation erfolgreich ausgegeben worden ist.
    if (SOEnb1) Exec1 = "Issue OPi to RUX"
  • DestBM [2 : 0] Byte Markierungen bezeichnend Bytes von DestReg, welche die Op verändert. Die Bits [2,1,0] entsprechen zu DestReg [31 : 16), Reg [15 : 8] beziehungsweise Reg [7 : 0]. DestBM wird während Abbruchzyklen zurückgesetzt.
    if (SC_Abort) DestBM = 3'b0
  • DestVal [31 : 0] DestVal ist der Register Ergebniswert von der Ausführung der an DestReg zu übergebenden Op. DestVal zeigt an, welche Bytes nach der Ausführung der Op gültig sind. DestVal wird geladen, wenn die Op die Stufe Ausführung 1 oder 2 abschließt, abhängig von dem Typ der Op. Für nicht ausgeführte Ops wie LDK wird DestVal mit dem geeigneten Register Ergebniswert initialisiert. DestVal hält alternativ große unmittelbare und Versetzungswerte für RegOps und (beziehungsweise) LdStOps und den wechselnden (sequentiell oder Ziel) Verzweigungs PC Wert zugehörig zu einer BRCOND Op.
  • Figure 00920001
  • StatMod [3 : 0] Zustandgruppenmarkierungen anzeigend welche Gruppen von Zustandsbits die Op verändert. Die Bits [3, 2, 1, 0] entsprechen {EZF, ECF}, OF, {SF, ZF, AF, PF} beziehungsweise CF. StatMod ist immer überall Null für nicht RegOps und wird während Abbruchzyklen zurückgesetzt.
    if (Exec1 ~S3 S1 RUX_NoStatMod + SC_Abort)
    StatMod = 4'b0
  • StatVal [7 : 0] Statval ist der Zustandergebniswert von der Ausführung dieser Op und wird an EFlags übergeben. StatMod bezeichnet gültige Bits nach der Ausführung der Op. Statval ist nur von Bedeutung für RegOps, was durch einen Wert von Null von StatMod für alle nicht RegOps berücksichtigt wird. Statval wird geladen, wenn die RegOp die Stufe Ausführung 1 abschließt.
    if (~S3 S1) Statval = (Exec 1) ? RUX_StatRes : RUY_StatRes
    OprndMatch_XXsrcY, wobei "XX" LU, SU, RUX oder RUX ist und "Y" 1 oder 2 ist.
  • Weitere Speicherelemente werden verwendet, um transiente Information zu speichern, die zwischen zwei Stufen einer Logik übergeht. Dies unterscheidet sich von Information von eher globaler Wichtigkeit. Die Speicherelemente sind physikalisch die gleichen wie die obigen und werden der Vollständigkeit halber aufgeführt. Weil zusätzliche Speicherelemente Information von der Stufe Ausgabe an Stufe 0 jeder Verarbeitungspipeline oder in einem Fall von Stufe 1 and Stufe 2 von SU übergeben, werden die Werte der Speicherelemente von den XXAdv0 (oder Suadv2) globalen Signalen gesteuert.
  • Figure 00930001
  • DBN [3 : 0] Die vier Bn (n = 0–3) Daten Stopppunkt Zustandbits für eine LdStOp. Dieses Feld ist anfänglich nur Nullen, dann, wenn ei ne LdStOp in dieser Position ausführt, werden Stopppunkt Bits von der entsprechenden Einheit für ein späteres Fangen aufgezeichnet.
    if ((AdvLU2 + AdvSU2) ~ S3 S2) DBN [3 : 0] = (DBN_LU [3 : 0] LU) + (DBN_SU [3 : 0] SU)
  • Definition Op Quad Eintrag im Ablaufplaner
  • Die vierundzwanzig Einträge werden auf FIFO Art verwaltet, wobei neue Operationen in ein Ende (die "Spitze") geladen werden, nach unten zu dem anderen Ende (dem "Boden") geschoben werden und von dem Boden des Reservoirs des Ablaufplaners 940 zurück gezogen oder entladen werden. Um die Steuerung zu vereinfachen verwaltet der Ablaufplaner 260 das Reservoir 940 auf einer Op Quad Basis. Die Operationen werden in Gruppen von vier in das Reservoir 940 geladen, durch geschoben und aus ihm zurück gezogen. Dies stimmt überein mit dem Holen und der Erzeugung von Operationen in der Form von Op Quads durch sowohl das Emcode ROM als auch den MacDec in dem Dekodierer 220.
  • Das Reservoir des Ablaufplaners 940 kann als ein Schieberegister mit sechs Einträgen, die Op Quads enthalten, angesehen werden. Jeder Op Quad enthält vier Einträge sowie zusätzliche Information, die zu dem Op Quad als ganzem gehört. Das Folgende zählt die zusätzlichen "Op Quad" Felder auf und stellt für jedes Feld eine kurze funktionale Beschreibung zur Verfügung. Alle Werte sind als aktiv hoch definiert. Die meisten der Felder sind statisch. Die Beschreibung der dynamischen Felder enthält eine Peudo RTL Definition der Logik, welche die Daten erzeugt, und der Freigabeeingänge der Speicherelemente, welche diese Felder halten.
  • Emcode: Zeigt an, ob dies ein Emcode Op Quad vom Emcode ROM oder ein von dem MacDec erzeugter Op Quad ist.
  • Eret: Zeigt an, dass dies ein Emcode Op Quad ist und ein ERET (Rückkehr vom Emcode ROM) "enthält".
  • FaultPC [31 : 0]: Der Wert des logischer Makrobefehl (mI) Fehlerprogrammzähler zugehörig zu den Operationen in dem Op Quad Eintrag. Verwendet von der Operationsübergabeeinheit (OCU) 970, wenn Fehlerausnahmen von einer beliebigen der Operationen behandelt werden.
  • BPTInfo [14 : 0]: Auf die Verzweigungsvorhersagetabelle bezogene Information vom Zeitpunkt, an dem der Op Quad erzeugt wurde. Dieses Feld ist nur für von dem MacDec erzeugte Op Quads gültig, die eine BRCOND Operation enthalten.
  • LimViol Zeigt an, dass der Op Quad die Dekodierung eines Transfersteuerbefehls ist, für den eine Verletzung der Codesegmentgrenze auf der Zieladresse detektiert wurde. Für die meisten Op Quads ist dieses Feld statisch. Für den ersten Op Quad Eintrag im Register kann dieses Feld geladen werden, wie von der folgenden Pseudo RTL Beschreibung zusammengefasst ist:
    @clk: LdLV = LdEntry0 ~ DEC_OpQSel_E
    if (LdLV) LimViol = DEC_LimViol
  • OpQV Zeigt an, ob der Op Quad Eintrag einen gültigen Op Quad enthält und von der Logik verwendet wird, welche das Schieben der Einträge steuert. Einträge innerhalb eines "ungültigen" Op Quads müssen trotzdem definiert werden und müssen den gleichen Zustand haben wie die abgebrochenen Einträge.
    if (SC_Abort) OpQV = 'b0
  • Op1I, Op2I, Op3I Ein Zähler der Anzahl der Makrobefehle (mI), die von diesem Op Quad (1, 2 oder 3) repräsentiert werden. Wird verwendet, um einen Zähler der zurückgezogenen Befehle zu unterhalten.
  • Ilen0, Ilen1 Die Längen in Bytes von dem ersten und (falls vorhanden) zweiten Makrobefehl, der von dem Op Quad repräsentiert wird. Wird verwendet, um die Adresse des Befehls zu bestimmen, an der ein Fehler aufgetreten ist.
  • Smc1stAddr, Smc1stPg, Smc2ndAddr, Smc2ndPg
  • Die erste und (falls Befehle von mehr als einer Seite in dem Op Quad da sind) zweite Adresse, die von Operationen in dem Op Quad umfasst wird. Wird verwendet, um sich selbst verändernden Code zu detektieren.
  • OpDec Definition
  • Der Befehlsdekodierer 220 enthält auch eine Op Ersetzungsschaltung 522, welche den Makrobefehlsdekodierer 230 und das Emulationscode ROM 232 des Befehlsdekodierers 220 mit dem Ablaufplaner 260 verbindet. Die Op Ersetzungsschaltung 522 erweitert RISC Befehle in Feldwerte, die an die Spitze, Op Quad Eintrag 0, des Reservoirs des Ablaufplaners 940 geladen werden. Um einen Op Quad zu erzeugen, verändert die Op Ersetzungsschaltung 522 einige Felder des RISC Befehls basierend auf anderen Feldern, leitet neue Felder von existierenden ab, ersetzt einige Felder mit physikalisch unterschiedlichen Feldern und leitet einige wenige Felder unverändert durch. Die Ersetzung der Umgebungsvariablen für Felder von Emcode Operationen, die derartiges erfordern, und das auf Null setzen von Operationen innerhalb von Emcode Op Quads, in deren Mitte gesprungen wurde, werden beide in einer Logik ausgeführt, die dem OpDec (das heißt EmDec) vorgeschaltet ist.
  • Die folgenden Pseudo RTL Gleichungen beschreiben die Erzeugung von jedem Feld eines Eintrags in dem Ablaufplaner aus den Feldern eines ankommenden RISC Befehls. Die Schreibweise xxxOp.yyy bezieht sich auf ein Feld yyy, das für einen Befehl vom Typ xxxOp definiert ist, unabhängig von dem aktuellen Typ des Befehls. Zum Beispiel bezieht sich RegOp.Src1 auf Bits in einem Befehl an der gleichen Position wie das Src1 Feld einer RegOp. Die 6A bis 6E zeigen beispielhafte Definitionen der Felder für eine RegOp, LdStOp, LIMMOp, SpecOp und FpOp.
  • Figure 00970001
  • "RUYD" ist ein Spezialregister, dass die zweite Registereinheit RUY zum Debuggen sperrt.
  • Figure 00970002
  • Figure 00980001
  • Figure 00990001
  • Figure 01000001
  • Der folgende Pseudo RTL Code beschreibt die Erzeugung von jedem Feld in einem Op Quad Eintrag, der zu einem Op Quad gehört anstatt zu einer bestimmten einzelnen Operation.
  • Figure 01000002
  • Figure 01010001
  • Ausgabeauswahl
  • In jedem Zyklus wählt der Ablaufplaner 260 basierend auf den State [3 : 0] Feldern von allen Einträgen zu dem Beginn des Zyklus eine LdOp, eine Stop und zwei RegOps aus, die in die entsprechenden Verarbeitungspipelines LU, SU, RUX oder RUY ausgegeben werden sollen. Der Ablaufplaner 260 wählt Operationen für die Ausgabe basierend auf den State und Type Feldern innerhalb jedes Eintrags aus, welche "in Reihenfolge" von den ältesten zu den neuesten Operationen in dem Reservoir des Ablaufplaners 940 durchsucht werden. Die Ausgabeauswahl berücksichtigt nicht Abhängigkeiten im Register, im Status und/oder im Speicher, die jede Operation von relativ gesehenen älteren Operationen haben kann..
  • Der Ablaufplaner 260 führt die Ausgabeauswahl gleichzeitig und unabhängig für jede der vier Verarbeitungspipelines durch. Der Algorithmus für die Auswahl ist für die vier Pipelines ähnlich. Die nächste nicht ausgegebene Operation (wie durch ihr State Feld angezeigt) eines gegebenen Typs wird ausgewählt. Anders ausgedrückt wird die nächste nicht ausgegebene LdOp für die Ladeeinheit 240 ausgewählt, die nächste nicht ausgegebene Stop für die Speichereinheit 242 ausgewählt und die nächsten zwei nicht ausgegebenen RegOps werden an die Registereinheit X und die Registereinheit Y ausgegeben (die erste an RUX, die zweite an RUY). Vom Konzept her hängt die Ausgabeauswahl für RUY von RUX ab, aber wird parallel zu der Ausgabeauswahl für RUX ausgeführt. Wie weiter unten diskutiert wird, können einige RegOps nur an RUX ausgegeben werden und die zur Ausgabe an RUY ausgewählte Operation ist die nächste RegOp, die an RUX ausgegeben werden kann.
  • Jeder Eintrag in dem Ablaufplaner erzeugt vier Bits (das heißt ein Signal) "Issuable to xxx", das anzeigt, ob diese Operation zur Zeit für die Ausgabeauswahl an die Pipeline xxx auswählbar ist, wobei xxx LU, SU, RUX oder RUY ist.
    "Issuable to xxx" _ "State = Unissued" && "Executable by xxx"
  • Signale, die "Issuable to xxx" sind, werden von den State und Type Bits eines Eintrags erzeugt. Insbesondere "State = Unissued" = ~ S0 beziehungsweise "Executable by xxx" = LU/SU/RU/RUY für die Ausführungspipeline LU/SU/RUX/RUY. Der Prozess der Auswahl tastet die Pipeline xxx von dem ältesten Eintrag zu dem jüngsten Eintrag nach Einträgen mit dem Bit "Issuable to xxx" gesetzt ab. Für die Pipelines LU, SU und RUX ist die erste mit dem Bit gesetzt gefundene Operation diejenige zur Ausgabe ausgewählte. Die Ausgabeauswahl für die Pipeline RUY wählt die erste derartige Operation aus, nachdem die Operation für die Pipeline RUX ausgewählt ist.
  • Operationen sind für die Ausgabeauswahl verfügbar unmittelbar nachdem sie in den Ablaufplaner geladen sind, das heißt eine Operation kann wäh rend ihres ersten Zyklus des Verweilens in dem Ablaufplaner ausgewählt werden. In diesen Fällen müssen lediglich die Type Bits und das Bit 50 an dem Anfang des Zyklus gültig sein. Alle anderen Felder in einem Eintrag können so spät erzeugt werden, wie zu der Phase Ausgabeauswahl (das heißt bis zu einem halben Zyklus später) und brauchen nur für die nächste Phase der Verarbeitungspipeline in einem Eintrag des Ablaufplaners gültig zu sein.
  • Falls eine für die Ausgabe ausgewählte Operation nicht in die Stufe 0 vorrückt, war die Operation dann nicht erfolgreich ausgegeben. Während des nächsten Taktzyklus zeigt das State Feld dieser Operation an, dass die Operation nicht ausgegeben ist, und die Operation bewirbt sich um die Ausgabe und wird vermutlich wieder ausgewählt.
  • In einem Ausführungsbeispiel der Erfindung tastet der Ablaufplaner 260 die Operationen unter Verwendung von Abtastungsketten ab, die von Logikschaltungen in den Einträgen gebildet werden. Jede Abtastungskette ist ähnlich zu einer Übertragskette, wie sie in Addierern mit hoher Geschwindigkeit verwendet werden. Für eine Abtastung nach Operationen, die an die Ladeeinheit, die Speichereinheit oder die Registereinheit X ausgegeben werden sollen, wird ein "Carry" Bit Cin, das in den Eintrag für den ältesten Eintrag eingegeben wird, gesetzt und verbreitet sich durch die Abtastungskette, bis eine Logik in einem der Einträge das Abtastungsbit löscht. Ein Eintrag löscht das Carry Bit, falls der Eintrag einer Operation von dem abgetasteten Typ entspricht (das heißt "Issuable to xxx"). Um nach einer Operation abzutasten, die an die Registereinheit Y ausgegeben werden soll, wird ein "Carry" Bit von einem Eintrag erzeugt, der zu der Operation gehört, die an die Registereinheit X ausgegeben werden soll, und das Carry Bit verbreitet sich, bis es von einem Eintrag gelöscht wird, der zu der Operation gehört, die an die Registereinheit Y ausgegeben werden kann.
  • Weiterleitung Verschiebung
  • Während der Phase Operandenweiterleitung holt der Ablaufplaner 260 die Verschiebungsoperanden und leitet sie an die LU und SU Verarbeitungspipelines weiter, im Zusatz zu den Registeroperanden für diese Einheiten. Die LU und die SU haben jeweils drei Eingangsoperandenbusse 952, welche zwei Registeroperanden und einen Verschiebungsoperanden befördern. Die Verschiebungsoperanden sind 32 Bit Quantitäten, aber einige Bytes können nicht definiert sein. Eine Ausführungseinheit verwendet während einer korrekten Operation die nicht definierten Verschiebungsbytes nicht.
  • Der Ablaufplaner 260 behandelt Verschiebungen auf eine Weise ähnlich zu den Ergebniswerten der Operationsregister. Die Verschiebungen werden gespeichert bis sie in den 32 Bit DestVal Feldern der Einträge verwendet werden und während der Phase Operandenweiterleitung auf die Verschiebungsbusse 950 getrieben werden, wie es angebracht ist. Verschiebungen sind in dem Ablaufplaner 260 immer unmittelbare Werte, so dass ein Weiterleiten von Verschiebungswerten aus der Registerdatei 264 nicht vorkommt. Das Feld DestVal wird auch benutzt für Ergebniswerte von LdOps und einigen StOps von LdStOps, aber die zwei Verwendungen treten nicht in einen Konflikt, da ein Ergebniswert nicht in einen Eintrag des Ablaufplaners geladen wird bis nach der Verwendung des Verschiebungswerts, das heißt nicht bis nach Stufe 0.
  • Kleine (8 Bit) Verschiebungen, welche innerhalb von Operationen angegeben sind, werden anders behandelt als große (16/32 Bit) Verschiebungen. Die Op Ersetzungsschaltung 522 erweitert eine kleine Verschiebungen um ein Vorzeichen bevor die kleinen Verschiebungen in das DestVal Feld des Eintrags geladen werden, der die dazu gehörige LdStOp hält. Von großen Verschiebungen wird angenommen, dass sie in dem DestVal Feld des Eintrags gespeichert werden, welcher der die Verschiebung verwendenden LdStOp unmittelbar voran geht. Im Allgemeinen hält der voran gehende Eintrag eine "LIMM t0, [disp]" Operation.
  • Die Auswahl von DestVal Werten, um sie während jedes Zyklus auf die Verschiebungsbusse 950 zu treiben erfordert nicht das Abtasten der Einträge des Ablaufplaners. Stattdessen bestimmt jeder Eintrag anhand seines State und Type Feldes, ob seine eigenen Treiber oder die Treiber in einem voran gehenden Eintrag frei gegeben werden, um einen Wert für das DestVal Feld auf den geeigneten Verschiebungsbus 950 zu treiben. Die folgenden Gleichungen fassen das Freigeben der Treiber für den Verschiebungsbus in jedem Eintrag zusammen.
  • Figure 01050001
  • Die Werte "thisOp" und "nextOp" identifizieren den physikalischen Eintrag, aus dem die folgenden Minterm Bezeichnungen LU, S1, 50 und LD stammen. Auch ist, für den Fall des ersten/jüngsten Eintrags in dem Ablaufplaner 260 der NextOp Minterm Null.
  • Unmittelbare Weiterleitung
  • In Übereinstimmung mit dem beispielhaften Format von RISC Befehlen für die Ausführungsmaschine 222, sind unmittelbare Werte nur src2 Operanden von RegOps. Der Ablaufplaner 260 behandelt unmittelbare Werte ähnlich wie Verschiebungen, aber als Teil des Weiterleitungsmechanismus für Registeroperanden. Wie Verschiebungswerte werden unmittelbare Werte in den DestVal Feldern von Einträgen gespeichert; aber die unmittelbaren Werte werden wie Registeroperanden über die Registeroperandenbusse 952 (speziell die RUXsrc2 und RUYsrc2 Operandenbusse) weiter geleitet.
  • Der beispielhafte RISC Befehlssatz verwendet nur kleine (8 Bit) unmittelbare Werte in RegOps und speichert die unmittelbaren Werte in DestVal Felder des die RegOp haltenden Eintrags. Die unmittelbaren Werte der Src2 Operanden werden während der Phase Operandenweiterleitung in der Stufe 0 anstelle eines Registerwertes an die entsprechenden Register Ausführungseinheiten weiter geleitet. Die Auswahl einer Quelle für den Registerwert (das heißt eines Eintrags in dem Ablaufplaner oder der Registerdatei) wird verhindert und der in Frage kommende Eintrag treibt direkt sein DestVal Feld auf den entsprechenden src2 Eingangsoperandenbus 952.
  • Die Verhinderung von jeglicher RUX/RUYsrc2 Operandenauswahl wird während der Phase Operandenauswahl durch eine Maskierung des Erzeugungssignals ausgeführt, das normalerweise von dem Eintrag ausgegeben würde, der die RegOp hält, deren Operanden geholt werden. Dies geschieht getrennt und unabhängig von RUXsrc2 und RUYsrc2 und verhindert eine Auswahl von jeglichem Eintrag durch die RUX/Ysrc2 Abtastungskette und eine Auswahl der Registerdatei als die Vorgabe Operandenquelle. Die vorherigen Gleichungen der Abtastungskette für die Operandenauswahl zeigen die Verhinderung.
  • Die Auswahl der "unmittelbaren" DestVal Werte zum Treiben auf die RUXsrc2 und RUYsrc2 Operandenbusse während jedes Zyklus erfordert keine Abtastung der Einträge des Ablaufplaners. Stattdessen gibt jeder Eintrag die Treiber seines DestVal Feldes auf den geeigneten Operandenbus einfach basierend auf seinem State und dazu gehörigen Bits frei. Dies sind die gleichen Treiber, die für die Weiterleitung von normalen Registerwerten verwendet werden; es ist einfach ein zusätzlicher Ausdruck in jeder Freigabegleichung zum Behandeln der unmittelbaren Operanden. Das Folgende fasst diese Ausdrücke als getrennte Gleichungen für das Freigeben der getrennten Bustreiber in jedem Eintrag zusammen.
    Oprnd_RUXsrc2 = (RU Exec1 ~ S1 S0 Imm) ? DestVal : 32'bZ
    Oprnd_RUYsrc2 = (RU ~ Exec1 ~ S1 S0 Imm) ? DestVal : 32'bZ
  • Wenn ein Eintrag einen unmittelbaren Wert auf einen Operandenbus 952 treibt, treibt der Eintrag auch den dazu gehörigen Operandenstatusbus 954. Die gleichen Bustreiber und Treibereingangswerte wie für die normalen Operanden werden für die unmittelbaren Werte verwendet; es ist einfach ein zusätzlicher Ausdruck in jeder Freigabegleichung (die gleichen zusätzlichen Ausdrücke wie oben). Das Folgende fasst diese Ausdrücke als getrennte Gleichungen für das Freigeben der getrennten Bustreiber zusammen.
    OprndStat_RUXsrc2 = (RU Exec1 ~ S1 S0 Imm) ? OprndStat 10'bZ
    OprndStat_RUYsrc2 = (RU ~ Exec1 ~ S1 S0 Imm) ? OprndStat 10'bZ
  • Holen von Datenoperanden
  • StOps haben drei Register Quelloperanden und kein Registerziel, im Gegensatz dazu haben andere Operationen bis zu zwei Quelloperanden und ein Ziel. Der dritte Quelloperand für eine Stop stellt die zu speichernden Daten zur Verfügung und wird hier manchmal als ein Datenoperand bezeichnet. Der Datenoperand wird nicht benötigt, um die Ausführung zu starten, aber wird für den Abschluss einer Stop benötigt. Das Holen eines Wertes für einen Stop Datenoperanden wird auf eine ähnliche Weise wie das Holen anderer Quelloperanden durchgeführt, ist aber mit der SU Stufe 2 synchronisiert. Wo der "normale" Prozess des Holens von Operanden während der Stufe Ausgabe und der Stufe der Verarbeitung der Operation geschieht, tritt der Holprozess für den Datenoperanden während der SU Stufen 1 und 2 auf. Der Ablaufplaner 260 detektiert einen Datenoperanden, der während der SU Stufe 2 noch nicht verfügbar ist und hält die dazu gehörige Stop in der Stufe 2.
  • Der Holprozess für Datenoperanden ist größtenteils der gleiche wie die oben beschriebenen Stufen Ausgabe und Holen von Operanden, mit zwei prinzipiellen Ausnahmen. Der erste Unterschied ist, dass eine Phase Operandenauswahl für die derzeit in der SU Stufe 1 befindliche Stop die Phase Ausgabeauswahl ersetzt und nicht über die Einträge des Ablaufplaners abtastet, um zwischen mehreren Kandidaten zu wählen. Stattdessen identifiziert sich der zu der Stop in der SU Stufe 1 gehörende Eintrag selbst von den State und Type Feldern. Der zweite Unterschied ist, dass das OpInfo Feld der Stop während einer Phase Verbreitung für den Datenoperanden nicht (erneut) ausgelesen werden muss. Stattdessen hält die Speichereinheit 242 den OpInfo Wert zurück, der ausgelesen wurde, als die Stop ausgegeben wurde, und verwendet das OpInfo Feld während der folgenden Phasen. Der während der SU Stufe Ausgabe ausgelesene OpInfo Wert wird mit der Operation durch die Stufen 0, 1 und 2 der SU Pipeline runter gereicht.
  • Die folgende Gleichung beschreibt die für das Holen der Datenoperanden erzeugten Signale.
  • SU Stufe 1: Phase Operandenauswahl
  • "Select for data operand fetch" = SU ~ S2 S1 SU Stufe 1: Phase Verbreitung von Datenoperanden
    Figure 01080001
    wobei „bus" sich auf OprndInfo_SUsrcSt bezieht.
  • Das Übereinstimmungssignal wird dann in einem Pipeline Registerbit in jedem Eintrag verriegelt:
    if SUAdv2) OprndMatch_SusrcSt
    "match with operand SUsrcSt"
  • SU Stufe 2: Phase Operandenauswahl
  • Die Bit Level Abtastungsgleichungen:
    ~P = K = OprndMatch_SUsrcSt
    G = SU ~ S3 S2
  • Die Abtastungsgleichungen auf Gruppenebene sind dieselben wie Abtastungsgleichungen für eine andere Auswahl von Operanden.
    "Supply OPi result value to SUsrcSt" = SUsrcStchain.CINi SUsrcStchain.Ki
  • SU Stufe 2: Phase Verbreitung von Datenoperanden
  • Freigeben des Treibers in jedem Eintrag des Ablaufplaners:
    Figure 01090001
  • Der über den Bus 555 transferierte Datenoperand Oprnd SUsrcSt wird in ein Pipeline Register an dem Eingang der Speichereinheit 242 eingelesen. Während dieser Phase verwendet die Steuerlogik (nicht gezeigt) den gelesenen Wert des Operandenstatus.
  • ReaOg Zusammenstösse
  • "Normalerweise" schreiten an eine bestimmte verarbeitende Ausführungseinheit ausgegebene Operationen die Pipeline in einer festen Reihenfolge im Hinblick auf andere an diese Pipeline ausgegebene Operationen runter. Wenn eine Operation zum Beispiel in der Stufe 0 aufgehalten wird, wird auch die derzeit zur Ausgabe an diese Pipeline ausgewählte Operation aufgehalten, weil Operationen sich nicht gegenseitig innerhalb einer Verarbeitungspipeline überholen können. Der Ablaufplaner 260 verwaltet im Allgemeinen die Verarbeitungspipelines basierend auf einer Ausgabeauswahl und Verarbeitung in der Reihenfolge.
  • Eine Ausnahme wird gemacht. Wenn eine RegOp in der Stufe 0 einer beliebigen Registereinheit aufgehalten wird wegen einem oder mehreren nicht zur Verfügung stehenden Operandenwerten, dann kann die RegOp aus der Verarbeitungspipeline ausgestoßen werden und in den nicht ausgegebenen Zustand zurück kehren. Dies führt zu einem Zurücksetzen des State Feldes der RegOp auf b0000. Wenn eine RegOp aus der RU Stufe 0 ausgestoßen wird, rückt die folgende für die Ausgabe an dieses Register ausgewählte RegOp in die Stufe 0 vor, unmittelbar den Platz der ausgestoßenen RegOp einnehmend. Gleichzeitig wird die ausgestoßene RegOp unmittelbar auswählbar für eine erneute Auswahl an eine Registereinheit, nicht notwendigerweise die gleiche Registereinheit.
  • Ausstoßen ist auf alle RegOps anwendbar und unterliegt den folgenden Beschränkungen. Zuerst kann eine nur RUX RegOp (in der RUX Stufe 0) nicht ausgestoßen werden, wenn eine nur RUX RegOp derzeit zur Ausgabe an RUX ausgewählt wird, weil das Ausstoßen die Garantie verletzen würde, dass nur RUX RegOps in Reihenfolge im Hinblick aufeinander ausgeführt werden. Zweitens sollte eine RegOp nur ausgestoßen werden, wenn sie für mehr als einen Takt aufgehalten wird, anderenfalls ist es im Allgemeinen besser, die RegOp in der Stufe 0 zu lassen, wartend auf das Vorrücken in die Stufe 1. Die obigen Gleichungen, welche die S1 State Bits der Einträge zeigen, implementieren das Ausstoßen von RegOps. Des weiteren erzeugt die globale Steuerlogik (nicht gezeigt) die globalen Ausstoßsignale (BumpRUX und BumpRUY), welche das Anlegen der RUXadv0 und RUYAdv0 Signale erzwingt.
  • Behandlung von Status Flags
  • Die Behandlung und Verwendung von Status Flags, sowohl x86 architekturalen Flags und mikro-architekturalen Flags, umfasst drei Gebiete von Funktionalität: das Holen von Status Flag Operandenwerten für cc-dep RegOps, das Holen von Status Flag Werten für die Auflösung von BRCOND Operationen und die Synchronisierung nicht abbrechbarer RegOps mit vorher gehenden BRCOND Operationen. Anders als Logik (nicht gezeigt) für Registeroperanden und zum Ordnen von LdOp-Stop ist eine Logik (nicht gezeigt) zum Unterstützen von Status Flag Funktionen nicht über alle Einträge des Ablaufplaners ausgebreitet. Die Behandlung von Status Flags für verwandte Operationen tritt nur auf, während Operationen, die auf Status Flags zugreifen, innerhalb gewisser Op Quad Einträge sind. Cc-dep RegOps müssen sich in dem RegOp Eintrag 3 befinden, dem mittleren Op Quad Eintrag in dem Reservoir des Ablaufplaners 940, während des Taktes, wenn das Holen des Statusoperanden geschieht (das heißt während der RUX Stufe 0). BRCOND Operationen und nicht abbrechbare RegOps müssen in dem Op Quad Eintrag 4 sein während der Auflösung durch die Verzweigungseinheit 252 beziehungsweise RUX Stufe 0.
  • Cc-dep und nicht abbrechbare RegOps werden in der RUX Stufe 0 aufgehalten, falls sie noch nicht in den Op Quad Eintrag 3 beziehungsweise 4 runter geschoben worden sind. Umgekehrt wird das Schieben von Op Quads im Ablaufplaner verhindert bis solche Operationen erfolgreich fähig sind, in die RUX Stufe 1 vorzurücken. Die Beschränkungen erlauben es der Logik 535 einfacher und kleiner zu sein. Zum Beispiel tritt das Holen von entsprechenden Status Flag Werten für cc-dep RegOps und BRCOND Operationen nur über den untersten drei Op Quad Einträgen des Ablaufplaners auf und kann unabhängig für jede der vier Gruppen von Status Flags, die den vier Stat-Mod Bits einer Operation entsprechen, ausgeführt werden. Die Logik kann geteilt werden oder sowohl für das Holen von Statusoperanden für cc-dep RegOps als auch für die Auflösung von BRCOND Operationen verwendet werden, und die Synchronisierung zwischen nicht abbrechbaren RegOps und BRCOND Operationen wird vereinfacht.
  • Des weiteren wird die Übergabe von Status Flag Werten direkt von jeder RegOp Ausführungseinheit zu einer die RUX Ausführungseinheit betretenden cc-dep RegOp nicht unterstützt. Das Ergebnis ist eine minimale Latenz von einem Takt zwischen der Ausführung einer ".cc" RegOp und der Ausführung einer folgenden cc-abhängigen RegOp. Der statistische Einfluss dieser Latenz auf die Leistungsfähigkeit ist minimal, weil cc-abhängige RegOps selten in aufeinander folgender Reihenfolge auftreten. Darüber hinaus kann der Einfluss eliminiert werden durch Emcode und MacDec Umordnungsoperationen zum Eliminieren von aufeinander folgenden cc-abhängigen RegOps.
  • Um die Vereinfachung und Reduzierung der Logik weiter zu unterstützen, werden eine Anzahl von Beschränkungen dort auferlegt, wo cc-dep RegOps, BRCOND Operationen und nicht abbrechbare RegOps relativ zueinander in Op Quads auftreten können. Dies übersetzt sich allgemein in Emcode Kodierungsregeln, aber in einigen Fällen wird auch die MacDec Dekodierung von mehreren mI's in einem Takt beschränkt. Insbesondere sind die Beschränkungen wie folgt:
    • 1) Keine ".cc" RegOps nach einer BRCOND Operation.
    • 2) Keine cc-dep RegOps nach einer ".cc" RegOp.
    • 3) Keine nicht abbrechbare RegOp in einem Quad mit einer BRCOND Operation.
    • 4) Nur eine cc-dep RegOp innerhalb eines Op Quads.
    • 5) Nur eine BRCOND Operation innerhalb eines Op Quads.
    • 6) Nur eine nicht abbrechbare RegOp innerhalb eines Op Quads.
  • Weiterleitung des Status an cc-dep RegOps
  • Während jedes Taktes werden die vier Operationen in dem Op Quad Eintrag 3 untersucht, um festzustellen, ob eine von diesen eine cc-dep RegOp ist. Falls eine ist, wird dann der bestimmte Typ der RegOp dekodiert, um zu bestimmen, welche Gruppen von Status Flags benötigt werden und die StatusV Bits werden überprüft, um festzustellen, ob alle von diesen Gruppen tatsächlich gültig sind. Gleichzeitig wird Status [7 : 0] blind an die RUX Ausführungseinheit übergeben.
  • Falls alle der erforderlichen Flag Gruppen gültig sind, wird dann der RegOp erlaubt, in die RUX Stufe 1 vorzurücken, zumindest soweit das Holen der Statusoperanden betroffen ist. Falls jedoch die RegOp nicht unmittelbar in die Stufe 1 vorrückt, dann wird das Schieben der Op Quad Einträge 3 bis 6 verhindert. Falls eine der erforderlichen Flag Gruppen derzeit nicht gültig ist, wird dann die RegOp davon abgehalten, in die RUX Stufe 1 vorzurücken, und das Schieben der Op Quad Einträge 3 bis 6 wird verhindert.
  • Falls keine nicht ausgeführte cc-dep RegOp in den Op Quad Einträgen 3 bis 6 ist, aber eine cc-dep RegOp in der RUX Stufe 0 ist, dann wird die RegOp ohne Bedingung in der Stufe 0 aufgehalten. Falls eine cc-dep RegOp in dem Op Quad Eintrag 3 noch nicht ausgeführt hat, aber keine cc-dep RegOp in der RUX Stufe 0 ist oder dort eine nicht aus geführte cc-dep RegOp in den Op Quad Einträgen 4 bis 6 ist, dann wird das Schieben der Op Quad Einträge 3 bis 6 verhindert.
  • Es gibt einen zusätzlichen Eingang von der RUX Einheit (RUX_NoStatMod), der anzeigt, dass die dort ausgeführte Operation die Status Flags nicht verändert. Eine taktverzögerte Version, genannt "NoStatMod", ist in verschiedenen Situationen hilfreich. Die folgenden Gleichungen beschreiben diese Logik.
  • Figure 01140001
  • Figure 01150001
  • Behandlung Auflösung BRCOND
  • Während jedes Taktes wird der Op Quad Eintrag 4 auf eine BRCOND Operation überprüft. Falls eine gefunden wird, wird dann das Bedingungscode (cc) Feld von diesem Eintrag dekodiert, um eine der 32 Kombinationen der Bedingungswerte und dazu gehörigen Gültig Bits auszuwählen. Der Wert und die Gültigkeit der ausgewählten Bedingung wird dann verwendet, um den Ablaufplaner daran zu hindern, die Quad Einträge 4 bis 6 zu schieben und/oder Pipeline Neustartsignale, falls notwendig, auszugeben.
  • Falls eine BRCOND Operation als falsch vorher gesagt gefunden wurde (und daher ein Neustart der Pipeline notwendig ist), wird das Neustart Signal ausgegeben basierend darauf, ob die BRCOND Operation eine "MacDec" oder Emcode Operation ist und ob sie vom internen oder externen Emcode ist. Des weiteren werden ein geeigneter x86 Makrobefehl oder Emcode Einsprungadresse und ein dazu gehöriger Wert für den Rückkehradressenstapel TOS erzeugt.
  • Für den Nutzen der Logik, welche die Synchronisierung zwischen nicht abbrechbaren RegOps und voran gehenden BRCOND Operationen (in dem nächsten Abschnitt beschrieben) handhabt, wird auch eine Aufzeichnung unterhalten von dem Auftreten einer falsch vorher gesagten BRCOND Operation, während sie ausstehend verbleibt (das heißt bis ein Abbruchzyklus auftritt). Des weiteren wird die Existenz einer ausstehenden, falsch vorher gesagten BRCOND Operation verwendet, um das Laden von "neuen" Op Quads (von dem "neu gestarteten" MacDec) aufzuhalten bis der Abbruchzyklus auftritt.
  • Falls eine BRCOND Operation korrekt vorher gesagt wurde, ist die einzig unternommene Aktion das Setzen des State Bits S3 der BRCOND Operation, um anzuzeigen, dass die BRCOND abgeschlossen ist.
  • Die folgenden Gleichungen beschreiben diese komplette Logik. Bezug wird genommen auf "DTF" und "SSTF" Signale – dies sind Signale, die Breakpoint- beziehungsweise Einzelschrittfallen anzeigen. Es gibt auch ein Signal mit der Bezeichnung "MDD" für "mehrfache Dekodierungsunfähigkeit", das zum Debuggen verwendet werden kann, um zu verhindern, dass mehr als ein Makrobefehl zu einem Zeitpunkt in den Ablaufplaner eingefügt wird.
  • Figure 01160001
  • Figure 01170001
  • Figure 01180001
  • Figure 01190001
  • Figure 01200001
  • Eine erfolgreich aufgelöste BRCOND Operation kann für mehr als einen Zyklus in dem Op Quad Eintrag 4 bleiben, weil die Op Quad Einträge 5 und 6 nicht fähig zum Schieben sind, und damit Op Quad Eintrag 4 daran hindern, runter zu schieben. Während dieser Zeit SC_Resolve = 1 und eines der Signale BrVec2XXX auf den Bussen 557 bleibt für die gesamte Zeit angelegt (im Gegensatz zu nur dem ersten Zyklus). Dies ist in Ordnung, weil der Befehlsdekodierer 220 jeden Takt an dem Neustarten festhält, bis das Signal BrVec2XXX ausschaltet. Alle anderen zusammenhängenden Signale, wie die Einsprungadresse, behalten während dieser Zeit richtige Werte.
  • Synchronisation nicht abbrechbarer RegOps
  • Während jedes Takts wird der Op Quad Eintrag 4 auf eine nicht abbrechbare RegOp geprüft. Falls eine gefunden wird, überprüft dann der Ablaufplaner 260 auf eine beliebige voran gehende falsch vorher gesagte BRCOND Operationen. Wegen der Beschränkungen Befehlsinformation der Emcode Kodierung, müssen jegliche voran gehende BRCOND Operationen in einem niedrigeren Op Quad Eintrag sein und damit müssen alle aufgelöst worden sein. Des weiteren wird garantiert, dass jede BRCOND Operation, die zur Zeit aufgelöst wird, nach die nicht abbrechbare RegOp fällt und damit irrelevant ist.
  • Falls keine derartigen falsch vorher gesagten BRCOND Operationen existie- ren, wird dann der RegOp erlaubt, in die RUX Stufe 1 vorzurücken. Falls die RegOp nicht unmittelbar in die Stufe 1 vorrückt, wird ihr immer noch erlaubt, aus dem Op Quad Eintrag 4 rauszuschieben.
  • Falls die Op Quad Einträge 4 oder 5 keine nicht ausgeführte nicht abbrechbare RegOp enthält, aber eine nicht abbrechbare RegOp in der RUX Stufe 0 ist, wird die nicht abbrechbare RegOp ohne Bedingung in der Stufe 0 aufgehalten und die nicht abbrechbare RegOp erreicht Op Quad Eintrag 4. Falls eine nicht abbrechbare RegOp in dem Op Quad Eintrag 4 ist, die noch nicht ausgeführt hat; aber keine nicht abbrechbare RegOp in der RUX Stufe 0 ist oder dort eine nicht ausgeführte nicht abbrechbare RegOp in dem Op Quad Eintrag 5 ist, dann wird das Schieben der Op Quad Einträge 4 und 5 verhindert.
  • Die folgenden Gleichungen beschreiben diese Logik:
  • Figure 01210001
  • Figure 01220001
  • Der superskalare Prozessor 120 kann in eine breite Vielzahl von Systemkonfigurationen eingearbeitet werden, beispielhaft in Einzelplatz- oder im Netzwerk befindliche Personal Computersysteme, Workstation Systeme, Multimediasysteme, Netzwerkserversysteme, Multiprozessorsysteme, eingebettete Systeme, integrierte Telefoniesysteme, Videokonferenzsysteme usw. 10 stellt einen beispielhaften Satz von geeigneten Systemkonfigurationen für einen Prozessor, wie einen superskalaren Prozessor 120, dar, der einen Befehlsdekodierer hat, welcher einen RISC86 Befehlssatz verwendet. Insbesondere stellt 10 eine geeignete Kombination von einem superskalaren Prozessor dar, der einen Befehlsdekodierer hat, welcher einen RISC86 Befehlssatz verwendet, mit geeigneten Buskonfigurationen, Speicherhierarchien und Cachespeicherkonfigurationen, I/O Schnittstellen, Steuerungen, Geräten und peripheren Komponenten. Während die Erfindung im Hinblick auf verschiedene Ausführungsbeispiele beschrieben worden ist, ist zu verstehen, dass diese Ausführungsbeispiele beispielhaft sind und dass der Umfang der Erfindung nicht auf diese beschränkt ist. Viele Variationen, Modifikationen, Zusätze und Verbesserungen dieser beschriebenen Ausführungsbeispiele sind möglich. Darüber hinaus können Strukturen und Funktionalitäten, die in dem beispielhaften Ausführungsbeispiel als Hardware dargestellt wurden, in alternativen Ausführungsbeispielen als Software, Firmware oder Mikrocode implementiert sein. Zum Beispiel stellt die Beschreibung einen Makrobefehl Dekodieren dar, der Kurzdekodierpfade hat, einschließlich drei Rotatoren 430, 432 und 434, drei Befehlsregistern 450, 452 und 454 und drei Kurzdekodierer SDec0 410, SDec1 412 und SDec2 414. In anderen Ausführungsbeispielen werden andere Anzahlen von Kurzdekodierpfaden verwendet. Ein Dekodieren, der zwei Dekodierpfade verwendet, ist höchst geeignet. Diese und andere Variationen, Modifikationen, Zusätze und Verbesserungen können in den Umfang der Erfindung fallen, wie sie in den folgenden Ansprüchen definiert ist.

Claims (32)

  1. Superskalarer Mikroprozessor (120) mit: einer Quelle für CISC-ähnliche Befehle (214); und einen RISC-ähnlichen Prozessorkern zum parallelen Ausführen mehrerer RISC-ähnlichen Operationen; gekennzeichnet durch einen Dekodieren (220), der die Quelle für CISC-ähnliche Befehle mit dem RISC-ähnlichen Prozessorkern koppelt, wobei der Dekodieren (220) zum Konvertieren von CISC-ähnlichen Befehlen in Operationen eines RISC-ähnlichen Befehlssatzes aufweist: mehrere Befehlscodes mit einheitlichen Bitlängen, wobei der Code in mehrere Bitfelder für eine definierte Verwendung unterteilt ist und die Codes in mehrere Befehlsklassen klassifiziert sind, wobei jeder Code in einer Befehlsklasse eine für sämtliche Codes einheitliche Definition der Bitfelder für eine definierte Verwendung enthält, einschließlich eines Bitfelds, das unter Verwendung indirekter Spezifizieren abgebildet wird, so dass ein einzelner Befehlscode mit einheitlicher Bitlänge in mehrere Befehlsversionen abbildet.
  2. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die Befehlsklassen umfassen: eine Registeroperations- (RegOp-) Klasse, die arithmetische Operationen, Verschiebeoperationen und Bewegungsoperationen und Bitfelder für eine definierte Verwendung umfasst, einschließlich eines Operationstypfelds, drei Operandenbitfeldern zum Bestimmen eines ersten Quellenoperanden, eines zweiten Quellenoperanden und eines Zieloperanden und eines Bitfelds zum Bestimmen der Datengröße der Operanden.
  3. Superskalarer Mikroprozessor nach Anspruch 2, bei dem die RegOp-Klasse ferner eine Operation umfasst, die ein oder mehrere Status-Flags modifiziert, wobei die RegOp-Klasse ferner Bitfelder für eine definierte Verwendung umfasst, welche aufweisen: ein Erweiterungs-Bitfeld zum Spezifizieren des einen oder der mehreren Status-Flags, die durch die Operation modifiziert werden; und ein Setz-Status-Bitfeld zum Bewirken der Operation zum Modifizieren der Status-Flags gemäß dem Erweiterungs-Bitfeld.
  4. Superskalarer Mikroprozessor nach Anspruch 2, bei dem die RegOp-Klasse ferner Operationen zum Lesen und Schreiben spezieller Register und Bitfelder für eine definierte Verwendung umfasst, welche aufweisen: ein Erweiterungs-Bitfeld zum Spezifizieren eines Bedingungscodes für einen bedingten Bewegungsbefehl und zum Spezifizieren eines speziellen Registers, das durch die Operationen zum Lesen und Schreiben spezieller Register gelesen und geschrieben wird.
  5. Superskalarer Mikroprozessor nach Anspruch 2, bei dem die RegOp-Klasse ferner Bitfelder für eine definierte Verwendung umfasst, welche aufweisen: ein Bitfeld zum Bestimmen einer Ausführungseinheit zum Ausführen einer Operation.
  6. Superskalarer Mikroprozessor nach Anspruch 2, bei dem die RegOp-Klasse von Operationen eine Operation zum Lesen und Schreiben eines Programmzählers zum Umleiten einer Prozessorausführung umfasst.
  7. Superskalarer Mikroprozessor nach Anspruch 2, bei dem die RegOp-Klasse von Operationen eine Prüfselektoroperation (CHKS) zum gleichzeitigen Überprüfen eines Speichersegments auf Zugriffserlaubnis und Laden des Selektors bei Erteilung der Erlaubnis umfasst.
  8. Superskalarer Mikroprozessor nach Anspruch 2, bei dem die RegOp-Klasse von Operationen umfasst: eine Schreib-Beschreiben-Real (WRDR-) Operation zum Laden eines Segmentregisters in einem Real-Modus; eine Schreib-Beschreiben-Schutzmodus-High- (WRDH-) Operation und eine Schreib-Beschreiben-Schutzmodus-Low- (WRDL-) Operation zum Durchführen einer Sequenz von Prüfoperationen zum Überprüfen von Datensegmenten und eines I/O-Adressenraums als Emulationscodesequenz von Hardware-Grundoperationen.
  9. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die indirekten Spezifizieren einen Befehlsparameter spezifizieren, der aus Parametern, einschließlich eines Operationsregisters, einer Datengröße und einer Adressengröße, ausgewählt ist.
  10. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die Befehlsklassen umfassen: eine Lade-/Speicheroperations- (LdStOp-) Klasse, die Lade- und Speicheroperationen und Bitfelder für eine definierte Verwendung umfasst, einschließlich eines Operationstypfelds, mehrerer Bitfelder zum Bestimmen einer Lade-/Speicheradresse im Speicher, eines Bitfelds zum Bestimmen eines Datenquellen-/-zielregisters zum Ausgeben/Empfangen von Daten von der Lade-/Speicheradresse im Speicher und eines Bitfelds zum Bestimmen der Datengröße der Quellen/Zieldaten.
  11. Superskalarer Mikroprozessor nach Anspruch 10, bei dem die mehreren Bitfelder zum Bestimmen einer Lade-/Speicheradresse im Speicher in der LdStOp-Klasse umfasst: ein Segmentregister zum Bestimmen eines Speichersegments der Lade-/Speicheradresse; ein Basisregister zum Bestimmen einer Basis der Lade-/Speicher-Speicheradresse; ein Indexregister zum Bestimmen eines Speicherindex; und ein Index-Skalenfaktor-Bitfeld zum Bestimmen eines Index-Skalenfaktors.
  12. Superskalerer Mikroprozessor nach Anspruch 11, bei dem die LdStOp-Klasse von Operationen eine Prüfdaten-Effektivadressen- (CDA-) Operation umfasst.
  13. Superskalarer Mikroprozessor nach Anspruch 11, bei dem die LdStOp-Klasse von Operationen eine Prüfbefehl-Effektivadressen- (CIA-) Operation umfasst.
  14. Superskalarer Mikroprozessor nach Anspruch 11, bei dem die LdStOp-Klasse von Operationen Ganzzahlenspeicherdaten mit einer Basisregister-Update- (STUPD-) Operation umfasst.
  15. Superskalarer Mikroprozessor nach Anspruch 11, bei dem die LdStOp-Klasse von Operationen eine Operation zum Invalidieren einer TLB-Adresse (TIA) umfasst.
  16. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die Befehlsklassen umfassen: eine Ladeoperations- (LdOp-) Klasse, die Ladeoperationen und Bitfelder für eine definierte Verwendung umfasst, einschließlich eines Operationstypfelds, mehrerer Bitfelder zum Bestimmen einer Quellenadresse im Speicher, eines Bitfelds zum Bestimmen eines Zielregisters zum Empfangen von Daten von der Quellenadresse im Speicher und eines Bitfelds zum Bestimmen der Datengröße der Quellen-/Zieldaten.
  17. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die Befehlsklassen umfassen: eine Speicheroperations- (StOp-) Klasse, die Speicheroperationen und Bitfelder für eine definierte Verwendung umfassen, einschließlich eines Operationstypfelds, mehrerer Bitfelder zum Bestimmen einer Speicheradresse im Speicher, eines Bitfelds zum Bestimmen eines Datenquel lenregisters zum Ausgeben von Daten aus dem Speicherregister und eines Bitfelds zum Bestimmen der Datengröße der Quellen-/Zieldaten.
  18. Superskalarer Mikroprozessor nach Anspruch 1, bei dem der Befehlssatz ferner eine Direktladeoperationsklasse (LIMMOp) mit Bitfeldern für eine definierte Verwendung umfasst, welche aufweisen: ein Direktdaten-High- (ImmHi-) Bitfeld und ein Direktdaten-Low(ImmLo-) Bitfeld zum Bestimmen des Direktdatenwerts; und ein Bitfeld zum Bestimmen eines Datenzielregisters zum Empfangen von Daten von der Lade-/Speicheradresse im Speicher.
  19. Superskalarer Mikroprozessor nach Anspruch 1, bei dem der Befehlssatz ferner eine Spezialoperationsklasse (SpecOp) mit einer bedingten Verzweigungsoperation, einer Setzvorgabe-Fehlerroutinen-Adressenoperation, einer Setzalternier-Fehlerroutinen-Adressenoperation und einer unbedingten Fehleroperation und Bitfeldern für eine definierte Verwendung umfasst, welche aufweisen: ein Bitfeld zum Bestimmen eines Bedingungscodes; und ein Direktdatenbitfeld zum Bestimmen eines vorzeichenbehafteten Direktdatenwerts.
  20. Superskalarer Mikroprozessor nach Anspruch 19, bei dem die Spezialoperationsklasse (SpecOp) ferner eine Konstantladeoperation umfasst und die Bitfelder für eine definierte Verwendung ferner umfassen: ein Bitfeld zum Bestimmen eines Datenzielregisters; und ein Bitfeld zum Bestimmen der Datengröße von Konstantdaten.
  21. Superskalarer Mikroprozessor nach Anspruch 19, bei dem die SpecOp-Klasse von Operationen eine Operation zum Laden einer Konstanten (LDK) umfasst.
  22. Superskalarer Mikroprozessor nach Anspruch 19, bei dem die SpecOp-Klasse von Operationen eine Operation zum Laden von Konstantdaten (LDKD) umfasst.
  23. Superskalarer Mikroprozessor nach Anspruch 1, bei dem das einer Operation zugehörige Bitfeld für eine definierte Verwendung durch einen Ersatzwert bestimmt ist, der von einer Emulationsumgebung des Prozessors (120) festgelegt ist.
  24. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die mehreren Befehlscodes in einer Struktur mit fester Bitlänge angeordnet sind, wobei die Struktur in mehrere Bitfelder für eine definierte Verwendung unterteilt ist, die Befehlscodes mehrere Operations- (Op-) Formate der mehreren Bitfelder für eine definierte Verwendung aufweisen und die Formate umfassen: ein erstes Register-Op-Format mit einem Format-Bitfeld, das den Befehlscode als einen ersten Register-Op-Formatcode bestimmt, ein Typ-Bitfeld, das einen Befehlstyp bestimmt, ein Bitfeld für einen ersten Quellenoperanden, das einen ersten Quellenoperanden identifiziert, ein Bitfeld für einen zweiten Quellenoperanden, das einen zweiten Quellenoperanden identifiziert, ein Ziel-Bitfeld, das einen Zieloperanden bestimmt, und ein Operandengrößen-Bitfeld, das eine Operanden- Bytegröße bestimmt; ein Lade-/Speicher-Op-Format mit einem Format-Bitfeld, das einen Befehlscode als einen Lade-/Speicher-Op-Formatcode bestimmt, ein Typ-Bitfeld, das einen Lade-/Speicherbefehlstyp bestimmt, ein Daten-Bitfeld, das eine Ziel-Quelle einer Lade-/Speicheroperation identifiziert, ein Index-Skalenfaktor-Bitfeld zum Bestimmen eines Index-Skalenfaktors, ein Segment-Bitfeld zum Bestimmen eines Segmentregisters, ein Basis-Bitfeld zum Bestimmen einer Lade/Speicherbasisadresse, ein Verschiebe-Bitfeld zum Bestimmen einer Lade-/Speicheradressenverschiebung und ein Index-Bitfeld zum Bestimmen eines Lade-/Speicheradressenindex.
  25. Superskalarer Mikroprozessor nach Anspruch 24, bei dem das erste Register-Op-Format ferner umfasst: ein Erweiterungs-Bitfeld zum Bestimmen eines Bedingungscodes.
  26. Superskalarer Mikroprozessor nach Anspruch 24, bei dem ein Bitfeld des Befehlscodes in das Op-Format ersetzt ist, wobei das Ersatz-Bitfeld als eine Funktion des Kontextes des Prozessors (120) festgelegt ist.
  27. Superskalarer Mikroprozessor nach Anspruch 1, bei dem die Befehlsklassen umfassen: eine Registeroperations- (RegOp-) Klasse, die arithmetische Operationen, Verschiebeoperationen und Bewegungsoperationen und Bitfelder für eine definierte Verwendung umfasst, einschließlich eines Operationstypfelds, drei Operandenbitfeldern zum Bestimmen eines ersten Quellenoperanden, eines zweiten Quellenoperanden und eines Zieloperanden und eines Bitfelds zum Bestimmen der Datengröße der Operanden; und eine Lade-/Speicheroperations- (LdStOp-) Klasse, die Lade- und Speicheroperationen und Bitfelder für eine definierte Verwendung umfasst, einschließlich eines Operationstypfelds, mehrerer Bitfelder zum Bestimmen einer Lade-/Speicheradresse im Speicher, eines Bitfelds zum Bestimmen eines Datenquellen-/-zielregisters zum Ausgeben/Empfangen von Daten von der Lade-/Speicheradresse im Speicher und eines Bitfelds zum Bestimmen der Datengröße der Quellen-/Zieldaten.
  28. Superskalarer Mikroprozessor nach Anspruch 27, bei dem die Befehlssatz-RegOp-Klasse ferner eine Operation umfasst, die ein oder mehrere Status-Flags modifiziert, wobei die RegOp-Klasse ferner Bitfelder für eine definierte Verwendung umfasst, welche aufweisen: ein Erweiterungs-Bitfeld zum Spezifizieren des einen oder der mehreren Status-Flags, die durch die Operation modifiziert werden; und ein Setz-Bitfeld zum Bewirken der Operation zum Modifizieren der Status-Flags gemäß dem Erweiterungs-Bitfeld.
  29. Superskalarer Mikroprozessor nach Anspruch 27, bei dem der Befehlssatz ferner eine Direktladeoperationsklasse (LIMMOp) mit Bitfeldern für eine definierte Verwendung umfasst, welche aufweisen: ein Direktdaten-High- (ImmHi-) Bitfeld und ein Direktdaten-Low(ImmLo-) Bitfeld zum Bestimmen des Direktdatenwerts; und ein Bitfeld zum Bestimmen eines Datenzielregisters zum Empfangen von Daten von der Lade-/Speicheradresse im Speicher.
  30. Superskalarer Mikroprozessor nach Anspruch 27, bei dem der Befehlssatz ferner eine Spezialoperationsklasse (SpecOp) mit einer bedingten Verzweigungsoperation, einer Setzvorgabe-Fehlerroutinen-Adressenoperation, einer Setzalternier-Fehlerroutinen-Adressenoperation und einer unbedingten Fehleroperation und Bitfeldern für eine definierte Verwendung umfasst, welche aufweisen: ein Bitfeld zum Bestimmen eines Bedingungscodes; und ein Direktdatenbitfeld zum Bestimmen eines vorzeichenbehafteten Direktdatenwerts.
  31. Superskalarer Mikroprozessor nach Anspruch 1, bei dem der Dekodieren einen Emulations-ROM und einen mit dem Emulations-ROM gekoppelten Emulationssequenzer aufweist, wobei der Dekodierer komplexe CISC-Befehle gemäß einer ausgewählten Emulationsumgebung dekodiert, und bei dem die indirekten Spezifizieren auf der Basis der ausgewählten Emulationsumgebung initialisiert werden.
  32. Computersystem (100) mit: einem Speicherteilsystem (122,124,130), in dem Daten und Befehle gespeichert werden; und einem Prozessor (120) nach einem der vorhergehenden Ansprüche, der zum Zugreifen auf die in dem Speicherteilsystem gespeicherten Daten und Befehle vorgesehen ist.
DE69629383T 1995-10-06 1996-10-04 Superskalarer mikroprozessor mit risc86 befehlssatz Expired - Lifetime DE69629383T2 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US592151 1984-03-22
US506995P 1995-10-06 1995-10-06
US5069P 1995-10-06
US502195P 1995-10-10 1995-10-10
US5021P 1995-10-10
US59215196A 1996-01-26 1996-01-26
US649983 1996-05-16
US08/649,983 US5926642A (en) 1995-10-06 1996-05-16 RISC86 instruction set
PCT/US1996/015422 WO1997013194A1 (en) 1995-10-06 1996-10-04 Risc86 instruction set

Publications (2)

Publication Number Publication Date
DE69629383D1 DE69629383D1 (de) 2003-09-11
DE69629383T2 true DE69629383T2 (de) 2004-06-09

Family

ID=27485438

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69629383T Expired - Lifetime DE69629383T2 (de) 1995-10-06 1996-10-04 Superskalarer mikroprozessor mit risc86 befehlssatz

Country Status (7)

Country Link
US (2) US5926642A (de)
EP (1) EP0853780B1 (de)
JP (1) JP3714962B2 (de)
KR (1) KR100513358B1 (de)
AU (1) AU7246596A (de)
DE (1) DE69629383T2 (de)
WO (1) WO1997013194A1 (de)

Families Citing this family (123)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5828875A (en) * 1997-05-29 1998-10-27 Telefonaktiebolaget Lm Ericsson Unroll of instructions in a micro-controller
US6016544A (en) * 1997-06-09 2000-01-18 Ip First Llc Apparatus and method for tracking changes in address size and for different size retranslate second instruction with an indicator from address size
US6289437B1 (en) * 1997-08-27 2001-09-11 International Business Machines Corporation Data processing system and method for implementing an efficient out-of-order issue mechanism
US8621101B1 (en) 2000-09-29 2013-12-31 Alacritech, Inc. Intelligent network storage interface device
US6226680B1 (en) 1997-10-14 2001-05-01 Alacritech, Inc. Intelligent network interface system method for protocol processing
US6434620B1 (en) * 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US8782199B2 (en) 1997-10-14 2014-07-15 A-Tech Llc Parsing a packet header
US6757746B2 (en) 1997-10-14 2004-06-29 Alacritech, Inc. Obtaining a destination address so that a network interface device can write network data without headers directly into host memory
US8539112B2 (en) 1997-10-14 2013-09-17 Alacritech, Inc. TCP/IP offload device
JP3614646B2 (ja) * 1998-03-12 2005-01-26 富士通株式会社 マイクロプロセッサ、演算処理実行方法及び記憶媒体
DE19826826A1 (de) * 1998-06-16 1999-07-15 Siemens Ag Verfahren zum Decodieren und Ausführen von Befehlen in einem RISC-Prozessor
US6292845B1 (en) * 1998-08-26 2001-09-18 Infineon Technologies North America Corp. Processing unit having independent execution units for parallel execution of instructions of different category with instructions having specific bits indicating instruction size and category respectively
US6195747B1 (en) * 1998-09-28 2001-02-27 Mentor Arc Inc. System and method for reducing data traffic between a processor and a system controller in a data processing system
US6212631B1 (en) * 1999-01-15 2001-04-03 Dell Usa, L.P. Method and apparatus for automatic L2 cache ECC configuration in a computer system
US6463521B1 (en) * 1999-06-23 2002-10-08 Sun Microsystems, Inc. Opcode numbering for meta-data encoding
US6990658B1 (en) * 1999-10-13 2006-01-24 Transmeta Corporation Method for translating instructions in a speculative microprocessor featuring committing state
US6904515B1 (en) * 1999-11-09 2005-06-07 Ati International Srl Multi-instruction set flag preservation apparatus and method
US6539470B1 (en) 1999-11-16 2003-03-25 Advanced Micro Devices, Inc. Instruction decode unit producing instruction operand information in the order in which the operands are identified, and systems including same
US6542984B1 (en) * 2000-01-03 2003-04-01 Advanced Micro Devices, Inc. Scheduler capable of issuing and reissuing dependency chains
US6564315B1 (en) * 2000-01-03 2003-05-13 Advanced Micro Devices, Inc. Scheduler which discovers non-speculative nature of an instruction after issuing and reissues the instruction
US6622235B1 (en) 2000-01-03 2003-09-16 Advanced Micro Devices, Inc. Scheduler which retries load/store hit situations
US6591343B1 (en) * 2000-02-22 2003-07-08 Ip-First, Llc Predecode in parallel with TLB compare
US6526463B1 (en) * 2000-04-14 2003-02-25 Koninklijke Philips Electronics N.V. Dynamically selectable stack frame size for processor interrupts
US6735689B1 (en) * 2000-05-01 2004-05-11 Raza Microelectronics, Inc. Method and system for reducing taken branch penalty
US6791564B1 (en) 2000-05-05 2004-09-14 Ipfirst, Llc Mechanism for clipping RGB value during integer transfer
US7069420B1 (en) * 2000-09-28 2006-06-27 Intel Corporation Decode and dispatch of multi-issue and multiple width instructions
US8019901B2 (en) 2000-09-29 2011-09-13 Alacritech, Inc. Intelligent network storage interface system
US7873814B1 (en) * 2000-12-22 2011-01-18 Lsi Corporation Microcode based hardware translator to support a multitude of processors
US6915416B2 (en) * 2000-12-28 2005-07-05 Texas Instruments Incorporated Apparatus and method for microcontroller debugging
US7181484B2 (en) 2001-02-21 2007-02-20 Mips Technologies, Inc. Extended-precision accumulation of multiplier output
US7162621B2 (en) * 2001-02-21 2007-01-09 Mips Technologies, Inc. Virtual instruction expansion based on template and parameter selector information specifying sign-extension or concentration
US7711763B2 (en) 2001-02-21 2010-05-04 Mips Technologies, Inc. Microprocessor instructions for performing polynomial arithmetic operations
US6986025B2 (en) * 2001-06-11 2006-01-10 Broadcom Corporation Conditional execution per lane
US7017032B2 (en) * 2001-06-11 2006-03-21 Broadcom Corporation Setting execution conditions
US7127593B2 (en) * 2001-06-11 2006-10-24 Broadcom Corporation Conditional execution with multiple destination stores
US7861071B2 (en) * 2001-06-11 2010-12-28 Broadcom Corporation Conditional branch instruction capable of testing a plurality of indicators in a predicate register
US7383421B2 (en) * 2002-12-05 2008-06-03 Brightscale, Inc. Cellular engine for a data processing system
US7389315B1 (en) * 2002-02-28 2008-06-17 Network Appliance, Inc. System and method for byte swapping file access data structures
US7260217B1 (en) * 2002-03-01 2007-08-21 Cavium Networks, Inc. Speculative execution for data ciphering operations
US7543087B2 (en) 2002-04-22 2009-06-02 Alacritech, Inc. Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device
US20040139299A1 (en) * 2003-01-14 2004-07-15 International Business Machines Corporation Operand forwarding in a superscalar processor
US7103754B2 (en) * 2003-03-28 2006-09-05 International Business Machines Corporation Computer instructions for having extended signed displacement fields for finding instruction operands
US7171653B2 (en) * 2003-06-03 2007-01-30 Hewlett-Packard Development Company, L.P. Systems and methods for providing communication between a debugger and a hardware simulator
US7185167B2 (en) * 2003-06-06 2007-02-27 Microsoft Corporation Heap allocation
GB2402763B (en) * 2003-06-13 2006-03-01 Advanced Risc Mach Ltd Data access program instruction encoding
US7321964B2 (en) * 2003-07-08 2008-01-22 Advanced Micro Devices, Inc. Store-to-load forwarding buffer using indexed lookup
US7996671B2 (en) * 2003-11-17 2011-08-09 Bluerisc Inc. Security of program executables and microprocessors based on compiler-architecture interaction
DE102004025419A1 (de) * 2004-05-24 2005-12-22 Infineon Technologies Ag Controller und Verfahren zum Verarbeiten von Befehlen
DE102004025418A1 (de) * 2004-05-24 2005-12-22 Infineon Technologies Ag Controller mit einer Decodiereinrichtung
US8248939B1 (en) 2004-10-08 2012-08-21 Alacritech, Inc. Transferring control of TCP connections between hierarchy of processing mechanisms
US20060174089A1 (en) * 2005-02-01 2006-08-03 International Business Machines Corporation Method and apparatus for embedding wide instruction words in a fixed-length instruction set architecture
JP4841861B2 (ja) * 2005-05-06 2011-12-21 ルネサスエレクトロニクス株式会社 演算処理装置及びデータ転送処理の実行方法
US20060282821A1 (en) * 2005-06-10 2006-12-14 Renno Erik K Efficient subprogram return in microprocessors
US7451293B2 (en) * 2005-10-21 2008-11-11 Brightscale Inc. Array of Boolean logic controlled processing elements with concurrent I/O processing and instruction sequencing
US7711990B1 (en) * 2005-12-13 2010-05-04 Nvidia Corporation Apparatus and method for debugging a graphics processing unit in response to a debug instruction
CN101371263A (zh) * 2006-01-10 2009-02-18 光明测量公司 用于在并行处理系统中处理多媒体数据的算法步骤的方法和装置
JP4778359B2 (ja) * 2006-05-17 2011-09-21 エヌイーシーコンピュータテクノ株式会社 エミュレーション方法及びコンピュータシステム
US20080244238A1 (en) * 2006-09-01 2008-10-02 Bogdan Mitu Stream processing accelerator
US20080059763A1 (en) * 2006-09-01 2008-03-06 Lazar Bivolarski System and method for fine-grain instruction parallelism for increased efficiency of processing compressed multimedia data
US20080059764A1 (en) * 2006-09-01 2008-03-06 Gheorghe Stefan Integral parallel machine
US20080059467A1 (en) * 2006-09-05 2008-03-06 Lazar Bivolarski Near full motion search algorithm
US7620797B2 (en) * 2006-11-01 2009-11-17 Apple Inc. Instructions for efficiently accessing unaligned vectors
US7624251B2 (en) * 2006-11-01 2009-11-24 Apple Inc. Instructions for efficiently accessing unaligned partial vectors
KR100730582B1 (ko) 2006-11-20 2007-06-20 아람휴비스(주) 이온토포레시스 장치
US8412981B2 (en) * 2006-12-29 2013-04-02 Intel Corporation Core sparing on multi-core platforms
US20080263171A1 (en) * 2007-04-19 2008-10-23 Alacritech, Inc. Peripheral device that DMAS the same data to different locations in a computer
US7734873B2 (en) * 2007-05-29 2010-06-08 Advanced Micro Devices, Inc. Caching of microcode emulation memory
US7761672B2 (en) * 2007-06-28 2010-07-20 Advanced Micro Devices, Inc. Data movement and initialization aggregation
US20090013124A1 (en) * 2007-07-03 2009-01-08 Dsp Group Limited Rom code patch method
US20090182985A1 (en) * 2008-01-11 2009-07-16 International Business Machines Corporation Move Facility and Instructions Therefore
US8341286B1 (en) 2008-07-31 2012-12-25 Alacritech, Inc. TCP offload send optimization
US9306793B1 (en) 2008-10-22 2016-04-05 Alacritech, Inc. TCP offload device that batches session layer headers to reduce interrupts as well as CPU copies
US9213665B2 (en) 2008-10-28 2015-12-15 Freescale Semiconductor, Inc. Data processor for processing a decorated storage notify
US8627471B2 (en) * 2008-10-28 2014-01-07 Freescale Semiconductor, Inc. Permissions checking for data processing instructions
CN107015926B (zh) * 2010-05-25 2020-08-07 威盛电子股份有限公司 微处理器以及相关的操作方法
US9967092B2 (en) 2010-05-25 2018-05-08 Via Technologies, Inc. Key expansion logic using decryption key primitives
US8700919B2 (en) 2010-05-25 2014-04-15 Via Technologies, Inc. Switch key instruction in a microprocessor that fetches and decrypts encrypted instructions
US9798898B2 (en) 2010-05-25 2017-10-24 Via Technologies, Inc. Microprocessor with secure execution mode and store key instructions
US9892283B2 (en) 2010-05-25 2018-02-13 Via Technologies, Inc. Decryption of encrypted instructions using keys selected on basis of instruction fetch address
US9911008B2 (en) 2010-05-25 2018-03-06 Via Technologies, Inc. Microprocessor with on-the-fly switching of decryption keys
US9146742B2 (en) 2011-04-07 2015-09-29 Via Technologies, Inc. Heterogeneous ISA microprocessor that preserves non-ISA-specific configuration state when reset to different ISA
US9378019B2 (en) 2011-04-07 2016-06-28 Via Technologies, Inc. Conditional load instructions in an out-of-order execution microprocessor
US9043580B2 (en) 2011-04-07 2015-05-26 Via Technologies, Inc. Accessing model specific registers (MSR) with different sets of distinct microinstructions for instructions of different instruction set architecture (ISA)
US9032189B2 (en) 2011-04-07 2015-05-12 Via Technologies, Inc. Efficient conditional ALU instruction in read-port limited register file microprocessor
US9128701B2 (en) 2011-04-07 2015-09-08 Via Technologies, Inc. Generating constant for microinstructions from modified immediate field during instruction translation
US9336180B2 (en) 2011-04-07 2016-05-10 Via Technologies, Inc. Microprocessor that makes 64-bit general purpose registers available in MSR address space while operating in non-64-bit mode
US9274795B2 (en) 2011-04-07 2016-03-01 Via Technologies, Inc. Conditional non-branch instruction prediction
US9645822B2 (en) 2011-04-07 2017-05-09 Via Technologies, Inc Conditional store instructions in an out-of-order execution microprocessor
US9317288B2 (en) * 2011-04-07 2016-04-19 Via Technologies, Inc. Multi-core microprocessor that performs x86 ISA and ARM ISA machine language program instructions by hardware translation into microinstructions executed by common execution pipeline
US9244686B2 (en) 2011-04-07 2016-01-26 Via Technologies, Inc. Microprocessor that translates conditional load/store instructions into variable number of microinstructions
US20120260073A1 (en) * 2011-04-07 2012-10-11 Via Technologies, Inc. Emulation of execution mode banked registers
US9176733B2 (en) * 2011-04-07 2015-11-03 Via Technologies, Inc. Load multiple and store multiple instructions in a microprocessor that emulates banked registers
US9898291B2 (en) 2011-04-07 2018-02-20 Via Technologies, Inc. Microprocessor with arm and X86 instruction length decoders
US8880851B2 (en) 2011-04-07 2014-11-04 Via Technologies, Inc. Microprocessor that performs X86 ISA and arm ISA machine language program instructions by hardware translation into microinstructions executed by common execution pipeline
US9141389B2 (en) 2011-04-07 2015-09-22 Via Technologies, Inc. Heterogeneous ISA microprocessor with shared hardware ISA registers
US9292470B2 (en) 2011-04-07 2016-03-22 Via Technologies, Inc. Microprocessor that enables ARM ISA program to access 64-bit general purpose registers written by x86 ISA program
US9280492B2 (en) * 2013-12-28 2016-03-08 Intel Corporation System and method for a load instruction with code conversion having access permissions to indicate failure of load content from registers
US9563427B2 (en) * 2014-05-30 2017-02-07 International Business Machines Corporation Relative offset branching in a fixed-width reduced instruction set computing architecture
US9547494B2 (en) * 2014-05-30 2017-01-17 International Business Machines Corporation Absolute address branching in a fixed-width reduced instruction set computing architecture
KR101770495B1 (ko) 2014-07-21 2017-08-22 비아 얼라이언스 세미컨덕터 씨오., 엘티디. 공통 상황 항목의 동시 무효화를 지원하는 어드레스 변환 캐시
US10127137B2 (en) * 2015-06-03 2018-11-13 Fengwei Zhang Methods and systems for increased debugging transparency
US9921763B1 (en) 2015-06-25 2018-03-20 Crossbar, Inc. Multi-bank non-volatile memory apparatus with high-speed bus
US10141034B1 (en) 2015-06-25 2018-11-27 Crossbar, Inc. Memory apparatus with non-volatile two-terminal memory and expanded, high-speed bus
US10222989B1 (en) * 2015-06-25 2019-03-05 Crossbar, Inc. Multiple-bank memory device with status feedback for subsets of memory banks
US10877759B2 (en) 2015-09-30 2020-12-29 International Business Machines Corporation Managing the capture of information in applications with prefix instructions
US9870305B2 (en) * 2015-09-30 2018-01-16 International Business Machines Corporation Debugging of prefixed code
US10394568B2 (en) 2015-09-30 2019-08-27 International Business Machines Corporation Exception handling for applications with prefix instructions
US10761852B2 (en) 2015-09-30 2020-09-01 International Business Machines Corporation Extending data range addressing
US10303498B2 (en) 2015-10-01 2019-05-28 Microsoft Technology Licensing, Llc Performance optimizations for emulators
US10620956B2 (en) 2017-03-03 2020-04-14 International Business Machines Corporation Search string processing via inline decode-based micro-operations expansion
US10564965B2 (en) 2017-03-03 2020-02-18 International Business Machines Corporation Compare string processing via inline decode-based micro-operations expansion
US10564967B2 (en) 2017-03-03 2020-02-18 International Business Machines Corporation Move string processing via inline decode-based micro-operations expansion
US10789069B2 (en) 2017-03-03 2020-09-29 International Business Machines Corporation Dynamically selecting version of instruction to be executed
US10324716B2 (en) 2017-03-03 2019-06-18 International Business Machines Corporation Selecting processing based on expected value of selected character
US10613862B2 (en) 2017-03-03 2020-04-07 International Business Machines Corporation String sequence operations with arbitrary terminators
US10255068B2 (en) 2017-03-03 2019-04-09 International Business Machines Corporation Dynamically selecting a memory boundary to be used in performing operations
US10521207B2 (en) * 2018-05-30 2019-12-31 International Business Machines Corporation Compiler optimization for indirect array access operations
US10795679B2 (en) * 2018-06-07 2020-10-06 Red Hat, Inc. Memory access instructions that include permission values for additional protection
US10884751B2 (en) 2018-07-13 2021-01-05 Advanced Micro Devices, Inc. Method and apparatus for virtualizing the micro-op cache
US11231918B1 (en) 2020-08-31 2022-01-25 Microsoft Technologly Licensing, LLC Native emulation compatible application binary interface for supporting emulation of foreign code
US11042422B1 (en) 2020-08-31 2021-06-22 Microsoft Technology Licensing, Llc Hybrid binaries supporting code stream folding
US11403100B2 (en) 2020-08-31 2022-08-02 Microsoft Technology Licensing, Llc Dual architecture function pointers having consistent reference addresses
US11977890B2 (en) * 2021-12-30 2024-05-07 Advanced Micro Devices, Inc. Stateful microcode branching

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4641262A (en) * 1983-03-07 1987-02-03 International Business Machines Corporation Personal computer attachment for host system display station
US4868765A (en) * 1986-01-02 1989-09-19 Texas Instruments Incorporated Porthole window system for computer displays
US4932048A (en) * 1986-04-15 1990-06-05 Canon Kabushiki Kaisha Data communication apparatus with voice communication control
US4941089A (en) * 1986-12-12 1990-07-10 Datapoint Corporation Input/output network for computer system
US5101341A (en) * 1988-08-25 1992-03-31 Edgcore Technology, Inc. Pipelined system for reducing instruction access time by accumulating predecoded instruction bits a FIFO
US5131086A (en) * 1988-08-25 1992-07-14 Edgcore Technology, Inc. Method and system for executing pipelined three operand construct
JP2810068B2 (ja) * 1988-11-11 1998-10-15 株式会社日立製作所 プロセッサシステム、コンピュータシステム及び命令処理方法
US5113515A (en) * 1989-02-03 1992-05-12 Digital Equipment Corporation Virtual instruction cache system using length responsive decoded instruction shifting and merging with prefetch buffer outputs to fill instruction buffer
US5018146A (en) * 1989-06-22 1991-05-21 Ge Fanuc Automatinon North America, Inc. Apparatus and method for determining if a particular plug-in card is appropriate for use with an electronic processor
US5233696A (en) * 1989-08-28 1993-08-03 Nec Corporation Microprocessor having precoder unit and main decoder unit operating in pipeline processing manner
US5185868A (en) * 1990-01-16 1993-02-09 Advanced Micro Devices, Inc. Apparatus having hierarchically arranged decoders concurrently decoding instructions and shifting instructions not ready for execution to vacant decoders higher in the hierarchy
US5201056A (en) * 1990-05-02 1993-04-06 Motorola, Inc. RISC microprocessor architecture with multi-bit tag extended instructions for selectively attaching tag from either instruction or input data to arithmetic operation output
CA2037708C (en) * 1990-05-04 1998-01-20 Richard J. Eickemeyer General purpose compound apparatus for instruction-level parallel processors
US5155843A (en) * 1990-06-29 1992-10-13 Digital Equipment Corporation Error transition mode for multi-processor system
WO1992006426A1 (en) * 1990-10-09 1992-04-16 Nexgen Microsystems Method and apparatus for parallel decoding of instructions with branch prediction look-up
JPH04156613A (ja) * 1990-10-20 1992-05-29 Fujitsu Ltd 命令バッファ装置
US5222244A (en) * 1990-12-20 1993-06-22 Intel Corporation Method of modifying a microinstruction with operands specified by an instruction held in an alias register
US5301342A (en) * 1990-12-20 1994-04-05 Intel Corporation Parallel processing computer for solving dense systems of linear equations by factoring rows, columns, and diagonal, inverting the diagonal, forward eliminating, and back substituting
DE69231011T2 (de) * 1991-02-08 2000-09-28 Fujitsu Ltd., Kawasaki Cachespeicher zur Verarbeitung von Befehlsdaten und Datenprozessor mit demselben
US5287490A (en) * 1991-03-07 1994-02-15 Digital Equipment Corporation Identifying plausible variable length machine code of selecting address in numerical sequence, decoding code strings, and following execution transfer paths
ATE291755T1 (de) * 1991-07-08 2005-04-15 Seiko Epson Corp Risc-prozessor mit erweiterbarer architektur
US5412466A (en) 1991-07-26 1995-05-02 Toa Medical Electronics Co., Ltd. Apparatus for forming flattened sample flow for analyzing particles
US5333277A (en) * 1992-01-10 1994-07-26 Exportech Trading Company Data buss interface and expansion system
GB2263987B (en) * 1992-02-06 1996-03-06 Intel Corp End bit markers for instruction decode
GB2263985B (en) * 1992-02-06 1995-06-14 Intel Corp Two stage window multiplexors for deriving variable length instructions from a stream of instructions
US5438668A (en) * 1992-03-31 1995-08-01 Seiko Epson Corporation System and method for extraction, alignment and decoding of CISC instructions into a nano-instruction bucket for execution by a RISC computer
US5394524A (en) * 1992-08-07 1995-02-28 International Business Machines Corporation Method and apparatus for processing two graphics data streams in parallel
US5412766A (en) * 1992-10-21 1995-05-02 International Business Machines Corporation Data processing method and apparatus for converting color image data to non-linear palette
US5440619A (en) * 1993-08-11 1995-08-08 Zoom Telephonics, Inc. Voice, data and facsimile modem with modified ringback answering
EP0651320B1 (de) * 1993-10-29 2001-05-23 Advanced Micro Devices, Inc. Superskalarbefehlsdekoder
US5504689A (en) * 1993-12-16 1996-04-02 Dell Usa, L.P. Apparatus and method for testing computer bus characteristics
US5495419A (en) * 1994-04-19 1996-02-27 Lsi Logic Corporation Integrated circuit physical design automation system utilizing optimization process decomposition and parallel processing
GB2289354B (en) * 1994-05-03 1997-08-27 Advanced Risc Mach Ltd Multiple instruction set mapping
DE69506623T2 (de) * 1994-06-03 1999-07-22 Motorola, Inc., Schaumburg, Ill. Datenprozessor mit einer Ausführungseinheit zur Durchführung von Ladebefehlen und Verfahren zu seinem Betrieb
US5598546A (en) * 1994-08-31 1997-01-28 Exponential Technology, Inc. Dual-architecture super-scalar pipeline
US5758141A (en) * 1995-02-10 1998-05-26 International Business Machines Corporation Method and system for selective support of non-architected instructions within a superscaler processor system utilizing a special access bit within a machine state register
US5638525A (en) * 1995-02-10 1997-06-10 Intel Corporation Processor capable of executing programs that contain RISC and CISC instructions
US5758114A (en) * 1995-04-12 1998-05-26 Advanced Micro Devices, Inc. High speed instruction alignment unit for aligning variable byte-length instructions according to predecode information in a superscalar microprocessor
US5619665A (en) * 1995-04-13 1997-04-08 Intrnational Business Machines Corporation Method and apparatus for the transparent emulation of an existing instruction-set architecture by an arbitrary underlying instruction-set architecture
US5646676A (en) * 1995-05-30 1997-07-08 International Business Machines Corporation Scalable interactive multimedia server system for providing on demand data

Also Published As

Publication number Publication date
DE69629383D1 (de) 2003-09-11
EP0853780A1 (de) 1998-07-22
KR100513358B1 (ko) 2006-02-01
WO1997013194A1 (en) 1997-04-10
EP0853780B1 (de) 2003-08-06
AU7246596A (en) 1997-04-28
US6336178B1 (en) 2002-01-01
JPH11510289A (ja) 1999-09-07
US5926642A (en) 1999-07-20
JP3714962B2 (ja) 2005-11-09
KR19990064091A (ko) 1999-07-26

Similar Documents

Publication Publication Date Title
DE69629383T2 (de) Superskalarer mikroprozessor mit risc86 befehlssatz
DE69631778T2 (de) Flexible implementierung eines systemverwaltungsmodus in einem prozessor
DE69802209T2 (de) An bytebereiche innerhalb eines befehlscaches gebundene verzweigungsselektoren zur schnellen identifizierung von verzweigungsprädiktoren
DE69737423T2 (de) Verfahren und gerät zum replizieren von datenspeicherung in einem fortgeschrittenen mikroprozessor
DE69605943T2 (de) Anordnung und verfahren zur mikrokodemodifikation
DE69904479T2 (de) Registerumbenennung wobei übertragungsinstruktionen mittels umbenennungsschildernzeichen realisiert werden
DE3486085T2 (de) Zentrale Verarbeitungseinheit für einen Digitalrechner.
DE69427672T2 (de) Befehlscachespeicher für Befehle mit variabler Byteslänge
DE69434669T2 (de) Spekulative Befehlswarteschlange für Befehle mit variabler Byteslänge
DE69508303T2 (de) Superskalarmikroprozessor mit einer Vorrichtung zur Namenänderung und Beförderung einer Operandenflagge und Verfahren zur Bearbeitung von RISC-ähnliche Funktionen in diesem Superskalarmikroprozessor
DE69802105T2 (de) Befehlsausrichtungseinheit mit doppelten befehlswarteschlangen zur hochfrequenz-befehlszuteilung
DE69710503T2 (de) Verzweigungsvorhersagemechanismus mit auswahlschaltern zum auswählen einer verzweigungsvorhersage
DE69427265T2 (de) Superskalarbefehlsdekoder
DE69521461T2 (de) Vorrichtung und Verfahren zur Abtastung einer Befehlswarteschlange
DE69433339T2 (de) Lade-/Speicherfunktionseinheiten und Datencachespeicher für Mikroprozessoren
DE69024068T2 (de) Verfahren und Datenverarbeitungseinheit zur Pipeline- Verarbeitung von Register- und Registeränderungs- Spezifizierern in dem gleichen Befehl
DE69836902T2 (de) Auf variable instruktionen eingestellter computer
DE69727773T2 (de) Verbesserte Verzweigungsvorhersage in einem Pipelinemikroprozessor
DE69932066T2 (de) Mechanismus zur &#34;store-to-load forwarding&#34;
DE69229198T2 (de) Verzweigungsbefehlprozessor und Verfahren
DE69835100T2 (de) Prozessor konfiguriert um vorausschauende resultate von zusammengefassten übertragungs-, vergleichs- und einfachen arithmetischen befehlen zu produzieren
DE69629495T2 (de) Vereinheitlichter multifunktions-operationsverteiler für die ungeordnete befehlsexekution in einem superskalaren prozessor
DE69904189T2 (de) Konfigurierter prozessor zur abbildung von logischen registernummern auf physikalische registernummern unter verwendung von virtuellen registernummern
DE69131189T2 (de) Bytevergleich-Operation für einen hochleistungsfähigen Prozessor
DE69129881T2 (de) Verzweigung in einem Pipeline-Prozessor

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: GLOBALFOUNDRIES INC. MAPLES CORPORATE SERVICES, KY