DE102015007422A1

DE102015007422A1 - Befehlssatz zum Eliminieren fehlausgerichteter Speicherzugriffe während der Verarbeitung eines Arrays mit fehlausgerichteten Datenzeilen

Info

Publication number: DE102015007422A1
Application number: DE102015007422.9A
Authority: DE
Inventors: Mikhail Plotnikov; Igor Ermolaev
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2014-07-09
Filing date: 2015-06-09
Publication date: 2016-01-14
Also published as: TW201617856A; TWI619073B; US20160011870A1; CN105278921A; US9910670B2; CN105278921B

Abstract

Beschrieben wird ein Prozessor mit einer Befehlsausführungspipeline. Die Befehlsausführungspipeline weist eine Befehlsabrufstufe zum Abrufen eines Befehls auf. Das Befehlsformat des Befehls spezifiziert einen ersten Eingangsvektor, einen zweiten Eingangsvektor und einen dritten Eingangsoperanden. Die Befehlsausführungspipeline umfasst eine Befehlsdecodierstufe zum Decodieren eines Befehls. Die Befehlsausführungspipeline weist eine Funktionseinheit zum Ausführen des Befehls auf. Die Funktionseinheit weist ein Routingnetz auf, um eine erste zusammenhängende Elementgruppe von einem ersten Ende eines der Eingangsvektoren an ein zweites Ende des resultierenden Vektors des Befehls zu leiten, und eine zweite zusammenhängende Elementgruppe von einem zweiten Ende des anderen der Eingangsvektoren an ein erstes Ende des resultierenden Vektors des Befehls zu leiten. Das erste und das zweite Ende sind einander gegenüberliegende Vektorenden. Die erste und die zweite zusammenhängende Elementgruppe werden anhand des dritten Eingangsoperanden definiert. Der Befehl ist nicht in der Lage, nicht zusammenhängende Elementgruppen aus den Eingangsvektoren in den resultierenden Vektor des Befehls zu leiten. Eine Software-Pipeline, die den Befehl verwendet, wird ebenfalls beschrieben

Description

