DE102012216567A1 - Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes - Google Patents

Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes Download PDF

Info

Publication number
DE102012216567A1
DE102012216567A1 DE102012216567A DE102012216567A DE102012216567A1 DE 102012216567 A1 DE102012216567 A1 DE 102012216567A1 DE 102012216567 A DE102012216567 A DE 102012216567A DE 102012216567 A DE102012216567 A DE 102012216567A DE 102012216567 A1 DE102012216567 A1 DE 102012216567A1
Authority
DE
Germany
Prior art keywords
register
architected
registers
last
instruction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102012216567A
Other languages
English (en)
Inventor
Michael K. Gschwind
Valentina Salapura
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE102012216567A1 publication Critical patent/DE102012216567A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098Register arrangements
    • G06F9/3012Organisation of register space, e.g. banked or distributed register file
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098Register arrangements
    • G06F9/3012Organisation of register space, e.g. banked or distributed register file
    • G06F9/30138Extension of register space, e.g. register cache
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824Operand accessing
    • G06F9/383Operand prefetching
    • G06F9/3832Value prediction for operands; operand history buffers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3838Dependency mechanisms, e.g. register scoreboarding
    • G06F9/384Register renaming
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858Result writeback, i.e. updating the architectural state or memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858Result writeback, i.e. updating the architectural state or memory
    • G06F9/38585Result writeback, i.e. updating the architectural state or memory with result invalidation, e.g. nullification

Landscapes

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

Abstract

Eine Mehrebenen-Registerhierarchie wird beschrieben, die einen Registerpool der ersten Ebene zum Cachespeicher-Zwischenspeichern (caching) von Registern aus einem Registerpool der zweiten Ebene in einem System aufweist, in welchem Programme architekturdefinierte Register dynamisch freigeben und wieder aktivieren können, so dass freigegebene architekturdefinierte Register nicht vom Prozessor aufrechterhalten zu werden brauchen, wobei der Prozessor auf Operanden aus dem Registerpool der ersten Ebene zugreift, wobei eine Letztverwendungs-Anweisung als eine Letztverwendung eines architekturdefinierten Registers vor seiner Freigabe aufweisend identifiziert wird, wobei das freiwerdende, letztmals verwendete architekturdefinierte Register die Mehrebenen-Registerhierarchie veranlasst, jede Entsprechung eines Eintrags zum letztmals verwendeten architekturdefinierten Register zu löschen.

