DE112012001542T5 - System, Vorrichtung und Verfahren zum Ausrichten von Registern - Google Patents

System, Vorrichtung und Verfahren zum Ausrichten von Registern Download PDF

Info

Publication number
DE112012001542T5
DE112012001542T5 DE112012001542.8T DE112012001542T DE112012001542T5 DE 112012001542 T5 DE112012001542 T5 DE 112012001542T5 DE 112012001542 T DE112012001542 T DE 112012001542T DE 112012001542 T5 DE112012001542 T5 DE 112012001542T5
Authority
DE
Germany
Prior art keywords
data
bit
destination
field
data elements
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112012001542.8T
Other languages
English (en)
Inventor
Roger Espasa Sans
Milind Baburao Girkar
Dennis R. Bradford
Victor W. Lee
Jesus Corbal San Adrian
Lisa K. Wu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112012001542T5 publication Critical patent/DE112012001542T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3816—Instruction alignment, e.g. cache line crossing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30018—Bit or string instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30032—Movement instructions, e.g. MOVE, SHIFT, ROTATE, SHUFFLE
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30192—Instruction operation extension or modification according to data descriptor, e.g. dynamic data typing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3818—Decoding for concurrent execution
    • G06F9/382—Pipelined decoding, e.g. using predecoding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3818—Decoding for concurrent execution
    • G06F9/3822—Parallel decoding, e.g. parallel decode units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3853—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution of compound instructions

Abstract

Ausführungsbeispiele von Systemen, Vorrichtungen und Verfahren zum Ausführen eines Ausrichtungsbefehls in einem Computerprozessor werden beschreiben. In einigen Ausführungsbeispielen bewirkt das Ausführen des Ausrichtungsbefehls ein selektives Speichern von Datenelementen von zwei verknüpften Quellen, die in ein Ziel zu speichern sind.