Gebiet der Erfindung
Das Gebiet der Erfindung betrifft die Informatik und spezieller einen Befehlssatz zum Eliminieren fehlausgerichteter Speicherzugriffe während der Verarbeitung eines Arrays mit fehlausgerichteten Datenzeilen.
Hintergrund der Erfindung
zeigt eine Übersichtsdarstellung eines Verarbeitungskerns 100, der mit Logikschaltungen auf einem Halbleiterchip implementiert ist. Der Verarbeitungskern weist ein Befehlsfließband (Pipeline) 101 auf. Die Pipeline besteht aus mehreren Stufen, die jeweils dafür ausgelegt sind, einen spezifischen Schritt in dem mehrschrittigen Prozess, der zur vollständigen Ausführung eines Programmcodebefehls erforderlich ist, auszuführen. Diese schließen typischerweise wenigstens ein: 1) Abrufen und Dekodieren von Befehlen; 2) Abrufen von Daten; 3) Ausführung; 4) Zurückkopieren. Die Ausführungsstufe führt eine spezifische Operation, die durch einen Befehl identifiziert ist, der in (einer) vorherigen Stufe(n) abgerufen und dekodiert wurde (z. B. in Schritt 1) oben), an Daten aus, die durch denselben Befehl identifiziert sind und in einer anderen vorherigen Stufe (z. B. in Schritt 2) oben) abgerufen wurden. Die Daten, an denen die Operation ausgeführt wird, werden typischerweise von einem (universellen) Registerspeicherplatz 102 abgerufen. Neue Daten, die bei Fertigstellung der Operation erzeugt werden, werden ebenso typischerweise an den Registerspeicherplatz „zurückkopiert” („Write-back”) (z. B. in Stufe 4) oben).
Die mit der Ausführungsstufe verknüpfte Logikschaltung setzt sich typischerweise aus mehreren „Ausführungseinheiten” oder „Funktionseinheiten” 103_1 bis 103_N zusammen, die jeweils dafür ausgelegt sind, ihre eigene Untermenge von Operationen auszuführen (z. B. führt eine erste Funktionseinheit ganzzahlige mathematische Operationen aus, eine zweite Funktionseinheit führt Gleitkommabefehle aus, eine dritte Funktionseinheit führt Laden/Speichern-Operationen aus dem/in den Cache/Speicher aus etc.). Die Gesamtheit aller von sämtlichen Funktionseinheiten ausgeführten Operationen entspricht dem „Befehlssatz”, der von dem Verarbeitungskern 100 unterstützt wird.
Im Bereich der Informatik sind zwei Arten von Prozessorarchitekturen weitgehend anerkannt: „Skalar” und „Vektor”. Ein Skalarprozessor ist dafür ausgelegt, Befehle auszuführen, die Operationen an einem Einzeldatensatz durchführen, wohingegen ein Vektorprozessor dafür ausgelegt ist, Befehle auszuführen, die Operationen an mehreren Datensätzen durchführen. und stellen ein Vergleichsbeispiel dar, das den grundlegenden Unterschied zwischen einem Skalarprozessor und einem Vektorprozessor zeigt.
zeigt ein Beispiel eines skalaren UND-Befehls, bei dem eine einzelne Operandengruppe, A und B, in einer UND-Verknüpfung verbunden wird, um ein einziges (oder „skalares”) Ergebnis C zu erzielen (d. h. AB = C). Im Gegensatz dazu zeigt ein Beispiel eines vektoriellen UND-Befehls, bei dem zwei Operandengruppen, A/B und D/E, jeweils in einer UND-Verknüpfung parallel verbunden werden, um gleichzeitig ein Vektorergebnis C, F zu erzielen (d. h., A.AND.B = C und D.AND.E = F). Begrifflich ist ein „Vektor” als ein Datenelement zu verstehen, das mehrere „Elemente” aufweist. Beispielsweise weist ein Vektor V = Q, R, S, T, U fünf verschiedene Elemente auf: Q, R, S, T und U. Die „Größe” des beispielhaften Vektors V beträgt fünf (da er fünf Elemente aufweist).
zeigt auch das Vorhandensein eines Vektorregisterraums 107, der von dem universellen Registerraum 102 verschieden ist. Speziell wird der universelle Registerraum 102 nominell zum Speichern von Skalarwerten verwendet. Wenn daher eine der Ausführungseinheiten Skalaroperationen durchführt, verwendet sie nominell Operanden, die aus dem universellen Registerspeicherraum 102 abgerufen wurden (und kopiert die Ergebnisse dorthin zurück). Im Gegensatz dazu verwendet eine der Ausführungseinheiten, wenn sie Vektoroperationen durchführt, nominell Operanden, die aus dem Vektorregisterraum 107 abgerufen wurden (und kopiert die Ergebnisse dorthin zurück). Verschiedene Speicherregionen können in ähnlicher Weise für die Speicherung von Skalarwerten und Vektorwerten zugewiesen werden. Namentlich können manche Maschinen den Vektorregisterraum nutzen, um Gleitkomma-Skalarwerte zu speichern.
Abbildungen
Ein besseres Verständnis der vorliegenden Erfindung ergibt sich anhand der nachstehenden ausführlichen Beschreibung im Zusammenhang mit den folgenden Zeichnungen, in denen gilt:
zeigt eine Befehlsausführungspipeline;
und vergleichen die Skalar- mit der Vektorverarbeitung;
und stellen die Verarbeitung eines Arrays mit fehlausgerichteten Zeilen;
zeigt ein verbessertes Verfahren der Verarbeitung eines Arrays mit fehlausgerichteten Zeilen;
zeigt ein Design für einen ersten Befehl, der in dem Prozess von verwendet wird;
zeigt ein Design für einen zweiten Befehl, der in dem Prozess von verwendet wird;
zeigt einen Kompilierungsprozess;
ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon gemäß Ausführungsformen der Erfindung zeigt.
ist ein Blockschaltbild, das das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon gemäß Ausführungsformen der Erfindung zeigt.
–d sind Blockschaltbilder, die ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung veranschaulichen.
ist ein Blockschaltbild einer Registerarchitektur gemäß einer Ausführungsform der Erfindung.
ist ein Blockschaltbild eines einzelnen CPU-Kerns, zusammen mit seinem Anschluss an das Verbindungsnetz und mit seiner lokalen Untermenge des Level-2(L2)-Cache, gemäß Ausführungsformen der Erfindung.
ist eine Explosionsansicht eines Teils des CPU-Kerns in gemäß Ausführungsformen der Erfindung.
–b sind Blockschaltbilder, die eine beispielhafte Out-of-Order-Architektur gemäß Ausführungsformen der Erfindung veranschaulichen.
ist ein Blockschaltbild eines Systems gemäß einer Ausführungsform der Erfindung.
ist ein Blockschaltbild eines zweiten Systems gemäß einer Ausführungsform der Erfindung.
ist ein Blockschaltbild eines dritten Systems gemäß einer Ausführungsform der Erfindung.
ist ein Blockschaltbild eines SoC gemäß einer Ausführungsform der Erfindung.
ist ein Blockschaltbild eines Einzelkernprozessors und eines Mehrkernprozessors mit integrierter Speichersteuerung und Graphik gemäß Ausführungsformen der Erfindung.
ist ein Blockschaltbild, das die Verwendung eines Software-Befehlsumwandlers zum Umwandeln von binären Befehlen in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt.
Ausführliche Beschreibung
Vektorverarbeitung ist nützlich für die Verarbeitung von Arrays. Als Beispiel kann jeder Vektor einer Zeile im Array entsprechen. Gemäß der grundlegenden Array-Verarbeitung wird der Informationswert einer Zeile (oder einfach eine „Zeile” des Arrays) aus dem Eingangsarray gelesen und verarbeitet. Der Wert einer Zeile resultierender Informationen aus der Verarbeitung wird dann in die resultierende Array-Struktur geschrieben.
zeigt ein Problem bzw. eine Ineffizienz auf, das/die entstehen kann, wenn die Zeilen eines Arrays bezogen auf den Speicheradressierungsraum „fehlausgerichtet” sind. zeigt eine beispielhafte Eingangsarray-Struktur 301 und eine beispielhafte „resultierende” Array-Struktur 302. Hier entspricht jede in erkennbare rechtwinklige Zeile einem Vektorregister, wobei ein einzelner Speicherlesevorgang ein oder mehrere solcher Vektorregister füllen kann. Idealerweise sind die Zeilen an den Rändern der Vektorregister ausgerichtet. Es ist jedoch zu beachten, dass die Informationswerte der Zeilen 303, 304 innerhalb ihrer jeweiligen Array-Strukturen 301, 302 fehlausgerichtet sind. Das bedeutet, dass die Zeilen nicht an den normalen Vektorgrenzen beginnen/enden, sondern stattdessen innerhalb derselben beginnen/enden. Darüber hinaus weisen die beiden Zeilen 303, 304 verschiedene Grade der Fehlausrichtung auf.
Vektorprozessoren und ihre Kompilierer können Ineffizienzen aufweisen, wenn sie für die Verarbeitung von Arrays mit fehlausgerichteten Zeilen eingesetzt werden. Spezieller können fehlausgerichtete Zugriffe ineffizient sein, da sie mehrere Lesevorgänge aus dem Speicher für nur eine Zeile von Eingangsdaten für einen Rechenvorgang verursachen können und/oder weil sie mehrere Schreibvorgänge in den Speicher für eine einzige Zeile resultierender Daten verursachen können.
Heutige Kompilierer suchen die Nachteile, die mit fehlausgerichteten Array-Zugriffen einhergehen, durch ein Verfahren zu verringern, das als „Peeling” bezeichnet wird und das mehrere Wiederholungen durchläuft, bis eine korrekt ausgerichtete resultierende Zeile erreicht wird. Infolge des Peelings wird die Array-Struktur ausgerichtet wie in . Hier wurde die Anfangsposition sowohl des Eingangs- als auch des resultierenden Arrays um denselben Betrag 305 verschoben, wobei der Betrag der Verschiebung die Ausrichtung der resultierenden Zeile 307 an den nominellen Vektorgrenzen der Maschine bewirkt hat. Durch die korrekt ausgerichtete resultierende Zeile 307 werden mehrere Speicherschreibvorgänge zum Einschreiben einer einzigen resultierenden Zeile vermieden. Da jedoch die Eingangs- und die resultierende Zeile fehlerhaft zueinander ausgerichtet waren, sind die Eingangszeilen 308 immer noch fehlausgerichtet. Somit sind immer noch mehrere Speicherlesevorgänge möglich, um eine Zeile Informationen für einen Rechenvorgang zu erhalten, und ein Prozessor kann nach wie vor in ineffizienter Weise arbeiten.
zeigt einen verbesserten Lösungsansatz, der mit Software-Pipelining und einem Paar speziell angepasster Befehle arbeitet. Die Anwendung von Software-Pipelining mit den speziellen Befehlen sorgt für eine effiziente Verarbeitung von Arrays mit fehlausgerichteten Zeilen ohne den Nachteil von fehlausgerichteten Zugriffen aus dem/in den Speicher. Hier werden die Grenzen der Array-Zeilen innerhalb der Pipelineschleife gehalten, statt an den Speicherzugriffsschnittstellen exponiert zu sein. Infolgedessen sind die aus dem Speicher abgerufenen Eingangsdaten an den Vektorgrenzen der Maschine ausgerichtet und nicht an den Grenzen der fehlausgerichteten Zeilen. Eingangsdaten können daher mittels korrekt ausgerichteter Speicherzugriffe abgerufen werden, selbst wenn die Zeilen des verarbeiteten Arrays fehlerhaft ausgerichtet sind. In ähnlicher Weise können resultierende Daten korrekt ausgerichtet in den Speicher geschrieben werden, auch wenn die resultierenden Array-Zeilen fehlerhaft ausgerichtet sind. Der Grad der Fehlausrichtung zwischen Eingangszeilen und resultierenden Zeilen kann auch unterschiedlich sein.
Wie in zu sehen, enthält eine Eingangsarray-Struktur 401 eine Reihe zu verarbeitender fehlausgerichteter Zeilen 411, 412, 413, die in Reaktion auf die Array-Verarbeitung resultierende Zeilen 431, 432, 433 in einem Ausgangsarray 402 ergeben. Der Einfachheit halber bezieht sich das Beispiel in lediglich auf Zugriffe aus dem/in den Vektorregisterraum. Für den Durchschnittsfachmann ist offensichtlich, dass, auch wenn in dem Beispiel in nur auf den Vektorregisterraum Bezug genommen wird, die hier erörterte ausgerichtete Zugriffsweise fehlausgerichtete Speicherzugriffe wie soeben besprochen eliminieren kann.
In einer grundlegenden Implementierung entspricht jedes Segment der Eingangsarray-Struktur 401 einem eindeutigen Vektorregister im Vektorregisterraum (mit jeweils eigener Registeradresse). Wie in dargestellt: 1) ein Anfangsabschnitt 411_1 von Eingangszeile 411 ist in Register RX1 enthalten; 2) ein Endabschnitt 411_2 von Eingangszeile 411 und ein Anfangsabschnitt 412_1 von Eingangszeile 412 sind in Register RX2 enthalten; und 3) ein Endabschnitt 412_2 von Eingangszeile 412 und ein Anfangsabschnitt 413_1 von Eingangszeile 413 sind in Register RX3 enthalten etc. Ähnlich, wie ebenfalls in dargestellt: 1) ein Anfangsabschnitt 431_1 der resultierenden Zeile 431 ist in Register RY1 enthalten; 2) ein Endabschnitt 431_2 der resultierenden Zeile 431 und ein Anfangsabschnitt 432_1 der resultierenden Zeile 432 sind in Register RY2 enthalten; und, 3) ein Endabschnitt 432_2 der resultierenden Zeile 432 und ein Anfangsabschnitt 433_1 der resultierenden Zeile 433 sind in Register RY3 enthalten etc. Es ist zu beachten, dass in dem speziellen Beispiel von die Ausrichtung der Zeilen im Eingangsarray 401 einen andere ist als die Ausrichtung der Zeilen im Ausgangsarray 402.
Die Software-Pipelineschleife kann aufgebaut sein wie in Bild 450, das die beiden neuen Befehle VSHIFTR2B 451, VSHIFTL2B 453 zeigt, zwischen einer beliebigen Codesequenz 452, die zum Ausführen der Array-Verarbeitung an jeder Zeile des Arrays verwendet wird. Ein besonderes Merkmal sowohl des VSHIFTR2B-Befehls 451 als auch des VSHIFTL2B-Befehls 453 ist, dass beide Befehle zwei Quellvektor-Quelloperanden und einen dritten Eingangsoperanden akzeptieren, der in gewisser Weise die Fehlausrichtung innerhalb des Arrays angibt, welche wiederum den Betrag der Verschiebung und Integration von Inhalt aus den beiden Vektor-Quelloperanden in einen einzelnen resultierenden Vektor angibt. In dem Beispiel von ist der dritte Eingangsoperand als skalarer Eingang S1 gekennzeichnet. Wie weiter unten noch ausführlicher beschrieben wird, kann der dritte Eingangsoperand andere Formen haben, beispielsweise ein Maskeneingangsvektor.
Der Einfachheit halber sei für die vorliegende Erörterung zur Demonstration der Software-Pipelineschleife angenommen, dass Zeile 411 gerade verarbeitet worden ist und die nächste Wiederholung der Software-Pipelineschleife mit der Verarbeitung von Zeile 412. beginnt. Insbesondere müssen, um Zeile 411 bereits verarbeitet zu haben, die Inhalte von Register RX2 schon in der vorangegangenen Wiederholung gelesen worden sein. Darüber hinaus enthält das Register RX2 einen Anfangsteil 412_1 von Zeile 412. Hier, am Beginn der Verarbeitung von Zeile 412, wird vorausgesetzt, dass die Inhalte von Register RX2 einschließlich des Anfangsteils 412_1 in den Inhalten von R2 enthalten sind wie in Pseudocode 450 angegeben. Außerdem wird im Rahmen der Schleifeninitialisierung ein Skalarwert S1 dazu verwendet, einen Betrag der Fehlausrichtung zu definieren, die zwischen den Zeilen von Eingangsarray 401 besteht.
Gemäß dem Pseudocode 450 werden die Inhalte von RX3, das den Endteil 412_2 von Zeile 412 enthält, in R3 eingelesen 455. Anschließend wird der VSHIFTR2B-Befehl ausgeführt 451, wobei R2, R3 und S1 als Eingangsoperanden verwendet werden und das Ergebnis in RZ1 gespeichert wird.
Die Ausführung des VSHIFTR2B-Befehls 451 ist in Bild 420 grafisch dargestellt. Wie in Bild 420 dargestellt, wird die Ausführung des VSHIFTR2B-Befehls 451: 1) die letzten drei Elemente der Inhalte von Register R2 um fünf Elementpositionen nach rechts verschieben 423, um den äußersten rechten Rand von Zeile 412 am äußersten rechten Rand des Registerraums auszurichten; 2) die ersten fünf Elementpositionen von Register R3 am äußersten linken Rand der verschobenen Elemente von R2 anhängen 424. Somit entspricht die Resultierende des VSHIFTR2B-Befehls in RZ1, auch als der „aktuelle Vektor” 421 bezeichnet, einer ausgerichteten Version der Eingangszeile 412. Es ist zu beachten, dass in diesem Beispiel acht Elemente pro Vektor vorhanden sind. S1 kann vor dem Hintergrund der in dem Eingangsarray dargestellten Fehlausrichtung als 3 oder 5 definiert sein, abhängig von dem gewählten Design.
RZ1 wird dann als Eingangsquelloperand für die Array-Verarbeitungssequenz 452 verwendet. Die Array-Verarbeitungssequenz 452 schreibt 425 ihre Resultierende 432 in RM2 ein. Die Resultierende 432 ist eine vollständig ausgerichtete Zeile resultierender Daten 432, wovon ein Anfangsabschnitt 432_1 in das Ausgangsarray 402 bei Register RY2 zu schreiben ist, zusammen mit einem Endabschnitt 431_2 der Resultierenden 431. Hier ist zu beachten, dass die Verarbeitung des vorhergehenden Zyklus für die vorherige Zeile 411 die ausgerichtete Zeile 431 als ihre Resultierende hervorgebracht hat. Die ausgerichtete Resultierende 431 ist derzeit in RM1 gespeichert, als Folge davon, dass Operation 456 während des vorangegangenen Schleifenzyklus ausgeführt wurde.
Anschließend wird der VSHIFTL2B-Befehl ausgeführt 453. Die Funktionsweise des VSHIFTL2B-Befehls ist in Bild 426 grafisch dargestellt. Wie in Bild 426 zu sehen, akzeptiert der VSHIFTL2B-Befehl die beiden Resultierenden 431, 432 und den skalaren S2-Eingang als Quelloperanden. Der skalare Eingang S2 gibt die Fehlausrichtung in den resultierenden Array 402 an. Es ist zu beachten, dass die Fehlausrichtung im resultierenden Array 402 eine andere ist als im Eingangsarray 401. Das heißt, während die Fehlausrichtung des Eingangsarrays 401 fünf Vektorelementpositionen (z. B. S1 = 5) entspricht, entspricht die Fehlausrichtung des Ausgangsarrays 402 drei Vektorelementpositionen (z. B. S2 = 3). Somit können S1 und S2 im Beispiel von verschiedene Werte annehmen.
Anhand dieser Eingangsoperanden wird der VSHIFTL2B-Befehl: 1) die ersten fünf Elementpositionen der zweiten Resultierenden 432 in RM2 um drei Elementpositionen nach links verschieben 427; und 2) die letzten drei Elemente der ersten Resultierenden 431 in RM1 an den äußersten rechten Rand der verschobenen Elemente der zweiten Resultierenden 432 anhängen 428. Diese Schritte bilden ordnungsgemäß fehlausgerichteten Dateninhalt von zwei verschiedenen Ausgangszeilen, der im resultierenden Array 402 (bei Register RC = RY2) mittels eines ausgerichteten Zugriffs gespeichert werden kann.
Die Inhalte von R3 werden dann in R2 verschoben, und die Inhalte von RM2 werden in RM1 verschoben, als Folge von Prozess 456.
Es sollte anhand der obigen Erörterung klar sein, dass die vorstehend beschriebene Verarbeitung sequentiell an dem nächsten Register RX4 in Eingangsarray 401 beginnen kann und dass die Ergebnisse in einem ausgerichteten Zugriff sequentiell in das Ausgabearray bei RY3 als Ausgangsergebnis 432_2, 433_1 eingeschrieben werden. Somit kann ein komplettes Array in dieser Weise verarbeitet werden. Es ist zu beachten, dass aus Sicht des Schemas von Software-Pipeline 450 bei jeder Wiederholung nur ein ausgerichteter Vektor Laden 455 pro Lesezugriff auf den Speicher und nur ein ausgerichteter Vektor Speichern 458 pro Schreibzugriff auf den Speicher verwendet wird. Im Allgemeinen ist die Zahl der ausgerichteten Speicherladevorgänge und -speichervorgänge pro Wiederholung der Software-Pipelineschleife gleich der Anzahl von Lese- bzw. Schreibzugriffen auf den Speicher.
Der vorstehend erörterte Ablauf kann als eine Software-Pipelineschleife betrachtet werden, zumindest weil Dateninhalte aus einer vorangegangenen Wiederholung (z. B. Inhalt von Register RM1) in einer folgenden Wiederholung genutzt werden (z. B. Bildung des Ausgangsvektors 431_2, 432_1). Es kann eine Schleifeninitialisierung (nicht dargestellt) durchgeführt werden, um die Schleife zu initialisieren. In einer Ausführungsform definiert die Schleifeninitialisierung die Skalare S1 und S2 und führt eine maskierte Leseoperation für den ersten zu verarbeitenden Eingangsvektor durch (die lediglich den Anfangsteil der ersten Zeile des Eingangsarrays erfasst) und liest anschließend den zweiten zu verarbeitenden Eingangsvektor. Die Schleifeninitialisierung wird damit fortgesetzt, dass ein VSHIFTR2B-Befehl ausgeführt wird, um einen ersten aktuellen Vektor zu bilden, der in der Folge von einer Array-Verarbeitungssequenz 452 verarbeitet wird. Das Ergebnis ist eine erste Ausgangszeile. Die Schleifeninitialisierung wird fortgesetzt mit dem Ausführen eines VSHIFTL2B-Befehls, um eine erste Resultierende zu bilden, welche einen Anfangsabschnitt der ersten Zeile des Ausgangsarrays enthält, der in der Folge maskiert im Ausgangsarray gespeichert und dann in RM1 verschoben wird. Die Inhalte des zweiten gelesenen Eingangsvektors werden in R2 verschoben. An dieser Stelle ist die Software-Pipelineschleife bereit zur Ausführung wie bereits unter Bezugnahme auf erörtert. Außerdem kann es eine Epilogroutine geben, die an jedem Ende nach der letzten Schleifenwiederholung ausgeführt wird, die eine maskierte Schreiboperation in den Vektorregisterraum des Endteils der letzten Zeile des Ausgangsarrays durchführt.
Der Einfachheit halber wurde die Fehlausrichtung im Ausgangsvektor 402, S2, als Eingangsbedingung zur Schleife selbst betrachtet. Es ist möglich, dass eine solche Fehlausrichtung aus der Array-Verarbeitung 452 resultiert und als eine weitere Resultierende dieser Verarbeitung 452 angegeben wird, die dem VSHIFTL2B-Befehl 453 zugeführt wird (d. h., Prozess 452 definiert S2). Darüber hinaus ist zu beachten, dass in einigen Fällen in das Ausgangsarray geschrieben werden kann, wenn die Ausgangsvektoren ausgerichtet sind. In diesem Fall kann die Resultierende von Prozess 452 in das Ausgangsarray 402 geschrieben werden, ohne dass der VSHIFTL2B-Befehl ausgeführt wird.
In einer alternativen Ausführungsform verwenden der VSHIFTR2B- und der VSHIFTL2B-Befehl anstelle eines Skalarwertes S einen Maskenwert k, um die Verschiebungssteuerungsinformationen anzugeben. Hier kann für den VSHIFTR2B-Befehl die Anzahl maskierter Bits der Maske verwendet werden, um eine skalare Verschiebungssteuerung S zu spezifizieren (z. B. 11100000 in dem Beispiel des VSHIFTR2B-Befehls von S = 5).
Diese Ausführungsform lässt sich mit folgendem Pseudocode beschreiben, wobei KL eine Anzahl von Elementen in einem Vektor ist:
Alternativ kann die Anzahl unmaskierter Bits der Eingangsmaske verwendet werden, um die Verschiebungssteuerung S zu spezifizieren.
In ähnlicher Weise können, für den VSHIFTL2B-Befehl, die maskierten Bits des Maskenwertes beispielsweise eine skalare Verschiebungssteuerung S angeben (z. B. 11111000 im Beispiel des VSHIFTL2B-Befehls von Verschiebungssteuerung S = 3).
Andere Maskenwertschemata können verwendet werden, um Verschiebungssteuerungsinformationen bereitzustellen. Die logische Umkehrung kann erzielt werden, indem ein weiterer Befehl in die Befehlssequenz 450 von eingefügt wird.
Mit den vorstehend beschriebenen Befehlen kann die beispielhafte Vektorschleife für (i = 0; i < N; i += KL) B[i + KL – 1:i] = berechnung (A[i + KL – 1:i])
vektorisiert werden und können gleichzeitig nichtausgerichtete Speicherzugriffe wie folgt eliminiert werden:
und zeigen Darstellungen von Schaltungsanordnungen für Funktionseinheiten einer Befehlsausführungspipeline 510, 520, die in der Lage sind, den VSHIFTR2B- bzw. den VSHIFTL2B-Befehl auszuführen. Wie in zu sehen, akzeptiert die VSHIFTR2B-Funktionseinheit 510 erste und zweite Eingangsvektoroperanden 501, 502. Hier haben die Eingangsvektoroperanden 501, 502 eine Größe von N Elementen. Ein weiterer Eingang 503 gibt eine von der Funktionseinheit 510 auszuführende Operation an, wobei ein Abschnitt von N–K zusammenhängenden Elementen des ersten Eingangsoperanden 501 und ein Abschnitt von K zusammenhängenden Elementen des zweiten Quelloperanden 502 ausgewählt werden, um in die Resultierende 505 eingebunden zu werden. Wie vorstehend ausführlich besprochen, kann der bei Eingang 503 empfangene Inhalt eine Fehlausrichtung in einem Datenarray angeben.
Eingang 503 wird genutzt, um ein Koppelnetz 504 zu steuern, das, als nur ein Beispiel, mittels Multiplexerschaltungen aufgebaut sein kann. Im Betrieb kann die tatsächlich auf das Koppelnetz 504 angewandte Steuerung über Eingang 503 von einem dritten Eingangsoperanden abgeleitet werden, der im Befehlsformat des Befehls angegeben ist. Beispielsweise kann, nachdem der Befehl decodiert ist, eine Reihe von Mikro-Ops an die Funktionseinheit ausgegeben oder innerhalb derselben generiert werden, um die ordnungsgemäße Schaltsteuerung des Koppelnetzes 504 einzurichten. Alternativ können ein Opcode und der dritte Eingangsoperand direkt über Eingang 503 auf das Koppelnetz 504 angewandt werden. Der dritte Eingangsoperand kann die Form eines (z. B. Masken-)Vektors oder Skalars im Befehlsformat haben. Im Fall eines Skalars kann der Skalarwert im Befehlsformat als ein Direktoperand angegeben sein oder kann aus einem anderen Skalarregisterraum abgerufen werden (z. B. dem Steuerregisterraum, wo z. B. bedingte Sprunginformationen aufbewahrt werden). Alternativ kann ein Vektoroperand tatsächlich durch den Befehl abgerufen werden, jedoch wird der Skalarwert dahingehend verstanden, dass er eines der Datenelemente des Vektors belegt.
Unabhängig von der Implementierung platziert das Koppelnetz 504 N–K zusammenhängende Elemente vom oberen Rand des ersten Quelloperanden 501 an den vorderen Rand der Resultierenden 505 und hängt innerhalb der Resultierenden K zusammenhängende Elemente vom unteren Rand des zweiten Quelloperanden 502 an den hinteren Rand der N–K Elemente an, die aus dem ersten Quelloperanden ausgewählt sind.
Der Befehl kann vollständig parallel (alle Vektorelemente werden gleichzeitig parallel verarbeitet), vollständig seriell (Elemente zur Einbindung in die Resultierende werden auf Einzelelementbasis ausgewählt) oder in einer beliebigen Kombination dieser beiden Ansätze ausgeführt werden.
In einer weiteren Ausführungsform ist die Granularität der von der Funktionseinheit 510 ausgeführten Operation konfigurierbar gestaltet, so dass die Operation an Vektorquelloperanden unterschiedlicher Elementzahlgröße durchgeführt werden kann. In diesem Fall ist N eine weitere Variable des Befehls, die beispielsweise in einem Direktoperanden des Befehls angegeben sein kann.
Wie in zu sehen, akzeptiert die VSHIFTL2B-Funktionseinheit 520 erste und zweite Eingangsvektoroperanden 511, 512. Hier haben die Eingangsvektoroperanden 511, 512 eine Größe von N Elementen. Ein weiterer Eingang 513 gibt eine von der Funktionseinheit 510 auszuführende Operation an, wobei ein oberer Abschnitt von K zusammenhängenden Elementen des ersten Eingangsoperanden 511 und ein unterer Abschnitt von N–K zusammenhängenden Elementen des zweiten Quelloperanden 512 ausgewählt werden, um in die Resultierende 515 eingebunden zu werden. Wie vorstehend ausführlich besprochen, kann der bei Eingang 513 empfangene Inhalt eine Fehlausrichtung in einem Datenarray angeben.
Eingang 513 wird genutzt, um ein Koppelnetz 514 zu steuern, das, als nur ein Beispiel, mittels Multiplexerschaltungen aufgebaut sein kann. Im Betrieb kann die tatsächlich auf das Koppelnetz 514 angewandte Steuerung über Eingang 513 von einem dritten Eingangsoperanden abgeleitet werden, der im Befehlsformat des Befehls angegeben ist. Beispielsweise kann, nachdem der Befehl decodiert ist, eine Reihe von Mikro-Ops an die Funktionseinheit ausgegeben oder innerhalb derselben generiert werden, um die ordnungsgemäße Schaltsteuerung des Koppelnetzes 514 einzurichten. Alternativ können ein Opcode und der dritte Eingangsoperand direkt über Eingang 514 auf das Koppelnetz 513 angewandt werden. Der dritte Eingangsoperand kann die Form eines (z. B. Masken-)Vektors oder Skalars im Befehlsformat haben. Im Fall eines Skalars kann der Skalarwert im Befehlsformat als ein Direktoperand angegeben sein oder kann aus einem anderen Skalarregisterraum abgerufen werden (z. B. dem Steuerregisterraum, wo z. B. bedingte Sprunginformationen aufbewahrt werden). Alternativ kann ein Vektoroperand tatsächlich durch den Befehl abgerufen werden, jedoch wird der Skalarwert dahingehend verstanden, dass er eines der Datenelemente des Vektors belegt.
Unabhängig von der Implementierung platziert das Koppelnetz 514 obere K zusammenhängende Elemente des ersten Quelloperanden 511 an den vorderen Rand der Resultierenden 515 und hängt innerhalb der Resultierenden untere N–K zusammenhängende Elemente des zweiten Quelloperanden 512 an den hinteren Rand der K Elemente an, die aus dem ersten Quelloperanden ausgewählt sind.
Der Befehl kann vollständig parallel (alle Vektorelemente werden gleichzeitig parallel verarbeitet), vollständig seriell (Elemente zur Einbindung in die Resultierende werden auf Einzelelementbasis ausgewählt) oder in einer beliebigen Kombination dieser beiden Ansätze ausgeführt werden.
In einer weiteren Ausführungsform ist die Granularität der von der Funktionseinheit 511 ausgeführten Operation konfigurierbar gestaltet, so dass die Operation an Vektorquelloperanden unterschiedlicher Elementzahlgröße durchgeführt werden kann. In diesem Fall ist N eine weitere Variable des Befehls, die beispielsweise in einem Direktoperanden des Befehls angegeben sein kann.
Es ist zu beachten, dass die vorstehend in und beschriebenen Operationen in ein und derselben Funktionseinheit zusammengefasst werden könnten. In verschiedenen Ausführungsformen entspricht der Opcode eines oder beider dieser Befehle einer Operation, die nur zusammenhängende Elementgruppen aus den beiden Quellvektoroperanden in die Resultierende verschieben kann wie vorstehend erörtert. Das bedeutet, dass der Befehl nicht verwendet werden kann, um nicht zusammenhängende Elementgruppen aus einem der Quelloperanden in die Resultierende zu verschieben. Falls nur ein einziges Element aus einem der Quelloperanden in die Resultierende verschoben werden muss, kann dieses Element als „zusammenhängend” gemäß der Operation des Befehls wie hier beschrieben betrachtet werden.
zeigt einen Kompilierungsprozess, der von einem Kompilierer durchgeführt werden kann (z. B. einem Kompilierer, der für einen Prozessor bestimmten Objektcode mit einer bestimmten Befehlssatzarchitektur konstruiert). Gemäß dem Prozess von erkennt der Kompilierer eine Verarbeitung, die an einem Array mit fehlausgerichteten Datenzeilen erfolgt 521. In Reaktion auf das Erkennen konstruiert der Kompilierer die Codesequenz, die die Array-Verarbeitung durchführt, so dass sie einen Befehl aufweist, der in seinem Befehlsformat erste und zweite Vektoroperanden sowie einen dritten Eingangsoperanden, der die Fehlausrichtung angibt, besitzt 522. In einer Ausführungsform wird kein Peeling-Prozess verwendet, um den Code zu konstruieren.
Ausführungsformen des Befehls/der Befehle wie vorstehend beschrieben können wenigstens teilweise in einem „generischen vektorfreundlichen Befehlsformat” ausgeführt sein, das nachstehend ausführlich beschrieben wird. Außerdem werden nachstehend beispielhafte Systeme, Architekturen und Pipelines näher beschrieben. Ausführungsformen des Befehls/der Befehle wie oben können in solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die dargestellten beschränkt.
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das sich für Vektorbefehle eignet (z. B. gibt es gewisse für Vektoroperationen spezifische Felder). Zwar werden Ausführungsformen beschrieben, in denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, jedoch verwenden alternative Ausführungsformen lediglich Vektoroperationen im vektorfreundlichen Befehlsformat. Beispielhaftes generisches vektorfreundliches Befehlsformat – –B
Die –B sind Blockschaltbilder, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen. ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon gemäß Ausführungsformen der Erfindung veranschaulicht; während ein Blockschaltbild ist, welches das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon gemäß Ausführungsformen der Erfindung veranschaulicht. Speziell ein generisches vektorfreundliches Befehlsformat 600, für das Befehlsvorlagen der Klasse A und Klasse B definiert sind, die beide Befehlsvorlagen ohne Speicherzugriff 605 und Befehlsvorlagen mit Speicherzugriff 620 umfassen. Der Begriff „generisch” im Zusammenhang des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat nicht an einen spezifischen Befehlssatz gebunden ist. Auch wenn Ausführungsformen beschrieben werden, bei denen Befehle im vektorfreundlichen Befehlsformat mit Vektoren arbeiten, die aus jedem der Register (Befehlsvorlagen ohne Speicherzugriff 605) oder Registern/Speicher (Befehlsvorlagen mit Speicherzugriff 620) gespeist werden, können alternative Ausführungsformen der Erfindung lediglich eines davon unterstützen. Ebenso weisen, auch wenn Ausführungsformen der Erfindung beschrieben werden, in denen Lade- und Speicherbefehle im Vektorbefehlsformat enthalten sind, alternative Ausführungsformen stattdessen oder zusätzlich dazu Befehle in einem anderen Befehlsformat auf, die die Vektoren in Register oder aus denselben verschieben (z. B. aus Speicher in Register, aus Registern in Speicher oder zwischen Registern). Ferner können, auch wenn Ausführungsformen der Erfindung beschrieben werden, die zwei Klassen von Befehlsvorlagen unterstützen, alternative Ausführungsformen lediglich eine davon oder mehr als zwei unterstützen.
Obwohl hier Ausführungsformen der Erfindung beschrieben werden, bei denen das vektorfreundliche Format Folgendes unterstützt: eine Vektoroperandenlänge (oder -größe) von 64 Byte mit 32 Bit (4 Byte) oder 64 Bit (8 Byte) Datenelementbreite (oder -größe) (womit ein 64-Byte-Vektor aus entweder 16 Doppelwort-Elementen oder alternativ aus 8 Vierwort-Elementen besteht); eine Vektoroperandenlänge (oder -größe) von 64 Byte mit 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreite (oder -größe); eine Vektoroperandenlänge (oder -größe) von 32 Byte mit 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreite (oder -größe); und eine Vektoroperandenlänge (oder -größe) von 16 Byte mit 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreite (oder -größe); können alternative Ausführungsformen mehr, weniger und/oder andere Vektoroperandengrößen (z. B. 656-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. 128 Bit (16 Byte) Datenelementbreite) unterstützen.
Die Befehlsvorlagen der Klasse in umfassen: 1) in den Befehlsvorlagen ohne Speicherzugriff 605 werden eine Befehlsvorlage für Operationen des Typs vollständige Rundungssteuerung ohne Speicherzugriff 610 und eine Befehlsvorlage für Operationen des Typs Datentransformation ohne Speicherzugriff 615 gezeigt; und 2) in den Befehlsvorlagen mit Speicherzugriff 620 werden eine temporäre Befehlsvorlage mit Speicherzugriff 625 und eine nicht-temporäre Befehlsvorlage mit Speicherzugriff 630 gezeigt. Die Befehlsvorlagen der Klasse B in umfassen: 1) in den Befehlsvorlagen ohne Speicherzugriff 605 werden eine Befehlsvorlage für eine Operation des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 612 und eine Befehlsvorlage für eine Operation des Typs vsize ohne Speicherzugriff mit Schreibmaskensteuerung 617 gezeigt; und 2) in den Befehlsvorlagen mit Speicherzugriff 620 wird eine Befehlsvorlage für die Schreibmaskensteuerung mit Speicherzugriff 627 gezeigt.
Format
Das generische vektorfreundliche Befehlsformat 600 umfasst die nachstehend aufgelisteten Felder in der Reihenfolge wie in den –B dargestellt. Im Zusammenhang mit den obigen Erörterungen in Bezug auf , und kann in einer Ausführungsform, unter Bezugnahme auf die nachstehend in den –B und vorgestellten Formatdetails, entweder ein Befehlstyp ohne Speicherzugriff 605 oder ein Befehlstyp mit Speicherzugriff 620 verwendet werden. Adressen für den/die Eingangsvektoroperanden und Ziel können im Registeradressfeld 644 angegeben werden, das nachstehend beschrieben wird. Die Befehle können destruktiv oder nicht-destruktiv formatiert sein.
Formatfeld 640 – ein spezifischer Wert (ein Befehlsformat-Kennungswert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und somit Vorkommnisse von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Somit unterscheidet der Inhalt des Formatfeldes 640 Vorkommnisse von Befehlen im ersten Befehlsformat von Vorkommnissen von Befehlen in anderen Befehlsformaten und erlaubt dadurch das Einfügen des vektorfreundlichen Befehlsformats in einen Befehlssatz, der andere Befehlsformate aufweist. Als solches ist dieses Feld in dem Sinne optional, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht benötigt wird.
Basisoperationsfeld 642 – der Inhalt dieses Feldes unterscheidet verschiedene Basisoperationen. Wie an späterer Stelle hier noch beschrieben wird, kann das Basisoperationsfeld 642 ein Opcode-Feld umfassen und/oder Teil eines solchen sein.
Registerindexfeld 644 – der Inhalt dieses Feldes spezifiziert, direkt oder durch Adressengenerierung, die Orte der Quell- und Zieloperanden, ganz gleich, ob sie sich in Registern oder im Speicher befinden. Diese umfassen eine ausreichende Anzahl von Bits zum Auswählen von N Registern aus einer P × Q-Registerdatei (z. B. 32 × 1012). Während in einer Ausführungsform N bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (z. B. können bis zu zwei Quellen unterstützt werden, wobei eine dieser Quellen zugleich als Ziel fungiert, können bis zu drei Quellen unterstützt werden, wobei eine dieser Quellen zugleich als Ziel fungiert, können bis zu zwei Quellen und ein Ziel unterstützt werden). Während in einer Ausführungsform P = 32 ist, können alternative Ausführungsformen mehr oder weniger Register unterstützen (z. B. 16). Während in einer Ausführungsform Q = 1012 Bits ist, können alternative Ausführungsformen mehr oder weniger Bits unterstützen (z. B. 128, 1024).
Modifiziererfeld 646 – der Inhalt dieses Feldes unterscheidet Vorkommnisse von Befehlen im generischen vektorfreundlichen Befehlsformat, die Speicherzugriffe spezifizieren, von solchen, bei denen dies nicht der Fall ist; das heißt, zwischen Befehlsvorlagen ohne Speicherzugriff 605 und Befehlsvorlagen mit Speicherzugriff 620. Speicherzugriffsoperationen lesen und/oder schreiben in der/die Speicherhierarchie (und spezifizieren in einigen Fällen die Quell- und/oder Zieladressen mithilfe von Werten in Registern), während Operationen ohne Speicherzugriff dies nicht tun (z. B. sind Quelle und Ziele Register). Während dieses Feld in einer Ausführungsform auch zwischen drei verschiedenen Arten der Durchführung von Speicheradressberechnungen wählt, können alternative Ausführungsformen mehr, weniger oder andere Arten unterstützen, Speicheradressberechnungen durchzuführen.
Erweiterungsoperationsfeld 650 – der Inhalt dieses Feldes unterscheidet, welche von mehreren unterschiedlichen Operationen zusätzlich zur Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 668, ein Alphafeld 652 und ein Betafeld 654 unterteilt. Das Erweiterungsoperationsfeld ermöglicht es, gängige Gruppen von Operationen in einem einzigen Befehl anstatt in 2, 3 oder 4 Befehlen durchzuführen. Nachstehend werden einige Beispiele für Befehle gegeben (deren Nomenklatur an späterer Stelle hierin noch ausführlicher besprochen wird), die das Erweiterungsfeld 650 nutzen, um die Anzahl erforderlicher Befehle zu verringern.
wobei [rax] der Basiszeiger ist, der für die Adressengenerierung zu verwenden ist, und wobei {} eine Umwandlungsoperation anzeigt, die durch das Datenmanipulationsfeld spezifiziert ist (an späterer Stelle hierin ausführlicher beschrieben).
Skalierfeld 660 – der Inhalt dieses Feldes ermöglicht das Skalieren des Indexfeldinhalts für die Speicheradressengenerierung (z. B. für die Adressengenerierung, die 2^skalierung·index + basis verwendet).
Verschiebungsfeld 662A – der Inhalt dieses Feldes wird im Rahmen der Speicheradressengenerierung verwendet (z. B. für eine Adressengenerierung, die 2^skalierung·index + basis + verschiebung verwendet).
Verschiebungsfaktorfeld 662B (es sei darauf hingewiesen, dass die Darstellung von Verschiebungsfeld 662A direkt über Verschiebungsfaktorfeld 662B angibt, dass entweder das eine oder das andere verwendet wird) – der Inhalt dieses Feldes wird im Rahmen der Adressengenerierung verwendet; er spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) zu skalieren ist – wobei N die Anzahl Bytes im Speicherzugriff ist (z. B. für eine Adressengenerierung, die 2^skalierung·index + basis + skalierte verschiebung verwendet). Redundante niedrigwertige Bits werden ignoriert, und somit wird der Inhalt des Verschiebungsfaktorfeldes mit der Gesamtgröße der Speicheroperanden (N) multipliziert, um die endgültige Verschiebung zu generieren, die beim Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird von der Prozessor-Hardware zur Laufzeit basierend auf dem vollständigen (an späterer Stelle hierin beschrieben) Opcode-Feld 674 und dem Datenmanipulationsfeld 654C bestimmt, wie an späterer Stelle hierin noch beschrieben wird. Das Verschiebungsfeld 662A und das Verschiebungsfaktorfeld 662B sind in dem Sinne optional, dass sie nicht für die Befehlsvorlagen ohne Speicherzugriff 605 benutzt werden und/oder dass verschiedene Ausführungsformen nur eines oder keines der beiden Felder implementieren können.
Datenelementbreitefeld 664 – der Inhalt dieses Feldes unterscheidet, welche von mehreren Datenelementbreiten zu verwenden ist (in einigen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für einige der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht benötigt wird, falls nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten mittels eines Aspekts des Opcodes unterstützt werden.
Schreibmaskenfeld 670 – der Inhalt dieses Feldes steuert, für jede Datenelementposition, ob die betreffende Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Erweiterungsoperation widerspiegelt. Befehlsvorlagen der Klasse A unterstützen Zusammenführen-Schreibmaskieren, während Befehlsvorlagen der Klasse B sowohl Zusammenführen- als auch Nullsetzen-Schreibmaskieren unterstützen. Beim Zusammenführen ermöglichen es Vektormasken, einen beliebigen Satz von Elementen im Ziel während der Ausführung irgendeiner Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) vor Aktualisierungen zu schützen; in einer anderen Ausführungsform das Beibehalten des alten Werts jedes Elements des Ziels, wobei das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz hierzu erlauben beim Nullsetzen Vektormasken, einen beliebigen Satz von Elementen im Ziel während der Ausführung irgendeiner Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) auf null zu setzen; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen Wert 0 hat. Eine Untermenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der ausgeführten Operation zu steuern (das heißt, die Spanne von Elementen, die modifiziert werden, vom ersten bis zum letzten); allerdings ist es nicht notwendig, dass die modifizierten Elemente aufeinander folgen. Somit ermöglicht das Schreibmaskenfeld 670 partielle Vektoroperationen einschließlich Ladevorgänge, Speichervorgänge, arithmetische Operationen, logische Operationen etc. Ebenso kann diese Maskierung zur Fehlerunterdrückung genutzt werden (d. h. durch Maskieren der Datenelementpositionen des Ziels, um das Empfangen des Ergebnisses irgendeiner Operation zu verhindern, das einen Fehler verursachen kann/wird – wenn z. B. angenommen wird, dass ein Vektor im Speicher eine Seitengrenze schneidet und dass die erste Seite, nicht jedoch die zweite Seite einen Seitenfehler verursachen würde, kann die Seitenstörung ignoriert werden, wenn alle auf der ersten Seite liegenden Datenelemente des Vektors durch die Schreibmaske maskiert sind). Ferner erlauben Schreibmasken „Vektorisierungsschleifen”, die bestimmte Typen bedingter Aussagen enthalten. Während hier Ausführungsformen der Erfindung beschrieben werden, bei denen der Inhalt des Schreibmaskenfeldes 670 eines aus einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske enthält (und der Inhalt des Schreibmaskenfeldes 670 somit indirekt angibt, dass eine Maskierung durchzuführen ist), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich dazu, dass der Inhalt des Schreibmaskenfeldes 670 die durchzuführende Maskierung direkt spezifiziert. Ferner erlaubt Nullsetzen Leistungsverbesserungen, wenn: 1) eine Registerumbenennung bei Befehlen benutzt wird, deren Zieloperand nicht auch eine Quelle ist (auch nichtternäre Befehle genannt), weil während der Pipelinestufe der Registerumbenennung das Ziel keine implizite Quelle mehr ist (es müssen keine Datenelemente aus dem aktuellen Zielregister in das umbenannte Zielregister kopiert werden oder in irgendeiner Form mit durch die Operation gezogen werden, weil jedes Datenelement, das nicht ein Ergebnis der Operation ist (jedes maskierte Datenelement) auf null gesetzt wird); und 2) während der Stufe des Zurückkopierens, weil Nullen geschrieben werden.
Direktoperandenfeld 672 – der Inhalt dieses Feldes ermöglicht die Spezifikation eines Direktoperanden. Dieses Feld ist in dem Sinne optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats, das Direktoperanden nicht unterstützt, nicht vorkommt und in Befehlen, die keinen Direktoperanden nutzen, nicht vorhanden ist.
Wahl der Befehlsvorlagenklasse
Klassenfeld 668 – der Inhalt dieses Feldes unterscheidet zwischen verschiedenen Klassen von Befehlen. Unter Bezugnahme auf die –B wählt der Inhalt dieses Feldes zwischen Befehlen der Klasse A und der Klasse B. In den –B werden Quadrate mit abgerundeten Ecken verwendet um anzuzeigen, dass in einem Feld ein spezifischer Wert enthalten ist (z. B. Klasse A 668A bzw. Klasse B 668B für das Klassenfeld 668 in den –B).
Befehlsvorlagen der Klasse A ohne Speicherzugriff
Im Fall von Befehlsvorlagen der Klasse A ohne Speicherzugriff 605 wird das Alphafeld 652 als ein RS-Feld 652A interpretiert, dessen Inhalt unterscheidet, welcher von verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Runden 652A.1 und Datentransformation 652A.2 jeweils für die Befehlsvorlage für Operationen des Typs Runden ohne Speicherzugriff 610 bzw. die Befehlsvorlagen für Operationen des Typs Datentransformation ohne Speicherzugriff 615 spezifiziert), während das Betafeld 654 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In werden Blöcke mit abgerundeten Ecken verwendet um anzuzeigen, dass ein spezifischer Wert vorhanden ist (z. B. kein Speicherzugriff 646A im Modifiziererfeld 646; Runden 652A.1 Datentransformation 652A.2 für Alphafeld 652/rs-Feld 652A). In den Befehlsvorlagen ohne Speicherzugriff 605 sind das Skalierfeld 660, das Verschiebungsfeld 662A und das Verschiebungsskalierfeld 662B nicht vorhanden.
Befehlsvorlagen ohne Speicherzugriff – Operation des Typs vollständige Rundungssteuerung
In der Befehlsvorlage für Operationen des Typs vollständige Rundungssteuerung ohne Speicherzugriff 610 wird das Betafeld 654 als Rundungssteuerungsfeld 654A interpretiert, dessen Inhalt eine statische Rundung bereitstellt. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerungsfeld 654A ein Feld für das Unterdrücken aller Gleitkommaausnahmen (SAE) 656 und ein Rundungsoperationsteuerungsfeld 658 aufweist, können alternative Ausführungsformen das Codieren beider Konzepte in ein und dasselbe Feld unterstützen oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (z. B. können sie nur das Rundungsoperationsteuerungsfeld 658 aufweisen).
SAE-Feld 656 – der Inhalt dieses Feldes unterscheidet, ob das Berichten von Ausnahmeereignissen deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Feldes 656 anzeigt, dass die Unterdrückung aktiviert ist, berichtet ein gegebener Befehl keinerlei Gleitkommaausnahmemarkierungen und ruft keine Abwickelvorrichtung (Handler) für Gleitkommaausnahmen auf.
Rundungsoperationsteuerungsfeld 658 – der Inhalt dieses Feldes unterscheidet, welche Operation aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden nach Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationsteuerungsfeld 658 das Ändern des Rundungsmodus für jeden Einzelbefehl und ist daher besonders nützlich, wenn dies erforderlich ist. In einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi aufweist, hat der Inhalt des Rundungsoperationsteuerungsfeldes 650 Vorrang vor diesem Registerwert (es ist vorteilhaft, den Rundungsmodus wählen zu können, ohne eine Speichern-Modifizieren-Wiederherstellen-Operation an einem solchen Steuerregister durchführen zu müssen).
Befehlsvorlagen ohne Speicherzugriff – Operation des Typs Datentransformation
Bei der Befehlsvorlage für Operationen des Typs Datentransformation ohne Speicherzugriff 615 wird das Betafeld 654 als ein Datentransformationsfeld 654B interpretiert, dessen Inhalt unterscheidet, welche von mehreren Datentransformationen durchgeführt werden soll (z. B. keine Datentransformation, Swizzle, Broadcast).
Befehlsvorlagen der Klasse A mit Speicherzugriff
Im Fall der Befehlsvorlage der Klasse A mit Speicherzugriff 620 wird das Alphafeld 652 als ein Räumungshinweisfeld 652B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in werden 652B.1 temporär bzw. 652B.2 nicht-temporär für die temporäre Befehlsvorlage mit Speicherzugriff 625 und die nicht-temporäre Befehlsvorlage mit Speicherzugriff 630 spezifiziert), während das Betafeld 654 als ein Datenmanipulationsfeld 654C interpretiert wird, dessen Inhalt unterscheidet, welche von mehreren Datenmanipulationsoperationen (auch Primitive genannt) durchgeführt werden soll (z. B. keine Manipulation; Broadcast; Hochkonvertierung einer Quelle; und Herunterkonvertierung eines Ziels). Die Befehlsvorlagen mit Speicherzugriff 620 umfassen das Skalierfeld 660 und optional das Verschiebungsfeld 662A oder das Verschiebungsskalierfeld 662B.
Vektorspeicherbefehle laden, mit Konvertierunterstützung, Vektoren aus dem Speicher und speichern Vektoren im Speicher. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten datenelementweise vom/an den Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske vorgegeben werden, die als Schreibmaske ausgewählt ist. In , werden Quadrate mit abgerundeten Ecken verwendet um anzuzeigen, dass in einem Feld ein spezifischer Wert enthalten ist (z. B. Speicherzugriff 646B im Modifiziererfeld 646; temporär 652B.1 und nicht-temporär 652B.2 im Alphafeld 652/Räumungshinweisfeld 652B).
Befehlsvorlagen mit Speicherzugriff – temporär
Temporäre Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um vom Zwischenspeichern (Caching) zu profitieren. Dies ist jedoch ein Hinweis und unterschiedliche Prozessoren können diesen auf verschiedene Art und Weise implementieren; dies schließt auch ein vollständiges Ignorieren des Hinweises ein.
Befehlsvorlagen mit Speicherzugriff – nicht-temporär
Nicht-temporäre Daten sind Daten, die wahrscheinlich nicht früh genug wiederverwendet werden, um vom Zwischenspeichern (Caching) im 1st-Level-Cache zu profitieren und sollten bei der Räumung Priorität erhalten. Dies ist jedoch ein Hinweis und unterschiedliche Prozessoren können diesen auf verschiedene Art und Weise implementieren; dies schließt auch ein vollständiges Ignorieren des Hinweises ein.
Befehlsvorlagen der Klasse B
Im Fall der Befehlsvorlagen der Klasse B wird das Alphafeld 652 als ein Feld zur Schreibmaskensteuerung (Z) 652C interpretiert, dessen Inhalt unterscheidet, ob das durch das Schreibmaskenfeld 670 gesteuerte Schreibmaskieren ein Zusammenführen oder Nullsetzen sein soll.
Befehlsvorlagen der Klasse B ohne Speicherzugriff
Im Fall der Befehlsvorlagen der Klasse B ohne Speicherzugriff 605 wird ein Teil des Betafeldes 654 als ein RL-Feld 657A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 657A.1 und Vektorlänge (VSIZE) 657A.2 jeweils für die Befehlsvorlage für Operationen des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 612 und die Befehlsvorlage für eine Operation des Typs VSIZE 617 ohne Speicherzugriff mit Schreibmaskensteuerung spezifiziert), während der Rest des Betafeldes 654 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In werden Blöcke mit abgerundeten Ecken verwendet um anzuzeigen, dass ein spezifischer Wert vorhanden ist (z. B. kein Speicherzugriff 646A im Modifiziererfeld 646; Runden 657A.1 und VSIZE 657A.2 im RL-Feld 657A). In den Befehlsvorlagen ohne Speicherzugriff 605 sind das Skalierfeld 660, das Verschiebungsfeld 662A und das Verschiebungsskalierfeld 662B nicht vorhanden.
Befehlsvorlagen ohne Speicherzugriff – Operation des Typs partielle Rundungssteuerung mit Schreibmaskensteuerung
Bei der Befehlsvorlage für Operationen des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 610 wird der Rest des Betafeldes 654 als ein Rundungsoperationsfeld 659A interpretiert, und das Berichten von Ausnahmeereignissen wird deaktiviert (ein gegebener Befehl berichtet keinerlei Gleitkommaausnahmemarkierungen und ruft keine Abwickelvorrichtung (Handler) für Gleitkommaausnahmen auf).
Rundungsoperationssteuerungsfeld 659A – ebenso wie das Rundungsoperationssteuerungsfeld 658 unterscheidet der Inhalt dieses Feldes, welche Operation aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden nach Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationsteuerungsfeld 659A das Ändern des Rundungsmodus für jeden Einzelbefehl und ist daher besonders nützlich, wenn dies erforderlich ist. In einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi aufweist, hat der Inhalt des Rundungsoperationsteuerungsfeldes 650 Vorrang vor diesem Registerwert (es ist vorteilhaft, den Rundungsmodus wählen zu können, ohne eine Speichern-Modifizieren-Wiederherstellen-Operation an einem solchen Steuerregister durchführen zu müssen).
Befehlsvorlagen ohne Speicherzugriff – Operation des Typs VSIZE mit Schreibmaskensteuerung
Bei der Befehlsvorlage für Operationen des Typs VSIZE ohne Speicherzugriff mit Schreibmaskensteuerung 617 wird der Rest des Betafeldes 654 als Vektorlängenfeld 659B interpretiert, dessen Inhalt unterscheidet, welche von mehreren Datenvektorlängen durchgeführt werden soll (z. B. 128, 856 oder 1012 Bytes).
Befehlsvorlagen der Klasse B mit Speicherzugriff
Bei der Befehlsvorlage der Klasse A mit Speicherzugriff 620 wird ein Teil des Betafeldes 654 als Broadcast-Feld 657B interpretiert, dessen Inhalt unterscheidet, ob die Datenmanipulationsoperation des Typs Broadcast durchgeführt werden soll oder nicht, während der Rest des Betafeldes 654 als Vektorlängenfeld 659B interpretiert wird. Die Befehlsvorlagen mit Speicherzugriff 620 umfassen das Skalierfeld 660 und optional das Verschiebungsfeld 662A oder das Verschiebungsskalierfeld 662B.
Weitere Anmerkungen zu den Feldern
Unter Bezugnahme auf das generische vektorfreundliche Befehlsformat 600 wird ein vollständiges Opcode-Feld 674 gezeigt, einschließlich Formatfeld 640, Basisoperationsfeld 642 und Datenelementbreitefeld 664. Während eine Ausführungsform gezeigt wird, bei der das vollständige Opcode-Feld 674 alle diese Felder umfasst, umfasst das vollständige Opcode-Feld 674 in Ausführungsformen, die nicht alle dieser Felder unterstützen, weniger als alle diese Felder. Das vollständige Opcode-Feld 674 stellt den Operationscode (Opcode) bereit.
Das Erweiterungsoperationsfeld 650, das Datenelementbreitefeld 664 und das Schreibmaskenfeld 670 ermöglichen, dass diese Merkmale im generischen vektorfreundlichen Befehlsformat für jeden Einzelbefehl spezifiziert werden können.
Die Kombination von Schreibmaskenfeld und Datenelementbreitefeld erzeugt dahingehend typisierte Befehle, dass sie ermöglichen, die Maske auf Basis von unterschiedlichen Datenelementbreiten anzuwenden.
Das Befehlsformat erfordert eine relativ geringe Anzahl von Bits, da es je nach Inhalt anderer Felder verschiedene Felder für verschiedene Zwecke wiederverwendet. Beispielsweise ist ein Gesichtspunkt, dass der Inhalt des Modifiziererfeldes zischen Befehlsvorlagen ohne Speicherzugriff 605 in –B und Befehlsvorlagen mit Speicherzugriff 6250 in –B wählt; während der Inhalt des Klassenfeldes 668 innerhalb der Befehlsvorlagen ohne Speicherzugriff 605 zwischen den Befehlsvorlagen 610/615 von und 612/617 von wählt; und während der Inhalt des Klassenfeldes 668 innerhalb der Befehlsvorlagen mit Speicherzugriff 620 zwischen den Befehlsvorlagen 625/830 von und 627 von wählt. Aus einem anderen Gesichtspunkt wählt der Inhalt des Klassenfeldes 668 zwischen Befehlsvorlagen der Klasse A bzw. der Klasse B aus und B; während der Inhalt des Modifiziererfeldes innerhalb der Befehlsvorlagen der Klasse A zwischen den Befehlsvorlagen 605 und 620 von wählt; und während der Inhalt des Modifiziererfeldes innerhalb der Befehlsvorlagen der Klasse B zwischen den Befehlsvorlagen 605 und 620 von wählt. Im Falle, dass der Inhalt des Klassenfeldes eine Befehlsvorlage der Klasse A anzeigt, wählt der Inhalt des Modifiziererfeldes 646 die Interpretation des Alphafeldes 652 (zwischen rs-Feld 652A und EH-Feld 652B). In ähnlicher Weise wählen die Inhalte des Modifiziererfeldes 646 und des Klassenfeldes 668, ob das Alphafeld als das rs-Feld 652A, das EH-Feld 652B oder das Schreibmaskensteuerungsfeld (Z) 652C interpretiert wird. Im Falle, dass das Klassen- und das Modifiziererfeld eine Operation der Klasse A ohne Speicherzugriff anzeigen, ändert sich die Interpretation des Betafeldes des Erweiterungsfeldes je nach dem Inhalt des rs-Feldes; während im Falle, dass das Klassen- und das Modifiziererfeld eine Operation der Klasse B ohne Speicherzugriff anzeigen, die Interpretation des Betafeldes vom Inhalt des RL-Feldes abhängt. Im Falle, dass das Klassen- und das Modifiziererfeld eine Operation der Klasse A mit Speicherzugriff anzeigen, ändert sich die Interpretation des Betafeldes des Erweiterungsfeldes je nach dem Inhalt des Basisoperationsfeldes; während im Falle, dass das Klassen- und das Modifiziererfeld eine Operation der Klasse B mit Speicherzugriff anzeigen, die Interpretation des Broadcast-Feldes 657B des Betafeldes des Erweiterungsfeldes je nach Inhalt des Basisoperationsfeldes wechselt. Somit ermöglicht die Kombination von Basisoperationsfeld, Modifiziererfeld und Erweiterungsoperationsfeld eine noch breitere Vielfalt von Erweiterungsoperationen, die spezifiziert werden können.
Die verschiedenen in Klasse A und Klasse B zu findenden Befehlsvorlagen sind in unterschiedlichen Situationen von Vorteil. Klasse A ist nützlich beim Nullsetzen-Schreibmaskieren oder wenn aus Leistungsgründen kürzere Vektorlängen erwünscht sind. Beispielsweise erlaubt das Nullsetzen, falsche Abhängigkeiten zu vermeiden, wenn die Umbenennung verwendet wird, da wir nicht mehr künstlich mit dem Ziel zusammenführen müssen; als weiteres Beispiel verringert die Vektorlängensteuerung Speichern-Laden-Weiterleitungsprobleme, wenn kürzere Vektorgrößen mit der Vektormaske emuliert werden. Klasse B ist nützlich, wenn es wünschenswert ist: 1) Gleitkommaausnahmen zuzulassen (d. h. wenn der Inhalt des SAE-Feldes „Nein” lautet), während gleichzeitig Rundungsmodussteuerungen verwendet werden; 2) Hochkonvertierung, Swizzle, Swap und/oder Herunterkonvertierung nutzen zu können; 3) Daten des Typs Grafik zu bearbeiten. Beispielsweise reduzieren Hochkonvertierung, Swizzle, Swap, Herunterkonvertierung und der Datentyp Grafik die Anzahl der Befehle, die benötigt werden, wenn mit Quellen in einem anderen Format gearbeitet wird; als weiteres Beispiel sorgt die Fähigkeit, Ausnahmen zuzulassen, für volle IEEE-Konformität bei gerichteten Rundungsmodi.
Beispielhaftes spezifisches vektorfreundliches Befehlsformat
ist ein Blockschaltbild, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung veranschaulicht. zeigt ein spezifisches vektorfreundliches Befehlsformat 700, das in dem Sinne spezifisch ist, als dass es den Ort, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 700 kann verwendet werden, um den x86-Befehlssatz zu erweitern, und somit sind einige der Felder ähnlich wie die Felder oder identisch mit den Feldern, die im bestehenden x86-Befehlssatz und Erweiterungen davon (z. B. AVX) verwendet werden. Dieses Format bleibt konsistent mit dem Präfixcodierfeld, dem realen Opcode-Byte-Feld, dem MOD-R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und den Direktoperandenfeldern des bestehenden x86-Befehlssatzes mit Erweiterungen. Die Felder aus , auf die die Felder aus abgebildet sind, sind hier dargestellt.
An dieser Stelle sei angemerkt, dass auch wenn Ausführungsformen der Erfindung zur Veranschaulichung unter Bezugnahme auf das spezifische vektorfreundliche Befehlsformat 700 im Zusammenhang des generischen vektorfreundlichen Befehlsformats 600 beschrieben werden, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 700 beschränkt ist, sofern dies nicht ausdrücklich geltend gemacht wird. So zieht das generische vektorfreundliche Befehlsformat 600 beispielsweise verschiedene mögliche Größen für die verschiedenen Felder in Betracht, während das spezifische vektorfreundliche Befehlsformat 700 als Befehlsformat mit Feldern spezifischer Größe gezeigt wird. Als spezifisches Beispiel sei angeführt, dass das Datenelementbreitefeld 664 zwar als ein Ein-Bit-Feld im spezifischen vektorfreundlichen Befehlsformat 700 dargestellt ist, die Erfindung jedoch diesbezüglich nicht eingeschränkt ist (das heißt, das generische vektorfreundliche Befehlsformat 600 zieht auch andere Größen des Datenelementbreitefeldes 664 in Betracht).
Format – Abb. 7
Das generische vektorfreundliche Befehlsformat 600 umfasst die nachstehend aufgelisteten Felder in der Reihenfolge wie in dargestellt.
EVEX-Präfix (Bytes 0–3)
EVEX-Präfix 702 – ist in einer Vier-Byte-Form codiert.
Formatfeld 640 (EVEX-Byte 0, Bits [7:0]) – das erste Byte (EVEX-Byte 0) ist das Formatfeld 640 und enthält 0x62 (der eindeutige Wert, der zum Unterscheiden des vektorfreundlichen Befehlsformats in einer Ausführungsform der Erfindung verwendet wird).
Die zweiten-vierten Bytes (EVEX Bytes 1–3) umfassen eine Anzahl von Bitfeldern, die eine spezifische Funktionalität bereitstellen.
REX-Feld 705 (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 657 BEX-Byte 1, Bit [5] – B). Die Bitfelder EVEX.R, EVEX.X und EVEX.B stellen dieselbe Funktionalität bereit wie die entsprechenden VEX-Bitfelder und werden unter Verwendung der 1er-Komplementform codiert, d. h. ZMM0 wird als 1111B codiert, ZMM15 wird als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes nach dem Stand der Technik (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von EVEX.R, EVEX.X und EVEX.B. gebildet werden können.
REX'-Feld 710 – dies ist der erste Teil des REX'-Feldes 710 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] – R'), das verwendet wird, um die oberen 16 oder die unteren 16 Register des erweiterten 32-Register-Satzes zu codieren. In einer Ausführungsform der Erfindung ist dieses Bit, zusammen mit anderen Bits wie nachstehend angegeben, in einem bit-invertierten Format gespeichert, um (im bekannten x86 32-Bit-Modus) von dem BOUND-Befehl zu unterscheiden, dessen reales Opcode-Byte 62 ist, der jedoch im (nachstehend beschriebenen) MOD-R/M-Feld nicht den Wert 11 im MOD-Feld akzeptiert; alternative Ausführungsformen der Erfindung speichern dieses und die anderen nachstehend angegebenen Bits nicht im 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 dem anderen RRR aus den anderen Feldern gebildet.
Opcode-Map-Feld 715 (EVEX-Byte 1, Bits [3:0] – mmmm) – der Inhalt dieses Feldes codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
Datenelementbreitefeld 664 (EVEX-Byte 2, Bit [7] – W) – wird durch die Bezeichnung EVEX.W dargestellt. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (32-Bit-Datenelemente oder 64-Bit-Datenelemente).
EVEX.vvvv 720 (EVEX Byte 2, Bits [6:3] – vvvv) – die Rolle von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, spezifiziert in invertierter Form (1er-Komplement), und gilt für Befehle mit 2 oder mehr Quelloperanden; 2) EVEX.vvvv codiert den Zielregisteroperanden, spezifiziert in 1er-Komplementform für bestimmte Vektorverschiebungen; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Somit codiert das Feld EVEX.vvvv 720 die 4 niedrigwertigen Bits des ersten Quellregister-Spezifikators, der in invertierter (1er-Komplement) Form gespeichert ist. In Abhängigkeit von dem Befehl wird ein zusätzliches unterschiedliches EVEX-Bitfeld verwendet, um die Spezifikatorgröße auf 32 Register zu erweitern.
EVEX.0 668 Klassenfeld (EVEX-Byte 2, Bit [2] – U) – Falls EVEX.0 = 0 ist, zeigt dies Klasse A oder EVEX.U0 an; falls EVEX.0 = 1 ist, zeigt dies Klasse B oder EVEX.U1 an.
Präfixcodierfeld 725 (EVEX-Byte 2, Bits [1:0] – pp) – stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zum Bereitstellen von Unterstützung für die bisherigen SSE-Befehle im EVEX-Präfix-Format hat dies außerdem den Vorteil, dass das SIMD-Präfix verdichtet wird (anstatt ein Byte zu benötigen, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Präfix nur 2 Bits). In einer Ausführungsform werden diese bisherigen SIMD-Präfixe, um bisherige SSE-Befehle zu unterstützen, die ein SIMD-Präfix (66H, F2H, F3H) sowohl im bisherigen Format als auch im EVEX-Präfix-Format verwenden, in das SIMD-Präfix-Codierfeld eincodiert; und zur Laufzeit werden diese bisherigen SIMD-Präfixe in das bisherige SIMD-Präfix erweitert, bevor sie für die PLA des Decodierers bereitgestellt werden (so dass die PLA das bisherige Format und das EVEX-Format dieser bisherigen Befehle ohne Modifikation ausführen kann). Auch wenn neuere Befehle den Inhalt des EVEX-Präfixcodierfeldes direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen aus Konsistenzgründen in ähnlicher Weise, erlauben jedoch, dass unterschiedliche Bedeutungen durch diese bisherigen SIMD-Präfixe spezifiziert werden. Eine alternative Ausführungsform kann die PLA umgestalten, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, so dass keine Erweiterung erforderlich ist.
Alphafeld 652 (EVEX Byte 3, Bit [7] – EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N; auch dargestellt durch α) – wie vorstehend beschrieben ist dieses Feld kontextspezifisch. Eine nähere Beschreibung folgt an späterer Stelle hierin.
Betafeld 654 (EVEX Byte 3, Bits [6:4] – SSS, auch bekannt als EVEX.s_2-0, EVEX.r_2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; auch dargestellt durch βββ) – wie vorstehend beschrieben ist dieses Feld kontextspezifisch. Eine nähere Beschreibung folgt an späterer Stelle hierin.
REX'-Feld 710 – dies ist der Rest des REX'-Feldes und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] – V'), das verwendet werden kann, um die oberen 16 oder die unteren 16 Register des erweiterten 32-Register-Satzes zu codieren. Dieses Bit ist im bit-invertierten 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 gebildet.
Schreibmaskenfeld 670 (EVEX-Byte 3, Bits [2:0] – kkk) – der Inhalt dieses Feldes spezifiziert den Index eines Registers in den Schreibmaskenregistern wie vorstehend beschrieben. In einer Ausführungsform der Erfindung hat der spezifische Wert EVEX.kkk = 000 ein besonderes Verhalten, das impliziert, dass keine Schreibmaske für diesen speziellen Befehl verwendet wird (dies kann auf verschiedene Art und Weise implementiert sein, unter anderem durch die Verwendung einer Schreibmaske, die mit allen Einsen festverdrahtet ist, oder einer Hardware, die die Maskierungshardware umgeht).
Reales Opcode-Feld 730 (Byte 4)
Dieses Feld wird auch Opcode-Byte genannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
MOD R/M-Feld 740 (Byte 5)
Modifiziererfeld 646 (MODR/M.MOD, Bits [7–6] – MOD-Feld 742) – Wie vorstehend beschrieben, unterscheidet der Inhalt des MOD-Feldes 742 zwischen Operationen mit und ohne Speicherzugriff. Das Feld wird an späterer Stelle hierin noch näher beschrieben.
MODR/M.reg-Feld 744, Bits [5–3] – die Rolle des ModR/M.reg-Feldes kann auf zwei Situationen zusammengefasst werden: Das ModR/M.reg-Feld codiert den Zielregisteroperanden oder einen Quellregisteroperanden, oder das ModR/M.reg-Feld wird als Opcode-Erweiterung behandelt und nicht für das Codieren irgendeines Befehlsoperanden verwendet.
MODR/M.r/m-Feld 746, Bits [2–0] – die Rolle des ModR/M.r/m-Feldes kann Folgendes umfassen: Das ModR/M.r/m-Feld codiert den Befehlsoperanden, der eine Speicheradresse referenziert, oder das ModR/M.r/m-Feld codiert den Zielregisteroperanden oder einen Quellregisteroperanden.
Skala, Index, Basis (SIB) Byte (Byte 6)
Skalierfeld 660 (SIB.SS, Bits [7–6] – Wie vorstehend beschrieben, wird der Inhalt des Skalierfeldes 660 für die Generierung von Speicheradressen verwendet. Das Feld wird an späterer Stelle hierin noch näher beschrieben.
SIB.xxx 754 (Bits [5–3] und SIB.bbb 756 (Bits [2–0]) – die Inhalte dieser Felder sind zuvor unter Bezugnahme auf die Registerindizes Xxxx und Bbbb angesprochen worden.
Verschiebungs-Byte(s) (Byte 7 oder Bytes 7–10)
Verschiebungsfeld 662A (Bytes 7–10) – wenn das MOD-Feld 742 den Wert 10 enthält, sind die Bytes 7–10 das Verschiebungsfeld 662A, und es arbeitet genauso wie die bisherige 32-Bit-Verschiebung (disp32) und arbeitet mit Byte-Granularität.
Verschiebungsfaktorfeld 662B (Byte 7) – wenn das MOD-Feld 742 den Wert 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 662B. Der Ort dieses Feldes ist identisch mit dem Ort der 8-Bit-Verschiebung (disp8) des bisherigen x86-Befehlssatzes, die mit Byte-Granularität arbeitet. Da disp8 vorzeichenerweitert ist, kann nur ein Versatz zwischen –128 und 127 Bytes adressiert werden; in Bezug auf 64-Byte-Cachezeilen verwendet disp8 8 Bits, die 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; allerdings erfordert disp32 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 662B eine Neuinterpretation von disp8; beim Verwenden des Verschiebungsfaktorfeldes 662B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfeldes multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Diese Art der Verschiebung wird als disp8·N bezeichnet. Dies reduziert die durchschnittliche Befehlslänge (ein einzelnes Byte wird 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 somit müssen die redundanten niederwertigen Bits des Adressversatzes nicht codiert werden. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 662B die 8-Bit-Verschiebung des bisherigen x86-Befehlssatzes. Somit wird das Verschiebungsfaktorfeld 662B auf dieselbe Weise codiert wie eine 8-Bit-Verschiebung des x86-Befehlssatzes (so dass keine Änderungen an den Mod-RM/SIB-Codierregeln erfolgen), mit der einzigen Ausnahme, dass disp8 auf disp8·N überladen wird. Mit anderen Worten gibt es keine Änderungen hinsichtlich der Codierregeln oder der Codierlängen, sondern nur hinsichtlich der Interpretation des Verschiebungswerts durch die Hardware (welche die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byte-weisen Adressversatz zu erhalten).
Direktoperand
Das Direktoperandenfeld 672 arbeitet wie vorstehend beschrieben.
Beispielhafte Registerarchitektur – Abb. 8
ist ein Blockschaltbild einer Registerarchitektur 800 gemäß einer Ausführungsform der Erfindung. Die Registerdateien und Register der Registerarchitektur sind nachstehend aufgelistet:
Vektorregisterdatei 810 – in der dargestellten Ausführungsform gibt es 32 Vektorregister, die 812 Bits breit sind; diese Register werden als zmm0 bis zmm31 referenziert. Die geringerwertigen 656 Bits der unteren 16 zmm-Register werden auf die Register ymm0–16 überlagert. Die geringerwertigen 128 Bits der unteren 16 zmm-Register (die geringerwertigen 128 Bits der ymm-Register) werden auf die Register xmm0–15 überlagert. Das spezifische vektorfreundliche Befehlsformat 700 wirkt auf diese überlagerte Registerdatei wie in den nachstehenden Tabellen dargestellt.
Mit anderen Worten wählt das Vektorlängenfeld 659B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede dieser kürzeren Längen halb so lang ist wie die vorhergehende Länge; und Befehlsvorlagen ohne das Vektorlängenfeld 659B wirken auf die maximale Vektorlänge. Ferner wirken, in einer Ausführungsform, die Befehlsvorlagen der Klasse B des spezifischen vektorfreundlichen Befehlsformats 700 auf gepackte oder skalare Gleitkommadaten mit einfacher/doppelter Genauigkeit und auf gepackte oder skalare ganzzahlige Daten. Skalaroperationen sind Operationen, die für die niedrigstwertige Datenelementposition in einem zmm/ymm/xmm-Register durchgeführt werden; die höherwertigen Datenelementpositionen bleiben entweder so, wie sie vor dem Befehl waren, oder sie werden je nach Ausführungsform auf null gesetzt.
Schreibmaskenregister 815 – in der dargestellten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), jedes mit einer Größe von 64 Bits. Wie vorstehend beschrieben, kann das Vektormaskenregister k0 in einer Ausführungsform der Erfindung nicht als eine Schreibmaske verwendet werden; wenn das Codieren, das normalerweise k0 angeben würde, für eine Schreibmaske verwendet wird, wählt es eine festverdrahtete Schreibmaske von 0xFFFF aus, wodurch effektiv die Schreibmaskierung für diesen Befehl deaktiviert wird.
Steuerungs- und Statusregister für Multimedia-Erweiterungen (MXCSR) 820 – in der dargestellten Ausführungsform stellt dieses 32-Bit-Register Status- und Steuerungsbits zur Verwendung in Gleitkommaoperationen bereit.
Universalregister 825 – in der dargestellten Ausführungsform gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den bestehenden x86 Adressierungsmodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register werden durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 referenziert.
Erweitertes Kennzeichen(EFLAGS)-Register 830 – in der dargestellten Ausführungsform wird dieses 32-Bit-Register verwendet, um die Ergebnisse zahlreicher Befehle aufzuzeichnen.
Gleitkomma-Steuerwort(FCW)-Register 835 und Gleitkomma-Statuswort(FSW)-Register 840 – in der dargestellten Ausführungsform werden diese Register von x87-Befehlssatzerweiterungen dazu genutzt, im Fall des FCW Rundungsmodi, Ausnahmemasken und Kennzeichen einzustellen und im Fall des FSW Ausnahmen zu verfolgen.
Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 845, der die MMX-gepackte Ganzzahl-Flachregisterdatei 850 per Alias zugeordnet ist – in der dargestellten Ausführungsform ist der x87-Stapel ein Acht-Elemente-Stapel, der verwendet wird, um unter Verwendung der x87-Befehlssatzerweiterung skalare Gleitkommaoperationen für 32/64/80-Bit-Gleitkommadaten durchzuführen; während die MMX-Register verwendet werden, um Operationen für 64-Bit-gepackte ganzzahlige Daten durchzuführen, sowie um Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
Segmentregister 855 – in der dargestellten Ausführungsform sind sechs 16-Bit-Register vorgesehen, die für die Generierung segmentierter Adressen verwendet werden.
RIP-Register 865 – in der dargestellten Ausführungsform speichert dieses 64-Bit-Register den Befehlszeiger.
Alternative Ausführungsformen der Erfindung können breitere oder schmalere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
Beispielhafte In-Order-Prozessorarchitektur – Abb. 9A–Abb. 9B
–B zeigen ein Blockschaltbild einer beispielhaften In-Order-Prozessorarchitektur. Diese beispielhaften Ausführungsformen sind rund um mehrere Instanziierungen eines In-Order-CPU-Kerns herum angelegt, der um einen Prozessor für breite Vektoren (VPU) erweitert ist. Die Kerne kommunizieren durch ein Verbindungsnetz mit großer Bandbreite mit fester Funktionslogik, Speicher-E/A-Schnittstellen und anderer erforderlicher E/A-Logik, je nach der e13t-Anwendung. Beispielsweise würde eine Implementierung dieser Ausführungsform als eigenständige GPU typischerweise einen PCIe-Bus umfassen.
ist ein Blockschaltbild eines einzelnen CPU-Kerns, zusammen mit dessen Verbindung zu dem On-die-Verbindungsnetz 902 und mit der zugehörigen lokalen Untermenge des Level-2(L2)-Caches 904 gemäß Ausführungsformen der Erfindung. Ein Befehlsdecodierer 900 unterstützt den x86-Befehlssatz mit einer Erweiterung, die das spezifische vektorfreundliche Befehlsformat 700 umfasst. Während in einer Ausführungsform der Erfindung (um das Design zu vereinfachen) eine Skalareinheit 908 und eine Vektoreinheit 910 getrennte Registersätze (Skalarregister 912 bzw. Vektorregister 914) verwenden und zwischen diesen übertragene Daten in den Speicher geschrieben und dann aus einem Level-1(L1)-Cache 906 erneut eingelesen werden, können alternative Ausführungsformen der Erfindung einen unterschiedlichen Ansatz verfolgen (z. B. das Verwenden eines einzelnen Registersatzes oder das Einschließen eines Kommunikationspfades, der es erlaubt, Daten ohne Schreiben und Zurücklesen zwischen den zwei Registerdateien zu übertragen).
Der L1-Cache 906 ermöglicht latenzarme Zugriffe auf den Cache-Speicher in die Skalareinheiten und die Vektoreinheiten. Zusammen mit Lade-op-Befehlen im vektorfreundlichen Befehlsformat bedeutet dies, dass der L1-Cache 906 in etwa wie eine erweiterte Registerdatei behandelt werden kann. Dies verbessert die Leistung vieler Algorithmen beträchtlich, insbesondere mit dem Räumungshinweisfeld 652B.
Die lokale Untermenge des L2-Caches 904 ist Teil eines globalen L2-Caches, der in getrennte lokale Untermengen unterteilt ist, eine pro CPU-Kern. Jeder CPU-Kern weist einen direkten Zugriffspfad zu seiner eigenen lokalen Untermenge des L2-Caches 904 auf. Von einem CPU-Kern gelesene Daten werden in dessen eigener Untermenge des L2-Caches 904 gespeichert, und es kann schnell darauf zugegriffen werden, was parallel zum Zugreifen anderer CPU-Kerne auf deren eigene Untermengen des lokalen L2-Caches erfolgen kann. Von einem CPU-Kern geschriebene Daten werden in dessen eigener Untermenge des L2-Caches 904 gespeichert und, falls erforderlich, aus anderen Untermengen gelöscht. Das Ringnetz stellt die Kohärenz für gemeinsam genutzte Daten sicher.
ist eine Explosionsansicht eines Teils des CPU-Kerns in gemäß Ausführungsformen der Erfindung. umfasst einen L1-Datencache 906A, Teil des L1-Caches 904, sowie mehr Einzelheiten hinsichtlich der Vektoreinheit 910 und der Vektorregister 914. Insbesondere ist die Vektoreinheit 910 eine Vektorverarbeitungseinheit (Vector Processing Unit, VPU) mit einer Breite von 16 (siehe die ALU 928 mit einer Breite von 16), die einen oder mehrere Befehle für Ganzzahlen, einfach genaue Gleitkommawerte und doppelt genaue Gleitkommawerte ausführt. Die VPU unterstützt das Swizzeln der Registereingaben mit Swizzle-Einheit 920, die numerische Umwandlung mit numerischen Umwandlungseinheiten 922A–B und die Replikation mit einer Replikationseinheit 924 am Speichereingang. Schreibmaskenregister 926 erlauben das Vorhersagen von resultierenden Vektorschreibvorgängen.
Registerdaten können auf vielfältige Weise geswizzelt werden, z. B. um eine Matrixmultiplikation zu unterstützen. Daten aus dem Speicher können über die VPU-Lanes repliziert werden. Dies ist eine verbreitete Operation sowohl in der grafischen als auch in der nichtgrafischen parallelen Datenverarbeitung, die die Cache-Effizienz beträchtlich erhöht.
Das Ringnetz ist bidirektional, um es Agenten wie CPU-Kernen, L2-Caches und anderen Logikblöcken zu ermöglichen, chipintern miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 812 Bits breit.
Beispielhafte Out-of-Order Architektur – Abb. 10
ist ein Blockschaltbild, das eine beispielhafte Out-of-Order-Architektur gemäß Ausführungsformen der Erfindung darstellt, und kann als eine spezifischere Beschreibung einer Pipeline wie etwa der vorstehend in erörterten Pipeline betrachtet werden. Speziell zeigt eine bekannte beispielhafte Out-of-Order-Architektur, die so modifiziert wurde, dass sie das vektorfreundliche Befehlsformat sowie dessen Ausführung beinhaltet. In weisen Pfeile auf eine Kopplung zwischen zwei oder mehr Einheiten hin, und die Pfeilrichtung zeigt in die Richtung, in der Daten zwischen den betreffenden Einheiten fließen. weist eine Frontend-Einheit 1005 auf, die an eine Ausführungsengine-Einheit 1010 und eine Speichereinheit 1015 gekoppelt ist; die Ausführungsengine-Einheit 1010 ist ferner an die Speichereinheit 1015 gekoppelt.
Die Frontend-Einheit 1005 umfasst eine Level-1(L1)-Sprungvorhersage-Einheit 1020, die an eine Level-2(L2)-Sprungvorhersage-Einheit 1022 gekoppelt ist. Die L1- und die L2-Sprungvorhersage-Einheit 1020 und 1022 sind an eine L1-Befehlscache-Einheit 1024 gekoppelt. Die L1-Befehlscache-Einheit 1024 ist an einen Übersetzungspuffer (TLB) für Befehle 1026 gekoppelt, der wiederum an eine Befehlsabruf- und Vordecodierungseinheit 1028 gekoppelt ist. Die Befehlsabruf- und Vordecodierungseinheit 1028 ist an eine Befehlsschlangeneinheit 1030 gekoppelt, die wiederum an eine Decodiereinheit 1032 gekoppelt ist. Die Decodiereinheit 1032 umfasst eine komplexe Decodiereinheit 1034 und drei einfache Decodiereinheiten 1036, 1038 und 1040. Die Decodiereinheit 1032 umfasst eine Mikrocode-ROM-Einheit 1042. Die Decodiereinheit 1032 kann wie vorstehend im Abschnitt zur Decodierstufe beschrieben arbeiten. Die L1-Befehlscache-Einheit 1024 ist ferner an eine L2-Cache-Einheit 1048 in der Speichereinheit 1015 gekoppelt. Die Befehls-TLB-Einheit 1026 ist ferner an eine Second-Level-TLB-Einheit 1046 in der Speichereinheit 1015 gekoppelt. Die Decodiereinheit 1032, die Mikrocode-ROM-Einheit 1042 und eine Schleifenstromdetektoreinheit 1044 sind jeweils an eine Umbenennungs-/Zuweisungseinheit 1056 in der Ausführungsengine-Einheit 1010 gekoppelt.
Die Ausführungsengine-Einheit 1010 umfasst die Umbenennungs-/Zuweisungseinheit 1056, die an eine Rückordnungseinheit 1074 und eine vereinheitlichte Planreinheit 1058 gekoppelt ist. Die Rückordnungseinheit 1074 ist wiederum an Ausführungseinheiten 1060 gekoppelt und umfasst eine Neuordnungspuffereinheit 1078. Die vereinheitlichte Planreinheit 1058 ist wiederum an eine physische Registerdatei-Einheit 1076 gekoppelt, die an die Ausführungseinheiten 1060 gekoppelt ist. Die physische Registerdatei-Einheit 1076 umfasst eine Vektorregistereinheit 1077A, eine Schreibmaskenregistereinheit 1077B und eine Skalarregistereinheit 1077C; diese Registereinheiten können die Vektorregister 810, die Vektormaskenregister 815 und die Universalregister 825 bereitstellen; und die physische Registerdatei-Einheit 1076 kann nicht dargestellte zusätzliche Registerdateien aufweisen (z. B. die skalare Gleitkomma-Stapelregisterdatei 845, der die MMX-gepackte Ganzzahl-Flachregisterdatei 850 per Alias zugeordnet ist). Die Ausführungseinheiten 1060 umfassen drei gemischte Skalar- und Vektoreinheiten 1062, 1064 und 1072; eine Ladeeinheit 1066; eine Speicheradresseneinheit 1068; eine Speicherdateneinheit 1070. Die Ladeeinheit 1066, die Speicheradresseneinheit 1068 und die Speicherdateneinheit 1070 sind jeweils wiederum an eine Daten-TLB-Einheit 1052 in der Speichereinheit 1015 gekoppelt.
Die Speichereinheit 1015 umfasst die Second-Level-TLB-Einheit 1046, die an die Daten-TLB-Einheit 1052 gekoppelt ist. Die Daten-TLB-Einheit 1052 ist an eine L1-Datencache-Einheit 1054 gekoppelt. Die L1-Datencache-Einheit 1054 ist wiederum an eine L2-Cache-Einheit 1048 gekoppelt. In einigen Ausführungsformen ist die L2-Cache-Einheit 1048 wiederum an L3-Cache-Einheiten und höher 1050 innerhalb und/oder außerhalb der Speichereinheit 1015 gekoppelt.
Beispielsweise kann die beispielhafte Out-of-Order-Architektur die Prozesspipeline 8200 wie folgt implementieren: 1) die Befehlsabruf- und Vordecodiereinheit 1028 führt die Abruf- und Längendecodierstufen durch; 2) die Decodiereinheit 1032 führt die Decodierstufe durch; 3) die Umbenennungs-/Zuweisungseinheit 1056 führt die Zuweisungsstufe und die Umbenennungsstufe durch; 4) der vereinheitlichte Planer 1058 führt die Planungsstufe durch; 5) die physische Registerdatei-Einheit 1076, die Neuordnungspuffereinheit 1078 und die Speichereinheit 1015 führen die Registerlese-/Speicherlesestufe durch; die Ausführungseinheiten 1060 führen die Ausführungs-/Datentransformationsstufe durch; 6) die Speichereinheit 1015 und die Neuordnungspuffereinheit 1078 führen die Rückkopier-/Speicherschreibstufe 1960 durch; 7) die Rückordnungseinheit 1074 führt die ROB-Lesestufe durch; 8) verschiedene Einheiten können in die Ausnahmebehandlungsstufe einbezogen sein; und die Rückordnungseinheit 1074 und die physische Registerdatei-Einheit 1076 führen die Übergabestufe durch.
Beispielhafte Einkern- und Mehrkernprozessoren – Abb. 15
ist ein Blockschaltbild eines Einzelkernprozessors und eines Mehrkernprozessors 1500 mit integrierter Speichersteuerung und Graphik gemäß Ausführungsformen der Erfindung. Die mit einer durchgehenden Linie gekennzeichneten Felder in zeigen einen Prozessor 1500 mit einem einzelnen Kern 1502A, einem Systemagenten 1510, einem Satz von einer oder mehreren Bussteuerungseinheit(en) 1516, während die optionale Ergänzung der mit einer gestrichelten Linie gekennzeichneten Felder einen alternativen Prozessor 1500 mit mehreren Kernen 1502A–N, einem Satz von einer oder mehreren integrierten Speichersteuerungseinheit(en) 1514 in der Systemagent-Einheit 1510 und einer integrierten Grafiklogik 1508 zeigt.
Die Speicherhierarchie weist in den Kernen eine oder mehrere Ebene(n) von Cache, einen Satz von oder eine oder mehrere gemeinsam genutzte(n) Cache-Einheit(en) 1506 und externen Speicher (nicht gezeigt), der an den Satz von integrierten Speichersteuerungseinheiten 1514 gekoppelt ist, auf. Der Satz von gemeinsam genutzten Cache-Einheiten 1506 kann einen oder mehrere Mid-Level-Caches, beispielsweise Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Level, einen Last-Level-Cache (LLC) und/oder Kombinationen davon aufweisen. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 1512 die integrierte Grafiklogik 1508, den Satz von gemeinsam genutzten Cache-Einheiten 1506 und die Systemagent-Einheit 1510 untereinander verbindet, können alternative Ausführungsformen eine beliebige Anzahl von bekannten Verfahren für das Verbinden solcher Einheiten verwenden.
In einigen Ausführungsformen ist/sind einer oder mehrere der Kerne 1502A–N Multithreading-fähig. Der Systemagent 1510 umfasst diejenigen Komponenten, welche die Kerne 1502A–N koordinieren und betreiben. Die Systemagent-Einheit 1510 kann beispielsweise eine Leistungssteuerungseinheit (Power Control Unit, PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann Logik und Komponenten darstellen oder umfassen, die für das Regeln des Leistungszustands der Kerne 1502A–N und der integrierten Grafiklogik 1508 benötigt werden. Die Anzeigeeinheit hat die Aufgabe, eine oder mehrere extern angeschlossene Anzeige(n) anzusteuern.
Die Kerne 1502A–N können in Bezug auf die Architektur und/oder den Befehlssatz homogen oder heterogen sein. Beispielsweise können einige der Kerne 1502A–N In-Order-Kerne sein (z. B. wie in und gezeigt), während andere Out-of-Order-Kerne sind (z. B. wie in gezeigt). Als weiteres Beispiel können zwei oder mehr der Kerne 1502A–N in der Lage sein, denselben Befehlssatz auszuführen, während andere in der Lage sein können, nur eine Untermenge dieses Befehlssatzes oder einen anderen Befehlssatz auszuführen. Wenigstens einer der Kerne ist in der Lage, das beschriebene vektorfreundliche Befehlsformat auszuführen.
Der Prozessor kann ein Universalprozessor sein, etwa ein Core^TM i3-, i5-, i7-, 2 Duo- und Quad-, Xeon^TM- oder Itanium^TM-Prozessor, wie sie von der Intel Corporation aus Santa Clara, Kalifornien, erhältlich sind. Alternativ kann der Prozessor von einem anderen Hersteller stammen. Der Prozessor kann ein Spezialprozessor sein, wie beispielsweise ein Netz- oder Kommunikationsprozessor, eine Kompressionsengine, ein Grafikprozessor, ein Coprozessor, ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 1500 kann Teil eines Substrats sein und/oder unter Verwendung einer Anzahl von Prozesstechnologien wie beispielsweise BiCMOS, CMOS oder NMOS auf einem oder mehreren Substraten implementiert sein.
Beispielhafte Computersysteme und Prozessoren – Abb. 11–Abb. 13
– sind beispielhafte Systeme, die geeignet sind, den Prozessor 1500 aufzuweisen, während ein beispielhaftes Ein-Chip-System (SoC) ist, das einen oder mehrere der Kerne 1502 aufweisen kann. Andere Systementwürfe und Konfigurationen nach dem Stand der Technik für Laptops, Desktops, Handheld-PCs, persönliche digitale Assistenten (PDAs), Arbeitsstationen (Engineering Workstations, EWS), Server, Netzvorrichtungen, Netzknoten, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienwiedergabegeräte, Handheld-Vorrichtungen und verschiedene andere elektronische Vorrichtungen, sind ebenfalls geeignet. Im Allgemeinen ist eine enorme Vielzahl von verschiedenen Systemen oder elektronischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder andere Ausführungslogik wie hier offenbart aufzunehmen, geeignet.
Es wird nun Bezug genommen auf ; gezeigt wird ein Blockschaltbild eines Systems 1100 gemäß einer Ausführungsform der Erfindung. Das System 1100 kann einen oder mehrere Prozessor(en) 1110, 1115 aufweisen, der/die an einen Grafikspeicher-Steuerungsknoten (Graphics Memory Controller Hub, GMCH) 1120 gekoppelt ist/sind. Der optionale Charakter zusätzlicher Prozessoren 1115 ist in durch die gestrichelten Linien angegeben.
Jeder Prozessor 1110, 1115 kann eine Version des Prozessors 1500 sein. Es ist jedoch zu beachten, dass es unwahrscheinlich ist, dass integrierte Grafiklogik und integrierte Speichersteuereinheiten in den Prozessoren 1110, 1115 enthalten sind.
zeigt, dass der GMCH 1120 an einen Speicher 1140 gekoppelt sein kann, bei dem es sich beispielsweise um einen dynamischen Direktzugriffsspeicher (DRAM) handeln kann. Der DRAM kann in wenigstens einer Ausführungsform einem nichtflüchtigen Cache zu geordnet sein.
Der GMCH 1120 kann ein Chipsatz oder ein Teil eines Chipsatzes sein. Der GMCH 1120 kann mit dem/den Prozessor(en) 1110, 1115 kommunizieren und das Zusammenwirken zwischen dem/den Prozessor(en) 1110, 1115 und dem Speicher 1140 steuern. Der GMCH 1120 kann außerdem als eine beschleunigte Busschnittstelle zwischen dem/den Prozessor(en) 1110, 1115 und anderen Elementen des Systems 1100 fungieren. In wenigstens einer Ausführungsform kommuniziert der GMCH 1120 mit dem/den Prozessor(en) 1110, 1115 über einen Multi-Drop-Bus, etwa einen Frontside-Bus (FSB) 1195.
Ferner ist der GMCH 1120 an eine Anzeige 1145 (etwa eine Flachbildschirmanzeige) gekoppelt. Der GMCH 1120 kann einen integrierten Grafikbeschleuniger aufweisen. Der GMCH 1120 ist ferner an einen Eingabe/Ausgabe-(E/A)Steuerungsknoten (ICH) 1150 gekoppelt, der dazu verwendet werden kann, diverse Peripherievorrichtungen mit dem System 1100 zu verbinden. In der Ausführungsform von beispielsweise ist eine externe Grafikvorrichtung 1160 dargestellt, die eine diskrete, an den ICH 1150 gekoppelte Grafikvorrichtung sein kann, zusammen mit einer weiteren Peripherievorrichtung 1170.
Alternativ können zusätzliche oder andere Prozessoren im System 1100 vorhanden sein. Beispielsweise können zusätzliche Prozessoren 1115 (einen) zusätzliche(n) Prozessor(en) umfassen, der/die identisch ist/sind mit Prozessor 1110, (einen) zusätzliche(n) Prozessor(en), der/die heterogen oder asymmetrisch zu Prozessor 1110 ist/sind, Beschleuniger (wie beispielsweise Grafikbeschleuniger oder digitale Signalverarbeitungs(DSP)-Einheiten), feldprogrammierbare Gate-Arrays oder einen beliebigen anderen Prozessor. Es kann verschiedene Unterschiede zwischen den physischen Ressourcen 1110, 1115 im Hinblick auf ein Spektrum von Gütemetriken geben, einschließlich architektonische, mikroarchitektonische, thermische, leistungsaufnahmebezogene Eigenschaften und dergleichen. Diese Unterschiede können sich in Asymmetrie und Heterogenität zwischen den Verarbeitungselementen 1110, 1115 bemerkbar machen. In wenigstens einer Ausführungsform können die verschiedenen Verarbeitungselemente 1110, 1115 in demselben Die-Paket enthalten sein.
Es wird nun Bezug genommen auf ; gezeigt wird ein zweites System 1200 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie in gezeigt, ist das Mehrprozessorsystem 1200 ein Punkt-zu-Punkt-Verbindungssystem und weist einen ersten Prozessor 1270 und einen zweiten Prozessor 1280 auf, die über eine Punkt-zu-Punkt-Verbindung 1250 gekoppelt sind. Wie in gezeigt, kann jeder der Prozessoren 1270 und 1280 eine Version des Prozessors 1500 sein.
Alternativ kann/können einer oder mehrere der Prozessoren 1270, 1280 ein anderes Element sein als ein Prozessor, etwa ein Beschleuniger oder ein feldprogrammierbares Gate-Array.
Auch wenn hier nur zwei Prozessoren 1270, 1280 dargestellt werden, ist einzusehen, dass der Schutzbereich der vorliegenden Erfindung nicht hierauf beschränkt ist. In anderen Ausführungsformen können ein oder mehrere zusätzliche Verarbeitungselemente in einem gegebenen Prozessor vorhanden sein.
Der Prozessor 1270 kann ferner einen integrierten Speichersteuerungsknoten (IMC) 1272 und Punkt-zu-Punkt(P-P)-Schnittstellen 1276 und 1278 aufweisen. In ähnlicher Weise kann der zweite Prozessor 1280 einen IMC 1282 und P-P-Schnittstellen 1286 und 1288 aufweisen. Die Prozessoren 1270, 1280 können Informationen über eine Punkt-zu-Punkt(PtP)-Schnittstelle 1250 unter Verwendung von PtP-Schnittstellenschaltungen 1286, 1288 austauschen. Wie in gezeigt, koppeln die IMCs 1272 und 1282 die Prozessoren an die jeweiligen Speicher, nämlich einen Speicher 1242 und einen Speicher 1244, die Teile des lokal mit den jeweiligen Prozessoren verbundenen Hauptspeichers sein können.
Die Prozessoren 1270, 1280 können jeder über individuelle P-P-Schnittstellen 1252, 1254 Daten mit einem Chipsatz 1290 austauschen, wobei Punkt-zu-Punkt-Schnittstellenschaltungen 1276, 1294, 1286, 1298 verwendet werden. Der Chipsatz 1290 kann auch über eine Hochleistungs-Grafikschnittstelle 1239 Daten mit einer Hochleistungs-Grafikschaltung 1238 austauschen.
Ein gemeinsam genutzter (nicht gezeigter) Cache kann in jedem Prozessor außerhalb beider Prozessoren enthalten sein, dabei aber mit den Prozessoren über eine P-P-Verbindung verbunden sein, so dass lokale Cache-Informationen jedes oder beider Prozessoren im gemeinsam genutzten Cache gespeichert werden können, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird.
Der Chipsatz 1290 kann über eine Schnittstelle 1296 an einen ersten Bus 1216 gekoppelt sein. In einer Ausführungsform kann der erste Bus 1216 ein Peripheriegeräteverbindungsbus (Peripheral Component Interconnect, PCI) oder ein Bus wie beispielsweise ein PCI Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein, wenngleich der Schutzbereich der vorliegenden Erfindung nicht hierauf beschränkt ist.
Wie in gezeigt, können verschiedene E/A-Vorrichtungen 1214 an den ersten Bus 1216 gekoppelt sein, zusammen mit einer Busbrücke 1218, die den ersten Bus 1216 an einen zweiten Bus 1220 koppelt. In einer Ausführungsform kann der zweite Bus 1220 ein Bus mit geringer Stiftzahl (Low Pin Count, LPC) sein. In einer Ausführungsform können verschiedene Vorrichtungen an einen zweiten Bus 1220 gekoppelt sein, beispielsweise eine Tastatur/Maus 1222, Kommunikationsvorrichtungen 1226 und eine Datenspeichereinheit 1228 wie beispielsweise ein Plattenlaufwerk oder eine Massenspeichervorrichtung, die Code 1230 aufweisen kann. Ferner kann ein Audio-E/A 1224 an den zweiten Bus 1220 gekoppelt sein. Es sei darauf hingewiesen, dass auch andere Architekturen möglich sind. So kann ein System beispielsweise anstelle der Punkt-zu-Punkt-Architektur aus einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.
Es wird nun Bezug genommen auf ; gezeigt wird ein Blockschaltbild eines dritten Systems 1300 gemäß einer Ausführungsform der vorliegenden Erfindung. Gleiche Elemente in und tragen gleiche Bezugsnummern, und bestimmte Aspekte von wurden in ausgelassen, um zu verhindern, dass andere Aspekte von verdeckt werden.
veranschaulicht, dass die Verarbeitungselemente 1270, 1280 einen integrierten Speicher und eine E/A-Steuerungslogik (Control Logic, „CL”) 1272 bzw. 1282 aufweisen können. In wenigstens einer Ausführungsform kann die CL 1272, 1282 Speichersteuerungsknotenlogik (IMC) umfassen, wie sie vorstehend im Zusammenhang mit und beschrieben wurde. Darüber hinaus können CL 1272, 1282 auch E/A-Steuerungslogik aufweisen. veranschaulicht, dass nicht nur die Speicher 1242, 1244 an die CL 1272, 1282 gekoppelt sind, sondern auch, dass die E/A-Vorrichtungen 1314 auch an die Steuerungslogik 1272, 1282 gekoppelt sind. Bisherige E/A-Vorrichtungen 1315 sind an den Chipsatz 1290 gekoppelt.
Es wird nun Bezug genommen auf ; gezeigt wird ein Blockdiagramm eines SoC 1400 gemäß einer Ausführungsform der vorliegenden Erfindung. Ähnliche Elemente in tragen ähnliche Referenznummern. Außerdem stehen mit einer gestrichelten Linie gekennzeichnete Felder für optionale Merkmale auf fortschrittlicheren SoCs. In ist (sind) (eine) Verbindungseinheit(en) 1402 gekoppelt an: einen Anwendungsprozessor 1410, der einen Satz von einem oder mehreren Kern(en) 1502A–N und eine (mehrere) gemeinsam genutzte(n) Cache-Einheit(en) 1506 aufweist; eine Systemagent-Einheit 1510; (eine) Bussteuerungseinheit(en) 1516; (eine) integrierte Speichersteuerungseinheit(en) 1514; einen Satz oder einen oder mehrere Coprozessor(en) 1420, der integrierte Grafiklogik 1508 aufweisen kann, einen Bildprozessor 1424 zum Bereitstellen einer Standbild- und/oder Videokamerafunktionalität, einen Audioprozessor 1426 zum Bereitstellen einer Hardware-Audiobeschleunigung und einen Videoprozessor 1428 zum Bereitstellen einer Videocodier-/-decodierbeschleunigung; eine statische Direktzugriffsspeichereinheit (Static Random Access Memory, SRAM) 1430; eine Direktspeicherzugriffseinheit (Direct Memory Access, DMA) 1432; und eine Anzeigeeinheit 1440 für das Ankoppeln an eine oder mehrere externe Anzeige(n).
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware implementiert sein oder eine Kombination dieser Implementierungsansätze darstellen. Ausführungsformen der Erfindung können als Computerprogramme oder als Programmcode implementiert sein, die/der auf programmierbaren Systemen ausgeführt werden/wird, die wenigstens einen Prozessor, ein Speichersystem (mit flüchtigem und nichtflüchtigem Speicher und/oder Speicherelementen), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
Programmcode kann auf Eingabedaten angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen angewendet werden. Für die Zwecke der Erfindung umfasst ein Verarbeitungssystem ein beliebiges System, das über einen Prozessor verfügt, beispielsweise: einen digitalen Signalprozessor (Digital Signal Processor, DSP), eine Mikrosteuerung, eine anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit, ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer prozeduralen Hochsprache oder in einer objektorientierten Programmiersprache für das Kommunizieren mit einem Verarbeitungssystem implementiert sein. Der Programmcode kann auf Wunsch auch in Assembler- oder Maschinensprache implementiert sein. Tatsächlich sind die hier beschriebenen Mechanismen hinsichtlich des Schutzbereichs nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann es sich bei der Sprache um eine kompilierte oder eine interpretierte Sprache handeln.
Ein oder mehrere Aspekt(e) von wenigstens einer Ausführungsform kann (können) durch repräsentative Befehle implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logiken im Prozessor repräsentiert, welche beim Auslesen durch eine Maschine bewirken, dass die Maschine Logik für das Durchführen der hier beschriebenen Verfahren erstellt. Solche Darstellungen, „IP-Kerne” genannt, können auf einem physischen, maschinenlesbaren Medium gespeichert werden und an verschiedene Kunden oder Fertigungseinrichtungen geliefert werden, damit sie dort in die Fertigungsmaschinen geladen werden, die tatsächlich die Logik oder den Prozessor ausmachen.
Ein solches maschinenlesbares Medium kann, ohne Einschränkung, nichtflüchtige, physische Anordnungen von Artikeln umfassen, die von einer Maschine oder einer Vorrichtung gefertigt oder geformt werden, einschließlich Speichermedien wie beispielsweise Festplatten, irgendeine andere Art von Platte einschließlich Floppy-Disketten, optische Platten, Kompakt-Disk-Festwertspeicher (Compact Disk Read-only Memories, CD-ROMs), wiederbeschreibbare Kompakt-Disks (Compact Disk Rewritables, CD-RWs) und magnetooptische Platten, Halbleitervorrichtungen wie beispielsweise Festwertspeicher (Read-only Memories, ROMs), Direktzugriffsspeicher (Random Access Memories, RAMs) wie beispielsweise dynamische Direktzugriffsspeicher (Dynamic Random Access Memories, DRAMs), statische Direktzugriffsspeicher (Static Random Access Memories, SRAMs), löschbare programmierbare Festwertspeicher (Erasable Programmable Read-only Memories, EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Festwertspeicher (Electrically Erasable Programmable Read-only Memories, EEPROMs), magnetische oder optische Karten oder irgendeine andere Art von Medien, die sich für das Speichern elektronischer Befehle eignen.
Entsprechend umfassen Ausführungsformen der Erfindung auch nichtflüchtige, physische maschinenlesbare Medien, die Befehle im vektorfreundlichen Befehlsformat oder Entwurfsdaten enthalten, beispielsweise eine Hardware-Beschreibungssprache (Hardware Description Language, HDL), welche die hier beschriebenen Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
In einigen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. So kann der Befehlsumwandler einen Befehl für das Verarbeiten durch den Kern in einen oder mehrere andere(n) Befehl(e) übersetzen (z. B. unter Verwendung einer statischen binären Übersetzung, einer dynamischen binären Übersetzung einschließlich einer dynamischen Kompilierung), umformen, emulieren oder sonstwie umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Bei dem Befehlsumwandler kann es sich um einen On-Prozessor, einen Off-Prozessor oder teilweise um einen On- und teilweise um einen Off-Prozessor handeln.
ist ein Blockschaltbild, das die Verwendung eines Software-Befehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt. In der dargestellten Ausführungsform ist der Befehlsumwandler ein Software-Befehlsumwandler, wenngleich der Befehlsumwandler alternativ auch in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert sein kann. zeigt, dass ein Programm in einer Hochsprache 1602 unter Verwendung eines x86-Kompilierers 1604 kompiliert werden kann, um x86-Binärcode 1606 zu erzeugen, der nativ von einem Prozessor mit wenigstens einem x86-Befehlssatzkern 1616 ausgeführt werden kann (es wird angenommen, dass einige der kompilierten Befehle im vektorfreundlichen Befehlsformat vorliegen). Der Prozessor mit wenigstens einem x86-Befehlssatzkern 1616 repräsentiert jeden Prozessor, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern durchführen kann, indem dieser Prozessor in kompatibler Weise oder sonstwie (1) einen wesentlichen Teil des Befehlssatzes des Intel x86-Befehlssatzkerns verarbeitet oder (2) Objektcode-Versionen von Anwendungen oder andere Software, die für das Ausführen auf einem Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern vorgesehen ist, ausführt, um im Wesentlichen dasselbe Ergebnis zu erzielen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern. Der x86-Kompilierer 1604 repräsentiert einen Kompilierer, der betrieben werden kann, um x86-Binärcode 1606 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Verknüpfungsverarbeitung auf dem Prozessor mit wenigstens einem x86-Befehlssatzkern 1616 ausgeführt werden kann. In ähnlicher Weise zeigt , dass das Programm in der Hochsprache 1602 unter Verwendung eines alternativen Befehlssatz-Kompilierers 1608 kompiliert werden kann, um alternativen Befehlssatz-Binärcode 1610 zu erzeugen, der von einem Prozessor ohne wenigstens einen x86-Befehlssatzkern 1614 nativ ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, Kalifornien, ausführen und/oder den ARM-Befehlssatz von ARM Holdings aus Sunnyvale, Kalifornien, ausführen). Der Befehlsumwandler 1612 wird verwendet, um den x86-Binärcode 1606 in Code umzuwandeln, der vom Prozessor ohne einen x86-Befehlssatzkern 1614 nativ ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht identisch mit dem alternativen Befehlssatz-Binärcode 1610, weil ein Befehlsumwandler, der hierzu in der Lage wäre, schwer herzustellen ist; allerdings wird der umgewandelte Code den allgemeinen Betrieb bewältigen und sich aus Befehlen aus dem alternativen Befehlssatz zusammensetzen. Somit repräsentiert der Befehlsumwandler 1612 Software, Firmware, Hardware oder eine Kombination davon, die es, durch Emulation, Simulation oder einen anderen Prozess, einem Prozessor oder einer anderen elektronischen Vorrichtung, der bzw. die keinen x86-Befehlssatzprozessor oder -kern aufweist, ermöglicht, den x86-Binärcode 1606 auszuführen.
Gewisse Operationen des Befehls/der Befehle im vektorfreundlichen Befehlsformat wie hierin offenbart können von Hardwarekomponenten durchgeführt werden und können als von einer Maschine ausführbare Befehle ausgeführt sein, die bewirken oder zumindest dazu führen, dass eine mit den Befehlen programmierte Schaltung oder sonstige Hardwarekomponente die Operationen durchführt. Die Schaltung kann eine(n) Universal- oder Spezialprozessor oder Logikschaltung umfassen, um nur einige Beispiele zu nennen. Die Operationen können außerdem wahlweise durch eine Kombination aus Hardware und Software durchgeführt werden. Ausführungslogik und/oder ein Prozessor kann/können spezifische oder besondere Schaltungen oder sonstige Logik umfassen, die auf einen Maschinenbefehl oder ein oder mehrere Steuersignal(e), die aus dem Maschinenbefehl abgeleitet sind, reagieren, um einen von dem Befehl spezifizierten Ergebnisoperanden zu speichern. Beispielsweise können Ausführungsformen des/der hier offenbarten Befehls/Befehle in einem oder mehreren der Systeme der – ausgeführt werden, und Ausführungsformen des Befehls/der Befehle im vektorfreundlichen Format können in dem in den Systemen auszuführenden Programmcode gespeichert sein. Zusätzlich können die Verarbeitungselemente dieser Abbildungen eine der hierin ausführlich beschriebenen Pipelines und/oder Architekturen nutzen (z. B. die In-Order- und Out-of-Order-Architekturen). Beispielsweise kann die Decodiereinheit der In-Order-Architektur den/die Befehl(e) decodieren, den decodierten Befehl an eine Vektor- oder Skalareinheit weitergeben etc.
Die vorstehende Beschreibung soll bevorzugte Ausführungsformen der vorliegenden Erfindung veranschaulichen. Anhand der vorstehenden Erörterungen sollte auch klar sein, dass speziell auf einem Gebiet der Technik, das ein schnelles Wachstum verzeichnet und auf dem Weiterentwicklungen nicht leicht vorherzusehen sind, die Erfindung hinsichtlich Anordnung und Details durch Fachleute auf diesem Gebiet modifiziert werden kann, ohne von den Grundsätzen der Erfindung abzuweichen, die in den Schutzbereich der beigefügten Patentansprüche und ihrer Äquivalente fallen. Beispielsweise können eine oder mehrere Operationen eines Verfahrens kombiniert oder weiter untergliedert werden.
Alternative Ausführungsformen
Auch wenn Ausführungsformen beschrieben wurden, die das vektorfreundliche Befehlsformat nativ ausführen, können alternative Ausführungsformen der Erfindung das vektorfreundliche Befehlsformat durch eine Emulationsschicht ausführen, die auf einem Prozessor läuft, welcher einen anderen Befehlssatz ausführt (z. B. ein Prozessor, der den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, Kalifornien, ausführt, ein Prozessor, der den ARM-Befehlssatz von ARM Holdings aus Sunnyvale, Kalifornien, ausführt). Außerdem versteht es sich, auch wenn die Flussdiagramme in den Abbildungen eine bestimmte Reihenfolge zeigen, in der Operationen durch gewisse Ausführungsformen der Erfindung ausgeführt werden, dass eine derartige Reihenfolge beispielhafter Natur ist (z. B. können alternative Ausführungsformen wahlweise die Operationen in unterschiedlicher Reihenfolge ausführen, bestimmte Operationen kombinieren, bestimmte Operationen überlappen lassen etc.).
In dieser gesamten ausführlichen Beschreibung wurden zu Erläuterungszwecken zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu bieten. Es wird jedoch einem Fachmann klar sein, dass eine oder mehrere andere Ausführungsform(en) ohne manche dieser spezifischen Einzelheiten ausgeführt werden kann können. Die beschriebenen speziellen Ausführungsformen werden nicht in der Absicht bereitgestellt, die Erfindung einzuschränken, sondern sollen Ausführungsformen der Erfindung veranschaulichen. Der Schutzbereich der Erfindung ist nicht anhand der vorstehenden spezifischen Beispiele, sondern ausschließlich anhand der nachstehenden Patentansprüche zu bestimmen.

Claims

Prozessor, umfassend: eine Befehlsausführungspipeline, umfassend: eine Befehlsabrufstufe zum Abrufen eines Befehls, wobei ein Befehlsformat des Befehls einen ersten Eingangsvektor, einen zweiten Eingangsvektor und einen dritten Eingangsoperanden spezifiziert; eine Befehlsdecodierstufe zum Dekodieren des Befehls; und eine Funktionseinheit zum Ausführen des Befehls, wobei die Funktionseinheit ein Routingnetz umfasst, um eine erste zusammenhängende Elementgruppe von einem ersten Ende eines der Eingangsvektoren an ein zweites Ende des resultierenden Vektors des Befehls zu leiten, und eine zweite zusammenhängende Elementgruppe von einem zweiten Ende des anderen der Eingangsvektoren an ein erstes Ende des resultierenden Vektors des Befehls zu leiten, wobei das erste und das zweite Ende einander gegenüberliegende Vektorenden sind, wobei die erste und die zweite zusammenhängende Elementgruppe anhand des dritten Eingangsoperanden definiert werden, wobei der Befehl nicht in der Lage ist, nicht zusammenhängende Elementgruppen aus den Eingangsvektoren in den resultierenden Vektor des Befehls zu leiten.
Prozessor nach Anspruch 1, wobei der dritte Eingangsoperand als Skalar spezifiziert ist.
Prozessor nach Anspruch 1, wobei der dritte Eingangsoperand mit einem Maskenvektor ausgeführt ist.
Prozessor nach einem der Ansprüche 1 bis 3, wobei das erste Ende ein linkes Ende und das zweite Ende ein rechtes Ende ist.
Prozessor nach einem der Ansprüche 1 bis 3, wobei das erste Ende ein rechtes Ende und das zweite Ende ein linkes Ende ist.
Prozessor nach einem der vorhergehenden Ansprüche, wobei die Befehlsausführungspipeline eine zweite Funktionseinheit zum Ausführen eines zweiten Befehls umfasst, wobei die zweite Funktionseinheit ein Routingnetz umfasst, um eine erste zusammenhängende Elementgruppe vom zweiten Ende eines ersten Eingangsvektors an ein erstes Ende des resultierenden Vektors des Befehls zu leiten, und eine zweite zusammenhängende Elementgruppe vom ersten Ende eines zweiten Eingangsvektors an das zweite Ende des resultierenden Vektors des zweiten Befehls zu leiten, wobei die erste und die zweite zusammenhängende Elementgruppe anhand eines dritten Eingangsoperanden des zweiten Befehls definiert wird.
Prozessor nach Anspruch 6, wobei die Funktionseinheit und die zweite Funktionseinheit ein und dieselbe Funktionseinheit sind.
Maschinenlesbares Medium, das darin gespeicherten Programmcode enthält, welcher, wenn er von einem Datenverarbeitungssystem ausgeführt wird, die Ausführung eines Verfahrens durch einen Kompilierer bewirkt, wobei das Verfahren umfasst: Erkennen der Verarbeitung eines Arrays mit fehlausgerichteten Zeilen; und Kompilieren der Verarbeitung des Arrays zu einer Software-Pipelineschleifen-Programmcodesequenz mit einem Befehl, dessen Befehlsformat einen ersten Eingangsvektor, einen zweiten Eingangsvektor und einen dritten Eingangsoperanden spezifiziert, wobei der Befehl eine erste zusammenhängende Elementgruppe von einem ersten Ende eines der Eingangsvektoren an ein zweites Ende des resultierenden Vektors des Befehls leitet und eine zweite zusammenhängende Elementgruppe von einem zweiten Ende des anderen der Eingangsvektoren an ein erstes Ende des resultierenden Vektors des Befehls leitet, wobei das erste und das zweite Ende einander gegenüberliegende Vektorenden sind, wobei die erste und die zweite zusammenhängende Elementgruppe anhand des dritten Eingangsoperanden definiert werden, und der Befehl nicht in der Lage ist, nicht zusammenhängende Elementgruppen aus den Eingangsvektoren in den resultierenden Vektor des Befehls zu leiten.
Maschinenlesbares Medium nach Anspruch 8, wobei Peeling bei der Formulierung der Programmcodesequenz nicht verwendet wird.
Maschinenlesbares Medium nach Anspruch 8 oder 9, wobei der resultierende Vektor des Befehls eine ausgerichtete Zeile des Arrays ist.
Maschinenlesbares Medium nach einem der Ansprüche 8 bis 10, wobei die Programmcodesequenz Code zum Verarbeiten der ausgerichteten Zeile beinhaltet.
Maschinenlesbares Medium nach einem der Ansprüche 8 bis 11, wobei der resultierende Vektor des Befehls Abschnitte von zwei verschiedenen Zeilen des Arrays beinhaltet.
Maschinenlesbares Medium nach einem der Ansprüche 8 bis 12, wobei die Software-Pipelineschleife auf zyklusweiser Basis als Eingang einen nächsten Vektor akzeptiert, der einen Anfangsabschnitt einer dritten Zeile und einen Endabschnitt der zweiten Zeile in einem Array aufweist, und wobei der Befehl den nächsten Vektor und den Eingangsvektor eines vorangegangenen Zyklus als den ersten und den zweiten Eingangsvektor akzeptiert, wobei der Vektor des vorangegangenen Zyklus einen Anfangsabschnitt des zweiten Vektors und einen Endabschnitt einer ersten Zeile des Arrays aufweist.
Maschinenlesbares Medium nach Anspruch 13, wobei Speicherzugriffe auf die Zeilen nicht an den Zeilengrenzen ausgerichtet sind.
Maschinenlesbares Medium nach einem der Ansprüche 8 bis 12, wobei die Software-Pipelineschleife auf zyklusweiser Basis einen nächsten Ausgangsvektor mit einem Endabschnitt einer ersten Zeile und einem Anfangsabschnitt einer zweiten Zeile schreibt, wobei der Befehl als den ersten und den zweiten Eingangsvektor Ergebnisse der an der ersten und der zweiten Zeile durchgeführten Verarbeitung akzeptiert.
Maschinenlesbares Medium nach Anspruch 15, wobei Speicherzugriffe auf die Zeilen nicht an den Zeilengrenzen ausgerichtet sind.
Datenverarbeitungssystem, umfassend: einen Systemspeicher; und einen an den Systemspeicher gekoppelten Prozessor, wobei der Prozessor eine Befehlsausführungspipeline umfasst, die umfasst: eine Befehlsabrufstufe zum Abrufen eines Befehls, wobei ein Befehlsformat des Befehls einen ersten Eingangsvektor, einen zweiten Eingangsvektor und einen dritten Eingangsoperanden spezifiziert; eine Befehlsdecodierstufe zum Dekodieren des Befehls; und eine Funktionseinheit zum Ausführen des Befehls, wobei die Funktionseinheit ein Routingnetz umfasst, um eine erste zusammenhängende Elementgruppe von einem ersten Ende eines der Eingangsvektoren an ein zweites Ende des resultierenden Vektors des Befehls zu leiten, und eine zweite zusammenhängende Elementgruppe von einem zweiten Ende des anderen der Eingangsvektoren an ein erstes Ende des resultierenden Vektors des Befehls zu leiten, wobei das erste und das zweite Ende einander gegenüberliegende Vektorenden sind, wobei die erste und die zweite zusammenhängende Elementgruppe anhand des dritten Eingangsoperanden definiert werden, wobei der Befehl nicht in der Lage ist, nicht zusammenhängende Elementgruppen aus den Eingangsvektoren in den resultierenden Vektor des Befehls zu leiten.
Datenverarbeitungssystem nach Anspruch 17, wobei der dritte Eingangsoperand als Skalar spezifiziert ist.
Datenverarbeitungssystem nach Anspruch 17, wobei der dritte Eingangsoperand mit einem Maskenvektor ausgeführt ist.
Datenverarbeitungssystem nach einem der Ansprüche 17 bis 19, wobei das erste Ende ein linkes Ende und das zweite Ende ein rechtes Ende ist.
Datenverarbeitungssystem nach einem der Ansprüche 17 bis 19, wobei das erste Ende ein rechtes Ende und das zweite Ende ein linkes Ende ist.
Datenverarbeitungssystem nach einem der Ansprüche 17 bis 21, wobei der Systemspeicher kompilierten Code enthält, um ein Array mit fehlausgerichteten Datenzeilen zu verarbeiten, wobei ausgerichtete Zugriffe auf den Systemspeicher erfolgen, um die Daten des Arrays zu verarbeiten.