DE112012007058T5

DE112012007058T5 - Vektormaskengesteuertes Clock-Gating für Leistungseffizenz eines Prozessors

Info

Publication number: DE112012007058T5
Application number: DE112012007058.5T
Authority: DE
Inventors: Jesus Corbal; Dennis R. Bradford; Jonathan C. Hall; Thomas D. Fletcher; Brian J. Hickmann; Dror Markovich; Amit Gradstein
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-12-19
Filing date: 2012-12-19
Publication date: 2015-08-06
Also published as: CN104813277B; CN104813277A; WO2014098845A1; US10133577B2; US20150220345A1

Abstract

Ein Prozessor umfasst eine Befehlsplanungs- und Versand-(Planungs-/Versand-)Einheit zum Empfangen eines Single-Instruction-Multiple-Data-(SIMD-)Befehls, um eine Operation auf vielen Datenelementen durchzuführen, die in einer von einem ersten Quelloperanden angezeigten Speicherposition gespeichert sind. Die Befehlsplanungs- und Versandeinheit soll ein erstes der Datenelemente bestimmen, das nicht betätigt wird, um ein Ergebnis zu erzeugen, das basierend auf einem zweiten Quelloperanden in einen Zieloperanden geschrieben wird. Der Prozessor umfasst zudem zahlreiche Verarbeitungselemente, die mit der Befehlsplanungs- und Versandeinheit gekoppelt sind, um die Datenelemente des SIMD-Befehls auf Vektorart zu verarbeiten, und eine mit der Befehlsplanungs- und Versandeinheit gekoppelte Leistungsverwaltungseinheit, um den Energieverbrauch eines ersten der Verarbeitungselemente, die zum Bearbeiten des ersten Datenelements konfiguriert sind, zu reduzieren.

Description

