DE112013005372T5

DE112013005372T5 - Befehl zum Bestimmen von Histogrammen

Info

Publication number: DE112013005372T5
Application number: DE112013005372.1T
Authority: DE
Inventors: Shih Shigjong KUO
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-12-28
Filing date: 2013-06-14
Publication date: 2015-07-23
Also published as: CN116954720A; US9804839B2; US20180067741A1; WO2014105126A9; US10416998B2; US20190065185A1; KR101794802B1; US20140189320A1; US10908907B2; KR20190006601A; KR101938290B1; US20190095210A1; KR20170125130A; CN108958799A; CN104823156A; KR20150102967A; WO2014105126A1; CN108958799B; US10908908B2; CN104823156B

Abstract

Es ist ein Prozessor mit einer Funktionseinheit einer Befehlsausführungs-Pipeline beschrieben worden. Die Funktionseinheit weist eine Vergleichsbank-Schaltungsanordnung und eine Addierer-Schaltungsanordnung auf. Die Vergleichsbank-Schaltungsanordnung dient zum Vergleichen eines oder mehrerer Elemente eines ersten Eingangsvektors mit einem Element eines zweiten Eingangsvektors. Die Addierer-Schaltungsanordnung ist mit der Vergleichsbank-Schaltungsanordnung gekoppelt, um die Anzahl von Elementen des zweiten Eingangsvektors, die mit dem ersten Eingangsvektor übereinstimmen, auf einer Element-für-Element-Basis des ersten Eingangsvektors zu addieren.

Description

