DE69612991T2 - System zur bearbeitung von selbstmodifizierendem kode - Google Patents

Description

Technisches Gebiet
• Die vorliegende Erfindung betrifft Prozessoren und insbesondere ein System zum Handhaben eines selbst-modifizierenden Codes in einem Pipeline-Prozessor.
Stand der Technik
• EP-A-0 159 712 offenbart ein Computersystem mit einer CPU und einem Speichersystem, wobei die CPU einen Cachespeicher aufweist und die CPU nach einem Pipeline-Protokoll betrieben wird. Das Computersystem weist Steuereinrichtungen zum Steuern des Datenflusses in einem derartigen System auf, um das Implementieren einander störender Befehle in der Pipeline zu vermeiden.
• US-A-5 434 987 betrifft ein Verfahren und eine Vorrichtung zum Verhindern des fehlerhaften Holens eines Befehls einer selbst-modifizierenden Codesequenz mit Abhängigkeit von einem gepufferten Speicher.
• Computerprogramme werden üblicherweise unter der vereinfachenden Annahme entwickelt, codiert und kompiliert, daß der sich ergebende Objektcode in sequentieller Folge ausgeführt wird. Trotz dieser Annahme versuchen jedoch moderne Prozessor-Entwicklungsverfahren Möglichkeiten dergleichzeitigen Ausführung von Maschinenbefehlen, d. h. Befehlsparaflelismus, zu nutzen. Um den Rechendurchsatz zu maximieren, können Pipeline-Techniken verwendet werden, um Befehlsparallelismus auf mehrere Stufen einer einzelnen Funktionseinheit oder eines einzelnen Ausführungspfades abzubilden. Im Gegensatz dazu bilden Superskalarverfahren, die eine außerordentliche Befehlsausgabe, eine außerordentliche Befehlsbeendigung und eine spekulative Ausführung eines Befehls aufweisen, Befehlsparallelismus auf mehrere Funktionseinheiten oder Ausführungspfade ab. Moderne Prozessor-Designs nutzen oft sowohl das Pipeline-, als auch das Superskalarverfahren. Die außerordentliche Befehlsausgabe beinhaltet das Ausgeben von Befehlen an Ausführungseinheiten unter geringer Beachtung der tatsächlichen Reihenfolge der Befehle im Ausführungscode. Ein superskalarer Prozessor, der die außerordentliche Ausgabe nutzt, muß nur durch Abhängigkeiten zwischen dem Ausgang (Ergebnisse) eines gegebenen Befehls und den Eingängen (Operanden) nachfolgender Befehle bei der Formulierung seiner Befehlssendesequenz eingeschränkt werden. Das außerordentliche Beenden ist andererseits ein Verfahren, daß es ermöglicht, einen bestimmten Befehl abzuschließen (z. B. seine Ergebnisse zu speichern), bevor ein Befehl abgeschlossen wird, der diesem in der Programmsequenz vorausgeht. Die spekulative Ausführung beinhaltet schließlich die Ausführung einer Befehlssequenz basierend auf vorhergesagten Ergebnissen (z. B. einer Verzweigung) und ermöglicht einem Prozessor, Befehle auszuführen, ohne auf die tatsächliche Auswertung der Verzweigungsbedingungen zu warten. Angenommen, Verzweigungen werden öfter richtig als falsch vorhergesagt, und angenommen, es liegt ein vernünftiges, effizientes Verfahren zum Rückgängigmachen von Ergebnissen einer falschen Vorhersage vor, wird der Befehlsparallelismus (d. h. die Zahl der zur parallelen Ausführung verfügbaren Befehle) üblicherweise durch spekulative Ausführung erhöht (siehe die Analyse in Johnson, Superscalar Processor Design, Prentice-Hall Inc., New Jersey, 1991, S. 63- 77).
• Superskalarverfahren betreffen im wesentlichen die Prozessororganisation unabhängig von dem Befehlssatz und anderen Architekturmerkmalen. Somit ist einer der Vorteile der Superskalarverfahren die Möglichkeit, einen Prozessor zu entwickeln, der mit einer existierenden Prozessorarchitektur codekompatibel ist, beispielsweise mit der x86 Prozessor-Architektur. Viele Superskalarverfahren sind gleichermaßen gut auf RISC- wie aufCISC-Architekturen anwendbar. Wegen der Regelmäßigkeiti vieler der RISC-Architekturen wurden jedoch Superskalarverfahren anfänglich auf RISC-Prozessordesigns angewandt. Insbesondere die Drei-Operanden-Lade/Speicher-Architektur, feste Befehlslängen, begrenzte Adressiermodi, und Register mit fester Breite in Verbindung mit einer RISC-Architektur und einem RISC-Befehlssatz erleichtern das Einzyklus-Decodieren mehrerer Befehle, das erforderlich ist, um mehrere Ausführungseinheiten kontinuierlich mit Arbeit zu versorgen.
• Ein Ansatz für das Entwickeln eines Superskalarprozessors, der mit einer x86- Architektur kompatibel ist, besteht im dynamischen Übersetzen von x86- Befehlen in RISC-Befehle oder Operationen, welche sodann von einem RISC- Kern oder einer RISC-Ausführungsmaschine ausgeführt werden können. Verfahren zum Entwickeln eines derartigen superskalaren RISC-Prozessors sind in Johnson, Superscalar Processor Designs beschrieben.
• Das Ausführen von Befehlen außerhalb der Reihenfolge, d. h. das Ausgeben und Beenden von Befehlen außerhalb der sequentiellen Reihenfolge, kann die Leistung eines superskalaren Prozessors erhöhen, indem es dem superskalaren Prozessor ermöglicht wird, mehrere Ausführungseinheiten parallel zu betreiben und so den Durchsatz zu verbessern. Daher kann ein Steuerprogramm für einen superskalaren Prozessor die Gesamtleistung verbessern, indem es bestimmt, welche Befehle außerhalb der Reihenfolge ausgeführt werden können, und indem es diese Befehle an geeignete Ausführungseinheiten liefert oder sendet. Ein Steuerprogramm für einen superskalaren Prozessor muß ebenfalls Interrupts und Traps verarbeiten. Zahlreiche Prozessorarchitekturen, einschließlich der x86-Prozessorarchitektur, erfordern Kenntnis eines Architekturzustands unmittelbar bevor oder nachdem ein Befehl einen Fehler, ein Interrupt oder eine Trap erzeugt hat. Dies stellt eine Schwierigkeit dar, wenn Befehle außerhalb der sequentiellen Abfolge ausgeführt werden. Das Steuerprogramm muß daher in der Lage sein, Befehle rückgängig zu machen und den Zustand des Systems wiederherzustellen, als ob die Befehle in der sequentiellen Abfolge ausgeführt worden wären. Ein selbst-modifizierender Code stellt eine weitere Verkomplizierung dar. Bei bestimmten Architekturen, einschließlich derjenigen, die der x86-Prozessorarchitektur entsprechen, kann ein Teil eines ausgeführten Programms andere Teile desselben Programms modifizieren. Die modifizierten Befehlssequenzteile können sodann ausgeführt werden.
• Bei bestimmten CISC-Architekturen, die es Programmen ermöglichen, sich selbst zu modifizieren, einschließlich der x86-Prozessorarchitektur, hat sich diese Art fragwürdiger Programmierpraxis innerhalb eines relevanten Teils der existierenden Softwarebasis etabliert. Um die Kompatibilität zu wahren, müssen die neuen Prozessoren infolgedessen nicht nur die unmittelbare Semantik des Befehlssatzes dieser Architektur verwenden, sondern auch erwartetes sekundäres Semantikverhalten. Bei Hochleistungs-Pipeline- Superskalar-Implementierungen kann dies eine bedeutsame und potentiell schwierig zu erfüllende Bedingung sein.
• Es bestehen keine Probleme hinsichtlich des Holens von Befehlen aus dem Speichersubsystem nach dem Beenden des Speicherns in den Befehlsstrom. Wenn jedoch nicht modifizierte Wiedergaben eines Befehls innerhalb der verschiedenen Pipelinestufen oder Funktionseinheiten eines Pipieline-Superskalarprozessors existieren, bestehen Konsistenzprobleme. Das Aufrechterhalten der Konsistenz darf nicht nur die herkömmliche Daten/Befehlscachekonsistenz umfassen, sondern auch die Konsistenz bezüglich der Speicher-Speicherbefehle, die andere Befehle modifizieren, welche kurz danach ausgeführt werden.
• Das Konsistenzproblem ist demjenigen ähnlich, dem man bei herkömmlicheren Daten/Befehlscachestrukturen begegnet, die in Hochleistungsprozessoren verwendet werden, bei denen das Schreiben in den Speicher in geeigneter Weise im Zustand und/oder dem Inhalt jedes betroffenen Cacheeintrags reflektiert werden muß. Jedoch ist das Ausmaß des Problems des selbstmodifizierenden Codes größer. Bei extremen "Speichern-in-den- Befehlsstrom"-Fällen kann auf einen modifizierenden Befehl unmittelbar eine Verzweigung und sodann ein modifizierter Zielbefehl folgen. Insbesondere bei Hochleistungsprozessordesigns mit ausgeprägter Pipelinestruktur kann es wegen der zusätzlichen Hardwareschaltungen und der zusätzlichen Designkomplexität schwierig und kostspielig sein, einen Ausführungspfad zu gewährleisten, der mit demjenigen eines Standardarchitekturprozessors (beispielsweise dem x86-Prozessor) identisch ist.
• Die Pipelineverarbeitung, insbesondere die tiefgehende Pipelineverarbeitung, die bei Hochleistungsimplementierungen von CISC-Architekturen allgemein üblich ist, führtzu großen Befehlsverarbeitungslatenzen und starken Überlappungen zwischen der Verarbeitung aufeinanderfolgender Befehle. Andererseits erfolgt die Ausführung eines Speicherschreibbefehls in solchen Pipelineverarbeitungen im allgemeinen spät. Infolgedessen können Aktionen wie das Holen von Befehlen aus dem Speicher oder Cache und das spekulative Senden von Befehlen an Ausführungspipelines leicht vor dem Abschluß eines Speicherschreibvorgangs erfolgen, der dem geholten oder versendeten Befehl in der Abarbeitungsfolge vorausgeht.
Offenbarung der Erfindung
• Ein Prozessor, der Tags aufweist, die Speicheradressen für Befehle angeben, welche durch Pipelinestufen des Prozessors laufen, und der einen Befehlsdecodierer mit einem Speicherzieladressenpuffer aufweist, ermöglicht es einer Logik die selbst-modifizierende Codes unterstützt, Speicheroperationen zu erkennen, die in den Datenstrom einschreiben, und einen Fehler des selbstmodifizierenden Codes auszulösen.
• Die vorliegende Erfindung ist in den Ansprüchen 1 und 8 beschrieben.
Kurzbeschreibung der Zeichnun en
• Ein besseres Verständnis der vorliegenden Erfindung und eine Verdeutlichung der zahlreichen Aufgaben, Merkmale und Vorteile für den Fachmann ergibt sich aus den beigefügten Zeichnungen.
• Fig. 1 zeigt ein Blockdiagramm eines erfindungsgemäßen Ausführungsbeispiels des superskalaren Computerprozessors, der eine Steuerung der Ausführung außerhalb der Reihenfolge ermöglicht.
• Fig. 2 ist ein Blockdiagramm eines Schedulers gemäß einem Ausführungsbeispiel der Erfindung.
• Fig. 3 ist ein Pipelinestufen-Diagramm zur Darstellung von Architekturstufen bei der Ausführung von Befehlen nach einem Ausführungsbeispiel der Erfindung.
• Fig. 4 ist ein Blockdiagramm zur Darstellung von Komponenten für die Ausführung von Lade- und Speicherbefehlen außerhalb der Reihenfolge gemäß einem Ausführungsbeispiel der Erfindung.
• Fig. 5 ist ein Blockdiagramm eines Computersystems mit einem Prozessor, der die Steuerung der außerhalb der Reihenfolge erfolgenden Ausführung von Lade- und Speicherfunktionen ermöglicht, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
• Die Verwendung gleicher Bezugszeichen in verschiedenen Figuren gibt gleiche oder ähnliche Elemente an.
Beste Art(en) der Ausführung der Erfindung
• Fig. 1 zeigt einen superskalaren Prozessor nach einem Ausführungsbeispiel der vorliegenden Erfindung. Der superskalare Prozessor 100 weist eine Ausführungsmaschine 150, die eine Architektur mit reduzierter Befehlssatzberechnung (RISC) verwendet, einen Befehlsdecodierer 140, Caches und ein Systeminterface 120 auf, das Zugang zu einem Adressenraum im Speichersubsystem 122 und zu (nicht dargestellten) Vorrichtungen auf lokalen Bussen ermöglicht.
• Der superskalare Prozessor 100 weist einen Cache auf, der in dem hier beschriebenen Ausführungsbeispiel in separate Daten- und Befehlsbereiche unterteilt ist. Der Datencache 170 und der Befehlscache 130 sind (über Cachesteuerlogik 160 und das Systeminterface 120) mit dem Adressenraum im Speichersubsystem 122 verbunden, das den Hauptspeicher und optional weitere Cachelevel, beispielsweise einen L2 Cache, aufweist. Der Zugriff auf einen L2 Cache, d. h. aufdie L2 Cachesteuerlogik und einen (nicht dargestellten) L2 Datenbereich, kann über das Systeminterface 120 erfolgen. Alternativ kann L2 Cachesteuerlogik zwischen der Cachesteuerlogik 160 (bei L1) und dem Systeminterface 120 vorgesehen sein.
• Cachesystemdesigns sind im Stand der Technik bekannt. Im Bereich der Caches sind insbesondere geeignete Designs bekannt, die geteilte "Harvard Architecture"-Befehls- und Datencaches (wie beispielsweise 170 und 130) und Mehrstufen-Cachehierarchien verwenden. In den meisten Belangen weist das Cachesubsystem des superskalaren Prozessors 100 (d. h. der Datencache 170, der Befehlscache 130, die Cachesteuerlogik 160 und ein optionaler L2 Cache) eines der geeigneten Designs auf. Aus Gründe, die nichts mit der Cache-Leistung zu tun haben, ist der Befehlscache 130 in die (nicht dargestellte) Vordecodierlogik integriert. Diese integrierte Vordecodierlogik identifiziert x86 Befehlsgrenzen im geholten Befehlsstrom und erleichtert das schnelle Decodieren von Befehlen durch den Befehlsdecodierer 140.
• Wie in Fig. 1 dargestellt, werden Befehlssequenzen aus dem Speichersubsystem in den Befehlscache 130 zur erwarteten Durchführung durch die Ausführungsmaschine 150 geladen. Bei dem Ausführungsbeispiel des Prozessors 100 nach Fig. 1 sind die Befehle im Befehlscache 130 CISC-Befehle, die aus einem komplexen Befehlssatz ausgewählt sind, beispielsweise dem x86-Befehlssatz, der von Prozessoren implementiert wird, die der x86-Prozessorarchitektur entsprechen. Der Befehlsdecodierer 140 wandelt CISC-Befehle, die vom Befehlscache 130 aus empfangen wurden, in Operationen für die Ausführungsmaschine 150 um. Bei dem Ausführungsbeispiel der Fig. 1 sind diese Operationen RISC-artige Operationen (im folgenden Op genannt) und ein einzelner x86 Befehl aus dem Befehlscache 130 wird in eine oder mehrere Op für die Ausführungsmaschine 150 decodiert. Einzelne Op fallen in eine von mehreren Arten von Gruppen einschließlich Registeroperationen (RegOp), Lade/Speicheroperationen (LdStOp), Operationen zum Laden des unmittelbaren Werts (LIMMOp), speziellen Operationen (SpecOp) und Fließstellenoperationen (FpOp). Alternative Ausführungsbeispiele können andere Befehlssätze decodieren und andere Operationstypen zur Ausführung liefern.
• Der Befehlsdecodierer 140 weist zwei Befehlsübersetzungsbereiche, einen Hardware-Übersetzungsbereich MacDec 141 und einen ROM-basierten Übersetzungsbereich 142, zusammen mit einer Verzweigungsvorhersagelogik 143 auf. Die häufigsten x86 Befehle werden in kurze Sequenzen von 1 bis 4 Op unter Verwendung mehrerer paralleler Hardwaredecodierer im Hardwareübersetzungsbereich 141 übersetzt. Der Hardwareübersetzungsbereich 141 decodiert diese vom Befehlscache 130 empfangenen gängigen x86-Befehle in kurze Sequenzen von Op, die anschließend dem Scheduler 180 zugeliefert werden. Weniger gängige x86 Befehle und die x86 Befehle, die zu Op-Sequenzen von mehr als 4 Op übersetzt werden, werden von einem ROM-basierten Übersetzungsbereich 142 übersetzt, der (vom ROM) eine übersetzte Op- Sequenz holt, die dem zu übersetztenden bestimmten x86 Befehl entspricht. Die übersetzten Op-Sequenzen der beiden Quellen, seien sie durch die Hardwaredecodierer erzeugt oder aus dem ROM geholt, werden dem Scheduler 180 zur Ausführung durch die Ausführungsmaschine 150 zugeleitet.
• Wie des weiteren in Fig. 1 dargestellt, weist die Ausführungsmaschine 150 einen Scheduler 180, ein Register 190, und mehrere Ausführungseinheiten auf, die von dem Scheduler 180 gesendete Op empfangen und ausführen. Bei dem Ausführungsbeispiel nach Fig. 1 weist die Ausführungsmaschine 150 sieben Ausführungseinheiten auf: eine Ladeeinheit 152, eine Speichereinheit 153, Registereinheiten 154 und 155, eine Fließstelleneinheit 156, eine Multimediaeinheit 157 und eine Verzweigungseinheit 158, obwohl alternative Ausführungsbeispiele mehr oder weniger Ausführungseinheiten vorsehen können. Bei einem beispielhaften Ausführungsbeispiel entfallen die Fließstelleneinheit 156 und die Multimediaeinheit 157. Die Ausführungseinheit 150 weist ferner eine Speicherschlange 159 auf, die zwischen der Speichereinheit 153 und dem Datencache 170 angeordnet ist.
• Der Scheduler 180 ist als eine geordnete Array von Speichereinträgen und damit verbundenen Logikblöcken ausgebildet, die zusammen das außerhalb der Reihenfolge erfolgende Senden von Op an Ausführungseinheiten und das Senden von Op-Ergebnissen an eine oder mehrere Ausführungseinheiten bewirken. Die geordnete Array von Speichereinträgen und Logikblöcken verwendet ferner einen Neuordnungspuffer und sieht das Umbenennen der im Register 190 definierten Architekturregister und die Wiederherstellung nach spekulativer Ausführung vor. Der Befehlsdecodierer 140 versorgt den Scheduler 180 mit neuen Op, die aus dem Befehlsstrom heraus decodiert wurden. Der Scheduler 180 speichert und hält wiederum (in einem Speichereintrag) Daten, die zu jedem neuen empfangenen Op gehören. Auf diese Weise verfolgt der Scheduler 180 den Zustand jedes Op und der zugehörigen Daten, während das Op an eine Ausführungseinheit ausgegeben und von dieser ausgeführt wird. Nachdem ein gegebenes Op vollständig ausgeführt wurde und Datenabhängigkeiten aufgelöst wurden, wird es zurückgezogen und der entsprechende Schedulereintrag wird freigegeben.
• Der Scheduler 180 ist über eine Gruppe von Bussen und Steuerleitungen, die zusammengefaßt als ein Bus 156 dargestellt sind, mit Ausführungseinheiten verbunden (d. h. der Ladeeinheit 152, der Speichereinheit 153, des Registereinheiten 154 und 155, der Fließkommaeinheit 156, der Multimediaeinheit 157, und der Verzweigungseinheit 158). Der Scheduler 180 liefert Op, Registeroperanden und Steuersignale an die Ausführungseinheiten und empfängt Ergebniswerte und Statusangaben von den Ausführungseinheiten, illustrativ über den Bus 189. Selbstverständlich müssen nichtsämtliche Busse und Steuerleitungen voll verbunden sein und der Bus 189 ist lediglich eine illustrative Darstellung der bidirektionalen Verbindung des Schedulers 180 mit den Ausführungseinheiten.
• Die Ladeeinheit 152 und die Speichereinheit 153 führen LdStOp (d. h. LdOp und StOp) aus, wobei sie jeweils Daten aus einem adressierbaren Speicher laden und in diesen speichern. Je nach Cachezustand einer bestimmten Speicheradresse kann ein LdStOp am L1 Datencache 170, einem (nicht dargestellten) L2 Cache oder an einem (ebenfalls nicht dargestellten) Hauptspeicher beendet sein. Die Speicherschlange 159 speichert vorübergehend Daten von der Speichereinheit 153, so daß die Speichereinheit 153 und die Ladeeinheit 152 parallel arbeiten können, ohne konkurrierende Zugriffe auf den Cache 170. Die Registereinheiten 154 und 155 führen RegOp aus, die ein Datenelement bearbeiten, das den Architekturregistern des Registers 190 zugeordnet ist.
Überblick über den Scheduler
• Fig. 2 zeigt ein exemplarisches Ausführungsbeispiel des Schedulers 180 mit 24 Einträgen (die als Zeilen dargestellt sind), von denen jeder einem anstehenden Op zugeordnet ist. Jeder Eintrag weist eine Reihe von Feldern auf, die zusammenfassend als Programmsteuerungsreservoir 240 dargestellt, um statische und dynamische Daten darzustellen, die einem anstehenden Op zugeordnet sind. Ferner sieht der Scheduler 180 eine Reihe von spezialisierten Logikblöcken vor, die kollektiv als Steuerlogik 230 dargestellt sind, welche mit den Einträgen des Programmsteuerungsreservoirs 240 verbunden sind, um mit anstehenden Op verbundene Daten zu empfangen. Die spezialisierten Logikblöcke der Steuerlogik 230 (die als Spalten 231, 232, 233, 235 und 236 dargestellt sind) liefern Signale, welche die Sequenzierung der Op-Ausführung und die Ausgabe von Operanden an und die Verteilung der Ergebnisse von den Ausführungseinheiten steuern. Die Steuereinheit 230 weist die Ausgabewähllogik 231, die Operandenwähllogik 232, die Lade/Speicher-Ordnungslogik 234, die Zustandsflaggenhandhabungslogik 235 und die Logik 536 zum Unterstützen des selbst-modifizierenden Codes auf.
• Die Ausgabewähllogik 231 steuert die Auswahl der Op aus dem Programmsteuerungsreservoir 240 zur Ausgabe an verfügbare Ausführungseinheiten während jedes Zyklus. Die Operandenwähllogik 232 identifiziert eine geeignete Quelle für Operandendaten, die von Op erfordert werden, welche an Ausführungseinheiten ausgegeben wurden. Je nach Datenabhängigkeiten und der Sequenzierung von Op innerhalb der Ausführungsmaschine 150, kann die geeignete Quelle ein Register 190, ein einem anderen anstehenden Op Eintrag zugeordneten Zielwertfeld (Zielwertfelder für Schedulereinträge sind kollektiv als 250 dargestellt), oder das Ergebnis eines abgearbeiteten Op sein, das auf einem der Ergebnisbusse (kollektiv als Ergebnisbusse 272 dargestellt) geliefert wird. Von der Ausgabewähllogik 231 und der Operandenwähllogik 232 gelieferte Steuersignale ermöglichen es dem Scheduler 180 Op aus dem programmsteuerungsreservoir 240 an verfügbare Ausführungseinheiten auszugeben und die geeignete Operandenquelle für jeden ausgegebenen Op zu wählen.
• Obwohl der Scheduler 180 Op außerhalb der Reihenfolge ausgibt und die Ausführungseinheiten (z. B. die Ladeeinheit 152, die Speichereinheit 153, die Registereinheit · 154, die Registereinheit Y 155 und die Verzweigungseinheit 158) Op außerhalb der Reihenfolge ausführen, müssen bestimme Op-Paare relativ zueinander in der gegebenen Reihenfolge abgearbeitet werden. Beispielsweise müssen LdOp und StOp, die aus derselben physischen Speicherstelle lesen und in diese schreiben, auf den Speicher in der vorgesehenen Reihenfolge zugreifen. Die Lade/Speicherordnungseinheit 234 zeigt eine derartige Ausführungsordnung zwischen LdOp und StOp.
• Die Logik 236 zum Unterstützen des selbst-modifizierenden Codes, die im folgenden näher beschrieben wird, löst einen Selbst-Modifizierender-Code- Fehler in Reaktion auf Angaben der Speicherschlange 159 und physischer Adressentagfelder 243. Die Speicherschlange 159 liefert mehrere Bits der linearen und physischen Zieladressen der StOp, welche die Speicherschlange 159 zur Zuweisung vorbereitet. Die Selbst-Modifizierender-Code-Unterstützungslogik 236 vergleicht diese Adressbits mit einer Befehlsadresse (oder -adressen, wenn die Befehle von verschiedenen Seiten kamen), die als physische Adressentagfelder 243 für jede Op-Vierergruppe gespeichert ist. Wenn irgendeine Vierergruppe paßt, kann ein Schreibvorgang für einen Befehl erfolgen, der bereits geholt wurde oder nun als eine Operation vorliegt (decodiert ist). Daher signalisiert die Selbst-Modifizierender-Code-Unterstützungslogik 236 der globalen Steuerlogik 260 den Scheduler 180 zu flushen, und der Hol/Decodiervorgang wird an dem Befehl fortgesetzt, der dem letzten zugewiesenen Befehl folgt (d. h. an dem Befehl, der dem Befehl folgt, welcher den Befehlsstrom modifizierte). Der Scheduler 180 behandelt die Erkennung eines selbst-modifizierenden Codes als eine Trap oder einen Fehler (d. h. er stellt ein "Trap anstehend" fest).
• Der Scheduler 180 weist ein Zielwertfeld auf, das einem jeden Schedulereintrag zugewiesen ist. Diese Zielwertfelder sind kollektiv bei 250 dargestellt. In Verbindung mit der Operandenwähllogik 232 implementieren die Zielwertfelder 250 einen Neuordnungspuffer und implizieren ein Umbenennen der Register. Die mit Architekturregistern des Registers 190 verbundenen Operandenwerte sind in den Zielwertfeldern 250 wiedergegeben und werden üblicherweise über Operandenbusse 271 als Registeroperandenwerte an Ausführungseinheiten ausgegeben. Die Operandenwerte können jedoch auch vom Register 190 geliefert werden, wenn keines der Zielwertfelder 250 einen neueren Registerzustand aufweist (d. h. einen bisher nicht zugewiesenen Registerzustand). Die Ergebnisse abgearbeiteter Op werden über Ergebnisbusse 272 an das Zielwertfeld des Schedulereintrags geliefert, der mit dem abgearbeiteten Op verbunden ist. Darüber hinaus können diese Ergebnisse auch an Ausführungseinheiten als Operanden für anstehende Op geliefert werden. Die Ergebnisse werden über die Ergebnisbusse 272 geliefert.
• Die Felder eines Programmsteuerungsreservoireintrags (als Beispiel der Programmsteuerungsreservoireintrag 240.1) enthalten Informationen bezüglich einer Operation (Op), deren Ausführung ansteht, die gerade ausgeführt wird, oder die abgearbeitet ist. Die meisten Felder eines Programmsteuerungsreservoireintrags werden initialisiert, wenn der Befehlsdecodierer 130 eine neue Op in das Programmsteuerungsreservoir 240 lädt. Jedoch werden andere Felder später geladen oder aktualisiert. Beispielsweise wird ein Zustandsfeld (das für jeden Eintrag als Feld 242 dargestellt ist) aktualisiert, während die entsprechende Op durch die Stufen derAusführungspipeline läuft. Speicherfelder, die einen Wert von der Zeit des Ladens einer Op in das Programmsteuerungsreservoir 240 bis zum Rückzug aus dem Scheduler 180 halten, werden als "statische Felder" bezeichnet. Die Daten statischer Felder und die anfänglichen Datenwerte von dynamischen Feldern werden vom Befehfsdecodierer 140 geliefert.
• Ein 3-Bit-Feld vom Typ [2 : 0] jedes Programmsteuerungsreservoireintrags (In Fig. 2 als Typ-Feld 241 dargestellt) spezifiziert den mit dem Programmsteuerungsreservoireintrag einhergehenden Op-Typ. Der Op-Typ ist insbesondere fürAusgabewahlzwecke wichtig (z. B. sollten LdOp an eine Ladeeinheit wie 150 ausgegeben werden); jedoch verwendet auch die Lade/Speicherordnungssteuerung das Typ-Feld 241. Die folgenden Signale werden aus dem Typ-Feld 241 decodiert.
• 000 = eine spezielle Operation, die noch nicht ausgeführt ist
• 010 = LU eine von der Ladeeinheit 152 ausgeführte LdOp
• 10x = SU eine von der Speicheeinheit 163 ausgeführte StOp
• 101 = ST eine StOp, die einen Speicher betrifft oder wenigstens eine Fehler = Adresse erzeugt (d. h. keine LEA Operation)
• 11x = RU eine von der Registereinheit · 154 oder möglicherweise von der Registereinheit Y 155 ausgeführte RegOp
• 110 = RUX eine NUR von der Registereinheit · 154 ausführbare RegOp
• 111 = RUY eine von der Registereinheit · 154 und der Registereinheit Y 155 ausführbare RegOp
• Ein 4-Bit-Feld, Zustand [3 : 0], jedes Programmsteuerungsreservoireintrags (in Fig. 2 als Typ-Zustand 242 dargestellt) gibt den gegenwärtigen Ausführungszustand einer Op (53, 52, 51 und 50 sind alternative Signalnamen für den Zustand [3 : 0]) an. Fünf mögliche Zustände des Typ-Feldes 242 werden durch ein Schiebefeld von Einsen wie folgt codiert:
• 0000 nicht ausgegeben
• 0001 Stufe 0
• 0011 Stufe 1
• 0111 Stufe 2
• 1111 abgeschlossen
• Zwischenzustände entsprechen der aktuellen Ausführungsstufe einer Op, die dem Eintrag entspricht, in dem dasTyp-Feld auftritt. Die Bits werden aktualisiert (durch Linksverschiebung), während die Op erfolgreich ausgegeben wird oder aus einer Stufe heraus fortschreitet. Der Zustand [3 : 0] wird während Abbruchzyklen ebenfalls auf 1111 gesetzt.
• Scheduler-Oo-Viergruppen-Organisation
• Der Scheduler 180 weist 24 Einträge im Programmsteuerungsreservoir 240 und Zielwertfelder 250 auf, die als FIFO gehandhabt werden. Neuen Op entsprechende Daten werden "oben" eingeladen, verschieben sich mit dem Fortschritt der Ausführung nach "unten" und werden aus dem unteren Ende des Programmreservoirs 240 zurückgezogen. Zur Vereinfachung der Steuerung handhabt der Scheduler 180 das Programmsteuerungsreservoir 240 und die Zielwertfelder 250 auf einer Op-Vierergruppen-Basis. Op werden in Vierergruppen in das Programmsteuerungsreservoir 240 geladen, durchgeschoben und aus diesem zurückgezogen. Auf diese Weise entspricht die Granularität des Schedulers 180 der Decodierbandbreite sowohl des Emcode ROM 142, als auch des MacDec 141 des Befehlsdecodierers 140. Der Scheduler 180 behandelt daher 24 Op-Einträge als sechs Op-Vierergruppeneinträge in einem FIFO mit einer Tiefe von sechs und einer Breite von vier.
• Daher kann das Programmsteuerungsreservoir 240 als ein Schieberegister mit sechs Einträgen angesehen werden, das Op-Vierergruppen enthält. Jede Op-Vierergruppe enthält vier Op-Einträge plus zusätzlicher Felder, die mit der Op-Vierergruppe als Ganzes einhergehen. Diese Op-Vierergruppenfelder, beispielsweise physische Adresstagfelder 243, werden vom Befehlsdecodierer 140 geliefert.
• Die physischen Adressentagfelder 243 weisen die FelderSmc1stAddr, Smclst- Pg, Smc2ndAddrund Smc2ndPg auf. Zusammen mit einem Op-Vierergruppe- Gültigkeitsfeld, OpQV, liefern diese physische Adressentagfelder 243 beschreibende Informationen an die Selbst-Modifizierender-Code-Unterstützungslogik 236, die mit Op-Vierergruppen-Granularität organisiert ist. Zum Beispiel entsprechen die physischen Adressentagfelder 243.1 und die Selbst- Modifizierender-Code-Unterstützungslogik 236.1 der Op-Vierergruppe 0 des Schedulers 180. Smc1stAddr und Smc1stpg repräsentieren Bereiche einer ersten physischen Speicheradresse für CISC-Befehle, aus denen eine Op (oder mehrere Op) der zugehörigen Op-Vierergruppe decodiert wurde. In dem beispielhaften Ausführungsbeispiel codieren die physischen Adressentagfelder 243 Smc1stPg und Smc1stAddr die Bits 19 : 12 und 11 : 5 der physischen Speicheradresse für den mit der ersten Op der Op-Vierergruppe verbundenen CISC-Befehl. Da die CISC-Befehlvorläufer der Op einer Op-Vierergruppe Cachezeilengrenzen überschreiten können, kann eine zweite physische Speicheradresse zum vollständigen Markieren einer Op-Vierergruppe mit den Adressen der zugehörigen CISC-Befehle erforderlich sein. In einem derartigen Fall geben Smc2ndAddr und Smc2ndPg Bereiche einer zweiten physischen Speicheradresse für die CISC-Befehle an, aus denen eine Op (oder mehrere Op) der zugehörigen Op-Vierergruppe decodiert wurden. Bei dem exemplarischen Ausführungsbeispiel codieren die physischen Adressentagfelder 243 Smc2ndPg und Smc2ndAddr die Bits 19 : 12 und 11 : 5 der physischen Speicheradresse für die über die Cachezeile gehenden CISC-Befehle, die mit einer nachfolgenden Op (oder mehreren Op) der Op-Vierergruppe einhergehen. Der Befehlsdecodierer 140 liefert die physischen Adressentagfelder 243 Smc1stAddr und Smc1stPg (und Smc2ndAddr und Smc2ndPg, wenn CISC-Befehle aus mehr als einer physischen Speicherseite in der Op-Vierergruppe vorliegen) an das Programmsteuerungsreservoir 240.
Operations(Op)-Zeitsteuerung und Ausführungsstufen
• Jeder Eintrag des Programmsteuerungsreservoirs 240 weist Felder auf, die ausstehende Op beschreiben. Diese Felder speichern statische Informationen, die ursprünglich aus den geholten oder vom Befehlsdecodierer 140 decodierten Op gespeichert wurden, und dynamische Zustandsinformationen, die sich aus der Ausführung von Op ergeben oder den Ausführungspipelinezustand einer gegebenen Op charakterisieren.
• Unter Prozessorsteuerungsgesichtspunkten ist der Scheduler 180 eine nach Befehlssequenzen geordnete Array von Op-Zustandsinformationen (Programmsteuerungsreservoir 240) mit zugehöriger Steuerlogik 230, die Steuersignale erzeugt, um Op aus der Array an jeweilige Ausführungseinheiten auszugeben, die Op-Ausführung durch Abfolgen von Pipeline-Stufen zu steuern, und schließlich Op aus dem Scheduler zurückzuziehen. Wie in Fig. 2 dargestellt, weist die Steuerlogik 230 fünf spezialisierte Blöcke von Steuerlogik auf (Ausgabewahllogik 231, Operandenwahllogik 232, Lade/Speicherordnungslogik 234, Zustandsflaggenhandhabungslogik 235 und Selbst- Modifizierender-Code-Unterstützungslogik 236), wobei jeder Bereiche (als Beispiel der Bereich 234.3 der Lade/Speicherordnungslogik 234) Informationen aus entsprechenden Einträgen des Programmsteuerungsreservoirs 240 empfängt. Steuerlogikblöcke liefern Steuersignale an die Ladeeinheit 152 und die Speichereinheit 153 über kollektiv als 273 dargestellte Steuerleitungen. Die jeweiligen von den Steuerlogikblöcken des Programmsteuerungsreservoirs 240 gelieferten Befehle hängen vom Zustand der Felder in den Op-Einträgen ab. Insbesondere das Feld Zustand [3 : 0] gibt den Fortschritt der Abarbeitung von zugehörigen Operationen an. Unterlogischen Gesichtspunkten ist jede Zustandssequenzierung innerhalb des Schedulers naturgemäß ein Einzel- Zyklus. Zustandsübergangsentscheidungen werden in jedem Zyklus basierend auf dem Maschinenzustand während des Zyklus getroffen. Die Struktur des Schedulers 180 reflektiert den Pipeline-Aufbau der Op-Ausführung. Der Scheduler 180 (und dementsprechend jeder Eintrag) kann in zahlreiche verschiedene unabhängige logische Bereiche unterteilt werden, von denen jeder direkt mit einer spezifischen Verarbeitungsstufe eines gegebenen Typs einer Operations- oder Ausführungspipeline verbunden ist.
• Die Pipelinestufung der Ausführungsmaschine 150 wird im folgenden anhand von Fig. 3 beschrieben. Sobald eine Op in die Ausführungsmaschine 150 geladen ist, durchläuft die Op eine drei- oder vierstufige Pipeline und macht entsprechend Übergänge zwischen vier oder fünf Zuständen mit, die durch das Feld Zustand [3 : 0] innerhalb des Schedulereintrags wiedergegeben sind, weicher mit der Op verbunden ist. Das Holen und Decodieren von befehlen erfolgt vor derAusführungsmaschine 150, daher ist die erste auf den Scheduler bezogene Pipelinestufe die Ausgabestufe. Fig. 3 zeigt die Pipelineabstufung für RegOp und LdStOp.
• Der Scheduler 180 übt die primäre Kontrolle über die Ausführungspipelines während der Ausgabe- und der Operandenholstufen 330 und 340 aus. Die Verarbeitung in der Ausgabestufe 330 und in der Operandenholstufe 340 kann in zwei Phasen pro Stufe unterteilt werden, wobei jede Phase nominell einen halben Taktzyklus einnimmt. Die Ausgabestufe 330 weist eine Ausgabewahlphase und eine Übertragungsphase auf, während die Operandenholstufe 340 eine Operandenwahlphase und eine Operandenlieferphase hat.
Ausgabestufe
• Während der Ausgabewählphase 320.1 der Ausgabestufe 330 wählt der Scheduler 180 die nächsten Op, die in die Pipelines der Ladeeinheit 152, der Speichereinheit 153, der Registereinheit · 154 und der Registereinheit 155 eintreten sollen (vier Op-Auswahlen erfolgen gleichzeitig). Während der Übertragungsphase 330.2 der Ausgabestufe 330 werden Informationen über jeden der Registeroperanden für jede gewählte Op an alle Schedulereinträge und an externe Logik (einschließlich des Registers 190 und der Ausführungseinheiten) geliefert. Aufdiese Weise lokalisiert die Übertragungsphase 330.2 Operandenwerte, die in einem der Zielwertfelder 250 des Schedulers 180 oder im Register 190 liegen können, oder die Ergebnissen entsprechen können, die auf Ergebnisbussen 272 an eine derAusführungseinheiten (Z. B. die Ladeeinheit 152, die Speichereinheit 153 oder die Registereinheiten 154 und 155) geliefert werden.
Operandenholstufe
• Während der Operandenwählphase 340.1 der Operandenholstufe 340 lokalisiert der Scheduler 180 bis zu acht Operandenwerte (4 Op · 2Operanden/Op) und bestimmt den Zustand jedes der Operandenwerte, d. h. ob ein gültiger Wert seitens der angegebenen Quelle tatsächlich verfügbar ist. Basierend auf diesen Informationen bestimmt der Scheduler 180, welche der Op in der Operandenholstufe 0 (Stufe 340) nach der Operandenlieferphase in die jeweiligen Ausführungspipelines, d. h. in die Stufe 1 (Stufe 350), übergeht. Die Entscheidungen bezüglich der Weiterleitung werden unabhängig für jede Op getroffen und lediglich Operandenabhängigkeiten grenzen die Reihenfolge ein, in der die Operationen tatsächlich ausgeführt werden. Ohne derartige Datenabhängigkeiten werden Op, die an verschiedene Ausführungseinheiten ausgegeben werden, generell durch die jeweiligen Pipelines hindurch in beliebiger Reihenfolge in bezug auf die Op verarbeitet, die anderen Ausführungseinheiten zugeordnet sind. Eine Ausnahme von dieser allgemeinen Regel betrifft die jeweilige Ordnung von Lade- und Speichervorgängen (d. h. der LdOp und StOp) und wird im folgenden näher erörtert.
LdStOp Ausführungsstufen
• Die ersten beiden scheduler-bezogenen Stufen, die "Operandenausgabe- Stufe" 330 und die "Operandenholstufe" 340 sind den RegOp und den LdStOp gemeinsam. Die nachfolgenden Stufen sind die Ausführungsstufen. RegOp weist eine einzelne Ausführungsstufe 350 auf, da sämtliche RegOp in einem einzigen Zyklus ausgeführt werden. Sobald eine RegOp in die Ausführungsstufe eintritt, wird sie stets erfolgreich abgeschlossen und verlässt die Stufe 350 am Ende dieses Taktzyklus. LdStOp haben andererseits zwei Ausführungsstufen 352 und 360, in denen die Adressenberechnung, die Segment- und Seitenübersetzung (und die Schutzprüfung) sowie der Datencachezugriff (im Falle von LdOp) sämtlich erfolgen. Anders als RegOp können StOp über beliebig lange Zeitspannen in jeder der Stufen 360 oder 370 gehalten werden. Die meisten Aufenthalte treten in der zweiten Stufe 370 auf. Üblicherweise ergeben sich die Aufenthalte in der Stufe 370 aus Fehlzugriffen auf den Datencache 170, Fehlern beim Zugriff auf die Daten-TLB 171 und Seitenfehlern. Aufenthalte in der Stufe 360 ergeben sich aus fehlerhaften Ausrichtungen Speicherreferenzen und aus dem Besetzt sein und der Blockade der Stufe 370 durch eine LdStOp, die nicht der Fertigstellung zugeleitet wird.
• Während der Operandenweiterleitungsphase 340.2 der Operandenholstufe 340 überträgt der Scheduler 180 Operandenwerte von den angegebenen Quellen über Operandenbusse und/oder Ergebnisbusse, die in Fig. 2 kollektiv als Busse 271 und 272 dargestellt sind, an Ausführungseinheiten, beispielsweise die Ladeeinheit 152, die Speichereinheit 153, die Registereinheit · 154 und die Registereinheit Y 155. Das exemplarische Ausführungsbeispiel weist neun Operandenbusse 271 auf, von denen acht Operandenwerte für Operationen in der Stufe 0 liefern. Ferner treten in dem exemplarischen Ausführungsbeispiel Operandentransfers ungeachtet der Gültigkeit der Werte auf, wodurch die Steuerlogik vereinfacht wird. Wenn ein Operandenwert ungültig ist, wird er von der jeweiligen Ausführungseinheit ignoriert, da der Scheduler 180 die zugehörige Operation nicht in die Stufe 1 weiterleitet. Die unmittelbaren Werte für RegOp werden als Teil des zuvor beschriebenen Registeroperandenweiterleitungsmechanismus gehandhabt. In solchen Fällen wird der unmittelbare Wert direkt von dem jeweiligen Zielwertfeldern 250 der Einträge des Schedulers 180 geliefert, die mit der Op verbunden sind.
• Verschiebungswerte werden ebenfalls während der Operandenweiterleitungsphase 340.2 über Verschiebungsbusse 189.4 an die Ladeeinheit 152 und die Speichereinheit 153 übertragen (unabhängige Werte für jede Einheit). Diese Verschiebungen sind 32-Bit-Werte und kommen stets aus den Einträgen des Schedulers 180. Die Wahl des Quelleneintrags erfolgt während der Operandenwählphase 340.1. Tritt eine LdOp oder eine StOp in die Stufe 1 ein, speichern die Ladeeinheit 152 und die Speichereinheit 153 zugehörige Verschiebungs- oder Operandenwerte.
• Der Scheduler 180 implementiert den Vier-Phasen-Steuermechanismus (wie zuvor beschrieben) zum Liefern der Adressenoperanden und der Verschiebung; jedoch erfordern StOp einen Speicherdatenoperanden zusätzlich zu den Adressenoperanden und den Verschiebungswerten. Der Scheduler 180 führt einen Vier-Phasen-Prozess zum Erhalten der Speicherdaten für eine StOp durch. Der StOp-Datenerhaltungsprozess ist dem zuvor beschriebenen Vorgang ähnlich; jedoch werden die Speicherdaten während derAusführungsstufe 2 (370) erhalten. Der Prozess zum Liefern der Speicherdaten ist mit den Stufen 1 und 2 der StOp synchronisiert und weist eine Wählphase 30ß.1 auf, die die StOp in der Ausführungsstufe 1 identifiziert, sowie eine Übertragungsphase 390.2, welche die Informationen überträgt, welche die Quelle eines Datenoperanden beschreiben, eine Datenoperandenwählphase 390.3 und eine Datenoperandenweiterleitungsphase 390.4. Speicherdaten werden parallel zur StOp-Ausführung geholt, und der tatsächliche Datenwert wird erhalten und an die Speicherschlange 159 bei der Beendigung der StOp- Verarbeitung geliefert. Wenn kein gültiger Speicherdatenwert verfügbar ist, wird die StOp in der Stufe 2 zurückgehalten.
On-Beendigungsstufe
• In dem exemplarischen Ausführungsbeispiel werden RegOp und LdOp fertiggestellt, indem Ergebnisse in eines der Zielwertfelder 250 des Schedulers 180 gespeichert werden. Jedes der Zielwertfelder 250 ist mit einem Op- Eintrag verbunden und dient als vorübergehender Speicher (ein Neuordnungspuffer) für Werte, die schließlich durch die OCU 265 dem Register 190 zugeleitetwerden. Bei StOp ist der entsprechende Haltespeicher vor dem Leiten an den Speicher die Speicherschlange 159. Die Speicherschlange 159 puffert Speicherschreibvorgänge, die mit einer StOp einhergehen, in einer ersten Zuweisungsstufe bis die OCU 265 den Speicherschreibvorgang in die zweite Zuweisungsstufe freigibt.
Ov-Zuweisung und -Zurückziehen
• Register-, Flag- und Speicherzustandsänderungen im Zusammenhang mit abgearbeiteten Op werden duirh die OCU (Operation Commit Unit) 265 zugewiesen (oder permanent gesetzt). Die OCU 265 zieht sodann den entsprechenden Op-Eintrag aus dem Scheduler 180 zurück. Die Ausführung einer Op kann zu mehreren Arten von Zustandsänderungen führen. Die haupttypen der Zustandsänderungen sind abbrechbar und umfassen: generelle Registeränderungen; Zustandsflaggenänderungen; und Speicherschreibvorgänge. Generelle Registerveränderungen resultieren aus allen RegOp, LdOp, LIMM Op, LDKxx Operationen und STUPD StOp. Zustandsflaggenveränderungen resultieren aus ".cc" RegOp und Speicherschreibvorgänge ergeben sich aus Stxxx StOp. Der Scheduler 180 und die Speicherschlange 159 unterstützen abbrechbare Zustandsänderungen durch das generelle Verfahren des zeitweiligen Speicherns von Register- und Zustandsergebnissen in den Zielwertfeldern 250 und im Programmsteuerungsreservoir 240 des Schedulers 180 und durch Speichern der Speicherschreibdaten in der Speicherschlange 159. Zeitweilige (oder spekulative) Registerwerte, Zustandswerte, und Speicherschreibwerte werden gehalten, bis die zugehörigen Op von der OCU 265 zugewiesen und zurückgezogen sind. Der Scheduler 180 liefert spekulativ Registerwerte, Zustandswerte, und Speicherschreibwerte, die im Programmsteuerungsreservoir 240 und der Speicherschlange 159 enthalten sind, je nach Bedarf Leere Seite
• an abhängige Op. Permanente Zustandsänderungen am Register 190 und dem Speicheradressenraum (aufgeteilt unter dem Datencache 170, dem Befehlscache 130, einem L2 Cache und dem Hauptspeicher) erfolgen jedoch während der Op-Zuweisung.
• Während jedes Zyklus prüft die OCU 265 jeden der Op-Einträge im unteren Op-Vierergruppeneintrag und versucht, die Ergebnisse so vieler dieser Operationen wie möglich zuzuweisen. Die mit den vier Op einer Op-Vierergruppe einhergehenden Zustandsänderungen können in einem Zyklus oder über viele Zyklen zugewiesen werden. Wenn sämtliche Op einer Op-Vierergruppe zugewiesen wurden oder erfolgreich zugewiesen werden, wird die Op-Vierergruppe aus dem Scheduler 180 am Ende des laufenden Zyklus zurückgezogen. Ansonsten werden so viele Veränderungen wie möglich zugewiesen und das Verfahren wird während nachfolgender Zyklen wiederholt, bis sämtliche Zustandsänderungen zugewiesen sind.
• Die Zuweisung von Registerergebnissen, Zustandsergebnissen und Speicherschreibvorgängen erfolgt unabhängig. Bei Op mit mehreren Ergebnissen (z. B. einer RegOp mit Register- und Zustandsergebnissen oder einer STUPD Operation mit einem Registerergebnis und einem Speicherschreibvorgang) werden die verschiedenen Ergebnisse nicht notwendigerweise gleichzeitig zugewiesen. Statt dessen ist die Zuweisung einer Art von Zustandsveränderung unabhängig von der anderen. Die Gesamtzuweisung einer Op erfolgt, wenn das letzte Ergebnis zugewiesen ist. Im allgemeinen weren Ergebnisse einer Op nicht zugewiesen bis:
• 1. der Op-Ausführungszustand (Zustand [3 : 0]) des Op-Eintrags angibt, daß die Op abgeschlossen ist;
• 2. der Zustand [3 : 0] einer beliebigen vorhergehenden Operation mit Fehlermöglichkeit, nämlich jede beliebige LdStOp, abgeschlossen ist, was impliziert, daß die Operationen fehlerfrei sind; und
• 3. der Zustand [3 : 0] einer beliebigen vorhergehenden BRCOND Operation abgeschlossen ist, was impliziert, daß BRCOND korrekt vorhergesagt wurde,
• Bei StOp, die einen Speicherschreibvorgang erzeugen, ist eine zusätzliche Einschränkung, daß nur ein Schreibvorgang pro Zyklus aus der Speicherschlange 159 in den Datencache 170 zugewiesen werden kann. Die OCU 265 kann bis zu vier Register und vier Zustandsergebnisse sowie einen Speicherschreibvorgang pro Zyklus zuweisen und weist üblicherweise eine Op-Vierergruppe aus dem Scheduler 180 in jedem Zyklus zu und zieht sie aus diesem zurück. Eine Op-Vierergruppe kann ohne zurückgezogen zu sein am unteren Ende des Schedulers 180 über mehr als einen Zyklus nur verbleiben, wenn die Op-Vierergruppe eine Mehrfach-Speicherschreibvorgang-StOp enthält oder eine der Operationen in der Op-Vierergruppe ausreichend in seiner Ausführung verzögert ist, so daß das zugehörige Zustand [3 : 0] Feld 242 noch nicht als abgeschlossen markiert ist.
• Die OCU 265 verwaltet und steuert die Zuweisung von Speicherschreibdatenwerten, die mit StOp einhergehen, an den Speicheradressenraum, d. h. an Stellen im L1 Cache (Datencache 170 und Befehlscache 130), einen L2 Cache und den Hauptspeicher. Die Speicherschreibvorgangszuweisung betrifft einen zusätzlichen Eintrag der Speicherschlange 159 und es wird höchstens ein Speicherschreibvorgang von der OCU 265 pro Zyklus zugewiesen. Die OCU 265 tastet die Feldwerte des Programmsteuerungsreservoirs 240 nach Op- Einträgen in den unteren beiden Op-Vierergruppen ab, um StOp mit zuzuweisenden Speicherschreibvorgängen zu identifizieren.
• Wenn eine StOp in der Speichereinheit 153 abgeschlossen ist, werden die zugehörigen Zielspeicheradresse und die Speicherdaten in eine Speicherschlange 159 gespeichert. Später, wenn der Speicherschreibvorgang für eine StOp tatsächlich zugewiesen wird, wird dieser gelesen und aus der Speicherschlange 159 zurückgezogen. Da die StOp entsprechend der Reihenfolge ausgeführt und zugewiesen werden, wird die Speicherschlange 159 als einfaches FIFO verwaltet. Infolgedessen ist die Abstimmung der Einträge in die Speicherschlange 159 mit zugehörigen StOp im Scheduler 180 einfach.
• In jedem Zyklus durchsucht die Speicherschreibvorgangzuweisungslogik der OCU 258 die beiden unteren Op-Vierergruppeneinträge des Schedulers 180 nach der nächstenältesten nicht zugewiesenen Speicherschreib-StOp (d. h. nach der nächsten StOp und dem zugehörigen Eintrag der Speicherschlange 159, der ausprobiert und zugewiesen wird). Da der Scheduler 180 und die Speicherschlange 159 beide als FIFO verwaltet werden, muß der von der OCU 265 ausgewählte Op-Eintrag mit dem untersten/ältesten Eintrag der Speicherschlange 159 verbunden sein.
• Der Zuweisungsvorgang für die StOp (Speicherschreibvorgang) ist als zweistufige Zuweisungspipeline implementiert. Während der ersten Zuweisungsstufe erfolgen keine Steuerentscheidungen. Statt dessen triggert die OCU 265 eine Datencachetagsuche nach dem Eintrag der Speicherschlange 159, der mit der nächstenältesten nicht zugewiesenen Speicherschreib-StOp im Scheduler 180 verbunden ist. Die Tagdaten, auf die zugegriffen wurde, werden zur Untersuchung während der zweiten Zuweisungsstufe einfach zwischengespeichert. Die Tagsuche im Datencache 170 erfolgt "blind", d. h. ohne Rücksicht darauf, ob die zugehörige StOp gegenwärtig zuweisbar ist. Bei dem exemplarischen Ausführungsbeispiel wählt die OCU 265 einen Op-Eintrag aus dem Scheduler 180 und die Speicherschlange 159 präsentiert gleichzeitig die Speicherschreibadresse für den zugehörigen Eintrag der Speicherschlange 159 an den Datencache 170 (d. h. initiiert eine Tagsuche).
• Eine Schreibzuweisung kann in die Zuweisungsstufe 2 fortschreiten, wenn diese Stufe entweder leer ist oder erfolgreich die Zuweisung eines Schreibvorgangs beendet. Wenn ein Speicherschreibvorgang aus der Speicherschlange 159 in die Zuweisungsstufe 2 eintritt, kann die zugehörige StOp aus dem Scheduler 180 zurückgezogen werden. Die OCU 265 bestimmt, ob die ausgewählte StOp zuweisbar ist, d. h. ob:
• 1. der Op-Ausführungszustand (Zustand [3 : 0]) des Op-Eintrags angibt, daß die Op abgeschlossen ist;
• 2. der Zustand [3 : 0] einer beliebigen vorhergehenden Operation mit Fehlermöglichkeit abgeschlossen ist, was impliziert, daß die Operationen fehlerfrei sind; und
• 3. der Zustand [3 : 0] einer beliebigen vorhergehenden BRCOND Operation abgeschlossen ist.
• Wenn die ausgewählte StOp zuweisbar ist und die Schreibvorgangszuweisung in die zweite Schreibvorgangszuweisungsstufe übergehen konnte, betrachtet die OCU 265 die StOp als zugewiesen. Im nächsten Zyklus sucht die OCU 265 nach der nächsten Speicherschreib-StOp und geht zu dieser über, während der Rest des Zuweisungsvorgangs asynchron zur OCU 265 und zum Scheduler 180 fortgesetzt wird.
• Die Schreibzuweisungspipeline der Speicherschlange 159 ist einen Schreibvorgang breit und unterstützt daher die Zuweisung lediglich einer Speicherschreib-StOp pro Zyklus. Bei Op-Vierergruppen, die nicht mehr als eine Speicherschreib-StOp aufweisen, ermöglicht dies die mögliche Zuweisung und das mögliche Zurückziehen einer Op-Vierergruppe pro Zyklus. Bei Op- Vierergruppen mit zwei, drei oder vier derartiger StOp ist jedoch eine entsprechende Mindestzahl von Zyklen erfordert, um jeden StOp-Eintrag der Op-Vierergruppe zuzuweisen. Infolgedessen verbleibt eine derartige Op- Vierergruppe über wenigstens die entsprechende Zahl von Zyklen am unteren Ende des Schedulers 180.
• Dieses Mißverhältnis im Durchsatz wird teilweise durch die Unterstützung der OCU 265 beim Zuweisen von Speicherschreibvorgängen ausgeglichen, die mit StOp in der nächstältesten Op-Vierergruppe (Op-Vierergruppe 4) verbunden sind. Da Speicherschreibvorgänge in der Reihenfolge zugewiesen werden, ermöglicht dies der OCU 265 einen "Vorsprung" von mehreren Schreib-Op-Vierergruppen zu erlangen, wenn die untere Op-Vierergruppe aufgehalten wird, ansonsten aber keine nicht zugewiesenen Speicherschreibvorgänge aufweist, oder wenn sie einfach keine StOp aufweist. Dies ünterstützt eine bessere Anpassung der Ein-Schreibvorgang-Pro-Zyklus-Zuweisungsrate der OCU 265 an die Durchschnittszahl von Speicherschreibvorgängen pro Op-Vierergruppe, die weniger als eins pro Op-Vierergruppe beträgt. Eine spezielle Situation tritt ein, wenn die Speicherreferenz einer StOp eine Ausrichtungsgrenze (gegenwärtig 8 Bytes) überschreitet und von der Speichereinheit 153 in zwei Speicherschreibvorgänge mit zwei zugehörigen Einträgen in der Speicherschlange 159 geteilt wird. In derartigen Situationen benötigt die OCU 265 zwei Zyklen, um die beiden Einträge der Speicherschlange 159 zurückzuziehen und weist die StOp bis zum zweiten Zyklus nicht offiziell zu. Wenn die StOp fehlerhaft ist, wird sie ohne Zurückziehen eines der Einträge der Speicherschlange 159 abgebrochen.
• Die folgende Pseudo-RTL-Beschreibung faßt die Funktionsweise der Schreibvorgangszuweisungslogik der OCU 265 zusammen. OP0 ist die älteste Op und OP3 ist die neuste Op in der untersten/letzten Op-Vierergruppe des Schedulers 180. Die OP4-OP7 sind die entsprechenden Op in der zweiten bis zur letzten Op-Vierergruppe des Schedulers 180 und die OP8-OP11 sind die entsprechenden Op in der dritten bis zur letzten Op-Vierergruppe des Schedulers 180. Die Operation der OCU 265 basiert auf einem Satz von Maskenbits (CmtMask [7 : 0]), welche den Fortschritt der OCU 265 bei der Zuweisung von Speicherschreib-StOp aus den letzten beiden Op-Vierergruppen wiedergeben.
• Im Betrieb sind die ersten N-Bits (beginnend am Bit 0) von CmtMask[7 : 0] frei, wodurch angegeben wird, daß die OCU 265 jede StOp bis zur N-ten derartigen StOp-Position, welche die nächste zuzuweisende StOp aufweist, zugewiesen hat. Alle Op, die den verbleibenden gesetzten Maskenbits von CmtMask[7 : 0] entsprechen, müssen noch auf zuweisbare StOp untersucht werden. Die OCU 265 hält ferner einen Bit-Satz (UncmtStOp[7 : 0]), der angibt, welche Op-Positionen nicht zugewiesene Speicherschreib-StOp enthalten. Während jedes Zyklus wählt die OCU 265 die nächste nicht zugewiesene StOp und erzeugt einen neuen Satz Maskenbits basierend auf der Position der gewählten StOp. Die nicht maskierten Op werden untersucht, um festzustellen, ob die gewählte StOp gegenwärtig zuweisbar ist oder ein Abbruchzyklus eingeleitet werden muß. Wenn im ersteren Fall die gewählte StOp zuweisbar ist und die Stufe 2 der Zuweisungspipeline in der Lage ist, eine neue Schreibzuweisung am Ende des Zyklus anzunehmen, weist die OCU 265 die StOp zu und aktualisiert die UncmtStOp-Bits. Die OCU 265 schiebt ferner die Bits der UncmtStOp, um eine Anpassung an eine Verschiebung der letzten beiden Op-Vierergruppen zu erreichen.
Selbst-Modifizierender-Code-Handhabungslogik
• Speicherschreibvorgänge werden in der Phase 2 382.2 der LdStOp-Zuweisungsstufe 382 dem Adressenraum zugewiesen (d. h. dem Datencache 170, dem Befehlscache 130, einem L2 Cache und/oder dem Hauptspeicher). Da die Lade-/Speicherordnungslogik 234 die Ordnung der Ausführung zwischen LdOp und StOp, welche auf die selbe Speicheradresse zugreifen, erzwingt, führt ein neuerer Ladevorgang garantiert die gerade zugewiesenen Speicherschreibdaten zurück. Wenn jedoch der Speicherschreibvorgang, der in der Phase 2 382.2 der LdStOp-Zuweisungsstufe 382 in den Befehlstrom einspeichert, können neuere Op (und deren Vorläufer-x86-Befehle) in verschiedenen Pipelinestufen (d. h. x86-Befehlsholstufe 310, x-86-Befehlsdecodierstufe 320, Ausgabestufe 330, Operandenholstufe 340, Ausführungsstufen 351, 352 und 360) auf alten Befehlsbytes basieren. Selbst Op, die abgeschlossen sind und auf die Zuweisung durch die OCU 265 warten, können auf alten Befehlsbytes basieren. Selbst-Modifizierender-Code-Handhabungskomponenten des Schedulers 180 und der Befehlsdecodierer 140 speichern in den Befehlsstrom, um alte Daten wie im folgenden beschrieben zu löschen.
• Wie in Fig. 4 dargestellt, werden StOp dem Adressenraum durch die Stufe 2 460 der Speicherschlange 159 zugewiesen. Die entsprechende Op-Vierergruppe wird aus dem Scheduler 180 durch die OCU 265 zurückgezogen, wenn jeder der Einträge der Op-Vierergruppe abgeschlossen ist (oder gerade zugewiesen wird). Die Stufe 1459 der Speicherschlange 159 liefert Bereiche der linearen und physischen Adresse (d. h. die StOp Adresse) für Speicherschreibdaten, welche die Speicherschlange 159 zur Zuweisung in der Stufe 2 460 vorbereitet. Insbesondere liefert die Stufe 1459 der Speicherschlange 159 die Bits 11-5 der linearen Adresse STQLinAddr (11,5) und die Bits 19-12 der physischen Adresse SlQjhysAddr (19,12). Die Selbst-Modifizierender- Code-Unterstützungslogik 236 des Schedulers 180 empfängt die StOp Adresse und vergleicht sie mit jeweiligen physischen Adressentags Smc1stAddr, Smc1stPg, Smc2ndAddr und Smc2ndPg, die in den Op-Vierergruppenfeldern 443.1, 443.2, 443.3 und 443.4 des Programmsteuerungsreservoirs 240 gespeichert sind. Basierend auf diesem Vergleich bestimmt die Selbst- Modifizierender-Code-Unterstützungslogik 236, ob die durch die Ladeschlange 159 zugewiesene StOp in eine Adresse einschreibt, die von irgendeiner Op- Vierergruppe im Scheduler 180 abgedeckt ist. Wenn ja, löst die Selbst- Modifizierender-Code-Unterstützungslogik 236 eine Selbst-Modifizierender- Code(SMC)-Trap aus. Die globale Steuerlogik 260 löscht den Scheduler 180 und der Hol-/Decodiervorgang wird an dem Befehl wieder aufgenommen, der dem letzten zugewiesenen Befehl folgt (d. h. dem Befehl, der auf den Befehl folgt, welcher den Befehlsstrom modifiziert hat).
• Wie zuvor beschrieben, liefert der Befehlsdecodierer 140 den Inhalt von Op- Vierergruppenfeldern 443.1, 443.2, 443.3 und 443.4 (in Fig. 2 kollektiv als physische Adressentagfelder 243 dargestellt), wenn die Op an den Scheduler 180 ausgegeben werden. Die physischen Adressentags Smc1stAddr, Smc1stPg, Smc2ndAddr und Smc2ndPg, die in den Op-Vierergruppenfeldern 443.1, 443.2, 443.3 und 443.4 gespeichert sind, repräsentieren die Bits 19-5 der ersten und zweiten physischen Speicheradresse für x86 Befehle, aus denen Op der entsprechenden Op-Vierergruppe aus einem x-86 Befehl (oder Befehlen) decodiert wurden, der eine Cachezeilengrenze überschreitet. Die folgende Pseudo-RTL beschreibt das Design und die Operation der Selbst- Modifizierender-Code-Unterstützungslogik 236 weiter.
• Der Befehlsdecodierer 140 fängt ebenfalls den selbst-modifizierenden Code unter Verwendung physischer Adressentags. Insbesondere empfangen die Adressenabgleichlogik 444 und die Holsteuerlogik 447 des Befehlsdecodierers 140 Teile der linearen und physischen Adresse (d. h. der StOp Adresse) für den Speicherschreibvorgang, welche die Speicherschlange 159 in der Stufe 2 460 zur Zuweisung vorbereitet. Wie zuvor liefert die Stufe 1459 der Speicherschlange 159 die Bits 11-S derlinearen Adresse STO LinAddr (11,5) und die Bits 19-12 der physischen Adresse STO PhysAddr (19,12). Die Adressenabgleichlogik 444 vergleicht die StOp Adresse mit AdressenTags 446, die jeweils Einträgen im Befehlspuffer 445 zugeordnet sind. Wird eine Übereinstimmung gefunden, Jöst die Adressenabgleichlogik 444 eine SMC-Trap aus. Die globale Steuerlogik 260 löscht den Befehlsdecodierer 140 und der Hol- /Decodiervorgang wird vom letzten zugewiesenen Befehl an fortgesetzt. In dem exemplarischen Ausführungsbeispiel wird eine SMC-Trap wie folgt behandelt. Nachdem alle Op, die mit der auslösenden StOp verbunden sind, zugewiesen sind (d. h. die Gruppe von Op, die aus dem selben x86 Befehl wie die auslösende StOp decodiert wurde, oder die gesamte Op-Vierergruppe, der die auslösende StOp angehört, je nachdem, welche größer ist), werden Op, die mit nachfolgenden x86 Befehlen einhergehen, abgebrochen. Bei dem exemplarischen Ausführungsbeispiel implementiert der folgende Emcode eine SMC-Trap.
• Der SMC-Trap-Emcode führt zum erweiterten Befehlszeiger (EIP) des zuvor genannten abgebrochenen Befehls. In einem alternativen Ausführungsbeispiel, das einen zwischen dem Datencäche 170 und dem Hauptspeicher angeordneten L2 Cache aufweist, könnte die auslösende StOp von dem L2 Cache bestätigt werden. In jedem Fall bedeutet eine derartige Bestätigung, daß bereits ein Snoop-Befehl an den Befehlscache 130 ausgegeben wurde. Nachdem der SMC-Trap-Emcode mit dem Speicherschreibvorgang, der mit der auslösenden StOp verbunden ist, synchronisiert ist, springt er (durch ein WrIP) zurück, um den nächsten x86 Befehl in dem Befehlsstrom zu holen. An diesem Punkt ist sichergestellt, daß die nächsten aus dem Hauptspeicher (oder alternativ aus dem L2 Cache geholten Bytes) aktuell sind.
• Selbst eine StOp, die keine SMC-Trap auslöst, erzeugt ein Zeitfenster nachdem der zugehörige Speicherschreibvorgang zugewiesen ist, jedoch bevor ein Snoop an den Befehlscache 130 ausgegeben wird, während dem jedes neue vom Befehlsdecodierer 140 geholte Befehlsbyte potentiell überholt ist. Um dies zu überwinden, speichert die Holsteuerlogik 447 des Befehlsdecodierers 140 eine Kopie der physischen Adresse (d. h. der StOp Adresse), die mit dem zugewiesenen Speicherschreibvorgang einhergeht. Wann immer der Befehlsdecodierer 140 neue Befehlsbytes aus dem Befehlscache 130 holt, prüft die Holsteuerlogik 447 die aktuelle Holadresse in bezug auf deren gespeicherte Kopie der StOp Adresse des zuletzt zugewiesenen Speicherschreibvorgangs. Wenn die gegenwärtige Holadresse der gespeicherten Kopie der StOp Adresse entspricht, macht die Holsteuerlogik 447 den Holvorgang ungültig. Die Holsteuerlogik 447 des Befehlsdecodierers 140 gibt weiterhin die selbe Holadresse aus, bis die zugewiesene StOp vom Speichersubsystem bestätigt ist. Wenn die Holsteuerlogik 447 eine Bestätigung vom Speichersubsystem empfängt, löscht sie ihren StOp Adressenspeicher. Bei einem alternativen Ausführungsbeispiel, das einen zwischen dem Datencache 170 und dem Hauptspeicher angeordneten L2 Cache aufweist, kann die Bestätigung statt dessen durch den L2 Cache erfolgen.
• Bei dem exemplarischen Ausführungsbeispiel gibt das Speichersubsystem einen Snoop-Befehl an den Befehlscache 130 vor (oder spätestens) gleichzeitig mit der StOp-Bestätigung aus. Während der Befehslcache 130 einen Snoop-Befehl verarbeitet, sperrt sie die Verarbeitung von Holbefehlen aus dem Befehlsdecodierer 140. Durch das Sperren von Holbefehlen während der Snoop-Verarbeitung schließt der Befehlscache 130 ein zweites kurzes Fenster, während dessen Befehlsholvorgänge potentiell alte Bytes rückführen könnten.
• Jede Op-Vierergruppe des Schedulers 180 kann Bytes decodierter x86 Befehle enthalten, die zwei Zeilen des Befehlscache 130 einnehmen. In ähnlicher Weise kann ein Eintrag in dem Befehlspuffer 445 zwei Zeilen des Befehlscache 130 einnehmen. Bei dem exemplarischen Ausführungsbeispiel besteht eine Zeile im Befehlsdecodierer 140 aus 32 Bytes. Das bedeutet, daß die jedem Op-Vierergruppeneintrag des Schedulers 180 und jedem Eintrag des Befehlspuffers 445 zugeordneten physischen Adressentags Adressen für beide möglichen 32-Byte-Cachezeilen codieren müssen. Bei einem Ausführungsbeispiel der Adressentags 446 und der physischen Adressentagfelder 243 wird ein Paar vollständiger physischer Adressentags (Bits 31 : 5) für jeden Op- Vierergruppeneintrag des Schedulers 180 und für jeden Eintrag des Befehlspuffers 445 gespeichert. Um jedoch die Hardware zu reduzieren, während gleichzeitig eine hohe Frequenz falscher Abgleiche vermieden wird, speichern die exemplarischen Ausführungsbeispiele der Adressentags 446 und der physischen Adressentagfelder 243 Teile physischer Adressen, von denen jedes die Bits 19 : 5 der physischen Speicheradresse des zugehörigen x86 Befehls (oder Befehle) enthält.
• Das exemplarische Ausführungsbeispiel unterstützt den Einzelzyklus-Durchsatz von Schreibvorgängen in den Speicher. Der Datencache 170 ist ein Rückschreibcache. Wenn eine Speicherschreibzuweisung, die einer StOp zugeordnet ist, den Datencache 170 trifft und die Zeile als besetzt oder verunreinigt erkannt wird, so kann der Schreibvorgang mit einer Rate von 1 pro Zyklus verarbeitet werden. Diese Situation bietet einige Schwierigkeiten bezüglich der Handhabung eines selbst-modifizierenden Codes, wenn eine besetzte/verunreinigte Leitung sowohl im Datencache 170 als auch im Befehlscache 130 vorhanden sein darf. Bei einem Ausführungsbeispiel müßte der Befehlscache 130 unmittelbar mit dem Zuweisen der StOp gesnoopt werden, was zu zusätzlicher Komplexität führen würde, da Eingrenzungsbelange im Tag-RAM des Zugriffsspeichercaches entstehen. Darüber hinaus müßte ein (nicht dargestellter) gewidmeter Adressenbus vom Datencache 170 zum Befehlscache 130 gesendet werden. Um diese Komplexität zu minimiereren, während der gegenseitige Ausschluß von Befehlscache 130 und Datencache 170 gleichzeitig gewahrt bleibt, verhindert die Cachesteuerlogik 160 bei dem exemplarischen Ausführungsbeispiel, daß eine Cachezeile in beiden Caches gleichzeitig residiert. Die geschätzte Einwirkung dieser Einschränkung auf die Leistung ist vernachlässigbar.
• Eine durch dieses Schema auferlegte Beschränkung besteht darin, daß eine StOp nicht in den Befehlsstrom schreiben kann, wenn die modifizierten Bytes in den selben Op-Vierergruppeneintrag decodiert werden wie die Schreib-StOp und die StOp älter als die modifizierten Bytes sind. Ein Prozessor, der der x86 Prozessorarchitektur entspricht, muß jedoch Steuerspezifikationen übertragen, bevor er aus dem modifizierten Befehlsstrom heraus arbeitet. Siehe Intel Pentium Processor, Software Reference Manual. In dem exemplarischen Ausführungsbeispiel eliminiert diese Anforderung (fall erfüllt) die Möglichkeit, daß eine StOp, die in den Befehlsstrom speichert, und die Bytes, die sie schreibt, jemals in der selben Op-Vierergruppe des Schedulers 180 stehen. Die Erfindung wurde unter Bezugnahme auf verschiedene Ausführungsbeispiele beschrieben, jedoch ist ersichtlich, daß diese Ausführungsbeispiele illustrativ sind und der Rahmen der Erfindung nicht auf diese beschränkt ist. Zahlreiche Variationen, Modifizierungen, Zusätze und Verbesserungen der beschriebenen Ausführungsbeispiele sind möglich. So ist zum Beispiel die Organisation derOp-Einträge im Scheduler 180 lediglich illustrativ. Alternative Ausführungsbeispiele können andere Strukturen und/oder Verfahren zum Wiedergeben der Art und des Zustands von Operationen in einem Computer mit mehreren und/oder als Pipeline angeordneten Ausführungseinheiten verwenden. Ferner können alternative Ausführungsbeispiele unterschiedliche Hierarchien von Speichern und Caches aufweisen, beispielsweise L1 und L2 Caches. Bei derartigen alternativen Ausführungsbeispielen können Speicherbestätigungen von einem L2 Cache geliefert werden.
• Alternative Ausführungsbeispiele können eine andere Verteilung von Strukturen und Funktionen, einschließlich Strukturen zurlag-Wiedergabe und zum Tag-Vergleich, zwischen dem Scheduler 180, der Speichereinheit 153, der Speicherschlange 159 und dem Befehlsdecodierer 140 aufweisen. Darüber hinaus können Strukturen und Funktionen, die bei dem exemplarischen Ausführungsbeispiel als Hardware ausgebildet sind, als Software, Firmware oder Mikrocode in alternativen Ausführungsbeispielen ausgebildet sein. Eine große Vielzahl von Computersystemkonfigurationen ist vorgesehen, die jeweils die Handhabung selbst-modifizierender Codes gemäß der Erfindung verkörpern. Beispielsweise weist ein derartiges Computersystem (z. B. das Computersystem 1000) einen Prozessor 100 auf, der eine erfindungsgemäße Handhabung selbst-modifizierenderCodes ermöglicht, ein Speichersubsystem (z. B. den RAM 1020), einen Anzeigeadapter 1010, einen Laufwerkscontroller/- adapter 1030, verschiedene Eingangs-/Ausgangsinterfaces und -adapter (z. B. ein paralleles Interface 1009, ein serielles Interface 1008, ein LAN Adapter 1007, etc.) und entsprechende Vorrichtungen (z. B. eine Anzeigevorrichtung 1001, ein Drucker 1002, ein Modem 1003, eine Tastatur 1006, und ein Datenspeicher). Der Datenspeicher weist Vorrichtungen wie eine Festplatte 1032, eine Floppy-Disk 1031, eine Bandeinheit, ein CD-ROM, eine Jukebox, eine redundante Anordnung kostengünstiger Disks (RAID), einen Flash- Speicher, etc., auf. Diese und andere Variationen, Modifizierungen, Zusätze und Verbesserungen fallen in den durch die nachfolgenden Ansprüche definierten Rahmen der Erfindung.

