DE112011105666T5 - Befehl und Logik zum Bereitstellen von Vektor-Lade-OP/Speicher-OP mit Schritt-Funktionalität - Google Patents

Befehl und Logik zum Bereitstellen von Vektor-Lade-OP/Speicher-OP mit Schritt-Funktionalität Download PDF

Info

Publication number
DE112011105666T5
DE112011105666T5 DE112011105666.4T DE112011105666T DE112011105666T5 DE 112011105666 T5 DE112011105666 T5 DE 112011105666T5 DE 112011105666 T DE112011105666 T DE 112011105666T DE 112011105666 T5 DE112011105666 T5 DE 112011105666T5
Authority
DE
Germany
Prior art keywords
register
data
value
memory
processor
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.)
Ceased
Application number
DE112011105666.4T
Other languages
English (en)
Inventor
Elmoustapha Ould-Ahmed-Vail
Kshitij A. Doshi
Suleyman Sair
Charles R. Yount
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 DE112011105666T5 publication Critical patent/DE112011105666T5/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30007Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30029Logical and Boolean instructions, e.g. XOR, NOT
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/3004Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30043LOAD or STORE instructions; Clear instruction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/76Architectures of general purpose stored program computers
    • G06F15/80Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8053Vector processors
    • G06F15/8061Details on data memory access
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30007Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30018Bit or string instructions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30007Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/3004Arrangements for executing specific machine instructions to perform operations on memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098Register arrangements
    • G06F9/30101Special purpose registers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016Decoding the operand specifier, e.g. specifier format
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181Instruction operation extension or modification
    • G06F9/30185Instruction operation extension or modification according to one or more bits in the instruction, e.g. prefix, sub-opcode
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/34Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/345Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes of multiple operands or results
    • G06F9/3455Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes of multiple operands or results using stride
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802Instruction prefetching
    • G06F9/3808Instruction prefetching for instruction reuse, e.g. trace cache, branch target cache
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887Concurrent 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]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824Operand accessing
    • G06F9/383Operand prefetching

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)
  • Executing Machine-Instructions (AREA)
  • Complex Calculations (AREA)

Abstract

Befehle und eine Logik stellen Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereit. In einigen Ausführungsformen, als Reaktion auf einen Befehl, der Folgendes spezifiziert: einen Satz von Ladevorgängen, eine zweite Operation, ein Zielregister, ein Operandenregister, eine Speicheradresse und eine Schrittlänge; lesen Ausführungseinheiten Werte in einem Maskenregister, wobei Felder in dem Maskenregister Schrittlängenvielfachen von der Speicheradresse zu Datenelementen im Speicher entsprechen. Ein erster Maskenwert gibt an, dass das Element nicht aus dem Speicher geladen worden ist, und ein zweiter Wert gibt an, dass das Element nicht geladen werden muss oder bereits geladen worden ist. Für jedes mit dem ersten Wert wird das Datenelement aus dem Speicher in die entsprechende Zielregisterstelle geladen und der entsprechende Wert in dem Maskenregister wird auf den zweiten Wert geändert. Die zweite Operation wird dann unter Verwendung von entsprechenden Daten in dem Ziel- und Operandenregister durchgeführt, um Ergebnisse zu generieren. Der Befehl kann nach Fehlern neu gestartet werden.