Description

  • GEBIET
  • Die vorliegende Erfindung betrifft das Gebiet der Prozessoren und insbesondere das Verwalten von Operanden-Cachespeichern auf Grundlage von Anweisungsinformationen.
  • HINTERGRUND
  • Laut Wikipedia, am 1.8.2011 im World Wide Web veröffentlicht, verfügen ”Multithreading-Computer” über Hardware-Unterstützung zum effizienten Ausführen mehrerer Threads. Diese unterscheiden sich von Multiprozessorsystemen (wie Mehrkernsystemen) dadurch, dass die Threads die Ressourcen eines Einzelkerns, nämlich die Datenverarbeitungseinheiten, die CPU-Cachespeicher und den Adressenumsetzpuffer (TLB – translation look-aside buffer), gemeinsam nutzen müssen. Während Multiprozessorsysteme mehrere vollständige Verarbeitungseinheiten enthalten, zielt Multithreading darauf ab, die Auslastung eines Einzelkerns durch Verwendung sowohl von Parallelität auf Thread-Ebene als auch von Parallelität auf Anweisungsebene zu steigern. Da die beiden Techniken einander ergänzen, werden sie bisweilen in Systemen mit mehreren Multithreading-CPUs und in CPUs mit mehreren Multithreading-Kernen kombiniert.
  • Das Multithreading-Paradigma ist populärer geworden, da Bemühungen, Parallelität auf Anweisungsebene weiter auszunutzen, seit den späten 1990er-Jahren auf der Stelle treten. Dies erlaubte dem Konzept der Durchsatz-Datenverarbeitung, aus dem mehr spezialisierten Gebiet der Transaktionsverarbeitung heraus wieder in den Vordergrund zu treten:
    Wenn es auch sehr schwierig ist, einen einzelnen Thread oder ein einzelnes Programm weiter zu beschleunigen, betreiben die meisten Computersysteme eigentlich Multitasking zwischen mehreren Threads oder Programmen.
  • Techniken, die das Beschleunigen des Gesamt-Systemdurchsatzes aller Tasks erlauben würden, wären ein bedeutender Leistungszuwachs.
  • Die beiden bedeutenden Techniken für Durchsatz-Datenverarbeitung sind Multiprocessing und Multithreading.
  • Einige Vorteile sind folgende:
    Wenn ein Thread viele Cachespeicher-Fehlschläge erfährt, kann der andere Thread oder können die anderen Threads fortfahren, indem er bzw. sie die ungenutzten Rechenressourcen ausnutzt bzw. ausnutzen, was somit zu einer schnelleren Gesamtausführung führen kann, da diese Ressourcen inaktiv gewesen wären, wenn nur ein einziger Thread ausgeführt worden wäre.
  • Wenn ein Thread nicht alle Rechenressourcen der CPU nutzen kann (weil Anweisungen auf die Ergebnisse voneinander angewiesen sind), gestattet das Ausführen eines weiteren Threads, diese nicht inaktiv bleiben zu lassen.
  • Wenn mehrere Threads am selben Satz von Daten arbeiten, können sie sogar ihren Cachespeicher gemeinsam nutzen, was zu einer besseren Cachespeicher-Nutzung oder Synchronisation seiner Werte führt.
  • Folgendes sind einige Kritikpunkte am Multithreading:
    Mehrere Threads können miteinander kollidieren, wenn sie Hardware-Ressourcen wie Cachespeicher oder Adressenumsetzpuffer (TLBs) gemeinsam nutzen.
  • Die Ausführungszeiten eines einzelnen Threads werden nicht verbessert, sondern können sich verschlechtern, auch wenn nur ein Thread läuft. Dies liegt an den niedrigeren Frequenzen und/oder zusätzlichen Pipeline-Stufen, die erforderlich sind, um Hardware für das Umschalten von Threads anzupassen.
  • Hardware-Unterstützung für Multithreading ist für die Software sichtbarer und erfordert folglich sowohl an Anwendungsprogrammen als auch an Betriebssystemen mehr Änderungen als Multiprocessing.
  • Es gibt eine Anzahl von Arten des Multithreading:
  • Block-Multithreading
  • Die einfachste Art von Multithreading tritt auf, wenn ein Thread läuft, bis er durch ein Ereignis blockiert wird, das normalerweise eine Blockierung mit langer Latenzzeit erzeugen würde. Eine solche Blockierung könnte ein Fehlschlag des Cachespeichers sein, wobei auf einen Speicher außerhalb des Chips zugegriffen werden muss, was bis zur Lieferung der Daten Hunderte von CPU-Zyklen dauern kann. Statt abzuwarten, bis die Blockierung sich auflöst, würde ein Thread-Prozessor die Ausführung auf einen anderen Thread umschalten, der ausführungsbereit ist. Erst wenn die Daten für den vorherigen Thread angekommen sind, wird der vorherige Thread wieder auf die Liste ausführungsbereiter Threads gesetzt.
    Zum Beispiel:
    • 1. Zyklus i: Anweisung j aus Thread A wird ausgegeben
    • 2. Zyklus i + 1: Anweisung j + 1 aus Thread A wird ausgegeben
    • 3. Zyklus i + 2: Anweisung j + 2 aus Thread A wird ausgegeben, Ladeanweisung, welche in allen Cachespeichern fehlt
    • 4. Zyklus i + 3: Thread-Scheduler aufgerufen, schaltet auf Thread B um
    • 5. Zyklus i + 4: Anweisung k aus Thread B wird ausgegeben
    • 6. Zyklus i + 5: Anweisung k + 1 aus Thread B wird ausgegeben
  • Konzeptionell ähnelt es dem in Echtzeit-Betriebssystemen verwendeten Verbund-Multitasking, bei welchem Tasks ohne äußere Einflüsse Ausführungszeit aufgeben, wenn sie auf irgendeine Art von Ereignis warten müssen.
  • Diese Art von Multithreading ist als Block- oder Verbund- oder grobkörniges Multithreading bekannt.
  • Hardware-Kosten
  • Das Ziel der Hardware-Unterstützung von Multithreading ist, schnelles Umschalten zwischen einem blockierten Thread und einem anderen ausführungsbereiten Thread zu ermöglichen. Um dieses Ziel zu erreichen, sollen die Hardware-Kosten die für Programme sichtbaren Register sowie einige Prozessorsteuerregister (wie den Programmbefehlszähler) nachbilden. Umschalten von einem Thread auf einen anderen Thread bedeutet, dass die Hardware von der Verwendung eines Registersatzes auf einen anderen umschaltet.
  • Solche zusätzliche Hardware hat die folgenden Vorteile:
    Die Thread-Umschaltung kann in einem einzigen CPU-Zyklus erfolgen.
  • Jedem Thread erscheint es, dass er allein läuft und keine Hardware-Ressourcen mit anderen Threads gemeinsam nutzt. Dies minimiert die Menge der Software-Änderungen in der Anwendung und im Betriebssystem, die erforderlich ist, um Multithreading zu unterstützen.
  • Um zügig zwischen aktiven Threads umzuschalten, muss jeder aktive Thread über seinen eigenen Registersatz verfügen. Zum Beispiel um schnell zwischen zwei Threads umzuschalten, muss die Register-Hardware zweimal realisiert werden.
  • Beispiele
  • Viele Familien von Mikrocontrollern und eingebetteten Prozessoren verfügen über mehrere Registerbänke, um bei Interrupts schnelle Kontextwechsel zu ermöglichen. Solche Schemas können als eine Art von Block-Multithreading zwischen dem Benutzerprogramm-Thread und den Interrupt-Threads angesehen werden.
  • Verzahntes Multithreading
    • 1. Zyklus i + 1: eine Anweisung aus Thread B wird ausgegeben
    • 2. Zyklus i + 2: eine Anweisung aus Thread C wird ausgegeben
  • Der Zweck dieser Art von Multithreading ist, alle Datenabhängigkeits-Blockierungen aus der Ausführungs-Pipeline zu entfernen. Da ein Thread relativ unabhängig von anderen Threads ist, besteht eine geringere Wahrscheinlichkeit, dass eine Anweisung in einer Pipeline-Stufe eine Ausgabe aus einer älteren Anweisung in der Pipeline benötigt.
  • Konzeptionell ähnelt es dem in Betriebssystemen verwendeten präemptiven Multitasking. Man kann sich die Analogie vorstellen, dass die jedem aktiven Thread gegebene Zeitscheibe genau ein CPU-Zyklus ist.
  • Diese Art von Multithreading wurde zuerst ”Barrel”-Verarbeitung genannt, wobei die Dauben eines Fasses (barrel) die Pipeline-Stufen und ihre Ausführungs-Threads darstellen. Verzahntes oder präemptives oder differenziertes oder Zeitscheiben-Multithreading ist modernere Terminologie.
  • Hardware-Kosten
  • Zusätzlich zu den beim Block-Multithreading erörterten Hardware-Kosten verursacht verzahntes Multithreading zusätzliche Kosten, da jede Pipeline-Stufe die Thread-ID der Anweisung, die sie verarbeitet, verfolgt. Außerdem müssen, da in der Pipeline mehrere Threads nebeneinander ausgeführt werden, gemeinsam genutzte Ressourcen wie Cachespeicher und TLBs größer sein, um Thrashing zwischen den verschiedenen Threads zu vermeiden.
  • Simultanes Multithreading
  • Die fortschrittlichste Art von Multithreading findet Anwendung bei superskalaren Prozessoren. Ein normaler superskalarer Prozessor gibt in jedem CPU-Zyklus mehrere Anweisungen aus einem einzigen Thread aus. Beim simultanen Multithreading (SMT, Simultaneous Multi-Threading) kann der superskalare Prozessor in jedem CPU-Zyklus Anweisungen aus mehreren Threads ausgeben. Erkennend, dass jeder einzelne Thread ein begrenztes Maß an Parallelität auf Anweisungsebene aufweist, versucht diese Art von Multithreading, die über mehrere Threads hinweg verfügbare Parallelität auszunutzen, um die mit nicht verwendeten Ausgabezeitfenstern zusammenhängende Verschwendung zu verringern.
    Zum Beispiel:
    • 1. Zyklus i: Anweisungen j und j + 1 aus Thread A; Anweisung k aus Thread B alle gleichzeitig ausgegeben
    • 2. Zyklus i + 1: Anweisung j + 2 aus Thread A; Anweisung k + 1 aus Thread B; Anweisung m aus Thread C alle gleichzeitig ausgegeben
    • 3. Zyklus i + 2: Anweisung j + 3 aus Thread A; Anweisungen m + 1 und m + 2 aus Thread C alle gleichzeitig ausgegeben.
  • Um die anderen Multithreading-Arten von SMT zu unterscheiden, wird der Begriff ”Zeitbezogenes Multithreading” verwendet, um anzuzeigen, wann Anweisungen aus nur einem Thread auf einmal ausgegeben werden können.
  • Hardware-Kosten
  • Zusätzlich zu den beim verzahnten Multithreading erörterten Hardware-Kosten gibt es bei SMT die zusätzlichen Kosten des Verfolgens der Thread-ID jeder Anweisung, die verarbeitet wird, durch jede Pipeline-Stufe. Ferner müssen gemeinsam genutzte Ressourcen wie Cachespeicher und TLBs für die große Anzahl aktiver Threads in der Größe angepasst werden.
  • Gemäß US-Patentschrift Nr. 7 827 388 ”Apparatus for adjusting instruction thread priority in a multi-thread processor”, erteilt am 2.11.2010, IBM zugewiesen und durch Verweis hierin einbezogen, wird eine Anzahl von Techniken verwendet, um die Geschwindigkeit, mit welcher Datenprozessoren Software-Programme ausführen, zu verbessern. Zu diesen Techniken gehören das Erhöhen der Prozessor-Taktfrequenz, das Nutzen von Cachespeicher und das Nutzen vorhersagegestützter Verzweigung. Das Erhöhen der Prozessor-Taktfrequenz erlaubt einem Prozessor, in einer gegebenen Zeitspanne relativ mehr Operationen durchzuführen. Der Cachespeicher wird in nächster Nähe des Prozessors angeordnet und arbeitet mit höheren Geschwindigkeiten als der Hauptspeicher, wodurch sich die Zeit verkürzt, die ein Prozessor braucht, um auf Daten und Anweisungen zuzugreifen. Vorhersagegestützte Verzweigung gestattet einem Prozessor, bestimmte Anweisungen auf Grundlage einer Vorhersage über die Ergebnisse einer früheren Anweisung auszuführen und so die Notwendigkeit des Abwartens der tatsächlichen Ergebnisse entbehrlich zu machen und auf diese Weise die Verarbeitungsgeschwindigkeit zu erhöhen.
  • Manche Prozessoren verwenden auch Pipelining-Anweisungsausführung, um die Systemleistungsfähigkeit zu steigern. Bei Pipelining-Anweisungsausführung werden Verarbeitungs-Tasks in eine Anzahl von Pipeline-Schritten oder -stufen aufgegliedert. Pipelining kann die Verarbeitungsgeschwindigkeit erhöhen, indem es nachfolgenden Anweisungen gestattet, mit der Verarbeitung zu beginnen, bevor vorher ausgegebene Anweisungen einen bestimmten Prozess beendet haben. Der Prozessor braucht nicht zu warten, bis eine Anweisung gänzlich verarbeitet ist, bevor er beginnt, die nächste Anweisung in der Sequenz zu verarbeiten.
  • Prozessoren, die Pipelining-Verarbeitung anwenden, können eine Anzahl verschiedener Pipeline-Stufen enthalten, welche verschiedenen Aktivitäten im Prozessor gewidmet sind. Zum Beispiel kann ein Prozessor aufeinanderfolgende Anweisungen in einer Abrufstufe, Decodier-/Abfertigungsstufe, Ausgabestufe, Ausführungsstufe, Beendigungsstufe und Abschlussstufe verarbeiten. Jede dieser einzelnen Stufen kann ihren eigenen Satz von Pipeline-Stufen verwenden, um die gewünschten Verarbeitungs-Tasks zu erfüllen.
  • Multithread-Anweisungsverarbeitung ist eine zusätzliche Technik, die zusammen mit Pipelining verwendet werden kann, um die Verarbeitungsgeschwindigkeit zu erhöhen. Multithread-Anweisungsverarbeitung beinhaltet das Einteilen eines Satzes von Programmanweisungen in zwei oder mehrere eigene Gruppen oder Threads von Anweisungen. Diese Multithreading-Technik gestattet, Anweisungen aus einem Thread durch eine Pipeline zu verarbeiten, während ein anderer Thread aus irgendeinem Grund möglicherweise nicht verarbeitet werden kann. Dies vermeidet die bei Einzel-Thread-Anweisungsverarbeitung angetroffene Situation, in welcher alle Anweisungen aufgehalten werden, während eine bestimmte Anweisung nicht ausgeführt werden kann, wie zum Beispiel bei einem Cachespeicher-Fehlschlag, wobei zum Ausführen einer bestimmten Anweisung erforderliche Daten nicht unmittelbar verfügbar sind. Datenprozessoren, die zur Verarbeitung mehrerer Anweisungs-Threads fähig sind, werden oft als Simultan-Multithreading-(SMT-)Prozessoren bezeichnet.
  • An dieser Stelle ist zu beachten, dass es eine Unterscheidung zwischen der Weise, wie die Software-Gemeinschaft den Begriff ”Multithreading” verwendet, und der Weise, wie der Begriff ”Multithreading” in der Computerarchitektur-Gemeinschaft verwendet wird, gibt. Die Software-Gemeinschaft verwendet den Begriff ”Multithreading”, um eine in mehrere zusammenhängende Threads unterteilte Einzel-Task zu bezeichnen. In der Computerarchitektur bezieht sich der Begriff ”Multithreading” auf Threads, die unabhängig voneinander sein können. Der Begriff ”Multithreading” wird in diesem Dokument im selben, von der Computerarchitektur-Gemeinschaft verwendeten Sinn verwendet.
  • Zur Erleichterung von Multithreading werden die Anweisungen aus den verschiedenen Threads an irgendeiner Stelle in der gesamten Prozessor-Pipeline auf irgendeine Art verzahnt. Es gibt gewöhnlich zwei verschiedene Techniken zum Verzahnen von Anweisungen für die Verarbeitung in einem SMT-Prozessor. Eine Technik beinhaltet das Verzahnen der Threads auf Grundlage eines Ereignisses mit langer Latenzzeit wie eines Cachespeicher-Fehlschlags, das bzw. der eine Verzögerung beim Verarbeiten eines Threads verursacht. Bei dieser Technik werden alle Prozessor-Ressourcen einem einzigen Thread gewidmet, bis die Verarbeitung dieses Threads durch irgendein Ereignis mit langer Latenzzeit aufgehalten wird. Bei Auftreten des Ereignisses mit langer Latenzzeit schaltet der Prozessor schnell auf einen anderen Thread um und bringt er diesen Thread voran, bis irgendein Ereignis mit langer Latenzzeit für diesen Thread auftritt oder bis der Umstand, der den anderen Thread blockierte, sich auflöst.
  • Die andere verbreitete Technik zum Verzahnen von Anweisungen aus mehreren Anweisungs-Threads in einem SMT-Prozessor beinhaltet das zyklusweise Verzahnen von Anweisungen gemäß einer Verzahnungsregel (hierin auch manchmal als Verzahnregel bezeichnet). Eine einfache zyklusweise Verzahnungstechnik kann einfach Anweisungen aus den verschiedenen Threads eins zu eins verzahnen. Zum Beispiel kann ein Zwei-Thread-SMT-Prozessor eine Anweisung aus einem ersten Thread in einem ersten Taktzyklus, eine Anweisung aus einem zweiten Thread in einem zweiten Taktzyklus, eine weitere Anweisung aus dem ersten Thread in einem dritten Taktzyklus nehmen und so weiter, zwischen den zwei Anweisungs-Threads hin und her. Eine komplexere zyklusweise Verzahnungstechnik kann das Verwenden von Software-Anweisungen, um jedem Anweisungs-Thread eine Priorität zuzuweisen, und dann das Verzahnen von Anweisungen aus den verschiedenen Threads beinhalten, um irgendeine auf den relativen Thread-Prioritäten beruhende Regel durchzusetzen 8. Zum Beispiel wenn einem Thread in einem Zwei-Thread-SMT-Prozessor eine höhere Priorität als dem anderen Thread zugewiesen wird, kann eine einfache Verzahnungsregel erfordern, dass doppelt so viele Anweisungen aus dem Thread höherer Priorität in den verzahnten Strom aufgenommen werden wie Anweisungen aus dem Thread niedrigerer Priorität.
  • Eine allgemein übliche, komplexere Regel für zyklusweise Verzahnung weist jedem Thread eine Priorität von ”1” bis ”7” zu und stellt eine Anweisung aus dem Thread niedrigerer Priorität auf Grundlage der Funktion 1/(2|X – Y| + 1) in den verzahnten Strom von Anweisungen ein, wobei X = die durch Software zugewiesene Priorität eines ersten Threads und Y = die durch Software zugewiesene Priorität eines zweiten Threads. Im Fall, wo zwei Threads gleiche Priorität haben, zum Beispiel X = 3 und Y = 3, erzeugt die Funktion ein Verhältnis von 1/2, und eine Anweisung aus jedem der beiden Threads wird alle zwei Taktzyklen in den verzahnten Anweisungsstrom einbezogen. Wenn die Thread-Prioritäten sich um 2 unterscheiden, zum Beispiel X = 2 und Y = 4, erzeugt die Funktion ein Verhältnis von 1/8, und eine Anweisung aus dem Thread niedrigerer Priorität wird alle acht Taktzyklen in den verzahnten Anweisungsstrom einbezogen.
  • Das Verwenden einer Prioritätsregel beim Entscheiden, wie oft Anweisungen aus bestimmten Threads einzubeziehen sind, soll gewöhnlich sicherstellen, dass Prozessor-Ressourcen auf Grundlage der durch Software zugewiesenen Priorität jedes Threads zugeteilt werden. Es gibt jedoch Situationen, in welchen sich eine optimale Zuteilung von Prozessor-Ressourcen möglicherweise nicht erreichen lässt, wenn man auf allein durch Software zugewiesene Thread-Prioritäten baut. Insbesondere durch Software zugewiesene Thread-Prioritäten können Prozessorereignisse wie zum Beispiel einen Cachespeicher-Fehlschlag nicht berücksichtigen, welche die Fähigkeit eines bestimmten Threads von Anweisungen, durch eine Prozessor-Pipeline voranzukommen, beeinträchtigen können. Folglich kann das Auftreten eines Ereignisses im Prozessor das Ziel, Prozessor-Ressourcen effizient zwischen verschiedenen Anweisungs-Threads in einem Multithread-Prozessor zuzuweisen, vollständig oder mindestens teilweise vereiteln.
  • Zum Beispiel kann einem ersten Anweisungs-Thread in einem Zwei-Thread-System durch Software eine Priorität von 5 zugewiesen werden, während einem zweiten Anweisungs-Thread durch Software eine Priorität von 2 zugewiesen werden kann. Bei Verwendung der oben beschriebenen Prioritätsregel 1/(2|X – Y| + 1) würden diese durch Software zugewiesenen Prioritäten vorschreiben, dass eine Anweisung aus dem Thread niedrigerer Priorität nur einmal alle sechzehn Taktzyklen in den verzahnten Anweisungsstrom einbezogen würde, während Anweisungen aus dem Anweisungs-Thread höherer Priorität in fünfzehn von sechzehn Taktzyklen einbezogen würden. Wenn eine Anweisung aus dem Anweisungs-Thread höherer Priorität einen Cachespeicher-Fehlschlag erführe, würde die Prioritätsregel nach wie vor vorschreiben, dass von sechzehn Anweisungen fünfzehn Anweisungen aus dem Anweisungs-Thread höherer Priorität sind, obwohl das Auftreten des Cachespeicher-Fehlschlags die Ausführung des jeweiligen Anweisungs-Threads wirksam blockieren könnte, bis die Daten für die Anweisung verfügbar werden.
  • In einer Ausführungsform wird jeder Anweisungs-Thread in einem SMT-Prozessor mit einer durch Software zugewiesenen Grundeingabeverarbeitungspriorität (base input processing priority) verknüpft. Außer wenn ein vordefiniertes Ereignis oder ein vordefinierter Umstand bei einer in Verarbeitung befindlichen oder zu verarbeitenden Anweisung eintritt, werden die Grundeingabeverarbeitungsprioritäten der jeweiligen Threads verwendet, um die Verzahnungsfrequenz zwischen den Threads gemäß einer Anweisungsverzahnungsregel zu bestimmen. Jedoch wird bei Auftreten irgendeines vordefinierten Ereignisses oder Umstands im zu einem bestimmten Anweisungs-Thread gehörigen Prozessor die Grundeingabeverarbeitungspriorität eines oder mehrerer Anweisungs-Threads angepasst, um besser angepasste Prioritätswerte zu erzeugen. Die Anweisungsverzahnungsregel wird dann entsprechend dem angepassten Prioritätswert oder den angepassten Prioritätswerten in Verbindung mit etwaigen Grundeingabeverarbeitungsprioritätswerten, die keiner Anpassung unterzogen wurden, umgesetzt.
  • Intel® Hyper-Threading ist in ”Intel® Hyper-Threading Technology, Technical User's Guide” 2003 der Intel® Corporation beschrieben, der durch Verweis hierin einbezogen wird. Gemäß dem ”Technical User's Guide” konzentrierten sich die Bemühungen, die Systemleistungsfähigkeit auf Einzelprozessorsystemen zu steigern, üblicherweise darauf, den Prozessor leistungsfähiger zu machen. Diese Ansätze beim Prozessoraufbau konzentrierten sich darauf, dem Prozessor zu ermöglichen, durch höhere Taktfrequenzen, Parallelität auf Anweisungsebene (ILP – instruction-level parallelism) und Cachespeicher mehr Anweisungen schneller zu verarbeiten. Techniken zum Erreichen höherer Taktfrequenzen beinhalten das Pipelining der Mikroarchitektur zu feineren Granularitäten, was auch als Super-Pipelining bezeichnet wird. Höhere Taktfrequenzen können die Leistung außerordentlich verbessern, indem sie die Anzahl von Anweisungen, die in jeder Sekunde ausgeführt werden können, erhöhen. Aber da in einer Super-Pipelining-Mikroarchitektur viel mehr Anweisungen ausgeführt werden, ist das Handhaben von Ereignissen, welche die Pipeline unterbrechen, wie Cachespeicher-Fehlschlägen, Interrupts und falschen Verzweigungsvorhersagen, viel kritischer und sind Fehler kostspieliger. ILP bezieht sich auf Techniken zum Erhöhen der Anzahl von pro Taktzyklus ausgeführten Anweisungen. Zum Beispiel weisen viele superskalare Prozessor-Implementierungen mehrere Ausführungseinheiten auf, die Anweisungen gleichzeitig verarbeiten können. In diesen superskalaren Implementierungen können mehrere Anweisungen pro Taktzyklus ausgeführt werden. Bei einfacher reihenfolgegemäßer Ausführung genügt es jedoch nicht, einfach mehrere Ausführungseinheiten zu haben. Das Problem besteht darin, genügend auszuführende Anweisungen zu finden. Eine Technik ist ”Out-of-Order”-Ausführung (Ausführung unter Missachtung der Reihenfolge), wobei auf Grundlage von Anweisungsabhängigkeiten statt auf Grundlage der Programmreihenfolge ein großes Fenster von Anweisungen gleichzeitig ausgewertet und an die Ausführungseinheiten gesendet wird. Zugriffe auf den Systemspeicher sind langsam, aber doch schneller als Zugriffe auf die Festplatte, aber im Vergleich zu den Ausführungsgeschwindigkeiten des Prozessors sind sie um Größenordnungen langsamer. Eine Technik zum Verringern der durch Zugriffe auf den Systemspeicher eingeführten Verzögerungen (als Latenzzeit bezeichnet) besteht darin, nah am Prozessor schnelle Cachespeicher hinzuzufügen. Cachespeicher bieten schnellen Speicherzugriff auf häufig benötigte Daten oder Anweisungen. Mit zunehmenden Cachespeicher-Geschwindigkeiten wächst jedoch auch das Problem der Wärmeabstrahlung und der Kosten. Aus diesem Grund werden Prozessoren häufig mit einer Cachespeicher-Hierarchie entworfen, in welcher schnelle, kleine Cachespeicher nahebei angeordnet sind und mit Zugriffs-Latenzzeiten nahe derjenigen des Prozessorkerns betrieben werden. Stufenweise größere Cachespeicher, die weniger häufig benötigte Daten oder Anweisungen handhaben, werden mit längeren Zugriffs-Latenzzeiten implementiert. Nichtsdestotrotz ist es zu bestimmten Zeitpunkten möglich, dass die benötigten Daten in keinem Prozessor-Cachespeicher vorliegen. Die Handhabung solcher Cachespeicher-Fehlschläge erfordert Zugriffe auf Systemspeicher oder Festplatte, und während dieser Zeiten ist der Prozessor wahrscheinlich blockiert, während er darauf wartet, dass die Speichertransaktionen beendet werden. Die meisten Techniken zur Steigerung der Prozessorleistung von einer Generation zur nächsten sind komplex und verursachen häufig eine merkliche Zunahme der Chipgröße und der Stromkosten. Wegen begrenzter Parallelität in Anweisungsflüssen arbeitet keine dieser Techniken mit 100 Prozent Wirkungsgrad. Daher lässt sich durch Verdopplung der Anzahl von Ausführungseinheiten in einem Prozessor nicht eine Verdopplung der Prozessorleistung erreichen. Entsprechend lässt sich durch einfaches Verdoppeln der Taktfrequenz nicht die Leistung verdoppeln, weil eine bestimmte Anzahl von Prozessorzyklen an ein langsameres Speicher-Teilsystem verlorengeht.
  • Multithreading
  • Mit der Zunahme der Prozessorfähigkeiten nahmen auch die Anforderungen an die Leistung zu, was den Druck auf Prozessor-Ressourcen mit maximaler Leistungsfähigkeit erhöht hat. In Anbetracht der Zeit, die Prozessoren damit verschwendeten, Einzel-Tasks auszuführen, während sie auf die Fertigstellung bestimmter Ereignisse warteten, begannen Software-Entwickler, sich zu fragen, ob der Prozessor gleichzeitig irgendeine andere Arbeit tun könnte.
  • Um zu einer Lösung zu gelangen, begannen Software-Architekten, Betriebssysteme zu schreiben, die als Threads bezeichnete laufende Stücke von Programmen unterstützten. Threads sind kleine Tasks, die unabhängig voneinander laufen können. Jeder Thread erhält seine eigene Zeitscheibe, und so stellt jeder Thread eine Grundeinheit der Prozessorauslastung dar. Threads werden in Prozesse organisiert, welche aus einem oder mehreren Threads bestehen. Alle Threads in einem Prozess teilen sich den Zugriff auf die Prozessressourcen.
  • Diese Multithreading-Betriebssysteme ermöglichten einem Thread seine Ausführung, während ein anderer Thread darauf wartet, dass etwas geschieht. Auf Personal-Computern und Servern auf Basis von Intel-Prozessoren unterstützen die heutigen Betriebssysteme wie Microsoft Windows* 2000 und Windows* XP allesamt Multithreading. Tatsächlich sind die Betriebssysteme selbst als Multithread-Prozesse ausgeführt. Teile davon können laufen, während andere Teile blockiert sind.
  • Um von Multithreading zu profitieren, müssen Programme ausführbare Abschnitte aufweisen, die parallel laufen können. Das heißt, anstelle der Entwicklung einer einzigen langen Folge von Anweisungen werden Programme in logische Arbeitsabschnitte gegliedert. Auf diese Weise können, wenn die Anwendung Operationen durchführt, die unabhängig voneinander laufen, diese Operationen in Threads aufgegliedert werden, deren Ausführung vom Betriebssystem geplant und gesteuert wird. Diese Abschnitte können dafür erstellt werden, verschiedene Dinge zu tun, wie Microsoft Word* zu gestatten, den Seitenumbruch eines Dokuments durchzuführen, während der Benutzer weitertippt. Der Seitenumbruch erfolgt in einem Thread und die Verarbeitung der Tastenanschläge erfolgt in einem anderen Thread. In Einzelprozessorsystemen werden diese Threads nacheinander, nicht nebeneinander ausgeführt. Der Prozessor schaltet schnell genug zwischen dem Tastenanschlag-Thread und dem Seitenumbruch-Thread hin und her, dass beide Prozesse gleichzeitig aufzutreten scheinen. Dies wird als funktional aufgelöstes Multithreading bezeichnet.
  • Multithread-Programme können auch so geschrieben werden, dass sie ein und dieselbe Task in parallelen Threads ausführen. Dies wird als datenmäßig aufgelöstes Multithreading bezeichnet, wobei die Threads sich nur in den Daten, die verarbeitet werden, unterscheiden. Zum Beispiel könnte ein Bild in einer Grafikanwendung so gezeichnet werden, dass jeder Thread auf einer Hälfte des Bilds arbeitet. Üblicherweise werden datenmäßig aufgelöste Anwendungen zwecks besserer Durchsatzleistung in Threads ausgeführt, während funktional aufgelöste Anwendungen aus Gründen der Reaktionsschnelligkeit auf Benutzereingaben oder der Funktionalität in Threads ausgeführt werden.
  • Wenn Multithread-Programme auf einer Einzelprozessormaschine ausgeführt werden, entsteht beim Wechseln des Kontexts zwischen den Threads ein gewisser Aufwand. Da das Umschalten zwischen Threads Zeit kostet, scheint es, dass das Ausführen von zwei Threads auf diese Weise weniger effizient ist als das Ausführen von zwei Threads nacheinander. Wenn einer der beiden Threads in einer Systemeinheit auf den Benutzer warten muss, entschädigt jedoch die Fähigkeit, den anderen Thread weiterarbeiten zu lassen, sehr schnell für den gesamten Aufwand des Umschaltens. Da im Beispiel der Grafikanwendung ein Thread die Benutzereingaben verarbeitet, kommt es sicher häufig zu Zeiträumen, während derer dieser nur wartet. Durch Umschalten zwischen Threads können Betriebssysteme, die Multithread-Programme unterstützen, die Leistungsfähigkeit und die Reaktionsschnelligkeit auf Benutzereingaben verbessern, selbst wenn sie auf einem Einzelprozessorsystem laufen.
  • Im echten Einsatz führen große Programme, die Multithreading verwenden, häufig viel mehr als zwei Threads aus. Software wie Datenbank-Steuerkomponenten erstellt für jede Anforderung eines Datensatzes, die empfangen wird, einen neuen Verarbeitungs-Thread. Auf diese Weise hindert keine einzelne E/A-Operation neue Anforderungen an der Ausführung und können Engpässe vermieden werden. Auf manchen Servern kann dieser Ansatz bedeuten, dass Tausende von Threads nebeneinander auf ein und derselben Maschine laufen.
  • Multiprocessing
  • Multiprocessing-Systeme haben mehrere gleichzeitig laufende Prozessoren. Multiprozessorsysteme der herkömmlichen Intel®-Architektur verfügen über zwei bis etwa 512 Prozessoren. Bei Multiprocessing-Systemen können verschiedene Threads auf verschiedenen Prozessoren laufen. Diese Fähigkeit beschleunigt die Programmleistungsfähigkeit beträchtlich. Jetzt können zwei Threads mehr oder weniger unabhängig voneinander laufen, ohne dass Thread-Umschaltungen die Ressourcen des Prozessors in Anspruch nehmen müssen. Mehrprozessor-Betriebssysteme sind selbst als Multithread-Prozesse ausgeführt, und die Threads können die einzelnen Prozessoren vorteilhaft nutzen.
  • Ursprünglich gab es zwei Arten von Mehrprozessorbetrieb (Multiprocessing): asymmetrischen und symmetrischen. Bei einem asymmetrischen System waren ein oder mehrere Prozessoren ausschließlich für bestimmte Tasks wie das Ausführen des Betriebssystems vorgesehen. Die übrigen Prozessoren waren für alle anderen Tasks (gewöhnlich die Benutzeranwendungen) verfügbar. Schnell zeigte sich, dass diese Konfiguration nicht optimal war. Auf manchen Maschinen liefen die Betriebssystem-Prozessoren mit 100 Prozent der Kapazität, während die dem Benutzer zugewiesenen Prozessoren nichts taten. Alsbald begannen Systementwickler, eine Architektur zu bevorzugen, welche die Verarbeitungslast besser ausglich: symmetrisches Multiprocessing (SMP). Die ”Symmetrie” bezieht sich auf die Tatsache, dass jeder Thread – sei es aus dem Betriebssystem oder aus der Benutzeranwendung – auf jedem Prozessor laufen kann. Auf diese Weise wird die gesamte Rechenlast gleichmäßig über alle Rechenressourcen verteilt. Heute sind symmetrische Multiprocessing-Systeme die Regel und asymmetrische Ausführungen fast verschwunden.
  • SMP-Systeme verwenden die doppelte Anzahl von Prozessoren, ohne dass sich jedoch die Leistung verdoppelt. Zwei Faktoren, welche eine einfache Verdoppelung der Leistung verhindern, sind, (i) wie gut die Arbeitslast parallelisiert werden kann; und (ii) der Systemaufwand. Zwei Faktoren, welche die Effizienz von Interaktionen zwischen Threads bestimmen, sind, (i) wie sie um dieselben Ressourcen konkurrieren; und (ii) wie sie mit anderen Threads Daten austauschen.
  • Multiprozessorsysteme
  • Heutige Server-Anwendungen bestehen aus mehreren Threads oder Prozessen, die parallel ausgeführt werden können. Online-Transaktions-Verarbeitung und Web-Services haben eine Fülle von Software-Threads, die zur Beschleunigung der Leistung gleichzeitig ausgeführt werden können. Sogar Desktop-Anwendungen werden zunehmend parallel. Intel-Architekten haben Parallelität auf Thread-Ebene (TIP – thread-level parallelism) implementiert, um die Leistungsfähigkeit bezüglich Transistoranzahl und Energieverbrauch zu verbessern.
  • Sowohl im Markt für High-End-Server als auch im Markt für Mid-Range-Server wurden Multiprozessoren gewöhnlich verwendet, um mehr Leistung vom System zu erhalten. Durch Hinzufügen von mehr Prozessoren erhalten Anwendungen eine potentiell wesentliche Leistungssteigerung durch gleichzeitiges Ausführen mehrerer Threads auf mehreren Prozessoren. Diese Threads könnten zu ein und derselben Anwendung, zu verschiedenen gleichzeitig laufenden Anwendungen, zu Betriebssystem-Services oder zu Betriebssystem-Threads, die Hintergrundwartung durchführen, gehören. Multiprozessorsysteme sind seit vielen Jahren im Einsatz, und Programmierer sind mit den Techniken zur Nutzung von Multiprozessoren für höhere Leistungsniveaus vertraut.
  • US-Patentanmeldung Nr. 2011/0087865 ”Intermediate Register Mapper”, veröffentlicht am 14.4.2011 durch Barrick et al. und durch Verweis hierin einbezogen, beschreibt ”ein Verfahren, einen Prozessor und ein Computerprogramm-Produkt, welche eine temporäre Registerzuordnungsfunktion in einem Registerumbenennungs-Mechanismus verwenden. Eine Suche in den logischen Registern ermittelt, ob bei einem mit der abgefertigten Anweisung verknüpften logischen Register ein Treffer aufgetreten ist. In dieser Hinsicht durchläuft die Suche in den logischen Registern mindestens eine Registerzuordnungsfunktion aus einer Gruppe von Registerzuordnungsfunktionen, die eine Zuordnungsfunktion für architekturdefinierte Register, eine vereinheitlichte Hauptzuordnungsfunktion und eine temporäre Registerzuordnungsfunktion beinhaltet. Ein einzelner Treffer beim logischen Register wird aus der Gruppe von Registerzuordnungsfunktionen ausgewählt. Wenn eine Anweisung mit einem Zuordnungsfunktions-Eintrag in der vereinheitlichten Hauptzuordnungsfunktion beendet, aber nicht abgeschlossen ist, wird der Zuordnungsinhalt des Registerzuordnungsfunktions-Eintrags in der vereinheitlichten Hauptzuordnungsfunktion zur temporären Registerzuordnungsfunktion verschoben und wird der Eintrag der vereinheitlichten Registerzuordnungsfunktion freigegeben, was eine Anzahl von für die Wiederverwendung verfügbaren Einträgen der vereinheitlichten Hauptzuordnungsfunktion erhöht.”
  • Die am 2. April 1998 eingereichte US-Patentschrift Nr. 6 314 511 ”Mechanism for freeing registers an processors that perform dynamic out-of-order execution of instructions using renaming registers” von Levy et al., durch Verweis hierin einbezogen, beschreibt das ”Freigeben von Umbenennungsregistern, die architekturdefinierten Registern zugeordnet wurden, bevor eine andere Anweisung das architekturdefinierte Register neu definierte. Umbenennungsregister werden von einem Prozessor verwendet, um Anweisungen entweder in einem Einzel- oder in einem Multithread-Prozessor, der Anweisungen ”out-of-order” (unter Missachtung der Reihenfolge) ausführt, dynamisch ”out-of-order” auszuführen. Ein Mechanismus zum Freigeben von Umbenennungsregistern wird beschrieben, der aus einem Satz von Anweisungen besteht, die von einem Compiler verwendet werden, um dem Prozessor anzuzeigen, wann er das physische (Umbenennungs-)Register, das einem bestimmten architekturdefinierten Register zugeordnet ist, freigeben kann. Durch diesen Mechanismus kann das Umbenennungsregister neu zugewiesen oder neu zugeordnet werden, um einen anderen Wert zu speichern, sobald das Umbenennungsregister nicht mehr für das Zuordnen zum architekturdefinierten Register benötigt wird. Es gibt mindestens drei Arten und Weisen, den Prozessor mit einer Anweisung, die das vom Zuordnen zu befreiende Umbenennungsregister identifiziert, zu aktivieren: (1) ein Benutzer kann die Anweisung, die sich auf ein bestimmtes Umbenennungsregister bezieht, explizit an den Prozessor bereitstellen; (2) ein Betriebssystem kann die Anweisung bereitstellen, wenn ein Thread inaktiv ist, der sich auf einen mit dem Thread verknüpften Satz von Registern bezieht; und (3) ein Compiler kann die Anweisung in die Vielzahl von an den Prozessor gerichteten Anweisungen einschließen. Es gibt mindestens fünf Ausführungsformen der an den Prozessor bereitgestellten Anweisung, um architekturdefinierten Registern zugeordnete Umbenennungsregister freizugeben: (1) Register-Bit freigeben; (2) Register freigeben; (3) Maske freigeben; (4) Opcode freigeben; und (5) Opcode/Maske freigeben. Die Anweisung ”Register-Bit freigeben” bewirkt die größte Beschleunigung für einen ”Out-of-Order”-Prozessor, und die Anweisung ”Register freigeben” bewirkt die geringste Beschleunigung.” ”Power ISATM Version 2.06 Revision B”, veröffentlicht am 23. Juli 2010, von IBM® und durch Verweis hierin einbezogen, erläutert eine beispielhafte RISC-(reduced instruction set computer)Anweisungssatz-Architektur. Power ISA wird hierin verwendet, um beispielhafte Ausführungsformen darzulegen, jedoch ist die Erfindung nicht auf Power ISA oder RISC-Architekturen beschränkt. Der Fachmann wird den Nutzen der Erfindung in einer Vielzahl von Architekturen ohne weiteres erkennen.
  • ”z/Architecture Principles of Operation” SA22-7832-08, Neunte Ausgabe (August 2010) von IBM® und durch Verweis hierin einbezogen, erläutert eine beispielhafte CISC-(complex instruction set computer)Anweisungssatz-Architektur.
  • KURZBESCHREIBUNG
  • Eine Mehrebenen-Registerhierarchie wird verwendet, die einen Registerpool der ersten Ebene und mindestens einen Registerpool einer höheren Ebene enthält. Der Registerpool der ersten Ebene ist ein Hochgeschwindigkeits-Cachespeicher von Registern, die Ausführungselementen des Prozessors einen schnellen Zugriff erlauben, während der Registerpool einer höheren Ebene alle zugewiesenen Register, vorzugsweise einen vollständigen Satz von architekturdefinierten Registern einer Anweisungssatz-Architektur (ISA – instruction set architecture) für jeden auf dem Prozessor laufenden Thread und alle Umbenennungsregister des Prozessors aufrechterhält, wodurch architekturdefinierte Register und/oder Umbenennungsregister der Mehrebenen-Registerhierarchie dynamisch zugewiesen werden können.
  • Letztverwendungs-Anweisungen werden ausgeführt, wobei einer Letztverwendungs-Anweisung ermöglicht wird, ein architekturdefiniertes Register letztmals zu verwenden. Nach dem Ausführen der Letztverwendungs-Anweisung ist das als ein letztmals verwendetes architekturdefiniertes Register identifizierte architekturdefinierte Register kein gültiger Eintrag in der Mehrebenen-Registerhierarchie mehr.
  • Vorteilhafterweise wird dem Registerpool der ersten Ebene insbesondere in einer Multithread”Out-of-order”-Ausführungsumgebung ermöglicht, durch Verringern der Anzahl aktiver architekturdefinierter Register nützlichere architekturdefinierte Register aufzunehmen.
  • In einer Ausführungsform wird eine Mehrebenen-Registerhierarchie verwaltet, die einen Registerpool der ersten Ebene zum Cachespeicher-Zwischenspeichern (caching) von Registern eines Registerpools der zweiten Ebene aufweist. Ein Prozessor weist verfügbaren Einträgen aus dem Pool der ersten Ebene oder aus dem Pool der zweiten Ebene architekturdefinierte Register zu, wobei architekturdefinierte Register durch eine ISA definiert und durch Registerfeld-Werte von Anweisungen der ISA adressierbar sind, wobei das Zuweisen das Verknüpfen jedes zugewiesenen architekturdefinierten Registers mit einem entsprechenden Eintrag eines Registerpools beinhaltet. Werte architekturdefinierter Register werden gemäß einem Ersetzungsalgorithmus bezüglich des Pools der ersten Ebene aus dem Pool der zweiten Ebene in den Pool der ersten Ebene verschoben. Auf Grundlage von in Ausführung befindlichen Anweisungen wird auf Werte architekturdefinierter Register aus dem Registerpool der ersten Ebene, welcher den architekturdefinierten Registern entspricht, zugegriffen. In Reaktion auf die Ausführung einer Letztverwendungs-Anweisung zur Verwendung eines als ein letztmals verwendetes architekturdefiniertes Register identifizierten architekturdefinierten Registers wird die Zuweisung des letztmals verwendeten architekturdefinierten Registers sowohl zum Pool der ersten Ebene als auch zum Pool der zweiten Ebene aufgehoben, wobei Einträge, deren Zuweisung aufgehoben wurde, für die Zuweisung zu architekturdefinierten Registern verfügbar sind.
  • Auf Grundlage der Feststellung, dass die Letztverwendungs-Anweisung auszuführen ist, wobei die Letztverwendungs-Anweisung einen Registerfeld-Wert enthält, welcher das letztmals verwendete architekturdefinierte Register, dessen Zuweisung nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll, identifiziert, wird in einer Ausführungsform der Wert des letztmals verwendeten architekturdefinierten Registers in ein physisches Register der zweiten Ebene aus dem Registerpool der zweiten Ebene kopiert. Dann wird die Letztverwendungs-Anweisung ausgeführt. Das Aufheben der Zuweisung des physischen Registers erfolgt nach Letztverwendung des Werts des architekturdefinierten Registers gemäß der Letztverwendungs-Anweisung. Dann wird die Zuweisung eines physischen Registers aus dem Registerpool der zweiten Ebene wie des architekturdefinierten Registers auf Grundlage der in Ausführung befindlichen Letztverwendungs-Anweisung, die abgeschlossen werden soll, aufgehoben. In Reaktion auf das Decodieren der Letztverwendungs-Anweisung zur Ausführung wird in einer Ausführungsform bestimmt, dass die Zuweisung des letztmals verwendeten architekturdefinierten Registers nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll.
  • In einer Ausführungsform wird das Aufheben der Zuweisung des physischen Registers durch eine Anweisungsabschlusslogik des Prozessors bestimmt.
  • In einer Ausführungsform enthält die Mehrebenen-Registerhierarchie architekturdefinierte Register, auf welche vor kurzem zugegriffen wurde, im Pool der ersten Ebene und architekturdefinierte Register, auf welche selten zugegriffen wird, im Pool der zweiten Ebene.
  • In einer Ausführungsform beinhalten die architekturdefinierten Register Allgemeinregister oder Gleitkommaregister, wobei architekturdefinierte Anweisungen Opcode-Felder und Registerfelder aufweisen, wobei die Registerfelder so konfiguriert sind, dass sie ein Register aus den architekturdefinierten Registern identifizieren.
  • In einer Ausführungsform wird eine Letztverwendungs-Identifizierungsanweisung ausgeführt, wobei die Ausführung das Identifizieren eines architekturdefinierten Registers der Letztverwendungs-Anweisung als das letztmals verwendete architekturdefinierte Register beinhaltet.
  • Ebenso werden hierin System und Computerprogramm-Produkte entsprechend den oben zusammengefassten Verfahren beschrieben und beansprucht.
  • Zusätzliche Funktionsmerkmale und Vorteile werden durch die Verfahren der vorliegenden Erfindung realisiert. Weitere Ausführungsformen und Aspekte der Erfindung sind hierin ausführlich beschrieben und werden als Bestandteil der beanspruchten Erfindung betrachtet.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Der Gegenstand, welcher als die Erfindung angesehen wird, wird in den Ansprüchen am Ende der Beschreibung genau dargelegt und klar beansprucht. Die vorerwähnten und weitere Aufgaben, Merkmale und Vorteile der Erfindung sind aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden beigefügten Zeichnungen ersichtlich:
  • 1 veranschaulicht eine beispielhafte Prozessor-Systemkonfiguration;
  • 2 veranschaulicht eine erste beispielhafte Prozessor-Pipeline;
  • 3 veranschaulicht eine zweite beispielhafte Prozessor-Pipeline;
  • 4 veranschaulicht eine beispielhafte Ausführungsform; und
  • Die 5 bis 8 veranschaulichen beispielhafte Ablaufpläne.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Ein ”Out-of-Order”-(OoO-)Prozessor enthält üblicherweise mehrere Ausführungs-Pipelines, die in opportunistischer Weise Anweisungen in einer anderen Reihenfolge als der von der Programmsequenz (oder ”Programmreihenfolge”) angegebenen ausführen können, um durch Verringern von Datenabhängigkeiten und Maximieren der Auslastung der für verschiedene Anweisungsarten zugeordneten Ausführungs-Pipelines die mittlere Anzahl von Anweisungen pro Zyklus zu maximieren. Die Ergebnisse der Anweisungsausführung werden üblicherweise vorübergehend in den physischen Registern einer oder mehrerer Registerdateien begrenzter Tiefe untergebracht. Ein OoO-Prozessor verwendet üblicherweise Registerumbenennung, um eine unnötige Durchnummerierung von Anweisungen wegen der Wiederverwendung eines gegebenen architekturdefinierten Registers durch nachfolgende Anweisungen in der Programmreihenfolge zu vermeiden.
  • Bei Barrick wird während Registerumbenennungsoperationen jedes durch eine Anweisung angesprochene architekturdefinierte (d. h. logische) Register einem eindeutigen physischen Register in einer Registerdatei zugeordnet. In aktuellen Hochleistungs-OoO-Prozessoren wird eine vereinheitlichte Hauptzuordnungsfunktion genutzt, um die physischen Register in mehreren Registerdateien zu verwalten. Neben dem Speichern der logisch-zu-physischen Registerumsetzung (d. h. in Zuordnungsfunktions-Einträgen) ist die vereinheitlichte Hauptzuordnungsfunktion auch für das Speichern von Abhängigkeitsdaten (d. h. Warteschlangen-Positionsdaten) zuständig, was für das Ordnen der Anweisungen bei Abschluss wichtig ist.
  • In einem auf vereinheitlichten Hauptzuordnungsfunktionen beruhenden Umbenennungsschema ist es erwünscht, Zuordnungsfunktions-Einträge so bald wie möglich für die Wiederverwendung durch den OoO-Prozessor freizugeben. Jedoch kann nach Stand der Technik ein Eintrag der vereinheitlichten Hauptzuordnungsfunktion nicht freigegeben werden, bis die Anweisung, die in ein durch den Zuordnungsfunktions-Eintrag zugeordnetes Register schreibt, abgeschlossen ist. Diese Einschränkung wird durchgesetzt, weil bis zum Abschluss eine Möglichkeit besteht, dass eine Anweisung, die ”beendet” ist (d. h. die bestimmte Ausführungseinheit (EU – execution unit) hat die Anweisung erfolgreich ausgeführt), noch gelöscht wird, bevor die Anweisung ”abgeschlossen” werden kann und bevor der architekturdefinierte, kohärente Zustand der Register aktualisiert wird. In aktuellen Implementierungen wurde Ressourcenengpässen bei der vereinheitlichten Hauptzuordnungsfunktion gewöhnlich durch Erhöhen der Anzahl der Einträge der vereinheitlichten Hauptzuordnungsfunktion begegnet. Jedoch ist das Erhöhen der Größe der vereinheitlichten Hauptzuordnungsfunktion hinsichtlich Chipfläche, Komplexität, Energieverbrauch und Zugriffszeit mit einem Nachteil verbunden.
  • Bei Barrick wird ein Verfahren zum Verwalten eines Satzes von einem oder mehreren physischen Registern in einem Datenverarbeitungssystem bereitgestellt. Das Datenverarbeitungssystem hat einen Prozessor, der Anweisungen unter Missachtung der Reihenfolge verarbeitet, wobei die Anweisungen auf logische Register verweisen und wobei jedes der logischen Register dem Satz aus einem oder mehreren physischen Registern zugeordnet wird. In Reaktion auf die Abfertigung einer oder mehrerer der Anweisungen führt eine Registerverwaltungseinheit eine Suche in den logischen Registern durch, welche ermittelt, ob bei einem mit der abgefertigten Anweisung verknüpften logischen Register in einer oder mehreren Registerzuordnungsfunktionen ein Treffer aufgetreten ist. In dieser Hinsicht durchläuft die Suche in den logischen Registern mindestens eine Registerzuordnungsfunktion aus einer Gruppe von Registerzuordnungsfunktionen, die eine Zuordnungsfunktion für architekturdefinierte Register, eine vereinheitlichte Hauptzuordnungsfunktion und eine temporäre Registerzuordnungsfunktion beinhaltet. Die Registerverwaltungseinheit wählt einen einzelnen Treffer beim logischen Register aus der Gruppe von Registerzuordnungsfunktionen aus. Wenn eine Anweisung mit einem Zuordnungsfunktions-Eintrag in der vereinheitlichten Hauptzuordnungsfunktion beendet, aber nicht abgeschlossen ist, verschiebt die Registerverwaltungseinheit logisch-zu-physische Registerumbenennungsdaten des Eintrags der vereinheitlichten Hauptzuordnung in der vereinheitlichten Hauptzuordnungsfunktion zur temporären Registerzuordnungsfunktion und gibt die vereinheitlichte Hauptzuordnungsfunktion den Eintrag der vereinheitlichten Hauptzuordnung vor Abschluss der Anweisung frei. Die Freigabe des Eintrags der vereinheitlichten Hauptzuordnung erhöht eine Anzahl von für die Wiederverwendung verfügbaren Einträgen der vereinheitlichten Hauptzuordnung.
  • Die Figuren und insbesondere 1 zeigen ein Beispiel eines Datenverarbeitungssystems 100, welches einen OoO-Prozessor enthalten kann, der eine temporäre Registerzuordnungsfunktion wie unten anhand 2 beschrieben verwendet. Wie in 1 gezeigt, verfügt das Datenverarbeitungssystem 100 über eine Zentraleinheit (CPU) 110, welche mit Prozessor 200 in 2 implementiert sein kann. Die CPU 110 ist durch eine Verschaltung 112 mit verschiedenen weiteren Komponenten verbunden. Ein Nur-Lese-Speicher (ROM – read-only memory) 116 ist mit der Verschaltung 112 verbunden und enthält ein ”Basic Input/Output System” (BIOS), das bestimmte grundlegende Funktionen des Datenverarbeitungssystems 100 steuert. Ein Direktzugriffsspeicher (RAM – random access memory) 114, ein EIA-Adapter 118 und ein DFV-Adapter 134 sind ebenfalls mit dem Systembus 112 verbunden. Der EIA-Adapter 118 kann ein Small-Computer-System-Interface-(”SCSI”-)Adapter sein, der mit einer Speichereinheit 120 Daten austauscht. Der DFV-Adapter 134 verbindet die Verschaltung 112 mit dem Netz 140, was dem Datenverarbeitungssystem 100 ermöglicht, mit anderen solchen Systemen wie einem fernen Computer 142 Daten auszutauschen. Ein/Ausgabe-Einheiten sind außerdem über einen Benutzerschnittstellenadapter 122 und einen Bildschirmadapter 136 mit der Verschaltung 112 verbunden. Eine Tastatur 124, ein Trackball 132, eine Maus 126 und ein Lautsprecher 128 sind alle über den Benutzerschnittstellenadapter 122 mit dem Bus 112 verbunden. Ein Bildschirm 138 ist über einen Bildschirmadapter 136 mit dem Systembus 112 verbunden. Auf diese Weise empfängt das Datenverarbeitungssystem 100 Eingaben zum Beispiel über die Tastatur 124, den Trackball 132 und/oder die Maus 126 und liefert es Ausgaben zum Beispiel über das Netz 140 auf die Speichereinheit 120, den Lautsprecher 128 und/oder den Bildschirm 138. Die im Datenverarbeitungssystem 100 veranschaulichten Hardware-Elemente sollen nicht erschöpfend sein, sondern vielmehr Hauptkomponenten eines Datenverarbeitungssystems in einer einzigen Ausführungsform darstellen.
  • Der Betrieb des Datenverarbeitungssystems 100 kann durch Programmcode wie Firmware und/oder Software gesteuert werden, welcher üblicherweise zum Beispiel ein Betriebssystem wie AIX® (”AIX” ist ein Warenzeichen der IBM Corporation) und ein oder mehrere Anwendungs- oder Middleware-Programme enthält.
  • In 2 ist ein superskalarer Prozessor 200 dargestellt. Anweisungen werden aus einem Speicher (z. B. RAM 114 in 1) abgerufen und in eine Anweisungssequenzbildungslogik (ISL – instruction sequencing logic) 204 geladen, welche einen Level-1-Anweisungs-Cachespeicher (L1-I-Cachespeicher) 206, eine Abruf-Decodier-Einheit 208, eine Anweisungswarteschlange 210 und eine Abfertigungseinheit 212 enthält. Speziell werden die Anweisungen in einen L1-I-Cachespeicher 206 von ISL 204 geladen. Die Anweisungen werden im L1-I-Cachespeicher 206 aufbewahrt, bis sie benötigt werden, oder ersetzt, wenn sie nicht benötigt werden. Die Anweisungen werden aus dem L1-I-Cachespeicher 206 abgerufen und durch die Abruf-Decodier-Einheit 208 decodiert. Nach Decodieren einer aktuellen Anweisung wird die aktuelle Anweisung in die Anweisungswarteschlange 210 geladen. Die Abfertigungseinheit 212 fertigt Anweisungen aus der Anweisungswarteschlange 210 an eine Registerverwaltungseinheit 214 sowie eine Abschlusseinheit 240 ab. Die Abschlusseinheit 240 ist mit einer allgemeinen Ausführungseinheit 224 und der Registerverwaltungseinheit 214 verbunden und überwacht, wann eine ausgegebene Anweisung abgeschlossen ist.
  • Wenn die Abfertigungseinheit 212 eine aktuelle Anweisung abfertigt, ordnet die vereinheitlichte Hauptzuordnungsfunktion 218 der Registerverwaltungseinheit 214 einem physischen Register in den Physische-Register-Dateien 232a bis 232n, das gerade keinem logischen Register zugewiesen ist, die Nummer eines logischen Zielregisters zu. Bei dem Ziel wird davon ausgegangen, dass es zu dem bezeichneten physischen Register aus den Physische-Register-Dateien 232a bis 232n umbenannt wird. Die vereinheitlichte Hauptzuordnungsfunktion 218 entfernt das zugewiesene physische Register aus einer in der vereinheitlichten Hauptzuordnungsfunktion 218 gespeicherten Liste 219 freier physischer Register. Alle nachfolgenden Verweise auf dieses logische Zielregister werden auf dasselbe physische Register verweisen, bis die Abruf-Decodier-Einheit 208 eine weitere Anweisung decodiert, die in dasselbe logische Register schreibt. Dann benennt die vereinheitlichte Hauptzuordnungsfunktion 218 das logische Register in eine andere, aus der Frei-Liste 219 ausgewählte physische Position um und wird die Zuordnungsfunktion aktualisiert, um die neuen logisch-zu-physischen Registerzuordnungsfunktionsdaten einzugeben. Wenn die logisch-zu-physischen Registerzuordnungsfunktionsdaten nicht mehr benötigt werden, werden die physischen Register alter Zuordnungen an die Frei-Liste 219 zurückgegeben. Wenn die Liste freier physischer Register 219 nicht genug physische Register enthält, setzt die Abfertigungseinheit 212 die Anweisungsabfertigung aus, bis die benötigten physischen Register verfügbar werden.
  • Nachdem die Registerverwaltungseinheit 214 die aktuelle Anweisung zugeordnet hat, gibt eine Ausgabewarteschlange 222 die aktuelle Anweisung an eine Steuerkomponente für die allgemeine Ausführung 224 aus, welche Ausführungseinheiten (EUs – execution units) 230a bis 230n enthält. Die Ausführungseinheiten 230a bis 230n sind von verschiedenen Typen wie Gleitkomma (FP – floating-point), Festkomma (FX – fixed-point) und Laden/Speichern (LS – load/store). Die Steuerkomponente für die allgemeine Ausführung 224 tauscht über einen Daten-Cachespeicher 234 mit einem Datenspeicher (z. B. RAM 114, ROM 116 in 1) Daten aus. Außerdem kann die Ausgabewarteschlange 222 Anweisungen des Typs FP, des Typs FX sowie LS-Anweisungen enthalten. Jedoch sollte man erkennen, dass jede beliebige Anzahl und Art von Anweisungen verwendet werden kann. Während der Ausführung erhalten die Ausführungseinheiten (EUs) 230a bis 230n die Quellenoperandenwerte von physischen Positionen in den Registerdateien 232a bis 232n und speichern sie Ergebnisdaten, falls vorhanden, in den Registerdateien 232a bis 232n und/oder im Daten-Cachespeicher 234.
  • Wie weiter durch 2 veranschaulicht, enthält die Registerverwaltungseinheit 214 Folgendes: (i) einen Zuordnungsfunktions-Cluster 215, welcher eine Zuordnungsfunktion für architekturdefinierte Register 216, eine vereinheitlichte Hauptzuordnungsfunktion 218, eine temporäre Registerzuordnungsfunktion 220 und eine (ii) Ausgabewarteschlange 222 enthält. Der Zuordnungsfunktions-Cluster 215 verfolgt die den logischen Registern verschiedener Anweisungen zugewiesenen physischen Register. In einer beispielhaften Ausführungsform verfügt die Zuordnungsfunktion für architekturdefinierte Register 216 über 16 logische (d. h. nicht physisch zugeordnete) Register jedes Typs, welche den letzten gültigen (d. h. mit Prüfpunkt versehenen) Zustand der logisch-zu-physischen Registerzuordnungsfunktionsdaten speichern. Jedoch sollte man erkennen, dass verschiedene Prozessorarchitekturen mehr oder weniger logische Register haben können, wie in der beispielhaften Ausführungsform beschrieben. Die Zuordnungsfunktion für architekturdefinierte Register 216 enthält eine Zeigerliste, die ein physisches Register identifiziert, welches den mit Prüfpunkt versehenen Zustand beschreibt. Die Physische-Register-Dateien 232a bis 232n enthalten üblicherweise mehr Register als die Anzahl von Einträgen in der Zuordnungsfunktion für architekturdefinierte Register 216. Es ist zu beachten, dass die spezielle Anzahl von physischen und logischen Registern, die in einem Umbenennungszuordnungsschema verwendet werden, schwanken kann.
  • Im Gegensatz dazu ist die vereinheitlichte Hauptzuordnungsfunktion 218 üblicherweise größer (sie enthält üblicherweise bis zu 20 Einträge) als die Zuordnungsfunktion für architekturdefinierte Register 216. Die vereinheitlichte Hauptzuordnungsfunktion 218 erleichtert das Verfolgen des transienten Zustands von logisch-zu-physischen Registerzuordnungen. Der Begriff ”transient” bezieht sich auf die Tatsache, dass die vereinheitlichte Hauptzuordnungsfunktion 218 versuchsweise logisch-zu-physische Registerzuordnungsdaten verfolgt, während die Anweisungen unter Missachtung der Reihenfolge (”out-of-order”) ausgeführt werden. Zu OoO-Ausführung kommt es üblicherweise, wenn in der Pipeline ältere Anweisungen vorliegen, die länger für die Ausführung brauchen (d. h. mehr Taktzyklen benötigen) würden als neuere Anweisungen. Jedoch wenn das Ergebnis nach dem Ausführen einer OoO-Anweisung erfordern sollte, dass es aus einem bestimmten Grund (z. B. wegen einer falschen Verzweigungsvorhersage) gelöscht wird, kann der Prozessor in den durch die Zuordnungsfunktion für architekturdefinierte Register 216 bewahrten, mit Prüfpunkt versehenen Zustand zurückkehren und die Ausführung ab dem letzten gültigen Zustand wiederaufnehmen.
  • Die vereinheitlichte Hauptzuordnungsfunktion 218 nimmt die Verknüpfung zwischen den physischen Registern in den Physische-Register-Dateien 232a bis 232n und der Zuordnungsfunktion für architekturdefinierte Register 216 vor. Der qualifizierende Begriff ”vereinheitlicht” bezieht sich auf die Tatsache, dass die vereinheitlichte Hauptzuordnungsfunktion 218 die Komplexität des Erstellens einer dedizierten Zuordnungsfunktion nach Kundenwünschen für jede der Registerdateien 232 (z. B. Allgemeinregister (GPRs – general-purpose registers), Gleitkommaregister (FPRs – floating-point registers), Festkommaregister (FXPs – fixed-point registers), Ausnahmebedingungsregister (XERs – exception registers), Bedingungsregister (CRs – condition registers) usw.) erübrigt.
  • Neben dem Erstellen eines transienten logisch-zu-physischen Registerzuordnungsfunktions-Eintrags einer OoO-Anweisung verfolgt die vereinheitlichte Hauptzuordnungsfunktion 218 auch Abhängigkeitsdaten (d. h. Anweisungen, die von der Beendigung einer älteren Anweisung in der Pipeline abhängig sind), was für das Ordnen der Anweisungen wichtig ist. Herkömmlicherweise reiht sich die Anweisung in die Ausgabewarteschlange 222 ein, sobald die vereinheitlichte Hauptzuordnungsfunktion 218 in die logisch-zu-physische Registerumsetzung einer Anweisung eingetreten ist. Die Ausgabewarteschlange 222 dient als Gatekeeper, bevor die Anweisung zur Ausführung an die Ausführungseinheit 230 ausgegeben wird. Meistens kann eine Anweisung die Ausgabewarteschlange 222 nicht verlassen, wenn sie davon abhängig ist, dass eine ältere Anweisung beendet wird. Aus diesem Grund verfolgt die vereinheitlichte Hauptzuordnungsfunktion 218 Abhängigkeitsdaten durch Speichern der Ausgabewarteschlangen-Positionsdaten für jede Anweisung, die zugeordnet wird. Nachdem die Anweisung durch die Steuerkomponente für die allgemeine Ausführung 224 ausgeführt wurde, wird die Anweisung für ”beendet” erklärt und aus der Ausgabewarteschlange 222 zurückgezogen.
  • Die Registerverwaltungseinheit 214 kann in einem einzigen Zyklus mehrere Anweisungen von der Abfertigungseinheit 212 empfangen, um eine gefüllte Einzelausgabe-Pipeline aufrechtzuerhalten. Das Abfertigen von Anweisungen wird durch die Anzahl verfügbarer Einträge in der vereinheitlichten Hauptzuordnungsfunktion 218 begrenzt. In herkömmlichen Zuordnungssystemen, welchen die temporäre Registerzuordnungsfunktion 220 fehlt, gibt es, wenn die vereinheitlichte Hauptzuordnungsfunktion 218 insgesamt 20 Zuordnungsfunktions-Einträge aufweist, ein Maximum von 20 Anweisungen, die sofort in Ausführung befindlich (d. h. prüfpunktlos) sein können. Demgemäß kann die Abfertigungseinheit 212 eines herkömmlichen Zuordnungssystems denkbar mehr Anweisungen ”abfertigen” als die Anzahl, welche tatsächlich aus der vereinheitlichten Hauptzuordnungsfunktion 218 zurückgezogen werden kann. Die Ursache dieses Engpasses bei der vereinheitlichten Hauptzuordnungsfunktion 218 ist die Tatsache, dass der Zuordnungsfunktions-Eintrag einer Anweisung herkömmlicherweise nicht aus der vereinheitlichten Hauptzuordnungsfunktion 218 zurückgezogen werden konnte, bis die Anweisung ”abgeschlossen” wurde (d. h. alle älteren Anweisungen die Ausführung ”beendet” haben).
  • Gemäß einer Ausführungsform dient die temporäre Registerzuordnungsfunktion 220 als ein nicht zeitkritisches Register, für welches eine ”beendete”, aber ”nicht abgeschlossene” Anweisung vor dem letztendlichen Abschluss der Anweisung aus der vereinheitlichten Hauptzuordnungsfunktion 218 zurückgezogen (d. h. aus der vereinheitlichten Hauptzuordnungsfunktion 218 entfernt) werden könnte. Sobald die Anweisung ”abgeschlossen” wird, benachrichtigt die Abschlusseinheit 240 die temporäre Registerzuordnungsfunktion 220 über den Abschluss. Der Zuordnungsfunktions-Eintrag in der temporären Registerzuordnungsfunktion 220 kann dann den architekturdefinierten kohärenten Zustand der Zuordnungsfunktion für architekturdefinierte Register 216 durch Ersetzen des entsprechenden Eintrags, der jetzt in der Zuordnungsfunktion für architekturdefinierte Register 216 gespeichert war, aktualisieren.
  • Wenn die Abfertigungseinheit 212 eine Anweisung abfertigt, vergleicht die Registerverwaltungseinheit 214 die zu der Anweisung gehörige(n) Nummer(n) logischer Register mit den Zuordnungen in der Zuordnungsfunktion für architekturdefinierte Register 216, der vereinheitlichten Hauptzuordnungsfunktion 218 und der temporären Registerzuordnungsfunktion 220, um zu ermitteln, ob eine Übereinstimmung (gewöhnlich als ”Treffer” bezeichnet) in der Zuordnungsfunktion für architekturdefinierte Register 216, der vereinheitlichten Hauptzuordnungsfunktion 218 und/oder der temporären Registerzuordnungsfunktion 220 vorliegt. Diese Auswertung wird als eine Suche in den logischen Registern bezeichnet. Wenn die Suche gleichzeitig bei mehr als einer Registerzuordnungsfunktion (d. h. der Zuordnungsfunktion für architekturdefinierte Register 216, der vereinheitlichten Hauptzuordnungsfunktion 218 und/oder der temporären Registerzuordnungsfunktion 220) erfolgt, wird die Suche als eine parallele Suche in den logischen Registern bezeichnet.
  • Jede Anweisung, die den Wert eines bestimmten logischen Zielregisters aktualisiert, wird einem neuen physischen Register zugeordnet. Jedes Mal, wenn diese neue Ausprägung des logischen Registers von einer anderen Anweisung als eine Quelle verwendet wird, muss dasselbe physische Register verwendet werden. Da es eine Vielzahl von Ausprägungen eine logischen Registers geben kann, kann es auch eine Vielzahl von dem logischen Register entsprechenden physischen Registern geben. Die Registerverwaltungseinheit 214 führt die Tasks des (i) Analysierens, welches physische Register einem durch eine bestimmte Anweisung verwendeten logischen Register entspricht, des (ii) Ersetzens des Verweises auf das logische Register durch einen Verweis auf das entsprechende physische Register (d. h. Registerumbenennung) und des (iii) Zuordnens eines neuen physischen Registers jedes Mal, wenn eine neue Ausprägung irgendeines logischen Registers erstellt wird (d. h. Zuordnung des physischen Registers), aus.
  • Anfangs, bevor Anweisungen abgefertigt werden, empfängt die vereinheitlichte Hauptzuordnungsfunktion 218 keinen Treffer/keine Übereinstimmung, da es keine gerade in Ausführung befindlichen Anweisungen gibt. In einem solchen Fall erstellt die vereinheitlichte Hauptzuordnungsfunktion 218 einen Zuordnungseintrag. Da nachfolgende Anweisungen abgefertigt werden, wenn eine Übereinstimmung mit einem logischen Register für dieselbe Nummer eines logischen Registers sowohl in der Zuordnungsfunktion für architekturdefinierte Register 216 als auch in der vereinheitlichten Hauptzuordnungsfunktion 218 gefunden wird, erhält das Auswählen der logisch-zu-physischen Registerzuordnung der vereinheitlichten Hauptzuordnungsfunktion 218 Priorität, da die Möglichkeit besteht, dass es Anweisungen gibt, die gerade unter Missachtung der Reihenfolge ausgeführt werden (d. h., dass die Zuordnung in einem transienten Zustand ist).
  • Nachdem die vereinheitlichte Hauptzuordnungsfunktion 218 einen Treffer/eine Übereinstimmung in ihrer Zuordnungsfunktion gefunden hat, reiht sich die Anweisung in die Ausgabewarteschlange 222 ein, um auf die Ausgabe zur Ausführung durch eine der Ausführungseinheiten 230 zu warten. Nachdem die Steuerkomponente für die allgemeine Ausführung 224 die Anweisung ausgeführt und ”beendet” hat, aber bevor die Anweisung ”abgeschlossen” wird, zieht die Registerverwaltungseinheit 214 den in der vereinheitlichten Hauptzuordnungsfunktion 218 jetzt gefundenen Zuordnungseintrag aus der vereinheitlichten Hauptzuordnungsfunktion 218 zurück und verschiebt sie den Zuordnungseintrag zur temporären Registerzuordnungsfunktion 220. Daraufhin wird ein Zeitfenster in der vereinheitlichten Hauptzuordnungsfunktion 218 verfügbar gemacht, um eine anschließend abgefertigte Anweisung zuzuordnen. Im Gegensatz zur vereinheitlichten Hauptzuordnungsfunktion 218 speichert die temporäre Registerzuordnungsfunktion 220 keine Abhängigkeitsdaten. Somit hängt die Zuordnung, die zur temporären Registerzuordnungsfunktion 220 übertragen wird, nicht von den Warteschlangenpositionen der mit ihren Quellenzuordnungen verknüpften Anweisungen ab (und verfolgt sie diese nicht). Dies ist so, weil die Ausgabewarteschlange 222 die ”beendete, aber nicht abgeschlossene” Anweisung nach einer erfolgreichen Ausführung zurückzieht. Im Gegensatz dazu speichert eine vereinheitlichte Hauptzuordnungsfunktion bei herkömmlichen Umbenennungszuordnungsschemas, welchen eine temporäre Registerzuordnungsfunktion fehlt, weiter den Quellenumbenennungs-Eintrag, bis die Anweisung abgeschlossen wird. Bei der vorliegenden Ausführungsform kann die temporäre Registerzuordnungsfunktion 220 weiter weg von anderen kritischen Pfadelementen angeordnet werden, weil die Ausführung der vereinheitlichten Hauptzuordnungsfunktion 218 nicht zeitkritisch ist.
  • Sobald die vereinheitlichte Hauptzuordnungsfunktion 218 einen Zuordnungseintrag aus der vereinheitlichten Hauptzuordnungsfunktion 218 zurückzieht und zur temporären Registerzuordnungsfunktion 220 verschiebt, führt der Zuordnungsfunktions-Cluster 215 an einer anschließend abgefertigten Anweisung eine parallele Suche in den logischen Registern durch, um zu ermitteln, ob die nachfolgende Anweisung einen Treffer/eine Übereinstimmung in der Zuordnungsfunktion für architekturdefinierte Register 216, der vereinheitlichten Hauptzuordnungsfunktion 218 und/oder der temporären Registerzuordnungsfunktion 220 enthält. Wenn in mindestens zwei Zuordnungsfunktionen aus der Gruppe der Zuordnungsfunktion für architekturdefinierte Register 216, der vereinheitlichten Hauptzuordnungsfunktion 218 und der temporären Registerzuordnungsfunktion 220 ein Treffer bei/eine Übereinstimmung mit derselben Nummer eines logischen Zielregisters gefunden wird, verleiht der Multiplexer 223 in Ausgabewarteschlange 222 durch Auswählen der logisch-zu-physischen Registerzuordnung der vereinheitlichten Hauptzuordnungsfunktion 218 Priorität vor derjenigen der temporären Registerzuordnungsfunktion 220, welche wiederum Auswahlpriorität vor der Zuordnungsfunktion für architekturdefinierte Register 216 genießt.
  • Der von Barrick vorgeschlagene Mechanismus, durch welchen die Auswahlpriorität ermittelt wird, wird nachfolgend erörtert. Ein logischer Übersichts-Ablaufplan eines beispielhaften Verfahrens zur Ermittlung, welche Zuordnungsdatenwerte beim Ausführen einer Anweisung zu verwenden sind, gemäß einer Ausführungsform. In einer Ausführungsform fertigt eine Abfertigungseinheit 212 eine oder mehrere Anweisungen an eine Registerverwaltungseinheit 214 ab. In Reaktion auf die Abfertigung der Anweisung(en) ermittelt die Registerverwaltungseinheit 214 durch eine parallele Suche in den logischen Registern, ob ein ”Treffer” bei einem zu jeder abgefertigten Anweisung gehörigen logischen Register (zusätzlich zu einem ”Treffer” bei einer Zuordnungsfunktion für architekturdefinierte Register 216) aufgetreten ist. In dieser Hinsicht versteht es sich von selbst, dass vorausgesetzt wird, dass die Zuordnungsfunktion für architekturdefinierte Register 216 immer einen Treffer/eine Übereinstimmung hat, da die Zuordnungsfunktion für architekturdefinierte Register 216 den mit Prüfpunkt versehenen Zustand der logisch-zu-physischen Registerzuordnungsfunktionsdaten speichert. Wenn die Registerverwaltungseinheit 214 keine Übereinstimmung/keinen Treffer in einer vereinheitlichten Hauptzuordnungsfunktion 218 und/oder einer temporären Registerzuordnungsfunktion 220 erkennt, wählt ein Multiplexer 223 die logisch-zu-physischen Registerumbenennungsdaten aus der Zuordnungsfunktion für architekturdefinierte Register 216 aus. Wenn die Registerverwaltungseinheit 214 eine Übereinstimmung/einen Treffer in der vereinheitlichten Hauptzuordnungsfunktion 218 und/oder der temporären Registerzuordnungsfunktion 220 erkennt, ermittelt die Registerverwaltungseinheit 214 in einem Entscheidungsblock, ob sowohl in der vereinheitlichten Hauptzuordnungsfunktion 218 als auch in der temporären Registerzuordnungsfunktion 220 eine Übereinstimmung/ein Treffer auftritt. Wenn in beiden Zuordnungsfunktionen 218 und 220 ein Treffer/eine Übereinstimmung festgestellt wird, ermittelt die Registerverwaltungseinheit 214, ob der Zuordnungseintrag in der vereinheitlichten Hauptzuordnungsfunktion 218”jünger” als der Zuordnungseintrag in der temporären Registerzuordnungsfunktion 220 ist (d. h., ob die Erstellung des Zuordnungseintrags kürzer zurückliegt). Wenn der Eintrag in der vereinheitlichten Hauptzuordnungsfunktion 218 jünger als der Eintrag in der temporären Registerzuordnungsfunktion 220 ist, wählt der Multiplexer 223 die logisch-zu-physischen Registerumbenennungsdaten aus der vereinheitlichten Hauptzuordnungsfunktion 218 aus. Wenn der Eintrag in der vereinheitlichten Hauptzuordnungsfunktion 218 nicht jünger als der Eintrag in der temporären Registerzuordnungsfunktion 220 ist, wählt der Multiplexer 223 die logisch-zu-physischen Registerumbenennungsdaten aus der temporären Registerzuordnungsfunktion 220 aus.
  • Wenn weder in der vereinheitlichten Hauptzuordnungsfunktion 218 noch in der temporären Registerzuordnungsfunktion 220 eine Übereinstimmung/ein Treffer auftritt, wird ermittelt, ob in der vereinheitlichten Hauptzuordnungsfunktion 218 ein ausschließlicher Treffer/eine ausschließliche Übereinstimmung auftritt. Wenn ein ausschließlicher Treffer bei der vereinheitlichten Hauptzuordnungsfunktion 218 auftritt, wählt der Multiplexer 223 die logisch-zu-physischen Registerumbenennungsdaten aus der vereinheitlichten Hauptzuordnungsfunktion 218 aus. Jedoch wenn kein Treffer/keine Übereinstimmung bei der vereinheitlichten Hauptzuordnungsfunktion 218 auftritt (und somit der Treffer/die Übereinstimmung ausschließlich bei der temporären Registerzuordnungsfunktion 220 auftritt), wählt der Multiplexer 223 die logisch-zu-physischen Registerumbenennungsdaten aus der temporären Registerzuordnungsfunktion 220 (Block 320) aus. Eine Steuerkomponente für die allgemeine Ausführung 224 verwendet die Ausgabedaten der Suche in den logischen Registern zur Ausführung.
  • In einer beispielhaften Ausführungsform fertigt eine Abfertigungseinheit 212 eine oder mehrere Anweisungen an die Registerverwaltungseinheit 214 ab. Eine vereinheitlichte Hauptzuordnungsfunktion erstellt einen neuen Eintrag der logisch-zu-physischen Registerzuordnung. Eine Ausgabewarteschlange 222 bewahrt die Ausgabewarteschlangen-Positionsdaten der abgefertigten Anweisung, welche den Zuordnungseintrag verwendet, der über die Suche in den logischen Registern (in 3 beschrieben) ausgewählt wird. Eine Steuerkomponente für die allgemeine Ausführung 224 erkennt, ob eine der in Ausführung befindlichen Anweisungen beendet wurde (d. h. ob eine der Einheiten 130 die Ausführung einer Anweisung beendet hat). Wenn die ausgegebene Anweisung nicht beendet wurde, wartet das Verfahren darauf, dass eine Anweisung beendet wird. In Reaktion auf das Erkennen durch die Steuerkomponente für die allgemeine Ausführung 224, dass eine Anweisung beendet ist, verschiebt die vereinheitlichte Hauptzuordnungsfunktion 218 die logisch-zu-physischen Registerumbenennungsdaten von der vereinheitlichten Hauptzuordnungsfunktion 218 zur temporären Registerzuordnungsfunktion 220. Die vereinheitlichte Hauptzuordnungsfunktion 218 zieht den zur beendeten Anweisung gehörigen Eintrag der vereinheitlichten Hauptzuordnung zurück. Eine Abschlusseinheit 240 ermittelt, ob die beendete Anweisung abgeschlossen ist. Wenn die beendete Anweisung nicht abgeschlossen ist, wartet die Abschlusseinheit 240 weiter, bis sie erkennt, dass die allgemeine Ausführungseinheit 224 alle älteren Anweisungen beendet hat. Jedoch wenn die Abschlusseinheit 240 erkennt, dass die beendete Anweisung abgeschlossen ist, aktualisiert die temporäre Registerzuordnungsfunktion 220 den architekturdefinierten kohärenten Zustand der Zuordnungsfunktion für architekturdefinierte Register 216 und zieht die temporäre Registerzuordnungsfunktion 220 ihren Zuordnungseintrag zurück.
  • US-Patentschrift Nr. 6 189 088 ”Forwarding stored data fetched for out-of-order load/read operation to over-taken operation read-accessing same memory location” von Gschwind, erteilt am 13. Februar 2001 und durch Verweis hierin einbezogen, beschreibt einen beispielhaften ”Out-of-Order”-(OoO-)Prozessor.
  • Bei Gschwind ist 3 ein funktionales Blockschaltbild eines herkömmlichen Computer-Verarbeitungssystems (das z. B. einen superskalaren Prozessor enthält), welches dynamisches Umordnen von Speicheroperationen und hardwaregestützte Implementierungen der Kollisionsprüfungs- und Datenumgehungssequenz unterstützt. Das heißt, das System in 3 enthält die zur Unterstützung des Umordnens von Anweisungen mittels der oben aufgeführten Mechanismen erforderlichen Hardware-Ressourcen, aber es enthält nicht die zur Unterstützung der Ausführung von „Out-of-Order”-Ladeoperationen vor reihenfolgegemäßen Ladeoperationen erforderlichen Hardware-Ressourcen. Das System besteht aus: einem Speicher-Teilsystem 301; einem Daten-Cachespeicher 302; einem Anweisungs-Cachespeicher 304; und einer Prozessoreinheit 300. Die Prozessoreinheit 300 enthält: eine Anweisungswarteschlange 303; mehrere Speichereinheiten (MUs – memory units) 305 zum Durchführen von Lade- und Speicheroperationen; mehrere Funktionseinheiten (FUs – functional units) 307 zum Durchführen von Ganzzahl-, logischen und Gleitkommaoperationen; eine Verzweigungseinheit (BU – branch unit) 309; eine Registerdatei 311; eine Registerzuordnungstabelle 320; eine Warteschlange für freie Register 322; eine Abfertigungstabelle 324; eine Zurückziehungs-Warteschlange 326; und eine reihenfolgegemäße Zuordnungstabelle 328.
  • Im in 3 veranschaulichten Prozessor werden Anweisungen aus dem Anweisungs-Cachespeicher 304 (oder aus dem Speicher-Teilsystem 301, wenn die Anweisungen sich nicht im Anweisungs-Cachespeicher 304 befinden) unter der Steuerung von Verzweigungseinheit 309 abgerufen, in die Anweisungswarteschlange 303 gestellt und anschließend aus der Anweisungswarteschlange 303 abgefertigt. Die von den Anweisungen zur Angabe von Operanden verwendeten Registernamen werden entsprechend dem Inhalt der Registerzuordnungstabelle 320 umbenannt, welche die aktuelle Zuordnung von Namen architekturdefinierter Register zu physischen Registern angibt. Die von den Anweisungen zur Angabe der Ziele für die Ergebnisse verwendeten Namen der architekturdefinierten Register werden aus der Warteschlange für freie Register 322, welche die Namen von physischen Registern enthält, die der Prozessor gerade nicht verwendet, entnommenen physischen Registern zugewiesen. Die Registerzuordnungstabelle 320 wird mit den durch die Anweisungen angegebenen Zuweisungen physischer Register zu den Namen der architekturdefinierten Zielregister aktualisiert. Anweisungen mit allen ihren umbenannten Registern werden in die Abfertigungstabelle 324 gestellt. Anweisungen werden außerdem einschließlich ihrer Adressen und der Namen ihrer physischen und architekturdefinierten Register in Programmreihenfolge in die Zurückziehungs-Warteschlange 326 gestellt. Anweisungen werden aus der Abfertigungstabelle 324 abgefertigt, wenn alle durch solche Anweisungen zu verwendenden Ressourcen verfügbar sind (physische Register wurden den erwarteten Operanden zugewiesen, und Funktionseinheiten sind frei). Die von der Anweisung verwendeten Operanden werden aus der Registerdatei 311 gelesen, welche üblicherweise Allgemeinregister (GPRs), Gleitkommaregister (FPRs) und Bedingungsregister (CRs) enthält. Anweisungen werden, möglicherweise unter Missachtung der Reihenfolge, in einer entsprechenden Speichereinheit 305, Funktionseinheit 307 oder Verzweigungseinheit 309 ausgeführt. Bei Abschluss der Ausführung werden die Ergebnisse aus den Anweisungen in die Registerdatei 311 gestellt. Anweisungen in der Abfertigungstabelle 324, die darauf warten, dass die physischen Register durch die ihre Ausführung abschließenden Anweisungen gesetzt werden, werden benachrichtigt. Die Zurückziehungs-Warteschlange 326 wird über die ihre Ausführung abschließenden Anweisungen sowie darüber, ob sie irgendwelche Ausnahmebedingungen ausgelöst haben, benachrichtigt. Abgeschlossene Anweisungen werden in Programmreihenfolge (ab dem Anfang der Warteschlange) aus der Zurückziehungs-Warteschlange 326 entfernt. Zum Zeitpunkt des Zurückziehens wird, wenn keine Ausnahmebedingungen durch eine Anweisung ausgelöst wurden, die reihenfolgegemäße Zuordnungstabelle 328 aktualisiert, so dass die Namen architekturdefinierter Register auf die physischen Register in Registerdatei 311, welche die Ergebnisse aus der zurückgezogen werdenden Anweisung enthalten, verweisen; die früheren Registernamen aus der reihenfolgegemäßen Zuordnungstabelle 328 werden in die Warteschlange für freie Register 322 zurückgegeben.
  • Andererseits wird, wenn eine Anweisung eine Ausnahmebedingung ausgelöst hat, die Programmsteuerung auf die Adresse der Anweisung gesetzt, die gerade aus der Zurückziehungs-Warteschlange 326 zurückgezogen wird. Ferner wird die Zurückziehungs-Warteschlange 326 gelöscht, wodurch alle nicht zurückgezogenen Anweisungen abgebrochen werden. Ferner wird die Registerzuordnungstabelle 320 auf den Inhalt der reihenfolgegemäßen Zuordnungstabelle 328 gesetzt und wird jedes nicht in der reihenfolgegemäßen Zuordnungstabelle 328 enthaltene Register zur Warteschlange für freie Register 322 hinzugefügt.
  • Ein herkömmlicher superskalarer Prozessor, welcher das Umordnen von Ladeanweisungen bezüglich vorausgehender Ladeanweisungen unterstützt (wie in 3 gezeigt), kann um Folgendes erweitert werden:
    • 1. einen Mechanismus zum Kennzeichnen von Ladeanweisungen, welche bezüglich vorausgehender Ladeanweisungen unter Missachtung der Reihenfolge ausgegeben werden;
    • 2. einen Mechanismus zum Nummerieren von Anweisungen, wie sie abgerufen werden, und zum Feststellen, ob eine Anweisung im Anweisungsstrom früher oder später auftrat. Stattdessen kann ein alternativer Mechanismus verwendet werden, um zu ermitteln, ob eine Anweisung bezüglich einer anderen Anweisung früher oder später auftrat;
    • 3. einen Mechanismus zum Speichern von Informationen über Ladeoperationen, welche unter Missachtung der Reihenfolge ausgeführt wurden, einschließlich ihrer Adresse in der Programmreihenfolge, der Adresse ihres Zugriffs und des für die größte garantierte, das geladene Datenelement enthaltende atomare Einheit gelesenen Datenwerts;
    • 4. einen Mechanismus zum Durchführen einer Kollisionsprüfung, wenn eine Ladeanweisung bezüglich einer oder mehrerer „Out-of-Order”-Ladeanweisungen reihenfolgegemäß ausgeführt wird, und zum Durchführen von Prioritätscodierung, wenn mehrere Anweisungen mit einer Ladeoperation kollidieren;
    • 5. einen Mechanismus zum Umgehen des mit einer kollidierenden Ladeoperation verknüpften Datenelements; und
    • 6. einen Mechanismus zum Löschen des in Schritt (3) erzeugten Datensatzes an der Stelle, wo der ”Out-of-Order”-Zustand in Programmreihenfolge aus der Zurückziehungs-Warteschlange 326 in die Registerdatei 311 zurückgezogen wird.
  • Die durch Gschwind offenbarten Mechanismen werden zusammen mit den im herkömmlichen, in 3 dargestellten ”Out-of-Order”-Prozessor verfügbaren Mechanismen verwendet wie folgt. Jede Anweisung wird mit einer Anweisungsnummer nummeriert, wenn sie in die Anweisungswarteschlange 303 kommt. Eine Ladeanweisung kann früher aus Abfertigungstabelle 324 abgefertigt werden als eine vorausgehende Ladeanweisung. Eine solche Ladeanweisung wird im Folgenden als eine ”Out-of-Order”-Ladeoperation bezeichnet. In einem solchen Fall wird der der Ladeanweisung entsprechende Eintrag in der Zurückziehungs-Warteschlange 326 als ein ”Out-of-Order”-Ladevorgang gekennzeichnet.
  • Das Erkennen der Abfertigung einer ”Out-of-Order”-Ladeoperation aus einer Abfertigungstabelle 324 an eine Speichereinheit 305 zur Ausführung erfolgt vorzugsweise mit zwei Zählern, einem Zähler ”Abgerufene Ladevorgänge” und einem Zähler ”Abgefertigte Ladevorgänge”. Der Zähler ”Abgerufene Ladevorgänge” wird hochgezählt, wenn ein Ladeoperation zur Abfertigungstabelle 324 hinzugefügt wird. Der Zähler ”Abgefertigte Ladevorgänge” wird hochgezählt, wenn eine Ladeoperation zur Ausführung an eine Speichereinheit 305 gesendet wird. Der aktuelle Inhalt des Zählers ”Abgerufene Ladevorgänge” wird an eine Ladeanweisung angehängt, wenn die Ladeanweisung zur Abfertigungstabelle 324 hinzugefügt wird. Wenn die Ladeanweisung zur Ausführung aus der Abfertigungstabelle 324 an eine Speichereinheit 305 abgefertigt wird, wird die Ladeanweisung als eine ”Out-of-Order”-Ladeoperation identifiziert, falls der an die Ladeanweisung in der Abfertigungstabelle 324 angehängte Wert zu diesem Zeitpunkt vom Inhalt des Zählers ”Abgefertigte Ladevorgänge” verschieden ist. Es ist zu beachten, dass die Differenz zwischen den beiden Zählerwerten der genauen Anzahl von Ladeoperationen entspricht, je nachdem, welche Ladeanweisung unter Missachtung der Reihenfolge (”out of order”) ausgegeben wird. ”Out-of-Order”-Ladeanweisungen werden nur dann an eine Speichereinheit 305 abgefertigt, wenn in der Ladereihenfolgetabelle Platz für das Hinzufügen von Einträgen verfügbar ist.
  • Die Ladereihenfolgetabelle ist eine einzelne Tabelle, auf welche alle Speichereinheiten 305 gleichzeitig zugreifen (d. h. es wird nur eine einzige logische Kopie aufrechterhalten, obwohl mehrere physische Kopien aufrechterhalten werden können, um die Verarbeitung zu beschleunigen). Es ist zu beachten, dass bei Verwendung mehrerer physischer Kopien der logische Inhalt der mehreren Kopien für alle Speichereinheiten 305 immer denselben Zustand widerspiegeln muss.
  • Die Anweisungsnummer der in Ausführung befindlichen Anweisung und die Tatsache, ob eine Anweisung spekulativ ausgeführt wird, werden der Speichereinheit 305 für jede ausgegebene Ladeoperation mitgeteilt.
  • Eine durch einen Prozessor implementierte Anweisungssatz-Architektur (ISA) definiert üblicherweise eine feste Anzahl von architekturdefinierten Allgemeinregistern, die zugänglich sind, auf Grundlage von Registerfeldern von Anweisungen der ISA. In Prozessoren für ”Out-of-Order”-Ausführung werden Umbenennungsregister zugewiesen, um Registerergebnisse spekulativ ausgeführter Anweisungen darin unterzubringen. Der Wert des Umbenennungsregisters wird als ein Wert eines architekturdefinierten Registers übergeben, wenn die entsprechende spekulative Anweisungsausführung ”übergeben” oder ”abgeschlossen” ist. Folglich gibt es in einer Registerumbenennungs-Ausführungsform zu jedem Zeitpunkt und wie es von einem im Prozessor ausgeführt werdenden Programm wahrgenommen wird, viel mehr Umbenennungsregister als architekturdefinierte Register.
  • In einer Ausführungsform von Umbenennungsregistern werden architekturdefinierten Registern und Umbenennungsregistern separate Register zugewiesen. In einer weiteren Ausführungsform sind Umbenennungsregister und architekturdefinierte Register zusammengeführte Register. Die zusammengeführten Register enthalten eine Markierung (Tag) zum Anzeigen des Zustands des zusammengeführten Registers, wobei in einem Zustand das zusammengeführte Register ein Umbenennungsregister ist und in einem anderen Zustand das zusammengeführte Register ein architekturdefiniertes Register ist.
  • In einer Ausführungsform mit zusammengeführten Registern werden die ersten n physischen Register als Teil der Initialisierung (zum Beispiel während eines Kontextwechsels oder beim Initialisieren einer Partition) als die architekturdefinierten Register zugewiesen, wobei n die Anzahl der durch die Anweisungssatz-Architektur (ISA) vereinbarten Register ist. Diese Register werden auf den Zustand ”architekturdefiniertes Register” (AR) gesetzt; die übrigen physischen Register nehmen den Zustand ”verfügbar” an. Wenn eine ausgegebene Anweisung ein Zielregister enthält, wird ein neuer Umbenennungspuffer benötigt. Aus diesem Grund wird ein physisches Register aus dem Pool der verfügbaren Register ausgewählt und dem Zielregister zugeordnet. Demgemäß wird der ausgewählte Registerzustand auf den Zustand ”Umbenennungspuffer nicht gültig” (NV – not valid) gesetzt und wird sein Gültig-Bit zurückgesetzt. Nachdem die verknüpfte Anweisung die Ausführung beendet hat, wird das erzeugte Ergebnis in das ausgewählte Register geschrieben, wird sein Gültig-Bit gesetzt und wechselt sein Zustand zu ”Umbenennungspuffer (RB – rename buffer) gültig”. Später, wenn die verknüpfte Anweisung abgeschlossen wird, wird der zugeordnete Umbenennungspuffer zu dem architekturdefinierten Register erklärt, welches das in der gerade abgeschlossenen Anweisung angegebene Zielregister implementiert. Sein Zustand wechselt dann zum Zustand eines architekturdefinierten Registers (AR), um dies widerzuspiegeln.
  • Während Register hinsichtlich der Leistungsfähigkeit fast eine Universallösung sind, haben sie einen Nachteil. Verschiedene Teile eines Computerprogramms verwenden allesamt ihre eigenen temporären Werte und konkurrieren daher um die Verwendung der Register. Da es sehr schwierig ist, die Art und Weise des Programmablaufs während der Laufzeit richtig zu verstehen, gibt es für den Entwickler keinen einfachen Weg, im Voraus zu wissen, wie viele Register er verwenden und wie viele Register er für andere Teile des Programms beiseite lassen sollte. Im Allgemeinen werden derartige Überlegungen nicht berücksichtigt, und die Entwickler und wahrscheinlicher noch die von diesen verwendeten Compiler versuchen, alle für sie sichtbaren Register zu verwenden. Im Fall von Prozessoren mit zu Anfang sehr wenigen Registern ist dies auch die einzige vernünftige Vorgehensweise.
  • Registerfenster zielen darauf ab, dieses Problem zu lösen. Da jeder Teil eines Programms Register zum eigenen Gebrauch benötigt, werden mehrere Sätze von Registern für die verschiedenen Teile des Programms bereitgestellt. Wenn diese Register sichtbar wären, gäbe es mehr Register, um welche konkurriert würde, d. h. sie müssen unsichtbar gemacht werden.
  • Das Unsichtbarmachen der Register lässt sich effizient implementieren; die CPU erkennt die Verschiebung von einem Teil des Programms zu einem anderen während eines Prozeduraufrufs. Es wird durch eine aus einer kleinen Anzahl von Anweisungen ausgeführt (Prolog) und endet mit einer aus einem entsprechend kleinen Satz (Epilog). Beim Berkeley-Aufbau würden diese Aufrufe bei Beendigen des Aufrufs an dieser Stelle einen neuen Satz von Registern ”einlagern” oder als ”inaktiv” (oder ”wiederverwendbar”) kennzeichnen lassen.
  • Prozessoren wie PowerPC sichern den Zustand in vordefinierten und reservierten Maschinenregistern. Wenn eine Ausnahmebedingung eintritt, während der Prozessor bereits den Inhalt des aktuellen Fensters verwendet, um eine weitere Ausnahmebedingung zu verarbeiten, erzeugt der Prozessor in genau dieser Situation einen doppelten Fehler.
  • In einer beispielhaften RISC-Ausführungsform sind nur acht von insgesamt 64 Registern für die Programme sichtbar. Der vollständige Satz von Registern ist als Registerdatei und jeder einzelne Satz von acht Registern ist als Fenster bekannt. Die Datei ermöglicht, dass bis zu acht Prozeduraufrufe über eigene Registersätze verfügen. Solange das Programm nicht Ketten abruft, die länger als acht Aufrufe tief sind, muss den Registern nie gestattet werden, überzulaufen, d. h. außerhalb im Hauptspeicher oder Cachespeicher gesichert zu werden, was im Vergleich zum Registerzugriff ein langsamer Prozess ist. Für viele Programme ist eine Kette von sechs so tief, wie das Programm reicht.
  • Vergleichsweise bietet eine andere Architektur gleichzeitige Sicht in vier Sätze von jeweils acht Registern. Drei Sätze von jeweils acht Registern werden ”gefenstert”. Acht Register (i0 bis i7) bilden die Eingaberegister für die aktuelle Prozedurebene. Acht Register (L0 bis L7) sind für die aktuelle Prozedurebene lokal, und acht Register (o0 bis o7) sind die Ausgaben aus der aktuellen Prozedurebene an die nächste aufgerufene Ebene. Bei Aufruf einer Prozedur verschiebt sich das Registerfenster um sechzehn Register, wodurch die alten Eingaberegister und die alten lokalen Register verborgen werden und die alten Ausgaberegister zu den neuen Eingaberegistern gemacht werden. Die gemeinsamen Register (alte Ausgaberegister und neue Eingaberegister) werden zur Parameterübergabe verwendet. Schließlich sind acht Register (g0 bis g7) für alle Prozedurebenen global sichtbar.
  • Bei einem verbesserten Aufbau können die Fenster ihre Größe verändern, was im gewöhnlichen Fall, wo weniger als acht Register für einen Aufruf benötigt werden, die Verwendung unterstützt. Außerdem werden dabei die Register in einen globalen Satz von 64 und 128 weitere für die Fenster getrennt.
  • Registerfenster stellen außerdem einen einfachen Upgrade-Pfad bereit. Da die zusätzlichen Register für die Programme unsichtbar sind, können jederzeit zusätzliche Fenster hinzugefügt werden. Zum Beispiel führt die Verwendung objektorientierter Programmierung häufig zu einer größeren Anzahl ”kleinerer” Aufrufe, welche zum Beispiel durch Vergrößern der Fenster von acht auf sechzehn untergebracht werden können. Das Endergebnis ist eine geringere Anzahl langsamer Registerfensterüberlauf- und -fülloperationen, weil die Registerfenster weniger häufig überlaufen.
  • Implementierungen von ”Out-of-Order”-Anweisungen für Anweisungssatz-Architektur-(ISA-)Prozessoren können architekturdefinierte Anweisungen direkt oder unter Verwendung von durch eine Hardware-Anweisungsdecodiereinheit aufgerufener Firmware ausführen. Jedoch ”zerschlagen” viele Prozessoren architekturdefinierte Anweisungen in an Hardware-Einheiten innerhalb des Prozessors gerichtete Mikro-Operationen. Ferner kann ein CISC-(complex instruction set computer)Architektur-Prozessor CISC-Anweisungen in RISC-(reduced instruction set computer) Architektur-Anweisungen umsetzen. Um Aspekte der Erfindung zu erläutern, werden ISA-Maschinenanweisungen beschrieben und können interne Operationen (iops) intern als die ISA-Maschinenanweisung oder als kleinere Einheiten (Mikro-ops) oder Mikrocode oder auf jede in der Fachwelt allgemein bekannte Art und Weise eingesetzt werden, wobei sie hierin nach wie vor als Maschinenanweisungen bezeichnet werden. Maschinenanweisungen einer ISA haben ein Format und eine Funktion wie durch die ISA definiert, sobald die ISA-Maschinenanweisung abgerufen und decodiert wird, kann sie in iops zur Verwendung im Prozessor umgewandelt werden.
  • Eine Anweisungssatz-Architektur (ISA) stellt Anweisungsformate bereit, wobei der Wert des Operanden für die durch einen Prozessor ausgeführt werdende Anweisung explizit oder implizit verfügbar ist. Operanden können zum Beispiel durch ein ”Direktfeld” einer Anweisung, durch ein durch einen Registerfeld-Wert der Anweisung explizit identifiziertes oder für den OpCode-Wert der Anweisung implizit definiertes Register bereitgestellt werden. Ferner kann ein Operand sich im Hauptspeicher befinden und durch einen Registerwert eines durch eine Anweisung definierten Registers adressiert werden. Die Adresse des Operanden im Hauptspeicher kann auch durch Addieren des Direktfelds der Anweisung zu einem Wert eines Basisadressenregisters oder durch Addieren eines Werts eines Basisadressenregisters zu einem Wert eines Indexregisters oder durch Addieren eines Werts eines Basisadressenregisters zu einem Wert eines Indexregisters und einem Wert eines Direktfelds ermittelt werden.
  • Um einen schnellen Zugriff auf Operanden bereitzustellen und parallele Ausführung zu unterstützen, wird Cachespeicher-Zwischenspeichern von Operanden (operand caching) angewendet. Zum Beispiel kann ein Operand im Hauptspeicher in einem Cachespeicher aus einer Hierarchie von Cachespeichern zwischengespeichert werden, wobei Cachespeicher für Kohärenz sorgen, indem sie zum Beispiel einem Prozessor, der einen Speichervorgang für den Operanden durchführen muss, die ausschließliche Verwendung einer Zeile zugestehen. Es ist wichtig, dass der dem Prozessor nächstgelegene Cachespeicher schnell ist, was bedeutet, dass der Cachespeicher wahrscheinlich klein ist. Daher werden Werte des Cachespeichers durch den Cachespeicher hindurch gespeichert (stored-thru), hinausgeworfen (cast-out), in einen Cachespeicher einer höheren Ebene zurückgegeben oder anderweitig häufig bereinigt, um neuen Operanden, die der Prozessor benötigt, Platz zu machen.
  • 4 zeigt den Aufbau einer beispielhaften Mehrebenen-Registersatzhierarchie (bzw. eines entsprechenden Register-Cachespeichers). Eine Registerzuordnungsfunktion 406 weist physischen Registern architekturdefinierte Register zu. Die physischen Register sind ein Pool von verfügbaren Registern und zugewiesenen Registern. Der Cachespeicher der niedrigsten Ebene (L1 402) ist ein kleiner Cachespeicher mit kurzer Latenzzeit, und der Cachespeicher der höchsten Ebene (Ln 408) ist der größte Cachespeicher mit langer Latenzzeit. In einer Ausführungsform ist der Cachespeicher der höchsten Ebene (L2 405 in einem 2-Ebenen-Cachespeicher) insofern ein inklusiver Cachespeicher (inclusive cache), als er eine Kopie jedes aktuell definierten Registers enthält. In einer weiteren Ausführungsform enthält jeder Cachespeicher der Hierarchie ein eindeutiges Register, das es in anderen Cachespeichern nicht gibt. Da Cachespeicher-Implementierungen allgemein bekannt sind, wird hierin ein aus L1 402 und L2 405 bestehender Zwei-Ebenen-Cachespeicher zur Erläuterung herangezogen.
  • Wenn ein Kontext eines Programms geladen wird, weist die Registerzuordnungsfunktion gemäß der ISA architekturdefinierten Registern physische Register (aus dem Pool von physischen Registern der Cachespeicher-Hierarchie) zu. In einem Beispiel werden 64 Register durch die Zuordnungsfunktion physischen Registern im L2-Register-Cachespeicher 405 zugewiesen. Ein L2-Verzeichnis 404 wird erstellt, das architekturdefinierte Register entsprechenden Eintragspositionen 410 im L2-Register-Cachespeicher 405 zuordnet. Anfangswerte architekturdefinierter Register werden in die Dateneinträge 410 geladen.
  • Wenn eine erste Anweisung ausgeführt wird, fordert die Ausführungseinheit 401 einen Zugriff auf ein architekturdefiniertes Register im L1-Register-Cachespeicher 402 an. Das L1-Verzeichnis 403 stellt fest, dass das architekturdefinierte Register nicht im L1-Cachespeicher 402 ist, und fordert daher mittels einer Cachespeicher-Verwaltungseinheit 407 das architekturdefinierte Register aus dem L2-Cachespeicher-Verzeichnis 404 an. Das L2-Verzeichnis macht den Eintrag im L2-Cachespeicher ausfindig und sendet ihn an den L1-Register-Cachespeicher 402. Der L1-Register-Cachespeicher 402 erlaubt den Zugriff auf den Eintrag 409 mittels des L1-Verzeichnisses 403, um den Eintrag zu lokalisieren.
  • In einer Ausführungsform verwaltet die Cachespeicher-Verwaltungseinheit 407 den L1-Cachespeicher 402 zum Beispiel unter Verwendung eines LRU-(least recently used – zuletzt verwendet)Ersetzungsalgorithmus, erhält aber im L2-Cachespeicher 405 eine aktuelle Kopie des vollständigen Registersatzes und im L1-Cachespeicher 402 eine aktuelle Kopie einer Teilmenge aufrecht. In einer Ausführungsform wird eine Kopie von L1-Cachespeicher-402 Einträgen in den L2-Cachespeicher 405 zurückgeschrieben, wenn Anweisungen abgeschlossen werden, die den L1-Cachespeicher-402 Eintrag verändern. Die in 4 gezeigte Ausführungsform veranschaulicht nur eine einzige mögliche Ausführungsform. Weitere Ausführungsformen sind möglich, zum Beispiel ein L1-Cachespeicher, der in einem inhaltsadressierbaren Speicher (CAM – content addressable memory) implementiert ist, welcher Verzeichnisfelder und ein entsprechendes Datenfeld mit einem in einem Direktzugriffsspeicher (RAM – random access memory) implementierten L2-Cachespeicher enthaltende Einträge aufweist, wobei das L1-Cachespeicher-Verzeichnisfeld zum Beispiel eine Adresse eines dem L1-Eintrag entsprechenden L2-Eintrags aufweist.
  • In einer Ausführungsform enthalten die L1- und L2-Verzeichniseinträge alle oder einige der Folgenden: ein Gültig-Bit, ein Registeradressenfeld, ein LRU-Anzeigerfeld, ein Sequenzfeld, ein Thread-Feld. Das Gültig-Bit zeigt an, ob der Verzeichniseintrag gültig ist, das Registeradressenfeld gibt die dem Eintrag zugewiesene Registeradresse an, das LRU-Anzeigerfeld gibt an, wann der Eintrag zuletzt verwendet wurde, das Sequenzfeld gibt das relative Alter des entsprechenden Umbenennungsregisters an (wobei ein Alter von 0 anzeigt, dass der Eintrag den der zuallerletzt abgeschlossenen Anweisung entsprechenden aktuellen Architekturwert enthält) und das Thread-Feld gibt an, mit welchem Thread das Register verknüpft ist. In einer Ausführungsform können 2 Threads gleichzeitig aktiv sein, und das Thread-Feld würde durch ein einzelnes Bit implementiert. In der Ausführungsform würden 2 Sätze von 64 architekturdefinierten GPRs (einer für jeden der zwei Threads) und eine größere Anzahl von Umbenennungsregistern in den L2-Cachespeicher 405 aufgenommen. Natürlich werden einige dieser Felder (einschließlich des LRU) vom inklusiven L2-Cachespeicher 405 nicht benötigt. Jedoch würden sich stets nur die zuletzt verwendeten im L1-Cachespeicher 402 befinden.
  • Registersatz-Hierarchien (Register-Cachespeicher-Hierarchien) mit mehreren Ebenen versetzen Architekten in die Lage, Prozessoren zu entwickeln, die große Mengen von Threads (z. B. 8 oder mehr Threads) und große Registerdateien für jeden Thread (z. B. 64 architekturdefinierte Allgemeinregister und eine noch größere Anzahl temporärer Umbenennungsregister) unterstützen. Damit Mehrebenen-Registerdateien effizient arbeiten können, müssen häufig verwendete Werte in Cachespeicherebenen mit kürzerer Latenzzeit bewahrt werden und sollten nicht verwendete Werte in einer Hierarchieebene mit längerer Latenzzeit bewahrt werden, um zu ermöglichen, dass die am häufigsten verwendeten Werte in Registerdatei-Ebenen (Register-Cachespeichern) mit kurzer Latenzzeit gespeichert werden. Die Entscheidung über das Platzieren von Registerdateien würde ausschließlich von den vergangenen Zugriffsmustern eines Registers abhängen, ohne dass im Compiler verfügbares Wissen über den Datenfluss genutzt werden könnte, um Register auf der geeigneten Ebene zu platzieren. Zum Beispiel könnte ein LRU-(least recently used – zuletzt verwendet) oder ein FIFO-(first in, first out)Ersetzungsalgorithmus verwendet werden.
  • In einer Ausführungsform nutzt eine Mehrebenen-Registerdatei-Hierarchie vom Compiler bereitgestellte Informationen über zukünftige Zugriffe auf eine Registerdatei. Zum Beispiel führt der Prozessor einen Anweisungssatz aus, wobei bestimmte ”Letztverwendungs-Anweisungen” (LU-(last-use)Anweisungen) eine Letztverwendungs-Information enthalten. In einer Ausführungsform wird ein Register, wenn für das Register eine Letztverwendungs-Angabe erkannt wird, aus dem Cachespeicher mit kürzerer Latenzzeit auf eine höhere Registerdatei-Hierarchieebene (mit längerer Latenzzeit) hochbefördert. Gemäß einer Ausführungsform wird ein Zurückschreiben eines Operanden in den langsameren Speicher eingeleitet, wenn ein Operand abgerufen wird. In einer weiteren Ausführungsform wird ein Zurückschreiben des Operanden eingeleitet, wenn die die Letztverwendung angebende Anweisung abgeschlossen ist. In noch einer weiteren Ausführungsform wird die Zuordnung des verknüpften architekturdefinierten Registers aufgehoben (es ist dann keinem architekturdefinierten Register mehr zugewiesen), wenn eine Letztverwendungs-Angabe für ein architekturdefiniertes Register erkannt wird, und wird der Wert gelöscht (nicht auf eine nächste Ebene hochbefördert). Dies erfolgt vorzugsweise, wenn die Anweisung, die das Register letztmals verwendete, abgeschlossen ist. Jedoch werden auf Grundlage der Erläuterung auch Varianten des Bestimmens, wann die Letztverwendung des Registers auftritt, betrachtet, einschließlich der Angabe, wie oft auf das Register zugegriffen werden wird, der Angabe einer Anzahl von auszuführenden Anweisungen, der Angabe einer bestimmten Anweisung usw.
  • In einer Ausführungsform wird eine Mehrebenen-Registerdatei (auch als Register-Cachespeicher bekannt) durch Nutzen von Letztverwendungs-Informationen in einem Anweisungssatz verwaltet. Wenn eine Letztverwendung eines Registers angegeben ist, wird das angegebene Register aus mindestens einer Ebene der Mehrebenen-Registerdatei gelöscht. Eine Letztverwendung kann durch eine semantische Spezifikation, die den letztmals verwendeten Wert auf einen undefinierten Wert setzt, angegeben werden. In einer Ausführungsform wird das angegebene Register, wenn eine Letztverwendung angegeben ist, aus allen Ebenen der Mehrebenen-Registerdatei gelöscht.
  • In einer Ausführungsform enthält eine Mehrebenen-Registerdatei eine Registerdateiplatzierungslogik, wobei die Platzierungslogik eine Ebene in der Hierarchie bestimmt, auf welcher eine bestimmte Registerdatei zu platzieren ist. In der Ausführungsform wird eine Letztverwendungs-Angabe von der Anweisungsdecodierlogik des Prozessors, die eine die Letztverwendungs-Angabe enthaltende Anweisung decodiert, und eine Anweisungsabschlussinformation von der Anweisungsabschlusslogik empfangen, wobei die Letztverwendungs-Information durch eine Anweisung, die angibt, dass eine Letztverwendung aufgetreten ist, bereitgestellt wird oder wobei die Letztverwendungs-Information einer Mehrebenen-Registerdatei-Hinweisanweisung entspricht.
  • Vorzugsweise ist die Anweisung, welche die Letztverwendungs-Angabe bereitstellt, eine Präfix-Anweisung zu der Anweisung, welche tatsächlich das Register letztmals verwendet, jedoch ist eine Anweisung, welche ihre eigene Letztverwendung eines Registers angibt, eine weitere hierin betrachtete Ausführungsform. Es ist auch möglich, dass eine Anweisung eine Letztverwendung für eine Vielzahl von architekturdefinierten Allgemeinregistern (GPRs) angeben kann. In einer weiteren Ausführungsform gibt eine Anweisung eine Letztverwendung für Register der Anweisung sowie eine Letztverwendung von Registern einer anderen (späteren) Anweisung an.
  • In einem Beispiel können architekturdefinierte Allgemeinregister mehreren physischen Registern aus einem Pool von physischen Registern zugewiesen werden, um ”Out-of-Order”-(OoO-)Ausführung von Anweisungen zu unterstützen, wobei die Werte von Ergebnisoperanden vor Abschluss der Ausführung der Anweisung temporären Registern (Umbenennungsregistern) und, wenn die verknüpfte Anweisung abgeschlossen ist, den aktuellen architekturdefinierten Allgemeinregistern zugewiesen werden. Die Zuweisung von Werten zu einem physischen Register kann eine Markierung (Tag) enthalten, die anzeigt, ob das entsprechende physische Register eine Bindung mit einem architekturdefinierten Register aufweist, das einen endgültigen Wert enthält, oder ob das entsprechende physische Register eine Bindung mit einem architekturdefinierten Register aufweist, das einen vorläufigen Wert enthält, der eine Verknüpfung mit einem architekturdefinierten Register aufweist, oder ob das entsprechende physische Register gerade keiner Verknüpfung mit einem architekturdefinierten Register zugewiesen ist.
  • Ähnlich in Cachespeichern ausgeführten Zwischenspeichervorgängen des Hauptspeichers kann der Pool von physischen Registern eine Cachespeicher-Hierarchie von physischen Registern bilden, in welcher einige physische Register in einem kleinen Bereich mit schnellem Zugriff bereitgestellt sind, welcher ein Register-Cachespeicher eines größeren Bereichs mit langsamerem Zugriff ist. Zum Beispiel können die in Cachespeichern zwischengespeicherten physischen Register (Register-Cachespeicher) in Selbsthalteschaltungen, in einem kleinen Direktzugriffsbereich oder in einem kleinen inhaltsadressierbaren Bereich implementiert werden. Dabei enthält der Register-Cachespeicher einen Datenteil und einen Verzeichnis-(Markierungs-)Teil, enthält der Datenteil mit einem Register verknüpfte Operandenwerte und identifiziert der Verzeichnisteil das mit dem Datenteil verknüpfte architekturdefinierte Register oder Umbenennungsregister. In einer solchen Implementierung werden architekturdefinierte Register in aktiven physischen Registern in Cachespeichern zwischengespeichert, wenn sie häufig oder gegenwärtig verwendet werden, jedoch werden sie zum Beispiel in den langsameren Bereich verschoben, um Registern Platz zu machen, auf welche vor kürzerer Zeit zugegriffen wurde.
  • Ein großer Pool von physischen Registern ist besonders nützlich in einer Multithread-Umgebung, wo mehrere ISA-Threads gleichzeitig von ein und demselben Prozessor ausgeführt werden. In einer Prozessor-ISA mit 64 architekturdefinierten Allgemeinregistern (GPRs), welche ”Out-of-Order”-Ausführung (Ausführung unter Missachtung der Reihenfolge) durchführt, muss der Prozessor die 64 architekturdefinierten GPRs sowie eine große Anzahl von Umbenennungsregistern zum vorübergehenden Aufnehmen des GPR-Zwischenstatus bereitstellen. In einem solchen Multithreading unterstützenden Prozessor benötigt jeder vom Prozessor unterstützte Thread diese Register. In einem 8-Thread-Prozessor der ISA werden 512 Register nur für die architekturdefinierten Allgemeinregister benötigt, ganz zu schweigen von einer größeren Anzahl von Umbenennungsregistern.
  • In einer Ausführungsform verwendet der Multithread-Prozessor einen Register-Cachespeicher-Mechanismus, wobei das Verzeichnis des Register-Cachespeichers vorzugsweise einen Thread-Bezeichner zum Identifizieren der Thread-Verknüpfung mit dem Register enthält. Das Verzeichnis enthält vorzugsweise einen Architekturregister-Bezeichner zum Identifizieren, mit welchem architekturdefinierten Register der Zeichenfolge der entsprechende Registeroperand verknüpft ist. Das Verzeichnis enthält vorzugsweise einen Abschlussanzeiger, der anzeigt, welcher Registerwert durch einen Abschluss einer entsprechenden Anweisung übergeben wird.
  • Das Problem bei Cachespeichern ist im Allgemeinen der durch das Verwalten der Daten verursachte Aufwand. Zugriffe auf einen Registerwert, der nicht in einem Cachespeicher zwischengespeichert ist, erfolgen langsamer, und der Zugriff auf Cachespeicher wird durch Castouts und Aktualisierungen beeinträchtigt. Die vorliegende Erfindung stellt einen Weg für den Prozessor bereit, zu wissen, ob ein Wert eines architekturdefinierten Registers aufbewahrt werden muss oder nicht. In einer Ausführungsform erhält der die ausgeführt werdenden Anweisungen bereitstellende Programmierer Anweisungen zum Verwalten der Existenz ausgewählter GPRs. Somit kann der Programmierer, obwohl die Anweisungssatz-Architektur (ISA) 64 architekturdefinierte GPRs für jeden Thread bereitstellt, diese selektiv aktivieren oder inaktivieren. In einer Ausführungsform ist ein Programmierer darauf beschränkt, 32 der 64 GPRs zu verwenden. Das auf dem Thread auszuführende Programmmodul wird so kompiliert, dass 32 GPRs inaktiviert und nur die anderen 32 Register verwendet werden. In einer Umgebung wird das Programm so kompiliert, dass zwei gleichwertige Module erzeugt werden, von welchen das eine 64 GPRs und das andere 32 GPRs verwendet. Das ausgeführte Modul wird zum Beispiel auf Grundlage von Umweltschutzerwägungen (wie Stromverbrauchs- oder Leistungsstatus) vom Betriebssystem (OS) ausgewählt. Die selektive Aktivierung von Allgemeinregistern (GPRs) ermöglicht dem zugrundeliegenden Prozessor, ein höheres Trefferverhältnis im Register-Cachespeicher zu erzielen, da es zum Beispiel insgesamt weniger GPRs gibt, die gleichzeitig unterstützt werden.
  • In einer weiteren Ausführungsform ist der Programmierer nicht in der Lage, GPRs zu aktivieren/inaktivieren, erhält er aber einen Weg, dem Prozessor eine ”Aktivitätsinformation” zu geben. Also kann der Programmierer zum Beispiel dem Prozessor mitteilen, dass der Wert eines Registers ein temporärer Wert ist, der nicht noch einmal verwendet wird und deshalb nicht gesichert zu werden braucht. Der Prozessor kann die Register-Cachespeicher-Operation entsprechend gestalten, indem er zum Beispiel den Wert überhaupt nicht im Cachespeicher speichert oder in einem anderen Beispiel das Allgemeinregister (GPR) aus dem Cachespeicher entfernt, ohne es in den langsamen Bereich zurückzuschreiben.
  • In einer Ausführungsform umfasst eine Letztverwendungs-(LU – last-use)Anweisung ein OpCode-Feld, welches eine durchzuführende Funktion angibt, und ein Registerfeld, welches ein LU-Register angibt. Wenn die LU-Anweisung ausgeführt wird, wird der Operand im LU-Register aus der Registerdatei der ersten Ebene (L1RF) gelesen und zur Durchführung der Funktion verwendet. Sobald das LU-Register gelesen wurde, weiß der Prozessor aus der LU-Anweisung, dass der Operand im LU-Register nicht mehr benötigt wird. Mit diesem Wissen kann der Prozessor verschiedenste Maßnahmen durchführen, darunter zum Beispiel das Löschen des Werts aus dem Cachespeicher, das Aufheben der Bindung des physischen Registers mit einem architekturdefinierten Register, das Verschieben der Bindung des architekturdefinierten Registers in einen Eintrag in einem langsameren Cachespeicher.
  • In einer Ausführungsform ist das LU-Register ein Allgemeinregister, ein Gleitkommaregister, ein Zusatzregister (wie ein Zugriffsregister der z/Architecture-ISA) oder ein generisches Register, das für Skalar- oder Gleitkommawerte nützlich ist.
  • In einer Ausführungsform liefert jeder Lesezugriff auf ein LU-Register durch eine spätere Anweisung, wobei keine Zwischenanweisung in das LU-Register geschrieben hat, einen ISA-definierten, maschinenspezifischen Wert (Standardwert), wobei der maschinenspezifische Wert ein nicht vorhersagbarer, undefinierter oder vordefinierter Wert ist, wobei der vordefinierte Wert auf allen Stellen 1, auf allen Stellen 0, ein hochgezählter Wert, ein heruntergezählter Wert, ein durch ein programmierbares Register festgelegter Wert oder eine Kombination dieser Werte sein kann.
  • Die Hierarchie der Register-Cachespeicher könnte aus einer beliebigen Anzahl von Ebenen bestehen, zur Erläuterung der Erfindung erörtert die Darstellung jedoch in erster Linie einen Cachespeicher mit einer Ebene. Einem Fachmann kann die Erläuterung des Cachespeichers mit einer Ebene dazu dienen, innerhalb des Umfangs der vorliegenden Erfindung Aspekte der Erfindung in Implementierungen von Register-Cachespeichern mit mehreren Ebenen in die Praxis umzusetzen.
  • Entsprechend 4 ruft in einer beispielhaften Implementierung eine Anweisungsabrufeinheit (IF) 411 Anweisungen 415 aus dem Hauptspeicher ab, decodiert eine Anweisungsdecodiereinheit (ID) 412 die Anweisung und werden, auf Grundlage der ID-Decodierung, architekturdefinierte Register, die sich nicht schon in der Registerdatei der niedrigeren Ebene 1 (L1RF) 402 befinden, aus der Registerdatei einer höheren Ebene (der Ebene n) (LnRF) 405 geladen, während weniger aktive architekturdefinierte Register gemäß dem L1-Ersetzungsalgorithmus aus L1RF 402 in LnRF 405 verschoben werden. Daraufhin wird die Anweisung in einer Ausführungseinheit (EX) 401 ausgeführt und wird ein resultierender Operandenwert in die L1RF 402 zurückgeschrieben (WB) 413. Bei Abschluss der Anweisung weist eine Abschlusseinheit 414 (Abschließen) den zurückgeschriebenen Operanden dem aktuellen architekturdefinierten Register zu.
  • In einer Ausführungsform bietet eine Mehrebenen-Registerdatei (d. h. Cachespeicher-Zwischenspeicherung von Registern unter Verwendung von LnRFs) einen Weg, Registerzugriff mit kurzer Latenzzeit (auf L1-Cachespeicher 402) aufrechtzuerhalten und gleichzeitig eine große Registerdatei bereitzustellen. Eine Registerdatei der ersten Ebene (niedrigsten Ebene) bietet schnellen Zugriff auf die Werte, auf welche zuletzt zugegriffen wurde. Eine Registerdatei der zweiten Ebene (einer höheren Ebene) bietet langsameren Zugriff und einen vollständigen Satz von Registern für jeden Thread.
  • MEHREBENEN-CACHESPEICHERVERWALTUNG:
  • Ein Ziel ist, die am häufigsten verwendeten Register im Cachespeicher (L1RF) bereitzuhalten, da es wahrscheinlicher ist, dass auf diese Register nochmals zugegriffen wird. Jedoch ist es ohne Einblick vom Programmierer schwierig, vorherzusagen, welche Register in der Zukunft tatsächlich verwendet werden.
  • Ein auf dem Verlauf beruhender Ansatz (LRU- (least recently used – zuletzt verwendet) oder FIFO-(first-in-first-out)Ersetzung) kann verwendet werden, jedoch sind auf dem Verlauf beruhende Registerdateien für kleine Registerdatei-Cachespeicherebenen besonders ineffizient.
  • Nun wird eine Mehrebenen-Registerdatei, bei welcher die ISA Letztverwendungs-Informationen bereitstellt, vorgestellt. Die Mehrebenen-Registerdatei verfügt in einer Ausführungsform über einen herkömmlichen Ersetzungsalgorithmus (LRU oder FIFO), welcher auf Grundlage von Letztverwendungs(LU-)Informationen über architekturdefinierte Register erweitert wird.
  • Wenn eine Anweisung eine Letztverwendungs-(LU – last-use)Angabe bereitstellt, werden Operanden-Cachespeicher-Verwaltungsmaßnahmen an einem als ein LU-Operand der Anweisung angegebenen Operanden durchgeführt, welche aus einer oder mehreren der Folgenden bestehen:
    der Verwaltungsmaßnahme, welche einen Operandenwert in einen Cachespeicher einer höheren Ebene (LnRF) hochbefördert und aus dem Cachespeicher der niedrigeren Ebene (L1RF) löscht. Die Verwaltungsmaßnahme kann durchgeführt werden, wenn die Anweisung abgeschlossen wird, wenn die Anweisung letztmals auf den Operanden zugreift oder durch Einleiten des Hochbeförderns, wenn die LU Angabe erkannt wird, und, zu einem späteren Zeitpunkt, Löschen aus dem Cachespeicher der niedrigeren Ebene (L1RF);
    der Verwaltungsmaßnahme, welche einen LU-Operandenwert in einen Cachespeicher einer höheren Ebene (LnRF) hochbefördert und im Cachespeicher der niedrigeren Ebene (L1RF) den Operanden zur Löschung kennzeichnet; und
    der Verwaltungsmaßnahme, welche beim Abschluss alle Kopien des Operanden auf allen Ebenen des Cachespeichers löscht.
  • Vorteilhafterweise führt das Hochbefördern eines Datenelements in einen Cachespeicher einer höheren Ebene zu:
    höherer Zuverlässigkeit durch Verwenden einer Speicherebene, welche durch mehr Schutzmechanismen (Fehlerkorrekturcode (ecc – error correction code), RAID-Redundanz usw.) und/oder flächen- und energieeffizientere Schutzmechanismen geschützt werden kann, weil sie sich nicht im kritischen Ausführungspfad befindet; und
    höherer Leistungsfähigkeit durch Sicherstellen, dass nichtverwendete Werte verschoben werden, um in niedrigeren Cachespeicher-Ebenen Platz zu machen; und
    besserem Verhalten hinsichtlich Strom-/Energieverbrauch
  • Dem Fachmann wird einleuchten, dass, wenn der Letztverwender auf den LU Wert zugegriffen hat (wie durch eine LU-Anweisung angegeben), bei normaler Ausführung keine weiteren Lesevorgänge zu erwarten sind. Jedoch kann die Anweisungsausführung wegen Ausnahmebedingungen und anderer besonderer Bedingungen abgebrochen werden und kann die Anweisung erneut ausgeführt werden. Somit verbleibt ein Wert durch Verzögern des Hochbeförderns des Werts auf die nächsthöhere Ebene in der aktuellen Ebene, bis kein weiteres Ereignis mehr es erforderlich machen kann, den Wert nochmals zu lesen. Da diese Ereignisse selten sind, wird der Wert jedoch in einer Ausführungsform nach dem letzten Lesevorgang auf die höhere Ebene hochbefördert, und wenn eine Ausnahmebedingung auftritt, kann der Wert von der höheren Ebene abgerufen werden.
  • In einer Ausführungsform wird der Operand ohne ein Zurückschreiben aus dem Cachespeicher gelöscht, wenn die Anweisung abgeschlossen wird.
  • In einer Ausführungsform wird der Operand aus dem Cachespeicher gelöscht, wenn die die Letztverwendung (LU) enthaltende und den in einen undefinierten Zustand zu versetzenden Operanden angebende Anweisung abgeschlossen wird. Der Operand wird nicht in einen Cachespeicher einer höheren Ebene (LnRF) hochbefördert, und zukünftige Verweise auf die Operandenposition werden entweder einen ISA-definierten Standardwert, der zum Beispiel ein alter Wert, ein vordefinierter Wert (zum Beispiel auf allen Stellen 1 oder auf allen Stellen 0) sein kann, oder einen undefinierten Wert liefern.
  • In einer weiteren Ausführungsform wird der Operand gelöscht, wenn bekannt ist, dass keine weiteren Ausnahmebedingungen mehr auftreten können, die es erforderlich machen könnten, den Wert nochmals zu lesen. Zum Beispiel wenn festgestellt wurde, dass keine Anweisung mit noch anstehendem Abschluss bis zur und einschließlich der LU-Anweisung auf eine Ausnahmebedingung stoßen kann.
  • In einer Ausführungsform wird der Operand aus allen Ebenen der Cachespeicher-Hierarchie (L1RF bis LnRF) gelöscht, wenn die LU-Anweisung abgeschlossen wird, ohne das Ergebnis zurückzuschreiben, und zukünftige Verweise auf die Operandenposition werden entweder einen alten Wert, einen vordefinierten Wert (zum Beispiel auf allen Stellen 1 oder auf allen Stellen 0) oder einen undefinierten Wert liefern.
  • In einer Ausführungsform wird der Operand aus allen Ebenen der Cachespeicher-Hierarchie (L1RF bis LnRF) gelöscht, wenn festgestellt wird, dass keine Ausnahmebedingungen auftreten können, die es erforderlich machen könnten, den Operanden nochmals zu lesen, wo festgestellt wurde, dass keine Anweisung mit noch anstehendem Abschluss bis zur und einschließlich der LU-Anweisung, welche die Letztverwendung angibt und die Einstellung für einen undefinierten Wert festlegt, auf eine Ausnahmebedingung stoßen kann.
  • In einer Ausführungsform wird der Operand in einen Cachespeicher einer höheren Ebene hochbefördert, wenn es ein LU-Operand ist, und dann wird der Operand aus dem Cachespeicher der aktuellen Ebene gelöscht, wenn der Operand zur Ausführung gelesen wurde. Daraufhin wird der LU-Operand aus einer oder allen Cachespeicher-Ebenen gelöscht. In einer Ausführungsform wird, wenn nach dem Löschen noch ein Zurückschreiben des Operanden ansteht, das Zurückschreiben abgebrochen.
  • In einer Ausführungsform wird ein Zurückschreiben in einen Cachespeicher der nächsthöheren Ebene eingeleitet, wenn der Letztverwendungs-Operand erstmals erkannt wird. Dann wird der Operand aus dem Cachespeicher der niedrigeren Ebene gelöscht, wenn der Operand gelesen wurde. Schließlich wird der Operand aus einer oder allen Ebenen des Cachespeichers gelöscht. In einer Ausführungsform wird das Zurückschreiben abgebrochen, wenn das Zurückschreiben noch ansteht.
  • Vorteilhafterweise führt das Entfernen nichtverwendeter Werte aus der Mehrebenen-Registerdatei zu:
    höherer Zuverlässigkeit bei Entfernen nichtverwendeter Werte aus der Registerdatei, bei welchen Integritätsfehler auftreten können, die eine Korrektur oder Beendigung der Ausführung auf Anwendungs-, Partitions- und/oder Systemebene erzwingen. Was die Fehlerkorrektur anbelangt, müssen Integritätsfehler bei merklicher Zunahme des Stromverbrauchs und/oder merklichem Rückgang der Leistung korrigiert werden. Wenn Fehler nicht korrigiert werden können, kommt es zu einem Systemausfall auf Anwendungs-, Partitions- und/oder Systemebene, wenn die betroffene Anwendung, die betroffene Partition und/oder das betroffene System wegen einer Datenintegritätsbedingung beendet wird;
    höherer Leistungsfähigkeit durch Verfügbarmachen von mehr Einträgen für verwendete Werte auf der Vielzahl von Cachespeicher-Ebenen; und
    besserem Verhalten hinsichtlich Strom-/Energieverbrauch, weil nichtverwendete Teile einer Registerdatei abgeschaltet werden können.
  • In einer beispielhaften Ausführungsform wird eine Anweisung mit einer Letztverwendungs-Angabe, die besagt, dass ein Operandenwert eines Registers von keiner späteren Anwendung mehr verwendet wird, ausgeführt. Für den Fall, dass ein Ereignis (wie eine Ausnahmebedingung) auftritt, welches einen Abbruch der Anweisungsausführung verursacht, wird eine Kopie des Operanden zuerst in einen Cachespeicher einer höheren Ebene kopiert, wobei die Kopie für eine spätere Ausführung verfügbar sein wird. Diese Kopie kann zusammen mit dem Wert im Cachespeicher der niedrigeren Ebene gelöscht werden, wenn die Anweisungsausführung abgeschlossen (übergeben) wird. Die Anweisung wird decodiert. Dann werden bei der Ausführung zu verwendende Operanden gelesen. Dann wird ein Zurückschreiben des als durch diese Anweisung letztmals zu verwendend identifizierten Letztverwendungs-(LU-)Operanden in die Registerdatei einer höheren Ebene (LnRF) eingeleitet. Dann wird die Anweisung einschließlich eines Zugriffs auf den LU-Operanden ausgeführt. Schließlich wird der LU-Operand aus der Registerdatei mit kurzer Latenzzeit (L1RF) gelöscht.
  • In einer Ausführungsform sichert eine Anweisung mit einer Letztverwendungs-Angabe einen Operandenwert eines Registers nicht, sondern löscht sie alle Ausprägungen des Operanden auf allen Ebenen der Cachespeicher-(Registerdatei-)Hierarchie, wenn sie abgeschlossen wird. In einer Ausführungsform wird das Ungültig-Bit in den dem Operandenregister entsprechenden Verzeichnissen 403 404 zurückgesetzt. In einer weiteren Ausführungsform wird ein separates Zuordnungs-/Zuordnungsaufhebungs-Bit verwendet.
  • Entsprechend 5 wird in einer Ausführungsform eine Mehrebenen-Registerhierarchie verwaltet, in welcher architekturdefinierte Register 505 Registerpools zugeordnet sind, wobei die Mehrebenen-Registerhierarchie einen Registerpool 507 der ersten Ebene zum Cachespeicher-Zwischenspeichern von Registern eines Registerpools 506 der zweiten Ebene aufweist. Bei einer Initialisierung wie nach Beginnen einer Kontextwechsel-Operation 501 weist ein Prozessor verfügbaren Einträgen aus dem Pool der ersten Ebene oder aus dem Pool der zweiten Ebene architekturdefinierte Register zu 502, wobei architekturdefinierte Register durch eine Anweisungssatz-Architektur (ISA) definiert und durch Registerfeld-Werte von Anweisungen der ISA adressierbar sind, wobei das Zuweisen das Verknüpfen jedes zugewiesenen architekturdefinierten Registers mit einem entsprechenden Eintrag eines Registerpools beinhaltet. Dann, nach erfolgter Initialisierung (Kontextwechsel) 503, werden Werte architekturdefinierter Register gemäß einem Ersetzungsalgorithmus bezüglich des Pools der ersten Ebene durch eine Cachespeicher-Verwaltungseinheit 407 aus dem Pool der zweiten Ebene 505 in den Pool der ersten Ebene 507 verschoben 504. Auf Grundlage von in Ausführung befindlichen Anweisungen 508 wird auf Werte architekturdefinierter Register aus dem Registerpool der ersten Ebene 507, welcher den architekturdefinierten Registern entspricht, zugegriffen 509. Entsprechend 6 wird in Reaktion auf das Ausführen 602 einer Letztverwendungs-Anweisung 601 zum Verwenden 509 eines als ein letztmals verwendetes architekturdefiniertes Register identifizierten architekturdefinierten Registers die Zuweisung des letztmals verwendeten architekturdefinierten Registers sowohl zum Pool der ersten Ebene 507 als auch zum Pool der zweiten Ebene 506 durch eine Registerzuordnungsfunktion 406 aufgehoben 603, wobei Einträge, deren Zuweisung aufgehoben wurde, für die Zuweisung zu architekturdefinierten Registern verfügbar sind.
  • Entsprechend 7 wird in einer Ausführungsform auf Grundlage der Feststellung 701, dass die Letztverwendungs-Anweisung 601 auszuführen ist, wobei die Letztverwendungs-Anweisung einen Registerfeld-Wert enthält, welcher das letztmals verwendete architekturdefinierte Register, dessen Zuweisung nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll, identifiziert, der Wert des letztmals verwendeten architekturdefinierten Registers aus dem Pool der ersten Ebene 507 in einen Eintrag der zweiten Ebene des Registerpools der zweiten Ebene 506 kopiert 706. Dann wird die Letztverwendungs-Anweisung ausgeführt 702. Das Aufheben der Zuweisung 703 des architekturdefinierten Registers aus dem ersten Pool 507 erfolgt nach Letztverwendung des Werts des architekturdefinierten Registers gemäß der Letztverwendungs-Anweisung. Dann wird die Zuweisung des architekturdefinierten Registers aus dem Registerpool der zweiten Ebene 506 auf Grundlage der in Ausführung befindlichen Letztverwendungs-Anweisung, die abgeschlossen werden soll, aufgehoben 704.
  • In Reaktion auf das Decodieren 705 der Letztverwendungs-Anweisung zur Ausführung wird in einer Ausführungsform bestimmt, dass die Zuweisung des letztmals verwendeten architekturdefinierten Registers nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll.
  • In einer Ausführungsform wird das Aufheben der Zuweisung des architekturdefinierten Registers 603 durch die Anweisungsabschlusslogik 708 des Prozessors bestimmt.
  • In einer Ausführungsform enthält die Mehrebenen-Registerhierarchie 505 architekturdefinierte Register, auf welche vor kurzem zugegriffen wurde, im Pool der ersten Ebene 507 und architekturdefinierte Register, auf welche selten zugegriffen wird, im Pool der zweiten Ebene 506.
  • In einer Ausführungsform beinhalten die architekturdefinierten Register Allgemeinregister oder Gleitkommaregister, wobei architekturdefinierte Anweisungen Opcode-Felder und Registerfelder aufweisen, wobei die Registerfelder so konfiguriert sind, dass sie ein Register aus den architekturdefinierten Registern identifizieren.
  • Entsprechend 8 ist in einer Ausführungsform eine weitere Anweisung eine Letztverwendungs-Identifizierungsanweisung, wobei die weitere Anweisung ausgeführt wird 801, wobei die Ausführung auf Grundlage der weiteren Anweisung das Identifizieren 804 eines architekturdefinierten Registers der Letztverwendungs-Anweisung als das letztmals verwendete architekturdefinierte Register anstelle des Identifizierens der Letztverwendungs-Anweisung 803 auf Grundlage der Letztverwendungs-Anweisung, welche die Letztverwendungs-Identifizierungsanweisung ist, beinhaltet.
  • Vorzugsweise wird eine Angabe darüber, welche architekturdefinierten Register aktiviert oder nicht aktiviert sind, für ein unterbrochen werdendes Programm (X) in einem Sicherungsbereich gesichert und wird eine Angabe darüber, welche architekturdefinierten Register aktiviert oder nicht aktiviert sind, für ein neues Programm (Y), das während eines Kontextwechsels abgerufen wird, aus dem Sicherungsbereich erlangt, wobei der Sicherungsbereich als eine Position architekturdefinierter Register oder eine für ein Betriebssystem (OS) verfügbare Hauptspeicherposition implementiert sein kann. Die Angabe kann ein bitsignifikantes Feld sein, wo jedes Bit einem Eintrag in einem architekturdefinierten Register entspricht, oder sie kann ein Bereich sein oder sie kann die aktivierten/aktiven architekturdefinierten Register anderweitig angeben. In einer Ausführungsform ist möglicherweise nur eine durch das OS bestimmte Teilmenge aktiviert. In einer Ausführungsform hat jeder Thread eines Multithread-Prozessors seinen eigenen Satz von ”Aktiviert”-, ”Inaktiviert”-Anzeigern. In einer weiteren Ausführungsform kann der Wert aktiver Anzeiger eines aktiven Programms oder Threads durch für das aktive Programm oder den Thread verfügbare Maschinenanweisungen explizit festgelegt werden.
  • In einer Ausführungsform bewirkt ein Zugriff auf ein inaktiviertes architekturdefiniertes Register, dass eine Programm-Ausnahmebedingung angezeigt wird.
  • In einer Ausführungsform wird ein inaktiviertes architekturdefiniertes Register durch Ausführung einer registeraktivierenden Anweisung aktiviert, die nicht in das inaktivierte architekturdefinierte Register schreibt.
  • Bei einer handelsüblichen Implementierung von Funktionen und Anweisungen wie einem Betriebssystem verwenden Programmierer die Assemblersprache. Diese in einem Speichermedium 114 (auch als Hauptspeicher bekannt) gespeicherten Anweisungsformate können in einem z/Architecture IBM Server, in einem PowerPC IBM Server oder alternativ in andere Architekturen ausführenden Maschinen nativ ausgeführt werden. Sie können in den bestehenden und in zukünftigen IBM-Servern und auf anderen Maschinen von IBM (z. B. pSeries®-Servern und xSeries®-Servern) emuliert werden. Sie können in Maschinen ausgeführt werden, wo die Ausführung gewöhnlich in einem Emulationsmodus erfolgt.
  • Im Emulationsmodus wird die emuliert werdende spezifische Anweisung decodiert und wird eine Subroutine erstellt, um die Einzelanweisung wie in einer C-Subroutine oder einem Treiber zu implementieren, oder wird irgendeine andere Technik zum Bereitstellen eines Treibers für die spezielle Hardware verwendet, wozu ein Fachmann nach Verstehen der Beschreibung einer Ausführungsform der Erfindung in der Lage ist.
  • Außerdem sind die verschiedenartigen oben beschriebenen Ausführungsformen lediglich Beispiele. Es kann viele Abwandlungen von diesen Ausführungsformen geben, ohne vom Geist der vorliegenden Erfindung abzuweichen. Obwohl hierin zum Beispiel eine logisch partitionierte Umgebung beschrieben sein kann, stellt dies nur ein einziges Beispiel dar. Aspekte der Erfindung sind für viele Arten von Umgebungen einschließlich weiterer Umgebungen, die eine Vielzahl von Zonen aufweisen, und nichtpartitionierter Umgebungen vorteilhaft. Ferner gibt es möglicherweise keine zentralen Prozessorkomplexe, aber trotzdem mehrere miteinander verbundene Prozessoren. Des Weiteren ist ein oder sind mehrere Aspekte der Erfindung auf Einzelprozessorumgebungen anwendbar.
  • Obwohl hierin bestimmte Umgebungen beschrieben sind, können wiederum viele Abwandlungen dieser Umgebungen implementiert werden, ohne vom Geist der vorliegenden Erfindung abzuweichen. Zum Beispiel können, wenn die Umgebung logisch partitioniert ist, mehr oder weniger logische Partitionen in der Umgebung enthalten sein. Ferner kann es mehrere miteinander verbundene zentrale Verarbeitungskomplexe geben. Dies sind lediglich einige der Abwandlungen, die machbar sind, ohne vom Geist der der vorliegenden Erfindung abzuweichen. Außerdem sind weitere Abwandlungen möglich. Zum Beispiel können in einer anderen Ausführungsform mehrere Anweisungen auf einmal ausgeführt werden, obwohl der hierin beschriebene Controller die Anweisung durchnummeriert, so dass eine einzige IDTE-Anweisung auf einmal ausgeführt wird. Ferner kann die Umgebung mehrere Controller enthalten. Überdies können mehrere Quiesce-Anforderungen (von einem oder mehreren Controllern) im System nebeneinander anhängig sein. Außerdem sind zusätzliche Abwandlungen möglich.
  • Wie hierin verwendet, beinhaltet der Begriff ”Verarbeitungseinheit” umlagerbare Entitäten wie Gäste; Prozessoren; Emulatoren; und/oder weitere ähnliche Komponenten. Überdies beinhaltet der Ausdruck ”durch eine Verarbeitungseinheit” auch ”im Namen einer Verarbeitungseinheit”. Der Begriff ”Puffer” beinhaltet einen Speicherbereich sowie verschiedene Arten von Datenstrukturen einschließlich, ohne darauf beschränkt zu sein, Arrays; und der Begriff ”Tabelle” kann andere als tabellenartige Datenstrukturen beinhalten. Ferner kann die Anweisung etwas anderes als Register enthalten, um Informationen zu bezeichnen. Überdies können eine Seite, ein Segment und/oder eine Region andere Größen als die hierin beschriebenen haben.
  • Eine oder mehrere der Fähigkeiten der vorliegenden Erfindung können in Software, Firmware, Hardware, oder irgendeiner Kombination davon implementiert sein. Ferner können eine oder mehrere der Fähigkeiten emuliert sein.
  • Ein oder mehrere Aspekte der vorliegenden Erfindung können in einem Herstellungsartikel (z. B. einem oder mehreren Computerprogramm-Produkten) enthalten sein, der zum Beispiel über durch Computer nutzbare Medien verfügt. Zu den Medien gehören zum Beispiel computerlesbare Programmcode-Mittel oder -Logik (z. B. Anweisungen, Code, Befehle usw.), um die Fähigkeiten der vorliegenden Erfindung bereitzustellen und zu unterstützen. Der Herstellungsartikel kann als ein Teil eines Computersystems enthalten sein oder separat verkauft werden. Die Medien (auch als materielles Speichermedium bekannt) können zum Beispiel auf einer Speichereinheit 120 als feste oder tragbare Medien, in Nur-Lese-Speicher (ROM – read-only memory) 116, in Direktzugriffsspeicher (RAM) 114 implementiert oder auf einem Computerchip einer CPU (110), einem E/A-Adapter 118 gespeichert sein.
  • Zusätzlich kann mindestens eine Programmspeichereinheit 120 bereitgestellt sein, die Speichermedien aufweist, welche durch eine Maschine lesbar sind, die mindestens ein Programm von durch die Maschine ausführbaren Anweisungen enthält, um die Fähigkeiten der vorliegenden Erfindung umzusetzen. Die hierin dargestellten Ablaufpläne sind lediglich Beispiele. Von diesen Ablaufplänen oder den hierin beschriebenen Schritten (oder Operationen) kann es viele Abwandlungen geben, ohne vom Geist der Erfindung abzuweichen. Zum Beispiel können die Schritte in einer anderen Reihenfolge ausgeführt werden oder können Schritte hinzugefügt, gelöscht oder verändert werden. Alle diese Abwandlungen werden als ein Bestandteil der beanspruchten Erfindung angesehen.
  • Obwohl bevorzugte Ausführungsformen hierin ausführlich dargestellt und beschrieben wurden, wird es dem Fachmann einleuchten, dass verschiedene Veränderungen, Hinzufügungen, Ersetzungen und dergleichen vorgenommen werden können, ohne vom Umfang der Erfindung wie in den folgenden Ansprüchen definiert abzuweichen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 7827388 [0028]
    • US 6314511 [0053]
    • US 6189088 [0095]