Claims (13)

1. Selbst-modifizierendes Codeverarbeitungssystem für einen Prozessor mit Operationseinträgen zur Wiedergabe von Pipelinestufen vom Befehlsholen bis zur Ergebniszuordnung, und mit einer Speicher-Pipeline (153, 159) zum Zuordnen von Speicheroperanden zu Zieladressen im Speicher (122), wobei das selbst-modifizierende Codeverarbeitungssystem aufweist:

- mehrere erste Tag-Speicher, die jeweils mit einer ersten Gruppe von Operationseinträgen verbunden sind, wobei die ersten Tag- Speicher erste Speicheradressen von Befehlen angeben, die den zugehörigen Operationseinträgen entsprechen;

- eine erste Vergleichslogik (236), die mit den ersten Tag-Speichern und der Speicher-Pipeline (153, 159) verbunden ist, um eine selbstmodifizierende Codeangabe in Reaktion auf eine Übereinstimmung der Zieladresse für eine von der Speicher-Pipeline zugeordnete Speicheroperation und einer beliebigen der in den ersten Tag-Speichern wiedergegebenen ersten Adressen zu liefern; und

- eine mit der ersten Vergleichslogik und den Operationseinträgen verbundene Steuerlogik (260) zum Löschen nicht zugewiesener Operationseinträge in Reaktion auf die selbst-modifizierende Codeangabe.

