DE112018003233T5

DE112018003233T5 - Vorhersage von codespezifischen zugehörigen registern

Info

Publication number: DE112018003233T5
Application number: DE112018003233.7T
Authority: DE
Inventors: Michael Karl Gschwind; Valentina Salapura
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2017-08-18
Filing date: 2018-08-07
Publication date: 2020-03-12
Also published as: US20190056940A1; CN110998520B; US20200004539A1; US10534609B2; JP7091441B2; GB2579004A; JP2020531966A; GB2579004B; WO2019034962A1; US10891133B2; GB202002831D0; CN110998520A

Abstract

Vorhersage von codespezifischen zugehörigen Registern. Es wird festgestellt, ob eine Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt. Die Feststellung nutzt einen codespezifischen Anzeiger, der für die Codeeinheit spezifisch ist. Beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wird eine Angabe eines zugehörigen Registers in einen ausgewählten Speicherort geladen. Beruhend auf dem Laden wird das zugehörige Register bei der spekulativen Verarbeitung genutzt.

Description

HINTERGRUND
Ein oder mehrere Aspekte betreffen im Allgemeinen die Verarbeitung in einer Datenverarbeitungsumgebung und insbesondere die Vereinfachung einer solchen Verarbeitung.
Viele Datenverarbeitungssysteme verwenden eine registerindirekte Verzweigung, bei der ein Speicherort der Adresse der nächsten auszuführenden Instruktion nicht in der Adresse selbst, sondern in einer Verzweigungsinstruktion angegeben wird. Zum Beispiel wird ein Speicherort eines Registers, der die Adresse enthält, angegeben.
Des Weiteren wird, gemäß häufig verwendeten binären Anwendungsschnittstellen (ABIs, application binary interfaces), eine Verzweigungsadresse zuerst in ein Mehrzweckregister (GPR, general purpose register) geladen und dann an ein Spezialsteuerregister (SPR, special purpose control register) übertragen, bevor eine registerindirekte Verzweigung vorgenommen wird. Zum Beispiel verzweigt eine Verzweigungsinstruktion in der von der International Business Machines Corporation, Armonk, New York, angebotenen Power Instruction Set Architecture (ISA) zu einem Zähler-(CTR-)Spezialregister. Das Spezialregister wird jedoch nicht direkt geladen, sondern über ein Mehrzweckregister.
Das Auslesen des Zählerregisters ist gewöhnlich aufwendig. Daher gibt mindestens eine ABI an, dass der Wert des CTR in einem anderen Register, wie beispielsweise R12, gespeichert werden soll, wenn eine Verzweigung zu einer Unterroutine (BCTR) vorgenommen wird, so dass das andere Register von der aufgerufenen Funktion als Basisregister verwendet werden kann. Wenn eine Verzweigungsvorhersage gemacht wird, wird die Verzweigungsadresse möglicherweise jedoch vorhergesagt, bevor der R12-Wert geladen wurde, so dass die aufgerufene Unterroutine als Reaktion auf einen Datenzugriff blockiert und die Performanz begrenzt wird.
KURZDARSTELLUNG
Durch die Bereitstellung eines Computerprogrammprodukts, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, werden Unzulänglichkeiten nach dem Stand der Technik überwunden und zusätzliche Vorteile bereitgestellt. Das Computerprogrammprodukt weist ein durch einen Computer lesbares Speichermedium auf, das durch eine Verarbeitungsschaltung gelesen werden kann und Instruktionen zur Durchführung eines Verfahrens speichert. Das Verfahren umfasst zum Beispiel die Feststellung für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt. Die Feststellung nutzt einen codespezifischen Anzeiger, der für die Codeeinheit spezifisch ist. Beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wird eine Angabe eines zugehörigen Registers in einen ausgewählten Speicherort geladen. Beruhend auf dem Laden wird das zugehörige Register bei der spekulativen Verarbeitung genutzt.
Durch einen Computer ausgeführte Verfahren und Systeme, die sich auf einen oder mehrere Aspekte beziehen, werden ebenfalls hierin beschrieben und beansprucht. Weiterhin werden Dienste, die sich auf einen oder mehrere Aspekte beziehen, ebenfalls hierin beschrieben und gegebenenfalls hierin beansprucht.
Gemäß einem Aspekt wird ein Computerprogrammprodukt bereitgestellt, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, wobei das Computerprogrammprodukt aufweist: ein durch einen Computer lesbares Speichermedium, das durch eine Verarbeitungsschaltung gelesen werden kann und Instruktionen zur Durchführung eines Verfahrens speichert, das aufweist: Feststellen für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wobei die Feststellung einen codespezifischen Anzeiger nutzt, der für die Codeeinheit spezifisch ist; beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, Laden einer Angabe eines zugehörigen Registers in einen ausgewählten Speicherort; und, beruhend auf dem Laden, Nutzen des zugehörigen Registers bei der spekulativen Verarbeitung.
Gemäß einem weiteren Aspekt wird ein Computersystem bereitgestellt, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, wobei das Computersystem aufweist: einen Hauptspeicher; und einen Prozessor, der mit dem Hauptspeicher Daten austauscht, wobei das Computersystem so konfiguriert ist, dass es ein Verfahren durchführt, wobei das Verfahren aufweist: Feststellen für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wobei die Feststellung einen codespezifischen Anzeiger nutzt, der für die Codeeinheit spezifisch ist; beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, Laden einer Angabe eines zugehörigen Registers in einen ausgewählten Speicherort; und, beruhend auf dem Laden, Nutzen des zugehörigen Registers bei der spekulativen Verarbeitung.
Gemäß einem weiteren Aspekt wird ein durch einen Computer ausgeführtes Verfahren bereitgestellt, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, wobei das durch einen Computer ausgeführte Verfahren aufweist: Feststellen, durch einen Prozessor, für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wobei die Feststellung einen codespezifischen Anzeiger nutzt, der für die Codeeinheit spezifisch ist; beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, Laden einer Angabe eines zugehörigen Registers in einen ausgewählten Speicherort; und, beruhend auf dem Laden, Nutzen des zugehörigen Registers bei der spekulativen Verarbeitung.
Zusätzliche Merkmale und Vorteile werden durch die hierin beschriebenen Techniken realisiert. Weitere Ausführungsformen und Aspekte werden hierin ausführlich beschrieben und als ein Teil der beanspruchten Aspekte betrachtet.
Figurenliste
Ein oder mehrere Aspekte werden in den Ansprüchen am Ende der Beschreibung besonders hervorgehoben und gesondert als Beispiele beansprucht. Das Vorstehende sowie Merkmale und Vorteile von einem oder mehreren Aspekten gehen aus der folgenden ausführlichen Beschreibung in Zusammenschau mit den beiliegenden Zeichnungen hervor, bei denen:

1A ein Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung zeigt;
1B weitere Einzelheiten eines Prozessors von 1A gemäß einem oder mehreren Aspekten der vorliegenden Erfindung zeigt;
1C weitere Einzelheiten eines Beispiels einer Instruktionsausführungspipeline zeigt, die gemäß einem oder mehreren Aspekten der vorliegenden Erfindung verwendet wird;
1D weitere Einzelheiten eines Beispiels eines Prozessors von 1A gemäß einem Aspekt der vorliegenden Erfindung zeigt;
2 ein Beispiel einer Verarbeitung in Verbindung mit einer Vorhersage für eine registerindirekte Verzweigung gemäß einem Aspekt der vorliegenden Erfindung zeigt;
3 ein Beispiel für das Prüfen der Vorhersagerichtigkeit gemäß einem Aspekt der vorliegenden Erfindung zeigt;
4 ein weiteres Beispiel für das Prüfen der Vorhersagerichtigkeit gemäß einem Aspekt der vorliegenden Erfindung zeigt;
5 ein Beispiel einer Verarbeitung in Verbindung mit einer Vorhersage für eine registerindirekte Verzweigung und ein zugehöriges Register gemäß einem Aspekt der vorliegenden Erfindung zeigt;
6 ein weiteres Beispiel für das Prüfen der Vorhersagerichtigkeit gemäß einem Aspekt der vorliegenden Erfindung zeigt;
7 ein Beispiel für das Prüfen der Vorhersagerichtigkeit für zugehörige Register gemäß einem Aspekt der vorliegenden Erfindung zeigt;
8 ein Beispiel einer Verarbeitung in Verbindung mit einer Vorhersage eines extern angegebenen zugehörigen Registers (EIARP, externally indicated affiliated register prediction) gemäß einem Aspekt der vorliegenden Erfindung zeigt;
9 ein Beispiel einer Verarbeitung in Verbindung mit einem Kontextwechsel und einer Vorhersage eines extern angegebenen zugehörigen Registers gemäß einem Aspekt der vorliegenden Erfindung zeigt;
10 ein Beispiel einer Verarbeitung in Verbindung mit dem Eintreten in eine Hardware-Ausnahmebedingungs-/Unterbrechungsverarbeitung gemäß einem Aspekt der vorliegenden Erfindung zeigt;
11 ein Beispiel einer Verarbeitung in Verbindung mit dem Beenden einer Hardware-Ausnahmebedingungs-/Unterbrechungsverarbeitung gemäß einem Aspekt der vorliegenden Erfindung zeigt;
12 ein Beispiel einer Verarbeitung in Verbindung mit einer Vorhersage für eine registerindirekte Verzweigung und die Verwendung einer Vorhersage eines extern angegebenen zugehörigen Registers gemäß einem Aspekt der vorliegenden Erfindung zeigt;
13 ein Beispiel einer Verarbeitung in Verbindung mit einer Vorhersage für eine registerindirekte Verzweigung und für eine Vorhersage, ob ein zugehöriges Register vorhergesagt werden kann, gemäß einem Aspekt der vorliegenden Erfindung zeigt;
14 ein weiteres Beispiel für das Prüfen der Vorhersagerichtigkeit gemäß einem Aspekt der vorliegenden Erfindung zeigt;
15 ein weiteres Beispiel für das Prüfen der Vorhersagerichtigkeit für zugehörige Register gemäß einem Aspekt der vorliegenden Erfindung zeigt;
16 noch ein weiteres Beispiel für das Prüfen der Vorhersagerichtigkeit für zugehörige Register gemäß einem Aspekt der vorliegenden Erfindung zeigt;
17 ein Beispiel einer Verarbeitung in Verbindung mit einer registerindirekten Verzweigungsvorhersage und für das dynamische Auswählen eines zugehörigen Registers, das vorhergesagt werden kann, gemäß einem Aspekt der vorliegenden Erfindung zeigt;
18 ein Beispiel für das Prüfen der Vorhersagerichtigkeit für zugehörige Register und das Aktualisieren eines Prädiktors gemäß einem Aspekt der vorliegenden Erfindung zeigt;
19 ein Beispiel einer Verarbeitung in Verbindung mit dem Erkennen einer Fusionsabfolge gemäß einem Aspekt der vorliegenden Erfindung zeigt;
20 ein Beispiel einer Verarbeitung in Verbindung mit einer Vorhersage eines extern angegebenen zugehörigen Registers und einer fusionsbasierten Zugehörigkeitsabfolge gemäß einem Aspekt der vorliegenden Erfindung zeigt;
21 ein Beispiel einer Verarbeitung in Verbindung mit dem Durchführen einer Verzweigungsvorhersage mit einer fusionsbasierten zugehörigen Abfolge gemäß einem Aspekt der vorliegenden Erfindung zeigt;
22 ein Beispiel einer Verarbeitung in Verbindung mit der Feststellung, ob eine Instruktion eine Zugehörigkeit erstellend oder löschend ist, gemäß einem Aspekt der vorliegenden Erfindung zeigt;
23 ein Beispiel einer Verarbeitung in Verbindung mit dem Vorhersagen von zugehörigen abgeleiteten Registern gemäß einem Aspekt der vorliegenden Erfindung zeigt;
24 ein Beispiel für das Prüfen der Vorhersagerichtigkeit für zugehörige abgeleitete Register gemäß einem Aspekt der vorliegenden Erfindung zeigt;
25 ein Beispiel einer Verarbeitung in Verbindung mit einer Verzweigungsvorhersage und fusionsbasierten zugehörigen abgeleiteten Abfolgen gemäß einem Aspekt der vorliegenden Erfindung zeigt;
die 26A bis 26B eine einzelne Ausführungsform zur Vereinfachung der Verarbeitung in einer Datenverarbeitungsumgebung gemäß einem Aspekt der vorliegenden Erfindung zeigen;
27A ein weiteres Beispiel einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung zeigt;
27B weitere Einzelheiten des Hauptspeichers von 27A zeigt;
28 eine einzelne Ausführungsform einer Cloud-Computing-Umgebung zeigt; und
29 ein Beispiel von Abstraktionsmodellschichten zeigt.

AUSFÜHRLICHE BESCHREIBUNG
Gemäß einem oder mehreren Aspekten wird beruhend auf der Vorhersage von einem Wert des Inhalts eines Registers (z.B. einer Zieladresse eines Zieladressregisters), der für registerindirekte Verzweigungen verwendet werden soll, der vorhergesagte Wert in dem Register (z.B. dem Zieladressregister, das hierin auch als vorhergesagtes Register bezeichnet wird) gespeichert. Das Register steht dann zur zukünftigen Verwendung zur Verfügung. Zum Beispiel werden die Inhalte eines Zieladressregisters aktualisiert und in Verbindung mit einem Vorhersageinstruktionsabruf zur Verfügung gestellt. Wenn eine Zieladresse vorhergesagt wird, wird sie gleichzeitig sowohl für einen Instruktionsabruf als auch zur Speicherung in einem Register oder an einem anderen ausgewählten Speicherort, auf den andere (z.B. andere Instruktionen oder Operationen) zugreifen können, zur Verfügung gestellt. Dadurch können andere den vorhergesagten Wert verwenden.
Als Beispiel ist das vorhergesagte Register oder der vorhergesagte Speicherort ein anderes Register oder ein anderer Speicherort als ein Programmzähler, der beruhend auf einer Vorhersage automatisch aktualisiert wird. Es bzw. er ist zum Beispiel ein Register oder ein Speicherort zusätzlich zum Programmzähler, wie etwa ein Zähler-(CTR-)Register oder ein anderes ausgewähltes Register/ein anderer ausgewählter Speicherort. Die Zieladresse wird, wenn sie vorhergesagt wurde, gleichzeitig dem vorhergesagten Register zur Verfügung gestellt, da nur eine Einrichtung die registerindirekte Verzweigung verarbeitet und die vorhergesagte Zieladresse speichert. Zum Beispiel befindet sie sich innerhalb der Grenzen einer einzelnen architekturdefinierten Instruktion (z.B. an der Hardware-/Software-Schnittstelle). Eine weitere architekturdefinierte Instruktion wird nicht benötigt, um den Wert in das vorhergesagte Register/an den vorhergesagten Speicherort zu kopieren oder zu verschieben.
In einem weiteren Aspekt wird zusätzlich zur Vorhersage des Werts des Inhalts eines Registers und der Speicherung des vorhergesagten Werts in dem vorhergesagten Register der vorhergesagte Wert auch an einem anderen Speicherort gespeichert, wie beispielsweise einem anderen Register, das verwendet wird, um die Verarbeitung zu vereinfachen. Dieser andere Speicherort bzw. dieses andere Register wird hierin als ein zugehöriger Speicherort bzw. ein zugehöriges Register bezeichnet, das den vorhergesagten Wert speichert, der von anderen Instruktionen verwendet wird. Bei dem zugehörigen Register handelt es sich um ein Register, das zu dem vorhergesagten Register gehört. Zum Beispiel hat ein zugehöriges Register eine bekannte Beziehung zu einem anderen Register (z.B. dem vorhergesagten Register), das beispielsweise als eine Kopie des anderen Registers bekannt ist. In einem bestimmten Fall können beide Register mit einer Instruktion referenziert werden. Als Beispiel verschiebt die MTCTR-R12-Instruktion den Inhalt von R12 in das CTR-Register. Somit ist R12 CTR zugehörig. Es gibt andere solche Beispiele.
In noch einem weiteren Aspekt wird eine Steuerung bereitgestellt, um anzugeben, ob ein zugehöriges Register bei der Vorhersage verwendet werden soll. Wenn ein zugehöriges Register vorhergesagt werden soll, stellt die Steuerung auch eine Angabe des zugehörigen Registers bereit (z.B. eine Registernummer). Diese Steuerung ist zum Beispiel codespezifisch und kann für jede Codeeinheit, wie etwa eine Anwendung, einen Prozess, eine Funktion, ein Modul oder ein dynamisch gemeinsam genutztes Objekt (z.B. eine Bibliothek), als Beispiele, aktiviert/deaktiviert werden.
In noch einem weiteren Aspekt kann der vorhergesagte Wert zur Vorhersage eines Werts verwendet werden, der in einem zugehörigen abgeleiteten Register (oder einem anderen Speicherort) gespeichert werden soll, um die Verarbeitung weiter zu vereinfachen. Ein zugehöriges abgeleitetes Register ist ein Register, dessen Inhalte von den Inhalten eines zugehörigen Registers abgeleitet werden. Zum Beispiel kann der Inhalt von R12 zusammen mit einem Offset verwendet werden, um einen Wert zu erhalten, der in einem ausgewählten Register wie beispielsweise R2 gespeichert werden soll. Somit ist R2 in diesem Beispiel ein zugehöriges abgeleitetes Register. Es gibt auch andere Beispiele.
Ferner kann in einem oder mehreren Aspekten eine bestimmte Abfolge von Instruktionen, die bei der registerindirekten Verzweigung verwendet werden und ein oder mehrere Register angeben, die vorhergesagt werden können, erkannt werden und darauf beruhend wird eine Abfolge von Operationen, die Operationen der bestimmten Abfolge von Instruktionen durchführen, durch Fusion verbunden, um die Verarbeitung zu vereinfachen. Das heißt, ein Fusionsprozess wird durchgeführt, um eine oder mehrere Instruktionen zu einem einzigen zusammengesetzten Prozess von Operationen zusammenzuführen. Das heißt, die Abfolge der Instruktionen ist als Ganzes zu behandeln.
Verschiedene Aspekte sind hierin beschrieben. Des Weiteren sind viele Variationen möglich, ohne vom Wesen von Aspekten der vorliegenden Erfindung abzuweichen. Es sei angemerkt, dass verschiedene Aspekte und Merkmale hierin beschrieben sind und jeder Aspekt bzw. jedes Merkmal, vorbehaltlich der Unvereinbarkeit, mit einem beliebigen anderen Aspekt oder Merkmal kombinierbar sein kann.
Eine einzelne Ausführungsform einer Datenverarbeitungsumgebung zur Einbindung und Verwendung von einem oder mehreren Aspekten der vorliegenden Erfindung wird unter Bezugnahme auf 1A beschrieben wird. In einem Beispiel beruht die Datenverarbeitungsumgebung auf der von der International Business Machines Corporation, Armonk, New York, angebotenen z/Architecture. Eine einzelne Ausführungsform der z/Architecture ist in „z/Architecture Principles of Operation“, IBM-Publikation Nr. SA22-7832-10, März 2015, beschrieben, die hiermit in ihrer Gesamtheit durch Bezugnahme hierin übernommen wird. Z/ARCHITECTURE ist ein eingetragenes Warenzeichen der International Business Machines Corporation, Armonk, New York, USA.
In einem weiteren Beispiel beruht die Datenverarbeitungsumgebung auf der von der International Business Machines Corporation, Armonk, New York, angebotenen Power Architecture. Eine einzelne Ausführungsform der Power Architecture ist in „Power ISA™ Version 2.07B“, International Business Machines Corporation, 9. April 2015, beschrieben, die hiermit in ihrer Gesamtheit durch Bezugnahme hierin übernommen wird. POWER ARCHITECTURE ist ein eingetragenes Warenzeichen der International Business Machines Corporation, Armonk, New York, USA.
Die Datenverarbeitungsumgebung kann auch auf anderen Architekturen beruhen, darunter, ohne darauf beschränkt zu sein, die x86-Architekturen von Intel. Es gibt auch andere Beispiele.
Wie in 1A gezeigt ist, enthält eine Datenverarbeitungsumgebung 100 zum Beispiel ein Computersystem 102, das z.B. in Form einer Mehrzweck-Datenverarbeitungseinheit gezeigt ist. Das Computersystem 102 kann, ohne darauf beschränkt zu sein, einen oder mehrere Prozessoren oder Verarbeitungseinheiten 104 (z.B. zentrale Verarbeitungseinheiten (CPUs, central processing units)), einen Speicher 106 (der als Hauptspeicher oder Arbeitsspeicher, als Beispiele, bezeichnet wird) und eine oder mehrere Ein-/Ausgabe-(E/A-)Schnittstellen 108 enthalten, die über einen oder mehrere Busse und/oder andere Verbindungen 110 miteinander verbunden sind.
Der Bus 110 stellt eine oder mehrere von beliebigen Busstrukturen von mehreren Arten von Busstrukturen dar, darunter einen Hauptspeicher-Bus oder einen Hauptspeicher-Controller, einen peripheren Bus, einen Accelerated Graphics Port und einen Prozessor- oder lokalen Bus, der beliebige von verschiedensten Busarchitekturen verwendet. Beispielhaft und nicht darauf beschränkt gehören zu solchen Architekturen der lokale Bus „Industry Standard Architecture (ISA)“, „Micro Channel Architecture (MCA)“, „Enhanced ISA (EISA)“, „Video Electronics Standards Association (VESA)“ und der „Peripheral Component Interconnect (PCI)“.
Der Hauptspeicher 106 kann zum Beispiel einen Cachespeicher 120, wie beispielsweise einen gemeinsam genutzten Cachespeicher, enthalten, der mit den lokalen Cachespeichern 122 der Prozessoren 104 verbunden sein kann. Des Weiteren kann der Hauptspeicher 106 ein oder mehrere Programme oder Anwendungen 130, ein Betriebssystem 132 und eine oder mehrere durch einen Computer lesbare Programminstruktionen 134 enthalten. Die durch einen Computer lesbaren Programminstruktionen 134 können so konfiguriert werden, dass sie Funktionen von Ausführungsformen von Aspekten der Erfindung ausführen.
Das Computersystem102 kann auch über z.B. E/A-Schnittstellen 108 mit einer oder mehreren externen Einheiten 140, einer oder mehreren Netzschnittstellen 142 und/oder einer oder mehreren Datenspeichereinheiten 144 Daten austauschen. Zu beispielhaften externen Einheiten gehören ein Benutzerterminal, ein Bandlaufwerk, eine Zeigereinheit, ein Bildschirm usw. Die Netzschnittstelle 142 ermöglicht dem Computersystem 102 den Datenaustausch mit einem oder mehreren Netzwerken, wie beispielsweise einem lokalen Netz (LAN, local area network), einem allgemeinen Weitverkehrsnetz (WAN, wide area network) und/oder einem öffentlichen Netz (z.B. dem Internet), die eine Übertragung mit anderen Datenverarbeitungseinheiten oder -systemen bereitstellen.
Die Datenspeichereinheit 144 kann ein oder mehrere Programme 146, eine oder mehrere durch einen Computer lesbare Programminstruktionen 148 und/oder Daten usw. speichern. Die durch einen Computer lesbaren Programminstruktionen können so konfiguriert werden, dass sie Funktionen von Ausführungsformen von Aspekten der Erfindung ausführen.
Das Computersystem 102 kann auswechselbare/nicht auswechselbare, flüchtige/nicht flüchtige Speichermedien eines Computersystems enthalten und/oder damit verbunden sein. Zum Beispiel kann es einen nicht auswechselbaren, nicht flüchtigen magnetischen Datenträger (der üblicherweise als „Festplattenlaufwerk“ bezeichnet wird), ein Magnetplattenlaufwerk, um von einer auswechselbaren, nicht flüchtigen Magnetplatte (z.B. einer „Diskette“) zu lesen und auf sie zu schreiben, und/oder ein optisches Plattenlaufwerk, um von einer auswechselbaren, nicht flüchtigen optischen Platte, wie beispielsweise einem CD-ROM, DVD-ROM oder einem anderen optischen Medium zu lesen oder auf es zu schreiben, enthalten und/oder damit verbunden sein. Es sollte klar sein, dass andere Hardware- und/oder Software-Komponenten in Verbindung mit dem Computersystem 102 verwendet werden könnten. Zu Beispielen gehören, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Anordnungen von Festplattenlaufwerken, RAID-Systeme, Bandlaufwerke und Speichersysteme zur Datenarchivierung usw.
Das Computersystem 102 kann mit zahlreichen anderen Mehrzweck- oder Spezialdatenverarbeitungssystemumgebungen oder -konfigurationen betrieben werden. Zu Beispielen für hinlänglich bekannte Datenverarbeitungssysteme, -umgebungen und/oder - konfigurationen, die für die Verwendung mit dem Computersystem 102 geeignet sein können, gehören, ohne darauf beschränkt zu sein, Personal-Computer-(PC-)Systeme, Server-Computersysteme, Thin Clients, Thick Clients, tragbare oder Laptop-Einheiten, Mehrprozessorsysteme, auf einem Mikroprozessor beruhende Systeme, Aufsatzgeräte (Set-Top-Boxen), programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Mainframe-Computersysteme sowie verteilte Cloud-Computing-Umgebungen, die beliebige der vorstehenden Systeme oder Einheiten enthalten, und dergleichen.
Weitere Einzelheiten in Bezug auf ein Beispiel des Prozessors 104 werden unter Bezugnahme auf 1B beschrieben. Der Prozessor 104 enthält eine Vielzahl von funktionalen Komponenten, die zur Ausführung von Instruktionen verwendet werden. Zu diesen funktionalen Komponenten gehören zum Beispiel eine Instruktionsabrufkomponente 150, um auszuführende Instruktionen abzurufen; eine Instruktionsdecodiereinheit 152, um die abgerufenen Instruktionen zu decodieren und Operanden der decodierten Instruktionen zu erhalten; Instruktionsausführungskomponenten 154, um die decodierten Instruktionen auszuführen; eine Hauptspeicherzugriffskomponente 156, um erforderlichenfalls auf den Hauptspeicher zur Instruktionsausführung zuzugreifen; und eine Zurückschreibkomponente 160, um die Ergebnisse der ausgeführten Instruktionen bereitzustellen. Eine oder mehrere dieser Komponenten können gemäß einem oder mehreren Aspekten der vorliegenden Erfindung zur Ausführung von einer oder mehreren Instruktionen und/oder Operationen in Verbindung mit einem Vorhersageinstruktionsabruf und/oder einer Vorhersageinstruktionsverarbeitung 166 verwendet werden.
Der Prozessor 104 enthält in einer einzelnen Ausführungsform auch ein oder mehrere Register 168, die von einer oder mehreren der funktionalen Komponenten verwendet werden sollen. Der Prozessor 104 kann zusätzliche, weniger und/oder andere Komponenten als die hierin bereitgestellten Beispiele enthalten.
Weitere Einzelheiten in Bezug auf eine Ausführungspipeline des Prozessors 104 werden unter Bezugnahme auf 1C beschrieben. Obgleich verschiedene Verarbeitungsstufen der Pipeline hierin abgebildet und beschrieben sind, wird darauf hingewiesen, dass zusätzliche, weniger und/oder andere Stufen verwendet werden können, ohne vom Wesen von Aspekten der Erfindung abzuweichen.
Unter Bezugnahme auf 1C wird in einer einzelnen Ausführungsform eine Instruktion aus einer Instruktionswarteschlange abgerufen 170 und eine Verzweigungsvorhersage 172 und/oder eine Decodierung 174 der Instruktion kann durchgeführt werden. Die decodierte Instruktion kann zu einer Gruppe von Instruktionen 176 hinzugefügt werden, die zusammen verarbeitet werden sollen. Die gruppierten Instruktionen werden einem Mapper 178 bereitgestellt, der etwaige Abhängigkeiten feststellt, Ressourcen zuweist und die Gruppe von Instruktionen/Operationen den entsprechenden Absetzwarteschlangen zuteilt. Es gibt eine oder mehrere Absetzwarteschlangen für die verschiedenen Arten von Ausführungseinheiten, darunter, als Beispiele, Verzweigen, Laden/Speichern, Gleitkomma, Festkomma, Vektor usw. Während einer Absetzstufe 180 wird eine Instruktion/Operation an die entsprechende Ausführungseinheit abgesetzt. Beliebige Register werden gelesen 182, um ihre Quellen abzurufen, und die Instruktion/Operation wird während einer Ausführungsstufe 184 ausgeführt. Wie angegeben ist, kann die Ausführung für eine Verzweigungs-, eine Lade-(LD-) oder eine Speicher-(ST-)Operation, eine Festkommaoperation (FX), eine Gleitkommaoperation (FP) oder eine Vektoroperation (VX), als Beispiele, erfolgen. Jedwede Ergebnisse werden während einer Zurückschreibstufe 186 in das/die entsprechende(n) Register geschrieben. Danach wird die Instruktion abgeschlossen 188. Wenn eine Unterbrechung oder Löschung 190 stattfindet, kann die Verarbeitung zum Instruktionsabruf 170 zurückkehren.
In einem Beispiel ist des Weiteren eine Registerumbenennungseinheit 192 mit der Decodiereinheit verbunden, die beim Sichern/Wiederherstellen von Registern verwendet werden kann.
Zusätzliche Einzelheiten in Bezug auf einen Prozessor werden unter Bezugnahme auf 1D beschrieben. In einem Beispiel ist ein Prozessor wie beispielsweise der Prozessor 104 ein Pipeline-Prozessor, der Vorhersage-Hardware, Register, Cachespeicher, Decodierer, eine Instruktionsabfolgesteuerungseinheit und Instruktionsausführungseinheiten als Beispiele enthalten kann. Die Vorhersage-Hardware enthält zum Beispiel eine lokale Verzweigungsverlaufstabelle (BHT, branch history table) 105a, eine globale Verzweigungsverlaufstabelle (BHT) 105b und einen globalen Selektor 105c. Auf die Vorhersage-Hardware wird durch ein Instruktionsabruf-Adressregister (IFAR, instruction fetch address register) 107 zugegriffen, das die Adresse für den nächsten Instruktionsabruf hat.
Dieselbe Adresse wird auch einem Instruktions-Cachespeicher 109 bereitgestellt, der eine Vielzahl von Instruktionen abrufen kann, die als „Abrufgruppe“ bezeichnet werden. Zum Instruktions-Cachespeicher 109 gehört ein Verzeichnis 111.
Auf den Cachespeicher und die Vorhersage-Hardware wird ungefähr zum gleichen Zeitpunkt mit derselben Adresse zugegriffen. Wenn die Vorhersage-Hardware über Vorhersage-Informationen für eine Instruktion in der Abrufgruppe verfügt, wird diese Vorhersage an eine Instruktionsabfolgesteuerungseinheit (ISU, instruction sequencing unit) 113 weitergeleitet, die wiederum Instruktionen an Ausführungseinheiten zur Ausführung absetzt. Die Vorhersage kann verwendet werden, um das IFAR 107 in Verbindung mit einer Verzweigungszielberechnung 115 und einer Verzweigungsziel-Vorhersage-Hardware (wie beispielsweise einem Verbindungsregister-Vorhersagestack 117a und einem Zählregisterstack 117b) zu aktualisieren. Wenn keine Vorhersage-Informationen vorhanden sind, aber ein oder mehrere Instruktionsdecodierer 119 eine Verzweigungsinstruktion in der Abrufgruppe finden, wird für diese Abrufgruppe eine Vorhersage erstellt. Vorhergesagte Verzweigungen werden in der Vorhersage-Hardware wie beispielsweise in einer Verzweigungsinformations-Warteschlange (BIQ, branch information queue) 125 gespeichert und an die ISU 113 weitergeleitet.
Eine Verzweigungsausführungseinheit (BRU, branch execution unit) 121 nimmt als Reaktion auf Instruktionen, die von der ISU 113 an sie abgesetzt werden, den Betrieb auf. Die BRU 121 hat Lesezugriff auf eine Datei 123 des Bedingungsregisters (CR, condition register). Die Verzweigungsausführungseinheit 121 hat des Weiteren Zugriff auf Informationen, die von der Verzweigungsprüflogik in der Verzweigungsinformations-Warteschlange 125 gespeichert werden, um den Erfolg einer Verzweigungsvorhersage festzustellen, und sie ist mit dem/den Instruktionsabruf-Adressregister(n) (IFAR) 107, die dem einen oder den mehreren von dem Mikroprozessor unterstützten Threads entsprechen, betriebsfähig verbunden. Gemäß mindestens einer einzelnen Ausführungsform gehören BIQ-Einträge zu einer Kennung und werden von einer Kennung gekennzeichnet, z.B. einem Verzweigungstag (BTAG, branch tag). Wenn eine zu einem BIQ-Eintrag gehörende Verzweigung abgeschlossen ist, wird sie so gekennzeichnet. BIQ-Einträge werden in einer Warteschlange verwaltet und die ältesten Warteschlangeneinträge werden sequenziell freigegeben, wenn sie als Warteschlangeneinträge gekennzeichnet sind, die zu einer abgeschlossenen Verzweigung gehörende Informationen enthalten. Die BRU 121 ist des Weiteren betriebsfähig verbunden, um eine Prädiktor-Aktualisierung zu veranlassen, wenn die BRU 121 eine Verzweigungs-Falschvorhersage erkennt.
Wenn die Instruktion ausgeführt wird, erkennt die BRU 121, ob die Vorhersage falsch ist. Wenn ja, muss die Vorhersage aktualisiert werden. Zu diesem Zweck enthält der Prozessor auch eine Prädiktoraktualisierungslogik 127. Die Prädiktoraktualisierungslogik 127 reagiert auf eine Aktualisierungsanzeige von der Verzweigungsausführungseinheit 121 und ist so konfiguriert, dass sie Array-Einträge in einer oder mehreren der lokalen BHT 105a, der globalen BHT 105b und dem globalen Selektor 105c aktualisiert. Die Vorhersage-Hardware 105a, 105b und 105c kann über Schreibanschlüsse verfügen, die sich von den Leseanschlüssen unterscheiden, welche von der Instruktionsabruf- und Vorhersageoperation verwendet werden, oder ein einzelner Schreib-/Leseanschluss kann gemeinsam genutzt werden. Die Prädiktoraktualisierungslogik 127 kann des Weiteren mit einem Verbindungsstack 117a und einem Zählregisterstack 117b betriebsfähig verbunden sein.
Nun Bezug nehmend auf die Bedingungsregister-Datei (CRF, condition register file) 123, hat die BRU 121 Lesezugriff auf die CRF 123 und die Ausführungseinheiten können in sie schreiben, darunter, ohne darauf beschränkt zu sein, eine Festkommaeinheit (FXU, fixed point unit) 141, eine Gleitkommaeinheit (FPU, floating point unit) 143 und eine Vektor-Multimediaerweiterungseinheit (VMXU, vector multimedia extension unit) 145. Eine Bedingungsregisterlogik-Ausführungseinheit (CRL-Ausführung, wobei CRL für condition register logic steht) 147 (die auch als die CRU bezeichnet wird) und eine Spezialregister-(SPR-)Handhabungslogik 149 haben Lese- und Schreibzugriff auf die Bedingungsregister-Datei (CRF) 123. Die CRU 147 führt logische Operationen an den in der CRF-Datei 123 gespeicherten Bedingungsregistern durch. Die FXU 141 ist in der Lage, Schreibaktualisierungsoperationen an der CRF 123 durchzuführen.
Der Prozessor 104 enthält des Weiteren eine Lade-/Speichereinheit 151 und verschiedene Multiplexer 153 und Pufferspeicher 155 sowie Adressumsetzungstabellen 157 und andere Schaltlogik.
Der Prozessor 104 führt Programme (die auch als Anwendungen bezeichnet werden) aus, die Hardware-Register zum Speichern von Informationen verwenden. Programme, die Routinen aufrufen, wie beispielsweise Funktionen, Unterroutinen oder andere Arten von Routinen, sind für das Sichern von Registern, die von dem Aufrufer (d.h. den Programmen, die die Routinen aufrufen) verwendet werden, und für das Wiederherstellen dieser Register nach der Rückkehr von dem Aufgerufenen (der aufgerufenen Routine) zuständig. Ebenso ist der Aufgerufene für das Sichern/Wiederherstellen von Registern, die er verwendet, zuständig, wie in den nachstehend bereitgestellten Code-Beispielen gezeigt ist.
Des Weiteren verwenden viele Datenverarbeitungssysteme Basisregister, um Daten und/oder Code zu adressieren. Zum Beispiel verwendet das von der International Business Machines Corporation angebotene System/360 (System z) eine Instruktion eines Verzweigungs- und Verbindungsregisters (BALR, branch and link register) und eine USING-Anweisung, um einen Index für die Adressierung von Daten und Code zu erstellen. Als ein weiteres Beispiel verwendet Power Systems eine Verzweigungs- und Verbindungsinstruktion (BL, branch and link instruction) mit einem Offset (z.B. BL +4), um eine Programmzähler-(PC-)Adresse in einem Register zur Verwendung für die Datenadressierung in positionsunabhängigem Code (PIC, position independent code) zu erstellen. Andere Systeme verwenden ebenso Basisregister, um Daten und Code zu adressieren.
Wie angegeben ist, wurden verschiedene Abfolgen verwendet, um die Adressierbarkeit herzustellen. Zum Beispiel wurden Abfolgen verwendet, bei denen der Programmzähler-(PC-)Wert in die Funktion des Aufgerufenen geladen wird, oder es wird die Aufrufadresse der bereitgestellten Funktion verwendet. Dies bietet die Möglichkeit, einen bekannten Wert bereitzustellen, der von der aktuellen Instruktionsadresse dargestellt wird, aber möglicherweise eine aufwendige Abfolge verwendet. Umgekehrt führt die Verwendung der angegebenen Funktionseinstiegsadresse zu einer einfacheren Abfolge, hängt aber von einer möglicherweise langen Abhängigkeitskette ab, um die Einstiegspunktadresse festzulegen. Die folgenden Beispiele beschreiben bisher verwendete Abfolgen zur Herstellung der Adressierbarkeit.
Ein Beispiel von Code für System/360 (System z) ist nachstehend abgebildet: Der folgende Assembly-Code von System/360 zeigt die Struktur von Unterroutinen-Aufrufen, die gewöhnlich verwendet werden, um eine Unterroutine in Mainframe-Systemen aufzurufen, die auf der System/360-Architektur beruhen:
Der folgende Assembly-Code von System/360 (System z) zeigt die Struktur von aufgerufenen Unterroutinen-Aufrufen in Mainframe-Systemen, die auf der System/360-Architektur beruhen:
Des Weiteren ist ein Beispiel von Code für ein System, das auf der Power Architecture beruht, nachstehend abgebildet. Der folgende Assembly-Code der Power Architecture zeigt die Struktur von Unterroutinen-Aufrufen, die gewöhnlich verwendet werden, um eine Unterroutine in Power-Systemen aufzurufen, die auf der Power Architecture beruhen:
Der folgende Assembly-Code der Power Architecture zeigt die Struktur von aufgerufenen Unterroutinen-Aufrufen in Power-Systemen, die auf der Power Architecture beruhen:
Wird der Programmzähler als Basis geladen, wie in den vorstehenden Beispielen, ist dies mit zusätzlichem Aufwand verbunden. Zum Beispiel enthält der Code für System/360 eine extra Instruktion balr r12, 0 und auf Power Systems gibt es einen extra Satz von Instruktionen, darunter mflr/bl.+4/mflr/mtlr. Somit wird bei einer einzelnen Codeumsetzung der Funktionseinstiegspunkt ebenfalls als Basis verwendet, wie nachstehend gezeigt ist.
Ein Beispiel für System/360-Code, der den Funktionseinstiegspunkt als Basis enthält, ist wie folgt:
Ein Beispiel von Code, der auf der Power Architecture beruht, ist wie folgt:
Während es bei der vorstehenden Umsetzung möglich ist, dass die Zieladresse zur Ausführung der Verzweigung zur Verfügung steht, um in die Unterroutine einzutreten, steht die Adresse während einer spekulativen Ausführung nach einer Verzweigungsvorhersage möglicherweise erst zur Verfügung, wenn die Zieladresse für eine Validierung der Vorhersage verfügbar wird. Zum Beispiel steht die Adresse zum Zeitpunkt der Vorhersage nicht in einem Register oder an einem anderen ausgewählten Speicherort (der sich vom Programmzähler unterscheidet) zur Verfügung, auf das bzw. den andere Instruktionen oder Operationen zugreifen können. Gemäß einem Aspekt der vorliegenden Erfindung wird beruhend darauf, dass ein Verzweigungsprädiktor eine registerindirekte Verzweigungsadresse vorhersagt, der vorhergesagte Wert somit auch als ein spekulativer Wert, zum Beispiel in einem architekturdefinierten Register, zur Verfügung gestellt. Wenn die Vorhersage richtig ist, geht die Ausführung dann schneller vonstatten. Wenn die Vorhersage falsch ist, wird eine Wiederherstellung vorgenommen, wie es beruhend auf der Falschvorhersage der Fall gewesen wäre.
Weitere Einzelheiten in Bezug auf eine Vorhersagetechnik für eine registerindirekte Verzweigung werden unter Bezugnahme auf 2. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. Zunächst wird die Zieladresse für eine registerindirekte Verzweigung vorhergesagt, SCHRITT 200, und der Instruktionsabruf wird an die vorhergesagte Zieladresse (die hierin auch als eine vorhergesagte Adresse bezeichnet wird) umgeleitet, SCHRITT 202. Des Weiteren wird in einem Beispiel ein neues Umbenennungsregister für das logische Register zugeordnet, das die Zieladresse enthält, SCHRITT 204. Das heißt, in einer einzelnen Ausführungsform wird eine Registerumbenennung für die Wiederherstellung verwendet. Bei der Registerumbenennung wird ein neues Umbenennungsregister bei einer Verzweigung zugeordnet, und das neue Umbenennungsregister wird mit dem vorhergesagten Wert geladen. Die Vorhersage wird geprüft und wenn die Vorhersage falsch ist, wird eine Wiederherstellung durchgeführt, indem eine Rückkehr zu dem zuvor benannten Register erfolgt.
Wie angegeben ist, wird die vorhergesagte Adresse in das zugeordnete Umbenennungsregister kopiert, SCHRITT 206. Das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 208. Des Weiteren wird eine Vorhersageprüfung durchgeführt, um festzustellen, ob die Vorhersage richtig ist, SCHRITT 210. Es gibt mehrere Möglichkeiten, zu veranlassen, dass eine Vorhersageprüfung stattfindet, darunter das Starten einer Zustandsmaschine, die die Prüfung durchführt, wenn der der Verzweigungsinstruktion bereitgestellte Zielregisterwert verfügbar wird; das Einfügen einer internen Operation (iop) zum Prüfen; oder Veranlassen, dass eine Verzweigungsoperation an eine Prüfpipeline abgesetzt wird, usw.
Bei Falschvorhersage wird eine Wiederherstellung durchgeführt. Es gibt mehrere Wiederherstellungsausführungsoptionen, die verwendet werden können, darunter das Kopieren des richtigen Werts aus dem alten Register in das neue Register; oder das Verwenden einer Umbenennungsausführung, bei der das neu zugeordnete Umbenennungsregister verworfen wird und die Umbenennungsübersicht auf ein vorheriges physisches Register zeigt, das den richtig geladenen Wert enthält. Weitere Einzelheiten in Bezug auf beispielhafte Wiederherstellungsausführungen, die z.B. von einem Prozessor durchgeführt werden, werden unter Bezugnahme auf die 3 bis 4 beschrieben.
Zunächst unter Bezugnahme auf 3 wird in einer einzelnen Ausführungsform eine Prüfung auf Richtigkeit einer Verzweigungsvorhersage durchgeführt, SCHRITT 300. Dies umfasst das Verwenden der vorhergesagten Adresse und das Vergleichen dieser Adresse mit einer aktuellen, als Eingabe in die Verzweigungsinstruktion berechneten Adresse, wenn sie verfügbar wird. Wenn die Vorhersage richtig ist, ABFRAGE 301, ist die Vorhersageprüfung abgeschlossen, SCHRITT 302, und eine Wiederherstellung ist nicht erforderlich.
Wenn die Vorhersage jedoch falsch ist, ABFRAGE 301, werden Instruktionen nach der falsch vorhergesagten Verzweigung gelöscht, SCHRITT 304. Des Weiteren wird der Instruktionsabruf an die berechnete Adresse umgeleitet, SCHRITT 306. Ferner wird der richtige nicht spekulative Wert in das Register geschrieben, das die Zieladresse enthält, SCHRITT 308. Es kann mehrere Möglichkeiten geben, dies vorzunehmen, darunter in einem Entwurf ohne Umbenennung, wobei in ein aktives Register geschrieben wird. Des Weiteren in einem Entwurf mit Umbenennung, wobei in ein vorhandenes Umbenennungsregister geschrieben oder ein neues Umbenennungsregister zugeordnet wird. Das Register, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 310. Dies schließt ein Beispiel der Vorhersageprüfung ab.
In einer weiteren Ausführungsform, unter Bezugnahme auf 4, wird eine Vorhersageprüfungstechnik für eine registerindirekte Verzweigung bereitgestellt, die ausdrücklich Registerumbenennung verwendet. In diesem Beispiel wird eine Prüfung der Richtigkeit einer Verzweigungsvorhersage durchgeführt, SCHRITT 400. Wenn die Vorhersage richtig ist, ABFRAGE 401, ist die Prüfung abgeschlossen, SCHRITT 402, und eine Wiederherstellung wird nicht durchgeführt. Wenn die Vorhersage jedoch falsch ist, ABFRAGE 401, werden die Instruktionen nach der falsch vorhergesagten Verzweigung gelöscht, SCHRITT 404, und das während der Vorhersage zugeordnete Umbenennungsregister wird freigegeben, wodurch das vorherige Umbenennungsregister mit der nicht spekulativen Zieladresse sichtbar wird, SCHRITT 406. Der Instruktionsabruf wird dann an die berechnete Adresse umgeleitet, SCHRITT 408. Dies schließt ein Beispiel der Vorhersageprüfung ab
Vorteilhafterweise entspricht die Technik von 4 einer Verzweigungsverarbeitung, wie sie derzeit in vielen Out-of-order-Prozessoren ausgeführt wird, bei der nach einer Verzweigungsinstruktion zugeordnete Register automatisch freigegeben werden, vorausgesetzt, dass das in Verbindung mit der Verarbeitung der Verzweigungsinstruktion zugeordnete Register als ein Register behandelt wird, das nach der Ausführung der Verzweigungsinstruktion zugeordnet wurde. In einer Ausführungsform, bei der das in Verbindung mit der Verzweigungsinstruktion zugeordnete Zielregister nicht als nach der Verzweigungsinstruktion zugeordnet behandelt und nicht freigegeben wird, kann eine Ausführung gemäß 3 so angepasst werden, dass das Umbenennungsregister, das zugeordnet wurde, um den spekulativen Wert zu halten, mit einem richtigen, nicht spekulativen Wert aktualisiert wird.
In einer weiteren Ausführungsform können Anmerkungen zu einer Nicht-Umbenennung verwendet werden, bei denen zum Beispiel zwei Kopien der Basis bereitgestellt werden. Dann wird bei einer Vorhersage zu der zweiten oder neuen Kopie gewechselt. Die Vorhersage kopiert den vorhergesagten Wert in die neue Kopie und zukünftige Instruktionen verwenden die neu aktivierte Kopie. Die Vorhersage wird geprüft, und bei Vorliegen einer Falschvorhersage wird die alte Kopie verwendet. In einer solchen Ausführung wird eine Falschvorhersage-Wiederherstellung durchgeführt, indem die aktive Kopie des Zielregisters aktualisiert wird, d.h., bei der auf die alte (nicht vorhersagbare) Kopie gezeigt wird und die zweite Kopie als der nächste neue Basiswert bei der nächsten Vorhersage aktiviert wird. Weitere Ausführungen sind ebenfalls möglich.
Wie hierin beschrieben ist, werden beruhend auf der Vorhersage von Inhalten (z.B. einem Wert; einer Zieladresse) eines Registers, das für eine registerindirekte Verzweigung verwendet werden soll, die vorhergesagten Inhalte, die für die Vorhersage verwendet werden, ebenfalls (z.B. gleichzeitig) in dem Register gespeichert, das für die registerindirekte Verzweigung verwendet werden soll, so dass es von anderen Instruktionen verwendet werden kann. Dies vereinfacht die Verarbeitung.
In einem weiteren Aspekt wird der vorhergesagte Wert, der in das Zieladressregister (und z.B. den Programmzähler) geschrieben wird, auch in ein zugehöriges Register geschrieben. Wenn der vorhergesagte Wert zum Beispiel in ein Zählerregister, CTR, bei dem es sich um das Zieladressregister handelt, geschrieben werden soll, wird er auch in ein weiteres ausgewähltes Register, wie beispielsweise R12, R15 oder ein anderes Register, das zu dem CTR-Register gehört, geschrieben.
Für eine bestimmte Verarbeitung, wie beispielsweise mit häufig verwendeten ABIs, muss eine Verzweigungsadresse zuerst in ein Mehrzweckregister (GPR) geladen und dann an ein Spezialsteuerregister (SPR) übertragen werden, bevor eine registerindirekte Verzweigung vorgenommen wird. Gemäß einem solchen Beispiel einer Verzweigungsarchitektur verzweigt die Power ISA zu einem Zähler-(CTR-)Spezialregister. Das Spezialregister (z.B. das Zählerregister, CTR) wird jedoch nicht direkt, sondern über ein Mehrzweckregister geladen.
Da das Auslesen des Zählerregisters aufwendig sein kann, gibt eine beispielhafte ABI des Weiteren an, dass der Wert des CTR in einem ausgewählten Register, z.B. R12, R15 oder einem anderen Register, gespeichert werden soll, wenn eine Verzweigung zu einer Unterroutine (BCTR) vorgenommen wird. Dadurch kann das ausgewählte Register von der aufgerufenen Funktion als ein Basisregister verwendet werden. Wenn eine Verzweigungsvorhersage gemacht wird, wird die Verzweigungsadresse möglicherweise jedoch vorhergesagt, bevor der Wert des ausgewählten Registers geladen wurde, so dass die aufgerufene Unterroutine als Reaktion auf einen Datenzugriff blockiert.
Zuvor wurde, um den Wert in dem ausgewählten Register wie beispielsweise R12 in diesem Beispiel bereitzustellen, eine Verschiebeoperation vom CTR (MFCTR) nach R12 durchgeführt, die das CTR-Register liest und das Ergebnis in R12 schreibt. Gemäß einer Definition einer ABI jedoch, wie zum Beispiel der Power ELF v2 ABI, wird, wenn ein Wert im CTR zur Verfügung gestellt wird, dieser Wert auch im R12 zur Verfügung gestellt. Somit ist die Verschiebeoperation vom CTR nach R12 nicht erforderlich, da Software bereits angibt, dass das, was auch immer sich im CTR-Register befindet, auch in R12 geschrieben werden soll, wodurch die Kopie entfällt. Gemäß einem Aspekt der vorliegenden Erfindung wird jedoch, wenn ein Register vorhergesagt wird, der vorhergesagte Wert für dieses Register in diesem Register zur Verfügung gestellt. Somit wird, wenn das vorhergesagte Register CTR ist, CTR gleichzeitig aktualisiert. Die Anwendung möchte jedoch R12 lesen, das nicht aktualisiert wurde, und da es keine Kopie gibt, gibt es keinen Software-Pfad, um den vorhergesagten Wert, der sich im CTR befindet, nach R12 zu holen. R12 ist ein zugehöriges Register; zu ihm besteht eine Verbindung, jedoch ist es keine Kopie, die unbedingt in dem Code zu sehen ist. Gemäß einem Aspekt der vorliegenden Erfindung wird derselbe Wert, der für CTR vorhergesagt und in das CTR geschrieben wird, daher auch in R12 (oder ein anderes ausgewähltes Register oder einen anderen ausgewählten Speicherort) geschrieben.
Gemäß einem Aspekt der vorliegenden Erfindung wird somit ein zugehöriges Register in Verbindung mit einer Verzweigungsvorhersage von einer oder mehreren Arten von Unterroutinen-Verzweigungen vorhergesagt. Dies ist nachstehend ausführlicher beschrieben.
Ein Beispiel einer Vorhersagetechnik für eine registerindirekte Verzweigung, die auch ein zugehöriges Register vorhersagt, wird unter Bezugnahme auf 5. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. Zunächst wird die Zieladresse für eine registerindirekte Verzweigung vorhergesagt, SCHRITT 500, und der Instruktionsabruf wird an die vorhergesagte Zieladresse umgeleitet, SCHRITT 502. Des Weiteren wird in einem Beispiel ein neues Umbenennungsregister für das logische Register, das die Zieladresse enthält, zugeordnet, SCHRITT 504, und die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister kopiert, SCHRITT 506. Das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 508.
Ferner wird gemäß einem Aspekt der vorliegenden Erfindung auch ein neues Umbenennungsregister für das zugehörige Register zugeordnet, SCHRITT 510. Die vorhergesagte Adresse wird in das für das zugehörige Register zugeordnete Umbenennungsregister kopiert, SCHRITT 512, und das Umbenennungsregister für das zugehörige Register wird als verfügbar gekennzeichnet, SCHRITT 514.
Eine Vorhersageprüfung wird durchgeführt, um festzustellen, ob die Verzweigungsvorhersage richtig ist, SCHRITT 516, wobei ein Beispiel der Vorhersageprüfung hierin beschrieben wird. Ferner wird eine Vorhersageprüfung für das zugehörige Register durchgeführt, SCHRITT 518. Diese Prüfung umfasst zum Beispiel das Vergleichen eines Werts des architekturdefinierten Werts, bevor die vorhandene Instruktion verarbeitet wird, wobei das zugehörige Register als Reaktion darauf mit dem von dieser vorhandenen Instruktion vorhergesagten Wert vorhergesagt wird. Die Prüfung kann eingeleitet werden, indem eine Zustandsmaschine gestartet wird, eine IOP für die Prüfung eingefügt oder veranlasst wird, dass eine Verzweigungsoperation an eine Prüfpipeline mit einem Hinweis, den zugehörigen Wert zu prüfen, abgesetzt wird. Viele Variationen sind möglich.
Weitere Einzelheiten in Verbindung mit einer Verzweigungsvorhersageprüfung werden unter Bezugnahme auf 6 beschrieben und weitere Einzelheiten einer Vorhersageprüfung, um die Vorhersage des zugehörigen Registers zu prüfen, werden unter Bezugnahme auf 7. In diesen Beispielen wird eine Registerumbenennung verwendet. Andere Ausführungen sind jedoch möglich, ohne eine Registerumbenennung zu verwenden. In einem Beispiel führt ein Prozessor diese Verarbeitung durch.
Zunächst unter Bezugnahme auf 6 wird in einem Beispiel eine Prüfung der Richtigkeit der Verzweigungsvorhersage durchgeführt, SCHRITT 600. Wenn die Verzweigungsvorhersage richtig ist, ABFRAGE 601, ist die Prüfung abgeschlossen, SCHRITT 602, und eine Wiederherstellung wird nicht durchgeführt. Wenn die Verzweigungsvorhersage jedoch falsch ist, ABFRAGE 601, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach der falsch vorhergesagten Verzweigung gelöscht, SCHRITT 604. Dies kann die Prüfung des zugehörigen Registers umfassen. Des Weiteren werden die während der Vorhersage zugeordneten Umbenennungsregister (z.B. das Zieladressregister und ein zugehöriges Register) freigegeben, wodurch die vorherigen Umbenennungsregister mit der nicht spekulativen Zieladresse und dem ursprünglichen Wert in dem zugehörigen Register sichtbar werden, SCHRITT 606. Der Instruktionsabruf wird dann an die berechnete Adresse umgeleitet, SCHRITT 608. Dies schließt eine einzelne Ausführung der Verzweigungsvorhersageprüfung ab.
In einem Beispiel kann die Vorhersage des zugehörigen Registers von der Prüfung der Verzweigungsvorhersage getrennt geprüft werden. Folglich werden weitere Einzelheiten in Bezug auf die Prüfung, durch z.B. einen Prozessor, der Vorhersage des zugehörigen Registers unter Bezugnahme auf 7. In einem Beispiel wird die Richtigkeit der Vorhersage des zugehörigen Registers geprüft, SCHRITT 700. Wenn die Vorhersage des zugehörigen Registers richtig ist, ABFRAGE 701, ist die Prüfung abgeschlossen, SCHRITT 702, und eine Wiederherstellung wird nicht durchgeführt. Wenn die Vorhersage des zugehörigen Registers jedoch falsch ist, ABFRAGE 701, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach dem falsch vorhergesagten zugehörigen Register (oder der erste Benutzer des falsch vorhergesagten zugehörigen Registers) gelöscht, SCHRITT 704, und das während der Vorhersage für das zugehörige Register zugeordnete Umbenennungsregister wird freigegeben, wodurch das vorherige Umbenennungsregister, das den nicht vorhergesagten, richtigen zugehörigen Wert enthält, sichtbar wird, SCHRITT 706. Die Ausführung wird dann an dem Löschpunkt neu gestartet, SCHRITT 708. Dies schließt ein Beispiel der Prüfung der Vorhersage des zugehörigen Registers ab.
In einem Aspekt der Prüfung einer Vorhersage vergleicht die Prüfung den vorhergesagten Wert des zugehörigen Registers mit dem aktuellsten Wert des zugehörigen Registers, der vor der Instruktion berechnet wurde, die die Vorhersage des zugehörigen Registers auslöst. In mindestens einer einzelnen Ausführungsform wird dieser Wert in einem Umbenennungsregister gespeichert.
In einer weiteren Ausführungsform wird die Wiederherstellung einer Falschvorhersage durchgeführt, indem ein Wert des zugehörigen Registers vor der Instruktion, die die Vorhersage des zugehörigen Registers auslöst, in das Umbenennungsregister kopiert wird, das zugeordnet wird, um den vorhergesagten Wert des zugehörigen Registers zu halten. In mindestens einer einzelnen Ausführungsform wird eine Wiederherstellung durch Zurückspeichern eines Werts verwendet, wenn die Freigabe eines Umbenennungsregisters aufwendiger ist als das Kopieren des richtigen Werts in das zugeordnete Umbenennungsregister.
Wie hierin beschrieben ist, werden beruhend auf der Vorhersage von Inhalten (z.B. einem Wert; einer Zieladresse) eines Registers, das für eine registerindirekte Verzweigung verwendet werden soll, die vorhergesagten Inhalte, die für die Vorhersage verwendet werden, ebenfalls (z.B. gleichzeitig) in dem Register, das für die registerindirekte Verzweigung (zusätzlich zu dem Programmzähler) verwendet werden soll, sowie in einem zugehörigen Register gespeichert, so dass der Wert von anderen Instruktionen verwendet werden kann. Dies vereinfacht die Verarbeitung.
In einem weiteren Aspekt wird eine Steuerung bereitgestellt, um anzugeben, ob ein zugehöriges Register bei der Vorhersage verwendet werden soll. Wenn angegeben wird, dass das zugehörige Register verwendet werden soll, kann die Steuerung des Weiteren eine Angabe des zugehörigen Registers, das verwendet werden soll, (z.B. eine Registernummer) enthalten. Diese Steuerung ist zum Beispiel codespezifisch und kann für jede Codeeinheit, wie etwa eine Anwendung, einen Prozess, ein Modul, eine Funktion oder ein dynamisch gemeinsam genutztes Objekt (z.B. eine Bibliothek), als Beispiele, aktiviert/deaktiviert werden.
In einem Aspekt werden eine oder mehrere Steuerungen für die Vorhersage von zugehörigen Registern bereitgestellt, bei denen ein erster Satz von Codeeinheiten von der Vorhersage von Werten von zugehörigen Registern profitiert und ein zweiter Satz von Codeeinheiten nicht profitiert. Viele Variationen sind möglich.
Als ein Beispiel wird die Steuerung in einem Maschinenzustandsregister (MSR, machine state register) bereitgestellt. Das Betriebssystem setzt die MSR-Steuerung für eine Codeeinheit und deaktiviert die MSR-Steuerung für eine weitere Codeeinheit. In einer weiteren Ausführungsform kann eine Seitentabelleneintrags-(Page Table Entry- bzw. PTE-)Steuerung bereitgestellt werden. Zum Beispiel steuert ein Bit in dem PTE die Vorhersage oder Nichtvorhersage für ein zugehöriges Register für Verzweigungen auf der Seite, auf der sich die Verzweigung befindet, wobei die Seite einer Seite entspricht, deren Adresse von dem PTE umgesetzt wird. In einer weiteren Ausführungsform steuert ein Bit in dem PTE die Vorhersage oder Nichtvorhersage eines zugehörigen Registers für Verzweigungen beruhend auf der Einstellung des Bits für die Seite der Zieladresse der Verzweigung, wobei die Adresse des Verzweigungsziels von dem PTE umgesetzt wird. In noch weiteren Ausführungsformen werden hybride Formen unterstützt, wobei das MSR-Bit zum Beispiel die Berücksichtigung eines in dem PTE gesetzten Bits ermöglicht. Viele andere Beispiele sind möglich.
In einem Beispiel einer PTE-Steuerung wird ein Bit in dem PTE durch das dynamische Ladeprogramm beruhend auf einer Angabe einer Modul- oder Seitenebene eines Programmmoduls gesetzt, die z.B. die Eigenschaften des Moduls, wie etwa die für ein bestimmtes Codesegment verwendete ABI-Ebene, beschreibt.
In mindestens einer einzelnen Ausführungsform verlinkt ein statischer Linker Module, um Funktionen gruppenweise in gemeinsame Seiten zusammenzufassen, wenn sie eine gemeinsame ABI-Ebene verwenden, und er trennt sie in separate Seiten, wenn sie keine gemeinsame ABI-Ebene verwenden.
In einer weiteren Ausführungsform nutzt ein Modul die ABI-Ebene anteilig, d.h., der Code in einem einzelnen Modul entspricht derselben ABI-Ebene, und die Ebene und die implizite Einstellung für diese Steuerung wird z.B. von einer Modul-Kopfzeile wie etwa der Signatur des ELF (Executable Linkable Format) bereitgestellt. Viele Beispiele und Varianten sind möglich. Bei den hierin beschriebenen beispielhaften Steuerungen handelt es sich lediglich um Beispiele.
Die Verwendung einer Steuerung, um anzugeben, ob eine Vorhersage von zugehörigen Registern für eine Codeeinheit verwendet werden soll, wird hierin der Einfachheit halber als eine Vorhersage eines extern angegebenen zugehörigen Registers (EIARP, externally indicated affiliated register prediction) bezeichnet. Eine einzelne Ausführungsform zur Verwendung einer Vorhersage eines extern angegebenen zugehörigen Registers für eine Codeeinheit wird unter Bezugnahme auf 8. In einem Beispiel wird diese Verarbeitung von einem Betriebssystem durchgeführt, das auf einem Prozessor einer Datenverarbeitungsumgebung ausgeführt wird.
Unter Bezugnahme auf 8 lädt das Betriebssystem zunächst eine Codeeinheit, wie beispielsweise eine Anwendung, einen Prozess, ein Modul, eine Funktion oder ein dynamisch gemeinsam genutztes Objekt usw., SCHRITT 800. Es wird festgestellt, ob die Codeeinheit (die hierin als geladener Code oder als Code bezeichnet wird) für eine codespezifische Vorhersage eines extern angegebenen zugehörigen Registers in Frage kommt, SCHRITT 802. Dies kann zum Beispiel festgestellt werden, indem die ABI-Version oder ein EIARP-Anzeiger des Codes geprüft wird, der in einer Kopfzeile oder einer Signatur des Codes, als Beispiele, bereitgestellt wird.
Wenn der Code nicht für eine Vorhersage eines extern angegebenen zugehörigen Registers in Frage kommt, ABFRAGE 804, ist die Verarbeitung abgeschlossen, SCHRITT 810. Andernfalls wird eine Angabe des zugehörigen Registers (z.B. eine Registernummer) in ein Steuerregister geladen, SCHRITT 806. Zu beispielhaften Steuerregistern gehören ein Maschinenzustandsregister (MSR, machine state register), ein Programmstatuswort (PSW), ein Spezialregister (SPR), ein Seitentabelleneintrag (PTE) auf Seitenbasis oder ein Segmenttabelleneintrag (STE, segment table entry) als nur ein paar Beispiele.
Ferner kann eine Steuerung (z.B. ein Flag oder ein anderer Anzeiger) gesetzt werden, die eine EIARP für den geladenen Code aktiviert, SCHRITT 808. In einem Beispiel wird das Flag oder ein anderer Anzeiger in einem Steuerregister oder einem anderen Steuerfeld wie beispielsweise in einem MSR, PSW, SPR, PTE oder STE als Beispiele gesetzt. Dies verringert das Risiko von übermäßigen Falschvorhersagen und Wiederherstellungsverzögerungen.
In einer weiteren Ausführungsform wird eine Steuerung gesetzt, um anzugeben, dass eine Codeeinheit keiner EIARP unterliegt, wenn die ABFRAGE 804 feststellt, dass der Code, beruhend auf den Code-Eigenschaften (z.B. der ABI-Ebene), nicht für eine Vorhersage eines zugehörigen Registers in Frage kommt.
In weiteren Ausführungsformen wird der Code von einer Programmladeroutine, einer dynamischen Programmladeroutine, einer gemeinsam genutzten Bibliotheksladeroutine, einer dynamischen Bibliotheksladeroutine oder einer anderen Systemkomponente, die für das Laden von Code ausgelegt ist, geladen.
In einer einzelnen Ausführungsform wird bei einem Kontextwechsel des Betriebssystems die Konfiguration einschließlich der codespezifischen EIARP aktualisiert (z.B. durch das Betriebssystem). Die Aktualisierung der codespezifischen EIARP aufgrund eines Kontextwechsels wird z.B. durchgeführt, wenn sich die Steuerung in einem Register befindet, das nicht ausdrücklich an die Codeeinheit gebunden ist, wie beispielsweise in einem MSR, SPR oder PSW. Da der PTE an den Code gebunden ist, braucht die EIARP-Konfiguration in einem Beispiel nicht aktualisiert zu werden. Eine einzelne Ausführungsform von Kontextwechsel-Logik in Verbindung mit der codespezifischen EIARP wird unter Bezugnahme auf 9.
Unter Bezugnahme auf 9 wird beruhend auf einem Kontextwechsel ein Wert aus dem Steuerregister des Kontexts, aus dem gewechselt wird, erhalten, SCHRITT 900, und in einer Kontextwechselstruktur gespeichert, SCHRITT 902. Eine andere Verarbeitung kann durchgeführt werden, SCHRITT 904. Ferner wird ein neuer Wert des Kontexts, in den gewechselt wird, erhalten, SCHRITT 906, und in einem Steuerregister des Kontexts gespeichert, in den gewechselt wird, SCHRITT 908.
In weiteren Ausführungsformen wird der Wert für das Steuerregister in der Kontextstruktur eines Antragstellers gespeichert, wenn der Wert anfangs festgelegt wird, z.B. in Verbindung mit der Verarbeitung der Technik von 8, und die SCHRITTE 900 und 902 werden, um die Einstellungen des Codes beizubehalten, während des Kontextwechselvorgangs weggelassen. Andere Varianten sind ebenfalls möglich.
Während der Verarbeitung kann ein Programm eine Hardware-Ausnahmebedingung (z.B. Seitenfehler, Gleitkomma-Ausnahmebedingung usw.) verwenden und über eine Unterbrechungsverarbeitung zum Betriebssystem wechseln. In einer einzelnen Ausführungsform können die Konfigurationseinstellungen bei einem Wechsel zum Betriebssystem deaktiviert werden (z.B. durch das Betriebssystem), wie unter Bezugnahme auf 10.
In einem Beispiel wird der Wert des Steuerregisters des Kontexts, aus dem gewechselt wird, erhalten, SCHRITT 1000, und in einem Ausnahmebedingungskontext gespeichert, SCHRITT 1002. Zu beispielhaften Ausnahmebedingungskontexten gehören zum Beispiel im Speicher mit geringer Kapazität für das System z oder ausgewählte Register für Power Systems, wie beispielsweise SRR0/SRR1... oder HSRR0/HSRR1... als Beispiele. Zum Ausnahmebedingungskontext können die codespezifischen EIARP- und/oder andere Konfigurationsinformationen gehören. Eine andere Verarbeitung kann durchgeführt werden, SCHRITT 1004. Des Weiteren kann optional ein Initialisierungswert eines Supervisors in einem Steuerregister wie beispielsweise in einem MSR, SPR usw. gespeichert werden, SCHRITT 1006. Eine zusätzliche und/oder andere Verarbeitung kann ebenfalls durchgeführt werden.
Nach der Behandlung der Ausnahmebedingung wird die Hardware-Ausnahmebedingungs-/Unterbrechungsverarbeitung beendet. Ein Beispiel für diese Verarbeitung, die durchgeführt wird, z.B. durch einen Prozessor, wird unter Bezugnahme auf 11. In einem Beispiel werden die codespezifischen EIARP- und/oder andere wiederherzustellende Konfigurationsinformationen aus dem Ausnahmebedingungskontext erhalten, SCHRITT 1100, und in einem ausgewählten Steuerregister (z.B. MSR, SPR, PSW usw.) gespeichert, SCHRITT 1102.
Weitere Einzelheiten der Verwendung einer codespezifischen EIARP mit Verzweigungsvorhersage werden unter Bezugnahme auf 12. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. In einer einzelnen Ausführungsform wird die Zieladresse für eine registerindirekte Verzweigung vorhergesagt, SCHRITT 1200, und der Instruktionsabruf wird an die vorhergesagte Zieladresse umgeleitet, SCHRITT 1202. Des Weiteren wird, in einem Beispiel, ein neues Umbenennungsregister für das logische Register, das die Zieladresse enthält, zugeordnet, SCHRITT 1204. Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister kopiert, SCHRITT 1206, und das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 1208.
Des Weiteren wird gemäß einem Aspekt der vorliegenden Erfindung festgestellt, ob EIARP für den Code aktiviert ist, ABFRAGE 1210. Dies wird zum Beispiel festgestellt, indem eine Steuerung geprüft wird, die angibt, ob ein zugehöriges Register für den Code vorhergesagt werden soll. Wenn EIARP für den Code nicht aktiviert ist, wird die Verarbeitung damit fortgesetzt, dass veranlasst wird, dass eine Prüfung der Verzweigungsvorhersage stattfindet, SCHRITT 1220. Andernfalls wird auch ein neues Umbenennungsregister für das zugehörige Register zugeordnet, SCHRITT 1212. Die Registernummer des zugehörigen Registers wird z.B. mittels EIARP-Konfigurationsinformationen festgestellt. Des Weiteren wird die vorhergesagte Adresse in das für das zugehörige Register zugeordnete Umbenennungsregister kopiert, SCHRITT 1214, und das Umbenennungsregister für das zugehörige Register wird als verfügbar gekennzeichnet, SCHRITT 1216.
Eine Prüfung der Vorhersage des zugehörigen Registers wird durchgeführt, um festzustellen, ob die Vorhersage des zugehörigen Registers richtig ist, SCHRITT 1218. Dies umfasst zum Beispiel das Vergleichen eines Werts des architekturdefinierten Werts, bevor die vorhandene Instruktion verarbeitet wird, wobei das zugehörige Register als Reaktion darauf mit dem von dieser vorhandenen Instruktion vorhergesagten Wert vorhergesagt wird.
Ferner wird eine Prüfung der Verzweigungsvorhersage durchgeführt, SCHRITT 1220. Beispiele für Logik zur Prüfung der Richtigkeit einer Vorhersage werden hierin beschrieben. Beispiele werden auch unter Bezugnahme auf die nachstehend beschriebenen 14 bis 15 beschrieben. Andere Beispiele sind ebenfalls möglich.
In noch einem weiteren Aspekt wird eine Vorhersage gemacht, ob ein zugehöriges Register vorhergesagt werden kann. Diese Vorhersage beruht zum Beispiel auf einer dynamischen Vorhersagefeststellung des Zugehörigkeitsstatus für ein in Frage kommendes zugehöriges Register (z.B. Verzweigungsinstruktion) Ein Prozessor stellt in einem Beispiel dynamisch den Umfang eines zugehörigen Registers für jede in Frage kommende Verzweigungsunterroutineninstruktion fest, die über ein zugehöriges Register verfügen kann. Die Verzweigungsinstruktionen, die bestimmten in Frage kommenden zugehörigen Register und die Aktivierung der dynamischen Zugehörigkeitsfeststellung können von einer Vielzahl von Steuerregistern gesteuert werden, darunter einem MSR-Bit, einem PTE-Bit, anderen Steuerregistern oder einer Kombination daraus. Dazu kann des Weiteren ein Steuerregister gehören, das einen Kandidaten für eine Zugehörigkeit oder eine Bitmaske, die mehrere Kandidaten für eine Zugehörigkeit feststellt, angibt.
Gemäß einem oder mehreren Aspekten wird ein Kandidat als zugehörig vorhergesagt und eine Vorhersage wird beruhend auf einem Prädiktor gemacht. Eine Prüfung der Vorhersage wird in dem Prozessor durchgeführt. Wenn die Vorhersage falsch war, weil das zugehörige Register nicht zugehörig ist, wird ein dynamischer Prädiktor aktualisiert, um eine zukünftige zugehörige Vorhersage zu unterdrücken.
Es gibt eine Vielzahl von Techniken, die genutzt werden können, um neue dynamische Zugehörigkeitsbeziehungen zu finden. Eine solche Technik umfasst zum Beispiel eine zufällige Annahme der Zugehörigkeit, wenn ein Prädiktor Nichtzugehörigkeit (mit einer hinreichend geringen Rate) angibt, um entweder ein tatsächlich geändertes Verhalten oder ein geändertes Verhalten aufgrund von Aliasing, bei dem eine andere Verzweigung dominant wird, zu ermitteln. Eine weitere Technik umfasst zum Beispiel Trainingsperioden, in denen das Betriebssystem festlegt, die Vorhersage von neuen Zugehörigkeiten zu erzwingen, entweder in einem festen Intervall oder als Reaktion auf bereitgestellte Änderungen, wie sie z.B. mit einer Vielzahl von dynamischen Laufzeit-Überwachungs- und Fingerabdruckabnahmetechniken festgestellt werden. Andere Techniken sind ebenfalls möglich.
In einem Aspekt wird eine Vorhersage gemacht, ob ein definiertes Register (entweder statisch definiert oder in einer EIARP-Konfiguration definiert, als Beispiele) für eine bestimmte Instanz (z.B. eine bestimmte Verzweigung) zugehörig ist. In diesem Aspekt wird eine Codeeinheit (z.B. eine Verzweigungsinstruktion) geladen und eine Nummer eines definierten Registers (z.B. R12) wird in der Hardware fest verdrahtet oder in ein Konfigurations- oder Steuerregister (z.B. MSR, PSW, SPR, PTE, STE usw.) geladen. Optional wird auch ein Flag gesetzt, um die Vorhersage für die Codeeinheit zu aktivieren.
Wenn die Registernummer in ein Konfigurations- oder Steuerregister geladen und nicht fest verdrahtet wird, wird die Verarbeitung beruhend auf einem Kontextwechsel durchgeführt, da jede Codeeinheit andere Konfigurationsinformationen haben kann. Ein Beispiel dieser Verarbeitung wird unter Bezugnahme auf 9.
Ebenso kann, wenn eine Hardware-Ausnahmebedingung verwendet und die Registernummer nicht fest verdrahtet wird, eine Verarbeitung von Ausnahmebedingungen durchgeführt werden, wie in einer einzelnen Ausführungsform unter Bezugnahme auf die 10 und 11 beschrieben ist.
Ein Beispiel einer Vorhersagetechnik für eine registerindirekte Verzweigung, die auch vorhersagt, ob ein definiertes Register zugehörig ist, wird unter Bezugnahme auf 13. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. In einem Beispiel wird die Zieladresse für eine registerindirekte Verzweigung zunächst vorhergesagt, SCHRITT 1300, und der Instruktionsabruf wird an die vorhergesagte Zieladresse umgeleitet, SCHRITT 1302. Des Weiteren wird in einem Beispiel ein neues Umbenennungsregister für das logische Register zugeordnet, das die Zieladresse enthält, SCHRITT 1304. Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister kopiert, SCHRITT 1306, und das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 1308.
Des Weiteren wird festgestellt, ob der zugehörige Wert vorhergesagt werden kann, ABFRAGE 1310. Kann, zum Beispiel, das zugehörige Register vorhergesagt werden? Wenn nicht, fährt die Verarbeitung damit fort, dass sie veranlasst, dass eine Verzweigungsvorhersageprüfung stattfindet, SCHRITT 1320. Andernfalls wird, in einer Ausführungsform, ein neues Umbenennungsregister für das zugehörige Register, das vorhergesagt wird, zugeordnet, SCHRITT 1312. Die Registernummer des zugehörigen Registers kann fest verdrahtet oder mittels EIARP-Konfigurationsinformationen festgestellt werden, als Beispiele.
Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister für das zugehörige Register kopiert, SCHRITT 1314, und das Umbenennungsregister für das zugehörige Register wird als verfügbar gekennzeichnet, SCHRITT 1316.
Eine Prüfung der Vorhersage des zugehörigen Registers wird durchgeführt, um festzustellen, ob die Vorhersage richtig ist, SCHRITT 1318, sowie eine Prüfung der Verzweigungsvorhersage, SCHRITT 1320, wie hierin beschrieben ist. Bei einer Falschvorhersage wird eine Wiederherstellung durchgeführt, wie unter Bezugnahme auf die 14 bis 15 beschrieben ist. In einem Beispiel führt ein Prozessor diese Verarbeitung durch.
In einer oder mehreren Ausführungsformen kann die ABFRAGE 1310 einer Überschreibung einer Steuerung unterliegen, um neue zugehörige Register zu erkennen. In einer einzelnen Ausführungsform wird die ABFRAGE 1310 zur Angabe eines zugehörigen Registers während einer Trainingsphase gezwungen. Eine Trainingsphase kann zum Beispiel einer festen oder konfigurierbaren Anzahl von Zyklen entsprechen, nachdem eine Anwendung geladen wurde. In einem weiteren Beispiel kann eine Trainingsphase zum Beispiel einer festen oder konfigurierbaren Anzahl von Zyklen nach einer Angabe, eine Trainingsphase zu starten, entsprechen. In einem Beispiel kann eine Trainingsstart-Angabe einem zufällig erzeugten Signal mit einer festen oder konfigurierbaren Wahrscheinlichkeit entsprechen. In einem weiteren Beispiel kann eine Trainingsstart-Angabe dem Verstreichen eines angegebenen Intervalls seit der letzten Trainingsphase, z.B. einer festen oder konfigurierbaren Anzahl von Zyklen oder einer festen oder konfigurierbaren Anzahl von Nanosekunden, Mikrosekunden oder einer anderen Zeiteinheit, entsprechen. In einer weiteren Ausführungsform gibt die ABFRAGE 1310 das Vorhandensein eines zugehörigen Registers für eine erste Anzahl von Ausführungen einer Verzweigung an; wobei die erste Anzahl fest oder konfigurierbar ist. Noch weitere Ausführungsformen können andere bekannte oder zukünftige Techniken nutzen, um einen Prädiktor für zugehörige Register zu trainieren.
Unter Bezugnahme auf 14 wird im Falle einer Verzweigungs-Falschvorhersage in diesem Beispiel definitionsgemäß die Vorhersage des zugehörigen Werts oder die Vorhersage in Bezug auf den zugehörigen Wert ebenfalls falsch vorhergesagt. Die Prüfung umfasst zum Beispiel die Feststellung der Richtigkeit der Verzweigungsvorhersage, SCHRITT 1400. Wenn die Verzweigungsvorhersage richtig ist, ABFRAGE 1401, ist die Prüfung abgeschlossen, SCHRITT 1402, und eine Wiederherstellung wird nicht durchgeführt. Wenn die Verzweigungsvorhersage jedoch falsch ist, ABFRAGE 1401, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach der falsch vorhergesagten Verzweigung gelöscht, SCHRITT 1404. Dazu kann das Löschen der Prüfung des zugehörigen Registers gehören. Des Weiteren werden die während der Vorhersage zugeordneten Umbenennungsregister freigegeben, wodurch die vorherigen Umbenennungsregister sichtbar werden, SCHRITT 1406. Dazu kann die Freigabe des Zieladressregisters sowie des zugehörigen Registers gehören, wenn EIARP aktiviert ist, wodurch die vorherigen Umbenennungsregister mit der nicht spekulativen Zieladresse und dem ursprünglichen Wert in dem zugehörigen Register sichtbar werden. Der Instruktionsabruf wird dann an die berechnete Adresse umgeleitet, SCHRITT 1408. Dies schließt eine einzelne Ausführung der Vorhersageprüfung ab.
Ferner kann in einer einzelnen Ausführungsform, wenn EIARP aktiviert ist, eine Prüfung auf Richtigkeit der Vorhersage des zugehörigen Registers aufgerufen werden, wie unter Bezugnahme auf 15. In einer einzelnen Ausführungsform wird eine Prüfung der Richtigkeit der Vorhersage eines zugehörigen Registers durchgeführt, SCHRITT 1500. Wenn die Vorhersage des zugehörigen Registers richtig ist, ABFRAGE 1501, ist die Prüfung abgeschlossen, SCHRITT 1502, und eine Wiederherstellung wird nicht durchgeführt. Wenn die Vorhersage des zugehörigen Registers jedoch falsch ist, ABFRAGE 1501, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach dem falsch vorhergesagten zugehörigen Register gelöscht, SCHRITT 1504. In einem weiteren Beispiel wird der erste Benutzer des falsch vorhergesagten zugehörigen Registers im SCHRITT 1504 gelöscht. Ferner wird das während einer Vorhersage für das zugehörige Register zugeordnete Umbenennungsregister freigegeben, wodurch das vorherige Umbenennungsregister, das den nicht vorhergesagten richtigen zugehörigen Wert enthält, sichtbar wird, SCHRITT 1506. Die Ausführung wird dann an dem Löschpunkt neu gestartet, SCHRITT 1508. Dies schließt ein Beispiel der Prüfung der Vorhersage des zugehörigen Registers ab.
In noch einer weiteren Ausführungsform kann, wenn ein Prädiktor verwendet wird, um vorherzusagen, ob ein zugehöriger Wert (z.B. ein zugehöriges Register) vorhergesagt werden kann, auch eine mit dieser Vorhersage verbundene Aktualisierung des Prädiktors durchgeführt werden, wie unter Bezugnahme auf 16. In einem Beispiel führt ein Prozessor diese Verarbeitung durch.
Unter Bezugnahme auf 16 wird in einer einzelnen Ausführungsform eine Prüfung der Richtigkeit der Vorhersage eines zugehörigen Registers durchgeführt, SCHRITT 1600. Wenn die Vorhersage, ob das zugehörige Register vorhergesagt werden kann, richtig ist, ABFRAGE 1601, kann der Zugehörigkeitsprädiktor aktualisiert werden, um eine richtige Vorhersage anzugeben, SCHRITT 1602, und eine Wiederherstellung wird nicht durchgeführt. In einem weiteren Beispiel braucht keine Aktualisierung durchgeführt zu werden.
Wenn die Vorhersage, ob das zugehörige Register vorhergesagt werden kann, jedoch falsch ist, ABFRAGE 1601, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach dem falsch vorhergesagten zugehörigen Register gelöscht, SCHRITT 1604. In einer weiteren Ausführungsform wird der erste Benutzer eines falsch vorhergesagten zugehörigen Registers im SCHRITT 1604 gelöscht. Ferner wird das während einer Vorhersage für das zugehörige Register zugeordnete Umbenennungsregister freigegeben, wodurch das vorherige Umbenennungsregister, das den nicht vorhergesagten richtigen zugehörigen Wert enthält, sichtbar wird, SCHRITT 1606. Des Weiteren wird der Zugehörigkeitsprädiktor in einem Beispiel aktualisiert, um eine falsche Vorhersage anzugeben, SCHRITT 1608. Die Ausführung wird dann an dem Löschpunkt neu gestartet, SCHRITT 1610. Dies schließt eine einzelne Ausführung der Vorhersageprüfung ab.
In einer alternativen Ausführungsform wird der in dem falsch vorhergesagten zugehörigen Register gespeicherte Wert in das Umbenennungsregister kopiert, anstatt das Umbenennungsregister freizugeben. Weitere Variationen sind möglich.
In einem weiteren Aspekt wird eine Vorhersage gemacht, ob ein Register für eine bestimmte Instanz zugehörig ist, und eine weitere Vorhersage wird hinsichtlich der Registernummer und einer weiteren Kennung gemacht. Ein Beispiel dieser Verarbeitung wird unter Bezugnahme auf 17. In einem Beispiel führt ein Prozessor diese Verarbeitung durch.
Unter Bezugnahme auf 17 wird zunächst die Zieladresse für eine registerindirekte Verzweigung vorhergesagt, SCHRITT 1700, und der Instruktionsabruf wird an die vorhergesagte Zieladresse umgeleitet, SCHRITT 1702. Des Weiteren wird in einem Beispiel ein neues Umbenennungsregister für das logische Register zugeordnet, das die Zieladresse enthält, SCHRITT 1704. Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister kopiert, SCHRITT 1706, und das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 1708.
Des Weiteren wird gemäß einem Aspekt festgestellt, ob der zugehörige Wert vorhergesagt werden kann, ABFRAGE 1710. Wenn nicht, fährt die Verarbeitung damit fort, dass sie veranlasst, dass eine Verzweigungsvorhersageprüfung stattfindet, SCHRITT 1726. Andernfalls wird festgestellt, ob eine neue Registerkennung (z.B. eine Nummer) als das vorhergesagte zugehörige Register ausgewählt werden soll, ABFRAGE 1712. Wenn nicht, wird eine Angabe eines vorhergesagten zugehörigen Registers, die z.B. von einem Prädiktor gemacht wird, als das zugehörige Register ausgewählt, SCHRITT 1714; andernfalls wird ein anderes Register, z.B. eine andere Registernummer) ausgewählt, SCHRITT 1716. Daraufhin wird ein neues Umbenennungsregister für das ausgewählte zugehörige Register (das z.B. die ausgewählte Registernummer hat) zugeordnet, SCHRITT 1718.
Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister für das zugehörige Register kopiert, SCHRITT 1720, und das Umbenennungsregister für das zugehörige Register wird als verfügbar gekennzeichnet, SCHRITT 1722.
Eine Prüfung der Vorhersage des zugehörigen Registers wird durchgeführt, um festzustellen, ob die zu dem zugehörigen Register gehörende Vorhersage richtig ist, SCHRITT 1724, sowie eine Prüfung der Verzweigungsvorhersage, SCHRITT 1726, wie hierin beschrieben ist.
In mindestens einer einzelnen Ausführungsform entspricht die ABFRAGE 1712 einem Test, ob ein Vorhersagevertrauen einen Schwellenwert überschreitet. Das Vorhersagevertrauen kann zum Beispiel einem bekannten Vertrauenswert von 1 oder mehr Bits entsprechen. Der Schwellenwert kann fest oder softwarekonfiguriert sein.
Eine Vorhersageprüfung kann auch durchgeführt werden, um festzustellen, ob das ausgewählte zugehörige Register richtig ist, wie unter Bezugnahme auf 18. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. In einer einzelnen Ausführungsform wird eine Prüfung der Richtigkeit der Vorhersage eines zugehörigen Registers durchgeführt, SCHRITT 1800. Wenn die Vorhersage des ausgewählten zugehörigen Registers richtig ist, ABFRAGE 1801, kann der Zugehörigkeitsprädiktor aktualisiert werden, um eine richtige Vorhersage des Registers anzugeben, das als das zugehörige Register verwendet wird, SCHRITT 1802, und eine Wiederherstellung wird nicht durchgeführt. In einer weiteren Ausführungsform wird der Prädiktor nicht aktualisiert.
Wenn die Vorhersage des ausgewählten zugehörigen Registers jedoch falsch ist, ABFRAGE 1801, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach dem falsch vorhergesagten zugehörigen Register gelöscht, SCHRITT 1804. In einer weiteren Ausführungsform wird der erste Benutzer des falsch vorhergesagten zugehörigen Registers im SCHRITT 1804 gelöscht. Ferner wird das während einer Vorhersage für das zugehörige Register zugeordnete Umbenennungsregister freigegeben, wodurch das vorherige Umbenennungsregister, das den nicht vorhergesagten richtigen zugehörigen Wert enthält, sichtbar wird, SCHRITT 1806. Des Weiteren wird der Zugehörigkeitsprädiktor in einem Beispiel aktualisiert, um eine falsche Vorhersage des bestimmten Registers, das als das zugehörige Register verwendet werden soll, anzugeben, SCHRITT 1808. Die Ausführung wird dann an dem Löschpunkt neu gestartet, SCHRITT 1810. Dies schließt eine Ausführung der Prüfung der Vorhersage des zugehörigen Registers ab.
Gemäß einem weiteren Aspekt werden zugehörige Register erkannt, indem eine Abfolge von Instruktionen erkannt wird. In einem Beispiel enthält die Abfolge eine erste Instruktion, die so ausgelegt ist, dass sie eine zugehörige Beziehung erzeugt, und eine zweite Instruktion, die so ausgelegt ist, dass sie eine Unterroutinen-Verzweigung durchführt. In einem Beispiel enthält die Abfolge:

mtctr        R12
bctrl

Diese Abfolge wird als eine Abfolge erkannt, die sowohl die eine Zugehörigkeit erstellende Verschiebeoperation als auch den Unterroutinen-Aufruf durchführt. In einer einzelnen Ausführungsform wird die eine Zugehörigkeit erstellende Abfolge in eine Fusionsabfolge von Operationen umgesetzt, welche die Verschiebeoperation durchführt, und sie erstellt eine Verzweigung mit einer Zugehörigkeitsvorhersage.

Beruhend auf dem Erkennen der vorstehenden Abfolge (oder einer ähnlichen Abfolge) wird eine Fusionsabfolge von Operationen erzeugt, die die Verschiebeoperation durchführt und die Verzweigung vornimmt. Als Beispiele kann eine vereinfachte Abfolge erzeugt werden, z.B. mit R12 fest verdrahtet oder mit EIARP; oder eine erweiterte Fusionsabfolge kann erzeugt werden, die eine Prüfung der vorhergesagten Verzweigungsadresse umfasst, so dass die Kosten der MTCTR-Instruktion insgesamt vermieden werden. Ein Beispiel einer erweiterten Abfolge wird unter Bezugnahme auf 19. In einer einzelnen Ausführungsform wird diese Verarbeitung von einem Decodierer durchgeführt.

Zunächst wird festgestellt, ob eine Möglichkeit einer Fusionsabfolge erkannt wurde, ABFRAGE 1900. Hat der Decodierer zum Beispiel MTCTR gefolgt von BCTRL, als Beispiel, erkannt? Wenn keine Möglichkeit einer Fusionsabfolge erkannt wurde, ist die Verarbeitung der Fusionserzeugung abgeschlossen. Andernfalls wird die Verarbeitung der Fusionserzeugung fortgesetzt. Eine Verzweigungszieladresse wird vorhergesagt, SCHRITT 1902. Die Zieladresse wird in einen Programmzähler (PC, program counter) geladen, so dass die Verarbeitung mit der Ausführung an der Zieladresse beginnen kann, SCHRITT 1904. Des Weiteren wird die vorhergesagte Zieladresse sowohl in das CTR-Register geladen, SCHRITT 1906, als auch in ein zugehöriges Register (z.B. R12), SCHRITT 1908. Da dies ein Unterroutinen-Aufruf ist, wird eine Rückkehradresse in ein Verbindungsregister (LR, link register) geladen, SCHRITT 1910. Ferner wird eine Prüfung der vorhergesagten Zieladresse durchgeführt, SCHRITT 1912. In einem Beispiel erfolgt diese Prüfung im Hinblick auf die Quelle von MTCTR, bei der es sich um den Wert von R12 handelt.

In einem Beispiel wird die Nummer (z.B. R12) des zugehörigen Registers als das zugehörige Register fest verdrahtet. In einem weiteren Beispiel wird das zugehörige Register in einer Steuerung, wie beispielsweise in einem ausgewählten Steuerregister, angegeben. In noch einem weiteren Beispiel wird es beruhend auf der Abfolge der Instruktionen dynamisch festgestellt (z.B. die nach MTCTR angegebene Registernummer). Andere Beispiele sind ebenfalls möglich. Bei der vorstehenden Abfolge braucht MTCTR nicht ausgeführt zu werden, da die Vorhersage den Wert überschreibt und das zugehörige Register und die vorhergesagte Zieladresse werden in einem Beispiel gleichzeitig geprüft. Weitere Variationen sind möglich.

In einer einzelnen beispielhaften Ausführungsform können die Operationen der Technik von 19 ausgedrückt werden, indem eine beispielhafte iop-Abfolge erzeugt wird, wie beispielsweise:

       mtctr R12
       old ctr=ctr
       update_Ir_from_instruction_address+
       predict_indirect_ctr+
       update_pc_from_prediction+
       update_ctr_from_prediction+
       update_affiliated_reg_from_prediction (R12)
       check_target_address (old_ctr)

In einer weiteren Ausführungsform wird die Kopie von R12 unterdrückt und eine vereinfachte iop-Abfolge wird erzeugt:

       old_affiliated=R12+
       update_Ir_from_instruction_address+
       predict_indirect_ctr+
       update_pc_from_prediction+
       update_ctr_from_prediction+
       update_affiliated_reg_from_prediciton (R12)
       check_target_address (old_affiliated)

In einer Vielzahl von Ausführungsformen erzeugt die Vorhersage-iop eine einzelne Vorhersage, die zur Aktualisierung des Programmzählers (d.h. PC - der Adresse, von der Instruktionen abgerufen werden), des Verzweigungszielregisters (ctr in diesem Beispiel) und eines zugehörigen Registers (R12 in diesem Beispiel) verwendet werden kann. In dieser bestimmten Ausführungsform ist die Vorhersage-iop auch so ausgelegt, dass sie den PC vor der Aktualisierung mit der Vorhersage erfasst, um eine Unterroutinen-Rückkehradresse, z.B. im Verbindungsregister (LR) zu erfassen. In einer weiteren Ausführungsform kann das Erfassen des PC in dem Verbindungsregister (LR) von einer gesonderten iop durchgeführt werden.

In diesen Beispielen wird das + verwendet, um die Performanz von mehreren Operationen in einer einzelnen iop anzugeben, wobei die beschreibenden Komponenten durch das +-Zeichen verbunden sind. Zum Beispiel aktualisiert update_pc_from_prediction den Programmzähler (PC) mit der von dem Prädiktor vorhergesagten Adresse.

In einer einzelnen Ausführungsform mit einem extern angegebenen zugehörigen Register beruht das Erkennen einer Fusionsabfolge auf dem Erkennen einer Abfolge, die ein in einem Konfigurationsregister angegebenes Register enthält. Vor dem Erkennen einer fusionsbasierten zugehörigen Abfolge wird ein zugehöriges Register angegeben, das ein Steuerregister für eine externe Angabe der zugehörigen Registerabfolge verwendet, die erkannt werden soll. Ein Beispiel für diese Verarbeitung, die durchgeführt wird, z.B. durch einen Prozessor, wird unter Bezugnahme auf 20. In einer weiteren Ausführungsform ist die Abfolge, die die Beziehung des zugehörigen Registers festlegt und die Nummer des zugehörigen Registers enthält, fest (oder „fest verdrahtet“) in der Prozessorlogik und die Technik von 20 wird in einer solchen Ausführungsform nicht durchgeführt.

Unter Bezugnahme auf 20 wird zunächst der Code (wie beispielsweise Code, der eine oder mehrere fusionierbare Abfolgen enthält, die eine Beziehung eines zugehörigen Registers festlegen) geladen, SCHRITT 2000. Des Weiteren wird eine Registernummer, die einem Register entspricht, das in einer eine Zugehörigkeit erzeugenden Abfolge auftreten kann, die erkannt werden soll, geladen, SCHRITT 2010. Des Weiteren wird optional ein Flag gesetzt, um EIARP zu aktivieren, SCHRITT 2020. Da nur Abfolgen umgesetzt werden, die als Beziehungen von zugehörigen Registern festlegende Abfolgen erkannt werden, besteht kein Risiko übermäßiger Falschvorhersagen und daher ist eine Einrichtung, um die Vorhersage von zugehörigen Registern zu aktivieren oder zu deaktivieren, in einer oder mehreren Ausführungsformen gegebenenfalls nicht vorhanden. In weiteren Ausführungsformen kann ein Flag, um die Vorhersage des Werts eines zugehörigen Registers zu aktivieren oder zu deaktivieren, als Sicherheitsmerkmal bereitgestellt werden, z.B. im Falle einer falschen Ausführung der Logik für das Vorhersagen des zugehörigen Registers. Andere Varianten sind ebenfalls möglich. Andere Varianten sind ebenfalls möglich.

Wenn das Register, das als ein zugehöriges Register verwendet werden soll, nicht fest verdrahtet ist, sondern stattdessen in einer Steuerung angegeben wird, werden die Konfigurationsinformationen, darunter eine Angabe des zugehörigen Registers, für eine spätere Wiederherstellung beruhend auf einem Kontextwechsel gespeichert. Eine einzelne Ausführungsform dieser Verarbeitung ist vorstehend unter Bezugnahme auf 9. Ebenso wird die Verarbeitung bei Verwendung einer Hardware-Ausnahmebedingung durchgeführt, wie unter Bezugnahme auf die 10 bis 11 beschrieben ist. Wenn die Registernummer jedoch fest verdrahtet ist, ist diese Verarbeitung optional.

Eine einzelne Ausführungsform einer Verzweigungsvorhersage mit einer fusionsbasierten zugehörigen Abfolge wird unter Bezugnahme auf 21. In einem Beispiel führt ein Prozessor diese Verarbeitung durch.

Unter Bezugnahme auf 21 wird ein Schritt, der eine Fusionsmöglichkeit erkennt, durchgeführt, SCHRITT 2100. Zum Beispiel wird von dem Decodierer eine Prüfung auf eine Abfolge von MTCTR Rx/BCTRL vorgenommen, wobei Rx einem Register entspricht, für das eine Zugehörigkeitsbeziehung mit der Verzweigungszieladresse erkannt werden kann. In einer beispielhaften Abfolge kann das Register Rx dem Register R12 entsprechen. Beruhend auf der Durchführung eines Erkennungsschritts für eine eine Zugehörigkeit erstellende Abfolge, die fusioniert werden kann, wird festgestellt, ob eine solche Möglichkeit einer Fusionsabfolge erkannt wird, ABFRAGE 2102. Das heißt, ist eine Abfolge von MTCTR Rx und BCTRL in dem Codestrom vorhanden und stimmt Rx von MTCTR mit einer erwarteten Registernummer, wie beispielsweise einer Nummer eines fest verdrahteten zugehörigen Registers, oder einer in einer Steuerung, z.B. der EIARP-Steuerung, bereitgestellten Nummer, als Beispiele, überein? Wenn keine Möglichkeit einer Fusionsabfolge erkannt wird, wird eine herkömmliche Verarbeitung durchgeführt, SCHRITT 2104. Andernfalls wird die Verarbeitung mit der Vorhersage der Zieladresse für eine registerindirekte Verzweigung, SCHRITT 2106, und der Umleitung des Instruktionsabrufs an die vorhergesagte Zieladresse, SCHRITT 2108, fortgesetzt. Des Weiteren wird, in einem Beispiel, ein neues Umbenennungsregister für das logische Register, das die Zieladresse enthält, zugeordnet, SCHRITT 2110. Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister kopiert, SCHRITT 2112, und das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 2114.

Ferner wird ein neues Umbenennungsregister für das zugehörige Register (z.B. das Register Rx, das in der eine Zugehörigkeit erstellenden Fusionsabfolge angegeben ist) zugeordnet, SCHRITT 2116. Die vorhergesagte Adresse wird in das für das zugehörige Register zugeordnete Umbenennungsregister kopiert, SCHRITT 2118, und das Umbenennungsregister für das zugehörige Register wird als verfügbar gekennzeichnet, SCHRITT 2120.

Eine Prüfung der Vorhersage der vorhergesagten Adresse wird durchgeführt, um festzustellen, ob die Vorhersage richtig ist, SCHRITT 2122. Dazu gehört zum Beispiel das Vergleichen der Zieladresse mit einem Wert des zugehörigen Registers (Rx) vor der Fusionsabfolge (z.B. unter Verwendung ihres vorherigen Umbenennungsregisters). Wenn die Vorhersage falsch ist, wird eine Wiederherstellung durchgeführt, wie hierin beschrieben ist. Ein Beispiel einer solchen Wiederherstellung ist unter Bezugnahme auf 14 beschrieben.

In weiteren Ausführungsformen wird die Nummer des zugehörigen Registers nicht fest verdrahtet oder von einer Steuerung (d.h. EIARP) bereitgestellt, sondern von der Abfolge selbst festgestellt (z.B. eine nach MTCTR angegebene Registernummer). In einer einzelnen solchen beispielhaften Ausführungsform prüft die ABFRAGE 2102, ob eine Abfolge von MTCTR, RX und BCTRL in dem Codestrom vorhanden ist. Wenn die Abfolge vorhanden ist, wird das in der Abfolge angegebene bestimmte Register RX als das zugehörige Register verwendet. In einer einzelnen solchen Ausführungsform sind die Code-Ladetechnik und die EIARP-Konfigurationstechnik, wie beispielsweise diejenige von 8 oder 20, nicht notwendig, und die Vorhersage eines zugehörigen Registers kann in Verbindung mit herkömmlichen Code-Ladetechniken betrieben werden. Des Weiteren ist das Sichern von Informationen eines zugehörigen Registers über einen Kontextwechsel und/oder das Durchführen einer Verarbeitung von Hardware-Ausnahmebedingungen nicht erforderlich, und die Vorhersage eines zugehörigen Registers kann in Verbindung mit herkömmlichen Kontextwechsel-Abfolgen und einer herkömmlichen Verarbeitung von Hardware-Ausnahmebedingungen in mindestens einer einzelnen Ausführungsform betrieben werden.

In dem vorstehenden Beispiel einer Abfolge von Instruktionen befinden sich die MTCTR- und BCTRL-Instruktionen in einer Reihenfolge. Gemäß einem weiteren Aspekt wird eine Zugehörigkeit jedoch selbst dann vorhergesagt, wenn sich die Instruktionen nicht in einer Reihenfolge befinden. Zum Beispiel sei der folgende Code angenommen:

       mtctr        R12
       <instructions...>
       Bctrl

Der vorstehende Code wird als ein Code erkannt, der sowohl die eine Zugehörigkeit erstellende Verschiebeoperation als auch den Unterroutinen-Aufruf durchführt. Somit wird beruhend darauf, dass eine Instruktion erkannt wird, die eine Zugehörigkeit erstellt (z.B. MTCTR), ein Anzeiger gesetzt. Der Anzeiger kann des Weiteren die Nummer (oder eine andere Angabe) des zugehörigen Registers angeben. Wenn eine Operation erkannt wird, die die Zugehörigkeit löscht (z.B. entweder den Inhalt des CTR oder des Registers ändert, welches die Quelle von MTCTR war), wird der Anzeiger sodann zurückgesetzt. Wenn eine BCTRL angetroffen wird, wird sie als eine Verzweigung mit einem zugehörigen Register angegeben, sofern eine Zugehörigkeitsangabe aktiv ist, wobei optional des Weiteren die Nummer des Registers angegeben wird, zu dem eine Zugehörigkeit besteht.

Eine einzelne Ausführungsform der Verarbeitung in Verbindung mit der Feststellung einer Zugehörigkeit, die auf einer dynamischen Steuerungsanalyse zur Laufzeit beruht, wird unter Bezugnahme auf 22. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. Die Technik von 22 wird an jeder Instruktion der Instruktionsstrom-Abfolge durchgeführt, um eine Zugehörigkeit eines Registers zu einem Verzweigungszielregister einer Verzweigung, Verzweigungen, für die ein zugehöriges Register vorhergesagt werden soll, sowie die Registernummer des zugehörigen Registers zu ermitteln. Erkannte Zugehörigkeitsbeziehungen werden von der Ausführung der Technik von 22 für eine Instruktion zur Ausführung dieser Technik für die nächste Instruktion weitergegeben, bis eine Zugehörigkeit entweder aufgehoben oder eine registerindirekte Verzweigung erkannt wird, in Verbindung mit welcher die Vorhersage des Werts eines zugehörigen Registers durchgeführt werden soll. Diese Verarbeitung wird in einem Beispiel von dem Instruktionsdecodierer durchgeführt.

Unter Bezugnahme auf 22 wird in einer einzelnen Ausführungsform eine Instruktion empfangen, SCHRITT 2200, und decodiert, SCHRITT 2202. Es wird festgestellt, ob es sich bei der Instruktion um eine eine Zugehörigkeit erstellende Instruktion, wie beispielsweise eine MTCTR, handelt, ABFRAGE 2204. Wenn es eine eine Zugehörigkeit erstellende Instruktion ist, wird jede beliebige bisherige Zugehörigkeit aufgehoben und die neue Zugehörigkeit wird verzeichnet (es wird z.B. ein Anzeiger gesetzt), SCHRITT 2206. Wenn die Instruktion jedoch keine Instruktion ist, die eine Zugehörigkeit erstellt, wird des Weiteren festgestellt, ob die Instruktion eine Instruktion ist, die eine Zugehörigkeit löscht (z.B. eine Instruktion, die entweder die Quelle oder das Ziel der Zugehörigkeitsbeziehung überschreibt, z.B. entweder das Quellenregister von MTCTR, das die Zugehörigkeit festgelegt hat, oder aber das Zählregister, CTR), ABFRAGE 2208. Wenn es eine eine Zugehörigkeit löschende Instruktion ist, wird die Zugehörigkeit aufgehoben (z.B. wird der Anzeiger zurückgesetzt), SCHRITT 2210.

Wenn die Instruktion keine Instruktion ist, die eine Zugehörigkeit erstellt oder eine Zugehörigkeit löscht, wird diese Verarbeitung mit der ABFRAGE 2212 fortgesetzt, die prüft, ob die vorhandene Instruktion eine registerindirekte Verzweigungsinstruktion ist und eine Zugehörigkeit gerade aktiv ist. Wenn die ABFRAGE 2212 positiv ist, wurde eine registerindirekte Verzweigungsinstruktion mit einem zugehörigen Register erkannt, und die Steuerung schaltet zum SCHRITT 2214. Andernfalls endet die Technik für die vorhandene Instruktion.

Im SCHRITT 2214 wurde eine registerindirekte Verzweigungsinstruktion erkannt, wenn eine Zugehörigkeitsbeziehung zwischen einem registerindirekten Verzweigungszielregister (wie beispielsweise dem Zählerregister, ctr) und einem anderen Register aktiv ist. Um die Vorhersage des Werts des erkannten zugehörigen Registers zu vereinfachen, wird das Vorhandensein eines zugehörigen Registers in Verbindung mit der Verzweigungsinstruktion angegeben, und die Registernummer des zugehörigen Registers wird verzeichnet, um die Vorhersage des Werts des zugehörigen Registers in Verbindung mit der Verzweigungsverarbeitung für die vorhandene Verzweigung zu vereinfachen. Die Technik von 22 endet für die vorhandene Instruktion.

Wenn die Technik von 22 für eine Instruktion, die für einen Prozessor verarbeitet wird (z.B. nach den SCHRITTEN 2206, 2210, 2212 bzw. 2214), beendet wird, wird die Verarbeitung an der nächsten abgerufenen Instruktion durchgeführt. Die verzeichneten Zugehörigkeitsinformationen werden von einer Ausführung der Technik von 22 zur nächsten Ausführung für die nächste Instruktion in dem Instruktionsstrom weitergegeben.

Beruhend auf der Feststellung der Abfolge einer eine Zugehörigkeit erstellenden Verschiebeoperation und einer nachfolgenden Verzweigung gemäß dem SCHRITT 2214, wird, obgleich sie durch eine oder mehrere andere Instruktionen getrennt sein können, beruhend auf der eine Zugehörigkeit erstellenden Verschiebeoperation und der Verzweigung eine Fusionsabfolge erzeugt, wie vorstehend beschrieben wurde. Als Beispiel kann die Verarbeitung von 19 sowie der 20 bis 21 zusätzlich zu der Wiederherstellung durchgeführt werden, wie unter Bezugnahme auf 14. Eine andere mit Fusion und/oder Vorhersageverzweigung beschriebene Verarbeitung kann in einer oder mehreren Ausführungsformen ebenfalls durchgeführt werden.

Wie hierin beschrieben ist, kann in einer einzelnen Ausführungsform, um die Kosten für die Durchführung einer Verschiebeoperation von einer Zählerinstruktion, MFCTR (die den Wert aus dem CTR in ein ausgewähltes Register (z.B. R12) verschiebt), zu vermeiden, wenn der CTR-Wert vorhergesagt wird, eine ABI das Vorhandensein des Werts des CTR in einem allgemeinen Register (z.B. dem Register R12 gemäß der bekannten ELFv2 ABI der Power Architecture) angeben, und der vorhergesagte Wert wird von einem Prozessor in das CTR und das ausgewählte Register (z.B. R12) geschrieben, wenn eine Abfolge, die der ABI-Funktionsaufrufabfolge entspricht, welche ein zugehöriges Register (wie beispielsweise R12) verwendet, um die Adresse der aufgerufenen Funktion an die aufgerufene Funktion zu übertragen, gemäß einem Aspekt der vorliegenden Erfindung erkannt wird.

Dieses ausgewählte Register wird hierin als ein zugehöriges Register bezeichnet. In einem Beispiel wird der Wert des ausgewählten Registers verwendet, um einen anderen Wert, wie beispielsweise einen Zeiger auf ein Inhaltsverzeichnis (TOC, table of contents) oder eine globale Offsettabelle (GOT, global offset table), gemäß allgemein bekannten ABI-Spezifikationen, wie beispielsweise der ELF v2 ABI der Power Architecture, festzustellen. Dieser andere Wert wird in einem anderen ausgewählten Register, wie etwa R2, gespeichert. Der Wert des anderen ausgewählten Registers, R2, wird zum Beispiel erhalten, indem ein Offset zu dem Wert in dem ausgewählten Register (z.B. R12) addiert wird. Der Wert des anderen ausgewählten Registers (z.B. R2) wird dann zum Beispiel als ein Zeiger auf das TOC oder die GOT verwendet, das bzw. die Zugriff auf Variablen bereitstellt. Im Einzelnen erzeugt ein Compiler Objektcode aus Quellcode, ohne die endgültige Adresse oder die Verschiebung des Codes/der Daten zu kennen. Insbesondere erzeugt der Compiler Objektcode, der auf eine Referenzdatenstruktur einer Variablenadresse (z.B. eine Global Offset Table oder ein Table of Contents (TOC)) für Variablenwerte zugreift, ohne die endgültige Größe der Datenstruktur oder Offsets/Adressen von verschiedenen Datenabschnitten zu kennen. Platzhalter für diese Informationen verbleiben im Objektcode und werden von einem Linker aktualisiert.

Da der Wert des zugehörigen Registers (z.B. R12) vorhergesagt wird und der Offset bekannt oder feststellbar ist, wird der Wert des anderen ausgewählten Registers gemäß einem Aspekt als ein zugehöriger abgeleiteter Wert vorhergesagt.

In einer Ausführung ist die Konfiguration und die Verarbeitung des zugehörigen abgeleiteten Werts ähnlich der Konfiguration und der Verarbeitung des zugehörigen Werts. Eine Angabe des zugehörigen abgeleiteten Werts (z.B. der Registernummer wie beispielsweise R2) kann zum Beispiel fest verdrahtet oder in einem Steuerregister oder einem anderen Steuerfeld wie beispielsweise einem MSR, SPR, PSW, PTE, STE usw. gespeichert sein. Des Weiteren kann, wenn der Code für EIARP in Frage kommt, die Registernummer des zugehörigen abgeleiteten Registers geladen werden (z.B. SCHRITT 806 von 8). Als weitere Beispiele kann der Wert gespeichert und bei einem Kontextwechsel zurückgespeichert werden, wie in einem Beispiel unter Bezugnahme auf 9 beschrieben ist, und er kann in eine Verarbeitung von Ausnahmebedingungen aufgenommen werden, wie in einem Beispiel unter Bezugnahme auf die 10 bis 11 beschrieben ist. Er kann auch in ein anderes zugehöriges Register und/oder eine Verarbeitung einer registerindirekten Verzweigungsvorhersage, die hierin beschrieben ist, aufgenommen werden.

Ein Beispiel einer Vorhersagetechnik für eine registerindirekte Verzweigung, die auch ein zugehöriges abgeleitetes Register vorhersagt, wird unter Bezugnahme auf 23. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. Zunächst wird eine Verarbeitung in Verbindung mit einer registerindirekten Verzweigung und einer Vorhersage eines zugehörigen Werts durchgeführt, SCHRITT 2300. Dazu können mehrere Operationen gehören, darunter zum Beispiel: Vorhersagen der Zieladresse für eine registerindirekte Verzweigung; Umleiten des Instruktionsabrufs an die vorhergesagte Zieladresse; Zuordnen eines neuen Umbenennungsregisters für das logische Register, das die Zieladresse enthält; Kopieren der vorhergesagten Adresse in das zugeordnete Umbenennungsregister; Kennzeichnen des Umbenennungsregisters, das die Zieladresse enthält, als verfügbar; Zuordnen eines neuen Umbenennungsregisters für das zugehörige Register; Kopieren der vorhergesagten Adresse in das für das zugehörige Register zugeordnete Umbenennungsregister; Kennzeichnen des Umbenennungsregisters für das zugehörige Register als verfügbar; und Durchführen von einer oder mehreren Vorhersageprüfungen, wie in einem Beispiel unter Bezugnahme auf 5.

Zusätzlich zu der vorstehenden Verarbeitung, bei der eine oder mehrere der vorstehenden Operationen durchgeführt werden, wird festgestellt, ob der Prädiktor ein zugehöriges abgeleitetes Register vorhersagt, ABFRAGE 2302. In einem Beispiel beruht dies auf dem Erkennen einer Abfolge von Instruktionen, die die Verwendung einer GOT darstellt. In einem weiteren Beispiel können eine oder mehrere Steuerungen in einem Steuerregister verwendet werden, um vorherzusagen, ob der Wert eines abgeleiteten zugehörigen Registers vorhergesagt werden soll. Andere Beispiele sind ebenfalls möglich.

Wenn der Prädiktor kein zugehöriges abgeleitetes Register vorhersagt, ist diese Verarbeitung abgeschlossen. In einem Beispiel wird, wenn der Code zu einer Abfolge, die einen abgeleiteten Wert berechnet, verzweigt, während der Ausführung eine dynamische Idiom-Erkennung durchgeführt. Eine Abfolge, die einen abgeleiteten Wert berechnet, wird erkannt, z.B. dynamisch während der Ausführung des Codes, und ein Prädiktor wird aktualisiert, um dies anzuzeigen.

Andernfalls, wenn der Prädiktor tatsächlich einen zugehörigen abgeleiteten Wert vorhersagt, wird in einem Beispiel ein Offset für den abgeleiteten Wert erhalten, SCHRITT 2304. Dieser Offset kann unter Verwendung einer Vielzahl von Techniken erhalten werden, darunter die Verwendung einer Lookup-Tabelle, das Zugreifen auf den Instruktionsstrom oder die Verwendung eines Prädiktors, als Beispiele. Viele Techniken sind möglich. Des Weiteren wird ein Wert für das zugehörige abgeleitete Register berechnet, indem zum Beispiel der Offset zu einem im SCHRITT 2300 erhaltenen vorhergesagten Wert des zugehörigen Registers addiert wird, Schritt 2306.

Ein neues Umbenennungsregister wird für das zugehörige abgeleitete Register zugeordnet, SCHRITT 2308. Der berechnete Wert wird in das zugeordnete Umbenennungsregister für das zugehörige abgeleitete Register kopiert, SCHRITT 2310, und das Umbenennungsregister für das zugehörige abgeleitete Register wird als verfügbar gekennzeichnet, SCHRITT 2312.

Eine Prüfung der Vorhersage des zugehörigen abgeleiteten Registers kann durchgeführt werden, um festzustellen, ob die Vorhersage richtig ist, SCHRITT 2314. Weitere Einzelheiten in Verbindung mit einer Vorhersageprüfung, die das Prüfen der Vorhersage des zugehörigen abgeleiteten Registers umfasst, werden unter Bezugnahme auf 24. Diese kann zusätzlich zu der Verzweigungsvorhersageprüfung und/oder den Prüfungen der Vorhersage des zugehörigen Registers durchgeführt werden, als Beispiele. In einem Beispiel führt ein Prozessor diese Verarbeitung durch.

Unter Bezugnahme auf 24 wird in einem Beispiel eine Prüfung der Richtigkeit der zugehörigen abgeleiteten Vorhersage durchgeführt, SCHRITT 2400. Wenn die Vorhersage richtig ist, ABFRAGE 2401, ist die Prüfung abgeschlossen, SCHRITT 2402, und eine Wiederherstellung wird nicht durchgeführt. Wenn die Vorhersage jedoch falsch ist, ABFRAGE 2401, wird eine Wiederherstellung durchgeführt. Zum Beispiel werden die Instruktionen nach dem Funktionseinstieg gelöscht, SCHRITT 2404. Des Weiteren werden die während der Vorhersage zugeordneten Umbenennungsregister freigegeben, darunter auch das Umbenennungsregister für den zugehörigen abgeleiteten Wert, SCHRITT 2406. Ferner wird der Instruktionsabruf dann umgeleitet, um die Berechnungen des zugehörigen abgeleiteten Registers (z.B. R2) und nachfolgende Instruktionen erneut auszuführen, SCHRITT 2408. Dies schließt eine einzelne Ausführung der Vorhersageprüfung ab.

In anderen Ausführungen kann die Angabe des zugehörigen abgeleiteten Registers (z.B. der Registernummer) vorhergesagt werden. Somit wird eine Verarbeitung für das zugehörige Register durchgeführt, wie hierin beschrieben ist, um die Angabe vorherzusagen, die Vorhersage zu verwenden, die Richtigkeit zu prüfen, z.B., indem der vorhergesagte Wert des zugehörigen abgeleiteten Registers mit dem Wert verglichen wird, der von der Instruktionsabfolge berechnet wird, die den Wert nicht vorhersagbar in dem Instruktionsstrom berechnet, und/oder eine Wiederherstellung daraus durchzuführen. Viele Variationen sind möglich.

In einem weiteren Aspekt können das Vorhandensein eines zugehörigen abgeleiteten Registers und die bestimmte Registernummer des Registers als Reaktion auf das Erkennen von einer oder mehreren Abfolgen von Instruktionen festgestellt werden. Zum Beispiel erkennt die Decodierlogik die folgende Codeabfolge:

       mtctr             Rx
       bctrl
       addis Ry, Rx, #higha (_foo - .TOC.)
       addi Ry, Ry, #low (_foo - .TOC.)

In dem vorstehenden Code steht „addis“ für „add immediate shift“, z.B. gemäß der Definition der Power Architecture in einer beispielhaften Ausführungsform; „addi“ steht für „add immediate“, z.B. gemäß der Definition der Power Architecture in einer beispielhaften Ausführungsform; Rx ist das zugehörige Register (z.B. R12); und Ry ist das zugehörige abgeleitete Register (z.B. R2).

Beruhend auf dem Erkennen der vorstehenden Abfolge (oder einer ähnlichen Abfolge; verschiedene Abfolgen sind möglich und eine Hardware-Ausführung kann eine oder mehrere der möglichen Abfolgen gemäß einer Vielzahl von beispielhaften Ausführungsformen erkennen) wird eine Fusionsabfolge erzeugt, die die Verschiebeoperation, die Verzweigung und die Berechnung des abgeleiteten Werts durchführt. Als Beispiele kann eine vereinfachte Fusionsabfolge erzeugt werden, wobei z.B. das zugehörige Register (z.B. R12) und das zugehörige abgeleitete Register (z.B. R2) fest verdrahtet sind oder in einem Steuerregister angegeben werden; oder eine erweiterte Fusionsabfolge kann erzeugt werden, die eine Prüfung der vorhergesagten Verzweigungsadresse im Hinblick auf das ursprüngliche zugehörige Register umfasst, wobei die Kosten für die MTCTR insgesamt vermieden werden. In einer einzelnen Ausführungsform wird diese Verarbeitung von einem Decodierer durchgeführt und umfasst zum Beispiel:

predict target address
       PC <= predicted target address
       CTR <= predicted target address
       Rx <= predicted target address 
       Ry <= predicted target address + offset
       return address
       check predicted target address against Rx

In einem Beispiel werden die Nummer des zugehörigen Registers (z.B. R12) und/oder die Nummer des zugehörigen abgeleiteten Registers (z.B. R2) als das zugehörige Register bzw. das zugehörige abgeleitete Register fest verdrahtet. In einem weiteren Beispiel wird die Nummer des zugehörigen Registers und/oder die Nummer des zugehörigen abgeleiteten Registers in einer Steuerung, wie beispielsweise in einem ausgewählten Steuerregister, angegeben. In noch einem weiteren Beispiel werden sie beruhend auf der Abfolge der Instruktionen dynamisch festgestellt (z.B. die nach MTCTR angegebene Registernummer oder die in addis oder addi bereitgestellte Registernummer). Andere Beispiele sind ebenfalls möglich.

Weitere Einzelheiten in Bezug auf eine Vorhersagetechnik für eine registerindirekte Verzweigung mit einer fusionsbasierten zugehörigen abgeleiteten Abfolge werden unter Bezugnahme auf 25. In einem Beispiel führt ein Prozessor diese Verarbeitung durch. In einer einzelnen Ausführungsform wird ein Schritt, der eine Fusionsmöglichkeit erkennt, durchgeführt, SCHRITT 2500. Zum Beispiel wird eine Prüfung von dem Decodierer auf eine Abfolge von MTCTR Rx/BCTRL./ADDIS/ADDI durchgeführt. Beruhend auf der Durchführung des Erkennungsschritts wird festgestellt, ob eine solche Möglichkeit einer Fusionsabfolge erkannt wird, ABFRAGE 2502. Das heißt, ist eine Abfolge von MTCTR, BCTRL, ADDIS und ADDI in dem Codestrom vorhanden und stimmt Rx von MTCTR mit einer erwarteten Registernummer, wie beispielsweise einer fest verdrahteten Nummer eines zugehörigen Registers, oder einer in einer Steuerung bereitgestellten Nummer, als Beispiele, überein? Wenn keine Möglichkeit einer Fusionsabfolge erkannt wird, wird eine herkömmliche Verarbeitung durchgeführt, SCHRITT 2504. Andernfalls wird die Verarbeitung in einem Beispiel mit der Vorhersage der Zieladresse für eine registerindirekte Verzweigung, SCHRITT 2506, und der Umleitung des Instruktionsabrufs an die vorhergesagte Zieladresse, SCHRITT 2508, fortgesetzt. Des Weiteren wird, in einem Beispiel, ein neues Umbenennungsregister für das logische Register, das die Zieladresse enthält, zugeordnet, SCHRITT 2510. Die vorhergesagte Adresse wird in das zugeordnete Umbenennungsregister kopiert, SCHRITT 2512, und das Umbenennungsregister, das die Zieladresse enthält, wird als verfügbar gekennzeichnet, SCHRITT 2514.

Des Weiteren wird auch ein neues Umbenennungsregister für das zugehörige Register (z.B. Rx, wie beispielsweise R12) zugeordnet, SCHRITT 2516. Die vorhergesagte Adresse wird in das für das zugehörige Register zugeordnete Umbenennungsregister kopiert, SCHRITT 2518, und das Umbenennungsregister für das zugehörige Register wird als verfügbar gekennzeichnet, SCHRITT 2520.

Ferner wird auch ein neues Umbenennungsregister für das zugehörige abgeleitete Register (z.B. Ry, wie beispielsweise R2) zugeordnet, SCHRITT 2522. Ein Offset wird zu der vorhergesagten Adresse addiert und das Ergebnis wird in dem für das zugehörige abgeleitete Register zugeordnete Umbenennungsregister gespeichert, SCHRITT 2524. Das Umbenennungsregister für das zugehörige abgeleitete Register wird als verfügbar gekennzeichnet, SCHRITT 2526.

Eine Prüfung der Vorhersage der vorhergesagten Adresse wird durchgeführt, um festzustellen, ob die Vorhersage richtig ist, SCHRITT 2528. Dazu gehört zum Beispiel das Vergleichen der Zieladresse mit einem Wert des zugehörigen Registers (Rx) vor der Fusionsabfolge (z.B. unter Verwendung ihres vorherigen Umbenennungsregisters). Wenn die Vorhersage falsch ist, wird in einem Beispiel eine Wiederherstellung durchgeführt, wie hierin beschrieben ist. Dies schließt eine Ausführungsform dieser Verarbeitung ab.

In weiteren Ausführungsformen können auch andere Vorhersageprüfungen durchgeführt werden, wie hierin beschrieben ist.

Ein oder mehrere Aspekte der vorliegenden Erfindung sind untrennbar mit Computertechnologie verbunden und vereinfachen die Verarbeitung in einem Computer, was deren Performanz verbessert. Weitere Einzelheiten einer einzelnen Ausführungsform zur Vereinfachung der Verarbeitung in einer Datenverarbeitungsumgebung, wie sie sich auf einen oder mehrere Aspekte der vorliegenden Erfindung bezieht, werden unter Bezugnahme auf die 26A bis 26B beschrieben.

Unter Bezugnahme auf 26A wird in einer einzelnen Ausführungsform für eine Codeeinheit festgestellt, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt (2600). Die Feststellung nutzt einen codespezifischen Anzeiger, der für die Codeeinheit spezifisch ist (2602). Beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wird eine Angabe eines zugehörigen Registers in einen ausgewählten Speicherort geladen (2604). Beruhend auf dem Laden wird das zugehörige Register bei der spekulativen Verarbeitung genutzt (2606).

In einem weiteren Beispiel hat eine weitere Codeeinheit einen weiteren codespezifischen Anzeiger, der für die andere Codeeinheit spezifisch ist, welcher verwendet werden soll, um festzustellen, ob die andere Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt (2608).

Als Beispiel wird der ausgewählte Speicherort aus einer Gruppe ausgewählt, die aus einem Maschinenzustandsregister, einem Programmstatuswort, einem Spezialregister, einem Seitentabelleneintrag, einem Segmenttabelleneintrag und einem spezifischen Steuerregister besteht (2610).

In einer weiteren Ausführungsform wird festgestellt, dass ein Kontextwechsel stattgefunden hat (2612). Beruhend auf dem Kontextwechsel wird eine Konfiguration aktualisiert und die Konfiguration enthält den codespezifischen Anzeiger (2614).

In einer einzelnen Ausführungsform wird festgestellt, ob sich der codespezifische Anzeiger an einem Speicherort befindet, der speziell an die Codeeinheit gebunden ist (2616), und die Aktualisierung wird beruhend auf der Feststellung durchgeführt, dass sich der codespezifische Anzeiger an einem Speicherort befindet, der nicht speziell an die Codeeinheit gebunden ist (2618).

Als Beispiele, unter Bezugnahme auf 26B, enthält der speziell an die Codeeinheit gebundene Speicherort einen Seitentabelleneintrag oder einen Segmenttabelleneintrag (2620), und der nicht speziell an die Codeeinheit gebundene Speicherort enthält ein Steuerregister (2622).

In einer weiteren Ausführungsform wird festgestellt, dass eine Hardware-Ausnahmebedingung verwendet wurde (2624). Beruhend auf der Hardware-Ausnahmebedingung werden Konfigurationsinformationen in einem Ausnahmebedingungskontext gespeichert (2626). Als Beispiel enthalten die Konfigurationsinformationen den codespezifischen Anzeiger (2628).

Überdies wird die Verarbeitung der Hardware-Ausnahmebedingung in einer einzelnen Ausführungsform beendet (2630). Das Beenden umfasst zum Beispiel das Erhalten von Konfigurationsinformationen aus dem Ausnahmebedingungskontext (2632) und das Speichern der Konfigurationsinformationen in einem Steuerregister (2634).

Als Beispiel ist das zugehörige Register ein Register, das ausgewählt wird, um eine vorhergesagte Zieladresse beruhend auf einer Vorhersage einer Zieladresse zu speichern (2636).

Ein oder mehrere Aspekte der vorliegenden Erfindung werden vorteilhaft verwendet, um die Instruktionsabfolgen zu beschleunigen. Gemäß einer einzelnen Ausführungsform für die Power Architecture kann die nachstehend bereitgestellte Abfolge effizient ausgeführt werden, bei der das Zählerregister verwendet wird, um eine GOT-Basis zu initialisieren, wenn der Einstieg in die Funktion über eine zählerindirekte Verzweigung erfolgt.

Somit kann ein Aufrufer eine Unterroutine aufrufen, wie nachstehend angegeben ist, wenn er einen registerindirekten oder einen modulexternen Aufruf durchführt und wenn das Zähler-(CRT-)Register mit dem Zielregister der aufzurufenden Funktion initialisiert wurde:

       bctrl

Gemäß einer einzelnen Ausführungsform definiert eine ABI eine Funktion so, dass sie zwei Einstiegspunkte hat, einen für zählregister-(crt-)indirekte Aufrufe von modulexternen Aufrufern und registerindirekte Aufrufe, wenn ein GOT-Zeiger initialisiert werden soll, und von einem lokalen Aufrufer, wenn ein GOT-Zeiger nicht initialisiert werden soll:

callee_ctr_indirect_entry:
       mfctr r12          ! obtain CTR value
       addis r2, r12, (.TOC.-callee_ctr_indirec_entry)@ha
       addi r2.r2, (.TOC.-callee_ctr_indirect_entry)@1
 calle_direct_local_entry:
       ...         ! subroutine body
       blr        ! return to caller

Vorteilhafterweise kann die MFCTR-Instruktion, die den Wert des Zählregisters lädt, den vorhergesagten spekulativen Wert des CTR sofort bereitstellen, was es der nachfolgenden Abfolge von addis und addi ermöglicht, den GOT-Zeiger als ein Register für den Zugriff auf globale Variablen zu berechnen, und was eine Fortsetzung von Zugriffen auf globale Variablen ermöglicht, die andernfalls die Verarbeitung des Unterroutinen-Hauptteils verzögern würden.

In einer weiteren Ausführungsform, z.B. gemäß dem System/360-Instruktionssatz, können Unterroutinen-Aufrufe unter Verwendung eines registerindirekten Aufrufs durchgeführt werden, und nur ein einziger Einstiegspunkt kann vorhanden sein.

Andere Arten von Datenverarbeitungsumgebungen können auch einen oder mehrere Aspekte der vorliegenden Erfindung enthalten und verwenden, darunter, ohne darauf beschränkt zu sein, Emulationsumgebungen, von denen ein Beispiel unter Bezugnahme auf 27A beschrieben wird. In diesem Beispiel enthält eine Datenverarbeitungsumgebung 20 zum Beispiel eine native zentrale Verarbeitungseinheit (CPU, central processing unit) 22, einen Hauptspeicher 24 und eine oder mehrere Eingabe-/Ausgabeeinheiten und/oder Schnittstellen 26, die zum Beispiel über einen oder mehrere Busse 28 und/oder andere Verbindungen miteinander verbunden sind. Als Beispiele kann die Datenverarbeitungsumgebung 20 einen von der International Business Machines Corporation, Armonk, New York, angebotenen PowerPC-Prozessor oder einen Power-Server enthalten; und/oder andere Rechner, die auf von der International Business Machines Corporation, Intel oder anderen Unternehmen angebotenen Architekturen beruhen.

Die native zentrale Verarbeitungseinheit 22 enthält ein oder mehrere native Register 30 wie beispielsweise ein oder mehrere Mehrzweckregister und/oder ein oder mehrere Spezialregister, die während der Verarbeitung innerhalb der Umgebung verwendet werden. Diese Register enthalten Informationen, die den Zustand der Umgebung zu irgendeinem bestimmten Zeitpunkt darstellen.

Überdies führt die native zentrale Verarbeitungseinheit 22 Anweisungen und Code aus, die im Hauptspeicher 24 gespeichert sind. In einem bestimmten Beispiel führt die zentrale Verarbeitungseinheit im Hauptspeicher 24 gespeicherten Emulator-Code 32 aus. Dieser Code ermöglicht es der in einer Architektur konfigurierten Datenverarbeitungsumgebung, eine andere Architektur zu emulieren. Zum Beispiel ermöglicht der Emulator-Code 32 Rechnern, die auf anderen Architekturen als der z/Architecture beruhen, wie beispielsweise PowerPC-Prozessoren, pSeries-Servern oder anderen Servern oder Prozessoren, die z/Architecture zu emulieren und Software und Instruktionen auszuführen, die beruhend auf der z/Architecture entwickelt wurden.

Weitere Einzelheiten in Bezug auf den Emulator-Code 32 werden unter Bezugnahme auf 27B beschrieben. Im Hauptspeicher 24 gespeicherte Gast-Instruktionen 40 weisen Software-Instruktionen (die z.B. mit Maschineninstruktionen korrelieren) auf, die für eine Ausführung in einer anderen Architektur als die der nativen CPU 22 entwickelt wurden. Beispielsweise wurden Gast-Instruktionen 40 möglicherweise für eine Ausführung auf einem Prozessor der z/Architecture konzipiert, werden stattdessen aber auf der nativen CPU 22 emuliert, bei der es sich zum Beispiel um einen Intel-Prozessor handeln kann. In einem Beispiel enthält der Emulator-Code 32 eine Instruktionsabrufroutine 42, um eine oder mehrere Gast-Instruktionen 40 aus dem Hauptspeicher 24 zu erhalten und um optional eine lokale Pufferung für die erhaltenen Instruktionen bereitzustellen. Er enthält auch eine Instruktionsumsetzungsroutine 44, um die Art der Gast-Instruktion festzustellen, die erhalten wurde, und um die Gast-Instruktion in eine oder mehrere entsprechende native Instruktionen 46 umzusetzen. Diese Umsetzung umfasst zum Beispiel das Ermitteln der Funktion, die durch die Gast-Instruktion ausgeführt werden soll, und das Wählen der nativen Instruktion(en) zum Ausführen dieser Funktion.

Außerdem enthält der Emulator-Code 32 eine Emulationssteuerungsroutine 48, um zu veranlassen, dass die nativen Anweisungen ausgeführt werden. Die Emulationssteuerungsroutine 48 kann die native CPU 22 veranlassen, eine Routine nativer Instruktionen, die eine oder mehrere zuvor erhaltene Gast-Instruktionen emulieren, auszuführen und am Ende dieser Ausführung die Steuerung an die Instruktionsabrufroutine zurückzugeben, um das Erhalten der nächsten Gast-Instruktion oder einer Gruppe von Gast-Instruktionen zu emulieren. Die Ausführung der nativen Instruktionen 46 kann das Laden von Daten aus dem Hauptspeicher 24 in ein Register; das Zurückspeichern von Daten aus einem Register in den Hauptspeicher; oder das Durchführen einer bestimmten Art einer arithmetischen oder logischen Operation, die von der Umsetzungsroutine bestimmt wird, umfassen.

Jede Routine ist zum Beispiel in Software ausgeführt, die im Hauptspeicher gespeichert und von der nativen zentralen Verarbeitungseinheit 22 ausgeführt wird. In weiteren Beispielen werden eine oder mehrere der Routinen oder Operationen in Firmware, Hardware, Software oder einer Kombination daraus ausgeführt. Die Register des emulierten Prozessors können unter Verwendung der Register 30 der nativen CPU oder durch Verwendung von Speicherplätzen im Hauptspeicher 24 emuliert werden. In Ausführungsformen können sich die Gast-Instruktionen 40, die nativen Instruktionen 46 und der Emulator-Code 32 in demselben Hauptspeicher befinden oder zwischen verschiedenen Speichereinheiten verteilt sein.

In der Verwendung hierin umfasst Firmware z.B. den Mikrocode oder den Millicode des Prozessors. Sie umfasst zum Beispiel die Instruktionen auf Hardware-Ebene und/oder Datenstrukturen, die bei der Ausführung von Maschinencode einer höheren Ebene verwendet werden. In einer Ausführungsform umfasst sie zum Beispiel proprietären Code, der üblicherweise als Mikrocode geliefert wird, welcher vertrauenswürdige Software oder Mikrocode enthält, die bzw. der spezifisch für die zugrunde liegende Hardware ist, und den Betriebssystemzugriff auf die System-Hardware steuert.

Eine Gast-Instruktion 40, die erhalten, umgesetzt und ausgeführt wird, kann zum Beispiel eine der hierin beschriebenen Instruktionen sein. Die Instruktion, die eine Instruktion von einer Architektur (z.B. der z/Architecture) ist, wird aus dem Hauptspeicher abgerufen, umgesetzt und als eine Abfolge von nativen Instruktionen 46 einer anderen Architektur (z.B. PowerPC, pSeries, Intel usw.) dargestellt. Diese nativen Instruktionen werden dann ausgeführt.

Ein oder mehrere Aspekte können sich auf das Cloud-Computing beziehen.

Es sei von vornherein klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing enthält. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen weiteren Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.

Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften enthalten, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle.

Bei den Eigenschaften handelt es sich um die folgenden:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Der Ressourcen-Verbrauch kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.

Die Dienst-Modelle sind wie folgt:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).

Bei den Einsatzmodellen handelt es sich um die folgenden:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann in den eigenen Räumen oder fremden Räumen stehen.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).

Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten aufweist.

Unter Bezugnahme auf 28 ist eine veranschaulichende Cloud-Computing-Umgebung 50 abgebildet. Wie gezeigt ist, weist die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der elektronische Assistent (PDA, personal digital assistant) oder das Mobiltelefon 54A, der Desktop-Computer 54B, der Laptop-Computer 54C und/oder das Automobil-Computer-System 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder in mehreren Netzwerken wie zum Beispiel privaten, Gemeinschafts-, öffentlichen oder hybriden Clouds, die hier vorstehend beschrieben wurden, oder in einer Kombination daraus zu Gruppen zusammengefasst (nicht gezeigt) werden. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienst anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten von in 28 gezeigten Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.

Unter Bezugnahme auf 29 wird ein Satz von funktionalen Abstraktionsschichten gezeigt, die durch die Cloud-Computing-Umgebung 50 (28) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 29 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:

Eine Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören Mainframe-Computer 61; auf der RISC-(Reduced-Instruction-Set-Computer-)Architektur beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. In einigen Ausführungsformen umfassen Software-Komponenten eine Netzwerk-Anwendungsserver-Software 67 und Datenbank-Software 68.

Die Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71; virtueller Speicher 72; virtuelle Netzwerke 73, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.

In einem Beispiel kann die Verwaltungsschicht 80 die nachstehend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 81 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 82 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware aufweisen. Die Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 84 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 85 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.

Eine Arbeitslastschicht 90 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und Registerverarbeitung 96.

Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen Integrationsstufe technischer Details handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) umfassen, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.

Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.

Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.

Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für eine integrierte Schaltung oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.

Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.

Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.

Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.

Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.

Zusätzlich zu dem Vorstehenden können ein oder mehrere Aspekte von einem Serviceanbieter, der die Verwaltung von Kundenumgebungen anbietet, bereitgestellt, angeboten, eingesetzt, verwaltet, gewartet usw. werden. Zum Beispiel kann der Serviceanbieter Computer-Code und/oder eine Computerinfrastruktur, die einen oder mehrere Aspekte für einen oder mehrere Kunden ausführt, erzeugen, pflegen, unterstützen usw. Der Serviceanbieter wiederum kann die Zahlungen von dem Kunden im Rahmen eines Abonnement- und/oder Gebührenvertrags - als Beispiele - erhalten. Darüber hinaus oder alternativ kann der Serviceanbieter die Zahlungen aus dem Verkauf von Werbeinhalten an einen oder mehrere Dritte erhalten.

In einem Aspekt kann eine Anwendung zur Durchführung von einer oder mehreren Ausführungsformen eingesetzt werden. Als ein Beispiel weist das Einsetzen einer Anwendung das Bereitstellen von Computerinfrastruktur auf, die so beschaffen ist, dass sie eine oder mehrere Ausführungsformen ausführen kann.

Als ein weiterer Aspekt kann eine Datenverarbeitungsinfrastruktur eingesetzt werden, die das Integrieren von computerlesbarem Code in ein Datenverarbeitungssystem aufweist, in dem der Code in Verbindung mit dem Datenverarbeitungssystem in der Lage ist, eine oder mehrere Ausführungsformen auszuführen.

Als noch ein weiterer Aspekt kann ein Prozess zum Integrieren einer Datenverarbeitungsinfrastruktur bereitgestellt werden, die das Integrieren von computerlesbarem Code in ein Computersystem aufweist. Das Computersystem weist einen durch einen Computer lesbaren Datenträger auf, in dem der Computer-Datenträger eine oder mehrere Ausführungsformen aufweist. Der Code in Verbindung mit dem Computersystem ist in der Lage, eine oder mehrere Ausführungsformen auszuführen.

Zwar wurden vorstehend verschiedene Ausführungsformen beschrieben, doch handelt es sich dabei lediglich um Beispiele. Zum Beispiel können Datenverarbeitungsumgebungen anderer Architekturen verwendet werden, um eine oder mehrere Ausführungsformen einzubinden und zu verwenden. Des Weiteren können verschiedene Instruktionen oder Operationen verwendet werden. Ferner können verschiedene Register verwendet und/oder andere Arten von Angaben (außer Registernummern) gemacht werden. Viele Variationen sind möglich.

Des Weiteren können andere Arten von Datenverarbeitungsumgebungen profitieren und verwendet werden. Als ein Beispiel kann ein zur Speicherung und/oder Ausführung von Programmcode geeignetes Datenverarbeitungssystem verwendet werden, das mindestens zwei Prozessoren enthält, die über einen Systembus direkt oder indirekt mit Speicherelementen verbunden sind. Zu den Speicherelementen gehört zum Beispiel ein lokaler Speicher, der während der tatsächlichen Ausführung des Programmcodes genutzt wird, ein Massenspeicher und ein Cachespeicher, die eine vorübergehende Speicherung von mindestens einem Teil des Programmcodes ermöglichen, um die Häufigkeit zu verringern, mit der Code während der Ausführung aus dem Massenspeicher abgerufen werden muss.

Eingabe-/Ausgabe- bzw. E/A-Einheiten (darunter, ohne darauf beschränkt zu sein, Tastaturen, Bildschirme, Zeigereinheiten, DASD, Band, CDs, DVDs, Thumb-Drives und andere Speichermedien usw.) können entweder direkt oder über dazwischenliegende E/A-Controller mit dem System verbunden sein. Netzadapter können ebenfalls mit dem System verbunden sein, um zu ermöglichen, dass das Datenverarbeitungssystem mit anderen Datenverarbeitungssystemen oder fernen Druckern oder Speichereinheiten über dazwischenliegende private oder öffentliche Netzwerke verbunden werden kann. Modems, Kabelmodems und Ethernet-Karten sind nur einige der verfügbaren Arten von Netzadaptern.

Die hierin verwendete Terminologie dient lediglich zur Beschreibung von bestimmten Ausführungsformen und soll nicht einschränkend sein. Die Singular-Formen „ein“, „eine“ und „der“, „die“, „das“ sollen in der Verwendung hierin auch die Pluralformen einschließen, sofern der Kontext nicht eindeutig etwas anderes angibt. Es wird des Weiteren darauf hingewiesen, dass die Begriffe „aufweist“ und/oder „aufweisend“, wenn sie in dieser Spezifikation verwendet werden, das Vorhandensein von angegebenen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten bezeichnen, das Vorhandensein oder das Hinzufügen von einem oder mehreren anderen/weiteren Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon jedoch nicht ausschließen.

Die entsprechenden Strukturen, Materialien, Vorgänge und Äquivalente von allen Mitteln beziehungsweise Schritt-plus-Funktion-Elementen (step plus function elements) in den nachstehenden Ansprüchen, sofern vorhanden, sollen jedwede Struktur, jedwedes Material oder jedweden Vorgang zur Ausführung der Funktion in Kombination mit anderen beanspruchten Elementen, die im Einzelnen beansprucht werden, mit einschließen. Die Beschreibung von einer oder mehreren Ausführungsformen erfolgte zum Zweck der Veranschaulichung und Erläuterung, sie soll aber weder erschöpfend noch auf die offenbarte Form beschränkt sein. Für den Fachmann sind viele Änderungen und Varianten erkennbar. Die Ausführungsform wurde gewählt und beschrieben, um die verschiedenen Aspekte und die praktische Anwendung bestmöglich zu erklären und um anderen Fachleuten das Verständnis verschiedener Ausführungsformen mit verschiedenen Änderungen, wie sie für die jeweilige vorgesehene Verwendung geeignet sind, zu ermöglichen.

Claims

Computerprogrammprodukt, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, wobei das Computerprogrammprodukt aufweist: ein durch einen Computer lesbares Speichermedium, das durch eine Verarbeitungsschaltung lesbar ist und Instruktionen zur Durchführung eines Verfahrens speichert, das aufweist: Feststellen für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wobei die Feststellung einen codespezifischen Anzeiger nutzt, der für die Codeeinheit spezifisch ist; beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, Laden einer Angabe eines zugehörigen Registers in einen ausgewählten Speicherort; und beruhend auf dem Laden, Nutzen des zugehörigen Registers bei der spekulativen Verarbeitung.
Computerprogrammprodukt nach Anspruch 1, wobei eine weitere Codeeinheit einen weiteren codespezifischen Anzeiger hat, der für die andere Codeeinheit spezifisch ist, welcher verwendet werden soll, um festzustellen, ob die andere Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt.
Computerprogrammprodukt nach Anspruch 1, wobei der ausgewählte Speicherort aus einer Gruppe ausgewählt wird, die aus einem Maschinenzustandsregister, einem Programmstatuswort, einem Spezialregister, einem Seitentabelleneintrag, einem Segmenttabelleneintrag und einem spezifischen Steuerregister besteht.
Computerprogrammprodukt nach Anspruch 1, wobei das Verfahren des Weiteren aufweist: Feststellen, dass ein Kontextwechsel stattgefunden hat; und Aktualisieren einer Konfiguration beruhend auf dem Kontextwechsel, wobei die Konfiguration den codespezifischen Anzeiger aufweist.
Computerprogrammprodukt nach Anspruch 4, wobei das Verfahren des Weiteren aufweist: Feststellen, ob sich der codespezifische Anzeiger an einem Speicherort befindet, der speziell an die Codeeinheit gebunden ist; und Durchführen der Aktualisierung beruhend auf der Feststellung, dass sich der codespezifische Anzeiger an einem Speicherort befindet, der nicht speziell an die Codeeinheit gebunden ist.
Computerprogrammprodukt nach Anspruch 5, wobei der speziell an die Codeeinheit gebundene Speicherort einen Seitentabelleneintrag oder einen Segmenttabelleneintrag aufweist.
Computerprogrammprodukt nach Anspruch 5, wobei der nicht speziell an die Codeeinheit gebundene Speicherort ein Steuerregister aufweist.
Computerprogrammprodukt nach Anspruch 1, wobei das Verfahren des Weiteren aufweist: Feststellen, dass eine Hardware-Ausnahmebedingung verwendet wurde, und Speichern von Konfigurationsinformationen in einem Ausnahmebedingungskontext beruhend auf der Hardware-Ausnahmebedingung, wobei die Konfigurationsinformationen den codespezifischen Anzeiger aufweisen.
Computerprogrammprodukt nach Anspruch 8, wobei das Verfahren des Weiteren das Beenden der Verarbeitung von Hardware-Ausnahmebedingungen aufweist, wobei das Beenden umfasst: Erhalten der Konfigurationsinformationen aus dem Ausnahmebedingungskontext; und Speichern der Konfigurationsinformationen in einem Steuerregister.
Computerprogrammprodukt nach Anspruch 1, wobei das zugehörige Register ein Register ist, das ausgewählt wird, um eine vorhergesagte Zieladresse beruhend auf einer Vorhersage einer Zieladresse zu speichern.
Computersystem, um die Verarbeitung in einer Datenverarbeitungsumgebung zu vereinfachen, wobei das Computersystem aufweist: einen Hauptspeicher; und einen Prozessor, der mit dem Hauptspeicher Daten austauscht, wobei das Computersystem so konfiguriert ist, dass es ein Verfahren durchführt, wobei das Verfahren aufweist: Feststellen für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wobei die Feststellung einen codespezifischen Anzeiger nutzt, der für die Codeeinheit spezifisch ist; beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, Laden einer Angabe eines zugehörigen Registers in einen ausgewählten Speicherort; und beruhend auf dem Laden, Nutzen des zugehörigen Registers bei der spekulativen Verarbeitung.
Computersystem nach Anspruch 11, wobei eine weitere Codeeinheit einen weiteren codespezifischen Anzeiger hat, der für die andere Codeeinheit spezifisch ist, welcher verwendet werden soll, um festzustellen, ob die andere Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt.
Computersystem nach Anspruch 11, wobei das Verfahren des Weiteren aufweist: Feststellen, dass ein Kontextwechsel stattgefunden hat; und Aktualisieren einer Konfiguration beruhend auf dem Kontextwechsel, wobei die Konfiguration den codespezifischen Anzeiger aufweist.
Computersystem nach Anspruch 13, wobei das Verfahren des Weiteren aufweist: Feststellen, ob sich der codespezifische Anzeiger an einem Speicherort befindet, der speziell an die Codeeinheit gebunden ist; und Durchführen der Aktualisierung beruhend auf der Feststellung, dass sich der codespezifische Anzeiger an einem Speicherort befindet, der nicht speziell an die Codeeinheit gebunden ist.
Computersystem nach Anspruch 11, wobei das Verfahren des Weiteren aufweist: Feststellen, dass eine Hardware-Ausnahmebedingung verwendet wurde; und Speichern von Konfigurationsinformationen in einem Ausnahmebedingungskontext beruhend auf der Hardware-Ausnahmebedingung, wobei die Konfigurationsinformationen den codespezifischen Anzeiger aufweisen.
Durch einen Computer ausgeführtes Verfahren zur Vereinfachung der Verarbeitung in einer Datenverarbeitungsumgebung, wobei das durch einen Computer ausgeführte Verfahren aufweist: Feststellen, durch einen Prozessor, für eine Codeeinheit, ob die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, wobei die Feststellung einen codespezifischen Anzeiger nutzt, der für die Codeeinheit spezifisch ist; beruhend auf der Feststellung, dass die Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt, Laden einer Angabe eines zugehörigen Registers in einen ausgewählten Speicherort; und beruhend auf dem Laden, Nutzen des zugehörigen Registers bei der spekulativen Verarbeitung.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 16, wobei eine weitere Codeeinheit einen weiteren codespezifischen Anzeiger hat, der für die andere Codeeinheit spezifisch ist, welcher verwendet werden soll, um festzustellen, ob die andere Codeeinheit für eine Vorhersage eines zugehörigen Registers in Frage kommt.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 16, wobei der ausgewählte Speicherort aus einer Gruppe ausgewählt wird, die aus einem Maschinenzustandsregister, einem Programmstatuswort, einem Spezialregister, einem Seitentabelleneintrag, einem Segmenttabelleneintrag und einem spezifischen Steuerregister besteht.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 16, das des Weiteren aufweist: Feststellen, dass ein Kontextwechsel stattgefunden hat; und Aktualisieren einer Konfiguration beruhend auf dem Kontextwechsel, wobei die Konfiguration den codespezifischen Anzeiger aufweist.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 19, das des Weiteren aufweist: Feststellen, ob sich der codespezifische Anzeiger an einem Speicherort befindet, der speziell an die Codeeinheit gebunden ist; und Durchführen der Aktualisierung beruhend auf der Feststellung, dass sich der codespezifische Anzeiger an einem Speicherort befindet, der nicht speziell an die Codeeinheit gebunden ist.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 20, wobei der speziell an die Codeeinheit gebundene Speicherort einen Seitentabelleneintrag oder einen Segmenttabelleneintrag aufweist.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 20, wobei der nicht speziell an die Codeeinheit gebundene Speicherort ein Steuerregister aufweist.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 16, das des Weiteren aufweist: Feststellen, dass eine Hardware-Ausnahmebedingung verwendet wurde, und Speichern von Konfigurationsinformationen in einem Ausnahmebedingungskontext beruhend auf der Hardware-Ausnahmebedingung, wobei die Konfigurationsinformationen den codespezifischen Anzeiger aufweisen.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 23, wobei das Verfahren des Weiteren das Beenden der Verarbeitung von Hardware-Ausnahmebedingungen aufweist, wobei das Beenden umfasst: Erhalten der Konfigurationsinformationen aus dem Ausnahmebedingungskontext; und Speichern der Konfigurationsinformationen in einem Steuerregister.
Durch einen Computer ausgeführtes Verfahren nach Anspruch 16, wobei das zugehörige Register ein Register ist, das ausgewählt wird, um eine vorhergesagte Zieladresse beruhend auf einer Vorhersage einer Zieladresse zu speichern.