Claims (15)

  1. Computerimplementiertes Verfahren zum Verwalten einer Mehrebenen-Registerhierarchie, welche einen Registerpool einer ersten Ebene zum Cachespeicher-Zwischenspeichern von Registern eines Registerpools einer zweiten Ebene aufweist, wobei das Verfahren aufweist: Zuweisen architekturdefinierter Register zu verfügbaren Einträgen aus dem Pool der ersten Ebene oder aus dem Pool der zweiten Ebene durch einen Prozessor, wobei architekturdefinierte Register durch eine Anweisungssatz-Architektur (ISA) definiert und durch Registerfeld-Werte von Anweisungen der ISA adressierbar sind, wobei das Zuweisen das Verknüpfen jedes zugewiesenen architekturdefinierten Registers mit einem entsprechenden Eintrag eines Registerpools aufweist; Verschieben von Werten architekturdefinierter Register aus dem Pool der zweiten Ebene in den Pool der ersten Ebene gemäß einem Ersetzungsalgorithmus bezüglich des Pools der ersten Ebene; auf Grundlage von in Ausführung befindlichen Anweisungen Zugreifen auf Werte architekturdefinierter Register aus dem Registerpool der ersten Ebene, welcher den architekturdefinierten Registern entspricht; auf Grundlage des Ausführens einer Letztverwendungs-Anweisung zum Verwenden eines als ein letztmals verwendetes architekturdefiniertes Register identifizierten architekturdefinierten Registers Aufheben der Zuweisung des letztmals verwendeten architekturdefinierten Registers sowohl zum Pool der ersten Ebene als auch zum Pool der zweiten Ebene, wobei Einträge, deren Zuweisung aufgehoben wurde, für die Zuweisung zu architekturdefinierten Registern verfügbar sind.
  2. Verfahren nach Anspruch 1, außerdem aufweisend: auf Grundlage der Feststellung, dass die Letztverwendungs-Anweisung auszuführen ist, wobei die Letztverwendungs-Anweisung einen Registerfeld-Wert enthält, welcher das letztmals verwendete architekturdefinierte Register, dessen Zuweisung nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll, identifiziert, Kopieren des Werts des letztmals verwendeten architekturdefinierten Registers in ein physisches Register der zweiten Ebene aus dem Registerpool der zweiten Ebene; dann Ausführen der Letztverwendungs-Anweisung; und Durchführen des Aufhebens der Zuweisung des physischen Registers nach Letztverwendung des Werts des architekturdefinierten Registers gemäß der Letztverwendungs-Anweisung; und dann Aufheben der Zuweisung eines physischen Registers aus dem Registerpool der zweiten Ebene wie des architekturdefinierten Registers auf Grundlage der in Ausführung befindlichen Letztverwendungs-Anweisung, die abgeschlossen werden soll.
  3. Verfahren nach Anspruch 2, außerdem aufweisend: auf Grundlage des Decodierens der Letztverwendungs-Anweisung zur Ausführung Bestimmen, dass die Zuweisung des letztmals verwendeten architekturdefinierten Registers nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll.
  4. Verfahren nach Anspruch 2, wobei das Aufheben der Zuweisung des physischen Registers durch eine Anweisungsabschlusslogik des Prozessors bestimmt wird.
  5. Verfahren nach Anspruch 4, wobei die Mehrebenen-Registerhierarchie architekturdefinierte Register, auf welche vor kurzem zugegriffen wurde, im Pool der ersten Ebene und architekturdefinierte Register, auf welche selten zugegriffen wird, im Pool der zweiten Ebene enthält.
  6. Verfahren nach Anspruch 5, wobei die architekturdefinierten Register Allgemeinregister oder Gleitkommaregister beinhalten, wobei architekturdefinierte Anweisungen Opcode-Felder und Registerfelder aufweisen, wobei die Registerfelder so konfiguriert sind, dass sie ein Register aus den architekturdefinierten Registern identifizieren.
  7. Verfahren nach einem der Ansprüche 1 bis 6, außerdem aufweisend: Ausführen einer Letztverwendungs-Identifizierungsanweisung, wobei die Ausführung das Identifizieren eines architekturdefinierten Registers der Letztverwendungs-Anweisung als das letztmals verwendete architekturdefinierte Register aufweist.
  8. Computersystem zum Verwalten einer Mehrebenen-Registerhierarchie, wobei das System aufweist: einen Prozessor, der so konfiguriert ist, dass er einen Registerpool der ersten Ebene zum Cachespeicher-Zwischenspeichern (caching) von Registern eines Registerpools der zweiten Ebene bereitstellt, wobei der Prozessor so konfiguriert ist, dass er mit einem Hauptspeicher Daten austauscht, wobei der Prozessor eine Anweisungsabruffunktion und eine oder mehrere Ausführungseinheiten zum Ausführen von Anweisungen aufweist, wobei der Prozessor so konfiguriert ist, dass er ein Verfahren ausführt, welches aufweist: Zuweisen architekturdefinierter Register zu verfügbaren Einträgen aus dem Pool der ersten Ebene oder aus dem Pool der zweiten Ebene durch einen Prozessor, wobei architekturdefinierte Register durch eine Anweisungssatz-Architektur (ISA) definiert und durch Registerfeld-Werte von Anweisungen der ISA adressierbar sind, wobei das Zuweisen das Verknüpfen jedes zugewiesenen architekturdefinierten Registers mit einem entsprechenden Eintrag eines Registerpools aufweist; Verschieben von Werten architekturdefinierter Register aus dem Pool der zweiten Ebene in den Pool der ersten Ebene gemäß einem Ersetzungsalgorithmus bezüglich des Pools der ersten Ebene; auf Grundlage von in Ausführung befindlichen Anweisungen Zugreifen auf Werte architekturdefinierter Register aus dem Registerpool der ersten Ebene, welcher den architekturdefinierten Registern entspricht; auf Grundlage des Ausführens einer Letztverwendungs-Anweisung zum Verwenden eines als ein letztmals verwendetes architekturdefiniertes Register identifizierten architekturdefinierten Registers Aufheben der Zuweisung des letztmals verwendeten architekturdefinierten Registers sowohl zum Pool der ersten Ebene als auch zum Pool der zweiten Ebene, wobei Einträge, deren Zuweisung aufgehoben wurde, für die Zuweisung zu architekturdefinierten Registern verfügbar sind.
  9. Computersystem nach Anspruch 8, wobei der Prozessor außerdem so konfiguriert ist, dass er: auf Grundlage der Feststellung, dass die Letztverwendungs-Anweisung auszuführen ist, wobei die Letztverwendungs-Anweisung einen Registerfeld-Wert enthält, welcher das letztmals verwendete architekturdefinierte Register, dessen Zuweisung nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll, identifiziert, den Wert des letztmals verwendeten architekturdefinierten Registers in ein physisches Register der zweiten Ebene aus dem Registerpool der zweiten Ebene kopiert; dann die Letztverwendungs-Anweisung ausführt; und das Aufhebens der Zuweisung des physischen Registers nach Letztverwendung des Werts des architekturdefinierten Registers gemäß der Letztverwendungs-Anweisung durchführt; und dann die Zuweisung eines physischen Registers aus dem Registerpool der zweiten Ebene wie des architekturdefinierten Registers auf Grundlage der in Ausführung befindlichen Letztverwendungs-Anweisung, die abgeschlossen werden soll, aufhebt.
  10. Computersystem nach Anspruch 9, wobei der Prozessor außerdem so konfiguriert ist, dass er: auf Grundlage des Decodierens der Letztverwendungs-Anweisung zur Ausführung bestimmt, dass die Zuweisung des letztmals verwendeten architekturdefinierten Registers nach Ausführung der Letztverwendungs-Anweisung aufgehoben werden soll.
  11. Computersystem nach Anspruch 9, wobei das Aufheben der Zuweisung des physischen Registers durch eine Anweisungsabschlusslogik des Prozessors bestimmt wird.
  12. Computersystem nach Anspruch 11, wobei die Mehrebenen-Registerhierarchie so konfiguriert ist, dass sie architekturdefinierte Register, auf welche vor Kurzem zugegriffen wurde, im Pool der ersten Ebene und architekturdefinierte Register, auf welche selten zugegriffen wird, im Pool der zweiten Ebene bewahrt.
  13. Computersystem nach Anspruch 12, wobei die architekturdefinierten Register Allgemeinregister oder Gleitkommaregister beinhalten, wobei architekturdefinierte Anweisungen Opcode-Felder und Registerfelder aufweisen, wobei die Registerfelder so konfiguriert sind, dass sie ein Register aus den architekturdefinierten Registern identifizieren.
  14. Computersystem nach einem der Ansprüche 8 bis 13, wobei der Prozessor außerdem so konfiguriert ist, dass er: eine Letztverwendungs-Identifizierungsanweisung ausführt, wobei die Ausführung das Identifizieren eines architekturdefinierten Registers der Letztverwendungs-Anweisung als das letztmals verwendete architekturdefinierte Register aufweist.
  15. Computerprogramm-Produkt zum Verwalten einer Mehrebenen-Registerhierarchie, welches einen Registerpool einer ersten Ebene zum Cachespeicher-Zwischenspeichern von Registern eines Registerpools einer zweiten Ebene aufweist, wobei das Computerprogramm-Produkt ein durch eine Verarbeitungsschaltung lesbares materielles Speichermedium aufweist, das Anweisungen zur Ausführung durch die Verarbeitungsschaltung zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 7 speichert.
