DE102020134681A1

DE102020134681A1 - Vorrichtungen, verfahren und systeme für anweisungen zum anfordern eines verlaufs-resets eines prozessorkerns

Info

Publication number: DE102020134681A1
Application number: DE102020134681.6A
Authority: DE
Inventors: Eliezer Weissmann; Robert Valentine; Gilbert Neiger; Mark Charney; Efraim Rotem; Jason Brandt; Michael Mishaeli; Baruch Chaikin; Itai Ravid
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-01-31
Filing date: 2020-12-22
Publication date: 2021-08-05
Also published as: US11966742B2; US20230076318A1; US20230273795A1; CN113204448A; US11645080B2

Abstract

Es werden Systeme, Verfahren und Vorrichtungen in Bezug auf Anweisungen zum Zurücksetzen von Software-Thread-Laufzeiteigenschaft-Verläufen in einem Hardwareprozessor beschrieben. In einer Ausführungsform weist ein Hardwareprozessor einen Hardware-Guide-Scheduler, der mehrere Software-Thread-Laufzeiteigenschaft-Verläufe aufweist; einen Decoder zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung ein Feld aufweist, das ein modellspezifisches Register identifiziert; und eine Ausführungsschaltung zum Ausführen der decodierten Einzelanweisung zum Prüfen, dass ein Freigabe-Bit des modellspezifischen Registers gesetzt ist, und, wenn das Freigabe-Bit gesetzt ist, zum Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers auf.

Description

QUERVERWEIS ZU VERWANDTEN ANMELDUNGEN
Die vorliegende Patentanmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldung Nr. 62/968,861 , eingereicht am 31. Januar 2020, mit dem Titel: „Apparatuses, Methods, and Systems for Instructions to Request a History Reset of a Processor Core“, die durch Bezugnahme in die vorliegende Anmeldung aufgenommen wird.
TECHNISCHES GEBIET
Die Offenbarung betrifft im Allgemeinen die Elektronik, und insbesondere betrifft eine Ausführungsform der Offenbarung Schaltungen zum Implementieren einer Anweisung zum Anfordern eines Verlaufs-Resets eines Prozessorkerns.
ALLGEMEINER STAND DER TECHNIK
Ein Prozessor, oder ein Satz von Prozessoren, führt Anweisungen aus einem Anweisungssatz, z.B. der Anweisungssatzarchitektur (ISA - Instruction Set Architecture), aus. Der Anweisungssatz ist der Teil der Computerarchitektur im Zusammenhang mit der Programmierung und weist im Allgemeinen die systemeigenen Datentypen, Anweisungen, die Registerarchitektur, Adressierungsmodi, die Arbeitsspeicherarchitektur, die Unterbrechungs- und Ausnahmebehandlung und externe Eingabe und Ausgabe (E/A) auf. Es sei darauf hingewiesen, dass sich der Begriff Anweisung hierin auf eine Makro-Anweisung, z.B. eine Anweisung, die dem Prozessor zur Ausführung bereitgestellt wird, oder auf eine Mikro-Anweisung, z.B. eine Anweisung, die daraus resultiert, dass der Decoder eines Prozessors Makro-Anweisungen decodiert, beziehen kann.
Figurenliste
Verschiedene Ausführungsformen in Übereinstimmung mit der vorliegenden Offenbarung werden unter Bezugnahme auf die Zeichnungen beschrieben, wobei:

1 ein Computersystem, das einen Prozessorkern aufweist, gemäß Ausführungsformen der Offenbarung veranschaulicht.
2 einen Hardware-Guide-Scheduler gemäß Ausführungsformen der Offenbarung veranschaulicht.
3 ein Beispielformat eines modellspezifischen Registers für einen Prozessor-internen Verlaufs-Reset gemäß Ausführungsformen der Offenbarung veranschaulicht.
4 ein Betriebssystem (BS) -Scheduler-Steuerflussdiagramm gemäß Ausführungsformen der Offenbarung veranschaulicht.
5 ein Anwendungsebenen-Steuerflussdiagramm gemäß Ausführungsformen der Offenbarung veranschaulicht.
6 ein Betriebssystem (BS) -Reset-Flussdiagramm gemäß Ausführungsformen der Offenbarung veranschaulicht.
7 ein Betriebssystem (BS) -Scheduler-Flussdiagramm gemäß Ausführungsformen der Offenbarung veranschaulicht.
8A - 8D Flussdiagramme für BS- und VMM- (Virtual Machine Monitor) Unterstützungsmodelle gemäß Ausführungsformen der Offenbarung veranschaulichen.
9 ein Flussdiagramm gemäß Ausführungsformen der Offenbarung veranschaulicht.
10A ein Blockdiagramm ist, welches ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen der Klasse A davon gemäß Ausführungsformen der Offenbarung veranschaulicht.
10B ein Blockdiagramm ist, welches das generische vektorfreundliche Anweisungsformat und Anweisungsvorlagen der Klasse B davon gemäß Ausführungsformen der Offenbarung veranschaulicht.
11A ein Blockdiagramm ist, welches Felder für die generischen vektorfreundlichen Anweisungsformate in 10A und 10B gemäß Ausführungsformen der Offenbarung veranschaulicht.
11B ein Blockdiagramm ist, welches die Felder des spezifischen vektorfreundlichen Anweisungsformates in 11A, die ein Feld Vollständiger Opcode' bilden, gemäß einer Ausführungsform der Offenbarung veranschaulicht.
11C ein Blockdiagramm ist, welches die Felder des spezifischen vektorfreundlichen Anweisungsformates in 11A, die ein Feld „Registerindex‟ bilden, gemäß einer Ausführungsform der Offenbarung veranschaulicht.
11D ein Blockdiagramm ist, welches die Felder des spezifischen vektorfreundlichen Anweisungsformates in 11A, die das Feld „Zusatzoperation‟ 1050 bilden, gemäß einer Ausführungsform der Offenbarung veranschaulicht.
12 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Offenbarung ist.
13A ein Blockdiagramm ist, welches sowohl eine beispielhafte sequentielle Pipeline als auch eine beispielhafte nicht-sequentielle Ausgabe/Ausführungs-Pipeline mit Registerumbenennung gemäß Ausführungsformen der Offenbarung veranschaulicht.
13B ein Blockdiagramm ist, welches sowohl eine beispielhafte Ausführungsform eines sequentiellen Architekturkerns als auch einen beispielhaften nicht-sequentiellen Ausgabe/Ausführungs-Architekturkern mit Registerumbenennung, die in einem Prozessor enthalten sein sollen, gemäß Ausführungsformen der Offenbarung veranschaulicht.
14A ein Blockdiagramm eines einzelnen Prozessorkerns zusammen mit seiner Verbindung zum On-Die-Zwischenverbindungsnetzwerk und mit seiner lokalen Teilmenge des L2 (Level 2) -Caches gemäß Ausführungsformen der Offenbarung ist.
14B eine erweiterte Ansicht eines Teils des Prozessorkerns in 14A gemäß Ausführungsformen der Offenbarung ist.
15 ein Blockdiagramm eines Prozessors, der mehr als einen Kern aufweisen kann, einen integrierten Arbeitsspeicher-Controller aufweisen kann und integrierte Grafik aufweisen kann, gemäß Ausführungsformen der Offenbarung ist.
16 ein Blockdiagramm eines Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung ist.
17 ein Blockdiagramm eines spezifischeren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung ist.
18 ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt.
19 ein Blockdiagramm eines Ein-Chip-Systems (SoC - System on a Chip) in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt.
20 ein Blockdiagramm ist, welches die Verwendung eines Softwareanweisungswandlers zum Umwandeln von Binäranweisungen in einem Quellanweisungssatz in Binäranweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Offenbarung gegenüberstellt.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung sind zahlreiche spezifische Details dargelegt. Jedoch wird verstanden werden, dass Ausführungsformen der Offenbarung auch ohne diese spezifischen Details in der Praxis umgesetzt werden können. In anderen Fällen wurden gut bekannte Schaltungen, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis dieser Beschreibung nicht zu verdecken.
Verweise in der Spezifikation auf „eine Ausführungsform“, „eine Beispielausführungsform“ usw. geben an, dass die beschriebene Ausführungsform ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft aufweisen kann, jedoch weist nicht notwendigerweise jede Ausführungsform das/die bestimmte Merkmal, Struktur oder Eigenschaft auf. Darüber hinaus beziehen sich derartige Phrasen nicht notwendigerweise auf die gleiche Ausführungsform. Außerdem wird, wenn ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben ist, davon ausgegangen, dass es innerhalb der Kenntnis eines Fachmanns auf dem Gebiet liegt, ein/e derartige/s Merkmal, Struktur oder Eigenschaft auch in Verbindung mit anderen Ausführungsformen umzusetzen, egal ob explizit beschrieben oder nicht.
Ein Prozessor (z.B. ein Hardwareprozessor) (der z.B. einen oder mehrere Kerne aufweist) kann Anweisungen (z.B. einen Thread von Anweisungen) ausführen, um an Daten zu arbeiten, um zum Beispiel arithmetische, logische oder andere Funktionen durchzuführen. Zum Beispiel kann Software eine Operation anfordern, und ein Hardwareprozessor (z.B. ein Kern oder Kerne davon) kann die Operation als Reaktion auf die Anforderung durchführen. Software kann die Ausführung eines Threads (z.B. eines Software-Threads) anfordern. Ein Betriebssystem (BS) kann einen Scheduler zur zeitlichen Planung der Ausführung von Threads (z.B. Software-Threads) auf einem Hardwareprozessor, z.B. auf einem logischen Prozessor (z.B. einem logischen Kern) des Hardwareprozessors, aufweisen. Jeder logische Prozessor kann als eine entsprechende zentrale Verarbeitungseinheit (CPU - Central Processing Unit) bezeichnet werden.
Jeder Thread kann einen Kontext aufweisen. In bestimmten Ausführungsformen werden Kontexte durch eine oder mehrere der folgenden Eigenschaften identifiziert: 1) einen Hardware-Thread-Identifikator, wie z.B. ein Wert, der einen von mehreren logischen Prozessoren (z.B. logischen Kernen) identifiziert, die durch Techniken wie z.B. simultanes Multithreading (SMT) auf dem gleichen physischen Kern implementiert werden; 2) eine Berechtigungsstufe, wie sie z.B. durch Ringe implementiert wird; 3) eine Seitentabellen-Basisadress- oder Codesegment-Konfiguration, wie sie z.B. in einem Steuerregister (z.B. CR3) oder Codesegment (CS) -Register implementiert wird; 4) Adressraum-Identifikatoren (ASIDs - Address Space Identifiers), wie sie z.B. durch eine Prozesskontext-ID (PCID - Process Context ID) oder eine Virtueller-Prozess-ID (VPID - Virtual Process ID) implementiert werden, welche die Virtuell-zu-Physisch-Abbildungen, die durch die CPU verwendet werden, semantisch unterscheiden; 5) Schlüsselregister, die kryptografisch versiegelte Assets (z.B. Tokens) enthalten, die zur Bestimmung einer Berechtigung der ausführenden Software verwendet werden; und/oder 6) Ephemera - eine Kontextveränderung, wie z.B. ein zufälliger Reset von Kontext.
Über jeglichen nicht unbedeutenden Zeitraum können viele Threads (z.B. Kontexte davon) innerhalb eines physischen Kerns aktiv sein. In bestimmten Ausführungsformen teilt Systemsoftware Zeitscheiben zwischen Anwendungen und Systemsoftware-Funktionen auf, wodurch es potentiell vielen Kontexten gestattet wird, auf Mikroarchitektur-Vorhersage- und/oder -Caching-Mechanismen zuzugreifen.
Bestimmte Ausführungsformen hierin sind auf eine neue Anweisung gerichtet, um eine Anfrage für einen Verlaufs-Reset (z.B. als Teil einer Kontextumschaltung) für einen physischen Kern anzuzeigen (z.B. für (eine) spezifische Verlaufsart(en) einer CPU/eines logischen Prozessors, die/der durch den physischen Kern implementiert wird). In bestimmten Ausführungsformen gestattet eine Anweisung (z.B. das Decodieren und Ausführen dieser Anweisung) einem Betriebssystem (BS) das Freigeben eines Hinweises an den Hardwareprozessor, um anzuzeigen, dass die Hardware ihren internen Verlauf zurücksetzen sollte, zum Beispiel wenn eine Software-Thread-Kontextumschaltung stattgefunden hat oder als Teillaufzeit eines Software-Threads. Das Auftreten der Software-Thread-Kontextumschaltung kann somit eine oder mehrere Maßnahmen durch die Hardware (z.B. basierend auf ihrer Architektur) auslösen und Verfahren unterstützen, die bestimmten B S-Konfigurationen folgen.
Bestimmte Ausführungsformen hierin sind auf eine neue Anweisung gerichtet, um (z.B. während einer Kontextumschaltung von zwei Threads auf einem physischen Kern) (z.B. einer Kontextumschaltung für eine CPU, die durch den physischen Kern implementiert wird) einen Reset des internen Verlaufs eines (z.B. logischen) Prozessors zu veranlassen (z.B. wie unter Bezugnahme auf 2 unten diskutiert) und/oder um (z.B. durch das Zurücksetzen) einen unterschiedlichen Prozessorvorhersageverlauf aufgrund der Kontextumschaltung zu initialisieren. Jedoch können bestimmte Prozessoren auf das Zurücksetzen von Hardware-Verlaufsdaten für Cache-Datenstrukturen (z.B. Daten-Caches, Anweisungs-Caches und/oder Adressenübersetzungspuffer (TLBs - Translation-Lookaside Buffers)), z.B. über die Ausführung einer Cache-Rückschreib- und -Annullierung- (WBINVD - Write-Back and Invalidate Cache) Anweisung zum Zurückschreiben aller modifizierten Cache-Zeilen im internen Cache des logischen Prozessors in den Hauptspeicher und Annullieren (z.B. Leeren) der internen Caches, beschränkt sein. In einer Ausführungsform soll ein Prozessor in ein Steuerregister (z.B. CR3) schreiben, um den Inhalt in einem TLB zurückzusetzen (z.B. auf Null zu setzen) und/oder eine Anweisung zum Löschen (z.B. Annullieren) des (der) Caches eines Prozessors auszuführen.
Jedoch unterstützen bestimmte Hardwareprozessoren möglicherweise keine Anweisung, die das Löschen einer Verlaufsvorhersage basierend auf einer Laufzeitausführung gestattet. Es ist möglicherweise nicht wünschenswert (z.B. aus Sicherheitsgründen), dass ein erster Thread (z.B. ein Software-Thread) Zugriff auf Informationen basierend auf einer vorherigen Ausführung eines zweiten (oder mehrerer) Threads (z.B. Software-Threads) hat, und zu diesen Informationen können (z.B. Software-) Thread-Laufzeiteigenschaft-Verläufe zählen. Somit kann es wünschenswert sein, dass die Hardware Kenntnis von einer Kontextumschaltung von Threads (z.B. Software-Threads) hat. Bestimmte Ausführungsformen hierin sehen ein Verfahren vor, um es einem BS zu ermöglichen, einen Verlaufs-Reset anzufordern, z.B. über die Ausführung einer Anweisung, wie hierin diskutiert. Bestimmte Ausführungsformen hierin sehen ein Verfahren vor, um es einem BS zu ermöglichen, einen Hinweis zu erzeugen, dass ein Verlaufs-Reset stattfinden soll. Bestimmte Ausführungsformen hierin markieren zum Beispiel explizit eine Anfrage für einen Verlaufs-Reset, ohne die Ausführung einer Anweisung zum Durchführen einer Sicherung von Prozessorzustandskomponenten, die durch die Anweisung angegeben werden (z.B. XSAVE), und/oder einer Anweisung zum Wiederherstellen gesicherter Prozessorzustandskomponenten, die durch die Anweisung angegeben werden (z.B. XRSTOR) (und der Hinweis zum Zurücksetzen des Verlaufs wird als Teil der Wiederherstellung von spezifischem Kontext erzeugt, wie z.B., jedoch nicht darauf beschränkt, der Wiederherstellung eines Wertes in einem modellspezifischen Register). Bestimmte Ausführungsformen hierin sind auf eine Anweisung gerichtet, die (z.B. getrennt von Ressourcen zum Sichern und Wiederherstellen von Kontext) ein modellspezifisches Register verwendet (z.B. wie unten unter Bezugnahme auf 3 diskutiert), um die Hardware auf einen möglichen Bedarf an einem Verlaufs-Reset hinzuweisen.
Bestimmte Ausführungsformen hierin sind auf eine Anweisung gerichtet, die einen Reset des internen Verlaufs des Prozessors veranlasst, z.B. die Anweisung zur Verwendung durch ein BS bei einem Kontextumschaltungsereignis. Bestimmte Ausführungsformen hierin sind auf eine Anweisung gerichtet, die nicht in ein modellspezifisches Register schreibt (dieses jedoch z.B. lesen kann) (und somit jegliche dadurch verursachte Latenz vermeidet). Bestimmte Ausführungsformen hierin sind auf eine Anweisung gerichtet, die einen unterschiedlichen Codepfad vom BS als Teil des BS-Schedulers vermeidet. In bestimmten Ausführungsformen weist ein BS (oder ein VMM (Virtual Machine Monitor)) die Fähigkeit auf, die möglichen Fähigkeiten dieser neuen Anweisung zu steuern (z.B. einen oder mehrere identifizierte Verläufe zu löschen usw.). Beispielfähigkeiten sind das Zurücksetzen von einem oder mehreren der Vorhersageverläufe eines Hardware-Guide-Schedulers (wie z.B. in 2 gezeigt).
Bestimmte Ausführungsformen hierein sind auf eine Anweisung gerichtet, die einen Verlaufs-Reset für die Hardware veranlasst, der z.B. für ein Software-Thread-Kontextumschaltungsereignis oder während der Laufzeit eines Software-Threads verwendet werden soll. Bestimmte Ausführungsformen hierin können verwendet werden, um eine bessere Anpassung der aktuell laufenden Software-Threads oder eines spezifischen Teils des laufenden Threads an die Hardware-interne Steuerheuristik zu ermöglichen. Ein Beispiel für einen internen Verlauf, der zurückgesetzt wird, ist ein Hardware-Guide-Scheduler (z.B. ein Zeitraumverlauf). Es kann wünschenswert sein, den internen Verlauf eines Prozessors zurückzusetzen (z.B. die Verläufe, die durch einen Hardware-Guide-Scheduler verwendet werden), um die Prozessoroptimierungen und seine Steuerung zurück ins BS für den tatsächlich laufenden Code (z.B. Software-Thread-Code) anzupassen. Eine BS-Software-Thread-Kontextumschaltung ist eines der Ereignisse, das während der Laufzeit eintreten kann, das den aktuellen Ausführungscode verändert. Ein weiteres Beispiel ist eine Teilmenge des Software-Threads, wobei es wichtig ist, einen vorhergehenden Verlauf zurückzusetzen (z.B. den Laufzeitvorhersage (z.B. Mikroarchitektur) -Verlauf eines Hardware-Guide-Schedulers), bevor ein neuer Teil (z.B. ein unterschiedlicher Software-Thread) zu laufen beginnt. Das Ermöglichen des Löschens des Verlaufs durch die Hardware kann eine bessere Leistung oder Performance ermöglichen, um Verlaufsinformationen zu löschen, welche die Ausführung von zwei unterschiedlichen Software-Threads stören können (sich z.B. auf die Genauigkeit auswirken kann), und/oder um ein Sicherheitsinformationsleck zwischen zwei unterschiedlichen Software-Threads (oder anderen sensiblen Softwareflüssen) zu vermeiden.
1 veranschaulicht ein Computersystem 100, das einen Prozessorkern 109 aufweist, gemäß Ausführungsformen der Offenbarung. Der Prozessorkern 109 weist mehrere Komponenten auf (z.B. Mikroarchitektur-Vorhersage- und -Caching-Mechanismen), die durch mehrere Kontexte gemeinsam genutzt werden können. Zum Beispiel können ein Verzweigungszielpuffer (BTB - Branch Target Buffer) 124, ein Anweisungs-Cache 132 und/oder ein Rücksendestapelpuffer (RSB - Return Stack Buffer) 144 durch mehrere Kontexte gemeinsam genutzt werden. Bestimmte Ausführungsformen weisen eine Kontextmanagerschaltung 110 zum gleichzeitigen Aufrechterhalten mehrerer einmaliger Zustände im Zusammenhang mit mehreren Kontexten und zum Umschalten aktiver Kontexte zwischen denjenigen, die durch die Kontextmanagerschaltung verfolgt werden, auf.
Das abgebildete Computersystem 100 weist einen Verzweigungsprädiktor 120 und einen Verzweigungsadressrechner 142 (BAC - Branch Address Calculator) in einem Pipeline-Prozessorkern 109(1)-109(N) gemäß Ausführungsformen der Offenbarung auf. Bezugnehmend auf 1 weist ein Pipeline-Prozessorkern (z.B. 109(1)) eine Anweisungszeiger (IP - Instruction Pointer) -Erzeugungsstufe 111, eine Abrufstufe 130, eine Decodierungsstufe 140 und eine Ausführungsstufe 150 auf. In einer Ausführungsform weist das Computersystem 100 mehrere Kerne 109(1-N) auf, wobei N jegliche positive Ganzzahl ist. In einer weiteren Ausführungsform weist das Computersystem 100 einen einzelnen Kern auf. In bestimmten Ausführungsformen unterstützt jede Instanz des Prozessorkerns 109(1-N) Multithreading (z.B. das Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads auf einem ersten und zweiten logischen Kern) und kann dies in einer Vielzahl von Möglichkeiten tun, einschließlich Zeitscheiben-Multithreading, gleichzeitigem Multithreading (wobei z.B. ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, für den der physische Kern gleichzeitiges Multithreading durchführt) oder einer Kombination davon (z.B. Abruf in Zeitscheiben und danach Decodierung und gleichzeitiges Multithreading). In der abgebildeten Ausführungsform weist jeder einzelne Prozessorkern 109(1) bis 109(N) eine Instanz des Verzweigungsprädiktors 120 auf. Der Verzweigungsprädiktor 120 kann einen Verzweigungszielpuffer (BTB) 124 aufweisen.
In bestimmten Ausführungsformen speichert der Verzweigungszielpuffer 124 (z.B. in einer Verzweigungsprädiktor-Anordnung) die vorhergesagte Zielanweisung, die jeder von mehreren Verzweigungsanweisungen entspricht (z.B. Verzweigungsanweisungen eines Abschnitts von Code, der mehrere Male ausgeführt wurde). In der abgebildeten Ausführungsform ist ein Verzweigungsadressrechner (BAC) 142 enthalten, welcher auf einen Rücksendestapelpuffer (RSB) 144 zugreift (diesen z.B. aufweist). In bestimmten Ausführungsformen soll der Rücksendestapelpuffer 144 die Rücksendeadressen von jeglichen CALL-Anweisungen (die z.B. ihre Rücksendeadresse auf den Stapel schieben) speichern (z.B. in einer LIFO (Last In First Out) -Stapeldatenstruktur).
Der Verzweigungsadressrechner (BAC) 142 wird zum Berechnen von Adressen für bestimmte Arten von Verzweigungsanweisungen und/oder zum Verifizieren von Verzweigungsvorhersagen, die durch einen Verzweigungsprädiktor (z.B. den BTB) getroffen werden, verwendet. In bestimmten Ausführungsformen führt der Verzweigungsadressrechner Verzweigungszielberechnung und/oder die Berechnung einer nächsten sequentiellen linearen Adresse durch. In bestimmten Ausführungsformen führt der Verzweigungsadressrechner statische Vorhersagen zu Verzweigungen basierend auf den Adressberechnungen durch.
In bestimmten Ausführungsformen enthält der Verzweigungsadressrechner 142 einen Rücksendestapelpuffer 144 zum Nachverfolgen der Rücksendeadressen der CALL-Anweisungen. In einer Ausführungsform versucht der Verzweigungsadressrechner, jegliche unangemessene Vorhersage, die durch den Verzweigungsprädiktor 120 getroffen wird, zu korrigieren, um Verzweigungsfehlvorhersage-Strafen zu verringern. Als ein Beispiel verifiziert der Verzweigungsadressrechner eine Verzweigungsvorhersage für diejenigen Verzweigungen, deren Ziel lediglich aus der Verzweigungsanweisung und dem Anweisungszeiger bestimmt werden kann.
In bestimmten Ausführungsformen pflegt der Verzweigungsadressrechner 142 den Rücksendestapelpuffer 144, der als ein Verzweigungsvorhersagemechanismus zum Bestimmen der Zieladresse von Rücksendeanweisungen genutzt wird, z.B. wenn der Rücksendestapelpuffer durch das Überwachen aller Verzweigungsanweisungen „Unterprogramm aufrufen“ und „aus Unterprogramm zurückkehren“ arbeitet. In einer Ausführungsform schiebt der Verzweigungsadressrechner, wenn der Verzweigungsadressrechner eine Verzweigungsanweisung „Unterprogramm aufrufen“ erkennt, die Adresse der nächsten Anweisung auf den Rücksendestapelpuffer, wobei z.B. ein Zeiger auf die Spitze des Stapels die Spitze des Rücksendestapelpuffers kennzeichnet. Indem die Adresse unmittelbar im Anschluss an jede Anweisung „Unterprogramm aufrufen“ auf den Rücksendestapelpuffer geschoben wird, enthält der Rücksendestapelpuffer in dieser Ausführungsform einen Stapel von Rücksendeadressen. Wenn der Verzweigungsadressrechner später eine Verzweigungsanweisung „aus Unterprogramm zurückkehren“ erkennt, entfernt der Verzweigungsadressrechner die oberste Rücksendeadresse vom Rücksendestapelpuffer, um z.B. die Rücksendeadresse zu verifizieren, die durch den Verzweigungsprädiktor 120 vorhergesagt wird. In einer Ausführungsform soll der Verzweigungsadressrechner für einen direkten Verzweigungstyp zum Beispiel übernommen (z.B. immer) für eine bedingte Verzweigung vorhersagen, und wenn der Verzweigungsprädiktor nicht übernommen für die direkte Verzweigung vorhersagt, hebt der Verzweigungsadressrechner die versäumte Vorhersage oder unangemessene Vorhersage des Verzweigungsprädiktors auf.
Der Kern 109 in 1 weist Schaltungen zum Validieren von Verzweigungsvorhersagen, die durch den Verzweigungsprädiktor 120 getroffen werden, auf. Jeder Eintrag des Verzweigungsprädiktors 120 (z.B. im BTB 124) kann ferner ein Feld „Gültig‟ und ein Feld „Bündeladresse‟ (BA - Bundle Address) aufweisen, welche zum Erhöhen der Genauigkeit und zum Validieren von Verzweigungsvorhersagen, die durch den Verzweigungsprädiktor 120 durchgeführt werden, verwendet werden, wie unten detaillierter beschrieben wird. In einer Ausführungsform bestehen das Feld „Gültig‟ und das Feld „BA‟ jeweils aus Ein-Bit-Feldern. In anderen Ausführungsformen kann die Größe der Felder „Gültig‟ und „BA‟ jedoch variieren. In einer Ausführungsform wird eine abgerufene Anweisung zum Decodieren an den Decoder 146 gesendet (z.B. über die Leitung 137 durch den BAC 142), und die decodierte Anweisung wird zum Ausführen an die Ausführungsschaltung (z.B. Einheit) 154 gesendet.
Das abgebildete Computersystem 100 weist ein Netzwerkgerät 101, eine Eingabe/Ausgabe (E/A) -Schaltung 103 (z.B. eine Tastatur), eine Anzeige 105 und einen Systembus (z.B. eine Zwischenverbindung) 107 auf.
In einer Ausführungsform werden die Verzweigungsanweisungen, die im Verzweigungsprädiktor 120 gespeichert sind, durch einen Compiler als Verzweigungsanweisungen vorausgewählt, die übernommen werden. In bestimmten Ausführungsformen weist der Compiler-Code 104, wie im Arbeitsspeicher 102 von 1 gespeichert gezeigt, eine Sequenz von Code auf, die, wenn sie ausgeführt wird, den Quellcode eines Programms, das in einer Hochsprache geschrieben ist, in ausführbaren Maschinencode übersetzt. In einer Ausführungsform weist der Compiler-Code 104 ferner zusätzlichen Verzweigungsprädiktor-Code 106 auf, der eine Zielanweisung für Verzweigungsanweisungen vorhersagt (zum Beispiel Verzweigungsanweisungen, die wahrscheinlich übernommen werden (z.B. vorausgewählte Verzweigungsanweisungen)). Der Verzweigungsprädiktor 120 (z.B. der BTB 124 davon) wird danach mit einer Zielanweisung für eine Verzweigungsanweisung aktualisiert. In einer Ausführungsform managt z.B. Software einen Hardware-BTB, wobei die Software den Vorhersagemodus spezifiziert oder wobei der Vorhersagemodus, der implizit durch den Modus der Anweisung definiert wird, die in den BTB geschrieben wird, auch ein Modusbit in dem Eintrag einstellt. Der Arbeitsspeicher 102 kann Betriebssystem (BS) -Code 160, VMM (Virtual Machine Monitor) -Code 162, ersten Anwendungscode (z.B. Programmcode) 164, zweiten Anwendungscode (z.B. Programmcode) 166 oder jegliche Kombination davon aufweisen. In Ausführungsformen für Berechnungen ist eine virtuelle Maschine (VM) eine Emulation eines Computersystems. In bestimmten Ausführungsformen basieren VMs auf einer spezifischen Computerarchitektur und stellen die Funktionalität eines zugrundeliegenden physischen Computersystems zur Verfügung. Ihre Implementierungen können spezialisierte Hardware, Firmware, Software oder eine Kombination beinhalten. In bestimmten Ausführungsformen ist ein VMM (Virtual Machine Monitor) (auch bekannt als ein Hypervisor) ein Softwareprogramm, dass, wenn es ausgeführt wird, die Erstellung, das Management und die Steuerung von VM-Instanzen ermöglicht und den Betrieb einer virtualisierten Umgebung auf einer physischen Host-Maschine managt. Ein VMM ist in bestimmten Ausführungsformen die primäre Software hinter Virtualisierungsumgebungen und -implementierungen. Wenn er über eine Host-Maschine (z.B. einem Prozessor) installiert ist, erleichtert ein VMM in bestimmten Ausführungsformen die Erstellung von VMs, z.B. jeweils mit separaten Betriebssystemen (BSs) und Anwendungen. Der VMM kann die Backend-Operation dieser VMs managen, indem er die notwendigen Rechen-, Arbeitsspeicher-, Speicher- und anderen Eingabe/Ausgabe (E/A) -Ressourcen zuteilt, wie z.B., jedoch nicht darauf beschränkt, eine Eingabe/Ausgabe-Arbeitsspeichermanagementeinheit (IOMMU - Input/OutputMemory Management Unit). Der VMM kann eine zentralisierte Schnittstelle zum Managen des gesamten Betriebs, des Status und der Verfügbarkeit von VMs, die über einer einzelnen Host-Maschine installiert sind oder über unterschiedliche und miteinander verbundene Hosts hinweg verteilt sind, bereitstellen.
Wie unten diskutiert, hat der abgebildete Kern (z.B. der Verzweigungsprädiktor 120 davon) Zugriff auf ein oder mehrere Register. In bestimmten Ausführungsformen weist der Kern ein oder mehrere Universalregister 108 auf.
In bestimmten Ausführungsformen weist jeder Eintrag für den Verzweigungsprädiktor 120 (z.B. im BTB 124 davon) ein Feld „Tag‟ und ein Feld „Ziel‟ auf. In einer Ausführungsform speichert das Feld „Tag‟ jedes Eintrags im BTB mindestens einen Abschnitt eines Anweisungszeigers (z.B. eine Arbeitsspeicheradresse), der eine Verzweigungsanweisung identifiziert. In einer Ausführungsform speichert das Feld „Tag‟ jedes Eintrags im BTB einen Anweisungszeiger (z.B. eine Arbeitsspeicheradresse), der eine Verzweigungsanweisung in Code identifiziert. In einer Ausführungsform speichert das Feld „Ziel‟ mindestens einen Abschnitt des Anweisungszeigers für das Ziel der Verzweigungsanweisung, die im Feld „Tag‟ des gleichen Eintrags identifiziert wird. Darüber hinaus weisen die Einträge für den Verzweigungsprädiktor 120 (z.B. im BTB 124 davon) in einer anderen Ausführungsform auch ein oder mehrere andere Felder auf. In bestimmten Ausführungsformen weist ein Eintrag kein separates Feld für die Vorhersage auf, ob die Verzweigungsanweisung übernommen wird, z.B. gilt, wenn eine Verzweigungsanweisung vorliegt (z.B. im BTB), diese als übernommen.
Wie in 1 gezeigt, empfängt der IP-Gen-Mux (IP-Erzeugungs-Multiplexer) 113 der IP-Erzeugungsstufe 111 einen Anweisungszeiger über die Leitung 114A. Der Anweisungszeiger, der über die Leitung 115A bereitgestellt wird, wird durch die Inkrementiererschaltung 115 erzeugt, welche eine Kopie des neuesten Anweisungszeigers vom Pfad 113A empfängt. Die Inkrementiererschaltung 115 kann den vorliegenden Anweisungszeiger um eine vorbestimmte Menge inkrementieren, um die nächste sequentielle Anweisung aus einer Programmsequenz zu erhalten, die gegenwärtig durch den Kern ausgeführt wird.
In einer Ausführungsform vergleicht der Verzweigungsprädiktor 120 bei Empfang des IP vom IP-Gen-Mux 113 einen Abschnitt des IP mit dem Feld „Tag‟ jedes Eintrags im Verzweigungsprädiktor 120 (z.B. im BTB 124). Wenn keine Übereinstimmung zwischen dem IP und dem Feld „Tag‟ des Verzweigungsprädiktors 120 gefunden wird, fährt der IP-Gen-Mux in dieser Ausführungsform mit der Auswahl des nächsten sequentiellen IP als die nächste abzurufende Anweisung fort. Umgekehrt liest der Verzweigungsprädiktor 120, wenn eine Übereinstimmung erkannt wird, das Feld „Gültig‟ des Verzweigungsprädiktor-Eintrags, welcher mit dem IP übereinstimmt. Wenn das Feld „Gültig‟ nicht gesetzt ist (z.B. einen logischen Wert von 0 aufweist), betrachtet der Verzweigungsprädiktor 120 den entsprechenden Eintrag in dieser Ausführungsform als „ungültig“ und ignoriert die Übereinstimmung zwischen dem IP und dem Tag des entsprechenden Eintrags, und das Verzweigungsziel des entsprechenden Eintrags wird nicht an den IP-Gen-Mux weitergeleitet. Andererseits fährt der Verzweigungsprädiktor 120, wenn das Feld „Gültig‟ des übereinstimmenden Eintrags gesetzt ist (z.B. einen logischen Wert von 1 aufweist), in dieser Ausführungsform mit dem Durchführen eines logischen Vergleichs zwischen einem vorbestimmten Abschnitt des Anweisungszeigers (IP) und dem Feld „Verzweigungsadresse (BA)‟ des übereinstimmenden Verzweigungsprädiktor-Eintrags fort. Wenn eine „zulässige Bedingung“ vorliegt, wird das Verzweigungsziel des übereinstimmenden Eintrags an den IP-Gen-Mux weitergeleitet, und ansonsten ignoriert der Verzweigungsprädiktor 120 die Übereinstimmung zwischen dem IP und dem Tag des Verzweigungsprädiktor-Eintrags. In einer Ausführungsform wird der Eintragsindikator nicht nur aus dem aktuellen Verzweigungs-IP gebildet, sondern auch mindestens aus einem Abschnitt des globalen Verlaufs.
Spezifischer gibt in einer Ausführungsform das Feld „BA‟ an, wo die entsprechende Verzweigungsanweisung innerhalb einer Linie des Cache-Arbeitsspeichers 132 gespeichert ist. In bestimmten Ausführungsformen ist ein Prozessor in der Lage, die Ausführung mehrerer Anweisungen pro Taktzyklus zu initiieren, wobei die Anweisungen nicht voneinander abhängig sind und nicht die gleichen Ausführungsressourcen verwenden.
Zum Beispiel weist jede Zeile des Anweisungs-Caches 132, der in 1 gezeigt ist, mehrere Anweisungen (z.B. sechs Anweisungen) auf. Darüber hinaus reagiert der Anweisungs-Cache 132 (z.B. im Fall eines „Treffers“), als Reaktion auf eine Abrufoperation durch die Abrufeinheit 134, in dieser Ausführungsform mit dem Bereitstellen einer vollständigen Zeile des Caches an die Abrufeinheit 134. Die Anweisungen innerhalb einer Cache-Zeile können als separate „Bündel“ gruppiert sein. Zum Beispiel können, wie in 1 gezeigt, die ersten drei Anweisungen in einer Cache-Zeile 133 als Bündel 0 adressiert sein und die zweiten drei Anweisungen können als Bündel 1 adressiert sein. Alle Anweisungen innerhalb eines Bündels sind unabhängig voneinander (können z.B. gleichzeitig zur Ausführung ausgegeben werden). Das Feld „BA‟, das in den Einträgen des Verzweigungsprädiktors 120 bereitgestellt ist, wird zum Identifizieren der Bündeladresse der Verzweigungsanweisung verwendet, welche in bestimmten Ausführungsformen dem entsprechenden Eintrag entspricht. Zum Beispiel identifiziert die BA in einer Ausführungsform, ob die Verzweigungsanweisung im ersten oder zweiten Bündel einer bestimmten Cache-Zeile gespeichert ist.
In einer Ausführungsform führt der Verzweigungsprädiktor 120 einen logischen Vergleich zwischen dem Feld „BA‟ eines übereinstimmenden Eintrags und einem vorbestimmten Abschnitt des IP durch, um zu bestimmen, ob eine „zulässige Bedingung“ vorliegt. Zum Beispiel wird in einer Ausführungsform die fünfte Bit-Position des IP (z.B. IP[4]) mit dem Feld „BA‟ eines übereinstimmenden Eintrags (z.B. im BTB) verglichen. In einer Ausführungsform liegt eine zulässige Bedingung vor, wenn IP[4] nicht höher als die BA ist. Eine derartige zulässige Bedingung hilft die offensichtlich unnötige Vorhersage einer Verzweigungsanweisung zu verhindern, welche nicht ausgeführt werden kann. D.h., wenn weniger als der gesamte IP beim Durchführen eines Vergleichs mit den Tags des Verzweigungsprädiktors 120 berücksichtigt wird, ist eine Übereinstimmung mit einem Tag möglich, bei welcher es sich möglicherweise nicht um eine echte Übereinstimmung handelt. Dennoch gibt eine Übereinstimmung zwischen dem IP und einem Tag des Verzweigungsprädiktors eine bestimmte Cache-Zeile an, welche eine Verzweigungsanweisung enthält, die dem entsprechenden Verzweigungsprädiktor-Eintrag entspricht, der möglicherweise in Kürze ausgeführt wird. Spezifisch soll, wenn die Bündeladresse des IP nicht höher als das Feld „BA‟ des übereinstimmenden Verzweigungsprädiktor-Eintrags ist, die Verzweigungsanweisung in der entsprechenden Cache-Zeile bald ausgeführt werden. Daher kann in bestimmten Ausführungsformen ein Leistungsvorteil erzielt werden, indem mit dem Abrufen des Ziels der Verzweigungsanweisung fortgefahren wird.
Wie oben diskutiert, wird in diesem Beispiel, wenn eine „zulässige Bedingung“ vorliegt, das Verzweigungsziel des übereinstimmenden Eintrags an den IP-Gen-Mux weitergeleitet. Ansonsten ignoriert der Verzweigungsprädiktor die Übereinstimmung zwischen dem IP und dem Tag. In einer Ausführungsform wird das Verzweigungsziel, das vom Verzweigungsprädiktor weitergeleitet wird, zunächst an einen Verzweigungsvorhersage (BP - Branch Prediction) -Umlenk-Mux 128 gesendet, bevor es an den IP-Gen-Mux gesendet wird. Der BP-Umlenk-Mux 128, wie in 1 gezeigt, kann auch Anweisungszeiger von anderen Verzweigungsvorhersagegeräten empfangen. In einer Ausführungsform werden die Eingabeleitungen, die durch den BP-Umlenk-Mux empfangen werden, priorisiert, um zu bestimmen, welcher Eingabeleitung das Durchqueren des BP-Umlenk-Mux hin zum IP-Gen-Mux gestattet wird.
Zusätzlich zum Weiterleiten eines Verzweigungsziels zum BP-Umlenk-Mux wird beim Erkennen einer Übereinstimmung zwischen dem IP und einem Tag des Verzweigungsprädiktors die BA des übereinstimmenden Verzweigungsprädiktor-Eintrags zum Verzweigungsadressrechner (BAC) 142 weitergeleitet. Der BAC 142 ist in 1 als in der Decodierungsstufe 140 befindlich gezeigt, kann sich jedoch auch in (einer) anderen Stufe(n) befinden. Der BAC kann über die Leitung 137 auch eine Cache-Zeile von der Abrufeinheit 134 empfangen.
Der durch den IP-Gen-Mux ausgewählte IP wird in diesem Beispiel über die Datenleitung 135 auch an die Abrufeinheit 134 weitergeleitet. Nachdem der IP durch die Abrufeinheit 134 empfangen wurde, wird die Cache-Zeile, die dem IP entspricht, aus dem Anweisungs-Cache 132 abgerufen. Die Cache-Zeile, die vom Anweisungs-Cache empfangen wird, wird über die Datenleitung 137 an den BAC weitergeleitet.
Bei Empfang der BA liest der BAC in diesem Beispiel die BA, um zu bestimmen, wo sich die vorausgewählte Verzweigungsanweisung (z.B. identifiziert im übereinstimmenden Verzweigungsprädiktor-Eintrag) in der nächsten Cache-Zeile, die durch den BAC empfangen werden soll, befindet (z.B. im ersten oder zweiten Bündel der Cache-Zeile). In einer Ausführungsform ist vorbestimmt, wo sich die Verzweigungsanweisung innerhalb eines Bündels einer Cache-Zeile befindet (z.B. wird die Verzweigungsanweisung in einem Bündel von drei Anweisungen als die zweite Anweisung gespeichert).
In alternativen Ausführungsformen weist die BA zusätzliche Bits auf, um die Adresse der Verzweigungsanweisung innerhalb einer Cache-Zeile spezifischer zu identifizieren. Daher wäre die Verzweigungsanweisung nicht auf eine spezifische Anweisungsposition innerhalb eines Bündels beschränkt.
Nachdem der BAC die Adresse der vorausgewählten Verzweigungsanweisung innerhalb der Cache-Zeile bestimmt hat und die entsprechende Cache-Zeile von der Abrufeinheit 134 empfangen hat, decodiert der BAC die entsprechende Anweisung, um zu verifizieren, dass der IP tatsächlich einer Verzweigungsanweisung entspricht. Wenn es sich bei der Anweisung, die durch die BA in der empfangenen Cache-Zeile adressiert wird, um eine Verzweigungsanweisung handelt, ist keine Korrektur für die Verzweigungsvorhersage notwendig. Umgekehrt sendet der BAC, wenn es sich bei der entsprechenden Anweisung in der Cache-Zeile nicht um eine Verzweigungsanweisung handelt (d.h., der IP entspricht nicht einer Verzweigungsanweisung), eine Nachricht an den Verzweigungsprädiktor, um den entsprechenden Verzweigungsprädiktor-Eintrag zu annullieren, um ähnliche Fehlvorhersagen zu dem gleichen Verzweigungsprädiktor-Eintrag zu verhindern. Danach wird der annullierte Verzweigungsprädiktor-Eintrag durch einen neuen Verzweigungsprädiktor-Eintrag überschrieben.
Außerdem inkrementiert der BAC in einer Ausführungsform den IP um eine vorbestimmte Menge und leitet den inkrementierten IP über die Datenleitung 145 an den BP-Umlenk-Mux 128 weiter; dabei hat z.B. die Datenleitung 145, die vom BAC kommt, Vorrang vor der Datenleitung vom Verzweigungsprädiktor. Dadurch wird der inkrementierte IP an den IP-Gen-Mux weitergeleitet und an die Abrufeinheit weitergegeben, um die Verzweigungsfehlvorhersage durch das Abrufen der Anweisungen, die dem IP sequentiell folgen, zu korrigieren.
In bestimmten Ausführungsformen gestattet es die Kontextmanagerschaltung 110, dass eine oder mehrere der oben diskutierten gemeinsam genutzten Komponenten durch mehrere Kontexte genutzt werden, während z.B. das Durchsickern von Informationen über Kontexte hinweg, indem die gespeicherten Informationen direkt oder indirekt beobachtet werden, verringert wird. Das Rechensystem 100 (z.B. der Kern 109) kann ein Steuerregister (z.B. (ein) modellspezifische(s) Register 112 (z.B. das unten unter Bezugnahme auf 3 diskutierte MSR)), ein Segmentregister 114 (welches z.B. die aktuelle Berechtigungsstufe angibt), einen Hardware-Guide-Scheduler 116 (wie z.B. unten unter Bezugnahme auf 2 diskutiert) oder jegliche Kombination davon aufweisen. Das Segmentregister 114 kann einen Wert speichern, der eine aktuelle Berechtigungsstufe von Software, die auf einem logischen Kern arbeitet, angibt, z.B. separat für jeden logischen Kern. In einer Ausführungsform ist die aktuelle Berechtigungsstufe in einem Feld „Aktuelle Berechtigungsstufe (CPL - Current Privilege Level)‟ eines Codesegmentauswahlregisters des Segmentregisters 114 gespeichert. In bestimmten Ausführungsformen erfordert der Prozessorkern 109 eine bestimmte Berechtigungsstufe zum Durchführen bestimmter Aktionen, zum Beispiel Aktionen, die durch einen bestimmten logischen Kern angefordert werden (z.B. Aktionen, die durch Software, die auf diesem bestimmten logischen Kern läuft, angefordert werden). Eine Instanz eines Hardware-Guide-Schedulers 116 kann sich in jedem Kern 109(1-N) des Computersystems 100 befinden (z.B. für jeden logischen Prozessor, der durch einen Kern implementiert wird). Eine einzelne Instanz eines Hardware-Guide-Schedulers 116 kann sich überall im Computersystem 100 befinden, z.B. eine einzelne Instanz des Hardware-Guide-Schedulers, die für alle vorliegenden Kerne 109(1-N) verwendet wird.
In einer Ausführungsform weisen die modellspezifischen Register 112 Konfigurations- und/oder Steuerregister auf. In einer Ausführungsform sind die Steuerregister getrennt/verschieden von den modellspezifischen Registern. In einer Ausführungsform wird (z.B. nur) auf Anfrage des BS, das auf dem Prozessor läuft, wo das BS z.B. im berechtigten Modus (z.B. im Systemmodus) arbeitet, in ein oder mehrere (z.B. modellspezifische) Register geschrieben, jedoch nicht für Code, der im nicht berechtigten Modus (z.B. im Benutzermodus) läuft. In einer Ausführungsform kann nur durch Software auf ein modellspezifisches Register geschrieben werden, die im Supervisor-Modus läuft, und nicht durch Software, die im Benutzermodus läuft.
In bestimmten Ausführungsformen decodiert der Decoder 146 eine Anweisung gemäß dieser Offenbarung, und diese decodierte Anweisung wird durch die Ausführungsschaltung 154 ausgeführt, zum Beispiel um mehrere Software-Thread-Laufzeiteigenschaft-Verläufe, z.B. des Hardware-Guide-Schedulers 116, zurückzusetzen.
Das Computersystem 100 kann eine Leistungsüberwachungsschaltung 168 aufweisen, die z.B. jegliche Zahl von Leistungszählern zum Zählen, Überwachen und/oder Protokollieren von Ereignissen, Aktivitäten und/oder Maßnahmen in Bezug auf die Leistung darin aufweist. In verschiedenen Ausführungsformen können Leistungszähler durch Software programmiert werden, die auf einem Kern zum Protokollieren von Leistungsüberwachungsinformationen läuft. Zum Beispiel können jegliche der Leistungszähler zum Inkrementieren für jedes Auftreten eines ausgewählten Ereignisses oder zum Inkrementieren für jeden Taktzyklus während eines ausgewählten Ereignisses programmiert werden. Zu den Ereignissen können jegliche aus einer Vielzahl von Ereignissen in Bezug auf eine Ausführung von Programmcode auf einem Kern zählen, wie z.B. Verzweigungsfehlvorhersagen, Cache-Treffer, Cache-Fehler, Adressenübersetzungspuffer-Treffer, Adressenübersetzungspuffer-Fehler usw. Daher können Leistungszähler bei den Anstrengungen verwendet werden, Programmcode abzustimmen oder zu profilieren, um die Leistung zu verbessern oder zu optimieren.
Jeder Kern 109 des Computersystems 100 kann der gleiche sein (z.B. symmetrische Kerne), oder eine angemessene Teilmenge von einem oder mehreren der Kerne kann sich von den anderen Kernen unterscheiden (z.B. asymmetrische Kerne). In einer Ausführungsform weist ein Satz von asymmetrischen Kernen einen ersten Kerntyp (z.B. einen Kern mit niedrigerem Stromverbrauch) und einen zweiten Kerntyp mit höherer Leistung (z.B. einen Kern mit höherem Stromverbrauch) auf.
In bestimmten Ausführungsformen weist ein Computersystem mehrere Kerne auf, die alle eine gleiche Anweisungssatzarchitektur (ISA) ausführen. In bestimmten Ausführungsformen weist ein Computersystem mehrere Kerne auf, die jeweils eine Anweisungssatzarchitektur (ISA) aufweisen, gemäß welcher sie Anweisungen ausführen, die durch Software an sie und/oder das System ausgegeben oder bereitgestellt werden. In dieser Spezifikation kann sich die Verwendung des Begriffs „Anweisung“ im Allgemeinen auf diese Art von Anweisung beziehen (welche auch als eine Makroanweisung oder eine ISA-Ebenen-Anweisung bezeichnet werden kann), im Gegensatz zu Folgenden: (1) einer Mikroanweisung oder Mikrooperation, die aufgrund der Decodierung (z.B. durch einen Hardwareanweisungsdecoder) einer Makroanweisung an Ausführungs- und/oder Zeitplanungshardware bereitgestellt werden kann, und/oder (2) einem Befehl, einer Prozedur, einem Programm, einem Unterprogramm oder einem anderen Softwarekonstrukt, dessen/deren Ausführung und/oder Durchführung die Ausführung mehrerer ISA-Ebenen-Anweisungen beinhaltet.
Bei anderen derartigen Systemen kann das System heterogen sein, weil es Kerne aufweist, die unterschiedliche ISAs aufweisen. Ein System kann einen ersten Kern mit Hardware, Festverdrahtung, Mikrocode, Steuerlogik und/oder anderer Mikroarchitektur, die zum Ausführen bestimmter Anweisungen gemäß einer bestimmten ISA (oder Erweiterungen oder einer anderen Teilmenge einer ISA) ausgelegt ist, aufweisen, und das System kann auch einen zweiten Kern ohne eine derartige Mikroarchitektur aufweisen. Mit anderen Worten, der erste Kern kann zum Ausführen dieser bestimmten Anweisungen ohne jegliche Translation, Emulation oder andere Umwandlung der Anweisungen (außer der Decodierung von Makroanweisungen zu Mikroanweisungen und/oder Mikrooperationen) in der Lage sein, wohingegen der zweite Kern dies nicht ist. In diesem Fall kann diese bestimmte ISA (oder Erweiterungen oder eine Teilmenge einer ISA) als durch den ersten Kern unterstützt (oder systemunterstützt) und als durch den zweiten Kern nicht unterstützt bezeichnet werden, und/oder das System kann als eine heterogene ISA aufweisend bezeichnet werden.
Bei anderen derartigen Systemen kann das System heterogen sein, weil es Kerne aufweist, welche die gleiche ISA aufweisen, sich jedoch hinsichtlich der Leistung, des Stromverbrauchs und/oder einer anderen Verarbeitungsmetrik oder - fähigkeit unterscheiden. Die Unterschiede können durch die Größe, Geschwindigkeit und/oder Mikroarchitektur des Kerns und/oder seiner Merkmale entstehen. In einem heterogenen System können ein oder mehrere Kerne als „groß“ bezeichnet werden, weil sie in der Lage sind, ein höheres Leistungsniveau (z.B. mehr Anweisungen pro Zyklus (IPC - Instructions Per Cycle)), mehr Stromverbrauch (z.B. weniger energieeffizient) und/oder eine andere Metrik bereitzustellen, dazu verwendet werden können und/oder ihre Verwendung dies tut und/oder darin resultiert, als dies bei einem oder mehreren anderen „kleinen“ Kernen im System der Fall ist.
Bei diesen und/oder anderen heterogenen Systemen kann es möglich sein, dass eine Aufgabe durch unterschiedliche Arten von Kernen durchgeführt wird. Außerdem kann es möglich sein, dass ein Scheduler (z.B. ein Hardware-Scheduler oder ein Software-Scheduler eines Betriebssystems, das auf dem Prozessor ausgeführt wird) Aufgaben für unterschiedliche Kerne plant oder an unterschiedliche Kerne versendet und/oder Aufgaben zwischen/unter unterschiedlichen Kernen verschiebt (im Allgemeinen ein „Aufgaben-Scheduler“). Daher können die Anstrengungen zum Optimieren, Ausgleichen oder anderweitigen Beeinflussen des Durchsatzes, der Wartezeit, der Antwortzeit, der Latenz, der Fairness, der Dienstqualität, der Leistung, des Stromverbrauchs und/oder einer anderen Maßnahme auf einem heterogenen System Aufgabenzeitplanungsentscheidungen beinhalten.
Zum Beispiel kann es, wenn eine bestimmte Aufgabe hauptsächlich aufgrund von Arbeitsspeicherzugriffen mit langer Latenz aufgehalten wird, effizienter sein, sie auf einem kleinen Kern zu planen und Energie eines ansonsten größeren Kerns zu sparen. Andererseits können schwere Aufgaben auf einem großen Kern geplant werden, um die Berechnung z.B. schneller abzuschließen und das System früher in einen Ruhezustand/Leerlauf übergehen zu lassen. Aufgrund der Diversität von Arbeitslasten, die ein System (z.B. ein Client) durchführen kann, der dynamischen Eigenschaften einer Arbeitslast und den Bedingungen des Systems selbst, ist es möglicherweise für eine reine Softwarelösung nicht ganz unkompliziert, derartige Entscheidungen zu treffen. Daher kann die Verwendung von Ausführungsformen hierin (z.B. eines Hardware-Guide-Schedulers) wünschenswert sein, um Informationen bereitzustellen, auf welchen derartige Entscheidungen, teilweise oder vollständig, basieren können. Außerdem kann die Verwendung dieser Ausführungsformen bei den Anstrengungen zum Optimieren und/oder Abstimmen von Anwendungen basierend auf den Informationen, die bereitgestellt werden können, wünschenswert sein.
Ausführungsformen können zusätzlich oder stattdessen auch andere gewünschte Vorteile bereitstellen, wie z.B. das Ermöglichen von Vorhersagen von Leistungsergebnissen basierend auf den dynamischen Eigenschaften eines Systems, das Eliminieren eines Bedarfs, eine Arbeitslast auf jedem Kern laufen zu lassen, um seine Arbeitsmenge zu messen, indem ISA-Ebenen-Zähler (z.B. eine Zahl von Lastanweisungen) bereitgestellt werden, die durch verschiedene Kerne gemeinsam genutzt werden können, und das Senken der Hardwareimplementierungskosten der Leistungsüberwachung durch das Bereitstellen eines einzelnen Zählers, der auf mehreren Leistungsüberwachungsereignissen basiert.
Ein Prozessor kann einen Hardware-Guide-Scheduler aufweisen, der durch mehrere Kontexte (und/oder Kerne) gemeinsam genutzt wird, z.B. wie weiter unten unter Bezugnahme auf 2 diskutiert.
Ein Prozessor kann auch andere gemeinsam genutzte Strukturen enthalten, die sich mit dem Zustand beschäftigen, einschließlich zum Beispiel Vorhersage strukturen, Caching-Strukturen, einer physischen Registerdatei (umbenannter Zustand) und einem gepufferten Zustand (ein Speicherpuffer). Vorhersagestrukturen, wie z.B. Verzweigungsprädiktoren oder Vorabrufeinheiten, können einen Zustand über vergangenes Ausführungsverhalten speichern, das zum Vorhersagen von zukünftigem Verhalten verwendet wird. Ein Prozessor kann diese Vorhersagen verwenden, um eine Spekulationsausführung zu lenken, wodurch eine Leistung erzielt wird, die sonst nicht möglich wäre. Caching-Strukturen, wie z.B. Caches oder TLBs, können lokale Kopien eines gemeinsam genutzten Zustands aufbewahren, wodurch Zugriffe durch den Prozessor sehr schnell werden.
Gemeinsam genutzte Strukturen sind ein Sicherheitsrisiko. Informationen können über Kontexte hinweg durchsickern, indem die gespeicherten Informationen direkt oder indirekt beobachtet werden. Außerdem kann das Verhalten in einem Opferkontext beeinflusst werden, indem aus dem Inneren eines angreifenden Kontextes heraus trainiert wird. Die Offenbarung hierin behebt einige dieser Probleme in bestimmten Ausführungsformen.
2 veranschaulicht einen Hardware-Guide-Scheduler 116 gemäß Ausführungsformen der Offenbarung. Der Hardware-Guide-Scheduler 116 (und/oder der Hybrid-Skalierungsprädiktor 240) kann in Logikgattern und/oder jeglicher anderen Art von Schaltungen implementiert werden, welche komplett oder in Teilen in einer diskreten Komponente enthalten sein können und/oder in die Schaltungen eines Verarbeitungsgerätes oder jeglicher anderen Vorrichtung in einem Computer oder einem anderen Informationsverarbeitungssystem integriert sein können, zum Beispiel implementiert in einem Kern (wie z.B. dem Kern 109 in 1) und/oder einem Systemagent (wie z.B. dem Systemagent 1510 in 15 oder 19) in einem heterogenen SoC (wie z.B. einer heterogenen Instanz des SoC 1900 in 19). Ein Guide-Scheduler kann durch Firmware-Code implementiert werden.
In 2 stellt jede von jeglicher Zahl von ungewichteten Ereigniszählungen (als Eo 210A bis E_N 210N gezeigt) eine ungewichtete Ereigniszählung oder jegliche andere Ausgabe eines Leistungszählers (im Allgemeinen jeweils eine „ungewichtete Ereigniszählung“) dar, wie z.B. jeglicher Leistungszähler in der Leistungsüberwachungsschaltung 168 von 1. In verschiedenen Ausführungsformen können Eo 210A bis E_N 210N einen Satz von jeglicher Zahl von ungewichteten Ereigniszählungen darstellen, einschließlich jeglicher Zahl von Teilmengen von ungewichteten Ereigniszählungen von unterschiedlichen Kernen. Zum Beispiel können die ungewichteten Ereigniszählungen von Leistungszählern, die sich alle in einem Kern befinden, von einem oder mehreren Leistungszählern in einem ersten Kern plus einem oder mehreren Leistungszählern in einem zweiten Kern, von einem oder mehreren Leistungszählern in einem ersten Kern plus einem oder mehreren Leistungszählern in einem zweiten Kern plus einem oder mehreren Leistungszählern in einem dritten Kern und so weiter stammen. Außerdem kann jegliche eine von mehreren der Ereigniszählungen (z.B. Eo 210A bis E_N 210N) eine Ausgabe (z.B. eine Rückmeldung) von einem aktiven Laufzeitzähler (z.B. einem Arbeitszähler) darstellen, wie z.B. dem Arbeitszähler 230 (wie unten beschrieben), wie in einer Ausführungsform, in welcher eine hierarchische Anordnung von Leistungs- und Arbeitszählern implementiert ist (es sei darauf hingewiesen, dass in einer derartigen Ausführungsform eine Ereigniszählung als eine ungewichtete Ereigniszählung bezeichnet werden kann, selbst wenn sie möglicherweise durch einen Arbeitszähler basierend auf gewichteten Ereigniszählungen erzeugt wurde).
In 2 stellt das Gewichte-Register 220 ein programmierbares oder konfigurierbares Register oder einen anderen Speicherort (oder eine Kombination von Speicherorten) zum Speichern jeglicher Zahl von Gewichtswerten (als Wo 222A bis W_N 222N gezeigt) dar, wobei jeder Gewichtswert einer der ungewichteten Ereigniszählungen entspricht und durch eine entsprechende Gewichtungseinheit (als die Gewichtungseinheiten 224A bis 224N gezeigt) zum Gewichten der entsprechenden ungewichteten Ereigniszählung und zum Erzeugen einer gewichteten Ereigniszählung verwendet werden soll. Die Gewichtswerte können ein abgestimmter Satz von Werten sein. Zum Beispiel kann Software oder Firmware einen Gewichtswert von 1 zu Eo und einen Gewichtswert von 2 zu E_N zuweisen, in welchem Fall die Gewichtungseinheit 224A Eo mit einem Faktor von 1 gewichten (z.B. skalieren oder multiplizieren) kann und die Gewichtungseinheit 224N E_N mit einem Faktor von 2 gewichten (z.B. skalieren oder multiplizieren) kann. In verschiedenen Ausführungsformen können jegliche Gewichtswerte (einschließlich 0), jeglicher Bereich von Gewichtswerten und/oder jeglicher Gewichtungsansatz (z.B. Multiplizieren, Dividieren, Addieren usw.) verwendet werden. In verschiedenen Ausführungsformen können Implementierungen eines Gewichte-Registers und/oder von Gewichtungseinheiten die Auswahl an Gewichtswerten auf einen von einer Zahl von möglichen Gewichtswerten begrenzen.
In 2 werden gewichtete Ereigniszählungen (als die Ausgaben der Gewichtungseinheiten 224A bis 224N gezeigt) zur Verarbeitung durch einen Arbeitszähler empfangen (als der heterogene (z.B. Hybrid-) Zähler (HCNT - Heterogenous Counter) 230 gezeigt, kann jedoch für homogene oder heterogene Prozessoren/Systeme verwendet werden). In einer Ausführungsform kann die Verarbeitung von gewichteten Ereigniszählungen das Summieren der gewichteten Ereigniszählungen zum Erzeugen eines Maßes einer Arbeitsmenge (im Allgemeinen eine „gemessene Arbeitsmenge“) umfassen. Verschiedene Ausführungsformen können dafür sorgen, dass diese gemessene Arbeitsmenge auf einer Vielzahl von Leistungsmessungen oder anderen Parametern, die jeweils auf verschiedene Weise skaliert oder manipuliert werden, basiert und für eine Vielzahl von Zwecken verwendet wird. In einer Ausführungsform kann ein Arbeitszähler zum Bereitstellen eines dynamischen Profils der aktuellen Arbeitslast verwendet werden.
Zum Beispiel kann der HCNT 230 zum Erzeugen einer gewichteten Summe von verschiedenen Klassen von Leistungsüberwachungsereignissen, die durch alle Kerne in einem System (z.B. einem SoC) dynamisch geschätzt werden können, verwendet werden. Der HCNT 230 kann zum Vorhersagen einer Hardware-Guide-Scheduler (HGS) -Klasse verwendet werden, z.B. kann der HCNT 230 als eine Quelle für den Hybrid-Skalierungsprädiktor 240 und/oder für jegliche Software 250, die Zugriff auf den HCNT 230 hat, verwendet werden. Die Ereignisse können Unterklassen einer ISA (z.B. AVX-Gleitkomma, AVX2-Ganzzahl), Spezialanweisungen (z.B. eine wiederholte Zeichenfolge) oder Kategorien von Engpässen (z.B. Frontend-gebunden aus Top-Down-Analyse) sein. Die Gewichte können derart ausgewählt werden, dass sie eine Art von Ausführungscode (z.B. Arbeitsspeicherstillstände oder Verzweigungscode) und/oder ein Leistungsverhältnis (z.B. 2 für eine Anweisungsklasse, die auf einem großen Kern doppelt so schnell ausgeführt wird, und 1 für alle anderen Anweisungsklassen), einen Skalar der Arbeitsmenge (z.B. 2 für verschmolzene Multiplikationsanweisungen) usw. reflektieren.
Bestimmte Ausführungsformen sorgen dafür, dass jegliche von einer Vielzahl von Ereignissen gezählt und/oder summiert werden, einschließlich Ereignissen in Bezug auf arithmetische Gleitkomma (z.B. 128-Bit) - Vektoranweisungen, arithmetische Ganzzahl (z.B. 256-Bit) -Vektoranweisungen, arithmetische Ganzzahl-Vektoranweisungen für ein neuronales Netz, Lastanweisungen, Speicheranweisungen, wiederholte Zeichenfolgen, Top-Down-Mikroarchitekturanalyse (TMA) -Level-1-Metriken (z.B. Frontend-gebunden, Backend-gebunden, schlechte Spekulation, Ausscheiden) und/oder jegliches Leistungsüberwachungsereignis, das durch jeglichen Zähler gezählt wird.
Zusätzlich zu einem Arbeitszähler gemäß einer Ausführungsform der Offenbarung veranschaulicht 2 eine Darstellung von Nutzungen eines Arbeitszählers gemäß Ausführungsformen der Offenbarung, einschließlich durch einen Hybrid-Skalierungsprädiktor 240 und/oder durch jegliche Software 250, die Zugriff auf den Arbeitszähler hat. In einer Ausführungsform kann der Hybrid-Skalierungsprädiktor 240 in Hardware oder Firmware implementiert sein, kann Informationen (zum Beispiel direkte oder indirekte Informationen, z.B. durch das Ermöglichen eines Bereiches von Indexen basierend auf den Zählerwerten) an ein BS 242 bereitstellen und/oder kann zum Vorhersagen von Leistungsskalierung (z.B. zwischen großen und kleinen Kernen) verwendet werden, z.B. durch das Bereitstellen eines Hinweises basierend auf dem Verlauf an die Hardware (z.B. über das Schreiben in ein MSR, das durch das BS gelesen wird).
In einer Ausführungsform kann ein Arbeitszähler zum Bereitstellen von Hinweisen (die z.B. in ein MSR geschrieben werden) an ein Betriebssystem, das auf einem heterogenen (oder z.B. homogenen) SoC oder System läuft, verwendet werden, wo die Hinweise zur Aufgabenplanung verwendet werden können, welche die Leistung und/oder die Dienstqualität verbessern kann. Hierbei handelt es sich zum Beispiel um ein homogenes System, das eine oder mehrere Instanzen des gleichen Kerns aufweist, zur Verwendung beim optimalen Mehrkern-Thread-Scheduling. Zum Beispiel kann ein heterogenes Client-System, das einen oder mehrere große Kerne und einen oder mehrere kleine Kerne aufweist, zum Ausführen einer Anwendung für künstliche Intelligenz (KI) (z.B. ein Modell für maschinelles Lernen) verwendet werden, einschließlich einer bestimmten Klasse von Anweisungen, welche die Verarbeitung der Art von Anweisungen, die typischerweise in der KI-Anwendung verwendet werden, z.B. insbesondere oder nur, wenn sie auf einem großen Kern ausgeführt werden, beschleunigen können. Die Verwendung eines Arbeitszählers, der zum Überwachen der Ausführung von dieser Klasse von Anweisungen programmiert ist, kann Hinweise an ein BS bereitstellen, um das BS dahingehend zu lenken, dass es Threads, welche diese Anweisungen aufweisen, auf großen Kernen anstatt kleinen Kernen plant, wodurch die Leistung und/oder die Dienstqualität verbessert wird.
In bestimmten Ausführungsformen sind die Gewichtswerte derart programmierbar, dass sie für das Abstimmen der Gewichte (z.B. in einem Labor) basierend auf tatsächlichen Ergebnissen sorgen. In Ausführungsformen können ein oder mehrere Gewichte von Null verwendet werden, um ein bestimmtes Ereignis oder eine bestimmte Klasse von Ereignissen abzutrennen. In Ausführungsformen können ein oder mehrere Gewichte von Null verwendet werden, um verschiedene Komponenten zu isolieren, die in einen Arbeitszähler einfließen. Ausführungsformen hierin können eine Option unterstützen, dass Hardware und/oder Software (z.B. ein BS) einen Arbeitszähler aus jeglichem von einer Vielzahl von Gründen aktiviert/deaktiviert, um zum Beispiel einen Leistungsverlust zu vermeiden, wenn der Arbeitszähler nicht im Einsatz ist.
In einer Ausführungsform verwendet ein Scheduler von Betriebssystemcode (z.B. der BS-Code 160 in 1) den Hardware-Guide-Scheduler 116 (und/oder den Hybrid-Skalierungsprädiktor 240) zum Auswählen des besten Kerns (z.B. Kerntyps) (oder einer anderen Komponente), der zum Ausführen eines Threads für einen Software-Thread verwendet werden soll, z.B. für einen Software-Thread des ersten Anwendungscodes (z.B. der erste Anwendungscode 164 in 1) oder des zweiten Anwendungscodes (z.B. der zweite Anwendungscode 166 in 1).
Software-Thread-Laufzeiteigenschaft-Verläufe (die z.B. die hierin diskutierten Gewichtswerte und/oder HCNT-Zählerwerte enthalten) können für einen ersten Software-Thread von Nutzen sein, jedoch nicht für einen anschließenden zweiten Software-Thread. Somit sehen bestimmte Ausführungsformen hierin eine Anweisung (und ein Verfahren) zum Löschen der Software-Thread-Laufzeiteigenschaft-Verläufe bei einer Kontextumschaltung (z.B. eine Umschaltung vom ersten Software-Thread zum zweiten Software-Thread) vor. Zum Beispiel wird dabei der aktuelle Wert des HCNT-Zählers gelöscht (und somit die Auswirkung dieses Wertes auf den vollständigen Vorhersagefluss). Zum Beispiel werden die aktuellen Werte der Zähler E0 ... En und/oder des HCNT 230 in 2 gelöscht.
In einer Ausführungsform ist die Anweisungsmnemonik „HRESET“, jedoch kann sie für andere Ausführungsformen auch eine andere Mnemonik sein. Der Nutzungs-Opcode von HRESET kann einen direkten Operanden, andere Arten von Operanden oder null explizite Operanden (z.B. definiert ohne die Verwendung von jeglichem Operanden) enthalten. In einer Ausführungsform ignoriert die Hardware (z.B. der Prozessorkern) jeglichen Wert eines direkten Operanden (z.B. ohne eine Ausnahme (z.B. einen Fehler) zu verursachen) und/oder jegliche anfragespezifische Einstellung. Es sollte verstanden werden, dass andere Ausführungsformen den Wert eines direkten Operanden nutzen können (z.B. derart, dass er für andere Verwendungen reserviert wird). In einer weiteren Ausführungsform, in welcher die Anweisung einen direkten Operanden aufweist, ist es möglich zu definieren, dass dieser direkte Operand nur Null aufweist (oder ansonsten eine Ausnahme (z.B. einen Fehler) verursacht, wenn die Anweisung ausgeführt wird). Andere Operandenwerte werden möglicherweise nicht unterstützt, und eine inkorrekte Einstellung kann eine Ausnahme erzeugen, wie einen ungültigen Opcode (Invalid Opcode) (z.B. undefinierter Opcode (UnDefined Opcode) oder allgemeiner Schutzfehler (General Protection Fault)).
In einer Ausführungsform soll eine Anweisung einen expliziten (z.B. direkten) Operanden ignorieren, während es sich bei ihrem impliziten Operanden (z.B. nicht explizit in einem Feld der Anweisung spezifiziert) um ein Universalregister (z.B. ein EAX-Register) (z.B. der Universalregister 108 in 1) handeln kann (um z.B. 32 Optionen einer Bit-Masken-Konfiguration zu ermöglichen). Eine andere Option ist das Definieren der Anweisung ohne einen expliziten direkten Operanden, und in diesem Fall wäre eine gültige Verwendung der Opcode (z.B. entsprechend der Mnemonik HRESET), während zum Beispiel ihr impliziter Operand (z.B. nicht explizit in einem Feld der Anweisung spezifiziert) ein Universalregister sein kann (z.B. ein EAX-Register) (z.B. der Universalregister 108 in 1). In bestimmten Ausführungsformen ist der implizite Operand ein einzelnes Register (z.B. EAX) oder eine Verknüpfung mehrerer Register (z.B. soll EAX:EDX den Inhalt des Registers EAX gefolgt vom Inhalt des Registers EDX verknüpfen (um z.B. 64 Optionen einer Bit-Masken-Konfiguration zu ermöglichen)).
In bestimmten Ausführungsformen nutzt eine Anweisung einen neuen Opcode (z.B. keinen älteren Opcode einer älteren Anweisung), derart, dass zum Beispiel Hardware, die diese Anweisung nicht unterstützt, nicht in der Lage sein wird, diese auszuführen (in einem Fall wie diesem wird z.B. die Ausnahme „undefinierte Anweisung‟ erzeugt). In bestimmten Ausführungsformen kann die Verwendung dieser Anweisung beinhalten, dass Software (z.B. ein BS) prüfen soll, ob die Hardware die Ausführung dieser Anweisung unterstützt, bevor die Ausführung der Anweisung geplant wird. In einer Ausführungsform soll die Software prüfen, ob die Hardware die Ausführung der Anweisung überstützt, indem eine Merkmals-Bit-Einstellung für eine Prüfanweisung (die z.B. eine Mnemonik CPUID aufweist) ausgeführt wird.
In bestimmten Ausführungsformen ist die Ausführung der Anweisung nur für eine bestimmte Berechtigungsstufe gestattet (zum Beispiel die Supervisor-Ebene (z.B. Ring 0) und/oder die Benutzerebene (z.B. Ring 3)). In einer Ausführungsform, in welcher die Anweisung nur auf eine Verwendung durch die Supervisor-Ebene (z.B. ein BS) (z.B. nur in Ring 0) begrenzt ist, erzeugt eine Anfrage für die Ausführung der Anweisung für die Benutzerebene (z.B. eine Benutzeranwendung) eine Ausnahme, z.B. eine allgemeine Schutzausnahme.
Bestimmte Ausführungsformen hierin definieren eine neue Anweisung, bei welcher das BS in der Lage ist, das Löschen der Komponenten des Prozessors auszuwählen (um z.B. (nur) die Verläufe von einem oder mehreren logischen Prozessoren zu löschen) (um z.B. (nur) einen oder mehrere Software-Thread-Laufzeiteigenschaft-Verläufe zu löschen). In einer Ausführungsform weist die Anweisung einen Steuerparameter auf, um es Software (z.B. dem BS) zu ermöglichen, während der Laufzeit den exakten unterstützten Verlaufs-Reset zu steuern (z.B. mit einem viel schnelleren Verfahren als dem Schreiben in ein MSR). In bestimmten Ausführungsformen erfolgt die Steuerung der neuen Anweisung durch die Parameter der Anweisung (z.B. ein Datenregister, das 32-Bit-Steueroptionen ermöglicht, und/oder ein Satz von Datenregistern, der 64-Bit-Steueroptionen ermöglicht). In bestimmten Ausführungsformen definiert eine Anweisung auch die BS-Steuerung (z.B. Zustimmung) über die Unterstützungsfähigkeiten der Anweisung. In bestimmten Ausführungsformen enthält eine Anweisung einen impliziten Operanden (z.B. EAX) oder einen expliziten Operanden.
In einer Ausführungsform, in welcher die Anweisung im Benutzermodus (z.B. Ring 3) unterstützt wird, kann das BS die Fähigkeit aufweisen, zu steuern und zu optionieren, welche Fähigkeiten (z.B. von mehreren Fähigkeiten) die Anweisung aufweisen soll und/oder welche Art von Verlauf diese Anweisung zurücksetzen kann und auf welche Weise. Um dies zu unterstützen, kann in bestimmten Ausführungsformen eine BS-Unterstützung (z.B. ein BS-Systemaufruf einer Anwendungsprogrammierungsschnittstelle (API - Application Programming Interface)) angefordert werden und verwendet werden, um die Anweisung für Benutzerebenen-Code freizugeben, um anzugeben, welche Reset (z.B. HRESET) - Unterstützungsfähigkeiten für das BS freigegeben wurden (z.B. durch die Hardware unterstützt werden), und/oder verwendet werden, um jegliche Reset (z.B. HRESET) -Anweisungsparameter (z.B. auf der Supervisor-Ebene) zu steuern.
In einer Ausführungsform stellt ein BS diese neue Anweisung als Teil einer BS-Scheduler-Laufzeitunterstützung ein, z.B. für einen Kontextumschaltungsfluss (z.B. wie in 4 gezeigt), oder als Teil eines Threads während der Laufzeitunterstützung, die unterschiedliche Arten von Thread-Aufgaben steuern kann (z.B. wie in 5 gezeigt). In bestimmten Ausführungsformen ist die Anweisung mit einem neuen Opcode definiert, sodass die Software (z.B. das BS) zunächst prüfen soll, ob die Hardware diese Anweisung unterstützt und welche deren Fähigkeiten sind, bevor diese Anweisung verwendet werden kann. Somit wird in einer Ausführungsform ein unterschiedlicher Codepfad durch die Software definiert, um diese neue Anweisung zu unterstützen. Zum Beispiel erfolgt das Prüfen, ob die Hardware die Anweisung unterstützt, durch das Lesen (z.B. CPUID) (eines) von Merkmalsbits, um zu bestimmen, ob die Hardware diese neue Anweisung unterstützt. In einer Ausführungsform soll die Software diese neue Anweisung nur dann verwenden, wenn sie durch die Hardware unterstützt wird, wie durch ihr Spezifizierungsverfahren angegeben wird.
In einer Ausführungsform eines Prozessors erfolgt die Ausführung auf spekulative Weise. Um einen spekulativen Verlaufs-Reset zu vermeiden, ist es möglich, dass, während die Anweisung (z.B. HRESET) für einen Verlaufs-Reset ausgeführt wird (z.B. während sämtliche Prüfungen zum Zurücksetzen des Verlaufs stattgefunden haben, jedoch bevor der Verlaufs-Reset selbst stattgefunden hat), eine Handlung als eine vorserialisierte Handlungsanweisung vorgenommen wird, wobei z.B. alle vorherigen (in Programmreihenfolge) Anweisungen lokal abgeschlossen wurden, bevor der Verlaufs-Reset erfolgt. In einer Ausführungsform wird HRESET verwendet, um ein Verlaufsleck zu vermeiden, z.B. in einem Kern, der Anweisungen außerhalb der Programmreihenfolge ausführt. Eine weitere mögliche Unterstützungsoption ist das Freigeben einer Vorserialisierungsanweisung zum Unterstützen lediglich einer Teilmenge der Verlaufs-Reset-Arten, die durch das spekulative Ausführungsverfahren des Prozessors beeinträchtigt werden können. Bei noch einer weiteren Option wird die Anweisung als serialisiert unterstützt. Es ist auch möglich, die Unterstützung als eine serialisierte Anweisung nur für spezifische HRESET-Fähigkeiten zu definieren, und nur wenn diese HRESET-Fähigkeiten zur Verwendung freigegeben sind. Zum Beispiel können Optionen zum Auswählen eines Unterstützungsverfahrens für eine vorserialisierte Anweisung oder eines Unterstützungsverfahrens für eine serialisierte Anweisung für eine angemessene Teilmenge von Verlaufs-Reset-Arten verwendet werden, um jegliche negative Leistungsnebenwirkung der Unterstützung für die vorserialisierte oder die serialisierte Anweisung zu begrenzen, indem z.B. alle vorherigen (z.B. in Programmreihenfolge) Anweisungen lokal abgeschlossen wurden, bevor der Verlaufs-Reset durchgeführt wird.
In einer Ausführungsform weist eine neue Reset-Anweisung (z.B. HRESET) ein modellspezifisches Register (MSR) auf (das z.B. durch das BS verwendet wird), um unterschiedliche Unterstützungsmerkmale freizugeben. In einer Ausführungsform sind, als eine Voreinstellung, sämtliche der Unterstützungsmerkmale deaktiviert. In einer Ausführungsform soll das BS eine Teilmenge oder alle der Unterstützungsmerkmale freigeben. In einer Ausführungsform wird nur die untere (z.B. 32) angemessene Teilmenge von Bits für die HRESET-Nutzung zugeteilt. Eine Beispieldefinition dieses MSR ist in 3 gezeigt.
3 veranschaulicht ein Beispielformat 300 eines modellspezifischen Registers für einen prozessorinternen Verlaufs-Reset gemäß Ausführungsformen der Offenbarung. Das abgebildete Format enthält ein erstes Bit (z.B. Bitposition Null) für ein Freigabe-Bit 302 (z.B. derart, dass das Setzen des Bits 302 auf einen ersten Wert (z.B. Eins) die Reset-Funktionalität einschaltet und das Setzen des Bits 302 auf einen zweiten Wert (z.B. Null) die Reset-Funktionalität ausschaltet). In einer Ausführungsform erfolgt der Reset für Software-Thread-Laufzeiteigenschaft-Verläufe z.B. nur für eine Reset-Anfrage, die im Supervisor-Modus gestellt wird. Die anderen Bits 304 können zum Angeben anderer Fähigkeiten der Anweisung verwendet werden. Wahlweise kann der Verlauf anderer Komponenten gelöscht werden, z.B. wie durch das Setzen eines entsprechenden Bits in den anderen Bits 304 angegeben (z.B. die Bits 63:1 für den 64-Bit-Modus bzw. die Bits 31:1 für den 32-Bit-Modus).
In einer Ausführungsform ist das MSR IA32_HRESET_ENABLE ein Lese-/Schreib-MSR und ist wie Folgt strukturiert: Bit 0 - Gibt einen Reset des EHFI (Enhanced Hardware Feedback Interface) -Verlaufs (z.B. ein akkumulierter Verlauf) (z.B. HGS oder HGS plus) frei, wenn es auf Eins gesetzt ist, Bits 31:1 - Reserviert für andere Fähigkeiten, die durch die Anweisung HRESET zurückgesetzt werden können, und (optional) Bits 63:32 - Reserviert. In einer Ausführungsform stellt ein Betriebssystem IA32_HRESET_ENABLE[Bit 0] über die Anweisung HRESET auf „EHFI-Verlaufs-Reset freigegeben‟ ein.
In einer Ausführungsform soll die Anweisung, um es einer Anweisung HRESET zu ermöglichen, die vorserialisierte Unterstützung (z.B. nur) einzuschalten, wenn alle der Bedingungen für den Verlaufs-Reset eingetreten sind, anfordern, dass ein Schreibvorgang des MSR (z.B. IA32_HRESET_ENABLE) abgeschlossen wird, bevor jeglicher Spekulationsteil der Anweisung HRESET ausgeführt werden kann. In einer Ausführungsform ist, um dies zu ermöglichen, eine WRMSR (z.B. Mikrocode) -Operation (z.B. zum Schreiben in das MSR) einer Anweisung (z.B. IA32_HRESET) als eine serialisierte Operation definiert.
In bestimmten Ausführungsformen ermöglicht die neue Anweisung (z.B. HRESET) einem BS das Zurücksetzen des Verlaufs eines Hardware-Guide-Schedulers (HGS oder HGS plus) aufgrund der Ausführung der Anweisung. Die Liste der Fähigkeiten kann um weitere Optionen erweitert werden, wie das Neueinstellen anderer Caching-Informationen in dem Kern (oder in dem Nicht-Kern), die sich auf den logischen Prozessor oder den Kernausführungsverlauf beziehen, oder das Markieren eines Kontextumschaltungsereignisses zwischen zwei Software-Threads, derart, dass die Markierung durch die Hardware verwendet werden kann, usw.
Ein Prozessor kann die Unterstützung der Anweisung HRESET, das Steuer-MSR (z.B. IA32_HRESET_ENABLE) (z.B. im Format 300 in 2) und die möglichen Steuerfähigkeiten für die Unterstützung des HRESET durch CPUID-Bits spezifizieren. In einer Ausführungsform sendet die Ausführung einer CPUID-Anweisung Prozessor (z.B. CPU) -Identifikationsdaten und Merkmalsinformationen an bestimmte Register (z.B. die Register EAX, EBX, ECX und EDX) zurück. In einer Ausführungsform werden die Unterstützung der Anweisung HRESET und das Steuer-MSR durch das Prüfen des Merkmalsunterstützungsbits, CPUID [0×7, ECX=1].EAX[22], angegeben. Die Spezifizierung der Unterstützungsfähigkeiten von HRESET und eine mögliche gültige Einstellung im Steuer-MSR kann durch die Zuordnung in einem 32-Bit-Register (z.B. einem Universalregister) erfolgen, z.B. in einem spezifischen CPUID-Blatt. Die 32 Bits können Folgende sein: CPUID[0×20,ECX=0].EBX[31:0].