Description

  • BEREICH DER OFFENBARUNG
  • Die vorliegende Offenbarung bezieht sich auf den Bereich von Verarbeitungslogik, Mikroprozessoren und einer zugeordneten Befehlssatzarchitektur, die, wenn sie von dem Prozessor oder einer anderen Verarbeitungslogik ausgeführt wird, logische, mathematische oder andere funktionale Operationen durchführt. Insbesondere bezieht sich die Offenbarung auf Befehle und Logik zum Bereitstellen von Vektor-Lade-Op und/oder Speicher-Op mit Schritt(stride)-Funktionalität.
  • HINTERGRUND DER OFFENBARUNG
  • Moderne Prozessoren weisen oft Befehle auf, um Operationen bereitzustellen, die berechnungstechnisch intensiv sind, jedoch einen hohen Grad an Datenparallelität bieten, die durch eine effiziente Implementierung unter Verwendung von verschiedenen Daten-Storage-Speichervorrichtungen ausgenutzt werden kann, wie z. B. Einzelbefehl-Mehrfachdaten(Single Instruction Multiple Data, SIMD)-Vektorregister.
  • Das Vektorisieren einer Anwendung oder eines Softwarecodes kann aufweisen, dass die Anwendung dazu gebracht wird, zu kompilieren, zu installieren und/oder auf spezifischen Systemen oder Befehlssatzarchitekturen abzulaufen, wie z. B. einer Vektorarchitektur mit einer großen oder weiten Breite. Für einige Anwendungen kann ein Speicherzugriff komplex, inkonsistent oder nicht zusammenhängend sein, beispielsweise wenn sich Vektorbreiten erhöhen (z. B. für Operationen wie z. B. dreidimensionales (3D) Bild-Rendering). Speicher, der für vektorisierte Prozesse verwendet wird, kann in nicht zusammenhängenden oder nicht benachbarten Speicherstellen gespeichert sein. Eine Vielzahl von Architekturen kann zusätzliche Befehle erfordern, die den Befehlsdurchsatz minimieren und die Anzahl von Taktzyklen signifikant erhöhen, die benötigt werden, um Daten in die Register vor einem Durchführen von beliebigen arithmetischen Operationen anzuordnen.
  • Mechanismen zum Verbessern von Speicherzugriff und Anordnen von Daten in und aus breiteren Vektoren können ein Implementieren von Sammel- und Streuoperationen zum Generieren eines lokalen zusammenhängenden Speicherzugriffs für Daten aus anderen nicht lokalen und/oder nicht zusammenhängenden Speicherstellen aufweisen. Sammeloperationen können Daten aus einem Satz von nicht zusammenhängenden oder zufälligen Speicherstellen in einer Storage-Speichervorrichtung einsammeln und die ungleichen Daten in einer gepackten Struktur kombinieren. Streuoperationen können Elemente in einer gepackten Struktur auf einen Satz von nicht zusammenhängenden oder zufälligen Speicherstellen verteilen. Andere Mechanismen können ein Laden und Speichern mit einem regelmäßigen Schritt oder Schrittweite aufweisen, um Daten aus einem Satz von nicht zusammenhängenden Speicherstellen in eine Storage-Speichervorrichtung einzusammeln und die Daten in eine gepackte Struktur zu kombinieren oder um Elemente in einer gepackten Struktur auf einen Satz von nicht zusammenhängenden Speicherstellen in einer Storage-Speichervorrichtung zu verteilen. Einige dieser Speicherstellen müssen nicht zwischengespeichert sein oder können aus einem physikalischen Speicher ausgelagert worden sein.
  • Wenn diese Operationen aufgrund eines Seitenfehlers (page fault) oder irgendeines anderen Grundes unterbrochen werden, kann bei einigen Architekturen der Zustand der Maschine nicht gesichert werden, was ein Wiederholen der gesamten Operation erfordert, statt eines Neustarts an der Stelle, an der die Operation unterbrochen worden ist. Da mehrere Speicherzugriffe erforderlich sein können bei einer beliebigen wiederholten Operation, können viele Taktzyklen für den Abschluss erforderlich sein, auf den beliebige nachfolgende abhängige arithmetische Operationen notwendigerweise warten müssen. Solche Verzögerungen stellen einen Flaschenhals dar, der Leistungsvorteile beschränkt, die ansonsten beispielsweise von einer Vektorarchitektur mit einer großen oder weiten Breite erwartet werden.
  • Mögliche Lösungen für solche die Leistung beschränkenden Probleme und Flaschenhälse wurden bislang nicht adäquat untersucht.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung wird beispielhaft und nicht beschränkend in den Figuren der begleitenden Zeichnungen dargestellt.
  • 1A ist ein Blockdiagramm einer Ausführungsform eines Systems, das Befehle ausführt, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitzustellen.
  • 1B ist ein Blockdiagramm einer weiteren Ausführungsform eines Systems, das Befehle ausführt, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitzustellen.
  • 1C ist ein Blockdiagramm einer weiteren Ausführungsform eines Systems, das Befehle ausführt, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitzustellen.
  • 2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, der Befehle ausführt, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitzustellen.
  • 3A stellt gepackte Datentypen gemäß einer Ausführungsform dar.
  • 3B stellt gepackte Datentypen gemäß einer Ausführungsform dar.
  • 3C stellt gepackte Datentypen gemäß einer Ausführungsform dar.
  • 3D stellt eine Befehlscodierung dar, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer Ausführungsform bereitzustellen.
  • 3E stellt eine Befehlscodierung dar, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer weiteren Ausführungsform bereitzustellen.
  • 3F stellt eine Befehlscodierung dar, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer weiteren Ausführungsform bereitzustellen.
  • 3G stellt eine Befehlscodierung dar, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer weiteren Ausführungsform bereitzustellen.
  • 3H stellt eine Befehlscodierung dar, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer weiteren Ausführungsform bereitzustellen.
  • 4A stellt Elemente einer Ausführungsform einer Prozessormikroarchitektur dar, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 4B stellt Elemente einer weiteren Ausführungsform einer Prozessormikroarchitektur dar, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 5 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 6 ist ein Blockdiagramm einer Ausführungsform eines Computersystems, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 7 ist ein Blockdiagramm einer weiteren Ausführungsform eines Computersystems, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Computersystems, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 9 ist ein Blockdiagramm einer Ausführungsform eines Systems auf einem Chip, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 10 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, um Befehle auszuführen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 11 ist ein Blockdiagramm einer Ausführungsform eines IP-Kern-Entwicklungssystems, das Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellt.
  • 12 stellt eine Ausführungsform eines Architekturemulationssystems dar, das Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellt.
  • 13 stellt eine Ausführungsform eines Systems zum Übersetzen von Befehlen dar, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • 14 stellt ein Flussdiagramm für eine Ausführungsform eines Verfahrens zum Bereitstellen von Vektor-Lade-Op mit Schritt-Funktionalität dar.
  • 15 stellt ein Flussdiagramm für eine weitere Ausführungsform eines Verfahrens zum Bereitstellen von Vektor-Lade-Op mit Schritt-Funktionalität dar.
  • 16 stellt ein Flussdiagramm für eine Ausführungsform eines Verfahrens zum Bereitstellen von Vektor-Speicher-Op mit Schritt-Funktionalität dar.
  • 17 stellt ein Flussdiagramm für eine weitere Ausführungsform eines Verfahrens zum Bereitstellen von Vektor-Speicher-Op mit Schritt-Funktionalität dar.
  • DETAILLIERTE BESCHREIBUNG
  • Die folgende Beschreibung offenbart Befehle und eine Verarbeitungslogik zum Bereitstellen von Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität innerhalb eines oder in Verbindung mit einem Prozessor, Computersystem oder einer anderen Verarbeitungsvorrichtung.
  • In einigen Ausführungsformen, als Reaktion auf einen Befehl, der Folgendes spezifiziert: einen Satz von Ladevorgängen, eine zweite Operation, ein Zielregister, ein Operandenregister, eine Speicheradresse und eine Schrittlänge, lesen Ausführungseinheiten Werte in einem Maskenregister, wobei Felder in dem Maskenregister Vielfachen der Schrittlänge von der Speicheradresse zu Datenelementen in Speicher entsprechen. Ein erster Maskenwert gibt an, dass das Element nicht aus dem Speicher geladen worden ist, und ein zweiter Wert gibt an, dass das Element nicht geladen werden muss oder bereits geladen worden ist. Für jedes mit dem ersten Wert wird das Datenelement aus dem Speicher in die entsprechende Zielregisterstelle geladen und der entsprechende Wert in dem Maskenregister wird auf den zweiten Wert geändert. Bei einem Fehler (fault) oder wenn alle Maskenregisterfelder den zweiten Wert haben, kann die zweite Operation unter Verwendung von entsprechenden Daten in dem Ziel- und Operandenregister durchgeführt werden, um Ergebnisse zu generieren. In einigen alternativen Ausführungsformen, als Reaktion auf einen Befehl, der Folgendes spezifiziert: beispielsweise einen Satz von Speichervorgängen, die einer ersten Operation folgen, ein Zielregister, ein Operandenregister, eine Speicheradresse und eine Schrittlänge, können Ausführungseinheiten mit oder ohne Verwendung eines Maskenregisters die erste Operation durchführen und Maskenwerte können verwendet werden, um anzugeben, ob das resultierende Element nicht in den Speicher gespeichert worden ist oder dass das Element nicht gespeichert werden muss oder bereits in den Speicher gespeichert worden ist.
  • In der folgenden Beschreibung werden zahlreiche spezifische Details, wie z. B. Verarbeitungslogik, Prozessortypen, mikroarchitektonische Bedingungen, Ereignisse, Umsetzungsmechanismen und Ähnliche dargelegt, um ein tiefgehendes Verständnis von Ausführungsformen der vorliegenden Erfindung bereitzustellen. Dem Fachmann wird jedoch klar sein, dass die Erfindung ohne solche spezifischen Details ausgeführt werden kann. Zusätzlich werden einige wohlbekannte Strukturen, Schaltungen und Ähnliche nicht detailliert gezeigt, um ein unnötiges Verschleiern von Ausführungsformen der vorliegenden Erfindung zu verhindern.
  • Obwohl die folgenden Ausführungsformen mit Bezug auf einen Prozessor beschrieben sind, sind andere Ausführungsformen auf andere Typen von integrierten Schaltungen und logischen Vorrichtungen anwendbar. Ähnliche Techniken und Lehren von Ausführungsformen der vorliegenden Erfindung können auf andere Typen von Schaltungen oder Halbleitervorrichtungen angewandt werden, die von einem höheren Pipeline-Durchsatz und verbesserter Leistungsfähigkeit profitieren können. Die Lehren von Ausführungsformen der vorliegenden Erfindung sind auf einen beliebigen Prozessor oder Maschine anwendbar, die Datenmanipulationen durchführt. Die vorliegende Erfindung ist jedoch nicht auf Prozessoren oder Maschinen beschränkt, die 512 Bit, 256 Bit, 128 Bit, 64 Bit, 32 Bit oder 16 Bit Datenoperationen durchführen, und kann auf einen beliebigen Prozessor und Maschine angewandt werden, in der Manipulation oder Verwaltung von Daten durchgeführt wird. Zusätzlich stellt die folgende Beschreibung Beispiele bereit und die begleitenden Zeichnungen zeigen verschiedene Beispiele zu Darstellungszwecken. Diese Beispiele sollten jedoch nicht in einem beschränkenden Sinne ausgelegt werden, da sie lediglich dazu bestimmt sind, Beispiele von Ausführungsformen der vorliegenden Erfindung bereitzustellen, statt eine erschöpfende Liste von allen möglichen Implementierungen von Ausführungsformen der vorliegenden Erfindung bereitzustellen.
  • Obwohl die nachstehenden Beispiele eine Befehlsbehandlung und Verteilung im Kontext von Ausführungseinheiten und logischen Schaltungen beschreiben, können andere Ausführungsformen der vorliegenden Erfindung mittels Daten oder Befehlen erzielt werden, die auf einem maschinenlesbaren, greifbaren Medium gespeichert sind, die, wenn sie von einer Maschine durchgeführt werden, die Maschine dazu veranlassen, Funktionen durchführen, die mit mindestens einer Ausführungsform der Erfindung konsistent sind. In einer Ausführungsform sind Funktionen, die Ausführungsformen der vorliegenden Erfindung zugeordnet sind, als maschinenausführbare Befehle ausgeführt. Die Befehle können verwendet werden, um einen Allzweck- oder Spezialprozessor, der mit den Befehlen programmiert ist, dazu zu veranlassen, die Schritte der vorliegenden Erfindung durchzuführen. Ausführungsformen der vorliegenden Erfindung können als ein Computerprogrammprodukt oder Software bereitgestellt sein, das ein maschinen- oder computerlesbares Medium mit darauf gespeicherten Befehlen aufweisen kann, die verwendet werden können, um einen Computer (oder andere elektronische Vorrichtungen) zu programmieren, um eine oder mehrere Operationen gemäß Ausführungsformen der vorliegenden Erfindung durchzuführen. Alternativ können Schritte von Ausführungsformen der vorliegenden Erfindung von spezifischen Hardwarekomponenten durchgeführt werden, die eine Logik mit fester Funktion zum Durchführen der Schritte enthalten, oder von einer beliebigen Kombination von programmierten Computerkomponenten und Hardwarekomponenten mit fester Funktion.
  • Befehle, die verwendet werden, um Logik zu programmieren, um Ausführungsformen der Erfindung durchzuführen, können innerhalb eines Speichers in dem System gespeichert sein, wie z. B. DRAM, Cache, Flash-Speicher oder ein anderer Storage-Speicher. Ferner können die Befehle über ein Netzwerk oder mittels anderer computerlesbarer Medien verteilt werden. Somit kann ein maschinenlesbares Medium einen beliebigen Mechanismus zum Speichern oder Übermitteln von Informationen in einer Form aufweisen, die von einer Maschine (z. B. einem Computer) lesbar ist, die jedoch nicht beschränkt ist auf Floppy-Disketten, optische Platten, Compact Disk Read-Only Memory (CD-ROMs) und magneto-optische Platten, Read Only Memory (ROMs), Random Access Memory (RAM), löschbaren programmierbaren Read Only Memory (EPROM), elektrisch löschbaren programmierbaren Read Only Memory (EEPROM), magnetische oder optische Karten, Flash-Speicher oder greifbare, maschinenlesbare Storage-Speicher, die bei der Übertragung von Informationen über das Internet über elektrische, optische, akustische oder verbreitete Signale anderer Formen (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.) verwendet werden. Entsprechend weist das computerlesbare Medium einen beliebigen Typ eines greifbaren maschinenlesbaren Mediums oder Datenträgers auf, der geeignet ist zum Speichern oder Übermitteln von elektronischen Befehlen oder Informationen in einer Form, die von einer Maschine (z. B. einem Computer) lesbar ist.
  • Ein Design kann durch verschiedene Stufen gehen, von der Erzeugung bis zur Simulation bis zur Fabrikation. Daten, die ein Design repräsentieren, können das Design in einer Vielzahl von Weisen repräsentieren. Zuerst kann die Hardware, wie es bei Simulationen nützlich ist, unter Verwendung von einer Hardwarebeschreibungssprache oder einer anderen funktionalen Beschreibungssprache repräsentiert werden. Zusätzlich kann ein Modell auf Schaltungsebene mit Logik und/oder Transistorgattern auf einigen Stufen des Design-Prozesses produziert werden. Ferner erreichen die meisten Designs auf irgendeiner Stufe eine Ebene von Daten, die die physikalische Anordnung von verschiedenen Vorrichtungen in dem Hardwaremodell repräsentieren. In dem Fall, in dem gewöhnliche Halbleiterfabrikationstechniken verwendet werden, können die Daten, die das Hardwaremodell repräsentieren, die Daten sein, die das Vorhandensein oder Fehlen von verschiedenen Merkmalen auf unterschiedlichen Maskenschichten für Masken spezifizieren, die verwendet werden, um die integrierte Schaltung zu produzieren. In einer beliebigen Repräsentation des Designs können die Daten in einer beliebigen Form eines maschinenlesbaren Mediums oder Datenträgers gespeichert sein. Ein Speicher oder ein magnetischer oder optischer Storage-Speicher, wie z. B. eine Platte, kann das maschinenlesbare Medium sein, um Informationen zu speichern, die über optische oder elektronische Wellen übertragen werden, die moduliert oder anderweitig generiert werden, um solche Informationen zu übertragen. Wenn eine elektrische Trägerwelle, die den Code oder das Design angibt oder trägt, bis zu dem Ausmaß übermittelt wird, dass ein Kopieren, Puffern oder Neu-Übertragen des elektrischen Signals durchgeführt wird, wird eine neue Kopie gemacht. Somit kann ein Kommunikationsanbieter oder ein Netzwerkanbieter auf einem greifbaren, maschinenlesbaren Medium zumindest temporär einen Artikel speichern, wie z. B. Informationen, die in eine Trägerwelle codiert sind, die Techniken von Ausführungsformen der vorliegenden Erfindung verkörpern.
  • Bei modernen Prozessoren werden eine Vielzahl von unterschiedlichen Ausführungseinheiten verwendet, um eine Vielzahl von Code und Befehlen zu verarbeiten und auszuführen. Nicht alle Befehle werden gleich erzeugt, da einige schneller abschließen, während andere eine Vielzahl von Taktzyklen benötigen können, um abzuschließen. Je schneller der Durchsatz von Befehlen, desto besser die Gesamtleistung des Prozessors. Somit wäre es vorteilhaft, wenn möglichst viele Befehle so schnell wie möglich ausgeführt werden. Jedoch gibt es bestimmte Befehle, die eine größere Komplexität haben und hinsichtlich Ausführungszeit und Prozessorressourcen mehr benötigen. Beispielsweise gibt es Gleitkommabefehle, Lade-/Speicheroperationen, Datenverschiebungen usw.
  • Je mehr Computersysteme im Internet und bei Text- und Multimedia-Anwendungen verwendet werden, wurde im Laufe der Zeit zusätzliche Prozessorunterstützung eingeführt. In einer Ausführungsform kann ein Befehlssatz einer oder mehreren Computerarchitekturen zugeordnet sein, aufweisend Datentypen, Befehle, Registerarchitektur, Adressierungsmodi, Speicherarchitektur, Interrupt- und Exception-Behandlung und externe Eingabe und Ausgabe (I/O).
  • In einer Ausführungsform kann die Befehlssatzarchitektur (Instruction Set Architecture, ISA) durch eine oder mehrere Mikroarchitekturen implementiert sein, welche eine Prozessorlogik und Schaltungen aufweisen, die verwendet werden, um einen oder mehrere Befehlssätze zu implementieren. Entsprechend können sich Prozessoren mit unterschiedlichen Mikroarchitekturen zumindest einen Teil eines gemeinsamen Befehlssatzes teilen. Beispielsweise implementieren Intel® Pentium 4-Prozessoren, Intel® CoreTM-Prozessoren und Prozessoren von Advanced Micro Devices, Inc. aus Sunnyvale, CA beinah identische Versionen des x86-Befehlssatzes (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt worden sind), sie haben jedoch unterschiedliche interne Designs. In einer ähnlichen Art und Weise können sich Prozessoren, die von anderen Prozessorentwicklungsunternehmen entwickelt werden, beispielsweise ARM Holdings, Ltd., MIPS oder ihre Lizenznehmer oder Adoptierer mindestens einen Teil eines gemeinsamen Befehlssatzes teilen, sie können jedoch unterschiedliche Prozessordesigns aufweisen. Beispielsweise kann dieselbe Registerarchitektur der ISA auf unterschiedliche Art und Weise in unterschiedlichen Mikroarchitekturen unter Verwendung von neuen oder wohlbekannten Techniken implementiert werden, aufweisend dedizierte physikalische Register, einen oder mehrere dynamisch allozierte physikalische Register unter Verwendung eines Registerumbenermungsmechanismus (z. B. die Verwendung einer Register-Alias-Tabelle (RAT), eines Umordnungspuffers (Reorder Buffer, ROB) und einer Ausscheidungsregisterdatei). In einer Ausführungsform können Register einen oder mehrere Register, Registerarchitekturen, Registerdateien oder andere Registersätze aufweisen, die von einem Softwareprogrammierer adressierbar sein können oder nicht.
  • In einer Ausführungsform kann ein Befehl einen oder mehrere Befehlsformate aufweisen. In einer Ausführungsform kann ein Befehlsformat verschiedene Felder (Anzahl von Bits, Stelle von Bits usw.) angeben, um unter Anderem die Operation, die durchgeführt werden soll, und den/die Operanden zu spezifizieren, auf denen die Operation durchgeführt werden soll. Einige Befehlsformate können ferner aufgebrochen sein, definiert durch Befehlsvorlagen (oder Teilformate). Beispielsweise können die Befehlsvorlagen eines gegebenen Befehlsformats derart definiert sein, dass sie unterschiedliche Teilsätze von Feldern des Befehlsformats haben, und/oder derart definiert sein, dass sie ein gegebenes Feld haben, das unterschiedlich interpretiert wird. In einer Ausführungsform wird ein Befehl unter Verwendung eines Befehlsformats ausgedrückt (und, wenn dies definiert ist, in einer gegebenen der Befehlsvorlagen dieses Befehlsformats) und spezifiziert oder gibt die Operation und die Operanden an, auf den die Operation arbeiten wird.
  • Wissenschaftliche, finanzielle, autovektorisierte Allzweck-, RMS-(Erkennung(recognition), Gewinnung (mining), und Synthese) und visuelle und Multimedia-Anwendungen (z. B. 2D/3D-Grafik, Bildverarbeitung, Videokomprimierung/Dekomprimierung, Spracherkennungsalgorithmen und Audiomanipulation) können erfordern, dass dieselbe Operation auf einer großen Anzahl von Dateneinheiten durchgeführt wird. In einer Ausführungsform bezieht sich Einzelbefehl-Mehrfachdaten (Single Instruction Multiple Data, SIMD) auf einen Typ von Befehl, der einen Prozessor dazu veranlasst, eine Operation auf mehreren Datenelementen durchzuführen. SIMD-Technologie kann in Prozessoren verwendet werden, die die Bits in einem Register logisch in eine Anzahl von Datenelementen mit festgelegter Größe oder variabler Größe aufteilen können, von denen jedes einen separaten Wert repräsentiert. Beispielsweise können in einer Ausführungsform die Bits in einem 64 Bit Register als ein Quelloperand organisiert sein, der vier separate 16 Bit Datenelemente enthält, von denen jedes einen separaten 16 Bit Wert repräsentiert. Auf diesen Datentyp kann als ein ,gepackter' Datentyp oder ,Vektor'-Datentyp Bezug genommen werden und auf Operanden dieses Datentyps wird als gepackte Datenoperanden oder Vektoroperanden Bezug genommen. In einer Ausführungsform kann eine gepackte Dateneinheit oder Vektor eine Sequenz von gepackten Datenelementen sein, die innerhalb eines einzelnen Registers gespeichert sind, und ein gepackter Datenoperand oder ein Vektoroperand kann ein Quell- oder Zieloperand eines SIMD-Befehls sein (oder ,gepackter Datenbefehl' oder ein ,Vektorbefehl'). In einer Ausführungsform spezifiziert ein SIMD-Befehl eine einzelne Vektoroperation, die auf zwei Quellvektoroperanden durchgeführt werden soll, um einen Zielvektoroperanden (auf den ebenfalls als ein Ergebnisvektoroperand Bezug genommen wird) derselben oder einer unterschiedlichen Größe zu generieren, mit derselben oder einer unterschiedlichen Anzahl von Datenelementen und in derselben oder einer unterschiedlichen Datenelementreihenfolge.
  • SIMD-Technologie, wie sie z. B. von den Intel® CoreTM-Prozessoren mit einem Befehlssatz, der x86, MMXTM, Streaming SIMD Extensions (SSE), SSE2, SSE3, SSE4.1 und SSE4.2 Befehle aufweist, von ARM-Prozessoren, wie z. B. der ARM-CortexTM-Familie von Prozessoren mit einem Befehlssatz, der die Vektor Floating Point (VFP) und/oder NEON-Befehle aufweist, und von MIPS-Prozessoren, wie z. B. der Loongson-Familie von Prozessoren, die von dem Institute of Computing Technology (ICT) der Chinese Academy of Sciences entwickelt werden, verwendet wird, hat eine signifikante Verbesserung der Anwendungsleistung ermöglicht (CoreTM und MMXTM sind registrierte Marken oder Marken der Intel Corporation aus Santa Clara, Kalifornien).
  • In einer Ausführungsform sind Ziel- und Quellregister/Daten generische Begriffe, um die Quelle und das Ziel der entsprechenden Daten oder Operation zu repräsentieren. In einigen Ausführungsformen können sie durch Register, Speicher oder andere Storage-Speicherbereiche mit anderen Namen oder Funktionen, als die abgebildeten, implementiert sein. Beispielsweise kann in einer Ausführungsform „DEST1” ein temporäres Storage-Speicherregister oder ein anderer Storage-Speicherbereich sein, während „SRC1” und „SRC2” ein erstes und zweites Quell-Storage-Speicherregister oder ein anderer Storage-Speicherbereich sein können usw. In anderen Ausführungsformen können zwei oder mehr der SRC- und DEST-Storage-Speicherbereiche unterschiedlichen Daten-Storage-Speicherelementen innerhalb desselben Storage-Speicherbereichs entsprechen (z. B. ein SIMD-Register). In einer Ausführungsform kann einer der Quellregister ebenfalls als ein Zielregister agieren, durch beispielsweise Rückschreiben des Ergebnisses eines Befehls, der auf den ersten und zweiten Quelldaten durchgeführt wird, in einen der zwei Quellregister, die als Zielregister dienen.
  • 1A ist ein Blockdiagramm eines beispielhaften Computersystems, das mit einem Prozessor geformt ist, das Ausführungseinheiten aufweist, um einen Befehl in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung auszuführen. Das System 100 weist eine Komponente auf, wie z. B. einen Prozessor 102, um Ausführungseinheiten einzusetzen, aufweisend Logik, um Algorithmen für Verarbeitungsdaten durchzuführen, in Übereinstimmung mit der vorliegenden Erfindung wie z. B. in der hier beschriebenen Ausführungsform. Das System 100 steht repräsentativ für Verarbeitungssysteme basierend auf dem PENTIUM® III, PENTIUM® 4, XeonTM, Itanium®, XScaleTM und/oder StrongARMTM-Mikroprozessoren, die von Intel Corporation aus Santa Clara, Kalifornien, verfügbar sind, obwohl andere Systeme (aufweisend PCs mit anderen Mikroprozessoren, Ingenieur-Workstations, Set-Top-Boxen und Ähnliche) ebenfalls verwendet werden können. In einer Ausführungsform kann das Beispielsystem 100 eine Version des WINDOWSTM-Betriebssystems ausführen, das von Microsoft Corporation aus Redmond, Washington, verfügbar ist, obwohl andere Betriebssysteme (beispielsweise UNIX und Linux), eingebettete Software und/oder grafische Benutzerschnittstellen ebenfalls verwendet werden können. Somit sind Ausführungsformen der vorliegenden Erfindung nicht auf irgendeine spezifische Kombination von Hardwareschaltkreisen und Software beschränkt.
  • Ausführungsformen sind nicht auf Computersysteme beschränkt. Alternative Ausführungsformen der vorliegenden Erfindung können in anderen Vorrichtungen verwendet werden, wie z. B. handgehaltene Vorrichtungen und eingebettete Anwendungen. Einige Beispiele von handgehaltenen Vorrichtungen weisen Mobiltelefone, Internet Protocol-Vorrichtungen, digitale Kameras, Personal Digital Assistants (PDAs) und handgehaltene PCs auf. Eingebettete Anwendungen können einen Mikrocontroller, einen digitalen Signalprozessor (DSP), ein System auf einem Chip, Netzwerkcomputer (NetPCs), Set-Top-Boxen, Netzwerk-Hubs, Fernnetz(Wide Area Network, WAN)-Switches oder ein beliebiges anderes System aufweisen, das einen oder mehrere Befehle in Übereinstimmung mit mindestens einer Ausführungsform durchführen kann.
  • 1A ist ein Blockdiagramm eines Computersystems 100, das mit einem Prozessor 102 geformt ist, der eine oder mehrere Ausführungseinheiten 108 aufweist, um einen Algorithmus durchzuführen, um mindestens einen Befehl in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung durchzuführen. Eine Ausführungsform kann im Kontext eines einzelnen Prozessordesktops oder Server-Systems beschrieben sein, jedoch können alternative Ausführungsformen in einem Multiprozessorsystem aufgenommen sein. Das System 100 ist ein Beispiel einer „Hub”-Systemarchitektur. Das Computersystem 100 weist einen Prozessor 102 auf, um Datensignale zu verarbeiten. Der Prozessor 102 kann ein Complex Instruction Set Computer(CISC)-Mikroprozessor, ein Reduced Instruction Set Computer(RISC)-Mikroprozessor, ein Very Long Instruction Word(VLIW)-Mikroprozessor, ein Prozessor, der eine Kombination von Befehlssätzen implementiert, oder eine beliebige andere Prozessorvorrichtung sein, wie z. B. ein digitaler Signalprozessor. Der Prozessor 102 ist an einen Prozessorbus 110 gekoppelt, der Datensignale zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 übertragen kann. Die Elemente des Systems 100 führen ihre gewöhnlichen Funktionen durch, die dem Fachmann wohlbekannt sind.
  • In einer Ausführungsform weist der Prozessor 102 einen internen Cache-Speicher 104 auf Ebene 1 (Level 1, L1) auf. In Abhängigkeit von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen des internen Cache haben. Alternativ kann in einer weiteren Ausführungsform der Cache-Speicher extern zu dem Prozessor 102 angeordnet sein. Andere Ausführungsformen können ebenfalls eine Kombination von sowohl internen als auch externen Caches aufweisen, in Abhängigkeit von der bestimmten Implementierung und Anforderungen. Eine Registerdatei 106 kann unterschiedliche Typen von Daten in verschiedenen Registern speichern, aufweisend Integer-Register, Gleitkommaregister, Statusregister und ein Befehlszeigerregister.
  • Eine Ausführungseinheit 108, die Logik zum Durchführen von Integer- und Gleitkommaoperationen aufweist, ist ebenfalls in dem Prozessor 102 angeordnet. Der Prozessor 102 weist ebenfalls einen Mikrocode(uCode)-ROM auf, der Mikrocode für bestimmte Makrobefehle speichert. In einer Ausführungsform weist die Ausführungseinheit 108 Logik zum Behandeln eines gepackten Befehlssatzes 109 auf. Durch Aufnehmen des gepackten Befehlssatzes 109 in den Befehlssatz eines Allzweckprozessors 102, zusammen mit zugeordneten Schaltkreisen, um die Befehle auszuführen, können die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten in einem Allzweckprozessor 102 durchgeführt werden. Somit können viele Multimedia-Anwendungen beschleunigt werden und effizienter ausgeführt werden durch Verwenden der vollen Breite eines Datenbusses eines Prozessors zum Durchführen von Operationen auf gepackten Daten. Dies kann die Notwendigkeit beseitigen, kleinere Einheiten von Daten über den Datenbus des Prozessors zu übertragen, um einen oder mehrere Befehle auf einem Datenelement zur selben Zeit durchzuführen.
  • Alternative Ausführungsformen einer Ausführungseinheit 108 können ebenfalls in Mikrocontrollern, eingebetteten Prozessoren, Grafikvorrichtungen, DSPs und anderen Typen von logischen Schaltungen verwendet werden. Das System 100 weist einen Speicher 120 auf. Der Speicher 120 kann eine dynamische Random Access Memory(DRAM)-Vorrichtung, eine statische Random Access Memory(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung oder eine andere Speichervorrichtung sein. Der Speicher 120 kann Befehle und/oder Daten speichern, die durch Datensignale repräsentiert sind, die von dem Prozessor 102 ausgeführt werden können.
  • Ein logischer Systemchip 116 ist an den Prozessorbus 110 und den Speicher 120 gekoppelt. Der logische Systemchip 116 in der dargestellten Ausführungsform ist ein Speichercontroller-Hub (MCH). Der Prozessor 102 kann mit dem MCH 116 über einen Prozessorbus 110 kommunizieren. Der MCH 116 stellt einen Speicherpfad 118 mit hoher Bandbreite zu dem Speicher 120 zum Befehls- und Daten-Speichern und zum Speichern von Grafikkommandos, Daten und Texturen bereit. Der MCH 116 ist dazu eingerichtet, Datensignale zwischen dem Prozessor 102, dem Speicher 120 und anderen Komponenten in dem System 100 zu leiten und um die Datensignale zwischen dem Prozessorbus 110, dem Speicher 120 und dem System-I/O 122 zu überbrücken. In einigen Ausführungsformen kann der logische Systemchip 116 einen grafischen Port zum Koppeln eines Grafikcontrollers 112 bereitstellen. Der MCH 116 ist an den Speicher 120 durch eine Speicherschnittstelle 118 gekoppelt. Die Grafikkarte 112 ist an den MCH 116 durch einen Accelerated Graphics Port(AGP)-Interconnect 114 gekoppelt.
  • Das System 100 verwendet einen proprietären Hub-Schnittstellenbus 122, um den MCH 116 an den VO-Controller-Hub (ICH) 130 zu koppeln. Der ICH 130 stellt direkte Verbindungen zu einigen I/O-Vorrichtungen über einen lokalen I/O-Bus bereit. Der lokale I/O-Bus ist ein Hochgeschwindigkeits-I/O-Bus zum Verbinden von Peripherie mit dem Speicher 120, dem Chipsatz und dem Prozessor 102. Einige Beispiele sind der Audio-Controller, ein Firmware-Hub (Flash-BIOS) 128, ein drahtloser Transceiver 126, ein Daten-Storage-Speicher 124, ein Alt-I/O-Controller, der Benutzereingabe- und Tastaturschnittstellen enthält, ein serieller Erweiterungsport, wie z. B. Universal Serial Bus (USB), und ein Netzwerkcontroller 134. Die Daten-Storage-Speichervorrichtung 124 kann ein Festplattenlaufwerk, ein Floppy-Diskettenlaufwerk, eine CD-ROM-Vorrichtung, eine Flash-Speichervorrichtung oder eine andere Massen-Storage-Speichervorrichtung aufweisen.
  • Für eine andere Ausführungsform eines Systems kann ein Befehl in Übereinstimmung mit einer Ausführungsform mit einem System auf einem Chip verwendet werden. Eine Ausführungsform eines Systems auf einem Chip umfasst einen Prozessor und einen Speicher. Der Speicher für ein solches System ist ein Flash-Speicher. Der Flash-Speicher kann auf demselben Die wie der Prozessor und andere Systemkomponenten angeordnet sein. Zusätzlich können andere logische Blöcke, wie z. B. ein Speichercontroller oder ein Grafikcontroller, ebenfalls in einem System auf einem Chip angeordnet sein.
  • 1B stellt ein Datenverarbeitungssystem 140 dar, das die Prinzipien einer Ausführungsform der vorliegenden Erfindung implementiert. Dem Fachmann wird direkt verständlich sein, dass die hier beschriebenen Ausführungsformen mit alternativen Verarbeitungssystemen verwendet werden können, ohne von dem Umfang von Ausführungsformen der Erfindung abzuweichen.
  • Das Computersystem 140 umfasst einen Verarbeitungskern 159, der in der Lage ist, mindestens einen Befehl in Übereinstimmung mit einer Ausführungsform durchzuführen. In einer Ausführungsform repräsentiert der Verarbeitungskern 159 eine Verarbeitungseinheit eines beliebigen Architekturtyps, aufweisend, jedoch nicht beschränkt auf eine Architektur eines CISC-, eines RISC- oder eines VLIW-Typs. Der Verarbeitungskern 159 kann ebenfalls zum Herstellen in einer oder mehreren Prozesstechnologien geeignet sein und, indem er auf einem maschinenlesbaren Medium oder Datenträger ausreichend detailliert repräsentiert ist, geeignet sein, die Herstellung zu vereinfachen.
  • Der Verarbeitungskern 159 umfasst eine Ausführungseinheit 142, einen Satz von Registerfeld(ern) 145 und einen Decodierer 144. Der Verarbeitungskern 159 weist ebenfalls einen zusätzlichen Schaltkreis (nicht gezeigt) auf, was für das Verständnis von Ausführungsformen der vorliegenden Erfindung nicht notwendig ist. Die Ausführungseinheit 142 wird verwendet zum Ausführen von Befehlen, die von dem Verarbeitungskern 159 empfangen werden. Zusätzlich zum Durchführen von typischen Prozessorbefehlen kann die Ausführungseinheit 142 Befehle in einem gepackten Befehlssatz 143 zum Durchführen von Operationen auf gepackten Datenformaten durchführen. Der gepackte Befehlssatz 143 weist Befehle zum Durchführen von Ausführungsformen der Erfindung und andere gepackte Befehle auf. Die Ausführungseinheit 142 ist an die Registerdatei 145 mit einem internen Bus gekoppelt. Die Registerdatei 145 repräsentiert einen Storage-Speicherbereich auf dem Verarbeitungskern 159 zum Speichern von Informationen, aufweisend Daten. Wie es vorher erwähnt worden ist, ist verständlich, dass der Storage-Speicherbereich, der zum Speichern der gepackten Daten verwendet wird, nicht kritisch ist. Die Ausführungseinheit 142 ist an den Decodierer 144 gekoppelt. Der Decodierer 144 wird zum Decodieren von Befehlen, die von dem Verarbeitungskern 159 empfangen werden, in Steuer- oder Kontrollsignale und/oder Mikrocodeeinstiegspunkte verwendet. Als Reaktion auf diese Kontrollsignale und/oder Mikrocodeeinstiegspunkte führt die Ausführungseinheit 142 die geeigneten Operationen durch. In einer Ausführungsform wird der Decodierer verwendet, um den Opcode des Befehls zu interpretieren, was angeben wird, welche Operation auf den entsprechenden Daten, die innerhalb des Befehls angegeben sind, durchgeführt werden sollte.
  • Der Verarbeitungskern 159 ist an den Bus 141 gekoppelt zum Kommunizieren mit verschiedenen anderen Systemvorrichtungen, die aufweisen können, jedoch nicht beschränkt sind auf beispielsweise eine synchrone dynamische Random Access Memory(SDRAM)-Steuerung 146, eine statische Random Access Memory(SRAM)-Steuerung 147, eine Burst-Flash-Speicherschnittstelle 148, eine Personal Computer Memory Card International Association(PCMCIA)/Compact Flash(CF)-Kartensteuerung 149, eine Liquid Crystal Display(LCD)-Steuerung 150, einen Direct Memory Access(DMA)-Controller 151 und eine alternative Bus-Masterschnittstelle 152. In einer Ausführungsform kann das Datenverarbeitungssystem 140 ebenfalls eine I/O-Brücke oder Bridge 154 umfassen zum Kommunizieren mit verschiedenen I/O-Vorrichtung über einen I/O-Bus 153. Solche I/O-Vorrichtungen können aufweisen, sind jedoch nicht beschränkt auf beispielsweise Univeral Asynchronous Receivers/Transmitter (UART) 155, Universal Serial Bus (USB) 156, Bluetooth-Wireless UART 157 und eine I/O-Erweiterungsschnittstelle 158.
  • Eine Ausführungsform des Datenverarbeitungssystems 140 stellt mobile, Netzwerk- und/oder drahtlose Kommunikationen und einen Verarbeitungskern 159 bereit, der in der Lage ist, SIMD-Operationen durchzuführen, aufweisend eine Text-String-Vergleichsoperation. Der Verarbeitungskern 159 kann mit verschiedenen Audio-, Video-, Bildgebungs- und Kommunikationsalgorithmen programmiert sein, aufweisend diskrete Transformationen, wie z. B. eine Walsh-Hadamard-Transformation, eine Fast Fourier-Transformation (FFD), eine diskrete Cosinus-Tranformation (DCT) und ihre entsprechenden inversen Transformation; Komprimierungs-/Dekomprimierungsverfahren, wie z. B. eine Farbraumtransformation, Videocodierbewegungsabschätzung oder Videodecodierbewegungskompensation; und Modulation/Demodulation(MODEM)-Funktionen, wie z. B. pulscodierte Modulation (Pulse Coded Modulation, PCM).
  • 1C stellt andere alternative Ausführungsformen eines Datenverarbeitungssystems dar, das in der Lage ist, Befehle auszuführen, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitzustellen. In Übereinstimmung mit einer alternativen Ausführungsform kann das Datenverarbeitungssystem 160 einen Hauptprozessor 166, einen SIMD-Coprozessor 161, einen Cache-Speicher 167 und ein Eingabe/Ausgabe-System 168 aufweisen. Das Eingabe/Ausgabe-System 168 kann optional an eine drahtlose Schnittstelle 169 gekoppelt sein. Der SIMD-Coprozessor 161 ist in der Lage, Operationen durchzuführen, aufweisend Befehle in Übereinstimmung mit einer Ausführungsform. Der Verarbeitungskern 170 kann zum Herstellen in einer oder mehreren Prozesstechnologien geeignet sein und, indem er auf einem maschinenlesbaren Medium oder Datenträger ausreichend detailliert repräsentiert ist, geeignet sein, die Herstellung aller oder von Teilen des Datenverarbeitungssystems 160, aufweisend den Verarbeitungskern 170, zu vereinfachen.
  • In einer Ausführungsform umfasst der SIMD-Coprozessor 161 eine Ausführungseinheit 162 und einen Satz einer von Registerdatei(en) 164. Eine Ausführungsform des Hauptprozessors 166 umfasst einen Decodierer 165, um Befehle eines Befehlssatzes 163, aufweisend Befehle in Übereinstimmung mit einer Ausführungsform, zum Ausführen durch die Ausführungseinheit 162 zu erkennen. In alternativen Ausführungsformen umfasst der SIMD-Coprozessor 161 ebenfalls mindestens einen Teil eines Decodierers 165B, um Befehle des Befehlssatzes 163 zu decodieren. Der Verarbeitungskern 170 weist ebenfalls zusätzliche Schaltkreise (nicht gezeigt) auf, die zum Verständnis von Ausführungsformen der vorliegenden Erfindung nicht notwendig sind.
  • Im Betrieb führt der Hauptprozessor 166 einen Strom von datenverarbeitenden Befehlen aus, die datenverarbeitende Operationen eines allgemeinen Typs kontrollieren, aufweisend Interaktionen mit dem Cache-Speicher 167 und dem Eingabe/Ausgabe-System 168. Innerhalb des Stroms der datenverarbeitenden Befehle sind SIMD-Coprozessorbefehle eingebettet. Der Decodierer 165 des Hauptprozessors 166 erkennt diese SIMD-Coprozessorbefehle, als dass sie einen Typ haben, der von einem angeschlossenen SIMD-Coprozessor 161 ausgeführt werden sollte. Der Hauptprozessor 166 gibt entsprechend diese SIMD-Coprozessorbefehle (oder Kontrollsignale, die die SIMD-Coprozessorbefehle repräsentieren) auf den Coprozessorbus 171 aus, von dem sie von beliebigen angeschlossenen SIMD-Corprozessoren empfangen werden. In diesem Fall wird der SIMD-Coprozessor 161 beliebige empfangene SIMD-Coprozessorbefehle, die für ihn bestimmt sind, akzeptieren und ausführen.
  • Daten können über drahtlose Schnittstellen 169 zum Verarbeiten durch die SIMD-Coprozessorbefehle empfangen werden. In einem Beispiel kann eine Sprachkommunikation in der Form eines digitalen Signals empfangen werden, der von den SIMD-Coprozessorbefehlen verarbeitet werden kann, um digitale Audio-Samples neu zu generieren, die für die Sprachkommunikationen repräsentativ sind. In einem weiteren Beispiel kann komprimiertes Audio und/oder Video in der Form eines digitalen Bitstroms empfangen werden, der von den SIMD-Coprozessorbefehlen verarbeitet werden kann, um digitale Audio-Samples und/oder bewegte Video-Rahmen neu zu generieren. In einer Ausführungsform des Verarbeitungskerns 170 sind der Hauptprozessor 166 und ein SIMD-Coprozessor 161 in einen einzelnen Verarbeitungskern 170 integriert, der eine Ausführungseinheit 162, einen Satz von Registerdatei(en) 164 und einen Decodierer 165 umfasst, um Befehle des Befehlssatzes 163 zu erkennen, aufweisend Befehle in Übereinstimmung mit einer Ausführungsform.
  • 2 ist ein Blockdiagramm der Mikroarchitektur für einen Prozessor 200, der logische Schaltungen aufweist, um Befehle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung durchzuführen. In einigen Ausführungsformen kann ein Befehl in Übereinstimmung mit einer Ausführungsform implementiert sein, um auf Datenelementen mit Größen von einem Byte, Wort, Doppelwort, Quadwort usw. zu arbeiten, sowie Datentypen, wie z. B. Integer- und Gleitkommadatentypen mit einfacher und doppelter Präzision. In einer Ausführungsform ist das In-Order-Frontend 201 der Teil des Prozessors 200, der Befehle abruft, die ausgeführt werden sollen, und sie vorbereitet, um später in der Prozessor-Pipeline verwendet zu werden. Das Frontend 201 kann mehrere Einheiten aufweisen. In einer Ausführungsform ruft der Befehlsvorabrufer 226 Befehle aus Speicher ab und füttert sie in einen Befehlsdecodierer 228, der sie wiederum decodiert oder interpretiert. In einer Ausführungsform decodiert beispielsweise der Decodierer einen empfangenen Befehl in einen oder mehrere Operationen, die „Mikrobefehle” oder „Mikrooperationen” (ebenfalls genannt Mikro-Op oder uOps) genannt werden, die die Maschine ausführen kann. In anderen Ausführungsformen parst der Decodierer den Befehl in einen Opcode und entsprechende Daten und Kontrollfelder, die von der Mikroarchitektur verwendet werden, um Operationen in Übereinstimmung mit einer Ausführungsform durchzuführen. In einer Ausführungsform nimmt der Spur-Cache 230 decodierte uOps und fügt sie in Programmreihenfolge in Sequenzen oder Spuren in der uOp-Warteschlange 234 zur Ausführung zusammen. Wenn der Spur-Cache 230 auf einen komplexen Befehl trifft, stellt der Mikrocode-ROM 232 die uOps bereit, die benötigt werden, um die Operation abzuschließen.
  • Einige Befehle werden in eine einzelne Mikro-Op konvertiert, während andere mehrere Mikro-Ops benötigen, um die vollständige Operation abzuschließen. Wenn mehr als vier Mikro-Ops benötigt werden, um einen Befehl abzuschließen, greift der Decodierer 228 in einer Ausführungsform auf den Mikrocode-ROM 232 zu, um den Befehl zu machen. In einer Ausführungsform kann ein Befehl in eine kleine Anzahl von Mikro-Ops zur Verarbeitung an dem Befehlsdecodierer 228 decodiert werden. In einer weiteren Ausführungsform kann ein Befehl innerhalb des Mikrocode-ROM 232 gespeichert sein, sollte eine Anzahl von Mikro-Ops benötigt werden, um die Operation zu vollenden. Der Spur-Cache 230 bezieht sich auf einen Einstiegspunkt eines programmierbaren logischen Arrays (PLA), um einen richtigen Mikrobefehlzeiger zum Lesen der Mikrocodesequenzen zu bestimmen, um einen oder mehrere Befehle in Übereinstimmung mit einer Ausführungsform aus dem Mikrocode-ROM 232 abzuschließen. Nachdem der Mikrocode-ROM 232 das Sequentialisieren von Mikro-Ops für einen Befehl beendet, nimmt das Frontend 201 der Maschine das Abrufen der Mikro-Ops aus dem Spur-Cache 230 wieder auf.
  • Die Ausführungs-Engine 203 außer Reihenfolge (out of order) befindet sich dort, wo die Befehle zur Ausführung vorbereitet werden. Die Ausführungslogik außer Reihenfolge hat eine Anzahl von Puffer, um den Fluss von Befehlen auszugleichen und umzuordnen, um die Leistung zu optimieren, während sie die Pipeline hinabschreiten und zur Ausführung eingeplant werden. Die Allokatorlogik alloziert die Maschinenpuffer und Ressourcen, die jede uOp benötigt, um ausgeführt zu werden. Die Registerumbenennungslogik benennt logische Register auf Einträge in einer Registerdatei um. Der Allokator alloziert ebenfalls einen Eintrag für jede uOp in einer der zwei uOp-Warteschlangen, eine für Speicheroperationen und eine für Nicht-Speicheroperationen, vor den Befehlsschedulern: ein Speicherscheduler, ein schneller Scheduler 202, ein langsamer/allgemeiner Gleitkommascheduler 204 und ein einfacher Gleitkommascheduler 206. Die uOp-Scheduler 202, 204, 206 bestimmen, wann eine uOp bereit ist, ausgeführt zu werden, basierend auf der Bereitschaft ihrer abhängigen Eingaberegisteroperandenquellen und der Verfügbarkeit der Ausführungsressourcen, die die uOps benötigen, um ihre Operation abzuschließen. Der schnelle Scheduler 202 einer Ausführungsform kann auf jeder Hälfte des Haupttaktzyklus einplanen, während die anderen Scheduler nur einmal pro Hauptprozessortaktzyklus einplanen können. Die Scheduler vermitteln unter den Verteilports, um uOps zur Ausführung einzuplanen.
  • Registerdateien 208, 210 sitzen zwischen den Schedulern 202, 204, 206 und den Ausführungseinheiten 212, 214, 216, 218, 220, 222, 224 in dem Ausführungsblock 211. Es gibt eine separate Registerdatei 208, 210 für Integer- bzw. Gleitkommaoperationen. Jede Registerdatei 208, 210 einer Ausführungsform weist ebenfalls ein Bypass-Netzwerk auf, das gerade abgeschlossene Ergebnisse, die noch nicht in die Registerdatei geschrieben worden sind, an neue abhängige uOps vorbeileiten oder weiterleiten kann. Die Integer-Registerdatei 208 und die Gleitkommaregisterdatei 210 sind ebenfalls in der Lage, Daten mit der anderen zu kommunizieren. In einer Ausführungsform ist die Integer-Registerdatei 208 in zwei separate Registerdateien aufgeteilt, eine Registerdatei für die niederwertigen 32 Bits von Daten und eine zweite Registerdatei für die höherwertigen 32 Bits der Daten. Die Gleitkommaregisterdatei 210 einer Ausführungsform hat 128 Bit breite Einträge, da Gleitkommabefehle typischerweise 64 bis 128 Bit breite Operanden haben.
  • Der Ausführungsblock 211 umfasst die Ausführungseinheiten 212, 214, 216, 218, 220, 222, 224, wo die Befehle tatsächlich ausgeführt werden. Dieser Abschnitt weist die Registerdateien 208, 210 auf, die die Integer- und Gleitkommadatenoperandenwerte speichern, die die Mikrobefehle benötigen, um auszuführen. Der Prozessor 200 einer Ausführungsform umfasst eine Anzahl von Ausführungseinheiten: Adressgenerierungseinheit (Address Generation Unit, AGU) 212, AGU 214, schnelle ALU 216, schnelle ALU 218, langsame ALU 220, Gleitkomma-ALU 222, Gleitkommaverschiebeinheit 224. In einer Ausführungsform führen die Gleitkommaausführungsblöcke 222, 224 Gleitkomma-, MMX-, SIMD- und SSE- oder andere Operationen aus. Die Gleitkomma-ALU 222 einer Ausführungsform weist einen 64 Bit durch 64 Bit Gleitkommadividierer auf, um Dividier-, Quadratwurzel- und Rest-Mikro-Ops auszuführen. In Ausführungsformen der vorliegenden Erfindung können Befehle, die einen Gleitkommawert involvieren, mit der Gleitkommahardware behandelt werden. In einer Ausführungsform gehen die ALU-Operationen zu den Hochgeschwindigkeits-ALU-Ausführungseinheiten 216, 218. Die schnellen ALUs 216, 218 einer Ausführungsform können schnelle Operationen mit einer effektiven Latenz von einem halben Taktzyklus ausführen. In einer Ausführungsform gehen die meisten komplexen Integer-Operationen zu der langsamen ALU 220, da die langsame ALU 220 eine Integer-Ausführungshardware für Operationen eines Typs mit langer Latenz aufweist, wie z. B. eine Multiplikator-, Verschiebungs-, Flag-Logik und Zweig-Verarbeitung. Speicherlade/speicheroperationen werden von den AGUs 212, 214 ausgeführt. In einer Ausführungsform sind die Integer-ALUs 216, 218, 220 im Zusammenhang mit Durchführen von Integer-Operationen auf 64 Bit Datenoperanden beschrieben. In alternativen Ausführungsformen können die ALUs 216, 218, 220 implementiert sein, um eine Vielzahl von Datenbits zu unterstützten, aufweisend 16, 32, 128, 256 usw. In einer ähnlichen Art und Weise können die Gleitkommaeinheiten 222, 224 implementiert sein, um einen Bereich von Operanden mit Bits verschiedener Breiten zu unterstützen. In einer Ausführungsform können die Gleitkommaeinheiten 222, 224 auf 128 Bit breiten gepackten Datenoperanden in Verbindung mit SIMD und Multimedia-Befehlen arbeiten.
  • In einer Ausführungsform verteilen die uOps-Scheduler 202, 204, 206 abhängige Operationen, bevor der Stammladevorgang die Ausführung beendet hat. Da uOps spekulativ eingeplant in dem Prozessor 200 ausgeführt werden, weist der Prozessor 200 ebenfalls eine Logik auf, um Speicher-Fehlschläge (Misses) zu behandeln. Wenn ein Datenladevorgang in dem Daten-Cache fehlschlägt, können abhängige Operationen, die den Scheduler mit temporär falschen Daten verlassen haben, in der Pipeline im Flug sein. Ein Wiederabspielmechanismus verfolgt und führt Befehle neu aus, die falsche Daten verwenden. Nur die abhängigen Operationen müssen neu abgespielt werden und den Unabhängigen ist es erlaubt, abzuschließen. Die Scheduler- und Wiederabspielmechanismen einer Ausführungsform eines Prozessors sind ebenfalls dazu entworfen, Befehle zu fangen, die Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitstellen.
  • Der Begriff „Register” kann sich auf die Prozessor-Storage-Speicherstellen auf dem Board beziehen, die als Teil von Befehlen verwendet werden, um Operanden zu identifizieren. Anders ausgedrückt können Register diejenigen sein, die von außerhalb des Prozessors (aus einer Perspektive eines Programmierers) verwendbar sind. Jedoch sollten die Register einer Ausführungsform in ihrer Bedeutung nicht auf einen bestimmten Typ einer Schaltung beschränkt sein. Vielmehr ist ein Register einer Ausführungsform in der Lage, Daten zu speichern und bereitzustellen und die hier beschriebenen Funktionen durchzuführen. Die hier beschriebenen Register können mittels Schaltkreisen innerhalb eines Prozessors unter Verwendung einer beliebigen Anzahl von unterschiedlichen Techniken implementiert sein, wie z. B. dedizierte physikalische Register, dynamisch allozierte physikalische Register unter Verwendung von Registerumbenennung, Kombinationen von dedizierten und dynamisch allozierten physikalischen Registern usw. In einer Ausführungsform speichern Integer-Register zweiunddreißig Bit Integer-Daten. Eine Registerdatei einer Ausführungsform enthält ebenfalls acht Multimedia-SIMD-Register für gepackte Daten. Für die nachfolgenden Diskussionen werden die Register als Datenregister verstanden, die entworfen sind, um gepackte Daten zu halten, wie z. B. 64 Bit breite MMXTM Register (auf die ebenfalls in einigen Fällen als „mm”-Register Bezug genommen wird) in Mikroprozessoren, die mit der MMX-Technologie von Intel Corporation aus Santa Clara, Kalifornien ausgerüstet sind. Diese MMX-Register, die sowohl in Integerals auch Gleitkommaformen verfügbar sind, können mit gepackten Datenelementen arbeiten, die SIMD- und SSE-Befehle begleiten. In einer ähnlichen Art und Weise können 128 Bit breite XMM-Register, die sich auf SSE2, SSE3, SSE4 oder eine darüber hinausgehende (auf die allgemein als „SSEx” Bezug genommen wird) Technologie beziehen, ebenfalls verwendet werden, um solche gepackten Datenoperanden zu halten. In einer Ausführungsform müssen beim Speichern von gepackten Daten und Integer-Daten die Register nicht zwischen den zwei Datentypen unterscheiden. In einer Ausführungsform sind Integer und Gleitkomma entweder in derselben Registerdatei oder unterschiedlichen Registerdateien enthalten. Darüber hinaus können in einer Ausführungsformen Gleitkomma- und Integer-Daten in unterschiedlichen Registern oder denselben Registern gespeichert sein.
  • In den Beispielen der folgenden Figuren ist eine Vielzahl von Datenoperanden beschrieben. 3A stellt verschiedene gepackte Datentypenrepräsentationen in Multimedia-Registern gemäß einer Ausführungsform der vorliegenden Erfindung dar. 3A stellt Datentypen für ein gepacktes Byte 310, ein gepacktes Wort 320 und ein gepacktes Doppelwort (dword) 330 für 128 Bit breite Operanden dar. Das gepackte Byte-Format 310 dieses Beispiels ist 128 Bit lang und enthält sechzehn gepackte Bytedatenelemente. Ein Byte ist hier als 8 Bit von Daten definiert. Informationen für jedes Bytedatenelement sind in Bit 7 bis Bit 0 für Byte 0, Bit 15 bis Bit 8 für Byte 1, Bit 23 bis Bit 16 für Byte 2 und schließlich Bit 120 bis Bit 127 für Byte 15 gespeichert. Somit werden alle verfügbaren Bits in dem Register verwendet. Diese Speicheranordnung erhöht die Speichereffizienz des Prozessors. Mit einem Zugriff auf sechzehn Datenelemente kann nun ebenfalls eine Operation auf sechzehn Datenelementen parallel durchgeführt werden.
  • Allgemein ist ein Datenelement ein individuelles Stück von Daten, das in einem einzelnen Register oder einer Speicherstelle mit anderen Datenelementen derselben Länge gespeichert ist. Bei gepackten Datensequenzen, die sich auf die SSEx-Technologie beziehen, ist die Anzahl von Datenelementen, die in einem XMM-Register gespeichert sind, 128 Bit geteilt durch die Länge in Bit eines individuellen Datenelements. In einer ähnlichen Art und Weise ist bei gepackten Datensequenzen, die sich auf MMX- und SSE-Technologie beziehen, die Anzahl von Datenelementen, die in einem MMX-Register gespeichert sind, 64 Bit geteilt durch die Länge in Bit eines individuellen Datenelements. Obwohl die in 3A dargestellten Datentypen 128 Bit lang sind, können Ausführungsformen der vorliegenden Erfindung ebenfalls mit 64 Bit breiten, 256 Bit breiten, 512 Bit breiten oder anders großen Operanden arbeiten. Das gepackte Wortformat 320 dieses Beispiels ist 128 Bit lang und enthält 8 gepackte Wortdatenelemente. Jedes gepackte Wort enthält sechzehn Bit von Informationen. Das gepackte Doppelwortformat 330 aus 3A ist 128 Bit lang und enthält vier gepackte Doppelwortdatenelemente. Jedes gepackte Doppelwortdatenelement enthält zweiunddreißig Bit von Informationen. Ein gepacktes Quadwort ist 128 Bit lang und enthält zwei gepackte Quadwort-Datenelemente.
  • 3B stellt alternative Daten-Storage-Speicherformate in einem Register dar. Jedes gepackte Datum kann mehr als ein unabhängiges Datenelement aufweisen. Drei gepackte Datenformate sind dargestellt; gepackte Hälfte 341, gepacktes Einzel 342 und gepacktes Doppel 343. Eine Ausführungsform der gepackten Hälfte 341, des gepackten Einzels 342 und des gepackten Doppels 343 enthält Festkommadatenelemente. In einer alternativen Ausführungsform kann eines oder mehrere der gepackten Hälfte 341, des gepackten Einzels 342 und des gepackten Doppels 343 Gleitkommadatenelemente enthalten. Eine alternative Ausführungsform der gepackten Hälfte 341 ist hundertachtundzwanzig Bit lang, enthaltend acht 16 Bit Datenelemente. Eine Ausführungsform des gepackten Einzels 342 ist hundertachtundzwanzig Bit lang und enthält vier 32 Bit Datenelemente. Eine Ausführungsform des gepackten Doppels 343 ist hundertachtundzwanzig Bit lang und enthält zwei 64 Bit Datenelemente. Es wird verständlich, dass solche gepackten Datenformate weiter auf andere Registerlängen erweitert werden können, beispielsweise auf 96 Bit, 160 Bit, 192 Bit, 224 Bit, 256 Bit, 512 Bit oder mehr.
  • 3C stellt verschiedene vorzeichenbehaftete und vorzeichenlose gepackte Datentyprepräsentationen in Multimedia-Registern gemäß einer Ausführungsform der vorliegenden Erfindung dar. Eine vorzeichenlose gepackte Byterepräsentation 344 stellt die Speicherung eines vorzeichenlosen gepackten Bytes in einem SIMD-Register dar. Die Information für jedes Bytedatenelement wird in Bit sieben bis Bit null für Byte null, Bit fünfzehn bis Bit acht für Byte eins, Bit dreiundzwanzig bis Bit sechzehn für Byte zwei usw. und schließlich Bit einhundertzwanzig bis Bit einhundertsiebenundzwanzig für Byte fünfzehn gespeichert. Somit werden alle verfügbaren Bits in dem Register verwendet. Diese Speicheranordnung kann die Speichereffizienz des Prozessors erhöhen. Mit einem Zugriff auf sechzehn Datenelemente kann nun ebenfalls eine Operation auf sechzehn Datenelementen parallel durchgeführt werden. Eine vorzeichenbehaftete gepackte Byterepräsentation 345 stellt die Speicherung eines vorzeichenbehafteten gepackten Bytes dar. Beachte, dass das achte Bit von jedem Bytedatenelement der Vorzeichenindikator ist. Eine vorzeichenlose gepackte Wortrepräsentation 346 stellt dar, wie Wort sieben bis Wort null in einem SIMD-Register gespeichert sind. Eine vorzeichenbehaftete gepackte Wortrepräsentation 347 ist ähnlich zu der vorzeichenlosen gepackten Wortrepräsentation 346 im Register. Beachte, dass das sechzehnte Bit von jedem Wortdatenelement der Vorzeichenindikator ist. Eine vorzeichenlose gepackte Doppelwortrepräsentation 348 zeigt, wie Doppelwortdatenelemente gespeichert sind. Eine vorzeichenbehaftete gepackte Doppelwortrepräsentation 349 ist ähnlich zu der vorzeichenlosen gepackten Doppelwortrepräsentation 348 im Register. Beachte, dass das notwendige Vorzeichenbit das zweiunddreißigste Bit von jedem Doppelwortdatenelement ist.
  • 3D ist eine Abbildung einer Ausführungsform eines Operationscodier(Opcode)-Formats 360 mit zweiunddreißig oder mehr Bits und Register/Speicheroperandenadressierungsmodi, die einen Typ von Opcode-Format entsprechen, das in dem „Intel® 64 and IA-32 Intel Architecture Software Developer's Manual Combined Volumes 2A and 2B: Instruction Set Reference A–Z”, beschrieben ist, das von der Intel Corporation, Santa Clara, CA auf dem World Wide Web (WWW) unter intel.com/products/processor/manuals/ verfügbar ist. In einer Ausführungsform kann ein Befehl durch einen oder mehrere Felder 361 und 362 codiert sein. Bis zu zwei Operandenstellen pro Befehl können identifiziert werden, aufweisend bis zu zwei Quelloperandenidentifikatoren 364 und 365. In einer Ausführungsform ist ein Zieloperandenidentifikator 366 derselbe wie der Quelloperandenidentifikator 364, während sie in anderen Ausführungsformen unterschiedlich sind. In einer alternativen Ausführungsform ist der Zieloperandenidentifikator 366 derselbe wie der Quelloperandenidentifikator 365, während sie in anderen Ausführungsformen unterschiedlich sind. In einer Ausführungsform wird einer der Quelloperanden, die durch die Quelloperandenidentifikatoren 364 und 365 identifiziert sind, mit den Ergebnissen des Befehls überschrieben, während der Identifikator 364 in anderen Ausführungsformen einem Quellregisterelement entspricht und der Identifikator 365 einem Zielregisterelement entspricht. In einer Ausführungsform können die Operandenidentifikatoren 364 und 365 verwendet werden, um 32 Bit oder 64 Bit Quell- und Zieloperanden zu identifizieren.
  • 3E ist eine Abbildung eines weiteren alternativen Operationscodier(Opcode)-Formats 370 mit vierzig oder mehr Bits. Das Opcode-Format 370 entspricht dem Opcode-Format 360 und umfasst ein optionales Präfix-Byte 378. Ein Befehl gemäß einer Ausführungsform kann durch ein oder mehrere Felder 378, 371 und 372 codiert sein. Bis zu zwei Operandenstellen pro Befehl können durch Quelloperandenidentifikatoren 374 und 375 und durch das Präfixbyte 378 identifiziert werden. In einer Ausführungsform kann das Präfixbyte 378 verwendet werden, um 32 Bit oder 64 Bit Quell- und Ziel-Operanden zu identifizieren. In einer Ausführungsform ist ein Zieloperandenidentifikator 376 derselbe wie der Quelloperandenidentifikator 374, während sie in anderen Ausführungsformen unterschiedlich sind. In einer alternativen Ausführungsform ist der Zieloperandenidentifikator 376 derselbe wie der Quelloperandenidentifikator 375, während sie in anderen Ausführungsformen unterschiedlich sind. In einer Ausführungsform arbeitet ein Befehl auf einem oder mehreren der Operanden, die durch die Operandenidentifikatoren 374 und 375 identifiziert sind, und einer oder mehrere Operanden, die durch die Operandenidentifikatoren 374 und 375 identifiziert sind, werden mit dem Ergebnis des Befehls überschrieben, während in anderen Ausführungsformen Operanden, die durch die Identifikatoren 374 und 375 identifiziert sind, in andere Datenelemente in einem anderen Register geschrieben werden. Die Opcode-Formate 360 und 370 erlauben eine Register zu Register, Speicher zu Register, Register durch Speicher, Register durch Register, Register durch Direkt (Immediate), Register zu Speicher-Adressierung, die zum Teil durch MOD-Felder 363 und 373 und durch optionale Skala-Index-Basis- und Versatz-Bytes spezifiziert ist.
  • Sich als nächstes 3F zuwendend, können in einigen alternativen Ausführungsformen 64 Bit (oder 128 Bit oder 256 Bit oder 512 Bit oder mehr) arithmetische Einzelbefehl-Mehrfachdaten(Single Instruction Multiple Data, SIMD)-Operationen durch einen Coprozessordatenverarbeitungs(CDP)-Befehl durchgeführt werden. Ein Operationscodier(Opcode)-Format 380 bildet einen solchen CDP-Befehl mit CDP-Opcode-Feldern 382 und 389 ab. Der Typ des CDP-Befehls, in alternativen Ausführungsformen der Operationen, kann durch ein oder mehrere Felder 383, 384, 387 und 388 codiert sein. Bis zu drei Operandenstellen pro Befehl können identifiziert werden, aufweisend bis zu zwei Quelloperandenidentifikatoren 385 und 390 und einen Zieloperandenidentifikator 386. Eine Ausführungsform des Coprozessors kann auf 8, 16, 32 und 64 Bit Werten arbeiten. In einer Ausführungsform wird ein Befehl auf Integer-Datenelementen durchgeführt. In einigen Ausführungsformen kann ein Befehl unter Verwendung eines Bedingungsfelds 381 bedingt ausgeführt werden. In einigen Ausführungsformen können Quelldatengrößen durch das Feld 383 codiert sein. In einigen Ausführungsformen kann eine Erkennung von Null (Zero, Z), Negativ (N), Carry (C) und Überlauf (Overflow, V) auf SIMD-Feldern gemacht werden. Für einige Befehle kann der Typ einer Sättigung durch das Feld 384 codiert sein.
  • Sich als nächstes 3G zuwendend, bildet diese ein weiteres alternatives Operationscodier(Opcode)-Format 397 ab, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer weiteren Ausführungsform bereitzustellen, die einem Typ eines Opcode-Formats entspricht, der in der „Intel® Advanced Vektor Extension Programming Reference” beschrieben ist, die von der Intel Corporation, Santa Clara, CA auf dem World Wide Web (www) unter intel.com/products/processor/manuals/ verfügbar ist.
  • Der ursprüngliche x86-Befehlssatz stellte einen 1-Byte-Opcode mit verschiedenen Formaten von Adresssilben und direkten Operanden bereit, die in zusätzlichen Bytes enthalten waren, deren Präsenz von dem ersten „Opcode”-Byte an bekannt war. Zusätzlich gab es bestimmte Byte-Werte, die als Modifikatoren für den Opcode reserviert waren (genannt Präfixe (prefixes), da sie vor dem Befehl platziert werden mussten). Wenn die ursprüngliche Palette von 256 Opcode-Bytes (aufweisend diese Sonderpräfixwerte) ausgeschöpft war, war ein einzelnes Byte für eine Umschaltung auf einen neuen Satz von 256 Opcodes reserviert. Während Vektorbefehle (z. B. SIMD) hinzugefügt wurden, wurde ein Bedarf nach mehr Opcodes generiert und die „zwei Byte”-Opcode-Abbildung war ebenfalls unzureichend, auch wenn sie durch die Verwendung von Präfixen erweitert worden ist. Zu diesem Zweck wurden neue Befehle in zusätzlichen Abbildungen hinzugefügt, die zwei Bytes plus einen optionalen Präfix als Identifikator verwenden.
  • Um zusätzliche Register in einem 64 Bit-Modus zu vereinfachen, kann zusätzlich ein zusätzliches Präfix (genannt „REX”) zwischen den Präfixen und dem Opcode (und beliebigen Umschalt-Bytes, die notwendig sind, um den Opcode zu bestimmen) verwendet werden. In einer Ausführungsform kann das REX 4 „Nutzlast” Bits haben, um eine Verwendung von zusätzlichen Registern im 64 Bit-Modus anzuzeigen. In anderen Ausführungsformen kann es weniger oder mehr als 4 Bits haben. Das allgemeine Format von mindestens einem Befehlssatz (das allgemein dem Format 360 und/oder Format 370 entspricht) wird generisch durch das Folgende dargestellt:
    [prefixes] [rex] escape [escape2] opcode modrm (usw.)
  • Das Opcode-Format 397 entspricht dem Opcode-Format 370 und umfasst optionale VEX-Präfixbytes 391 (in einer Ausführungsform beginnend mit C4 hex), um die meisten anderen gewöhnlich verwendeten Alt-Befehlspräfixbytes und Umschalt-Codes zu ersetzen. Das Folgende stellt beispielsweise eine Ausführungsform dar, die zwei Felder verwendet, um einen Befehl zu codieren, die verwendet werden kann, wenn ein zweiter Umschalt-Code in dem ursprünglichen Befehl vorhanden ist oder wenn zusätzliche Bits (z. B. die XB- und W-Felder) in dem REX-Feld verwendet werden müssen. In der nachfolgend dargestellten Ausführungsform wird ein Alt-Umschalten durch einen neuen Umschalt-Wert repräsentiert, die Alt-Präfixe werden vollständig als Teil der „Nutzlast”-Bytes komprimiert, Alt-Präfixe werden wiedergewonnen und sind für eine zukünftige Erweiterung verfügbar, der zweite Umschalt-Code ist in einem „Abbildungs”-Feld komprimiert, wobei eine zukünftige Abbildung oder Merkmalsraum verfügbar sind, und neue Merkmale werden hinzugefügt (z. B. eine erhöhte Vektorlänge und ein zusätzlicher Quellregisterspezifikator).
  • Figure DE112011105666T5_0002
  • Ein Befehl gemäß einer Ausführungsform kann durch ein oder mehrere Felder 391 und 392 codiert sein. Bis zu vier Operandenstellen pro Befehl können durch das Feld 391 in Verbindung mit Quelloperandenidentifikatoren 374 und 375 und in Verbindung mit einem optionalen Skala-Index-Basis(Scale Index Base, SIB)-Identifikator 393, einem optionalen Versatzidentifikator 394 und einem optionalen Direktbyte 395 identifiziert werden. In einer Ausführungsform können VEX-Präfixbytes 391 verwendet werden, um 32 Bit oder 64 Bit Quell- und Zieloperanden und/oder 128 Bit oder 256 Bit SIMD-Register oder Speicheroperanden zu identifizieren. In einer Ausführungsform kann die durch das Opcode-Format 397 bereitgestellte Funktionalität zu dem Opcode-Format 370 redundant sein, während sie in anderen Ausführungsformen unterschiedlich sind. Die Opcode-Formate 370 und 397 erlauben eine Register zu Register, Speicher zu Register, Register durch Speicher, Register durch Register, Register durch Direkt, Register zu Speicher-Adressierung, die zum Teil durch MOD-Feld 373 und durch optionalen (SIB) Identifikator 393, einen optionalen Versatzidentifikator 394 und ein optionales Direktbyte 395 spezifiziert ist.
  • Sich 3H zuwendend, ist diese eine Abbildung eines weiteren alternativen Operationscodier(Opcode)-Formats 398, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität gemäß einer weiteren Ausführungsform bereitzustellen. Das Opcode-Format 398 entspricht den Opcode-Formaten 370 und 397 und umfasst optionale EVEX-Präfixbytes 396 (in einer Ausführungsform beginnend mit 62 hex), um die meisten anderen allgemein verwendeten als Alt-Befehlspräfixbytes und Umschalt-Codes zu ersetzen und zusätzliche Funktionalität bereitzustellen. Ein Befehl gemäß einer Ausführungsform kann durch ein oder mehrere Felder 396 und 392 codiert sein. Bis zu vier Operandenstellen pro Befehl und eine Maske können durch Feld 396 in Kombination mit Quelloperandidentifikatoren 374 und 375 und in Kombination mit einem optionalen Skala-Index-Basis(SIB)-Identifikator 393, einem optionalen Versatzidentifikator 394 und einem optionalen Direktbyte 395 identifiziert werden. In einer Ausführungsform können die EVEX-Präfixbytes 396 verwendet werden, um 32 Bit oder 64 Bit Quell- und Zieloperanden und/oder 128 Bit, 256 Bit oder 512 Bit SIMD-Register oder Speicheroperanden zu identifizieren. In einer Ausführungsform kann die Funktionalität, die durch das Opcode-Format 398 bereitgestellt wird, zu den Opcode-Formaten 370 oder 397 redundant sein, während sie in anderen Ausführungsformen unterschiedlich sind. Das Opcode-Format 398 erlaubt Register zu Register, Speicher zu Register, Register durch Speicher, Register durch Register, Register durch Direkt, Register zu Speicher-Adressierung mit Masken, die zum Teil durch MOD-Feld 373 und durch optionalen (SIB) Indentifikator 393, einen optionalen Versatzidentifikator 394 und ein optionales Direktbyte 395 spezifiziert ist. Das allgemeine Format von mindestens einem Befehlssatz (der allgemein dem Format 360 und/oder dem Format 370 entspricht) ist generisch durch das Folgende dargestellt:
    evex1 RXBmnimmm WvvvLpp evex4 opcode modrm [sib] [disp] [imm]
  • In einer Ausführungsform kann ein Befehl, der gemäß dem EVEX-Format 398 codiert ist, zusätzliche „Nutzlast”-Bits haben, die verwendet werden können, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität mit zusätzlichen neuen Merkmalen bereitzustellen, wie z. B. ein benutzerkonfigurierbares Maskenregister oder ein zusätzlicher Operand oder eine Auswahl aus 128 Bit, 256 Bit oder 512 Bit Vektorregistern oder mehr Register, aus denen gewählt werden kann, usw.
  • Zum Beispiel kann dort, wo das VEX-Format 397 verwendet werden kann, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität mit einer impliziten Maske bereitzustellen, oder wo die zusätzliche Operation unär ist, wie z. B. eine Typkonvertierung, das EVEX-Format 398 verwendet werden, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität mit einer expliziten benutzerkonfigurierbaren Maske bereitzustellen, und wo die zusätzliche Operation binär ist, wie z. B. einer Addition oder Multiplikation, die einen zusätzlichen Operanden erfordert. Einige Ausführungsformen des EVEX-Formats 398 können ebenfalls verwendet werden, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität und einer impliziten Abschlussmaske bereitzustellen, wo die zusätzliche Operation ternär ist. Zusätzlich kann dort, wo das VEX-Format 397 verwendet werden kann, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität auf 128 Bit oder 256 Bit Vektorregistern bereitzustellen, das EVEX-Format 398 verwendet werden, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität auf 128 Bit, 256 Bit, 512 Bit oder größeren (oder kleineren) Vektorregistern bereitzustellen. Somit können Befehle zum Bereitstellen von Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität Abhängigkeiten zwischen Befehlen für zusätzliche Operationen und Befehlen für Speicheroperationen, wie z. B. Laden oder Speichern von Daten mit einem wiederholten Schritt, eliminieren.
  • Beispielhafte Befehle zum Bereitstellen von Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität sind durch die folgenden Beispiele dargestellt:
    Befehl Ziel/1. Quelle Quelle1 Maske Quelle2 Quelle3 Beschreibung
    load-op (Lade-Op) Vmm1 Vmm2 Mask1 Mem32 Schritt Verwende Schritt und Mem32, um gemäß Mask1 in Vmm1 zu laden, und wende dann Op auf Vmm1 und Vmm2 an
    store-op (Speicher-Op) Vmm1 Vmm2 Mask1 Mem32 Schritt Wende Op auf Vmm1 und Vmm2 an, verwende dann Schritt und Mem32, um gemäß Mask1 zu speichern
    load-op (Lade-Op) Vmm1 Vmm2 Mem32 Schritt Verwende Schritt und Mem32, um in Vmm1 zu laden (implizite Maske), und wende dann Op auf Vmm1 und Vmm2 an
    store-op (Speicher-Op) Vmm1 Vmm2 Mem32 Schritt Wende Op auf Vmm1 und Vmm2 an, verwende dann Schritt und Mem32, um zu speichern (implizite Maske)
    load-op (Lade-Op) Vmm1 Mask1 Mem32 Schritt Verwende Schritt und Mem32, um gemäß Mask1 in Vmm1 zu laden, und wende dann unäre Op auf Vmm1 an
    store-op (Speicher-Op) Vmm1 Mask1 Mem32 Schritt Wende unäre Op auf Vmm1 an und verwende Schritt und Mem32, um gemäß Mask1 zu speichern
    load-op (Lade-Op) Vmm1 Mask1 Mem32 Schritt Verwende Schritt und Mem32, um gemäß Mask1 in Temp zu laden, und wende dann Op auf Vmm1 und Temp an
  • 4A ist ein Blockdiagramm, das eine Pipeline in Reihenfolge (In Order-Pipeline) und eine Registerumbenennungsstufe, eine Ausgabe/Ausführungs-Pipeline außer Reihenfolge (Out Of Order-Ausgabe/Ausführungspipeline) gemäß mindestens einer Ausführungsform der Erfindung darstellt. 4B ist ein Blockdiagramm, das einen In Order-Architekturkern und eine Registerumbenennungslogik, eine Out Of Order-Ausgabe/Ausführungslogik, die in einen Prozessor eingefügt werden sollen, gemäß mindestens einer Ausführungsform der Erfindung darstellt. Die Boxen mit durchgezogener Linie in 4A stellen die In Order-Pipeline dar, während die Boxen mit gestrichelter Linie die Registerumbenennung, Out Of Order-Ausgabe/Ausführungspipeline darstellen. In einer ähnlichen Art und Weise stellen die Boxen mit durchgezogener Linie in 4B die In Order-Architekturlogik dar, während die Boxen mit gestrichelter Linie die Registerumbenennungslogik und die Out Of Order-Ausgabe/Ausführungslogik darstellen.
  • In 4A weist eine Prozessor-Pipeline 400 eine Abrufstufe 402, eine Längendecodierstufe 404, eine Decodierstufe 406 und eine Allokationsstufe 408, eine Umbenennungsstufe 410, eine Scheduling(ebenfalls bekannt als eine Verteil oder Ausgabe)-Stufe 412, eine Registerlese/Speicherlesestufe 414, eine Ausführungsstufe 416, eine Rückschreib/Speicherschreibstufe 418, eine Ausnahmenbehandlungsstufe 422 und eine Übergabestufe 424 auf.
  • In 4B bezeichnen Pfeile eine Kopplung zwischen zwei oder mehr Einheiten und die Richtung des Pfeils gibt eine Richtung eines Datenflusses zwischen diesen Einheiten an. 4B zeigt einen Prozessorkern 490, der eine Frontend-Einheit 430 aufweist, die an eine Ausführungs-Engine-Einheit 450 gekoppelt ist, und beide sind an eine Speichereinheit 470 gekoppelt.
  • Der Kern 490 kann ein Reduced Instruction Set Computing(RISC)-Kern, ein Complex Instruction Set Computing(CISC)-Kern, ein Very Long Instruction Word(VLIW)-Kern oder ein Typ eines hybriden oder alternativen Kerns sein. Als eine noch weitere Möglichkeit kann der Kern 490 ein Spezialkern sein, wie z. B. ein Netzwerk- oder Kommunikationskern, eine Kompressions-Engine, ein Grafikkern oder Ähnliches.
  • Die Frontend-Einheit 430 weist eine Sprungvorhersageeinheit 432 auf, die an eine Befehls-Cache-Einheit 434 gekoppelt ist, die an einen Befehlsübersetzungsnachschlagepuffer (Translation Lookaside Buffer, TLB) 436 gekoppelt ist, der an eine Befehlsabrufeinheit 438 gekoppelt ist, die an eine Decodiereinheit 440 gekoppelt ist. Die Decodiereinheit oder der Decodierer können Befehle decodieren und als Ausgabe eine oder mehrere Mikrooperationen, Mikrocodeeinstiegspunkte, Mikrobefehle, andere Befehle oder andere Kontrollsignale generieren, die aus den ursprünglichen Befehlen decodiert werden oder die ursprünglichen Befehle anderweitig reflektieren oder aus ihnen abgeleitet sind. Der Decodierer kann unter Verwendung von verschiedenen unterschiedlichen Mechanismen implementiert sein. Beispiele von geeigneten Mechanismen weisen auf, sind jedoch nicht beschränkt auf Nachschlagetabellen, Hardware-Implementierungen, programmierbare logische Arrays (PLAs), Mikrocode-Read Only Memories (ROMs) usw. Die Befehls-Cache-Einheit 434 ist ferner an eine Cache-Einheit 476 auf Ebene 2 (Level 2, L2) in der Speichereinheit 470 gekoppelt. Die Decodiereinheit 440 ist an eine Umbenennungs/Allokatoreinheit 452 in der Ausführungs-Engine-Einheit 450 gekoppelt.
  • Die Ausführungs-Engine-Einheit 450 weist die Umbenennungs/Allokatoreinheit 452 auf, die an eine Ausscheideeinheit 454 und einen Satz von einer oder mehreren Scheduler-Einheit(en) 456 gekoppelt ist. Die Scheduler-Einheit(en) 456 repräsentiert eine beliebige Anzahl von unterschiedlichen Schedulern, aufweisend Reservierungsstationen, zentrales Befehlsfenster usw. Die Scheduler-Einheit(en) 456 ist an die physikalische Registerdatei(en)-Einheit(en) 458 gekoppelt. Jede der physikalischen Registerdatei(en)-Einheiten 458 repräsentiert eine oder mehrere physikalische Registerdateien, von denen unterschiedliche einen oder mehrere unterschiedliche Datentypen speichern, wie z. B. skalarer Integer, skalares Gleitkomma, gepackter Integer, gepacktes Gleitkomma, Vektor-Integer, Vektor-Gleitkomma usw., Status (z. B. ein Befehlszeiger, der die Adresse des nächsten Befehls ist, der ausgeführt werden soll), usw. Die physikalischen Registerdatei(en)-Einheit(en) 458 überlappt mit der Ausscheideeinheit 454, um verschiedene Möglichkeiten darzustellen, wie Registerumbenennung und Out Of Order-Ausführung implementiert werden kann (z. B. unter Verwendung eines/von Umbenennungspuffers/-puffern und einer/von Ausscheideregisterdatei(en), unter Verwendung einer/von zukünftigen Datei(en), eines/von Historienpuffers/-puffern und einer/von Ausscheideregisterdatei(en); unter Verwendung von Registerabbildungen und eines Pools von Registern; usw.). Allgemein sind die architektonischen Register von außerhalb des Prozessors oder aus einer Perspektive eines Programmierers sichtbar. Die Register sind nicht auf irgendeinen bekannten bestimmten Typ einer Schaltung beschränkt. Verschiedene unterschiedliche Typen von Registern sind geeignet, solange sie in der Lage sind, Daten wie hier beschrieben zu speichern und bereitzustellen. Beispiele von geeigneten Registern weisen auf, sind jedoch nicht beschränkt auf dedizierte physikalische Register, dynamisch allozierte physikalische Register, die Registerumbenennung verwenden, Kombinationen von dedizierten und dynamisch allozierten physikalischen Registern usw. Die Ausscheideeinheit 454 und die physikalische(n) Registerdatei(en)-Einheit(en) 458 sind an den/die Ausführungscluster 460 gekoppelt. Der/Die Ausführungscluster 460 weisen einen Satz von einer oder mehreren Ausführungseinheiten 462 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 464 auf. Die Ausführungseinheiten 462 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und auf verschiedenen Typen von Daten (z. B. skalares Gleitkomma, gepackter Integer, gepacktes Gleitkomma, Vektor-Integer, Vektor-Gleitkomma) durchführen. Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten aufweisen können, die spezifischen Funktionen oder Sätzen von Funktionen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten aufweisen, die alle alle Funktionen durchführen. Die Scheduler-Einheit(en) 456, die physikalische Registerdatei(en)-Einheit(en) 458 und der/die Ausführungscluster 460 sind möglicherweise mehrfach gezeigt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Typen von Daten/Operationen erzeugen (z. B. eine skalare Integer-Pipeline, eine skalare Gleitkomma/gepackte Integer/gepackte Gleitkomma/Vektor-Integer/Vektor-Gleitkomma-Pipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Scheduler-Einheit, physikalische Registerdatei(en)-Einheit und/oder Ausführungscluster haben und im Fall einer separaten Speicherzugriffspipeline sind bestimmte Ausführungsformen implementiert, in den nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 464 hat). Es sollte ebenfalls verständlich sein, dass dort, wo separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines eine Out Of Order-Ausgabe/Ausführung und der Rest In Order (in Reihenfolge) sein kann.
  • Der Satz von Speicherzugriffseinheiten 464 ist an die Speichereinheit 470 gekoppelt, die eine Daten-TLB-Einheit 472 aufweist, die an eine Daten-Cache-Einheit 474 gekoppelt ist, die an eine Cache-Einheit 476 auf Ebene 2 (Level 2, L2) gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 464, eine Ladeeinheit, eine Speicheradresseinheit und eine Speicherdateneinheit aufweisen, von denen jede an die Daten-TLB-Einheit 472 in der Speichereinheit 470 gekoppelt ist. Die L2-Cache-Einheit 476 ist an eine oder mehre andere Ebenen von Cache und schließlich an einen Hauptspeicher gekoppelt.
  • Die beispielhafte Registerumbenennung, Out Of Order-Ausgabe/Ausführungskernarchitektur kann beispielsweise die Pipeline 400 wie folgt implementieren: 1) der Befehlsabruf 438 führt die Abruf- und Längendecodierstufen 402 und 404 durch; 2) die Decodiereinheit 440 führt die Decodierstufe 406 durch; 3) die Umbenennungs/Allokatoreinheit 452 führt die Allokationsstufe 408 und die Umbenennungsstufe 410 durch; 4) die Scheduler-Einheit(en) 456 führt die Einplanungsstufe 412 durch; 5) die physikalische(n) Registerdatei(en)-Einheit(en) 458 und die Speichereinheit 470 führen die Registerlese/Speicherlesestufe 414 durch; der Ausführungscluster 460 führt die Ausführungsstufe 416 durch; 6) die Speichereinheit 470 und die physikalische(n) Registerdatei(en)-Einheit(en) 458 führen die Rückschreib/Speicherschreibstufe 418 durch; 7) verschiedene Einheiten können bei der Ausnahmenbehandlungsstufe 422 involviert sein; und 8) die Ausscheideeinheit 454 und die physikalische(n) Registerdatei(en)-Einheit(en) 458 führen die Übergabestufe 424 durch.
  • Der Kern 490 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 z. B. NEON) von ARM Holdings aus Sunnyvale, CA).
  • Es sollte verständlich sein, dass der Kern Multithreading unterstützen kann (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) und dies auf verschiedenen Wegen machen kann, aufweisend Zeitscheiben-Multithreading, simultanes Multithreading (wo ein einzelner physikalischer Kern einen logischen Kern für jeden der Threads bereitstellt, ist dieser physikalische Kern simultan Multithreading) oder eine Kombination davon (z. B. Zeitscheibenabruf und Decodieren und danach simultanes Multithreading, wie z. B. die Intel® Hyperthreading-Technologie).
  • Während Registerumbenennung im Kontext der Out Of Order-Ausführung beschrieben ist, sollte verständlich sein, dass Registerumbenennung in einer In Order-Architektur verwendet werden kann. Während die dargestellte Ausführungsform des Prozessors ebenfalls separate Befehls- und Daten-Cache-Einheiten 434/474 und eine gemeinsame L2-Cache-Einheit 476 aufweist, können alternative Ausführungsformen einen einzelnen internen Cache sowohl für Befehle als auch Daten haben, wie z. B. einen internen Cache auf Ebene 1 (Level 1, L1), oder mehrere Ebenen eines internen Cache. In einigen Ausführungsformen kann das System eine Kombination eines internen Cache und eines externen Cache aufweisen, der extern zu dem Kern und/oder dem Prozessor ist. Alternativ können alle Caches extern zu dem Kern und/oder Prozessor sein.
  • 5 ist ein Blockdiagramm eines Einzelkernprozessors und eines Mehrkernprozessors 500 mit einem integrierten Speichercontroller und Grafik gemäß Ausführungsformen der Erfindung. Die Boxen mit durchgezogener Linie in 5 stellen einen Prozessor 500 mit einem einzelnen Kern 502A, einem Systemagenten 510, einem Satz von einem oder mehreren Bus-Controller-Einheiten 516 dar, während die optionale Hinzufügung von Boxen mit gestrichelten Linien einen alternativen Prozessor 500 mit mehreren Kernen 502A–N, einen Satz von einer oder mehreren integrierten Speicher-Controller-Einheit(en) 514 in der Systemagenteneinheit 510 und eine integrierte Grafiklogik 508 darstellt.
  • Die Speicherhierarchie weist eine oder mehrere Ebenen von Cache innerhalb des Kerns, einen Satz von oder eine oder mehrere gemeinsame Cache-Einheiten 506 und einen externen Speicher (nicht gezeigt), auf der an den Satz von integrierten Speicher-Controller-Einheiten 514 gekoppelt ist. Der Satz von gemeinsamen Cache-Einheiten 506 kann einen oder mehrere Caches auf mittlerer Ebene (Mid-Level), wie z. B. Ebene 2 (Level 2, L2), Ebene 3 (Level 3, L3), Ebene 4 (Level 4, L4) oder andere Ebenen von Cache, einen Cache auf letzter Ebene (Last Level Cache, LLC) und/oder Kombinationen davon aufweisen. Während in einer Ausführungsform eine ringbasierte Interconnect-Einheit 512 die integrierte Grafiklogik 508, den Satz von gemeinsamen Cache-Einheiten 506 und die Systemagenteneinheit 510 verschaltet, können alternative Ausführungsformen eine beliebige Anzahl von wohlbekannten Techniken zum Zusammenschalten solcher Einheiten verwenden.
  • In einigen Ausführungsformen sind einer oder mehrere der Kerne 502A–N in der Lage zum Multi-Threading. Der Systemagent 510 weist diese Komponenten auf, die die Kerne 502A–N koordinieren und betreiben. Die Systemagenteneinheit 510 kann beispielsweise eine Leistungssteuereinheit (Power Control Unit, PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann aus Logik und Komponenten sein oder diese aufweisen, die zum Regulieren des Leistungszustands der Kerne 502A–N und der integrierten Grafiklogik 508 benötigt werden. Die Anzeigeeinheit ist zum Betreiben einer oder mehrerer extern verbundener Anzeigen oder Displays.
  • Die Kerne 502A–N können bezüglich der Architektur und/oder des Befehlssatzes homogen oder heterogen sein. Beispielsweise können einige der Kerne 502A–N In Oder sein, während andere Out Of Order sind. Als ein weiteres Beispiel können zwei oder mehr der Kerne 502A–N in der Lage sein zur Ausführung desselben Befehlssatzes, während andere in der Lage sein können zum Ausführen nur eines Teilsatzes dieses Befehlssatzes oder eines unterschiedlichen Befehlssatzes.
  • Der Prozessor kann ein Allzweckprozessor sein, wie z. B. ein CoreTM i3, i5, i7, 2 Duo und Quad, XeonTM, ItaniumTM, XScaleTM oder StrongARMTM-Prozessor, die von der Intel Corporation aus Santa Clara, Kalifornien verfügbar sind. Alternativ kann der Prozessor von einem anderen Unternehmen sein, wie z. B. die ARM Holdings, Ltd., MIPS usw. Der Prozessor kann ein Spezialprozessor sein, wie z. B. ein Netzwerk- oder Kommunikationsprozessor, eine Kompressions-Engine, ein Grafikprozessor, ein Coprozessor, ein eingebetteter Prozessor oder Ähnliches. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 500 kann ein Teil eines und/oder kann auf einem oder mehreren Substraten implementiert sein unter Verwendung einer beliebigen Anzahl von Verarbeitungstechnologien, wie z. B. BiCMOS, CMOS oder NMOS.
  • 68 sind beispielhafte Systeme, die zum Aufnehmen des Prozessors 500 geeignet sind, während 9 ein beispielhaftes System auf einem Chip (System an a Chip, SoC) ist, das einen oder mehrere der Kerne 502 aufweisen kann. Andere System-Designs und Konfigurationen, die im Stand der Technik für Laptops, Desktops, handgehaltene PCs, Personal Digital Assistants, Ingenieur-Workstations, Server, Netzwerkvorrichtungen, Netzwerk-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), grafische Vorrichtungen, Videospielvorrichtungen, Set-Top Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienspieler, handgehaltene Vorrichtungen und verschiedene andere elektronische Vorrichtungen bekannt sind, sind ebenfalls geeignet. Im Allgemeinen ist eine große Vielzahl von Systemen oder elektronischen Vorrichtungen, die in der Lage sind zum Aufnehmen eines Prozessors und/oder anderer Ausführungslogik, wie sie hier offenbart sind, im Allgemeinen geeignet.
  • Nun Bezug nehmend auf 6 ist ein Blockdiagramm eines Systems 600 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 600 kann einen oder mehrere Prozessoren 610, 615 aufweisen, die an einen Grafikspeicher-Controller-Hub (GMCH) 620 gekoppelt sind. Die optionale Art und Weise von zusätzlichen Prozessoren 615 ist in 6 durch gestrichelte Linien angegeben.
  • Jeder Prozessor 610, 615 kann irgendeine Version des Prozessors 500 sein. Jedoch sollte beachtet werden, dass es unwahrscheinlich ist, dass die integrierte Grafiklogik und die integrierten Speichersteuereinheiten in den Prozessoren 610, 615 existieren würden. 6 stellt dar, dass der GMCH 620 an einen Speicher 640 gekoppelt sein kann, der beispielsweise ein dynamischer Random Access Memory (DRAM) sein kann. Der DRAM kann in mindestens einer Ausführungsform einem nicht flüchtigen Cache zugeordnet sein.
  • Der GMCH 620 kann ein Chipsatz oder ein Teil eines Chipsatzes sein. Der GMCH 620 kann mit dem/den Prozessor(en) 610, 615 kommunizieren und eine Interaktion zwischen dem/den Prozessor(en) 610, 615 und dem Speicher 640 steuern. Der GMCH 620 kann ebenfalls als eine beschleunigte Busschnittstelle zwischen dem/den Prozessor(en) 610, 615 und anderen Elementen des Systems 600 agieren. In mindestens einer Ausführungsform kommuniziert der GMCH 620 mit dem/den Prozessor(en) 610, 615 über einen Multi-Drop-Bus, wie z. B. einen Frontside-Bus (FSB) 695.
  • Der GMCH 620 ist ferner an eine Anzeige 645 gekoppelt (wie z. B. einen Flachbildschirm). Der GMCH 620 kann einen integrierten Grafikbeschleuniger aufweisen. Der GMCH 620 ist ferner an einen Eingabe/Ausgabe(I/O)-Controller-Hub (ICH) 650 gekoppelt, der verwendet werden kann, um verschiedene Peripherievorrichtungen an das System 600 zu koppeln. In der Ausführungsform aus 6 ist z. B. eine externe Grafikvorrichtung 660 gezeigt, die eine diskrete Grafikvorrichtung sein kann, die an den ICH 650 gekoppelt ist, zusammen mit anderen Peripherievorrichtungen 670.
  • Alternativ können ebenfalls zusätzliche oder unterschiedliche Prozessoren in dem System 600 vorhanden sein. Beispielsweise kann ein/können zusätzliche(r) Prozessor(en) 650 einen zusätzlichen/zusätzliche Prozessor(en), der derselbe/die dieselben wie der Prozessor 610 ist/sind, (einen) zusätzliche(n) Prozessor(en), der/die zu dem Prozessor 610 heterogen oder asymmetrisch ist/sind, Beschleuniger (wie z. B. Grafikbeschleuniger oder digitale Signalverarbeitungs(DSP)-Einheiten), feldprogrammierbare Gatter-Arrays oder einen beliebigen anderen Prozessor aufweisen. Es kann eine Vielzahl von Unterschieden zwischen den physikalischen Ressourcen 610, 615 hinsichtlich eines Spektrums von Leistungsmetrik geben, aufweisend architektonische, mikroarchitektonische, thermale, Leistungsverbrauchseigenschaften und ähnliche. Diese Unterschiede können sich effektiv selbst als Asymmetrie und Heterogenität unter den Prozessoren 610, 615 manifestieren. In mindestens einer Ausführungsform können die verschiedenen Prozessoren 610, 615 auf derselben Die-Packung angesiedelt sein.
  • Nun Bezug nehmend auf 7 ist ein Blockdiagramm eines zweiten Systems 700 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 7 gezeigt, ist das Multiprozessorsystem 700 ein Punkt-zu-Punkt-Interconnect-System und weist einen ersten Prozessor 770 und einen zweiten Prozessor 780 auf, die über einen Punkt-zu-Punkt-Interconnect 750 gekoppelt sind. Jeder der Prozessoren 770 und 780 kann irgendeine Version des Prozessors 500 als einer oder mehrere der Prozessoren 610, 615 sein.
  • Obwohl nur mit zwei Prozessoren 770, 780 gezeigt, sollte verständlich sein, dass der Umfang der vorliegenden Erfindung nicht derart beschränkt ist. In anderen Ausführungsformen kann ein oder mehrere zusätzliche Prozessoren in einem gegebenen Prozessor vorhanden sein.
  • Die Prozessoren 770 und 780 sind derart gezeigt, dass sie integrierte Speicher-Controller-Einheiten 772 bzw. 782 aufweisen. Der Prozessor 770 weist ebenfalls als Teil seiner Bus-Controller-Einheiten Punkt-zu-Punkt(P-P)-Schnittstellen 776 und 778 auf; in einer ähnlichen Art und Weise weist der zweite Prozessor 780 P-P-Schnittstellen 776 und 788 auf. Die Prozessoren 770, 780 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 750 unter Verwendung der P-P-Schnittstellenschaltungen 778, 788 austauschen. Wie in 7 gezeigt, koppeln IMCs 772 und 782 die Prozessoren an entsprechende Speicher und zwar einen Speicher 732 und einen Speicher 734, die Teile eines Hauptspeichers sein können, der lokal an die entsprechenden Prozessoren angeschlossen ist.
  • Die Prozessoren 770, 780 können jeweils Informationen mit einem Chipsatz 790 über individuelle P-P-Schnittstellen 752, 754 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 776, 794, 786, 798 austauschen. Der Chipsatz 790 kann ebenfalls Informationen mit einer Hochleistungsgrafikschaltung 738 über eine Hochleistungsgrafikschnittstelle 739 austauschen.
  • Ein gemeinsamer Cache (nicht gezeigt) kann in jeden Prozessor oder außerhalb von beiden Prozessoren, jedoch verbunden mit den Prozessoren über einen P-P-Interconnect aufgenommen sein, so dass lokale Cache-Informationen des einen oder beider Prozessoren in dem gemeinsamen Cache gespeichert sein können, wenn ein Prozessor in einen Niedrigleistungsmodus versetzt wird.
  • Der Chipsatz 790 kann an einen ersten Bus 716 über eine Schnittstelle 796 gekoppelt sein. In einer Ausführungsform kann der erste Bus 716 ein Peripheral Component Interconnect(PCI)-Bus sein oder ein Bus, wie z. B. ein PCI Express-Bus oder ein anderer I/O-Interconnect-Bus einer dritten Generation sein, obwohl der Umfang der vorliegenden Erfindung nicht derart beschränkt ist.
  • Wie in 7 gezeigt, können verschiedene I/O-Vorrichtungen 714 an den ersten Bus 716 zusammen mit einer Busbrücke 718 gekoppelt sein, die den ersten Bus 716 an einen zweiten Bus 720 koppelt. In einer Ausführungsform kann der zweite Bus 720 ein Low Pin Count(LPC)-Bus sein. Verschiedene Vorrichtungen können an den zweiten Bus 720 gekoppelt sein, aufweisend beispielsweise eine Tastatur und/oder eine Maus 722, Kommunikationsvorrichtungen 727 und eine Storage-Speichervorrichtung 728, wie z. B. ein Plattenlaufwerk oder eine Massen-Storage-Speichervorrichtung, die Befehle/Code und Daten 730 aufweisen kann, in einer Ausführungsform. Eine Audio-I/O 724 kann ferner an den zweiten Bus 720 gekoppelt sein. Beachte, dass andere Architekturen möglich sind. Beispielsweise kann ein System statt der Punkt-zu-Punkt-Architektur aus 7 einen Multi-Drop-Bus oder eine andere solche Architektur implementieren.
  • Nun Bezug nehmend auf 8 ist ein Blockdiagramm eines dritten Systems 800 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in 7 und 8 tragen gleiche Bezugszeichen und bestimmte Aspekte aus 7 wurden in 8 ausgelassen, um ein Verschleiern weiterer Aspekte aus 8 zu verhindern.
  • 8 stellt dar, dass die Prozessoren 870, 880 einen integrierten Speicher und I/O-Steuerlogik („SL”) 872 bzw. 882 aufweisen können. In mindestens einer Ausführungsform kann die SL 872, 882 integrierte Speicher-Controller-Einheiten aufweisen, wie z. B. die oben in Verbindung mit 5 und 7 beschriebenen. Zusätzlich kann die SL 872, 882 ebenfalls eine I/O-Steuerlogik aufweisen. 8 stellt dar, dass nicht nur die Speicher 832, 834 an die SL 872, 882 gekoppelt sind, sondern ebenfalls, dass I/O-Vorrichtung 814 ebenfalls an die Steuerlogik 872, 882 gekoppelt sind. Alt-I/O-Vorrichtungen 815 sind an den Chipsatz 890 gekoppelt.
  • Nun Bezug nehmend auf 9 ist ein Blockdiagramm eines SoC 900 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 5 tragen gleiche Bezugszeichen. Boxen mit gestrichelten Linien sind ebenfalls optionale Merkmale auf mehr weiterentwickelten SoCs. In 9 ist eine/sind Interconnect-Einheit(en) 902 gekoppelt an: einen Anwendungsprozessor 910, der einen Satz von einem oder mehreren Kernen 502A–N und (eine) gemeinsame Cache-Einheit(en) 506 aufweist; eine Systemagenteneinheit 510; (eine) Bus-Controller-Einheit(en) 516; (eine) integrierte Speicher-Controller-Einheit(en) 514; einen Satz von einem oder mehreren Mediaprozessoren 920, die eine integrierte Grafiklogik 508, einen Bildprozessor 924 zum Bereitstellen von Stand- und/oder Videokamerafunktionalität, einen Audioprozessor 926 zum Bereitstellen von Hardware-Audio-Beschleunigung und einen Videoprozessor 928 zum Bereitstellen von Videocodier/Decodierbeschleunigung aufweisen können; eine statische Random Access Memory(SRAM)-Einheit 930; eine Direct Memory Access(DMA)-Einheit 932; und eine Anzeigeeinheit 940 zum Koppeln an eine oder mehrere externe Anzeigen.
  • 10 stellt einen Prozessor dar, der eine Zentralverarbeitungseinheit (CPU) und eine Grafikverarbeitungseinheit (GPU) umfasst, die mindestens einen Befehl gemäß einer Ausführungsform durchführen können. In einer Ausführungsform könnte ein Befehl zum Durchführen von Operationen gemäß mindestens einer Ausführungsform von der CPU durchgeführt werden. In einer weiteren Ausführungsform könnte der Befehl von der GPU durchgeführt werden. In noch einer weiteren Ausführungsform kann der Befehl durch eine Kombination von Operationen durchgeführt werden, die von der GPU und der CPU durchgeführt werden. Ein Befehl in Übereinstimmung mit einer Ausführungsform kann z. B. in einer Ausführungsform empfangen werden und zur Ausführung auf der GPU decodiert werden. Jedoch kann eine oder mehrere Operationen innerhalb des decodierten Befehls von einer CPU durchgeführt werden und das Ergebnis an die GPU zum, finalen Ausscheiden des Befehls zurückgegeben werden. Umgekehrt kann in einigen Ausführungsformen die CPU als der primäre Prozessor und die GPU als der Coprozessor agieren.
  • In einigen Ausführungsformen können Befehle, die aus hochgradig parallelen Durchsatzprozessoren Vorteile ziehen, von der GPU durchgeführt werden, während Befehle, die aus der Leistung von Prozessoren Vorteile ziehen, die aus Architekturen mit tiefen Pipelines Vorteile ziehen, von der CPU durchgeführt werden können. Beispielsweise können grafische, wissenschaftliche Anwendungen, finanzielle Anwendungen und andere parallele Arbeitslasten aus der Leistung der GPU Vorteile ziehen und entsprechend ausgeführt werden, während stärker sequentielle Anwendungen, wie z. B. ein Betriebssystemkernel oder Anwendungscode, für die CPU besser geeignet sein können.
  • In 10 weist ein Prozessor 1000 eine CPU 1005, eine GPU 1010, einen Bildprozessor 1015, einen Videoprozessor 1020, einen USB-Controller 1025, einen UART-Controller 1030, einen SPI/SDIO-Controller 1035, eine Anzeigevorrichtung 1040, einen High-Definition Multimedia Interface(HDMI)-Controller 1045, einen MIPI-Controller 1050, einen Flash-Speicher-Controller 1055, einen Dual Data Rate(DDR)-Controller 1060, eine Sicherheits-Engine 1065 und eine I2S/I2C (Integrated Interchip Sound/Inter-Integrated Circuit)-Schnittstelle 1070 auf. Andere Logik und Schaltungen können in dem Prozessor aus 10 aufgenommen sein, aufweisend mehr CPUs oder GPUs und andere Peripherieschnittstellen-Controller.
  • Einer oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Daten implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, die verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen werden, die Maschine dazu veranlassen, Logik zu fabrizieren, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, bekannt als „IP-Kerne”, können auf einem greifbaren, maschinenlesbaren Medium („Band”) gespeichert sein und verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, um in Fabrikationsmaschinen geladen zu werden, die tatsächlich die Logik oder den Prozessor machen. Beispielsweise können IP-Kerne, wie z. B. die CortexTM-Familie von Prozessoren, die von ARM Holdings, Ltd. entwickelt werden, und Loongson IP-Kerne, die von dem Institute of Computing Technology (ICT) der Chinese Academy of Sciences entwickelt werden, an verschiedene Kunden oder Lizenznehmer lizensiert oder verkauft werden, wie z. B. Texas Instruments, Qualcomm, Apple oder Samsung und in Prozessoren implementiert sein, die von diesen Kunden oder Lizenznehmern produziert werden.
  • 11 zeigt ein Blockdiagramm, das die Entwicklung von IP-Kernen gemäß einer Ausführungsform darstellt. Storage-Speicher 1130 weist Simulationssoftware 1120 und/oder Hardware oder ein Softwaremodell 1110 auf. In einer Ausführungsform können die Daten, die das IP-Kerndesign repräsentieren, dem Storage-Speicher 1130 über Speicher 1140 (z. B. eine Festplatte), eine verdrahtete Verbindung (z. B. das Internet) 1150 oder eine drahtlose oder Funkverbindung 1160 bereitgestellt sein. Die IP-Kerninformationen, die von dem Simulationswerkzeug generiert werden, und das Modell können dann an eine Fabrikationseinrichtung übermittelt werden, wo es durch einen Dritten fabriziert werden kann, um mindestens einen Befehl in Übereinstimmung mit mindestens einer Ausführungsform durchzuführen.
  • In einigen Ausführungsformen kann ein oder mehrere Befehle einem ersten Typ oder Architektur (z. B. x86) entsprechen und auf einem Prozessor eines anderen Typs oder Architektur (z. B. ARM) übersetzt oder emuliert werden. Ein Befehl gemäß einer Ausführungsform kann deshalb auf einem beliebigen Prozessor oder Prozessortyp durchgeführt werden, aufweisend ARM, x86, MIPS, eine GPU oder einen anderen Prozessortyp oder Architektur.
  • 12 stellt dar, wie ein Befehl eines ersten Typs von einem Prozessor eines unterschiedlichen Typs gemäß einer Ausführungsform emuliert wird. In 12 enthält ein Programm 1205 einige Befehle, die dieselbe oder im Wesentlichen dieselbe Funktion wie ein Befehl gemäß einer Ausführungsform ausführen können. Die Befehle des Programms 1205 können jedoch einen Typ haben und/oder ein Format aufweisen, das unterschiedlich oder inkompatibel mit einem Prozessor 1215 ist, was bedeutet, dass die Befehle des Typs in Programm 1205 nicht in der Lage sein müssen, nativ von dem Prozessor 1215 ausgeführt zu werden. Jedoch werden unter Zuhilfenahme einer Emulationslogik 1210 die Befehle des Programms 1205 in Befehle übersetzt, die nativ in der Lage sind, von dem Prozessor 1215 ausgeführt zu werden. In einer Ausführungsform ist die Emulationslogik in Hardware ausgeführt. In einer weiteren Ausführungsform ist die Emulationslogik auf einem greifbaren, maschinenlesbaren Medium ausgeführt, das Software enthält, um Befehle des Typs in dem Programm 1205 in den Typ zu übersetzen, der von dem Prozessor 1215 nativ ausführbar ist. In weiteren Ausführungsformen ist die Emulationslogik eine Kombination aus Hardware mit fester Funktion oder programmierbarer Hardware und einem Programm, das auf einem greifbaren, maschinenlesbaren Medium gespeichert ist. In einer Ausführungsform umfasst der Prozessor die Emulationslogik, während in anderen Ausführungsformen die Emulationslogik außerhalb des Prozessors existiert und durch einen Dritten bereitgestellt wird. In einer Ausführungsform ist der Prozessor in der Lage, die Emulationslogik zu laden, die in einem greifbaren, maschinenlesbaren Medium verkörpert ist, das Software enthält, durch Ausführen von Mikrocode oder Firmware, die in dem Prozessor enthalten oder dem Prozessor zugeordnet ist.
  • 13 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlskonvertierers kontrastiert, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß einer Ausführungsform der Erfindung zu konvertieren. In der dargestellten Ausführungsform ist der Befehlskonvertierer ein Softwarebefehlskonvertierer, obwohl der Befehlskonvertierer alternativ als Software, Firmware, Hardware oder verschiedene Kombinationen davon implementiert sein kann. 13 zeigt ein Programm in einer Sprache 1302 auf einer hohen Ebene, das unter Verwendung eines x86-Compilers 1304 kompiliert werden kann, um x86-Binärcode 1306 zu generieren, der nativ von einem Prozessor mit mindestens einem x86-Befehlssatzkern 1316 ausgeführt werden kann. Der Prozessor mit dem mindestens einen x86-Befehlssatzkern 1316 repräsentiert einen beliebigen Prozessor, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern durchführen kann, durch kompatibles Ausführen oder anderweitiges Verarbeiten von (1) einem wesentlichen Abschnitt des Befehlssatzes des Intel x86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die darauf ausgerichtet ist, auf einem Intel-Prozessor ohne mindestens einem x86-Befehlssatzkern zu laufen, um im Wesentlichen dasselbe Ergebnis, wie ein Intel-Prozessor ohne mindestens einem x86-Befehlssatzkern zu erreichen. Der x86-Compiler 1304 repräsentiert einen Compiler, der betriebsbereit ist, x86-Binärcode 1306 (z. B. Objektcode) zu generieren, der mit oder ohne zusätzlicher Linkage-Verarbeitung auf dem Prozessor mit mindestens einem x86-Befehlssatzkern 1316 ausgeführt werden kann. In einer ähnlichen Art und Weise zeigt 13 das Programm in der Sprache 1302 auf hoher Ebene, das unter Verwendung eines alternativen Befehlssatzcompilers 1308 kompiliert werden kann, um einen alternativen Befehlssatzbinärcode 1310 zu generieren, der nativ von einem Prozessor mit mindestens einem x86-Befehlssatzkern 1314 ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA ausführen und/oder die den ARM-Befehlssatz von ARM Holding aus Sunnyvale, CA ausführen). Der Befehlskonvertierer 1312 wird verwendet, um den x86-Binärcoe 1306 in Code zu konvertieren, der von dem Prozessor ohne einen x86-Befehlssatzkern 1314 nativ ausgeführt werden kann. Es ist unwahrscheinlich, dass dieser konvertierte Code derselbe wie der alternative Befehlssatzbinärcode 1310 ist, da ein Befehlskonvertierer, der dazu in der Lage wäre, schwer zu machen ist. Jedoch wird der konvertierte Code die allgemeine Operation erreichen und aus Befehlen aus dem alternativen Befehlssatz aufgebaut sein. Somit repräsentiert der Befehlskonvertierer 1312 Software, Firmware, Hardware oder eine Kombination davon, die durch Emulation, Simulation oder einen anderen beliebigen Prozess einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86-Befehlssatzprozessor oder Kern hat, erlaubt, den x86-Binärcode 1306 auszuführen.
  • 14 stellt ein Diagramm für eine Ausführungsform eines Verfahrens 1401 dar, um Vektor-Lade-Op mit Schritt-Funktionalität bereitzustellen. Das Verfahren 1401 und andere hier offenbarte Verfahren werden durch Verarbeitungsblöcke durchgeführt, die dedizierte Hardware oder Software oder Software der Operationscodes umfassen können, die von Allzweckmaschinen oder von Spezialmaschinen oder von einer Kombination von beiden ausführbar sind.
  • In einem Verarbeitungsblock 1409 des Verfahrens 1401 wird optional ein Duplikat von der Maske erzeugt, die verwendet werden soll, wenn die zweite Operation durchgeführt wird. Die Verarbeitung fährt dann mit Verarbeitungsblock 1410 fort, wobei ein nächster Wert aus jedem Feld aus einer Vielzahl von Maskenfeldern in einem Maskenregister gelesen wird. Es wird verständlich, dass obwohl das Verfahren 1401 als iterativ dargestellt ist, es vorteilhaft sein kann, viele der Operationen parallel durchzuführen, wenn dies möglich ist. Jedes aus der Vielzahl von Maskenfeldern in dem Maskenregister kann einem Vielfachen einer Schrittlänge von einer Startadresse für ein entsprechendes Datenelement in einem Speicher entsprechen und für jedes Feld in dem Maskenregister gibt ein Wert an, dass das entsprechende Element nicht aus dem Speicher geladen worden ist, und ein zweiter Wert gibt an, dass das entsprechende Datenelement nicht geladen werden muss oder bereits aus dem Speicher geladen worden ist. In einer Ausführungsform ist das Maskenregister ein architektonisch sichtbares Register. In einer weiteren Ausführungsform kann das Maskenregister implizit sein, beispielsweise wobei alle Felder initial angeben, dass das entsprechende Element nicht aus dem Speicher geladen worden ist. In einem Verarbeitungsblock 1420 wird die Schrittlänge zu einem Versatz zum Zugreifen auf Speicher hinzugefügt. In einem Verarbeitungsblock 1430 werden die Felder des Maskenregisters mit dem ersten Wert verglichen, der angibt, dass das entsprechende Element nicht aus dem Speicher geladen worden ist. Wenn es nicht dem ersten Wert gleicht, fährt die Verarbeitung mit Verarbeitungsblock 1460 fort, wobei die Ladeoperation reiteriert bis sie beendet ist. Sonst wird in einem Verarbeitungsblock 1440 das entsprechende Datenelement aus dem Speicher geladen und in ein Vektorregister mit einer Vielzahl von Datenfeldern gespeichert, wobei in einem Abschnitt davon die geladenen Datenelemente zu speichern sind. Beim erfolgreichen Abschluss des Verarbeitungsblocks 1440 wird das entsprechende Feld in dem Maskenregister in einem Verarbeitungsblock 1450 auf den zweiten Wert geändert, der angibt, dass das entsprechende Datenelement bereits aus dem Speicher geladen worden ist.
  • Es wird verständlich, dass in einer alternativen Ausführungsform die Duplikatmaske des Verarbeitungsblocks 1409 durch Setzen eines Felds in einem Duplikatmaskenregister auf den ersten Wert zur Verwendung durch die zweite Operation aufgebaut sein kann, wenn das entsprechende Feld in dem Maskenregister in dem Verarbeitungsblock 1450 auf den zweiten Wert geändert wird. Somit kann der Abschluss der zweiten Operation unter einer partiell duplizierten Maske erlaubt werden und eine Lade-Op mit Schritt-Funktionalität nach einem Speicherfehler oder Fault unter Verwendung der neuen Maske neu gestartet werden, um nur Elemente nachzuverfolgen, die weiterhin die Ausführung der Lade-Op mit Schritt-Funktionalität benötigen.
  • In einem Verarbeitungsblock 1460 wird bestimmt, ob die Ladeoperation beendet ist (d. h. jedes Feld aus der Vielzahl von Maskenfeldern in dem Maskenregister hat den zweiten Wert oder es ist ein Fehler aufgetreten). Falls dem nicht so ist, reiteriert die Verarbeitung beginnend mit Verarbeitungsblock 1410. Sonst fährt die Verarbeitung mit Verarbeitungsblock 1470 fort, in dem die zweite Operation durchgeführt wird. In einer Ausführungsform kann die zweite Operation unter Verwendung der Duplikatmaske aus dem optionalen Verarbeitungsblock 1409 durchgeführt werden. In einer weiteren Ausführungsform kann die zweite Operation ohne eine Verwendung einer Maske durchgeführt werden. In einem Verarbeitungsblock 1480 werden dann die Ergebnisse des SIMD Lade-Op mit Schritt-Befehls in einem Vektorregister gespeichert.
  • 15 stellt ein Flussdiagramm für eine weitere Ausführungsform eines Verfahrens 1501 dar, um Vektor-Lade-Op mit Schritt-Funktionalität bereitzustellen. In einem Verarbeitungsblock 1505 des Verfahrens 1501 wird ein Lade-Op mit Schritt-Befehl decodiert. Die Verarbeitung fährt mit Verarbeitungsblock 1509 fort, in dem optional ein Duplikat von der Maske erzeugt wird, das verwendet werden soll, wenn die zweite Operation durchgeführt wird. Die Verarbeitung fährt dann mit Verarbeitungsblock 1510 fort, in dem ein nächster Wert aus jedem Feld aus einer Vielzahl von Maskenfeldern in einem Maskenregister gelesen wird. Wiederum, während der Prozess 1501 als iterativ dargestellt ist, können viele der Operationen parallel durchgeführt werden, wenn dies möglich ist. In einem Verarbeitungsblock 1520 wird die Schrittlänge zu einem Versatz zum Zugreifen auf Speicher hinzugefügt. In einem Verarbeitungsblock 1530 wird das nächste Feld des Maskenregisters mit dem ersten Wert verglichen, der angibt, dass das entsprechende Element nicht aus dem Speicher gesammelt worden ist. Wenn es dem ersten Wert nicht gleicht, fährt die Verarbeitung mit Verarbeitungsblock 1560 fort, in dem die Ladeoperation reiteriert, bis sie endet. Sonst wird in einem Verarbeitungsblock 1540 das entsprechende Datenelement aus dem Speicher geladen und in ein Vektorzielregister mit einer Vielzahl von Datenfeldern gespeichert, wobei in einen Abschnitt davon die geladenen Datenelemente zu speichern sind. Bei einem erfolgreichen Abschluss des Verarbeitungsblocks 1540 wird das entsprechende Feld in dem Maskenregister in einem Verarbeitungsblock 1550 auf den zweiten Wert geändert, der angibt, dass das entsprechende Datenelement bereits aus dem Speicher gesammelt worden ist.
  • Es wird wiederum verständlich, dass in einer alternativen Ausführungsform die Duplikatmaske aus Verarbeitungsblock 1509 durch Setzen eines Felds in einem Duplikatmaskenregister auf den ersten Wert aufgebaut sein kann, zur Verwendung durch die zweite Operation, wenn das entsprechende Feld in dem Maskenregister in dem Verarbeitungsblock 1550 auf den zweiten Wert geändert wird. Somit kann der Abschluss der zweiten Operation unter einer partiell duplizierten Maske erlaubt werden und ein Sammel-Op-Befehl nach einem Speicherfehler unter Verwendung der neuen Maske neu gestartet werden, um nur Elemente nachzuverfolgen, die weiterhin die Ausführung des Sammel-Operation-Befehls benötigen.
  • In einem Verarbeitungsblock 1560 wird bestimmt, ob die Sammel-Operation beendet ist (d. h. jedes Feld aus der Vielzahl von Maskenfeldern in dem Maskenregister hat den zweiten Wert oder es ist ein Fehler aufgetreten). Wenn dies nicht der Fall ist, reiteriert die Verarbeitung beginnend mit dem Verarbeitungsblock 1510. Sonst fährt die Verarbeitung mit Verarbeitungsblock 1565 fort, in dem die zweite Operation auf Elementen aus dem Zielregister und Elementen aus einem zweiten Operandenregister durchgeführt wird. In einer Ausführungsform kann die zweite Operation unter Verwendung der Duplikatmaske aus dem optionalen Verarbeitungsblock 1509 durchgeführt werden. In einer weiteren Ausführungsform kann die zweite Operation ohne eine Verwendung einer Maske durchgeführt werden. In einem Verarbeitungsblock 1580 werden dann die Ergebnisse des SIMD Sammel-Operation-Befehls in dem Vektorzielregister gespeichert.
  • Es wird verständlich sein, dass Abhängigkeiten zwischen der Sammel-Operation und einer zweiten Operation effizient durch Hardware behandelt werden können, insbesondere in einer Out of Order-Mikroarchitektur, wodurch weitere Compiler-Optimierungen und ein verbesserter Befehlsdurchsatz erlaubt wird.
  • 16 stellt ein Flussdiagramm einer Ausführungsform eines Verfahrens 1601 dar, um Vektor-Speicher-Op mit Schritt-Funktionalität bereitzustellen. In einem Verarbeitungsblock 1610 des Verfahrens 1601 wird die erste Operation auf Elementen aus einem ersten Operandenregister und entsprechenden Elementen aus einem zweiten Operandenregister durchgeführt und Ergebnisse werden in ein temporäres Register gespeichert. In einem Verarbeitungsblock 1620 werden die ersten/zweiten Werte eines Maskenregisters invertiert (oder gekippt) um eine Duplikatmaske zu erzeugen. Die Verarbeitung fährt dann mit Verarbeitungsblock 1630 fort, in dem ein nächster Wert aus einem Feld aus einer Vielzahl von Maskenfeldern in dem Maskenregister gelesen wird. Es wird verständlich, dass, obwohl das Verfahren 1601 als iterativ dargestellt ist, es vorteilhaft sein kann, viele der Operationen parallel durchzuführen, wenn dies möglich ist. Jedes aus der Vielzahl von Maskenfeldern in dem Maskenregister kann einem Vielfachen einer Schrittlänge von einer Startadresse für ein entsprechendes Datenelement in einem Speicher entsprechen und für jedes Feld in dem Maskenregister gibt ein Wert an, dass das entsprechende Element nicht in dem Speicher gespeichert worden ist, und ein zweiter Wert gibt an, dass das entsprechende Datenelement nicht gespeichert werden muss oder bereits in den Speicher gespeichert worden ist. In einer Ausführungsform ist das Maskenregister ein architektonisch sichtbares Register. In einer weiteren Ausführungsform kann das Maskenregister implizit sein, wobei beispielsweise alle Felder initial angeben, dass das entsprechende Element nicht in den Speicher gespeichert worden ist. In einem Verarbeitungsblock 1640 wird die Schrittlänge zu einem Versatz zum Zugreifen auf Speicher hinzugefügt. In einem Verarbeitungsblock 1650 werden die Felder des Maskenregisters mit dem ersten Wert verglichen, der angibt, dass das entsprechende Element des temporären Registers nicht in den Speicher gespeichert worden ist. Wenn es nicht dem ersten Wert gleicht, fährt die Verarbeitung mit Verarbeitungsblock 1680 fort, in dem die Speicheroperation reitertiert, bis sie beendet ist. Sonst wird in einem Verarbeitungsblock 1660 das entsprechende Datenelement aus dem temporären Register in den Speicher gespeichert. Beim erfolgreichen Abschluss des Verarbeitungsblocks 1660 wird das entsprechende Feld in dem Maskenregister in einem Verarbeitungsblock 1670 auf den zweiten Wert geändert, der angibt, dass das entsprechende Datenelement bereits in den Speicher gespeichert worden ist, und ein entsprechendes Feld in dem Duplikatmaskenregister wird auf den ersten Wert geändert.
  • In einem Verarbeitungsblock 1680 wird bestimmt, ob die Speicheroperation beendet ist (d. h. jedes Feld aus der Vielzahl von Maskenfeldern in dem Maskenregister hat den zweiten Wert oder es ist ein Fehler aufgetreten). Wenn dies nicht der Fall ist, reiteriert die Verarbeitung beginnend mit dem Verarbeitungsblock 1630. Sonst fährt die Verarbeitung mit Verarbeitungsblock 1690 fort, in dem die Ergebnisse des SIMD Lade-Op mit Schritt-Befehls aus dem temporären Register in ein Vektorzielregister unter Verwendung der duplizierten Maske gespeichert werden. Somit kann der Abschluss der ersten Operation unter einer partiell duplizierten Maske erlaubt werden und ein Speicher-Op mit Schritt-Befehl nach einem Speicherfehler unter Verwendung der neuen Maske neu gestartet werden, um nur Elemente nachzuverfolgen, die weiterhin die Ausführung des Speicher-Op mit Schritt-Befehls benötigen.
  • 17 stellt ein Flussdiagramm für eine weitere Ausführungsform eines Verfahrens 1701 dar, um Vektor-Speicher-Op mit Schritt-Funktionalität bereitzustellen. In einem Verarbeitungsblock 1705 des Verfahrens 1701 wird ein Speicher-Op mit Schritt-Befehl decodiert. Die Verarbeitung fährt mit Verarbeitungsblock 1730 fort, in dem ein nächster Wert aus einem Feld aus einer Vielzahl von Maskenfeldern in einem Maskenregister gelesen wird. Es wird verständlich sein, dass obwohl der Prozess 1701 als iterativ dargestellt ist, es vorteilhaft sein kann, viele der Operationen parallel durchzuführen, wenn dies möglich ist.
  • In einer Ausführungsform ist das Maskenregister ein architektonisch sichtbares Register. In einer weiteren Ausführungsform kann das Maskenregister implizit sein, wobei beispielsweise alle Felder initial angeben, dass das entsprechende Element nicht in den Speicher gespeichert worden ist. In einem Verarbeitungsblock 1740 wird die Schrittlänge zu einem Versatz zum Zugreifen auf Speicher hinzugefügt. In einem Verarbeitungsblock 1750 werden die Felder des Maskenregisters mit dem ersten Wert verglichen, der angibt, dass das entsprechende Element nicht in den Speicher gespeichert worden ist. Wenn es nicht dem ersten Wert gleicht, fährt die Verarbeitung mit Verarbeitungsblock 1780 fort, in dem die Speicheroperation reiteriert, bis sie beendet ist. Sonst wird in einem Verarbeitungsblock 1710 die erste Operation auf entsprechenden Elementen aus einem ersten Operanden/Zielregister und entsprechenden Elementen aus einem zweiten Operandenregister durchgeführt. In einem Verarbeitungsblock 1760 wird das entsprechende Ergebnisdatenelement in den Speicher gespeichert. Beim erfolgreichen Abschluss des Verarbeitungsblocks 1760 wird das entsprechende Feld in dem Maskenregister in einem Verarbeitungsblock 1770 auf den zweiten Wert geändert, der angibt, dass das entsprechende Datenelement bereits in den Speicher gespeichert worden ist.
  • In einem Verarbeitungsblock 1780 wird bestimmt, ob die Streu-Operation beendet ist (d. h. jedes Feld aus der Vielzahl von Maskenfeldern in dem Maskenregister hat den zweiten Wert oder es ist ein Fehler aufgetreten). Wenn dies nicht der Fall ist, reitertiert die Verarbeitung beginnend mit dem Verarbeitungsblock 1730. Sonst fährt die Verarbeitung mit Verarbeitungsblock 1790 fort, in dem die Ergebnisse des SIMD Speicher-Op mit Schritt-Befehls in einem Vektorzielregister gespeichert werden.
  • Ausführungsformen der vorliegenden Erfindung haben zum Gegenstand einen Befehl, um Vektor-Lade-Op und/oder Speicher-Op mit Schritt-Funktionalität bereitzustellen, wobei Abhängigkeiten zwischen der Lade- oder Speicher-Operation und einer weiteren Operation durch Hardware effizient behandelt werden können, insbesondere in einer Out Of Order-Mikroarchitektur, wodurch weitere Compileroptimierungen und ein verbesserter Befehlsdurchsatz möglich werden.
  • Ausführungsformen der hier offenbarten Mechanismen können als Hardware, Software, Firmware oder eine Kombination solcher Implementierungsansätze implementiert sein. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert sein, der auf programmierbaren Systemen ausführt, die mindestens einen Prozessor, ein Storage-Speichersystem (aufweisend flüchtigen und nicht flüchtigen Speicher und/oder Storage-Speicherelemente), mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung umfassen.
  • Der Programmcode kann auf Eingabebefehle angewandt werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können auf eine oder mehrere Ausgabevorrichtungen in einer bekannten Art und Weise angewandt werden. Für die Zwecke dieser Anmeldung weist ein Verarbeitungssystem ein beliebiges System auf, das einen Prozessor hat, wie z. B. einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit, ASIC) oder einen Mikroprozessor.
  • Der Programmcode kann in einer prozeduralen oder objektorientierten Programmiersprache auf hoher Ebene implementiert sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann ebenfalls in Assembler oder in einer Maschinensprache implementiert sein, wenn dies gewünscht ist. In der Tat sind die hier beschriebenen Mechanismen nicht in ihrem Umfang auf irgendeine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
  • Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Befehle implementiert sein, die auf einem maschinenlesbaren Medium oder Datenträger gespeichert sind, der verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen werden, die Maschinen dazu veranlassen, Logik zu fabrizieren, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, bekannt als „IP-Kerne”, können auf einem greifbaren, maschinenlesbaren Medium oder Datenträger gespeichert sein und an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, um in die Fabrikationsmaschinen geladen zu werden, die tatsächlich die Logik oder den Prozessor machen.
  • Solche maschinenlesbaren Speichermedien und Datenträger können, ohne Beschränkung, nicht flüchtige, greifbare Anordnungen von Artikeln aufweisen, die von einer Maschine oder Vorrichtung hergestellt oder geformt sind, aufweisend Storage-Speichermedien oder Datenträger, wie z. B. Festplatten, einen beliebigen anderen Typ einer Platte, aufweisend Floppy-Disketten, optische Platten, Compact Disk Read-Only Memories (CD-ROMs), Compact Disk Rewritables (CD-RWs) und magneto-optische Platten, Halbleitervorrichtungen, wie z. B. Nurlesespeicher (Read-Only Memories, ROMs), Direktzugriffsspeicher (Random Access Memories, RAMs), wie z. B. dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare programmierbare Nurlesespeicher (EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Nurlesespeicher (EEPROMs), magnetische oder optische Karten oder irgendeinen anderen Typ von Medien, die zum Speichern von elektronischen Befehlen geeignet sind.
  • Entsprechend weisen Ausführungsformen der Erfindung ebenfalls nicht flüchtige, greifbare maschinenlesbare Medien oder Datenträger auf, die Befehle enthalten oder Design-Daten enthalten, wie z. B. Hardware Description Language (HDL), die Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale, die hier beschrieben sind, definieren. Auf solche Ausführungsformen kann ebenfalls als Programmprodukte Bezug genommen werden.
  • In einigen Fällen kann ein Befehlskonvertierer verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz zu konvertieren. Der Befehlskonvertierer kann z. B. Übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung aufweisend dynamische Kompilation), Morphen, Emulieren oder anderweitig einen Befehl in einen oder mehrere andere Befehle konvertieren, die von dem Kern verarbeitet werden sollen. Der Befehlskonvertierer kann als Software, Hardware, Firmware oder eine Kombination davon implementiert sein. Der Befehlskonvertierer kann auf einem Prozessor, entfernt von einem Prozessor oder teilweise auf und teilweise entfernt von einem Prozessor angeordnet sein.
  • Somit werden Techniken zum Durchführen eines oder mehrerer Befehle gemäß mindestens einer Ausführungsform offenbart. Während bestimmte beispielhafte Ausführungsformen beschrieben worden sind und in den begleitenden Zeichnungen gezeigt worden sind, sollte verständlich sein, dass solche Ausführungsformen rein darstellend und für die breite Erfindung nicht beschränkend sind und dass diese Erfindung nicht auf die spezifischen Konstruktionen und Anordnungen, die gezeigt und beschrieben sind, beschränkt werden soll, da verschiedene andere Modifikationen dem Fachmann beim Studium dieser Offenbarung einfallen werden. In einem Bereich der Technologie, wie diesem, in dem das Wachstum schnell ist und weiterer Fortschritt nicht leicht vorhersehbar sind, können die offenbarten Ausführungsformen durch Fortschritte der Basistechnologie in Anordnung und Detail ohne Weiteres modifizierbar sein, ohne von den Grundsätzen der vorliegenden Offenbarung oder dem Umfang der begleitenden Ansprüche abzuweichen.

