PatentDe  


Dokumentenidentifikation DE112005002403T5 16.08.2007
Titel Prozessor-Pipeline mit konstantem Durchsatz
Anmelder Intel Corp., Santa Clara, Calif., US
Erfinder Akkary, Haitham, Portland, Oreg., US;
Rajwar, Ravi, Portland, Oreg., US;
Srinivasan, Srikanth, Portland, Oreg., US
Vertreter BOEHMERT & BOEHMERT, 28209 Bremen
DE-Aktenzeichen 112005002403
Vertragsstaaten AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KM, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, LY, MA, MD, MG, MK, MN, MW, MX, MZ, NA, NG, NI, NO, NZ, OM, PG, PH, PL, PT, RO, RU, SC, SD, SE, SG, SK, SL, SM, SY, TJ, TM, TN, TR, TT, TZ, UA, UG, US, UZ, VC, VN, YU, ZA, ZM, ZW, EP, AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, IS, IT, LT, LU, LV, MC, NL, PL, PT, RO, SE, SI, SK, TR, OA, BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, TG, AP, BW, GH, GM, KE, LS, MW, MZ, NA, SD, SL, SZ, TZ, UG, ZM, ZW, EA, AM, AZ, BY, KG, KZ, MD, RU, TJ, TM
WO-Anmeldetag 21.09.2005
PCT-Aktenzeichen PCT/US2005/034145
WO-Veröffentlichungsnummer 2006039201
WO-Veröffentlichungsdatum 13.04.2006
Date of publication of WO application in German translation 16.08.2007
Veröffentlichungstag im Patentblatt 16.08.2007
IPC-Hauptklasse G06F 9/38(2006.01)A, F, I, 20050921, B, H, DE