2. Selbst-modifizierendes Codeverarbeitungssystem nach Anspruch 1, bei dem

- die erste Gruppe von Operationseinträgen mehrere Op-Einträge aufweist, die in Op-Gruppen organisiert sind, welche in einer Zeitplanungseinrichtung (180) wiedergegeben sind; und

- die ersten Tag-Speicher jeweils zwei Tag-Felder aufweisen, die Speicheradressen für eine Gruppe von Befehlen abdecken, aus denen die Op-Einträge der zugehörigen Op-Gruppe decodiert werden, wobei die Tag-Feld-Paare dem Abdecken von Speicheradressen auf beiden Seiten einer Cachezeilengrenze dienen, wenn die Befehlsgruppe die Cachezeilengrenze überschreitet.

3. Selbst-modifizierendes Codeverarbeitungssystem nach Anspruch 2, bei dem die in dem Tag-Feld-Paar wiedergegebenen ersten Adressen Teiladressen sind, und bei dem die erste Vergleichslogik (236) die selbstmodifizierende Codeangabe in Reaktion auf eine Übereinstimmung zwischen einer beliebigen der in den Tag-Feldern wiedergegebenen Teiladressen und einem entsprechenden Bereich der Zieladresse für die Speicheroperation liefert, die durch die Speicher-Pipeline zugewiesen wurde.

