DE69628932T2 - Abtastkette zur schnellen feststellung eines ersten und zweiten objektes von ausgewählten typen in einer sequentiellen liste - Google Patents

Abtastkette zur schnellen feststellung eines ersten und zweiten objektes von ausgewählten typen in einer sequentiellen liste Download PDF

Info

Publication number
DE69628932T2
DE69628932T2 DE69628932T DE69628932T DE69628932T2 DE 69628932 T2 DE69628932 T2 DE 69628932T2 DE 69628932 T DE69628932 T DE 69628932T DE 69628932 T DE69628932 T DE 69628932T DE 69628932 T2 DE69628932 T2 DE 69628932T2
Authority
DE
Germany
Prior art keywords
entry
group
operations
operand
signal
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
DE69628932T
Other languages
English (en)
Other versions
DE69628932D1 (de
Inventor
G. John FAVOR
Amos Ben-Meir
E. Jeffrey TRULL
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
Priority claimed from US08/592,722 external-priority patent/US5745724A/en
Application filed by Advanced Micro Devices Inc filed Critical Advanced Micro Devices Inc
Publication of DE69628932D1 publication Critical patent/DE69628932D1/de
Application granted granted Critical
Publication of DE69628932T2 publication Critical patent/DE69628932T2/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
    • 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
    • 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
    • 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/38—Concurrent instruction execution, e.g. pipeline, 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, 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, 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, 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, look ahead
    • G06F9/3824—Operand accessing
    • G06F9/3826—Bypassing or forwarding of data results, e.g. locally between pipeline stages or within a pipeline stage
    • G06F9/3828—Bypassing or forwarding of data results, e.g. locally between pipeline stages or within a pipeline stage with global bypass, e.g. between pipelines, between clusters
    • 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, 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, 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

Description

  • Technisches Gebiet
  • Diese Erfindung betrifft Schaltungen und Verfahren zum schnellen Identifizieren eines Objekts in einer sequentiellen Liste und betrifft insbesondere Schaltungen und Verfahren zum Auswählen von Operationen für die Benutzung durch Ausführungseinheiten in einem superskalaren Prozessor.
  • Stand der Technik
  • Ein typisches Computerprogramm ist eine Liste von Befehlen, welche, wenn sie kompiliert oder assembliert ist, eine Abfolge von Maschinenbefehlen oder Operationen erzeugt, die ein Prozessor ausführt. Die Operationen haben eine Programmreihenfolge, die von der Logik des Computerprogramms definiert wird, und sind generell zu einer sequentiellen Ausführung in einer Programmreihenfolge vorgesehen. Skalare Prozessoren führen die Operationen in der Programmreihenfolge aus, was einen skalaren Prozessor darauf begrenzt, eine Operation abzuschließen bevor die nächste Operation abgeschlossen wird. Um die Leistungsfähigkeit des Prozessors zu verbessern, sind superskalare Prozessoren entwickelt worden, welche eine Vielzahl von Ausführungseinheiten enthalten, die fähig sind, parallel zu arbeiten, so dass Operationen parallel oder außer der Reihe des Programms ausgeführt und abgeschlossen werden können. Superskalare Prozessoren können zu einem Zeitpunkt mehr als eine Operation abschließen und können daher bei der Berechnung schneller sein als mit der gleichen Taktfrequenz arbeitende skalare Prozessoren.
  • Ein Ablaufplaner in einem superskalaren Prozessor kann die Ausführung von Programmen zeitlich planen, so dass Operationen außer der normalen Reihenfolge des Programms ausgeführt werden. Schwierigkeiten in der außer der Reihe Ausführung treten auf, weil eine Operation von einer anderen da hin gehend abhängig sein kann, dass die Logik des Computerprogramms erfordert, dass die erste Operation in dem Programm vor der zweiten Operation ausgeführt werden muss. Ob eine Operation überhaupt ausgeführt werden soll, hängt oft von dem Ergebnis einer Verzweigungsoperation ab. Falls eine Operation, die einer bedingten Verzweigungsoperation folgt, vor der Verzweigung ausgeführt wird, muss die Ausführung spekulativ sein, weil die Verzweigung den Befehl überspringen kann. Des weiteren erfordern viele Computer, dass der Zustand des Systems bekannt ist, unmittelbar bevor oder nachdem eine Operation einen Fehler, Interrupt oder Fang erzeugt, aber wenn Operationen außer der Reihe ausgeführt werden, kann eine Operation, die einem Fehler in einem Programm folgt, ausgeführt worden sein, bevor der Fehler auftrat. Daher muss der Prozessor fähig sein, Operationen rückgängig zu machen, die nicht hätten ausgeführt werden sollen, und muss fähig sein, den Zustand des Systems, der einem Fehler folgt, zu konstruieren.
  • Zwei ziemlich miteinander kollidierende Ziele von superskalaren Architekturen sind eine schnelle Ablaufplanung, so dass ein Prozessor mit einer hohen Taktfrequenz arbeiten kann, und eine effiziente Ablaufplanung, um die parallele Ausführung von Operationen, die tatsächlich für den Abschluss des Programms erforderlich sind, zu maximieren. Ablaufplaner sind gewünscht, die diese Ziele erfüllen.
  • Das IBM Technical Disclosure Bulletin, Volumen Abbildungseinheit 30, Nummer 9, Februar 1988, Seiten 325–329, beschreibt eine Transfergateschaltung hoher Leistungsfähigkeit mit Vorausschau, um führende Nullen zu zählen. Die Funktion zähle führende Nullen (CLZ) detektiert das erste Auftreten einer logischen "1" suchend von dem MSB zu dem LSB von binären Eingangsdaten und stellt einen logischen "0" Ausgang bis zu der ersten "1" und eine logische "1" für alle nachfolgenden Ausgangsbits zur Verfügung. Eine Vorausschau Funktion wird implementiert durch die Unterteilung der durchsuchten Datenbits in zwei Teile und Setzen der Ausgangsbits des unteren Teils auf eine logische "1", wenn von dem ersten Block von CLZ Schaltungen ein logischer "1" Ripple-Ausgang zur Verfügung gestellt wird.
  • IEEE Transactions on Computers, Volumen 23, Nummer Zeilenvorhersage 12, Dezember 1974, Seiten 1317 bis 1320 offenbaren ein Entwurfsverfahren für mehrfache Übereinstimmungsauflöser. Der Ansatz umfasst die wiederholte Verwendung eines Standard Funktionsblocks, um eine Auflösungsbaumstruktur zu bilden, die fähig ist zur Erzeugung von Adressen oder logischen Vektoren mit reduzierter Ausbreitungsverzögerung. Die Schaltung wählt ein Element, das eine logische "1" ist aus einem N-Bit Vektor aus unter Verwendung von Zeigern und Verbotsvektoren.
  • In Übereinstimmung mit der Erfindung enthält eine außer der Reihe Maschine einen Satz von Ausführungseinheiten, die zu einem parallelen Betrieb fähig sind, und einen Ablaufplaner, der Operationen an die Ausführungseinheiten absendet. Der Ablaufplaner enthält Einträge, die mit auszuführenden Operationen verbunden sind. Jeder Eintrag enthält Speicherplatz für Informationen, die für die Ausführung einer verbundenen Operation erforderlich sind, und eine Logik für die Zuleitung der Informationen an die richtige Ausführungseinheit, wenn erforderlich.
  • Die Einträge in dem Ablaufplaner sind nicht im Hinblick auf den Befehlstyp spezialisiert und die Ausführungseinheiten haben keine spezialisierten Warteschlangen, die blockiert werden können, falls ein Befehl angehalten wird. Der Ablaufplaner enthält Abtastungsketten, die Operationen für die Ausgabe an die Ausführungseinheiten auswählen, welche die Operationen ausführen. Jede Ausführungseinheit hat eine Klasse von Operationen, die sie ausführen kann; aber in einigen Ausführungsbeispielen der Erfindung überlappen sich die Klassen von Operationen, die von zwei der Ausführungseinheiten ausgeführt werden, oder sind identisch. In derartigen Ausführungsbeispielen müssen die Abtastungsketten sicher stellen, dass die gleiche Operation nicht an zwei Ausführungseinheiten ausgegeben wird. Ein Weg um sicher zu stellen, dass zwei verschiedene Operationen an zwei Ausführungseinheiten ausgegeben werden, die überlappende Klassen von ausführbaren Operationen haben, ist es, zu erfordern, dass die an eine Ausführungseinheit ausgege bene Operation der an die andere Ausführungseinheit ausgegebenen Operation folgt (in der Reihenfolge des Programms).
  • Eine Abtastungskette in Übereinstimmung mit der Erfindung kann eine Operation einer zweiten Klasse identifizieren, die nach einem Objekt einer ersten Klasse folgt. Für einen schnelleren Betrieb arbeiten die Abtastungsketten unabhängig und parallel zu den anderen Abtastungsketten, sogar obwohl die Ergebnisse von zwei der Abtastungsketten logisch abhängig sein könnten. Die Abtastungskette erzeugt Einzeleintrag "Erzeugung", "Ausbreitung" oder "Beseitigung" und "nur" Ausdrücke, welche ein Abtastungsbit steuern. Begrifflich, wenn der "nur" Ausdruck nicht angelegt ist, erzeugt ein Eintrag, der zu einer Operation der ersten Klasse gehört, das Abtastungsbit und legt den "nur" Ausdruck an. Das Abtastungsbit breitet sich zu den folgenden Einträgen in dem Ablaufplaner aus. Nachdem der "nur" Ausdruck angelegt ist, ist eine weitere Erzeugung des Abtastungsbits verhindert. Jeder Eintrag breitet das Abtastungsbit entweder zu dem nächsten Eintrag aus oder, falls der Eintrag zu einer Operation der zweiten Klasse gehört, beseitigt das Abtastungsbit und identifiziert sich selbst als der ausgewählte Eintrag. Die Ausbreitung kann mit einer Vorausschaulogik durchgeführt werden, die Gruppenausdrücke von Einzelausdrücken unterscheidet, um anzuzeigen, ob ein Abtastungsbit von einer Gruppe von Einträgen erzeugt, ausgebreitet oder beseitigt werden würde. Entsprechend können Abtastungen schnell durch geführt werden, weil die Ausbreitung tatsächlich parallel geführt wird.
  • Operationen werden erstens in Übereinstimmung mit dem Typ und der Verfügbarkeit der erforderlichen Ausführungseinheit und zweitens in Übereinstimmung mit der sequentiellen Ordnung des Programms abgeschickt. Die Verfügbarkeit von Operanden wird während der Auswahl der Ausgabe nicht überprüft. Jedoch können Operationen, die eine Ausführungspipeline blockieren würden, aus frühen Stufen der Pipeline ausgestoßen werden, so dass Befehle des gleichen Typs außer der Reihenfolge des Programms ausgeführt werden können.
  • Nachdem eine abbrechbare Operation ausgegeben und ausgeführt ist, werden die Ergebnisse der Operation in dem zugeordneten Eintrag und/oder in einer Speicherwarteschlange gehalten. Der Ablaufplaner hält ein Ergebnis, bis eine dem Ablaufplaner zugeordnete Operationsübergabeeinheit bestimmt, dass kein Fehler oder falsch vorher gesagte Verzweigung der zugeordneten Operation voran geht. Falls die Operationsübergabeeinheit bestimmt, dass die Ergebnisse der ältesten ausgeführten Operationen durch die sequentielle Ausführung eines Programms erzeugt würden, werden die Ergebnisse beständig gemacht durch Schreiben in eine Registerdatei, ein Statusregister oder einen Speicher, und die Operation wird zurück gezogen und von dem Ablaufplaner entfernt. Falls die Operationsübergabeeinheit bestimmt, dass ein Ergebnis nicht durch die sequentielle Ausführung eines Programms erzeugt würde (zum Beispiel wegen einer falsch vorher gesagten Verzweigung oder einem voran gehenden Fehler oder Abbruch), wird die Operation zurück gezogen ohne dass andauernde Änderungen gemacht werden.
  • In einem Ausführungsbeispiel der Erfindung enthält der Ablaufplaner Zeilen von Einträgen, die anhängigen Operationen zugeordnet sind. Jeder Eintrag entspricht einer einzelnen Operation und jede Zeile von Einträgen entspricht mehreren Operationen, zum Beispiel vier Operationen. Der Ablaufplaner arbeitet in einigen Bereichen wie ein Schieberegister, wo einer neuen Gruppe von Operationen zugeordnete Informationen in eine oberste Zeile des Ablaufplaners geladen werden und als eine Gruppe in Richtung der untersten Zeile des Ablaufplaners geschoben werden, wenn ältere Operationen zurück gezogen werden. Markierungen, die das Alter einer Operation anzeigen, werden nicht benötigt, da die Position einer Operation in dem Ablaufplaner ihr Alter anzeigt.
  • Die meisten Operationen sind unmittelbar für die Ausführung auswählbar, wenn sie in die oberste Zeile des Ablaufplaners geladen werden, aber können von jedem Punkt in dem Ablaufplaner an die Ausführungseinheiten ausgegeben werden. Ein Statusfeld in einem Eintrag für eine Operation zeigt an, ob die Operation ausgegeben worden ist, sich in einer Ausführungsstufe einer Pipeline befindet oder abgeschlossen worden ist. Der Status der Operation ist unabhängig von der Position in dem Ablaufplaner, aber je länger die Operation in dem Ablaufplaner ist, desto größer ist die Chance, dass die Operation ausgegeben und abgeschlossen wird. Operationen in einer Zeile werden gleichzeitig zurück gezogen, so dass jeden Taktzyklus mehrere Operationen abgeschlossen werden können.
  • Einige Operationen, wie Bewertungen von bedingten Verzweigungen und Registeroperationen, die von Status Flags abhängen, werden ausgeführt, wenn die Operationen eine bestimmte Zeile des Ablaufplaners erreichen, wo ältere Operationen wahrscheinlich abgeschlossen sind. Entsprechend werden Operationen, die von den Status Flags abhängen, in einer Zeile behandelt, wo ältere Operationen wahrscheinlich die Änderungen der Werte der Status Flags abgeschlossen haben. Dies minimiert Stockungen der Pipeline, die durch Wartevorgänge auf gültige Werte der Status Flags hervor gerufen werden.
  • Der Ablaufplaner ist eng mit den Ausführungseinheiten und der Operationsübergabeeinheit verbunden und hält Informationen aufrecht, die Operationen für mehrere Ausführungspipelines betreffen. Der Ablaufplaner gibt Operationen aus, stellt die Informationen hinsichtlich der Operation den Ausführungseinheiten zu geforderten Zeiten zur Verfügung und hält die Ergebnisse von abgeschlossenen Operationen zur Weiterleitung, wie erforderlich für die Ausführung von Operationen bevor die Ergebnisse übergeben worden sind. Entsprechend stellt der Ablaufplaner eine einzelne einheitliche Struktur zur Verfügung, welche die Ausführung von Operationen zeitlich plant, während der Ausführung benötigte Operandenwerte zur Verfügung stellt und wie ein Umordnungspuffer agiert.
  • In den begleitenden Zeichnungen, lediglich beispielhaft:
  • 1 zeigt ein Blockdiagramm eines Computersystems, das in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung einen Prozessor enthält.
  • 2 zeigt einen Prozessor in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung.
  • 3 stellt ein beispielhaftes Format für RISC Befehle dar, die von einer außer der Reihe Maschine in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung ausgeführt werden.
  • 4A, 4B, 4C und 4D zeigen Pipelines von vier Typen von RISC Befehlen in einem Ausführungsbeispiel der Erfindung.
  • 5 stellt einen Ablaufplaner in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung dar.
  • 6 zeigt ein Schaltungsdiagramm eines Bereichs eines Ablaufplanungsreservoirs in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung.
  • 7 stellt ein beispielhaftes Format für Felder für Operationen und Op Quads dar, die in einem Ablaufplaner in Übereinstimmung mit 5 gespeichert sind.
  • 8A und 8B stellen eine Abtastungskette dar, die Vorausschau für eine schnelle Auswahl verwendet.
  • 9A, 9B und 9C stellen eine Abtastungskette dar, die Vorausschau für eine schnelle Auswahl einer Operation für eine zweite Ausführungseinheit verwendet.
  • 10 ist ein Blockdiagramm der Schnittstelle zwischen den Ausführungseinheiten und dem Ablaufplaner aus 5.
  • 11A, 11B und 11C sind Blockdiagramme von Ausführungsbeispielen von Verarbeitungssystemen der Erfindung.
  • Die Verwendung von den gleichen Bezugszeichen in verschiedenen Figuren zeigen ähnliche oder identische Gegenstände an.
  • Wege zum Ausführen der Erfindung und industrielle Anwendbarkeit
  • Die Erfindung wird in Verbindung mit dem folgenden Überblick beschrieben:
    • I. Überblick
    • II. Ablaufplaner
    • A. Laden des Ablaufplaners
    • 1. Statische Felder Eintrag
    • 2. Dynamische Felder Eintrag
    • 3. Op Quad Felder
    • B. Lade/Schiebe Steuerung
    • III. Ausführung Operation
    • A. Stufe Ausgabe
    • 1. Ausgabeauswahlphase
    • a. Abtastungsketten Ausgabeauswahl
    • b. Abtastungsketten Ausgabeauswahl für RUY
    • 2. Verbreitungsphase Operandeninformation
    • B. Stufe Operandenweiterleitung
    • 1. Operandenauswahlphase
    • 2. Operandentransferphase
    • 3. Weiterleitung Verschiebung
    • 4. Weiterleitung unmittelbarer Wert
    • C. Abruf Datenoperand
    • D. Ausstoß Registeroperation
    • E. Lade/Speicher Ordnung
    • F. Behandlung Abbruch
    • IV. Globale Steuerlogik
    • A. Von externer Logik verwendete Ablaufplanerinformation
    • B. Globale Steuerfunktionen
    • V. Status Flags
    • A. Abruf Status Flags
    • B. Weiterleitung Status Flags an cc-Dep RegOps
    • C. Auflösung Verzweigungsvorhersage
    • VI. Synchronisierung nicht abbrechbarer Operationen
    • VII. Behandlung selbstmodifizierender Code
    • VIII. Operationsübergabeeinheit
    • A. Übergabe
    • 1. Übergabe Register
    • 2. Übergabe Status Flags
    • 3. Übergabe Speicherschreibvorgänge
    • B. Zurückziehung Op Quads
    • C. Fehlerbehandlung
    • 1. Fehlerbehandlung Ladeoperationen
    • 2. Behandlung FAULT und LDDHA/LDAHA Op
    • 3. Behandlung Grenzverletzung des Ziels
    • 4. Behandlung falsch vorher gesagter Verzweigungen
    • D. Erzeugung Abbruchzyklus
    • IX. Verarbeitungssysteme
    • X. Abschluss
    • Anhang A: RISC86TM Syntax
    • Anhang B: Pseudo-RTL Beschreibungen
  • I. Überblick
  • Ein Prozessor in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung kann in einer Vielzahl von Anwendungen einschließlich eines Personal Computers angewendet werden. 1 zeigt ein Blockdiagramm eines Computer Motherboards 100, das in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung einen Prozessor 200 enthält. Der Prozessor 200 ist eine monolithische integrierte Schaltung, die fähig ist, einen komplexen Befehlssatz auszuführen und kann hergestellt werden unter Verwendung konventioneller Prozesse für integrierte Schaltungen, wie einem 5 Metallschichten CMOS Prozess mit 0,35 μm Entwurfsregeln. Ein mit dem Prozessor 200 verbundener Chipsatz enthält einen externen Level 2 Cachespeicher 125, eine Speichersteuerung 121, die eine Schnittstelle zu einem Hauptspeicher 122 zur Verfügung stellt, und Bussteuerungen 150 und 160, die Schnittstellen zu lokalen Bussen, wie einem PCI Bus 155 und einem ISA Bus 165, zur Verfügung stellen.
  • 2 zeigt ein Blockdiagramm eines Ausführungsbeispiels des Prozessors 200. Der Prozessor 200 hat ein Systeminterface 205, das Zugriff auf den Adressraum eines Computersystems einschließlich des Hauptspeichers 122 und Geräten an den lokalen Bussen 151 und 161 zur Verfügung stellt. In einem beispielhaften Ausführungsbeispiel hat das Systeminterface 205 einen 64 Bit Systembus mit einer Multiprozessor Cachespeicherkohärenz Unterstützung für geänderte, exklusive, geteilte und ungültige (MESI) Zustände und konfigurierbarer Busanpassung.
  • Ein integrierte Level 2 Cachespeicher Steuerlogik 210 stellt eine Schnittstelle zwischen einem privaten Bus und einem externen SRAM zur Verfügung, welches einen Level 2 Cachespeicher 125 bildet. Die Bereitstellung des Level 2 Cachespeicher Interfaces getrennt vom Systeminterface 205 entkoppelt die Geschwindigkeit des Level 2 Cachespeichers von dem System Bus/Chipsatz, was einen schnelleren Cachespeicher erlaubt und die Benutzung des Systembusses und des Cachespeicherbusses senkt, was eine größere Bandbreite auf jedem Bus erlaubt. Die Level 2 Cachespeicher Steuerlogik 210 sorgt weiter für mehrfache Taktskalierung und konfigurierbare Größen des Cachespeichers für bis zu 2 MB an Daten- und Markierungsspeicherplatz aus handelsüblichen Burst Pipeline synchronen SRAMs. Der Level 2 Cachespeicher verwendet eine Rückschreibpolitik und eine 32 Byte Zeilengröße.
  • Als eine Alternative zu der in 1 gezeigten Konfiguration hat der Prozessor 200 einen einzelnen Bus für den Zugriff auf das System und auf den Cachespeicher. Der Bus kann zum Beispiel Pin für Pin mit Chipsätzen für Prozessoren wie dem Pentium kompatibel sein.
  • Ein Level 1 Befehls-Cachespeicher 230 und ein Level 1 Daten-Cachespeicher 220 sind intern in dem Prozessor 200 und sind über eine Level 1 Cachespeicher Steuerlogik 215 mit dem Level 2 Cachespeicher und mit dem Systembus verbunden. In dem beispielhaften Ausführungsbeispiel ist der Befehls-Cachespeicher 230 ein zwei Wege Satz assoziativer Cachespeicher, der Speicherplatz für 16 KB an Befehlen und weiteren Vordekodierungsinformationen enthält. Der Daten-Cachespeicher 220 ist ein zwei Wege Satz assoziativer Cachespeicher, der Speicherplatz für 32 KB an Daten enthält. Um für schnelleren Betrieb und die Vermeidung von Zugriffskonflikten zu sorgen, verwendet der Daten-Cachespeicher 220 in einer Pipeline organisierte Bänke von Speicher mit zwei Anschlüssen, welche einen Lesevorgang und einen Schreibvorgang pro Takt erlauben.
  • Befehle werden von dem Hauptspeicher 122 in den Befehls-Cachespeicher 230 geladen. In Übereinstimmung mit dem beispielhaften Ausführungsbeispiel sind die Befehle in dem Hauptspeicher 122 CISC Befehle aus einem komplexen Befehlssatz wie dem PC Industriestandard x86 Befehlssatz. Die CISC Befehle werden hier manchmal als Makrobefehle bezeichnet. Bis zu 16 Byte von CISC Befehlen werden pro Takt abgerufen. Während des Ladens des Befehls-Cachespeichers 230 werden Bytes der Befehle für eine schnelle Identifizierung der Grenzen der Makrobefehle vordekodiert. Die Vordekodierung fügt zu jedem Byte Codebits hinzu, um einen Offset von dem Byte zu dem Start des folgenden Befehls anzuzeigen, unter der Annahme, dass das Befehlsbyte das erste Byte eines Befehls ist.
  • Ein Befehlsdekodierer 240 führt nicht bedingte Verzweigungsbefehle aus, führt eine Vorhersage der Verzweigungen für bedingte Verzweigungsbefehle durch und konvertiert die von dem Befehls-Cachespeicher 230 abgerufenen CISC Befehle in Operationen für eine Ausführungsmaschine 250. Die Ausführungsmaschine 250 implementiert eine superskalare, außer der Reihe Architektur mit reduzierter Befehlssatzberechnung (RISC). Ein einzelner CISC Befehl von dem Befehls-Cachespeicher 230 dekodiert zu Null (für nicht bedingte Verzweigungsbefehle), eine oder mehrere Operationen für die Ausführungsmaschine 250. Mehrere CISC Befehle können jeden Takt dekodiert werden, um einen Satz von RISC Befehlen zu erzeugen, der die von der Ausführungsmaschine 250 ausgeführten Befehle Operationen anzeigt. Der Befehlsdekodierer 240 enthält einen Hardwaredekodierer (MacDec) 242 für die üblichsten CISC Befehle und einen Einsprungdekodierer 244 für die nicht üblichen und komplexeren CISC Befehle. Der Einsprungdekodierer 244 enthält ein ROM 246, das hier manchmal als Emcode ROM 246 bezeichnet wird, das Sequenzen von RISC Befehlen enthält, hier manchmal als Emcode bezeichnet. Der Einsprungdekodierer 244 wählt in Übereinstimmung mit dem zu dekodierenden CISC Befehl eine Adresse in dem Emcode ROM 246 aus und ersetzt oder verändert Teile der von dem Emcode ROM 246 gelesenen RISC Befehle, wie es zur Konvertierung des CISC Befehls in entsprechende RISC Befehle erforderlich ist.
  • 3 und der Anhang A stellen ein beispielhaftes Format eines RISC Befehls dar, der für die Ausführung von x86 CISC Befehlen optimiert ist und manchmal als der RISC86® Befehlssatz bezeichnet wird. Jeder RISC86® Befehl ist entweder eine Register Operation (RegOp), eine Lade-Speicher Operation (LdStOp) oder eine Spezialoperation (SpecOp). Eine RegOp wird manchmal als eine ".cc" RegOp bezeichnet, um anzuzeigen, dass die RegOp Bedingungscodes verändert, oder als eine "cc-dep" Reg, um anzuzeigen, dass die RegOp von Bedingungscodes abhängt. LdStOps werden weiter unterteilt entweder als Lade-Operation (LdOp) oder als Speicher-Operation (StOp). Eine Lade unmittelbaren Wert Operation (LIMMOp) ist ein Typ einer LdOp, der ein anderes Format als andere LdOps hat und manchmal einen großen unmittelbaren Wert für eine folgende LdStOp oder eine RegOp zur Verfügung stellt. SpecOps umfassen Verzweigungsoperationen (BrOps) und Gleitkomma Operation (FpOp), die verschiedene Formate haben. Die 3 und der Anhang A beschreiben lediglich BrOps als ein Beispiel für eine SpecOp. Eine bedingte Verzweigungsoperation (BRCOND) ist ein Typ einer BROp, der von einem Bedingungscode abhängt (Feld cc in 3).
  • In dem beispielhaften Ausführungsbeispiel der Erfindung konvertiert der Befehlsdekodierer 240 x86 Makrobefehle in RISC86® Befehle (oder Operationen). Der MacDec 242 konvertiert übliche Makrobefehle in kurze Sequen zen von RISC86® Operationen. Zum Beispiel werden die x86 Makrobefehle INC reg, PUSH reg und Jcc tgt_addr in eine RegOp, eine StOp beziehungsweise in eine BRCOND dekodiert; ein ADD reg.mem Makrobefehl wird als eine LdOp und eine RegOp in Folge dekodiert; ein ADD mem.reg Makrobefehl wird als eine LdOp, eine RegOp und eine StOp in Folge dekodiert und ein LEAVE Makrobefehl wird als eine RegOp, eine LdOp und eine RegOp in Folge dekodiert.
  • In einem Ausführungsbeispiel dekodiert der Befehlsdekodierer 240 bis zu zwei x86 Makrobefehle pro Takt, um einen Satz von vier RISC86® Operationen zu erzeugen, welche in einem Takt in die Ausführungsmaschine 250 geladen werden können. No-Op Operationen werden verwendet, falls es notwendig ist, einen Satz von vier Operationen abzuschließen. Zwei Operationen werden in einem Takt dekodiert, falls die zwei nachfolgenden Befehle als Befehle identifiziert werden können, die jeweils zu zwei oder weniger Operationen dekodiert werden. In einem alternativen Ausführungsbeispiel können bis zu drei (oder mehr) Makrobefehle in einem Takt dekodiert werden, um einen Satz von vier (oder mehr) Operationen zu bilden. Der Einsprungdekodierer 244 wird verwendet, um Makrobefehle zu dekodieren, die nicht üblich sind oder sich zu langen Sequenzen von RISC86® Operationen dekodieren. Derartige Sequenzen können länger als vier Operationen sein und können mehr als einen Taktzyklus für das Laden in die Ausführungsmaschine 250 benötigen.
  • Für nicht bedingte Makrobefehle bestimmt der Befehlsdekodierer 240 den nächsten für die Dekodierung abzurufenden Makrobefehl und erzeugt keine Operationen. Für einen bedingten Verzweigungs-Makrobefehl enthält der Dekodierer 240 eine Verzweigungsvorhersagelogik 248, welche den Programmzähler, der einem bedingten Verzweigungsbefehl folgt, vorher sagt und eine BRCOND erzeugt, die später bewertet wird, um festzustellen, ob die Vorhersage korrekt war. Bedingte Verzweigungen (BRCONDs) können auch in RISC Befehlssequenzen von dem Emcode ROM 246 auftreten, wenn der zu dekodierende Makrobefehl keine bedingte Verzweigung ist. Das Emcode ROM 246 enthält eine Vorhersage für jede derartige BRCOND, die der Einsprungdekodierer 244 verwendet, wenn eine RISC Befehlssequenz für einen dekodierten Makrobefehl erzeugt wird. Die Vorhersage für eine BRCOND von dem Emcode ROM 246 wird auf eine ähnliche Weise wie für BRCONDs bewertet, die direkt von dem bedingten Verzweigungs-Makrobefehl erzeugt wird.
  • Die Ausführungsmaschine 250 enthält sieben Ausführungseinheiten 251 bis 257, welche im Allgemeinen parallel arbeiten können, einen Ablaufplaner 280, der Operationen zur Ausführung ausgibt, und eine Operationsübergabeeinheit (OCU) 260, die mit dem Ablaufplaner 280 zur Übergabe der Ergebnisse der Operationen verbunden ist. Jede Ausführungseinheit hat entsprechende Operationen, die sie ausführen kann. Eine Ladeeinheit 251 und eine Speichereinheit 252 führen LdOps beziehungsweise StOps aus. Eine Speicherwarteschlange 270 speichert temporär Daten von spekulativen Ausführungen von StOps durch die Speichereinheit 252. Daten von der Speicherwarteschlange 270 werden in den Daten-Cachespeicher 220 geschrieben, wenn die Ergebnisse einer StOp wie unten beschrieben übergeben werden. Die Registereinheiten 253 und 254, hier auch als RUX und RUY bezeichnet, führen RegOps aus, welche dem Namen nach auf eine Registerdatei 290 zugreifen. Eine Gleitkommaeinheit 255 und eine Multimediaeinheit 256 sind optionale Einheiten, welche Gleitkomma Operationen (FpOps) beziehungsweise Operationen für Multimedia Anwendungen ausführen. In dem beispielhaften Ausführungsbeispiel sind die Gleitkommaeinheit 255 und die Multimediaeinheit 256 unterdrückt.
  • Der Ablaufplaner 280 gibt Operationen an die Ausführungseinheiten 251 bis 257 aus, verschickt während der Ausführung von den verschiedenen Ausführungseinheiten benötigte Informationen und löscht Informationen zu Operationen, wenn die Operationen zurück gezogen werden. Der Ablaufplaner 280 ist in Einträge unterteilt, wobei jeder Eintrag zu einer Operation gehörigen Speicherplatz und eine Logik enthält. Die Information in einem Speicherplatz eines Eintrags beschreibt eine Operation, die ausgeführt werden soll, ausgeführt wird oder ausgeführt worden ist. In dem beispielhaften Ausführungsbeispiel sind Sätze von vier Einträgen in Gruppen organisiert, die hier als Zeilen bezeichnet werden, auch wenn die Einträge physikalisch nicht in einer Reihe angeordnet sind. Die mit vier Operationen in einer Zeile verbundene Information wird hier als ein Op Quad bezeichnet. Zeilen enthalten Speicherfelder und Logik, die einem Op Quad als Gruppe zugeordnet sind, zusätzlich zu der Information und der Logik, die einzelnen Operationen zugeordnet ist.
  • Der Ablaufplaner 280 arbeitet auf viele Arten wie ein Schieberegister. In einem beispielhaften Ausführungsbeispiel ist der Ablaufplaner 280 sechs Zeilen tief. Der Befehlsdekodierer 240 kann jeden Taktzyklus einen neuen Op Quad in die oberste Zeile des Ablaufplaner 280 laden. Der Op Quad wird von der obersten Zeile zu einer untersten Zeile geschoben, von der der Op Quad zurück gezogen wird. Die Position eines Op Quads in dem Ablaufplaner 280 zeigt das Alter oder den Platz in der Reihenfolge des Programms für den Op Quad an; aber für die meisten Operationen ist die Position in dem Ablaufplaner 280 unabhängig von der Stufe der Ausführung.
  • Die 4A bis 4D zeigen mehrstufige Pipelines, die mit RegOps, LdOps, StOps und BrOps verbunden sind. Jede Stufe in der Pipeline erfordert dem Namen nach einen Prozessortaktzyklus, es sei denn eine Operation wird in einer der Stufen aufgehalten, was Operationen in früheren Stufen am Vorrücken verhindert. Zwei einleitende Stufen 410 und 420 sind üblich für alle Ausführungspipelines. Während der Stufe 410 werden bis zu 16 Byte von CISC Befehlen in den Befehls-Cachespeicher 230 abgerufen und vordekodiert, um die Grenzen des Befehls zu identifizieren und nachfolgende Dekodierungszeit zu reduzieren. Während der Stufe 420 dekodiert der Befehlsdekodierer 240 bis zu drei CISC Befehle von dem Befehls-Cachespeicher 230 und bildet einen Op Quad, der in die oberste Zeile des Ablaufplaners 280 geladen wird.
  • Der Ablaufplaner 280 steuert dann eine Stufe Ausgabe 430 und eine Stufe Operandenweiterleitung 440, die mit anderen Operationen als BrOps verbunden ist. Während einer Stufe Ausgabe 430 tastet der Ablaufplaner 280 seine Einträge ab und gibt bis zu sechs Operationen an die entsprechenden Ausführungseinheiten 251 bis 256 aus. Der Ablaufplaner 280 kann neuere Operationen vor einer älteren Operation für die Ausgabe auswählen, so dass die Ausführung außer der Reihe und spekulativ ist. Die Anhängigkeiten von Operanden werden während der Ausgabeauswahl nicht berücksichtigt. Der Ablaufplaner 280 übermittelt Operanden für die zuvor während der Stufe Ausgabeauswahl 430 ausgegebenen Operationen während der Stufe Operandenweiterleitung 440 an die Ausführungseinheiten 251 bis 256. Während der Stufe 440 können einige Operationen, die an die Registereinheit 253 oder 254 ausgegeben wurden, aus einer Pipeline gestoßen werden, um eine lange Blockade der Pipeline zu verhindern, falls benötigte Operanden nicht für einige Taktzyklen zur Verfügung stehen.
  • Wie in 4A gezeigt wird die Ausführung von RegOps in einem Taktzyklus, der die Stufe Ausführung 450 ist, abgeschlossen. Die Stufe Ausführung 450 einer RegOp umfasst eine ALU Phase 451, in der eine arithmetische Logikeinheit (ALU) in der Registereinheit 253 oder 254 die Quelloperanden der RegOp in Übereinstimmung mit dem Typ der bearbeiteten RegOp bearbeitet, und eine Ergebnisübermittlungsphase 452, in der ein Ergebnis und Statuswerte von der Registereinheit 253 oder 254 in dem der RegOp entsprechenden Eintrag zurück gespeichert werden. Die in dem Eintrag gespeicherten Ergebnisse und Status Flags werden nachfolgend an die Registerdatei 290 und das architekturisierte Status Flag Register übergeben, falls und wenn es sicher ist, dies zu tun. Nachdem oder genau dann, wenn eine Operation abgeschlossen wird, können die Ergebnisse der Operation übergeben werden und die Operation kann zurück gezogen werden durch Schieben des Op Quads, der die Operation enthält, aus dem Ablaufplaner 280. Zwischen dem Abschluss und der Übergabe sind die Ergebnisse und die Status Flags von einer Operation für den Ablaufplaner 280 zur Ausführung von anderen Befehlen verfügbar.
  • Die 4B und 4C zeigen, dass LdOps und StOps zwei Ausführungsstufen 450 und 460 erfordern. Die Ausführungsstufen 450 und 460 umfassen eine Adressberechnungsphase 453, die eine virtuelle Adresse für eine Datenadresse bestimmt, eine DTLB Abbildungsphase 453, die Adressen für den Zugriff auf den Daten-Cachespeicher 220 abbildet, und eine Ergebnistransferphase, welche das Ergebnis der Operation für die Speicherung in dem der Operation entsprechenden Eintrag zurück gibt. Nach Abschluss einer Operation empfängt der Ablaufplaner 280 Ergebnisse, die spekulativ sind und nur übergeben werden, falls und wenn es sicher ist, dies zu tun.
  • 4D stellt die Behandlung von BrOps dar. Wenn der Befehlsdekodierer 240 einen CISC Verzweigungsbefehl dekodiert und eine BrOp erzeugt, bestimmt der Befehlsdekodierer 240 einen neuen Programmzähler für die nächsten zu dekodierenden CISC Befehl. Für nicht bedingte Verzweigungen gibt es keine Unsicherheit in dem neuen Programmzähler und der Befehlsdekodierer 240 schließt die nicht bedingte Verzweigung durch Ändern des Programmzählers ab. Der Befehlsdekodierer 240 enthält parallele Addierer für die schnelle Addition eines Offsets und des alten Werts des Programmzählers, um den neuen Wert des Programmzählers zu berechnen. Der Befehlsdekodierer 240 enthält auch einen Rückkehradressenstapel mit 16 Einträgen, in den Adressen von Befehlen, die Aufrufen von Subroutinen folgen, für eine spätere Vorhersage von Adressen von Befehlen nach Rückkehrbefehlen geschoben werden.
  • Für bedingte Verzweigungen sagt der Befehlsdekodierer 240 den Wert des Programmzählers, der einer bedingten Verzweigung folgt, vorher und fügt eine BRCOND in einen in den Ablaufplaner 280 geladenen Op Quad ein. In dem beispielhaften Ausführungsbeispiel ist die Verzweigungsvorhersage ein Verzweigungskorrelationsprozess, der im Stand der Technik manchmal als zwei Level Verzweigungsvorhersage bezeichnet wird. Das U.S. Patent Nummer 5,454,117 mit dem Titel "Configurable Branch Prediction for a Processor Performing Speculative Execution" beschreibt einen beispielhaften Verzweigungskorrelationsprozess, der verwendet werden kann. Die Verzweigungskorrelation sagt die Adresse eines nach einem Verzweigungsbefehl ausgeführten Befehls vorher.
  • Die Verzweigungsvorhersagelogik 248 in dem Befehlsdekodierer 240 verwendet eine Verzweigungsgeschichtstabelle (BHT) mit 8.192 Einträgen, wo bei jeder Eintrag der BHT zwei Standard Geschichtsbits enthält, die eine Tendenz für die Verzweigung anzeigen, ob sie genommen wird oder nicht. Die Einträge sind indiziert unter Verwendung einer Kombination von vier Bits des Programmzählers (PC) und neun Bits einer globalen Verzweigungsgeschichte, so dass, ob eine Verzweigung genommen wird oder nicht, nicht nur von der Adresse der Verzweigung sondern auch von dem Pfad vorher gesagt wird, den die Ausführung des Programms für das Erreichen der Verzweigung nahm. Dies stellt eine bessere Vorhersage der Verzweigung zur Verfügung, was die Chance, den Ablaufplaner 280 wie unten beschrieben entleeren zu müssen, verringert.
  • Falls der vorher gesagte oder geänderte Programmzähler in einem Verzweigungsziel-Cachespeicher mit 16 Einträgen des Befehlsdekodierers 240 trifft, ist der nächste CISC Befehl bereit zur Dekodierung an dem Ende der Stufe x86 Befehlsdekodierung 420. Ansonsten ist ein Taktzyklus 424 erforderlich, um eine Adresse zu berechnen und den nächsten CISC Befehl für die Dekodierung abzurufen.
  • Wie alle anderen in den Ablaufplaner 280 geladenen Operationen schieben bedingte Verzweigungsoperationen (BRCONDs) auf den Boden des Ablaufplaners 280 zu, wenn ältere Operationen zurückgezogen werden, aber keine Ausgabeauswahlabtastung wird für BRCONDs verwendet. Eine BRCOND tritt. in eine Stufe Bewertung Verzweigungsbedingung 490 ein, wenn die BRCOND die Zeile 4 des Ablaufplaners 280 erreicht. Die Verzweigungsbewertungseinheit 257 kann pro Takt eine BRCOND bewerten, vorausgesetzt, dass die für jede BRCOND erforderlichen Bedingungscodes (cc) gültig sind. Die Verzweigungsbewertungseinheit 257 bestimmt den korrekten der BRCOND folgenden Programmzähler und ob die BRCOND korrekt vorher gesagt wurde. Die erforderlichen Bedingungscodes sind wahrscheinlich gültig, wenn die BRCOND Zeile 4 erreicht, weil ältere Operationen (die in Zeilen 4 und 5) wahrscheinlich abgeschlossen worden sind. Falls die erforderlichen Bedingungscodes noch nicht gültig sind, wird die BRCOND aufgehalten durch ein Verhindern des Ausschiebens des Op Quads aus Zeile 4. Wenn eine BRCOND aufgehalten wird, werden Op Quads über der Zeile 4 daran gehindert, weiter zu schieben, es sei denn eine oder mehrere der Zeilen 0 bis 3 ist ein leerer (das heißt ungültiger) Op Quad. Falls jede der Zeilen 0 bis 3 gültige Op Quads enthält, kann der Befehlsdekodierer 240 keinen neuen Op Quad in den Ablaufplaner 280 laden, während die BRCOND aufgehalten wird. Das Schieben der Zeilen 4 und 5 wird ebenso aufgehalten, wenn das Schieben von Zeile 3 aufgehalten wird, weil das Schieben der Zeile 4 oder 5 die Erzeugung eines leeren Op Quads erfordern würde und das beispielhafte Ausführungsbeispiel einen leeren Op Quad nur in der obersten Zeile des Ablaufplaners 280 erzeugen kann.
  • Falls eine Verzweigung korrekt vorher gesagt wurde, macht die Abrufung, Dekodierung und Ausführung von Operationen ohne Unterbrechung weiter. Falls die Verzweigung nicht korrekt vorher gesagt wurde, startet der Ablaufplaner 280 den Befehlsdekodierer 240 erneut an der korrekten der BRCOND folgenden Befehlsadresse, so dass der Befehlsdekodierer 240 anfängt, die richtigen Befehle abzurufen und zu dekodieren, während Ergebnisse von Operationen, die älter sind als die falsch vorher gesagte Verzweigung, übergeben werden und aus dem Ablaufplaner 280 zurück gezogen werden. Das Laden von neuen Befehlen in den Ablaufplaner 280 wird verhindert, bis die falsch vorher gesagte BRCOND zurück gezogen ist und der Ablaufplaner 280 entleert ist. Wenn die falsch vorher gesagte BRCOND zurück gezogen ist, wird die Ausführungseinheit 250 entleert durch das ungültig Machen jeder Operation in dem Ablaufplaner 280 und in den Ausführungseinheiten 251 bis 257. Alle Operationen können ungültig gemacht werden, weil alle der falsch vorher gesagten BRCOND vorangehenden Operationen abgeschlossen und zurück gezogen worden sein müssen, bevor die falsch vorher gesagte Verzweigung aus der unteren Reihe des Ablaufplaners 280 ausschiebt, und kein neuer Befehl wird in den Ablaufplaner 280 geladen, bevor die falsch vorher gesagte Verzweigung zurück gezogen wird. Das ungültig Machen aller Operationen vereinfacht den Prozess, da keine Identifikation, welche Operationen zurück gehalten werden müssen, erforderlich ist. Das Verzögern des Ladens von neuen Befehlen hat eine minimalen Auswirkung auf die Leistungsfähigkeit, weil üblicherweise die falsch vorher gesagte Verzweigung zu der untersten Reihe schiebt und nach zwei Taktzyklen zurück gezo gen wird, was in etwa dieselbe Zeitspanne ist, die der Befehlsdekodierer 240 benötigt, um die ersten neuen Befehle abzurufen und zur Verfügung zu haben.
  • Die Ausführungsmaschine 250 führt abbrechbare und nicht abbrechbare Operationen durch. Nicht abbrechbare Operationen können nicht spekulativ ausgeführt werden und werden nur ausgeführt, wenn die Ergebnisse sicher übermittelt werden können. Abbrechbare Operationen werden spekulativ ausgeführt. Nachdem eine abbrechbare Operation die letzte Stufe ihrer Pipeline erreicht und abgeschlossen ist, wird jedes Ergebnis der Ausführung in dem Ablaufplaner 280 gespeichert, bis die Operationsübergabeeinheit 260 bestimmt, dass die Übergabe der Ergebnisse sicher ist. Jeden Takt kann einen Op Quad (bis zu vier Operationen) übergeben und aus dem Ablaufplaner 280 zurück gezogen werden.
  • II. Ablaufplaner
  • 5 zeigt das beispielhafte Ausführungsbeispiel, in dem der Ablaufplaner 280 24 Einträge enthält, die mit bis zu 24 Operationen verbunden sind. Jeder Eintrag enthält Speicherelemente (tatsächlich Flip-Flops) in einem Ablaufplanungsreservoir 540 und Logikbereiche 530, 532, 534, 536 und 538, die mit jedem Eintrag verbunden sind. Die Speicherelemente speichern Informationen hinsichtlich einer Operation (Op), welche auf eine Ausführung wartet, ausgeführt wird oder abgeschlossen ist. Ein Operationsdekodierer 510 empfängt von dem Befehlsdekodierer 240 vier RISC86® Operationen und lädt oder leitet einen neuen Op Quad in die oberste Zeile des Ablaufplanungsreservoirs 540 ein. Die Felder in dem Reservoir 540 sind in 7 gezeigt und sind mit den Feldern der in 3 gezeigten verbundenen RISC86® Befehle verwandt, aber nicht identisch. Einige Felder behalten den gleichen Wert durch die Ausführung der verbundenen Operation bei und werden hier als "statische Felder" bezeichnet. Andere Felder werden später geladen oder geändert, wenn zum Beispiel die Operation die Ausführung abschließt, und werden als "dynamische Felder" bezeichnet.
  • Die Speicherelemente in dem Ablaufplanungsreservoir 540 können locker als ein Schieberegister angesehen werden, das eine Tiefe von sechs Zeilen hat. Jede Zeile enthält vier Einträge, jeder Eintrag ist mit einem RISC86® Befehl verbunden. Jeden Taktzyklus wird ein Op Quad, der nicht in einer Zeile aufgehalten wird, zu der nächsten Zeile runter geschoben, falls die nächste Zeile leer ist oder einen Op Quad enthält, der ebenfalls nach unten geschoben wird. Der Op Quad in der untersten Zeile (Zeile 5) schiebt aus dem Ablaufplaner 280 raus, wenn alle mit der untersten Zeile verbundenen Operationen übergeben worden sind.
  • 6 zeigt ein Ausführungsbeispiel eines Bereichs des Ablaufplanungsreservoirs 540. Der Bereich des in 6 gezeigten Bereichs des Ablaufplanungsreservoirs 540 enthält ein Speicherelement (flankengesteuertes Flip-Flop 623) für ein dynamisches Feld in Zeile 3 des Ablaufplaners 280 und ein Speicherelement (flankengesteuertes Flip-Flop 643) für ein statisches Feld in der gleichen Zeile. Die Zeile 3 enthält ähnliche Speicherelemente für jedes Bit in den dynamischen und statischen Feldern wie in 6 gezeigt und unten beschrieben. Die anderen Zeilen in dem Ablaufplanungsreservoir 540 sind ähnlich oder identisch wie Zeile 3 und sind in Reihe mit Zeile 3 geschaltet.
  • In 6 speichern die Flip-Flops 642, 643 und 644 ein Bit des selben statischen Felds in den jeweiligen Zeilen 2, 3 und 4; und ein mit einem Op Quad verbundener Bitwert schiebt von dem Flip-Flop 642 zu dem Flip-Flop 644, wenn der Op Quad von Zeile 2 zu Zeile 4 schiebt. Eine globale Steuerlogik 520 erzeugt die Signale LdEntry[i], eines für jede Zeile (i = 0 bis 5), die steuern, ob Schiebungen für die entsprechende Zeile auftreten. Die Zeilen werden bei der ansteigenden Flanke des Taktsignals CLK überschrieben. Zum Beispiel gibt das Signal LdEntry3 das Flip-Flop 643 entweder frei oder sperrt es und ein Signal LdEntry4 gibt das Flip-Flop 644 entweder frei oder sperrt es. Entsprechend wird, wenn ein Op Quad in Zeile 4 aufgehalten wird, das Signal LdEntry4 zurück genommen, so dass das Flip-Flop 644 einen Wert zurückhält. Die Unabhängigkeit der Signale LdEntry[i] erlaubt das Füllen von leeren Einträgen der Op Quads, die oberhalb eines aufgehaltenen Op Quads sein können. Zum Beispiel kann, wenn ein Op Quad in Zeile 4 aufgehalten wird, das Signal LdEntry3 angelegt werden, so dass ein Wert OpField2 von Zeile 2 mit der steigenden Flanke des Taktsignals CLK in Zeile 3 schiebt. (Leere Zeilen können das Ergebnis sein, falls zum Beispiel der Befehlsdekodierer 240 nicht fähig ist, jeden Takt einen Op Quad zur Verfügung zu stellen wegen eines Fehltreffers in dem Verzweigungsziel-Cachespeicher.) Die Tabelle B.1 in dem Anhang B beschreibt die Operation einer Schaltung, die statische Felder implementiert.
  • Dynamische Felder sind komplizierter als statische Felder, da neue Daten von außerhalb des Ablaufplanungsreservoirs 540 in ein dynamisches Feld eingefügt werden können, während alte Daten verschoben werden, und die neuen Daten bei dem korrekten Op Quad bleiben müssen, der zu der nächsten Zeile verschieben kann oder nicht. Die Signale OpFieldValue2 und OpFieldValue3 stellen Informationen dar, die mit entsprechenden ersten und zweiten Op Quads in Zeilen 2 und 3 verbunden sind. Eine Schaltung außerhalb des Ablaufplanungsreservoirs 540 erzeugt Signale NewValue2 und NewValue3, um die mit den ersten beziehungsweise zweiten Op Quads verbundenen Informationen zu verändern. Ein Multiplexer 632 wählt aus, ob ein neues Informationssignal NewOpField2 sich zu einem neuen Wert NewValue2 ändert, um den ersten Op Quad zu verändern, oder ob es gleich bleibt mit dem alten Wert OpFieldValue2. Ein Multiplexer 633 wählt aus, ob ein neues Informationssignal NewOpField3 sich zu einem neuen Wert NewValue3 ändert oder ob es gleich bleibt mit dem alten Wert OpFieldValue3.
  • Ob die mit dem ersten Op Quad verbundenen Werte des dynamischen Felds sich verändern oder nicht, der Wert NewOpField2 kann mit der steigenden Flanke des Taktsignals CLK in Zeile 2 oder Zeile 3 geschrieben werden. Um den ersten Op Quad in Zeile 2 zu schieben, veranlasst das Signal LdEntry3 einen Multiplexer 613, das Signal NewOpField2 als Signal NextOpField3 auszuwählen, das mit der steigenden Flanke des Taktsignals CLK in das Flip-Flop 623 geschrieben wird. Um den ersten Op Quad daran zu hindern, in Zeile 3 verschoben zu werden, veranlasst das Signal LdEntry3 den Multiplexer 613, das Signal NewOpField3 auszuwählen, das in das Flip-Flop 23 ge schrieben wird. Das Signal LdEntry4 und der Multiplexer 614 wählen auf ähnliche Weise aus, ob es dem zweiten Op Quad erlaubt wird, von Zeile 3 in Zeile 4 zu verschieben. Die Tabelle B.2 im Anhang B beschreibt die Operation einer Schaltung, die statische Felder implementiert.
  • II.A. Laden des Ablaufplaners
  • Der Befehlsdekodierer 240 dekodiert Makrobefehle und bildet Sätze von vier RISC86 Befehlen, welche an den Ablaufplaner 280 übermittelt werden, immer wenn Zeile 0 (die Spitze) des Ablaufplaners 280 leer ist oder einen Op Quad enthält, der in Zeile 1 verschoben wird. Das Emcode ROM 246 kann einen Op Quad enthalten, wobei nicht alle der Operationen in dem Op Quad tatsächlich Teil einer Implementierung eines x86 Befehls sein müssen. Dies kann auftreten, weil verschiedene x86 Befehle unterschiedliche Eintrittspunkte in dem gleichen Code in dem Emcode ROM 246 haben oder weil eine Operation in dem Emcode ROM 246 eine Verzweigung in die Mitte eines Op Quads veranlasst. Befehle, für die für den x86 Befehl eine Kodierung nicht erforderlich ist, werden auf Null gesetzt (in NO-Ops geändert). Die Dekodierung von Befehlen enthält auch die Ersetzung von Umgebungsvariablen für Felder von Operationen. Für die Ersetzung von Variablen unterhält eine Emulation der Umgebung Umgebungsvariablen, die zum Beispiel eine Vorgabeadresse und Datengrößen und Registernummern für das derzeitige Codesegment und den x86 Befehl, der dekodiert wird, umfassen. Die Umgebungsvariablen ersetzen Platzhalterwerte in Operation von dem Emcode ROM 246. Die Ersetzung mit Umgebungsvariablen erhöht die Flexibilität des Emcode ROMs 246, weil verschiedene Umgebungsvariablen eine Emcode Sektion konvertierten, um verschiedene x86 Befehle zu implementieren. Der Befehlsdekodierer 240 und/oder der Operationsdekodierer 510 führen wie erforderlich die Ersetzung mit Umgebungsvariablen durch.
  • In dem Ablaufplaner 280 empfängt der Operationsdekodierer 510 einen Op Quad von dem Befehlsdekodierer 240 und füllt die Speicherfelder in der obersten Zeile des Ablaufplanungsreservoirs 540. Falls kein Op Quad von dem Befehlsdekodierer 240 verfügbar ist, erzeugt der Operationsdekodierer 510 einen leeren Op Quad, wenn der Op Quad in der obersten Zeile nach unten schiebt.
  • 7 stellt ein Beispiel von statischen Eintragsfeldern 541, dynamischen Eintragsfeldern 542 und Op Quad Feldern 549 in dem Ablaufplanungsreservoir 540 dar. Die anfänglichen Werte der Eintragsfelder 541 und 542 hängen von den entsprechenden x86 Befehlen ab. Der Operationsdekodierer 510 modifiziert einige Felder von den RISC86 Befehlen basierend auf anderen Feldern, leitet neue Felder von existierenden ab und leitet einige Felder durch nicht geänderte. Felder von Op Quads werden aus Informationen erzeugt, die dem Op Quad als ganzem entsprechen.
  • II.A.1. Statische Felder Eintrag
  • In dem beispielhaften Ausführungsbeispiel enthält jeder Eintrag statische Felder 541, welche wie folgt definiert sind, wobei alle Signale aktiv hoch sind.
  • Das Feld Type[2:0] gibt den Typ der mit dem Eintrag verbundenen Operation an. Mögliche Typen umfassen: SpecOp; LdOp; StOp; StOp, die auf den Speicher verweist oder eine fehlerhafte Adresse erzeugt; RegOp, nur ausführbar von der Registereinheit 352; und RegOp, ausführbar von jeder Registereinheit 253 oder 254. Die Multimediaeinheit 256 führt ausgewählte Typen von RegOps durch, die mit Multimediaanwendungen zusammen hängen. Gleitkomma Operationen (FpOps) sind ein Typ von SpeOps, die von der Gleitkommaeinheit 255 ausgeführt werden. Die Tabelle B.3 im Anhang B beschreibt eine Schaltung im Operationsdekodierer 510, die einen Wert für das Feld Type erzeugt.
  • Das Feld LD_Imm zeigt an, ob die Operation einen unmittelbaren Wert von einer vorher gehenden LIMMOp benötigt. Der unmittelbare Wert ist eine große Versetzung, falls die Operation eine LdStOp ist, die eine große Versetzung gegenüber einer kleinen (8-Bit) Versetzung verwendet, die in dem Feld DestVal des Eintrags gehalten wird. Für eine RegOp ist der unmittelba re Wert der zweite Operand Src2. Die Tabelle B.4 im Anhang B beschreibt eine Schaltung im Operationsdekodierer 510, die einen Wert für das Feld Ld_Imm erzeugt.
  • Die Felder Src1Reg[4:0], Src2Reg[4:0] und SrcStReg[4:0] halten Registernummern, die Register identifizieren, die den ersten Quelloperanden Src1, den zweiten Quelloperanden Src2 beziehungsweise den Speicherdatenoperanden der Operation halten. Die Tabellen B.5, B.6 und B.7 in dem Anhang B beschreiben eine Schaltung im Operationsdekodierer 510, die einen Wert für die Felder Src1Reg, Src2Reg und SrcStReg erzeugt.
  • Das Feld DestReg[4:0] hält eine Registernummer, die das Zielregister der Operation identifiziert. Die Tabelle B.8 in dem Anhang B beschreibt eine Schaltung im Operationsdekodierer 510, die einen Wert für das Feld DestReg erzeugt.
  • Die Felder zeigen an, welche Bytes der Operanden Src1 und Src2 für die Ausführung der Operation gültig sein müssen. Per Definition sind Src1BM[1:0] und Src2BM[1:0] gleich zu Src12BM[2]. Die Bits 2, 1 und 0 von Src1BM[1:0] und Src2BM[1:0] zeigen die Bits [31:16], [15:8] beziehungsweise [7:0] an. Die Tabelle B.9 in dem Anhang B beschreibt eine Schaltung im Operationsdekodierer 510, die einen Wert für die Felder Src1BM[1:0], Src2BM[1:0] und Src12BM[2] erzeugt.
  • Das Feld SrcStBM[2:0] zeigt an, welche Bytes der Speicherdatenoperanden für den Abschluss einer StOp erforderlich sind. Die Bitübereinstimmung ist die gleiche wie für Src1BM oder Src2BM. Die, Tabelle B.10 beschreibt eine Schaltung im Operationsdekodierer 510, die einen Wert für das Feld SrcStBM erzeugt.
  • Das Feld OpInfo[2:0] hält zusätzliche Informationen für die Ausführungseinheiten oder die Operationsübergabeeinheit (OCU) in Abhängigkeit, ob die Operation ausführbar ist. Das Feld OpInfo hat drei mögliche Felddefinitionen, abhängig davon, ob die Operation eine RegOp, eine LdStOp oder eine SpecOp ist. Für eine RegOp enthält das Feld OpInfo eine Verkettung von: sechs Bits von dem RISC86 Type Feld, vier Bits von dem RISC86 Ext Feld, das RISC86 R1 Feld und zwei Bits, die eine effektive Datengröße DataSz für die Operation anzeigen. Für eine LdStOp enthält das Feld OpInfo eine Verkettung von: vier Bits von dem RISC86 Type Feld, zwei Bits von dem RISC86 ISF Feld, vier Bits von dem RISC86 Seg Feld, zwei Bits, die die effektive Datengröße DataSz für die Operation anzeigen, und ein Bit AddrSz, das die effektive Größe der Adresse für die Berechnung der Adresse anzeigt (32/16 Bit). Für eine SpecOp enthält das Feld OpInfo eine Verkettung von vier Bits von dem RISC86 Type Feld und fünf Bits von dem RISC86 cc Feld. Die Tabelle B.11 beschreibt eine Schaltung im Operationsdekodierer 510, die einen Wert für das Feld OpInfo erzeugt.
  • II.A.2. Dynamische Felder Eintrag
  • Die dynamischen Eintragsfelder werden von dem Operationsdekodierer 510 initialisiert, aber können sich während der Ausführung von Operationen ändern. Üblicherweise enthält jeder Eintrag eine Logik zum Ändern von dynamischen Feldern wie erforderlich. Die dynamischen Felder 542 für einen Eintrag sind in dem beispielhaften Ausführungsbeispiel wie folgt definiert.
  • Das Feld State[3:0] zeigt den Zustand der Ausführung einer Operation im Hinblick auf die Pipelines der 4A bis 4D an. (S3, S2, S1 und S0 sind wechselnde Signalnamen für State[3:0]). Das Feld State kodiert fünf mögliche Zustände durch das Schieben eines Felds von Einsen durch vier Bits. Der Wert b0000 beschreibt einen "nicht ausgegeben" Zustand; b0001, b0011 und b0111 zeigen eine Operation an in der Stufe Operandenweiterleitung, der Stufe Ausführung 1 und der Stufe Ausführung 2 an und b1111 zeigt an, dass die Operation abgeschlossen ist. Die meisten Operationen betreten den Ablaufplaner 280 mit dem Feld State auf b0000 " nicht ausgegeben" gesetzt und das Feld State ändert sich, nachdem die Operation an eine Ausführungsstufe ausgegeben ist. Das Feld State wird aktualisiert (tatsächlich geschoben), wenn die Operation ausgegeben wird oder aus einer Stufe der Pipeline vorrückt. Nach dem Abschließen der Pipeline wird das Feld State auf b1111 gesetzt, während die Operation darauf wartet, übergeben und zurück gezogen zu werden. Das Feld State jedes Eintrags wird während eines Abbruchzyklus auf b1111 gesetzt. Einige Operationen (zum Beispiel Lade konstant Operation) haben einen anfänglichen Wert des State Feldes von 1111 und sind daher bereits abgeschlossen, wenn sie in den Ablaufplaner 280 geladen werden. Die Tabelle B.12 beschreibt Schaltung in dem Operationsdekodierer 510, die das Feld State initialisiert, und Schaltungen in den Einträgen des Ablaufplaners 280, die das Feld State während der Ausführung der verbundenen Operation verändern.
  • Das Feld Exec1 zeigt an, dass die Registereinheit 253 (nicht 254) eine Operation ausführt, und ist gesetzt, wenn die Operation erfolgreich an die Ausführungseinheit 253 ausgegeben worden ist. Die Tabelle B.13 zeigt die Logik, welche das Feld Exec1 setzt und ändert.
  • Das Feld DestBM[2:0] hält Bytemarkierungen, die anzeigen, welches Byte des von dem Feld DestReg angezeigten Registers von der Operation modifiziert wird. DestBM[2], DestBM[1] und DestBM[0] entsprechen den Bits [31:16], [15:8] beziehungsweise [7:0]. Das Feld DestBM wird von dem Operationsdekodierer 510 initialisiert und kann während eines Abbruchzyklus gelöscht werden. Die mit dem Feld DestBM verbundene Logik ist in Tabelle B.14 des Anhangs B beschrieben.
  • Das Feld DestVal[31:0] hält Ergebnisse von der Ausführung der Operation, die an DestReg übergeben werden sollen. DestBM zeigt an, welche Bytes nach der Ausführung einer Operation gültig sind. Das Feld DestVal wird geladen, wenn die Operation die Ausführungsstufe 1 oder 2 abschließt (abhängig von dem Typ der Operation); für nicht ausgeführte Operationen (zum Beispiel LDK) wird DestVal mit dem geeigneten Wert des Ergebnisses initialisiert. Das Feld DestVal kann zum temporären Speichern verwendet werden, bevor die Ergebnisse gespeichert werden, wenn eine Operation abgeschlossen wird. In dem beispielhaften Ausführungsbeispiel hält das Feld DestVal anfänglich unmittelbare und Versetzungswerte für RegOps beziehungsweise LdStOps und den wechselnden (sequentiell oder Ziel) Wert des Verzweigungsprogrammzählers für eine BRCOND. Die mit dem Feld DestVal verbundene Logik ist in Tabelle B.15 des Anhangs B beschrieben.
  • Das Feld StatMod[3:0] hält Markierungen für Statusgruppen, die anzeigen, welche Gruppen von Status Flags eine Operation verändert. Die Bits 3, 2, 1 beziehungsweise 0 entsprechen den Gruppen der Flag Bits {EZF, ECF}, OF, {SF, ZF, AF, PF} und CF, wobei die Flag Bits EZF; ECF, OF, SF, AF, PF und CF von RegOps verändert werden können. Das Feld StatMod enthält für nicht Reg-Ops nur Nullen und wird während Abbruchzyklen gelöscht. Die mit dem Feld StatMod verbundene Logik ist in Tabelle B.16 des Anhangs B beschrieben.
  • Das Feld StatVal[7:0] hält den Ergebniswert des Status der Operation, der an die Status Register Eflags zu übergeben ist. StatMod zeigt an, welche Flag Gruppen nach der Ausführung betroffen sind. StatVal ist nur für RegOps von Bedeutung, dies wird von StatMod berücksichtigt. StatVal wird geladen, wenn die RegOp die Stufe Ausführung 1 abschließt. Die mit dem Feld StatVal verbundene Logik ist in Tabelle B.17 des Anhangs B beschrieben.
  • Die Felder OprndMatch_XXsrcY, wobei "XX" LU, SU, RUX oder RUY ist und "Y" 1 oder 2 ist, sind zusätzliche Speicherelemente für übergehende Information, die zwischen zwei Stufen der Pipeline übergeht, im Gegensatz zu Information von eher globaler Wichtigkeit. Die Tabelle B.18 in dem Anhang B beschreibt Logik, welche die Felder OprndMatch_XXsrcY steuert.
  • Das Feld DBN[3:0] hält vier Datenbreakpoint-Statusbits Bn (n = 0 bis 3) für eine LdStOp. Dieses Feld hat anfänglich nur Nullen, dann, wenn die verbundene LdStOp ausführt, werden zum späteren Fangen Breakpointbits von der entsprechenden Einheit aufgezeichnet. Die mit dem Feld DBN[3:0] verbundene Logik ist in Tabelle B.19 des Anhangs B beschrieben.
  • II.A.3. Op Quad Felder
  • Jede Zeile in dem Ablaufplaner 280 enthält vier Einträge plus den Op Quad Feldern 549, die mit dem Op Quad als ganzem verbunden sind. Das Folgende zählt die in 7 gezeigtem zusätzlichen Op Quad Feldern 549 auf. Der Operationsdekodierer 510 initialisiert die Op Quad Felder. Die meisten Op Quad Felder sind statisch. Einige Op Quad Felder sind dynamisch und eine Logik in jeder Zeile des Ablaufplaners 280 ändert das dynamische Op Quad Feld wie erforderlich.
  • Das Feld Emcode zeigt an, ob die Op Quad von dem MacDec 242 oder dem Einsprungdekodierer 244 (das heißt Emcode ROM 246) ist. Die Tabelle B.20 beschreibt das Setzen des Feldes Emcode.
  • Das Feld Eret zeigt an, ob dies ein Emcode Op Quad ist und ob der als letzter Op Quad in einer Reihe von Op Quads, darstellend einen komplexen Makrobefehl, markiert ist. Die Tabelle B.20 beschreibt Logik, welche das Feld Eret setzt.
  • Das Feld FaultPC[31:0] hält den logischen Wert des Programmzählers für einen Fehler eines Makrobefehls, der mit den ersten Operationen in der Zeile verbunden ist. Die Operationsübergabeeinheit 260 verwendet das Feld FaultPC, wenn sie Fehlerausnahmen behandelt. Die Tabelle B.21 beschreibt Logik, welche das Feld FaultPC setzt.
  • Das Feld BPTInfo[14:0] hält auf die Tabelle zur Verzweigungsvorhersage bezogene Information von dem Zeitpunkt, zu dem der Op Quad erzeugt wurde. Das Feld BPTInfo ist nur für von dem MacDec erzeugte Op Quads definiert, die eine BRCOND enthalten. Die Tabelle B.22 beschreibt Logik, welche das Feld BPTInfo setzt.
  • Das Feld RASPtr[2:0] hält einen Zeiger auf den Rückkehradressenstapel zu dem Zeitpunkt, an dem der Op Quad erzeugt wurde. Das Feld RASPtr ist nur für von dem MacDec erzeugte Op Quads definiert, die eine BRCOND enthalten. Die Tabelle B.23 beschreibt Logik, welche das Feld RASPtr setzt.
  • Das Feld LimViol zeigt an, dass der Op Quad die Dekodierung eines Transfersteuerbefehls ist, für den eine Verletzung der Codesegmentgrenze an der Zieladresse festgestellt wurde. Für die meisten Zeilen ist das Feld LimViol statisch. Das Feld LimViol wird in Zeile 1 geladen wie in der Tabelle B.25 in dem Anhang B zusammengefasst ist.
  • Das Feld OpQV zeigt an, ob die Zeile einen gültigen Op Quad enthält, und die globale Logik 520 verwendet das Feld OpQV, wenn die das Schieben der Op Quads steuert. Ungültige Op Quads können überschrieben werden, wenn ein Op Quad, der niedriger in dem Ablaufplaner 280 ist, aufgehalten wird. Die Felder in einer Zeile, die einen "ungültigen" Op Quad enthalten, haben die gleichen Werte wie ein abgebrochener Op Quad, und ein Op Quad kann als Ergebnis eines Abbruchs ungültig werden. Die Tabelle B.26 beschreibt Logik, welche das Feld OpQV steuert.
  • Die Felder Op11, Op21 und Op31 halten einen Zähler (1, 2 oder 3) der Anzahl der Makrobefehle, die von einem Op Quad repräsentiert werden, und werden verwendet, um zurück gezogene Befehle zu zählen.
  • Die Felder Ilen0 und Ilen1 halten Längen in Bytes des ersten und (falls vorhanden) zweiten Makrobefehls, die von einem Op Quad repräsentiert werden, und werden verwendet, um die Adresse des Befehls zu bestimmen, an der ein Fehler auftrat.
  • Die Felder Smc1stAddr, Smc1stPg, Smc2ndAddr und Smc2ndPg halten die erste und (falls Befehle von mehr als einer Seite in dem Op Quad sind) die zweite Adresse, die von den Operationen in dem Op Quad abgedeckt sind, und werden verwendet, um den selbst modifizierenden Modus zu detektieren.
  • II.B. Lade/Schiebe Steuerung
  • Wie zuvor beschrieben verwaltet der Ablaufplaner 280 24 Einträge als ein Schieberegister (oder FIFO Puffer), das sechs Zeilen enthält. Der Ablaufpla ner 280 ist nicht dahingehend so starr wie ein Schieberegister, dass jede Zeile eine unabhängige Schiebesteuerung hat (tatsächlich ein Ladesteuersignal LdEntry[i]). Ein Op Quad kann in die nächste Zeile runter geschoben werden (und der vorhergehende Op Quad kann von oben in diese Zeile runter geschoben werden) solange die nächste Zeile leer ist oder leer gemacht wird. Op Quads schieben immer nach unten in Zeilen mit höheren Nummern, wenn Platz zur Verfügung steht. Idealerweise schiebt jeder Op Quad eine Zeile pro Taktzyklus nach unten, bei einer Grenze des Taktzyklus.
  • Für die meisten Operationen ist die Position in dem Ablaufplaner 280 unabhängig von der Stufe der Pipeline für die Operation. Entsprechend schieben die meisten Operationen in dem Ablaufplaner 280 nach unten, sogar wenn sie in einer Ausführungspipeline aufgehalten werden. Zwei Ausnahmen sind Operationen, die von Status Flags abhängig sind und jede Operation in der untersten Zeile des Ablaufplaners 280. Operationen, die von Status Flags abhängig sind, haben eine Stufe, die ausgeführt werden muss, wenn die Operation in einer bestimmten Zeile des Ablaufplaners 280 ist, und damit ein Schieben verhindert, bis die Stufe abgeschlossen ist. Operationen in Zeile 5 verhindern ein Schieben oder Zurückziehen eines Op Quads von Zeile 5, bis alle Operationen in Zeile 5 abgeschlossen und übergeben sind.
  • Die Tabelle B.27 in dem Anhang B beschreibt Schaltung in der globalen Steuerlogik 520, welche die Signale LdEntry0 bis LdEntry5 erzeugt, die das Schieben in dem Ablaufplaner 280 steuern, und welche SchedFull und SchedEmpty signalisiert, die anzeigen, ob der Ablaufplaner 280 einen neuen Op Quad an dem Ende des derzeitigen Zyklus akzeptieren kann.
  • III. Ausführung Operation
  • Physikalisch ist das Ablaufplanungsreservoir 540 eine Speicherstruktur, die Statuswerte für Operationen hält. Zusätzlich zu dem Ablaufplanungsreservoir 540 enthält der Ablaufplaner 280 eine Logik, die auf den Statuswerten während der Ausführung einer Operation arbeitet. Von einer Perspektive der Steuerung ist der Ablaufplaner 280 ein Datenpfad in Form einer Pipeline, der Steuerinformationen für die Ausführung von Operationen durch Verarbeitungspipelines erzeugt und Ergebnisse von Ausnahmen behandelt. Speichern in dem Ablaufplaner und Änderungen des Status sind synchron mit dem Systemtakt, das heißt alle Änderungen des Status in dem Ablaufplaner 280 sind an der steigenden Flanke des Systemtakts, so dass alle Speicherelemente in dem Ablaufplaner 280 (zumindest logisch) flankengesteuerte Flip-Flops sind, wie die im Hinblick auf 6 beschriebenen. Von einer Perspektive der Logik sind alle Sequenzen der Status tatsächlich ein einzelner Zyklus. Entscheidungen über die Übergänge von Status werden jeden Zyklus basierend auf der Zustandsmaschine während des Zyklus gemacht.
  • Die Struktur des Ablaufplaners 280 berücksichtigt den pipelineartigen Typ der Ausführung von Operationen. Die Logik in dem Ablaufplaner 280 (und entsprechend jedes Eintrags) kann in viele bestimmte, größtenteils unabhängige Stücke von Logik unterteilt werden, von denen jedes direkt einer bestimmten Verarbeitungsstufe eines gegebenen Typs einer Operation oder einer Ausführungspipeline zugeordnet ist. Von der Perspektive einer bestimmten Verarbeitungspipeline stellt ein Stück von Logik des Ablaufplaners, die jeder Stufe zugeordnet ist, eine Schlüsselsteuerinformation für die in dieser Stufe vorgenommene Verarbeitung und/oder für die Bestimmung, wann die Stufe erfolgreich abschließen kann, zur Verfügung. Von der Perspektive einer gegebenen Stufe, wie über alle verarbeitenden Pipelines betrachtet (zumindest für die ersten paar Stufen), führen sehr ähnliche Stücke an Logik die gleiche Funktion für jede Pipeline oder für jeden Quelloperanden einer Operation für jede Pipeline durch.
  • Die 4A bis 4D zeigen den zeitlichen Ablauf der Pipeline für vier Typen von Operationen. Für diese Typen wird eine Operation nach der Stufe Befehlsdekodierung 420 in den Ablaufplaner 280 geladen. Eine BrOp wird in der Stufe Bewertung Verzweigung 490, die auftritt, wenn die BrOp Zeile 4 des Ablaufplaners 280 erreicht, abgeschlossen. RegOps, StOps und LdOps gehen durch eine Pipeline mit drei oder vier Stufen und gehen entsprechend zwischen vier oder fünf Zuständen über. Das Feld State[3:0] in einem Ein trag des Ablaufplaners verfolgt oder repräsentiert die Stufe der Operation, die mit dem Eintrag verbunden ist.
  • Die Stufe Ausgabe Op 430 und die Stufe Weiterleitung Operanden 440 der 4A und 4C sind für alle RegOps, LdOps und StOps üblich und werden folgend beschrieben.
  • Folgend auf die Stufe Weiterleitung Operanden 430 sind die Ausführungsstufen. Die RegOps haben lediglich eine Stufe Ausführung 450, weil die Registereinheiten 253 und 254 alle RegOps in einem einzelnen Takt ausführen. Des weiteren, sobald eine RegOp die Stufe Ausführung 450 betritt, beendet sie immer erfolgreich die Stufe 450 und verlässt diese an dem Ende von diesem Taktzyklus. Die LdOps und StOps haben zwei Ausführungsstufen 450 und 460, während derer die Berechnung der Adresse 453, eine Abbildung der Übersetzung von dem Segment und von der Seite (und eine Überwachung des Schutzes) und des Daten-Cachespeichers 455 und der Transfer der Ergebnisse 462 statt finden. Anders als RegOps können LdOps und StOps für Vermittlungsperioden in jeder Stufe 450 oder 460 gehalten werden. Die meisten Aufhaltungen von LdOps (am meisten anzumerken sind Fehltreffer und Fehler in dem Daten-Cachespeicher und dem Datenübersetzungsseitenblickpuffer (DTLB)) treffen auf die letzte Stufe 460 zu. Aufhaltungen in der Stufe 450 stammen von falsch ausgerichteten Speicherreferenzen und daher, dass die Stufe 460 von einer Operation besetzt und blockiert wird, die nicht zum Anschluss vorrückt.
  • Der Ablaufplaner 280 steuert von den Ausführungsmaschinen erzeugte Pipelines, wie die Ladeeinheit 251, die Speichereinheit 252, die Registereinheiten 253 und 254, die Gleitkomma Einheit 255 und die Multimediaeinheit 256. Das beispielhafte Ausführungsbeispiel der Erfindung enthält die Registereinheiten 253 und 254, die Ladeeinheit 251 und die Speichereinheit 252. Die Anwendung von Aspekten der Erfindung auf Prozessoren, die mehr oder weniger Ausführungseinheiten haben, wird angesichts dieser Offenbarung ersichtlich werden. Zum Beispiel kann in einem Ausführungsbeispiel, das die Multimediaeinheit 256 enthält, die Multimediaeinheit 256 logisch als Teil der ersten Registereinheit 253 betrachtet werden, so dass für die Multimediaeinheit 256 Operationen ausgegeben, Operanden weiter geleitet und Ergebnisse übermittelt werden unter Verwendung von Schaltung für die Registereinheit 253.
  • In einem Ausführungsbeispiel hat die Gleitkomma Einheit (FPU) 255 ihre eigene unabhängige Registerdatei und Übergabeeinheit; und der Ablaufplaner 280 enthält eine Abtastungskette, um FpOps für die Ausgabe an die FPU 255 auszuwählen.
  • Der Ablaufplaner 280 gibt eine FpOp aus und leitet Operanden an die FPU 255 weiter. Die Ausführung der FpOp betrifft nur Register in der Registerdatei, die der FPU 255 zugeordnet sind, so dass der Ablaufplaner 280 keine Ergebnisse von der FPU 255 benötigt. Die FPU 255 kann signalisieren, dass eine FpOp unmittelbar abgeschlossen ist, lange bevor die FPU. 255 die FpOp tatsächlich abschließt oder übergibt. Die OCU 260 übergibt die FpOp und zieht sie aus dem Ablaufplaner 280 zurück ohne etwas zu ändern.
  • Jede der Registereinheiten 253 und 254 stellt eine Pipeline zur Verfügung, die als RU Pipeline oder als RUX oder RUX Pipeline bezeichnet wird, um die Registereinheit 253 von der Registereinheit 254 zu unterscheiden. Jede RU Pipeline hat drei Stufen, auf die als Stufe Ausgabe 430, Stufe Weiterleitung Operanden 440 und Stufe Ausführung 450 Bezug genommen werden. Die Ladeeinheit 251 beziehungsweise die Speichereinheit 252 stellen die LU beziehungsweise SU Pipelines zur Verfügung, die vier Stufen haben: die Stufe Ausgabe 430, die Stufe Weiterleitung Operanden 440 und die Stufen Ausführung 450 und 460. Wie oben beschrieben repräsentiert das Feld State fünf Zustände einer Operation unter Verwendung einer "Verschieben/Erhöhen von Feldern von Einsen" Kodierung, um die derzeitige Stufe der Pipeline der verbundenen Operation anzuzeigen oder um anzuzeigen, dass die Operation ihre Pipeline abgeschlossen hat.
  • Der Ablaufplaner 280 hat eine primäre Steuerung über die Stufen Ausgabe 430 und die Stufen Weiterleitung Operanden 440. Die Verarbeitung inner halb der Stufen Ausgabe 430 und Weiterleitung Operanden 440 ist in zwei Phasen pro Stufe unterteilt, wobei die Phasen dem Namen nach während der ersten und zweiten Hälften des System Taktzyklus auftreten. Die Stufe Ausgabe 430 enthält eine Operandenauswahlphase 431 und eine Ausbreitungsphase 432. Die Stufe Weiterleitung Operanden 440 enthält eine Operandenauswahlphase 441 und eine Operandentransferphase 442.
  • Während der Operandenauswahlphase 431 wählt der Ablaufplaner 280 die nächsten Operationen aus, die jede der Pipelines betreten sollen. In dem beispielhaften Ausführungsbeispiel geschehen zum Beispiel vier Operationsauswahlen zur gleichen Zeit für die LU, SU, RUX und RUX Pipelines. Während der Ausbreitungsphase 432 werden Informationen über die Operanden jeder ausgewählten Operation an alle Einträge in dem Ablaufplaner und an die externe Logik verbreitet.
  • Während der Operandenauswahlphase 441 verwendet der Ablaufplaner 280 die Informationen aus der Ausbreitungsphase 432, um die Operanden zu orten (bis zu 2* "die Anzahl der Ausführungseinheiten" Operanden. Die Quelle eines Operanden kann die Registerdatei 290, das Ablaufplanungsreservoir 540 oder ein Ergebnisbus 561, 562, 563 oder 564 einer Ausführungseinheit 251, 252, 253 oder 254 sein. Das Ablaufplanungsreservoir 540 enthält Felder für unmittelbare Werte, Ergebnisse, die noch nicht übergeben worden sind und Informationen betreffend Operationen, die in der Reihenfolge des Programms voran gehen, aber nicht abgeschlossen sind. Der Ergebnisbus einer Ausführungseinheit ist die Quelle eines Operanden, wenn die Ausführungseinheit eine Operation abschließt, welche den benötigten Operanden betrifft. Der Ablaufplaner 280 bestimmt auch den Status von jedem Wert der Operanden, das heißt ob ein gültiger Wert tatsächlich von der bezeichneten Quelle zur Verfügung steht. Basierend auf dieser Information bestimmt der Ablaufplaner 280 in der Stufe Operandenweiterleitung 440, welche der Operationen in die Stufe Ausführung 450 vorrückt. Das Vorrücken ist für jede Pipeline unabhängig. Lediglich explizite Abhängigkeiten der Operanden erzwingen die Reihenfolge, in der die Operationen ausgeführt werden. Außer für solche Abhängigkeiten werden unterschiedliche Typen von Operationen durch ihre entsprechenden Pipelines in einer willkürlichen Reihenfolge im Hinblick auf andere Typen von Operationen verarbeitet.
  • Während der Operandentransferphase 442 transferiert der Ablaufplaner 280, Operandenwerte von den bezeichneten Quellen über Operandenbusse 554 an die Ausführungseinheiten 251 bis 254. Wie in 5 gezeigt, hat das beispielhafte Ausführungsbeispiel neun Operandenbusse 554, von denen acht Operandenwerte für Operationen in der Stufe Operandenweiterleitung zur Verfügung stehen. Ausführungsbeispiele mit mehreren Ausführungseinheiten, wie das Ausführungsbeispiel mit einer Gleitkomma Einheit 255, können mehrere Operandenbusse haben. Der Transfer von Operanden geschieht unabhängig davon, ob Operandenwerte gültig sind. Falls ein Operandenwert ungültig ist, rückt die verbundene Operation nicht zu der Stufe Ausführung 450 vor, so dass die Ausführungseinheit den ungültigen Operanden nicht verwendet.
  • Während der Operandentransferphase 442 von LdOps und StOps, transferiert die Versetzungsweiterleitung 443 Versetzungsoperanden über Versetzungsbusse 555 an die Ladeeinheit 251 und an die Speichereinheit 252 (einen an jede Einheit). Die Versetzungsoperanden sind 32 Bit Werte von Einträgen des Ablaufplaners. Die Auswahl von Quelleinträgen für Versetzungen geschieht während der Operandenauswahlphase 441.
  • Wenn eine LdOp oder eine StOp die Stufe Ausführung 450 betritt, verriegeln die Lade- und Speichereinheiten 251 und 252 Werte für zugeordnete Versetzungen und Operanden und hält diese so lange wie die Operation in der Stufe 450 verbleibt. Der Ablaufplaner 280 hat eine begrenzte Steuerung über die Ausführungsstufen 450 und 460 der Pipeline. In den Stufen 450 und 460 verfolgt der Ablaufplaner 280 die Zustände der Operationen und liest resultierende Werte der Register und Status ein. Die Adressberechnung 453 in der Stufe Ausführung 450 bestimmt eine Adresse, auf die von der LdStOp zugegriffen wird. Falls die Adresse und die Datengröße für eine LdStOp einen Datenzugriff veranlasst, der sich über eine Grenze zwischen Einträgen in dem Daten-Cachespeicher erstreckt, wird die LdStOp hier als falsch ausgerichtet bezeichnet. Falsch ausgerichtete LdStOps werden in zwei Datenzugriffe getrennt; eine erster Zugriff rückt zu der Stufe Ausführung 460 vor, während der zweite Zugriff in der Stufe Ausführung 450 aufgehalten wird. Das State Feld des Eintrags des Ablaufplaners, das auf die falsch ausgerichtete LdStOp bezogen ist, zeigt die Stufe Ausführung für den zweiten Zugriff an.
  • Zusätzlich zu den vier Phasenprozessen zum Erlangen der Quelloperanden zum Starten der Ausführung, führt der Ablaufplaner 280 einen ähnlichen Prozess mit vier Phasen aus zum Erlangen der Datenoperanden für eine StOp; aber der Datenoperand wird für die StOp in der SU Stufe 460 erlangt. Der Prozess für die Bereitstellung der Speicherdaten ist synchronisiert mit den Stufen 450 und 460 der StOp und enthält eine Operationsauswahlphase 456, welche die StOp in der Stufe Ausführung 450 identifiziert, eine Ausbreitungsphase 457, welche die Quelle eines Datenoperanden beschreibende Informationen übermittelt, eine Datenoperandenauswahlphase 461 und eine Datenoperandentransferphase 462. Kurz gesagt wird ein Speicherdatenoperand parallel zu der Ausführung der StOp abgerufen und der aktuelle Datenwert wird gewonnen und zu der Speicherwarteschlange 270 transferiert, sobald die StOp abgeschlossen ist. Die Stufe Abschluss und Austritt 460 entspricht der Erzeugung eines Eintrags in der Speicherwarteschlange für die StOp, basierend auf den in der Phase 461 ausgewählten Daten und der physikalischen Adresse von der Adressberechnung 453 und der DTLB Abbildung 455. Falls ein gültiger Datenoperand oder eine physikalische Adresse noch nicht zur Verfügung steht, wird die StOp in der Stufe 460 fest gehalten.
  • Neben den Stücken der Ablaufplanungslogik 530 und 532, die der Ausgabe von Operationen und der Weiterleitung von Operanden zugeordnet sind, enthalten Einträge Stücke von Logik 534, die mit dem Ordnen von Lade- und Speicheroperationen befasst sind. Gerade da einiges Ordnen der Befehle wegen Abhängigkeiten zwischen Registern auch zwischen Operationen aufrecht erhalten wird, wird auch eine begrenzte Ordnung der Ausführung zwischen LdOps und StOps wegen Abhängigkeiten im Speicher aufrecht erhalten (zum Beispiel können LdOps nicht frei vor älteren StOps ausgeführt werden). Die Lade-Speicher Ordnung bezieht sich auf StOps, die auf den Speicher zugreifen und auf StOps wie CIA (Überprüfung Befehlsadresse) und CDA (Überprüfung Datenadresse) Operationen, welche auf den Speicher verweisen und/oder fehlerhafte Adressen erzeugen, aber nicht auf LEA (Lade effektive Adresse) Operationen. Keine LdOps sind von der Lade-Speicher Ordnung ausgeschlossen, da alle LdOps auf den Speicher verweisen.
  • Die Lade-Speicher Ordnung wird bei der Stufe 460 der beiden Ausführungspipelines erzwungen, wo eine LdOp oder eine StOp in der Stufe 460 aufgehalten wird, bis ein Abschließen der Operation sicher ist. Bis zu der Stufe 460 wird kein. Ordnen zwischen den LU und SU Pipelines aufrecht erhalten. Des weiteren können LdStOps im Allgemeinen außer der Reihe abschließen, wenn eine Unabhängigkeit vom Speicher durch partielle Vergleiche mit älteren LdStOps "bewiesen" ist. Die Speicherwarteschlange 270 führt mit der Überprüfung der Abhängigkeit verbundene Vergleiche von Adressen durch, erfordert aber Unterstützung durch den Ablaufplaner bei der Bestimmung des relativen Alters von LdOps und StOps in den LU und SU Ausführungspipelines. Nur die geeigneten Vergleiche der Adressen (eine LdOp mit älteren StOps und eine StOp mit älteren LdOps) werden betrachtet bei der Bestimmung, ob einer gegebenen LdOp oder StOp erlaubt ist abzuschließen.
  • Eine Lade-Speicher Ordnungslogik 534 enthält Logik, die sich auf die LU Pipeline bezieht, und Logik, die sich auf die SU Pipeline bezieht. Die auf die LU Pipeline bezogene Logik bestimmt das Alter jeder LdOp in der LU Stufe 460 in Bezug auf beliebige StOps in den SU Stufen 450 oder 460 und beliebigen weiteren StOps. Die Logik 534 erzeugt drei Signale SC_SU2OLDER, SC_SU1OLDER und SC_SU0OLDER auf einem Bus 556, um anzuzeigen, ob eine StOp in der SU Stufe 450, der Stufe 460 oder woanders älter ist als die LdOp in der LU Stufe 460. Die mit der SU Pipeline verbundene Logik bestimmt das Alter jeder LdOp in der SU Stufe 460 in Bezug auf beliebige LdOps in der LU Stufe 460 und beliebigen weiteren LdOps und erzeugt zwei Signale SC_LU2OLDER und SC_LU1OLDER, um anzuzeigen, ob irgendwelche LdOps älter sind als die StOp in der Stufe 460.
  • Der Ablaufplaner 280 enthält des weiteren eine Logik zur Behandlung von Status Flags 538, die der Erwerbung und der Verwendung von Status Flags oder Bedingungscode (cc) Werten zugeordnet ist. Drei relativ unabhängige Bereiche an Funktionalität sind betroffen: das Abrufen von Werten für Status Flags für von der Registereinheit 253 ausgeführte RegOps, die vom Status abhängig sind, das Abrufen von Werten für Status Flags für die Auflösung von BRCONDs durch die Verzweigungsbewertungseinheit 257 und die Synchronisierung nicht abbrechbarer RegOps mit vorangehenden BRCONDs.
  • Die RUX Ausführungseinheit führt vom Status abhängige ("cc-dep") RegOps aus und erfordert einen Statusoperandenwert zu der gleichen Zeit wie den Registeroperandenwert, das heißt am Ende der Stufe Operandenweiterleitung 440. CC-dep RegOps wird es nicht erlaubt, zu der Stufe Ausführung 450 vorzurücken, bis sie Zeile 3 erreichen, und werden in Zeile 3 festgehalten, bis sie gültige Bedingungscodes empfangen. Anders als das Abrufen von Registerwerten ist der Prozess des Abrufens des Status nicht in eine Pipeline gebracht und geschieht in einem Zyklus, das heißt während der RUX Stufe Operandenweiterleitung 440. Des weiteren ruft dieselbe Logik 538 aktualisierte Werte der Status Flags sowohl für die cc-dep RegOps als auch für die BRCONDs ab. Für cc-dep RegOps werden die Bedingungscodes der Ausführungseinheit 253 zugeführt, während die Gültigkeit der von der RegOp benötigten Statuswerte überprüft wird. Falls gültige Werte für alle erforderlichen Status Flags noch nicht zur Verfügung stehen, wird die RegOp in der Stufe Operandenweiterleitung 440 aufgehalten (das gleiche für den Fall, dass die Registeroperandenwerte noch nicht zur Verfügung stehen).
  • BRCONDs erfordern keine tatsächliche Ausführungsbearbeitung. Stattdessen, während eine BRCOND aussteht (und bevor sie den Boden des Ablaufplaners 280 erreicht), wird die BRCOND als korrekt vorher gesagt oder nicht korrekt vorher gesagt aufgelöst. BRCONDs werden in Reihenfolge aufgelöst, mit einer Rate von bis zu einer BRCOND pro Zyklus. Wenn eine BRCOND die Zeile 4 erreicht, überprüft die Logik zur Behandlung von Status Flags 538, um festzustellen, ob gültige Status Flags für die Bewertung der BRCOND entweder von der Registerdatei 290 oder einer älteren Operation als der BRCOND zur Verfügung stehen. Die Logik zur Behandlung von Flags 538 stellt auch fest, ob die älteren Operationen, falls vorhanden, welche die für die Bewertung der BRCOND erforderlichen Status Flags zur Verfügung stellen, abgeschlossen sind. Falls Werte für die erforderlichen Status Flags noch nicht zur Verfügung stehen, wird die Auflösung der BRCOND durch ein Verhindern des Schiebens des Op Quads, der die BRCOND enthält, aufgehalten. Wenn die für die nächste nicht aufgelöste BRCOND erforderlichen Werte für die Status Flags zur Verfügung stehen, führt die Logik zur Behandlung von Status Flags 538 die Werte der Status Flags der Verzweigungsbewertungseinheit 257 zu, welche feststellt, ob der innerhalb der BRCOND angegebene Bedingungscode korrekt vorher gesagt wurde. Falls die BRCOND nicht korrekt vorher gesagt wurde, werden Neustartsignale angelegt, um die Befehlsabruf- und Dekodierbereiche des Befehlsdekodierers 240 (2) an der korrekten Verzweigungsadresse zu starten. Falls die Operation korrekt vorher gesagt wurde geschieht nichts.
  • Die Auflösung von BRCONDs ist für die Ausführung von nicht abbrechbaren RegOps von Bedeutung. Die Ausführung von nicht abbrechbaren RegOps führt zu Änderungen, die nicht abgebrochen oder rückgängig gemacht werden können. Entsprechend werden nicht abbrechbare RegOps am Eintreten in die Stufe Ausführung 450 gehindert, bis die Ausführung der RegOp sicher ist. Dies erfordert, dass alle vorangehenden BRCONDs aufgelöst sind und bestimmt sind, korrekt vorher gesagt worden zu sein, bevor die nicht abbrechbare RegOp zu der Stufe Ausführung 450 vorrücken kann. Daher wird, während jede vorangehende BRCOND nicht aufgelöst bleibt oder als falsch vorher gesagt befunden worden ist, die nicht abbrechbare RegOp in der Stufe Operandenweiterleitung 440 festgehalten. Falls vorangehende BRCONDs korrekt vorher gesagt wurden, ist die Verzögerung temporär; aber falls eine vorangehende BRCOND nicht korrekt vorher gesagt wurde, wird die RegOp aufgehalten, bis ein abschließender Abbruchzyklus den Ablaufplaner 280 entleert.
  • Der Einsprungdekodierer 244 erzeugt nicht abbrechbare RegOps aus dem Emcode ROM 246. In dem Emcode ROM 246 sind keine Operationen, die eine implizite Abhängigkeit von der Ergebnissen einer nicht abbrechbaren RegOp haben, in dem Op Quad erlaubt, welcher dem Op Quad unmittelbar vorangeht, der die nicht abbrechbare RegOp enthält. Entsprechend hat, wenn die nicht abbrechbare RegOp in Zeile 4 ausgeführt wird, keine Operation in Zeile 5 eine implizite Abhängigkeit von der nicht abbrechbaren RegOp und alle älteren Operationen, die eine implizite Abhängigkeit von der nicht abbrechbaren RegOp gehabt haben könnten, sind zurück gezogen und daher abgeschlossen, bevor die nicht abbrechbare RegOp in Zeile 4 ausgeführt wird.
  • III.A. Stufe Ausgabe
  • Der Ablaufplaner 280 führt die Ausgabeauswahl- und Ausbreitungsphase 431 und 432 parallel für jede Ausführungspipeline durch und erfordert eine Ausgabeabtastung und Operanden. In dem beispielhaften Ausführungsbeispiel werden Operationen der Stufe Ausgabe parallel für die Ladeeinheit 251, die Speichereinheit 252, die Registereinheit 253 und die Registereinheit 254 ausgeführt.
  • III.A.1. Ausgabeauswahlphase
  • Jeden Takt versucht der Ablaufplaner 280 eine Operation zur Ausgabe an jede Einheit auszuwählen, die zu einer parallelen Ausführung fähig ist. In dem beispielhaften Ausführungsbeispiel wählt der Ablaufplaner 280 eine LdOp, eine StOp und zwei RegOps aus, um an die LU, SU, RUX und RUX Pipelines ausgegeben zu werden. Für die Ausgabeauswahlphase 431 tastet der Ablaufplaner 280 alle Einträge in dem Ablaufplanungsreservoir 540 "in Reihenfolge" von den ältesten zu den neuesten Operationen ab und wählt Operationen basierend auf den Feldern State und Type der Einträge zur Ausgabe aus. Die Ausgabeauswahl 431 berücksichtigt nicht den Status der Register oder Abhängigkeiten im Speicher, die Operationen auf einander haben können. Dies vereinfacht den Prozess der Auswahl der Ausgabe und erlaubt, dass die Ausgabeauswahlphase 431 für ein relativ großes Ablaufplanungsreservoir 540 schnell abgeschlossen wird.
  • Die Ausgabeauswahl ist für jede der vier Verarbeitungspipelines gleichzeitig und unabhängig. Für jede Pipeline LU, SU und RUX wird die nächste nicht ausgegebene Operation (wie von ihrem State Feld angezeigt) ausgewählt, welche die Pipeline verarbeiten kann (wie von dem Type Feld angezeigt). Anders gesagt wird die nächste nicht ausgegebene LdOp für die Ladeeinheit 251 ausgewählt, die nächste nicht ausgegebene StOp für die Speichereinheit 252 ausgewählt und die nächste nicht ausgegebene RegOp für die Registereinheit 253 ausgewählt. Für die Registereinheit 254 wird eine RegOp ausgewählt, die der für die Pipeline RUX ausgewählten RegOp folgt. Begrifflich hängt die Ausgabeauswahl für die Pipeline RUY von der Ausgabeauswahl für RUX ab; aber physikalisch wird die Ausgabeauswahl für RUY parallel mit der Ausgabeauswahl für RUX durchgeführt.
  • Für die Abtastungen erzeugt jeder Eintrag in dem Ablaufplaner vier Bits (das heißt ein Bit für jede Pipeline) IssuableToxx, welche anzeigen, ob die verbundene Operation zur Zeit für die Ausgabeauswahl an die Pipeline xx auswählbar ist, wobei xx LU, SU, RUX oder RUY ist. Der Prozess der Ausgabeauswahl für die Pipeline xx tastet von dem ältesten Eintrag in dem Ablaufplaner zu dem neuesten Eintrag in dem Ablaufplaner ab auf der Suche nach Einträgen mit einem gesetzten IssuableToxx Bit. Für die Pipelines LU, SU und RUX ist die erste gefundene Operation mit dem gewünschten Bit IssuableToLU, IssuableToSU oder IssuableToRU gesetzt die für die Ausgabe an die Pipeline LU, SU oder RUX ausgewählte. Die Ausgabeauswahl für die Pipeline RUY wählt die erste Operation mit IssuableToRUY gesetzt aus, die der für die Pipeline RUX ausgewählten Operation folgt.
  • Operationen können für die Ausgabeauswahl gewählt werden unmittelbar nachdem sie in den Ablaufplaner 280 geladen werden, das heißt eine Ope ration kann während ihres ersten Zyklus in dem Ablaufplaner 280 ausgegeben werden. In solchen Fällen müssen nur 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 wie am Ende der Ausgabeauswahlphase 431 erzeugt werden (das heißt bis zu einem halben Zyklus später) und müssen in einem Eintrag des Ablaufplaners nur für die Ausbreitungsphase 432 gültig sein.
  • Falls eine für die Ausgabe ausgewählte Operation nicht zu der Stufe Operandenweiterleitung 440 vorrückt, bleibt die Operation nicht ausgegeben, und während des nächsten Taktzyklus bewirbt sich die Operation um eine Ausgabe und wird vielleicht erneut ausgewählt.
  • III.A.1.a. Abtastungsketten Ausgabeauswahl
  • In einem Ausführungsbeispiel der Erfindung tastet der Ablaufplaner 280 die Operationen unter Verwendung von Abtastungskettenschaltungen ab, die aus den Einträgen zugeordneten Logikblöcken gebildet werden. Jede Abtastungskette ist ähnlich zu einer Übertragskette, wie sie in manchen Addierern verwendet wird. In einer Abtastungskette der Ausgabeauswahl für die Ladeeinheit, die Speichereinheit oder die Registereinheit X läuft ein "Abtastung" Bit Cin, das dem ältesten Eintrag eingegeben wird, logisch durch die Abtastungskette, bis ein logischer Block in einem der Einträge das Abtastungsbit beseitigt. Ein Eintrag beseitigt das Abtastungsbit, falls der Eintrag einer Operation des gewünschten Typs (das heißt IssuableToxx ist angelegt) zugeordnet ist. Um nach einer an die Registereinheit 254 auszugebenden Operation abzutasten, wird ein Abtastungsbit von einem Eintrag logisch erzeugt, der mit der an die Registereinheit 253 auszugebenden Operation verbunden ist, und das Abtastungsbit breitet sich aus, bis es von einem Eintrag beseitigt wird, der mit der an die Registereinheit 254 auszugebenden Operation verbunden ist. Der Eintrag, der das Abtastungsbit beseitigt, legt ein Signal IssueOpToxx an, um sich selbst als der Eintrag zu identifizieren, der mit der an die Ausführungseinheit xx auszugebenden Operation verbunden ist. Der ausgewählte Eintrag kann daher geeignete Aktionen unternehmen, wie sie für die Ausbreitungsphase 431 erforderlich sind. Falls ein Ab tastungsbit für die Ausführungseinheit xx sich durch alle Einträge verbreitet ohne beseitigt zu werden, ist kein Eintrag in dem Ablaufplaner 280 mit einer Operation verbunden, die an die Einheit xx ausgegeben werden kann, und keine Operation wird zur Ausgabe ausgewählt.
  • Während eine Abtastungskette, bei der ein Abtastungsbitsignal sich seriell durch jeden einzelnen Eintrag in dem Ablaufplaner 280 ausbreitet relativ einfach ist, kann eine schnellere Implementierung notwendig sein. Vorausschautechniken entsprechend denen, die in traditionellen Erzeugung-Ausbreitung-Beseitigung Übertragsketten verwendet werden, können angewendet werden. Eine Vorausschautechnik kombiniert Einträge in Gruppen und jede Gruppe erzeugt, verbreitet oder beseitigt ein Abtastungsbit. Vorausschau ist schneller, weil Gruppen Erzeugung-, Ausbreitungs- und Beseitigungsausdrücke parallel aus Einzeleintragsausdrücken bestimmt werden und ob eine Abtastung eine Gruppe durchläuft, kann festgestellt werden, ohne ein Signal, das sich durch jeden Eintrag in der Gruppe ausbreitet. Durch aufeinander folgende Kombination von Gruppenausdrücken tritt tatsächlich keine Ausbreitung eines Abtastungsbitsignals auf, weil das gesamte Ablaufplanungsreservoir eine einzelne Gruppe bildet.
  • Für die LU, SU und RUX Abtastungsketten sind die Einzeleintrag Beseitigungsausdrücke K die Signale IssuableToxx. Die erzeugten Ausdrücke G sind alle Null und die Ausbreitungsausdrücke P sind das Komplement der verbundenen K Ausdrücke. Die Tabelle B.28 zeigt Einzeleintragsausdrücke für LU, SU und RUX Abtastungsketten für die Pipelines LU, SU und RUX.
  • Die 8A und 8B zeigen eine Logik 800, die einen Bereich einer RUX Abtastungskette benutzend Vorausschaugruppen für sechs Einträge implementiert. Gruppen von mehr oder weniger Einträgen können verwendet werden, aber sechs Einträge pro Gruppe unterteilen 24 Einträge in vier Quadranten und reduzieren die Anzahl von Leitungen, die bei der Verarbeitung der Gruppenausdrücke verwendet werden. Wie in 8A gezeigt, hat jeder Quadrant zugewiesene NOR Gatter 810 und 812 und ein NAND Gatter 814, die zusammen wie ein OR Gatter mit sechs Eingängen agieren und ein Gruppenbeseitigungssignal Kgrp3, Kgrp2, Kgrp1 und Kgrp0 für den Quadranten 3, 2, 1 oder 0 erzeugen. Die Eingänge der NOR Gatter 810 und 812 sind die Signale IssuableToRUX, welche die Einzeleintragbeseitigungsausdrücke für die Pipeline RUX sind. Die Abtastungsketten für die Pipelines LU und SU sind identisch, mit der Ausnahme, dass die entsprechenden Signale IssuableToLU und IssuableToSU anstatt von IssuableToRUX eingegeben werden.
  • Die Abtastungen nach Ausgabeauswahlen sind von den ältesten zu den neuesten Einträgen in Übereinstimmung mit der physikalischen Reihenfolge der Einträge in dem Ablaufplaner 280. Der Quadrant 3 enthält die ältesten Einträge. Falls das Signal Kgrp3 angelegt wird, würde eine der Operationen in dem Quadranten 3 ein Abtastungsbit beseitigen und eine Operation aus dem Quadranten 3 sollte ausgegeben werden. Ein Puffer 823 legt ein verzögertes Signal IssueQuadrant[3] an, um den Quadranten 3 auszuwählen. Falls das Signal Kgrp3 nicht angelegt wird, kann ein Abtastungsbit sich durch den Quadranten 3 ausbreiten, aber eine Operation in dem Quadranten 2, 1 oder 0 könnte ausgewählt werden. Ein NAND Gatter 822 legt ein Signal IssueQuadrant[2] an, falls das Signal Kgrp2 angelegt ist und das Signal Kgrp3 nicht angelegt ist. Auf ähnliche Weise legen die NAND Gatter 821 und 820 Signale IssueQuadrant[1] beziehungsweise IssueQuadrant[0] an, wenn das Abtastungsbit sich durch den Quadranten 1 oder 0 ausbreiten kann, und das Gruppenbeseitigungssignal Kgrp1 oder Kgrp0 angelegt ist (das heißt falls die Gruppe das Abtastungsbit beseitigen würde). Falls keines der Gruppenbeseitigungssignale Kgrp[3:0] angelegt ist, wird keine Operation für die Ausgabe ausgewählt.
  • 8B zeigt eine Logik 850, die eine Operation von dem Quadranten 0 auswählt, wenn das Signal IssueQuadrant[0] angelegt ist. Vier Schaltungen ähnlich wie die Logik 850, eine für jeden Quadranten, arbeiten parallel. Da der Eintrag 5 der älteste Eintrag in dem Quadranten 0 ist, wird der Eintrag 5 ausgewählt, wenn er an die Pipeline RUX ausgegeben werden kann und der Quadrant 0 für die Ausgabe ausgewählt ist. Ein AND Gatter 865 legt ein Signal IssueOpToRUX[5] an, um anzuzeigen, dass der Eintrag 5 die ausge wählte Operation enthält, falls IssueQuadrant[0] angelegt ist und IssuableToRUX[5] angelegt ist. Die AND Gatter 860 bis 864 entsprechen den Einträgen 0 bis 4 und legen ein entsprechendes Bit in dem Signal IssueOpToRUX[0:4] an, um die ausgewählte Operation zu identifizieren, wenn diese Operation an RUX ausgegeben werden kann und keine ältere Operation in dem Quadranten 0 an RUX ausgegeben werden kann. Die NOR Gatter 870 bis 873 legen Signale an die entsprechenden NAND Gatter 860 bis 863 an, um anzuzeigen, dass keiner der älteren Einträge an RUX ausgegeben werden kann.
  • Als eine Alternative zu den Schaltungen 800 und 850 kann jede Logik eingesetzt werden, welche die Gleichungen aus der Tabelle B.29 in dem Anhang B implementiert.
  • Die Logik 800 aus 8A erzeugt das Signal IssueQuadrant[3:0] nach drei Gatterlaufzeiten von dem Eingang des Signals IssuableToRUX[23:0], sogar wenn der ausgewählte Eintrag sich in dem Quadranten 0 befindet, dem letzten durchsuchten Quadranten. Die Logik 850 aus 8B erzeugt das Signal IssueOpToRUX nach etwa zwei zusätzlichen Gatterlaufzeiten. Ohne die Verwendung von Vorausschautechniken, muss ein Abtastungsbit sich durch den gesamten Ablaufplaner ausbreiten, wenn keine Operation ausgewählt ist. Dies ist in dem beispielhaften Ausführungsbeispiel etwa 24 oder mehr Gatterlaufzeiten. Entsprechend sind die Vorausschau Abtastungsketten üblicherweise viel schneller als die seriellen Abtastungsketten, wenn ein Abtastungsbit sich durch jeden Eintrag ausbreitet.
  • III.A.1.b. Abtastungsketten Ausgabeauswahl für RUY
  • Die RUY Abtastungskette ist komplexer und verwendet vier Ausdrücke G, P, K und O. Die Ausdrücke G, P und K sind übereinstimmend mit den konventionellen Erzeugungs-, Ausbreitung- und Beseitigungsausdrücken. Der O Ausdruck stellt sicher, dass nur eine Operation ausgewählt wird. Der Einzeleintrag Erzeugungsausdruck G für den Eintrag i ist das Signal IssuableToRUX[i] und der Ausdruck O ist gleich zu dem Ausdruck G. Der Einzeleintrag Beseitigungsausdruck K für den Eintrag i ist das Signal IssuableToRUY[i] und die P Ausdrücke sind die Komplemente zu den zugeordneten K Ausdrücken.
  • Die Vorausschautechniken können auch bei der Ausgabeauswahl für die Pipeline RUY verwendet werden. Begrifflich wird für die RUY Abtastungskette ein Abtastungsbit durch den Eintrag erzeugt, der eine Operation enthält, die für die Ausgabe an RUX ausgewählt ist und von der nächst neueren Operation beseitigt wird, die an die Pipeline RUY ausgegeben werden kann. Eine Gruppe erzeugt ein Ausgangsabtastungsbit, falls ein Eintrag in der Gruppe das Abtastungsbit erzeugt und kein folgender Eintrag in der Gruppe die Abtastung beseitigt. Eine Gruppe verbreitet ein Abtastungsbit, wenn jeder Eintrag in der Gruppe das Abtastungsbit verbreitet. Ein O Ausdruck, sobald er erzeugt ist, hindert neuere Einträge daran, ein neues Abtastungsbit zu erzeugen, und ein Gruppen O Ausdruck wird erzeugt, wenn ein beliebiger Eintrag in der Gruppe einen Einzeleintrag O Ausdruck erzeugt. Gleichungen in der Tabelle B.30 in dem Anhang B fasst die Logik zusammen, welche die Gruppenausdrücke aus Einzeleintrag Ausdrücken in einer RUY Abtastungskette erzeugt.
  • Die 9A, 9B und 9C stellen eine Abtastungskette der Ausgabeauswahl für die Pipeline RUY dar, welche anfänglich den Ablaufplaner 280 in acht Gruppen mit 3 Einträgen unterteilen. In 9A implementieren die Logikblöcke 910 die in der Tabelle B.30 gezeigte Logik und erzeugen Gruppenausdrücke Ggrp[7:1], Pgrp[7:1] und Ogrp[7:1] aus den Einzeleintrag Signalen G[23:3] und O[23:3]. Die Gruppenausdrücke für die neueste Gruppe, Einträge 0 bis 2, werden aus den unten beschriebenen Gründen nicht benötigt. Die Gruppenausdrücke werden in drei Stufen kombiniert, um Ausdrücke für größere Gruppen zu bilden. Die Schaltung 900 erzeugt Gruppenausdrücke, wie die Erzeugungsausdrücke G_7, G_67, G_567, G_4567, G_34576, G_234567 und G_1234567 für Gruppen, welche die ältesten drei, sechs, neun, zwölf, fünfzehn, achtzehn oder einundzwanzig Einträge enthalten.
  • Die erste Stufe der Schaltung 900, die die Logikblöcke 920 enthält, kombiniert Gruppenausdrücke von benachbarten Gruppen von drei Einträgen, um Gruppenausdrücke für Gruppen von sechs Einträgen zu bilden. Die zweite Stufe, die die Logikblöcke 930 enthält, kombiniert Gruppenausdrücke von benachbarten Gruppen von entweder drei oder sechs Einträgen, um Gruppenausdrücke für eine Gruppe von neun oder zwölf Einträgen zu bilden. Die dritte Stufe, die die Logikblöcke 940 enthält, kombiniert Gruppenausdrücke von benachbarten Gruppen von zwölf, neun, sechs oder drei Einträgen, um Gruppenausdrücke für Gruppen von einundzwanzig, achtzehn und fünfzehn Einträgen zu bilden.
  • Die Logikblöcke 920, 930 und 940 kombinieren die Gruppenausdrücke GK, PX und OX für eine Gruppe X mit Gruppenausdrücken GY, PY und OY für die nächst neuere Gruppe Y, um die Ausdrücke GXY, PXY und OXY für eine Gruppe XY zu erzeugen, welche die Verkettung der Gruppen X und Y ist. In einem Ausführungsbeispiel der Erfindung implementiert jeder der Blöcke 920, 930 und 940 die folgenden Gleichungen.
  • Figure 00480001
  • Die in 9B gezeigte Schaltung zeigt eine beispielhafte Implementierung der Blöcke 920, 930 und 940. In 9B sind die Eingangssignale für die Gruppen 1 und 2 und die Ausgangssignale sind für die Vereinigung von Gruppe 1 und 2; aber jede gewünschten aufeinander folgenden Gruppen können die Gruppen 1 und 2 ersetzen. Alternativ kann eine andere äquivalente Logik verwendet werden oder alternative Stufen, Blöcke 920 und 930 oder Blöcke 930 und 940, können mit invertierender Logik implementiert werden. Des weiteren sind wie unten beschrieben Ausbreitungsausdrücke für die letzte Stufe, Blöcke 940, nicht erforderlich und der Block 940 kann vereinfacht werden, indem die Ausbreitungsgleichungen nicht implementiert werden (das heißt eliminieren des AND Gatters 922).
  • Die gewünschten Ausgangssignale von der Schaltung 900 sind G Ausdrücke und 0 Ausdrücke. Die Ausgangssignale G_7, G_67, G_567, G_4567, G_34576, G_234567 und G_1234567 zeigen an, ob ein zuvor erzeugtes Abtastungsbit die Gruppen 6, 5, 4, 3, 2, 1 beziehungsweise 0 erreicht, und werden hier auch als Signale CinGrp[6:0] bezeichnet. Die Signale O_7, O_67, O_567, O_4567, O_34576, O_234567 beziehungsweise O_1234567 zeigen an, ob ein Abtastungsbit vor der Gruppe 6, 5, 4, 3, 2, 1 beziehungsweise 0 erzeugt wurde, ohne Rücksicht darauf, ob das Abtastungsbit beseitigt wird bevor es die entsprechende Gruppe erreicht. Die Signale O_7, O_67, O_567, O_4567, O_34576, O_234567 und O_1234567 werden hier auch als Signale OinGrp[6:0] bezeichnet.
  • Ein Signal IssueOpToRUY[23:0] mit mehreren Bits kann von den Gruppensignalen CinGrp[6:0] und OinGrp[6:0] und den Einzeleintrag Signalen P, K, G und O erzeugt werden. Die 9C zeigt eine Logik, die Einträge zur Ausgabe an die RUY Ausführungseinheit auswählt. Die Logik, welche die Einträge 23 bis 21 des Signals IssueOpToRUY[23:0] erzeugt, unterscheidet sich von der Logik für die anderen Gruppen, weil es keine Gruppenausbreitung in die Gruppe 7, die älteste Gruppe, gibt. Die gezeigte Logik, die IssueOpToRUY[20:18] für Gruppe 6 erzeugt, wird für jede Gruppe 5 bis 0 wiederholt. Wie in der Tabelle B.30 des Anhangs B gezeigt ist, sind die Gruppenausbreitungsausdrücke für die letzte Gruppe 0 für die Auswahl einer Operation für die Ausgabe nicht erforderlich.
  • III.A.2. Verbreitungsphase Operandeninformation
  • Während der Verbreitungsphase der Stufe Ausgabe der Verarbeitungspipelines werden Informationen über Operanden für Operationen, die an die Ausführungseinheiten ausgegeben werden sollen, an alle Einträge in dem Ablaufplaner 280 und an die externe Logik verbreitet. Diese Informationen beschreiben zwei Quelloperanden für jede zur Ausgabe ausgewählten Operation. Der Eintrag für die ausgewählten Operationen übermittelt auch Informationen über die ausgewählten Operationen an die externe Logik und an die zugeordnete Ausführungseinheit.
  • Die Operandeninformationsbusse 552 (5) laufen durch den Ablaufplaner 280. Die Anzahl der Operandeninformationsbusse 552 stimmt mit der maximalen Anzahl von Operanden überein, die von den Ausführungseinheiten benötigt werden könnten. Ein der ausgewählten Operation zugeordneter Eintrag treibt zwei Operandeninformationsbusse 552, die der Ausführungseinheit zugeordnet sind, zu der die zugeordnete Operation ausgegeben wird. Jeder Operandeninformationsbus 552 ist acht Bit breit und trägt eine 5-Bit Registernummer Src1Reg[4:0] oder Src2Reg[4:0] und eine 3-Bit Bytemarkierung Src1BM[2:0] oder Src2BM[2:0] für einen Quelloperanden. Die Tabelle B.31 beschreibt die Logik der Einträge, welche die Operandeninformationsbusse 552 treibt.
  • Eine Vergleichslogik in jedem Eintrag vergleicht verbreitete Operandeninformation mit ähnlichen Informationen, die ein Zielregister für die Operation in dem den Vergleich machenden Eintrag betrifft. Die Vergleichslogik überprüft auf überein stimmende Registernummern und auf überlappende Bytemarkierungen (das heißt einige oder alle der für eine Operation erforderlichen Bytes sind oder werden von der Operation verändert). Die Ergebnisse der mehrfachen ("# der Operandeninformationsbusse" * "# der Einträge") Vergleiche sind Signale, die während der nächsten Verarbeitungsphase, der Operandenauswahlphase 441, auftretende Aktionen steuern. Die Tabelle B.32 beschreibt die Logik, welche die Vergleiche durchführt. Die folgende Gleichung fasst einen allgemeinen Vergleich zusammen:
    Figure 00500001
    wobei "XXsrcY" eines der LUsrc1, LUsrc2, SUsrc1, SUsrc2, RUXsrc1, RUXsrc2, RUYsrc1 oder RUYsrc2 ist und RUYsrc2 und "bus" sich auf das Signal OprndInfo_XXsrcY beziehen, das einer der Operandeninformationsbusse 552 ist.
  • "Übereinstimmung" Signale Oprndmatch_XXsrcY, die aus den Vergleichen stammen, sind das Produkt der Verbreitungsphase und werden bei der Auswahl der Operanden verwendet. Dies geschieht nebeneinander in jedem Eintrag, das heißt in jedem Eintrag werden acht Übereinstimmungssignale der Operandenauswahllogik 532 des Eintrags in Form einer Pipeline zugeführt. Sämtliche Übereinstimmungssignale verbleiben lokal in jedem Eintrag und werden in Registern verriegelt zur Benutzung in der folgenden Stufe der Pipeline. Kurz gesagt führen in jedem Eintrag acht Operandeninformationsbus-Komparatoren acht "Steuer" Signale an acht Stücke von der Operandenauswahllogik 532 zu. Die Übereinstimmungssignale in jedem Eintrag innerhalb der untersten Zeile werden durch zusätzliche Signale gesperrt oder maskiert, die mit der Übergabe dieser Ergebnisse der Register der Operationen an die architekturisierte Registerdatei 290 zusammen hängen. Siehe die Beschreibung der Operationsübergabeeinheit 260 unten.
  • Jeder Eintrag steuert nicht tatsächlich das Laden der überein stimmenden Bits in die Operandenübereinstimmungsregister innerhalb des Eintrags. Die globale Logik 520 erzeugt das Signal LUAdv0, SUAdv0, RUXAdv0 und RUYAdv0, das anzeigt, ob eine ausgegebene Operation in die Stufe Operandenweiterleitung 440 vorrücken wird, und Übereinstimmungssignale werden nur verriegelt und verwendet, wenn eine Operation tatsächlich in die Stufe Operandenweiterleitung 440 vorrückt.
  • Vier Operandeninformationsbusse 551 entsprechend der Ladeeinheit 251, der Speichereinheit 252, der Registereinheit 253 und der Registereinheit 254 stellen zusätzliche Informationen zur Verfügung, die eine ausgegebene Operation beschreiben. Die zusätzliche Information, nämlich das OpInfo Feld, wird während der Verbreitungsphase aus dem Ablaufplaner 280 ausgelesen und in externen Pipelineregistern verriegelt, wenn die Operation tatsächlich in die Stufe Operandenweiterleitung vorrückt. Die Tabelle B.33 beschreibt eine Logik, welche die Operandeninformationssignale erzeugt.
  • Die während der Verbreitungsphase zur Verfügung gestellten Src1/Src2Reg und Src1/2BM Felder werden für eine Nummer von Zwecken während der nächsten beiden Phasen verwendet (das heißt während der Stufe Operandenweiterleitung). Die OpInfo Felder werden einfach "die Pipeline runter" an die entsprechenden Ausführungseinheiten weiter gegeben (über einen zweiten Satz von Pipelineregistern, die von dem entsprechenden Signal XXAdv1 gesteuert werden). für RUX und RUY Operationen werden auch die Bytemarkierungen Src1/2BM "die Pipeline runter" an die entsprechende Registereinheit weiter gegeben.
  • III.B. Stufe Operandenweiterleitung
  • Die Stufe Operandenweiterleitung besteht aus einer Operandenauswahlphase und einer Operandentransferphase.
  • III.B.1. Operandenauswahlphase
  • Jeden Zyklus, in der Stufe Operandenweiterleitung, verwendet der Ablaufplaner 280 Übereinstimmungsbits, die von der Ausgabestufenlogik 530 erzeugt wurden und in den Operandenübereinstimmungsregistern gespeichert wurden, um Einträge auszuwählen, die Werte für Operanden zur Verfügung stellen, die "abgerufen" werden. Der Ablaufplaner 280 bestimmt auch für jeden Operanden, ob die Werte des Operanden von einem Eintrag des Ablaufplaners oder von der Registerdatei 290 stammen. Die Registerdatei 290 ist die Vorgabe, wenn kein überein stimmender Eintrag da war. Während der Operandentransferphase treiben die gewählten Einträge und/oder die Registerdatei 290 Werte der Operanden auf die Operandenbusse 554 und transferieren damit Werte der Operanden zu den zugeordneten Ausführungseinheiten.
  • Wie bei dem Prozess der Ausgabeauswahl in den Stufen Ausgabe sind die Operandenauswahlen unabhängig und gleichzeitig. Daher enthält die Operandenauswahllogik 532 acht Abtastungsketten zum Auswählen der Einträge, um Operanden zur Verfügung zu stellen. Jeder Eintrag hat ein Operandenübereinstimmungsregisterbit für jeden Operandenbus und der dazu gehörigen Abtastungskette. Jede Abtastungskette sucht nach dem neuesten Eintrag mit einer Übereinstimmung, der älter ist als die Operation, deren Operand abgerufen wird. Logisch startet die Abtastung (ein Abtastungsbit wird erzeugt) von dem Eintrag, der die Operation enthält, deren Operand abgerufen wird, und schreitet in die Richtung der älteren Einträge fort zu dem ersten Eintrag mit einem gesetzten Operandenübereinstimmungsbit. Falls ein Eintrag mit einem gesetzten Übereinstimmungsbit gefunden ist, stellt dieser Eintrag den angeforderten Operanden während der nächsten Phase durch Treiben auf den dazu gehörigen Operandenbus 554 zur Verfügung. Falls kein "überein stimmender" Eintrag gefunden wird, veranlasst eine Abtastungsbitausgabe von der Abtastungskette die Registerdatei 290, den Wert des Operanden zur Verfügung zu stellen.
  • Falls eine Operation, deren Operanden abgerufen werden, nicht aus der Stufe Operandenweiterleitung vorrückt, dann wird der Prozess der Operandenauswahl in dem nächsten Zyklus erneut durchgeführt. Eine Operation wird nicht vorrücken, wenn zum Beispiel ein Eintrag mit gesetztem Übereinstimmungsbit nicht alle für den Operanden erforderlichen Bytes verändert (und damit nicht zur Verfügung stellen kann). Da das State Feld und die physikalische Stelle der Operationen in dem Ablaufplanungsreservoir 540 sich jeden Zyklus ändern können, kann der Ausgang der neuen Auswahl unterschiedlich sein zu dem Ausgang des derzeitigen Zyklus. Kurz gesagt bestimmt während jedes Zyklus der Auswahlprozess, was getan werden muss, um die geeigneten Werte der Operanden während dieses Zyklus weiterzuleiten.
  • Die Abtastung, um die geeignete Quelle für einen Wert des Operanden zu finden, kann auf die gleiche Weise ausgeführt werden wie die oben beschriebenen Abtastungen der Ausgabeauswahl. Jedoch verläuft die Abtastung in die Richtung der älteren Operationen, was das Gegenteil der Richtung der Abtastungen der Ausgabeauswahl ist. Des weiteren sind die Abtastungsketten für die Auswahl der Operanden keine "Ausbreitung-Beseitigung" Ketten. Die Abtastungsketten für die Auswahl der Operanden sind analog zu einer traditionellen Übertrags- oder "Erzeugung-Ausbreitung-Beseitigung" Kette. Das anfängliche Abtastungsbit Cin in der Abtastungsket te ist Null und der Eintrag, welcher der Operation entspricht, deren Operand abgerufen wird, erzeugt das Abtastungsbit. Eine Abtastungsbeseitigung tritt an dem ersten folgenden Eintrag auf, dessen Operandenübereinstimmungsbit gesetzt ist, und die Ausbreitung der Abtastung geschieht an dazwischen liegenden Einträgen.
  • Die globale Steuerlogik 520 verwendet das letzte Ausgangsabtastungsbit Cout von dem letzten/ältesten Eintrag, um zu bestimmen, ob ein beliebiger Eintrag ausgewählt wurde, und damit, ob die Registerdatei 290 stattdessen ausgewählt werden sollte, um den Operanden zur Verfügung zu stellen. Falls Cout angelegt ist, wählt die globale Steuerlogik 520 die Registerdatei 290 aus. Die ausgewählte Quelle treibt den entsprechenden Operandenbus während der Operandentransferphase, welche der spätere Teil der Stufe Operandenweiterleitung ist. Während der Operandenauswahlphase wird das Quellregister in der Registerdatei 290, das formal den gewünschten Wert für den Operanden hält, für den Fall gelesen, dass die Registerdatei 290 zum Treiben des Operandenbusses ausgewählt ist.
  • Wie bei den Abtastungsketten für die Ausgabeauswahl, verbessert eine Implementierung der Vorausschau die Geschwindigkeit. Die Tabelle B.34 des Anhangs B stellt ein Beispiel einer Abtastungskette für die Auswahl von Operanden in Ausdrücken von Vorausschaugleichungen zur Verfügung, die mit den traditionellen Erzeugung-Ausbreitung-Beseitigung Gleichungen ähnlich sind.
  • III.B.2. Operandentransferphase
  • Während der Operandentransferphase 442 der Stufe Operandenweiterleitung 440 werden Werte für jeden der acht Quelloperanden abgerufen und über die Operandenbusse 554 an Eingangsregister der dazu gehörigen Ausführungseinheiten übermittelt. Die Operandenwerte sind 32-Bit Größen, aber einige Bytes könnten nicht definiert sein. Während einer korrekten Operation, verwendet eine Ausführungseinheit keine nicht definierten Bytes der Operanden. Jeder Eintrag oder die Registerdatei 290 kann jeden Operan denbus 554 treiben und jeder Eintrag des Ablaufplanungsreservoirs 540 kann jeden und/oder alle Busse treiben.
  • In dem beispielhaften Ausführungsbeispiel werden während der Operandenauswahlphase 192 Operandenauswahlsignale und 8 Abtastungskettensignale Cout erzeugt. Basierend auf diesen Signalen gibt eine Logik in jedem gewählten Eintrag die geeigneten Bustreiber in dem Eintrag frei. Falls keiner der Einträge für einen Operanden ausgewählt ist, gibt die Registerdatei 290 Treiber für diesen Operanden frei. Die Tabelle B.35 in dem Anhang B beschreibt eine Logik zum Freigeben des Treibers für die Operandenbusse 554.
  • Die Operandenregister in den Ausführungseinheiten 251 bis 254 lesen die Werte der Operanden von den Operandenbussen 554 für die Verwendung in nachfolgenden Stufen der Pipeline ein. Die globale Steuerlogik 520 erzeugt Steuersignale, eines je Verarbeitungspipeline, um das Laden der Operandenregister zu steuern. Neue Operandenwerte werden in eine Ausführungseinheit geladen, wenn eine Operation in der Stufe Operandenweiterleitung in die Stufe Ausführung 450 vorrücken kann. Das globale Signal LUAdv1 steuert die LU Stufe 1 Quelloperandenregister. Auf ähnliche Weise steuern die Signale SUAdv1, RUXAdv1 beziehungsweise RUYAdv1 das SU, RUX und RUY Laden der Operandenregister.
  • Während der Operandentransferphase 442 der Stufe Operandenweiterleitung 440 der vier Verarbeitungspipelines wird Information über jede der Operationen, die zur Bereitstellung eines Operandenwerts ausgewählt wurde, auch aus dem Ablaufplaner 280 ausgelesen. Jeder Operandenbus 554 hat einen dazu gehörigen Operandenstatusbus 552, der ein Operandenstatussignal OprndStat trägt, das den "Ursprung" des Operanden beschreibt, der abgerufen wird. Das Operandenstatussignal eines Eintrags ist eine Verkettung der Felder State, DestBM, Type und Exec1 des Eintrags, der den Wert des Operanden zur Verfügung stellt. Die externe Logik verwendet diese Information während der Operandentransferphase, um die Quelle und die Verfügbarkeit eines gültigen Werts für den Operanden zu bestimmen.
  • Die Registerdatei 290 hat ebenso einen Satz von Treibern für die Operandenstatusbusse 553, um sicher zu stellen, dass die Operandenstatusbusse 553 definierte Werte tragen und dass die Werte zu einem geeigneten Verhalten der die Information verwendenden Logik führt. Die Tabelle B.36 des Anhangs B beschreibt das Operandenstatussignal und seine Erzeugung.
  • Jeder an die Ausführungseinheit gelieferten Quelloperanden kommt von einer der drei möglichen Quellen: einem Eintrag in dem Ablaufplaner, der Registerdatei 290 oder einem Ergebnisbus von dieser oder einer anderen Ausführungseinheit. Die Operandentransferphase 442 deckt die Lieferung von einem Eintrag ab. Auf die Registerdatei 290 wird während der Operandenauswahlphase parallel zu Aktivitäten des Ablaufplaners zugegriffen. Insbesondere wird die Registernummer für den gewünschten Operanden während der Verbreitungsphase von dem Eintrag der Operation verbreitet und an den geeigneten Leseanschluss der Registerdatei 290 weiter gegeben. Für jeden zur Verfügung zu stellenden Operanden stellt der Ablaufplaner 280 fest, ob ein Eintrag in dem Ablaufplaner oder die Registerdatei 290 den Operandenbus 554 treibt, der dem Operanden entspricht; und der resultierende Operand wird während der Operandentransferphase über den Operandenbus 554 an die Ausführungseinheit transferiert.
  • Wie in 10 gezeigt sind die Operandenbusse 554 über Multiplexer 1010 mit Operandeneingangsregistern 1021 bis 1024 und 1031 bis 1034 in den Ausführungseinheiten 251 bis 254 verbunden. Die Ergebnisbusse 561 bis 564 von den Ausführungseinheiten 251 bis 254 sind ebenfalls mit den Multiplexern 1010 verbunden. Daher laufen fünf "Operanden" Busse zu jedem Operandeneingang von jeder Ausführungseinheit, nämlich einer der Operandenbusse 554, die zur Eingabe dieses Operanden von dem Ablaufplaner 280 oder der Registerdatei 290 bestimmt ist sowie vier Ergebnisbusse von den Ausführungseinheiten 251 bis 254. Während der Operandentransferphase erzeugt der Ablaufplaner 280 Signale für die 5:1 Multiplexer 1010 an jedem Operandeneingangsregister. Das Operandenstatussignal zeigt an, ob der gewünschte Wert des Operanden von einer Ausführungseinheit verfüg bar ist oder gerade verfügbar wird; und falls dies der Fall ist, wird der entsprechende Ergebnisbus und das Ergebnis Result_XX von einer Ausführungseinheit 251 bis 254 ausgewählt. Anderenfalls wird der Operandenbus 554 ausgewählt. Die Gültigkeit des Operanden ist eine unabhängige Sache, die sich nur darauf auswirkt, ob die dazu gehörige Operation in der Stufe Operandenweiterleitung 440 in die Stufe Ausführung 450 vorrückt und damit tatsächlich eine Ausführungseinheit betritt.
  • III.B.3. Weiterleitung Verschiebung
  • Zusätzlich zu den Registeroperanden ruft der Ablaufplaner 280 Versetzungsoperanden ab und leitet sie während der Operandentransferphase 442 an die LU und SU Verarbeitungspipelines weiter. Die Ladeeinheit 251 und die Speichereinheit 252 haben jeweils drei Eingangsoperandenbusse (zwei Registeroperandenbusse 554 und einen Versetzungsbus 555). Die Versetzungsoperanden sind 32-Bit Größen, aber einige Bytes in dem Versetzungsoperanden könnten nicht definiert sein und werden daher während einer korrekten Operation der Ausführungseinheiten 251 und 252 nicht verwendet.
  • Der Ablaufplaner 280 behandelt Versetzungen auf eine ähnliche Weise wie die Ergebniswerte der Operationsregister. Versetzungen werden anfänglich in den 32-Bit DestVal Feldern der Einträge gespeichert, bis sie verwendet werden und werden während der Operandentransferphase 442 wie erforderlich auf die Versetzungsbusse 555 getrieben. Versetzungen sind für RISC86 Operationen immer unmittelbare Werte, so dass die Weiterleitung von Versetzungswerten aus der Registerdatei 290 nicht auftritt. Das Feld DestVal wird ebenfalls für die Ergebniswerte von LdOps und einigen StOps verwendet, aber die zwei Verwendungen des Felds DestVal kollidieren nicht, da ein Ergebniswert nicht in einen Eintrag des Ablaufplaners geladen wird, bis nachdem die Versetzung aus dem Eintrag weiter geleitet ist, das heißt nicht bis nach der Stufe Operandenweiterleitung 440.
  • Kleine (8-Bit) Versetzungen, welche innerhalb Operationen angegeben sind, werden anders als große (16/32 Bit) Versetzungen behandelt. Der Operationsdekodierer 510 erweitert eine kleine Versetzung um ein Vorzeichen bevor die kleine Versetzung in das DestVal Feld des Eintrags geladen wird, der die dazu gehörige LdStOp hält. Von großen Versetzungen wird angenommen, dass sie in dem DestVal Feld des Eintrags für eine LIMMOp gespeichert sind, die der die Versetzung benutzenden LdStOp unmittelbar voraus geht. Im Allgemeinen hält der vorangehende Eintrag eine "LIMM t0,[disp]" Operation, die in einem kompletten Zustand in den Ablaufplaner 280 geladen werden kann, so dass die LIMMOp nicht ausgegeben oder ausgeführt wird.
  • Die Auswahl der DestVal Felder, um die Versetzungsbusse 555 zu treiben, während jedes Zyklus erfordert nicht die Abtastung von Einträgen des Ablaufplaners. Stattdessen bestimmt jeder Eintrag anhand seiner State und Type Felder, ob seine Treiber oder Treiber in einem voran gehenden Eintrag freizugeben sind, um einen Wert des Feldes DestVal auf dem geeigneten Versetzungsbus 555 anzulegen. Die Tabelle B.37 im Anhang B fasst eine Logik zur Freigabe der Treiber für den Versetzungsbus in jedem Eintrag zusammen.
  • III.B.4. Weiterleitung unmittelbarer Wert
  • In dem beispielhaften Format der RISC86 Operationen sind unmittelbare Werte Operanden src2 von RegOps. Der Ablaufplaner 280 behandelt unmittelbare Werte und Versetzungen ähnlich. Der RISC86 Befehlssatz verwendet nur kleine (8-Bit) unmittelbare Werte in RegOps, und der Operationsdekodierer 510 speichert die unmittelbaren Werte in dem Feld DestVal des Eintrags, der die RegOp enthält. Daher sind unmittelbare Werte dahingehend wie Versetzungen, dass sie in den DestVal Feldern der Einträge gespeichert werden, aber sind dahingehend wie Registeroperanden, dass sie über die Registeroperandenbusse 554 (insbesondere die RUXsrc2 und RUYsrc2 Operandenbusse) weiter geleitet werden. Unmittelbare Werte für Src2 Operanden werden anstelle eines Registerwerts während der Operandentransfer phase 442 der Stufe Operandenweiterleitung 440 an entsprechende Registerausführungseinheiten weitergeleitet. Die Auswahl einer Quelle für den Registerwert (das heißt einem Eintrag in dem Ablaufplaner oder der Registerdatei 290) wird verhindert und der fragliche Eintrag treibt sein DestVal Feld direkt auf den geeigneten Operandenbus 554.
  • Die Verhinderung der Auswahl von RUX/RUX src2 Operanden wird während der Operandenauswahlphase 441 durchgeführt durch Maskierung des Einzeleintrag Erzeugungsausdrucks, dass ein die RegOp enthaltender Eintrag normalerweise in eine Abtastungskette für die Auswahl von Operanden ausgeben würde. Dies geschieht getrennt und unabhängig für RUXsrc2 und RUYsrc2 und verhindert die Auswahl eines Eintrags durch die RUX/Ysrc2 Abtastungskette. Einträge, die unmittelbare Werte enthalten, verhindern auch die Auswahl der Registerdatei 290 als die Vorgabe für die Quelle der Operanden. Die Einzeleintrag Ausdrücke für die RUX und RUY Abtastungsketten für die Auswahl der Operanden, wie in Tabelle B.34 beschrieben, zeigen die Verhinderung.
  • Die Auswahl von kleinen "unmittelbaren" DestVal Werten während jedes Zyklus zum Treiben auf die RUXsrc2 und RUYsrc2 Operandenbusse erfordert nicht die Abtastung der Einträge des Ablaufplaners. Stattdessen gibt jeder Eintrag die Treiber von seinem DestVal Feld auf den entsprechenden Operandenbus 554 einfach basierend auf dem State Feld und den verwandten Bits frei. Die gleichen Treiber können für die Weiterleitung von Werten der Registeroperanden und die Weiterleitung von Operanden mit unmittelbaren Werten verwendet werden. Die Tabelle B.38 in dem Anhang B beschreibt eine Schaltung zum Treiben der unmittelbaren Werte auf die Operandenbusse 554. Wenn ein Eintrag einen unmittelbaren Wert auf den Operandenbus 554 treibt, kann der Eintrag auch den dazu gehörigen Operandenstatusbus 553 treiben. Die gleichen Bustreiber und Eingangswerte für die Treiber wie für Registeroperanden werden für unmittelbare Werte verwendet, aber mit einem zusätzlichen Ausdruck, wie in Tabelle B.38 gezeigt.
  • III.C. Abruf Datenoperand
  • StOps haben drei Registerquelloperanden und kein Zielregister. 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 einer StOp zu starten, wird aber für das Abschließen der StOp benötigt. Der Abruf von Datenoperanden wird auf ähnliche Weise durchgeführt wie das Abrufen von anderen Quelloperanden, aber wo der "normale" Prozess des Abrufs von Operanden während der Stufe Ausgabe 430 und der Stufe Operandenweiterleitung 440 geschieht, geschieht der Prozess des Abrufs von Datenoperanden während der Ausführungsstufen 450 und 460. Der Ablaufplaner 280 überprüft die Verfügbarkeit von Datenoperanden während der SU Stufe Ausführung 460 und hält die dazu gehörige StOp in der Stufe 460, falls der Datenoperand nicht zur Verfügung steht.
  • Der Prozess des Abrufs von Datenoperanden ist im wesentlichen derselbe wie die oben beschriebenen Stufen Ausgabe und Operandenweiterleitung mit zwei prinzipiellen Unterschieden. Erstens erfordert die Operandenauswahlphase 456 keine Abtastung über die Einträge des Ablaufplaners, um zwischen mehreren Kandidaten auszuwählen, wie es während der Ausgabeauswahlphase 431 auftritt. Stattdessen identifiziert sich der zu der StOp gehörende Eintrag in der SU Stufe 450 selbst von den State und Type Feldern und stellt der Speichereinheit 252 den Datenoperanden, wenn erfordert, zur Verfügung. Der zweite Unterschied ist, dass das OpInfo Feld für die StOp für die Speichereinheit 252 während der Verbreitungsphase 457 für den Datenoperanden nicht (erneut) ausgelesen werden muss. Stattdessen hält die Speichereinheit 252 den OpInfo Wert, von dem Zeitpunkt wann die StOp ausgegeben wurde, zurück und verwendet ihn. Der OpInfo Wert, der während der SU Stufe Ausgabe 430 ausgelesen wurde, wird durch die Stufe Operandenweiterleitung und die ersten und zweiten Ausführungsstufen der SU Pipeline geleitet.
  • Die Tabelle B.39 in dem Anhang B beschreibt Signale, die für die Auswahl und die Weiterleitung von Datenoperanden erzeugt wurden.
  • III.D. Ausstoß Registeroperation
  • Der Ablaufplaner 280 behandelt im Allgemeinen die Ausführungspipelines basierend auf einer in Reihenfolge Ausgabeauswahl und Verarbeitung für jeden Typ von Operation. "Normalerweise" rücken an eine Ausführungseinheit ausgegebene Operationen die Pipeline runter in der Reihenfolge weiter vor, in der die Operationen ausgegeben wurden. Wenn eine Operation zum Beispiel in der Stufe Operandenweiterleitung der SU oder LU Pipeline aufgehalten wird, wird auch die Operation aufgehalten, die gerade zur Ausgabe an diese Pipeline ausgewählt wird, weil Operationen einander nicht innerhalb einer Verarbeitungspipeline überholen dürfen. Wenn jedoch eine RegOp in der Stufe Operandenweiterleitung von entweder der Registereinheit 253 oder 254 aufgrund eines oder mehrerer nicht zur Verfügung stehender Werte für Operanden aufgehalten wird, kann die RegOp aus der Verarbeitungspipeline und zurück in den nicht ausgegebenen Zustand ausgestoßen werden. Das Ausstoßen setzt das State Feld der RegOp auf b0000 zurück. Wenn eine RegOp aus einer Stufe Operandenweiterleitung 440 ausgestoßen wird, rückt eine andere RegOp, die zur Ausgabe für diese Registereinheit ausgewählt wurde, zu der Stufe Operandenweiterleitung 440 vor und nimmt unmittelbar den Platz der ausgestoßenen RegOp ein. Gleichzeitig wird die ausgestoßene RegOp unmittelbar auswählbar für eine erneute Ausgabe an eine Registereinheit, nicht notwendigerweise an die gleiche Registereinheit.
  • Das Ausstoßen ist auf alle RegOps anwendbar, den folgenden Zwängen unterworfen. Erstens wird eine nur RUX RegOp (in der RUX Stufe Operandenweiterleitung) nicht ausgestoßen, wenn eine nur RUX RegOp derzeit zur Ausgabe an RUX ausgewählt wird, weil das Ausstoßen eine Beschränkung verletzen würde, dass nur RUX RegOps in der Reihenfolge im Hinblick aufeinander auszuführen sind. Zweitens sollte eine RegOp nur ausgestoßen werden, falls die RegOp für mehr als einen Zyklus gesperrt wird, anderenfalls nutzt ein Belassen der RegOp in der Stufe Operandenweiterleitung 440 die Ressourcen der Ausführungseinheit effizienter aus. Die Tabelle B.12 beschreibt eine Schaltung, die das State Feld von Einträgen verändert, um das Ausstoßen von RegOps zu implementieren. Die globale Steuerlogik 520 erzeugt globale Ausstoßsignale BumpRUX und BumpRUY, welche das Anlegen der Signale RUXAdv0 beziehungsweise RUYAdv0 erzwingen, so dass die geeignete ausgegebene RegOp zu der Stufe Operandenweiterleitung 440 vorrückt. Eine Beschreibung unterhalb der globale Steuerlogik 520 zeigt des weiteren die Bedingungen an, unter denen eine RegOp ausgestoßen wird.
  • III.E. Lade/Speicher Ordnung
  • Der Ablaufplaner 280 unterstützt die Beibehaltung der erforderlichen Ordnung zwischen LdOps und StOps. Insbesondere unterstützt die Lade/Speicher Ordnungslogik 534 die Überprüfung von Speicherabhängigkeiten von Ladevorgängen und Speichervorgängen durch Anzeigen der relativen Alter von ausgewählten LdOps und StOps. Falls eine LdOp oder eine StOp möglicherweise auf die gleiche Adresse wie eine ältere StOp oder LdOp, die noch nicht abgeschlossen ist, zugreift, behalten Halteoperationen in der Stufe Ausführung 460 der LU und SU Verarbeitungspipelines eine korrekte Lade/Speicher Ordnung bei.
  • Die Lade- und Speichereinheiten 251 und 252 enthalten Adresskomparatoren und eine Ordnungslogik 534 in dem Ablaufplaner 280 stellt auf einem Bus 556 Information zur Verfügung, die das relative Alter der LdStOps anzeigt, so dass nur die geeigneten Adressvergleiche berücksichtigt werden, wenn festgestellt wird, ob eine LdOp oder eine StOp in der zweiten Ausführungsstufe 460 gehalten wird. Der Prozess zur Bestimmung des relativen Alters ist ähnlich zu dem Prozess der Ausgabeauswahl/Verbreitung von Operandeninformation. Während einer ersten Phase 463 der Stufe Ausführung 460 für LdOp und StOp Pipelines, führt die Ordnungslogik 534 fünf "Ausbreitung-Beseitigung" Abtastungen über alle Einträge des Ablaufplaners von dem ältesten zu dem neuesten durch. Zwei Abtastungen vergleichen LdOps mit der StOp in der SU Stufe 460 und drei Abtastungen vergleichen StOps mit der LdOp in der LU Stufe 460. Während einer zweiten Phase 464 unter sucht der Eintrag für die LdOp und/oder die StOp in der Stufe Ausführung 460 die Ergebnisse von den dazu gehörigen zwei oder drei Abtastungsketten und treibt die globalen Signale SC_SU2OLDER, SC_SU1OLDER, SC_SU0OLDER, SC_LU2OLDER und SC_LU1OLDER auf dem Bus 556, welche die gewünschte Information über das relative Alter direkt anzeigen.
  • Eine LdOp in der Stufe Ausführung 460 oder in der Stufe 450 und durchführend die zweite Hälfte eines falsch ausgerichteten Ladevorgangs benötigt drei Abtastungsketten, um das Alter der LdOp im Hinblick auf drei Kategorien von StOps zu bestimmen. Jede Abtastungskette tastet nach der ältesten StOp in einer Kategorie ab. Eine Abtastungskette detektiert eine StOp in der Stufe 460 oder in der Stufe 450 und führt die zweite Hälfte eines falsch ausgerichteten Speichervorgangs durch. Eine weitere Abtastungskette detektiert eine StOp in der Stufe 450 und eine dritte Abtastungskette detektiert die älteste StOp, die noch nicht in der Stufe 450 ist. Der Zustand des Abtastungsbits an einem beliebigen Punkt in der Abtastungskette spiegelt wieder, ob eine ältere StOp eines gegebenen Typs schon gefunden worden ist. Daher kann der Eintrag für eine LdOp mit den Eingangsabtastungsbits das relative Alter der LdOp im Vergleich zu einer StOp in einer gegebenen Kategorie feststellen. Falls das Eingangsabtastungsbit Cin 1 ist, ist das Abtastungssignal noch nicht "beseitigt", und keine ältere StOp von der gegebenen Kategorie existiert. Die Lade/Speicher Ordnungslogik 534 bestimmt, welche, falls irgendwelche; Signale von den Adresskomparatoren relevant sind.
  • Eine StOp in der Stufe 460 oder in der Stufe 450 und durchführend die zweite Hälfte eines falsch ausgerichteten Speichervorgangs benötigt zwei Abtastungsketten, um ihr Alter im Hinblick auf zwei Kategorien von LdOps zu bestimmen. Eine Abtastungskette detektiert jede LdOp in der Stufe 460 oder in der Stufe 450 und führt die zweite Hälfte eines falsch ausgerichteten Ladevorgangs durch. Die zweite Abtastungskette detektiert jede LdOps, die noch nicht in der Stufe 460 sind. Auf der Basis der Eingangsabtastungsbits Cin für den Eintrag, der die fraglich StOp enthält, bestimmt die Ordnungslogik 534, welche Signale von den Adresskomparatoren relevant sind.
  • Jede Abtastungskette ist eine "Ausbreitung-Beseitigung" Kette von dem altesten Eintrag des Ablaufplaners zu dem neuesten. Die Tabelle B.40 in dem Anhang B beschreibt die Lade/Speicher Ordnung.
  • III.F. Behandlung Abbruch
  • Wenn ein Abbruchzyklus auftritt, wird der Ablaufplaner 280 entleert. Alle Op Quads werden ungültig gemacht durch das Löschen aller Op Quad Felder OpQV, und Felder der Einträge werden ebenfalls auf harmlose Werte gesetzt. Die Felder in den Einträgen müssen gelöscht werden, weil das Feld OpQV nur die Steuerung des Ladens und des Schiebens von Op Quads betrifft und andere Operationen in dem Ablaufplaner 280 das Feld OpQV ignorieren und annehmen, dass die Einträge gültig sind. Ein logisch ungültige Operation in dem Ablaufplaner 280 zu einer logischen aber harmlosen Operation verändert. Um dies zu tun, wird das State Feld der Operation aus abgeschlossen gesetzt, so dass die Operation nicht ausgegeben oder ausgeführt wird. Die DestBM und StatMod Felder werden gesetzt, um anzuzeigen, dass die Operation keine Registerbytes oder Status Flags modifiziert. Unter diesen Umständen können alle anderen Felder beliebige Werte haben, ohne dass jeglicher "Schaden" verursacht wird. Eine derartige Operation ist tatsächlich eine No-op Operation.
  • Ein neuer Op Quad kann in den Ablaufplaner 280 geladen werden sobald der Ablaufplaner 280 entleert ist. Der neue Op Quad gehört nicht zu einem der ausstehenden Op Quads, die entleert werden müssen; stattdessen ist es logisch der erste neue Op Quad "nach" dem Abbruch. Dies würde geschehen nach einer abgebrochenen oder falsch vorher gesagten BRCOND. Der erste neue Op Quad nach fünf Abbruchzyklen wird aufgrund von Ausnahmebedingungen verzögert.
  • Dies führt dazu, dass die folgende Sequenz von Ereignissen an dem Ende des Abbruchzyklus auftritt. Es ist zu bemerken, dass die Speicherelemente in dem Ablaufplaner 280 vollständig synchron mit dem Systemtakt sind und nicht ihren Zustand ändern in Reaktion auf Eingänge, bis zu der nächsten Grenze des Zyklus. Zuerst geschehen die Änderungen in den Feldern OpQV, State, DestBM und StatMod wie oben beschrieben. Dann schieben alle, einige oder keine der Op Quads runter in eine neue Position und ein neuer Op Quad wird in den obersten Eintrag des Ablaufplaner geladen. Für mit Ausnahmen zusammenhängende Abbrüche wird der neue Op Quad auch ungültig gemacht und welches Schieben auch immer geschieht, ist im Allgemeinen ein don't care, weil alle Op Quads in dem Ablaufplaner entleert werden. Für mit BRCONDs zusammenhängende Abbrüche ist der neue Op Quad gültig oder leer.
  • Das Abbruchsignal kommt in zwei Varianten vor, "früh" und "spät". Die frühe Version wird SC_Eabort und die späte Variante SC_Abort genannt. Das frühe Abbruchsignal wird an Bereiche des Ablaufplaners 280 übermittelt, die eine unmittelbare Nachricht eines Abbruchs erfordern. Die späte Variante ist die selbe wie die frühe, aber mit einem Flip-Flop um einen Zyklus verzögert und wird weiter verbreitet.
  • IV. Globale Steuerlogik
  • Zusätzlich zu der zu den einzelnen Einträgen gehörigen Logik enthält der Ablaufplaner 280 eine Logik, die den Ablaufplaner 280 global steuert.
  • IV.A. Von externer Logik verwendete Ablaufplanerinformation
  • Die externe Logik wie die globale Steuerlogik 520 und die Ausführungseinheiten 251 bis 254 verwenden eine Vielzahl von Informationen, die während der Verbreitungs- und Operandentransferphasen des Abrufens von Werten für die Operanden von dem 380 zur Verfügung gestellt werden. Für die meisten Typen von Operanden sind die Verbreitungs- und Operandentransferphasen während der Stufen Ausgabe und Operandenweiterleitung der Verarbeitungspipelines. Während der Verbreitungsphase wird Information über die Operation, deren Operanden abgerufen werden, auf dem geeigneten OpInfo Bus 551 ausgelesen; und die zwei Quellregister (Src1 und Src2) der Operation und die Bytemarkierung (Src1BM und Src2BM) Felder werden auf zwei dazu gehörigen OprndInfo Bussen 552 ausgelesen. Für den Datenoperand von StOps sind die Verbreitungs- und Operandentransferphasen während der SU Stufen 450 und 460. Information für die Datenoperanden einer StOp wird auf einem dazu gehörigen OprndInfo Bus 552 getrieben, aber es gibt keine dazu gehörige OpInfo. Die Speichereinheit 252 hält Information einer Operation von dem Zeitpunkt zurück, an dem die StOp ausgegeben wurde. Die Verbreitung der Operandeninformation wird während der nächsten paar Phasen verwendet. Die Information der Operation wird einfach die Pipeline runter an die Ausführungseinheiten weiter gereicht. Für den Fall der Registereinheiten 253 und 254 werden auch die zwei Quellbytemarkierung Src1BM und Src2BM Bits von den OprndInfo Bussen 552 die Pipeline runter weiter gereicht. Während der Operandentransferphase wird Information über jede der Operationen, welche die Quelle eines Operandenwerts ist, von dem OprndStat Bus 533 ausgelesen, der zu jedem Operandenbus 554 gehört. Die Information, die den Status der die Quelle bildenden Operation beschreibt, wird während dieser Phase direkt verwendet (und nur verwendet). Die Tabelle B.41 fasst die aus dem Ablaufplaner 280 zu verschiedenen Zeitpunkten ausgelesene Information zusammen.
  • IV.B. Globale Steuerfunktionen
  • Das Vorgehende beschreibt die Logik, Speicherelemente und Busse, die den Kern des Ablaufplaners 280 enthalten. Der Ablaufplaner 280 enthält auch eine globale Steuerlogik 520, die das Schieben in dem Ablaufplaner 280 steuert und das "Zuführen" von Operationen und Operanden an die Ausführungseinheiten 251 bis 254. Das Folgende beschreibt Stücke der globalen Steuerlogik 520 für die vier Phasen des Prozesses des Abrufens von Operanden.
  • Während der Ausgabeauswahlphase ist das einzige externe Interesse, ob eine Operation für die Ausgabe an jede Verarbeitungspipeline ausgewählt wurde. Für jede Auswahl der Ausgabe, die keine auswählbare Operation fand, treibt kein Eintrag des Ablaufplaners die entsprechenden OpInfo und OprndInfo Busse 551 und 552. Die Werte auf diesen Bussen und die folgenden drei Phasen für diese Verarbeitungspipeline sind don't care. Das einzige Erfordernis ist, dass ein Operation gültig Bit (OpV) für die Stufe Operandenweiterleitung 440 einer Verarbeitungspipeline Null ist, um anzuzeigen, dass die Stufe Operandenweiterleitung 440 in dieser Stufe der Pipeline leer ist.
  • Die Operation gültig Bits (OpV) für die Stufe Operandenweiterleitung zeigt an, ob gültige Operationen an die Ausführungseinheiten ausgegeben werden. Das Ausgangsabtastungsbit Cout von jeder Abtastungskette einer Ausgabeauswahl erzeugt ein OpV Bit für Operationen in der Stufe Ausgabe. Die Tabelle B.42 beschreibt die Operation gültig oder OpV Bits. Die globalen Signale XXAdv0 steuern das Laden von OpV Bits in die Pipelineregister, um dem Fortschritt der leeren Operation zu folgen. Während Abbruchzyklen werden alle Pipelineregister ohne Bedingung gelöscht, um die Ausführungseinheiten zu entleeren.
  • Die Verbreitungsphase erfordert keine erhebliche globale Steuerlogik als die Steuerung der Pipelineregister, welche von dem Ablaufplaner 280 gelesene Information (nämlich die OprndInfo und OpInfo Werte) verriegeln.
  • Während der Operandenauswahlphase geschehen zwei externe Ereignisse. Zuerst werden die Quellregisternummern (das heißt die SrcYReg Felder der verriegelten OprndInfo Werte), die während der vorherigen Phase gelesen wurden, verwendet, um auf die Registerdatei 290 zuzugreifen. Dies geschieht parallel zu den Abtastungen der Auswahl der Operanden in dem Ablaufplaner 280. Bis zu neun Quelloperanden können jeden Zyklus abgerufen werden. Entsprechend hat die Registerdatei 290 neun entsprechende Leseanschlüsse, von denen jeder zu einem der Operandenbusse 554 gehört. Die an diese Leseanschlüsse gelieferten Registerfelder sind XXsrcY und SusrcSt, wobei XX = {LU, SU, RUX, RUY} und Y = {1, 2}.
  • Ein zweites externes Ereignis während der Operandenauswahlphase ist, für jeden Operandenbus 554 und Operandeninformationsbus 552 festzustellen, ob der Ablaufplaner 280 oder die Registerdatei 290 einen Wert während der nächsten Phase zur Verfügung stellen wird. Jeder Eintrag des Ablaufplaners bestimmt direkt für sich selbst, ob er die Busse treiben sollte oder nicht, deshalb ist die einzige Angelegenheit für die globale Steuerlogik 520, ob die Registerdatei 290 frei gegeben werden sollte. Die Freigabe der Registerdatei 290 basiert auf den Ausgangsabtastungsbits Cout, die anzeigen, ob irgendein Eintrag während der Operandenauswahlphase ausgewählt wurde. Falls das letzte Abtastungssignal Cout einer Abtastungskette für die Auswahl von Operanden anzeigt, dass kein Eintrag für den dazu gehörigen Operandenbus 554 ausgewählt wurde, gibt die globale Steuerlogik die Registerdatei 290 frei, um den dazu gehörigen Operandenbus 554 und den Operandeninformationsbus 552 zu treiben. Gleichungen, welche die Signale auf den Operandenbussen 554 beschreiben, sind in den Tabellen B.35 und B.36 von Anhang B.
  • Während der Operandentransferphase steuert die globale Steuerlogik 520: das "Ausstoßen" von RegOps, alle Ausführungseinheiten-Eingangsmultiplexer 1010 der Ausführungseinheiten, die Bestimmung der Gültigkeit für jeden abzurufenden Operandenwert und die Erzeugung des Signals HoldXX0, das sich in die Erzeugung der globalen Steuersignale für die Pipelineregister XXAdv0 zerlegt.
  • Eine Implementierung des Ausstoßens von RegOps wird zwischen der Logik in jedem Eintrag des Ablaufplaners, die das State Feld des Eintrags ändert, und der globalen Steuerlogik 520 aufgeteilt, welche die globalen Ausstoßsignale BumpRUX und BumpRUY erzeugt und das Anlegen der Signale RUXAdv1 und RUYAdv1 erzwingt. Die Erzeugung der BumpRUX/Y Signale ist basiert auf den OprndStat Werten, die während der Operandentransferphase für jeden der Registereinheit-Quelloperanden (das heißt OprndStat_RUXsrcY und OprndStat_RUYsrcY, wobei srcY = {src1, src2}) aus dem Ablaufplaner 280 ausgelesen werden. Insbesondere werden die Felder State und Type für jede Operandenquelle untersucht, um festzustellen, ob die die Quelle zur Verfügung stellende Operation zumindest zwei Zyklen entfernt ist von der Bereitstellung eines korrekten Werts für den O peranden. Falls jede eine Quelle zur Verfügung stellende Operation zumindest zwei Zyklen entfernt ist von der Bereitstellung eines korrekten Werts für den Operanden, wird die abhängige RegOp aus der Stufe Operandenweiterleitung ausgestoßen. Eine RegOp ist zumindest zwei Zyklen entfernt ist von der Bereitstellung eines Operanden, wenn die RegOp noch nicht zu der Stufe Operandenweiterleitung vorgerückt ist. Eine LdOp ist zumindest zwei Zyklen entfernt ist von der Bereitstellung eines Operanden, wenn die LdOp noch nicht zu der ersten Ausführungsstufe vorgerückt ist.
  • Die Tabelle B.43 fasst die Erzeugung der Signale BumpRUX/Y zusammen und umfasst einen zusätzlichen Zeitüberschreitungsausdruck, der Situationen behandelt, die ansonsten Blockadesituationen wären. 3-Bit Zähler, die zu den RUX und RUY Stufen Operandenweiterleitung gehören, erzeugen Signale RUX/Ytimeout nachdem eine Operation für mehr als eine Zeitüberschreitungsperiode in der Stufe Operandenweiterleitung fest gehalten worden ist. Nimmt man RUX als Beispiel, wird, wann immer die RUX Stufe Operandenweiterleitung geladen wird (ohne Rücksicht, ob mit einer gültigen oder ungültigen Operation), der dazu gehörige Zähler auf einen Startwert zurück gesetzt. Während aller anderen Zyklen wird der Zähler runter gezählt. Falls der Zähler 000 erreicht, dann wird RUXtimeout angelegt, um anzuzeigen, dass die Operation zu lange aufgehalten worden ist.
  • Die RUX/Ytimeout Signale veranlassen ein Setzen des entsprechenden Operation gültig Signals OpV für die Stufe Operandenweiterleitung der Registereinheiten 253 und 254. Zum Beispiel erzwingt des Signal RUXtimeout unmittelbar das Signal OpV_RUX_0 auf gleich 0, was dann die Ausgabe des Pipelinesteuersignals RUXAdv0 veranlasst, um die RUX Stufe Operandenweiterleitung erneut zu laden. Das Signal OpV_RUX_0 stellt sicher, dass die RUX Stufe Ausführung 450 die ausgestoßene RegOp nicht sieht, wenn das Signal RUXAdv1 ebenfalls angelegt ist.
  • Eine zweite während der Operandentransferphase 442 auftretende globale Steuerfunktion ist die Erzeugung eines Steuersignals für jeden Quelloperanden Eingangsmultiplexer 1010, die mit den Ausführungseinheiten 251 bis 254 verbunden sind. Wie oben beschrieben wählt jeder 5:1 Multiplexer 1010 einen Operanden von einem dazu gehörigen Operandenbus 554 oder einem der Ergebnisbusse 561 bis 564 aus, um ihn in ein dazu gehöriges Operandenregister 1021 bis 1024 oder 1031 bis 1034 zu laden. Während der Operandentransferphase 442 verwendet die Steuerlogik 520 die Operandenstatussignale von den Bussen 553, um die Steuersignale für jeden der Multiplexer 1010 zu erzeugen und um die Operanden OprndStat SusrcSt und OprndStat XXsrcY auszuwählen, wobei XX = {LU, SU, RUX; RUY} und Y = {1, 2}, um sie in die Operandenregister zu laden. Insbesondere untersucht die globale Steuerlogik 520 die Felder State und Type für jede Operandenquelle, um festzustellen, ob die die Quelle bildende Operation die Ausführung abgeschlossen hat und, falls nicht abgeschlossen, welche Ausführungseinheit die die Quelle bildende Operation ausführt. Der Operandenbus 554 wird ausgewählt, wenn die Quellen die Registerdatei 290, eine abgeschlossene Operation oder eine Operation, die sich selbst einen src2 unmittelbaren Wert zur Verfügung stellt, sind. Anderenfalls wird der Ergebnisbus von der Ausführungseinheit ausgewählt, die dem Typ der die Quelle bildenden Operation entspricht. Die Tabelle B.44 in dem Anhang B fasst die Erzeugung der Auswahlsignale für jeden Operanden zusammen.
  • Eine dritte globale Steuerfunktion, die während der Operandentransferphase geschieht, ist die Feststellung der Gültigkeit von jedem der neun Operandenwerte, die den Quelloperandenregistern der Ausführungseinheiten präsentiert werden. Ein Signal wird für jeden Quelloperanden erzeugt, um anzuzeigen, ob der Wert des Quelloperanden gültig ist. Wie mit der Steuerung des dazu gehörigen Multiplexers 1010 der Ausführungseinheit basiert die Bestimmung der Gültigkeit des Operanden auf den Feldern State und Type der OprndStat Werte von den Bussen 553. Eine die Quelle bildende Operation muss entweder die Ausführung abgeschlossen haben oder zur Zeit die Ausführung für einen gültig zu seienden Operanden abschließen. Des weiteren wird das DestBM Feld des OprndStat Werts mit dem Feld Src1BM oder Src2BM des verriegelten OprndInfo Werts für den Operanden, der abgerufen wird, verglichen. Falls der Operand gültig ist, muss die Bytemarkierung der die Quelle bildenden Operation ein Supersatz der erforderlichen Bytemarkie rungen Src1BM oder Src2BM sein. Ein src2 unmittelbarer Wert ist immer gültig. Ein Signal OprndInvld_XXsrcY wird angelegt, um anzuzeigen, dass der Operand srcY für die Ausführungseinheit XX ungültig ist. Die Tabelle B.45 fasst eine Logik zusammen, welche die Signale OprndInvld_XXsrcY erzeugt.
  • Eine vierte globale Steuerungsfunktion, die während der Operandentransferphase auftritt, ist die Erzeugung eines Pipelinesteuersignals, das die Operation in einer Stufe der Pipeline aufhält, wenn die erforderlichen Operanden für ein Vorrücken nicht gültig sind. Die Signale SC_HoldXX0 halten Operationen in der Stufe Operandenweiterleitung 440 der Ausführungseinheit XX, falls keine Quelloperanden zur Verfügung stehen. StOps können aus der Stufe Operandenweiterleitung 440 vorrücken, sogar wenn der Datenoperand nicht zur Verfügung steht, aber das Signal SC_HoldSU2 hält die StOp in der zweiten Ausführungsstufe 460, wenn der Datenoperand dann ungültig ist. Cc-dep RegOps werden in der Stufe Operandenweiterleitung 440 aufgehalten, falls die erforderlichen Bedingungscodes ungültig sind. Die Tabelle B.45 fasst eine Logik zusammen, welche die Signale SC_HoldXX0 und SC_HoldSU2 erzeugt.
  • V. Status Flags
  • Die Status Flag Logik 538 für sowohl die x86 architekturalen Flags als auch die mikro-architekturalen Flags umfasst drei Gebiete von Funktionalität: das Abrufen von Status Flag Operandenwerten für cc-dep RegOps, das Abrufen von Status Flag Werten für die Auflösung von BRCONDs und das Synchronisieren nicht abbrechbarer RegOps mit vorher gehenden BRCONDs. Anders als die Operandenauswahllogik 532 und die LdOp-StOp Ordnungslogik 534 ist die Status Flag Behandlungslogik 538 nicht über alle Einträge des Ablaufplaners verteilt. Die Behandlung von Status Flags für verwandte Operationen tritt nur auf während Operationen, die auf Status Flags zugreifen, die innerhalb gewisser Zeilen des Ablaufplaners 280 sind. Cc-dep RegOps müssen während des Zyklus in der Zeile 3 sein, wenn ein Abrufen der Statusoperanden geschieht (das heißt während der RUX Stufe Operandenweiterlei tung). BRCONDs und nicht abbrechbare RegOps müssen während der Auflösung durch die Verzweigungsbewertungseinheit 257 in der Zeile 4 beziehungsweise in der RUX Stufe Operandenweiterleitung sein. Entsprechend werden cc-dep und nicht abbrechbare RegOps in der RUX Stufe Operandenweiterleitung aufgehalten, bis sie in die Zeilen 3 beziehungsweise 4 runter schieben, und das Schieben der Op Quads in den Zeilen 3 und 4 wird verhindert, bis die cc-dep und nicht abbrechbaren RegOps in diesen Zeilen in die RUX Stufe Ausführung vorrücken können. Die BRCOND verbleibt in Zeile 4 bis die für die Bewertung erforderlichen Status Flags gültig sind.
  • Die Beschränkung der Ausführung oder der Bewertung von cc-dep RegOps, nicht abbrechbaren RegOps und BRCOND auf die Fälle, wenn die Operationen in bestimmten Zeilen des Ablaufplaners 280 sind, vereinfacht die Status Flag Behandlungslogik 538. Zum Beispiel ist die Status Flag Behandlungslogik 538 nur in den untersten drei Zeilen des Ablaufplaners erforderlich und nur die untersten beiden Zeilen werden verwendet, um die geeigneten Werte der Status Flags zu bestimmen. Des weiteren können die gleichen Werte der Status Flags sowohl von einer cc-dep RegOp in Zeile 3 als auch von einer BRCOND in Zeile 4 geteilt werden. Die Synchronisierung zwischen den nicht abbrechbaren RegOps und BRCONDs wird vereinfacht, weil die Position von BRCONDs, in der sie bewertet werden, fest ist.
  • Eine Anzahl von Beschränkungen, die bezogen sind auf die Positionierung von cc-dep RegOps, BRCONDs und nicht abbrechbaren RegOps relativ zueinander innerhalb von Op Quads, vereinfacht die Logik weiter. Die Beschränkungen übersetzen sich im wesentlichen zu Kodierregeln für die Emcodierung, aber zwingen in einigen Fällen auch die MacDec 242 Dekodierung von mehreren Makrobefehlen in einem Zyklus. Die Beschränkungen erfordern, dass ein Op Quad enthält:
    • 1) Keine cc verändernden RegOps nach einer BRCOND;
    • 2) Keine cc verändernden RegOps vor einer cc-dep RegOp;
    • 3) Keine nicht abbrechbaren RegOps und eine BRCOND zusammen;
    • 4) Nur eine cc-dep RegOp;
    • 5) Nur eine BRCOND; und
    • 6) Nur eine nicht abbrechbare RegOp.
  • Mit diesen Beschränkungen sind Status Flags, die für eine cc-dep RegOp in Zeile 3 korrekt sind, ebenso für eine BRCOND in Zeile 4 korrekt, und die gleiche Status Flag Schaltung dient zwei Zwecken.
  • V.A. Abruf Status Flags
  • Die Status Flag Behandlungslogik 538 ruft vier unabhängige Gruppen von Status Flags ab, die den vier Bits des Felds StatMod entsprechen. Die Tabelle B.47 in dem Anhang B identifiziert die vier Flag Gruppen und ihre Übereinstimmung mit dem Feld StatMod. Ob jede Gruppe für eine Operation gültig ist, wird unabhängig bestimmt in Abhängigkeit davon, ob ältere Operationen, welche die Gruppe ändern könnten, abgeschlossen wurden.
  • Die Weitergabe der Werte der Status Flags direkt von entweder der Registereinheit 253 oder 254 an eine cc-dep RegOp, die die Registereinheit 253 betritt, wird in dem beispielhaften Ausführungsbeispiel nicht unterstützt. Entsprechend werden die Status Flags in dem Zyklus gültig, der dem Abschluss einer einen Bedingungscode ändernden RegOp folgt. Dies erzeugt eine minimale Latenz von einem Zyklus zwischen einer RegOp, die eine bestimmte Gruppe von Status Flags modifiziert, und einer Ausführung von einer folgenden cc-dep RegOp, welche die Gruppe verwendet. Der statistische Einfluss von dieser Latenz auf die Leistungsfähigkeit ist minimal, weil die cc-dep RegOps relativ selten sind, wenn typischer x86 Code dekodiert wird. Des weiteren kann jeder Einfluss von der Latenz eliminiert werden, wenn der Befehlsdekodierer 240 die RISC86 Operationen ordnet, um eine cc-dep RegOp in einem Op Quad zu vermeiden, der unmittelbar einer RegOp folgt, welche die für die cc-dep RegOp benötigten Bedingungscodes ändert.
  • Während jedes Zyklus wird der effektive Satz von. Werten der Status Flags an der Grenze zischen den Zeilen 3 und 4 des Ablaufplaners berechnet. Die berechneten Status Flags umfassen das übergebene Status Flag und alle Änderungen an den Status Flags, die durch die Operationen in den Zeilen 4 und 5 veranlasst wurden. Wie oben erwähnt verändern nur die RegOps die Status Flags. Da jede RegOp nur eine, zwei, drei oder alle vier der Gruppen von Status Flags ändern kann, wird die Berechnung der Status Flags unabhängig für jede der vier Gruppen durchgeführt. Das Ergebnis dieser Berechnung, für jede Gruppe, ist ein Satz von Flag Werten und Zustandsinformationen von der neuesten RegOp mit einem StatMod Bit, das dem Gruppensatz entspricht. Das State Feld für diese RegOp zeigt an, ob die RegOp abgeschlossen wurde und die zur Verfügung gestellten gültigen Flag Werte.
  • Die Status Flag Logik 538 erzeugt acht Status Flag Bits STATUS und vier Gültigkeitsbits STATUSV, die zu den vier Gruppen von Status Flags wie in der Tabelle B.47 gezeigt gehören. Diese 12 Bit werden über einen Bus 557 an die Verzweigungsbewertungseinheit 257, die die BRCONDs bewertet, und an Logik in der Registereinheit 253, die die cc-dep RegOps behandelt, weiter gegeben. Die Registereinheit 253 und die Verzweigungsbewertungseinheit 257 bestimmen anhand der Gültigkeitsbits STATUSV, ob die erforderlichen Status. Flags gültig sind, und falls sie gültig sind, verwenden sie die STATUS Bits, um die cc-dep RegOps (falls vorhanden) in Zeile 3 auszuführen und um die BRCOND (falls vorhanden) in Zeile 4 zu bewerten. Die globale Steuerlogik 520 erzeugt Schiebesteuersignale basierend darauf, ob die erforderlichen Status Flags gültig sind.
  • Ein Prozess ähnlich zu dem für das Abrufen der Werte der Registeroperanden ruft jede Status Flag Gruppe ab, um die geeigneten Flag Werte für die letzte Operation in der Zeile 3 des Ablaufplaners 280 zu erhalten. Im Folgenden bezieht sich die Schreibweise OpX auf den Eintrag X in dem Ablaufplaner 280, wobei X = 0 beziehungsweise X = 23 die neueste und älteste Operation in dem Ablaufplaner 280 identifiziert. Die Zeile 4 zum Beispiel enthält Op16, Op17, Op 18 und Op19. Für jede Flag Gruppe lokalisiert eine Abtastung vom Ausbreitung-Beseitigung Typ von Op16 bis Op23 die erste Operation mit dem für diese Flag Gruppe gesetzten StatMod Bit und das abgeschlossen Zustand Bit dieses Eintrags (das heißt 53) und der geeignete Satz von Flag Werten werden ausgelesen. Das StatusV Bit für diese Gruppe ist einfach das State Bit 53 von dem gefundenen Eintrag. Falls keine derartige Operation gefunden wird, werden die gewünschten Flag Werte von dem architekturalen Status Flag Register gelesen und das Signal STATUSV wird gesetzt, um anzuzeigen, dass die Gruppe gültig ist. Die Tabelle B.48 beschreibt die Status Flag Abruflogik für jede Flag Gruppe.
  • V.B. Weiterleitung Status an cc-Dep RegOps
  • Während jedes Zyklus untersucht die globale Steuerlogik 520 die vier Operationen in der Zeile 3, um festzustellen, ob eine von ihnen eine cc-dep RegOp ist. Falls eine ist, wird dann diese RegOp dekodiert, um festzustellen, welche Gruppen von Status Flags benötigt werden, und die StatusV Bits werden überprüft, um festzustellen, ob alle diese Gruppen gültig sind. Nebenher wird Status[7:0] ohne Überprüfung an die RUX Ausführungseinheit übergeben. Falls eine der erforderlichen Flag Gruppen zur Zeit nicht gültig ist, wird die cc-dep RegOp vom Vorrücken in die RUX Stufe Ausführung abgehalten und das Schieben des Op Quads aus der Zeile 3 wird verhindert. Falls alle der erforderlichen Flag Gruppen gültig sind, wird es der cc-dep RegOp erlaubt, in die RUX Stufe Ausführung vorzurücken, zumindest soweit wie das Abrufen des Statusoperanden betroffen ist. Die cc-dep RegOp kann immer noch an dem Vorrücken gehindert werden, weil ein Operand nicht zur Verfügung steht. Falls die cc-dep RegOp nicht in die Stufe Ausführung 460 vorrückt, wird das Schieben der Zeile 3 verhindert.
  • Falls in den Zeilen 3 bis 5 keine nicht ausgeführte cc-dep RegOp ist, aber eine cc-dep RegOp in der RUX Stufe Operandenweiterleitung ist, dann wird die RegOp ohne Bedingung in der Stufe Operandenweiterleitung aufgehalten. Falls eine cc-dep RegOp in der Zeile 3 noch nicht ausgeführt wurde, aber sich keine cc-dep RegOp in der RUX Stufe Operandenweiterleitung befindet, wird das Schieben der Zeilen 3 verhindert. Die Tabelle B.49 beschreibt eine Logik, die das Schieben und das Vorrücken von Operationen steuert.
  • V. Auflösung Verzweigungsvorhersage
  • Während jedes Zyklus, wenn eine BRCOND in der Zeile 4 gefunden wird, wird das Bedingungscode (cc) Feld von dieser BRCOND dekodiert, um einen vorher gesagten Bedingungswert zu bestimmen. Der vorher gesagte Bedingungswert wird mit einem ausgewählten aus den 32 Bedingungswerten, die aus den Status Flags von der Status Flag Behandlungslogik 538 abgeleitet sind, verglichen, falls die dazu gehörigen Gültigkeitsbits anzeigen, dass die ausgewählte Bedingung gültig ist. Falls die ausgewählte Bedingung noch nicht gültig ist, wird das Schieben des Op Quads in Zeile 4 verhindert und die Bewertung der BRCOND wird wieder in dem nächsten Taktzyklus versucht. Falls die ausgewählte Bedingung gültig ist, zeigt ein Vergleich der vorher gesagten Bedingung und der ausgewählten Bedingung an, ob die Vorhersage korrekt war.
  • Falls eine BRCOND als falsch vorher gesagt befunden wurde (und damit ein Neustart der Pipeline erforderlich ist), wird das Neustartsignal angelegt auf der Basis, ob die BRCOND von dem MacDec 242 ist oder eine Emcode Operation von der internen oder externen Emcodierung ist. Des weiteren werden eine geeignete Adresse eines x86 Makrobefehls oder eines Emcodeeinsprungs und ein dazu gehöriger Rückkehradressenstapel TOS Wert erzeugt und an den Befehlsdekodierer 240 zurück gegeben, um die Kodierung erneut zu starten.
  • Für den Nutzen der Logik, welche die Synchronisation zwischen den nicht abbrechbaren RegOps und vorher gehenden BRCONDs behandelt (in dem nächsten Abschnitt beschrieben), wird eine Aufzeichnung von einer falsch vorher gesagten BRCOND unterhalten, während sie ausstehend verbleibt (das heißt bis ein Abbruchzyklus auftritt). Des weiteren hält eine ausstehende falsch vorher gesagte BRCOND das Laden eines "neuen" Op Quads auf, bis der Abbruchzyklus auftritt.
  • Falls eine BRCOND korrekt vorher gesagt wurde, ist die einzig unternommene Aktion, das State Bit S3 der BRCOND zu setzen, um anzuzeigen, dass die BRCOND abgeschlossen ist. Die Tabelle B.50 beschreibt eine Logik, welche die Bewertung von BRCONDs behandelt.
  • VI. Synchronisierung nicht abbrechbarer Operationen
  • Während jedes Zyklus, falls eine nicht abbrechbare RegOp in der Zeile 4 gefunden wurde, überprüft der Ablaufplaner 280 dann auf irgendwelche vorher gehenden, falsch vorher gesagten BRCONDs. Wegen der Beschränkungen bei der Emcodekodierung, müssen alle vorher gehenden BRCONDs in einer niedrigeren Zeile sein und müssen daher alle aufgelöst worden sein. Des weiteren ist jede BRCOND, die zur Zeit aufgelöst wird (in Zeile 4), nach der nicht abbrechbaren RegOp und ist daher nicht relevant.
  • Falls es keine. falsch vorher gesagte BRCOND gibt, wird der nicht abbrechbaren RegOp erlaubt, in die RUX Stufe Ausführung vorzurücken, obwohl die RegOp nicht vorrückt, falls erforderliche Operanden noch nicht zur Verfügung stehen. Falls die RegOp nicht unmittelbar in die RUX Stufe Ausführung vorrückt, ist es der RegOp immer noch erlaubt, aus der Zeile 4 zu schieben.
  • Falls die Zeilen 4 oder 5 eine nicht ausgeführte, nicht abbrechbare RegOp enthalten, aber keine nicht abbrechbare RegOp in der RUX Stufe Operandenweiterleitung ist, wird die nicht abbrechbare RegOp bedingungslos in der Stufe Operandenweiterleitung fest gehalten, bis die nicht abbrechbare RegOp die Zeile 4 erreicht. Falls eine nicht abbrechbare RegOp in der Zeile 4 noch nicht ausgeführt worden ist, aber keine nicht abbrechbare RegOp in der RUX Stufe Operandenweiterleitung ist, oder eine nicht ausgeführte, nicht abbrechbare RegOp in der Zeile 5 ist, wird das Schieben der Zeilen 4 und 5 verhindert. Die Tabelle B.51 beschreibt eine Logik, welche die nicht abbrechbaren RegOps behandelt.
  • VII. Behandlung selbstmodifizierender Code
  • Die Speicherwarteschlange 270 stellt verschiedene Bits der linearen und physikalischen Adressen für Daten zur Verfügung, die übergeben werden sollen. Falls die Speicheradressen mit einer beliebigen Befehlsadresse für einen Op Quad überein stimmen, könnte ein Schreibvorgang zu einem Befehl einen Befehl verändert haben, und eine nun in dem Ablaufplaner 280 vorliegende (dekodierte) Operation könnte nicht korrekt sein. Die nicht korrekte Operation muss korrigiert werden bevor Ergebnisse von dieser Operation übergeben werden.
  • In dem beispielhaften Ausführungsbeispiel dieser Erfindung vergleicht die Unterstützungslogik für den selbstmodifizierenden Code 536 Adressbits von der Speicherwarteschlange 270 mit der Adresse des Befehls (oder den Adressen, falls die Befehle in einem Op Quad von verschiedenen Seiten sind) von jedem Op Quad. Falls ein Vergleich die Möglichkeit einer Veränderung des Codes eliminiert, macht die Logik 536 nichts. Falls die Möglichkeit nicht eliminiert ist, entleert die Logik 536 den Ablaufplaner 280 und startet den Prozess des Abrufens/Dekodierens von der Adresse des letzten übergebenen Befehls an. Logisch wird in dem Ablaufplaner 280 die Detektierung von selbstmodifizierendem Code wie eine Art von Falle behandelt und unterteilt sich in ein Signal, dass eine "anhängige Falle" anzeigt. Die Tabelle B.52 beschreibt einen beispielhaften Bereich der Behandlungslogik für den selbstmodifizierenden Code 536.
  • VIII. Operationsübergabeeinheit
  • Die OCU (Operationsübergabeeinheit) 260 arbeitet im Allgemeinen an den Operationen in der letzten oder der vorletzten Zeile (Zeile 4 oder 5) des Ablaufplaners 280. Die prinzipielle Funktion der OCU 260 ist es, die Ergebnisse von Operationen zu übergeben (oder dauerhaft zu machen) und dann die Op Quads aus dem Ablaufplaner 280 zurück zu ziehen. Die OCU 260 leitet auch Abbruchzyklen ein.
  • Viele Typen von Ergebnissen oder Zustandsänderungen können von der Ausführung einer Operation her stammen. Die prinzipiellen Typen von Veränderungen sind abbrechbar und umfassen: Registeränderungen; Status Flag Änderungen und Speicherschreibvorgänge. In dem RISC86 Befehlssatz ergeben sich Änderungen der Register aus allen RegOps, LdOps, LIMMOps, LDK Operationen und STUPD StOps. Änderungen der Status Flags resultieren aus ".cc" RegOps und Speicherschreibvorgängen, die von Stxx StOps stammen. Der Ablaufplaner 280 und die Speicherwarteschlange 270 unterstützen abbrechbare Änderungen des Zustands durch ein temporäres Speichern der Register und Statusergebnisse in Einträgen in dem Ablaufplaner 280 und der Daten der Speicherschreibvorgänge in Einträgen in der Speicherwarteschlange 270, bis die dazu gehörige Operation übergeben und zurück gezogen ist. Die Übergabe der Operation macht die Änderungen des Zustands dauerhaft. Während die neuen Werte des Zustands in dem Ablaufplaner 280 und der Speicherwarteschlange 270 ansässig sind, werden die Werte des Zustands wie erforderlich an die abhängigen Operationen weiter geleitet.
  • Alle anderen Änderungen des Zustands können nicht abgebrochen werden und ergeben sich aus der Ausführung nicht abbrechbarer RegOps. Die Änderungen des Zustands, die nicht abgebrochen werden können, umfassen Änderungen an den Standard x86 Registern, wie den Segmentregistern und den nicht Status EFlag Bits und Änderungen an den mikro-architekturalen Registern für die Ausführung von RISC Operationen. Nicht abbrechbare Änderungen des Zustands können unmittelbar während der Ausführung nicht abbrechbarer RegOps auftreten und der Befehlsdekodierer 240 und der Ablaufplaner 280 sind verantwortlich, dass eine ausreichende Synchronisierung der nicht abbrechbaren Operationen mit den umgebenden Operationen sicher gestellt ist.
  • VIII.A. Übergabe
  • Während jedes Zyklus untersucht die OCU 260 Operationen in den Zeilen 4 und/oder 5 des Ablaufplaners 280 und versucht, die Ergebnisse von so vielen Operationen wie möglich zu übergeben. Die Zustandsänderungen in einem Op Quad können in einem Zyklus oder über mehrere Zyklen übergeben werden. Falls alle der Operationen von einem Op Quad in der untersten Zeile übergeben worden sind oder erfolgreich übergeben werden, wird der Op Quad aus dem Ablaufplaner 280 an dem Ende des derzeitigen Zyklus zurück gezogen, dadurch, dass es einem Op Quad erlaubt wird, von der Zeile 4 in die Zeile 5 zu schieben und diese zu überschreiben. Anderenfalls werden so viele Änderungen wie möglich übergeben und das Schieben in die Zeile 5 wird verhindert. Der Prozess der Übergabe wird jeden Zyklus wiederholt, bis alle Operationen in der Zeile 5 übergeben worden sind und es dem Op Quad aus Zeile 4 erlaubt ist, in die Zeile 5 runter zu schieben.
  • Die Übergabe von Registerergebnissen, Statusergebnissen und Speicherschreibvorgängen werden unabhängig durchgeführt. Für Operationen, die mehrere Ergebnisse haben (zum Beispiel eine RegOp mit Register- und Statusergebnissen oder eine STUPD Operation mit einem Registerergebnis und einem Speicherschreibvorgang), werden die verschiedenen Ergebnisse nicht notwendigerweise gleichzeitig übergeben. Die Übergabe eines Typs von Zustandsveränderung kann im Allgemeinen vor oder hinter der Übergabe eines anderen Typs von Zustandsveränderung sein. Die gesamte Übergabe von einer Operation geschieht, wenn die OCU 260 das letzte Ergebnis von der Operation übergibt.
  • Die Ergebnisse einer Operation werden nicht übergeben bis: der Zustand der Ausführung der Operation anzeigt, dass die Operation abgeschlossen ist; jegliche voraus gehenden, fehlerhaften Operationen, nämlich alle vorher gehenden LdStOps, abgeschlossen sind, was impliziert, dass die Operationen fehlerfrei sind; und jegliche vorher gehenden BRCONDs abgeschlossen sind, was impliziert, dass die BRCONDs korrekt vorher gesagt wurden. FAULT Operationen sind nicht von Interesse, da der Dekodierer 240 jede FAULT Operation als die erste "gültige" Operation in einem Op Quad platziert, so dass keine Operationen in der gleichen Zeile wie eine FAULT Operation abgeschlossen werden müssen. Für StOps, die einen Speicherschreibvorgang erzeugen, ist eine weitere Beschränkung, dass nur ein Schreibvorgang pro Zyklus von der Speicherwarteschlange 270 in den Daten-Cachespeicher 220 übergeben werden kann.
  • Die OCU 260 kann bis zu vier Register und vier Statusergebnisse und einen Speicherschreibvorgang pro Zyklus übergeben und zieht jeden Zyklus einen Op Quad aus dem Ablaufplaner 280 zurück. Ein Op Quad bleibt in der untersten Zeile des Ablaufplaners 280 und für mehr als einen Zyklus nicht zurück gezogen, nur wenn der Op Quad mehrere in den Speicher schreibende StOps enthält oder wenn einige der Operationen in dem Op Quad noch nicht abgeschlossen sind.
  • Falls eine Operation in der untersten Zeile als fehlerhaft behandelt werden muss, zum Beispiel falls die Operation eine FAULT Operation ist oder ein Fehler während der Ausführung der Operation auftritt, wird die Übergabe der folgenden Operationen verhindert. Sobald alle älteren Operationen innerhalb des Op Quads, die als fehlerhaft behandelt werden, übergeben worden sind oder erfolgreich übergeben werden, zieht die OCU 260 den Op Quad zurück und leitet einen Abbruchzyklus ein. Der Abbruchzyklus entleert den Ablaufplaner 280 und alle Ausführungseinheiten von allen ausstehenden Operationen.
  • Nebenher zu dem Abbruchzyklus führt die OCU 260 auch den Befehlsdekodierer 240 zu einer von zwei möglichen Emcode "Eintrittspunkt" Adressen, entweder die "Vorgabe" Fehlerbehandlungsadresse (wie durch einen Neustart von Emcode initialisiert) oder eine "alternative" Behandlungsadresse (wie von einem Makrobefehl oder einem eine Ausnahme verarbeitenden Emcode angegeben). LDDHA und LDAHA Operationen, die in einem abgeschlossenen Zustand in den Ablaufplaner 280 geladen werden und von der OCU 260 erkannt und "ausgeführt" werden, wenn sie den Boden des Ablaufplaners 280 erreichen, unterstützen das Setzen der Fehler Vorgabe- und alternativen Behandlungsadressen.
  • Nur gewisse Typen von Operationen können als fehlerhaft behandelt werden, nämlich LdOps, StOps (außer LEA Operationen) und FAULT Operationen. Für eine LdOp oder eine StOp werden Fehler von der zweiten Ausführungsstufe 460 der LU oder SU Ausführungspipeline identifiziert; und wenn ein Fehler detektiert wird, wird die LdStOp in der zweiten Ausführungsstufe gehalten, bis der dazu gehörige oder ein nicht verwandter Abbruchzyklus die LdStOp aus dem Ablaufplaner 280 und der Ausführungseinheit 251 oder 252 entleert. Dies führt dazu, dass abgeschlossene LdStOps garantiert frei von Fehlern sind. Die OCU 260 unterscheidet zwischen einer als fehlerhaft behandelten LdStOp und einer LdStOp, die noch nicht abgeschlossen ist, durch Signale von den Ausführungseinheiten 251 und 252, die anzeigen, dass eine als fehlerhaft behandelte Operation in ihrer jeweiligen zweiten Ausführungsstufe stecken geblieben ist. Wenn die OCU 260 versucht, die nächste nicht abgeschlossene LdStOp zu übergeben und die dazu gehörige Ausführungseinheit 251 oder 252 einen Fehler für eine Operation signalisiert, die in der zweiten Ausführungsstufe fest gehalten wird, muss die Operation, welche die OCU 260 zu übergeben versucht, die Operation sein, die auf einen Fehler getroffen ist. Falls die dazu gehörige Ausführungseinheit 251 oder 252. nicht ein Fehlersignal anlegt, dann kann nichts Bestimmtes über eine nicht abgeschlossene LdStOp fest gestellt werden und die OCU 260 wartet auf die LdStOp, abzuschließen.
  • FAULT Operationen werden in den Ablaufplaner 280 in einem abgeschlossenen Zustand und immer fehlerhaft geladen. Die OCU 260 behandelt die Übergabe von FAULT Operationen und des sich daraus ergebenden Abbruchs von umgebenden Operationen auf die gleiche Weise wie bei LdStOps, die einen Fehler haben.
  • Zusätzlich zu Fehlern bei bestimmten Operationen erkennt die OCU 260 auch verschiedene Debugfallen-Ausnahmen, welche angesammelt und gemerkt werden bis zu dem Ende einer Emcode-Sequenz, wie von einem ERET angezeigt. Falls ein "ERET" Op Quad zurück gezogen wird und Fallen-Ausnahmen anhängig sind, leitet die OCU 260 einen Abbruchzyklus ein, als ob ein Fehler auf einer fünften und letzten Operation in dem Op Quade erkannt wurde.
  • Die OCU 260 erkennt eine "Grenzverletzung eines Verzweigungsziels" Bedingung, die, während zugehörig zu gerade gewissen Operationen in dem Op Quad, mit dem Op Quad als ganzes markiert wird. Dies zeigt bedin gungslos einen Abbruchzyklus an, als ob ein Fehler auf der ersten Operation in dem Op Quad erkannt wurde.
  • Während die OCU 260 primär befasst ist mit Operationen, die abbrechbare Änderungen des Zustands erzeugen, behandelt die OCU 260 auch BRCONDs. BRCONDs werden aufgelöst, wenn sie in der Zeile 4 sind. Falls eine Fehlvorhersage detektiert wird, werden die Logik zum Abrufen von Makrobefehlen und der Befehlsdekodierer 240 unmittelbar zurück gesetzt und von der richtigen Adresse des Makrobefehls an erneut gestartet. Wenn die falsch vorher gesagte BRCOND die Zeile 5 erreicht, wird die Übergabe von Operationen, die neuer sind als die falsch vorher gesagte BRCOND verhindert, und ein Abbruchzyklus wird eingeleitet, nachdem alle Operationen, die der falsch vorher gesagten BRCOND voran gehen, übergeben worden sind oder erfolgreich übergeben werden. Der Abbruchzyklus entleert den Ablaufplaner 280 und alle Ausführungseinheiten von allen Operationen. Der Abbruchzyklus gibt auch das Laden "neuer" Operationen von dem Dekodierer 240 in den Ablaufplaner 280 frei für die unmittelbare Ausgabe an die Ausführungseinheiten 251 bis 256. Falsch vorher gesagte BRCONDs und, Abbrüche wegen fehlerhafter Operationen unterscheiden sich darin, dass für falsch vorher gesagte BRCONDs kein Hinleitung zu Emcode eingeleitet wird. Keine Aktivität ist nötig, um eine korrekt vorher gesagte BRCOND zu übergeben, die den Boden des Ablaufplaners 280 erreicht.
  • Die OCU 260 übergibt entweder jede BRCOND oder bricht sie ab. Die OCU 260 wählt die Aktion aus auf der Basis des State Felds des Eintrags im Ablaufplaner von der BRCOND. Wenn eine BRCOND aufgelöst wird, wird ihr State Feld im Eintrag des Ablaufplaners entweder auf abgeschlossen geändert, falls korrekt vorher gesagt, oder wird nicht ausgegeben gelassen, falls falsch vorher gesagt. Daher zeigt, ob eine BRCOND in Zeile 4 abgeschlossen wird, direkt an, ob die BRCOND falsch vorher gesagt wurde.
  • Der tatsächliche Zeitablauf der Übergaben des Ergebnisses der Operation ist relativ einfach und kann angesehen werden als während des letzteren Teils des Übergabezyklus geschehend. Typischerweise wird ein Op Quad während des gleichen Zyklus übergeben, in dem er in den Boden des Ablaufplaners 280 fällt, und wird am Ende dieses Zyklus aus dem Ablaufplaner 280 zurück gezogen. Während dieses Zyklus, während Ergebnisse in die Registerdatei 290 geschrieben werden, werden Werte für Operanden weiterhin von dem Ablaufplaner 280, nicht von der Registerdatei 290, an alle abhängigen Operationen weiter geleitet.
  • Die Übergabe von Schreibvorgängen (das heißt die Übergabe von StOps) ist ein Prozess mit zwei Stufen implementiert in der Form einer Schreibübergabepipeline mit zwei Stufen. Die erste Stufe der Schreibübergabepipeline entspricht dem Übergabezyklus der OCU 260 für eine StOp und so weit wie die OCU 260 betroffen ist, ist die StOp übergeben worden, wenn sie die zweite Stufe dieser Pipeline betritt. Vom Zeitablauf her muss die StOp die zweite Schreibübergabestufe betreten vor dem oder neben einander mit dem Zurückziehen des dazu gehörigen Op Quads von dem Ablaufplaner 280. Falls eine StOp nicht die zweite Stufe betreten kann, wird die StOp als noch nicht übergebbar angesehen und das Zurückziehen des Op Quads wird aufgehalten.
  • Wenn die OCU 260 einen Abbruchzyklus einleitet aufgrund einer fehlerhaften Operation, werden ein Abbruchsignal und eine dazu gehörige Emcode Einsprungadresse während des Übergabe/Rückzug Zyklus des Op Quads angelegt, der die den Fehler verursachende Operation enthält. Während des nächsten Zyklus wird der Ablaufplaner 280 entleert worden sein und der Ziel Emcode Op Quad wird abgerufen. Für einen internen Emcode wird der Ablaufplaner 280 für exakt diesen einen Zyklus leer sein.
  • Das Abbruchsignal für eine falsch vorher gesagte BRCOND wird ebenso während des Übergabe/Rückzug Zyklus des dazu gehörigen Op Quads angelegt. Da das Abrufen und Dekodieren des Befehls zuvor erneut gestartet wurde, kann der Ablaufplaner 280 so früh erneut mit einem neuen Op Quad geladen werden wie der allernächste Zyklus, das heißt der Ablaufplaner 280 bleibt nicht einmal für einen Zyklus leer.
  • Wenn die OCU 260 mehrere Operationen in einem Op Quad als einen Abbruchzyklus erfordernd erkennt, wählt sie die erste derartige Operation aus und leitet entsprechende Abbruchaktionen im Hinblick auf diese Operation zu einem geeigneten Zeitpunkt für diese Operation ein.
  • VIII.A.1. Übergabe Register
  • Die OCU 260 behandelt und steuert die Übergabe von Ergebniswerten des Registers an die Registerdatei 290. Während jedes Zyklus kann das Registerergebnis von jeder abgeschlossenen Operation innerhalb einer der untersten zwei Zeilen des Ablaufplaners 280 in die Registerdatei 290 geschrieben werden (während des letzteren Teils des Zyklus, über vier unabhängige Schreibanschlüsse). Jeder Schreibvorgang wird den Bytemarkierungen, Feld DestBM[2:0] von dem dazu gehörigen Eintrag des Ablaufplaners, entsprechend durchgeführt. Dieser Prozess trifft für die x86 architekturalen Register und die temporären/mikro-architekturalen Register zu.
  • Falls eine Operation nicht abgeschlossen und übertragbar ist, wird der dazu gehörige Schreibvorgang in die Registerdatei für diesen Zyklus verhindert. Falls eine Operation von einem Typ ist, der begrifflich kein Registerergebnis erzeugt, dann werden die Bytemarkierungen alle gelöscht und die Registernummer ist möglicherweise nicht definiert. Dies führt dazu, dass während des Schreibvorgangs in die Registerdatei keine Bytes verändert werden. Auf ähnliche Weise wird ein Register t0 (ein Register, das immer Null ist) als Ziel für diese Operation angegeben. In beiden von diesen Fällen zwingt der Operationsdekodierer 210 die Bytemarkierungen während des Ladens zu b0000.
  • Im Allgemeinen besteht die Möglichkeit eines Konflikts, das heißt mehrere gleichzeitige Schreibvorgänge auf das gleiche Register. Das gewünschte Ergebnis ist von der neuesten Operation und die anderen, älteren Schreibvorgänge werden verhindert und tatsächlich ignoriert. Die Registerdatei 290 behandelt diese Funktion getrennt von der Steuerung der OCU 260 für den Prozess der Übergabe der Register, einfach basierend auf den präsentierten Registernummern und den dazu gehörigen Schreibfreigaben.
  • Des weiteren, wenn die im Konflikt stehenden Schreibvorgänge derart sind, dass die älteren Schreibvorgänge Bytes des Registers verändern, die nicht von dem neuesten Schreibvorgang verändert werden, dann ist der tatsächliche Schreibvorgang in die Registerdatei eine Kombination von Bytes der im Konflikt stehenden Operationen. Falls zum Beispiel eine erste (älteste) Operation die Bytes {3, 2, 1, 0} verändert, eine zweite Operation die Bytes {1, 0} verändert und eine dritte (neueste) Operation das Byte {1} verändert, dann nimmt der tatsächliche Schreibvorgang in die Registerdatei die Bytes {3, 2} der ersten Operation, das Byte {0} von der zweiten Operation und das Byte {1} von der dritten Operation. In anderen Fällen werden einige Bytes der Registerdatei überhaupt nicht verändert. Die Steuerlogik in der Registerdatei 290 behandelt diese weitere Funktionalität. Kurz gesagt arbeitet die Konfliktauslösungslogik innerhalb der Registerdatei 290 auf der Basis von einzelnen Bytes statt von 32-Bit Worten.
  • Die Schreibfreigaben für alle vier Operationen werden parallel erzeugt. Eine dazu gehörige Schreibfreigabe wird für jede abgeschlossene Operation an die Registerdatei 290 angelegt, falls alle vorher gehenden/älteren LdStOps innerhalb des Op Quads abgeschlossen sind und keine vorher gehende/ältere BRCOND falsch vorher gesagt ist. Wenn Ergebnisse einer Operation in die Registerdatei 290 geschrieben werden, werden die dazu gehörigen DestBM Bits gelöscht, um anzuzeigen, dass der Eintrag in dem Ablaufplaner nicht länger einen Registerwert an abhängige Operationen zur Verfügung stellt. Das Löschen des DestBM Felds wird auch für partielle Schreibvorgänge in Registern durchgeführt. Falls eine abhängige Operation nicht alle erforderlichen Bytes von einer Operation erhalten kann, wird die abhängige Operation in der Stufe Operandenweiterleitung aufgehalten, bis sie alle der Bytes aus der Registerdatei 290 erhalten kann.
  • Des weiteren werden neun Signale OprndMatch_XXsrcY, die zu einem Eintrag des Ablaufplaners gehören (siehe obige Beschreibung), maskiert (das heißt gezwungen, keine Übereinstimmung anzuzeigen), wenn die DestBM Bits in diesem Eintrag dabei sind, gelöscht zu werden. Dies ist wegen der Ausgestaltung in Form einer Pipeline des Prozesses zum Abrufen der Registeroperanden in dem Ablaufplaner 280. Insbesondere werden die DestBM Bits eines Eintrags in beiden Stufen von diesem Prozess verwendet und müssen konsistent über beide Zyklen sein.
  • Um den Durchsatz von Registerübergaben zu erhöhen, können die Schreibvorgänge in Operationsregister von Zeile 4 an, wenn die Registerübergabe für alle Operationen in der Zeile 5 abgeschlossen worden ist, statt finden. Dies wird erreicht durch eine Verallgemeinerung der RegOp Schreibfreigabelogik, um entweder die vier Operationen in der Zeile 5 oder die vier Operationen in Zeile 4 zu berücksichtigen. Die Operationen der ausgewählten Zeile werden umbenannt in "OpA" bis "OpD" anstelle von Op23 bis Op20 oder Op19 bis Op16. Die Tabelle B.53 beschreibt eine Logik, die Ergebnisse zur Übergabe an die Registerdatei 290 auswählt.
  • VIII.A.2. Übergabe Status Flags
  • Die OCU 260 behandelt und steuert auch die Übergabe an die architekturalen EFlags Register der von den ".cc" RegOps erzeugten Status Flag Ergebnisse. Anders als bei der Übergabe von Registerergebnissen werden keine der (bis zu vier) Status Flag Ergebnisse von Operationen aus der Zeile 5 in die EFlags geschrieben bis der Op Quad in der Zeile 5 dabei ist, entweder zurück gezogen oder abgebrochen zu werden. In dem normalen Fall, wenn alle Operationen in dem Op Quad vollständig übergeben worden sind oder erfolgreich übergeben werden, wird das gesammelte oder gesamte Ergebnis von allen vier Statusergebnissen am Ende des Zyklus in die EFlags geschrieben, wenn der Op Quad aus dem Ablaufplaner 280 zurück gezogen wird. Für ein Op Quad, der einen fehlerhaften Befehl oder eine BRCOND enthält, werden nur die Statusergebnisse von den Operationen vor dem fehlerhaften Befehl oder der BRCOND übergeben und das gesammelte Ergebnis wird während oder an dem Ende des Abbruchzyklus geschrieben.
  • Dieser Prozess betrifft die mikro-architekturalen Status Flags (EZF und ECF) ebenso wie die x86 architekturalen Status Flags. Kurz gesagt wird das architekturale EFlags Register auf 34 Bit erweitert, um den beiden zusätzlichen Status Flags Platz zu schaffen. Die RDFLG und WRFLG RegOps beziehen sich nur auf den Standard 32 Bit Bereich von diesem erweiterten EFlags Register.
  • Die Erzeugung des gesammelten Statusergebnisses basiert auf den Statusbitmarkierungen (StatMod[3:0]) von jedem der vier Einträge in der untersten Zeile. Die acht Status Flags werden zu Zwecken der Markierung von Veränderungen in vier Gruppen unterteilt statt acht einzelne Bitmarkierungen zu haben. Wie mit den Aktualisierungen für ein allgemeines Register in der Registerdatei besteht die Möglichkeit einer Kollision, das heißt von mehreren Veränderungen an die gleiche Gruppe von Status Flags. Das gewünschte Ergebnis ist die neueste Änderungswert für jede Gruppe von Status Flags.
  • Die Erzeugung des gesammelten Statusergebnisses basiert auch auf dem abgeschlossenen Status (State[3]) von jeder der vier Operationen. Für einen Op Quad, der abgebrochen wird, identifiziert das State Feld, welche Statusergebnisse übergeben werden sollten und welche nicht übergeben werden sollten. Für die Übergabe müssen alle vorher gehenden Operationen abgeschlossen sein und damit frei von Fehlern und falschen Vorhersagen. Die Tabelle B.54 fasst eine Logik zusammen, welche die Änderungen der Status Flags sammelt.
  • Keine explizite Steuerung oder Beschränkung der Übergabe und der Zurückziehung einer Operation wird so weit benötigt, wie die Ergebnisse von Status Flags betroffen sind. Da Status Flags nur Ergebnisse von RegOps ändern und da alle RegOps Veränderungen des Registerzustands erzeugen (sogar falls nur zu t0), kann ein Op Quad nicht zurück gezogen werden bis alle RegOps innerhalb des Op Quads abgeschlossen sind und damit gültige Statusergebniswerte haben. Es besteht also kein Bedarf, gegeben wie die Werte der Status Flags weiter geleitet werden (an BRCONDs und "cc- abhängige" RegOps), für jegliches Löschen von StatMod Feldern für die Operationen in der untersten Zeile.
  • VIII.A.3. Übergabe Speicherschreibvorgänge
  • Eine dritte Funktion der OCU 260 ist die Steuerung der Übergabe von Datenwerten von Speicherschreibvorgängen an den "Speicher" (den Daten-Cachespeicher und/oder Hauptspeicher). Dies unterscheidet sich von der Übergabe von Register- und Statusergebnissen in einer Anzahl von Wegen: die Übergabe von Speicherschreibvorgängen umfasst einen dazu gehörigen Eintrag in der Speicherwarteschlange (in den meisten Fällen); maximal ein Speicherschreibvorgang kann pro Zyklus übergeben werden; der Prozess der Übergabe hat eine Übergabepipeline mit zwei Stufen. Die OCU 260 tastet die untersten beiden Zeilen ab, um StOps für Speicherschreibvorgänge zum Übergeben zu finden. Die Möglichkeit von Fehlern bei den dazu gehörigen StOps existiert.
  • Die Speicherschreibvorgänge gehören alle zu StOps (außer für LEA, CIA und CDA Operationen, welche sich nicht tatsächlich auf Speicher beziehen). Wenn eine StOp die Ausführung abschließt, werden die dazu gehörige Speicheradresse und die Speicherdaten in die Speicherwarteschlange 270 eingebracht. Später, wenn der Speicherschreibvorgang von einer StOp übergeben wird, wird dieser Eintrag aus dem Cachespeicher ausgelesen und von der Speicherwarteschlange 270 zurück gezogen. StOps werden ausgeführt und übergeben in einer Reihenfolge bezüglich zueinander, die es der Speicherwarteschlange 270 erlaubt, wie ein einfacher FIFO zu arbeiten, und Übereinstimmung von Einträgen der Speicherwarteschlange mit dazu gehörigen StOps des Ablaufplaners ist automatisch.
  • Der tatsächliche Prozess der Übergabe aber ist komplizierter und unten beschrieben. Im Allgemeinen ist ein Prozess mit zwei Stufen erforderlich, in denen der letzte/älteste Eintrag in der Speicherwarteschlange zuerst gelesen und die Adresse in dem Daten-Cachespeicher 220 nachgeschlagen wird; dann, basierend auf dem Status des Nachschlagens, werden die Speicher daten in den Daten-Cachespeicher 220 und/oder raus zu dem Speicher geschrieben. In dem letzteren Fall werden die Daten und die Adresse typischerweise einfach in den Schreibpuffer geladen und später in den Speicher ausgeschrieben.
  • In der Schreibübergabepipeline mit zwei Stufen entspricht die erste Stufe (das heißt das Daten-Cachespeicher Markierungsnachschlagen) dem Übergabezyklus von Register- und Statusergebnissen, das heißt der enthaltene Op Quad könnte am Ende des Zyklus von dieser Stufe zurück gezogen werden. Aus Sicht der OCU 260 wird der Prozess der Übergabe im wesentlichen als eine Einzelzyklus/Einzelstufe Aktion betrachtet, die entweder erfolgreich ist oder verzögert wird. Die Übergabe eines Speicherschreibvorgangs kann aus ähnlichen Gründen wie für eine Zustandsänderung eines Registers aufgehalten werden, und auch aufgehalten werden, falls die Übergabe des Speicherschreibvorgangs nicht in die Stufe 2 der Übergabepipeline eintreten kann. Wenn ein Speicherschreibvorgang in die Übergabestufe 2 eintritt, kann die dazu gehörige StOp aus dem Ablaufplaner 280 zurück gezogen werden und der Rest des Übergabeprozesses ist asynchron zu der OCU 260 und dem Ablaufplaner 280.
  • Während der ersten Übergabestufe werden keine Steuerentscheidungen gemacht. Das Nachschlagen der Markierung des Daten-Cachespeichers wird ausgeführt und die Markierungsdaten, auf die zugegriffen wird, werden für eine Untersuchung in der zweiten Übergabestufe einfach verriegelt.
  • Die Schreibübergabepipeline ist nur eine einzelne Pipeline und unterstützt daher nur die Übergabe von einem Speicherschreibvorgang pro Zyklus. Für Op Quads, die maximal eine in den Speicher schreibende StOp enthalten, erlaubt dies die mögliche Übergabe und Zurückziehung von einem Op Quad jeden Zyklus (der gleichen Art von Einsprüchen unterworfen, wie sie von der Übergabe von Zustandsänderungen der Register stammen). Für Op Quads, die zwei, drei oder vier StOps enthalten, ist eine entsprechende minimale Anzahl von Zyklen erforderlich, um den Op Quad zu übergeben, was den Op Quad veranlasst, für mindestens so viele Zyklen an dem Boden des Ablaufplaner 280 zu bleiben. Die Übergabe eines Speicherschreibvorgangs, der zu einer StOp in der Zeile 4 oder 5 gehört, verringert die Aufhaltungen, die von mehreren StOps in einem Op Quad verursacht werden. Unter der Annahme, dass Speicherschreibvorgänge in Reihenfolge übergeben werden, kann die OCU 260 einen "Vorsprung" auf Op Quads mit mehreren Schreibvorgängen bekommen, wenn der Boden Op Quad aufgehalten wird, aber ansonsten leer ist von nicht übergebenen Speicherschreibvorgängen oder der Boden Op Quad einfach keine StOps enthält. Dies hilft, die Fähigkeit der OCU 260, einen Schreibvorgang pro Zyklus zu übergeben, besser an die durchschnittliche Anzahl der Schreibvorgänge pro Op Quad anzupassen, die weniger als eins pro Op Quad ist.
  • Während jedes Zyklus sucht die Speicherschreibvorgang-Übergabelogik der OCU in den untersten beiden Zeilen nach der ältesten, nicht übergebenen, in den Speicher schreibenden StOp (das heißt nach der nächsten StOp und einem dazu gehörigen Schreibvorgang, um eine Übergabe zu versuchen). Die ausgewählte Operation erzeugte den derzeitigen Boden/ältesten Eintrag in der Speicherwarteschlange. Nebenher zu der Auswahl der Operation wird die Adresse des ältesten Eintrags in der Speicherwarteschlange dem Daten-Cachespeicher präsentiert und ein Nachschlagen der Markierung eingeleitet. Es ist zu bemerken, dass dies "blind" gemacht wird, das heißt ohne Betrachtungen, ob die dazu gehörige StOp tatsächlich derzeit übergeben werden kann.
  • Falls die ausgewählte StOp übergeben werden kann und die Übergabe des Schreibvorgangs fähig ist, in die zweite Stufe der Übergabe des Schreibvorgangs vor zu rücken, betrachtet die OCU 260 die StOp als übergeben. In dem nächsten Zyklus sucht die OCU 260 nach der nächsten in den Speicher schreibenden StOp. Die Kriterien für eine Übergabe einer StOp sind die gleichen wie für die Übergabe eines Registerergebnisses: die ausgewählte StOp muss abgeschlossen sein, alle vorher gehenden/älteren LdStOps in dem Op Quad (und möglicherweise dem vorher gehenden Op Quad, falls diese StOp in der letzten Zeile ist) müssen ebenso abgeschlossen sein und es darf keine vorher gehende/ältere falsch vorher gesagte BRCOND da sein. Eine Schreibübergabe ist fähig, in die Übergabestufe 2 vorzurücken, wenn diese Stufe entweder leer ist oder die Übergabe eines Schreibvorgangs erfolgreich beendet ist.
  • Falls die ausgewählte StOp nicht übergeben werden kann, nur weil sie nicht abgeschlossen ist, untersucht die OCU 260 das Signal von der zweiten SU Ausführungsstufe, das anzeigt, ob eine StOp in dieser Stufe mit einer detektierten Fehlerbedingung "stecken" geblieben ist. Wenn dort irgendeine dieser Operationen ist, ist es die gleiche StOp, welche die OCU 260 (nicht erfolgreich) zu Übertragen versucht, und muss daher von der OCU 260 abgebrochen werden. Ein geeigneter Abbruchzyklus wird nicht eingeleitet, bis die StOp in der Bodenzeile ist, alle vorher gehenden Operationen in dem Op Quad übergeben worden sind und keine vorher gehende BRCOND falsch vorher gesagt wurde. Dies ist im wesentlichen eine Erweiterung der Bedingung für eine StOp, übergebbar zu sein. In der Zwischenzeit verbleibt die OCU 260 in diesem Zustand, bis ein Abbruchzyklus für eine vorher gehende Operation eingeleitet ist.
  • Die OCU 260 ist hauptsächlich mit in den Speicher schreibenden Stops befasst, aber behandelt auch CIA und CDA Operationen, weil diese Operationen fehlerhafte Speicheradressen erzeugen, welche die OCU 260 untersuchen und übergeben muss. In dem normalen Fall der Fehler freien Ausführung von solch einer Operation verwendet die OCU 260 ganz unbedeutend einen Zyklus für die Übergabe der Operation und geht einfach weiter zu der Übergabe der nächsten StOp in dem nächsten Zyklus. Da während der Ausführung der Operation keine Einträge in der Speicherwarteschlange geschaffen wurden, wird kein Eintrag aus der Speicherwarteschlange zurück gezogen. Falls ein Fehler während der Ausführung der CIA oder CDA Operation detektiert wurde, "steckt" die Operation in der zweiten SU Ausführungsstufe, und die OCU 260 bricht auf genau die gleiche Weise wie für die anderen StOps ab.
  • Eine zweite spezielle Situation für die OCU 260 tritt auf, wenn eine Speicherreferenz einer StOp eine Ausrichtungsgrenze (derzeit 8 Bytes) über schreitet und von der Speichereinheit 252 in zwei Speicherschreibvorgänge mit zwei dazu gehörigen Einträgen in der Speicherwarteschlange aufgeteilt wird. In derartigen Fällen braucht die OCU 260 zwei Zyklen, um die zwei Einträge in der Speicherwarteschlange zurück zu ziehen, und übergibt die StOp offiziell nicht bis zu dem zweiten Zyklus. Falls die StOp einen Fehler hat, wird sie ohne ein Zurückziehen von jeglichen Einträgen in der Speicherwarteschlange abgebrochen.
  • Das beispielhafte Ausführungsbeispiel der OCU 260 verwendet einen Satz von Maskierungsbits (CmtMask[7:0]), die den Fortschritt der OCU bei der Übergabe von in den Speicher schreibenden StOps innerhalb der letzten beiden Zeilen repräsentieren. Jedes der acht Maskierungsbits CmtMask[7:0] entspricht den acht Einträgen in den letzten beiden Zeilen. Ein erster Satz von Bits (anfangend von Bit 0) ist gelöscht, um anzuzeigen, dass die OCU 260 die entsprechenden Einträge durchsucht hat und jegliche StOps Befehlsinformation zu dem Eintrag, der dem letzten gelöschten Bit entspricht, übergeben hat. Der Eintrag, der dem letzten gelöschten Bit entspricht, enthält die nächste zu übergebende StOp. Die Einträge, die den gesetzten Maskierungsbits entsprechen, müssen noch nach StOps durchsucht werden, die übergeben werden können. Die OCU 260 unterhält auch einen Satz von Bits (UncmtStOp[7:0]) anzeigend, welche Einträge in den letzten beiden Zeilen nicht übergebene, in den Speicher schreibende StOps enthalten.
  • Während jedes Takts wählt die OCU 260 die nächste nicht übergebene StOp aus und erzeugt einen neuen Satz von Maskierungsbits auf der Basis des Eintrags, der diese StOp enthält. Die nicht maskierten Einträge werden untersucht, um festzustellen, ob die ausgewählte StOp zur Zeit übergeben werden kann oder ein Abbruchzyklus eingeleitet werden muss. Falls die ausgewählte StOp übergeben werden kann und falls die Stufe 2 der Übergabepipeline bereit ist, an dem Ende des Zyklus eine neue Übergabe eines Schreibvorgangs zu akzeptieren, wird die StOp übergeben und die UncmtStOp Bits werden mit neuen Werten aktualisiert. Die UncmtStOp Bits werden ebenso aktualisiert/geschoben, um einem Schieben der letzten bei den Reihen zu entsprechen. Die Tabelle B.55 in dem Anhang B beschreibt diese Logik.
  • VIII.B. Zurückziehung Op Quads
  • Wenn alle abbrechbaren Zustandsänderungen der Operationen in der untersten Zeile des Ablaufplaners 280 übergeben worden sind oder erfolgreich übergeben werden, zieht die OCU 260 den Op Quad aus dem Ablaufplaner 280 an dem Ende des Zyklus zurück. Dies erlaubt es dem nächsten Op Quad, in die unterste Zeile des Ablaufplaners 280 zu schieben. Während Zyklen, in denen nicht alle derartigen Operationsergebnisse übergeben worden sind, wird der Op Quad nicht zurück gezogen und wird entweder zurückbehalten für weitere Bearbeitung der Übergabe oder aufgrund eines Abbruchzyklus ungültig gemacht. Falls ungültig gemacht, würde der Abbruchzyklus in Reaktion auf irgendeinen Fehler sein, der bei einer der Operationen in der Zeile 5 erkannt worden ist.
  • Insbesondere erfordert das Zurückziehen eines Op Quads, dass alle Registerergebnisse, Statusergebnisse und Speicherschreibvorgänge übergeben werden, und dass sich keine FAULT Operation oder falsch vorher gesagte BRCOND in dem Op Quad befindet. Das Zurückziehen eines Op Quads geschieht auch unmittelbar, falls der Op Quad als ungültig markiert ist. Die Schiebesteuerlogik des Ablaufplaners kümmert sich automatisch darum. Die Statusergebnisse werden alle zusammen in Verbindung mit dem Zurückziehen (oder Abbruch) des Op Quads übergeben. Die Tabelle B.56 fasst eine Schaltung in der OCU 260 für das Zurückziehen von Op Quads zusammen.
  • VIII.C. Fehlerbehandlung
  • VIII.C.1. Fehlerbehandlung Ladeoperationen
  • LdOps erfordern normalerweise keine spezielle Behandlung durch die OCU 260, da LdOps nur zu generellen Zustandsänderungen der Register führen. Wie die meisten StOps können jedoch auch LdOps während der Ausführung auf Fehler treffen. Eine spezielle Logik in der OCU 260 erkennt und behan delt LdOp Fehler auf die gleiche Weise wie StOp Fehler. Um zu bestimmen, ob eine fehlerhafte LdOp in der untersten Zeile des Ablaufplaners 280 existiert, durchsucht die OCU 260 die Zeile 5 nach einer Operation, die eine LdOp ist mit allen vorher gehenden/älteren Operationen abgeschlossen und übergeben und keiner vorher gehenden falsch vorher gesagten BRCOND. Die OCU 260 untersucht auch ein Signal von der Ladeeinheit 251, das anzeigt, ob eine LdOp mit einer detektierten Fehlerbedingung in der zweiten Ausführungsstufe der LU Pipeline "stecken" geblieben ist.
  • Falls eine LdOp in der Zeile 5 nicht vollständig ist und nur abgeschlossene und übergebene Operationen vorausgehen und das Signal von der LU Stufe 2 angelegt ist, erkennt die OCU 260 eine fehlerhafte LdOp und leitet einen geeigneten Abbruchzyklus unmittelbar ein, um die LdOp und alle folgenden Operationen abzubrechen. Die Tabelle B.57 fasst die LdOp Fehlerbehandlungslogik der OCU zusammen.
  • VIII.C.2. Behandlung FAULT und LDDHA/LDAHA Operation
  • Einige wenige Spezialoperationen, FAULT, LDDHA und LDAHA Operationen erfordern eine zusätzliche, spezielle Behandlung der Übergabe. Keine dieser Operationen werden an eine Ausführungseinheit ausgegeben oder von ihr ausgeführt. Die FAULT, LDDHA und LDAHA Operationen haben keine Abhängigkeiten mit anderen Operationen bei der Ausführung und sind nur für die OCU 260 von Bedeutung.
  • Die OCU 260 behandelt die FAULT Operation ziemlich gleich wie eine fehlerhafte LdStOp. Ein Abbruchzyklus wird zusammen mit dem Einspringen an den derzeitigen Emcode OCU Fehlerbehandler eingeleitet. Anders als bei fehlerhaften LdStOps ist hier keine Ausgabe, ob da ein Fehler zu erkennen ist und wenn der Abbruchzyklus einzuleiten ist. Um die Logik der OCU zur Behandlung von FAULT Operationen zu vereinfachen, werden den Dekodierern 410 und 510 die folgenden Beschränkungen auferlegt: 1) FAULT Operationen müssen in der ersten Operationsposition in einem Op Quad sein, 2) alle folgenden Operationen in dem Op Quad müssen "No-Ops" sein (zum Beispiel LDK t0,xx) und 3) der folgende Op Quad darf keine in den Speicher schreibenden StOps enthalten. Die Verhinderung von in den Speicher schreibenden StOps in dem nächsten Op Quad stellt sicher, dass alle weitere Übergabelogik der OCU bei "FAULT" Op Quads ohne weitere besondere Betrachtungen blind operieren kann.
  • Der Zustand von einer FAULT Operation wird auf 'b0000 initialisiert, wenn sie in den Ablaufplaner 280 geladen wird. Wenn die FAULT Operation die Zeile 5 erreicht, verhindert das nicht abgeschlossene State Feld der Fault Operation, dass die Op Quad Zurückziehungslogik der OCU den Op Quad zurück zieht, und die FAULT Operation Übergabelogik in der OCU 260 leitet unmittelbar einen Abbruchzyklus ein. Die Bestimmungen des Abbruchzyklus sind die gleichen wie für Fehler bei LdStOps. Der einzige Unterschied ist die Erzeugung einer einzigartigen Fehler ID. Die Tabelle B.58 beschreibt eine Logik, die in Abbruchsignal für eine FAULT Operation erzeugt.
  • Die LDDHA/LDAHA Operationen ermöglichen ein Setzen von Emcode und ändern die Adresse in dem Emcode ROM 246, zu dem die von der OCU erkannten Ausnahmen hingeleitet werden. Die OCU 260 unterhält zwei Einsprungadressregister, eines zum Halten der "Vorgabe" Behandlungsadresse und ein anderes zum Halten einer "alternativen" Behandlungsadresse. Das Einsprungadressregister ist in der Vorgabe für die meisten Emcodes (sowohl Makrobefehle als auch Ausnahmen verarbeitender Emcode) aktiv und wird gerade einmal durch den Rücksetz Emcode über eine LDDHA Operation gesetzt. (Der Prozessor 200 führt den Rücksetz Emcode zur Initialisierung nach einem Rücksetzen durch). Das zweite Einsprungadressregister wird über eine LDAHA Operation gesetzt.
  • Für Emcode Sequenzen von dem Einsprungdekodierer 244 (definiert als von einem Eintrittspunkt bis zu einem ERET zu sein), welche keine LDAHA Operation enthalten, führen jegliche Fehler, die von der OCU 260 bei Operationen in der Sequenz erkannt wurden, zu einem Einspringen an die Vorgabeadresse; aber Fehler bei Operationen in dem Op Quad, der die LDAHA Operation enthält, oder in jedem folgenden Op Quad bis zu und einschließlich dem letzten Quad der Emcode Sequenz, führen zu einem Einspringen an die Adresse in dem zweiten Einsprungadressregister. Das Zurückziehen des "E-RET" Op Quads aktiviert tatsächlich das Vorgabe Behandlungsadressregister erneut für alle folgenden Operationen bis zum nächsten Auftreten von einer LDAHA Operation. Das Auftreten eines Abbruchzyklus aktiviert auch das Vorgabe Behandlungsadressregister erneut.
  • Um die Sache für die OCU 260 zu vereinfachen, werden LDDHA/LDAHA Operationen gezwungen, in der ältesten Operationsposition von einem Op Quad angeordnet zu sein. "Gültige" Operationen sind in den folgenden Operationspositionen von dem Op Quad erlaubt. Die Tabelle B.59 fasst die LDDHA/LDAHA Operationsbehandlungslogik der OCU zusammen.
  • VIII.C.3. Behandlung Grenzverletzung des Ziels
  • Zusätzlich zu der Übergabe von Änderungen des Zustand, die zu jeder Operation in einem Op Quad gehören, erkennt die OCU 260 auch eine spezielle Bedingung, die für einen Op Quad als ganzes markiert wird. Immer wenn der MacDec 260 einen Transfersteuerbefehl dekodiert und eine Grenzverletzung eines Codesegments bei der Zieladresse detektiert wird (nachdem der MacDec einen Op Quad erzeugt hat und der Op Quad in den Ablaufplaner 280 geladen worden ist), wird der Op Quad markiert, um anzuzeigen, dass eine derartige Verletzung in Zusammenhang mit dem Op Quad detektiert wurde.
  • Wenn der Op Quad die OCU 260 erreicht und übergeben werden soll, wird das gesetzte Markierungsbit erkannt und ein Abbruchzyklus wird eingeleitet ohne eine Übergabe von jeglichen Änderungen des Zustands der Operationen in dem Op Quad. Tatsächlich wird der ganze Op Quad als fehlerhaft behandelt. Die Auswirkung ist ähnlich als ob eine FAULT Operation in dem Op Quad wäre. Die Tabelle B.60 beschreibt eine Logik zur Behandlung der Grenzverletzungen eines Verzweigungsziels.
  • VIII.C.4. Behandlung falsch vorher gesagter Verzweigungen
  • Neben der Übergabe von abbrechbaren Änderungen des Zustands und der Behandlung von verschiedenen speziellen Fällen, behandelt die OCU 260 die Erzeugung von Abbruchzyklen für falsch vorher gesagte BRCONDs. Wie zuvor erwähnt, geschieht das erneute Starten des Abrufens der Befehle und der Dekodierungsbereiche, bevor die BRCOND den Boden des Ablaufplaners 280 erreicht. Der Ablaufplaner 280 erzeugt nachfolgend einen Abbruch und stellt sicher, dass nur vorher gehende Operationen übergeben werden. Wie bei der Erzeugung von Abbruchzyklen für Operationsfehler wird der Abbruch nicht eingeleitet, bis alle vorher gehenden Operationen übergeben worden sind. Die Tabelle B.61 fasst eine Logik zusammen, die einen Abbruch für eine falsch vorher gesagte Verzweigung erzeugt.
  • VIII.D. Erzeugung Abbruchzyklus
  • Die OCU 260 erzeugt Abbruchzyklen in zwei Situationen: die Erkennung eines Op Fehlers (bei einer LdStOp oder einer FAULT Operation) und die Erkennung einer falsch vorher gesagten BRCOND. Die vorangegangenen Bereiche und Tabellen B.55, B.57, B.58 und B.61 decken die Erzeugung von Signalen ab, die einen Abbruchzyklus einleiten (das heißt Signale StAbort, LdAbort, FltAbort, LimAbort und BrAbort). Dieser Bereich beschreibt die Erzeugung des allgemeinen Abbruchsignals und verwandter Informationen.
  • Das Abbruchsignal ist eine Kombination von allen einzelnen Abbruchsignalen, die zu der Übergabe von bestimmten Typen von Änderungen des Zustands oder von Operationen gehören. Die dazu gehörige Emcode Einsprungadresse, welche nur definiert ist für mit Fehlern verwandte Abbrüche und nicht für mit BRCONDs verwandten Abbrüchen, ist wie oben beschrieben die FltVecAddr. Das Abbruchsignal entleert den Ablaufplaner 280 und alle Ausführungseinheiten 251 bis 257 von allen ausstehenden Operationen und initialisiert diese Bereiche erneut in Vorbereitung auf den Empfang neuer Operationen von dem Befehlsdekodierer 240. Für mit BRCONDs verwandte Abbrüche ist dies ausreichend, weil die Verzweigungsbewertungseinheit 257 das Abrufen von Emcode und x86 Makrobefehlen und den Befehlsdekodierer 240 zuvor erneut gestartet hat.
  • Für mit Fehlern verwandte Abbrüche muss auch der Befehlsdekodierer 240 an der Fehlerbehandlungsadresse neu gestartet werden. Wenn die erneuten Starts der Befehlsabrufung/Dekodierung gleichzeitig für sowohl eine falsch vorher gesagte BRCOND als auch eine Operationsausnahme signalisiert werden, wird der Operationsausnahme eine höhere Priorität gegeben. Die Einsprungadresse für den Neustart und die Erzeugung des geeigneten Neustartsignals werden entsprechend erzeugt. Wenn ein mit einem Fehler verwandter Abbruch auftritt, verriegelt die OCU 260 auch Information über den Fehler, nämlich den x86 Makrobefehlsprogrammzähler (die logische Adresse des dazu gehörigen x86 Befehls, der tatsächlich von dem Fehler betroffen ist), in ein Register SR4. Die Tabelle B.62 fasst die Logik der OCU zur Erzeugung des Abbruchzyklus zusammen.
  • IX. Verarbeitungssysteme
  • Ausführungsbeispiele der Erfindung umfassen eine breite Vielzahl von Verarbeitungssystemen, beispielhaft umfassend allein stehende und im Netzwerk integrierte Personal Computer Systeme, Workstation Systeme, Multimedia Systeme, Netzwerkserver Systeme, Multiprozessor Systeme, eingebettete Systeme, integrierte Telephonie Systeme und Videokonferenz Systeme. Die 11A bis 11C stellen einen beispielhaften Satz von Verarbeitungssystemen dar, die einen superskalaren Prozessor 200 in Übereinstimung mit der Erfindung mit geeigneten Buskonfigurationen, Speicherhierarchien und Cachespeicherkonfigurationen, I/O Schnittstellen, Steuerungen, Geräten und peripheren Komponenten kombinieren. Der Satz von in den 11A bis 11C dargestellten Verarbeitungssystemen ist lediglich beispielhaft. Geeignete Konfigurationen für ein System, das einen superskalaren Prozessor 200 integriert, umfassen Kombinationen von Komponenten, Karten, Schnittstellen und Geräten, wie:
    • 1. Videoanzeigegeräte, Monitore, Flachbildschirme und Touch-Bildschirme;
    • 2. Zeigegeräte und Tastature;
    • 3. Koprozessoren, Gleitkommaprozessoren, Grafikprozessoren, I/O Steuerungen und UARTs;
    • 4. sekundäre und tertiäre Speichergeräte, Steuerungen und Schnittstellen, Cachespeicher, RAM, ROM, Flash-Speicher, statisches RAM, dynamisches RAM
    • 5. CD-ROMs, feste Platten, entfernbare Medienspeichergeräte, Disketten, WORMs, IDE Steuerungen, enhanced-IDE Steuerungen, SCSI Geräten, Scanner, Jukeboxen;
    • 6. PCMCIA Schnittstellen und Geräte, ISA Busse und Geräte, EISA Busse und Geräte, PCI lokal Busse und Geräte, VESA lokal Busse und Geräte, Micro Channel Architektur Busse und Geräte;
    • 7. Netzwerkschnittstellen, -adapter und -karten wie für Ethernet, Token Ring, 10Base-T, verdrillte Paare, nicht verdrillte Paare, ATM Netzwerke, Seitenverzögerung, IDSN, usw.;
    • 8. Videokarten und Geräte, 2D und 3D Grafikkarten, Seitenpuffer, MPEG/JPEG Kompression/Dekompression Logik und Geräte, Karten und Geräte für Videokonferenzen und Videokameras und Seitenaufnahmegeräte;
    • 9. Computerintegrierte Telephoniekarten und -geräte, Modemkarten und -geräte, Faxkarten und -geräte;
    • 10. Soundkarten und -geräte; Audio und Videoeingabesysteme, Mikrophone und Lautsprecher;
    • 11. Datengewinnungs- und Steuerkarten und -schnittstellen, Kompressions/Dekompressionslogik und -geräte, Verschlüsselungs/Entschlüsselungslogik und -geräte; und
    • 12. Bandsicherungseinheiten, redundante/fehlertolerante Komponenten und Geräte so wie RAID und ECC Speicher.
  • Geeignete Kombinationen von derartigen Komponenten, Karten, Schnittstellen und Geräten (einschließlich der oben aufgezählten als auch vergleichba rer Komponenten, Karten, Schnittstellen und Geräten) sind zu zahlreich, um aufgelistet zu werden.
  • Ein im Netzwerk befindlicher Personal Computer 100 enthält einen superskalaren Prozessor 200 wie in 11A gezeigt. Der superskalare Prozessor 200 ist mit einem Speichersubsystem 120 verbunden. Das Speichersubsystem 120 ist als RAM gezeigt, obwohl andere Ausführungsbeispiele einen Cachespeicher oder mehrere Cachespeicher umfassen, die zwischen dem RAM und dem superskalaren Prozessor 200 zwischengeschaltet sind. Der superskalare Prozessor 200 und das Speichersubsystem 120 sind als Teil eines Motherboards des Computers 100 enthalten. Eine Reihe von Adaptern, Schnittstellen und Steuerungen verbindet den Prozessor 200 mit Geräten und peripheren Komponenten. Diese Adapter, Schnittstellen und Steuerungen sind üblicherweise als Karten in einem Platinenleitungsbus des Motherboards 101 mit dem Prozessor 200 verbunden. Jedoch können alternative Ausführungsbeispiele einzelne Adapter, Schnittstellen und Steuerungen in das Motherboard 101 integrieren. Ein Grafikadapter 110 ist mit dem superskalaren Prozessor 200 verbunden und treibt Signale, um die Anzeige 111 zu steuern, in Übereinstimmung mit von dem superskalaren Prozessor 200 zur Verfügung gestellten Aktualisierungen des Schirms. Eine parallele Schnittstelle 109 und eine serielle Schnittstelle 108 stellen signalisierende Schnittstellen in Form eines parallelen Anschlusses und eines seriellen Anschlusses zur Verfügung, um auf Geräte mit parallelem Anschluss (zum Beispiel Drucker, wie der parallele Drucker 102, Bandsicherungseinheiten, usw.) beziehungsweise Geräte mit seriellem Anschluss (zum Beispiel Modem 103, Zeigegeräte und Drucker) umzusetzen. Eine Festplatte/Diskette Steuerung 130 steuert den Zugriff auf eine Festplatte 132 und eine Diskette 131. Ein LAN Adapter 107 rüstet den Computer 100 mit einer Netzwerkschnittstelle zu Lokalbereichsnetzwerken aus, wie einem 802.3 Ethernet, 10Base-T, verdrillte Paare und Token Ring Netzwerken. Wie bei den anderen Adaptern und Schnittstellen, ist der LAN Adapter 107 üblicherweise als eine Karte in dem Platinenleitungsbus des Motherboards 101 mit dem Prozessor 200 verbunden.
  • Der superskalare Prozessor 200 ist insbesondere attraktiv als der Prozessor, oder einer von mehreren Prozessoren, in einer Netzwerkserverkonfiguration, wie in 11B gezeigt; wo mehrere Instanzen des superskalaren Prozessors 200 an einen Level 2 Cachespeicher 125 und an einen Prozessorbus 123 angeschlossen gezeigt sind. Jeder superskalare Prozessor 200 ist über einen Prozessorbus 123 mit einer Speichersteuerung 121 und einer Systemsteuerung 150 verbunden. Die Speichersteuerung stellt eine 64 Bit Schnittstelle zu dem Speicher Hauptspeicher 122 einschließlich einer 8 Bit Paritätsschnittstelle für die Unterstützung von Fehler korrigierenden Codes (ECC) zur Verfügung. Ein ECC Speicher ist wünschenswert, aber optional. Die Systemsteuerung 150 stellt die Schnittstelle (oder Brücke) zwischen dem 64 Bit Prozessorbus 123 und dem 32 Bit Lokalbus 151 zur Verfügung. Der Lokalbus 151 ist ein beliebiger I/O Bus mit hoher Geschwindigkeit, zum Beispiel ein VESA Lokalbus (VL Bus) oder ein Peripheriekomponentenverbindungs (PCI) Bus. Die Systemsteuerung 150 stellt ein Puffern zur Verfügung, um die potentiell verschiedenen Taktraten des Prozessorbusses 123 und des Lokalbusses 151 zu unterstützen. Die Systemsteuerung 150 vermittelt für die Benutzung der beiden Busse (123 und 151) und kann in gewissen Konfigurationen Burst-Datenübertragungen zwischen den beiden Bussen unterstützen. Der Lokalbus 151 ist mit mehreren lokalen Busgeräten und Komponenten (beispielhaft einem SCSI Adapter 170, einer IDE Steuerung 180, einem LAN Adapter 157 und einer Brücke und Peripheriesteuerung 160) verbunden. Weil die Anforderungen an das Anzeigegerät üblicherweise bei Netzwerkserverkonfigurationen weniger fordernd sind als bei Personal Computer oder Workstation Konfigurationen, ist der Anzeigeadapter 112 an den ISA Bus 161 mit niedriger Bandbreite angeschlossen gezeigt.
  • Die IDE Steuerung 180 ist repräsentativ für eine Vielzahl von Steuerungsentwürfen (einschließlich IDE, enhanced IDE, ATA und verbessertes kleine Geräte Interface (ESDI) Steuerungsentwürfen) zum Umsetzen an Speichergeräte wie Platten, Bandlaufwerke und CD-ROMs. Die IDE Steuerung 180 ist mit zwei Platten (Festplatte 181 und Diskette 182) und einer Bandsicherungseinheit 183 verbunden. Alternative Konfigurationen könnten ein IDE/enhanced IDE CD-ROM über die IDE Steuerung 180 ansprechen, ob wohl sowohl ein CD-ROM 172 als auch eine CD Jukebox 173 in dem Ausführungsbeispiel von 11B über einen Kleine Computersystemschnittstelle (SCSI) Adapter 170 angesprochen werden.
  • Der SCSI Adapter 170 ist mit dem Lokalbus 151 und mehreren SCSI Geräten (beispielhaft mit einem Redundanten Array aus günstigen Platten (RAID) 171, einem CD-ROM 172, einem Scanner 2016, einer CD Jukebox 173 und einem Scanner 174) in einer verketteten Konfiguration verbunden. Für Zwecke der Darstellung ist die Kette der SCSI Geräte in der 11B wie ein Bus gezeigt. Der LAN Adapter 157 ist repräsentativ für geeignete Netzwerkadapter wie solche basierend auf IEEE 802.x Standards (zum Beispiel 802.3 Basisband Ethernet auf koaxialen Medien, verdrillten und nicht verdrillten Paarmedien und 10base-T, 802.3 Breitbandnetzwerken, 802.4 Token Passing Netzwerken, 802.5 Token Ring Netzwerken, usw.) und solchen basierend auf fiberglasverteilten Datenschnittstellen (FDDI) Standards. Der ISA Bus 161 ist mit dem Lokalbus 151 verbunden über die Brücke und Peripheriesteuerung 160 und stellt einen 16 Bit I/O Bus und modulare Verbindungen für eine Vielzahl von peripheren Komponenten einschließlich des Anzeigeadapters 112, einer Telephoniekarte 136 und einer Multifunktions I/O Karte wie der Super I/O 135 zur Verfügung. Die Super I/O 135 stellt Unterstützung für ein Zeigegerät 137, einen seriellen Anschluss 138, einen parallelen Anschluss 139 und eine Platte 131 zur Verfügung.
  • Eine Multimedia Workstationkonfiguration für den superskalaren Prozessor 200 ist in 11C gezeigt. Wie bei der Serverkonfiguration aus 11B enthält die Multimedia Workstationkonfiguration eine Hierarchie von Bussen mit wechselnden Charakteristika der Leistungsfähigkeit, jeder angepasst an die daran angeschlossenen Geräte und Komponenten. Die Fachleute auf dem Gebiet werden eine Vielzahl von geeigneten Variationen der Bushierarchie von 11C erkennen. Der Speicherbus 126 verbindet den superskalaren Prozessor 200, den Cachespeicher 127, den Speicher 128 und die Brücke 129. Wie bei der Netzwerkserverkonfiguration aus 11B ist eine Vielzahl von Cachespeicherkonfigurationen für eine Multimedia Workstation geeignet. Der Lokalbus ist vorzugsweise ein I/O Bus mit hoher Geschwindig keit, wie ein VL Bus oder PCI Bus. Der SCSI Adapter 170, der LAN Adapter 157, ein Grafikadapter 114, ein Soundadapter 190 und ein Motion Video Adapter 195 sind über dem I/O Bus 151 miteinander und mit dem superskalaren Prozessor 200 verbunden. Der SCSI Adapter 170, der LAN Adapter 157 und eine Erweiterungsbusbrücke 160 sind zusammen mit den an jeden angeschlossenen Komponenten und Geräten vergleichbar mit entsprechenden Adaptern, Komponenten und Geräten, die oben unter Bezugnahme auf 11B besprochen wurden. Insbesondere ist der SCSI Adapter 170 mit mehreren SCSI Geräten (beispielhaft Platte 175, Bandsicherungseinheit 176 und CD-ROM 172) in einer verketteten Konfiguration verbunden.
  • In Übereinstimmung mit einem Ausführungsbeispiel des superskalaren Prozessors 200 kann der superskalare Prozessor 200 eine Multimediaeinheit 256 für die Ausführung von Multimediaerweiterungen des x86 Befehlssatzes enthalten. Wieder Bezug nehmend auf 11C sind Multimediaadapter, wie der Soundadapter 190, der Motion Video Adapter 195 und der Grafikadapter 114 jeweils über die Busse 151 und 126 mit dem superskalaren Prozessor 200 verbunden, um Transfers von Multimediadaten mit hoher Geschwindigkeit zwischen den Multimediaadaptern, dem Speicher 128 und den sekundären Speichergeräten (zum Beispiel Platte 175) zur Verfügung zu stellen. Der Soundadapter 190 stellt digital zu analog (D/A) und analog zu digital (A/D) Schnittstellen zum Synthetisieren beziehungsweise Abtasten von Audiosignalen zur Verfügung. Die A/D und D/A Schnittstellen des Soundadapters. 190 sind mit einem Mikrophon 191 beziehungsweise einem Lautsprecher 192 verbunden. Geeignete Entwürfe für Soundkarten sind im Stand der Technik weit verbreitet und der Soundadapter 190 ist von beliebigem geeigneten Design.
  • Der Motion Video Adapter 195 stellt Unterstützung für das Einlesen und Komprimieren von Videosignalen, zum Beispiel von einer Videokamera 196, zur Verfügung. Des weiteren versorgt der Motion Video Adapter 195 ein Anzeigegerät wie einen Fernseher, einen Fernseher mit hoher Auflösung oder einen hoch auflösenden Computermonitor über einen Seitenpuffer 197 mit Anzeigesignalen. Alternative Ausführungsbeispiele des Motion Video Adapters 195 könnten den Seitenpuffer 197 eliminieren und eine Rasteranzeige direkt ansteuern. Des weiteren könnten alternative Ausführungsbeispiele des Motion Video Adapters 195 die Videoeingang und die Videoausgang Funktionalität des Motion Video Adapters 195 entkoppeln und stattdessen getrennte Komponenten für den Videoeingang und für den Videoausgang zur Verfügung stellen.
  • Weil Videoinformation einen großen Betrag an Speicherplatz benötigt, wird sie im allgemeinen komprimiert. Entsprechend muss, um komprimierte Videoinformation, zum Beispiel aus Daten geliefert auf einer CD Rom in dem CD-ROM 172, zu zeigen, die komprimierte Videoinformation dekomprimiert werden. Burstmodus Datentransfers mit hoher Bandbreite werden von dem I/O Bus 151 unterstützt, der vorzugsweise ein Lokalbus wie ein PCI mit Unterstützung für die Vermittlung von Längen der Burst Datentransfers ist. Die Videokomprimierung und Dekomprimierung kann von dem superskalaren Prozessor 200 ausgeführt werden (Ausführen von Multimediabefehlen in einer Multimediaeinheit) und/oder von dem Motion Video Adapter 195. Deshalb unterstützt der Speicherbus 126 und die Brücke 129 vorzugsweise Burst Datentransfers über die Brücke 129 zwischen dem Speicherbus 126 und dem I/O Bus 151.
  • X. Abschluss
  • Obwohl die vorliegende Erfindung unter Bezugnahme auf bestimmte Ausführungsbeispiele beschrieben worden ist, ist die Beschreibung nur ein Beispiel der Anwendbarkeit der Erfindung und sollte nicht als Beschränkung genommen werden. Verschiedene Anpassungen und Kombinationen von Merkmalen der offenbarten Ausführungsbeispiele sind innerhalb des Umfangs der vorliegenden Erfindung.
  • Anhang A: RISC86TM Syntax
  • Dieser Anhang beschreibt Op-Codes in Übereinstimmung mit der in 3 dargestellten RISC86TM Syntax.
  • RegOp DEFINITIONEN
  • Die Bits 36 und 37 eines Op-Codes sind 00, um eine RegOp zu identifizieren. Die Bits 10 und 11 werden nicht benutzt und sollten 00 sein.
  • A.1 Kodierung RegOp Type Feld
    Figure 01060001
  • Figure 01070001
  • Von einem "/" getrennte mnemonische Ausdrücke haben identische Typen Felder und werden von den Registereinheiten 253 und 254 gleich behandelt. Diese RegOps unterscheiden sich in Änderungen des Status, die durch die Felder Ext und SS angezeigt werden und von der OCU 260 übergeben werden.
  • Das Type Feld wird basierend auf Feld DSz unterschiedlich interpretiert. Wie oben dargestellt führen die Ausführungseinheiten eine Operation für eine Byte-formatige RegOp aus und eine andere Operation für 16/32-Bit formatige RegOp.
  • Alle Byte-formatigen RegOps und alle RegOps mit einem Type Feld der Form x1xxxx, 1x1xxx oder xx01xx sind nur-RUX Operationen.
  • Die Hardware behandelt alle RegOps mit Werten des Type Felds der Form xx01xx als "cc-dependent" und synchronisiert daher die Ausführung der Operation mit der Weiterleitung der Statusoperanden.
  • A.2 RegOp Erweiterungsfeld Ext[3:0]
  • Für MOVcc Ops, gibt {Type[0],Ext[3:0]} einen 5-Bit Bedingungscode an. Für RDxxx/WRxxx Ops, gibt {Type[0],Ext[3:0]} eine 5-Bit Spezialregisternummer an. Für WRFLG(.cc) stimmt die Kodierung der spec Registernummer mit dem gewünschten StatMod Wert überein, wenn ".cc" angegeben ist. Für RDSEG Ops gibt Ext[3:0] ein 4-Bit Segment (Auswahl) Register an. Der Satz der Segmentregister umfasst x86 architekturale Register und zusätzliche Spezialsegmentregister.
  • Figure 01080001
  • Das OS Segmentregister wird zur Op Dekodierungszeit durch die aktuelle 3-Bit Registernummer von der Emulationsumgebung ersetzt.
  • Für weitere Operationen mit dem Feld SS = 1, gibt {Type[0],Ext[3:0]} vier Statusänderungsbits an (wie in dem Ablaufplaner 280 gespeichert).
  • A.3 RegOp Operation/Datengröße Feld DSz[2:0]
  • Das Feld DSz zeigt eine Datengröße für die Operation an.
    PSz[2:0] Operation/Datengröße
    000 1 Byte
    001 2 Byte
    010 4 Byte
    011 DSize
    100 ASize
    101 SSize
  • Die Größen DSize, ASize und SSize sind Platzhalter, die mit entsprechenden Umgebungsvariablen während der Umgebungsersetzung ersetzt werden.
  • A.4 RegOp RUX-only Feld R1
  • RI wird gesetzt, um anzuzeigen, dass die RegOp nur an die Registereinheit 251 ausgegeben werden kann.
  • A.5 RegOp Ziel Feld Dest[4:0]
  • Das Feld Dest[4:0] hält eine 5-Bit allgemeine Registernummer, die ein Zielregister für die Operation identifiziert.
  • A.6 RegOp Erste Quelle Feld Scr1[4:0]
  • Das Feld Scr1[4:0] hält eine 5-Bit allgemeine Registernummer, die ein erstes Quellregister für die Operation identifiziert.
  • A.6 RegOp Setzen Status Feld SS
  • Das Feld SS wird gesetzt, um anzuzeigen, dass die Operation die von dem Feld Ext angezeigten Status Flags ändert.
  • A.6 RegOp Feld I
  • Das Feld I zeigt an, ob das Feld Imm8/Src2 einen unmittelbaren Wert oder eine Registernummer enthält.
  • A.6 RegOp Feld Imm8/Src2[7:0]
  • Das Feld Imm8/Src2 hält einen unmittelbaren Wert oder eine Registernummer für einen zweiten Quelloperanden. Wenn I = 0 ist, enthält Imm8/Src2[4:0] eine 5-Bit Registernummer. Wenn I = 1 ist, gibt Imm8/Src2[7:0] einen 8-Bit unmittelbaren Wert mit Vorzeichen an, der auf eine von dem Feld DSz angezeigte Größe um das Vorzeichen erweitert wird.
  • LdStOp DEFINITIONEN
  • Die Bits 37 und 36 von einem Op-Code sind 0 und 1, um eine LdStOp anzuzeigen.
  • A.7 LdStOp Type Feld Type[3:0]
    Figure 01100001
  • Figure 01110001
  • A.8 LdStOp Adressberechnungsgröße Feld Asz[1:0]
  • Vor der Emcode Umgebungsersetzung, zeigt das Feld ASz[1:0] die Größe der Adressberechnung wie folgt an.
    Asz[1:0] Größe
    00 ASize
    01 SSize
    10 4 Byte
    11 DSize
  • Die Emcode Umgebungsersetzung ändert ASize, SSize oder DSize auf die geeignete feste Größe.
  • A.9 LdStOp Datengröße Feld DSz[1:0]
    Figure 01110002
  • A.10 LdStOp Daten Feld Data[4:0]
  • Das Feld Data zeigt eine 5-Bit allgemeine Registernummer für das Speicherquelle- oder Ladeziel-Register an.
  • A.10 LdStOp Segment Feld Seg[3:0]
  • Das Feld Seg[3:0] identifiziert ein Segmentregister.
  • A.11 LdStOp Basisoperanden Feld Base[3:0]
  • Das Feld Base enthält eine 4-Bit Registernummer, die ein allgemeines Register in der unteren Hälfte der Registerdatei anzeigt. Der Wert von dem Register ist die Basis für die Berechnung der Adresse.
  • A.12 LdStOp Index Feld Index[3:0]
  • Das Feld Base enthält eine 4-Bit Registernummer, die ein allgemeines Register in der unteren Hälfte der Registerdatei anzeigt. Der Wert von dem Register wird als ein Adressindex verwendet, der während einer Berechnung der Adresse skaliert und zu der Basis addiert wird.
  • A. 13 LdStOp Index Skalierungsfaktor Feld ISF[1:0]
  • Das Feld ISF zeigt an, dass der Index um einen Faktor von 1, 2, 4 oder 8 skaliert werden soll.
  • A. 14 LdStOp Große Versetzung Feld LD
  • Das Feld LD zeigt an, ob die Operation eine große (32-Bit) Versetzung von einer vorher gehenden LIMMOp oder eine kleine (8-Bit) Versetzung von dem Feld Disp8 verwendet.
  • A.15 LdStOp Kleine Versetzung Feld Disp[f7:0]
  • Das Feld Disp8[7:0] enthält eine 8-Bit Versetzung, die auf eine von dem Feld Asz angezeigte Größe um ein Vorzeichen erweitert wird.
  • LIMMOp DEFINITIONEN
  • Die Bits 37 und 36 von einem Op-Ccode sind 11, um eine LIMMOp anzuzeigen.
  • A.16 LIMMOp Unmittelbare Felder ImmHi und ImmLo
  • Die Felder ImmHi[14:0] beziehungsweise ImmLo[16:0] enthalten die höchstwertigen 15 Bits und die niedrigstwertigen 17 Bits eines 32-Bit unmittelbaren Werts.
  • A. 17 LIMMOp Ziel Feld Dest[3:0]
  • Das Feld Dest[3:0] speichert eine 4-Bit Registernummer, die ein Ziel für den unmittelbaren Wert anzeigt.
  • Bemerkung: Die Standard NO-OP ist "LIMM t0, < undefined > ", welche in einem abgeschlossenen Zustand in den Ablaufplaner geladen wird und durch Schreiben eines unmittelbaren Werts < undefined > in ein Register, das durch das Schreiben nicht geändert wird, übertragen.
  • SpecOp DEFINITIONEN
  • Die Bits 37 und 36 von einem Op-Code sind 10, um eine SpecOp anzuzeigen. Das Bit 35 ist für die in diesem Anhang beschriebenen SpecOps gesetzt, aber für FpOps frei.
  • A. 18 SpecOp Type Feld Type[3:0]
    Figure 01130001
  • A.19 SpecOp Bedingungscode Feld cc[4:0]
  • Das Feld cc[4:0] enthält einen 5-Bit Bedingungscode für BRCOND Operationen. Die Bits cc[4:1] geben die zu testende Bedingung wie folgt an.
  • Figure 01140001
  • Das Bit cc[0] gibt an, ob die Bedingung oder ihr Komplement als wahr bewertet wird.
  • In den obigen Definitionen zeigen "-", "•", "+" und "^" logische NOT, AND, OR beziehungsweise XOR Operationen an. OF, SF, ZF, AF, PF, und CF sind Standard x86 Status Bits, EZF und ECF sind ein Emulations Null Flag und ein Emulations Carry Flag, das die Emcodierung in Sequenzen benutzt, die x86 Befehle implementieren, wenn das architekturale Null Flag ZF und das Carry Flag CF nicht geändert werden. IP, DTF und SSTF sind Signale, die einen anhängigen Interrupt, ein debug Fang Flag beziehungsweise ein Einzelschritt Fang Flag anzeigen.
  • Die Verzweigungsbedingungen STRZ und MSTRC sind logisch identisch und werden bei der Implementierung von x86 Befehlen, wie einem bewege Zeichenkette Befehl MOVS, verwendet. Für derartige x86 Befehle speichert die Emcodierung einen Index in einem Register und erzeugt eine Schleife, die mit einer BRCOND endet. Jede Iteration der Schleife bewegt ein Stück an Daten und zählt den Index runter. Die Verzweigungsvorhersage sagt anfänglich voraus, dass die BRCOND an dem Anfang der Schleife verzweigt. Die Bedingung MSTRC zeigt an, dass die Verzweigungsbewertungslogik 257 dem Befehlsdekodierer 240 zu signalisieren hat, wenn der Index einen vordefinierten Punkt nahe bei dem Abschluss des x86 Befehls erreicht. Der Dekodierer 240 ändert dann die Verzweigungsvorhersage für die in den Ablaufplaner 280 zu ladende BRCOND. Entsprechend können eine falsch vorher gesagte Verzweigung und ein dazu gehöriger Abbruch verhindert werden, wenn das Durchlaufen der Schleife beendet ist. Dies verbessert die Effizient des Prozessors.
  • A.20 SpecOP Datengröße Feld DSz[1:0]
  • Das Feld DSz[1:0] zeigt eine Datengröße von 1 Byte, 4 Byte oder DSize für Laden konstant Operationen LDK und LDKD an.
  • A.21 SpecOp Ziel Feld Dest[4:0]
  • Das Feld Dest hält eine 5-Bit Registernummer, die das Ziel der Operation LDK und LDKD ist.
  • A.21 SpecOp unmitelbares Feld Imm17[16:0]
  • Das Feld Imm17[16:0] enthält eine 17-Bit konstante, eine 17-Bit mit Vorzeichen versehene unmittelbare oder eine 14-Bit Op Adresse.
  • ALLGEMEINE REGISTER DEFINITIONEN
  • Da gibt es 24 Integer allgemeine Register. Die ersten acht Register entsprechen den x86 allgemeinen Registern AX bis DI. Die verbleibenden sechzehn Register dienen als temporäre oder Arbeitsregister zur Benutzung mit mehreren Operationssequenzen, die CISC Befehle verwenden. Die Operationen, die 5-Bit Registernummern verwenden, können auf 32 Register zugreifen, und verbleibende nicht für Integer Register benutzte Registernummern können Multimedia Register oder Platzhalter für die Ersetzung von Umgebungsvariablen sein.
  • Der x86 Integer Registersatz unterstützt Adressierung für Byte Operationen von einem der unteren beiden Bytes der Hälft der Register (AX, CX, DX und BX). Basierend auf der Angabe der Registergröße werden die 3-Bit Registernummern innerhalb der x86 Befehle entweder als hi/lo Byte Register oder als word/dword Register interpretiert. Von einer Operationsperspektive wird die Größe entweder von dem ASz oder DSz Feld der Operation bestimmt. (ASz für Basis und Index Register in LdStOps; und allgemein DSz für Daten/Ziel, Src1 und Src2 Register). Der Arbeits Integer Registersatz unterstützt eine ähnliche Adressierung der unteren beiden Bytes von. wiederum der Hälfte des Registers (t1–t4 und t8–t11).
  • Die folgende Tabelle bildet Registernummern 1 to 24 auf benannte Register ab.
  • Figure 01160001
  • Figure 01170001
  • Die mnemonischen Bezeichnungen "t0" und "_" sind synonym für ein Register, in das geschrieben werden kann, das aber immer einen Wert Null zurück gibt, wenn es gelesen wird. " " wird üblicherweise in einem Kontext verwendet, in dem ein Operand oder ein Ergebniswert ein don't care ist. Wie oben angezeigt, kann das Register t0 nicht im Byte Modus angesprochen werden.
  • Anhang B: Pseudo-RTL Beschreibungen
  • Die Tabellen in diesem Anhang beschreiben Logik, die in dem beispielhaften Ausführungsbeispiel des Prozessors 200 durchweg verwendete Signale erzeugt. Jede Tabelle kann in anderen Tabellen beschriebene Signale ohne weitere Erklärung oder Bezugnahme auf die anderen Tabellen verwenden. Die in diesem Anhang beschriebenen Signale werden gesetzt oder aktiv hoch, wenn nicht ausdrücklich anders angezeigt.
  • Die folgenden Bezeichnungen werden verwendet. "~" zeigt das Komplement oder das Inverse eines Signals an, wie es von einem Inverter zur Verfügung gestellt werden würde. Mit einem "•", " " und "&" verbundene Signale werden wie ein logisches UND verbunden, wie es von einem AND Gatter implementiert werden könnte. Mit einem "+" verbundene Signale werden wie logisches ODER kombiniert, wie es von einem OR Gatter implementiert werden könnte. Mit einem "^" verbundene Signale werden wie logisches exklusives ODER kombiniert, wie es von einem XOR Gatter implementiert werden könnte. Der Ausdruck "if (a) x = b else x = c" oder alternativ "if (a) x = b c" zeigt einen Multiplexer mit einem Ausgangssignal x an, das gleich ist mit Signal b, wenn das Signal a anliegt, und ansonsten entspricht das Signal x c. Wenn "else x = c" weg gelassen wird, ist das Signal x niedrig, wenn das Signal a niedrig ist. Ein weiterer Ausdruck, der einen Multiplexer darstellt, ist "x = switch (A) case A1:x1 case A2:x2 ... case An:xn", wobei das Ausgangssignal x Werte x1 oder x2 oder ... xn hat, abhängig von dem Wert des Auswahlsignals A mit mehreren Bits. Wo Gases weg gelassen werden wie in "x = (A) x1:x2: ... xn", entsprechen die Ausgangswerte x1 bis xn den sequentiellen Werten des Signals A. Die meisten beschriebenen Signale ändern sich jeden Taktzyklus. Der Ausdruck @(clock) zeigt ein Signal an, das bei einer Flanke des Signaltakts in einem Register für die Verwendung in einem nachfolgenden Taktzyklus verriegelt wird.
  • Wie von den Fachleuten auf diesem Gebiet verstanden wird, kann die unten beschriebene Logik auf eine Vielzahl von Arten implementiert werden.
  • Tabelle B.1 Statische Feldspeicherelementoperation
    Figure 01180001
  • Tabelle B.2 Dynamische Feldspeicherelementoperation
    Figure 01180002
  • Figure 01190001
  • Die globale Steuerlogik 520 für den Ablaufplaner 280 erzeugt unabhängige Signale LdEntry[i], die ein in ein entsprechendes Flip-Flop geladenes Signal auswählen.
  • Die Bezeichnung xxOp.yyy bezieht sich auf ein Eingangssignal für den Operationsdekodierer 510, das einen Wert von einem Feld yyy anzeigt, das für einen RISC86. Befehl vom Typ xxOp definiert ist. Zum Beispiel bezieht sich RegOp.Src1 auf Bits in einem Befehl, die an derselben Stelle stehen wie das Src1 Feld einer Regp. 3 und Anhang A definieren eine beispielhafte Felddefinition für eine RegOp, eine LdStOp, eine LIMMOp und eine SpecOp.
  • Tabelle B.3 Feldtyp
    Figure 01190002
  • "RUYD" ist ein Spezialregister, dass die zweite Registereinheit RUY zum debuggen sperrt.
  • Tabelle B.4 Feld LD Imm
    Figure 01190003
  • Tabelle B.5 Feld Src1Reg
    Figure 01200001
  • Tabelle B.6 Feld Src2Reg
    Figure 01200002
  • Tabelle B.7 Feld SrcStReg
    Figure 01200003
  • Tabelle B.8 Feld DestReg
    Figure 01200004
  • Tabelle B.9 Felder Src1BM, Src2BM und Src12BM
    Figure 01200005
  • Figure 01210001
  • Tabelle B.10 Feld SrcStBM
    Figure 01210002
  • Tabelle B.11 Feld OpInfo
    Figure 01210003
  • Tabelle B.12 Feld Status
  • Der Operationsdekodierer 510 initialisiert das Feld Status [3:0] entweder als b0000 (nicht ausgegeben) oder b1111 (abgeschlossen) in Übereinstimmung mit dem OpId Feld des entsprechenden RISC86 Befehls.
  • Figure 01210004
  • Das Feld Status (Signale S0, S1, S2 and S3) ändert sich während der Ausfüh rung der Operation wie folgt.
  • Figure 01220001
  • Das Signal SC_Abort wird angelegt, um die Ausführung von derzeit in dem Ablaufplaner 280 befindlichen Operationen abzubrechen. Die Signale IssueOpToLU[i], IssueOpToSU[i], IssueOpToRUX[i] und IssueOpToRUY[i].
  • Tabelle B.13 Feld Exec1
  • Der Operationsdekodierer 510 initialisiert das Feld Exec1 auf niedrig.
  • Figure 01220002
  • Nachfolgend ändert sich das Feld Exec1 wie folgt.
  • Figure 01220003
  • Das Signal IssueOpToRUX wird in dem Eintrag während der Abtastungskette der Ausgabeauswahl für die Registereinheit 253 erzeugt.
  • Tabelle B.14 Feld DestBM
  • Der Operationsdekodierer 520 initialisiert das Feld DestBM in Übereinstimmung mit der Operation, um anzuzeigen, welche Bytes des Zielregisters verändert werden.
  • Figure 01230001
  • Das Feld DestBM wird wie folgt frei gegeben:
  • Figure 01230002
  • Tabelle B.15 Feld DestVal
  • Der Operationsdekodierer 510 erzeugt das Feld DestVal aus dem verbundenen RISC86 Befehl unter Verwendung der folgenden Logik.
  • Figure 01230003
  • Folgend auf die Operation ändert sich das Feld DestVal wie folgt.
    Figure 01240001
    wobei die Signale DC_DestRes, SUI_DestRes, RUX_DestRes und RUY_DestRes von der Ausführungseinheit sind, welche die Operation ausgeführt hat.
  • Tabelle B.16 Feld StatMod
  • Der Operationsdekodierer 510 setzt das Feld StatMod in Übereinstimmung mit der verbundenen Operation.
  • Figure 01240002
  • Die Logik in dem Ablaufplaner 280 löscht das Feld StatMod während eines Abbruchvorgangs.
  • Figure 01240003
  • Tabelle B. 17 Feld StatVal Erzeugungslogik
  • Das Feld StatVal ist anfänglich Null.
    Figure 01240004
    und ändert sich, wenn eine RegOp abgeschlossen ist.
  • Figure 01240005
  • Tabelle B.18 Felder OprndMatch XXsrcY
  • Die Felder OprndMatch_XXsrcY leiten Information von der Stufe Ausgabe an die Stufe Operandenweiterleitung von jeder Verarbeitungspipeline weiter (oder in einem Fall von Stufe 1 zu Stufe 2 einer SU), Werte werden von den globalen Signalen XXAdvY (genauer gesagt XXAdv0 oder SUAdv2) gesteuert.
  • Figure 01250001
  • Tabelle B.19 Feld DBN
  • Das Feld DBN ist anfänglich Null.
    Figure 01250002
    und ändert sich während der Ausführung wie folgt.
  • Figure 01250003
  • Tabelle B.20 Op Quad Feld Emcode
    Figure 01250004
  • Tabelle B.21 Op Quad Feld Eret
    Figure 01250005
  • Tabelle B.22 Op Quad Feld FaultPC
    Figure 01260001
  • Der logische PC für den ersten dekodierten x86 Befehl in dem Op Quad.
  • Tabelle B.23 Op Quad Feld BPTInfo
    Figure 01260002
  • Information von dem derzeitigen BPT Zugriff.
  • Tabelle B.24 Op Quad Feld RASPtr
    Figure 01260003
  • Der derzeitige Rückkehradressenstapel.
  • Tabelle B.25 Op Quad Feld OpQV
  • Der Operationsdekodierer 510 setzt anfänglich das Feld OpQV, um anzuzeigen, ob der an die Spitze des Ablaufplaners 280 geladene Op Quad gültig ist.
  • Figure 01260004
  • Dieser Multiplexer ist nicht einzigartig: alle neuen Op Quad Felder stammen von ähnlichen (aber 3:1) Multiplexern, siehe OCU Beschreibung für die Beschreibung von ExcpAbort.
  • Das Feld OpQv kann später nach einem Abbruchvorgang frei gemacht werden, um eine Op Quad ungültig zu machen und eine Ausführung oder eine Übergabe zu verhindern.
  • Figure 01270001
  • Tabelle B.26 Op Quad Feld LimViol
    Figure 01270002
  • Das Feld LimViol wird tatsächlich einen Taktzyklus später als alle anderen der obigen Felder geladen (das heißt während des ersten Taktzyklus, in dem der neue Op Quad in dem Ablaufplaner vorhanden und gültig ist). Dies wird in der obigen Beschreibung von diesem Op Quad Feld berücksichtigt.
  • Figure 01270003
  • Tabelle B.27 Schiebesteuerlogik
  • Die Signale LdEntry0 bis LdEntry5 steuern das Laden von Zeile 0 (mit einem neuen Op Qquad) bis zum Laden von Zeile 5 (mit einem Op Quad aus Zeile 4) wie hinsichtlich 6 beschrieben. In dieser Tabelle zeigt das Eingangssignal OpQRetire, von OCU 260, an, wann ein gültiger Op Quad in der untersten Zeile des Ablaufplaners 280 zurück gezogen werden kann und die Eingangssignale HoldOpQ3, HoldOpQ4A und HoldOpQ4B zeigen an, ob eine Bewertung eines Bedingungscodes eine Operation in Zeile 3 oder 4 aufgehalten hat.
  • Figure 01270004
  • Figure 01280001
  • B.28 Ausgabeabtastungsausdrücke für Einzeleinträge
  • Ausdrücke für Einzeleinträge sind:
    Figure 01280002
    wobei "State = Unissued" gleich ~SO ist beziehungsweise "Executable by xx" gleich ist mit LU/SU/RU/RUY für die Ausführungspipelines LU/SU/RUX/RUY. Die Typ Bits LUi, SUi, Rui, RUXi, wie sie hier benutzt werden, sind: LU = 1 für LdOps; SU = 1 für StOps (einschließlich von Operationen wie LEA); RU = 1 für alle RegOps und RUY = 1 für RegOps, die von RUY ausführbar sind.
  • Tabelle B.29 LU, SU und RUX Vorausschau Abtastungsketten
  • Sechs Einzeleintragssignale bilden vier Gruppenausbreitungssignale XXPgrp[3:0] und Gruppenlöschsignale XXKgrp[3:0] für die Abtastungskette XX, wobei XX LU, SU oder RUX ist. Jedes Gruppensignal entspricht einem Quadranten des Ablaufplaners 280. Die Folgenden sind Gruppensignale für den ersten Quadranten (Quadrant 0), der Einträge 0 bis 5 für jede der Abtastungsketten enthält.
    Figure 01280003
    wobei PO zu P5 und KO zu K5 die Ausdrücke der Einzeleinträge für sechs aufeinanderfolgende Einträge und die Pipeline XX sind.
  • Eine Gruppe enthält den ausgewählten Befehl, wenn sein Gruppenlöschsignal XXKgrp gesetzt ist und keine ältere Gruppe das Abtastungsbit löscht. Ein Bit aus dem XXIssueQuadrant[0:3] wird gesetzt, um die Gruppe zu identifizieren, welche die zur Ausgabe an die Pipeline XX ausgewählte Operation enthält. Die Signale XXIssueQuadrant[0:3] werden wie folgt erzeugt.
  • Figure 01290001
  • Die Signale IssueToXX[i], zum Anzeigen, ob die Operation, wenn überhaupt, ausgegeben wurde, werden an die Pipeline XX ausgegeben und werden aus den Signalen IssueQuadrant und den Einzeleintrag Löschausdrücken IssuableToXX wie folgt erzeugt.
  • Figure 01290002
  • Tabelle B.30 RUY Abtastungskette (3-Bit Gruppen)
  • Die einzelnen Einträge P, K, O und G werden kombiniert, um die Gruppenausdrücke Ggrp[7:0], Pgrp[7:0] und Ogrp[7:0] für acht Gruppen von drei Einträgen zu schaffen. Für die Gruppe O sind die Gruppenausdrücke:
    Figure 01300001
    wobei x, y beziehungsweise z die ältesten, mittleren und neuesten Einträge in der Gruppe i identifizieren. Die Einzeleintrag G Ausdrücke sind Bits des Signals IssuableToRUX[23:0] und die Einzeleintrag K Ausdrücke sind Bits von IssuableToRUY[23:0].
  • Gruppenausdrücke werden in Stufen kombiniert, um Gruppenausdrücke für noch größere Gruppen zu bilden. Die folgenden Gleichungen beschreiben eine Logik, welche die Gruppenausdrücke GX, OX, PX, GY, OY und PY kombinieren, um Gruppenausdrücke für eine Gruppe XY zu bilden, welche die Vereinigung der Gruppen X und Y ist.
  • Figure 01300002
  • Die Signale CinGrp[6:0] und OinGrp[6:0] werden von diesen Kombinationen ausgegeben. Die Signale CinGrp[6:0] sind die Signale G_7, G_67, G_567, G_4567, G_34567, G_234567 und G_1234567. Die Ausgangssignale OinGrp[6:0] sind die Signal O_7, O_67, O_567, O_4567, O_34567, O_234567 und O_1234567.
  • Ein Bit des Signals IssueOpToRUY[23:0] wird gesetzt, um den ausgewählten Eintrag zu identifizieren. Die folgenden Gleichungen beschreiben die Logik, welche das Signal IssueOpToRUY erzeugt.
  • Figure 01300003
  • Für Gruppen i, wobei i gleich ist von 6 bis 0:
  • Figure 01310001
  • Tabelle B.31 Verbreitung Operandeninformation
  • Jeder Eintrag erzeugt Signale Src1Info und Src2Info, welche Quelloperanden für die in dem Eintrag enthaltene Operation beschreiben.
  • Figure 01310002
  • Falls die Operation zur Ausgabe ausgewählt wird, treibt der Eintrag die Signale Src1Info und Src2Info auf Operandeninformationsbussen, die mit der Ausführungseinheit verbunden sind, an die die Operation ausgegeben wird. Die Signale OprndInfo XXsrcY sind die tatsächlich auf dem Operandeninformationsbus getragenen Signale, die mit dem Quelloperanden Y für die Ausführungseinheit XX verbunden sind und wie folgt erzeugt werden.
  • Figure 01310003
  • B.32 Vergleiche der Übereinstimmung von Operandeninformationen
  • Die folgende Gleichung fasst einen allgemeinen Vergleich zusammen:
    Figure 01320001
    wobei "XxsrcY" einer der LUsrc1, LUsrc2, SUsrc1, SUsrc2, RUXsrc1, RUXsrc2, RUYsrc1 und RUYsrc2 ist und „bus" sich auf das Signal OprndInfo XxsrcY bezieht, das eines der Operandeninformationsbusse 552 ist. Die Überprüfung der Bytemerkmale umfasst nicht BM[2] als eine Vereinfachung und einen Kompromiss. BM[2] = 1 impliziert (BM[1] BM[0]) = 1 und daher, falls busBM[2] = 1, wird unabhängig von DestBM[2] eine Übereinstimmung signalisiert.
  • Tabelle B.33 Verbreitung Operationsinformation
  • Die folgenden Gleichungen fassen die Auslesung von OpInfo Feldern von Einträgen zusammen, die eine Operation enthalten, die ausgegeben wird. Den folgenden Gleichungen entsprechend kann jeder Eintrag ein Signal OpInfo_LU erzeugen.
  • OpInfo SU, OpInfo_RUX oder OpInfo_RUY auf den Operationsinformationsbussen entsprechen der LU, SU, RUX oder RUY Pipeline.
  • Figure 01320002
  • Lediglich ein Eintrag, der eine ausgegebene Operation enthält, treibt ein Signal auf einem Bus 551.
  • Die Signale XXAdv0 steuern diese externen Pipelineregister auf dieselbe Weise, wie sie die internen Register steuern.
  • Tabelle B.34 Abtastungskette für die Auswahl von Operanden
  • Die Einzeleintrag Ausdrücke sind für die acht Abtastungsketten LUsrc1, LUsrc2, SUsrc1, SUsrc2, RUXsrc1, RUXsrc2, RUYsrc1 und RUYsrc2.
  • Figure 01330001
  • Die Gruppenausdrücke für 4-Bit Gruppen werden wie folgt gebildet.
  • Figure 01330002
  • Alternativ können 3-Bit oder 6-Bit Gruppen verwendet werden.
  • Jeder Eintrag enthält ein Logiksignal, das die Signale SupplyValueToXXsrcY erzeugt, die anzeigen, ob der Eintrag den Operanden srcY an die Ausführungspipeline XX liefert.
  • Figure 01330003
  • Figure 01340001
  • XXsrcYchain.CIN und XXsrcYchain.K sind das Eingangsabtastungsbitsignal und der Löschausdruck in einem Eintrag in der Abtastungskette entsprechend dem Operanden srcY der Pipeline XX.
  • Tabelle B.35 Freigabelogik für den Transfer von Operanden
  • Jeder Eintrag hat acht Treiber, die acht zu transferierenden Operandensignalen Oprnd_XXsrcY entsprechen. Ein Eintrag gibt seine Treiber frei, um Ergebniswerte einer Operation zu liefern, wenn das Signal SupplyValueToXXSrcY während der Operandenauswahlphase angelegt wird.
  • Figure 01340002
  • Die Registerdatei 290 gibt ihre Treiber frei, um die Signale Oprnd_XxsrcY zu liefern, wenn ein Abtastungsbitausgang von einer Abtastungskette gesetzt wird.
  • Figure 01340003
  • Figure 01350001
  • Tabelle B.36 Operandeninformationssignal
  • Ein Eintrag, der einen Operanden zur Verfügung stellt, stellt auch wie folgt ein Operanden Statussignal zur Verfügung.
  • Figure 01350002
  • Freigabesignale für die Operandentreiber geben Treiber für das Operanden Statussignal wie folgt frei.
  • Figure 01350003
  • Die Registerdatei 290 treibt einen Operanden Statusbus 553, wenn keiner der Einträge ausgewählt ist, um einen Operanden zur Verfügung zu stellen, der dem Operanden Statusbus entspricht. Das Operanden Statussignal von der Registerdatei 290 ist von der folgenden Form.
  • Figure 01350004
  • Die Logik, welche die Registerdatei 290 frei gibt, die Operanden Statusbusse 553 zu treiben, wird wie folgt zusammengefasst.
  • Figure 01350005
  • Figure 01360001
  • Tabelle B.37 Verschiebungsweiterleitung
  • Während der Stufe Weiterleitung der Operanden, wird die Verschiebungsweiterleitung eines Eintrags entweder von dem Eintrag oder von dem voran gehenden Eintrag in dem Ablaufplaner 280 frei gegeben. Das Folgende fasst die Weiterleitung der Signale Disp_LU und Disp_SU an die Ladeeinheit 251 und die Speichereinheit 252 zusammen.
  • Figure 01360002
  • Die Werte "thisOp" und "nextOp" identifizieren den physikalischen Eintrag, von dem die folgenden Signale LU, S1, S0 und LD stammen. Auch ist, für den Fall des ersten/neuesten Eintrags in dem Ablaufplaner 280 der NextOp Ausdruck Null.
  • Tabelle B.38 Unmittelbare Weiterleitung von Werten
  • Die Treiber stellen den Registereinheiten 253 und 254 unmittelbare Werte wie folgt zur Verfügung.
  • Figure 01360003
  • Die folgenden Gleichungen fassen die Freigabe von verschiedenen Bussen für Operanden Statussignale zusammen.
  • Figure 01360004
  • Tabelle B.39 Auswahl und Weiterleitung von Datenoperanden
  • Während der Operationsauswahlphase 456 bestimmt jeder Eintrag, ob er in der Stufe Ausführung 450 ist.
  • Figure 01370001
  • Während der Stufe Verbreitung von Datenoperanden erzeugt der Eintrag, der die Operation enthält, welche bestimmt ist, in der Stufe Ausführung 450 zu sein, wie folgt ein Informationssignal für den Datenoperanden.
  • Figure 01370002
  • Jeder Eintrag bestimmt aus dem Datenoperanden-Informationssignal, ob der Eintrag eine Operation enthält, die sich auf das Quellregister des Datenoperanden auswirkt. Ein Übereinstimmungsregister für Datenoperanden in jedem Eintrag verriegelt einen Wert OprndMatch_SUsrcSt, der anzeigt, ob der Eintrag sich auf die Quelle des Datenoperanden auswirkt.
    Figure 01370003
    wobei „bus" sich auf OprndInfo_SUsrcSt bezieht.
  • Während der Phase der Auswahl der Operanden 461, wählt eine von dem ausgewählten Eintrag startende Abtastungskette eine Quelle des Datenoperanden aus. Die Quelle ist der neueste vorausgehende Eintrag, der sich auf die Quelle des Datenoperanden oder auf die Registerdatei 290 auswirkt, wenn kein vorausgehender Eintrag sich auf den Datenoperanden auswirkt. Die Abtastungskette hat Einzeleintrag Abtastungsausdrücke:
  • Figure 01370004
  • Figure 01380001
  • Die Abtastungsgleichungen auf Gruppenebene sind dieselben wie Abtastungsgleichungen für eine andere Auswahl von Operanden, wie in Tabelle B.34, und jeder Eintrag bestimmt von einem Eingangsabtastungsbit und einem Löschausdruck für den Eintrag, ob der Eintrag ausgewählt ist.
  • Figure 01380002
  • Während der Phase des Transfers von Datenoperanden 462, werden die Treiber in jedem Eintrag des Ablaufplaners wie folgt frei gegeben.
  • Figure 01380003
  • Falls keiner der Einträge des Treibers frei gegeben ist, werden die Treiber am Ausgang der Registerdatei wie folgt frei gegeben.
  • Figure 01380004
  • Der über den Bus 554 transferierte Datenoperand Oprnd_SUsrcSt wird in ein Register 1052 in der Speichereinheit 252 eingelesen. Während der Phase des Transfers von Datenoperanden 462 verwendet die Steuerlogik 520 den gelesenen Wert des Operandenstatus.
  • Tabelle B.40 Abtastungsketten zum Lade-Speicher-Ordnen
  • Die Abtastungsketten zum Lade-Speicher-Ordnen haben Einzeleintrag Ausbreitungs/Lösch (P/K) Ausdrücke, die auf den Status und Typ Feldern jedes Eintrags basieren. Für die drei LdOp Abtastungsketten wird das ST Typ Bit anstatt des SU Bits verwendet. Dies unterscheidet die StOps, die sich tatsächlich auf Speicher beziehen, von LEA Operationen, die lediglich logische Adressen erzeugen. LUst2/LUst1/LUst0 und SUId2/SUId1 bezeich nen die jeweiligen Abtastungsketten für die Ladeeinheit 251 und die Speichereinheit 252.
  • Die Einzeleintrag Ausdrücke für die Abtastungsketten sind:
  • Figure 01390001
  • Die Vorausschau Gruppenausdrücke (basierend auf Gruppen von vier) sind:
  • Figure 01390002
  • Die Eingangssignale der Abtastungsbits für Op Quads sind:
  • Figure 01390003
  • Während der zweiten Phase 462 der Stufe Ausführung 460 für eine LdStOp werden die Cins der zwei/drei Abtastungsbits zu dem Eintrag, der die LdStOp hält, mit einem 24:1 Multiplexer wie folgt kombiniert:
  • Figure 01390004
  • Figure 01400001
  • Die Abtastungsbits Cin werden invertiert, wenn sie auf die globalen Signale getrieben werden, mit dem Ergebnis, dass, wenn ein globales Signal Eins ist, dann die zugeordnete Stufe eine ältere Operation enthält.
  • Tabelle 8.41 Information von dem Ablaufplaner an externe Logik
  • Das Folgende fasst die Information, die aus dem Ablaufplaner 280 ausgelesen wird, an verschiedenen Zeitpunkten, für den externen Gebrauch zusammen:
  • Während der Phase der Verbreitung von Operandeninformation:
  • Figure 01400002
  • Während der Phase des Transfers von Operanden:
  • Figure 01400003
  • Bemerke: XX = {LU,SU,RUX,RUY}; Y = {1,2}
  • Tabelle B.42 Operation Gültig Bits
  • Das Folgende fasst die OpV Bits für die Stufe Ausgabe der vier Ausführungspipelines zusammen.
  • Figure 01400004
  • Tabelle B.43 RegOp Zusammenstösse
  • Die globale Steuerlogik 520 enthält eine Logik, welche die Signale BumpRUX/Y wie folgt erzeugt. Unten enthalten sind Ausdrücke zur Behandlung, was ansonsten Blockadesituationen sein könnten.
  • Das Signal InhBumpRUX verhindert RegOp Zusammenstösse, wenn die Stufe Operandenweiterleitung eine nur RUX Operation ist und eine auszugebende RegOp auch eine nur RUX Operation ist.
  • Figure 01410001
  • Das Signal BumpRUX wird ausgegeben, um eine RegOp aus der Stufe Operandenweiterleitung der Ausführungseinheit 253 zu stoßen, falls nicht verboten und eine der Quelloperationen nicht ausgegeben ist oder eine LdOp in der Stufe Operandenweiterleitung ist oder ein Zeitüberschreitungssignal in Reaktion auf die RegOp in der Stufe Operandenweiterleitung angelegt wird, die länger als eine Zählung zur Zeitüberschreitung gehalten wird.
  • Figure 01410002
  • Das Signal BumpRUY zum Ausstoßen einer RegOp aus der zweiten Registereinheit 254 kann nicht verboten werden, aber wird andererseits aus den gleichen Gründen wie das Signal BumpRUX ausgegeben.
  • Figure 01410003
  • Tabelle B.44 Multiplexersteuerung für den Transfer von Operanden
  • Die folgenden Gleichungen fassen die fünf Eingangsauswahlsignale für jeden Operandenmultiplexer zusammen. Die globale Steuerlogik 520 verwendet das Operanden Statussignal auf den Bussen 553, um entweder einen Operandenbus 554 oder einen der Ergebnisbusse 561 bis 564 auszuwählen, um einen Operanden zur Verfügung zu stellen. Für die meisten Operanden wird der Operandenbus 554 ausgewählt, wenn die Quelloperation abgeschlossen ist.
  • Figure 01420001
  • Für die zweiten Operanden von RegOps wird der Operandenbus ausgewählt, wenn die Quelloperation abgeschlossen ist oder der Operand ein unmittelbarer Wert ist.
    Figure 01420002
    wobei die Signale RUXsrc2Imm und RUYsrc2Imm anzeigen, dass der src2 Operand ein unmittelbarer Wert ist.
  • Figure 01420003
  • Der Ergebnisbus von jener der Ausführungseinheiten 251 bis 254, welche die Quelloperation ausführen würde, wird ausgewählt, wenn der Operandenbus 554 nicht ausgewählt ist.
  • Figure 01420004
  • Der ausgewählte Operand kann ungültig sein. Eine Ausführungseinheit wird dadurch gehindert, den ungültigen Operanden auszuführen, dass die dazugehörige Operation daran gehindert wird, von der Stufe Operandenweiterleitung 440 zu der Stufe Ausführung 450 weiter zu schreiten.
  • Tabelle 8.45 Identifizierung eines ungültigen Operanden
  • Die globale Steuerlogik 520 verwendet die Operanden Statussignale von dem Bus 553, um die Signale OprndInvld_XXsrcY zu erzeugen, die anzeigen, ob ein Operand srcY (Y = {1, 2}) für eine Ausführungseinheit XX (xx = {LU, SU, RUX, RUY}) ist.
  • Figure 01430001
  • Tabelle B.46 Haltesignal Logik
  • Die Haltesignale SC_HoldXX0 werden erzeugt, um eine Operation daran zu hindern, zu der Stufe Ausführung 450 weiter zu gelangen, wenn die benötigten Operanden nicht zur Verfügung stehen. StOps ist es erlaubt, zu der Stufe Ausführung 450 zu gelangen, sogar wenn der Datenoperand noch nicht zur Verfügung steht, weil der Datenoperand nicht bis zur Stufe zweite Ausführung 460 benötigt wird. Jedoch hält das Signal SC_HoldSU2 die Operation in der Stufe Ausführung 460, wenn der Datenoperand immer noch ungültig ist.
  • Figure 01430002
  • Tabelle B.47 Gruppen von Status Flags
  • Die Standard x86 Status Flagbits OF, SF. ZF, PF, CF, EZF und ECF sind in vier Gruppen unterteilt, die Bits des Signals STATUSV und des Felds Stat-Mod wie folgt entsprechen.
  • Figure 01430003
  • Figure 01440001
  • Tabelle B.48 Abrufen der Status Flags
  • Jeder der Einträge 16 bis 23 erzeugt die Signale StatInfo_1, StatInfo_2, StatInfo_3 und StatInfo_4, die den vier Gruppen von Flags entsprechen und die Status Flags und ein Gültigkeitsbit für die vier Gruppen von Flags anzeigen. Jedes beliebige oder mehrere der Signale StatInfo_1, StatInfo_2, StatInfo_3 und StatInfo_4 werden benutzt, um die Signale STATUS und STATUSV zu erzeugen, wenn der Eintrag von einer Abtastungskette für eine entsprechende Gruppe ausgewählt ist. Im folgenden zeigt der Präfix "OPj:" einen Feld- oder Signalformeintrag j an.
  • Figure 01440002
  • Das architekturisierte Statusflagregister erzeugt die Signale FlgStatInfo_1, FlgStatInfo_2, FlgStatInfo_3 und FlgStatInfo_4, von denen jedes verwendet wird, um die Signale STATUS und STATUSV zu erzeugen, wenn von einer Abtastungskette kein Eintrag für eine entsprechende Gruppe ausgewählt ist.
  • Figure 01440003
  • Die folgende Logik stellt vier Abtastungsketten ohne Vorausschau dar, um einen Eintrag zur Bereitstellung einer Gruppe von Flags zu finden.
  • Figure 01440004
  • Figure 01450001
  • Die Informationssignale für die Ausgangsstatusflags sind:
  • Figure 01450002
  • Tabelle B.49 Behandlung cc-RegOp
  • Ein Signal CCDepInRUX_0 zeigt an, ob sich eine cc-dep RegOp in der Stufe Operandenweiterleitung der Registereinheit RUX befindet, und wird von Pipelineregistern erzeugt, die Operationsinformation und Gültigkeit Bits für die Operation in der Stufe Operandenweiterleitung enthalten.
  • Figure 01460001
  • Ein Signal UnexecCCDepInQ3 zeigt an, ob sich eine nicht ausgeführte cc-dep RegOp in Zeile 3 befindet und wird von den Typ und Status Bits in den Einträgen von Zeile 3 erzeugt.
  • Figure 01460002
  • Die folgende Logik bestimmt und erzeugt ein Signal StatV, das anzeigt, ob in der Stufe Operandenweiterleitung die für die RegOp erforderliche Status Bit Gruppe gültig ist.
  • Figure 01460003
  • Das Signal StrtExecCCDep verfolgt, wenn sich eine nicht ausgeführte cc-dep RegOp in Zeile 3 befindet.
  • Figure 01460004
  • Das Signal UnexecCCDepInQ4 verfolgt, wenn sich eine nicht ausgeführte cc-dep RegOp in Zeile 4 befindet.
  • Figure 01470001
  • Das Signal SC_HoldStatus hält eine Kopie der Werte der Status Flags an dem Eingang der Registereinheit RUX.
  • Figure 01470002
  • Das Signal StatusInvld_RUX hält eine RegOp Ausführung.
  • Figure 01470003
  • Das Signal HoldOpQ3 hält einen Op Quad vom Ausschieben aus der Zeile 3 des Ablauplaners.
  • Figure 01470004
  • Das Signal RUX_NoStatMod; von der RUX Einheit, zeigt an, dass die ausgeführte Operation die Status Flags nicht ändert. Eine zyklusverzögerte Version, genannt NoStatMod.
  • Tabelle B.50 Behandlung BRCOND
  • Die folgenden Gleichungen beschreiben die Behandlung von BRCOND. Es wird unten Bezug genommen auf die Signale DTF und SSTF, welche Signale sind, die Breakpoint beziehungsweise Einzelschritt Fänge anzeigen. Ein Signal MDD, für "mehrfache Dekodierungsverhinderung", kann zum Debuggen verwendet werden, um zu verhindern, dass zu einem Zeitpunkt mehr als ein Makrobefehl in den Ablaufplaner 280 eingefügt wird.
  • Die Behandlung von BRCOND bestimmt, ob sich eine BRCOND in Zeile 4 befindet. Das Signal BRCONDj zeigt an, ob eine OPj eine nicht bewertete BRCOND ist.
    Figure 01480001
    wobei j die Nummer des Eintrags ist und Type, OpInfo und 53 Felder des Eintrags j sind. Das Signal BRCONDInQ4 zeigt an, ob die Zeile 4 eine BRCOND enthält.
  • Figure 01480002
  • Falls eine BRCOND in Zeile 4 ist, ist der vorher gesagte Bedingungscode (SpecOp.cc) von dem Feld OpInfo des Eintrags, der die BRCOND enthält.
  • Figure 01480003
  • Werte des Signals CondCode[4:1] sind wie folgt definiert. (Das Bit CondCode[0] dreht die Richtung.)
  • Figure 01480004
  • Das Signal CondV zeigt an, ob die für die Bewertung von BRCOND erforderlichen Status Bits gültig sind.
  • Figure 01490001
  • Das Signal HoldOpQ4A ist zur Verhinderung des Schiebens der Op Quad in Zeile 4, wenn eine BRCOND in Zeile 4 ist und die für die Bewertung erforderliche Bedingung ungültig ist.
  • Figure 01490002
  • Das Signal CondVal zeigt an, dass der vorher gesagte Wert CondCode[0] falsch vorher gesagt war.
    Figure 01490003
    Figure 01500001
    wobei das Signal IP definiert ist als
    Figure 01500002
    und anzeigt, ob irgendwelche aktiven h/w Interruptanforderungen vorhanden sind.
  • Das Signal SC_Resolve zeigt eine bedingte Auflösungsverzweigung an.
  • Figure 01500003
  • Ein Register zeichnet das Signal Resolved auf, das eine Auflösung einer BRCOND in dem Quad 4 anzeigt.
  • Figure 01500004
  • Die x86 MOVS (bewege Zeichenkette) Befehle werden in einer Emcodierungsschleife von Operationen dekodiert. Um die Geschwindigkeit zu verbessern, mit der MOVS Befehle ausgeführt werden, werden vollständige 32-Bit Transfers durchgeführt, bis ein Bytezähler für die Schleife kleiner als 4 ist. Eine bedingte BRCOND wird bei der Überprüfung des Zähler für den MOVS verwendet. Das Signal TermMOVS beendet die Emcodierungsschleife, wenn das Bewegen der Zeichenkette fast abgeschlossen ist.
  • Figure 01500005
  • Figure 01510001
  • Das Signal BrVecAddr von dem Feld DestVal für eine BRCOND zeigt die Emcode oder Befehl Einsprungadresse an, die zu benutzen ist, wenn die Verzweigung falsch vorher gesagt wurde.
  • Figure 01510002
  • Die Signale SC_OldRASPtr, SC_OldBPTInfo und SC_RestartAddr werden übermittelt, um den Befehlsdekodierer 240 erneut zu starten. Ein Neustart kann in Reaktion auf eine falsch vorher gesagte Verzweigung oder einen Fehler erzeugt werden. Das Signal SC_OldRASPtr von dem Feld RASPtr eines falsch vorher gesagten oder fehlerbehafteten Eintrags dient zum Wiederherstellen des RAS TOS Zeigers. Das Signal SC OldBPTInfo zeigt die korrekte Information der Tabelle zur Verzweigungsvorhersage zum Korrigieren der Tabelle zur Verzweigungsvorhersage an. Das Signal SC RestartAddr zeigt den Programmzähler nach dem Neustart an.
  • Figure 01510003
  • Die Signale BrVec2Emc und BrVec2Dec zeigen an, dass ein Neustart erforderlich ist wegen einer falsch vorher gesagten BRCOND, für den Fall einer BRCOND von dem Emcodierer oder MacDec 252.
  • Figure 01520001
  • Ein Register zeichnet eine Fehlvorhersage auf:
  • Figure 01520002
  • Wenn eine BRCOND korrekt vorher gesagt wurde, wird die BRCOND wie folgt als abgeschlossen markiert.
  • Figure 01520003
  • Eine erfolgreich aufgelöste BRCOND kann für mehr als einen Zyklus in Zeile 4 bleiben, weil Zeile 5 nicht fähig zum Schieben ist, und damit Zeile 4 daran hindert, runter zu schieben. Während dieser Zeit wird das Signal SC_Resolve angelegt und eines der Signale BrVec2XX auf dem Bus 558 bleibt für die gesamte Zeit angelegt (im Gegensatz zu nur dem ersten Zyklus). Der Befehlsdekodierer 240 hält jeden Takt an dem Neustarten fest, bis das Signal BrVec2XX ausschaltet. Alle anderen zusammenhängenden Signale, wie die Einsprungadresse, behalten während dieser Zeit richtige Werte.
  • Tabelle B.51 Behandlung nicht abbrechbare RegOp
  • Das Signal NonAbInRU_0 wird angelegt, um anzuzeigen, dass eine nicht abbrechbare RegOp in der RUX Stufe Operandenweiterleitung ist.
  • Figure 01520004
  • Das Signal UnexecNonAbInQ4 wird ausgegeben, um anzuzeigen, dass eine nicht abbrechbare RegOp in Zeile 4 des Ablaufplaners 280 ist, und wird von den Feldern Type, OpInfo und dem Status der Einträge 16 bis 19 erzeugt.
  • Figure 01530001
  • Das Signal NonAbSync wird verwendet, um das Vorrücken von der RUX Stufe Operandenweiterleitung anzuhalten, falls eine nicht abbrechbare RegOp in der RUX Stufe Operandenweiterleitung und nicht in Zeile 4 ist oder eine vorhergehende BRCOND falsch vorher gesagt wurde oder ein Fang anhängig ist.
  • Figure 01530002
  • Die nicht abbrechbare RegOp wird daran gehindert, aus der Zeile 4 rauszuschieben, bis sie zu der RUX Stufe Ausführung vorrückt.
  • Figure 01530003
  • Tabelle B.52 Handhabungslogik für selbstmodifizierenden Code
  • Die Handhabungslogik für selbstmodifizierenden Code macht die folgenden Vergleiche, um die Möglichkeit zu eliminieren, dass Code modifiziert worden ist.
  • Figure 01530004
  • Figure 01540001
  • Tabelle B.53 Übergabe an die Registerdatei
  • Die folgenden Gleichungen fassen die Schreibfreigabe für die Registerdatei und Änderungen an dem DestBM Feld und dem Signal OprndMatch XXsrcY für jede Operation von einem Op Quad zusammen. Ergebnisse der Operation, die von dem Signal RegCmtSel zur Übergabe ausgewählt werden, sind von Zeile 4 oder 5.
  • Figure 01540002
  • Das Signal CmtInh verhindert eine Übergabe, falls eine Grenzverletzung für eine Operation in Zeile 5 auftritt oder ein Fang anhängig ist. Das Signal RegCmtInh verhindert die Übergabe eines Registers.
  • Figure 01540003
  • Die Signale WrEnbli geben die Übergabe an die Registerdatei 290 frei, wenn keine Grenzverletzung in dem zu übergebenden Op Quad ist und ältere Operationen in der Zeile älter sind und daher auch übergeben werden.
  • Figure 01540004
  • Figure 01550001
  • Die Byte Merkmale DestBM sind in dem Zyklus, in dem die Ergebnisse der Registerdatei 290 übergeben werden, frei.
  • Figure 01550002
  • Die Signal OprndMatch XXsrcY werden wirksam abgebildet, so dass die Registerdatei 290 die Operanden zur Verfügung stellt.
  • Figure 01550003
  • Tabelle B.54 Übergabe Status Flags
  • Die folgende Gleichung fasst die kumulative Erzeugung des Ergebnisses oder den Auswahlprozess für eine Statusgruppe zusammen. Ähnliche Prozesse werden unabhängig für jede Statusgruppe angewendet.
  • Figure 01560001
  • Tabelle B.55 Übergabe StOp
  • Das Signal StCmtSel zeigt an, welcher der Einträge 23 bis 16 die zur Übergabe ausgewählte StOp enthält. Der älteste Eintrag, der eine nicht übergebene StOp enthält, wird ausgewählt.
  • Figure 01560002
  • StCmtSel entspricht b0000 bis b0111, wenn Eintrag 23 bis 16 ausgewählt sind. StCmtSel entspricht b1111, wenn kein Eintrag ausgewählt ist.
  • Das Signal CmtMask hat acht Bit, die den acht Einträgen in den letzten zwei Zeilen des Ablaufplaners 280 entsprechen. Die Bits, die dem ältesten Eintrag bis zu dem gewählten Eintrag entsprechen sind Null und die verbleibenden Bits sind Eins.
  • Figure 01560003
  • Das Signal CmtCiaCda zeigt die an, dass die ausgewählte StOp ein CIA oder ein CDA Befehl ist.
  • Figure 01570001
  • Das Signal StCmtInh verhindert die Übergabe einer StOp, wenn alle Übergaben verhindert sind,
  • Figure 01570002
  • Die Signale StCmtV beziehungsweise Q5StCmtV zeigen an, ob eine StOp und eine StOp in Zeile 5 in diesem Zyklus für die Übergabe bereit sind. Es gibt keine Übergabe einer StOp, wenn keine StOp ausgewählt wurde, die Übergabe von StOps verhindert ist, die ausgewählt StOp nicht abgeschlossen wurde oder ältere StOps nicht abgeschlossen wurden.
  • Figure 01570003
  • Das Signal StAdv zeigt an, ob eine StOp zu Stufe 2 der Speicherübergabepipeline vorrücken kann.
  • Figure 01570004
  • Die Signale StRetire und Q5StRetire zeigen an, ob irgendeine der Zeile 5 StOp diesen Zyklus übergeben wird.
  • Figure 01580001
  • Das Signal NewUncmtStOp identifiziert alle StOps in den unteren zwei Zeilen, die noch nicht übermittelt worden sind und werden.
  • Figure 01580002
  • Wenn eine StOp übergeben wird, werden die UncmtStOp Bits wie folgt aktualisiert.
  • Figure 01580003
  • Das Signal AllStCmt zeigt an, ob alle in den Speicher schreibenden StOps in Zeile 5 übergeben worden sind oder erfolgreich übertragen werden.
  • Figure 01580004
  • Das Signal SC_HoldSC1 zeigt an, ob die OCU 260 glaubt, dass die Speicherübergabe bereit ist, zu Stufe 2 vorzurücken.
  • Figure 01580005
  • Die Speichereinheit 252 erzeugt ein Signal SUViol, das einen Fehler für eine StOp anzeigt, die in der zweiten Ausführungsstufe stecken geblieben ist. Ein Abbruch wird erzeugt, wenn die ausgewählte StOp in der zweiten Ausführungsstufe stecken geblieben ist und damit den Fehler veranlasst hat.
  • Figure 01590001
  • Tabelle B.56 Zurückziehen von Op Quads
  • Die folgende Gleichung fasst die Op Quad Rückzugssteuerlogik der OCU zusammen.
  • Figure 01590002
  • Das Signal OpQRetire kann für denselben Op Quad für mehrere Zyklen ausgegeben werden. Dies geschieht, wenn ein Schieben des unteren Op Quads zeitweise verhindert wird.
  • Wenn der Op Quad zurück gezogen oder abgebrochen ist, werden die angesammelten Status Flags übergeben.
  • Figure 01590003
  • Tabelle B.57 Abbruch LdOp
  • OCU 260 erzeugt ein Abbruchsignal LdAbort für eine LdOp in Zeile 5, wenn sie nicht abgeschlossen ist und alle älteren Operationen abgeschlossen und übergeben worden sind.
  • Figure 01590004
  • Tabelle B.58 FAULT OP Abbruch
  • Die folgende Gleichung fasst die Behandlungslogik für FAULT Operation der OCU zusammen.
  • Figure 01600001
  • Tabelle B.59 LDDHA/LDAHA Behandlungslogik
  • Die OCU behandelt LDDHA und LDAHA Operationen, wenn sie den Eintrag 23 erreichen, durch Laden von DestVal in das geeignete Standardwertbehandler-Adressregister.
  • Figure 01600002
  • Das Signal EffAltFltVecAddr stellt die neue alternative Behandleradresse für Fehler auf Ops innerhalb des gleichen Op Qquads wie eine LDAHA Operation zur Verfügung.
  • Figure 01600003
  • Das Wechseln und das Umschalten zwischen den Behandleradressen wird mit der Erkennung von Fehlern an umgebenden Operationen synchronisiert.
  • Figure 01600004
  • OPQ bezieht sich auch ein Op Quad Feld.
  • Tabelle B.60 Behandlung Grenzverletzungen Verzweigungsziel
  • Falls ein gültiger Op Quad, der markiert ist, eine Grenzverletzung des Ver zweigungsziels zu haben, Zeile 5 erreicht, erzeugt die OCU 260 ein Abbruchsignal LimAbort.
  • Figure 01610001
  • Tabelle B.61 Abbruch für falsch vorher gesagte BRCOND
  • Die OCU 260 erzeugt ein Abbruchssignal BrAbort für eine falsch vorher gesagte BRCOND, wenn alle Operationen, die einer nicht abgeschlossenen BRCOND in Zeile 5 vorangehen, abgeschlossen sind.
  • Figure 01610002
  • Die Übergabe der folgenden Operationen wird durch den Status der BRCOND als nicht angeschlossen (das heißt ~S3) verhindert. Auch wird BrAbort angelegt, wenn F1tAbort angelegt wird, aber dies ist harmlos.
  • Tabelle B.62 Abbruchszykluslogik
  • Das Signal ExcpAbort zeigt einen Abbruch an, wenn eine beliebige Abbruchbedingung eine Einsprungadresse für einen Neustart benötigt.
  • Figure 01610003
  • Das Signal SC_EAbort enthält auch Abbrüche für falsch vorher gesagte BRCOND.
  • Figure 01610004
  • Der Abbruch wird von dem Signal SC_Abort an einer Taktflanke eingeleitet.
  • Figure 01620001
  • Die Informationen, die für die verschiedenen Anlässe des Abbruchs erforderlich sind, werden wie folgt zur Verfügung gestellt.
  • Figure 01620002
  • Verriegeln in SR4:
  • Figure 01620003
  • Wähle Emcode Einsprungadresse aus:
  • Figure 01620004

Claims (18)

  1. Verarbeitungssystem mit: einer ersten Ausführungseinheit (253) zum Ausführen einer ersten Klasse von Operationen; einer zweiten Ausführungseinheit (254) zum Ausführen einer zweiten. Klasse von Operationen, wobei die zweite Klasse die erste Klasse überlappt; Eintragsstellen (540) zum Speichern von Information, die von dem Verarbeitungssystem auszuführende Operationen beschreibt, wobei die Eintragsstellen sequentiell geordnet sind; und einer Abtast-Kette (900) zum Wählen von Operationen aus den Eintragsstellen; dadurch gekennzeichnet, dass die Abtast-Kette aufweist: eine an jeder Eintragsstelle vorgesehene Erzeugungsschaltung (540, IssuableToRUX), die ein Abtast-Bit erzeugt, falls der betreffende Eintrag Information enthält, die eine Operation in der ersten Klasse beschreibt; eine Ausbreitungsschaltung (910, 920, 930, 940), die das Abtast-Bit von einer ersten Eintragsstelle zu Eintragsstellen weitergibt, die in sequentieller Reihenfolge auf die erste Eintragsstelle folgen, wobei die erste Eintragsstelle in sequentieller Reihenfolge die erste von sämtlichen Ein tragsstellen ist, die Information identifizieren, welche eine Operation in der ersten Klasse beschreibt; und eine an jeder Eintragsstelle vorgesehene Wählschaltung (9c), um die an dieser Eintragsstelle befindliche Operation zur Ausführung durch die zweite Ausführungseinheit zu wählen, falls die Ausbreitungsschaltung das Abtast-Bit an die Eintragsstelle weitergibt und die Eintragsstelle Information speichert, die eine Operation in der zweiten Klasse beschreibt.
  2. Verarbeitungssystem nach Anspruch 1, bei dem die Ausbreitungsschaltung (910, 920, 930) das Abtast-Bit weitergibt, indem sie parallel ein Set von Ausbreitungs-Termen (Pgrp,PXY) bestimmt, bei dem jeder Gruppenausbreitungs-Term angibt, ob ein Abtast-Bit, das sich in eine entsprechende Gruppe von Eintragsstellen ausbreitet, sich aus der entsprechenden Gruppe von Eintragsstellen heraus ausbreiten würde.
  3. Verarbeitungssystem nach Anspruch 2, bei dem die Ausbreitungsschaltung parallel ein Set von Gruppenerzeugungs-Termen (Ggrp,GXY) bestimmt, wobei ein Gruppenerzeugungs-Term aktiviert wird, falls ein Eintrag in der entsprechenden Gruppe ein Abtast-Bit erzeugt und falls kein folgender Eintrag in der entsprechenden Gruppe Information speichert, die eine Operation in der zweiten Klasse beschreibt.
  4. Verarbeitungssystem nach Anspruch 3, bei dem die Ausbreitungsschaltung parallel ein Set von Nur-Gruppen-Termen (Ogrp,OXY) bestimmt, wobei ein Nur-Gruppen-Term aktiviert wird, falls ein Eintrag in der entsprechenden Gruppe ein Abtast-Bit erzeugt.
  5. Verarbeitungssystem nach einem der vorherigen Ansprüche, ferner mit einem Speicher-Untersystem (120), das Daten und Instruktionen für das Verarbeitungssystem speichert.
  6. Verarbeitungssystem nach Anspruch 5, bei dem das Verarbeitungssystem ein Computer-Motherboard (101) bildet.
  7. Verarbeitungssystem nach Anspruch 6, bei dem das Motherboard (101) ferner einen Backplane-Bus zum Anschluss einer oder mehrerer Einrichtungen an mit dem Motherboard verbundene Karten aufweist.
  8. Verarbeitungssystem nach Anspruch 1, bei dem jede Eintragsstelle eine Schaltung aufweist, die als Reaktion darauf, dass ein der Eintragsstelle zugeordnetes Objekt von einem gewählten Typ ist und ein Objekt in der zweiten Klasse beschreibt, ein Kill-Signal (IssuableToRUY) aktiviert, wobei die Ausbreitungsschaltung mehrere Gruppen-Term-Schaltungen aufweist, die in Entsprechung zu einer Sequenz von Gruppen von Eintragsstellen stehen, wobei jede Gruppen-Term-Schaltung mit den Eintragsstellen in einer entsprechenden Gruppe verbunden ist und als Reaktion darauf, dass eine Eintragsstelle in der entsprechenden Gruppe ein Kill-Signal aktiviert, ein Gruppen-Kill-Signal (Kgrp) ausgibt; wobei die Wählschaltung mehrere Eintragsstellen-Wählschaltungen in Entsprechung zu der Sequenz von Gruppen aufweist, wobei jede Eintragsstellen-Wählschaltung, falls sie nicht deaktiviert ist, eine Eintragsstelle wählt, die sich in der entsprechenden Gruppe befindet und einem Objekt zugewiesen ist, das vom gewählten Typ ist und sich in der zweiten Klasse befindet; und wobei die Ausbreitungs- und Wählschaltung ferner eine Gruppen-Wählschaltung aufweist, die mit den Gruppen-Term-Schaltungen und den Eintragsstellen-Wählschaltungen verbunden ist, wobei für jede Eintragsstellen-Wählschaltung die Gruppen-Wählschaltung diese Eintragsstellen-Wählschaltung deaktiviert, falls der der Eintragsstellen-Wählschaltung entsprechenden Gruppe in der Sequenz von Gruppen eine Gruppe vorausgeht, für die die Gruppen-Term-Schaltung ein Gruppen-Kill-Signal aktiviert.
  9. Wählschaltung (900) mit: einem Array von Eintragsstellen (540), wobei die Eintragsstellen eine sequentielle Reihenfolge aufweisen und jede Eintragsstelle eine Schaltung, die als Reaktion darauf, dass ein der Eintragsstelle zugewiesenes Objekt von einem ersten Typ ist, ein Erzeugungssignal (IssuableToRUX) aktiviert, und eine Schaltung aufweist, die als Reaktion darauf, dass das Objekt von einem zweiten Typ ist, ein Kill-Signal aktiviert; mehreren Gruppen-Term-Schaltungen (910), die in Entsprechung zu einer Sequenz von Gruppen von Eintragsstellen stehen, wobei jede Gruppen-Term-Schaltung: ein Gruppenerzeugungssignal (Ggrp) aktiviert, falls innerhalb der entsprechenden Gruppe eine erste Eintragsstelle ein Erzeugungssignal aktiviert und keine Eintragsstelle, die der ersten Eintragsstelle sequentiell folgt, ein Kill-Signal aktiviert; ein Nur-Gruppen-Signal (Ogrp) als Reaktion darauf aktiviert, dass eine Eintragsstelle in der entsprechenden Gruppe ein Erzeugungssignal aktiviert; und ein Gruppen-Kill-Signal (Kgrp) als Reaktion darauf aktiviert, dass eine Eintragsstelle in der entsprechenden Gruppe ein Kill-Signal aktiviert; einer mit den Gruppen-Term-Schaltungen verbundenen Ausbreitungsschaltung (920, 930, 940), die für jede Gruppe ein O-Term-Signal erzeugt, das als Reaktion darauf aktiviert wird, dass eine vorhergehende Gruppe ein Nur-Gruppen-Signal aktiviert, und ein Abtast-Bit-Signal aktiviert, das aktiviert wird, falls eine erste vorhergehende Gruppe ein Gruppenerzeugungssignal aktiviert und keine vorhergehende Gruppe, die auf die erste vorhergehende Gruppe folgt, ein Gruppen-Kill-Signal aktiviert; und mehreren Eintragsstellen-Wählschaltungen (9C) in Entsprechung zu der Sequenz von Gruppen, wobei jede Eintragsstellen-Wählschaltung derart angeordnet ist, dass sie von der Ausbreitungsschaltung das Abtast-Bit und die Nur-Gruppen-Signale für die entsprechende Gruppe empfängt, wobei jede Eintragsstellen-Wählschaltung eine Eintragsstelle wählt, die sich in der entsprechenden Gruppe befindet, falls diese Eintragsstelle ein Kill-Signal aktiviert und entweder das Abtast-Bit-Signal aktiviert ist oder das Nur-Signal nicht aktiviert ist und eine Eintragsstelle, die sich in der entsprechenden Gruppe befindet und der gewählten Eintragsstelle vorhergeht, ein Erzeugungssignal aktiviert.
  10. Wählschaltung nach Anspruch 9 in einem Verarbeitungssystem, mit: einer erste Ausführungs-Schaltung (253), die eine erste Klasse von Operationen ausführen kann, welche durch Eintragsstellen des ersten Typs beschrieben wird; einer zweite Ausführungs-Schaltung (254), die eine zweite Klasse von Operationen ausführen kann, welche durch Eintragsstellen des zweiten Typs beschrieben wird, wobei die zweite Klasse die erste Klasse überlappt.
  11. Wählschaltung nach Anspruch 10, bei der das Verarbeitungssystem ferner ein Speicher-Untersystem (120) aufweist, das Daten und Instruktionen für das Verarbeitungssystem speichert, und bei der das Verarbeitungssystem ein Computer-Motherboard (101) bildet.
  12. Wählschaltung nach Anspruch 11, bei der das Motherboard (101) ferner einen Backplane-Bus zum Anschluss einer oder mehrerer Einrichtungen an mit dem Motherboard verbundenen Karten aufweist.
  13. Verfahren zum gleichzeitigen Auswählen von Operationen zur Ausführung durch erste (253) und zweite (254) Ausführungseinheiten in einem Superskalar-Prozessor (200), wobei die erste Ausführungseinheit eine erste Klasse von Operationen ausführen kann und die zweite Ausführungseinheit eine zweite Klasse von Operationen ausführen kann, welche die erste Klasse überlappt, mit den folgenden Verfahrensschritten: Speichern von Information, die ein Set von Operationen in einem Set sequentieller Eintragsstellen (540) beschreibt; Abtasten der Eintragsstellen in sequentieller Reihenfolge, um eine erste Eintragsstelle zu wählen, die Information speichert, welche eine erste Operation der ersten Klasse beschreibt; Wählen der ersten Operation zur Ausführung durch die erste Ausführungseinheit; Beseitigen eines Abtast-Bit-Signals aus der ersten Eintragsstelle und Fortführung in sequentieller Reihenfolge; Killen des Abtast-Bits durch eine zweite Eintragsstelle, die Information speichert, welche eine zweite Operation, die der zweiten Klasse zugehört, beschreibt; und Wählen der zweiten Operation zur Ausführung durch die zweite Ausführungseinheit.
  14. Verfahren nach Anspruch 13, bei dem das in sequentieller Reihenfolge erfolgende Abtasten der Eintragsstellen umfasst: aus jeder Eintragsstelle, Erzeugen eines Einzel-Eintragsstellen-Erzeugungssignals, das angibt, ob die Information in der Eintragsstelle eine Operation der ersten Klasse beschreibt; Kombinieren der Einzel-Eintragsstellen-Erzeugungssignale zum Erzeugen von Gruppen-Erzeugungssignalen, wobei jedes Gruppen-Erzeugungssignal einer Gruppe von Eintragsstellen entspricht und angibt, ob eine Eintragsstelle in der Gruppe Information enthält, die eine Operation der ersten Klasse beschreibt und derart ausgelegt ist, dass sich das Abtast-Bit aus der Eintragsstelle aus der Gruppe heraus ausbreiten kann, ohne auf eine Eintragsstelle zu treffen, die Information enthält, welche eine Operation der zweiten Klasse beschreibt; Verwenden der Gruppen-Erzeugungssignale, um festzustellen, welche Gruppe von Eintragsstellen die erste Eintragsstelle enthält; und Identifizieren der ersten Eintragsstelle unter den Eintragsstellen in der Gruppe, welche die erste Eintragsstelle enthält.
  15. Verfahren nach Anspruch 14, bei dem das Weitergeben des Abtast-Bits umfasst: aus jeder Eintragsstelle, Erzeugen eines Einzel-Eintragsstellen-Ausbreitungssignals, das angibt, ob die Information in der Eintragsstelle eine Operation der zweiten Klasse beschreibt; Kombinieren der Einzel-Eintragsstellen-Ausbreitungssignale zum Erzeugen von Gruppen-Ausbreitungssignalen, wobei jedes Gruppen-Ausbreitungssignal mehreren Eintragsstellen entspricht und angibt, ob Information in den mehreren Eintragsstellen eine Operation der zweiten Klasse beschreibt; Verwenden der Gruppen-Ausbreitungssignale und der Gruppen-Erzeugungssignale, um eine Gruppe von Eintragsstellen zu identifizieren, welche die zweite Eintragsstelle enthält; und Identifizieren der zweiten Eintragsstelle unter den Eintragsstellen in der Gruppe, welche die zweite Eintragsstelle enthält.
  16. Verfahren nach Anspruch 14 oder Anspruch 15, ferner mit dem Kombinieren der Einzel-Eintragsstellen-Erzeugungssignale zum Erzeugen von Nur-Gruppen-Term-Signalen, von denen jedes einer Gruppe von Einträgen entspricht und angibt, ob Information in der Gruppe von Eintragsstellen eine Operation der ersten Klasse beschreibt.
  17. Verfahren nach Anspruch 16, bei dem die Verwendung der Gruppen-Erzeugungssignale das Verwenden der Gruppen-Erzeugungssignale mit Nur-Gruppen-Term-Signalen umfasst, um die Gruppe von Eintragsstellen zu identifizieren, welche die erste Eintragsstelle enthält.
  18. Verfahren nach einem der Ansprüche 13 bis 17, bei dem die erste Klasse sämtliche Operationen in der zweiten Klasse enthält.
DE69628932T 1995-10-06 1996-10-04 Abtastkette zur schnellen feststellung eines ersten und zweiten objektes von ausgewählten typen in einer sequentiellen liste Expired - Lifetime DE69628932T2 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US506995P 1995-10-06 1995-10-06
US5069P 1995-10-06
US502195P 1995-10-10 1995-10-10
US5021P 1995-10-10
US592722 1996-01-26
US08/592,722 US5745724A (en) 1996-01-26 1996-01-26 Scan chain for rapidly identifying first or second objects of selected types in a sequential list
US08/650,055 US5881261A (en) 1996-01-26 1996-05-16 Processing system that rapidly indentifies first or second operations of selected types for execution
US650055 1996-05-16
PCT/US1996/015742 WO1997013200A1 (en) 1995-10-06 1996-10-04 Scan chain for rapidly identifying first or second objects of selected types in a sequential list

Publications (2)

Publication Number Publication Date
DE69628932D1 DE69628932D1 (de) 2003-08-07
DE69628932T2 true DE69628932T2 (de) 2004-04-22

Family

ID=27485442

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69628932T Expired - Lifetime DE69628932T2 (de) 1995-10-06 1996-10-04 Abtastkette zur schnellen feststellung eines ersten und zweiten objektes von ausgewählten typen in einer sequentiellen liste

Country Status (5)

Country Link
EP (1) EP0853787B1 (de)
JP (1) JPH11510290A (de)
AU (1) AU7383596A (de)
DE (1) DE69628932T2 (de)
WO (1) WO1997013200A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3493866B2 (ja) * 1995-12-27 2004-02-03 ライオン株式会社 発泡性口腔用組成物

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100248903B1 (ko) * 1992-09-29 2000-03-15 야스카와 히데아키 수퍼스칼라마이크로프로세서에서의 적재 및 저장연산처리방법 및 시스템

Also Published As

Publication number Publication date
WO1997013200A1 (en) 1997-04-10
EP0853787A1 (de) 1998-07-22
JPH11510290A (ja) 1999-09-07
AU7383596A (en) 1997-04-28
DE69628932D1 (de) 2003-08-07
EP0853787B1 (de) 2003-07-02

Similar Documents

Publication Publication Date Title
DE69629495T2 (de) Vereinheitlichter multifunktions-operationsverteiler für die ungeordnete befehlsexekution in einem superskalaren prozessor
DE69433339T2 (de) Lade-/Speicherfunktionseinheiten und Datencachespeicher für Mikroprozessoren
DE69629383T2 (de) Superskalarer mikroprozessor mit risc86 befehlssatz
DE69737423T2 (de) Verfahren und gerät zum replizieren von datenspeicherung in einem fortgeschrittenen mikroprozessor
DE69534148T2 (de) Rechnersystem zur Ausführung von Verzweigungsbefehlen
DE69835100T2 (de) Prozessor konfiguriert um vorausschauende resultate von zusammengefassten übertragungs-, vergleichs- und einfachen arithmetischen befehlen zu produzieren
DE69908193T2 (de) Ausführung von speicher- und ladeoperationen mittels einer linkdatei
DE69727773T2 (de) Verbesserte Verzweigungsvorhersage in einem Pipelinemikroprozessor
DE69932066T2 (de) Mechanismus zur &#34;store-to-load forwarding&#34;
DE69631778T2 (de) Flexible implementierung eines systemverwaltungsmodus in einem prozessor
DE112009000741B4 (de) Vektorbefehle zum Ermöglichen von effizienter Synchronisation und parallelen Reduktionsoperationen
US5799165A (en) Out-of-order processing that removes an issued operation from an execution pipeline upon determining that the operation would cause a lengthy pipeline delay
DE60009151T2 (de) Vorhersage von datenbeförderung von speicher- zum ladebefehl mit untrainierung
DE60010907T2 (de) Sram-steuerungvorrichtung für parallele prozessorarchitektur mit adressen- und befehlswarteschlange und arbiter
DE112004002848B4 (de) Mikroprozessor und Verfahren zum Verifizieren einer Speicherdatei in einem derartigen Mikroprozessor
DE60306937T2 (de) Synchronisierung von pipelines in einem datenverarbeitungsgerät
DE69233493T2 (de) RISC-Prozessor mit erweiterbarer Architektur
DE60036016T2 (de) Schnell multithreading für eng gekoppelte multiprozessoren
DE112007003801B3 (de) Vorrichtung mit einer speichereinheit und einer logik zur bereitstellung eines effizienten mechanismus‘ für transaktionalspeicherausführungen in out-of-order-prozessoren
DE2855106C2 (de) Einrichtung zur Durchführung von bedingten Verzweigungen
DE69233313T2 (de) Hochleistungsarchitektur für RISC-Mikroprozessor
DE69434669T2 (de) Spekulative Befehlswarteschlange für Befehle mit variabler Byteslänge
DE112011101364B4 (de) Fehlerbehebung in Multithread-Code
DE69908175T2 (de) Verbesserte befehlsdekodierung durch paralleldekodierungsalgorithmus
DE112018000848T5 (de) Registerkontextwiederherstellung auf der Grundlage der Wiedergewinnung von Umbenennungsregistern

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