DE102012217970A1 - Computeranweisungen zum Aktivieren und Deaktivieren von Operanden - Google Patents

Computeranweisungen zum Aktivieren und Deaktivieren von Operanden Download PDF

Info

Publication number
DE102012217970A1
DE102012217970A1 DE201210217970 DE102012217970A DE102012217970A1 DE 102012217970 A1 DE102012217970 A1 DE 102012217970A1 DE 201210217970 DE201210217970 DE 201210217970 DE 102012217970 A DE102012217970 A DE 102012217970A DE 102012217970 A1 DE102012217970 A1 DE 102012217970A1
Authority
DE
Germany
Prior art keywords
instruction
operand
register
registers
processor
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.)
Withdrawn
Application number
DE201210217970
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 DE102012217970A1 publication Critical patent/DE102012217970A1/de
Withdrawn 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/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • 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/30003Arrangements for executing specific machine instructions
    • G06F9/30076Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • 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/30145Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016Decoding the operand specifier, e.g. specifier format
    • 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/30181Instruction operation extension or modification
    • G06F9/30185Instruction operation extension or modification according to one or more bits in the instruction, e.g. prefix, sub-opcode
    • 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/3836Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • 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
    • 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/3861Recovery, e.g. branch miss-prediction, exception handling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12Replacement control
    • G06F12/121Replacement control using replacement algorithms
    • G06F12/126Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning

Landscapes

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

Abstract

Eine Befehlssatzarchitektur (Instruction Set Architecture, ISA) enthält Anweisungen zur selektiven Angabe von letztmals verwendeten definierten Operanden mit Werten, auf die nicht wieder zugegriffen wird, wobei die definierten Operanden nach einer Anweisung, die von einer Anweisung als letztmals verwendet angegeben wird, aktiviert oder deaktiviert werden, wobei die definierten Operanden aktiviert werden, indem eine Schreiboperation in einen inaktiven Operanden durchgeführt wird, wobei die Aktivierung/Deaktivierung mit einer Anweisung ausgeführt werden kann, die die letzte Verwendung des Operanden oder eine andere (Präfix-)Anweisung aufweist.

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf das Gebiet von Prozessoren, und im Besonderen auf die Prozessorausführung von Anweisungen bzw. Befehlen (Instructions), die die letztmalige Verwendung eines Operanden angeben.
  • Hintergrund
  • Laut Wikipedia weisen, nach einer Veröffentlichung vom 1.8.2011 im World Wide Web, „Multithreading Computer” eine Hardwareunterstützung auf, die die effiziente Ausführung mehrerer Threads (bzw. Ausführungsstränge) unterstützt. Diese unterscheiden sich von Multiprozessorsystemen (wie Systeme mit mehreren Cores bzw. Kernen) dadurch, dass die Threads die Ressourcen in einem Core gemeinsam nutzen müssen: die Computingeinheiten bzw. Recheneinheiten, die CPU-Caches und den Übersetzungspuffer (Translation Look-aside Buffer, TLB). Während Multiprozessorsysteme mehrere vollständige Verarbeitungseinheiten (Processing Units) enthalten, ist Multithreading auf die erhöhte Nutzung eines Cores ausgerichtet, indem ein Parallelismus bzw. parallele Verarbeitung sowohl auf Threadebene wie auch auf Anweisungsebene zum Einsatz kommt. Da die beiden Techniken komplementär sind, werden sie manchmal in Systemen mit mehreren Multithread-fähigen CPUs und in CPUs mit mehreren Multithread-fähigen Cores kombiniert.
  • Das Multithreading-Paradigma wurde seit dem Ende der 1900er Jahre aufgrund der Anstrengungen, die parallele Verarbeitung auf Anweisungsebene stärker zu nutzen, immer populärer. Dadurch konnte das Konzept des durchsatzorientierten Computings (Throughput Computing) aus dem spezielleren Feld der Transaktionsverarbeitung wieder mehr Geltung erlangen: Selbst wenn es sehr schwierig ist, ein einzelnen Thread oder ein einzelnes Programm weiter zu beschleunigen, setzen die meisten Computersysteme de facto Multitasking zwischen mehreren Threads oder Programmen ein.
  • Techniken, mit denen der Gesamtsystemdurchsatz aller Tasks bzw. Aufgaben beschleunigt werden kann, bedeuten eine erhebliche Leistungssteigerung.
  • Die beiden Haupttechniken des durchsatzorientierten Computings sind Multiprocessing und Multithreading.
  • Zu den Vorteilen gehören:
    Wenn bei einem Thread viele Cachefehler auftreten, können die anderen Thread(s) weiterarbeiten, wodurch ungenutzte Computing-Ressourcen genutzt werden, was zu einer schnelleren Gesamtausführung führen kann, da diese Ressourcen bei der Ausführung von nur einem Thread im Leerlaufzustand wären.
  • Wenn ein Thread nicht alle Computing-Ressourcen der CPU verwenden kann (da Anweisungen von dem gegenseitigen Ergebnis abhängen), ermöglicht das Ausführen eines weiteren Threads, dass sie nicht im Leerlaufzustand bleiben.
  • Wenn mehrere Threads das gleiche Datenset bearbeiten, können sie ihren Cache tatsächlich gemeinsam verwenden, was zu einer besseren Cachenutzung oder Synchronisierung der Werte führt.
  • Zu den Kritikpunkten des Multithreadings gehören:
    Mehrere Threads können bei der gemeinsamen Nutzung von Hardwareressourcen wie Cache oder Übersetzungspuffer (TLBs) miteinander in Konflikt kommen.
  • Die Ausführungszeiten eines einzelnen Threads werden nicht verbessert, sondern können sich verschlechtern, selbst wenn nur ein Thread ausgeführt wird. Das ist auf geringere Frequenzen und/oder zusätzliche Pipeline-Stufen zurückzuführen, die erforderlich sind, um die Thread-Wechsel-Hardware zu berücksichtigen.
  • Der Hardwaresupport von Multithreading ist für die Software sichtbar, wodurch mehr Änderungen an den Anwendungsprogrammen und Betriebssystemen als beim Multiprocessing erforderlich sind.
  • Es gibt verschiedene Arten von Multithreading:
  • Block-Multithreading
  • Der einfachste Multithreading-Typ tritt auf, wenn ein Thread ausgeführt wird, bis er durch ein Ereignis blockiert wird, was normalerweise zu einer langen Latenz-Stillstandzeit führen würde. Solche ein Stillstand kann auf einen Cachefehler zurückzuführen sein, der auf Speicher außerhalb des Chips zurückgreifen muss, wodurch es Hunderte von CPU-Zyklen dauern kann, bis die Daten wieder zurückgegeben werden. Anstatt auf die Auflösung des Stillstandzustands zu warten, wechselt ein Prozessor mit Threadausführung die Ausführung auf einen anderen ausführungsbereiten Thread. Erst wenn die Daten für den vorherigen Thread angekommen sind, wird der vorherige Thread wieder zurück auf die Liste der ausführungsbereiten Threads gesetzt. Zum Beispiel:
    • Zyklus i: Anweisung j wird von Thread A abgesetzt
    • 2. Zyklus i + 1: Anweisung j + 1 wird von Thread A abgesetzt
    • 3. Zyklus i + 2: Anweisung j + 2 wird von Thread A abgesetzt, die Ladeanweisung, die in allen Caches zu einem Fehler führt
    • 4. Zyklus i + 3: Der Thread-Scheduler wird aufgerufen, Wechsel zu Thread B
    • 5. Zyklus i + 4: Anweisung k wird von Thread B abgesetzt
    • 6. Zyklus i + 5: Anweisung k + 1 wird von Thread B abgesetzt
  • Dies entspricht vom Konzept her einem kooperierenden Multitasking, das in Echtzeitbetriebssystemen zum Einsatz kommt, in denen die Tasks freiwillig Ausführungszeit aufgeben, wenn sie auf eine bestimmte Art von Ereignis warten müssen.
  • Dieser Multithreading-Typ wird als Block-, kooperatives oder grobes Multithreading bezeichnet.
  • Hardwarekosten
  • Das Ziel der Multithreading-Hardwareunterstützung besteht darin, einen schnellen Wechsel zwischen einem blockierten Thread und einem anderen ausführungsbereiten Thread zu ermöglichen. Für die Verwirklichung dieses Ziels bestehen die Hardwarekosten darin, die für das Programm sichtbaren Register sowie einige andere Prozessorsteuerregister (wie Programmzähler) zu replizieren. Der Wechsel von einem Thread auf einen anderen Thread bedeutet, dass die Hardware von der Verwendung eines Registersatzes auf einen anderen wechselt.
  • Diese weitere Hardware bietet folgende Vorteile:
    Der Thread-Wechsel erfolgt in einem CPU-Zyklus.
  • Jeder Thread nimmt sich so wahr, dass er als einziger ausgeführt wird und keine Ressourcen mit anderen Threads gemeinsam verwendet. Dies minimiert den Umfang der in der Anwendung erforderlichen Softwareänderungen sowie die Unterstützung von Multithreading durch das Betriebssystem. Um die aktiven Threads effizient zu wechseln, benötigt jeder aktive Thread einen eigenen Registersatz. Um beispielsweise schnell zwischen zwei Threads zu wechseln, muss die Registerhardware zweimal instanziiert werden.
  • Beispiele
  • Viele Familien von Mikrocontrollern und eingebetteten Prozessoren verfügen über mehrere Registerbänke, um schnelle Kontextwechsel für Interrupts zu ermöglichen. Diese Schemas können als Block-Multithreading-Typ unter dem Benutzerprogramm-Thread und den Interrupt-Threads betrachtet werden.
  • Interleaved Multithreading
    • 1. Zyklus i + 1: Eine Anweisung wird von Thread B abgesetzt
    • 2. Zyklus i + 2: Eine Anweisung wird von Thread C abgesetzt
  • Der Zweck dieses Multithreading-Typs besteht darin, alle durch Datenabhängigkeiten bedingte Stillstandzustände in der Ausführungs-Pipeline zu entfernen. Da ein Thread relativ unabhängig von den anderen Threads ist, ist die Möglichkeit geringer, dass eine Anweisung in einer Pipe-Stufe eine Ausgabe aus einer älteren Anweisung in der Pipeline benötigt.
  • Konzeptionell entspricht dies dem in Betriebssystemen verwendeten präemptiven Multitasking. Dies lässt sich als Analogie so beschreiben, dass der jedem aktiven Thread bereitgestellte Zeit-Slot einem CPU-Zyklus entspricht.
  • Dieser Multithreading-Typ wurde zuerst als Barrel-Verarbeitung bezeichnet, in der die Stäbe eines Fasses (Barrel) die Pipeline-Stufen und ihre auszuführenden Threads darstellen. Interleaved bzw. präemptives oder feines Multithreading oder Multithreading mit Zeit-Slots sind zeitgemäßere Bezeichnungen.
  • Hardwarekosten
  • Zusätzlich zu den beim Biock-Multithreading-Typ erörterten Hardwarekosten weist das Interleaved Multithreading die zusätzlichen Kosten auf, dass jede Pipeline-Stufe die Thread ID der Anweisung, die sie verarbeitet, verfolgt. Ebenso, da in der Pipeline mehr Threads gleichzeitig ausgeführt werden, müssen die gemeinsamen Ressourcen wie Caches und TLBs größer sein, um Konflikte zwischen den verschiedenen Threads zu vermeiden.
  • Simultanes Multithreading
  • Der modernste Multithreading-Typ kommt bei superskalaren Prozessoren zum Einsatz. Ein normaler superskalarer Prozessor setzt mehrere Anweisungen aus einem einzelnen Thread pro CPU-Zyklus ab. Beim simultanen Multithreading (Simultaneous Multi-threading, SMT) kann der superskalare Prozessor Anweisungen von mehreren Threads pro CPU-Zyklus absetzen. Da ein einzelner Thread nur begrenzt Parallelismus auf Anweisungsebene aufweist, versucht diese Art von Multithreading den über mehrere Threads verfügbaren Parallelismus zu nutzen, um die Verschwendung nicht belegter Slots zu senken.
  • Zum Beispiel:
    • Zyklus i: Anweisungen j und j + 1 aus Thread A; Anweisung k aus Thread B werden alle gleichzeitig abgesetzt.
    • 2. Zyklus i + 1: Anweisung j + 2 aus Thread A; Anweisung k + 1 aus Thread B; Anweisung m aus Thread C werden alle gleichzeitig abgesetzt.
    • 3. Zyklus i + 2: Anweisung j + 3 aus Thread A; Anweisungen m + 1 und m + 2 aus Thread C werden alle gleichzeitig abgesetzt.
  • Um andere Multithreading-Typen von SMT zu unterscheiden, wird der Begriff temporäres Multithreading (Temporal Multithreading) verwendet, um anzugeben, wenn von nur einem Thread Anweisungen zu einem Zeitpunkt abgesetzt werden können.
  • Hardwarekosten
  • Zusätzlich zu den für das Interleaved Multithreading erörterten Hardwarekosten weist SMT weitere Kosten in jeder Pipeline-Stufe für das Verfolgen der Thread-ID jeder verarbeiteten Anweisung auf. Auch hier müssen gemeinsame Ressourcen wie Caches und TLBs für die hohe Zahl aktiver Threads in der Größe angepasst werden.
  • Gemäß dem am 2.11.2010 an IBM erteilten US-Patent-Nr. 7.827.388 „Apparatus for adjusting instruction thread priority in a multi-thread prozessor”, das hierin als Referenz miteingebunden ist, werden verschiedene Techniken verwendet, um die Geschwindigkeit, mit der Datenprozessoren Softwareprogramme ausführen, zu verbessern. Zu diesen Techniken gehören die Erhöhung der Prozessortaktgeschwindigkeit, die Verwendung von Cachespeicher und die Verwendung prädiktiver Verzweigungen. Durch die Erhöhung der Prozessortaktrate kann ein Prozessor in einem bestimmten Zeitraum diesbezüglich mehr Operationen durchführen. Der Cachespeicher ist in direkter Nähe des Prozessors angeordnet und arbeitet mit höheren Geschwindigkeiten als der Hauptspeicher, wodurch der Prozessor weniger Zeit für den Zugriff auf Daten und Anweisungen benötigt. Durch die prädiktive Verzweigung kann ein Prozessor bestimmte Anweisungen basierend auf einer Prognose der Ergebnisse einer früheren Anweisung ausführen, wodurch nicht mehr auf die tatsächlichen Ergebnisse gewartet werden muss, was die Verarbeitungsgeschwindigkeit erhöht.
  • Einige Prozessoren nutzen auch die Ausführung von Anweisungen über die Pipeline, um die Systemleistung zu optimieren. Bei der Ausführung von Anweisungen über die Pipeline werden die Verarbeitungstasks in mehrere Pipeline-Schritte oder -stufen aufgeteilt. Pipelining kann die Verarbeitungsgeschwindigkeit erhöhen, indem es allen nachfolgenden Anweisungen ermöglicht, mit der Verarbeitung zu beginnen, bevor die zuvor abgesetzten Anweisungen einen bestimmten Prozess beendet haben. Der Prozessor muss nicht darauf warten, dass eine Anweisung vollständig verarbeitet wird, bevor mit der Verarbeitung der nächsten Anweisung in der Sequenz begonnen wird.
  • Prozessoren, die eine Verarbeitung über eine Pipeline einsetzen, können mehrere unterschiedliche Pipeline-Stufen aufweisen, die verschiedenen Aktivitäten im Prozessor zugeordnet sind. Zum Beispiel kann ein Prozessor sequenzielle Anweisungen in einer Abrufstufe, einer Dekodier-/Verteilungsstufe (Decode/Dispatch), einer Stufe, in der Befehle abgesetzt werden, einer Ausführungsstufe, eine Beendigungsstufe und einer Abschlussstufe verarbeiten. In jeder dieser Stufen kann eine eigene Gruppe von Pipeline-Stufen zur Durchführung der gewünschten Verarbeitungstasks zum Einsatz kommen.
  • Die Multithread-Anweisungsverarbeitung ist eine weitere Technik, die zusammen mit Pipelining verwendet werden kann, um die Verarbeitungsgeschwindigkeit zu erhöhen. Bei der Multithread-Anweisungsverarbeitung wird ein Satz an Programmanweisungen in zwei oder mehrere getrennte Gruppen oder Threads von Anweisungen unterteilt. Mit diesem Multithreading-Verfahren lassen sich Anweisungen von einem Thread über eine Pipeline verarbeiten, während ein anderer Thread aus irgendeinem Grund nicht verarbeitet werden kann. Dadurch wird die Situation vermieden, die bei der Verarbeitung einzelner Thread-Anweisungen auftritt, bei der alle Anweisungen angehalten werden, während eine bestimmte Anweisung nicht ausgeführt werden kann, wie beispielsweise in einer Cachefehler-Situation, in der die zur Ausführung einer bestimmten Anweisung erforderlichen Daten nicht sofort verfügbar sind. Datenprozessoren, die mehrere Anweisungs-Threads verarbeiten können, werden oftmals als simultane Multithreading(SMT)-Prozessoren bezeichnet.
  • An diesem Punkt ist zu beachten, dass ein Unterschied darin besteht, wie die Software-Community den Begriff „Multithreading” verwendet, und der Art und Weise, wie der Begriff „Multithreading” in der Computerarchitektur-Community verwendet wird. Die Software-Community bezieht sich mit dem Begriff „Multithreading” auf eine Task, die in mehrere zueinander in Beziehung stehende Threads unterteilt ist. In der Computerarchitektur wird der Begriff „Multithreading” für Threads verwendet, die voneinander unabhängig sein können. Der Begriff „Multithreading” wird in dem vorliegenden Dokument im gleichen Sinn wie in der Computerarchitektur-Community verwendet.
  • Um das Multithreading zu vereinfachen, werden die Anweisungen von den verschiedenen Threads auf bestimmte Weise an einem Punkt in der Gesamtprozessor-Pipeline verschränkt bzw. verschränkt (Englisch: interleaved). Es gibt im Allgemeinen zwei verschiedenen Verfahren zum Verschränken von Anweisungen zur Verarbeitung in einem SMT-Prozessor. Eine Technik beinhaltet das Interleaving (bzw. Verschränken oder Verschachteln) von Threads basierend auf einem langen Latenzereignis, wie einem Cachefehler, der eine Verzögerung in der Verarbeitung eines Threads erzeugt. In dieser Technik sind alle Prozessorressourcen für einen einzelnen Thread reserviert, bis die Verarbeitung dieses Threads durch ein langes Latenzereignis verzögert wird. Bei Eintritt des langen Latenzereignisses wechselt der Prozessor schnell zu einem anderen Thread und verarbeitet diesen Thread, bis für diesen Thread ein langes Latenzereignis auftritt, oder bis der Sachverhalt, der den anderen Thread blockiert hat, gelöst wird.
  • Die andere allgemeine Technik zum Verschränken von Anweisungen aus mehreren Anweisungs-Threads in einem SMT-Prozessor beinhaltet das Verschränken von Anweisungen auf einer Zyklus-zu-Zyklus-Basis gemäß einer bestimmten Verschränkungsregel (manchmal auch als Interleave-Regel bezeichnet). Bei einer einfachen Zyklus-zu-Zyklus-Interleaving-Technik werden einfach Anweisungen aus verschiedenen Threads 1:1 verschränkt. Zum Beispiel kann sich ein SMT-Prozessor mit zwei Threads 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 und so weiter holen, wobei zwischen den beiden Anweisungs-Threads vor- und zurückgesprungen wird. Bei einer komplexeren Zyklus-zu-Zyklus-Interleaving-Technik können Softwareanweisungen verwendet werden, um jedem Anweisungs-Thread eine Priorität zuzuordnen und dann die Anweisungen aus den verschiedenen Threads zu verschränken, um gewisse Regeln basierend auf den relativen Thread-Prioritäten durchzusetzen. Wenn beispielsweise einem Thread in einem SMT-Prozessor mit zwei Threads einer höheren Priorität zugewiesen wird als einem anderen Thread, kann eine einfache Interleaving-Regel erfordern, dass doppelt so viele Anweisungen von dem Thread mit höherer Priorität in den Interleave-Strom im Vergleich zu Anweisungen des Threads mit niedriger Priorität aufgenommen werden sollen.
  • Eine komplexere aktuell verwendete Zyklus-zu-Zyklus-Interleaving-Regel weist jedem Thread eine Priorität von „1” bis „7” zu und setzt eine Anweisung aus einem Thread mit einer niedrigeren Priorität in den Strom der verschränkten Anweisungen basierend auf der Funktion 1/(2|X – Y| + 1), wobei X = die von der Software zugewiesene Priorität eines ersten Threads und Y = die von der Software zugewiesene Priorität eines zweiten Threads ist. In dem Fall, in dem die beiden Threads die gleiche Priorität aufweisen, 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 in den Strom der verschränkten Anweisungen einmal pro jeweils zwei Taktzyklen aufgenommen. Wenn sich die Thread-Prioritäten 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 mit niedriger Priorität wird in den Stream der verschränkten Anweisungen einmal pro jeweils acht Taktzyklen aufgenommen.
  • Im Allgemeinen ist die Verwendung einer Prioritätsregel angedacht, um zu wählen, wie oft Anweisungen aus bestimmten Threads aufgenommen werden. Damit soll sichergestellt werden, dass die Prozessorressourcen basierend auf der von der Software jedem Thread zugewiesenen Priorität zugeordnet werden. Es gibt jedoch Situationen, in denen es nicht ausreichend ist, sich nur auf die von der Software zugewiesenen Threadprioritäten zu verlassen, die nicht zu einer optimalen Zuordnung der Prozessorressourcen führen können. Im Besonderen können von der Software zugewiesene Threadprioritäten keine Prozessorereignisse wie beispielsweise Cachefehler berücksichtigen, die sich auf die Fähigkeit eines bestimmten Anweisungs-Threads auswirken können, eine bestimmte Prozessor-Pipeline zu durchlaufen. Somit kann das Auftreten eines Ereignisses im Prozessor vollständig oder wenigstens teilweise das Ziel außer Kraft setzen, Prozessorressourcen effizient zwischen verschiedenen Anweisungs-Threads in einem Multithread-Prozessor zuzuweisen.
  • Zum Beispiel kann eine Priorität von 5 von der Software einem ersten Anweisungs-Thread in einem System mit zwei Threads zugeordnet werden, während eine Priorität von 2 dem zweiten Anweisungs-Thread von der Software zugewiesen werden kann. Mit der oben beschriebenen Prioritätsregel 1/(2|X – Y| + 1) würden diese von der Software zugewiesenen Prioritäten vorschreiben, dass eine Anweisung von einem Thread mit einer niedrigeren Priorität in den verschränkten Anweisungsstrom nur einmal pro 16 Taktzyklen verschränkt werden würde, während Anweisungen aus dem Anweisungs-Thread mit der höheren Priorität in 15 pro jeweils 16 Taktzyklen verschränkt werden würden. Wenn bei einer Anweisung von dem Anweisungs-Thread mit der höheren Priorität ein Cachefehler auftritt, schreibt die Prioritätsregel immer noch vor, dass 15 der jeweils 16 Taktzyklen Anweisungen von dem Anweisungs-Thread mit höherer Priorität aufweisen, selbst wenn das Auftreten des Cachefehlers effektiv die Ausführung des betreffenden Anweisungs-Threads blockiert, bis die Daten für die Anweisung verfügbar sind.
  • In einer Ausführungsform wird jedem Anweisungs-Thread in einem SMT-Prozessor eine von der Software zugewiesene Basiseingabe-Verarbeitungspriorität zugeordnet. Sofern nicht ein vordefiniertes Ereignis oder Sachverhalt auftritt, bei dem eine Anweisung verarbeitet wird bzw. verarbeitet werden soll, werden die Basiseingabe-Verarbeitungsprioritäten der betreffenden Threads verwendet, um die Verschränkungsfrequenz zwischen den Threads nach gewissen Anweisungsverschränkungsregeln bestimmen. Tritt aber ein bestimmtes Ereignis oder Sachverhalt in dem Prozessor ein, das bzw. der mit dem betreffenden Anweisungs-Thread in Beziehung steht, wird die Basiseingabe-Verarbeitungspriorität einer oder mehrerer Anweisungs-Threads angepasst, um eine oder mehrere angepasste Prioritätswerte zu erzeugen. Die Anweisungsverschränkungsregel wird dann gemäß dem angepassten Prioritätswert bzw. Prioritätswerten zusammen mit beliebigen Basiseingabe-Verarbeitungsprioritätswerten durchgesetzt, die noch nicht angepasst wurden.
  • Das 2003 im „Intel® Hyper-Threading Technology, Technical User's Guide" 2003 beschriebene Intel® Hyper-Threading von Intel® ist hier durch Bezugnahme eingebunden. Gemäß dem Technical User's Guide sind die Anstrengungen, die Systemleistung auf einem Prozessor zu steigern, herkömmlicherweise darauf ausgerichtet, den Prozessor leistungsfähiger zu machen. Diese Ansätze des Prozessordesigns sind darauf ausgerichtet, dem Prozessor zu ermöglichen, mehr Anweisungen schneller durch höhere Taktraten, Parallelismus auf Anweisungsebene (Instruction-level Parallelism, ILP) und Caches zu verarbeiten. Zu den Techniken zur Verwirklichung höherer Taktraten gehört das Pipelining der Mikroarchitektur in feinere Auflösungen, was auch als Super-Pipelining bezeichnet wird. Höhere Taktraten können die Leistung stark erhöhen, indem die Anzahl der Anweisungen erhöht wird, die pro Sekunde ausgeführt werden können. Da aber in einer Mikroarchitektur mit Super-Pipelining weit mehr Anweisungen ausgeführt werden, ist die Verarbeitung von Ereignissen, die die Pipeline unterbrechen, wie Cachefehler, Interrupts und falsche Verzweigungsprognosen, sehr viel kritischer und Fehler sind kostenaufwändiger. ILP bezieht sich auf Techniken, um die Anzahl der Anweisungen zu erhöhen, die in jedem Taktzyklus ausgeführt werden. Zum Beispiel weisen superskalare Prozessorimplementierungen mehrere Ausführungseinheiten auf, die Anweisungen gleichzeitig verarbeiten können. In diesen superskalaren Implementierungen können jeden Taktzyklus mehrere Anweisungen ausgeführt werden. Bei einer einfachen Ausführung gemäß der Reihenfolge reicht es nicht aus, einfach mehrere Ausführungseinheiten zu haben. Die Herausforderung besteht darin, ausreichend Anweisungen zur Ausführung zu finden. Eine Technik ist die Ausführung außerhalb der Reihenfolge (bzw. Out-of-Order), bei der ein großes Fenster an Anweisungen basierend auf den Abhängigkeiten zwischen den Anweisungen anstelle auf der Basis der Programmreihenfolge gleichzeitig ausgewertet und an Ausführungseinheiten gesendet wird. Zugriffe auf den Systemspeicher sind langsam, aber immer noch schneller als Festplattenzugriffe. Im Vergleich zu den Ausführungsgeschwindigkeiten des Prozessors sind sie aber um Größenordnungen langsamer. Eine Technik, um die beim Zugriff auf den Systemspeicher eingeführten Verzögerungen (als Latenz bezeichnet) zu verringern, besteht darin, schnelle Caches nahe dem Prozessor hinzuzufügen. Caches bieten den schnellen Zugriff auf Speicher für Daten oder Anweisungen, auf die häufig zugegriffen wird. Mit Erhöhung der Cachegeschwindigkeit steigt aber das Problem der Wärmeabgabe und der Kosten. Aus diesem Grund sind die Prozessoren oftmals mit einer Cachehierarchie konzipiert, in der schnelle kleine Caches nahe dem Prozessorkern angeordnet sind und mit Zugriffslatenzen nahe diesem betrieben werden. Zunehmend größere Caches, die Daten oder Anweisungen verarbeiten, auf die weniger häufig zugegriffen wird, werden mit längeren Zugriffslatenzen implementiert. Dennoch kann es vorkommen, dass sich benötigte Daten nicht im Prozessorcache befinden. Die Verarbeitung dieser Cachefehler erfordert den Zugriff auf den Systemspeicher oder die Festplatte und die in diesen Zeiten besteht die Wahrscheinlichkeit, dass der Prozessor einen Stillstand erleidet, während er darauf wartet, dass die Transaktionen im Speicher beendet werden. Die meisten Techniken zur Verbesserung der Prozessorleistung von einer Generation zur nächsten sind komplex und erhöhen oftmals die Die-Größe und Stromkosten erheblich. Aufgrund des begrenzten Parallelismus in den Anweisungsflüssen arbeitet keine dieser Techniken 100-prozentig effizient. In der Folge führt die Verdopplung der Anzahl der Ausführungseinheiten in einem Prozessor nicht zur Verdoppelung der Prozessorleistung. Ebenso führt aufgrund der Anzahl der Prozessorzyklen, die in einem langsameren Speichersubsystem verloren gehen, eine einfache Verdoppelung der Taktrate nicht zu einer Verdoppelung der Leistung.
  • Multithreading
  • Mit der Steigerung des Leistungsvermögens von Prozessoren sind auch die Anforderungen an die Leistung gestiegen, die den Druck auf die Prozessorressourcen mit maximaler Effizienz erhöht haben. Aufgrund der Tatsache, dass Prozessoren Zeit für eine einzelne Task verschwendeten, während sie auf den Abschluss bestimmter Ereignisse warteten, sind die Softwareentwickler der Frage nach gegangen, ob der Prozessor gleichzeitig nicht andere Aufgaben übernehmen kann.
  • Aus diesem Grund begannen Softwarearchitekten Betriebssysteme zu erstellen, die die Ausführung von Programmteilen unterstützten, die als Threads bezeichnet wurden. Die Threads sind kleine Tasks, die unabhängig ausgeführt werden können. Jeder Thread erhält einen eigenen Zeit-Slot, sodass jeder Thread eine Grundeinheit der Prozessornutzung darstellt. Threads sind in Prozesse gegliedert, die sich aus einem oder mehreren Threads zusammensetzen. Alle Threads in einen Prozess nutzen den gemeinsamen Zugriff auf die Prozessressourcen.
  • Diese Multithreading-Betriebssysteme ermöglichen die Ausführung eines Threads, während ein anderer darauf wartet, dass etwas geschieht. Auf Personal Computern und Servern auf der Basis von Intel-Prozessoren unterstützen heute alle Betriebssysteme, wie Microsoft Windows* 2000 und Windows* XP, Multithreading. De facto verwenden die Betriebssysteme selbst Multithreading. Teile davon können ausgeführt werden, während andere Teile im Stillstand sind.
  • Um von Multithreading profitieren zu können, müssen Programme ausführbare Bereiche besitzen, die parallel ausgeführt werden können. Das heißt, anstatt als eine einzelne lange Folge von Anweisungen entwickelt zu werden, werden Programme in logisch arbeitende Bereiche aufgeteilt. Wenn die Anwendung auf diese Weise Operationen ausführt, die unabhängig voneinander durchgeführt werden, können diese Operationen in Threads aufgeteilt werden, deren Ausführung vom Betriebssystem geplant und gesteuert wird. Diese Bereiche können für die Durchführung verschiedener Dinge erstellt werden. So kann beispielsweise Microsoft Word* ermöglicht werden, ein Dokument während der Benutzereingaben neu mit Seitenzahlen zu versehen. Die Neunummerierung der Seiten tritt in einem Thread auf und die Verarbeitung der Tastatureingaben in einem anderen. Auf Einprozessorsystemen werden diese Threads sequenziell und nicht gleichzeitig ausgeführt. Der Prozessor wechselt zwischen dem Tastatureingabethread und dem Neunummerierungsthread ausreichend schnell hin und her, dass beide Prozesse gleichzeitig zu erfolgen scheinen. Dies wird als funktional zerlegtes Multithreading bezeichnet.
  • Programme mit Multithreading können auch erstellt werden, um dieselbe Task in parallelen Threads auszuführen. Dies wird als Datenzerlegungs-Multithreading (Data-decomposed Multithreaded) bezeichnet, in dem sich die Threads nur in den zu verarbeitenden Daten unterscheiden. Beispielsweise kann eine Szene in einer Grafikanwendung gezeichnet werden, sodass jeder Thread eine halbe Szene übernimmt. In der Regel werden bei Anwendungen mit Datenzerlegung Threads für die Durchsatzleistung erstellt, während bei funktional zerlegten Anwendungen Threads im Hinblick auf die Reaktionsfähigkeit der Benutzer oder auf andere Funktionalitätsaspekte erstellt werden.
  • Wenn Programme mit Multithreading auf einem Einprozessorsystem ausgeführt werden, tritt etwas Overhead auf, wenn der Kontext zwischen den Threads gewechselt wird. Da der Wechsel zwischen Threads Zeit kostet, scheint es, dass das Ausführen der beiden Threads auf diese Weise weniger effizient ist als das Ausführen der beiden Threads nacheinander. Wenn jeder Thread auf einem Systemgerät auf den Benutzer warten muss, gleicht die Fähigkeit, dass der andere Thread weiterhin arbeitet, jedoch sehr schnell den gesamten Overhead des Wechsels aus. Da ein Thread im Beispiel der Grafikanwendung die Benutzereingabe verarbeitet, treten sicherlich häufige Zeitspannen auf, in denen er nur wartet. Durch den Wechsel zwischen den Threads können Betriebssysteme, die Programme mit Multithreading unterstützen, die Leistung und die Reaktionsfähigkeit der Benutzer verbessern, selbst wenn sie auf einem Einprozessorsystem ausgeführt werden.
  • In der realen Welt führen große Programme mit Multithreading oftmals viel mehr als zwei Threads aus. Software wie Datenbank-Engines erstellt für jede eingehende Anforderung eines Datensatzes einen neuen Verarbeitungsthread. Auf diese Weise verhindert keine einzelne I/O-Operation die Ausführung neuer Anforderungen und Engpässe können vermieden werden. Auf einigen Servern kann dieser Ansatz bedeuten, dass Tausende von Threads gleichzeitig auf demselben System ausgeführt werden.
  • Multiprocessing
  • Multiprocessing-Systeme weisen mehrere Prozessoren auf, die gleichzeitig ausgeführt werden. Herkömmlicherweise besitzen auf der Intel®-Architektur basierende Multiprocessing-Systeme zwischen zwei und 512 Prozessoren. Auf Multiprocessing-Systemen können verschiedene Threads auf unterschiedlichen Prozessoren ausgeführt werden. Diese Fähigkeit beschleunigt die Programmleistung erheblich. Nun können zwei Threads mehr oder weniger unabhängig voneinander ausgeführt werden, ohne dass Threadwechsel erforderlich sind, um die Prozessorressourcen zu erhalten. Multiprozessor-Betriebssysteme sind selbst Multithread-fähig, und die Threads können die einzelnen Prozessoren optimal nutzen.
  • Ursprünglich gab es zwei Arten von Multiprocessing: asymmetrisches und symmetrisches. Bei einem asymmetrischen System waren ein oder mehrere Prozessoren ausschließlich für bestimmte Tasks reserviert, wie der Ausführung des Betriebssystems. Die restlichen Prozessoren waren für alle anderen Tasks verfügbar (im Allgemeinen die Benutzeranwendungen). Es zeigt sich schnell, dass diese Konfiguration nicht optimal war. Auf einigen Maschinen liefen die Betriebssystemprozessoren mit 100 Prozent Kapazität, während die den Benutzern zugewiesenen Prozessoren untätig waren. Innerhalb kurzer Zeit bevorzugten die Systementwickler eine Architektur, die die Verarbeitungslast besser ausglich: symmetrisches Multiprocessing (SMP). Die „Symmetrie” bezieht sich auf die Tatsache, dass jeder Thread – sei es vom Betriebssystem oder der Benutzeranwendung – auf jedem beliebigen Prozessor ausgeführt werden kann. Auf diese Weise wird die Computing-Gesamtlast gleichmäßig über alle Computing-Ressourcen verteilt. Heute sind symmetrische Multiprocessing-Systeme der Standard und asymmetrische Designs sind nahezu verschwunden.
  • SMP-Systeme verdoppeln die Anzahl der Prozessoren, ohne aber die Leistung zu verdoppeln. Die beiden Faktoren, die verhindern, dass sich die Leistung einfach verdoppelt, sind (i) wie gut die Arbeitslast parallelisiert werden kann; sowie der (ii) Systemoverhead. Zwei Faktoren, die die Effizienz der Interaktionen zwischen Threads bestimmen, sind (i) wie sie sich um dieselbe Ressource bewerben; und (ii) wie sie mit anderen Threads kommunizieren.
  • Multiprozessor-Systeme
  • Die heutigen Serveranwendungen bestehen aus mehreren Threads oder Prozessen, die parallel ausgeführt werden können. Die Onlinetransaktionsverarbeitung und Webservices weisen eine Fülle an Softwarethreads auf, die für eine schnellere Leistung gleichzeitig ausgeführt werden können. Selbst Desktopanwendungen verwenden verstärkt die parallele Ausführung. Die Intel-Architekten haben Parallelismus auf Threadebene (Thread-level Parallelism, TLP) implementiert, um die Leistung in Bezug zur Transistorzahl und dem Stromverbrauch zu verbessern.
  • In den High-End- und Mid-Range-Servermärkten sind Multiprozessoren die Regel, um mehr Leistung von dem System zu erhalten. Indem weitere Prozessoren hinzugefügt werden, erhalten Anwendung potenziell wesentliche Leistungssteigerungen, indem mehrere Threads auf mehreren Prozessoren gleichzeitig ausgeführt werden. Diese Threads können aus derselben Anwendung, aus verschiedenen gleichzeitig ausgeführten Anwendungen, aus Betriebssystemdiensten oder aus Betriebssystem-Threads stammen, die im Hintergrund Wartungsaufgaben übernehmen. Multiprozessorsysteme werden seit vielen Jahren verwendet, und die Programmierer sind mit den Techniken zur Nutzung der Multiprozessoren zum Erzielen höherer Leistungslevel vertraut.
  • Die am 14.4.2011 veröffentlichte US-Patentanmeldung „Intermediate Register Mapper” mit der Veröffentlichungsnr. 2011/0087865 von Barrick et al., die hier durch Referenz eingebunden ist, beschreibt „ein Verfahren, einen Prozessor und ein Computerprogrammprodukt, das eine Zwischenregister-Zuordnungseinheit mit einem Registerbenennungsmechanismus nutzt. Eine lokale Registersuche bzw. Register-Lookup bestimmt, ob ein Treffer in einem logischen Register, das der verteilten Anweisung zugeordnet ist, aufgetreten ist. Diesbezüglich durchsucht das logische Register-Lookup wenigstens eine Registerzuordnungseinheit aus einer Gruppe von Registerzuordnungseinheiten, darunter eine Zuordnungseinheit eines definierten Registers, einer vereinheitlichten Registerzuordnungseinheit und einer Zwischenregister-Zuordnungseinheit. Ein einzelner Treffer im logischen Register wird aus der Gruppe der Registerzuordnungseinheiten ausgewählt. Wenn eine Anweisung, die einen Zuordnungseintrag in der vereinheitlichten Hauptzuordnungseinheit besitzt, beendet aber noch nicht abgeschlossen wurde, werden die Zuordnungsinhalte des Eintrags der Registerzuordnungseinheit in der vereinheitlichten Hauptzuordnungseinheit in die Zwischenzuordnungseinheit verschoben, und der Eintrag in der vereinheitlichten Registerzuordnungseinheit wird freigegeben, wodurch sich die Anzahl der zur Wiederverwendung verfügbaren Einträge der vereinheitlichten Hauptzuordnungseinheit erhöht.”
  • Das am 2. April 1998 eingereichte US-Patent-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., das hier durch Referenz eingebunden ist, beschreibt „die Freigabe von Umbenennungsregistern, die definierten (architected) Registern zugewiesen wurden, bevor eine weitere Anweisung das architekturbestimmte Register neu definiert. Das Umbenennen von Registern wird von Prozessoren verwendet, um Anweisung dynamisch außerhalb der Reihenfolge (bzw. Out-of-Order) entweder in einem von einem Prozessor mit einem Thread oder mit mehreren Threads, der die Anweisungen außerhalb der Reihenfolge ausführt, auszuführen. Ein Mechanismus wird beschrieben, um die Umbenennungsregister freizugeben, der aus einem Satz von einem Compiler verwendeten Anweisungen besteht, um dem Prozessor anzugeben, wann er das physische (Umbenennungs-)Register freigeben kann, das einem bestimmten definierten Register zugewiesen ist. Dieser Mechanismus ermöglicht, dass das Umbenennungsregister neu zugeordnet oder zugewiesen wird, um einen anderen Wert zu speichern, sobald das Umbenennungsregister nicht mehr für die Zuweisung an das architekturbestimmte Register benötigt wird. Es gibt mindestens drei Möglichkeiten, um dem Prozessor bei einer Anweisung, die das Umbenennungsregister angibt, die Freigabe der Zuordnung zu ermöglichen: (1) ein Benutzer kann dem Prozessor die Anweisung, die sich auf ein bestimmtes Umbenennungsregister bezieht, explizit angeben; (2) ein Betriebssystem kann die Anweisung bereitstellen, wenn sich ein Thread im Wartezustand befindet, der sich auf einen dem Thread zugeordneten Registersatz bezieht; und (3) ein Compiler kann die Anweisung in die Vielzahl der Anweisungen einbinden, die dem Prozessor zur Verfügung gestellt werden. Es gibt mindestens fünf Ausführungsformen der Anweisung, die dem Prozessor zur Freigabe der Benennungsregister bereitgestellt werden, die den definierten Registern zugeordnet sind: (1) Registerbit freigeben; (2) Register freigeben; (3) Maske freigeben; (4) Opcode freigeben und (5) Opcode/Maske freigeben. Die Anweisung „Registerbit freigeben” bietet die höchste Geschwindigkeit für einen Prozessor mit einer Verarbeitung außerhalb der Reihenfolge und die Anweisung „Register freigeben” bietet die geringste Geschwindigkeit.”
  • „Power ISATM Version 2.06 Revision B" von IBM®, das am 23. Juli 2010 veröffentlicht wurde und hier durch Referenz eingebunden ist, beschreibt eine beispielhafte Architektur eines RISC(Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz)-Befehlssatzes. Die Power ISA wird in dem vorliegenden Dokument verwendet, um beispielshafte Ausführungsformen zu veranschaulichen, die Erfindung ist jedoch nicht auf Power ISA- oder RISC-Architekturen beschränkt. Fachleute werden die Verwendung der Erfindung in verschiedenen Architekturen einfach verstehen.
  • „z/Architecture Principles of Operation" SA22-7832-08, in der neunten Edition (August 2010) von IBM® und hier durch Referenz eingebunden, beschreibt eine beispielhaften Architektur des CISC(Complex Instruction Set Computer, Computer mit komplexen Befehlssatz)-Befehlssatzes.
  • ÜBERSICHT
  • Eine Befehlssatzarchitektur (ISA, Instruction Set Architecture) enthält Operandenressourcen, die von Maschinenanweisungen bzw. Maschinenbefehlen der ISA verwendet werden. Ein Satz von Operandenressourcen, wie allgemeine Register, wird bereitgestellt und ist für Programmierer, die ISA verwenden, zugänglich. Zuvor stellten ISAs dem Programm eine feste Anzahl an aktiven definierten Registern bereit, zum Beispiel 64 8 Byte-Register, die von 6 Bit-Feldern der ISA-Anweisungen adressiert werden können. Hier wird eine ISA-Architektur eingeführt, bei der der Programmierer dem Prozessor Informationen über die Verwendung (Liveliness, bzw. Nutzungsgrad) der Register angeben kann. Zum Beispiel können spezielle architekturbestimmte Register basierend auf der Information vom Programmierer „aktiviert” oder „deaktiviert” werden. Wenn ein Programmierer weiß, dass der Wert in einem Register nicht mehr benötigt wird, kann der Programmierer das Register deaktivieren, sodass der Prozessor Leistungsvorteile durch Ignorieren des Werts erzielen kann. So veranlasst der Programmierer eine Anweisung beispielsweise, die „letzte” bzw. „letztmalige Verwendung” eines Registers durch eine Verbraucheranweisung (Consumer Instruction) mithilfe des Werts im Register anzugeben, die auf eine Erzeugeranweisung (Producer Instruction) folgt, die einen Wert im Register speichert, da es ein temporärer, nicht mehr benötigter Wert ist, sodass der ausführende Prozessor erkennt, dass die Erzeugeranweisung den Wert nicht im definierten Register speichern muss, das als letztmal verwendet angegeben ist.
  • In einer Ausführungsform, bei der der aktive Operand ein in der Architektur definierter Operand ist, auf den eine Anweisung zugreifen kann, wobei der Zugriff auf einen deaktivierten Operanden keine zuvor im Operanden gespeicherten Rückgabewerte liefern muss, wird ein aktiver Operand durch Ausführen einer Anweisung zum Deaktivieren des Operanden (OD) deaktiviert, wobei die OD-Anweisung ein Opcode-Feld mit einem Opcode-Wert aufweist und die OD-Anweisung einen zugeordneten zu deaktivierenden Operanden aufweist. Die Ausführung bestimmt die letztmalige Verwendung des zugeordneten Operanden, führt eine in Opcode definierte Funktion mit dem zugeordneten Operanden aus und setzt den zugeordneten Operanden in einen deaktivierten Zustand.
  • In einer Ausführungsform wird eine beliebige von einer OD-Anweisung oder einer anderen Anweisung ausgeführt, um anzugeben, dass die Verwendung des zugeordneten Operanden durch die OD-Anweisung die letztmalige Verwendung ist. In einer Ausführungsform geht die andere Anweisung der OD-Anweisung in der Programmreihenfolge voran.
  • In einer Ausführungsform besteht der zugeordnete Operand aus einem beliebigen von einem architekturbestimmten allgemeinen Register, einem definierten Zusatzregister oder einem architekturbestimmten Gleitkommazahlenregister, wobei eine Leseoperation des deaktivierten Operanden einen Standardwert zurückgibt, wobei der Standardwert ein beliebiger von einem architekturbedingten nicht definierten Wert oder von einem definierten Standardwert ist. Definierte Zusatzregister sind für Programmierer verfügbare ISA-spezifische architekturbestimmte Register, wie zum Beispiel Zugriffsregister der z/Architecture.
  • In einer Ausführungsform führt das Durchführen einer Schreiboperation in einen architekturbestimmten Operanden in einem deaktivierten Zustand dazu, dass der architekturbestimmte Operand in den aktiven Zustand gesetzt wird.
  • In einer Ausführungsform unterdrückt das Durchführen der Leseoperation eines Operanden in einem deaktivierten Zustand die Fehlerberichterstellung, die der Leseoperation bezüglich des Operanden zugeordnet ist.
  • In einer Ausführungsform weist die Leseoperation bezüglich eines Operanden in einem deaktivierten Zustand ein beliebiges auf von dem Erhalten des Standardwerts aus einem Speicherort, auf den das Programm zugreifen kann; die Rückgabe eines Standardwerts nur mit 1en oder nur mit 0en; oder die Rückgabe eines beliebigen eines inkrementierten Standwerts oder eines dekrementierten Standardwerts für jede Leseoperation des Operanden im deaktivierten Zustand.
  • In einer Ausführungsform weist das Deaktivieren eines Operanden die Rückgabe eines physischen Registers, das einem definierten Register zugeordnet ist, an einen Pool verfügbarer physischer Register, die zur Zuweisung als architekturbestimmte Register verfügbar sind, auf; und das Aktivieren eines Operanden weist die Zuordnung eines physischen Registers aus dem Pool verfügbarer physischer Register als architekturbestimmtes Register in einem aktiven Zustand auf.
  • In einer Ausführungsform ist der Pool der physischen Register als Umbenennungsregister zuweisbar.
  • In einer Ausführungsform wird ein Kontextwechsel durchgeführt, wodurch die Operandenwerte für die aktiven Operanden eines aktuellen Kontextes gespeichert werden, ein beliebiger von den Standardwerten der deaktivierten Operanden oder von den Zustandsinformationen, die angeben, dass die Operanden im aktuellen Kontext deaktiviert sind, gespeichert wird, wodurch die gespeicherten Operandenwerte für die gespeicherten aktiven Operanden eines anderen Kontexts wiederhergestellt werden und ein beliebiger von den gespeicherten Standardwerten als aktive Operanden des anderen Kontexts wiederhergestellt werden oder von dem deaktivierten Zustand der Operanden des anderen Kontextes wiederhergestellt wird.
  • System- und Computerprogrammprodukte, die den oben in der Übersicht dargestellten Verfahren entsprechen, werden ebenso beschrieben und beansprucht.
  • Weitere Merkmale und Vorteile werden durch die Techniken der vorliegenden Erfindung verwirklicht. Weitere Ausführungsformen und Aspekte der Erfindung werden in diesem Dokument detailliert beschrieben und als Teil der beanspruchten Erfindung betrachtet.
  • Kurzbeschreibung der Zeichnungen
  • Der als Erfindung betrachtete Aspekt wird im Besonderen dargestellt und eindeutig in den Ansprüchen am Ende der Zusammenfassung der Beschreibung beansprucht. Die obigen und weitere Ziele, Merkmale und Vorteile der Erfindung werden durch die folgende detaillierte Beschreibung in Verbindung mit den begleitenden Zeichnungen deutlich, in denen:
  • 1 eine beispielhafte Konfiguration eines Prozessorsystems darstellt;
  • 2 ein erstes Beispiel der Prozessor-Pipeline darstellt;
  • 3 ein zweites Beispiel der Prozessor-Pipeline darstellt;
  • 4 ein Beispiel einer Implementierung einer Registereinrichtung in der Architektur beschreibt;
  • 5 ein Beispiel einer Implementierung einer Registerzuordnungseinheit-Einrichtung in der Architektur beschreibt;
  • 6 eine Registerleseoperation in der Architektur beschreibt;
  • 7 eine Registerschreiboperation in der Architektur beschreibt; und
  • 8 eine Registerkontextwechseloperation in der Architektur beschreibt.
  • Detaillierte Beschreibung
  • Ein Out-of-Order-(OoO)-Prozessor enthält in der Regel mehrere Ausführungs-Pipelines, die Anweisungen opportunistisch in einer anderen Reihenfolge ausführen können als die Programmsequenz (oder „Programmreihenfolge” bzw. Programmabfolge) angibt, um die Durchschnittsrate der Anweisungen pro Zyklus zu maximieren, indem die Datenabhängigkeiten reduziert und die Nutzung der Ausführungs-Pipelines maximiert werden, die den verschiedenen Anweisungstypen zugeordnet sind. Die Ergebnisse der Anweisungsausführung werden in der Regel temporär in physischen Registern einer oder mehrerer Registerdateien mit begrenzter Tiefe gespeichert. Ein OoO-Prozessor nutzt in der Regel die Registerumbenennung, um eine unnötige Serialisierung von Anweisungen aufgrund der Wiederverwendung eines gegebenen definierten Registers durch aufeinanderfolgende Anweisungen in der Programmabfolge zu vermeiden.
  • Gemäß US 2011/0087865 wird bei den Registerumbennungsoperationen jedes definierte (d. h. logische) Register, auf das einer Anweisung abzielt, einem eindeutigen physischen Register in einer Registerdatei zugeordnet. In aktuellen OoO-Hochleistungsprozessoren wird eine vereinheitlichte Hauptzuordnungseinheit zur Verwaltung der physischen Register in mehreren Registerdateien genutzt. Zusätzlich zur Speicherung der Übersetzung vom logischen in das physische Register (d. h. in Einträgen der Zuordnungseinheit) ist die vereinheitlichte Hauptzuordnungseinheit auch dafür verantwortlich, Abhängigkeitsdaten (d. h. Positionsdaten in der Warteschlange) zu speichern, was für die Anordnung der Anweisungen beim Abschluss wichtig ist.
  • In einem Umbenennungsschema auf der Basis der vereinheitlichten Hauptzuordnungseinheit ist es wünschenswert, dass Einträge in der Zuordnungseinheit möglichst schnell für die Wiederverwendung durch den OoO-Prozessor freigegeben werden. Im Stand der Technik kann aber ein Eintrag in der vereinheitlichten Hauptzuordnungseinheit erst dann freigegeben werden, wenn die Anweisung, die in ein durch den Zuordnungseintrag zugeordnete Register schreibt, abgeschlossen ist. Diese Bedingung wird durchgesetzt, da bis zum Abschluss die Möglichkeit besteht, dass eine Anweisung, die „beendet” wurde (wie die bestimmte Ausführungseinheit (EU, Execution Unit), die die Anweisung erfolgreich ausgeführt hat) gelöscht (bzw. geleert; flushed) wird, bevor die Anweisung „abgeschlossen” werden kann und bevor der definierte kohärente Zustand der Register aktualisiert wird.
  • In aktuellen Implementierungen wurden allgemein Ressourcenbedingungen der vereinheitlichten Zuordnungseinheit allgemein behandelt, indem die Anzahl der Einträge in der vereinheitlichten Hauptzuordnungseinheit erhöht wurde. Die Erhöhung der Größe der vereinheitlichten Hauptzuordnungseinheit geht mit Strafen in den Bereichen Die-Fläche, Komplexität, Stromverbrauch und Zugriffszeit einher.
  • Im oben erwähnten Patent US 2011/0087865 wird ein Verfahren zum Verwalten einer Satzes von einem oder mehreren physischen Registern in einem Datenverarbeitungssystem vorgesehen. Das Datenverarbeitungssystem verfügt über einen Prozessor, der Anweisungen außerhalb der Reihenfolge verarbeitet, wobei die Anweisungen logische Register referenzieren und wobei jedes der logischen Register dem Satz von einem oder mehreren physischen Registern zugeordnet wird. Als Reaktion auf das Verteilen einer oder mehrerer Anweisungen, führt eine Registerverwaltungseinheit ein logisches Register-Lookup durch, das bestimmt, ob ein der verteilten Anweisung zugeordneter Treffer im logischen Register in einer oder mehreren Registerzuordnungseinheiten aufgetreten ist. In dieser Hinsicht durchsucht das logische Register-Lookup wenigstens eine Registerzuordnungseinheit aus einer Gruppe von Registerzuordnungseinheiten, darunter eine Zuordnungseinheit der definierten Register, eine vereinheitlichte Registerzuordnungseinheit und einer Zwischenregister-Zuordnungseinheit. Die Registerverwaltungseinheit wählt einen Treffer im logischen Register aus der Gruppe der Registerzuordnungseinheiten aus. Wenn eine Anweisung mit einem Zuordnungseinheitseintrag in der vereinheitlichten Hauptzuordnungseinheit beendet aber noch nicht abgeschlossen wurde, verschiebt die Registerverwaltungseinheit die Daten für die Umbenennung des logischen in das physische Register des Eintrags in der vereinheitlichten Hauptzuordnungseinheit in die Zwischenregister-Zuordnungseinheit, und die vereinheitlichte Hauptzuordnungseinheit gibt den Eintrag in der vereinheitlichten Hauptzuordnungseinheit vor Abschluss der Anweisung frei. Die Freigabe des Eintrags in der vereinheitlichten Hauptzuordnungseinheit erhöht die Anzahl von Einträgen in der vereinheitlichten Hauptzuordnungseinheit, die zur Wiederverwendung verfügbar sind.
  • Im Folgenden wird nun auf die FIG. und im Besonderen auf 1 Bezug genommen. Hier wird Beispiel eines Datenverarbeitungssystems 100 dargestellt, das einen OoO-Prozessor enthalten kann, der eine Zwischenregister-Zuordnungseinheit aufweist, wie im Folgenden mit Bezugnahme auf 2. beschrieben. Wie in 1 dargestellt, verfügt das Datenverarbeitungssystem 100 über einen zentrale Verarbeitungseinheit (CPU, Central Processing Unit) 110, die mit dem Prozessor 200 von 2 ausgestattet sein kann. Die CPU 110 ist mit verschiedenen anderen Komponenten über einen Interconnect (bzw. Verbindung) 112 verbunden. Festspeicher („ROM”, Read Only Memory) 116 ist mit dem Interconnect 112 verbunden und weist ein grundlegendes Eingabe-/Ausgabesystem („BIOS”, Basic Input/Output System) auf, das bestimmte Grundfunktionen des Datenverarbeitungssystem 100 steuert. Ein Schreib-Lese-Speicher („RAM”, Random Access Memory) 114, ein I/O-Adapter 118 und ein Kommunikationsadapter 134 sind ebenso mit dem Systembus 112 verbunden. Beim I/O-Adapter 118 kann es sich um einen „SCSI”-Adapter (Small Computer System Interface) handeln, der mit einer Speichereinrichtung 120 kommuniziert. Der Kommunikationsadapter 134 bildet mit dem Netzwerk 140 eine Schnittstelle zum Interconnect 112, wodurch das Datenverarbeitungssystem 100 mit anderen solchen Systemen kommunizieren kann, wie einem entfernten Computer 142. Die Eingabe-/Ausgabeeinrichtungen sind ebenso mit dem Interconnect 112 über den Benutzerschnittstellenadapter 122 und den Bildschirmadapter 136 verbunden. Die Tastatur 124, der Trackball 132, die Maus 126 und die Lautsprecher 128 sind alle mit dem Bus 112 über einen Benutzerschnittstellenadapter 122 miteinander verbunden. Der Bildschirm 138 ist mit dem Systembus 112 über den Bildschirmadapter 136 verbunden. Auf diese Weise empfängt das Datenverarbeitungssystem 100 Eingaben beispielsweise über die Tastatur 124, den Trackball 132, und/oder die Maus 126 und stellt Ausgaben zum Beispiel über das Netzwerk 142, auf der Speichereinrichtung 120, dem Lautsprecher 128 und/oder dem Bildschirm 138 bereit. Die im Datenverarbeitungssystem 100 dargestellten Hardwarekomponenten sind nicht als erschöpfend zu betrachten, sondern stellen vielmehr die grundlegenden Komponenten eines Datenverarbeitungssystems in einer Ausführungsform dar.
  • Der Betrieb des Datenverarbeitungssystems 100 kann durch Programmcode gesteuert werden, wie Firmware und/oder Software, wozu in der Regel zum Beispiel ein Betriebssystem wie AIX® („AIX” ist ein Markenzeichen der IBM Corporation) und eine oder mehrere Anwendungen oder Middleware-Programm gehören. Ein solcher Programmcode weist Anweisungen auf, die im Folgenden mit Bezugnahme auf 2 erörtert werden.
  • Mit Bezugnahme auf 2 wird nun ein superskalarer Prozessor 200 dargestellt. Anweisungen werden aus dem Speicher (z. B. dem RAM 114 von 1) abgerufen und in die Befehlsabfolgelogik (ISL, Instruction Sequencing Logic) 204 geladen, die den Level 1-Befehlsscache (L1 I-Cache) 206, die Abruf-Dekodiereinheit 208, die Anweisungsschlange 210 und die Verteilungseinheit 212 enthält. Im Besonderen werden die Anweisungen in den L1 I-Cache 206 von ISL 20 geladen. Die Anweisungen werden im L1 I-Cache 206 gehalten, bis sie benötigt werden, oder ersetzt, wenn sie nicht benötigt werden. Die Anweisungen werden aus dem L1 I-Cache 206 abgerufen und durch die Abruf-Dekodiereinheit 208 dekodiert. Nachdem eine aktuelle Anweisung dekodiert wurde, wird die aktuelle Anweisung in die Anweisungsschlange 210 geladen. Die Verteilungseinheit 212 verteilt Anweisungen aus der Anweisungsschlange 210 in die Registerverwaltungseinheit 214 sowie die Abschlusseinheit 240. Die Abschlusseinheit 240 ist mit der allgemeinen Ausführungseinheit 224 und der Registerverwaltungseinheit 214 verbunden und überwacht, wann eine abgesetzte Anweisung abgeschlossen wurde.
  • Wenn die Verteilungseinheit 212 eine aktuelle Anweisung verteilt, weist die vereinheitlichte Hauptzuordnungseinheit 218 der Registerverwaltungseinheit 214 eine logische Zielregisternummer einem physischen Register in den physischen Registerdateien 232a232n zu, die derzeit keinem logischen Register zugewiesen ist. Das Ziel soll in das angegebene physische Register aus den physischen Registerdateien 232a232n umbenannt werden.
  • Die vereinheitlichte Zuordnungseinheit 218 entfernt das zugewiesene physische Register aus einer Liste 219 der freien physischen Register in der einheitlichen Zuordnungseinheit 218. Alle nachfolgenden Referenzen auf dieses logische Zielregister zeigen auf dasselbe logische Register, bis die Abruf-Dekodiereinheit 208 eine andere Anweisung dekodiert, die in dasselbe logische Register schreibt. Die vereinheitlichte Zuordnungseinheit 218 benennt die logischen Register in einen anderen physischen Speicherort um, der aus der Freiliste 219 ausgewählt wurde, und die Zuordnungseinheit wird aktualisiert, um die neuen Daten der logischen-zu-physischen Registerzuordnung einzutragen. Wenn die Daten der logischen-zu-physischen Registerzuordnung nicht mehr benötigt werden, werden die alten Zuordnungen der physischen Register in die Freiliste 219 zurückgegeben. Wenn die Freiliste 219 nicht über ausreichend physische Register verfügt, unterbricht die Verteilungseinheit 212 das Verteilen der Anweisungen, bis die benötigten physischen Register verfügbar sind.
  • Nachdem die Registerverwaltungseinheit 214 die aktuelle Anweisung zugeordnet hat, setzt die Warteschlange der abzusetzenden Anweisungen 222 die aktuelle Anweisung für die allgemeine Ausführungs-Engine 224 ab, die die Ausführungseinheiten (Eus, Execution Units) 230a230n enthält. Die Ausführungseinheiten 230a230n sind von verschiedenen Typen, wie Gleitkommazahl (FP, Floating-point), Festkomma (FX, Fixed-Point) und Laden/Speichern (LS). Die allgemeine Ausführungs-Engine 224 tauscht Daten mit dem Datenspeicher (wie RAM 114, ROM 116 von 1) über einen Datencache 234 aus. Darüber hinaus kann die Warteschlange der abzusetzenden Anweisungen 222 Anweisungen vom FP-Typ, FX-Typ und LS-Anweisungen enthalten. Es versteht sich aber, dass eine beliebige Anzahl und beliebige Typen von Anweisungen verwendet werden können. Bei der Ausführung erhalten die EUs 230a230n die Quellenoperandenwerte aus den physischen Speicherorten in der Registerdatei 232a232n und speichern Ergebnisdaten, falls vorhanden, in den Registerdateien 232a232n und/oder im Datencache 234.
  • Mit weiterer Bezugnahme auf 2 weist die Registerverwaltungseinheit 214 auf: (i) Zuordnungseinheitscluster 215, zu denen die Zuordnungseinheit der definierten Register 216, die vereinheitlichte Hauptzuordnungseinheit 218, die Zwischenregister-Zuordnungseinheit 220, und (ii) die Warteschlange der abzusetzenden Anweisungen 222 gehören. Das Zuordnungseinheitscluster 215 verfolgt die physischen Register, die den logischen Registern der verschiedenen Anweisungen zugeordnet sind. In einer beispielhaften Ausführungsform verfügt eine Zuordnungseinheit der definierten Register 216 über 16 logische (d. h. physisch nicht zugeordnete) Register eines jeden Typs, die den letzten, gültigen Zustand (d. h. für den ein Checkpoint besteht) der logischen-zu-physischen Registereinheitzuordnungsdaten speichern. Es sollte aber beachtet werden, dass die unterschiedlichen Prozessorarchitekturen über mehr oder weniger logische Register verfügen können als in der beispielhaften Ausführungsform beschrieben. Die Zuordnungseinheit der definierten Register 216 enthält eine Pointerliste (bzw. Zeigerliste), die ein physisches Register angibt, das den Zustand mit Checkpoint beschreibt. Die physischen Registerdateien 232a232n enthalten in der Regel mehr Register als die Anzahl der Einträge in einer Zuordnungseinheit der definierten Register 216. Es sollte beachtet werden, dass die bestimmte Anzahl der physischen und logischen Register, die in einem Umbenennungszuordnungsschema verwendet werden, variieren kann.
  • Dem gegenüber ist die vereinheitlichte Hauptzuordnungseinheit 218 in der Regel größer (enthält in der Regel bis zu 20 Einträge) als die Zuordnungseinheit der definierten Register 216. Die vereinheitlichte Hauptzuordnungseinheit 218 vereinfacht das Verfolgen des Übergangszustands der logischen-zu-physischen Registerzuordnungen. Der Begriff „Übergang” (bzw. transient) bezieht sich auf die Tatsache, dass die vereinheitlichte Hauptzuordnungseinheit 218 die vorläufigen logischen-zu-physischen Registerzuordnungsdaten verfolgt, wenn die Anweisungen außerhalb der Reihenfolge ausgeführt werden. Die OoO-Ausführung tritt in der Regel auf, wenn ältere Anweisungen vorliegen, deren Ausführung länger dauern würde (d. h. die mehr Taktzyklen verwenden) als neuere Anweisungen in der Pipeline. Sollte aber das erwartete Ergebnis einer OoO-Anweisung erfordern, dass es aus einem bestimmten Grund gelöscht wird (z. B. einer falschen Verzweigungsprognose) kann der Prozessor zu dem Status des Checkpoints zurückkehren, der in der Zuordnungseinheit der definierten Register 216 aufbewahrt ist und die Ausführung ab dem letzten gültigen Zustand wieder aufnehmen.
  • Die vereinheitlichte Hauptzuordnungseinheit 218 stellt die Verknüpfung zwischen den physischen Registern in den physischen Registerdateien 232a232n und der Zuordnungseinheit der definierten Register 216 her. Der qualifizierende Begriff „vereinheitlicht” (Unified) bezieht sich auf die Tatsache, dass die vereinheitlichte Hauptzuordnungseinheit 218 die Komplexität einer angepassten dedizierten Zuordnungseinheit für alle Registerdateien 232 (wie allgemeine Register (GPRs), Gleitkommazahlenregister (FPRs), Festkommaregister (FXPs), Ausnahmeregister (XERs, Exception Register), Bedingungsregister (CRs, Condition Register) usw.) verringert.
  • Zusätzlich zum Erstellen eines transienten logischen-zu-physischen Registerzuordnungseinheitseintrags einer OoO-Anweisung verfolgt die vereinheitlichte Hauptzuordnungseinheit 218 auch die Abhängigkeitsdaten (d. h. Anweisungen, die von der Beendigung einer älteren Anweisung in der Pipeline abhängen), was für die Reihenfolge der Anweisungen wichtig ist. Herkömmlicherweise, sobald eine vereinheitlichte Hauptzuordnungseinheit 218 mit der Übersetzung des logischen in das physische Register einer Anweisung begonnen hat, wird die Anweisung an die Warteschlange der abzusetzenden Anweisungen 222 übergeben. Die Warteschlange der abzusetzenden Anweisungen 222 dient als Torwächter, bevor die Anweisung an die Ausführungseinheit 230 zur Ausführung abgesetzt wird. Als allgemeine Regel kann eine Anweisung die Warteschlange der abzusetzenden Anweisungen 222 nicht verlassen, wenn sie davon abhängig ist, dass eine ältere Anweisung beendet wird. Aus diesem Grund verfolgt die vereinheitlichte Hauptzuordnungseinheit 218 die Abhängigkeitsdaten durch Speichern der Positionsdaten der Warteschlange der abzusetzenden Anweisungen für jede zugeordnete Anweisung. Nach Ausführung der Anweisung durch die allgemeine Ausführung-Engine 224 gilt die Anweisung als „beendet” und wird aus der Warteschlange der abzusetzenden Anweisungen 222 zurückgenommen.
  • Die Registerverwaltungseinheit 214 kann mehrere Anweisungen aus der Verteilungseinheit 212 in einem einzelnen Zyklus empfangen, um so eine gefüllte einzelne Befehlsabsetzungs-Pipeline bereitzustellen. Das Verteilen der Anweisungen ist auf die Anzahl der verfügbaren Einträge in der vereinheitlichten Hauptzuordnungseinheit 218 beschränkt. Wenn in herkömmlichen Zuordnungssystemen, in denen die Zwischenregister-Zuordnungseinheit 220 fehlt, die vereinheitlichte Hauptzuordnungseinheit 218 über insgesamt 20 Hauptzuordnungseinträge verfügt, gibt es maximal 20 Anweisungen, die auf im Augenblick flüchtig (d. h. nicht in einem Checkpoint gespeichert) sind. Somit kann die Verteilungseinheit 212 eines herkömmlichen Zuordnungseinheitssystems möglicherweise mehr Anweisungen „verteilen” als tatsächlich aus der vereinheitlichten Hauptzuordnungseinheit 218 zurückgegeben werden können. Der Grund für diesen Engpass in der vereinheitlichten Hauptzuordnungseinheit 218 ist in der Tatsache begründet, dass der Eintrag in der Zuordnungseinheit einer Anweisung herkömmlicherweise erst aus der vereinheitlichten Hauptzuordnungseinheit 218 entfernt werden kann, wenn die Anweisung „abgeschlossen” ist (d. h. die Ausführung aller älterer Anweisungen beendet wurde).
  • Gemäß einer Ausführungsform dient die Zwischenregister-Zuordnungseinheit 220 als nicht zeitplanungskritisches Register, für das eine „beendete” aber „unvollständige” Anweisung aus der vereinheitlichten Hauptzuordnungseinheit 218 mit dem Fortschritt des letztendlichen Abschlusses der Anweisung zurückgenommenen werden (d. h. aus der vereinheitlichten Hauptzuordnungseinheit 218 entfernt werden) kann. Wenn die Anweisung „abgeschlossen wird”, benachrichtigt die Abschlusseinheit 240 die Zwischenregister-Zuordnungseinheit 220 von dem Abschluss. Der Zuordnungseinheitseintrag in der Zwischenregister-Zuordnungseinheit 220 kann dann den architekturbestimmten kohärenten Status der Zuordnungseinheit der architekturbestimmten Register 216 durch Ersetzen des entsprechenden Eintrags, der aktuell in der Zuordnungseinheit der architekturbestimmten Register 216 gespeichert wurde, aktualisieren.
  • Wenn die Verteilungseinheit 212 eine Anweisung verteilt, wertet die Registerverwaltungseinheit 214 die logischen Registernummer(n), die der Anweisung zugeordnet sind, für Zuordnungen in der Zuordnungseinheit der architekturbestimmten Register 216, der vereinheitlichten Hauptzuordnungseinheit 218 und der Zwischenregister-Zuordnungseinheit 220 aus, um zu bestimmen, ob eine Übereinstimmung (im Allgemeinen als „Treffer” bezeichnet) in der Zuordnungseinheit der architekturbestimmten Register 216, der vereinheitlichten Hauptzuordnungseinheit 218 und/oder der Zwischenregister-Zuordnungseinheit 220 vorliegt. Diese Auswertung wird als logisches Register-Lookup bezeichnet. Wird das Lookup gleichzeitig bei mehr als einer Registerzuordnungseinheit durchgeführt (d. h. der Zuordnungseinheit der architekturbestimmten Register 216, der vereinheitlichten Hauptregisterzuordnungseinheit 218 und/oder der Zwischenregister-Zuordnungseinheit 220), wird das Lookup als paralleles logisches Register-Lookup bezeichnet.
  • Jede Anweisung, die den Wert eines bestimmen logischen Zielregisters aktualisiert, wird einem neuen physischen Register zugewiesen. Immer wenn diese neue Instanz des logischen Registers von einer anderen Anweisung als Quelle verwendet wird, muss dasselbe physische Register verwendet werden. Da eine Vielzahl an Instanzen eines logischen Registers bestehen kann, kann auch eine Vielzahl physischer Register bestehen, die dem logischen Register entsprechen. Die Registerverwaltungseinheit 214 führt die Aufgaben durch: (i) Analysieren, welches physische Register einem logischen Register entspricht, das von einer bestimmten Anweisung verwendet wird, (ii) Ersetzen der Referenz auf das logische Register durch eine Referenz auf das entsprechende physische Register (d. h. Umbenennen des Registers) und (iii) Zuweisen eines neuen physischen Registers, jedes Mal, wenn eine neue Instanz eines beliebigen logischen Registers erstellt wird (d. h. Zuweisung des physischen Registers).
  • Anfangs, bevor Anweisungen verteilt werden, erhält die vereinheitlichte Hauptzuordnungseinheit 218 keinen Treffer/keine Übereinstimmung, da aktuell keine Anweisungen vorliegen, die nicht festgeschrieben sind. In diesem Fall erstellt die vereinheitlichte Hauptzuordnungseinheit 218 einen Zuordnungseintrag. Werden nachfolgende Anweisungen verteilt, wenn eine logische Registerübereinstimmung für dieselbe logische Registernummer in beiden von der Zuordnungseinheit der definierten Register 216 und der vereinheitlichten Hauptzuordnungseinheit 218 gefunden wird, erhält die Auswahl der logischen-zur-physischen Registerzuordnung der vereinheitlichten Hauptzuordnungseinheit 218 Priorität, da die Möglichkeit besteht, dass Anweisungen derzeit außerhalb der Reihenfolge ausgeführt werden können (d. h. die Zuordnung befindet sich in einem Übergangsstatus).
  • Nachdem die vereinheitlichte Hauptzuordnungseinheit 218 einen Treffer/eine Übereinstimmung in der Zuordnungseinheit gefunden hat, geht die Anweisung an die Warteschlange der abzusetzenden Anweisungen 222 weiter, um auf das Absetzen zur Ausführung durch eine der Ausführungseinheiten 230 zu warten. Nachdem eine allgemeine Ausführungs-Engine 224 die Anweisung ausführt und „beendet”, bevor aber die Anweisung „abgeschlossen wird”, nimmt die Registerverwaltungseinheit 214 den Zuordnungseinheitseintrag, der aktuell in der vereinheitlichten Hauptzuordnungseinheit 218 gefunden wurde, aus der vereinheitlichten Hauptzuordnungseinheit 218 und verschiebt den Zuordnungseintrag in die Zwischenregister-Zuordnungseinheit 220. In der Folge wird ein Slot in der vereinheitlichten Hauptzuordnungseinheit 218 zum Zuordnen einer nachfolgend verteilten Anweisung verfügbar gemacht. Im Unterschied zur vereinheitlichten Hauptzuordnungseinheit 218 speichert die Zwischenregister-Zuordnungseinheit 220 keine Abhängigkeitsdaten. Somit hängt die an die Zwischenregister-Zuordnungseinheit 220 übertragene Zuordnung nicht von den Warteschlangenpositionen der Anweisungen ab (und verfolgt diese nicht), die den Quellzuordnungen zugeordnet sind. Der Grund hierfür ist, dass die Warteschlange der abzusetzenden Anweisungen 222 die „beendete, aber nicht abgeschlossene” Anweisung nach der erfolgreichen Ausführung zurücknimmt. Im Gegensatz dazu speichert bei herkömmlichen Schemas der Umbenennungszuordnung, bei denen eine Zwischenregister-Zuordnungseinheit fehlt, eine vereinheitlichte Hauptzuordnungseinheit weiterhin den Quellenumbenennungseintrag, bis die Anweisung abgeschlossen ist. Im Rahmen der vorliegenden Ausführungsform kann die Zwischenregister-Zuordnungseinheit 220 von anderen kritischen Pfadelementen weiter entfernt positioniert werden, da der Betrieb der vereinheitlichten Hauptzuordnungseinheit 218 nicht zeitkritisch ist.
  • Wenn die vereinheitlichte Hauptzuordnungseinheit 218 einen Zuordnungseintrag aus der vereinheitlichten Hauptzuordnungseinheit 218 zurücknimmt und in die Zwischenregister-Zuordnungseinheit 220 übernimmt, führt das Zuordnungscluster 214 ein paralleles logisches Register-Lookup für eine nachfolgende verteilte Anweisung durch, um zu bestimmen, ob die nachfolgende Anweisung einen Treffer/eine Übereinstimmung in einer von der Zuordnungseinheit der definierten Register 216, der vereinheitlichten Hauptzuordnungseinheit 218 und der Zwischenregister-Zuordnungseinheit 220 enthält. Wenn ein Treffer/eine Übereinstimmung derselben logischen Zielregisternummer in wenigstens zwei von der Zuordnungseinheit der definierten Register 216, der vereinheitlichten Hauptzuordnungseinheit 218 und der Zwischenregister-Zuordnungseinheit 220 gefunden wird, setzt ein Multiplexer 223 in der Warteschlange der abzusetzenden Anweisungen 222 die Priorität durch Auswahl der logischen-zur-physischen Registerzuordnung der vereinheitlichten Hauptzuordnungseinheit 218 vor der der Zwischenregister-Zuordnungseinheit 220 durch, die wiederum eine Auswahlpriorität gegenüber der Zuordnungseinheit der definierten Register 216 besitzt.
  • Der von US 2011/0087865 vorgeschlagene Mechanismus, durch den die Auswahlpriorität bestimmt wird, wird wie im Folgenden erörtert. In einem übergeordneten logischen Ablaufdiagramm eines beispielhaften Verfahrens wird dargestellt, welche Zuordnungsdatenwerte in der Ausführung einer Anweisung gemäß einer Ausführungsform verwendet werden sollen. In einer Ausführungsform verteilt eine Verteilungseinheit 212 eine oder mehrere Anweisungen an die Registerverwaltungseinheit 214. Als Reaktion auf das Verteilen der Anweisung(en) bestimmt die Registerverwaltungseinheit 214 über ein paralleles logisches Register-Lookup, ob ein „Treffer” im logischen Register (zusätzlich zu einem „Treffer” in der Zuordnungseinheit der definierten Register 216), der jeder verteilten Anweisung zugeordnet ist, aufgetreten ist. In dieser Hinsicht versteht es sich, dass bei der Zuordnungseinheit der definierten Register 216 davon ausgegangen wird, dass immer ein Treffer/eine Übereinstimmung vorliegt, da die Zuordnungseinheit der definierten Register 216 den Checkpoint-Zustand der logischen-zu-physischen Registerzuordnungsdaten speichert. Wenn die Registerverwaltungseinheit 214 keine Übereinstimmung/keinen Treffer in der vereinheitlichten Hauptzuordnungseinheit 218 und/oder der Zwischenregister-Zuordnungseinheit 220 erfasst, wählt der Multiplexer 223 die logischen-zu-physischen Registerumbenennungsdaten aus der Zuordnungseinheit der definierten Register 216. Wenn die Registerverwaltungseinheit 214 eine Übereinstimmung/einen Treffer in der vereinheitlichten Hauptzuordnungseinheit 218 und/oder der Zwischenregister-Zuordnungseinheit 220 erfasst, bestimmt die Registerverwaltungseinheit 214 in einem Entscheidungsblock, ob eine Übereinstimmung/ein Treffer in beiden von der vereinheitlichten Hauptzuordnungseinheit 218 und/oder der Zwischenregister-Zuordnungseinheit 220 auftritt. Wenn ein Treffer/eine Übereinstimmung in beiden Zuordnungseinheiten 218 und 220 bestimmt wird, bestimmt eine Registerverwaltungseinheit 214, ob der Zuordnungseintrag in der vereinheitlichten Hauptzuordnungseinheit 218 „jünger” (d. h. das Erstellen des Zuordnungseintrags ist neueren Datums) als der Zuordnungseintrag in der Zwischenregister-Zuordnungseinheit 220 ist. Wenn der Eintrag in der vereinheitlichten Hauptzuordnungseinheit 218 jünger ist als der Eintrag in der Zwischenregister-Zuordnungseinheit 220, wählt der Multiplexer 223 die logischen-zu-physischen Registerumbenennungsdaten aus der vereinheitlichten Hauptzuordnungseinheit 218 aus. Wenn der Eintrag in der vereinheitlichten Hauptzuordnungseinheit 218 nicht jünger ist als der Eintrag in der Zwischenregister-Zuordnungseinheit 220, wählt der Multiplexer 223 die logischen-zu-physischen Registerumbenennungsdaten aus der Zwischenregister-Zuordnungseinheit 220 aus.
  • Wenn keine Übereinstimmung/kein Treffer in beiden von der vereinheitlichten Hauptzuordnungseinheit 218 und der Zwischenregisterspeichereinheit 220 vorkommt, wird bestimmt, ob ein Treffer/eine Übereinstimmung ausschließlich in der vereinheitlichten Hauptzuordnungseinheit 218 vorkommt. Wenn ein Treffer ausschließlich in der vereinheitlichten Hauptzuordnungseinheit 218 aufritt, wählt der Multiplexer 223 die Umbenennungsdaten des logischen-zu-physischen Registers aus der vereinheitlichten Hauptzuordnungseinheit 218 aus. Wenn jedoch ein Treffer/eine Übereinstimmung nicht in der vereinheitlichten Zuordnungseinheit 218 auftritt (somit tritt der Treffer/die Übereinstimmung ausschließlich in der Zwischenregister-Zuordnungseinheit 220 auf), wählt der Multiplexer 223 die logischen-zu-physischen Registerumbenennungsdaten aus der Zwischenregister-Zuordnungseinheit 220 (Block 320) aus. Eine allgemeine Ausführungs-Engine 224 verwendet die Ausgabedaten des logischen Register-Lookups zur Ausführung.
  • In einer beispielhaften Ausführungsform verteilt eine Verteilungseinheit 212 eine oder mehrere Anweisungen an die Registerverwaltungseinheit 214. Eine vereinheitlichte Hauptzuordnungseinheit erstellt einen neuen logischen-zu-physischen Registerzuordnungseintrag. Die Warteschlange der abzusetzenden Anweisungen 222 hält die Positionsdaten der Warteschlange der abzusetzenden Anweisungen der verteilten Anweisung, die den Zuordnungseintrag nutzt, der über das logische Register-Lookup ausgewählt wird (in 3 beschrieben). Die allgemeine Ausführungs-Engine 224 erfasst, ob eine der Anweisungen in Ausführung beendet wurde (d. h. eine der Us 130 hat die Ausführung einer Anweisung beendet). Wenn die abgesetzte Anweisung nicht beendet wurde, wartet die Methode, dass eine Anweisung beendet wird. In Reaktion auf die allgemeine Ausführungs-Engine 224, die erfasst, das eine Anweisung beendet wurde, verschiebt die vereinheitlichte Hauptzuordnungseinheit 218 die logischen-zu-physischen Registerumbenennungsdaten von der vereinheitlichten Hauptzuordnungseinheit 218 in die Zwischenregister-Zuordnungseinheit 220. Die vereinheitlichte Hauptzuordnungseinheit 218 nimmt den Eintrag der vereinheitlichten Hauptzuordnungseinheit, der der fertigen Anweisung zugeordnet ist, zurück. Eine Abschlusseinheit 240 bestimmt, ob die beendete Anweisung abgeschlossen wurde. Wenn die beendete Anweisung nicht abgeschlossen wurde, wartet die Abschlusseinheit 240 weiter, bis sie erfasst, dass die allgemeine Ausführungseinheit 224 alle älteren Anweisungen beendet hat. Wenn die Abschlusseinheit 240 jedoch erfasst, dass die beendete Anweisung abgeschlossen wurde, aktualisiert die Zwischenregister-Zuordnungseinheit 220 den architekturbestimmten kohärenten Zustand der Zuordnungseinheit der architekturbestimmten Register 216 und de Zwischenregister-Zuordnungseinheit 220 nimmt den Zuordnungseintrag zurück.
  • Das am 13. Februar 2001 eingereichte US-Patent-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 Gwschind, das hier durch Referenz eingebunden ist, beschreibt ein Beispiel eines Out-of-Order (OoO)-Prozessors.
  • Gemäß US 6189088 ist 3 ein funktionalen Blockdiagramm eines herkömmlichen Computerverarbeitungssystems (z. B. mit einem superskalaren Prozessor), das die dynamische Neuordnung der Speicheroperationen und der hardwarebasierten Implementierungen der Interferenztest- und Datenumgehungsabfolge unterstützt. Das heißt, das System von 3 beinhaltet Hardwareressourcen, die zur Unterstützung der Neuanordnung von Anweisungen mit den oben aufgeführten Mechanismen erforderlich sind, enthält aber keine Hardwareressourcen, die zur Unterstützung der Ausführung von Ladeoperationen außerhalb der Reihenfolge vor den Ladeoperationen gemäß der Reihenfolge erforderlich sind. Das System besteht aus: einem Speichersubsystem 301; einem Datencache 302; einem Anweisungscache 304; und einer Prozessoreinheit 300. Die Prozessoreinheit 500 weist auf: eine Anweisungswarteschlange 303; verschiedene Speichereinheiten (Mus, Memory Units) 305 zum Durchführen von Lade- und Speicheroperationen; verschiedene Funktionseinheiten (Fus, Functional Units) 307 zum Durchführen von Ganzzahlen-, Logik- und Gleitkommaoperationen; eine Verzweigungseinheit (BU, Branch Unit) 309; eine Registerdatei 311; eine Registerzuordnungstabelle 320; eine Warteschlange der freien Register 322; eine Verteilungstabelle 324; eine Rücknahmewarteschlange 326 und eine Zuordnungstabelle gemäß der Reihenfolge 328.
  • In dem in 3 dargestellten Prozessor werden Anweisungen aus dem Anweisungscache 304 (oder aus dem Speichersystem 301, wenn sich die Anweisungen nicht im Anweisungscache 304 befinden) unter der Steuerung der Verzweigungseinheit 309 abgerufen, in die Anweisungsschlange 303 gesetzt und nachfolgend aus der Anweisungsschlange 303 verteilt. Die von den Anweisungen verwendeten Registernamen zur Angabe von Operanden werden gemäß den Inhalten der Registerzuordnungstabelle 320 umbenannt, die die aktuelle Zuordnung der definierten Registernamen zu den physischen Registern angibt. Die von den Anweisungen zur Angabe der Ziele für die Ergebnisse verwendeten definierten Registernamen werden physischen Registern zugeordnet, die aus der Warteschlange der freien Register 322 extrahiert werden, die die Namen der physischen Register enthält, die derzeit nicht vom Prozessor verwendet werden. Die Registerzuordnungstabelle 320 wird mit den Zuordnungen der physischen Register zu den definierten Zielregisternamen, die durch die Anweisungen angeben werden, aktualisiert. Die Anweisungen mit allen umbenannten Registern werden in der Verteilungstabelle 324 abgelegt. Die Anweisungen werden auch in der Rücknahmeschlange 326 in der Programmreihenfolge mit ihren Adressen und ihren physischen und definierten Registernamen abgelegt. Die Anweisungen werden aus der Verteilungstabelle 324 verteilt, wenn alle durch diese Anweisungen zu verwendenden Ressourcen verfügbar sind (physische Register wurden den erwarteten Operanden zugewiesen, und funktionale Einheiten sind frei). Die von der Anweisung verwendeten Operanden werden aus der Registerdatei 311 gelesen, die in der Regel allgemeine Register (GPRs, General-Purpose Registers), Gleitkommazahlenregister (FPRs, Floating-Point Registers) und Bedingungsregister (CRs, Condition Registers) enthält. Die Anweisungen werden potenziell außerhalb der Reihenfolge in einer zugehörigen Hauptspeichereinheit 305, einer Funktionseinheit 307 oder einer Verzweigungseinheit 309 ausgeführt. Bei Abschluss der Verarbeitung werden die Ergebnisse der Anweisungen in die Registerdatei 311 eingetragen. Anweisungen in einer Verteilungstabelle 324, die darauf warten, dass die von den Anweisungen eingestellten physischen Register die Ausführung abschließen, werden benachrichtigt. Die Rücknahmewarteschlange 326 wird benachrichtigt, dass die Anweisungen die Ausführung abschließen und ob Ausnahmen (Exceptions) ausgelöst wurden. Abgeschlossene Anweisungen werden aus der Rücknahmewarteschlange 326 in der Programmreihenfolge entfernt (vom Kopf der Warteschlange). Bei der Rücknahme wird, wenn von einer Anweisung keine Ausnahmen ausgelöst wurden, die Zuordnungstabelle gemäß der Reihenfolge 328 aktualisiert, sodass die definierten Registernamen auf die physischen Register in der Registerdatei 311 zeigen, die die Ergebnisse aus der zurückgenommenen Anweisung enthalten; die vorherigen Registernahmen aus der Zuordnungstabelle gemäß der Reihenfolge 328 werden in die Warteschlange der freien Register 322 zurückgegeben.
  • Andererseits, wenn eine Anweisung eine Ausnahme ausgelöst hat, dann wird die Programmsteuerung auf die Adresse der Anweisung festgelegt, die aus der Rücknahmewarteschlange 326 zurückgenommen wird. Darüber hinaus wird die Rücknahmewarteschlange 326 geleert (gelöscht), wodurch alle nicht zurückgenommenen Anweisungen storniert werden. Weiterhin wird die Registerzuordnungstabelle 320 auf die Inhalte der Zuordnungstabelle gemäß der Reihenfolge 328 eingestellt, und jedes Register, das nicht in der Zuordnungstabelle gemäß der Reihenfolge 328 ist, wird der Warteschlange der freien Register 322 hinzugefügt.
  • Ein herkömmlicher superskalarer Prozessor, der die Neuanordnung der Ladeanweisungen bezüglich der vorhergehenden Ladeanweisungen (wie in 3 dargestellt) unterstützt, kann durch Folgendes erweitert werden:
    • 1. Einen Mechanismus zum Markieren von Ladeanweisungen, die außerhalb der Reihe abgesetzt werden, bezüglich der vorhergehenden Ladeanweisungen;
    • 2. Einen Mechanismus zur Nummerierung der Anweisungen bei deren Abruf, und zum Bestimmen, ob eine Anweisung früher oder später im Anweisungsstrom aufgetreten ist. Ein alternativer Mechanismus kann an dieser Stelle verwendet werden, um zu bestimmen, ob eine Anweisung früher oder später bezüglich einer anderen Anweisung auftrat;
    • 3. Einen Mechanismus zum Speichern von Informationen über Ladeoperationen, die außerhalb der Reihenfolge durchgeführt wurden, einschließlich deren Adresse in der Programmreihenfolge, der Zugriffsadresse und den für die größte garantierte atomare Einheit mit dem geladenen Datum gelesenen Datumswert;
    • 4. Einen Mechanismus zum Durchführen eines Interferenztests, wenn eine Ladeanweisung in der Reihenfolge bezüglich einer oder mehrerer Ladeanweisungen außerhalb der Reihenfolge ausgeführt wird, und zum Durchführen einer Prioritätskodierung, wenn mehrere Anweisungen mit der Ladeoperation in Konflikt stehen;
    • 5. Einen Mechanismus zum Umgehen des Datums, das einer einen Konflikt verursachenden Ladeoperation zugeordnet ist; und
    • 6. Einen Mechanismus zum Löschen des in Schritt (3) generierten Datensatzes an dem Punkt, an dem der Out-of-Order-Zustand aus der Rücknahmeschlange 326 in die Registerdatei 311 in der Programmreihenfolge zurückgenommen wird.
  • Die in US 6189088 beschriebenen Mechanismen werden in Verbindung mit Mechanismen wie folgt verwendet, die in einem in 3 dargestellten herkömmlichen Out-of-Order-Prozessor verfügbar sind. Jede Anweisung wird mit einer Anweisungsnummer nummeriert, wenn sie in die Anweisungsschlange 303 aufgenommen wird. Eine Ladeanweisung kann von einer Verteilungstabelle 324 früher als eine vorhergehende Ladeanweisung verteilt werden. Eine solche Ladeanweisung wird im Folgenden als eine 'Out-of-Order'-Ladeanweisung bezeichnet. In diesem Fall wird der Eintrag in der Rücknahmewarteschlange 326, der der Ladeanweisung entspricht, als eine Out-of-Order-Ladeoperation markiert.
  • Das Erfassen des Verteilens einer Out-of-Order-Ladeoperation aus der Verteilungstabelle 324 in eine Hauptspeichereinheit 305 zur Ausführung wird vorzugsweise mit zwei Zählern verwirklicht, einem „Zähler der abgerufenen Ladeoperationen” und einen „Zähler der verteilten Ladeoperationen”. Der Zähler der abgerufenen Ladeoperationen wird erhöht, wenn eine Ladeoperation in die Verteilungstabelle 324 eingefügt wird. Der Zähler der verteilten Ladeoperationen wird erhöht, wenn eine Ladeoperation an die Hauptspeichereinheit 305 zur Ausführung gesendet wird. Die aktuellen Inhalte des Zählers der abgerufenen Ladeoperationen wird der Ladeanweisung angehängt, wenn die Ladeanweisung zur Verteilungstabelle 324 hinzugefügt wird.
  • Wenn die Ladeanweisung aus der Verteilungstabelle 324 in einer Hauptspeichereinheit 305 zur Ausführung verteilt wird, wenn der an die Ladeanweisung angehängte Wert in der Verteilungstabelle 324 sich von den Inhalten des Zählers der verteilten Ladeoperationen zu diesem Zeitpunkt unterscheidet, dann wird die Ladenanweisung als eine Out-of-Order-Ladeanweisung identifiziert. Man beachte, dass die Differenz zwischen den zwei Zählerwerten der exakten Zahl von Ladeoperationen entspricht bezüglich der die Ladeoperation außerhalb der Reihenfolge abgesetzt wird. Out-of-order-Ladeanweisungen werden nur in eine Hauptspeichereinheit 305 verteilt, wenn Speicherplatz zum Hinzufügen von Einträgen in einer Tabelle für die Ladereihenfolge verfügbar ist.
  • Die Tabelle für die Ladereihenfolge ist eine einzelne Tabelle, auf die von allen Hauptspeichereinheiten 305 gleichzeitig zugegriffen wird (d. h., nur eine einzelne logische Kopie wird beibehalten, obwohl mehrere physische Kopien beibehalten werden können, um die Verarbeitung zu beschleunigen). Man beachte, dass wenn mehrere physische Kopien verwendet werden, die logischen Inhalte der mehreren Kopien dann immer denselben Status für alle Hauptspeichereinheiten 305 widerspiegeln müssen.
  • Für jede abgesetzte Ladeoperation werden die Anweisungsnummer der ausgeführten Anweisung und die Tatsache, ob eine Anweisung spekulativ ausgeführt wird, einer Speichereinheit 305 kommuniziert.
  • Eine Befehlsatzarchitektur (ISA, Instruction Set Architecture), die von einem Prozessor implementiert wurde, definiert in der Regel eine feste Anzahl an zugreifbaren architekturbestimmten allgemeinen Registern basierend auf Registerfeldern von IAS-Anweisungen. In Prozessoren mit Out-of-Order-Ausführung werden Umbenennungsregister zugewiesen, um die Registerergebnisse von spekulativ ausgeführten Anweisungen zu enthalten. Der Wert des Umbenennungsregisters wird als architekturbestimmten Registerwert festgeschrieben, wenn die zugeordnete Ausführung der spekulativen Anweisung „festgeschrieben” oder „abgeschlossen wird. Somit liegen zu einem beliebigen Zeitpunkt und wie von einem auf einem Prozessor ausgeführten Programm beobachtet in einer Registerumbenennungs-Ausführungsform viel mehr Umbenennungsregister als architekturbestimmten Register vor.
  • In einer Ausführungsform der Umbenennungsregister werden getrennte Register den architekturbestimmten Registern und den Umbenennungsregistern zugeordnet. In einer weiteren Ausführungsform sind die Umbenennungsregister und die architekturbestimmten Register zusammengeführte Register. Zu den zusammengeführten Registern gehört ein Tag (Kennzeichner) zur Angabe 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 architekturbestimmten Register ist.
  • In einer Ausführungsform mit einem zusammengeführten Register werden im Rahmen der Initialisierung (zum Beispiel während eines Kontextwechsels oder bei der Initialisierung einer Partition) die ersten n physischen Register als die architekturbestimmten Register zugewiesen, wobei n die Anzahl der Register ist, die durch die Befehlssatzarchitektur (ISA) deklariert werden. Diese Register müssen auf Zustand „architekturbestimmtes Register” (AR, Architectural Register) eingestellt werden; die restlichen physischen Register übernehmen den verfügbaren Zustand. Wenn eine abgesetzte Anweisung ein Zielregister enthält, ist ein neuer Umbenennungspuffer erforderlich. Aus diesem Grund wird ein physisches Register aus dem Pool verfügbarer Register ausgewählt und dem Zielregister zugewiesen. Dementsprechend wird der ausgewählte Registerzustand auf den Zustand „Umbenennungspuffer ungültig” (NV, Not Valid) gesetzt, und das Gültigkeitsbit wird zurückgesetzt. Nachdem die zugehörige Anweisung die Ausführung beendet hat, wird das erzeugte Ergebnis in das ausgewählte Register geschrieben, das Gültigkeitsbit wird eingestellt und der Zustand wird in „Umbenennungspuffer gültig” (RB, Rename Buffer) geändert. Später, wenn die zugehörige Anweisung abgeschlossen wird, wird der zugeordnete Umbenennungspuffer als das architekturbestimmte Register deklariert, dass das in der gerade abgeschlossenen Anweisung angegebene Zielregister implementiert. Der Zustand ändert sich daher dann in den Zustand „architekturbestimmtes Register” (AR).
  • Während Register eine nahezu universelle Lösung für die Leistungsaspekte darstellen, haben sie einen Nachteil. Die verschiedenen Teile eines Computerprogramms nutzen jeweils ihre eigenen temporären Werte und kämpfen daher um die Nutzung der Register. Da ein gutes Verständnis der Natur des Programmablaufes zur Ausführungszeit sehr schwierig ist, ist es für Entwickler nicht einfach vorab abzuschätzen, wie viele Register sie verwenden sollen und wie viele sie für andere Teile des Programms übrig lassen sollen. Im Allgemeinen werden diese Arten von Überlegungen ignoriert und die Entwickler und noch wahrscheinlicher die von ihnen verwendeten Compiler versuchen alle Register zu verwenden, die für sie sichtbar sind. Im Falle von Prozessoren, die mit sehr wenigen Registern beginnen, ist dies die einzige vernünftige Verfahrensweise.
  • Registerfenster sind ein Mittel zur Behebung dieses Problems. Da jeder Programmteil Register für die eigene Nutzung belegen möchte, werden mehrere Gruppen von Registern für verschiedene Programmteile bereitgestellt. Wenn die Register angezeigt werden, würde um noch mehr Register gekämpft werden, d. h., sie müssen ausgeblendet werden.
  • Das Ausblenden der Register kann auf effiziente Weise implementiert werden. Die CPU erkennt das Verschieben von einem Programmteil in ein anderes während einer Prozeduraufrufs. Dies wird mit einer kleinen Zahl an Anweisungen verwirklicht (Prolog) und endet mit einem ähnlich kleinen Satz (Epilog). Im Berkeley-Design würden diese Aufrufe dazu führen, dass an diesem Punkt ein neuer Satz an Registern „eingelagert” (swapped in) oder am Ende des Aufrufs als „tot” (oder „wiederverwendbar”) markiert wird.
  • Prozessoren wie PowerPC speichern den Status in vordefinierten und reservierten Maschinenregistern. Wenn eine Ausführung eintritt, während der Prozessor bereits die Inhalte des aktuellen Fensters nutzt, um eine weitere Ausnahme zu verarbeiten, erzeugt der Prozessor in dieser Situation einen doppelten Fehler.
  • In einer beispielhaften RISC-Ausführungsform sind für das Programm nur acht Register von insgesamt 64 sichtbar. Der komplette Satz an Registern wird als Registerdatei bezeichnet, und jeder Satz von acht als ein Fenster. Die Datei ermöglicht, dass bis zu acht Prozeduraufrufe ihre eigenen Registersätze haben. Solange das Programm keine Aufrufketten von über acht Aufrufe tief aufruft, müssen die Register nie geleert werden, d. h., in den Hauptspeicher oder den Cache weggeschrieben werden, was im Vergleich zu dem Zugriff auf die Register ein langsamer Prozess ist. Für viele Programm ist eine Kette von sechs Aufrufen das tiefste, was ein Programm ausführt.
  • Im Vergleich dazu sind in einer anderen Architektur vier Sätze von jeweils acht Registern gleichzeitig sichtbar. Drei Sätze der acht Register werden in Form von „Fenstern” dargestellt. Acht Register (i0 bis i7) bilden die Eingaberegister für die aktuelle Prozedurenebene. Acht Register (L0 bis L7) sind für die aktuelle Prozedurenebene lokal, und acht Register (o0 bis o7) sind die Ausgaben der aktuellen Prozedurenebene für die nächste aufgerufene Ebene. Bei einem Prozeduraufruf wird das Registerfenster um 16 Register versetzt, wodurch die alten Eingaberegister und die alten lokalen Register ausgeblendet werden und die alten Ausgaberegister zu den neuen Eingaberegistern werden. Die gemeinsamen Register (alte Ausgaberegister und neue Eingaberegister) werden zur Parameterübergabe verwendet. Letztlich sind acht Register (g0 bis g7) global auf allen Prozedurenebenen sichtbar.
  • Ein verbessertes Design weist den Fenstern eine variable Größe zu, was bei der Nutzung im allgemeinen Fall vorteilhaft ist, wenn weniger als acht Register für einen Aufruf benötigt werden. Ebenso werden die Register in einen globalen Satz von 64 und einem weiteren von 128 für die Fenster getrennt.
  • Registerfenster bieten auch einen einfachen Aktualisierungspfad. Da die weiteren Register für die Programme nicht sichtbar sind, können jederzeit weitere Fenster erstellt werden. Zum Beispiel führt der Einsatz der objektorientierten Programmierung oftmals zu einer höheren Anzahl an „kleineren” Aufrufen, die durch Erhöhen der Fenster von acht auf 16 beispielsweise berücksichtigt werden kann. Das Endergebnis sind weniger Leer- und Fülloperationen für langsame Registerfenster, das ein Überlauf der Registerfenster weniger häufig vorkommt.
  • Implementierungen der Out-of-Order-Anweisungen von ISA(Instruction Set Architecture)-Prozessoren können architekturbestimmten Anweisungen direkt oder mithilfe von Firmware ausführen, die durch eine Hardwareeinheit zum Dekodieren der Anweisungen aufgerufen wird. Viele Prozessoren teilen („crack”) jedoch definierte Anweisungen in Mikro-Ops auf, die auf die Hardwareeinheiten im Prozessor ausgerichtet sind. Darüber hinaus kann ein Prozessor mit einer CISC(Complex Instruction Set Computer)-Architektur CISC-Anweisungen in Anweisungen der RISC(Reduced Instruction Set Computer)-Architektur übersetzen. Um Aspekte der Erfindung zu vermitteln, werden ISA-Maschinenanweisungen beschrieben, und interne Operationen (Iops) können intern als ISA-Maschinenanweisung bereitgestellt werden, oder als kleinere Einheiten (Mikro-Ops) oder Mikrocode oder durch ein beliebiges anderes in der Technik bekanntes Mittel, und sie werden hier immer noch als Maschinenanweisungen bezeichnet. Maschinenanweisungen einer ISA verfügen über ein Format und eine Funktion gemäß der ISA-Definition, sobald die ISA-Maschinenanweisung abgerufen und dekodiert wird, kann sie in Iops umgewandelt werden, die im Prozessor verwendet werden können.
  • Viele moderne Prozessoren verwenden sehr viele physische Register und einen Registerumbenennungsansatz, um die architekturbestimmten Register einem großen Satz an physischen Registern zuzuordnen. Viele Werte in den Registern werden länger aufbewahrt als dies notwendig ist, wobei Prozessoren nicht wissen, wann ein Register seinen Wert nicht mehr behalten muss. Das Aufbewahren nicht benötigter Werte in der physischen Registerdatei senkt die Anzahl der im Pool verfügbaren Register, was eine negative Auswirkung auf die Effizienz des Compilers hat und zu einer weniger aggressiven Out-of-Order-Ausführung, einer geringeren Prozessorleistung, erhöhtem Strom- und Energieverbrauch und der erhöhten Anfälligkeit einer Transaktion für „nichtkritische” Fehler (Soft Errors) aufgrund der längeren Ausführungszeit führt. Darüber hinaus ermöglichen mehr verfügbare Register eine bessere Leistung für die Ausführung mehrerer Threads und für mehrere Partitionen, was eine bessere Plattform für die Virtualisierung bietet, um Cloud-Computing-Umgebungen zu ermöglichen. Zu guter Letzt erhöhen nicht benötigte Werte die Anzahl der verwundbaren Daten, die vorübergehende Fehler erleiden können, die entweder korrigiert werden müssen oder eine Maschinentestangabe auslösen, um eine Anwendung, Partition oder System herunterzufahren und so die Weitergabe der beschädigten Daten zu vermeiden.
  • Im Falle von Multithread-Prozessoren kann ein Prozessor einen Thread dann abschließen, wenn alle persistenten Daten im Hauptspeicher gespeichert sind und wenige (wenn überhaupt) Register Werte enthalten können, die in Zukunft benötigt werden. An diesem Punkt können die definierten Register, die dem Thread zugewiesen sind, an den Pool zurückgegeben werden können, wenn der Prozessor weiß, dass nicht mehr auf sie zugegriffen wird.
  • Gemäß einem Aspekt der Erfindung kann ein architekturbestimmten Register „nicht zugeordnet” sein, wenn angegeben wird, dass sein Wert nicht mehr verwendet wird. Wenn daher eine Anweisung angibt, dass eine letzte Referenz auf einen Zustand, der einen Speicherort enthält, aufgetreten ist oder gerade auftritt, wird die Zuordnung des physischen Registers zum architekturbestimmten Register aufgehoben, und es wird in den Pool der verfügbaren Register zurückgegeben. In einer Ausführungsform werden Mechanismen verwendet, um Anweisungen abzurufen, Anweisungen außerhalb der Reihenfolge abzusetzen, einschließlich der Fähigkeit, Abhängigkeiten zwischen den Anweisungen zu entdecken, die von einer Anweisung verwendeten Register umzubenennen, die Verfügbarkeit der von einer Anweisung verwendeten Ressourcen zu erfassen und die Zuordnung eines Registers zu entfernen, das als „letztmals verwendet” gekennzeichnet wurde, und in einer Ausführungsform wird der Inhalt als nicht verfügbar gesetzt, um den Out-of-Order-Zustand des Prozessors beizubehalten, der die Auswirkungen der Anweisungen bei deren Ausführung (außerhalb der Reihenfolge bzw. Out-of-Order) widerspiegelt, um Anweisungen gemäß der Programmreihenfolge zurückzunehmen und gleichzeitig den Zustand, der die Reihenfolge berücksichtigt, mit den Auswirkungen der zurückzunehmenden Anweisung zu aktualisieren und um eine Anweisung in der Programmreihenfolge zurückzunehmen, ohne den Zustand, der die Reihenfolge berücksichtigt, zu aktualisieren (was effektiv die Auswirkungen der zurückzunehmenden Anweisung storniert) und um die Programmausführung in der Reihenfolge ausgehend von der zurückgenommenen Anweisung (was die Stornierung aller bestehenden Auswirkungen im Out-of-Order-Zustand impliziert) wiederaufzunehmen Heutzutage müssen Mikroprozessoren alle Werte berechnen und verwalten, die als vom Anweisungsstrom berechnet beschrieben werden, bis der Wert überschrieben wird.
  • Viele moderne Prozessoren verwenden einen Registerumbenennungsansatz, um architekturbestimmten Register einem großen Satz physischer Register zuzuweisen.
  • Werden nicht benötigte Werte länger in Registern aufbewahrt als erforderlich, hat dies erhebliche Auswirkungen, was zu einem Verlust der Zuverlässigkeit (RAS, Loss of Reliability), Leistung sowie höherem Strom- und Energieverbrauch führt.
  • Computer verfügen in der Regel über ein Betriebssystem (OS, Operating System) und ein oder mehrere Anwendungsprogramme, die auf einem oder mehreren Prozessoren ausgeführt werden. Das OS verwaltet Ressourcen und stellt eine Anwendungsschnittstelle für Anwendungsprogramme für den Ressourcenzugriff bereit. Das OS wird in der Regel mit erster Autorität auf den Prozessoren ausgeführt. Das OS ermöglicht Anwendungen für eine bestimmte Zeit die Ausführung auf dem Prozessor, wodurch der Prozessor einen Kontextwechsel von den dem OS bereitgestellten Ressourcen zu den von dem Anwendungsprogramm bereitgestellten Ressourcen durchzuführen veranlasst wird. An einem Punkt tritt ein weiterer Kontextwechsel vom Anwendungsprogramm auf das OS auf, zum Beispiel aufgrund eines Fehlers, auf den das Anwendungsprogramm stieß oder aufgrund eines Aufrufs des OS durch das Anwendungsprogramm.
  • Der architekturbestimmten Zustand (Kontext) eines Threads, eines Prozesses und eines Prozessors beinhaltet Register und Speicherwerte, die durch die Architektur definiert sind und jeweils jedem Thread, Prozess oder Prozessor zugeordnet sind. Folglich muss die Software bei einem Kontextwechsel immer den gesamten Zustand speichern und wiederherstellen, der dem Thread, Prozess oder Prozessor zugeordnet ist, und die Hardware muss aufwändige Register verwalten, um den nicht benötigten Zustand von Ressourcen zu verwalten, die andernfalls für eine Leistungsbeschleunigung zugeordnet werden können. Schließlich erhöht die Verwaltung eines nicht benötigten Zustands die Verwundbarkeit eines Systems gegenüber einzelner Störereignisse (d. h. nicht kritischen Fehlern bzw. Soft Errors), wodurch die Zuverlässigkeit sinkt, da der Zustand umfassender verwundbar wird, und die Fehlerrate proportional zur Anzahl der den Zustand aufweisenden Elemente skaliert, wobei das System bei Auftreten eines Fehlers immer annehmen muss, dass Benutzerdaten beschädigt wurden, was umfassende Korrektureinrichtungen erforderlich macht, oder dies auf Datenbeschädigungen hinweist, zum Beispiel bei einer Maschinentest-Stoppoperation, was sich auf die Verfügbarkeit des Systems auswirkt.
  • Zustandsinformationen in einem Computersystem beinhalten in der Regel einen Programmzählerwert (die Speicheradresse der nächsten auszuführenden Anweisung), definierte allgemeine Registerwerte (in einer Beispielarchitektur 16 × 64 Bit Register, z. B. in anderen Beispielarchitekturen 64 × 64 Bit Register), definierte Gieitkommazahlenregister (z. B. in einem Beispiel 32 × 128 Bit Registers) und andere für ein Programm verfügbare Register (wie IBM zArchitecture-Zugriffsregister). Zum weiteren Kontext können Bedingungscodes gehören, die Informationen über das Ergebnis einer zuvor ausgeführten Anweisung angeben.
  • Wenn beispielsweise ein Betriebssystem in einem Prozessor aufgerufen wird, der eine Anwendung ausführt, wird der Kontext der Anwendung gespeichert (zum Beispiel im Hauptspeicher), wobei der Programmzähler auf die nächste auszuführende Anweisung und die bis dato durch das Anwendungsprogramm berechnete Registerwerte zeigt, sodass bei einer späteren Wiederaufnahme der Ausführung des Anwendungsprogramms der Programmzähler wiederhergestellt werden kann, sodass die Ausführung der Anwendung mit der nächsten Anweisung mit den zuvor berechneten Registerwerten wieder gestartet werden kann.
  • Im Stand der Technik können Computerbefehlssatz-Architekturen (ISAs), die eine feste Anzahl an Ressourcen (allgemeine Register zum Beispiel) und Anweisungen bereitstellen, eine der Ressourcen explizit oder implizit als adressierbare Entität angeben. Bei einer ISA, in der 32 allgemeine Register angegeben sind, müssten die ISA ausführenden Prozessoren immer den Kontext eines jeden der 32 Register beibehalten. In einer Ausführungsform ist nur eine Teilmenge der angegebenen Ressource (32 Register) aktiviert, um einem Prozessor die Nutzung der Tatsache zu erlauben, dass der Kontext nur für die aktivierten Ressourcen (Register) verwaltet werden muss. Somit kann der Wert der aktivierten Ressource, wenn zum Beispiel eine aktivierte Ressource deaktiviert wird, verworfen anstatt gespeichert werden. Jeder Zugriff auf eine deaktivierte Ressource gibt vorzugsweise einen architekturbedingten Wert oder eine Bedingung anstelle eines zuletzt in der Ressource gespeicherten Werts zurück.
  • In einer Ausführungsform können Anweisungen die letzte bzw. letztmalige Verwendung eines Registers angeben, wodurch das Register in einen deaktivierten Zustand gebracht wird. In einer Ausführungsform wird ein Register in einem deaktivierten Zustand in einen aktivierten Zustand geändert, indem eine Anweisung im Register gespeichert wird. In einer Ausführungsform kann eine Anweisung Register angeben, die in von einer anderen Anweisung in einen deaktivierten Zustand gesetzt werden müssen. Zum Beispiel kann eine Präfixanweisung ein Register (oder eine Gruppe von Registern) angeben, die in der nächsten sequenziellen Anweisung, in einer späteren oder sogar in einer früheren Anweisung in der Programmreihenfolge zuletzt verwendet werden. In einer Ausführungsform kann eine Anweisung Register angeben, die von einer anderen Anweisung in einen aktivierten Zustand gesetzt werden müssen. Zum Beispiel kann eine Präfixanweisung ein Register (oder eine Gruppe von Registern) angeben, das in der nächsten sequenziellen Anweisung, in einer späteren oder sogar in einer vorhergehenden Anweisung in der Programmreihenfolge in einen aktivierten Zustand gesetzt wird.
  • Levy schlägt Anweisungen vor, mit der die letzte Verwendung eines Umbenennungsregister angegeben wird. Wie hinlänglich bekannt ist, ist ein Umbenennungsregister eine spekulative Form eines definierten Registers, das temporär Operanden für nicht abgeschlossene Anweisungen enthält. Levy schweigt sich dazu aus, wie ein Ereignis gehandhabt werden soll, wenn eine spekulative Anweisung tatsächlich abgeschlossen wird, bei der das Umbenennungsregister invalidiert wurde und an den Pool verfügbarer physischer Register zurückgegeben wurde, oder wie Umbenennungsregister in beliebiger Weise an Kontextwechseln beteiligt sein können. Weiterhin sind Umbenennungsregister keine definierten Register, es handelt sich um spekulative Register, die bei einem Kontextwechsel weder gespeichert noch wiederhergestellt werden. Umbenennungsregister sind für Compiler und Programme nicht sichtbar. Ausführungsformen behandeln die definierten Ressourcen einschließlich allgemeiner Register, die für Compiler und Programmierer sichtbar sind. Die Ausführungsformen beinhalten, wie Kontextwechsel, die Fehlererfassung und verschieden Zugriffe auf nicht zugewiesene definierte Operanden (Register) gehandhabt werden.
  • Compiler (und Programmierer) verstehen, wenn sie einen Wert nicht mehr benötigen. Bereitgestellt wird eine Möglichkeit, die bekannten Programmentwicklungsinformationen und Informationen bei der Kompilierung einem Mikroprozessor so zu kommunizieren, dass der Mikroprozessor weiß, dass die Werte nicht mehr benötigt werden, dass zum Beispiel auf einen Operandenwert in einem Register nicht mehr von zukünftigen Anweisungen zugegriffen wird, sodass das Register in einen deaktivierten Zustand gesetzt werden und der Inhalt vom Prozessor verworfen oder ignoriert werden kann. Eine solche Bedingung kann zum Beispiel vorliegen, wenn eine Anweisung ein Ergebnis und einen Bedingungscode speichert, wobei auf die Anweisung eine Verzweigungsanweisung zum Verzweigen basierend auf dem Bedingungscode folgt. Die Anweisung ist eine allgemeine Anweisung, und der gespeichert Wert wird in anderen Verwendungen benötigt. In dieser Verwendung der allgemeinen Anweisung ist jedoch nur der Bedingungscode erforderlich, und auf das gespeicherte Ergebnis wird nicht von einer zukünftigen Anweisung zugegriffen.
  • Ein Beispiel einer Prozessor-Pipeline weist auf:
    • 1. Einen Mechanismus zum Abrufen von Anweisungen;
    • 2. Einen Mechanismus zum Absetzen abgerufener Anweisungen außerhalb der Reihenfolge, einschließlich der Fähigkeit, Abhängigkeiten zwischen den Anweisungen zu erkennen, die von einer Anweisung verwendeten Register umzubenennen und die Verfügbarkeit der von einer Anweisung verwendeten Ressourcen zu erfassen;
    • 3. Einen Mechanismus zum Beibehalten des Out-of-Order-Zustands des Prozessors, der die Auswirkungen der Anweisungen bei der Ausführung (außerhalb der Reihenfolge bzw. Out-of-Order) widerspiegelt;
    • 4. Einen Mechanismus zur Zurücknahme von Anweisungen in der Programmreihenfolge, der gleichzeitig den Zustand gemäß der Reihenfolge mit den Auswirkungen der zurückzunehmenden Anweisung aktualisiert; und
    • 5. Einen Mechanismus zur Zurücknahme einer Anweisung gemäß der Programmreihenfolge, ohne den Zustand gemäß der Reihenfolge zu aktualisieren (was effektiv die Auswirkungen der zurückzunehmenden Anweisung storniert) und zur Wiederaufnahme der Ausführung gemäß der Reihenfolge des Programms ab der zurückzunehmenden Anweisung (was das Stornieren aller im Out-of-Order Zustand bestehenden Auswirkungen impliziert).
  • Eine durch einen Prozessor implementierte Architektur mit einer Registerumbenennung kann wenigstens physische Register, Zuweisungslogik (wie eine Zuordnungstabelle) zum Zuordnen von architekturbestimmten Registern an physische Register und einen architekturbestimmten Satz an definierten Registern aufweisen. architekturbestimmte Register werden in Entsprechung zu den physischen Registern zugewiesen und diese Entsprechungsinformation wird in der Zuordnungslogik beibehalten. In Aspekten der vorliegenden Erfindung kann ein architekturbestimmtes Register für die letzte Verwendung angegeben werden, nach der das Register in der Architektur deaktiviert wird, sodass in einem Registerumbenennungsprozessor, wenn einem architekturbestimmten Register ein neues physisches Register zugewiesen bzw. die Zuweisung entfernt wird, die Zuordnungstabelle aktualisiert wird, um widerzuspiegeln, ob das architekturbestimmte Register aktiviert oder deaktiviert ist.
  • In einer Ausführungsform verwendet ein Umbenennungsprozessor Informationen für die letzte Verwendung eines Werts im architekturbestimmten Register. Nachdem ein Wert in einem Register als zum letzten Mal verwendet bestimmt wird, wird die Zuordnung des physischen Registers zum architekturbestimmten Register aufgehoben, und es wird in den Pool der verfügbaren Register zurückgegeben.
  • In einer Ausführungsform, wenn eine Lesereferenz zu einem nicht zugeordneten architekturbestimmten Register erfolgt, d. h., einem Register, das zum letzten Mal verwendet wurde, dessen „letztmalige Verwendung” angegeben wurde, wird ein Standardwert zurückgegeben, beispielsweise entweder ein vordefinierter Wert (zum Beispiel nur 1en oder nur 0en), ein Register, von dem bekannt ist, dass es den Standardwert enthält, oder eine dekodierte Anweisungskennung, die den Leseprozess der physischen Registerdatei anweist, dass ein Standardwert generiert wird, wenn der Indikator vorhanden ist.
  • Wenn in einer Ausführungsform eine Schreibreferenz auf ein nicht zugeordnetes Register erfolgt, d. h., einem Register, dessen „letztmalige Verwendung” angegeben wurde und für das die letzte Verwendung durchgeführt wurde, wird dem architekturbestimmten Register ein neues physisches Register zugewiesen.
  • In einer Ausführungsform werden mehrere Register wieder in den Pool der freien physischen Register freigegeben. Dies entspricht der Tatsache, dass eine größere Menge an physischen Registern vorliegt. Wenn mehr physische Register auf einer Freiliste verfügbar gemacht werden, kann dadurch eine aggressivere Ausführung außerhalb der Reihenfolge erfolgen. Dies ist für eine effizientere Registerzuweisung und im Besonderen in Multithread-Architekturen vorteilhaft, in denen ein Satz an definierten Registern dynamisch den physischen Registern zugewiesen wird. Die Prozessorzuverlässigkeit wird verbessert, währen unkritische Fehler, die in den freien (oder freigegebenen) Registern auftreten, die Korrektheit der Berechnungen nicht beeinträchtigen. Für Fachleute ist verständlich, dass kein konkretes Risiko eines Datenverlusts besteht, da der Wert nicht mehr benötigt wird.
  • In einem Beispiel werden die folgenden Anweisungen ausgeführt.
    LR R2, Rb
    AR R2, Rc
    LR R3, Ra
    ARU R3, Rc /* letzte Verwendung von Rc */
    MRU R2, Ra /* letzte Verwendung von Ra */ (unkritischer Fehler Rc)
    MRU R3, Rb /* letzte Verwendung von Rb */
    AR R2, R3

    „LR R2, Rb” lädt Inhalte von Rb (Rb) in R2

    „AR R2, Rc” fügt (Rc) zu (R2) hinzu

    ”LR R3, Ra” lädt (Ra) in (R3)
  • „ARU R3, Rc” fügt (Rc) zu (R3) hinzu (identisch mit „AR R3 Rc”), aber gibt dem Prozessor auch an, dass der Rc-Wert von der Anweisung zuletzt verwendet wird. Der Prozessor kann nach der letzten Verwendung die Bindung des architekturbestimmten Rc-Registers zu jedem beliebigen physischen Register entfernen. Jede zukünftige Schreiboperation in Rc instanziiert eine Bindung des architekturbestimmten Rc-Registers mit einem neuen physischen Register, wenn die Bindung entfernt wurde. Bis eine Schreiboperation in das architekturbestimmte Rc-Register durchgeführt wird, gibt jede Leseoperation beispielsweise entweder einen nicht definierten Wert, einen vordefinierten Wert (nur 1en oder nur 0en) oder einen vom Programm bestimmten Wert (aus einem für ein Programm verfügbaren Register) aus.
  • „MRU R2, Ra” multipliziert (R2) mit (Ra) (identisch mit „MR R2, Ra”, aber gibt dem Prozessor auch an, dass der Ra-Wert von der Anweisung zuletzt verwendet wird.
  • „MRU R3, Rb” multipliziert (R3) mit (Rb) (identisch mit „MR R3, Rb”, aber gibt dem Prozessor auch an, dass der Rb-Wert von der Anweisung zuletzt verwendet wird.
  • Wenn ein Register mit einer letztmaligen Verwendung eines Registers (d. h. (Ra) der Anweisung „MRU R2, Ra”) auf eine Ausnahme nach der letzten Verwendung (wie einen durch einen Vorababruf entdeckten unkritischen Fehler) trifft, kann der Fehler in einer Ausführungsform unterdrückt werden, da der Wert nicht mehr benötigt wird.
  • In einer Ausführungsform wird die Kommunikation der Information über die letzte Verwendung einem Mikroprozessor über Maschinenanweisungen bereitgestellt. Zum Beispiel werden die Semantiken in einem Befehlssatz bereitgestellt, mit denen ein Mikroprozessor auf effiziente Weise die Information zur letzten Verwendung verwendet, um die operativen Aspekte des Mikroprozessors zu verbessern und so die Zuverlässigkeit oder Leistung zu erhöhen oder den Stromverbrauch zu senken.
  • BEISPIEL A:
  • Anweisungen zur Berechnung a·(b+c) + b·(a+c):
    LR R2, Rb
    AR R2, Rc
    LR R3, Ra
    AR R3, Rc /* letzte Verwendung von Rc */
    MR R2, Ra /* letzte Verwendung von Ra */
    MR R3, Rb /* letzte Verwendung von Rb */
    AR R2, R3
  • In Beispiel A wird das Register R2 mit den Inhalten von Rb geladen, dann werden die Inhalte von Rc zu R2 hinzugefügt. Das Register (R3) wird mit (Ra) geladen, dann werden die Inhalte von Rc zu (R3) durch eine AR-Anweisung hinzugefügt. Dann wird (R2) mit (Ra) durch eine MR-Anweisung multipliziert. Dann wird (R3) mit (Rb) durch eine MR-Anweisung multipliziert. Schließlich wird (R3) zu (R2) hinzugefügt. Jede Anweisung mit einer letzten Verwendung eines Registerwerts wird durch die Kommentare /* letzte Verwendung von Rn */ angegeben.
  • BEISPIEL B:
    • LR R2, Rb
    • AR R2, Rc
    • LR R3, Ra
    • AR R3, Rc /* letzte Verwendung von Rc */
    • MR R2, Ra /* letzte Verwendung von Ra */ (unkritischer Fehler Rc)
    • MR R3, Rb /* letzte Verwendung von Rb */
    • AR R2, R3
  • Wenn in Beispiel B eine Datenbeschädigung für die Register Ra, Rb oder Rc (z. B. aufgrund eines Störereignisses durch einen unkritischen Fehler) auftritt, muss eine Wiederherstellungsaktion (Recovery Action) gestartet werden, die die Leistung beeinträchtigt (herabsetzt) und zusätzlichen Strom/Energie verbraucht. BEISPIEL B zeigt den Fall, in dem Daten aufgrund eines unkritischen Fehlers in Rc verlorengehen.
  • Wenn eine Datenbeschädigung, für die keine Wiederherstellung möglich ist, für die Register Ra, Rb oder Rc auftritt (z. B. im Verlauf eines Kontextwechsels des Betriebssystems), muss ein Maschinentest angegeben werden, und die Anwendung, die Partition oder sogar die gesamte Maschine müssen den Betrieb anhalten, was zu einem Verlust von Daten und der Verwendung der Maschine führt. Der Maschinentest tritt auf, obwohl in diesem Beispiel der Wert in Ra, Rb und Rc nicht mehr gebraucht wird, sodass kein konkretes Risiko besteht, dass Daten verlorengehen.
  • In einer Ausführungsform wird eine Angabe der letzten Verwendung eines Registerwerts an den für Ra, Rb und Rc (/* letzte Verwendung von Rn */) angegebenen Positionen bereitgestellt, und es resultieren keine negativen Folgen aus einer Ausnahme, die von einem Fehler verursacht wurde, der mit einem Registerwert in einer nachfolgenden Verwendung verknüpft ist, nachdem dieser das letzte Mal verwendet wurde. In BEISPIEL B wird Rc von der Anweisung AR als „letztmalige Verwendung” verwendet, aber im Folgenden wird ein Fehler erfasst (bei Ausführen der ersten MR-Anweisung). Da das Rc-Register als letzte Verwendung wie durch von der Anweisung angegeben verwendet wurde, kann der nachfolgende unkritische Fehler (eventuell ein Vorababruf durch eine nachfolgende Anweisung) ignoriert werden.
  • In einer Ausführungsform werden die Semantiken der Anweisung geändert, um die letztmalige Verwendung des Registers anzugeben. Zum Beispiel gibt das Hinzufügen eines Registers mit ARLU an, dass die zugrundeliegende Maschinenanweisung die letzte Verwendung des Quellenoperanden (Rc) im Unterschied zur AR-Semantik angibt, die keine letztmalige Verwendung eines Registers angibt.

    AR R2, Rc /* keine Angabe der letzten Verwendung */
    ARLU R2, Rc /* letzte Verwendung von Rc */
  • In einer Ausführungsform deaktiviert die ARLU-Anweisung das Register Rc. Im deaktivierten Zustand wird ein definierter Standardwert anstelle der in Rc von einer vorhergehenden Anweisung gespeicherten Inhalte zurückgegeben. Der Standardwert kann ein in der Architektur nicht definierter Wert sein (maschinenunabhängiger Wert) und jeder weitere Zugriff auf diese Ressource (Rc) kann einen in der Architektur nicht definierten Wert zurückgeben.
  • In wieder einer anderen Ausführungsform kann der beim Zugriff auf das deaktivierte Register Rc zurückgegebene Standardwert ein in der Architektur definierter Wert sein, wie ein beliebiger von nur 1en oder nur 0en, oder ein vom Programm bestimmter Wert (das Programm schreibt in ein Spezialregister, dessen Inhalt für Standardwerte verwendet wird).
  • In einer anderen Ausführungsform ist der Standardwert ein algorithmischer Wert wie eine Wertefolge, die von jedem nachfolgenden Lesevorgang zurückgegeben werden, sodass die beiden nachfolgenden Leseoperationen möglicherweise nicht denselben Standardwert zurückgeben. Die Sequenz kann zum Beispiel ein inkrementierter Wert, ein dekrementierter Wert oder ein anderer mit einem Algorithmus erstellter Wert sein.
  • Dies ist vor allem nützlich, um die Anforderung zu vermeiden, eine Wiederherstellung eines beschädigten Wertes durchzuführen.
  • BEISPIEL C:
  • Die optimierte Folge (wobei ARLU, MRLU anstelle von AR und MR verwendeten werden, um die letzte Verwendung anzugeben) lautet nun:
    LR R2, Rb
    AR R2, Rc
    LR R3, Ra
    ARLU R3, Rc /* letzte Verwendung von Rc */
    MRLU R2, Ra /* letzte Verwendung von Ra */
    MRLU R3, Rb /* letzte Verwendung von Rb */
    AR R2, R3
  • In BEISPIEL C ist kein Maschinentest oder eine Wiederherstellung erforderlich.
  • In einer Ausführungsform wird die Angabe der letzten Verwendung durch Opcode bereitgestellt. Für die Anweisung AR wird OpCode1 verwendet, aber für ARLU gibt OpCode2 dieselbe Funktion wie die Anweisung AR an, gibt aber das Quellregister (RS) als das zuletzt zu verwendende Register an.

    AR Rt, Rs
    OpCode1 Rt Rs

    ARLU Rt, Rs
    OpCode2 Rt Rs
  • Der Opcode kodiert, dass das Register Rs zu Rt hinzugefügt wird und das Register Rs das letzte von der Anweisung verwendete ist (und dann in einen deaktivierten Zustand gesetzt wird).

    L Rt, (RB, RD)
    OpCode1 Rt RB RD
  • Für Anweisungen mit zwei oder mehreren Registern muss beispielsweise angegeben werden, welches der Register zum letzten Mal verwendet wird, z. B. (LLLUB = RB, LLLUD = RD und LLLUt = Rt). In einer Ausführungsform gibt LLLUB Rt (RB, RD) die letzte Verwendung von RB an.
    OpCode2 Rt RB RD
  • Die Freigabe des Registers RB aus dem aktivierten Zustand wird in diesem Beispiel durch den Opcode2 angegeben, indem ein neuer dedizierter Codepunkt für den Opcode gewählt wird. Der Opcode2 kodiert, dass das Register RB zu RD hinzugefügt wird, dass von dieser Adresse Daten in Rt geladen werden und das RD-Register von dieser Anweisung letztmals verwendet wird.
    LLLUD Rt (RB, RD) *letzte Verwendung von RD
    OpCode3 Rt RB RD
  • Die Freigabe nach Verwendung des Registers RD wird in diesem Beispiel durch den Opcode3 angegeben, indem ein neuer dedizierter Codepunkt für den Opcode gewählt wird. Der Opcode3 kodiert, dass das Register RB zu RD hinzugefügt wird, von hier Adressdaten in Rt geladen werden und das RD-Register von dieser Anweisung letztmals verwendet wird.
  • Die Angabe der letzten Verwendung eines Registers, wenn mehr als ein letztmals verwendetes Register vorliegt, erfordert die Verwendung mehrerer Opcodes. Wenn mehrere Register das letzte Mal verwendet werden, sollte ein wieder anderer Opcode verwendet werden.
  • Dies wird noch deutlicher, wenn mehrere Register „letztmals verwendet” werden müssen. In einer Ausführungsform wird die letztmalige Verwendung mehrerer Register durch die Verwendung von Registermaskenbit in einem Anweisungsfeld angegeben.
  • Zum Beispiel besitzt eine Anweisung LLU Rt (RB, RD) M, M über ein Maskenfeld MM.
    OpCode MM Rt RB RD
  • Die Freigabe der von der MM-Maske definierten Register wird in Opcode beschrieben, indem ein neuer dedizierter Codepunkt für den Opcode gewählt wird. Der Opcode gibt die durchzuführende Operation an, zum Beispiel, dass das Register RB zu RD hinzugefügt wird und die Ergebnisdaten in Rt geladen werden. Darüber hinaus werden die Maskenbit MM verwendet, die jeweils die zukünftige Verwendung der Register RB, RD und Rt angeben. Die MM-Bit können Bit-signifikant sein, sodass jedes Bit mit einem entsprechenden Registeroperanden der letztmaligen Verwendung der Anweisung verknüpft ist oder einen Bereich der als letztmals verwendeten Register angeben kann.
  • Wenn in einer Ausführungsform die Register RB und/oder RD zum letzten Mal verwendet werden, werden Maskenbit eingestellt, um anzugeben, dass diese Register in einer Ausführungsform die letztmalige Verwendung darstellen. Die MM-Bit können dergestalt eine Kodierung sein, dass beispielsweise die Kodierung RB als letzte Verwendung (MM = 0) oder RB und auch RD als letzte Verwendung (MM = 1) angibt.
  • In einer Ausführungsform wird ein Flagbit der Anweisung der letztmaligen Verwendung zugeordnet, um anzugeben, dass das entsprechende Register das letzte Mal verwendet wird.
  • Zum Beispiel kann LLU Rt, (RB, RD) F, F durch eine Maschinenanweisung mit dem folgenden Format kodiert werden:
    OpCode Rt FB RB FD RD
  • Die letzte Verwendung der Register RB und RD ist durch den Opcode in Kombination mit den FB-, FD-Bit definiert (FB-Bit zugeordnet zu RB und FD zugeordnet zu RD), indem ein neuer dedizierter Codepunkt für den Opcode für die Anweisung mit letztmaliger Verwendung gewählt wird; wobei der Opcode kodiert, dass das Register RB zu RD hinzugefügt wird und diese Adressdaten in Rt geladen werden. Darüber hinaus werden die Flags (bzw. Markierungen) FB und FD verwendet, wobei jedes die zukünftige Verwendung der Register RB und RD angibt. Wenn die Register RB und/oder RD das letzte Mal verwendet werden, werden beide Flags FB und FD eingestellt, um anzugeben, dass diese Register die letztmalige Verwendung darstellen.
  • PRÄFIX-ANWEISUNGEN:
  • RISC-Befehlssätze bieten attraktive Eigenschaften zum Abruf von Anweisungen und der Dekodierung, wie eine Anweisungslänge in fester Breite, die die Verarbeitung von Ausnahmen, den Neustart von Anweisungen, die Änderung von Anweisungen bei der Ausführung und das Dekodieren und Gruppieren von Anweisungen vereinfachen. Befehlssätze in fester Breite begrenzen den Kodierspeicherplatz für jede Anweisung, begrenzen die Größe von Verschiebungen und beschränken die Einführung neuer Anweisungen, um neue Funktionen wie die relative Adressierung mit einem PC (Programmzähler bzw. Program Counter) zu bestehenden Anweisungen hinzuzufügen, denen diese Funktionalität fehlt. Ausgereifte CISC-Architekturen weisen eine ähnliche Beschränkung auf.
  • Es wurde vorgeschlagen, die Anweisungswörter in Anweisungsgruppen (wie dem Itanium-Befehlssatz) zu erweitern, einem Befehlssatz mit Anweisungen in einfacher Breite doppelt breite RISC-Anweisungen bereitzustellen und Optimierungen bei der Anweisungsdekodierung zu verwenden, um diese Einschränkungen zu überwinden. Jede der vorgeschlagenen Lösungen weist erhebliche Nachteile auf:
    Anweisungsgruppen beschränken die Adressierbarkeit einzelner Anweisungen, führen zu einer unerwünschten Aufblähung von Code und können nicht atomar in einem 54-Bit-Befehlssatz aktualisiert werden.
  • Doppelt breite RISC-Anweisungen können sich über Grenzen erstrecken und Komplikationen beim Abruf von Anweisungen und zugehörigen Ausnahmen hervorrufen, zu aufgeblähtem Code führen und müssen mit der Verzweigung in der Mitte einer Anweisung zurechtkommen (d. h. die Entdeckung von Anweisungsgrenzen wird problematisch).
  • Die Optimierung bei der Anweisungsdekodierung bietet Verfahren zur Kombination von Anweisungspaaren bei der Dekodierung in eine einzelne interne Anweisung (Iop). Die Optimierung bei der Anweisungsdekodierung überwindet einige der Beschränkungen anderer Lösungen, bietet aber nicht die Möglichkeit, eine zum Programmzähler relative Adressierung einzuführen, und kann zu der Anforderung führen, exzessive Berechnungen durchzuführen, um den definierten Zustand beizubehalten, der von Anweisungen berechnet wurde, die andernfalls von einer zusammengeführten internen Anweisung vollständig zusammengefasst werden.
  • Wir führen das Konzept der Präfixanweisungen (im Unterschied zu Anweisungspräfixen) ein, zum Beispiel eine Präfixanweisung (addpcis+), um einen bestehenden Befehlssatz zu erweitern, um zum Beispiel lange Verschiebungen oder Anweisungen relativ zum Programmzähler bereitzustellen, um die von diesen Merkmalen angebotenen Vorteile zu nutzen. Anweisungspräfixe verändern die Funktionalität einer nachfolgenden Anweisung. Dergestalt müssen Anweisungspräfixe immer mit der geänderten Anweisung ausgeführt werden, was de facto zu einer Anweisung mit einer sehr langen variablen Breite führt und damit einhergehende Komplexitäten aufweist. Der Grund liegt darin, dass eine eingreifende Operation wie ein Kontextwechsel zu einem Verlust der Präfixfunktion führen würde, wenn die mit einem Präfix versehene Anweisung ausgeführt wird (außer der Präfixzustand wurde beibehalten und bei Kontextwechseln wiederhergestellt). Dies kann für eine RISC-Befehlssatzarchitektur (ISA, Instruction Set Architecture) unattraktiv sein, da sowohl die ISA-Merkmale wie auch die ISA-Implementierungen optimiert wurden, um die von den RISC-ISAs mit fester Breite bereitgestellte Regelmäßigkeit zu nutzen.
  • In einer Ausführungsform wird ein Anweisungspräfix im Gegensatz zu einer Präfixanweisung verwendet. Ein Anweisungspräfix kann als eine Erweiterung einer Anweisung vorgestellt werden, sodass ein Anweisungspräfix auch als ein Anweisungssuffix implementiert werden könnte. Ein Anweisungspräfix für eine Anweisung würde vorzugsweise Informationen für die Anweisung angeben, der es vorangestellt wird. Es ist jedoch auch möglich, ein Präfix zu einer Anweisung hinzuzufügen, die Informationen für eine andere Anweisung als die, der es als Präfix dient, bereitstellt. Somit ist eine Präfixanweisung ein Präfix, das eigenständig ausgeführt wird, mit einem eigene Opcode-Feld, wohingegen eine Anweisungspräfix als Teil einer Anweisung ausgeführt wird, der es als Präfix vorangestellt ist, und es keine unabhängig ausführbare Anweisung ist.
  • In Ausführungsformen der Präfixe, die die letzte Verwendung eines Registers in einer nachfolgenden Anweisung angeben, gibt es zwei Optimierungsausführungsformen zur Handhabung der Präfixe, die die letzte Verwendung angeben, die ermöglichen, dass das Präfix von der Anweisung getrennt wird, für die die letzte Verwendung angegeben wird:
    • 1 – In einer ersten Ausführungsform wird das Präfix ignoriert und die Anweisung kann ohne Präfix und ohne die positiven Auswirkungen auf die Registerumbenennung ausgeführt werden (in einer Architekturspezifikation, in der die Angabe der letzten Verwendung angibt, dass ein zukünftiges Lesen des definierten Registers der letztmaligen Verwendung einen nicht definierten Wert zurückgibt). Wenngleich dies in einer Hochleistungsausführung nicht erstrebenswert sein kann, kann es in Modellen mit geringerer Leistung akzeptabel sein (entweder wohl durchdacht beim Design durch Erstellen eines günstigeren Modells, das über keine Hardware zur Verarbeitung dieses Präfix verfügt, oder sogar durch Marktsegmentierung und die bewusste Deaktivierung vorhandener Hardware, um ein Modell mit niedrigerer und eines mit höherer Leistung zu erstellen), oder wenn die Grenzbedingungen identifiziert sind (z. B. eine Ausnahme eintritt oder dem Zeilenpuffer die Anweisungsbyte ausgehen). Es kann einfacher sein, eine Maschine zu erstellen, die das Präfix in diesen Situationen verwirft, und wenn die ISA-Architektur angibt, dass Leseoperationen der Register mit letztmaliger Verwendung einen nicht definierten Wert zurückgeben, liegt die Rückgabe des konkreten Registerwerts sicherlich innerhalb der Implementierungsgrenzen.
    • 2 – In einer anderen Ausführungsform kann die Angabe der letztmaligen Verwendung in einem Programmzustandswort (PSW bzw. Program Status Word) oder einem Konfigurationsregister (CR bzw. Configuration Register) erfasst und bei Kontextwechseln wiederhergestellt werden und zum Neustart nach einer Ausnahme oder einem Kontextwechsel verwendet werden, und ein Präfix muss der ausstehenden Anweisung nach der Rückkehr von einer Ausnahme vorangestellt werden, z. B. mit einer speziellen Rückkehr von einer Interrupt-Anweisung.
  • Aufgrund von Beschränkungen bei verfügbaren Opcodes und der Länge der Anweisungen können weder weitere Opcode-Punkte noch Masken- oder Flagfelder verfügbar gemacht werden. Auch das Zuweisen eines neuen Formats zu jeder Anweisung kann hinsichtlich der Komplexität und des Kodierspeicherplatzes untragbar sein. In dem Fall wird eine Präfixanweisung bereitgestellt, bei deren Ausführung die letzte Verwendung der Register anderer Anweisungen kontrolliert wird. Eine solche Ausführung einer Präfixanweisung kann dazu führen, dass das RB der nächsten sequenziellen Anweisung nach der Ausführung deaktiviert wird. In einer Ausführungsform kann die Ausführung einer Präfixanweisung dazu führen, dass das RB der nächsten sequenziellen Anweisung (NSI bzw. Next Sequential Instruction) für die Verwendung durch NSI bei der Ausführung aktiviert wird und nach der Verwendung durch die NSI-Ausführung deaktiviert wird.
  • Gemäß den Aspekten der vorliegenden Erfindung ändert eine Präfixanweisung wenigstens einen Quellenoperanden R der nächsten sequenziellen Anweisung, sodass ein numerischer Wert, der durch die Präfixanweisung berechnet wird, als Eingabe für den angegebenen Operanden R dient. (Gemäß einer beispielhaften RISC-Ausführungsform entspricht der geänderte Operand R einem Register, einschließlich, ohne darauf beschränkt zu sein, einem oder mehreren Ganzzahlen-, allgemeinen, Bedingungs-, Prädikat-, Gleitkommazahlen-, Vektor- oder Multimediaregister(n).) Im Unterschied zu Anweisungspräfixen des Stands der Technik kann eine Präfixanweisung als eine den Zustand ändernde Anweisung eigenständig ausgeführt werden und ihre Semantik entspricht bei der Ausführung als Anweisung dem Verhalten des Präfixanweisungsverhaltens in einem von den Präfixanweisungen definierten Geltungsbereich, d. h., eine Präfixanweisung wird definiert, um nur die Eingabe R der nächsten sequenziellen Anweisung zu ändern und das tatsächliche R in einem nicht definierten oder von der Implementierung abhängigen definierten Zustand zu belassen. Wird die Präfixanweisung als eine Anweisung ausgeführt, hat ihr Verhalten (die Berechnung des Architekturwerts R) die gleiche Auswirkung auf die nächste sequenzielle Anweisung und alle nachfolgenden Anweisungen (ein Verhalten, das von einer Präfixanweisung nicht angegeben wird). Somit eröffnet eine Präfixanweisung eine breite Palette an Implementierungsmöglichkeiten. Gemäß einem anderen Aspekt einer Präfixanweisung und gemäß der Definition, die definierte Ressource (z. B. Register Rn) mit einem nicht definierten Wert nach Ausführung der nächsten sequenziellen Anweisung zu belassen, wird auch für die Ressource Rn als Ergebnis der Präfixanweisung angegeben, ihre letztmalige Verwendung in der nächsten sequenziellen Anweisung zuhaben. (Und in wenigstens einer beispielhaften Ausführungsform nutzt eine Implementierung eines Mikroprozessors, der Optimierungen der letztmaligen Verwendung in seiner Mikroarchitektur unterstützt, die Informationen zur letztmaligen Verwendung zur weiteren Steigerung der Leistung und Zuverlässigkeit, indem Registerdateien auf mehreren Ebenen, Registerumbenennungen und anderen Aspekte eines Mikroprozessors gemäß der Angabe der letztmaligen Verwendung, die der Präfixanweisung inhärent ist, verwaltet werden.)
  • Eine Präfixanweisung kann zweckmäßigerweise mit einer Anweisungsoptimierung bei der Dekodierung der Anweisung implementiert werden und ohne dass ein Wert R generiert werden muss, der zu einem definierten Ergebnis über die geänderte Anweisung hinaus kompatibel ist, z. B. wenn die Präfixanweisung mit einer Anweisung kombiniert werden kann und von der Anweisung bei der Anweisungsoptimierung im Rahmen der Dekodierung zusammengefasst werden kann, ist keine weitere Berechnung erforderlich, um einen in R zu speichernden Wert zu generieren. Die Optimierungslogik kann auch Bestimmungsschritte durchführen, um in bestimmten Situationen Optimierungen durchzuführen und in anderen nicht. Erfolgt keine Optimierung, kann eine Präfixanweisung konservativ als eigenständige Anweisung ausgeführt werden. Wenn bei einer Präfixanweisung und der geänderten Anweisung eine Ausnahme auftritt (z. B. da eine geänderte Anweisung sich auf der nächsten Seite befindet und ein Seitenfehler aufgrund dessen auftritt, dass die nächste Seite ausgelagert wurde und wieder eingelesen werden muss), kann eine Präfixanweisung als Anweisung ausgeführt werden, das Register R aktualisieren und die fehlerhafte Anweisungsadresse der geänderten Anweisung angeben. Nach dem Einlesen der nächsten Seite kann die Ausführung mit der nächsten Anweisung fortgesetzt werden, ohne dass die Präfixanweisung neu gestartet werden muss (dies bietet einen erheblichen Vorteil gegenüber der Komplexität, die bei der Verarbeitung von Anweisungspräfixen in CISC-Architekturen besteht). Bei einem anderen Aspekt des Neustarts einer Anweisung, kann eine Implementierung einige der Auswirkungen einer Präfixanweisung in einem speziellen Register (SPR, Special Purpose Register) zu speichern beabsichtigen und eine geänderte Anweisung neu starten, wobei der Zustand der Präfixanweisung von dem SPR beim Neustart erhalten wird, um die Präfixanweisung und die geänderte nächste sequenzielle Anweisung in einer einzigen Operation auszuführen. In einer anderen Ausführungsform unterdrückt jedes Ausnahmeereignis, das zwischen einer Präfixanweisung und der nächsten sequenziellen Anweisung stattfindet, den Neustart der Präfixanweisung, nachdem die Ausnahme verarbeitet wurde. In einer anderen Ausführungsform ist keine Ausnahme zwischen der Ausführung der Präfixanweisung und der nächsten sequenziellen Anweisung zugelassen.
  • In anderen Aspekten der Präfixanweisungen können kostengünstige Mikroprozessorimplementierungen mit geringer Komplexität gemäß der RISC-ISA mit Präfixanweisungen ungeachtet der Präfixanweisungen weiterhin als RISC ISA ausgeführt werden, indem jede Präfixanweisung optional als eine eigenständige Anweisung implementiert wird. In anderen Aspekten der Präfixanweisungen kann eine Implementierung oder Architektur angeben, dass die schrittweise Ausführung und das Verfolgen von Ausnahmen zwischen einer Präfixanweisung und einer geänderten sequenziellen Anweisung auftreten oder nicht auftreten darf.
  • In einer Ausführungsform wird ein Anweisungspräfix auf eine bereits bestehende Anweisung angewendet. Die Präfixoperation wird vorzugsweise initiiert, indem eine Anweisung mit einem Präfix-Opcode ausgeführt wird. Fachleute werden verstehen, dass verschiedene Möglichkeiten der Angabe von Präfixen als Anweisungen möglich sind und in Verbindung mit Aspekten der vorliegenden Erfindung verwendet werden können. In einer Ausführungsform kann die Präfixanweisung eine vorhergehende Anweisung, eine nächste sequenzielle Anweisung oder einen vom Präfix abhängigen Anweisungsstrom bearbeiten. So kann beispielsweise eine Präfixanweisung vor einer nächsten Anweisung verwendet werden, um die zuletzt verwendeten Register der nächsten Anweisung zu definieren. In einer Ausführungsform kann die Präfixanweisung der Anweisung mit der letztmaligen Verwendung über mehrere dazwischenliegende Anweisungen vorausgehen, um dem Prozessor Zeit zu geben, die letzte Verwendung ohne eine Verzögerung in der Pipeline vorzubereiten. Eine solche Präfixanweisung kann eine Reihe von dazwischenliegenden Anweisungen oder einen Adresswert niedriger Ordnung der Anweisung angeben, die zum Beispiel die letztmalige Verwendung eines Register enthält.
  • In einem Beispiel geht der Anweisung mit der letzten Verwendung ein Wert in einem Anweisungsstrom voraus, der von einem Prozessor zu verwenden ist, der die Anweisung mit der letzten Verwendung ausführt, um wie folgt zu bestimmen, welche Register die zuletzt verwendeten sind:
    LLU Rt, (RB, RD), MM:
    verwendet das MM-Feld des Präfixwerts, um zu bestimmen, welches Register bzw. welche Register die letztmals verwendeten Register sind. Fachleute werden verstehen, dass andere Felder (PF1) in einem gemeinsamen Präfix vorhanden sein können, z. B. durch Angabe weiterer Registerspezifizierungsbit oder durch eine auszuführende Funktion.
  • Ein folgendes Beispiel einer Präfixanweisung zeigt die Präfixanweisung (PRE, MM) mit einem MM-Maskenfeld für die Angabe eines Registers (RB, RD oder Rt) in der nächsten sequenziellen Anweisung, das das letztmals verwendete Register in der nächsten sequenziellen Anweisung ist:
    Figure 00730001
  • Im folgenden Beispiel verfügt die Präfixanweisung (PRE) über ein MM-Feld, wie zuvor dargestellt, sowie über ein Präfixfeld (PF1) zur Angabe einer Funktion, die von der nächsten Anweisung auszuführen ist. Das Feld PF1 kann die Ausführung der nächsten sequenziellen Anweisung zusätzlich zur Angabe des letztmals verwendeten Registers bzw. der letztmals verwendeten Register ändern.
  • Figure 00730002
  • Gemäß einer anderen Ausführungsform wird eine eindeutige Präfixanweisung zur Angabe verwendet, dass ein Wert in der nächsten Anweisung zum letzten Mal verwendet werden soll. „LU, Rx” gibt an, dass das RX-Register das letzte Mal zu verwenden ist und einen Wert bereitstellen kann, der anstelle des RX-Registers der nächsten Anweisung zu verwenden ist. „LU, R1, R2„ gibt an, dass R1 und R2 in der nächsten Anweisung das letzte Mal verwendet werden, und es können R1- und R2-Werte für die nächste Anweisung bereitgestellt werden. „LU MMMMMM” kann eine Vielzahl von Registern angeben, die das letzte Mal verwendet werden (zum Beispiel über die Bit-signifikante Darstellung von Registern in der Maske MMMMMM oder einem Bereich von Registern), und LU Rx, MMMMMM können eine Vielzahl von letztmals zu verwendenden Registern angeben, sowie einen Rx-Wert, der von der nächsten Anweisung zu verwenden ist. In einer Ausführungsform stellt die Präfixanweisung ein direktes Feld bereit, das von der nächsten Anweisung zu verwenden ist. In einer Ausführungsform stellt die Präfixanweisung den Programmzählerwert (PC) der nächsten Anweisung bereit, der von dieser anstelle eines Registerwerts, der in der nächsten Anweisung angegeben wird, zu verwenden ist.
  • Figure 00740001
  • Fachleute werden verstehen, dass die LU-Anweisung 1 oder eine Vielzahl an Registerspezifizierern bereitstellen kann, deren letzte Verwendung erfolgt ist. In einer Ausführungsform kann die LU-Anweisung einer Anweisung vorangehen und Informationen zur letzten Verwendung von Registern für die folgenden Anweisung bereitstellen (ähnlich dem zuvor beschriebenen Präfixwert).
  • In einer anderen Ausführungsform der LU-Anweisung kann die LU-Anweisung über ein Feld verfügen, um die letzte Verwendung für mehrere Anweisungen anzugeben, wobei entweder an einer impliziten Registernummer oder an einem in einem Registerfeld angegebenen Register begonnen wird.
  • Wenngleich Beispiele für Ganzzahlenregister angeführt wurden, ist es für Fachleute ersichtlich, dass die hier dargelegten Lehren auf andere Operandenwerte angewendet werden können, wie allgemeine Register, Gleitkommazahlenregister, Zusatzregister, die anderen Registern zugeordnet sind, und Hauptspeicher-Speicherorten, zum Beispiel einen Block in einem Hauptspeicher, der einem Speicherort zugeordnet ist, der durch eine Adresse in einem Register bestimmt wird. Ein solcher Block kann zum Beispiel eine Seite sein (z. B. 4 KB) oder eine Cachezeile (128 Byte) oder mehrere Blöcke, wenn ein Operand einzelne Blöcke überschreitet.
  • Die letzte Verwendung eines Hauptspeicherblocks kann dem Prozessor ermöglichen, den Hauptspeicherblock präemptiv aus dem Cache zu löschen. Dies ist zweckmäßig, da der Compiler weiß, dass dies die letzte Verwendung des Blocks ist und die Anweisung mit der letzten Verwendung dazu nutzen kann, den Prozessor bei der Verwaltung der Cachesäuberung zu unterstützen. Wenn der Cache einen geänderten Block löscht, erhöht dies die Leistung, da der Block nicht in den Hauptspeicher zurückgeschrieben werden muss. Zuvor musste jede Zeile in einem Cache, in die geschrieben wurde, im Hauptspeicher gespeichert werden.
  • In einer beispielhaften Ausführungsform der Präfixanweisungen werden verschiedene neue Anweisungen, wie die Anweisungen addpcis+, addis+ und pcaddis+, für die POWER ISA bereitgestellt. Gemäß der Definition der Anweisung addpcis+ wird ein Register RT geändert, um die Summe eines versetzten direkten 16-Bit-Felds und eines Registers darzustellen. Wird die Registernummer 0 angegeben, ist der zu der versetzten direkten Anweisung addierte Wert der der nächsten Anweisungsadresse (oder der aktuellen Anweisungsadresse, in einer alternativen Ausführungsform). Es können mehrere zusammengefasste Anweisungsidiome generiert werden, wodurch ein 32-Bit-Verschiebewert in Speicheranweisungen verwendet werden kann, die ansonsten nur 16-Bit-Verschiebewerte unterstützen, indem die Präfixanweisung addis+ mit einer nachfolgenden Anweisung zusammengefasst wird.
  • In einem Aspekt der Anweisung addis+ muss der Ergebniswert (RT) von addis+ nicht beibehalten werden, wenn eine Speicheranweisung oder eine Ladeoperation vorliegt, die den RT-Wert nicht referenziert. Gemäß der Definition der Anweisung addis+ wird ein Register RT geändert, um die Summe eines versetzten direkten 16-Bit-Felds und eines Registers darzustellen. Wird die Registernummer 0 angegeben, ist der zu der verschobenen direkten Anweisung hinzugefügte Wert der der Nummer 0. Es können mehrere zusammengefasste Anweisungsidiome generiert werden, wodurch ein 32-Bit-Verschiebewert in Speicheranweisungen verwendet werden kann, die ansonsten nur 16-Bit-Versatzwerte unterstützen, indem die Präfixanweisung addis+ mit einer nachfolgenden Anweisung zusammengefasst wird.
  • Gemäß der Definition der Anweisung pcaddis+ wird ein Register RT geändert, um die Summe eines versetzten direkten 16-Bit-Felds und der Adresse der nächsten Anweisung (oder die aktuelle Adresse der Anweisung in einer alternativen Ausführungsform) darzustellen. Es können mehrere zusammengefasste Anweisungsidiome generiert werden, wodurch ein 32-Bit-Versatzwert in Speicheranweisungen verwendet werden kann, die ansonsten nur 16-Bit-Versatzwerte unterstützen, indem die pcaddis+-Präfixanweisung mit einer nachfolgenden Anweisung zusammengefasst wird.
  • In einer Ausführungsform addiert eine Anweisung addpcis+ einen Operanden aus dem Register 2 (r2) zu einem direkten Feld hinzu und stellt das Ergebnis der nächsten sequenziellen Anweisung bereit, wie wenn sie in einem angegebenen Ergebnisregister (r4) gespeichert würde, der Ergebnisregisterwert aber tatsächlich nicht geändert wird. Die Ausführung der nachfolgenden Anweisung (z. B. lwz) verwendet den von der Anweisung addpcis+ bereitgestellten Wert anstelle des angegebenen Quellregisters. Falls in einer Ausführungsform ein dazwischenliegender Kontextwechsel auftritt, wird das Ergebnis der Anweisung addpics+ im angegebenen Register (r4) gespeichert, sodass bei Rückgabe des Kontextes die Anweisung lwz den Registerwert abruft. In einer anderen Ausführungsform sind Kontextwechsel zwischen einer Präfixanweisung und der nächsten sequenziellen Anweisung, der sie als Präfix dient, nicht gestattet. In einer anderen Ausführungsform wird das Ergebnis der Anweisung addpcis+ als Wert der „letztmaligen Verwendung” angegeben, sodass die nächste sequenzielle Ausführung der letzte Benutzer des Werts ist. Die letzte Verwendung eines Werts in einer Ausführungsform setzt die Architekturressource in einen nicht verwendeten Zustand, bis eine nachfolgende Aktion, wie eine Schreiboperation, die Ressource in einen verwendeten Zustand versetzt. Während eine Ressource sich in einem nicht verwendeten Zustand befindet, wird ein Standardwert für Lesezugriffe zurückgegeben. Der Standardwert kann u. a. beispielsweise ein programmierbarer Wert, nur 1en oder nur 0en oder ein in der Architektur nicht definierter Wert (Pseudozufallszahl) sein.
  • Somit ist die folgende Beispielsequenz möglich:

    addpcis+ r4, r2, 0x1234
    lwz r5, r4, 0x5678

    wobei die Anweisung addpcis+ das direkte Feld (0x1234) in den höherrangigen Bereich von R2 hinzufügt und das Ergebnis in einem Pseudoquellregister R4 der nächsten sequenziellen Anweisung (lwz) bereitstellt und die letzte Verwendung von R4 angibt. Die Anweisung „lwz” fügt das direkte Feld (0x5678 Vorzeichen-erweitert, sign extended) zu dem Pseudoregister R4 hinzu und verwendet das Ergebnis als eine Adresse für den Zugriff auf den Hauptspeicher, um einen Hauptspeicherwert zu lesen und den Wert in R5 zu laden.
  • Bei der Optimierung durch den Prozessor werden die Anweisungen addpcis+ und lwz zusammengefasst in eine lwz-iop (interne op) =>

    lwz-iop r5, r2, 0x12345678

    was möglich ist, da R4 die letzte Verwendung war, es muss von der optimierten Anweisung nicht hineingeschrieben werden.
  • Ebenso wird:

    addpcis+ r4, r2, 0x1234
    lfd f5, r4, 0x5678

    bei der Optimierung zu =>
    lfd-iop f5, r2, 0x12345678
  • In einer anderen Ausführungsform wird

    addpcis+ r4, r2, 0x1234
    addi r5, r4, 0x5678

    bei der Optimierung zu =>

    addi-iop r5, rx, 0x12345678
  • In einer Ausführungsform werden Pseudo-Mnemoniken eingeführt, wodurch Programmierer eine einzelne Op erstellen können und die temporäre Architekturressource wird überschrieben. Zum Beispiel ist im Folgenden lwz mit <r4> eine solche Pseudo-Op, die angibt, dass R4 ein letztmals verwendetes Register ist.
    lwz r5, r2, 0x12345678<r4>
  • Ein Assembler (bzw. Assemblierer oder Programmumsetzer) würde dies interpretieren und die folgenden zwei ISA-Anweisungen erstellen

    addpcis+ r4, r2, 0x1234
    lwz r5, r4, 0x5678

    die der Prozessor optimieren würde, um daraus lwz-iop zu machen =>
    lwz-iop r5, r2, 0x12345678
  • In einer anderen Ausführungsform würde
    lfd f5, r2, 0x12345678<r4>
    von einem Assembler interpretiert werden, um das ISA-Paar zu erzeugen:

    addpcis+ r4, r2, 0x1234
    lfd f5, r4, 0x5678
    das der Prozessor optimieren würde, um daraus lfd-iop zu machen =>
    lfd-iop f5, r2, 0x12345678
  • Wenn in einer Ausführungsform ein angegebener Wert „0” für den Spezifizierer des Quellregisters der Anweisung addpcis+ ist, wird der Wert der nächsten Anweisungsadresse (NIA, Next Instruction Address) verwendet. Dadurch können Programme auf den Programmzähler (PC) zugreifen und eine Adressierung in Bezug zum Programmzähler bereitstellen. Zum Beispiel stellt das folgende Anweisungspaar der Anweisung addpcis+ lzw die anstelle des Registerwerts r4 zu verwendende Programmzähleradresse bereit:

    addpcis+ r4, 0, 0x1234
    lwz r5, r4, 0x5678

    die vom Prozessor in eine lwz-iop optimiert wird (mit einer Assembler-Darstellung von lwz- r5, pc, 0x12345678<r4>), wird =>

    lwz-iop r5, pc, 0x12345678<r4>

    wobei der Pseudowert r4 in der Anweisung addpcis+ berechnet wird, indem der Programmzählerwert zum direkten Feld (0x1234) addiert wird.
  • Ebenso ist das Anweisungspaar:

    addpcis+ r4, 0, 0x1234
    lfd f5, r4, 0x5678

    optimiert, um zu ergeben =>
    lfd-iop f5, pc, 0x12345678 (mit einer Assembler-Darstellung von lfd f5, pc, 0x12345678 <r4>)
  • Ebenso sind

    addpcis+ r5, 0, 0x1234
    addis r5, r5, 0x5678

    optimiert, um zu ergeben =>

    addi-iop r5, pc, 0x12345678
  • In einer Ausführungsform ist der Wert von RT nicht definiert, wenn auf die Präfixanweisung keine Anweisung folgt, die RT referenziert. In einer anderen Ausführungsform wird eine Ausnahme für eine ungültige Anweisung ausgelöst bzw. kann ausgelöst werden. In einer anderen Ausführungsform wird das Ergebnis RT auf das Berechnungsergebnis festgelegt, das von der Präfixanweisung impliziert wird.
  • In einer Softwareausführungsform wird addpcis+ verwendet, um eine Tabelle (d. h. das Inhaltsverzeichnis (TOC, Table of Contents)) unter Verwendung des Programmzählers zu adressieren und um große TOC-Offsets für Ladeoperationen in Nicht-GPR-Register mit einer einzelnen Iop-Sequenz in einer optimierten binären Anwendungsschnittstelle (ABI, Application Binary Interface) mit Daten in TOC bereitzustellen. In einem Aspekt der Softwareausführungsform zum Generieren des Codes für Präfixanweisungen, stellt die Codegenerierung (z. B. in einem Compiler) sicher, dass die Präfixanweisung in Verbindung mit einer geänderten Anweisung generiert wird und direkt vor der geänderten Anweisung angeordnet wird. In einem anderen Aspekt werden weitere Anpassungsmaßnahmen durchgeführt, um die Optimierung bei der Dekodierung zu vereinfachen, z. B. einschließlich, aber nicht darauf beschränkt, der Sicherstellung, dass eine Präfixanweisung und die nächste sequenzielle Anweisung in eine oder mehrere von einer einzelnen Seite, einer einzelnen Cachezeile, einer einzelnen Anweisungsgruppe zu Beginn einer einzelnen Anweisungsgruppe fallen.
  • In einer Ausführungsform wird eine Präfixanweisung angegeben, wobei die Präfixanweisung den Wert einer definierten Ressource ändert, der als Quellenoperand von einer nächsten sequenziellen Anweisung im Anweisungsstrom verwendet wird, wobei die definierte Ressource nach der Ausführung der folgenden sequenziellen Anweisung im Anweisungsstrom in einem nicht definierten Zustand verbleibt.
  • In einer anderen Ausführungsform wird eine beliebige der Präfixanweisungen addis+, addpcis+ oder pcaddis+ angegeben,

    Add PC Immediate Shifted-Präfix D-Form
    addpcis+ RT, RA, SI
    Figure 00820001
    if RA = 0 then RT ← (NIA) + EXTS(SI||160)
    else RT ← (RA) + EXTS(SI||160)
  • Die Summe (RAI|NIA) + (SI||0x0000) wird als Quelle für Referenzen auf das Register RT nur für die nächste sequenzielle Anweisung bereitgestellt.
  • addpcis+ ist ein Anweisungspräfix und ändert die folgende Anweisung, sodass bei Angabe von RT der für RT berechnete Wert als Eingabe verwendet wird.
  • Die Anweisung gibt an, dass RT nach der Ausführung der nächsten sequenziellen Anweisung nicht mehr verwendet wird, und der Wert nicht mehr definiert ist. Wenn die Ausführung nach der Anweisung addpcis+ und vor der nächsten sequenziellen Anweisung unterbrochen wird, wird der Status auf eine Weise aktualisiert, die der Ausführung ermöglicht, die nächste Anweisung wiederaufzunehmen und das korrekte Ergebnis zu liefern (d. h. RT wird geschrieben, oder ein anderes in der Implementierung definiertes Verfahren, um die Auswirkung der Änderung der nächsten sequenziellen Anweisungsquelle RT beizubehalten, wird verwendet). Spezielle geänderte Register:
    Man beachte, dass addpcis+ den Wert von NIA verwendet, nicht die Inhalte von GPR 0, wenn RA = 0.

    Add Immediate Shifted-Präfix D-Form
    addis+ RT, RA, SI
    Figure 00830001
    if RA = 0 then RT ← EXTS(SI||160)
    else RT ← (RA) + EXTS(SI||160)
  • Die Summe (RA|0) + (SI||0x0000) wird als Quelle für Referenzen auf das Register RT nur für die nächste sequenzielle Anweisung bereitgestellt.
  • addis+ ist ein Anweisungspräfix und ändert die folgende Anweisung, sodass bei Angabe von RT der für RT berechnete Wert als Eingabe verwendet wird.
  • Die Anweisung gibt an, dass RT nach der Ausführung der nächsten sequenziellen Anweisung nicht mehr verwendet wird, und der Wert nicht mehr definiert ist. Wenn die Ausführung nach der Anweisung addis+ und vor der nächsten sequenziellen Anweisung unterbrochen wird, wird der Status auf eine Weise aktualisiert, um der Ausführung zu ermöglichen, die nächste Anweisung wiederaufzunehmen und das korrekte Ergebnis zu liefern (d. h. RT wird geschrieben, oder ein anderes in der Implementierung definiertes Verfahren, um die Auswirkung der Änderung der nächsten sequenziellen Anweisungsquelle RT beizubehalten, wird verwendet).

    PC Add Immediate Shifted-Präfix D-Form
    pcaddis+ RT, SI
    Figure 00840001
  • Die Summe NIA + (SI||0x0000) wird als Quelle für Referenzen auf das Register RT nur für die nächste sequenzielle Anweisung bereitgestellt.
  • pcaddis+ ist ein Anweisungspräfix und ändert die folgende Anweisung, sodass bei Angabe von RT der für RT berechnete Wert als Eingabe verwendet. Die Anweisung gibt an, dass RT nach der nächsten sequenziellen Anweisung nicht mehr verwendet wird, und der Wert nicht definiert ist.
  • Wenn die Ausführung nach der Anweisung pcaddis+ und vor der nächsten sequenziellen Anweisung unterbrochen wird, wird der Status auf eine Weise aktualisiert, die der Ausführung ermöglicht wird, die nächste Anweisung wiederaufzunehmen und das korrekte Ergebnis zu liefern (d. h. RT wird geschrieben, oder ein anderes in der Implementierung definiertes Verfahren, um die Auswirkung der Änderung der nächsten sequenziellen Anweisungsquelle RT beizubehalten, wird verwendet).
  • Es wird auf 4 Bezug genommen, in der eine beispielhafte Architekturregister-Zuordnungseinheit dargestellt wird, die eine architekturbestimmte Registertabelle 400 mit Einträgen zum Zuordnen der architekturbestimmten Registeradressen 402 zu entsprechenden Einträgen 401 verwendet. Jeder Eintrag 401 enthält ein TAG-Feld, das angibt, ob das Register aktiv oder inaktiv ist. Jeder Eintrag 401 enthält einen physischen Registerbezeichner (oder ein physisches Register in einer anderen Ausführungsform), um ein physisches Register eines physischen Registerpools 405 zu identifizieren. Ein aktiviertes architekturbestimmtes Register (aktiv) kann einem physischen Register zugewiesen werden, und ein nicht aktiviertes architekturbestimmtes Register (deaktiviert) kann keinem physischen Register zugewiesen sein. Beim Zugriff auf ein architekturbestimmtes Register (zur Verwendung mit einem Ausführungsmodul 403) durch eine Anweisung wählt die Adresse 402 den Eintrag 401 der Tabelle 400 entsprechend dem architekturbestimmten Register. Wenn in 407 das TAG-Feld angibt, dass das Register aktiv ist (aktiviert), wird der Operand des zugehörigen physischen Registers aus dem physischen Register gelesen bzw. in das physische Register geschrieben). Wenn in 407 das TAG-Feld angibt, dass das Register nicht aktiv ist (deaktiviert), wird ein in der Architektur definierter Wert an die Ausführungseinheit 403 für eine Leseoperation zurückgegeben. In einer Ausführungsform ist der in der Architektur definierte Wert ein Standardwert 404. In einer Registerumbenennungsumgebung weist eine Abschlusseinheit 406 in Verbindung mit einer Umbenennungsregister-Zuordnungseinheit 408 ein physisches Register als architekturbestimmtes Register zu, wenn die ausgeführte Anweisung abgeschlossen wird, wie in der Technik wohlbekannt ist. Das oben Aufgeführte ist ein Beispiel, das die Ausführungsformen veranschaulicht, um die Aspekte der Erfindung zu vermitteln, weitere Ausführungsformen sind möglich, die für Fachleute nützlich sein können, wurden in den Aspekten der Erfindung vermittelt.
  • Es wird auf 5 Bezug genommen. In einer Ausführungsform wird eine Zuordnungseinheit der architekturbestimmten Register 508 zum Zuweisen der physischen Register eines Pools physischer Register 510 an einen Operanden 509 verwendet. Ein Satz von TAGs 507, die den architekturbestimmten Registern zugewiesen sind, gibt an, ob ein Operand aktiviert (A) oder deaktiviert (D) ist.
  • In einer Ausführungsform, wobei der aktive Operand ein in der Architektur architekturbestimmter Operand ist, auf den eine Anweisung zugreifen kann, wobei bei einem Zugriff auf einen deaktivierten Operanden keine zuvor im Operanden gespeicherten Werte zurückgegeben werden müssen, wird ein aktiver Operand durch Ausführen der Anweisung 500 zum Deaktivieren des Operanden (OD) deaktiviert 504, wobei die OD-Anweisung ein Opcode-Feld mit einem Opcode-Wert aufweist und die OD-Anweisung einen zugeordneten zu deaktivierenden Operanden besitzt. Die Ausführung bestimmt 502 die letzte Verwendung des zugeordneten Operanden, führt eine mit Opcode definierte Funktion mit dem zugeordneten Operanden aus 503 und setzt den zugeordneten Operanden in einen deaktivieren Zustand.
  • In einer Ausführungsform wird eine beliebige von einer OD-Anweisung 500 oder einer anderen Anweisung 506 ausgeführt, um anzugeben 501, dass die Verwendung des zugeordneten Operanden durch die OD-Anweisung 500 die letzte Verwendung ist. In einer Ausführungsform geht die andere Anweisung der OD-Anweisung in der Programmreihenfolge voran.
  • In einer Ausführungsform weist das Deaktivieren (TAG = A → D 507) des Operanden 506 die Rückgabe eines physischen Registers, das dem architekturbestimmten Register 509 zugeordnet ist, an einen Pool 510 verfügbarer Register auf, die zur Zuweisung als architekturbestimmte Register verfügbar sind.
  • Es wird auf 6 Bezug genommen. In einer Ausführungsform besteht der zugeordnete Operand aus einem beliebigen von einem allgemeinen architekturbestimmten Register, einem architekturbestimmten Zusatzregister oder einem architekturbestimmten Gleitkommazahlenregister, wobei eine Leseoperation 603 des deaktivierten Operanden 509 (D 507) einen Standardwert 602 zurückgibt, wobei der Standardwert ein beliebiger von einem in der Architektur nicht definierten Wert oder von einem Standardwert in der Architektur ist. Architekturbestimmte Zusatzregister sind zum Beispiel für Programmierer verfügbare ISA-spezifische architekturbestimmte Register, wie zum Beispiel Zugriffsregister der z/Architecture.
  • In einer Ausführungsform (6) unterdrückt 604 das Durchführen der Leseoperation 603 eines Operanden in einem deaktivierten Zustand (TAG = D 507) die Fehlerberichterstellung, die der Leseoperation 603 des Operanden 509 zugeordnet ist.
  • In einer Ausführungsform weist 604 die Leseoperation 603 eines Operanden in einem deaktivierten Zustand (TAG = D 507) ein beliebiges von dem Erhalten des Standardwerts von einem Speicherort, auf den das Programm zugreifen kann; der Rückgabe des Standardwerts mit nur 1en oder nur 0en; oder die Rückgabe eines beliebigen von einem inkrementierten Standwert oder einem dekrementierten Standardwert für jede Leseoperation des Operanden im deaktivierten Zustand auf.
  • In einer Ausführungsform weist das Deaktivieren (TAG = A → D 507) eines Operanden 509, der als aktiv „A” 702 markiert ist, das Zuweisen eines physischen Registers 703 aus dem Pool 510 der verfügbaren physischen Register als architekturbestimmtes Register 509 in einem aktiven Zustand (TAG = A 507) auf.
  • In einer Ausführungsform ist der Pool der physischen Register 510 als Umbenennungsregister mit einer Umbenennungsregister-Zuordnungseinheit 704 zuweisbar.
  • Mit Bezugnahme auf 8 wird in einer Ausführungsform ein Kontextwechsel von Kontext X auf Kontext Y durchgeführt 801, der: Zustandsinformationen von Kontext X in einem Kontextspeicherbereich 804 (wie einem Hauptspeicher) speichert 802, einschließlich: Operandenwerten für aktive Operanden eines aktuellen Kontexts, einen beliebigen von Standardwerten der deaktivierten Operanden oder Zustandsinformationen 802 speichert, die Operanden angeben, die im aktuellen Kontext deaktiviert sind; und die Zustandsinformation des Kontexts Y aus dem Kontextspeicherbereich 804 wiederherstellt 803, einschließlich: gespeicherter Operandenwerte 803 für gespeicherte aktive Operanden eines anderen Kontexts und einem beliebigen von den gespeicherten Standardwerten als aktive Operanden des anderen Kontexts wiederherstellt oder dem deaktivierten Zustand der Operanden des anderen Kontexts wiederherstellt 803.
  • Vorzugsweise wird eine Angabe, welche definierten Register aktiviert oder deaktiviert sind, für ein Programm (X) gespeichert, das unterbrochen wird, und eine Angabe, welche definierten Register aktiviert oder deaktiviert sind, wird erhalten für das neue Programm (Y), das während eines Kontextwechsels in einem Speicherbereich abgerufen wird, wie ein architekturbestimmtes architekturbestimmtes Register oder einen für ein Betriebssystem (OS, Operating System) verfügbaren Hauptspeicherort. Die Angabe kann ein Bit-signifikantes Feld sein, in dem jedes Bit einem definierten Registereintrag oder einem Bereich entspricht, oder auf andere Weise die aktivierten/aktiven definierten Register angibt. In einer Ausführungsform kann nur eine vom OS bestimmte Teilmenge aktiviert werden. In einer Ausführungsform verfügt jeder Thread eines Multithread-Prozessors über einen eigene Satz an aktivierten, deaktivierten Indikatoren. In einer anderen Ausführungsform kann der Wert des aktiven Indikators eines aktiven Programms oder Threads explizit durch im aktiven Programm oder Thread Maschinenanweisungen verfügbare Maschinenanweisungen eingestellt werden.
  • In einer Ausführungsform führt ein Zugriff auf ein deaktiviertes architekturbestimmtes Register zur Anzeige einer Programmausnahme.
  • In einer Ausführungsform wird ein deaktiviertes architekturbestimmtes Register durch die Ausführung einer Registeraktivierungsanweisung aktiviert, die nicht in das deaktivierte architekturbestimmte Register schreibt.
  • In einer kommerziellen Implementierung der Funktionen und Anweisungen, bei der z. B. Betriebssystemprogrammierer in der Programmiersprache Assembler programmieren, werden diese Anweisungsformate in einem Speichermedium 114 gespeichert (auch als Hauptspeicher bzw. Main Storage oder Main Memory bezeichnet), die nativ auf einem z/Architecture IBM Server, PowerPC IBM-Server oder alternativ auf Maschinen, die andere Architekturen ausführen, ausgeführt werden können. Sie können in bestehenden und zukünftigen IBM-Servern und anderen IBM-Maschinen (wie pSeries®-Server und xSeries®-Server) emuliert werden. Sie können in Maschinen ausgeführt werden, in denen die Ausführung allgemein in einem Emulationsmodus durchgeführt wird.
  • In einer Ausführungsform werden für einen ersten Prozessor definierte Anweisungen und Funktionen, die für eine Befehlssatzarchitektur (ISA) ausgelegt sind, auf einem zweiten Prozessor mit einer anderen ISA emuliert. Die Maschinenanweisungen einer ersten ISA werden zum Beispiel in Emulationsprogrammroutinen übersetzt, die Maschinenanweisungen und Funktionen einer zweiten ISA nutzen. Das auf einem zweiten Prozessor ausgeführte Emulationsprogramm führt die für die erste ISA erstellten Programme aus, indem de abgerufenen Maschinenanweisungen des Programms in Programmodule übersetzt werden, die Maschinenanweisungen der zweiten ISA aufweisen, und danach werden de Programmmodule auf dem für de zweite ISA ausgelegten zweiten Prozessor ausgeführt.
  • Im Emulationsmodus wird die spezielle emulierte Anweisung dekodiert, und eine Subroutine wird erstellt, um die einzelne Anweisung als C-Subroutine oder Treiber zu implementieren, oder eine andere Technik wird verwendet, um einen Treiber für eine bestimmte Hardware bereitzustellen, wie Fachleute durch das Verständnis der Beschreibung einer Ausführungsform der Erfindung verstehen werden.
  • Darüber hinaus sind die oben beschriebenen verschiedenen Ausführungsformen nur Beispiele. Es kann viele Variationen dieser Ausführungsformen geben, ohne vom Geist der vorliegenden Erfindung abzuweichen. Obwohl hier beispielsweise eine Umgebung mit logischen Partitionen beschrieben werden kann, ist dies nur ein Beispiel. Aspekte der Erfindung sind für viele Arten von Umgebungen von Vorteil, einschließlich anderer Umgebungen, die eine Vielzahl an Zonen aufweisen, sowie Umgebungen ohne Partitionen. Weiterhin können auch keine zentralen Prozessorenkomplexe vorliegen, aber dennoch mehrere Prozessoren miteinander verbunden sein. Und darüber hinausgehend sind ein oder mehrere Aspekte der Erfindung auf Einprozessorumgebungen anwendbar.
  • Obwohl in dem vorliegenden Dokument bestimmte Umgebungen beschrieben werden, können viele Variationen für diese Umgebungen implementiert werden, ohne vom Geist der vorliegenden Umgebung abzuweichen. Wenn die Umgebung zum Beispiel logische Partitionen aufweist, dann können mehr oder weniger Partitionen in die Umgebung aufgenommen werden. Weiterhin können viele zentrale Verarbeitungskomplexe miteinander verbunden sein. Dies sind nur einige der Variationen, die vorgenommen werden können, ohne vom Geist der vorliegenden Erfindung abzuweichen. Es sind auch weitere Variationen möglich. Obwohl beispielsweise der hier beschriebene Controller die Anweisungen serialisiert, sodass eine IDTE-Anweisung einmal ausgeführt wird, können in einer anderen Umgebung mehrere Anweisungen zu einem Zeitpunkt ausgeführt werden. Weiterhin kann die Anweisung mehrere Controller enthalten. Und darüber hinaus können mehrere Stilllegungsanforderungen (von einem oder mehreren Controllern) gleichzeitig im System ausstehen. Weitere Variationen sind ebenso möglich.
  • Gemäß der Verwendung im vorliegenden Dokument enthält der Begriff „Verarbeitungseinheit” in Seiten formatierbare Entitäten, wie Gäste (Guests); Prozessoren; Emulatoren und/oder andere ähnliche Komponenten. Darüber hinaus enthält der Begriff „durch eine Verarbeitungseinheit” die Bedeutung „im Auftrag einer Verarbeitungseinheit”. Der Begriff „Puffer” (Buffer) enthält die Bedeutung eines Speicherbereichs, wie auch verschiedene Typen von Datenstrukturen, einschließlich Arrays, ohne darauf beschränkt zu sein; und der Begriff „Tabelle” (Table) kann andere Datenstrukturen als vom Typ Tabelle enthalten. Weiterhin kann die Anweisung Anderes als Register zur Angabe von Informationen enthalten. Darüber hinaus kann eine Seite, ein Segment und/oder ein Bereich eine andere Größe aufweisen, als die hier beschriebenen.
  • Eine oder mehrere Funktionen der vorliegenden Erfindung können in Software, Firmware, Hardware oder einer Kombination daraus implementiert werden. Weiterhin können eine oder mehrere Funktionen emuliert werden.
  • Ein oder mehrere Aspekte der vorliegenden Erfindung können in einen Fertigungsgegenstand aufgenommen werden (z. B. ein oder mehrere Computerprogrammprodukte), der zum Beispiel von einem Computer nutzbare Medien aufweist. Die Medien sind hierin beispielsweise als computerlesbare Programmcodemittel oder -logik ausgeführt (wie Anweisungen, Code, Befehle, etc.), um die Funktionen der vorliegenden Erfindung bereitzustellen und zu ermöglichen. Der Fertigungsgegenstand kann als Komponente eines Computersystems enthalten sein oder einzeln verkauft werden. Die Medien (auch als materielles Speichermedium bekannt) können beispielsweise auf einem Speichergerät 120 als festes oder tragbares Medium, Festspeicher (ROM bzw. Read-only Memory) 116, Direktzugriffsspeicher 114 (RAM bzw. Random Access Memory) oder auf einem Computerchip der CPU (110) gespeichert oder in einem I/O-Adapter 118 implementiert werden.
  • Darüber hinaus kann wenigstens ein Programmspeichergerät 120 mit Speichermedien, die von einer Maschine lesbar sind, die wenigstens ein Programm mit Anweisungen verkörpert, das von der Maschine ausgeführt werden können, um die Funktionen der vorliegenden Erfindung durchzuführen, bereitgestellt werden.
  • Die hier dargestellten Ablaufdiagramme sind nur Beispiele. Für diese hier beschriebenen Diagramme oder Schritte (oder Operationen) können viele Variationen bestehen, ohne vom Geist der Erfindung abzuweichen. So können beispielsweise Schritte in einer anderen Reihenfolge ausgeführt werden oder Schritt hinzugefügt, gelöscht oder geändert werden. All diese Variationen werden als Teil der beanspruchten Erfindung betrachtet.
  • Obwohl bevorzugte Ausführungsformen hier detailliert dargestellt und beschrieben wurden, ist es für Fachleute ersichtlich, dass verschiedene Modifikationen, Hinzufügungen, Ersetzungen und Ähnliches vorgenommen werden können, ohne vom Umfang der Erfindung abzuweichen, wie dies in den folgenden Ansprüchen definiert ist.
  • 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 2011/0087865 [0078, 0081, 0099]
    • US 6189088 [0102, 0103, 0107]
  • Zitierte Nicht-Patentliteratur
    • „Intel® Hyper-Threading Technology, Technical User's Guide” 2003 [0039]
    • „Power ISATM Version 2.06 Revision B” von IBM®, das am 23. Juli 2010 veröffentlicht wurde [0054]
    • „z/Architecture Principles of Operation” SA22-7832-08, in der neunten Edition (August 2010) von IBM® [0055]

Claims (15)

  1. Ein computerimplementiertes Verfahren zum Deaktivieren eines aktiven Operanden, wobei der aktive Operand eine Anweisung ist, auf die über einen in der Architektur definierten Operanden zugegriffen werden kann, wobei ein Zugriff auf einen deaktivierten Operanden keine Werte zurückgeben muss, die zuvor im Operanden gespeichert wurden, wobei das Verfahren aufweist: Ausführen durch einen Prozessor einer Anweisung zum Deaktivieren eines Operanden (OD, Operand Deactivating), wobei die OD-Anweisung ein Opcode-Feld mit einem Opcode-Wert aufweist und die OD-Anweisung über einen zugeordneten zu deaktivierenden Operanden verfügt, wobei die Ausführung umfasst: Bestimmen einer letzten Verwendung des zugeordneten Operanden; Durchführen einer in Opcode definierten Funktion unter Verwendung des zugeordneten Operanden; und Setzen des zugeordneten Operanden in einen deaktivierten Zustand.
  2. Das Verfahren gemäß Anspruch 1, das weiterhin aufweist ein Ausführen durch einen Prozessor einer beliebigen von einer OD-Anweisung oder einer anderen Anweisung, um anzugeben, dass die Verwendung des zugeordneten Operanden durch die OD-Anweisung die letztmalige Verwendung ist.
  3. Das Verfahren gemäß Anspruch 2, wobei der zugeordnete Operand aus einem beliebigen von einem architekturbestimmten allgemeinen Register, einem architekturbestimmten Zusatzregister oder einem definierten Gleitkommazahlenregister besteht, wobei eine Leseoperation des deaktivierten Operanden einen Standardwert zurückgibt, wobei der Standardwert ein beliebiger von einem architekturbedingt nicht definierten Wert oder einem architekturbedingten definierten Standardwert ist.
  4. Das Verfahren gemäß Anspruch 3, das weiterhin aufweist: Durchführen einer Schreiboperation bezüglich eines architekturbestimmten Operanden in einem deaktivierten Zustand, das dazu führt, dass der architekturbestimmte Operand in den aktiven Zustand gesetzt wird.
  5. Das Verfahren gemäß Anspruch 3, das weiterhin aufweist: Durchführen der Leseoperation bezüglich eines Operanden in einem deaktivierten Zustand, wobei eine der Leseoperation des Operanden zugeordnete Fehlerberichterstellung unterdrückt wird.
  6. Das Verfahren gemäß Anspruch 3, das weiterhin aufweist, das Durchführen der Leseoperation bezüglich eines Operanden in einem deaktivierten Zustand, wobei dies ein beliebiges aufweist von: Erhalten des Standardwerts von einem Speicherort, auf den ein Programm zugreifen kann; Rückgeben eines Standardwertes nur mit 1en oder nur mit 0en; oder Rückgeben eines beliebigen von einem inkrementierten Standardwert oder einem dekrementierten Standardwert.
  7. Das Verfahren gemäß Anspruch 3, das weiterhin aufweist: Das Deaktivieren des zugeordneten Operanden, weist eine Rückgabe eines dem definierten Register zugeordneten physischen Registers an einen Pool verfügbarer Register auf, die zur Zuweisung als architekturbestimmte Register verfügbar sind; und Ein Aktivieren eines Operanden, das ein Zuordnen eines physischen Registers aus dem Pool verfügbarer physischer Register als architekturbestimmtes Register in einem aktiven Zustand aufweist.
  8. Das Verfahren gemäß Anspruch 3, das weiterhin aufweist ein Durchführen eines Kontextwechsels, wobei der Kontextwechsel aufweist: Speichern in einem Kontextspeicherbereich von Operandenwerten für aktive Operanden eines aktuellen Kontexts; und Speichern eines beliebigen von Standardwerten von deaktivierten Operanden oder von Zustandsinformationen, die im aktuellen Kontext deaktiviert sind; und Wiederherstellen aus dem Kontextspeicherbereich der gespeicherten Operandenwerte für gespeicherte aktive Operanden des anderen Kontexts; und ein beliebiges von dem Wiederherstellen der gespeicherten Standardwerte als aktive Operanden des anderen Kontexts oder dem Wiederherstellen des deaktivierten Zustands von Operanden des anderen Kontexts.
  9. Ein Prozessor zum Deaktivieren eines aktiven Operanden, wobei der aktive Operand ein in der Architektur definierter Operand ist, auf den über eine Anweisung zugegriffen werden kann, wobei der Zugriff auf einen deaktivierten Operanden keine Werte zurückgeben muss, die zuvor im Operanden gespeichert wurden, wobei der Prozessor aufweist: eine Anweisungsabrufeinheit, eine Anweisungsdekodiereinheit und wenigstens eine Ausführungseinheit, wobei der Prozessor dazu ausgebildet ist, ein Verfahren aufzuführen, das aufweist; Ausführen einer Anweisung zum Deaktivieren eines Operanden (Operand Deactivating, OD), wobei die OD-Anweisung ein Opcode-Feld mit einem Opcode-Wert aufweist und die OD-Anweisung über einen zugewiesenen zu deaktivierenden Operanden verfügt, wobei die Ausführung umfasst: Bestimmen einer letzten Verwendung des zugeordneten Operanden; Durchführen einer in Opcode definierten Funktion unter Verwendung des zugeordneten Operanden; und Setzen des zugeordneten Operanden in einen deaktivierten Zustand.
  10. Der Prozessor gemäß Anspruch 9, der weiterhin dazu ausgebildet ist, eine beliebige von der OD-Anweisung oder einer anderen Anweisung auszuführen, um anzugeben, dass die Verwendung des zugeordneten Operanden durch die OD-Anweisung die letztmalige Verwendung ist.
  11. Der Prozessor gemäß Anspruch 10, wobei der zugeordnete Operand aus einem beliebigen von einem architekturbestimmten allgemeinen Register, einem definierten Zusatzregister oder einem definierten Gleitkommazahlenregister besteht, wobei eine Leseoperation des deaktivierten Operanden einen Standardwert zurückgibt, wobei der Standardwert ein beliebiger von einem architekturbedingt nicht definierten Wert oder von einem architekturbedingten definierten Standardwert ist.
  12. Der Prozessor gemäß Anspruch 11, der weiterhin dazu ausgebildet ist, eine Schreiboperation bezüglich eines definierten Operanden in einem deaktivierten Zustand durchzuführen, was dazu führt, dass der definierte Operand in den aktiven Zustand gesetzt wird, und/oder der Prozessor, der weiterhin dazu ausgebildet ist, das Lesen bezüglich eines Operanden in einem deaktivierten Zustand durchzuführen, wobei eine Fehlerberichterstellung, die der Leseoperation des Operanden zugeordnet ist, unterdrückt wird.
  13. Der Prozess gemäß Anspruch 11, der weiterhin dazu ausgebildet ist, das Lesen bezüglich eines Operanden in einem deaktivierten Zustand durchzuführen, wobei dies ein beliebiges aufweist von: Erhalten des Standardwerts von einem Speicherort, auf den ein Programm zugreifen kann; Rückgeben eines Standardwerts nur mit 1en oder nur mit 0en; oder Rückgeben eines beliebigen von einem inkrementierten Standardwert oder einem dekrementierten Standardwert.
  14. Der Prozessor gemäß Anspruch 11, der weiterhin dazu ausgebildet ist: Deaktivieren des zugeordneten Operanden, das die Rückgabe eines physischen Registers, das als definierten Register zugeordnet ist, an einen Pool verfügbarer physischer Register aufweist, die zur Zuweisung als architekturbestimmte Register verfügbar sind; und Aktivieren eines Operanden, das ein Zuordnen eines physischen Registers aus dem Pool verfügbarer physischer Register als architekturbestimmtes Register in einem aktiven Zustand aufweist, und/oder der Prozessor weiterhin dazu ausgebildet ist, einen Kontextwechsel durchzuführen, wobei der Kontextwechsel aufweist: Speichern in einem Kontextspeicherbereich von Operandenwerten für aktive Operanden eines aktuellen Kontexts; und Speichern eines beliebigen von Standardwerten von deaktivierten Operanden oder von Zustandsinformationen, die angeben, dass Operanden im aktuellen Kontext deaktiviert sind; und Wiederherstellen der gespeicherten Operandenwerte für gespeicherte aktive Operanden eines anderes Kontexts aus dem Kontextspeicherbereich; und em beliebiges von dem Wiederherstellen der gespeicherten Standardwerte als aktive Operanden des anderen Kontexts oder dem Wiederherstellen des deaktivierten Zustands von Operanden des anderen Kontexts.
  15. Computerprogrammprodukt zum Deaktivieren eines aktiven Operanden, wobei der aktive Operand eine Anweisung ist, auf die über einen in der Architektur definierten Operanden zugegriffen werden kann, wobei der Zugriff auf einen deaktivierten Operanden keine Werte zurückgeben muss, die zuvor im Operanden gespeichert wurden, wobei das Computerprogrammprodukt aufweist: ein materielles Speichermedium, das von einem Verarbeitungsschaltkreis lesbar ist und Anweisungen zum Ausführen eines Verfahrens gemäß einem der Ansprüche 1 bis 8 durch den Verarbeitungsschaltkreis speichert.
DE201210217970 2011-10-03 2012-10-01 Computeranweisungen zum Aktivieren und Deaktivieren von Operanden Withdrawn DE102012217970A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/251,458 2011-10-03
US13/251,458 US9697002B2 (en) 2011-10-03 2011-10-03 Computer instructions for activating and deactivating operands

Publications (1)

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

Family

ID=46882020

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201210217970 Withdrawn DE102012217970A1 (de) 2011-10-03 2012-10-01 Computeranweisungen zum Aktivieren und Deaktivieren von Operanden

Country Status (3)

Country Link
US (2) US9697002B2 (de)
DE (1) DE102012217970A1 (de)
GB (1) GB2495359A (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9442730B2 (en) 2013-07-31 2016-09-13 Apple Inc. Instruction source specification
US10061587B2 (en) * 2014-09-25 2018-08-28 Intel Corporation Instruction and logic for bulk register reclamation
US10671393B2 (en) * 2015-04-24 2020-06-02 International Business Machines Corporation Techniques for facilitating cracking and fusion within a same instruction group
US10191747B2 (en) * 2015-06-26 2019-01-29 Microsoft Technology Licensing, Llc Locking operand values for groups of instructions executed atomically
US10346168B2 (en) 2015-06-26 2019-07-09 Microsoft Technology Licensing, Llc Decoupled processor instruction window and operand buffer
US10877759B2 (en) 2015-09-30 2020-12-29 International Business Machines Corporation Managing the capture of information in applications with prefix instructions
US10761852B2 (en) * 2015-09-30 2020-09-01 International Business Machines Corporation Extending data range addressing
US9870305B2 (en) 2015-09-30 2018-01-16 International Business Machines Corporation Debugging of prefixed code
US10185568B2 (en) 2016-04-22 2019-01-22 Microsoft Technology Licensing, Llc Annotation logic for dynamic instruction lookahead distance determination
US10445037B2 (en) * 2016-09-26 2019-10-15 Fuji Xerox Co., Ltd. Image processing apparatus and storage medium
US11188334B2 (en) * 2019-12-02 2021-11-30 Microsoft Technology Licensing, Llc Obsoleting values stored in registers in a processor based on processing obsolescent register-encoded instructions
CN111414199B (zh) * 2020-04-03 2022-11-08 中国人民解放军国防科技大学 一种指令融合的实现方法及装置
US11392386B2 (en) * 2020-08-14 2022-07-19 International Business Machines Corporation Program counter (PC)-relative load and store addressing for fused instructions
US11900116B1 (en) * 2021-09-29 2024-02-13 International Business Machines Corporation Loosely-coupled slice target file data

Citations (4)

* 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
US20110087865A1 (en) 2009-10-13 2011-04-14 International Business Machines Corporation Intermediate Register Mapper

Family Cites Families (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5303358A (en) 1990-01-26 1994-04-12 Apple Computer, Inc. Prefix instruction for modification of a subsequent instruction
US5095526A (en) 1990-01-26 1992-03-10 Apple Computer, Inc. Microprocessor with improved interrupt response with interrupt data saving dependent upon processor status
US5539911A (en) 1991-07-08 1996-07-23 Seiko Epson Corporation High-performance, superscalar-based computer system with out-of-order instruction execution
DE4323929A1 (de) 1992-10-13 1994-04-14 Hewlett Packard Co Software-geführtes Mehrebenen-Cache-Speichersystem
US5590352A (en) 1994-04-26 1996-12-31 Advanced Micro Devices, Inc. Dependency checking and forwarding of variable width operands
JP3711422B2 (ja) 1995-12-20 2005-11-02 セイコーエプソン株式会社 情報処理回路
US6094719A (en) 1997-06-25 2000-07-25 Sun Microsystems, Inc. Reducing data dependent conflicts by converting single precision instructions into microinstructions using renamed phantom registers in a processor having double precision registers
US6317876B1 (en) 1999-06-08 2001-11-13 Hewlett-Packard Company Method and apparatus for determining a maximum number of live registers
US6449710B1 (en) 1999-10-29 2002-09-10 Stmicroelectronics, Inc. Stitching parcels
US6654871B1 (en) * 1999-11-09 2003-11-25 Motorola, Inc. Device and a method for performing stack operations in a processing system
US6393579B1 (en) 1999-12-21 2002-05-21 Intel Corporation Method and apparatus for saving power and improving performance in a collapsable pipeline using gated clocks
US6687806B1 (en) 2000-06-15 2004-02-03 Advanced Micro Devices, Inc. Apparatus and method for generating 64 bit displacement and immediate values
US6748519B1 (en) 2000-06-15 2004-06-08 International Business Machines Corporation Method and apparatus for utilizing renamed registers based upon a functional or defective operational status of the register
US6907601B1 (en) * 2000-06-30 2005-06-14 Intel Corporation Method and apparatus for inserting more than one allocation instruction within a routine
EP1199629A1 (de) 2000-10-17 2002-04-24 STMicroelectronics S.r.l. Prozessorarchitektur mit veränderlichen Pipelinestufen
US7228403B2 (en) 2000-12-23 2007-06-05 International Business Machines Corporation Method for handling 32 bit results for an out-of-order processor with a 64 bit architecture
US7162621B2 (en) 2001-02-21 2007-01-09 Mips Technologies, Inc. Virtual instruction expansion based on template and parameter selector information specifying sign-extension or concentration
US6950926B1 (en) 2001-03-02 2005-09-27 Advanced Micro Devices, Inc. Use of a neutral instruction as a dependency indicator for a set of instructions
US7191315B2 (en) 2001-06-04 2007-03-13 Sun Microsystems, Inc. Method and system for tracking and recycling physical register assignment
US6910121B2 (en) 2002-01-02 2005-06-21 Intel Corporation System and method of reducing the number of copies from alias registers to real registers in the commitment of instructions
US20030154419A1 (en) 2002-01-10 2003-08-14 Binyu Zang Register renaming in binary translation using rollback and recovery
US20030217356A1 (en) * 2002-01-10 2003-11-20 Leonid Baraz Register allocation for program execution analysis
JP3856737B2 (ja) 2002-07-19 2006-12-13 株式会社ルネサステクノロジ データ処理装置
US7131017B2 (en) 2002-08-16 2006-10-31 Carnegie Mellon University Programmable pipeline fabric having mechanism to terminate signal propagation
US6934830B2 (en) 2002-09-26 2005-08-23 Sun Microsystems, Inc. Method and apparatus for reducing register file access times in pipelined processors
AU2003283680A1 (en) 2002-12-04 2004-06-23 Koninklijke Philips Electronics N.V. Software-based control of microprocessor power dissipation
US7127592B2 (en) 2003-01-08 2006-10-24 Sun Microsystems, Inc. Method and apparatus for dynamically allocating registers in a windowed architecture
US7290261B2 (en) 2003-04-24 2007-10-30 International Business Machines Corporation Method and logical apparatus for rename register reallocation in a simultaneous multi-threaded (SMT) processor
US7805536B1 (en) 2003-05-23 2010-09-28 Juniper Networks, Inc. Determining forwarding plane liveness
US20050129191A1 (en) 2003-12-16 2005-06-16 Nokia Corporation System and method for a communication network including an automatic call answering function such as a voice mail server
US20050251662A1 (en) 2004-04-22 2005-11-10 Samra Nicholas G Secondary register file mechanism for virtual multithreading
US7395419B1 (en) 2004-04-23 2008-07-01 Apple Inc. Macroscalar processor architecture
US7284092B2 (en) 2004-06-24 2007-10-16 International Business Machines Corporation Digital data processing apparatus having multi-level register file
US7206903B1 (en) 2004-07-20 2007-04-17 Sun Microsystems, Inc. Method and apparatus for releasing memory locations during transactional execution
US7747993B2 (en) 2004-12-30 2010-06-29 Michigan Technological University Methods and systems for ordering instructions using future values
US20060174089A1 (en) 2005-02-01 2006-08-03 International Business Machines Corporation Method and apparatus for embedding wide instruction words in a fixed-length instruction set architecture
US20060190710A1 (en) 2005-02-24 2006-08-24 Bohuslav Rychlik Suppressing update of a branch history register by loop-ending branches
US8296550B2 (en) 2005-08-29 2012-10-23 The Invention Science Fund I, Llc Hierarchical register file with operand capture ports
US7747841B2 (en) * 2005-09-26 2010-06-29 Cornell Research Foundation, Inc. Method and apparatus for early load retirement in a processor system
US7647482B2 (en) 2006-03-31 2010-01-12 Intel Corporation Methods and apparatus for dynamic register scratching
US7380104B2 (en) 2006-04-25 2008-05-27 International Business Machines Corporation Method and apparatus for back to back issue of dependent instructions in an out of order issue queue
JP2007304663A (ja) 2006-05-08 2007-11-22 Univ Nagoya プロセッサ及びそのデータ処理方法
US7840947B2 (en) * 2006-06-09 2010-11-23 Oracle America, Inc. Delayed breakpoints
US7849446B2 (en) * 2006-06-09 2010-12-07 Oracle America, Inc. Replay debugging
US8181158B2 (en) * 2006-06-09 2012-05-15 Oracle America, Inc. Viewing and modifying transactional variables
US7506139B2 (en) 2006-07-12 2009-03-17 International Business Machines Corporation Method and apparatus for register renaming using multiple physical register files and avoiding associative search
US7472260B2 (en) * 2006-10-10 2008-12-30 P.A. Semi, Inc. Early retirement of store operation past exception reporting pipeline stage in strongly ordered processor with load/store queue entry retained until completion
US20080148022A1 (en) 2006-12-13 2008-06-19 Arm Limited Marking registers as available for register renaming
US7669039B2 (en) 2007-01-24 2010-02-23 Qualcomm Incorporated Use of register renaming system for forwarding intermediate results between constituent instructions of an expanded instruction
US7676653B2 (en) 2007-05-09 2010-03-09 Xmos Limited Compact instruction set encoding
US7818543B2 (en) 2007-07-10 2010-10-19 Globalfoundries Inc. Method and apparatus for length decoding and identifying boundaries of variable length instructions
US7818542B2 (en) 2007-07-10 2010-10-19 Globalfoundries Inc. Method and apparatus for length decoding variable length instructions
US8108614B2 (en) 2007-12-31 2012-01-31 Eric Sprangle Mechanism for effectively caching streaming and non-streaming data patterns
US20100312991A1 (en) 2008-05-08 2010-12-09 Mips Technologies, Inc. Microprocessor with Compact Instruction Set Architecture
US20100095286A1 (en) 2008-10-10 2010-04-15 Kaplan David A Register reduction and liveness analysis techniques for program code
US8078844B1 (en) 2008-12-09 2011-12-13 Nvidia Corporation System, method, and computer program product for removing a register of a processor from an active state
US8266411B2 (en) 2009-02-05 2012-09-11 International Business Machines Corporation Instruction set architecture with instruction characteristic bit indicating a result is not of architectural importance
US8612727B2 (en) 2009-05-19 2013-12-17 Via Technologies, Inc. Apparatus and method for marking start and end bytes of instructions in a stream of instruction bytes in a microprocessor having an instruction set architecture in which instructions may include a length-modifying prefix
JP5471082B2 (ja) 2009-06-30 2014-04-16 富士通株式会社 演算処理装置および演算処理装置の制御方法
US8612959B2 (en) * 2011-10-03 2013-12-17 International Business Machines Corporation Linking code for an enhanced application binary interface (ABI) with decode time instruction optimization
US8756591B2 (en) 2011-10-03 2014-06-17 International Business Machines Corporation Generating compiled code that indicates register liveness
US9740623B2 (en) * 2013-03-15 2017-08-22 Intel Corporation Object liveness tracking for use in processing device cache

Patent Citations (4)

* 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
US20110087865A1 (en) 2009-10-13 2011-04-14 International Business Machines Corporation Intermediate Register Mapper

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Intel(RTM) Hyper-Threading Technology, Technical User's Guide" 2003
"Power ISATM Version 2.06 Revision B" von IBM(RTM), das am 23. Juli 2010 veröffentlicht wurde
"z/Architecture Principles of Operation" SA22-7832-08, in der neunten Edition (August 2010) von IBM(RTM)

Also Published As

Publication number Publication date
US9690589B2 (en) 2017-06-27
GB2495359A (en) 2013-04-10
US20130086363A1 (en) 2013-04-04
US20140108768A1 (en) 2014-04-17
US9697002B2 (en) 2017-07-04
GB201213315D0 (en) 2012-09-05
GB2495359A8 (en) 2013-04-24

Similar Documents

Publication Publication Date Title
DE102012217970A1 (de) Computeranweisungen zum Aktivieren und Deaktivieren von Operanden
DE102012216571A1 (de) Nutzung einer architekturdefinierten letztverwendungs-operandenangabe in einem computersystem-operandenressourcenpool
DE102012216565A1 (de) Decodierzeit-computeranweisungsoptimierung
DE102012216592A1 (de) Präfix-Computeranweisung zur Erweiterung der Anweisungsfunktionalität
DE102012216567A1 (de) Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes
US10061588B2 (en) Tracking operand liveness information in a computer system and performing function based on the liveness information
Schoeberl Time-predictable computer architecture
DE69612991T2 (de) System zur bearbeitung von selbstmodifizierendem kode
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE112011100715T5 (de) Hardware-hilfs-thread
DE102015002383A1 (de) Verfahren und Vorrichtung zum Implementieren einer dynamischen Out-of-order-Prozessorpipeline
DE112009005006T5 (de) Optimierungen für ein ungebundenes transaktionales Speichersystem (UTM)
DE102014119281A1 (de) Prozessor mit virtualisierter befehlssatzstruktur &amp; verfahren
DE102014003799A1 (de) Systeme und Verfahren zur Übertragungseliminierung mit Bypass-Mehrfachinstanziierungstabelle
DE102019119956A1 (de) Architektur und verfahren zur datenparallelen einzelprogramm- mehrfachdaten(spmd)-ausführung
DE112013007703T5 (de) Befehl und Logik zum Kennzeichnen von Befehlen zur Rückordnung in einem mehrsträngigen Out-of-order-Prozessor
DE102016006560A1 (de) Systeme, Verfahren und Vorrichtungen zur Leistungsverbesserung von statusabhängigen Berechnungen
Warg Techniques to reduce thread-level speculation overhead
Fung Gpu computing architecture for irregular parallelism
Asanović et al. Energy-exposed instruction sets
Hilton et al. CPROB: Checkpoint processing with opportunistic minimal recovery
Lankamp Developing a reference implementation for a microgrid of microthreaded microprocessors
Hampton Reducing exception management overhead with software restart markers
Diestelhorst Interaction of Hardware Transactional Memory and Microprocessor Microarchitecture
Gove Solaris application programming

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

Representative=s name: SPIES DANNER & PARTNER PATENTANWAELTE PARTNERS, DE

R082 Change of representative

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R016 Response to examination communication
R016 Response to examination communication
R120 Application withdrawn or ip right abandoned