Description

  • Gebiet der Erfindung
  • Die Erfindung bezieht sich allgemein auf eine Computerprozessor-Architektur und insbesondere auf Befehle, die, wenn sie ausgeführt werden, ein bestimmtes Resultat bewirken.
  • Hintergrund
  • Da die Einzelbefehl-Mehrfachdaten(SIMD)-Breite von Prozessoren sich erhöht, wird es zunehmend für Anwendungsentwickler (und Compilers) schwerer, voll die SIMD-Hardware zu nutzen, da Datenelemente natürlicherweise nicht in Bezug auf die Größe eines vollständigen Vektors ausgerichtet sind und typischerweise Cachezeilen-Teilungen erzeugen, wobei eine Speicherverweisung in zwei unterschiedlichen Zeilen einer Cachespeicher-Hierarchie angeordnet sind. Traditionell umfasst das Handhaben von Cachezeilen-Teilungen Folgendes: Detektieren der Cachezeilen-Teilungsbedingung, Ausführen von zwei unterschiedlichen TLB-Nachschlagoperationen, Durchführen von zwei Cachezeilen-Zugriffen und dadurch Nutzen von zwei unabhängigen Speicherports und/oder Verwenden von bestimmten Logikschaltungen, um die Stücke von Daten, die von den zwei aufeinanderfolgenden Cachezeilen kommen, auf dem Weg vom Speicher zusammen zu fügen.
  • Kurzbeschreibung der Figuren
  • Die vorliegende Erfindung wird beispielhaft, jedoch nicht einschränkend durch die Figuren der beiliegenden Zeichnungen dargestellt, in welchen ähnliche Bezugszeichen ähnliche Elemente bezeichnen und in welchen:
  • 1 eine beispielhafte Ausführung eines Ausrichtungs-(ALIGN)-Befehls zeigt;
  • 2 eine beispielhafte Ausführung eines Ausrichtungs-(ALIGN)-Befehls zeigt;
  • 3 eine beispielhafte Ausführung eines Ausrichtungs-(ALIGN)-Befehls zeigt;
  • 4 ein Ausführungsbeispiel eines Verfahrens zum Ausrichten von Daten von zwei Quellen und ein Abspeichern der Ausrichtung an einem Zielort durch ein Ausführen eines Ausrichtungsbefehls in einem Prozessor zeigt;
  • 5 ein Ausführungsbeispiel eines Verfahrens zum Verarbeiten eines Ausrichtungsbefehls zeigt;
  • 6 ein Ausführungsbeispiel eines Verfahrens zum Verarbeiten eines Ausrichtungsbefehls zeigt;
  • 7 ein Ausführungsbeispiel eines Verfahrens zum Verarbeiten eines Ausrichtungsbefehls in einen Pseudo-Code zeigt;
  • 8A ein Blockdiagramm zeigt, welches ein generisches Vektor-freundliches Befehlsformat und dafür Klasse-A-Befehlsvorlagen entsprechend zu Ausführungsbeispielen der Erfindung zeigen;
  • 8B ein Blockdiagramm zeigt, welches ein generisches Vektor-freundliches Befehlsformat und dafür Klasse-B-Befehlsvorlagen entsprechend zu Ausführungsbeispielen der Erfindung zeigen;
  • 9A–C ein beispielhaftes generisches Vektor-freundliches Befehlsformat entsprechend zu Ausführungsbeispielen der Erfindung zeigen;
  • 10 ein Blockdiagramm für eine Registerarchitektur entsprechend zu einem Ausführungsbeispiel der Erfindung zeigt;
  • 11 ein Blockdiagramm eines Einfach-CPU-Kernes zusammen mit dessen Verbindung zu einem Verbindungs-Netzwerk auf dem Chip und mit seinem lokalen Unterbereich des Level 2(L2)-Caches entsprechend zu Ausführungsbeispielen der Erfindung zeigt;
  • 11B eine Raumansicht eines Teils eines CPU-Kernes der 11A entsprechend zu Ausführungsbeispielen der Erfindung zeigt;
  • 12 ein Blockdiagramm zeigt, welches eine beispielhafte Außer-der-Reihe Architektur entsprechend zu Ausführungsbeispielen der Erfindung illustriert;
  • 13 ein Blockdiagramm eines Systems entsprechend zu einem Ausführungsbeispiel der Erfindung zeigt;
  • 14 ein Blockdiagramm eines zweiten Systems entsprechend zu einem Ausführungsbeispiel der Erfindung zeigt;
  • 15 ein Blockdiagramm eines dritten Systems entsprechend zu einem Ausführungsbeispiel der Erfindung zeigt;
  • 16 ein Blockdiagramm eines SoC entsprechend zu einem Ausführungsbeispiel der Erfindung zeigt;
  • 17 ein Blockdiagramm eines Einfach-Kern-Prozessors und eines Multi-Kern-Prozessors mit integriertem Speichercontroller und Graphik entsprechend zu Ausführungsbeispielen der Erfindung zeigt;
  • 18 ein Blockdiagramm zeigt, welches die Verwendung eines Software-Befehlsumwandlers herausstellt, der binäre Befehle in einem Quellbefehlssatz umwandelt in binäre Befehle in einem Ziel-Befehlssatz entsprechend zu Ausführungsbeispielen der Erfindung umwandelt.
  • Detaillierte Beschreibung
  • In der folgenden Beschreibung werden mehrere spezifische Details dargelegt. Es ist jedoch davon auszugehen, dass Ausführungsbeispiele der Erfindung auch ohne diese spezifischen Details ausgeführt werden können. Bei anderen Gelegenheiten sind gut bekannte Schaltungen, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis der Beschreibung nicht zu erschweren.
  • In der Beschreibung wird Bezug genommen auf „ein einziges Ausführungsbeispiel”, „ein Ausführungsbeispiel”, ein „beispielhaftes Ausführungsbeispiel”, etc., die andeuten, dass ein beschriebenes Ausführungsbeispiele ein bestimmtes Merkmal, Struktur oder Charakteristik umfassen können, aber jedes Ausführungsbeispiel braucht nicht notwendigerweise das bestimmte Merkmal, Struktur oder Charakteristik zu umfassen. Im Weiteren beziehen sich derartige Formulierungen nicht notwendigerweise auf das gleiche Ausführungsbeispiel. Weiterhin, wenn ein bestimmtes Merkmal, Struktur oder Charakteristik in Zusammenhang mit einem Ausführungsbeispiel beschrieben wird, wird davon ausgegangen, dass es in dem Wissen eines Fachmannes liegt, den Effekt eines solchen Merkmales, Struktur oder Charakteristik in Verbindung mit anderen Ausführungsbeispielen, ob sie nun explizit genannt sind oder nicht, herauszufinden.
  • Wie zuvor detailliert dargelegt, erfordern konventionelle Ausrichtungen von Datenelementen mehrere Schritte, die zu einigen ungewünschten Konsequenzen führen können. Beispielsweise, in einigen Situationen, spezifizieren die Nutzer potentielle Fehlausrichtungsverhalten über spezifische Eselsbrücken (wie das Ausführen von Befehlen wie VMOVUPS), die ein langsameres Ausführen infolge der Annahme verursachen, dass Cachezeilen-Teilungen immer erzeugt werden. In anderen Situationen ist es der Hardware überlassen, Cachefehlausrichtungen während der Laufzeit zu detektieren, was in einer zusätzlichen Performanceverschlechterung resultiert.
  • Ausrichtung
  • Ausführungsbeispiele von Vektorausrichtungs-(VALIGN)-Befehlen werden weiter unten detailliert erläutert und Ausführungsbeispiele von Systemen, Architekturen, Befehlsformaten etc., die genutzt werden können, um solche Befehle auszuführen, werden ebenfalls weiter unten ausführlich dargestellt. Während der Ausführung bewirkt ein Vektorausrichtungsbefehl, dass ein Prozessor Datenelemente eines ersten und zweiten Quelloperanden des Befehls verknüpft, Datenelemente nach rechts von den verknüpften Daten basierend auf einem Offset-(direkt)-Wert des Befehls verschoben werden, und eine oder mehrere der Elemente der verknüpften und verschobenen Daten werden in einem Zielvektorregister gespeichert werden. In einigen Ausführungsbeispielen werden die Elemente (oder wird das Element) der verschobenen und verknüpften Daten, die/das in dem Zielvektorregister zu speichern sind/ist, bestimmt durch entsprechende Bits eines Schreibmaskenregisters. Die erste und zweite Quelle können beide Register oder Speicherorte sein oder eine Kombination daraus. In einigen Ausführungsbeispielen, wenn die Quelle ein Speicherort ist, werden deren Daten vor dem Verknüpfen in ein Register geladen.
  • Ein Beispiel für diesen Befehl ist: ”VALIGND zmm1 {k1}, zmm2, zmm3/m512, offset,” wobei zmm1, zmm2, zmm3 Vektorregister sind (wie beispielsweise 128-, 256-, 512-Bit Register), m512 ist ein 512-Bit-Speicheroperand, der entweder in einem Register oder direkt gespeichert ist, k1 ist ein Schreibmaskenoperand (wie ein 16-Bit-Register, wie jene, die zuvor beschrieben wurden), und der Versatz (offset) ist ein Direktwert (zum Beispiel 8-Bit-Direktwert), die die Ausrichtung in 32-Bit-Elementen von Datenelementen der Quellen, nachdem sie verknüpft wurden, bestimmt, wie es weiter untern genauer ausgeführt wird. Was immer vom Speicher abgerufen wird, ist angefangen von der Adresse eine Sammlung von aufeinanderfolgenden Bits und kann unterschiedliche Größen aufweisen (128-, 256-, 512-Bit etc.) in Abhängigkeit von der Größe des Zielregisters – die Größe ist im Allgemeinen gleich der Größe des Zielregisters. In einigen Ausführungsbeispielen weist außerdem die Schreibmaske unterschiedliche Größen auf (8-Bits, 32-Bits, etc.). Zusätzlich werden in einigen Ausführungsbeispielen nicht alle Bits der Schreibmaske für den Befehl genutzt (zum Beispiel werden lediglich die acht Bits mit der geringsten Signifikanz genutzt). Natürlicherweise ist VALIGND der Befehlscode des Befehles. Typischerweise ist jeder Operand explizit in dem Befehl definiert. Die Größe der Datenelemente kann durch den „Präfix” des Befehls definiert sein, wie durch die Verwendung eines Hinweises auf das Datengranularitäts-Bit wie „W” wie zuvor beschrieben. In den meisten Ausführungsbeispielen weist W darauf hin, dass jedes Datenelement entweder 32 oder 64 Bits aufweist. Wenn die Datenelemente 32 Bit groß sind und die Quellen 512 Bit groß sind, dann sind sechzehn (16) Datenelemente pro Quelle vorhanden.
  • 1 zeigt eine beispielhafte Ausführung des ALIGN-Befehls. In diesem Beispiel sind zwei Quellen von jeweils 16 Datenelementen vorhanden. In den meisten Fällen ist eine dieser Quellen ein Register (für dieses Beispiel, wird die Quelle 1101 als ein 512-Bit-Register behandelt wie beispielsweise ein ZMM-Register mit 16 32-Bit-Datenelementen, jedoch können auch andere Datenelemente und Registergrößen genutzt werden, wie beispielsweise XMM-, YMM-Register und 16- oder 64-Bit-Datenelemente). Die andere Quelle 103 ist entweder ein Register oder ein Speicherort (in dieser Illustration ist die Quelle 2 die andere Quelle). Wenn die zweite Quelle ein Speicherort ist, ist sie in den meisten Ausführungsbeispielen in einem temporären Register vor dem Vermischen von Quellen platziert. Außerdem können Datenelemente von dem Speicherort einer Transformation vor dem Platzieren in dem temporären Register ausgesetzt werden. Die Daten 103 umfassen 16 Datenelemente von A bis P und die Daten 103 umfassen 16 Datenelemente von Q bis AF.
  • Wie dargestellt werden die Daten von den Registern 101 und 103 verknüpft 105 mit den am wenigsten signifikanten Datenelement des ersten Datenregisters 101, A, welches das am wenigsten signifikante Datenelement der verknüpften Daten 105 ist. Das am wenigsten signifikante Datenelement des zweiten Datenregisters 103, Q, folgt unmittelbar dem am meisten signifikanten Datenelement des ersten Datenregisters 101. Die verknüpften Datenelemente 105 werden um drei (der Direktwert des Befehls) verschoben (ausgerichtet), was die Datenelemente D bis AF von den ursprünglichen Quelle unverändert lassen. Natürlicherweise kann auch ein Bit-Reihenfolge-Format (Big Endian style) genutzt werden und die Datenelemente würden nach links durch einen entsprechenden Direktwert verschoben werden.
  • Die am wenigsten signifikante Datenelemente (D bis S) dieser verschobenen und verknüpften Daten werden in das Zielregister des Befehls verschoben bis keine weiteren Datenelemente-Positionen in dem Zielregister vorhanden sind. In anderen Ausführungsbeispielen werden die am meisten signifikanten Datenelemente in das Zielregister 107 geschrieben. Dieses Schreiben kann parallel oder seriell ausgeführt werden. Wie gezeigt, werden die 16 am wenigsten signifikanten Datenelemente in das Zielregister geschrieben, da es nur Raum für 16 zu speichernde Datenelemente dieser Größe aufweist.
  • 2 zeigt die gleichen Quelldaten und Verschiebung, nutzt aber die Inhalte eines Maskenregisters 201, um zu bestimmen, welche der am wenigsten signifikanten Datenelemente der verknüpften und verschobenen Daten 105 in das Zielregister geschrieben werden sollen. In einigen Ausführungsbeispielen ist das Maskenregister ein „k”-Maskenregister (k1–k7), wie zuvor ausgeführt wurde. Das Maskenregister ist als 0x878B gezeigt. Für jede Position der Maske, die einen Wert von „1” speichert, ist das entsprechende Datenelement von den verknüpften und verschobenen Daten 105 in die entsprechende Position des Zielregisters geschrieben. Beispielsweise, da die Position „0” der Maske eine „1” ist, dann ist der Wert, D, der entsprechenden Datenelementposition „0” der verschobenen und verknüpften Datenelemente in der Position „0” des Zielregisters gespeichert. Für jede Position der Maske, die einen Wert von „0” speichert, wird das entsprechende Datenelement des Zielregisters nicht überschrieben. Zum Beispiel ist in der Position „2” hat die Maske eine „0”, so dass das Ziel DC bleibt anstatt, dass es mit einem Wert von F überschrieben wird. Während „1” als ein Hinweis gezeigt wird, dass eine bestimmte Datenelementposition in das Zielregister geschrieben werden soll und ein „0” anzeigt, dass dieses Schreiben nicht ausgeführt werden soll, wird in anderen Ausführungsbeispielen eine entgegengesetzte Konvention verwandt. Außerdem wird in anderen Ausführungsbeispielen die am höchsten signifikanten Datenelemente geschrieben und nicht die am wenigsten signifikanten.
  • Die 3 zeigt die gleichen Quelldaten und Verschiebung, aber nutzt die Inhalte eines Maskenregisters, um zu bestimmen, welche der am wenigsten signifikanten Datenelemente der verknüpften und verschobenen Daten 105 in das Zielregister geschrieben werden sollen. In diesem Beispiel werden nicht alle der Maskenbits genutzt. Das kann, beispielsweise, in einigen Ausführungsbeispielen mit 64-bit-Datenelementen und 512-Bit-Registern passieren.
  • 4 zeigt ein Ausführungsbeispiel für ein Verfahren zum Ausrichten von Daten von zwei Quellen und ein Abspeichern der Ausrichtung an einen Zielort durch ein Ausführen eines Ausrichtungsbefehls in einem Prozessor. Bei 401 wird ein Ausrichtungsbefehl mit einem Zieloperanden, ersten und zweiten Quelloperanden, einen Versatz-(direkt)-Wert und ein Maskenoperand erhalten. Die Ziel- und Quelloperanden sind von der gleichen Größe. In einigen Ausführungsbeispielen können sie alle 512 Bit groß sein. In anderen Ausführungsbeispielen können sie jedoch unterschiedliche Größen wie beispielsweise 128 oder 256 Bit aufweisen. Typischerweise sind die Ziel- und der erste Quelloperand beide Register wie eines der Vektorregister (XMM, YMM oder ZMM), wie sie zuvor beschrieben wurden. Der zweite Quelloperand kann entweder ein Register oder ein Speicheroperand sein. In einigen Ausführungsbeispielen ist der Versatz ein 8-Bit Direktwert. Die Maske, die erhalten wird, kann einer der „k”-Schreibmasken, wie sie zuvor beschrieben wurden, sein oder sie ist in einigen Ausführungsbeispielen ein anderes Register oder ein Speicherort.
  • Der Ausrichtungsbefehl ist bei 403 decodiert. In Abhängigkeit vom Befehlsformat kann eine Vielzahl von Daten bei dieser Stufe ausgewertet werden, so als ob es zu einer Datentransformation kommt, zu welchen Register zu schreiben ist und abzufragen sind, auf welche Speicheradresse zugegriffen wird unter Nutzung des Speicherquelloperanden und potentiell des Versatzes, sofern er umfasst ist, etc. Die Quelloperandenwerte werden bei 405 abgerufen/gelesen. Wenn beide Quellen Register sind, dann werden diese Register gelesen. Wenn eine oder beide der Quellenoperanden ein Speicheroperand ist, dann werden Datenelemente, die zu dem Operand gehören, abgerufen. In einigen Ausführungsbeispielen werden Datenelemente von einem Speicher in einem temporären Register gespeichert.
  • Wenn irgendeine Transformation von Datenelemente auszuführen ist (wie eine Aufwärtsumwandlung, Broadcast, Swizzle (Umordnen) usw.), kann das bei 407 ausgeführt werden. Zum Beispiel kann ein 16-Bit-Datenelement vom Speicher in 32-Bit-Datenelement aufwärts konvertiert werden oder Datenelemente können umgeordnet werden von einem Muster in ein anderes (zum Beispiel XYZW XYZW XYZW ... XYZW zu XXXXXXXX YYYYYYYY ZZZZZZZZZZ WWWWWWWW).
  • Der Ausrichtungsbefehl wird bei 409 ausgeführt. Die Ausführung dieses Befehls bewirkt die Verknüpfung der Datenelemente des ersten und zweiten Quelloperanden und ein Verschieben nach rechts von diesen Datenelementen von jenen verknüpften Daten basierend auf dem Versatz. In einigen Ausführungsbeispielen sind die ersten und zweiten Operanden jene Datenelemente, die am wenigsten signifikant sind von den verknüpften Datenelementen. Einige der Datenelemente der verschobenen verknüpften Daten können in einem Zielvektorregister bei 411 in Abhängigkeit von entsprechenden Bits eines Schreibmaskenregisters gespeichert werden. Während 409 und 411 separat dargestellt sind, können in einigen Ausführungsbeispielen diese Operationen zusammen als Teil der Ausführung des Befehls ausgeführt werden.
  • Während das Obige dargestellt wurde in einer Art der Ausführungsumgebung, ist es ebenfalls möglich, es leicht an anderen Umgebungen wie zum Beispiel In-Fester-Ordnung (in order) und In-Anderer-Ordnung (out of order) Umgebung anzupassen.
  • 5 zeigt ein Ausführungsbeispiel eines Verfahrens zum Verarbeiten eines Ausrichtungsbefehls. In diesem Ausführungsbeispiel ist angenommen, dass einige, aber nicht alle, der Operationen 401 bis 407 früher ausgeführt werden, jedoch sind sie nicht gezeigt, um die dargestellten Details nicht zu verdecken. Zum Beispiel, ist das Abholen und Dekodieren nicht gezeigt, noch ist der Operanden-(Quell- oder Schreibmasken-)-Abruf gezeigt.
  • Die Datenelemente der ersten und zweiten Quellen werden bei 501 verknüpft, um einen größeren „Vektor” zum Operieren darauf zu erzeugen. Zum Beispiel sind die Daten von zwei Quellregistern miteinander verknüpft, so dass die Datenelemente der ersten Quelle die weniger signifikanten Bits und die Datenelemente der zweiten Quelle die am signifikantesten sind, wie es in den 1 und 2 gezeigt ist. In einigen Ausführungsbeispielen ist dieser größere Vektor 1024 Bits lang. Selbstverständlich ist die Größe dieses größeren Vektors abhängig von der Größe der Quellen.
  • Die verknüpften Daten der ersten und zweiten Quelle sind nach rechts verschoben um einen Betrag von Datenelementen, der durch den direkten Wert des Befehls bei 503 definiert ist.
  • Ein Bestimmen, ob eine Schreibmaske zu nutzen ist, kann bei 505 ausgeführt werden. Dies ist optional, abhängig von der Implimentation der zu Grunde liegenden Art der Architektur. Zum Beispiel, wenn ein Schreibmaskenregister, wie k0, wie oben beschrieben verwandt wird, wird keine Maske genutzt werden. Solange k0 ein Register ist, zu dem geschrieben werden kann, wenn es in einem Befehl enthalten ist, bedeutet es, dass kein Maskieren auszuführen ist (das heißt, es ist im Wesentlichen bei „1”-Wert bei allen Bit-Positionen). Natürlich kann es in anderen Architekturen genutzt werden, wie jedes andere Register genutzt werden würde.
  • Wenn die Schreibmaske zu nutzen ist, dann ist für jede Bit-Position in der Schreibmaske eine Bestimmung bei 507 durchzuführen, ob diese Bit-Position anzeigt, dass das entsprechende Element der verschobenen verknüpften Daten der ersten und zweiten Quelle in einem entsprechenden Ort eines Zielregisters zu speichern ist. In einigen Ausführungsbeispielen wird diese Bestimmung und/oder potentiell das spätere Abspeichern bei 511 seriell ausgeführt – das heißt, die Bestimmung wird ausgeführt für die erste Bit-Position (das heißt, k1[0]) und wird dann für die sequentiellen Bit-Positionen berechnet. In anderen Ausführungsbeispielen wird diese Bestimmung und/oder das potentielle spätere Speichern bei 511 parallel ausgeführt – das heißt, das Bestimmen ist für alle Bit-Positionen (das heißt, k1[0]–k1[15]) zur gleichen Zeit vorgesehen. Außerdem ändert sich die Anzahl der zu berechnenden Bit-Positionen in Abhängigkeit von der Datenelementengröße. Zum Beispiel in einer 512-Bit-Implementation mit 32-Bit-Datenelementen werden sechzehn (16) Bits der Maske zur Bestimmung berechnet. In einer 512-Bit-Implementation mit 64-Bit Datenelementen werden lediglich acht (8) Bits der Maske berechnet. In diesem Fall werden typischerweise die wenigsten signifikanten acht (8) Bits berechnet, aber andere Konventionen können ebenfalls genutzt werden.
  • Wenn eine Bit-Position der Maske darauf hindeutet, dass nichts in die entsprechende Datenelementeposition eines Zielregisters zu schreiben ist, dann wird nichts in das Zielregister bei 509 geschrieben. Wenn eine Bit-Position der Maske anzeigt, dass die entsprechenden Daten der verschobenen verknüpften Daten in die entsprechende Datenelementeposition eines Zielregisters zu schreiben ist, dann wird es in die entsprechende Position des Datenelementes des Zielregisters bei 511 geschrieben. Ein Beispiel für einen solchen Speicher ist in der 2 gezeigt. Wenn eine Maske nicht zu nutzen ist, dann werden alle der entsprechenden Datenelemente der verschobenen verknüpften Daten in den entsprechenden Positionen der Datenelemente des Zielregisters bei 511 gespeichert. Ein Beispiel für einen solchen Speicher ist in der 1 gezeigt.
  • Wenn die letzte Bit-Position der betrachteten Maske berechnet wurde oder alle Positionen der Datenelemente in dem Ziel, zu welchem geschrieben werden kann, berechnet wurden, endet das Verfahren.
  • 6 zeigt ein Ausführungsbeispiel eines Verfahrens zum Verarbeiten eines Ausrichtungsbefehls. In diesem Ausführungsbeispiel ist angenommen, dass einige, aber nicht alle, der Operationen 401 bis 407 vorher bereits ausgeführt wurden, jedoch sind sie nicht gezeigt, um die im Folgenden darzustellenden Details nicht zu verdecken. Zum Beispiel ist das Abholen und Dekodieren nicht gezeigt, ebensowenig wie der Operand (Quellen- oder Schreibmasken) Abfrage gezeigt ist.
  • Datenelemente der ersten und zweiten Quelle werden bei 601 miteinander verknüpft, um einen größeren „Vektor” zu erzeugen, auf dem operiert wird. Zum Beispiel sind die Daten von zwei Quellregistern derart verknüpft, dass die Datenelemente der ersten Quelle die Bits mit der niedrigeren Signifikanz und die Datenelemente der zweiten Quelle die Bits mit der höchsten Signifikanz sind, wie es in den 1 und 2 gezeigt ist. In einigen Ausführungsbeispielen ist dieser größere Vektor 1024 Bits lang. Natürlich kann die Größe des größeren Vektors in Abhängigkeit der Größe der Quelle variiert werden.
  • Die verknüpften Daten der ersten und zweiten Quelle sind nach rechts verschoben um eine Menge an Datenelementen, die durch den Direktwert des Befehls bei 603 definiert sind.
  • Ein Bestimmen, ob eine Schreibmaske zu nutzen ist, kann ebenso durchgeführt werden (nicht gezeigt). Dies ist optional in Abhängigkeit von der Implementierung der zugrundeliegenden Hardwarearchitektur wie zuvor dargestellt. Wenn eine Maske nicht zu nutzen ist, dann wird keine Prüfung bei 605 oder 607 durchgeführt.
  • Für die erste Bit-Position in der Schreibmaske wird eine Bestimmung, ob die Bit-Position darauf hinweist, dass das entsprechende Element der verschobenen verknüpften Daten der ersten und zweiten Quelle in einer entsprechenden Position eines Zielregisters zu speichern ist, bei 605 durchgeführt. Wenn die erste Bit-Position der Maske darauf hindeutet, dass nichts in die entsprechende Position des Datenelementes des Zielregisters zu schreiben ist, dann wird nichts in das Zielregister bei 609 geschrieben. Wenn die erste Bit-Position der Maske andeutet, dass die entsprechenden Daten der verschobenen verknüpften Daten in die entsprechende Position des Datenelementes des Zielregisters zu schreiben ist, dann wird es in die entsprechende Position des Datenelementes des Zielregisters bei 611 geschrieben. Ein Beispiel für einen solchen Speicher ist in der 2 gezeigt.
  • Eine Bestimmung, ob die berechnete Schreibmaskenposition die letzte war der Schreibmaske oder ob alle Positionen der Datenelemente des Ziels aufgefüllt sind, wird bei 613 ausgeführt. Wenn dies der Fall ist, dann ist die Operation beendet. Der letztere Fall kann auftreten, wenn beispielsweise die Datenelementgröße 64 Bits, die Zielgröße 512 Bits und Schreibmaskengröße 16 Bits ist. In diesem Fall sind nur 8 Bits für die Schreibmaske notwendig.
  • Wenn es nicht der Fall ist, dann ist die nächste Bitposition in der Schreibmaske zu berechnen, um ihren Wert bei 612 zu bestimmen. Außerdem ist die Bitposition bei 607, und so weiter, berechnet. Wenn die letzte Bitposition der betrachteten Maske berechnet wurde, oder alle Positionen des Datenelementes in dem Ziel, zu welchem geschrieben werden kann, geschrieben wurden, endet das Verfahren.
  • 7 zeigt ein Ausführungsbeispiel des Verfahrens zum Verarbeiten eines Ausrichtungsbefehls in einen Pseudo-Code.
  • Programme greifen typischerweise auf Speicher in einer sequenziellen Art zu. Zum Beispiel ist der Bezug (a) ein Zugriff auf einen ersten 512-Bit-Vektor, der bei der Adresse @ lokalisiert ist, der Bezug (b) ist ein Zugriff auf einen zweiten 512-Bit-Vektor, der an der Adresse @+64 Bytes lokalisiert ist und der Bezug (c) ist ein Zugriff auf einen ersten 512-Bit-Vektor, der bei der Adresse @+128 Bytes lokalisiert ist. In diesem Szenario ist der Bezug (a) gegenüberliegend der Cachezeile A und B lokalisiert, der Bezug (b) ist gegenüberliegend der Cachezeile B und C lokalisiert und der Bezug (c) ist gegenüberliegend der Cachezeile C und D lokalisiert. Bei der Verwendung von regulären Lasten, wird auf die Cachezeile B und C zweimal zugegriffen und die Anzahl der gesamten Cachezeilenzugriffe wäre 6 (3x2).
  • Unter allgemeinen Bedingungen sind die Cachezeilenports wertvollere Ressourcen als Registerports. Ausführungsbeispiele des zuvor beschriebenen Ausrichtungsbefehls führen eine Datenausrichtung auf Registern durch anstatt auf Cachezeilen und daher liefert ein solcher Befehl einen Performancezuwachs. Bei der Verwendung des Ausrichtungsbefehls werden die Cachezeilendaten in den Registern ausgerichtet und es gibt typischerweise nur eine neue Cachezeile, die pro Vektorbezug abgeholt wird – anstatt auf jede Cachezeile zweimal zuzugreifen, wird sie lediglich einmal gelesen und gleichzeitig mit dem Cachezugriff ausgerichtet, was einen Durchsatz von einem Vektor pro Zyklus unterstützt, wobei immer noch nur ein einfacher Speicherport genutzt wird.
  • Ausführungsbeispiele des/der zuvor beschriebenen Befehl(e) können in einem „generischen vektorfreundlichen Befehlsformat” wie weiter unten beschrieben umgesetzt werden. In anderen Ausführungsbeispielen wird ein solches Format nicht genutzt und andere Befehlsformate werden verwendet, jedoch ist die Beschreibung unten für die Schreibmaskenregister, unterschiedlichen Datentransformationen (Swizzle, Broadcast, usw.), Adressierungen usw. allgemein anwendbar für die Beschreibung von Ausführungsbeispielen der/die Befehl(e) wie oben beschrieben. Außerdem sind beispielhafte Systeme, Architekturen und Pipelines unten dargelegt. Ausführungsbeispiele des/der Befehl(e) von oben können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber auf diese nicht begrenzt.
  • Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, welches geeignet ist Vektorbefehle (zum Beispiel gibt es dort bestimmte Felder, die spezifisch sind für Vektoroperationen). Während Ausführungsbeispiele beschrieben werden, in welchen sowohl Vektoren als auch Skalaroperationen über das vektorfreundliche Befehlsformat unterstützt sind, können alternative Ausführungsbeispiele für Vektoroperationen lediglich das vektorfreundliche Befehlsformat nutzen.
  • Beispielhafte generische vektorfreundliche Befehlsformate – Fig. 8A–B
  • 8A–B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und dazugehörige Befehlsvorlagen entsprechend zu Ausführungsbeispielen der Erfindung zeigen. 8A ist ein Blockdiagramm, welches ein generisches vektorfreundliches Befehlsformat und dazugehörige Klasse A Befehlsvorlagen nach Ausführungsbeispielen der vorliegenden Erfindung zeigt; während Figur B ein Blockdiagramm ist, welches das generische vektorfreundliche Befehlsformat und dazugehörige Klasse B-Befehlsvorlagen entsprechend zu Ausführungsbeispielen der Erfindung zeigt. Insbesondere umfasst ein generisches vektorfreundliches Befehlsformat 800, für welches die Klasse A- und Klasse B-Befehlsvorlagen definiert sind, sowohl Befehlsvorlagen für keinen Speicherzugriff 805 als auch Befehlsvorlagen für einen Speicherzugriff 820. Der Begriff „generisch” im Zusammenhang mit vektorfreundlichen Befehlsformaten bezieht sich auf das Befehlsformat, welches nicht zu einem spezifischen Befehlssatz gehört. Während Ausführungsbeispiele beschrieben werden, in welchen Befehle in dem vektorfreundlichen Befehlsformat auf Vektoren operieren, die entweder von Registern (kein Speicherzugriff 805 Befehlsvorlagen) oder von Registern/Speicher (Befehlsvorlage Speicherzugriff 820) herrühren, können alternative Ausführungsbeispiele der Erfindung sich lediglich auf einen von diesen Beiden beziehen. Außerdem, während Ausführungsbeispiele der Erfindung beschrieben werden, in welchen Last- und Speicherbefehle in dem Vektorbefehlsformat beschrieben werden, beziehen sich alternative Ausführungsbeispiele stattdessen oder zusätzlich auch auf Befehle, in einem anderen Befehlsformat, welches Vektoren in und aus Registern bewegt (zum Beispiel von einem Speicher in Register, von Register in einen Speicher oder zwischen Registern). Weiterhin, während Ausführungsbeispielen der Erfindung beschrieben werden, die zwei Klassen von Befehlsvorlagen unterstützen, beziehen sich alternative Ausführungsbeispiele ebenso auf den Fall, dass nur eines davon oder mehr als zwei unterstützt werden.
  • Während Ausführungsbeispiele der Erfindung beschrieben werden, in welchen das folgende vektorfreundliche Befehlsformat unterstützt wird: Eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit (4 Byte)- oder 64 Bit (8 Byte)-Datenelementenbreiten (oder -größen) (und daher besteht ein 64-Byte-Vektor aus entweder 16 Doppelwort-großen Elemente oder alternativ aus 8 Vierfachwort-großen Elementen); eine 64 Byte-Vektoroperandenlänge (oder -größe) mit 16 Bit (2 Byte)- oder 8 Bit (1 Byte)-Datenelementenbreiten (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)-Datenelementenbreiten (oder -größen); und eine 16 Byte-Vektoroperandenlänge (oder -göße) mit 32 Bit (4 Byte)-, 64 Bit (8 Byte)-, 16 Bit (2 Byte)-, oder 8 Bit (1 Byte)-Datenelementenbreiten (oder -größen); unterstützten alternative Ausführungsbeispiele mehr, weniger und/oder andere Vektoroperandengrößen (zum Beispiel 856-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenlementenbreiten (zum Beispiel 128-Bit (16 Byte)-Datenelementenbreiten).
  • Die Klasse A-Befehlsvorlagen in der 8A umfassen: 1) innerhalb der Befehlsvorlage für keinen Speicherzugriff 805 ist ein Kein-Speicherzugriff gezeigt, Befehlsvorlage für eine vollständigen Rundungssteueroperation und ein Kein-Speicherzugriff gezeigt, eine Befehlsvorlage für einen Datentransformationstyp 815 gezeigt; und 2) innerhalb der Befehlsvorlagen für einen Speicherzugriff 820 ist Folgendes gezeigt, ein Speicherzugriff, temporäre 825 Befehlsvorlage und ein Speicherzugriff, nicht temporäre 830 Befehlsvorlage. Die Klasse B-Befehlsvorlagen in der 8B umfassen: 1) innerhalb der Kein-Speicherzugriff 805-Befehlsvorlagen ist Folgendes gezeigt, ein Kein-Speicherzugriff, Schreibmaskenkontrolle, Befehlsvorlage für eine teilweise Rundungsoperation und einen Kein-Speicherzugriff, Schreibmaskenkontrolle, Befehlsvorlage für eine vsize-artige Operation 817; und 2) innerhalb der Befehlsvorlagen für einen Speicherzugriff 820 ist Folgendes gezeigt, ein Speicherzugriff, Befehlsvorlagen für eine Schreibmaskenkontrolle 827.
  • Format
  • Das generische vektorfreundliche Befehlsformat 800 umfasst die folgenden Felder, die unten in der Reihenfolge aufgelistet sind, wie sie in den 8A bis 8B gezeigt sind.
  • Formatfeld 840 – ein spezifischer Wert (ein Identifizierwert für ein Befehlsformat) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und somit das Auftreten von Befehlen in dem vektorfreundlichen Befehlsformat in dem Befehlsstrom. Somit unterscheidet der Inhalt des Formatfeldes 840 das Auftreten von Befehlen in dem ersten Befehlsformat von dem Auftreten von Befehlen in einem anderen Befehlsformat, um so zu erlauben, dass das vektorfreundliche Befehlsformat in dem Befehlssatz eingeführt wird, der andere Befehlsformate aufweist. Als solches ist dieses Feld optional in dem Sinne, dass es für den Befehlssatz nicht erforderlich ist, der lediglich das generische vektorfreundliche Befehlsformat hat.
  • Basisoperationsfeld 842 – sein Inhalt unterscheidet zwischen unterschiedlichen Basisoperationen. Wie es später beschrieben wird, kann das Basisoperationsfeld 842 ein Befehlscode-Feld umfassen und/oder Teil davon sein.
  • Registerindexfeld 844 – sein Inhalt spezifiziert direkt oder über eine Adresserzeugung die Orte der Quell- und Zieloperanden, ob sie in Registern oder in Speichern sind. Dies umfasst eine hinreichende Anzahl von Bits, um N Register von PxQ (zum Beispiel 32x1012)-Registerdateien zu selektieren. Während in einem Ausführungsbeispiel N bis zu drei Quellen und ein Zielregister sein kann, können in alternativen Ausführungsbeispielen mehr oder weniger Quellen und Zielregister unterstützt werden (zum Beispiel können bis zu 2 Quellen unterstützt werden, wo eine von diesen Quellen ebenso als ein Ziel dient, oder es können bis zu 3 Quellen unterstützt sein, wobei eine dieser Quellen ebenso als Ziel agiert, oder es können bis zu 2 Quellen und ein Ziel unterstützt sein). Während in einem Ausführungsbeispiel P = 32 ist, können in alternativen Ausführungsbeispielen mehr oder weniger Register (beispielsweise 16) unterstützt werden. Während in einem Ausführungsbeispiel Q = 1012 Bits ist, können in alternativen Ausführungsbeispielen mehr oder weniger Bits unterstützt werden (zum Beispiel 128, 1024).
  • Modifizierfeld 846 – sein Inhalt unterscheidet das Auftreten von Befehlen in dem generischen Vektorbefehlsformat, welche Speicherzugriffe kennzeichnen, von solchen, die dies nicht tun; das heißt, zwischen Befehlsvorlagen für Keinen-Speicherzugriff 805 und Befehlsvorlagen für einen Speicherzugriff 820. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (in einigen Fällen unter Angabe der Quell- und/oder Zieladressen, die Werte in Registern nutzen), während Kein-Speicherzugriffsoperationen dies nicht tun (zum Beispiel sind die Quellen und die Ziele Register). Während in einem Ausführungsbeispiel dieses Feld auch zwischen 3 unterschiedlichen Arten auswählt, wie die Speicheradressberechnung auszuführen ist, können in alternativen Ausführungsbeispielen mehr, weniger oder andere Arten der Speicheradressberechnungen ausgeführt werden.
  • Vergrößerungsoperationsfeld 850 – sein Inhalt kennzeichnet welcher von der Vielzahl von unterschiedlichen Operationen auszuführen ist, zusätzlich zu der Basisoperation. Dieses Feld ist kontextspezifisch. In einem Ausführungsbeispiel der Erfindung wird dieses Feld unterteilt in ein Klassenfeld 868, ein Alphafeld 852 und ein Betafeld 854. Das Vergrößerungsoperationsfeld erlaubt gemeinsame Gruppen von Operationen durch einen einfachen Befehl auszuführen, anstatt durch zwei, drei oder vier Befehle. Im Folgenden sind einige Beispiele von Befehlen angegeben (ihre Nomenklatur ist im Detail weiter unten beschrieben), die das Vergrößerungsfeld 850 nutzen, um die Anzahl der erforderlichen Befehle zu reduzieren.
  • Figure DE112012001542T5_0002
  • Figure DE112012001542T5_0003
  • Wobei [rax] ein Basiszeiger ist, der für die Adresserzeugung genutzt wird und wobei {} eine Umwandlungsoperation anzeigt, die durch das Datenmanipulationsfeld festgelegt ist (wie es weiter unten im Detail beschrieben wird).
  • Skalierfeld 860 – sein Inhalt erlaubt das Skalieren des Indexfeldinhaltes zur Speicheradresserzeugung (zum Beispiel zum Erzeugen von Adressen, die 2scale*index+base nutzen).
  • Verschiebungsfeld 862A – sein Inhalt wird genutzt als Teil der Speicheradresserzeugung (zum Beispiel zur Adresserzeugung, die 2scale*index+base+Verschiebung nutzt).
  • Verschiebungsfaktorfeld 862B (Bemerkung: das Nebeneinander des Verschiebungsfeldes 862A direkt über dem Verschiebungsfaktorfeld 862B deutet an, dass das Eine oder Andere genutzt wird) – sein Inhalt wird genutzt als Teil der Adresserzeugung; es legt einen Verschiebungsfaktor fest, der zu skalieren ist durch einen Wert des Speicherzugriffes (N) – wobei N eine Zahl von Bytes in dem Speicherzugriff ist (zum Beispiel für die Adresserzeugung, die 2scale*index+base+skalierte Verschiebung nutzt). Überflüssige Bits niedriger Ordnung werden ignoriert und daher wird der Inhalt des Verschiebungsfaktorfeldes mit der Speicheroperandengesamtgröße (N) multipliziert, um die letztendliche Verschiebung zu erzeugen, die in der Berechnung der effektiven Adresse zu nutzen ist. Der Wert von N wird durch die Prozessorhardware bei der Ausführung berechnet, und zwar basierend auf dem vollständige Befehlscode-Feld 874 (welches später beschrieben wird) und das Datenmanipulationsfeld 854C wie es später beschrieben wird. Das Verschiebungsfeld 862A und das Verschiebungsfaktorfeld 862B sind optional für den Fall, dass sie nicht für die Befehlsvorlagen für Kein-Speicherzugriff 805 genutzt werden, und/oder andere Ausführungsbeispiele implementieren nur eine oder keine von diesen zwei.
  • Datenelement-Breitenfeld 864 – sein Inhalt kennzeichnet, welche aus einer Anzahl von Datenelementenbreiten zu nutzen ist (in einigen Ausführungsbeispielen für alle Befehle; in anderen Ausführungsbeispielen für nur einige der Befehle). Dieses Feld ist optional in dem Sinne, dass es nicht erforderlich ist, wenn nur eine Datenelementbreite unterstützt ist und/oder Datenelementenbreiten unterstützt werden, die einige Aspekte von Befehlscodes verwenden.
  • Schreibmaskenfeld 870 – sein Inhalt steuert auf einer pro Datenelement-Positionbasis, ob die Position des Datenelementes in dem Zielvektoroperanden das Resultat der Basisoperation und Vergrößerungsoperation wiedergibt. Klasse-A-Befehlsvorlagen unterstützen das Zusammenfügen von Schreibmasken, während Klasse-B-Befehlsvorlagen das Zusammenfügen und Nichtanwenden (zeroing) von Schreibmasken unterstützt. Beim Zusammenfügen erlauben Schreibmasken jeden Satz von Elementen in dem Ziel, dass sie geschützt werden vor Updates während der Ausführung irgendeiner Operation (die durch die Basisoperation oder die Vergrößerungsoperation festgelegt ist); in anderen Ausführungsbeispielen, wird der alte Wert von jedem Element des Zieles erhalten, wo das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu, bei der Nichtanwendung Vektormasken, wird jedem Satz von Elementen im Ziel erlaubt, dass es während der Ausführung einer beliebigen Operation auf Null gesetzt wird (was durch die Basisoperation oder die Vergrößerungsoperation festgelegt wird); in einem Ausführungsbeispiel wird ein Element des Zieles auf Null gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Untergruppe dieser Funktionalität wird durch die Möglichkeit dargestellt, die Vektorlänge der Operation, die auszuführen ist, zu steuern (das heißt die Spanne von Elementen, die modifiziert werden, vom ersten bis zum letzten); es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Daher erlaubt das Schreibmaskenfeld 870 teilweise Vektoroperationen, einschließlich ein Laden, Speichern, arithmethische Operationen, logische Operationen usw. Diese Maskierung kann ebenfalls zur Fehlerunterdrückung genutzt werden (das heißt, indem die Positionen der Datenelemente am Ziel maskiert werden, um einen Erhalt eines Resultates von irgendeiner Operation vorzubeugen, die einen Fehler verursachen kann oder wird – zum Beispiel angenommen, dass ein Vektor in einem Speicher eine Seitengrenze überschreitet und dass die erste Seite, nicht aber die zweite Seite, einen Seitenfehler verursachen würde, kann der Seitenfehler ignoriert werden, wenn alle Datenelemente des Vektors, die auf der ersten Seite liegen, durch die Schreibmaske maskiert werden). Im Weiteren erlauben Schreibmasken eine ”Vektorisierung von Loops”, die bestimmte Arten von Bedingungsaussagen enthalten. Während Ausführungsbeispiele der Erfindung beschrieben werden, in welchem der Inhalt des Schreibmaskenfeldes 870 eine aus der Anzahl von Schreibmaskenregistern auswählt, welche die Schreibmaske, die zu nutzen ist, enthält (und daher identifiziert der Inhalt des Schreibmaskenfeldes 870 indirekt, dass eine Maskierung auszuführen ist), erlauben alternative Ausführungsbeispiele stattdessen oder zusätzlich, dass der Inhalt des Maskenschreibfeldes 870 direkt die Maskierung festlegt, die auszuführen ist. Außerdem erlaubt das Nullsetzen eine Verbesserung der Performance, wenn: 1) eine Registerumbenennung genutzt wird für Befehle deren Zieloperand nicht ebenso eine Quelle ist (welche ebenfalls Nicht-Ternär-Befehle genannt werden), weil während der Phase der Registerumbenennung das Ziel nicht länger eine implizite Quelle ist (es ist nicht erforderlich, Datenelemente von dem gegenwärtigen Zielregister in das umbenannte Zielregister zu kopieren oder irgendwie mitzunehemen mit der Operation, weil jedes Datenelement, welches kein Resultat der Operation ist (jedes maskierte Datenelement) auf Null gesetzt wird); und 2) während des Zustandes des Zurückschreibens, weil Nullen geschrieben werden.
  • Das Direktwertfeld 872 – sein Inhalt erlaubt das Festlegen von Direktwerten. Dieses Feld ist optional in dem Sinne, dass es in eine Implementierung eines generischen vektorfreundlichen Formats, welches keine Direktdaten unterstützt, nicht vorhanden ist und es ist nicht für Befehle vorhanden, die keine Direktwerte nutzen.
  • Befehlsvorlage Klassenauswahl
  • Klassenfeld 868 – sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Befehlen. In Bezug auf 2A, 2B, die Inhalte dieses Feldes wählen zwischen Klasse A- und Klasse B-Befehlen aus. In 8A, 8B, gerundete Eckquadrate werden genutzt, um einen bestimmten Wert anzuzeigen, der in dem Feld vorhanden ist (zum Beispiel Klasse A 868A und Klasse B 868B für das Klassenfeld 868 entsprechend in den 8A bis 8B).
  • Befehlsvorlagen der Klasse A für Keinen-Speicherzugriff
  • Im Falle von Befehlsvorlagen der Klasse A für keinen Speicherzugriff 805 wird das Alphafeld 852 als ein RS-Feld 852A interpretiert, dessen Inhalt kennzeichnet, welche der unterschiedlichen Vergrößerungsoperationstypen auszuführen sind (zum Beispiel wird ein Runden 852A.1 und eine Datentransformation 852A.2 entsprechend für den Kein-Speicherzugriff gekennzeichnet, die Rundungsartoperation 810 und die Kein-Speicherzugriff, Befehlsvorlagen für den Datentransformationstypoperation 815), während das Betafeld 854 kennzeichnet, welche der Operationen des spezifischen Typs auszuführen ist. In der 8 sind die gerundeten Eckblöcke genutzt, um einen spezifischen Wert anzuzeigen, der vorhanden ist (zum Beispiel Keinen-Speicherzugriff 846A in dem Modifizierfeld 846; Runden 852A.1 und Datentransformation 852A.2 für das Alphafeld 852/RS Feld 852A). In den Befehlsvorlagen für Keinen-Speicherzugriff 805 sind das Skalierfeld 860, das Verschiebungsfeld 862A und das Verschiebungsskalierfeld 862B nicht vorhanden.
  • Befehlsvorlagen für Kein-Speicherzugriff – volle Rundungskontrolloperation
  • In der Befehlsvorlage für Kein-Speicherzugriff, volle Rundungskontrolloperation 810, wird das Betafeld 854 als ein Rundungskontrollfeld 854A interpretiert, dessen Inhalt(e) eine statische Rundung bereitstellt. Während in den beschriebenen Ausführungsbeispielen der Erfindung das Rundungskontrollfeld 854A eine Unterdrückung aller Fließkommastellenausnahmebedingung(SAE)-Feld 856 und eines Rundungssteuerfeldes 858 umfasst, können in alternativen Ausführungsbeispielen diese beiden Konzepte durch ein gleiches Feld unterstützt werden oder nur eines oder das andere dieser Konzepte/Felder unterstützt werden (zum Beispiel kann lediglich ein Rundungsoperationskontrollfeld 858 vorhanden sein).
  • SAE-Feld 856 – sein Inhalt kennzeichnet, ob oder ob nicht das Berichten über Ausnahmeerscheinungen außer Kraft gesetzt werden soll; wenn der Inhalt des SAE-Feldes 856 eine Unterdrückung anzeigt, wird ein gegebener Befehl keinen Bericht über einen Fließkommaausnahmehinweis erstellen und wird kein Programm zum Handhaben von Fließkommaausnahmen aufrufen.
  • Steuerfeld zur Rundungssteueroperation 858 – sein Inhalt kennzeichnet, welche der Gruppe von Rundungsoperationen auszuführen ist (zum Beispiel Aufrunden, Abrunden, Runden hin zu Null und Runden zum nächstgelegenen). Das Steuerfeld zur Rundungsoperation 858 erlaubt daher einen Wechsel des Rundungsmodus auf der Grundlage eines Befehls und ist daher insbesondere nützlich, wenn diese Operation erforderlich ist. In einem Ausführungsbeispiel der Erfindung, wenn der Prozessor ein Steuerregister zum Kennzeichnen des Rundungsmodus umfasst, überschreibt der Inhalt des Steuerfeldes zur Rundungsoperation 850 den Registerwert (ermöglicht es, den Rundungsmodus zu wählen, ohne ein Sichern-Ändern-Wiederherstellen auf einem solchem Steuerregister auszuführen, was vorteilhaft ist).
  • Befehlsvorlage für Kein-Speicher-Zugriff – Operation Datentransformationstyp
  • In der Befehlsvorlage für keinen Speicherzugriff Datentransformationstypoperation 815 wird das Beta-Feld 854 als ein Datentransformationsfeld 854B interpretiert, dessen Inhalt kennzeichnet, welche aus einer Anzahl von Datentransformationen auszuführen ist (zum Beispiel, ob keine Datentransformation, ein Swizzle oder ein Broadcast auszuführen ist).
  • Befehlsvorlage für einen Speicherzugriff der Klasse A
  • Im Falle, dass eine Befehlsvorlage für einen Speicherzugriff 820 der Klasse A erfolgt, wird das Alpha-Feld 852 als ein Räumungs-(eviction)Hinweisfeld interpretiert 852B, dessen Inhalt kennzeichnet, welcher der Räumungshinweise zu nutzen ist (in der 8A, das Temporäre 852B.1 und das nicht-temporäre 852B.2 werden entsprechend gekennzeichnet für den Speicherzugriff, die temporäre Befehlsvorlage 852 und der Speicherzugriff, nicht temporäre 830 Befehlsvorlage), während das Beta-Feld 854 interpretiert wird als ein Datenmanipulationsfeld 854C, dessen Inhalt kennzeichnet, welcher der mehreren Datenmanipulationsoperationen (die auch als Primitiv bekannt sind) auszuführen ist (zum Beispiel, keine Manipulation; Broadcast, Hochkonvertierung einer Quelle; und Runter-Konvertierung eines Zieles). Die Befehlsvorlagen für den Speicherzugriff 820 umfassen das Skalierfeld 860 und, optional, das Verschiebungsfeld 862A oder das Verschiebungsskalierfeld 862B.
  • Vektor-Speicher-Befehle führen das Laden von Vektoren und das Speichern von Vektoren in einem Speicher durch, mit einer Konvertierunterstützung. Wie bei regulären Vektorbefehlen transferieren Vektor-Speicherbefehle Daten vom/zum Speicher in einer Weise von Datenelementen, wobei die Elemente, die tatsächlich transferiert werden, durch die Inhalte der Vektormaske, die durch die Schreibmaske ausgewählt wurde, vorgeschrieben werden. In der 8A werden gerundete Quadrate verwendet, um anzuzeigen, dass ein bestimmter Wert in einem Feld vorhanden ist (zum Beispiel Speicherzugriff 846B für das Modifizierfeld 846; Temporäre 852B.1 und Nicht-Temporäre 852B.2 für das Alpha-Feld 852/Räumungshinweisfeld 852B).
  • Speicherzugriff-Befehlsvorlage – Temporär
  • Temporäre Daten sind Daten, die möglicherweise bald wieder genutzt werden, so dass sie nützlicherweise zwischengespeichert werden. Dies ist jedoch ein Hinweis und unterschiedliche Prozesse können dies in unterschiedlicher Weise implementieren, einschließlich ein vollständiges Ignorieren des Hinweises.
  • Speicherzugriffs-Befehlsvorlage – Nicht Temporär
  • Nicht temporäre Daten sind Daten, die kaum früh genug wiedergenutzt werden, um von einem Caching in einem 1st-Level-Cache zu profitieren und sollten Priorität zum Räumen gegeben werden. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können diesen in unterschiedlicher Art implementieren, einschließlich des vollständigen Ignorieren des Hinweises.
  • Befehlsvorlage der Klasse B
  • Bei den Befehlsvorlagen der Klasse B wird das Alpha Feld 852 als ein Schreibmaskensteuerungsfeld (Z) 852C interpretiert, dessen Inhalt kennzeichnet, ob das Schreibmaskieren, welches durch das Schreibmaskenfeld 820 gesteuert wird, ein Verschmelzen oder ein Auf-Null-Setzen sein soll.
  • Kein-Speicherzugriff Befehlsvorlage der Klasse B
  • Bei den Befehlsvorlagen für keinen Speicherzugriff 805 der Klasse B wird ein Teil des Beta-Feldes 854 als ein RL Feld 857A interpretiert, dessen Inhalt kennzeichnet, welcher der unterschiedlichen Vergrößerungsoperationstypen auszuführen sind (zum Beispiel werden ein Runden 857A.1 und eine Vektorlänge (VSIZE) 857A.2 entsprechend gekennzeichnet für den keinen-Speicher-Zugriff, Schreibmaskensteuerung, Befehlsvorlage für einen teilweisen Rundungssteuerungstyp Operation 812 und keinen Speicherzugriff, Schreibmaskensteuerung, VSIZE-Typ Operation 817 Befehlsvorlage), während der Rest des Beta-Feldes 854 kennzeichnet, welche der Operationen des gekennzeichneten Typs auszuführen ist. In 8 werden die gerundeten Blöcke verwendet, um anzuzeigen, ob ein spezifischer Wert vorhanden ist (zum Beispiel kein Speicherzugrifff 846A in dem Modifizierfeld 846; Rundung 857A.1 und VSIZE 857A.2 für das RL-Feld 857A). In den Befehlsvorlagen für keinen Speicherzugriff 805, ist das Skalierfeld 860, das Verschiebungsfeld 862A, und das Verschiebungsskalierfeld 862B nicht vorhanden.
  • Befehlsvorlagen kein Speicherzugriff – Schreibmaskensteuerung, Teilrundungssteuerungsoperation
  • In der Befehlsvorlage kein Speicherzugriff, Schreibmaskensteuerung, Teilrundungssteuerungsoperation 810 wird der Rest des Beta-Feldes 854 als ein Rundungsoperationsfeld 859A interpretiert und ein Bericht zu einer Ausnahmebedingung ist ausgeschaltet (ein gegebener Befehl berichtet über keine Fließkomma-Ausnahmebedingungsanzeige und ruft keinen Fließkomma-Ausnahmebedingungshändler auf).
  • Rundungs-Operations-Steuerfeld 859A – wie auch bei dem Rundungsoperationssteuerfeld 858 unterscheidet dessen Inhalt, welcher aus der Gruppe von Rundungsoperationen auszuführen ist (zum Beispiel Aufrunden, Abrunden, Runden hin zu Null, Runden zu dem nächst gelegenen). Daher erlaubt das Rundungssteuerfeld 859A einen Wechsel des Rundungsmodus basierend auf einem Befehl und ist daher insbesondere nützlich, wenn dies erforderlich ist. In einem Ausführungsbeispiel der Erfindung, in dem der Prozessor ein Steuerregister zum Kennzeichnen des Rundungsmoduses umfasst, überschreibt der Inhalt des Rundungssteuerfeldes 850 diesen Registerwert (wobei es vorteilhaft ist, wenn es ermöglicht wird auszuwählen, welcher Rundungsmodus benutzt wird, ohne dass eine Sicherung-Änderung-Wiederherstellung eines solchen Steuerregisters auszuführen ist).
  • Kein-Speicherzugriff Befehlsvorlagen – Schreibmaskensteuerung, VSIZE-Operation
  • Bei der Kein-Speicherzugriff, Schreibmaskensteuerung, VSIZE-Operation 817 Befehlsvorlage wird der Rest des Beta-Feldes 854 als ein Vektor-Längenfeld 859B interpretiert, dessen Inhalt kennzeichnet, welcher aus der Anzahl von Datenvektorlängen darauf auszuführen ist (zum Beispiel 128, 856 oder 1012 Byte).
  • Befehlsvorlage-Speicherzugriff der Klasse B
  • Bei einer Befehlsvorlage Speicherzugriff 820 der Klasse A, wird ein Teil des Beta-Feldes 854 interpretiert als ein Broadcast Feld 857B, dessen Inhalt unterscheidet, ob oder ob nicht eine Broadcast Datenmanipulationsoperation auszuführen ist, während der Rest des Beta-Feldes 854 das Vektor-Längenfeld 859B interpretiert. Die Befehlsvorlagen Speicherzugriff 820 umfassen ein Skalierfeld 860 und optional ein Verschiebungsfeld 862A oder ein Verschiebungsskalierfeld 862B.
  • Zusätzliche Kommentare hinsichtlich der Felder
  • In Bezug auf das generische vektorfreundliche Befehlsformat 800 ist ein volles Befehlscodefeld 874 gezeigt, welches das Formatfeld 840, das Basisoperationsfeld 842 und das Datenelementbreitenfeld 864 umfasst. Während ein Ausführungsbeispiel gezeigt ist, in dem das vollständige Befehlscodefeld 874 alle diese Felder umfasst, umfasst in anderen Ausführungsbeispielen, die nichts davon unterstützen, das volle Befehlscodefeld 854 weniger als diese Felder. Das volle Befehlscodefeld 854 stellt den Operationscode bereit.
  • Das Vergrößerungsoperationsfeld 850, das Datenelementbreitenfeld 864 und das Schreibmaskenfeld 870 erlauben, dass diese Merkmale ausgewählt werden können auf der Basis von Befehlen in dem generischen vektorfreundlichen Befehlsformat.
  • Die Kombination des Schreibmaskenfeldes und des Datenbreitenfeldes erzeugen Maschinenbefehle, indem sie erlauben, dass die Maske basierend auf unterschiedlichen Datenelementenbreiten angewendet wird.
  • Das Befehlsformat erfordert eine relativ kleine Anzahl von Bits, weil unterschiedliche Felder für unterschiedliche Verwendungszwecke basierend auf den Inhalten der anderen Felder erneut genutzt werden. Zum Beispiel ist ein Aspekt dass der Inhalt des Modifizierfeldes gewählt werden kann zwischen den Befehlsvorlagen keinen Speicherzugriff 805 der 8A–B und den Befehlsvorlagen Speicherzugriff 8250 der 8A–B, während der Inhalt des Klassenfeldes 868 innerhalb dieser Befehlsvorlagen für keinen Speicherzugriff 805 zwischen Befehlsvorlagen 810/815 der 8A und 812/817 der 8B wählt; und während der Inhalt des Klassenfeldes 868 innerhalb solcher Speicherzugriffsbefehlsvorlagen 820 zwischen Befehlsvorlagen 825, 830 der 8A und 827 der 8B wählt. Von einem anderen Gesichtspunkt aus betrachtet, wählt der Inhalt des Klassenfeldes 868 zwischen der Klasse A und Klasse B Befehlsvorlagen entsprechend den 8A und B aus; während der Inhalt des Modifiziererfeldes innerhalb der Klasse A Befehlsvorlagen auswählt zwischen Befehlsvorlagen 805 und 820 der 8A; und während der Inhalt des Modifizierfeldes innerhalb dieser Klasse B Befehlsvorlagen auswählt zwischen Befehlsvorlagen 805 und 820 der 8B. Wenn der Inhalt des Klassenfeldes, welcher eine Klasse A Befehlsvorlage andeutet, wählt der Inhalt des Modifiziererfeldes 846 die Auslegung des Alpha-Feldes 852 aus (zwischen dem rs Feld 852A und dem EH Feld 852B). In ähnlicher Weise wählt der Inhalt des Modifizierfeldes 846 und des Klassenfeldes 868 aus, ob das Alpha-Feld als das rs Feld 852A, das EH Feld 852B, oder das Schreibmaskensteuer (Z) Feld 852C interpretiert wird. In dem Fall, wenn die Klassen und Modifizierfelder ein Klasse A kein-Speicherzugriff-Operation andeuten, wechselt die Interpretation des Beta-Feldes des Vergrößerungsfeldes basierend auf den Inhalt des rs Feldes; während im Falle, dass die Klassen und Modifizierfelder ein Klasse B kein-Speicherzugriffsoperation anzeigen, die Interpretation des Beta Feldes von den Inhalten des RL Feldes abhängt. In dem Fall, dass die Klassen- und Modifizierfelder eine Klasse A Speicherzugriffsoperation anzeigen, wechselt die Interpretation des Beta-Feldes des Vergrößerungsfeldes basierend auf den Inhalt des Basisoperationsfeldes; während im Fall, dass die Klassen und Modifizierfelder eine Klasse B Speicherzugriff-Operation anzeigen, die Interpretation des Broadcast-Feldes 857B des Beta-Feldes des Vergrößerungsfeldes basierend auf den Inhalten des Basisoperationsfeldes wechselt. Daher erlauben die Kombination des Basisoperationsfeldes, des Modifizierfeldes und des Vergrößerungsoperationsfeldes eine größere Vielfalt von Vergrößerungsoperationen, die spezifiziert werden können.
  • Die unterschiedlichen Befehlsvorlagen, die innerhalb der Klasse A und Klasse B gefunden werden, sind für verschiedene Situationen vorteilhaft. Die Klasse A ist nützlich, wenn Schreibmaskierungen auf Null gesetzt werden oder kleinere Vektorlängen für Performancegründe gewünscht werden. Das zu Null setzen erlaubt zum Beispiel das Vermeiden von gefälschten Abhängigkeiten, wenn eine Umbenennung genutzt wird, da es nicht weiter erforderlich ist, künstlich mit dem Ziel zu verschmelzen; als ein anderes Beispiel erleichtert die Vektorlängensteuerung Speicher-Last-Weiterleitungsprobleme, wenn ein kürzerer Vektor mit der Vektormaske emuliert wird. Die Klasse B ist nützlich, wenn es wünschenswert ist: 1) Fließkomma-Ausnahmebedingungen zu erlauben (d. h., wenn die Inhalte des SAE Feldes ein Nein anzeigen), während der Nutzung einer Rundungs-Modus-Steuerung zur gleichen Zeit; 2) in der Lage zu sein, eine Hoch-Konvertierung durchzuführen, ein Swizzling, ein Austauschen und/oder eine Herunter-Konvertierung durchzuführen; 3) auf einen Graphikdatentyp zu operieren. Zum Beispiel verringert eine Hoch-Konvertierung, Swizzling, ein Tauschen, eine Herunter-Konvertierung und der Graphik-Datentyp die Anzahl von Befehlen, die erforderlich sind, wenn mit Quellen in unterschiedlichen Formaten zu arbeiten ist; als ein weiteres Beispiel, die Fähigkeit Ausnahmebedingungen zu erlauben, stellt volle IEEE Konformität mit einem vorgeschriebenen Rundungsmodus bereit.
  • Beispielhaftes spezifisches vektorfreundliches Befehlsformat
  • 9A–C zeigen beispielhafte spezifische vektorfreundliche Befehlsformate entsprechend Ausführungsbeispielen der vorliegenden Erfindung. 9A–C zeigen ein spezifisches vektorfreundliches Befehlsformat 900, welches spezifisch in dem Sinne ist, dass es den Ort, die Größe, die Interpretation und die Ordnung der Felder als auch die Werte von einigen dieser Feldern vorschreibt. Dieses spezifische vektorfreundliche Befehlsformat 900 kann genutzt werden als Erweiterung des x86 Befehlssatzes und daher sind einige der Felder ähnlich oder gleich zu solchen, die bereits in existierenden x86 Befehlssatz genutzt werden bzw. Erweiterungen davon (zum Beispiel, AVX). Dieses Format bleibt konsistent mit dem Prefix Codier-Feld, realen Befehlscode Byte Feld, MOD R/M-Feld, SIB Feld, Verschiebungsfeld, und Direktdatenfeldern des existierenden x86 Befehlssatz mit Erweiterungen. Die Felder der 8, in welchen sich die Felder die 9A–C abbilden, sind dargestellt.
  • Es versteht sich, dass obwohl Ausführungsbeispiele der Erfindungen in Bezug auf das spezifische vektorfreundliche Befehlsformat 900 in dem Zusammenhang von dem generischen vektorfreundlichen Instruktionsformat 800 beschrieben sind, um beispielhafte Anwendungsbereiche darzustellen, ist die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 900 beschränkt bzw. nur dann wenn es beansprucht wird. Zum Beispiel sind in dem generischen vektorfreundlichen Befehlsformat 800 eine Vielzahl von möglichen Größen für verschiedene Felder genannt, während das spezifische vektorfreundliche Befehlsformat 900 gezeigt ist, dass es Felder von bestimmten Größen aufweist. Nur um ein spezifisches Beispiel zu geben, während das Datenelementbreitenfeld 864 als ein ein-Bit-Feld in dem spezifischen vektorfreundlichen Befehlsformat 900 dargestellt ist, ist die Erfindung nicht darauf beschränkt (das heißt, das generische vektorfreundliche Befehlsformat 800 beinhaltet ebenso andere Größen für das Datenelementbreitenfeld 864).
  • Format-Fig. 9A–C
  • Das generische vektorfreundliche Befehlsformat 800 umfasst die folgenden Felder, die unten in der Reihenfolge wie in den 9A bis 9C dargestellt sind.
  • EVEX Präfix (Bytes 0-3)
  • EVEX Präfix 902 – welches in einem 4-Byte-Format kodiert ist.
  • Formatfeld 840 (EVEX Byte 0, Bits [7:0]) – das erste Byte (EVEX Byte 0) ist das Formatfeld 840 und es enthält 0x62 (der eindeutige Wert, der genutzt wird, um das vektorfreundliche Befehlsformate in einem Ausführungsbeispiel der Erfindung zu unterscheiden).
  • Das zweite bis vierte Byte (EVEX Bytes 1-3) umfasst eine Anzahl von Bit-Feldern, die eine spezifische Fähigkeit bereitstellen.
  • REX-Feld 905 (EVEX Byte 1, Bits [7-5]) – besteht aus einem EVEX.R Bit-Feld (EVEX Byte 1, Bits [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 die gleiche Funktionalität bereit wie die entsprechenden VEX Bit-Felder und sind kodiert unter Nutzung von 1s Ergänzungsform, das heißt, ZMM0 ist kodiert als 1111B, ZMM15 ist kodiert als 0000B. Andere Felder der Befehle kodieren die unteren 3 Bits der Registerindices, wie sie im Stand der Technik bekannt ist (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb gebildet werden können durch Addieren von EVEX.R, EVEX.X und EVEX.B.
  • Das Feld 910 von REX – dies ist der erste Teil des Feldes 910 des REX und ist das Bit-Feld des EVEX.R (EVEX Byte 1, Bit [4]-R'), welches genutzt wird zum Kodieren von entweder den oberen 16 oder den unteren 16 des erweiterten 32-Bit-Satzes. In einem Ausführungsbeispiel der Erfindung ist dieses Bit zusammen mit anderen, wie unten dargestellt, im bit-invertierten Format gespeichert, um (in dem bekannten x86 32-Bit-Mode) von den BOUND-Befehlen zu unterscheiden, deren Befehlscode-Byte 62 ist, aber in dem MOD R/M-Feld (wie unten beschrieben) nicht den Wert von 11 in dem MOD-Feld akzeptiert; andere Ausführungsbeispiele der Erfindungen speichern nicht diesen und die anderen angezeigten Bits im invertierten Format ab. Ein Wert von 1 wird genutzt, um die unteren 16 Register zu kodieren. In anderen Worten, ist R'Rrrr gebildet durch ein Kombinieren von EVEX.R', EVEX.R und dem anderen RRR von den anderen Feldern.
  • Das Befehlscodeabbildungsfeld 915 (EVEX Byte 1, Bits [3:0]-mmmm) – sein Inhalt kodiert ein beabsichtigtes führendes Befehlscode-Byte (0F, 0F 38 oder 0F 3).
  • Datenelementbreitenfeld 864 (EVEX Byte 2, Bit [7]-W) – wird dargestellt durch die Bezeichnung EVEX.W. EVEX.W wird verwandt um eine 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 Bedeutung von EVEX.vvvv kann das Folgende umfassen: 1) EVEX.vvvv kodiert den ersten Quellregisteroperanden, der in inventierter (1s-Kompliment) Form spezifiziert ist, und für Befehle mit zwei oder mehr Quelloperanden gültig ist; 2) EVEX.vvvv kodiert den Zielregisteroperanden, der in 1s-Kompliment-Form für bestimmte Vektorverschiebungen spezifiziert ist; oder 3) EVEX.vvvv kodiert keinen Operanden, das Feld ist reserviert und sollte enthalten 1111b. Daher kodiert das EVEX vvvv-Feld 920 die 4 niederwärtigen Bits der Spezifikationssymbole des ersten Quellregister, die in invertierter (1s-komplimentären)-Form gespeichert sind. In Abhängigkeit von dem Befehl ist ein zusätzliches unterschiedliches EVEX-Bit-Feld verwandt, um die Größe des Spezifikationssymbols auf 32 Register auszudehnen.
  • EVEX.U 868 Klassenfeld (EVEX Byte 2, Bit [2]-U) – wenn EVEX.U = 0, zeigt dies Klasse A an oder EVEX.U0; wenn EVEX.U = 1, zeigt dies Klasse B oder EVEX.U1 an.
  • Das Präfixkodierfeld 925 (EVEX Byte 2, Bits [1:0]-pp) – stellt zusätzliche Bits zum Basisoperationsfeld bereit. Zusätzlich zu dem Bereitstellen einer Unterstützung für vorhandene SSE-Befehle in dem EVEX-Präfix-Format hat dies ebenso den Nutzen, den SIMD-Präfix kompakter zu machen (anstatt zu erfordern, dass ein Byte das SIMD-Präfix ausdrücken muss, erfordert das EVEX-Präfix nur zwei Bits). In einem Ausführungsbeispiel, um vorhandenen SSE-Befehle zu unterstützen, die ein SIMD-Präfix nutzen (66H, F2H, F3H), sind in beiden vorhandenen Formaten und in dem EVEX-Präfix-Format diese vorhandenen SIMD-Präfixe kodiert in dem SIMD-Präfix-Kodierformat; und bei der Ausführung werden sie expandiert in das vorhandene SIMD-Präfix bevor sie einem PLA eines Decoders bereitgestellt werden, (so dass der PLA beides ausführen kann, das vorhanden und EVEX-Format von diesen vorhandenen Befehlen ohne Änderungen). Obwohl neuere Befehle den Inhalt des EVEX-Präfix-Kodierfeldes direkt als Befehlscodeerweiterung nutzen können, sind bestimmte Ausführungsbeispiele in einer ähnlichen Art wegen der Konsistenz ausgedehnt und erlauben unterschiedliche Bedeutungen, die durch die vorhandenen SIMD-Präfixe spezifiziert sind. Ein anderes Ausführungsbeispiel kann das PLA neugestalten, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, und erfordert daher keine Erweiterung.
  • Das Alphafeld 852 (EVEX Byte 3, Bit [7]-EH; welches auch bekannt ist als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N; welches auch mit α gekennzeichnet ist) – dieses Feld ist wie zuvor beschrieben kontextspezifisch. Zusätzliche Beschreibung ist weiter unten hinzugefügt.
  • Das Betafeld 854 (EVEX Byte 3, Bits [6:4]-SSS, welches ebenso bekannt ist als EVEX.s2-0; EVEX.r2-0, EVEX.rr1, EVEX.LL0; EVEX.LLB; welches auch mit βββ dargestellt wird) – dieses Feld ist wie zuvor beschrieben kontextspezifisch. Eine zusätzliche Beschreibung ist weiter unten hinzugefügt.
  • Das Feld 910 vom REX – dies ist der Rest von dem Feld von REX und ist das EVEX.V'-Bit-Feld (EVEX Byte 3, Bit [3]-V'), welches genutzt werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32 Registersatze zu kodieren. Dieses Bit ist in einem invertierten Bit-Format gespeichert. Ein Wert von 1 wird genutzt, um die unteren 16 Register zu kodieren. In anderen Worten, V'VVVV ist gebildet durch eine Kombination von EVEX.V', EVEX.vvvv.
  • Schreibmaskenfeld 870 (EVEX Byte 3, Bits [2:0]-kkk) – sein Inhalt bestimmt den Index eines Registers in den Schreibmaskenregistern wie zuvor beschrieben. In einem Ausführungsbeispiel der Erfindung hat der spezifische Wert EVEX.kkk = 000 ein spezifisches Verhalten, welches bedeutet, dass keine Schreibmaske genutzt wird für den bestimmten Befehl (dies kann implementiert sein in eine Vielzahl von Wegen, einschließlich der Nutzung einer Schreibmaskenverdrahtung von allen oder durch Hardware, welche die Maskenhardware umgeht).
  • Realer Befehlscode-Feld 930 (Byte 4)
  • Dies ist auch bekannt als das Befehlscode-Byte. Teil des Befehlscodes ist in diesem Feld spezifiziert.
  • MOD R/M-Feld 940 (Byte 5)
  • Das Modifier-Feld 846 (MODR/M.MOD, Bits [7-6]-MOD-Feld 942) – wie zuvor beschrieben kennzeichnet der Inhalt des MOD-Feldes 942 den Speicherzugriff und den Nichtspeicherzugriffsoperationen. Dieses Feld wird weiter unten näher beschrieben.
  • MODR/M.reg-Feld 944, Bits [5-3] – die Rolle des MODR/M.reg.-Feldes kann durch zwei Situationen zusammengefasst werden: MODR/M.reg kodiert entweder den Zielregisteroperanden oder einen Quellregisteroperanden oder das MODR/M.reg wird als Befehlscodeerweiterung betrachtet und wird nicht genutzt zur Kodierung irgendeines Befehlsoperanden.
  • MODR/M.r/m-Feld 946, Bits [2-0] – die Rolle des MODR/M.r/m-Feldes kann das Folgende umfassen: MODR/M.r/m kodiert Befehlsoperanden, die sich auf eine Speicheradresse beziehen oder MODR/M.r/m kodiert entweder den Zielregisteroperanden oder einen Quellregisteroperanden.
  • Skalierung, Index, Bais (SIB) Byte (Byte6)
  • Skalierfeld 860 (SIB.SS, Bits [7-6] – wie zuvor beschrieben wird der Inhalt des Skalierfeldes 860 genutzt zur Erzeugung von Speicheradressen. Dieses Feld wird weiter unten näher beschrieben.
  • SIB.xxx 954 (Bits [5-3] und SIB.bbb 956 (Bits [2-0]) – auf die Inhalte dieser Felder wurde zuvor Bezug genommen in Bezug auf die Registerindices Xxxx und Bbbb.
  • Verschiebungsbyte(s) (Byte 7 oder Bytes 7-10)
  • Das Verschiebungsfeld 862A (Bytes 7-10) – wenn das MOD-Feld 942 10 enthält, werden die Bytes 7-10 das Verschiebungsfeld 862A und es funktioniert in der gleichen Art wie für vorhandene 32-Bit-Verschiebungen (disp32) und arbeitet auf Byte-Granularität.
  • Verschiebungsfaktorfeld 862B (Byte 7) – wenn das MOD-Feld 942 einen Wert 01 enthält, ist das Verschiebungsfaktorfeld 862B Byte 7. Die Lage dieses Feldes ist die gleiche wie bei dem vorhandenen x86-Befehlssatz 8-Bit-Verschiebung (disp8), welches auf Byte-Granularität arbeitet. Da das disp8-Vorzeichen erweitert ist, kann es nur Adressen zwischen –128 und 127 Bytes versetzen adressieren; in Bezug auf 64-Byte-Cachezeilen disp8 nutzt 8 Bits, die nur auf 4 sinnvolle Werte gesetzt werden kann –128, –64, 0 und 64; da häufig ein größerer Bereich erforderlich ist, wird disp32 genutzt; jedoch erfordert die disp32 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 862B eine Uminterpretation des disp8; wenn das Verschiebungsfaktorfeld 862B genutzt wird, wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfeldes multipliziert durch die Größe des Speicheroperandenzugriffs (N) bestimmt. Diese Art von Verschiebung wird bezeichnet als disp8*N. Dies reduziert die durchschnittliche Befehlslänge (ein einfaches Byte wird für eine Verschiebung genutzt, aber mit einem wesentlich größeren Bereich). Diese komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung multipliziert wird mit der Granularität des Speicherzugriffs und daher brauchen die redundanten niedrigwertigen Bits des Adressversatzes nicht kodiert zu werden. In anderen Worten, das Verschiebungsfaktorfeld 862B ersetzt den vorhandenen x86-Befehlssatz 8-Bit-Verschiebung. Daher kodiert das Verschiebungsfaktorfeld 862B in der gleichen Art wie eine x86-Befehlssatz 8-Bit-Verschiebung (daher sind keine Änderungen in den MODRM/SIB-Kodierregeln erforderlich), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird. In anderen Worten, es gibt keine Änderungen in den Kodierregeln oder Kodierlängen, aber lediglich in der Interpretation des Verschiebungswertes durch die Hardware (welches die Verschiebung zu skalieren hat durch einen Wert des Speicheroperanden, um eine byte-artigen Adressverschiebung zu erhalten).
  • Direktdaten
  • Direktdatenfeld 872 operiert wie zuvor beschrieben.
  • Beispielhafte Registerarchitektur – Fig. 10
  • 10 ist ein Blockdiagramm einer Registerarchitektur 1000 entsprechend zu einem Ausführungsbeispiel der Erfindung. Die Registerdateien und Register der Registerarchitektur sind unten aufgelistet:
    Vektorregisterdatei 1010 – in dem dargestellten Ausführungsbeispiel gibt es 32 Vektorregister, die 1012-Bit breit sind; diese Register werden referenziert als zmm0 bis zmm31. Die niederwertigen 856-Bits der unteren 16 zmm-Register sind überlagert auf die Register ymm0-16. Die niedrigen 128 Bits der unteren 16 zmm-Register (die niederwertigen 128 Bits der ymm-Register) sind überlagert auf die Register xmm0-15. Das spezifische vektorfreundliche Befehlsformat 900 operiert auf den überlagerten Registerdateien wie es in der Tabelle unten dargestellt ist.
    Justierbare Vektorlänge Klasse Operationen Register
    Befehlsvorlagen, die kein Vektorlängenfeld umfassen 859B A (Fig. 8A; U = 0) 810, 815, 825, 830 zmm Register (die Vektorlänge ist 64 byte)
    B (Fig. 8B; U = 1) 812 zmm Register (die Vektorlänge ist 64 byte)
    Befehlsvorlage, die das Vektorlängenfeld umfassen 859B B (Fig. 8B; U = 1) 817, 827 zmm, ymm, oder xmm Register (die Vektorlänge ist 64 byte, 32 byte, oder 16 byte) abhängig von dem Vektorlängenfeld 859B
  • Anders ausgedrückt selektiert das Vektorlängenfeld 859B zwischen einer maximalen Länge und einer oder mehreren kürzeren Längen, wobei jede der kürzeren Längen die Hälfte der vorherigen Länge ist; und Befehlsvorlagen ohne das Vektorlängenfeld 859B operieren auf der maximalen Vektorlänge. In einem Ausführungsbeispiel operieren ferner Befehlsvorlagen für das spezifische vektorfreundliche Befehlsformat 900 der Klasse B auf verpackte oder einfach skalare, doppelt genaue Fließkommadaten und verpackte oder ganzzahlig skalare Daten. Skalare Operationen sind Operationen, die auf der Datenelementposition der niedrigsten Ordnung in einem zmm/ymm/xmm Register ausgeführt werden; die Datenelementenpositionen höherer Ordnung werden entweder so belassen wie sie vor dem Befehl waren oder werden auf Null gesetzt in Abhängigkeit von dem Ausführungsbeispiel.
  • Schreibmaskenregister 1010 – in dem gezeigten Ausführungsbeispiel gibt es 8 Schreibmaskenregister (k0 bis k7), wovon jedes 64 Bits groß ist. Wie zuvor beschrieben kann in einem Ausführungsbeispiel der Erfindung das Vektormaskenregister k0 nicht als Schreibmaske benutzt werden; wenn die Kodierung, die normalerweise anzeigen würde, dass k0 als eine Schreibmaske verwendet wird, dann wählt es eine hartverdrahtete Schreibmaske von 0xFFFF aus, was effektiv das Schreibmaskieren für den Befehl abschaltet.
  • Multimedia Erweiterungssteuerstatusregister (MXCSR) 1020 – in dem gezeigten Ausführungsbeispiel stellt dieses 32-Bit-Register Status und Steuerbits zur Verwendung von Fließkommaoperationen bereit.
  • Universalregister 1025 – in dem gezeigten Ausführungsbeispiel gibt es sechzehn 64-Bit Universalregister, die zusammen mit den existierenden x86 Adressierungsmodi zum Adressieren von Speicheroperanden genutzt werden. Auf diese Register wird Bezug genommen durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15.
  • Das Erweiterungsflag (EFLAGS) Register 1030 – in dem gezeigten Ausführungsbeispiel wird dieses 32 Bit Register genutzt zum Aufnehmen der Resultate von vielen Befehlen.
  • Fließkommasteuerwort (FCW) Register 1035 und Fließkommastatuswort (FSW) Register 1040 – in dem gezeigten Ausführungsbeispiel werden diese Register verwandt durch x87 Befehlssatzerweiterungen, um Rundungsmodi, Ausnahmebedingungenmaskierungen und Flags für den Fall von FCW anzuzeigen und um Ausnahmebedingungen für den Fall von FSW nachzuverfolgen.
  • Skalare, Fließkommastackregisterfile (x87 Stack) 1045 auf welches das MMX verpackte ganzzahlige flache Registerfile 1050 einen Alias hat – in dem gezeigten Ausführungsbeispiel ist der x87 Stack ein acht-Elemente Stack, der verwandt wird zum Ausführen von skalaren Fließkommaoperationen auf 32/64/80-Bit Fließkommadaten, die die x87 Befehlssatzerweiterung nutzen; während die MMX Register genutzt werden zum Ausführen von Operationen auf 64-Bit gepackte ganzzahlige Daten als auch um Operanden für einige Operationen, die zwischen den MMX und XMM Registern auszuführen sind, zu halten.
  • Segmentregister 1055 – in dem gezeigten Ausführungsbeispiel gibt es sechs 16-Bit Register, die genutzt werden zum Speicher von Daten, die für die segmentiere Adresserzeugung genutzt werden.
  • RIP Register 1065 – in dem gezeigten Ausführungsbeispiel speichert dieses 16-Bit-Register den Befehlszeiger.
  • Andere Ausführungsbeispiele der Erfindung nutzen breitere oder engere Register. Außerdem nutzen andere Ausführungsbeispiele der Erfindung mehr, weniger oder andere Registerdateien oder Register.
  • Beispielhafte In-Fester-Ordnung Prozessor Architektur – Fig. 11A–Fig. 11B
  • 11A–11B zeigen ein Beispiel einer beispielhaften In-Fester-Ordnung Prozessorarchitektur. Diese beispielhafte Ausführungsbeispiele sind um mehrfache Instanziierung eines In-Fester-Ordnung CPU-Kerns, der vergrößerter ist mit einem weiten Vektorprozessor (VPU) gestaltet. Kerne kommunizieren über ein hochbandbreitiges Verbindungsnetzwerk mit einigen festen Funktionslogikschaltungen, Speicher I/O Schnittstellen und anderen notwendigen I/O Logikschaltungen in Abhängigkeit von der e13t Anwendung. Beispielsweise würde eine Implementierung dieses Ausführungsbeispiels als eine eigenständige GPU typischerweise ein PCIe Bus umfassen.
  • 11A ist ein Blockdiagramm eines einfachen CPU Kerns zusammen mit dessen Verbindung zu einem auf dem Chip vorhanden Verbindungsnetzwerk 1102 und mit seinem lokalen Unterbereich von Level 2 (L2) Cache 1102, entsprechend Ausführungsbeispielen der Erdfindung. Ein Befehlsdecoder 1110 unterstützt den x86 Befehlssatz mit einer Erweiterung, die das spezifische Vektorbefehlsformat 900 umfasst. Während in einem Ausführungsbeispiel der Erfindung (um die Ausführung zu vereinfachen) eine Skalareinheit 1108 und eine Vektoreinheit 1110 separate Registersätze nutzen (entsprechende Skalarregister 1112 und Vektorregister 1114) und Daten, die zwischen ihnen transferiert werden, in Speicher geschrieben und dann von einem Level 1 (L1) Cache 1106 zurückgelesen werden, könnten andere Ausführungsbeispiele der Erfindung einen unterschiedlichen Zugang wählen (zum Beispiel die Verwendung eines einfachen Registersatzes oder Einbeziehen eines Kommunikationspfades, der es erlaubt, Daten zwischen den zwei Registerfilen zu transferieren ohne dass sie geschrieben oder zurückgelesen werden).
  • Der L1 Cache 1106 erlaubt Zugriffe mit geringer Wartezeit auf Cachespeicher in den Skalar- und Vektoreinheiten. Zusammen mit Lade-OP Befehlen in dem vektorfreundlichen Befehlsformat bedeutet dies, dass der L1 Cache 1106 behandelt werden kann als ein erweitertes Registerfile. Dies verbessert signifikant die Performance von vielen Algorithmen, insbesondere mit dem Räumungshinweisfeld 852B.
  • Der lokale Unterbereich von L2 Cache 1104 ist Teil eines globalen L2 Caches, der geteilt ist in separate, lokale Unterbereiche, einen pro CPU Kern. Jede CPU hat einen direkten Zugangspfad zu ihrem eigenen lokalen Unterbereich von L2 Cache 1104. Daten, die durch einen CPU Kern gelesen werden, werden in ihrem L2 Cache Unterbereich 1104 gespeichert und darauf kann schnell zugegriffen werden, parallel mit anderen CPU Zugriffen auf deren eigenen lokalen L2 Cacheunterbereich. Daten, die durch einen CPU Kern geschrieben werden, werden in ihrem eigenen L2 Cache Unterbereich 1104 gespeichert und werden von anderen Unterbereichen, wenn notwendig entleert. Ein Ringnetzwerk stellt die Kohärenz von geteilten Daten sicher.
  • 11B ist eine auseinander gezogene Ansicht eines Teils des CPU Kerns der 11A entsprechend zu Ausführungsbeispielen der Erfindung. 11B umfasst einen L1 Datencache 1106A Teil des L1 Caches 1104 als auch weitere Details in Bezug auf die Vektoreinheit 1110 und die Vektorregister 1114. Insbesondere ist die Vektoreinheit 1110 ein 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 1128), welche Befehle ganzzahliger Werte, Fließzahlen einfacher Präzision, Fließzahlen doppelter Präzision ausführt. Die VPU unterstützt Swizzling der Registereingaben mit der Swizzle einheit 1120, numerische Umwandlungen mit den numerischen Umwandlungseinheiten 1122A–B und Nachbilden mit der Nachbildungseinheit 1124 auf dem Speichereingang. Die Schreibmaskenregister 1126 erlauben die Vorhersage des resultierenden Vektorgeschriebenen.
  • Datenregister können einer Swizzleoperation auf unterschiedlichen Wegen unterworfen werden, zum Beispiel um Matrixmultiplikationen zu unterstützen. Daten von einem Speicher können nachgebildet werden über die VPU Linien. Das ist eine übliche Operation sowohl in Graphik- als auch in nichtgraphik parallelen Datenverarbeitungen, was signifikant die Cacheeffizienz erhöhen.
  • Das Ringnetzwerk ist ein bidirektionales, um Agenten wie CPU Kerne, L2 Caches und anderen Logikblöcken zu erlauben, miteinander innerhalb des Chips zu kommunizieren. Jeder Ringdatenpfad ist 1012-Bit breit pro Richtung.
  • Beispielhafte In-Anderer-Ordnung Architektur – Fig. 12
  • 12 ist ein Blockdiagramm, welches eine beispielhafte In-Anderer-Ordnung Architektur gemäß Ausführungsbeispielen der Erfindung zeigt. Insbesondere zeigt die 12 eine bekannte beispielhafte In-Anderer-Ordnung Architektur, die modifiziert wurde, um das vektorfreundliche Befehlsformat und die Ausführung davon miteinzubeziehen. In der 12 bezeichnen Pfeile eine Kopplung zwischen zwei oder mehr Einheiten und die Richtung der Pfeile zeigen eine Richtung des Datenflusses zwischen diesen Einheiten an. 12 umfasst eine vordere Endeinheit 1205, die an einer Ausführungsmaschineneinheit 1210 koppelt und an eine Speichereinheit 1215 koppelt; die Ausführungsmaschineneinheit 1210 koppelt weiterhin an die Speichereinheit 1215.
  • Die Frontendeinheit 1205 umfasst eine Level 1 (L1) Vorhersageeinheit 1220, die an eine Level 2 (L2) Vorhersageeinheit 1222 koppelt. Die L1 und L2 Vorhersage-Einheiten 1220 und 1222 koppeln an die L1 Befehlscacheeinheit 1224. Die L1 Befehlscacheeinheit 1224 koppelt an einen Befehlsübersetzungspuffer (TLB) 1226, der weiter an eine Befehlsabhol- und Vorkodiereinheit 1228 koppelt. Die Befehlsabhol- und Vorkodiereinheit 1228 ist an eine Befehlswarteeinheit 1230 gekoppelt, die weiter an eine Dekodereinheit 1232 koppelt. Die Dekodereinheit 1232 umfasst eine komplexe Dekodereinheit 1234 und drei einfache Dekodereinheiten 1236, 1238 und 1240. Die Dekodereinheit 1232 umfasst eine Mikrocode ROM-Einheit 1242. Die Dekodereinheit 1232 kann wie zuvor beschrieben in der Dekoderstufenabteilung opererien. Die L1 Befehlscacheeinheit 1224 koppelt weiter an eine L2 Cacheeinheit 1248 in der Speichereinheit 1215. Die Befehls TLB Einheit 1226 koppelt weiter an einen zweiten Level TLB Einheit 1246 in der Speichereinheit 1215. Die Dekodereinheit 1232, die Mikro-Code ROM Einheit 1242 und eine Loopstromdetektionseinheit 1244 koppeln jeweils an eine Umbenennungs/Zuweisungseinheit 1256 in der Ausführungseinheit 1210.
  • Die Ausführungsmaschineneinheit 1210 umfasst eine Umbenennungs/Zuweisungseinheit 1256, die an eine Stilllegungseinheit 1274 und eine vereinigte Planungseinheit 1258 koppelt. Die Stilllegungseinheit 1274 koppelt weiter an die Ausführungseinheiten 1260 und umfasst eine Umordnungspuffereinheit 1278. Die vereinigte Planungseinheit 1258 koppelt an eine physische Registerfileeinheit 1276, welche an die Verarbeitungseinheiten 1260 koppelt. Die physische Registerfileeinheit 1276 umfasst eine Vektorregistereinheit 1277A, eine Schreibmaskierungsregistereinheit 1277B und eine Skalarregistereinheit 1277C; diese Registereinheiten können die Vektorregister 1010, die Vektormaskierungsregister 1015, und die universellen Register 1025 bereitstellen; und die physische Registerfileeinheit 1276 kann zusätzliche Registerfile, die nicht gezeigt sind, umfassen (zum Beispiel das skalare Fließkommastackregisterfile 1045, das auf den MMX verpackten ganzzahligen flachen Register 1050 zeigt). Die Ausführungseinheiten 1260 umfassen drei gemischte skalare und Vektoreinheiten 1262, 1264 und 1272; die Ladeeinheit 1266; eine Speicheradressiereinheit 1268, eine Datenspeichereinheit 1270. Die Ladeeinheit 1266, die Speicheradressiereinheit 1268, und die Datenspeichereinheit 1270 sind weiter an die Daten TLB Einheit 1252 in der Speichereinheit 1215 gekoppelt.
  • Die Speichereinheit 1215 umfasst die zweite Level TLB Einheit 1246, die an die Daten TLB Einheit 1252 koppelt. Die Daten TLB Einheit 1252 koppelt an die L1 Datencacheeinheit 1254. Die L1 Datencacheeinheit 1254 ist weiter gekoppelt an eine L2 Cacheeinheit 1248. In einigen Ausführungsbeispielen ist die L2 Cacheeinheit 1248 weiter gekoppelt an L3 und höheren Cacheeinheiten 1250 innerhalb und/oder außerhalb der Speichereinheit 1215.
  • Um ein weiteres Beispiel anzugeben, kann die beispielhafte In-Anderer-Ordnung Architektur die Prozesspipeline 8200 wie folgt implementieren: 1) die Befehlsabhole und Vorkodiereinheit 1228 führt den Abhol- und den Längendekodierzustand aus; 2) die Dekodiereinheit 1232 führt die Dekodierstufe aus; 3) die Umbenennungs/Zuweisungseinheit 1256 führt die Zuweisungssstufe und die Umbennennungsstufe aus; 4) der vereinigte Planer 1258 führt die Planungsstufe aus; 5) die physische Registerfileeinheit 1276, die Urnordnungspuffereinheit 1278 und die Speichereinheit 1215 führen die Registerlese/Speicherlesestufe aus; die Ausführungseinheiten 1260 führen die Ausführungs/Datentransformationsstufe durch; 6) die Speichereinheit 1215 und die Umordnungspuffereinheit 1278 führen die Zurückschreibe/Speicherschreibestufe 1960 durch; 7) die Stilllegungseinheit 1274 führt die ROB Lesestufe durch; 8) unterschiedliche Einheiten können einbezogen werden in der Handhabungsstufe für Ausnahmenbedingungen; und 9) die Stilllegungseinheit 1274 und die physische Registerfileeinheit 1276 führen die Commitstufe durch.
  • Beispielhafte Einkern- und Multikernprozessoren – Fig. 17
  • 17 ist ein Blockdiagramm für einen Einkernprozessor und einen Multikernprozessor 1700 mit integriertem Speichercontroller und integrierter Graphik entsprechend zu Ausführungsbeispielen der Erfindung. Die durchgezogene Linienbox in der 17 stellt einen Prozessor 1700 mit einem einfachen Kern 1702A dar, einen Systemagenten 1710, einen Satz von einem oder mehreren Bussteuereinheiten 1716, während die optional zusätzlichen unterbrochenen Linienboxen andere Prozessor 1700 darstellen mit mehreren Kernen 1702A–N, einen Satz von einem oder mehreren integrierten Speichercontrollereinheit(en) 1714 in der Systemagenteneinheit 1710 und eine integrierte Speichergraphiklogik 1708 darstellen.
  • Die Speicherhierarchie umfasst ein oder mehrere Level von Cache innerhalb der Kerne, einen Satz von einen oder mehreren geteilten Cacheeinheiten 1706 und einen externen Speicher (nicht gezeigt), der an den Satz von integrierten Speichercontrollereinheiten 1714 koppelt. Der Satz von geteilten Cacheeinheiten 1706 kann einen oder mehrere Cachespeicher von mittlerem Niveau umfassen, wie zum Beispiel Level 2 (L2), Level 3 (L3), Level 4 (L4) oder anderen Levels von Cache umfassen, einen letzten Levelcache (LLC), und/oder Kombinationen davon. Während in einem Ausführungsbeispiel eine ringbasierte Verbindungseinheit 1712 die integrierte Graphiklogikschaltung 1708, den Satz von geteilten Cacheeinheiten 1706 und die Systemagenteneinheit 1710 miteinander verbindet, kann in weiteren Ausführungsbeispielen jede Anzahl von bekannten Techniken zum Verbinden solcher Einheiten benutzt werden.
  • In anderen Ausführungsbeispielen sind eine oder mehrere Kerne 1702A–N in der Lage, Multi-Threading auszuführen. Der Systemagent 1710 umfasst solche Komponenten, die die Kerne 17012A–N koordinieren und betreiben. Die Systemagenteneinheit 1710 kann beispielsweise eine Leistungssteuereinheit (PCU) und eine Displayeinheit umfassen. Die PCU kann eine Logikschaltung und Komponenten sein oder umfassen, die erforderlich sind zum Regulieren des Leistungszustandes der Kerne 1702A–N und der integrierten Graphiklogik 1708. Die Displayeinheit ist zum Betreiben von einem oder mehreren extern verbundenen Anzeigen ausgebildet.
  • Die Kerne 1702A–N können homogen oder heterogen in Bezug auf die Architektur und/oder des Befehlssatzes sein. Zum Beispiel können einige der Kerne 1702A–N In-Fester-Ordnung sein (zum Beispiel wie jene, die in den 11A und 11B gezeigt sind) während andere In-Anderer-Ordnung sind (zum Beispiel wie die in der 12 gezeigten). In einem anderen Beispiel können zwei oder mehr der Kerne 1702A–N in der Lage sein, den gleichen Befehlssatz auszuführen, während andere in der Lage sind, lediglich eine Untermenge des Befehlssatzes auszuführen oder andere Befehlssätze auszuführen. Zumindest eine der Kerne ist in der Lage zum Ausführen des vektorfreundlichen Befehlsformats wie es hierin beschrieben ist.
  • Der Prozessor kann ein universeller Prozessor sein wie zum Beispiel ein Core i3, i5, i7 oder 2 Duo und Quad Xeon oder Itanium Prozessor sein, die von der Intel Corporation in Santa Clara, Kalifornien, verfügbar gemacht sind. Ebenso kann der Prozessor von einer anderen Firma sein. Der Prozessor kann ein spezieller Prozessor sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, Graphikprozessor, Koprozessor oder eingebetteter Prozessor oder ähnliches sein. Der Prozessor kann auf einen oder mehreren Chips implementiert sein. Der Prozessor 1700 kann Teil von und/oder implementiert sein auf einen oder mehreren Subtraten unter Nutzung einer Anzahl von Prozesstechnologien wie beispielsweise BiCMOS, CMOS oder NMOS.
  • Beispielhafte Computersystem und Prozessoren – Fig. 13–Fig. 15
  • 13 bis 15 zeigen beispielhafte Systeme, die geeignet sind zum Umfassen des Prozessors 1700, während die 88 ein beispielhaftes System auf einen Chip (SoC) ist, welches einen oder mehrere Kerne 1702 umfassen kann. Andere Systemausführungen und Konfigurationen sind ebenfalls bekannt für Laptops, Desktops, tragbare PCs, persönliche digitale Assistenten, Workstations, Server, Netzwerkgeräte, Netzwerkhubs, Schalter, eingebettete Prozessoren, digitale Signalprozessoren (DSP), Graphikgeräte, Videospielgeräte, Settopboxen, Mikrocontroller, mobile Telefone, mobile Mediaplayer, tragbare Geräte, unterschiedliche Arten von elektronischen Geräten sind ebenfalls geeignet. Im Allgemeinen ist eine große Vielfalt von Systemen oder elektronischen Geräten verfügbar zum Einbeziehen eines Prozessors und/oder andere Ausführunglogikschaltungen wie sie hierin offenbart sind und allgemein geeignet sind.
  • Die 13 zeigt ein Blockdiagramm eines Systems 1300 entsprechend einem Ausführungsbeispiel der Erfindung. Das System 1300 kann einen oder mehrere Prozessoren 1310, 1315 umfassen, die an einen graphischen Memorycontrollerhub (GMCH) 1320 koppeln. Die optionalen Eigenschaften von zusätzlichen Prozessoren 1315 sind in der 13 durch unterbrochene Linien dargestellt.
  • Jeder Prozessor 1301, 1315 kann eine Version des Prozessors 1700 sein. Es sollte jedoch festgehalten werden, dass es unwahrscheinlich ist, dass integrierte Graphiklogikschaltungen und integrierte Speichercontrolleinheiten in den Prozessoren 1310, 1315 existieren würden.
  • 13 zeigt, dass die GMCH 1320 an einen Speicher 1340 koppeln kann, der zum Beispiel ein dynamischer Zufallszugriffspeicher (DRAM) ist. Der DRAM kann zumindest in einem Ausführungsbeispiel mit einem nicht-volatilen Cache verknüpft sein.
  • Der GMCH 1320 kann ein Chipsatz oder ein Teil eines Chipsatzes sein. Der GMCH 1320 kann mit den Prozessor(en) 1310, 1315 kommunizieren und die Wechselwirkung zwischen dem/die Prozessor(en) 1310, 1315 und Speicher 1340 steuern. Der GMCH 1320 kann ebenfalls als eine beschleunigte Busschnittstelle zwischen den/dem Prozessor(en) 1310, 1315 oder anderen Elementen des Systems 1300 agieren. In zumindest einem Ausführungsbeispiel kommuniziert der GMCH 1320 mit dem/den Prozessor(en) 1310, 1315 über einen Multi-Drop-Bus wie beispielsweise einen Frontbus (FSB) 1395.
  • Außerdem ist der GMCH 1320 an eine Anzeige 1345 gekoppelt (wie beispielsweise einen Flatpaneldisplay). Der GMCH 1320 kann einen integrierten Graphikbeschleuniger umfassen. Der GMCH 1320 kann weiter an einen Input/Output (I/O) Controllerhub (ICH) 1350 koppeln, welcher benutzt werden kann, um unterschiedliche Peripheriegeräte an das System 1300 zu koppeln. In dem beispielhaften Ausführungsbeispiel der 13 ist ein externes Graphikgerät 1360 gezeigt, welches ein diskretes Graphikgerät, das an das ICH 1350 koppelt, sein kann, zusammen mit anderen Peripheriegräten 1370.
  • Alternativ können zusätzliche oder andere Prozessoren ebenfalls in dem System 1300 vorhanden sein. Zum Beispiel kann/können (ein) zusätzliche(r) Prozessor(en) 1315 folgendes umfassen: zusätzliche Prozessor(en), die gleich sind zu dem Prozessor 1310, zusätzliche(n) Prozessore(n), die heterogen oder asymetrisch zu dem Prozessor 1310 sind, Beschleuniger (wie beispielsweise Graphikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP)), feldprogrammierbare Gatearrays oder andere Prozessoren sein. Es kann eine Vielzahl von Unterschieden zwischen den physischen Ressourcen 1310, 1315 geben in Bezug auf das Spektrum der Metriken des Nutzens einschließlich in Bezug auf die Architektur, Mikroarchitektur, thermischen, Leistungsverbrauchscharakteristiken oder ähnliches. Diese Unterschiede können effektiv sich manifestieren als Asymmetrie und Heterogenität unter den Verarbeitungselementen 1310, 1315. Für zumindest ein Ausführungsbeispiel können die unterschiedlichen Verarbeitungselemente 1310, 1315 in einem gleichen Chippaket vorhanden sein.
  • In der 14 ist ein Blockdiagramm eines zweiten Systems 1400 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung gezeigt. Wie in der 14 gezeigt ist, ist das Multiprozessorsystem 1400 ein Punkt-zu-Punkt-Verbindungssystem und umfasst einen ersten Prozessor 1470 und einen zweiten Prozessor 1480, die über eine Punkt-zu-Punkt-Verbindung 1450 miteinander koppeln. Wie in der 14 gezeigt, kann jeder der Prozessoren 1470 und 1480 eine Version des Prozessors 1700 sein.
  • Alternativ kann einer oder mehrere Prozessoren 1470, 1480 ein von einem Prozessor unterschiedliches Element sein wie beispielsweise ein Beschleuniger oder ein feldprogrammierbares Gatearray.
  • Während es nur mit zwei Prozessoren 1470, 1480 gezeigt ist, sollte klar sein, dass der Schutzbereich der vorliegenden Erfindung darauf nicht beschränkt ist. In anderen Ausführungsbeispielen können eine oder mehrere zusätzliche Verarbeitungselemente in einem gegebenen Prozessor vorhanden sein.
  • Der Prozessor 1470 kann weiter einen integrierten Speichercontrollerhub (IMC) 1472 und Punkt-zu-Punkt (P-P) Schnittstellen 1476 und 1478 umfassen. In ähnlicher Weise kann der zweite Prozessor 1480 einen IMC 1482 und P-P Schnittstellen 1486 und 1488 umfassen. Die Prozessoren 1470, 1480 können Daten über eine Punkt-zu-Punkt (PtP) Schnittstelle 1450 unter Nutzung einer PtP Schnittstellenschaltung 1478, 1488 austauschen. Wie in der 14 gezeigt ist, koppeln die IMCs 1472 und 1482 die Prozessoren an entsprechenden Speicher, nämlich einen Speicher 1442 und einen Speicher 1444, die Teile eines Hauptspeichers, der lokal an den entsprechenden Prozessoren angebracht ist, sein können.
  • Die Prozessoren 1470, 1480 können Daten mit einem Chipsatz 1490 über individuelle P-P Schnittstellen 1452, 1454 unter Nutzung der Punkt-zu-Punkt Schnittstellenschaltungen 1476, 1494, 1486, 1498 austauschen. Der Chipsatz 1490 kann Daten mit einer Hoch-Performancegraphikschaltung 1438 über eine Hochperformancegraphikschnittstelle 1439 austauschen.
  • Der gemeinsame Cache (nicht gezeigt) kann in jedem Prozessor außerhalb der beiden Prozessoren umfasst sein, und ist doch verbunden mit den Prozessoren über die P-P Verbindung, sodass jeder von den beiden Prozessoren lokale Cacheinformationen in dem gemeinsamen Cache speichern kann, wenn ein Prozessor in einen Niedrigleistungsmodus gesetzt ist.
  • Der Chipsatz 1490 kann an einen ersten Bus 1416 über eine Schnittstelle 1496 koppeln. In einem Ausführungsbeispiel kann der erste Bus 1416 ein peripherer Komponenten-Verbindungs-(PCI)Bus sein oder ein Bus wie beispielsweise ein PCI Expressbus oder ein anderer Verbindungsbus dritter Generation (I/O), obwohl der Schutzbereich der gegenwärtigen Erfindung darauf nicht beschränkt ist.
  • Wie in der 14 gezeigt, können unterschiedliche I/O Geräte 1414 an den ersten Bus 1416 zusammen mit einer Busbrücke 1418 koppeln, die den ersten Bus 1416 an einen zweiten Bus 1420 koppelt. In einem Ausführungsbeispiel kann der zweite Bus 1420 ein Low-Pin-Count (LPC) Bus sein. Unterschiedliche Geräte können an den zweiten Bus 1420 koppeln einschließlich, zum Beispiel, eine Tastatur/Maus 1422, Kommunikationsgeräte 1426 und eine Datenspeichereinheit 1428 wie ein Laufwerk oder ein anderes Massenspeichergerät, das einen Code 1430 umfassen kann in einem Ausführungsbeispiel. Weiterhin kann ein Audio I/O 1424 an den zweiten Bus 1420 koppeln. Es sei angemerkt, dass andere Architekturen ebenfalls möglich sind. Zum Beispiel kann, anstatt der Punkt-zu-Punkt Architektur der 14, ein System ein Multi-Drop-Bus implementieren oder eine andere Architektur.
  • In Bezug auf die 15 ist ein Blockdiagramm eines dritten Systems 1500 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung gezeigt. Ähnliche Elemente tragen in der 14 und 15 ähnliche Bezugszeichen, bestimmte Aspekte der 14 werden in der 15 vermieden, um zu vermeiden, dass andere Aspekte in der 15 verdeckt werden.
  • Die 15 zeigt, dass die Verarbeitungselemente 1470, 1480 einen integrierten Speicher und I/O Controllogikschaltung („CL”) 1472 und 1482 entsprechend aufweisen können. Für zumindest ein Ausführungsbeispiel können die CL 1472, 1482 eine Speichercontrolhubschaltung (IMC) aufweisen wie jene, die zuvor in Verbindung mit den 8, 9 und 14 beschrieben wurden. Zusätzlich können die CL 1472, 1482 ebenfalls I/O Controllogikschaltungen umfassen. Die 15 zeigt, dass nicht nur die Speicher 1442, 1444 an die CL 1472, 1482 koppeln, sondern dass ebenfalls die I/O Geräte 1514 an die Logikschaltung 1472, 1482 gekoppelt sind. Vorgänger I/O Geräte 1515 sind an den Chipsatz 1490 gekoppelt.
  • Bezugnehmend jetzt auf die 16, ist ein Blockdiagramm eines SoC 1600 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung gezeigt. Ähnliche Elemente in der 17 tragen ähnliche Bezugszeichen. Ebenso kennzeichnen unterbrochene Linienboxen optionale Merkmale in fortgeschrittenen SoCs. In der 16 ist/sind (eine) Verbindungseinheit(en) 1602 gekoppelt an: einen Anwendungsprozessor 1610, der einen Satz von einem oder mehreren Kernen 1702A–N und gemeinsame Cacheeinheit(en) 1706 umfasst, eine Systemagenteneinheit 1710, (eine) Buscontrollereinheit 1716; (einen) integrierte Speichercontrollereinheit(en) 1714; einen Satz oder einen oder mehreren Medienprozessoren 1620, die eine integrierte Graphiklogikschaltung 1708 umfassen können, einen Bildprozessor 1624 zum Bereitstellen eines ruhenden und/oder einer Videokamerafunktionalität, einen Audioprozessor 1626 zum Bereitstellen von Hardwareaudiobeschleunigungen, und einen Videoprozessor 1628 zum Bereitstellen von Videokodierungen/Dekodierungsbeschleunigungen; eine statische Zufallszugriffsspeicher-(SRAM)Einheit 1630, eine Direktspeicherzugriffs (DMA) Einheit 1632; einer Anzeigeeinheit 1640 zum Koppeln an die einen oder mehreren externen Anzeigen.
  • Ausführungsbeispiele des Mechanismus, der hierin offenbart ist, können ebenfalls in Hardware, Software, Firmware oder Kombinationen von diesen Implementierungen umgesetzt sein. Ausführungsbeispiele der Erfindung können ebenfalls als Computerprogramme, Programmcode, der auf programmbierbaren Systemen ausgeführt wird mit zumindest einem Prozessor, Speichersystem (mit volatilen und nicht-volatilen Speicher und/oder Speicherelementen), zumindest einem Eingabegerät und zumindest einem Ausgabegerät ausgeführt werden.
  • Der Programmcode kann auf Eingabedaten angewandt werden, um die Funktionen, die hierin beschrieben sind, auszuführen und um Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können angewendet werden auf einen oder mehreren bekannte Ausgabegeräten. Für den Zweck dieser Anmeldung umfasst ein Verarbeitungssystem jedes System, welches ein Prozessor wie zum Beispiel einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC), oder einen Mikroprozessor umfasst.
  • Der Programmcode kann in einem höheren Niveauprozess oder einen objektorientierten Programmiersprache implementiert sein, um mit einem Prozessorsystem zu kommunizieren. Der Programmcode kann ebenso in Assembly oder Maschinensprache, wenn gewünscht implementiert sein. In der Tat sind die Mechanismen, die hierin beschrieben sind, nicht begrenzt auf den Umfang von einer bestimmten Programmiersprache. In jedem Fall kann die Sprache eine kompilierte oder eine interpretierte Sprache sein.
  • Einer oder mehrere Aspekte von zumindest einem Ausführungsbeispiel können durch Instruktionen dargestellt werden, die auf maschinenlesbaren Medien gespeichert sind, welche unterschiedliche Logikschaltungen innerhalb eines Prozessors darstellen, die, wenn sie durch eine Maschine gelesen werden, die Maschine dazu veranlassen, die Logik zu erzeugen und die Techniken, wie sie hierin beschrieben sind, auszuführen. Solche Darstellungen sind auch bekannt als „IP Kerne” und können auf einem greifbaren, maschinenlesbaren Medium gespeichert werden und an verschiedene Kunden oder Herstellungseinrichtungen weitergegeben werden, um in die Herstellungsmaschinen geladen zu werden, die die Logiken oder Prozessoren erzeugen.
  • Solche maschinenlesbaren Speichermedien können ohne Begrenzung nicht-transitorische, greifbare Anordnungen von Artikeln sein, die hergestellt werden oder gebildet werden durch eine Maschine oder ein Gerät, einschließlich Speichermedien, wie Harddisks, jede Form von Disks einschließlich Disketten, optische Disks (kompakte Nur-Lese Speicherdisks (CD-ROM), kompakte Disk Wiederbeschreibbar (CD-RWs)) und magnetoptische Disks, Halbleitergeräte wie zum Beispiel Nur-Lese Speicher (ROMs), Zufall-Zugriff-Speicher (RAMs), wie dynamische Random Access Memories (DRAMs), statische Random Access Memories (SRAMs), löschbare programmierbare Nur-Lese Speicher (EPROMs), Flash Memories, elektrisch löschbare programmierbare Nur-Lese Speicher (EEPROMs), magnetische oder optische Karten oder jeder andere Typ von Medien, die geeignet sind zum Speichern von elektronischen Befehlen.
  • Dementsprechend umfassen Ausführungsbeispiele der Erfindung ebenso nicht-transitorische, greifbare maschinenlesbare Medien, die Instruktionen des vektorfreundlichen Datenformats aufweisen oder Ausführungsdaten aufweisen wie die Hardware-Beschreibungssprache (HDL), die Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale, die darin beschrieben sind, definieren. Solche Ausführungsbeispiele können auch als Programmprodukte bezeichnet werden.
  • In einigen Fällen kann ein Befehlskonverter genutzt werden zum Umwandeln von einem Befehl von einem Quellbefehlsatz in einen Zielbefehlssatz. Zum Beispiel können Befehlskonverter folgendes übersetzen (zum Beispiel unter Nutzung von statischer Binärübersetzung, dynamischer Binärübersetzung einschließlich dynamischer Kompilation) von Morph, Emulator oder anderen Konvertierungen eines Befehls zu einer oder mehreren anderen Befehlen, die durch den Kern auszuführen sind. Der Befehlskonverter kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Der Befehlskonverter kann auf dem Prozessor, außerhalb des Prozessors oder teilweise auf und teilweise außerhalb des Prozessors sein.
  • 18 ist ein Blockdiagramm, welches die Verwendung eines Softwarebefehlskonverter zum Konvertieren von Binärbefehlen in einem Quellbefehlssatz zu Binärbefehlen in einen Zielbefehlssatz entsprechend zu Ausführungsbeispielen der vorliegenden Erfindung herausstellt. In dem gezeigten Ausführungsbeispiel ist der Befehlskonverter ein Softwarebefehlskonverter, obwohl alternativ der Befehlskonverter auch in Software, Firmware, Hardware oder anderen Kombination daraus implementiert sein kann. 18 zeigt ein Programm in einer höheren Sprache 1802, die unter Nutzung eines x86 Compilers 1804 kombiniert werden kann, um ein x86 Binärcode 1806 zu erzeugen, welcher nativ auf einem Prozessor mit zumindest einer x86 Befehlssatzkern 1816 ausführbar ist (es wird angenommen, dass einige der Befehle, die kompiliert wurden, in dem vektorfreundlichen Befehlsformat sind). Der Prozessor mit zumindest einem x86 Befehlssatzkern 1816 stellt jeden Prozessor dar, der im Wesentlichen die gleichen Funktionen wie ein Intel Prozessor mit zumindest einem x86 Befehlssatz kompatibel ausführen kann oder anders folgendes verarbeiten kann (1) einen wesentlichen Anteil des Befehlssatzes eines Intel x86 Befehlssatzkernes oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, die darauf ausgerichtet sind auf einen Intel Prozessor mit zumindest einen x86 Befehlssatzkern zu laufen, um im Wesentlichen das gleiche Resultat zu erzielen wie mit einem Intel Prozessor mit zumindest einem x86 Befehlssatzkern. Der x86 Compiler 1804 stellt einen Compiler dar, der betreibbar ist, um einen x86 Binärcode 1806 zu erzeugen (zum Beispiel Objektcode), der mit oder ohne zusätzlichen Verbindungsprozessierungen ausgeführt werden kann auf einem Prozessor mit zumindest einem x86 Befehlssatzkern 1816. In ähnlicher Weise zeigt 90 das Programm in einer höheren Sprache 1802, welche unter Nutzung eines alternativen Befehlssatzcompilers 1808 kompiliert sein kann, um einen alternativen Befehlssatz Binärcode 1810 zu erzeugen, welcher nativ auf einen Prozessor ohne zumindest einen x86 Befehlssatzkern 1814 ausgeführt werden kann (zum Beispiel ein Prozessor mit Kernen, die den MIPS Befehlssatz der MIPS Technologies of Sunnyvale, CA und/oder die den ARM Befehlssatz der ARM Holdings of Sunnyvale, CA ausführt). Der Befehlskonverter 1812 wird genutzt zum Konvertieren der x86 Binärcodes 1806 in einen Code, der nativ auf einen Prozessor ohne einen x86 Befehlssatzkern 1814 ausgeführt werden kann. Dieser konvertierte Code ist wahrscheinlich nicht der gleiche wie der alternative Befehlssatzbinärcode 1810, weil ein Befehlskonverter, der dazu kompatibel ist, schwer herzustellen ist; jedoch wird der konvertierte Code die allgemeine Operation erreichen und aufgebaut sein durch Befehle des alternativen Befehlssatzes. Daher stellt der Befehlskonverter 1812 Software, Firmware, Hardware oder Kombinationen daraus dar, über Emulation, Simulation oder anderen Prozessen, die erlauben einen Prozessor oder anderen elektronischen Geräten, die keinen x86 Befehlssatz Prozessor haben oder einen Kern zum Ausführen von dem x86 Binärcode 1806 haben.
  • Bestimmte Operationen der Befehle in dem vektorfreundlichen Befehlsformat, welches hierin offenbart ist, können durch Hardwarekomponenten ausgeführt werden, und können in maschinenlesbaren Befehlen dargestellt sein, die genutzt werden, um zu bewirken oder zumindest darin zu resultieren, dass eine Schaltung oder andere Hardwarekomponente mit den Befehlen, die die Operationen ausführen, programmiert werden. Die Schaltung kann einen universellen oder speziellen Prozessor umfassen, oder eine Logikschaltung, um nur einige Beispiele zu nennen. Die Operationen können optional ausgeführt werden durch eine Kombination von Hardware und Software.
  • Die Ausführungslogikschaltung und/oder ein Prozessorkern können spezifische oder bestimmte Schaltungen oder andere Logikschaltungen umfassen, die auf einen Maschinenbefehl oder auf einen oder mehrere Steuersignale reagieren, die von Maschinenbefehlen verursacht werden, um Befehle zu speichern, die in den Resultatoperanden spezifiziert sind. Zum Beispiel können Ausführungsbeispiele der/des Befehl(e/s), die hierin offenbart sind, auf einen oder mehreren Systeme der 13 bis 16 ausgeführt werden und Ausführungsbeispiele der/des Befehl(e/s) in dem vektorfreundlichen Befehlsformat können in Programmcode, welches auf den Systemen auszuführen sind, gespeichert sein. Zusätzlich können Verarbeitungselemente dieser Figuren eine der detaillierten Pipelines und/oder Architekturen nutzen, wie sie hierin beschrieben sind (zum Beispiel die In-Fester-Ordnung oder In-Anderer-Ordnung Architekturen). Zum Beispiel kann Dekodereinheit der In-Fester-Ordnung Architektur Befehle dekodieren, die dekodierten Befehle an eine Vektor- oder Skalareinheit weitergeben und so weiter.
  • Die obige Beschreibung beabsichtigt bevorzugte Ausführungsbeispiele der vorliegenden Erfindung darzustellen. Von der Diskussion oben sollte es ebenfalls klar sein, dass insbesondere in solchen Gebieten der Technologie, wo das Wachstum schnell ist und weitere Fortschritte leicht vorhersehbar sind, die Erfindung in Bezug auf die Anordnung und die Details modifiziert werden kann durch einen Fachmann ohne von den Prinzipien der vorliegenden Erfindung innerhalb des Schutzumfanges des beiliegenden Ansprüche oder ihren Äquivalenten abzuweichen. Zum Beispiel kann eine oder mehrere Operationen eines Verfahrens kombiniert werden oder separiert werden.
  • Alternative Ausführungsbeispiele
  • Während Ausführungsbeispiele beschrieben wurden, die nativ das vektorfreundliche Befehlsformat ausführen, können alternative Ausführungsbeispiele das vektorfreundliche Befehlsformat über eine Emulationsschicht, die auf einen Prozessor abläuft, der einen unterschiedlichen Befehlssatz hat, ausgeführt werden, (zum Beispiel einen Prozessor, der MIPS Satz eines MIPS Technologien von Sunnyvale, CA, einem Prozessor der ARM Befehlssatz von ARM Holding of Sunnyvale, CA ausführt). Außerdem, während die Flussdiagramme in den Figuren eine bestimmte Ordnung von Operationen, die durchzuführen sind, durch bestimmte Ausführungsbeispiele der Erfindung zeigt, sollte verstanden werden, dass diese Ordnung nur beispielhaft zu verstehen ist (zum Beispiel können alternative Ausführungsbeispiele die Operationen in einer anderen Ordnung oder Reihenfolge ausführen, bestimmte Operationen miteinander kombinieren, bestimmte Operationen überlagern und so weiter).
  • Die obige Beschreibung dient dem Zweck der Darstellung verschiedener spezifischer Details, um ein klares Verständnis für die Ausführungsbeispiele der Erfindung zu liefern. Es ist jedoch offensichtlich, dass ein Fachmann ein oder mehrere Ausführungsbeispiele ohne diese spezifischen Details umsetzen kann. Bestimmte Ausführungsbeispiele, die beschrieben wurden, sind nicht beschränkt auf die Erfindung, sondern stellen lediglich Ausführungen der Erfindung dar. Der Umfang der Erfindung ist nicht bestimmt durch die spezifischen Beispiele, wie sie oben angegeben sind, sondern allein durch die folgenden Ansprüche.
  • MIPS Satz eines MIPS Technologien von Sunnyvale, CA, einem Prozessor der ARM Befehlssatz von ARM Holding of Sunnyvale, CA ausführt). Außerdem, während die Flussdiagramme in den Figuren eine bestimmte Ordnung von Operationen, die durchzuführen sind, durch bestimmte Ausführungsbeispiele der Erfindung zeigt, sollte verstanden werden, dass diese Ordnung nur beispielhaft zu verstehen ist (zum Beispiel können alternative Ausführungsbeispiele die Operationen in einer anderen Ordnung oder Reihenfolge ausführen, bestimmte Operationen miteinander kombinieren, bestimmte Operationen überlagern und so weiter).
  • Die obige Beschreibung dient dem Zweck der Darstellung verschiedener spezifischer Details, um ein klares Verständnis für die Ausführungsbeispiele der Erfindung zu liefern. Es ist jedoch offensichtlich, dass ein Fachmann ein oder mehrere Ausführungsbeispiele ohne diese spezifischen Details umsetzen kann. Bestimmte Ausführungsbeispiele, die beschrieben wurden, sind nicht beschränkt auf die Erfindung, sondern stellen lediglich Ausführungen der Erfindung dar. Der Umfang der Erfindung ist nicht bestimmt durch die spezifischen Beispiele, wie sie oben angegeben sind, sondern allein durch die folgenden Ansprüche.

