-
Hintergrund
-
Von
Mikroprozessoren wird zunehmend verlangt, mehrere Kerne auf einem
einzelnen Chip zu unterstützen.
Um Arbeitsaufwand und Kosten der Entwicklung niedrig zu halten und
sich an zukünftige Anwendungen
anzupassen, versuchen Konstrukteure häufig, Mehrkern-Mikroprozessoren
zu entwerfen, die die Bedürfnisse
einer ganzen Produktpalette erfüllen,
von tragbaren Laptops bis zu Hochleistungsservern. Dieses Konstruktionsziel
stellt Prozessorentwickler vor ein schwieriges Dilemma: die für Mikroprozessoren
in Laptop- und Desktop-Rechnern wichtige Single-Thread-Performance
beizubehalten und gleichzeitig den für Mikroprozessoren in Server wichtigen
Systemdurchsatz bereitzustellen. Üblicherweise haben Entwickler
versucht, das Ziel einer hohen Single-Thread-Performance durch Verwendung von
Chips mit einzelnen, großen,
komplexen Kernen zu erreichen. Andererseits haben Entwickler versucht,
das Ziel eines hohen Systemdurchsatzes durch Bereitstellen mehrerer,
im Vergleich dazu kleinerer, einfacherer Kerne auf einem einzelnen
Chip zu erreichen. Weil Entwickler jedoch mit Begrenzungen der Chipgröße und des
Energieverbrauchs konfrontiert sind, stellt das gleichzeitige Bereitstellen
von sowohl hoher Single-Thread-Performance als auch von hohem Systemdurchsatz
auf demselben Chip wesentliche Herausforderungen dar. Spezieller
bietet ein einzelner Chip keinen Platz für viele große Kerne, und kleine Kerne
stellen üblicherweise
keine hohe Single-Thread-Performance bereit.
-
Ein
Faktor, der den Durchsatz stark beeinflusst, ist die Notwendigkeit,
Befehle auszuführen, die
von Operationen mit großer
Latenz abhängen, wie
z. B. das Behandeln von Cache-Fehlern. Befehle in einem Prozessor
können
in einer logischen Struktur, die als „Scheduler” bekannt ist, auf eine Ausführung warten.
Im Scheduler warten Befehle mit zugewiesenem Zielregister darauf,
dass ihre Quelloperanden verfügbar
werden, wonach die Befehle den Scheduler verlassen, ausgeführt werden
und ausscheiden können.
-
Wie
jede Struktur in einem Prozessor ist der Scheduler Platzbeschränkungen
unterworfen und hat folglich eine endliche Anzahl von Einträgen. Befehle,
die von der Betreuung eines Cache-Miss abhängen, müssen möglicherweise Hunderte von Zyklen
warten, bis der Miss behandelt wird. Während sie warten, bleiben ihre
Schedulereinträge
zugewiesen und daher nicht verfügbar
für andere
Befehle. Diese Situation erzeugt Druck auf den Scheduler und kann
zu einem Leistungsverlust führen.
-
In ähnlicher
Weise wird Druck auf den Registersatz (die Registerdatei) erzeugt,
weil den im Scheduler wartenden Befehlen weiter ihre Zielregister
zugewiesen sind und diese daher für andere Befehle nicht verfügbar sind.
Diese Situation kann auch für die
Leistung nachteilig sein, insbesondere angesichts der Tatsache,
dass der Registersatz gezwungen sein kann, tausende von Befehlen
vorzuhalten, und dass er normalerweise eine energiehungrige, zyklusempfindliche,
durchgängig
getaktete Struktur ist.
-
LEBECK,
Alvin et al: A Large Instruction Window for Tolerating Cache Misses.
In IEEE Proceedings of the 29th Annual International Symposium an Computer
Architecture, 2002, IEEE Computer Society befasst sich mit einer
Mikroarchitektur zur Steigerung des Durchsatzes in der Befehlsverarbeitung
von Prozessoren. Dabei ist vorgesehen, dass Befehle, die von einer
Operation mit großer
Latenzzeit abhängen,
aus der Bearbeitungsschlange in einen separaten, und viel größeren, Wartepuffer
verschoben werden. Nach Durchführung
einer solchen Operation mit großer
Latenzzeit wird der jeweils davon abhängige Befehl wieder in die
Bearbeitungsschlange zurückgeholt.
Eine Steigerung des Durchsatzes ist hierdurch jedoch nur eingeschränkt möglich; häufig ist
ein Teil der zur Ausführung
eines Befehls benötigten
Eingabedaten bereits verfügbar
und belegt Register, die bis zur Verfügbarkeit der übrigen benötigten Daten
somit blockiert sind.
-
Die
zu lösende
Aufgabe ist somit darin zu sehen, den Durchsatz von Befehlen in
der Pipeline eines Prozessors zu steigern.
-
Kurzbeschreibung der Zeichnungen
-
1 zeigt
Elemente eines Prozessors, umfassend eine Slice-Prozessoreinheit
gemäß Ausführungsformen
der vorliegenden Erfindung,
-
2 zeigt
einen Prozeßablauf
gemäß Ausführungsformen
der vorliegenden Erfindung und
-
3 zeigt
ein System, umfassend einen Prozessor gemäß Ausführungsformen der vorliegenden
Erfindung.
-
Ausführliche Beschreibung
-
Ausführungsformen
der vorliegenden Erfindung betreffen ein System und Verfahren zum
verhältnismäßigen Steigern
des Prozessordurchsatzes und der Speicherlatenztoleranz, und zum
Abbauen der Belastung des Schedulers und des Registersatzes durch
Abziehen von Befehlen, die von Operationen mit langer Latenz abhängig sind,
aus dem Prozessor-Pipeline-Fluß und deren
Wiedereinführen
in den Fluss, wenn die Operationen mit langer Latenz abgeschlossen
sind. Auf diese Weise binden die Befehle keine Ressourcen, und der
Gesamtdurchsatz von Befehlen in der Pipeline wird vergleichsweise
gesteigert.
-
Spezieller
betreffen Ausführungsformen
der vorliegenden Erfindung das Erkennen von Befehlen, die von Operationen
mit langer Latenz abhängig
sind, die im Folgenden als „Slice”-Befehle
bezeichnet werden, und ihr Verschieben von der Pipeline in einen „Slice-Datenpuffer” gemeinsam
mit zumindest einem Teil der Informationen, die notwendig sind,
um den Slice-Befehl auszuführen.
Die Schedulereinträge
und Zielregister der Slice-Befehle können dann durch andere Befehle
erneut zur Verwendung angefordert werden. Befehle, die von den Operationen
mit langer Latenz unabhängig
sind, können
diese Ressourcen verwenden und die Programmausführung fortsetzen. Wenn die
Operationen mit langer Latenz, von denen die Slice-Befehle im Slice-Datenpuffer
abhängen,
erfüllt
sind, können
die Slice-Befehle wieder in die Pipeline eingeführt, ausgeführt und ausgeschieden werden.
Ausführungsformen
der vorliegenden Erfindung führen
dadurch zu einer Prozessorpipeline mit nicht-blockiertem, konstantem
Durchsatz.
-
1 zeigt
ein Beispiel eines Systems gemäß Ausführungsformen
der vorliegenden Erfindung. Das System kann eine „Slice-Verarbeitungseinheit” 100 gemäß Ausführungsformen
der vorliegenden Erfindung umfassen. Die Slice-Verarbeitungseinheit 100 kann
einen Slice-Datenpuffer 101, einen Slice-Umbenennungsfilter 102 und
einen Slice-Remapper 103 umfassen.
Mit diesen Elementen verbundene Operationen werden im Folgenden ausführlicher
dargestellt.
-
Die
Slice-Verarbeitungseinheit 100 kann mit einer Prozessorpipeline
verknüpft
sein. Die Pipeline kann einen Befehlsdecoder 104, der mit
der Zuweisungs- und Registerumbenennungslogik 105 verbunden
ist, enthalten, um Befehle zu decodieren. Wie bekannt ist, können Prozessoren
eine Logik umfassen, wie die Zuweisungs- und Registerumbenennungslogik 105,
um Befehlen physische Register zuzuweisen und um logische Register
der Befehle auf die physischen Register abzubilden. „Abbilden” bedeutet
hier, eine Entsprechung zwischen etwas zu definieren oder zu bezeichnen
(in begrifflicher Hinsicht wird ein logischer Registerkennzeichner
in einen physischen Registerkennzeichner „umbenannt”). Spezieller werden den Quell-
und Zieloperanden eines Befehls während ihrer kurzen Lebensdauer
in einer Pipeline, wenn sie als Kennzeichner der Register eines
Satzes von logischen (auch „architektonischen”) Registern des
Prozessors spezifiziert sind, physische Register zugeteilt, so dass
der Befehl tatsächlich
im Prozessor ausgeführt
werden kann. Der physische Registersatz ist normalerweise viel umfangreicher
als der logische Registersatz, und daher können mehrere verschiedene physische
Register auf dasselbe logische Register abgebildet werden.
-
Die
Zuweisungs- und Registerumbenennungslogik 105 kann an μop-(„Mikro”-Operations-, d. h.
Befehls-)Warteschlangen 106 gekoppelt werden, um Befehle
zur Ausführung
in Reihe zu bringen, und die μop-Warteschlangen 106 können mit
Schedulern 107 gekoppelt werden, um die Befehle zur Ausführung einzuplanen.
Das Abbilden von logischen Registern auf physische Register (im
Folgenden „die physische
Registerabbildung” genannt),
ausgeführt von
der Zuweisungs- und Registerumbenennungslogik 105, kann
in einem Neuordnungspuffer (ROB) (nicht dargestellt) oder in den
Schedulern 107 für
Befehle, die ihre Ausführung
erwarten, aufgezeichnet werden. Gemäß Ausführungsformen der vorliegenden
Erfindung kann die physische Registerabbildung für als Slice-Befehle erkannte
Befehle in den Slice-Datenpuffer 101 kopiert werden, wie
im Weiteren ausführlicher
beschrieben wird.
-
Die
Scheduler 107 können
an den Registersatz gekoppelt werden, der die physischen Register des
Prozessors, in 1 mit Umgehungslogik im Feld 108 gezeigt,
umfaßt.
Der Registersatz und die Umgehungslogik 108 können mit
dem Datencache und der Logik der funktionellen Einheiten 109 verbunden
sein, die die zur Ausführung
geplanten Befehle ausführt.
Ein L2-Cache 110 kann mit dem Datencache und der Logik
der funktionellen Einheiten 109 verbunden sein, um über eine
Speicherschnittstelle 111 aus dem Speicher-Subsystem (nicht
dargestellt) wiedererlangte Daten bereitzustellen.
-
Wie
bereits erwähnt,
kann das Behandeln eines Cache-Miss für eine Ladung, die im L2-Cache fehlt,
als eine Operation mit langer Latenz angesehen werden. Andere Beispiele
für Operationen
mit langer Latenz umfassen Gleitkommaoperationen und abhängige Ketten
von Gleitkommaoperationen. Da Befehle von der Pipeline verarbeitet
werden, können Befehle,
die von Operationen mit langer Latenz abhängen, als Slice-Befehle eingestuft
werden und müssen
eine besondere Behandlung gemäß Ausführungsformen
der vorliegenden Erfindung erhalten, um zu verhindern, dass die
Slice-Befehle den Pipelinedurchsatz blockieren oder verlangsamen.
Ein Slice-Befehl kann ein unabhängiger
Befehl sein, wie z. B. ein Laden, das einen Cache-Miss erzeugt,
oder ein Befehl, der von einem anderen Slice-Befehl abhängt, wie
z. B. ein Befehl, der das durch den Ladebefehl geladene Register
liest.
-
Wenn
ein Slice-Befehl in der Pipeline auftritt, kann er im Slice-Datenpuffer 101 an
seinem Platz in einer Planungsreihenfolge von Befehlen gespeichert werden,
wie von den Scheduler 107 festgelegt wird. Ein Scheduler
ordnet Befehle normalerweise in der Reihenfolge der Datenabhängigkeit.
Der Slice-Befehl kann im Slice-Datenpuffer gemeinsam mit zumindest einem
Teil der Informationen gespeichert werden, die notwendig sind, um
den Befehl auszuführen.
Zum Beispiel können
die Informationen den Wert eines Quelloperanden, falls verfügbar, und
die physische Registerabbildung des Befehls umfassen. Die physische
Registerabbildung bewahrt die zu dem Befehl gehörende Datenabhängigkeitsinformation.
Durch Speichern jedes verfügbaren
Quellenwerts und der physischen Registerabbildung zusammen mit dem Slice-Befehl
im Slice-Datenpuffer kann das zugehörige Register freigegeben und
für andere
Befehle wieder angefordert werden, sogar bevor der Slice-Befehl erfüllt ist.
Wenn der Slice-Befehl anschließend
wieder in die Pipeline eingeführt
wird, um seine Ausführung zu
erfüllen,
kann es ferner unnötig
sein, zumindest einen seiner Quelloperanden erneut zu berechnen, während die
physische Registerabbildung sicherstellt, dass der Befehl an der
richtigen Stelle in einer Slice-Befehlsfolge ausgeführt wird.
-
Gemäß Ausführungsformen
der vorliegenden Erfindung kann ein Erkennen von Slice-Befehlen dynamisch
ausgeführt
werden, indem Register- und Speicherabhängigkeiten von Operationen
mit langer Latenz verfolgt werden. Spezieller können Slice-Befehle durch Verteilen
eines Slice-Befehl-Indikators über
physische Register und Speicherwarteschlangeneinträge erkannt
werden. Eine Speicherwarteschlange ist eine Struktur (in 1 nicht
dargestellt) im Prozessor zum Halten von Speicherbefehlen, die für das Schreiben
in den Speicher in einer Warteschlange vorgesehen sind. Lade- und
Speicherbefehle können
Felder in Speicherwarteschlangeneinträgen lesen bzw. schreiben. Der
Slice-Befehl-Indikator kann ein Bit sein, das im Folgenden als „Not a
Value” (NAV)-Bit
bezeichnet wird, das jedem physischen Register und Speicherwarteschlangeneintrag zugeordnet
ist. Das Bit kann anfänglich
nicht gesetzt sein (hat z. B. einen Logikwert von „0”), kann
aber gesetzt werden (z. B. auf logisch „1”), wenn ein zugehöriger Befehl
von Operationen mit langer Latenz abhängt.
-
Das
Bit kann anfänglich
für einen
unabhängigen
Slice-Befehl gesetzt werden und dann an Befehle verteilt werden,
die direkt oder indirekt von dem unabhängigen Befehl abhängen. Spezieller
kann das NAV-Bit des Zielregisters eines unabhängigen Slice-Befehls im Scheduler,
wie z. B. ein Laden, das den Cache verfehlt, gesetzt werden. Nachfolgende Befehle
mit diesem Zielregister als Quelle können das NAV-Bit „erben”, indem
die NAV-Bits in
ihren jeweiligen Zielregistern ebenfalls gesetzt werden können. Wenn
der Zieloperand eines Speicherbefehls ein gesetztes NAV-Bit hat,
kann das NAV-Bit des Speicherwarteschlangeneintrags, das dem Speicher entspricht,
gesetzt werden. Für
nachfolgende Ladebefehle, die entweder aus diesem Speicherwarteschlangeneintrag
lesen oder voraussichtlich daraus weiterleiten, kann das NAV-Bit
in ihren jeweiligen Zielen gesetzt werden. Die Befehlseinträge im Scheduler
können
ebenfalls mit NAV-Bits für
ihre Quell- und Zieloperanden versehen sein, die den NAV-Bits im physischen
Registersatz und den Speicherwarteschlangeneinträgen entsprechen. Die NAV-Bits
in den Schedulereinträgen
können
als entsprechende NAV-Bits in den physischen Registern gesetzt werden,
und es werden Speicherwarteschlangeneinträge gesetzt, um die Schedulereinträge als Slice-Befehle
enthaltend zu kennzeichnen. Durch das vorangehende Verfahren kann
im Scheduler eine Abhängigkeitskette
von Slice-Befehlen gebildet werden.
-
Im
normalen Verlauf von Operationen in einer Pipeline kann ein Befehl
den Scheduler verlassen und ausgeführt werden, wenn seine Quellregister
bereit sind, das heißt,
die Werte enthalten, die notwendig sind, damit der Befehl abläuft und
ein gültiges
Ergebnis ergibt. Ein Quellregister kann bereit werden, wenn zum
Beispiel ein Quellbefehl ausgeführt
und ein Wert in das Register geschrieben wurde. Ein solches Register
wird hier als ein „abgeschlossenes Quellregister” bezeichnet.
Gemäß Ausführungsformen
der vorliegenden Erfindung kann ein Quellregister als bereit angesehen
werden, wenn es entweder ein abgeschlossenes Quellregister ist,
oder wenn sein NAV-Bit gesetzt ist. Folglich kann ein Slice-Befehl
den Scheduler verlassen, wenn jedes seiner Quellregister ein abgeschlossenes
Quellregister ist, und wenn jedes Quellregister, das kein abgeschlossenes
Quellregister ist, sein NAV-Bit gesetzt hat. Slice-Befehle und Nicht-Slice-Befehle
können
daher ohne die durch Abhängigkeit
von Operationen mit langer Latenz verursachten Verzögerungen
aus der Pipeline in einem konstanten Fluß „ablaufen” und ermöglichen den nachfolgenden Befehlen,
Schedulereinträge
zu erlangen.
-
Die
Operationen, die ausgeführt
werden, wenn ein Slice-Befehl den Scheduler verlässt, können das Aufzeichnen des Wertes
jedes abgeschlossenen Quellregisters des Befehls im Slice-Datenpuffer
zusammen mit dem Befehl selbst umfassen und das Kennzeichnen jedes
abgeschlossenen Quellregisters als gelesen markieren. Dies ermöglicht es, dass
das abgeschlossene Quellregister zur Verwendung durch andere Befehle
wieder angefordert wird. Die physische Registerabbildung des Befehls
kann ebenfalls im Slice-Datenpuffer
aufgezeichnet werden. Eine Mehrzahl von Slice-Befehlen (ein „Slice”) kann
im Slice-Datenpuffer zusammen mit entsprechenden Werten abgeschlossener
Quellregister und physischen Registerabbildungen aufgezeichnet werden.
Angesichts des Voranstehenden kann ein Slice als eigenständiges Programm
angesehen werden, das wieder in die Pipeline eingeführt werden
kann, wenn die Operationen mit langer Latenz, von denen es abhängt, abgeschlossen
sind, und das effizient ausgeführt
werden kann, da die einzige Eingabe, die notwendig ist, damit der
Slice abläuft,
die Daten des Ladevorgangs sind (unter der Annahme, die Operation
mit langer Latzenz ist die Behandlung eines Cache-Miss). Andere
Eingaben, wie die Werte abgeschlossener Quellregister, wurden in
den Slice-Datenpuffer kopiert oder werden intern für den Slice
erzeugt.
-
Ferner
können,
wie bereits erwähnt,
die Zielregister der Slice-Befehle für erneute Anforderung und Verwendung
durch andere Befehle freigegeben werden, was Druck auf den Registersatz
abbaut.
-
In
Ausführungsformen
kann der Slice-Datenpuffer eine Mehrzahl von Einträgen enthalten.
Jeder Eintrag kann eine Mehrzahl von Feldern enthalten, die jedem
Slice-Befehl entsprechen, einschließlich eines Feldes für den Slice-Befehl
selbst, ein Feld für den
Wert eines abgeschlossenen Quellregisters und Felder für die physischen
Registerabbildungen der Quell- und Zielregister des Slice-Befehls.
Slice-Datenpuffereinträge
können
zugewiesen werden, wenn Slice-Befehle den Scheduler verlassen, und
die Slice-Befehle können,
wie bereits erwähnt,
im Slice-Datenpuffer in der Reihenfolge gespeichert werden, die
sie im Scheduler hatten. Die Slice-Befehle können zu gegebener Zeit in derselben
Reihenfolge an die Pipeline zurückgegeben
werden. Zum Beispiel könnten
die Befehle in Ausführungsformen über die μop-Warteschlagen 107 wieder
in die Pipeline eingeführt
werden, aber es sind andere Anordnungen möglich. In Ausführungsformen
kann der Slice-Datenpuffer
ein SRAM (statisches Random Access Memory) mit hoher Dichte sein,
das ein Array mit langer Latenz und hoher Bandbreite implementiert, ähnlich wie
ein L2-Cache.
-
Nun
wird wiederum auf 1 Bezug genommen. Wie in 1 dargestellt
und bereits beschrieben kann eine Slice-Prozessoreinheit 100 gemäß Ausführungsformen
der vorliegenden Erfindung einen Slice-Umbenennungsfilter 102 und
einen Slice-Remapper 103 umfassen. Der Slice-Remapper 103 kann
auf eine Weise, die analog zu der Art ist, in der die Zuweisungs-
und Registerumbenennungslogik 105 logische Register auf
physische Register abbildet, neue physische Register auf die physischen Registerkennzeichner
der physischen Registerabbildungen im Slice-Datenpuffer abbilden.
Diese Operation kann notwendig sein, weil die Register der ursprünglichen
physischen Registerabbildung wie oben beschrieben freigegeben wurden.
Diese Register wurden wahrscheinlich erneut angefordert und werden
von anderen Befehlen verwendet, wenn ein Slice bereit ist, wieder
in die Pipeline eingeführt
zu werden.
-
Der
Slice-Umbenennungsfilter 102 kann für Operationen verwendet werden,
die mit Checkpointing verknüpft
sind, einem bekannten Verfahren in spekulativen Prozessoren. Checkpointing
kann ausgeführt
werden, um den Zustand der architektonischen Register eines bestimmten
Threads zu einem bestimmten Zeitpunkt zu bewahren, so dass der Zustand
bei Bedarf leicht wiederhergestellt werden kann. Zum Beispiel kann
ein Checkpointing bei einer Programmverzweigung mit geringer Zuverlässigkeit ausgeführt werden.
-
Wenn
ein Slice-Befehl in ein physisches Checkpoint-Register schreibt,
sollte diesem Befehl kein neues physisches Register durch den Remapper 103 zugewiesen
werden. Statt dessen muss das gecheckpointete physische Register
auf dasselbe physische Register abgebildet werden, das ihm ursprünglich durch
die Zuweisungs- und Registerumbenennungslogik 105 zugewiesen
wurde, da ansonsten der Checkpoint korrumpiert/ungültig werden
würde.
Der Slice-Umbenennungsfilter 102 stellt dem Slice-Neuzuordner 103 die
Informationen zur Verfügung,
welche physischen Register gecheckpointet sind, so dass der Slice-Remapper 103 den
gecheckpointeten physischen Registern ihre ursprünglichen Abbildungen zuweisen
kann. Wenn die Ergebnisse von Slice-Befehlen, die in gecheckpointete Register schreiben,
verfügbar
sind, können
sie mit den Ergebnissen von unabhängigen Befehlen, die in gecheckpointete
Register schreiben, die früher
abgeschlossen sind, zusammengeführt
oder in diese integriert werden.
-
Gemäß Ausführungsformen
der vorliegenden Erfindung kann der Slice-Remapper 103 eine größere Anzahl
von physischen Registern zur Verfügung haben, um sie den physischen
Registerabbildungen von Slice-Befehlen zuzuweisen, als die Zuweisungs-
und Registerumbenennungslogik 105. Dies kann der Fall sein,
um Deadlocks aufgrund von Checkpointing zu vermeiden. Insbesondere
kann es sein, dass physische Register nicht verfügbar sind, um auf Slice-Befehle
neu abgebildet zu werden, weil die physischen Register durch Checkpoints
belegt sind. Andererseits kann es der Fall sein, dass die durch
die Checkpoints belegten physischen Register erst dann freigegeben
werden können,
wenn die Slice-Befehle abgeschlossen sind. Diese Situation kann
zu einem Deadlock führen.
-
Entsprechend
könnte,
wie oben erwähnt,
der Slice-Remapper einen Bereich von physischen Registern zum Abbilden
zur Verfügung
haben, der größer als
der der Zuweisungs- und
Registerumbenennungslogik 105 zur Verfügung stehende Bereich ist. Zum
Beispiel könnte
es 192 tatsächliche
physische Register in einem Prozessor geben, wobei 128 davon der
Zuweisungs- und Registerumbenennungslogik 105 zum Abbilden
auf Befehle zur Verfügung
gestellt werden könnten,
während
die gesamte Menge von 192 dem Slice-Remapper zur Verfügung stehen
würde.
Folglich stünden
in diesem Beispiel 64 dem Slice-Remapper zusätzliche physische Register
zur Verfügung,
um sicherzustellen, dass keine Deadlocksituation auftritt, weil
keine Register im Basissatz von 128 zur Verfügung stehen.
-
Nun
wird unter Bezugnahme auf die Elemente von 1 ein Beispiel
angegeben. Es wird angenommen, dass jedem Befehl in der unten aufgeführten Folge
von Befehlen (1) und (2) ein entsprechender Schedulereintrag in
den Schedulern 107 zugewiesen wurde. Um der Kürze willen
nehmen wir ferner an, dass die angezeigten Registerkennzeichner die
physische Registerabbildung darstellen, d. h. sie beziehen sich
auf die durch die Befehle zugewiesenen physischen Register, auf
die die logischen Register der Befehle abgebildet wurden. Folglich
ist für
jeden physischen Registerkennzeichner ein entsprechendes logisches
Register impliziert. R1 ← Mx (1)(lade die
Inhalte des Speicherortes, dessen Adresse Mx ist, in das physische
Register R1) R2 ← R1 + R3 (2)(addiere
die Inhalte der physischen Register R1 und R3 und setze das Ergebnis
in physisches Register R2)
-
In
den Schedulern 107 warten Befehle (1) und (2) auf ihre
Ausführung.
Wenn ihre Quelloperanden verfügbar
werden, können
die Befehle (1) und (2) den Scheduler verlassen und ablaufen, wodurch
ihre jeweiligen Einträge
in den Schedulern 107 für
andere Befehle verfügbar
werden. Der Quelloperand des Ladebefehls (1) ist eine Speicherstelle,
und folglich erfordert Befehl (1), dass die richtigen Daten aus
der Speicherstelle im L1-Cache (nicht dargestellt) oder im L2-Cache 110 vorhanden
sind. Befehl (2) ist von Befehl (1) abhängig, da es für ihn notwendig
ist, dass Befehl (1) erfolgreich abläuft, damit die richtigen Daten
im Register R1 vorhanden sind. Es ist anzunehmen, dass Register
R3 ein abgeschlossenes Quellregister ist.
-
Nun
ist ferner anzunehmen, dass der Ladebefehl, Befehl (1), im L2-Cache 110 fehlschlägt. Normalerweise
könnte
es hunderte von Zyklen dauern, bis der Cache-Miss behandelt wird.
Während
dieser Zeit stünden
in einem herkömmlichen
Prozessor die von Befehl (1) und (2) besetzten Schedulereinträge anderen
Befehlen nicht zur Verfügung,
wodurch der Durchsatz gebremst und die Leistung gesenkt wird. Außerdem würden die
physischen Register R1, R2 und R3 zugewiesen bleiben, während der
Cache-Miss behandelt wird, was Druck auf den Registersatz erzeugt.
-
Im
Gegensatz dazu können
Befehle (1) und (2) gemäß Ausführungsformen
der vorliegenden Erfindung auf die Slice-Prozessoreinheit 100 umgeleitet
werden und ihre entsprechenden Scheduler- und Registersatzressourcen
für die
Verwendung durch andere Befehle in der Pipeline freigemacht werden. Spezieller
kann das NAV-Bit in R1 gesetzt werden, wenn der Befehl (1) im Cache
fehlschlägt,
und dann, auf Grundlage der Tatsache, dass der Befehl (2) R1 liest,
auch in R2 gesetzt werden. Nachfolgende, nicht dargestellte Befehle,
die R1 oder R2 als Quellen haben, hätten ebenfalls das NAV-Bit
in ihren jeweiligen Zielregistern gesetzt. Die NAV-Bits in den Schedulereinträgen, die
den Befehlen entsprechen, würden ebenfalls
gesetzt werden, was sie als Slice-Befehle kennzeichnet.
-
Befehl
(1) ist insbesondere ein unabhängiger Slice-Befehl,
weil er als Quelle kein Register oder keinen Speicherwarteschlangeneintrag
hat. Andererseits ist Befehl (2) ein abhängiger Slice-Befehl, weil er
als Quelle ein Register hat, dessen NAV-Bit gesetzt ist.
-
Weil
das NAV-Bit in R1 gesetzt ist, kann Befehl (1) die Scheduler 107 verlassen.
Dem Verlassen der Scheduler 107 folgend wird Befehl (1)
in den Slice-Datenpuffer 101 geschrieben, zusammen mit seiner
physischen Registerabbildung R1 (an ein logisches Register). In ähnlicher
Weise kann Befehl (2), weil das NAV-Bit in R1 gesetzt ist und weil
R3 ein abgeschlossenes Quellenregister ist, die Scheduler 107 verlassen,
worauf Befehl (2), der Wert von R3 und die physischen Registerabbildungen
R1 (an ein logisches Register), R2 (an ein logisches Register) und R3
(an ein logisches Register) in den Slice-Datenpuffer 101 geschrieben
werden. Befehl (2) kommt nach Befehl (1) in den Slice-Datenpuffer,
genau wie dies in den Scheduler der Fall war. Die Schedulereinträge, die
bisher von Befehlen (1) und (2) und besetzt waren und Register R1,
R2 und R3, können
nun alle erneut angefordert und für die Verwendung durch andere Befehle
verfügbar
gemacht werden.
-
Wenn
der durch Befehl (1) erzeugte Cache-Miss behoben ist, können Befehle
(1) und (2) in ihrer ursprünglichen
Planungsreihenfolge mit einer vom Slice-Remapper 103 ausgeführten neuen
physischen Registerabbildung wieder in die Pipeline eingeführt werden.
Der Wert des abgeschlossenen Quellregisters kann als Direktoperand
mit den Befehlen mitgeschickt werden. Die Befehle können anschließend ausgeführt werden.
-
Angesichts
der vorangegangenen Beschreibung zeigt 2 einen
Prozessablauf gemäß Ausführungsformen
der vorliegenden Erfindung. Wie in Feld 200 dargestellt,
kann der Prozess das Erkennen eines Befehls in einer Prozessor-Pipeline
als einen von einer Operation mit langer Latenz abhängigen umfassen.
Zum Beispiel könnte
der Befehl ein Ladebefehl sein, der einen Cache-Miss erzeugt.
-
Wie
in Feld 201 dargestellt, kann auf der Grundlage des Erkennens
veranlasst werden, dass der Befehl die Pipeline verläßt, ohne
ausgeführt
worden zu sein und zusammen mit zumindest einem Teil der Informationen,
die notwendig sind, um den Befehl auszuführen, in einen Slice-Datenpuffer
verschoben wird. Dieser zumindest eine Teil der Informationen kann
einen Wert eines Quellregisters und eine physische Registerabbildung
umfassen. Der Schedulereintrag und das (die) durch den Befehl zugewiesene(n)
physische(n) Register können
freigegeben und für
die Verwendung durch einen anderen Befehl erneut angefordert werden,
wie in Feld 202 dargestellt.
-
Nachdem
die Operationen mit langer Wartezeit abgeschlossen sind, kann der
Befehl wieder in die Pipeline eingeführt werden, wie in Feld 203 dargestellt.
Der Befehl kann einer aus einer Mehrzahl von Befehlen sein, die
auf der Grundlage der Tatsache, dass sie als von einer Operation
mit langer Latenz abhängig
erkannt wurden, aus der Pipeline in den Slice-Datenpuffer verschoben wurden. Die Mehrzahl
kann in den Slice-Datenpuffer in einer Planungsreihenfolge verschoben
und in derselben Reihenfolge wieder in die Pipeline eingeführt werden.
Der Befehl kann dann ausgeführt
werden, wie in Feld 204 dargestellt.
-
Es
ist zu beachten, dass, um in einer Architektur für die Bearbeitung und Wiederherstellung
von Checkpoints, die eine Pipeline mit konstantem Durchsatz umsetzt,
eine präzise
Ausnahmenbehandlung und Wiederherstellung von Programmverzweigungen
zu ermöglichen,
zwei Arten von Registern solange nicht freigegeben werden sollten,
bis der Checkpoint nicht länger
erforderlich ist: Register, die zum architektonischen Zustand des
Checkpoints gehören,
und Register, die architektonischen „Live-outs” entsprechen. Wie bekannt
ist, sind Liveout-Register die logischen Register und entsprechenden
physischen Register, die den aktuellen Zustand eines Programms abbilden.
Spezieller entspricht ein Liveout-Register dem letzten oder aktuellsten
Befehl eines Programms, um in ein bestimmtes logisches Register
aus dem logischen Befehlssatz eines Prozessors zu schreiben. Von
den Liveout-Registern und den gecheckpointeten Registern gibt es
jedoch nur eine kleine Anzahl (in der Größenordnung logischer Befehle)
im Vergleich zum physischen Registersatz.
-
Die übrigen physischen
Register können
erneut angefordert werden, wenn (1) alle nachfolgenden Befehle,
die die Register lesen, sie gelesen haben, und (2) die physischen
Register anschließend neu
abgebildet, d. h. überschrieben,
wurden. Eine Pipeline mit konstantem Durchsatz gemäß Ausführungsformen
der vorliegenden Erfindung garantiert Bedingung (1), weil abgeschlossene
Quellregister als für
Slice-Befehle gelesen gekennzeichnet werden, noch bevor die Slice-Befehle
ausgeführt
sind, aber nachdem sie den Wert der abgeschlossenen Queliregister
gelesen haben. Bedingung (2) ist während des normalen Bearbeitens
selbst erfüllt – für L logische Register
wird der (L + 1)-te Befehl, der eine neue physische Registerabbildung
erfordert, eine frühere
physische Registerabbildung überschreiben.
Folglich werden für
jede Menge N von Befehlen mit einem Zielregister, die die Pipeline
verlassen, N –L
physische Register überschrieben
und folglich wird Bedingung (2) erfüllt.
-
Indem
sichergestellt wird, dass die Werte abgeschlossener Quellregister
und Informationen zur physischen Registerabbildung für einen
Slice aufgezeichnet werden, können
also Register mit einer solchen Geschwindigkeit erneut angefordert
werden, dass jedes Mal, wenn ein Befehl ein physisches Register
erfordert, ein solches Register immer verfügbar ist – wodurch die Eigenschaft eines
konstanten Durchsatzes erzielt wird.
-
Es
wird ferner angemerkt, dass der Slice-Datenpuffer bedingt durch
mehrere unabhängige
Ladevorgänge
mehrere Slices enthalten kann. Wie bereits beschrieben, sind die
Slices im wesentlichen in sich abgeschlossene Programme, die nur
darauf warten, dass Datenwerte eines Ladefehlers zurückkommen, um
für die
Ausführung
bereit zu sein. Wenn die Datenwerte eines Ladefehlers verfügbar sind,
können die
Slices in jeder Reihenfolge abgerufen (in die Pipeline wieder eingeführt) werden.
Das Behandeln von Ladefehlern kann außerhalb der Reihenfolge abgeschlossen
werden, und daher kann zum Beispiel ein Slice, der zu einem späteren Fehler
im Slice-Datenpuffer gehört,
früher
für das
Wiedereinführen
in die Pipeline bereit sein, als ein früherer Slice im Slice-Datenpuffer.
Es gibt eine Mehrzahl von Möglichkeiten
für die
Behandlung dieser Situation: (1) warten, bis der älteste Slice
bereit ist, und Entleeren des Slice-Datenpuffers in einer First-In-First-Out
Reihenfolge, (2) Entleeren des Slice-Datenpuffers in einer First-In-First-Out
Reihenfolge, wenn irgendein Fehler im Slice-Datenpuffer zurückkommt,
und (3) Entleeren des Slice-Datenpuffers der Reihe nach ab dem behandelten
Fehler (führt
nicht notwendigerweise dazu, dass der älteste Slice zuerst entleert
wird).
-
3 ist
ein Blockdiagramm eines Rechnersystems, das einen architektonischen
Zustand umfassen kann, das ein oder mehrere Prozessorpakete und
einen Speicher zur Verwendung gemäß einer Ausführungsform
der vorliegenden Erfindung umfaßt.
In 3 kann ein Rechnersystem 300 ein oder mehrere
Prozessorpakete 310(1)–310(n) umfassen, verbunden
mit einem Prozessorbus 320, der mit einer Systemlogik 330 verbunden
sein kann. Jedes des einen oder der mehreren Prozessorpakete 310(1)–310(n) kann
ein N-Bit-Prozessorpaket
sein und kann einen Decoder (nicht dargestellt) und ein oder mehrere
N-Bit-Register (nicht
dargestellt) umfassen. Die Systemlogik 330 kann über einen
Bus 350 mit einem Systemspeicher 340 verbunden
sein und kann durch einen peripheren Bus 360 mit einem nicht-flüchtigen
Speicher 370 und einer oder mehreren peripheren Vorrichtungen 380(1)–380(m) verbunden
sein. Der periphere Bus 360 kann zum Beispiel einen oder
mehrere Peripheral Component Interconnect (PCI)-Busse, PCI-Special
Interest Group(SIGH)PCI-Local
Bus Spezifikation, Ausgabe 2.3, veröffentlicht am 18. Dezember
1998, Industry Standard Architecture (ISA)-Busse, Extended ISA(EISA)-Busse,
BCPR Services Inc. EISA-Spezifikation,
Version 3.12, 1992, veröffentlicht
im Jahr 1992, Universal Serial Bus (USB), USB – Spezifikation, Version 1.1,
veröffentlicht
am 23. September 1998, und vergleichbare periphere Busse umfassen. Der
nicht-flüchtige
Speicher 370 kann eine statische Speichervorrichtung, wie
z. B. ein Read-Only-Memory (ROM) oder ein Flash-Speicher sein. Periphere Vorrichtungen 380(1)–380(m) können zum
Beispiel eine Tastatur umfassen; eine Maus oder eine andere Zeigevorrichtung,
Massenspeichervorrichtungen, wie z. B. Harddisk-Laufwerke, Compact Disc(CD)-Laufwerke,
optische Laufwerke und Digital Video Disc(DVD)-Laufwerke; Anzeigen
und ähnliches.
-
Mehrere
Ausführungsformen
der vorliegenden Erfindung sind hier speziell dargestellt und/oder beschrieben.
Es ist jedoch anzuerkennen, dass Abwandlungen und Variationen der vorliegenden
Erfindung durch die oben angeführten
Lehren und innerhalb des Schutzbereichs der beigefügten Ansprüche abgedeckt
sind, ohne von der Idee und dem vorgesehenen Umfang der Erfindung
abzuweichen.