DE102012216567A 2011-10-03 2012-09-17 Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes Ceased DE102012216567A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/251,505 US20130086364A1 (en) 2011-10-03 2011-10-03 Managing a Register Cache Based on an Architected Computer Instruction Set Having Operand Last-User Information
US13/251,505 2011-10-03

Publications (1)

Publication Number Publication Date
DE102012216567A1 true DE102012216567A1 (de) 2013-04-04

Family

ID=46882023

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012216567A Ceased DE102012216567A1 (de) 2011-10-03 2012-09-17 Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes

Country Status (3)

Country Link
US (2) US20130086364A1 (de)
DE (1) DE102012216567A1 (de)
GB (1) GB2495361B (de)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9690583B2 (en) 2011-10-03 2017-06-27 International Business Machines Corporation Exploiting an architected list-use operand indication in a computer system operand resource pool
US8850557B2 (en) * 2012-02-29 2014-09-30 International Business Machines Corporation Processor and data processing method with non-hierarchical computer security enhancements for context states
US9286068B2 (en) 2012-10-31 2016-03-15 International Business Machines Corporation Efficient usage of a multi-level register file utilizing a register file bypass
US20140122842A1 (en) * 2012-10-31 2014-05-01 International Business Machines Corporation Efficient usage of a register file mapper mapping structure
US10275251B2 (en) * 2012-10-31 2019-04-30 International Business Machines Corporation Processor for avoiding reduced performance using instruction metadata to determine not to maintain a mapping of a logical register to a physical register in a first level register file
US9459869B2 (en) 2013-08-20 2016-10-04 Apple Inc. Intelligent caching for an operand cache
US9378146B2 (en) 2013-08-20 2016-06-28 Apple Inc. Operand cache design
US9652233B2 (en) * 2013-08-20 2017-05-16 Apple Inc. Hint values for use with an operand cache
GB2556740A (en) * 2013-11-29 2018-06-06 Imagination Tech Ltd Soft-partitioning of a register file cache
GB2520731B (en) * 2013-11-29 2017-02-08 Imagination Tech Ltd Soft-partitioning of a register file cache
US9329867B2 (en) 2014-01-08 2016-05-03 Qualcomm Incorporated Register allocation for vectors
US9817664B2 (en) 2015-02-19 2017-11-14 Apple Inc. Register caching techniques for thread switches
US9619394B2 (en) 2015-07-21 2017-04-11 Apple Inc. Operand cache flush, eviction, and clean techniques using hint information and dirty information
CN107851006B (zh) * 2015-08-18 2020-12-04 华为技术有限公司 多线程寄存器映射
US20170060593A1 (en) * 2015-09-02 2017-03-02 Qualcomm Incorporated Hierarchical register file system
US9785567B2 (en) 2015-09-11 2017-10-10 Apple Inc. Operand cache control techniques
CN106371805B (zh) * 2016-08-18 2018-07-17 中国科学院自动化研究所 处理器的动态调度互联寄存器及调度数据的方法
US10613987B2 (en) 2016-09-23 2020-04-07 Apple Inc. Operand cache coherence for SIMD processor supporting predication
CN107894935B (zh) * 2017-10-31 2023-05-05 深圳市鸿合创新信息技术有限责任公司 Ops电脑模块检测处理方法、装置以及电子设备
WO2020177229A1 (en) * 2019-03-01 2020-09-10 Huawei Technologies Co., Ltd. Inter-warp sharing of general purpose register data in gpu
US11086630B1 (en) 2020-02-27 2021-08-10 International Business Machines Corporation Finish exception handling of an instruction completion table
CN112486575A (zh) * 2020-12-07 2021-03-12 广西电网有限责任公司电力科学研究院 一种共享加速运算部件的电力人工智能芯片及应用方法
US20220413858A1 (en) * 2021-06-28 2022-12-29 Advanced Micro Devices, Inc. Processing device and method of using a register cache
CN116560729B (zh) * 2023-05-11 2024-06-04 北京市合芯数字科技有限公司 一种多线程处理器的寄存器多级管理方法及系统
CN116627501B (zh) * 2023-07-19 2023-11-10 北京开源芯片研究院 物理寄存器的管理方法、装置、电子设备及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6189088B1 (en) 1999-02-03 2001-02-13 International Business Machines Corporation Forwarding stored dara fetched for out-of-order load/read operation to over-taken operation read-accessing same memory location
US6314511B2 (en) 1997-04-03 2001-11-06 University Of Washington Mechanism for freeing registers on processors that perform dynamic out-of-order execution of instructions using renaming registers
US7827388B2 (en) 2003-04-25 2010-11-02 International Business Machines Corporation Apparatus for adjusting instruction thread priority in a multi-thread processor

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7210026B2 (en) * 2002-06-28 2007-04-24 Sun Microsystems, Inc. Virtual register set expanding processor internal storage
US6934830B2 (en) * 2002-09-26 2005-08-23 Sun Microsystems, Inc. Method and apparatus for reducing register file access times in pipelined processors
US7284092B2 (en) * 2004-06-24 2007-10-16 International Business Machines Corporation Digital data processing apparatus having multi-level register file
JP4520788B2 (ja) * 2004-07-29 2010-08-11 富士通株式会社 マルチスレッドプロセッサ
US20070083735A1 (en) * 2005-08-29 2007-04-12 Glew Andrew F Hierarchical processor
US8316352B2 (en) * 2006-06-09 2012-11-20 Oracle America, Inc. Watchpoints on transactional variables
US8055886B2 (en) * 2007-07-12 2011-11-08 Texas Instruments Incorporated Processor micro-architecture for compute, save or restore multiple registers and responsive to first instruction for repeated issue of second instruction
US8078843B2 (en) * 2008-01-31 2011-12-13 International Business Machines Corporation Facilitating processing in a computing environment using an extended drain instruction

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6314511B2 (en) 1997-04-03 2001-11-06 University Of Washington Mechanism for freeing registers on processors that perform dynamic out-of-order execution of instructions using renaming registers
US6189088B1 (en) 1999-02-03 2001-02-13 International Business Machines Corporation Forwarding stored dara fetched for out-of-order load/read operation to over-taken operation read-accessing same memory location
US7827388B2 (en) 2003-04-25 2010-11-02 International Business Machines Corporation Apparatus for adjusting instruction thread priority in a multi-thread processor