Claims (19)

  1. Verfahren zum Ausführen eines Ausrichtungsbefehls in einem Computerprozessor mit: Abholen des Ausrichtungsbefehls, wobei der Ausrichtungsbefehl einen Schreibmaskenoperanden, einen Zieloperanden, einen ersten Quelloperanden, einen zweiten Quelloperanden und einen Versatzwert umfasst; Dekodieren des abgerufenen Ausrichtungsbefehls; Ausführen des dekodierten Ausrichtungsbefehls durch Verknüpfen einer ersten Vielzahl von Datenelementen des ersten Quelloperanden und einer zweiten Vielzahl von Datenelementen des zweiten Quelloperanden, Nach-Rechts-Verschieben der verknüpften Datenelemente basierend auf dem Versatzwert, und Bestimmen welche der nach rechts verschobenen, verknüpften Datenelemente in einer entsprechenden Position des Zieles basierend auf entsprechenden Bits der Schreibmaske zu speichern sind; und Abspeichern jener Datenelemente der nach rechts verschobenen, verknüpften Datenelemente, die bestimmt wurden, um in dem Ziel an der entsprechenden Position in dem Ziel gespeichert zu werden.
  2. Verfahren nach Anspruch 1, wobei die Schreibmaske ein 16-Bit-Register ist.
  3. Verfahren nach Anspruch 1, wobei der Versatz ein 8-Bit-Direktwert ist.
  4. Verfahren nach Anspruch 1, welches weiter umfasst: Bestimmen, ob die Schreibmaske zu verwenden ist; und wenn die Schreibemaske zu verwenden ist, Speichern der Datenelemente der nach rechts verschobenen, miteinander verknüpften Datenelemente an den entsprechenden Positionen des Zieles ohne zu bestimmen, welche der nach rechts verschobenen, miteinander verknüpften Datenelemente in der entsprechenden Position des Zieles basierend auf entsprechenden Bits der Schreibemaske zu speichern sind.
  5. Verfahren nach Anspruch 1, wobei das Bestimmen für jede Bit-Position der Schreibmaske parallel ausgeführt wird.
  6. Verfahren nach Anspruch 1, wobei der erste und zweite Quelloperand ein 512-Bit-Register sind.
  7. Verfahren nach Anspruch 1, wobei der zweite Quelloperand ein 512-Bit-Speicherort und die Datenelemente von dem Speicherort in ein temporäres 512-Bit-Register vor dem Aneinanderknüpfen der Quellen gespeichert werden.
  8. Verfahren nach Anspruch 1, wobei die Datenelemente des ersten Operanden die Datenelemente der geringsten Signifikanz der nach rechts verschobenen, miteinander verknüpften Datenelemente sind.
  9. Verfahren mit: in Antwort auf einen Ausrichtungsbefehl, der einen ersten und zweiten Quelloperanden, einen Zieloperanden, einen Schreibmaskenoperanden und einen Versatz umfasst, miteinander Verknüpfen eines ersten Satzes von Datenelementen der ersten Quelle mit einem zweiten Satz von Datenelementen der zweiten Quelle; nach rechts Verschieben der verknüpften Datenelemente um X Datenelemente, wobei X ein Direktwert ist, der durch den Ausrichtungsbefehl bereitgestellt wird; und für eine erste Bit-Position einer Schreibmaske, Bestimmen, ob die erste Bit-Position anzeigt, dass das entsprechende Datenelement der verschobenen, miteinander verknüpften Datenelemente an einem entsprechenden Ort des Zieles zu speichern ist, Speichern des entsprechenden Datenelementes der verschobenen, miteinander verknüpften Datenelemente an einem entsprechenden Ort in dem Ziel, wenn die erste Bit-Position der Schreibmaske andeutet, dass es gespeichert werden soll, und Unverändert Lassen eines Datenelementes in dem entsprechenden Ort des Zieles, wenn die erste Bit-Position der Schreibmaske andeutet, dass das entsprechende Datenelement nicht in dem Ziel gespeichert werden soll.
  10. Verfahren nach Anspruch 9, welches weiter folgendes umfasst: Miteinander Verknüpfen eines ersten Satzes von Datenelementen der ersten Quelle mit einem zweiten Satz von Datenelementen der zweiten Quelle; für eine zweite Bit-Position einer Schreibmaske, Bestimmen, ob die zweite Bit-Position andeutet, dass das entsprechende Datenelement der verschobenen, miteinander verknüpften Datenelemente an einem entsprechenden Ort in dem Ziel zu speichern ist, Speichern des entsprechenden Datenelementes der verschobenen, miteinander verknüpften Datenelemente an einem entsprechenden Ort in dem Ziel, wenn die zweite Bit-Position der Schreibmaske andeutet, dass es zu speichern ist, und ein Datenelement in dem entsprechenden Ort in dem Ziel unverändert lassen, wenn die zweite Bit-Position der Schreibmaske andeutet, dass ihr entsprechendes Datenelement nicht im Ziel zu speichern ist.
  11. Verfahren nach Anspruch 10, welches weiter folgendes umfasst: Bestimmen, wenn die letzte Bit-Position bewertet wurde, ob ihr entsprechendes Datenelement der verschobenen, miteinander verknüpften Datenelemente an einem entsprechenden Ort in dem Ziel zu speichern ist, um den Ausrichtungsbefehl abzuschließen.
  12. Verfahren nach Anspruch 9, wobei die erste Bit-Position der Schreibmaske das Bit der niedrigsten Signifikanz der Schreibmaske ist.
  13. Verfahren nach Anspruch 9, wobei die Schreibmaske ein 16-Bit Register ist.
  14. Verfahren nach Anspruch 9, wobei der Versatz ein 8-Bit Direktwert ist.
  15. Verfahren nach Anspruch 9, wobei das Bestimmen für jede Bit-Position der Schreibmaske parallel ausgeführt wird.
  16. Verfahren nach Anspruch 1, wobei der erste und zweite Quelloperand 512-Bit-Register sind.
  17. Verfahren nach Anspruch 1, wobei der zweite Quelloperand ein 512-Bit-Speicherort ist und die Datenelemente von dem Speicherort in einem temporären 512-Bit Register vor dem miteinander Verknüpfen der Quellen geladen werden.
  18. Vorrichtung mit: einem Hardwaredecoder, um einen Ausrichtbefehl zu dekodieren, wobei der Ausrichtbefehl folgendes umfasst: einen Schreibmaskenoperanden, einen Zieloperanden, einen ersten Quelloperanden, einen zweiten Quelloperanden und einen Versatzwert; eine Ausführungslogik, um mehrere erste Datenelemente des ersten Quelloperanden und mehrere zweite Datenelemente eines zweiten Quelloperanden miteinander zu verknüpfen, nach rechts Verschieben der verknüpften Datenelemente basierend auf dem Versatzwert, Bestimmen, welche von den nach rechts verschobenen miteinander verknüpften Datenelementen in entsprechenden Positionen des Zieles zu speichern sind, und zwar basierend auf entsprechenden Bits der Schreibmaske, und Speichern der Datenelemente der nach rechts verschobenen miteinander verknüpften Datenelemente, die bestimmt wurden, dass sie in dem Ziel an der entsprechenden Position in dem Ziel zu speichern sind.
  19. Vorrichtung nach Anspruch 18, welcher weiter folgendes umfasst: ein 16-Bit Schreibmasken-Register, um die Schreibmaske zu speichern; und zumindest zwei 512-Bit Register, um die Datenelemente der ersten und zweiten Quelle zu speichern.
