DE112016004359T5

DE112016004359T5 - Systeme, Verfahren und Vorrichtungen für eine Dekompression unter Verwendung von Hardware und Software

Info

Publication number: DE112016004359T5
Application number: DE112016004359.7T
Authority: DE
Inventors: Vinodh Gopal; James D. Guilford; Sean M. Gulley; Kirk S. Yap
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-09-25
Filing date: 2016-09-23
Publication date: 2018-06-07
Also published as: CN107925419A; US10135461B2; US10666288B2; TW201722088A; CN114142867A; CN107925419B; US20170093424A1; WO2017053840A1; TWI729996B; US20190173489A1

Abstract

Hier beschrieben sind Ausführungsformen von Systemen, Verfahren und Vorrichtungen für eine Dekompression unter Verwendung von Hardware und Software. Bei Hardware speichert ein Eingabepuffer eintreffende Eingabedatensätze aus einem komprimierten Strom. Mehrere Decodierer decodieren mindestens einen Eingabedatensatz aus dem Eingabepuffer, um einen Zwischendatensatz aus den decodierten Daten auszugeben, und ein Teilsatz aus den mehreren Decodierern soll einen Strom von Literalen ausgeben. Schließlich formatiert eine Umformungsschaltung einen Zwischendatensatz in einen von zwei Typen von Token.

Description

Gebiet
Die verschiedenen hier beschriebenen Ausführungsformen betreffen Dekompressionstechniken.
Hintergrund
Snappy ist ein Algorithmus in der LZ77-Familie, der bei Anwendungen wie etwa der Hadoop-Kompression, dem BTRFS-Dateisystem, bei Rechenzentrumsanwendungen wie etwa Indexdiensten weit verbreitet ist und auch in einigen Browsern aktiviert ist. In diesen Anwendungen sind Dekompressionslatenzen für die Systemleistung entscheidend.
Figurenliste
Die vorliegende Erfindung wird beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen veranschaulicht, in denen gleiche Bezugszeichen ähnliche Elemente anzeigen, und wobei:

1 eine Ausführungsform eines Systems für eine beschleunigte Dekompression darstellt.
2 eine Ausführungsform eines Systems für eine beschleunigte Dekompression darstellt.
3 eine Ausführungsform eines Hardwarebeschleunigers darstellt.
4 eine Ausführungsform eines Tokenformats und einer Tokenausgabe von dem Beschleuniger darstellt.
5 eine Ausführungsform eines Dekompressionsverfahrens darstellt.
6 ein Beispiel für Fast-Path-Code darstellt.
7 eine Ausführungsform eines heterogenen Hardware-Dekompressors darstellt.
8 eine Ausführungsform eines Fast- und Slow-Path-Tokenformats darstellt.
9 eine Ausführungsform eines Fast-Path-Verarbeitungsflusses auf einem Prozessor, der den zweiten Tokentyp unterstützt, darstellt.
10-12 Offsets und Längen, die in dem Zwischenformat für verschiedene Typen von Kompressionsalgorithmen angegeben sind, darstellen.
13 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Erfindung ist.
14A ein Blockdiagramm ist, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order Issue/Ausführungspipeline gemäß Ausführungsformen der Erfindung darstellt.
14B ein Blockdiagramm ist, das sowohl eine beispielhafte Ausführungsform eines In-Order-Architekturkerns als auch eines beispielhaften Registerumbenennungs-, Out-of-Order Issue/Ausführungsarchitekturkerns, die in einen Prozessor gemäß Ausführungsformen der Erfindung einzuschließen sind, darstellt.
15A-B ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur darstellen, deren Kern einer aus mehreren logischen Blöcken (beinhaltend andere Kerne des selben Typs und/oder unterschiedlicher Typen) auf einem Chip wäre.
16 ein Blockdiagramm eines Prozessors 1600 ist, der gemäß Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und integrierte Grafik aufweisen kann.
17-20 Blockdiagramme von beispielhaften Rechnerarchitekturen sind.
21 ein Blockdiagramm ist, das die Verwendung eines Softwarebefehlskonvertierers zum Konvertieren von binären Befehlen in einem Quellenbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt. Es versteht sich jedoch, dass Ausführungsformen der Erfindung ohne diese spezifischen Einzelheiten praktizierbar sind. Bezugnahmen in der Offenbarung auf „eine Ausführungsform“, „eine beispielhafte Ausführungsform“ usw. zeigen an, dass die beschriebene Ausführungsform ein/e bestimmte/s Funktion, Struktur oder Merkmal beinhalten kann, doch nicht jede Ausführungsform notwendigerweise die/das bestimmte Funktion, Struktur oder Merkmal beinhalten muss. Darüber hinaus beziehen sich solche Ausdrücke nicht notwendigerweise auf dieselbe Ausführungsform. Wenn ein/e bestimmte/s Funktion, Struktur oder Merkmal in Verbindung mit einer Ausführungsform beschrieben wird, ist ferner zu bedenken, dass es in der Kenntnis eines Fachmanns liegt, dass ein/e derartige/s Funktion, Struktur oder Merkmal in Verbindung mit anderen Ausführungsformen, ob sie explizit beschrieben wurden oder nicht, ebenfalls betroffen ist.
Untenstehend ausführlich beschrieben sind Ausführungsformen zum Beschleunigen einer Dekompression (z. B. von LZ77-basierten Kompressionsalgorithmen) unter Verwendung einer effizienten und neuartigen Partitionierung der Berechnungen zwischen Hardware mit fester Funktion und Software. Viele der untenstehenden Ausführungsformen erörtern den LZ77 „Snappy“-Algorithmus, doch gelten sie genauso gut für andere Kompressionstechniken in dieser Familie (z. B. LZF, LZ4), die auf (ähnlichen) Codierungsformaten basieren. Im Allgemeinen finden LZ77-Kompressionsalgorithmen wiederholte Teilzeichenketten auf und ersetzen sie mit rückwärtsgerichteten Referenzen (relative Abstands-Offsets). Die komprimierten Daten bestehen aus einer Reihe von Elementen von zwei Typen: Literalbytes und Zeiger zu replizierten Zeichenketten, wobei ein Zeiger als ein Paar <Länge, rückwärtsgerichteter Abstands-Offset> dargestellt ist.
Das Snappy-Format besteht aus Zeichen, die entweder einen Lauf von Literalbytes oder eine Referenz darstellen. Das Codieren beginnt mit einem Tag oder Steuerbyte, das Informationen zu dem Typ des Zeichens, der Länge von Literalen oder Referenzen sowie einige Bits des Abstands-Offsets enthält. Dem Tag-Byte folgen Literale oder 1 oder 2 Abstands-Offset-Bytes. In einigen (seltenen) Fällen großer History-Puffer oder sehr langer Literal-Zeichenketten sind zusätzliche Bytes vorhanden.
Der Dekompressionsvorgang besteht aus zwei Hauptschritten: 1) Parsen des Eingabestroms in Token (Literale oder LZ77-Kopien) und 2) Kopieren einer angegebenen Anzahl von Bytes in einen Ausgabestrom. Aktuelle Softwareverfahren zum Implementieren der LZ77-Dekompression sind eingeschränkt durch schlechtbedingte datenabhängige Verzweigungen, Lade-Latenzen und eine Anzahl von Befehlen, die den kritischen Pfad des Decodierens eines Zeichens beeinträchtigen. Da die Dekompression ein serieller Vorgang ist, ist der kritische Pfad in der Regel damit verbunden, wie schnell das nächste Zeichen gelöst und mit dem Verarbeiten begonnen werden kann.
In den untenstehend erörterten Ausführungsformen wird der erste obenstehende Schritt in Hardware mit fester Funktion und der zweite Schritt durch Software auf einem herkömmlichen Prozessor durchgeführt. Das Hauptaugenmerk liegt untenstehend auf einem kritischen Abschnitt der LZ77-Dekompression und teilt das Problem effizient zwischen Hardware mit fester Funktion nur für das Frontend-Parsen und Software für Datenkopien auf. Ein dazwischenliegender Tokenstrom ist definiert, der durch Beseitigen von datenabhängigen Verzweigungen von schwacher Konfidenz sehr günstig für die Softwareleistung ist, der eine kleine Anzahl von Befehlen in der kritischen Schleife aufweist und der den aktuellen kritischen Pfad der Software beseitigt, um zur nächsten Zeichendecodierung (durch Definieren von Token von fester Länge) zu gelangen.
Die Nachbearbeitungs-Softwareberechnung ist in einen schnellen („fast“) und einen langsamen („slow“) Pfad aufgeteilt und stellt sicher, dass der schnelle Pfad in herkömmlichen Kernen die höchste Geschwindigkeit erreicht. 1 stellt eine Ausführungsform eines Systems für eine beschleunigte Dekompression dar. Im Speicher 103 (entweder einem flüchtigen Speicher wie einem Direktzugriffsspeicher (random access memory - RAM) oder einem nichtflüchtigen Speicher wie einer Platte) sind ein komprimierter LZ77-Strom 105, ein unkomprimierter LZ77-Strom 107 und schneller und langsamer Verarbeitungscode 109 gespeichert. Der komprimierte Strom 105 ist eine Eingabe in den Beschleuniger 111, die eine LZ77-codierte Datei umfasst. Der unkomprimierte Strom 107 ist eine Ausgabe des Beschleunigers 111 und der Ausführungseinheiten 113. In der Regel beinhaltet dieser Strom eine Historie dessen, was bereits decodiert wurde. Code zum Verarbeiten des Stroms, um sowohl den Beschleuniger 111 als auch die Ausführungseinheiten 113 anzuleiten, ist im schnellen und langsamen Verarbeitungscode 109 gespeichert. Ein Beispiel für diesen Code wird später in 6 erörtert zu werden.
Der Beschleuniger 111 generiert Token von fester Länge (z. B. 5-Byte), die eine Kopie aus dem History-/Ausgabepuffer oder eine Kopie aus dem Eingabestrom (d. h. einen Satz von Literalen) darstellen. Gelegentlich kann der Beschleuniger 111 untenstehend als Frontend-Hardware bezeichnet werden. Der Beschleuniger 111 liest einen LZ77-Strom (komprimiert) ein und gibt einen Strom von Token (d.h., nicht beinhaltend die Literaldaten) in einem Format von fester Länge aus. Die Ausführungseinheiten 113 des Prozessorkerns 101 fungieren als ein Back-End und verwenden die Token, den ursprünglichen Strom und den Ausgabestrom (History) zum Erzeugen der decodierten Ausgabe.
2 stellt eine Ausführungsform eines Systems für eine beschleunigte Dekompression dar. In diesem Beispiel sind die Komponenten dieselben wie in der vorherigen Figur, der Beschleuniger 211 jedoch liegt außerhalb des Prozessorkerns 101.
Die Beschleunigerausgabe besteht aus einem Strom von Token von fester Länge (5-Byte). Am häufigsten generiert ein LZ77-Datensatz ein einzelnes Token. In seltenen Fällen generiert ein Datensatz zwei Token, was von einem Ausnahmefall-„Slow-Path“ im Prozessorcode bearbeitet wird. Der Tokenstrom stellt zwei Offsets bereit, die von dem Prozessorcode als Offsets mit Bezug auf ein Quell- und Ziel-Basisregister für die Speicherkopieroperationen verwendet werden. Anstatt den Code die Adressen bei jedem Schritt in der Iteration inkrementieren zu lassen, stellt der Hardware-Beschleuniger eher einen wachsenden Offset für die Basisadresse der Software bereit. An einem bestimmten Punkt, wenn der Offset zu groß wird, wird ein Aktualisierungstoken gesendet, um die Basisregister im Prozessorcode zu inkrementieren. Diese Aktualisierungsereignisse sind nicht häufig und beeinträchtigen die Leistung oder die Größe des Zwischenstroms nicht spürbar; andererseits verbessern sie die Leistung jeder Wiederholung des Codes, da es sich um eine enge/kleine Schleife handelt.
3 stellt eine Ausführungsform eines Hardware-Beschleunigers dar. Beispielsweise den Beschleuniger 111 oder 211. Im dargestellten Beispiel liegen zwei Eingabebereitstellungspuffer 301 jeweils mit einer Größe von 8 Byte vor. Diese Eingabepuffer 301 empfangen komprimierte Daten (wie etwa durch Snappy komprimierte Daten). Natürlich können auch andere Puffergrößen verwendet werden. Die Puffer 301 werden basierend auf einem Zeiger, der von einem Decodierer 305 bereitgestellt ist, verschoben.
Ein Selektor 303 wählt basierend auf einem aktuellen Zeiger in dem decodierten Strom mindestens ein Byte aus den Eingabepuffern aus. In einer Ausführungsform ist der Selektor 303 ein 8:1-Multiplexer, der bis zu 5 Bytes aus den Puffern 301 auswählt.
Die Decodierer-/Offset-ALU 305 decodiert die ausgewählten Bytes, um mehrere Datenelemente zu bestimmen einschließlich einem oder mehreren aus Folgendem: ob die decodierten Daten ein Literal, ein Zeichen sind, eine Überlappungsbedingung verursachen (wo sich der Eingabe- und der Ausgabestrom überlappen), der Größe des LZ77-Datensatzes (zu verwenden in einer Aktualisierungssynchronisierung der Quell- und Zielbasisregister), der Länge des Literals oder Zeichens, und Offsets für das Literal oder Zeichen. Der Decodierer 305 bestimmt auch einen nächsten Zeiger zum Weiterbewegen des Puffers 301 und zum Verwenden durch den Selektor 303. Die Ausgabe des Decodierers ist in einigen Ausführungsformen in einem LZ77-Datensatzregister 311 gespeichert.
Ein LZ77-zu-Token-Konvertierer 313 nimmt die Ausgabe des Decodierers 305 (und des Registers 311), um ein Token von einer festen Länge zu generieren (z. B. 5 Byte), das einige der decodierten Daten beinhaltet. Der Konvertierer 313 nimmt auch relative Quellen- und Ziel-Offsets auf, die in den Basisregistern 315 und 317 gespeichert sind, und aktualisiert sie.
Ein Ausgabetokenregister 319 speichert ein Token, bis ein Ausgabetokenakkumulator 321 bereit ist, es auszusenden.
4 stellt eine Ausführungsform eines Tokenformats und einer Tokenausgabe von dem Beschleuniger dar. 401 stellt ein Gesamtformat dar, das Felder für Quellen-Offset, Literale, Aktualisierung, Lang, Überlappung, Länge und Ziel-Offset beinhaltet. Beispielhafte Größen und Bitpositionen sind gezeigt, jedoch können verschiedene Größen oder Positionierungen verwendet werden. Zusätzlich ist das Feld für Länge („len/16“) die Länge in 16-Byte-Blöcken und in einigen Ausführungsformen ist es „floor((len-1)/16)“ da mindestens ein Block vorhanden sein sollte (außer auf dem langsamen Pfad).
Die Ziel-/Ausgabeadresse ist als ein Zieloffset (destination offset - „dst_offset“) von einem Basiszeiger (wobei der Basiszeiger periodisch mit „Aktualisierungs“-Datensätzen aktualisiert wird) angegeben. Das bedeutet, dass, anders als im Fall, in dem die Ausgabe einer Kopie die Eingabe für die Kopie des nächsten Datensatzes bildet, keine Abhängigkeiten zwischen Iterationen bestehen.
In den meisten Ausführungsformen ist die Länge von zu kopierenden Elementen auf 16-Bytes aufgerundet bereitgestellt. Dies ermöglicht ein schnelles einfaches Kopieren in Prozessorcode an Stelle eines langsamen Byte-für-Byte-Kopierens. Jedoch können in LZ77 überlappende Kopien aus einer Entfernung auftreten, die zu nahe am aktuellen Zeiger ist, was ein langsameres Kopieren erfordert. Der Beschleuniger detektiert diese Fälle und setzt den „Überlappungs“-Bit-Parameter. Die Länge für Literale in der Codierung von LZ77 (wie etwa Snappy) kann bis zu 2³² (4 GB) sein, aber am häufigsten wird sie <61 Byte sein. Die Länge für Zeichen ist auf 64 (d. h. <=64) begrenzt, doch die Entfernung zurück kann so groß sein wie das History-Fenster.
Im dargestellten Beispiel sind alle Kopien als Vielfache von 16 Byte ausgedrückt, jedoch kann in einigen Ausführungsformen eine andere Größe verwendet werden. Die Zieladresse schreitet nur voran durch die Länge des Referenz-/Literal-Laufs, doch es ist in der Regel effizient, größere Abschnitte von fester Länge zu kopieren, da dies schneller ist als variable Byte-für-Byte-Kopien.
Der Quellen-Offset (source offset - „src_offset“) ist ein Vorzeichenwert. Bei einem Literal ist er normalerweise ein positiver Wert (bezüglich eines Adressregisters, das zum ursprünglichen Eingabestrom zeigt). Bei einem Zeichen würde er anfänglich ein negativer Wert bezüglich des Ausgabezeigers sein (d. h. ein Adressregister, das zum Ausgabestrom zeigt), doch während die Ausgabe geschrieben wird (ohne Ändern des Ausgabezeigers), könnte er zu einem positiven Wert werden.
Aktualisierung zeigt an, dass die Eingabe- und Ausgabeadresse durch ein Delta zu aktualisieren sind, dieses synchronisiert die Quellen- und Datenzeiger und ist in der Regel eine große Menge, die hinzuzufügen ist. Literal zeigt an, dass das, was verarbeitet wird, ein Literal oder ein Zeichen ist. Lang zeigt an, ob große, unkomprimierbare Daten vorliegen, die selten sein sollten und den langsamen Pfad erfordern.
403 stellt ein Beispiel eines Tokens für ein Zeichen dar, wobei der Quellen-Offset sich auf die Ausgabeadresse bezieht. Das bedeutet, das Zeichen mit Bezug auf den Ausgabezeiger zu kopieren.
405 stellt ein Beispiel eines Tokens für ein Zeichen dar, wobei der Quellen-Offset sich auf die Ausgabeadresse bezieht, wobei die Kopieausgabe die Eingabe überlappt.
407 stellt ein Beispiel eines Tokens für ein Literal dar, wobei der Quellen-Offset sich auf die Eingabeadresse des ursprünglich komprimierten Strompuffers bezieht. Das bedeutet, das Literal von dem Puffer zu kopieren.
409 stellt ein Beispiel dar, wobei eine Aktualisierung der Quellen- und Ziel-Offsets vorzunehmen ist und das Delta dieser Aktualisierungen.
411 stellt ein Beispiel eines Tokens dar, das ein langes Literal anzeigt, wobei die Länge der Literal-Zeichenkette sehr groß ist. Hier bestehen zwei Probleme. Das erste besteht darin, dass die Länge/16 7 Bits überzieht, sodass ein Feld von größerer Länge benötigt wird (eine unkomprimierbare Datenmenge). Zu Beginn der Kopieroperation sind die Offset-Felder (gemeinsam mit ihren zugehörigen Basisregistern) von angemessener Größe. Das zweite Problem besteht darin, dass nach einer Kopieroperation der Ausgabezeiger in einer „großen“ Menge vorangeschritten ist (d. h. einer Menge, die bedeutend größer sein könnte als das, was durch einen normalen „Aktualisierungsvorgang“ inkrementiert werden kann). Ebenso wird der Basiszeiger in den ursprünglichen Eingabestrom auch in einer „großen“ Menge vorangeschritten sein. Um dem zu begegnen, gibt es einen großen Wert, der zu beiden dieser Basiszeiger zu addieren ist, nachdem die Kopieroperation (eine indirekte große Aktualisierung) beendet.
In dem Fall des langen Literals ist die Größe gegeben (nicht die Größe/16). Dies bestimmt die zu kopierende Datenmenge und ist auch der Wert, der den Eingabe- und Ausgabebasisregistern hinzuzufügen ist. In einigen Ausführungsformen weist einen 17-Bit-Eingabe-Offset und ein Feld von 8 Bit Länge auf. In einigen Ausführungsformen ist die feste Länge der Token auf 8 Byte definiert.
413 zeigt ein langes Zeichen an, wobei der Quellen-Offset, sogar nach einer Aktualisierung, nicht in der Breite des Feldes ausgedrückt werden kann.
5 stellt eine Ausführungsform eines Dekompressionsverfahrens dar. Dieses Verfahren arbeitet in Verbindung mit dem obenstehend beschriebenen Beschleuniger und konsumiert die Ausgabe jenes Beschleunigers.
Bei 501 wird ein Datensatz aus einem decodierten Strom geladen. Ein Datensatz wird beispielsweise aus einem LZ77-Strom wie etwa einem Snappy-Strom geladen. Eine erste Anzahl von Bytes wird dem geladenen Datensatzzeiger für den decodierten Strom bei 503 hinzugefügt. Es werden beispielsweise dem Zeiger des geladenen Datensatzes 5 Bytes hinzugefügt. Diese Schritte gestatten, dass ein Datensatz aus einem decodierten Strom geladen werden kann.
Bei 505 wird ein Vorzeichenwert für einen Quellen-Offset erzeugt.
Eine Bestimmung dessen, ob ein langsamer Pfad (nicht unter Verwendung des Hardware-Beschleunigers) zu verwenden ist, wird bei 507 vorgenommen. Diese Bestimmung verwendet eine Tokenausgabe von dem Hardware-Beschleuniger, um zu bestimmen, ob eine Bedingung existiert, welche die effiziente Verwendung des Hardware-Beschleunigers nicht gestattet. Es liegt beispielsweise eine Lang-, Aktualisierungs- oder Überlappungsbedingung vor. In diesem Fall wird dann der langsame Pfad bei 509 verwendet, doch dies sollte einen seltenen Vorfall darstellen.
Falls keine derartige Bedingung vorliegt, wird bei 511 eine Bestimmung vorgenommen, ob die decodierten Daten ein Literal sind. Diese Informationen kommen von dem Token, das von dem Hardware-Beschleuniger zugeführt wurde. Wenn sie ein Literal bilden, dann verwendet der Quellenzeiger bei 513 für die Daten einen Basisregisterspeicher als Basiszeiger, der dem komprimierten (ursprünglichen) Strom zugehörig ist. Der Basiszeiger wird dem Vorzeichen-Quellen-Offset hinzugefügt, um eine Ladeadresse zu erzeugen. Wenn sie kein Literal bilden, dann ist der Quellenzeiger der Basiszeiger, welcher der dekomprimierten Ausgabe zugehörig ist plus dem Vorzeichen-Quellen-Offset in den dekomprimierten (Ausgabe-) Strom bei 515. Es ist zu beachten, dass diese Basisregister entweder in dem Beschleuniger oder dem Prozessorkern vorhanden sind.
Bei 517 werden die Daten aus dem dekomprimierten oder komprimierten Strom geladen, basierend auf dem Quellenzeiger bei 517. Die geladenen Daten werden bei 519 als ein Abschnitt, z. B. 16 Bytes, gespeichert. Dieses Verfahren wiederholt sich, bis der komprimierte Strom verarbeitet ist.
6 stellt ein Beispiel für Fast-Path-Code dar. Die Schleife wird für jedes Zeichen ausgeführt. Die ersten beiden Befehle (mov und add) laden einen Datensatz aus einem decodierten Strom. Die nächsten drei Befehle stellen einen Vorzeichenwert für den Quellen-Offset bereit. Die nächsten zwei Befehle testen auf die in den Token beinhalteten Bedingungen. Falls Probleme vorliegen, die verhindern, dass der schnelle Pfad wirksam ist (Lang, Aktualisieren oder Überlappen auf 1 gesetzt), dann wird zum langsamen Pfad gesprungen. Die nächsten drei Befehle (mov, test und cmovnz) schalten gegebenenfalls den Quellenzeiger. Vmovdqu ist ein Ladebefehl, und die bis zum Ende der Schleife folgenden Befehle werden zum Speichern einer 16-Byte-Kopie verwendet.
Heterogene Dekompressionsverarbeitung
Obenstehend ausgeführt ist ein Frontend, das Token von fester Länge (5-Byte) generiert, die Folgendes darstellen: Kopiere N Bytes aus dem History-/Ausgabe-Puffer und Kopiere N Bytes aus dem Eingabestrom (d. h. einen Satz von Literalen). Dies ermöglicht dem Prozessorcode, verzweigungsfrei zu sein und einfach einen Verschiebebefehl zum Laden eines Quellenzeigers für die Kopie zu verwenden.
Dies ist bedauerlicherweise nicht immer für alle Kompressionsalgorithmen ideal. Bei einem Byte-orientierten Format, beispielsweise, welches keinen Satz von Literalen codiert, sondern nur ein einzelnes Literal-Byte für jede Position codiert, an der keine Übereinstimmung gefunden wurde, kann dies weniger als ideal sein. Während das einfache feste 5-Byte-Token ein einzelnes Literal darstellen könnte, würde 1 Token pro Literal generiert werden, was ein starkes Aufblähen in einem Zwischen-Tokenstrom und eine entsprechende Zunahme der Nachverarbeitungslaufzeit auf dem Prozessor verursachen würde. Zusätzlich könnten jegliche Bit-orientierten Formate wie etwa Deflate oder LZS, wobei das Literal nicht auf einer Bytegrenze liegt, sondern eher ein Satz von n-Bits, der bei einem beliebigen Bit-Offset in einem Byte startet (und somit Bytes spreizen könnte), ein Problem darstellen. Das Bit-orientierte Format ist wiederum sogar noch problematischer, wenn die Bits, die zusammenhängende Literale darstellen, in dem Bitstrom verteilt sind. Es ist auch zu beachten, dass bei Deflate die Literale Huffman-codiert und somit nicht sichtbar sind.
Untenstehend ausführlich beschrieben sind Ausführungsformen von Systemen, Vorrichtungen und Verfahren, um diese anderen Formate zu bearbeiten. Ein sekundärer Ausgabestrom wird durch den Hardware-Dekompressor zusätzlich zum Token-Strom generiert. Im Wesentlichen parst die Hardware auch die möglicherweise als Bits codierten Literale an beliebigen Positionen in dem komprimierten Bitstrom aus und schreibt die Literal-Bytes als einen kontinuierlichen Literal-Strom aus.
Die Hardwareausgaben werden auf exakt dieselbe Weise definiert, ungeachtet des Formats, das sie dekomprimieren. Das Token-Strom-Format ist identisch, und Deflate würde lediglich einen zusätzlichen Literal-Byte-Strom generiert haben (wobei dies bei Snappy nicht der Fall wäre).
Zusätzlich zu dem obenstehend ausführlich dargestellten Format ist ein zweites Format aus der Dekompressionshardware an den Prozessor definiert, das für einige SIMD-fähige Prozessoren optimiert ist. Während das obenstehend definierte Format nur einfache ganzzahlige Befehle mit guter Leistung erforderte, können leistungsstärkere Prozessoren eine größere Beschleunigung mit einem anderen Format erhalten.
7 stellt eine Ausführungsform einer heterogenen Hardware-Dekompressionsvorrichtung dar. Diese Dekompressionsvorrichtung kann als Beschleuniger verwendet werden wie etwa diejenigen aus 1 und 2. Der Eingabepuffer 701 empfängt komprimierte Datenströme zum Weitergeben an einen oder mehrere Decodierer (Decodierer 0 703, Decodierer 1705 und Decodierer N 707). Diese Decodierer (oder Parser) nehmen diesen Eingabedatenstrom und generieren Zwischendatensätze (oder Token) und/oder Literalströme.
Snappy- und LZ4-Decodierer (Decodierer N 707) generieren nur eine einzige Ausgabe (Zwischendatensätze, welche dann verarbeitet werden, um den Token-Strom auszubilden), wobei Decodierer für Deflate (Decodierer 703) und LZS (Decodierer 705) eine zusätzliche Ausgabe aufweisen (den Byte-ausgerichteten Literal-Strom).
Diese Frontend-Decodierer verarbeiten Eingabedatensätze aus den komprimierten Strömen und wandeln sie in Zwischendatensätze um, welche dann in einen endgültigen Token-Strom umformatiert werden. Basierend auf einer gewünschten Konfigurierung kann einer aus zwei verschiedenen Typen von Tokenausgaben für einige SIMD-fähige Prozessoren generiert werden. Abhängig von dem spezifischen Dekompressionsalgorithmus kann ein Eingabedatensatz einen einzelnen oder mehrere Ausgabetoken generieren.
Die Dekompressionsvorrichtungen erzeugen jeweils einen Zwischendatensatz, der in eine Anzahl endgültiger Ausgabeformate umformatiert wird (z. B. bei einigen Ausführungsformen zwei, wie hier ausgeführt). Der Zwischendatensatz überträgt entweder Informationen über einen Satz von Literal-Bytes oder eine Referenz. Ein Eingabedatensatz kann genau einen Zwischendatensatz ergeben (normale Operation beim Decodieren von beispielsweise Snappy). Jedoch kann ein Eingabedatensatz eine Anzahl von Zwischendatensätzen generieren (z. B. einen sehr großen gespeicherten Block von Literalen im Snappy-Format). Ebenso kann, zur Effizienz des Decodierens von Formaten wie etwa Deflate, da jedes Literal einen Eingabedatensatz darstellt, ein Decodierer einen Satz von diesen bündeln, um einen einzelnen Zwischendatensatz (für N Literale) zu erzeugen. Der Zwischendatensatz enthält üblicherweise Informationen wie etwa den Beginn/das Ende des aktuellen Datensatzes im Eingabestrom, ob der Eingabestrom oder ein spezieller Literal-Strom zum Extrahieren von Literalen bei Software verwendet werden soll usw., sodass die Dekompressions-Hardware erfahren kann, wie der Eingabestrom vorankommt, der Literal-Strom vorankommt und der Ausgabestrom vorankommt. Und in allen Fällen werden Referenzen durch Länge-/Abstand-Offsets dargestellt.
Die in dem Zwischenformat angegebenen Offsets und Längen für verschiedene Typen von Kompressionsalgorithmen sind in den 10-12 abgebildet. 10 zeigt einen Byte-ausgerichteten einzelnen Datensatz wie bei Snappy oder LZF auftretend. Jeder „Eingabedatensatz“ enthält genau einen Datensatz, entweder eines Literals oder einer Rückbezugsreferenz. Ebenfalls sind die Literal-Bytes in dem komprimierten Strom in einer Byte-ausgerichteten Position schnell verfügbar. 11 zeigt einen einzelnen Datensatz für einen eigenständigen Literal-Strom wie auftretend bei LZS, LZSS und DEFLATE. Jeder „Eingabedatensatz“ enthält genau einen Datensatz, entweder eines Literals oder eines Rückbezugs. Jedoch sind die Literale nicht leicht verfügbar in einer Byte-ausgerichteten Position (z. B. LZS, LZSS) in dem komprimierten Strom und/oder die Literale sind einfach nicht verfügbar (z. B. Deflate). 12 zeigt einen Byte-ausgerichteten einzelnen Datensatz, wie etwa auftretend bei LZRW, LZ4 und LZJB. Jeder „Eingabedatensatz“ ist eine Gruppe, die mehrere Datensätze enthält, und Literal-Bytes sind in einer Byte-ausgerichteten Position in dem komprimierten Strom leicht verfügbar. In jedem der Kompressionsalgorithmen kommen die Literale aus dem komprimierten Strom.
Ein Selektor 709 wird verwendet, um zwischen Zwischendatensätzen auszuwählen, aus den Decodierern, die dann in einem Bereitstellungspuffer für Zwischendatensätze 711 gespeichert werden. Die Datensatzumformatierungsschaltanordnung 713 kombiniert Zwischendatensätze in einen einzigen Ausgabetoken. In einigen Formaten können Eingabedatensätze in Gruppen angegeben werden. Einige Algorithmen begrenzen die Länge von Literalen für jeden Datensatz, bei Deflate tatsächlich nur ein Byte. In solchen Fällen könnte der komprimierte Strom möglicherweise aufeinanderfolgende Datensätze vom Literal-Typ aufweisen. Anstatt mehrere Ausgabetoken von Ein-Byte-Literalen auszugeben, vereinigt die Umformatierungsschaltanordnung 713 die mehreren Literaldatensätze in einen Ausgabedatensatz. In einigen Ausführungsformen werden 8 aufeinanderfolgende Zwischendatensätze im Puffer 711 gepuffert, und die Datensatzumformatierungsschaltanordnung überprüft jegliche Abhängigkeit von einem Referenzdatensatz mit einem kurzen Offset, der die gepufferten Datensätze spreizt, und einen vollständigen SIMD-Token (für Fast-Path) oder einzelne Token (für Slow-Path) abgibt. Diese Token sind untenstehend ausführlich erläutert.
Der Selektor 715 wählt zwischen Literalausgaben (715) aus und legt die ausgewählten Literale dem Selektor 717 vor, der zwischen der Ausgabe der Datensatzumformatierungsschaltanordnung 713 und Literalen basierend auf der Ausgabe von einem Ausgabearbiter 719 auswählt. Ein Ausgabepuffer 721 hält ausgewählte Literale und Token zur weiteren Verarbeitung.
Wie obenstehend angedeutet wurde, gibt es in einigen Ausführungsformen zwei Ausgabe-Token-Strom-Formate. Das erste Format ist ein 40-Bit-Token fester Länge, das für eine effiziente Verarbeitung auf jedem beliebigen Prozessor konzipiert wurde, das nur einfache ganzzahlige Befehle verwendet und obenstehend ausgeführt wurde. Ein zweites Token-Strom-Format kann auch generiert werden, um sich einige SIMD-Prozessoren zunutze zu machen. In einigen Ausführungsformen wird das Formatieren des Tokens durch eine Datensatzumformatierungsschaltanordnung 713 ausgeführt.
In einigen Ausführungsformen puffert die Dekompressionsvorrichtung die jüngsten 8 Literal- oder Referenztoken und prüft, ob eine Interdependenz vorliegt. Eine Interdependenz hat eine sehr geringe Wahrscheinlichkeit, da jedes Token im Durchschnitt ca. 5 Ausgabe-Bytes generiert, und eine Dependenz innerhalb dieses Zeitraums impliziert, dass eine Referenz einen Abstands-Offset < 5*8 = 40 aufgewiesen hat. Unter Annahme, dass keine Dependenz vorliegt, kann deshalb die Verarbeitung von 8 Token zur gleichen Zeit unter Verwendung von Bahnen aus vier Worten vorgenommen werden.
Das zweite Format weist einen schnellen und einen langsamen Pfad auf (für den seltenen Fall einer Dependenz innerhalb der jüngsten 8 Token). 8 stellt eine Ausführungsform eines Tokenformats für einen schnellen und einen langsamen Pfad dar. Im Fast-Path-Format werden mehrere Längen von ungleich Null 801 bis 803 und Quellenzeiger 805 bis 807 bereitgestellt. In der Regel betragen die 8 „Längen“ jeweils eine Größe von 8-Bit und sind dargestellt durch die Bitstelle (die Länge wird im Bereich 1 bis 8 angenommen). Dies ist im Wesentlichen eine Maske, die für eine Vektor-Kompression zu verwenden ist. Anders ausgedrückt sagt die Länge, wie viele Bytes einer Dateninformation zu kopieren sind. Die 8 Viererwort(64-Bit)-Zeiger werden zum Sammeln von Viererworten verwendet und stellen die Quelladressen für die Literale oder Referenzkopien bereit.
Der langsame Pfad verwendet im ersten Byte 809 eine 0 als Fluchtsymbol (escape byte). Die Länge 811 kann bis zu 255 betragen. Eine Quellenadresse für die Kopie ist im Zeiger 813 bereitgestellt.
9 stellt eine Ausführungsform eines Fast-Path-Verarbeitungsflusses auf einem Prozessor dar, der den zweiten Tokentyp unterstützt. Insbesondere hat der Prozessor die jüngsten Literal- oder Referenztoken (wie etwa 8 Token) zu verarbeiten, die sich im zweiten Format befinden, wie in 8 gezeigt. In einigen Ausführungsformen ist eine Bestimmung dessen, ob der schnelle Verarbeitungspfad oder der langsame Pfad zu verwenden ist, zu treffen. Dies wird vorgenommen durch Prüfen des ersten Bytes eines Satzes empfangener Token im zweiten Format, um zu sehen, ob er Null beträgt. In diesem Fall wird der langsame Pfad verwendet, anderenfalls wird der schnelle Pfad verwendet, wie hier ausführlich beschrieben.
Bei 901 wird ein erstes Register mit den Längen aus dem Fast-Path-Format geladen. In einigen Ausführungsformen sind dies die ersten 8 Token, die als Längen 8 gezeigt sind. In der Regel ist dieses Register ein 64-Bit-Allzweckregister, jedoch können auch andere Registergrößen und -typen verwendet werden.
Ein zweites Register wird mit den Quellenzeigern der empfangenen Token bei 903 beladen. Wenn man sich 8 ansieht, sind diese die Zeiger 805-07. In der Regel ist das zweite Register ein 512-Bit-Register für gepackte Daten (oder Vektor-Register). Die Zeiger sind „Sammel(gather)“-Zeiger, die Adressen für Literal- oder Referenzkopien eines Eingabestroms bereitstellen.
Bei 905 werden Daten in ein drittes Register geladen, wobei die Daten am Ort des Zeigers des zweiten Registers gefunden werden. In der Regel werden 8 Bytes aus jedem Ort in ein 512-Bit-Register für gepackte Daten (oder Vektor-Register) geladen.
In einigen Ausführungsformen wird ein spezielles Schreibmaskenregister (z. B. k-mask) mit den 64 Bits aus dem ersten Register bei 907 eingestellt. Dies stellt die Masken dafür ein, was aus dem dritten Register zu ziehen ist.
Eine Kompression der Daten im dritten Register wird bei 909 unter Verwendung des ersten Registers oder des Schreibmaskenregisters als eine Maske vorgenommen. Dies dekomprimiert die Daten aus dem dritten Register aus dem, was „gut“ ist. Das Ergebnis wird in einen Ausgabezeiger bei 911 gespeichert.
In einigen Ausführungsformen wird der Ausgabezeiger auf eine Anzahl von gültigen Bits (jene, die auf 1 gestellt sind) im ersten Register eingestellt plus dem Ausgabezeigerwert aus 911. Der Ausgabezeiger wird durch die Anzahl geschriebener (durch die SIMD-Kompressionsoperation) gültiger Bits vorgeschoben. Jeder in nachfolgenden Referenzen verwendete Offset arbeitet rückwärts von dem aktualisierten Ausgabezeiger aus. Zusätzlich wird in einigen Ausführungsformen die Gruppe von Token zur Verarbeitung bei 915 in eine Warteschlange gereiht.
In Pseudo-Code lautet der Fast-Path-Fluss auf einem Prozessor gemäß einer Ausführungsform wie folgt:

Falls (token[0] !=0){
Lade ein 64-Bit-Register RK = token[7:0]
Lade ein ZMM1Register mit den nächsten 64 Bytes, die 8 Sammel-Zeiger darstellen
Sammle 8-Bytes pro Token für die 8 Token (unter Verwendung der 8 Adressen) in ZMM2 Stelle k-Register ein unter Verwendung von KMOVQ, das 64 Bits von RK verschiebt Vcompressb auf die gesammelten Daten in ZMM2 mit k-Maske oben Speichere das Ergebnis in den Ausgabezeiger (zu beachten: gleichmäßige nichtausgerichtete Speicherung, NICHT verstreuen)
Ausgabezeiger += popcnt(RK); Token += 72;
}

Das Obenstehende gestattet eine verlustlose Kompression, die in vielen verschiedenen Anwendungen verwendet wird, und viele große Einheiten (z. B. Datenbank-, Speicher- und Netzanwendungen) zeigen zunehmend Interesse am Beschleunigen von Kompression/Dekompression, da diese sehr rechenintensiv sind. Zahlreiche Massenmarktanwendungen, für die eine schnellere Dekompression, beinhalten Webserver, Eingabe-/Ausgabeoptimierung in komprimierten Dateisystemen und eine Snappy-Kompression/Dekompression in Hadoop.
In einigen Ausführungsformen kann eine genau dieselbe Softwareroutine zur Nachbearbeitung verwendet werden, um die anscheinend ungleichen Fälle eines Formats, das einen zusätzlichen Literal-Strom generiert, und eines, das dies nicht tut, zu bearbeiten. Wenn ein zusätzlicher Literal-Strom vorliegt, bildet der Zeiger des Literal-Stroms, der von der Hardware generiert wurde (wie obenstehend ausgeführt), eine Eingabe in die Softwareroutine, wobei im letzteren Fall der Software ein Zeiger zum ursprünglich komprimierten Strom zugewiesen wird. Es ist zu beachten, dass zusätzliche Ströme durch den Decodierer 0 703 und den Decodierer 1 705 (z. B. DEFLATE und LZS) erzeugt werden und in 11 gezeigt sind.
Untenstehend ausgeführt sind beispielhafte Kernarchitekturen, Prozessoren und Architekturen, welche die obenstehend beschriebenen Ausführungsformen verwenden können.
Schreibmaskenregister 1315 - in der dargestellten Ausführungsform liegen 8 Schreibmaskenregister (k0 bis k7) mit jeweils einer Größe von 64 Bit vor. In einer alternativen Ausführungsform liegen die Schreibmaskenregister 1315 in einer Größe von 16 Bit vor. Wie zuvor beschrieben, kann in einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als eine Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 anzeigt, für eine Schreibmaske verwendet wird, wählt sie eine festverdrahtete Schreibmaske aus 0xFFFF aus, wodurch effektiv die Schreibmaskierung für diesen Befehl deaktiviert wird.
Allzweckregister 1325 - in der dargestellten Ausführungsform liegen sechzehn 64-Bit-Allzweckregister vor, die gemeinsam mit den existierenden x86-Adressierungsmodi zum Adressieren von Speicheroperanden verwendet werden. Diese Register werden durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 referenziert.
Skalare Fließkomma-Stack-Registerdatei (x87-Stack) 1345, auf der die MMX-gepackte ganzzahlige Flachregisterdatei 1350 einen Aliasnamen hat - in der dargestellten Ausführungsform ist der x87-Stack ein Acht-Element-Stack, der verwendet wird, um skalare Fließkommaoperationen an 32/64/80-Bit Fließkommadaten unter Verwendung der x87-Befehlssatzerweiterung auszuführen; während die MMX-Register verwendet werden, um Operationen an 64-Bit gepackten ganzzahligen Daten durchzuführen sowie um Operanden für einige zwischen den MMX- und XMM-Registern ausgeführten Operationen zu halten.
Alternative Ausführungsformen der Erfindung können breitere oder schmalere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
Prozessorkerne können auf verschiedene Weisen, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Implementierungen solcher Kerne können beispielsweise Folgendes beinhalten: 1) einen Allzweck-In-Order-Kern, bestimmt für Allzweck-Berechnungen; 2) einen Hochleistungs-Allzweck-Out-of-Order-Kern, bestimmt für Allzweck-Berechnungen; 3) einen Spezialzweckkern, hauptsächlich bestimmt für Grafik und/oder wissenschaftliche (Durchsatz-) Berechnungen. Implementierungen verschiedener Prozessoren können Folgendes beinhalten: 1) eine CPU, beinhaltend einen oder mehrere Allzweck-In-Order-Kerne, bestimmt für Allzweck-Berechnungen, und/oder einen oder mehrere Allzweck-Out-of-Order-Kerne, bestimmt für Allzweck-Berechnungen; und 2) einen Co-Prozessor, beinhaltend einen oder mehrere Spezialzweckkerne, hauptsächlich bestimmt für Grafik und/oder wissenschaftlichen (Durchsatz). Derartige verschiedene Prozessoren führen zu verschiedenen Computersystemarchitekturen, die Folgendes beinhalten können: 1) den Co-Prozessor auf einem separaten Chip von der CPU; 2) den Co-Prozessor auf einem separaten Die in demselben Paket wie eine CPU; 3) den Co-Prozessor auf demselben Die wie eine CPU (in diesem Fall wird ein solcher Co-Prozessor manchmal als Spezialzwecklogik bezeichnet wie etwa integrierte Grafik- und/oder wissenschaftliche (Durchsatz-) Logik, oder als Spezialzweckkerne); und 4) ein System auf einem Chip, das auf dem selben Chip die beschriebene CPU beinhalten kann (manchmal als Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet), den obenstehend beschriebenen Co-Prozessor und Zusatzfunktionen. Beispielhafte Kernarchitekturen werden als Nächstes beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computerarchitekturen.
Beispielhafte Kernarchitekturen In-Order- und Out-of-Order-Kern-Blockdiagramm
14A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Issue/Ausführungs-Pipeline gemäß Ausführungsformen der Erfindung darstellt. 14B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines In-Order-Architekturkerns als auch eines beispielhaften Registerumbenennungs-, Out-of-Order-Issue /Ausführungsarchitekturkerns, die in einem Prozessor gemäß Ausführungsformen der Erfindung beinhaltet werden sollen, darstellt. Die Kästen in Volllinie in 14A-B stellen die In-Order-Pipeline und den In-Order-Kern dar, während das optionale Hinzufügen der Kästen in gestrichelten Linien die Registerumbenennungs-, Out-of-Order-Issue/Ausführungspipeline und -kern darstellt. Angesichts der Tatsache, dass der In-Order-Aspekt eine Teilmenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
14A beinhaltet eine Prozessor-Pipeline 1400 eine Abrufphase 1402, eine Längendecodierphase 1404, eine Decodierphase 1406, eine Zuordnungsphase 1408, eine Umbenennungsphase 1410, eine Ablaufplanungsphase (auch bekannt als Meldungs- oder Issue-Phase) 1412, eine Registerlese-/Speicherlesephase 1414, eine Ausführungsphase 1416, eine Rückschreib-/Speicherschreibphase 1418, eine Ausnahmebearbeitungsphase 1422 und eine Festlegungsphase 1424.
14B zeigt einen Prozessorkern 1490, beinhaltend eine Frontend-Einheit 1430, die an eine Ausführungsmaschineneinheit 1450 gekoppelt ist, und beide sind an eine Speichereinheit 1470 gekoppelt. Der Kern 1490 kann ein RISC(reduced instruction set computing)-Kern, ein CISC(complex instruction set computing)-Kern, ein VLIW(very long instruction word)-Kern oder ein hybrider oder alternativer Kerntyp sein. Als noch eine andere Option kann der Kern 1490 ein Spezialzweckkern wie zum Beispiel ein Netz- oder Kommunikationskern, eine Kompressionsmaschine, ein Co-Prozessorkern, ein GPGPU(general purpose computing graphics processing unit)-Kern, ein Grafikkern oder dergleichen sein.
Die Frontend-Einheit 1430 beinhaltet eine Verzweigungsvorhersageeinheit 1432, die an eine Befehlszwischenspeichereinheit 1434 gekoppelt ist, die wiederum an einen Befehlsübersetzungspuffer (instruction translation lookaside buffer - TLB) 1436 gekoppelt ist, der an eine Befehlsabrufeinheit 1438 gekoppelt ist, die an eine Decodiereinheit 1440 gekoppelt ist. Die Decodiereinheit 1440 (oder der Decodierer) kann Befehle decodieren und als Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Eingangspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale ausgeben, die aus den ursprünglichen Befehlen decodiert werden oder diese auf andere Weise wiedergeben oder von ihnen abgeleitet sind. Die Decodiereinheit 1440 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele für geeignete Mechanismen beinhalten, ohne aber darauf beschränkt zu sein, Verweistabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (PLA), Mikrocode-Nur-Lese-Speicher(ROM) usw. In einer Ausführungsform beinhaltet der Kern 1490 einen Mikrocode-ROM oder ein anderes Medium, das einen Mikrocode für bestimmte Makrobefehle speichert (z. B. in der Decodiereinheit 1440 oder anderweitig innerhalb der Frontend-Einheit 1430). Die Decodiereinheit 1440 ist an eine Umbenennungs-/Zuordnungseinheit 1452 in der Ausführungsmaschineneinheit 1450 gekoppelt.
Die Ausführungsmaschineneinheit 1450 beinhaltet die Umbenennungs-/Zuordnungseinheit 1452, die an eine Rückordnungseinheit 1454 und einen Satz aus einer oder mehreren Ablaufplanungseinheit(en) 1456 gekoppelt ist. Die Ablaufplanungseinheit(en) 1456 stellen eine beliebige Anzahl verschiedener Ablaufplaner dar, einschließlich Reservierungsstationen, eines zentralen Befehlsfensters usw. Die Ablaufplanungseinheit(en) 1456 ist/sind an die physische(n) Registerdatei(en)-Einheit(en) 1458 gekoppelt. Jede der physischen Registerdatei(en)-Einheiten 1458 stellt eine oder mehrere physische Registerdateien dar, von denen unterschiedliche eine oder mehrere unterschiedliche Datenarten speichern, wie etwa skalare ganze Zahl, skalares Fließkomma, gepackte ganze Zahl, gepacktes Fließkomma, ganze Vektorzahl, Vektorfließkomma, 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 1458 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Allzweckregister bereitstellen. Die physische(n) Registerdatei(en)-Einheit(en) 1458 wird/werden von der Rückordnungseinheit 1454 überlappt, um verschiedene Weisen darzustellen, in denen eine Registerumbenennung und eine Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung von eines oder mehrerer Aufzeichnungspuffer und einer oder mehrerer Rückordnungsregisterdateien; unter Verwendung von einer oder mehrerer Zukunftsdateien, eines oder mehrerer History-Puffer und einer oder mehrerer Rückordnungsregisterdateien; unter Verwendung einer Registerkarte und eines Pools von Registern usw). Die Rückordnungseinheit 1454 und die physische(n) Registerdatei(en)-Einheit(en) 1458 sind an den/die Ausführungscluster 1460 gekoppelt. Der/Die Ausführungscluster 1460 beinhaltet/beinhalten einen Satz von einer oder mehrerer Ausführungseinheiten 1462 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 1464. Die Ausführungseinheiten 1462 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) an verschiedenen Datentypen (z. B. skalares Fließkomma, gepackte ganze Zahl, gepacktes Fließkomma, ganze Vektorzahl, Vektorfließkomma) ausführen. Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten beinhalten können, die für spezifische Funktionen oder Sätze von Funktionen bestimmt sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten beinhalten, die alle sämtliche Funktionen ausführen. Die Ablaufplanungseinheit(en) 1456, die physische(n) Registerdatei(en)-Einheit(en) 1458 und der/die Ausführungscluster 1460 sind in einer möglichen Vielzahl gezeigt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Typen von Daten/Operationen schaffen (z. B. eine skalare ganzzahlige Pipeline, eine skalare Fließkomma/gepackte ganze Zahl/gepackte Fließkomma/ganze Vektorzahl/Vektorfließkomma-Pipeline und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Ablaufplanungseinheit, physische Registerdatei(en)-Einheit und/oder ihren eigenen Ausführungscluster aufweisen - und im Falle einer separaten Speicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in denen nur der Ausführungscluster jener Pipeline die Speicherzugriffseinheit(en) 1464 aufweist). Es versteht sich ebenfalls, dass, wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-Order Issue/Ausführung sein können und der Rest In-Order.
Der Satz von Speicherzugriffseinheiten 1464 ist an die Speichereinheit 1470 gekoppelt, die eine Daten-TLB-Einheit 1472 beinhaltet, die an eine Datenzwischenspeichereinheit 1474 gekoppelt ist, die an eine Stufe-2(L2)-Zwischenspeichereinheit 1476 gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 1464 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit beinhalten, von denen jede an die Daten-TLB-Einheit 1472 in der Speichereinheit 1470 gekoppelt ist. Die Befehlszwischenspeichereinheit 1434 ist ferner an eine Stufe-2(L2)-Zwischenspeichereinheit 1476 in der Speichereinheit 1470 gekoppelt. Die L2-Zwischenspeichereinheit 1476 ist an eine oder mehrere andere Stufen eines Zwischenspeichers und schließlich an einen Hauptspeicher gekoppelt.
Als Beispiel kann die beispielhafte Registerumbenennungs-, Out-of-Order Issue/Ausführungs-Kernarchitektur die Pipeline 1400 wie folgt implementieren: 1) der Befehlsabruf 1438 führt die Abruf- und Längendecodierphasen 1402 und 1404 aus; 2) die Decodiereinheit 1440 führt die Decodierphase 1406 aus; 3) die Umbenennungs-/Zuordnungseinheit 1452 führt die Zuordnungsphase 1408 und die Umbenennungsphase 1410 aus; 4) die Ablaufplanungseinheit(en) 1456 führt/führen die Ablaufplanungsphase 1412 aus; 5) die physische(n) Registerdatei(en)-Einheit(en) 1458 und die Speichereinheit 1470 führen die Registerlese-/Speicherlesephase 1414 aus; der Ausführungscluster 1460 führt die Ausführungsphase 1416 aus; 6) die Speichereinheit 1470 und die physische(n) Registerdatei(en)-Einheit(en) 1458 führen die Rückschreib-/Speicherschreibphase 1418 aus; 7) verschiedene Einheiten können an der Ausnahmebearbeitungsphase 1422 beteiligt sein; und 8) die Rückordnungseinheit 1454 und die physische(n) Registerdatei(en)-Einheit(en) 1458 führen die Festlegungsphase 1424 aus.
Der Kern 1490 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, Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie etwa NEON) von ARM Holdings, Sunnyvale, CA) einschließlich des/der hier beschriebenen Befehls/Befehle unterstützen. In einer Ausführungsform beinhaltet der Kern 1490 eine Logik zum Unterstützen einer Gepackte-Daten-Befehlssatzerweiterung (z. B. AVX1, AVX2), wodurch die Operationen, die von vielen Multimedia-Anwendungen verwendet werden, mit gepackten Daten ausgeführt werden können.
Es versteht sich, dass der Kern ein Multithreading (eine Mehrsträngigkeit) (Ausführen von zwei oder mehreren parallelen Sätzen von Operationen oder Bearbeitungssträngen (Threads)) unterstützen kann und dies auf verschiedene Weisen tun kann, einschließlich Zeitintervall-Multithreading, gleichzeitiges Multithreading (wobei ein einzelner physischer Kern einen logischen Kern für jeden der Bearbeitungsstränge bereitstellt, bei welchen der physische Kern gleichzeitig ein Multithreading ausführt) oder einer Kombination davon (z. B. ein Abrufen in Zeitintervallen und Decodieren und anschließendes gleichzeitiges Multithreading danach wie etwa bei der Intel^® Hyperthreading Technologie).
Während eine Registerumbenennung im Zusammenhang mit einer Out-of-Order-Ausführung beschrieben ist, versteht es sich, dass die Registerumbenennung in einer In-Order-Architektur verwendet werden kann. Während die dargestellte Ausführungsform des Prozessors auch separate Befehls- und Datenzwischenspeichereinheiten 1434/1474 und eine gemeinsame L2-Zwischenspeichereinheit 1476 beinhaltet, können alternative Ausführungsformen einen einzelnen internen Zwischenspeicher sowohl für Befehle als auch Daten aufweisen wie zum Beispiel einen Stufe-1(L1)-internen Zwischenspeicher oder mehrere Stufen eines internen Zwischenspeichers. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Zwischenspeicher und einem externen Zwischenspeicher, der extern zum Kern und/oder zum Prozessor liegt, beinhalten. Alternativ dazu kann der gesamte Zwischenspeicher extern zum Kern und/oder zum Prozessor liegen.
Spezifische beispielhafte In-Order-Kernarchitektur
15A-B stellen ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur dar, bei deren Kern es sich um einen von mehreren logischen Blöcken (einschließlich anderer Kerne desselben Typs und/oder verschiedener Typen) in einem Chip handelt. Die logischen Blöcke kommunizieren durch ein Hoch-Bandbreitenverbindungsnetz (z. B. ein Ringnetz) mit einer gewissen festgelegten Funktionslogik, Speicher-I/O-Schnittstellen und anderer notwendiger I/O-Logik, abhängig von der Anwendung.
15A ist ein Blockdiagramm eines einzelnen Prozessorkerns, gemeinsam mit seiner Verbindung zum Verbindungsnetz 1502 auf dem Die und mit seinem lokalen Teilsatz des Stufe-2(L2)-Zwischenspeichers 1504 gemäß Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdecodierer 1500 den x86-Befehlssatz mit einer Gepackte-Daten-Befehlssatzerweiterung. Ein L1- Zwischenspeicher 1506 gestattet Zugriffe von geringer Latenz auf den Zwischenspeicher in den skalaren und Vektoreinheiten. Während in einer Ausführungsform (zum Vereinfachen des Designs) eine skalare Einheit 1508 und eine Vektoreinheit 1510 separate Registersätze (bzw. skalare Register 1512 und Vektorregister 1514) verwenden und zwischen ihnen übertragene Daten in den Speicher geschrieben werden und dann wieder aus einem Stufe-1(L1)-Zwischenspeicher 1506 ausgelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad beinhalten, der Daten gestattet, zwischen den zwei Registerdateien übertragen zu werden, ohne dass diese geschrieben und ausgelesen werden).
Der lokale Teilsatz des L2-Zwischenspeichers 1504 ist Teil eines globalen L2-Zwischenspeichers, der in separate lokale Teilsätze, einen pro Prozessorkern, geteilt ist. Jeder Prozessorkern weist einen direkten Zugriffspfad auf seinen eigenen lokalen Teilsatz des L2-Zwischenspeichers 1504 auf. Von einem Prozessorkern ausgelesene Daten werden in seinem L2-Zwischenspeicherteilsatz 1504 gespeichert, sodass schnell darauf zugegriffen werden kann, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Zwischenspeicherteilsätze zugreifen. Von einem Prozessorkern geschriebene Daten werden in seinem eigenen L2-Zwischenspeicherteilsatz 1504 gespeichert und, falls notwendig, aus anderen Teilsätzen gelöscht. Das Ringnetz gewährleistet eine Kohärenz gemeinsamer Daten. Das Ringnetzwerk ist zweiseitig gerichtet, so dass Agenten wie etwa Prozessorkerne, L2- Zwischenspeicher und andere logische Blöcke innerhalb des Chips miteinander kommunizieren können. Jeder Ringdatenpfad ist pro Richtung 1012-Bits breit.
15B ist eine erweiterte Ansicht eines Teils des Prozessorkerns aus 15A gemäß Ausführungsformen der Erfindung. 15B beinhaltet einen L1-Datenzwischenspeicher 1506A, Teil des L1-Zwischenspeichers 1504, sowie mehrere Einzelheiten bezüglich der Vektoreinheit 1510 und der Vektorregister 1514. Konkret ist die Vektoreinheit 1510 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 1528), die eine oder mehrere von ganzzahligen, Einzelpräzisionsfließ- und Doppelpräzisionsfließbefehlen ausführt. Die VPU unterstützt eine Umwandlung (Swizzling) der Registereingaben durch die Swizzling-Einheit 1520, eine numerische Konvertierung mit numerischen Konvertierungseinheiten 1522A-B und eine Replikation mit der Replikationseinheit 1524 in der Speichereingabe. Schreibmaskenregister 1526 ermöglichen eine Aussage resultierender Vektoreinträge.
Prozessor mit integrierter Speichersteuerung und Grafiken
16 ist ein Blockdiagramm eines Prozessors 1600, der gemäß Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und integrierte Grafiken aufweisen kann. Die durchgehend gezeichneten Kästen aus 16 stellen einen Prozessor 1600 mit einem einzelnen Kern 1602A, einen Systemagenten 1610, einen Satz von einer oder mehreren Bus-Steuereinheiten 1616 dar, während das optionale Hinzufügen der Kästen in gestrichelten Linien einen alternativen Prozessor 1600 mit mehreren Kernen 1602A-N, einen Satz aus einer oder mehreren integrierten Speichersteuerungseinheiten 1614 in der Systemagenteneinheit 1610 und eine Spezialzwecklogik 1608 darstellt.
Somit können verschiedene Implementierungen des Prozessors 1600 Folgendes beinhalten: 1) eine CPU mit der Spezialzwecklogik 1608, die eine integrierte Grafik- und/oder wissenschaftliche (Durchsatz)-Logik (die einen oder mehrere Kerne beinhalten kann) ist und wobei die Kerne 1602A-N ein oder mehrere Allzweckkerne sind (z. B. Allzweck-In-Order-Kerne, Allzweck-Out-of-Order-Kerne, eine Kombination der zwei); 2) einen Co-Prozessor, wobei die Kerne 1602A-N eine große Anzahl von Spezialzweckkernen sind, die vorwiegend für Grafik und/oder wissenschaftlichen (Durchsatz) bestimmt ist; und 3) einen Co-Prozessor, wobei die Kerne 1602A-N eine große Anzahl von Allzweck-In-Order-Kernen sind. Somit kann der Prozessor 1600 ein Allzweckprozessor, ein Co-Prozessor oder ein Spezialzweckprozessor wie zum Beispiel ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU (Allzweckgrafikverarbeitungseinheit), ein Co-Prozessor mit hohem Durchsatz und vielen integrierten Kernen (many integrated cores - MIC) (enthaltend 30 oder mehr Kerne), ein eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 1600 kann ein Teil einer Trägerschicht sein und/oder kann auf einer oder mehreren Trägerschichten implementiert sein unter Verwendung einer aus einer Anzahl von Prozesstechnologien wie zum Beispiel BiCMOS, CMOS oder NMOS.
Die Speicherhierarchie beinhaltet eine oder mehrere Zwischenspeicherstufen innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsamen Zwischenspeichereinheiten 1606 sowie einen externen Speicher (nicht gezeigt), der an den Satz von integrierten Speichersteuerungseinheiten 1614 gekoppelt ist. Der Satz von gemeinsamen Zwischenspeichereinheiten 1606 kann einen oder mehrere Mittelstufen-Zwischenspeicher beinhalten, wie etwa Stufe 2 (L2), Stufe 3 (L3), Stufe 4 (L4) oder andere Zwischenspeicherstufen, einen Zwischenspeicher der letzten Stufe (Last Level Cache - LLC), und/oder Kombinationen davon. Während in einer Ausführungsform eine auf Ring basierende Verbindungseinheit 1612 die integrierte Grafiklogik 1608, den Satz gemeinsamer Zwischenspeichereinheiten 1606 und die Systemagenteneinheit 1610/integrierte Speichersteuerungseinheit(en) 1614 verbindet, kann in alternativen Ausführungsformen jede Anzahl bekannter Techniken zum Verbinden solcher Einheiten verwendet werden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Zwischenspeichereinheiten 1606 und Kernen 1602-A-N aufrechterhalten.
In einigen Ausführungsformen sind einer oder mehrere der Kerne 1602A-N fähig zu einem Multithreading. Der Systemagent 1610 beinhaltet jene Komponenten, welche die Kerne 1602A-N koordinieren und betreiben. Die Systemagenteneinheit 1610 kann beispielsweise eine Leistungssteuereinheit (power control unit - PCU) und eine Anzeigeeinheit beinhalten. Die PCU kann eine Logik und Komponenten, die zum Regulieren des Leistungszustands der Kerne 1602A-N und der integrierten Grafiklogik 1608 benötigt werden, beinhalten oder dies darstellen. Die Anzeigeeinheit dient zum Antreiben einer oder mehrerer extern angeschlossener Anzeigen.
Die Kerne 1602A-N können im Sinne des Architektur-Befehlssatzes homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 1602A-N können zur Ausführung desselben Befehlssatzes fähig sein, während andere zur Ausführung nur eines Teilsatzes dieses Befehlssatzes oder eines anderen Befehlssatzes fähig sind.
Beispielhafte Rechnerarchitekturen
17-20 sind Blockdiagramme beispielhafter Rechnerarchitekturen. Andere aus dem Stand der Technik bekannte Systemdesigns und Konfigurationen für Laptops, Desktops, tragbare PCs, persönliche digitale Assistenten, Technikarbeitsplätze (engineering workstations), Server, Netzvorrichtungen, Netzknoten, Schalter, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrosteuerungen, Mobiltelefone, tragbare Media-Player, tragbare Vorrichtungen und verschiedene andere elektronische Vorrichtungen sind ebenfalls geeignet. Im Allgemeinen ist eine große Vielfalt von Systemen oder elektronischen Vorrichtungen, die zum Integrieren eines Prozessors und/oder anderer Ausführungslogik wie hier offenbart fähig sind, allgemein geeignet.
Nun Bezug nehmend auf 17 ist ein Blockdiagramm eines Systems 1700 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 1700 kann einen oder mehrere Prozessoren 1710, 1715 beinhalten, die an einen Steuerungsknoten 1720 gekoppelt sind. In einer Ausführungsform beinhaltet der Steuerungsknoten 1720 einen Grafikspeichersteuerungsknoten (graphics memory controller hub - GMCH) 1790 und einen Eingangs/Ausgangs-Knoten (Input/Output Hub - IOH) 1750 (die auf separaten Chips vorhanden sein können); wobei der GMCH 1790 Speicher- und Grafiksteuerungen beinhaltet, an die ein Speicher 1740 und ein Co-Prozessor 1745 gekoppelt sind; der IOH 1750 ist koppelt Eingangs/Ausgangs(I/O)-Vorrichtungen 1760 an den GMCH 1790. Alternativ dazu sind eine oder beide der Speicher- und Grafiksteuerungen innerhalb des Prozessors integriert (wie hier beschrieben), der Speicher 1740 und der Co-Prozessor 1745 sind direkt an den Prozessor 1710 gekoppelt und der Steuerungsknoten 1720 ist auf einem einzelnen Chip mit dem IOH 1750.
Die optionale Eigenschaft zusätzlicher Prozessoren 1715 ist in 17 mit unterbrochenen Linien dargestellt. Jeder Prozessor 1710, 1715 kann einen oder mehrere der hier beschriebenen Prozessorkerne beinhalten und eine Version des Prozessors 1600 sein.
Der Speicher 1740 kann beispielsweise ein dynamischer Direktzugriffsspeicher (dynamic random access memory - DRAM), ein Phasenänderungsspeicher (phase change memory - PCM) oder eine Kombination der zwei sein. Bei mindestens einer Ausführungsform kommuniziert der Steuerungsknoten 1720 mit dem/den Prozessor(en) 1710, 1715 über einen Multidrop-Bus wie etwa einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle wie etwa QuickPath Interconnect (QPI) oder eine ähnliche Verbindung 1795.
In einer Ausführungsform ist der Co-Prozessor 1745 ein Spezialzweckprozessor wie zum Beispiel ein Hochdurchsatz-MIC-Prozessor, ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Steuerungsknoten 1720 einen integrierten Grafikbeschleuniger beinhalten.
Es können zahlreiche Unterschiede zwischen den physischen Ressourcen 1710, 1715 im Sinne eines bewährten Metrikspektrums vorliegen, einschließlich architektonischer, mikroarchitektonischer und thermischer Eigenschaften, sowie Eigenschaften betreffend den Stromverbrauch und dergleichen vorliegen.
In einer Ausführungsform führt der Prozessor 1710 Befehle aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In diese Befehle können Co-Prozessorbefehle eingebettet sein. Der Prozessor 1710 erkennt diese Co-Prozessorbefehle als einen Typ, der von dem angefügten Co-Prozessor 1745 auszuführen sein soll. Dementsprechend gibt der Prozessor 1710 diese Co-Prozessorbefehle (oder Steuersignale, die Co-Prozessorbefehle darstellen) auf einem Co-Prozessorbus oder einer anderen Verbindung an den Co-Prozessor 1745 aus. Der/die Co-Prozessor(en) 1745 nimmt/nehmen die empfangenen Co-Prozessorbefehle an und führt/führen sie aus.
Nun Bezug nehmend auf 18 ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 1800 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 18 gezeigt, ist ein Multiprozessorsystem 1800 ein Punkt-zu-Punkt-Verbindungssystem und beinhaltet einen ersten Prozessor 1870 und einen zweiten Prozessor 1880, die über eine Punkt-zu-Punkt-Verbindung 1850 gekoppelt sind. Jeder der Prozessoren 1870 und 1880 kann eine Version des Prozessors 1600 darstellen. In einer Ausführungsform der Erfindung sind die Prozessoren 1870 und 1880 jeweils die Prozessoren 1710 und 1715, während der Co-Prozessor 1838 der Co-Prozessor 1745 ist. In einer anderen Ausführungsform sind die Prozessoren 1870 und 1880 jeweils der Prozessor 1710 und der Co-Prozessor 1745.
Die Prozessoren 1870 und 1880 sind gezeigt unter Beinhaltung integrierter Speichersteuerungs(Integrated Memory Controller - IMC)-Einheiten 1872 bzw. 1882. Der Prozessor 1870 beinhaltet auch als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 1876 und 1878; ebenso beinhaltet der zweite Prozessor 1880 P-P-Schnittstellen 1886 und 1888. Die Prozessoren 1870, 1880 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 1850 unter Verwendung von P-P-Schnittstellenschaltungen 1878, 1888 austauschen. Wie in 18 gezeigt, koppeln die IMCs 1872 und 1882 die Prozessoren an entsprechende Speicher, nämlich einen Speicher 1832 und einen Speicher 1834, die Teile eines Hauptspeichers, der lokal an die entsprechenden Prozessoren angebracht ist, sein können.
Die Prozessoren 1870, 1880 können jeweils Informationen mit einem Chipsatz 1890 über einzelne P-P-Schnittstellen 1852, 1854 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1876, 1894, 1886, 1898 austauschen. Der Chipsatz 1890 kann optional Informationen mit dem Co-Prozessor 1838 über eine Hochleistungsschnittstelle 1839 austauschen. In einer Ausführungsform ist der Co-Prozessor 1838 ein Spezialzweckprozessor wie zum Beispiel ein Hochdurchsatz-MIC-Prozessor, ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
Ein gemeinsamer Zwischenspeicher (nicht gezeigt) kann entweder in jedem Prozessor oder außerhalb beider Prozessoren beinhaltet sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die lokalen Zwischenspeicherinformationen eines oder beider Prozessoren in dem gemeinsamen Zwischenspeicher gespeichert werden können, falls ein Prozessor in einen Energiesparmodus versetzt wird.
Der Chipsatz 1890 kann über eine Schnittstelle 1896 an einen ersten Bus 1816 gekoppelt werden. In einer Ausführungsform kann der erste Bus 1816 ein Peripheral Component Interconnect(PCI)-Bus oder ein Bus wie etwa ein PCI-Expressbus oder ein anderer I/O-Verbindungsbus der dritten Generation sein, obwohl der Umfang der vorliegenden Erfindung nicht so eingeschränkt ist.
Wie in 18 gezeigt, können verschiedene I/O-Vorrichtungen 1814 an einen ersten Bus 1816 gekoppelt sein, gemeinsam mit einer Bus-Brücke 1818, die den ersten Bus 1816 an einen zweiten Bus 1820 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzlicher Prozessoren 1815 wie etwa Co-Prozessoren, Hoch-Durchsatz-MIC-Prozessoren, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungs(DSP)-Einheiten), feldprogrammierbare Gate-Arrays oder jeder andere Prozessor an den ersten Bus 1816 gekoppelt. In einer Ausführungsform kann der zweite Bus 1820 ein Low Pin Count(LPC)-Bus sein. In einer Ausführungsform können verschiedene Vorrichtungen an einen zweiten Bus 1820 gekoppelt werden, beispielsweise beinhaltend eine Tastatur und/oder eine Maus 1822, Kommunikationsvorrichtungen 1827 und eine Speicherungseinheit 1828 wie etwa ein Festplattenlaufwerk oder eine andere Massenspeicherungsvorrichtung, die Befehle/Code und Daten 1830 beinhalten können. Ferner kann ein Audio-I/O 1824 an den zweiten Bus 1820 gekoppelt sein. Es ist zu beachten, dass andere Architekturen möglich sind. Ein System kann beispielsweise an Stelle der Punkt-zu-Punkt-Architektur aus 18 einen Multidrop-Bus oder eine andere derartige Architektur implementieren.
Nun Bezug nehmend auf 19 ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 1900 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in 18 und 19 tragen gleiche Bezugszeichen und auf bestimmte Aspekte aus 18 wurde in 19 verzichtet, um eine Verschleierung anderer Aspekte aus 19 zu vermeiden.
19 stellt dar, dass die Prozessoren 1870, 1880 jeweils einen integrierten Speicher und eine I/O-Steuerlogik (control logic-„CL“) 1872 und 1882 beinhalten können. Somit beinhalten die CL 1872, 1882 integrierte Speichersteuerungseinheiten und beinhalten eine I/O-Steuerlogik. 19 stellt dar, dass nicht nur die Speicher 1832, 1834 an die CL 1872, 1882 gekoppelt sind, sondern auch, dass die I/O-Vorrichtungen 1914 an die Steuerlogik 1872, 1882 gekoppelt sind. Alt-I/O-Vorrichtungen 1915 sind an den Chipsatz 1890 gekoppelt.
Nun Bezug nehmend auf 20 ist ein Blockdiagramm eines SoC 2000 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 16 tragen gleiche Bezugszeichen. Auch sind Kästen in gestrichelten Linien optionale Funktionen auf höherentwickelten SoCs. In 20 ist/sind eine Verbindungseinheit(en) 2002 an Folgendes gekoppelt: einen Anwendungsprozessor 2010, der einen Satz aus einem oder mehreren Kernen 202A-N und einer oder mehreren gemeinsamen Zwischenspeichereinheiten 1606 beinhaltet; eine Systemagenteneinheit 1610; (eine) Bussteuerungseinheit(en) 1616; (eine) integrierte Speichersteuerungseinheit(en) 1614; einen Satz aus einem oder mehreren Co-Prozessoren 2020, die eine integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor beinhalten können; eine statische Direktzugriffspeicher(static random access memory - SRAM)-Einheit 2030; eine Direktzugriffsspeicher(direct memory access - DMA)-Einheit 2032; und eine Anzeigeeinheit 2040 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform beinhaltet/beinhalten der/die Co-Prozessor(en) 2020 einen Spezialzweckprozessor wie zum Beispiel einen Netz- und Kommunikationsprozessor, eine Kompressionsmaschine, eine GPGPU, einen Hoch-Durchsatz-MIC-Prozessor, einen eingebetteten Prozessor oder dergleichen.
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination derartiger Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert sein, die auf programmierbaren Systemen laufen umfassend mindestens einen Prozessor, ein Speichersystem (beinhaltend flüchtige und nichtflüchtige Speicher- und/oder Speicherungselemente), mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung.
Ein Programmcode wie etwa in 18 dargestellter Code 1830 kann auf Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen auszuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen angewendet werden. Zum Zwecke dieser Anmeldung beinhaltet ein Verarbeitungssystem jedes System, das einen Prozessor aufweist, wie zum Beispiel: einen Digitalsignalprozessor (DSP), eine Mikrosteuerung, eine anwendungsspezifische integrierte Schaltung (application specific integrated circuit - ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer hochwertigen prozedural- oder objektorientierten Programmsprache zum Kommunizieren mit einem Verarbeitungssystem implementiert werden. Der Programmcode kann, falls gewünscht, auch in einer Assembly- oder Maschinensprache implementiert sein. In der Tat 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 mindestens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das unterschiedliche Logik innerhalb des Prozessors darstellt, welche, wenn von einer Maschine gelesen, die Maschine veranlasst, eine Logik zu erstellen, um die darin beschriebenen Techniken auszuführen. Solche als „IP-Kerne“ bekannten Darstellungen können auf einem greifbaren, maschinenlesbaren Medium gespeichert werden und verschiedenen Kunden oder Herstellungseinrichtungen zugeführt werden, um in die Herstellungsmaschinen, die eigentlich die Logik erzeugen, oder den Prozessor geladen zu werden.
Solche maschinenlesbaren Speicherungsmedien können ohne Einschränkung nichtflüchtige, greifbare Anordnungen von durch eine Maschine oder eine Vorrichtung hergestellte oder gebildete Artikel beinhalten, einschließlich Speicherungsmedien wie etwa Festplatten, jeden anderen Typ von Platten einschließlich Disketten, optischer Platten, Kompaktplatten-Nur-Lese-Speicher (compact disk read-only memories - CD-ROMs), wiederbeschreibbarer Kompaktplatten (compact disks rewritable- CD-RWs) und magnetooptischer Platten, Halbleitervorrichtungen wie etwa Nur-Lese-Speicher (read-only memories - ROMs), Direktzugriffsspeicher (random access memories - RAMs) wie etwa dynamischer Direktzugriffsspeicher (dynamic random access memories - DRAMs), statischer Direktzugriffsspeicher (static random access memories - SRAMs), löschbarer programmierbarer Nur-Lese-Speicher (erasable programmable read-only memories - EPROMs), Flash-Speicher, elektrisch löschbarer programmierbarer Nur-Lese-Speicher (electrically erasable programmable read-only memories - EEPROMs), Phasenänderungsspeicher (phase change memory - PCM), magnetischen oder optischen Karten, oder jeden anderen Typ von Medien, der zum Speichern elektronischer Befehle geeignet ist.
Dementsprechend beinhalten Ausführungsformen der Erfindung auch nichtflüchtige, greifbare maschinenlesbare Medien, die Befehle enthalten oder die Designdaten enthalten, wie etwa HDL (Hardware Description Language), die hier beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemfunktionen definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
Emulation (beinhaltend binäre Übersetzung, Morphen von Code usw.)
In einigen Fällen kann ein Befehlskonvertierer verwendet werden, um einen Befehl aus einem Quellen-Befehlssatz in einen Ziel-Befehlssatz zu konvertieren. Der Befehlskonvertierer kann beispielsweise übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischer Übersetzung), morphen, emulieren oder anderweitig einen Befehl in einen oder mehrere andere Befehle konvertieren, um von dem Kern verarbeitet zu werden. Der Befehlskonvertierer kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlskonvertierer kann auf dem Prozessor, extern von dem Prozessor oder teilweise sowohl auf dem Prozessor und extern davon sein.
21 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlskonvertierers zum Konvertieren von binären Befehlen in einem Quellen-Befehlssatz zu binären Befehlen in einem Ziel-Befehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt. In der dargestellten Ausführungsform ist der Befehlskonvertierer ein Softwarebefehlskonvertierer, obwohl alternativ dazu der Befehlskonvertierer in Software, Firmware, Hardware oder verschiedenen Kombinationen daraus implementiert sein kann. 21 zeigt, dass ein Programm in einer höheren Sprache 2102 unter Verwendung eines x86-Compilers 2104 übersetzt werden kann, um einen x86-Binärcode 2106 zu erzeugen, der systemeigen von einem Prozessor mit mindestens einem x86-Befehlssatzkern 2116 ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Befehlssatzkern 2116 stellt jeden Prozessor dar, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern ausführen kann durch kompatibles Ausführen oder anderweitiges Verarbeiten von (1) einem wesentlichen Teil des Befehlssatzes des Intel x86-Befehlssatzkerns oder (2) Versionen von Objektcode von Anwendungen oder anderer Software, die darauf zugeschnitten ist, auf einem Intel-Prozessor mit mindestens einem x86-Befehlssatzkern zu laufen, um im Wesentlichen dasselbe Ergebnis zu erreichen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern. Der x86-Compiler 2104 stellt einen Compiler dar, der betriebsfähig ist, einen x86-Binärcode 2106 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Verknüpfungsverarbeitung auf dem Prozessor mit mindestens einem x86-Befehlssatzkern 2116 ausgeführt werden kann. Ähnlich zeigt 21, dass das Programm in der höheren Sprache 2102 unter Verwendung eines alternativen Befehlssatz-Compilers 2108 übersetzt werden kann, um alternativen Befehlssatz-Binärcode 2110 zu generieren, der systemeigen von einem Prozessor ohne mindestens einen x86-Befehlssatzkern 2114 (z. B. ein Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies, Sunnyvale, CA, ausführen und/oder die den ARM-Befehlssatz von ARM Holdings, Sunnyvale, CA, ausführen) ausgeführt werden kann. Der Befehlskonvertierer 2112 wird verwendet, um den x86-Binärcode 2106 in Code zu konvertieren, der systemeigen von dem Prozessor ohne einen x86-Befehlssatzkern 2114 ausgeführt werden kann. Dieser konvertierte Code ist wahrscheinlich nicht derselbe wie der alternative Befehlssatz-Binärcode 2110, da ein Befehlskonvertierer, der dazu in der Lage ist, schwer herzustellen ist; der konvertierte Code jedoch wird den allgemeinen Betrieb ausführen und aus Befehlen aus dem alternativen Befehlssatz bestehen. Somit stellt der Befehlskonvertierer 2112 Software, Firmware, Hardware oder eine Kombination daraus dar, die durch Emulation, Simulation oder jeden anderen Vorgang einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86-Befehlssatz-Prozessor oder -kern aufweist, erlaubt, den x86-Binärcode 2106 auszuführen.