Claims (30)

  1. Prozessor, der Folgendes umfasst: ein erstes Register, das eine erste Vielzahl von Datenfeldern umfasst, wobei jedes aus der ersten Vielzahl von Datenfeldern in dem ersten Register einem Vielfachen einer Schrittlänge von einer Startadresse für ein entsprechendes Datenelement in einem Speicher entspricht, wobei für jedes Datenfeld in dem ersten Register ein erster Wert angibt, dass das entsprechende Element noch nicht aus dem Speicher geladen worden ist, und ein zweiter Wert angibt, dass das entsprechende Datenelement nicht geladen werden muss oder bereits aus dem Speicher geladen worden ist; eine Decodierstufe zum Decodieren eines ersten Befehls, der das erste Register und einen Satz von Ladeoperationen spezifiziert, die einem oder mehreren aus der ersten Vielzahl von Datenfeldern entsprechen, und eine zweite Einzelbefehl-Mehrfachdaten(Single Instruction Multiple Data, SIMD)-Operation spezifiziert; und eine oder mehrere Ausführungseinheiten, die als Reaktion auf den decodierten ersten Befehl eingerichtet sind, um: die Werte von jedem der Datenfelder in dem ersten Register zu lesen; für jedes Datenfeld aus der Vielzahl von Datenfeldern in dem ersten Register mit dem ersten Wert das entsprechende Datenelement aus dem Speicher zu laden und das entsprechende Datenelement in ein zweites Register zu speichern, wobei das zweite Register eine zweite Vielzahl von Datenfeldern aufweist, wobei in einen Abschnitt davon die geladenen Datenelemente zu speichern sind, und um den Wert des entsprechenden Datenfeldes in dem ersten Register von dem ersten Wert auf den zweiten Wert zu ändern; und die zweite SIMD-Operation unter Verwendung der Datenelemente durchzuführen, die in dem Abschnitt der zweiten Vielzahl von Datenfeldern gespeichert sind, um entsprechende Ergebnisdatenelemente zu generieren.
  2. Prozessor nach Anspruch 1, wobei der erste Wert eine Eins ist.
  3. Prozessor nach Anspruch 1, wobei der zweite Wert eine Null ist.
  4. Prozessor nach Anspruch 1, wobei die eine oder mehreren Ausführungseinheiten als Reaktion auf den decodierten ersten Befehl eingerichtet sind, die Vielzahl von Datenfeldern in dem ersten Register zu duplizieren.
  5. Prozessor nach Anspruch 4, wobei die eine oder mehreren Ausführungseinheiten als Reaktion auf den decodierten ersten Befehl eingerichtet sind, jedes aus der Vielzahl von Datenfeldern mit dem ersten Wert in dem ersten Register zu duplizieren, wenn der Wert dieses Datenfelds in dem ersten Register von dem ersten Wert auf den zweiten Wert geändert wird.
  6. Prozessor nach Anspruch 5, wobei die eine oder mehreren Ausführungseinheiten eingerichtet sind, die Vielzahl von duplizierten Datenfelder aus dem ersten Register zu verwenden, um die zweite SIMD-Operation durchzuführen, entweder bei einem Fehler (Fault) oder nachdem jedes Datenfeld aus der ersten Vielzahl von Datenfeldern in dem ersten Register den zweiten Wert hat.
  7. Prozessor nach Anspruch 1, wobei die zweite Operation unär ist.
  8. Prozessor nach Anspruch 1, wobei die zweite Operation binär ist.
  9. Prozessor nach Anspruch 1, wobei die Datenelemente, die in das zweite Register gespeichert werden, 32 Bit Datenelemente sind.
  10. Prozessor nach Anspruch 1, wobei die Datenelemente, die in das zweite Register gespeichert werden, 64 Bit Datenelemente sind.
  11. Prozessor nach Anspruch 1, wobei das zweite Register ein 512 Bit Vektorregister ist.
  12. Maschinenlesbares Medium zum Aufnehmen von funktional deskriptivem Material, das einen ersten ausführbaren Befehl aufweist, der, wenn er von einer Maschine ausgeführt wird, die Maschine dazu veranlasst: Werte von jedem Datenfeld aus einer ersten Vielzahl von Datenfeldern in einem ersten Register zu lesen, wobei jedes aus der ersten Vielzahl von Datenfeldern in dem ersten Register einem Vielfachen einer Schrittlänge von einer Startadresse für ein entsprechendes Datenelement in einem Speicher entspricht und wobei für jedes Datenfeld in dem ersten Register ein erster Wert angibt, dass das entsprechende Element nicht aus dem Speicher geladen worden ist, und ein zweiter Wert angibt, dass das entsprechende Datenelement nicht geladen werden muss oder bereits aus dem Speicher geladen worden ist; für jedes Datenfeld aus der Vielzahl von Datenfeldern in dem ersten Register mit dem ersten Wert das entsprechende Datenelement aus dem Speicher zu laden und das entsprechende Datenelement in ein zweites Register zu speichern, wobei das zweite Register eine zweite Vielzahl von Datenfeldern aufweist, wobei in einen Abschnitt davon die geladenen Datenelemente zu speichern sind, und den Wert des entsprechenden Datenfelds in dem ersten Register von dem ersten Wert auf den zweiten Wert zu ändern; und dann eine zweite Einzelbefehl-Mehrfachdaten(SIMD)-Operation unter Verwendung der Datenelemente durchzuführen, die in dem Abschnitt der zweiten Vielzahl von Datenfeldern gespeichert sind, um entsprechende Ergebnisdatenelemente zu generieren.
  13. Maschinenlesbares Medium nach Anspruch 12, wobei der erste ausführbare Befehl, wenn er von der Maschine ausgeführt wird, ferner die Maschine dazu veranlasst: die Vielzahl von Datenfeldern in dem ersten Register zu duplizieren.
  14. Maschinenlesbares Medium nach Anspruch 12, wobei der erste ausführbare Befehl, wenn er von der Maschine ausgeführt wird, die Maschine ferner dazu veranlasst: jedes aus der Vielzahl von Datenfeldern mit dem ersten Wert in dem ersten Register zu duplizieren, wenn der Wert dieses Datenfelds in dem ersten Register von dem ersten Wert auf den zweiten Wert geändert wird.
  15. Maschinenlesbares Medium nach Anspruch 14, wobei der erste ausführbare Befehl, wenn er von der Maschine ausgeführt wird, ferner die Maschine dazu veranlasst: die Vielzahl von duplizierten Datenfeldern aus dem ersten Register zu verwenden, um die zweite SIMD-Operation durchzuführen, entweder bei einem Fehler oder nachdem jedes Datenfeld aus der ersten Vielzahl von Datenfeldern in dem ersten Register den zweiten Wert hat.
  16. Maschinenlesbares Medium nach Anspruch 12, wobei die zweite Operation unär ist.
  17. Maschinenlesbares Medium nach Anspruch 12, wobei die zweite Operation binär ist.
  18. Maschinenlesbares Medium nach Anspruch 12, wobei die Datenelemente, die in das zweite Register gespeichert werden, 32 Bit Datenelemente sind.
  19. Maschinenlesbares Medium nach Anspruch 12, wobei die Datenelemente, die in das zweite Register gespeichert werden, 64 Bit Datenelemente sind.
  20. Maschinenlesbares Medium nach Anspruch 12, wobei das zweite Register ein 512 Bit Vektorregister ist.
  21. Prozessor, der Folgendes umfasst: eine Decodierstufe, um einen ersten Einzelbefehl-Mehrfachdaten(SIMD)-Befehl zu decodieren, spezifizierend: einen Satz von Ladeoperationen und eine zweite SIMD-Operation, ein Zielregister, ein Operandenregister, eine Speicheradresse und eine Schrittlänge; und eine oder mehrere Ausführungseinheiten, die als Reaktion auf den decodierten ersten SIMD-Befehl eingerichtet sind: Werte von jedem Datenfeld aus einer ersten Vielzahl von Datenfeldern in einem Maskenregister zu lesen, wobei jedes aus der ersten Vielzahl von Datenfeldern in dem Maskenregister, wobei jedes aus der ersten Vielzahl von Datenfeldern in dem ersten Register einem Vielfachen der Schrittlänge von der Speicheradresse für ein entsprechendes Datenelement in einem Speicher entspricht und wobei für jedes Datenfeld in dem Maskenregister ein erster Wert angibt, dass das entsprechende Element nicht aus dem Speicher geladen worden ist, und ein zweiter Wert angibt, dass das entsprechende Datenelement nicht geladen werden muss oder bereits aus dem Speicher geladen worden ist; für jedes Datenfeld aus der Vielzahl von Datenfeldern in dem Maskenregister mit dem ersten Wert das entsprechende Datenelement aus dem Speicher in ein entsprechendes Datenfeld in dem Zielregister zu laden und den Wert des Datenfelds in dem Maskenregister von dem ersten Wert auf den zweiten Wert zu ändern; und die zweite SIMD-Operation unter Verwendung der Datenelemente, die in das Zielregister geladen sind, und entsprechender Datenelemente in dem Operandenregister durchzuführen, um entsprechende Ergebnisdatenelemente zu generieren.
  22. Prozessor nach Anspruch 21, wobei die eine oder mehreren Ausführungseinheiten als Reaktion auf den decodierten ersten SIMD-Befehl eingerichtet sind, die Vielzahl von Datenfeldern in dem Maskenregister zu duplizieren.
  23. Prozessor nach Anspruch 22, wobei die eine oder mehreren Ausführungseinheiten als Reaktion auf den decodierten ersten SIMD-Befehl eingerichtet sind, jedes aus der Vielzahl von Datenfeldern mit dem ersten Wert in dem Maskenregister zu duplizieren, wenn der Wert dieses Datenfels in dem Maskenregister von dem ersten Wert auf den zweiten Wert geändert wird.
  24. Prozessor nach Anspruch 23, wobei die eine oder mehreren Ausführungseinheiten eingerichtet sind, die Vielzahl von duplizierten Datenfeldern aus dem Maskenregister zu verwenden, um die zweite SIMD-Operation durchzuführen, entweder bei einem Fehler oder nachdem jedes Datenfeld aus der ersten Vielzahl von Datenfeldern in dem Maskenregister den zweiten Wert hat.
  25. Prozessor nach Anspruch 21, wobei die Datenelemente, die in das zweite Register gespeichert werden, 32 Bit Datenelemente sind.
  26. Prozessor nach Anspruch 21, wobei die Datenelemente, die in das zweite Register gespeichert werden, 64 Bit Datenelemente sind.
  27. Prozessor nach Anspruch 21, wobei das zweite Register ein 512 Bit Vektorregister ist.
  28. Verarbeitungssystem, das Folgendes umfasst: einen Speicher; und eine Vielzahl von Prozessoren, von denen jeder Folgendes umfasst: eine Decodierstufe, die eingerichtet ist, einen ersten Einzelbefehl-Mehrfachdaten(SIMD)-Befehl zu decodieren, spezifizierend: einen Satz von Ladeoperationen und eine zweite SIMD-Operation, ein Zielregister, ein Operandenregister, eine Speicheradresse und eine Schrittlänge; und eine oder mehrere Ausführungseinheiten, die als Reaktion auf den decodierten ersten SIMD-Befehl eingerichtet sind: Werte von jedem Datenfeld aus einer ersten Vielzahl von Datenfeldern in einem Maskenregister zu lesen, wobei jedes aus der ersten Vielzahl von Datenfeldern in dem Maskenregister, wobei jedes aus der ersten Vielzahl von Datenfelder in dem ersten Register einem Vielfachen der Schrittlänge von der Speicheradresse für ein entsprechendes Datenelement in einem Speicher entspricht und wobei für jedes Datenfeld in dem Maskenregister ein erster Wert angibt, dass das entsprechende Element nicht aus dem Speicher geladen worden ist, und ein zweiter Wert angibt, dass das entsprechende Datenelement nicht geladen werden muss oder bereits aus dem Speicher geladen worden ist; für jedes Datenfeld aus der Vielzahl von Datenfeldern in dem Maskenregister mit dem ersten Wert das entsprechende Datenelement aus dem Speicher in ein entsprechendes Datenfeld in dem Zielregister zu laden und den Wert des Datenfelds in dem Maskenregister von dem ersten Wert auf den zweiten Wert zu ändern; und die zweite SIMD-Operation unter Verwendung der Datenelemente, die in das Zielregister geladen sind, und entsprechender Datenelemente in dem Operandenregister durchzuführen, um entsprechende Ergebnisdatenelemente zu generieren.
  29. Verarbeitungssystem nach Anspruch 28, wobei die eine oder mehreren Ausführungseinheiten als Reaktion auf den ersten SIMD-Befehl ferner eingerichtet sind: jedes aus der Vielzahl von Datenfeldern mit dem ersten Wert in dem Maskenregister zu duplizieren, wenn der Wert dieses Datenfelds in dem Maskenregister von dem ersten Wert auf den zweiten Wert geändert wird.
  30. Verarbeitungssystem nach Anspruch 29, wobei die eine oder mehreren Ausführungseinheiten als Reaktion auf den ersten SIMD-Befehl ferner eingerichtet sind: die Vielzahl von duplizierten Datenfeldern aus dem Maskenregister zu verwenden, um die zweite SIMD-Operation durchzuführen, entweder bei einem Fehler oder nachdem jedes Datenfeld aus der ersten Vielzahl von Datenfeldern in dem Maskenregister den zweiten Wert hat.