4. Selbst-modifizierendes Codeverarbeitungssystem mach Anspruch 1, bei dem die erste Gruppe und eine zweite Gruppe der Operationseinträge jeweils mit einer Zeitplanungseinrichtung (180) und mit einem Befehisdecodierer (140) verbunden ist, wobei das selbst-modifizierende Codeverarbeitungssystem ferner aufweist:

- mehrere zweite Tag-Speicher, die jeweils mit Einträgen der zweiten Gruppe von Operationseinträgen verbunden sind, wobei die zweiten Tag-Speicher zweite Adressen im Befehlsspeicher wiedergeben, die den zugehörigen Operationseinträgen entsprechen;

- eine zweite Vergleichslogik (444), die mit den zweiten Tag-Speichern, der Speicher-Pipeline (153, 159) und derSteuerlogikverbunden ist, wobei die zweite Vergleichslogik die selbst-modifizierende Codeangabe in Reaktion auf eine Übereinstimmung zwischen der Zieladresse für die von der Speicher-Pipeline zugeordnete Speicheroperation und einer beliebigen, in den zweiten Tag-Speichern wiedergegebenen Adresse liefert;

- wobei die Steuerlogik die zweite Gruppe von Operationseinträgen und nicht zugewiesenen Einträgen der ersten Gruppe von Operationseinträgen in Reaktion aufdie selbst-modifizierende Codeangabe löscht.

