DE112016005849T5

DE112016005849T5 - Hardwarebeschleuniger und Verfahren für zustandsbehafetete Komprimierungs- und Dekomprimierungsoperationen

Info

Publication number: DE112016005849T5
Application number: DE112016005849.7T
Authority: DE
Inventors: Tracy Garrett Drysdale; James D. Guilford; Vinodh Gopal; Gilbert M. Wolrich; James T. Kukunas
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-12-20
Filing date: 2016-11-21
Publication date: 2018-08-30
Also published as: DE112016005849T8; US20170177404A1; TW201730752A; TWI729024B; WO2017112233A1; US10169073B2

Abstract

Verfahren und Einrichtungen im Zusammenhang mit zustandsbehafteten Komprimierungs- und Dekomprimierungsoperationen werden beschrieben. In einer Ausführungsform umfasst ein Hardwareprozessor einen Kern zum Ausführen eines Strangs und Auslagern von einem Komprimierungs- und/oder Dekomprimierungsstrang und einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger zum Ausführen des Komprimierungs- und/oder Dekomprimierungsstrangs zum Verbrauchen von Eingabe- und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist.

Description

TECHNISCHES GEBIET
Die Offenbarung bezieht sich allgemein auf Elektronik, und insbesondere bezieht sich eine Ausführungsform der Offenbarung auf einen Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger zum Durchführen einer Komprimierungsoperation und/oder Dekomprimierungsoperation.
HINTERGRUND
Ein Prozessor, oder eine Menge von Prozessoren, führt Befehle aus einem Befehlssatz, z. B. der Befehlssatzarchitektur (ISA, Instruction Set Architecture), aus. Der Befehlssatz ist der Teil der Computerarchitektur, der sich auf Programmierung bezieht, und umfasst allgemein die systemeigenen Datentypen, Befehle, Registerarchitektur, Adressierungsmodi, Speicherarchitektur, Unterbrechungs- und Ausnahmenbehandlung und externe Eingabe und Ausgabe (E/A). Es ist anzumerken, dass der Begriff „Befehl“ sich hier auf einen Makrobefehl, d. h. einen Befehl, der dem Prozessor zur Ausführung bereitgestellt wird, oder auf einen Mikrobefehl, d. h. einen Befehl, der aus dem Decodieren von Makrobefehlen durch den Decodierer eines Prozessors resultiert, beziehen kann.
Figurenliste
Die vorliegende Offenbarung wird in den Figuren der beigefügten Zeichnungen als Beispiel und nicht als Einschränkung dargestellt, wobei ähnliche Bezüge ähnliche Elemente anzeigen und wobei:

1 stellt einen Hardwareprozessor einschließlich mehrerer Kerne und Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger gemäß Ausführungsformen der Offenbarung dar.
2 stellt eine Verarbeitungsvorrichtung und einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger gemäß Ausführungsformen der Offenbarung dar.
3 stellt einen Hardwareprozessor umfassend mehrere Kerne, eine Hardwarebeschleunigeranforderungsverwaltung und Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger gemäß Ausführungsformen der Offenbarung dar.
4 stellt ein Flussdiagramm gemäß Ausführungsformen der Offenbarung dar.
5 stellt ein Flussdiagramm einer Beschleunigungsoperation gemäß Ausführungsformen der Offenbarung dar.
6A ist ein Blockdiagramm, ein generisches vektorfreundliches Befehlsformat und Klasse-A-Befehlsvorlagen davon darstellend, gemäß Ausführungsformen der Offenbarung.
6B ist ein Blockdiagramm, das generische vektorfreundliche Befehlsformat und Klasse-B-Befehlsvorlagen davon darstellend, gemäß Ausführungsformen der Offenbarung.
7A ist ein Blockdiagramm, Felder für die generischen vektorfreundlichen Befehlsformate in 6A und 6B darstellend, gemäß Ausführungsformen der Offenbarung.
7B ist ein Blockdiagramm, die Felder des spezifischen vektorfreundlichen Befehlsformats in Figur 7A, die ein volles Opcode-Feld bilden, darstellend, gemäß einer Ausführungsform der Offenbarung.
7C ist ein Blockdiagramm, die Felder des spezifischen vektorfreundlichen Befehlsformats in Figur 7A, die ein Registerindexfeld bilden, darstellend, gemäß einer Ausführungsform der Offenbarung.
7D ist ein Blockdiagramm, die Felder des spezifischen vektorfreundlichen Befehlsformats in Figur 7A, die das Zusatzoperationsfeld 650 bilden, darstellend, gemäß einer Ausführungsform der Offenbarung.
8 ist ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Offenbarung.
9A ist ein Blockdiagramm, das sowohl eine beispielhafte reihenfolgetreue (In-order) Pipeline als auch eine beispielhafte reihenfolgeveränderte (Out-of-order) Ausgabe-/Ausführungspipeline mit Registerumbenennung gemäß Ausführungsformen der Offenbarung darstellt.
9B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines reihenfolgetreuen (In-order) Architekturkerns als auch eines reihenfolgeveränderten (Out-of-order) Ausgabe-/Ausführungs-Architekturkerns mit Registerumbenennung, in einen Prozessor einzuschließen, gemäß Ausführungsformen der Offenbarung darstellt.
10A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung zu dem On-Die-Verbindungsnetzwerk und mit seinem lokalen Teilsatz des Level-2-Caches (L2), gemäß Ausführungsformen der Offenbarung.
10B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 10A gemäß Ausführungsformen der Offenbarung.
11 ist ein Blockdiagramm eines Prozessors, der mehr als einen Kern haben kann, der eine integrierte Speichersteuerung haben kann und der integrierte Grafik haben kann, gemäß Ausführungsformen der Offenbarung.
12 ist ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Offenbarung.
13 ist ein Blockdiagramm eines spezifischeren beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Offenbarung.
14 ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Offenbarung.
15 ist ein Blockdiagramm eines Systems-on-a-Chip (SoC) gemäß einer Ausführungsform der vorliegenden Offenbarung.
16 ist ein Blockdiagramm, die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz abgesetzt darstellend, gemäß Ausführungsformen der Offenbarung.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt. Allerdings versteht es sich, dass Ausführungsformen der Offenbarung ohne diese spezifischen Details umgesetzt sein können. In anderen Fällen sind wohl bekannte Schaltungen, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis dieser Beschreibung nicht einzutrüben.
Bezugnahmen in der Spezifikation auf „eine Ausführungsform“, „eine beispielhafte Ausführungsform“ usw. zeigen an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine Struktur oder Charakteristik umfassen kann, aber jede Ausführungsform muss nicht notwendigerweise das spezielle Merkmal, die Struktur oder Charakteristik umfassen. Darüber hinaus beziehen sich solche Phrasen nicht notwendigerweise auf die gleiche Ausführungsform. Ferner, wenn ein bestimmtes Merkmal, eine Struktur oder Charakteristik in Verbindung mit einer Ausführungsform beschrieben wird, wird davon ausgegangen, dass es im Wissen eines Fachmanns liegt, ein solches Merkmal, eine Struktur oder Charakteristik in Verbindung mit anderen Ausführungsformen umzusetzen, seien sie ausdrücklich beschrieben oder nicht.
Ein (z. B. Hardware-)Prozessor (z. B. mit einem oder mehreren Kernen) kann Befehle (z. B. einen Strang von Befehlen) zum Operieren auf Daten ausführen, beispielsweise, um arithmetische, logische oder andere Funktionen durchzuführen. Beispielsweise kann Software eine Operation anfordern, und ein Hardwareprozessor (z. B. ein Kern oder Kerne davon) kann die Operation in Reaktion auf die Anforderung durchführen. In einer Ausführungsform ist ein Prozessor mit einem Beschleuniger (z. B. auf dem Die) (z. B. einer Auslagerungs-Engine) gekoppelt, um, beispielsweise, eine oder mehrere (z. B. ausgelagerte) Operationen durchzuführen, anstatt dass diese Operationen nur auf dem Prozessor durchgeführt werden. In einer Ausführungsform umfasst ein Prozessor einen Beschleuniger (z. B. auf dem Die) (z. B. einer Auslagerungs-Engine), um, beispielsweise, eine oder mehrere Operationen durchzuführen, anstatt dass diese Operationen nur auf dem Prozessor durchgeführt werden.
Zwei nicht einschränkende Beispiele von Operationen sind eine Komprimierungsoperation und eine Dekomprimierungsoperation. Eine Komprimierungsoperation kann sich auf Codieren von Informationen unter Verwendung von weniger Bits als in der ursprünglichen Darstellung beziehen. Eine Dekomprimierungsoperation kann sich auf Decodieren von komprimierten Informationen zurück in die ursprüngliche Darstellung beziehen. Eine Komprimierungsoperation kann Daten aus einem ersten Format in ein komprimiertes, zweites Format komprimieren. Eine Dekomprimierungsoperation kann Daten aus einem komprimierten, ersten Format in ein nicht komprimiertes, zweites Format dekomprimieren. Eine Komprimierungsoperation kann in Übereinstimmung mit einem (z. B. Komprimierungs-)Algorithmus durchgeführt werden. Eine Dekomprimierungsoperation kann in Übereinstimmung mit einem (z. B. Dekomprimierungs-)Algorithmus durchgeführt werden.
In einer Ausführungsform kann ein Beschleuniger eine Komprimierungsoperation (z. B. Strang) und/oder Dekomprimierungsoperation (z. B. Strang), beispielsweise, in Reaktion auf eine Anforderung zum und/oder für einen Prozessor (z. B. eine Zentraleinheit (CPU)) zum Durchführen dieser Operation durchführen. Ein Beschleuniger kann (z. B. auf einem Die mit einem Beschleuniger oder außerhalb des Dies) mit einem oder mehreren Puffern koppeln, um Daten zu speichern, z. B. die Eingabedaten und/oder die Ausgabedaten. In einer Ausführungsform koppelt ein Beschleuniger mit einem Eingabepuffer, um Eingabe davon zu laden, und einem Ausgabepuffer, um Ausgaben darauf zu speichern. Ein Prozessor kann einen Befehl zum Auslagern einer Operation oder von Operationen (z. B. einen Befehl, einen Strang von Befehlen oder andere Arbeiten) an einen Beschleuniger ausführen.
Eine Operation kann auf einem Strom von Eingabedaten durchgeführt werden. Ein Strom von Daten kann in Blöcken mit kleinerer (z. B. unterschiedlicher) Größe als der gesamte Block bereitgestellt werden, z. B. mit den bereitgestellten kleineren Blöcken, bis die Operation am gesamten Block durchgeführt wird. Bei einem zustandsbehafteten Strom von Daten kann jede Teilmenge von Daten (z. B. in seinem jeweiligen Puffer) davon in ihrer ursprünglichen Reihenfolge (z. B. an einen Beschleuniger) übermittelt (z. B. Operationen darauf ausgeführt) werden, beispielsweise, um in einer zustandsbehafteten Weise komprimiert oder dekomprimiert zu werden. Beispielsweise können alle genutzten Puffer kumulativ einen gesamten Block (z. B. Datei) von (z. B. kontinuierlichen) Daten speichern, um, beispielsweise, komprimiert oder dekomprimiert zu werden. Bei einem zustandslosen Strom von Daten kann (z. B. in seinem jeweiligen Puffer) jede Teilmenge von Daten davon in einer beliebigen (z. B. nicht ursprünglichen) Reihenfolge (z. B. an einen Beschleuniger) übermittelt (z. B. Operationen darauf ausgeführt) werden, wobei, beispielsweise, jede Teilmenge von Daten unabhängig von den anderen Teilmengen von Daten (z. B. Blöcken) ist. In einer Ausführungsform wird jede Teilmenge (z. B. Block) eines zustandslosen Stroms von Daten unabhängig von allen anderen Teilmengen (z. B. Block) der Daten komprimiert, beispielsweise so, dass kein Zustand zwischen den Teilmengen (z. B. Blöcken) erhalten wird und der Datenstrom daher als zustandslos bezeichnet werden kann. Beispielsweise kann ein Datenstrom zustandslos sein, wenn jede Teilmenge von Daten (z. B. ein Schiebefenster (mit z. B. 32 Kilobyte (KB)) komplett innerhalb der Teilmenge (z. B. Block) gehalten werden kann, auf der momentan eine Operation durchgeführt wird (z. B. komprimiert), und hat möglicherweise keinen Bezug auf andere Teilmengen (z. B. Blöcke). Beispielsweise kann jede Teilmenge von Daten (z. B. Block) eines zustandslosen Stroms von Daten als eigene unabhängige Aufgabe komprimiert oder dekomprimiert werden.
Zustandsbehaftete Komprimierung und zustandsbehaftete Dekomprimierung können aufgrund von Schiebefensterbezügen (z. B. rückwärts) (z. B. Zeichenfolgenbezügen), beispielsweise, in der ursprünglichen Reihenfolge der Daten, als zustandsbehaftet bezeichnet werden. Bei einer zustandsbehafteten Operation kann ein Schiebefenster Bezug auf Daten in beliebigen vorherigen Daten innerhalb eines bestimmten Bereichs (z. B. 32 KB oder 64 KB) der Daten nehmen, die momentan komprimiert oder dekomprimiert werden. Beispielsweise kann im DEFLATE-Algorithmus die Fenstergröße 32 KB sein. Die Fenstergröße kann wunschgemäß ausgewählt werden, kann z. B. für andere Algorithmen variieren. In einer Ausführungsform wird eine an einen Beschleuniger (z. B. Auslagerungsvorrichtung) übermittelte zustandsbehaftete Operation in Reihenfolge ausgeführt und hat Zugriff auf ein vorheriges Fenster (z. B. 32 KB) von Daten (z. B. zum Komprimieren oder Dekomprimieren) an einem gegebenen Punkt, beispielsweise, selbst wenn dieses (z. B. 32 KB große) Fenster in einem vorher übermittelten (z. B. separaten) Puffer liegt. In einer Ausführungsform, wenn ein Beschleuniger aufhören soll (z. B. vor Abschluss), eine Datenmenge (z. B. einen Kontext) zu verarbeiten, kann er das (z. B. 32 KB große) Fenster speichern, beispielsweise, sodass die Daten des vorherigen Fensters erneut in den Beschleuniger geladen werden können, wenn er beginnt, diese Datenmenge (z. B. Kontext) wieder zu verarbeiten.
In einer Ausführungsform soll ein (z. B. Komprimierungs-)Algorithmus auf einer Datenmenge (z. B. größer als 128 KB) arbeiten, der in mehrere kleinere Teilmengen von Daten aufgebrochen werden soll (z. B. 32 KB oder 64 KB (z. B. mallocs)). Eine Verarbeitungsvorrichtung (z. B. ein Prozessor) kann eine Komprimierungs- oder Dekomprimierungsfunktion mehrmals aufrufen, z. B. einmal für jede Teilmenge von Daten. Die Verarbeitungsvorrichtung (z. B. darauf ausgeführte Software) kann auch einen Eingabepuffer und/oder Ausgabepuffer zuordnen (z. B. bereitstellen), um die Daten (z. B. Quelle und/oder Ausgabe komprimiert oder dekomprimiert) für jeden Aufruf zu halten. In bestimmten Ausführungsformen sind Komprimierung und/oder Dekomprimierung datenabhängig, und daher ist die Ausgabegröße der komprimierten oder dekomprimierten Daten nicht bekannt (z. B. a priori oder während der Zuordnung von Puffern). In einer Ausführungsform von Komprimierung kann, für beliebigen nicht komprimierbaren Inhalt, die Größe der Ausgabedaten größer als die Eingabedaten sein. Eine Lösung kann sein, den Ausgabepuffer als ein Mehrfaches (z. B. zwei bis 20 Mal) der Größe des Eingabepuffers zu dimensionieren. Allerdings kann dies in einigen Ausführungsformen ein verschwenderischer Speicherverbrauch sein, beispielsweise, wo die Komprimierungsoperation die Größe der Ausgabedaten (z. B. Datei) auf weniger als die (z. B. 40% der) Größe der Eingabedaten (z. B. Datei) komprimiert. Eine weitere Lösung kann sein, einen (z. B. Eingabe- und/oder Ausgabepuffer) bei etwa der erwarteten Größe der Resultierenden der (z. B. Komprimierungs- oder Dekomprimierungs-)Operation zu dimensionieren, dann aber jede Situation zu behandeln, in der die Daten nicht korrekt in einen Ausgabepuffer passen und/oder alle Daten nicht vom Eingabepuffer verbraucht (z. B. Operation darauf ausgeführt) werden.
In einer Ausführungsform kann eine Verarbeitungsvorrichtung (z. B. die darauf ausgeführte Software) eine Komprimierungs- und/oder Dekomprimierungsfunktion aufrufen, um mit einem Eingabepuffer und einem Ausgabepuffer (und z. B. einem Zeiger auf einen Zustandsbereich) zu arbeiten und dann die Ergebnisse zu prüfen, um zu sehen, ob die Ausgabe gefüllt wurde und/oder die Eingabe vollständig verbraucht wurde. In einer Ausführungsform kann, darauf basierend, ein neuer Eingabe- und/oder Ausgabepuffer zugeordnet werden, und ein nachfolgender Funktionsaufruf kann, beispielsweise, mit dem aktualisierten Zustand vom vorherigen Aufruf durchgeführt werden. Allerdings kann dieses Verfahren des Blockierens von Aufrufen nicht wünschenswert sein (z. B. zu einer weniger als optimalen Leistung führen), wenn die Komprimierung und/oder Dekomprimierung über einen (z. B. Komprimierungs- und/oder Dekomprimierungs-)Hardwarebeschleuniger (z. B. Beschleunigungsengine) erfolgt.
In einer Ausführungsform kann es eine Latenz bei Übermittlung einer Anforderung an eine Beschleunigungsengine und bei der Rückantwort geben. Beispielsweise kann, während dieser Latenzzeit, ein (z. B. Software-)Strang geblockt und/oder im Leerlauf sein (beispielsweise, die Leistung und/oder Verarbeitungsressourcenausnutzung negativ beeinflussend) aufgrund der seriellen Natur der Verarbeitung, und/oder der Kontext dieses Strangs kann ausgetauscht worden sein (beispielsweise Hinzufügen von Mehraufwand zum Bewegen des (z. B. Kontexts der Verarbeitungsressource (z. B. CPU) mit jedem Komprimierungs- und Dekomprimierungsaufruf)). Bestimmte Ausführungsformen eines seriellen Übermittlungsmodells können auch problematisch am Beschleuniger sein, beispielsweise, wenn der Komprimierungs- (oder Dekomprimierungs-)Algorithmus Zustand umfasst (beispielsweise einen Betrag größer als 100 KB, z. B. in Abhängigkeit vom Typ des Algorithmus) zum Hinein- und/oder Herausbewegen (z. B. des Beschleunigers) mit jedem Aufruf (z. B. wo der Aufruf 32 KB oder 64 KB neue Daten bereitstellt). Dies kann einen (z. B. nicht wünschenswerten) Leistungsmehraufwand hinzufügen und/oder eine kritische Bandbreitensituation am Beschleunigerkontaktpunkt verursachen (z. B. so, dass ein Beschleuniger zustandsbehaftete Komprimierung und/oder Dekomprimierung für einen Algorithmus bei einer Rate größer als 100 GBit/Sekunde nicht umsetzen kann). Eine weitere Alternative kann sein, den (z. B. Hardware-)Beschleuniger gesperrt zu halten und den Zustand nicht herein- oder herauszubewegen, dies kann aber zu einer weniger effizienten (z. B. nicht wünschenswerten) Nutzung des (z. B. Hardware-)Beschleunigers führen, beispielsweise, da der nächste Aufruf (der nach Abschluss des vorherigen Aufrufs vorzunehmen ist) Aktivieren des (z. B. Software-)Strangs, Zuordnen eines neuen Eingabe- und/oder Ausgabepuffers und Einsenden einer neuen Anforderung, die dann in den Leerlauf versetzt werden kann, während sie sich zum Kopf einer zu bearbeitenden Warteschlange nach oben bewegt, z. B. zu Zeit(en), während denen der Beschleuniger im Leerlauf ist, umfassen kann.
In einer Ausführungsform kann ein serialisiertes und sperrendes Schema einen oder mehrere Aufrufe (z. B. von Software) an einen Beschleuniger übermitteln, um einen Komprimierungsstrang und/oder Dekomprimierungsstrang (z. B. Operation oder Funktion) auszuführen. Ein Beschleuniger kann auf Daten operieren, bis entweder ein Eingabepuffer geleert oder ein Ausgabepuffer gefüllt ist (z. B. mit den Eingabe- und Ausgabedatenpuffern, die zur Wiederverwendung zurückgegeben werden (z. B. durch einen Prozessor), wenn die einzelnen Anforderungen abgeschlossen sind). Wenn sich allerdings, in einer Ausführungsform, ein Ausgabepuffer füllt und Eingabe bleibt und die übrig gebliebene Eingabe für eine Operation erneut übermittelt werden muss, kann z. B. eine unmittelbar darauf folgende Übermittlung von neuen Daten nicht durchgeführt werden.
Bestimmte Ausführungsformen hier stellen neuartige Techniken zum Verbessern der Interaktion zwischen einer Verarbeitungsvorrichtung (z. B. darauf ausgeführte Software) und einem Hardwarebeschleuniger, beispielsweise, für verbesserte Leistung bereit. In einer Ausführungsform wird ein Aufruf einer Operation (z. B. zum Durchführen von Komprimierung und/oder Dekomprimierung) durch einen mit einer Verarbeitungsvorrichtung gekoppelten Beschleuniger nicht als reine Anforderung an den Beschleuniger zum Durchführen der Operation erachtet. Stattdessen kann in dieser Ausführungsform eine anfängliche Anforderung den Kontext für die Operation aufstellen (z. B. die Komprimierungs- und/oder Dekomprimierungsaufgabe). Die Eingabepuffer können an eine kontextbasierte Warteschlange von Puffern übermittelt werden. Die Ausgabepuffer können an eine kontextbasierte Warteschlange von Puffern übermittelt werden. In einer Ausführungsform gibt es keine (z. B. strikte) Korrelation zwischen den Eingabe- und Ausgabepuffern. So kann, beispielsweise ein Beschleuniger weniger als alle (z. B. die Hälfte der) Daten in einem ersten Eingabepuffer verbrauchen und feststellen, dass ein erster Ausgabepuffer voll mit Ausgabedaten ist. Der Beschleuniger in diesem Beispiel kann dann beginnen, einen zweiten Ausgabepuffer in der Warteschlange von Puffern zu verwenden (beispielsweise während er dem (z. B. Software-)Strang signalisiert, dass ein Ausgabepuffer jetzt verfügbar ist) und kann Verbrauchen (z. B. Verarbeiten) der Daten im ersten Eingabepuffer beenden. In einer Ausführungsform fährt der Beschleuniger fort, (z. B. nahtlos) auf den Eingabedaten von einem zweiten Eingabepuffer zu arbeiten (während er beispielsweise dem (z. B. Software-)Strang signalisiert, dass ein anderer Eingabepuffer verbraucht wurde), was Daten erzeugen (z. B. produzieren) kann, die zum Speichern in dem zweiten Ausgabepuffer gesendet werden (z. B. und einen dritten Ausgabepuffer und so weiter, falls erforderlich). In bestimmten Ausführungsformen hier sind die Rückantworten vom Beschleuniger daher nicht an die Vorstellung eines Komprimierungs- oder Dekomprimierungsaufrufs gebunden, sondern stattdessen an die Operation(en), die auf einem beliebigen (z. B. Eingabe- oder Ausgabe-)Puffer durchgeführt wird bzw. werden (z. B. die Daten in einem Eingabepuffer, die vollständig verbraucht werden, oder ein neuer Ausgabepuffer, der zur Verwendung verfügbar ist). Bestimmte Ausführungsformen hier erlauben (z. B. der Software) das Bereitstellen von mehreren (z. B. 2, 3, 4, 5, 6, 7, 8, 9, 10 usw.) Eingabe- und Ausgabepuffern, und anschließendes Warten auf die Fertig-Antworten, um zu sehen, ob und/oder wie viele weitere (z. B. Eingabe- oder Ausgabe-)Puffer bereitzustellen sind. In einer Ausführungsform kann dies unabhängig und parallel zum Ausführen des Beschleunigers erfolgen. In einer Ausführungsform kann es, solange das System (z. B. Software) (z. B. einen Eingabe- oder Ausgabe-)Puffer bei oder etwa bei der durchschnittlichen Verbrauchsrate von (z. B. Eingabe- oder Ausgabe-)Puffern bereitstellen kann, keine (z. B. strikte) Serialisierung und/oder Latenz zwischen dem System (z. B. Software) und dem Beschleuniger geben. Diese Ausführungsform kann zu besserer Latenz und Durchsatz führen, kann aber auch Speichern und/oder Wiederherstellen von Zustand am Beschleuniger verhindern.
In bestimmten Ausführungsformen kann eine Verarbeitungsvorrichtung (z. B. Prozessor oder Kern davon) eine Komprimierungsoperation (z. B. Strang) und/oder eine Dekomprimierungsoperation (z. B. Strang) an einen Hardwarebeschleuniger (z. B. eine Beschleunigerschaltung) auslagern. In einer Ausführungsform ist ein Hardwarebeschleuniger mit einem Eingabe- und Ausgabepuffer gekoppelt, z. B. um einen zustandsbehafteten Strom von Eingabedaten zu empfangen, auf dem Operationen durchgeführt werden, um Ausgabedaten zu produzieren. Ein Hardwarebeschleuniger kann mit einem oder mehreren von Folgendem gekoppelt sein: mehrere Eingabespeicher (z. B. Puffer) zum Speichern der Eingabedaten, mehrere Ausgabespeicher (z. B. Puffer) zum Speichern der Ausgabedaten, ein Eingabepufferdeskriptorspeicher (z. B. Feld) mit einem Eintrag für jeden entsprechenden Eingabepuffer, ein Eingabepufferantwortdeskriptorspeicher (z. B. Feld) mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, ein Ausgabepufferdeskriptorspeicher (z. B. Feld) mit einem Eintrag für jeden entsprechenden Ausgabepuffer und ein Ausgabepufferantwortdeskriptorspeicher (z. B. Feld) mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer. Ein Eingabe- und/oder Ausgabepufferdeskriptoreintrag kann einen Zeiger auf einen Puffer, eine Größe der Daten im Puffer, ein Pufferkennzeichen oder eine beliebige Kombination daraus umfassen. Ein Eingabe- und/oder Ausgabeantwortpufferdeskriptoreintrag kann eine Größe der Daten im Puffer (z. B. die Größe der in einem Eingabepuffer verbleibenden Daten und/oder die Größe des nicht verwendeten Teils eines Ausgabepuffers), ein Pufferkennzeichen oder beides (z. B., aber ohne einen Zeiger) umfassen. Der Begriff Größe der Daten kann sich auf die Gesamtgröße der Daten beziehen, beispielsweise, und nicht auf die Größe der einzelnen Elemente aus mehreren Elementen von Daten.
Obwohl diese Offenbarung Ausführungsformen im Kontext von Komprimierungs- und Dekomprimierungsalgorithmen umfasst, kann diese Offenbarung auf andere Domänen ausgeweitet werden. Bestimmte Ausführungsformen können aufeinander folgende Aufrufe an einen Beschleuniger (z. B. Durchführen eines Strangs darauf) für einen zustandsbehafteten Strom von Daten ermöglichen, beispielsweise, ohne eine Größe von Datenpuffern wie im schlimmsten Fall für die Eingabe- und/oder Ausgabeströme zuzuordnen und/oder mit Ermöglichen, dass der Beschleuniger effizient (z. B. hochgradig) genutzt werden kann.
Bestimmte Ausführungsformen hier ermöglichen, dass Eingabe- und Ausgabepufferübermittlung und/oder -antworten asynchron sein können. Bestimmte Ausführungsformen hier können ein oder mehrere aus Folgenden umfassen: Puffer werden an einen Beschleuniger übergeben, ein Beschleuniger kann in exklusivem Besitz dieser Puffer sein, bis sie ausdrücklich zurückgegeben werden, Pufferrückgabe muss nicht an Abschluss einer Anforderung gebunden sein (z. B. Abschluss eines zur Ausführung an den Beschleuniger gesendeten Strangs), ein Beschleuniger kann Operation auf einem (z. B. aktuellen) Kontext einstellen, wenn entweder kein Eingabe- oder Ausgabepufferplatz mehr vorhanden ist (z. B. stellt aber nicht Operation auf (z. B. Rückgabe-)Puffern ein, die eine gültige Eingabe übrig haben), so Fortsetzen von Operation auf einem aktuellen Kontext erlaubend, wenn ein oder mehrere neue Puffer rechtzeitig ankommen, und Eingabe- und Ausgabepuffer voneinander und vom Anforderungsübermittlungsmodell entkoppelnd. Bestimmte Ausführungsformen hier können Beschleunigerleistung verbessern, Latenz verringern und sich positiv auf die Systemleistung auswirken. Bestimmte Ausführungsformen hier können Bandbreite (und z. B. den zugehörigen Leistungsmehraufwand) verringern, einsparen und/oder wiederherstellen, beispielsweise bei der Komprimierung und/oder Dekomprimierung eines zustandsbehafteten Stroms von Eingabedaten. Bestimmte Ausführungsformen hier können einen Beschleuniger zum Umsetzen von zustandsbehafteter Komprimierung und/oder Dekomprimierung für einen Algorithmus bei einer Rate größer als 100 GBit/Sekunde (z. B. bei einer Rate von etwa 200-400 GBit/Sekunde) umfassen.
1 stellt einen Hardwareprozessor 100 einschließlich mehrerer Kerne (0 bis N, wobei N 1 oder mehr sein kann) und Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger (0 bis M, wobei M 1 oder mehr sein kann) gemäß Ausführungsformen der Offenbarung dar. Hardwareprozessor 100 (z. B. Beschleuniger und/oder Kern(e) davon) können mit einer Datenspeichervorrichtung 104 (z. B. Speicher) gekoppelt sein. In einer Ausführungsform kann der Speicher ein dynamischer Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory), ein privater (z. B. privat für einen Beschleuniger) Direktzugriffsspeicher (RAM), ein Cache-Speicher oder ein Systemspeicher sein. Obwohl mehrere Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger (0 bis M) abgebildet sind, kann ein einzelner Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger genutzt werden, z. B. Beschleuniger 0 (102). Obwohl mehrere Kerne abgebildet sind, kann ein einzelner Kern genutzt werden, z. B. Kern 0 (106). Ein Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger kann eine Hardwarekomprimierungs- und - dekomprimierungsschaltung (z. B. Logik) sein.
Ein Prozessor 100 (z. B. Kern 106) kann eine Anforderung (z. B. von Software) empfangen, eine Komprimierungs- und/oder Dekomprimierungsoperation durchzuführen und kann die Komprimierungsoperation (z. B. Strang) und/oder eine Dekomprimierungsoperation (z. B. Strang) (z. B. zumindest einen Teil davon) an einen Hardwarebeschleuniger (z. B. Beschleuniger 102) auslagern. Kerne, Beschleuniger und Datenspeichervorrichtung 104 können miteinander kommunizieren (z. B. gekoppelt sein). Pfeile zeigen Zwei-Wege-Kommunikation (z. B. zu und von einer Komponente) an, es kann aber Ein-Weg-Kommunikation verwendet werden. In einer Ausführungsform kann ein (z. B. jeder) Kern mit der Datenspeichervorrichtung, beispielsweise, einem oder mehreren aus: Eingabepuffer 108, Ausgabepuffer 110, Pufferdeskriptoren 112 und Antwortdeskriptoren 112 kommunizieren (z. B. gekoppelt sein). In einer Ausführungsform kann ein Kern nicht in die Pufferantwortdeskriptoren 122 schreiben. In einer Ausführungsform kann ein (z. B. jeder) Beschleuniger mit der Datenspeichervorrichtung, beispielsweise, einem oder mehreren aus: Eingabepuffer 108, Ausgabepuffer 110, Pufferdeskriptoren 112 und Antwortdeskriptoren 112 kommunizieren (z. B. gekoppelt sein). In einer Ausführungsform kann ein Beschleuniger nicht in die Pufferdeskriptoren 112 schreiben.
In einer Ausführungsform kann ein Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger in Prozessor 100 sein. Ein Hardwarebeschleuniger (z. B. jeder Hardwarebeschleuniger) kann mit einem (z. B. seinem eigenen) Eingabepuffer und/oder Ausgabepuffer gekoppelt sein, z. B. um einen zustandsbehafteten Strom von Eingabedaten zu empfangen, auf dem Operationen durchgeführt werden, um Ausgabedaten zu produzieren. Ein Hardwarebeschleuniger (z. B. jeder Hardwarebeschleuniger) kann gekoppelt sein mit einem oder mehreren aus: mehreren Eingabepuffern 108 zum Speichern der Eingabedaten, mehreren Ausgabepuffern 110 zum Speichern der Ausgabedaten, Speicher für Pufferdeskriptoren 112 und Pufferantwortdeskriptoren 122, beispielsweise, wie nachfolgend erörtert. Pufferdeskriptoren 112 können ein oder mehrere aus Folgenden umfassen: einen Eingabepufferdeskriptorspeicher (z. B. Feld 116 mit einem Eintrag für jeden entsprechenden Eingabepuffer) und/oder Zeiger 114 auf den letzten gültigen Eingabepuffer, und einen Ausgabepufferdeskriptorspeicher (z. B. Feld 120 mit einem Eintrag für jeden entsprechenden Ausgabepuffer) und/oder einen Zeiger 118 auf den letzten gültigen Ausgabepuffer.
Pufferantwortdeskriptoren 122 können ein oder mehrere aus Folgenden umfassen: einen Eingabepufferantwortdeskriptorspeicher (z. B. Feld 126 mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer) und/oder einen Zeiger 124 auf den letzten verbrauchten Eingabepuffer, und einen Ausgabepufferantwortdeskriptorspeicher (z. B. Feld 130 mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer) und/oder einen Zeiger 128 auf den letzten verbrauchten Ausgabepuffer. Ein Eingabe- und/oder Ausgabepufferdeskriptoreintrag kann einen Zeiger auf einen (z. B. Eingabe- oder Ausgabe-)Puffer, eine Größe der Daten in diesem Puffer, ein Pufferkennzeichen oder eine beliebige Kombination daraus umfassen. Ein Eingabe- und/oder Ausgabeantwortpufferdeskriptoreintrag kann eine Größe der Daten im Puffer (z. B. die Größe der in einem Eingabepuffer verbleibenden Daten und/oder die Größe des nicht verwendeten Teils eines Ausgabepuffers), ein Pufferkennzeichen oder beides (z. B., aber ohne einen Zeiger) umfassen. Der Begriff Größe der Daten kann sich auf die Gesamtgröße der Daten beziehen, beispielsweise, und nicht auf die Größe der einzelnen Elemente aus mehreren Elementen von Daten. In einer Ausführungsform ist die Anzahl der Einträge im Speicher (z. B. Feld 116 und Feld 126) für die Eingabepufferdeskriptoren and Eingabepufferantwortdeskriptoren die gleiche wie die Anzahl von (z. B. für einen Kontext) verwendeten, beispielsweise, zugeordneten, z. B. N_EIN, Eingabepuffern. Zusätzlich oder alternativ dazu ist die Anzahl der Einträge im Speicher (z. B. Feld 120 und Feld 130) für die Ausgabepufferdeskriptoren and Ausgabepufferantwortdeskriptoren die gleiche wie die Anzahl von (z. B. für einen Kontext) verwendeten, beispielsweise, zugeordneten, z. B. N_AUS, Ausgabepuffern. In einer Ausführungsform kann ein Puffer ein Ringpuffer sein. Obwohl die Zeiger als angrenzend an die Felder gezeigt sind, können andere Ausführungsformen die Zeiger an einem beliebigen Ort, z. B. lokal zu einem Beschleuniger speichern.
Eine beispielhafte Operation wird jetzt unter Bezugnahme auf 2 erörtert. 2 stellt eine Hardwareverarbeitungsvorrichtung (z. B. Kern) 206 und einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger 202 dar. In einer weiteren Ausführungsform können mehrere Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger verwendet werden. Die abgebildete Hardwareverarbeitungsvorrichtung 206 und der Beschleuniger 202 können mit der Datenspeichervorrichtung 204 (z. B. Speicher) kommunizieren (z. B. über eine Kopplung oder eine andere Verbindung).
Eine Verarbeitungsvorrichtung (z. B. Kern 206) kann eine Anforderung (z. B. von Software) empfangen, eine Komprimierungs- und/oder Dekomprimierungsoperation durchzuführen und kann die Komprimierungsoperation (z. B. Strang) und/oder eine Dekomprimierungsoperation (z. B. Strang) an einen Hardwarebeschleuniger 202 auslagern. Eine oder mehrere Anforderungen können in einer optionalen Beschleunigerbefehlswarteschlange 203 gespeichert sein, die lokal zum Beschleuniger 202 oder separat davon sein kann. Hardwarebeschleuniger 202 kann mit einem oder mehreren von Folgendem gekoppelt sein: mehrere Eingabepuffer 208 zum Speichern der Eingabedaten, mehrere Ausgabepuffer 210 zum Speichern der Ausgabedaten (z. B. zum Empfangen eines zustandsbehafteten Stroms von Eingabedaten, auf denen Operationen durchgeführt werden, um Ausgabedaten zu produzieren), Speicher für Pufferdeskriptoren 212 und Speicher für Pufferantwortdeskriptoren 222. Pufferdeskriptoren 212 können ein oder mehrere aus Folgenden umfassen: einen Eingabepufferdeskriptorspeicher (z. B. Feld 216 mit einem Eintrag für jeden entsprechenden Eingabepuffer) und/oder Zeiger 214 auf den letzten gültigen Eingabepuffer, und einen Ausgabepufferdeskriptorspeicher (z. B. Feld 220 mit einem Eintrag für jeden entsprechenden Ausgabepuffer) und/oder einen Zeiger 218 auf den letzten gültigen Ausgabepuffer. Pufferantwortdeskriptoren 222 können ein oder mehrere aus Folgenden umfassen: einen Eingabepufferantwortdeskriptorspeicher (z. B. Feld 226 mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer) und/oder einen Zeiger 224 auf den letzten (z. B. durch den Beschleuniger) verbrauchten Eingabepuffer, und einen Ausgabepufferantwortdeskriptorspeicher (z. B. Feld 230 mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer) und/oder einen Zeiger 228 auf den letzten (z. B. durch den Beschleuniger) verbrauchten Ausgabepuffer. Ein Eingabe- und/oder Ausgabepufferdeskriptoreintrag kann einen Zeiger auf einen (z. B. Eingabe- oder Ausgabe-)Puffer (z. B. Puffer 0 bis N-1), eine Größe der Daten in diesem Puffer, ein Pufferkennzeichen oder eine beliebige Kombination daraus umfassen. Ein Eingabe- und/oder Ausgabeantwortpufferdeskriptoreintrag kann eine Größe der Daten im Puffer (z. B. die Größe der in einem Eingabepuffer verbleibenden Daten und/oder die Größe des nicht verwendeten Teils eines Ausgabepuffers), ein Pufferkennzeichen oder beides (z. B., aber ohne einen Zeiger) umfassen. Der Begriff Größe der Daten kann sich auf die Gesamtgröße der Daten beziehen, beispielsweise, und nicht auf die Größe der einzelnen Elemente aus mehreren Elementen von Daten. In einer Ausführungsform ist die Anzahl der Einträge im Speicher (z. B. Feld 216 und Feld 226) für die Eingabepufferdeskriptoren and Eingabepufferantwortdeskriptoren die gleiche wie die Anzahl von (z. B. für einen Kontext) verwendeten, beispielsweise, zugeordneten Eingabepuffern. Zusätzlich oder alternativ dazu ist die Anzahl der Einträge im Speicher (z. B. Feld 220 und Feld 230) für die Ausgabepufferdeskriptoren and Ausgabepufferantwortdeskriptoren die gleiche wie die Anzahl von (z. B. für einen Kontext) verwendeten, beispielsweise, zugeordneten Ausgabepuffern. In einer Ausführungsform kann ein Puffer ein Ringpuffer sein. Obwohl die Zeiger als angrenzend an die Felder gezeigt sind, können andere Ausführungsformen die Zeiger an einem beliebigen Ort, z. B. lokal zu einem Beschleuniger speichern. Das Genannte kann Teil einer Kontextstruktur 205 sein, z. B. mit einem einzelnen Kontext für jede Komprimierungs- und/oder Dekomprimierungsoperation auf einer ganzen Datenmenge. Eine Kontextstruktur kann statische Kontextdaten 207 umfassen, beispielsweise, eines oder mehrere von Folgendem umfassend: ein Feld für eine Aufgabenbeschreibung (z. B. Aufgabenkennung (ID) oder ein oder mehrere andere Arbeitsdeskriptoren), Optionen, Auslegungen, zustandsbehaftete Zeiger für Sicherungsbereich und globale Steuerungskennzeichen.
Als ein Beispiel kann Verarbeitungsvorrichtung 206 eine Anforderung für eine Operation (z. B. eine Komprimierungs- oder Dekomprimierungsoperation) auf einer Eingabedatenmenge empfangen. Bestimmte Beispiele hier erörtern eine Komprimierungsoperation. In einer Ausführungsform einer Dekomprimierungsoperation können die Beispiele für eine Komprimierungsoperation anwendbar sein, z. B. andere als Ausgabepuffer schneller verbraucht werden als Eingabepuffer bei Dekomprimierung, während Komprimierung Eingabepuffer schneller als Ausgabepuffer verbrauchen kann, z. B. kann die Hardwareoperation der Schnittstelle zwischen der Verarbeitungsvorrichtung und dem Beschleuniger in beiden Fällen die gleiche sein.
In einer Ausführungsform des Sendens einer Anforderung an einen Beschleuniger kann Verarbeitungsvorrichtung 206 eine gewisse Anzahl von Eingabepuffern 208 zuordnen und füllen 232, einen LetztGültEin-Zeiger 214 schreiben 236, und (z. B. Größen-Informationen in jedem entsprechenden Eintrag für jeden Puffer im Eingabepufferdeskriptorfeld 216 schreiben 234.
Ein Eingabepufferdeskriptoreintrag (z. B. PuffDesk 0) in Eingabepufferdeskriptorfeld 216 kann die entsprechenden Informationen für diesen Eingabepuffer (z. B. Eingabepuffer 0) in Eingabepuffern 208 umfassen. Beispielsweise kann ein Eingabepufferantwortdeskriptoreintrag (z. B. AntwPuffDesk 0) in Eingabepufferantwortdeskriptorfeld 226 die entsprechenden Informationen für diesen (z. B. gleichen) Eingabepuffer (z. B. Eingabepuffer 0) in Eingabepuffern 208 umfassen. In bestimmten Ausführungsformen wird die Variable N_EIN wird mit Bezug auf den Eingabepuffer verwendet, und N_AUS wird mit Bezug auf den Ausgabepuffer verwendet. In einer Ausführungsform können N_EIN und N_AUS unterschiedliche Werte haben, beispielsweise können die Anzahl von Eingabepuffern und die Anzahl von Ausgabepuffern, die verwendet (z. B. zugeordnet) werden, unterschiedlich sein. In einer Ausführungsform können N_EIN und N_AUS den gleichen Wert (z. B. N) haben, beispielsweise können die Anzahl von Eingabepuffern und die Anzahl von Ausgabepuffern, die verwendet (z. B. zugeordnet) werden, gleich sein.
Ein Ausgabepufferdeskriptoreintrag (z. B. PuffDesk 0) in Ausgabepufferdeskriptorfeld 220 kann die entsprechenden Informationen für einen Ausgabepuffer (z. B. Ausgabepuffer 0) in Ausgabepuffern 210 umfassen. Beispielsweise kann ein Ausgabepufferantwortdeskriptoreintrag (z. B. AntwPuffDesk 0) in Ausgabepufferantwortdeskriptorfeld 230 die entsprechenden Informationen für diesen (z. B. gleichen) Ausgabepuffer (z. B. Ausgabepuffer 0) in Ausgabepuffern 210 umfassen. In einer Ausführungsform dient die Verarbeitungsvorrichtung dazu zu prüfen, dass alle vorher gesendeten Puffer (z. B. für einen Kontext) vor dem Wiederverwenden verbraucht wurden. Verarbeitungsvorrichtung 206 kann LetztGültEin-Zeiger 214 schreiben 236, um den letzten Eingabepuffer der Eingabepuffer 208 anzuzeigen, für den die Verarbeitungsvorrichtung (z. B. gültige) Daten bereitgestellt hat.
Die Verarbeitungsvorrichtung kann einen oder mehrere Ausgabepuffer der Ausgabepuffer 210 zuordnen, um die Ausgabe des Beschleunigers zu empfangen. Beispielsweise kann die Verarbeitungsvorrichtung den LetztGültAus-Zeiger 218 und (z. B. Größen-)Informationen für jeden Eintrag (z. B. PuffDesk 0) von Ausgabepufferdeskriptorfeld 220 schreiben 238. LetztGültAus kann den letzten Ausgabepuffer anzeigen, den die Verarbeitungsvorrichtung bereitgestellt hat, in den der Beschleuniger Ausgabedaten schreiben kann. Die Verarbeitungsvorrichtung kann einen Ausführungsbefehl an den Beschleuniger schreiben (z. B. über eine Verbindung oder einen Anschluss, wie etwa, unter anderem, einen speicherabgebildeten Eingabe-/Ausgabe-Anschluss (MMIO, Memory-Mapped Input/Output)), um anzuzeigen, dass neue Daten verfügbar sind. Benachrichtigungen (z. B. asynchron mit den Operationen der Verarbeitungsvorrichtung) vom Beschleuniger können der Verarbeitungsvorrichtung (z. B. Anforderer) anzeigen, dass der Beschleuniger die Zeiger auf die letzte verbrauchte Eingabe (LetztVerbrEin) und/oder die letzte verbrauchte Ausgabe (LetztVerbrAus) aktualisiert hat. Verarbeitungsvorrichtung kann fortfahren (z. B. asynchron zu dieser Benachrichtigung), mehr (z. B. Eingabe- und/oder Ausgabe-)Puffer hinzuzufügen, wenn Platz vorhanden ist, oder zu warten, dass freie Puffer verfügbar werden, wenn alle in Verwendung sind. In einer Ausführungsform kann eine Verarbeitungsvorrichtung einen Befehl decodieren und/oder ausführen, um zu veranlassen, dass eine Anforderung (z. B. ein Befehlspaket) an einen Beschleuniger gesendet wird. In einer Ausführungsform wird die Zuordnung von Eingabepuffern und die Zuordnung von Ausgabepuffern durch Software, die auf einem Prozessor ausgeführt wird, verwaltet (z. B. initiiert), beispielsweise, basierend auf Arbeitslastbedingungen, z. B. Durchsatz, Anzahl von gleichzeitig ausgeführten Strängen, Latenztoleranz usw. In einer Ausführungsform ist die Anzahl von Eingabepuffern eine beliebige Zahl zwischen 1 und 16 oder 4 und 16. In einer Ausführungsform ist die Anzahl von Ausgabepuffern eine beliebige Zahl zwischen 1 und 16 oder 4 und 16.
Beschleuniger 202 kann ein Befehlspaket 232, z. B. von der Verarbeitungsvorrichtung 206 empfangen. Befehlspaket 232 kann gelesen werden (z. B. durch den Beschleuniger), und Werte können aktualisiert werden, z. B. in der Beschleunigerbefehlswarteschlange 203, und die Anforderung im Befehlspaket kann am Ende der Warteschlange platziert werden (z. B. im statischen Direktzugriffsspeicher (SRAM) eines Beschleunigers oder im Direktzugriffsspeicher des Systems (RAM)). In einer Ausführungsform kann ein erster Warteschlangeneintrag gelesen und verarbeitet werden. Der Beschleuniger 202 kann, z. B. für einen spezifischen Kontext, auf gültige Eingabe- und Ausgabepuffer prüfen, beispielsweise durch Prüfen von LetztVerbr mit LetztGült auf Eingabe und/oder Ausgabe. In einer Ausführungsform, wenn LetztGültEin nicht gleich LetztVerbrEin ist, gibt es einen oder mehrere Eingabepuffer, auf denen gearbeitet werden kann. In einer Ausführungsform, wenn LetztGültAus nicht gleich LetztVerbrAus ist, sind ein oder mehrere Ausgabepuffer verfügbar, in denen Ausgabedaten gespeichert werden können. In einer Ausführungsform, wenn nicht sowohl Eingangsdaten verfügbar sind als auch Platz für Ausgabedaten verfügbar ist, dann kann der Beschleuniger auf zusätzliche Aktualisierungen an Eingabe- und Ausgabepuffern prüfen und gegebenenfalls fortfahren. In einer Ausführungsform, wenn sowohl Eingabedaten als auch Platz für Ausgabedaten verfügbar sind, kann der Beschleuniger Eingabe verbrauchen und Ausgabe erzeugen, bis der Nachschub entweder an Eingabepuffern oder Ausgabepuffern erschöpft ist. Der Beschleuniger 202 kann (z. B. bei Verbrauch) Kennzeichen und/oder Datenausgabegrößen in Antwortdeskriptoren 222 aktualisieren und/oder die Variablen LetztVerbrEin 224 und LetztVerbrAus 228 aktualisieren. Der Beschleuniger kann auf zusätzliche Aktualisierungen an Eingabe- und Ausgabepuffern prüfen und gegebenenfalls fortfahren. Der Beschleuniger kann eine Benachrichtigung (z. B. Unterbrechung oder ein anderes Signal) an den Prozessor senden. In einer Ausführungsform umfasst eine Benachrichtigung eines oder mehrere von Folgendem: eine (z. B. allgemeine) Prozessorunterbrechung (z. B. CPU), Cache-Leitungszugriffssignal (z. B. Überwachen und Warten) und Speicherschreiben in einen Bereich, den der Prozessor regelmäßig prüft (z. B. Abfragen). Eine Benachrichtigung kann zwischen einem Beschleuniger und einem Prozessor über einen speziellen Kommunikationskanal (z. B. Leitung) und/oder eine Warteschlangenschnittstelle gesendet werden.
Als ein weiteres Beispiel kann, unter Annahme einer Datenmenge mit einer Gesamtgröße (z. B. eine 200-KB-Datei), jeder Eingabepuffer (z. B. Speicher) kleiner als die Gesamtgröße sein (z. B. jeder Eingabepuffer kann 64 KB Daten speichern). In einer zustandsbehafteten Ausführungsform sind der Verbrauch der Eingabepuffer 208 und Ausgabepuffer 210 unabhängig vom Pufferübermittlungsmechanismus. Die Eingabepuffer können vollständig von den Ausgabepuffern entkoppelt sein. Datenpuffer können dem Beschleuniger gehören, bis sie vollständig verbraucht sind oder bis der Beschleuniger (z. B. Logik davon) die Entscheidung trifft, sie zurückzugeben, z. B. zur Verwendung durch einen anderen Kontext. In einer Ausführungsform ist die Operation des Beschleunigers auf einem bestimmten Kontext nicht direkt an ein Anforderungs- und/oder Antwortmodell gebunden. Beispielsweise können mehrere Mengen von Daten in die Warteschlange auf einem einzelnen Kontext platziert sein (z. B. wenn genügend Puffer, Pufferdeskriptorspeicher und Pufferantwortdeskriptorspeicher gegeben ist), und der Beschleuniger kann frei auf den Daten dieses Kontexts arbeiten, unabhängig von der Übermittlungsreihenfolge von Daten in Bezug auf andere Kontexte. Beispielsweise kann der Beschleuniger Umschalten zwischen Kontexten verhindern aufgrund des Entkoppelns von Übermittlungs- und Ausführungsreihenfolge. Innerhalb eines Kontexts kann die Operation (z. B. Komprimierung oder Dekomprimierung) in Übermittlungsreihenfolge ausgeführt werden, aber mit anderen Kontexten ist möglicherweise keine Reihenfolge erforderlich.
Initialisierung:
In diesem Beispiel kann, in Reaktion auf eine Operation auf einer Datenmenge, eine Verarbeitungsvorrichtung 206 (z. B. Kern oder CPU) den gesamten für die Operation des Beschleunigers 202 verwendeten Speicher zuordnen 232 und initialisieren 234, z. B. einschließlich Platz für jede Kontextstruktur 205, die das entsprechende Eingabepufferdeskriptorfeld 216 für Eingabepuffer 208, Ausgabepufferdeskriptorfeld 220 für Ausgabepuffer 210, Eingabepufferantwortdeskriptorfeld 226 für Eingabepuffer 208 und Ausgabepufferantwortdeskriptorfeld 230 für Ausgabepuffer 210 umfassen kann. In einer Ausführungsform kann der Zeiger 214 auf den anfänglichen letzten gültigen Eingabepuffer (LetztGültEin) auf den Index von 3 (z. B. das vierte Element im Index) gesetzt 236 werden, beispielsweise, da die 200-KB-Datei alle drei 64-KB-Puffer und einen Teil des vierten 64-KB-Puffers aufbraucht (z. B. Element 4, das Index 3 ist, wenn 0 der erste Index ist), der Zeiger 218 auf den letzten gültigen Ausgabepuffer (LetztGültAus) kann ebenfalls auf den Index von 3 gesetzt 238 werden, der Zeiger 224 auf den letzten verbrauchten Eingabepuffer (LetztVerbrEin) kann ebenfalls auf den Index von 3 gesetzt 242 werden, und der Zeiger 228 auf den letzten verbrauchten Ausgabepuffer (LetztVerbrAus) kann ebenfalls auf den Index von 3 gesetzt 248 werden. Das Längenfeld in den Eingabepufferdeskriptoren für Puffer 0 und 1 kann jeweils auf 64 KB gesetzt werden. In einer Ausführungsform zeigt die anfängliche Einstellung der Zeiger des letzten gültigen Eingabepuffers (LetztGültEin) und des letzten verbrauchten Eingabepuffers (LetztVerbrEin) auf einen gleichen Indexwert (z. B. 3 im obigen Beispiel), und die anfängliche Einstellung der Zeiger des letzten gültigen Ausgabepuffers (LetztGültAus) und des letzten verbrauchten Ausgabepuffers (LetztVerbrAus) auf einen (z. B. sich von dem des Eingabepuffers unterscheidenden) gleichen Indexwert (z. B. 3 im obigen Beispiel) an, dass keine gültigen Eingabe- bzw. Ausgabedaten verfügbar sind.
In einer Ausführungsform kann, nach der Initialisierung, nur der Beschleuniger die LetztVerbr-Werte (z. B. LetztVerbrEin 224 und LetztVerbrAus 228) aktualisieren. Die Verarbeitungsvorrichtung 206 kann die LetztGült-Werte (z. B. LetztGültEin 214 und LetztGültAus 218) aktualisieren. Die Verarbeitungsvorrichtung 206 kann vier Pufferdeskriptoren für Eingabe und Ausgabe zuordnen (z. B. bei 234 und 236), z. B. sodass N=4 (z. B. bei 234 und 240). Die Zeiger auf Speicherbereiche mit Eingabe- und Ausgabedaten können für dieses Beispiel geschrieben werden und dann gleich bleiben, können aber bei allgemeiner Verwendung geändert werden, z. B. vor jeder Übermittlung an den Beschleuniger zum Durchführen der Operation. In diesem Beispiel können vier Speicherpuffer in Eingabepuffer 208 zugeordnet 232 werden (z. B. N=4) und können auch in Ausgabepuffer 210 zugeordnet 252 werden (z. B. ebenfalls N=4). Diese Puffer können dynamisch zugeordnet sein und sich während der Ausführung ändern, z. B. dass die Pufferdeskriptoren und/oder Pufferantwortdeskriptoren so modifiziert sind, dass sie auf diese(n) Puffer zeigen, bevor dem Beschleuniger signalisiert wird, dass ein Puffer bereit für Verwendung ist.
In diesem Beispiel kann dann LetztGültAus 218 auf 2 gesetzt werden, was z. B. anzeigt, dass Ausgabepuffer 0, 1 und 2 jetzt gültig sind, um Ausgabe zu empfangen. Die Verarbeitungsvorrichtung 206 kann die erste Teilmenge von Daten (z. B. einen 64-KB-Block) in den Eingabepuffer 0 und die zweite Teilmenge (z. B. 64-KB-Block) in Eingabepuffer 1 aus Eingabepuffern 208 laden (z. B. kopieren), wenn beispielsweise nur die ersten zwei Teilmengen der Eingabedaten momentan verfügbar sind. In einer Ausführungsform sind die zwei Teilmengen kontinuierliche (z. B. benachbarte) Daten aus den Eingabedaten.
Operation:
Die Verarbeitungsvorrichtung 206 (z. B. Prozessor oder CPU) kann eine Anforderung (z. B. Befehlspaket 232) an den Beschleuniger 202 senden, um eine Operation auf den Eingabedaten durchzuführen. Der Kontextstrukturzeiger davon kann dem Beschleuniger anzeigen, welcher operationale Kontext aktualisiert wurde. In einer Ausführungsform von Operation empfängt der Beschleuniger das Befehlspaket 232. Das Befehlspaket kann eins oder mehrere von Folgendem umfassen: einen oder mehrere Steuerungsparameter, LetztGültEin-Zeiger (z. B. zum Speichern in Feld 214), LetztGültAus-Zeiger (z. B. zum Speichern in Feld 218) und Kontextstrukturzeiger. Die Anforderung (z. B. Befehlspaket 232) kann zur späteren Verarbeitung in einer internen Warteschlange, z. B. in der Beschleunigerbefehlswarteschlange 203, platziert werden. Wenn die Anforderung die erste Anforderung ist, kann sie (z. B. unmittelbar) aus der Warteschlange entfernt werden, um mit dem Verarbeiten zu beginnen. In einer Ausführungsform kann Beschleuniger 202 prüfen, ob diese LetztVerbrEin und LetztGültEin nicht gleich sind, was anzeigt, dass Eingabedaten verfügbar sind. In einer Ausführungsform kann Beschleuniger 202 prüfen, ob LetztVerbrAus und LetztGültAus nicht gleich sind, was anzeigt, dass Ausgabepufferplatz verfügbar ist. Wenn Eingabedaten verfügbar sind (und z. B. Ausgabepufferplatz verfügbar ist), kann der Beschleuniger den ersten Puffer von Eingabepuffer 208 lesen, der neue Eingabedaten umfasst, und die Daten verarbeiten (z. B. komprimieren oder dekomprimieren) und die erzeugten Ausgabedaten an den ersten Puffer von Ausgabepuffer 210 ausgeben, der Platz zum Empfangen (z. B. eines Teils) der Daten umfasst. In diesem Beispiel können die zwei Eingabepuffer 0 und 1 vollständig erschöpft sein, und die Ausgabedaten davon können in den ersten Ausgabepuffer 0 passen.
In einer Ausführungsform können zu diesem Zeitpunkt keine weiteren Eingabedaten verfügbar sein. Es ist anzumerken, dass es in bestimmten Ausführungsformen möglich ist, dass die Verarbeitungsvorrichtung 206 LetztGültEin inkrementiert hat, wenn Eingabepuffer zum Laden mit Daten (z. B. durch die Verarbeitungsvorrichtung 206) verfügbar waren. Beispielsweise kann der Beschleuniger 202 (z. B. regelmäßig) prüfen, ob die Verarbeitungsvorrichtung 206 mehr Daten gesendet und LetztGültEin aktualisiert hat. In einer Ausführungsform, wenn zu diesem Zeitpunkt keine weiteren Eingabedaten verfügbar sind, kann der Beschleuniger 202 in diesem bestimmten Kontext möglicherweise nicht weiter fortschreiten und kann ein Signal oder eine Unterbrechung an die Verarbeitungsvorrichtung 206 senden, z. B. und Verarbeitungsvorrichtung 206 kann den Status prüfen. In bestimmten Ausführungsformen kann jetzt ein weiterer Kontext (z. B. in der Warteschlange) fortfahren zur Ausführung auf dem Beschleuniger 202, wenn dieser Kontext Daten zum Verarbeiten hat. Die Verarbeitungsvorrichtung 206 kann das Signal oder die Unterbrechung empfangen und den LetztVerbrEin-Zeiger der Antwortdeskriptoren prüfen. Wenn beispielsweise die Verarbeitungsvorrichtung in diesem Beispiel feststellt, dass LetztVerbrEin jetzt auf 1 gesetzt ist, was gleich LetztGültEin ist, kann dies anzeigen, dass beide vorher bereitgestellten Eingabepuffer verbraucht wurden, und dass es erneut 4 leere Eingabepuffer gibt. Wenn beispielsweise die Verarbeitungsvorrichtung in diesem Beispiel den LetztVerbrAus-Zeiger prüft und feststellt, dass dieser immer noch auf 3 gesetzt ist, kann dies anzeigen, dass kein Ausgabepuffer an die Verarbeitungsvorrichtung zurückgegeben wurde, z. B. dass es Daten im Ausgabepuffer 0 gibt, diese aber nicht an die Verarbeitungsvorrichtung zurückgegeben wurden. In einer Ausführungsform nimmt diese Operation an, dass der Puffer vollständig gefüllt wird, bevor er zurückgegeben wird, z. B. sofern nicht der Kontext angezeigt hat, dass alle Daten gesendet wurden, wobei in diesem Fall ein teilweiser Puffer zurückzugeben ist. In bestimmten Ausführungsformen ist das Maß, wie voll ein Puffer ist, bevor er zurückgegeben wird, ein einstellbarer Parameter, z. B. kann ein Puffer zurückgegeben werden, wenn er voll ist oder wenn er ein bestimmtes Niveau aufweist, das kleiner als voll ist.
In diesem Beispiel wird davon ausgegangen, dass die Verarbeitungsvorrichtung 206 jetzt Eingabepuffer 2 mit 64 KB von Daten und Eingabepuffer 3 mit den verbleibenden 4 KB von Daten füllt, was die 200-KB-Datei vervollständigt. Das Längenfeld in den Eingabepufferdeskriptoren für Puffer 2 und 3 kann auf 64 KB bzw. 4 KB gesetzt werden. Die Verarbeitungsvorrichtung kann die Eingabepufferdeskriptorzeiger und Kennzeichen für Eingabepuffer 2 und 3 schreiben. Ein Dateiendekennzeichen (EOF, End of File) kann im Kennzeichenfeld des Eingabedeskriptoreintrags für Puffer 3 gesetzt sein. In einer Ausführungsform werden, wenn immer noch Ausgabepuffer verfügbar sind, keine Ausgabepuffer hinzugefügt. Die Verarbeitungsvorrichtung kann den LetztGültEin-Zeiger auf 3 aktualisieren. Der LetztVerbrEin kann jetzt 1 sein (z. B. wie vorher erwähnt), was bedeutet, dass jetzt 2 Eingabepuffer verfügbar sind. Die Verarbeitungsvorrichtung kann ein Befehlspaket 232 an den Beschleuniger 202 senden, anzeigend, dass neue Eingabedaten verfügbar sind. Diese Eingabepuffer können dann verarbeitet werden, z. B. wie oben erörtert. Die Ausgabedaten von der (z. B. Komprimierungs-)Operation der zwei neuen Puffer kann an den Ausgabepuffer 0 angehängt werden, bis dieser voll ist. In einer Ausführungsform können beliebige weitere Daten in Ausgabepuffer 1 geladen (z. B. gespeichert) werden. Der LetztVerbrAus-Zeiger kann auf 0 aktualisiert werden, wenn Ausgabepuffer 0 voll ist.
Die (z. B. Komprimierungs-)Operation kann fortfahren, bis alle Eingabedaten erschöpft sind, und in diesem Beispiel kann Ausgabepuffer 1 teilweise gefüllt sein. Da das EOF-Kennzeichen im Eingabepufferdeskriptor für Puffer 3 gesetzt wurde, kann der Beschleuniger das EOF-Kennzeichen im Ausgabepufferdeskriptor für Ausgabepuffer 1 setzen. Die Verarbeitungsvorrichtung kann diese Informationen verwenden, um zu bestimmen, dass die Operation auf dieser Datenmenge (z. B. Kontext) abgeschlossen ist. Der Beschleuniger kann LetztVerbrAus auf 1 setzen, wenn er nicht länger Daten zu Ausgabepuffer 1 zu schreiben hat, z. B. selbst wenn Ausgabepuffer 1 nicht voll ist, da der Strom abgeschlossen ist. Der Beschleuniger kann einen Eintrag (z. B. AntwPuffDesk 0) in das Eingabepufferantwortdeskriptorfeld 226 für einen Eingabepuffer (z. B. Eingabepuffer 0) der Eingabepuffer 208 laden (z. B. aktualisieren) 246, z. B. um anzuzeigen, wie viele Eingabedaten im Eingabepuffer verbleiben und/oder beliebige Kennzeichen. Der Beschleuniger kann einen Eintrag (z. B. AntwPuffDesk 0) in das Ausgabepufferantwortdeskriptorfeld 230 für einen Ausgabepuffer (z. B. Ausgabepuffer 0) der Ausgabepuffer 210 laden (z. B. aktualisieren) 250, z. B. um anzuzeigen, wie viele Ausgabedatenplatz verbleibt oder wie viele Daten in diesem Ausgabepuffer gespeichert wurden und/oder beliebige Kennzeichen (z. B. falls EOF).
LetztVerbrEin kann auf 3 gesetzt werden, anzeigend, dass Puffer 2 und Puffer 3 vollständig verbraucht wurden. Der Beschleuniger kann ein Signal oder eine Unterbrechung an die Verarbeitungsvorrichtung senden. Die Verarbeitungsvorrichtung kann LetztVerbrEin lesen und bestimmen, ob es gleich LetztGültEin ist und daher, ob die gesamte Eingabe verbraucht wurde. Die Verarbeitungsvorrichtung kann LetztVerbrAus lesen und kann eine 1 lesen. Dies kann anzeigen, dass Ausgabepuffer 0 und 1 verbraucht wurden und gültige Ausgabedaten enthalten. Die Verarbeitungsvorrichtung kann beliebige Pufferdeskriptorkennzeichen und Datenlängenwerte für Ausgabepuffer 0 und 1 prüfen. Die Verarbeitungsvorrichtung kann detektieren, dass Ausgabepuffer 0 mit 64 KB Daten voll ist und dass Ausgabepuffer 1 siebzehn (17) KB Daten mit gesetztem EOF-Kennzeichen hat, was anzeigt, dass dies die Operation auf dieser Datenmenge (z. B. Kontext) abschließt. Die Verarbeitungsvorrichtung kann die Ausgabedaten von den Ausgabepuffern lesen und sie nutzen (z. B. bewegen), beispielsweise, entsprechend den Erfordernissen der Anwendung. Beispielsweise kann die Verarbeitungsvorrichtung 206 die LetztGültAus 218 und LetztVerbrAus 228 prüfen, um zu bestimmen, ob ein Ausgabepuffer (z. B. neue) Daten vom Beschleuniger 202 hat.
Kontextzerstörung:
Die Verarbeitungsvorrichtung kann bestimmen, dass diese (z. B. Komprimierungs- oder Dekomprimierungs-)Operation abgeschlossen ist. Im Allgemeinen können (z. B. Ring-)Pufferfelder mehrmals verwendet worden sein, und die Operation zwischen dem Beschleuniger und der Verarbeitungsvorrichtung kann asynchron sein, z. B. mit gleichzeitiger Operation des Beschleunigers und der Verarbeitungsvorrichtung. In einer Ausführungsform kann die Verarbeitungsvorrichtung entweder den Kontext gänzlich löschen, indem sie den gesamten Speicher freigibt und einen Befehl an die Vorrichtung sendet, um den internen Kontextstatus in der Vorrichtung zu zerstören, oder sie kann zusätzliche Puffer einrichten und eine neue Sequenz von Operationen auf dem gleichen Kontext starten.
Die obigen Beispiele erörtern eine Verarbeitungsvorrichtung, die LetztGültEin und LetztGültAus direkt im Speicher mit dem Befehlspaket aktualisiert, was dem Beschleuniger anzeigt, dass Aktualisierungen an den Eingabe- und Ausgabepuffern stattgefunden haben. In diesem Fall kann der Beschleuniger (z. B. regelmäßig) auf neuen Eingabe- und Ausgabepufferplatz prüfen, z. B., und mit dem Verarbeiten beginnen, wenn er in der Lage ist, sobald das Befehlspaket empfangen wird. In diesem Fall kann das Befehlspaket als ein Ausführungsbefehl (z. B. Start) erachtet werden. Eine alternative Ausführungsform ist, die LetztGültEin- und LetztGültAus-Werte im Befehlspaket selbst zu übertragen. In diesem Fall kann dann der Beschleuniger die Werte aus dem Befehlspaket lesen und den internen Zustand aktualisieren. In einer weiteren Ausführungsform können die Pufferdeskriptoren durch Befehlspakete aktualisiert werden. Die Entscheidung, was direkt geschrieben wird und was über Befehlspakete übertragen wird, kann auswählbar sein, z. B. bei Fertigung oder zu Laufzeit.
3 stellt einen Hardwareprozessor umfassend mehrere Kerne 0 bis N (z. B. Prozessorkern 0 (306)), eine Hardwarebeschleunigeranforderungsverwaltung 301 und Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger 0 bis M (z. B. Hardwarebeschleuniger 0 (102)) gemäß Ausführungsformen der Offenbarung dar. In einer Ausführungsform kann Hardwarebeschleunigeranforderungsverwaltung 301 bestimmen, welche Operation (z. B. Aufgabe) von mehreren (z. B. Komprimierungs- oder Dekomprimierungs-)Operationen (z. B. Aufgaben) an einen bestimmten Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger gesendet wird. Obwohl mehrere Kerne (z. B. Anforderer des Beschleunigers zum Durchführen einer Operation) abgebildet sind, kann, in einer Ausführungsform, ein einzelner Kern mit der Hardwarebeschleunigeranforderungsverwaltung 301 gekoppelt (z. B. verbunden) sein, beispielsweise, um Daten an einen bestimmten Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger zu senden. Es ist anzumerken, dass ähnlich nummerierte Komponenten eine ähnliche oder die gleiche Funktionalität umfassen können wie diese Komponenten in den anderen Figuren. Beispielsweise kann Beschleuniger 302 in 3 eine Operation in Reaktion auf eine Anforderung von Kern 306 durchführen, da Beschleuniger 102 in 1 eine Operation in Reaktion auf eine Anforderung von Kern 106 durchführen kann und/oder Beschleuniger 202 eine Operation in Reaktion auf eine Anforderung von Verarbeitungsvorrichtung 206 (z. B. Kern oder Prozessor) durchführen kann. Hardwarebeschleunigeranforderungsverwaltung 301 kann mit Datenspeichervorrichtung 304 und/oder Beschleunigern (z. B. 0 bis M) kommunizieren.
Eine Ausführungsform einer Hardwarebeschleunigeranforderungsverwaltung kann Bezug nehmend auf ihre Interaktion mit dem Prozessor erörtert werden, beispielsweise durch Ansehen der Anwendungsprogrammierschnittstelle (API, Application Programming Interface) zwischen den Softwaretreibern (z. B. eines eine Operation anfordernden Softwareprogramms) und der Beschleunigerhardware. Anfänglich kann eine (z. B. Komprimierungs- oder Dekomprimierungs-)Aufgabe für den Beschleuniger erstellt werden, beispielsweise, durch Auslagern von dem Prozessor. In einer Ausführungsform können die Software, der Prozessor und/oder der Beschleuniger auf diese Aufgabe über eine eindeutige Aufgabenkennung (z. B. Aufgaben-ID) Bezug nehmen. Die Aufgabe kann eine verknüpfte Kontextstruktur 305 haben, beispielsweise, die dann für die Lebensdauer der Aufgabe verwendet wird, z. B. kann eine Aufgabe die Komprimierung oder eine Dekomprimierung einer (z. B. großen) Datei über zahlreiche Aufrufe an den Beschleuniger sein. In einer Ausführungsform kann die Kontextstruktur 305 eines oder mehrere von Folgendem umfassen: statische Kontextdaten 307, zum Beispiel, Aufgabeninformationen (z. B. ein Arbeitsdeskriptor), ein (z. B. ringförmiges) Feld von Pufferdeskriptoren 312 entsprechend den Eingabe- und Ausgabepuffern und ein (z. B. ringförmiges) Feld von Pufferantwortdeskriptoren 322 entsprechend den Eingabe- und Ausgabepuffern. Das Eingabepufferdeskriptorfeld 316 (und/oder der LetztGültEin-Zeiger 314) und das Ausgabepufferdeskriptorfeld 320 (und/oder der LetztGültAus-Zeiger 318) können zusammen in einem Teil gruppiert sein (z. B. wie gezeigt, in Datenspeichervorrichtung 304 gespeichert), lokal zum Prozessorkern 306 gespeichert sein (z. B. um durch den Prozessor aktualisiert zu werden), oder sie können separat und voneinander entfernt gespeichert sein. Das Eingabepufferantwortdeskriptorfeld 326 (und/oder der LetztVerbrEin-Zeiger 324) und das Ausgabepufferantwortdeskriptorfeld 330 (und/oder der LetztVerbrAus-Zeiger 328) können zusammen in einem Teil gruppiert sein (z. B. wie gezeigt, in Datenspeichervorrichtung 304 gespeichert), lokal zum Beschleuniger 302 gespeichert sein (z. B. um durch den Beschleuniger aktualisiert zu werden), oder sie können separat und voneinander entfernt gespeichert sein. In einer Ausführungsform beschreiben Pufferdeskriptoren (z. B. PuffDesk) den Inhalt der zugehörigen Eingabe- und Ausgabepuffer, die eines oder mehrere der folgenden Felder umfassen können: Zeiger (z. B. Zeiger auf den bestimmten Puffer), Datengröße und Kennzeichen. Größe kann übergebene Bits oder Bytes und/oder zum Speichern von Daten verfügbaren Platz umfassen. Kennzeichen können pufferbasierte Kennzeichen sein. In einer Ausführungsform können Antwortpufferdeskriptoren (z. B. AntwPuffDesk) eines oder mehrere der folgenden Felder umfassen: kein Zeiger, eine Größe und Kennzeichen. Größe kann die in einen Ausgabepuffer übergebenen und/oder in einem Eingabepuffer verbleibenden Bits oder Bytes umfassen. Kennzeichen kann ein EOF anzeigen, z. B. das letzte Byte von Ausgabe in Reaktion auf einen Leerungs- oder EOF-Befehl in einem Eingabepufferdeskriptor. In diesem Beispiel kann der Ausgabepuffer als beim Lesen des Kennzeichens verbraucht erachtet werden, und der LetztGültAus-Wert kann inkrementiert werden, um widerzuspiegeln, dass dieser Ausgabepuffer vollständig ist, z. B. werden keine weiteren Daten in den Ausgabepuffer geladen, unabhängig davon, ob er tatsächlich voll ist (z. B. wo sich voll darauf bezieht, dass der gesamte Speicher im Puffer verwendet wird). In einer Ausführungsform werden die Pufferdeskriptoren und die Antwortdeskriptoren eins zu eines für jeden Puffer zugeordnet. In bestimmten Ausführungsformen können Puffer und ihre Deskriptoren für jede von mehreren Eingabedatenmengen (z. B. Strömen) und/oder mehreren Ausgabedatenmengen (z. B. Strömen) eingeschlossen werden.
Nachdem eine Aufgabe erstellt wurde, kann der Prozessor (z. B. Software, die auf dem Prozessor ausgeführt wird) Puffer für die Aufgabe zuordnen. Wenn der Beschleuniger die Daten in den Eingabepuffern verarbeitet und/oder der Prozessor die Ausgabedaten verbraucht (z. B. liest oder zerstört), können die Eingabe- und/oder Ausgabepuffer an die Software zurückgegeben werden, z. B. über einen Benachrichtigungsmechanismus, wie etwa, unter anderem, Unterbrechungen und Abfragen.
Pufferübermittlung: eine Aufgabe kann eine Anzahl von Datenmengen (z. B. Strömen) enthalten, beispielsweise 2 oder 3, z. B. eine Eingabe und eine oder zwei Ausgaben. Jede Datenmenge (z. B. Strom) kann durch eine Menge (z. B. ringförmiges Feld) von Pufferdeskriptoren und Antwortdeskriptoren dargestellt sein. In einer Ausführungsform kann jeder Pufferdeskriptoreintrag eines oder mehrere von Folgendem enthalten: einen Zeiger auf den entsprechenden Puffer, die Größe des Puffers (z. B. die Menge von Daten für einen Eingabepuffer und die Größe von Platz für einen Ausgabepuffer) und Kennzeichen. Beispielsweise kann die Länge der Puffer fest sein, wobei z. B. ihre Größe und/oder Position zum Zeitpunkt der Erstellung der Aufgabe bestimmt wurde. Eingabe- und/oder Ausgabepuffer können an den Beschleuniger gesendet werden durch Schreiben an eine gewisse Adresse, beispielsweise, wobei die Informationen für jeden Puffer entsprechend als ein Eintrag in den Deskriptoren hinzugefügt werden (z. B. in einem ringförmigen Feld). In einer Ausführungsform umfassen die Informationen die Anzahl der hinzugefügten Puffer. Jeder solche Pufferdeskriptor kann nach diesem Punkt implizit dem Hardwarebeschleuniger gehören, z. B. sodass der Prozessor und/oder die Software diese Daten nicht modifizieren kann, bis der Puffer, z. B. durch den Beschleuniger an den Prozessor und/oder die Software, zurückgegeben wird.
Es ist anzumerken, dass Schreiben in die Hardware (z. B. in die Deskriptoren 312, 322) der Anzahl der den einzelnen Aufgaben (z. B. Kontext) hinzugefügten Puffer ein Beispiel für Übermitteln von Puffern an einen Beschleuniger ist. In einer weiteren Ausführungsform kann die Anzahl von Puffern in jeder Aufgabe (z. B. Kontext) in die Kontextstruktur geschrieben werden, z. B. und der Prozessor kann ein Anforderungssignal an den Beschleuniger senden, damit der Beschleuniger die Kontextstruktur auf diese Information prüft.
Antwortmechanismus: der Antwortmechanismus kann sein, dass einige Daten an eine spezifische Speicheradresse geschrieben werden, z. B. wo die Details der Antwort in den Daten sind, die geschrieben wurden. Beispielhafte Mechanismen dafür, wie der Prozessor diese Daten ansehen (z. B. darüber benachrichtigt werden) soll, umfassen, unter anderem: Durchführen einer (z. B. Software-)Abfrage dieser Adresse, zum Überwachen dieser Adresse und Warten, bis sie aktualisiert wird, oder eine Unterbrechung (z. B. auf Benutzerebene) kann den Strang anweisen, auf dem Beschleuniger ausgeführt zu werden, um aktiviert zu werden und die Adresse anzusehen.
Pufferkorrelation: in einer Ausführungsform kann jeder Beschleuniger (z. B. von mehreren Beschleunigern) einen Eingabestrom und einen oder zwei Ausgabeströme haben. Wenn es zwei Ausgabeströme gibt, kann es einen primären Ausgabestrom und einen sekundären Ausgabestrom geben. Beispielsweise bei LZ4-Komprimierung kann der primäre Ausgabestrom der komprimierte Datenstrom sein, und der sekundäre Ausgabestrom kann ein umgeordneter Strom sein. In einer Ausführungsform ist die Unterscheidung, dass der primäre Strom Puffer verwenden kann oder nicht, und dass der sekundäre Strom Puffer verwenden kann. In einer Ausführungsform kann ein primärer Strom mehr Ausgaben erzeugen als der sekundäre Strom. In einem Beispiel können die primären Ausgabepuffer während der Operation gefüllt werden, z. B. mit Ausnahme eines Puffers, der für das Ende des Stroms verwendet wird. In einer Ausführungsform ist eine pufferzentrierte Sichtweise, dass Eingabe- und Ausgabepuffer nicht korreliert sind, beispielsweise, ein Eingabepuffer kann Daten in zwei (z. B. oder mehr) Ausgabepuffern erzeugen. Beispielsweise können in einen Ausgabepuffer Daten geladen sein (z. B. darin enthalten sein), die (z. B. durch einen Beschleuniger) aus zwei (z. B. oder mehr) Eingabepuffern erzeugt wurden. Allerdings können, in einer Ausführungsform, die zwei (z. B. oder mehr) Ausgabepuffer (z. B. primär und sekundär) korreliert sein, beispielsweise, ein Ausgabepuffer kann einen oder mehrere Bezüge auf Daten in dem anderen Ausgabepuffer enthalten, und die Operation (z. B. Komprimierung oder Dekomprimierung) kann verzögert sein, wenn die Ausgaberaten unterschiedlich sind. Wenn beispielsweise die primären Ausgabepuffer mit einer Rate von einem Puffer pro Eingabepuffer gefüllt wurden, aber die sekundären Ausgabepuffer mit einer Rate von einem Puffer alle zwei Eingabepuffer gefüllt wurden, kann die Situation eintreten, wo das System (z. B. Software und/oder Hardware) einen oder mehrere primäre Ausgabepuffer zum Verarbeiten hat, dies aber nicht durchführen kann, wenn es auf den entsprechenden sekundären Ausgabepuffer wartet, beispielsweise, wobei die Hardware keinen weiteren sekundären Ausgabepuffer erzeugt, weil sie wartet, dass ein weiterer primärer Ausgabepuffer gefüllt wird. In bestimmten Ausführungsformen sind die primären und sekundären Puffer nicht synchronisiert. In einer Ausführungsform kann der Prozessor (z. B. Beschleuniger) das Verarbeiten stoppen, wenn entweder die verfügbaren primären Puffer oder die verfügbaren sekundären Puffer erschöpft sind. Eine Ausführungsform hier mit mehreren Ausgabepuffern umfasst Zurückgeben eines sekundären Ausgabepuffers, wann immer ein primärer Ausgabepuffer zurückgegeben wird und/oder ein sekundärer Ausgabepuffer gefüllt wird.
In einer Ausführungsform ist der primäre Ausgabestrom ein interner Strom, und Rückgabepuffer, die nicht voll sind, sind, beispielsweise in Komprimierung mit mehreren Blöcken (z. B. DEFLATE) zurückzugeben, ein primärer Ausgabepuffer kann zurückgegeben werden, wenn das Ende eines Blocks erreicht ist, z. B. damit der Prozessor früher mit der Arbeit beginnen kann. Bestimmte Ausführungsformen hier können dem Beschleuniger ermöglichen, die Größe der verwendeten und/oder für (z. B. alle) Puffer verwendeten Daten zurückzugeben.
In einer Ausführungsform des Zurückgebens von Puffern (z. B. von einer Beschleunigungsoperation) können zwei Typen von Informationen vom Beschleuniger an die Verarbeitungsvorrichtung gesendet werden, um Puffer zurückzugeben: (1) welche Puffer zurückgegeben werden, und (2) wie viel des Puffers verwendet wurde. Eine Ausführungsform dafür ist, einen Speicherbereich für Pufferantwortdaten (z. B. Rückgabedaten) zu haben, beispielsweise, Pufferantwortdeskriptoren. In einer Ausführungsform kann der Beschleuniger (z. B. regelmäßig) diese Information schreiben, beispielsweise, gleichzeitig mit dem Senden einer Benachrichtigung an den Beschleunigeranforderer (z. B. Prozessor). In einer Ausführungsform, wenn z. B. der Beschleuniger nicht detektiert, wann diese Information gelesen wird (z. B. durch Hardware oder Software), kann die Information kumulative Daten sein, und nicht inkrementelle Daten, z. B. für einen Kontext. Ein Beispielmechanismus zum Anzeigen, welche Puffer zurückgegeben werden, ist durch eine Zählung pro Strom von zurückgegebenen Puffern, beispielsweise, wo die Pufferrückgabedaten im Wesentlichen aus einem Zähler pro Strom (z. B. 2 bis 3 Zähler) bestehen würden, und können von einer Serie von Größenfeldern begleitet sein, z. B. einem entsprechend jedem Pufferdeskriptor.
In einer Ausführungsform kann ein pufferzentriertes Übermittlungsschema asynchron zwischen Eingabe- und Ausgabeströmen und/oder -puffern sein. In einer weiteren Ausführungsform sollen explizite Synchronisierungsereignisse während der Komprimierung auftreten (z. B. ein Leerungsereignis zum Leeren aller Ausgaben entsprechend dem Verbrauch exakt dieser Menge an Eingabedaten). In einer Ausführungsform kann ein Kennzeichen eingeschlossen werden (z. B. durch die Verarbeitungsvorrichtung oder den Beschleuniger), um das asynchrone Verhalten zu brechen, beispielsweise, durch Bereitstellen der Kennzeichen mit jedem Puffer, die dem Hardwarebeschleuniger anzeigen, ob eine Synchronisierung von Daten (z. B. mit einem anderen Strom von Daten) erwünscht ist, z. B. beim Verbrauch dieses Puffers.
4 stellt ein Flussdiagramm 400 gemäß Ausführungsformen der Offenbarung dar. Nachfolgende Bezugnahmen können sowohl 3 als auch 4 betreffen.
Ein Beispiel der Architektur eines Hardwarebeschleunigers umfasst eine (z. B. Hardware-)Beschleunigungsanforderungsverwaltung 301 zum Verwalten von Anforderungen an den oder die Beschleuniger. Dies kann zentralisiert sein (wie z. B. in 3), oder jeder Beschleuniger kann seine eigene Beschleunigungsanforderungsverwaltung umfassen. In der folgenden Diskussion kann Bezugnahme auf einen einzelnen Strom erfolgen, dies kann aber auf Ausführungsformen mit mehreren Strömen anwendbar sein. Die Anzahl von Aufgabenanforderungen, die der Anforderungswarteschlange hinzugefügt oder zurückgegeben werden (z. B. an den Anforderer (z. B. Software)) können durch einen Zähler (z. B. N_EIN und/oder N_AUS) definiert sein. Die Anzahl von Aufgabenanforderungen, die der Warteschlange durch den Anforderer (z. B. Verarbeitungsvorrichtung oder Software) hinzugefügt werden, kann die Übermittlungszählung 402 genannt werden. Sie kann durch einen Wert in der Kontextdatenstruktur in der Datenspeichervorrichtung dargestellt sein und kann auch an den Beschleuniger gesendet werden, z. B. über die Ausführung eines Befehls zum Platzieren einer Anforderung in die Warteschlange. Zu bestimmten Zeiten kann es auch eine Version der Übermittlungszählung geben, die innerhalb der Verwaltung 301 gespeichert ist. Eine Ausführungsform kann die Zählungen an die Hardware senden, z. B. im Befehlspaket, wie etwa, unter anderem, Befehlspaket 232 in 2. In einer weiteren Ausführungsform können die Zählungen in der Kontextstruktur, z. B. nur in der Kontextstruktur, gespeichert sein. Die Rückgabezählung kann die Anzahl von Puffern sein, die an den Anforderer (z. B. Verarbeitungsvorrichtung oder Software) durch den Beschleuniger zurückgegeben wurden. Dies kann auch ein Wert in der Kontextdatenstruktur sein. Innerhalb der Verwaltung 301 kann es eine Kopie der Pufferdeskriptoren 312, z. B. zusammen mit einer Kopie der Übermittlungszählung, geben. Diese Kopie wird der Schnappschuss und die Schnappschusszählung genannt. Der Schnappschuss kann eine Kopie sein, die nicht mehr aktuell ist. Die Aufgabenkennung kann eine Kombination aus der Prozesskennung und der Adresse der Kontextstruktur sein. Die Aufgabenkennung kann in einer Kontextstruktur 305 gespeichert sein, kann aber (z. B. auch) in separatem Speicher (z. B. intern oder extern) gespeichert sein, um dem Prozessor (z. B. Beschleuniger) zu ermöglichen, bestimmte Daten, beispielsweise Pufferdeskriptorkopien, intern schnell zu indizieren. In einer Ausführungsform sind Pufferdeskriptoren im Speicher gespeichert, und der Prozessor (z. B. Beschleuniger) nimmt einen Schnappschuss des Zustands der Pufferdeskriptoren und operiert auf ihnen. Die Pufferdeskriptoren können durch den Prozessor aktualisiert werden, während der Beschleuniger die jetzt abgelaufene Kopie verwendet. Die Schnappschusszählung in einer Ausführungsform kann diese (z. B. potenziell) abgelaufene Kopie der Übermittlungszählung umfassen, die in der Kontextstruktur gespeichert ist, die aktuell ist. In einer Ausführungsform gibt es eine Übermittlungszählung für die Eingabepuffer und eine Übermittlungszählung für die Ausgabepuffer, wenn die Eingabe- und Ausgabepuffer entkoppelt sind. In einer Ausführungsform kann es, wenn Eingabe- und Ausgabepuffer gekoppelt (z. B. synchronisiert) sind, eine Übermittlungszählung geben.
In einer Ausführungsform kann es mehrere Beschleuniger geben, beispielsweise, Beschleuniger unterschiedlicher Typen, z. B. einen Komprimierungsbeschleuniger, einen Dekomprimierungsbeschleuniger, einen Beschleuniger für jeden spezifischen Komprimierungs- und/oder Dekomprimierungsalgorithmus. Jeder Typ kann separat verwaltet werden, z. B. wie nachfolgend beschrieben.
Es kann eine Menge von Daten geben, die mit den einzelnen Beschleunigern verbunden sind, die als die aktive Aufgabe bezeichnet wird (beispielsweise aktive Aufgaben 0 bis X, z. B. im aktiven Aufgabenfeld 412 gespeichert). Eine aktive Aufgabendatenmenge kann die Informationen zum Verwalten dieser Aufgabe umfassen. Es kann eine anliegende Aufgabenwarteschlange 410 geben (z. B. weniger als etwa 10, 8, 7, 6, 5, 4 oder 3 Einträge), die die Daten aus der Kontextstruktur für diese Aufgabe umfassen kann (z. B. den Pufferdeskriptorschnappschuss, die Zählungen, Zeiger zum Speichern/Wiederherstellen usw.). In einer Ausführungsform umfasst ein (z. B. jeder) Eintrag in der anliegenden Aufgabenwarteschlange die Daten zum Starten einer Aufgabe an einem Beschleuniger, z. B. wenn ein Beschleuniger verfügbar wird. Es kann eine Anforderungswarteschlange 408 geben, mit z. B. einer größeren Größe als die anliegende Aufgabenwarteschlange 410. In einer Ausführungsform kann ein (z. B. jeder) Eintrag in der Anforderungswarteschlange 408 die Daten für die Anforderungen umfassen, die nicht aktiv oder anliegend sind.

In einer Ausführungsform, wenn eine Anforderung für eine Operation empfangen wird (z. B. eine Anforderung zum Durchführen einer Operation durch den Prozessor und/oder zum Auslagern an den Beschleuniger), kann die Aufgabenkennung effektiv mit der Aufgabenkennung für die aktiven Aufgaben 412 und die anliegende Aufgabenwarteschlange 410 verglichen werden. In einer Ausführungsform, wenn es eine Übereinstimmung gibt, wird der entsprechende Zustand aktualisiert, beispielsweise, andernfalls kann diese Anforderung zu (z. B. dem Ende) der Anforderungswarteschlange 408 hinzugefügt werden. Wenn ein Beschleuniger verfügbar wird, kann es eine anliegende Aufgabe aus der anliegenden Aufgabenwarteschlange 410 geben, die bereit ist, unmittelbar darauf gestartet zu werden. In einer Ausführungsform, wenn es Platz in der anliegenden Aufgabenwarteschlange 410 gibt, können Anforderung aus der Anforderungswarteschlange 408 dahin geladen werden. In einer Ausführungsform, wenn die nächste Aufgabe aus der Anforderungswarteschlange 408 nicht für eine Operation durch den Beschleuniger bereit ist (z. B. wenn ihre Eingabepuffer leer sind oder Ausgabepuffer voll sind), kann die Aufgabe angehalten (oder verworfen) werden, und sie kann anderweitig zur anliegenden Aufgabenwarteschlange 410 hinzugefügt werden. In bestimmten Ausführungsformen, wenn die Aufgabe nicht für eine Operation durch den Beschleuniger bereit ist, ist die Aufgabe nicht für Beschleunigung bereit, sofern es keine spätere Anforderung gibt, die die verfügbaren Pufferzähler erhöht. Die folgende Tabelle 1 stellt ein Beispiel des Verarbeitens einer Anforderung für einen Beschleuniger durch eine Beschleunigungsanforderungsverwaltung dar. TABELLE 1:

	WENN:	GEHT ANFORDERUNG ZU:
1	ANFORDERUNG MIT EINER AKTIVEN AUFGABE ÜBEREINSTIMMT	AKTIVE AUFGABE
2	EIN BESCHLEUNIGER VERFÜGBAR IST, DIE ANLIEGENDE AUFGABENWARTESCHLANGE LEER IST UND DIE AUFGABE ZUR AUSFÜHRUNG BEREIT IST	AKTIVE AUFGABE
3	ANFORDERUNG MIT EINER ANLIEGENDEN AUFGABE ÜBEREINSTIMMT	ANLIEGENDE AUFGABENWARTESCHLANGE
4	PLATZ IN DER ANLIEGENDEN AUFGABENWARTESCHLANGE VERFÜGBAR IST, DIE ANFORDERUNGSWARTESCHLANGE LEER IST, UND DIE AUFGABE ZUR AUSFÜHRUNG BEREIT IST	ANLIEGENDE AUFGABENWARTESCHLANGE
5	ANFORDERUNG ANDERWEITIG IST	ANFORDERUNGSWARTESCHLANGE

In einer Ausführungsform, wenn eine Aufgabenanforderung für Einfügung in die anliegende Aufgabenwarteschlange 410 berücksichtigt wird (z. B. wo die Anforderung entweder direkt von einer Anforderung für den Beschleuniger oder von der Anforderungswarteschlange 408 kommt), können anfänglich die Übermittlungszählungen von der Anforderung selbst verfügbar sein. In einer Ausführungsform sind die Übermittlungszählungen die Anzahl der verfügbaren, für Eingabe und Ausgabe übermittelten Puffer, beispielsweise, als ein anderer Weg zum Behandeln von LetztGültEin und LetztGültAus. Es kann eine Übermittlungszählung (z. B. für jede Eingabe und Ausgabe) geben, und der Prozessor (z. B. Beschleuniger) kann eine Verbrauchszählung für jede Eingabe und Ausgabe aufzeichnen. In bestimmten Ausführungsformen kann der nächste Schritt sein, die relevanten Teile der Kontextstruktur zu lesen, z. B. die Rückgabezählungen (z. B. die Zeiger) und/oder die Pufferdeskriptoren anzusehen. In einer Ausführungsform, wenn eine beliebige der Rückgabezählungen mit der entsprechenden Übermittlungszählung übereinstimmt, kann diese Warteschlange leer sein, und die Aufgabe ist nicht für Beschleunigung bereit, z. B. sodass diese Anforderung fallen gelassen werden kann. Wenn die Warteschlange nicht leer ist, können die Daten in die anliegende Aufgabenwarteschlange 410 geschrieben werden. Diese Kopie der Pufferdeskriptoren und Übermittlungszählungen kann als ein Schnappschuss bezeichnet werden. In einer Ausführungsform können Übermittlungszählungen 402 ein (z. B. rollierender) Zähler sein, der zumindest eine Zählerzahl größer als die Anzahl von Puffern in dem Eingabestrom (z. B. Feld) ist. Es kann einen Übermittlungszähler für jeden Eingabestrom geben, z. B. sofern die Puffer nicht synchronisiert sind. In einer Ausführungsform sind die Schnappschusszählungen der letzte Schnappschuss der Übermittlungszählungen, die der Beschleuniger (z. B. oder die Beschleunigeranforderungsverwaltung) aus dem Speicher gelesen hat. In einer Ausführungsform werden Übermittlungszählungen aus Aufgabenanforderungsdaten berechnet, z. B. sodass der Prozessor (z. B. Beschleuniger) bestimmt, ob die Schnappschussdaten abgelaufen sind. Andere Daten 406 können einen Kontextzeiger zum Lesen der Kontextinformationen umfassen.
In einer Ausführungsform kann jede Aufgabe in der anliegenden Aufgabenwarteschlange 410 für Beschleunigung bereit sein, z. B. hat der Schnappschuss der Aufgabe zumindest einen Eingabepuffer mit Daten und einen Ausgabepuffer mit verfügbarem Platz in jedem Strom. Es kann zwei Mengen von Zählungen in jedem Eintrag in der anliegenden Aufgabenwarteschlange geben (z. B. und für jede aktive Aufgabe): eine Menge von Zählungen für den Schnappschuss, und eine zweite Menge von Zählungen für die letzten bekannten Zählungen. In einer Ausführungsform können diese anfänglich die gleichen sein, wenn aber eine Anforderung hereinkommt, die mit einem Eintrag in der anliegenden Aufgabenwarteschlange übereinstimmt, können sich die Übermittlungszählungen erhöhen, z. B. die Schnappschusszählungen dagegen nicht. Dies kann anzeigen, dass der Schnappschuss nicht mehr aktuell ist, z. B. dass mehr Puffer verfügbar sind, als in dem Schnappschuss angezeigt sind.
In einer Ausführungsform zum Aktualisieren eines Schnappschusses, wenn die Anzahl von Einträgen (z. B. im Schnappschuss) in einem beliebigen Eingabepuffer oder Ausgabepuffer auf 0 oder 1 geht, und die entsprechende Übermittlungszählung 402 (z. B. wie durch eine Anforderung aktualisiert) größer als 1 ist, können die Anforderungsverwaltung und/oder der Beschleuniger die Übermittlungszählungen 402 und Pufferdeskriptoren und Pufferantwortdeskriptoren erneut lesen und dann den (z. B. abgelaufenen) Schnappschuss entsprechend aktualisieren. In einer Ausführungsform kann dies entweder dadurch ausgelöst werden, dass der Beschleuniger die Verwendung eines Puffers beendet (und ihn z. B. zurückgibt), um die Zählungen zu verringern, oder durch eine Anforderung, die mit dieser Aufgabe übereinstimmt und die Übermittlungszählungen 402 erhöht.
5 stellt ein Flussdiagramm 500 einer Beschleunigungsoperation gemäß Ausführungsformen der Offenbarung dar. Der abgebildete Fluss 500 umfasst Empfangen von einem Komprimierungsstrang und/oder einem Dekomprimierungsstrang an einem Hardwareprozessor 502, Auslagern des Komprimierungsstrangs und/oder des Dekomprimierungsstrangs an einen Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger 504 und Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs auf dem Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten (wobei z. B. der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist) 506.
In einer Ausführungsform einer zustandslosen Komprimierungs- und Dekomprimierungsoperation kann es sein, dass keine Abhängigkeit zwischen Blöcken von Eingabe wie allen Blöcken besteht, sodass alle als unabhängige Aufgaben betrachtet werden, z. B. anstatt eines Stroms von mehreren Blöcken in einer Aufgabe. In einer Ausführungsform, wenn z. B. die Eingabegröße beim Komprimieren bekannt ist, kann dann auch die Ausgabegröße beim Dekomprimieren bekannt sein. Wenn beispielsweise alle zu komprimierenden Eingabeblöcke eine Größe (z. B. 64 KB) haben, dann können die Ausgabegrößen nach Komprimierung mehrere unterschiedliche Größen haben. Nach einer nachfolgenden Dekomprimierung können die Blöcke allesamt wieder die nicht komprimierte Größe (z. B. 64 KB) haben. Daher können Puffergrößen basierend auf der Kenntnis der Größen von Daten, als diese komprimiert waren, gewählt werden. Daher können die Eingabe- und Ausgabepuffer in einer 1:1-Beziehung für zustandslos verwendet werden, beispielsweise für jeden Eingabeblock kann ein Ausgabeblock verwendet sein, z. B. unabhängig, ob es sich um Komprimieren oder Dekomprimieren handelt. Puffergrößen können so gewählt werden, dass sie eine Größe haben, um die Ausgabedaten zu halten, egal, ob die Daten komprimiert oder dekomprimiert werden.
In einer Ausführungsform kann eine zustandsbehaftete Hardware und/oder ein zustandsbehaftetes Verfahren für eine zustandslose Operation verwendet werden. Beispielsweise kann ein Kennzeichen gesetzt werden, um dem Beschleuniger anzuzeigen, dass die Aufgabe zustandslos ist, was den Beschleuniger veranlassen kann, jeden Puffer unabhängig zu behandeln und/oder Ausgabe von jeder Operation auf einem Eingabepuffer in seinen eigenen eindeutigen Ausgabepuffer zu schreiben. Beispielsweise kann eine zustandslose Umsetzung möglicherweise nicht die Pufferdeskriptor- und/oder Antwortdeskriptorfelder verwenden. In einer Ausführungsform kann, anstatt die Puffer zu verwenden, ein (z. B. jedes) Befehlspaket Informationen umfassen, die einen Eingabe- und Ausgabepuffer für eine Operation beschreiben. Dies kann die Zeiger auf die Eingabe- und Ausgabepuffer, die Puffergrößen und Aufgabenkennzeichen umfassen. Das Befehlspaket kann auf eine interne Warteschlange (z. B. Anforderungswarteschlange 408) platziert und entnommen und ausgeführt werden. Das Befehlspaket kann (z. B. auch) eine Antwortposition zum Schreiben einer Abschlussanmerkung für diese Anforderung enthalten.
In einer Ausführungsform umfasst ein Hardwareprozessor einen Kern zum Ausführen eines Strangs und Auslagern von einem Komprimierungsstrang und/oder einem Dekomprimierungsstrang und einen Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger zum Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist. Der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger kann einen Index für einen letzten gültigen Eingabeeintrag des Eingabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Eingabeantworteintrag des Eingabepufferantwortdeskriptorfelds vergleichen und einen Index für einen letzten gültigen Ausgabeeintrag des Ausgabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Ausgabeantworteintrag des Ausgabepufferantwortdeskriptorfelds vergleichen, um zu bestimmen, wenn der Komprimierungsstrang und/oder der Dekomprimierungsstrang auszuführen ist, um Eingabedaten zu verbrauchen, um Ausgabedaten zu erzeugen. Der Prozessor und/oder Kern kann die mehreren Eingabepuffer zuordnen, die mehreren Eingabepuffer mit den Eingabedaten laden und die Einträge im Eingabepufferdeskriptorfeld für jeden entsprechenden Eingabepuffer laden. Der Prozessor und/oder Kern kann die mehreren Ausgabepuffer für die Ausgabedaten zuordnen und die Einträge im Ausgabepufferdeskriptorfeld für jeden entsprechenden Ausgabepuffer laden. Der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger kann die mehreren Ausgabepuffer mit den Ausgabedaten laden und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Ausgabepuffer laden. Der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger kann die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Eingabepuffer laden. Die Einträge im Eingabepufferdeskriptorfeld können jeweils eine Größe der im entsprechenden Eingabepuffer gespeicherten Eingabedaten umfassen, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld können jeweils eine Größe der im entsprechenden Eingabepuffer verbleibenden Eingabedaten umfassen, die Einträge im Ausgabepufferdeskriptorfeld können jeweils eine Größe des entsprechenden, zum Speichern von Ausgabedaten verfügbaren Ausgabepuffers umfassen, und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld können jeweils eine Größe der in den entsprechenden Ausgabepuffern gespeicherten Ausgabedaten umfassen. Die Eingabedaten können ein zustandsbehafteter Strom von Daten sein.
In einer weiteren Ausführungsform umfasst ein Verfahren Empfangen von einem Komprimierungsstrang und/oder einem Dekomprimierungsstrang an einem Hardwareprozessor, Auslagern des Komprimierungsstrangs und/oder des Dekomprimierungsstrangs an einen Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger und Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs auf dem Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist. Das Verfahren kann Vergleichen eines Index für einen letzten gültigen Eingabeeintrag des Eingabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Eingabeantworteintrag des Eingabepufferantwortdeskriptorfelds und Vergleichen eines Index für einen letzten gültigen Ausgabeeintrag des Ausgabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Ausgabeantworteintrag des Ausgabepufferantwortdeskriptorfelds umfassen, um zu bestimmen, wann der Komprimierungsstrang und/oder der Dekomprimierungsstrang auszuführen ist, um Eingabedaten zu verbrauchen, um Ausgabedaten zu erzeugen. Das Verfahren kann Zuordnen der mehreren Eingabepuffer, Laden der mehreren Eingabepuffer mit den Eingabedaten und Laden der Einträge im Eingabepufferdeskriptorfeld für jeden entsprechenden Eingabepuffer umfassen. Das Verfahren kann Zuordnen der mehreren Ausgabepuffer für die Ausgabedaten und Laden der Einträge im Ausgabepufferdeskriptorfeld für jeden entsprechenden Ausgabepuffer umfassen. Das Verfahren kann Laden der mehreren Ausgabepuffer mit den Ausgabedaten und Laden der entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Ausgabepuffer umfassen. Das Verfahren kann Laden der entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Eingabepuffer umfassen. Das Verfahren kann Bereitstellen von einem oder mehreren von Folgendem umfassen: die Einträge im Eingabepufferdeskriptorfeld, die jeweils eine Größe der im entsprechenden Eingabepuffer gespeicherten Eingabedaten umfassen, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld, die jeweils eine Größe der im entsprechenden Eingabepuffer verbleibenden Eingabedaten umfassen, die Einträge im Ausgabepufferdeskriptorfeld, die jeweils eine Größe des entsprechenden, zum Speichern von Ausgabedaten verfügbaren Ausgabepuffer umfassen, und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld, die jeweils eine Größe der in den entsprechenden Ausgabepuffern gespeicherten Ausgabedaten umfassen. Die Eingabedaten können ein zustandsbehafteter Strom von Daten sein.
In noch einer weiteren Ausführungsform umfasst ein System einen Hardwareprozessor zum Ausführen eines Strangs und Auslagern von einem Komprimierungsstrang und/oder einem Dekomprimierungsstrang und einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger zum Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist. Der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger kann einen Index für einen letzten gültigen Eingabeeintrag des Eingabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Eingabeantworteintrag des Eingabepufferantwortdeskriptorfelds vergleichen und einen Index für einen letzten gültigen Ausgabeeintrag des Ausgabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Ausgabeantworteintrag des Ausgabepufferantwortdeskriptorfelds vergleichen, um zu bestimmen, wenn der Komprimierungsstrang und/oder der Dekomprimierungsstrang auszuführen ist, um Eingabedaten zu verbrauchen, um Ausgabedaten zu erzeugen. Der Hardwareprozessor kann die mehreren Eingabepuffer zuordnen, die mehreren Eingabepuffer mit den Eingabedaten laden und die Einträge im Eingabepufferdeskriptorfeld für jeden entsprechenden Eingabepuffer laden. Der Hardwareprozessor kann die mehreren Ausgabepuffer für die Ausgabedaten zuordnen und die Einträge im Ausgabepufferdeskriptorfeld für jeden entsprechenden Ausgabepuffer laden. Der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger kann die mehreren Ausgabepuffer mit den Ausgabedaten laden und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Ausgabepuffer laden. Der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger kann die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Eingabepuffer laden. Die Einträge im Eingabepufferdeskriptorfeld können jeweils eine Größe der im entsprechenden Eingabepuffer gespeicherten Eingabedaten umfassen, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld können jeweils eine Größe der im entsprechenden Eingabepuffer verbleibenden Eingabedaten umfassen, die Einträge im Ausgabepufferdeskriptorfeld können jeweils eine Größe des entsprechenden, zum Speichern von Ausgabedaten verfügbaren Ausgabepuffers umfassen, und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld können jeweils eine Größe der in den entsprechenden Ausgabepuffern gespeicherten Ausgabedaten umfassen. Die Eingabedaten können ein zustandsbehafteter Strom von Daten sein.
In einer weiteren Ausführungsform umfasst ein Hardwareprozessor Mittel zum Ausführen eines Strangs und Auslagern von einem Komprimierungsstrang und/oder einem Dekomprimierungsstrang und Mittel zum Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei die Mittel zum Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt sind.
In noch einer weiteren Ausführungsform umfasst eine Einrichtung eine Datenspeichervorrichtung, die Code speichert, der, wenn durch einen Hardwareprozessor ausgeführt, den Hardwareprozessor veranlasst, eines der hier beschriebenen Verfahren durchzuführen. Eine Einrichtung kann sein, wie in der ausführlichen Beschreibung beschrieben. Ein Verfahren kann sein, wie in der ausführlichen Beschreibung beschrieben.
Ein Befehlssatz kann ein oder mehrere Befehlsformate umfassen. Ein gegebenes Befehlsformat kann verschiedene Felder (Anzahl von Bits, Ort von Bits) zum Angeben, unter anderen Dingen, der Operation, die durchgeführt werden soll (Opcode) und des bzw. der Operanden, auf denen die Operation durchgeführt werden soll, und/oder andere(s) Datenfeld(er) (z. B. Maske) definieren. Einige Befehlsformate werden durch die Definition von Befehlsvorlagen (oder Unterformaten) weiter aufgeteilt. Beispielsweise können die Befehlsvorlagen eines gegebenen Befehlsformats so definiert sein, dass sie unterschiedliche Teilsätze der Felder des Befehlsformats haben (die enthaltenen Felder sind typischerweise in der gleichen Reihenfolge, aber zumindest einige haben unterschiedliche Bitpositionen, da weniger Felder enthalten sind) und/oder so definiert sind, dass ein gegebenes Feld unterschiedlich interpretiert wird. Daher wird jeder Befehl eines ISA unter Verwendung eines gegebenen Befehlsformats (und, wenn definiert, in einer gegebenen der Befehlsvorlagen dieses Befehlsformats) ausgedrückt und umfasst Felder zum Angeben der Operation und der Operanden. Beispielsweise hat ein beispielhafter ADD-Befehl einen spezifischen Opcode und ein Befehlsformat, das ein Opcode-Feld zum Angeben dieses Opcodes und Operandenfelder zum Auswählen von Operanden (Quelle 1/Ziel und Quelle2) umfasst; und ein Auftreten dieses ADD-Befehls in einem Befehlsstrom hat spezifische Inhalte in den Operandenfeldern, die spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, Bezug nehmend auf die Advanced Vector Extensions (AVX) (AVX1 und AVX2) und unter Verwendung des VEX-Codierschemas (Vector Extensions), wurde freigegeben und/oder veröffentlicht (z. B. siehe Intel® 64 and IA-32 Architectures Software Developer's Manual, September 2015; und siehe Intel® Architecture Instruction Set Extensions Programming Reference, August 2015).
Beispielhafte Befehlsformate
Ausführungsformen des bzw. der hier beschriebenen Befehle können in unterschiedlichen Formaten ausgeführt sein. Zusätzlich werden beispielhafte Systeme, Architekturen und Pipelines nachfolgend ausführlich beschrieben. Ausführungsformen des bzw. der Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf diese aufgeführten beschränkt.
Generisches vektorfreundliches Befehlsformat
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (z. B. gibt es gewisse Felder, die für Vektoroperationen spezifisch sind). Während Ausführungsformen beschrieben sind, in denen sowohl Vektor- als auch skalare Operationen durch das vektorfreundliche Format unterstützt sind, verwenden alternative Ausführungsformen nur Vektoroperationen im vektorfreundlichen Befehlsformat.
6A-6B sind Blockdiagramme, ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon darstellend, gemäß Ausführungsformen der Offenbarung. 6A ist ein Blockdiagramm, ein generisches vektorfreundliches Befehlsformat und Klasse-A-Befehlsvorlagen davon darstellend, gemäß Ausführungsformen der Offenbarung; während 6B ein Blockdiagramm ist, das generische vektorfreundliche Befehlsformat und Klasse-B-Befehlsvorlagen davon darstellend, gemäß Ausführungsformen der Offenbarung. Insbesondere ein generisches vektorfreundliches Befehlsformat 600, für das Klasse-A- und Klasse-B-Befehlsvorlagen definiert sind, die beide Befehlsvorlagen ohne Speicherzugriff 605 und Befehlsvorlagen mit Speicherzugriff 620 umfassen. Der Begriff generisch im Kontext des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat nicht an einen spezifischen Befehlssatz gebunden ist.
Während Ausführungsformen der Offenbarung beschrieben werden, in denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder Größe) mit Datenelementbreiten (oder Größen) von 32 Bit (4 Byte) oder 64 Bit (8 Byte) (und daher besteht ein 64-Byte-Vektor entweder aus 16 Elementen in Doppelwortgröße oder alternativ aus 8 Elementen in Quadrupelwortgröße); eine 64-Byte-Vektoroperandenlänge (oder Größe) mit Datenelementbreiten (oder Größen) von 16 Bit (2 Byte) oder 8 Bit (1 Byte); eine 32-Byte-Vektoroperandenlänge (oder Größe) mit Datenelementbreiten (oder Größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); und eine 16-Byte-Vektoroperandenlänge (oder Größe) mit Datenelementbreiten (oder Größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); können alternative Ausführungsformen mehr, weniger und/oder verschiedene Vektoroperandengrößen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder verschiedenen Datenelementbreiten (z. B. Datenelementbreiten von 128 Bit (16 Byte)) unterstützen.
Die Klasse-A-Befehlsvorlagen in 6A umfassen: 1) innerhalb der Befehlsvorlagen ohne Speicherzugriff 605 ist eine Befehlsvorlage für eine Operation vom vollen Rundungssteuerungstyp ohne Speicherzugriff 610 und eine Befehlsvorlage für eine Operation vom Datentransformationstyp ohne Speicherzugriff 615 gezeigt; und 2) innerhalb der Befehlsvorlagen mit Speicherzugriff 620 ist eine temporale Befehlsvorlage mit Speicherzugriff 625 und eine nicht-temporale Befehlsvorlage mit Speicherzugriff 630 gezeigt. Die Klasse-B-Befehlsvorlagen in 6B umfassen: 1) innerhalb der Befehlsvorlagen ohne Speicherzugriff 605 ist eine Befehlsvorlage für eine Operation vom teilweisen Rundungssteuerungstyp mit Schreibmaskensteuerung ohne Speicherzugriff 612 und eine Befehlsvorlage für eine Operation vom vsize-Typ mit Schreibmaskensteuerung ohne Speicherzugriff 617 gezeigt; und 2) innerhalb der Befehlsvorlagen mit Speicherzugriff 620 ist eine Befehlsvorlage mit Schreibmaskensteuerung mit Speicherzugriff 627 gezeigt.
Das generische vektorfreundliche Befehlsformat 600 umfasst die folgenden Felder, nachfolgend in der in 6A-6B dargestellten Reihenfolge aufgeführt.
Formatfeld 640 - ein spezifischer Wert (eine Befehlsformat-Identifiziererwert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und daher Auftreten von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Daher ist dieses Feld optional in dem Sinne, dass es nicht für einen Befehlssatz benötigt wird, der nur das generische vektorfreundliche Befehlsformat hat.
Basisoperationsfeld 642 - sein Inhalt unterscheidet die unterschiedlichen Basisoperationen.
Registerindexfeld 644 - sein Inhalt gibt, direkt oder über Adresserzeugung, die Orte der Quell- und Zieloperanden an, seien sie in Registern oder im Speicher. Dies umfasst eine ausreichende Anzahl von Bits zum Auswählen von N Registern aus einer PxQ-Registerdatei (z. B. 32×512, 16×128, 32×1024, 64×1024). Während in einer Ausführungsform N bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (z. B. können bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel wirkt; können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel wirkt; können bis zu zwei Quellen und ein Ziel unterstützen).
Modifiziererfeld 646 - sein Inhalt unterscheidet Auftreten von Befehlen im generischen Vektorbefehlsformat, die Speicherzugriff angeben, von denen, die dies nicht tun; das heißt, zwischen Befehlsvorlagen ohne Speicherzugriff 605 und Befehlsvorlagen mit Speicherzugriff 620. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (in einigen Fällen die Quell- und Zieladressen unter Verwendung von Werten in Registern angebend), während Nicht-Speicherzugriffsoperationen dies nicht tun (z. B. die Quelle und Ziele sind Register). Während in einer Ausführungsform dieses Feld auch zwischen drei unterschiedlichen Wegen zum Durchführen von Speicheradressberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder verschiedene zum Durchführen von Speicheradressberechnungen unterstützen.
Zusatzoperationsfeld 650 - sein Inhalt unterscheidet, welche von mehreren unterschiedlichen Operationen zusätzlich zu der Basisoperation durchzuführen sind. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Offenbarung wird dieses Feld in ein Klassenfeld 668, ein Alpha-Feld 652 und ein Beta-Feld 654 unterteilt. Das Zusatzoperationsfeld 650 ermöglicht gängigen Gruppen von Operationen, in einem einzelnen Befehl durchgeführt zu werden, anstatt in 2, 3 oder 4 Befehlen.
Skalierungsfeld 660 - sein Inhalt ermöglicht das Skalieren des Inhalts des Indexfelds zur Speicheradresserzeugung (z. B. für Adresserzeugung, die 2^Skalierung * Index + Basis verwendet).
Verschiebungsfeld 662A- sein Inhalt wird als Teil einer Speicheradresserzeugung verwendet (z. B. für Adresserzeugung, die 2^Skalierung * Index + Basis + Verschiebung verwendet).
Verschiebungsfaktorfeld 662B (es ist anzumerken, dass die Stellung von Verschiebungsfeld 662A direkt über Verschiebungsfaktorfeld 662B anzeigt, dass das eine oder das andere verwendet wird) - sein Inhalt wird als Teil der Adresserzeugung verwendet; gibt einen Verschiebungsfaktor an, 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^Skalierung * Index + Basis + skalierte Verschiebung verwendet). Redundante Bits niedriger Ordnung werden ignoriert, und daher wird der Inhalt des Verschiebungsfaktorfelds mit der Speicheroperandengesamtgröße (N) multipliziert, um die abschließende Verschiebung zu erzeugen, die beim Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird durch die Prozessorhardware bei Laufzeit basierend auf dem vollen Opcode-Feld 674 (hier später beschrieben) und dem Datenmanipulationsfeld 654C bestimmt. Das Verschiebungsfeld 662A und das Verschiebungsfaktorfeld 662B sind optional in dem Sinn, dass sie nicht für die Befehlsvorlagen ohne Speicherzugriff 605 verwendet werden, und/oder unterschiedliche Ausführungsformen können nur eins oder keins der zwei umsetzen.
Datenelementbreitenfeld 664 - sein Inhalt unterscheidet, welche einer Anzahl von Datenelementbreiten zu verwenden ist (in einigen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für einige der Befehle). Dieses Feld ist optional in dem Sinn, dass es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung einiger Aspekte der Opcodes unterstützt werden.
Schreibmaskenfeld 670 - sein Inhalt steuert, basierend auf der Datenelementposition, ob diese Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und Zusatzoperation widerspiegelt. Klasse-A-Befehlsvorlagen unterstützen Zusammenführungs-Schreibmaskierung, während Klasse-B-Befehlsvorlagen sowohl Zusammenführungs- als auch Nullungs-Schreibmaskierung unterstützen. Beim Zusammenführen erlauben Vektormasken jedem Satz von Elementen im Ziel, vor Aktualisierungen während der Ausführung einer beliebigen Operation (angegeben durch die Basisoperation und die Zusatzoperation) geschützt zu werden; in einer anderen Ausführungsform, Beibehalten des alten Werts jedes Elements des Ziels, wo das zugehörige Maskenbit eine 0 hat. Im Gegensatz dazu, erlauben beim Nullen Vektormasken einem beliebigen Satz von Elementen im Ziel, während der Ausführung eines beliebigen Befehls (angegeben durch die Basisoperation und die Zusatzoperation) genullt zu werden; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das zugehörige Maskenbit einen 0-Wert hat. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der durchzuführenden Operation zu steuern (das heißt die Spanne von Elementen, die modifiziert werden, vom ersten bis zum letzten); allerdings ist es nicht notwendig, dass die Elemente, die modifiziert werden, aufeinander folgen. Daher erlaubt das Schreibmaskenfeld 670 teilweise Vektoroperationen, einschließlich Ladeoperation, Speicherungen, arithmetisch, logisch usw. Während Ausführungsformen der Offenbarung beschrieben werden, in denen der Inhalt des Schreibmaskenfelds 670 eines aus einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske enthält (und daher identifiziert der Inhalt des Schreibmaskenfelds 670 indirekt die durchzuführende Maskierung), erlauben alternative Ausführungsformen stattdessen oder zusätzlich dem Inhalt des Schreibmaskenfelds 670, die durchzuführende Maskierung direkt anzugeben.
Direktausführungsfeld 672 - sein Inhalt ermöglicht die Spezifikation einer Direktausführung. Dieses Feld ist optional in dem Sinn, dass es in einer Umsetzung des generischen vektorfreundlichen Formats, das keine Direktausführung unterstützt, nicht vorhanden ist, und dass es nicht in Befehlen vorhanden ist, die keine Direktausführung verwenden.
Klassenfeld 668 - sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Befehlen. Bezug nehmend auf 6A-B, wählen die Inhalte dieses Felds zwischen Klasse-A- und Klasse-B-Befehlen aus. In 6A-B werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Klasse A 668A bzw. Klasse B 668B für das Klassenfeld 668 in 6A-B).
Befehlsvorlagen von Klasse A
Im Falle der Befehlsvorlagen der Klasse A ohne Speicherzugriff 605 wird das Alpha-Feld 652 als ein RS-Feld 652A interpretiert, dessen Inhalt unterscheidet, welche der unterschiedlichen Zusatzoperationstypen durchzuführen sind (z. B. Runden 652A.1 und Datentransformation 652A.2 sind jeweils für die Befehlsvorlagen für Operation vom Rundungstyp ohne Speicherzugriff 610 bzw. die Operation vom Datentransformationstyp 615 ohne Speicherzugriff angegeben), während das Beta-Feld 654 unterscheidet, welche der Operationen des angegebenen Typs durchzuführen sind. In den Befehlsvorlagen ohne Speicherzugriff 605 sind das Skalierungsfeld 660, das Verschiebungsfeld 662A und das Verschiebungsskalierungsfeld 662B nicht vorhanden.
Befehlsvorlagen ohne Speicherzugriff - Operation vom vollen Rundungssteuerungstyp
In der Befehlsvorlage für die Operation vom vollen Rundungssteuerungstyp ohne Speicherzugriff 610 wird das Beta-Feld 654 als Rundungsteuerungsfeld 654A interpretiert, dessen Inhalte(e) statisches Runden bieten. Während in den beschriebenen Ausführungsformen der Offenbarung das Rundungssteuerungsfeld 654A ein Feld zum Unterdrücken aller Gleitkommaausnahmen (SAE) 656 und ein Rundungsoperationssteuerungsfeld 658 umfasst, können alternative Ausführungsformen diese beiden Konzepte unterstützen und in das gleiche Feld codieren oder nur ein oder das andere dieser Konzepte/Felder haben (z. B. kann nur das Rundungsoperationssteuerfeld 658 haben).
SAE-Feld 656 - sein Inhalt unterscheidet, ob oder ob nicht Melden von Ausnahmeereignissen deaktiviert werden soll; wenn der Inhalt des SAE-Felds 656 anzeigt, dass Unterdrückung aktiviert ist, meldet ein gegebener Befehl keinen Typ von Gleitkommaausnahmen-Kennzeichen und zeigt keinen Gleitkommaausnahmen-Handler an.
Rundungsoperationssteuerfeld 658 - sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden Richtung null und Runden zur nächstgelegenen Rundungszahl). Daher erlaubt das Rundungsoperationssteuerfeld 658 das Ändern des Rundungsmodus auf einer Befehlsbasis. In einer Ausführungsform der Offenbarung, wo ein Prozessor ein Steuerregister zum Angeben der Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerfelds 650 diesen Registerwert.
Befehlsvorlagen ohne Speicherzugriff - Operation vom Datentransformationstyp
In der Befehlsvorlage der Operation vom Datentransformationstyp ohne Speicherzugriff 615 wird das Beta-Feld 654 als ein Datentransformationsfeld 654B interpretiert, dessen Inhalt unterscheidet, welche aus einer Anzahl von Datentransformationen durchzuführen ist (z. B. keine Datentransformation, Mischen, Senden).
Im Falle einer Befehlsvorlage der Klasse A mit Speicherzugriff 620 wird das Alpha-Feld 652 als ein Räumungshinweisfeld 652B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise zu verwenden ist (in 6A sind temporal 652B.1 und nicht-temporal 652B.2 angegeben für die temporale Befehlsvorlage mit Speicherzugriff 625 bzw. die nicht-temporale Befehlsvorlage mit Speicherzugriff 630), während das Beta-Feld 654 als ein Datenmanipulationsfeld 654C interpretiert wird, dessen Inhalt unterscheidet, welche aus einer Anzahl von Datenmanipulationsoperationen (auch als Primitiven bekannt) durchzuführen sind (z. B. keine Manipulation; Senden; Aufwärtsumwandlung einer Quelle; und Abwärtsumwandlung eines Ziels). Die Befehlsvorlagen mit Speicherzugriff 620 umfassen das Skalierungsfeld 660 und optional das Verschiebungsfeld 662A oder das Verschiebungsskalierungsfeld 662B.
Vektorspeicherbefehle führen Vektorladeoperationen vom und Vektorspeicheroperationen im Speicher mit Umwandlungsunterstützung durch. Wie bei regulären Vektorbefehlen, transferieren Vektorspeicherbefehle Daten datenelementweise vom/in den Speicher, wobei die Elemente, die tatsächlich transferiert werden, durch die Inhalte der Vektormaske, die als Schreibmaske ausgewählt ist, bestimmt wird.
Befehlsvorlagen mit Speicherzugriff - Temporal
Temporale Daten sind Daten, die wahrscheinlich bald genug wiederverwendet werden, um von Caching profitieren zu können. Dies ist allerdings ein Hinweis, und unterschiedliche Prozessoren können dies in unterschiedlichen Weisen umsetzen, einschließlich vollständiges Ignorieren des Hinweises.
Befehlsvorlagen mit Speicherzugriff - Nicht-temporal
Nicht-temporale Daten sind Daten, die wahrscheinlich nicht bald genug wiederverwendet werden, um von Caching im Level-1-Cache profitieren zu können und denen Priorität für Räumung gegeben werden sollte. Dies ist allerdings ein Hinweis, und unterschiedliche Prozessoren können dies in unterschiedlichen Weisen umsetzen, einschließlich vollständiges Ignorieren des Hinweises.
Befehlsvorlagen von Klasse B
Im Falle der Befehlsvorlagen von Klasse B wird das Alpha-Feld 652 als eine Schreibmaskensteuerfeld (Z) 652C interpretiert, dessen Inhalt unterscheidet, ob die durch das Schreibmaskenfeld 670 gesteuerte Schreibmaskierung zusammenführend oder nullend sein soll.
Im Falle der Befehlsvorlagen der Klasse B ohne Speicherzugriff 605 wird ein Teil des Beta-Felds 654 als ein RL-Feld 657A interpretiert, dessen Inhalt unterscheidet, welche der unterschiedlichen Zusatzoperationstypen durchzuführen sind (z. B. Runden 657A.1 und Vektorlänge (VSIZE) 657A.2 sind jeweils für die Befehlsvorlage für Schreibmaskensteuerungsoperation vom teilweisen Rundungssteuerungstyp ohne Speicherzugriff 612 bzw. die Befehlsvorlage für Schreibmaskensteuerungsoperation vom VSIZE-Typ ohne Speicherzugriff 617 angegeben), während der Rest des Beta-Felds 654 unterscheidet, welche der Operationen des angegebenen Typs durchzuführen sind. In den Befehlsvorlagen ohne Speicherzugriff 605 sind das Skalierungsfeld 660, das Verschiebungsfeld 662A und das Verschiebungsskalierungsfeld 662B nicht vorhanden.
In der Befehlsvorlage für Schreibmaskensteuerungsoperation vom teilweisen Rundungssteuerungstyp ohne Speicherzugriff 610 wird der Rest des Beta-Felds 654 als ein Rundungsoperationsfeld 659A interpretiert, und Melden von Ausnahmeereignissen ist deaktiviert (ein gegebener Befehl meldet keinen Typ von Gleitkommaausnahmen-Kennzeichen und zeigt keinen Gleitkommaausnahmen-Handler an).
Rundungsoperationssteuerfeld (Round operation) 659A - wie bei Rundungsoperationssteuerfeld 658, unterscheidet sein Inhalt, welche aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden Richtung null und Runden zur nächstgelegenen Rundungszahl). Daher erlaubt das Rundungsoperationssteuerfeld 659A das Ändern des Rundungsmodus auf einer Befehlsbasis. In einer Ausführungsform der Offenbarung, wo ein Prozessor ein Steuerregister zum Angeben der Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerfelds 650 diesen Registerwert.
In der Befehlsvorlage der Schreibmaskensteuerungsoperation vom VSIZE-Typ ohne Speicherzugriff 617 wird der Rest des Beta-Felds 654 als ein Vektorlängenfeld 659B interpretiert, dessen Inhalt unterscheidet, auf welcher einer Anzahl von Datenvektorlängen durchgeführt werden soll (z. B. 128, 256 oder 512 Byte).
Im Falle einer Befehlsvorlage der Klasse B mit Speicherzugriff 620 wird ein Teil des Beta-Felds 654 als ein Sendefeld 657B interpretiert, dessen Inhalt unterscheidet, ob oder ob nicht die Datenmanipulationsoperation vom Sendetyp durchzuführen ist, während der Rest des Beta-Felds 654 als das Vektorlängenfeld 659B interpretiert wird. Die Befehlsvorlagen mit Speicherzugriff 620 umfassen das Skalierungsfeld 660 und optional das Verschiebungsfeld 662A oder das Verschiebungsskalierungsfeld 662B.
Hinsichtlich des generischen vektorfreundlichen Befehlsformats 600, ist ein volles Opcode-Feld 674 gezeigt, das Formatfeld 640, das Basisoperationsfeld 642 und das Datenelementbreitenfeld 664 umfassend. Während eine Ausführungsform gezeigt ist, bei der das volle Opcode-Feld 674 all diese Felder umfasst, umfasst das volle Opcode-Feld 674 in Ausführungsformen, die nicht alle unterstützen, weniger als alle diese Felder. Das volle Opcode-Feld 674 stellt den Operationscode (Opcode) bereit.
Das Zusatzoperationsfeld 650, das Datenelementbreitenfeld 664 und das Schreibmaskenfeld 670 ermöglichen, dass diese Merkmale auf einer befehlsweisen Grundlage im generischen vektorfreundlichen Befehlsformat angegeben werden können.
Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugt typenbehaftete Befehle dahingehend, dass sie ermöglichen, die Maske basierend auf unterschiedlichen Datenelementbreiten anzuwenden.
Die verschiedenen Befehlsvorlagen, die in Klasse A und Klasse B zu finden sind, sind in unterschiedlichen Situationen vorteilhaft. In einigen Ausführungsformen der Offenbarung können unterschiedliche Prozessoren oder unterschiedliche Kerne nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Beispielsweise kann ein universeller reihenfolgeveränderter (Out-of-order) Hochleistungskern, der für universelles Rechnen gedacht ist, nur Klasse B unterstützen, ein Kern, der primär für Grafik und/oder wissenschaftliches (Durchsatz) Rechnen gedacht ist, kann nur Klasse A unterstützen, und ein Kern, der für beides gedacht ist, kann beide unterstützen (natürlich liegt ein Kern, der einen gewissen Mix aus Vorlagen und Befehlen von beiden Klassen hat, aber nicht alle Vorlagen und Befehle von beiden Klassen, innerhalb des Geltungsbereichs der Offenbarung). Außerdem kann ein einzelner Prozessor mehrere Kerne umfassen, die alle die gleiche Klasse unterstützen oder von denen verschiedene Kerne unterschiedliche Klassen unterstützen. Beispielsweise kann in einem Prozessor mit separaten Grafik- und universellen Kernen einer der Grafikkerne, die primär für Grafik und/oder wissenschaftliches Rechnen gedacht sind, nur Klasse A unterstützen, während einer oder mehrere der universellen Kerne universelle Hochleistungskerne mit reihenfolgeveränderter (Out-of-order) Ausführung und Registerumbenennung sein können, die für universelles Rechnen gedacht sind, die nur Klasse B unterstützen. Ein weiterer Prozessor, der keinen separaten Grafikkern hat, kann einen oder mehrere reihenfolgetreue (In-order) oder reihenfolgeveränderte (Out-of-order) Kerne umfassen, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können in verschiedenen Ausführungsformen der Offenbarung Merkmale von einer Klasse auch in der anderen Klasse umgesetzt sein. Programme, die in einer höheren Sprache geschrieben sind, würden in eine Vielzahl von unterschiedlichen ausführbaren Formen gebracht werden (z. B. just-in-time-kompiliert oder statisch kompiliert), umfassend: 1) eine Form, nur Befehle der Klasse(n) aufweisend, die durch den Zielprozessor für Ausführung unterstützt werden; oder 2) eine Form, alternative Routinen aufweisend, die unter Verwendung unterschiedlicher Kombinationen aller Klassen geschrieben wurden und Steuerflusscode aufweisen, der die auszuführenden Routinen basierend auf den durch den Prozessor, der momentan den Code ausführt, unterstützten Befehlen auswählt.
Beispielhaftes spezifisches vektorfreundliches Befehlsformat
7 ist ein Blockdiagramm, ein beispielhaftes spezifisches vektorfreundliches Befehlsformat darstellend, gemäß Ausführungsformen der Offenbarung. 7 zeigt ein spezifisches vektorfreundliches Befehlsformat 700, dass spezifisch in dem Sinn ist, dass es den Ort, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für einige dieser Felder angibt. Das spezifische vektorfreundliche Befehlsformat 700 kann verwendet werden, um den x86-Befehlssatz zu erweitern, und daher sind einige der Felder ähnlich wie oder die gleichen wie die, die im bestehenden x86-Befehlssatz und Erweiterungen davon (z. B. AVX) verwendet werden. Dieses Feld bleibt konsistent mit dem Präfixcodierungsfeld, dem Real-Opcode-Bytefeld, dem MOD R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und dem Direktausführungsfeld des vorhandenen x86-Befehlssatzes mit Erweiterungen. Die Felder aus 6, in die die Felder aus 7 abgebildet werden, sind dargestellt.
Es versteht sich, dass, obwohl Ausführungsformen der Offenbarung zu Darstellungszwecken unter Bezugnahme auf das spezifische vektorfreundliche Befehlsformat 700 im Kontext des generischen vektorfreundlichen Befehlsformats 600 beschrieben sind, die Offenbarung nicht auf das spezifische vektorfreundliche Befehlsformat 700 beschränkt ist, ausgenommen dort, wo beansprucht. Beispielsweise berücksichtigt das generische vektorfreundliche Befehlsformat 600 eine Vielzahl möglicher Größen für die verschiedenen Felder, während das spezifische vektorfreundliche Befehlsformat 700 als Felder mit spezifischen Größen aufweisend gezeigt ist. Als spezifisches Beispiel, während das Datenelementbreitenfeld 664 als ein Ein-Bit-Feld im spezifischen vektorfreundlichen Befehlsformat 700 dargestellt ist, ist die Offenbarung nicht so beschränkt (das heißt, das generische vektorfreundliche Befehlsformat 600 zieht andere Größen für das Datenelementbreitenfeld 664 in Betracht).
Das generische vektorfreundliche Befehlsformat 600 umfasst die folgenden Felder, nachfolgend in der in 7A dargestellten Reihenfolge aufgeführt.
EVEX-Präfix (Bytes 0-3) 702 - ist in einer Vier-Byte-Form codiert.
Formatfeld 640 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Formatfeld 640, und es beinhaltet 0×62 (der eindeutige Wert, der in einer Ausführungsform der Offenbarung zum Unterscheiden des vektorfreundlichen Befehls verwendet wird).
Das zweite-vierte Byte (EVEX-Bytes 1-3) umfassen eine Anzahl von Bitfeldern, die eine spezifische Fähigkeit bieten.
REX-Feld 705 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] - R), einem EVEX.X-Bitfeld (EVEX-Byte 1, bit [6] - X) und einem 657BEX-Byte 1, Bit[5] - B). Die EVEX.R-, EVEX.X- und EVEX.B-Bitfelder bieten die gleiche Funktionalität wie die zugehörigen VEX-Bitfelder und werden unter Verwendung der Einerkomplementform codiert, d. h. ZMM0 wird als 1111B codiert, ZMM15 wird als 0000B codiert. Andere Felder der Befehle codieren die niedrigeren drei Bits der Registerindizes, wie im Fachgebiet bekannt ist (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb durch Addieren von EVEX.R, EVEX.X und EVEX.B gebildet werden können.
REX'-Feld 610 - dies ist der erste Teil des REX'-Felds 610 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Register-Satzes zu codieren. In einer Ausführungsform der Offenbarung wird dieses Bit, zusammen mit anderen, wie nachfolgend angezeigt, im bitinvertierten Format gespeichert, um (im wohlbekannten x86-32-Bit-Modus) vom BOUND-Befehl zu unterscheiden, dessen Real-Opcode-Byte 62 ist, akzeptiert aber nicht im MOD-R/M-Feld (nachfolgend beschrieben) den Wert von 11 im MOD-Feld; alternative Ausführungsformen der Offenbarung speichern dieses und die anderen nachfolgend angezeigten Bits nicht im invertierten Format. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten, R'Rrrr wird durch Kombinieren von EVEX.R', EVEX.R und den anderen RRR aus anderen Feldern gebildet.
Opcode-Abbildungsfeld 715 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
Datenelementbreitenfeld 664 (EVEX-Byte 2, Bit [7] - W) - wird durch die Notation EVEX.W repräsentiert. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
EVEX.vvvv 720 (EVEX-Byte 2, Bits [6:3]-vvvv) - die Rolle von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, angegeben in invertierter Form (Einerkomplement) und ist gültig für Befehle mit 2 oder mehr Quelloperanden; 2) EVEX.vvvv codiert den Zielregisteroperanden, angegeben in Einerkomplementform für gewisse Vektorverschiebungen; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Daher codiert EVEX.vvvv-Feld 720 die 4 Bits niedriger Ordnung des ersten Quellregisterspezifizierers, gespeichert in invertierter Form (Einerkomplement). In Abhängigkeit vom Befehl wird ein zusätzliches unterschiedliches EVEX-Bitfeld verwendet, um die Spezifizierergröße auf 32 Register zu erweitern.
EVEX.U-Klassenfeld 668 (EVEX-Byte 2, Bit [2]-U) - Wenn EVEX.U = 0, zeigt dies Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, zeigt dies Klasse B oder EVEX.U1 an.
Präfixcodierungsfeld 725 (EVEX-Byte 2, Bits [1:0]-pp) bietet zusätzliche Bits für das Basisoperationsfeld. Zusätzlich zum Bereitstellen von Unterstützung für ältere SSE-Befehle im EVEX-Präfixformat hat dies auch den Vorteil des Kompaktierens des SIMD-Präfixes (anstatt dass ein Byte erforderlich ist, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Präfix nur 2 Bits). In einer Ausführungsform werden, um die älteren SSE-Befehle zu unterstützen, die ein SIMD-Präfix (66H, F2H, F3H) sowohl im älteren Format als auch im EVEX-Präfixformat verwenden, diese älteren SIMD-Präfixe in das SIMD-Präfixcodierungsfeld codiert und werden bei Laufzeit in das ältere SIMD-Präfix erweitert, bevor Sie der PLA des Decodierers bereitgestellt werden (sodass die PLA sowohl das ältere als auch das EVEX-Format dieser älteren Befehle ohne Modifikationen ausführen kann). Obwohl neuere Befehle den Inhalt des EVEX-Präfixcodierungsfelds direkt als eine Opcode-Erweiterung verwenden können, erweitern gewisse Ausführungsformen aus Gründen der Konsistenz in einer ähnlichen Weise, erlauben aber, dass unterschiedliche Bedeutungen durch diese älteren SIMD-Präfixe angegeben werden. Eine alternative Ausführungsform kann die PLA neu konzipieren, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, und daher die Erweiterung nicht benötigen.
Alpha-Feld 652 (EVEX-Byte 3, Bit [7] - EH; auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.write mask control (Schreibmaskensteuerung) und EVEX.N; auch dargestellt als α) - wie vorher beschrieben, ist dieses Feld kontextspezifisch.
Beta-Feld 654 (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 dargestellt durch βββ) - wie vorher beschrieben, ist dieses Feld kontextspezifisch.
REX'-Feld 610 - dies ist der Rest des REX'-Felds 1410 und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Register-Satzes zu codieren. Dieses Bit wird im bitinvertierten Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten, V'VVVV wird durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
Schreibmaskenfeld 670 (EVEX-Byte 3, Bits [2:0]-kkk) - sein Inhalt gibt den Index eines Registers in den Schreibmaskenregistern an, wie vorher beschrieben. In einer Ausführungsform der Offenbarung hat der spezifische Wert EVEX.kkk=000 ein spezielles Verhalten, implizierend, dass keine Schreibmaske für den bestimmten Befehl verwendet wird (dies kann auf verschiedene Weisen umgesetzt werden, einschließlich des Verwendens einer Schreibmaske, fest mit allen verdrahtet, oder von Hardware, die die Maskierungshardware umgeht).
Das Real-Opcode-Feld 730 (Byte 4) ist auch als das Opcode-Byte bekannt. Teil des Opcodes wird in diesem Feld angegeben.
MOD-R/M-Feld 740 (Byte 5) umfasst MOD-Feld 742, Reg-Feld 744 und R/M-Feld 746. Wie zuvor beschrieben, unterscheidet der Inhalt des MOD-Felds 742 zwischen Operationen mit Speicherzugriff und ohne Speicherzugriff. Die Rolle von Reg-Feld 744 kann für zwei Situationen zusammengefasst werden: Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden, oder als eine Opcode-Erweiterung behandelt zu werden und nicht zum Codieren eines Befehlsoperanden verwendet zu werden. Die Rolle von R/M-Feld 746 kann Folgendes umfassen: Codieren des Befehlsoperanden, der sich auf eine Speicheradresse bezieht, oder Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden.
Skalierungs-Index-Basis-Byte (SIB, Scale, Index, Base) (Byte 6) - Wie zuvor beschrieben, wird der Inhalt des Skalierungsfelds 650 für Speicheradressenerzeugung verwendet. SIB.xxx 754 und SIB.bbb 756 - auf die Inhalte dieser Felder wurde vorher im Zusammenhang mit den Registerindizes Xxxx und Bbbb Bezug genommen.
Verschiebungsfeld 662A (Bytes 7-10) - wenn MOD-Feld 742 eine 10 beinhaltet, sind Bytes 7-10 das Verschiebungsfeld 662A, und es funktioniert genauso wie die ältere 32-Bit-Verschiebung (disp32) und arbeitet mit Bytegranularität.
Verschiebungsfaktorfeld 662B (Byte 7) - wenn MOD-Feld 742 eine 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 662B. Der Ort dieses Felds ist der gleiche wie der der älteren 8-Bit-Verschiebung (disp8) im x86-Befehlssatz, die mit Bytegranularität arbeitet. Da disp8 vorzeichenerweitert ist, kann es nur Versätze zwischen -128 und 127 Bytes adressieren; in Verbindung mit 64-Byte-Cache-Zeilen verwendet disp8 acht (8) Bits, die auf nur vier wirklich sinnvolle Werte -128, -64, 0 und 64 gesetzt werden können; da häufig ein größerer Bereich benötigt ist, wird disp32 verwendet; disp32 erfordert allerdings 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 662B eine Neuinterpretation von disp8; bei Verwenden von Verschiebungsfaktorfeld 662B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds, multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Dieser Typ von Verschiebung wird als disp8*N bezeichnet. Dies verringert die durchschnittliche Befehlslänge (ein einzelnes Byte wird für die Verschiebung verwendet, aber mit einem viel größeren Bereich). Eine solche komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist und dass daher die redundanten Bits niedrigerer Ordnung des Adressenversatzes nicht codiert werden müssen. Mit anderen Worten, das Verschiebungsfaktorfeld 662B ersetzt die 8-Bit-Verschiebung des älteren x86-Befehlssatzes. Daher wird das Verschiebungsfaktorfeld 662B auf die gleiche Weise codiert wie eine 8-Bit-Verschiebung des x86-Befehlssatzes (also keine Änderungen in den ModRM/SIB-Codierregeln), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird. Mit anderen Worten, es gibt keine Änderungen in den Codierregeln oder Codierlängen, sondern nur bei der Interpretation des Verschiebungswertes durch Hardware (die die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byteweisen Adressenversatz zu erhalten). Direktausführungsfeld 672 arbeitet, wie zuvor beschrieben.
Volles Opcode-Feld
7B ist ein Blockdiagramm, die Felder des spezifischen vektorfreundlichen Befehlsformats 700, die das volle Opcode-Feld 674 bilden, darstellend, gemäß einer Ausführungsform der Offenbarung. Insbesondere umfasst das volle Opcode-Feld 674 das Formatfeld 640, das Basisoperationsfeld 642 und das Datenelementbreitenfeld (W) 664. Das Basisoperationsfeld 642 umfasst das Präfixcodierungsfeld 725, das Opcode-Abbildungsfeld 715 und das Real-Opcode-Feld 730.
Registerindexfeld
7C ist ein Blockdiagramm, die Felder des spezifischen vektorfreundlichen Befehlsformats 700, die das Registerindexfeld 644 bilden, darstellend, gemäß einer Ausführungsform der Offenbarung. Insbesondere umfasst das Registerindexfeld 644 das REX-Feld 705, das REX'-Feld 710, das MODR/M.reg-Feld 744, das MODR/M.r/m-Feld 746, das VVVV-Feld 720, das xxx-Feld 754 und das bbb-Feld 756.
Zusatzoperationsfeld
7D ist ein Blockdiagramm, die Felder des spezifischen vektorfreundlichen Befehlsformats 700, die das Zusatzoperationsfeld 650 bilden, darstellend, gemäß einer Ausführungsform der Offenbarung. Wenn das Klassenfeld (U) 668 eine 0 enthält, bedeutet dies EVEX.U0 (Klasse A 668A); wenn es eine 1 enthält, bedeutet dies EVEX.U1 (Klasse B 668B). Wenn U=0 und das MOD-Feld 742 eine 11 enthält (eine Operation ohne Speicherzugriff bedeutend), wird das Alpha-Feld 652 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 652A interpretiert. Wenn das rs-Feld 652A eine 1 enthält (Runden 652A.1), wird das Beta-Feld 654 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerfeld 654A interpretiert. Das Rundungssteuerfeld 654A umfasst ein Ein-Bit-SAE-Feld 656 und ein Zwei-Bit-Rundungsoperationsfeld 658. Wenn das rs-Feld 652A eine 0 enthält (Datentransformation 652A.2), wird das Beta-Feld 654 (EVEX-Byte 3, Bits [6:4]- SSS) als das Drei-Bit-Datentransformationsfeld 654B interpretiert. Wenn U=0 und das MOD-Feld 742 eine 00, 01 oder 10 enthält (eine Operation mit Speicherzugriff bedeutend), wird das Alpha-Feld 652 (EVEX-Byte 3, Bit [7] - EH) als das Räumungshinweisfeld (EH, Eviction Hint) 652B interpretiert, und das Beta-Feld 654 (EVEX-Byte 3, Bits [6:4]- SSS) wird als ein Drei-Bit-Datenmanipulationsfeld 654C interpretiert.
Wenn U=1, wird das Alpha-Feld 652 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerfeld (Z) 652C interpretiert. Wenn U=1 und das MOD-Feld 742 eine 11 enthält (eine Operation ohne Speicherzugriff bedeutend), wird ein Teil des Beta-Felds 654 (EVEX-Byte 3, Bit [4]- S₀) als das RL-Feld 657A interpretiert; wenn es eine 1 enthält (Runden 657A.1), wird der Rest des Beta-Felds 654 (EVEX-Byte 3, Bit [6-5]- S_2-1) als das Rundungsoperationsfeld 659A interpretiert, während wenn das RL-Feld 657A eine 0 enthält (VSIZE 657.A2), wird der Rest des Beta-Felds 654 (EVEX-Byte 3, Bit [6-5]- S_2-1) als das Vektorlängenfeld 659B (EVEX-Byte 3, Bit [6-5]- L_1-0) interpretiert. Wenn U=1 und das MOD-Feld 742 eine 00, 01 oder 10 enthält (eine Operation mit Speicherzugriff bedeutend), wird das Beta-Feld 654 (EVEX-Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 659B (EVEX-Byte 3, Bit [6-5]- L_1-0) und das Sendefeld 657B (EVEX-Byte 3, Bit [4]- B) interpretiert.
Beispielhafte Registerarchitektur

8 ist ein Blockdiagramm einer Registerarchitektur 800 gemäß einer Ausführungsform der Offenbarung. In der dargestellten Ausführungsform gibt es 32 Vektorregister 810, die 512 Bits breit sind; auf diese Register wird als zmm0 bis zmm31 Bezug genommen. Die 256 Bits der niedrigeren Ordnung der 16 unteren zmm-Register werden auf den Registern ymm0-16 überlagert. Die 128 Bits der niedrigeren Ordnung der 16 unteren zmm-Register (die 128 Bits der niedrigeren Ordnung der ymm-Register) werden auf den Registern xmm0-15 überlagert. Das spezifische vektorfreundliche Befehlsformat 700 operiert auf dieser überlagerten Registerdatei, wie in den folgenden Tabellen dargestellt.

Anpassbare Vektorlänge	Klasse	Operationen	Register
Befehlsvorlagen, die das Vektorlängenfeld 659B nicht umfassen	A ( 6A; U=0)	610, 615, 625, 630	zmm-Register (die Vektorlänge ist 64 Byte)
	B ( 6B; U=1)	612	zmm-Register (die Vektorlänge ist 64 Byte)
Befehlsvorlagen, die das Vektorlängenfeld 659B umfassen	B ( 6B; U=1)	617, 627	zmm-, ymm- oder xmm-Register (die Vektorlänge ist 64 Byte, 32 Byte oder 16 Byte) in Abhängigkeit vom Vektorlängenfeld 659B

Mit anderen Worten, das Vektorlängenfeld 659B wählt zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede der solchen kürzeren Längen die halbe Länge der vorhergehenden Länge ist, und Befehlsvorlagen ohne das Vektorlängenfeld 659B operieren auf der maximalen Vektorlänge. Ferner operieren, in einer Ausführungsform, die Klasse-B-Befehlsvorlagen des spezifischen vektorfreundlichen Befehlsformats 700 auf gepackten oder skalaren Gleitkommadaten mit einfacher/doppelter Genauigkeit und gepackten oder skalaren ganzzahligen Daten. Skalare Operationen sind Operationen, die auf der Datenelementposition der niedrigsten Ordnung in einem zmm/ymm/xmm-Register durchgeführt werden; die Datenelementpositionen der höheren Ordnung werden, in Abhängigkeit von der Ausführungsform, entweder so gelassen, wie sie vor dem Befehl waren, oder genullt.
Schreibmaskenregister 815 - in der dargestellten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils 64 Bit groß sind. In einer alternativen Ausführungsform haben die Schreibmaskenregister 815 eine Größe von 16 Bit. Wie zuvor beschrieben, kann, in einer Ausführungsform der Offenbarung, das Vektormaskenregister k0 nicht als eine Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 anzeigen würde, für eine Schreibmaske verwendet wird, wählt sie eine fest verdrahtete Schreibmaske 0×FFFF aus, dadurch effektiv die Schreibmaskierung für diesen Befehl deaktivierend.
Universelle Register 825 - in der dargestellten Ausführungsform gibt es sechzehn universelle 64-Bit-Register, die zusammen mit den vorhandenen x86-Adressierungsmodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register sind mit RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.
Die skalare Gleitkommastapelregisterdatei (x87-Stapel) 845, die als Alias für die gepackte ganzzahlige flache MMX-Registerdatei 850 verwendet wird - in der dargestellten Ausführungsform ist der x87-Stapel ein Acht-Elemente-Stapel, 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 gepackten ganzzahligen 64-Bit-Daten durchzuführen sowie um Operanden für einige Operationen zu halten, die zwischen dem MMX- und dem XMM-Register durchgeführt werden.
Alternative Ausführungsformen der Offenbarung können weitere oder engere Register verwenden. Zusätzlich können alternative Ausführungsformen der Offenbarung mehr, weniger oder unterschiedliche Registerdateien und Register verwenden.
Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
Prozessorkerne können auf unterschiedliche Weise, für unterschiedliche Zwecke und in unterschiedlichen Prozessoren umgesetzt werden. Beispielsweise können Umsetzungen solcher Kerne umfassen: 1) einen universellen reihenfolgetreuen (In-order) Kern, gedacht für universelles Rechnen; 2) einen universellen reihenfolgeveränderten (Out-of-order) Hochleistungskern, gedacht für universelles Rechnen; 3) einen speziellen Kern, primär gedacht für Grafik und/oder wissenschaftliches (Durchsatz) Rechnen. Umsetzungen von unterschiedlichen Prozessoren können umfassen: 1) eine CPU, einen oder mehrere universelle reihenfolgetreue (In-order) Kerne, gedacht für universelles Rechnen, umfassend, und/oder einen oder mehrere universelle reihenfolgeveränderte (Out-of-order) Kerne, gedacht für universelles Rechnen; und 2) einen Koprozessor, einen oder mehrere spezielle Kerne, primär gedacht für Grafik und/oder wissenschaftliches (Durchsatz) Rechnen, umfassend. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die umfassen können: 1) den Koprozessor auf einem von der CPU separaten Chip; 2) den Koprozessor auf einem separaten Die im gleichen Chipgehäuse wie eine CPU (in diesem Fall wird ein solcher Koprozessor manchmal als spezielle Logik, wie etwa als integrierte Grafik und/oder wissenschaftliche (Durchsatz) Logik, oder als spezielle Kerne bezeichnet); und 4) ein System auf einem Chip, das auf demselben Die die beschriebene CPU (manchmal als der bzw. die Anwendungskerne oder Anwendungsprozessoren bezeichnet), den oben beschriebenen Koprozessor und zusätzliche Funktionalität umfassen kann. Beispielhafte Kernarchitekturen werden als nächstes beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen.
Beispielhafte Kernarchitekturen
Blockdiagramm zu reihenfolgetreuem (In-order) und reihenfolgeverändertem (Out-of-order) Kern
9A ist ein Blockdiagramm, das sowohl eine beispielhafte reihenfolgetreue (In-order) Pipeline als auch eine beispielhafte reihenfolgeveränderte (Out-of-order) Ausgabe-/Ausführungspipeline mit Registerumbenennung gemäß Ausführungsformen der Offenbarung darstellt. 9B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines reihenfolgetreuen (In-order) Architekturkerns als auch eines reihenfolgeveränderten (Out-of-order) Ausgabe-/Ausführungs-Architekturkerns mit Registerumbenennung, in einen Prozessor einzuschließen, gemäß Ausführungsformen der Offenbarung darstellt. Die Felder mit durchgezogenen Linien in 9A-B stellen die reihenfolgetreue Pipeline und den reihenfolgetreuen Kern dar, während die optionale Hinzufügung von Feldern mit gestrichelten Linien die/den reihenfolgeveränderte(n) Ausgabe-/Ausführungspipeline bzw. - kern mit Registerumbenennung darstellt. Unter der Voraussetzung, dass der reihenfolgetreue Aspekt eine Teilmenge des reihenfolgeveränderten Aspekts ist, wird der reihenfolgeveränderte Aspekt beschrieben.
In 9A umfasst eine Prozessorpipeline 900 eine Abrufstufe 902, eine Längendecodierstufe 904, eine Decodierstufe 906, eine Zuordnungsstufe 908, eine Umbenennungsstufe 910, eine Ablaufsteuerungsstufe (Scheduling, auch als Verteilung oder Ausgabe bekannt) 912, eine Registerlese-/Speicherlesestufe 914, eine Ausführungsstufe 916, eine Zurückschreibe-/Speicherschreibestufe 918, eine Ausnahmenbehandlungsstufe 922 und eine Übergabestufe 924.
9B zeigt Prozessorkern 990, eine Frontendeinheit 930 umfassend, gekoppelt mit einer Ausführungsengineeinheit 950, und beide sind mit einer Speichereinheit 970 gekoppelt. Der Kern 990 kann ein Kern mit reduziertem Befehlssatz (RISC, Reduced Instruction Set Computing), ein Kern mit komplexem Befehlssatz (CISC, Complex Instruction Set Computing), ein Kern mit sehr langen Befehlswörtern (VLIW, Very Long Instruction Word) oder ein hybrider oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 990 ein spezieller Kern sein, wie etwa, beispielsweise, ein Netzwerk- oder Kommunikationskern, eine Komprimierungsengine, ein Koprozessorkern, ein universeller Berechnungskern für Grafikprozessoreinheiten (GPGPU, General Purpose Computing Graphics Processing Unit), ein Grafikkern oder ähnliches.
Die Frontendeinheit 930 umfasst eine Verzweigungsvorhersageeinheit 932, gekoppelt mit einer Befehlscacheeinheit 934, die mit einem Befehlsübersetzungspuffer (TLB, Instruction Translation Lookaside Buffer) 936 gekoppelt ist, der mit einer Befehlsabrufeinheit 938 gekoppelt ist, die mit einer Decodiereinheit 940 gekoppelt ist. Die Decodiereinheit 940 (oder Decodierer oder Decodierereinheit) kann Befehle (z. B. Makrobefehle) decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocodeeinstiegspunkte, Mikrobefehle oder Befehle oder andere Steuersignale decodieren, die aus den ursprünglichen Befehlen decodiert werden oder diese anderweitig widerspiegeln oder aus diesen abgeleitet sind. Die Decodiereinheit 940 kann unter Verwendung verschiedener unterschiedlicher Mechanismen umgesetzt sein. Beispiele von geeigneten Mechanismen umfassen, sind aber nicht beschränkt auf, Nachschlagetabellen, Hardwareumsetzungen, programmierbare Logikarrays (PLAs), Mikrocode-Nur-Lese-Speicher (ROMs, Read Only Memories) usw. In einer Ausführungsform umfasst der Kern 990 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für gewisse Makrobefehle speichert (z. B. in Decodiereinheit 940 oder anderweitig innerhalb der Frontendeinheit 930). Die Decodiereinheit 940 ist mit einer Umbenennungs-/Zuordnungseinheit 952 in der Ausführungsengineeinheit 950 gekoppelt.
Die Ausführungsengineeinheit 950 umfasst die Umbenennungs-/Zuordnungseinheit 952, gekoppelt mit einer Rückzugseinheit 954 und einer Menge von einer oder mehreren Ablaufsteuerungseinheiten 956. Die Ablaufsteuerungseinheit(en) 956 stellt bzw. stellen eine beliebige Anzahl von unterschiedlichen Ablaufsteuerungseinheiten dar, einschließlich Reservierungsstationen, zentralem Befehlsfenster usw. Ablaufsteuerungseinheit(en) 956 ist bzw. sind mit der bzw. den physischen Registerdateieinheiten 958 gekoppelt. Jede der physischen Registerdateieinheiten 958 stellt eine oder mehrere physische Registerdateien dar, von denen unterschiedliche einen oder mehrere unterschiedliche Datentypen speichern, wie etwa skalare Ganzzahlen, skalare Gleitkommazahlen, gepackte Ganzzahlen, gepackte Gleitkommazahlen, Vektorganzzahlen, Vektorgleitkommazahlen, Status (z. B. einen Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. In einer Ausführungsform umfasst die physische Registerdatei(en)einheit 958 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und universelle Register bereitstellen. Die physische(n) Registerdatei(en)einheit(en) 958 wird bzw. werden von der Rückzugseinheit 954 überlappt, um verschiedene Weisen darzustellen, in denen Registerumbenennung und reihenfolgeveränderte Ausführung umgesetzt werden können (z. B. unter Verwendung eines Neuordnungspuffers und einer Rückzugsregisterdatei; unter Verwendung einer Zukunftsdatei, eines Verlaufspuffers und einer Rückzugsregisterdatei; unter Verwendung einer Registerabbildung und einer Sammlung von Registern usw.). Die Rückzugseinheit 954 und die physische(n) Registerdatei(en)einheit(en) 958 ist bzw. sind mit dem bzw. den Ausführungsclustern 960 gekoppelt. Das bzw. die Ausführungscluster 960 umfassen eine Menge von einer oder mehreren Ausführungseinheiten 962 und eine Menge von einer oder mehreren Speicherzugriffseinheiten 964. Die Ausführungseinheiten 962 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) auf verschiedenen Typen von Daten (z. B. skalare Gleitkommadaten, gepackte ganzzahlige Daten, gepackte Gleitkommadaten, Vektorganzzahl, Vektorgleitkomma) durchführen. Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten, speziell für spezifische Funktionen oder Mengen von Funktionen bestimmt, umfassen können, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten umfassen, die allesamt alle Funktionen durchführen. Die Ablaufsteuerungseinheit(en) 956, die physische(n) Registerdatei(en)einheit(en) 958 und das bzw. die Ausführungscluster 960 werden als möglicherweise mehrere gezeigt, da gewisse Ausführungsformen separate Pipelines für gewisse Typen von Daten/Operationen erzeugen (z. B. eine skalare ganzzahlige Pipeline, eine skalare Gleitkomma-/gepackte ganzzahlige/gepackte Gleitkomma-/Vektorganzzahl-/Vektorgleitkomma-Pipeline und/oder eine Speicherzugriffspipeline, die jeweils ihr(e) eigene(s) Ablaufsteuerungseinheit, physische Registerdetei(en)einheit und/oder Ausführungscluster haben - und im Falle einer separaten Speicherzugriffspipeline sind gewisse Ausführungsformen umgesetzt, bei denen nur das Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 964 hat). Es versteht sich auch, dass dort, wo separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines reihenfolgeveränderte Ausgabe-/Ausführungspipelines und die restlichen reihenfolgetreue sein können.
Die Menge von Speicherzugriffseinheiten 964 ist mit der Speichereinheit 970 gekoppelt, die eine Daten-TLB-Einheit 972 umfasst, gekoppelt mit einer Datencacheeinheit 974, gekoppelt mit einer Level-2-Cacheeinheit (L2) 976. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 964 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit umfassen, die jeweils mit der Daten-TLB-Einheit 972 in der Speichereinheit 970 gekoppelt sind. Die Befehlscacheeinheit 934 ist ferner mit einer Level-2-Cacheeinheit (L2) 976 in der Speichereinheit 970 gekoppelt. Die L2-Cacheeinheit 976 ist mit einem oder mehreren anderen Cacheebenen und eventuell mit dem Hauptspeicher gekoppelt.
Als Beispiel kann die beispielhafte, Register umbenennende reihenfolgeveränderte Ausgabe-/Ausführungskernarchitektur die Pipeline 900 wie folgt umsetzen: 1) der Befehlsabruf 938 führt die Abruf- und die Längendecodierstufen 902 und 904 durch; 2) die Decodiereinheit 940 führt die Decodierstufe 906 durch; 3) die Umbenennungs-/Zuordnungseinheit 952 führt die Zuordnungsstufe 908 und die Umbenennungsstufe 910 durch; 4) die Ablaufsteuerungseinheit(en) 956 führt bzw. führen die Ablaufsteuerungsstufe 912 durch; 5) die physische(n) Registerdatei(en)einheit(en) 958 und die Speichereinheit 970 führen die Registerlese-/Speicherlesestufe 914 durch; das Ausführungscluster 960 führt die Ausführungsstufe 916 durch; 6) die Speichereinheit 970 und die physische(n) Registerdatei(en)einheit(en) 958 führen die Zurückschreibe-/Speicherschreibestufe 918 durch; 7) verschiedene Einheiten können bei der Ausnahmenbehandlungsstufe 922 beteiligt sein; und 8) die Rückzugseinheit 954 und die physische(n) Registerdatei(en)einheit(en) 958 führen die Übergabestufe 924 durch.
Der Kern 990 kann einen oder mehrere Befehlssätze (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen, wie etwa NEON) von ARM Holdings aus Sunnyvale, CA) unterstützen, einschließlich der hier beschriebenen Befehle. In einer Ausführungsform umfasst der Kern 990 Logik zum Unterstützen einer Befehlssatzerweiterung mit gepackten Daten (z. B. AVX1, AVX2), dadurch ermöglichend, dass Operationen, die von vielen Multimedia-Anwendungen verwendet werden, mit gepackten Daten durchgeführt werden.
Es versteht sich, dass der Kern Multithreading (Ausführen von zwei oder mehreren parallelen Sätzen von Operationen oder Strängen) unterstützen kann, und er kann dies auf eine Vielzahl von Weisen tun, einschließlich Zeitscheiben-Multithreading, gleichzeitiges Multithreading (wobei ein einzelner physischer Kern einen logischen Kern für jeden der Stränge bereitstellt, für den der physische Kern ein gleichzeitiges Multithreading durchführt), oder eine Kombination daraus (z. B. Zeitscheibenabruf und -decodierung und gleichzeitiges Multithreading danach, wie etwa bei der Intel® Hyperthreading-Technologie).
Während Registerumbenennung im Kontext von reihenfolgeveränderter (Out-of-order) Ausführung beschrieben ist, versteht es sich, dass Registerumbenennung in einer reihenfolgetreuen (In-order) verwendet werden kann. Während die dargestellte Ausführungsform des Prozessors auch separate Befehls- und Datencacheeinheiten 934/974 und eine gemeinsam genutzte L2-Cacheeinheit 976 umfasst, können alternative Ausführungsformen einen einzelnen internen Cache für Befehle und Daten haben, wie etwa, beispielsweise, einen internen Level-1-Cache (L1) oder mehrere Ebenen von internem Cache haben. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Cache und einem externen Cache umfassen, die extern zum Kern und/oder zum Prozessor ist. Alternativ kann der gesamte Cache extern zum Kern und/oder zum Prozessor sein.
Spezifische beispielhafte reihenfolgetreue (In-order) Kernarchitektur
10A-B stellen ein Blockdiagramm einer spezifischeren beispielhaften reihenfolgetreuen (In-order) Kernarchitektur dar, deren Kern einer von mehreren Logikblöcken (einschließlich anderer Kerne vom gleichen Typ und/oder anderen Typen) in einem Chip wäre. Die Logikblöcke kommunizieren über ein Verbindungsnetzwerk mit hoher Bandbreite (z. B. ein Ringnetzwerk) mit einigen festen Funktionslogiken, Speicher-E/A-Schnittstellen und anderen notwendigen E/A-Logiken, in Abhängigkeit von der Anwendung.
10A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung zu dem On-Die-Verbindungsnetzwerk 1002 und mit seinem lokalen Teilsatz des Level-2-Caches (L2) 1004, gemäß Ausführungsformen der Offenbarung. In einer Ausführungsform unterstützt eine Befehlsdecodiereinheit 1000 den x86-Befehlssatz mit einer Befehlssatzerweiterung mit gepackten Daten. Ein L1-Cache 1006 ermöglicht Zugriffe mit niedriger Latenz auf Cachespeicher in skalare und Vektoreinheiten. Während in einer Ausführungsform (zum Vereinfachen der Konzeption) eine skalare Einheit 1008 und eine Vektoreinheit 1010 separate Registersätze verwenden (skalare Register 1012 bzw. Vektorregister 1014) und Daten, die zwischen ihnen transferiert werden, in Speicher geschrieben und dann von einem Level-1-Cache (L1) 1006 zurückgelesen werden, können alternative Ausführungsformen der Offenbarung einen unterschiedlichen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad umfassen, der Daten ermöglicht, zwischen den zwei Registerdateien transferiert zu werden, ohne geschrieben und zurückgelesen zu werden).
Der lokale Teilsatz des L2-Caches 1004 ist Teil eines globalen L2-Caches, der in separate lokale Teilsätze unterteilt wird, einen pro Prozessorkern. Jeder Prozessorkern hat einen direkten Zugriffspfad auf seinen eigenen lokalen Teilsatz des L2-Caches 1004. Daten, die von einem Prozessorkern gelesen werden, werden in seinem L2-Cacheteilsatz 1004 gespeichert, und auf diese kann schnell zugegriffen werden, parallel mit anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Cacheteilsätze zugreifen. Daten, die von einem Prozessorkern geschrieben werden, werden in dessen eigenem L2-Cacheteilsatz 1004 gespeichert und, wenn nötig, aus anderen Teilsätzen entfernt. Das Ringnetzwerk sichert Kohärenz der gemeinsam genutzten Daten. Das Ringnetzwerk ist bidirektional, um Agenten, wie etwa Prozessorkernen, L2-Caches und anderen Logikblöcken zu ermöglichen, innerhalb des Chips miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012 Bit breit.
10B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 10A gemäß Ausführungsformen der Offenbarung. 10B umfasst einen L1-Datencache 1006A als Teil des L1-Caches 1004, sowie weitere Details hinsichtlich der Vektoreinheit 1010 und der Vektorregister 1014. Insbesondere ist die Vektoreinheit 1010 eine 16-breite Vektorverarbeitungseinheit (VPU, Vector Processing Unit) (siehe die 16-breite ALU 1028), die einen oder mehrere Ganzzahlbefehle, Gleitkommabefehle mit einfacher Genauigkeit und Gleitkommabefehle mit doppelter Genauigkeit ausführt. Die VPU unterstützt Mischen der Registereingänge mit Mischeinheit 1020, numerische Umwandlung mit numerischen Umwandlungseinheiten 1022A-B und Replikation mit Replikationseinheit 1024 auf dem Speichereingang. Schreibmaskenregister 1026 ermöglichen das Prädizieren von resultierenden Vektorschreibvorgängen.
11 ist ein Blockdiagramm eines Prozessors 1100, der mehr als einen Kern haben kann, der eine integrierte Speichersteuerung haben kann und der integrierte Grafik haben kann, gemäß Ausführungsformen der Offenbarung. Die Felder mit den durchgezogenen Linien in 11 stellen einen Prozessor 1100 mit einem einzelnen Kern 1102A, einen Systemagenten 1110, eine Menge von einer oder mehreren Bussteuerungseinheiten 1116 dar, während die optionale Hinzufügung von Feldern mit gestrichelten Linien einen alternativen Prozessor 1100 mit mehreren Kernen 1102A-N, eine Menge von einem oder mehreren integrierten Speichersteuerungeinheiten 1114 in der Systemagenteneinheit 1110 und spezieller Logik 1108 darstellt.
Daher können unterschiedliche Umsetzungen des Prozessors 1100 umfassen: 1) eine CPU, wobei die spezielle Logik 1108 integrierte Grafik und/oder wissenschaftliche (Durchsatz) Logik ist (die einen oder mehrere Kerne umfassen kann), und wobei die Kerne 1102A-N ein oder mehrere universelle Kerne sind (z. B. universelle reihenfolgetreue (In-order) Kerne, universelle reihenfolgeveränderte (Out-of-order) Kerne, eine Kombination aus den zwei); 2) einen Koprozessor, wobei die Kerne 1102A-N eine große Anzahl von speziellen Kernen sind, primär für Grafik und/oder wissenschaftliches (Durchsatz) Rechnen gedacht; und 3) einen Koprozessor, wobei die Kerne 1102A-N eine große Anzahl von universellen reihenfolgetreuen (In-order) Kernen sind. Daher kann der Prozessor 1100 ein universeller Prozessor, Koprozessor oder spezieller Prozessor sein, wie etwa, beispielsweise, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine universelle Grafikprozessor-Berechnungseinheit (GPGPU, General Purpose Graphics Processing Unit), ein Koprozessor mit hohem Durchsatz und vielen integrierten Kernen (MIC, Many Integrated Core) (30 oder mehr Kerne umfassend), ein eingebetteter Prozessor oder ähnliches. Der Prozessor kann auf einem oder mehreren Chips umgesetzt sein. Der Prozessor 1100 kann ein Teil eines und/oder kann umgesetzt sein auf einem oder mehreren Substraten unter Verwendung einer beliebigen Anzahl von Prozesstechnologien, wie etwa, beispielsweise, BiCMOS, CMOS oder NMOS.
Die Speicherhierarchie umfasst ein oder mehrere Level von Cache innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsam genutzten Cacheeinheiten 1106 und externen Speicher (nicht gezeigt), gekoppelt mit der Menge an integrierten Speichersteuerungseinheiten 1114. Die Menge an gemeinsam genutzten Cacheeinheiten 1106 kann einen oder mehrere Mid-Level-Caches, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cacheebenen, einen Cache auf der untersten Ebene (LLC, Last Level Cache) und/oder Kombinationen davon umfassen. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 1112 die integrierte Grafiklogik 1108, die Menge an gemeinsam genutzten Cacheeinheiten 1106 und die Systemagenteneinheit 1110/die integrierte(n) Speichersteuerungseinheit(en) 1114 verbinden, können alternative Ausführungsformen eine beliebige Anzahl von wohlbekannten Techniken zum Verbinden solcher Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einer oder mehreren Cacheeinheiten 1106 und Kernen 1102-A-N gewahrt.
In einigen Ausführungsformen sind einer oder mehrere der Kerne 1102A-N in der Lage, Multithreading durchzuführen. Der Systemagent 1110 umfasst diejenigen Komponenten, die Kerne 1102A-N koordinieren und betreiben. Die Systemagenteneinheit 1110 kann, beispielsweise, eine Leistungssteuerungseinheit (PCU, Power Control Unit) und eine Anzeigeeinheit umfassen. Die PCU kann Logik und Komponenten, die zum Regeln des Leistungszustands der Kerne 1102A-N und der integrierten Grafiklogik 1108 benötigt werden, sein oder umfassen. Die Anzeigeeinheit dient zum Betreiben einer oder mehrerer extern angeschlossener Anzeigen.
Die Kerne 1102A-N können homogen oder heterogen in Bezug auf den Architekturbefehlssatz sein; das heißt, zwei oder mehr der Kerne 1102A-N können zur Ausführung des gleichen Befehlssatzes in der Lage sein, während andere möglicherweise in der Lage sind, nur einen Teilsatz dieses Befehlssatzes oder einen unterschiedlichen Befehlssatz auszuführen.
Beispielhafte Computerarchitekturen
12-15 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere im Fachgebiet bekannte Systemkonzeptionen und -auslegungen für Laptops, Desktops, handgestützte PCs, persönliche digitale Assistenten, technische Workstations, Server, Netzwerkvorrichtungen, Netzwerkhubs, Weichen, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrosteuerungen, Mobiltelefone, tragbare Medienabspielvorrichtungen, handgestützte Vorrichtungen und verschiedene andere elektronische Vorrichtungen sind ebenfalls geeignet. Im Allgemeinen ist eine riesige Vielfalt von Systemen oder elektronischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder andere Ausführungslogik, wie hier offenbart, zu integrieren, allgemein geeignet.
Jetzt Bezug nehmend auf 12 ist ein Blockdiagramm eines Systems 1200 in Übereinstimmung mit einer Ausführungsform der Offenbarung gezeigt. Das System 1200 kann einen oder mehrere Prozessoren 1210, 1215 umfassen, die mit einem Steuerungshub 1220 gekoppelt sind. In einer Ausführungsform umfasst der Steuerungshub 1220 einen Grafikspeichersteuerungshub (GMCH, Graphics Memory Controller Hub) 1290 und einen Eingabe-/Ausgabe-Hub (IOH, Input/Output Hub) 1250 (die sich auf separaten Chips befinden können); der GMCH 1290 umfasst Speicher- und Grafiksteuerungen, mit denen Speicher 1240 und ein Koprozessor 1245 gekoppelt sind; der IOH 1250 koppelt Eingabe-/Ausgabevorrichtungen (E/A) 1260 mit dem GMCH 1290. Alternativ sind einer oder beide der Speicher- und Grafiksteuerungen in den Prozessor integriert (wie hier beschrieben), der Speicher 1240 und der Koprozessor 1245 sind direkt mit dem Prozessor 1210 gekoppelt, und der Steuerungshub 1220 in einem einzelnen Chip mit dem IOH 1250. Speicher 1240 kann ein Beschleunigerverwaltungsmodul 1240A umfassen, um beispielsweise Code zu speichern, der, wenn ausgeführt, einen Prozessor veranlasst, ein beliebiges Verfahren dieser Offenbarung durchzuführen.
Die optionale Natur der zusätzlichen Prozessoren 1215 wird in 12 durch unterbrochene Linien gekennzeichnet. Jeder Prozessor 1210, 1215 kann einen oder mehrere der hier beschriebenen Verarbeitungskerne umfassen und kann eine Version des Prozessors 1100 sein.
Der Speicher 1240 kann, beispielsweise, ein dynamischer Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory), ein Phasenwechselspeicher (PCM, Phase Change Memory) oder eine Kombination aus den zwei sein. In zumindest einer Ausführungsform kommuniziert der Steuerungshub 1220 mit dem bzw. den Prozessoren 1210, 1215 über einen Multi-Drop-Bus, wie etwa einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie etwa QuickPath Interconnect (QPI) oder eine ähnliche Verbindung 1295.
In einer Ausführungsform ist der Koprozessor 1245 ein spezieller Prozessor, wie etwa, beispielsweise, ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder ein Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder ähnliches. In einer Ausführungsform kann der Steuerungshub 1220 einen integrierten Grafikbeschleuniger umfassen.
Es kann eine Vielzahl von Unterschieden zwischen den physischen Ressourcen 1210, 1215 im Hinblick auf ein Spektrum von relevanten Metriken geben, einschließlich architektonisch, mikroarchitektonisch, thermisch, der Stromverbrauchscharakteristiken und ähnliches.
In einer Ausführungsform führt der Prozessor 1210 Befehle aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. Eingebettet in die Befehle können Koprozessorbefehle sein. Der Prozessor 1210 erkennt, dass diese Koprozessorbefehle von einem Typ sind, der durch den angeführten Koprozessor 1245 ausgeführt werden soll. Entsprechend gibt der Prozessor 1210 diese Koprozessorbefehle (oder Steuersignale, die Koprozessorbefehle darstellend) auf einem Koprozessorbus oder einer anderen Verbindung, an den Koprozessor 1245 aus. Ein oder mehrere Koprozessoren 1245 akzeptieren die empfangenen Koprozessorbefehle und führen sie aus.
Jetzt Bezug nehmend auf 13 ist ein Blockdiagramm eines ersten spezifischeren Systems 1300 in Übereinstimmung mit einer Ausführungsform der Offenbarung gezeigt. Wie in 13 gezeigt, ist Mehrprozessorsystem 1300 ein Punkt-zu-Punkt-Verbindungssystem und umfasst einen ersten Prozessor 1370 und einen zweiten Prozessor 1380, die über eine Punkt-zu-Punkt-Verbindung 1350 gekoppelt sind. Jeder der Prozessoren 1370 und 1380 kann eine Version des Prozessors 1100 sein. In einer Ausführungsform der Offenbarung sind Prozessoren 1370 und 1380 Prozessoren 1210 bzw. 1215, während Koprozessor 1338 Koprozessor 1245 ist. In einer anderen Ausführungsform sind Prozessoren 1370 und 1380 Prozessor 1210 bzw. Koprozessor 1245.
Prozessoren 1370 und 1380 sind als integrierte Speichersteuerungseinheiten (IMC, Integrated Memory Controller) 1372 bzw. 1382 umfassend gezeigt. Prozessor 1370 umfasst auch als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt-Schnittstellen (P-P) 1376 und 1378; in ähnlicher Weise umfasst der zweite Prozessor 1380 P-P-Schnittstellen 1386 und 1388. Prozessoren 1370, 1380 können Informationen über eine Punkt-zu-Punkt-Schnittstelle (P-P) 1350 unter Verwendung von P-P-Schnittstellenschaltungen 1378, 1388 austauschen. Wie in 13 gezeigt, koppeln IMCs 1372 und 1382 die Prozessoren mit jeweiligen Speichern, insbesondere einem Speicher 1332 und einem Speicher 1334, die Teile des lokal mit den jeweiligen Prozessoren verbundenen Hauptspeichers sein können.
Prozessoren 1370, 1380 können auch jeweils Informationen mit einem Chipsatz 1390 über individuelle P-P-Schnittstellen 1352, 1354 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1376, 1394, 1386, 1398 austauschen. Chipsatz 1390 kann optional Informationen mit dem Koprozessor 1338 über eine Hochleistungsschnittstelle 1339 austauschen. In einer Ausführungsform ist der Koprozessor 1338 ein spezieller Prozessor, wie etwa, beispielsweise, ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder ein Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder ähnliches.
Ein gemeinsam genutzter Cache (nicht gezeigt) kann in jedem Prozessor oder außerhalb beider Prozessoren enthalten sein und dennoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die lokalen Cacheinformationen jedes Prozessors oder beider Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, wenn ein Prozessor in den Modus mit niedriger Leistung versetzt wird.
Chipsatz 1390 kann mit einem ersten Bus 1316 über eine Schnittstelle 1396 gekoppelt sein. In einer Ausführungsform kann der erste Bus 1316 ein peripherer Komponentenverbindungsbus (PCI, Peripheral Component Interconnect) oder ein Bus, wie etwa ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein, obwohl der Schutzumfang der vorliegenden Offenbarung nicht so beschränkt ist.
Wie in 13 gezeigt, können verschiedene E/A-Vorrichtungen 1314 mit dem ersten Bus 1316 gekoppelt sein, zusammen mit einer Busbrücke 1318, die den ersten Bus 1316 mit einem zweiten Bus 1320 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 1315, wie etwa Koprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie etwa, z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungseinheiten (DSPs)), feldprogrammierbare Gate-Arrays oder jeder andere Prozessor, mit dem ersten Bus 1316 gekoppelt. In einer Ausführungsform kann der zweite Bus 1320 ein Bus mit niedriger Pinzahl (LPC, Low Pin Count) sein. Verschiedene Vorrichtungen können mit einem zweiten Bus 1320 gekoppelt sein, einschließlich, beispielsweise eine Tastatur und/oder eine Maus 1322, Kommunikationsvorrichtungen 1327 und eine Speichereinheit 1328, wie etwa ein Plattenlaufwerk oder eine andere Massenspeichervorrichtung, die, in einer Ausführungsform, Befehle/Code und Daten 1330 umfassen kann. Ferner kann ein Audio-E/A 1324 mit dem zweiten Bus 1320 gekoppelt sein. Es ist anzumerken, dass andere Architekturen möglich sind. Beispielsweise kann ein System anstelle der Punkt-zu-Punkt-Architektur aus 13 einen Multi-Drop-Bus oder eine andere solche Architektur umsetzen.
Jetzt Bezug nehmend auf 14 ist ein Blockdiagramm eines zweiten spezifischeren Systems 1400 in Übereinstimmung mit einer Ausführungsform der Offenbarung gezeigt. Ähnliche Elemente in 13 und 14 tragen ähnliche Bezugszeichen, und gewisse Aspekte von 13 wurden in 14 ausgelassen, um Eintrüben von anderen Aspekten aus 14 zu verhindern.
14 stellt dar, dass die Prozessoren 1370, 1380 integrierten Speicher und E/A-Steuerlogik („CL“, Control Logic) 1372 bzw. 1382 umfassen können. Daher umfasst die CL 1372, 1382 integrierte Speichersteuerungseinheiten und umfasst E/A-Steuerlogik. 14 stellt dar, dass nicht nur die Speicher 1332, 1334 mit der CL 1372, 1382 gekoppelt sind, sondern dass auch E/A-Vorrichtungen 1414 ebenfalls mit der Steuerlogik 1372, 1382 gekoppelt sind. Ältere E/A-Vorrichtungen 1415 sind mit dem Chipsatz 1390 gekoppelt.
Jetzt Bezug nehmend auf 15 ist ein Blockdiagramm eines SoC 1500 in Übereinstimmung mit einer Ausführungsform der Offenbarung gezeigt. Ähnliche Elemente in 11 tragen ähnliche Bezugszeichen. Außerdem sind Felder mit gestrichelten Linien optionale Merkmale auf weiterentwickelten SoCs. In 15 ist bzw. sind Verbindungseinheit(en) 1502 gekoppelt mit: einem Anwendungsprozessor 1510, der einen Satz von einem oder mehreren Kernen 202A-N und gemeinsam genutzte Cacheeinheit(en) 1106 umfasst; einer Systemagenteneinheit 1110; einer oder mehreren Bussteuerungseinheiten 1116; einer oder mehreren integrierten Speichersteuerungseinheiten 1114; einem Satz aus einem oder mehreren Koprozessoren 1520, der integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor umfassen kann; eine statische Direktzugriffsspeichereinheit (SRAM, Static Random Access Memory) 1530; eine Direktzugriffsspeichereinheit (DMA, Direct Memory Access) 1532; und eine Anzeigeeinheit 1540 zum Koppeln mit einer oder mehreren externen Anzeigen. In einer Ausführungsform umfasst bzw. umfassen der/die Koprozessor(en) 1520 einen speziellen Prozessor, wie etwa, beispielsweise, einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder ähnliches.
Hier offenbarte Ausführungsformen (z. B. der Mechanismen) können in Hardware, Software, Firmware oder einer Kombination aus solchen Umsetzungsansätzen umgesetzt sein. Ausführungsformen der Offenbarung können als Computerprogramm oder Programmcode, der auf programmierbaren Systemen, zumindest einen Prozessor, ein Speichersystem (einschließlich flüchtiger und nicht-flüchtiger Speicher und/oder Speicherelemente), zumindest eine Eingabevorrichtung und zumindest eine Ausgabevorrichtung umfassend, ausgeführt wird.
Programmcode, wie etwa Code 1330, dargestellt in 13, kann auf die Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen angewendet werden. Im Zusammenhang mit dieser Anmeldung umfasst ein Verarbeitungssystem jedes System, das einen Prozessor hat, wie etwa, beispielsweise, einen Digitalsignalprozessor (DSP), eine Mikrosteuerung, eine anwendungsspezifische integrierte Schaltung (ASIC, Application Specific Integrated Circuit) oder einen Mikroprozessor.
Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache umgesetzt sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch, wenn gewünscht, in Assembler- oder Maschinensprache umgesetzt sein. Tatsächlich sind die hier beschriebenen Mechanismen in ihrem Umfang nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Ein oder mehrere Aspekte von zumindest einer Ausführungsform können durch repräsentative Befehle, gespeichert auf einem maschinenlesbaren Medium, das unterschiedliche Logik innerhalb des Prozessors repräsentiert, umgesetzt sein, die, wenn von einer Maschine gelesen, die Maschine veranlassen, Logik zu erzeugen, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, auch als „IP-Kern“ bekannt, können auf einem materiellen, maschinenlesbaren Medium gespeichert und verschiedenen Kunden oder Fertigungseinrichtungen bereitgestellt werden, um in die Fertigungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich fertigen.
Solche maschinenlesbaren Speichermedien können umfassen, ohne Beschränkung, nicht-flüchtige, materielle Anordnungen von Artikeln, die durch eine Maschine gefertigt oder gebildet werden, einschließlich Speichermedien, wie etwa Festplatten, jeder andere Typ von Platte, einschließlich Floppy Disks, optische Platten, CD-Nur-Lese-Speicher (CD-ROMs, Compact Disk Read-Only Memories), wiederbeschreibbare Compact Disks (CD-RWs) und magnetooptische Platten, Halbleitervorrichtungen, wie etwa Nur-Lese-Speicher (ROMs, Read-Only Memories), Direktzugriffsspeicher (RAMs, Random Access Memories), wie etwa dynamische Direktzugriffsspeicher (DRAMs, Dynamic Random Access Memories), statische Direktzugriffsspeicher (SRAMs, Static Random Access Memories), löschbare, programmierbare Nur-Lese-Speicher (EPROMs, Erasable Programmable Read-Only Memories), Flash-Speicher, elektrisch löschbare, programmierbare Nur-Lese-Speicher (EEPROMs, Electrically Erasable Programmable Read-Only Memories), Phasenwechselspeicher (PCM, Phase Change Memory), magnetische oder optische Karten oder jeder andere Typ von zum Speichern von elektronischen Befehlen geeigneten Medien.
Entsprechend umfassen Ausführungsformen der Offenbarung auch nicht-flüchtige, materielle, maschinenlesbare Medien, Befehle enthaltend oder Konzeptionsdaten enthaltend, wie etwa Hardwarebeschreibungssprache (HDL, Hardware Description Language), die Strukturen, Schaltungen, Einrichtungen, Prozessoren und/oder Systemmerkmale, wie hier beschrieben, definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
Emulierung (einschließlich binäre Übersetzung, Code-Morphing usw.)
In einigen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl aus einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Beispielsweise kann der Befehlsumwandler einen Befehl in einen oder mehrere andere Befehle, die durch den Kern zu verarbeiten sind, übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung, einschließlich dynamischer Kompilierung), morphen, emulieren oder anderweitig umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination daraus umgesetzt sein. Der Befehlsumwandler kann auf dem Prozessor, außerhalb des Prozessors, teilweise auf dem Prozessor oder teilweise außerhalb des Prozessors sein.
16 ist ein Blockdiagramm, die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz abgesetzt darstellend, gemäß Ausführungsformen der Offenbarung. In der dargestellten Ausführungsform ist der Befehlsumwandler ein Softwarebefehlsumwandler, obwohl der Befehlsumwandler alternativ in Software, Firmware, Hardware oder verschiedenen Kombinationen daraus umgesetzt sein kann. 16 zeigt, wie ein Programm in einer höheren Sprache 1602 mit einem x86-Compiler 1604 kompiliert werden kann, um x86-Binärcode 1606 zu erzeugen, der systemintern durch einen Prozessor mit zumindest einem x86-Befehlssatzkern 1616 ausgeführt werden kann. Der Prozessor mit zumindest einem x86-Befehlssatzkern 1616 repräsentiert jeden Prozessor, der im Wesentlichen die gleichen Funktionen durchführen kann wie ein Intel-Prozessor mit zumindest einem x86-Befehlssatzkern durch kompatibles Ausführen oder anderweitiges Verarbeiten (1) eines wesentlichen Teils des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, dazu bestimmt, auf einem Intel-Prozessor mit zumindest einem x86-Befehlssatzkern ausgeführt zu werden, um im Wesentlichen das gleiche Ergebnis zu erreichen wie ein Intel-Prozessor mit zumindest einem x86-Befehlssatzkern. Der x86-Compiler 1604 repräsentiert einen Compiler, der betreibbar ist, um x86-Binärcode 1606 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Verknüpfungsverarbeitung, auf dem Prozessor mit zumindest einem x86-Befehlssatzkern 1616 ausgeführt werden kann. In ähnlicher Weise zeigt 16, wie das Programm in der höheren Sprache 1602 mit einem alternativen Befehlssatzcompiler 1608 kompiliert werden kann, um alternativen Befehlssatz-Binärcode 1610 zu erzeugen, der systemintern durch einen Prozessor ohne zumindest einen x86-Befehlssatzkern 1614 (z. B. einen Prozessor mit Kernen, die den MIPS Befehlssatz von MIPS Technologies aus Sunnyvale, CA ausführen und/oder den ARM-Befehlssatz von ARM Holdings aus Sunnyvale, CA, ausführen) ausgeführt werden kann. Der Befehlsumwandler 1612 wird verwendet, um den x86-Binärcode 1606 in Code umzuwandeln, der systemintern durch den Prozessor ohne einen x86-Befehlssatzkern 1614 ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht der gleiche wie der alternative Befehlssatz-Binärcode 1610, da ein Befehlsumwandler, der dies erreichen könnte, schwierig zu erstellen ist; allerdings erfüllt der umgewandelte Code die allgemeine Operation und besteht aus Befehlen aus dem alternativen Befehlssatz. Daher repräsentiert der Befehlsumwandler 1612 Software, Firmware, Hardware oder eine Kombination daraus, die, durch Emulierung, Simulation oder jeden anderen Prozess, einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86-Befehlssatzprozessor oder -kern hat, ermöglicht, den x86-Binärcode 1606 auszuführen.

Claims

Hardwareprozessor, der Folgendes umfasst: einen Kern zum Ausführen eines Strangs und Auslagern eines Komprimierungsstrangs und/oder eines Dekomprimierungsstrangs; und einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger zum Ausführen des Komprimierungsstrangs und/oder des Dekomprimierungsstrangs zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist.
Hardwareprozessor nach Anspruch 1, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger dazu dient, einen Index für einen letzten gültigen Eingabeeintrag des Eingabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Eingabeantworteintrag des Eingabepufferantwortdeskriptorfelds zu vergleichen und einen Index für einen letzten gültigen Ausgabeeintrag des Ausgabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Ausgabeantworteintrag des Ausgabepufferantwortdeskriptorfelds zu vergleichen, um zu bestimmen, wann der Komprimierungsstrang und/oder der Dekomprimierungsstrang auszuführen ist, um Eingabedaten zu verbrauchen, um Ausgabedaten zu erzeugen.
Hardwareprozessor nach Anspruch 1, wobei der Kern dazu dient, die mehreren Eingabepuffer zuzuordnen, die mehreren Eingabepuffer mit den Eingabedaten zu laden und die Einträge im Eingabepufferdeskriptorfeld für jeden entsprechenden Eingabepuffer zu laden.
Hardwareprozessor nach Anspruch 3, wobei der Kern dazu dient, die mehreren Ausgabepuffer für die Ausgabedaten zuzuordnen und die Einträge im Ausgabepufferdeskriptorfeld für jeden entsprechenden Ausgabepuffer zu laden.
Hardwareprozessor nach Anspruch 1, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger dazu dient, die mehreren Ausgabepuffer mit den Ausgabedaten zu laden und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Ausgabepuffer zu laden.
Hardwareprozessor nach Anspruch 5, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger dazu dient, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Eingabepuffer zu laden.
Hardwareprozessor nach einem der Ansprüche 1-6, wobei die Einträge im Eingabepufferdeskriptorfeld jeweils eine Größe der im entsprechenden Eingabepuffer gespeicherten Eingabedaten umfassen, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld jeweils eine Größe der im entsprechenden Eingabepuffer verbleibenden Eingabedaten umfassen, die Einträge im Ausgabepufferdeskriptorfeld jeweils eine Größe des entsprechenden, zum Speichern von Ausgabedaten verfügbaren Ausgabepuffers umfassen, und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld jeweils eine Größe der in dem entsprechenden Ausgabepuffer gespeicherten Ausgabedaten umfassen.
Hardwareprozessor nach Anspruch 1, wobei die Eingabedaten ein zustandsbehafteter Strom von Daten sind.
Verfahren, das Folgendes umfasst: Empfangen von einem Komprimierungsstrang und/oder einem Dekomprimierungsstrang an einem Hardwareprozessor; Auslagern des Komprimierungsstrangs und/oder des Dekomprimierungsstrangs an einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger; und Ausführen des Komprimierungsstrangs und/oder des Dekomprimierungsstrangs auf dem Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist.
Verfahren nach Anspruch 9, ferner umfassend Vergleichen eines Index für einen letzten gültigen Eingabeeintrag des Eingabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Eingabeantworteintrag des Eingabepufferantwortdeskriptorfelds und Vergleichen eines Index für einen letzten gültigen Ausgabeeintrag des Ausgabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Ausgabeantworteintrag des Ausgabepufferantwortdeskriptorfelds, um zu bestimmen, wann der Komprimierungsstrang und/oder der Dekomprimierungsstrang auszuführen ist, um Eingabedaten zu verbrauchen, um Ausgabedaten zu erzeugen.
Verfahren nach Anspruch 9, ferner umfassend Zuordnen der mehreren Eingabepuffer, Laden der mehreren Eingabepuffer mit den Eingabedaten und Laden der Einträge im Eingabepufferdeskriptorfeld für jeden entsprechenden Eingabepuffer.
Verfahren nach Anspruch 11, ferner umfassend Zuordnen der mehreren Ausgabepuffer für die Ausgabedaten und Laden der Einträge im Ausgabepufferdeskriptorfeld für jeden entsprechenden Ausgabepuffer.
Verfahren nach Anspruch 9, ferner umfassend Laden der mehreren Ausgabepuffer mit den Ausgabedaten und Laden der entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Ausgabepuffer.
Verfahren nach Anspruch 13, ferner umfassend Laden der entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Eingabepuffer.
Verfahren nach einem der Ansprüche 9-14, die Einträge im Eingabepufferdeskriptorfeld, die jeweils eine Größe der im entsprechenden Eingabepuffer gespeicherten Eingabedaten umfassen, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld, die jeweils eine Größe der im entsprechenden Eingabepuffer verbleibenden Eingabedaten umfassen, die Einträge im Ausgabepufferdeskriptorfeld, die jeweils eine Größe des entsprechenden, zum Speichern von Ausgabedaten verfügbaren Ausgabepuffers umfassen, und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld, die jeweils eine Größe der in dem entsprechenden Ausgabepuffer gespeicherten Ausgabedaten umfassen, bereitstellend.
Verfahren nach Anspruch 9, wobei die Eingabedaten ein zustandsbehafteter Strom von Daten sind.
System, das Folgendes umfasst: einen Hardwareprozessor zum Ausführen eines Strangs und Auslagern eines Komprimierungsstrangs und/oder eines Dekomprimierungsstrangs; und einen Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger zum Ausführen des Komprimierungsstrangs und/oder des Dekomprimierungsstrangs zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei der Hardwarekomprimierungs- und -dekomprimierungsbeschleuniger mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt ist.
System nach Anspruch 17, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger dazu dient, einen Index für einen letzten gültigen Eingabeeintrag des Eingabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Eingabeantworteintrag des Eingabepufferantwortdeskriptorfelds zu vergleichen und einen Index für einen letzten gültigen Ausgabeeintrag des Ausgabepufferdeskriptorfelds mit einem Index für einen letzten verbrauchten Ausgabeantworteintrag des Ausgabepufferantwortdeskriptorfelds zu vergleichen, um zu bestimmen, wann der Komprimierungsstrang und/oder der Dekomprimierungsstrang auszuführen ist, um Eingabedaten zu verbrauchen, um Ausgabedaten zu erzeugen.
System nach Anspruch 17, wobei der Hardwareprozessor dazu dient, die mehreren Eingabepuffer zuzuordnen, die mehreren Eingabepuffer mit den Eingabedaten zu laden und die Einträge im Eingabepufferdeskriptorfeld für jeden entsprechenden Eingabepuffer zu laden.
System nach Anspruch 19, wobei der Hardwareprozessor dazu dient, die mehreren Ausgabepuffer für die Ausgabedaten zuzuordnen und die Einträge im Ausgabepufferdeskriptorfeld für jeden entsprechenden Ausgabepuffer zu laden.
System nach Anspruch 17, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger dazu dient, die mehreren Ausgabepuffer mit den Ausgabedaten zu laden und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Ausgabepuffer zu laden.
System nach Anspruch 21, wobei der Hardwarekomprimierungs- und - dekomprimierungsbeschleuniger dazu dient, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld für jeden entsprechenden verbrauchten Eingabepuffer zu laden.
System nach einem der Ansprüche 17-22, wobei die Einträge im Eingabepufferdeskriptorfeld jeweils eine Größe der im entsprechenden Eingabepuffer gespeicherten Eingabedaten umfassen, die entsprechenden Antworteinträge im Eingabepufferantwortdeskriptorfeld jeweils eine Größe der im entsprechenden Eingabepuffer verbleibenden Eingabedaten umfassen, die Einträge im Ausgabepufferdeskriptorfeld jeweils eine Größe des entsprechenden, zum Speichern von Ausgabedaten verfügbaren Ausgabepuffers umfassen, und die entsprechenden Antworteinträge im Ausgabepufferantwortdeskriptorfeld jeweils eine Größe der in dem entsprechenden Ausgabepuffer gespeicherten Ausgabedaten umfassen.
System nach Anspruch 17, wobei die Eingabedaten ein zustandsbehafteter Strom von Daten sind.
Hardwareprozessor, der Folgendes umfasst: Mittel zum Ausführen eines Strangs und Auslagern eines Komprimierungsstrangs und/oder eines Dekomprimierungsstrangs; und Mittel zum Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs zum Verbrauchen von Eingabedaten und Erzeugen von Ausgabedaten, wobei die Mittel zum Ausführen des Komprimierungsstrangs und/oder Dekomprimierungsstrangs mit mehreren Eingabepuffern zum Speichern der Eingabedaten, mehreren Ausgabepuffern zum Speichern der Ausgabedaten, einem Eingabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Eingabepuffer, einem Eingabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Eingabepuffer, einem Ausgabepufferdeskriptorfeld mit einem Eintrag für jeden entsprechenden Ausgabepuffer und einem Ausgabepufferantwortdeskriptorfeld mit einem entsprechenden Antworteintrag für jeden entsprechenden Ausgabepuffer gekoppelt sind.