Also Published As

Publication number Publication date
GB2495361A (en) 2013-04-10
US20140047219A1 (en) 2014-02-13
GB2495361A8 (en) 2013-04-24
GB201213318D0 (en) 2012-09-05
US20130086364A1 (en) 2013-04-04
GB2495361B (en) 2013-12-25

Similar Documents

Publication Publication Date Title
DE102012216567A1 (de) Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes
DE102012216571A1 (de) Nutzung einer architekturdefinierten letztverwendungs-operandenangabe in einem computersystem-operandenressourcenpool
DE102012216565A1 (de) Decodierzeit-computeranweisungsoptimierung
US10061588B2 (en) Tracking operand liveness information in a computer system and performing function based on the liveness information
Shriraman et al. Flexible decoupled transactional memory support
DE102012217970A1 (de) Computeranweisungen zum Aktivieren und Deaktivieren von Operanden
DE112010003330B4 (de) Einrichten von Prüfpunkten bei Cachespeichern für die spekulative Versionierung
DE102012216592A1 (de) Präfix-Computeranweisung zur Erweiterung der Anweisungsfunktionalität
DE60029619T2 (de) Verfahren, vorrichtung, medium und programm zur aufnahme und zum verlassen von mehreren fäden in einem vielfadenprozessor
DE69612991T2 (de) System zur bearbeitung von selbstmodifizierendem kode
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE202007019502U1 (de) Globaler Überlauf für virtualisierten Transaktionsspeicher
DE112011100715T5 (de) Hardware-hilfs-thread
DE112009005006T5 (de) Optimierungen für ein ungebundenes transaktionales Speichersystem (UTM)
DE112011104596T5 (de) Systeme, Vorrichtungen und Verfahren für ein Hardware- und Softwaresystem zum automatischen Zerlegen eines Programms in mehrere parallele Threads
DE102007054057A1 (de) Mechanismus zum Detektieren und Vorhersagen eines kritischen Abschnitts zur Hardware-Lock-Elision
DE102014003799A1 (de) Systeme und Verfahren zur Übertragungseliminierung mit Bypass-Mehrfachinstanziierungstabelle
DE69429612T2 (de) Schreibpuffer für einen superskalaren Mikroprozessor mit Pipeline
DE102019119956A1 (de) Architektur und verfahren zur datenparallelen einzelprogramm- mehrfachdaten(spmd)-ausführung
DE69425311T2 (de) Mikroprozessor mit spekulativer Befehlsausführung
Abeydeera et al. SAM: Optimizing multithreaded cores for speculative parallelism
Duţu et al. Independent forward progress of work-groups
Park et al. Quantifying the performance and energy-efficiency impact of hardware transactional memory on scientific applications on large-scale NUMA systems
Ohmacht et al. IBM Blue Gene/Q memory subsystem with speculative execution and transactional memory
Marzulo et al. Talm: A hybrid execution model with distributed speculation support

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final