DE102018129341A1

DE102018129341A1 - Verfahren und Einrichtung für Mehrfachlade- und Mehrfachspeicher-Vektorbefehle

Info

Publication number: DE102018129341A1
Application number: DE102018129341.0A
Authority: DE
Inventors: Lawrence Meadows; Alejandro Duran; Simon Pennycook; Jason Sewall
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-12-29
Filing date: 2018-11-21
Publication date: 2019-07-04
Also published as: US20190205137A1; CN109992240A

Abstract

Einrichtung und Verfahren zum Laden und Speichern mehrerer Sätze von gepackten Datenelementen. Beispielsweise umfasst eine Ausführungsform eines Prozessors: einen Decodierer zum Decodieren eines Mehrfachladebefehls zum Erzeugen eines decodierten Mehrfachladebefehls, der mehrere Operationen umfasst, wobei der Mehrfachladebefehl einen Opcode, Quelloperanden und wenigstens einen Zieloperanden aufweist; ein erstes Quellregister zum Speichern von N gepackten Indexwerten; ein zweites Quellregister zum Speichern eines Basisadresswertes; eine Ausführungsschaltung zum Ausführen der Operationen des decodierten Mehrfachladebefehls, wobei die Ausführungsschaltung umfasst: eine Schaltung für parallele Adresserzeugung, um die Basisadresse aus dem zweiten Quellregister mit jedem der N gepackten Indexwerte zu kombinieren, um N Systemspeicheradressen zu erzeugen; eine Datenladeschaltung, um zu bewirken, dass N Sätze von Datenelementen von den N Systemspeicheradressen abgerufen werden, wobei die Datenladeschaltung die N Sätze von Datenelementen in N Vektorzielregistern speichert, die durch den wenigstens einen Zieloperanden identifiziert sind.

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die Ausführungsformen der Erfindung betreffen allgemein das Gebiet von Computerprozessoren. Insbesondere betreffen die Ausführungsformen eine Einrichtung und ein Verfahren für Mehrfachlade- und Mehrfachspeicher-Vektorbefehle.
Beschreibung des bisherigen Standes der Technik
Ein Befehlssatz oder eine Befehlssatzarchitektur (Instruction Set Architecture, ISA) ist der Teil der Computerarchitektur im Zusammenhang mit dem Programmieren, einschließlich der nativen Datentypen, Befehle, Registerarchitektur, Adressierungsmodi, Speicherarchitektur, Unterbrechungs- und Ausnahmebehandlung und externen Eingabe und Ausgabe (E/A). Es sei darauf hingewiesen, dass sich der Begriff „Befehl“ hierin allgemein auf Makrobefehle bezieht, d. h. Befehle, die dem Prozessor zur Ausführung bereitgestellt werden, im Gegensatz zu Mikrobefehlen oder Micro-ops, d. h. dem Ergebnis des Decodierers eines Prozessors, der Makrobefehle decodiert. Die Mikrobefehle oder Micro-ops können dafür ausgelegt sein, eine Ausführungseinheit auf dem Prozessor anzuweisen, Operationen durchzuführen, um die Logik in Verbindung mit dem Makrobefehl zu implementieren.
Die ISA unterscheidet sich von der Mikroarchitektur, die der Satz von Prozessordesigntechniken ist, der zum Implementieren des Befehlssatzes verwendet wird. Prozessoren mit unterschiedlichen Mikroarchitekturen können einen gemeinsamen Befehlssatz teilen. So implementieren beispielsweise Intel® Pentium 4-Prozessoren, Intel® Core™-Prozessoren und Prozessoren von Advanced Micro Devices, Inc. aus Sunnyvale (CA) nahezu identische Versionen des x86-Befehlssatzes (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt worden sind), weisen aber unterschiedliche interne Aufbauten auf. Beispielsweise kann dieselbe Registerarchitektur der ISA in unterschiedlichen Mikroarchitekturen unter Verwendung bekannter Verfahren auf verschiedene Arten implementiert sein; hierzu zählen dedizierte physische Register, ein oder mehrere unter Verwendung eines Registerumbenennungsmechanismus dynamisch zugewiesene physische Register (z. B. durch die Verwendung einer Register-Alias-Tabelle (RAT), eines Neuordnungspuffers (Reorder Buffer, ROB) und einer Rückordnungsregisterdatei). Sofern nicht anders angegeben, beziehen sich die hier verwendeten Formulierungen Registerarchitektur, Registerdatei und Register auf das, was für die Software/den Programmierer sichtbar ist und die Art und Weise, in der Befehle Register spezifizieren. Wo eine Unterscheidung erforderlich ist, wird der Begriff „logisch“, „Architektur-“ oder „für Software sichtbar“ verwendet, um Register/Dateien in der Registerarchitektur anzuzeigen, während verschiedene Adjektive verwendet werden, um Register in einer gegebenen Mikroarchitektur (z. B. physische Register, Neuordnungspuffer, Rückordnungsregister, Registerpool) zu bezeichnen.
Multiply-Accumulate (Multiplizieren-Kumulieren) ist eine gebräuchliche Digitalsignalverarbeitungsoperation, die das Produkt von zwei Zahlen berechnet und dieses Produkt zu einem akkumulierten Wert addiert. Vorhandene Mikroarchitekturen für einen Befehl, mehrere Daten (Single Instruction, Multiple Data, SIMD) implementieren Multiply-Accumulate-Operationen durch das Ausführen einer Folge von Befehlen. Zum Beispiel kann eine Multiplikation-Kumulation (Multiply-Accumulate) mit einem Multiply-Befehl, gefolgt von einer 4-Wege-Addition und dann einer Akkumulation mit den Ziel-Vierfachwort-Daten zum Erzeugen von zwei gesättigten 64-Bit-Ergebnissen durchgeführt werden.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung ergibt sich anhand der nachstehenden ausführlichen Beschreibung im Zusammenhang mit den folgenden Zeichnungen, in denen gilt:

1A und 1B sind Blockschaltbilder, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen;
2A-C sind Blockschaltbilder, die ein beispielhaftes VEX-Befehlsformat gemäß Ausführungsformen der Erfindung veranschaulichen;
3 ist ein Blockschaltbild einer Registerarchitektur gemäß einer Ausführungsform der Erfindung; und
4A ist ein Blockschaltbild, das sowohl eine beispielhafte In-order-Pipeline für Abrufen, Decodieren, Rückordnen als auch eine beispielhafte Pipeline für Registerumbenennung, Out-of-order-Ausgabe/-Ausführung gemäß Ausführungsformen der Erfindung veranschaulicht;
4B ist ein Blockschaltbild, das sowohl eine beispielhafte Ausführungsform eines In-order-Kerns für Abrufen, Decodieren, Rückordnen als auch eines beispielhaften Architekturkerns für Registerumbenennung, Out-of-order-Ausgabe/-Ausführung zur Aufnahme in einen Prozessor gemäß Ausführungsformen der Erfindung veranschaulicht;
5A ist ein Blockschaltbild eines Einzelprozessorkerns zusammen mit dessen Verbindung zu einem On-Die-Verbindungsnetz;
5B veranschaulicht eine erweiterte Ansicht eines Teils des Prozessorkerns in 5A gemäß Ausführungsformen der Erfindung;
6 ist ein Blockschaltbild eines Einzelkernprozessors und eines Mehrkernprozessors mit integrierter Speichersteuerung und integrierter Grafik gemäß Ausführungsformen der Erfindung;
7 veranschaulicht ein Blockschaltbild eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung;
8 veranschaulicht ein Blockschaltbild eines zweiten Systems gemäß einer Ausführungsform der vorliegenden Erfindung;
9 veranschaulicht ein Blockschaltbild eines dritten Systems gemäß einer Ausführungsform der vorliegenden Erfindung;
10 veranschaulicht ein Blockschaltbild eines Ein-Chip-Systems (System-on-a-Chip, SoC) gemäß einer Ausführungsform der vorliegenden Erfindung;
11 veranschaulicht ein Blockschaltbild, das die Verwendung eines Softwarebefehlskonverters zum Konvertieren von binären Befehlen in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt;
12 veranschaulicht eine Prozessorarchitektur, auf der Ausführungsformen der Erfindung implementiert werden können;
13 veranschaulicht eine Ausführungsform eines Mehrfachladebefehls;
14 veranschaulicht eine Ausführungsform eines Mehrfachspeicherbefehls;
15 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung; und
16 veranschaulicht ein Verfahren gemäß einer Ausführungsform der Erfindung.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zu Erläuterungszwecken zahlreiche konkrete Details dargelegt, um ein gründliches Verständnis der weiter unten beschriebenen Ausführungsformen der Erfindung zu schaffen. Es ist jedoch für den Fachmann ersichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Details ausgeführt werden können. In anderen Fällen sind hinlänglich bekannte Strukturen und Vorrichtungen in Blockschaltbildform gezeigt, um zu vermeiden, dass die zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung unklar werden.
Beispielhafte Prozessorarchitekturen, Befehlsformate und Datentypen
Ein Befehlssatz schließt ein oder mehrere Befehlsformate ein. Ein gegebenes Befehlsformat definiert verschiedene Felder (Anzahl Bits, Bitposition), um unter anderem die durchzuführende Operation (Opcode) und den bzw. die Operanden zu spezifizieren, für die diese Operation durchgeführt werden soll. Einige Befehlsformate sind durch die Definition von Befehlsvorlagen (oder Unterformaten) noch weiter aufgegliedert. So können beispielsweise die Befehlsvorlagen eines gegebenen Befehlsformats so definiert sein, dass sie unterschiedliche Untermengen der Felder des Befehlsformats aufweisen (die eingeschlossenen Felder liegen typischerweise in derselben Reihenfolge vor, aber wenigstens einige Felder weisen unterschiedliche Bitpositionen auf, weil weniger Felder eingeschlossen sind) und/oder so definiert sein, dass bei ihnen ein gegebenes Feld anders interpretiert wird. Somit wird jeder Befehl einer ISA unter Verwendung eines gegebenen Befehlsformats (und, falls definiert, in einer gegebenen Vorlage der Befehlsvorlagen dieses Befehlsformats) ausgedrückt und weist Felder für das Spezifizieren der Operation und der Operanden auf. Zum Beispiel weist ein beispielhafter ADD-Befehl einen spezifischen Opcode und ein Befehlsformat auf, das ein Opcode-Feld zum Angeben dieses Opcodes und Operandenfelder zum Auswählen von Operanden (Quelle1/Ziel und Quelle2) aufweist; und ein Vorhandensein dieses ADD-Befehls in einem Befehlsdatenstrom weist spezifische Inhalte in den Operandenfeldern auf, die spezifische Operanden auswählen.
Ausführungsformen der hierin beschriebenen Befehl(e) können in verschiedenen Formaten ausgeführt sein. Außerdem sind Beispielsysteme, Architekturen und Pipelines weiter unten detailliert beschrieben. Ausführungsformen des Befehls bzw. der Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sie sind jedoch nicht auf die genannten Systeme, Architekturen und Pipelines beschränkt.
Generisches vektorfreundliches Befehlsformat
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (z. B. gibt es bestimmte Felder spezifisch für Vektoroperationen). Zwar werden Ausführungsformen beschrieben, in denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, jedoch verwenden alternative Ausführungsformen lediglich Vektoroperationen im vektorfreundlichen Befehlsformat.
1A-1B sind Blockschaltbilder, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen. 1A ist ein Blockschaltbild, das ein generisches vektorfreundliches Befehlsformat und Klasse-A-Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulicht; und 1B ist ein Blockschaltbild, das das generische vektorfreundliche Befehlsformat und Klasse-B-Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulicht. Insbesondere ein generisches vektorfreundliches Befehlsformat 100, für das Klasse-A-Befehlsvorlagen und Klasse B definiert sind, die beide Befehlsvorlagen ohne Speicherzugriff 105 und Befehlsvorlagen mit Speicherzugriff 120 beinhalten. Der Begriff „generisch“ im Zusammenhang des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat nicht an einen spezifischen Befehlssatz gebunden ist.
Während Ausführungsformen der Erfindung beschrieben werden, in denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte) oder 64 Bit (8 Byte) (und somit besteht ein 64-Byte-Vektor entweder aus 16 Doppelwort-Elementen oder alternativ dazu aus 8 Vierfachwort-Elementen); eine 64-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 16 Bit (2 Byte) oder 8 Bit (1 Byte); eine 32-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); und eine 16-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); können alternative Ausführungsformen mehr, weniger und/oder andere Vektoroperandengrößen unterstützen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. Datenelementbreiten von 128 Bit (16 Byte)).
Die Klasse-A-Befehlsvorlagen in 1A beinhalten: 1) in den Befehlsvorlagen ohne Speicherzugriff 105 werden eine Befehlsvorlage für Operationen des Typs vollständige Rundungssteuerung ohne Speicherzugriff 110 und eine Befehlsvorlage für Operationen des Typs Datentransformation ohne Speicherzugriff 115 gezeigt; und 2) in den Befehlsvorlagen mit Speicherzugriff 120 werden eine temporäre Befehlsvorlage mit Speicherzugriff 125 und eine nicht-temporäre Befehlsvorlage mit Speicherzugriff 130 gezeigt. Die Klasse-B-Befehlsvorlagen in 1B schließen ein: 1) in den Befehlsvorlagen ohne Speicherzugriff 105 werden eine Befehlsvorlage für eine Operation des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 112 und eine Befehlsvorlage für eine Operation des Typs vsize ohne Speicherzugriff mit Schreibmaskensteuerung 117 gezeigt; und 2) in den Befehlsvorlagen mit Speicherzugriff 120 wird eine Befehlsvorlage für die Schreibmaskensteuerung mit Speicherzugriff 127 gezeigt.
Das generische vektorfreundliche Befehlsformat 100 beinhaltet die weiter unten aufgeführten folgenden Felder in der in 1A-1B veranschaulichten Reihenfolge ein.
Formatfeld 140 - ein spezifischer Wert (ein Befehlsformat-Kennungswert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und somit Vorkommnisse von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Als solches ist dieses Feld in dem Sinne optional, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht benötigt wird.
Basisoperationsfeld 142 - der Inhalt dieses Feldes unterscheidet verschiedene Basisoperationen.
Registerindexfeld 144 - der Inhalt dieses Feldes spezifiziert, direkt oder durch Adressengenerierung, die Orte der Quell- und Zieloperanden, ganz gleich, ob sie sich in Registern oder im Speicher befinden. Diese weisen eine ausreichende Anzahl von Bits auf, um N Register aus einer PxQ-Registerdatei (z. B. 32x512, 16x128, 32x1024, 64x1024) auszuwählen. Während in einer Ausführungsform N bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (z. B. können bis zu zwei Quellen unterstützt werden, wobei eine dieser Quellen zugleich als Ziel fungiert, können bis zu drei Quellen unterstützt werden, wobei eine dieser Quellen zugleich als Ziel fungiert, können bis zu zwei Quellen und ein Ziel unterstützt werden).
Modifiziererfeld 146 - der Inhalt dieses Feldes unterscheidet Vorkommnisse von Befehlen im generischen Vektorbefehlsformat, die Speicherzugriffe spezifizieren, von solchen, bei denen dies nicht der Fall ist; das heißt, zwischen Befehlsvorlagen ohne Speicherzugriff 105 und Befehlsvorlagen mit Speicherzugriff 120. Speicherzugriffsoperationen lesen und/oder schreiben in der/die Speicherhierarchie (und spezifizieren in einigen Fällen die Quell- und/oder Zieladressen mithilfe von Werten in Registern), während Operationen ohne Speicherzugriff dies nicht tun (z. B. sind Quelle und Ziele Register). Während dieses Feld in einer Ausführungsform auch zwischen drei verschiedenen Arten der Durchführung von Speicheradressberechnungen wählt, können alternative Ausführungsformen mehr, weniger oder andere Arten unterstützen, Speicheradressberechnungen durchzuführen.
Erweiterungsoperationsfeld 150 - der Inhalt dieses Feldes unterscheidet, welche von mehreren unterschiedlichen Operationen zusätzlich zur Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 168, ein Alphafeld 152 und ein Betafeld 154 unterteilt. Das Erweiterungsoperationsfeld 150 ermöglicht es, gängige Gruppen von Operationen in einem einzigen Befehl anstatt in 2, 3 oder 4 Befehlen durchzuführen.
Skalierfeld 160 - der Inhalt dieses Feldes ermöglicht das Skalieren des Indexfeldinhalts für die Speicheradressengenerierung (z. B. für die Adressengenerierung, die 2^skalierung * index + basis verwendet).
Verschiebungsfeld 162A - dessen Inhalt wird als Teil der Speicheradressgenerierung verwendet (z. B. zur Adressgenerierung, die 2^skalierung * index + basis + Verschiebung verwendet).
Verschiebungsfaktorfeld 162B (es sei darauf hingewiesen, dass die Darstellung von Verschiebungsfeld 162A direkt über Verschiebungsfaktorfeld 162B angibt, dass entweder das eine oder das andere verwendet wird) - der Inhalt dieses Feldes wird im Rahmen der Adressengenerierung verwendet; er spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) zu skalieren ist - wobei N die Anzahl Bytes im Speicherzugriff ist (z. B. für eine Adressengenerierung, die 2^skalierung * index + basis + skalierte Verschiebung verwendet). Redundante niedrigwertige Bits werden ignoriert und somit wird der Inhalt des Verschiebungsfaktorfeldes mit der Gesamtgröße der Speicheroperanden (N) multipliziert, um die endgültige Verschiebung zu generieren, die beim Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird von der Prozessor-Hardware zur Laufzeit basierend auf dem (an späterer Stelle hierin beschriebenen) vollständigen Opcode-Feld 174 und dem Datenmanipulationsfeld 154C bestimmt. Das Verschiebungsfeld 162A und das Verschiebungsfaktorfeld 162B sind in dem Sinne optional, dass sie nicht für die Befehlsvorlagen ohne Speicherzugriff 105 benutzt werden und/oder dass verschiedene Ausführungsformen nur eines oder keines der beiden Felder implementieren können.
Datenelementbreitefeld 164 - der Inhalt dieses Feldes unterscheidet, welche von mehreren Datenelementbreiten zu verwenden ist (in einigen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für einige der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht benötigt wird, falls nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten mittels eines Aspekts des Opcodes unterstützt werden.
Schreibmaskenfeld 170 - der Inhalt dieses Feldes steuert, für jeden Datenelementort, ob der betreffende Datenelementort im Zielvektoroperanden das Ergebnis der Basisoperation und der Erweiterungsoperation widerspiegelt. Klasse-A-Befehlsvorlagen unterstützen Zusammenführen-Schreibmaskieren, während Klasse-B-Befehlsvorlagen sowohl Zusammenführen- als auch Nullsetzen-Schreibmaskieren unterstützen. Beim Zusammenführen ermöglichen Vektormasken, dass ein beliebiger Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung einer Operation (angegeben durch die Basisoperation und die Erweiterungsoperation) geschützt wird; in einer anderen Ausführungsform Beibehalten des alten Wertes jedes Elements des Ziels, wobei das entsprechende Maskenbit eine 0 hat. Demgegenüber ermöglichen Vektormasken beim Nullsetzen, dass ein beliebiger Satz von Elementen im Ziel während der Ausführung einer Operation (angegeben durch die Basisoperation und die Erweiterungsoperation) auf Null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen Wert von 0 hat. Eine Untermenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der durchgeführten Operation zu steuern (das heißt, die Spanne von Elementen, die modifiziert werden, vom ersten bis zum letzten); allerdings ist es nicht notwendig, dass die modifizierten Elemente aufeinander folgen. Somit ermöglicht das Schreibmaskenfeld 170 partielle Vektoroperationen einschließlich Ladevorgänge, Speichervorgänge, arithmetische Operationen, logische Operationen usw. Während hier Ausführungsformen der Erfindung beschrieben werden, bei denen der Inhalt des Schreibmaskenfeldes 170 eines von mehreren Schreibmaskenregistern auswählt, welches die zu verwendende Schreibmaske enthält (und der Inhalt des Schreibmaskenfeldes 170 somit indirekt die durchzuführende Maskierung identifiziert), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich dazu, dass der Inhalt des Schreibmaskenfeldes 170 die durchzuführende Maskierung direkt spezifiziert.
Direktoperandenfeld 172 - der Inhalt dieses Feldes ermöglicht die Spezifikation eines Direktoperanden. Dieses Feld ist in dem Sinne optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats, das Direktoperanden nicht unterstützt, nicht vorkommt und in Befehlen, die keinen Direktoperanden nutzen, nicht vorhanden ist.
Klassenfeld 168 - der Inhalt dieses Feldes unterscheidet zwischen verschiedenen Klassen von Befehlen. Bezug nehmend auf 1A-B wählt der Inhalt dieses Feldes zwischen Klasse-A- und Klasse-B-Befehlen aus. In 1A-B werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass in einem Feld ein spezifischer Wert enthalten ist (z. B. Klasse A 168A bzw. Klasse B 168B für das Klassenfeld 168 in 1A-B).
Klasse-A-Befehlsvorlagen
Im Fall der Klasse-A-Befehlsvorlagen ohne Speicherzugriff 105 wird das Alphafeld 152 als ein RS-Feld 152A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Runden 152A.1 und Datentransformation 152A.2 jeweils für die Befehlsvorlagen für Operationen des Typs Runden 110 ohne Speicherzugriff und die Befehlsvorlagen für Operationen des Typs Datentransformation ohne Speicherzugriff 115 spezifiziert), während das Betafeld 154 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Befehlsvorlagen ohne Speicherzugriff 105 sind das Skalierfeld 160, das Verschiebungsfeld 162A und das Verschiebungsskalierfeld 162B nicht vorhanden.
Befehlsvorlagen ohne Speicherzugriff - Operation des Typs vollständige Rundungssteuerung
In der Befehlsvorlage für Operationen des Typs vollständige Rundungssteuerung ohne Speicherzugriff 110 wird das Betafeld 154 als Rundungssteuerungsfeld 154A interpretiert, dessen Inhalt eine statische Rundung bereitstellt. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerungsfeld 154A ein Feld für das Unterdrücken aller Gleitkommaausnahmen (SAE) 156 und ein Rundungsoperationsteuerungsfeld 158 aufweist, können alternative Ausführungsformen das Codieren beider Konzepte in ein und dasselbe Feld unterstützen oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (z. B. können sie nur das Rundungsoperationsteuerungsfeld 158 aufweisen).
SAE-Feld 156 - der Inhalt dieses Feldes unterscheidet, ob das Berichten von Ausnahmeereignissen deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Feldes 156 anzeigt, dass die Unterdrückung aktiviert ist, berichtet ein gegebener Befehl keinerlei Gleitkommaausnahmemarkierungen und ruft keine Abwickelvorrichtung (Handler) für Gleitkommaausnahmen auf.
Rundungsoperationssteuerungsfeld 158 - der Inhalt dieses Feldes unterscheidet, welche Operation aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden nach Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationssteuerungsfeld 158 ein Ändern des Rundungsmodus für jeden Einzelbefehl. In einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister für das Spezifizieren von Rundungsmodi aufweist, hat der Inhalt des Rundungsoperationssteuerungsfeldes 150 Vorrang vor diesem Registerwert.
Befehlsvorlagen ohne Speicherzugriff - Operation des Typs Datentransformation
Bei der Befehlsvorlage für Operationen des Typs Datentransformation ohne Speicherzugriff 115 wird das Betafeld 154 als ein Datentransformationsfeld 154B interpretiert, dessen Inhalt unterscheidet, welche von mehreren Datentransformationen durchgeführt werden soll (z. B. keine Datentransformation, Swizzel, Senden).
Im Fall der Klasse-A-Befehlsvorlage mit Speicherzugriff 120 wird das Alphafeld 152 als ein Räumungshinweisfeld 152B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in 1A werden 152B.1 temporär bzw. 152B.2 nicht-temporär für die temporäre Befehlsvorlage mit Speicherzugriff 125 und die nicht-temporäre Befehlsvorlage mit Speicherzugriff 130 spezifiziert), während das Betafeld 154 als ein Datenbearbeitungsfeld 154C interpretiert wird, dessen Inhalt unterscheidet, welche von mehreren Datenbearbeitungsoperationen (auch Primitive genannt) durchgeführt werden soll (z. B. keine Manipulation; Senden; Aufwärtswandlung einer Quelle; und Abwärtswandlung eines Ziels). Die Befehlsvorlagen mit Speicherzugriff 120 umfassen das Skalierfeld 160 und optional das Verschiebungsfeld 162A oder das Verschiebungsskalierfeld 162B.
Vektorspeicherbefehle laden, mit Umwandlungsunterstützung, Vektoren aus dem Speicher und speichern Vektoren im Speicher. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten datenelementweise vom/an den Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske vorgegeben werden, die als Schreibmaske ausgewählt ist.
Befehlsvorlagen mit Speicherzugriff - temporär
Temporäre Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um vom Zwischenspeichern (Caching) zu profitieren. Dies ist jedoch ein Hinweis, und unterschiedliche Prozessoren können diesen auf verschiedene Art und Weise implementieren; dies schließt auch ein vollständiges Ignorieren des Hinweises ein.
Befehlsvorlagen mit Speicherzugriff - nicht-temporär
Nicht-temporäre Daten sind Daten, die wahrscheinlich nicht früh genug wiederverwendet werden, um vom Zwischenspeichern (Caching) im Ist-Level-Cache zu profitieren, und sollten bei der Räumung Priorität erhalten. Dies ist jedoch ein Hinweis, und unterschiedliche Prozessoren können diesen auf verschiedene Art und Weise implementieren; dies schließt auch ein vollständiges Ignorieren des Hinweises ein.
Klasse-B-Befehlsvorlagen
Im Fall der Klasse-B-Befehlsvorlagen wird das Alphafeld 152 als ein Feld zur Schreibmaskensteuerung (Z) 152C interpretiert, dessen Inhalt unterscheidet, ob das durch das Schreibmaskenfeld 170 gesteuerte Schreibmaskieren ein Zusammenführen oder Nullsetzen sein soll.
Im Fall der Klasse-B-Befehlsvorlagen ohne Speicherzugriff 105 wird ein Teil des Betafeldes 154 als ein RL-Feld 157A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 157A.1 und Vektorlänge (VSIZE) 157A.2 jeweils für die Befehlsvorlage für Operationen des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 112 und die Befehlsvorlage für eine Operation des Typs VSIZE 117 ohne Speicherzugriff mit Schreibmaskensteuerung spezifiziert), während der Rest des Betafeldes 154 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Befehlsvorlagen ohne Speicherzugriff 105 sind das Skalierfeld 160, das Verschiebungsfeld 162A und das Verschiebungsskalierfeld 162B nicht vorhanden.
Bei der Befehlsvorlage für Operationen des Typs partielle Rundungssteuerung ohne Speicherzugriff mit Schreibmaskensteuerung 110 wird der Rest des Betafeldes 154 als ein Rundungsoperationsfeld 159A interpretiert, und das Berichten von Ausnahmeereignissen ist deaktiviert (ein gegebener Befehl berichtet keinerlei Gleitkommaausnahmemarkierungen und ruft keine Abwickelvorrichtung (Handler) für Gleitkommaausnahmen auf).
Rundungsoperationssteuerungsfeld 159A - ebenso wie das Rundungsoperationssteuerungsfeld 158 unterscheidet der Inhalt dieses Feldes, welche Operation aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden nach Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationssteuerungsfeld 159A ein Ändern des Rundungsmodus für jeden Einzelbefehl. In einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister für das Spezifizieren von Rundungsmodi umfasst, hat der Inhalt des Rundungsoperationssteuerungsfeldes 150 Vorrang vor diesem Registerwert.
Bei der Befehlsvorlage für Operationen des Typs VSIZE ohne Speicherzugriff mit Schreibmaskensteuerung 117 wird der Rest des Betafeldes 154 als Vektorlängenfeld 159B interpretiert, dessen Inhalt unterscheidet, welche von mehreren Datenvektorlängen durchgeführt werden soll (z. B. 128, 256 oder 512 Bytes).
Bei der Klasse-B-Befehlsvorlage mit Speicherzugriff 120 wird ein Teil des Betafeldes 154 als Sendefeld 157B interpretiert, dessen Inhalt unterscheidet, ob die Datenbearbeitungsoperation des Typs Senden (Broadcast) durchgeführt werden soll oder nicht, während der Rest des Betafeldes 154 als Vektorlängenfeld 159B interpretiert wird. Die Befehlsvorlagen mit Speicherzugriff 120 weisen das Skalierfeld 160 und optional das Verschiebungsfeld 162A oder das Verschiebungsskalierfeld 162B auf.
Unter Bezugnahme auf das generische vektorfreundliche Befehlsformat 100 wird ein Feld mit vollständigem Opcode 174 gezeigt, welches das Formatfeld 140, das Basisoperationsfeld 142 und das Datenelementbreitefeld 164 aufweist. Während eine Ausführungsform gezeigt wird, bei der das Feld mit vollständigem Opcode 174 alle diese Felder aufweist, beinhaltet das Feld mit vollständigem Opcode 174 in Ausführungsformen, die nicht alle dieser Felder unterstützen, weniger als alle diese Felder. Das Feld mit vollständigem Opcode 174 stellt den Operationscode (Opcode) bereit.
Das Erweiterungsoperationsfeld 150, das Datenelementbreitefeld 164 und das Schreibmaskenfeld 170 ermöglichen, dass diese Merkmale im generischen vektorfreundlichen Befehlsformat für jeden Einzelbefehl spezifiziert werden können.
Die Kombination von Schreibmaskenfeld und Datenelementbreitefeld erzeugt dahingehend typisierte Befehle, dass sie ermöglichen, die Maske auf Basis von unterschiedlichen Datenelementbreiten anzuwenden.
Die verschiedenen in Klasse A und Klasse B zu findenden Befehlsvorlagen sind in unterschiedlichen Situationen von Vorteil. In einigen Ausführungsformen der Erfindung können verschiedene Prozessoren oder verschiedene Kerne in einem Prozessor nur die Klasse A, nur die Klasse B oder beide Klassen unterstützen. So kann beispielsweise ein universeller Out-of-Order-Hochleistungskern, der für allgemeine Datenverarbeitungszwecke vorgesehen ist, nur Klasse B, ein Kern, der primär für grafische und/oder wissenschaftliche (Durchsatz) Berechnungen vorgesehen ist, nur Klasse A und ein Kern, der für beides vorgesehen ist, beide Klassen unterstützen (natürlich liegt auch ein Kern, der über eine Mischung aus Vorlagen und Befehlen aus beiden Klassen, aber nicht alle Vorlagen und Befehle aus beiden Klassen verfügt, im Geltungsbereich der hier beschriebenen Erfindung). Auch ein einzelner Prozessor kann mehrere Kerne aufweisen, die alle dieselbe Klasse unterstützen oder in denen verschiedene Kerne unterschiedliche Klassen unterstützen. So kann beispielsweise in einem Prozessor mit getrennten Grafik- und Universalkernen einer der Grafikkerne, der primär für grafische und/oder wissenschaftliche Berechnungen vorgesehen ist, nur Klasse A unterstützen, während einer oder mehrere der Universalkerne für allgemeine Datenverarbeitungszwecke vorgesehene universelle Hochleistungskerne mit Out-of-Order-Ausführung und Registerumbenennung sein können, die nur Klasse B unterstützen. Ein anderer Prozessor, der nicht über einen separaten Grafikkern verfügt, kann einen oder mehrere universelle In-Order-/Out-of-Order-Kerne aufweisen, die Klasse A und Klasse B unterstützen. Natürlich können in unterschiedlichen Ausführungsformen der hier beschriebenen Erfindung Merkmale aus einer Klasse auch in der anderen Klasse implementiert sein. In einer Hochsprache geschriebene Programme würden (z. B. zum Bedarfszeitpunkt kompiliert oder statisch kompiliert) in mehrere unterschiedliche ausführbare Formen gebracht werden, einschließlich: 1) eine Form, welche nur Befehle der Klasse(n) aufweist, die vom Zielprozessor zur Ausführung unterstützt werden; oder 2) eine Form, welche alternative Routinen aufweist, die unter Verwendung verschiedener Kombinationen der Befehle aller Klassen geschrieben wurden, und welche Flusssteuerungscode aufweist, der die auszuführenden Routinen auf Basis der vom Prozessor, welcher gerade den Code ausführt, unterstützen Befehle auswählt.
VEX-Befehlsformat
Die VEX-Codierung macht es möglich, dass Befehle mehr als zwei Operanden aufweisen können, und macht es möglich, dass SIMD-Vektorregister länger als 28 Bit sein können. Die Verwendung eines VEX-Präfixes unterstützt eine Syntax mit drei (oder mehr) Operanden. So führten beispielsweise die vorstehenden Befehle mit zwei Operanden Operationen wie A = A + B, wodurch ein Quelloperand überschrieben wird, durch. Die Verwendung eines VEX-Präfixes ermöglicht es Operanden, nichtdestruktive Operationen wie A = B + C durchzuführen.
2A veranschaulicht ein beispielhaftes AVX-Befehlsformat, das ein VEX-Präfix 202, ein Feld mit reellem Opcode 230, ein Mod-R/M-Byte 240, ein SIB-Byte 250, ein Verschiebungsfeld 262 und IMM8 272 aufweist. veranschaulicht, welche Felder aus ein Feld mit vollständigem Opcode 274 und ein Basisoperationsfeld 241 bilden. 2C veranschaulicht, welche Felder von 2A ein Registerindexfeld 244 bilden.
Das VEX-Präfix (Bytes 0-2) 202 ist in einer Drei-Byte-Form codiert. Das erste Byte ist das Formatfeld 290 (VEX-Byte 0, Bits [7:0]), welches einen expliziten C4-Byte-Wert enthält (den für das Unterscheiden des C4-Befehlsformats verwendeten eindeutigen Wert). Die zweiten-dritten Bytes (VEX-Bytes 1-2) weisen eine Anzahl von Bitfeldern auf, die eine spezifische Funktionalität bereitstellen. Insbesondere besteht das REX-Feld 205 (VEX-Byte 1, Bits [7-5]) aus einem VEX.R-Bit-Feld (VEX-Byte 1, Bit [7] - R), einem VEX.X-Bit-Feld (VEX-Byte 1, Bit [6] - X) und einem VEX.B-Bit-Feld (VEX-Byte 1, Bit [5] - B). Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes nach dem Stand der Technik (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von VEX.R, VEX.X und VEX.B gebildet werden können. Das Opcode-Map-Feld 215 (VEX-Byte 1, Bits [4:0] - mmmmm) weist Inhalt zum Codieren eines implizierten führenden Opcode-Bytes auf. Das W-Feld 264 (VEX-Byte 2, Bit [7] - W) - ist durch die Notation VEX.W dargestellt und stellt je nach Befehl unterschiedliche Funktionen bereit. Die Rolle von VEX.vvvv 220 (VEX-Byte 2, Bits [6:3]-vvvv) kann Folgendes beinhalten: 1) VEX.vvvv codiert den ersten Quellregisteroperanden, angegeben in invertierter (1s-Komplement-) Form, und gilt für Befehle mit 2 oder mehr Quelloperanden; 2) VEX.vvvv codiert den Zielregisteroperanden, angegeben in 1s-Komplement-Form, für bestimmte Vektorverschiebungen; oder 3) VEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Wenn das VEX.L 268-Größe-Feld (VEX-Byte 2, Bit [2]-L) = 0 ist, zeigt es einen 28-Bit-Vektor an; wenn VEX.L = 1, zeigt es einen 256-Bit-Vektor an. Das Präfixcodierungsfeld 225 (VEX-Byte 2, Bits [1:0]-pp) stellt zusätzliche Bits für das Basisoperationsfeld 241 bereit.
Das Feld mit reellem Opcode 230 (Byte 3) wird auch Opcode-Byte genannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
Das MOD-R/M-Feld 240 (Byte 4) beinhaltet das MOD-Feld 242 (Bits [7-6]), das Reg-Feld 244 (Bits [5-3]) und das R/M-Feld 246 (Bits [2-0]). Die Rolle des Reg-Feldes 244 kann Folgendes umfassen: Codieren des Zielregisteroperanden oder eines Quellregisteroperanden (rrr-Teil von Rrrr) oder Handhabung als eine Opcode-Erweiterung und Nichtverwendung für das Codieren irgendeines Befehlsoperanden. Die Rolle des R/M-Feldes 246 kann Folgendes umfassen: Codieren des Befehlsoperanden, der eine Speicheradresse referenziert, oder Codieren des Zielregisteroperanden oder eines Quellregisteroperanden.
Skala, Index, Basis (SIB) - der Inhalt des Skalierfeldes 250 (Byte 5) schließt SS252 (Bits [7-6]) ein, das zur Speicheradressgenerierung verwendet wird. Die Inhalte von SIB.xxx 254 (Bits [5-3]) und SIB.bbb 256 (Bits [2-0]) sind zuvor unter Bezugnahme auf die Registerindizes Xxxx und Bbbb angesprochen worden.
Das Verschiebungsfeld 262 und das Direktoperandenfeld (IMM8) 272 enthalten Daten.
Beispielhafte Registerarchitektur
3 ist ein Blockschaltbild einer Registerarchitektur 300 gemäß einer Ausführungsform der Erfindung. In der dargestellten Ausführungsform gibt es 32 Vektorregister 310, die 512 Bits breit sind; diese Register werden als zmm0 bis zmm31 referenziert. Die niederwertigen 256 Bits der unteren 6 zmm-Register sind auf den Registern ymm0-15 überlagert. Die niederwertigen 128 Bits auf den unteren 6 zmm-Registern (die niederwertigen 128 Bits des ymm-Registers) sind auf den Registern xmm0-15 überlagert.
Universalregister 325 - in der dargestellten Ausführungsform gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den bestehenden x86 Adressierungsmodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register werden durch die Namen RAX, RBX, PCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 referenziert.
Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 345, der die MMX-gepackte Ganzzahl-Flachregisterdatei 350 per Alias zugeordnet ist - in der dargestellten Ausführungsform ist der x87-Stapel ein Acht-Elemente-Stapel, der verwendet wird, um unter Verwendung der x87-Befehlssatzerweiterung skalare Gleitkommaoperationen für 32/64/80-Bit-Gleitkommadaten durchzuführen; während die MMX-Register verwendet werden, um Operationen für 64-Bit-gepackte ganzzahlige Daten durchzuführen, sowie um Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
Alternative Ausführungsformen der Erfindung können breitere oder schmalere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
Prozessorkerne können für unterschiedliche Zwecke und in unterschiedlichen Prozessoren auf verschiedene Art und Weise implementiert sein. So können beispielsweise Implementierungen solcher Kerne beinhalten: 1) einen universellen In-Order-Kern für allgemeine Datenverarbeitungszwecke; 2) einen universellen Out-of-Order-Hochleistungskern für allgemeine Datenverarbeitungszwecke; 3) einen Spezialkern, der primär für grafische und/oder wissenschaftliche (Durchsatz)Berechnungen vorgesehen ist. Implementierungen von unterschiedlichen Prozessoren können beinhalten: 1) eine CPU, die einen oder mehrere In-order-Universalkerne aufweist, die für allgemeine Datenverarbeitungszwecke vorgesehen sind, und/oder einen oder mehrere Out-of-order-Universalkerne, die für allgemeine Datenverarbeitungszwecke vorgesehen sind; und 2) einen Coprozessor, der einen oder mehrerer Spezialkerne aufweist, die hauptsächlich für Grafik und/oder wissenschaftlich (Durchsatz) vorgesehen sind. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die aufweisen können: 1) den Coprozessor auf einem von der CPU verschiedenen Chip; 2) den Coprozessor auf einem separaten Die in demselben Paket wie eine CPU; 3) den Coprozessor auf demselben Halbleiterplättchen wie die CPU (in diesem Fall wird ein solcher Coprozessor manchmal als Speziallogik bezeichnet, beispielsweise als integrierte Grafik und/oder wissenschaftliche (Durchsatz)Logik oder als Spezialkerne); und 4) ein System auf einem Chip, der auf demselben Halbleiterplättchen die beschriebene CPU (manchmal als Anwendungskern(e) oder als Anwendungsprozessor(en) bezeichnet), den vorstehend beschriebenen Coprozessor und zusätzliche Funktionalität aufweisen kann. Beispielhafte Kernarchitekturen werden anschließend beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen. Hierin ausführlich beschrieben sind Schaltungen (Einheiten), die beispielhafte Kerne, Prozessoren usw. umfassen.
Beispielhafte Kernarchitekturen
4A ist ein Blockschaltbild, das eine beispielhafte In-Order-Pipeline und eine beispielhafte registerumbenennende Out-of-Order-Ausgabe-/Ausführungspipeline gemäß Ausführungsformen der Erfindung veranschaulicht. 4B ist ein Blockschaltbild, das eine beispielhafte Ausführungsform eines In-Order-Architekturkerns und einen beispielhaften registerumbenennenden Out-of-Order-Ausgabe-/Ausführungsarchitekturkern zur Aufnahme in einen Prozessor gemäß Ausführungsformen der Erfindung veranschaulicht. Die in mit einer durchgehenden Linie gekennzeichneten Felder veranschaulichen die In-Order-Pipeline und den In-Order-Kern, während die optionale Ergänzung der mit einer gestrichelten Linie gekennzeichneten Felder die Registerumbenennung, die Out-of-Order-Ausgabe/Ausführungspipeline und den Out-of-Order-Ausgabe/Ausführungskern veranschaulicht. Da der In-Order-Aspekt eine Untermenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
In 4A umfasst eine Prozessorpipeline 400 eine Abrufstufe 402, eine Längendecodierstufe 404, eine Decodierstufe 406, eine Zuweisungsstufe 408, eine Umbenennungsstufe 410, eine Zeitplanungsstufe (auch Versandstufe oder Ausgabestufe genannt) 412, eine Registerlese-/Speicherlesestufe 414, eine Ausführungsstufe 416, eine Rückschreibe-/Speicherschreibstufe 418, eine Ausnahmebehandlungsstufe 422 und eine Übergabestufe 424.
zeigt einen Prozessorkern 490 mit einer Frontend-Einheit 430, die an eine Ausführungsmaschineneinheit 450 gekoppelt ist, und beide sind an eine Speichereinheit 470 gekoppelt. Der Kern 490 kann ein Kern für Rechnen mit reduziertem Befehlssatz (Reduced Instruction Set Computing, RISC), ein Kern für Rechnen mit komplexem Befehlswort (Complex Instruction Set Computing, CISC), ein Kern mit sehr langem Befehlswort (Very Long Instruction Word, VLIW) oder ein hybrider oder alternativer Kerntyp sein. Als eine noch andere Option kann es sich bei dem Kern 490 um einen Spezialkern handeln, beispielsweise einen Netz- oder Kommunikationskern, eine Kompressionsmaschine, einen Coprozessorkern, den Kern einer Grafikverarbeitungseinheit für allgemeine Verarbeitungszwecke (General Purpose Computing Graphics Processing Unit, GPGPU), einen Grafikkern oder dergleichen.
Die Frontend-Einheit 430 weist eine Sprungvorhersage-Einheit 432 auf, die an eine Befehlscache-Einheit 434 gekoppelt ist, welche an einen Übersetzungspuffer (Translation Lookaside Buffer, TLB) für Befehle 436 gekoppelt ist, der wiederum an eine Befehlsabrufeinheit 438 gekoppelt ist, die an eine Decodiereinheit 440 gekoppelt ist. Die Decodiereinheit 440 (oder der Decodierer) kann Befehle decodieren und als Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Einsprungpunkte, Mikrobefehle, andere Befehle oder andere Steuersignale generieren, die anhand der ursprünglichen Befehle decodiert werden oder die ursprünglichen Befehle in anderer Weise wiedergeben oder von den ursprünglichen Befehlen abgeleitet sind. Die Decodiereinheit 440 kann unter Verwendung von mehreren unterschiedlichen Mechanismen implementiert sein. Beispiele für geeignete Mechanismen umfassen, ohne jedoch hierauf beschränkt zu sein, Nachschlagetabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (Programmable Logic Arrays, PLAs), Festwertspeicher (Read-only Memories, ROMs) für Mikrocode etc. In einer Ausführungsform weist der Kern 490 einen Mikrocode-ROM oder ein anderes Medium auf, das Mikrocode für bestimmte Makrobefehle (z. B. in einer Decodiereinheit 440 oder sonstwie in der Frontend-Einheit 430) speichert. Die Decodiereinheit 440 ist an eine Umbenennungs-/Zuweisungseinheit 452 in der Ausführungsmaschineneinheit 450 gekoppelt.
Die Ausführungsmaschineneinheit 450 weist die Umbenennungs-/Zuweisungseinheit 452 auf, die an eine Rückordnungseinheit 454 und an einen Satz von einer oder mehreren Planereinheit(en) 456 gekoppelt ist. Die Planereinheit(en) 456 repräsentiert (repräsentieren) eine beliebige Anzahl von unterschiedlichen Planern, einschließlich Reservierungsstationen, ein zentrales Befehlsfenster etc. Die Planereinheit(en) 456 ist (sind) an die physischen Registerdatei-Einheit(en) 458 gekoppelt. Alle Einheit(en) der physischen Registerdatei(en) 458 stellen eine oder mehrere physische Registerdateien dar, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma, Status (z. B. ein Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. In einer Ausführungsform umfasst die Einheit der physischen Registerdatei(en) 458 eine Vektorregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdatei-Einheit(en) 458 wird (werden) von der Rückordnungseinheit 454 überlappt, um verschiedene Arten und Weisen zu veranschaulichen, auf die eine Registerumbenennung und eine Out-of-Order-Ausführung implementiert sein können (z. B. unter Verwendung von (einem oder mehreren) Neuordnungspuffern und (einer oder mehreren) Rückordnungsregisterdateien; unter Verwendung von (einer oder mehreren) zukünftigen Dateien, (einem oder mehreren) historischen Puffern und (einer oder mehreren) Rückordnungsregisterdateien; unter Verwendung von Registerkarten und eines Registerpools usw.). Die Rückordnungseinheit 454 und die physische(n) Registerdateieinheit(en) 458 sind an die Ausführungscluster 460 gekoppelt. Der (Die) Ausführungscluster 460 weist (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, Additionen, Subtraktionen, Multiplikationen) und an verschiedenen Datentypen (z. B. skalarer Gleitkommawert, gepackte Ganzzahl, gepackter Gleitkommawert, Vektorganzzahl, Vektorgleitkommawert) durchführen. Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten aufweisen können, die für spezifische Funktionen oder Funktionssätze vorgesehen sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten aufweisen, die alle sämtliche Funktionen durchführen. Die Planereinheit(en) 456, die physische(n) Registerdatei-Einheit(en) 458 und die Ausführungscluster 460 werden als möglicherweise mehrfach vorhanden gezeigt, weil bestimmte Ausführungsformen getrennte Pipelines für bestimmte Arten von Daten/Operationen erzeugen (z. B. eine skalare Ganzzahl-Pipeline, eine Pipeline für skalare Gleitkommawerte/gepackte Ganzzahlen/gepackte Gleitkommawerte/Vektorganzzahlen/Vektorgleitkommawerte und/oder eine Speicherzugriffspipeline, die jeweils eine eigene Planereinheit, physische Registerdatei-Einheit und/oder Ausführungscluster aufweisen - und im Fall einer separaten Speicherzugriffspipeline sind bestimmte Ausführungsformen implementiert, bei denen nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 464 aufweist). Ferner sei darauf hingewiesen, dass in den Fällen, in denen separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines als Out-of-Order-Ausgabe-/Ausführungspipeline und der Rest als In-Order-Pipeline ausgeführt sein kann (können).
Der Satz der 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 Level-2 (L2)-Cache-Einheit 476 gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 464 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit aufweisen, von denen jede an die Daten-TLB-Einheit 472 in der Speichereinheit 470 gekoppelt ist. Die Befehls-Cache-Einheit 434 ist ferner an eine Level-2 (L2)-Cache-Einheit 476 in der Speichereinheit 470 gekoppelt. Die L2-Cache-Einheit 476 ist an einen oder mehrere andere Cache-Level gekoppelt und letztendlich an einen Hauptspeicher.
Beispielsweise kann die registerumbenennende Out-of-Order-Ausgabe/Ausführungskern-Architektur die Pipeline 400 wie folgt implementieren: 1) die Befehlsabrufeinheit 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-/Zuweisungseinheit 452 führt die Zuweisungsstufe 408 und die Umbenennungsstufe 410 durch; 4) die Planereinheit(en) 456 führt (führen) die Planungsstufe 412 durch; 5) die physische(n) Registerdatei-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 physische(n) Registerdateieinheit(en) 458 führen die Rückschreibe-/Speicherschreibstufe 418 durch; 7) verschiedene Einheiten können in die Ausnahmebehandlungsstufe 422 einbezogen sein; und 8) die Rückordnungseinheit 454 und die physische(n) Registerdatei-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, Kalifornien; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings aus Sunnyvale, Kalifornien), einschließlich der hier beschriebenen Befehle. In einer Ausführungsform weist der Kern 490 Logik für das Unterstützen einer Befehlssatzerweiterung für gepackte Daten (z. B. AVX1, AVX2) auf, so dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden können.
An dieser Stelle sei angemerkt, dass der Kern ein Multithreading (das Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Programmfäden) unterstützen kann und dies auf verschiedene Art und Weise realisieren kann, einschließlich zeitscheibenbasiertes Multithreading, simultanes Multithreading (bei dem ein einzelner physischer Kern für jeden der Programmfäden, die dieser physische Kern gleichzeitig verarbeitet, einen logischen Kern bereitstellt) oder eine Kombination davon (z. B. zeitscheibenbasiertes Abrufen und Decodieren und anschließendes simultanes Multithreading wie beispielsweise bei der Intel® Hyperthreading-Technologie).
Auch wenn die Registerumbenennung im Zusammenhang mit der Out-of-Order-Ausführung beschrieben wird, versteht es sich, dass die Registerumbenennung auch in einer In-Order-Architektur verwendet werden kann. Auch wenn die dargestellte Ausführungsform des Prozessors getrennte Befehls- und Datencache-Einheiten 434/474 und eine gemeinsam genutzte L2-Cache-Einheit 476 aufweist, können alternative Ausführungsformen einen einzelnen internen Cache für beides, Befehle und Daten, aufweisen, wie beispielsweise einen internen Level-1 (L1)-Cache oder mehrere Ebenen von internem Cache. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Cache und einem externen Cache aufweisen, der außerhalb des Kerns und/oder des Prozessors liegt. Alternativ kann der gesamte Cache außerhalb des Kerns und/oder des Prozessors liegen.
Spezifische beispielhafte In-Order-Kernarchitektur
5A-B zeigen ein Blockschaltbild einer spezifischeren beispielhaften In-order-Kernarchitektur, deren Kern einer von verschiedenen Logikblöcken (einschließlich anderer Kerne des gleichen Typs und/oder verschiedener Typen) in einem Chip wäre. Die Logikblöcke kommunizieren durch ein Verbindungsnetz mit großer Bandbreite (z. B. ein Ringnetz) mit fester Funktionslogik, Speicher-E/A-Schnittstellen und anderer erforderlicher E/A-Logik, je nach Anwendung.
5A ist ein Blockschaltbild eines einzelnen Prozessorkerns, zusammen mit dessen Verbindung zum On-die-Verbindungsnetz 502 und mit der zugehörigen lokalen Untermenge des Level-2 (L2)-Caches 504 gemäß Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdecodierer 500 den x86-Befehlssatz mit einer Befehlssatzerweiterung für gepackte Daten. Ein L1-Cache 506 ermöglicht latenzarme Zugriffe auf den Cache-Speicher in die Skalar- und die Vektoreinheiten. Während in einer Ausführungsform (um das Design zu vereinfachen) eine Skalareinheit 508 und eine Vektoreinheit 510 getrennte Registersätze (Skalarregister 512 bzw. Vektorregister 514) verwenden und zwischen diesen übertragene Daten in den Speicher geschrieben und dann aus einem Level-1 (L1)-Cache 506 erneut eingelesen werden, können alternative Ausführungsformen der Erfindung einen unterschiedlichen Ansatz verfolgen (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad aufweisen, der es erlaubt, Daten ohne Zurückschreiben und -lesen zwischen den zwei Registerdateien zu übertragen).
Die lokale Untermenge des L2-Caches 504 ist Teil eines globalen L2-Caches, der in getrennte lokale Untermengen unterteilt ist, eine pro Prozessorkern. Jeder Prozessorkern weist einen Direktzugriffspfad zu seiner eigenen lokalen Untermenge des L2-Caches 504 auf. Von einem Prozessorkern gelesene Daten werden in dessen eigener Untermenge des L2-Caches 504 gespeichert und es kann schnell darauf zugegriffen werden, was parallel zum Zugreifen anderer Prozessorkerne auf deren Untermengen des lokalen L2-Caches erfolgen kann. Von einem Prozessorkern geschriebene Daten werden in der zum Prozessorkern gehörigen Untermenge des L2-Caches 504 gespeichert und, falls erforderlich, aus anderen Untermengen gelöscht. Das Ringnetz stellt die Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetz ist bidirektional, um es Agenten wie Prozessorkernen, L2-Caches und anderen Logikblöcken zu ermöglichen, chipintern miteinander zu kommunizieren. Jeder Ringdatenpfad ist in einigen Ausführungsformen je Richtung 1024 Bits breit.
5B ist eine erweiterte Ansicht eines Teils des Prozessorkerns aus 5A gemäß Ausführungsformen der Erfindung. 5B beinhaltet einen L1-Datencache 506A, Teil des L1-Caches 504, sowie mehr Einzelheiten hinsichtlich der Vektoreinheit 510 und der Vektorregister 514. Insbesondere ist die Vektoreinheit 510 eine Vektorverarbeitungseinheit (Vector Processing Unit, VPU) mit einer Breite 16 (siehe die ALU 528 mit Breite 16), die einen oder mehrere Befehle für Ganzzahlen, einfach genaue Gleitkommawerte und doppelt genaue Gleitkommawerte ausführt. Die VPU unterstützt das Swizzeln der Registereingaben mit Swizzel-Einheit 520, die numerische Umwandlung mit Einheiten zur numerischen Umwandlung 522A-B und die Replikation mit einer Replikationseinheit 524 am Speichereingang.
Prozessor mit integrierter Speichersteuerung und Grafik
6 ist ein Blockschaltbild eines Prozessors 600, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und eine integrierte Grafik gemäß Ausführungsformen der Erfindung aufweisen kann. Die Felder in 6 mit durchgezogenen Linien veranschaulichen einen Prozessor 600 mit einem einzelnen Kern 602A, einem Systemagenten 610, einem Satz von einer oder mehreren Bussteuerungseinheiten 616, während die optionale Ergänzung der Felder mit gestrichelten Linien einen alternativen Prozessor 600 mit mehreren Kernen 602A-N, einen Satz von einer oder mehreren integrierten Speichersteuerungseinheit(en) 614 in der Systemagenteneinheit 610 und eine Speziallogik 608 veranschaulicht.
Somit können unterschiedliche Implementierungen des Prozessors 600 aufweisen: 1) eine CPU mit der Speziallogik 608, bei der es sich um eine integrierte Grafik und/oder eine wissenschaftliche (Durchsatz)Logik handelt (die einen oder mehrere Kerne aufweisen kann) und die Kerne 602A-N, bei denen es sich um einen oder mehrere Universalkerne (z. B. universelle In-Order-Kerne, universelle Out-of-Order-Kerne, eine Kombination der beiden) handelt; 2) einen Coprozessor, mit den Kernen 602A-N, bei denen es sich um eine große Anzahl von Spezialkernen handelt, die primär für grafische und/oder wissenschaftliche (Durchsatz)Berechnungen vorgesehen sind; und 3) einen Coprozessor mit den Kernen 602A-N, bei denen es sich um eine große Anzahl von universellen In-Order-Kernen handelt. Somit kann der Prozessor 600 ein Universalprozessor, ein Coprozessor oder ein Spezialprozessor sein, wie zum Beispiel ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU (General Purpose Graphics Processing Unit, Universalgrafikverarbeitungseinheit), ein MIC-Coprozessor (MIC = Many Integrated Core, viele integrierte Kerne) mit hohem Durchsatz (mit 30 oder mehr Kernen), ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 600 kann Teil eines Substrats sein und/oder unter Verwendung einer Anzahl von Prozesstechnologien wie beispielsweise BiCMOS, CMOS oder NMOS auf einem oder mehreren Substraten implementiert sein.
Die Speicherhierarchie beinhaltet ein oder mehrere Cache-Level in den Kernen 604A-N, einen Satz oder eine oder mehrere gemeinsame Cache-Einheiten 606 und externen Speicher (nicht gezeigt), der an den Satz von integrierten Speichersteuerungseinheiten 614 gekoppelt ist. Der Satz von gemeinsam genutzten Cache-Einheiten 606 kann einen oder mehrere Mid-Level-Caches, beispielsweise Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Level, einen Last-Level-Cache (LLC) und/oder Kombinationen davon aufweisen. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 612 die integrierte Grafiklogik 608, den Satz von gemeinsamen Cache-Einheiten 606 und die Systemagenteneinheit 610/die integrierte(n) Speichersteuerungseinheit(en) 614 zusammenschaltet, können alternative Ausführungsformen eine beliebige Zahl von bekannten Techniken zum Zusammenschalten solcher Einheiten verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer/einem oder mehreren Cache-Einheiten 606 und Kernen 602-A-N beibehalten.
Bei manchen Ausführungsformen sind einer oder mehrere der Kerne 602A-N in der Lage, im Mehrstrangbetrieb zu arbeiten. Der Systemagent 610 beinhaltet diejenigen Komponenten, welche die Kerne 602AN koordinieren und betreiben. Die Systemagent-Einheit 610 kann beispielsweise eine Leistungssteuerungseinheit (Power Control Unit, PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann eine Logik sowie Komponenten sein oder aufweisen, die zur Regelung des Leistungszustands der Kerne 602A-N und der integrierten Grafiklogik 608 notwendig sind. Die Anzeigeeinheit dient zum Ansteuern von einer oder mehreren extern verbundenen Anzeigen.
Die Kerne 602A-N können in Bezug auf den Architekturbefehlssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 602A-N können in der Lage sein, denselben Befehlssatz auszuführen, während andere in der Lage sein können, nur eine Untermenge dieses Befehlssatzes oder einen anderen Befehlssatz auszuführen.
Beispielhafte Computerarchitekturen
Die 7-10 sind Blockschaltbilder von beispielhaften Computerarchitekturen. Andere in der Technik bekannte Systementwürfe und Konfigurationen für Laptops, Desktops, Handheld-PCs, persönliche digitale Assistenten (PDAs), Arbeitsstationen (Engineering Workstations, EWS), Server, Netzvorrichtungen, Netzknoten, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienwiedergabegeräte, Handheld-Vorrichtungen und verschiedene andere elektronische Vorrichtungen sind ebenfalls geeignet. Im Allgemeinen ist eine große Vielfalt von Systemen oder elektronischen Vorrichtungen, die zur Aufnahme eines Prozessors und/oder anderer Ausführungslogik wie hierin offenbart in der Lage sind, allgemein geeignet.
Es wird nun Bezug genommen auf 7; gezeigt wird ein Blockschaltbild eines Systems 700 gemäß einer Ausführungsform der vorliegenden Erfindung. Das System 700 kann einen oder mehrere Prozessoren 710, 715 aufweisen, die an einen Steuerungsknoten 720 gekoppelt sind. In einer Ausführungsform weist der Steuerungsknoten 720 einen Grafikspeicher-Steuerungsknoten (Graphics Memory Controller Hub, GMCH) 790 und einen Eingabe/Ausgabe-Knoten (Input/Output Hub, IOH) 750 auf (die sich auf separaten Chips befinden können); schließt der GMCH 790 Speicher- und Grafiksteuerungen ein, an die ein Speicher 740 und ein Coprozessor 745 gekoppelt sind; koppelt das IOH 750 Ein-/Ausgabe (E/A)-Vorrichtungen 760 an den GMCH 790. Alternativ sind eine oder beide der Speicher- und Grafiksteuerungen (wie hier beschrieben) im Prozessor integriert, der Speicher 740 und der Coprozessor 745 sind direkt an den Prozessor 710 gekoppelt und der Steuerungsknoten 720 befindet sich in einem einzelnen Chip mit dem IOH 750.
Der optionale Charakter zusätzlicher Prozessoren 715 ist in 7 durch die gestrichelten Linien hervorgehoben. Jeder Prozessor 710, 715 kann einen oder mehrere der hier beschriebenen Verarbeitungskerne aufweisen und eine Version des Prozessors 600 sein.
Bei dem Speicher 740 kann es sich beispielsweise um dynamischen Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM), Phasenwechselspeicher (Phase Change Memory, PCM) oder um eine Kombination der beiden handeln. Für wenigstens eine Ausführungsform kommuniziert der Steuerungsknoten 720 mit den Prozessor(en) 710, 715 über einen Multi-Drop-Bus, etwa einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle oder eine ähnliche Verbindung 795.
In einer Ausführungsform ist der Coprozessor 745 ein Spezialprozessor, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Steuerungsknoten 720 einen integrierten Grafikbeschleuniger aufweisen.
Es kann verschiedene Unterschiede zwischen den physischen Ressourcen 710, 7155 im Hinblick auf ein Spektrum von Gütemetriken geben, zu denen architektonische, mikroarchitektonische, thermische, leistungsaufnahmebezogene Eigenschaften und dergleichen zählen.
In einer Ausführungsform führt der Prozessor 710 Befehle aus, die Datenverarbeitungsoperationen von allgemeiner Art steuern. In die Befehle können Coprozessorbefehle eingebettet sein. Der Prozessor 710 erkennt diese Coprozessorbefehle als Befehle eines Typs, der durch den verbundenen Coprozessor 745 ausgeführt werden sollte. Dementsprechend gibt der Prozessor 710 diese Coprozessorbefehle (oder Steuersignale, die Coprozessorbefehle repräsentieren) über einen Coprozessor-Bus oder eine andere Zwischenverbindung an den Coprozessor 745 aus. Ein oder mehrere Coprozessoren 745 nehmen die empfangenen Befehle an und führen sie aus.
Es wird nun Bezug genommen auf 8; gezeigt wird ein Blockschaltbild eines ersten spezifischeren beispielhaften Systems 800 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie in 8 gezeigt, ist das Mehrprozessorsystem 800 ein Punkt-zu-Punkt-Verbindungssystem und weist einen ersten Prozessor 870 und einen zweiten Prozessor 880 auf, die über eine Punkt-zu-Punkt-Verbindung 850 gekoppelt sind. Jeder der Prozessoren 870 und 880 kann eine Version des Prozessors 600 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 870 und 880 die Prozessoren 710 bzw. 715, während der Coprozessor 838 der Coprozessor 745 ist. In einer anderen Ausführungsform sind die Prozessoren 870 und 880 Prozessor 710 bzw. Coprozessor 745.
Es ist gezeigt, dass die Prozessoren 870 und 880 integrierte Speichersteuerungseinheiten (IMC, Integrated Memory Controller) 872 bzw. 882 aufweisen. Der Prozessor 870 weist außerdem als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt (P-P)-Schnittstellen 876 und 878 auf; in ähnlicher Weise weist der zweite Prozessor 880 P-P-Schnittstellen 886 und 888 auf. Die Prozessoren 870, 880 können Informationen über eine Punkt-zu-Punkt (P-P)-Schnittstelle 850 unter Verwendung von P-P-Schnittstellenschaltungen 878, 888 austauschen. Wie in 8 gezeigt, koppeln die IMCs 872 und 882 die Prozessoren an die jeweiligen Speicher, nämlich einen Speicher 832 und einen Speicher 834, die Teile des lokal mit den jeweiligen Prozessoren verbundenen Hauptspeichers sein können.
Die Prozessoren 870, 880 können jeder über individuelle P-P-Schnittstellen 852, 854 Informationen mit einem Chipsatz 890 austauschen, wobei Punkt-zu-Punkt-Schnittstellenschaltungen 876, 894, 886, 898 verwendet werden. Der Chipsatz 890 kann optional über eine Hochleistungsschnittstelle 892 Informationen mit dem Coprozessor 838 austauschen. In einer Ausführungsform ist der Coprozessor 838 ein Spezialprozessor, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
Ein gemeinsam genutzter (nicht gezeigter) Cache kann in jedem Prozessor enthalten sein oder außerhalb beider Prozessoren vorliegen, aber mit den Prozessoren über eine P-P-Verbindung verbunden sein, so dass lokale Cache-Informationen eines der oder beider Prozessoren im gemeinsam genutzten Cache gespeichert werden können, falls ein Prozessor in einen Niedrigenergiemodus versetzt wird.
Der Chipsatz 890 kann über eine Schnittstelle 896 an einen ersten Bus 816 gekoppelt sein. In einer Ausführungsform kann der erste Bus 816 ein Peripheriegeräteverbindungsbus (Peripheral Component Interconnect, PCI) oder ein Bus wie beispielsweise ein PCI Express-Bus oder ein anderer E/A-Verbindungsbus sein, wenngleich der Schutzbereich der vorliegenden Erfindung nicht hierauf beschränkt ist.
Wie in 8 gezeigt, können verschiedene E/A-Vorrichtungen 814 an den ersten Bus 816 gekoppelt sein, zusammen mit einer Busbrücke 818, die den ersten Bus 816 an einen zweiten Bus 820 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 815, beispielsweise Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie beispielsweise Grafikbeschleuniger oder Digitalsignal-Verarbeitungseinheiten (Digital Signal Processing Units, DSPs)), feldprogrammierbare Gatteranordnungen oder ein beliebiger anderer Prozessor an den ersten Bus 816 gekoppelt. In einer Ausführungsform kann der zweite Bus 820 ein Bus mit geringer Stiftzahl (Low Pin Count, LPC) sein. Verschiedene Vorrichtungen können an einen zweiten Bus 820 gekoppelt sein, in einer Ausführungsform beispielsweise eine Tastatur und/oder eine Maus 822, Kommunikationsvorrichtungen 827 und eine Datenspeichereinheit 828 wie beispielsweise ein Plattenlaufwerk oder eine Massenspeichervorrichtung, die in einer Ausführungsform Befehle/Code und Daten 830 aufweisen kann. Ferner kann ein Audio-E/A 824 an den zweiten Bus 816 gekoppelt sein. Es sei darauf hingewiesen, dass auch andere Architekturen möglich sind. So kann ein System beispielsweise anstelle der Punkt-zu-Punkt-Architektur aus 8 einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.
Es wird nun Bezug genommen auf 9; gezeigt wird ein Blockschaltbild eines zweiten beispielhaften spezifischeren Systems 900 gemäß einer Ausführungsform der vorliegenden Erfindung. Gleiche Elemente in 8 und 9 tragen gleiche Bezugszeichen, und bestimmte Aspekte von 8 wurden in 9 ausgelassen, um zu verhindern, dass andere Aspekte von 9 verdeckt werden.
9 veranschaulicht, dass die Prozessoren 870, 880 einen integrierten Speicher und eine E/A-Steuerungslogik (Control Logic, „CL“) 972 bzw. 982 aufweisen können. Somit weist die CL 972, 982 integrierte Speichersteuerungseinheiten und eine E/A-Steuerlogik auf. 9 veranschaulicht, dass nicht nur die Speicher 832, 834 an die CL 872, 882 gekoppelt sind, sondern auch, dass die E/A-Vorrichtungen 914 ebenfalls an die Steuerungslogik 872, 882 gekoppelt sind. Bisherige E/A-Vorrichtungen 915 sind an den Chipsatz 890 gekoppelt.
Es wird nun Bezug genommen auf 10; gezeigt wird ein Blockschaltbild eines SoC 1000 gemäß einer Ausführungsform der vorliegenden Erfindung. Ähnliche Elemente in 6 tragen ähnliche Bezugszeichen. Außerdem sind Kästchen mit gestrichelten Linien optionale Merkmale bei fortschrittlicheren SoCs. In 10 ist (sind) (eine Verbindungseinheit(en) 1002 gekoppelt an: einen Anwendungsprozessor 1010, der einen Satz von einem oder mehreren Kernen 102A-N, Cache-Einheiten 604A-N und eine (mehrere) gemeinsam genutzte(n) Cache-Einheit(en) 606; eine Systemagenteneinheit 610; (eine) Bussteuerungseinheit(en) 616; (eine) integrierte Speichersteuerungseinheit(en) 614; einen Satz von einem oder mehreren Coprozessoren 1020, der integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor aufweisen kann; eine statische Direktzugriffsspeichereinheit (Static Random Access Memory, SRAM) 1030; eine Direktspeicherzugriffseinheit (Direct Memory Access, DMA) 1032; und eine Anzeigeeinheit 1040 für das Ankoppeln an eine oder mehrere externe Anzeigen aufweist. In einer Ausführungsform weist (weisen) der (die) Coprozessor(en) 1020 einen Spezialprozessor wie beispielsweise einen Netzprozessor oder einen Kommunikationsprozessor, eine Kompressionsmaschine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder dergleichen auf.
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware implementiert sein oder eine Kombination dieser Implementierungsansätze darstellen. Ausführungsformen der Erfindung können als Computerprogramme oder als Programmcode implementiert sein, die/der auf programmierbaren Systemen ausgeführt werden/wird, die wenigstens einen Prozessor, ein Speichersystem (mit flüchtigem und nichtflüchtigem Speicher und/oder Speicherelementen), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
Programmcode, beispielsweise der in 8 dargestellte Code 830, kann auf Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen angewendet werden. Für die Zwecke dieser Patentanmeldung umfasst ein Verarbeitungssystem ein beliebiges System, das über einen Prozessor verfügt, beispielsweise: einen digitalen Signalprozessor (Digital Signal Processor, DSP), eine Mikrosteuerung, eine anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit, ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer prozeduralen Hochsprache oder in einer objektorientierten Programmiersprache für das Kommunizieren mit einem Verarbeitungssystem implementiert sein. Der Programmcode kann auf Wunsch auch in Assembler- oder Maschinensprache implementiert sein. Tatsächlich sind die hier beschriebenen Mechanismen hinsichtlich des Schutzbereichs nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann es sich bei der Sprache um eine kompilierte oder eine interpretierte Sprache handeln.
Ein oder mehrere Aspekte von wenigstens einer Ausführungsform können durch repräsentative Befehle implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logiken im Prozessor repräsentiert, welche beim Auslesen durch eine Maschine bewirken, dass die Maschine Logik für das Durchführen der hier beschriebenen Verfahren erstellt. Derartige Darstellungen, bekannt als „IP-Kerne“, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und für verschiedene Kunden oder Herstellungseinrichtungen bereitgestellt werden, um in die Herstellungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich herstellen.
Solche maschinenlesbaren Speichermedien können ohne Einschränkung nichttransitorische, greifbare Anordnungen von durch eine Maschine oder Vorrichtung hergestellten oder gebildeten Gegenständen aufweisen, einschließlich Speichermedien wie Festplatten, jede andere Art von Platten, einschließlich Floppy-Disks, optische Platten, CD-ROMs, wiederbeschreibbare CD-ROMs und magneto-optische Platten, Halbleitervorrichtungen, wie Festspeicher (ROMs), Direktzugriffsspeicher (RAMs), wie dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare programmierbare Festwertspeicher (EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Festwertspeicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder irgendeine andere Art von Medien, die zur Speicherung elektronischer Befehle geeignet sind.
Demgemäß beinhalten Ausführungsformen der Erfindung auch nichttransitorische, greifbare maschinenlesbare Medien, die Befehle oder Ausführungsdaten enthalten, wie Hardwarebeschreibungssprache (HDL, Hardware Description Language), die hier beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
Emulation (einschließlich binärer Übersetzung, Codeumformung usw.)
In einigen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. So kann der Befehlsumwandler beispielsweise einen Befehl für das Verarbeiten durch den Kern in einen oder mehrere andere Befehle übersetzen (z. B. unter Verwendung einer statischen binären Übersetzung, einer dynamischen binären Übersetzung einschließlich einer dynamischen Kompilierung), umformen, emulieren oder sonstwie umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Der Befehlsumwandler kann prozessorintern, prozessorextern oder teilweise prozessorintern und teilweise prozessorextern sein.
11 ist ein Blockschaltbild, das die Verwendung eines Software-Befehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt. In der dargestellten Ausführungsform ist der Befehlsumwandler ein Software-Befehlsumwandler, wenngleich der Befehlsumwandler alternativ auch in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert sein kann. 11 zeigt, dass ein Programm in einer Hochsprache 1102 unter Verwendung eines ersten Compilers 1104 kompiliert werden kann, um einen ersten Binärcode (z. B. x86) 1106 zu erzeugen, der nativ durch einen Prozessor mit wenigstens einem ersten Befehlssatzkern 1116 ausgeführt werden kann. In einigen Ausführungsformen stellt der Prozessor mit wenigstens einem ersten Befehlssatzkern 1116 einen beliebigen Prozessor dar, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern durchführen kann, indem er (1) einen wesentlichen Abschnitt des Befehlssatzes des Intel x86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern ausgeführt werden sollen, auf kompatible Weise ausführt oder auf andere Weise verarbeitet, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern zu erzielen. Der erste Kompilierer 1104 stellt einen Kompilierer dar, der betreibbar ist, um Binärcode des ersten Befehlssatzes 1106 (z. B. Objektcode) zu erzeugen, der, mit oder ohne zusätzliche Verknüpfungsverarbeitung, auf dem Prozessor mit wenigstens einem ersten Befehlssatzkern 1116 ausgeführt werden kann. In ähnlicher Weise zeigt 11, dass das Programm in der höheren Sprache 1102 unter Verwendung eines alternativen Befehlssatz-Kompilierers 1108 kompiliert werden kann, um einen alternativen Befehlssatz-Binärcode 1110 zu erzeugen, der nativ durch einen Prozessor ohne wenigstens einen ersten Befehlssatzkern 1114 ausgeführt werden kann (z. B. einen Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA, USA, ausführen und/oder die den ARM-Befehlssatz von ARM Holdings in Sunnyvale, CA, USA, ausführen). Der Befehlsumwandler 1112 wird verwendet, um den ersten Binärcode 1106 in Code zu konvertieren, der nativ durch den Prozessor ohne einen ersten Befehlssatzkern 1114 ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht identisch mit dem alternativen Befehlssatz-Binärcode 1110, weil ein Befehlsumwandler, der hierzu in der Lage wäre, schwer herzustellen ist; allerdings wird der umgewandelte Code den allgemeinen Betrieb bewältigen und sich aus Befehlen aus dem alternativen Befehlssatz zusammensetzen. Somit stellt der Befehlsumwandler 1112 Software, Firmware, Hardware oder eine Kombination davon dar, die es, durch Emulation, Simulation oder ein anderes Verfahren, einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen ersten Befehlssatzprozessor oder -kern aufweist, ermöglicht, den ersten Binärcode 1106 auszuführen.
Einrichtung und Verfahren für Mehrfachlade- und Mehrfachspeicher-Vektorbefehle
Eine Ausführungsform der Erfindung umfasst einen Prozessor mit Schaltungen und/oder Logik zum Ausführen von Mehrfachladebefehlen, die in Reaktion auf einen einzigen Befehl mehrere Vektorregister mit gepackten Daten laden, sowie von Mehrfachspeicherbefehlen, die in Reaktion auf einen einzigen Befehl mehrere Vektorelemente aus mehreren Vektorregistern im Speichersubsystem speichern.
12 veranschaulicht einen beispielhaften Prozessor 1255, auf dem Ausführungsformen der Erfindung implementiert werden können und der mehrere Kerne 0-N zum gleichzeitigen Ausführen von mehreren Befehls-Threads aufweist. Die veranschaulichte Ausführungsform weist Mehrfachlade- und Mehrfachspeicher-Decodierschaltungen/- logik 1231 im Decodierer 1230 und Mehrfachlade- und Mehrfachspeicher-Ausführungsschaltungen/-logik 1341 in der Ausführungseinheit 1240 auf. In Reaktion auf die Ausführung dieser Befehle kann eine Speichersteuerungseinheit 1290 die zugrunde liegenden Lade-/Speicheroperationen implementieren, indem sie auf ein Speichersubsystem des Prozessors zugreift, das einen Systemspeicher 1200, einen Level-3-Cache 1216, der von den Kernen geteilt wird, und/oder andere Cache-Ebenen (z. B. L2-Cache 1211) aufweist. Diese Pipeline-Komponenten können die hierin beschriebenen Operationen in Reaktion auf das Decodieren und die Ausführung der Mehrfachlade- und Mehrfachspeicher-Befehle durchführen. Während in 12 nur Details eines Einzelkerns (Kern 0) gezeigt sind, versteht es sich, dass jeder der anderen Kerne von Prozessor 1255 ähnliche Komponenten einschließen kann.
Vor der Beschreibung konkreter Details der Ausführungsformen der Erfindung wird eine Beschreibung verschiedener anderer Komponenten des beispielhaften Prozessors 1255 bereitgestellt. Die mehreren Kerne 0-N können jeweils eine Speichersteuerungseinheit 1290 zum Durchführen von Speicheroperationen (z. B. Lade-/Speicheroperationen), einen Satz von Universalregistern (General Purpose Registers, GPRs) 1205, einen Satz von Vektorregistern 1206 und einen Satz von Maskenregistern 1207 aufweisen. In einer Ausführungsform werden mehrere Vektordatenelemente in jedes Vektorregister 1206 gepackt, das eine Breite von 512 Bit zum Speichern von zwei 256-Bit-Werten, vier 128-Bit-Werten, acht 64-Bit-Werten, sechzehn 32-Bit-Werten usw. aufweisen kann. Die zugrunde liegenden Prinzipien der Erfindung sind jedoch nicht auf eine bestimmte Größe/einen bestimmten Typ von Vektordaten beschränkt. In einer Ausführungsform weisen die Maskenregister 1207 acht 64-Bit-Operanden-Maskenregister auf, die zum Durchführen von Bit-Maskieroperationen bei den in den Vektorregistern 1206 gespeicherten Werten verwendet werden (z. B. als hierin beschriebene Maskenregister k0-k7 implementiert). Die zugrunde liegenden Prinzipien der Erfindung sind jedoch nicht auf eine bestimmte Größe/einen bestimmten Typ von Maskenregister beschränkt.
Jeder Kern 0-N kann einen dedizierten Level-1 (L1)-Cache 1212 und Level-2 (L2)-Cache 1211 zum Zwischenspeichern von Befehlen und Daten gemäß einer angegebenen Cache-Verwaltungsrichtlinie einschließen. In einer alternativen Ausführungsform wird jeder L2-Cache von zwei oder mehr Kernen geteilt. Der L1-Cache 1212 weist einen separaten Befehls-Cache 1220 zum Speichern von Befehlen und einen separaten Daten-Cache 1221 zum Speichern von Daten auf. Die in den verschiedenen Prozessor-Caches gespeicherten Befehle und Daten werden mit der Granularität von Cache-Zeilen verwaltet, die eine feste Größe (z. B. eine Länge von 64, 128, 512 Bytes) aufweisen können. Jeder Kern dieser beispielhaften Ausführungsform weist eine Befehlsabrufeinheit 1210 zum Abrufen von Befehlen aus dem Hauptspeicher 1200 und/oder einem gemeinsamen Level-3 (L3)-Cache 1216 auf. Die Befehlsabrufeinheit 1210 weist verschiedene hinlänglich bekannte Komponenten auf, einschließlich eines Folgebefehlszeigers 1203 zum Speichern der Adresse des nächsten Befehls, der aus dem Speicher 1200 (oder einem der Caches) abgerufen werden soll; eines Befehlsübersetzungspuffers (Instruction Translation Lookaside Buffer, ITLB) 1204 zum Speichern einer Karte von kürzlich verwendeten Virtuell-zu-physisch-Befehlsadressen, um die Geschwindigkeit der Adressübersetzung zu verbessern; einer Sprungvorhersageeinheit 1202 zum spekulativen Vorhersagen von Befehlssprungadressen; und Sprungzielpuffern (Branch Target Buffers, BTBs) 1201 zum Speichern von Sprungadressen und Zieladressen.
Wie bereits erwähnt, weist eine Decodiereinheit 1230 Mehrfachlade- und Mehrfachspeicher-Schaltungen/- Logik 1231 auf, um Mehrfachlade- und Mehrfachspeicherbefehle in Mikrooperationen oder „pops“ zu decodieren, und die Ausführungseinheit 1240 weist Mehrfachlade- und Mehrfachspeicherbefehl-Ausführungsschaltungen/-logik 1241 auf, um die pops auszuführen. In einigen Implementierungen ist die Speichersteuerungseinheit 1290 selbst in der Lage, die Befehle und/oder pops auszuführen, um die hier beschriebenen Verfahren durchzuführen. Eine Rückschreib-/Rückordnungseinheit 1250 ordnet die ausgeführten Befehle zurück und schreibt die Ergebnisse zurück.
In einer Implementierung lädt ein Mehrfachladebefehl mehrere Vektorregister mit einem einzigen Befehl, und ein Mehrfachspeicherbefehl speichert Datenelemente aus mehreren Vektorregistern mit einem einzigen Befehl. Der Begriff „Mehrfachlade/- speicherbefehl“ wird nachstehend gelegentlich verwendet, wenn Merkmale angesprochen werden, die für beide Befehle gelten. In einer Ausführungsform enthält ein Vektorindexregister mehrere gepackte Ganzzahlwerte, die als Indizes zum Laden und Speichern von Datenelementen verwendet werden. Beispielsweise können mit 512-Bit-Registern acht 32-Bit-Indizes oder sechzehn 16-Bit-Indizes gespeichert werden. In ähnlicher Weise können mit 256-Bit-Registern vier 32-Bit-Indizes oder acht 16-Bit-Indizes gespeichert werden. Während diese Werte zu Veranschaulichungszwecken bereitgestellt werden, sind die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Datenelementgröße oder Registergröße beschränkt.
Im Allgemeinen berechnet, wenn angenommen wird, dass im Indexvektorregister N Indizes gespeichert sind, eine Ausführungsform des Mehrfachlade/-speicherbefehls N effektive Adressen, indem jeder Index einer Basisadresse (die in einem Basisadressregister gespeichert ist) hinzugefügt wird. Anschließend lädt der Mehrfachladebefehl aufeinanderfolgende Elemente mit SIMD-Breite von jeder Adresse in N Vektorregister. Der Mehrfachspeicherbefehl ruft gepackte Daten aus jedem von N Vektorregistern ab und speichert die gepackten Daten an den N berechneten effektiven Adressen im Speicher (z. B. als N Sätze von aufeinanderfolgenden Datenelementen mit SIMD-Breite).
13 stellt eine Implementierung eines Mehrfachladebefehls dar, der ein Indexvektorregister, welches acht Indexwerte (A-H) speichert, ein Basisadressregister zum Speichern einer Basisadresse 1310, ein Maskenregister 1315 zum Speichern eines Maskenwertes und Mehrfachlade-Ausführungsschaltungen 1320 zum Ausführen des Mehrfachladebefehls aufweist. Insbesondere fügt die Mehrfachladeschaltung 1320 jeden Indexwert A-H der Basisadresse aus dem Basisadressregister 1310 hinzu, um effektive Adressen für 8 Sätze von aufeinanderfolgenden Datenelementen mit SIMD-Breite, die an verschiedenen Positionen des Speichersubsystems 1320 gespeichert sind, zu bestimmen. Der Mehrfachladebefehl weist auch einen Operanden auf, um den Satz von Vektorregistern zu identifizieren, in dem die Datenelemente gespeichert werden sollen. In 13 beispielsweise speichert VRA den Satz gepackter Datenelemente, der durch den Index A gekennzeichnet ist, VR_B speichert den Satz gepackter Datenelemente, der durch den Index B gekennzeichnet ist, und so weiter. Die Vektorregister VR_A bis VR_H können als aufeinanderfolgende Vektorregister in der Registerdatei gekennzeichnet sein oder können durch den Befehl einzeln identifiziert (und unzusammenhängend über die Registerdatei verteilt) sein.
Ein oder mehrere Maskenwerte können in einem oder mehreren Maskenregistern 1315 gespeichert sein, um verschiedene Maskierungsoperationen durchzuführen. Beispielsweise wird in einer Ausführungsform für einen ersten Maskenwert (z. B. 1) das entsprechende Element mit SIMD-Breite an die vorgesehene Position im entsprechenden Vektorregister geladen, und für einen zweiten Maskenwert (z. B. 0) werden Nullen an die Position im Vektorregister geladen. Somit wird in dieser Implementierung für jedes einzelne Element mit SIMD-Breite ein separates Bit in den Maskenregistern 1315 gespeichert. Anstatt Nullen an diese Position des Vektorregisters zu schreiben, können die aktuellen Werte im Vektorregister beibehalten werden (gelegentlich als „Zusammenführen-Maskieren“ bezeichnet). Verschiedene andere Formen des Maskierens können angewandt werden, um Datenelemente oder Gruppen von Datenelementen zu maskieren (wobei z. B. ein einzelnes Maskenbit N Datenelemente maskieren kann).
14 veranschaulicht eine Ausführungsform eines Mehrfachspeicherbefehls. Hier speichert das Indexvektorregister 1400 Indexwerte A-H, die Positionen im Speichersubsystem 1420 identifizieren, an die die Mehrfachspeicherschaltung 1420 Gruppen von Daten mit SIMD-Breite aus einer Gruppe von Vektorregistern VR_A-VR_H speichert. Beispielsweise werden die gepackten Datenelemente in VRA an die Speichersubsystemadresse kopiert, die durch Hinzufügen der Adresse im Basisadressregister 1410 zu dem Indexwert, der in Datenelement A im Indexvektorregister 1400 gespeichert ist, identifiziert ist. Die Mehrfachspeicherschaltung 1420 führt parallel und gleichzeitig Adressberechnungen für die anderen 7 Indexwerte durch (d. h., es werden Werte B-H zu dem Basisadressregisterwert hinzugefügt), um insgesamt 8 Adressen zu erzeugen, an die gepackte Datenelemente aus den Registern VRA-VRH kopiert werden. Die Maskenregister können in dieser Ausführungsform ggf. nicht genutzt werden, oder sie können wie in der Mehrfachladen-Ausführungsform oben verwendet werden.
Die Ausführungsformen der Erfindung, die hier beschrieben werden, ermöglichen es, mit einem einzigen Befehl mehrere Ströme aus dem Speicher zu laden, was die Belastung der Register verringert und unnötige Adressierungsoperationen eliminiert, wodurch bisherige Einschränkungen bei der Bereitstellung einer optimalen Prozessorleistung überwunden werden. Diese Ausführungsformen können auch dazu beitragen, dass Codes SoA- oder AoSoA-Datenlayouts verwenden, indem die zum Laden von Daten erforderlichen Frontend-Schlitze reduziert werden, welche dann für andere Befehle genutzt werden können.
In einer Ausführungsform werden die Mehrfachladebefehle und Mehrfachspeicherbefehle gemäß folgendem Befehlsformat angegeben:

vmultiload[type][esize][mask] output_registers, base_address, index_vector, mask
vmultistore[type][esize][mask] input_registers, base_address, index_vector, mask

In diesem Beispiel gibt [type] den Typ der Ganzzahlen (z. B. Bytes, Wörter, Doppelwörter, Vierfachwörter etc.) der Elements im Indexvektorregister 1400 (z. B. Elemente A-H in 13-14) an, [esize] gibt Typ und Größe der Elemente an, die in die Vektorregister geladen werden sollen (z. B. einfach genaue Gleitkommawerte, Doppelwort-Ganzzahlen etc.), und [mask] zeigt an, wie maskierte Elemente zu füllen sind (z. B. Null-Füllen, Zusammenführen-Füllen etc.).
Die Variablen output_registers, base_address und index_vector spezifizieren die jeweils zu benutzenden Vektorregister für Quelle oder Ziel der Anweisung. Dies könnte lediglich ein einzelnes Register sein (und die übrigen könnten implizit bestimmt sein als die darauf folgenden Register in der Vektorregisterdatei) oder könnte eine Codierung sein, die eine explizite Auflistung von Vektorregistern erlaubt.
Es ist zu beachten, dass die Ausführungsformen der Erfindung nicht auf eine bestimmte Teilmenge oder Reihenfolge von Suffixen, eine bestimmte Art und Weise der Beschreibung von Eingangs-/Ausgangsregistern oder ein bestimmtes Format des Befehls beschränkt sind. Für jede spezifische Kombination erzeugt eine Ausführungsform der vmultiload-Befehle Operationen gemäß dem nachstehenden Pseudo-Code:

 vector_list = Liste der Ausgangsvektorregister
 nvectors = Anzahl der Elemente in vector_list
 für (v = 0; v < nvectors; v++)
 {
 wenn (mask[v])
 vload[esize] vector_list[v], base_address+index_vector[v]
 ansonsten, wenn ([mask])
 fülle vector_list[v] wie durch [mask] angegeben
 }

Somit kann gemäß diesem Code, wenn ein bestimmtes Element in der Vektorliste maskiert ist (z. B. lautet der entsprechende Maskenwert 1), der Zielvektor dann gemäß der Maske aktualisiert werden (z. B. mit Nullen etc.). Andersherum wird, wenn der Maskenwert keine Maskierung anzeigt, das Vektorelement, das durch base address + index vector identifiziert ist, geladen.

In ähnlicher Weise wird eine Ausführungsform des vmultistore-Befehls folgenden Pseudo-Code implementieren:

 vector_list = Liste der Eingangsvektorregister
 nvectors = Anzahl der Elemente in vector_list
 für (v = 0; v < nvectors; v++) 



 {
 wenn (mask[v])
 vstore[esize] base_address+index_vector[v], vector_list[v]
 }

Hier werden gepackte Daten, die in der Liste der Vektorregister gespeichert sind, unter Verwendung der base address + index vector-Komponente, die jedem Vektorregister zugeordnet ist, in den Systemspeicher geladen.

Die hier beschriebenen Ausführungsformen sind nicht auf eine bestimmte Mikroarchitektur-Implementierung beschränkt. Insbesondere können die Lade- und/oder Speichervorgänge simultan in denselben Zyklen oder in verschiedenen Zyklen oder in einer beliebigen Reihenfolge erfolgen; dabei können Überlappungen zwischen verschiedenen Strömen auftreten; und die Speicheradressen müssen nicht synchronisiert sein.

Als konkreteres Beispiel könnte für einfach genaue Gleitkomma-Elemente mit 64-Bit-Indizes und impliziter Aufzählung der Eingangs-/Ausgangsregister der Mehrfachladebefehl wie folgt lauten (z. B. unter Verwendung einer AVX-512-Implementierung):

 vmultiload64ps erstes Register, Basisadresse,
 Indexvektor, Maske
 so dass:
 k0=00010101
 r10=&a
 zmm30 = [100, 0, 200, 0, 300, 0, 0, 0]

Beispielsweise laden vmultiloadps zmm0, r10, zmm30, k0 in zmm0 die Werte aus a[100] bis a[115], in zmm2 die Werte von a[200] bis a[215], in zmm4 die Werte von a[300] bis a[315].

Ein Verfahren gemäß einer Ausführungsform der Erfindung ist in 15 veranschaulicht. Das Verfahren kann im Kontext der vorstehend beschriebenen Prozessor- und Systemarchitekturen implementiert werden, ist jedoch nicht auf eine bestimmte Systemarchitektur beschränkt.

Bei 1501 wird ein Mehrfachladebefehl abgeholt, der Felder für einen Opcode, Quelloperanden und Zieloperanden aufweist. Bei 1502 wird der Mehrfachladebefehl decodiert, um einen decodierten Mehrfachladebefehl zu erzeugen. In einer Ausführungsform umfasst der decodierte Befehl mehrere Laden-Mikrooperationen wie hier beschrieben. Bei 1503 werden die Daten, die mit den Quelloperanden verknüpft sind, abgerufen und in den Quellregistern gespeichert. Darüber hinaus werden die Operationen der decodierten Befehle geplant.

Bei 1504 werden die Operationen ausgeführt, wobei die Basisadresse aus einem ersten Quellregister jedem von N Indexwerten aus einem zweiten Quellregister hinzugefügt wird, um N Systemspeicheradressen zu erzeugen, die N Sätze von Datenelementen im Systemspeicher identifizieren. Beispielsweise sind in einer Ausführungsform die Quellregister gepackte 512-Bit-Datenregister, die acht gepackte 64-Bit-Datenwerte oder sechzehn gepackte 32-Bit-Datenwerte speichern. Die zugrunde liegenden Prinzipien der Erfindung sind jedoch nicht auf eine bestimmte Register- oder Datenelementgröße beschränkt.

Bei 1505 werden die Operationen des decodierten Befehls ausgeführt, um N Sätze von Datenelementen von den N Systemspeicheradressen in N Zielregister zu speichern. Wie bereits erwähnt, werden die N Zielregister ebenfalls durch den Mehrfachladebefehl identifiziert.

Ein Verfahren gemäß einer Ausführungsform der Erfindung ist in 16 veranschaulicht. Das Verfahren kann im Kontext der vorstehend beschriebenen Prozessor- und Systemarchitekturen implementiert werden, ist jedoch nicht auf eine bestimmte Systemarchitektur beschränkt.

Bei 1601 wird ein Mehrfachspeicherbefehl abgeholt, der Felder für einen Opcode und Quelloperanden aufweist. Bei 1602 wird der Mehrfachspeicherbefehl decodiert, um einen decodierten Mehrfachspeicherbefehl zu erzeugen. In einer Ausführungsform umfasst der decodierte Befehl mehrere Speichern-Mikrooperationen wie hier beschrieben. Bei 1603 werden die Daten, die mit den Quelloperanden verknüpft sind, abgerufen und in den Quellregistern gespeichert. Darüber hinaus werden die Operationen der decodierten Befehle geplant.

Bei 1604 werden die Operationen ausgeführt, wobei die Basisadresse aus einem ersten Quellregister jedem von N Indexwerten aus einem zweiten Quellregister hinzugefügt wird, um N Systemspeicheradressen zu erzeugen. Beispielsweise sind in einer Ausführungsform die Quellregister gepackte 512-Bit-Datenregister, die acht gepackte 64-Bit-Datenwerte oder sechzehn gepackte 32-Bit-Datenwerte speichern. Die zugrunde liegenden Prinzipien der Erfindung sind jedoch nicht auf eine bestimmte Register- oder Datenelementgröße beschränkt.

Bei 1605 werden die Operationen des decodierten Befehls ausgeführt, um N Sätze von Datenelementen aus den N Quellregistern an den N Systemspeicheradressen im Systemspeicher zu speichern. Wie bereits erwähnt, werden die N Quellregister ebenfalls durch den Mehrfachladebefehl identifiziert.

Wenngleich die Operationen in 15 und 16 eine bestimmte Reihenfolge aufweisen, können eine oder mehrere dieser Operationen in einer anderen als der dargestellten Reihenfolge durchgeführt werden. Weiterhin können gewisse Operationen (z. B. etwa 1504-1505 und 1604-1605) der Ausführungsformen gleichzeitig statt in der bestimmten Reihenfolge wie in diesen Figuren dargestellt ausgeführt werden.

In der vorstehenden Beschreibung wurden die Ausführungsformen der Erfindung Bezug nehmend auf spezifische beispielhafte Ausführungsformen davon beschrieben. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom allgemeineren Wesen und Schutzbereich der Erfindung wie in den beigefügten Ansprüchen dargelegt abzuweichen. Die Beschreibung und die Zeichnungen sind dementsprechend in einem veranschaulichenden und nicht in einem einschränkenden Sinne zu betrachten.

Ausführungsformen der Erfindung können verschiedene Schritte beinhalten, die vorstehend beschrieben wurden. Die Schritte können in maschinenausführbaren Befehlen ausgeführt sein, die verwendet werden können, um einen Universal- oder Spezialprozessor zum Durchführen der Schritte zu veranlassen. Alternativ dazu können diese Schritte durch spezifische Hardwarekomponenten, die festverdrahtete Logik zum Durchführen der Schritte enthalten, oder durch eine beliebige Kombination programmierter Computerkomponenten und angepasster Hardwarekomponenten durchgeführt werden.

Wie hierin beschrieben, können sich Befehle auf spezifische Konfigurationen von Hardware, wie etwa anwendungsspezifische integrierte Schaltungen (Application Specific Integrated Circuits, ASICs), die dafür ausgelegt sind, bestimmte Operationen durchzuführen, oder die eine vorher festgelegte Funktionalität aufweisen, oder auf Softwarebefehle, die in einem Speicher gespeichert sind, der in einem nichttransitorischen computerlesbaren Medium ausgeführt ist, beziehen. Somit können die in den Figuren gezeigten Verfahren unter Verwendung von Code und Daten implementiert sein, die auf einer oder mehreren elektronischen Vorrichtungen (z. B. einer Endstation, einem Netzelement usw.) gespeichert sind und ausgeführt werden. Diese elektronischen Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netz) Code und Daten unter Verwendung von computermaschinenlesbaren Medien, wie nichttransitorischen computermaschinenlesbaren Speichermedien (z. B. Magnetplatten; optische Platten; Direktzugriffsspeicher; Festwertspeicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und transitorische computermaschinenlesbare Kommunikationsmedien (z. B. elektrische, optische, akustische oder eine andere Form propagierter Signale - wie Trägerwellen, Infrarotsignale, digitale Signale usw.). Außerdem weisen diese elektronischen Vorrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren, die an eine oder mehrere andere Komponenten, wie eine oder mehrere Speichervorrichtungen (nichttransitorische maschinenlesbare Speichermedien), Benutzereingabe/- ausgabevorrichtungen (z. B. eine Tastatur, ein Berührungsschirm und/oder eine Anzeige), gekoppelt sind, und Netzverbindungen auf. Das Koppeln des Satzes von Prozessoren und anderen Komponenten erfolgt typischerweise durch eine/n oder mehrere Busse und Brücken (auch als Bussteuerungen bezeichnet). Die Speichervorrichtung und die Signale, die den Netzverkehr tragen, stellen ein oder mehrere maschinenlesbare Speichermedien bzw. maschinenlesbare Kommunikationsmedien dar. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieser elektronischen Vorrichtung. Selbstverständlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung anderer Kombinationen von Software, Firmware und/oder Hardware implementiert werden. Über diese gesamte ausführliche Beschreibung hinweg wurden zur Erläuterung zahlreiche konkrete Details dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu schaffen. Es ist jedoch für den Fachmann ersichtlich, dass die Erfindung ohne einige dieser spezifischen Details ausgeführt werden kann. In gewissen Fällen wurden hinlänglich bekannte Strukturen und Funktionen nicht in allen Einzelheiten beschrieben, um zu vermeiden, dass der Gegenstand der vorliegenden Erfindung unklar wird. Demnach sollten der Schutzbereich und das Wesen der Erfindung nach den folgenden Patentansprüchen bewertet werden.

Claims

Prozessor, umfassend: einen Decodierer zum Decodieren eines Mehrfachladebefehls zum Erzeugen eines decodierten Mehrfachladebefehls, der mehrere Operationen umfasst, wobei der Mehrfachladebefehl einen Opcode, Quelloperanden und wenigstens einen Zieloperanden aufweist; ein erstes Quellregister zum Speichern von N gepackten Indexwerten; ein zweites Quellregister zum Speichern eines Basisadresswertes; eine Ausführungsschaltung zum Ausführen der Operationen des decodierten Mehrfachladebefehls, wobei die Ausführungsschaltung umfasst: eine Schaltung für parallele Adresserzeugung, um die Basisadresse aus dem zweiten Quellregister mit jedem der N gepackten Indexwerte zu kombinieren, um N Systemspeicheradressen zu erzeugen; eine Datenladeschaltung, um zu bewirken, dass N Sätze von Datenelementen von den N Systemspeicheradressen abgerufen werden, wobei die Datenladeschaltung die N Sätze von Datenelementen in N Vektorzielregistern speichert, die durch wenigstens einen Zieloperanden identifiziert sind.
Prozessor nach Anspruch 1, wobei das erste Quellregister ein Vektorregister umfasst, um N gepackte 16-Bit-, 32-Bit- oder 64-Bit-Ganzzahlwerte zu speichern, wobei jeder der Ganzzahlwerte einen Indexwert umfasst.
Prozessor nach Anspruch 1, wobei N den Wert 8, 16 oder 32 hat und wobei jeder Satz von Datenelementen 8, 16 oder 32 Datenelemente umfasst.
Prozessor nach Anspruch 1 oder 2, wobei die Schaltung für parallele Adresserzeugung die Basisadresse aus dem zweiten Quellregister jedem der N gepackten Indexwerte hinzufügt, um N Systemspeicheradressen zu erzeugen.
Prozessor nach Anspruch 1 oder 4, ferner umfassend: eine Speichersteuerungseinheit, die mit dem Systemspeicher und der Datenladeschaltung gekoppelt ist, wobei die Speichersteuerungseinheit das Abrufen der N Sätze von Datenelementen von den N Systemspeicheradressen in Reaktion auf die Datenladeschaltung durchführt.
Prozessor nach Anspruch 1 oder 5, wobei wenigstens ein Zieloperand ein Vektorregister identifiziert und die übrigen N-1 Register implizit bestimmt sind als die darauf folgenden Register in der Vektorregisterdatei.
Prozessor nach Anspruch 1 oder 6, ferner umfassend: ein Maskenregister zum Speichern von mehreren Maskenbits, wobei die Datenladeschaltung eine Maskierschaltung umfasst, um zu bestimmen, ob ein Datenelement aus jedem der N Sätze von Datenelementen an eine Datenelementposition in einem der Zielregister geschrieben werden soll, basierend auf einem Maskenbit, das dem Datenelement zugeordnet ist.
Prozessor nach Anspruch 7, wobei, wenn das Maskenbit anzeigt, dass das Datenelement maskiert ist, die Datenladeschaltung einen 0-Wert an die Datenelementposition schreibt oder keinerlei Wert an die Datenelementposition schreibt.
Verfahren, umfassend: Decodieren eines Mehrfachladebefehls zum Erzeugen eines decodierten Mehrfachladebefehls, der mehrere Operationen umfasst, wobei der Mehrfachladebefehl einen Opcode, Quelloperanden und wenigstens einen Zieloperanden aufweist; Speichern von N gepackten Indexwerten in einem ersten Quellregister; Speichern eines Basisadresswertes in einem zweiten Quellregister; Ausführen der Operationen des decodierten Mehrfachladebefehls, wobei die Operationen beinhalten: Kombinieren der Basisadresse aus dem zweiten Quellregister mit jedem der N gepackten Indexwerte, um N Systemspeicheradressen zu erzeugen; Abrufen von N Sätzen von Datenelementen von den N Systemspeicheradressen; und Speichern der N Sätze von Datenelementen in N Vektorzielregistern, die durch wenigstens einen Zieloperanden identifiziert sind.
Verfahren nach Anspruch 9, wobei das erste Quellregister ein Vektorregister umfasst, um N gepackte 16-Bit-, 32-Bit- oder 64-Bit-Ganzzahlwerte zu speichern, wobei jeder der Ganzzahlwerte einen Indexwert umfasst.
Verfahren nach Anspruch 9, wobei N den Wert 8, 16 oder 32 hat und wobei jeder Satz von Datenelementen 8, 16 oder 32 Datenelemente umfasst.
Verfahren nach Anspruch 9 oder 10, wobei die Schaltung für parallele Adresserzeugung die Basisadresse aus dem zweiten Quellregister jedem der N gepackten Indexwerte hinzufügt, um N Systemspeicheradressen zu erzeugen.
Verfahren nach Anspruch 9 oder 12, wobei das Abrufen der N Sätze von Datenelementen umfasst, die N Systemspeicheradressen an eine Speichersteuerungseinheit zu senden und die N Sätze von Datenelementen von der Speichersteuerungseinheit zu empfangen.
Verfahren nach Anspruch 9 oder 13, wobei der wenigstens eine Zieloperand ein Vektorregister identifiziert und die übrigen N-1 Register implizit bestimmt sind als die darauf folgenden Register in der Vektorregisterdatei.
Verfahren nach Anspruch 9 oder 14, ferner umfassend: Speichern mehrerer Maskenbits in einem Maskenregister; und Bestimmen, ob ein Datenelement aus jedem der N Sätze von Datenelementen an eine Datenelementposition in einem der Zielregister geschrieben werden soll, basierend auf einem Maskenbit, das dem Datenelement zugeordnet ist.
Verfahren nach Anspruch 15, wobei, wenn das Maskenbit anzeigt, dass das Datenelement maskiert ist, ein 0-Wert an die Datenelementposition geschrieben wird oder keinerlei Wert an die Datenelementposition geschrieben wird.
Maschinenlesbares Medium mit darauf gespeichertem Programmcode, der bei Ausführung durch eine Maschine die Maschine dazu veranlasst, die folgenden Operationen durchzuführen: Decodieren eines Mehrfachladebefehls zum Erzeugen eines decodierten Mehrfachladebefehls, der mehrere Operationen umfasst, wobei der Mehrfachladebefehl einen Opcode, Quelloperanden und wenigstens einen Zieloperanden aufweist; Speichern von N gepackten Indexwerten in einem ersten Quellregister; Speichern eines Basisadresswertes in einem zweiten Quellregister; Ausführen der Operationen des decodierten Mehrfachladebefehls, wobei die Operationen beinhalten: Kombinieren der Basisadresse aus dem zweiten Quellregister mit jedem der N gepackten Indexwerte, um N Systemspeicheradressen zu erzeugen; Abrufen von N Sätzen von Datenelementen von den N Systemspeicheradressen; und Speichern der N Sätze von Datenelementen in N Vektorzielregistern, die durch wenigstens einen Zieloperanden identifiziert sind.
Maschinenlesbares Medium nach Anspruch 17, wobei das erste Quellregister ein Vektorregister umfasst, um N gepackte 16-Bit-, 32-Bit- oder 64-Bit-Ganzzahlwerte zu speichern, wobei jeder der Ganzzahlwerte einen Indexwert umfasst.
Maschinenlesbares Medium nach Anspruch 17, wobei N den Wert 8, 16 oder 32 hat und wobei jeder Satz von Datenelementen 8, 16 oder 32 Datenelemente umfasst.
Maschinenlesbares Medium nach Anspruch 17 oder 18, wobei die Schaltung für parallele Adresserzeugung die Basisadresse aus dem zweiten Quellregister jedem der N gepackten Indexwerte hinzufügt, um N Systemspeicheradressen zu erzeugen.
Maschinenlesbares Medium nach Anspruch 17 oder 20, wobei das Abrufen der N Sätze von Datenelementen umfasst, die N Systemspeicheradressen an eine Speichersteuerungseinheit zu senden und die N Sätze von Datenelementen von der Speichersteuerungseinheit zu empfangen.
Maschinenlesbares Medium nach Anspruch 17 oder 21, wobei der wenigstens eine Zieloperand ein Vektorregister identifiziert und die übrigen N-1 Register implizit bestimmt sind als die darauf folgenden Register in der Vektorregisterdatei.
Maschinenlesbares Medium nach Anspruch 17 oder 22, ferner Programmcode umfassend, der die Maschine dazu veranlasst, die folgenden Operationen durchzuführen: Speichern mehrerer Maskenbits in einem Maskenregister; und Bestimmen, ob ein Datenelement aus jedem der N Sätze von Datenelementen an eine Datenelementposition in einem der Zielregister geschrieben werden soll, basierend auf einem Maskenbit, das dem Datenelement zugeordnet ist.
Maschinenlesbares Medium nach Anspruch 23, wobei, wenn das Maskenbit anzeigt, dass das Datenelement maskiert ist, ein 0-Wert an die Datenelementposition geschrieben wird oder keinerlei Wert an die Datenelementposition geschrieben wird.
Prozessor, umfassend: einen Decodierer zum Decodieren eines Mehrfachspeicherbefehls zum Erzeugen eines decodierten Mehrfachspeicherbefehls, der mehrere Operationen umfasst, wobei der Mehrfachspeicherbefehl einen Opcode und Quelloperanden aufweist; ein erstes Quellregister zum Speichern von N gepackten Indexwerten; ein zweites Quellregister zum Speichern eines Basisadresswertes; eine Ausführungsschaltung zum Ausführen der Operationen des decodierten Mehrfachspeicherbefehls, wobei die Ausführungsschaltung umfasst: eine Schaltung für parallele Adresserzeugung, um die Basisadresse aus dem zweiten Quellregister mit jedem der N gepackten Indexwerte zu kombinieren, um N Systemspeicheradressen zu erzeugen; eine Datenspeicherschaltung, um die N Sätze von Datenelementen aus N Vektorquellregistern an die N Systemspeicheradressen zu kopieren.