Beschreibung[de]
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 Servern 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 beeinflußt, 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, daß 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, daß der Registersatz gezwungen sein kann, Tausende von Befehlen vorzuhalten, und daß er normalerweise eine energiehungrige, zyklusempfindliche, durchgängig getaktete Struktur ist.

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 Fluß, 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 daß 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 &mgr;op-(„Mikro"-Operations-, d.h. Befehls-)Warteschlangen 106 gekoppelt werden, um Befehle zur Ausführung in Reihe zu bringen, und die &mgr;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, daß 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 Schedulern 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, daß 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 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äßt, 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. Dies ermöglicht es, daß 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 Zielregistern 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 &mgr;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 ist 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 daß der Zustand bei Bedarf leicht wiederhergestellt werden kann. Zum Beispiel kann ein Checkpointing bei einer Programmsverzweigung mit niedriger 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 muß das mit 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 daß der Slice-Remapper 102 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, daß 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, daß 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, daß 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. Angenommen, daß 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, daß 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), daß 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, daß Befehl (1) erfolgreich abläuft, damit die richtigen Daten im Register R1 vorhanden sind. Es ist anzunehmen, daß Register R3 ein abgeschlossenes Quellregister ist.

Nun ist ferner anzunehmen, daß 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, daß 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 Schedulern 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 Prozeßablauf gemäß Ausführungsformen der vorliegenden Erfindung. Wie in Feld 200 dargestellt, kann der Prozeß 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 veranlaßt werden, daß 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 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, daß sie als von einer Operation mit langer Latenz abhängig erkannt wurden, aus der Pipeline in den Slice-Datenpuffer verschobenen 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, daß, 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 Quellregister 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 überschritten und folglich wird Bedingung (2) erfüllt.

Indem sichergestellt wird, daß 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, daß jedes Mal, wenn ein Befehl ein physisches Register erfordert, ein solches Register immer verfügbar ist – weswegen die Eigenschaft eines konstanten Durchsatzes erzielt wird.

Es wird ferner angemerkt, daß 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, daß 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 behandelte Fehler (führt nicht notwendigerweise dazu, daß 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 ein 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 umfassen, 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. 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, daß Abwandlungen und Variationen der vorliegenden Erfindung durch die oben angeführten Lehren und innerhalb des Bereichs der beigefügten Ansprüche abgedeckt sind, ohne von der Idee und dem vorgesehenen Umfang der Erfindung abzuweichen.

Zusammenfassung

Ausführungsformen der vorliegenden Erfindung betreffen ein System und Verfahren zum verhältnismäßigen Steigern des Prozessordurchsatzes und zum Abbauen der Belastung des Schedulers und Registersatzes des Prozessors durch Abziehen von Befehlen, die von Operationen mit langer Latenz abhängig sind, aus dem Fluß in der Prozessor-Pipeline und deren Wiedereinführen in den Fluß, 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.


Anspruch[de]
Verfahren, umfassend:

Erkennen eines Befehls in einer Prozessor-Pipeline als einen Befehl, der von einer Operation mit langer Latenz abhängig ist,

Veranlassen auf der Grundlage des Erkennens, daß der Befehl in einem Datenspeicherbereich angeordnet wird zusammen mit zumindest einem Teil der Informationen, die notwendig sind, um den Befehl auszuführen, und

Freigeben eines durch den Befehl zugewiesenen physischen Registers.
Das Verfahren nach Anspruch 1, ferner umfassend das Freigeben eines durch den Befehl besetzten Schedulereintrags. Das Verfahren nach Anspruch 1, ferner umfassend:

Wiedereinführen des Befehls in die Pipeline, nachdem die Operation mit langer Latenz abgeschlossen ist.
Das Verfahren nach Anspruch 1, wobei der zumindest eine Teil der Informationen einen Wert eines Quellregisters des Befehls umfaßt. Das Verfahren nach Anspruch 1, wobei der zumindest eine Teil der Informationen eine physische Registerabbildung des Befehls umfaßt. Das Verfahren nach Anspruch 1, wobei der Befehl einer aus einer Mehrzahl von Befehlen in der Pipeline ist, die von einer Operation mit langer Latenz abhängen, und wobei die Mehrzahl von Befehlen in einer Planungsreihenfolge der Befehle in dem Datenspeicherbereich angeordnet wird. Das Verfahren nach Anspruch 1, ferner umfassend:

Wiedereinführen der Mehrzahl von Befehlen in die Pipeline in der Planungsreihenfolge, nachdem die Operation mit langer Latenz abgeschlossen ist.
Prozessor, umfassend:

einen Datenspeicherbereich, um die Befehle zu speichern, die als von einer Operation mit langer Latenz abhängig erkannt wurden, wobei der Datenspeicherbereich für jeden Befehl ein Feld für den Befehl, ein Feld für einen Wert eines Quellregisters des Befehls und ein Feld für eine physische Registerabbildung eines Registers des Befehls umfaßt.
Der Prozessor nach Anspruch 8, ferner umfassend:

einen mit dem Datenspeicherbereich verbundenen Remapper, um physische Register auf physische Registerkennzeichner der physischen Registerabbildungen des Datenspeicherbereichs abzubilden.
Der Prozessor nach Anspruch 8, ferner umfassend einen Filter, um mit Checkpoints versehene Register für den Remapper zu kennzeichnen. System, umfassend:

einen Speicher, um Befehle zu speichern, und

ein mit dem Speicher verbundener Prozessor, um die Befehle auszuführen, wobei der Professor einen Datenspeicherbereich umfaßt, um die Befehle zu speichern, die als von einer Operation mit langer Latenz abhängig erkannt wurden, wobei der Datenspeicherbereich für jeden Befehl ein Feld für den Befehl, ein Feld für einen Wert eines Quellregisters des Befehls und ein Feld für eine physische Registerabbildung eines Registers des Befehls umfaßt.
Das System nach Anspruch 11, wobei der Prozessor ferner umfaßt:

einen mit dem Datenspeicherbereich verbundenen Remapper, um physische Register auf physische Registerkennzeichner der physischen Registerabbildungen des Datenspeicherbereichs abzubilden.
Das System nach Anspruch 11, wobei der Prozessor ferner umfaßt:

einen Filter, um mit Checkpoints versehene Register für den Remapper zu kennzeichnen.
Verfahren, umfassend:

Ausführen eines Ladebefehls, der einen Cache-Miss erzeugt,

Setzen eines Indikators in einem Zielregister, das dem Ladebefehl zugewiesen ist, um anzuzeigen, daß der Ladebefehl von einer Operation mit langer Latenz abhängt,

Verschieben des Ladebefehls in einen Datenspeicherbereich zusammen mit zumindest einem Teil der Informationen, die zum Ausführen des Ladebefehls notwendig sind, und

Freigeben des dem Ladebefehl zugewiesenen Zielregisters.
Das Verfahren nach Anspruch 14, ferner umfassend:

Setzen eines Indikators in einem Zielregister eines anderen Befehls auf der Grundlage des im Zielregister des Ladebefehls gesetzten Indikators,

Verschieben des anderen Befehls in einen Datenspeicherbereich zusammen mit zumindest einem Teil der Informationen, die zum Ausführen des anderen Befehls notwendig sind, und

Freigeben des dem anderen Befehl zugewiesenen Zielregisters.
Das Verfahren nach Anspruch 15, ferner umfassend Freigeben der durch den Ladebefehl und den anderen Befehl zugewiesenen Schedulereinträge. Das Verfahren nach Anspruch 15, wobei der zumindest eine Teil der Informationen eine physische Registerabbildung des anderen Befehls umfaßt. Das Verfahren nach Anspruch 15, ferner umfassend:

Wiedereinführen des Ladebefehls und des anderen Befehls in eine Prozessor-Pipeline in einer Planungsreihenfolge, nachdem die Operation mit langer Latenz abgeschlossen ist.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com