TECHNISCHES GEBIET
Ausführungsformen der vorliegenden Erfindung betreffen Mikroprozessoren im Allgemeinen. Insbesondere betreffen Ausführungsformen der vorliegenden Erfindung die Energieverwaltung eines Mikroprozessors.
HINTERGRUND
Energieverbrauch ist ein wichtiges Anliegen bei modernen elektronischen und prozessorbasierten Vorrichtungen. In den vergangenen Jahren wurde die Verwendung von Laptops und Notebooks für die mobile Computernutzung alltäglich. Darüber hinaus umfassen viele der heutigen mobilen Vorrichtungen eine Funktionalität als Standardfunktion, so dass der Benutzer auf seine E-Mails zugreifen, Computerspiele spielen oder auf das Internet zugreifen kann, während er unterwegs ist. In all diesen Beispielen ist die elektronische Vorrichtung auf eine endliche Energiequelle, wie etwa eine Batterie, angewiesen. Somit ist das Reduzieren des Energieverbrauchs und somit das Steigern der Lebensdauer der Batterie ein wichtiger Faktor bei der Platzierung eines Produkts, das für den Markt attraktiv und somit wirtschaftlich profitabel ist.
Ein Ansatz um den Energieverbrauch bei einer prozessorbasierten Vorrichtung zu reduzieren, ist den Energieverbrauch des Prozessors zu reduzieren. Eine häufige Technik ist, ungenutzte Funktionsblöcke innerhalb des Prozessors zu deaktivieren, basierend auf der Operation oder dem Operationssatz, der zu einem bestimmten Zeitpunkt ausgeführt wird. Darüber hinaus ist der Prozess zum Aktivieren und Deaktivieren von Funktionsblöcken grundsätzlich dynamisch, da die Blöcke aktiviert sein sollten, um keine Wartezeit bei der Verarbeitung einzuführen, und dennoch rasch deaktivierbar sein sollten, um übermäßigen Stromverbrauch zu minimieren.
Fortschrittlichere Prozessoren, wie etwa die Advanced-Vector-Extensions-Prozessoren (AVX-Prozessoren) von Intel können Single-Instruction-Multiple-Data-Befehle (SIMD-Befehle) auf Vektorart ausführen. Manche der Befehle führen basierend auf einem Maskenoperanden Operationen auf mehreren Datenelementen durch. 1 ist ein Blockdiagramm, das Vektorausführungsregeln veranschaulicht. Beispielsweise führt der Befehl VADDPS ZMM1 {k1}, ZMM2, ZMM3 bis zu 16 Einzelpräzisions-(SP-)Additionsoperationen über 32-Bit-Elemente von Daten innerhalb von 512-Bit-Registern durch, alles gleichzeitig. Die Maske k1 ist ein 16-Bit-Register, von dem jedes Bit sich auf jedes in dem Vektorbefehl zu verarbeitende Datenelement bezieht. Wenn das Maskenbit eins ist, wird das Datenelement verarbeitet und an den Zielort gespeichert. Wenn das Maskenbit null ist, schreibt der Prozessor entweder null oder lässt den Zielort unverändert (abhängig von dem Schreibmaskenmodus). Bei Hardware werden alle 16 Elemente stets innerhalb der arithmetisch logischen Einheit (ALU) des Vektors als Einzeleinheit bearbeitet. Leider kommt es zu einem Verlust an Energieeffizienz, da ein Prozentsatz der innerhalb der Vektor-ALU durchgeführten Operationen verworfen werden wird, da das ihnen zugeordnete Maskenbit auf null gesetzt werden kann. 2 ist Pseudocode, der ein Beispiel für maskengesteuerte AVX-Operationen zeigt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Ausführungsformen der Erfindung werden in den Figuren der beiliegenden Zeichnungen, in denen dieselben Bezugszeichen ähnliche Elemente bezeichnen, beispielhaft und nicht einschränkend veranschaulicht.
1 ist ein Blockdiagramm, das Vektorausführungsregeln veranschaulicht.
2 ist Pseudocode, der ein Beispiel für maskengesteuerte AVX-Operationen veranschaulicht.
3 ist ein Blockdiagramm einer Ausführungspipeline eines Prozessors oder Prozessorkerns gemäß einer Ausführungsform der Erfindung.
4 ist ein Blockdiagramm, das Operationen eines maskengesteuerten SIMD-Befehls gemäß einer Ausführungsform der Erfindung veranschaulicht.
5 ist ein Blockdiagramm, das einen Prozessor oder Prozessorkern gemäß einer anderen Ausführungsform der Erfindung veranschaulicht.
6 ist ein Flussdiagramm, das ein von einem Prozessor gemäß einer Ausführungsform der Erfindung durchgeführtes Verfahren veranschaulicht.
7A veranschaulicht ein beispielhaftes Advanced-Vector-Extension-Befehlsformat (AVX-Befehlsformat) gemäß einer Ausführungsform der Erfindung.
7B veranschaulicht ein beispielhaftes Advanced-Vector-Extension-Befehlsformat (AVX-Befehlsformat) gemäß einer anderen Ausführungsform der Erfindung.
7C veranschaulicht ein beispielhaftes Advanced-Vector-Extension-Befehlsformat (AVX-Befehlsformat) gemäß einer anderen Ausführungsform der Erfindung.
8A ist ein Blockdiagramm, das ein allgemeines vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon gemäß Ausführungsformen der Erfindung veranschaulicht.
8B ist ein Blockdiagramm, das ein allgemeines vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse B davon gemäß Ausführungsformen der Erfindung veranschaulicht.
9A ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß einer Ausführungsform der Erfindung veranschaulicht.
9B ist ein Blockdiagramm, das ein allgemeines vektorfreundliches Befehlsformat gemäß einer anderen Ausführungsform der Erfindung veranschaulicht.
9C ist ein Blockdiagramm, das ein allgemeines vektorfreundliches Befehlsformat gemäß einer anderen Ausführungsform der Erfindung veranschaulicht.
9D ist ein Blockdiagramm, das ein allgemeines vektorfreundliches Befehlsformat gemäß einer anderen Ausführungsform der Erfindung veranschaulicht.
10 ist ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Erfindung.
11A ist ein Blockdiagramm, das sowohl eine beispielhafte reihenfolgegebundene Pipeline und eine beispielhafte reihenfolgelose Registerumbenennungs-, Ausgabe-/Ausführungs-Pipeline gemäß einer Ausführungsform der Erfindung zeigt.
11B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines reihenfolgegebundenen Architekturkerns und eines beispielhaften reihenfolgelosen Registerumbenennungs-, Ausgabe-/Ausführungs-Architekturkerns für die Integration in einen Prozessor gemäß einer Ausführungsform der Erfindung zeigt.
12A ist ein Blockdiagramm eines Prozessorkerns gemäß einer Ausführungsform der Erfindung.
12B ist ein Blockdiagramm eines Prozessorkerns gemäß einer anderen Ausführungsform der Erfindung.
13 ist ein Blockdiagramm eines Prozessors gemäß Ausführungsformen der Erfindung.
14 ist ein Blockdiagramm eines Systems in Übereinstimmung mit einer Ausführungsform der Erfindung.
15 ist ein Blockdiagramm eines spezielleren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der Erfindung.
16 ist ein Blockdiagramm eines spezielleren beispielhaften Systems in Übereinstimmung mit einer anderen Ausführungsform der Erfindung.
17 ist ein Blockdiagramm eines SoC in Übereinstimmung mit einer Ausführungsform der Erfindung.
18 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlsumwandlers zur Umwandlung von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz veranschaulicht.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Verschiedene Ausführungsformen und Aspekte der Erfindung werden mit Bezug auf nachstehend erörterte Details beschrieben und die beiliegenden Zeichnungen werden die verschiedenen Ausführungsformen veranschaulichen. Die folgende Beschreibung und Zeichnungen dienen zur Veranschaulichung der Erfindung und sollen nicht als die Erfindung einschränkend verstanden werden. Zahlreiche spezifische Details werden beschrieben, um ein tiefgreifendes Verständnis verschiedener Ausführungsformen der Erfindung zu ermöglichen. Jedoch werden in manchen Fällen wohlbekannte oder herkömmliche Details nicht beschrieben, um die Diskussion von Ausführungsformen der vorliegenden Erfindung kurz zu halten.
Der Verweis in der Beschreibung auf „eine Ausführungsform” oder „einer Ausführungsform” bedeutet, dass ein bestimmtes in Zusammenhang mit der Ausführungsform beschriebenes Merkmal, Struktur oder Eigenschaft in zumindest einer Ausführungsform umfasst sein kann. Das Auftreten der Phrase „in einer Ausführungsform” an verschiedenen Stellen der Beschreibung bezieht sich nicht notwendigerweise immer auf dieselbe Ausführungsform.
Gemäß manchen Ausführungsformen können Maskenwerte eines SIMD-Befehls verwendet werden, um zu bestimmen, ob ein bestimmtes Datenelement von einer entsprechenden ALU, die einen Wert an einen Zielort schreiben wird, verarbeitet werden wird. Wenn bestimmt ist, dass das Datenelement nicht verarbeitet werden wird, kann der Energieverbrauch der entsprechenden Vektorbahn (z. B. ein Verarbeitungselement, das das Datenelement verarbeitet, einschließlich ALU, Registerdatei, Datenbusversandpfad, Rückschreibepfad in einer Ruhestandseinheit etc.) reduziert oder abgeschaltet werden.
In einer Ausführungsform können die Maskenwerte am Beginn des Versands eines Vektorbefehls gelesen werden, so dass Clock-Gating auf Datenelementebene innerhalb der Vektor-ALU-Pipeline durchgeführt werden kann, um eine dynamische Energieverschwendung aufgrund von unnötigen Bitschaltungen von Werten auf Datenelementen die am Zielort nicht aktualisiert werden. Das Clock-Gating kann auf eine Vielzahl von Pipelinestufen, einschließlich Vektorregisterlesen, Datenbusversand, Shuffle und Datentransformation, ALU-Ausführung und Rückschreiben etc., angewandt werden.
3 ist ein Blockdiagramm eines Prozessors oder Prozessorkerns gemäß einer Ausführungsform der Erfindung. Bezugnehmend auf 3 kann der Prozessor 100 jede Art von Befehlsverarbeitungsgerät oder Verarbeitungselemente darstellen. Ein Verarbeitungselement bezieht sich auf einen Thread, einen Prozess, einen Kontext, einen logischen Prozessor, einen Hardware-Thread, einen Kern und/oder ein beliebiges Verarbeitungselement, das Zugriff auf andere gemeinsam genutzte Ressourcen des Prozessors, wie etwa Reservierungseinheiten, Ausführungseinheiten, Pipelines und höherrangige Caches/Speicher teilt. Ein physikalischer Prozessor bezieht sich üblicherweise auf einen integrierten Schaltkreis, der potentiell eine beliebige Anzahl anderer Verarbeitungselemente, wie etwa Kerne oder Hardware-Threads, umfasst. Ein Kern betrifft häufig Logik, die sich auf einem integrierten Schaltkreis befindet und in der Lage ist, einen unabhängigen Architekturzustand aufrecht zu erhalten, wobei jeder unabhängig aufrecht erhaltene Architekturzustand mit zumindest manchen gewidmeten Ausführungsressourcen zugeordnet wird. In einer Ausführungsform kann der Prozessor 100 ein Allzweckprozessor sein. Der Prozessor 100 kann ein beliebiger aus verschiedenen Complex-Instruction-Set-Computing-Prozessoren (CISC-Prozessoren), verschiedenen Reduced-Instruction-Set-Computing-Prozessoren (RISC-Prozessoren), verschiedenen Very-Long-Instruction-Word-Prozessoren (VLIW-Prozessoren), verschiedenen Hybriden davon oder eine gänzlich andere Art von Prozessoren sein.
Prozessorkerne können auf verschiedene Weisen für verschiedene Zwecke und in verschiedenen Prozessoren umgesetzt sein. Beispielsweise können Implementierungen solcher Kerne umfassen: 1) einen reihenfolgegebundenen Allzweck-Kern für allgemeine Rechenleistungen; 2) einen reihenfolgelosen Hochleistungs-Allzweck-Kern für allgemeine Rechenleistungen; 3) einen Spezialkern, der speziell für Grafik und/oder wissenschaftliche (Durchsatz-)Rechenleistung vorgesehen ist. Implementierungen verschiedener Prozessoren können umfassen: 1) eine CPU, die einen oder mehrere reihenfolgegebundene Allzweck-Kerne für allgemeine Rechenleistungen und/oder einen oder mehrere reihenfolgelose Allzweck-Kerne für allgemeine Rechenleistungen umfasst; und 2) einen Co-Prozessor, der einen oder mehrere Spezialkerne umfasst, die hauptsächlich für Grafik und/oder wissenschaftliche Zwecke (Durchsatz) vorgesehen sind. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computer-Systemarchitekturen, die folgendes umfassen können: 1) den Co-Prozessor auf einem von der CPU getrennten Chip; 2) den Co-Prozessor auf einem separaten Nacktchip im selben Gehäuse wie eine CPU; 3) den Co-Prozessor auf demselben Nacktchip wie eine CPU (in welchem Fall ein solcher Co-Prozessor manchmal als Sonderzweck-Logik bezeichnet wird, wie etwa integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik, oder als Sonderzweck-Kerne); und 4) ein System auf einem Chip, das die beschriebene CPU auf demselben Nacktchip umfassen kann (manchmal als der/die Anwendungskerne) oder Anwendungsprozessor(en) bezeichnet, der oben beschriebene Co-Prozessor und zusätzliche Funktionalität). Beispielhafte Kernarchitekturen werden als nächstes beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computer-Architekturen.
In einer Ausführungsform umfasst der Prozessor 100, ohne darauf beschränkt zu sein, eine Befehlsabrufeinheit 101, einen Befehlsdekodierer 102, einen Umbenenner/Zuweiser 103, einen Planer/Versender 104, eine oder mehrere Ausführungseinheiten 105 und eine Ruhestandseinheit 106, die eine Prozessorpipeline ausbilden. Eine Pipeline oder ein Abschnitt einer Pipeline, wie etwa ein Vorderenden- oder Befehlsdekodierabschnitt 102 der Pipeline können von mehreren Threads gemeinsam genutzt werden. Architekturzustandsregister (nicht gezeigt) sind repliziert, so dass einzelne Architekturzustände/-kontexte in der Lage sind, für verschiedene logische Prozessoren gespeichert zu werden. Andere kleinere Ressourcen, wie etwa Befehlszeiger und Umbenennungslogik in der Umbenennungs-Zuweisungs-Logik 103 können auch für die Threads repliziert werden. Manche Ressourcen, wie etwa Reorganisationspuffer in einer Reorganisations-/Ruhestandseinheit 106, Lade-/Speicherpuffer und Warteschlangen können durch Partitionierung gemeinsam genutzt werden. Während Ressourcen, wie etwa interne Allzweckregister (z. B. Register 108), seitentabellenbasierte Register, ein niederrangiger Datencache (z. B. Cache 107) und der Datenübersetzungspuffer (TLB), Ausführungseinheit(en) 104 und eine reihenfolgelose Einheit (nicht gezeigt) potentiell vollständig gemeinsam genutzt werden können.
In einer Ausführungsform soll der Befehlsdekodierer 102 die von der Befehlsabrufeinheit 101 empfangenen Befehle dekodieren. Die Befehle können Makrobefehle sein, die aus einem Cachespeicher 107, der ein integraler Bestandteil des Prozessors 100 oder diesem eng zugeordnet ist, abgerufen wurden, oder können von einem externen Speicher über einen Systembus abgefragt werden. Der Befehlsdekodierer 102 kann die Makrobefehle dekodieren und eine oder mehrere Mikrooperationen, Mikrocode, Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Kontrollsignale, die die Befehle widerspiegeln oder davon hergeleitet sind, erzeugen oder ausgeben. Der Befehlsdekodierer 102 kann unter Verwendung einiger verschiedener Mechanismen umgesetzt sein. Beispiele für geeignete Mechanismen umfassen, ohne darauf beschränkt zu sein, Mikrocode-Festwertspeicher (ROM), Übersichtstabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (PLA) und dergleichen.
In einer Ausführungsform umfasst die Zuweisungs- und Umbenennungseinheit 103 einen Zuweiser für die Reservierung von Ressourcen, wie etwa Registerdateien, um Befehlsverarbeitungsergebnisse zu speichern. Jedoch ist ein Thread potentiell zu einer reihenfolgelosen Ausführung fähig, wenn die Zuweisungs- und Umbenennungseinheit auch andere Ressourcen, wie etwa Reorganisationspuffer zum Nachverfolgen von Befehlsergebnissen, reserviert. Sie kann auch einen Registerumbenenner zum Umbenennen von Programm-Befehls-Referenzregistern auf andere prozessorinterne Register umfassen. Während einer solchen Umbenennungsphase können Verweise auf externe oder logische Register in interne oder physikalische Registerverweise umgewandelt werden, um durch die Registerwiederverwendung verursachte Abhängigkeiten zu eliminieren.
Die Planungs- und Versandeinheit 104 soll Befehle Planen und für die Ausführung an Ausführungseinheiten 105 versenden. Tatsächlich sind Befehlen/Operationen potentiell auf Ausführungseinheiten 105 gemäß ihrer Typverfügbarkeit geplant. Beispielsweise wird ein Gleitkommabefehl auf einem Anschluss einer Ausführungseinheit, der eine verfügbare Gleitkommaausführungseinheit aufweist, geplant. Beispiele für Ausführungseinheiten umfassen eine Gleitkommaausführungseinheit, eine Integerausführungseinheit, eine Sprungausführungseinheit, eine Ladeausführungseinheit, eine Speicherausführungseinheit und andere bekannte Ausführungseinheiten.
Ausführungseinheiten 105, die eine arithmetisch logische Einheit oder eine andere Art von Logikeinheit, die in der Lage ist, Operationen basierend auf Befehlen auszuführen, umfassen können. In Folge dessen, dass der Befehlsdekodierer 102 die Befehle dekodiert, kann die Ausführungseinheit 105 eine oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale, die die Befehle widerspiegeln oder von diesen hergeleitet sind, empfangen. Die Ausführungseinheit 105 kann infolge von Befehlen, die einen oder mehrere Quelloperanden (SRC) anzeigen, betätigbar sein und ein Ergebnis in einen oder mehrere Zieloperanden (DEST) eines von den Befehlen angegebenen Registersatzes speichern. Die Ausführungseinheit 105 kann Schaltungen oder eine andere Ausführungslogik (z. B. Software, die mit Hardware und/oder Firmware kombiniert ist) umfassen, die für die Ausführung von Befehlen und anderen von den Befehlen stammenden Steuersignalen und die dementsprechende Durchführung einer Operation betätigbar sind. Die Ausführungseinheit 105 kann jede Art von Ausführungseinheiten, wie etwa Logik-Einheiten, arithmetisch logische Einheiten (ALU), Arithmetik-Einheiten, Integer-Einheiten etc. darstellen.
In einer Ausführungsform umfasst die Reorganisations-/Ruhestandseinheit 105 Bestandteile, wie etwa die oben erwähnten Reorganisationspuffer, Ladepuffer und Speicherpuffer, um eine reihenfolgelose Ausführung und später eine reihenfolgegebundene Ruhestellung von außerhalb der Reihenfolge ausgeführten Befehlen zu unterstützen.
Manche oder alle der Quell- und Zieloperanden können in Speicherressourcen 108, wie etwa Registern eines Registersatzes oder eines Speichers, gespeichert werden. Ein Registersatz kann Teil einer Registerdatei sein, potentiell zusammen mit anderen Registern, wie etwa Statusregistern, Flagregistern etc. Ein Register kann eine Speicherposition oder eine Vorrichtung, die zum Speichern von Daten verwendet werden kann, sein. Der Registersatz kann sich häufig physisch auf einem Nacktchip mit der/den Ausführungseinheit(en) befinden. Die Register können von der Außenseite des Prozessors oder aus der Perspektive eines Programmierers sichtbar sein. Beispielsweise können Befehle in den Registern gespeicherte Operanden spezifizieren. Mehrere verschiedene Arten von Registern sind geeignet, solange sie fähig sind, Daten wie hierin beschrieben zu speichern und bereitzustellen. Die Register können gegebenenfalls umbenannt werden. Beispiele für geeignete Register umfassen, ohne darauf beschränkt zu sein, zweckgewidmete physikalische Register, dynamisch zugewiesene physikalische Register mittels Registerumbenennung, Kombinationen aus zweckgewidmeten und dynamisch zugewiesenen physikalischen Registern etc. Alternativ dazu können ein oder mehrere der Quell- und Zieloperanden in einer Speicherposition, die kein Register ist, wie etwa beispielsweise einer Position in einem Systemspeicher, gespeichert werden.
In einer Ausführungsform umfasst der Cache 107 eine Vielzahl von Caches, wie etwa einen hochrangigen und/oder niederrangigen Cache. Höherrangige Caches und weiter draußen liegende Caches dienen dazu, unlängst abgerufene und/oder bearbeitete Elemente zwischenzuspeichern. Es wird angemerkt, dass sich höherrangig oder weiter draußen liegend auf Caches bezieht, deren Rang sich erhöht oder die weiter weg von der/den Ausführungseinheit(en) liegen. In einer Ausführungsform ist der höherrangige Cache ein Datencache der zweiten Ebene. Jedoch ist der höherrangige Cache nicht so beschränkt, da er ein Befehlscache sein oder einen umfassen kann, der auch als Spurcache bezeichnet werden kann. Ein Spurcache kann stattdessen nach einem Dekodierer gekoppelt werden, um unlängst dekodierte Befehle zu speichern. Er umfasst unter Umständen einen Abzweigungszielpuffer. um Abzweigungen, die ausgeführt oder genommen werden sollen, vorherzusagen, und einen Befehlsübersetzungspuffer (I-TLB), um Adressübersetzungseinträge für Befehle zu speichern.
Niederrangige Datencaches und Datenübersetzungspuffer (D-TLB) können mit (einer) Ausführungseinheit(en) gekoppelt sein. Der Datencache dient dazu, unlängst verwendete/bearbeitete Elemente, wie etwa Datenoperanden, zu speichern, die unter Umständen in Speicherkohärenzzuständen, wie etwa den Zuständen modifiziert, exklusiv, gemeinsam genutzt und ungültig (MESI) gehalten werden. Der D-TLB dient dazu, neue Übersetzungen von virtuellen/linearen zu physikalischen Adressen zu speichern. Zuvor umfasste ein D-TLB-Eintrag eine physische Adresse und andere Information, wie etwa einen Offset, um kostengünstige Übersetzungen für kürzlich verwendete virtuelle Speicheradressen bereitzustellen.
Der Prozessor 100 umfasst zudem eine Busschnittstelleneinheit (nicht gezeigt). Eine Busschnittstelleneinheit dient zur Kommunikation mit Vorrichtungen, die außerhalb eines Prozessors liegen, wie etwa einem Systemspeicher, einem Chipsatz, einer Northbridge oder einer anderen integrierten Schaltung. Der Speicher kann für den Prozessor zweckgewidmet sein oder mit anderen Vorrichtungen in einem System gemeinsam genutzt werden. Beispiele für den Speicher umfassen dynamische Direktzugriffsspeicher (DRAM), statische RAM (SRAM), nichtvolatile Speicher (NV-Speicher und Langzeitspeicher. Üblicherweise umfasst die Busschnittstelleneinheit Eingangs-/Ausgangspuffer (I/O-Puffer), um Bussignale auf einer Verbindung zu übertragen und empfangen. Beispiele für die Verbindung umfassen einen Gunning-Transceiver-Logic-Bus (GTL-Bus), einen GTL+-Bus, einen Double-Data-Rate-Bus (DDR-Bus), einen gepumpten Bus, einen differenziellen Bus, einen Cache-kohärenten Bus, einen Punkt-zu-Punkt-Bus, einen Multidrop-Bus oder andere Verbindungen, die ein beliebiges bekanntes Busprotokoll umsetzen. Die Busschnittstelleneinheit kann auch mit einem höherrangigen Cache kommunizieren.
In einer Ausführungsform können die verschiedenen oben beschriebenen Stufen in drei Phasen organisiert werden. Die erste Phase kann als ein reihenfolgegebundenes Vorderende inklusive der Abrufstufe 101, Dekodierstufe 102, Zuweisungs-Umbenennungsstufe 103 bezeichnet werden. Während der reihenfolgegebundenen Vorderendenphase fahren die Befehle durch die Pipeline 100 in ihrer ursprünglichen Programmreihenfolge fort. Die zweite Phase kann als die reihenfolgelose Ausführungsphase inklusive der Planungs-/Versandstufe 104 und der Ausführungsstufe 105 bezeichnet werden. Während dieser Phase kann jeder Befehl geplant, versendet und ausgeführt werden, sobald seine Datenabhängigkeiten gelöst wurden und die Ausführungseinheit verfügbar ist, unabhängig von seiner sequentiellen Position im ursprünglichen Programm. Die dritte Phase, die als reihenfolgegebundene Ruhestandsphase bezeichnet wird und die Ruhestandsstufe 106 umfasst, in Befehle in ihrer originalen, sequenziellen Programmreihenfolge ruhiggestellt werden, um die Integrität und die Semantik des Programmes zu erhalten und ein präzises Unterbrechungsmodell bereitzustellen.
Bezugnehmend wiederum auf 3 umfasst der Planer/Versender 104 in einer Ausführungsform eine Detektionslogik für inaktive Elemente 120, um etwaige der vielen Datenelemente in Operanden 112 eines SIMD-Befehls zu detektieren, die nicht von Vektorbearbeitungseinheiten (VPU) 111 bearbeitet werden und/oder deren Ergebnis nicht an eine Zielspeicherposition geschrieben werden. Solch ein Datenelement wird als ein inaktives Datenelement bezeichnet. Datenelemente eines SIMD-Befehls können von mehreren Verarbeitungselementen auf eine Vektorart verarbeitet werden. Das inaktive Datenelement oder die inaktiven Datenelemente werden in einem Bezeichner für inaktive Elemente 113 angegeben, die in einem Register oder einer Speicherposition gespeichert werden können. In einer Ausführungsform soll die Energieverwaltungseinheit 114 basierend auf dem Bezeichner für inaktive Elemente 113 den Energieverbrauch des/der Verarbeitungselements/-elemente entsprechend dem/den inaktiven Datenelement(en) reduzieren. In einer Ausführungsform soll die Energieverwaltungseinheit 114 die Taktfrequenz reduzieren oder das Taktsignal an eine Verarbeitungseinheit, die einem jeden inaktiven Datenelement entspricht, abschalten. Ein Verarbeitungselement kann eine Kombination aus einer oder mehreren ALU, einer Registerdatei, Datenbusversandpfad, Rückschreibepfad in einer Ruhestandseinheit etc. sein. Es wird angemerkt, dass der Detektor für inaktive Elemente 120 auch in einem aus der Befehlsabrufeinheit 101, dem Befehlsdekodierer 102 und/oder der Umbenennungs-/Zuweisungseinheit 103 umgesetzt sein kann.
In einer Ausführungsform untersucht der Detektor für inaktive Elemente 120 den SIMD-Befehl, um zu bestimmen, welche der mehreren Datenelemente des SIMD-Befehls nicht bearbeitet werden und/oder deren Ergebnisse nicht an einen Zielort geschrieben werden. Insbesondere kann der Detektor für inaktive Elemente 120 einen Operanden des Befehls untersuchen, um das/die inaktive(n) Datenelement€ zu bestimmen. Beispielsweise untersucht der Detektor für inaktive Elemente 120 bei einem Befehl wie etwa VADDPS ZMM1, {k1}, ZMM2, ZMM3, der ein maskengesteuerter Befehl für die Vektoraddition ist, einen Operanden, um zu bestimmen, welche der Datenelemente inaktiv sind. In diesem Beispiel soll der VADDPS-Befehl entsprechende Datenelemente, die in den Quelloperanden ZMM2 und ZMM3 basierend auf der Maske k1 gespeichert sind, addieren und die Additionsergebnisse an den Zielort ZMM1 speichern. In dieser speziellen Ausführungsform untersucht der Detektor unabhängiger Elemente 120 die Maske „k1”, um zu bestimmen, welche der Datenelemente in ZMM2 und ZMM3 nicht bearbeitet und nicht in das Zielregister ZMM1 geschrieben werden. Für diese inaktiven Elemente werden die inaktiven Angaben in einem Bezeichner für inaktive Elemente 113 gespeichert. Die Energieverwaltungseinheit 114 reduziert dann den Energieverbrauch des entsprechenden Verarbeitungselements oder der Vektorbahn, basierend auf dem Bezeichner für inaktive Elemente 113.
4 ist ein Blockdiagramm, das Operationen eines maskengesteuerten SIMD-Befehls gemäß einer Ausführungsform der Erfindung veranschaulicht. Bezugnehmend auf 4 umfasst ein SIMD-Befehl in diesem Beispiel einen ersten Quelloperanden 401 und einen zweiten Quelloperanden 402, der basierend auf der Maske 403 von der Verarbeitungsressource 404 verarbeitet werden soll. Insbesondere umfasst der Quelloperand 401 mehrere Datenelemente 411–414, während der Quelloperand 402 die Datenelemente 421–424 umfasst. Die Datenelemente 411–414 werden mit entsprechenden der Datenelemente 421–424 von den Verarbeitungselementen 441–444 basierend auf den Maskenbits 431–434 verarbeitet. Die Ergebnisse werden in entsprechenden Zielspeicherpositionen (nicht gezeigt) gespeichert. Jedes der Maskenbits weist einen logischen Wert von eins oder null auf, um anzugeben, ob die entsprechenden Datenelemente als inaktive Datenelemente bearbeitet werden. Eine solche Anzeigeinformation wird als Teil des Bezeichners für inaktive Elemente 113 gespeichert. Der Bezeichner für inaktive Elemente 113 wird dann von Clock-Gate-Logiken 451–454 verwendet, um den Energieverbrauch der Verarbeitungselemente 441 bis 444 zu konfigurieren. Beispielsweise, wenn das Maskenbit einen logischen Wert von eins aufweist, werden das Datenelement 412 und das Datenelement 422 vom Verarbeitungselement 442 verarbeitet. Jedoch, wenn das Maskenbit 433 einen logischen Wert null aufweist, werden das Datenelement 413 und das Datenelement 423 vom Verarbeitungselement 443 nicht verarbeitet und das Ergebnis wird nicht an einen entsprechenden Zielort geschrieben. In solch einer Situation kann die Energie oder das Taktsignal an das Verarbeitungselement 443 reduziert oder abgeschaltet werden, um den Gesamtenergieverbrauch des Prozessors zu reduzieren.
5 ist ein Blockdiagramm, das einen Prozessor oder Prozessorkern gemäß einer anderen Ausführungsform der Erfindung veranschaulicht. Der Prozessor 500 kann als Teil des Prozessors 100 aus 3 umgesetzt sein. Bezugnehmend auf 5, wenn der Planer 502 Opcodes eines SIMD-Befehls aus der Ausführungswarteschlange 501 empfängt, untersucht der Planer 502 die Operanden (z. B. die Maske) um die auf null gestellten Anzeiger der Quell- und Zieloperanden, die angeben, welche der Datenelemente inaktive Elemente sind. Insbesondere bestimmt der Planer 502 die inaktiven Elemente und markiert sie über den Pfad 506 im Register der nullgesetzten Bezeichner (RZI) 504. Ein Multi-Pump-Multiplexer (MPM) 509 wird verwendet, um einen Anschluss der physikalischen Registerdatei (PRF) 503 für die Ausführung durch die Ausführungseinheit 505 auszuwählen, beispielsweise wenn die Ausführungsbreite geringer als die Registerbreite ist. In dem speziellen Fall der Multi-Pump-Vektor-Verarbeitungsimplementierung mit geringer Breite wird der 502 redundante Pumpoperationen sparen, falls zusammenhängende Zielelemente auf null gesetzt werden. Wenn nur wenige Elemente auf null gesetzt werden, können die zu den auf null gesetzten Elementen passenden Vektorbahnen Clock-Gating unterzogen werden können, beispielsweise über Pfad 507. Beispiele für das Vorhersagen von Nullelementen können SUB/ADD mit beiden Nullquellen, MUL mit zumindest einer Nullquelle und Datenbewegungen mit einer Nullquelle umfassen.
Somit wird jedes Element am gepackten Register markiert, ob es einen Nullwert oder einen Nichtnullwert aufweist und Überprüfungen über den Pfad 508 vor dem Einplanen von Operationen auf dem Zielelement sollten im Voraus null sein. Im Fall einer Nullvorhersage wird der Elementwert nicht mit Hilfe der regulären Ausführung berechnet und wird im Voraus als null markiert. Dieses Schema spart Energieverbrauch, weil der Nullwert nicht berechnet wird und kann Ausführungszyklen bei der Multi-Pump-Mikroarchitektur sparen, falls eine oder einige Ausführungsphasen nicht erforderlich sind. Compiler, die gepackte Opcodes für skalare Berechnungen nutzen, benutzen üblicherweise nur das am wenigsten signifikante Byteelement (LSB) des gepackten Registers; somit wurde bei Multi-Pump die Ausführung aller höheren Abschnitte eingespart.
6 ist ein Flussdiagramm, das ein von einem Prozessor durchgeführtes Verfahren gemäß einer Ausführungsform der Erfindung veranschaulicht. Verfahren 600 kann durch die Verarbeitung von Logik, die Hardware, Software oder eine Kombination daraus umfassen kann, durchgeführt werden. Beispielsweise kann das Verfahren 600 vom Prozessor 100 aus 3 durchgeführt werden. Bezugnehmend auf 6 bei Block 601 empfängt die Verarbeitungslogik einen Befehl mit mehreren Quelloperanden, die jeweils mehrere zu verarbeitende Datenelemente aufweisen (z. B. SIMD-Befehl). Bei Block 602 untersucht die Verarbeitungslogik einen der Operanden, um zu bestimmen, welche der Datenelemente verarbeitet werden sollen. Bei Block 603 reduziert die Verarbeitungslogik basierend auf der Untersuchung den Energieverbrauch von einem oder mehreren Verarbeitungselementen, die keine Datenelemente verarbeiten oder eine Nullausgabe an einen Zielort schreiben sollen. Bei Block 604 wird der Befehl dann geplant und an die Verarbeitungselemente zur Ausführung versandt.
Ein Befehlssatz oder eine Befehlssatzarchitektur (ISA) ist der Teil der Computerarchitektur, die sich auf die Programmierung bezieht, und kann die nativen Datentypen, Befehle, Registerarchitektur, Adressmodi, Speicherarchitektur, Handhabung von Unterbrechungen und Ausnahmen und externe Eingabe und Ausgabe (I/O) umfassen. Der Begriff Befehl betrifft hierin im Allgemeinen Makrobefehle – das hießt Befehle, die dem Prozessor (oder Befehlsumwandler, der einen Befehl in einen oder mehrere vom Prozessor zu verarbeitende andere Befehle übersetzt (z. B. mittels statischer Binärübersetzung, dynamischer Binärübersetzung einschließlich dynamischer Kompilierung), morpht, emuliert oder anderweitig umwandelt) für die Ausführung bereitgestellt werden – im Gegensatz zu Mikrobefehlen oder Mikrooperationen (Mikro-Ops) – die das Ergebnis eines Prozessordekodierers, der Makrobefehle dekodiert, sind.
Die ISA wird von der Mikroarchitektur, die das interne Design des den Befehlssatz implementierenden Prozessors ist, unterschieden. Prozessoren mit unterschiedlichen Mikroarchitekturen können einen gemeinsamen Befehlssatz nutzen. Beispielsweise implementieren Intel^® Pentium 4 Prozessoren, Intel^® Core^TM-Prozessoren und Prozessoren von Advanced Micro Devices, Inc. Aus Sunnyvale, Kalifornien, nahezu identische Versionen des x86-Befehlssatzes (mit einigen Erweiterungen, die im Zuge neuerer Versionen hinzugefügt werden, haben aber unterschiedliche interne Designs. Beispielsweise kann dieselbe Registerarchitektur der ISA auf verschiedene Weisen in verschiedenen Mikroarchitekturen mittels wohlbekannter Verfahren, einschließlich zweckgewidmeter physikalischer Register, einem oder mehreren dynamisch zugewiesenen physikalischen Register mit Hilfe eines Registerumbenennungsmechanismus (z. B. die Verwendung einer Register-Alias-Tabelle (RAT), einem Reorganisationspuffer (ROB) und einer Ruhestandsregisterdatei; die Verwendung mehrerer Karten und einem Registerpool), etc., implementiert werden. Sofern nicht anders festgelegt werden die Phrasen Registerarchitektur, Registerdatei und Register hierin verwendet, um zu bezeichnen, was für die Software/den Programmierer sichtbar ist und die Art, auf die Befehle Register spezifizieren. Wenn Spezifität gewünscht ist, wird der Zusatz logisch, Architektur- oder Software-sichtbar verwendet, um Register/Dateien in der Registerarchitektur anzugeben, während andere Adjektive für Zielregister in einer gegebenen Mikroarchitektur verwendet werden (z. B. physikalisches Register, Reorganisationspuffer, Ruhestandsregister, Registerpool).
Ein Befehlssatz umfasst ein oder mehrere Befehlsformate. Ein gegebenes Befehlsformat definiert verschiedene Felder (Anzahl von Bits, Position der Bits), um unter anderem der durchzuführenden Operation (Opcode) und den/die Operanden, auf die die Operation anzuwenden ist, zu spezifizieren. Manche Befehlsformate werden durch die Definition von Befehlsvorlagen (oder Unterformaten) weiter aufgegliedert. Beispielsweise kann eine Befehlsvorlage eines bestimmten Befehlsformats als verschiedene Untergruppen der Felder des Befehlsformats aufweisend definiert werden (die umfassten Felder sind üblicherweise in derselben Reihenfolge aber zumindest manche weisen andere Bitpositionen auf, weil weniger Felder umfasst sind) und/oder als ein gegebenes Feld unterschiedlich interpretierend definiert werden. Somit wird jeder Befehl einer ISA mit Hilfe eines gegebenen Befehlsformats ausgedrückt (und, falls definiert, in einer gegebenen der Befehlsvorlagen dieses Befehlsformats) und umfasst Felder um Spezifizieren der Operation und der Operanden. Beispielsweise weist ein beispielhafter ADD-Befehl einen spezifischen Opcode und ein Befehlsformat auf, das ein Opcode-Feld umfasst, um diesen Opcode und Operandenfelder zu spezifizieren, um Operanden (Quelle1/Ziel und Quelle2) auszuwählen; und ein Vorkommen dieses ADD-Befehl in einem Befehlsstrom wird spezifische Inhalte in den Operandenfeldern aufweisen, die spezifische Operanden auswählen.
Wissenschaftliche, finanzielle, auto-vektorisierte Allzweck-, RMS (Erkennung, Suchen und Synthese) und visuelle und Multimediaanwendungen (z. B. 2D-/3D-Graphiken, Bildbearbeitung, Videokompression/-dekompression, Spracherkennungsalgorithmen und Audiomanipulation) erfordern häufig, dass dieselbe Operation auf eine großen Anzahl von Dateneinheiten angewandt wird (wird als „Datenparallelismus” bezeichnet). Single Instruction Multiple Data (SIMD) bezieht sich auf einen Befehlstyp, der dazu führt, dass ein Prozessor eine Operation auf mehrere Dateneinheiten anwendet. SIMD-Technologie ist besonders für Prozessoren geeignet, die die Bits in einem Register logisch in eine Anzahl von Datenelementen mit festgelegter Größe einteilen können, wobei jedes davon einen eigenen Wert darstellt. Beispielsweise können die Bits in einem 256-Bit-Register als ein Quelloperand spezifiziert werden, der als vier separate 64-Bit-gepackte Datenelemente (Vier-Wort-große (Q) Datenelemente), acht separate 32-Bit-gepackte Datenelemente (Doppel-wort-große (D) Datenelemente), sechzehn separate 16-Bit-Datenelemente (Wort-große (W) Datenelemente) oder zweiunddreißig getrennte 8-Bit-Datenelemente (Byte-große (B) Datenelemente) bearbeitet werden soll. Dieser Datentyp wird als gepackter Datentyp oder Vektordatentyp bezeichnet und Operanden von diesem Datentyp werden als gepackte Datenoperanden oder Vektoroperanden bezeichnet. In anderen Worten bezeichnet eine gepackte Dateneinheit oder Vektor eine Sequenz von gepackten Datenelementen und ein gepackter Datenoperand oder ein Vektoroperand ist ein Quelle- oder Zieloperand eines SIMD-Befehls (auch bekannt als ein gepackter Datenbefehl oder Vektorbefehl).
So spezifiziert zum Beispiel ein Typ eines SIMD-Befehls eine einzelne Vektoroperation, der auf zwei Quellvektoroperanden auf vertikale Weise durchgeführt werden soll, um einen Zielvektoroperand (auch bezeichnet als ein Ergebnisvektoroperand) derselben Größe, mit derselben Anzahl an Datenelementen und in derselben Datenelementreihenfolge, zu erzeugen. Die Datenelemente in den Quellvektoroperanden werden als Quelldatenelemente bezeichnet, während die Datenelemente im Zielvektoroperanden als Ziel- oder Ergebnisdatenelemente bezeichnet werden. Diese Quellvektoroperanden sind von derselben Größe und enthalten Datenelemente derselben Breite, weswegen sie dieselbe Anzahl an Datenelementen enthalten. Die Quelldatenelemente in denselben Bitpositionen in den zwei Quellvektoroperanden bilden Datenelementpaare (auch bezeichnet als entsprechende Datenelemente; das heißt, die Datenelemente an Datenelementposition 0 eines jeden Quelloperanden entsprechen einander, die Datenelemente an Datenelementposition 1 eines jeden Quelloperanden entsprechen einander und so weiter). Die von dem SIMD-Befehl spezifizierte Operation wird getrennt auf jedem dieser Paare von Quelldatenelementen durchgeführt, um eine passende Anzahl von Ergebnisdatenelementen zu erzeugen und somit hat jedes Paar von Quelldatenelementen ein entsprechendes Ergebnisdatenelement. Da die Operation vertikal ist und da der Ergebnisvektoroperand dieselbe Größe hat, dieselbe Anzahl an Datenelementen aufweist und die Ergebnisdatenelemente in derselben Datenelementreihenfolge wie die Quellvektoroperanden gespeichert sind, befinden sich die Ergebnisdatenelementen an denselben Bitpositionen des Ergebnisvektoroperanden wie ihr entsprechendes Paar von Quelldatenelementen in den Quellvektoroperanden. Zusätzlich zu diesem beispielhaften Typ von SIMD-Befehl gibt es eine Vielzahl von anderen Typen von SIMD-Befehlen (z. B. einer, der nur einen oder mehr als zwei Quellvektoroperanden aufweist, die in horizontaler Weise arbeiten, der einen Ergebnisvektoroperanden einer unterschiedlichen Größe, der Datenelemente einer anderen Größe aufweist und/oder eine andere Datenelementreihenfolge hat, erzeugt). Es versteht sich, dass der Begriff Zielvektoroperand (oder Zieloperand) als das direkte Ergebnis der Durchführung der von einem Befehl spezifizierten Operation definiert wird, einschließlich der Speicherung dieses Zieloperanden an einer Position (sei es ein Register oder an einer von diesem Befehl spezifizierten Speicheradresse), so dass er von einem anderen Befehl (durch Spezifikation derselben Position durch einen anderen Befehl) als Quelloperand zugegriffen werden kann.
Die SIMD-Technologie, wie sie von Intel^® Core^TM Prozessoren mit einem Befehlssatz, der x86, MMX^TM, Streaming SIMD Extensions (SSE), SSE2, SSE3, SSE41 und SSE42 Befehle umfasst, verwendet wird, ermöglichte eine signifikante Verbesserung des Leistungsverhaltens von Anwendungen. Ein zusätzlicher Satz von SIMD-Erweiterungen, die als die Advanced Vector Extensions (AVX (AVX1 und AVX2) bezeichnet werden und das Vector-Extensions-(VEX-)Kodierschema verwenden, wurde freigegeben und/oder veröffentlicht (z. B. siehe Intel^® 64 und IA-32 Architectures Software Developers Manual, Oktober 2011; und siehe Intel^® Advanced Vector Extensions Programmierreferenz, Juni 2011).
Ausführungsformen des/der hierin beschriebenen Befehls/Befehle können in verschiedenen Formaten verkörpert sein. Zusätzlich dazu werden nachfolgend beispielhafte Systeme, Architekturen und Pipelines im Detail beschrieben. Ausführungsformen des/der Befehls/Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf die beschriebenen beschränkt.
VEX-Kodierung erlaubt Befehlen mehr als zwei Operanden zu haben und erlaubt SIMD-Vektorregistern länger als 1289 Bit lang zu sein. Die Verwendung einer VEX-Vorsilbe ermöglicht eine Syntax mit drei (oder mehr) Operanden. Beispielsweise führten frühere Befehle mit zwei Operanden Operationen wie etwa A = A + B durch, die einen Quelloperanden überschreiben. Die Verwendung einer VEX-Vorsilbe ermöglicht den Operanden, nichtdestruktive Operationen, wie etwa A = B + C durchzuführen.
7A veranschaulicht ein beispielhaftes AVX-Befehlsformat einschließlich einer VEX-Vorsilbe 2102, einem echten Opcode-Feld 2130, Mod-R/M-Byte 2140, SIB-Byte 2150, Verschiebungsfeld 2162 und IMM8 2172. 7B veranschaulicht, welche Felder aus 7A ein vollständiges Opcode-Feld 2174 und ein Basisoperationsfeld 2142 ergeben. 7C veranschaulicht, welche Felder aus 7A ein Registerindexfeld 2144 ergeben.
Die VEX-Vorsilbe (Bytes 0-2) 2102 ist in einer Drei-Byte-Form kodiert. Das erste Byte ist das Formatfeld 2140 (VEX Byte 0, Bits [7:0]), das einen expliziten C4-Bytewert enthält (der eindeutige Wert, der zum Unterscheiden des C4-Befehlsformats verwendet wird). Das zweite und dritte Byte (VEX Bytes 1-2) umfassen eine Reihe von Bitfeldern, die eine spezifische Fähigkeit bereitstellen. Insbesondere besteht das REX-Feld 2105 (VEX Byte 1, Bits [7-5]) aus einem VEX.R-Bitfeld (VEX Byte 1, Bit [7] – R), VEX.X-Bitfeld (VEX Byte 1, Bit [6] – X) und VEX.B-Bitfeld (VEX Byte 1, Bit [5] – 5). Andere Felder der Befehle kodieren die unteren drei Bits der Registerindexe, wie auf dem Gebiet der Erfindung bekannt (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb durch das Hinzufügen von VEX.R, VEX.X und VEX.B ausgebildet werden können. Das Opcode-Kartenfeld 2155 (VEX Byte 1, Bits [4:0] – mmmmm) umfasst Inhalt, um ein impliziertes führendes Opcode-Byte zu kodieren. Das W-Feld 2164 (VEX Byte 2, Bit [7] – W) – wird durch die Bezeichnung VEX.W dargestellt und stellt abhängig vom Befehl unterschiedliche Funktionen Bereit. Die Rolle von VEX.vvvv 2120 (VEX Byte 2, Bits [6:3]-vvvv) kann folgendes umfassen: 1) VEX-vvvv kodiert den ersten Quellregisteroperanden, spezifiziert in invertierter (1s-Komplement-)Form und ist gültig für Befehle mit 2 oder mehr Quelloperanden; 2) VEX-vvvv kodiert den Zielregisteroperanden, spezifiziert in 1s-Komplementform für bestimmte Vektorverschiebungen; oder 3) VEX.vvvv kodiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Wenn das Größenfeld von VEX.L 2168 (VEX Byte 2, Bit [2]-L) = 0, zeigt das einen 128-Bit-Vektor an; wenn VEX.L = 1, zeigt das einen 256-Bit-Vektor an. Das vorsilbenkodierende Feld 2125 (VEX Byte 2, Bits [1:0]-pp stellt zusätzliche Bits für das Basisoperationsfeld bereit.
Das echte Opcode-Feld 2130 (Byte 3) ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert. Das MOD-R/M-Feld 2140 (Byte 4) umfasst das MOD-Feld 2142 (Bits [7-6], Reg-Feld 2144 (Bits [5-3]) und das R/M-Feld 2146 (Bits [2-0]). Die Rolle des Reg-Felds 2144 kann folgendes umfassen: entweder den Zielregisteroperanden oder einen Quellregisteroperanden (das rrr von Rrrr) kodieren oder als eine Opcode-Verlängerung behandelt werden und nicht verwendet werden, um irgendeinen Befehlsoperanden zu kodieren. Die Rolle des R/M-Felds 2146 kann folgendes umfassen: den Befehlsoperanden, der eine Speicheradresse referenziert, oder entweder den Zielregisteroperanden oder einen Quellregisteroperanden kodieren.
Skala, Index, Basis (SIB) – der Inhalt des Skalierfeldes 2150 (Byte 5) umfasst SS2152 (Bits [7-6]), die für die Speicheradressenerzeugung verwendet wird. Auf die Inhalte von SIB.xxx 2154 (Bits [5-3]) und SIB.bbb 2156 (Bits [2-0]) wurde zuvor mit Bezug auf die Registerindexe Xxxx und Bbbb verwiesen. Das Verschiebungsfeld 2162 und das Direktoperandenfeld (IMM8) 2172 enthalten Adressdaten.
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das fair Vektorbefehle geeignet ist (z. B. es gibt bestimmte Felder, die für Vektoroperationen spezifisch sind).
Während Ausführungsformen beschrieben werden, bei denen sowohl Vektoroperationen als auch skalare Operationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden in alternativen Ausführungsformen nur Vektoroperationen das vektorfreundliche Befehlsformat.
8A, 8B und 8C sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen. 8A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon gemäß Ausführungsformen der Erfindung zeigt; während Fig. B ein Blockdiagramm ist, das das generische vektorfreundliche Befehlsformat und Befehlsvorlagen davon der Klasse B gemäß Ausführungsformen der Erfindung zeigt. Insbesondere ein generisches vektorfreundliches Befehlsformat 2200, für das Befehlsvorlagen der Klasse A und der Klasse B definiert wurden, die beide Befehlsvorlagen ohne Speicherzugriff 2205 und Befehlsvorlagen mit Speicherzugriff 2220 umfassen. Der Begriff generisch im Zusammenhang mit dem vektorfreundlichen Befehlsformat bezieht sich darauf, dass das Befehlsformat nicht an einen spezifischen Befehlssatz gebunden ist.
Während Ausführungsformen der Erfindung beschrieben werden, bei 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 doppelwortgroßen Elementen oder alternativ dazu aus 8 vierfachwortgroßen 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); alternative Ausführungsformen können mehr/weniger und/oder andere Vektoroperandengrößen unterstützen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. 128-Bit (16 Byte) Datenelementbreiten).
Die Befehlsvorlagen der Klasse A in 8A umfassen: 1) innerhalb der Befehlsvorlagen ohne Speicherzugriff 2205 ist eine Befehlsvorlage für eine vollständig runde Steuertypoperation ohne Speicherzugriff 2210 und eine Befehlsvorlage für eine Datenumwandlungstypoperation ohne Speicherzugriff 2215 gezeigt; und 2) innerhalb der Befehlsvorlagen mit Speicherzugriff 2220 ist eine temporale Befehlsvorlage mit Speicherzugriff 2225 und eine nichttemporale Befehlsvorlage mit Speicherzugriff 2230 gezeigt. Die Befehlsvorlagen der Klasse B in 8B umfassen: 1) innerhalb der Befehlsvorlagen ohne Speicherzugriff 2205 ist eine Befehlsvorlage für Schreibmaskensteuerung, teilweise runden Steuertypoperation mit Speicherzugriff 2212 und eine Befehlsvorlage für eine Schreibmaskensteuerung, v-Größen-artige Operation ohne Speicherzugriff 2217 gezeigt; und 2) innerhalb der Befehlsvorlagen mit Speicherzugriff 2220 ist eine Befehlsvorlage für eine Schreibmaskensteuerung mit Speicherzugriff 2227 gezeigt.
Das generische vektorfreundliche Befehlsformat 2200 umfasst die folgenden Felder, die nachfolgend in der in 8A und 8B veranschaulichten Reihenfolge aufgelistet sind. Formatfeld 2240 – ein spezifischer Wert (ein Befehlsformatbezeichnerwert) in diesem Feld identifiziert das vektorfreundliche Befehlsformat und somit das Auftreten von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen eindeutig. Somit ist dieses Feld optional, in dem Sinn, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht erforderlich ist. Basisoperationsfeld 2242 – sein Inhalt kennzeichnet verschiedene Basisoperationen.
Registerindexfeld 2244 – sein Inhalt, direkt oder durch Adresserzeugung, spezifiziert die Positionen der Quell- und Zieloperanden, seien sie in Registern oder im Speicher. Diese umfassen eine ausreichende Anzahl von Bits, um N Register aus einer P×Q (z. B. 32×512, 16×128, 32×1024, 64×1024) Registerdatei 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 dieser Quellen und Zielregister unterstützen (z. B. sie können bis zu zwei Quellen, wobei eine dieser Quellen auch als das Ziel agiert, unterstützen, sie können bis zu drei Quellen, wobei eine dieser Quellen auch als das Ziel agiert, unterstützen, sie können bis zu zwei Quellen und ein Ziel unterstützen).
Modifikatorfeld 2246 – sein Inhalt kennzeichnet Auftreten von Befehlen im generischen Vektorbefehlsformat, die Speicherzugriff spezifizieren, von denen, die das nicht tun; das heißt, zwischen Befehlsvorlagen ohne Speicherzugriff 2205 und Befehlsvorlagen mit Speicherzugriff 2220. Speicherzugriffsoperationen lesen und/oder schreiben aus der/in die Speicherhierarchie (wobei sie in manchen Fällen die Quell- und/oder Zieladressen mit Hilfe von Werten in Registern spezifizieren), während Operationen ohne Speicherzugriff dies nicht tun (z. B. die Quellen und Ziele sind Register). Während in einer Ausführungsform dieses Feld auch zwischen drei verschiedenen Wegen, um Speicheradressberechnungen durchzuführen, auswählt, können alternative Ausführungsformen mehr, weniger oder andere Wege für Speicheradressberechnungen unterstützen.
Vergrößerungsoperationsfeld 2250 – ihr Inhalt kennzeichnet, welche einer Vielzahl unterschiedlicher Operationen zusätzlich zu der Basisoperation angewandt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 2268, ein Alphafeld 2252 und ein Betafeld 2254 unterteilt. Das Vergrößerungsoperationsfeld 2250 erlaubt, dass allgemeine Operationsgruppen in einem einzigen Befehl anstatt in 2, 3 oder 4 Befehlen durchgeführt werden. Skalierfeld 2260 – sein Inhalt ermöglicht das Skalieren des Inhalts des Indexfelds entsprechend der Speicheradresserzeugung (z. B. für Adresserzeugung, die 2^skala* Index + Basis verwendet).
Verschiebungsfeld 2262A – sein Inhalt wird als Teil der Speicheradressenerzeugung verwendet (z. B. für Adresserzeugung, die 2^skala* Index + Basis + Verschiebung verwendet). Das Verschiebungsfaktorfeld 2262B (es wird angemerkt, dass die Nebeneinanderstellung des Verschiebungsfelds 2262A direkt über dem Verschiebungsfaktorfeld 2262B angibt, ob das eine oder das andere verwendet wird) – sein Inhalt wird als Teil der Adresserzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) zu skalieren ist – wobei N die Anzahl von Bytes im Speicherzugriff ist (z. B. für Adresserzeugung, die 2^skala* Index + Basis + skalierte Verschiebung verwendet). Redundante niederrangige Bits werden ignoriert und somit wird der Inhalt des Verschiebungsfaktorfelds mit der Gesamtgröße der Speicheroperanden (N) multipliziert, um die Endverschiebung für die Verwendung bei der Berechnung einer effektiven Adresse zu erzeugen. Der Wert von N wird von der Prozessor-Hardware während der Laufzeit bestimmt, basierend auf dem vollständigen Opcode-Feld 2274 (hierin nachfolgend beschrieben) und dem Datenmanipulationsfeld 2254C. Das Verschiebungsfeld 2262A und das Verschiebungsfaktorfeld 2262B sind optional in dem Sinne, dass sie nicht für Befehlsvorlagen ohne Speicherzugriff 2205 und/oder andere Ausführungsformen, die nur eines oder keines der beiden einsetzen, verwendet werden.
Datenelementbreitenfeld 2264 – sein Inhalt kennzeichnet, welche einer Reihe von Datenelementbreiten zu verwenden ist (in manchen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für manche der Befehle). Dieses Feld ist optional in dem Sinne, dass es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung eines gewissen Aspekts der Opcodes unterstützt werden.
Schreibmaskenfeld 2270 – sein Inhalt steuert auf einer Basis pro Datenelementposition, ob diese Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Vergrößerungsoperation widerspiegelt. Befehlsvorlagen der Klasse A unterstützen vereinende Schreibmaskierung, während Befehlsvorlagen der Klasse B sowohl vereinende als auch nullsetzende Schreibmaskierung unterstützen. Beim Vereinen erlauben Vektormasken, dass ein beliebiger Elementesatz am Ziel während der Ausführung einer beliebigen Operation (von der Basisoperation oder der Vergrößerungsoperation spezifiziert) vor Aktualisierungen geschützt wird; in einer anderen Ausqführungsform das Erhalten des alten Werts für jedes Element des Ziels, bei dem das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu, erlauben Vektormasken beim Nullsetzen, dass ein beliebiger Elementesatz am Ziel während der Ausführung einer beliebigen Operation (von der Basisoperation oder der Vergrößerungsoperation spezifiziert) auf null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Untergruppe dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, der ausgeführt wird, zu steuern (das heißt, die Spanne an Elementen, die modifiziert wird, vom ersten bis zum letzten); jedoch ist es nicht erforderlich, dass die Elemente, die modifiziert werden, aufeinander folgen. Somit erlaubt das Schreibmaskenfeld 2270 partielle Vektoroperationen, einschließlich Lade-, Speicher-, arithmetische, logische etc. Während Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfeld 2270 eines aus einer Reihe von Schreibmaskenregistern auswählen, das die zu verwendende Schreibmaske enthält (und somit identifiziert der Inhalt des Schreibmaskenfelds 2270 indirekt, welche Maskierung durchzuführen ist), alternative Ausführungsformen erlauben stattdessen oder zusätzlich dazu, dass der Inhalt des Maskenschreibfelds 2270 die durchzuführende Maskierung direkt identifiziert.
Direktoperandenfeld 2272 – sein Inhalt erlaubt die Spezifikation eines Direktoperanden. Dieses Feld ist optional in dem Sinne, dass es bei einer Implementierung eines generischen vektorfreundlichen Formats, das keine Direktoperanden unterstützt, nicht vorliegt und dass es bei Befehlen, die keinen Direktoperanden verwenden, nicht vorliegt. Klassenfeld 2268 – sein Inhalt kennzeichnet zwischen verschiedenen Befehlsklassen. Mit Bezug auf 8A und 8B wählen die Inhalte dieses Felds zwischen Befehlen das Klasse A und der Klasse B. In 8A und 8B werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorliegt (z. B. Klasse A 2268A und Klasse B 2268B für das Klassenfeld 2268 in 8A bzw. 8B) Im Falle einer Befehlsvorlage ohne Speicherzugriff 2205 der Klasse A wird das Alphafeld 2252 als ein RS-Feld 2252A interpretiert, dessen Inhalt kennzeichnet, welcher der verschiedenen Vergrößerungsoperationstypen durchzuführen ist (z. B. rund 2252A-1 und Datenumwandlung 2252A.2 werden jeweils für die Befehlsvorlagen für die Rundtypoperation ohne Speicherzugriff 2210 bzw. die Datenumwandlungstypoperation ohne Speicherzugriff 2215 spezifiziert), während das Betafeld 2254 kennzeichnet, welche der Operationen des spezifizierten Typs durchzuführen sind. Bei den Befehlsvorlagen ohne Speicherzugriff ohne Speicherzugriff 2205 liegen das Skalierfeld 2260, das Verschiebungsfeld 2262A und das Verschiebungsskalenfeld 2262B nicht vor.
Bei der Befehlsvorlage der vollständig runden Steuertypoperation ohne Speicherzugriff 2210 wird das Betafeld 2254 als ein rundes Steuerfeld 2254A interpretiert, dessen Inhalte) eine statische Rundung bereitstellen. Während in den beschriebenen Ausführungsformen der Erfindung das runde Steuerfeld 2254A ein Feld zum Supprimieren aller Gleitkommaausnahmen (SAE) 2256 und ein rundes Operationssteuerfeld 2258 umfasst, können alternative Ausführungsformen beide dieser Konzepte in dasselbe Feld kodieren oder können nur das eine oder das andere dieser Konzepte/Felder aufweisen (z. B. können nur das Rundungsoperationssteuerfeld 2258 aufweisen).
SAE-Feld 2256 – sein Inhalt kennzeichnet, ob die Berichterstattung über Ausnahmefälle gegebenenfalls deaktiviert werden soll; wenn der Inhalt des SAE-Felds 2256 anzeigt, dass eine Suppression aktiviert ist, meldet ein gegebener Befehl keine Art von Gleitkomma-Ausnahmeflagge und zieht keinen Gleitkomma-Ausnahmenbehandler heran.
Rundungsoperationssteuerfeld 2258 – sein Inhalt kennzeichnet, welcher aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Gegen-Null-Runden, Auf-das-nächste-Runden). Somit erlaubt das Rundungsoperationssteuerfeld 2258 das Ändern des Rundungsmodus auf einer Basis pro Befehl. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerfelds 2250 diesen Registerwert.
In einer Befehlsvorlage für eine datentransformationsartige Operation ohne Speicherzugriff 2215 wird das Betafeld 2254 als Datentransformationsfeld 2254B interpretiert, dessen Inhalt kennzeichnet, welche einer Reihe von Datentransformationen durchzuführen ist (z. B. keine Datentransformation, Swizzling, Ausstrahlung).
Im Fall einer Befehlsvorlage der Klasse A mit Speicherzugriff 2220 wird das Alphafeld 2252 als ein Räumungshinweisfeld 2252B interpretiert, dessen Inhalt kennzeichnet, welcher der Räumungshinweise zu verwenden ist (in 8A sind temporal 2252B.1 bzw. nichttemporal 2252B.2 für die temporale Befehlsvorlage mit Speicherzugriff 2225 und die nichttemporale Befehlsvorlage mit Speicherzugriff 2230 spezifiziert), während das Betafeld 2254 als ein Datenmanipulationsfeld 2254C interpretiert wird, dessen Inhalt kennzeichnet, welcher aus einer Reihe von Datenmanipulationsoperationen (auch bekannt als Primitive) durchzuführen ist (z. B. keine Manipulation; Ausstrahlung; Aufwärtskonversion einer Quelle; und Abwärtskonversion eines Ziels). Die Befehlsvorlagen mit Speicherzugriff 2220 umfassen das Skalierfeld 2260 und gegebenenfalls das Verschiebungsfeld 2262A oder das Verschiebungsskalierfeld 2262B.
Vektorspeicherbefehle führen Vektorladeoperationen aus dem und Vektorspeicheroperationen in den Speicher mit Konversionsunterstützung durch. Wie bei regulären Vektorbefehlen transferieren Vektorspeicherbefehle Daten aus dem/in den Speicher in einer datenelementartigen Weise, wobei die Elemente, die tatsächlich transferiert werden, von den Inhalten der Vektormaske, die als die Schreibmaske ausgewählt wird, diktiert werden.
Bei temporalen Daten ist es wahrscheinlich, dass sie bald genug wiederverwendet werden, so dass sie von einer Zwischenspeicherung profitieren würden. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können diesen auf unterschiedliche Arten implementieren, einschließlich des vollständigen Ignorierens des Hinweises. Bei nichttemporalen Daten ist es unwahrscheinlich, dass sie bald genug wiederverwendet werden, so dass sie von einer Zwischenspeicherung im Cache der ersten Ebene profigieren und sollten für die Räumung Priorität erhalten. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können diesen auf unterschiedliche Arten implementieren, einschließlich des vollständigen Ignorierens des Hinweises.
Im Falle der Befehlsvorlagen der Klasse B wird das Alphafeld 2252 als ein Schreibmaskensteuer-(Z)Feld 2252C interpretiert, dessen Inhalt kennzeichnet, ob die vom Schreibmaskenfeld 2270 gesteuerte Schreibmaskierung eine verschmelzende oder eine Nullsetzende sein sollte.
Im Falle der Befehlsvorlagen der Klasse B ohne Speicherzugriff 2205 wird ein Teil des Betafelds 2254 als ein RL-Feld 2257A interpretiert, dessen Inhalt kennzeichnet, welche der verschiedenen Arten von Vergrößerungsoperationen durchzuführen ist (z. B. rundes 2257A.1 bzw. Vektorlängen-(VSIZE) 2257A.2 werden für die Befehlsvorlage der teilrundsteuerungsartigen Schreibmaskensteuerungsoperation ohne Speicherzugriff 2212 und die Befehlsvorlage der VSIZE-artigen Schreibmaskensteuerungsoperation ohne Speicherzugriff 2217 spezifiziert), währen der Rest des Betafelds 2254 kennzeichnet, welche der Operationen des spezifizierten Typs auszuführen sind. Bei den Befehlsvorlagen ohne Speicherzugriff 2205 liegen das Skalierfeld 2260, das Verschiebungsfeld 2262A und das Verschiebungsskalierfeld 2262B nicht vor.
Bei der Befehlsvorlage für die teilrundsteuerungsartige Schreibmaskensteuerungsoperation ohne Speicherzugriff 2210 wird der Rest des Betafelds 2254 als ein Rundoperationsfeld 2259A interpretiert und die Berichterstattung von Ausnahmeereignissen wird deaktiviert (ein gegebener Befehl erstattet keinen Bericht über jegliche Art von Gleitkommaausnahmeflagge und aktiviert keinen Gleitkommaausnahmebehandler).
Das Rundungsoperationssteuerfeld 2259A – ist wie auch das Rundungsoperationssteuerungsfeld 2258, sein Inhalt kennzeichnet, welcher aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Auf-Null-Runden oder Auf-das-nächste-Runden). Somit ermöglicht das Rundungsoperationssteuerfeld 2259A das Ändern des Rundungsmodus auf einer Basis pro Befehl. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerfelds 2250 diesen Registerwert.
Bei der Befehlsvorlage der VSIZE-artigen Schreibmaskensteueroperation ohne Speicherzugriff 2217 wird der Rest des Betafelds 2254 als ein Vektorlängenfeld 2259B interpretiert, dessen Inhalt kennzeichnet, auf welcher aus einer Reihe von Datenvektorlängen die Durchführung vorzunehmen ist (z. B. 128, 256 oder 512 Byte).
Im Falle einer Befehlsvorlage der Klasse B mit Speicherzugriff 2220 wird ein Teil des Betafelds 2254 als ein Ausstrahlungsfeld 2257B interpretiert, dessen Inhalt kennzeichnet, ob die ausstrahlungsartige Datenmanipulationsoperation durchzuführen ist oder nicht, während der Rest des Betafelds 2254 als Vektorlängenfeld 2259B interpretiert wird. Die Befehlsvorlagen mit Speicherzugriff 2220 umfassen das Skalierfeld 2260 und gegebenenfalls das Verschiebungsfeld 2262A oder das Verschiebungsskalierfeld 2262B.
Mit Bezug auf das generische vektorfreundliche Befehlsformat 2200 ist ein vollständiges Opcode-Feld 2274 gezeigt, welches das Formatfeld 2240, das Basisoperationsfeld 2242 und das Datenelementbreitenfeld 2264 umfasst. Während eine Ausführungsform gezeigt ist, in der das vollständige Opcode-Feld 2274 alle diese Felder umfasst, umfasst das vollständige Opcode-Feld 2274 weniger als alle dieser Felder in Ausführungsformen, die diese nicht unterstützen. Das vollständige Opcode-Feld 2274 stellt den Operationscode (Opcode) bereit.
Das Vergrößerungsoperationsfeld 2250, das Datenelementbreitenfeld 2264 und das Schreibmaskenfeld 2270 ermöglichen, dass diese Merkmale auf einer Basis pro Befehl im generischen vektorfreundlichen Befehlsformat spezifiziert werden. Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugen typisierte Befehle insofern, als dass sie erlauben, dass die Maske basierend auf verschiedenen Datenelementbreiten angewandt wird.
Die innerhalb der Klassen A und B gefunden verschiedenen Befehlsvorlagen sind in unterschiedlichen Situationen vorteilhaft. In manchen Ausführungsformen der Erfindung können verschiedene Prozessoren oder verschiedene Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Beispielsweise kann es sein, dass ein reihenfolgeloser Hochleistungs-Allzweck-Kern, der für Allzweckrechenoperationen vorgesehen ist, nur die Klasse B unterstützt, ein Kern, der hauptsächlich für Grafik und/oder wissenschaftliche (Durchsatz-)Rechenoperationen vorgesehen ist, nur Klasse A unterstützt und ein Kern, der für beides vorgesehen ist, beides unterstützt (natürlich ist auch ein Kern, der eine Mischung aus Vorlagen und Befehlen aus beiden Klassen, aber nicht alle Vorlagen und Befehle aus beiden Klassen aufweist, innerhalb des Bereichs der Erfindung). Ebenso kann ein einzelner Prozessor mehrere Kerne umfassen, die alle dieselbe Klasse unterstützen oder bei denen verschiedene Kerne verschiedene Klassen unterstützen. Beispielsweise kann in einem Prozessor mit separaten Grafik- und Allzweckkernen einer der Grafikkerne, der hauptsächlich für Grafiken und/oder wissenschaftliche Rechenleistungen vorgesehen ist, nur die Klasse A unterstützen, während einer oder mehrere der Allzweckkerne für Allzweckrechenleistungen vorgesehenen Hochleistungs-Allzweckkerne mit einer reihenfolgelosen Registerumbenennung sein können, die nur die Klasse B unterstützen. Ein weiterer Prozessor, der keinen separaten Grafikkern aufweist, kann in der anderen Klasse in anderen Ausführungsformen der Erfindung umgesetzt sein. Programme, die in einer höheren Programmiersprache geschrieben wurden, würden in eine Vielfalt von unterschiedlichen ausführbaren Formen gesetzt werden (z. B. gerade rechtzeitig kompiliert oder statisch kompiliert), die umfassen: 1) eine Form mit nur Befehlen der Klasse(n), die vom Zielprozessor unterstützt wird/werden zur Ausführung; oder 2) eine Form mit alternativen Routinen, die unter Verwendung verschiedener Kombinationen der Befehle aus allen Klassen geschrieben wurde und einen Steuerflusscode aufweist, der die Routinen für die Ausführung basierend auf den Befehlen, die vom Prozessor, der derzeit den Code ausführt, unterstützt werden.
9 ist ein Blockdiagramm das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung veranschaulicht. 9 zeigt ein spezifisches vektorfreundliches Befehlsformat 2300, das in dem Sinne spezifisch ist, dass es die Position, Größe, Interpretation und die Reihenfolge der Felder sowie Werte für manche der Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 2300 kann verwendet werden, um den x86-Befehlssatz zu erweitern, und somit sind manche der Felder ähnlich oder dieselben wie die im bestehenden x86-Befehlssatz und der Erweiterung davon (z. B. AVX) verwendeten. Dieses Format bleibt mit dem Präfixkodierfeld, dem echten Opcode-Byte-Feld, MOD-R/M-Feld, SIB-Feld, Verschiebungsfeld und unmittelbaren Feldern des bestehenden x86-Befehlssatzes mit Erweiterungen konsistent. Die Felder aus 8, auf die die Felder aus 9 abgebildet sind, werden veranschaulicht.
Es sollte sich verstehen, dass obwohl Ausführungsformen der Erfindung mit Bezug auf das spezifische vektorfreundliche Befehlsformat 2300 im Zusammenhang mit dem generischen vektorfreundlichen Befehlsformat 2200 für illustrative Zwecke beschrieben werden, die Erfindung jedoch nicht auf das spezifische vektorfreundliche Befehlsformat 2300 beschränkt ist, außer wo ausdrücklich angegeben. Beispielsweise erwägt das generische vektorfreundliche Befehlsformat 2200 eine Vielzahl möglicher Größen für die verschiedenen Felder, während das spezifische vektorfreundliche Befehlsformat 2300 als Feldern spezifischer Größen aufweisend gezeigt ist. In einem speziellen Beispiel, während das Datenelementbreitenfeld 2264 als ein Ein-Bit-Feld im spezifischen vektorfreundlichen Befehlsformat 2300 veranschaulicht ist, ist die Erfindung nicht dahingehend eingeschränkt (das heißt, das generische vektorfreundliche Befehlsformat 2200 erwägt andere Größen des Datenelementbreitenfelds 2264).
Das generische vektorfreundliche Befehlsformat 2200 umfasst die folgenden unten in der in 9A veranschaulichten Reihenfolge aufgelisteten Felder. EVEX-Präfix (Bytes 0-3) 2302 – ist in einer Vier-Bit-Form kodiert. Formatfeld 2240 (EVEX Byte 0, Bits [7:0]) – das erste Byte (EVEX Byte 0) ist das Formatfeld 2240 und enthält 0×62 (der eindeutige Wert, der für die Kennzeichnung des vektorfreundlichen Befehlsformats in einer Ausführung der Erfindung verwendet wird). Das zweite-vierte Byte (EVEX Bytes 1-3) umfassen eine Reihe von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
REX-Feld 2305 (EVEX Byte 1, Bits [7-5]) – besteht aus einem EVEX.R-Bitfeld (EVEX Byte 1, Bit [7] – R), EVEX.X-Bitfeld (EVEX Byte 1, Bit [6] – X) und 2257BEX-Byte 1, Bit[5] – B). Die EVEX-R-, EVEX.X- und EVEX.B-Bitfelder stellen dieselbe Funktionalität wie die entsprechenden VEX-Bitfelder bereit und sind mittels der 1s-Komplementform kodiert, d. h. ZMM0 ist als 1111B kodiert, ZMM15 ist als 0000B kodiert. Andere Felder der Befehle kodieren die unteren drei Bits der Registerindizes, wie auf dem Gebiet der Erfindung bekannt (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von EVEX.R, EVEX.X und EVEX.B ausgebildet werden können.
REX'-Feld 2210 – das ist der erste Teil des REX'-Felds 2210 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] – R'), das verwendet wird, um entweder die oberen 16 oder unteren 16 des erweiterten 32 Registersatzes zu kodieren. In einer Ausführungsform der Erfindung wird dieses Bit, zusammen mit anderen, wie unten angegeben, in einem bitinvertierten Format gespeichert, um (im wohlbekannten x86 32-Bitmodus) vom BOUND-Befehl zu unterscheiden, dessen echtes Opcode-Byte 62 ist, aber den Wert 11 im MOD-Feld nicht im MOD-R/M-Feld akzeptiert; alternative Ausführungsformen der Erfindung speichern dieses und die anderen unten im invertierten Format angegebenen Bits nicht. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu kodieren. In anderen Worten wird R'Rrrr ausgebildet, indem EVEX.R', EVEX-R und die anderen RRR aus anderen Feldern kombiniert werden.
Opcode-Abbildungsfeld 2315 (EVEX-Byte 1, Bits [3:0] – mmmm) – sein Inhalt kodiert ein implizites führendes Opcode-Byte (0F, 0F 38 oder 0F 3). Datenelementbreitenfeld 2264 (EVEX-Byte 2, Bit [7] – W) – wird durch den Begriff EVEX.W dargestellt. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente). EVEX.vvvv 2320 (EVEX Byte 2, Bits [6:3]-vvvv) – die Rolle von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv kodiert für den ersten Quellregisteroperanden, der in der invertierten (1s-Komplement-)Form spezifiziert und für Befehle mit 2 oder mehr Quelloperanden gültig ist; 2) EVEX.vvvv kodiert für den Zielregisteroperanden, der in der 1s-Komplementform für bestimmte Vektorverschiebungen spezifiziert ist; oder 3) EVEX.vvvv kodiert für keinen Operanden, das Feld ist reserviert und sollte 111b enthalten. Somit kodiert das EVEX.vvvv-Feld 2320 die 4 niederwertigen Bits des in der invertierten (1s-Komplement-)Form gespeicherten ersten Quellregisterspezifikators. Abhängig vom Befehl wird ein zusätzliches unterschiedliches EVEX-Bitfeld verwendet, um die Spezifikatorgröße auf 32 Register auszuweiten. EVEX.U 2268 Klassenfeld (EVEX-Byte 2, Bit [2]-U) – Wenn EVEX.U = 0, gibt es Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, gibt es Klasse B oder EVEX.U1 an.
Präfixkodierendes Feld 2325 (EVEX Byte 2, Bits [1:0]-pp) – stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zur Bereitstellung von Unterstützung für die SSE-Befehle der älteren Generation im EVEX-Präfixformat hat dies auch den Vorzug, des Kompaktierens des SIMD-Präfixes (anstatt ein Byte zum Exprimieren des SIMD-Präfixes zu benötigen, erfordert der EVEX-Präfix nur 2 Bit). In einer Ausführungsform sind diese SIMD-Präfixe der älteren Generation in das SIMD-präfixkodierende Feld kodiert, um SSE-Befehle der älteren Generation, die einen SIMD-Präfix verwenden (66H, F2H, F3H), sowohl im älteren Format als auch im EVEX-Präfixformat, zu unterstützen; und werden während der Laufzeit in das SIMD-Präfix der älteren Generation ausgeweitet, bevor sie der PLA des Dekodierers bereitgestellt werden (so dass die PLA sowohl das alte als auch das EVEX-Format dieser Befehle der älteren Generation ohne Modifikation ausführen kann). Obwohl neuere Befehle den Inhalt des EVEX-Präfixkodierenden Feldes direkt als Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen auf eine ähnliche Weise für Konsistenz, aber erlauben unterschiedliche Meinungen, die von diesen SIMD-Präfixen der älteren Generation spezifiziert werden. Eine alternative Ausführungsform kann die PLA umgestalten, um die 2-Bit-SIMD-Präfixkodierungen zu unterstützen und somit die Erweiterung nicht zu benötigen.
Alphafeld 2252 (EVEX-Byte 3, Bit [7] – EH; auch bekannt als EVEX-EH, EVEX-rs, EVEX-RL, EVEX-Schreibmaskensteuerung und EVEX-N; auch durch α veranschaulicht) – wie zuvor beschrieben ist dieses Feld kontextabhängig. Betafeld 2254 (EVEX-Byte 3, Bits [6:4]-SSS, auch bekannt als EVEX.s_2-0, EVEX.r_2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; auch durch βββ veranschaulicht) – wie zuvor beschrieben ist dieses Feld kontextabhängig.
REX'-Feld 2210 – ist der Rest des REX'-Felds und ist das EVEX.V'-Bit-Feld (EVEX-Byte 3, Bit [3] – V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32 Registersatzes zu kodieren. Dieses Bit wird im bitinvertierten Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu kodieren. In anderen Worten wird V'VVVV ausgebildet, indem EVEX.V' und EVEX.vvvv kombiniert werden.
Schreibmaskenfeld 2270 (EVEX-Byte 3, Bits [2:0]-kkk) – sein Inhalt spezifiziert den Index eines Registers in das Schreibmaskenregister, wie zuvor beschrieben. In einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk = 000 ein spezielles Verhalten auf, das beinhaltet, dass keine Schreibmaske für den speziellen Befehl verwendet wird (dies kann auf eine Vielzahl von Wegen umgesetzt werden, einschließlich der Verwendung einer Schreibmaske, die mit allen einen oder Hardware, die die Maskierungs-Hardware überbrücken, festverdrahtet ist).
Das echte Opcode-Feld 2330 (Byte 4) ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert. MOD-R/M-Feld 2340 (Byte 5) umfasst MOD-Feld 2342, Reg-Feld 2344 und R/M-Feld 2346. Wie zuvor beschrieben unterscheidet der Inhalt des MOD-Felds 2342 zwischen Operationen mit Speicherzugriff und ohne Speicherzugriff. Die Rolle des Reg-Felds 2344 kann auf zwei Situationen zusammengefasst werden: entweder den Zielregisteroperanden oder den Quellregisteroperanden kodieren oder als eine Opcode-Erweiterung behandelt und nicht zum Kodieren jeglicher Befehlsoperanden verwendet werden. Die Rolle des R/M-Felds 2346 kann Folgendes umfassen: das Kodieren des Befehlsoperanden, der eine Speicheradresse referenziert, oder das Kodieren von entweder dem Zielregisteroperanden oder einem Quellregisteroperanden.
Skala-Index-Basis-(SIB-)Byte (Byte 6) – wie zuvor beschrieben wird der Inhalt des Skalierfelds 2250 für die Speicheradressengenerierung verwendet. SIB-xxx 2354 und SIB.bbb 2356 – auf die Inhalte dieser Felder wurde zuvor mit Bezug auf die Registerindizes Xxxx und Bbbb verwiesen. Verschiebungsfeld 2262A (Bytes 7-10) – wenn das MOD-Feld 2342 10 enthält, sind die Bytes 7-10 das Verschiebungsfeld 2262A und es funktioniert auf dieselbe Weise wie die 32-Bit Verschiebung der älteren Generation (disp32) und arbeitet mit Byte-Granularität.
Verschiebungsfaktorfeld 2262B (Byte 7) – wenn das MOD-Feld 2342 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 2262B. Die Position dieses Felds ist dieselbe wie die der 8-Bit-Verschiebung der älteren Generation (disp8) des x86-Befehlssatzes, die mit Byte-Granularität arbeitet. Da disp8 zeichenverlängert ist, kann es nur zwischen –128 und 127 Byte-Offsets adressieren; in Bezug auf 64-Byte-Cachezeilen verwendet disp8 8 Bits, die nur auf vier wirklich zweckmäßige Werte gesetzt werden können –128, –64, 0 und 64, da häufig eine größere Bandbreite benötigt wird, wird disp32 benutzt; jedoch erfordert disp32 4 Byte. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 2262B eine Neuinterpretation von disp8; bei der Verwendung des Verschiebungsfaktorfelds 2262B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Diese Art der Verschiebung wird als disp8*N bezeichnet. Dies reduziert die durchschnittliche Befehlslänge (ein einzelnes Byte wird für die Verschiebung verwendet, aber mit einer viel größeren Bandbreite). Eine solche komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist und somit die redundanten niederrangigen Bits des Adress-Offsets nicht kodiert werden müssen. In anderen Worten ersetzt das Verschiebungsfaktorfeld 2262B die 8-Bit-Verschiebung der älteren Generation des x86-Befehlssatzes. Somit wird das Verschiebungsfaktorfeld 2262B auf dieselbe Weise wie eine 8-Bit-Verschiebung des x86-Befehlssatzes kodiert (also keine Änderungen in den ModRM/SIB-Kodierregeln) mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird). In anderen Worten, es gibt keine Änderungen an den Kodierregeln oder Kodierlängen, sondern nur in der Interpretation des Verschiebungswerts durch die Hardware (die die Verschiebung durch die Größe des Speicheroperanden skalieren muss, um einen Adress-Offset Byte für Byte zu erhalten). Das Direktoperandenfeld 2272 arbeitet wie zuvor beschrieben.
9B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 2300 veranschaulicht, die das vollständige Opcode-Feld 2273 in Übereinstimmung mit einer Ausführungsform der Erfindung bilden. Insbesondere umfasst das vollständige Opcode-Feld 2274 das Formatfeld 2240, das Basisoperationsfeld 2242 und das Datenelementbreiten-(W-)Feld 2264. Das Basisoperationsfeld 2242 umfasst das präfixkodierende Feld 2325, das Opcode-Abbildungsfeld 2315 und das echte Opcode-Feld 2330.
9C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 2300 veranschaulicht, die gemäß einer Ausführungsform der Erfindung das Registerindexfeld 2244 bilden. Insbesondere umfasst das Registerindexfeld 2244 das REX-Feld 2305, das REX'-Feld 2310, das MODR/M.reg-Feld 2344, das MODR/M.r/m-Feld 2346, das VVVV-Feld 2320, xxx-Feld 2354 und das bbb-Feld 2356.
9D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 2300 veranschaulicht, die gemäß einer Ausführungsform der Erfindung das Vergrößerungsoperationsfeld 2250 bilden. Wenn das Klasse-(U)Feld 2268 0 enthält, bedeutet es EVEX-U0 (Klasse A 2268A); wenn es 1 enthält, bedeutet es EVEX.U1 (Klasse B 2268B). Wenn U = 0 und das MOD-Feld 2342 11 enthält (was eine Operation ohne Speicherzugriff kennzeichnet), wird das Alphafeld 2252 (EVEX-Byte 3, Bit [7] – EH) als das rs-Feld 2252A interpretiert. Wenn das rs-Feld 2252A eine 1 enthält (rund 2252A.1), wird das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]-SSS) als das Rundungssteuerfeld 2254A interpretiert. Das Rundungssteuerfeld 2254A umfasst ein Ein-Bit-SAE-Feld 2256 und ein Zwei-Bit-Rundungsoperationsfeld 2258. Wenn das rs-Feld 2252A eine 0 enthält (Datentransformation 2252A.2), wird das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]-SSS) als ein Drei-Bit-Datentransformationsfeld 2254B interpretiert. Wenn U = 0 und das MOD-Feld 2342 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff kennzeichnet), wird das Alphafeld 2252 (EVEX-Byte 3, Bit [7] – EH) als das Räumungshinweis-(EH-)Feld 2252B interpretiert und das Betafeld 2254 (EVEX-Byte 3, Bits [6:4]-SSS) wird als Drei-Bit-Datenmanipulationsfeld 2254C interpretiert.
Wenn U = 1, wird das Alphafeld 2252 (EVEX-Byte 3, Bit [7] – EH) als das Schreibmaskenkontroll-(Z-)Feld 2252C interpretiert. Wenn U = 1 und das MOD-Feld 2342 11 enthält (was eine Operation ohne Speicherzugriff kennzeichnet), wird ein Teil des Betafelds 2254 (EVEX-Byte 3, Bit [4]-S₀) als das RL-Feld 2257A interpretiert; wenn es eine 1 enthält (rund 2257A.1), wird der Rest des Betafelds 2254 (EVEX-Byte 3, Bits [6-5]-S2_1) als das Rundungsoperationsfeld 2259A interpretiert, während wenn das RL-Feld 2257A eine 0 enthält (VSIZE 2257.A2), wird der Rest des Betafelds (EVEX-Byte 3, Bits [6-5]-S_2-1) als Vektorlängenfeld 2259B (EVEX-Byte 3 Bit [6-5]-L_1-0) interpretiert. Wenn U = 1 und das MOD-Feld 2342 00, 01 oder 20 enthält (was eine Operation mit Speicherzugriff kennzeichnet), wird das Betadatenfeld 2254 (EVEX-Byte 3, Bits [6:4]-SSS) als Vektorlängenfeld 2259B (EVEX-Byte 3 Bit [6-5]-L_1-0) und das Ausstrahlungsfeld 2257B (EVEX-Byte 3, Bit [4]-B) interpretiert.

10 ist ein Blockdiagramm einer Registerarchitektur 2400 gemäß einer Ausführungsform der Erfindung. In der veranschaulichten Ausführungsform gibt es 32 Vektorregister 2410, die 512 Bits breit sind; diese Register werden als zmm0 bis zmm31 referenziert. Die niederrangigen 256 Bits der niederen 16 zmm-Register sind auf die Register ymm0-16 überlagert. Die niederrangigen 128 Bits der niederen der niederen 16 zmm-Register (die niederrangigen 128 Bits der ymm-Register) werden auf die Register xmm0-15 überlagert. Das spezifische vektorfreundliche Befehlsformat 2300 arbeitet auf dieser überlagerten Registerdatei wie in der nachfolgenden Tabelle beschrieben.

Einstellbare Vektorlänge	Klasse	Operationen	Register
Befehlsvorlage, die das Vektorlängenfeld 2259B nicht umfassen	A (Fig. 8A; U = 0)	2210, 2215, 2225, 2230	zmm-Register (die Vektorlänge beträgt 64 Byte)
	B (Fig. 8B; U = 1)	2212	zmm-Register (die Vektorlänge beträgt 64 Byte)
Befehlsvorlage, die das Vektorlängenfeld 2259B umfassen	B (Fig. 8B; U = 1)	2217, 2227	Zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) abhängig vom Vektorlängenfeld 2259B