Ein mögliches Format der CPUID kann wie unten in Tabelle 1 gezeigt sein. Tabelle 1: Beispiel-CPUID-Bits

CPUID-Bits	Beschreibung
CPUID[0x7, ECX=1].EAX[22]	Gibt an, dass MSR und Anweisung HRESET (z.B. CPUID-Blatt 0x20) unterstützt werden
CPUID[0×20, ECX=0].EBX[0]	Gibt die Unterstützung des Parameters HRESET EAX[0] und des MSR HRESET_ENABLE[0] zum Freigeben eines Resets des HGS oder zum Freigeben eines Resets des HGS und eines anderen Verlaufs „HGS PLUS“ an
CPUID[0x20, ECX=0].EBX[31:1]	Reserviert für HRESET EAX[31: 1]- und A32_HRESET_ENABLE[31:1]-Fähigkeiten

Falls eine Ausführungsform einer Anweisung HRESET durch zwei unterschiedliche Benutzer (z.B. Unternehmen) verwendet wird, besteht die Möglichkeit, dass jeder Benutzer seine Version des Steuer-MSR definiert, die unterschiedliche Arten von Fähigkeiten pro Benutzer freigibt, wobei in diesem Fall die Spezifizierung entweder durch eine spezifische Zuordnung eines CPUID-Blattes oder -Unterblattes pro Unternehmen erfolgt. Eine weitere Option kann die gemeinsame Nutzung des gleichen Steuer- und Spezifizierungs-MSR oder CPUID-Blattes oder -Unterblattes sein.
In bestimmten Implementierungen, die durch einen neuen Opcode unterstützt werden, ist es auch möglich zu prüfen, dass die Software einen gültigen Wert im HRESET-Steuerparameter (z.B. im Register EAX) eingestellt hat. Somit kann es wünschenswert sein zu bestätigen, dass die Einstellung der Steuerparameter (z.B. im Register EAX) mit der (den) Einstellung(en) übereinstimmt, die durch das BS im Einverständnis-MSR (z.B. IA32_HRESET_ENABLE) vorgenommen wurde(n). Falls eines der Steuerbits im Steuerparameter (z.B. gespeichert im Register EAX) nicht mit dem entsprechenden Bit übereinstimmt, das im MSR eingestellt ist (z.B. IA32 _HRESET_ENABLE), wird in bestimmten Ausführungsformen eine Ausnahme erzeugt (z.B. eine allgemeine Schutzausnahme). In einer Ausführungsform wird, wenn die Software keinerlei Verlaufs-Reset-Fähigkeiten durch den Anweisungsparameter (z.B. EAX) freigibt, die Anweisung HRESET durch die Hardware als eine Nulloperation (NOP) ausgeführt, z.B. mit oder ohne einige zusätzliche Ausführungslatenz gegenüber einer regulären NOP.
In einer Ausführungsform ist der Pseudocode zum Initialisieren eines (z.B. 32-Bit-Modus) HRESET-MSR (z.B. IA32_HRESET_ENABLE) Folgender:

Wenn (CPUID[HRESET]) {

 OS_HRESET_CAP = CPUID[HRESET_CAP]
 WRMSR IA32HRESET ENABLE, HRESET_CAP }

Die Einstellung des IA32_HRESET_ENABLE-Wertes kann eine Teilmenge der CPUID[HRESET_CAP]-Bits sein.

In einer Ausführungsform ist der Pseudocode für die Ausführung einer Anweisung HRESET zum Zurücksetzen der Software-Thread-Laufzeiteigenschaft-Verläufe nur wenn CPL=Null (Ring 0) Folgender:


 UNDEFINED (#UD), wenn HRESET nicht unterstützt wird (CPUID[7,
 ECX=1].EAX[22] ==0)
 GENERAL PROTECTION FAULT (#GP(0)), wenn CPL>0 oder ((EAX und NOT
 IA32_HRESET_ENABLE)!= 0)
 WENN EAX = 0
      DANN NOP 



      SONST
      FÜR JEDES i derart, dass EAX[i]
             Zurücksetzen des Verlaufs für Merkmal i

In einer Ausführungsform vermeidet eine Implementierung der Ausführung einer Anweisung HRESET eine spekulative Ausführung, während die Reset-Operation stattfindet, indem vorserialisierte Unterstützung ermöglicht wird. In einer dieser Ausführungsformen ist der Pseudocode für die Ausführung einer Anweisung HRESET Folgender:


 WENN EAX = 0
      DANN NOP
      SONST // keine spekulative Ausführung des Untenstehenden
      FÜR JEDES i derart, dass EAX[i]
             Zurücksetzen des Verlaufs für Merkmal i

In einer Ausführungsform, wenn der Operand EAX = 0, ist die versuchte Ausführung von HRESET in Ring 0 eine NOP. In einer Ausführungsform, wenn Operand EAX = 0 und IA32_HRESET_ENABLE == 0, ist die versuchte Ausführung von HRESET in Ring 0 eine NOP (z.B. wie zur Ausführung durch ein BS, einen VMM oder ein VM-BS angefordert).

In bestimmten Ausführungsformen modifiziert die Ausführung der Anweisung keinerlei Architekturzustand (Register, Arbeitsspeicher, Flags usw.) außer den Software-Thread-Laufzeiteigenschaft-Verläufen (z.B. innerhalb eines Hardware-Guide-Schedulers), die durch die Ausführung einer Anweisung HRESET zurückgesetzt werden.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) ein oder mehrere Felder gemäß dem folgenden Format auf:

Opcode/ Anweisung	Operanden - Codierung (Op/En)	64/32-Bit-Modus-Unterstützung	CPUID-Merkmals-Flag	Beschreibung
F3 0F 3A F0C0 /ib HRESET imm8, <EAX>	A (siehe unten)	Ja (V) / Ja (V)	HRESET	Anfrage für Prozessorverlaufs-
				Reset. Gesteuert durch den impliziten Operanden EAX.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) ein oder mehrere Felder gemäß der folgenden Operanden-Codierung „A“ auf:

Op/En	Tupel	Operand 1	Operand 2	Operand 3	Operand 4
A	Nicht zutreffend	ModRM:r/m (r)	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) folgende Beschreibung auf. Die Ausführung bestimmter Ausführungsformen einer Verlaufs-Reset-Anweisung (HRESET) stellt dem Prozessor einen Hinweis zur Verfügung, um den Vorhersageverlauf des aktuellen logischen Prozessors selektiv zurückzusetzen. In bestimmten Ausführungsformen wird die HRESET-Operation z.B. durch den impliziten Operanden EAX gesteuert und der Wert des expliziten direkten Operanden (z.B. acht Bit breit, „imm8“) wird ignoriert. In bestimmten Ausführungsformen gibt CPUID.07H.01H:EAX.HRESET[Bit 22] die Unterstützung für eine Anweisung HRESET an. In bestimmten Ausführungsformen kann diese Anweisung nur bei einer CPL von Null ausgeführt werden. In bestimmten Ausführungsformen ist eine Anweisung HRESET in der Lage, einen Reset-Hinweis für mehrere Vorhersagen bereitzustellen.

In bestimmten Ausführungsformen muss die Systemsoftware, vor der Ausführung einer Anweisung HRESET, folgende Schritte durchführen:

1. Spezifizieren der HRESET-Fähigkeiten über CPUID.20H.0H:EBX, wodurch angegeben wird, welche Vorhersagen zurückgesetzt werden können, und
2. Einverständnis zum Zurücksetzen einer Teilmenge der verfügbaren Fähigkeiten durch das Einstellen der entsprechenden Bits im MSR IA32_HRESET_ENABLE. Zum Beispiel werden die Einverständnis-Bits im MSR IA32_HRESET_ENABLE in Einklang mit den CPUID-Bits der HRESET-Fähigkeiten gebracht.

In bestimmten Ausführungsformen muss der implizite Operand EAX gesetzte Bits enthalten, bei welchen es sich um eine Teilmenge derjenigen handelt, die z.B. im MSR IA32_HRESET_ENABLE MSR gesetzt sind, ansonsten erzeugt HRESET #GP(0). In bestimmten Ausführungsformen, wenn EAX=0, wird eine Anweisung HRESET als eine NOP interpretiert. In bestimmten Ausführungsformen resultiert jeglicher Versuch, eine Anweisung HRESET innerhalb einer Transaktionsregion auszuführen, in einem Transaktionsabbruch.
In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) die folgende Operation auf:

      WENN EAX = 0
             DANN NOP
             SONST
             FÜR JEDES i derart, dass EAX[i] = 1
                   Zurücksetzen des Vorhersageverlaufs für Merkmal i
      FI //z.B. Schließen der WENN-Anweisung

In bestimmten Ausführungsformen hat eine Verlaufs-Reset-Anweisung (HRESET) keinen Einfluss auf jegliche Flags eines Prozessors.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) eine oder mehrere der folgenden geschützten Modus-Ausnahmen auf:

#GP(0) Wenn CPL > 0 oder (EAX und NOT IA32HRESET ENABLE)   0.
 #UD Wenn CPUID.07H.01H:EAX.HRESET[Bit 22] = 0.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) Realadressmodus-Ausnahmen auf, bei welchen es sich um die gleichen wie die geschützte(n) Modus-Ausnahme(n) oben handelt.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) die folgende Virtuell-8086-Modus-Ausnahme auf: #GP(0) Die Anweisung HRESET wird im Virtuell-8086-Modus nicht erkannt.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) Kompatibilitätsmodus-Ausnahmen auf, bei welchen es sich um die gleichen wie die geschützte(n) Modus-Ausnahme(n) oben handelt.

In bestimmten Ausführungsformen weist eine Verlaufs-Reset-Anweisung (HRESET) 64-Bit-Modus-Ausnahmen auf, bei welchen es sich um die gleichen wie die geschützte(n) Modus-Ausnahme(n) oben handelt.

In bestimmten Ausführungsformen verursacht die Ausführung einer CPUID-Anweisung (z.B., wenn das Register EAX einen Anfangswert von 07H aufweist und das Register ECX einen Anfangswert von 1 aufweist) eine Ausgabe, bei welcher das Bit mit einer Indexposition 22 in EAX für den HRESET steht, wenn es z.B. Eins ist, wodurch angegeben wird, dass der (z.B. logische) Prozessor den Verlaufs-Reset (HRESET) und das MSR IA32HRESET _ENABLE unterstützt und/oder dass das Prozessorverlaufs-Reset-Blatt (z.B. EAX = 20H) gültig ist. In bestimmten Ausführungsformen (z.B. bei einem Prozessorverlaufs-Reset-Unterblatt) verursacht die Ausführung einer CPUID-Anweisung (z.B., wenn das Register EAX einen Anfangswert von 20H aufweist und das Register ECX einen Anfangswert von 0 aufweist) eine Ausgabe, bei welcher die Register Folgendes tun: EAX meldet die maximale Zahl von Unterblättern, die im Blatt 20H unterstützt werden, EBX gibt an, welche Bits im MSR IA32_HRESET_ENABLE gesetzt sein können, um einen EHFI (Enhanced Hardware Feedback Interface) -Verlauf freizugeben, und ECX und EDX sind reserviert.

In bestimmten Ausführungsformen setzt die Ausführung einer Anweisung HRESET explizit einen EHFI-Verlauf zurück.

In bestimmten Ausführungsformen gibt es einen impliziten EHFI-Verlaufs-Reset (z.B. anstelle eines Resets als Reaktion auf die Ausführung einer Anweisung HRESET).

In bestimmten Ausführungsformen wird der EHFI-Verlauf in jeglichen der folgenden Szenarien implizit zurückgesetzt:

1. Wenn der Prozessor in den SMM-Modus schaltet oder diesen verlässt und IA32_DEBUGCTL MSR.FREEZE_WHILE_SMM (Bit 14) gesetzt ist, wird der EHFI-Verlauf implizit durch den Prozessor zurückgesetzt.
2. Wenn GetSec[SENTER] ausgegeben wird (z.B. zum Initiieren der Einführung einer gemessenen Umgebung und zum Platzieren des initiierenden logischen Prozessors (ILP - Initiating Logical Processor) in einen authentifizierten Codeausführungsmodus), setzt der Prozessor den EHFI-Verlauf auf allen logischen Prozessoren im System zurück, einschließlich logischer Prozessoren an anderen Anschlüssen (außer dem, auf dem GetSec(SENTER) ausgeführt wird).
3. Wenn GetSec[ENTERACCS] ausgegeben wird, setzt der Prozessor den EHFI-Verlauf auf dem logischen Prozessor zurück, auf dem er ausgeführt wird.
4. Wenn INIT oder SIPI (Wait for Startup Inter Processor Interrupt) -Signale durch einen logischen Prozessor verarbeitet werden, wird der EHFI-Verlauf zurückgesetzt, egal ob das Signal ein Ergebnis von GetSec[ENTERACCS] war oder nicht.

In bestimmten Ausführungsformen sollte, wenn das Betriebssystem es erfordert, dass die EHFI aktiv ist, nachdem die gemessene Umgebung verlassen wurde oder wenn ein SIPI-Ereignis verarbeitet wird, dieses die EHFI reaktivieren.

4 veranschaulicht ein Betriebssystem (BS) -Scheduler-Steuerflussdiagramm (z.B. Assemblercode) 400 gemäß Ausführungsformen der Offenbarung. Dieses beinhaltet zum Beispiel das Beenden der aktuellen Thread-Ausführung (z.B., und das Speichern des aktuellen Thread-Kontextes) bei 402, wenn (CPUID.HRESET == 1) {MOV EAX, BS-Unterstützung für Verlaufs-Reset-Optionen und Ausführung von HRESET} bei 404 und das Wiederherstellen/Initialisieren einer neuen Thread-Ausführung (z.B., und das Wiederherstellen/Initialisieren des neuen Thread-Kontextes) bei 406. HRESET kann einen direkten Wert (z.B. imm8) als einen Operanden aufweisen. In einer Ausführungsform wird CPUID.HRESET == 1 durch das Setzen von CPUID.07H.01H:EAX.HRESET[Bit 22] == 1 implementiert.

5 veranschaulicht ein Anwendungsebenen-Steuerflussdiagramm (z.B. Assemblercode) 500 gemäß Ausführungsformen der Offenbarung. Dieses beinhaltet zum Beispiel, dass ein BS-Scheduler das Thread-Laufzeitmanagement zum Beenden einer Software (S/W) -Aufgabe verwendet bei 502, wenn (CPUID.HRESET == 1) {MOV EAX, BS-Unterstützung für Verlaufs-Reset-Optionen und Ausführung von HRESET} bei 504, und dass ein BS-Scheduler das Thread-Laufzeitmanagement zum Wiederherstellen/Initialisieren einer neuen S/W-Aufgabe verwendet bei 506

6 veranschaulicht ein Betriebssystem (BS) -Reset-Flussdiagramm (z.B. Assemblercode) 600 gemäß Ausführungsformen der Offenbarung. Dieses beinhaltet zum Beispiel das Prüfen, ob CPUID.HRESET == 1 bei 602, das Durchführen von SUPPORT _CAP=CPUID[Y].HRESET_CAP bei 604 und das Schreiben von SUPPORT CAP und OS SUPPORT MASK in das MSR HRESET bei 606. In einer Ausführungsform ist CPUID[Y].HRESET_CAP CPUID[0x20, ECX=0].EBX[31:0].

7 veranschaulicht ein Betriebssystem (BS) -Scheduler-Flussdiagramm (z.B. Assemblercode) 700 gemäß Ausführungsformen der Offenbarung. Dieses beinhaltet zum Beispiel

das Beenden der aktuellen Thread-Ausführung und das Sichern des aktuellen Thread-Kontextes bei 702, wenn (CPUID.HRESET == 1) {MOV EAX, BS-Unterstützung für Verlaufs-Reset-Optionen und Ausführung von HRESET} bei 704 und das Wiederherstellen/Initialisieren einer neuen Thread-Ausführung und das Wiederherstellen/Initialisieren des neuen Thread-Kontextes bei 706.

In einer Ausführungsform nutzt das BS den HRESET-Steuerparameter in einem Register (z.B. EAX) zum Steuern während der Laufzeit, welcher der exakte Verlaufs-Reset-Typ sein soll (z.B. die Fähigkeiten der Anweisung). In bestimmten Ausführungsformen ist das Verwenden des Anweisungsparameters ein einfacheres Verfahren gegenüber dem Einstellen eines MSR während der Laufzeit. In bestimmten Ausführungsformen ermöglicht dies dem BS, den Verlauf (und z.B. eine angemessene Teilmenge von Verlaufsarten) pro Software-Thread-Typ zurückzusetzen (z.B. ein erster Thread-Typ für eine erste Anwendung und ein zweiter Thread-Typ für eine zweite Anwendung).

In bestimmten Ausführungsformen kann das BS den Prozessorverlauf auch während der Laufzeit des Software-Threads zurücksetzen (und nicht nur während einer Kontextumschaltung).

In bestimmten Ausführungsformen nimmt das Nutzungsmodell einer Anweisung HRESET an, dass, im Anschluss an die Ausführung der Anweisung HRESET, die Verläufe, die zurückgesetzt wurden, keine Auswirkung auf jegliche Operation haben, die im Anschluss an dieses Ereignis erfolgt (z.B. nach der Ausführung der Anweisung HRESET), zum Beispiel kann selbst bei einem Prozessor, der nicht-sequentielle und spekulative Ausführung unterstützt, die Annahme sein, dass die Ordnungsregel für Ereignisse beibehalten wird. Zum Beispiel ermöglicht die Hardware, als Teil des Hardware-Guide-Schedulers, dem MSR, eine Rückmeldung basierend auf dem Laufzeitverlauf an das BS zurückzusenden (um z.B. einen Hinweis bereitzustellen), bevor dieses MSR gelesen wird.

Bezüglich des Flusses unten, verursacht die Ausführung der Anweisung HRESET einen Reset des Hardware-Guide-Schedulers (HGS) (z.B. HGS PLUS) // garantiert, dass der HGS (zum Beispiel plus jeglichem anderen Verlauf, der zurückzusetzen ist, wie durch die Fähigkeiten angegeben, z.B. kumulativ als HGS PLUS bezeichnet) vor dieser Anweisung HRESET nicht mehr für jegliche darauffolgenden Lesevorgänge des MSR sichtbar ist (z.B. RDMSR und/oder ein Thread-Feedback-MSR (z.B. MSR IA32_THREAD_FEEDBACK_CHAR)), um die Hinweise zu erhalten (z.B. wie oben unter Bezugnahme auf 2 diskutiert). In bestimmten Ausführungsformen erfolgt dies unter der Annahme, dass das Lesen der Rückmeldung unterstützt wird (wie z.B. auch die Vorserialisierung) und/oder dass der RDMSR auch als ISA für Vorserialisierung oder vollständige Serialisierung definiert ist, damit er z.B. durch die Hardware geschützt ist, auf welcher der RDMSR ausgeführt werden wird, nachdem der HRESET seinen Ausführungsfluss abgeschlossen hat. In bestimmten Ausführungsformen soll ein Prozessor eine Anweisung HRESET nicht spekulativ ausführen, um z.B. ein Wiederfüllen der Verläufe (z.B. im HGS) zu vermeiden, nachdem der Prozessor annimmt, dass die Verläufe gelöscht wurden.

Eine Beispielunterstützung dafür ist im Fluss unten gezeigt:

HRESET [HGS_RESET] // garantiert, dass der Verlauf des HGS (z.B. HGS PLUS) vor der Anweisung HRESET nicht für jegliche nachfolgende (z.B. RDMSR) HGS (z.B. HGS PLUS) -Verlaufsrückmeldung zur Verwendung durch ein BS sichtbar ist, z.B. aufgrund eines Unterstützungsmodells für Vorserialisierung einer Ausführungsform des HRESET.
RDMSR-Verlaufsrückmeldung // Annahme einer Vorserialisierung dieses MSR-Lesevorgangs (wobei dieses MSR z.B. einen Hinweis aufweist, der einen Kerntyp basierend auf dem HGS (z.B. HGS PLUS) -Verlauf angibt).

Dieser Fluss kann zum Erstellen einer Serialisierung zwischen der Ausführung einer Anweisung HRESET, welche den Verlauf des HGS zurücksetzt, und vor dem Lesen des HGS (z.B. HGS PLUS) -Verlaufs (z.B. über ein MSR) als Rückmeldung an das BS verwendet werden.

In bestimmten Ausführungsformen stellt der Anweisungsfluss, zum Vermeiden einer spekulativen Ausführung dieser Anweisung, bevor das Verlaufs-Reset tatsächlich ausgeführt wird, nur während die Bedingungen für den Verlaufs-Reset erfüllt sind, sicher, dass keine spekulative Ausführung stattfindet. In einer Ausführungsform ist es für ein spezifisches HRESET-Unterstützungsmerkmal möglich, eine starke Ordnungsunterstützung, wie eine vollständig serialisierte Anweisung, hinzuzufügen. In einer Ausführungsform ist es möglich, die HRESET-Unterstützung mit einer vollständig serialisierten Anweisung zu definieren, oder nur wenn die Bedingungen für den Verlaufs-Reset erfüllt sind. In bestimmten Ausführungsformen gibt es, falls diese Bedingungen nicht erfüllt sind (und keine Ausnahme aufgrund einer falschen Einstellung/Nutzung erzeugt wurde), keine Nebenwirkung einer möglichen spekulativen Ausführung dieser Anweisung, während sie als eine NOP ausgeführt wird. In bestimmten Ausführungsformen vermeidet eine Anweisung die Serialisierung z.B. nur, wenn sie dafür eingestellt ist, als eine NOP ausgeführt zu werden; falls ein/eines der Fähigkeitsbit(s) im EAX-Operanden gesetzt ist, wird diese Anweisung ausgeführt, während die Vorserialisierung aktiviert ist.

8A - 8D veranschaulichen Flussdiagramme für BS- und VMM-(Virtual Machine Monitor) Unterstützungsmodelle gemäß Ausführungsformen der Offenbarung.

In bestimmten Ausführungsformen ist ein VMM (Virtual Machine Monitor) (auch bekannt als ein Hypervisor) ein Softwareprogramm, das, wenn es ausgeführt wird (z.B. im Supervisor-Modus, jedoch nicht im Benutzermodus), die Erstellung, das Management und die Steuerung vom VM-Instanzen ermöglicht und den Betrieb einer virtualisierten Umgebung auf einer physischen Host-Maschine managt. In bestimmten Ausführungsformen ist ein VMM die primäre Software hinter Virtualisierungsumgebungen und -implementierungen. Wenn ein VMM in bestimmten Ausführungsformen über einer Host-Maschine (z.B. einem Prozessor) installiert ist, erleichtert er die Erstellung von VMs (z.B. VM-Einführung), zum Beispiel jeweils mit separaten Betriebssystemen (BS) und Anwendungen. Der VMM kann den Backend-Betrieb dieser VMs managen, indem er die notwendigen Rechen-, Arbeitsspeicher-, Speicher- und andere Eingabe/Ausgabe (E/A) - Ressourcen zuteilt, wie z.B., jedoch nicht darauf beschränkt, eine Eingabe/Ausgabe-Arbeitsspeichermanagementeinheit (IOMMU - Input/Output Memory Management Unit). Der VMM kann eine zentralisierte Schnittstelle zum Managen des gesamten Betriebs, des Status und der Verfügbarkeit von VMs bereitstellen, die über einer einzelnen Host-Maschine installiert sind oder über unterschiedliche und miteinander verbundene Hosts hinweg verteilt sind. In bestimmten Ausführungsformen erfordert das Umschalten zwischen VMs (z.B. VM-Eintritt, VM-Wiederherstellung und/oder VM-Austritt) eine Umschaltung des Prozessorkerns in einen Supervisor-Modus (z.B. anstatt in einem Benutzermodus zu bleiben).

8A veranschaulicht das Flussdiagramm eines Unterstützungsmodells ,BS' gemäß Ausführungsformen der Offenbarung. Dieses beinhaltet zum Beispiel ein mögliches Nutzungsmodell „BS-HRESET‟ 801, bei welchem (1) das BS während der BS-Startzeit prüft, ob HRESET unterstützt wird, indem die funktionalen CPUID-Bits CPUID[7,1][22] spezifiziert werden, um (i) die HRESET-Fähigkeiten über CPUID[0x20, ECX=0].EBX[31:0] zu spezifizieren, welche angeben, welche Vorhersagen zurückgesetzt werden können, und um (ii) das Einverständnis zum Zurücksetzen einer Teilmenge der verfügbaren Fähigkeiten durch das Setzen der entsprechenden Bits im MSR IA32_HRESET_ENABLE zu geben. Dafür werden zum Beispiel die Einverständnis-Bits im MSR IA32HRESET_ENABLE in Einklang mit den CPUID-Bits der HRESET-Fähigkeiten gebracht (Übereinstimmung 1 zu 1), und (2) während einer S/W-Thread-Kontextumschaltung sollte das BS den H/W-Verlauf des aktuellen S/W-Threads löschen, bevor der neue S/W-Thread seine Laufzeit startet, um (i) die Ziel-Reset-Merkmale durch den EAX-Operanden des HRESET einzustellen, wobei (ii) der EAX-Operand des HRESET gesetzte Bits enthalten soll, bei welchen es sich um eine Teilmenge von denen handelt, die im MSR IA32_HRESET_ENABLE gesetzt sind (ansonsten erzeugt HRESET z.B. #GP(0)), und um (iii) die EAX-ISA des HRESET auszuführen.

Als Teil der Virtualisierung kann der VMM in einem Modell nicht verhindern, dass Gastsoftware einen HRESET ausführt, und der HRESET kann keinen VM-Austritt verursachen und weist keine entsprechende VM-Ausführungssteuerung auf.

In einer Ausführungsform kann der VMM steuern, welche Bits in HRESET_ENABLE (z.B. ein MSR im Format 300 in 3) (z.B. IA32_HRESET_ENABLE) gesetzt werden, indem ein Gastschreibvorgang (WRMSR) in das MSR und ein Gastlesevorgang (RDMSR) aus diesem MSR abgefangen werden. In einer Ausführungsform kann der VMM über die Merkmale entscheiden, für welche er gestattet, dass ein Gast den Verlauf zurücksetzt. In einer Ausführungsform kann der VMM durch Virtualisierung die CPUID-Bits derjenigen Merkmale steuern, die zur Gastunterstützung gültig sein werden. In einer Ausführungsform emuliert der VMM das MSR HRESET_ENABLE, um nur diejenigen Bits freizugeben, die durch den Gast gesetzt werden dürfen. In einer Ausführungsform behält der VMM das MSR mit dem Wert bei, der durch das Gast-BS erwartet wird. In diesem Modell kann der Gast, wenn der VMM jegliche Einstellung in HRESET_ENABLE vermeidet, eine Anweisung HRESET lediglich als NOP ausführen.

Die Virtualisierungsunterstützung kann eines oder mehrere der folgenden drei Nutzungsmodelle verwenden:

In einem Modell (z.B. Modell 802, wie in 8B gezeigt) hat der VMM z.B. keine Kenntnis von der Unterstützung für die Anweisung HRESET; wenn der VMM keine Kenntnis über diese neue Anweisung hat, spezifiziert er sie nicht und gibt sie nicht für seinen BS-VM-Gast frei. Dann ist zum Beispiel das neue CPUID-Merkmalsbit dieser Anweisung nicht für den VM-Guest unter diesem VMM freigegeben. In einer Ausführungsform dieses Falls ist der BS-Gast nicht in der Lage, die Unterstützung dieser neuen Anweisung zu spezifizieren, und das BS sollte sie nicht verwenden. Aufgrund dessen stellt der VMM die Fähigkeiten im MSR IA32_HRESET_ENABLE nicht selbst ein, und weil das Gast-BS nicht in der Lage ist, das Steuer-MSR selbst einzustellen (z.B. virtualisiert der VMM diese(s) MSR(s) nicht für eine VM-BS-Nutzung), bleibt dieses MSR aufgrund dessen in bestimmten Ausführungsformen leer. In bestimmten Ausführungsformen dieses Modells ist das VM-BS (Gast) nicht in der Lage, die Unterstützung der Anweisung HRESET zu spezifizieren (weil der VMM diese nicht freigibt), und die Erwartung ist, dass das VM-BS (Gast) die Anweisung HRESET nicht freigeben und verwenden wird, wenn das VM-BS die Ausführung dieser neuen Anweisung anfordert; in einem Modell (z.B., wenn dieser Anweisungsparameter im Register EAX leer ist) wird der HRESET als eine NOP ausgeführt. Wenn EAX nicht leer ist, resultiert die Ausführung dieser neuen Anweisung in der Ausnahme ALLGEMEINER SCHUTZFEHLER (GENERAL PROTECTION FAULT).

In einer Ausführungsform (z.B. in 8B gezeigt), weist das Nutzungsmodell „VMM Möglich‟ Folgendes auf: (1) während der VMM-Startzeit gibt der VMM die HRESET-Unterstützung nicht frei, anschließend gibt der VMM die Unterstützung für HGS+ nicht frei, (2) Vermeiden des Virtualisierens des HRESET CPUID-Funktionsbits, Vermeiden des Virtualisierens der HRESET CPUID-Fähigkeitsbits und des MSR IA32_HRESET_ENABLE und Vermeiden der Virtualisierung der HGS+ CPUID-Bits und des MSR HGS+, Aktivieren der VM-Nutzung, wenn HRESET und seine Teilmenge oder alle Fähigkeitsbits unterstützt werden, und/oder BS als VM des HRESET ist nur möglich, während sein impliziter Operand EAX == 0, in diesem Fall wird er als NOP ausgeführt, und wenn EAX=!0, erzeugt die Ausführung von HRESET #GP.

In einem weiteren Modell (z.B. Modell 803, wie in 8C gezeigt), hat der VMM Kenntnis von der HRESET-Anweisungsunterstützung, vermeidet jedoch die Nutzung dieser neuen Anweisung durch sein Gast-BS, z.B. falls der VMM Kenntnis von der Anweisung HRESET hat und sie für seine Nutzung freigibt, bedeutet dies, dass der VMM Spezifizierungsunterstützung des HRESET als Merkmal und seine Fähigkeiten aufweist, genauso wie beim regulären BS (z.B. kein VM-BS). In einer Ausführungsform weist der VMM auch die Nutzung des HRESET als Teil seines Scheduler-Unterstützungsflusses oder im Thread-Laufzeitmanagement eines anderen VMM auf und verwendet diese Anweisung nur, wenn die Hardware sie unterstützt. In einer Ausführungsform kann der VMM den HRESET verwenden, falls der VMM seinen eigenen Verlauf zurücksetzen sollte, und um die Möglichkeit zu vermeiden, dass eine VM (z.B. ein Gast) direkten oder indirekten Zugriff auf diesen Verlauf haben kann.

In einer Ausführungsform soll der VMM dem Satz von HRESET-Verlaufs-Reset-Fähigkeiten zustimmen. In einer Ausführungsform soll der VMM das (die) Fähigkeitsbit(s) im HRESET EAX-Parameter setzen, die auch im Einverständnis-MSR IA32_HRESET_ENABLE gesetzt wurden. In diesem Nutzungsfall vermeidet der VMM die Verwendung des MSR HRESET durch seinen Gast. In einer Ausführungsform emuliert der VMM die CPUID und vermeidet die Option zum Spezifizieren der Unterstützung von HRESET und seiner Fähigkeiten durch den VM-BS-Gast. In einer Ausführungsform vermeidet der VMM die Option zum Zugreifen auf IA32_HRESET_ENABLE durch den VM-BS-Gast. In einer Ausführungsform soll ein VMM, bevor er den VM-BS-Gast wiederherstellt, IA32_HRESET_ENABLE freihalten. In einer Ausführungsform liegt es, während des Austretens der virtuellen Maschine (VMEXIT) und vor der Ausführung des Threads eines VMM, beim VMM, seinen Einstellwert in IA32_HRESET_ENABLE wiederherzustellen. In bestimmten Ausführungsformen ist es, wenn der VM-BS-Gast keine Zugriffsoption hat oder nicht durch den (z.B. HGS oder HGS plus) Verlauf beeinträchtigt wird, der während der VMM-Laufzeit angesammelt wurde, einschließlich seines Software-Threads oder Dienstes, gültig, den Verlauf nicht zurückzusetzen, bevor der VM-BS-Gast wiederhergestellt wurde. In einer weiteren Ausführungsform soll der VMM den Verlauf mit einer Anweisung HRESET zurücksetzen (z.B. wo dies durch die VMM HRESET-Fähigkeiten gestattet wird), bevor der BS-VM-Gast wiederhergestellt wird, falls die VMM-Software-Threads aktiv sind oder der VMM seinen Dienst verwendet, der möglicherweise sensible Informationen enthält, die durch ein Verlaufs-Reset zurückgesetzt werden sollten. In bestimmten Ausführungsformen soll der folgende Fluss verwendet werden. In einer Ausführungsform kann der Verlaufs-Reset nur für eine Teilmenge von Fähigkeiten durchgeführt werden (z.B. Ausführung von HRESET mit dem HRESET EAX-Parameterwert des VMM). Ein Beispielfluss (z.B. ausgeführt durch einen VMM vor dem Wiederherstellen einer VM) ist Folgender:

      WRMSR HRESET_ENABLE, VMM-Unterstützungsfähigkeiten
      MOV EAX, VMM-Unterstützungsfähigkeiten
      HRESET imm8 // Löschen des HGS-Verlaufs
      WRMSR HRESET_ ENABLE, ZERO_ VAL

In bestimmten Nutzungsmodellen verwendet, z.B. aufgrund des Fehlens der Option des VM-BS-Gastes, die Unterstützung der Anweisung HRESET und ihrer Fähigkeiten zu spezifizieren, und der Option zum Schreiben in das Einverständnis-MSR IA32HRESET__ENABLE, der BS-VM-Gast die Anweisung HRESET in bestimmten Ausführungsformen nicht. In einer Ausführungsform wird, wenn das VM-BS noch immer die Ausführung dieser neuen Anweisung anfordert (z.B., wenn dieser Anweisungsparameter im EAX-Register leer ist), der HRESET als eine NOP ausgeführt. In einer Ausführungsform verursacht, wenn das durch die Anweisung verwendete Register (z.B. EAX) nicht leer ist (z.B. alles Nullen), die Ausführung der Anweisung eine Ausnahme (z.B. einen allgemeinen Schutzfehler (GENERAL PROTECTION FAULT)).

In einer Ausführungsform kann ein Nutzungsmodell „Nur VMM‟ des HRESET (z.B. wie in 8C gezeigt) eines oder mehrere der Folgenden aufweisen:

1. Während der VMM-Startzeit prüft der VMM, ob HRESET durch Spezifizierung des funktionalen CPUID-Bits CPUID[7,1][22] unterstützt wird.
1. 1. Spezifizieren der HRESET-Fähigkeiten durch CPUID[0x20, ECX=0].EBX[31:0], wodurch angegeben wird, welche Vorhersagen zurückgesetzt werden können.
2. 2. Zustimmen zum Zurücksetzen einer Teilmenge der verfügbaren Fähigkeiten durch das Setzen der entsprechenden Bits im MSR IA32_HRESET_ENABLE. Die Zustimmungsbits im MSR IA32HRESET ENABLE stimmen mit den CPUID-Bits der HRESET-Fähigkeiten überein (Übereinstimmung 1 zu 1).
3. 3. Sichern der VMM-Nutzung-HRESET-Fähigkeiten zur Verwendung.
2. Der VMM sollte seine Einstellung des MSR IA32_HRESET_ENABLE nach VMEXIT wiederherstellen, falls der VMM die Anweisung HRESET verwenden wird. In diesem Fall sollte der VMM die Einstellung des IA32_HRESET_ENABLE der VM vor VMLAUNC oder VMRESUM auf Null setzen, um zu vermeiden, dass seine VM die Option erhält, HRESET anders als eine NOP auszuführen.
3. Während der S/W-Thread-Kontextumschaltung des VMM, und bevor der neue S/W-Thread seine Laufzeit startet, sollte der VMM den H/W-Verlauf des aktuellen S/W-Threads löschen.
1. 1. Einstellen der Ziel-Reset-Merkmale durch den HRESET EAX-Operanden.
2. 2. Der HRESET EAX-Operand muss gesetzte Bits enthalten, bei welchen es sich um eine Teilmenge derjenigen handelt, die im MSR IA32_HRESET_ENABLE gesetzt sind. Ansonsten erzeugt HRESET #GP(0).
3. 3. Ausführen der HRESET EAX-ISA.
4. Während des VMM-VM-Migrationsflusses oder eines anderen VMM-Ereignisses, welches das Zurücksetzen des aktuellen H/W-Verlaufs anfordert, wenn HRESET unterstützt wird (Prüfen der Funktion CPUID):
1. 1. Der VMM muss den Wert des MSR IA32HRESET ENABLE möglicherweise wieder in den VMM-Unterstützungswert herstellen, wenn dieses MSR für die VM-Nutzung virtualisiert wird.
2. 2. Einstellen der VMM-Ziel-Reset-Merkmale durch den HRESET EAX-Operanden.
3. 3. Ausführen der HRESET EAX-ISA.
4. 4. In diesem Fall sollte der VMM die Einstellung des IA32HRESET ENABLE der VM vor VMLAUNC oder VMRESUM auf Null setzen, um zu vermeiden, dass seine VM die Option erhält, HRESET anders als eine NOP auszuführen.
5. Der VMM sollte die HRESET CPUID-Bits (z.B. CPUID[7,1][22] und HRESET CPUID[0x20,0].EBX) und das MSR IA32HRESET ENABLE nicht virtualisieren.
1. 1. Immer wenn die VM versucht, auf das MSR IA32HRESET__CTLENABLE zuzugreifen, sollte der VMM einen Universalfehler an die VM ausgeben.
2. 2. Die CPU erzeugt kein #UD, wenn das Gast-BS infolgedessen HRESET ausführt, stattdessen veranlasst die CPU Folgendes:
  1. 1. Ausführen von HRESET als NOP, wenn EAX = 0 (keine Anforderung des Zurücksetzens jegliches Verlaufs).
  2. 2. Erzeugen von #GP(0), wenn EAX != 0.