5. Selbst-modifizierendes Codeverarbeitungssystem nach Anspruch 4, bei dem

- die erste Gruppe von Operationseinträgen mehrere Op-Einträge aufweist, die in Op-Gruppen organisiert sind, welche in einer Zeitplanungseinrichtung wiedergegeben sind;

- die ersten Tag-Speicher jeweils zwei Tag-Felder aufweisen, die Speicheradressen für eine Gruppe von Befehlen abdecken, aus denen die Op-Einträge der zugehörigen Op-Gruppe decodiert werden, wobei die Tag-Feld-Paare dem Abdecken von Speicheradressen auf beiden Seiten einer Cachezeilengrenze dienen, wenn die Befehlsgruppe die Cachezeilengrenze überschreitet;

- die zweite Gruppe von Operationseinträgen mehrere Befehlseinträge aufweist, die als Befehlspuffer im Befehlsdecodierer organisiert sind, wobei jeder Befehlspuffereintrag einer Cachezeile entspricht; und

- wobei die zweiten Adressen die Cachezeile abdecken.

6. Selbst-modifizierendes Codeverarbeitungssystem nach Anspruch 5, bei dem

- die ersten und zweiten Adressen Teiladressen sind;

- die erste Vergleichslogik (236) die selbst-modifizierende Codeangabe in Reaktion auf eine Übereinstimmung zwischen einer der in den Tag-Feldern wiedergegebenen Teiladressen und einem entsprechenden Bereich der Zieladresse liefert; und