DE112011105666.4T 2011-09-26 2011-09-26 Befehl und Logik zum Bereitstellen von Vektor-Lade-OP/Speicher-OP mit Schritt-Funktionalität Ceased DE112011105666T5 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2011/053331 WO2013048369A1 (en) 2011-09-26 2011-09-26 Instruction and logic to provide vector load-op/store-op with stride functionality

Publications (1)

Publication Number Publication Date
DE112011105666T5 true DE112011105666T5 (de) 2014-07-10

Family

ID=47996117

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112011105666.4T Ceased DE112011105666T5 (de) 2011-09-26 2011-09-26 Befehl und Logik zum Bereitstellen von Vektor-Lade-OP/Speicher-OP mit Schritt-Funktionalität

Country Status (8)

Country Link
US (1) US9804844B2 (de)
JP (1) JP5933011B2 (de)
KR (2) KR101877347B1 (de)
CN (2) CN103827814B (de)
BR (1) BR112014004600A2 (de)
DE (1) DE112011105666T5 (de)
GB (1) GB2508312B (de)
WO (1) WO2013048369A1 (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101877347B1 (ko) 2011-09-26 2018-07-12 인텔 코포레이션 벡터 로드-op/저장-op에 스트라이드 기능을 제공하는 명령어 및 로직
US20170269935A1 (en) * 2011-09-26 2017-09-21 Elmoustapha Ould-Ahmed-Vall Instruction and logic to provide vector loads and stores with strides and masking functionality
DE112011105664T5 (de) * 2011-09-26 2014-08-21 Intel Corporation Instruktion und Logik zum Bereitstellen einer Vektorstreuungs-Op- und -Hol-Op-Funktionalität
US9471308B2 (en) 2013-01-23 2016-10-18 International Business Machines Corporation Vector floating point test data class immediate instruction
US9715385B2 (en) 2013-01-23 2017-07-25 International Business Machines Corporation Vector exception code
US9513906B2 (en) 2013-01-23 2016-12-06 International Business Machines Corporation Vector checksum instruction
US9804840B2 (en) 2013-01-23 2017-10-31 International Business Machines Corporation Vector Galois Field Multiply Sum and Accumulate instruction
US9823924B2 (en) 2013-01-23 2017-11-21 International Business Machines Corporation Vector element rotate and insert under mask instruction
US9778932B2 (en) 2013-01-23 2017-10-03 International Business Machines Corporation Vector generate mask instruction
CN103414854B (zh) * 2013-08-13 2017-04-19 三星半导体(中国)研究开发有限公司 具有图像处理功能的片上***及其运行方法
KR102152735B1 (ko) * 2013-09-27 2020-09-21 삼성전자주식회사 그래픽 처리 장치 및 이의 동작 방법
KR101941874B1 (ko) * 2013-12-23 2019-01-25 인텔 코포레이션 클러스터 와이드-실행 머신에서 메모리 액세스를 위한 명령어 및 로직
US9600442B2 (en) * 2014-07-18 2017-03-21 Intel Corporation No-locality hint vector memory access processors, methods, systems, and instructions
US9467279B2 (en) * 2014-09-26 2016-10-11 Intel Corporation Instructions and logic to provide SIMD SM4 cryptographic block cipher functionality
US10528345B2 (en) * 2015-03-27 2020-01-07 Intel Corporation Instructions and logic to provide atomic range modification operations
US20170177352A1 (en) * 2015-12-18 2017-06-22 Intel Corporation Instructions and Logic for Lane-Based Strided Store Operations
US10019262B2 (en) * 2015-12-22 2018-07-10 Intel Corporation Vector store/load instructions for array of structures
US9996319B2 (en) * 2015-12-23 2018-06-12 Intel Corporation Floating point (FP) add low instructions functional unit
US10248488B2 (en) * 2015-12-29 2019-04-02 Intel Corporation Fault tolerance and detection by replication of input data and evaluating a packed data execution result
GB2546510B (en) 2016-01-20 2018-09-26 Advanced Risc Mach Ltd Vector atomic memory update instruction
GB2548601B (en) * 2016-03-23 2019-02-13 Advanced Risc Mach Ltd Processing vector instructions
US20180088946A1 (en) * 2016-09-27 2018-03-29 Intel Corporation Apparatuses, methods, and systems for mixing vector operations
US20180173527A1 (en) * 2016-12-15 2018-06-21 Optimum Semiconductor Technologies, Inc. Floating point instruction format with embedded rounding rule
WO2018174926A1 (en) 2017-03-20 2018-09-27 Intel Corporation Systems, methods, and apparatuses for tile transpose
US11275588B2 (en) 2017-07-01 2022-03-15 Intel Corporation Context save with variable save state size
US11829754B2 (en) 2018-12-07 2023-11-28 Nec Corporation Compile device, compile method, and non-transitory computer readable medium for increasing a speed of a program
GB2584268B (en) * 2018-12-31 2021-06-30 Graphcore Ltd Load-Store Instruction
GB2580664B (en) * 2019-01-22 2021-01-13 Graphcore Ltd Double load instruction
US11163575B2 (en) * 2019-04-03 2021-11-02 Microsoft Technology Licensing, Llc Widening memory access to an aligned address for unaligned memory operations
CN110908716B (zh) * 2019-11-14 2022-02-08 中国人民解放军国防科技大学 一种向量聚合装载指令的实现方法
US11573795B1 (en) * 2021-08-02 2023-02-07 Nvidia Corporation Using a vector processor to configure a direct memory access system for feature tracking operations in a system on a chip

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0731669B2 (ja) * 1986-04-04 1995-04-10 株式会社日立製作所 ベクトル・プロセツサ
JPH036663A (ja) * 1989-06-02 1991-01-14 Mitsubishi Electric Corp ベクトルデータ処理方式
JP2868133B2 (ja) * 1990-06-20 1999-03-10 富士通株式会社 アクセスマスク制御方式
JP2665111B2 (ja) * 1992-06-18 1997-10-22 日本電気株式会社 ベクトル処理装置
JP3006663B2 (ja) 1995-01-27 2000-02-07 ブラザー工業株式会社 印面作成装置
JP3335808B2 (ja) * 1995-08-15 2002-10-21 エヌイーシーコンピュータテクノ株式会社 ベクトル処理装置
US5838984A (en) 1996-08-19 1998-11-17 Samsung Electronics Co., Ltd. Single-instruction-multiple-data processing using multiple banks of vector registers
US6625721B1 (en) * 1999-07-26 2003-09-23 Intel Corporation Registers for 2-D matrix processing
US20040006667A1 (en) 2002-06-21 2004-01-08 Bik Aart J.C. Apparatus and method for implementing adjacent, non-unit stride memory access patterns utilizing SIMD instructions
US6920546B2 (en) * 2002-08-13 2005-07-19 Intel Corporation Fusion of processor micro-operations
US7437521B1 (en) * 2003-08-18 2008-10-14 Cray Inc. Multistream processing memory-and barrier-synchronization method and apparatus
US7275148B2 (en) 2003-09-08 2007-09-25 Freescale Semiconductor, Inc. Data processing system using multiple addressing modes for SIMD operations and method thereof
GB2409064B (en) * 2003-12-09 2006-09-13 Advanced Risc Mach Ltd A data processing apparatus and method for performing in parallel a data processing operation on data elements
TW200739363A (en) * 2006-04-04 2007-10-16 Nat Univ Chung Cheng Flexible load and storage device for multimedia applications
US20080071851A1 (en) * 2006-09-20 2008-03-20 Ronen Zohar Instruction and logic for performing a dot-product operation
US9529592B2 (en) * 2007-12-27 2016-12-27 Intel Corporation Vector mask memory access instructions to perform individual and sequential memory access operations if an exception occurs during a full width memory access operation
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
US9513905B2 (en) * 2008-03-28 2016-12-06 Intel Corporation Vector instructions to enable efficient synchronization and parallel reduction operations
US20100199067A1 (en) 2009-02-02 2010-08-05 International Business Machines Corporation Split Vector Loads and Stores with Stride Separated Words
US20120254591A1 (en) 2011-04-01 2012-10-04 Hughes Christopher J Systems, apparatuses, and methods for stride pattern gathering of data elements and stride pattern scattering of data elements
KR101877347B1 (ko) 2011-09-26 2018-07-12 인텔 코포레이션 벡터 로드-op/저장-op에 스트라이드 기능을 제공하는 명령어 및 로직

Also Published As

Publication number Publication date
GB2508312A (en) 2014-05-28
KR101572770B1 (ko) 2015-11-27
KR20140057363A (ko) 2014-05-12
WO2013048369A1 (en) 2013-04-04
WO2013048369A9 (en) 2013-10-03
CN103827814A (zh) 2014-05-28
BR112014004600A2 (pt) 2017-06-13
GB201402148D0 (en) 2014-03-26
GB2508312B (en) 2020-04-22
KR20150137129A (ko) 2015-12-08
CN103827814B (zh) 2017-04-19
US9804844B2 (en) 2017-10-31
US20140195778A1 (en) 2014-07-10
CN106951214B (zh) 2019-07-19
JP5933011B2 (ja) 2016-06-08
JP2014526758A (ja) 2014-10-06
CN106951214A (zh) 2017-07-14
KR101877347B1 (ko) 2018-07-12

Similar Documents

Publication Publication Date Title
DE112011105666T5 (de) Befehl und Logik zum Bereitstellen von Vektor-Lade-OP/Speicher-OP mit Schritt-Funktionalität
DE112011105664T5 (de) Instruktion und Logik zum Bereitstellen einer Vektorstreuungs-Op- und -Hol-Op-Funktionalität
DE112011105665T5 (de) Befehl und Logik zum Liefern von Vektorladen und -speichern mit Schritt- und Maskierfunktionalität
DE102013021221A1 (de) Befehle und Logik zur Vektorisierung von bedingten Schleifen
DE102013018238A1 (de) Anweisung und Logik zum Bereitstellen einer Vektorkompressions- und Rotationsfunktionalität
DE102014003795A1 (de) Verfahren und Vorrichtungen für Fusionsbefehle zur Bereitstellung der OR-Test- und AND-Test-Funktionalität auf mehreren Testquellen
DE102015006863A1 (de) Befehle und Logik zum Unterbrechen und Wiederaufnehmen von Paging in Secure Enclaves
US10037205B2 (en) Instruction and logic to provide vector blend and permute functionality
DE102014003563A1 (de) Fusionierbare befehle und logik zum versehen mit or-test- und and-test-funktionalität unter benutzen von mehrfachtestquellen
DE112013005416T5 (de) Verfahren, Vorrichtungen, Befehle und Logik zum Bereitstellen von Vektoradressenkonflikt-Detektionsfunktionalität
DE102014004563A1 (de) Befehle und Logik zur Bereitstellung verbesserter Paging-Fähigkeiten für Secure Enclave-Seitencaches
CN107430508B (zh) 用于提供原子范围操作的指令和逻辑
DE202016009016U1 (de) Befehle und Logik für wiederkehrende benachbarte Sammlungen
DE102018006757A1 (de) Festkomma-zu-gleitkomma-umwandlung
DE112013004867T5 (de) Befehl und Logik zum Bereitstellen von Push-Puffer-Kopier- und Speicher-Funktionalität
DE102018005105A1 (de) Befehle für entfernte atomare operationen
DE112017004911T5 (de) Anweisung und Logik für die Erkennung eines numerischen Ansammlungsfehlers
DE112014006508T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen für Fliesskommaaddition mit drei Quellenoperanden
DE102014003661A1 (de) Prozessoren, Verfahren, Systeme und Befehle zur Konsolidierung unmaskierter Elemente von Operationsmasken
DE112012007058T5 (de) Vektormaskengesteuertes Clock-Gating für Leistungseffizenz eines Prozessors
DE112016004960T5 (de) Befehl und logik, um informationen im voraus aus einem beständigen speicher zu holen
DE102014003706A1 (de) BEREICHSBEGRENZTE VEKTORSPEICHERZUGRIFFSINSTRUKTIONEN, PROZESSOREN, VERFAHREN und SYSTEME
DE102018001229A1 (de) Beschleunigerschaltung mit variabler Wortlänge für ein neuronales Netzwerk
DE102014004564A1 (de) Prozessoren, verfahren und systeme zum implementieren von teilregisterzugriffen mit maskierten gesamtregisterzugriffen
DE112013007702T5 (de) Befehl und Logik für den Speicherzugriff in einer geclusterten Maschine mit breiter Ausführung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final