Gebiet der Erfindung
Das Gebiet der Erfindung betrifft generell Rechnersysteme und insbesondere einen Befehl zum Bestimmen von Histogrammen.
Hintergrund
1 zeigt ein High-Level-Diagramm eines Verarbeitungskerns 100, der mit einer logischen Schaltungsanordnung auf einem Halbleiterchip implementiert ist. Der Verarbeitungskern weist eine Pipeline 101 auf. Die Pipeline ist aus mehreren Stufen gebildet, die jeweils so ausgelegt sind, dass sie einen spezifischen Schritt in dem Multischrittprozess durchführen, der erforderlich ist, um einen Programmcodebefehl vollständig auszuführen. Diese umfassen typsicherweise mindestens: 1) Befehlsabruf und -dekodierung; 2) Datenabruf; 3) Ausführung; 4) Zurückschreiben. Bei der Ausführungsstufe wird eine spezifische Operation durchgeführt, die von einem Befehl identifiziert wird, der aus (einer) vorhergehenden Stufe(n) (z. B. in Schritt 1) oben) abgerufen und dekodiert worden ist, und zwar anhand von Daten, die von demselben Befehl identifiziert und in einer anderen vorhergehenden Stufe abgerufen worden sind (z. B. Schritt 2) oben). Die Daten, anhand derer gearbeitet wird, werden typischerweise aus einem (Universal-)Registerspeicherplatz 102 abgerufen. Neue Daten, die bei Beendigung der Operation erstellt werden, werden typsicherweise ebenfalls in den Registerspeicherplatz ”zurückgeschrieben” (z. B. bei Schritt 4) oben).
Die logische Schaltungsanordnung, die der Ausführungsstufe zugehörig ist, ist typischerweise aus mehreren ”Ausführungseinheiten” oder ”Funktionseinheiten” 103_1 bis 103_N gebildet, die jeweils so ausgelegt sind, dass sie ihren eigenen einzigartigen Teilsatz an Operationen durchführen (z. B. führt eine erste Funktionseinheit mathematische Ganzzahlenoperationen durch, führt eine zweite Funktionseinheit Gleitkommabefehle aus, führt eine dritte Funktionseinheit Lade-/Speicheroperationen aus einem/in einen Cache/Speicher durch etc.). Die Zusammenfassung sämtlicher dieser Operationen, die von sämtlichen der Funktionseinheiten durchgeführt werden, entspricht dem ”Befehlssatz”, der von dem Verarbeitungskern 100 unterstützt wird.
Zwei Typen von Prozessorarchitekturen sind auf dem Gebiet der Computerwissenschaft weithin anerkannt: ”Skalar” und ”Vektor”. Ein Skalarprozessor ist so ausgelegt, dass er Befehle ausführt, mittels derer Operationen anhand eines einzelnen Satzes von Daten durchgeführt werden, während ein Vektorprozessor so ausgelegt ist, dass er Befehle ausführt, mittels derer Operationen anhand von mehreren Sätzen von Daten durchgeführt werden. 2A und 2B präsentieren ein Vergleichsbeispiel, das den grundlegenden Unterschied zwischen einem Skalarprozessor und einem Vektorprozessor aufzeigt.
2A zeigt ein Beispiel eines Skalar-UND-Befehls, bei dem ein einzelner Operandensatz A und B durch UND miteinander verkntüpft sind, um ein singuläres (oder ”skalares”) Ergebnis C (d. h. AB = C) zu produzieren. Im Gegensatz dazu zeigt 2B ein Beispiel eines Vektor-UND-Befehls, bei dem zwei Operandensätze A/B und D/E jeweils durch UND miteinander verknüpft sind, um ein Vektorergebnis C, F (d. h. A.UND.B = C und D.UND.E = F) zu produzieren. Terminologisch ist ein ”Vektor” ein Datenelement mit mehreren ”Elementen”. Zum Beispiel weist ein Vektor V = Q, R, S, T, U fünf unterschiedliche Elemente auf: Q, R, ST und U. Die ”Größe” des beispielhaften Vektors V ist fünf (da er fünf Elemente aufweist).
1 zeigt ferner das Vorhandensein eines Vektorregisterplatzes 104, der sich von dem Universalregisterplatz 102 unterscheidet. Insbesondere wird der Universalregisterplatz 102 nominell verwendet, um Skalarwerte zu speichern. Somit verwenden sie dann, wenn eine der Ausführungseinheiten Skalaroperationen durchführt, nominell Operanden, die aus dem Universalregisterplatz 102 abgerufen werden (und Ergebnisse werden in dieses zurückgeschrieben). Im Gegensatz dazu verwenden sie dann, wenn eine der Ausführungseinheiten Vektoroperationen durchführt, nominell Operanden, die aus dem Vektorregisterplatz 107 abgerufen werden (und Ergebnisse werden in diesen zurückgeschrieben). Verschiedene Regionen eines Speichers können gleichermaßen zur Speicherung von Skalarwerten und Vektorwerten zugeordnet werden.
Es sei ferner auf das Vorhandensein einer Maskierlogik 104_1 bis 104_N und 105_1 bis 105_N an den jeweiligen Eingängen in die und Ausgängen aus dem Funktionseinheiten 103_1 bis 103_N hingewiesen. Bei verschiedenen Implementierungen ist nur eine dieser Schichten tatsächlich implementiert – obwohl dies kein striktes Erfordernis ist. Für jeden Befehl, bei dem eine Maskierung verwendet wird, können eine Eingangs-Maskierlogik 104_1 bis 104_N und/oder eine Ausgangs-Maskierlogik 105_1 bis 105_N verwendet werden, um zu steuern, an welchen Elementen für den Vektorbefehl effektiv gearbeitet wird. Hier wird ein Maskenvektor aus einem Maskenregisterplatz 106 gelesen (z. B. zusammen mit Eingangsdatenvektoren, die aus dem Vektorregisterplatz 107 gelesen werden) und mindestens einer der Maskierlogik- 104, 105 Schichten präsentiert.
Im Verlauf der Ausführung eines Vektorprogrammcodes braucht nicht jeder Vektorbefehl ein vollständiges Datenwort zu benötigen. Zum Beispiel können die Eingangsvektoren für einige Befehle nur 8 Elemente aufweisen, können die Eingangsvektoren für weitere Befehle 16 Elemente aufweisen, können die Eingangsvektoren für weitere Befehle 32 Elemente aufweisen etc. Die Maskierschichten 104/105 werden daher zum Identifizieren eines Satzes von Elementen eines vollständigen Vektordatenworts verwendet, das für einen besonderen Befehl gilt, um unterschiedliche Vektorgrößen über Befehle zu realisieren. Typischerweise wird für jeden Vektorbefehl ein spezifisches Maskenmuster, das in dem Maskenregisterplatz 106 gehalten wird, durch den Befehl aufgerufen, aus dem Maskenregisterplatz abgerufen und zu einer oder beiden Maskenschichten 104/105 geliefert, um den korrekten Satz von Elementen für die besondere Vektoroperation zu ”aktivieren”.
Ein aktuell verfügbarer Vektorbefehl PCMPxESTy ist in der Lage, verschiedene Vergleichs-”Aggregations-”Funktionen für die Elemente eines ersten Eingangsvektors gegenüber den Elementen eines anderen Eingangsvektors durchzuführen. Die Ausgangsresultierende des PCMPxESTy-Befehls ist ein Maskenvektor, der das Ergebnis der von dem Befehl durchgeführten Vergleiche anzeigt. Die besondere Aggregationsfunktion, die von einem besonderen PCMPxESTy-Befehl durchzuführen ist, wird von dem Wert eines Direktwertoperanden innerhalb des PCMPxESTy-Befehl-Formats spezifiziert. Die unterstützten Aggregationsfunktionen umfassen ”Gleich jeder”, ”Gleich beliebiger”, ”Bereiche” und ”Gleich geordnet” und werden nachstehend beschrieben. Obwohl die PCMPxESTy-Befehle in der Lage sind, nummerische Vergleiche durchzuführen, wurden sie teilweise entwickelt, um die Verarbeitung von Textinformationen zu unterstützen. Somit werden die Eingangs”vektoren” häufig als ”Folgen” von Textzeichen spezifiziert.
Gleich jeder (imm[3:2] = 10). Bei dieser Operation werden gleich positionierte Elemente von zwei Folgen verglichen. Das Ergebnis des Vergleichs ist eine Bitmaske (1, falls die entsprechenden Bytes gleich sind, 0, falls sie nicht gleich sind). Zum Beispiel:
Operand1 = ”UseFlatAssembler”
Operand2 = ”UsingAnAssembler”
Zwischenergebnis(IntRes1) = 1100000111111111
Gleich beliebiger (imm[3:2] = 00). Der erste Operand ist ein Zeichensatz, der zweite ist eine Folge. Die Bitmaske weist 1 auf, falls das Zeichen zu einem Satz gehört, eine 0, falls nicht:
Operand2 = ”You Drive Me Mad”, Operand 1 = ”aeiouy”
IntRes1 = 0110001010010010
Gleich Bereich (imm[3:2] = 01). Der erste Operand besteht aus Bereichen, zum Beispiel bedeutet ”azAZ” sämtliche Zeichen von a bis z und sämtliche Zeichen von A bis Z:
Operand2 = ”I'm here because”, Operand 1 = ”azAZ”
IntRes1 = 1010111101111111
Gleich geordnet (imm[3:2] = 11). Teilfolgensuche. Der erste Operand enthält eine Folge, nach der gesucht wird, der zweite ist eine Folge, in der gesucht wird. Die Bitmaske weist eine 1 auf, falls die Teilfolge an der entsprechenden Position gefunden wird:
Operand2 = ”WhenWeWillBeWed!”, Operand1 = ”We”
IntRes1 = 000010000000100
Nach dem Berechnen der Aggregationsfunktion kann IntRes1 komplementiert werden, zu einer Bytemaske erweitert werden oder als Bitmaske präsentiert werden. Das Ergebnis wird in den Vektorregisterplatz geschrieben.
Ein beispielhaftes Histogramm ist in 3 zu sehen. Wie in 3 zu sehen ist, ist die horizontale Achse in Segmente 301_1 bis 301_N unterteilt, wobei jedes Segment einem nummerischen Bereich oder ”Bin” entspricht. Zum Beispiel kann jedes Segment unterschiedlichen Gewichtsbereichen entsprechen (z. B. Bin 301_1 = kleiner als 90 Pounds; 301_2 = 91 Pounds bis 110 Pounds; 301_3 = 111 Pounds bis 130 Pounds etc.). Die horizontale Achse entspricht der Zählung einer Population innerhalb jedes jeweiligen Bins. Falls zum Beispiel das Gewicht von 100 erwachsenen Männern auf die Bins der horizontalen Achse abgebildet würde, würde eine Histogrammform 300 entstehen, die die Anzahl von Männern aus den 100 Männern innerhalb des Bereichs jedes jeweiligen Bins zeigt (z. B. 0 Mann in Bin 301_1; 1 Mann in Bin 301_2; 2 Männer in Bin 301_3 etc.).
Figuren
Die vorliegende Erfindung ist beispielhaft und nicht einschränkend in den Figuren der beiliegenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen im Wesentlichen gleiche Elemente anzeigen und in denen:
1 eine Befehlsausführungs-Pipeline zeigt;
2A und 2B eine Vektorverarbeitung zeigen;
3 ein Histogramm zeigt;
4A, 4B, und 4C unterschiedliche Aspekte eines PRNGCMP-Befehls zeigen; 5A–D unterschiedliche Funktionseinheiten-Auslegungen für einen PRGNCMP-Befehl zeigen;
6A ein Blockschaltbild mit Darstellung eines generischen vektorfreundlichen Befehlsformats und Klasse-A-Befehlsvorlagen desselben gemäß Ausführungsformen der Erfindung ist.
6B ein Blockschaltbild mit Darstellung des generischen vektorfreundlichen Befehlsformats und Klasse-B-Befehlsvorlagen desselben gemäß Ausführungsformen der Erfindung ist.
7A–C Blockschaltbilder mit Darstellung eines beispielhaften spezifischen vektorfreundlichen Befehlsformats gemäß Ausführungsformen der Erfindung sind.
8 ein Blockschaltbild einer Registerarchitektur gemäß einer Ausführungsform der Erfindung ist.
9A ein Blockschaltbild eines Einzel-CPU-Kerns zusammen mit seiner Verbindung mit dem auf dem Chip befindlichen Verbindungsnetzes und mit seinem lokalen Teilsatz des Level-2-(L2-)Caches gemäß Ausführungsformen der Erfindung ist.
9B eine Explosionsansicht eines Teils des CPU-Kerns von 9A gemäß Ausführungsformen der Erfindung ist.
10 ein Blockschaltbild mit Darstellung einer beispielhaften Out-of-OrderArchitektur gemäß Ausführungsformen der Erfindung ist.
11 ein Blockschaltbild eines Systems gemäß einer Ausführungsform der Erfindung ist.
12 ein Blockschaltbild eines zweiten Systems gemäß einer Ausführungsform der Erfindung ist.
13 ein Blockschaltbild eines dritten Systems gemäß einer Ausführungsform der Erfindung ist.
14 ein Blockschaltbild eines SoC gemäß einer Ausführungsform der Erfindung ist.
15 ein Blockschaltbild eines Einzelkernprozessors und eines Multikernprozessors mit einem Integriert-Speicher-Controller und -Grafik gemäß Ausführungsformen der Erfindung ist.
16 ein Blockschaltbild zum Gegenüberstellen der Verwendung eines Softwarebefehlsumwandlers zum Umwandeln von binären Befehlen in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung ist.
Detaillierte Beschreibung
4A zeigt einen Prozess, der von einem neuen Befehl PRNGCMP durchgeführt wird, welcher zum Erzeugen eines Histogramms verwendet werden kann. Die Operation des PRNGCMP-Befehls basiert auf dem PCMPxESTy-Befehl. Der PRNGCMP-Befehl liefert jedoch eine Vektorresultierende, deren Bestandelemente den Zählungen innerhalb eines Bins statt einer Maske entsprechen. Wie in 4A zu sehen ist, übernimmt der Befehl als ersten Eingangsoperanden einen Vektor, dessen Bestandelemente den Einbereichen 401 entsprechen und übernimmt als zweiten Operanden einen Vektor, der einer Vielzahl von Werten für die jeweiligen Populationseinheiten, die einem Binning 402 zu unterziehen sind, entspricht. Zum Beispiel würden in Fortführung des Beispiels von 3 die unterschiedlichen Elemente des Eingangsvektors 401 unterschiedlichen Einbereichen des Histogramms entsprechen (z. B. erstes Element = 0 bis 90 lbs; zweites Element = 91 bis 110 lbs; drittes Element = 111 bis 130 lbs; ...) und würden die unterschiedlichen Elemente des Eingangsvektors 402 den jeweiligen Gewichten von unterschiedlichen Männern entsprechen (z. B. erstes Element = Gewicht von Mann Nr. 1; zweites Element = Gewicht von Mann Nr. 2; drittes Element = Gewicht von Mann Nr. 3 ... etc.).
Der Befehl geht dann zum Durchführen seiner Aggregationsfunktion weiter, die einem Vergleich 403 jedes Elements in dem zweiten Eingangsvektor 402 mit jedem Element in dem ersten Eingangsvektor entspricht. Wie in 4A zu sehen ist, ist gemäß einer Ausführungsform, z. B. unter einer Mikrocodesteuerung, der Befehl so ausgelegt, dass er für jedes Element in dem zweiten Eingangsvektor ”eine Schleife beschreibt”. Somit wird für eine erste Schleife das erste Element des Eingangsvektors 402 (z. B. das Gewicht von Mann Nr. 1) mit jedem Element des Eingangsvektors 401 (den anderen Gewichtsbins des Histogramms) verglichen. Im Fall eines einfachen Histogramms gibt es keine Überlappung zwischen den Bins der horizontalen Achse und gibt es höchstens eine Übereinstimmung.
Bei der beispielhaften Darstellung von 4A fällt das erste Element des zweiten Eingangsvektors in das Bin, das dem dritten Element des ersten Eingangsvektors entspricht. Der Zwischenvektor 450, der aus dem Vergleich resultiert, zeigt, dass die Zählung 1 für das dritte Bin und null für die anderen Bins beträgt.
Jede nachfolgende Schleife führt den gleichen Prozess für das nächste Element in dem zweiten Eingangsvektor durch. Insbesondere wird das Ergebnis des Vergleichs jeder Schleife der Summierung mit den jeweiligen Zwischenvektoren 404 der vorhergehenden Schleifen hinzugefügt. Somit dient die Summierung der Zwischenvektoren als Akkumulator, der die Zählung für jedes Bin in jeder Schleife akkumuliert. Falls zum Beispiel das zweite Element des Eingangsvektors 402 ebenfalls in das dritte Bin fiele, würde das dritte Element der Zwischenvektorsummierung 404 einen Wert von 2 am Ende der zweiten Schleife enthalten. Wenn sämtliche Elemente des zweiten Eingangsvektors 402 analysiert sind (sämtliche der Schleifen beendet sind), hält der Akkumulator/Zwischenvektor die Zählung für jedes Bin für den gesamten Eingangsvektorsatz 405. An diesem Punkt wird die Zwischenvektorsummierung als Resultierende für den Befehl 406 präsentiert.
Mehrere PRNGCMP-Befehle können ausgeführt werden, um sowohl die Anzahl von Bins als auch die Größe der Population, die zu analysieren ist, für ein besonderes Histogramm zu skalieren. Falls zum Beispiel die Vektorverarbeitungs-Hardware-Logik nur eine maximale Eingangsvektor-Operandengröße von 8 in Betracht zieht und gewünscht ist, dass ein Histogramm 128 Bins für eine Populationsgröße von 1024 aufweist, dann kann das fertige Histogramm durch 16 × 128 = 2.048 PRNGCMP-Befehle berechnet werden. Hier werden 128/8 = 16 Befehle benötigt, um die Anzahl von Bins auf 128 zu skalieren, und es werden 2048/8 = 128 Befehle benötigt, um die Population auf eine Größe von 2048 zu skalieren. Andernfalls würden 16 Vektoren mit jeweils acht Elementen benötigt, um effektiv 64 Histogrammbins zu bilden, und 128 Vektoren jedes Elements würden benötigt, um effektiv eine Populationsgröße von 1024 zu schaffen. Jeder der 16 Binvektoren würde als erster Eingangsvektor für seinen eigenen jeweiligen Satz von 128 PRNGCMP-Befehlen verwendet (ein Befehl für jeden Populationsvektor wird als zweiter Eingangsvektor verwendet).
4B zeigt eine generischere Struktur. Wie in 4B zu sehen ist, gibt es X erste Eingangsvektoren 411_1 bis 411_X, die benötigt werden, um sämtliche der gewünschten Bins zu erstellen, und es gibt Y zweite Eingangsvektoren 412_1 bis 412_Y, die benötigt werden, um die gesamte Population zu erstellen. Bei dem vorstehend diskutierten Beispiel sind X = 16 und ist Y = 128. Jeder erste Eingangsvektor 411_1, 411_2, ... 411_X wird mit einem PRNGCMP-Befehl gegenüber sämtlichen der zweiten Eingangsvektoren 412_1, 412_2, ... 412_Y ausgeführt, um einen Satz 430 von X PRNGCMP-Befehlen 420_1, 420_2, ... 420_X für den ersten 411_1 der ersten Eingangsvektoren zu bilden. Die Resultierende jedes Befehls setzt sich als Anfangswert für die Zwischenvektorsummierung eines ”gleich positionierten” Befehls” in den nächsten Satz durch, um die akkumulierende Art der Zwischenwertsummierung für einen gleichen Satz von Bins zu übertragen.
Falls zum Beispiel die Resultierende des ersten Befehls in dem ersten Satz 420_1 (1,0,2,3,0,0,0,2) ist und der erste Befehl in dem nächsten Satz 420_X + 1 eine Vergleichszählung (0,0,1,2,1,1,0,3) für den zweiten Eingangsvektor 412_2 ergibt, ist die Resultierende des Befehls 420_X + 1 die Summierung der zwei Vektoren (1,0,3,5,1,1,0,5). Der Übertrag der Akkumulation wird für einen gleichen Satz von Bins fortgesetzt, bis sämtliche Y zweiten Eingangsvektoren verarbeitet worden sind, an welchem Punkt die Zählungen des Histogramms für den Satz von Bins beendet ist. Der gleiche Prozess wird für jeden der X ersten Eingangsvektoren verfolgt. Insbesondere können Zwischenvektorsummierungen in einem Vektorregisterplatz gespeichert und danach zur Verwendung als Eingangs-Zwischenwertsummierung für den nächsten Befehl für einen gleichen Satz von Bins (gleichen ersten Eingangsvektor) gelesen werden. Der Anfangswert für die Zwischenvektorsummierung wird auf einen Nullvektor für die Befehle des ersten Satzes 430 gesetzt.
Es sei darauf hingewiesen, dass, falls der PRNGCMP-Befehl nicht so ausgelegt ist, dass er einen Zwischenwertsummierungs-Eingangsoperanden übernimmt und addiert, die Resultierende des unmittelbar vorhergehenden PRNGCMP-Befehls zu der Resultierenden eines unmittelbar nachfolgenden PRNGCMP-Befehls für einen gleichen Einsatz mit einem dazwischengeschalteten Vektor-ADD-Befehl zwischen den PRNGCMP-Befehlen addiert werden kann.
4D zeigt ein beispielhaftes Befehlsformat 440 für den PRNGCMP-Befehl. insbesondere spezifiziert neben einem Opcode, der den Befehl als PRNGCMP-Befehl identifiziert, das Befehlsformat 440 drei Eingangsoperanden 441, 442 und 443 und einen Direktwertoperanden 444. Das Feld, das den Eingangsoperanden 441 spezifiziert, identifiziert einen Vektorregisterplatz R1, an dem sich die Anfangs-Zwischenvektorsummierung befindet. Wie oben diskutiert worden ist, wird der Anfangs-Zwischenvektor-Summierungswert zum Ergebnis des Vergleichs zwischen dem ersten und dem zweiten Vektor addiert, um das Endergebnis des Befehls zu bestimmen.
Bei der besonderen Ausführungsform des Befehls von 4C wird die Resultierende des Befehls ebenfalls in den gleichen Registerplatz R1 geschrieben, der für die Zwischenvektorsummierung 441 spezifiziert ist. Das nächste Eingangsoperandenfeld 442 identifiziert einen Vektorregisterplatz R2, an dem sich der erste Eingangsvektor, der Eindefinitionen für das Histogramm enthält, befindet, und das nachfolgende Eingangsoperandenfeld 443 identifiziert einen Vektorregister- oder Systemspeicherplatz R3/MEM, an dem sich der zweite Eingangsvektor, der die Populationseinheiten enthält, befindet.
Das Direktwertoperandenfeld 444 ist bei einer Ausführungsform kodiert, um bis zu vier unterschiedliche spezifische Merkmale des auszuführenden Befehls zu spezifizieren. Insbesondere spezifiziert ein erstes Feld des Zwischenoperanden 444 den Typ des durchzuführenden Vergleichs (der Aggregationsoperation), ein zweites Feld spezifiziert die Abmessungen der Zwischen- und zweiten Eingangsvektoren (z. B. jeweils 16 Elemente eines Bytes oder jeweils 8 Element von zwei Bytes) und ob die Elemente vorzeichenbehaftet sind oder nicht , ein drittes Feld spezifiziert, ob die Resultierendenelemente nach links oder rechts in ihren jeweiligen Vektorpositionen ausgerichtet sind. Bei einer weiteren Ausführungsform können zwei Typen von Aggregationsfunktionen spezifiziert sein: ”Gleich Bereich” oder ”Gleich beliebiger”. Im Fall von ”Gleich Bereich” sind zwei Werte in einen einzelnen Vektorelementplatz gepackt. Falls zum Beispiel der erste Eingangsvektor acht unterschiedliche Bins spezifiziert, weist der Eingangsvektor sechszehn unterschiedliche Werte auf. Hier ist jedes Bin von einem Paar von Werten in dem ersten Eingangsvektor definiert, wobei einer des Paars die obere Grenze des Bereichs spezifiziert und der andere des Paars die untere Grenze des Bereichs spezifiziert. Im Fall von ”Gleich beliebiger” ist jedes Bin als skalar statt als Bereich definiert, so dass nur ein Wert in dem ersten Vektor benötigt wird, um ein Bin zu spezifizieren. Hier kann zum Beispiel der ”Gleich beliebiger”-Modus angewendet werden, um stärker granularisierte Histogramme zu erstellen als mit ”Gleich Bereich”. Zum Beispiel kann ein Histogramm, das einem Binning zu einer einzelnen Pound-Granularität (120 lbs, 121 lbs, 122 lbs, ...) unterzogen wird, mit ”Gleich beliebiger” im Gegensatz zu ”Gleich Bereich” implementiert werden, was verwendet werden kann, um Pound-Bereiche (120–139 lbs; 140–159 lbs; ... etc.) zu implementieren.
Bei weiteren Ausführungsformen kann der Opcode oder Zwischenwert 444 ferner das Datenformat der Elemente in dem ersten, dem zweiten und/oder dem Zwischenvektor (Ganzzahl, Gleitkomma, Zeichen) und/oder die jeweilige Größen des ersten und des Zwischeneingangsvektors und des zweiten Eingangsvektors spezifizieren. Bezüglich der Vektorgrößen sei darauf hingewiesen, dass der erste Eingangsvektor (und Zwischenvektor), die eine Anzahl von Bins spezifizieren, nicht die gleiche Größe aufzuweisen brauchen wie der zweite Eingangsvektor mit den Populationswerten.
Bei einer alternativen Ausführungsform wird der Anfangs-Zwischenvektor-Summierungswert nicht als Eingangsoperand übernommen. Bei dieser Ausführungsform entspricht das von dem Feld 441 identifizierte Register genau dem Resultierendenziel und wird nicht als einen Eingangsoperanden haltend angesehen.
5A zeigt eine Architektur für eine Funktionseinheit 500, die so ausgelegt ist, dass sie einen PRNGCMP-Befehl durchführt. Wie in 5A zu sehen ist, weist die Funktionseinheit eine Komparator-Schaltungsanordnungsbank 505 mit einem vorangehenden Multiplexer 504 auf. Ein Eingang jeder Komparatorschaltung in der Komparatorbank übernimmt seinen eigenen ausgerichteten jeweiligen Eingang aus einem ersten Eingangsvektorregister 501. Dieser Eingang entspricht der Bindefinition für jedes Bin, das in dem ersten Eingangsvektor identifiziert wird, der in dem Register 501 gehalten wird. Im Fall von ”Gleich beliebiger” führt jeder Eingang einen Wert und implementiert jede Komparatorschaltung eine Vergleichsfunktion für ihren jeweiligen Binplatz. In einem gleichen Maschinenzyklus ist die Multiplexerschaltung 504 so ausgelegt, dass sie einen besonderen Populationswert aus dem zweiten Eingangsvektor in einem Register 502 auswählt und jedem Komparator in der Komparatorbank 505 präsentiert.
Somit wird bei einer Ausführungsform in einem gleichen Maschinenzyklus ein einzelner Populationswert gleichzeitig gegenüber sämtlichen Bins, die von dem ersten Eingangsvektor definiert sind, gerastert. Im einfachsten Fall identifiziert nur eine Komparatorschaltung eine Übereinstimmung. Somit gleicht im einfachsten Fall das Ausgangsergebnis aus der Komparator-Schaltungsanordnung einem Vektor mit den gleichen logischen Werten mit einer Ausnahme. Falls zum Beispiel der Populationswert mit dem dritten Bin von links übereinstimmt, kann die Komparatorbank-Schaltungsanordnung 505 den folgenden Vektor ergeben: 0010 ... 0. Ein in einem ROM 507 gespeicherter Mikrocode initialisiert den Inhalt eines Registers 508 mit einem Nullvektor, so dass in einer ersten Schleife das Ergebnis aus dem Vektoraddierer 506, das in das Register 508 geschrieben ist, mit dem Ausgang aus der Komparatorbank 505 übereinstimmt. Der Mikrocode aus dem ROM 507 initialisiert dann eine nächste Schleife und bewirkt, dass der Multiplexer 504 den nächsten Populationswert aus dem zweiten Eingangsvektor in dem Register 502 auswählt. Der Addierer 506 addiert den jüngsten Vergleich zu der Akkumulation (Summierung) der vorhergehenden Vergleiche. Das Durchlaufen der Schleife wird fortgesetzt, bis jedes Element in dem zweiten Eingangsvektor verarbeitet worden ist, an welchem Punkt sich die akkumulierte Resultierende in einem Zwischenregister 508 befindet (der Mikrocode in ROM 507 steuert auch das Halten des Registers 508 bei jeder Schleife). Die Zwischenwert-Resultierende wird dann von einem Addierer 509 zu dem Anfangs-Vektorsummierungs-Eingangsoperanden (aus einem Eingangsoperandenregister 503) addiert, um die Befehlsresultierende zu produzieren. Die Resultierende überschreibt bei einer Ausführungsform den Anfangs-Zwischenvektorsummierungs-Eingangsoperanden in dem Register 503.
Die Verarbeitung ist die gleiche wie oben für den ”Gleich-Bereich”-Modus beschrieben worden ist, mit der Ausnahme, dass zwei Werte aus dem ersten Eingangsvektor in dem Register 501 zu ihrer entsprechenden Bin-Vergleichsschaltung in der Komparatorbank 504 geleitet werden. Die Vergleichsschaltung für jedes einzelne Bin kann zwei Komparatoren enthalten: einen ersten, der bestimmt, ob der Populationswert höher ist als eine untere Grenze, und einen zweiten, der bestimmt, ob der Populationswert niedriger als oder gleich der oberen Grenze ist. Nur wenn beide Vergleiche ”wahr” ergeben, zeigt die Vergleichsschaltung für dieses Bin eine Übereinstimmung für dieses Bin an.
Insbesondere kann jedes der Eingangsregister 501, 502 und Eingangs-/Resultierendenregister 503 einem Vektorregisterplatz entsprechen, der von einem Code oder von Registern, die sich innerhalb der Pipeline mit der Funktionseinheit befinden (z. B. können die Register 501, 502 Registern innerhalb der Datenabrufstufe oder Funktionseinheit entsprechen, die Eingangsoperanden aus Registern des Vektorregisterplatzes empfangen, der von dem Programmcode aufgerufen worden ist), explizit aufgerufen worden ist.
Bei einer alternativen Ausführungsform wird ein Anfangs-Zwischenwert nicht als Eingangsoperand übernommen. In diesem Fall gibt es keine Verschaltung von dem Register 503 zu dem Eingang der Addierer-Schaltungsanordnung 506.
5B zeigt eine weitere Ausführungsform einer Funktionseinheit 510 zum Implementieren eines PRNGCMP-Befehls. Bei der Vorgehensweise von 5B werden keine Schleifen verwendet, und es werden stattdessen explizit sämtliche Werte des Befehls in einer einzelnen Sequenz berechnet. Fachleute auf dem Sachgebiet erkennen, dass bei der Vorgehensweise von 5A auf das Einsparen von Silizium-Flächenbereich zu Lasten der Leistung Wert gelegt wird, wohingegen bei der Vorgehensweise von 5B auf die Leistung zu Lasten des Silizium-Flächenbereichs Wert gelegt wird. Insbesondere werden bei der Vorgehensweise von 5B keine Multiplexer benötigt und weist die Additionsschaltungsstufe Addierer auf, die den Eingang für jedes Element des zweiten Vektors statt nur einen übernehmen.
Fachleute sind in der Lage, Hybrid-Vorgehensweisen aus denjenigen von 5A und 5B so auszulegen, dass auf eine Mischung aus Leistungs- und Silizium-Flächenbereichs-Effizient Wert gelegt wird.
5C zeigt weitere alternative Ausführungsformen von Funktionseinheiten, die in der Lage sind, nicht nur PRNGCMP-Befehle, sondern auch PCMPxESTy-Befehle auszuführen. Insbesondere enthalten diese alternativen Ausführungsformen von Funktionseinheiten eine Schalter-Schaltungsanordnung, die einen Datenfluss durch die Addierer-Schaltungsanordnung oder um die Addierer-Schaltungsanordnung herum führen, um diese zu umgehen. Hier ist dann, wenn das Opcode-Feld eines Befehls dekodiert wird, um einen PRNGCMP-Befehl zu ergeben, die Schalter-Schaltungsanordnung so ausgelegt, dass sie den Datenfluss durch die Addierer-Schaltungsanordnung zwingt, wohingegen dann, wenn das Opcode-Feld eines Befehls dekodiert wird, um einen PCMPxESTy-Befehl zu ergeben, die Schalter-Schaltungsanordnung so ausgelegt ist, dass sie bewirkt, dass der Datenfluss aus den Komparatorbanken die Addierer-Schaltungsanordnung umgeht.
Obwohl die vorstehende Diskussion das Vergleichen eines einzelnen Populationselements mit mehreren Elementen des ersten (Bindefinitions-)Eingangsvektors bei einer einzelnen Operation betrifft, kann die alternative Vorgehensweise angewendet werden, bei der mehrere Populationselemente mit einen einzelnen (Bindefinitions-)Element bei einer einzelnen Operation verglichen werden. 5D zeigt eine Ausführungsform der Funktionseinheitsstruktur bei dieser Vorgehensweise. Hier erfolgt eine Ausfächerung eines einzelnen Bitdefinitionselements aus dem ersten Eingangsvektor zu der Vergleichsschaltungsanordnung und wird die Resultierende des Vergleichs mit einem Mehrfach-Eingangsaddierer summiert, um eine ”Eingangsfächerung” der Resultierenden zu einer finalen summierten Skalaren für das besondere ausgewählte Binelement zu bewirken. Die Skalare wird dann zu dem geeigneten Elementplatz des Resultierendenvektors geleitet. Falls mikrokodierte Schleifen implementiert werden, können Multiplexer auf Levels XXX, YYY platziert werden, um das korrekte Binelement zu der Vergleichsbank zu leiten und das Addierergebnis zu dem korrekten Resultierendenvektorelementplatz zu leiten. Bei einer weiteren Ausführungsform kann die Addierer-Schaltungsanordnung umgangen werden, um PCMPxESTy-Befehle auszuführen, wie vorstehend beschrieben worden ist.
Ausführungsformen des (der) Befehls (Befehle), die oben detailliert beschrieben worden sind, können in einem ”generischen vektorfreundlichen Befehlsformat” ausgeführt werden, wie nachstehend detailliert beschrieben wird. Bei weiteren Ausführungsformen wird ein solches Format nicht verwendet und wird ein anderes Befehlsformat verwendet, die nachstehende Beschreibung der Schreibmaskenregister, verschiedener Datentransformationen (Swizzle, Senden etc.) Adressierung etc. ist jedoch generell auf die Beschreibung der vorstehenden Ausführungsformen des (der) Befehls (Befehle) anwendbar. Des Weiteren werden beispielhafte Systeme, Architekturen und Pipelines nachstehend detailliert beschrieben. Vorstehende Ausführungsformen des (der) Befehls (Befehle) können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die detailliert beschriebenen beschränkt.
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (z. B. gibt es bestimmte Felder, die für Vektoroperationen spezifisch sind). Obwohl Ausführungsformen beschrieben worden sind, bei denen sowohl Vektor- als auch Skalaroperationen von dem vektorfreundlichen Befehlsformat unterstützt werden, werden bei alternativen Ausführungsformen nur Vektoroperationen mit dem vektorfreundlichen Befehlsformat verwendet.
Beispielhaftes generisches vektorfreundliches Befehlsformat – Fig. 6A–B
6A–B sind Blockschaltbilder mit Darstellung eines generischen vektorfreundlichen Befehlsformats und von Befehlsvorlagen dafür gemäß Ausführungsformen der Erfindung. 6A ist ein Blockschaltbild mit Darstellung eines generischen vektorfreundlichen Befehlsformats und von Klasse-A-Befehlsvorlagen dafür gemäß Ausführungsformen der Erfindung; während 6B ein Blockschaltbild mit Darstellung des generischen vektorfreundlichen Befehlsformats und von Klasse-B-Befehlsvorlagen dafür gemäß Ausführungsformen der Erfindung ist. Insbesondere ein generisches vektorfreundliches Befehlsformat 600, für das Klasse-A- und Klasse-B-Befehlsvorlagen definiert sind, die beide Kein-Speicherzugriff- 605 Befehlsvorlagen und Speicherzugriff- 602 Befehlsvorlagen aufweisen. Der Ausdruck generisch im Kontext des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat an keinen spezifischen Befehlssatz gebunden ist. Obwohl Ausführungsformen beschrieben werden, bei denen Befehle in dem vektorfreundlichen Befehlsformat auf Vektoren arbeiten, die entweder aus Registern (Kein-Speicherzugriff- 605 Befehlsvorlagen) oder Registern/Speichern (Speicherzugriff- 620 Befehlsvorlagen) bezogen werden, können alternative Ausführungsformen der Erfindung nur eines davon unterstützen. Ferner werden zwar Ausführungsformen beschrieben, bei denen Lade- und Speicherbefehle in dem Vektorbefehlsformat enthalten sind, alternative Ausführungsformen weisen jedoch stattdessen oder zusätzlich Befehle in einem anderen Befehlsformat auf, die Vektoren in und aus Registern bewegen (z. B. aus einem Speicher in Register, aus einem Register in einen Speicher, zwischen Registern). Ferner werden zwar Ausführungsformen der Erfindung beschrieben, die zwei Klassen von Befehlsvorlagen unterstützen, alternative Ausführungsformen können jedoch nur eines davon oder mehr als zwei unterstützen.
Obwohl Ausführungsformen der Erfindung beschrieben werden, bei denen das vektorfreundliche Befehlsformat folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit-(4-Byte-) oder 64-Bit-(8-Byte-)Datenelementbreiten (oder -größen) (und somit besteht ein 64-Byte-Vektor entweder aus 16 Doppelwortgrößen-Elementen oder alternativ 8 Quadwordgrößen-Elementen); eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 16-Bit-(2-Byte-)oder 8-Bit-(1-Byte-)Datenelementbreiten (oder -größen); eine 32-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit-(4-Byte-), 64-Bit-(8-Byte-), 16-Bit-(2-Byte-) oder 8-Bit(1-Byte-)Datenelementbreiten (oder -größen); und eine 16-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit-(4-Byte-), 64-Bit-(8-Byte-), 16-Bit-(2-Byte-) oder 8-Bit(1-Byte-)Datenelementbreiten (oder -größen); können alternative Ausführungsformen mehr, weniger und/oder andere Vektoroperandengrößen (z. B. 656-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. 128-Bit-(16-Byte-)Datenelementbreiten) unterstützen.
Die Klasse-A-Befehlsvorlagen in 6A weisen auf: 1) innerhalb der Kein-Speicherzugriff- 605 Befehlsvorlagen sind eine Kein-Speicherzugriff-Vollrundungs-Steuerungsoperations- 610 Befehlsvorlage und eine Kein-Speicherzugriff-Datentransformationsoperations- 615 Befehlsvorlage gezeigt; und 2) innerhalb der Speicherzugriff- 620 Befehlsvorlagen sind eine Speicherzugriff-Zeitlich- 625 Befehlsvorlage und eine Speicherzugriff-Nichtzeitlich- 630 Befehlsvorlage gezeigt. Die Klasse-B-Befehlsvorlagen in 6B weisen auf: 1) innerhalb der Kein-Speicherzugriff- 605 Befehlsvorlagen sind eine Kein-Speicherzugriff-Schreibmaskensteuerungs-Teilrundungs-Steuerungsoperations- 612 Befehlsvorlage und eine Kein-Speicherzugriff-Schreibmaskensteuerungs-Vsize-Operations- 617 Befehlsvorlage gezeigt; und 2) innerhalb der Speicherzugriff- 620 Befehlsvorlagen ist eine Speicherzugriff-Schreibmaskensteuerungs- 627 Befehlsvorlage gezeigt.
Format
Das generische vektorfreundliche Befehlsformat 600 weist die folgenden nachstehend in der in 6A–B dargestellten Reihenfolge aufgeführten Felder auf. In Zusammenhang mit der vorstehenden Diskussion kann bei einer Ausführungsform, die sich auf die nachstehend in 6A–B und 7 vorgesehenen Details bezieht, entweder ein Kein-Speicherzugriff-Befehlstyp 605 oder ein Speicherzugriff-Befehlstyp 620 verwendet werden. Adressen für den (die) Eingangsvektoroperanden und das Ziel können in Registeradressenfeldern 644, die nachstehend beschrieben werden, identifiziert werden.
Formatfeld 640 – ein spezifischer Wert (ein Befehlsformat-Identifiziererwert) in diesem Feld identifiziert auf einzigartige Weise das vektorfreundliche Befehlsformat und somit das Auftreten von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Somit unterscheidet der Inhalt des Formatfelds 640 zwischen dem Auftreten von Befehlen im ersten Befehlsformat und dem Auftreten von Befehlen in anderen Befehlsformaten, wodurch das Eintragen des vektorfreundlichen Befehlsformats in einen Befehlssatz, der andere Befehlsformate aufweist, ermöglicht wird. Somit ist dieses Feld optional in dem Sinn, dass es nicht für einen Befehlssatz benötigt wird, der nur das generische vektorfreundliche Befehlsformat aufweist.
Basisoperationsfeld 642 – sein Inhalt unterscheidet zwischen unterschiedlichen Basisoperationen. Wie nachstehend beschrieben wird, kann das Basisoperationsfeld 642 ein Opcode-Feld aufweisen und/oder Teil eines solchen sein.
Registerindexfeld 644 – sein Inhalt spezifiziert direkt oder durch Adressenerzeugung die Plätze der Quell- und Zieloperanden unabhängig davon, ob sie sich in Registern oder im Speicher befinden. Diese weisen eine ausreichende Anzahl von Bits zum Auswählen von N Registern aus einer P × Q-(z. B. 32 × 1012)Registerdatei auf. Obwohl bei einer Ausführungsform N bis zu drei Quellen und ein Zielregister umfassen kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (z. B. bis zu zwei Quellen unterstützen können, wobei eine dieser Quellen auch als Ziel dient, bis zu drei Quellen unterstützen können, wobei eine dieser Quellen auch als Ziel dient, bis zu zwei Quellen und ein Ziel unterstützen können). Obwohl bei einer Ausführungsform P = 32 ist, können alternative Ausführungsformen mehr oder weniger Register (z. B. 16) unterstützen. Obwohl bei einer Ausführungsform Q = 1012 ist, können alternative Ausführungsformen mehr oder weniger Bits (z. B. 128, 1024) unterstützen.
Modifiziererfeld 646 – sein Inhalt unterscheidet zwischen dem Auftreten von Befehlen im generischen vektorfreundlichen Befehlsformat, die einen Speicherzugriff spezifizieren, und denjenigen, bei denen dies nicht der Fall ist; das heißt zwischen Kein-Speicherzugriff- 605 Befehlsvorlagen und Speicherzugriff- 620 Befehlsvorlagen. Bei Speicherzugriffsoperationen wird aus der Speicherhierarchie gelesen und/oder in diese geschrieben (wobei in einigen Fällen die Quell- und/oder Zieladressen unter Verwendung von Werten in Registern spezifiziert werden), während dies bei Kein-Speicherzugriff-Operationen nicht der Fall ist (z. B. die Quelle und Ziele Register sind).
Obwohl bei einer Ausführungsform dieses Feld ferner zwischen drei unterschiedlichen Arten zum Durchführen von Speicheradressenberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder andere Arten zum Durchführen von Speicheradressenberechnungen unterstützen.

Augmentationsoperationsfeld 650 – sein Inhalt unterscheidet, welche einer Vielzahl von unterschiedlichen Operationen zusätzlich zu der Basisoperation durchgeführt wird. Dieses Feld ist kontextspezifisch. Bei einer Ausführungsform der Erfindung ist dieses Feld in ein Klassefeld 668, ein Alpha-Feld 652 und ein Beta-Feld 654 unterteilt. Das Augmentationsoperationsfeld ermöglicht, dass gemeinsame Gruppen von Operationen in einem einzelnen Befehl statt in 2, 3 oder 4 Befehlen durchgeführt werden. Nachstehend finden sich einige Beispiele für Befehle (deren Bezeichnung nachstehend genauer beschrieben wird), bei denen das Augmentationsoperationsfeld 650 zum Verringern der Anzahl von erforderlichen Befehlen verwendet wird.

Vorhergehende Befehlssequenzen	Befehlssequenzen gemäß einer Ausführungsform der Erfindung
vaddps ymm0, ymm1, ymm2	vaddps zmm0, zmm1, zmm2
vpshufd ymm2, ymm2, 0 × 55 vaddps ymm0, ymm1, ymm2	vaddps zmm0, zmm1, zmm2 {bbbb}
vpmovsxbd ymm2, [rax] vcvtdq2ps ymm2, ymm2 vaddps ymm0, ymm1, ymm2	vaddps zmm0, zmm1, [rax]{sint8}
vpmovsxbd ymm3, [rax] vcvtdq2ps ymm3, ymm3 vaddps ymm4, ymm2, ymm3 vblendvps ymm1, ymm5, ymm1, ymm4	vaddps zmm1{k5}, zmm2, [rax]{sint8}
vmaskmovps ymm1, ymm7, [rbx] vbroadcastss ymm0, [rax] vaddps ymm2, ymm0, ymm1 vblendvps ymm2, ymm2, ymm1, ymm7	vmovaps zmm1{k7}, [rbx] vaddps zmm2{k7}{z}, zmm1, [rax]{1 to N}

wobei [rax] der Basiszeiger ist, der zur Adressenerzeugung verwendet wird, und wobei {} eine Konvertierungsoperation anzeigt, die von dem Datenbearbeitungsfeld (das später genauer beschrieben wird) spezifiziert wird.

Skalenfeld 660 – sein Inhalt ermöglicht die Skalierung des Inhalts des Indexfelds für die Speicheradressenerzeugung (z. B. für eine Adressenerzeugung, bei der 2^Skala*Index + Basis verwendet wird). Verschiebungsfeld 662A – sein Inhalt wird als Teil der Speicheradressenerzeugung verwendet (z. B. für eine Adressenerzeugung, bei der 2^Skala*Index + Basis + Verschiebung verwendet wird).
Verschiebungsfaktorfeld 662B (es sei darauf hingewiesen, dass die Juxtaposition des Verschiebungsfelds 662A direkt über dem Verschiebungsfaktorfeld 662B anzeigt, dass das eine oder das andere verwendet wird) – sein Inhalt wird als Teil der Adressenerzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, der von der Größe eines Speicherzugriffs (N) skaliert wird – wobei N die Anzahl von Bytes beim Speicherzugriff ist (z. B. für eine Adressenerzeugung, bei der 2^Skala*Index + Basis + skalierte Verschiebung verwendet wird). Redundante niederwertige Bits werden ignoriert und somit wird der Inhalt des Verschiebungsfaktorfelds mit der Gesamtgröße der Speicheroperanden (N) multipliziert, um die finale Verschiebung zu erzeugen, die beim Berechnen einer effektiven Adresse verwendet wird. Der Wert von N wird von der Prozessor-Hardware bei einer Laufzeit bestimmt, die auf dem Voll-Opcode-Feld 674 (das später beschrieben wird) und dem Datenmanipulationsfeld 654C, das später beschrieben wird, basiert. Das Verschiebungsfeld 662A und das Verschiebungsfaktorfeld 662B sind optional in dem Sinn, dass sie nicht für die Kein-Speicherzugriff- 605 Befehlsvorlagen verwendet werden und/oder bei anderen Ausführungsformen nur eines oder keines der beiden implementiert werden kann.
Datenelementbreitenfeld 664 – sein Inhalt unterscheidet, welche eine Anzahl von Datenelementbreiten verwendet wird (bei einigen Ausführungsformen für sämtliche Befehle; bei anderen Ausführungsformen nur für einige der Befehle). Dieses Feld ist optional in dem Sinn, dass es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung einiger Aspekte der Opcodes unterstützt werden.
Schreibmaskenfeld 670 – sein Inhalt steuert auf einer pro-Datenelementposition-Basis, ob diese Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisoperation und Augmentationsoperation wiedergibt. Klasse-A-Befehlsvorlagen unterstützen die Zusammenfügungs-Schreibmaskierung, während Klasse-B-Befehlsvorlagen sowohl die Zusammenfügungs- als auch die Nullungs-Schreibmaskierung unterstützen. Bei der Zusammenfügung ermöglichen es Vektormasken, dass jeder Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung jeder Operation (von der Basisoperation und der Augmentationsoperation spezifiziert) geschützt werden; bei einer anderen Ausführungsform die Beibehaltung des alten Werts jedes Elements des Ziels, wobei das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu ermöglichen es Nullungs-Vektormasken jedem Satz von Elementen im Ziel, während der Ausführung jeder Operation (von der Basisoperation und der Augmentationsoperation spezifiziert)) genullt zu werden; bei einer Ausführungsform ist ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Ein Teilsatz dieser Funktionalität ist die Fähigkeit zum Steuern der Vektorläng der Operation, die gerade durchgeführt wird (das heißt, dass diese Spanne von Elementen vom ersten bis zum letzten modifiziert wird); es ist jedoch nicht erforderlich, dass die Elemente, die modifiziert werden, konsekutiv sind. Somit ermöglicht das Schreibmaskenfeld 670 Teil-Vektoroperationen, einschließlich Ladungen, Speicherungen, arithmetisch, logisch etc. Ferner kann diese Maskierung für eine Fehlerunterdrückung verwendet werden (d. h. durch Maskieren der Datenelementpositionen des Ziels, um den Empfang des Ergebnisses einer Operation, die einen Fehler verursachen wird/kann, zu verhindern – z. B. kann unter der Annahme, dass ein Vektor im Speicher eine Seitenbegrenzung kreuzt und dass die erste Seite, jedoch nicht die zweite Seite, einen Seitenfehler hervorruft, der Seitenfehler ignoriert werden, wenn sämtliche Datenelemente des Vektors, die auf der ersten Seite liegen, von der Schreibmaske maskiert sind). Ferner ermöglichen Schreibmasken ”Vektorisierungsschleifen”, die bestimmte Typen von bedingten Anweisungen enthalten. Obwohl Ausführungsformen der Erfindung beschrieben werden, bei denen der Inhalt des Schreibmaskenfelds 670 eines einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske enthält (und somit der Inhalt des Schreibmaskenfelds 670 indirekt diese durchzuführende Maskierung identifiziert), ermöglichen es alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 670 direkt die durchzuführende Maskierung spezifiziert. Ferner ermöglicht eine Nullung Leistungsverbesserungen, wenn 1) eine Registerumbenennung bei Befehlen angewendet wird, deren Zieloperand nicht auch eine Quelle ist (auch als Nichtternär-Befehle bezeichnet), da bei der Registerumbenennungs-Pipeline-Stufe das Ziel nicht länger eine implizite Quelle ist (keine Datenelemente aus dem aktuellen Zielregister in das umbenannte Zielregister kopiert oder auf irgendeine Art bei der Operation transportiert zu werden brauchen, da jedes Datenelement, das nicht das Operationsergebnis ist (jedes maskierte Datenelement) genullt wird); und 2) bei der Rückschreibestufe, da Nullen geschrieben werden.
Direktwertfeld 672 – sein Inhalt ermöglicht die Spezifizierung eines Direktwerts. Dieses Feld ist optional in dem Sinn, dass es bei einer Implementierung des generischen vektorfreundlichen Formats nicht vorhanden ist, das einen Direktwert nicht unterstützt, und bei Befehlen nicht vorhanden ist, die keinen Direktwert verwenden.
Befehlsvorlagen-Klassenauswahl
Klassefeld 668 – sein Inhalt unterscheidet zwischen unterschiedlichen Befehlsklassen. Gemäß 2A–B wählt der Inhalt dieses Felds zwischen Klasse-A- und Klasse-B-Befehlen. In 6A–B werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Klasse A 668A und Klasse B 668B jeweils für das Klassefeld 668 in 6A–B).
Kein-Speicherzugriff-Befehlsvorlagen der Klasse A
Im Fall der Kein-Speicherzugriff- 605 Befehlsvorlagen der Klasse A wird das Alpha-Feld 652 als RS-Feld 652A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Augmentationsoperationstypen durchzuführen ist (z. B. werden Rundungen 652A.1 und Datentransformation 652A.2 jeweils für die Kein-Speicherzugriff-Rundungsoperations- 610 und die Kein-Speicherzugriff-Datentransformationsoperations- 615 Befehlsvorlage spezifiziert), während das Beta-Feld 654 unterscheidet, welche der Operationen des spezifizierten Typs durchzuführen ist. In
6 werden Blöcke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert vorhanden ist (z. B. Kein-Speicherzugriff 646A in dem Modifiziererfeld 646; Rundung 652A.1 und Datentransformation 652A.2 für das Alpha-Feld 652/rs-Feld 652A). Bei den Kein-Speicherzugriff- 605 Befehlsvorlagen sind das Skalenfeld 660, das Verschiebungsfeld 662A und das Verschiebungsskalenfeld 662B nicht vorhanden.
Kein-Speicherzugriff-Befehlsvorlagen – Vollrundungs-Steuerungsoperation
Bei der Kein-Speicherzugriff-Vollrundungs-Steuerungsoperations- 610 Befehlsvorlage wird das Beta-Feld 654 als Rundungssteuerungsfeld 654A interpretiert, dessen Inhalt(e) ein statisches Runden vorsieht (vorsehen). Obwohl bei der beschriebenen Ausführungsform der Erfindung das Rundungssteuerungsfeld 654A ein Unterdrücke-sämtliche-Gleitkommaausnahmen-(SAE-)Feld 656 und ein Rundungsoperations-Steuerungsfeld 658 aufweist, können bei alternativen Ausführungsformen diese beiden Konzepte unterstützt werden und in dasselbe Feld kodiert werden oder nur das eine oder das andere dieser Konzepte/Felder vorgesehen sein (z. B. nur das Rundungsoperations-Steuerungsfeld 658 vorgesehen sein).
SAE-Feld 656 – sein Inhalt unterscheidet, ob das Melden des Ausnahmeereignisses deaktiviert wird oder nicht; wenn der Inhalt des SAE-Felds 656 anzeigt, dass eine Unterdrückung aktiviert ist, meldet ein vorgegebener Befehl keine Art von Gleitkomma-Ausnahme-Flag und stellt keinen Gleitkomma-Ausnahme-Handler bereit.
Rundungsoperations-Steuerungsfeld 658 – sein Inhalt unterscheidet, welche einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden in Richtung null und Runden auf den nächstliegenden Wert). Somit ermöglicht das Rundungsoperations-Steuerungsfeld 658 das Verändern des Rundungsmodus auf einer pro-Befehl-Basis und ist somit besonders sinnvoll, wenn dies erforderlich ist. Bei einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi aufweist, setzt der Inhalt des Rundungsoperations-Steuerungsfelds 650 diesen Registerwert außer Kraft (wobei es vorteilhaft ist, dass er in der Lage ist, den Rundungsmodus zu wählen, ohne ein Sichern-Modifizieren-Wiederherstellen an einem solchen Steuerregister durchführen zu müssen).
Kein-Speicherzugriff-Befehlsvorlagen – Datentransformationsoperation
Bei der Kein-Speicherzugriff-Datentransformationsoperations- 615 Befehlsvorlage wird das Beta-Feld 654 als Datentransformationsfeld 654B interpretiert, dessen Inhalt unterscheidet, welche einer Anzahl von Datentransformationen durchzuführen ist (z. B. keine Datentransformation, Swizzle, Senden).
Speicherzugriff-Befehlsvorlagen der Klasse A
Im Fall einer Speicherzugriff- 620 Befehlsvorlage der Klasse A wird das Alpha-Feld 652 als Räumungshinweisfeld 652B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise zu verwenden ist (in 6A werden jeweils zeitlich 652A.1 und nichtzeitlich 652B.2 für die Speicherzugriff-Zeitlich- 625 Befehlsvorlage und die Speicherzugriff-Nichtzeitlich- 630 Befehlsvorlage spezifiziert), während das Beta-Feld 654 als Datenmanipulationsfeld 654C interpretiert wird, dessen Inhalt unterscheidet, welche einer Anzahl von Datenmanipulationsoperationen (auch als Primitive bekannt) durchzuführen ist (z. B. keine Manipulation, Senden; Aufwärtskonvertierung einer Quelle; und Abwärtskonvertierung eines Ziels). Die Speicherzugriff- 620 Befehlsvorlagen weisen das Skalenfeld 660 und wahlweise das Verschiebungsfeld 662A oder das Verschiebungsskalenfeld 662B auf.
Vektorspeicherbefehle führen mit einer Konvertierungsunterstützung Vektorladungen aus einen und Vektorspeicherungen in einen Speicher durch. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten datenelementweise aus einem/in einen Speicher, wobei die Elemente, die tatsächlich übertragen werden, vom Inhalt der Vektormaske diktiert werden, die als Schreibmaske ausgewählt ist. In 6A werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Speicherzugriff 646B für das Modifiziererfeld 646; zeitlich 652B.1 und nichtzeitlich 652B.2 für das Alpha-Feld 652/Räumungshinweisfeld 652B).
Speicherzugriff-Befehlsvorlagen – Zeitlich
Zeitliche Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um Nutzen aus dem Caching zu ziehen. Dies ist jedoch ein Hinweis, und andere Prozessoren können diesen auf andere Arten implementieren, einschließlich des Ignorierens des Hinweises insgesamt.
Speicherzugriff-Befehlsvorlagen – Nichtzeitlich
Nichtzeitliche Daten sind Daten, bei denen es unwahrscheinlich ist, dass sie früh genug wiederverwendet werden, um Nutzen aus dem Caching des 1. Levels zu ziehen und denen Priorität beim Räumen eingeräumt werden sollte. Dies ist jedoch ein Hinweis, und andere Prozessoren können diesen auf andere Arten implementieren, einschließlich des Ignorierens des Hinweises insgesamt.
Befehlsvorlagen der Klasse B
Im Fall der Befehlsvorlagen der Klasse B wird das Alpha-Feld 652 als Schreibmaskensteuerungs-(Z-)Feld 652C interpretiert, dessen Inhalt unterscheidet, ob die von dem Schreibmaskenfeld 670 gesteuerte Schreibmaskierung eine Zusammenfügung oder eine Nullung sein soll.
Kein-Speicherzugriff-Befehlsvorlagen der Klasse B
Im Fall der Kein-Speicherzugriff- 605 Befehlsvorlagen der Klasse B wird ein Teil des Beta-Felds 654 als RL-Feld 657A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Augmentationsoperationstypen durchzuführen ist (z. B. sind Rundung 657A.1 und Vektorlänge (VSIZE) 657A.2 jeweils für die Kein-Speicherzugriff-Schreibmaskensteuerungs-Teilrundungs-Steuerungsoperations- 612 Befehlsvorlage und die Kein-Speicherzugriff-Schreibmaskensteuerungs-VSIZE-Operations- 617 Befehlsvorlage spezifiziert), während der Rest des Beta-Felds 654 unterscheidet, welche der Operationen des spezifizierten Typs durchzuführen ist. In 6 werden Blöcke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert vorhanden ist (z. B. Kein-Speicherzugriff 646A in dem Modifiziererfeld 646; Rundung 657A.1 und VSIZE 657A.2 für das RL-Feld 657A). Bei den Kein-Speicherzugriff- 605-Befehlsvorlagen sind das Skalenfeld 660, das Verschiebungsfeld 662A und das Verschiebungsskalenfeld 662B nicht vorhanden.
Kein-Speicherzugriff-Befehlsvorlagen – Schreibmaskensteuerungs-Teilrundungs-Steuerungsoperation
Bei der Kein-Speicherzugriff-Schreibmaskensteuerungs-Teilrundungs-Steuerungsoperations- 610 Befehlsvorlage wird der Rest des Beta-Felds 654 als Rundungsoperationsfeld 659A interpretiert und wird die Ausnahmeereignismeldung deaktiviert (meldet ein vorgegebener Befehl keine Art von Gleitkomma-Ausnahme-Flag und stellt keinen Gleitkomma-Ausnahme-Handler bereit).
Rundungsoperations-Steuerungsfeld 659A – genau wie beim Rundungsoperations-Steuerungsfeld 658 unterscheidet sein Inhalt, welche einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden in Richtung null und Runden auf den nächstliegenden Wert). Somit ermöglicht das Rundungsoperations-Steuerungsfeld 659A das Verändern des Rundungsmodus auf einer pro-Befehl-Basis und ist somit besonders sinnvoll, wenn dies erforderlich ist. Bei einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi aufweist, setzt der Inhalt des Rundungsoperations-Steuerungsfelds 650 diesen Registerwert außer Kraft (wobei es vorteilhaft ist, dass er in der Lage ist, den Rundungsmodus zu wählen, ohne ein Sichern-Modifizieren-Wiederherstellen an einem solchen Steuerregister durchführen zu müssen).
Kein-Speicherzugriff-Befehlsvorlagen – Schreibmaskensteuerungs-VSIZE-Operation
Bei der Kein-Speicherzugriff-Schreibmaskensteuerungs-VSIZE-Operations- 617 Befehlsvorlage wird der Rest des Betafelds 654 als Vektorlängenfeld 659B interpretiert, dessen Inhalt unterscheidet, an welcher einer Anzahl von Datenvektorlängen eine Durchführung erfolgt (z. B. 128, 856 oder 1012 Bytes).
Speicherzugriff-Befehlsvorlagen der Klasse B
Im Fall einer Speicherzugriff- 620 Befehlsvorlage der Klasse A wird ein Teil des Beta-Felds 654 als Sendefeld 657B interpretiert, dessen Inhalt unterscheidet, ob die Sende-Datenmanipulationsoperation durchzuführen ist oder nicht, während der Rest des Beta-Felds 654 als Vektorlängenfeld 659B interpretiert wird. Die Speicherzugriff- 620 Befehlsvorlagen weisen das Skalenfeld 660 und wahlweise das Verschiebungsfeld 662A oder das Verschiebungsskalenfeld 662B auf.
Zusatzkommentare zu Feldern
Bezüglich des generischen vektorfreundlichen Befehlsformats 600 ist ein Voll-Opcode-Feld 674 gezeigt, das das Formatfeld 640, das Basisoperationsfeld 642 und das Datenelementbreitenfeld 664 aufweist. Obwohl eine Ausführungsform gezeigt ist, bei der das Voll-Opcode-Feld 674 alle diese Felder aufweist, weist das Voll-Opcode-Feld 674 weniger als alle diese Felder auf bei Ausführungsformen, bei der nicht alle unterstützt werden. Das Voll-Opcode-Feld 674 stellt den Operationscode bereit.
Das Augmentationsoperationsfeld 650, das Datenelementbreitenfeld 664 und das Schreibmaskenfeld 670 ermöglichen es, dass diese Merkmale auf einer pro-Befehl-Basis im generischen vektorfreundlichen Befehlsformat spezifiziert werden.
Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld schafft dahingehend typisierte Befehle, dass ermöglicht wird, dass die Maske auf der Basis von unterschiedlichen Datenelementbreiten aufgebracht wird.
Das Befehlsformat benötigt eine relativ kleine Anzahl von Bits, da es unterschiedliche Felder für unterschiedliche Zwecke auf der Basis des Inhalts anderer Felder wiederverwendet. Zum Beispiel besteht eine Perspektive darin, dass der Inhalt des Modifiziererfelds zwischen den Kein-Speicherzugriff- 605 Befehlsvorlagen in 6A–B und den Speicherzugriff- 620 Befehlsvorlagen in 6A–B wählt; während der Inhalt des Klassefelds 668 innerhalb dieser Kein-Speicherzugriff- 605 Befehlsvorlagen zwischen Befehlsvorlagen 610/615 von 6A und 612/617 von 6B wählt; und während der Inhalt des Klassefelds 668 innerhalb dieser Speicherzugriff- 620 Befehlsvorlagen zwischen Befehlsvorlagen 625/830 von 6A und 627 von 6B wählt. Aus einer anderen Perspektive wählt der Inhalt des Klassefelds 668 zwischen den Klasse-A- und Klasse-B-Befehlsvorlagen von 6A bzw. 6B; während der Inhalt des Modifiziererfelds innerhalb dieser Klasse-A-Befehlsvorlagen zwischen Befehlsvorlagen 605 und 620 von 6A wählt; und während der Inhalt des Modifiziererfelds innerhalb dieser Klasse-B-Befehlsvorlagen zwischen den Befehlsvorlagen 605 und 620 von 6B wählt. In dem Fall, in dem der Inhalt des Klassefelds eine Klasse-A-Befehlsvorlage anzeigt, wählt der Inhalt des Modifiziererfelds 646 die Interpretation des Alpha-Felds 652 zwischen dem rs-Feld 652A und dem EH-Feld 652B. Auf verwandte Weise wählt der Inhalt des Modifiziererfelds 646 und des Klassefelds 668, ob das Alpha-Feld als rs-Feld 652A, EH-Feld 652B oder Schreibmaskensteuerungs-(Z-)Feld 652C interpretiert wird. In dem Fall, in dem das Klasse- und das Modifiziererfeld eine Klasse-A-Kein-Speicherzugriff-Operation anzeigen, verändert sich die Interpretation des Beta-Felds des Augmentationsfelds auf der Basis des Inhalts des rs-Felds; während in dem Fall, in dem das Klasse- und das Modifiziererfeld eine Klasse-B-Kein-Speicherzugriff-Operation anzeigen, die Interpretation des Beta-Felds vom Inhalt des RL-Felds abhängig ist. In dem Fall, in dem das Klasse- und das Modifiziererfeld eine Klasse-A-Speicherzugriffsoperation anzeigen, verändert sich die Interpretation des Beta-Felds des Augmentationsfelds auf der Basis des Inhalts des Operationsfelds; während sich in dem Fall, in dem das Klasse- und das Modifiziererfeld eine Klasse-B-Speicherzugriffsoperation anzeigen, die Interpretation des Sendefelds 657B des Beta-Felds des Augmentationsfelds auf der Basis des Inhalts des Basisoperationsfelds verändert. Somit ermöglicht die Kombination aus dem Basisoperationsfeld, dem Modifiziererfeld und dem Augmentationsoperationsfeld, dass eine noch größere Vielzahl von Augmentationsoperationen spezifiziert wird.
Die verschiedenen Befehlsvorlagen, die innerhalb der Klasse A und Klasse B zu finden sind, sind in verschiedenen Situationen nützlich. Klasse A ist nützlich, wenn eine Nullung-Schreibmaskierung oder kleinere Vektorlängen aus Leistungsgründen gewünscht sind. Zum Beispiel ermöglicht eine Nullung das Vermeiden von falschen Abhängigkeiten, wenn eine Umbenennung angewendet wird, da es nicht länger erforderlich ist, künstlich eine Zusammenfügung mit dem Ziel durchzuführen; als weiteres Beispiel werden durch die Vektorlängensteuerung Speicher-Lade-Übertragungsfragen vereinfacht bei der Emulierung von kürzeren Vektorgrößen mit der Vektormaske. Klasse B ist sinnvoll, wenn es wünschenswert ist: 1) Gleitkomma-Ausnahmen zu ermöglichen (d. h. wenn der Inhalt des SAE-Felds ein Nein anzeigt) bei gleichzeitiger Anwendung von Rundungsmodussteuerungen; 2) in der Lage zu sein, Aufwärtskonvertierung, Swizzling, Swap und/oder Abwärtskonvertierung anzuwenden; 3) anhand des Grafikdatentyps zu arbeiten. Zum Beispiel wird durch Aufwärtskonvertieren, Swizzling, Swap, Abwärtskonvertieren und den Grafikdatentyp die Anzahl von Befehlen verringert, die erforderlich sind, wenn mit Quellen in einem anderen Format gearbeitet wird; als weiteres Beispiel bietet die Fähigkeit zum Ermöglichen von Ausnahmen eine volle IEEE-Konformität mit gerichteten Rundungsmodi.
Beispielhaftes spezifisches vektorfreundliches Befehlsformat
7A–C sind Blockschaltbilder mit Darstellung eines beispielhaften spezifischen vektorfreundlichen Befehlsformats gemäß Ausführungsformen der Erfindung. 7A–C zeigen ein spezifisches vektorfreundliches Befehlsformat 700, das spezifisch in dem Sinn ist, dass es den Platz, die Größe, Interpretation und Reihenfolge der Felder sowie Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 700 kann zum Erweitern des x86-Befehlssatzes verwendet werden, und somit sind einige der Felder im Wesentlichen die gleichen oder die gleichen wie diejenigen, die in dem bestehenden x86-Befehlssatz und dessen Erweiterung (z. B. AVX) verwendet werden. Dieses Format bleibt mit dem Präfixkodierungsfeld, Real-Opcode-Byte-Feld, MOD R/M-Feld, SIB-Feld, Verschiebungsfeld und Direktwertfeldern des bestehenden x86-Befehlssatzes mit Erweiterungen konsistent. Die Felder von 6, in die die Felder aus 7A–C abgebildet werden, sind dargestellt.
Es versteht sich, dass zu Veranschaulichungszwecken Ausführungsformen der Erfindung zwar mit Bezug auf das spezifische vektorfreundliche Befehlsformat 700 im Kontext des generischen vektorfreundlichen Befehlsformats 600 beschrieben werden, die Erfindung jedoch nicht auf das spezifische vektorfreundliche Befehlsformat 700 beschränkt ist, es sei denn, dies wird beansprucht. Zum Beispiel zieht das generische vektorfreundliche Befehlsformat 600 eine Vielzahl von möglichen Größen für die verschiedenen Felder in Betracht, während das spezifische vektorfreundliche Befehlsformat 700 mit Feldern mit spezifischen Größen gezeigt ist. Bei einem spezifischen Beispiel ist das Datenelementbreitenfeld 664 zwar als Ein-Bit-Feld in dem spezifischen vektorfreundlichen Befehlsformat 700 dargestellt, die Erfindung ist jedoch nicht darauf beschränkt (das heißt, dass das generische vektorfreundliche Befehlsformat 600 andere Größen des Datenelementbreitenfelds 664 in Betracht zieht).
Format – Fig. 7A–C
Das generische vektorfreundliche Befehlsformat 600 weist die folgenden Felder auf, die nachstehend in der in 7A–C dargestellten Reihenfolge aufgeführt sind.
EVEX-Präfix (Bytes 0-3)
EVEX-Präfix 702 – ist in einer Vier-Bit-Form kodiert.
Formatfeld 640 (EVEX-Byte 0, Bits [7:0]) – das erste Byte (EVEX-Byte 0) ist das Formatfeld 640, und es enthält 0×62 (der einzigartige Wert, der bei einer Ausführungsform der Erfindung zum Unterscheiden des vektorfreundlichen Befehlsformats verwendet wird). Das zweite bis vierte Byte (EVEX-Bytes 1-3) weisen eine Anzahl von Bitfeldern auf, die eine spezifische Fähigkeit bieten.
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 657BEX-Byte 1, Bit[5]-B). Das EVEX.R-, das EVEX.X-, und das EVEX.B-Bitfeld bieten die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder und werden unter Verwendung einer 1 s-Komplement-Form kodiert, d. h. ZMM0 wird als 1111B kodiert, ZMM15 wird als 0000B kodiert. Weitere Felder der Befehle kodieren die unteren drei Bits der Registerindizes, wie auf dein Sachgebiet bekannt ist (rrr, xxx, und bbb), so dass Rrrr, Xxxx, und Bbbb durch Addieren von EVEX.R, EVEX.X, and EVEX.B gebildet werden können.
REX'-Feld 710 – dies ist der erste Teil des REX'-Felds 710 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit[4]-R'), das zum Kodieren von entweder den oberen 16 oder den unteren 16 des erweiterten 32-Registersatzes verwendet wird. Bei einer Ausführungsform der Erfindung wird dieses Bit zusammen mit anderen, wie nachstehend angezeigt ist, in einem bitinvertierten Format gespeichert zwecks Unterscheidung (in dem bekannten x86-32-Bit-Modus) von dem BOUND-Befehl, dessen Real-Opcode-Byte 62 ist, jedoch nicht in dem (nachstehend beschriebenen) MOD R/M-Feld den Wert 11 in dem MOD-Feld übernimmt; bei alternativen Ausführungsformen der Erfindung werden dieses und die anderen nachstehend angezeigten Bits nicht im invertierten Format gespeichert. Ein Wert 1 wird zum Kodieren der unteren 16 Register verwendet. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und der anderen RRR aus anderen Feldern gebildet.
Opcode-Abbildungsfeld 715 (EVEX-Byte 1, Bits[3:0]-mmmm) – sein Inhalt kodiert ein impliziertes führendes Opcode-Byte (0F, 0F38 oder 0F3).
Datenelementbreitenfeld 664 (EVEX-Byte 2, Bit[7]-W) – wird durch die Bezeichnung EVEX.W dargestellt. EVEX.W wird zum Definieren der Granularität des Datentyps (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente) verwendet.
EVEX.vvvv 720 (EVEX-Byte 2, Bits[6:3]-vvvv) – die Rolle von EVEX.vvvv kann folgendes umfassen: 1) EVEX.vvvv kodiert den ersten Quellregisteroperanden, der in invertierter (1 s-Komplement-)Form spezifiziert ist und für Befehle mit 2 oder mehr Quelloperanden gültig ist; 2) EVEX.vvvv kodiert den Zielregisteroperanden, der in 1 s-Komplement-Form für bestimmte Vektorverlagerungen spezifiziert ist; oder 3) EVEX.vvvv kodiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Somit kodiert das EVEX.vvvv-Feld 720 die 4 niederwertigen Bits des ersten Quellregisterspezifizierers, der in invertierter (1 s-Komplement-)Form gespeichert ist. In Abhängigkeit von dem Befehl wird ein zusätzliches anderes EVEX-Bitfeld zum Erweitern der Spezifizierergröße auf 32 Register verwendet.
EVEX.U- 668 Klassefeld (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äfixkodierungsfeld 725 (EVEX-Byte 2, Bits[1:0]-pp) – liefert weitere Bits für das Basisoperationsfeld. Zusätzlich zum Bieten von Unterstützung für die älteren SSE-Befehle im EVEX-Präfixformat bietet dies ferner den Vorteil des Kompaktierens des SIMD-Präfixes (statt ein Byte zum Ausdrücken des SIMD-Präfixes erforderlich zu machen, benötigt das EVEX-Präfix nur 2 Bits). Bei einer Ausführungsform werden zum Unterstützen von älteren SSE-Befehlen, die ein SIMD-Präfix (66H, F2H, F3H) sowohl im älteren Format als auch im EVEX-Präfix-Format verwenden, diese älteren SIMD-Präfixe in das SIMD-Präfix-Kodierungsfeld kodiert; und expandieren während der Laufzeit in das ältere SIMD-Präfix vor dem Liefern zu dem PLA des Dekodierers (so dass das PLA sowohl das ältere als auch das EVEX-Format dieser älteren Befehle ohne Modifikation ausführen kann). Obwohl neuere Befehle den Inhalt des EVEX-Präfix-Kodierungsfelds direkt als Opcode-Erweiterung verwenden können, expandieren bestimmte Ausführungsformen auf im Wesentlichen gleiche Weise aus Gründen der Beständigkeit, ermöglichen jedoch, dass diese älteren SIMD-Präfixe unterschiedliche Bedeutungen spezifizieren. Bei einer alternativen Ausführungsform kann das PLA neu ausgelegt werden, um die 2-Bit-SIMD-Präfixkodierungen zu unterstützen und somit keine Expandierung zu benötigen.
Alpha-Feld 652 (EVEX-Byte 3, Bit[7]-EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.-Schreibmaskensteuerung und EVEX.N; auch dargestellt durch a) – wie vorstehend beschrieben ist dieses Feld kontextspezifisch. Eine weitere Beschreibung folgt später.
Beta-Feld 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 worden ist, ist dieses Feld kontextspezifisch. Eine weitere Beschreibung folgt später.
REX'-Feld 710 – dies ist der Rest des REX'-Felds und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit[3]-V'), das zum Kodieren entweder der oberen 16 oder der unteren 16 des erweiterten 32-Registersatzes verwendet werden kann. Dieses Bit wird im bitinvertierten Format gespeichert. Ein Wert 1 wird zum Kodieren der unteren 16 Register verwendet. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
Schreibmaskenfeld 670 (EVEX-Byte 3, Bits[2:0]-kkk) – sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie vorstehend beschrieben worden ist. Bei einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk = 000 ein besonderes Verhalten auf, das impliziert, dass keine Schreibmaske für den besonderen Befehl verwendet wird (diese kann in einer Vielzahl von Arten implementiert sein, einschließlich der Verwendung einer Schreibmaske, die mit sämtlichen Einsen fest verschaltet ist, oder einer Hardware, die die Maskierungs-Hardware umgeht).
Real-Opcode-Feld 730 (Byte 4)
Dies ist auch als Opcode-Byte bekannt. 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 worden ist, unterscheidet der Inhalt des MOD-Felds 742 zwischen Speicherzugriff- und Kein-Speicherzugriff-Operationen. Dieses Feld wird später beschrieben.
MODR/M.reg-Feld 744, Bits[5-3] – die Rolle des ModR/M.reg-Felds kann zu zwei Situationen zusammengefasst werden: ModR/M.reg kodiert entweder den Zielregisteroperanden oder einen Quellregisteroperanden, oder ModR/M.reg wird als Opcode-Erweiterung behandelt und nicht zum Kodieren eines Befehlsoperanden verwendet.
MODR/M.r/m-Feld 746, Bits[2-0] – die Rolle des ModR/M.r/m-Felds kann folgendes umfassen: ModR/M.r/m kodiert den Befehlsoperanden, der eine Speicheradresse referenziert, oder ModR/M.r/m kodiert entweder den Zielregisteroperanden oder einen Quellregisteroperanden.
Skalen-Index-Basis-(SIB)Byte (Byte 6)
Skalenfeld 660 (SIB.SS, Bits[7-6] – wie vorstehend beschrieben worden ist, wird der Inhalt des Skalenfelds 660 für die Speicheradressenerzeugung verwendet. Dieses Feld wird später beschrieben.
SIB.xxx 754 (Bits[5-3] und SIB.bbb 756 (Bits [2-0]) – der Inhalt dieser Felder ist vorstehend hinsichtlich der Registerindizes Xxxx and Bbbb referenziert worden.
Verschiebungsbyte(s) (Byte 7 oder Bytes 7–10)
Verschiebungsfeld 662A (Bytes 7-10) – wenn das MOD-Feld 742 10 enthält, sind Bytes 7–10 das Verschiebungsfeld 662A, und es funktioniert auf die gleiche Weise wie die ältere 32-Bit-Verschiebung (disp32) und funktioniert bei einer Bytegranularität.
Verschiebungsfaktorfeld 662B (Byte 7) – wenn das MOD-Feld 742 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 662B. Der Platz dieses Felds ist der gleiche wie derjenige der älteren x86-Befehlssatz-8-Bit-Verschiebung (disp8), die bei einer Bytegranularität arbeitet. Da disp8 vorzeichenerweitert ist, kann es nur zwischen –128 und 127 Byte-Offsets adressieren; in Bezug auf 64-Byte-Cache-Lines verwendet disp8 8 Bits, die nur auf vier wirklich sinnvolle Werte –128, –64, 0 und 64 gesetzt werden können; da häufig ein größerer Bereich erforderlich ist, wird disp32 verwendet; disp32 benötigt jedoch 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 662B eine Neuinterpretation von disp8; bei Verwendung des Verschiebungsfaktorfelds 662B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Dieser Typ von Verschiebung wird als disp8*N bezeichnet. Dadurch wird die mittlere Befehlslänge verringert (ein einzelnes Byte wird für die Verschiebung verwendet, jedoch mit einem viel größeren Bereich). Eine solche komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Mehrfaches der Granularität des Speicherzugriffs ist und somit die redundanten niederwertigen Bits des Adressen-Offsets nicht kodiert zu werden brauchen. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 662B die ältere x86-Befehlssatz-8-Bit-Verschiebung. Somit wird das Verschiebungsfaktorfeld 662B auf die gleiche Weise kodiert wie eine x86-Befehlssatz-8-Bit-Verschiebung (somit keine Veränderungen bei den ModM/SIB-Kodierungsregeln), mit der einzigen Ausnahme, dass disp8 auf disp8*N überbelastet ist. Mit anderen Worten gibt es keine Veränderungen bei den Kodierungsregeln oder Kodierungslängen, sondern nur bei der Interpretation des Verschiebungswerts durch die Hardware (die zum Erhalten eines byteweisen Adressen-Offsets die Verschiebung mittels der Größe des Speicheroperanden skalieren muss).
Direktwert
Das Direktwertfeld 672 arbeitet wie vorstehend beschrieben.
Beispielhafte Registerarchitektur – Fig. 8

8 ist ein Blockschaltbild einer Registerarchitektur 800 gemäß einer Ausführungsform der Erfindung. Die Registerdateien und Register der Registerarchitektur sind nachstehend aufgeführt:
Vektorregisterdatei 810 – bei der dargestellten Ausführungsform gibt es 32 Vektorregister, die 812 Bit breit sind; diese Register werden als zmm0 bis zmm31 referenziert. Die niederwertigen 656 Bits der unteren 16 zmm-Register überlagern die Register ymm0–16. Die niederwertigen 128 Bits der unteren 16 zmm-Register (die niederwertigen 128 Bits der ymm-Register) überlagern die Register xmm0–15. Das spezifische vektorfreundliche Befehlsformat 700 arbeitet auf diesen überlagerten Registern, wie in den nachstehenden Tabellen dargestellt ist.

Einstellbare	Klasse	Operationen	Register
Vektorlänge Befehlsvorlagen, die kein Vektorlängenfeld 659B aufweisen	A (Fig. 6A; U = 0) B (Fig. 6B; U = 1)	810, 615, 625, 630 812	zmm-Register (die Vektorlänge beträgt 64 Byte) zmm-Register (die Vektorlänge beträgt 64 Byte)
Befehlsvorlagen, die das Vektorlängenfeld 659B aufweisen	B (Fig. 6B; U = 1)	817, 627	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) je nach Vektorlängenfeld 659B

Mit anderen Worten wählt das Vektorlängenfeld 659B zwischen einer maximalen Länge und einer oder mehreren kürzeren Längen, wobei jede solche kürzere Länge die halbe Länge der vorhergehenden Länge ist; und Befehlsvorlagen ohne das Vektorlängenfeld 659B arbeiten bei der maximalen Vektorlänge. Ferner arbeiten bei einer Ausführungsform die Klasse-B-Befehlsvorlagen des spezifischen vektorfreundlichen Befehlsformats 700 anhand von gepackten oder skalaren Gleitkommadaten mit einfacher/doppelter Genauigkeit und gepackten oder skalaren Ganzzahlendaten.
Skalaroperationen sind Operationen, die an der Position des niedrigstwertigen Datenelements in einem zmm/ymm/xmm-Register durchgeführt werden; die Positionen der höherwertigen Datenelemente bleiben je nach Ausführungsform entweder die gleichen, die sie vor dem Befehl waren, oder werden genullt.
Schreibmaskenregister 815 – bei der dargestellten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7) jeweils mit einer Größe von 64 Bit. Wie vorstehend beschrieben worden ist, kann bei einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als Schreibmaske verwendet werden; wenn die Kodierung, die normalerweise k0 anzeigen würde, für eine Schreibmaske verwendet wird, wird eine festverschaltete Schreibmaske mit 0xFFFF ausgewählt, wobei das Schreibmaskieren für diesen Befehl effektiv deaktiviert wird.
Multimedia Extensions-Steuerstatusregister (MXCSR) 820 – bei der dargestellten Ausführungsform stellt dieses 32-Bit-Register Status und Steuerbits bereit, die bei Gleitkommaoperationen verwendet werden.
Universalregister 825 – bei der dargestellten Ausführungsform gibt es sechszehn 64-Bit-Universalregister, die zum Adressieren der Speicheroperanden zusammen mit den bestehenden x86-Adressiermodi verwendet werden. Diese Register werden mit den Bezeichnungen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 referenziert.
Erweitert-Flags-(EFLAGS-)Register 830 – bei der dargestellten Ausführungsform wird das 32-Bit-Register zum Aufzeichnen der Ergebnisse von vielen Befehlen verwendet.
Gleitkomma-Steuerwort-(floating point control word – FCW-)Register 835 und Gleitkomma-Statuswort-(floating point status word – FSW-)Register 840 – bei der dargestellten Ausführungsform werden diese Register von x87-Befehlssatzerweiterungen verwendet, um Rundungsmodi, Ausnahmenmasken und Flags im Falle des FCW zu setzen und um Ausnahmen im Fall des FSW nachzuverfolgen.
Skalar-Gleitkomma-Stapelregisterdatei (x87-Stapel) 845, auf der die MMX-Gepackt-Ganzzahlen-Flachregisterdatei 850 einem Aliasing unterzogen wird – bei der dargestellten Ausführungsform ist der x87-Stapel ein Acht-Element-Stapel, der zum Durchführen von Skalar-Gleitkomma-Operationen auf 32-/64-/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzerweiterung verwendet wird; während die MMX-Register zum Durchführen von Operationen an gepackten 64-Bit-Ganzzahlendaten sowie zum Halten von Operanden für einige Operationen, die zwischen den MMX- und XMM-Registern durchgeführt werden, verwendet werden.
Segmentregister 855 – bei der dargestellten Ausführungsform gibt es sechs 16-Bit-Register, die zum Speichern von Daten verwendet werden, welche zur Erzeugung von segmentierten Adressen verwendet werden.
RIP-Register 865 – bei der dargestellten Ausführungsform speichert dieses 64-Bit-Register den Befehlszeiger.
Bei alternativen Ausführungsformen der Erfindung können breitere oder schmalere Register verwendet werden. Des Weiteren können bei alternativen Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwendet werden.
Beispielhafte In-Order Prozessor Architektur – Fig. 9A–Fig. 9B
9A–B zeigen ein Blockschaltbild einer beispielhaften In-Order-Prozessor-Architektur. Diese beispielhaften Ausführungsformen sind um mehrere Instanziierungen eines In-Order-CPU-Kerns herum ausgelegt, der mit einem Breitvektorprozessor (VPU) augmentiert ist. Kerne kommunizieren über ein Zwischenverbindungsnetz mit hoher Bandbreite mit Festfunktionslogik, Speicher-I/O-Schnittstellen und einer weiteren erforderlichen I/O-Logik in Abhängigkeit von der e13t-Anwendung. Zum Beispiel würde eine Implementierung dieser Ausführungsform als eigenständige GPU typischerweise einen PCIe-Bus aufweisen.
9A ist ein Blockschaltbild eines Einzel-CPU-Kerns zusammen mit seiner Verbindung mit dem auf dem Die befindlichen Zwischenverbindungsnetz 902 und mit seinem lokalen Teilsatz des Level-2-(L2-)Caches 904 gemäß Ausführungsformen der Erfindung. Ein Befehlsdekodierer 900 unterstützt den x86-Befehlssatz mit einer Erweiterung, die das spezifische Vektorbefehlsformat 700 aufweist. Obwohl bei einer Ausführungsform der Erfindung (zum Vereinfachen der Auslegung) eine Skalareinheit 908 und eine Vektoreinheit 910 separate Registersätze (jeweils Skalarregister 912 und Vektorregister 914) verwenden und Daten, die zwischen diesen übertragen werden, in den Speicher geschrieben werden und dann aus einem Level-1-(L1-)Cache 906 ausgelesen werden, kann bei alternativen Ausführungsformen der Erfindung eine andere Vorgehensweise angewendet werden (z. B. Verwendung eines einzelnen Registersatzes oder Aufnehmen eines Kommunikationswegs, der ermöglicht, dass Daten zwischen den zwei Registerdateien übertragen werden, ohne geschrieben und ausgelesen zu werden).
Der L1-Cache 906 ermöglicht Zugriffe mit niedriger Latenz auf den Cachespeicher in Skalar- und Vektoreinheiten. Zusammen mit Ladeoperationsbefehlen im vektorfreundlichen Befehlsformat bedeutet dies, dass das L1-Cache 906 in gewissem Maß wie eine erweiterte Registerdatei behandelt werden kann. Dadurch wird die Leistung von vielen Algorithmen signifikant verbessert, insbesondere mit dem Räumungshinweisfeld 652B.
Der lokale Teilsatz des L2-Caches 904 ist Teil eines globalen L2-Caches, das in separate lokale Teilsätze unterteilt ist, und zwar einen pro CPU-Kern. Jede CPU weist einen Direktzugriffsweg auf ihren eigenen lokalen Teilsatz des L2-Caches 904 auf. Daten, die von einem CPU-Kern gelesen werden, werden in seinem L2-Cache-Teilsatz 904 gespeichert, und es kann schnell auf diese zugegriffen werden, und zwar parallel zum Zugriff durch andere CPUs auf deren eigene L2-Cache-Teilsätze. Daten, die von einem CPU-Kern geschrieben werden, werden in dessen eigenem L2-Cache-Teilsatz 904 gespeichert und, falls erforderlich, aus anderen Teilsätzen eliminiert. Das Ringnetz stellt eine Kohärenz für gemeinsam genutzte Daten sicher.
9B ist eine Explosionsansicht eines Teils des CPU-Kerns in 9A gemäß Ausführungsformen der Erfindung. 9B umfasst einen L1-Datencache- 906A Teil des L1-Caches 904 sowie mehr Details bezüglich der Vektoreinheit 910 und der Vektorregister 914. Insbesondere ist die Vektoreinheit 910 eine 16-breite Vektorverarbeitungseinheit (vector processing unit – VPU) (siehe 16-breite ALU 928), die Ganzzahlen-, Gleitkommazahlen-Befehle mit einfacher Genauigkeit und doppelter Genauigkeit verarbeitet. Die VPU unterstützt das Swizzling der Registereingänge mit einer Swizzle-Einheit 920, eine nummerische Umwandlung mit Nummerisch-Umwandlungs-Einheiten 922A–B und eine Replikation mit einer Replikationseinheit 924 am Speichereingang. Schreibmaskenregister 926 ermöglichen ein Prädizieren der daraus resultierenden Vektorschreibungen.
Die Registerdaten können auf eine Vielzahl von Arten einem Swizzling unterzogen werden, z. B. um eine Matrixmultiplikation zu unterstützen. Die Daten aus dem Speicher können über die VPU-Spuren repliziert werden. Dies ist eine gängige Operation sowohl bei der parallelen Grafik- als auch der Nicht-Grafik-Datenverarbeitung, durch die die Cache-Effizienz signifikant erhöht wird.
Das Ringnetz ist bidirektional, um es Agenten, wie z. B. CPU-Kernen, L2-Caches und anderen logischen Blöcken zu ermöglichen, innerhalb des Chips miteinander zu kommunizieren. Jeder Ring-Datenweg ist pro Richtung 812 Bit breit.
Beispielhafte Out-of-Order-Architektur – Fig. 10
10 ist ein Blockschaltbild mit Darstellung einer beispielhaften Out-of-Order-Architektur gemäß Ausführungsformen der Erfindung und kann als spezifischere Beschreibung einer Pipeline, wie z. B. der oben mit Bezug auf 1 diskutierten Pipeline, angesehen werden. Insbesondere zeigt 10 eine bekannte beispielhafte Out-of-Order-Architektur, die modifiziert worden ist, damit sie das vektorfreundliche Befehlsformat und dessen Ausführung integriert. In 10 zeigen Pfeile eine Kopplung zwischen zwei oder mehr Einheiten, und die Richtung des Pfeils zeigt eine Richtung des Datenflusses zwischen diesen Einheiten. 10 umfasst eine Front-End-Einheit 1005, die mit einer Ausführungsmaschineneinheit 1010 und einer Speichereinheit 1015 gekoppelt ist; die Ausführungsmaschineneinheit 1010 ist ferner mit der Speichereinheit 1015 gekoppelt.
Die Front-End-Einheit 1005 weist eine Level-1-(L1-)Verzweigungsvorhersageeinheit 1020 auf, die mit einer Level-2-(L2-)Verzweigungsvorhersageeinheit 1022 gekoppelt ist. Die L1- und L2-Verzweigungsvorhersageeinheiten 1020 und 1022 sind mit einer L1-Befehls-Cacheeinheit 1024 gekoppelt. Die L1-Befehls-Cacheeinheit 1024 ist mit einem Befehlsübersetzungs-Lookaside-Puffer (translation lookaside buffer – TLB) 1026 gekoppelt, der ferner mit einer Befehlsabruf- und -vordekodierungseinheit 1028 gekoppelt ist. Die Befehlsabruf- und -vordekodierungseinheit 1028 ist mit einer Befehls-Warteschlangeneinheit 1030 gekoppelt, die ferner mit einer Dekodierungseinheit 1032 gekoppelt ist. Die Dekodierungseinheit 1032 umfasst eine komplexe Dekodierungseinheit 1034 und drei einfache Dekodierungseinheiten 1036, 1038 und 1040. Die Dekodierungseinheit 1032 weist eine Mikrocode-ROM-Einheit 1042 auf. Die Dekodierungseinheit 1032 kann so arbeiten, wie vorstehend in dem Dekodierungsstufenabschnitt beschrieben worden ist. Die L1-Befehls-Cacheeinheit 1024 ist ferner mit einer L2-Cacheeinheit 1048 in der Speichereinheit 1015 gekoppelt. Die Befehls-TLB-Einheit 1026 ist ferner mit einer TLB-Einheit 1046 des zweiten Levels in der Speichereinheit 1015 gekoppelt. Die Dekodierungseinheit 1032, die Mikrocode-ROM-Einheit 1042 und eine Loop-Stream-Detektoreinheit 1044 sind jeweils mit einer Umbenennungs-/Zuteilereinheit 1056 in der Ausführungsmaschineneinheit 1010 gekoppelt.
Die Ausführungsmaschineneinheit 1010 weist die Umbenennungs-/Zuteilereinheit 1056 auf, die mit einer Rückzugseinheit 1074 und einer Einheits-Schedulereinheit 1058 gekoppelt ist. Die Rückzugseinheit 1074 ist ferner mit Ausführungseinheiten 1060 gekoppelt und weist einen Neuordnungspuffer 1078 auf. Die Einheits-Schedulereinheit 1058 ist ferner mit einer Physikalisch-Registerdateien-Einheit 1076 gekoppelt, die mit den Ausführungseinheiten 1060 gekoppelt it. Die Physikalisch-Registerdateien-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 Physikalisch-Registerdateien-Einheit 1076 kann weitere nicht gezeigte Registerdateien (z. B. die Skalar-Gleitkomma-Stapelregisterdatei 845, die auf der MMX-Gepackt-Ganzzahlen-Flachregisterdatei 850 einem Aliasing unterzogen wird) aufweisen. Die Ausführungseinheiten 1060 weisen drei gemischte Skalar- und Vektoreinheiten 1062, 1064 und 1072; eine Ladeeinheit 1066; eine Speicheradresseneinheit 1068; eine Speicherdateneinheit 1070 auf. Die Ladeeinheit 1066, die Speicheradresseneinheit 1068 und die Speicherdateneinheit 1070 sind jeweils ferner mit einer Daten-TLB-Einheit 1052 in der Speichereinheit 1015 gekoppelt.
Die Speichereinheit 1015 weist die TLB-Einheit 1046 des zweiten Levels auf, die mit der Daten-TLB-Einheit 1052 gekoppelt ist. Die Daten-TLB-Einheit 1052 ist mit einer L1-Daten-Cacheeinheit 1054 gekoppelt. Die L1-Daten-Cacheeinheit 1054 ist ferner mit einer L2-Cacheeinheit 1048 gekoppelt. Bei einigen Ausführungsformen ist die L2-Cacheeinheit 1048 ferner mit L3- und höheren Cacheeinheiten 1050 innerhalb und/oder außerhalb der Speichereinheit 1015 gekoppelt.
Die beispielhafte Out-of-Order-Architektur kann beispielhaft die Prozess-Pipeline 8200 wie folgt implementieren: 1) die Befehlsabruf- und -vordekodierungseinheit 1028 führt die Abruf- und Längendekodierungsstufen durch; 2) die Dekodierungseinheit 1032 führt die Dekodierungsstufe durch; 3) die Umbenennungs-/Zuteilereinheit 1056 führt die Zuteilungsstufe und die Umbenennungsstufe durch; 4) der Einheits-Scheduler 1058 führt die Schedulingstufe durch; 5) die Physikalisch-Registerdateien-Einheit 1076, die Neuordnungspuffereinheit 1078 und die Speichereinheit 1015 führen die Registerlese-/Speicherlesestufe durch; die Ausführungseinheiten 1060 führen die Ausführungs-/Datenübertragungsstufen durch; 6) die Speichereinheit 1015 und die Neuordnungspuffereinheit 1078 führen die Rückschreibe-/Speicherschreibestufe durch; 7) die Rückzugseinheit 1074 führt die ROB-Lesestufe durch; 8) verschiedene Einheiten können in die Ausnahmehandhabungsstufe eingebunden sein; und 9) die Rückzugseinheit 1074 und die Physikalisch-Registerdateien-Einheit 1076 führen die Commitstufe durch.
Beispielhafte Einzelkern- und Multikernprozessoren – Fig. 15
15 ist ein Blockschaltbild eines Einzelkernprozessors und eines Multikernprozessors 1500 mit einem Integriert-Speicher-Controller und -Grafik gemäß Ausführungsformen der Erfindung. Die in durchgezogenen Linien dargestellten Kästchen in 15 zeigen einen Prozessor 1500 mit einem Einzelkern 1502A, einem Systemagenten 1510, einem Satz von einer oder mehreren Bus-Controller-Einheiten 1516, während die wahlweise hinzugefügten, in gestrichelten Linien dargestellten Kästchen einen alternativen Prozessor 1500 mit mehreren Kernen 1502A–N, einem Satz von einer oder mehreren Integriert-Speicher-Controller-Einheit(en) 1514 in der Systemagenteneinheit 1510 und einer Integriert-Grafik-Logik 1508 zeigen.
Die Speicherhierarchie weist einen oder mehrere Cache-Levels innerhalb der Kerne, einen Satz oder einen oder mehrere gemeinsam genutzte Cacheeinheiten 1506 und einen (nicht gezeigten) externen Speicher, der mit dem Satz von Integriert-Speicher-Controller-Einheiten 1514 gekoppelt ist, auf. Der Satz von gemeinsam genutzten Cacheeinheiten 1506 kann einen oder mehrere Caches auf mittlerem Level, wie z. B. Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Levels, einen Cache eines letzten Levels (last level cache – LLC) und/oder Kombinationen daraus aufweisen. Obwohl bei einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 1512 die Integriert-Grafik-Logik 1508, den Satz von gemeinsam genutzten Cacheeinheiten 1506 und die Systemagenteneinheit 1510 miteinander verbindet, kann bei alternativen Ausführungsformen jede Anzahl von bekannten Techniken zum Verbinden solcher Einheiten angewendet werden.
Bei einigen Ausführungsformen sind ein oder mehrere der Kerne 1502A–N multithreadingfähig. Der Systemagent 1510 weist diejenigen Komponenten auf, die die Kerne 1502A–N koordinieren und betreiben. Die Systemagenteneinheit 1510 kann zum Beispiel eine Energiesteuereinheit (power control unit – PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann aus einer Logik und Komponenten gebildet sein oder diese aufweisen, die zum Regeln des Energiezustands der Kerne 1502A–N und der Integriert-Grafik-Logik 1508 benötigt werden. Die Anzeigeeinheit dient zum Treiben einer oder mehrerer extern verbundener Anzeigen.
Die Kerne 1502A–N können hinsichtlich der Architektur und/oder des Befehlssatzes homogen oder heterogen sein. Zum Beispiel können einige der Kerne 1502A–N In-Order sein (wie z. B. derjenige, der in 9A und 9B gezeigt ist), während andere Out-of-Order sein können (wie z. B. derjenige, der in 10 gezeigt ist). Als weiteres Beispiel können zwei oder mehr der Kerne 1502A–N in der Lage sein, den gleichen Befehlssatz auszuführen, während andere in der Lage sein können, nur einen Teilsatz des Befehlssatzes oder einen anderen Befehlssatz auszuführen. Mindestens einer der Kerne ist in der Lage, das hier beschriebene vektorfreundliche Befehlsformat auszuführen.
Der Prozessor kann ein Universalprozessor, wie z. B. ein Core^TM i3-, i5-, i7-, 2 Duo- und Quad-, Xeon^TM- oder Itanium^TM-Prozessor sein, der von Intel Corporation, Santa Clara, Calif. erhältlich ist Alternativ kann der Prozessor von einer anderen Firma stammen. Der Prozessor kann ein Spezialprozessor, wie zum Beispiel ein Netz- oder Kommunikationsprozessor, eine Komprimierungsmaschine, ein Grafikprozessor, Koprozessor, eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 1500 kann Teil eines oder mehrerer Substrate sein oder kann unter Anwendung einer Anzahl von Prozesstechnologien, wie zum Beispiel BiCMOS, CMOS oder NMOS, in diese implementiert werden.
Beispielhafte Computersysteme und Prozessoren – Fig. 11–Fig. 13
11–13 sind beispielhafte Systeme, die zum Aufnehmen des Prozessors 1500 geeignet sind, während 88 ein beispielhaftes System-on-Chip (SoC) zeigt, das einen oder mehrere der Kerne 1502 aufweisen kann. Andere Systemauslegungen und -konfigurationen, die auf dem Sachgebiet für Laptops, Desktops, Handheld-PCs, persönliche digitale Assistenten, Konstruktionsarbeitsstationen, Server, Netzvorrichtungen, Netz-Hubs, Schalter, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienplayer, Handheld-Vorrichtungen und verschiedene andere elektronische Vorrichtungen bekannt sind, sind ebenfalls geeignet. Generell ist eine große Vielzahl von Systemen oder elektronischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder eine andere Ausführungslogik, die hier offengelegt ist, aufzunehmen, allgemein geeignet.
11 zeigt ein Blockschaltbild eines Systems 1100 gemäß einer Ausführungsform der Erfindung. Das System 1100 kann einen oder mehrere Prozessoren 1110, 1115 aufweisen, die mit einem Grafikspeicher-Controller-Hub (graphics memory controller hub – GMCH) 1120 gekoppelt sind. Die optionale Natur von zusätzlichen Prozessoren 1115 ist in 11 durch gestrichelte Linien dargestellt.
Jeder Prozessor 1110, 1115 kann eine bestimmte Version des Prozessors 1500 sein. Es sei jedoch darauf hingewiesen, dass es unwahrscheinlich ist, dass die Integriert-Grafik-Logik und die Integriert-Speicher-Steuereinheiten in den Prozessoren 1110, 1115 vorhanden sind.
11 zeigt, dass der GMCH 1120 mit einem Speicher 1140 gekoppelt sein kann, der zum Beispiel ein dynamischer Schreib-/Lesespeicher (dynamic random access memory – DRAM) sein kann. Der DRAM kann bei mindestens einer Ausführungsform einem nichtflüchtigen Cache zugeordnet sein.
Der GMCH 1120 kann ein Chipsatz oder ein Abschnitt eines Chipsatzes sein. Der GMCH 1120 kann mit dem (den) Prozessor(en) 1110, 1115 kommunizieren und eine Interaktion zwischen dem (den) Prozessor(en) 1110, 1115 und dem Speicher 1140 steuern. Der GMCH 1120 kann ferner als beschleunigte Busschnittstelle zwischen dem (den) Prozessor(en) 1110, 1115 und anderen Elementen des Systems 1100 dienen. Bei mindestens einer Ausführungsform kommuniziert der GMCH 1120 über einen Mehrpunktbus, wie z. B. einen Frontside-Bus (FSB) 1195, mit dem (den) Prozessor(en) 1110, 1115.
Ferner ist der GMCH 1120 mit einer Anzeige 1145 (wie z. B. einen Flachbildschirm) gekoppelt. Der GMCH 1120 kann einen Integriert-Grafik-Beschleuniger aufweisen. Der GMCH 1120 ist ferner mit einem Eingangs-/Ausgangs-(input/output – I/O-)Controller-Hub (ICH) 1150 gekoppelt, der verwendet werden kann, um verschiedene Peripherievorrichtungen mit dem System 1100 zu koppeln. Zum Beispiel ist bei der Ausführungsform von 11 eine externe Grafikvorrichtung 1160 gezeigt, die eine diskrete Grafikvorrichtung sein kann, welche zusammen mit einer weiteren Peripherievorrichtung 1170 mit dem ICH 1150 gekoppelt sein kann.
Alternative, weitere oder andere Prozessoren können ebenfalls in dem System 1100 vorhanden sein. Zum Beispiel kann (können) (ein) weitere(r) Prozessor(en) 1115 (einen) weitere(n) Prozessor(en), der (die) der (die) gleiche(n) ist (sind) wie der Prozessor 1110, (einen) weitere(n) Prozessor(en), der (die) heterogen oder asymmetrisch zu dem Prozessor 1110 ist (sind), Beschleuniger (wie z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungs-(DSP-)Einheiten), feldprogrammierbare Gate-Arrays oder jeden anderen Prozessor aufweisen. Es kann hinsichtlich eines Metrics-of-Merit-Spektrums einschließlich architektonischer, mikroarchitektonischer, Wärme-, Energieverbrauchs-Charakteristiken oder dergleichen eine Vielzahl von Unterschieden zwischen den physikalischen Ressourcen 1110, 1115 geben. Diese Unterschiede können sich effektiv als Asymmetrie und Heterogenität zwischen den Verarbeitungselementen 1110, 1115 manifestieren. Bei mindestens einer Ausführungsform können sich die verschiedenen Verarbeitungselemente 1110, 1115 in derselben Die-Packung befinden.
12 zeigt ein Blockschaltbild eines zweiten Systems 1200 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie in 12 gezeigt ist, ist ein Multiprozessorsystem 1200 ein Punkt-zu-Punkt-Zwischenverbindungssystem und weist einen ersten Prozessor 1270 und einen zweiten Prozessor 1280 auf, die über eine Punkt-zu-Punkt-Zwischenverbindung 1250 miteinander gekoppelt sind. Wie in 12 gezeigt ist, kann jeder der Prozessoren 1270 und 1280 eine bestimmte Version des Prozessors 1500 sein.
Alternativ können ein oder mehrere Prozessoren 1270, 1280 ein anderes Element als ein Prozessor sein, wie z. B. ein Beschleuniger oder ein feldprogrammierbares Gate-Array.
Obwohl nur zwei Prozessoren 1270, 1280 gezeigt sind, versteht sich, dass der Umfang der vorliegenden Erfindung nicht darauf beschränkt ist. Bei anderen Ausführungsformen können ein oder mehrere weitere Verarbeitungselemente in einem vorgegebenen Prozessor vorhanden sein.
Der Prozessor 1270 kann ferner einen Integriert-Speicher-Controller-Hub (integrated memory controller – IMC) 1272 und Punkt-zu-Punkt-(P-P-)Schnittstellen 1276 und 1278 aufweisen. Auf im Wesentlichen gleiche Weise kann der zweite Prozessor 1280 einen IMC 1282 und P-P-Schnittstellen 1286 und 1288 aufweisen. Die Prozessoren 1270, 1280 können Daten über eine Punkt-zu-Punkt-(P-P-)Schnittstelle 1250 unter Verwendung von P-P-Schnittstellenschaltungen 1278, 1288 austauschen. Wie in 12 gezeigt ist, koppeln die IMCs 1272 und 1282 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 1242 und einem Speicher 1244, die Abschnitte eines Hauptspeichers sein können, der lokal an die jeweiligen Prozessoren angeschlossen ist.
Die Prozessoren 1270, 1280 können Daten über einzelne P-P-Schnittstellen 1252, 1254 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1276, 1294, 1286, 1298 mit einem Chipsatz 1290 austauschen. Der Chipsatz 1290 kann ferner Daten über eine Hochleistungs-Grafikschnittstelle 1239 mit einer Hochleistungs-Grafikschaltung 1238 austauschen.
Ein (nicht gezeigter) gemeinsam genutzter Cache kann in jedem der zwei Prozessoren oder außerhalb der beiden Prozessoren vorgesehen sein, jedoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, so dass Lokal-Cache-Informationen einer der zwei oder beider Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, falls ein Prozessor in einen Niederenergiemodus gesetzt ist.
Der Chipsatz 1290 kann über eine Schnittstelle 1296 mit einem ersten Bus 1216 gekoppelt sein. Bei einer Ausführungsform kann der erste Bus 1216 ein Peripheriekomponenten-Zwischenverbindungs-(Peripheral Component Interconnect – PCI-)Bus oder ein Bus, wie z. B. ein PCI-Express-Bus oder ein anderer I/O-Zwischenverbindungsbus der dritten Generation sein, obwohl der Umfang der vorliegenden Erfindung nicht darauf beschränkt ist.
Wie in 12 gezeigt ist, können verschiedene I/O-Vorrichtungen 1214 mit dem ersten Bus 1216 gekoppelt sein, und zwar zusammen mit einer Busbrücke 1218, die den ersten Bus 1216 mit einem zweiten Bus 1220 koppelt. Bei einer Ausführungsform kann der zweite Bus 1220 ein Low-Pin-Count-(LPC-)Bus sein. Verschiedene Vorrichtungen können bei einer Ausführungsform mit dem zweiten Bus 1220 gekoppelt sein, einschließlich zum Beispiel einer Tastatur/Maus 1222, Kommunikationsvorrichtungen 1226 und einer Datenspeicherungseinheit 1228, wie z. B. eines Diskettenlaufwerks oder einer anderen Massenspeicherungsvorrichtung, die einen Code 1230 aufweisen kann. Es sei darauf hingewiesen, dass andere Architekturen möglich sind. Zum Beispiel kann anstelle der Punkt-zu-Punkt-Architektur von 12 ein System einen Mehrpunktbus oder eine andere derartige Architektur implementieren.
13 zeigt ein Blockschaltbild eines dritten Systems 1300 gemäß einer Ausführungsform der vorliegenden Erfindung. Gleiche Elemente in 12 und 13 sind mit gleichen Bezugszeichen bezeichnet, und bestimmte Aspekte von 12 sind in 13 weggelassen worden, um zu vermeiden, dass andere Aspekte von 13 nicht klar ersichtlich sind.
13 zeigt, dass die Verarbeitungselemente 1270, 1280 eine Integriert-Speicher- und I/O-Steuerlogik (control logic – ”CL”) 1272 bzw. 1282 aufweisen können. Bei mindestens einer Ausführungsform kann die CL 1272, 1282 eine Speicher-Controller-Hub-Logik (IMC) aufweisen, wie z. B. diejenige, die oben in Verbindung mit 89 und 12 beschrieben worden ist. Des Weiteren kann die CL 1272, 1282 ferner eine I/O-Steuerlogik aufweisen. 13 zeigt, dass nicht nur die Speicher 1242, 1244 mit der CL 1272, 1282 gekoppelt sind, sondern dass auch I/O-Vorrichtungen 1314 ebenfalls mit der Steuerlogik 1272, 1282 gekoppelt sind. Ältere I/O-Vorrichtungen 1315 sind mit dem Chipsatz 1290 gekoppelt.
14 zeigt ein Blockschaltbild eines SoC 1400 gemäß einer Ausführungsform der vorliegenden Erfindung. Im Wesentlichen gleiche Elemente in 14 sind mit gleichen Bezugszeichen bezeichnet. Ferner sind in gestrichelten Linien dargestellte Kästchen optionale Merkmale weiterentwickelter SoCs. In 14 ist (sind) (eine) Zwischenverbindungseinheit(en) 1402 gekoppelt mit: einem Anwendungsprozessor 1410, der einen Satz von einem oder mehreren Kernen 1502A–N und (eine) gemeinsam genutzte Cacheeinheit(en) 1506 aufweist; einer Systemagenteneinheit 1510; (einer) Bus-Controller-Einheit(en) 1516; (einer) Integriert-Speicher-Controller-Einheit(en) 1514; einem Satz oder einen oder mehrere Prozessoren 1420, der eine Integriert-Grafik-Logik 1508, einen Bildprozessor 1424 zum Bereitstellen einer Stand- und/oder Videobild-Kamerafunktionalität, einen Audioprozessor 1426 zum Bereitstellen einer Hardware-Audio-Beschleunigung und einen Videoprozessor 1428 zum Bereitstellen einer Video-Kodierungs-/Dekodierungs-Beschleunigung aufweisen kann; eine Statisch-Schreib-/Lesespeicher-(SRAM-)Einheit 1430; eine Direktspeicherzugriffs-(direct memory access – DMA-)Einheit 1432; und eine Anzeigeeinheit 1440 zum Koppeln mit einer oder mehreren externen Anzeigen.
Ausführungsformen der hier offengelegten Mechanismen können in Hardware, Software, Firmware oder einer Kombination aus solchen Implementierungsarten implementiert sein. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert sein, der auf programmierbaren Systemen arbeitet, die mindestens einen Prozessor, ein Speicherungssystem (einschließlich flüchtiger und nichtflüchtiger Speicher- und/oder Speicherungselementen), mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung umfasst.
Der Programmcode kann auf Eingangsdaten angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgangsinformationen zu erzeugen. Die Ausgangsinformationen können auf bekannte Weise bei einer oder mehreren Ausgangsvorrichtungen angewendet werden.
Zum Zweck dieser Anmeldung umfasst ein Verarbeitungssystem jedes System, das einen Prozessor aufweist, wie zum Beispiel: einen Digitalsignalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (application specific integrated circuit – ASIC) oder einen Mikroprozessor.
Der Programmcode kann zum Kommunizieren mit einem Verarbeitungssystem in einer höheren verfahrens- oder objektorientierten Programmiersprache implementiert sein. Der Programmcode kann ferner, falls gewünscht, in einer Assembler- oder Maschinensprache implementiert sein. Die hier beschriebenen Mechanismen sind in ihrem Umfang nicht auf eine besondere Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Ein oder mehrere Aspekte mindestens einer Ausführungsform können mittels charakteristischer Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das eine unterschiedliche Logik in dem Prozessor darstellt und das, wenn es von einer Maschine gelesen wird, bewirkt, dass die Maschine eine Logik zum Durchführen der hier beschriebenen Techniken herstellt. Solche Verkörperungen, die als ”IP-Kerne” bekannt sind, können auf einem realen maschinenlesbaren Medium gespeichert werden und zu verschiedenen Kunden oder Herstellanlagen zwecks Ladens in die Fertigungsmaschinen, die die Logik oder den Prozessor tatsächlich herstellen, geliefert werden.
Solche maschinenlesbaren Speichermedien können umfassen, sind jedoch nicht beschränkt auf nichttransitorische reale Anordnungen von Artikeln, die von einer Maschine oder Vorrichtung hergestellt oder ausgebildet werden, einschließlich Speicherungsmedien, wie z. B. Festplatten, jeden anderen Typ von Platte, einschließlich Floppy Disks, optische Platten, Kompaktdisketten-Nurlesespeicher (compact disc read-only memories – CD-ROMs), wiederbeschreibbare Kompaktdisketten (compact disk rewritables – CD-RWs) und magnetooptische Platten, Halbleitervorrichtungen, wie z. B. Nurlesespeicher (ROMs), Schreib-/Lesespeicher (RAMs), wie z. B. dynamische Schreib-/Lesespeicher (DRAMs), statische Schreib-/Lesespeicher (SRAMs), löschbare programmierbare Nurlesespeicher (erasable programmable read-only memories – EPROMs), Flashspeicher, elektrisch löschbare programmierbare Nurlesespeicher (electrically erasable programmable read-only memories – EEPROMSs), magnetische oder optische Karten und jeden anderen Typ von Medien, der zum Speichern von elektronischen Befehlen geeignet ist.
Entsprechend umfassen Ausführungsformen der Erfindung ferner nichttransitorische reale maschinenlesbare Medien, die Befehle im vektorfreundlichen Befehlsformat enthalten oder Auslegungsdaten enthalten, wie z. B. Hardwarebeschreibungssprache (Hardware Description Language – HDL), die hier beschriebene Strukturen, Schaltungen, Einrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
In einigen Fällen kann ein Befehlsumwandler zum Umwandeln eines Befehls aus einem Quellbefehlssatz in einen Zielbefehlssatz verwendet werden. Zum Beispiel kann der Befehlsumwandler einen Befehl (z. B. unter Anwendung einer statischen binären Übersetzung, einer dynamischen binären Übersetzung einschließlich einer dynamischer Kompilation) übersetzen, morphen, emulieren oder anderweitig in einen oder mehrere andere Befehle umwandeln, die von dem Kern zu verarbeiten sind. Der Befehlsumwandler kann in der Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlsumwandler kann sich auf einem Prozessor, außerhalb eines Prozessors oder teilweise auf einem und teilweise außerhalb eines Prozessor(s) befinden.
16 ist ein Blockschaltbild zur Gegenüberstellung der Verwendung eines Software-Befehlsumwandlers zum Umwandeln von binären Befehlen in einen Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung. Bei der dargestellten Ausführungsform ist der Befehlsumwandler ein Software-Befehlsumwandler, obwohl alternativ der Befehlsumwandler in der Software, Firmware, Hardware oder verschiedenen Kombinationen daraus implementiert sein kann. 16 zeigt, dass ein Programm in einer Hochsprache 1602 unter Verwendung eines x86-Kompilierers 1604 kompiliert werden kann, um einen x86-Binärcode 1606 zu erzeugen, der von einem Prozessor mit mindestens einem x86-Befehlssatzkern 1616 nativ ausgeführt werden kann (es wird angenommen, dass einige der Befehle, die kompiliert worden sind, das vektorfreundliche Befehlsformat aufweisen). Der Prozessor mit mindestens einem x86-Befehlssatzkern 1616 stellt jeden Prozessor dar, der im Wesentlichen die gleichen Funktionen durchführen kann wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern, und zwar durch kompatibles Ausführen oder anderweitiges Verarbeiten (1) eines wesentlichen Abschnitts des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder einer anderen Software, die dazu vorgesehen sind, auf einem Intel-Prozessor mit mindestens einem x86-Befehlssatzkern zu laufen, um im Wesentlichen das gleiche Ergebnis zu erzielen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern. Der x86-Kompilierer 1604 stellt einen Kompilierer dar, der so ausgelegt ist, dass er einen x86-Binärcode 1606 (z. B. Objektcode) erzeugt, der mit oder ohne weitere Verknüpfungsverarbeitung auf dem Prozessor mit dem mindestens einen x86-Befehlssatzkern 1616 ausgeführt werden kann. Auf im Wesentlichen gleiche Weise zeigt 90, dass das Programm in der Hochsprache 1602 unter Verwendung eines Alternativ-Befehlssatz-Kompilierers 1608 kompiliert werden kann, um einen Alternativ-Befehlssatz-Binärcode 1610 zu erzeugen, der von einem Prozessor ohne mindestens einen x86-Befehlssatzkern 1614 (z. B. einem Prozessor mit Kernen, die einen MIPS-Befehlssatz von MIPS Technologies, Sunnyvale, CA, ausführen und/oder den ARM-Befehlssatz von ARM Holding, Sunnyvale, CA ausführen) nativ ausgeführt werden kann. Der Befehlsumwandler 1612 wird verwendet, um den x86-Binärcode 1606 in einen Code umzuwandeln, der von dem Prozessor ohne einen x86-Befehlssatzkern 1614 nativ ausgeführt werden kann. Es ist nicht wahrscheinlich, dass dieser umgewandelte Code der gleiche ist wie der Alternativ-Befehlssatz-Binärcode 1610, da es schwierig ist, einen Befehlsumwandler herzustellen, der dazu in der Lage ist; der umgewandelte Code erfüllt jedoch die allgemeine Operation und ist aus Befehlen aus dem alternativen Befehlssatz aufgebaut. Somit stellt der Befehlsumwandler 1612 eine Software, Firmware, Hardware oder eine Kombination daraus dar, die es durch Emulation, Simulation oder einen anderen Prozess einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86-Befehlssatzprozessor oder -kern aufweist, ermöglicht, den x86-Binärcode 1606 auszuführen.
Bestimmte Operationen des (der) Befehls (Befehle) im vektorfreundlichen Befehlsformat, das hier offengelegt ist, können von Hardware-Komponenten durchgeführt werden und können als maschinenausführbare Befehle ausgeführt sein, die verwendet werden, um zu bewirken oder zumindest dazu zu führen, dass eine Schaltung oder eine andere Hardware-Komponente, die mit den Befehlen programmiert ist, die Operationen durchführt. Die Schaltung kann einen Universal- oder Spezialprozessor oder eine logische Schaltung aufweisen, um nur einige wenige Beispiele zu nennen. Die Operationen können ferner wahlweise von einer Kombination aus Hardware und Software durchgeführt werden. Eine Ausführungslogik und/oder ein Prozessor können eine spezifische oder besondere Schaltungsanordnung oder Logik aufweisen, die auf einen Maschinenbefehl oder ein oder mehrere Steuersignale, die von dem Maschinenbefehl abgeleitet sind, anspricht, um einen befehlsspezifischen Ergebnisoperanden zu speichern. Zum Beispiel können Ausführungsformen des (der) hier offengelegten Befehls (Befehle) in einem oder mehreren der Systeme von 11–16 ausgeführt werden, und Ausführungsformen des (der) Befehls (Befehle) im vektorfreundlichen Befehlsformat können in einem Programmcode gespeichert sein, der in den Systemen auszuführen ist. Des Weiteren können die Verarbeitungselemente dieser Figuren eine der hier detailliert dargelegten Pipelines und/oder Architekturen (z. B. die In-Order- und Out-of-Order-Architektur) verwenden. Zum Beispiel kann die Dekodierungseinheit der In-Order-Architektur den (die) Befehl(e) dekodieren, den dekodierten Befehl zu einer Vektor- oder Skalareinheit weiterleiten etc.
Die vorstehende Beschreibung dient zum Veranschaulichen bevorzugter Ausführungsformen der vorliegenden Erfindung. Aus der vorstehenden Diskussion wird ersichtlich, dass insbesondere in einem solchen Technologiebereich, in dem ein schnelles Wachstum erfolgt und Weiterentwicklungen nicht leicht vorhersehbar sind, die Erfindung in ihrer Anordnung und ihren Details durch Fachleute auf dem Sachgebiet modifiziert werden kann, ohne dass dadurch von den Prinzipien der vorliegenden Offenlegung innerhalb des Schutzumfangs der beiliegenden Patentansprüche und deren Äquivalente abgewichen wird. Zum Beispiel können eine oder mehrere Operationen eines Verfahrens kombiniert oder weiter aufgeteilt werden.
Alternative Ausführungsformen
Obwohl Ausführungsformen beschrieben worden sind, bei denen das vektorfreundliche Befehlsformat nativ ausgeführt wird, kann bei alternativen Ausführungsformen der Erfindung das vektorfreundliche Befehlsformat durch eine Emulationsschicht ausgeführt werden, die auf einem Prozessor läuft, der einen anderen Befehlssatz ausführt (z. B. einem Prozessor, der den MIPS-Befehlssatz von MIPS Technologies, Sunnyvale, CA, ausführt, einem Prozessor, der den ARM-Befehlssatz von ARM Holdings, Sunnyvale, CA, ausführt). Ferner zeigen die Ablaufdiagramme in den Figuren zwar eine besondere Reihenfolge von Operationen, die bei bestimmten Ausführungsformen der Erfindung durchgeführt werden, es versteht sich jedoch, dass eine solche Reihenfolge beispielhaft ist (z. B. können bei alternativen Ausführungsformen die Operationen in einer anderen Reihenfolge durchgeführt werden, bestimmte Operationen kombiniert werden, bestimmte Operationen einander überlappen etc.)
In der vorstehenden Beschreibung sind zum Zweck der Erläuterung zahlreiche spezifische Details dargelegt worden, um ein gründliches Verständnis der Ausführungsformen der Erfindung zu ermöglichen. Es ist für einen Fachmann auf dem Sachgebiet jedoch offensichtlich, dass eine oder mehrere Ausführungsformen ohne diese spezifischen Details in die Praxis umgesetzt werden können. Die besonderen Ausführungsformen, die beschrieben worden sind, dienen nicht zum Einschränken der Erfindung, sondern zum Veranschaulichen von Ausführungsformen der Erfindung. Der Umfang der Erfindung wird nicht von den spezifischen oben dargelegten Beispielen bestimmt, sondern nur von den nachstehenden Patentansprüchen.

Claims

Prozessor, der umfasst: eine Funktionseinheit einer Befehlsausführungs-Pipeline mit: einer Vergleichsbank-Schaltungsanordnung zum Vergleichen eines oder mehrerer Elemente eines ersten Eingangsvektors mit einem Element eines zweiten Eingangsvektors; einer Addierer-Schaltungsanordnung, die mit der Vergleichsbank-Schaltungsanordnung gekoppelt ist, um die Anzahl von Elementen des zweiten Eingangsvektors, die mit einem Wert des ersten Eingangsvektors übereinstimmt, auf einer Element-für-Element-Basis des ersten Eingangsvektors zu addieren.
Prozessor nach Anspruch 1, wobei die Funktionseinheit einen ROM aufweist, der einen Mikrocode enthält, welcher eine Schleife durch die Vergleichsbank und eine Addierer-Schaltungsanordnung für jedes Element des zweiten Eingangsvektors steuert.
Prozessor nach Anspruch 1, wobei die Funktionseinheit ferner umfasst: eine zweite Vergleichsbank-Schaltungsanordnung zum Vergleichen des einen oder der mehreren Elemente des ersten Eingangsvektors mit einem weiteren Element eines zweiten Eingangsvektors, wobei die zweite Vergleichsbank mit der Addierer-Schaltungsanordnung gekoppelt ist.
Prozessor nach Anspruch 1, der ferner einen Datenweg von der Vergleichsschaltungsanordnung umfasst, der die Addierer-Schaltungsanordnung umgeht.
Prozessor nach Anspruch 4, wobei die Funktionseinheit einen ersten Befehl zum Bestimmen eines Histogramms und einen zweiten Befehl zum Bestimmen, ob bestimmte Zeichen in einer Zeichenfolge zu finden sind, ausführt.
Prozessor nach Anspruch 1, wobei die Funktionseinheit einen Befehl ausführt, dessen Befehlsformat einen Direktwertoperanden aufweist, der einen Typ eines durchzuführenden Vergleichs spezifiziert.
Prozessor nach Anspruch 6, wobei der Typ des Vergleichs eines umfasst von: Gleich Bereich; Gleich beliebiger.
Prozessor nach Anspruch 7, wobei die Funktionseinheit einen ersten Befehl zum Bestimmen eines Histogramms und einen zweiten Befehl zum Bestimmen, ob bestimmte Zeichen in einer Zeichenfolge zu finden sind, ausführt, wobei der Befehl ein Befehlsformat zum Spezifizieren, ob der Gleich-Bereich- oder der Gleich-beliebiger-Vergleich für den ersten und den zweiten Befehl durchzuführen ist, aufweist.
Prozessor nach Anspruch 1, wobei die Funktionseinheit eine Verschaltung für die Ausfächerung des Elements des ersten Vektors zu mehreren Vergleichsschaltungen der Vergleichsschaltungsanordnung zum Durchführen mehrerer Vergleiche des einzelnen Elements mit den Elementen des zweiten Eingangsvektors in einem gleichen Zyklus enthält.
Prozessor nach Anspruch 9, wobei die Funktionseinheit eine Verschaltung für die Eingangsfächerung mehrerer jeweiliger Werte aus den mehreren Vergleichsschaltungen in die Addierer-Schaltungsanordnung zum Produzieren eines Skalarsummierungswerts für das Element des ersten Eingangsvektors gegenüber den Elementen des zweiten Eingangsvektors enthält.
Verfahren, das umfasst: Bestimmen eines Histogramms oder eines Abschnitts desselben durch Ausführung eines einzelnen Befehls in einer Befehlsausführungs-Pipeline, wobei das Ausführen des einzelnen Befehls umfasst: Vergleichen von Elementen eines ersten Eingangsvektors mit einem Element eines zweiten Eingangsvektors; Addieren der Anzahl von Elementen des zweiten Eingangsvektors, die mit einem Wert des ersten Eingangsvektors übereinstimmen, auf einer Element-für-Element-Basis des ersten Eingangsvektors.
Verfahren nach Anspruch 11, das ferner das Durchführen von mikrogesteuerten Schleifen durch eine Vergleichsschaltungsanordnung, die so ausgelegt ist, dass sie das Vergleichen durchführt, und eine Addierer-Schaltungsanordnung, die so ausgelegt ist, dass sie das Addieren durchführt, für jedes der mehreren Elemente des zweiten Eingangsvektors umfasst.
Verfahren nach Anspruch 11, das ferner das Durchführen des Folgenden gleichzeitig mit dem Vergleichen umfasst: Vergleichen der Elemente des ersten Eingangsvektors mit einem weiteren Element eines zweiten Eingangsvektors.
Verfahren nach Anspruch 11, das ferner das Ausführen eines zweiten Befehls mit der Funktionseinheit umfasst, die Elemente eines weiteren ersten Eingangsvektors mit einem Element eines weiteren zweiten Eingangsvektors vergleicht, jedoch nicht die Anzahl von Elementen des weiteren zweiten Eingangsvektors, die einem Wert des weiteren ersten Eingangsvektors entspricht, auf einer Element-für-Element-Basis des weiteren ersten Eingangsvektors addiert.
Verfahren nach Anspruch 14, wobei sowohl der erste als auch der zweite Befehl eine Vergleichsoperation durchführt, die aus einer Gruppe von Vergleichsoperationen ausgewählt ist, welche umfasst: Gleich Bereich; Gleich beliebiger.
Maschinenlesbares Medium, das einen Programmcode enthält, der bei Verarbeitung durch einen Prozessor bewirkt, dass der Prozessor ein Verfahren durchführt, das umfasst: Bestimmen eines ersten Abschnitts eines Histogramms, wobei der Abschnitt die finalen Zählungen für einen Abschnitt der Bins des Histogramms bildet, wobei das Bestimmen das Ausführen einer Reihe von Befehlen umfasst, wobei jeder Befehl einen anderen Satz der Population des Histogramms mit dem Abschnitt der Bins des Histogramms vergleicht und mit diesem summiert, bis die finalen Zählungen erreicht sind.
Maschinenlesbares Medium nach Anspruch 16, wobei ein unmittelbar folgender der Befehle als Eingang die resultierenden Zählungen eines unmittelbar vorhergehenden der Befehle übernimmt.
Maschinenlesbares Medium nach Anspruch 16, wobei die Reihen von Befehlen mit Vektoradditionsbefehlen verschachtelt sind.
Maschinenlesbares Medium nach Anspruch 16, wobei die Vergleiche ein Gleich-Bereich-Vergleich sind.
Maschinenlesbares Medium nach Anspruch 16, wobei die Vergleiche ein Gleich-Beliebiger-Vergleich sind.