DE112012007063B4 - Zusammenfügen von benachbarten Sammel-/Streuoperationen - Google Patents

Zusammenfügen von benachbarten Sammel-/Streuoperationen Download PDF

Info

Publication number
DE112012007063B4
DE112012007063B4 DE112012007063.1T DE112012007063T DE112012007063B4 DE 112012007063 B4 DE112012007063 B4 DE 112012007063B4 DE 112012007063 T DE112012007063 T DE 112012007063T DE 112012007063 B4 DE112012007063 B4 DE 112012007063B4
Authority
DE
Germany
Prior art keywords
instruction
memory
data
memory location
entry
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.)
Active
Application number
DE112012007063.1T
Other languages
English (en)
Other versions
DE112012007063T5 (de
Inventor
Andrew T. Forsyth
Brian J. Hickmann
Jonathan C. Hall
Christopher J. Hughes
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 DE112012007063T5 publication Critical patent/DE112012007063T5/de
Application granted granted Critical
Publication of DE112012007063B4 publication Critical patent/DE112012007063B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8007—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors single instruction multiple data [SIMD] multiprocessors
    • 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/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
    • G06F9/30038—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations using a mask
    • 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/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30043—LOAD or STORE instructions; Clear instruction
    • 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/30098—Register arrangements
    • 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/30098—Register arrangements
    • G06F9/30105—Register structure
    • 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/30145—Instruction analysis, e.g. decoding, instruction word fields
    • 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/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016—Decoding the operand specifier, e.g. specifier format
    • G06F9/30163—Decoding the operand specifier, e.g. specifier format with implied specifier, e.g. top of stack
    • 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/3017—Runtime instruction translation, e.g. macros
    • 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
    • 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 or look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3804—Instruction prefetching for branches, e.g. hedging, branch folding
    • 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 or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • 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 or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • 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 or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3888—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple threads [SIMT] in parallel
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/452—Instruction code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • 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 or look ahead
    • G06F9/3824—Operand accessing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Advance Control (AREA)
  • Complex Calculations (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

Prozessor (200), umfassend:einen Befehlsdecodierer (202), um einen ersten Befehl (210) zum Sammeln von Datenelementen aus einem Speicher (206) zu decodieren, wobei der erste Befehl (210) einen ersten Operanden, der einen ersten Speicherort spezifiziert, und einen zweiten Operanden aufweist, der eine erste Speicheradresse spezifiziert, die mehrere Datenelemente speichert;eine Ausführungseinheit (204), die an den Befehlsdecodierer (202) gekoppelt ist, um in Reaktion auf den ersten und einen zweiten Befehl (210) ein erstes und ein zweites der Datenelemente zusammenhängend von einem Speicherort auszulesen, basierend auf der ersten Speicheradresse, die durch den zweiten Operanden angegeben ist, und um das erste Datenelement in einem ersten Eintrag des ersten Speicherortes und ein zweites Datenelement in einem ersten Eintrag eines zweiten Speicherortes entsprechend dem ersten Eintrag des ersten Speicherortes zu speichern,wobei der Befehlsdecodierer ferner den zweiten Befehl mit einem dritten Operanden decodiert, der den zweiten Speicherort spezifiziert, und mit einem vierten Operanden, der eine zweite Speicheradresse spezifiziert, wobei die zweite Speicheradresse zu der ersten Speicheradresse um die Größe eines einzelnen Datenelements versetzt ist,wobei der erste Befehl ferner ein Präfix umfasst, das dem Befehlsdecodierer und der Ausführungseinheit angibt, dass der zweite Befehl auf den ersten Befehl folgt und der erste Befehl zu puffern ist, bis der zweite Befehl ankommt, und wobei der zweite Befehl das Präfix nicht umfasst.

Description

  • TECHNISCHES GEBIET
  • Das technische Gebiet der Erfindung betrifft allgemein eine Prozessorarchitektur und konkreter Verfahren für das Zusammenfügen von Sammel- und Streu (Gather-Scatter) -operationen.
  • BISHERIGER STAND DER TECHNIK
  • Um den SIMD-Prozessor (Single Instruction, Multiple Data) vollständig zu nutzen, werden Sammelbefehle verwendet, um einen Satz von (möglicherweise) nicht zusammenhängenden Quelldatenelementen aus dem Speicher auszulesen und diese zusammenzupacken, typischerweise in ein einzelnes Register. Streubefehle bewirken das Gegenteil. In einigen Fällen ist bekannt, dass die Datenelemente im Speicher zusammenhängend sind. Bedauerlicherweise nutzen herkömmliche Sammel- (Gather-) und Streu- (Scatter-) Befehle diese bekannten Informationen nicht und reduzieren somit die Effizienz des SIMD-Prozessors.
  • US 2005/0125640 Al offenbart eine Datenverarbeitungsvorrichtung und ein Verfahren, um Daten zwischen Registern und einem Speicher zu bewegen.
  • In Shahbahrami, Asadollah; Juurlink, Ben; Vassiliadis, Stamatis: „Versatility of Extended Subwords and the Matrix Register File , ACM Trans. Archit. Code Optim., 5, 2008 werden diverse Mikroarchitektur-Techniken diskutiert, um die Restriktionen in bestehenden SIMD-Architekturen aufzuheben.
  • KURZFASSUNG DER ERFINDUNG
  • Der Gegenstand der Erfindung ist im unabhängigen Anspruch 1 und in den nebengeordneten Patentansprüchen 5 und 9 angegeben. Erfindungsgemäß umfasst dabei der erste Befehl ein Präfix, das dem Befehlsdecodierer und der Ausführungseinheit angibt, dass der zweite Befehl auf den ersten Befehl folgt und der erste Befehl zu puffern ist, bis der zweite Befehl ankommt, wobei der zweite Befehl das Präfix nicht umfasst.
  • Bevorzugte Ausführungsformen der Erfindung ergeben sich aus den abhängigen Patentansprüchen, der nachfolgenden Beschreibung und den Zeichnungen.
  • Figurenliste
  • Ausführungsformen der Erfindung werden beispielhaft und nicht einschränkend in den Abbildungen der begleitenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen gleiche Elemente angeben.
    • zeigt ein Fragment (Snippet) eines Quellcodes.
    • zeigt die resultierenden Sammel-/Streuoperationen, wenn die Lade-/Speicherbefehle des Quellcodes aus vektorisiert sind.
    • ist ein Blockschaltbild einer Ausführungspipeline eines Prozessors oder Prozessorkerns.
    • Die bis sind Blockschaltbilder, die das Zusammenfügen von drei benachbarten Sammelbefehlen veranschaulichen.
    • ist ein Blockschaltbild, welches das Zusammenfügen von drei benachbarten Sammelbefehlen mit einer Schreibmaske veranschaulicht.
    • ist ein Flussdiagramm, das ein Verfahren für das Verarbeiten eines zusammengefügten Sammelbefehls veranschaulicht.
    • ist ein Flussdiagramm, das in näheren Einzelheiten das Verfahren von veranschaulicht.
    • ist ein Blockschaltbild, welches das Zusammenfügen von drei benachbarten Streubefehlen veranschaulicht.
    • Die bis sind Blockschaltbilder, die ein Beispiel des Zusammenfügens von benachbarten Sammelbefehlen unter Verwendung der aktuellen ISA veranschaulicht.
    • zeigt den Pseudocode für die Operation eines neuen Befehls vgatherp0 123 qpd.
    • zeigt den Pseudocode für die Operation eines neuen Befehls vgatherp4567qpd.
    • zeigt den Pseudocode für die Operation eines neuen Befehls vgatherp01 qpd.
    • zeigt den Pseudocode für die Operation eines neuen Befehls vgatherp23 qpd.
    • zeigt den Pseudocode für die Operation eines neuen Befehls vgatherp34qpd.
    • zeigt den Pseudocode für die Operation eines neuen Befehls vgatherp67qpd.
    • ist ein Blockschaltbild der GENMUX-Einheit für das Transponieren der X-Komponenten der VPU-Bänke.
    • ist ein Blockschaltbild der GENMUX-Einheit für das Transponieren der Y-Komponenten der VPU-Bänke.
    • zeigt ein AVX-Befehlsformat (Advanced Vector Extensions).
    • zeigt ein AVX-Befehlsformat (Advanced Vector Extensions).
    • zeigt ein AVX-Befehlsformat (Advanced Vector Extensions).
    • ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon veranschaulicht.
    • ist ein Blockschaltbild, welches das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon veranschaulicht.
    • ist ein Blockschaltbild, das ein spezifisches vektorfreundliches Befehlsformat veranschaulicht.
    • ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat veranschaulicht.
    • ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat veranschaulicht.
    • ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat veranschaulicht.
    • ist ein Blockschaltbild einer Registerarchitektur.
    • ist ein Blockschaltbild, das eine In-order-Pipeline und eine registerumbenennende Out-of-Order-Ausgabe-/Ausführungspipeline veranschaulicht.
    • ist ein Blockschaltbild, das einen In-order-Architekturkern und einen registerumbenennenden Out-of Order-Ausgabe-/Ausführungsarchitekturkern zur Aufnahme in einen Prozessor veranschaulicht.
    • ist ein Blockschaltbild eines Prozessorkerns.
    • ist ein Blockschaltbild eines Prozessorkerns.
    • ist ein Blockschaltbild eines Prozessors.
    • ist ein Blockschaltbild eines Systems.
    • ist ein Blockschaltbild eines spezifischeren Systems.
    • ist ein Blockschaltbild eines spezifischeren Systems.
    • ist ein Blockschaltbild eines SoC.
    • ist ein Blockschaltbild, das die Verwendung eines Software-Befehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Verschiedene Ausführungsformen und Aspekte der Erfindungen werden unter Bezugnahme auf nachstehend erörterte Details beschrieben, und die begleitenden Zeichnungen veranschaulichen die verschiedenen Ausführungsformen. Die nachfolgende Beschreibung und die Zeichnungen dienen der Veranschaulichung der Erfindung und sind nicht als die Erfindung einschränkend zu verstehen. Zahlreiche spezifische Details werden beschrieben, um für ein gründliches Verständnis der verschiedenen Ausführungsformen der Erfindung zu sorgen. Allerdings werden in bestimmten Fällen bekannte oder herkömmliche Details nicht beschrieben, um eine kompakte Erörterung von Ausführungsformen der Erfindung bereitzustellen.
  • Verweise in der Spezifikation auf „1 Ausführungsform“ oder „eine Ausführungsform“ bedeuten, dass ein besonderes Merkmal, eine Struktur oder eine Eigenschaft, die in Verbindung mit der Ausführungsform beschrieben werden, in wenigstens einer Ausführungsform der Erfindung enthalten sein kann. Die Vorkommnisse der Formulierung „in einer Ausführungsform“ an verschiedenen Stellen der Spezifikation beziehen sich nicht notwendigerweise alle auf dieselbe Ausführungsform.
  • zeigt ein Fragment (Snippet) eines Quellcodes. Ein sehr gängiges Muster in Quellcodes, veranschaulicht in , ist das Laden und Speichern von zusammenhängenden Elementen einer Struktur in eine(r) Folge von Registern. Wenn der Quellcode aus vektorisiert ist, wird jeder der Ladevorgänge zu einer Sammeloperation, und jeder der Speichervorgänge wird zu einer Streuoperation, was in veranschaulicht ist.
  • Es wird nun Bezug genommen auf ; die Sammeloperation 1 führt acht Speicherlesevorgänge durch, über den Speicher verteilt gemäß den acht Indizes in Register zmm8. Die Sammeloperation 2 verwendet dieselbe Basis (rax) und dieselben Indizes (zmm8) und führt nahezu exakt dieselben Speicherlesevorgänge durch wie Sammeloperation 1, mit der Ausnahme, dass diese Operation um 8 Bytes versetzt ist (da Sammeloperation 2 einen Verschiebungsoperanden von 8 aufweist). Sammeloperation 3 führt dieselben Speicherlesevorgänge durch wie Sammeloperation 1, mit der Ausnahme, dass diese Operation um 16 Bytes versetzt ist (da Sammeloperation 2 einen Verschiebungsoperanden von 16 aufweist). Somit erzeugen die drei Sammeloperationen insgesamt vierundzwanzig Lesevorgänge bei Durchlaufen eines Speicherausführungsclusters (Memory Execution Cluster, MEC). Die drei Sammeloperationen erfordern außerdem, dass die Sammel-/Streu-Zustand-Maschine (weitere Einzelheiten werden weiter unten geliefert) dreimal eingerichtet werden muss, was eine signifikante Anzahl von Zyklen und Transfers zwischen einer Vektorverarbeitungseinheit (Vector Processing Unit, VPU) und dem MEC erfordert.
  • Es wird weiterhin Bezug genommen auf ; die Streuoperation 1 führt acht Speicherschreibvorgänge durch, über den Speicher verteilt gemäß den acht Indizes in zmm8. Die Streuoperation 2 verwendet dieselbe Basis (rax) und dieselben Indizes (zmm8) und führt nahezu exakt dieselben Speicherschreibvorgänge durch wie Streuoperation 1, mit der Ausnahme, dass diese Operation um 8 Bytes versetzt ist (da Streuoperation 2 einen Verschiebungsoperanden von 8 aufweist). Streuoperation 3 führt dieselben Speicherschreibvorgänge durch wie Streuoperation 1, mit der Ausnahme, dass diese Operation um 16 Bytes versetzt ist (da Streuoperation 2 einen Verschiebungsoperanden von 16 aufweist). Somit erzeugen die drei Streuoperationen insgesamt vierundzwanzig Schreibvorgänge bei Durchlaufen eines Speicherausführungsclusters (Memory Execution Cluster, MEC). Die drei Streuoperationen erfordern außerdem, dass die Sammel-/Streu-Zustand-Maschine drei Mal eingerichtet werden muss, was eine signifikante Anzahl von Zyklen und Transfers zwischen der VPU und dem MEC erfordert.
  • Gemäß einigen nichtbeanspruchten Beispielen wird eine neue Befehlssatzarchitektur (Instruction Set Architecture, ISA) genutzt, um ein zusammengefügtes Sammeln von zusammenhängenden Datenelementen aus dem Speicher durchzuführen und diese Datenelemente in einen Satz von mehreren Zielregistern einzuspeichern. Die neue ISA wird außerdem genutzt, um ein zusammengefügtes Streuen von Datenelementen anhand von mehreren Quelloperanden (z. B. Register, Speicherorte) durchzuführen, indem diese Datenelemente im Speicher in zusammenhängenden Datenelementen gespeichert werden. Ein neuer Satz von Prozessorbefehlen wird verwendet, um das zusammengefügte Sammeln/Streuen mit signifikanter Leistungsverbesserung in Bezug auf vorhandene Prozessorbefehle zu implementieren. Die ISA ist für den Betrieb mit SIMD-Registern mit 128 Bit (z. B. XMM-Register), SIMD-Registern mit 256 Bit (z. B. YMM-Register) oder SIMD-Registern mit 512 Bit (z. B. ZMM-Register) definiert. Die vorstehend besprochene SIMD-Register-Breite dient nur zur Veranschaulichung. Es versteht sich, dass die ISA für den Betrieb mit anderen SIMD-Register-Breiten definiert sein kann. Beispiele von zusammengefügten Sammelverfahren umfassen das Auslesen zusammenhängender Datenelemente aus dem Speicher unter Verwendung eines einzelnen Speicherzugriffs und das Speichern dieser Datenelemente an mehreren Zielspeicherorten. Beispiele von zusammengefügten Streuverfahren umfassen das Auslesen von Datenelementen aus mehreren Quellregistern und das zusammenhängende Speichern dieser Datenelemente im Speicher in einem einzelnen Speicherzugriff. In der hier bereitgestellten Beschreibung soll zusammenhängende Datenelemente bedeuten, dass sich die Datenelemente im Speicher nebeneinander befinden. Somit befindet sich der Ort im Speicher, der dem Ende eines Datenelements entspricht, neben dem Ort im Speicher, der dem Anfang eines anderen Datenelements entspricht.
  • ist ein Blockschaltbild eines Prozessors oder Prozessorkerns. Es wird Bezug genommen auf ; der Prozessor 200 kann eine beliebige Art von befehlsverarbeitenden Vorrichtungen oder Verarbeitungselementen repräsentieren. Ein Verarbeitungselement bezieht sich auf einen Strang, einen Prozess, einen Kontext, einen logischen Prozessor, einen Hardwarestrang, einen Kern und/oder irgendein Verarbeitungselement, das Zugriffe auf andere gemeinsam genutzte Ressourcen des Prozessors teilt, beispielsweise Reservierungseinheiten, Ausführungseinheiten, Pipelines und andere übergeordnete Caches/Speicher. Ein physischer Prozessor bezieht sich typischerweise auf eine integrierte Schaltung, welche potenziell eine beliebige Anzahl von anderen Verarbeitungselementen aufweist, beispielsweise Kerne oder Hardwarestränge. Ein Kern bezieht sich oft auf Logik, die sich auf einer integrierten Schaltung befindet, welche in der Lage ist, einen unabhängigen Architekturzustand aufrechtzuerhalten, wobei jeder unabhängig aufrechterhaltene Architekturzustand an mindestens einige dedizierte Ausführungsressourcen gekoppelt ist. In einem Beispiel kann es sich bei dem Prozessor 200 um einen Universalprozessor handeln. Der Prozessor 200 kann einer von verschiedenen Prozessoren für die Verarbeitung komplexer Befehlssätze (Complex Instruction Set Computing, CISC) sein, einer von verschiedenen Prozessoren für die Verarbeitung reduzierter Befehlssätze (Reduced Instruction Set Computing, RISC), einer von verschiedenen Prozessoren für sehr lange Befehlswörter (Very Long Instruction Word, VLIW), eine von verschiedenen Hybridausführungen davon oder ein vollkommen anderer Prozessortyp. Der Prozessor 200 kann auch einen oder mehrere Prozessorkerne repräsentieren.
  • In einem Beispiel umfasst der Prozessor 200, ohne jedoch hierauf beschränkt zu sein, einen Befehlsdecodierer 202 zum Empfangen und Decodieren von Befehlen 210. Der Befehlsdecodierer 202 kann eine(n) oder mehrere Mikrooperationen, Mikrocode, Einsprungspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale generieren und ausgeben, welche den Befehl 210 wiedergeben oder von diesem abgeleitet sind. Der Befehlsdecodierer 202 kann unter Verwendung von mehreren unterschiedlichen Mechanismen implementiert sein. Beispiele für geeignete Mechanismen umfassen, ohne jedoch hierauf beschränkt zu sein, Festwertspeicher (Read-only Memories, ROMs) für Mikrocode, Nachschlagetabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (Programmable Logic Arrays, PLAs) und dergleichen.
  • Ausführungseinheiten 204, die eine arithmetische Logikeinheit (Arithmetic Logic Unit, ALU) oder eine andere Art von Logikeinheit aufweisen können, welche in der Lage ist, Operationen basierend auf Befehlen durchzuführen. Als Folge davon, dass der Befehlsdecodierer 202 den Befehl decodiert, kann die Ausführungseinheit 204 eine(n) oder mehrere Mikrooperationen, Mikrocode-Einsprungspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale empfangen, welche die Befehle wiedergeben oder von diesen abgeleitet sind. Die Ausführungseinheit 204 kann als Folge davon, dass Befehle einen oder mehrere Quelloperanden (SRC) angeben, betrieben werden und ein Ergebnis in einem oder mehreren Zieloperanden (DEST) eines durch die Befehle angegebenen Registersatzes speichern. Die Ausführungseinheit 204 kann Schaltungen oder eine andere Ausführungslogik aufweisen (z. B. eine mit Hardware und/oder Firmware kombinierte Software), die betrieben werden kann, um Befehle oder andere, von den Befehlen abgeleitete Steuersignale auszuführen und eine Operation entsprechend durchzuführen.
  • In einem Beispiel kann der Befehl 210 die Quell- und - Zieloperanden implizit angeben und/oder explizit spezifizieren (z.B. durch ein oder mehrere dedizierte Felder oder Sätze von Bits). Beispiele für geeignete Quellen und/oder Ziele der Operanden umfassen Register, Speicher, Direktoperanden des Befehls und Kombinationen davon. In verschiedenen Beispielen können die Quell- und Zieloperanden als 8-Bit-, 16-Bit-, 32-Bit-, 64-Bit-, 128-Bit-, 256-Bit- oder 512-Bit-Operanden ausgeführt sein, wenngleich dies nicht erforderlich ist.
  • Einige oder alle der Quell- und Zieloperanden können in Speicherressourcen 206 wie Registern eines Registersatzes oder Speichers gespeichert sein. Ein Registersatz kann Teil einer Registerdatei sein, zusammen mit potenziell anderen Registern, beispielsweise Statusregistern, Markierungsregistern etc. Bei einem Register kann es sich um einen Speicherort oder eine Vorrichtung handeln, die für das Speichern von Daten verwendet werden kann. Der Registersatz kann sich oft physisch auf einem Halbleiterplättchen mit der Ausführungseinheit bzw. den Ausführungseinheiten befinden. Die Register können von der Außenseite des Prozessors oder aus Programmiererperspektive sichtbar sein. So können beispielsweise Befehle in den Registern gespeicherte Operanden spezifizieren. Mehrere unterschiedliche Arten von Registern sind geeignet, sofern diese in der Lage sind, Daten wie hier beschrieben zu speichern und bereitzustellen. Die Register können oder können nicht umbenannt werden. Beispiele für geeignete Register umfassen, ohne jedoch hierauf beschränkt zu sein, dedizierte physische Register, unter Verwendung der Registerumbenennung dynamisch zugewiesene physische Register, Kombinationen aus dedizierten und dynamisch zugewiesenen physischen Registern etc. Alternativ können einer oder mehrere der Quell- und Zieloperanden an einem anderen Speicherort als einem Register gespeichert sein, beispielsweise an einem Ort im Systemspeicher.
  • Gemäß einem Beispiel weist die Ausführungseinheit 204 eine Sammel-/Streueinheit 208 auf, welche Sammel-/Streubefehle ausführt, die vom Befehlsdecodierer 202 decodiert worden sind. Nachstehend finden sich Beispiele von Sammel- und Streubefehlen, welche bei Ausführung durch die Sammel-/Streueinheit 208 die Effizienz eines SIMD-System verbessern, indem sie die Vorteile nutzen, die sich durch die Tatsache ergeben, dass Datenelemente zusammenhängend im Speicher vorliegen.
  • In einem Beispiel handelt es sich bei dem Sammelbefehl um einen zusammengefügten Sammelbefehl. Die Ausführung dieses Befehls durch die Sammel-/Streueinheit 208 speichert zusammenhängende Datenelemente aus dem Speicher in mehrere Zieloperanden. So werden beispielsweise in einigen Beispielen bis zu sechzehn 32-Bit- oder acht 64-Bit-Gleitkomma-Datenelemente bedingt in Zieloperanden gepackt, beispielsweise XMM-, YMM- oder ZMM-Register.
  • Die in die Zieloperanden zu ladenden zusammenhängenden Speicherdatenelemente werden über eine Art von SIB-Adressierung (Skala, Index und Basis) spezifiziert. Der zusammengefügte Sammelbefehl umfasst außerdem eine Schreibmaske. In einigen Beispielen, die ein dediziertes Maskenregister verwenden, beispielsweise eine (an späterer Stelle erläuterte) Schreibmaske „k“, werden die Speicherdatenelemente geladen, wenn deren zugehöriges Schreibmaskenbit angibt, dass dies erfolgen soll (in einigen Beispielen beispielsweise, wenn das Bit den Wert „1“ hat). Falls das zugehörige Schreibmaskenbit eines Speicherdatenelements nicht gesetzt ist, bleibt das entsprechende Datenelement des Zieloperanden (z. B. ein XMM-, YMM- oder ZMM-Register) unverändert.
  • In einem Beispiel hat die Ausführung eines zusammengefügten Sammelbefehls zur Folge, dass das gesamte Schreibmaskenregister auf null gesetzt wird, sofern es keine Ausnahme gibt. Allerdings wird der Befehl in einigen Beispielen durch eine Ausnahme ausgesetzt, falls bereits wenigstens ein Element gesammelt worden ist (d. h. wenn die Ausnahme durch ein anderes Element ausgelöst wird als das niedrigstwertige Element mit gesetztem zugehörigen Schreibmaskenbit). Wenn dies geschieht, werden das Zielregister und das Schreibmaskenregister teilweise aktualisiert (diejenigen Elemente, die gesammelt worden sind, werden in das Zielregister platziert und die zugehörigen Maskenbits werden auf null gesetzt). Falls noch irgendwelche Fallen oder Interrupts von bereits gesammelten Elementen ausstehen, können diese anstelle der Ausnahme ausgegeben werden, und das EFLAGS-Wiederaufnahme-Kennzeichen oder ein Äquivalent wird auf eins gesetzt, so dass ein Befehlshaltepunkt nicht erneut ausgelöst wird, wenn der Befehl fortgesetzt wird.
  • In einigen Beispielen mit 128 Bit großen Zielregistern sammelt der Befehl bis zu vier einfach genaue Gleitkommawerte oder zwei doppelt genaue Gleitkommawerte pro Zielregister. In einigen Beispielen mit 256 Bit großen Zielregistern sammelt der Befehl bis zu acht einfach genaue Gleitkommawerte oder vier doppelt genaue Gleitkommawerte pro Zielregister. In einigen Beispielen mit 512 Bit großen Zielregistern sammelt der Befehl bis zu sechzehn einfach genaue Gleitkommawerte oder acht doppelt genaue Gleitkommawerte pro Zielregister.
  • In einigen Beispielen, falls die Masken- und Zielregister identisch sind, gibt dieser Befehl eine allgemeine Schutz- (GP, General Protection) verletzung aus. Typischerweise können die Datenelementwerte in beliebiger Reihenfolge aus dem Speicher ausgelesen werden. Allerdings werden Fehler von rechts nach links ausgegeben. Das heißt: Falls ein Fehler durch ein Element ausgelöst und ausgegeben wird, werden alle Elemente, die sich näher an dem niedrigstwertigen Bit (Least Significant Bit, LSB) des Ziels XMM, YMM oder ZMM befinden, abgeschlossen (und sind fehlerfrei). Einzelne Elemente, die sich näher an dem MSB befinden, können abgeschlossen werden oder auch nicht. Falls ein gegebenes Element mehrere Fehler auslöst, werden diese Fehler in der herkömmlichen Reihenfolge ausgegeben. Eine gegebene Implementierung dieses Befehls ist wiederholbar - bei identischen Eingangswerten und identischem Architekturzustand wird derselbe Satz von Elementen links vom fehlerhaften Element gesammelt.
  • Der zusammengefügte Sammelbefehl kann in mehreren Formaten implementiert sein. In einem Beispiel ist der zusammengefügte Sammelbefehl wie folgt definiert: VGATHERQ4PD zmm3 : zmm 5 : zmm 6 : zmm 0 { k1 } , [ rax + zmm 9 ]
    Figure DE112012007063B4_0001
    wobei gilt: zmm3, zmm5, zmm6 und zmm0 sind Zielvektorregister-Operanden (beispielsweise ein 128-, 256-, 512-Bit-Register etc.), k1 ist ein Schreibmaskenoperand (beispielsweise ein 16-Bit-Register, für das an späterer Stelle Beispiele erläutert werden), rax ist die Basisadresse und zmm9 ist ein Indexvektor/eine Indexanordnung. Es sei darauf hingewiesen, dass das vorstehende Format nur zum Zwecke der Veranschaulichung beschrieben wird; auch andere Formate oder Reihenfolgen der Operanden können implementiert sein. In einem Beispiel werden die Basis und ein in einem Index des Indexvektors gespeicherter Wert verwendet, um eine Speicheradresse zu erzeugen, die dem Anfangsort eines Blocks von zusammenhängenden Datenelementen entspricht, welche gelesen und in den entsprechenden Datenelementen (d. h. Einträgen) der Zieloperanden gespeichert werden. In einigen Beispielen hat die Schreibmaske außerdem eine unterschiedliche Größe (8 Bits, 32 Bits etc.). Darüber hinaus werden in einigen Beispielen nicht alle Bits der Schreibmaske von dem Befehl genutzt.
  • In einem Beispiel im vorstehenden Format 0 des Befehls ist der erste Zieloperand zmm3, der zweite Zieloperand ist zmm5, der dritte Zieloperand ist zmm6 und der vierte Zieloperand ist zmm0. In einem anderen Beispiel ist die Reihenfolge der Operanden umgekehrt. In einem Beispiel gibt die Reihenfolge dieser Operanden explizit die Reihenfolge an, in der im Speicher befindliche zusammenhängende Datenelemente in die Zieloperanden geladen werden. Somit wird in dem vorstehenden Beispiel für Format 0, unter der Annahme, dass die Schreibmaske angibt, dass alle Datenelemente aktualisiert werden sollen (was nachstehend ausführlicher besprochen wird), und ferner unter der Annahme, dass zmm3 der erste Operand ist, das Datenelement an Speicherort „rax+zmm9[0]“ in zmm3[0] eingespeichert. Die nächsten drei zusammenhängenden Datenelemente, d. h. die Datenelemente an Speicherort „rax+zmm9[0]+größevon(datenelement)“, an „rax+zmm9[0]+(2*größevon(datenelement))“ und an „rax+zmm9[0]+(3*größevon(datenelement))“ werden in das erste Datenelement jedes nachfolgenden Zieloperanden eingespeichert, d. h. zmm5[0], zmm6[0] bzw. zmm0[0]. Das zweite Datenelement jedes Zieloperanden wird mit im Speicher befindlichen zusammenhängenden Datenelementen unter Verwendung desselben Adressierungsschemas aktualisiert, z. B. wird zmm3[1] mit dem Datenelement an Speicherort „rax+zmm9[1]“ aktualisiert und zmm5[1], zmm6[1], zmm0[1] werden mit den nächsten drei zusammenhängenden Datenelementen im Speicher geladen.
  • VGATHERQ4PD ist der Opcode des Befehls. Typischerweise ist jeder Operand explizit im Befehl definiert. Die Größe der Datenelemente kann im „Suffix“ des Befehls definiert sein. So kann beispielsweise das Suffix „PD“ im Befehl VGATHERQ4PD angeben, dass es sich bei dem Datenelement um einen Wert mit doppelter Genauigkeit handelt (d. h. um einen 64-BitWert). In den meisten Beispielen sind die Datenelemente 32- oder 64-Bit-Werte. Wenn die Datenelemente eine Größe von 32 Bit haben und die Operanden eine Größe von 512 Bit haben, dann gibt es sechzehn (16) Datenelemente pro Operand. In einigen Beispielen gibt die Anzahl von Datenelementen pro Operand implizit die Anzahl von Indizes an, die im Indexvektor vorliegen (z. B. zmm9 im vorstehenden Beispiel). In einigen Beispielen ist die Anzahl von Operanden außerdem explizit im Befehl definiert. So kann beispielsweise im vorstehenden Beispiel die „4“ vor dem Suffix „PD“ angeben, dass der Befehl vier benachbarte Sammelbefehle zusammenfügt, d. h. die Ausführung des Befehls hat zur Folge, dass vier zusammenhängende Datenelemente aus dem Speicher in entsprechende Datenelemente von vier Zieloperanden geschrieben werden (z. B. zmm3, zmm5, zmm6 und zmm0 im vorstehenden Beispiel). In einem Beispiel wird der Block aus zusammenhängenden Datenelementen in einem einzelnen Speicherzugriff aus dem Speicher ausgelesen. In einem Beispiel wird der Block von Datenelementen in einem einzelnen Zyklus in alle Zieloperanden eingespeichert.
  • In einem anderen Beispiel ist der zusammengefügte Sammelbefehl wie folgt definiert: VGATHERQ4PD zmm3 − zmm 0 { k1 } , [ rax + zmm 9 ] .
    Figure DE112012007063B4_0002
  • Die Ausführung des zusammengefügten Sammelbefehls mit Format 1 bewirkt, dass Operationen, die den vorstehend im Text zu Format 0 besprochenen Operationen ähneln, ausgeführt werden. Der Unterschied zwischen Format 0 und Format 1 besteht darin, dass bei Format 1 die Zielregister als Registerbereich spezifiziert sind. Im vorstehenden Beispiel für Format 1 ist der Bereich von Zielregistern durch zmm3 und zmm0 begrenzt. Implizit sind somit zmm3, zmm2, zmm1 und zmm0 die Zielregister, wobei zmm2 und zmm1 durch die Tatsache impliziert sind, dass der Befehl explizit angibt, dass Datenelemente aus dem Speicher in vier Zielregister gepackt werden sollen. Es sei darauf hingewiesen, dass es sich in diesem Beispiel, auch wenn die Wahl des ersten Zielregisters frei spezifiziert sein kann, um einen Syntaxfehler handelt, wenn ein Bereich von Zielregistern spezifiziert wird, der nicht mit der Anzahl von Zielregistern übereinstimmt, die explizit durch den Befehl angegeben werden.
  • In einem anderen Beispiel ist der zusammengefügte Sammelbefehl wie folgt definiert: VGATHERQ4PD zmm3 − zmm 0 { k1 } , [ rax + zmm 9 ] .
    Figure DE112012007063B4_0003
  • Die Ausführung des zusammengefügten Sammelbefehls mit Format 2 bewirkt, dass Operationen, die den vorstehend im Text zu Format 0 besprochenen Operationen ähneln, ausgeführt werden. Der Unterschied zwischen Format 0 und Format 2 besteht darin, dass bei Format 2 die Zielregister fixiert sind. Somit werden beispielsweise im vorstehenden Beispiel die Zielregister auf zmm3, zmm2, zmm1 und zmm0 fixiert, weil der Befehl explizit angibt, dass Datenelemente aus dem Speicher in vier Zielregister gepackt werden sollen. Es sei darauf hingewiesen, dass es sich in diesem Beispiel um einen Syntaxfehler handelt, wenn andere Zielregister als „zmm3-zmm0“ spezifiziert werden und dies nur als Hilfe zur besseren Lesbarkeit spezifiziert ist. Auch wenn im vorstehenden Beispiel die Register auf „zmm3-zmm0“ fixiert sind, versteht sich, dass die Register auf einen Bereich von anderen Registern fixiert werden können, z. B. „zmm4-zmm1“ oder „zmm5-zmm2“ etc., oder auf einen Satz von nicht zusammenhängenden Registern.
  • In einem Beispiel werden die Datenelemente aus dem Speicher abgerufen und, in ähnlicher Weise wie der vorstehend besprochenen, in temporären Vektorregistern gespeichert, bevor diese Datenelemente in den Zielregistern gespeichert werden.
  • Die bis veranschaulichen ein Beispiel für die Ausführung eines zusammengefügten Sammelbefehls, der drei benachbarte Sammelbefehle zusammenfügt. In diesem Beispiel fasst zmm8 die acht qword-Indizes (d. h. jeder Index ist 64 Bit breit) für drei zusammengefügte Sammelbefehle. Da die Zielregister (zmm0, zmm1 und zmm2) jeweils 512 Bit breit sind, beträgt die Größe jedes der acht Datenelemente 8 Byte in der Breite (d. h. Einheit mit doppelter Genauigkeit). Somit ruft jeder Speicherlesevorgang einen 24-Byte-Speicherblock bestehend aus drei Werten mit doppelter Genauigkeit ab. In dieser Darstellung sind der erste, der zweite und der dritte Zieloperand zmm0, zmm1 bzw. zmm2. Somit wird das erste Datenelement jedes 24-Byte-Blocks in das entsprechende Datenelement von zmm0 eingespeichert; das zweite Datenelement des Blocks wird in das entsprechende Datenelement von zmm1 eingespeichert; und das dritte Datenelement des Blocks wird in das entsprechende Datenelement von zmm2 eingespeichert. In diesen Darstellungen ist der Startspeicherort jedes Blocks von Datenelementen die Basisadresse plus der Wert, der im entsprechenden Index der Indexanordnung gespeichert ist, z. B. „rax+zmm8[0]“. Für eine bessere Lesbarkeit steht in den Abbildungen jedoch für „rax+zmm 8[0]“ einfach nur „zmm8[0]“. Diese Bezeichnung gilt für alle nachfolgenden Abbildungen in der Beschreibung.
  • Es wird nun Bezug genommen auf ; ein 24-Byte-Speicherblock bestehend aus drei Datenelementen mit doppelter Genauigkeit (d. h. jedes Datenelement im Speicher ist 8 Bytes breit) wird aus dem Speicher ausgelesen, wobei das erste Datenelement des Speicherblocks an Speicherort „rax+zmm8[0]“ beginnt, das zweite Datenelement des Speicherblocks ist acht Bytes vom Anfangsort entfernt, und das dritte Datenelement beginnt an einem Ort, der sechzehn Bytes vom Startspeicherort des Blocks entfernt ist. Das erste Datenelement des Speicherblocks ist im ersten Datenelement des ersten Zielregisters gespeichert (d. h. zmm0[0]), das zweite Datenelement des Speicherblocks ist im ersten Datenelement des zweiten Zielregisters gespeichert (d. h. zmm1 [0]) und das dritte Datenelement des Speicherblocks ist im ersten Datenelement des dritten Zielregisters gespeichert (d. h. zmm2[0]). In einem Beispiel ist das „erste Datenelement“ eines Zielregisters das Datenelement, welches die niedrigstwertigen Bits (Least Significant Bits, LSB) des Zielregisters umfasst. In einem anderen Beispiel umfasst das „erste Datenelement“ eines Zielregisters die höchstwertigen Bits (Most Significant Bits, MSB) des Zielregisters.
  • veranschaulicht den Speicherlesevorgang eines zweiten 24-Byte-Speicherblocks. In dieser Darstellung beginnt der Speicherblock bei „rax+zmm8[1]“. Da der zweite Index von zmm8 (d. h. zmm8[1]) verwendet wird, um die Speicheradresse zu generieren, werden die abgerufenen zusammenhängenden Datenelemente im zweiten Datenelement jedes Zielregisters gespeichert (d. h. zmm0[1], zmml[1] und zmm2[1]).
  • veranschaulicht den Speicherlesevorgang eines dritten 24-Byte-Speicherblocks, beginnend an dem Speicherort „rax+zmm8[2]“. Da der dritte Index von zmm8 (d. h. zmm8[2]) verwendet wird, um die Speicheradresse zu generieren, werden die abgerufenen zusammenhängenden Datenelemente im dritten Datenelement jedes Zielregisters gespeichert (d. h. zmm0[2], zmm1[2] und zmm2[2]).
  • veranschaulicht den Speicherlesevorgang eines vierten 24-Byte-Speicherblocks, beginnend an dem Speicherort „rax+zmm8[3]". Da der vierte Index von zmm8 (d. h. zmm8[3]) verwendet wird, um die Speicheradresse zu generieren, werden die abgerufenen zusammenhängenden Datenelemente im vierten Datenelement jedes Zielregisters gespeichert (d. h. zmm0[3], zmm1[3] und zmm2[3]).
  • zeigt die Zielregister zmm0, zmm1 und zmm2, vollständig gepackt mit Datenelementen aus dem Speicher, nachdem vier weitere 24-Byte-Speicherblöcke gelesen wurden.
  • veranschaulicht ein anderes Beispiel für die Ausführung eines zusammengefügten Sammelbefehls unter Verwendung der Schreibmaske. In dieser Darstellung ist die Basisadresse rax (nicht gezeigt), und der Indexvektor/die Indexanordnung ist zmm8. Die Darstellung ist ein Beispiel für das Zusammenfügen von drei benachbarten Sammeloperationen, d. h. Gruppen von drei zusammenhängend im Speicher befindlichen Datenelementen werden gemäß der Schreibmaske k1 in Datenelemente von drei Zieloperanden (zmm2, zmm1 und zmm0) eingespeichert. Die Schreibmaske k1 hat einen hexadezimalen Wert von 0xA3. In dieser Darstellung sind der erste, der zweite und der dritte Zieloperand zmm2, zmm1 bzw. zmm0.
  • Die Ausführung des zusammengefügten Sammelbefehls bewirkt, dass die Sammel-/Streueinheit 208 eine erste Speicheradresse generiert und bestimmt, ob Lesevorgang 0 ausgeführt werden soll. In einem Beispiel ist die erste Adresse die Basisadresse plus dem im ersten Index der Indexanordnung gespeicherten Wert (d. h. „rax+zmm8[0]“), welcher auf einen Speicherort des ersten Datenelements im Speicher zeigt, das im ersten Datenelement des ersten Zieloperanden (zmm2[0]) gespeichert werden soll.
  • In einem Beispiel bestimmt die Sammel-/Streueinheit 208, ob Datenelemente aus dem Speicher gelesen und gemäß den Schreibmaskenbit-Werten in den entsprechenden Datenelementen der Zieloperanden gespeichert werden sollen. In dieser Darstellung hat das erste (LSB) Bit der Schreibmaske, d. h. k1[0], den Wert „1“, was in einem Beispiel angibt, dass das erste (LSB) Datenelement jedes Zieloperanden aktualisiert werden solle. Infolgedessen werden das Datenelement an Speicherort „rax+zmm8[0]“ mit dem Wert „2“ und die nächsten zwei zusammenhängenden Datenelemente mit den Werten „1“ und „0“ in einem einzelnen Speicherzugriff aus dem Speicher ausgelesen. In einem Beispiel werden die Datenelemente {2, 1, 0} in einem einzelnen Zyklus in zmm2[0], zmm1[0] bzw. zmm0[0] gespeichert.
  • In ähnlicher Weise generiert die Sammel-/Streueinheit 208 eine zweite Adresse, die auf den Speicherort „rax+zmm8[1]" zeigt, und bestimmt, ob Lesevorgang 1 ausgeführt werden soll. Ebenso wie k1[0] wird auch die Schreibmaske k1[1] auf „1“ gesetzt; somit werden zusammenhängende Datenelemente {12, 11, 10} beginnend an Ort „rax+zmm8[1]“ aus dem Speicher abgerufen und in zmm2[1], zmm1[1] bzw. zmm0[1] eingespeichert.
  • Die Sammel-/Streueinheit 208 überspringt Lesevorgang 2 in diesem Beispiel, weil anders als bei k1[0] und k1[1] das Schreibmaskenbit k1[2] auf „0“ gesetzt ist, was in einem Beispiel angibt, dass das dritte Datenelement der Zieloperanden nicht aktualisiert werden soll. Infolgedessen bleiben zmm2[2], zmm1[2] und zmm0[2] unverändert, was durch die Kennzeichnung „x“ in angegeben wird.
  • Die Sammel-/Streueinheit 208 führt dieselbe Logik durch wie vorstehend besprochen und bestimmt, dass Lesevorgang 3, Lesevorgang 4 und Lesevorgang 6 übersprungen werden sollen, weil k1[3], k1[4] und k1[6] alle auf „0“ gesetzt sind. Darüber hinaus bestimmt die Sammel-/Streueinheit 208, dass Lesevorgang 5 durchgeführt werden soll, weil k1[5] auf „1“ gesetzt ist, und ruft die zusammenhängenden Datenelemente {52, 51, 50} beginnend bei der Adresse „rax+zmm8[5]" aus dem Speicher ab und speichert diese Datenelemente in zmm2[5], zmm1[5] bzw. zmm0[5]. In gleicher Weise wird Lesevorgang 7 durchgeführt, weil k1 [7] auf „1“ gesetzt ist, und zusammenhängende Datenelemente {72, 71, 70} werden beginnend an Ort „rax+zmm8[7]" aus dem Speicher abgerufen und in zmm2[7], zmm1[7] bzw. zmm0[7] eingespeichert.
  • ist ein Flussdiagramm, das ein Verfahren 500 für das Verarbeiten eines zusammengefügten Sammelbefehls veranschaulicht. Das Verfahren 500 kann vom Prozessor 200 aus durchgeführt werden. Es wird Bezug genommen auf ; bei Block 505 wird ein erster Befehl für das Sammeln von zusammenhängenden Datenelementen aus dem Speicher decodiert. In einem Beispiel weist der erste Befehl mehrere Operanden auf, z. B. einen ersten Operanden, der einen ersten Speicherort spezifiziert, einen zweiten Operanden, der einen zweiten Speicherort spezifiziert, und einen dritten Operanden, der eine Speicheradresse spezifiziert. In einem Beispiel weist der dritte Operand eine Basisadresse und eine Indexanordnung auf. Der erste Befehl kann auch eine Schreibmaske aufweisen. Beispielhafte Operandengrößen sind vorstehend ausführlich beschrieben worden.
  • Bei Block 510 werden in Reaktion auf den ersten Befehl zusammenhängende erste und zweite Datenelemente aus dem Speicher ausgelesen, wobei die Speicheradresse, die durch den dritten Operanden angegeben wird, als Basis fungiert. In einem Beispiel werden die zusammenhängenden Datenelemente in einem einzelnen Speicherzugriff aus dem Speicher ausgelesen.
  • Bei Block 515 wird der erste Befehl ausgeführt, um zusammenhängende erste und zweite Datenelemente aus dem Speicher in einen ersten Eintrag des ersten bzw. zweiten Speicherortes einzuspeichern. In einem Beispiel werden die zusammenhängenden Datenelemente in einem einzelnen Zyklus in den ersten und den zweiten Speicherort eingespeichert. In einem Beispiel werden die Datenelemente in temporäre Vektorregister eingespeichert, bevor diese Datenelemente in Zieloperanden eingespeichert werden.
  • ist ein Flussdiagramm, das ein Verfahren 600 für das Verarbeiten eines zusammengefügten Sammelbefehls veranschaulicht. Das Verfahren 600 kann vom Prozessor 200 aus durchgeführt werden. In dieser Darstellung wird davon ausgegangen, dass einige, wenn nicht alle, der Operationen 505-515 aus zuvor durchgeführt worden sind. So ist beispielsweise zumindest ein erster Befehl zum Sammeln von Datenelementen decodiert worden. Es wird Bezug genommen auf ; bei Block 605 wird eine erste Adresse eines ersten Datenelements im Speicher gemäß einer Basisadresse generiert und ein Wert wird in einem ersten Index einer Indexanordnung gespeichert. In einem Beispiel handelt es sich bei der ersten Adresse um die Basisadresse plus dem Wert, der im ersten Index der Indexanordnung gespeichert ist.
  • Bei Block 610 wird gemäß einem Wert des ersten Schreibmaskenbits bestimmt, ob die Datenelemente in den ersten Eintrag des ersten und zweiten Speicherortes eingespeichert werden sollen. In einem Beispiel ist das erste Schreibmaskenbit das LSB-Bit der Schreibmaske. Wenn das Schreibmaskenbit nicht angibt, dass die Datenelemente an dem ersten und zweiten Speicherort gespeichert werden sollen, dann bleibt der erste Eintrag des ersten und zweiten Speicherortes bei Block 630 unverändert und die Verarbeitung ist abgeschlossen. In einem Beispiel gibt ein Schreibmaskenbit mit dem Wert „0“ an, dass die Datenelemente nicht an dem ersten und zweiten Speicherort gespeichert werden sollen. In einem anderen Beispiel kommt die gegenteilige Konvention zur Anwendung.
  • Wenn bei Block 615 der im ersten Maskenbit der Schreibmaske gespeicherte Wert angibt, dass die Datenelemente im ersten Eintrag des ersten und zweiten Speicherortes gespeichert werden sollen, dann werden Datenelemente aus dem Speicher ausgelesen. In einem Beispiel befindet sich das erste Datenelement an der ersten Adresse, und das zweite Datenelement befindet sich zusammenhängend gleich neben dem ersten Datenelement. In einem Beispiel werden die Datenelemente in einem einzelnen Speicherzugriff aus dem Speicher ausgelesen.
  • Bei Block 620 werden das erste und das zweite Datenelement in den ersten und den zweiten Speicherort eingespeichert. In einem Beispiel ist der Speicherort eine Anordnung von Einträgen (z. B. eine Anordnung von Datenelementen) und der erste Eintrag des Speicherortes ist der LSB-Eintrag. In einem Beispiel werden die Datenelemente in einem einzelnen Zyklus in den ersten Eintrag des ersten und des zweiten Speicherortes eingespeichert. In einem Beispiel werden das erste und das zweite Datenelement in Vektorregistern gespeichert, bevor diese Datenelemente in den ersten und den zweiten Speicherort eingespeichert werden.
  • Bei Block 625 wird das erste Schreibmaskenbit gelöscht, um anzuzeigen, dass der entsprechende Block von Datenelementen abgerufen und im ersten und im zweiten Speicherort gespeichert worden ist und der Prozess abgeschlossen ist.
  • Es wird erneut Bezug genommen auf ; wie vorstehend besprochen, führt die Sammel-/Streueinheit 208 Sammel- und Streubefehle aus. In einem Beispiel handelt es sich bei dem Streubefehl um einen zusammengefügten Streubefehl. Die Ausführung dieses Befehls durch die Sammel-/Streueinheit 208 speichert Datenelemente aus mehreren Quelloperanden in zusammenhängende Speicherorte, so dass sich die Datenelemente nebeneinander im Speicher befinden.
  • Die in den Speicher zu ladenden Datenelemente von Quelloperanden werden über eine Art von SIB-Adressierung (Skala, Index und Basis) spezifiziert. Der zusammengefügte Streubefehl umfasst auch eine Schreibmaske. In einigen Beispielen, die ein dediziertes Maskenregister verwenden, beispielsweise eine Schreibmaske „k“, werden die Datenelemente von Quelloperanden in den Speicher geladen, wenn deren zugehöriges Schreibmaskenbit angibt, dass dies erfolgen soll (in einigen Beispielen beispielsweise, wenn das Bit den Wert „1“ hat). Wenn das zugehörige Schreibmaskenbit eines Datenelements nicht gesetzt ist, bleibt das entsprechende Datenelement im Speicher unverändert.
  • In einigen Beispielen mit 128 Bit großen Quellregistern streut der Befehl bis zu vier einfach genaue Gleitkommawerte oder zwei doppelt genaue Gleitkommawerte pro Quellregister. In einigen Beispielen mit 256 Bit großen Quellregistern streut der Befehl bis zu acht einfach genaue Gleitkommawerte oder vier doppelt genaue Gleitkommawerte pro Quellregister. In einigen Beispielen mit 512 Bit großen Quellregistern streut der Befehl bis zu sechzehn einfach genaue Gleitkommawerte oder acht doppelt genaue Gleitkommawerte pro Quellregister.
  • Der zusammengefügte Streubefehl kann in mehreren Formaten implementiert sein. In einem Beispiel ist der zusammengefügte Streubefehl wie folgt definiert: VSCATTERQ4PD  [ rax + zmm 9 ] { k1 } , zmm 3 : zmm 5 : zmm 6 : zmm 0
    Figure DE112012007063B4_0004
    wobei gilt: zmm3, zmm5, zmm6 und zmm0 sind Quellvektorregister-Operanden (beispielsweise ein 128-, 256-, 512-Bit-Register etc.), k1 ist ein Schreibmaskenoperand (beispielsweise ein 16-Bit-Register, für das an späterer Stelle Beispiele erläutert werden), rax ist die Basisadresse, und zmm9 ist ein Indexvektor/eine Indexanordnung. In einem Beispiel werden die Basis und ein in einem Index des Indexvektors gespeicherter Wert verwendet, um eine Speicherzieladresse zu generieren, an der das erste Datenelement des ersten Quelloperanden gespeichert wird. In einigen Beispielen hat die Schreibmaske außerdem eine unterschiedliche Größe (8 Bits, 32 Bits etc.). Darüber hinaus werden in einigen Beispielen nicht alle Bits der Schreibmaske von dem Befehl genutzt.
  • In einem Beispiel im vorstehenden Format 3 des zusammengefügten Streubefehls ist der erste Quelloperand zmm3, der zweite Quelloperand ist zmm5, der dritte Quelloperand ist zmm6 und der vierte Quelloperand ist zmm0. In einem anderen Beispiel ist die Reihenfolge der Quelloperanden umgekehrt, d. h. zmm3 ist der vierte Operand und zmm0 ist der erste Operand. In einem Beispiel gibt die Reihenfolge dieser Operanden explizit die Reihenfolge an, in der Datenelemente aus jedem Quelloperanden in zusammenhängenden Speicher eingespeichert werden. Somit wird im vorstehenden Beispiel für Format 3, unter der Annahme, dass die Schreibmaske angibt, dass alle Datenelemente aktualisiert werden sollen (was nachstehend ausführlicher besprochen wird), und ferner unter der Annahme, dass der erste Quelloperand zmm3 ist, das Datenelement zmm3[0] des Quelloperanden beginnend an Speicherort „rax+zmm9[0]" als das erste Datenelement im zusammenhängenden Speicherblock gespeichert. Die Datenelement der nächsten drei Quelloperanden, d. h. zmm5[0], zmm6[0] und zmm0[0], werden an einem zusammenhängenden Speicherort gespeichert, d. h. zmm5[0] wird an „rax+zmm9[0] + größevon(datenelement)“ gespeichert, zmm6[0] wird an „rax+zmm9[0]+(2*größevon(datenelement))“ gespeichert und zmm0[0] wird an „rax+zmm9[0]+(3*größevon(datenelement))“ gespeichert. Das zweite Datenelement jedes Quelloperanden wird, beginnend an Ort „rax+zmm9[1]", an einem zusammenhängenden Speicherort gespeichert, was so ähnlich erfolgt wie das Speichern der ersten Datenelemente der Quelloperanden. Somit wird zmm3[1] unter" „rax+zmm9[1]" gespeichert; zmm5[1] wird an „rax+zmm9[1]+größevon(Datenelement)“ gespeichert; zmm6[1] wird an „rax+zmm9[1]+(2*größevon(Datenelement))“ gespeichert; und zmm0[1] wird an „rax+zmm9[1]+(3*größevon(datenelement))“ gespeichert. Die verbleibenden Datenelemente der Quelloperanden werden unter Verwendung derselben Logik in zusammenhängende Speicherblöcke eingespeichert.
  • VSCATTERQ4PD ist der Opcode des Befehls. Typischerweise ist jeder Operand explizit im Befehl definiert. Die Größe der Datenelemente kann im „Suffix“ des Befehls definiert sein. So kann beispielsweise das Suffix „PD“ im Befehl VSCATTERQ4PD angeben, dass es sich bei dem Datenelement um einen Wert mit doppelter Genauigkeit handelt (d. h. um einen 64-BitWert). In den meisten Beispielen sind die Datenelemente 32- oder 64-Bit-Werte. Wenn die Datenelemente eine Größe von 32 Bit haben und die Operanden eine Größe von 512 Bit haben, dann gibt es sechzehn (16) Datenelemente pro Operand. In einigen Beispielen gibt die Anzahl von Datenelementen pro Operand implizit die Anzahl von Indizes an, die im Indexvektor vorliegen (z. B. zmm9 im vorstehenden Beispiel). In einem Beispiel ist die Anzahl von Operanden außerdem explizit im Befehl definiert. So kann beispielsweise im vorstehenden Beispiel die „4“ vor dem Suffix „PD“ angeben, dass der Befehl vier benachbarte Streubefehle zusammenfügt, d. h. die Ausführung des Befehls hat zur Folge, dass Datenelemente aus vier Quelloperanden in zusammenhängende Speicherblöcke von vier Datenelemente geschrieben werden. In einem Beispiel werden die Datenelemente der Quelloperanden in einem einzelnen Speicherzugriff in jeden zusammenhängenden Speicherblock geschrieben.
  • In einem anderen Beispiel ist der zusammengefügte Streubefehl wie folgt definiert: VSCATTERQ4PD  [ rax + zmm 9 ] { k1 } , zmm 3 − zmm 0.
    Figure DE112012007063B4_0005
  • Die Ausführung des zusammengefügten Streubefehls mit Format 4 bewirkt, dass Operationen, die den vorstehend im Text zu Format 3 besprochenen Operationen ähneln, ausgeführt werden. Der Unterschied zwischen Format 3 und Format 4 besteht darin, dass bei Format 4 die Quelloperandenregister als Registerbereich spezifiziert sind. Im vorstehenden Beispiel für Format 4 ist der Bereich von Quellregistern durch zmm3 und zmm0 begrenzt. Implizit sind somit zmm3, zmm2, zmm1 und zmm0 die Quellregister, wobei zmm2 und zmm1 durch die Tatsache impliziert sind, dass der Befehl explizit angibt, dass Datenelemente aus vier Quellregistern in den Speicher gepackt werden sollen. Es sei darauf hingewiesen, dass es sich in diesem Beispiel, auch wenn die Wahl des ersten Quellregisters frei spezifiziert sein kann, um einen Syntaxfehler handelt, wenn ein Bereich von Quellregistern spezifiziert wird, der nicht mit der Anzahl von Quellregistern übereinstimmt, die explizit durch den Befehl angegeben werden.
  • In einem anderen Beispiel ist der zusammengefügte Streubefehl wie folgt definiert: VSCATTERQ4PD  [ rax + zmm 9 ] { k1 } , zmm 3 − zmm 0
    Figure DE112012007063B4_0006
  • Die Ausführung des zusammengefügten Streubefehls mit Format 5 bewirkt, dass Operationen, die den vorstehend im Text zu Format 3 besprochenen Operationen ähneln, ausgeführt werden. Der Unterschied zwischen Format 3 und Format 5 besteht darin, dass bei Format 5 die Quellregister fixiert sind. Somit werden beispielsweise im vorstehenden Beispiel die Quellregister auf zmm3, zmm2, zmm1 und zmm0 fixiert, weil der Befehl explizit angibt, dass Datenelemente aus vier Zielregistern in den Speicher gepackt werden sollen. Es sei darauf hingewiesen, dass es sich in diesem Beispiel um einen Syntaxfehler handelt, wenn andere Quellregister als „zmm3-zmm0“ spezifiziert werden und dies nur als Hilfe zur besseren Lesbarkeit spezifiziert ist. Auch wenn im vorstehenden Beispiel die Register auf „zmm3-zmm0“ fixiert sind, versteht sich, dass die Register auf einen Bereich von anderen Registern fixiert werden können, z. B. „zmm4-zmm1“ oder „zmm5-zmm2“ etc.
  • veranschaulicht ein Beispiel für die Ausführung eines zusammengefügten Streubefehls, welcher die Verwendung der Schreibmaske umfasst. In dieser Darstellung ist die Basisadresse rax (nicht gezeigt), und der Indexvektor/die Indexanordnung ist zmm8. Die Darstellung ist ein Beispiel für das Zusammenfügen von drei benachbarten Streuoperationen, d. h. Datenelemente aus einer Gruppe von drei Quelloperanden (zmm2, zmm 1 und zmm0) werden gemäß der Schreibmaske k1 in zusammenhängenden Speicher eingespeichert. Die Schreibmaske k1 hat einen hexadezimalen Wert von 0xA3. In dieser Darstellung sind der erste, der zweite und der dritte Quelloperand zmm2, zmm1 bzw. zmm0. Wieder beeinflusst dies die Reihenfolge der Datenelemente, die in den Speicherblock eingespeichert werden.
  • Die Ausführung des zusammengefügten Streubefehls bewirkt, dass die Sammel-/Streueinheit 208 eine erste Speicheradresse generiert und bestimmt, ob Schreibvorgang 0 ausgeführt werden soll. In einem Beispiel ist die erste Adresse die Basisadresse plus dem im ersten Index der Indexanordnung gespeicherten Wert (d. h. „rax+zmm8[0]““), welcher auf einen Speicherort des Anfangs des Blocks von zusammenhängendem Speicher zeigt, wo das erste Datenelement des ersten Quelloperandenregisters (zmm2[0]) gespeichert werden soll.
  • In einem Beispiel bestimmt die Sammel-/Streueinheit 208, ob die Datenelemente von Quelloperanden gemäß den Schreibmaskenbit-Werten in den Speicher eingespeichert werden sollen. In dieser Darstellung hat das erste (LSB) Bit der Schreibmaske, d. h. k1[0], den Wert „1“, was in einem Beispiel angibt, dass das erste (LSB) Datenelement jedes Quelloperanden gepackt und in zusammenhängenden Speicher eingespeichert werden soll. Infolgedessen werden Datenelemente von Quelloperanden {2, 1, 0} von zmm2[0], zmm 1 [0] bzw. zmm0[0] gepackt und als Block von zusammenhängendem Speicher gespeichert, beginnend an Speicherort „rax+zmm8 [0]“.
  • In ähnlicher Weise generiert die Sammel-/Streueinheit 208 eine zweite Adresse, die auf den Speicherort „rax+zmm8[1]" zeigt, und bestimmt, ob Schreibvorgang 1 ausgeführt werden soll. Ebenso wie k1[0] wird auch das Schreibmaskenbit k1[1] auf „1“ gesetzt; somit werden Datenelemente {12, 11, 10} von zmm2[1], zmm1[1] bzw. zmm0[0] gepackt und in einen zusammenhängenden Speicherblock beginnend an Speicherort „rax+zmm8[1]" eingespeichert.
  • Die Sammel-/Streueinheit 208 überspringt Schreibvorgang 2 in diesem Beispiel, weil anders als bei k1 [0] und k1[1] das Schreibmaskenbit k1[2] auf „0“ gesetzt ist, was in einem Beispiel angibt, dass das dritte Datenelement der Quelloperanden nicht in den Speicher eingespeichert werden soll. Infolgedessen werden zmm2[2], zmm1[2] und zmm0[2] nicht in Speicher geschrieben.
  • Die Sammel-/Streueinheit 208 führt dieselbe Logik durch wie vorstehend besprochen und bestimmt, dass Schreibvorgang 3, Schreibvorgang 4 und Schreibvorgang 6 übersprungen werden sollen, weil k1[3], k1[4] und k1[6] alle auf „0“ gesetzt sind. Darüber hinaus bestimmt die Sammel-/Streueinheit 208, dass Schreibvorgang 5 durchgeführt werden sollte, weil k1[5] auf „1'''' gesetzt ist, und speichert Datenelemente {52, 51, 50} von Quelloperanden zmm2[5], zmm1[5] und zmm0[5] in zusammenhängenden Speicher beginnend an der Adresse „rax+zmm8[5]". In gleicher Weise wird Schreibvorgang 7 durchgeführt, weil k1[7] auf „1“ gesetzt ist und Datenelemente {72, 71, 70} von Quelloperanden zmm2[7], zmm1[7] und zmm0[7] in zusammenhängenden Speicher beginnend an „rax+zmm8[7]" eingespeichert werden.
  • In der vorstehenden Erörterung werden benachbarte Sammel-/Streubefehle durch eine nichtbeanspruchte, neue ISA zusammengefügt. Es versteht sich jedoch, dass benachbarte Sammel-/Streuoperationen auch unter Verwendung der aktuellen ISA zusammengefügt werden können, indem diese Operationen „im Hintergrund“ kombiniert werden. So können beispielsweise die drei Sammelbefehle: vgatherqpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0007
     vgatherqpd zmm1 { k1 } , [ rax + zmm8 + 8 ]
    Figure DE112012007063B4_0008
     vgatherqpd zmm2 { k1 } , [ rax + zmm8 + 16 ]
    Figure DE112012007063B4_0009
    von der aktuellen SIMD-Hardware als einzelner zusammengefügter Sammelbefehl durchgeführt werden. In einem Beispiel müssen die drei vorstehend erwähnten Sammelbefehle, um als zusammengefügter Sammelbefehl kombiniert zu werden, dieselben Operanden aufweisen, d. h. Basis, Skala, Index und Schreibmaske. Darüber hinaus müssen die Befehle den richtigen Versatz/die richtige Verschiebung aufweisen. So muss beispielsweise der Versatz jedes Sammelbefehls ein Vielfaches der Größe des Datenelements sein, so dass sich jedes Datenelement eines Befehls zusammenhängend im Speicher neben dem Datenelement des vorhergehenden Befehls befindet. In einem Beispiel, wenn die vorstehend erwähnten Sammelbefehle empfangen werden, geht die Sammel-/Streueinheit 208 davon aus, dass diese Befehle zusammengefügt werden können, und gibt die kombinierten Lesevorgänge aus und prüft dann, vor dem Rückordnen der Befehle, auf Basis ihrer Operanden, ob die Befehle zusammengefügt werden können. Falls nicht, werden die Ergebnisse verworfen, und die Befehle werden als separate Sammelvorgänge erneut ausgeführt.
  • In einem Beispiel können die folgenden Streuoperationen in ähnlicher Weise „im Hintergrund“ zusammengefügt werden: vscatterqpd  [ rax + zmm8 + 0 ] { k1 } , zmm 0
    Figure DE112012007063B4_0010
     vscatterqpd  [ rax + zmm8 + 8 ] { k1 } , zmm1
    Figure DE112012007063B4_0011
     vscatterqpd  [ rax + zmm8 + 16 ] { k1 } , zmm2 .
    Figure DE112012007063B4_0012
  • Erfindungsgemäß werden benachbarte Sammel-/Streuoperationen unter Verwendung der aktuellen ISA zusammengefügt, indem ein Präfix zu den Befehlen hinzugefügt wird, um stark darauf hinzuweisen, dass diese Befehle verschmolzen/zusammengefügt werden. So können beispielsweise die Sammelbefehle: rep vgatherqpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0013
     repvgatherqpd zmm1 { k1 } , [ rax + zmm8 + 8 ]
    Figure DE112012007063B4_0014
     vgatherqpd zmm2 { k1 } , [ rax + zmm8 + 16 ]
    Figure DE112012007063B4_0015
    von der SIMD-Hardware als einzelner zusammengefügter Sammelbefehl durchgeführt werden. In dieser erfindungsgemäßen Ausführungsform sichert das Präfix „rep“ der Hardware zu, dass weitere Sammelbefehle anstehen, die zusammengefügt werden können, und dass die Hardware die ersten paar Befehle puffern soll, bis der letzte Befehl (welcher kein Präfix aufweist) ankommt. In ähnlicher Weise können die folgenden stark angedeuteten Sammelbefehle zusammengefügt werden: repvscatterqpd  [ rax + zmm8 + 0 ] { k1 } , zmm 0
    Figure DE112012007063B4_0016
     repvscatterqpd  [ rax + zmm8 + 8 ] { k1 } , zmm1
    Figure DE112012007063B4_0017
     vscatterqpd  [ rax + zmm8 + 16 ] { k1 } , zmm2 .
    Figure DE112012007063B4_0018
  • - veranschaulicht ein anderes Beispiel für das Zusammenfügen benachbarter Sammelbefehle unter Verwendung der aktuellen ISA. In diesem Beispiel wird der erste Sammelbefehl an die Sammel-/Streueinheit 208 gesendet, welche davon ausgeht, dass es sich um den ersten von drei zusammenhängenden Sammelbefehlen handelt. In diesem Beispiel sind die Datenelemente jeweils 8 Byte breit (Einheit mit doppelter Genauigkeit), und da die Zieloperanden zmm0, zmm1 und zmm2 jeweils 512 Bit breit sind, gibt es acht Datenelemente, die für jeden Zieloperanden aus dem Speicher zu sammeln sind. Für jedes zu sammelnde Datenelement ruft die Sammel-/Streueinheit 208 wenigstens acht Bytes (die Größe eines Datenelements) aus dem Speicher ab, aber die Einheit wird versuchen, bis zu sechzehn weitere Bytes (zwei weitere Werte mit doppelter Genauigkeit) abzurufen, ohne über das Ende der Cachezeile hinauszugehen. Die Sammel-/Streueinheit 208 speichert das erste Datenelement in den ersten Zieloperanden und so viele Datenelemente, wie sie aus dem Speicher auslesen kann, in die entsprechenden Datenelemente der verbleibenden Zieloperanden ein. In dem anderen Beispiel kann die Sammel-/Streueinheit 208 die Datenelemente in einem Puffer speichern und die Daten aus dem Puffer in die Zielregister kopieren, wenn die Befehle rückgeordnet werden. In diesem Beispiel hält die Sammel-/Streueinheit 208 auch nach, welche Datenelemente der Zieloperanden nicht aktualisiert wurden, weil sich die Datenelemente in einer anderen Cachezeile befanden. In diesem Beispiel kann die Sammel-/Streueinheit 208 auch einen Signatur-Cache pflegen, der festhält, wie der aktuelle Sammelbefehl aussieht, z. B. wie viele Datenelemente es gibt, wie deren Größe ist, welche Basis und Indexregister verwendet wurden und welche unmittelbare Skalierung und welcher Versatz zur Basis gegeben sind.
  • Es wird nun Bezug genommen auf ; der erste Speicherlesevorgang des ersten Sammelbefehls wird durchgeführt. In diesem Beispiel kann der erste Speicherblock aller drei Datenelemente in derselben Cachezeile gelesen werden, und die Sammel-/Streueinheit 208 ist in der Lage, das erste Datenelement aller drei Zieloperanden (zmm0[0], zmm1[0] und zmm2[0]) zu aktualisieren.
  • veranschaulicht, dass der Speicherlesevorgang durch die Sammel-/Streueinheit 208 für das zweite Datenelement der Zieloperanden nicht den gesamten Block mit 3 Datenelementen erzeugt. Insbesondere befindet sich das dritte Datenelement des Blocks in einer anderen Cachezeile. Infolgedessen wird nur das zweite Datenelement der ersten zwei Zieloperanden (zmm0[1] und zmm1[1]) mit Datenelementen aus dem Speicher aktualisiert, und das zweite Datenelement des dritten Zieloperanden (zmm2[1]) wird nicht aktualisiert.
  • veranschaulicht, dass die Sammel-/Streueinheit 208 in der Lage ist, den gesamten Speicherblock mit 3 Datenelementen während des dritten Speicherlesevorgangs zu lesen. Infolgedessen wird das dritte Datenelement jedes Zieloperanden aktualisiert.
  • veranschaulicht, dass der vierte Speicherlesevorgang nur einen einzelnen Wert mit doppelter Genauigkeit ausgibt, weil sich das zweite und das dritte Datenelement in einer anderen Cachezeile befinden. Somit wird nur das vierte Datenelement des ersten Zieloperanden (zmm0[3]) aktualisiert.
  • veranschaulicht, dass nach vier weiteren Speicherlesevorgängen alle acht Datenelemente des ersten Zieloperanden (zmm0) aktualisiert sind. Allerdings sind zmm1[3], zmm1[6], zmm2[1], zmm2[3], zmm2[5] und zmm2[6] nicht aktualisiert worden, aufgrund der Tatsache, dass sich deren zugehörige Datenelemente in unterschiedlichen Cachezeilen befanden.
  • veranschaulicht, dass, sobald der erste Sammelbefehl abgeschlossen ist, d. h. wenn alle Datenelemente von zmm0 aktualisiert worden sind, der Befehl rückgeordnet wird und der nächste Sammelbefehl verarbeitet wird.
  • veranschaulicht, wie die Sammel-/Streueinheit 208 den zweiten Sammelbefehl verarbeitet, indem die Einheit einen Speicherlesevorgang für das vierte Datenelement des zweiten Zieloperanden (zmm1[3]) durchführt. Die Sammel-/Streueinheit 208 überspringt die Speicherlesevorgänge für die ersten drei Datenelemente von zmm1, weil diese Datenelemente, wie vorstehend besprochen, bereits während des Aktualisierens von zmm0 aktualisiert wurden. Es sei außerdem darauf hingewiesen, dass sich in dieser Abbildung das vierte Datenelement des dritten Zieloperanden (zmm2[3]) in derselben Cachezeile befindet und somit zmm2[3] ebenfalls aktualisiert wird.
  • veranschaulicht, wie die Sammel-/Streueinheit 208 den letzten Speicherlesevorgang durchführt, um das Aktualisieren von zmm1 abzuschließen; anschließend wird der zweite Sammelbefehl rückgeordnet. Obwohl dies nicht dargestellt ist, aktualisiert die Sammel-/Streueinheit 208 auch die verbleibenden Datenelemente von zmm2 unter Verwendung ähnlicher Prozeduren wie vorstehend besprochen und bewirkt das Rückordnen des dritten Sammelbefehls.
  • In einem anderen Beispiel werden benachbarte Sammel- und Streubefehle zusammengefügt, indem partielle Sammel-/Streubefehle transponiert werden. Wie vorstehend besprochen, erfordert das Sammeln einer 2-Elemente-Struktur aus acht Indizes derzeit zwei Sammelbefehle: vgatherqpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0019
     vgatherqpd zmm 0 { k2 } , [ rax + zmm8 + 8 ]
    Figure DE112012007063B4_0020
  • Angenommen, es gilt k1=k2= alle „1“, dann betrachtet jeder dieser Befehle alle acht Indizes in zmm8 und führt einen einzelnen 8-Byte-Ladevorgang durch. Dies hat sechzehn Cachezeilenzugriffe zur Folge, was doppelt so viel ist wie erforderlich. In der nachfolgenden Erörterung wird die Namenskonvention x,y,z,w für Datenelemente verwendet, und das Kürzel „x0“ bedeutet „der Wert mit doppelter Genauigkeit an Adresse rax+zmm8[0]+0“. In ähnlicher Weise steht „y3“ für „der Wert mit doppelter Genauigkeit an Adresse rax+zmm8[3]+8“. Ausgehend von dieser Namenskonvention produziert die Ausführung der vorstehend erwähnten Sammelbefehle die folgenden Ergebnisse:
    Zmm0 x0 x1 x2 x3 x4 x5 x6 x7
    Zmm1 y0 y1 y2 y3 y4 y5 y6 y7
  • In einem Beispiel wird ein „partieller“ Sammelvorgang durchgeführt, der nur einige der Indizes verwendet, aber dafür mehr Daten pro Index laden kann. Dies kann als ein Paar von partiellen Sammelbefehlen veranschaulicht werden: vgatherp0123qpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0021
     vgatherp4567qpd zmm1 { k2 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0022
  • Der Teil „0123“ des ersten Befehls zeigt der Sammel-/Streueinheit 208 an, dass der Befehl nur die ersten vier Indizes von zmm8 verwendet und die ersten vier Bits der Schreibmaske k1. In ähnlicher Weise zeigt „4567“ im zweiten Befehl an, dass der Befehl nur die zweiten vier Indizes und Schreibmaskenbits verwendet. Somit sind dies die Ergebnisse:
    Zmm0 x0 x1 x2 x3 y0 y1 y2 y3
    Zmm 1 y4 y5 y6 y7 x4 x5 x6 x7
  • Der Grund für die ungerade Reihenfolge der Ergebnisse wird nachstehend ausführlicher erläutert.
  • veranschaulicht den Pseudocode für die Operation vgatherp0123qpd. Falls Ladevorgang 128 fehlschlägt, wird dieser Vorgang durch dieselben Fehlerbehandlungsmechanismen gehandhabt wie dies bei den bestehenden Sammeloperationen der Fall ist. Ebenso wie bei den standardmäßigen Sammeloperationen ist es wichtig, die Schreibmaskenbits zu löschen, wenn Ladevorgänge durchgeführt werden, so dass der Befehl durch das Betriebssystem (BS) nach dem Fehler neu gestartet werden kann.
  • veranschaulicht den Pseudocode für die Operation vgatherp4567qpd, der dem Pseudocode für vgatherp0123qpd ähnelt; die Unterschiede sind hervorgehoben. Der Vorteil der Verwendung dieser zwei neuen Befehle besteht darin, dass die Sammel-/Streueinheit 208 in der Lage ist, halb so viele Lesevorgänge (acht statt sechzehn) durchzuführen, auch wenn jeder Lesevorgang die doppelte Größe hat (128 Bits statt 64). Somit ist es möglich, die Sequenz nahezu doppelt so schnell zu durchlaufen.
  • Das Vorstehende ist eine Beschreibung einer 2-Element-Struktur. Das Äquivalent für eine 4-Element-Struktur ist ähnlich: vgatherp01qpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0023
     vgatherp23qpd zmm1 { k2 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0024
     vgatherp34qpd zmm2 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0025
     vgatherp67qpd zmm3 { k2 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0026
  • Jeder der vorstehend angeführten partiellen Sammelbefehle führt nur zwei Lesevorgänge durch, aber jeder Lesevorgang hat eine Größe von 256 Bits. Die Ergebnisse sehen wie folgt aus:
    Zmm0 x0 x1 y0 y1 z0 z1 w0 w1
    Zmm 1 w2 w3 x2 x3 y2 y3 z2 z3
    Zmm2 z4 z5 w4 w5 x4 x5 y4 y5
    Zmm3 y6 y7 z6 z7 w6 w7 x6 x7
  • Die - veranschaulichen den Pseudocode für die partiellen Sammelbefehle vgatherp01qpd, vgatherp23qpd, vgatherp34qpd bzw. vgatherp67qpd.
  • Einer der Vorteile der vorstehend erwähnten partiellen Sammeloperationen besteht darin, dass diese Operationen die Anzahl der Speicherzugriffe reduzieren. Allerdings besteht der Nachteil darin, dass die in die Vektorregister geschriebenen Datenelemente nicht im Format vorliegen, das für die Standard-Vektorarithmetik zweckmäßig ist. In einem Beispiel kann diese Formatierungsunregelmäßigkeit durch die bestehenden Misch-/Permutationsoperationen in der ISA gelöst werden. Es ist eindeutig möglich, die 2-Element-Transponierung mit 4 VPERMD-Befehlen mit den entsprechenden Schreibmasken und die 4-Element-Transponierung in 16 VPERMD-Befehlen mit Schreibmasken durchzuführen. Alternativ kann der neuere VPERMI2W-Befehl Daten aus Registerquellen permutieren, was dazu genutzt werden, die Anzahl der erforderlichen Befehle zu halbieren.
  • Selbst wenn diese vorhandenen Permutationsbefehle verwendet werden, kann die neue Folge von Sammelbefehlen wegen der signifikanten Reduktion von Speicherzugriffen eine bessere Leistung erzielen als die vorhandenen Folgen.
  • In einem Beispiel werden die neuen Spezialbefehle verwendet, um die Transponierung in nur zwei oder vier Befehlen durchzuführen, indem die Vorteile genutzt werden, die sich durch die Tatsache ergeben, dass die VPUs als vier „Bänke“ von ALUs und Registerdateiblöcken ausgeführt sind, von denen jede Bank 128 Bits des Ergebnisses verarbeitet. Das bedeutet, dass jede Bank ein von der benachbarten Bank abweichendes Quellregister auslesen kann, was es der Sammel-/Streueinheit 208 ermöglicht, Teile von bis zu vier Registern auszulesen, während nur ein einzelner Leseport pro Bank verwendet wird. Dies ermöglicht es einem einzelnen Transponierbefehl, Daten aus allen vier Registern auszulesen und dann das kombinierte temporäre 512-Bit-Ergebnis an die Mischeinheit („GENMUX“ genannt) zu senden, um die Daten in der richtigen Reihenfolge neu zu ordnen.
  • Die und veranschaulichen den Aufbau der Zieloperanden zmm0 und zmm1 durch Transponieren der Ergebnisse der partiellen Sammelvorgänge. Es wird Bezug genommen auf ; die GENMUX-Einheit braucht keine Permutation durchzuführen, da die Daten bereits in der richtigen Reihenfolge vorliegen. Allerdings müssen die Y-Komponenten wie in gezeigt permutiert werden, um die richtige Reihenfolge der Datenelemente für zmm1 zu produzieren. Die Z- und W-Komponenten können in ähnlicher Weise permutiert werden, um zmm2 und zmm3 zu produzieren.
  • In einem Beispiel sind diese Operationen als mehrere Befehle mit fest programmierter Auswahl und Permutationsteuerungen spezifiziert. In einem anderen Beispiel sind die Operationen flexibler spezifiziert, wobei die Steuerungen aus Direktwerten oder aus Registern stammen. Der Einfachheit halber zeigen wir diese Operationen hier als fest programmierte diskrete Befehle.
  • Die Verwendung dieser Transponierbefehle ermöglicht es, die vollständige Operation Sammeln+Transponieren schnell durchzuführen. Die 2-Komponenten-Version erfordert zwei Sammelbefehle und zwei Transponierbefehle: vgatherp0123qpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0027
     vgatherp4567qpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0028
     vtranspose0123pd zmm 10, zmm 0, zmm1
    Figure DE112012007063B4_0029
     vtranspose4567pd zmm 11, zmm 0, zmm1 .
    Figure DE112012007063B4_0030
  • Die 4-Komponenten-Version erfordert vier Sammelbefehle und vier Transponierbefehle: v gatherp01qpd zmm 0 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0031
     vgatherp23qpd zmm1 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0032
     vgatherp45qpd zmm2 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0033
     vgatherp67qpd zmm3 { k1 } , [ rax + zmm8 + 0 ]
    Figure DE112012007063B4_0034
     vtranspose01pd zmm 10, zmm 0, zmm1 ,zmm 2, zmm 3
    Figure DE112012007063B4_0035
     vtranspose23pd zmm 11, zmm 0, zmm1 ,zmm 2, zmm 3
    Figure DE112012007063B4_0036
     vtranspose45pd zmm 12, zmm 0, zmm1 ,zmm 2, zmm 3
    Figure DE112012007063B4_0037
     vtranspose67pd zmm 13, zmm 0, zmm1 ,zmm 2, zmm 3
    Figure DE112012007063B4_0038
  • Ein Befehlssatz oder eine Befehlssatzarchitektur (Instruction Set Architecture, ISA) ist der Teil der Computerarchitektur, der sich auf die Programmierung bezieht, und kann die nativen Datentypen, Befehle, die Registerarchitektur, Adressiermodi, die Speicherarchitektur, Interrupts und die Ausnahmehandhabung sowie externe Eingaben und Ausgaben (E/A) umfassen. Der Begriff Befehl bezieht sich hier allgemein auf Makrobefehle - das heißt Befehle, die für den Prozessor bereitgestellt werden (oder für den Befehlsumwandler, der einen Befehl zur Ausführung in einen oder mehrere andere Befehle übersetzt (d. h. durch statische binäre Übersetzung, dynamische binäre Übersetzung einschließlich dynamischer Kompilierung), umformt, emuliert oder in anderer Weise für die Ausführung durch den Prozessor umwandelt) - im Gegensatz zu Mikrobefehlen oder Mikrooperationen (Mikro-Ops) - das heißt das Ergebnis des Decodierers eines Prozessors, welcher Makrobefehle decodiert.
  • Die ISA unterscheidet sich von der Mikroarchitektur, bei der es sich um den internen Aufbau des Prozessors handelt, der den Befehlssatz implementiert. Prozessoren mit unterschiedlichen Mikroarchitekturen können einen gemeinsamen Befehlssatz teilen. So implementieren beispielsweise Intel® Pentium 4-Prozessoren, Intel® Core™-Prozessoren und Prozessoren von Advanced Micro Devices, Inc. aus Sunnyvale (CA) nahezu identische Versionen des x86-Befehlssatzes (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt worden sind), weisen aber unterschiedliche interne Aufbauten auf. Beispielsweise kann dieselbe Registerarchitektur der ISA in unterschiedlichen Mikroarchitekturen unter Verwendung bekannter Verfahren auf verschiedene Arten implementiert sein; hierzu zählen dedizierte physische Register, ein oder mehrere unter Verwendung eines Registerumbenennungsmechanismus dynamisch zugewiesene physische Register (z. B. durch die Verwendung einer Register-Alias-Tabelle (RAT), eines Neuordnungspuffers (Reorder Buffer, ROB) und einer Rückordnungsregisterdatei; die Verwendung mehrerer Maps und eines Registerpools) etc. Sofern nicht anders angegeben, beziehen sich die hier verwendeten Formulierungen Registerarchitektur, Registerdatei und Register auf das, was für die Software/den Programmierer sichtbar ist und die Art und Weise, in der Befehle Register spezifizieren. Dort, wo Spezifität erwünscht ist, wird das Adjektiv logisch, architektonisch oder software-sichtbar verwendet, um Register/Dateien in der Registerarchitektur anzuzeigen, während andere Adjektive verwendet werden, um Register in einer gegebenen Mikroarchitektur zu bezeichnen (z. B. physische Register, Neuordnungspuffer, Rückordnungsregister, Register-Pool).
  • Ein Befehlssatz umfasst ein oder mehrere Befehlsformate. Ein gegebenes Befehlsformat definiert verschiedene Felder (Anzahl Bits, Bitposition), um unter anderem die durchzuführende Operation (Opcode) und den Operanden bzw. die Operanden zu spezifizieren, für die diese Operation durchgeführt werden soll. Einige Befehlsformate sind durch die Definition von Befehlsvorlagen (oder Unterformaten) noch weiter aufgegliedert. So können beispielsweise die Befehlsvorlagen eines gegebenen Befehlsformats so definiert sein, dass sie unterschiedliche Untermengen der Felder des Befehlsformats aufweisen (die eingeschlossenen Felder liegen typischerweise in derselben Reihenfolge vor, aber wenigstens einige Felder weisen unterschiedliche Bitpositionen auf, weil weniger Felder eingeschlossen sind) und/oder so definiert sein, dass bei ihnen ein gegebenes Feld anders interpretiert wird. Somit wird jeder Befehl einer ISA unter Verwendung eines gegebenen Befehlsformats ausgedrückt (und, falls definiert, in einer gegebenen Vorlage der Befehlsvorlagen dieses Befehlsformats) und weist Felder für das Spezifizieren der Operation und der Operanden auf. So weist beispielsweise eine ADD-Anweisung einen spezifischen Opcode und ein Befehlsformat auf, das ein Opcode-Feld einschließt, um zu spezifizieren, dass der Opcode und die Operandenfelder Operanden auswählen (quellel/ziel und quelle2); und ein Auftreten dieses ADD-Befehls in einem Befehlsstrom weist spezifische Komponenten in den Operandenfeldern auf, die spezifische Operanden auswählen.
  • Wissenschaftliche, finanztechnische-, autovektorisierte Universal-, RMS- (Recognition, Mining & Synthesis) sowie visuelle und Multimedia-Anwendungen (z. B. 2D/3D-Grafiken, Bildverarbeitung, Videokompression/-dekompression, Spracherkennungsalgorithmen und Audiobearbeitung) erfordern oft, dass ein und dieselbe Operation für eine große Anzahl von Datenpositionen durchgeführt wird (was als „Datenparallelismus“ bezeichnet wird). Single Instruction Multiple Data (SΠVVID) bezieht sich auf eine Art von Befehl, der einen Prozessor veranlasst, eine Operation für mehrere Datenpositionen durchzuführen. Die SIMD-Technologie eignet sich insbesondere für Prozessoren, die Bits in einem Register logisch in eine Anzahl von Datenelementen mit fester Größe aufteilen können, wobei jedes dieser Datenelemente einen separaten Wert darstellt. So können beispielsweise die Bits in einem 256-Bit-Register als ein Quelloperand spezifiziert werden, für den Operationen als vier separate 64-Bit-gepackte Datenelemente (Vierwort-Datenelement (Q)), acht separate 32-Bit-gepackte Datenelemente (Doppelwort-Datenelemente (D)), sechzehn separate 16-Bit-gepackte Datenelemente (Einwort-Datenelemente (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Byte-Datenelemente (B)) durchgeführt werden sollen. Diese Art von Daten wird als gepackter Datentyp oder Vektordatentyp bezeichnet, und Operanden dieses Datentyps werden als gepackte Datenoperanden oder Vektoroperanden bezeichnet. Mit anderen Worten bezeichnet eine gepackte Datenposition oder ein Vektor eine Folge von gepackten Datenelementen, und ein gepackter Datenoperand oder ein Vektoroperand ist ein Quell- oder Zieloperand eines SIMD-Befehls (auch gepackter Datenbefehl oder Vektorbefehl genannt).
  • Beispielsweise spezifiziert eine Art von SIMD-Befehl eine einzelne Vektoroperation, die für zwei Quellvektoroperanden in einer vertikalen Weise durchgeführt werden soll, um einen Zielvektoroperanden (auch Ergebnisvektoroperand genannt) derselben Größe, mit derselben Anzahl von Datenelementen und in derselben Datenelementfolge zu generieren. Die Datenelemente in den Quellvektoroperanden werden als Quelldatenelemente bezeichnet, während die Datenelemente im Zielvektoroperand als Ziel- oder Ergebnisdatenelemente bezeichnet werden. Diese Quellvektoroperanden haben dieselbe Größe und enthalten Datenelemente derselben Breite und enthalten somit dieselbe Anzahl von Datenelementen. Die Quelldatenelemente an denselben Bitpositionen in den zwei Quellvektoroperanden bilden Paare von Datenelementen (auch als entsprechende Datenelemente bezeichnet; das heißt, die Datenelemente an Datenelementposition 0 jedes Quelloperanden entsprechen einander, die Datenelemente an Datenelement-Position 1 jedes Quelloperanden entsprechen einander und so weiter). Die durch diesen SIMD-Befehl spezifizierte Operation wird für jedes dieser Paare von Quelldatenelementen getrennt durchgeführt, um eine entsprechende Anzahl von Ergebnisdatenelementen zu generieren, und somit gibt es zu jedem Paar von Quelldatenelementen ein entsprechendes Ergebnisdatenelement. Da die Operation vertikal erfolgt und da der Ergebnisvektoroperand dieselbe Größe hat, dieselbe Anzahl von Datenelementen aufweist und die Ergebnisdatenelemente in derselben Datenelementreihenfolge gespeichert sind wie die Quellvektoroperanden, befinden sich die Ergebnisdatenelemente an denselben Bitpositionen des Ergebnisvektoroperanden wie ihr entsprechendes Paar von Quelldatenelementen in den Quellvektoroperanden. Zusätzlich zu dieser Art von SIMD-Befehl gibt es verschiedene andere Arten von SIMD-Befehlen (z. B. solche, die nur einen oder mehr als zwei Quellvektoroperanden aufweisen, die in einer horizontalen Weise arbeiten, die einen Ergebnisvektoroperanden generieren, die eine unterschiedliche Größe haben, die Datenelemente mit einer unterschiedlichen Größe haben und/oder die eine andere Reihenfolge der Datenelemente aufweisen). An dieser Stelle sei angemerkt, dass der Begriff Zielvektoroperand (oder Zieloperand) als das direkte Ergebnis des Durchführens der Operation definiert ist, spezifiziert durch einen Befehl, einschließlich der Speicherung des betreffenden Zieloperanden an einem Ort (sei es ein Register oder an einer durch den betreffenden Befehl spezifizierten Speicheradresse), so dass von einem anderen Befehl (durch Spezifikation desselben Ortes durch den anderen Befehl) hierauf als Quelloperand zugegriffen werden kann.
  • Die SIMD-Technologie, beispielsweise die von den Intel® Core™-Prozessoren eingesetzte Technologie mit einem Befehlssatz wie x86, MMX™, Streaming SIMD Extensions (SSE), SSE2, SSE3, SSE4.1 und SSE4.2-Befehlen, hat eine signifikante Verbesserung hinsichtlich der Anwendungsleistung ermöglicht. Ein zusätzlicher Satz von SIMD-Erweiterungen, die als Advanced Vector Extensions (AVX) (AVX1 und AVX2) bezeichnet werden und das Codierschema Vector Extensions (VEX) verwenden, ist freigegeben und/oder veröffentlicht worden (siehe z. B. Intel® 64 und IA-32 Architectures Software Developers Manual, Oktober 2011; und siehe Intel® Advanced Vector Extensions Programming Reference, Juni 2011).
  • Beispiele des hier beschriebenen Befehls bzw. der hier beschriebenen Befehle können in unterschiedlichen Formaten ausgeführt sein. Zusätzlich werden beispielhafte Systeme, Architekturen und Pipelines nachstehend ausführlich beschrieben. Ausführungsformen des Befehls bzw. der Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sie sind jedoch nicht auf die genannten Systeme, Architekturen und Pipelines beschränkt.
  • Die VEX-Codierung macht es möglich, dass Befehle mehr als zwei Operanden aufweisen können, und macht es möglich, dass SIMD-Vektorregister länger als 128 Bit sein können. Die Verwendung eines VEX-Präfixes sieht eine Syntax mit drei (oder mehr) Operanden vor. So führten beispielsweise die vorstehenden Befehle mit zwei Operanden Operationen wie A = A + B durch, die einen Quelloperanden überschreibt. Die Verwendung eines VEX-Präfixes ermöglicht es Operanden, nichtdestruktive Operationen wie A = B + C durchzuführen.
  • veranschaulicht ein AVX-Befehlsformat, das ein VEX-Präfix 2102, ein reales Opcode-Feld 2130, ein Mod R/M-Byte 2140, ein SIB-Byte 2150, ein Verschiebungsfeld 2162 und IMM8 2172 aufweist. veranschaulicht, welche Felder aus ein vollständiges Opcode-Feld 2174 und ein Basisoperationsfeld 2142 bilden. veranschaulicht, welche Felder aus ein Registerindexfeld 2144 bilden.
  • Das VEX-Präfix (Bytes 0-2) 2102 ist in einer Drei-Byte-Form codiert. Das erste Byte ist das Formatfeld 2140 (VEX-Byte 0, Bits [7:0]), welches einen expliziten C4-Byte-Wert enthält (den für das Unterscheiden des C4-Befehlsformats verwendeten eindeutigen Wert). Die zweitendritten Bytes (VEX-Bytes 1-2) umfassen eine Anzahl von Bitfeldern, die eine spezifische Funktionalität bereitstellen. Insbesondere das REX-Feld 2105 (VEX-Byte 1, Bits [7-5]) besteht aus einem VEX.R- Bitfeld (VEX-Byte 1, Bit [7] - R), einem VEX.X- Bitfeld (VEX-Byte 1, Bit [6] - X) und einem VEX.B- Bitfeld (VEX-Byte 1, Bit [5] - B). Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes nach dem Stand der Technik (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von VEX.R, VEX.X und VEX.B gebildet werden können. Das Opcode-Map-Feld 2115 (VEX-Byte 1, Bits [4:0] - mmmmm) schließt Inhalt zum Codieren eines implizierten führenden Opcode-Bytes ein. Das W-Feld 2164 (VEX-Byte 2, Bit [7] - W) - ist durch die Bezeichnung VEX.W dargestellt und stellt je nach Befehl unterschiedliche Funktionen bereit. Die Rolle von VEX.vvvv 2120 (VEX-Byte 2, Bits [6:3]-vvvv) kann Folgendes umfassen: 1) VEX.vvvv codiert den ersten Quellregisteroperanden, spezifiziert in invertierter Form (1er-Komplement) und gilt für Befehle mit 2 oder mehr Quelloperanden; 2) VEX.vvvv codiert den Zielregisteroperanden, spezifiziert in 1er-Komplementform für bestimmte Vektorverschiebungen; oder 3) VEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Falls das Größenfeld VEX.L 2168 (VEX-Byte 2, Bit[2]-L) = 0 ist, zeigt dies einen 128-Bit-Vektor an; falls VEX.L = 1 ist, zeigt dies einen 256-Bit-Vektor an. Das Präfixcodierfeld 2125 (VEX-Byte 2, Bits [1:0]-pp) stellt zusätzliche Bits für das Basisoperationsfeld bereit.
  • Das reale Opcode-Feld 2130 (Byte 3) wird auch Opcode-Byte genannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert. Das MOD-R/M-Feld 2140 (Byte 4) umfasst das MOD-Feld 2142 (Bits [7-6]), das Reg-Feld 2144 (Bits [5-3]) und das R/M-Feld 2146 (Bits [2-0]). Die Rolle des Reg-Feldes 2144 kann Folgendes umfassen: Codieren des Zielregisteroperanden oder eines Quellregisteroperanden (rrr-Teil von Rrrr) oder Handhabung als eine Opcode-Erweiterung und Nichtverwendung für das Codieren irgendeines Befehlsoperanden. Die Rolle des R/M-Feldes 2146 kann Folgendes umfassen: Codieren des Befehlsoperanden, der eine Speicheradresse referenziert, oder Codieren des Zielregisteroperanden oder eines Quellregisteroperanden.
  • Skala, Index, Basis (SIB) - Der Inhalt des Skalierfeldes 2150 (Byte 5) schließt SS2152 (Bits [7-6]) ein, was für die Generierung der Speicheradresse verwendet wird. Die Inhalte von SIB.xxx 2154 (Bits [5-3]) und SIB.bbb 2156 (Bits [2-0]) sind zuvor unter Bezugnahme auf die Registerindizes Xxxx und Bbbb angesprochen worden. Das Verschiebungsfeld 2162 und das unmittelbare Feld (IMM8) 2172 enthalten Adressdaten.
  • Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (z. B. gibt es bestimmte Felder, die für Vektoroperationen spezifisch sind). Obwohl hier Beispiele beschrieben werden, in denen sowohl Vektoroperationen als auch skalare Operationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Beispiele nur Vektoroperationen mit dem vektorfreundlichen Befehlsformat.
  • , und sind Blockschaltbilder, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon veranschaulichen. ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon veranschaulicht, während ein Blockschaltbild ist, welches das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon veranschaulicht. Insbesondere ein generisches vektorfreundliches Befehlsformat 2200, für das Befehlsvorlagen der Klasse A und Klasse B definiert sind, die beide Befehlsvorlagen ohne Speicherzugriff 2205 und Befehlsvorlagen mit Speicherzugriff 2220 umfassen. Der Begriff generisch im Zusammenhang des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat nicht an einen spezifischen Befehlssatz gebunden ist.
  • Obwohl hier Beispiele beschrieben werden, bei denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine Vektoroperandenlänge (oder -größe) von 64 Byte mit 32 Bit (4 Byte) oder 64 Bit (8 Byte) Datenelementbreite (oder -größe) (womit ein 64-Byte-Vektor aus entweder 16 Doppelwort-Elementen oder alternativ aus 8 Vierwort-Elementen besteht); eine Vektoroperandenlänge (oder -größe) von 64 Byte mit 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreite (oder -größe); eine Vektoroperandenlänge (oder -größe) von 32 Byte mit 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreite (oder -größe); und eine Vektoroperandenlänge (oder Größe) von 16 Byte mit 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreite (oder -größe); können alternative Beispiele mehr, weniger und/oder andere Vektoroperandengrößen (z. B. Vektoroperanden mit 256 Byte) mit mehr, weniger oder anderen Datenelementbreiten (z. B. 128 Bit (16 Byte) Datenelementbreite) unterstützen.
  • Die Befehlsvorlagen der Klasse A in umfassen: 1) in den Befehlsvorlagen ohne Speicherzugriff 2205 werden eine Befehlsvorlage für Operationen des Typs vollständige Rundungssteuerung 2210 ohne Speicherzugriff gezeigt und eine Befehlsvorlage für Operationen des Typs Datentransformation ohne Speicherzugriff 2215; und 2) in den Befehlsvorlagen mit Speicherzugriff 2220 werden eine Befehlsvorlage für temporäre Speicherzugriffe 2225 und eine Befehlsvorlage für nicht-temporäre Speicherzugriffe 2230 gezeigt. Die Befehlsvorlagen der Klasse B in umfassen: 1) in den Befehlsvorlagen ohne Speicherzugriff 2205 werden eine Befehlsvorlage für eine Operation des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 2212 und eine Befehlsvorlage für eine Operation des Typs VSIZE ohne Speicherzugriff mit Schreibmaskensteuerung 2217 gezeigt; und 2) in den Befehlsvorlagen mit Speicherzugriff 2220 wird eine Befehlsvorlage für die Schreibmaskensteuerung mit Speicherzugriff 2227 gezeigt.
  • Das generische vektorfreundliche Befehlsformat 2200 umfasst die nachstehend aufgelisteten Felder in der Reihenfolge wie in und dargestellt. Formatfeld 2240 - ein spezifischer Wert (ein Befehlsformat-Kennungswert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und somit Vorkommnisse von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Als solches ist dieses Feld in dem Sinne optional, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht benötigt wird. Basisoperationsfeld 2242 - der Inhalt dieses Feldes unterscheidet verschiedene Basisoperationen.
  • Registerindexfeld 2244 - der Inhalt dieses Feldes spezifiziert, direkt oder durch Adressengenerierung, die Orte der Quell- und Zieloperanden, ganz gleich, ob sie sich in Registern oder im Speicher befinden. Diese Operanden umfassen eine ausreichende Anzahl von Bits zum Auswählen von N Registern aus einer PxQ-Registerdatei (z. B. 32x512, 16x128, 32x1024, 64x1024). Während in einem Beispiel N bis zu drei Quellen und ein Zielregister sein kann, können alternative Beispiele mehr oder weniger Quellen und Zielregister unterstützen (z. B. können bis zu zwei Quellen unterstützt werden, wobei eine dieser Quellen zugleich als Ziel fungieren kann, bis zu drei Quellen, wobei eine dieser Quellen zugleich als Ziel fungieren kann, bis zu zwei Quellen und ein Ziel).
  • Modifiziererfeld 2246 - der Inhalt dieses Feldes unterscheidet Vorkommnisse von Befehlen im generischen vektorfreundlichen Befehlsformat, die Speicherzugriffe spezifizieren, von solchen, bei denen dies nicht der Fall ist; das heißt, zwischen Befehlsvorlagen ohne Speicherzugriff 2205 und Befehlsvorlagen mit Speicherzugriff 2220. Speicherzugriffsoperationen lesen und/oder schreiben in der/die Speicherhierarchie (und spezifizieren in einigen Fällen die Quell- und/oder die Zieladressen mithilfe von Werten in Registern), während Operationen ohne Speicherzugriff dies nicht tun (z. B. sind Quelle und Ziele Register). Während dieses Feld in einem Beispiel auch zwischen drei verschiedenen Arten der Durchführung von Speicheradressberechnungen wählt, können alternative Beispiele mehr, weniger oder andere Arten unterstützen, Speicheradressberechnungen durchzuführen.
  • Erweiterungsoperationsfeld 2250 - der Inhalt dieses Feldes unterscheidet, welche von mehreren verschiedenen Operationen zusätzlich zur Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. In einem Beispiel ist dieses Feld in ein Klassenfeld 2268, ein Alphafeld 2252 und ein Betafeld 2254 unterteilt. Das Erweiterungsoperationsfeld 2250 ermöglicht es, gängige Gruppen von Operationen in einem einzigen Befehl anstatt in 2, 3 oder 4 Befehlen durchzuführen. Skalierfeld 2260 - der Inhalt dieses Feldes ermöglicht das Skalieren des Indexfeldinhalts für die Speicheradressengenerierung (z. B. für die Adressengenerierung, die 2skalierung * index + basis verwendet).
  • Verschiebungsfeld 2262A - der Inhalt dieses Feldes wird im Rahmen der Speicheradressengenerierung verwendet (z. B. für eine Adressengenerierung, die 2skalierung * index + basis + verschiebung verwendet). Verschiebungsfaktorfeld 2262B (es sei darauf hingewiesen, dass die Darstellung von Verschiebungsfeld 2262A direkt über Verschiebungsfaktorfeld 2262B angibt, dass entweder das eine oder das andere verwendet wird) - der Inhalt dieses Feldes wird im Rahmen der Adressengenerierung verwendet; er spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) zu skalieren ist - wobei N die Anzahl Bytes im Speicherzugriff ist (z. B. für eine Adressengenerierung, die 2skalierung * index + basis + skalierte Verschiebung verwendet). Redundante niedrigwertige Bits werden ignoriert, und somit wird der Inhalt des Verschiebungsfaktorfeldes mit der Gesamtgröße der Speicheroperanden (N) multipliziert, um die endgültige Verschiebung zu generieren, die beim Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird von der Prozessor-Hardware zur Laufzeit basierend auf dem (an späterer Stelle hierin beschriebenen) vollständigen Opcode-Feld 2274 und dem Datenmanipulationsfeld 2254C bestimmt. Das Verschiebungsfeld 2262A und das Verschiebungsfaktorfeld 2262B sind in dem Sinne optional, dass sie nicht für die Befehlsvorlagen ohne Speicherzugriff 2205 verwendet werden und/oder dass verschiedene Beispiele nur eines oder keines der beiden Felder implementieren können.
  • Datenelementbreitefeld 2264 - der Inhalt dieses Feldes unterscheidet, welche von mehreren Datenelementbreiten zu verwenden ist (in einigen Beispielen für alle Befehle; in anderen Beispiele nur für einige der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht benötigt wird, falls nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten mittels eines Aspekts des Opcodes unterstützt werden.
  • Schreibmaskenfeld 2270 - der Inhalt dieses Feldes steuert, für jede Datenelementposition, ob die betreffende Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Erweiterungsoperation widerspiegelt. Befehlsvorlagen der Klasse A unterstützen das Zusammenführen-Schreibmaskieren, während Befehlsvorlagen der Klasse B sowohl Zusammenführen- als auch Nullsetzen-Schreibmaskieren unterstützen. Beim Zusammenführen ermöglichen es Vektormasken, einen beliebigen Satz von Elementen im Ziel während der Ausführung irgendeiner Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) vor Aktualisierungen zu schützen; in einem anderen Beispiel das Beibehalten des alten Werts jedes Elements des Ziels, wobei das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz hierzu erlauben es Vektormasken beim Nullsetzen, einen beliebigen Satz von Elementen im Ziel während der Ausführung irgendeiner Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) auf null zu setzen; in einem Beispiel wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen Wert 0 hat. Eine Untermenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der durchgeführten Operation zu steuern (das heißt, die Spanne von Elementen, die modifiziert werden, vom ersten bis zum letzten); allerdings ist es nicht notwendig, dass die modifizierten Elemente aufeinander folgen. Somit ermöglicht das Schreibmaskenfeld 2270 partielle Vektoroperationen, einschließlich Ladevorgänge, Speichervorgänge, arithmetische Operationen, logische Operationen etc. Während hier Beispiele beschrieben werden, bei denen der Inhalt des Schreibmaskenfeldes 2270 eines von mehreren Schreibmaskenregistern auswählt, welches die zu verwendende Schreibmaske enthält (und der Inhalt des Schreibmaskenfeldes 2270 somit indirekt die durchzuführende Maskierung identifiziert), ermöglichen alternative Beispiele stattdessen oder zusätzlich dazu, dass der Inhalt des Schreibmaskenfeldes 2270 die durchzuführende Maskierung direkt spezifiziert.
  • Direktoperandenfeld 2272 - der Inhalt dieses Feldes ermöglicht die Spezifikation eines Direktoperanden. Dieses Feld ist in dem Sinne optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats nicht enthalten ist, das keine Direktwerte unterstützt, und nicht in Befehlen enthalten ist, die keine Direktoperanden verwenden. Klassenfeld 2268 - der Inhalt dieses Feldes unterscheidet zwischen verschiedenen Klassen von Befehlen. Unter Bezugnahme auf und wählt der Inhalt dieses Feldes zwischen Befehlen der Klasse A und der Klasse B. In und werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass in einem Feld ein spezifischer Wert enthalten ist (z. B. Klasse A 2268A und Klasse B 2268B für das Klassenfeld 2268 in bzw. ).
  • Im Fall der Befehlsvorlagen der Klasse A ohne Speicherzugriff 2205 wird das Alphafeld 2252 als ein RS-Feld 2252A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Runden 2252A.1 und Datentransformation 2252A.2 jeweils für die Befehlsvorlagen für Operationen des Typs Runden 2210 ohne Speicherzugriff und die Befehlsvorlagen für Operationen des Typs Datentransformation ohne Speicherzugriff 2215 spezifiziert), während das Betafeld 2254 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Befehlsvorlagen ohne Speicherzugriff 2205 sind das Skalierfeld 2260, das Verschiebungsfeld 2262A und das Verschiebungsskalierfeld 2262B nicht vorhanden.
  • Bei dem Vektorbefehl für Operationen des Typs vollständige Rundungssteuerung ohne Speicherzugriff 2210 wird das Betafeld 2254 als Rundungssteuerungsfeld 2254A interpretiert, dessen Inhalt eine statische Rundung bereitstellt. Während in den beschriebenen Beispielen das Rundungssteuerungsfeld 2254A ein Feld für das Unterdrücken aller Gleitkommaausnahmen (SAE) 2256 und ein Rundungsoperationssteuerungsfeld 2258 umfasst, können alternative Beispiele das Codieren beider Konzepte in ein und dasselbe Feld unterstützen oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (z. B. können sie nur das Rundungsoperationssteuerungsfeld 2258 aufweisen).
  • SAE-Feld 2256 - der Inhalt dieses Feldes unterscheidet, ob das Berichten von Ausnahmeereignissen deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Feldes 2256 anzeigt, dass die Unterdrückung aktiviert ist, meldet ein gegebener Befehl keinerlei Gleitkommaausnahmemarkierungen und ruft keine Abwickelvorrichtung (Handler) für Gleitkommaausnahmen auf.
  • Rundungsoperationssteuerungsfeld 2258 - der Inhalt dieses Feldes unterscheidet, welche einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden nach Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationssteuerungsfeld 2258 ein Ändern des Rundungsmodus für jeden Einzelbefehl. In einem Beispiel, bei der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi umfasst, hat der Inhalt des Rundungsoperationssteuerungsfeldes 2250 Vorrang vor diesem Regi sterwert.
  • Bei der Befehlsvorlage für Operationen des Typs Datentransformation ohne Speicherzugriff 2215 wird das Betafeld 2254 als ein Datentransformationsfeld 2254B interpretiert, dessen Inhalt unterscheidet, welche von mehreren Datentransformationen durchgeführt werden soll (z. B. keine Datentransformation, Swizzle, Broadcast).
  • Im Fall der Befehlsvorlage der Klasse A mit Speicherzugriff 2220 wird das Alphafeld 2252 als ein Räumungshinweisfeld 2252B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in werden 2252B. 1 temporär bzw. 2252B.2 nicht-temporär für die temporäre Befehlsvorlage mit Speicherzugriff 2225 und die nicht-temporäre Befehlsvorlage mit Speicherzugriff 2230 spezifiziert), während das Betafeld 2254 als ein Datenmanipulationsfeld 2254C interpretiert wird, dessen Inhalt unterscheidet, welche von mehreren Datenmanipulationsoperationen (auch Primitive genannt) durchgeführt werden soll (z. B. keine Manipulation; Broadcast; Hochkonvertierung einer Quelle; und Herunterkonvertierung eines Ziels). Die Befehlsvorlagen mit Speicherzugriff 2220 umfassen das Skalierfeld 2260 und optional das Verschiebungsfeld 2262A oder das Verschiebungsskalierfeld 2262B.
  • Vektorspeicherbefehle laden, mit Konvertierunterstützung, Vektoren aus dem Speicher und speichern Vektoren im Speicher. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten datenelementweise vom/an den Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske vorgegeben werden, die als Schreibmaske ausgewählt ist.
  • Temporäre Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um vom Zwischenspeichern (Caching) zu profitieren. Dies ist jedoch ein Hinweis, und unterschiedliche Prozessoren können diesen auf verschiedene Art und Weise implementieren; dies schließt auch ein vollständiges Ignorieren des Hinweises ein. Nicht-temporäre Daten sind Daten, die wahrscheinlich nicht früh genug wiederverwendet werden, um vom Zwischenspeichern (Caching) im 1st-Level-Cache zu profitieren, und sollten bei der Räumung Priorität erhalten. Dies ist jedoch ein Hinweis, und unterschiedliche Prozessoren können diesen auf verschiedene Art und Weise implementieren; dies schließt auch ein vollständiges Ignorieren des Hinweises ein.
  • Im Fall der Befehlsvorlagen der Klasse B wird das Alphafeld 2252 als ein Feld zur Schreibmaskensteuerung (Z) 2252C interpretiert, dessen Inhalt unterscheidet, ob das durch das Schreibmaskenfeld 2270 gesteuerte Schreibmaskieren ein Zusammenführen oder Nullsetzen sein soll.
  • Im Fall der Befehlsvorlagen der Klasse B ohne Speicherzugriff 2205 wird ein Teil des Betafeldes 2254 als ein RL-Feld 2257A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 2257A.1 und Vektorlänge (VSIZE) 2257A.2 jeweils für die Befehlsvorlage für Operationen des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 2212 und die Befehlsvorlage für Operationen des Typs VSIZE 2217 ohne Speicherzugriff mit Schreibmaskensteuerung, spezifiziert), während der Rest des Betafeldes 2254 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Befehlsvorlagen ohne Speicherzugriff 2205 sind das Skalierfeld 2260, das Verschiebungsfeld 2262A und das Verschiebungsskalierfeld 2262B nicht vorhanden.
  • Bei der Befehlsvorlage für Operationen des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 2210 wird der Rest des Betafeldes 2254 als ein Rundungsoperationsfeld 2259A interpretiert, und das Berichten von Ausnahmeereignissen wird deaktiviert (ein gegebener Befehl berichtet keinerlei Gleitkommaausnahmemarkierungen und ruft keine Abwickelvorrichtung (Handler) für Gleitkommaausnahmen auf).
  • Rundungsoperationssteuerungsfeld 2259A - ebenso wie das Rundungsoperationssteuerungsfeld 2258 unterscheidet der Inhalt dieses Feldes, welche Operation aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden nach Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationssteuerungsfeld 2259A ein Ändern des Rundungsmodus für jeden Einzelbefehl. In einem Beispiel, bei der ein Prozessor ein Steuerregister für das Spezifizieren von Rundungsmodi umfasst, hat der Inhalt des Rundungsoperationssteuerungsfeldes 2250 Vorrang vor diesem Registerwert.
  • Bei der Befehlsvorlage für Operationen des Typs VSIZE ohne Speicherzugriff mit Schreibmaskensteuerung 2217 wird der Rest des Betafeldes 2254 als Vektorlängenfeld 2259B interpretiert, dessen Inhalt unterscheidet, welche von mehreren Datenvektorlängen durchgeführt werden soll (z. B. 128, 256 oder 512 Bytes).
  • Bei der Befehlsvorlage der Klasse B mit Speicherzugriff 2220 wird ein Teil des Betafeldes 2254 als Broadcast-Feld 2257B interpretiert, dessen Inhalt unterscheidet, ob die Datenmanipulationsoperation des Typs Broadcast durchgeführt werden soll oder nicht, während der Rest des Betafeldes 2254 als Vektorlängenfeld 2259B interpretiert wird. Die Befehlsvorlagen mit Speicherzugriff 2220 umfassen das Skalierfeld 2260 und optional das Verschiebungsfeld 2262A oder das Verschiebungsskalierfeld 2262B.
  • Unter Bezugnahme auf das generische vektorfreundliche Befehlsformat 2200 wird ein vollständiges Opcode-Feld 2274 gezeigt, einschließlich Formatfeld 2240, Basisoperationsfeld 2242 und Datenelementbreitefeld 2264. Während ein Beispiel gezeigt wird, bei der das vollständige Opcode-Feld 2274 alle diese Felder umfasst, umfasst das vollständige Opcode-Feld 2274 in Beispielen, die nicht alle diese Felder unterstützen, weniger als alle diese Felder. Das vollständige Opcode-Feld 2274 stellt den Operationscode (Opcode) bereit.
  • Das Erweiterungsoperationsfeld 2250, das Datenelementbreitefeld 2264 und das Schreibmaskenfeld 2270 ermöglichen, dass diese Merkmale im generischen vektorfreundlichen Befehlsformat für jeden Einzelbefehl spezifiziert werden können. Die Kombination von Schreibmaskenfeld und Datenelementbreitefeld erzeugt dahingehend typisierte Befehle, dass sie ermöglichen, die Maske auf Basis von unterschiedlichen Datenelementbreiten anzuwenden.
  • Die verschiedenen in Klasse und Klasse B zu findenden Befehlsvorlagen sind in unterschiedlichen Situationen von Vorteil. In einigen Beispielen unterstützen unterschiedliche Prozessoren oder verschiedene Kerne in einem Prozessor unter Umständen nur Klasse A, nur Klasse B oder beide Klassen. So unterstützt beispielsweise ein universeller Out-of-Order-Hochleistungskern, der für allgemeine Datenverarbeitungszwecke vorgesehen ist, unter Umständen nur Klasse B, ein Kern, der primär für grafische und/oder wissenschaftliche (Durchsatz) Berechnungen vorgesehen ist, unter Umständen nur Klasse A und ein Kern, der für beides vorgesehen ist, unter Umständen beide Klassen (natürlich liegt auch ein Kern, der über eine Mischung aus Vorlagen und Befehlen aus beiden Klassen, aber nicht alle Vorlagen und Befehle aus beiden Klassen verfügt). Auch ein einzelner Prozessor kann mehrere Kerne aufweisen, die alle dieselbe Klasse unterstützen oder in denen verschiedene Kerne unterschiedliche Klassen unterstützen. So kann beispielsweise in einem Prozessor mit getrennten Grafik- und Universalkernen einer der Grafikkerne, der primär für grafische und/oder wissenschaftliche Berechnungen vorgesehen ist, nur Klasse A unterstützen, während einer oder mehrere der Universalkerne für allgemeine Datenverarbeitungszwecke vorgesehene universelle Hochleistungskerne mit Out-of-Order-Ausführung und Registerumbenennung sein können, die nur Klasse B unterstützen. Ein anderer Prozessor, der nicht über einen separaten Grafikkern verfügt, kann einen oder mehrere universelle In-Order-/Out-of-Order- Kerne aufweisen, die Klasse A und Klasse B unterstützen. Natürlich können in unterschiedlichen Beispielen Merkmale aus einer Klasse auch in der anderen Klasse implementiert sein. In einer Hochsprache geschriebene Programme würden (z. B. zum Bedarfszeitpunkt kompiliert oder statisch kompiliert) in mehrere unterschiedliche ausführbare Formen gebracht werden, einschließlich: 1) eine Form, welche nur Befehle der Klasse(n) aufweist, die vom Zielprozessor zur Ausführung unterstützt werden; oder 2) eine Form, welche alternative Routinen aufweist, die unter Verwendung verschiedener Kombinationen der Befehle aller Klassen geschrieben wurde, und welche Flusssteuerungscode aufweist, der die auszuführenden Routinen auf Basis der vom Prozessor unterstützen Befehle auswählt, welcher gerade den Code ausführt.
  • ist ein Blockschaltbild, das ein spezifisches vektorfreundliches Befehlsformat veranschaulicht. zeigt ein spezifisches vektorfreundliches Befehlsformat 2300, das in dem Sinne spezifisch ist, als dass es den Ort, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 2300 kann verwendet werden, um den x86-Befehlssatz zu erweitern, und somit sind einige der Felder ähnlich wie die Felder oder identisch mit den Feldern, die im bestehenden x86-Befehlssatz und Erweiterungen davon (z. B. AVX) verwendet werden. Dieses Format bleibt konsistent mit dem Präfixcodierfeld, dem realen Opcode-Byte-Feld, dem MOD-R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und den Direktoperandenfeldern des bestehenden x86-Befehlssatzes mit Erweiterungen. Die Felder aus , auf die die Felder aus abgebildet sind, sind hier dargestellt.
  • An dieser Stelle sei angemerkt, dass auch wenn Beispiele zur Veranschaulichung unter Bezugnahme auf das spezifische vektorfreundliche Befehlsformat 2300 im Zusammenhang des generischen vektorfreundlichen Befehlsformats 2200 beschrieben werden, jedoch nicht auf das spezifische vektorfreundliche Befehlsformat 2300 beschränkt ist, sofern dies nicht ausdrücklich geltend gemacht wird. So zieht das generische vektorfreundliche Befehlsformat 2200 beispielsweise verschiedene mögliche Größen für die verschiedenen Felder in Betracht, während das spezifische vektorfreundliche Befehlsformat 2300 als Befehlsformat mit Feldern spezifischer Größe gezeigt wird. Als spezifisches Beispiel sei angeführt, dass das Datenelementbreitefeld 2264 zwar als ein Ein-Bit-Feld im spezifischen vektorfreundlichen Befehlsformat 2300 dargestellt ist, jedoch diesbezüglich nicht eingeschränkt ist (das heißt, das generische vektorfreundliche Befehlsformat 2200 zieht auch andere Größen des Datenelementbreitefeldes 2264 in Betracht).
  • Das generische vektorfreundliche Befehlsformat 2200 umfasst die nachstehend aufgelisteten Felder in der Reihenfolge wie in dargestellt. EVEX-Präfix (Bytes 0-3) 2302 - ist in einer Vier-Byte-Form codiert. Formatfeld 2240 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Formatfeld 2240 und enthält 0x62 (der eindeutige Wert, der zum Unterscheiden des vektorfreundlichen Befehlsformats in einem Beispiel verwendet wird). Die zweiten-vierten Bytes (EVEX Bytes 1-3) umfassen eine Anzahl von Bitfeldern, die eine spezifische Funktionalität bereitstellen.
  • REX-Feld 2305 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX.R Bitfeld (EVEX-Byte 1, Bit [7] - R), einem EVEX.X Bitfeld (EVEX-Byte 1, Bit [6] - X) und 2257 BEX Byte 1, Bit [5] - B). Die Bitfelder EVEX.R, EVEX.X und EVEX.B stellen dieselbe Funktionalität bereit wie die entsprechenden VEX-Bitfelder und werden unter Verwendung der 1er-Komplementform codiert, d. h. ZMM0 wird als 1111B codiert, ZMM15 wird als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes nach dem Stand der Technik (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von EVEX.R, EVEX.X und EVEX.B. gebildet werden können.
  • REX'-Feld 2210 - dies ist der erste Teil des REX'-Feldes 2210 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), das verwendet wird, um die oberen 16 oder die unteren 16 Register des erweiterten 32-Register-Satzes zu codieren. In einem Beispiel ist dieses Bit, zusammen mit anderen Bits wie nachstehend angegeben, in einem bit-invertierten Format gespeichert, um (im bekannten x86 32-Bit-Modus) von dem BOUND-Befehl zu unterscheiden, dessen reales Opcode-Byte 62 ist, der jedoch im (nachstehend beschriebenen) MOD-R/M-Feld nicht den Wert 11 im MOD-Feld akzeptiert; alternative Beispiele speichern dieses und die anderen nachstehend angegebenen Bits nicht im invertierten Format. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und dem anderen RRR aus den anderen Feldern gebildet.
  • Opcode-Map-Feld 2315 (EVEX-Byte 1, Bits [3:0] - mmmm) - der Inhalt dieses Feldes codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3). Datenelementbreitefeld 2264 (EVEX-Byte 2, Bit [7] - W) - wird durch die Bezeichnung EVEX.W dargestellt. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (32-Bit-Datenelemente oder 64-Bit-Datenelemente). EVEX.vvvv 2320 (EVEX Byte 2, Bits [6:3]-vvvv) - die Rolle von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, spezifiziert in invertierter Form (1er-Komplement), und gilt für Befehle mit 2 oder mehr Quelloperanden; 2) EVEX.vvvv codiert den Zielregisteroperanden, spezifiziert in 1er-Komplementform für bestimmte Vektorverschiebungen; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Somit codiert das Feld EVEX.vvvv 2320 die 4 niedrigwertigen Bits des ersten Quellregister-Spezifikators, der in invertierter (1er-Komplement) Form gespeichert ist. In Abhängigkeit von dem Befehl wird ein zusätzliches unterschiedliches EVEX-Bitfeld verwendet, um die Spezifikatorgröße auf 32 Register zu erweitern. EVEX.U 2268 Klassenfeld (EVEX-Byte 2, Bit [2]-U) - Falls EVEX.U = 0 ist, zeigt dies Klasse A oder EVEX.U0 an; falls EVEX.U = 1 ist, zeigt dies Klasse B oder EVEX.U1 an.
  • Präfixcodierfeld 2325 (EVEX-Byte 2, Bits [1 :0]-pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zum Bereitstellen von Unterstützung für die bisherigen SSE-Befehle im EVEX-Präfix-Format hat dies außerdem den Vorteil, dass das SIMD-Präfix verdichtet wird (anstatt ein Byte zu benötigen, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Präfix nur 2 Bits). In einem Beispiel werden diese bisherigen SΠVVID-Präfixe, um bisherige SSE-Befehle zu unterstützen, die ein SIMD-Präfix (66H, F2H, F3H) sowohl im bisherigen Format als auch im EVEX-Präfix-Format verwenden, in das SIMD-Präfix-Codierfeld eincodiert; und zur Laufzeit werden diese bisherigen SIMD-Präfixe in das bisherige SIMD-Präfix erweitert, bevor sie für die PLA des Decodierers bereitgestellt werden (so dass die PLA das bisherige Format und das EVEX-Format dieser bisherigen Befehle ohne Modifikation ausführen kann). Auch wenn neuere Befehle den Inhalt des EVEX-Präfixcodierfeldes direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Beispiele aus Konsistenzgründen in ähnlicher Weise, erlauben jedoch, dass unterschiedliche Bedeutungen durch diese bisherigen SIMD-Präfixe spezifiziert werden. Ein alternatives Beispiel kann die PLA umgestalten, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, so dass keine Erweiterung erforderlich ist.
  • Alphafeld 2252 (EVEX-Byte 3, Bit [7] - EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX. Schreibmaskensteuerung und EVEX.N; auch dargestellt durch α) - wie vorstehend beschrieben ist dieses Feld kontextspezifisch. Betafeld 2254 (EVEX-Byte 3, Bits [6:4]-SSS, auch bekannt als EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; auch dargestellt durch ßßß) - wie vorstehend beschrieben ist dieses Feld kontextspezifisch.
  • REX'-Feld 2210 - dies ist der Rest des REX'-Feldes und ist das EVEX.V-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das verwendet werden kann, um die oberen 16 oder die unteren 16 Register des erweiterten 32-Register-Satzes zu codieren. Dieses Bit ist im bit-invertierten Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
  • Schreibmaskenfeld 2270 (EVEX-Byte 3, Bits [2:0]-kkk) - der Inhalt dieses Feldes spezifiziert den Index eines Registers in den Schreibmaskenregistern wie vorstehend beschrieben. In einem Beispiel hat der spezifische Wert EVEX.kkk=000 ein besonderes Verhalten, das impliziert, dass keine Schreibmaske für diesen speziellen Befehl verwendet wird (dies kann auf verschiedene Art und Weise implementiert sein, unter anderem durch die Verwendung einer Schreibmaske, die mit allen Einsen festverdrahtet ist, oder einer Hardware, die die Maskierungshardware umgeht).
  • Das reale Opcode-Feld 2330 (Byte 4) wird auch Opcode-Byte genannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert. Das MOD-R/M-Feld 2340 (Byte 5) umfasst das MOD-Feld 2342, das Reg-Feld 2344 und das R/M-Feld 2346. Wie vorstehend beschrieben, unterscheidet der Inhalt des MOD-Feldes 2342 zwischen Operationen mit und ohne Speicherzugriff. Die Rolle des Reg-Feldes 2344 kann auf zwei Situationen zusammengefasst werden: Codieren des Zielregisteroperanden oder eines Quellregisteroperanden, oder als Opcode-Erweiterung behandelt zu werden und nicht für das Codieren irgendeines Befehlsoperanden verwendet zu werden. Die Rolle des R/M-Feldes 2346 kann Folgendes umfassen: Codieren des Befehlsoperanden, der eine Speicheradresse referenziert, oder Codieren des Zielregisteroperanden oder eines Quellregisteroperanden.
  • Skala, Index, Basis (SIB) -Byte (Byte 6) - Wie vorstehend beschrieben wird der Inhalt des Skalierfeldes 2250 für die Generierung von Speicheradressen verwendet. SIB.xxx 2354 und SIB.bbb 2356 - auf die Inhalte dieser Felder wurde zuvor im Hinblick auf die Registerindizes Xxxx und Bbbb verwiesen. Verschiebungsfeld 2262A (Bytes 7-10) - wenn das MOD-Feld 2342 den Wert 10 enthält, sind die Bytes 7-10 das Verschiebungsfeld 2262A, und es arbeitet genauso wie die alte 32-Bit-Verschiebung (disp32) und arbeitet mit Byte-Granularität.
  • Verschiebungsfaktorfeld 2262B (Byte 7) - wenn das MOD-Feld 2342 den Wert 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 2262B. Der Ort dieses Feldes ist identisch mit dem Ort der 8-Bit-Verschiebung (disp8) des bisherigen x86-Befehlssatzes, die mit Byte-Granularität arbeitet. Da disp8 vorzeichenerweitert ist, kann nur ein Versatz zwischen -128 und 127 Bytes adressiert werden; in Bezug auf 64-Byte-Cachezeilen verwendet disp8 8 Bits, die auf nur vier wirklich nützliche Werte eingestellt werden können -128, -64, 0 und 64; da oft ein größerer Bereich benötigt wird, wird disp32 verwendet; allerdings erfordert disp32 4 Bytes. In Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 2262B eine Neuinterpretation von disp8; beim Verwenden des Verschiebungsfaktorfeldes 2262B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfeldes multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Diese Art der Verschiebung wird als disp8*N bezeichnet. Dies reduziert die durchschnittliche Befehlslänge (ein einzelnes Byte wird für die Verschiebung verwendet, aber mit einem viel größeren Bereich). Eine solche komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist, und somit müssen die redundanten niederwertigen Bits des Adressversatzes nicht codiert werden. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 2262B die 8-Bit-Verschiebung des bisherigen x86-Befehlssatzes. Somit wird das Verschiebungsfaktorfeld 2262B auf dieselbe Weise codiert wie eine 8-Bit-Verschiebung des x86-Befehlssatzes (so dass keine Änderungen an den Mod-RM/SIB-Codierregeln erfolgen), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird. Mit anderen Worten gibt es keine Änderungen hinsichtlich der Codierregeln oder der Codierlängen, sondern nur hinsichtlich der Interpretation des Verschiebungswerts durch die Hardware (welche die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byte-weisen Adressversatz zu erhalten). Das Direktoperandenfeld 2272 arbeitet wie vorstehend beschrieben.
  • ist ein Blockschaltbild, das die Felder des spezifischen vektorfreundlichen Befehlsformats 2300 veranschaulicht, aus denen sich das vollständige Opcode-Feld 2274 zusammensetzt. Insbesondere umfasst das vollständige Opcode-Feld 2274 das Formatfeld 2240, das Basisoperationsfeld 2242 und das Datenelementbreitefeld (W) 2264. Das Basisoperationsfeld 2242 umfasst das Präfixcodierfeld 2325, das Opcode-Map-Feld 2315 und das reale Opcode-Feld 2330.
  • ist ein Blockschaltbild, das die Felder des spezifischen vektorfreundlichen Befehlsformats 2300 veranschaulicht, aus denen sich das Registerindexfeld 2244 zusammensetzt. Insbesondere umfasst das Registerindexfeld 2244 das REX-Feld 2305, das REX'-Feld 2310, das MODR/M.reg-Feld 2344, das MODR/M.r/m-Feld 2346, das VVVV-Feld 2320, das xxx-Feld 2354 und das bbb-Feld 2356.
  • ist ein Blockschaltbild, das die Felder des spezifischen vektorfreundlichen Befehlsformats 2300 veranschaulicht, aus denen sich das Erweiterungsoperationsfeld 2250 zusammensetzt. Wenn das Klassenfeld (U) 2268 den Wert 0 enthält, steht dies für EVEX.U0 (Klasse A 2268A); wenn das Feld den Wert 1 enthält, steht dies für EVEX.U1 (Klasse B 2268B). Wenn U=0 ist und das MOD-Feld 2342 den Wert 11 enthält (was für eine Operation ohne Speicherzugriff steht), wird das Alphafeld 2252 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 2252A interpretiert. Wenn das rs-Feld 2252A eine 1 enthält (Runden 2252A.1), wird das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]- SSS) als Rundungssteuerungsfeld 2254A interpretiert. Das Rundungssteuerungsfeld 2254A umfasst ein Ein-Bit-SAE-Feld 2256 und ein Zwei-Bit-Rundungsoperationsfeld 2258. Wenn das rs-Feld 2252A eine 0 enthält (Datentransformation 2252A.2), wird das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]- SSS) als ein Drei-Bit-Datentransformationsfeld 2254B interpretiert. Wenn U=0 ist und das MOD-Feld 2342 den Wert 00, 01 oder 10 enthält (was für eine Operation mit Speicherzugriff steht), wird das Alphafeld 2252 (EVEX-Byte 3, Bit [7] - EH) als Räumungshinweisfeld (EH) 2252B interpretiert und das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]- SSS) wird als ein Drei-Bit-Datenmanipulationsfeld 2254C interpretiert.
  • Wenn U=1 ist, wird das Alphafeld 2252 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerungsfeld (Z) 2252C interpretiert. Wenn U=1 ist und das MOD-Feld 2342 den Wert 11 enthält (was für eine Operation ohne Speicherzugriff steht), wird ein Teil des Betafeldes 2254 (EVEX-Byte 3, Bit [4] - S0) als das RL-Feld 2257A interpretiert; wenn das Feld eine 1 enthält (Runden 2257A.1), wird der Rest des Betafeldes 2254 (EVEX-Byte 3, Bit [6-5]-S2-1) als das Rundungsoperationsfeld 2259A interpretiert; wenn jedoch das RL-Feld 2257A eine 0 enthält (VSIZE 2257.A2), wird der Rest des Betafeldes 2254 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Vektorlängenfeld 2259B (EVEX-Byte 3, Bit[6-5]- L1-0) interpretiert. Wenn U=1 ist und das MOD-Feld 2342 den Wert 00, 01 oder 10 enthält (was für eine Operation mit Speicherzugriff steht), wird das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 2259B (EVEX-Byte 3, Bit [6-5]- L1-0) und das Broadcast-Feld 2257B (EVEX-Byte 3, Bit [4]- B) interpretiert.
  • ist ein Blockschaltbild einer Registerarchitektur 2400. In dem dargestellten Beispiel gibt es 32 Vektorregister 2410, die 512 Bits breit sind; diese Register werden als zmm0 bis zmm31 referenziert. Die geringerwertigen 256 Bits der unteren 16 zmm-Register werden auf die Register ymm0-16 überlagert. Die geringerwertigen 128 Bits der unteren 16 zmm-Register (die geringerwertigen 128 Bits der ymm-Register) werden auf die Register xmm0-15 überlagert. Das spezifische vektorfreundliche Befehlsformat 2300 wirkt auf diese überlagerte Registerdatei wie in den nachstehenden Tabellen dargestellt.
    Anpassbare Vektorlänge Klasse Operationen Register
    Befehlsvorlagen, die nicht das Vektorlängenfeld 2259B aufweisen A ( ; U=0) 2210, 2215, 2225, 2230 zmm-Register (die Vektorlänge beträgt 64 Bytes)
    B ( ; U=1) 2212 zmm-Register (die Vektorlänge beträgt 64 Bytes)
    Befehlsvorlagen, die das Vektorlängenfeld 2259B aufweisen B ( ; U=1) 2217, 2227 zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Bytes, 32 Bytes oder 16 Bytes) in Abhängigkeit vom Vektorlängenfeld 2259B
  • Mit anderen Worten wählt das Vektorlängenfeld 2259B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede dieser kürzeren Längen halb so lang ist wie die vorhergehende Länge; und Befehlsvorlagen ohne das Vektorlängenfeld 2259B wirken auf die maximale Vektorlänge. Ferner wirken die Befehlsvorlagen der Klasse B des spezifischen vektorfreundlichen Befehlsformats 2300 auf gepackte oder skalare Gleitkommadaten mit einfacher/doppelter Genauigkeit und auf gepackte oder skalare ganzzahlige Daten. Skalare Operationen sind Operationen, die für die niedrigstwertige Datenelementposition in einem zmm/ymm/xmm-Register durchgeführt werden; die höherwertigen Datenelementpositionen bleiben entweder so, wie sie vor dem Befehl waren, oder sie werden null gestellt.
  • Schreibmaskenregister 2415 - in dem dargestellten Beispiel gibt es 8 Schreibmaskenregister (k0 bis k7), jedes mit einer Größe von 64 Bits. In einem alternativen Beispiel haben die Schreibmaskenregister 2415 eine Größe von 16 Bits. Wie vorstehend beschrieben, kann das Vektormaskenregister k0 in einem Beispiel nicht als eine Schreibmaske verwendet werden; wenn das Codieren, das normalerweise k0 angeben würde, für eine Schreibmaske verwendet wird, wählt es eine festverdrahtete Schreibmaske von 0xFFFF aus, wodurch effektiv die Schreibmaskierung für diesen Befehl deaktiviert wird.
  • Universalregister 2425 - in dem dargestellten Beispiel gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den bestehenden x86 Adressierungsmodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register werden durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 referenziert.
  • Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 2445, der die MMX-gepackte Ganzzahl-Flachregisterdatei 2450 per Alias zugeordnet ist - in dem dargestellten Beispiel ist der x87-Stapel ein Acht-Elemente-Stapel, der verwendet wird, um unter Verwendung der x87-Befehlssatzerweiterung skalare Gleitkommaoperationen für 32/64/80-Bit-Gleitkommadaten durchzuführen; während die MMX-Register verwendet werden, um Operationen für 64-Bit-gepackte ganzzahlige Daten durchzuführen, sowie um Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
  • Alternative Beispiele können breitere oder schmalere Register verwenden. Zusätzlich können alternative Beispiele mehr, weniger oder andere Registerdateien und Register verwenden.
  • Prozessorkerne können für unterschiedliche Zwecke und in unterschiedlichen Prozessoren auf verschiedene Art und Weise implementiert sein. So können beispielsweise Implementierungen solcher Kerne umfassen: 1) einen universellen In-Order-/Out-of-Order-Kern für allgemeine Datenverarbeitungszwecke; 2) einen universellen Out-of-Order-Hochleistungskern für allgemeine Datenverarbeitungszwecke; 3) einen Spezialkern, der primär für grafische und/oder wissenschaftliche (Durchsatz) Berechnungen vorgesehen ist. Implementierungen von unterschiedlichen Prozessoren können umfassen: 1) eine CPU mit einem oder mehreren universellen In-Order-Kernen für allgemeine Verarbeitungszwecke und/oder einen oder mehrere universelle Out-of-Order-Keme für allgemeine Verarbeitungszwecke; und 2) einen Coprozessor mit einem oder mehreren Spezialkernen, der (die) primär für grafische und/oder wissenschaftliche (Durchsatz) Berechnungen vorgesehen ist (sind). Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die umfassen können: 1) den Coprozessor auf einem anderen Chip als die CPU; 2) den Coprozessor auf einem separaten Halbleiterplättchen in demselben Paket wie die CPU; 3) den Coprozessor auf demselben Halbleiterplättchen wie die CPU (in diesem Fall wird ein solcher Coprozessor manchmal als Speziallogik bezeichnet, beispielsweise als integrierte Grafik und/oder wissenschaftliche (Durchsatz)Logik oder als Spezialkerne); und 4) ein System auf einem Chip, der auf demselben Halbleiterplättchen die beschriebene CPU (manchmal als Anwendungskern(e) oder als Anwendungsprozessor(en) bezeichnet), den vorstehend beschriebenen Coprozessor und zusätzliche Funktionalität aufweisen kann. Beispielhafte Kernarchitekturen werden als nächstes beschrieben, gefolgt von Beschreibungen von Prozessoren und Computerarchitekturen.
  • ist ein Blockschaltbild, das eine In-Order-Pipeline und eine registerumbenennende Out-of-Order-Ausgabe-/Ausführungspipeline veranschaulicht. ist ein Blockschaltbild, das einem In-Order-Architekturkern und einen registerumbenennenden Out-of Order-Ausgabe-/Ausführungsarchitekturkern zur Aufnahme in einen Prozessor veranschaulicht. Die mit einer durchgehenden Linie gekennzeichneten Felder veranschaulichen die In-Order-Pipeline und den In-Order-Kern, während die optionale Ergänzung der mit einer gestrichelten Linie gekennzeichneten Felder die Registerumbenennung, die Out-of-Order-Ausgabe-/Ausführungspipeline und den Out-of-Order-Ausgabe-/Ausführungskem veranschaulicht. Da der In-Order-Aspekt eine Untermenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
  • In umfasst eine Prozessorpipeline 2500 eine Abrufstufe 2502, eine Längendecodierstufe 2504, eine Decodierstufe 2506, eine Zuweisungsstufe 2508, eine Umbenennungsstufe 2510, eine Zeitplanungsstufe (auch Versandstufe oder Ausgabestufe genannt) 2512, eine Registerlese-/Speicherlesestufe 2514, eine Ausführungsstufe 2516, eine Rückschreibe-/Speicherschreibstufe 2518, eine Ausnahmebehandlungsstufe 2522 und eine Übergabestufe 2524.
  • zeigt einen Prozessorkern 2590 mit einer Frontend-Einheit 2530, die an eine Ausführungsengine-Einheit 2550 gekoppelt ist, und beide sind an eine Speichereinheit 2570 gekoppelt. Bei dem Kern 2590 kann es sich um einen Kern für die Verarbeitung reduzierter Befehlssätze (Reduced Instruction Set Computing, RISC), einen Kern für die Verarbeitung komplexer Befehlssätze (Complex Instruction Set Computing, CISC), einen Kern für sehr lange Befehlswörter (Very Long Instruction Word, VLIW) oder eine hybride oder alternative Kernart handeln. Als eine noch andere Option kann es sich bei dem Kern 2590 um einen Spezialkern handeln, beispielsweise einen Netz- oder Kommunikationskern, eine Kompressionsengine, einen Coprozessorkern, den Kern einer Grafikverarbeitungseinheit für allgemeine Verarbeitungszwecke (General Purpose Computing Graphics Processing Unit, GPGPU), einen Grafikkern oder dergleichen.
  • Die Frontend-Einheit 2530 umfasst eine Sprungvorhersage-Einheit 2532, die an eine Befehlscache-Einheit 2534 gekoppelt ist, welche an einen Übersetzungspuffer (Translation Lookaside Buffer, TLB) für Befehle 2536 gekoppelt ist, der wiederum an eine Befehlsabrufeinheit 2538 gekoppelt ist, die an eine Decodiereinheit 2540 gekoppelt ist. Die Decodiereinheit 2540 (oder der Decodierer) kann Befehle decodieren und als Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Einsprungpunkte, Mikrobefehle, andere Befehle oder andere Steuersignale generieren, die anhand der ursprünglichen Befehle decodiert werden oder die ursprünglichen Befehle in anderer Weise wiedergeben oder von den ursprünglichen Befehlen abgeleitet sind. Die Decodiereinheit 2540 kann unter Verwendung von mehreren unterschiedlichen Mechanismen implementiert sein. Beispiele für geeignete Mechanismen umfassen, ohne jedoch hierauf beschränkt zu sein, Nachschlagetabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (Programmable Logic Arrays, PLAs), Festwertspeicher (Read-only Memories, ROMs) für Mikrocode etc. In einem Beispiel umfasst der Kern 2590 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makrobefehle (z. B. in einer Decodiereinheit 2540 oder sonstwie in der Frontend-Einheit 2530) speichert. Die Decodiereinheit 2540 ist an eine Umbenennungs-/Zuweisungseinheit 2552 in der Ausführungsengine-Einheit 2550 gekoppelt.
  • Die Ausführungsengine-Einheit 2550 umfasst die Umbenennungs-/Zuweisungseinheit 2552, die an eine Rückordnungseinheit 2554 und an einen Satz von einer oder mehreren Planungseinheit(en) 2556 gekoppelt ist. Die Planereinheit(en) 2556 repräsentiert (repräsentieren) eine beliebige Anzahl von unterschiedlichen Planern, einschließlich Reservierungsstationen, ein zentrales Befehlsfenster etc. Die Planereinheit(en) 2556 ist (sind) an die physischen Registerdatei-Einheit(en) 2558 gekoppelt. Jede der physischen Registerdatei-Einheiten 2558 repräsentiert eine oder mehrere physische Registerdatei(en), von denen verschiedene einen oder mehrere unterschiedliche Dateitypen speichern, beispielsweise skalare Ganzzahl, skalarer Gleitkommawert, gepackte Ganzzahl, gepackter Gleitkommawert, Vektorganzzahl, Vektorgleitkommawert, Status (z. B. einen Befehlszeiger, bei dem es sich um die Adresse des nächsten auszuführenden Befehls handelt) etc.
  • In einem Beispiel umfasst die physische Registerdatei-Einheit 2558 eine Vektorregister-Einheit, eine Schreibmaskenregister-Einheit und eine Skalarregister-Einheit. Dieser Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physischen Registerdatei-Einheit(en) 2558 wird (werden) von der Rückordnungseinheit 2554 überlappt, um verschiedene Arten und Weisen zu veranschaulichen, auf die eine Registerumbenennung und eine Out-of-Order-Ausführung implementiert sein können (z. B. unter Verwendung von Neuordnungspuffern und Rückordnungsregisterdateien; unter Verwendung von zukünftigen Dateien, historischen Puffern und Rückordnungsregisterdateien; unter Verwendung von Register-Maps und eines Registerpools; etc.). Die Rückordnungseinheit 2554 und die physische Registerdatei-Einheit(en) 2558 ist (sind) an den (die) Ausführungscluster 2560 gekoppelt.
  • Der (die) Ausführungscluster 2560 umfasst (umfassen) einen Satz von einer oder mehreren Ausführungseinheiten 2562 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 2564. Die Ausführungseinheiten 2562 können verschiedene Operationen (z. B. Verschiebungen, Ergänzungen, Subtraktionen, Multiplikationen) durchführen, und an verschiedenen Datentypen (z. B. skalarer Gleitkommawert, gepackte Ganzzahl, gepackter Gleitkommawert, Vektorganzzahl, Vektorgleitkommawert). Zwar können einige Beispiele eine Anzahl von Ausführungseinheiten umfassen, die für spezifische Funktionen oder Sätze von Funktionen vorgesehen sind, jedoch können andere Beispiele nur eine Ausführungseinheit oder mehrere Ausführungseinheiten aufweisen, die alle sämtliche Funktionen durchführen.
  • Die Planereinheit(en) 2556, die physische(n) Registerdatei(en) 2558 und die Ausführungscluster 2560 werden als möglicherweise mehrfach vorhanden gezeigt, weil bestimmte Beispiele getrennte Pipelines für bestimmte Arten von Daten/Operationen erzeugen (z. B. eine skalare Ganzzahl-Pipeline, eine Pipeline für skalare Gleitkommawerte/gepackte Ganzzahlen/gepackte Gleitkommawerte/Vektorganzzahlen/Vektorgleitkommawerte und/oder eine Speicherzugriffspipeline, die jeweils eine eigene Planereinheit, physische Registerdatei-Einheit und/oder Ausführungscluster aufweisen - und im Fall einer separaten Speicherzugriffspipeline sind in einem bestimmten Beispiel implementiert, bei denen nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 2564 aufweist). Ferner sei darauf hingewiesen, dass in den Fällen, in denen separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines als Out-of-Order-Ausgabe-/Ausführungspipeline und der Rest als In-Order-Pipeline ausgeführt sein kann.
  • Der Satz von Speicherzugriffseinheiten 2564 ist an die Speichereinheit 2570 gekoppelt, welche eine Daten-TLB-Einheit 2572 aufweist, die an eine Datencache-Einheit 2574 gekoppelt ist, welche wiederum an eine Level-2 (L2)-Cache-Einheit 2576 gekoppelt ist. In einem Beispiel können die Speicherzugriffseinheiten 2564 eine Ladeeinheit, eine Speicheradresseinheit und eine Speicherdateneinheit aufweisen, wobei jede dieser Einheiten an die Daten-TLB-Einheit 2572 in der Speichereinheit 2570 gekoppelt ist. Die Befehlscache-Einheit 2534 ist ferner an eine Level-2 (L2)-Cache-Einheit 2576 in der Speichereinheit 2570 gekoppelt. Die L2-Cache-Einheit 2576 ist an einen oder mehrere andere Cache-Level gekoppelt und letztendlich an einen Hauptspeicher.
  • Beispielsweise kann die registerumbenennende Out-of Order-Ausgabe/Ausführungskern-Architektur die Pipeline 2500 wie folgt implementieren: 1) die Befehlsabrufeinheit 2538 führt die Abruf- und Längendecodierstufen 2502 und 2504 durch; 2) die Decodiereinheit 2540 führt die Decodierstufe 2506 durch; 3) die Umbenennungs-/Zuweisungseinheit 2552 führt die Zuweisungsstufe 2508 und die Umbenennungsstufe 2510 durch; 4) die Planereinheit(en) 2556 führt (führen) die Planungsstufe 2512 durch; 5) die physische(n) Registerdatei-Einheit(en) 2558 und die Speichereinheit 2570 führen die Registerlese-/Speicherlesestufe 2514 durch; der Ausführungscluster 2560 führt die Ausführungsstufe 2516 durch; 6) die Speichereinheit 2570 und die physische(n) Registerdateieinheit(en) 2558 führen die Rückschreibe-/Speicherschreibstufe 2518 durch; 7) verschiedene Einheiten können in die Ausnahmebehandlungsstufe 2522 einbezogen sein; und 8) die Rückordnungseinheit 2554 und die physische(n) Registerdatei-Einheit(en) 2558 führen die Übergabestufe 2524 durch.
  • Der Kern 2590 kann einen oder mehrere Befehlssätze unterstützen (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt worden sind); den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings aus Sunnyvale, CA), einschließlich der hier beschriebenen Befehle. In einem Beispiel weist der Kern 2590 Logik auf für das Unterstützen einer Befehlssatzerweiterung für gepackte Daten (z. B. AVX1, AVX2 und/oder eine Form des vorstehend beschriebenen generischen vektorfreundlichen Befehlsformats (U=0 und/oder U=1)), so dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden können.
  • An dieser Stelle sei angemerkt, dass der Kern ein Multithreading (das Ausführen von zwei oder mehreren parallelen Sätzen von Operationen oder Programmfäden) unterstützen kann und dies auf verschiedene Art und Weise realisieren kann, einschließlich zeitscheibenbasiertes Multithreading, simultanes Multithreading (bei dem ein einzelner physischer Kern für jeden der Programmfäden, die dieser physische Kern gleichzeitig verarbeitet, einen logischen Kern bereitstellt), oder eine Kombination davon (z. B. zeitscheibenbasiertes Abrufen und Decodieren und anschließendes simultanes Multithreading wie beispielsweise bei der Intel® Hyperthreading-Technologie).
  • Auch wenn die Registerumbenennung im Zusammenhang der Out-of-Order-Ausführung beschrieben wird, versteht es sich, dass die Registerumbenennung auch in einer In-Order-Architektur verwendet werden kann. Auch wenn das dargestellte Beispiel des Prozessors getrennte Befehls- und Datencache-Einheiten 2534/2574 und eine gemeinsam genutzte L2-Cache-Einheit 2576 aufweist, können alternative Beispiele einen einzelnen internen Cache für beides, Befehle und Daten, aufweisen, wie beispielsweise einen internen Level-1 (L1)-Cache oder mehrere Ebenen von internem Cache. In einigen Beispielen kann das System eine Kombination aus einem internen Cache und einem externen Cache aufweisen, der extern zu dem Kern und/oder dem Prozessor vorliegt. Alternativ kann der gesamte Cache extern zu dem Kern und/oder dem Prozessor vorliegen.
  • und zeigen ein Blockschaltbild einer spezifischeren In-Order-Kernarchitektur, deren Kern einer von mehreren Logikblöcken (einschließlich anderer Kerne desselben Typs und/oder unterschiedlicher Typen) in einem Chip wäre. Die Logikblöcke kommunizieren durch ein Verbindungsnetz mit großer Bandbreite (z. B. ein Ringnetz) mit fester Funktionslogik, Speicher-E/A-Schnittstellen und anderer erforderlicher E/A-Logik, je nach Anwendung.
  • ist ein Blockschaltbild eines einzelnen Prozessorkerns, zusammen mit dessen Verbindung zu dem On-die-Verbindungsnetz 2602 und mit der zugehörigen lokalen Untermenge des Level-2 (L2)-Caches 2604. In einem Beispiel unterstützt ein Befehlsdecodierer 2600 den x86-Befehlssatz mit einer Befehlssatzerweiterung für gepackte Daten. Ein L1-Cache 2606 ermöglicht latenzarme Zugriffe auf den Cache-Speicher in die skalaren Einheiten und die Vektoreinheiten. Während in einem Beispiel (um das Design zu vereinfachen) eine skalare Einheit 2608 und eine Vektoreinheit 2610 getrennte Registersätze (skalare Register 2612 bzw. Vektorregister 2614) verwenden und zwischen diesen übertragene Daten in den Speicher geschrieben und dann aus einem Level-1 (L1)-Cache 2606 erneut eingelesen werden, können alternative Beispiele einen unterschiedlichen Ansatz verfolgen (z. B. das Verwenden eines einzelnen Registersatzes oder das Einschließen eines Kommunikationspfads, der es erlaubt, Daten ohne Schreiben und Zurücklesen zwischen den zwei Registerdateien zu übertragen).
  • Die lokale Untermenge des L2-Caches 2604 ist Teil eines globalen L2-Caches, der in getrennte lokale Untermengen unterteilt ist, eine pro Prozessorkern. Jeder Prozessorkern weist einen direkten Zugriffspfad zu seiner eigenen lokalen Untermenge des L2-Caches 2604 auf. Von einem Prozessorkern gelesene Daten werden in der zugehörigen Untermenge des L2-Caches 2604 gespeichert und es kann schnell darauf zugegriffen werden, parallel zum Zugreifen anderer Prozessorkerne auf deren Untermengen des lokalen L2-Caches. Von einem Prozessorkern geschriebene Daten werden in dessen eigener Untermenge des L2-Caches 2604 gespeichert und, falls erforderlich, aus anderen Untermengen gelöscht. Das Ringnetz stellt die Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetz ist bidirektional, um es Agenten wie Prozessorkernen, L2-Caches und anderen Logikblöcken zu ermöglichen, chipintern miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012 Bits breit.
  • ist eine erweiterte Ansicht eines Teils des Prozessorkerns aus . umfasst einen L1-Datencache 2606A, Teil des L1-Caches 2604 sowie mehr Einzelheiten hinsichtlich der Vektoreinheit 2610 und der Vektorregister 2614. Insbesondere ist die Vektoreinheit 2610 eine Vektorverarbeitungseinheit (Vector Processing Unit, VPU) mit einer Breite 16 (siehe die ALU 2628 mit Breite 16), die einen oder mehrere Befehle für Ganzzahlen, einfach genaue Gleitkommawerte und doppelt genaue Gleitkommawerte ausführt. Die VPU unterstützt das Swizzeln der Registereingaben mit Swizzle-Einheit 2620, die numerische Umwandlung mit numerischen Umwandlungseinheiten 2622A-B und die Replikation mit einer Replikationseinheit 2624 am Speichereingang. Schreibmaskenregister 2626 erlauben das Vorhersagen von resultierenden Vektorschreibvorgängen.
  • ist ein Blockschaltbild eines Prozessors 2700, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und eine integrierte Grafik aufweisen kann. Die mit einer durchgehenden Linie gekennzeichneten Felder in zeigen einen Prozessor 2700 mit einem einzelnen Kern 2702A, einem Systemagenten 2710, einem Satz von einem oder mehreren Bussteuerungseinheiten 2716, während die optionale Ergänzung der mit einer gestrichelten Linie gekennzeichneten Felder einen alternativen Prozessor 2700 mit mehreren Kernen 2702A-N, einem Satz von einer oder mehreren integrierten Speichersteuerungseinheit(en) 2714 in der Systemagent-Einheit 2710 und einer Speziallogik 2708 zeigt.
  • Somit können unterschiedliche Implementierungen des Prozessors 2700 aufweisen:
    • 1) eine CPU mit der Speziallogik 2708, bei der es sich um eine integrierte Grafik und/oder eine wissenschaftliche (Durchsatz)Logik handelt (die einen oder mehrere Kerne aufweisen kann) und die Kerne 2702A-N, bei denen es sich um einen oder mehrere Universalkern(e) (z. B. universelle In-Order- Kerne, universelle Out-of-Order-Keme, eine Kombination der beiden) handelt; 2) einen Coprozessor, mit den Kernen 2702A-N, bei denen es sich um eine große Anzahl von Spezialkernen handelt, die primär für grafische und/oder wissenschaftliche (Durchsatz)Berechnungen vorgesehen sind; und 3) einen Coprozessor mit den Kernen 2702A-N, bei denen es sich um eine große Anzahl von universellen In-Order-Kernen handelt. Somit kann es sich bei dem Prozessor 2700 um einen Mehrzweckprozessor, einen Coprozessor oder einen Spezialprozessor wie beispielsweise einen Netz- oder Kommunikationsprozessor, eine Kompressionsengine, einen Grafikprozessor, eine GPGPU (General Purpose Graphics Processing Unit), einen durchsatzstarken MIC (Many Integrated Core)-Coprozessor (mit 30 oder mehr Kernen), einen eingebetteten Prozessor oder dergleichen handeln. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 2700 kann Teil eines Substrats sein und/oder unter Verwendung einer Anzahl von Prozesstechnologien wie beispielsweise BiCMOS, CMOS oder NMOS auf einem oder mehreren Substraten implementiert sein.
  • Die Speicherhierarchie weist in den Kernen eine oder mehrere Ebenen von Cache, einen Satz von oder eine oder mehrere gemeinsam genutzte(n) Cache-Einheit(en) 2706 und externen Speicher (nicht gezeigt), der an den Satz von integrierten Speichersteuerungseinheiten 2714 gekoppelt ist, auf. Der Satz von gemeinsam genutzten Cache-Einheiten 2706 kann einen oder mehrere Mid-Level-Cache(s), beispielsweise Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Level, einen Last-Level-Cache (LLC) und/oder Kombinationen davon aufweisen. Während in einem Beispiel eine ringbasierte Verbindungseinheit 2712 die integrierte Grafiklogik 2708, den Satz von gemeinsam genutzten Cache-Einheiten 2706 und die Systemagent-Einheit 2710/die integrierte(n) Speichersteuerungseinheit(en) 2714 untereinander verbindet, können alternative Beispiele eine beliebige Anzahl von bekannten Verfahren für das Verbinden solcher Einheiten verwenden. In einem Beispiel wird die Kohärenz zwischen einer/einem oder mehreren Cache-Einheiten 2706 und Kernen 2702-A-N beibehalten.
  • In einigen Beispielen ist/sind einer oder mehrere der Kerne 2702A-N Multithreadingfähig. Der Systemagent 2710 umfasst diejenigen Komponenten, welche die Kerne 2702A-N koordinieren und betreiben. Die Systemagent-Einheit 2710 kann beispielsweise eine Leistungssteuerungseinheit (Power Control Unit, PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann Logik und Komponenten darstellen oder umfassen, die für das Regeln des Leistungszustands der Kerne 2702A-N und der integrierten Grafiklogik 2708 benötigt werden. Die Anzeigeeinheit hat die Aufgabe, eine oder mehrere extern angeschlossene Anzeigen anzusteuern.
  • Die Kerne 2702A-N können in Bezug auf den Architekturbefehlssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 2702A-N können in der Lage sein, denselben Befehlssatz auszuführen, während andere in der Lage sein können, nur eine Untermenge dieses Befehlssatzes oder einen anderen Befehlssatz auszuführen.
  • bis sind Blockschaltbilder von Computerarchitekturen. Andere Systementwürfe und Konfigurationen nach dem Stand der Technik für Laptops, Desktops, Handheld-PCs, persönliche digitale Assistenten (PDAs), Arbeitsstationen (Engineering Workstations, EWS), Server, Netzvorrichtungen, Netzknoten, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienwiedergabegeräte, Handheld-Vorrichtungen und verschiedene andere elektronische Vorrichtungen, sind ebenfalls geeignet. Im Allgemeinen ist eine enorme Vielzahl von verschiedenen Systemen oder elektronischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder andere Ausführungslogik wie hier offenbart aufzunehmen, geeignet.
  • Es wird nun Bezug genommen auf ; gezeigt wird ein Blockschaltbild eines Systems 2800. Das System 2800 kann einen oder mehrere Prozessoren 2810, 2815 aufweisen, die an einen Steuerungsknoten 2820 gekoppelt sind. In einem Beispiel weist der Steuerungsknoten 2820 einen Grafikspeicher-Steuerungsknoten (Graphics Memory Controller Hub, GMCH) 2890 und einen Eingabe-/Ausgabe-Knoten (Input/Output Hub, IOH) 2850 auf (die auf getrennten Chips vorliegen können); der GMCH 2890 weist Speicher- und Grafiksteuerungen auf, an die Speicher 2840 und ein Coprozessor 2845 gekoppelt sind; der IOH 2850 koppelt Eingabe/Ausgabe (E/A)-Vorrichtungen 2860 an den GMCH 2890. Alternativ sind eine oder beide der Speicher- und Grafiksteuerungen (wie hier beschrieben) im Prozessor integriert, der Speicher 2840 und der Coprozessor 2845 sind direkt an den Prozessor 2810 gekoppelt, und der Steuerungsknoten 2820 befindet sich in einem einzelnen Chip mit dem IOH 2850.
  • Der optionale Charakter zusätzlicher Prozessoren 2815 ist in durch die gestrichelten Linien angegeben. Jeder Prozessor 2810, 2815 kann einen oder mehrere der hier beschriebenen Verarbeitungskerne aufweisen und eine Version des Prozessors 2700 sein.
  • Bei dem Speicher 2840 kann es sich beispielsweise um dynamischen Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM), Phasenwechselspeicher (Phase Change Memory, PCM) oder um eine Kombination der beiden handeln. Bei mindestens einem Beispiel kommuniziert der Steuerungsknoten 2820 mit dem (den) Prozessor(en) 2810, 2815 über einen Multi-Drop-Bus, wie beispielsweise einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie beispielsweise QuickPath Interconnect (QPI), oder eine ähnliche Verbindung 2895.
  • In einem Beispiel ist der Coprozessor 2845 ein Spezialprozessor, wie beispielsweise ein durchsatzstarker MIC-Prozessor, ein Netz- oder Kommunikationsprozessor, eine Kompressionsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einem Beispiel kann der Steuerungsknoten 2820 einen integrierten Grafikbeschleuniger aufweisen.
  • Es kann verschiedene Unterschiede zwischen den physischen Ressourcen 2810, 2815 im Hinblick auf ein Spektrum von Gütemetriken geben, einschließlich architektonische, mikroarchitektonische, thermische, leistungsaufnahmebezogene Eigenschaften und dergleichen.
  • In einem Beispiel führt der Prozessor 2810 Befehle aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In den Befehlen können Coprozessorbefehle eingebettet sein. Der Prozessor 2810 erkennt diese Coprozessorbefehle als Befehle eines Typs, der durch den verbundenen Coprozessor 2845 ausgeführt werden sollte. Dementsprechend gibt der Prozessor 2810 diese Coprozessorbefehle (oder Steuersignale, die Coprozessorbefehle repräsentieren) über einen Coprozessor-Bus oder eine andere Zwischenverbindung an den Coprozessor 2845 aus. Ein oder mehrere Coprozessor(en) 2845 akzeptiert (akzeptieren) die empfangenen Befehle und führt (führen) diese aus.
  • Es wird nun Bezug genommen auf ; gezeigt wird ein Blockschaltbild eines ersten spezifischeren Systems 2900. Wie in gezeigt, ist das Mehrprozessorsystem 2900 ein Punkt-zu-Punkt-Verbindungssystem und weist einen ersten Prozessor 2970 und einen zweiten Prozessor 2980 auf, die über eine Punkt-zu-Punkt-Verbindung 2950 gekoppelt sind. Jeder der Prozessoren 2970 und 2980 kann eine Version des Prozessors 2700 sein. In einem Beispiel sind die Prozessoren 2970 und 2980 die Prozessoren 2810 bzw. 2815, während der Coprozessor 2938 der Coprozessor 2845 ist. In einem anderen Beispiel sind die Prozessoren 2970 und 2980 Prozessor 2810 bzw. Coprozessor 2845.
  • Die Prozessoren 2970 und 2980 werden mit integrierter Speichersteuerungseinheit (Integrated Memory Controller, IMC) 2972 bzw. 2982 gezeigt. Der Prozessor 2970 weist außerdem als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt (P-P)-Schnittstellen 2976 und 2978 auf; in ähnlicher Weise weist der zweite Prozessor 2980 P-P-Schnittstellen 2986 und 2988 auf. Die Prozessoren 2970, 2980 können Informationen über eine Punkt-zu-Punkt (P-P)-Schnittstelle 2950 unter Verwendung von P-P-Schnittstellenschaltungen 2978, 2988 austauschen. Wie in gezeigt, koppeln die IMCs 2972 und 2982 die Prozessoren an die jeweiligen Speicher, nämlich einen Speicher 2932 und einen Speicher 2934, die Teile des lokal mit den jeweiligen Prozessoren verbundenen Hauptspeichers sein können.
  • Die Prozessoren 2970, 2980 können jeder über individuelle P-P-Schnittstellen 2952, 2954 Informationen mit einem Chipsatz 2990 austauschen, wobei Punkt-zu-Punkt-Schnittstellenschaltungen 2976, 2994, 2986, 2998 verwendet werden. Der Chipsatz 2990 kann optional über eine Hochleistungsschnittstelle 2939 Informationen mit dem Coprozessor 2938 austauschen. In einem Beispiel ist der Coprozessor 2938 ein Spezialprozessor, wie beispielsweise ein durchsatzstarker MIC-Prozessor, ein Netz- oder Kommunikationsprozessor, eine Kompressionsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
  • Ein gemeinsam genutzter (nicht gezeigter) Cache kann in jedem Prozessor enthalten sein oder außerhalb beider Prozessoren vorliegen, aber mit den Prozessoren über eine P-P-Verbindung verbunden sein, so dass lokale Cache-Informationen jedes oder beider Prozessoren im gemeinsam genutzten Cache gespeichert werden können, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird. Der Chipsatz 2990 kann über eine Schnittstelle 2996 an einen ersten Bus 2916 gekoppelt sein. In einem Beispiel kann der erste Bus 2916 ein Peripheriegeräteverbindungsbus (Peripheral Component Interconnect, PCI) oder ein Bus wie beispielsweise ein PCI Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein.
  • Wie in gezeigt, können verschiedene E/A-Vorrichtungen 2914 an den ersten Bus 2916 gekoppelt sein, zusammen mit einer Busbrücke 2918, die den ersten Bus 2916 an einen zweiten Bus 2920 koppelt. In einem Beispiel sind ein oder mehrere zusätzliche Prozessoren 2915, beispielsweise Coprozessoren, durchsatzstarke MIC-Prozessoren, GPGPUs, Beschleuniger (wie beispielsweise Grafikbeschleuniger oder digitale Signalverarbeitungseinheiten (Digital Signal Processing Units, DSPs)), feldprogrammierbare Gate-Arrays oder andere Prozessoren an den ersten Bus 2916 gekoppelt. In einem Beispiel kann der zweite Bus 2920 ein Bus mit geringer Stiftzahl (Low Pin Count, LPC) sein. In einem Beispiel können verschiedene Vorrichtungen an einen zweiten Bus 2920 gekoppelt sein, beispielsweise eine Tastatur und/oder eine Maus 2922, Kommunikationsvorrichtungen 2927 und eine Speichereinheit 2928 wie beispielsweise ein Plattenlaufwerk oder eine Massenspeichervorrichtung, die Befehle/Code und Daten 2930 aufweisen kann. Ferner kann ein Audio-E/A 2924 an den zweiten Bus 2920 gekoppelt sein. Es sei darauf hingewiesen, dass auch andere Architekturen möglich sind. So kann ein System beispielsweise anstelle der Punkt-zu-Punkt-Architektur aus einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.
  • Es wird nun Bezug genommen auf ; gezeigt wird ein Blockschaltbild eines zweiten spezifischeren Systems 3000. Gleiche Elemente in und tragen gleiche Bezugsnummern, und bestimmte Aspekte von wurden in ausgelassen, um zu verhindern, dass andere Aspekte von verdeckt werden. veranschaulicht, dass die Prozessoren 2970, 2980 einen integrierten Speicher und eine E/A-Steuerungslogik (Control Logic, „CL“) 2972 bzw. 2982 aufweisen können. Somit weist die CL 2972, 2982 integrierte Speichersteuerungseinheiten und eine E/A-Steuerungslogik auf. veranschaulicht, dass nicht nur die Speicher 2932, 2934 an die CL 2972, 2982 gekoppelt sind, sondern auch, dass die E/A-Vorrichtungen 3014 auch an die Steuerungslogik 2972, 2982 gekoppelt sind. Bisherige E/A-Vorrichtungen 3015 sind an den Chipsatz 2990 gekoppelt.
  • Es wird nun Bezug genommen auf ; gezeigt wird ein SoC 3100. Ähnliche Elemente in tragen ähnliche Referenznummern. Außerdem stehen mit einer gestrichelten Linie gekennzeichnete Felder für optionale Merkmale auf fortschrittlicheren SoCs. In ist (sind) eine Verbindungseinheit(en) 3102 gekoppelt an: einen Anwendungsprozessor 3110, der einen Satz von einem oder mehreren Kern(en) 202A-N und eine (mehrere) gemeinsam genutzte(n) Cache-Einheit(en) 2706 aufweist; eine Systemagent-Einheit 2710; (eine) Bussteuerungseinheit(en) 2716; (eine) integrierte Speichersteuerungseinheit(en) 2714; einen Satz von einem oder mehreren Coprozessoren 3120, der integrierte Grafiklogik aufweisen kann, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor; eine statische Direktzugriffsspeichereinheit (Static Random Access Memory, SRAM) 3130; eine Direktspeicherzugriffseinheit (Direct Memory Access, DMA) 3132; und eine Anzeigeeinheit 3140 für das Ankoppeln an ein oder mehrere externe Anzeigen. In einem Beispiel umfasst (umfassen) der (die) Coprozessor(en) 3120 einen Spezialprozessor wie beispielsweise einen Netzprozessor oder einen Kommunikationsprozessor, eine Kompressionsengine, eine GPGPU, einen durchsatzstarken MIC-Prozessor, einen eingebetteten Prozessor oder dergleichen.
  • Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware implementiert sein oder eine Kombination dieser Implementierungsansätze darstellen. Ausführungsformen der hier Erfindung können als Computerprogramme oder als Programmcode implementiert sein, die/der auf programmierbaren Systemen ausgeführt werden/wird, die wenigstens einen Prozessor, ein Speichersystem (mit flüchtigem und nichtflüchtigem Speicher und/oder Speicherelementen), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
  • Programmcode, beispielsweise der in dargestellte Code 2930, kann auf Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen angewendet werden. Für die Zwecke der Erfindung umfasst ein Verarbeitungssystem ein beliebiges System, das über einen Prozessor verfügt, beispielsweise; einen digitalen Signalprozessor (Digital Signal Processor, DSP), eine Mikrosteuerung, eine anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit, ASIC) oder einen Mikroprozessor.
  • Der Programmcode kann in einer prozeduralen Hochsprache oder in einer objektorientierten Programmiersprache für das Kommunizieren mit einem Verarbeitungssystem implementiert sein. Der Programmcode kann auf Wunsch auch in Assembler- oder Maschinensprache implementiert sein. Tatsächlich sind die hier beschriebenen Mechanismen hinsichtlich des Schutzbereichs nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann es sich bei der Sprache um eine kompilierte oder eine interpretierte Sprache handeln.
  • Ein oder mehrere Aspekt(e) von wenigstens einer Ausführungsform kann (können) durch repräsentative Befehle implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logiken im Prozessor repräsentiert, welche beim Auslesen durch eine Maschine bewirken, dass die Maschine Logik für das Durchführen der hier beschriebenen Verfahren erstellt. Solche Darstellungen, „IP-Kerne“ genannt, können auf einem physischen, maschinenlesbaren Medium gespeichert werden und an verschiedene Kunden oder Fertigungseinrichtungen geliefert werden, damit sie dort in die Fertigungsmaschinen geladen werden, die tatsächlich die Logik oder den Prozessor ausmachen.
  • Ein solches maschinenlesbares Medium kann, ohne Einschränkung, nichtflüchtige, physische Anordnungen von Artikeln umfassen, die von einer Maschine oder einer Vorrichtung gefertigt oder geformt werden, einschließlich Speichermedien wie beispielsweise Festplatten, irgendeine andere Art von Platte einschließlich Disketten, optische Platten, Kompakt-Disk-Festwertspeicher (Compact Disk Read-only Memories, CD-ROMs), wiederbeschreibbare Kompakt-Disks (Compact Disk Rewritables, CD-RWs) und magnetooptische Platten, Halbleitervorrichtungen wie beispielsweise Festwertspeicher (Read-only Memories, ROMs), Direktzugriffsspeicher (Random Access Memories, RAMs) wie beispielsweise dynamische Direktzugriffsspeicher (Dynamic Random Access Memories, DRAMs), statische Direktzugriffsspeicher (Static Random Access Memories, SRAMs), löschbare programmierbare Festwertspeicher (Erasable Programmable Read-only Memories, EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Festwertspeicher (Electrically Erasable Programmable Read-only Memories, EEPROMs), Phasenwechselspeicher (Phase Change Memory, PCM), magnetische oder optische Karten oder irgendeine andere Art von Medien, die sich für das Speichern elektronischer Befehle eignen.
  • Entsprechend umfassen Ausführungsformen der Erfindung auch nichtflüchtige, physische maschinenlesbare Medien, die Befehle oder Entwurfsdaten enthalten, beispielsweise eine Hardware-Beschreibungssprache (Hardware Description Language, HDL), welche die hier beschriebenen Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • In einigen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. So kann der Befehlsumwandler einen Befehl für das Verarbeiten durch den Kern in einen oder mehrere andere Befehle übersetzen (z. B. unter Verwendung einer statischen binären Übersetzung, einer dynamischen binären Übersetzung einschließlich einer dynamischen Kompilierung), umformen, emulieren oder sonstwie umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Bei dem Befehlsumwandler kann es sich um einen On-Prozessor, einen Off-Prozessor oder teilweise um einen On- und teilweise um einen Off-Prozessor handeln.
  • ist ein Blockschaltbild, das die Verwendung eines Software-Befehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz gegenüberstellt. In dem dargestellten Beispiel ist der Befehlsumwandler ein Software-Befehlsumwandler, wenngleich der Befehlsumwandler alternativ auch in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert sein kann. zeigt, dass ein Programm in einer Hochsprache 3202 unter Verwendung eines x86-Kompilierers 3204 kompiliert werden kann, um x86-Binärcode 3206 zu erzeugen, der nativ von einem Prozessor mit wenigstens einem x86-Befehlssatzkern 3216 ausgeführt werden kann. Der Prozessor mit wenigstens einem x86-Befehlssatzkern 3216 repräsentiert jeden Prozessor, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern durchführen kann, indem dieser Prozessor in kompatibler Weise oder sonstwie (1) einen wesentlichen Teil des Befehlssatzes des Intel x86-Befehlssatzskerns verarbeitet oder (2) Objektcode-Versionen von Anwendungen oder andere Software, die für das Ausführen auf einem Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern vorgesehen ist, ausführt, um im Wesentlichen dasselbe Ergebnis zu erzielen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern. Der x86-Kompilierer 3204 repräsentiert einen Kompilierer, der betrieben werden kann, um x86-Binärcode 3206 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Verknüpfungsverarbeitung auf dem Prozessor mit wenigstens einem x86-Befehlssatzkern 3216 ausgeführt werden kann. In ähnlicher Weise zeigt , dass das Programm in der Hochsprache 3202 unter Verwendung eines alternativen Befehlssatz-Kompilierers 3208 kompiliert werden kann, um alternativen Befehlssatz-Binärcode 3210 zu erzeugen, der von einem Prozessor mit wenigstens einem x86-Befehlssatzkern 3214 nativ ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, Kalifornien, ausführen und/oder den ARM-Befehlssatz von ARM Holdings aus Sunnyvale, Kalifornien, ausführen). Der Befehlsumwandler 3212 wird verwendet, um den x86-Binärcode 3206 in Code umzuwandeln, der vom Prozessor ohne einen x86-Befehlssatzkern 3214 nativ ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht identisch mit dem alternativen Befehlssatz-Binärcode 3210, weil ein Befehlsumwandler, der hierzu in der Lage wäre, schwer herzustellen ist; allerdings wird der umgewandelte Code den allgemeinen Betrieb bewältigen und sich aus Befehlen aus dem alternativen Befehlssatz zusammensetzen. Somit repräsentiert der Befehlsumwandler 3212 Software, Firmware, Hardware oder eine Kombination davon, die es, durch Emulation, Simulation oder einen anderen Prozess, einem Prozessor oder einer anderen elektronischen Vorrichtung, der bzw. die keinen x86-Befehlssatzprozessor oder -kern aufweist, ermöglicht, den x86-Binärcode 3206 auszuführen.
  • Gemäß einem nichtbeanspruchten Beispiel weist ein Prozessor einen Befehlsdecodierer für das Decodieren eines ersten Befehls zum Sammeln von Datenelementen aus einem Speicher auf, wobei der erste Befehl über einen ersten Operanden verfügt, der einen ersten Speicherort spezifiziert, und über einen zweiten Operanden, der eine erste Speicheradresse spezifiziert, die mehrere Datenelemente speichert. Der Prozessor weist ferner eine Ausführungseinheit auf, die an den Befehlsdecodierer gekoppelt ist, um in Reaktion auf den ersten Befehl ein erstes und ein zweites der Datenelemente zusammenhängend von einem Speicherort auszulesen, basierend auf der ersten Speicheradresse, die durch den zweiten Operanden angegeben ist, und um das erste Datenelement in einem ersten Eintrag des ersten Speicherortes und ein zweites Datenelement in einem zweiten Eintrag eines zweiten Speicherortes entsprechend dem ersten Eintrag des ersten Speicherortes zu speichern. In einem Beispiel umfasst der erste Befehl ferner einen dritten Operanden, der den zweiten Speicherort spezifiziert. In einem Beispiel decodiert der Befehlsdecodierer ferner einen zweiten Befehl mit einem dritten Operanden, der den zweiten Speicherort spezifiziert, und mit einem vierten Operanden, der eine zweite Speicheradresse spezifiziert, wobei die zweite Speicheradresse zu der ersten Speicheradresse um die Größe eines einzelnen Datenelements versetzt ist. Gemäß einem Aspekt der Erfindung umfasst der erste Befehl ferner ein Präfix, das dem Befehlsdecodierer und der Ausführungseinheit angibt, dass der zweite Befehl folgt. In einem anderen Beispiel sagt die Ausführungseinheit vorher, dass der zweite Befehl existiert. In einem Beispiel folgen der erste Eintrag des ersten Speicherortes und der zweite Eintrag des zweiten Speicherortes nicht direkt aufeinander, wobei der zweite Speicherort durch den ersten Operanden spezifiziert ist. Gemäß einem Beispiel wird das erste Datenelement in einem dritten Eintrag eines dritten Speicherortes gespeichert, bevor dieses Datenelement im ersten Eintrag des ersten Speicherortes gespeichert wird, und das zweite Datenelement wird in einem vierten Eintrag eines vierten Speicherortes gespeichert, bevor dieses Datenelement im zweiten Eintrag des zweiten Speicherortes gespeichert wird.
  • Einige Teile der vorstehenden ausführlichen Beschreibungen sind hier in Bezug auf Algorithmen und symbolische Darstellungen von Operationen für Datenbits in einem Computerspeicher vorgestellt worden. Diese algorithmischen Beschreibungen und Darstellungen stehen für die Verfahren, die Fachleute auf dem Gebiet der Datenverarbeitung verwenden, um die Substanz ihrer Arbeit möglichst effektiv an andere Fachleute zu vermitteln. Unter einem Algorithmus versteht man hier und allgemein eine in sich konsistente Folge von Operationen, die zu einem gewünschten Ergebnis führt. Bei den Operationen handelt es sich um Operationen, die physische Manipulationen von physischen Mengen erfordern.
  • Es sollte jedoch bedacht werden, dass alle diese und ähnliche Begriffe mit den entsprechenden physischen Mengen in Verbindung zu bringen sind und es sich hierbei nur um zweckmäßige Kennzeichnungen handelt, die auf diese Mengen angewendet werden. Soweit nicht ausdrücklich anders angegeben oder aus der vorstehenden Besprechung ersichtlich, versteht es sich, dass sich in der gesamten Beschreibung Erörterungen, in denen Begriffe wie die in den nachstehenden Patenansprüchen dargelegten Begriffe verwendet werden, auf die Aktion und Prozesse eines Computersystems oder einer ähnlichen elektronischen Verarbeitungsvorrichtung beziehen, die als physische (elektronische) Mengen in den Registern und Speichern des Computersystems dargestellte Daten manipuliert und in andere Daten umwandelt, die in ähnlicher Weise als physische Mengen in den Speichern und Registern des Computersystems oder anderen derartigen Informationsspeichern, Übertragungs- oder Anzeigevorrichtungen dargestellt sind.
  • Die in den Abbildungen gezeigten Verfahren können unter Verwendung von Code und Daten implementiert werden, die in einer oder mehreren elektronischen Vorrichtungen gespeichert und ausgeführt werden. Derartige elektronische Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netz) Code und Daten unter Verwendung von computerlesbaren Medien wie beispielsweise nichtflüchtige computerlesbare Speichermedien (z. B. Magnetplatten; optische Datenträger; Speicher mit wahlfreiem Zugriff; Festwertspeicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und flüchtige computerlesbare Übertragungsmedien (z. B. elektrische, optische, akustische Signale oder Signale anderer Form - beispielsweise Trägerwellen, Infrarotsignale, Digitalsignale).
  • Die in den vorstehenden Abbildungen gezeigten Prozesse oder Verfahren können durch Verarbeitungslogik durchgeführt werden, die Hardware umfasst (z. B. Schaltungen, dedizierte Logik etc.), Firmware, Software (z. B. auf einem nichtflüchtigen computerlesbaren Medium vorliegend) oder eine Kombination beider. Auch wenn die Prozesse oder Verfahren vorstehend in Bezug auf einige sequenzielle Operationen beschrieben werden, sei an dieser Stelle darauf hingewiesen, dass einige der hier beschriebenen Operationen unter Umständen auch in anderer Reihenfolge durchgeführt werden können. Darüber hinaus können einige Operationen parallel anstatt sequenziell durchgeführt werden.
  • In der vorstehenden Spezifikation sind Ausführungsformen der Erfindung in Bezug auf spezifische Ausführungsformen davon beschrieben worden. Es ist offensichtlich, dass verschiedene Modifikationen hieran vorgenommen werden können, ohne vom breiteren Grundgedanken und Schutzbereich der Erfindung abzuweichen, wie sie in den nachstehenden Ansprüchen dargelegt sind. Die Spezifikation und Zeichnungen sind dementsprechend in einem veranschaulichenden Sinne und nicht in einem einschränkenden Sinne zu betrachten.

Claims (12)

  1. Prozessor (200), umfassend: einen Befehlsdecodierer (202), um einen ersten Befehl (210) zum Sammeln von Datenelementen aus einem Speicher (206) zu decodieren, wobei der erste Befehl (210) einen ersten Operanden, der einen ersten Speicherort spezifiziert, und einen zweiten Operanden aufweist, der eine erste Speicheradresse spezifiziert, die mehrere Datenelemente speichert; eine Ausführungseinheit (204), die an den Befehlsdecodierer (202) gekoppelt ist, um in Reaktion auf den ersten und einen zweiten Befehl (210) ein erstes und ein zweites der Datenelemente zusammenhängend von einem Speicherort auszulesen, basierend auf der ersten Speicheradresse, die durch den zweiten Operanden angegeben ist, und um das erste Datenelement in einem ersten Eintrag des ersten Speicherortes und ein zweites Datenelement in einem ersten Eintrag eines zweiten Speicherortes entsprechend dem ersten Eintrag des ersten Speicherortes zu speichern, wobei der Befehlsdecodierer ferner den zweiten Befehl mit einem dritten Operanden decodiert, der den zweiten Speicherort spezifiziert, und mit einem vierten Operanden, der eine zweite Speicheradresse spezifiziert, wobei die zweite Speicheradresse zu der ersten Speicheradresse um die Größe eines einzelnen Datenelements versetzt ist, wobei der erste Befehl ferner ein Präfix umfasst, das dem Befehlsdecodierer und der Ausführungseinheit angibt, dass der zweite Befehl auf den ersten Befehl folgt und der erste Befehl zu puffern ist, bis der zweite Befehl ankommt, und wobei der zweite Befehl das Präfix nicht umfasst.
  2. Prozessor nach Anspruch 1, wobei die Ausführungseinheit vorhersagt, dass der zweite Befehl auf den ersten Befehl folgt.
  3. Prozessor nach Ansprach 1, wobei der erste Eintrag des ersten Speicherortes und der zweite Eintrag des zweiten Speicherortes nicht zusammenhängend sind, und wobei der zweite Speicherort durch den ersten Operanden spezifiziert ist.
  4. Prozessor nach Ansprach 1, wobei das erste Datenelement in einem dritten Eintrag eines dritten Speicherortes gespeichert wird, bevor dieses Datenelement im ersten Eintrag des ersten Speicherortes gespeichert wird, und wobei das zweite Datenelement in einem vierten Eintrag eines vierten Speicherortes gespeichert wird, bevor dieses Datenelement im zweiten Eintrag des zweiten Speicherortes gespeichert wird.
  5. Verfahren (500), umfassend: Decodieren (505) eines ersten Befehls zum Sammeln von Datenelementen aus einem Speicher, wobei der erste Befehl einen ersten Operanden, der einen ersten Speicherort spezifiziert, und einen zweiten Operanden aufweist, der eine erste Speicheradresse spezifiziert, die mehrere Datenelemente speichert; zusammenhängendes Lesen (510), in Reaktion auf den ersten und einen zweiten Befehl, eines ersten und eines zweiten der Datenelemente aus einem Speicherort basierend auf der ersten Speicheradresse, die durch den zweiten Operanden angegeben ist; und Speichern (515) des ersten Datenelements in einem ersten Eintrag des ersten Speicherortes und eines zweiten Datenelements in einem ersten Eintrag eines zweiten Speicherortes entsprechend dem ersten Eintrag des ersten Speicherortes, wobei der Befehlsdecodierer ferner den zweiten Befehl mit einem dritten Operanden decodiert, der den zweiten Speicherort spezifiziert, und mit einem vierten Operanden, der eine zweite Speicheradresse spezifiziert, wobei die zweite Speicheradresse zu der ersten Speicheradresse um die Größe eines einzelnen Datenelements versetzt ist, wobei der erste Befehl ferner ein Präfix umfasst, das dem Befehlsdecodierer und der Ausführungseinheit angibt, dass der zweite Befehl auf den ersten Befehl folgt und der erste Befehl zu puffern ist, bis der zweite Befehl ankommt, und wobei der zweite Befehl das Präfix nicht umfasst.
  6. Verfahren nach Anspruch 5, wobei die Ausführungseinheit vorhersagt, dass der zweite Befehl auf den ersten Befehl folgt.
  7. Verfahren nach Anspruch 5, wobei der erste Eintrag des ersten Speicherortes und der zweite Eintrag des zweiten Speicherortes nicht zusammenhängend sind, und wobei der zweite Speicherort durch den ersten Operanden spezifiziert ist.
  8. Verfahren nach Anspruch 5, wobei das erste Datenelement in einem dritten Eintrag eines dritten Speicherortes gespeichert wird, bevor dieses Datenelement im ersten Eintrag des ersten Speicherortes gespeichert wird, und wobei das zweite Datenelement in einem vierten Eintrag eines vierten Speicherortes gespeichert wird, bevor dieses Datenelement im ersten Eintrag des zweiten Speicherortes gespeichert wird.
  9. Datenverarbeitungssystem, umfassend: eine Zwischenverbindung; einen an die Zwischenverbindung gekoppelten dynamischen Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM); und einen an die Zwischenverbindung gekoppelten Prozessor, umfassend einen Befehlsdecodierer für das Decodieren eines ersten Befehls zum Sammeln von Datenelementen aus einem Speicher, wobei der erste Befehl über einen ersten Operanden verfügt, der einen ersten Speicherort spezifiziert, und über einen zweiten Operanden, der eine erste Speicheradresse spezifiziert, die mehrere Datenelemente speichert; eine Ausführungseinheit, die an den Befehlsdecodierer gekoppelt ist, um in Reaktion auf den ersten und einen Befehl ein erstes und ein zweites der Datenelemente zusammenhängend von einem Speicherort auszulesen, basierend auf der ersten Speicheradresse, die durch den zweiten Operanden angegeben ist, und um das erste Datenelement in einem ersten Eintrag des ersten Speicherortes und ein zweites Datenelement in einem ersten Eintrag eines zweiten Speicherortes entsprechend dem ersten Eintrag des ersten Speicherortes zu speichern, wobei der Befehlsdecodierer ferner den zweiten Befehl mit einem dritten Operanden decodiert, der den zweiten Speicherort spezifiziert, und mit einem vierten Operanden, der eine zweite Speicheradresse spezifiziert, wobei die zweite Speicheradresse zu der ersten Speicheradresse um die Größe eines einzelnen Datenelements versetzt ist, wobei der erste Befehl ferner ein Präfix umfasst, das dem Befehlsdecodierer und der Ausführungseinheit angibt, dass der zweite Befehl auf den ersten Befehl folgt und der erste Befehl zu puffern ist, bis der zweite Befehl ankommt, und wobei der zweite Befehl das Präfix nicht umfasst.
  10. Datenverarbeitungssystem nach Anspruch 9, wobei die Ausführungseinheit vorhersagt, dass der zweite Befehl auf den ersten Befehl folgt.
  11. Datenverarbeitungssystem nach Anspruch 9, wobei der erste Eintrag des ersten Speicherortes und der erste Eintrag des zweiten Speicherortes nicht zusammenhängend sind, und wobei der zweite Speicherort durch den ersten Operanden spezifiziert ist.
  12. Datenverarbeitungssystem nach Anspruch 9, wobei das erste Datenelement in einem dritten Eintrag eines dritten Speicherortes gespeichert wird, bevor dieses Datenelement im ersten Eintrag des ersten Speicherortes gespeichert wird, und wobei das zweite Datenelement in einem vierten Eintrag eines vierten Speicherortes gespeichert wird, bevor dieses Datenelement im ersten Eintrag des zweiten Speicherortes gespeichert wird.
DE112012007063.1T 2012-12-26 2012-12-26 Zusammenfügen von benachbarten Sammel-/Streuoperationen Active DE112012007063B4 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2012/071688 WO2014105011A1 (en) 2012-12-26 2012-12-26 Coalescing adjacent gather/scatter operations

Publications (2)

Publication Number Publication Date
DE112012007063T5 DE112012007063T5 (de) 2015-08-06
DE112012007063B4 true DE112012007063B4 (de) 2022-12-15

Family

ID=50976095

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112012007063.1T Active DE112012007063B4 (de) 2012-12-26 2012-12-26 Zusammenfügen von benachbarten Sammel-/Streuoperationen

Country Status (5)

Country Link
US (13) US9348601B2 (de)
KR (2) KR20150064197A (de)
CN (2) CN107562444B (de)
DE (1) DE112012007063B4 (de)
WO (1) WO2014105011A1 (de)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8515052B2 (en) 2007-12-17 2013-08-20 Wai Wu Parallel signal processing system and method
US9378560B2 (en) * 2011-06-17 2016-06-28 Advanced Micro Devices, Inc. Real time on-chip texture decompression using shader processors
DE112012007063B4 (de) 2012-12-26 2022-12-15 Intel Corp. Zusammenfügen von benachbarten Sammel-/Streuoperationen
US9639503B2 (en) * 2013-03-15 2017-05-02 Qualcomm Incorporated Vector indirect element vertical addressing mode with horizontal permute
US9244684B2 (en) 2013-03-15 2016-01-26 Intel Corporation Limited range vector memory access instructions, processors, methods, and systems
BR112015027741A2 (pt) 2013-05-31 2017-07-25 Intel Corp cache coerente de sistema com capacidade para dispersar/reunir
US9411600B2 (en) * 2013-12-08 2016-08-09 Intel Corporation Instructions and logic to provide memory access key protection functionality
US9600442B2 (en) 2014-07-18 2017-03-21 Intel Corporation No-locality hint vector memory access processors, methods, systems, and instructions
US20160093297A1 (en) * 2014-09-26 2016-03-31 Michael E. Deisher Method and apparatus for efficient, low power finite state transducer decoding
US9875214B2 (en) * 2015-07-31 2018-01-23 Arm Limited Apparatus and method for transferring a plurality of data structures between memory and a plurality of vector registers
US10503502B2 (en) 2015-09-25 2019-12-10 Intel Corporation Data element rearrangement, processors, methods, systems, and instructions
GB2543304B (en) * 2015-10-14 2020-10-28 Advanced Risc Mach Ltd Move prefix instruction
GB2543303B (en) * 2015-10-14 2017-12-27 Advanced Risc Mach Ltd Vector data transfer instruction
US20170116154A1 (en) * 2015-10-23 2017-04-27 The Intellisis Corporation Register communication in a network-on-a-chip architecture
US9946541B2 (en) * 2015-12-18 2018-04-17 Intel Corporation Systems, apparatuses, and method for strided access
US10338920B2 (en) * 2015-12-18 2019-07-02 Intel Corporation Instructions and logic for get-multiple-vector-elements operations
US10152321B2 (en) * 2015-12-18 2018-12-11 Intel Corporation Instructions and logic for blend and permute operation sequences
US20170177350A1 (en) * 2015-12-18 2017-06-22 Intel Corporation Instructions and Logic for Set-Multiple-Vector-Elements Operations
US20170177364A1 (en) * 2015-12-20 2017-06-22 Intel Corporation Instruction and Logic for Reoccurring Adjacent Gathers
US20170177360A1 (en) * 2015-12-21 2017-06-22 Intel Corporation Instructions and Logic for Load-Indices-and-Scatter Operations
US20170177349A1 (en) * 2015-12-21 2017-06-22 Intel Corporation Instructions and Logic for Load-Indices-and-Prefetch-Gathers Operations
US20170177359A1 (en) * 2015-12-21 2017-06-22 Intel Corporation Instructions and Logic for Lane-Based Strided Scatter Operations
US20170177543A1 (en) * 2015-12-22 2017-06-22 Intel Corporation Aggregate scatter instructions
US10019262B2 (en) 2015-12-22 2018-07-10 Intel Corporation Vector store/load instructions for array of structures
US10289416B2 (en) * 2015-12-30 2019-05-14 Intel Corporation Systems, apparatuses, and methods for lane-based strided gather
US20170192782A1 (en) * 2015-12-30 2017-07-06 Robert Valentine Systems, Apparatuses, and Methods for Aggregate Gather and Stride
US10296416B2 (en) * 2016-07-02 2019-05-21 Intel Corporation Read from memory instructions, processors, methods, and systems, that do not take exception on defective data
GB2552154B (en) 2016-07-08 2019-03-06 Advanced Risc Mach Ltd Vector register access
GB2552153B (en) * 2016-07-08 2019-07-24 Advanced Risc Mach Ltd An apparatus and method for performing a rearrangement operation
US20180173527A1 (en) * 2016-12-15 2018-06-21 Optimum Semiconductor Technologies, Inc. Floating point instruction format with embedded rounding rule
WO2018158603A1 (en) * 2017-02-28 2018-09-07 Intel Corporation Strideshift instruction for transposing bits inside vector register
US10191740B2 (en) 2017-02-28 2019-01-29 Intel Corporation Deinterleave strided data elements processors, methods, systems, and instructions
US10795836B2 (en) 2017-04-17 2020-10-06 Microsoft Technology Licensing, Llc Data processing performance enhancement for neural networks using a virtualized data iterator
CN107341372B (zh) * 2017-07-25 2018-12-07 北京深思数盾科技股份有限公司 一种软件保护方法和装置
US10643707B2 (en) * 2017-07-25 2020-05-05 Western Digital Technologies, Inc. Group write operations for a data storage device
US10747844B2 (en) * 2017-12-12 2020-08-18 Tesla, Inc. Systems and methods for converting a matrix input to a vectorized input for a matrix processor
US20200004535A1 (en) * 2018-06-30 2020-01-02 Intel Corporation Accelerator apparatus and method for decoding and de-serializing bit-packed data
US10838734B2 (en) * 2018-09-24 2020-11-17 Intel Corporation Apparatus and method for processing structure of arrays (SoA) and array of structures (AoS) data
US10963189B1 (en) * 2018-11-18 2021-03-30 Pure Storage, Inc. Coalescing write operations in a cloud-based storage system
US11093438B2 (en) * 2019-01-07 2021-08-17 International Business Machines Corporation Pipelining multi-directional reduction
US20220100484A1 (en) * 2019-01-25 2022-03-31 The Regents Of The University Of California Coalescing Operand Register File for Graphical Processing Units
CN113626082A (zh) * 2020-05-08 2021-11-09 安徽寒武纪信息科技有限公司 数据处理方法及装置以及相关产品
CN113626083B (zh) * 2020-05-08 2023-10-13 安徽寒武纪信息科技有限公司 数据处理装置以及相关产品
US11567767B2 (en) 2020-07-30 2023-01-31 Marvell Asia Pte, Ltd. Method and apparatus for front end gather/scatter memory coalescing
US11567771B2 (en) * 2020-07-30 2023-01-31 Marvell Asia Pte, Ltd. Method and apparatus for back end gather/scatter memory coalescing
US12056044B2 (en) 2022-10-28 2024-08-06 Hewlett Packard Enterprise Development Lp Mechanism to represent data structures for a datatype engine and provide inline compaction

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050125640A1 (en) 2003-12-09 2005-06-09 Arm Limited Data processing apparatus and method for moving data between registers and memory

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734874A (en) 1994-04-29 1998-03-31 Sun Microsystems, Inc. Central processing unit with integrated graphics functions
US6542918B1 (en) * 1996-06-21 2003-04-01 Ramot At Tel Aviv University Ltd. Prefix sums and an application thereof
US6857061B1 (en) * 2000-04-07 2005-02-15 Nintendo Co., Ltd. Method and apparatus for obtaining a scalar value directly from a vector register
US20030023960A1 (en) * 2001-07-25 2003-01-30 Shoab Khan Microprocessor instruction format using combination opcodes and destination prefixes
US7017032B2 (en) * 2001-06-11 2006-03-21 Broadcom Corporation Setting execution conditions
AU2003228069A1 (en) * 2002-05-24 2003-12-12 Koninklijke Philips Electronics N.V. A scalar/vector processor
US7293056B2 (en) 2002-12-18 2007-11-06 Intel Corporation Variable width, at least six-way addition/accumulation instructions
US7275148B2 (en) * 2003-09-08 2007-09-25 Freescale Semiconductor, Inc. Data processing system using multiple addressing modes for SIMD operations and method thereof
GB2409059B (en) * 2003-12-09 2006-09-27 Advanced Risc Mach Ltd A data processing apparatus and method for moving data between registers and memory
US7260702B2 (en) 2004-06-30 2007-08-21 Microsoft Corporation Systems and methods for running a legacy 32-bit x86 virtual machine on a 64-bit x86 processor
US8838528B2 (en) * 2006-05-22 2014-09-16 Inmage Systems, Inc. Coalescing and capturing data between events prior to and after a temporal window
US7984273B2 (en) 2007-12-31 2011-07-19 Intel Corporation System and method for using a mask register to track progress of gathering elements from memory
US8447962B2 (en) 2009-12-22 2013-05-21 Intel Corporation Gathering and scattering multiple data elements
US10387151B2 (en) 2007-12-31 2019-08-20 Intel Corporation Processor and method for tracking progress of gathering/scattering data element pairs in different cache memory banks
US20090198885A1 (en) * 2008-02-04 2009-08-06 Manoj Jose K System and methods for host software stripe management in a striped storage subsystem
US8150865B2 (en) 2008-07-29 2012-04-03 Oracle International Corporation Techniques for coalescing subqueries
US8140478B2 (en) * 2009-01-29 2012-03-20 Microsoft Corporation Commit rate management with decoupled commit operations
US8275966B2 (en) * 2009-07-30 2012-09-25 Cleversafe, Inc. Dispersed storage network virtual address generations
US8549264B2 (en) * 2009-12-22 2013-10-01 Intel Corporation Add instructions to add three source operands
US8627065B2 (en) * 2010-11-09 2014-01-07 Cleversafe, Inc. Validating a certificate chain in a dispersed storage network
US9727471B2 (en) 2010-11-29 2017-08-08 Intel Corporation Method and apparatus for stream buffer management instructions
US8972698B2 (en) 2010-12-22 2015-03-03 Intel Corporation Vector conflict instructions
CN103827813B (zh) 2011-09-26 2016-09-21 英特尔公司 用于提供向量分散操作和聚集操作功能的指令和逻辑
US9110833B2 (en) * 2012-06-25 2015-08-18 Cleversafe, Inc. Non-temporarily storing temporarily stored data in a dispersed storage network
DE112012007063B4 (de) 2012-12-26 2022-12-15 Intel Corp. Zusammenfügen von benachbarten Sammel-/Streuoperationen

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050125640A1 (en) 2003-12-09 2005-06-09 Arm Limited Data processing apparatus and method for moving data between registers and memory

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Intel: Intel® Fortran Compiler XE 12.1 User and Reference Guides. XE 12.1. USA, 2011 (323276-121US). - Firmenschrift. https://scc.ustc.edu.cn/zlsc/sugon/intel/compiler_f/main_for/optaps/common/optaps_vec_keys.htm [abgerufen am 22.01.2020]
Rickards, Ian: ARM Architecture & NEON, Stanford University, 2010. URL: http://mercury.pr.erau.edu/~siewerts/cs332/documents/ARM-ASM/ARM-Tutorials/lect.10.arm_soc.pdf [abgerufen am 22.01.2020]
Shaaban, Muhammad: Introduction to Vector Processing, Advanced Computer Architecture (EECC 722), Rochester Institute of Technology, 01.10.2012. URL: http://meseec.ce.rit.edu/eecc722-fall2012/ [abgerufen am 22.01.2020]
Shahbahrami, Asadollah; Juurlink, Ben; Vassiliadis, Stamatis: Versatility of Extended Subwords and the Matrix Register File. In: ACM Trans. Archit. Code Optim., 5, 2008, 1, S. 5:1 - 5:30. - ISSN 1544-3566. https://doi.org/10.1145/1369396.1369401 [abgerufen am 23.01.2020]

Also Published As

Publication number Publication date
US9575765B2 (en) 2017-02-21
US20160124749A1 (en) 2016-05-05
US10275257B2 (en) 2019-04-30
DE112012007063T5 (de) 2015-08-06
WO2014105011A1 (en) 2014-07-03
US9658856B2 (en) 2017-05-23
US20210406026A1 (en) 2021-12-30
US9645826B2 (en) 2017-05-09
US11003455B2 (en) 2021-05-11
KR20170038133A (ko) 2017-04-05
US9626193B2 (en) 2017-04-18
KR20150064197A (ko) 2015-06-10
US20160103786A1 (en) 2016-04-14
US9348601B2 (en) 2016-05-24
US20160103788A1 (en) 2016-04-14
US20160110196A1 (en) 2016-04-21
US9626192B2 (en) 2017-04-18
US11599362B2 (en) 2023-03-07
US20230137812A1 (en) 2023-05-04
US20160103787A1 (en) 2016-04-14
US20160103789A1 (en) 2016-04-14
US20160103790A1 (en) 2016-04-14
US20170255470A1 (en) 2017-09-07
US20140181464A1 (en) 2014-06-26
US20190250921A1 (en) 2019-08-15
CN104756068A (zh) 2015-07-01
KR101877190B1 (ko) 2018-07-10
US9612842B2 (en) 2017-04-04
US9632792B2 (en) 2017-04-25
CN107562444A (zh) 2018-01-09
US20160103684A1 (en) 2016-04-14
CN107562444B (zh) 2020-12-18
CN104756068B (zh) 2018-08-17
US9563429B2 (en) 2017-02-07

Similar Documents

Publication Publication Date Title
DE112012007063B4 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE112013004798B4 (de) Befehlssatz zur Nachrichtenplanung des SHA256-Algorithmus
DE102018005977A1 (de) Gleitkomma- zu festkomma-umwandlung
DE112013005188B4 (de) Prozessor und vefrahren zur vektorisierung von zusammengeführten, mehrfach geschachtelten schleifen
DE112017001804T5 (de) Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand
DE112011105122T5 (de) Systeme, Vorrichtungen und Verfahren zum Vermischen zweier Quelloperanden in einem einzigen Ziel unter Verwendung einer Schreibmaske
DE112012007119T5 (de) Threadmigration-Unterstützung für Kerne unterschiedlicher Architektur
DE102014003706A1 (de) BEREICHSBEGRENZTE VEKTORSPEICHERZUGRIFFSINSTRUKTIONEN, PROZESSOREN, VERFAHREN und SYSTEME
DE102019109845A1 (de) Vereinheitlichte Beschleunigung eines Blockgeheimcodes eines symmetrischen Schlüssels für AES-SMS4-Camellia
DE102015006863A1 (de) Befehle und Logik zum Unterbrechen und Wiederaufnehmen von Paging in Secure Enclaves
DE102019100009A1 (de) Vereinheitlichter Hardwarebeschleuniger für Verschlüsselungssysteme mit symmetrischen Schlüsseln
DE102018125817A1 (de) Systeme und Verfahren zum Laden eines Kachelregisterpaars
DE112014006508T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen für Fliesskommaaddition mit drei Quellenoperanden
DE102015002215A1 (de) Sortierbeschleunigungsprozessor, -Verfahren, -Systeme und -Befehle
DE112011105121T5 (de) Systeme, Vorrichtungen und Verfahren zum Schrittmustersammeln von Datenelementen und Schrittmusterstreuen von Datenelementen
DE112012007058T5 (de) Vektormaskengesteuertes Clock-Gating für Leistungseffizenz eines Prozessors
DE102018125232A1 (de) Einrichtung und Verfahren für komplexe Multiplikation und Akkumulation
DE112013004796T5 (de) Befehlssatz für die SHA1-Rundenverarbeitung in 128 Bit-Datenwegen
DE102018124945A1 (de) Einrichtung und verfahren für komplexe multiplikation
DE112012001542T5 (de) System, Vorrichtung und Verfahren zum Ausrichten von Registern
DE112013003741T5 (de) Systeme, Vorrichtungen und Verfahren zum Durchführen einer Konfliktdetektion unf einer Übertragung von Inhalten eines Registers an Datenelementpositionen eines anderen Registers
DE112013003713T5 (de) Befehlssatz für SKEIN256 SHA3-Algorithmus auf einem 128-Bit-Prozessor
DE102015007422A1 (de) Befehlssatz zum Eliminieren fehlausgerichteter Speicherzugriffe während der Verarbeitung eines Arrays mit fehlausgerichteten Datenzeilen
DE112017003347T5 (de) Systeme, Vorrichtungen und Verfahren für Strided-Ladevorgänge
DE112017000983T5 (de) System und Verfahren zum Ausführen eines Befehls zum Permutieren einer Maske

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R130 Divisional application to

Ref document number: 112012007384

Country of ref document: DE

Ref document number: 112012007364

Country of ref document: DE

R082 Change of representative

Representative=s name: SAMSON & PARTNER PATENTANWAELTE MBB, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R130 Divisional application to

Ref document number: 112012007364

Country of ref document: DE

Ref document number: 112012007384

Country of ref document: DE

R020 Patent grant now final