DE112017003347T5 - Systeme, Vorrichtungen und Verfahren für Strided-Ladevorgänge - Google Patents

Abstract

Systeme, Verfahren und Vorrichtungen für Strided-Ladevorgänge wie beschrieben. In einer Ausführungsform ist eine Anweisung, die mindestens einen Opcode, ein Feld für mindestens zwei Quelloperanden für gepackte Daten, ein Feld für einen Zieloperanden für gepackte Daten, und eine Direkte enthält, als Anweisung für einen Strided-Ladevorgang vorgesehen. Diese Anweisung wird ausgeführt, um gepackte Datenelemente von den mindestens zwei Quelloperanden für gepackte Daten unter Verwendung eines Strides zu laden und die Ergebnisse der Strided-Ladevorgänge in den Zieloperanden für gepackte Daten zu speichern, beginnend an einer definierten Position, die teilweise von der Direkten bestimmt wird.

Description

• BEREICH DER ERFINDUNG
• Der Bereich der Erfindung bezieht sich allgemein auf eine Computerprozessorarchitektur und genauer gesagt auf eine Anweisung, die bei Ausführung ein bestimmtes Ergebnis verursacht.
• ALLGEMEINER STAND DER TECHNIK
• Ein Anweisungssatz oder eine Anweisungssatzarchitektur (ISA) ist der Teil der Computerarchitektur, der sich auf Programmierung bezieht, und kann die nativen Datentypen, Anweisungen, Registerarchitektur, Adressierungsmodi, Speicherarchitektur, Unterbrechungs- und Ausnahmenhandhabung sowie externe Ein- und Ausgaben (E/A) enthalten. Es sollte angemerkt werden, dass der Begriff Anweisung sich hierin allgemein auf eine Makroanweisung bezieht - das sind Anweisungen, die dem Prozessor zur Ausführung übermittelt werden - im Gegensatz zu Mikroanweisungen oder Mikro-Ops - die entstehen, wenn der Decoder eines Prozessors Makroanweisungen decodiert).
• Die Anweisungssatzarchitektur unterscheidet sich von der Mikroarchitektur, die der innere Aufbau des Prozessors ist, der die ISA umsetzt. Prozessoren mit verschiedenen Mikroarchitekturen können einen gemeinsamen Anweisungssatz teilen. Beispielsweise setzen Intel-Pentium-4-Prozessoren, Intel-Kern-Prozessoren und Advanced-Micro-Devices,-Inc. -of-Sunnyvale-CA-Prozessoren annähernd identische Versionen des x86-Anweisungssatzes um (wobei neueren Versionen einige Erweiterungen hinzugefügt wurden), weisen jedoch unterschiedliche interne Aufbauten auf. Beispielsweise kann dieselbe Registerarchitektur der ISA in verschiedenen Mikroarchitekturen auf unterschiedliche Weise umgesetzt werden, unter Verwendung bekannter Techniken, einschließlich spezieller physischer Register, eines oder mehrerer dynamisch zugeordneter physischer Register unter Verwendung eines Registerumbenennungsmechanimus (z. B. Verwendung einer Registeralias-Tabelle (RAT), eines Reorder Buffer (ROB) und einer Rücknahmeregisterdatei; die Verwendung mehrerer Karten und eines Pools von Registern), usw. Wenn nicht anders vorgegeben, beziehen sich die Begriffe Registerarchitektur, Registerdatei und Register auf das, was für die Software/den Programmierer sichtbar ist, und die Art, in der die Anweisungen Register vorgeben. Wo eine Spezifizität gewünscht wird, wird das Adjektiv logisch, architektonisch oder für die Software sichtbar verwendet, um Register/Dateien in der Registerarchitektur anzugeben, während verschiedene Adjektive verwendet werden, um Register in einer gegebenen Mikroarchitektur anzugeben (z. B. physische Register, Umorientierungspuffer, Rücknahmeregister, Registerpool).
• Ein Anweisungssatz enthält ein oder mehrere Anweisungsformate. Ein gegebenes Anweisungsformat definiert verschiedene Felder (Anzahl Bits, Ort der Bits) zur Vorgabe, unter anderem, der Funktion, die ausgeführt werden soll, und des/der Operanden, auf dem/denen die Funktion ausgeführt werden soll. Eine gegebene Anweisung wird unter Verwendung eines gegebenen Anweisungsformats ausgedrückt und spezifiziert die Funktion und die Operanden. Ein Anweisungsstream ist eine spezifische Sequenz von Anweisungen, wobei jede Anweisung in der Sequenz ein Auftreten einer Anweisung in einem Anweisungsformat ist.
• Wissenschaftliche, finantielle, autovektorisierte Allgemeinzweck-, RMS (Recognition, Mining, und Synthesis)/optische und Multimedia-Anwendungen (z. B. 2D/3D-Grafiken, Bildbearbeitung, Videokompression/-dekompression, Stimmerkennungsalgorithmen und Tonbearbeitung) verlangen häufig die Durchführung derselben Funktion auf einer großen Anzahl von Datenpunkten (bezeichnet als „Datenparallelismus“). „Single Instruction Multiple Data“ (SIMD) bezieht sich auf eine Art von Anweisung, die einen Prozessor veranlasst, dieselbe Funktion auf mehreren Datenpunkten auszuführen. SIMD-Technologie eignet sich besonders für Prozessoren, die logisch die Bits in einem Register in eine Anzahl von Datenelementen fester Größe unterteilen können, von denen jedes einen separaten Wert darstellt. Beispielsweise können die Bits in einem 64-bit-Register vorgegeben sein als ein Quelloperand, auf dem eine Funktion in Form von vier separaten 16-bit-Datenelementen stattfinden soll, von denen jedes einen separaten 16-bit-Wert darstellt. Als ein weiteres Beispiel können die Bits in einem 256-bit-Register vorgegeben sein als ein Quelloperand auf dem eine Funktion als vier separate 64-bit-gepackte Datenelemente (Quad-Word -(Q) Größendatenelemente), acht separate 32-Bit-gepackte Datenelemente (Double Word- (D) Größendatenelemente), sechzehn separate 16-Bit-gepackte Datenelemente (Word- (W) Größendatenelemente) oder zweiunddreißig separate 8-Bit Datenelemente (Byte-(B) Größendatenelemente) ausgeführt werden soll. Diese Art von Daten wird bezeichnet als gepackter Datentyp oder Vektordatentyp und Operanden dieses Datentyps werden bezeichnet als gepackte Datenoperanden oder Vektoroperanden. In anderen Worten: ein gepackter Datenpunkt oder -vektor bezieht sich auf eine Sequenz gepackter Datenelemente; und ein gepackter Datenoperand oder Vektoroperand ist ein Quell- oder Zieloperand einer SIMD-Anweisung (auch bekannt als eine gepackte Datenanweisung oder eine Vektoranweisung).
• Beispielhaft gibt ein Typ der SIMD-Anweisung eine einzelne Vektorfunktion vor, die auf zwei Quellvektoroperanden in einer vertikalen Weise ausgeführt werden soll, um einen Zielvektoroperanden (auch bezeichnet als ein Ergebnisvektoroperand) derselben Größe, mit derselben Anzahl Datenelemente und in derselben Datenelementreihenfolge zu erzeugen. Die Datenelemente in den Quellvektoroperanden werden als Quelldatenelemente bezeichnet, während die Datenelemente in dem Zielvektoroperanden als Ziel- oder Ergebnisdatenelemente bezeichnet werden. Diese Quellvektoroperanden haben dieselbe Größe und enthalten Datenelemente derselben Breite, und enthalten daher dieselbe Anzahl an Datenelementen. Die Quelldatenelemente in denselben Bitpositionen der beiden Quellvektoroperanden bilden Datenelementepaare (auch bezeichnet als entsprechende Datenelemente; das heißt, das Datenelement in der Datenelementposition 0 jedes Quelloperanden entspricht sich, das Datenelement in Datenelementposition 1 jedes Quelloperanden entspricht sich und so weiter). Die Funktion, die durch diese SIMD-Anweisung vorgegeben ist, wird auf jedem dieser Paare Quelldatenelemente separat ausgeführt, um eine entsprechende Anzahl von Ergebnisdatenelementen zu erzeugen, und so hat jedes Paar Quelldatenelemente ein entsprechendes Ergebnisdatenelement. Da die Funktion vertikal ist, und da der Ergebnisvektoroperand dieselbe Größe aufweist, dieselbe Anzahl Datenelemente aufweist, und die Ergebnisdatenelemente in derselben Datenelementreihenfolge gespeichert sind, wie die Quellvektoroperanden, befinden sich die Ergebnisdatenelemente in denselben Bitpositionen des Ergebnisvektoroperanden, wie ihr entsprechendes Paar Quelldatenelemente in den Quellvektoroperanden. Neben dieser exemplarischen Art einer SIMD-Anweisung gibt es eine Vielzahl anderer Arten von SIMD-Anweisungen (die z. B. nur einen oder mehr als zwei Quellvektoroperanden aufweisen; die in einer horizontalen Weise funktionieren; die einen Ergebnisvektoroperanden erzeugen, der eine andere Größe aufweist, die eine andere Größe von Datenelementen aufweisen und/oder die eine andere Datenelementreihenfolge aufweisen). Es sollte verstanden werden, dass der Begriff Zielvektoroperand (oder Zieloperand) definiert ist als das direkte Ergebnis der Durchführung der Funktion, die durch eine Anweisung vorgegeben ist, einschließlich der Speicherung dieses Zieloperanden an einem Ort (egal, ob dies ein Register ist oder an einer Speicheradresse, die durch diese Anweisung vorgegeben ist), sodass darauf als ein Quelloperand durch eine andere Anweisung zugegriffen werden kann (durch Vorgeben desselben Orts durch eine andere Anweisung.
• Figurenliste
• Die vorliegende Erfindung wird beispielhaft und nicht einschränkend durch die Figuren der beiliegenden Zeichnungen illustriert, in denen gleiche Bezugszeichen ähnliche Elemente angeben und wobei:
• 1 eine Ausführungsform von Hardware zur Verarbeitung einer Strideload-Anweisung illustriert;
• 2 ein Beispiel einer Ausführung einer Strideload-Anweisung nach einer Ausführungsform illustriert;
• 3 ein Beispiel einer Ausführung einer Strideload-Anweisung nach einer Ausführungsform illustriert;
• 4 Ausführungsformen der Strideload-Anweisung illustriert;
• 5 eine Ausführungsform des Verfahrens, das durch einen Prozessor durchgeführt wird, um eine Strideload-Anweisung zu verarbeiten, illustriert;
• 6 eine Ausführungsform des Ausführungsabschnitts des Verfahrens, das durch einen Prozessor durchgeführt wird, um eine Strideload-Anweisung zu verarbeiten, illustriert;
• 7 eine Ausführungsform einer Pseudocode-Darstellung der Ausführung einer Strideload-Anweisung illustriert;
• 8A-8B Blockdiagramme, die ein generisches vektorfreundliches Anweisungsformat und Anweisungstemplates davon illustrieren, nach den Ausführungsformen der Erfindung sind;
• 9A-D ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat nach Ausführungsformen der Erfindung illustrieren;
• 10 ein Blockdiagramm einer Registerarchitektur nach einer Ausführungsform der Erfindung ist;
• 11A ein Blockdiagramm ist, das sowohl eine beispielhafte Pipeline in fester Reihenfolge als auch eine beispielhafte Pipeline für Ausgabe/Ausführung einer Registerumbenennung außerhalb der Reihenfolge nach Ausführungsformen der Verbindung illustriert;
• 11B ein Blockdiagramm ist, das sowohl eine beispielhafte Ausführungsform eines Architekturkerns in fester Reihenfolge als auch einen beispielhaften Architekturkern für Ausgabe/Ausführung einer Registerumbenennung außerhalb der Reihenfolge, der nach Ausführungsformen der Erfindung in einem Prozessor enthalten sein soll, illustriert;
• 12A-B ein Blockdiagramm einer Architektur eines spezifischeren beispielhaften Kerns in fester Reihenfolge illustrieren, wobei der Kern einer von mehreren Logikblocks (der andere Kerne desselben Typs und/oder anderer Typen enthält) auf einem Chip wäre;
• 13 ein Blockdiagramm eines Prozessors 1300 ist, der mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafik aufweisen kann, nach Ausführungsformen der Erfindung;
• 14-16 Blockdiagramme beispielhafter Computerarchitekturen sind; und
• 17 ein Blockdiagramm ist, das die Verwendung eines Softwareanweisungsumwandlers zur Umwandlung binärer Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz nach Ausführungsformen der Erfindung gegenüberstellt.
• AUSFÜHRLICHE BESCHREIBUNG
• In der folgenden Beschreibung sind zahlreiche spezifische Einzelheiten dargelegt. Es versteht sich jedoch, dass Ausführungsformen der Erfindung ohne diese spezifischen Einzelheiten praktiziert werden können. In anderen Fällen wurden bekannte Schaltkreise, Strukturen und Techniken nicht ausführlich dargestellt, um das Verständnis der Beschreibung nicht zu verschleiern.
• Verweise in der Spezifikation auf „eine Ausführungsform“, „eine Ausführungsform,“ „eine beispielhafte Ausführungsform“ usw. weisen daraufhin, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft enthalten kann, dass jedoch nicht jede Ausführungsform notwendigerweise das bestimmte Merkmal, die bestimmte Struktur oder Eigenschaft enthalten muss. Weiter beziehen sich solche Begriffe nicht notwendigerweise auf dieselbe Ausführungsform. Ferner wird, wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft in Zusammenhang mit einer Ausführungsform beschrieben ist, festgehalten, dass es im Rahmen des Wissens eines Fachmanns liegt, das Merkmal, die Struktur oder Eigenschaft in Zusammenhang mit anderen Ausführungsformen herzustellen, egal, ob dies ausdrücklich beschrieben ist oder nicht.
• Ausführungsformen, die hierin beschrieben sind, können auf das Problem der Vektorisierung von Schleifen mit Ladungen von Arrays von Strukturen gelten. Ein solches Muster ist auch als Stride-Ladevorgang bekannt. Betrachten Sie beispielsweise ein Array aus Strukturen, das aus 3 Feldern besteht:
  typedef struct {
• double x;
• double y;
• double z;
• }xyz;
• xyz *A;
und mit Zugängen auf die Felder konsekutiver Elemente des Arrays:
for(i=0; i<N; i++){
• x local = A[i].x;
• y_local = A[i].y;
• z local = A[i].z;
• computation(x local, y_local, z local);

...
}
• Zum Vektorisieren der Schleife mit Vektorregistern der Länge VL müssen Bits, die KL-Elemente eines bestimmten Datentyps aufweisen (in dem Beispiel KL=VL/64, bei Zugriff auf 64-bit Floating-Point-Daten, für VL=512, KL=8), Elemente in ein Vektorregister aus dem Speicher erfassen. Elemente befinden sich im Speicher mit einem Stride 3: $$\text{x\_local\_vec}=\left[\text{A}\left[\text{i}+7\right].\text{x}:\text{A}\left[\text{i}+6\right].\text{x}:\text{A}\left[\text{i}+5\right].\text{x}:\text{A}\left[\text{i}+4\right].\text{x}:\text{A}\left[\text{i}+3\right].\text{x}:\text{A}\left[\text{i}+2\right].\text{x}:\text{A}\left[\text{i}+1\right].\text{x}:\text{A}\left[\text{i}+0\right].\text{x}\right]$$

  

  $$\text{y\_local\_vec}=\left[\text{A}\left[\text{i}+7\right].\text{y}:\text{A}\left[\text{i}+6\right].\text{y}:\text{A}\left[\text{i}+5\right].\text{y}:\text{A}\left[\text{i}+4\right].\text{y}:\text{A}\left[\text{i}+3\right].\text{y}:\text{A}\left[\text{i}+2\right].\text{y}:\text{A}\left[\text{i}+1\right].\text{y}:\text{A}\left[\text{i}+0\right].\text{y}\right]$$

  

  $$\text{z\_local\_vec}=\left[\text{A}\left[\text{i}+7\right].\text{z}:\text{A}\left[\text{i}+6\right].\text{z}:\text{A}\left[\text{i}+5\right].\text{z}:\text{A}\left[\text{i}+4\right].\text{z}:\text{A}\left[\text{i}+3\right].\text{z}:\text{A}\left[\text{i}+2\right].\text{z}:\text{A}\left[\text{i}+1\right].\text{z}:\text{A}\left[\text{i}+0\right].\text{z}\right]$$

  
• In einem Anweisungssatz, der eine Erfassungsanweisung enthält, können solche Ladevorgänge durch 3 angrenzende Erfassungen mit denselben Indizes erfolgen: $$\text{x\_local\_vec}=\text{gatherqpd}\left[\text{\&A}\left[\text{i}+0\right]+\text{v\_index}*8\right]$$

  

  $$\text{y\_local\_vec}=\text{gatherqpd}\left[\text{\&A}\left[\text{i}+0\right]+\text{v\_index}*8+8\right]$$

  

  $$\text{z\_local\_vec}=\text{gatherqpd}\left[\text{\&A}\left[\text{i}+0\right]+\text{v\_index}*8+16\right],$$

  

  wobei v_index = [21:18:15:12:9:6:3:0] - Vektor der Indizes, die die Abstände von Elementen von der Basisadresse bestimmen.
• Leider können diese Erfassungen einige Nachteile aufweisen. Beispielsweise ist die Erfassungsumsetzung selbst komplexer als ein regulärer Vektorladevorgang, da Indizes im allgemeinen Fall nicht bekannt sind und mögliche Ausnahmen verarbeitet werden müssen. Daher ist die Leistung nicht optimal. Weiterhin wird die Lokalität von x_local, y_local, z local nicht in Betracht gezogen (sie können sich in derselben Cachezeile befinden).
• Um diese Probleme zu lösen, kann eine Gather-to-Shuffle- (G2S) Optimierung aktiviert werden, die mehrere konsekutive Vektoren in Vektorregister lädt und dann Daten nach verschiedenen Zielorten mit einer Reihe von Permutationsanweisungen mischt (oder permutiert). In einem beispielhaften Fall sollten 3 Vektoren von 8 Elementen geladen und an 3 Zielorte permutiert werden. Ein Problem mit der G2S-Optimierung ist, dass die Permutationssteuerungen für jeden Zielort eindeutig sind und in separaten Vektorregistern erzeugt und erhalten bleiben müssen, solange die gesamte Schleife ausgeführt wird. Ein Stride kann einen größeren Wert (N) aufweisen und die Anzahl eindeutiger Permutationssteuerungen wächst an als N*(N-1). So wird der Registerdruck dramatisch erhöht. Für Stride 5 würde man 20 Register benötigen, um alle Permutationssteuerungen zu halten. Die Anzahl der Permutationsanweisungen in Sequenzen wächst ebenfalls.
• Ein Stride-Muster kann auch in einer Schleife auftreten, die mit einem Schrittwert >1 funktioniert: for(i=0; i<N; i+=5){
• $$\text{x\_local}=\text{B}\left[\text{i}\right];$$
  
• $$\text{y\_local}=\text{B}\left[\text{i}+\text{1}\right];$$
  
• $$\text{z\_local}=\text{B}\left[\text{i}+2\right];$$
  
• $$\text{u\_local}=\text{B}\left[\text{i}+3\right];$$
  
• $$\text{v\_local}=\text{B}\left[\text{i}+4\right];$$
  
  computation(x_local, y_local, z local, u local, v local);

...
}
• Betrachtet wird die aktuelle von einem Compiler erzeugte Permutationssequenz für Stride 3:
• vmovdqu32 zmm5, ZMMWORD PTR .L_2i10floatpacket.2[rip] //Permutation laden
• vmovdqu32 zmm4, ZMMWORD PTR .L_2i10floatpacket.3[rip] //Steuerung von
• vmovdqu32 zmm3, ZMMWORD PTR .L_2i10floatpacket.4[rip] //Speicher vor
• vmovdqu32 zmm2, ZMMWORD PTR .L_2i10floatpacket.5[rip] //Schleife
• vmovdqu32 zmm1, ZMMWORD PTR .L_2i10floatpacket.6[rip]
• vmovdqu32 zmmO, ZMMWORD PTR .L_2i10floatpacket.7[rip]
..B1.12:
• vmovdqu32 zmm8, ZMMWORD PTR [rcx] //Laden von 3 Eingabevektoren
• vmovdqu32 zmm9, ZMMWORD PTR [64+rcx]
• vmovdqu32 zmm11, ZMMWORD PTR [128+rcx]
• vmovaps zmm6, zmm5 //Wiederherstellen überschrieben
• vmovaps zmm7, zmm3 //Permutationssteuerungen
• vmovaps zmm10, zmm1 //hier
• vpermi2q zmm6, zmm8, zmm9
• vpermi2q zmm7, zmm8, zmm9
• vpermi2q zmm10, zmm8, zmm9
• vmovaps zmm12, zmm4 //Wiederherstellen überschrieben
• vmovaps zmm13, zmm2 //Permutationssteuerungen
• vmovaps zmm14, zmm0 //hier
• vpermi2q zmm12, zmm6, zmm11
• vpermi2q zmm13, zmm7, zmm11
• vpermi2q zmm14, zmm10, zmm11
• cmp eax, r10d
• jb ..B1.12
• Es gibt 6 Permutationssteuerungen und insgesamt 12 Anweisungen für die Permutation nach Laden von 3 Vektoren (und plus 6 Ladevorgängen von Permutationssteuerungen aus dem Speicher).
• Mit einer Strideload-Anweisung sieht die Sequenz wie folgt aus:
• vmovdqu32 zmm1, ZMMWORD PTR [rcx] //Laden von 3 Eingabevektoren
• vmovdqu32 zmm2, ZMMWORD PTR [64+rcx]
• vmovdqu32 zmm3, ZMMWORD PTR [128+rcx]
• strideload zmm12, zmm1, zmm2, 010:000:00b //Permutation selbst
• strideload zmm12, zmm3, zmm3, 010:010:01b
• strideload zmm13, zmm1, zmm2, 010:001:00b
• strideload zmm13, zmm3, zmm3, 010:000:01b
• strideload zmm14, zmm1, zmm2, 010:010:00b
• strideload zmm14, zmm3, zmm3, 010:001:01b
• Hier dienen 6 Anweisungen den Permutationen nach 3 Ladevorgängen, es wird kein Register für Permutationssteuerungen erhalten und keine Speicherreferenzen dienen dem Abrufen der Permutationssteuerungen.
• Hierin sind Vorrichtungen, Systeme und Verfahren von Ausführungsformen detailliert, die eine Strided-Ladevorgangs- („Strideload“) Anweisung verwenden, die bei Ausführung durch einen Hardwareprozessor das Laden gepackter Datenelemente von mindestens zwei verketteten Quelloperanden für gepachte Daten (srcM,...,src2, src1) unter Verwendung eines Strides und das Speichern der Ergebnisse der Strided-Ladevorgänge in einem Zieloperanden beginnend ab einer definierten Position auslöst. Die definierte Position des Ziels ist durch (Rundung*M*KL+Abstand)/Stride definiert. Der „Rundungs-“ Wert ist durch eine Direkte der Strideload-Anweisung bereitgestellt. KL ist eine Anzahl gepackter Datenelemente in einer Quelle (Vektorlänge (VL) geteilt durch die gepackte Datenelementgröße). M ist die Anzahl verketteter Quelloperanden. Der „Stride-“ Wert ist mindestens teilweise durch eine Direkte der Strideload-Anweisung bereitgestellt. Eine Startdatenelementposition der verketteten Quellen ist durch einen Abstand definiert, wird durch eine Direkte der Strideload-Anweisung bereitgestellt. In einer Ausführungsform ist die Direkte ein 8-bit-Wert und Bits 7:5 werden verwendet, den Stride zu berechnen (der Wert dieser Bits plus 1), Bits 4:2 stellen den Abstand bereit und Bits 1:0 stellen die Rundung bereit. In einigen Ausführungsformen erfolgt das Speichern unter Kontrolle einer Schreibmaske und ein Feld für die Schreibmaske ist in der Anweisung enthalten.
• 1 illustriert eine Ausführungsform der Hardware zur Verarbeitung einer Strideload-Anweisung. Die illustrierte Hardware ist typischerweise ein Teil eines Hardwareprozessors oder Kerns, wie etwa ein Teil einer zentralen Verarbeitungseinheit, eines Beschleunigers usw.
• Eine Strideload-Anweisung wird durch eine Decodierungsschaltung 101 empfangen. Beispielsweise empfängt die Decodierungsschaltung 101 diese Anweisung von der Fetch-Logik/Schaltung. Die Strideload-Stride-Anweisung enthält Felder für zwei oder mehr Quelloperanden (z. B. gepackte Datenregister (manchmal bezeichnet als Vektorregister)), einen Ziel operanden (z. B. ein gepacktes Datenregister (manchmal bezeichnet als Vektorregister)), einen Opcode und eine Direkte. In einigen Ausführungsformen enthält die Strideload-Anweisung ein Feld für eine Direkte. Ausführlichere Ausführungsformen der Anweisungsformate werden nachfolgend erklärt.
• Die Decodierungsschaltung 101 decodiert die Strideload-Anweisung in eine oder mehrere Funktionen. In einigen Ausführungsformen enthält diese Decodierung die Erzeugung mehrerer Mikrooperationen, die durch die Ausführungsschaltungen durchgeführt werden sollen (wie etwa die Ausführungsschaltung 109). Die Decodierungsschaltung 101 decodiert auch Anweisungspräfixe.
• In einigen Ausführungsformen stellt die Registerumbenennung, Registerzuordnung und/oder Planungsschaltung 103 eine Funktion für ein oder mehrere der folgenden Elemente bereit: 1) Umbenennung logischer Operandenwerte zu physischen Operandenwerten (z. B. eine Registeraliastabelle in einigen Ausführungsformen), 2) Zuordnung von Statusbits und Flags zu der decodierten Anweisung und/oder 3) Planung der decodierten Anweisung für die Ausführung auf Ausführungsschaltungen aus einem Anweisungspool (z. B. Verwendung einer Reservierungsstation in einigen Ausführungsformen).
• Register (Registerdatei) 105 und Speicher 107 speichern Daten als Operanden der Strideload-Anweisung, die durch Ausführungsschaltungen 109 betrieben werden. Beispielregistertypen enthalten gepackte Datenregister, Register für allgemeine Zwecke und Floating Point Register. Die Register 105 können auch Schreibmaskenregister wie hierin beschrieben beinhalten.
• Die Ausführungsschaltungen 109 führen die decodierte Strideload-Anweisung aus, um gepackte Datenelemente von mindestens zwei verketteten Quelloperanden (srcM, ..., src2, src1) unter Verwendung eines Stride zu laden und die Ergebnisse der Strided-Ladevorgänge beginnend von einer definierten Position in dem Zieloperanden zu speichern. Die definierte Position des Ziels ist durch (Rundung*M*KL+Abstand)/Stride definiert. Der „Rundungs-“ Wert ist durch eine Direkte der Strideload-Anweisung bereitgestellt. KL ist eine Anzahl gepackter Datenelemente in einer Quelle (Vektorlänge (VL), geteilt durch die gepackte Datenelementgröße). M ist die Anzahl verketteter Quelloperanden. Der „Stride-“ Wert ist mindestens teilweise durch eine Direkte der Strideload-Anweisung bereitgestellt. Eine Startdatenelementposition der verketteten Quellen ist durch einen Abstand definiert, wird durch eine Direkte der Strideload-Anweisung bereitgestellt. In einer Ausführungsform ist die Direkte ein 8-bit-Wert und Bits 7:5 werden verwendet, den Stride zu berechnen (der Wert dieser Bits plus 1), Bits 4:2 stellen den Abstand bereit und Bits 1:0 stellen die Rundung bereit. In einigen Ausführungsformen erfolgt das Speichern unter Kontrolle einer Schreibmaske und ein Feld für die Schreibmaske ist in der Anweisung enthalten. In einigen Ausführungsformen weist die Rücknahmeschaltung 111 architektonisch das Ergebnis zu (z. B. weist ein Zielregister zu den Registern 105 zu) und nimmt die Anweisung zurück.
• 2 illustriert ein Beispiel einer Ausführung einer Strideload-Anweisung nach einer Ausführungsform. Dieses Beispiel soll nicht einschränkend sein. Beispielsweise wird, während dieses Beispiel ein Little-Endian-Format verwendet, die Lehre hierin eine Ausführung im Big-Endian-Format erlauben.
• Typischerweise hängt die Anzahl der gepackten Datenelemente, die extrahiert werden sollen, und deren Größen, von der Anweisungscodierung ab (Datenelementgröße). So kann sich eine unterschiedliche Anzahl gepackter Datenelemente wie 2, 4, 8, 16, 32 oder 64 in einer gepackten Datenquelle befinden. Gepackte Datenzielregistergrößen enthalten 64-bit, 128-bit, 256-bit und 512-bit.
• In diesem Beispiel enthalten die Quellen 201 (z. B. gepackte Datenregister) je 8 gepackte Datenelemente. Diese Quellen 201 sind zum Zweck der Strided-Ladevorgänge verkettet. Die am wenigsten signifikanten Datenelementpositionen speichern jeweils eine „0“, „2“ bzw. „5“. Diese Werte werden im Dezimalformat angezeigt, sind jedoch typischerweise als binäre oder hexadezimale Werte gespeichert.
• Lade-/Speicherschaltungen (die für einfacheres Verständnis nicht dargestellt sind) werden verwendet, um Datenelemente aus den Quellen 201 nach einem Strided-Wert und einem anfänglichen Abstand zu extrahieren und um diese konsekutiv am Ziel 205 zu speichern.
• In der 0-Rundungs-Strideload-Funktion ist das Ziel REG0 und die Quellen sind REG1 und REG2. Die Direkte ist in Binärformat als 01000100 dargestellt. Dies entspricht einem Abstand 1 (Bits 4:2 der Direkten haben einen Wert 1). Dies bedeutet, dass das erste Datenelement, das gewählt wird, 1 von dem am wenigsten signifikanten Datenelement der verketteten Quellen von REG1 und REG2 beabstandet ist. Dieses Datenelement ist in REG1 markiert und weist einen Wert von 0 auf. Der Stride-Wert, der verwendet werden soll, ist der Wert der direkten Bits 7:5 (der 010b oder in Dezimalwerten 2 ist) plus 1, was in diesem Beispiel ein Stride-Wert von 3 ist. Die Rundung wird durch die beiden am wenigsten signifikanten Bits 1:0 der Direkten gefunden und beträgt 0.
• Der Startpunkt zum Speichern von Strided-Werten in das Ziel 205 von den verketteten Quellen REG1 und REG2 wird unter Verwendung des folgenden (Rundung*M*KL+Abstand)/Stride gefunden. Wie angemerkt ist die Rundung 0, die Anzahl Quellen M ist 2, der Abstand ist 1 und der Stride ist 3. KL ist für dieses Beispiel 8 (es gibt 8 Datenelemente pro Quellregister). Daher ist der Startpunkt für das Ziel 0. In diesem Beispiel werden nur 5 Datenelementorte in das Ziel 205 geladen, wie für diese Rundung gezeigt.
• In der 1-Rundungs-Strideload-Funktion ist das Ziel REG0 und die Quelle ist REG3. Die Direkte ist in Binärformat als 01000000 dargestellt. Dies entspricht einem Abstand von 0 (Bits 4:2 der Direkten haben einen Wert 0). Dies bedeutet, dass das erste Datenelement, das gewählt wird, 0 von dem am wenigsten signifikanten Datenelement der verketteten Quelle von REG3 beabstandet ist. Dieses Datenelement ist in REG3 markiert und weist einen Wert von 5 auf. Der Stride-Wert, der verwendet werden soll, ist der Wert der direkten Bits 7:5 (der 010b oder in Dezimalwerten 2 ist) plus 1, was in diesem Beispiel ein Stride-Wert von 3 ist. Die Rundung wird durch die beiden am wenigsten signifikanten Bits 1:0 der Direkten gefunden und beträgt 1.
• Der Startpunkt zum Speichern von Strided-Werten in das Ziel 205 von der verketteten Quelle REG3 wird unter Verwendung des folgenden (Rundung*M*KL+Abstand)/Stride gefunden. Wie angemerkt ist die Rundung 1, die Anzahl Quellen M ist 2, der Abstand ist 0 und der Stride ist 3. KL ist für dieses Beispiel 8 (es gibt 8 Datenelemente pro Quellregister). Daher ist der Startpunkt für das Ziel 5. In diesem Beispiel werden nur 3 Datenelementorte in das Ziel 205 geladen, wie für diese Rundung gezeigt.
• 3 illustriert ein Beispiel einer Ausführung einer Strideload-Anweisung nach einer Ausführungsform. Dieses Beispiel soll nicht einschränkend sein. Beispielsweise wird, während dieses Beispiel ein Little-Endian-Format verwendet, die Lehre hierin eine Ausführung im Big-Endian-Format erlauben.
• Typischerweise hängt die Anzahl der gepackten Datenelemente, die extrahiert werden sollen, und deren Größen, von der Anweisungscodierung ab (Datenelementegröße). So kann sich eine unterschiedliche Anzahl gepackter Datenelemente wie 2, 4, 8, 16, 32 oder 64 in einer gepackten Datenquelle befinden. Gepackte Datenzielregistergrößen enthalten 64-bit, 128-bit, 256-bit und 512-bit.
• In diesem Beispiel enthalten die Quellen 301 (z. B. gepackte Datenregister) je 8 gepackte Datenelemente. Diese Quellen 301 sind zum Zweck der Strided-Ladevorgänge verkettet. Die am wenigsten signifikanten Datenelementpositionen speichern jeweils eine „0“, „2“ bzw. „5“. Diese Werte werden im Dezimalformat angezeigt sind jedoch typischerweise als binäre oder hexadezimale Werte gespeichert.
• Lade-/Speicherschaltungen (die für einfacheres Verständnis nicht dargestellt sind) werden verwendet, um Datenelemente aus den Quellen 301 nach einem Strided-Wert und einem anfänglichen Abstand zu extrahieren und um diese konsekutiv am Ziel 305 zu speichern.
• In der 0-Rundungs-Strideload-Funktion ist das Ziel REG0 und die Quellen sind REG1 und REG2. Die Direkte ist in Binärformat als 01000100 dargestellt. Dies entspricht einem Abstand 1 (Bits 4:2 der Direkten haben einen Wert 1). Dies bedeutet, dass das erste Datenelement, das gewählt wird, 1 von dem am wenigsten signifikanten Datenelement der verketteten Quellen von REG1 und REG2 beabstandet ist. Dieses Datenelement ist in REG1 markiert und weist einen Wert von 0 auf. Der Stride-Wert, der verwendet werden soll, ist der Wert der direkten Bits 7:5 (der 010b oder in Dezimalwerten 2 ist) plus 1, was in diesem Beispiel ein Stride-Wert von 3 ist. Die Rundung wird durch die beiden am wenigsten signifikanten Bits 1:0 der Direkten gefunden und beträgt 0.
• Der Startpunkt zum Speichern von Strided-Werten in das Ziel 305 von den verketteten Quellen REG1 und REG2 wird unter Verwendung des folgenden (Rundung*M*KL+Abstand)/Stride gefunden. Wie angemerkt ist die Rundung 0, die Anzahl Quellen M ist 2, der Abstand ist 1 und der Stride ist 3. KL ist für dieses Beispiel 8 (es gibt 8 Datenelemente pro Quellregister). Daher ist der Startpunkt für das Ziel 0. In diesem Beispiel wird jedoch eine Schreibmaske 303 (z. B. ein Schreibmaskenregister) verwendet. In Datenelement- (oder Bit-) Position 3 der Schreibmaske 303 befindet sich eine 0, die anzeigt, dass der Strided-Wert nicht in das Ziel 305 geschrieben wird. In diesem Beispiel werden nur 4 Datenelementorte in das Ziel 305 geladen, wie für diese Rundung gezeigt.
• In der 1-Rundungs-Strideload-Funktion ist das Ziel REG0 und die Quelle ist REG3. Die Direkte ist in Binärformat als 01000000 dargestellt. Dies entspricht einem Abstand 0 (Bits 4:2 der Direkten haben einen Wert 0). Dies bedeutet, dass das erste Datenelement, das gewählt wird, 0 von dem am wenigsten signifikanten Datenelement der verketteten Quelle von REG3 beabstandet ist. Dieses Datenelement ist in REG3 markiert und weist einen Wert von 5 auf. Der Stride-Wert, der verwendet werden soll, ist der Wert der direkten Bits 7:5 (der 010b oder in Dezimalwerten 2 ist) plus 1, was in diesem Beispiel ein Stride-Wert von 3 ist. Die Rundung wird durch die beiden am wenigsten signifikanten Bits 1:0 der Direkten gefunden und beträgt 1.
• Der Startpunkt zum Speichern von Strided-Werten in das Ziel 305 von der verketteten Quelle REG3 wird unter Verwendung des folgenden (Rundung*M*KL+Abstand)/Stride gefunden. Wie angemerkt ist die Rundung 1, die Anzahl Quellen M ist 2, der Abstand ist 0 und der Stride ist 3. KL ist für dieses Beispiel 8 (es gibt 8 Datenelemente pro Quellregister). Daher ist der Startpunkt für das Ziel 5. In diesem Beispiel wird erneut dieselbe Schreibmaske (z. B. das zuvor beschriebene Schreibmaske-Register) verwendet. In Datenelement- (oder Bit-) Position 5 der Schreibmaske befindet sich eine 0, die anzeigt, dass der Strided-Wert nicht in das Ziel 305 geschrieben werden wird. In diesem Beispiel werden nur 2 Datenelementorte in das Ziel 305 geladen, wie für diese Rundung gezeigt.
• Eine Ausführungsform eines Formats (einschließlich Feldern) für eine Strideload-Anweisung ist Strideload{B/W/D/Q}{k} DST, SRCM...SRC0. In einigen Ausführungsformen ist die Strideload{B/W/D/Q} der Opcode der Anweisung. B/W/D/Q gibt die Datenelementgrößen der Quellen/des Ziels als Byte, Wort, Doppelwort und Quadwort an. DST ist ein gepacktes Datenzielregister und SRCM...SRC0 sind gepackte Datenquellregister. K ist eine Schreibmaske, die in einigen Ausführungsformen verwendet wird, wie hierin beschrieben.
• In einigen Ausführungsformen enthält die Strideload-Anweisung einen Schreibmaske-Registeroperanden. Eine Schreibmaske wird verwendet, um konditional Funktionen pro Element zu steuern und die Ergebnisse zu aktualisieren. Abhängig von der Umsetzung verwendet die Schreibmaske Verschmelzungs- oder Nullungsmaskierung. Anweisungen, die mit einem Prädikat- (Schreibmaske-, Schreibmaske- oder k-Register-) Operanden codiert sind, verwenden den Operanden zum bedingten Steuern der Rechnerfunktion pro Element und zur Aktualisierung des Ergebnisses auf den Zieloperanden. Der Prädikatoperand ist als Opmask- (Schreibmaske-) Register bekannt. Die Opmask ist ein Satz von acht architektonischen Registern der Größe MAX_KL (64-bit). Es ist zu beachten, dass aus diesem Satz von 8 architektonischen Registern nur k1 bis k7 als Prädikatoperand adressiert werden können. k0 kann als reguläre Quelle oder Ziel verwendet werden, aber nicht als Prädikatoperand codiert sein. Es ist auch zu beachten, dass ein Prädikatoperand verwendet werden kann, um Speicherfehlerunterdrückung für einige Anweisungen mit einem Speicheroperanden zu aktivieren (Quelle oder Ziel). Als ein Prädikatoperand enthalten die Opmask-Register ein Bit zum Kontrollieren der Funktion/Aktualisieren auf jedes Datenelement eines Vektorregisters. Allgemein können Opmask-Register Anweisungen mit Elementgrößen unterstützen: Einzel-Präzisions-Floating-Point (float32), Integer Doubleword(int32), Doppelpräzisions-Floating-Point (float64), Integer Quadword (int64). Die Länge eines Opmask-Registers, MAX_KL, ist ausreichend, um bis zu 64 Elemente mit einem Bit pro Element zu handhaben, d.h. 64 Bits. Für eine bestimmte Vektorlänge greift jede Anweisung nur auf die Anzahl der am wenigsten signifikanten Maskenbits zu, die basierend auf dem Datentyp erforderlich sind. Ein Opmask-Register wirkt sich auf eine Anweisung auf Granularität pro Element aus. So sind alle numerischen oder nichtnumerischen Funktionen jedes Datenelements und Updates pro Element von Zwischenergebnissen des Zieloperanden auf dem entsprechenden Bit des Opmask-Registers mit einem Prädikat versehen. In den meisten Ausführungsformen gehorcht eine Opmask, die als Prädikatoperand dient, den folgenden Eigenschaften: 1) die Funktion der Anweisung wird nicht für ein Element ausgeführt, wenn das entsprechende Opmask-Bit nicht eingestellt ist (dies deutet an, dass keine Ausnahme oder Verletzung durch eine Funktion auf ein ausmaskiertes Element erfolgen kann, und daher wird kein Ausnahmeflag aufgrund einer ausmaskierten Funktion aktualisiert); 2) ein Zielelement wird nicht mit dem Ergebniss der Funktion aktualisiert, wenn das jeweilige Schreibmaske-Bit nicht eingestellt wurde. Stattdessen muss der Zielelementwert erhalten bleiben (Verschmelzungsmaskierung) oder ausgenullt werden (Nullungsmaskierung); 3) für einige Anweisungen mit einem Speicheroperanden werden Speicherfehler für Elemente mit einem Maskenbit 0 unterdrückt. Es ist zu beachten, dass diese Funktion ein vielseitiges Konstrukt bereitstellt, um eine Steuerflussvorhersage umzusetzen, da die Maske im Grund ein Verschmelzungsverhalten für die Vektorregisterziele bereitstellt. Alternativ kann die Maskierung zum Nullen statt zum Verschmelzen verwendet werden, sodass die ausmaskierten Elemente mit 0 aktualisiert werden, statt den alten Wert zu erhalten. Das Nullungsverhalten wird bereitgestellt, um die implizierte Abhängigkeit von dem alten Wert zu entfernen, wenn dieser nicht benötigt wird.
• 4 illustriert Ausführungsformen der Strideload-Anweisung, einschließlich Felder für den Opcode 401, den Ziel operand 403 für gepackte Daten, die Quelloperanden 405 für gepackte Daten, eine Direkte 409 und in einigen Ausführungsformen einen Schreibmaske-Operanden 407. In einigen Ausführungsformen ist es nicht möglich, ausdrücklich ausreichend viele Quelloperanden für die Anweisungen zu codieren. In solchen Ausführungsformen können implizite Register verwendet werden (z. B. ist SRC0 immer ein bestimmtes Register oder in dem Register für allgemeine Zwecke vorgegeben) oder durch Codierung einer Quelle, die dieses Register und dann die nächsten n Register angibt (beispielsweise wenn eine Anweisung, die vier Quellen nimmt, Bits enthält, die SRC0 ist ein Operand, der auch bedeutet, dass SRC1, SRC2 und SRC3 die anderen drei Quellen sind).
• 5 illustriert eine Ausführungsform des Verfahrens, das durch einen Prozessor durchgeführt wird, um eine Strideload-Anweisung zu verarbeiten.
• Bei 501 wird eine Anweisung geholt. Beispielsweise wird eine Strideload-Anweisung geholt. Die Strideload-Anweisung enthält Felder für einen Opcode, mindestens einen Quelloperand für gepackte Daten, eine Direkte und einen Zieloperand für gepackte Daten. In einigen Ausführungsformen enthält die Strideload-Anweisung ein Feld für einen Schreibmaskenoperanden. In einigen Ausführungsformen wird die Anweisung von einem Anweisungscache abgeholt.
• Die abgeholte Anweisung wird in 503 decodiert. Beispielsweise wird die abgeholte Strideload-Anweisung durch eine Decodierungsschaltung decodiert, wie hierin beschrieben. In einigen Ausführungsformen ist die Anweisung in eine oder mehrere Mikrofunktionen decodiert.
• Daten, die mit dem Quelloperanden der decodierten Anweisung assoziiert sind, werden bei 505 abgerufen. Beispielsweise wird auf fortlaufende Elemente aus dem Speicher beginnend an der Quelladresse zugegriffen, oder es wird auf ein Quell- und/oder Zielregister mit gepackten Daten zugegriffen.
• Bei 507 wird die decodierte Anweisung durch eine Ausführungsschaltung (Hardware) ausgeführt, wie die hierin erklärte. Für die Strideload-Anweisung wird die Ausführung Elemente mit gepackten Daten aus mindestens zwei verkettete Quelloperanden für gepackte Daten (srcM, ..., src2, src1) unter Verwendung eines Stride laden und die Ergebnisse der Strided-Ladevorgänge beginnend an einer definierten Position in einem Zieloperanden speichern. Die definierte Position des Ziels ist durch (Rundung*M*KL+Abstand)/Stride definiert. Der „Rundungs-“ Wert ist durch eine Direkte der Strideload-Anweisung bereitgestellt. KL ist eine Anzahl gepackter Datenelemente in einer Quelle (Vektorlänge (VL), geteilt durch die gepackte Datenelementgröße). M ist die Anzahl verketteter Quelloperanden. Der „Stride-“ Wert ist mindestens teilweise durch eine Direkte der Strideload-Anweisung bereitgestellt. Eine Startdatenelementposition der verketteten Quellen ist durch einen Abstand definiert, wird durch eine Direkte der Strideload-Anweisung bereitgestellt. In einer Ausführungsform ist die Direkte ein 8-bit-Wert und Bits 7:5 werden verwendet, den Stride zu berechnen (der Wert dieser Bits plus 1), Bits 4:2 stellen den Abstand bereit und Bits 1:0 stellen die Rundung bereit. In einigen Ausführungsformen erfolgt das Speichern unter Kontrolle einer Schreibmaske und ein Feld für die Schreibmaske ist in der Anweisung enthalten.
• In einigen Ausführungsformen wird die Anweisung in 509 zugesichert oder zurückgenommen.
• 6 illustriert eine Ausführungsform des Ausführungsabschnitts des Verfahrens, das durch einen Prozessor durchgeführt wird, um eine Strideload-Anweisung zu verarbeiten.
• In 601 wird eine Bestimmung einer Anzahl von Datenelementen pro Quellregister mit gepackten Daten, ein Abstandswert und ein Rundungswert erstellt, zusammen mit einer Berechnung eines Stride-Werts. Die Anzahl der Datenelemente pro Quellregister (KL) für gepackte Daten wird durch Vektorlänge (VL) geteilt durch Größe des gepackten Datenelements bestimmt (typischerweise angegeben als Teil des Opcodes der Anweisung). Wie oben erklärt, enthält die Anweisung ein Feld für eine Direkte, die verwendet wird, um die anderen Werte abzurufen. In einer Ausführungsform ist die Direkte ein 8-bit-Wert und Bits 7:5 werden verwendet, den Stride zu berechnen (der Wert dieser Bits plus 1), Bits 4:2 stellen den Abstand bereit und Bits 1:0 stellen die Rundung bereit. Der Abstand ist eine Startdatenelementposition der verketteten Quellregister mit gepackten Daten.
• Die Quellregister sind in 603 verkettet. In einigen Ausführungsformen wird eine temporäre Datenstruktur für das verkettete Ergebnis verwendet.
• Eine Bestimmung einer Startdatenelementposition des Zielregisters mit gepackten Daten erfolgt in 605. Die Startposition des Zielregisters mit gepackten Daten ist definiert durch (Rundung*M*KL+Abstand)/Stride, wobei M die Anzahl verketteter Quellregister mit gepackten Daten ist.
• Bei 607 wird ein Datenelementwert von den verketteten Quellregistern mit gepackten Daten an der Abstanddatenelementposition geladen und an der bestimmten Startdatenelementposition des Zielregisters mit gepackten Daten gespeichert. In einigen Ausführungsformen unterliegt diese Speicherung einer Schreibmaske.
• Bei 609 wird ein Datenelementwert von den verketteten Quellregistern mit gepackten Daten bei der Datenelementposition in einem Abstand von Stride-Werten von der direkt vorhergehenden geladenen Datenelementposition geladen und konsekutiv mit dem vorherigen Speichervorgang in das Zielregister mit gepackten Daten gespeichert. In einigen Ausführungsformen unterliegt diese Speicherung einer Schreibmaske.
• Bei 611 wird festgestellt, ob alle der Strided-Datenelementpositionen der verketteten Quellregister mit gepackten Daten erschöpft wurden. Wenn nicht, wird die nächste Strided-Datenelementposition in 609 geladen usw.
• Wenn ja, werden in einigen Ausführungsformen Werte an Datenelementpositionen des Ziels bei 613 auf null gestellt.
• 7 illustriert eine Ausführungsform einer Pseudocode-Darstellung der Ausführung einer Strideload-Anweisung.
• Die nachfolgenden Figuren erklären Beispielarchitekturen und Systeme zum Umsetzen von Ausführungsformen des Obigen. In einigen Ausführungsformen sind ein oder mehrere oben beschriebene Hardwarebestandteile und/oder Anweisungen wie nachfolgend ausführlicher erklärt emuliert oder als Softwaremodule umgesetzt.
• Ausführungsformen der oben ausführlich erklärten Anweisung(en) können in einem „generischen vektorfreundlichen Anweisungsformat“ verkörpert sein, wie nachfolgend erklärt. In anderen Ausführungsformen ist ein solches Format nicht verwendet, und ein anderes Anweisungsformat wird verwendet; die nachfolgende Beschreibung der Schreibmaskeregister, verschiedenen Datentransformationen (Swizzle, Broadcast usw.), Adressierung usw. gilt jedoch allgemein für die Beschreibung der Ausführungsformen der Anweisung(en) oben. Weiterhin werden beispielhafte Systeme, Architekturen und Pipelines nachfolgend ausführlich erklärt. Ausführungsformen der obigen Anweisung(en) können in solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die beschriebenen beschränkt.
• Ein Anweisungssatz kann ein oder mehrere Anweisungsformate enthalten. Ein gegebenes Anweisungsformat kann verschiedene Felder (z. B. Anzahl Bits, Ort der Bits) zur Vorgabe, unter anderem, der Funktion, die ausgeführt werden soll (z. B. Opcode), und des/der Operanden, auf die die Funktion ausgeführt werden soll, und/oder eines oder mehrerer anderer Datenfeld(er) (z. B. Maske) enthalten. Einige Anweisungsformate sind weiter aufgeschlüsselt, trotz der Definition der Anweisungstemplates (oder Unterformate). Beispielsweise können die Anweisungstemplates eines bestimmten Anweisungsformats definiert werden, verschiedene Untersätze von Feldern des Anweisungsformats aufzuweisen (die enthaltenen Felder befinden sich üblicherweise in derselben Reihenfolge, aber zumindest einige haben unterschiedliche Bitpositionen, da weniger Felder enthalten sind), und/oder definiert werden, ein bestimmtes Feld unterschiedlich interpretiert aufzuweisen. So wird jede Anweisung einer ISA unter Verwendung eines bestimmten Anweisungsformats ausgedrückt (und, wenn definiert, in einem bestimmten der Anweisungstemplates des Anweisungsformats) und enthält Felder zur Vorgabe der Funktion und der Operanden. Beispielsweise hat eine beispielhafte ADD-Anweisung einen spezifischen Opcode und ein Anweisungsformat, das ein Opcode-Feld enthält, um festzulegen, dass die Opcode- und Operandenfelder Operanden auswählen (Quelle1/Ziel und Quelle2); und ein Auftreten dieser ADD-Anweisung in einem Anweisungs-Stream hat spezifische Inhalte in den Operandenfeldern, die spezifische Operanden auswählen. Ein Satz SIMD-Erweiterungen, auf den als Advanced Vector Extensions (AVX) (AVX1 und AVX2) verwiesen wird und der das Vector Extensions (VEX) Codingschema verwendet, wurde herausgegeben und/oder veröffentlicht (z. B. siehe Intel® 64 und IA-32 Architectures Software Developer's Manual, September 2014; und siehe Intel® Advanced Vector Extensions Programming Reference, Oktober 2014).
• Beispielhafte Anweisungsformate
• Ausführungsformen der Anweisung(en), die hierin beschrieben sind, können in verschiedenen Formaten verkörpert sein. Weiterhin werden beispielhafte Systeme, Architekturen und Pipelines nachfolgend ausführlich erklärt. Ausführungsformen der Anweisung(en) können in solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die beschriebenen beschränkt.
• Generisches vektorfreundliches Anweisungsformat
• Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das sich für Vektoranweisungen eignet (z. B. gibt es bestimmte Felder, die speziell für Vektorfunktionen gelten). Während Ausführungsformen beschrieben sind, in denen sowohl Vektor- als auch Skalierungsfunktionen durch das vektorfreundliche Anweisungsformat unterstützt sind, verwenden alternative Ausführungsformen nur Vektorfunktionen das vektorfreundliche Anweisungsformat.
• 8A-8B sind Blockdiagramme, die ein generisches vektorfreundliches Anweisungsformat und Anweisungstemplates davon nach den Ausführungsformen der Erfindung illustrieren; 8A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Klasse-A-Anweisungstemplates davon nach Ausführungsformen der Erfindung illustriert; während 8B ein Blockdiagramm ist, das ein generisches vektorfreundliches Anweisungsformat und Klasse-B-Anweisungstemplates davon nach Ausführungsformen der Erfindung illustriert. Speziell ein generisches vektorfreundliches Anweisungsformat 800, für das Klasse-A- und Klasse-B-Anweisungstemplates definiert sind, die beide keine Speicherzugriffs- 805 Anweisungstemplates und Speicherzugriffs- 820 Anweisungstemplates enthalten. Der Begriff generisch im Zusammenhang mit dem vektorfreundlichen Anweisungsformat bezieht sich darauf, dass das Anweisungsformat nicht mit einem bestimmten Anweisungssatz verknüpft ist.
• Während Ausführungsformen der Erfindung beschrieben werden, in denen das vektorfreundliche Anweisungsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandlänge (oder -größe) mit 32 Bit (4 Byte) oder 64 Bit (8 Byte) Datenelementbreiten (oder -größen) (und so besteht ein 64-Byte-Vektor aus entweder 16 doppelwortgroßen Elementen oder alternativ aus 8 quadwortgroß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); alternative Ausführungsformen können mehr, weniger und/oder andere Vektoroperandengrößen (z. B. 256 Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. 128 Bit (16 Byte) Datenelementbreiten) enthalten.
• Die Klasse-A-Anweisungstemplates in 8A enthalten: 1) innerhalb der Anweisungstemplates 805 ohne Speicherzugriff wird ein Anweisungstemplate für eine Funktion 810 vom Typ kein Speicherzugriff, volle Rundungssteuerung und ein Anweisungstemplate für eine Funktion 815 vom Typ kein Speicherzugriff, Datentransformation gezeigt; und 2) innerhalb der Anweisungstemplates für Speicherzugriff 820 wird ein temporales 825 Anweisungstemplate mit Speicherzugriff und ein nichttemporales 830 Anweisungstemplate mit Speicherzugriff gezeigt. Die Klasse-B-Anweisungstemplates in 8B enthalten: 1) innerhalb der Anweisungstemplates 805 ohne Speicherzugriff wird ein Anweisungstemplate für eine Funktion 812 vom Typ kein Speicherzugriff, Schreibmaskensteuerung, teilweise Rundungssteuerung und ein Anweisungstemplate für eine Funktion 817 vom Typ kein Speicherzugriff, Schreibmaskensteuerung, Vsize gezeigt; und 2) innerhalb der Anweisungstemplates für Speicherzugriff 820 wird ein Anweisungstemplate mit Speicherzugriff und Schreibmaskensteuerung 827 gezeigt.
• Das generische vektorfreundliche Anweisungsformat 800 enthält folgende Felder, die nachfolgend aufgeführt sind, in der Reihenfolge wie in 8A-8B illustriert.
• Formatfeld 840 - ein spezifischer Wert (ein Anweisungsformatkennungswert) in diesem Feld identifiziert eindeutig das vektorfreundliche Anweisungsformat und daher Auftreten der Anweisungen in dem vektorfreundlichen Anweisungsformat in Anweisungsstreams. So ist dieses Feld optional in dem Sinn, dass es nicht für einen Anweisungssatz benötigt wird, der nur ein generisches vektorfreundliches Anweisungsformat aufweist.
• Basisfunktionsfeld 842 - sein Inhalt unterscheidet zwischen verschiedenen Basisfunktionen.
• Registerindexfeld 844 - sein Inhalt spezifiziert direkt oder durch Adresserzeugung die Orte der Quell- und Zieloperanden, egal, ob diese sich in Registern oder im Speicher befinden. Diese umfassen eine ausreichende Anzahl an Bits zur Auswahl von N Registern aus einer P×Q (z. B. 32×512, 16×128, 32×1024, 64×1024) Registerdatei. Während in einer Ausführungsform N bis zu drei Quell- und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quell- und Zielregister unterstützen (können z. B. bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel dient, können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel dient, können bis zu zwei Quellen und ein Ziel unterstützen).
• Modifizierer 846 - sein Inhalt unterscheidet Auftreten von Anweisungen in dem generischen Vektoranweisungsformat, die Speicherzugriff angeben von denen, die dies nicht tun; d. h. zwischen Anweisungstemplates (846A) ohne Speicherzugriff 805 und Anweisungstemplates für Speicherzugriff 820. Speicherzugriffsfunktionen lesen von und/oder schreiben auf die Speicherhierarchie (in einigen Fällen unter Vorgabe der Quell- und/oder Zieladressen unter Verwendung von Werten in Registern), während Funktionen ohne Speicherzugriff dies nicht tun (z. B. wenn die Quelle und Ziele Register sind). Während in einer Ausführungsform dieses Feld auch zwischen drei verschiedenen Arten wählt, Speicheradressberechnungen durchzuführen, können alternative Ausführungsformen mehr, weniger oder andere Möglichkeiten unterstützen, Speicheradressberechnungen auszuführen.
• Augmentierungsfunktionsfeld 850 - sein Inhalt unterscheidet, welche einer Vielzahl von verschiedenen Funktionen neben der Basisfunktion ausgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung, ist dieses Feld in ein Klassefeld 868, ein Alphafeld 852 und ein Betafeld 854 unterteilt. Das Augmentierungsfunktionsfeld 850 erlaubt die Ausführung gemeinsamer Funktionsgruppen in einer einzigen Anweisung statt in 2, 3 oder 4 Anweisungen.
• Skalierungsfeld 860 - sein Inhalt erlaubt die Skalierung des Inhalts des Indexfelds für Speicheradresserzeugung (z. B. für Adresserzeugung, die 2 ^scale * Index + Basis verwendet).
• Verschiebungsfeld 862A- sein Inhalt wird als Teil der Speicheradressenerzeugung verwendet (z. B. für eine Adressenerzeugung, die 2 ^scale * Index + Basis + Verschiebung verwendet).
• Verschiebungsfaktorfeld 862B (beachten Sie, dass die Nebeneinanderstellung von Verschiebungsfeld 862A direkt mit dem Verschiebungsfaktorfeld 862B angibt, dass eines oder das andere verwendet wird) - sein Inhalt wird als Teil der Adressenerzeugung verwendet; es gibt einen Verschiebungsfaktor an, der durch die Größe eines Speicherzugriffs (N) skaliert werden soll - wobei N die Anzahl Bytes im Speicherzugriff ist (z. B. für eine Adressenerzeugung, die 2^scale * Index + Basis + skalierte Verschiebung verwendet). Redundante Bits niedriger Ordnung werden ignoriert, und daher wird der Inhalt des Verschiebungsfaktorfelds mit der Gesamtgröße (N) der Speicheroperanden multipliziert, um die endgültige Verschiebung zu berechnen, die für die Berechnung einer effektiven Adresse verwendet werden soll. Der Wert für N wird bestimmt durch die Prozessorhardware bei Laufzeit, auf Grundlage des vollen Opcode-Felds 874 (später hierin beschrieben) und des Datenmanipulationsfelds854C. Das Verschiebungsfeld 862A und das Verschiebungsfaktorfeld 862B sind optional insofern, als sie nicht für die Anweisungstemplates ohne Speicherzugriff 805 verwendet werden, und/oder verschiedene Ausführungsformen können nur eines oder keines der beiden umsetzen.
• Datenelementbreitenfeld 864 - sein Inhalt unterscheidet, welche einer Anzahl von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Anweisungen; in anderen Ausführungsformen nur für einige der Anweisungen). Dieses Feld ist optional insofern, als es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung eines Aspekts der Opcodes unterstützt werden.
• Schreibmaskenfeld 870 - sein Inhalt steuert auf Grundlage pro Datenelementposition, ob die Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisfunktion und Augmentierungsfunktion wiederspiegelt. Klasse-A-Anweisungstemplates unterstützen Verschmelzungs-Schreibmaskierung, während Klasse-B-Anweisungstemplates sowohl Verschmelzungs- als auch Nullungs-Schreibmaskierung unterstützen. Bei der Verschmelzung erlauben Vektormasken den Schutz jedes Elementesatzes in dem Ziel vor Aktualisierungen während der Ausführung einer beliebigen Funktion (vorgegeben durch die Basisfunktion und die Augmentierungsfunktion); in einer anderen Ausführungsform wird der alte Wert jedes Elements des Ziels erhalten, wenn das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu erlauben beim Nullen die Vektormasken das Nullen jedes Elementesatzes in dem Ziel bei der Ausführung einer beliebigen Funktion (vorgegeben durch die Basisfunktion und die Augmentierungsfunktion); in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das jeweilige Maskenbit einen Wert 0 aufweist. Ein Untersatz dieser Funktionalität ist die Möglichkeit, die Vektorlänge der Funktion, die ausgeführt wird, zu steuern (d. h. die Spanne der Elemente, die geändert werden, vom ersten zum letzten); es ist jedoch nicht notwendig, dass die geänderten Elemente konsekutiv sind. So erlaubt das Schreibmaskenfeld 870 teilweise Vektorfunktionen, einschließlich Ladevorgänge, Speichervorgänge, arithmetische Vorgänge, logische Vorgänge usw. Während Ausführungsformen der Erfindung beschrieben sind, in denen der Inhalt des Schreibmaskenfelds 870 eines aus einer Anzahl von Schreibmaskenregistern wählt, das die zu verwendende Schreibmaske enthält (und daher der Inhalt des Schreibmaskenfelds 870 indirekt identifiziert, dass die Maskierung durchgeführt werden soll), können alternative Ausführungsformen stattdessen oder zusätzlich erlauben, dass der Inhalt des Maskenschreibefelds 870 direkt die durchzuführende Maskierung angibt.
• Direktes Feld 872 - sein Inhalt erlaubt die Vorgabe einer Direkten. Dieses Feld ist optional insofern, als es nicht in einer Umsetzung des generischen vektorfreundlichen Formats vorhanden ist, das Direkte nicht unterstützt und nicht in Anweisungen vorhanden ist, die keine Direkte verwenden.
• Klassefeld 868 - sein Inhalt unterscheidet zwischen verschiedenen Anweisungsklassen. Mit Verweis auf 8A-B wählen die Inhalte dieses Felds zwischen Klasse-A- und Klasse-B-Anweisungen. In 8A-B werden Quadrate mit gerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Klasse A 868A und Klasse B 868B für das Klassefeld 868 jeweils in 8A-B).
• Anweisungstemplates von Klasse A
• In den Fällen der Anweisungstemplates ohne Speicherzugriff 805 aus Klasse A wird das Alphafeld 852 ausgelegt als RS-Feld 852A, dessen Inhalt unterschiedet, welche der verschiedenen Augmentierungsfunktionstypen durchgeführt werden sollen (z. B. Rundung 852A.1 und Datentransformation 852A.2 werden jeweils für Anweisungstemplates der Funktion 810 vom Typ kein Speicherzugriff, Rundung und der Funktion 815 vom Typ kein Speicherzugriff, Datentransformation vorgegeben), während das Betafeld 854 unterscheidet, welche der Funktionen der vorgegebenen Art durchgeführt werden sollen. In den Anweisungstemplates ohne Speicherzugriff 805 sind das Skalierungsfeld 860, das Verschiebungsfeld 862A und Verschiebungsskalierungsablage 862B nicht vorhanden.
• Anweisungstemplates ohne Speicherzugriff - Funktion vom Typ volle Rundungssteuerung
• In dem Anweisungstemplate für Funktion 810 vom Typ kein Speicherzugriff, volle Rundungssteuerung, ist das Betafeld 854 interpretiert als Rundungssteuerungsfeld 854A, dessen Inhalt (Inhalte) eine statische Rundung bereitstellen. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 854A ein Feld 856 zum Unterdrücken aller Floating-Point-Ausnahmen (SAE) und ein Rundungsfunktionssteuerfeld 858 enthält, können alternative Ausführungsformen unterstützen können diese Konzepte beide in dasselbe Feld codieren oder nur eines oder das andere dieser Konzepte/Felder aufweisen (z. B. können nur ein Rundungsfunktionssteuerfeld 858 aufweisen).
• SAE Feld 856 - sein Inhalt unterscheidet dazwischen, ob die Ausnahmenereignisberichterstattung deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Felds 856 angibt, dass die Unterdrückung aktiviert ist, meldet eine gegebene Anweisung nicht eine Art von Floating-Point-Ausnahmeflag und bringt keinen Floating-Point-Ausnahmehandler auf.
• Rundungsfunktionssteuerfeld 858 - der Inhalt unterscheidet dazwischen, welche einer Gruppe von Rundungsfunktionen ausgeführt werden soll (z. B. Aufrunden, Abrunden, Runden zu Null und Runden zum nächsten). Daher erlaubt das Rundungsfunktionssteuerfeld 858 die Änderung des Rundungsmodus auf Grundlage pro Anweisung. In einer Ausführungsform der Erfindung, wo ein Prozessor ein Steuerregister enthält, um Rundungsmodi anzugeben, überschreibt der Inhalt des Rundungsfunktionssteuerfelds 850 den Registerwert.
• Anweisungstemplates ohne Speicherzugriff - Funktion vom Typ Datentransformation
• In dem Anweisungstemplate der Funktion 815 vom Typ kein Speicherzugriff, Datentransformation wird das Betafeld 854 ausgelegt als Datentransformationsfeld 854B, dessen Inhalt unterscheidet, welche einer Anzahl von Datentransformationen ausgeführt werden soll (z. B. keine Datentransformation, Swizzle, Broadcast).
• Im Fall eines Anweisungstemplates für Speicherzugriff 820 von Klasse A wird das Alphafeld 852 ausgelegt als Räumungshinweisfeld 852B, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in 8A sind temporal 852B. 1 bzw. nicht temporal 852B.2 für das temporale 825 Anweisungstemplate mit Speicherzugriff und das nichttemporale 830 Anweisungstemplate mit Speicherzugriff angegeben), während das Betafeld 854 ausgelegt wird als ein Datenmanipulationsfeld 854C, dessen Inhalt unterscheidet, welche aus einer Anzahl von Datenmanipulationsfunktionen (auch bekannt als Primitive) durchgeführt werden soll (z. B. keine Manipulation; Broadcast; Aufkonvertierung einer Quelle; und Abkonvertierung eines Ziels). Die Anweisungstemplates mit Speicherzugriff 820 enthalten das Skalierungsfeld 860, und gegebenenfalls das Verschiebungsfeld 862A oder das Verschiebungsskalierungsfeld 862B.
• Vektorspeicheranweisungen führen Vektorladevorgänge von und Vektorspeichervorgänge auf den Speicher mit Konvertierungssupport aus. Wie bei regulären Vektoranweisungen übertragen Vektorspeicheranweisungen Daten von/an den Speicher in einer Weise pro Datenelement, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske diktiert werden, die als Schreibmaske gewählt wird.
• Speicherzugriffsanweisungstemplates - Temporal
• Temporale Daten sind Daten, die wahrscheinlich schnell genug wiederverwendet werden, um vom Cachen zu profitieren. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können ihn auf unterschiedliche Weise umsetzen, einschließlich des vollständigen Ignorierens des Hinweises.
• Speicherzugriffsanweisungstemplates - Nichttemporal
• Nichttemporale Daten sind Daten, die wahrscheinlich nicht so schnell wiederverwendet werden, dass sie vom Cachen im Cache der 1. Ebene profitieren würden, und die Priorität für die Räumung erhalten sollten. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können ihn auf unterschiedliche Weise umsetzen, einschließlich des vollständigen Ignorierens des Hinweises.
• Anweisungstemplates von Klasse B
• Im Fall der Anweisungstemplates von Klasse B wird das Alphafeld 852 interpretiert als Schreibmaskensteuerungs- (Z) Feld 852C, dessen Inhalt unterscheidet, ob die Schreibmaskierung, die durch das Schreibmaskenfeld 870 gesteuert wird, eine Verschmelzung oder eine Nullung sein sollte.
• In den Fällen der Anweisungstemplates ohne Speicherzugriff 805 aus Klasse B wird ein Teil des Betafelds 854 ausgelegt als RL-Feld 857A, dessen Inhalt unterschiedet, welche der verschiedenen Augmentierungsfunktionstypen durchgeführt werden soll (z. B. Rundung 857A.1 und Vektorlänge (VSIZE) 857A.2 werden jeweils für das Anweisungstemplate der Funktion 812 vom Typ kein Speicherzugriff, Schreibmaskensteuerung, teilweise Rundungssteuerung und das Anweisungstemplate der Funktion 817 vom Typ kein Speicherzugriff, Schreibmaskensteuerung, VSIZE vorgegeben), während der Rest des Betafelds 854 unterscheidet, welche der Funktionen der vorgegebenen Art durchgeführt werden soll. In den Anweisungstemplates ohne Speicherzugriff 805 sind das Skalierungsfeld 860, das Verschiebungsfeld 862A und die Verschiebungsskalierungsablage 862B nicht vorhanden.
• In dem Anweisungstemplate der Funktion 810 vom Typ ohne Speicherzugriff, mit Schreibmaskensteuerung und teilweiser Rundungssteuerung, wird der Rest des Betafelds 854 ausgelegt als ein Rundungsfunktionsfeld 859A und die Ausnahmenberichterstattung ist deaktiviert (eine gegebene Anweisung meldet keine Art von Floating-Point Ausnahmefall und bringt keinen Floating-Point-Ausnahmehandler auf).
• Rundungsfunktionssteuerfeld 859A - genau wie das Rundungsfunktionssteuerfeld 858 unterscheidet sein Inhalt dazwischen, welche einer Gruppe von Rundungsfunktionen ausgeführt werden soll (z. B. Aufrunden, Abrunden, Runden zu Null und Runden zum nächsten). Daher erlaubt das Rundungsfunktionssteuerfeld 859A die Änderung des Rundungsmodus auf Grundlage pro Anweisung. In einer Ausführungsform der Erfindung wo ein Prozessor ein Steuerregister enthält, um Rundungsmodi anzugeben, überschreibt der Inhalt des Rundungsfunktionssteuerfelds 850 den Registerwert.
• In dem Anweisungstemplate für die Funktion 817 vom Typ ohne Speicherzugriff, Schreibmaskensteuerung, VSIZE, wird der Rest des Betafelds 854 ausgelegt als ein Vektorlängenfeld 859B, dessen Inhalt unterscheidet, auf welcher aus einer Anzahl von Datenvektorlängen ausgeführt werden soll (z. B. 128, 256 oder 512 Byte).
• Im Fall eines Anweisungstemplates für Speicherzugriff 820 von Klasse B wird ein Teil des Betafelds 854 ausgelegt als ein Broadcast-Feld 857B, dessen Inhalt unterscheidet, ob die Datenmanipulationsfunktion vom Typ Broadcast durchgeführt werden soll oder nicht, während der Rest des Betafelds 854 ausgelegt wird das Vektorlängenfeld 859B. Die Anweisungstemplates mit Speicherzugriff 820 enthalten das Skalierungsfeld 860, und gegebenenfalls das Verschiebungsfeld 862A oder das Verschiebungsskalierungsfeld 862B.
• Bezüglich des generischen vektorfreundlichen Anweisungsformats 800 ist ein volles Opcode-Feld 874 dargestellt, einschließlich des Formatfelds 840, des Basisfunktionsfelds 842 und des Datenelementbreitenfelds 864. Während eine Ausführungsform dargestellt ist, in der das volle Opcode-Feld 874 alle dieser Felder enthält, enthält das volle Opcode-Feld 874 weniger als alle dieser Felder in Ausführungsformen, die nicht alle davon unterstützen. Das volle Opcode-Feld 874 stellt den Funktionscode (Opcode) zur Verfügung.
• Das Augmentierungsfunktionsfeld 850, das Datenelementbreitenfeld 864 und das Schreibmaskenfeld 870 erlauben die Vorgabe dieser Merkmale auf Grundlage pro Anweisung in dem generischen vektorfreundlichen Anweisungsformat.
• Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugen typisierte Anweisungen, indem sie die Anwendung der Maske basierend auf unterschiedlichen Datenelementbreiten erlauben.
• Die verschiedenen Anweisungstemplates, die in Klasse A und Klasse B zu finden sind, sind in verschiedenen Situationen hilfreich. In einigen Ausführungsformen der Erfindung können verschiedene Prozessoren oder verschiedene Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Beispielsweise kann ein Kern außerhalb der Reihenfolge mit hoher Leistung und für allgemeine Zwecke, der für Rechenaufgaben für allgemeine Zwecke vorgesehen ist, nur Klasse B unterstützen, ein Kern, der vornehmlich für Grafik- und/oder wissenschaftliche (Durchsatz) Berechnung vorgesehen ist, kann nur Klasse A unterstützen, und ein Kern, der für beides vorgesehen ist, kann beides unterstützen (natürlich liegt ein Kern, der eine Mischung aus Templates und Anweisungen aus beiden Klassen aufweist, aber nicht alle Templates und Anweisungen aus beiden Klassen, im Rahmen des Bereichs der Erfindung). Außerdem kann ein einzelner Prozessor mehrere Kerne enthalten, von denen alle dieselbe Klasse unterstützen, oder bei denen verschiedene Kerne verschiedene Klassen unterstützen. Beispielsweise kann bei einem Prozessor mit separaten Kernen für Grafik und allgemeine Zwecke einer der Grafikkerne, die vornehmlich für Grafik- und/oder wissenschaftliche Berechnung vorgesehen sind, nur Klasse A unterstützten, während ein oder mehrere andere der Kerne für allgemeine Zwecke Kerne mit hoher Leistung für allgemeine Zwecke mit Ausführung außerhalb der Reihenfolge und Registerumbenennung sein können, die für Berechnungen für allgemeine Zwecke vorgesehen sind, die nur Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, kann einen oder mehrere Kerne in oder außerhalb der Reihenfolge für allgemeine Zwecke enthalten, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können Merkmale aus einer Klasse auch in den anderen Klassen in unterschiedlichen Ausführungsformen der Erfindung umgesetzt werden. Programme, die in einer High-Level-Sprache geschrieben sind, würden (z. B. bei Bedarf kompiliert oder statisch kompiliert) in eine Vielzahl verschiedener ausführbarer Formen gebracht, einschließlich: 1) einer Form, die nur Anweisungen der Klasse(n) aufweist, die durch den Zielprozessor für die Ausführung unterstützt werden; oder 2) einer Form, die alternative Routinen aufweist, die unter Verwendung verschiedener Kombinationen der Anweisungen aller Klassen geschrieben wurden, und Steuerflusscode aufweisen, der die Routinen, die ausgeführt werden sollen, basierend auf den Anweisungen wählt, die durch den Prozessor unterstützt werden, der aktuell den Code ausführt.
• Beispielhaftes spezifisches vektorfreundliches Anweisungsformat
• 9A-D illustrieren ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat nach Ausführungsformen der Erfindung. Diese zeigen ein spezifisches vektorfreundliches Anweisungsformat 900, das in dem Sinn spezifisch ist, dass es den Ort, die Größe, Auslegung und Reihenfolge der Felder vorgibt, sowie Werte für einige dieser Felder. Das spezifische vektorfreundliche Anweisungsformat 900 kann verwendet werden, um den x86-Anweisungssatz zu erweitern und so sind einige der Felder ähnlich oder gleich wie die, die in dem bestehenden x86-Anweisungssatz und dessen Erweiterung verwendet werden (z. B. AVX). Dieses Format bleibt konsistent mit dem Präfixcodierungsfeld, Real-Opcode-Byte-Feld, MOD-R/M-Feld, SIB-Feld, Verschiebungsfeld und den direkten Feldern des bestehenden x86-Anweisungssatzes mit Erweiterungen. Die Felder von 8, in die die Felder der Karte von 9A-D illustriert sind.
• Es sollte verstanden werden, dass, auch wenn Ausführungsformen der Erfindung mit Verweis auf das spezifische vektorfreundliche Anweisungsformat 900 in dem Kontext des generischen vektorfreundlichen Anweisungsformats 800 für illustrative Zwecke beschriebene sind, die Erfindung nicht beschränkt ist auf das spezifische vektorfreundliche Anweisungsformat 900, außer, wenn dies beansprucht wird. Beispielsweise betrachtet das generische vektorfreundliche Anweisungsformat 800 eine Vielzahl möglicher Größen für die verschiedenen Felder, während das spezifische vektorfreundliche Anweisungsformat 900 als Felder spezifischer Größen aufweisend beschrieben wird. Durch ein spezifisches Beispiel wird, während das Datenelementbreitenfeld 864 in dem spezifischen vektorfreundlichen Anweisungsformat 900 als ein Einbitfeld illustriert ist, die Erfindung nicht so eingeschränkt (d. h. das generische vektorfreundliche Anweisungsformat 800 betrachtet andere Größen des Datenelementbreitenfelds 864).
• Das generische vektorfreundliche Anweisungsformat 800 enthält folgende Felder, die nachfolgend aufgeführt sind, in der Reihenfolge wie in 9A illustriert.
• Das EVEX-Präfix (Bytes 0-3) 902 - ist in einer Vierbyteform codiert.
• Formatfeld 840 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Formatfeld 840 und enthält 0x62 (der eindeutige Wert, der für die Unterscheidung des vektorfreundlichen Anweisungsformats in einer Ausführungsform der Erfindung verwendet wird).
• Die zweiten bis vierten Bytes (EVEX-Bytes 1-3) enthalten eine Anzahl von Bitfeldern, die spezifische Fähigkeiten bereitstellen.
• REX-Feld 905 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX.R-Bit-Feld (EVEX-Byte 1, Bit [7] - R), EVEX.X Bit-Feld (EVEX-Byte 1, Bit [6] - X) und 857BEX-Byte 1, Bit[5] - B). Die EVEX.R, EVEX.X, und EVEX.B Bit-Felder stellen dieselbe Funktionalität zur Verfügung, wie die entsprechenden VEX Bit-Felder, und werden unter Verwendung von 1s Komplementform codiert, d. h. ZMM0 wird codiert als 1111B, ZMM15 wird codiert als 0000B. Andere Felder der Anweisungen codieren die unteren drei Bits der Registerindizes wie auf dem Stand der Technik bekannt (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb gebildet werden können, indem EVEX.R, EVEX.X und EVEX.B addiert werden.
• REX'-Feld 810 - Dies ist der erste Teil des REX'-Felds 810 und ist das EVEX.R'-Bit-Feld (EVEX-Byte 1, Bit [4] - R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. In einer Ausführungsform der Erfindung, wird dieses Bit zusammen mit anderen, wie unten angegeben, in einem bitinvertierten Format gespeichert, um (in dem bekannten x86 32-Bitmodus) von der BOUND-Anweisung zu unterscheiden, deren echtes real Opcode-Byte 62 ist, aber die im MOD-R/M-Feld (nachfolgend beschrieben) nicht den Wert 11 im MOD-Feld annimmt; alternative Ausführungsformen der Erfindung speichern dieses und die anderen angegebenen Bits unten nicht im invertierten Format. Ein Wert 1 wird verwendet, um die unteren 16 Register zu codieren. In anderen Worten: R'Rrrr wird durch Kombination von EVEX.R', EVEX.R und den anderen RRR aus anderen Feldern gebildet.
• Opcode-Kartenfeld 915 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
• Datenelementbreitenfeld 864 (EVEX-Byte 2, Bit [7] - W) - ist dargestellt durch die Notation EVEX.W. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (entweder 32-bit-Datenelemente oder 64-bit-Datenelemente).
• EVEX.vvvv 920 (EVEX-Byte 2, Bits [6:3]-vvvv)- die Rolle von EVEX.vvvv kann Folgendes enthalten: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, vorgegeben in invertierter (ls-Komplement) Form, und gilt für Anweisungen mit 2 oder mehr Quelloperanden; 2) EVEX.vvvv codiert den Zielregisteroperanden, vorgegeben in 1s-Komplementform für bestimmte Vektorverschiebungen; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. So codiert EVEX.vvvv Feld 920 die 4 Bits niedriger Ordnung des ersten Quellregisterspezifizierers, der in invertierter Form (ls-Komplement) gespeichert ist. Abhängig von der Anweisung wird ein zusätzliches anderes EVEX-Bit-Feld verwendet, um die Spezifizierergröße auf 32 Register zu vergrößern.
• EVEX.U 868 Klassefeld (EVEX-Byte 2, Bit [2]-U) - Wenn EVEX.U = 0, gibt es Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, gibt es Klasse B oder EVEX.U1 an.
• Präfixcodierungsfeld 925 (EVEX-Byte 2, Bits [1:0]-pp) - stellt weitere Bits für das Basisfunktionsfeld bereit. Neben der Bereitstellung einer Unterstützung für Alt-SSE-Anweisungen in dem EVEX-Präfixformat hat dies auch den Vorteil der Verdichtung des SIMD-Präfix (statt zu verlangen, dass ein Byte das SIMD-Präfix ausdrückt, verlangt das EVEX-Präfix nur 2 Bits). In einer Ausführungsform sind zur Unterstützung von Alt-SSE-Anweisungen, die ein SIMD-Präfix (66H, F2H, F3H) im Altformat und im EVEX-Präfix-Format verwenden, diese Alt-SIMD-Präfixes in das SIMD-Präfixcodierungsfeld codiert; und in der Runtime werden sie in das Alt-SIMD-Präfix expandiert, bevor sie für das PLA des Decoders bereitgestellt werden (sodass das PLA das Alt- und das EVEX-Format dieser Altanweisungen ohne Änderung ausführen kann). Auch wenn neure Anweisungen den Inhalt des EVEX-Präfixcodierungsfelds direkt als Opcode-Erweiterung verwenden könnten, erweitern sich bestimmte Ausführungsformen in ähnlicher Weise für die Konsistenz, erlauben jedoch die Vorgabe verschiedener Bedeutungen durch diese Alt-SIMD-Präfixes. Eine alternative Ausführungsform kann das PLA neu entwerfen, um die 2-Bit-SIMD-Präfix-Codierungen zu unterstützen, und daher die Erweiterung nicht verlangen.
• Alpha-Feld 852 (EVEX-Byte 3, Bit [7] - EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX. Schreibmaskensteuerung, und EVEX.N; auch illustriert mit α) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.
• Beta Feld 854 (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 illustriert mit βββ) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.
• REX'-Feld 810 - dies ist der Rest des REX'-Felds und das EVEX.V' Bit-Feld (EVEX-Byte 3, Bit [3] - V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. Dieses Bit wird im bitinvertierten Format gespeichert. Ein Wert 1 wird verwendet, um die unteren 16 Register zu codieren. In anderen Worten: V'VVVV wird gebildet, indem EVEX.V', EVEX.vvvv kombiniert werden.
• Schreibmaskenfeld 870 (EVEX-Byte 3, Bits [2:0]-kkk) - sein Inhalt gibt den Index eines Registers in den Schreibmaskenregistern vor, wie zuvor beschrieben. In einer Ausführungsform der Erfindung, weist der spezifische Wert EVEX.kkk=000 ein besonderes Verhalten auf, das impliziert, dass keine Schreibmaske für die bestimmte Anweisung verwendet wird (dies kann in einer Vielzahl von Wegen umgesetzt werden, einschließlich der Verwendung einer Schreibmaske, die fest mit allen verkabelt ist, oder Hardware, die die Maskierungshardware umgeht).
• Das echte Opcode-Feld 930 (Byte 4) ist auch bekannt als das Opcode-Byte. Ein Teil des Opcode wird in diesem Feld vorgegeben.
• Das MOD-R/M-Feld 940 (Byte 5) enthält MOD-Feld 942, Reg-Feld 944 und R/M-Feld 946. Wie zuvor beschrieben unterscheidet der Inhalt des MOD-Felds 942 zwischen Speicherzugriffs- und Nicht-Speicherzugriffs-Funktionen. Die Rolle des Reg-Felds 944 kann auf zwei Situationen zusammengefasst werden: Codierung entweder des Zielregisteroperanden oder eines Quellregisteroperanden, oder Behandlung als Opcode-Erweiterung und keine Verwendung zum Codieren eines Anweisungsoperanden. Die Rolle des R/M-Felds 946 kann Folgendes enthalten: Codierung des Anweisungsoperanden, der sich auf eine Speicheradresse bezieht, oder Codierung von entweder dem Zielregisteroperanden oder einem Quellregisteroperanden.
• Skalierung, Index, Basis- (SIB) Byte (Byte 6) 950 - Wie zuvor beschrieben, wird der Inhalt des Skalierungsfelds 852 zur Speicheradressenerzeugung verwendet. SIB.xxx 954 und SIB.bbb 956 - Die Inhalte dieser Felder wurden zuvor bereits bezüglich der Registerindizes Xxxx und Bbbb erwähnt.
• Verschiebungsfeld 862A (Bytes 7-10) - Wenn das MOD-Feld 942 10 enthält, sind Bytes 7-10 das Verschiebungsfeld 862A, und es funktioniert genau, wie bei der Alt-32-Bit-Verschiebung (disp32) und funktioniert mit Byte-Granularität.
• Verschiebungsfaktorfeld 862B (Byte 7) - wenn das MOD-Feld 942 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 862B. Der Ort dieses Felds ist derselbe wie derjenige der Alt-x86-Anweisungssatz-8-Bit-Verschiebung (disp8), die auf Byte-Granularität funktioniert. Da disp8 ein erweitertes Zeichen ist, kann es nur zwischen -128 und 127 Bytes Abstände adressieren; für 64-Byte-Cachezeilen verwendet disp8 8 Bits, die nur auf die vier wirklich nützlichen Werte -128, -64, 0 und 64 eingestellt werden können; da oft ein größerer Bereich benötigt wird, wird disp32 verwendet; disp32 verlangt jedoch 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 862B eine Reinterpretation von disp8; bei der Verwendung des Verschiebungsfaktorfelds 862B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds bestimmt, multipliziert mit der Größe des Speicheroperandenzugriffs (N). Diese Art von Verschiebung wird als disp8*N bezeichnet. Dies verringert die durchschnittliche Anweisungslänge (ein einzelnes Byte des verwendeten für die Verschiebung, aber 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 daher die redundanten Bits niedriger Ordnung des Adressabstands nicht codiert werden müssen. In anderen Worten: das Verschiebungsfaktorfeld 862B ersetzt die Alt-x86-Anweisungssatz-8-Bit-Verschiebung. Daher ist das Verschiebungsfaktorfeld 862B in derselben Weise codiert, wie eine x86-Anweisungssatz-8-Bit-Verschiebnug (also ohne Änderungen der ModRM/SIB-Codierungsregeln), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird. Anders ausgedrückt, es gibt keine Änderungen in den Codierungsregeln oder Codierungslängen, aber nur in der Auslegung des Verschiebungswerts durch Hardware (die die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen Adressabstand pro Byte zu erhalten). Das direkte Feld 872 funktioniert wie zuvor beschrieben.
• Volles Opcode-Feld
• 9B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 900 illustriert, die das volle Opcode-Feld 874 nach einer Ausführungsform der Erfindung darstellen. Insbesondere enthält das volle Opcode-Feld 874 das Formatfeld 840, das Basisfunktionsfeld 842 und das Datenelementbreite- (W) Feld 864. Das Basisfunktionsfeld 842 enthält das Präfixcodierungsfeld 925, das Opcode-Kartenfeld 915 und das echte Opcode-Feld 930.
• Registerindexfeld
• 9C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 900 illustriert, die das Registerindexfeld 844 nach einer Ausführungsform der Erfindung darstellen. Vor allem enthält das Registerindexfeld 844 das REX-Feld 905, das REX'-Feld 910, das MODR/M.reg-Feld 944, das MODR/M.r/m-Feld 946, das VVVV-Feld 920, xxx-Feld 954 und das bbb-Feld 956.
• Augmentierungsfunktionsfeld
• 9D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 900 illustriert, die das Augmentierungsfunktionsfeld 850 nach einer Ausführungsform der Erfindung darstellen. Wenn das Klasse-(U)-Feld 868 0 enthält, zeigt es EVEX.U0 (Klasse A 868A) an; wenn es 1 enthält, zeigt es EVEX.U1 (Klasse B 868B) an. Wenn U=0 und das MOD-Feld 942 11 enthält (zur Anzeige einer Funktion ohne Speicherzugriff), wird das Alphafeld 852 (EVEX-Byte 3, Bit [7] - EH) als rs-Feld 852A ausgelegt. Wenn das rs-Feld 852A eine 1 enthält (Rundung 852A.1), wird Betafeld 854 (EVEX-Byte 3, Bits [6:4]- SSS) ausgelegt als das Rundungssteuerfeld 854A. Das Rundungssteuerfeld 854A enthält ein Bit-SAE-Feld 856 und ein zwei-Bit-Rundungsfunktionsfeld 858. Wenn das rs-Feld 852A eine 0 (Datentransformation 852A.2) enthält, wird Betafeld 854 (EVEX-Byte 3, Bits [6:4]- SSS) ausgelegt als ein Dreibitdatentransformationsfeld 854B. Wenn U=0 und das MOD-Feld 942 00, 01, oder 10 enthält (Anzeige einer Speicherzugriffsfunktion), wird das Alphafeld 852 (EVEX-Byte 3, Bit [7] - EH) ausgelegt als Räumungshinweis- (EH) Feld 852B und das Betafeld 854 (EVEX-Byte 3, Bits [6:4]- SSS) wird ausgelegt als ein Dreibit-Datenmanipulationsfeld 854C.
• Wenn U=1, wird das Alphafeld 852 (EVEX-Byte 3, Bit [7] - EH) ausgelegt als das Schreibmaskensteuerungs- (Z) Feld 852C. Wenn U=1 und das MOD-Feld 942 11 enthält (was eine Funktion ohne Speicherzugriff darstellt), wird ein Teil des Betafelds 854 (EVEX-Byte 3, Bit [4]-S₀) ausgelegt als das RL-Feld 857A; wenn es eine 1 (Rundung 857A.1) enthält, wird der Rest des Betafelds 854 (EVEX-Byte 3, Bit [6-5]- S_2-1) ausgelegt als das Rundungsfunktionsfeld 859A, während das RL-Feld 857A eine 0 (VSIZE 857.A2) enthält, wird der Rest des Betafelds 854 (EVEX-Byte 3, Bit [6-5]- S_2-1) ausgelegt als das Vektorlängenfeld 859B (EVEX-Byte 3, Bit [6-5]- L_1-0). Wenn U=1 und das MOD-Feld 942 00, 01, oder 10 enthält (was eine Speicherzugriffsfunktion darstellt), wird das Betafeld 854 (EVEX-Byte 3, Bits [6:4]- SSS) ausgelegt als das Vektorlängenfeld 859B (EVEX-Byte 3, Bit [6-5]- L_1-0) und das Broadcast-Feld 857B (EVEX-Byte 3, Bit [4]- B).
• Beispielhafte Registerarchitektur
• 10 ist ein Blockdiagramm einer Registerarchitektur 1000 nach einer Ausführungsform der Erfindung. In der illustrierten Ausführungsform gibt es 32 Vektorregister 1010, die 512 Bits breit sind; diese Register sind als zmm0 bis zmm31 referenziert. Die 256 Bits niedrigerer Ordnung der unteren 16 zmm Register werden auf die Register ymm0-16 überlagert. Die 128 Bits niedrigerer Ordnung der unteren 16 zmm Register (die 128 Bits niedrigerer Ordnung der ymm-Register) werden auf die Register xmm0-15 überlagert. Das spezifische vektorfreundliche Anweisungsformat 900 funktioniert auf dieser überlagerten Registerdatei wie in den folgenden Tabellen dargestellt.

  Einstellbare Vektorlänge	Klasse	Funktionen	Register
  Anweisungstemplates, die nicht das Vektorlängenfeld 859B enthalten	A ( 8A; U=0)	810, 815, 825, 830	zmm-Register (die Vektorlänge beträgt 64 Byte)
  	B ( 8B; U=1)	812	zmm-Register (die Vektorlänge beträgt 64 Byte)
  Anweisungstemplates, die nicht das Vektorlängenfeld 859B enthalten	B ( 8B; U=1)	817, 827	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) abhängig von dem Vektorlängenfeld 859B