In anderen Worten wählt das Vektorlängenfeld 2259B zwischen einer Höchstlänge und einer oder mehreren anderen kürzeren Längen aus, wobei jede der kürzeren Längen die halbe Länge der vorhergehenden Länge ist; und die Befehlsvorlagen ohne dem Vektorlängenfeld 2259B auf der Höchstvektorlänge arbeiten. Zudem arbeiten in einer Ausführungsform die Klasse-B-Befehlsvorlagen des spezifischen vektorfreundlichen Formats 2300 auf gepackten oder skalaren Einzel-/Doppelpräzisions-Gleitkommadaten und gepackten oder skalaren Integerdaten. Skalare Operationen sind Operationen, die auf der Datenelementposition der untersten Ordnung in einem zmm/ymm/xmm-Register arbeiten; die Datenelementpositionen der höheren Ordnung werden abhängig von der Ausführungsform entweder gleichgelassen, wie sie vor dem Befehl waren oder auf null gesetzt.
Schreibmaskenregister 2415 – in der veranschaulichten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7) mit jeweils einer Größe von 64 Bit. In einer alternativen Ausführungsform haben die Schreibmaskenregister 2415 eine Größe von 16 Bit. Wie zuvor beschrieben kann in einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als Schreibmaske verwendet werden; wenn die Kodierung, die normalerweise kennzeichnen würde, dass k0 als Schreibmaske verwendet wird, für eine Schreibmaske verwendet wird, wählt sie eine festverdrahtete Schreibmaske von 0xFFF, wodurch die Schreibmaskierung für diesen Befehl wirksam deaktiviert wird.
Allzweckregister 2425 – in der veranschaulichten Ausführungsform gibt es 16 64-Bit-Allzweckregister, die gemeinsam mit den bestehenden x86-Adressiermodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register werden durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.
Skalare Gleitkomma-Stapel-Registerdatei (x87 Stapel) 2445, auf die die MMX-gepackte Integer-Flachregisterdatei 2450 alias-verweist – in der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel aus acht Elementen, der verwendet wird, um skalare Gleitkommaoperationen auf 32-/64-/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzerweiterung durchzuführen; während die MMX-Register verwendet werden, um Operationen auf 64-Bit-gepackten Integerdaten durchzuführen, sowie Operanden für manche zwischen den MMX- und XMM-Registern durchgeführten Operanden zu halten.
Alternative Ausführungsformen der Erfindung können breitere oder schmälere Register verwenden. Zusätzlich dazu können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
Prozessorkerne können auf unterschiedliche Arten, für unterschiedliche Zwecke und in unterschiedlichen Prozessoren umgesetzt sein. beispielsweise können Implementierungen solcher Kerne umfassen: 1) einen reihenfolgegebundenen Allzweck-Kern für allgemeine Rechenleistungen; 2) einen reihenfolgelosen Hochleistungs-Allzweck-Kern für allgemeine Rechenleistungen; 3) einen Spezialkern, der speziell für Grafik und/oder wissenschaftliche (Durchsatz-)Rechenleistung vorgesehen ist. Implementierungen verschiedener Prozessoren können umfassen: 1) eine CPU, die einen oder mehrere reihenfolgegebundene Allzweckkerne für allgemeine Rechenleistungen und/oder einen oder mehrere reihenfolgelose Allzweck-Kerne für allgemeine Rechenleistungen umfasst; und 2) einen Co-Prozessor, der einen oder mehrere Spezialkerne umfasst, die hauptsächlich für Grafik und/oder wissenschaftliche Zwecke (Durchsatz) vorgesehen sind. Solche unterschiedlichen Prozessoren fuhren zu unterschiedlichen Computer-Systemarchitekturen, die folgendes umfassen können: 1) den Co-Prozessor auf einem von der CPU getrennten Chip; 2) den Co-Prozessor auf einem separaten Nacktchip im selben Gehäuse wie eine CPU; 3) den Co-Prozessor auf demselben Nacktchip wie eine CPU (in welchem Fall ein solcher Co-Prozessor manchmal als Sonderzweck-Logik bezeichnet wird, wie etwa integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik, oder als Sonderzweck-Kerne); und 4) ein System auf einem Chip, das die beschriebene CPU auf demselben Nacktchip umfassen kann (manchmal als der/die Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet, der oben beschriebene Co-Prozessor und zusätzliche Funktionalität). Beispielhafte Kernarchitekturen werden als nächstes beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computer-Architekturen.
11A ist ein Blockdiagramm, das sowohl eine beispielhafte reihenfolgegebundene Pipeline und eine beispielhafte reihenfolgelose Registerumbenennungs-, Ausgabe-/Ausführungs-Pipeline gemäß einer Ausführungsform der Erfindung zeigt. 11B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines reihenfolgegebundenen Architekturkerns und eines beispielhaften reihenfolgelosen Registerumbenennungs-, Ausgabe-/Ausführungs-Architekturkerns für die Integration in einen Prozessor gemäß einer Ausführungsform der Erfindung. Die Kästen mit durchgehenden Linien veranschaulichen die reihenfolgegebundene Pipeline und den reihenfolgegebundenen Kern, während die optionale Hinzufügung der Kästen mit gestrichelten Linien reihenfolgelose Registerumbenennungs-, Ausgabe-/Ausführungs-Pipeline und Kern veranschaulichen. Angesichts der Tatsache, dass der reihenfolgegebundene Aspekt eine Teilmenge des reihenfolgelosen Aspekts ist, wird der reihenfolgelose Aspekt beschrieben.
In 11A umfasst eine Prozessorpipeline 2500 eine Abrufstufe 2502, eine Längendekodierstufe 2504, eine Dekodierstufe 2506, eine Zuweisungsstufe 2508, eine Umbenennungsstufe 2510, eine Planungs- (auch bekannt als Versand- oder Ausgabe-)Stufe 2512, eine Registerlese-/Speicherlesestufe 2514, eine Ausführungsstufe 2516, eine Rückschreib-/Speicherschreibstufe 2518, eine Ausnahmenbehandlungsstufe 2522 und eine Übergabestufe 2524.
11B zeigt einen Prozessorkern 2590 mit einer Vorderendeneinheit 2530, die mit einer Ausführungsmotoreinheit 2550 gekoppelt ist und beide mit einer Speichereinheit 2570 gekoppelt sind. Der Kern 2590 kann ein Reduced-Instruction-Set-Computing-(RISC-)Kern, ein Complex-Instruction-Set-Computing-(CISC-)Kern, ein Very-Long-Word-(VLIW-)Kern oder ein hybrider oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 2590 ein Spezialzweckkern, wie etwa beispielsweise ein Netzwerk- oder Kommunikationskern, ein Kompressionskern, Co-Prozessorkern, ein Kern für Allzweck-Berechnungen auf Grafikprozessoreinheit(en) (GPGPU), Grafikkern oder dergleichen sein.
Die Vorderendeneinheit 2530 umfasst eine Abzweigungsvorhersageeinheit 2532, die mit einer Befehlscacheeinheit 2534 gekoppelt ist, die mit einem Befehlsübersetzungspuffer (TLB) 2536 gekoppelt ist, der mit einer Befehlsabrufeinheit 2538 gekoppelt ist, die mit einer Dekodiereinheit 1540 gekoppelt ist. Die Dekodiereinheit 2540 (oder Dekodierer) kann Befehle dekodieren und als Ausgabe einen oder mehrere Mikrooperationen, Mikro-Code-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale erzeugen, die aus den ursprünglichen Befehlen dekodiert werden oder diese anderweitig widerspiegeln oder von diesen hergeleitet sind. Die Dekodiereinheit 2540 kann unter Verwendung verschiedener Mechanismen implementiert werden. Beispiele für geeignete Mechanismen umfassen, ohne darauf beschränkt zu sein, Übersichtstabellen, Hardware-Implementierungen, programmierbare Logik-Anordnungen (PLA), Mikrocode-Festwertspeicher (ROM) etc. In einer Ausführungsform umfasst der Kern 2590 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für gewisse Makrobefehle speichert (z. B. in der Dekodiereinheit 2540 oder anderweitig innerhalb der Vorderendeneinheit 2530). Die Dekodiereinheit 2540 ist mit einer Umbenennungs-/Zuweisungseinheit 2552 in der Ausführungsmotoreinheit 2550 gekoppelt.
Die Ausführungsmotoreinheit 2550 umfasst die mit einer Ruhestandseinheit 2554 und einem Satz aus einer oder mehreren Planungseinheit(en) 2556 gekoppelte Umbenennungs-/Zuweisungseinheit 2552. Die Planungseinheit(en) 2556 stellt/stellen eine beliebige Zahl von verschiedenen Planern, einschließlich Reservierungsstationen, zentrales Befehlsfenster etc., dar. Die Planungseinheit(en) 2556 ist/sind mit der/den physikalischen Registerdatei(en)-Einheit(en) 2558 gekoppelt. Jede der physikalischen Registerdatei(en)-Einheiten 2558 repräsentiert eine oder mehrere physikalische Registerdateien, wobei verschiedene davon einen oder mehrere verschiedene Datentypen, wie etwa skalaren Integer, skalares Gleitkomma, gepackten Integer, gepacktes Gleitkomma, Vektorinteger, Vektorgleitkomma, Status (z. B. ein Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) etc., speichern.
In einer Ausführungsform umfasst die physikalische Registerdatei(en)-Einheit 2558 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Allzweckregister bereitstellen. Die physikalische(n) Registerdatei(en)-Einheit(en) 2558 wird/werden von der Ruhestandseinheit 2554 überlappt, um verschiedene Weisen, auf die das Umbenennen und die reihenfolgelose Ausführung implementiert werden können, zu veranschaulichen (z. B. mittels (eines) Reorganisationspuffer(s) und (einer) Ruhestandsregisterdatei(en); mittels (einer) Zukunftsdatei(en), (einem) Verlaufspuffer und (einer) Ruhestandsregisterdatei(en); mittels einer Registerabbildung und einem Pool aus Registern; etc.). Die Ruhestandseinheit 2554 und die physikalische(n) Registerdatei(en)-Einheit(en) 2558 sind mit dem/den Ausführungs-Cluster(n) 2560 gekoppelt.
Das/die Ausführungs-Cluster 2560 umfasst einen Satz aus einer oder mehreren Ausführungseinheiten 2562 und einen Satz aus einem oder mehreren Speicherzugriffseinheiten 2564. Die Ausführungseinheiten 2562 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) auf verschiedene Datentypen (z. B. skalares Gleitkomma, gepackter Integer, gepacktes Gleitkomma, Vektorinteger, Vektorgleitkomma) anwenden. Während manche Ausführungen eine Reihe von Ausführungseinheiten, die für spezifische Funktionen oder Funktionssätze zweckgewidmet sind, umfassen, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten, die alle dieselben Funktionen durchführen, umfassen.
Die Planungseinheit(en) 2556, physikalische(n) Registerdatei(en)-Einheit(en) 2558 und das/die Ausführungs-Cluster werden als möglicherweise Plural gezeigt, da gewisse Ausführungsformen separate Pipelines für bestimmte Datentypen/Operationen erzeugen (z. B. eine skalare Integer-Pipeline, eine skalare Gleitkomma-/gepackte Integer-/gepackte Gleitkomma-/Vektorinteger-(Vektorgleitkomma-Pipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Planungseinheit, physikalische Registerdatei(en)-Einheit und/oder Ausführungs-Cluster aufweisen – und im Fall einer separaten Speicherzugriffspipeline werden gewisse Ausführungsformen umgesetzt, in denen nur das Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 2564 aufweist.) Es versteht sich ebenso, dass wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines reihenfolgelose Ausgabe-/Ausführungs-Pipelines und der Rest reihenfolgegebundene Pipelines sein können.
Der Satz von Speicherzugriffseinheiten 2564 ist mit der Speichereinheit 2570 gekoppelt, die eine Daten-TLB-Einheit 2572, die mit einer Daten-Cache-Einheit 2574 gekoppelt ist, die mit einer Ebene-2-(L2-)Cache-Einheit 2576 gekoppelt ist, umfasst. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 2564 eine Ladeeinheit, eine Speicheradresseinheit und eine Speicherdateneinheit umfassen, die jeweils mit der Daten-TLB-Einheit 2572 in der Speichereinheit 2570 gekoppelt sind. Die Befehls-Cache-Einheit 2534 ist zudem mit einer Ebene-2-(L2-)Cache-Einheit 2576 in der Speichereinheit 2570 gekoppelt. Die L2-Cache-Einheit 2576 ist mit einem oder mehreren anderen Cache-Ebenen und schlussendlich mit einem Hauptspeicher gekoppelt.
Beispielsweise können die beispielhafte reihenfolgelose Registerumbenennungs-, Ausgabe-/Ausführungs-Kernarchitektur die Pipeline 2500 wie folgt implementieren: 1) die Befehlsabrufeinheit 2538 führt die Abruf- und Längendekodierstufen 2502 und 2504 durch; 2) die Dekodiereinheit 2540 führt die Dekodierstufe 2506 durch; 3) die Umbenennungs-/Zuweisungseinheit 2552 führt die Zuweisungsstufe 2508 und die Umbenennungsstufe 2510 durch; 4) die Planungseinheit(en) 2558 führt/führen die Planungsstufe 2512 durch; 5) die physikalische(n) Registerdatei(en)-Einheit(en) 2558 und die Speichereinheit 2570 führen die Registerlese-/Speicherlesephase 2514 durch; das Ausführungs-Cluster 2560 führt die Ausführungsstufe 2516 durch; 6) die Speichereinheit 2570 und die physikalischen Register-Datei(en)-Einheit(en) 2558 führen die Rückschreib-/Speicherschreibstufe 2518 durch; 7) verschiedene Einheiten können bei der Ausnahmebehandlungsstufe 2522 involviert sein; und 8) die Ruhestandseinheit 2554 und die physikalische(n) Registerdatei(en)-Einheit(en) 2558 führen die Übergabestufe 2524 durch.
Der Kern 2590 kann einen oder mehrere Befehlssätze (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPSA Technologies aus Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie etwa NEON) von ARM Holdings aus Sunnyvale, CA), einschließlich des/der hierin beschriebenen Befehls/Befehle unterstützen. In einer Ausführungsform umfasst der Kern 2590 eine Logik, um eine gepackte Datenbefehlssatzerweiterung (z. B. AVX1, AVX2 und/oder eine beliebige Form des zuvor beschriebenen generischen vektorfreundlichen Befehlsformats (U = 0 und/oder U = 1)) zu unterstützen, wodurch die von vielen Multimedia-Anwendungen verwendeten Operationen mittels gepackten Daten durchgeführt werden können.
Es versteht sich, dass der Kern Multithreading (die Ausführung von zwei oder mehreren parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf eine Vielzahl von Weisen tun kann, einschließlich Zeitscheiben-Multithreading, simultanes Multithreading (bei dem ein einzelner physikalischer Kern einen logischen Kern für jeden der Threads bereitstellt, die der physikalische Kern gleichzeitig multithreaded), oder eine Kombination daraus (z. B. Zeitscheibenabrufen- und Dekodieren und simultanes Multithreading danach, wie etwa bei der Intel^® Hyperthreading-Technologie.
Während das Registerumbenennen im Zusammenhang mit der reihenfolgelosen Ausführung beschrieben wird, versteht es sich, dass Registerumbenennung in einer reihenfolgegebundenen Architektur verwendet wird. Während die veranschaulichte Ausführungsform des Prozessors auch separate Befehls- und Daten-Cache-Einheiten 2534/2574 und eine gemeinsam genutzte L2-Cache-Einheit 2576 umfasst, können alternative Ausführungsformen einen einzelnen internen Cache für sowohl Befehle als auch Daten aufweisen, wie etwa beispielsweise einen internen Ebene-1-(L1-)Cache, oder mehrere Ebenen interner Caches. In manchen Ausführungsformen kann das System eine Kombination aus einem internen Cache und einem externen Cache, der außerhalb des Kerns und/oder des Prozessors liegt, umfassen. Alternativ dazu kann der gesamte Cache außerhalb des Kerns und/oder Prozessors liegen.
12A und 12B veranschaulichen ein Blockdiagramm einer genaueren beispielhaften reihenfolgegebundenen Kernarchitektur, wobei der Kern einer aus mehreren Logik-Blöcken in einem Chip wäre (einschließlich anderer Kerne derselben Art und/oder anderer Arten). Die Logik-Blöcke kommunizieren durch ein verbundenes Netzwerk mit hoher Bandbreite (z. B. ein Ringnetzwerk) mit einer fixierten Funktionslogik, Speicher-I/O-Schnittstellen und anderer notwendiger I/O-Logik, abhängig von der Anwendung.
12A ist ein Blockdiagramm eines einzelnen Prozessorkerns zusammen mit einer Verbindung mit dem verbundenen Netzwerk 2602 auf dem Nacktchip und mit seiner lokalen Teilmenge des Ebene-2-(L2-)Caches 2604, gemäß Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdekodierer 2600 den x86-Befehlssatz mit einer gepackten Datenbefehlssatzerweiterung. Ein L1-Cache 2606 erlaubt Zugriffe mit geringer Wartezeit auf den Cachespeicher in die Skalar- und Vektoreinheiten. Während in einer Ausführungsform (zur Vereinfachung des Designs) eine Skalareinheit 2608 und eine Vektoreinheit 2610 separate Registersätze nutzen (die Skalarregister 2612 bzw. Vektorregister 2614) und zwischen ihnen transferierte Daten werden in den Speicher geschrieben und dann aus einem Ebene-1-(L1-)Cache 2606 wieder zurück eingelesen, alternative Ausführungsformen der Erfindung können einen anderen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad umfassen, der das Transferieren der Daten zwischen den beiden Registerdateien ohne Zurückschreiben und Wiedereinlesen erlaubt).
Die lokale Teilmenge des L2-Caches 2604 ist ein Teil eines globalen L2-Caches, der in separate lokale Teilmengen geteilt ist, eine pro Prozessorkern. Jeder Prozessorkern hat einen direkten Zugriffspfad zu seiner eigenen lokalen Teilmenge des L2-Caches 2604. Von einem Prozessorkern gelesene Daten werden in seiner L2-Cache-Teilmenge 2604 gespeichert und auf sie kann rasch zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen L2-Cache-Teilmengen zugreifen. Von einem Prozessorkern geschriebene Daten werden in seiner eigenen L2-Cache-Teilmenge 2604 gespeichert und gegebenenfalls aus anderen Teilmengen gelöscht. Das Ringnetzwerk garantiert Kohärenz für gemeinsam genutzte Daten. Das Ringnetzwerk ist bidirektional, um Elementen, wie etwa Prozessorkernen, L2-Caches oder andere Logik-Blöcke, zu erlauben miteinander innerhalb des Chips zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012-Bits breit.
12B ist eine vergrößerte Ansicht eines Teils des Prozessorkerns aus 12A gemäß Ausführungsformen der Erfindung. 12B umfasst einen L1-Daten-Cache 2606A, der Teil des L1-Caches 2604 ist, sowie weitere Details bezüglich der Vektoreinheit 2610 und der Vektorregister 2614. Insbesondere ist die Vektoreinheit 2610 eine 16 breite Vektorverarbeitungseinheit (VPU) (siehe die 16 breite ALU 2628), die einen oder mehrere aus Integer, Einzelpräzisionsgleitkomma-, und Doppelpräzisionsgleitkommabefehlen ausführt. Die VPU unterstützt das Swizzeln der Registereingaben mit der Swizzleeinheit 2620, die numerische Umwandlung mit numerischen Umwandlungseinheiten 2622A-B und die Replikation mit der Replikationseinheit 2624 auf der Speichereingabe. Schreibmaskenregister 2626 erlauben das Vorhersagen von resultierenden Vektorschreiboperationenn.
13 ist ein Blockdiagramm eines Prozessors 2700, der gemäß Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Speichersteuereinheit aufweisen kann und integrierte Grafiken aufweisen kann. Die Kästen in 13 mit durchgehenden Linien veranschaulichen einen Prozessor 2700 mit einem Einzelkern 2702A, einen Systemagenten 2710, einen Satz aus einer oder mehreren Bussteuereinheit(en) 2716, während die optionale Hinzufügung der Kästen mit gestrichelten Linien einen alternativen Prozessor mit mehreren Kernen 2702A–N, einem Satz aus einer oder mehreren integrierten Speichersteuereinheit(en) 2714 in der Systemagenteneinheit 2710 und einer Sonderzwecklogik 2708 veranschaulicht.
Somit können die verschiedenen Implementierungen des Prozessors 2700 umfassen: 1) eine CPU mit einer Sonderzwecklogik 2708, die integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik ist (die einen oder mehr Kerne umfassen kann), und wobei die Kerne 2702A–N ein oder mehrere Allzweckkerne sind (z. B. reihenfolgegebundene Allzweckkerne, reihenfolgelose Allzweckkerne, eine Kombination aus den beiden); 2) einen Co-Prozessor, wobei die Kerne 2702A–N eine große Anzahl von Spezialzweckkernen sein können, die in erster Linie für Grafik und/oder Wissenschaft(lichen Durchsatz) vorgesehen sind; und 3) ein Co-Prozessor, wobei die Kerne 2702A–N eine große Anzahl von reihenfolgegebundenen Allzweckkernen sind. Somit kann der Prozessor 2700 ein Allzweckprozessor, Co-Prozessor oder Spezialzweckprozessor sein, wie etwa beispielsweise ein Netzwerk- oder Kommunikationsprozessor, Kompressionsmotor, Grafikprozessor, GPGPU (Kern für Allzweck-Berechnungen auf Grafikprozessoreinheit(en)), ein Hochdurchsatz Many-Integrated-Core-(MIC-)Co-Prozessor (inklusive 30 oder mehr Kernen), ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 2700 kann ein Teil von einem oder mehreren Substrat(en) und/oder darauf implementiert sein, unter Verwendung einer beliebigen aus einer Reihe von Prozesstechnologien, wie etwa beispielsweise BiCMOS, CMOS oder NMOS.
Die Speicherhierarchie umfasst eine oder mehrere Cacheebenen innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsam genutzten Cache-Einheiten 2706 und externen Speicher (nicht gezeigt), der mit dem Satz aus integrierten Speichersteuereinheiten 2714 gekoppelt ist. Der Satz gemeinsam genutzter Cache-Einheiten 2706 kann einen oder mehrere Caches mittlerer Ebene umfassen, wie etwa Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Cache-Ebenen, einen Cache der letzten Ebene (LLC) und/oder Kombinationen daraus. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 2712 die integrierte Grafiklogik 2708, den Satz gemeinsam genutzter Cache-Einheiten 2706 und die Systemagenteneinheit 2710/integrierte Speichersteuereinheit(en) 2714 verbindet, können alternative Ausführungsformen eine beliebige Anzahl wohlbekannter Verfahren zum Verbinden solcher Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einer oder mehreren Cache-Einheiten 2706 und Kernen 2702A–N aufrechterhalten.
In manchen Ausführungsformen ist einer oder mehrere der Kerne 2702A–N multithreading-fähig. Der Systemagent 2710 umfasst diese Komponenten, die die Kerne 2702A–N koordinieren und betreiben. Die Systemagenteneinheit 2710 kann beispielsweise eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit umfassen. Die PCU kann eine Logik und Komponenten sein oder umfassen, die zum Regulieren des Energiezustandes der Kerne 2702A–N und der integrierten Grafiklogik 2708 benötigt werden. Die Anzeigeeinheit dient zum Steuern einer oder mehrerer extern verbundenen Anzeigen.
Die Kerne 2702A–N können in Bezug auf den Architekturbefehlssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 2702A–N können in der Lage sein, denselben Befehlssatz auszuführen, während andere in der Lage sein können, nur eine Teilmenge dieses Befehlssatzes oder eines anderen Befehlssatzes auszuführen.
14 bis 18 sind Blockdiagramme beispielhafter Computerarchitekturen. Andere Systemdesigns und Konfigurationen, die auf dem Gebiet der Erfindung für Laptops, Desktops, Hand-PC, persönliche digitale Assistenten, Technikarbeitsplätze, Server, Netzwerkvorrichtungen, Netzwerkknoten, Schalter, eingebettete Prozessoren, digitale Signalprozessoren (DSP), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrosteuereinheiten, Mobiltelefone, tragbare Medienabspielgeräte, Handheld-Vorrichtungen und verschiedene andere elektronische Vorrichtungen bekannt sind, sind ebenfalls geeignet. Im Allgemeinen ist eine große Vielfalt von Systemen oder elektronischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, zu integrieren, prinzipiell geeignet.
Bezugnehmend nun auf 14 ist ein Blockdiagramm eines Systems 2800 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 2800 kann einen oder mehrere Prozessor(en) 2810, 2815 umfassen, der/die mit einem Steuerknoten 2820 gekoppelt ist/sind. In einer Ausführungsform umfasst der Steuerknoten 2820 einen Grafikspeichersteuerknoten (GMCH) 2890 und einen Eingangs-/Ausgangs-Knoten (IOH) 2850 (die sich auf separaten Chips befinden können); der GMCH 2890 umfasst Speicher- und Grafiksteuereinheiten, mit denen Speicher 2840 und ein Co-Prozessor 2845 gekoppelt sind; der IOH 2850 koppelt Eingangs-/Ausgangs-(I/O-)Vorrichtungen 2860 mit dem GMCH 2890. Alternativ dazu sind eine oder beide der Speicher- und Grafiksteuereinheiten innerhalb des Prozessors integriert (wie hierin beschrieben), der Speicher 2840 und der Co-Prozessor 2845 sind direkt mit dem Prozessor 2810 und dem Steuerknoten 2820, die sich auf einem einzigen Chip mit dem IOH 2850 befinden, gekoppelt.
Die optionale Natur zusätzlicher Prozessoren 2815 wird in 14 durch gebrochene Linien angemerkt. Jeder Prozessor 2810, 2815 kann einen oder mehrere der hierin beschriebenen Prozessorkerne umfassen und kann eine beliebige Version des Prozessors 2700 sein.
Der Speicher 2840 kann beispielsweise ein dynamischer Direktzugriffsspeicher (DRAM), ein Phasenwechselspeicher (PCM) oder eine Kombination aus den beiden sein. Für zumindest eine Ausführungsform kommuniziert der Steuerknoten 2820 mit dem/den Prozessor(en) 2810, 2815 über einen Multi-Drop-Bus, wie etwa einem Front-Side-Bus (FSB), einer Punkt-zu-Punkt-Verbindung, wie etwa QuickPath Interconnect (QPI) oder einer ähnlichen Verbindung 2895.
In einer Ausführungsform ist der Co-Prozessor 2845 ein Spezialzweckprozessor, wie etwa beispielsweise ein Hochdurchsatz-MIC-Prozessor, ein Netzwerk- oder Kommunikationsprozessor, ein Kompressionsmotor, ein Grafikprozessor, GPGPU, eingebetteter Prozessor und dergleichen. In einer Ausführungsform kann der Steuerknoten 2820 einen integrierten Grafikbeschleuniger umfassen.
Es kann eine Vielzahl von Unterschieden zwischen den physikalischen Ressourcen 2810, 2815 in Bezug auf das Metrikspektrum geben, einschließlich architektonische, mikroarchitektonische, thermische, bezüglich der Leistungsverbrauchseigenschaften und dergleichen.
In einer Ausführungsform führt der Prozessor Befehle aus, die Steuerdatenverarbeitungsoperationen einer allgemeinen Art ausführen. Innerhalb der Befehle können Co-Prozessorbefehle eingebettet sein. Der Prozessor 2810 erkennt diese Co-Prozessorbefehle als von einer Art, die vom angehängten Co-Prozessor 2845 ausgeführt werden sollte. Demgemäß gibt der Prozessor 2810 diese Co-Prozessorbefehle (oder Steuersignale, die Co-Prozessorbefehle darstellen) auf einem Co-Prozessorbus oder einer anderen Verbindung an den Co-Prozessor 2845 aus. Der/Die Co-Prozessor(en) 2845 nehmen die empfangenen Co-Prozessorbefehle an und führen sie aus.
Bezugnehmend nun auf 15 ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 2900 in Übereinstimmung mit einer ausführungsform der vorliegenden Erfindung gezeigt. Wie in 15 gezeigt ist das Multiprozessorsystem 2900 ein Punkt-zu-Punkt-Verbindungssystem und umfasst einen ersten Prozessor 2970 und einen zweiten Prozessor 2980, der über eine Punkt-zu-Punkt-Schnittstelle 2950 gekoppelt ist. Jeder der Prozessoren 2970 und 2980 kann eine beliebige Version des Prozessors 2700 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 2970 und 2980 die Prozessoren 2810 bzw. 2815, während der Co-Prozessor 2938 der Co-Prozessor 2845 ist. In einer anderen Ausführungsform sind die Prozessoren 2970 und 2980 die Prozessoren 2810 bzw. Co-Prozessor 2845.
Die Prozessoren 2970 und 2980 werden als die integrierten Speichersteuereinheiten (IMC) 2972 bzw. 2982 umfassend gezeigt. Prozessor 2970 umfasst auch als Teil seiner Bussteuereinheiten Punkt-zu-Punkt-(P-P-)Schnittstellen 2976 und 2978; ebenso umfasst der zweite Prozessor 2980 P-P-Schnittstellen 2986 und 2988. Die Prozessoren 2970, 2980 können Informationen über eine Punkt-zu-Punkt-(P-P-)Schnittstelle 2950 mittels der P-P-Schnittstellenschaltkreise 2978, 2988 austauschen. Wie in 15 gezeigt, koppeln die IMC 2972 und 2982 die Prozessoren mit entsprechenden Speichern, nämlich einem Speicher 2932 und einem Speicher 2934, die Anteile des an die entsprechenden Prozessoren lokal angehängten Hauptspeichers sein können.
Die Prozessoren 2970, 2980 können Informationen mit einem Chipsatz 2990 über individuelle P-P-Schnittstellen 2952, 2954 mittels Punkt-zu-Punkt-Schnittstellenschaltkreise 2976, 2994, 2986, 2998 austauschen. Der Chipsatz 2990 kann gegebenenfalls Informationen mit dem Co-Prozessor 2938 über eine Hochleistungsschnittstelle 2939 austauschen. In einer Ausführungsform ist der Co-Prozessor ein Sonderzweckprozessor, wie etwa beispielsweise ein Hochdurchsatz-MIC-Prozessor, ein Netzwerk- oder Kommunikationsprozessor, ein Kompressionsmotor, Grafikprozessor, GPGPU, eingebetteter Prozessor oder dergleichen.
Ein gemeinsam genutzter Cache (nicht gezeigt) kann bei einem der beiden Prozessoren oder außerhalb beider Prozessoren umfasst sein, wobei er mit den Prozessoren über eine P-P-Schnittstelle verbunden ist, so dass die lokale Cache-Information von einem der beiden oder beiden Prozessoren in dem gemeinsam genutzten Cache gespeichert werden kann, wenn der Prozessor in einem Energiesparmodus versetzt wird. Der Chipsatz 2990 kann mit einem ersten Bus 2916 über eine Schnittstelle 2996 gekoppelt sein. In einer Ausführungsform kann der erste Bus 2916 ein Peripheral-Component-Interconnect-(PCI-)Bus oder ein Bus, wie etwa ein PCI-Express-Bus oder ein anderer I/O-Verbindungsbus der dritten Generation sein, obwohl der Schutzumfang der Erfindung dahingehend nicht eingeschränkt ist.
Wie in 15 gezeigt können verschiedene I/O-Vorrichtungen 2914 mit dem ersten Bus 2916 gekoppelt sein, zusammen mit einer Busbrücke 2918, die den ersten Bus 2916 mit einem zweiten Bus 2920 koppelt. In einer Ausführungsform ist/sind ein oder mehrere zusätzliche(r) Prozessor(en) 2915, wie etwa Co-Prozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPU, Beschleuniger (wie etwa z. B. Grafikbeschleuniger oder digitale Signalverarbeitungs-(DSP-)Einheiten, programmierbare(Logik-)Gatter-Anordnungen oder jeder andere Prozessor, mit dem ersten Bus 2916 gekoppelt. In einer Ausführungsform kann der zweite Bus 2920 ein Low-Pin-Count-(LPC-)Bus sein. Verschiedene Vorrichtungen können mit einem zweiten Bus 2920 gekoppelt sein, einschließlich beispielsweise einer Tastatur und/oder Maus 2922, Kommunikationsvorrichtungen 2927 und einer Speichereinheit 2928, wie etwa eines Disk-Laufwerks oder einer anderen Massenspeichervorrichtung, die Befehle/Code und Daten 2930 umfassen können, in einer Ausführungsform. Zudem kann eine Audio-I/O 2924 mit dem zweiten Bus 2920 gekoppelt sein. Es wird vermerkt, dass auch andere Architekturen möglich sind. Beispielsweise kann ein System anstelle der Punkt-zu-Punkt-Architektur aus 15 einen Multi-Drop-Bus oder eine andere Architektur dieser Art implementieren.
Nun auf 16 Bezug nehmend ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 3000 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Gleiche Elemente in 16 und 17 tragen dieselben Bezugszeichen und gewisse Aspekte aus 15 wurden in 16 ausgelassen, um zu vermeiden, dass andere Aspekte von 16 unklar gemacht werden. 16 veranschaulicht, dass die Prozessoren 2970, 2980 integrierte Speicher und I/O-Steuerlogik („CL”) 2972 bzw. 2982 umfassen können. Somit umfassen die CL 2972, 2982 integrierte Speichersteuereinheiten und umfassen I/O-Steuerlogik. 16 veranschaulicht, dass die Speicher 2932, 2934 nicht nur mit der CL 2972, 2982 gekoppelt sind, sondern auch, dass die I/O-Vorrichtungen 3014 ebenfalls mit der Steuerlogik 2972, 2982 gekoppelt sind. I/O-Vorrichtungen der älteren Generation 3015 sind mit dem Chipsatz 2990 gekoppelt.
Bezugnehmend nun auf 17 ist ein Blockdiagramm eines SoC 2100 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 13 tragen dieselben Bezugszeichen. Ebenso sind Kästen mit gestrichelten Linien optionale Merkmale auf fortschrittlicheren SoC. In 17 ist/sind (eine) Verbindungseinheit(en) gekoppelt mit: einem Anwendungsprozessor 3110, der einen Satz aus einem oder mehreren Kernen 202A–N und (einer) gemeinsam genutzten Cache-Einheit(en) 2706 umfasst; einer Systemagenteneinheit 2710; (einer) Bussteuereinheit(en) 2716; (einer) integrierten Speichersteuereinheit(en) 2714; einem Satz aus einem oder mehreren Co-Prozessoren 3120, die integrierte Grafik-Logik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor umfassen können; einer statischen Direktzugriffsspeicher-(SRAM-)Einheit 3130; einer Speicherdirektzugriffs-(DMA-)Einheit 3132; und einer Anzeigeeinheit 3140 für die Kopplung mit einer oder mehreren externen Anzeigen. In einer Ausführungsform umfasst/umfassen der/die Co-Prozessor(en) 3120 einen Sonderzweckprozessor, wie etwa beispielsweise einen Netzwerk- oder Kommunikationsprozessor, Kompressionsmotor, GPGPU, einem Hochdurchsatz-MIC-Prozessor, eingebetteten Prozessor oder dergleichen.
Ausführungsformen der hierin offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination aus solchen Implementierungsansätzen implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, der auf programmierbaren Systemen ausgeführt wird, die zumindest einen Prozessor, ein Speichersystem (einschließlich flüchtigem und nichtflüchtigem Speicher und/oder Speicherelementen), zumindest eine Eingabevorrichtung und zumindest eine Ausgabevorrichtung umfasst.
Programmcode, wie etwa der in 15 veranschaulichte Code 2930 kann auf Eingangsbefehle angewandt werden, um die hierin beschriebenen Funktionen durchzuführen und Ausgangsinformation zu erzeugen. Die Ausgangsinformation kann auf eine oder mehrere Ausgangsvorrichtungen auf bekannte Weise angewandt werden. Für die Zwecke dieser Anmeldung umfasst ein Verarbeitungssystem ein beliebiges System, das einen Prozessor, wie etwa beispielsweise; einen Digitalsignalprozessor (DSP-), eine Mikrosteuereinheit, eine anwendungsspezifische interne Schaltung (ASIC) oder einen Mikroprozessor, aufweist.
Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache implementiert sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann, wenn gewünscht, auch in Assembler- oder Maschinensprache implementiert sein. Tatsächlich sind die hierin beschriebenen Mechanismen nicht auf den Umfang einer bestimmten Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Ein oder mehrere Aspekte von zumindest einer Ausführungsform kann durch repräsentative Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logiken innerhalb des Prozessors darstellt, die, wenn sie von einer Maschine gelesen werden, die Maschine dazu veranlassen, eine Logik herzustellen, um die hierin beschriebenen Verfahren durchzuführen. Solche Darstellungen, bekannt als „IP-Kerne”, können auf einem greifbaren, maschinenlesbaren Medium gespeichert werden und verschiedenen Kunden oder Produktionsanlagen bereitgestellt werden, um sie in die Produktionsmaschinen, die die Logik oder den Prozessor tatsächlich herstellen, zu laden.
Solche maschinenlesbare Speichermedien können umfassen, ohne darauf beschränkt zu sein, nichttransistorische, greifbare Anordnungen von Gegenständen, die von einer Maschine oder einer Vorrichtung ausgebildet werden, einschließlich Speichermedien, wie etwa Festplatten, jede andere Art von Disk, einschließlich Floppy-Disks, optischer Disks, Compact Disc Read-Only Memorys (CD-ROM), Compact-Disk-Rewritable's (CD-RW) und magnetooptische Disks, Halbleitervorrichtungen, wie etwa Festwertspeicher (ROM), Direktzugriffsspeicher (RAM), dynamische Direktzugriffsspeicher (DRAM), statische Direktzugriffsspeicher (SRAM), löschbare programmierbare Nur-Lese-Speicher (EPROM), Flash-Speicher, elektrisch lösbare programmierbare Nur-Lese-Speicher (EEPROM), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder jede andere Art von Medium, die sich zum Speichern elektronischer Befehle eignet.
Demgemäß können Ausführungsformen der Erfindung auch nichttransistorische, greifbare maschinenlesbare Medien umfassen, die Befehle enthalten oder Aufbaudaten, wie etwa Hardwarebeschreibungssprache (HDL), enthalten, die hierin beschriebene Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemeigenschaften definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
In manchen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl aus einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Beispielsweise kann der Befehlsumwandler übersetzen (z. B. mittels statischer Binärübersetzung, dynamischer Binärübersetzung, einschließlich dynamischer Kompilierung), morphen, emulieren oder einen Befehl anderweitig in einen oder mehrere andere vom Kern zu verarbeitende Befehle umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination daraus umgesetzt sein. Der Befehlsumwandler kann sich auf dem Prozessor, nicht auf dem Prozessor oder teilweise auf und teilweise nicht auf dem Prozessor befinden.
18 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung darstellt. In der veranschaulichten Ausführungsform ist der Befehlsumwandler ein Softwarebefehlsumwandler, obwohl der Befehlsumwandler alternativ dazu in Software, Firmware, Hardware oder Kombinationen daraus umgesetzt sein kann. 18 zeigt, dass ein Programm in einer höheren Programmiersprache 3202 mit Hilfe eines x86 Compilers 3204 kompiliert werden kann, um x86 Binärcode 3206 zu erzeugen, der von einem Prozessor mit zumindest einem x86 Befehlssatzkern 3216 nativ ausgeführt werden kann. Der Prozessor mit zumindest einem x86 Befehlssatzkern 3216 stellt einen beliebigen Prozessor dar, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit zumindest einem x86 Befehlssatzkern ausführen, indem er (1) einen wesentlichen Anteil des Befehlssatzes des Intel x86 Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die für die Ausführung auf einem Intel-Prozessor mit zumindest einem x86 Befehlssatzkern ausgerichtet ist, kompatibel ausführt oder anderweitig verarbeitet, um im Wesentlichen dasselbe Ergebnis wie ein Intel-Prozessor mit zumindest einem x86 Befehlssatzkern zu erreichen. Der x86 Compiler 3204 stellt einen Compiler dar, der zum Erzeugen von x86 Binärcode 3206 (z. B. Objektcode) betätigbar ist, der mit oder ohne zusätzlicher Verlinkungsbearbeitung auf dem Prozessor mit zumindest einem x86 Befehlssatzkern 3216 ausgeführt werden kann. 18 zeigt ebenso, dass das Programm in der höheren Programmiersprache unter Verwendung eines alternativen Befehlssatz-Compilers 3208 kompiliert werden kann, um einen alternativen Befehlssatzbinärcode 3210 zu erzeugen, der von einem Prozessor ohne zumindest einen x86 Befehlssatzkern 3214 (z. B. ein Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA, ausführen und/oder die den ARM-Befehlssatz von ARMS Holdings aus Sunnyvale, CA, ausführen) nativ ausgeführt werden kann. Der Befehlsumwandler 3212 wird verwendet, um den x86 Binärcode 3206 in Code umzuwandeln, der von dem Prozessor ohne einen x86 Befehlssatzkern 3214 nativ ausgeführt werden kann. Dieser umgewandelte Code ist vermutlich nicht derselbe wie der alternative Befehlssatzbinärcode 3210, weil ein Befehlsumwandler, der dazu in der Lage ist, schwierig herzustellen ist; jedoch wird der umgewandelte Code den allgemeine Operation bewerkstelligen und wird aus Befehlen vom alternativen Befehlssatz bestehen. Somit stellt der Befehlsumwandler 3212 Software, Firmware, Hardware oder eine Kombination daraus dar, die durch es einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86 Befehlssatzprozessor oder -kern aufweist, durch Emulation, Simulation oder jeden anderen Prozess den x86 Binärcode 3206 auszuführen.
Gemäß einer Ausführungsform umfasst ein Prozessor eine Befehlsplanungs- und Versand-(Planungs-/Versand-)Einheit, um einen Single-Instruction-Multiple-Data-(SIMD-)Befehl zu empfangen, um eine Operation auf einer Vielzahl von Datenelementen, die an einer von einem ersten Quelloperanden angegebenen Speicherposition gespeichert werden, durchzuführen, wobei die Befehlsplanungs- und Versandeinheit ein erstes der Datenelemente, die nicht betätigt werden, bestimmt, um ein Ergebnis zu erzeugen, das basierend auf einen zweiten Quelloperanden in einen Zieloperanden geschrieben wird; eine Vielzahl von Verarbeitungselementen, die mit der Befehlsplanungs- und Versandeinheit gekoppelt sind, um die Datenelemente des SIMD-Befehls auf Vektorart zu verarbeiten; und eine mit der Befehlsplanungs- und Versandeinheit gekoppelte Energieverwaltungseinheit, um den Energieverbrauch eines für die Verarbeitung des ersten Datenelements konfigurierten ersten der Verarbeitungselemente zu reduzieren.
Die Energieverwaltungseinheit umfasst eine Clock-Gating-Logik, um eine Taktfrequenz eines Taktsignals auf das erste Verarbeitungselement zu reduzieren. Die Clock-Gating-Logik ist dazu konfiguriert, das Taktsignal zum ersten Verarbeitungselement abzuschalten. Die Energieverwaltungseinheit ist dazu konfiguriert, die Taktfrequenz an eine arithmetische Logikeinheit (ALU) des zur Verarbeitung des ersten Datenelements konfigurierten ersten Verarbeitungselements zu reduzieren. Die Energieverwaltungseinheit ist dazu konfiguriert, den Energieverbrauch an einen Rückschreibepfad der dem ersten Datenelement zugeordneten Ruhestandseinheit zu reduzieren. Die Energieverwaltungseinheit ist dazu konfiguriert, den Energieverbrauch an einen Datenbus-Versandpfad zu einer dem ersten Datenelement zugeordneten Speicherposition zu reduzieren. Der zweite Quelloperand umfasst eine Vielzahl von Bits, die den Datenelementen entsprechen, wobei jedes Bit einen logischen Wert speichert, der angibt, ob ein entsprechendes Datenelement betätigt werden soll.
Gemäß manchen Aspekten umfasst ein Prozessor eine Befehlsplanungs- und Versand-(Planungs-/Versand-)Einheit, um einen Single-Instruction-Multiple-Data-(SIMD-)Befehl zu empfangen, um eine Operation auf einer Vielzahl von Datenelementen, die an einer von einem ersten Quelloperanden angegebenen Speicherposition gespeichert werden, durchzuführen, wobei die Befehlsplanungs- und Versandeinheit ein erstes der Datenelemente, die nicht betätigt werden, bestimmt, um ein Ergebnis zu erzeugen, das basierend auf einen zweiten Quelloperanden in einen Zieloperanden geschrieben wird; eine Vielzahl von Verarbeitungselementen, die mit der Befehlsplanungs- und Versandeinheit gekoppelt sind, um die Datenelemente des SIMD-Befehls auf Vektorart zu verarbeiten; und eine mit der Befehlsplanungs- und Versandeinheit gekoppelte Energieverwaltungseinheit, um den Energieverbrauch eines für die Verarbeitung des ersten Datenelements konfigurierten ersten der Verarbeitungselemente zu reduzieren. Die Energieverwaltungseinheit umfasst eine Clock-Gating-Logik, um eine Taktfrequenz eines Taktsignals an das erste Verarbeitungselement zu reduzieren. Die Clock-Gating-Logik ist dazu konfiguriert, das Taktsignal an das erste Verarbeitungselement abzuschalten. Die Energieverwaltungseinheit ist dazu konfiguriert, die Taktfrequenz an eine arithmetische Logikeinheit (ALU) des zur Verarbeitung des ersten Datenelements konfigurierten ersten Verarbeitungselements zu reduzieren. Die Energieverwaltungseinheit ist dazu konfiguriert, den Energieverbrauch an einen Rückschreibepfad der dem ersten Datenelement zugeordneten Ruhestandseinheit zu reduzieren. Die Energieverwaltungseinheit ist dazu konfiguriert, den Energieverbrauch an einen Datenbus-Versandpfad zu einer dem ersten Datenelement zugeordneten Speicherposition zu reduzieren. Der zweite Quelloperand umfasst eine Vielzahl von Bits, die den Datenelementen entsprechen, wobei jedes Bit einen logischen Wert speichert, der angibt, ob ein entsprechendes Datenelement betätigt werden soll.
Manche Abschnitte der vorstehenden detaillierten Beschreibung wurden in Form von Algorithmen und symbolischen Darstellungen von Operationenn auf Datenbits innerhalb eines Computerspeichers dargestellt. Diese algorithmischen Beschreibungen und Darstellungen sind die Wege, die von Fachleuten auf dem Gebiet der Datenverarbeitung verwendet werden, um das Wesentliche ihrer Arbeit anderen Fachleuten am wirksamsten zu vermitteln. Ein Algorithmus versteht sich hier, und allgemein, als eine in sich konsistente Operationssequenz, die zu einem gewünschten Ergebnis führt. Diese Operationen sind jene, die physikalische Manipulationen physikalischer Quantitäten erfordern.
Es sollte jedoch beachtet werden, dass all diese und ähnliche Begriffe mit den entsprechenden physikalischen Quantitäten assoziiert werden müssen und lediglich passende Bezeichnungen sind, die diesen Quantitäten gegeben wurden. Sofern nicht anders angegeben als aus der obenstehenden Diskussion ersichtlich, versteht es sich, dass in der gesamten Beschreibung Diskussionen, die Begriffe, wie die in den nachfolgenden Patentansprüchen dargelegten, die Handlung und Prozesse eines Computersystems oder einer ähnlichen elektronischen Rechenvorrichtung betreffen, die als physikalische (elektronische) Quantitäten dargestellte Daten innerhalb der Register und Speicher des Computersystems in andere Daten manipuliert oder transformiert, die ebenso als physikalische Quantitäten innerhalb der Speicher oder Register des Computersystems oder anderer solcher Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen dargestellt werden.
Die in den Figuren gezeigten Verfahren können unter Verwendung von auf einer oder mehreren elektronischen Vorrichtungen gespeicherten und ausgeführten Code und Daten implementiert werden. Solche elektronischen Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netzwerk) Code und Daten unter Verwendung computerlesbarer Medien, wie etwa nichttransistorischer computerlesbarer Speichermedien (z. B. Magnetdisks; optische Disks; Direktzugriffsspeicher; Festwertspeicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und transitorische computerlesbare Übertragungsmedien (z. B. elektrische, optische, akustische und eine andere Art von verbreiteten Signalen – wie etwa Trägerwellen, Infrarotsignale, digitale Signale).
Die in den vorangegangenen Figuren abgebildeten Prozesse oder Verfahren können von einer Verarbeitungslogik, die Hardware (z. B. Schaltkreise, zweckgewidmete Logik etc.), Firmware, Software (z. B. eingebettet auf einem nichttransistorischen computerlesbaren Medium) oder eine Kombination aus beidem umfasst, durchgeführt werden. Obwohl die obenstehenden Prozesse oder Verfahren hinsichtlich einiger sequenzieller Operationen beschrieben wurden, versteht es sich, dass manche der beschriebenen Operationen in einer anderen Reihenfolge durchgeführt werden können. Darüber hinaus können manche Operationen parallel anstatt sequenziell ausgeführt werden.
In der vorangegangenen Beschreibung wurden Ausführungsformen der Erfindung mit Bezug auf spezifische beispielhafte Ausführungsformen davon beschrieben. Es wird ersichtlich, dass verschiedene Modifikationen daran vorgenommen werden können, ohne vom Geist und Schutzumfang der Erfindung, wie in den nachstehenden Patentansprüchen dargelegt, abzuweichen. Die Beschreibung und Zeichnungen sollen demgemäß in einem veranschaulichenden Sinne anstatt einem einschränkenden Sinne verstanden werden.

Claims

Prozessor, umfassend: eine Befehlsplanungs- und -versandeinheit (Planungs-/Versandeinheit), um einen Single-Instruction-Multiple-Data-Befehl (SIMD-Befehl) zu empfangen, um eine Operation auf eine Vielzahl von Datenelementen anzuwenden, die an einem durch einen ersten Quelloperanden angezeigten Speicherort gespeichert sind, wobei die Befehlsplanungs-/Versandeinheit ein erstes der Datenelemente bestimmen soll, das nicht bearbeitet wird, um ein in einen Zieloperanden geschriebenes Ergebnis basierend auf einem zweiten Quelloperanden zu erzeugen; eine Vielzahl mit der Befehlsplanungs-/Versandeinheit gekoppelter Verarbeitungselemente, um die Datenelemente des SIMD-Befehls auf eine Vektorart zu verarbeiten; und eine mit der Befehlsplanungs-/Versandeinheit gekoppelte Energieverwaltungseinheit, um den Energieverbrauch eines ersten der Verarbeitungselemente, das für die Verarbeitung des ersten Datenelements konfiguriert ist, zu reduzieren.
Prozessor nach Anspruch 1, wobei die Energieverwaltungseinheit eine Clock-Gating-Logik umfasst, um eine Taktfrequenz eines Taktsignals an das erste Verarbeitungselement zu reduzieren.
Prozessor nach Anspruch 2, wobei die Clock-Gating-Logik dazu konfiguriert ist, das Taktsignal an das erste Verarbeitungselement abzuschalten.
Prozessor nach Anspruch 2, wobei die Energieverwaltungseinheit dazu konfiguriert ist, die Taktfrequenz an eine arithmetisch logische Einheit (ALU) des ersten Verarbeitungselements, das für die Verarbeitung des ersten Datenelements konfiguriert ist, zu reduzieren.
Prozessor nach Anspruch 2, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch einer dem ersten Datenelement zugeordneten Registerdatei zu reduzieren.
Prozessor nach Anspruch 2, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch eines Rückschreibepfads einer dem ersten Datenelement zugeordneten Ruhestandseinheit zu reduzieren.
Prozessor nach Anspruch 2, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch eines Datenbusversandpfads zu einem dem ersten Datenelement zugeordneten Speicherort zu reduzieren.
Prozessor nach Anspruch 1, wobei der zweite Quelloperand eine Vielzahl von den Datenelementen entsprechenden Bits umfasst, wobei jedes Bit einen logischen Wert speichert, der angibt, ob ein entsprechendes Datenelement bearbeitet werden sollte.
Verfahren, umfassend: das Empfangen an einer Befehlsplanungs- und -versandeinheit (Planungs-/Versandeinheit) eines Prozessors von einem Single-Instruction-Multiple-Data-Befehl (SIMD-Befehl), um eine Operation auf eine Vielzahl von Datenelementen anzuwenden, die die an einem durch einen ersten Quelloperanden angezeigten Speicherort gespeichert sind, wobei die Befehlsplanungs-/Versandeinheit ein erstes der Datenelemente bestimmen soll, das nicht bearbeitet wird, um ein in einen Zieloperanden geschriebenes Ergebnis basierend auf einem zweiten Quelloperanden zu erzeugen; das Verarbeiten der Datenelemente des SIMD-Befehls auf eine Vektorart durch eine Vielzahl mit der Befehlsplanungs-/Versandeinheit gekoppelter Verarbeitungselemente; und das Reduzieren des Energieverbrauchs eines ersten der Verarbeitungselemente, das für die Verarbeitung des ersten Datenelements konfiguriert ist, durch eine mit der Befehlsplanungs-/Versandeinheit gekoppelte Energieverwaltungseinheit.
Verfahren nach Anspruch 9, wobei die Energieverwaltungseinheit eine Clock-Gating-Logik umfasst, um eine Taktfrequenz eines Taktsignals an das erste Verarbeitungselement zu reduzieren.
Verfahren nach Anspruch 2, wobei die Clock-Gating-Logik dazu konfiguriert ist, das Taktsignal an das erste Verarbeitungselement abzuschalten.
Verfahren nach Anspruch 10, wobei die Energieverwaltungseinheit dazu konfiguriert ist, die Taktfrequenz an eine arithmetisch logische Einheit (ALU) des ersten Verarbeitungselements, das für die Verarbeitung des ersten Datenelements konfiguriert ist, zu reduzieren.
Verfahren nach Anspruch 10, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch einer dem ersten Datenelement zugeordneten Registerdatei zu reduzieren.
Verfahren nach Anspruch 10, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch eines Rückschreibepfads einer dem ersten Datenelement zugeordneten Ruhestandseinheit zu reduzieren.
Verfahren nach Anspruch 10, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch eines Datenbusversandpfads zu einem dem ersten Datenelement zugeordneten Speicherort zu reduzieren.
Verfahren nach Anspruch 9, wobei der zweite Quelloperand eine Vielzahl von den Datenelementen entsprechenden Bits umfasst, wobei jedes Bit einen logischen Wert speichert, der angibt, ob ein entsprechendes Datenelement bearbeitet werden sollte.
System, umfassend: eine Verbindung; einen mit der Verbindung gekoppelten dynamischen Direktzugriffsspeicher (DRAM); und einen mit der Verbindung gekoppelten Prozessor, wobei der Prozessor umfasst eine Befehlsplanungs- und -versandeinheit (Planungs-/Versandeinheit), um einen Single-Instruction-Multiple-Data-Befehl (SIMD-Befehl) zu empfangen, um eine Operation auf eine Vielzahl von Datenelementen anzuwenden, die an einem durch einen ersten Quelloperanden angezeigten Speicherort gespeichert sind, wobei die Befehlsplanungs-/Versandeinheit ein erstes der Datenelemente bestimmen soll, das nicht bearbeitet wird, um ein in einen Zieloperanden geschriebenes Ergebnis basierend auf einem zweiten Quelloperanden zu erzeugen; eine Vielzahl mit der Befehlsplanungs-/Versandeinheit gekoppelter Verarbeitungselemente, um die Datenelemente des SIMD-Befehls auf eine Vektorart zu verarbeiten; und eine mit der Befehlsplanungs-/Versandeinheit gekoppelte Energieverwaltungseinheit, um den Energieverbrauch eines ersten der Verarbeitungselemente, das für die Verarbeitung des ersten Datenelements konfiguriert ist, zu reduzieren.
System nach Anspruch 17, wobei die Energieverwaltungseinheit eine Clock-Gating-Logik umfasst, um eine Taktfrequenz eines Taktsignals an das erste Verarbeitungselement zu reduzieren.
System nach Anspruch 18, wobei die Clock-Gating-Logik dazu konfiguriert ist, das Taktsignal an das erste Verarbeitungselement abzuschalten.
System nach Anspruch 18, wobei die Energieverwaltungseinheit dazu konfiguriert ist, die Taktfrequenz an eine arithmetisch logische Einheit (ALU) des ersten Verarbeitungselements, das für die Verarbeitung des ersten Datenelements konfiguriert ist, zu reduzieren.
System nach Anspruch 18, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch einer dem ersten Datenelement zugeordneten Registerdatei zu reduzieren.
System nach Anspruch 18, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch eines Rückschreibepfads einer dem ersten Datenelement zugeordneten Ruhestandseinheit zu reduzieren.
System nach Anspruch 18, wobei die Energieverwaltungseinheit dazu konfiguriert ist, den Energieverbrauch eines Datenbusversandpfads zu einem dem ersten Datenelement zugeordneten Speicherort zu reduzieren.
System nach Anspruch 17, wobei der zweite Quelloperand eine Vielzahl von den Datenelementen entsprechenden Bits umfasst, wobei jedes Bit einen logischen Wert speichert, der angibt, ob ein entsprechendes Datenelement bearbeitet werden sollte.