In einer bestimmten Ausführungsform dieses Modells kann ein VMM steuern (z.B. wie in 8D gezeigt), welche Bits in IA32_HRESET_ENABLE gesetzt werden, der VMM kann Gast-WRMSR und -RDMSR für dieses MSR abfangen, der VMM kann entscheiden, welche Verlaufsfähigkeiten er einem Gast gestattet zurückzusetzen, indem er eine Teilmenge der Fähigkeitsbits für den Gast spezifiziert (z.B. eine virtualisierte CPUID), beim Abfangen eines MSR-Schreibvorgangs (WRMSR), erzeugt der VMM #GP(0) für den Gast, wenn dieser versucht hat, jegliches Bit über die Teilmenge hinaus zu setzen, die durch den VMM in der CPUID gestattet wurde, und/oder der VMM sollte den MSR-Wert für den Gast beibehalten, wenn der Gast gesetzte Fähigkeitsbits aufweist, die durch den VMM gestattet werden, sowie während einer VM-Umschaltung.

In noch einem weiteren Modell (z.B. Modell 804, wie in 8D abgebildet), hat der VMM Kenntnis von der Unterstützung der Anweisung HRESET und gibt die HRESET-Unterstützung für sein VM-BS frei, z.B. spezifiziert und unterstützt der VMM den HRESET auf die gleiche Weise wie für das reguläre BS. In bestimmten Ausführungsformen dieses Modells gibt der VMM den HRESET zur Verwendung durch den VM-BS-Gast frei. In bestimmten Ausführungsformen beinhaltet die Freigabe für den VM-BS-Gast die Option zum Spezifizieren der HRESET-Anweisungsunterstützung durch CPUID.HRESET (wobei CPUID.HRESET z.B. CPUID[0×7,ECX=1].EAX[22] ist) und der Fähigkeiten des HRESET durch CPUID.HRESET_CAP (z.B. CPUID[0x20].EBX[31:0]). In bestimmten Ausführungsformen erfolgt dies durch das Emulieren der CPUID-Anweisung. In bestimmten Ausführungsformen ermöglicht der VMM dem VM-BS-Gast die Option zum Freigeben der und Zustimmen zu den HRESET-Fähigkeiten für den VM-BS-Gast und zum Zugreifen auf das Konfigurations-MSR IA32HRESET_ENABLE des HRESET. In bestimmten Ausführungsformen wird diese Art der Unterstützung durch das Emulieren der Unterstützung von IA32_HRESET_ENABLE für den VM-BS-Gast bereitgestellt. In bestimmten Ausführungsformen kann der VMM eine Teilmenge der H/W-Unterstützungsfähigkeiten für die Nutzung durch den VM-BS-Gast freigeben, z.B. durch das Emulieren nur dieser Teilmenge als Teil von CPUID.HRESET_CAP (wobei HRESET_CAP z.B. CPUID[0x20, ECX=0].EBX[31:0] ist) und das Steuern, dass nur diese Fähigkeitsbits durch den VM-BS-Gast im MSR HRESET_ENABLE freigegeben werden. In bestimmten Ausführungsformen löst ein falsches und nicht unterstütztes Setzen von Bits durch den VM-BS-Gast im emulierten MSR HRESET_ENABLE eine allgemeine Schutzausnahme vom VMM für den VM-BS-Gast aus. Als eine weitere Option kann der VMM dem VM-BS-Gast das Lesen des IA32_HRESET ENABLE auch ohne Emulation ermöglichen.

In bestimmten Ausführungsformen sollte, während der Laufzeit des VM-BS-Gastes und vor der Ausführung des VMM-Threads durch den VMM oder VMLAUNC, VMRESUME weiterhin IA32_HRESET_ENABLE auf den Einstellwert dieses MSR für den VM-BS-Gast wiederherstellen, während dieser Wert als Teil der Emulation dieses MSR gesichert wird.

In bestimmten Ausführungsformen liegt es, während VMEXIT und vor der Ausführung des Threads des VMM oder einer VM-Umschaltung zu einem anderen VM-BS-Gast, beim VMM, zunächst den Verlauf des aktuellen Gastes zurückzusetzen und seine Einstellung eines Wertes in HRESET_ENABLE wiederherzustellen, bevor HRESET mit dem HRESET EAX-Parameterwert des VMM ausgeführt wird. Die beiden Reset-Aufrufe können in einen einzelnen Aufruf verschmolzen werden, der die gemeinsame Einstellung der HRESET-Fähigkeiten aufweist. In bestimmten Ausführungsformen erfolgt der Verlaufs-Reset nur, wenn die Möglichkeit besteht, dass Operationen des VMM Einfluss auf den Verlauf des Gastes haben können und/oder wenn es wünschenswert ist, ein Durchsickern des Verlaufs vom Gast zum VMM zu vermeiden.

Ein Beispielfluss ist Folgender:

      MOV EAX, aktuelle Unterstützungsfähigkeiten des VM-BS-Gastes
      HRESET // Löschen des Verlaufs des aktuellen Gastes
      WRMSR HRESET_ENABLE, VMM-Unterstützungsfähigkeiten
      MOV EAX, VMM-Unterstützungsfähigkeiten
      HRESET imm8 // Löschen des relevanten Verlaufs des VMM

Der obige Fluss mit zwei HRESET-Operationen kann verwendet werden, wenn keine Übereinstimmung zwischen den beiden Konfigurationen vorliegt, jedoch ist es möglich, diesen Fluss in eine einzelne Nutzung des HRESET zu optimieren. Ein Beispiel dieses Flusses ist unten gezeigt:

      WRMSR HRESET ENABLE, VMM-Unterstützungsfähigkeiten ODER
      Unterstützungsfähigkeiten des aktuellen VM-BS-Gastes 

      MOV EAX, VMM-Unterstützungsfähigkeiten ODER
      Unterstützungsfähigkeiten des aktuellen VM-BS-Gastes
      HRESET imm8 // Löschen des relevanten Verlaufs des VMM
      WRMSR HRESET_ENABLE, VMM-Unterstützungsfähigkeiten

In bestimmten Ausführungsformen liegt es, vor dem Wiederherstellen eines VM-BS-Gastes, beim VMM, den Verlauf zurückzusetzen, der während seiner Laufzeit angesammelt wurde, und den VM-BS-Gast in IA32_HRESET_ENABLE wiederherzustellen. In einer Ausführungsform erfolgt das Zurücksetzen von Informationen durch einen VMM im Falle der Ausführung von VMM-Software-Threads oder der Ausführung anderer sensibler Arbeit durch den VMM.

Ein Beispielfluss ist Folgender:

      MOV EAX, VMM-Unterstützungsfähigkeiten ODER
      Unterstützungsfähigkeiten des VM-BS-Gastes
      HRESET imm8 // Löschen des relevanten Verlaufs des VMM
      WRMSR HRESET ENABLE, VMM-Unterstützungsfähigkeiten ODER
      Unterstützungsfähigkeiten des VM-BS-Gastes

In bestimmten Ausführungsformen einer Kontextumschaltung zwischen zwei unterschiedlichen VM-BS-Gästen soll der VMM den Verlauf basierend auf den Fähigkeitseinstellungen des alten und des neuen VM-BS-Gastes zurücksetzen (z.B., wenn sie nicht übereinstimmen) und die IA32_HRESET_ENABLE-Werte sichern und wiederherstellen.

Ein Beispielfluss ist Folgender:

      Sichern des aktuellen VM-BS-Gastes durch RDMSR des MSR
      IA32_HRESET_ENABLE
      MOV EAX, Unterstützungsfähigkeiten des aktuellen Gastes
      HRESET imm8
      WRMSR IA32_HRESET_ENABLE, Unterstützungsfähigkeiten des neuen
      Gastes
      MOV EAX, Unterstützungsfähigkeiten des neuen Gastes
      HRESET

In bestimmten Ausführungsformen weist der Fluss zwei Instanzen des HRESET auf, wenn zwischen den beiden HRESET-Konfigurationen keine Übereinstimmung herrscht, jedoch besteht die Möglichkeit, ihn in eine einzelne HRESET-Operation zu optimieren.

Ein Beispielfluss ist Folgender:

      Sichern des aktuellen VM-BS-Gastes durch RDMSR des MSR
      IA32_HRESET_ENABLE
      WRMSR IA32 HRESET_ENABLE, Unterstützungsfähigkeiten des neuen
      Gastes ODER des aktuellen VM-BS-Gastes
      MOV EAX, Unterstützungsfähigkeiten des neuen Gastes ODER des
      aktuellen VM-BS-Gastes
      HRESET imm8
      WRMSR IA32_HRESET_ENABLE, Unterstützungsfähigkeiten des neuen
      Gastes

In einer Ausführungsform kann ein Nutzungsmodell für VMM und VM(s) (z.B. wie in 8C und 8D gezeigt) eines oder mehrere der Folgenden aufweisen:

1. Während der VMM-Startzeit prüft der VMM, ob HRESET durch Spezifizierung des funktionalen CPUID-Bits CPUID[7,1][22] unterstützt wird.
1. 1. Spezifizieren der HRESET-Fähigkeiten durch CPUID[0x20, ECX=0].EBX[31:0], wodurch angegeben wird, welche Vorhersagen zurückgesetzt werden können.
2. 2. Zustimmen zum Zurücksetzen einer Teilmenge der verfügbaren Fähigkeiten durch das Setzen der entsprechenden Bits im MSR IA32HRESET ENABLE. Die Einverständnis-Bits im MSR IA32HRESET ENABLE stimmen mit den CPUID-Bits der HRESET-Fähigkeiten überein (Übereinstimmung 1 zu 1).
3. 3. Sichern der VMM-Nutzung-HRESET-Fähigkeiten zur Verwendung.
2. Der VMM sollte seine Einstellung des MSR IA32_HRESET_ENABLE nach VMEXIT wiederherstellen, falls der VMM die Anweisung HRESET verwenden wird. In diesem Fall sollte der VMM die Einstellung des IA32_HRESET_ENABLE der VM vor VMLAUNC oder VMRESUME wiederherstellen/einstellen.
3. Während der S/W-Thread-Kontextumschaltung des VMM, und bevor der neue S/W-Thread seine Laufzeit startet, sollte das BS den H/W-Verlauf des aktuellen S/W-Threads löschen.
1. 1. Einstellen der Ziel-Reset-Merkmale durch den HRESET EAX-Operanden.
2. 2. Der HRESET EAX-Operand muss gesetzte Bits enthalten, bei welchen es sich um eine Teilmenge derjenigen handelt, die im MSR IA32_HRESET_ENABLE gesetzt sind. Ansonsten erzeugt HRESET #GP(0).
3. 3. Ausführen der HRESET EAX-ISA.
4. Während des VMM-VM-Migrationsflusses oder eines anderen VMM-Ereignisses, welches das Zurücksetzen des aktuellen H/W-Verlaufs anfordert, wenn HRESET unterstützt wird (Prüfen der Funktion CPUID):
1. 1. Der VMM muss der Wert des MSR IA32HRESET ENABLE möglicherweise wieder in den VMM-Unterstützungswert herstellen, wenn dieses MSR für die VM-Nutzung virtualisiert wird.
2. 2. Einstellen der VMM-Ziel-Reset-Merkmale durch den HRESET EAX-Operanden.
3. 3. Ausführen der HRESET EAX-ISA.
4. 4. Wiederherstellen, falls nötig, des MSR IA32HRESET ENABLE auf den virtualisierten Einstellwert der VM für dieses MSR.
5. Virtualisieren der CPUID-Bits des HRESET und des MSR IA32HRESET ENABLE:
1. 1. Freigeben zur Nutzung durch die VM, wenn HRESET und ihre Teilmenge oder alle Fähigkeitsbits unterstützt werden.
  1. 1. Virtualisieren des HRESET-Funktionsbits CPUID[7,1][22]
  2. 2. Virtualisieren des HRESET CPUID[32,0].EBX
2. 2. Virtualisieren des MSR zum Steuern des HRESET
  1. 1. Virtualisieren, welche Bits im MSR IA32_HRESET_ENABLE durch die VM gesetzt werden können
3. 3. Es besteht die Möglichkeit, unterschiedliche Unterstützungsfähigkeiten pro VM freizugeben.
4. 4. Der VMM muss möglicherweise den Wert des MSR IA32HRESET ENABLE wieder in den VMM-Unterstützungswert herstellen, falls dieses MSR zur Nutzung durch die VM virtualisiert wurde, in diesem Fall muss der VMM den VM-Wert wiederherstellen, bevor diese VM wiederhergestellt wird.
5. 5. Die CPU erzeugt kein #UD, wenn das Gast-BS infolgedessen HRESET ausführt, stattdessen veranlasst die CPU Folgendes:
  1. 1. Ausführen von HRESET als NOP, wenn EAX = 0 (keine Anforderung des Zurücksetzens jegliches Verlaufs).
  2. 2. Erzeugen von #GP(0), wenn EAX != 0.

In bestimmten Ausführungsformen dieses Modells kann ein VMM steuern, welche Bits im IA32_HRESET_ENABLE gesetzt werden, der VMM kann einen MSR-Gastschreibvorgang (WRMSR) und einen MSR-Gastlesevorgang (RDMSR) für dieses MSR abfangen, der VMM kann entscheiden, welche Verlaufsfähigkeiten er einem Gast gestattet zurückzusetzen, spezifiziert eine Teilmenge der Fähigkeitsbits für den Gast (z.B. eine virtualisierte CPUID), beim Abfangen eines WRMSR erzeugt der VMM #GP(0) für den Gast, wenn dieser versucht hat, jegliches Bit über die Teilmenge, die durch den VMM im CPUID gestattet wurde, hinaus zu setzen, und/oder der VMM sollte den MSR-Wert für den Gast aufrechterhalten, wenn der Gast gesetzte Fähigkeitsbits aufweist, die durch den VMM gestattet wurden, sowie während einer VM-Umschaltung. In bestimmten Ausführungsformen dieses Modells beinhaltet die Virtualisierungsunterstützung für den HRESET eine Virtualisierung der CPUID-Bits; wenn ein VMM zum Beispiel einer VM die Option zur Verwendung des HRESET gestatten soll, soll der VMM das CPUID-Bit der HRESET-Funktion (z.B. CPUID[7,1].EAX[22]) und die HRESET-Fähigkeiten, die der VMM für die VM freigibt (z.B. durch die CPUID[0x20].EBX-Bits), virtualisieren.

In bestimmten Ausführungsformen kann ein VMM keinen VM-Austritt verursachen, z.B. wenn HRESET gerade durch die VM verwendet wird, er weist keine entsprechende VM-Ausführungssteuerung auf und/oder der VMM kann nicht sicherstellen, dass ein HRESET immer #UD erzeugt.

9 veranschaulicht ein Flussdiagramm gemäß Ausführungsformen der Offenbarung. Der abgebildete Fluss 900 beinhaltet das Erzeugen mehrerer Software-Thread-Laufzeiteigenschaft-Verläufe mit einem Hardware-Guide-Scheduler eines Hardwareprozessors 902, das Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung mit einem Decoder des Hardwareprozessors, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister 904 identifiziert, und das Ausführen der decodierten Einzelanweisung mit einer Ausführungsschaltung des Hardwareprozessors, um zu prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und wenn das Freigabe-Bit gesetzt ist, die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers 906 zurückzusetzen.

Beispielhafte Architekturen, Systeme usw., in denen der obige Fluss eingesetzt werden kann, sind unten detailliert beschrieben.

Mindestens einige Ausführungsformen der offenbarten Technologien können im Hinblick auf die folgenden Beispiele beschrieben werden:

Beispiel 1. Ein Hardwareprozessor, welcher Folgendes aufweist:
- einen Hardware-Guide-Scheduler, der mehrere Software-Thread-Laufzeiteigenschaft-Verläufe aufweist;
- einen Decoder zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister identifiziert; und
- eine Ausführungsschaltung zum Ausführen der decodierten Einzelanweisung für Folgendes:
  - Prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und
  - wenn das Freigabe-Bit gesetzt ist, Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers.
Beispiel 2. Der Hardwareprozessor von Beispiel 1, wobei, wenn das Freigabe-Bit gesetzt ist, die Ausführungsschaltung die decodierte Einzelanweisung zum Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers ausführen soll, ohne einen anderen Architekturzustand des Hardwareprozessors zu modifizieren.
Beispiel 3. Der Hardwareprozessor von Beispiel 1, wobei es sich bei einem Opcode der Einzelanweisung um einen älteren Opcode handelt, und, wenn das Freigabe-Bit nicht gesetzt ist, die Ausführungsschaltung die Einzelanweisung als eine Nulloperation ausführen soll.
Beispiel 4. Der Hardwareprozessor von Beispiel 1, wobei, wenn das Freigabe-Bit gesetzt ist, die Ausführungsschaltung die decodierte Einzelanweisung zum Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers nur ausführen soll, wenn die Einzelanweisung zur Ausführung durch ein Betriebssystem angefordert wird.
Beispiel 5. Der Hardwareprozessor von Beispiel 1, wobei die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe mehrere Gewichte für entsprechende Klassen von Leistungsüberwachungsereignissen für mehrere Kerne des Hardwareprozessors aufweisen.
Beispiel 6. Der Hardwareprozessor von Beispiel 5, wobei die entsprechenden Klassen eine erste Klasse für einen ersten Kerntyp und eine zweite Klasse für einen zweiten Kern mit höherer Leistung aufweisen.
Beispiel 7. Der Hardwareprozessor von Beispiel 5, wobei die entsprechenden Klassen eine erste Klasse für eine Vektoranweisung des Ganzzahltyps und eine zweite Klasse für eine Vektoranweisung des Gleitkommatyps aufweisen.
Beispiel 8. Der Hardwareprozessor von Beispiel 1, wobei der Hardware-Guide-Scheduler einen Hinweis für einen nächsten Software-Thread, der auf dem Hardwareprozessor ausgeführt werden soll, in einem Register des Hardwareprozessors speichern soll, um einem Betriebssystem einen Kerntyp von mehreren Kerntypen des Hardwareprozessors anzuzeigen, und der Hinweis auf den mehreren Software-Thread-Laufzeiteigenschaft-Verläufen basiert.
Beispiel 9. Ein Verfahren, welches Folgendes umfasst:
- Erzeugen mehrerer Software-Thread-Laufzeiteigenschaft-Verläufe mit einem Hardware-Guide-Scheduler eines Hardwareprozessors;
- Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung mit einem Decoder des Hardwareprozessors, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister identifiziert; und
- Ausführen der decodierten Einzelanweisung mit einer Ausführungsschaltung des Hardwareprozessors für Folgendes:
  - Prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und
  - wenn das Freigabe-Bit gesetzt ist, Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers.
Beispiel 10. Das Verfahren von Beispiel 9, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers zurücksetzt, ohne einen anderen Architekturzustand des Hardwareprozessors zu modifizieren.
Beispiel 11. Das Verfahren von Beispiel 9, wobei es sich bei einem Opcode der Einzelanweisung um einen älteren Opcode handelt, und, wenn das Freigabe-Bit nicht gesetzt ist, die Ausführungsschaltung die Einzelanweisung als eine Nulloperation ausführt.
Beispiel 12. Das Verfahren von Beispiel 9, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers nur zurücksetzt, wenn die Einzelanweisung zur Ausführung durch ein Betriebssystem angefordert wird.
Beispiel 13. Das Verfahren von Beispiel 9, wobei die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe mehrere Gewichte für entsprechende Klassen von Leistungsüberwachungsereignissen für mehrere Kerne des Hardwareprozessors aufweisen.
Beispiel 14. Das Verfahren von Beispiel 13, wobei die entsprechenden Klassen eine erste Klasse für einen ersten Kerntyp und eine zweite Klasse für einen zweiten Kern mit höherer Leistung aufweisen.
Beispiel 15. Das Verfahren von Beispiel 13, wobei die entsprechenden Klassen eine erste Klasse für eine Vektoranweisung des Ganzzahltyps und eine zweite Klasse für eine Vektoranweisung des Gleitkommatyps aufweisen.
Beispiel 16. Das Verfahren von Beispiel 9, welches ferner das Speichern eines Hinweises, durch den Hardware-Guide-Scheduler, für einen nächsten Software-Thread, der auf dem Hardwareprozessor ausgeführt werden soll, in einem Register des Hardwareprozessors umfasst, um einem Betriebssystem einen Kerntyp von mehreren Kerntypen des Hardwareprozessors anzuzeigen, wobei der Hinweis auf den mehreren Software-Thread-Laufzeiteigenschaft-Verläufen basiert.
Beispiel 17. Ein nichttransitorisches maschinenlesbares Medium, das Code speichert, der, wenn er durch eine Maschine ausgeführt wird, die Maschine zum Durchführen eines Verfahrens veranlasst, das Folgendes umfasst:
- Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung mit einem Decoder eines Hardwareprozessors, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister identifiziert; und
- Ausführen der decodierten Einzelanweisung mit einer Ausführungsschaltung des Hardwareprozessors für Folgendes:
  - Prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und
  - wenn das Freigabe-Bit gesetzt ist, Zurücksetzen mehrerer Software-Thread-Laufzeiteigenschaft-Verläufe eines Hardware-Guide-Schedulers des Hardwareprozessors.
Beispiel 18. Das nichttransitorische maschinenlesbare Medium von Beispiel 17, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers zurücksetzt, ohne einen anderen Architekturzustand des Hardwareprozessors zu modifizieren.
Beispiel 19. Das nichttransitorische maschinenlesbare Medium von Beispiel 17, wobei es sich bei einem Opcode der Einzelanweisung um einen älteren Opcode handelt, und, wenn das Freigabe-Bit nicht gesetzt ist, die Ausführungsschaltung die Einzelanweisung als eine Nulloperation ausführt.
Beispiel 20. Das nichttransitorische maschinenlesbare Medium von Beispiel 17, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers nur zurücksetzt, wenn die Einzelanweisung zur Ausführung durch ein Betriebssystem angefordert wird.
Beispiel 21. Das nichttransitorische maschinenlesbare Medium von Beispiel 17, wobei die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe mehrere Gewichte für entsprechende Klassen von Leistungsüberwachungsereignissen für mehrere Kerne des Hardwareprozessors aufweisen.
Beispiel 22. Das nichttransitorische maschinenlesbare Medium von Beispiel 21, wobei die entsprechenden Klassen eine erste Klasse für einen ersten Kerntyp und eine zweite Klasse für einen zweiten Kern mit höherer Leistung aufweisen.
Beispiel 23. Das nichttransitorische maschinenlesbare Medium von Beispiel 21, wobei die entsprechenden Klassen eine erste Klasse für eine Vektoranweisung des Ganzzahltyps und eine zweite Klasse für eine Vektoranweisung des Gleitkommatyps aufweisen.
Beispiel 24. Das nichttransitorische maschinenlesbare Medium von Beispiel 17, welches ferner das Speichern eines Hinweises, durch den Hardware-Guide-Scheduler, für einen nächsten Software-Thread, der auf dem Hardwareprozessor ausgeführt werden soll, in einem Register des Hardwareprozessors umfasst, um einem Betriebssystem einen Kerntyp von mehreren Kerntypen des Hardwareprozessors anzuzeigen, wobei der Hinweis auf den mehreren Software-Thread-Laufzeiteigenschaft-Verläufen basiert.
Beispiel 25. Das nichttransitorische maschinenlesbare Medium von Beispiel 17, welches ferner das Übersetzen der Einzelanweisung in eine oder mehrere Anweisungen einer unterschiedlichen Anweisungssatzarchitektur vor dem Decodieren umfasst, wobei das Ausführen der einen oder der mehreren Anweisungen der unterschiedlichen Anweisungssatzarchitektur funktional äquivalent zum Ausführen der decodierten Einzelanweisung sein soll.

In noch einer weiteren Ausführungsform weist eine Vorrichtung ein Datenspeichergerät auf, welches Code speichert, der, wenn er durch einen Hardwareprozessor ausgeführt wird, den Hardwareprozessor zum Durchführen jegliches hierin offenbarten Verfahrens veranlasst. Eine Vorrichtung kann wie in der detaillierten Beschreibung beschrieben sein. Ein Verfahren kann wie in der detaillierten Beschreibung beschrieben sein.

Ein Anweisungssatz kann ein oder mehrere Anweisungsformate beinhalten. Ein gegebenes Anweisungsformat kann verschiedene Felder definieren (z.B. Zahl von Bits, Standort von Bits), um, unter anderem, die Operation, die durchgeführt werden soll (z.B. ein Opcode), und den (die) Operanden, an welchem/n diese Operation durchgeführt werden soll, und/oder (ein) andere(s) Datenfeld(er) (z.B. eine Maske) zu spezifizieren. Einige Anweisungsformate werden durch die Definition von Anweisungsvorlagen (oder Unterformaten) weiter aufgegliedert. Zum Beispiel können die Anweisungsvorlagen eines gegebenen Anweisungsformates derart definiert sein, dass sie unterschiedliche Teilmengen der Felder des Anweisungsformates aufweisen (die enthaltenen Felder liegen typischerweise in der gleichen Reihenfolge vor, jedoch weisen zumindest einige davon unterschiedliche Bitpositionen auf, weil weniger Felder enthalten sind), und/oder derart definiert sein, dass ein gegebenes Feld unterschiedlich interpretiert wird. Somit wird jede Anweisung einer ISA unter Verwendung eines gegebenen Anweisungsformates ausgedrückt (und, falls definiert, in einer gegebenen einen der Anweisungsvorlagen dieses Anweisungsformates) und beinhaltet Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist eine beispielhafte ADD (HINZUFÜGEN) -Anweisung einen spezifischen Opcode und ein Anweisungsformat auf, das ein Feld „Opcode‟ zum Spezifizieren dieses Opcodes, und Felder „Operand‟ zum Auswählen von Operanden (Quelle 1/Ziel und Quelle 2) aufweist; und durch ein Auftreten dieser ADD-Anweisung in einem Anweisungsstrom werden durch spezifische Inhalte in den Feldern „Operand‟ spezifische Operanden ausgewählt. Ein Satz von SIMD-Erweiterungen, bezeichnet als Advanced Vector Extensions (AVX) (AVX1 und AVX2), und die Verwendung des Vector Extensions (VEX) -Codierungsschemas wurden freigegeben und/oder veröffentlicht (siehe z.B. Intel® 64 and IA-32 Architectures Software Developer's Manual, November 2018; und siehe Intel® Architecture Instruction Set Extensions Programming Reference, Oktober 2018).

Beispielhafte Anweisungsformate

Ausführungsformen der hierin beschriebenen Anweisung(en) können in unterschiedlichen Formaten verkörpert sein. Außerdem sind unten beispielhafte Systeme, Architekturen und Pipelines detailliert beschrieben. Ausführungsformen der Anweisung(en) können auf derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die detailliert beschriebenen beschränkt.

Generisches vektorfreundliches Anweisungsformat

Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das für Vektoranweisungen geeignet ist (z.B. liegen bestimmte Felder vor, die spezifisch für Vektoroperationen sind). Während Ausführungsformen beschrieben sind, in welchen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Anweisungsformat unterstützt werden, verwenden alternative Ausführungsformen lediglich Vektoroperationen mit dem vektorfreundlichen Anweisungsformat.

10A - 10B sind Blockdiagramme, welche ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon gemäß Ausführungsformen der Offenbarung veranschaulichen. 10A ist ein Blockdiagramm, welches ein generisches vektorfreundliches Anweisungsformat und Klasse-A-Anweisungsvorlagen davon gemäß Ausführungsformen der Offenbarung veranschaulicht; während 10B ein Blockdiagramm ist, welches das generische vektorfreundliche Anweisungsformat und Klasse-B-Anweisungsvorlagen davon gemäß Ausführungsformen der Offenbarung veranschaulicht. Spezifisch veranschaulicht ist ein generisches vektorfreundliches Anweisungsformat 1000, für welches Klasse-A- und Klasse-B-Anweisungsvorlagen definiert sind, welche beide Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 und Anweisungsvorlagen mit Arbeitsspeicherzugriff 1020 aufweisen. Der Begriff generisch im Kontext des vektorfreundlichen Anweisungsformates bezieht sich darauf, dass das Anweisungsformat nicht an jeglichen spezifischen Anweisungssatz gebunden ist.

Während Ausführungsformen der Offenbarung beschrieben werden, in welchen das vektorfreundliche Anweisungsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit (4 Bytes) oder 64-Bit (8 Bytes) -Datenelementbreiten (oder -größen) (somit besteht ein 64-Byte-Vektor entweder aus 16 Elementen mit Doppelwortgröße oder alternativ aus 8 Elementen mit Quadwortgröße), eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 16-Bit (2 Bytes) oder 8-Bit (1 Byte) -Datenelementbreiten (oder -größen), eine 32-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit (4 Bytes), 64-Bit (8 Bytes), 16-Bit (2 Bytes) oder 8-Bit (1 Byte) -Datenelementbreiten (oder -größen) und eine 16-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit (4 Bytes), 64-Bit (8 Bytes), 16-Bit (2 Bytes) oder 8-Bit (1 Byte) -Datenelementbreiten (oder -größen), können alternative Ausführungsformen mehr, weniger und/oder unterschiedliche Vektoroperandengrößen (z.B. 256-Byte-Vektoroperanden) mit mehr, weniger oder unterschiedlichen Datenelementbreiten (z.B. 128-Bit (16 Bytes) - Datenelementbreiten) unterstützen.

Die Klasse-A-Anweisungsvorlagen in 10A weisen Folgendes auf: 1) innerhalb der Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 sind eine Anweisungsvorlage für eine Operation des Vollrundungssteuerungstyps ohne Arbeitsspeicherzugriff 1010 und eine Anweisungsvorlage für eine Operation des Datentransformationstyps ohne Arbeitsspeicherzugriff 1015 gezeigt; und 2) innerhalb der Anweisungsvorlagen mit Arbeitsspeicherzugriff 1020 sind eine Anweisungsvorlage mit temporärem Arbeitsspeicherzugriff 1025 und eine Anweisungsvorlage mit nichttemporärem Arbeitsspeicherzugriff 1030 gezeigt. Die Klasse-B-Anweisungsvorlagen in 10B weisen Folgendes auf: 1) innerhalb der Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 sind eine Anweisungsvorlage für eine Schreibmaskensteuerungsoperation des Teilrundungssteuerungstyps ohne Arbeitsspeicherzugriff 1012 und eine Anweisungsvorlage für eine Schreibmaskensteuerungsoperation des V-Größentyps ohne Arbeitsspeicherzugriff 1017 gezeigt; und 2) innerhalb der Anweisungsvorlagen mit Arbeitsspeicherzugriff 1020 ist eine Anweisungsvorlage für eine Schreibmaskensteuerungsoperation mit Arbeitsspeicherzugriff 1027 gezeigt.