Claims

Hardware-Dekompressionsvorrichtung, Folgendes umfassend: einen Eingabepuffer zum Speichern von eintreffenden Eingabedatensätzen aus einem komprimierten Strom; mehrere Decodierer, wobei jeder Decodierer mindestens einen Eingabedatensatz aus dem Eingabepuffer decodieren und einen Zwischendatensatz aus den decodierten Daten und einen Teilsatz aus den mehreren Decodierern zum Ausgeben eines Stroms von Literalen ausgeben soll; eine Umformatierungsschaltung zum Formatieren eines Zwischendatensatzes in einen aus mindestens zwei Typen von Token.
Hardware-Vorrichtung nach Anspruch 1, wobei ein erster aus den mehreren Decodierern gemäß dem DEFLATE-Kompressionsalgorithmus decodieren und einen Byte-ausgerichteten Literal-Strom von Literalen, die Huffman-codiert waren, ausgeben soll.
Hardware-Vorrichtung nach Anspruch 2, wobei der Zwischendatensatz mindestens eins aus einem Satz von Literalen, Informationen zu einer Anzahl von Literalen des Zwischendatensatzes und Informationen über eine Referenz beinhaltet.
Hardware-Vorrichtung nach einem der Ansprüche 1-3, wobei ein zweiter aus den mehreren Decodierern einen Zwischendatensatz pro Eingabedatensatz generieren soll.
Hardware-Vorrichtung nach einem der Ansprüche 1-4, wobei ein dritter aus den mehreren Decodierern einen einzelnen Zwischendatensatz aus mehreren Eingabedatensätzen generieren soll.
Hardware-Vorrichtung nach einem der Ansprüche 1-5, wobei ein vierter aus den mehreren Decodierern mehrere Zwischendatensätze aus einem einzelnen Eingabedatensatz generieren soll.
Hardware-Vorrichtung nach einem der Ansprüche 1-6, wobei ein gegebener Decodierer eins aus einem einzelnen Zwischendatensatz pro Eingabedatensatz, mehrere Zwischendatensätze pro Eingabedatensatz und einen einzelnen Zwischendatensatz pro mehreren Eingabedatensätzen abhängig von vom Decodierer bereitgestellten Inhalt generieren soll.
Hardware-Vorrichtung nach einem der Ansprüche 1-7, wobei die Vorrichtung extern zu einem Prozessorkern ist.
Hardware-Vorrichtung nach einem der Ansprüche 1-8, ferner Folgendes umfassend: einen Zwischendatensatz-Bereitstellungspuffer zum Puffern aufeinanderfolgender Zwischendatensätze, wobei die Umformatierungsschaltung die Token durch Prüfen nach jeglicher Dependenz von einem Referenzdatensatz mit einem Offset, welcher die gepufferten aufeinanderfolgenden Zwischendatensätze spreizt, formatieren und einen ersten Typ von Token für eine Fast-Path-Verwendung sowie einen zweiten Typ von Token für einen Slow-Path generieren soll. Puffern von acht aufeinanderfolgenden Zwischendatensätzen
Verfahren, Folgendes umfassend: Empfangen mehrerer Token für Literale oder Referenzen; Laden eines ersten Registers mit einer Maske von den Token; Laden eines zweiten Registers mit Adresszeigern von den Token; Sammeln und Speichern einer ersten Anzahl von Bytes pro Token an Orten, welche als Adresszeiger des zweiten Registers gezeigt werden, in ein drittes Register; Komprimieren der gesammelten und gespeicherten Bytes unter Verwendung der Maske; Speichern des Ergebnisses der Kompression in einen Ausgabezeiger; und Inkrementieren des Ausgabezeigers durch eine Anzahl von Bytes, die durch das Komprimieren generiert wurden.
Verfahren nach Anspruch 10, wobei die Maske aus Längen mehrerer Token für Literale oder Referenzen besteht.
Verfahren nach einem der Ansprüche 10-11, wobei die Adresszeiger 64-Bit-Werte von jedem der Token umfassen.
Verfahren nach einem der Ansprüche 10-12, ferner umfassend: Bestimmen, dass ein erstes Byte der Token nicht Null ist.
Verfahren nach einem der Ansprüche 10-13, wobei das erste Register ein 64-Bit-Allzweckregister ist.
Verfahren nach einem der Ansprüche 10-13, wobei das erste Register ein 64-Bit-Schreibmaskenregister ist.
Verfahren nach einem der Ansprüche 10-15, wobei das zweite und dritte Register 512-Bit gepackte Daten-Register sind.
Verfahren, Folgendes umfassend: Empfangen eines von zwei Typen von Ausgabe von Dekompressions-Hardware, wobei die Dekompressions-Hardware bei einem ersten Typ von Ausgabe zusätzlich zu den Token einen eigenständigen Literal-Strom generiert und die Dekompressions-Hardware bei dem zweiten Typ nur Token generiert; und Nachbearbeiten der Ausgabe des ersten Typs durch Bereitstellen eines Eingabezeigers an den eigenständigen Literal-Strom und Nachbearbeiten der Ausgabe des zweiten Typs durch Übergeben eines Zeigers an einen ursprünglich komprimierten Strom.
Verfahren nach Anspruch 17, wobei die Dekompressions-Hardware für jeden gewählten Typ von Ausgabe den eigenständigen Literal-Strom während einer DEFLATE- oder LZS-Decodierung generiert.
Verfahren nach Anspruch 17, wobei für jeden gewählten Ausgabetyp die Dekompressions-Hardware keinen eigenständigen Literal-Strom während des LZ4- und Snappy-Decodierens generiert.
Verfahren nach einem der Ansprüche 17-19, wobei die Software einen History-Puffer hält, durch Festhalten einer ausreichenden Menge der Ausgabe der Dekompressions-Hardware zum Bedienen von Referenzen, die daraus gesammelt wurden.
Hardware-Dekompressionsvorrichtung, Folgendes umfassend: ein Eingabepuffermittel zum Speichern eintreffender Eingabedatensätze aus einem komprimierten Strom; mehrere Decodierungsmittel, wobei jedes Decodierungsmittel mindestens einen Eingabedatensatz aus dem Eingabepuffer decodieren und einen Zwischendatensatz aus den decodierten Daten ausgeben soll und ein Teilsatz aus den mehreren Decodierern einen Strom von Literalen ausgeben soll; ein Umformatierungsmittel zum Formatieren eines Zwischendatensatzes in einen von mindestens zwei Typen von Token.
Hardware-Vorrichtung nach Anspruch 21, wobei ein erstes aus den mehreren Decodierungsmitteln gemäß dem DEFLATE-Kompressionsalgorithmus decodieren und einen Byte-ausgerichteten Literal-Strom von Literalen, die Huffman-codiert waren, ausgeben soll.
Hardware-Vorrichtung nach Anspruch 22, wobei der Zwischendatensatz mindestens eins aus einem Satz von Literalen, Informationen zu einer Anzahl von Literalen des Zwischendatensatzes und Informationen über eine Referenz beinhaltet.
Hardware-Vorrichtung nach einem der Ansprüche 21-23, wobei ein zweites aus den mehreren Decodierungsmitteln einen Zwischendatensatz pro Eingabedatensatz generieren soll.
Hardware-Vorrichtung nach einem der Ansprüche 21-24, wobei ein drittes aus den mehreren Decodierungsmitteln einen einzelnen Zwischendatensatz aus mehreren Eingabedatensätzen generieren soll.