DE112012001542.8T 2011-04-01 2012-03-29 System, Vorrichtung und Verfahren zum Ausrichten von Registern Withdrawn DE112012001542T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
USUS-13/078,868 2011-04-01
US13/078,868 US20120254589A1 (en) 2011-04-01 2011-04-01 System, apparatus, and method for aligning registers
PCT/US2012/031202 WO2012135494A2 (en) 2011-04-01 2012-03-29 System, apparatus, and method for aligning registers

Publications (1)

Publication Number Publication Date
DE112012001542T5 true DE112012001542T5 (de) 2014-02-20

Family

ID=46928899

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112012001542.8T Withdrawn DE112012001542T5 (de) 2011-04-01 2012-03-29 System, Vorrichtung und Verfahren zum Ausrichten von Registern

Country Status (7)

Country Link
US (1) US20120254589A1 (de)
JP (1) JP5764257B2 (de)
KR (2) KR101926241B1 (de)
CN (2) CN107273095B (de)
DE (1) DE112012001542T5 (de)
GB (1) GB2504226B (de)
WO (1) WO2012135494A2 (de)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2943248T3 (es) 2011-04-01 2023-06-12 Intel Corp Formato de instrucción compatible con vectores y ejecución del mismo
US20130027416A1 (en) * 2011-07-25 2013-01-31 Karthikeyan Vaithianathan Gather method and apparatus for media processing accelerators
US10209986B2 (en) * 2011-12-22 2019-02-19 Intel Corporation Floating point rounding processors, methods, systems, and instructions
CN104011670B (zh) 2011-12-22 2016-12-28 英特尔公司 用于基于向量写掩码的内容而在通用寄存器中存储两个标量常数之一的指令
US9606961B2 (en) 2012-10-30 2017-03-28 Intel Corporation Instruction and logic to provide vector compress and rotate functionality
US9632781B2 (en) * 2013-02-26 2017-04-25 Qualcomm Incorporated Vector register addressing and functions based on a scalar register data value
US9477467B2 (en) 2013-03-30 2016-10-25 Intel Corporation Processors, methods, and systems to implement partial register accesses with masked full register accesses
US11461096B2 (en) 2019-05-24 2022-10-04 Texas Instruments Incorporated Method and apparatus for vector sorting using vector permutation logic
US9606803B2 (en) 2013-07-15 2017-03-28 Texas Instruments Incorporated Highly integrated scalable, flexible DSP megamodule architecture
US9740888B1 (en) * 2014-02-07 2017-08-22 Seagate Technology Llc Tamper evident detection
US10133570B2 (en) * 2014-09-19 2018-11-20 Intel Corporation Processors, methods, systems, and instructions to select and consolidate active data elements in a register under mask into a least significant portion of result, and to indicate a number of data elements consolidated
US20160179550A1 (en) * 2014-12-23 2016-06-23 Intel Corporation Fast vector dynamic memory conflict detection
US9971686B2 (en) * 2015-02-23 2018-05-15 Intel Corporation Vector cache line write back processors, methods, systems, and instructions
JP6492943B2 (ja) 2015-05-07 2019-04-03 富士通株式会社 計算機、コンパイル方法、コンパイルプログラム、およびパイプライン処理プログラム
US10001995B2 (en) 2015-06-02 2018-06-19 Intel Corporation Packed data alignment plus compute instructions, processors, methods, and systems
GB2540939B (en) * 2015-07-31 2019-01-23 Advanced Risc Mach Ltd An apparatus and method for performing a splice operation
WO2020066375A1 (ja) * 2018-09-25 2020-04-02 日本電気株式会社 情報処理装置、情報処理方法、プログラム
CN110688330B (zh) * 2019-09-23 2021-08-31 北京航空航天大学 一种基于内存映射相邻性的虚拟内存地址翻译方法
TWI762908B (zh) * 2020-04-17 2022-05-01 新唐科技股份有限公司 串接式擴增裝置及包含其之串接式系統

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4873630A (en) * 1985-07-31 1989-10-10 Unisys Corporation Scientific processor to support a host processor referencing common memory
US4789925A (en) * 1985-07-31 1988-12-06 Unisys Corporation Vector data logical usage conflict detection
US4949250A (en) * 1988-03-18 1990-08-14 Digital Equipment Corporation Method and apparatus for executing instructions for a vector processing system
JPH01319863A (ja) * 1988-06-21 1989-12-26 Nec Corp ベクトルマスク制御方式
EP1265132A3 (de) * 1994-12-02 2005-02-09 Intel Corporation Mikroprozessor mit Packfunktion für zusammengesetzte Operanden
JP2806346B2 (ja) * 1996-01-22 1998-09-30 日本電気株式会社 演算処理装置
US6535903B2 (en) * 1996-01-29 2003-03-18 Compaq Information Technologies Group, L.P. Method and apparatus for maintaining translated routine stack in a binary translation environment
US5983344A (en) * 1997-03-19 1999-11-09 Integrated Device Technology, Inc. Combining ALU and memory storage micro instructions by using an address latch to maintain an address calculated by a first micro instruction
US5933650A (en) * 1997-10-09 1999-08-03 Mips Technologies, Inc. Alignment and ordering of vector elements for single instruction multiple data processing
US6223277B1 (en) * 1997-11-21 2001-04-24 Texas Instruments Incorporated Data processing circuit with packed data structure capability
US6745318B1 (en) * 1999-08-18 2004-06-01 Sanjay Mansingh Method and apparatus of configurable processing
US6807622B1 (en) * 2000-08-09 2004-10-19 Advanced Micro Devices, Inc. Processor which overrides default operand size for implicit stack pointer references and near branches
JP3776732B2 (ja) * 2001-02-02 2006-05-17 株式会社東芝 プロセッサ装置
US7340495B2 (en) * 2001-10-29 2008-03-04 Intel Corporation Superior misaligned memory load and copy using merge hardware
US7685212B2 (en) * 2001-10-29 2010-03-23 Intel Corporation Fast full search motion estimation with SIMD merge instruction
US7349934B2 (en) * 2002-12-20 2008-03-25 Texas Instruments Incorporated Processor system and method with combined data left and right shift operation
CN100338571C (zh) * 2003-09-27 2007-09-19 英特尔公司 处理器的扩展寄存器空间装置和方法
GB2411974C (en) * 2003-12-09 2009-09-23 Advanced Risc Mach Ltd Data shift operations
GB2411975B (en) * 2003-12-09 2006-10-04 Advanced Risc Mach Ltd Data processing apparatus and method for performing arithmetic operations in SIMD data processing
US7339592B2 (en) * 2004-07-13 2008-03-04 Nvidia Corporation Simulating multiported memories using lower port count memories
US8127117B2 (en) * 2006-05-10 2012-02-28 Qualcomm Incorporated Method and system to combine corresponding half word units from multiple register units within a microprocessor
US7761694B2 (en) * 2006-06-30 2010-07-20 Intel Corporation Execution unit for performing shuffle and other operations
US8156310B2 (en) * 2006-09-11 2012-04-10 International Business Machines Corporation Method and apparatus for data stream alignment support
GB0619380D0 (en) * 2006-10-02 2006-11-08 Transitive Ltd Method and apparatus for program code conversion from a register window based subject computing architecture
US8667250B2 (en) * 2007-12-26 2014-03-04 Intel Corporation Methods, apparatus, and instructions for converting vector data
CN101930356B (zh) * 2010-08-24 2013-03-20 中国航天科技集团公司第九研究院第七七一研究所 用于浮点协处理器的寄存器文件分组编址、读写控制方法
US8788794B2 (en) * 2010-12-07 2014-07-22 Advanced Micro Devices, Inc. Programmable atomic memory using stored atomic procedures