Das generische vektorfreundliche Anweisungsformat 1000 weist die folgenden Felder auf, die unten in der in 10A - 10B veranschaulichten Reihenfolge aufgeführt sind.

Feld „Format‟ 1040 - ein spezifischer Wert (ein Anweisungsformat-Identifizierungswert) in diesem Feld identifiziert eindeutig das vektorfreundliche Anweisungsformat und somit das Auftreten von Anweisungen im vektorfreundlichen Anweisungsformat in Anweisungsströmen. An sich ist dieses Feld insofern optional, dass es für einen Anweisungssatz, der nur das generische vektorfreundliche Anweisungsformat aufweist, nicht benötigt wird.

Feld „Basisoperation‟ 1042 - sein Inhalt unterscheidet unterschiedliche Basisoperationen.

Feld „Registerindex‟ 1044 - sein Inhalt spezifiziert direkt oder durch Adresserzeugung die Standorte der Quell- und Zieloperanden, egal ob sie sich in Registern oder im Arbeitsspeicher befinden. Dazu zählen eine ausreichende Zahl von Bits zum Auswählen von N Registern aus einer PxQ (z.B. 32x512, 16x128, 32x1024, 64x1024) -Registerdatei. Während in einer Ausführungsform N bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (können z.B. bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel dient, können bis zu drei Quellen unterstützen, wobei eine dieser drei Quellen auch als das Ziel dient, oder können bis zu zwei Quellen und ein Ziel unterstützen).

Feld „Modifikator‟ 1046 - sein Inhalt unterscheidet das Auftreten von Anweisungen im generischen Vektoranweisungsformat mit Arbeitsspeicherzugriff gegenüber denen ohne; d.h., zwischen Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 und Anweisungsvorlagen mit Arbeitsspeicherzugriff 1020. Operationen mit Arbeitsspeicherzugriff lesen aus der und/oder schreiben in die Arbeitsspeicherhierarchie (in einigen Fällen werden dabei die Quell- und/oder Zieladressen unter Verwendung von Werten in Registern spezifiziert), während Operationen ohne Arbeitsspeicherzugriff dies nicht tun (z.B. sind die Quelle und die Ziele Register). Während dieses Feld in einer Ausführungsform auch zwischen drei unterschiedlichen Möglichkeiten auswählt, Arbeitsspeicheradressberechnungen durchzuführen, können alternative Ausführungsformen mehr, weniger oder unterschiedliche Möglichkeiten zum Durchführen von Arbeitsspeicheradressberechnungen unterstützen.

Feld „Zusatzoperation‟ 1050 - sein Inhalt unterscheidet, welche einer Vielzahl unterschiedlicher Operationen zusätzlich zur Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Offenbarung ist dieses Feld in ein Feld „Klasse‟ 1068, ein Feld „Alpha‟ 1052 und ein Feld „Beta‟ 1054 unterteilt. Das Feld „Zusatzoperation‟ 1050 gestattet, dass gemeinsame Gruppen von Operationen in einer Einzelanweisung anstatt 2, 3 oder 4 Anweisungen durchgeführt werden.

Feld „Skalierung‟ 1060 - sein Inhalt gestattet das Skalieren des Inhalts des Feldes „Index‟ für die Arbeitsspeicheradresserzeugung (z.B. bei der Adresserzeugung, die 2^Skalierung *Index + Basis verwendet).

Feld ‚Verschiebung‘ 1062A - sein Inhalt wird als Teil der Arbeitsspeicheradresserzeugung verwendet (z.B. bei der Adresserzeugung, die 2^Skaiierung *Index + Basis + Verschiebung verwendet).

Feld „Verschiebungsfaktor‟ 1062B (es sei darauf hingewiesen, dass die Nebeneinanderstellung des Feldes ‚Verschiebung‘ 1062A direkt über dem Feld „Verschiebungsfaktor‟ 1062B angibt, dass entweder das eine oder das andere verwendet wird) - sein Inhalt wird als Teil der Adresserzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, der durch die Größe eines Arbeitsspeicherzugriffes (N) skaliert werden soll - wobei N die Zahl von Bytes im Arbeitsspeicherzugriff ist (z.B. bei der Adresserzeugung, die 2^Skalierung *Index + Basis + skalierte Verschiebung verwendet). Redundante niederwertige Bits werden ignoriert, und daher wird der Inhalt des Feldes „Verschiebungsfaktor‟ mit der Gesamtgröße der Arbeitsspeicheroperanden (N) multipliziert, um die abschließende Verschiebung zu erzeugen, die beim Berechnen einer effektiven Adresse verwendet werden soll. Der Wert von N wird durch die Prozessorhardware während der Laufzeit basierend auf dem Feld, „Vollständiger Opcode‟ 1074 (später hierin beschrieben) und dem Feld „Datenmanipulation‟ 1054C bestimmt. Das Feld „Verschiebung‟ 1062A und das Feld „Verschiebungsfaktor‟ 1062B sind insofern optional, dass sie für die Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 nicht verwendet werden, und/oder unterschiedliche Ausführungsformen implementieren möglicherweise nur eines oder keines der beiden.

Feld „Datenelementbreite‟ 1064 - sein Inhalt unterscheidet, welche einer Reihe von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Anweisungen; in anderen Ausführungsformen nur für einige der Anweisungen). Dieses Feld ist insofern optional, dass es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird, und/oder Datenelementbreiten unter Verwendung eines Aspektes des Opcodes unterstützt werden.

Feld „Schreibmaske‟ 1070 - sein Inhalt steuert, auf einer Pro-Datenelementposition-Basis, ob diese Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Zusatzoperation reflektiert. Klasse-A-Anweisungsvorlagen unterstützen eine verschmelzende Schreibmaskenoperation, während Klasse-B-Anweisungsvorlagen sowohl eine verschmelzende als auch eine auf Null setzende Schreibmaskenoperation unterstützen. Beim Verschmelzen gestatten Vektormasken, dass jeglicher Satz von Elementen im Ziel während der Ausführung jeglicher Operation (spezifiziert durch die Basisoperation und die Zusatzoperation) vor Aktualisierungen geschützt wird; in einer anderen Ausführungsform wird der alte Wert von jedem Element des Ziels erhalten, für welches das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu gestatten Vektormasken bei der Nullsetzung, dass jeglicher Satz von Elementen im Ziel während der Ausführung jeglicher Operation (spezifiziert durch die Basisoperation und die Zusatzoperation) auf Null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 eingestellt, wenn das entsprechende Maskenbit einen Wert 0 aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit zum Steuern der Vektorlänge der Operation, die gerade durchgeführt wird (d.h., die Spanne von Elementen, die modifiziert werden, vom ersten zum letzten); jedoch ist es nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Somit gestattet das Feld „Schreibmaske‟ 1070 teilweise Vektoroperationen, einschließlich Lasten, Speicherungen, Arithmetik, Logik usw. Während Ausführungsformen der Offenbarung beschrieben sind, in welchen der Inhalt des Feldes „Schreibmaske‟ 1070 eines aus einer Zahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske enthält (und der Inhalt des Feldes „Schreibmaske‟ 1070 somit indirekt identifiziert, dass Maskierung durchgeführt werden soll), gestatten alternative Ausführungsformen stattdessen oder zusätzlich dazu, dass der Inhalt des Feldes „Schreibmaske‟ 1070 direkt die durchzuführende Maskierung spezifiziert.

Feld „Direkt‟ 1072 - sein Inhalt gestattet die Spezifizierung eines direkten Operanden. Dieses Feld ist insofern optional, dass es in einer Implementierung des generischen vektorfreundlichen Formates, die keinen direkten Operanden unterstützt, nicht vorliegt und in Anweisungen, die keinen direkten Operanden verwenden, nicht vorliegt.

Feld „Klasse‟ 1068 - sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Anweisungen. Unter Bezugnahme auf 10A - B wählt der Inhalt dieses Feldes zwischen Klasse-A- und Klasse-B-Anweisungen aus. In 10A - B werden Kästchen mit gerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert in einem Feld vorliegt (z.B. Klasse A 1068A bzw. Klasse B 1068B für das Feld „Klasse‟ 1068 in 10A - B).

Anweisungsvorlagen der Klasse A

Im Fall der Anweisungsvorlagen der Klasse A ohne Arbeitsspeicherzugriff 1005 wird das Feld „Alpha‟ 1052 als ein Feld ,RS' 1052A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Zusatzoperationstypen durchgeführt werden soll (z.B. sind Rundung 1052A.1 und Datentransformation 1052A.2 entsprechend für die Anweisungsvorlage für die Operation des Rundungstyps ohne Arbeitsspeicherzugriff 1010 und die Anweisungsvorlage für die Operation des Datentransformationstyps ohne Arbeitsspeicherzugriff 1015 spezifiziert), während das Feld „Beta‟ 1054 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. Bei den Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 liegen das Feld „Skalierung‟ 1060, das Feld ‚Verschiebung‘ 1062A und das Feld „Verschiebungsskalierung‟ 1062B nicht vor.

Anweisungsvorlagen ohne Arbeitsspeicherzugriff - Operation des V ollrundungssteuerungstyps

Bei der Anweisungsvorlage für die Operation des Vollrundungssteuerungstyps ohne Arbeitsspeicherzugriff 1010, wird das Feld „Beta‟ 1054 als ein Feld „Rundungssteuerung‟ 1054A interpretiert, dessen Inhalt(e) statische Rundung bereitstellt/bereitstellen. Während in den beschriebenen Ausführungsformen der Offenbarung das Feld „Rundungssteuerung‟ 1054A ein Feld „Alle Gleitkommaausnahmen unterdrücken‟ (SAE - Suppress All Floating Point Exceptions) 1056 und ein Feld „Rundungsoperationssteuerung‟ 1058 aufweist, codieren alternative Ausführungsformen diese beiden Konzepte möglicherweise in das gleiche Feld oder weisen lediglich das eine oder das andere dieser Konzepte/Felder auf (z.B. weisen möglicherweise nur das Feld „Rundungsoperationssteuerung‟ 1058 auf).

Feld „SAE‟ 1056 - sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung deaktiviert werden soll oder nicht; wenn der Inhalt des Feldes „SAE‟ 1056 angibt, dass eine Unterdrückung aktiviert ist, meldet eine gegebene Anweisung keinerlei Gleitkommaausnahme-Flag und aktiviert keinen Gleitkommaausnahme- Handler.

Feld „Rundungsoperationssteuerung‟ 1058 - sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z.B. Aufrunden, Abrunden, Runden-gegen-Null und Runden-zum-Nächsten). Somit gestattet das Feld „Rundungsoperationssteuerung‟ 1058 eine Veränderung des Rundungsmodus auf einer Pro-Anweisung-Basis. In einer Ausführungsform der Offenbarung, in welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi aufweist, hebt der Inhalt des Feldes „Rundungsoperationssteuerung‟ 1050 diesen Registerwert auf.

Anweisungsvorlagen ohne Arbeitsspeicherzugriff - Operation des Datentransformationstyp s

Bei der Anweisungsvorlage für die Operation des Datentransformationstyps ohne Arbeitsspeicherzugriff 1015, wird das Feld „Beta‟ 1054 als ein Feld „Datentransformation‟ 1054B interpretiert, dessen Inhalt unterscheidet, welche von einer Reihe von Datentransformationen durchgeführt werden soll (z.B. keine Datentransformation, Umstellen, Übertragen).

Im Fall einer Anweisungsvorlage der Klasse A mit Arbeitsspeicherzugriff 1020 wird das Feld „Alpha‟ 1052 als ein Feld ,Räumungshinweis' 1052B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in 10A sind Temporär 1052B.1 und Nichttemporär 1052B.2 entsprechend für die Anweisungsvorlage mit temporärem Arbeitsspeicherzugriff 1025 und die Anweisungsvorlage mit nichttemporärem Arbeitsspeicherzugriff 1030 spezifiziert), während das Feld „Beta‟ 1054 als ein Feld „Datenmanipulation‟ 1054C interpretiert wird, dessen Inhalt unterscheidet, welche aus einer Reihe von Datenmanipulationsoperationen (auch bekannt als Primitive) durchgeführt werden soll (z.B. keine Manipulation, Übertragung, Aufwärtskonvertierung einer Quelle und Abwärtskonvertierung eines Ziels). Die Anweisungsvorlagen mit Arbeitsspeicherzugriff 1020 weisen das Feld „Skalierung‟ 1060 und wahlweise das Feld „Verschiebung‟ 1062A oder das Feld „Verschiebungsskalierung‟ 1062B auf.

Vektorspeicheranweisungen führen Vektorlasten aus dem Arbeitsspeicher aus und der Vektor speichert in den Arbeitsspeicher, mit Konvertierungsunterstützung. Wie bei regulären Vektoranweisungen übertragen Vektorspeicheranweisungen Daten datenelementweise aus dem/in den Arbeitsspeicher, wobei die Elemente, die tatsächlich übertragen werden, durch den Inhalt der Vektormaske diktiert werden, die als die Schreibmaske ausgewählt ist.

Anweisungsvorlagen mit Arbeitsspeicherzugriff - Temporär

Temporäre Daten sind Daten, die wahrscheinlich so schnell wieder verwendet werden, dass sie von Caching profitieren würden. Dies ist jedoch lediglich ein Hinweis, und unterschiedliche Prozessoren können ihn auf unterschiedliche Weise implementieren, einschließlich des vollständigen Ignorierens des Hinweises.

Anweisungsvorlagen mit Arbeitsspeicherzugriff - Nichttemporär

Nichttemporäre Daten sind Daten, die wahrscheinlich nicht so schnell wieder verwendet werden, als dass sie von Caching im Level-1-Cache profitieren würden, und ihnen sollte Priorität bei der Räumung eingeräumt werden. Dies ist jedoch lediglich ein Hinweis, und unterschiedliche Prozessoren können ihn auf unterschiedliche Weise implementieren, einschließlich des vollständigen Ignorierens des Hinweises.

Anweisungsvorlagen der Klasse B

Im Fall der Anweisungsvorlagen der Klasse B wird das Feld „Alpha‟ 1052 als ein Feld „Schreibmaskensteuerung (Z)‟ 1052C interpretiert, dessen Inhalt unterscheidet, ob die Schreibmaske, die durch das Feld „Schreibmaskensteuerung‟ 1070 gesteuert wird, verschmelzend oder auf Null setzend sein sollte.

Im Fall der Anweisungsvorlagen der Klasse B ohne Arbeitsspeicherzugriff 1005 wird ein Teil des Feldes „Beta‟ 1054 als ein Feld „RL‟ 1057A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Zusatzoperationstypen durchgeführt werden soll (z.B. sind Rundung 1057A.1 und Vektorlänge (V-GRÖSSE) 1057A.2 entsprechend für die Anweisungsvorlage für die Schreibmaskensteuerungsoperation des Teilrundungssteuertyps ohne Arbeitsspeicherzugriff 1012 und die Anweisungsvorlage für die Schreibmaskensteuerungsoperation des V-GRÖSSEN-Typs ohne Arbeitsspeicherzugriff 1017 spezifiziert), während der Rest des Feldes „Beta‟ 1054 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. Bei den Anweisungsvorlagen ohne Arbeitsspeicherzugriff 1005 liegen das Feld „Skalierung‟ 1060, das Feld ‚Verschiebung‘ 1062A und das Feld „Verschiebungsskalierung‟ 1062B nicht vor.

Bei der Anweisungsvorlage für die Schreibmaskenoperation des Teilrundungssteuerungstyps ohne Arbeitsspeicherzugriff 1010 wird der Rest des Feldes „Beta‟ 1054 als ein Feld „Rundungsoperation‟ 1059A interpretiert und die Ausnahmeereignismeldung ist deaktiviert (eine gegebene Anweisung meldet keinerlei Gleitkommaausnahme-Flag und aktiviert keinen Gleitkommaausnahme-Handler).

Feld „Rundungsoperationssteuerung‟ 1059A - wie das Feld „Rundungsoperationssteuerung‟ 1058 unterscheidet sein Inhalt, welche aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z.B. Aufrunden, Abrunden, Runden-gegen-Null und Runden-zum-Nächsten). Somit gestattet das Feld „Rundungsoperationssteuerung‟ 1059A die Veränderung des Rundungsmodus auf einer Pro-Anweisung-Basis. In einer Ausführungsform der Offenbarung, in welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi aufweist, hebt der Inhalt des Feldes „Rundungsoperationssteuerung‟ 1050 diesen Registerwert auf.

Bei der Anweisungsvorlage für die Schreibmaskensteuerungsoperation des V-GRÖSSEN-Typs ohne Arbeitsspeicherzugriff 1017 wird der Rest des Feldes „Beta‟ 1054 als ein Feld „Vektorlänge‟ 1059B interpretiert, dessen Inhalt unterscheidet, welche aus einer Reihe von Datenvektorlängen für die Durchführung verwendet werden soll (z.B. 128, 256 oder 512 Bytes).

Im Fall einer Anweisungsvorlage der Klasse B mit Arbeitsspeicherzugriff 1020 wird ein Teil des Feldes „Beta‟ 1054 als ein Feld „Übertragung‟ 1057B interpretiert, dessen Inhalt unterscheidet, ob die Datenmanipulationsoperation des Übertragungstyps durchgeführt werden soll oder nicht, während der Rest des Feldes „Beta‟ 1054 als das Feld „Vektorlänge‟ 1059B interpretiert wird. Die Anweisungsvorlagen mit Arbeitsspeicherzugriff 1020 weisen das Feld „Skalierung‟ 1060 und wahlweise das Feld ‚Verschiebung‘ 1062A oder das Feld „Verschiebungsskalierung‟ 1062B auf.

Bezüglich des generischen vektorfreundlichen Anweisungsformates 1000 ist das Feld „Vollständiger Opcode‟ 1074 als das Feld ,Format' 1040, das Feld „Basisoperation‟ 1042 und das Feld „Datenelementbreite‟ 1064 aufweisend gezeigt. Während eine Ausführungsform gezeigt ist, in welcher das Feld „Vollständiger Opcode‟ 1074 alle dieser Felder aufweist, weist das Feld „Vollständiger Opcode‟ 1074 in Ausführungsformen, die nicht alle von ihnen unterstützen, weniger als alle dieser Felder auf. Das Feld „Vollständiger Opcode‟ 1074 stellt den Operationscode (Opcode) zur Verfügung.

Das Feld „Zusatzoperation‟ 1050, das Feld „Datenelementbreite‟ 1064 und das Feld „Schreibmaske‟ 1070 gestatten das Spezifizieren dieser Merkmale auf einer Pro-Anweisung-Basis im generischen vektorfreundlichen Anweisungsformat.

Die Kombination des Feldes „Schreibmaske‟ und des Feldes „Datenelementbreite‟ erstellt dahingehend typisierte Anweisungen, dass sie das Anwenden der Maske basierend auf unterschiedlichen Datenelementbreiten gestattet.

Die verschiedenen Anweisungsvorlagen innerhalb von Klasse A und Klasse B sind in unterschiedlichen Situationen vorteilhaft. In einigen Ausführungsformen der Offenbarung unterstützen unterschiedliche Prozessoren oder unterschiedliche Kerne innerhalb eines Prozessors möglicherweise nur Klasse A, nur Klasse B oder beide Klassen. Zum Beispiel unterstützt ein nicht-sequentieller Hochleistungsuniversalkern, der für die Universalberechnung gedacht ist, möglicherweise nur Klasse B, ein Kern, der primär für Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung gedacht ist, unterstützt möglicherweise nur Klasse A, und ein Kern, der für beides gedacht ist, unterstützt möglicherweise beide (natürlich liegt ein Kern, der eine Mischung aus Vorlagen und Anweisungen aus beiden Klassen, jedoch nicht alle Vorlagen und Anweisungen aus beiden Klassen aufweist, innerhalb des Geltungsbereiches der Offenbarung). Auch kann ein einzelner Prozessor mehrere Kerne aufweisen, von welchen alle die gleiche Klasse unterstützen, oder in welchem unterschiedliche Kerne eine unterschiedliche Klasse unterstützen. Zum Beispiel unterstützt in einem Prozessor mit separaten Grafik- und Universalkernen einer der Grafikkerne, der primär für die Grafik- und/oder wissenschaftliche Berechnung gedacht ist, möglicherweise nur Klasse A, während es sich bei einem oder mehreren der Universalkerne um Hochleistungsuniversalkerne mit nicht-sequentieller Ausführung und Registerumbenennung, bestimmt für die Universalberechnung, handeln kann, die nur Klasse B unterstützen. Ein weiterer Prozessor, der keinen separaten Grafikkern aufweist, weist möglicherweise einen weiteren sequentiellen oder nicht-sequentiellen Universalkern auf, der sowohl Klasse A als auch Klasse B unterstützt. Natürlich können in unterschiedlichen Ausführungsformen der Offenbarung Merkmale aus einer Klasse auch in der anderen Klasse implementiert werden. Programme, die in einer Hochsprache geschrieben sind, würden in eine Vielzahl unterschiedlicher ausführbarer Formen umgewandelt (z.B. JIT-kompiliert oder statisch kompiliert) werden, einschließlich: 1) einer Form, die nur Anweisungen der Klasse(n) aufweist, die durch den Zielprozessor zur Ausführung unterstützt wird/werden; oder 2) einer Form, die alternative Programme aufweist, die unter Verwendung unterschiedlicher Kombinationen der Anweisungen aller Klassen geschrieben sind und Steuerflusscode aufweisen, der die Programme zur Ausführung basierend auf den Anweisungen, die durch den Prozessor unterstützt werden, welcher den Code gerade ausführt, auswählt.

Beispielhaftes spezifisches vektorfreundliches Anweisungsformat

11 ist ein Blockdiagramm, welches ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Offenbarung veranschaulicht. 11 zeigt ein spezifisches vektorfreundliches Anweisungsformat 1100, welches insofern spezifisch ist, dass es den Standort, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Anweisungsformat 1100 kann zum Erweitern des x86-Anweisungssatzes verwendet werden, und somit sind einige der Felder ähnlich oder die gleichen wie diejenigen, die im bestehenden x86-Anweisungssatz und Erweiterungen davon (z.B. AVX) verwendet werden. Dieses Format bleibt in Einklang mit dem Feld „Präfixcodierung‟, dem Feld „Reales Opcode-Byte‟, dem Feld „MOD R/M‟, dem Feld „SIB‟, dem Feld ‚Verschiebung‘ und dem Feld „Direkt‟ des bestehenden x86-Anweisungssatzes mit Erweiterungen. Die Felder aus 10, in welche die Felder aus 11 abgebildet werden, sind veranschaulicht.

Es sollte verstanden werden, dass, obwohl Ausführungsformen der Offenbarung zu veranschaulichenden Zwecken unter Bezugnahme auf das spezifische vektorfreundliche Anweisungsformat 1100 im Kontext des generischen vektorfreundlichen Anweisungsformates 1000 beschrieben sind, die Offenbarung nicht auf das spezifische vektorfreundliche Anweisungsformat 1100 beschränkt ist, außer wo dies beansprucht ist. Zum Beispiel zieht das generische vektorfreundliche Anweisungsformat 1000 eine Vielzahl möglicher Größen für die verschiedenen Felder in Betracht, während das spezifische vektorfreundliche Anweisungsformat 1100 als Felder spezifischer Größen aufweisend gezeigt ist. Als ein spezifisches Beispiel ist, während das Feld „Datenelementbreite‟ 1064 im spezifischen vektorfreundlichen Anweisungsformat 1100 als ein Ein-Bit-Feld veranschaulicht ist, die Offenbarung nicht dahingehend eingeschränkt (d.h., das generische vektorfreundliche Anweisungsformat 1000 zieht auch andere Größen des Feldes „Datenelementbreite‟ 1064 in Betracht).

Das generische vektorfreundliche Anweisungsformat 1000 weist die folgenden Felder auf, unten aufgeführt in der in 11A veranschaulichten Reihenfolge.

EVEX-Präfix (Bytes 0-3) 1102 - ist in einer Vier-Byte-Form codiert.

Feld „Format‟ 1040 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Feld „Format‟ 1040 und es enthält 0x62 (der eindeutige Wert, der in einer Ausführungsform der Offenbarung zum Unterscheiden des vektorfreundlichen Anweisungsformates verwendet wird).

Das zweite bis vierte Byte (EVEX-Bytes 1-3) weisen eine Reihe von Bitfeldern auf, die spezifische Fähigkeiten bereitstellen.

Feld „REX‟ 1105 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem Bitfeld „EVEX.R‟ (EVEX-Byte 1, Bit [7] - R), einem Bitfeld „EVEX.X‟ (EVEX-Byte 1, Bit [6] - X) und einem Bitfeld „EVEX.B‟ (EVEX-Byte 1, Bit [5] - B). Die Bitfelder „EVEX.R‟, „EVEX.X‟ und „EVEXB‟ stellen die gleiche Funktionalität wie die entsprechenden Bitfelder „VEX‟ zur Verfügung und sind unter Verwendung einer 1s-Komplement-Form codiert, d.h. ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Anweisungen codieren die unteren drei Bits der Registerindexe wie in der Technik bekannt ist (rrr, xxx und bbb), derart, dass Rrrr, Xxxx und Bbbb durch das Hinzufügen von EVEX.R, EVEX.X und EVEX.B gebildet werden können.

Feld „REX‟ 1010 - dies ist der erste Teil des Feldes „REX‟ 1010 und ist das Bitfeld „EVEX.R‟ (EVEX-Byte 1, Bit [4] - R'), das zum Codieren entweder der oberen 16 oder unteren 16 des erweiterten 32-Registersatzes verwendet wird. In einer Ausführungsform der Offenbarung ist dieses Bit, zusammen mit anderen, wie unten angegeben, in einem Bit-invertierten Format gespeichert, um es (im gut bekannten x86 32-Bit-Modus) von der Anweisung BOUND zu unterscheiden, deren reales Opcode-Byte 62 ist, akzeptiert jedoch im Feld „MOD R/M‟ (unten beschrieben) nicht den Wert 11 im Feld „MOD‟; alternative Ausführungsformen der Offenbarung speichern dieses und die anderen angegebenen Bits unten im invertierten Format nicht. Ein Wert von 1 wird zum Codieren der unteren 16 Register verwendet. Mit anderen Worten, R'Rrrr wird durch das Kombinieren von EVEX.R', EVEX.R und den anderen RRR aus anderen Feldern gebildet.

Feld „Opcode-Abbildung‟ 1115 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein implizites führendes Opcode-Byte (0F, 0F 38 oder 0F 3).

Feld „Datenelementbreite‟ 1064 (EVEX-Byte 2, Bit [7] - W) - ist durch die Notation EVEX.W dargestellt. EVEX.W wird zum Definieren der Granularität (Größe) des Datentyps verwendet (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).

EVEX.vvvv 1120 (EVEX-Byte 2, Bits [6:3] - vvvv) - die Rolle von EVEX.vvvv kann Folgendes beinhalten: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, spezifiziert in invertierter (1s-Komplement) Form, und ist gültig für Anweisungen mit 2 oder mehr Quelloperanden; 2) EVEX.vvvv codiert den Zielregisteroperanden, spezifiziert in 1s-Komplement-Form für bestimmte Vektorverschiebungen; oder 3) EVEX.vvvv codiert keinerlei Operanden, das Feld ist reserviert und sollte 1111b enthalten. Somit codiert das Feld „EVEX.vvvv‟ 1120 die 4 niederwertigen Bits des ersten Quellregister-Spezifikators, gespeichert in invertierter (1s-Komplement) Form. In Abhängigkeit von der Anweisung wird ein zusätzliches unterschiedliches Bitfeld „EVEX‟ verwendet, um die Größe des Spezifikators auf 32 Register zu erweitern.

Klassenfeld „EVEX.U‟ 1068 (EVEX-Byte 2, Bit [2] - U) - wenn EVEX.U = 0, gibt es Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, gibt es Klasse B oder EVEX.U1 an.

Feld „Präfixcodierung‟ 1125 (EVEX-Byte 2, Bits [1:0] - pp) - stellt zusätzliche Bits für das Feld „Basisoperation‟ zur Verfügung. Zusätzlich zum Bereitstellen von Unterstützung für die älteren SSE-Anweisungen im EVEX-Präfixformat, hat dies auch den Vorteil des Komprimierens des SIMD-Präfixes (anstatt ein Byte zum Ausdrücken des SIMD-Präfixes zu erfordern, erfordert der EVEX-Präfix lediglich 2 Bits). In einer Ausführungsform werden, zum Unterstützen älterer SSE-Anweisungen, die einen SIMD-Präfix (66H, F2H, F3H) sowohl in dem älteren Format als auch im EVEX-Präfixformat verwenden, diese älteren SIMD-Präfixe in das Feld „SIMD-Präfixcodierung‟ codiert, und während der Laufzeit werden sie in den älteren SIMD-Präfix erweitert, bevor sie an das PLA der Decodierungsschaltung bereitgestellt werden (damit das PLA sowohl das ältere als auch das EVEX-Format dieser älteren Anweisungen ohne Modifikation ausführen kann). Obwohl neuere Anweisungen den Inhalt des Feldes „EVEX-Präfixcodierung‟ direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen der Einheitlichkeit halber in ähnlicher Weise, gestatten jedoch, dass durch diese älteren SIMD-Präfixe unterschiedliche Bedeutungen spezifiziert werden. Eine alternative Ausführungsform kann das PLA derart umgestalten, dass es die 2-Bit-SIMD-Präfixcodierungen unterstützt und somit die Erweiterung nicht benötigt.

Feld „Alpha‟ 1052 (EVEX-Byte 3, Bit [7] - EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX. Schreibmaskensteuerung und EVEX.N; auch veranschaulicht mit α) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.

Feld „Beta‟ 1054 (EVEX-Byte 3, Bits [6:4] - SSS; auch bekannt als EVEX.S₂-₀, EVEX.r₂-₀, EVEX.rr1, EVEX.LL0, EVEX.LLB; auch veranschaulicht mit βββ) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.

Feld „REX‟ 1010 - dies ist der Rest des Feldes „REX‟ und ist das Bitfeld „EVEX.V‟ (EVEX-Byte 3, Bit [3] - V'), das zum Codieren entweder der oberen 16 oder unteren 16 des erweiterten 32-Registersatzes verwendet werden kann. Dieses Bit ist im Bit-invertierten Format gespeichert. Ein Wert von 1 wird zum Codieren der unteren 16 Register verwendet. Mit anderen Worten, V'VVVV wird durch das Kombinieren von EVEX.V' und EVEX.vvvv gebildet.

Feld „Schreibmaske‟ 1070 (EVEX-Byte 3, Bits [2:0] - kkk) - sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie zuvor beschrieben. In einer Ausführungsform der Offenbarung weist der spezifische Wert EVEX.kkk=000 ein spezielles Verhalten auf, welches impliziert, dass keine Schreibmaske für die bestimmte Anweisung verwendet wird (dies kann in einer Vielzahl von Möglichkeiten implementiert werden, einschließlich der Verwendung einer Schreibmaske, die für alles Einsen festverdrahtet ist, oder Hardware, welche die Maskierungshardware umgeht).

Feld „Realer Opcode‟ 1130 (Byte 4) - auch bekannt als das Opcode-Byte. Ein Teil des Opcodes ist in diesem Feld spezifiziert.

Feld „MOD R/M‟ 1140 (Byte 5) - beinhaltet das Feld „MOD‟ 1142, das Feld „Reg‟ 1144 und das Feld „R/M‟ 1146. Wie zuvor beschrieben, unterscheidet der Inhalt des Feldes „MOD‟ 1142 zwischen Operationen mit Arbeitsspeicherzugriff und ohne Arbeitsspeicherzugriff. Die Rolle des Feldes „Reg‟ 1144 kann auf zwei Situationen zusammengefasst werden: das Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden oder die Behandlung als eine Opcode-Erweiterung und nicht verwendet zum Codieren jegliches Anweisungsoperanden. Die Rolle des Feldes „R/M‟ 1146 kann Folgendes beinhalten: das Codieren des Anweisungsoperanden, der auf eine Arbeitsspeicheradresse verweist, oder das Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden.

SIB (Skalierung, Index, Basis) -Byte (Byte 6) - Wie zuvor beschrieben, wird der Inhalt des Feldes „Skalierung‟ 1050 zur Arbeitsspeicheradresserzeugung verwendet. SIB.xxx 1154 und SIB.bbb 1156 - auf den Inhalt dieser Felder wurde zuvor in Bezug auf die Registerindexe Xxxx und Bbbb verwiesen.

Feld „Verschiebung‟ 1062A (Bytes 7-10) - wenn das Feld „MOD‟ 1142 10 enthält, sind die Bytes 7-10 das Feld ‚Verschiebung‘ 1062A, und es funktioniert genauso wie die ältere 32-Bit-Verschiebung (disp32) und arbeitet mit Byte-Granularität.

Feld „Verschiebungsfaktor‟ 1062B (Byte 7) - wenn das Feld „MOD‟ 1142 01 enthält, ist Byte 7 das Feld „Verschiebungsfaktor‟ 1062B. Der Standort dieses Feldes ist der gleiche wie die 8-Bit-Verschiebung (disp8) des älteren x86-Anweisungssatzes, welcher mit Byte-Granularität arbeitet. Da disp8 zeichenerweitert ist, kann nur Versatz zwischen -128 und 127 Bytes adressiert werden; hinsichtlich 64-Byte-Cache-Zeilen verwendet disp8 8 Bits, die nur auf die vier wirklich nützlichen Werte -128, -64, 0 und 64 eingestellt werden können; da häufig ein größerer Bereich benötigt wird, wird disp32 verwendet; jedoch erfordert disp32 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Feld „Verschiebungsfaktor‟ 1062B eine Neuinterpretation von disp8; wenn das Feld „Verschiebungsfaktor‟ 1062B verwendet wird, wird die tatsächliche Verschiebung durch den Inhalt des Feldes „Verschiebungsfaktor‟ multipliziert mit der Größe des Arbeitsspeicherzugriffsoperanden (N) bestimmt. Diese Art der Verschiebung wird als disp8*N bezeichnet. Dies verringert die durchschnittliche Anweisungslänge (es wird ein einzelnes Byte für die Verschiebung verwendet, jedoch mit einem viel größeren Bereich). Eine derartige komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Multiples der Granularität des Arbeitsspeicherzugriffs ist, und daher müssen die redundanten niederwertigen Bits des Adressversatzes nicht codiert werden. Mit anderen Worten, das Feld „Verschiebungsfaktor‟ 1062B substituiert die 8-Bit-Verschiebung des älteren x86-Anweisungssatzes. Somit wird das Feld „Verschiebungsfaktor‟ 1062B auf die gleiche Weise codiert wie eine 8-Bit-Verschiebung des x86-Anweisungssatzes (also keine Veränderungen in den ModRM/SIB-Codierungsregeln), mit der einzigen Ausnahme, dass disp8 zu disp8*N wird. Mit anderen Worten, es gibt keine Veränderungen in den Codierungsregeln oder Codierungslängen, sondern lediglich in der Interpretation des Verschiebungswertes durch die Hardware (welche die Verschiebung um die Größe des Arbeitsspeicheroperanden skalieren muss, um einen byteweisen Adressversatz zu erhalten). Das Feld „Direkt‟ 1072 arbeitet wie zuvor beschrieben.

Feld „Vollständiger Opcode‟

11B ist ein Blockdiagramm, welches die Felder des spezifischen vektorfreundlichen Anweisungsformates 1100 veranschaulicht, aus denen das Feld „Vollständiger Opcode‟ 1074 gemäß einer Ausführungsform der Offenbarung besteht. Spezifisch beinhaltet das Feld „Vollständiger Opcode‟ 1074 das Feld „Format‟ 1040, das Feld „Basisoperation‟ 1042 und das Feld „Datenelementbreite‟ (W) 1064. Das Feld „Basisoperation‟ 1042 beinhaltet das Feld „Präfixcodierung‟ 1125, das Feld „Opcode-Abbildung‟ 1115 und das Feld „Realer Opcode‟ 1130.

Feld „Registerindex‟

11C ist ein Blockdiagramm, welches die Felder des spezifischen vektorfreundlichen Anweisungsformates 1100 veranschaulicht, aus denen das Feld „Registerindex‟ 1044 gemäß einer Ausführungsform der Offenbarung besteht. Spezifisch beinhaltet das Feld „Registerindex‟ 1044 das Feld „REX‟ 1105, das Feld „REX‟ 1110, das Feld „MODR/M.reg‟ 1144, das Feld „MODR/M.r/m‟ 1146, das Feld ,VVVV` 1120, das Feld „xxx‟ 1154 und das Feld „bbb‟ 1156.

Feld „Zusatzoperation‟

11D ist ein Blockdiagramm, welches die Felder des spezifischen vektorfreundlichen Anweisungsformates 1100 veranschaulicht, aus denen das Feld „Zusatzoperation‟ 1050 gemäß einer Ausführungsform der Offenbarung besteht. Wenn das Feld „Klasse‟ (U) 1068 0 enthält, bedeutet es EVEX.U0 (Klasse A 1068A); wenn es 1 enthält, bedeutet es EVEX.U1 (Klasse B 1068B). Wenn U=0 und das Feld „MOD‟ 1142 11 enthält (was eine Operation ohne Arbeitsspeicherzugriff bedeutet), wird das Feld ,Alpha` 1052 (EVEX-Byte 3, Bit [7] - EH) als das Feld ,rs' 1052A interpretiert. Wenn das Feld ,rs' 1052A eine 1 enthält (Rundung 1052A. 1), wird das Feld „Beta‟ 1054 (EVEX-Byte 3, Bits [6:4] - SSS) als das Feld „Rundungssteuerung‟ 1054A interpretiert. Das Feld „Rundungssteuerung‟ 1054A weist ein Ein-Bit-Feld „SAE‟ 1056 und ein Zwei-Bit-Feld „Rundungsoperation‟ 1058 auf. Wenn das Feld ,rs' 1052A eine 0 enthält (Datentransformation 1052A.2), wird das Feld „Beta‟ 1054 (EVEX-Byte 3, Bits [6:4] - SSS) als ein Drei-Bit-Feld „Datentransformation‟ 1054B interpretiert. Wenn U=0 und das Feld „MOD‟ 1142 00, 01 oder 10 enthält (was eine Operation mit Arbeitsspeicherzugriff bedeutet), wird das Feld „Alpha‟ 1052 (EVEX-Byte 3, Bit [7] - EH) als das Feld ,Räumungshinweis' (EH) 1052B interpretiert und das Feld „Beta‟ 1054 (EVEX-Byte 3, Bits [6:4] - SSS) wird als ein Drei-Bit-Feld „Datenmanipulation‟ 1054C interpretiert.

Wenn U=1, wird das Feld „Alpha‟ 1052 (EVEX-Byte 3, Bit [7] - EH) als das Feld „Schreibmaskensteuerung‟ (Z) 1052C interpretiert. Wenn U=1 und das Feld „MOD‟ 1142 11 enthält (was eine Operation ohne Arbeitsspeicherzugriff bedeutet), wird ein Teil des Feldes „Beta‟ 1054 (EVEX-Byte 3, Bit [4] - So) als das Feld „RL‟ 1057A interpretiert; wenn es eine 1 enthält (Rundung 1057A.1), wird der Rest des Feldes „Beta‟ 1054 (EVEX-Byte 3, Bit [6-5] - S_2-1) als das Feld „Rundungsoperation‟ 1059A interpretiert, während, wenn das Feld „RL‟ 1057A eine 0 enthält (VGRÖSSE 1057.A2), der Rest des Feldes „Beta‟ 1054 (EVEX-Byte 3, Bit [6-5] - S_2-1) als das Feld „Vektorlänge‟ 1059B (EVEX-Byte 3, Bit [6-5] - L₁ ^_ ₀) interpretiert wird. Wenn U=1 und das Feld „MOD‟ 1142 00, 01 oder 10 enthält (was eine Operation mit Arbeitsspeicherzugriff bedeutet), wird das Feld „Beta‟ 1054 (EVEX-Byte 3, Bits [6:4] - SSS) als das Feld „Vektorlänge‟ 1059B (EVEX-Byte 3, Bit [6-5] - L_1-0) und das Feld „Übertragung‟ 1057B (EVEX-Byte 3, Bit [4] - B) interpretiert.

Beispielhafte Registerarchitektur

12 ist ein Blockdiagramm einer Registerarchitektur 1200 gemäß einer Ausführungsform der Offenbarung. In der veranschaulichten Ausführungsform liegen 32 Vektorregister 1210 vor, die 512 Bits breit sind; diese Register sind als zmm0 bis zmm31 referenziert. Die niederwertigen 256 Bits der unteren 16 zmm-Register sind über die Register ymm0-16 gelegt. Die niederwertigen 128 Bits der unteren 16 zmm-Register (die niederwertigen 128 Bits der ymm-Register) sind über die Register xmm0-15 gelegt. Das spezifische vektorfreundliche Anweisungsformat 1100 arbeitet mit dieser überlagerten Registerdatei wie in der Tabelle unten veranschaulicht.

Einstellbare Vektorlänge	Klasse	Operationen	Register
Anweisungsvorlagen, die das Feld „Vektorlänge‟ 1059B nicht beinhalten	A ( 10A; U=0)	1010, 1015, 1025, 1030	zmm-Register (die Vektorlänge beträgt 64 Bytes)
	B ( 10B; U=1)	1012	zmm-Register (die Vektorlänge beträgt 64 Bytes)
Anweisungsvorlagen, die das Feld „Vektorlänge‟ 1059B beinhalten	B ( 10B; U=1)	1017, 1027	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Bytes, 32 Bytes oder 16 Bytes), in Abhängigkeit vom Feld „Vektorlänge‟ 1059B

Mit anderen Worten, das Feld „Vektorlänge‟ 1059B wählt zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede derartige kürzere Länge die Hälfte der Länge der vorhergehenden Länge ist; und Anweisungsvorlagen ohne das Feld „Vektorlänge‟ 1059B arbeiten mit der maximalen Vektorlänge. Außerdem arbeiten in einer Ausführungsform die Klasse-B-Anweisungsvorlagen des spezifischen vektorfreundlichen Anweisungsformates 1100 mit gepackten oder Skalar-Gleitkommadaten mit einfacher/doppelter Genauigkeit und gepackten oder Skalar-Ganzzahldaten. Skalaroperationen sind Operationen, die an der niederwertigsten Datenelementposition in einem zmm/ymm/xmm-Register durchgeführt werden; die höherwertigen Datenelementpositionen werden entweder so gelassen, wie sie vor der Anweisung waren, oder auf Null gesetzt, in Abhängigkeit von der Ausführungsform.

Schreibmaskenregister 1215 - in der veranschaulichten Ausführungsform liegen 8 Schreibmaskenregister vor (k0 bis k7), jeweils mit einer Größe von 64 Bits. In einer alternativen Ausführungsform weisen die Schreibmaskenregister 1215 eine Größe von 16 Bits auf. Wie zuvor beschrieben, kann in einer Ausführungsform der Offenbarung das Vektormaskenregister k0 nicht als eine Schreibmaske verwendet werden; wenn die Codierung angibt, dass normalerweise k0 als eine Schreibmaske verwendet werden würde, wird eine festverdrahtete Schreibmaske OxFFFF ausgewählt, wodurch effektiv die Schreibmaskierung für diese Anweisung deaktiviert wird.

Universalregister 1225 - in der veranschaulichten Ausführungsform liegen sechzehn 64-Bit-Universalregister vor, die zusammen mit den bestehenden x86-Adressierungsmodi zum Adressieren von Arbeitsspeicheroperanden verwendet werden. Diese Register sind durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 referenziert.

Skalar-Gleitkomma-Stapelregisterdatei (x87-Stapel) 1245, auf welcher die gepackte MMX-Ganzzahl-Flachregisterdatei 1250 aliasiert ist - in der veranschaulichten Ausführungsform ist der x87-Stapel ein Acht-Element-Stapel, der zum Durchführen von Skalar-Gleitkomma-Operationen an 32/64/80-Bit-Gleitkommadaten unter Verwendung der x87-Anweisungssatzerweiterung verwendet wird; während die MMX-Register zum Durchführen von Operationen an gepackten 64-Bit-Ganzzahldaten verwendet werden, enthalten sie auch Operanden für einige Operationen, die zwischen den MMX- und XMM-Registern durchgeführt werden.

Alternative Ausführungsformen der Offenbarung können breitere oder schmalere Register verwenden. Außerdem können alternative Ausführungsformen der Offenbarung mehr, weniger oder unterschiedliche Registerdateien und Register verwenden.

Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen

Prozessorkerne können auf unterschiedliche Weise, für unterschiedliche Zwecke und in unterschiedlichen Prozessoren implementiert werden. Zum Beispiel können Implementierungen derartiger Kerne Folgendes aufweisen: 1) einen sequentiellen Universalkern, der für die Universalberechnung bestimmt ist; 2) einen nicht-sequentiellen Hochleistungsuniversalkern, der für die Universalberechnung bestimmt ist; 3) einen Spezialkern, der primär für die Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung bestimmt ist. Zu Implementierungen unterschiedlicher Prozessoren können Folgende zählen: 1) eine CPU, die einen oder mehrere sequentielle Universalkerne, bestimmt für die Universalberechnung, und/oder einen oder mehrere nicht-sequentielle Universalkerne, bestimmt für die Universalberechnung, aufweist; und 2) ein Co-Prozessor, der einen oder mehrere Spezialkerne, primär bestimmt für die Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung, aufweist. Derartige unterschiedliche Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, zu welchen Folgende zählen können: 1) der Co-Prozessor auf einem separaten Chip von der CPU; 2) der Co-Prozessor auf einem separaten Die im gleichen Package wie eine CPU; 3) der Co-Prozessor auf dem gleichen Die wie eine CPU (wobei in diesem Fall ein derartiger Co-Prozessor gelegentlich als Speziallogik, wie z.B. integrierte Grafik- und/oder wissenschaftliche (Durchsatz-) Logik, oder als Spezialkerne bezeichnet wird); und 4) ein Ein-Chip-System, das die beschriebene CPU (gelegentlich als der (die) Anwendungskern(e) oder der (die) Anwendungsprozessor(en) bezeichnet), den oben beschriebenen Co-Prozessor und zusätzliche Funktionalität auf dem gleichen Die aufweisen kann. Beispielhafte Kernarchitekturen werden als nächstes beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computerarchitekturen.

Beispielhafte Kernarchitekturen

Blockdiagramm eines sequentiellen und nicht-sequentiellen Kerns

13A ist ein Blockdiagramm, welches sowohl eine beispielhafte sequentielle Pipeline als auch eine beispielhafte nicht-sequentielle Ausgabe/Ausführungs-Pipeline mit Registerumbenennung gemäß Ausführungsformen der Offenbarung veranschaulicht. 13B ist ein Blockdiagramm, welches sowohl eine beispielhafte Ausführungsform eines sequentiellen Architekturkerns als auch einen beispielhaften nicht-sequentiellen Ausgabe/Ausführungs-Architekturkern mit Registerumbenennung, die in einem Prozessor enthalten sein sollen, gemäß Ausführungsformen der Offenbarung veranschaulicht. Die Kästchen mit durchgezogenen Linien in 13A - B veranschaulichen die sequentielle Pipeline und den sequentiellen Kern, während die optional hinzugefügten Kästchen mit gestrichelten Linien die nicht-sequentielle Ausgabe/Ausführungs-Pipeline mit Registerumbenennung und den entsprechenden Kern veranschaulichen. Angesichts der Tatsache, dass der sequentielle Aspekt eine Teilmenge des nicht-sequentiellen Aspektes ist, wird der nicht-sequentielle Aspekt beschrieben.

In 13A weist eine Prozessor-Pipeline 1300 eine Abrufstufe 1302, eine Längendecodierungsstufe 1304, eine Decodierungsstufe 1306, eine Zuteilungsstufe 1308, eine Umbenennungsstufe 1310, eine Zeitplanungsstufe (auch bekannt als eine Versand- oder Ausgabestufe) 1312, eine Register-Lese-/Arbeitsspeicher-Lesestufe 1314, eine Ausführungsstufe 1316, eine Rückschreib-/Arbeitsspeicher-Schreibstufe 1318, eine Ausnahmebehandlungsstufe 1322 und eine Festlegungsstufe 1324 auf.

13B zeigt den Prozessorkern 1390 einschließlich einer Frontend-Einheit 1330, die an eine Ausführungsmaschineneinheit 1350 gekoppelt ist, welche beide an eine Arbeitsspeichereinheit 1370 gekoppelt sind. Der Kern 1390 kann ein RISC (Reduced Instruction Set Computing) -Kern, ein CISC (Complex Instruction Set Computing) -Kern, ein VLIW (Very Long Instruction Word) -Kern oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 1390 ein Spezialkern sein, wie zum Beispiel ein Netzwerk- oder Kommunikationskern, eine Komprimierungsmaschine, ein Co-Prozessorkern, ein GPGPU (General Purpose Computing Graphics Processing Unit) -Kern, ein Grafikkern oder dergleichen.

Die Frontend-Einheit 1330 weist eine Verzweigungsvorhersage-Einheit 1332 gekoppelt an eine Anweisungs-Cache-Einheit 1334 auf, welche an einen Anweisungs-TLB (Translation Lookaside Buffer) 1336 gekoppelt ist, welcher an eine Anweisungsabrufeinheit 1338 gekoppelt ist, welche an eine Decodierungseinheit 1340 gekoppelt ist. Die Decodierungseinheit 1340 (z.B. eine Decodierungsschaltung) kann Anweisungen (z.B. Makroanweisungen) decodieren und erzeugt als eine Ausgabe ein/e/n oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale, welche aus den ursprünglichen Anweisungen decodiert werden, diese anderweitig reflektieren oder davon abgeleitet sind. Die Decodierungseinheit 1340 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Zu Beispielen geeigneter Mechanismen zählen, jedoch nicht darauf beschränkt, Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logik-Arrays (PLAs - Programmable Logic Arrays), Mikrocode-ROMs (Read Only Memories) usw. In einer Ausführungsform weist der Kern 1390 einen Mikrocode-ROM oder ein anderes Medium auf, das Mikrocode für bestimmte Makroanweisungen speichert (z.B. in der Decodierungseinheit 1340 oder anderweitig innerhalb der Frontend-Einheit 1330). Die Decodierungseinheit 1340 ist an eine Umbenennungs-/Zuteilungseinheit 1352 in der Ausführungsmaschineneinheit 1350 gekoppelt.

Die Ausführungsmaschineneinheit 1350 weist die Umbenennungs-/Zuteilungseinheit 1352 gekoppelt an eine Abschlusseinheit 1354 und einen Satz von einer oder mehreren Scheduler-Einheit(en) 1356 auf. Die Scheduler-Einheit(en) 1356 stellt/stellen jegliche Zahl von unterschiedlichen Schedulern dar, einschließlich Reservierungsstationen, eines zentralen Anweisungsfensters usw. Die Scheduler-Einheit(en) 1356 ist/sind an die physische(n) Registerdateieinheit(en) 1358 gekoppelt. Jede der physischen Registerdateieinheit(en) 1358 stellt eine oder mehrere physische Registerdateien dar, von welchen unterschiedliche einen oder mehrere Datentypen speichern, wie z.B. Skalar-Ganzzahl, Skalar-Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma, Status (z.B. ein Anweisungszeiger, bei welchem es sich um die Adresse der nächsten Anweisung handelt, die ausgeführt werden soll) usw. In einer Ausführungsform weist die physische Registerdateieinheit 1358 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit auf. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdateieinheit(en) 1358 wird/werden durch die Abschlusseinheit 1354 überlappt, um verschiedene Möglichkeiten zu veranschaulichen, in welchen Registerumbenennung und nicht-sequentielle Ausführung implementiert werden können (z.B. unter Verwendung (eines) von Neuordnungspuffers/n und (einer) von Abschlussregisterdatei(en); unter Verwendung (einer) von Zukunftsdatei(en), (eines) von Verlaufspuffers/n und (einer) von Abschlussregisterdatei(en); unter Verwendung (einer) von Registerabbildung(en) und eines Pools von Registern usw.). Die Abschlusseinheit 1354 und die physische(n) Registerdateieinheit(en) 1358 sind an das (die) Ausführungscluster 1360 gekoppelt. Das (Die) Ausführungscluster 1360 weist/weisen einen Satz von einer oder mehreren Ausführungseinheiten 1362 (z.B. Ausführungsschaltungen) und einen Satz von einer oder mehreren Arbeitsspeicherzugriffseinheiten 1364 auf. Die Ausführungseinheiten 1362 können verschiedene Operationen (z.B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Arten von Daten (z.B. Skalar-Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma) durchführen. Während einige Ausführungsformen eine Reihe von Ausführungseinheiten dediziert für spezifische Funktionen oder einen Satz von Funktionen aufweisen können, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten, die alle alle Funktionen durchführen, aufweisen. Die Scheduler-Einheit(en) 1356, die physische(n) Registerdateieinheit(en) 1358 und das/die Ausführungscluster 1360 sind als möglicherweise in der Mehrzahl vorliegend gezeigt, weil bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erstellen (z.B. eine Skalar-Ganzzahl-Pipeline, eine Skalar-Gleitkomma-Pipeline, eine gepackte Ganzzahl-Pipeline, eine gepacktes Gleitkomma-Pipeline, eine Vektorganzzahl-Pipeline, eine Vektorgleitkomma-Pipeline und/oder eine Arbeitsspeicherzugriff-Pipeline, die jeweils ihr/e eigene/s Scheduler-Einheit, physische Registerdateieinheit und/oder Ausführungscluster aufweisen - und im Fall einer separaten Arbeitsspeicherzugriff-Pipeline werden bestimmte Ausführungsformen implementiert, in welchen nur das Ausführungscluster dieser Pipeline die Arbeitsspeicherzugriffseinheit(en) 1364 aufweist). Es sollte auch verstanden werden, dass, wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines nicht-sequentielle Ausgabe-/Ausführungs-Pipelines sein können und der Rest sequentielle Pipelines sein können.

Der Satz von Arbeitsspeicherzugriffseinheiten 1364 ist an die Arbeitsspeichereinheit 1370 gekoppelt, welche eine Daten-TLB-Einheit 1372 gekoppelt an eine Daten-Cache-Einheit 1374 gekoppelt an eine L2 (Level 2) - Cache-Einheit 1376 aufweist. In einer beispielhaften Ausführungsform können die Arbeitsspeicherzugriffseinheiten 1364 eine Ladeeinheit, eine Adressspeichereinheit und eine Datenspeichereinheit aufweisen, von welchen jede an die Daten-TLB-Einheit 1372 in der Arbeitsspeichereinheit 1370 gekoppelt ist. Die Anweisungs-Cache-Einheit 1334 ist ferner an eine L2 (Level 2) -Cache-Einheit 1376 in der Arbeitsspeichereinheit 1370 gekoppelt. Die L2-Cache-Einheit 1376 ist an ein oder mehrere andere Level von Cache und schließlich an einen Hauptspeicher gekoppelt.

Beispielhaft kann die beispielhafte nicht-sequentielle Ausgabe-/Ausführungskernarchitektur mit Registerumbenennung die Pipeline 1300 wie Folgt implementieren: 1) die Anweisungsabrufeinheit 1338 führt die Abruf- und Längendecodierungsstufen 1302 und 1304 durch; 2) die Decodierungseinheit 1340 führt die Decodierungsstufe 1306 durch; 3) die Umbenennungs-/Zuteilungseinheit 1352 führt die Zuteilungsstufe 1308 und die Umbenennungsstufe 1310 durch; 4) die Scheduler-Einheit(en) 1356 führt/führen die Zeitplanungsstufe 1312 durch; 5) die physische(n) Registerdateieinheit(en) 1358 und die Arbeitsspeichereinheit 1370 führen die Registerlese-/Arbeitsspeicherlesestufe 1314 durch; das Ausführungscluster 1360 führt die Ausführungsstufe 1316 durch; 6) die Arbeitsspeichereinheit 1370 und die physische(n) Registerdateieinheit(en) 1358 führen die Rückschreib-/Arbeitsspeicherschreibstufe 1318 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsstufe 1322 beteiligt sein; und 8) die Abschlusseinheit 1354 und die physische(n) Registerdateieinheit(en) 1358 führen die Festlegungsstufe 1324 durch.

Der Kern 1390 kann einen oder mehrere Anweisungssätze unterstützen (z.B. den x86-Anweisungssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies aus Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen, wie z.B. NEON) von ARM Holdings aus Sunnyvale, CA), einschließlich der hierin beschriebenen Anweisung(en). In einer Ausführungsform weist der Kern 1390 Logik zum Unterstützen einer Anweisungssatzerweiterung für gepackte Daten auf (z.B. AVX1, AVX2), wodurch die Operationen gestattet werden, die durch viele Multimedia-Anwendungen, die unter Verwendung gepackter Daten durchzuführen sind, genutzt werden.

Es sollte verstanden werden, dass der Kern Multithreading (das Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies in einer Vielzahl von Möglichkeiten tun kann, einschließlich Zeitscheiben-Multithreading, gleichzeitiges Multithreading (wobei ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, für den der physische Kern gleichzeitiges Multithreading durchführt) oder eine Kombination davon (z.B. Abrufen und Decodieren in Zeitscheiben und danach gleichzeitiges Multithreading, wie z.B. bei der Intel® Hyper-Threading-Technologie).

Während die Registerumbenennung im Kontext der nicht-sequentiellen Ausführung beschrieben wird, sollte verstanden werden, dass die Registerumbenennung auch in einer sequentiellen Architektur zum Einsatz kommen kann. Während die veranschaulichte Ausführungsform des Prozessors auch separate Anweisungs- und Daten-Cache-Einheiten 1334/1374 und eine gemeinsam genutzte L2-Cache-Einheit 1376 aufweist, können alternative Ausführungsformen einen einzelnen internen Cache für sowohl Anweisungen als auch Daten aufweisen, wie zum Beispiel einen internen L1 (Level 1) -Cache oder mehrere Level von internem Cache. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Cache und einem externen Cache, der sich außerhalb des Kerns und/oder des Prozessors befindet, aufweisen. Alternativ dazu kann sich sämtlicher Cache außerhalb des Kerns und/oder des Prozessors befinden.

Spezifische beispielhafte sequentielle Kernarchitektur

14A - B veranschaulichen ein Blockdiagramm einer spezifischeren beispielhaften sequentiellen Kernarchitektur, wobei es sich bei dem Kern um einen von mehreren Logikblöcken (einschließlich anderer Kerne des gleichen Typs und/oder unterschiedlicher Typen) in einem Chip handeln würde. Die Logikblöcke kommunizieren über ein Zwischenverbindungsnetzwerk mit hoher Bandbreite (z.B. ein Ringnetzwerk) mit einiger Feste-Funktion-Logik, Arbeitsspeicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik, in Abhängigkeit von der Anwendung.

14A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung zum On-Die-Zwischenverbindungsnetzwerk 1402 und mit seiner lokalen Teilmenge des L2 (Level 2) -Caches 1404, gemäß Ausführungsformen der Offenbarung. In einer Ausführungsform unterstützt eine Anweisungsdecodierungseinheit 1400 den x86-Anweisungssatz mit einer Anweisungssatzerweiterung für gepackte Daten. Ein LI-Cache 1406 gestattet den Skalar- und Vektoreinheiten Zugriff mit geringer Latenz auf den Cache-Arbeitsspeicher. Während in einer Ausführungsform (zum Vereinfachen des Designs) eine Skalareinheit 1408 und eine Vektoreinheit 1410 separate Registersätze verwenden (die Skalarregister 1412 bzw. die Vektorregister 1414) und Daten, die zwischen ihnen übertragen werden, in Arbeitsspeicher geschrieben werden und dann aus einem L1 (Level 1) -Cache 1406 zurück eingelesen werden, können alternative Ausführungsformen der Offenbarung einen unterschiedlichen Ansatz verwenden (z.B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad aufweisen, der es gestattet, dass Daten zwischen den beiden Registerdateien übertragen werden, ohne geschrieben und zurückgelesen zu werden).

Die lokale Teilmenge des L2-Caches 1404 ist Teil eines globalen L2-Caches, der in separate lokale Teilmengen, eine pro Prozessorkern, unterteilt ist. Jeder Prozessorkern weist einen direkten Zugriffspfad zu seiner eigenen lokalen Teilmenge des L2-Caches 1404 auf. Daten, die durch einen Prozessorkern gelesen werden, werden in seiner L2-Cache-Teilmenge 1404 gespeichert und es kann schnell darauf zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Cache-Teilmengen zugreifen. Daten, die durch einen Prozessorkern geschrieben werden, werden in seiner eigenen L2-Cache-Teilmenge 1404 gespeichert und, falls nötig, aus anderen Teilmengen geleert. Das Ringnetzwerk stellt die Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetzwerk ist bidirektional, um es Agenten, wie z.B. Prozessorkernen, L2-Caches und anderen Logikblöcken, zu gestatten, innerhalb des Chips miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012 Bits breit.

14B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 14A gemäß Ausführungsformen der Offenbarung. 14B weist einen L1-Daten-Cache 1406A, der Teil des L1-Caches 1404 ist, sowie weitere Details hinsichtlich der Vektoreinheit 1410 und der Vektorregister 1414 auf. Spezifisch ist die Vektoreinheit 1410 eine Vektorverarbeitungseinheit (VPU - Vector Processing Unit) mit einer Breite von 16 (siehe die ALU mit Breite 16 1428), welche eine oder mehrere aus Ganzzahlanweisungen, Gleitkommaanweisungen mit einfacher Genauigkeit und Gleitkommaanweisungen mit doppelter Genauigkeit ausführt. Die VPU unterstützt das Umstellen der Registereingaben mit der Umstellungseinheit 1420, das numerische Konvertieren mit den numerischen Konvertierungseinheiten 1422A-B und das Replizieren mit der Replikationseinheit 1424 an der Arbeitsspeichereingabe. Die Schreibmaskenregister 1426 gestatten das Prädizieren resultierender Vektorschreibvorgänge.

15 ist ein Blockdiagramm eines Prozessors 1500, der mehr als einen Kern aufweisen kann, einen integrierten Arbeitsspeicher-Controller aufweisen kann und integrierte Grafik aufweisen kann, gemäß Ausführungsformen der Offenbarung. Die Kästchen mit durchgezogenen Linien in 15 veranschaulichen einen Prozessor 1500 mit einem einzelnen Kern 1502A, einem Systemagent 1510 und einem Satz von einer oder mehreren Bus-Controller-Einheiten 1516, während die optional hinzugefügten Kästchen mit gestrichelten Linien einen alternativen Prozessor 1500 mit mehreren Kernen 1502A-N, einem Satz von einer oder mehreren integrierten Arbeitsspeicher-Controller-Einheit(en) 1514 in der Systemagent-Einheit 1510 und Speziallogik 1508 veranschaulichen.

Somit können unterschiedliche Implementierungen des Prozessors 1500 Folgendes aufweisen: 1) eine CPU mit der Speziallogik 1508, bei welcher es sich um integrierte Grafik- und/oder wissenschaftliche (Durchsatz-) Logik handelt (welche einen oder mehrere Kerne aufweisen kann), und den Kernen 1502A-N, bei welchen es sich um einen oder mehrere Universalkerne handelt (z.B. sequentielle Universalkerne, nicht-sequentielle Universalkerne, eine Kombination der beiden); 2) einen Co-Prozessor mit den Kernen 1502A-N, bei welchen es sich um eine große Zahl von Spezialkernen handelt, die primär für Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnungen bestimmt sind; und 3) einen Co-Prozessor mit den Kernen 1502A-N, bei welchen es sich um eine große Zahl von sequentiellen Universalkernen handelt. Somit kann der Prozessor 1500 ein Universalprozessor, ein Co-Prozessor oder ein Spezialprozessor sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsmaschine, ein Grafikprozessor, eine GPGPU (General Purpose Graphics Processing Unit), ein MIC (Many Integrated Core) -Co-Prozessor mit hohem Durchsatz (der 30 oder mehr Kerne aufweist), ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert werden. Der Prozessor 1500 kann, unter Verwendung jeglicher einer Reihe von Prozesstechnologien, wie zum Beispiel BiCMOS, CMOS oder NMOS, ein Teil von einem oder mehreren Substraten sein und/oder darauf implementiert werden.

Die Arbeitsspeicherhierarchie weist ein oder mehrere Level von Cache innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsam genutzten Cache-Einheiten 1506 und externen Arbeitsspeicher (nicht gezeigt) gekoppelt an den Satz von integrierten Arbeitsspeicher-Controller-Einheiten 1514 auf. Der Satz von gemeinsam genutzten Cache-Einheiten 1506 kann einen oder mehrere Mid-Level-Caches, wie z.B. L2 (Level 2), L3 (Level 3), L4 (Level 4) oder andere Level von Cache, einen LLC (Last Level Cache) und/oder Kombinationen davon aufweisen. Während in einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 1512 die integrierte Grafiklogik 1508, den Satz von gemeinsam genutzten Cache-Einheiten 1506 und die Systemagent-Einheit 1510/die integrierte(n) Arbeitsspeicher-Controller-Einheit(en) 1514 miteinander verbindet, können alternative Ausführungsformen jegliche Zahl gut bekannter Techniken zum Verbinden derartiger Einheiten verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Cache-Einheiten 1506 und den Kernen 1502A-N aufrechterhalten.

In einigen Ausführungsformen sind einer oder mehrere der Kerne 1502AN zu Multithreading in der Lage. Der Systemagent 1510 weist diejenigen Komponenten auf, welche die Kerne 1502A-N koordinieren und betreiben. Die Systemagent-Einheit 1510 kann zum Beispiel eine Leistungssteuerungseinheit (PCU - Power Control Unit) und eine Anzeigeeinheit aufweisen. Bei der PCU kann es sich um Logik und Komponenten, die zum Regeln des Energiezustands der Kerne 1502A-N und der integrierten Grafiklogik 1508 benötigt werden, handeln oder sie kann diese aufweisen. Die Anzeigeeinheit dient dem Antreiben von einer oder mehreren extern angeschlossenen Anzeigen.

Die Kerne 1502A-N können hinsichtlich der Anweisungssatzarchitektur homogen oder heterogen sein; d.h., zwei oder mehr der Kerne 1502A-N können zur Ausführung des gleichen Anweisungssatzes in der Lage sein, während andere zur Ausführung von nur einer Teilmenge dieses Anweisungssatzes oder eines unterschiedlichen Anweisungssatzes in der Lage sein können.

Beispielhafte Computerarchitekturen

16 - 19 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere in der Technik bekannte Systemdesigns und - konfigurationen für Laptops, Desktops, Handheld-PCs, PDAs, Engineering-Arbeitsplätze, Server, Netzwerkgeräte, Netzwerk-Hubs, Schalter, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikgeräte, Videospielegeräte, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Mediaplayer, Handheld-Geräte und verschiedene andere elektronische Geräte sind auch geeignet. Im Allgemeinen ist eine große Vielfalt von Systemen oder elektronischen Geräten, die in einen Prozessor und/oder andere Ausführungslogik, wie hierin offenbart, integriert werden können, allgemein geeignet.

Nun Bezug nehmend auf 16, ist ein Blockdiagramm eines Systems 1600 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung gezeigt. Das System 1600 kann einen oder mehrere Prozessoren 1610, 1615 aufweisen, welche an einen Controller-Hub 1620 gekoppelt sind. In einer Ausführungsform weist der Controller-Hub 1620 einen Grafikarbeitsspeicher-Controller-Hub (GMCH - Graphics Memory Controller Hub) 1690 und einen Eingabe-/Ausgabe-Hub (EAH) 1650 auf (welche sich auf separaten Chips befinden können); der GMCH 1690 weist Arbeitsspeicher- und Grafik-Controller auf, an welche ein Arbeitsspeicher 1640 und ein Co-Prozessor 1645 gekoppelt sind; der EAH 1650 koppelt die Eingabe/Ausgabe (E/A) -Geräte 1660 an den GMCH 1690. Alternativ dazu sind einer oder beide der Arbeitsspeicher- und Grafik-Controller in den Prozessor integriert (wie hierin beschrieben), der Arbeitsspeicher 1640 und der Co-Prozessor 1645 sind direkt an den Prozessor 1610 gekoppelt und der Controller-Hub 1620 befindet sich auf einem einzelnen Chip mit dem EAH 1650. Der Arbeitsspeicher 1640 kann Kontextumschaltungscode 1640A aufweisen, um zum Beispiel Code zu speichern, der, wenn er ausgeführt wird, einen Prozessor zum Durchführen jegliches Verfahrens dieser Offenbarung veranlasst.

Die optionale Natur zusätzlicher Prozessoren 1615 ist in 16 mit unterbrochenen Linien gezeigt. Jeder Prozessor 1610, 1615 kann einen oder mehrere der hierin beschriebenen Verarbeitungskerne aufweisen und kann eine Version des Prozessors 1500 sein.

Der Arbeitsspeicher 1640 kann zum Beispiel dynamischer Direktzugriffsspeicher (DRAM - Dynamic Random Access Memory), Phasenwechselspeicher (PCM - Phase Change Memory) oder eine Kombination der beiden sein. Bei mindestens einer Ausführungsform kommuniziert der Controller-Hub 1620 mit dem (den) Prozessor(en) 1610, 1615 über einen Multi-Drop-Bus, wie z.B. einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie z.B. Quickpath Interconnect (QPI), oder eine ähnliche Verbindung 1695.

In einer Ausführungsform ist der Co-Prozessor 1645 ein Spezialprozessor, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controller-Hub 1620 einen integrierten Grafikbeschleuniger aufweisen.

Es kann eine Vielzahl von Unterschieden zwischen den physischen Ressourcen 1610, 1615 hinsichtlich eines Spektrums von Leistungsmetriken, einschließlich Architektur-, Mikroarchitektur-, thermischen, Stromverbrauchseigenschaften und dergleichen, vorliegen.

In einer Ausführungsform führt der Prozessor 1610 Anweisungen aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. Es können Co-Prozessor-Anweisungen in die Anweisungen eingebettet sein. Der Prozessor 1610 erkennt diese Co-Prozessor-Anweisungen als von einem Typ, der durch den angeschlossenen Co-Prozessor 1645 ausgeführt werden sollte. Dementsprechend gibt der Prozessor 1610 diese Co-Prozessor-Anweisungen (oder Steuersignale, welche Co-Prozessor-Anweisungen darstellen) auf einem Co-Prozessor-Bus oder einer anderen Zwischenverbindung an den Co-Prozessor 1645 aus. Der (Die) Co-Prozessor(en) 1645 nehmen die empfangenen Co-Prozessor-Anweisungen an und führen sie aus.

Nun Bezug nehmend auf 17, ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 1700 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung gezeigt. Wie in 17 gezeigt, ist das Multiprozessorsystem 1700 ein Punkt-zu-Punkt-Zwischenverbindungssystem und weist einen ersten Prozessor 1770 und einen zweiten Prozessor 1780 gekoppelt über eine Punkt-zu-Punkt-Zwischenverbindung 1750 auf. Jeder der Prozessoren 1770 und 1780 kann eine Version des Prozessors 1500 sein. In einer Ausführungsform der Offenbarung sind die Prozessoren 1770 und 1780 entsprechend die Prozessoren 1610 und 1615, während der Co-Prozessor 1738 der Co-Prozessor 1645 ist. In einer weiteren Ausführungsform sind die Prozessoren 1770 und 1780 entsprechend der Prozessor 1610 und der Co-Prozessor 1645.

Die Prozessoren 1770 und 1780 sind als die integrierten Arbeitsspeicher-Controller (IMC - Integrated Memory Controller) -Einheiten 1772 bzw. 1782 aufweisend gezeigt. Der Prozessor 1770 weist, als Teil seiner Bus-Controller-Einheiten, auch die Punkt-zu-Punkt (P-P) -Schnittstellen 1776 und 1778 auf; ähnlich weist der zweite Prozessor 1780 die P-P-Schnittstellen 1786 und 1788 auf. Die Prozessoren 1770, 1780 können über eine Punkt-zu-Punkt (P-P) -Schnittstelle 1750 unter Verwendung der P-P-Schnittstellenschaltungen 1778, 1788 Informationen austauschen. Wie in 17 gezeigt, koppeln die IMCs 1772 und 1782 die Prozessoren an entsprechende Arbeitsspeicher, nämlich einen Arbeitsspeicher 1732 und einen Arbeitsspeicher 1734, bei welchen es sich um Abschnitte eines Hauptspeichers handeln kann, die lokal an die entsprechenden Prozessoren angeschlossen sind.

Die Prozessoren 1770, 1780 können über die individuellen P-P-Schnittstellen 1752, 1754 unter Verwendung der Punkt-zu-Punkt-Schnittstellenschaltungen 1776, 1794, 1786, 1798 Informationen mit einem Chipsatz 1790 austauschen. Der Chipsatz 1790 kann über eine Hochleistungsschnittstelle 1739 optional Informationen mit dem Co-Prozessor 1738 austauschen. In einer Ausführungsform ist der Co-Prozessor 1738 ein Spezialprozessor, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.

Ein gemeinsam genutzter Cache (nicht gezeigt) kann in einem der Prozessoren enthalten sein oder sich außerhalb beider Prozessoren befinden, jedoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, derart, dass lokale Cache-Informationen von einem oder beiden Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, wenn ein Prozessor in einen Niedrigenergiemodus geschaltet wird.

Der Chipsatz 1790 kann über eine Schnittstelle 1796 an einen ersten Bus 1716 gekoppelt sein. In einer Ausführungsform kann der erste Bus 1716 ein PCI (Peripheral Component Interconnect) -Bus oder ein Bus, wie z.B. PCI Express-Bus oder ein anderer E/A-Zwischenverbindungsbus der dritten Generation, sein, obwohl der Umfang der vorliegenden Offenbarung nicht dahingehend beschränkt ist.

Wie in 17 gezeigt, können verschiedene E/A-Geräte 1714 an den ersten Bus 1716 gekoppelt sein, zusammen mit einer Busbrücke 1718, welche den ersten Bus 1716 an einen zweiten Bus 1720 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzliche(r) Prozessor(en) 1715, wie z.B. Co-Prozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie z.B. Grafikbeschleuniger oder Digitalsignalverarbeitungseinheiten (DSPs)), feldprogrammierbare Gate-Arrays oder jeglicher anderer Prozessor, an den ersten Bus 1716 gekoppelt. In einer Ausführungsform kann der zweite Bus 1720 ein LPC (Low Pin Count) -Bus sein. Es können verschiedene Geräte an einen zweiten Bus 1720 gekoppelt sein, zum Beispiel einschließlich einer Tastatur und/oder einer Maus 1722, Kommunikationsgeräten 1727 und einer Speichereinheit 1728, wie z.B. ein Festplattenlaufwerk oder ein anderes Massenspeichergerät, welches in einer Ausführungsform Anweisungen/Code und Data 1730 aufweisen kann. Außerdem kann eine Audio-E/A 1724 an den zweiten Bus 1720 gekoppelt sein. Es sei darauf hingewiesen, dass auch andere Architekturen möglich sind. Zum Beispiel kann ein System anstelle der Punkt-zu-Punkt-Architektur von 17 einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.

Nun Bezug nehmend auf 18, ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 1800 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung gezeigt. Gleiche Elemente in 17 und 18 tragen gleiche Referenzziffern, und bestimmte Aspekte von 17 wurden aus 18 weggelassen, um ein Verdecken anderer Aspekte von 18 zu vermeiden.

18 veranschaulicht, dass die Prozessoren 1770, 1780 integrierten Arbeitsspeicher und E/A-Steuerlogik („CL“ - Control Logic) 1772 bzw. 1782 aufweisen können. Somit weist die CL 1772, 1782 integrierte Arbeitsspeicher-Controller-Einheiten auf und weist E/A-Steuerlogik auf. 18 veranschaulicht, dass nicht nur die Arbeitsspeicher 1732, 1734 an die CL 1772, 1782 gekoppelt sind, sondern dass auch die E/A-Geräte 1814 an die Steuerlogik 1772, 1782 gekoppelt sind. Ältere E/A-Geräte 1815 sind an den Chipsatz 1790 gekoppelt.

Nun Bezug nehmend auf 19, ist ein Blockdiagramm eines SoC 1900 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung gezeigt. Ähnliche Elemente in 15 tragen gleiche Referenzziffern. Auch zeigen Kästchen mit gestrichelten Linien optionale Merkmale in fortgeschritteneren SoCs. In 19 ist eine/sind Zwischenverbindungseinheit(en) 1902 an Folgendes gekoppelt: einen Anwendungsprozessor 1910, welcher einen Satz von einem/r oder mehreren Kernen 1502A-N und gemeinsam genutzten Cache-Einheit(en) 1506 aufweist; eine Systemagent-Einheit 1510; (eine) Bus-Controller-Einheit(en) 1516; (eine) integrierte Arbeitsspeicher-Controller-Einheit(en) 1514; einen Satz von einem oder mehreren Co-Prozessoren 1920, welche integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor aufweisen können; eine statische Direktzugriffsspeicher (SRAM - Static Random Access Memory) -Einheit 1930; eine Einheit für direkten Arbeitsspeicherzugriff (DMA - Direct Memory Access) 1932; und eine Anzeigeeinheit 1940 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform weist der/weisen die Co-Prozessor(en) 1920 einen Spezialprozessor auf, wie zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsmaschine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder dergleichen.

Hierin offenbarte Ausführungsformen (z.B. der Mechanismen) können in Hardware, Software, Firmware oder einer Kombination derartiger Implementierungsansätze implementiert werden. Ausführungsformen der Offenbarung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozessor, ein Speichersystem (einschließlich flüchtiger und nicht-flüchtiger Arbeitsspeicher- und/oder Speicherelemente), mindestens ein Eingabegerät und mindestens ein Ausgabegerät aufweisen.

Programmcode, wie z.B. der in 17 veranschaulichte Code 1730, kann auf Eingabeanweisungen angewendet werden, um die hierin beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in einer bekannten Art und Weise auf ein oder mehrere Ausgabegeräte angewendet werden. Zum Zweck dieser Anmeldung weist ein Verarbeitungssystem jegliches System auf, das einen Prozessor aufweist, wie zum Beispiel einen Digitalsignalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC - Application Specific Integrated Circuit) oder einen Mikroprozessor.

Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache zum Kommunizieren mit einem Verarbeitungssystem implementiert werden. Der Programmcode kann, falls gewünscht, auch in Assembler- oder Maschinensprache implementiert werden. Tatsächlich sind die hierin beschriebenen Mechanismen in ihrem Umfang nicht auf jegliche bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.

Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, welches verschiedene Logik innerhalb des Prozessors darstellt, welche, wenn sie durch eine Maschine gelesen wird, die Maschine zum Herstellen von Logik zum Durchführen der hierin beschriebenen Techniken veranlasst. Derartige Darstellungen, bekannt als „IP-Kerne“, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Herstellungseinrichtungen bereitgestellt werden, um sie in die Herstellungsmaschinen zu laden, welche dann tatsächlich die Logik oder den Prozessor herstellen.

Zu derartigen maschinenlesbaren Speichermedien können, ohne Einschränkung, nichttransitorische, greifbare Anordnungen von Gegenständen, die durch eine Maschine oder ein Gerät hergestellt oder gebildet werden, zählen, einschließlich Speichermedien, wie z.B. Festplatten, jegliche andere Art von Platte, einschließlich Disketten, optischer Platten, CD-ROMs (Compact Disk Read-Only Memories), CD-RWs (Compact Disk Rewritables) und magnetoptischer Platten, Halbleiterbauelemente, wie z.B. ROMs (Read-Only Memories), RAMs (Random Access Memories), wie z.B. DRAMs (Dynamic Random Access Memories), SRAMs (Static Random Access Memories), EPROMs (Erasable Programmable Read-Only Memories), Flashspeicher, EEPROMs (Electrically Erasable Programmable Read-Only Memories), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder jegliche andere Art von Medien, die zum Speichern elektronischer Anweisungen geeignet sind.

Dementsprechend weisen Ausführungsformen der Offenbarung auch nichttransitorische, greifbare maschinenlesbare Medien auf, die Anweisungen enthalten oder Designdaten enthalten, wie z.B. Hardwarebeschreibungssprache (HDL - Hardware Description Language), welche hierin beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Derartige Ausführungsformen können auch als Programmprodukte bezeichnet werden.

Emulation (einschließlich Binärtranslation, Code-Morphing usw.)

In einigen Fällen kann ein Anweisungswandler zum Umwandeln einer Anweisung aus einem Quellanweisungssatz in einen Zielanweisungssatz verwendet werden. Zum Beispiel kann der Anweisungswandler eine Anweisung in eine oder mehrere andere Anweisungen, die durch den Kern verarbeitet werden sollen, übersetzen (z.B. unter Verwendung statischer Binärtranslation, dynamischer Binärtranslation, einschließlich dynamischer Kompilierung), morphen, emulieren oder anderweitig umwandeln. Der Anweisungswandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert werden. Der Anweisungswandler kann sich im Prozessor, außerhalb des Prozessors oder teilweise im und teilweise außerhalb des Prozessors befinden.

20 ist ein Blockdiagramm, welches die Verwendung eines Software-Anweisungswandlers zum Umwandeln von Binäranweisungen in einem Quellanweisungssatz in Binäranweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Offenbarung gegenüberstellt. In der veranschaulichten Ausführungsform ist der Anweisungswandler ein Software-Anweisungswandler, obwohl alternativ dazu der Anweisungswandler auch in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 20 zeigt, dass ein Programm in einer Hochsprache 2002 unter Verwendung eines x86-Compilers 2004 kompiliert werden kann, um x86-Binärcode 2006 zu erzeugen, der durch einen Prozessor mit mindestens einem x86-Anweisungssatzkern 2016 systemintern ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Anweisungssatzkern 2016 stellt jeglichen Prozessor dar, der im Wesentlichen die gleichen Funktionen wie ein Intel®-Prozessor mit mindestens einem x86-Anweisungssatzkern durch das kompatible Ausführen oder anderweitige Verarbeiten (1) eines wesentlichen Abschnittes des Anweisungssatzes des Intel®-x86-Anweisungssatzkerns oder (2) von Objektcode-Versionen von Anwendungen oder anderer Software, die auf einem Intel®-Prozessor mit mindestens einem x86-Anweisungssatzkern laufen sollen, durchführen kann, um im Wesentlichen das gleiche Ergebnis wie ein Intel®-Prozessor mit mindestens einem x86-Anweisungssatzkern zu erzielen. Der x86-Compiler 2004 stellt einen Compiler dar, der zum Erzeugen von x86-Binärcode 2006 funktionsfähig ist (z.B. Objektcode), der, mit oder ohne zusätzliche Verknüpfungsverarbeitung, auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 2016 ausgeführt werden kann. Ähnlich zeigt 20, dass das Programm in der Hochsprache 2002 unter Verwendung eines alternativen Anweisungssatz-Compilers 2008 kompiliert werden kann, um alternativen Anweisungssatz-Binärcode 2010 zu erzeugen, der durch einen Prozessor ohne mindestens einen x86-Anweisungssatzkern 2014 systemintern ausgeführt werden kann (z.B. durch einen Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies aus Sunnyvale, CA ausführen und/oder den ARM-Anweisungssatz von ARM Holdings aus Sunnyvale, CA ausführen). Der Anweisungswandler 2012 wird zum Umwandeln des x86-Binärcodes 2006 in Code verwendet, der durch den Prozessor ohne einen x86-Anweisungssatzkern 2014 systemintern ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht der gleiche wie der alternative Anweisungssatz-Binärcode 2010, weil ein Anweisungswandler, der dazu fähig wäre, schwierig herzustellen ist; jedoch erreicht der umgewandelte Code die allgemeine Operation und besteht aus Anweisungen aus dem alternativen Anweisungssatz. Somit stellt der Anweisungswandler 2012 Software, Firmware, Hardware oder eine Kombination davon dar, die es, durch Emulation, Simulation oder jeglichen anderen Prozess, einem Prozessor oder einem anderen elektronischen Gerät, das keinen x86-Anweisungssatz-Prozessor oder -Kern aufweist, gestattet, den x86-Binärcode 2006 auszuführen.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

US 62/968861 [0001]

Claims

Hardwareprozessor, welcher Folgendes aufweist: einen Hardware-Guide-Scheduler, der mehrere Software-Thread-Laufzeiteigenschaft-Verläufe aufweist; einen Decoder zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister identifiziert; und eine Ausführungsschaltung zum Ausführen der decodierten Einzelanweisung für Folgendes: Prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und wenn das Freigabe-Bit gesetzt ist, Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers.
Hardwareprozessor nach Anspruch 1, wobei, wenn das Freigabe-Bit gesetzt ist, die Ausführungsschaltung die decodierte Einzelanweisung zum Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers ausführen soll, ohne einen anderen Architekturzustand des Hardwareprozessors zu modifizieren.
Hardwareprozessor nach einem der Ansprüche 1-2, wobei es sich bei einem Opcode der Einzelanweisung um einen älteren Opcode handelt, und, wenn das Freigabe-Bit nicht gesetzt ist, die Ausführungsschaltung die Einzelanweisung als eine Nulloperation ausführen soll.
Hardwareprozessor nach einem der Ansprüche 1-3, wobei, wenn das Freigabe-Bit gesetzt ist, die Ausführungsschaltung die decodierte Einzelanweisung zum Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers nur ausführen soll, wenn die Einzelanweisung zur Ausführung durch ein Betriebssystem angefordert wird.
Hardwareprozessor nach einem der Ansprüche 1-4, wobei die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe mehrere Gewichte für entsprechende Klassen von Leistungsüberwachungsereignissen für mehrere Kerne des Hardwareprozessors aufweisen.
Hardwareprozessor nach Anspruch 5, wobei die entsprechenden Klassen eine erste Klasse für einen ersten Kerntyp und eine zweite Klasse für einen zweiten Kern mit höherer Leistung aufweisen.
Hardwareprozessor nach Anspruch 5, wobei die entsprechenden Klassen eine erste Klasse für eine Vektoranweisung des Ganzzahltyps und eine zweite Klasse für eine Vektoranweisung des Gleitkommatyps aufweisen.
Hardwareprozessor nach einem der Ansprüche 1-7, wobei der Hardware-Guide-Scheduler einen Hinweis für einen nächsten Software-Thread, der auf dem Hardwareprozessor ausgeführt werden soll, in einem Register des Hardwareprozessors speichern soll, um einem Betriebssystem einen Kerntyp von mehreren Kerntypen des Hardwareprozessors anzuzeigen, und der Hinweis auf den mehreren Software-Thread-Laufzeiteigenschaft-Verläufen basiert.
Verfahren, welches Folgendes umfasst: Erzeugen mehrerer Software-Thread-Laufzeiteigenschaft-Verläufe mit einem Hardware-Guide-Scheduler eines Hardwareprozessors; Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung mit einem Decoder des Hardwareprozessors, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister identifiziert; und Ausführen der decodierten Einzelanweisung mit einer Ausführungsschaltung des Hardwareprozessors für Folgendes: Prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und wenn das Freigabe-Bit gesetzt ist, Zurücksetzen der mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers.
Verfahren nach Anspruch 9, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers zurücksetzt, ohne einen anderen Architekturzustand des Hardwareprozessors zu modifizieren.
Verfahren nach einem der Ansprüche 9-10, wobei es sich bei einem Opcode der Einzelanweisung um einen älteren Opcode handelt, und, wenn das Freigabe-Bit nicht gesetzt ist, die Ausführungsschaltung die Einzelanweisung als eine Nulloperation ausführt.
Verfahren nach einem der Ansprüche 9-11, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers nur zurücksetzt, wenn die Einzelanweisung zur Ausführung durch ein Betriebssystem angefordert wird.
Verfahren nach einem der Ansprüche 9-12, wobei die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe mehrere Gewichte für entsprechende Klassen von Leistungsüberwachungsereignissen für mehrere Kerne des Hardwareprozessors aufweisen.
Verfahren nach Anspruch 13, wobei die entsprechenden Klassen eine erste Klasse für einen ersten Kerntyp und eine zweite Klasse für einen zweiten Kern mit höherer Leistung aufweisen.
Verfahren nach Anspruch 13, wobei die entsprechenden Klassen eine erste Klasse für eine Vektoranweisung des Ganzzahltyps und eine zweite Klasse für eine Vektoranweisung des Gleitkommatyps aufweisen.
Verfahren nach einem der Ansprüche 9-15, welches ferner das Speichern eines Hinweises, durch den Hardware-Guide-Scheduler, für einen nächsten Software-Thread, der auf dem Hardwareprozessor ausgeführt werden soll, in einem Register des Hardwareprozessors umfasst, um einem Betriebssystem einen Kerntyp von mehreren Kerntypen des Hardwareprozessors anzuzeigen, wobei der Hinweis auf den mehreren Software-Thread-Laufzeiteigenschaft-Verläufen basiert.
Nichttransitorisches maschinenlesbares Medium, das Code speichert, der, wenn er durch eine Maschine ausgeführt wird, die Maschine zum Durchführen eines Verfahrens veranlasst, das Folgendes umfasst: Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung mit einem Decoder eines Hardwareprozessors, wobei die Einzelanweisung ein Feld aufweist, das ein Steuerregister identifiziert; und Ausführen der decodierten Einzelanweisung mit einer Ausführungsschaltung des Hardwareprozessors für Folgendes: Prüfen, dass ein Freigabe-Bit des Steuerregisters gesetzt ist, und wenn das Freigabe-Bit gesetzt ist, Zurücksetzen mehrerer Software-Thread-Laufzeiteigenschaft-Verläufe eines Hardware-Guide-Schedulers des Hardwareprozessors.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 17, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers zurücksetzt, ohne einen anderen Architekturzustand des Hardwareprozessors zu modifizieren.
Nichttransitorisches maschinenlesbares Medium nach einem der Ansprüche 17-18, wobei es sich bei einem Opcode der Einzelanweisung um einen älteren Opcode handelt, und, wenn das Freigabe-Bit nicht gesetzt ist, die Ausführungsschaltung die Einzelanweisung als eine Nulloperation ausführt.
Nichttransitorisches maschinenlesbares Medium nach einem der Ansprüche 17-19, wobei, wenn das Freigabe-Bit gesetzt ist, das Ausführen der decodierten Einzelanweisung die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe des Hardware-Guide-Schedulers nur zurücksetzt, wenn die Einzelanweisung zur Ausführung durch ein Betriebssystem angefordert wird.
Nichttransitorisches maschinenlesbares Medium nach einem der Ansprüche 17-20, wobei die mehreren Software-Thread-Laufzeiteigenschaft-Verläufe mehrere Gewichte für entsprechende Klassen von Leistungsüberwachungsereignissen für mehrere Kerne des Hardwareprozessors aufweisen.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 21, wobei die entsprechenden Klassen eine erste Klasse für einen ersten Kerntyp und eine zweite Klasse für einen zweiten Kern mit höherer Leistung aufweisen.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 21, wobei die entsprechenden Klassen eine erste Klasse für eine Vektoranweisung des Ganzzahltyps und eine zweite Klasse für eine Vektoranweisung des Gleitkommatyps aufweisen.
Nichttransitorisches maschinenlesbares Medium nach einem der Ansprüche 17-23, welches ferner das Speichern eines Hinweises, durch den Hardware-Guide-Scheduler, für einen nächsten Software-Thread, der auf dem Hardwareprozessor ausgeführt werden soll, in einem Register des Hardwareprozessors umfasst, um einem Betriebssystem einen Kerntyp von mehreren Kerntypen des Hardwareprozessors anzuzeigen, wobei der Hinweis auf den mehreren Software-Thread-Laufzeiteigenschaft-Verläufen basiert.
Nichttransitorisches maschinenlesbares Medium nach einem der Ansprüche 17-24, welches ferner das Übersetzen der Einzelanweisung in eine oder mehrere Anweisungen einer unterschiedlichen Anweisungssatzarchitektur vor dem Decodieren umfasst, wobei das Ausführen der einen oder der mehreren Anweisungen der unterschiedlichen Anweisungssatzarchitektur funktional äquivalent zum Ausführen der decodierten Einzelanweisung sein soll.