- die zweite Vergleichslogik (444) die selbst-modifizierende Codeangabe in Reaktion auf eine Übereinstimmung zwischen einer der in den zweiten Tag-Feldern wiedergegebenen Teiladressen und einem entsprechenden Bereich der Zieladresse liefert.

7. Selbst-modifizierendes Codeverarbeitungssystem nach Anspruch 2, ferner mit:

- einem Adressenspeicher, der mit der Speicher-Pipeline (153, 159) verbunden ist, um die Zieladresse für aufeinanderfolgende Speicheroperationen zu empfangen, wobei der Adressenspeicher in Reaktion auf eine Speicherbestätigung von einem Speicher-Subsystem gelöscht wird; und

- einer Holsteuerlogik (447), die mit dem Adressenspeicher verbunden ist, um das Holen eines Befehls von eine aktuellen Holadresse in Reaktion auf eine Übereinstimmung zwischen der aktuellen Holadresse und der im Adressenspeicher gespeicherten Zieladresse ungültig zu machen.

8. Selbst-modifizierendes Codeverarbeitungssystem nach Anspruch 7, ferner mit:

- einem zwischen dem Befehlsdecodierer (140) und dem Speicher- Subsystem (122) angeordneten Befehlscache (130), der das Verarbeiten von Holvorgängen vom Befehlsdecodierer sperrt, während er eine Abfrage aus dem Speicher-Subsystem verarbeitet; und

- einem zwischen der Speicherpipeline und dem Speicher-Subsystem angeordneten Datencache (170); und

- einer Befehls-/Datencachesteuerlogik, die ein gleichzeitiges Vorhandensein einer Cachezeile in dem Befehlscache und dem Datencache verhindert.

9. Vorrichtung mit einem selbst-modifizierenden Codeverarbeitungssystem, wobei die Vorrichtung aufweist:

- ein Speicher-Subsystem (122); einen Befehls- (130) und einen Datencache (170), die mit dem Speicher-Subsystem (122) verbunden sind; und

- mehrere Ausführungseinheiten, einschließlich einer Speicher-Pipeline (153, 159), die mit dem Datencache (170) verbunden ist, um ein Ergebnis einer Speicheroperation (StOp) dem Speicher-Subsystem zuzuweisen, wobei die Speicher-Pipeline eine StOp-Zieladressenangabe bei der Zuweisung des StOp-Ergebnisses liefert, gekennzeichnet durch

- eine Zeitplanungseinrichtung (180), die eine geordnete Vielzahl von Op-Einträgen für Ops, die, im wesentlichen durch Ergebniszuweisung, aus Befehlen decodiert sind, und eine entsprechende Vielzahl von ersten Adress-Tags zum Abdecken von Speicheradressen der Befehle aufweist;