Also Published As

Publication number Publication date
KR20130137697A (ko) 2013-12-17
WO2012135494A3 (en) 2012-12-27
KR101926241B1 (ko) 2018-12-06
KR20160014100A (ko) 2016-02-05
JP5764257B2 (ja) 2015-08-19
US20120254589A1 (en) 2012-10-04
GB2504226B (en) 2020-01-29
CN103562854B (zh) 2017-07-14
JP2014510352A (ja) 2014-04-24
WO2012135494A2 (en) 2012-10-04
GB2504226A (en) 2014-01-22
CN107273095A (zh) 2017-10-20
CN103562854A (zh) 2014-02-05
GB201317942D0 (en) 2013-11-27
KR101592079B1 (ko) 2016-02-04
CN107273095B (zh) 2020-12-29

Similar Documents

Publication Publication Date Title
DE112012001542T5 (de) System, Vorrichtung und Verfahren zum Ausrichten von Registern
DE112012007063B4 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE102018005977A1 (de) Gleitkomma- zu festkomma-umwandlung
DE112013005188B4 (de) Prozessor und vefrahren zur vektorisierung von zusammengeführten, mehrfach geschachtelten schleifen
DE112011105121T5 (de) Systeme, Vorrichtungen und Verfahren zum Schrittmustersammeln von Datenelementen und Schrittmusterstreuen von Datenelementen
DE112011105122T5 (de) Systeme, Vorrichtungen und Verfahren zum Vermischen zweier Quelloperanden in einem einzigen Ziel unter Verwendung einer Schreibmaske
DE112017001804T5 (de) Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand
DE102018124945A1 (de) Einrichtung und verfahren für komplexe multiplikation
DE112013005236T5 (de) Verfahren und Vorrichtung für Integralbild-Berechnungsbefehle
DE112011105818T5 (de) Systeme, Vorrichtungen und Verfahren zum Expandieren einer Speicherquelle in ein Zielregister und komprimieren eines Quellenregisters in eine Zielspeicherstelle
DE102018125232A1 (de) Einrichtung und Verfahren für komplexe Multiplikation und Akkumulation
DE102018006757A1 (de) Festkomma-zu-gleitkomma-umwandlung
DE102014003706A1 (de) BEREICHSBEGRENZTE VEKTORSPEICHERZUGRIFFSINSTRUKTIONEN, PROZESSOREN, VERFAHREN und SYSTEME
DE102016006400A1 (de) Hardware-prozessoren und verfahren für eng-gekoppelte heterogene datenverarbeitung
DE112013005343T5 (de) Befehle für Codierungsalgorithemen mit gleitendem Fenster
DE112012007058T5 (de) Vektormaskengesteuertes Clock-Gating für Leistungseffizenz eines Prozessors
DE112014006508T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen für Fliesskommaaddition mit drei Quellenoperanden
DE102018125817A1 (de) Systeme und Verfahren zum Laden eines Kachelregisterpaars
DE102015007422A1 (de) Befehlssatz zum Eliminieren fehlausgerichteter Speicherzugriffe während der Verarbeitung eines Arrays mit fehlausgerichteten Datenzeilen
DE112012007119T5 (de) Threadmigration-Unterstützung für Kerne unterschiedlicher Architektur
DE112013004798T5 (de) Befehlssatz zur Nachrichtenplanung des SHA256-Algorithmus
DE102019109845A1 (de) Vereinheitlichte Beschleunigung eines Blockgeheimcodes eines symmetrischen Schlüssels für AES-SMS4-Camellia
DE112017003336T5 (de) Vorrichtungen, verfahren und systeme zum elementsortieren von vektoren
DE202019005682U1 (de) Hardwaregestützte Paging-Mechanismen
DE112019002389T5 (de) Architektur zur dynamischen umwandlung einer speicherkonfiguration

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee