DE112017001804T5

DE112017001804T5 - Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand

Info

Publication number: DE112017001804T5
Application number: DE112017001804.8T
Authority: DE
Inventors: Kshitij A. Doshi; Christopher J. Hughes
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-04-01
Filing date: 2017-03-07
Publication date: 2018-12-13
Also published as: WO2017172300A1; US20170286300A1; CN108701088A; CN108701088B; US10067870B2

Abstract

Beschrieben sind eine Vorrichtung und ein Verfahren für synchrone Seitentabellenaktualisierungen mit geringem Aufwand. Beispielsweise umfasst eine Ausführungsform eines Prozessors Folgendes: einen Satz von einem oder mehreren Kernen zum Ausführen von Befehlen und Verarbeiten von Daten; einen Übersetzungspuffer (TLB), welcher mehrere Einträge umfasst, um Adressübersetzungen von virtuell nach physisch aufzunehmen, welche durch den Satz eines oder mehrerer Kerne beim Ausführen der Befehle verwendbar sind; einen Sperrschaltkomplex, um zu ermöglichen, dass ein Thread einen ersten Seitentabelleneintrag (PTE) in dem TLB sperrt, um zu gewährleisten, dass zu einem Zeitpunkt nur ein Thread den ersten PTE modifizieren kann, wobei der TLB dazu dient, den ersten PTE beim Erlangen der Sperre durch den Thread zu modifizieren; eine PTE-Invalidierungsschaltung, um einen PTE-Invalidierungsbefehl auf einem ersten Kern auszuführen, um den ersten PTE in anderen TLBs anderer Kerne zu invalidieren, wobei die PTE-Invalidierungsschaltung als Reaktion auf eine Ausführung des PTE-Invalidierungsbefehls eine Anzahl anderer TLBs anderer Kerne, welche über die PTE-Invalidierung benachrichtigt werden müssen, als Reaktion bestimmt, PTE-Invalidierungsmeldungen an die anderen TLBs überträgt und auf Erwiderungen wartet; und der Sperrschaltkomplex die Sperre auf dem ersten PTE als Reaktion auf Erhalten von Erwiderungen von all den anderen TLBs freigibt.

Description

HINTERGRUND
Gebiet der Erfindung
Diese Erfindung betrifft im Allgemeinen das Feld der Computerprozessoren. Insbesondere betrifft die Erfindung ein Verfahren und eine Vorrichtung für synchrone Seitentabellenaktualisierungen mit geringem Aufwand.
Beschreibung der verwandten Technik
Prozessormikroarchitekturen
Ein Befehlssatz oder Befehlssatzarchitektur (ISA) ist der Teil der Rechnerarchitektur, welcher Programmierung betrifft. welche die nativen Datentypen, Befehle, Registerarchitektur, Adressiermodi, Speicherarchitektur, Unterbrechungs- und Ausnahmebehandlung und externe Eingabe und Ausgabe (E/A) umfasst. Es sei angemerkt, dass sich der Begriff „Befehl“ hierin im Allgemeinen auf Makrobefehle - d. h. auf Befehle, welche dem Prozessor zur Ausführung bereitgestellt werden - im Gegensatz zu Mikrobefehlen oder Mikrooperationen bezieht - d. h. auf das Ergebnis eines Decodierers des Prozessors, welcher Makrobefehle decodiert. Die Mikrobefehle oder Mikrooperationen können konfiguriert sein, einer Ausführungseinheit auf dem Prozessor zu befehlen, Operationen durchzuführen, um die Logik zu implementieren, welche dem Makrobefehl zugeordnet ist.
Die ISA wird von der Mikroarchitektur unterschieden, welche der Satz Prozessorentwurfsverfahren ist, welcher zum Implementieren des Befehlssatzes verwendet wird. Prozessoren mit verschieden Mikroarchitekturen können sich einen gemeinsam genutzten Befehlssatz teilen. Beispielsweise implementieren Intel® Pentium 4 Prozessoren, Intel® Core™ Prozessoren und Prozessoren von Advanced Micro Devices, Inc. in Sunnyvale CA beinahe identische Versionen des x86-Befehlssatzes (mit einigen Erweiterungen, welche bei neueren Versionen hinzugefügt wurden), weisen jedoch verschiedene interne Entwürfe auf. Beispielsweise kann die gleiche Registerarchitektur der ISA auf verschiedenen Wegen in verschiedenen Mikroarchitekturen unter Verwendung wohlbekannter Techniken implementiert werden, welche dedizierte physische Register, ein oder mehrere dynamisch zugeordnete physische Register unter Verwendung eines Registerumbenennungsmechanismus (z. B. die Verwendung einer Registeraliastabelle (RAT), eines Neuordnungspuffers (ROB) und einer Ausbuchungsregisterdatei). Außer es ist anderslautend beschrieben, werden die Begriffe Registerarchitektur, Registerdatei und Register hier verwendet, um das zu bezeichnen, was der Software/dem Programmierer sichtbar ist, und um die Weise zu bezeichnen, in welcher Befehle Register angeben. Wo eine Unterscheidung erforderlich ist, werden die Adjektive „logisch“, „architektonisch“ oder „Software-sichtbar“ verwendet, um Register/Dateien in der Registerarchitektur anzugeben, während verschiedene Adjektive verwendet werden, um Register in einer gegebenen Mikroarchitektur zu bezeichnen (z. B. physisches Register, Neuordnungspuffer, Ausbuchungsregister, Registersammlung).
TLB-Kohärenz
In einem System mit gemeinsam genutztem Speicher müssen sowohl Caches als auch TLBs kohärent gehalten werden, um allen Threads die gleiche Speicheransicht bereitzustellen. Einer der Hauptgründe dafür, dass Kohärenz für TLBs unterhalten werden muss, ist, dass es schwierig ist, den gesamten Datenzustand kohärent zu halten, wenn zwei verschiedene CPUs verschiedene Adressübersetzungen für die gleiche Seite aufweisen. TLBs kohärent zu halten ist relativ günstig, wenn sich Seitentabelleneinträge (PTEs) sehr selten verändern, wie dies heute der Fall ist. Aktuelle Systeme verwenden eine Kombination aus einer trägen PTE-Wiederverwendung, welche in seltenen Fällen durch sofortige TLB-Abschüsse unterstützt werden. TLB-Abschüsse sind ungeheuer aufwendig, sind jedoch bei aktuellen Systemen der einzige Weg, eine PTE-Veränderung in einer synchronen Weise zu verbreiten. Es ist zu erwarten, dass sich in naher Zukunft die Frequenz von PTE-Veränderungen erhöhen wird, was einen effizienteren Mechanismus zum Verbreiten von PTE-Veränderungen erforderlich macht.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erlangt werden, wobei:

1A und 1B Blockdiagramme sind, welche ein allgemeines vektorfreundliches Befehlsformat und Befehlstemplates davon gemäß Ausführungsformen der Erfindung illustrieren.
2A bis D ein Blockdiagramm ist, welches ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung illustriert.
3 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Erfindung ist; und
4A ein Blockdiagramm ist, welches sowohl eine beispielhafte In-Reihenfolge-Pipeline für Abrufen, Decodieren und Ausbuchen als auch eine beispielhafte Registerumbenennungs-Außer-Reihenfolge-Ausgabe/Ausführungs-Pipeline gemäß Ausführungsformen der Erfindung illustriert;
4B ein Blockdiagramm ist, welches sowohl ein Ausführungsbeispiel für einen In-Reihenfolge-Kern für Abrufen, Decodieren und Ausbuchen als auch einen beispielhaften Registerumbenennung-außer-Reihenfolge-Ausgabe/Ausführung-Architektur-Kern, welcher in einem Prozessor aufzunehmen ist, gemäß Ausführungsformen der Erfindung illustriert;
Figur SA ein Blockdiagramm eines einzelnen Prozessorkerns zusammen mit seiner Verbindung zu einem On-Die-Zwischenverbindungsnetz ist;
5B eine erweiterte Ansicht eines Teils des Prozessorkerns in 5A gemäß Ausführungsformen der Erfindung illustriert;
6 ein Blockdiagramm eines einkernigen Prozessors und eines mehrkernigen Prozessors mit integrierter Speichersteuerung und Grafik gemäß Ausführungsformen der Erfindung ist;
7 ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung illustriert;
8 ein Blockdiagramm eines zweiten Systems gemäß einer Ausführungsform der vorliegenden Erfindung illustriert;
9 ein Blockdiagramm eines dritten Systems gemäß einer Ausführungsform der vorliegenden Erfindung illustriert;
10 ein Blockdiagramm eines SoC (System-on-Chip) gemäß einer Ausführungsform der vorliegenden Erfindung illustriert;
11 ein Blockdiagramm illustriert, welches die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln von binären Befehlen in einem Quellenbefehlssatz zu binären Befehlen in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung kontrastiert;
12 eine Architektur gemäß einer Ausführungsform der Erfindung illustriert;
13 Operationen illustriert, welche durch einen Initiator (z. B. einen Kern/Agenten) und einen oder mehrere andere Kern/Agenten-Übersetzungspuffer (TLBs: Translation Lookaside Buffers) gemäß einer Ausführungsform der Erfindung implementiert werden; und
14 eine Ausführungsform illustriert, welche Fence-Operationen einsetzt, um Datenkohärenz zu gewährleisten.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zum Zwecke der Erklärung zahlreiche spezifische Einzelheiten dargestellt, um ein gründliches Verständnis der Ausführungsformen der nachfolgend beschriebenen Erfindung bereitzustellen. Durchschnittsfachleuten ist jedoch offenkundig, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen werden wohlbekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um ein Verschleiern der unterliegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
BEISPIELHAFTE PROZESSORARCHITEKTUREN UND DATENTYPEN
Ein Befehlssatz umfasst ein oder mehrere Befehlsformate. Ein gegebenes Befehlsformat definiert verschiedene Felder (Anzahl von Bits, Ort von Bits), um u. a. die auszuführende Operation (Opcode) und den(die) Operand(en) zu spezifizieren, an welchen die Operation durchgeführt werden soll. Manche Befehlsformate sind durch die Definition von Befehlstemplates (oder Teilformaten) weiter aufgeschlüsselt. Zum Beispiel können die Befehlstemplates eines gegebenen Befehlsformats so definiert sein, dass sie unterschiedliche Teilsätze der Felder des Befehlsformats aufweisen (die enthaltenen Felder sind typischerweise in der gleichen Reihenfolge, aber wenigstens manche weisen unterschiedliche Bitpositionen auf, weil dort weniger Felder enthalten sind), und/oder so definiert sein, dass sie ein gegebenes Feld aufweisen, welches unterschiedlich interpretiert wird. Dementsprechend wird jeder Befehl einer ISA unter Verwendung eines gegebenen Befehlsformats (und, falls definiert, in einem gegebenen der Befehlstemplates jenes Befehlsformats) ausgedrückt und umfasst Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist ein beispielhafter ADD-Befehl einen spezifischen Opcode und ein Befehlsformat auf, welches ein Opcode-Feld zum Spezifizieren dieses Opcodes und Operandenfelder zum Auswählen von Operanden (Quelle1/Ziel und Quelle 2) umfasst; und ein Auftreten dieses ADD-Befehls in einem Befehlsstrom wird spezifische Inhalte in den Operandenfeldern aufweisen, welche spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, welche als AVX (Advanced Vector Extensions - weiterentwickelte Vektorerweiterungen) (AVX1 und AVX2) bezeichnet werden und das VEX-Codierungsschema (VEX: Vector Extensions - Vektorerweiterungen) verwenden, wurde herausgegeben und/oder veröffentlicht (man siehe z. B. Intel® 64 und IA-32 Architectures Software Developers Manual, Oktober 2011; und Intel® Advanced Vector Extensions Programming Reference, Juni 2011).
Beispielhafte Befehlsformate
Ausführungsformen des/der hier beschriebenen Befehls/Befehle können in verschiedenen Formaten ausgeführt werden. Außerdem sind beispielhafte Systeme, Architekturen und Pipelines nachstehend ausführlich beschrieben. Ausführungsformen des/der Befehls/Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf jene ausführlich beschriebene beschränkt.
Allgemeines vektorfreundliches Befehlsformat
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, welches für Vektorbefehle geeignet ist (z. B. gibt es bestimmte Felder, welche für Vektoroperationen spezifisch sind). Obgleich Ausführungsformen beschrieben sind, bei welchen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen durch das vektorfreundliche Befehlsformat.
1A bis 1B sind Blockdiagramme, welche ein allgemeines vektorfreundliches Befehlsformat und Befehlstemplates davon gemäß Ausführungsformen der Erfindung illustrieren. 1A ist ein Blockdiagramm, welches ein allgemeines vektorfreundliches Befehlsformat und Klasse-A-Befehlstemplates gemäß Ausführungsformen der Erfindung illustriert; während 1B ein Blockdiagramm ist, welches das allgemeine vektorfreundliche Befehlsformat und Klasse-B-Befehlstemplates davon gemäß Ausführungsformen der Erfindung illustriert. Insbesondere ein allgemeines vektorfreundliches Befehlsformat 100, für welches Klasse-A- und Klasse-B-Befehlstemplates definiert sind, welche beide Befehlstemplates ohne Speicherzugriff 105 und Befehlstemplates mit Speicherzugriff 120 umfassen. Der Ausdruck allgemein in dem Zusammenhang des vektorfreundlichen Befehlsformats verweist darauf, dass das Befehlsformat nicht an irgendeinen spezifischen Befehlssatz gebunden ist.
Obgleich Ausführungsformen der Erfindung beschrieben werden, in welchen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit- (4-Byte-) oder 64-Bit- (8-Byte-) Datenelementbreiten (oder -größen) (und somit besteht ein 64-Byte-Vektor aus entweder 16 doppelwortgroßen Elementen oder alternativ 8 vierwortgroßen Elementen); eine 64-Byte-Vektoroperandenlänge (oder -große) mit 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-) Datenelementbreiten (oder -größen); eine 32-Byte-Vektoroperandenlänge (oder - größe) mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit-(1-Byte-) Datenelementbreiten (oder -größen); und eine 16-Byte-Vektoroperandenlänge (oder - größe) mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-) Datenelementbreiten (oder -größen); können alternative Ausführungsformen mehr, weniger und/oder verschiedene Vektoroperandengrößen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder verschiedenen Datenelementbreiten (z. B. 128-Bit- (16-Byte-) Datenelementbreiten) unterstützen.
Die Klasse-A-Befehlstemplates in 1A umfassen Folgendes: 1) innerhalb der Befehlstemplates ohne Speicherzugriff 105 ist ein Befehlstemplate für eine Vollrundungssteuerungsoperation ohne Speicherzugriff 110 und ein Befehlstemplate für eine Datentransformationstypoperation ohne Speicherzugriff 115 gezeigt; und 2) innerhalb der Befehlstemplates mit Speicherzugriff 120 ist ein Temporal-Befehlstemplate mit Speicherzugriff 125 und ein Nichttemporal-Befehlstemplate mit Speicherzugriff 130 gezeigt. Die Klasse-B-Befehlstemplates in 1B umfassen Folgendes: 1) innerhalb der Befehlstemplates ohne Speicherzugriff 105 ist ein Befehlstemplate für eine Schreibmaskensteuer-Partialrundungssteueroperation ohne Speicherzugriff 112 und ein Befehlstemplate für eine Schreibmaskensteuer-VSIZE-Typoperation ohne Speicherzugriff 117 gezeigt; und 2) innerhalb der Befehlstemplates mit Speicherzugriff 120 ist ein Befehlstemplate für eine Schreibmaskensteuerung mit Speicherzugriff 127 gezeigt.
Das allgemeine vektorfreundliche Befehlsformat 100 umfasst die folgenden Felder, welche nachfolgend in der in 1A bis 1B illustrierten Reihenfolge aufgeführt sind.
Formatfeld 140 - ein spezifischer Wert (ein Befehlsformatkennungswert) in diesem Feld identifiziert das vektorfreundliche Befehlsformat eindeutig und dementsprechend das Auftreten von Befehlen in dem vektorfreundlichen Befehlsformat in Befehlsströmen. Als solches ist dieses Feld in dem Sinne optional, dass es nicht für einen Befehlssatz benötigt wird, welcher nur das allgemeine vektorfreundliche Befehlsformat aufweist.
Basisoperationsfeld 142 - sein Inhalt unterscheidet verschiedene Basisoperationen.
Registerindexfeld 144 - sein Inhalt spezifiziert direkt oder durch Adressenerzeugung die Orte der Quell- und Zieloperanden, seien sie in Registern oder im Speicher. Diese umfassen eine ausreichende Anzahl von Bits, um N Register aus einer PxQ-(z. B. 32×512, 16×128, 32×1024, 64×1024)-Registerdatei auszuwählen. Während bei 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 (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu zwei Quellen und ein Ziel unterstützen).
Modifiziererfeld 146 - sein Inhalt unterscheidet das Auftreten von Befehlen im allgemeinen Vektorbefehlsformat, welche den Speicherzugriff spezifizieren, von denen, welche dies nicht tun; d. h. zwischen Befehlstemplates ohne Speicherzugriff 105 und Befehlstemplates mit Speicherzugriff 120. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (wobei in manchen Fällen die Quellen- und/oder Zieladressen unter Verwendung von Werten in Registern spezifiziert werden), während Operationen ohne Speicherzugriff dies nicht tun (z. B. sind die Quelle und die Ziele Register). Während bei einer Ausführungsform dieses Feld auch zwischen drei verschiedenen Arten auswählt, um Speicheradressenberechnungen durchzuführen, können alternative Ausführungsformen mehr, weniger oder verschiedene Arten unterstützen, um Speicheradressenberechnungen durchzuführen.
Ergänzungsoperationsfeld 150 - sein Inhalt unterscheidet, welche einer Vielfalt verschiedener Operationen zusätzlich zu der Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. Bei einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 168, ein Alphafeld 152 und ein Betafeld 154 unterteilt. Das Ergänzungsoperationsfeld 150 ermöglicht, dass gemeinsame Gruppen von Operationen in einem einzelnen Befehl statt in 2, 3 oder 4 Befehlen durchgeführt werden.
Skalierungsfeld 160 - sein Inhalt ermöglicht die Skalierung des Inhalts des Indexfelds zur Speicheradressenerzeugung (z. B. zur Adressenerzeugung, welche 2^Skalierung * Index + Basis verwendet).
Verschiebungsfeld 162A - sein Inhalt wird als Teil der Speicheradressenerzeugung verwendet (z. B. zur Adressenerzeugung, welche 2^Skalierung * Index + Basis + Verschiebung verwendet).
Verschiebungsfaktorfeld 162B (man beachte, dass die Nebeneinanderstellung von Verschiebungsfeld 162A direkt über Verschiebungsfaktorfeld 162B anzeigt, dass das eine oder das andere verwendet wird) - sein Inhalt wird als Teil der Adressenerzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, welcher durch die Größe eines Speicherzugriffs (N) skaliert werden soll - wobei N die Anzahl von Bytes im Speicherzugriff ist (z. B. zur Adressenerzeugung, welche 2^Skalierung * Index + Basis + skalierte Verschiebung verwendet). Redundante Bits niedriger Ordnung werden ignoriert und daher wird der Inhalt des Verschiebungsfaktorfelds mit der Speicheroperandengesamtgröße (N) multipliziert, um die abschließende Verschiebung zu erzeugen, welche beim Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird durch die Prozessorhardware zur Laufzeit basierend auf dem Voll-Opcode-Feld 174 (nachstehend hier beschrieben) und dem Datenmanipulationsfeld 154C bestimmt. Das Verschiebungsfeld 162A und das Verschiebungsfaktorfeld 162B sind in dem Sinne optional, dass sie nicht für die Befehlstemplates ohne Speicherzugriff 105 verwendet werden und/oder unterschiedliche Ausführungsformen nur eines oder keines der beiden implementieren können.
Datenelementbreitenfeld 164 - sein Inhalt unterscheidet, welche von einer Anzahl von Datenelementbreiten verwendet werden soll (bei manchen Ausführungsformen für alle Befehle; bei anderen Ausführungsformen für nur manche der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unterstützt werden, welche einen gewissen Gesichtspunkt der Opcodes verwenden.
Schreibmaskenfeld 170 - sein Inhalt steuert auf einer Basis je Datenelementposition, ob diese Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisoperation und der Ergänzungsoperation reflektiert. Klasse-A-Befehlstemplates unterstützen Zusammenlegungsschreibmaskierung, während Klasse-B-Befehlstemplates sowohl Zusammenlegungs- als auch Nullungsschreibmaskierung unterstützen. Beim Zusammenlegen ermöglichen Vektormasken, dass jeder Satz von Elementen im Ziel während der Ausführung einer Operation (spezifiziert durch die Basisoperation und die Ergänzungsoperation) vor Aktualisierungen geschützt ist; bei einer anderen Ausführungsform, dass der alte Wert jedes Elements des Ziels bewahrt wird, wo das entsprechende Maskenbit eine 0 aufweist. Demgegenüber ermöglichen Nullungsvektormasken, dass jeder Satz von Elementen im Ziel während der Ausführung einer Operation (spezifiziert durch die Basisoperation und die Ergänzungsoperation) genullt wird; bei einer Ausführungsform, dass ein Element des Ziels auf 0 gesetzt wird, wenn das entsprechende Maskenbit einen Wert von 0 aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der ausgeführten Operation zu steuern (d. h. die Spanne von modifizierten Elementen vom ersten bis zum letzten); es ist jedoch nicht notwendig, dass die Elemente, welche modifiziert werden, konsekutiv sind. Somit erlaubt das Schreibmaskenfeld 170 Teilvektoroperationen, einschließlich Lade-, Speicher-, Arithmetik-, Logikoperationen usw. Während Ausführungsformen der Erfindung beschrieben werden, bei welchen der Inhalt des Schreibmaskenfelds 170 eines aus einer Anzahl von Schreibmaskenregistern auswählt, welches die zu verwendende Schreibmaske enthält (und somit der Inhalt des Schreibmaskenfelds 170 indirekt die auszuführende Maskierung identifiziert), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 170 direkt die auszuführende Maskierung spezifiziert.
Unmittelbarfeld 172 - sein Inhalt ermöglicht die Spezifikation eines Unmittelbaren. Dieses Feld ist in dem Sinne optional, dass es bei einer Implementierung des allgemeinen vektorfreundlichen Formats, welches einen Unmittelbaren nicht unterstützt, nicht vorhanden ist und in Befehlen, welche keinen Unmittelbaren verwenden, nicht vorhanden ist.
Klassenfeld 168 - sein Inhalt unterscheidet zwischen verschiedenen Klassen von Befehlen. Unter Bezugnahme auf 1A bis B wählen die Inhalte dieses Felds zwischen Befehlen der Klasse A und Klasse B. In 1A bis B werden Rechtecke mit abgerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Klasse A 168A bzw. Klasse B 168B für das Klassenfeld 168 in 1A bis B).
Befehlstemplates der Klasse A
Im Fall der Klasse-A-Befehlstemplates ohne Speicherzugriff 105 wird das Alphafeld 152 als ein RS-Feld 152A interpretiert, dessen Inhalt unterscheidet, welche der verschiedenen Ergänzungsoperationstypen ausgeführt werden sollen (z. B. sind Runden 152A.1 und Datentransformation 152A.2 jeweils für die Befehlstemplates für eine Rundungstypoperation ohne Speicherzugriff 110 und für eine Datentransformationstypoperation ohne Speicherzugriff 115 spezifiziert), während das Betafeld 154 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden sollen. In den Befehlstemplates ohne Speicherzugriff 105 sind das Skalierungsfeld 160, das Verschiebungsfeld 162A und das Verschiebungsskalierungsfeld 162B nicht vorhanden.
Befehlstemplates ohne Speicherzugriff - Vollrundungssteuertypoperation
In dem Befehlstemplate für eine Vollrundungssteuertypoperation ohne Speicherzugriff 110 wird das Betafeld 154 als ein Rundungssteuerfeld 154A interpretiert, dessen Inhalt(e) eine statische Rundung bereitstellt(bereitstellen). Während bei den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 154A ein SAE-Feld 156 (SAE: Suppress All floating point Exceptions - Unterdrücken aller Gleitkommaausnahmen) und ein Rundungsoperationssteuerfeld 158 umfasst, können alternative Ausführungsformen diese beiden Konzepte in das gleiche Feld codieren oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperationssteuerfeld 158 aufweisen).
SAE-Feld 156 - sein Inhalt unterscheidet, ob das Ausnahmeereignisberichten deaktiviert wird oder nicht; wenn der Inhalt des SAE-Felds 156 anzeigt, dass eine Unterdrückung aktiviert ist, meldet ein gegebener Befehl keine Art von Gleitkommaausnahme-Flag und löst keinen Gleitkommaausnahmebehandler aus.
Rundungsoperationssteuerfeld 158 - sein Inhalt unterscheidet, welche einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden zu Null und Runden zum Nächsten). Dementsprechend ermöglicht das Rundungsoperationssteuerfeld 158 das Verändern des Rundungsmodus auf einer Basis je Befehl. Bei einer Ausführungsform der Erfindung, bei welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, übersteuert der Inhalt des Rundungsoperationssteuerfelds 150 diesen Registerwert.
Befehlstemplates ohne Speicherzugriff - Datentransformationstypoperation
In dem Befehlstemplate für eine Datentransformationstypoperation ohne Speicherzugriff 115 wird das Betafeld 154 als ein Datentransformationsfeld 154B interpretiert, dessen Inhalt unterscheidet, welche einer Anzahl von Datentransformationen ausgeführt werden soll (z. B. keine Datentransformation, Swizzle, Broadcast).
Im Fall eines Klasse-A-Befehlstemplates mit Speicherzugriff 120 wird das Alphafeld 152 als ein Räumungshinweisfeld 152B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in 1A werden Temporal 152B.1 und Nichttemporal 152B.2 jeweils für das Temporal-Befehlstemplate mit Speicherzugriff 125, und das Nichttemporal-Befehlstemplate mit Speicherzugriff 130 spezifiziert), während das Betafeld 154 als ein Datenmanipulationsfeld 154C interpretiert wird, dessen Inhalt unterscheidet, welche einer Anzahl von Datenmanipulationsoperationen (auch als Primitive bekannt) ausgeführt werden soll (z. B. keine Manipulation; Broadcast; Aufwärtsumwandlung einer Quelle und Abwärtsumwandlung eines Ziels). Die Befehlstemplates mit Speicherzugriff 120 umfassen das Skalierungsfeld 160 und optional das Verschiebungsfeld 162A oder das Verschiebungsskalierungsfeld 162B.
Vektorspeicherbefehle führen Vektorladen aus dem Speicher und Vektorspeichern in den Speicher mit Umwandlungsunterstützung durch. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten von dem/in den Speicher auf eine datenelementweise Art, wobei die Elemente, welche tatsächlich übertragen werden, durch die Inhalte der Vektormaske, welche als die Schreibmaske ausgewählt ist, diktiert werden.
Befehlstemplates mit Speicherzugriff - Temporal
Temporale Daten sind Daten, welche wahrscheinlich zeitnah genug wiederverwendet werden, um von Caching zu profitieren. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Weisen, einschließlich vollständigen Ignorierens des Hinweises, implementieren.
Befehlstemplates mit Speicherzugriff - Nichttemporal
Nichttemporale Daten sind Daten, welche wahrscheinlich nicht zeitnah genug wiederverwendet werden, um von Caching in dem 1st-Level-Cache zu profitieren, und sollten Priorität zum Räumen erhalten. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Weisen, einschließlich vollständigen Ignorierens des Hinweises, implementieren.
Befehlstemplates der Klasse B
Im Fall der Befehlstemplates der Klasse B wird das Alphafeld 152 als ein Schreibmaskensteuer-(Z)-Feld 152C interpretiert, dessen Inhalt unterscheidet, ob die durch das Schreibmaskenfeld 170 gesteuerte Schreibmaskierung eine Zusammenlegung oder eine Nullung sein muss.
Im Fall der Befehlstemplates der Klasse B ohne Speicherzugriff 105 wird ein Teil des Betafelds 154 als ein RL-Feld 157A interpretiert, dessen Inhalt unterscheidet, welche der verschiedenen Ergänzungsoperationstypen ausgeführt werden sollen (z. B. sind Runden 157A.1 und Vektorlänge (VSIZE) 157A.2 jeweils für das Befehlstemplate für eine Schreibmaskensteuer-Partialrundungssteueroperation ohne Speicherzugriff 112 und das Befehlstemplate für eine Schreibmaskensteuer-VSIZE-Typoperation ohne Speicherzugriff 117 spezifiziert), während der Rest des Betafelds 154 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden sollen. In den Befehlstemplates ohne Speicherzugriff 105 sind das Skalierungsfeld 160, das Verschiebungsfeld 162A und das Verschiebungsskalierungsfeld 162B nicht vorhanden.
In dem Befehlstemplate für eine Schreibmaskensteuer-Partialrundungssteueroperation ohne Speicherzugriff 110 wird der Rest des Betafelds 154 als ein Rundungsoperationsfeld 159A interpretiert und ist das Ausnahmeereignisberichten deaktiviert (ein gegebener Befehl meldet keine Art von Gleitkommaausnahme-Flag und löst keinen Gleitkommaausnahmebehandler aus).
Rundungsoperationssteuerfeld 159A - ebenso wie das
Rundungsoperationssteuerfeld 158 unterscheidet sein Inhalt, welche einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden zu Null und Runden zum Nächsten). Dementsprechend ermöglicht das Rundungsoperationssteuerfeld 159A das Verändern des Rundungsmodus auf einer Basis je Befehl. Bei einer Ausführungsform der Erfindung, bei welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, übersteuert der Inhalt des Rundungsoperationssteuerfelds 150 diesen Registerwert.
In dem Befehlstemplate für eine Schreibmaskensteuer-VSIZE-Typoperation ohne Speicherzugriff 117 wird der Rest des Betafelds 154 als ein Vektorlängenfeld 159B interpretiert, dessen Inhalt unterscheidet, an welcher einer Anzahl von Datenvektorlängen ausgeführt werden soll (z. B. 128, 256 oder 512 Byte).
Im Fall eines Befehlstemplates der Klasse B mit Speicherzugriff 120 wird ein Teil des Betafelds 154 als ein Broadcast-Feld 157B interpretiert, dessen Inhalt unterscheidet, ob die Broadcast-Typ-Datenmanipulationsoperation durchgeführt werden soll oder nicht, während der Rest des Betafelds 154 als das Vektorlängenfeld 159B interpretiert wird. Die Befehlstemplates mit Speicherzugriff 120 umfassen das Skalierungsfeld 160 und optional das Verschiebungsfeld 162A oder das Verschiebungsskalierungsfeld 162B.
Mit Bezug auf das allgemeine vektorfreundliche Befehlsformat 100 ist ein Voll-Opcode-Feld 174 einschließlich des Formatfelds 140, des Basisoperationsfelds 142 und des Datenelementbreitenfelds 164 gezeigt. Während eine Ausführungsform gezeigt ist, bei welcher das Voll-Opcode-Feld 174 alle dieser Felder umfasst, umfasst das Voll-Opcode-Feld 174 bei Ausführungsformen, welche nicht alle von ihnen unterstützen, weniger als alle dieser Felder. Das Voll-Opcode-Feld 174 stellt den Operationscode (Opcode) bereit.
Das Ergänzungsoperationsfeld 150, das Datenelementbreitenfeld 164 und das Schreibmaskenfeld 170 ermöglichen, dass diese Merkmale auf einer Basis je Befehl in dem allgemeinen vektorfreundlichen Befehlsformat spezifiziert werden.
Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erschafft insofern typisierte Befehle, als dass ermöglicht wird, dass die Maske basierend auf verschiedenen Datenelementbreiten angewandt wird.
Die verschiedenen Befehlstemplates, welche innerhalb Klasse A und Klasse B gefunden werden, sind in verschiedenen Situationen vorteilhaft. Bei manchen Ausführungsformen der Erfindung können unterschiedliche Prozessoren oder unterschiedliche Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Zum Beispiel kann ein Hochleistungs-Allzweck-Außer-Reihenfolge-Kern, welcher für Allzweckberechnung vorgesehen ist, nur Klasse B unterstützen, kann ein Kern, welcher primär für Grafik- und/oder wissenschaftliche (Durchsatz-)Berechnung vorgesehen ist, nur Klasse A unterstützen, und kann ein Kern, welcher für beides vorgesehen ist, beides unterstützen (natürlich liegt ein Kern, welcher eine Mischung aus Templates und Befehlen aus beiden Klassen, aber nicht alle Templates und Befehle aus beiden Klassen aufweist, innerhalb des Geltungsbereichs der Erfindung). Außerdem kann ein einzelner Prozessor mehrere Kerne umfassen, welche alle die gleiche Klasse unterstützen oder bei welchen unterschiedliche Kerne eine unterschiedliche Klasse unterstützen. Beispielsweise kann in einem Prozessor mit separaten Grafik- und Allzweckkernen einer der Grafikkerne, welcher primär für Grafik- und/oder wissenschaftliche Berechnung vorgesehen ist, nur Klasse A unterstützen, während einer oder mehrere der Allzweckkerne für Allzweckberechnung vorgesehene Hochleistungsallzweckkerne mit Außer-Reihenfolge-Ausführung und Registerumbenennung sein können, welche nur Klasse B unterstützen. Ein anderer Prozessor, welcher keinen separaten Grafikkern aufweist, kann einen oder mehrere Allzweck-In-Reihenfolge- oder -Außer-Reihenfolge-Kerne umfassen, welche sowohl Klasse A als auch Klasse B unterstützen. Natürlich können bei unterschiedlichen Ausführungsformen der Erfindung Merkmale aus einer Klasse auch in der anderen Klasse implementiert sein. Programme, welche in einer höheren Sprache geschrieben sind, würden in eine Vielfalt unterschiedlicher ausführbarer Formen umgesetzt werden (z. B. just-in-time-kompiliert oder statisch kompiliert), umfassend: 1) eine Form lediglich mit Befehlen der Klasse(n), welche durch den Zielprozessor zur Ausführung unterstützt wird(werden); oder 2) eine Form mit alternativen Routinen, welche unter Verwendung verschiedener Kombinationen der Befehle aller Klassen geschrieben sind und einen Steuerflusscode aufweisen, welcher die auszuführenden Routinen basierend auf den Befehlen auswählt, welche von dem Prozessor, welcher gerade den Code ausführt, unterstützt werden.
Beispielhaftes spezifisches vektorfreundliches Befehlsformat
2 ist ein Blockdiagramm, welches ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung illustriert.
2 zeigt ein spezifisches vektorfreundliches Befehlsformat 200, welches in dem Sinne spezifisch ist, dass es den Ort, die Größe, die Interpretation und die Reihenfolge von Feldern sowie Werte für manche dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 200 kann verwendet werden, um den x86-Befehlssatz zu erweitern, und dementsprechend sind manche der Felder jenen, welche in dem existierenden x86-Befehlssatz und einer Erweiterung davon (z. B. AVX) verwendet werden, ähnlich oder die gleichen wie diese. Dieses Format bleibt konsistent mit dem Präfixcodierungsfeld, Real-Opcode-Byte-Feld, MOD-R/M-Feld, SIB-Feld, Verschiebungsfeld und den Unmittelbarfeldern des existierenden x86-Befehlssatzes mit Erweiterungen. Die Felder aus 1, auf welche die Felder aus 2 abgebildet sind, sind dargestellt.
Es versteht sich, dass, obwohl Ausführungsformen der Erfindung zu Illustrationszwecken unter Bezugnahme auf das spezifische vektorfreundliche Befehlsformat 200 im Zusammenhang mit dem allgemeinen vektorfreundlichen Befehlsformat 100 beschrieben sind, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 200 beschränkt ist, außer wo dies beansprucht wird. Zum Beispiel zieht das allgemeine vektorfreundliche Befehlsformat 100 eine Vielfalt möglicher Größen für die verschiedenen Felder in Betracht, während das spezifische vektorfreundliche Befehlsformat 200 mit Feldern spezifischer Größen gezeigt ist. Als ein spezifisches Beispiel ist die Erfindung, obwohl das Datenelementbreitenfeld 164 bei dem spezifischen vektorfreundlichen Befehlsformat 200 als ein Ein-Bit-Feld illustriert ist, nicht derart beschränkt (das heißt, das allgemeine vektorfreundliche Befehlsformat 100 zieht andere Größen des Datenelementbreitenfelds 164 in Betracht).
Das allgemeine vektorfreundliche Befehlsformat 100 umfasst die folgenden Felder, welche unten in der in 2A illustrierten Reihenfolge aufgelistet sind.
EVEX-Präfix (Bytes 0 bis 3) 202 - ist in einer Vier-Bit-Form codiert.
Formatfeld 140 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Formatfeld 140 und es umfasst 0x62 (der eindeutige Wert, welcher bei einer Ausführungsform der Erfindung zum Unterscheiden des vektorfreundlichen Befehlsformats verwendet wird).
Die zweiten bis vierten Bytes (EVEX-Bytes 1 bis 3) umfassen eine Anzahl von Bitfeldern, welche eine spezifische Fähigkeit bereitstellen.
REX-Feld 205 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] - R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] -X) und 1157BEX-Byte 1, Bit [5] - B). Die EVEX.R-, EVEX.X- und EVEX.B-Bitfelder stellen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder bereit und sind unter Verwendung einer 1s-Komplementform codiert, d. h. ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes wie in der Technik bekannt ist (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Addieren von EVEX.R, EVEX.X und EVEX.B ausgebildet werden können.
REX'-Feld 110 - dies ist der erste Teil des REX'-Felds 110 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), welches verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. Bei einer Ausführungsform der Erfindung wird dieses Bit zusammen mit anderen, wie nachstehend angegeben, in bitinvertiertem Format zum Unterscheiden (in dem bekannten x86-32-Bit-Modus) von dem BOUND-Befehl, dessen reales Opcode-Byte 62 ist, gespeichert, akzeptiert aber im MOD R/M-Feld (nachstehend beschrieben) nicht den Wert 11 im MOD-Feld; alternative Ausführungsformen der Erfindung speichern dieses und die anderen nachstehend angegebenen Bits nicht in dem invertierten Format. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und der anderen RRR aus anderen Feldern ausgebildet.
Opcode-Map-Feld 215 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
Datenelementbreitenfeld 164 (EVEX-Byte 2, Bit [7] - W) - wird durch die Notation EVEX.W repräsentiert. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente) zu definieren.
EVEX.vvv 220 (EVEX-Byte 2, Bits [6:3]-vvvv) - die Rolle von EVEX.vvvv kann das Folgende umfassen: 1) EVEX.vvvv codiert den ersten Quellenregisteroperanden, welcher in invertierter (1s-Komplement-)Form spezifiziert ist und für Befehle mit 2 oder mehr Quellenoperanden gültig ist; 2) EVEX.vwv codiert den Zielregisteroperanden, welcher für bestimmte Vektorverschiebungen in 1s-Komplementform spezifiziert ist; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und muss 1111b enthalten. Dementsprechend codiert das EVEX.vvvv-Feld 220 die 4 Bits niedriger Ordnung des ersten Quellenregisterspezifikationssymbols, welche in invertierter (1s-Komplement-)Form gespeichert werden. In Abhängigkeit von dem Befehl wird ein zusätzliches verschiedenes EVEX-Bitfeld verwendet, um die Spezifikationssymbolgröße auf 32 Register zu erweitern.
Klassenfeld EVEX.U 168 (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.
Präfixcodierungsfeld 225 (EVEX-Byte 2, Bits [1:0]-pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zu dem Bereitstellen einer Unterstützung für die veralteten SSE-Befehle in dem EVEX-Präfix-Format weist dies auch den Vorteil der Kompaktierung des SIMD-Präfixes auf (statt ein Byte zum Ausdrücken des SIMD-Präfixes zu benötigen, benötigt das EVEX-Präfix nur 2 Bit). Bei einer Ausführungsform werden zum Unterstützen veralteter SSE-Befehle, welche ein SIMD-Präfix (66H, F2H, F3H) sowohl im veralteten Format als auch im EVEX-Präfixformat verwenden, diese veralteten SIMD-Präfixe in das SIMD-Präfix-Codierungsfeld codiert; und zur Laufzeit werden sie in das veraltete SIMD-Präfix expandiert, bevor sie dem PLA des Decodierers bereitgestellt werden (so kann der PLA sowohl das veraltete als auch das EVEX-Format dieser veralteten Befehle ohne Modifikation ausführen). Obwohl neuere Befehle den Inhalt des EVEX-Präfixcodierungsfelds direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen auf eine ähnliche Weise für Konsistenz, erlauben aber, dass unterschiedliche Bedeutungen durch diese veralteten SIMD-Präfixe spezifiziert werden. Eine alternative Ausführungsform kann den PLA umgestalten, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, und benötigt dementsprechend die Erweiterung nicht.
Alphafeld 152 (EVEX-Byte 3, Bit [7] - EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N; auch mit α illustriert) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.
Betafeld 154 (EVEX-Byte 3, Bits [6:4]-SSS, auch bekannt als EVEX.s_2-0, EVEX.r_2-0, EVEX.rr1, EVEX.LLO, EVEX.LLB; auch mit βββ illustriert) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.
REX'-Feld 110 - dies ist der Rest des REX'-Felds und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), welches verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. Dieses Bit wird im bitinvertierten Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv ausgebildet.
Schreibmaskenfeld 170 (EVEX-Byte 3, Bits [2:0]-kkk) - sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie zuvor beschrieben. Bei einer Ausführungsform der Erfindung weist der spezielle Wert EVEX.kkk = 000 ein spezielles Verhalten auf, welches impliziert, dass keine Schreibmaske für den bestimmten Befehl verwendet wird (dies kann in einer Vielfalt von Arten implementiert werden, einschließlich der Verwendung einer Schreibmaske, welche zu allen Einsen festverdrahtet ist, oder einer Hardware, welche die Maskierungshardware umgeht).
Real-Opcode-Feld 230 (Byte 4) ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
MOD-R/M-Feld 240 (Byte 5) umfasst MOD-Feld 242, Reg-Feld 244 und R/M-Feld 246. Wie zuvor beschrieben, unterscheidet der Inhalt des MOD-Felds 242 zwischen Operationen mit Speicherzugriff und Operationen ohne Speicherzugriff. Die Rolle des Reg-Felds 244 kann auf zwei Situationen zusammengefasst werden: Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden oder Behandeltwerden als eine Opcode-Erweiterung und nicht Verwendetwerden zum Codieren eines Befehlsoperanden. Die Rolle des R/M-Felds 246 kann das Folgende umfassen: Codieren des Befehlsoperanden, welcher eine Speicheradresse referenziert, oder Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden.
Byte für Skalierung, Index, Basis (SIB) (Byte 6) - Wie zuvor beschrieben, wird der Inhalt des Skalierungsfelds 150 zur Speicheradressenerzeugung verwendet. SIB.xxx 254 und SIB.bbb 256 - auf die Inhalte dieser Felder wurde zuvor hinsichtlich der Registerindizes Xxxx und Bbbb Bezug genommen.
Verschiebungsfeld 162A (Bytes 7 bis 10) - wenn MOD-Feld 242 10 enthält, sind Bytes 7 bis 10 das Verschiebungsfeld 162A, und es funktioniert genauso wie die veraltete 32-Bit-Verschiebung (disp32) und arbeitet bei Byte-Granularität.
Verschiebungsfaktorfeld 162B (Byte 7) - wenn das MOD-Feld 242 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 162B. Der Ort dieses Felds ist der gleiche wie jener der 8-Bit-Verschiebung (disp8) des veralteten x86-Befehlssatzes, welche bei Byte-Granularität arbeitet. Da disp8 vorzeichenerweitert ist, kann es nur zwischen -128 und 127 Bytes Offsets adressieren; in Bezug auf 64-Byte-Cachezeilen verwendet disp8 8 Bit, welche auf nur vier wirklich nützliche Werte eingestellt werden können -128, -64, 0 und 64; da oft ein größerer Bereich benötigt wird, wird disp32 verwendet; disp32 benötigt jedoch 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 162B eine Neuinterpretation von disp8; beim Verwenden des Verschiebungsfaktorfelds 162B wird die tatsächliche Verschiebung bestimmt durch den Inhalt des Verschiebungsfaktorfelds multipliziert mit der Größe des Speicheroperandenzugriffs (N). Diese Art Verschiebung wird als disp8*N bezeichnet. Dies reduziert die durchschnittliche Befehlslänge (es wird ein einzelnes Byte für die Verschiebung verwendet, aber mit einem viel größeren Bereich). Eine solche komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist, und daher müssen die redundanten Bits niedriger Ordnung des Adressenversatzes nicht codiert werden. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 162B die veraltete 8-Bit-Verschiebung des x86-Befehlssatzes. Dementsprechend wird das Verschiebungsfaktorfeld 162B auf die gleiche Weise wie eine 8-Bit-Verschiebung des x86-Befehlssatzes codiert (solange es keine Änderungen in den ModRM/SIB-Codierungsregeln gibt), mit der einzigen Ausnahme, dass disp8 zu disp8*N überladen wird. Mit anderen Worten gibt es keine Veränderungen in den Codierungsregeln oder Codierungslängen, sondern nur bei der Interpretation des Verschiebungswertes durch Hardware (welche die Verschiebung mit der Größe des Speicheroperanden skalieren muss, um einen byteweisen Adressenversatz zu erhalten).
Unmittelbarfeld 172 arbeitet wie zuvor beschrieben.
Voll-Opcode-Feld
2B ist ein Blockdiagramm, welches die Felder des spezifischen vektorfreundlichen Befehlsformats 200, welche das Voll-Opcode-Feld 174 ausmachen, gemäß einer Ausführungsform der Erfindung illustriert. Insbesondere umfasst das Voll-Opcode-Feld 174 das Formatfeld 140, das Basisoperationsfeld 142 und das Datenelementbreiten-(W)-Feld 164. Das Basisoperationsfeld 142 umfasst das Präfixcodierungsfeld 225, das Opcode-Map-Feld 215 und das Real-Opcode-Feld 230.
Registerindexfeld
2C ist ein Blockdiagramm, welches die Felder des spezifischen vektorfreundlichen Befehlsformats 200, welche das Registerindexfeld 144 ausmachen, gemäß einer Ausführungsform der Erfindung illustriert. Insbesondere umfasst das Registerindexfeld 144 das REX-Feld 205, das REX'-Feld 210, das MODR/M.reg-Feld 244, das MODR/M.r/m-Feld 246, das VVVV-Feld 220, das xxx-Feld 254 und das bbb-Feld 256.
Ergänzungsoperationsfeld
2D ist ein Blockdiagramm, welches die Felder des spezifischen vektorfreundlichen Befehlsformats 200, welche das Ergänzungsoperationsfeld 150 ausmachen, gemäß einer Ausführungsform der Erfindung illustriert. Wenn das Klassen-(U)-Feld 168 0 enthält, bezeichnet es EVEX.U0 (Klasse A 168A); wenn es 1 enthält, bezeichnet es EVEX.U1 (Klasse B 168B). Wenn U = 0 ist und das MOD-Feld 242 11 enthält (was eine Operation ohne Speicherzugriff bezeichnet), wird das Alphafeld 152 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 152A interpretiert. Wenn das rs-Feld 152A eine 1 enthält (Runden 152A.1), wird das Betafeld 154 (EVEX-Byte 3, Bits [6:4]-SSS) als das Rundungssteuerfeld 154A interpretiert. Das Rundungssteuerfeld 154A umfasst ein Ein-Bit-SAE-Feld 156 und ein Zwei-Bit-Rundungsoperationsfeld 158. Wenn das rs-Feld 152A eine 0 enthält (Datentransformation 152A.2), wird das Betafeld 154 (EVEX-Byte 3, Bits [6:4]-SSS) als ein Drei-Bit-Datentransformationsfeld 154B interpretiert. Wenn U = 0 ist und das MOD-Feld 242 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff bezeichnet), wird das Alphafeld 152 (EVEX-Byte 3, Bit [7-] - EH) als das Räumungshinweis-(EH)-Feld 152B interpretiert, und das Betafeld 154 (EVEX-Byte 3, Bits [6:4]-SSS) wird als ein Drei-Bit-Datenmanipulationsfeld 154C interpretiert.
Wenn U = 1 ist, wird das Alphafeld 152 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuer-(Z)-Feld 152C interpretiert. Wenn U = 1 ist und das MOD-Feld 242 11 enthält (was eine Operation ohne Speicherzugriff bezeichnet), wird ein Teil des Betafelds 154 (EVEX-Byte 3, Bit [4]- So) als das RL-Feld 157A interpretiert; wenn es eine 1 enthält (Rundung 157A.1), wird der Rest des Betafelds 154 (EVEX-Byte 3, Bit [6-5]- S_2-1) als das Rundungsoperationsfeld 159A interpretiert, während, wenn das RL-Feld 157A eine 0 enthält (VSIZE 157.A2), der Rest des Betafelds 154 (EVEX-Byte 3, Bit [6-5]- S_2-1) als das Vektorlängenfeld 159B (EVEX-Byte 3, Bit [6-5]- L_1-0) interpretiert wird. Wenn U = 1 ist und das MOD-Feld 242 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff bezeichnet), wird das Betafeld 154 (EVEX-Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 159B (EVEX-Byte 3, Bit [6-5]- L_1-0) und das Broadcast-Feld 157B (EVEX-Byte 3, Bit [4]- B) interpretiert.
Beispielhafte Registerarchitektur

3 ist ein Blockdiagramm einer Registerarchitektur 300 gemäß einer Ausführungsform der Erfindung. Bei der illustrierten Ausführungsform gibt es 32 Vektorregister 310, welche 512 Bit breit sind; diese Register werden als zmm0 bis zmm31 bezeichnet. Die 256 Bit niedriger Ordnung der unteren 16 zmm-Register werden auf Register ymm0 bis 16 überlagert. Die 128 Bit niedriger Ordnung der unteren 16 zmm-Register (die 128 Bit niedriger Ordnung der ymm-Register) werden auf Register xmm0 bis 15 überlagert. Das spezifische vektorfreundliche Befehlsformat 200 arbeitet auf diesen überlagerten Registerdateien, wie in den nachfolgenden Tabellen illustriert ist.

Anpassbare Vektorlänge	Klasse	Operationen	Register
Befehlstemplates, welche das Vektorlängenfeld 159B nicht umfassen	A ( 1A; U = 0)	110, 115, 125, 130	zmm-Register (die Vektorlänge beträgt 64 Byte)
	B ( 1B; U = 1)	112	zmm-Register (die Vektorlänge beträgt 64 Byte)
Befehlstemplates, welche das Vektorlängenfeld 159B umfassen	B ( 1B; U = 1)	117, 127	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) in Abhängigkeit von dem Vektorlängenfeld 159B

Mit anderen Worten wählt das Vektorlängenfeld 159B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede solche kürzere Länge die Hälfte der Länge der vorhergehenden Länge ist; und Befehlstemplates ohne das Vektorlängenfeld 159B arbeiten auf der maximalen Vektorlänge. Weiterhin arbeiten die Befehlstemplates der Klasse B des spezifischen vektorfreundlichen Befehlsformats 200 bei einer Ausführungsform auf gepackten oder skalaren Gleitkommadaten mit einfacher/doppelter Genauigkeit und gepackten oder skalaren Ganzzahlendaten. Skalare Operationen sind Operationen, welche auf der Datenelementposition niedrigster Ordnung in einem zmm-/ymm-/xmm-Register ausgeführt werden; in Abhängigkeit von der Ausführungsform bleiben die Datenelementpositionen höherer Ordnung entweder gleich wie vor dem Befehl oder sie werden auf Null gesetzt.
Schreibmaskenregister 315 - bei der illustrierten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), jeweils mit einer Größe von 64 Bit. Bei einer alternativen Ausführungsform weisen die Schreibmaskenregister 315 eine Größe von 16 Bit auf. Wie zuvor beschrieben, kann bei einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als eine Schreibmaske verwendet werden; wenn die Codierung, welche normalerweise k0 angeben würde, für eine Schreibmaske verwendet wird, wählt sie eine festverdrahtete Schreibmaske von 0xFFFF aus, wobei eine Schreibmaskierung für diesen Befehl wirksam deaktiviert wird.
Allzweckregister 325 - bei der illustrierten Ausführungsform gibt es sechzehn 64-Bit-Allzweckregister, welche zusammen mit den existierenden x86-Adressierungsmodi zum Adressieren von Speicheroperanden verwendet werden. Diese Register werden mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.
Skalare Gleitkommastapel-Registerdatei (x87-Stapel) 345, auf welche die MMX-gepackte ganzzahlige flache Registerdatei 350 aliasiert ist - bei der illustrierten Ausführungsform ist der x87-Stapel ein Stapel mit acht Elementen, welcher zur Durchführung von skalaren Gleitkommaoperationen auf 32-/64-/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzerweiterung verwendet wird; während die MMX-Register dafür verwendet werden, Operationen auf gepackten 64-Bit-Ganzzahlendaten durchzuführen sowie Operanden für manche Operationen zu halten, welche zwischen den MMX- und XMM-Registern durchgeführt werden.
Alternative Ausführungsformen der Erfindung können breitere oder schmalere Register verwenden. Außerdem können alternative Ausführungsformen der Erfindung mehr, weniger oder verschiedene Registerdateien und Register verwenden.
Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
Prozessorkerne können auf verschiedene Arten, für verschiedene Zwecke und in unterschiedlichen Prozessoren implementiert werden. Beispielsweise können Implementierungen solcher Kerne Folgendes umfassen: 1) einen Allzweck-In-Reihenfolge-Kern, welcher für Allzweckberechnung vorgesehen ist; 2) einen Hochleistungs-Allzweck-Außer-Reihenfolge-Kern, welcher für Allzweckberechnung vorgesehen ist; 3) einen Spezialkern, welcher primär für Grafik- und/oder wissenschaftliche (Durchsatz-)Berechnung vorgesehen ist. Implementierungen unterschiedlicher Prozessoren können Folgendes umfassen: 1) eine CPU, welche einen oder mehrere für Allzweckberechnung vorgesehene Allzweck-In-Reihenfolge-Kerne und/oder einen oder mehrere für Allzweckberechnung vorgesehene Allzweck-Außer-Reihenfolge-Kerne umfasst; und 2) einen Koprozessor, welcher einen oder mehrere Spezialkerne aufweist, welche primär für Grafik und/oder Wissenschaft (Durchsatz) vorgesehen sind. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, welche Folgendes umfassen können: 1) den Koprozessor auf einem von der CPU getrennten Chip; 2) den Koprozessor auf einem separaten Die in dem gleichen Gehäuse wie eine CPU; 3) den Koprozessor auf dem gleichen Die wie eine CPU (in diesem Fall wird ein solcher Koprozessor manchmal als Speziallogik, wie etwa als integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik, oder als Spezialkerne bezeichnet); und 4) ein System auf einem Chip, welches auf dem gleichen Die die beschriebene CPU (manchmal als der(die) Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet), den vorstehend beschriebenen Koprozessor und zusätzliche Funktionalitäten umfassen kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computerarchitekturen.
4A ist ein Blockdiagramm, welches sowohl eine beispielhafte In-Reihenfolge-Pipeline als auch eine beispielhafte Registerumbenennungs-Außer-Reihenfolge-Ausgabe/Ausführungs-Pipeline gemäß Ausführungsformen der Erfindung illustriert. 4B ist ein Blockdiagramm, welches sowohl eine beispielhafte Ausführungsform eines In-Reihenfolge-Architekturkerns als auch eines beispielhaften Registerumbenennungs-Außer-Reihenfolge-Ausgabe/Ausführung-Architekturkern, welcher in einem Prozessor aufgenommen werden soll, gemäß Ausführungsformen der Erfindung illustriert. Die Kästchen mit durchgezogener Linie aus 4A bis B illustrieren eine In-Reihenfolge-Pipeline und einen In-Reihenfolge-Kern, während die optionale Addition der Kästchen mit unterbrochener Linie die Registerumbenennung, Außer-Reihenfolge-Ausgabe/Ausführungs-Pipeline und -Kern illustriert. Unter der Annahme, dass der In-Reihenfolge-Gesichtspunkt eine Teilmenge des Außer-Reihenfolge-Gesichtspunkts ist, wird der Außer-Reihenfolge-Gesichtspunkt beschrieben.
In 4A umfasst eine Prozessor-Pipeline 400 eine Abrufstufe 402, eine Längendecodierstufe 404, eine Decodierstufe 406, eine Zuordnungsstufe 408, eine Umbenennungsstufe 410, eine Ablaufsteuerungsstufe (auch bekannt als Verteilungs- oder Ausgabestufe) 412, eine Registerlese-/Speicherlesestufe 414, eine Ausführungsstufe 416, eine Zurückschreibe-/Speicherschreibestufe 418, eine Ausnahmebehandlungsstufe 422 und eine Übergabestufe 424.
4B zeigt einen Prozessorkern 490, welcher eine Frontend-Einheit 430 umfasst, welche mit einer Ausführungsfunktionseinheit 450 gekoppelt ist, und beide sind mit einer Speichereinheit 470 gekoppelt. Der Kern 490 kann ein RISC-Kern (RISC: Reduced Instruction Set Computing -Berechnung mit reduziertem Befehlssatz), ein CISC-Kern (CISC: Complex Instruction Set Computing - Berechnung mit komplexem Befehlssatz), ein VLIW-Kern (VLIW: Very Long Instruction Word - sehr langes Befehlswort) oder ein hybrider oder alternativer Kerntyp sein. Als noch eine andere Option kann der Kern 490 ein Spezialkern, wie beispielsweise ein Netz- oder Kommunikationskern, eine Kompressionsfunktionseinheit, ein Koprozessorkern, ein GPGPU-Kern (GPGPU: General Purpose Computing Graphics Processing Unit - Allzweckberechnung-Grafikverarbeitungseinheit), Grafikkern oder dergleichen sein.
Die Frontend-Einheit 430 beinhaltet eine Zweigprädiktionseinheit 432, welche mit einer Befehlscacheeinheit 434 gekoppelt ist, welche mit einem Befehls-TLB (Translation Lookaside Buffer) 436 gekoppelt ist, welcher mit einer Befehlsabrufeinheit 438 gekoppelt ist, welche mit einer Decodiereinheit 440 gekoppelt ist. Die Decodiereinheit 440 (oder der Decodierer) kann Befehle decodieren und als eine Ausgabe erzeugen: eine(n) oder mehrere Mikrooperationen, Mikrocodeeintragspunkte, Mikrobefehle oder andere Befehle oder andere Steuersignale, welche aus den ursprünglichen Befehlen decodiert wurden oder diese anderweitig reflektieren oder anderweitig davon abgeleitet sind. Die Decodiereinheit 440 kann unter Verwendung zahlreicher verschiedener Mechanismen implementiert werden. Beispiele für geeignete Mechanismen umfassen, sind aber nicht beschränkt auf, Nachschlagetabellen, Hardwareumsetzungen, programmierbare Logikarrays (PLA: Programmable Logic Arrays), Mikrocode-Nur-Lese-Speicher (ROM: Read Only Memories) usw. In einer Ausführungsform umfasst der Kern 490 einen Mikrocode-ROM oder ein anderes Medium, welches Mikrocode für bestimmte Makrobefehle speichert (z. B. in Decodiereinheit 440 oder anderweitig innerhalb der Frontend-Einheit 430). Die Decodiereinheit 440 ist mit einer Umbenennungs-/Zuordnungseinheit 452 in der Ausführungsfunktionseinheit 450 gekoppelt.
Die Ausführungsfunktionseinheit 450 umfasst die Umbenennungs-/Zuordnungseinheit 452, welche mit einer Ausbuchungseinheit 454 und einem Satz einer oder mehrerer Ablaufsteuereinheit(en) 456 gekoppelt ist. Die Ablaufsteuereinheit(en) 456 repräsentiert(repräsentieren) eine beliebige Anzahl unterschiedlicher Ablaufsteuerungen, welche Reservierungsstationen, ein zentrales Befehlsfenster usw. umfassen. Die Ablaufsteuereinheit(en) 456 ist(sind) mit der(den) physischen Registerdatei(en)einheit(en) 458 gekoppelt. Jede der physischen Registerdatei(en)einheiten 458 repräsentiert eine oder mehrere physische Registerdateien, von welchen verschiedene einen oder mehrere unterschiedliche Datentypen speichern, wie beispielsweise skalare Ganzzahlen, skalare Gleitkommazahlen, gepackte Ganzzahlen, gepackte Gleitkommazahlen, Vektorganzzahlen, Vektorgleitkommazahlen, Status (z. B. einen Befehlszeiger, welcher die Adresse des nächsten Befehls ist, welcher ausgeführt werden soll) usw. Bei einer Ausführungsform umfasst die physische Registerdatei(en)einheit 458 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Allzweckregister bereitstellen. Die physische(n) Registerdatei(en)einheit(en) 458 ist(sind) durch die Ausbuchungseinheit 454 überlappt, um verschiedene Wege zu illustrieren, auf welchen eine Registerumbenennung und Außer-Reihenfolge-Ausführung implementiert werden können (z. B. unter Verwendung eines Neuordnungspuffers(von Neuordnungspuffern) und einer Ausbuchungsregisterdatei(von Ausbuchungsregisterdateien); unter Verwendung einer Zukunftsdatei(von Zukunftsdateien), eines Historienpuffers(von Historienpuffern) und einer Ausbuchungsregisterdatei(von Ausbuchungsregisterdateien); unter Verwendung von Registerabbildungen und eines Registerpools usw.). Die Ausbuchungseinheit 454 und die physische(n) Registerdatei(en)einheit(en) 458 sind mit dem(den) Ausführungscluster(n) 460 gekoppelt. Der(die) Ausführungscluster 460 umfasst(umfassen) einen Satz einer oder mehrerer Ausführungseinheiten 462 und einen Satz einer oder mehrerer Speicherzugriffseinheiten 464. Die Ausführungseinheiten 462 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und auf verschiedenen Datentypen (z. B. Skalargleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzahl, Vektorgleitkomma) durchführen. Während manche Ausführungsformen eine Anzahl von Ausführungseinheiten umfassen können, welche für spezifische Funktionen oder Funktionssätze dediziert sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten umfassen, welche allesamt alle Funktionen durchführen. Die Ablaufsteuereinheit(en) 456, die physische(n) Registerdatei(en)einheit(en) 458 und der(die) Ausführungscluster 460 sind als möglicherweise mehrere gezeigt, weil bestimmte Ausführungsformen getrennte Pipelines für bestimmte Typen von Daten/Operationen erschaffen (z. B. eine Skalarganzzahl-Pipeline, eine Skalargleitkomma-/gepackte Ganzzahl-/gepackte Gleitkomma-/Vektorganzzahl-/Vektorgleitkomma-Pipeline und/oder eine Speicherzugriffs-Pipeline, welche jeweils ihre eigene Ablaufsteuereinheit, physische Registerdatei(en)einheit und/oder Ausführungscluster aufweisen - und im Fall einer getrennten Speicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, bei welchen nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 464 aufweist). Es versteht sich auch, dass, wenn getrennte Pipelines verwendet werden, eine oder mehrere dieser Pipelines Außer-Reihenfolge-Ausgabe-/Ausführung und der Rest In-Reihenfolge sein können.
Der Satz Speicherzugriffseinheiten 464 ist mit der Speichereinheit 470 gekoppelt, welche eine Daten-TLB-Einheit 472 umfasst, welche mit einer Datencacheeinheit 474 gekoppelt ist, welche mit einer Level-2-(L2)-Cacheeinheit 476 gekoppelt ist. Bei einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 464 eine Ladeeinheit, eine Adressenspeichereinheit und eine Datenspeichereinheit umfassen, von welchen jede mit der Daten-TLB-Einheit 472 in der Speichereinheit 470 gekoppelt ist. Die Befehlscacheeinheit 434 ist weiterhin mit einer Level-2-(L2)-Cacheeinheit 476 in der Speichereinheit 470 gekoppelt. Die L2-Cacheeinheit 476 ist mit einem oder mehreren anderen Cache-Leveln und schließlich mit einem Hauptspeicher verbunden.
Beispielsweise kann die beispielhafte Registerumbenennungs-Außer-Reihenfolge-Ausgabe-/Ausführungskernarchitektur die Pipeline 400 wie folgt implementieren: 1) der Befehlsabruf 438 führt die Abruf- und Längendecodierstufen 402 und 404 durch; 2) die Decodiereinheit 440 führt die Decodierstufe 406 durch; 3) die Umbenennungs-/Zuordnungseinheit 452 führt die Zuordnungsstufe 408 und die Umbenennungsstufe 410 durch; 4) die Ablaufsteuereinheit(en) 456 führt(führen) die Ablaufsteuerungsstufe 412 durch; 5) die physische(n) Registerdatei(en)einheit(en) 458 und die Speichereinheit 470 führen die Registerlese-/Speicherlesestufe 414 durch; der Ausführungscluster 460 führt die Ausführungsstufe 416 durch; 6) die Speichereinheit 470 und die physische(n) Registerdatei(en)einheit(en) 458 führen die Zurückschreibe-/Speicherschreibestufe 418 durch; 7) verschiedene Einheiten können in der Ausnahmebehandlungsstufe 422 beteiligt sein und 8) die Ausbuchungseinheit 454 und die physische(n) Registerdatei(en)einheit(en) 458 führen die Übergabestufe 424 durch.
Der Kern 490 kann einen oder mehrere Befehlssätze unterstützen (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, welche mit neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), was die hier beschriebenen Befehle umfasst. Bei einer Ausführungsform umfasst der Kern 490 Logik zum Unterstützen einer Befehlssatzerweiterung gepackte Daten (z. B. AVX1, AVX2), wodurch ermöglicht wird, dass die durch viele Multimediaanwendungen verwendeten Operationen unter Verwendung gepackter Daten durchgeführt werden.
Es versteht sich, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weisen vornehmen kann, was Zeitscheiben-Multithreading, simultanes Multithreading (wobei ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, welche der physische Kern simultan im Multithreading behandelt) oder eine Kombination davon (z. B. Zeitscheibenabruf und -Decodierung und simultanes Multithreading danach, wie etwa bei der Hyperthreading-Technologie von Intel®) umfasst.
Während eine Registerumbenennung in dem Zusammenhang einer Außer-Reihenfolge-Ausführung beschrieben ist, versteht es sich, dass eine Registerumbenennung in einer In-Reihenfolge-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch getrennte Befehls- und Datencacheeinheiten 434/474 und eine gemeinsam genutzte L2-Cacheeinheit 476 umfasst, können alternative Ausführungsformen einen einzelnen internen Cache sowohl für Befehle als auch für Daten aufweisen, wie etwa beispielsweise einen internen Level-1-(L1)-Cache oder mehrere Level eines internen Cache. Bei manchen Ausführungsformen kann das System eine Kombination eines internen Cache und eines externen Cache umfassen, welcher bezüglich des Kerns und/oder des Prozessors extern ist. Alternativ kann der gesamte Cache bezüglich des Kerns und/oder des Prozessors extern sein.
5A bis B illustrieren ein Blockdiagramm einer spezifischeren beispielhaften In-Reihenfolge-Kernarchitektur, wobei der Kern einer von mehreren Logikblöcken (einschließlich anderer Kerne desselben Typs und/oder unterschiedlichen Typs) in einem Chip wäre. Die Logikblöcke kommunizieren durch ein Zwischenverbindungsnetz mit hoher Bandbreite (z. B. ein Ringnetz) in Abhängigkeit von der Anwendung mit einer festen Funktionslogik, Speicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik.
5A ist ein Blockdiagramm eines Einzelprozessorkerns zusammen mit seiner Verbindung zu dem On-Die-Zwischenverbindungsnetz 502 und mit seinem lokalen Teilsatz des Level-2-(L2)-Cache 504 gemäß Ausführungsformen der Erfindung. Bei einer Ausführungsform unterstützt ein Befehlsdecodierer 500 den x86-Befehlssatz mit einer Befehlssatzerweiterung für gepackte Daten. Ein L1-Cache 506 ermöglicht Zugriffe mit geringer Latenz auf Cachespeicher in die Skalar- und Vektoreinheiten. Während bei einer Ausführungsform (um die Gestaltung zu vereinfachen) eine Skalareinheit 508 und eine Vektoreinheit 510 getrennte Registersätze verwenden (Skalarregister 512 bzw. Vektorregister 514) und Daten, welche zwischen ihnen übertragen werden, in einen Speicher geschrieben werden und dann aus einem Level-1-(L1)-Cache 506 zurückgelesen werden, können alternative Ausführungsformen der Erfindung einen unterschiedlichen Ansatz verwenden (z. B. einen einzigen Registersatz verwenden oder einen Kommunikationspfad umfassen, welcher ermöglicht, dass Daten zwischen den zwei Registerdateien übertragen werden, ohne geschrieben und zurückgelesen zu werden).
Der lokale Teilsatz des L2-Cache 504 ist Teil eines globalen L2-Cache, welcher in getrennte lokale Teilsätze, einer je Prozessorkern, unterteilt ist. Jeder Prozessorkern weist einen direkten Zugriffspfad auf seinen eigenen lokalen Teilsatz des L2-Cache 504 auf. Daten, welche durch einen Prozessorkern gelesen werden, werden in seinem L2-Cacheteilsatz 504 gespeichert, und auf sie kann schnell parallel mit anderen Prozessorkernen, welche auf ihre eigenen lokalen L2-Cacheteilsätze zugreifen, zugegriffen werden. Daten, welche durch einen Prozessorkern geschrieben werden, werden in seinem eigenen L2-Cacheteilsatz 504 gespeichert und werden bei Bedarf aus anderen Teilsätzen ausgeräumt. Das Ringnetz stellt die Kohärenz gemeinsam genutzter Daten sicher. Das Ringnetz ist bidirektional, um zu ermöglichen, dass Agenten, wie beispielsweise Prozessorkerne, L2-Caches und andere Logikblöcke, innerhalb des Chips miteinander kommunizieren. Jeder Ringdatenpfad ist je Richtung 1012 Bit breit.
5B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 5A gemäß Ausführungsformen der Erfindung. 5B umfasst einen L1-Datencache 506A, welcher Teil des L1-Cache 504 ist, sowie mehr Einzelheiten hinsichtlich der Vektoreinheit 510 und der Vektorregister 514. Insbesondere ist die Vektoreinheit 510 eine 16-breite Vektorverarbeitungseinheit (VPU: Vector Processing Unit) (siehe die 16-breite ALU 528), welche einen oder mehr als einen von Ganzzahlbefehlen, Gleitkommabefehlen mit einfacher Genauigkeit und Gleitkommabefehlen mit doppelter Genauigkeit ausführt. Die VPU unterstützt Swizzling der Registereingaben mit Swizzle-Einheit 520, numerisches Umwandeln mit numerischen Umwandlungseinheiten 522A bis B und Replikation mit Replikationseinheit 524 auf der Speichereingabe. Schreibmaskenregister 526 ermöglichen eine Vorhersage resultierender Vektorschreibvorgänge.
6 ist ein Blockdiagramm eines Prozessors 600, welcher mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und integrierte Grafik aufweisen kann, gemäß Ausführungsformen der Erfindung. Die Kästchen mit durchgezogener Linie in 6 illustrieren einen Prozessor 600 mit einem einzelnen Kern 602A, einem Systemagenten 610, einem Satz einer oder mehrerer Busssteuereinheiten 616, während die optionale Hinzunahme der Kästchen mit unterbrochener Linie einen alternativen Prozessor 600 mit mehreren Kernen 602A bis N, einen Satz einer oder mehrerer integrierter Speichersteuereinheit(en) 614 in der Systemagenteneinheit 610 und eine Speziallogik 608 illustriert.
Dementsprechend können verschiedene Implementierungen des Prozessors 600 Folgendes umfassen: 1) eine CPU, wobei die Speziallogik 608 integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik ist (welche einen oder mehrere Kerne umfassen kann), und wobei die Kerne 602A bis N ein oder mehrere Allzweckkerne sind (z. B. Allzweck-In-Reihenfolge-Kerne, Allzweck-Außer-Reihenfolge-Kerne, eine Kombination der beiden); 2) einen Koprozessor, wobei die Kerne 602A bis N eine große Anzahl von Allzweckkernen sind, welche primär für Grafik und/oder Wissenschaft (Durchsatz) vorgesehen sind; und 3) einen Koprozessor, wobei die Kerne 602A bis N eine große Anzahl Allzweck-In-Reihenfolge-Kerne sind. Dementsprechend kann der Prozessor 600 ein Allzweckprozessor, ein Koprozessor oder Spezialprozessor, wie beispielsweise ein Netz- oder Kommunikationsprozessor, eine Kompressionsfunktionseinheit, ein Grafikprozessor, GPGPU (Allweckgrafikverarbeitungseinheit), ein Hochdurchsatz-MIC-Koprozessor (MIC: Many Integrated Core - viele integrierte Kerne) (welcher 30 oder mehr Kerne umfasst), ein eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 600 kann ein Teil eines oder mehrerer Substrate, welche eine beliebige einer Anzahl von Prozesstechnologien verwenden, wie beispielsweise BiCMOS, CMOS oder NMOS, sein und/oder auf solchen implementiert sein.
Die Speicherhierarchie umfasst ein oder mehrere Level eines Cache innerhalb der Kerne, einen Satz oder einen oder mehrere gemeinsam genutzte Cacheeinheiten 606 und externen Speicher (nicht dargestellt), welcher mit dem Satz integrierter Speichersteuereinheiten 614 gekoppelt ist. Der Satz gemeinsam genutzter Cacheeinheiten 606 kann einen oder mehrere Mid-Level-Caches, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Level eines Cache, einen Last-Level-Cache (LLC) und/oder Kombinationen davon umfassen. Während bei einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 612 die integrierte Grafiklogik 608, den Satz gemeinsam genutzter Cacheeinheiten 606 und die Systemagenteneinheit 610/integrierte Speichersteuereinheit(en) 614 miteinander verbindet, können alternative Ausführungsformen eine beliebige Anzahl wohlbekannter Techniken zum Zwischenverbinden solcher Einheiten verwenden. Bei einer Ausführungsform wird Kohärenz zwischen einer oder mehreren Cacheeinheiten 606 und Kernen 602-A bis N unterhalten.
Bei manchen Ausführungsformen sind ein oder mehrere der Kerne 602A bis N zu einer Multi-Thread-Verarbeitung fähig. Der Systemagent 610 umfasst solche Komponenten, welche die Kerne 602A bis N koordinieren und betreiben. Die Systemagenteneinheit 610 kann beispielsweise eine Leistungssteuerungseinheit (PCU) und eine Anzeigeeinheit umfassen. Die PCU kann Logik und Komponenten sein oder umfassen, welche zum Regulieren des Leistungszustands der Kerne 602A bis N und der integrierten Grafiklogik 608 benötigt werden. Die Anzeigeeinheit dient dem Ansteuern einer oder mehrerer extern verbundener Anzeigen.
Die Kerne 602A bis N können hinsichtlich eines Architekturbefehlssatzes homogen oder heterogen sein; d. h. zwei oder mehr der Kerne 602A bis N können fähig sein, den gleichen Befehlssatz auszuführen, während andere fähig sein können, nur eine Teilmenge dieses Befehlssatzes oder einen verschiedenen Befehlssatz auszuführen.
7 bis 10 sind Blockdiagramme beispielhafter Computerarchitekturen. Andere Systemgestaltungen und Konfigurationen, welche in der Technik für Laptops, Desktops, Handheld-PC, persönliche digitale Assistenten, technische Workstations, Server, Netzwerkvorrichtungen, Netzwerk-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSP), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, portable Medienabspieler, tragbare Vorrichtungen und verschiedene andere elektronische Vorrichtungen bekannt sind, sind ebenfalls geeignet. Allgemein sind eine große Vielfalt von Systemen oder elektronischen Vorrichtungen, welche zum Einbinden eines Prozessors und/oder anderer Ausführungslogik fähig sind, wie hier offenbart, allgemein geeignet.
Nun unter Bezugnahme auf 7 ist ein Blockdiagramm eines Systems 700 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 700 kann einen oder mehrere Prozessoren 710, 715 umfassen, welche mit einem Steuerungs-Hub 720 gekoppelt sind. Bei einer Ausführungsform umfasst der Steuerungs-Hub 720 einen Grafikspeichersteuerungs-Hub (GMCH, Graphics Memory Controller Hub) 790 und einen Eingabe-/Ausgabe-Hub (IOH, Input/Output Hub) 750 (welche sich auf separaten Chips befinden können); der GMCH 790 umfasst Speicher- und Grafiksteuerungen, mit welchen Speicher 740 und ein Koprozessor 745 gekoppelt sind; der IOH 750 koppelt Eingabe-/Ausgabe-(E/A)-Vorrichtungen 760 mit dem GMCH 790. Ersatzweise sind eine oder beide der Speicher- und Grafiksteuerungen in dem Prozessor integriert (wie hier beschrieben), sind der Speicher 740 und der Koprozessor 745 direkt mit dem Prozessor 710 gekoppelt und ist der Steuerungs-Hub 720 in einem einzelnen Chip mit dem IOH 750 integriert.
Die optionale Natur zusätzlicher Prozessoren 715 ist in 7 mit unterbrochenen Linien gekennzeichnet. Jeder Prozessor 710, 715 kann einen oder mehrere der hier beschriebenen Verarbeitungskerne beinhalten und kann eine Version des Prozessors 600 sein.
Der Speicher 740 kann beispielsweise dynamischer Direktzugriffsspeicher (DRAM, Direct Random Access Memory), Phasenwechselspeicher (PCM, Phase Change Memory) oder eine Kombination der beiden sein. Für wenigstens eine Ausführungsform kommuniziert der Steuerungs-Hub 720 mit dem(den) Prozessor(en) 710, 715 über einen Mehrpunktbus, wie beispielsweise einen Front-Side-Bus (FSB), einer Punkt-zu-Punkt-Schnittstelle, wie beispielsweise QuickPath-Interconnect (QPI), oder einer ähnlichen Verbindung 795.
Bei einer Ausführungsform ist der Koprozessor 745 ein Spezialprozessor, wie beispielweise ein Hochdurchsatz-MIC-Prozessor, ein Netz- oder Kommunikationsprozessor, eine Kompressionsfunktionseinheit, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. Bei einer Ausführungsform kann der Steuerungs-Hub 720 einen integrierten Grafikbeschleuniger umfassen.
Es kann eine Vielfalt von Unterschieden hinsichtlich eines Spektrums von Leistungsmetriken, einschließlich Architektur-, Mikroarchitektur-, thermischen, Stromverbrauchseigenschaften und dergleichen, zwischen den physischen Ressourcen 710, 715 geben.
Bei einer Ausführungsform führt der Prozessor 710 Befehle aus, welche Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In die Befehle können Koprozessorbefehle eingebettet sein. Der Prozessor 710 erkennt diese Koprozessorbefehle als von einem Typ, welcher durch den angehängten Koprozessor 745 ausgeführt werden muss. Entsprechend gibt der Prozessor 710 diese Koprozessorbefehle (oder Steuersignale, welche Koprozessorbefehle repräsentieren) auf einem Koprozessorbus oder einer anderen Zwischenverbindung an den Koprozessor 745 aus. Der(die) Koprozessor(en) 745 nimmt(nehmen) die erhaltenen Koprozessorbefehle an und führt(führen) diese aus.
Nun unter Bezugnahme auf 8 ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 800 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 8 gezeigt, ist das Multiprozessorsystem 800 ein Punkt-zu-Punkt-Zwischenverbindungssystem und umfasst einen ersten Prozessor 870 und einen zweiten Prozessor 880, welche über eine Punkt-zu-Punkt-Zwischenverbindung 850 gekoppelt sind. Jeder der Prozessoren 870 und 880 kann eine Version des Prozessors 600 sein. Bei einer Ausführungsform der Erfindung sind die Prozessoren 870 und 880 die Prozessoren 710 bzw. 715, während der Koprozessor 838 der Koprozessor 745 ist. Bei einer anderen Ausführungsform sind die Prozessoren 870 und 880 der Prozessor 710 bzw. der Koprozessor 745.
Die Prozessoren 870 und 880 sind einschließlich IMC-Einheiten (IMC: Integrated Memory Controller - Integrierte Speichersteuerung) 872 bzw. 882 gezeigt. Der Prozessor 870 umfasst auch als Teil seiner Bussteuerungseinheiten die Punkt-zu-Punkt-(P-P)-Schnittstellen 876 und 878; gleichermaßen umfasst der zweite Prozessor 880 die P-P-Schnittstellen 886 und 888. Die Prozessoren 870 und 880 können Informationen über eine Punkt-zu-Punkt-(P-P)-Schnittstelle 850 unter Verwendung der P-P-Schnittstellenschaltungen 878, 888 austauschen. Wie in 8 gezeigt, koppeln die IMC 872 und 882 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 832 und einem Speicher 834, welche Teile eines Hauptspeichers sein können, welche lokal an die jeweiligen Prozessoren gebunden sind.
Die Prozessoren 870, 880 können jeweils Informationen über individuelle P-P-Schnittstellen 852, 854 mit einem Chipsatz 890 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltkreisen 876, 894, 886, 898 austauschen. Der Chipsatz 890 kann optional Informationen mit dem Koprozessor 838 über eine Hochleistungsschnittstelle 839 austauschen. Bei einer Ausführungsform ist der Koprozessor 838 ein Spezialprozessor, wie beispielsweise ein Hochdurchsatz-MIC-Prozessor, ein Netz- oder Kommunikationsprozessor, eine Kompressionsfunktionseinheit, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
Ein gemeinsam genutzter Cache (nicht dargestellt) kann in beiden Prozessoren oder außerhalb beider Prozessoren, jedoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden, enthalten sein, so dass lokale Cacheinformationen eines oder beider Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, wenn ein Prozessor in einen Niederleistungsmodus versetzt wird.
Der Chipsatz 890 kann über eine Schnittstelle 896 mit einem ersten Bus 816 gekoppelt sein. Bei einer Ausführungsform kann der erste Bus 816 ein PCI-Bus (PCI: Peripheral Component Interconnect) oder ein Bus, wie beispielsweise ein PCI-Express-Bus oder ein anderer E/A-Zwischenverbindungsbus der dritten Generation, sein, obwohl der Schutzumfang der vorliegenden Erfindung nicht derart beschränkt ist.
Wie in 8 gezeigt, können verschiedene E/A-Vorrichtungen 814 zusammen mit einer Busbrücke 818, welche den ersten Bus 816 mit einem zweiten Bus 820 koppelt, mit dem ersten Bus 816 gekoppelt sein. Bei einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 815, wie beispielsweise Koprozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPU, Beschleuniger (wie beispielsweise Grafikbeschleuniger oder DSP-Einheiten (DSP: Digital Signal Processing - digitale Signalverarbeitung)), vor Ort programmierbare Gate-Arrays oder ein beliebiger anderer Prozessor, mit dem ersten Bus 816 gekoppelt. Bei einer Ausführungsform kann der zweite Bus 820 ein LPC-Bus (LPC: Low Pin Count) sein. Verschiedene Vorrichtungen können mit einem zweiten Bus 820 gekoppelt sein, welcher bei einer Ausführungsform zum Beispiel eine Tastatur und/oder eine Maus 822, Kommunikationsvorrichtungen 827 und eine Speichereinheit 828 umfasst, wie beispielsweise ein Plattenlaufwerk oder eine andere Massenspeichervorrichtung, welche Befehle/Code und Daten 830 umfassen kann. Weiterhin kann eine Audio-E/A 824 mit dem zweiten Bus 820 gekoppelt sein. Es ist zu beachten, dass andere Architekturen möglich sind. Beispielsweise kann ein System an Stelle der Punkt-zu-Punkt-Architektur der 8 einen Mehrpunktbus oder eine andere derartige Architektur implementieren.
Nun unter Bezugnahme auf 9 ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 900 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in 8 und 9 tragen gleiche Bezugsziffern, und bestimmte Gesichtspunkte der 8 wurden in 9 weggelassen, um eine Verschleierung anderer Gesichtspunkte der 9 zu vermeiden.
9 illustriert, dass die Prozessoren 870, 880 integrierte Speicher- und E/A-Steuerlogik (CL, Control Logic) 872 bzw. 882 umfassen können. Dementsprechend umfasst die CL 872, 882 integrierte Speichersteuereinheiten und umfasst E/A-Steuerlogik. 9 illustriert weiterhin, dass nicht nur die Speicher 832, 834 mit der CL 872, 882 gekoppelt sind, sondern auch, dass E/A-Vorrichtungen 914 ebenfalls mit der Steuerlogik 872, 882 gekoppelt sind. Veraltete E/A-Vorrichtungen 915 sind mit dem Chipsatz 890 gekoppelt.
Nun unter Bezugnahme auf 10 ist ein Blockdiagramm eines SoC 1000 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in 6 tragen gleiche Bezugsziffern. Außerdem sind Kästchen mit unterbrochenen Linien optionale Merkmale auf fortschrittlicheren SoC. In 10 ist eine Verbindungseinheit(en) 1002 gekoppelt mit: einem Anwendungsprozessor 1010, welcher einen Satz eines oder mehrerer Kerne 202A bis N und gemeinsam genutzte Cacheeinheit(en) 606 umfasst; einer Systemagenteneinheit 610; einer Bussteuereinheit 616; einer integrierten Speichersteuereinheit 614; einem Satz eines oder mehrerer Koprozessoren 1020, welche integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor umfassen können; einer SRAM-Einheit (SRAM - statischer Direktzugriffsspeicher) 1030; einer DMA-Einheit (DMA - Direktspeicherzugriff) 1032; und einer Anzeigeeinheit 1040 zum Koppeln mit einer oder mehreren externen Anzeigen. Bei einer Ausführungsform umfasst(umfassen) der(die) Koprozessor(en) 1020 einen Spezialprozessor, wie beispielsweise einen Netz- oder Kommunikationsprozessor, eine Kompressionsfunktionseinheit, eine GPGPU, einen Hochdurchsatz-MIC-Prozessor, einen eingebetteten Prozessor oder dergleichen.
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, welche auf programmierbaren Systemen ausgeführt werden, welche wenigstens einen Prozessor, ein Speichersystem (einschließlich flüchtigen und nichtflüchtigen Speichers und/oder Speicherelemente), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
Programmcode, wie beispielsweise der in 8 illustrierte Code 830, kann auf Eingabebefehle angewandt werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können auf eine oder mehrere Ausgabevorrichtungen auf bekannte Weise angewandt werden. Zum Zweck dieser Anmeldung umfasst ein Verarbeitungssystem ein beliebiges System, welches einen Prozessor aufweist, wie beispielsweise einen digitalen Signalprozessor (DSP), einen Mikrocontroller, einen anwendungsspezifischen integrierten Schaltkreis (ASIC: Application Specific Integrated Circuit) oder einen Mikroprozessor.
Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann, falls gewünscht, auch in einer Assembler- oder Maschinensprache implementiert werden. Tatsächlich sind die hier beschriebenen Mechanismen im Schutzumfang nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Ein oder mehrere Gesichtspunkte mindestens einer Ausführungsform können durch repräsentative Befehle, welche auf einem maschinenlesbaren Medium gespeichert sind, welches verschiedene Logik innerhalb des Prozessors repräsentiert, implementiert sein, welche, wenn sie durch eine Maschine gelesen werden, die Maschine veranlassen, Logik zum Durchführen der hier beschriebenen Techniken zu fabrizieren. Derartige Repräsentationen, bekannt als „IP-Kerne“, können auf einem greifbaren maschinenlesbaren Medium gespeichert sein und an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, um in die Fabrikationsmaschinen geladen zu werden, welche tatsächlich die Logik oder den Prozessor herstellen.
Solche maschinenlesbaren Speichermedien können ohne Einschränkung nichtflüchtige greifbare Anordnungen von Artikeln, welche durch eine Maschine oder eine Vorrichtung hergestellt oder ausgebildet werden, umfassen, einschließlich Speichermedien wie Festplatten, jede andere Art von Platte, einschließlich Disketten, optischen Platten, CD-ROM, CD-RW und magnetooptischen Platten, Halbleitervorrichtungen wie Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM) wie dynamische Direktzugriffsspeicher (DRAM), statische Direktzugriffsspeicher (SRAM), löschbare programmierbare Nur-Lese-Speicher (EPROM), Flash-Speicher, elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROM), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder jede andere Art von Medien, welche zum Speichern elektronischer Befehle geeignet sind.
Entsprechend umfassen Ausführungsformen der Erfindung auch nichtflüchtige greifbare maschinenlesbare Medien, welche Befehle enthalten oder Gestaltungsdaten enthalten, wie beispielsweise HDL (Hardware Description Language), welche Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert, welche hier beschrieben sind. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
In manchen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl von einem Quellenbefehlssatz in einen Zielbefehlssatz umzuwandeln. Beispielsweise kann der Befehlsumwandler einen Befehl in einen oder mehrere andere durch den Kern zu verarbeitende Befehle übersetzen (z. B. unter Verwendung statischer Binärübersetzung, dynamischer Binärübersetzung einschließlich dynamischer Kompilation), umformen, emulieren oder anderweitig umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Der Befehlsumwandler kann auf dem Prozessor, außerhalb des Prozessors oder teilweise auf und teilweise außerhalb des Prozessors sein.
11 ist ein Blockdiagramm, welches die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln von binären Befehlen in einem Quellenbefehlssatz zu binären Befehlen in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung kontrastiert. Bei der illustrierten Ausführungsform ist der Befehlsumwandler ein Softwarebefehlsumwandler, obwohl alternativ dazu der Befehlsumwandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 11 zeigt ein Programm in einer höheren Sprache 1102, welches unter Verwendung eines x86-Kompilierers 1104 kompiliert werden kann, um einen x86-Binärcode 1106 zu erzeugen, welcher durch einen Prozessor mit wenigstens einem x86-Befehlsatzkern 1116 nativ ausgeführt werden kann. Der Prozessor mit wenigstens einem x86-Befehlssatzkern 1116 repräsentiert einen beliebigen Prozessor, welcher im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern durch kompatibles Ausführen oder anderweitiges Verarbeiten (1) eines wesentlichen Teils des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, welche auf einem Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern ablaufen soll, durchführen kann, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern zu erreichen. Der x86-Compiler 1104 repräsentiert einen Compiler, welcher betreibbar ist, um x86-Binärcode 1106 (z. B. Objektcode) zu erzeugen, welcher mit oder ohne zusätzliche Verknüpfungsverarbeitung, auf dem Prozessor mit zumindest einem x86-Befehlssatzkern 1116 ausgeführt werden kann. Gleichermaßen zeigt 11, dass das Programm in der höheren Sprache 1102 unter Verwendung eines alternativen Befehlssatzkompilierers 1108 kompiliert werden kann, um alternativen Befehlssatz-Binärcode 1110 zu erzeugen, welcher durch einen Prozessor ohne wenigstens einen x86-Befehlssatzkern 1114 (z. B. einen Prozessor mit Kernen, welche den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA, ausführen und/oder den ARM-Befehlssatz von ARM Holdings in Sunnyvale, CA, ausführen) nativ ausgeführt werden kann. Der Befehlsumwandler 1112 wird verwendet, um den x86-Binärcode 1106 in einen Code umzuwandeln, welcher durch den Prozessor ohne einen x86-Befehlssatzkern 1114 nativ ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht der gleiche wie der alternative Befehlssatz-Binärcode 1110, da ein Befehlsumwandler, welcher dies kann, schwierig herzustellen ist; der umgewandelte Code wird jedoch die allgemeine Operation ausführen und aus Befehlen aus dem alternativen Befehlssatz bestehen. Dementsprechend repräsentiert der Befehlsumwandler 1112 Software, Firmware, Hardware oder eine Kombination davon, welche durch Emulation, Simulation oder einen beliebigen anderen Prozess ermöglicht, dass ein Prozessor oder eine andere elektronische Vorrichtung, welcher/welche keinen Prozessor oder Kern mit x86-Befehlssatz aufweist, den x86-Binärcode 1106 ausführt.
VORRICHTUNG UND VERFAHREN FÜR TRÄGE SYNCHRONE SEITENTABELLENAKTUALISIERUNGEN
Wie beschrieben, müssen bei einem System mit gemeinsam genutztem Speicher sowohl Caches als auch TLBs kohärent gehalten werden, um allen Threads die gleiche Speicheransicht bereitzustellen. Einer der Hauptgründe dafür, dass Kohärenz für TLBs unterhalten werden muss, ist, dass es schwierig ist, den gesamten Datenzustand kohärent zu halten, wenn zwei verschiedene CPUs verschiedene Adressübersetzungen für die gleiche Seite aufweisen. TLBs kohärent zu halten ist relativ günstig, wenn sich Seitentabelleneinträge (PTEs) sehr selten verändern, wie dies heute der Fall ist. Aktuelle Systeme verwenden eine Kombination aus einer trägen PTE-Wiederverwendung, welche in seltenen Fällen durch sofortige TLB-Abschüsse unterstützt werden. TLB-Abschüsse sind ungeheuer aufwendig, sind jedoch bei aktuellen Systemen der einzige Weg, eine PTE-Veränderung in einer synchronen Weise zu verbreiten. Es ist zu erwarten, dass sich in naher Zukunft die Frequenz von PTE-Veränderungen erhöhen wird, was einen effizienteren Mechanismus zum Verbreiten von PTE-Veränderungen erforderlich macht.
Eine Ausführungsform der Erfindung beschleunigt eine TLB-Verarbeitung durch Hinzufügen von Hardware zu den TLBs, um eine synchrone TLB-Invalidierung einer spezifischen virtuellen Adresse und einen neuen Befehl durchzuführen, um diese Hardware anzusteuern. Weiterhin kombinieren manche Ausführungsformen der Erfindung eine mutex mit diesem Befehl, um zu gewährleisten, dass nur ein Thread in dem System versuchen wird, zu einem Zeitpunkt einen gegebenen Seitentabelleneintrag (PTE) zu verändern.
12 illustriert eine Architektur, auf welcher die Ausführungsformen der Erfindung implementiert werden können, welche einen TLB 1220 zur Cachespeicherung von Adressübersetzungen von virtuell nach physisch, eine Speicherhierarchie 1230, welche einen Systemspeicher und einen oder mehrere Cache-Level umfasst, und mehrere Kerne 1210 bis 1211 zum Ausführen von Befehle und zum Verarbeiten von Daten umfasst. Obwohl er als innerhalb des Kerns 1210 integriert illustriert ist, können manche Architekturen wählen, ihn zu trennen, so dass ein TLB mehr als einer Ausführungsfunktionseinheit (Kern) dient. Zum Verbessern der Geschwindigkeit der Adressübersetzung, kann der TLB 1220 eine feste Anzahl von Schlitzen umfassen, welche Seitentabelleneinträge enthalten, von welchen jeder eine virtuelle Adresse auf eine physische Adresse in einem Systemspeicher abbildet. Beim Versuchen auf eine bestimmte Seite innerhalb des virtuellen Adressraums zuzugreifen, führt der Kern 1210 eine TLB-Suche durch, wie illustriert. Wenn die Abbildung virtuell auf physisch in dem TLB 1220 vorhanden ist, dann wird die physische Adresse der Speicherverwaltungseinheit 1210 bereitgestellt, welche dann unter Verwendung der physischen Adresse auf die Speicherhierarchie 1230 zugreifen kann.
Wenn die Abbildung virtuell auf physisch nicht in dem TLB 1220 vorhanden ist, führt dies zu einem „TLB-Fehlzugriff“. Bei einer Ausführungsform greift der Kern 1210 als Erwiderung auf einen TLB-Fehlzugriff auf eine Seitensucheinheit 1223 zu, welche Seitensuchdienste bereitstellt. Obwohl sie als eine getrennte Einheit illustriert ist, kann die Seitensucheinheit 1223 bei einer Ausführungsform Teil des TLB 1220 und/oder des Kerns 1210 sein. Eine Seitensuche bezieht Nachschlagen der Adressabbildung in der Seitentabelle (welche in Systemspeicher gespeichert ist) ein, um festzustellen, ob eine Abbildung existiert. Wenn eine existiert, wird sie bei einer Ausführungsform an den TLB 1220 zurückgeschrieben. Die nachfolgende Ausführung des fehlgeschlagenen Befehls führt zu einem TLB-Treffer, und der Speicherzugriff wird fortgesetzt. Wenn keine Abbildung existiert, dann kann durch einen Seitenfehlerbehandler 1222 (welcher bei einer Ausführungsform als Software implementiert werden kann) eine Fehlerausnahme eingeleitet werden.
Bei einer Ausführungsform wird der TLB 1220 als ein Assoziativspeicher (CAM: Content Addressable Memory) implementiert, obwohl die unterliegenden Prinzipien der Erfindung nicht auf einen bestimmten TLB-Typ eingeschränkt sind. Der TLB ist eine Komponente, welche von Durchschnittsfachleuten gut verstanden ist, und deshalb wird seine grundlegende Operation hier nicht ausführlicher beschrieben, um ein Verschleiern der unterliegenden Prinzipien der Erfindung zu vermeiden.
Wie in 12 illustriert, umfasst eine Ausführungsform der Erfindung mehrere neue Hardwarekomponenten, welche eine PTE-(INVPTE)-Invalidierungsausführungslogik 1214 innerhalb des Kerns 1210, um einen hier beschriebenen INVPTE-Befehl auszuführen, und eine Fence-Befehls- und TLB-Signalisierungslogik 1216 umfassen, um ein Signal aus dem TLB 1220 zu erhalten, eine Fence-Operation einzufügen (z. B. eine Fence-uop), und dem TLB 1220 zu signalisieren, wenn der Fence ausgebucht wird. Hardwarekomponenten in dem TLB 1220 umfassen ein PTE-Invalidierungsanforderungs-Behandlungsmodul 1221, um PTE-Invalidierungsanforderungsmeldungen (PTE_INV_REQ) zu erhalten, um als Reaktion den spezifizierten TLB-Eintrag zu invalidieren, ein Signal an den Kern 1210 zu senden und, wenn der Kern einmal zurücksignalisiert hat, eine Erwiderung PTE_INV_REP an den Initiator zu senden. Zusätzlich umfasst der TLB 1220 eine INVPTE-Ablaufsteuereinheit 1224 (welche auch in dem Kern 1210 implementiert werden kann), um PTE_INV_REQ-Meldungen zu senden und auf PTE_INV_REP-Erwiderungen zu warten, wenn ein INVPTE-Befehl ausgeführt wird, wie nachfolgend beschrieben.
13 illustriert ein Beispiel gemäß einer Ausführungsform, bei welcher ein „Initiator“-Thread 1300 (welcher z. B. auf Kern 1210 ausgeführt wird) versucht, eine Veränderung an einem Seitentabelleneintrag (PTE) vorzunehmen, und bereit ist, darauf zu warten, dass die Veränderung für alle andere Threads in dem System sichtbar wird, bevor eine Ausführung wieder aufgenommen wird, d. h. er möchte ein synchrones Verfahren verwenden, um eine PTE-Veränderung vorzunehmen. Bei 1301 erfasst der Initiator-Thread 1300 zuerst eine mutex (oder eine äquivalente gemeinsame Ausschluss-/Sperroperation), welche einer gegebenen virtuellen Seite V zugeordnet ist. Bei einer Ausführungsform wird dies als Software gemacht und gewährleistet, dass zu einem Zeitpunkt nur ein Thread eine Veränderung an dem PTE dieser Seite vornimmt. Wenn es zu viele Seiten gibt, um eine mutex pro Seite zu verwalten, kann ein kleiner Satz mutexes zugeordnet werden und eine Hashing-Funktion kann verwendet werden, um V auf eine der mutexes abzubilden. Dies ist ein normales Verfahren zum Reduzieren des Platzbedarfs einer Matrix von mutexes, welches die Richtigkeit nicht beeinflusst aber zu einigem unnötigen Warten führen kann, wenn zwei Threads versuchen, gleichzeitig auf verschiedenen Seiten zu arbeiten, welche auf die gleiche mutex abgebildet sind. Eine Verwendung einer einzelnen mutex, um Konkurrenzen unter gleichzeitigen Threads beim Durchführen eines synchronen TLB-Abschusses zu verhindern, darf nicht auf einen einzelnen PTE begrenzt sein, und Software kann auch wählen, den Abschuss einer Sammlung von PTE für eine bessere Effizienz zu bündeln.
Bei 1302 modifiziert der Initiator-Thread 1300 einen PTE einer virtuellen Seite V, was durch die mutex sicher geschützt ist. Er bestimmt dann die Anzahl anderer Kerne/Agenten 1320, welche über die Veränderung eines PTE der virtuellen Seite V benachrichtigt werden müssen, welche durch eine Erwiderungszählung (RESP_CNT) identifiziert wurden. Bei einer Ausführungsform bestimmt er auch die Identität dieser Kerne/Agenten, welche in einer Bit-Maske („Maske“) codiert werden. Die RESP_CNT ist typischerweise die Anzahl Kerne/Agenten in dem System minus eins (für den Initiator 1300), sie kann jedoch kleiner sein, wenn bestimmt werden kann, dass eine Teilmenge von Kernen/Agenten keinen PTE der virtuellen Seite V in ihren TLBs im Cache speichern können.
Als nächstes führt der Initiator 1300 bei 1304 einen PTE-Invalidierungsbefehl, INVPTE, aus. Bei einer Ausführungsform erhält jeder TLB 1310 eines antwortenden Kerns/Agenten die PTE-Invalidierungsanforderung (PTE_INV_REQ(V)), welche bewirkt, dass die TLBs bei 1312 Einträge für die virtuelle Seite V invalidieren, und sendet eine Erwiderung, welche bei 1313 die Invalidierung anzeigt. Der Befehl nimmt die Adresse der virtuellen Seite V, die Erwiderungszählung und die Erwiderungsgebermaske. Der Befehl kann primär in Ausführungslogik ausgeführt werden, welche in der Steuervorrichtung des L1-Caches 1212, dem TLB 1220 oder in dem Kern 1210 selbst integriert ist. Diese Logik 1221 ist in 12 innerhalb des TLB 1220 illustriert, um die meiste der neuen Hardware zu verkapseln. Bei einer Ausführungsform serialisiert der Befehl spätere Befehle in Programmreihenfolge; sie müssen auf ein Ausbuchen dieses Befehls warten, bevor sie eine Ausführung beginnen können.
Bei einer Ausführungsform initialisiert der Befehl die INVPTE-Ablaufsteuereinheit 1224 mit der RESP_CNT und der Maske. Bei 1306 sendet die Ablaufsteuereinheit 1224 dann PTE-Invalidierungsanforderungen für Seite V (PTE_INV_REQ(V)) gemäß der Maske an die TLBs 1310 anderer Kerne und wartet auf Erwiderungen (PTE_INV_REP(V)), welche bei 1313 gezeigt sind. Mit Eintreffen jeder Erwiderung dekrementiert der TLB 1220 bei 1308 (CNT) einen Zähler der Anzahl von Erwiderungen, auf welche er wartet, und prüft bei 1307, ob diese Anzahl null erreicht hat. Wenn ja, gibt er die Steuerung an den Kern zurück, wobei die mutex für die virtuelle Seite V bei 1309 freigegeben wird.
Hierbei ist garantiert, dass alle Threads in dem System die neue Version des PTE der virtuellen Seite V verwenden. Folglich gibt die Software auf dem Kern die mutex für die virtuelle Seite V frei und setzt die Ausführung fort. Die soeben beschriebene Verfahrensweise weist auf Kernen mit Außer-Reihenfolge-Ausführung eine Komplikation auf. Das Problem ist, dass, wenn der TLB eines Erwiderungsgeberkerns eine PTE_INV_REQ erhält, er Befehle in der Pipeline aufweisen kann, welche bereits die alte Version des PTE von V nachgeschlagen haben, aber nicht beendet sein können (z. B. ein L2-Fehlzugriff). Um zu gewährleisten, dass der Initiator nicht vorzeitig informiert wird, dass eine Verwendung der alten Version beendet ist, müssen alle derartigen Befehle beendet sein (oder ausgeräumt sein).
14 illustriert eine Ausführungsform, welche diese Herausforderung überwindet. Insbesondere benachrichtigt der TLB bei Erhalt einer PTE_INV_REQ bei 1311 den Kern, welcher bei 1401 eine Fence-uop in den uop-Strom einfügt. Bei 1402 müssen uops, welche danach in die Pipeline eintreten, darauf warten, dass der Fence ausgebucht wird, bevor sie auf den TLB zugreifen. Ist der Fence einmal ausgebucht, benachrichtigt der Kern den TLB, welcher dann bei 1313 die PTE_INV_REP sendet.
Mögliche Optimierungen an den Ausführungsformen der Erfindung umfassen das Folgende. Zuerst kann die Software mit gegenwärtigen Interprozessunterbrechungs-(IPI)-basierten TLB-Abschüssen, welche von Software durchgeführt werden, eine Ausräum-Benachrichtigungsabbildung unterhalten, um zu vermeiden, dass sie sich mit allen anderen CPUs/Kernen synchronisieren muss, wenn die Software bereits Schritte unternommen hat, um die Anzahl CPUs/Kerne zu reduzieren, welche an einem entfernten Abschuss teilnehmen müssen. Dies würde Löschen einiger Bits aus der Maske für den INVPTE-Befehl einbeziehen. Zusätzlich kann bei einem mehrkernigen Mehrsockelsystem jeder Sockel als ein entfernter Proxy für die anderen Sockel wirken, um die oben stehend beschriebenen Invalidierungen zu beenden, so dass eine Anzahl Intersockelsignale auf 1 reduziert wird. Manche zentralisierte Hardware, z. B. eine der Speichersteuervorrichtungen oder ein gemeinsam genutztes Cache mit niedrigstem Level (LLC), kann die Invalidierungsanforderungen an die Kerne in dem Sockel weiterleiten, die Erwiderungen sammeln und eine einzelne „Gruppen-“Erwiderung zurück an den Initiator senden. Schließlich kann Software Algorithmen für ein opportunistisches Bündeln mehrerer Seiten für synchrone Abschüsse implementieren, um den zusätzlichen Aufwand derartiger Abschüsse während einer Verwendung des oben stehenden Mechanismus zu amortisieren, so dass seine bereits reduzierten Kosten weiter unter mehreren Neuabbildungsoperationen aufgeteilt werden.
Die Ausführungsformen der Erfindung stellen aktuellen Verfahren für synchrone PTE-Aktualisierungen, welche auf Interprozessorunterbrechungen beruhen, welche sowohl für den Initiator einer Veränderung als auch für andere Threads in dem System ungeheuer aufwendig sind, ein überlegenes Leistungsvermögen bereit. Diese Ausführungsformen ermöglichen deutlich effizientere synchrone PTE-Aktualisierungen bei sehr moderaten Hardwarekosten und sehr moderater Komplexität.
In der vorstehenden Spezifikation wurden die Ausführungsformen der Erfindung unter Bezugnahme auf spezifische Ausführungsbeispiele davon beschrieben. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom breiteren Geist und Schutzumfang der Erfindung, wie in den beigefügten Ansprüchen dargelegt, abzuweichen. Die Beschreibung und die Zeichnungen sind dementsprechend in einem beispielhaften statt in einem einschränkenden Sinn zu sehen.
Ausführungsformen der Erfindung können verschiedene Schritte umfassen, welche oben stehend beschrieben wurden. Die Schritte können als maschinenausführbare Befehle verkörpert werden, welche verwendet werden können, um zu bewirken, dass ein Allzweck- oder Spezialprozessor die Schritte durchführt. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, welche festverdrahtete Logik zum Durchführen der Schritte enthalten, oder durch eine beliebige Kombination von programmierten Computerkomponenten und individualisierten Hardwarekomponenten durchgeführt werden.
Wie hier beschrieben, können Befehle spezifische Konfigurationen von Hardware bezeichnen, wie beispielsweise anwendungsspezifische integrierte Schaltkreise (ASIC), welche konfiguriert sind, bestimmte Operationen durchzuführen, oder eine vorgegebene Funktionalität oder Softwarebefehle aufweisen, welche in einem Speicher gespeichert sind, welcher in einem nichtflüchtigen computerlesbaren Medium verkörpert ist. Somit können die in den Figuren gezeigten Verfahren unter Verwendung von Code und Daten implementiert werden, welche auf einer oder mehreren elektronischen Vorrichtungen gespeichert und ausgeführt werden (z. B. einem Endgerät, einem Netzwerkelement usw.). Derartige elektronische Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netzwerk) Code und Daten unter Verwendung maschinenlesbarer Computermedien, wie beispielsweise nichtflüchtiger maschinenlesbarer Computerspeichermedien (z. B. magnetischer Festplatten; optischer Festplatten; Direktzugriffsspeicher; Nur-Lese-Speicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und flüchtiger maschinenlesbarer Computerkommunikationsmedien (z. B. elektrisch optisch, akustisch oder auf andere Weise sich fortpflanzender Signale - wie beispielsweise Trägerwellen, Infrarotsignalen, digitalen Signalen usw.). Zusätzlich umfassen solche elektronischen Vorrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren, welche mit einer oder mehreren anderen Komponenten gekoppelt sind, wie einer oder mehreren Speichervorrichtungen (nichtflüchtigen maschinenlesbaren Speichermedien), Benutzereingabe-/-ausgabevorrichtungen (z. B. einer Tastatur, einem Berührungsbildschirm und/oder einer Anzeige) und Netzwerkverbindungen. Die Kopplung des Satzes von Prozessoren und anderen Komponenten erfolgt typischerweise durch einen oder mehrere Busse und Brücken (auch als Bussteuerungen bezeichnet). Die Speichervorrichtung und die den Netzwerkverkehr führenden Signale repräsentieren jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieser elektronischen Vorrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert werden. Überall in dieser ausführlichen Beschreibung wurden zum Zwecke der Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein umfassendes Verständnis der vorliegenden Erfindung bereitzustellen. Durchschnittsfachleuten ist jedoch offenkundig, dass die Erfindung ohne einige dieser spezifischen Einzelheiten in die Praxis umgesetzt werden kann. In bestimmten Fällen wurden wohlbekannte Strukturen und Funktionen nicht ausführlich beschrieben, um ein Verschleiern des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend müssen der Schutzumfang und Erfindungsgedanke im Hinblick auf die folgenden Ansprüche beurteilt werden.

Claims

Prozessor, Folgendes umfassend: mehrere Kerne, um Befehle auszuführen und Daten zu verarbeiten; einen oder mehrere Übersetzungspuffer (TLBs), umfassend mehrere Einträge, um Adressübersetzungen von virtuell nach physisch aufzunehmen, welche durch mindestens einen der mehreren Kerne beim Ausführen der Befehle verwendbar sind; und eine Seitentabelleneintrag-(PTE)-Invalidierungsschaltung, um einen PTE-Invalidierungsbefehl auf einem ersten Kern auszuführen, um einen ersten PTE in TLBs anderer Kerne zu invalidieren, wobei die PTE-Invalidierungsschaltung als Reaktion auf eine Ausführung des PTE-Invalidierungsbefehls eine Anzahl anderer TLBs anderer Kerne, welche über die PTE-Invalidierung benachrichtigt werden müssen, als Reaktion bestimmt, PTE-Invalidierungsmeldungen an die anderen TLBs überträgt und auf Erwiderungen wartet.
Prozessor nach Anspruch 1, weiterhin Folgendes umfassend: einen Sperrschaltkomplex, um zu ermöglichen, dass ein Thread den ersten PTE in dem ersten TLB sperrt, um zu gewährleisten, dass zu einem Zeitpunkt nur ein Thread den ersten PTE modifizieren kann, wobei der erste TLB dazu dient, den ersten PTE beim Erlangen der Sperre durch den Thread zu modifizieren; und der Sperrschaltkomplex die Sperre auf dem ersten PTE als Reaktion auf Erhalten von Erwiderungen von all den anderen TLBs freigibt.
Prozessor nach Anspruch 2, wobei der Sperrschaltkomplex dazu dient, eine mutex-Operation zu implementieren, um die Sperre auf dem ersten PTE zu erlangen.
Prozessor nach Anspruch 2, wobei jeder TLB einen PTE-Invalidierungsanforderungs-Behandlungsschaltkomplex umfasst, um Invalidierungsanforderungen zu erhalten, welche aus anderen TLBs übertragen werden, wobei der Invalidierungsanforderungs-Behandlungsschaltkomplex als Reaktion bewirkt, dass die TLBs einen oder mehrere PTEs invalidieren, welche in den Invalidierungsanforderungen identifiziert sind, und eine Erwiderung übertragen, welche die Invalidierung angibt.
Prozessor nach Anspruch 4, weiterhin Folgendes umfassend: eine PTE-Invalidierungsablaufsteuerschaltung, welche mit einem Zählwert programmiert werden soll, welcher anfänglich auf die Anzahl anderer TLBs gesetzt ist, welche benachrichtigt werden müssen, wobei die PTE-Invalidierungsablaufsteuerschaltung den Zählwert beim Erhalten jeder Erwiderung von jedem der anderen TLBs dekrementiert, wobei der Sperrschaltkomplex die Sperre freigibt, wenn der Zählwert auf einen Schwellwert dekrementiert wurde.
Prozessor nach Anspruch 5, wobei ein Maskenwert verwendet werden muss, um jeden der anderen TLBs eindeutig zu identifizieren, welcher benachrichtigt werden soll.
Prozessor nach Anspruch 1, weiterhin Folgendes umfassend: Fence-Befehlslogik jedes der anderen Kerne, um eine Fence-Operation in einen Befehlsstrom einzufügen, um zu bewirken, dass alle Befehle in einer Pipeline der anderen Kerne warten, bis die Fence-Operation ausgebucht ist, bevor auf die TLBs jedes der anderen Kerne zugegriffen wird.
Prozessor nach Anspruch 7, wobei die Erwiderungen von den TLBs der anderen Kerne nur gesendet werden sollen, nachdem die Fence-Operation ausgebucht wurde.
Verfahren, welches Folgendes umfasst: Aufnehmen mehrerer Adressübersetzungen von virtuell nach physisch in einem Übersetzungspuffer (TLB), welche durch den Satz von einem oder mehreren Kernen beim Ausführen der Befehle verwendbar sind; Sperren eines ersten Seitentabelleneintrags (PTE) in dem TLB, um zu gewährleisten, dass zu einem Zeitpunkt nur ein Thread den ersten PTE modifizieren kann, wobei der TLB dazu dient, den ersten PTE beim Erlangen der Sperre zu modifizieren; Ausführen eines PTE-Invalidierungsbefehls auf einem ersten Kern, um den ersten PTE in anderen TLBs anderer Kerne zu invalidieren, wobei die PTE-Invalidierungsschaltung als Reaktion auf eine Ausführung des PTE-Invalidierungsbefehls eine Anzahl anderer TLBs anderer Kerne, welche über die PTE-Invalidierung benachrichtigt werden müssen, als Reaktion bestimmt, PTE-Invalidierungsmeldungen an die anderen TLBs überträgt und auf Erwiderungen wartet; und Freigeben der Sperre auf dem ersten PTE als Reaktion auf Erhalten von Erwiderungen von all den anderen TLBs.
Verfahren nach Anspruch 9, wobei der Sperrschaltkomplex dazu dient, eine mutex-Operation zu implementieren, um die Sperre auf dem ersten PTE zu erlangen.
Verfahren nach Anspruch 9, wobei jeder TLB einen PTE-Invalidierungsanforderungs-Behandlungsschaltkomplex umfasst, um Invalidierungsanforderungen zu erhalten, welche aus anderen TLBs übertragen werden, wobei der Invalidierungsanforderungs-Behandlungsschaltkomplex als Reaktion bewirkt, dass die TLBs einen oder mehrere PTEs invalidieren, welche in den Invalidierungsanforderungen identifiziert sind, und eine Erwiderung übertragen, welche die Invalidierung angibt.
Verfahren nach Anspruch 11, weiterhin Folgendes umfassend: eine PTE-Invalidierungsablaufsteuerschaltung, welche mit einem Zählwert programmiert werden soll, welcher anfänglich auf die Anzahl anderer TLBs gesetzt ist, welche benachrichtigt werden müssen, wobei die PTE-Invalidierungsablaufsteuerschaltung den Zählwert beim Erhalten jeder Erwiderung von jedem der anderen TLBs dekrementiert, wobei der Sperrschaltkomplex die Sperre freigibt, wenn der Zählwert auf einen Schwellwert dekrementiert wurde.
Verfahren nach Anspruch 12, wobei ein Maskenwert verwendet werden muss, um jeden der anderen TLBs eindeutig zu identifizieren, welcher benachrichtigt werden soll.
Verfahren nach Anspruch 9, weiterhin Folgendes umfassend: Fence-Befehlslogik jedes der anderen Kerne, um eine Fence-Operation in einen Befehlsstrom einzufügen, um zu bewirken, dass alle Befehle in einer Pipeline der anderen Kerne warten, bis die Fence-Operation ausgebucht ist, bevor auf die TLBs jedes der anderen Kerne zugegriffen wird.
Verfahren nach Anspruch 14, wobei die Erwiderungen von den TLBs der anderen Kerne nur gesendet werden sollen, nachdem die Fence-Operation ausgebucht wurde.
System, welches Folgendes umfasst: einen Speicher, um Befehle und Daten zu speichern; einen Prozessor, um die Befehle auszuführen und die Daten zu verarbeiten; einen Grafikprozessor, um Grafikoperationen als Erwiderung auf Grafikbefehle durchzuführen; eine Netzwerkschnittstelle, um Daten über ein Netzwerk zu erhalten und zu übertragen; eine Schnittstelle zum Erhalten einer Benutzereingabe von einer Maus oder Positionsmarken-Steuerungsvorrichtung, wobei die mehreren Kerne als Reaktion auf die Benutzereingabe die Befehle ausführen und die Daten verarbeiten; der Prozessor Folgendes umfassend: mehrere Kerne, um Befehle auszuführen und Daten zu verarbeiten; einen Übersetzungspuffer (TLB), umfassend mehrere Einträge, um Adressübersetzungen von virtuell nach physisch aufzunehmen, welche durch mindestens einen der mehreren Kerne beim Ausführen der Befehle verwendbar sind; einen Sperrschaltkomplex, um zu ermöglichen, dass ein Thread einen ersten Seitentabelleneintrag (PTE) in dem TLB sperrt, um zu gewährleisten, dass zu einem Zeitpunkt nur ein Thread den ersten PTE modifizieren kann, wobei der TLB dazu dient, den ersten PTE beim Erlangen der Sperre durch den Thread zu modifizieren; eine PTE-Invalidierungsschaltung, um einen PTE-Invalidierungsbefehl auf einem ersten Kern auszuführen, um den ersten PTE in anderen TLBs anderer Kerne zu invalidieren, wobei die PTE-Invalidierungsschaltung als Reaktion auf eine Ausführung des PTE-Invalidierungsbefehls eine Anzahl anderer TLBs anderer Kerne, welche über die PTE-Invalidierung benachrichtigt werden müssen, als Reaktion bestimmt, PTE-Invalidierungsmeldungen an die anderen TLBs überträgt und auf Erwiderungen wartet; und der Sperrschaltkomplex die Sperre auf dem ersten PTE als Reaktion auf Erhalten von Erwiderungen von all den anderen TLBs freigibt.
System nach Anspruch 16, wobei der Sperrschaltkomplex dazu dient, eine mutex-Operation zu implementieren, um die Sperre auf dem ersten PTE zu erlangen.
System nach Anspruch 16, wobei jeder TLB einen PTE-Invalidierungsanforderungs-Behandlungsschaltkomplex umfasst, um Invalidierungsanforderungen zu erhalten, welche aus anderen TLBs übertragen werden, wobei der Invalidierungsanforderungs-Behandlungsschaltkomplex als Reaktion bewirkt, dass die TLBs einen oder mehrere PTEs invalidieren, welche in den Invalidierungsanforderungen identifiziert sind, und eine Erwiderung übertragen, welche die Invalidierung angibt.
System nach Anspruch 18, weiterhin Folgendes umfassend: eine PTE-Invalidierungsablaufsteuerschaltung, welche mit einem Zählwert programmiert werden soll, welcher anfänglich auf die Anzahl anderer TLBs gesetzt ist, welche benachrichtigt werden müssen, wobei die PTE-Invalidierungsablaufsteuerschaltung den Zählwert beim Erhalten jeder Erwiderung von jedem der anderen TLBs dekrementiert, wobei der Sperrschaltkomplex die Sperre freigibt, wenn der Zählwert auf einen Schwellwert dekrementiert wurde.
System nach Anspruch 19, wobei ein Maskenwert verwendet werden muss, um jeden der anderen TLBs eindeutig zu identifizieren, welcher benachrichtigt werden soll.
System nach Anspruch 16, weiterhin Folgendes umfassend: Fence-Befehlslogik jedes der anderen Kerne, um eine Fence-Operation in einen Befehlsstrom einzufügen, um zu bewirken, dass alle Befehle in einer Pipeline der anderen Kerne warten, bis die Fence-Operation ausgebucht ist, bevor auf die TLBs jedes der anderen Kerne zugegriffen wird.
System nach Anspruch 21, wobei die Erwiderungen von den TLBs der anderen Kerne nur gesendet werden sollen, nachdem die Fence-Operation ausgebucht wurde.