- eine erste Vergleichslogik (236), die mit der Speicher-Pipeline und mit den ersten Adress-Tags verbunden ist, um die selbst-modifizierende Codefehlerverarbeitungseinrichtung in Reaktion auf eine Übereinstimmung zwischen der StOp-Zieladresse und einem der ersten Adress-Tags auszulösen;

- einen zwischen dem Befehlscache und der Zeitplanungseinrichtung angeordneten Befehlsdecodierer (140), der mehrere Befehlspuffereinträge und zweite Adress-Tags aufweist, die mit den Befehlspuffereinträgen verbunden sind; und

- eine mit der Speicher-Pipeline und den zweiten Adress-Tags verbundene zweite Vergleichslogik (444) zum Auslösen der selbst-modifizierenden Codefehlerverarbeitungseinrichtung in Reaktion auf eine Übereinstimmung zwischen der StOp-Zieladresse und einem der zweiten Adress-Tags.

10. Vorrichtung nach Anspruch 9, bei der die selbst-modifizierende Codefehlerverarbeitungseinrichtung aufweist:

- eine mit der ersten und der zweiten Vergleichslogik (236, 444) und der Zeitplanungseinrichtung (180) sowie dem Befehlsdecodierer verbundene Steuerlogik zum Löschen nicht zugewiesener Op aus den Op-Einträgen und zum Löschen von Befehlen aus dem Befehlspuffer in Reaktion auf eine selbst-modifizierende Codefehleranzeige seitens der ersten oder der zweiten Vergleichslogik.

11. Vorrichtung nach Anspruch 10, bei der die selbst-modifizierende Codefehlerverarbeitungseinrichtung ferner eine selbst-modifizierende Codefehlerverarbeitungseinheitzur Durchführung der folgenden Schritte aufweist:

- Zuweisen der Ops, die mit dem selben Befehl verbunden sind wie das auslösende StOp;

- Warten auf die Bestätigung des auslösenden StOp durch das Speicher-Subsystem; und

- Zurückspringen in den Befehlsstrom zu einem Befehl, der unmittelbar auf den Befehl folgt, der dem auslösenden StOp zugeordnet ist.

12. Vorrichtung nach Anspruch 10, bei der die selbst-modifizierende Codefehlerverarbeitungseinrichtung ferner aufweist:

- einen Adressenspeicher, der mit der Speicher-Pipeline zum Empfangen der Zieladresse für aufeinanderfolgende StOps verbunden ist, wobei derAdressenspeicher in Reaktion auf die Bestätigung des StOp seitens des Speicher-Subsystems gelöscht wird; und

- eine Holsteuerlogik (447), die mit dem Adressenspeicherverbunden ist, um das Holen eines Befehls von einer Holadresse durch den Befehlsdecodierer in Reaktion aufeine Übereinstimmung zwischen der Holadresse und der im Adressenspeicher gespeicherten Zieladresse ungültig zu machen.

13. Computersystem mit mehreren Ausführungseinheiten (150), einer Zeitplanungseinrichtung (180), einem Befehlsdecodierer (140), einem Speicher-Subsystem (122) und einem Befehls- (130) sowie einem Datencache (170), die jeweils mit dem Speicher-Subsystem (122) verbunden sind, wobei das Computersystem eine Vorrichtung nach Anspruch 9 aufweist.