• Anders ausgedrückt: das Vektorlängenfeld 859B wählt zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen, wobei jede dieser kürzeren Längen die Hälfte der Länge der vorhergehenden Länge ist; und Anweisungstemplates ohne das Vektorlängenfeld 859B funktionieren auf der maximalen Vektorlänge. Weiter funktionieren in einer Ausführungsform die Klasse-B-Anweisungstemplates des spezifischen vektorfreundlichen Anweisungsformats 900 auf gepackten oder skalaren Einzel-/Doppelpräzisions-Floating-Point-Daten und gepackten oder skalierten Integerdaten. Skalierungsfunktionen sind Funktionen, die auf die Datenelementposition der niedrigsten Ordnung in einem zmm/ymm/xmm-Register ausgeführt werden können; die Datenelementpositionen höherer Ordnung bleiben entweder gleich, wie sie vor der Anweisung waren, oder werden abhängig von der Ausführungsform genullt.
• Schreibmaskenregister 1015 - in der illustrierten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die je 64 Bits groß sind. In einer alternativen Ausführungsform sind die Schreibmaskenregister 1015 16 Bits groß. Wie zuvor beschrieben, kann in einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 anzeigen würde, für eine Schreibmaske verwendet wird, wählt es eine fest verkabelte Schreibmaske von 0xFFFF aus, und deaktiviert damit effektiv die Schreibmaskierung für diese Anweisung.
• Register mit allgemeinem Zweck 1025 - in der illustrierten Ausführungsform gibt es sechzehn 64-Bit-Register für allgemeine Zwecke, die zusammen mit den bestehenden x86-Adressierungsmodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register werden durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, und R8 bis R15 bezeichnet.
• Skalierungs-Floating-Point-Stapelregisterdatei (x87-Stapel) 1045, auf der die MMX-Flachregisterdatei 1050 mit gepackten Integerzahlen gealiast wird - in der dargestellten Ausführungsform ist der x87-Stapel ein Achtelementstapel, der verwendet wird, um skalare Floating-Point-Funktionen auf 32/64/80-Bit-Floating-Point-Daten auszuführen, wobei die x87-Anweisungssatzserweiterung verwendet wird; während die MMX-Register verwendet werden, um Funktionen auf 64-bit gepackten Integerdaten auszuführen, sowie Operanden für einige Funktionen zu halten, die zwischen den MMX- und XMM-Registern ausgeführt werden.
• Alternative Ausführungsformen der Erfindung können breitere und engere Register verwenden. Weiterhin können alternative Ausführungsformen der Erfindung mehr, weniger oder verschiedene Registerdateien und Register verwenden.
• Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
• Prozessorkerne können in verschiedener Weise umgesetzt werden, zu unterschiedlichen Zwecken und in verschiedenen Prozessoren. Beispielsweise können Umsetzungen solcher Kerne enthalten: 1) einen Kern in fester Reihenfolge für allgemeine Zwecke, der für allgemeine Rechnervorgänge vorgesehen ist; 2) einen Hochleistungskern außerhalb der Reihenfolge für allgemeine Zwecke, der für allgemeine Rechnervorgänge vorgesehen ist; 3) einen Spezialzweckkern, der vornehmlich für Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung vorgesehen ist. Umsetzungen verschiedener Prozessoren können enthalten: 1) eine CPU, die einen oder mehrere Kerne in fester Reihenfolge für allgemeine Zwecke enthält, die für allgemeine Rechnervorgänge vorgesehen sind, und/oder einen oder mehrere Kerne außerhalb der Reihenfolge für allgemeine Zwecke, die für allgemeine Rechnervorgänge vorgesehen sind; und 2) einen Coprozessor, der einen oder mehrere Spezialzweckkerne enthält, die vornehmlich für Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung vorgesehen sind. Solche verschiedenen Prozessoren führen zu verschiedenen Computersystemarchitekturen, die enthalten können: 1) den Coprozessor auf einem von der CPU getrennten Chip; 2) den Coprozessor auf einem separaten Die in demselben Paket wie eine CPU; 3) den Coprozessor auf demselben Die wie eine CPU (in welchem Fall ein solcher Coprozessor manchmal als Spezialzwecklogik, wie etwa bei einer integrierten Grafik und/oder wissenschaftlichen (Durchsatz-) Logik, oder als Spezialzweckkerne bezeichnet wird); und 4) ein System auf einem Chip, das auf demselben Die die beschriebene CPU (manchmal bezeichnet als der/die Anwendungskern(e) oder Anwendungsprozessor(en)), den oben beschriebenen Coprozessor und weitere Funktionen enthalten kann. Beispielkernarchitekturen sind als nächstes beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computerarchitekturen.
• Beispielkernarchitekturen
• Kernblockdiagramm in Reihenfolge und außerhalb der Reihenfolge
• 11A ist ein Blockdiagramm, das sowohl eine beispielhafte Pipeline in fester Reihenfolge als auch eine beispielhafte Pipeline für Ausgabe/Ausführung einer Registerumbenennung außerhalb der Reihenfolge nach Ausführungsformen der Erfindung illustriert. 11B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines Architekturkerns in fester Reihenfolge als auch einen beispielhaften Architekturkern für Ausgabe/Ausführung einer Registerumbenennung außerhalb der Reihenfolge, der nach Ausführungsformen der Erfindung in einem Prozessor enthalten sein soll, illustriert. Die durchgezogen umrandeten Kästen in den 11A-B illustrieren die Pipeline in fester Reihenfolge und den Kern in fester Reihenfolge, während die optionale Ergänzung der Kästen mit gestrichelter Linie die Registerumbenennung, die Pipeline und den Kern für die Ausgaben/Ausführung außerhalb der Reihenfolge illustriert. Da der Aspekt der Reihenfolge ein Untersatz des Aspektes außerhalb der Reihenfolge ist, wird der Aspekt außerhalb der Reihenfolge beschrieben.
• In 11A enthält eine Prozessorpipeline 1100 ein Abrufstadium 1102, ein Längendecodierungsstadium 1104, ein Decodierungsstadium 1106, ein Zuordnungsstadium 1108, ein Umbenennungsstadium 1110, ein Planungsstadium (auch bekannt als Absendung oder Ausgabe) 1112, ein Registerlese-/Speicherlesestadium 1114, ein Ausführungsstadium 1116, ein Zurückschreibe-/Speicherschreibestadium 1118, ein Ausnahmenbehandlungsstadium 1122 und ein Zuordnungsstadium 1124.
• 11B zeigt den Prozessorkern 1190, der eine Frontendeinheit 1130 enthält, die mit einer Ausführungsengineeinheit 1150 verknüpft ist, und beide sind mit einer Speichereinheit 1170 verknüpft. Der Kern 1190 kann ein Reduced-Instruction-Set-Computing-(RISC) Kern, ein Complex-Instruction-Set-Computing- (CISC) Kern, ein Very-Long-Instruction-Word- (VLIW) Kern oder ein hybrider oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 1190 ein Spezialzweckkern sein, wie beispielweise ein Netzwerk- oder Kommunikationskern, eine Compression Engine, ein Coprozessorkern, ein General-Purpose-Computing-Graphics-Processing-Unit-(GPGPU) Kern, Grafikkern oder ähnliches.
• Die Frontendeinheit 1130 enthält eine Zweigvorhersageeinheit 1132, die mit einer Anweisungscacheeinheit 1134 verknüpft ist, die mit einem Anweisungs-Translation-Lookaside-Buffer (TLB) 1136 verknüpft ist, der mit einer Anweisungsabholeinheit 1138 verknüpft ist, die mit einer Decodierungseinheit 1140 verknüpft ist. Die Decodierungseinheit 1140 (oder der Decoder) kann Anweisungen decodieren und als Ausgabe eine oder mehrere Mikrooperationen, Mikrocodeeintragepunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale erzeugen, die von den Originalanweisungen decodiert sind, oder diese anderweitig widerspiegeln oder die davon angeleitet sind. Die Decodierungseinheit 1140 kann unter Verwendung verschiedener anderer Mechanismen umgesetzt werden. Beispiele geeigneter Mechanismen enthalten, sind jedoch nicht beschränkt auf Nachschlagetabellen, Hardwareumsetzungen, programmierbare Logikarrays (PLAs), Mikrocode-Read-Only-Memories (ROMs) usw. In einer Ausführungsform enthält der Kern 1190 ein Mikrocode-ROM- oder anderes Medium, das Mikrocode für bestimmte Makroanweisungen speichert (z. B. in der Decodierungseinheit 1140 oder anderweitig innerhalb der Frontendeinheit 1130). Die Decodierungseinheit 1140 ist in Ausführungsengineeinheit 1150 mit einer Umbenennungs-/Zuweisereinheit 1152 verknüpft.
• Die Ausführungsengineeinheit 1150 enthält die Umbenennungs-/Zuweisereinheit 1152, die mit einer Rückzugseinheit 1154 und einem Satz einer oder mehrerer Planereinheit(en) 1156 verknüpft ist. Die Planereinheit(en) 1156 stellen eine beliebige Anzahl verschiedener Planer, einschließlich Reservierungsstationen, eines zentralen Anweisungsfensters usw. dar. Die Planereinheit(en) 1156 sind mit der/den physischen Registerdatei(en)einheit(en) 1158 verknüpft. Jede der physischen Registerdatei(en)einheiten 1158 stellt eine oder mehrere physische Registerdateien dar, von denen verschiedene eine oder mehrere verschiedene Datentypen speichern, wie etwa Scalar Integer, Scalar Floating Point, Packed Integer, Packed Floating Point, Vector Integer, Vector Floating Point, Status (z. B. ein Anweisungszeiger, der die Adresse der nächsten Anweisung ist, die ausgeführt werden soll) usw. In einer Ausführungsform umfasst die physische Registerdatei(en)einheit 1158 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Register zu allgemeinen Zwecken bereitstellen. Die physischen Registerdatei(en)einheit(en) 1158 werden durch die Rückzugseinheit 1154 überlappt, um verschiedene Wege zu illustrieren, in denen die Registerumgebung und Ausführung außerhalb der Reihenfolge umgesetzt werden können (z. B. unter Verwendung eines oder mehrerer Umsortierungspuffer und einer oder mehrerer Rückzugsregisterdatei(en); unter Verwendung einer oder mehrerer künftiger Datei(en), eines oder mehrerer Verlaufspuffer und einer oder mehrerer Rüchzugsregisterdatei(en); unter Verwendung einer Registerkarten und eines Pools von Registern; usw.). Die Rückzugseinheit 1154 und die physische(n) Registerdatei(en)einheit(en) 1158 sind mit dem/den Ausführungscluster(n) 1160 verknüpft. Das/die Ausführungscluster 1160 enthalten einen Satz einer oder mehrerer Ausführungseinheiten 1162 und einen Satz einer oder mehrerer Speicherzugriffseinheiten 1164. Die Ausführungseinheiten 1162 können verschiedene Funktionen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und auf verschiedenen Arten von Daten (z. B. Scalar Floating Point, Packed Integer, Packed Floating Point, Vector Integer, Vector Floating Point) durchführen. Während einige Ausführungsformen eine Reihe von Ausführungseinheiten speziell für spezifische Funktionen oder Funktionssätze enthalten können, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle Funktionen durchführen. Die Planereinheit(en) 1156, physische(n) Registerdatei(en)einheit(en) 1158, und Ausführungscluster 1160 sind als möglicherweise im Plural dargestellt, weil bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Funktionen erstellen (z. B. eine Scalar-Integer-Pipeline, eine Scalar-Floating-Point/Packed-Integer/Packed-Floating-Point/Vector-Integer/Vector-Floating-Point-Pipeline, und/oder eine Speicherzugriffspipeline, die jeweils eine eigene Planereinheit, physische Registerdatei(en)einheit, und/oder Ausführungscluster aufweisen - und im Fall einer separaten Speicherzugriffspipeline sind bestimmte Ausführungsformen umgesetzt, in denen nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 1164 aufweist). Es sollte auch verstanden werden, dass, wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines außerhalb der Reihenfolge ausgegeben/ausgeführt werden können, und der Rest in der Reihenfolge.
• Dieser Satz Speicherzugriffseinheiten 1164 ist mit der Speichereinheit 1170 verknüpft, die eine Daten-TLB-Einheit 1172 enthält, die mit einer Datencacheeinheit 1174 verknüpft ist, die mit einer Level-2- (L2) Cacheeinheit 1176 verknüpft ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 1164 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit enthalten, von denen jede mit der Daten-TLB-Einheit 1172 in der Speichereinheit 1170 verknüpft ist. Die Anweisungscacheeinheit 1134 ist ferner mit einer Level-2- (L2) Cacheeinheit 1176 in der Speichereinheit 1170 verknüpft. Die L2-Cacheeinheit 1176 ist mit einer oder mehreren anderen Ebenen des Cache und schließlich mit einem Hauptspeicher verknüpft.
• Beispielhaft kann die Kernarchitektur für beispielhafte Registerumbenennung zur Ausgabe/Ausführung außerhalb der Reihenfolge die Pipeline 1100 wie folgt umsetzen: 1) Der Anweisungsabruf 1138 führt die Abruf- und Längendecodierungsstadien 1102 und 1104 durch; 2) die Decodierungseinheit 1140 führt das Decodierungsstadium 1106 durch; 3) die Umbenennungs-/Zuweisereinheit 1152 führt das Zuordnungsstadium 1108 und das Umbenennungsstadium 1110 durch; 4) die Planereinheit(en) 1156 führen das Planungsstadium 1112 durch; 5) die physischen Registerdatei(en)einheit(en) 1158 und die Speichereinheit 1170 führen das Registerlese-/Speicherlesestadium 1114 durch; der Ausführungscluster 1160 führt das Ausführungsstadium 1116 durch; 6) die Speichereinheit 1170 und die physischen Registerdatei(en)einheit(en) 1158 führen das Zurückschreibe-/Speicherschreibestadium 1118 aus; 7) verschiedene Einheiten können an dem Ausnahmebehandlungsstadium 1122 beteiligt sein; und 8) die Rückzugseinheit 1154 und die physischen Registerdatei(en)einheit(en) 1158 führen das Zuweisungsstadium 1124 aus.
• Der Kern 1190 kann einen oder mehrere Anweisungssätze unterstützen (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt wurden); den MIPS-Anweisungssatz der MIPS Technologies von Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen weiteren Erweiterungen wie NEON) von ARM Holdings aus Sunnyvale, CA), einschließlich der hierin beschriebenen Anweisung(en). In einer Ausführungsform enthält der Kern 1190 eine Logik zur Unterstützung einer gepackten Datenanweisungssatzerweiterung (z. B. AVX1, AVX2), wodurch ermöglicht wird, dass die Funktionen, die durch viele Multimediaanwendungen verwendet werden, unter Verwendung gepackter Daten ausgeführt werden.
• Es ist zu verstehen, dass der Kern Multithreading unterstützt (Ausführung von zwei oder mehr parallelen Funktionssätzen oder Threads), und dies auf eine Vielzahl von Wegen tun kann, einschließlich Time-Sliced Multithreading, simultanes Multithreading (wobei ein einziger physischer Kern einen logischen Kern für jeden der Threads bereitstellt, die der physische Kern simultan einem Multithreading unterzieht), oder einer Kombination davon (z. B. Time-Sliced-Abruf und Decodierung und simultanes Multithreading danach, wie etwa in der Intel® Hyperthreading-Technologie).
• Während die Registerumbenennung im Zusammenhang der Ausführung außerhalb der Reihenfolge beschrieben wird, sollte verstanden werden, dass die Registerumbenennung in einer Architektur innerhalb der Reihenfolge verwendet wird. Während die illustrierte Ausführungsform des Prozessors auch separate Anweisungs- und Datencacheeinheiten 1134/1174 und eine geteilte L2-Cacheeinheit 1176 enthält, können alternative Ausführungsformen einen einzigen internen Cache für Anweisungen und Daten gleichermaßen enthalten, wie etwa einen internen Level-1 (L1) Cache oder mehrere Ebenen eines internen Caches. In einigen Ausführungsformen kann das System eine Kombination eines internen Caches und eines externen Caches enthalten, der außerhalb des Kerns und/oder des Prozessors liegt. Alternativ kann der gesamte Cache außerhalb des Kerns und/oder des Prozessors liegen.
• Spezifische beispielhafte Kernarchitektur in fester Reihenfolge
• 12A-B illustrieren ein Blockdiagramm einer Architektur eines spezifischeren beispielhaften Kerns in fester Reihenfolge, wobei der Kern einer von mehreren Logikblocks (der andere Kerne desselben Typs und/oder anderer Typen enthält) auf einem Chip wäre. Die Logikblöcke kommunizieren durch ein Verbindungsnetzwerk mit hoher Bandbreite (z. B. ein Ringnetzwerk) mit einer Logik mit fester Funktion, Speicher-E/A-Schnittstellen und einer anderen notwendigen E/A-Logik, abhängig von der Anwendung.
• 12A ist ein Blockdiagramm eines einzigen Prozessorkerns, zusammen mit der Verbindung mit dem Verbindungsnetzwerk 1202 auf dem Die, und mit dem örtlichen Untersatz des Level-2- (L2) Cache 1204 nach Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Anweisungsdecoder 1200 den x86-Anweeisungssatz mit einer gepackten Datenanweisungssatzerweiterung. Ein L1-Cache 1206 erlaubt Zugriffe mit geringer Latenz auf den Cachespeicher in die skalaren und Vektoreinheiten. Während in einer Ausführungsform (zur Vereinfachung des Designs) eine skalare Einheit 1208 und eine Vektoreinheit 1210 separate Registersätze verwenden (bzw. skalare Register 1212 und Vektorregister 1214) und Daten, die zwischen ihnen übertragen werden, in den Speicher geschrieben und dann von einem Level-1- (L1) Cache 1206 wieder ausgelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verfolgen (z. B. Verwendung eines einzelnen Registersatzes oder Enthalten eines Kommunikationspfads, der es erlaubt, Daten zwischen den zwei Registerdateien zu übertragen, ohne geschrieben und zurückgelesen zu werden).
• Der örtliche Untersatz des L2-Cache 1204 ist ein Abschnitt eines globalen L2-Caches, das in separate örtliche Untersätze unterteilt ist, und zwar in einen pro Prozessorkern. Jeder Prozessorkern weist einen direkten Zugriffspfad auf seinen eigenen örtlichen Untersatz des L2-Cache 1204 auf. Daten, die von einem Prozessorkern gelesen werden, werden in seinem L2-Cache-Untersatz 1204 gespeichert und sind parallel zu anderen Prozessorkernen, die auf ihre eigenen örtlichen L2-Cache-Untersätze zugreifen, für schnellen Zugriff zugänglich. Daten, die durch einen Prozessorkern geschrieben werden, werden in ihrem eigenen L2-Cache-Untersatz 1204 gespeichert und werden von anderen Untersätzen bei Bedarf geflusht. Das Ringnetzwerk stellt die Kohärenz für geteilte Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten wie Prozessorkernen, L2-Caches und anderen Logikblocks zu erlauben, miteinander innerhalb des Chips zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012 Bits breit.
• 12B ist eine erweiterte Ansicht eines Abschnitts des Prozessorkerns in 12A nach Ausführungsformen der Erfindung. 12B enthält einen L1-Datencache- 1206A Abschnitt des L1-Cache 1204, sowie weitere Details bezüglich der Vektoreinheit 1210 und der Vektorregister 1214. Speziell ist die Vektoreinheit 1210 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 1228), die eine oder mehrere der Integer-, Single-Precision-Float-und Double-Precision-Float-Anweisungen ausführt. Die VPU unterstützt Swizzling der Registereingaben mit der Swizzleeinheit 1220, numerische Umwandlung mit den numerischen Umwandlungseinheiten 1222A-B und Replizieren mit der Replizierungseinheit 1224 auf dem Speichereingang. Schreibmaskenregister 1226 erlauben die Vorhersagen daraus entstehender Vektorschreibvorgänge.
• 13 ist ein Blockdiagramm eines Prozessors 1300, der mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafik aufweisen kann, nach Ausführungsformen der Erfindung. Die Kästen mit durchgezogenen Linien in 13 illustrieren einen Prozessor 1300 mit einem einzelnen Kern 1302A, einen Systemagenten 1310, einen Satz von einer oder mehreren Buscontrollereinheiten 1316, während die optionale Ergänzung der Kästen mit gestrichelten Linien einen alternativen Prozessor 1300 mit mehreren Kernen 1302A-N, einen Satz von einer oder mehreren integrierten Speichercontrollereinheit(en) 1314 in der Systemagenteneinheit 1310, und Spezialzwecklogik 1308 enthält.
• So können verschiedene Umsetzungen des Prozessors 1300 enthalten: 1) eine CPU, in der die Spezialzwecklogik 1308 eine integrierte Grafik- und/oder wissenschaftliche (Durchsatz-) Logik ist (die einen oder mehrere Kerne enthalten kann), und die Kerne 1302A-N ein oder mehrere Kerne für einen allgemeinen Zweck sein können (z. B. Kerne für einen allgemeinen Zweck in fester Reihenfolge, Kerne für einen allgemeinen Zweck außerhalb der Reihenfolge, eine Kombination der beiden); 2) einen Coprozessor, bei dem die Kerne 1302A-N eine große Anzahl an Spezialzweckkernen sind, die vornehmlich für Grafik- und/oder wissenschaftliche (Durchsatz-)Zwecke vorgesehen sind; und 3) einen Coprozessor, in dem die Kerne 1302A-N eine große Anzahl von Kernen für einen allgemeinen Zweck in fester Reihenfolge sind. So kann der Prozessor 1300 ein Prozessor für einen allgemeinen Zweck, ein Coprozessor oder ein Spezialzweckprozessor sein, wie etwa beispielsweise ein Netzwerk- oder Kommunikationsprozessor, eine Compression Engine, ein Grafikprozessor, eine GPGPU (General Purpose Graphics Processing Unit), ein Many-Integrated-Core- (MIC) Coprozessor mit hohem Durchsatz (einschließlich 30 oder mehr Kernen), ein eingebetteter Prozessor oder etwas Ähnliches. Der Prozessor kann auf einem oder mehreren Chips umgesetzt sein. Der Prozessor 1300 kann ein Bestandteil von einem oder mehreren Substraten sein, die eine aus einer Reihe von Prozesstechnologien verwenden, wie etwa beispielweise BiCMOS, CMOS oder NMOS, und/oder darauf umgesetzt sein.
• Die Speicherhierarchie enthält eine oder mehrere Ebenen des Caches 1304A-N innerhalb der Kerne, einen Satz oder eine oder mehrere geteilte Cacheeinheiten 1306 und externen Speicher (nicht dargestellt), der mit dem Satz integrierter Speichercontrollereinheiten 1314 verknüpft ist. Der Satz geteilter Cacheeinheiten 1306 kann einen oder mehrere Caches auf mittlerer Ebene enthalten, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cacheebenen, einen Last-Level-Cache (LLC) und/oder Kombinationen davon. Während in einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 1312 die integrierte Grafiklogik 1308, den Satz geteilter Cacheeinheiten 1306 und die Systemagenteneinheit 1310/integrierte Speichercontrollereinheit(en) 1314 verbindet, können alternative Ausführungsformen eine beliebige Anzahl gut bekannter Techniken für die Zwischenverbindung solcher Einheiten verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Cacheeinheiten 1306 und Kernen 1302-A-N aufrechterhalten.
• In einigen Ausführungsformen sind ein oder mehrere der Kerne 1302A-N in der Lage, Multithreading auszuführen. Der Systemagent 1310 enthält die Bestandteile, die die Kerne 1302A-N koordinieren und bedienen. Die Systemagenteneinheit 1310 kann beispielsweise eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit enthalten. Die PCU kann Logik und Bauteile darstellen oder enthalten, die für die Regulierung des Leistungszustands der Kerne 1302A-N und die integrierte Grafiklogik 1308 erforderlich sind. Die Anzeigeeinheit dient dem Betrieb von einer oder mehreren extern verbundenen Anzeigen.
• Die Kerne 1302A-N können den Architekturanweisungssatz betreffend homogen oder heterogen sein; dies bedeutet, dass zwei oder mehr der Kerne 1302A-N in der Lage sein können, denselben Anweisungssatz auszuführen, während andere in der Lage sein können, nur einen Untersatz des Anweisungssatzes oder einen anderen Anweisungssatz auszuführen.
• Beispielhafte Computerarchitekturen
• 14-16 sind Blockdiagramme beispielhafter Computerarchitekturen. Andere Systemdesigns und Konfigurationen, die in der Technik für Laptops, Desktops, Handheld PCs, Personal Digital Assistants, Engineering-Workstations, Server, Netzwerkvorrichtungen, Netzwerkhubs, Switches, eingebettete Prozessoren, Digital Signal Processors (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrocontroller, Handys, tragbare Mediaplayer, tragbare Vorrichtungen und verschiedene andere elektrische Vorrichtungen verwendet werden können, eignen sich ebenfalls. Allgemein sind eine riesige Vielzahl an Systemen oder elektrischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, einzuschließen, allgemein geeignet.
• Nun wird mit Verweis auf 14 ein Blockdiagramm eines Systems 1400 nach einer Ausführungsform der vorliegenden Erfindung dargestellt. Das System 1400 kann einen oder mehrere Prozessoren 1410, 1415 enthalten, die mit einem Controllerhub 1420 verknüpft sind. In einer Ausführungsform enthält der Controllerhub 1420 einen Grafikspeicher-Controllerhub (GMCH) 1490 und einen Eingabe-/Ausgabehub (IOH) 1450 (der auf separaten Chips vorhanden sein kann); der GMCH 1490 enthält Speicher- und Grafikcontroller, mit denen Speicher 1440 und ein Coprozessor 1445 verknüpft sind; der IOH 1450 ist mit Eingabe-/Ausgabe- (E/A) Vorrichtungen 1460 mit dem GMCH 1490 verknüpft. Alternativ sind ein oder beide Speicher und Grafikcontroller innerhalb des Prozessors (wie hierin beschrieben) integriert, der Speicher 1440 und der Coprozessor 1445 sind direkt mit dem Prozessor 1410 und dem Controllerhub 1420 in einem einzigen Chip mit dem IOH 1450 verknüpft.
• Die optionale Art der weiteren Prozessoren 1415 ist in 14 mit unterbrochenen Linien markiert. Jeder Prozessor 1410, 1415 kann einen oder mehrere der Verarbeitungskerne enthalten, die hierin beschrieben sind, und kann eine Version des Prozessors 1300 darstellen.
• Der Speicher 1440 kann beispielsweise ein Dynamic Random Access Memory (DRAM), Phase Change Memory (PCM) oder eine Kombination aus den beiden sein. Für mindestens eine Ausführungsform kommuniziert der Controllerhub 1420 mit dem/den Prozessor(en) 1410, 1415 über einen Multi-Drop Bus, wie etwa einen Frontside Bus (FSB), Point-to-Point-Schnittstelle wie QuickPath Interconnect (QPI), oder eine ähnliche Verbindung 1495.
• In einer Ausführungsform ist der Coprozessor 1445 ein Spezialzweckprozessor, wie etwa beispielweise ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Compression Engine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder etwas Ähnliches. In einer Ausführungsform kann der Controllerhub 1420 einen integrierten Grafikbeschleuniger enthalten.
• Es kann eine Vielzahl von Unterschieden zwischen den physischen Ressourcen 1410, 1415 geben, was ein Spektrum von Metriken von Vorteil betrifft, einschließlich architektonischer, mikroarchitektonischer, thermaler, Leistungsverbrauchseigenschaften und dergleichen.
• In einer Ausführungsform führt der Prozessor 1410 Anweisungen aus, die Datenverarbeitungsfunktionen einer allgemeinen Art steuern. Innerhalb der Anweisungen können Coprozessor-Anweisungen eingebettet sein. Der Prozessor 1410 erkennt diese Coprozessor-Anweisungen als von einer bestimmten Art, die durch den beiliegenden Coprozessor 1445 ausgeführt werden sollten. Dementsprechend gibt der Prozessor 1410 diese Coprozessor-Anweisungen (oder Steuersignale, die Coprozessor-Anweisungen darstellen) auf einem Coprozessor-Bus oder einer anderen Verbindung an den Coprozessor 1445 aus. Der/die Coprozessor(en) 1445 nehmen die empfangenen Coprozessor-Anweisungen an und führen sie aus.
• Nun wird mit Verweis auf 15 ein Blockdiagramm eines ersten spezifischeren Beispielsystems 1500 nach einer Ausführungsform der vorliegenden Erfindung dargestellt. Wie in 15 dargestellt, ist ein Multiprozessorsystem 1500 ein Punkt-zu-Punkt Verbindungssystem, und enthält einen ersten Prozessor 1570 und einen zweiten Prozessor 1580, die über eine Punkt-zu-Punkt-Verbindung 1550 verknüpft sind. Jeder der Prozessoren 1570 und 1580 kann eine Version von Prozessor 1300 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 1570 und 1580 jeweils Prozessoren 1410 und 1415, während der Coprozessor 1538 Coprozessor 1445 ist. In einer anderen Ausführungsform sind die Prozessoren 1570 und 1580 jeweils Prozessor 1410 Coprozessor 1445.
• Die Prozessoren 1570 und 1580 sind dargestellt als Integrated Memory Controller (IMC) Einheiten 1572 bzw. 1582 enthaltend. Der Prozessor 1570 enthält auch als Bestandteil seiner Buscontrollereinheiten Punkt-zu-Punkt- (P-P) Schnittstellen 1576 und 1578; ebenso enthält der zweite Prozessor 1580 P-P-Schnittstellen 1586 und 1588. Die Prozessoren 1570, 1580 können Informationen über eine Punkt-zu-Punkt- (P-P) Schnittstelle 1550 unter Verwendung von P-P-Schnittstellenschaltkreisen 1578, 1588 austauschen. Wie in 15 dargestellt, verknüpfen die IMCs 1572 und 1582 die Prozessoren mit jeweiligen Speichern, namentlich einem Speicher 1532 und einem Speicher 1534, die Abschnitte des Hauptspeichers sein können, die örtlich mit den jeweiligen Prozessoren verbunden sind.
• Die Prozessoren 1570, 1580 können jeweils unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltkreisen 1576, 1594, 1586, 1598 Informationen mit einem Chipsatz 1590 über einzelne P-P-Schnittstellen 1552, 1554 austauschen. Chipsatz 1590 kann optional Informationen mit dem Coprozessor 1538 über eine Hochleistungsschnittstelle 1592 austauschen. In einer Ausführungsform ist der Coprozessor 1538 ein Spezialzweckprozessor, wie etwa beispielweise ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Compression Engine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder etwas Ähnliches.
• Ein geteilter Cache (nicht dargestellt) kann in jedem der Prozessoren oder außerhalb der beiden Prozessoren enthalten sein, aber mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die örtlichen Cacheinformationen von einem oder beiden Prozessoren in einem geteilten Cache gespeichert sein können, wenn ein Prozessor in den niedrigen Leistungsmodus geschaltet wird.
• Chipsatz 1590 kann mit einem ersten Bus 1516 über eine Schnittstelle 1596 verknüpft sein. In einer Ausführungsform kann der erste Bus 1516 ein Peripheral-Component-Interconnect-(PCI) Bus sein, oder ein Bus wie ein PCI-Express-Bus oder ein anderer Bus für eine E/A-Verbindung der dritten Generation, auch wenn der Umfang der vorliegenden Erfindung nicht darauf beschränkt ist.
• Wie in 15 dargestellt, können verschiedene E/A-Vorrichtungen 1514 mit dem ersten Bus 1516 verknüpft sein, zusammen mit einer Busbrücke 1518, die den ersten Bus 1516 mit einem zweiten Bus 1520 verknüpft. In einer Ausführungsform sind ein oder mehrere weitere Prozessor(en) 1515, wie etwa Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie etwa z. B. Grafikbeschleuniger oder digitale Signalverarbeitungs- (DSP) Einheiten), im Feld programmierbare Gatearrays oder jeder andere Prozessor mit dem ersten Bus 1516 verknüpft. In einer Ausführungsform kann der zweite Bus 1520 ein Low-Pin-Count- (LPC) Bus sein. Verschiedene Vorrichtungen können mit einem zweiten Bus 1520 verknüpft sein, einschließlich beispielweise einer Tastatur und/oder Maus 1522, Kommunikationsvorrichtungen 1527 und einer Speichereinheit 1528 wie etwa eines Festplattenlaufwerks oder einer anderen Massespeichervorrichtung, die Anweisungen/Code und Daten 1530 enthalten können, in einer Ausführungsform. Weiterhin kann eine Audio-E/A 1524 mit dem zweiten Bus 1520 verknüpft werden. Beachten Sie, dass andere Architekturen möglich sind. Beispielsweise kann statt der Punkt-zu-Punkt-Architektur von 15 ein System einen Multi-Drop-Bus oder eine andere solche Architektur umsetzen.
• Nun wird mit Verweis auf 16 ein Blockdiagramm eines zweiten spezifischeren Beispielsystems 1600 nach einer Ausführungsform der vorliegenden Erfindung dargestellt. Gleiche Elemente in 15 und 16 tragen gleiche Referenzziffern und bestimmte Aspekte von 15 wurden in 16 ausgelassen, um das Verdecken anderer Aspekte von 16 zu vermeiden.
• 16 illustriert, dass die Prozessoren 1570, 1580 einen integrierten Speicher und eine E/A-Steuerlogik („CL“) 1572 bzw. 1582 enthalten können. So enthalten die CL 1572, 1582 integrierte Speichercontrollereinheiten und eine E/A-Steuerlogik. 16 illustriert, dass nicht nur die Speicher 1532, 1534 mit der CL 1572, 1582 verknüpft sind, sondern auch dass E/A-Vorrichtungen 1614 ebenfalls mit der Steuerlogik 1572, 1582 verknüpft sind. Alt-E/A-Vorrichtungen 1615 sind mit dem Chipsatz 1590 verknüpft.
• Nun wird mit Verweis auf 16 ein Blockdiagramm eines SoC 1600 nach einer Ausführungsform der vorliegenden Erfindung dargestellt. Gleiche Elemente in 13 tragen gleiche Referenzziffern. Außerdem sind gestrichelte Kästen optionale Funktionen auf fortschrittlicheren SoCs. In 16 sind eine oder mehrere Verbindungseinheit(en) 1602 verknüpft mit: einem Anwendungsprozessor 1610, der einen Satz mit einem oder mehreren Kernen 1302A-N, Cache 1304A-N und geteilte Cache-Einheit(en) 1306 enthält; einer Systemagenteneinheit 1310; einer oder mehreren Buscontrollereinheit(en) 1316; einer oder mehreren integrierten Speichercontrollereinheit(en) 1314; einem Satz von einem oder mehreren Coprozessoren 1620, die eine integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor enthalten; einer Static Random Access Memory (SRAM) Einheit 1630; einer Direct Memory Access (DMA) Einheit 1632; und einer Anzeigeeinheit 1640 für die Verbindung mit einer oder mehreren externen Anzeigen. In einer Ausführungsform enthält/enthalten der/die Coprozessor(en) 1620 einen Spezialzweckprozessor, wie etwa beispielweise einen Netzwerk- oder Kommunikationsprozessor, eine Compression Engine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder etwas Ähnliches.
• Ausführungsformen der hierin offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Umsetzungsansätze umgesetzt werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode umgesetzt werden, der auf programmierbaren Systemen ausgeführt wird, die mindestens einen Prozessor, ein Speichersystem (einschließlich flüchtigen und nichtflüchtigen Speichers und/oder Speicherelementen), mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung umfassen.
• Programmcode, wie etwa Code 1530, der in 15 illustriert ist, kann auf Eingabeanweisungen angewendet werden, um die Funktionen auszuführen, die hierin beschrieben sind, und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können auf eine oder mehrere Ausgabevorrichtungen in bekannter Weise angewendet werden. Zum Zweck dieser Anmeldung enthält ein Verarbeitungssystem jedes System, das einen Prozessor aufweist, wie etwa beispielsweise: einen Digital Signal Processor (DSP), einen Mikrocontroller, einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder einen Mikroprozessor.
• Der Programmcode kann in einer High-Level-Procedural oder einer objektorientierten Programmiersprache umgesetzt werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch in der Baugruppen- oder Maschinensprache umgesetzt werden, wenn dies gewünscht wird. In der Tat sind die hier beschriebenen Mechanismen im Umfang nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
• Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Anweisungen umgesetzt werden, die auf einem maschinenlesbaren Medium gespeichert sind, das unterschiedliche Logik innerhalb des Prozessors darstellt, was nach Lesen durch eine Maschine dazu führt, dass die Maschine eine Logik herstellt, um die hierin beschriebenen Techniken auszuführen. Solche Darstellungen, bekannt als „IP-Kerne“, können auf einem greifbaren maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, um in die Herstellungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich ausmachen.
• Solche maschinenlesbaren Speichermedien können ohne Einschränkung enthalten: nichttransitorische, greifbare Anordnungen von Artikeln, die durch eine Maschine oder Vorrichtung hergestellt oder gebildet sind, einschließlich Speichermedien wie Festplatten, andere Arten von Disketten, einschließlich Floppy Disks, optische Disks, Compact Disc Read-Only Memories (CD-ROMs), Compact Disk Rewritables (CD-RWs) und magnetooptische Disketten, Halbleitervorrichtungen wie Read-Only Memories (ROMs), Random Access Memories (RAMs) wie Dynamic Random Access Memories (DRAMs), Static Random Access Memories (SRAMs), Erasable Programmable Read-Only Memories (EPROMs), Flashspeicher, Electrically Erasable Programmable Read-Only Memories (EEPROMs), Phase Change Memories (PCM), magnetische oder optische Karten oder jede andere Art von Medien, die sich für das Speichern elektronischer Anweisungen eignet.
• Dementsprechend können Ausführungsformen der Erfindung auch nichttransitorische greifbare maschinenlesbare Medien enthalten, die Anweisungen enthalten oder Designdaten enthalten, wie etwa Hardware Description Language (HDL), die Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemeigenschaften definiert, die hierin beschrieben sind. Diese Ausführungsformen können auch als Programmprodukte bezeichnet sein.
• Emulation (einschließlich binärer Übersetzung, Code Morphing usw.)
• In einigen Fällen kann ein Anweisungsumwandler verwendet werden, um eine Anweisung von einem Quellanweisungssatz auf einen Zielanweisungssatz umzuwandeln. Beispielsweise kann der Anweisungsumwandler eine Anweisung in eine oder mehrere andere Anweisungen übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischer Kompilierung), morphen, emulieren oder anderweitig umwandeln, die durch den Kern verarbeitet werden sollen. Der Anweisungsumwandler kann in Software, Hardware, Firmware oder einer Kombination davon umgesetzt werden. Der Anweisungsumwandler kann auf dem Prozessor, außerhalb des Prozessors oder teilweise auf und teilweise außerhalb des Prozessors sein.
• 17 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungsumwandlers zur Umwandlung binärer Anweisungen in einem Quellanweisungssatz auf binäre Anweisungen in einem Zielanweisungssatz, nach Ausführungsformen der Erfindung gegenüberstellt. In der illustrierten Ausführungsform ist der Anweisungsumwandler ein Softwareanweisungsumwandler, wenn auch alternativ der Anweisungsumwandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon umgesetzt sein kann. 17 zeigt, dass ein Programm in einer High-Level-Sprache 1702 unter Verwendung eines x86-Compilers 1704 kompiliert werden kann, um x86 Binärcode 1706 zu erzeugen, der nativ mit mindestens einem x86-Anweisungssatzkern 1716 durch einen Prozessor ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Anweisungssatzkern 1716 stellt einen beliebigen Prozessor dar, der im Wesentlichen dieselben Funktionen ausführen kann, wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern durch kompatible Ausführung oder andere Verarbeitung (1) eines wesentlichen Abschnitts des Anweisungssatzes des Intel-x86-Anweisungssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, die darauf abzielen, auf einem Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern zu laufen, um im Wesentlichen dasselbe Ergebnis zu erreichen, wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern. Der x86-Compiler 1704 stellt einen Compiler dar, der bedient werden kann, um x86 Binärcode 1706 zu erzeugen (z. B. Objektcode), der mit oder ohne weitere Verbindungsverarbeitung auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 1716 ausgeführt werden kann. Ebenso zeigt 17, dass das Programm in der High-Level-Sprache 1702 unter Verwendung eines alternativen Anweisungssatzcompilers 1708 kompiliert werden kann, um einen alternativen Anwendungssatzbinärcode 1710 zu erzeugen, der nativ durch einen Prozessor ohne mindestens einen x86-Anweisungssatzkern 1714 (z. B. einen Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies aus Sunnyvale, CA, ausführen und/oder die den ARM-Anwendungssatz von ARM Holdings aus Sunnyvale, CA, ausführen) ausgeführt werden kann. Der Anweisungsumwandler 1712 wird verwendet, um den x86-Binärcode 1706 in Code umzuwandeln, der nativ durch den Prozessor ohne einen x86-Anweisungssatzkern 1714 ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht derselbe wie der Binärcode 1710 des alternativen Anwendungssatzes, da ein Anweisungsumwandler, der hierzu in der Lage ist, schwer herzustellen ist; der umgewandelte Code wird jedoch die allgemeine Funktion erreichen und aus Anweisungen aus einem alternativen Anweisungssatz bestehen. So stellt der Anweisungsumwandler 1712 Software, Firmware, Hardware oder eine Kombination davon dar, die durch Emulation, Simulation oder einen anderen Ablauf einem Prozessor oder einer anderen elektrischen Vorrichtung, die keinen x86-Anweisungssatzprozessor oder -kern aufweist, erlaubt, den x86-Binärcode 1706 auszuführen.

Claims (25)

1. Vorrichtung, umfassend: ein Decodermittel, um eine Anweisung zu decodieren, wobei die Anweisung mindestens einen Opcode, ein Feld für mindestens zwei Quelloperanden für gepackte Daten, ein Feld für einen Zieloperanden für gepackte Daten, und eine Direkte enthält; und Ausführungsmittel zur Ausführung der decodierten Anweisung zum Laden gepackter Datenelemente von den mindestens zwei Quelloperanden für gepackte Daten unter Verwendung eines Strides und Speichern der Ergebnisse der Strided-Ladevorgänge in den Zieloperanden für gepackte Daten, beginnend an einer definierten Position, die teilweise von der Direkten bestimmt wird.
2. Vorrichtung nach Anspruch 1, wobei die Quelloperanden für gepackte Daten verkettetet sind.
3. Vorrichtung nach einem der Ansprüche 1 bis 2, wobei die definierte Position durch einen Rundungswert, der durch die Direkte bereitgestellt wird, eine Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, einen Abstand, der durch die Direkte bereitgestellt wird, die Anzahl der Quelloperanden für gepackte Daten und den Stride, der aus der Direkten bestimmt wird, bestimmt wird.
4. Vorrichtung nach Anspruch 3, wobei der Stride ein Wert aus der Direkten plus 1 ist.
5. Vorrichtung nach Anspruch 3, wobei die definierte Position die Rundung, multipliziert mit der Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, multipliziert mit der Anzahl der Quelloperanden für gepackte Daten plus einen Abstand ist, wobei dieser Wert durch den Stride geteilt wird.
6. Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Anweisung ein Feld für einen Schreibmaskenoperanden enthalten soll.
7. Vorrichtung nach Anspruch 6, wobei das Ausführungsmittel ein Ergebnis der Strided-Ladevorgänge auf Grundlage von Werten des Schreibmaskenoperanden speichern soll.
8. Verfahren umfassend: Decodieren einer Anweisung, wobei die Anweisung mindestens einen Opcode, ein Feld für mindestens zwei Quelloperanden für gepackte Daten, ein Feld für einen Zieloperanden für gepackte Daten, und eine Direkte enthält; und Ausführung der decodierten Anweisung zum Laden gepackter Datenelemente von den mindestens zwei Quelloperanden für gepackte Daten unter Verwendung eines Strides und Speichern der Ergebnisse der Strided-Ladevorgänge in den Zieloperanden für gepackte Daten, beginnend an einer definierten Position, die teilweise von der Direkten bestimmt wird.
9. Verfahren nach Anspruch 8, wobei die Quelloperanden für gepackte Daten verkettetet sind.
10. Verfahren nach einem der Ansprüche 8 bis 9, wobei die definierte Position durch einen Rundungswert, der durch die Direkte bereitgestellt wird, eine Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, einen Abstand, der durch die Direkte bereitgestellt wird, die Anzahl der Quelloperanden für gepackte Daten und den Stride, der aus der Direkten bestimmt wird, bestimmt wird.
11. Verfahren nach Anspruch 9, wobei der Stride ein Wert aus der Direkten plus 1 ist.
12. Verfahren nach Anspruch 9, wobei die definierte Position die Rundung, multipliziert mit der Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, multipliziert mit der Anzahl der Quelloperanden für gepackte Daten plus einen Abstand ist, wobei dieser Wert durch den Stride geteilt wird.
13. Verfahren nach einem der Ansprüche 8 bis 13, wobei die Anweisung ein Feld für einen Schreibmaskenoperanden enthalten soll.
14. Verfahren nach Anspruch 13, wobei das Speichern auf Werten des Schreibmasken-Operanden basiert.
15. Nichttransitorisches maschinenlesbares Medium, das Anweisungen speichert, die bei Ausführung einen Prozessor veranlassen sollen, ein Verfahren auszuführen, das Verfahren umfassend: Decodieren einer Anweisung, wobei die Anweisung mindestens einen Opcode, ein Feld für mindestens zwei Quelloperanden für gepackte Daten, ein Feld für einen Zieloperanden für gepackte Daten, und eine Direkte enthält; und Ausführung der decodierten Anweisung zum Laden gepackter Datenelemente von den mindestens zwei Quelloperanden für gepackte Daten unter Verwendung eines Strides und Speichern der Ergebnisse der Strided-Ladevorgänge in den Zieloperanden für gepackte Daten, beginnend an einer definierten Position, die teilweise von der Direkten bestimmt wird.
16. Nichttransitorisches maschinenlesbares Medium nach Anspruch 15, wobei die Quelloperanden für gepackte Daten verkettetet sind.
17. Nichttransitorisches maschinenlesbares Medium nach Anspruch 16, wobei die definierte Position durch einen Rundungswert, der durch die Direkte bereitgestellt wird, eine Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, einen Abstand, der durch die Direkte bereitgestellt wird, die Anzahl der Quelloperanden für gepackte Daten und den Stride, der aus der Direkten bestimmt wird, bestimmt wird.
18. Nichttransitorisches maschinenlesbares Medium nach Anspruch 16, wobei der Stride ein Wert aus der Direkten plus 1 ist.
19. Nichttransitorisches maschinenlesbares Medium nach Anspruch 16, wobei die definierte Position die Rundung, multipliziert mit der Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, multipliziert mit der Anzahl der Quelloperanden für gepackte Daten plus einen Abstand ist, wobei dieser Wert durch den Stride geteilt wird.
20. Nichttransitorisches maschinenlesbares Medium nach Anspruch 15, wobei die Anweisung ein Feld für einen Schreibmaskenoperanden umfassen soll und das Speichern auf Werten des Schreibmaskenoperanden basiert.
21. Vorrichtung, umfassend: eine Decoderschaltung, um eine Anweisung zu decodieren, wobei die Anweisung mindestens einen Opcode, ein Feld für mindestens zwei Quelloperanden für gepackte Daten, ein Feld für einen Zieloperanden für gepackte Daten, und eine Direkte enthält; und Ausführungsschaltung zur Ausführung der decodierten Anweisung zum Laden gepackter Datenelemente von den mindestens zwei Quelloperanden für gepackte Daten unter Verwendung eines Strides und Speichern der Ergebnisse der Strided-Ladevorgänge in den Zieloperanden für gepackte Daten, beginnend an einer definierten Position, die teilweise von der Direkten bestimmt wird.
22. Vorrichtung nach Anspruch 21, wobei die Quelloperanden für gepackte Daten verkettetet sind.
23. Vorrichtung nach Anspruch 22, wobei die definierte Position durch einen Rundungswert, der durch die Direkte bereitgestellt wird, eine Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, einen Abstand, der durch die Direkten bereitgestellt wird, die Anzahl der Quelloperanden für gepackte Daten und den Stride, der aus den Direkten bestimmt wird, bestimmt wird.
24. Vorrichtung nach Anspruch 23, wobei der Stride ein Wert aus der Direkten plus 1 ist.
25. Vorrichtung nach Anspruch 23, wobei die definierte Position die Rundung, multipliziert mit der Anzahl gepackter Datenelemente in jedem der Quelloperanden für gepackte Daten, multipliziert mit der Anzahl der Quelloperanden für gepackte Daten plus einen Abstand ist, wobei dieser Wert durch den Stride geteilt wird.

Images