DE112016004192T5

DE112016004192T5 - Fehlerprüfung komprimierter Ströme in heterogenen Kompressionsbeschleunigern

Info

Publication number: DE112016004192T5
Application number: DE112016004192.6T
Authority: DE
Inventors: James D. Guilford; Vinodh Gopal; Laurent Coquerel
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-09-15
Filing date: 2016-08-08
Publication date: 2018-05-30
Also published as: CN108028663B; US9787332B2; WO2017048406A1; CN108028663A; US20170077964A1

Abstract

Eine Kompressionsmaschine kann für eine effizientere Fehlerprüfung eines komprimierten Stroms gestaltet sein, um eine Anpassung eines heterogenen Designs zu enthalten, das verschachtelte Hardware- und Software-Stufen einer Kompression und Dekompression enthält. Ein Ausgang eines String Matchers kann umgekehrt sein, um einen Bit-Strom zu generieren, der dann mit einem Eingangsstrom zur Kompressionsmaschine als erste Fehlerprüfung verglichen wird. Ein endgültiger komprimierter Ausgang der Kompressionsmaschine kann teilweise dekomprimiert sein, um eine Entropiecode-Codierung eines Entropiecode-Codierers umzukehren. Der teilweise dekomprimierte Ausgang kann mit einem Ausgang eines Entropiecodegenerators verglichen werden, um eine zweite Fehlerprüfung durchzuführen. Ein Ermitteln eines Fehlers bei der ersten Fehlerprüfung verringert die Latenz beim Generieren einer Störung oder Ausnahme, deutlich, wie dies beim Durchführen rechenintensiver Aspekte der Kompression und Dekompression mit Software anstelle spezialisierter Hardware der Fall ist.

Description

Die vorliegende Offenbarung betrifft das Gebiet des Speichermanagements und insbesondere die Optimierung einer Fehlerprüfung komprimierter Ströme in heterogenen Kompressionsbeschleunigern.
Hintergrund
Hardware-Beschleuniger bieten eine Gelegenheit, mit maßgeschneiderten Schaltungsdesigns Leistungs- und Energieverbesserungen um Größenordnungen zu erreichen. Mit dem Fortschritt in der Technologie jedoch ist auch die Menge an Daten gestiegen, die verarbeitet, gespeichert und übertragen werden muss. Sogenannte Big Data (große Datenmenge) stellen ein Großteil derzeitiger Technologielösungen und somit fortgeschrittener Lösungen zur Kompression und Dekompression dar, sodass mehr Daten in weniger Raum (oder mit geringerem Bedarf an Bandbreite) als je zuvor gespeichert und übertragen werden können. Es besteht jedoch die Herausforderung, eine stille Datenkorruption in Hardware-Maschinen zu erfassen, die eine Kompression durchführen. Das Thema weicher Fehler (Soft Errors, SER) ist bekannt, aber diese sind im Allgemeinen nachweisbar. Das Problem ist jedoch schwerwiegend, wenn ein Fehler während eines Kompressionsvorgangs unerfasst bleibt. Algorithmen, die stark komprimierte Ströme generieren, leiden an dem Problem, dass Daten schwierig aus einem beschädigten Strom zu gewinnen sind; im schlimmsten Fall gehen alle Daten nach dem Punkt der Beschädigung verloren.
Die aktuellsten Lösungen beruhen auf einer einfachen Verhärtung der Strukturen, die in den Kompressoren verwendet werden, wie Fehlerkorrekturcode (Error Correction Code, ECC)-geschützte RAMs oder paritätsgeschützte Busse. Falls jedoch ein unerfasster Mehrfach-Bit-Fehler oder ein Ereignis in der Berechnungsdatenpfadlogik vorliegt, ist nicht klar, ob diese, außer mit Hilfe der Anwendung probabilistischer Verfahren, die an sich ungenau sind, vermieden werden können. Einige Entwickler beanspruchen die Entwicklung eines vollständigen Dekompressionsvorgangs als Fehlerprüfung bei einer Kompression, aber diese Lösung ist teuer, da sie signifikante Hardware-Ressourcen erfordert und auch einer Verarbeitungs-Pipeline einer Anwendung eine signifikante Latenz auferlegt.
Figurenliste

Figure 1 ist eine schematische Darstellung eines beispielhaften Fehlerprüfungssystems mit vollständigen Kompressions- und Dekompressionsmaschinen.
2 ist eine schematische Darstellung eines beispielhaften Fehlerprüfungssystems mit einer heterogenen Kompressions- und Dekompressionsmaschine ohne vollständige Dekompression.
3 ist ein Flussdiagramm eines beispielhaften Verfahrens zur Fehlerprüfung eines komprimierten Stroms, das das heterogene Design des Systems von 2 verwendet.
4 ist ein Flussdiagramm eines anderen beispielhaften Verfahrens zur Fehlerprüfung eines komprimierten Stroms, das das heterogene Design des Systems von 2 verwendet.
5A ist ein Blockdiagramm, das eine Pipeline in ursprünglicher Reihenfolge und eine Registerumbenennungsstufe, Ausgabe-/Ausführungs-Pipeline in einer anderen Reihenfolge gemäß einer bestimmten Ausführungsform zeigt.
5B ist ein Blockdiagramm, das eine Mikroarchitektur für einen Prozessor, der eine Kompressions-/Dekompressionsoptimierung in Solid-State Speichervorrichtungen implementiert, gemäß einer bestimmten Ausführungsform zeigt.
6 zeigt ein Blockdiagramm der Mikroarchitektur für einen Prozessor, die logische Schaltungen zum Durchführen einer Kompressions-/Dekompressionsoptimierung in Solid-State Speichervorrichtungen enthält, gemäß einer Ausführungsform.
7 ist ein Blockdiagramm eines Computersystems gemäß einer bestimmten Implementierung.
8 ist ein Blockdiagramm eines Computersystems gemäß einer anderen Implementierung.
9 ist ein Blockdiagramm eines System-on-Chip gemäß einer bestimmten Implementierung.
10 zeigt eine andere Implementierung eines Blockdiagramms für ein Rechensystem.
11 zeigt eine andere Implementierung eines Blockdiagramms für ein Rechensystem.

Beschreibung von Ausführungsformen
Eine Lösung der teuren Auswirkungen auf eine Anwendungsverarbeitung bei Verwendung einer vollständigen Dekompression als Fehlerprüfung bei einer Kompression ist die Verwendung eines heterogenen (oder hybriden) Kompressions- und Dekompressionsdesigns, das sowohl Hardware wie auch Software verwendet. Diese Maschinen sind viel kleiner, da weniger Hardware erforderlich ist, was jedoch auf Kosten einer gewissen Software-Verarbeitung geht. Ein Vorsehen einer Fehlerprüfung in diesen heterogenen Modellen kann zusätzliche Herausforderungen bedeuten, einschließlich einer zusätzlichen Latenz beim Erfassen von Fehlern. Dies kann auf die zahlreichen Hardware-Software-Interaktionen zurückzuführen sein, die im kritischen Pfad eines Verarbeitungsflusses einer Anwendung auftreten. Die vorliegende Offenbarung präsentiert eine Lösung zur Implementierung einer Fehlererfassung in einem komprimierten Strom mit verminderter Latenz, was besser ist, als eine vollständige Kompression, gefolgt von einer vollständigen Dekompression unter Verwendung einer heterogenen Kompressions- und Dekompressionsmaschine vorzunehmen.
In einem Beispiel kann eine Kompressionsmaschine für eine effizientere Fehlerprüfung eines komprimierten Stroms umgestaltet werden, um eine Anpassung eines heterogenen Designs zu enthalten, das verschachtelte Hardware- und Software-Stufen einer Kompression und Dekompression enthält. Ein Ausgang eines Hardware String Matchers kann umgekehrt werden, um einen Bit-Strom zu generieren, der dann mit einem Eingangsstrom in die Kompressionsmaschine als erste Fehlerprüfung verglichen wird. Diese Umkehroperation kann in Software durchgeführt werden und eine Fehlerprüfung früh im Kompressionsprozess vorsehen. Ein endgültiger komprimierter Ausgang der Kompressionsmaschine kann teilweise dekomprimiert sein, um eine Entropiecode-Codierung eines Entropiecode-Codierers umzukehren. Der teilweise dekomprimierte Ausgang kann mit einem Ausgang eines Entropiecodegenerators verglichen werden, um eine zweite Fehlerprüfung durchzuführen. Wenn ein Fehler bei der ersten Fehlerprüfung gefunden wird, wird die Latenz beim Generieren einer Störung oder Ausnahme deutlich verringert, wie dies bei Durchführung rechnerintensiver Aspekte der Kompression und Dekompression mit Software anstelle von spezialisierter Hardware der Fall ist.
In einem anderen Beispiel kann ein Fehlerprüfungs-, Datenkompressionssystem eine Kompressionsmaschine mit einer Vielzahl von Kompressionsstufen zum Komprimieren eines Eingangsstroms von Daten enthalten. Eine erste Kompressionsstufe kann einen Hardware-Matcher enthalten, um Zeichenketten diverser Teilzeichenketten des Eingangsstroms abzugleichen und ein Zwischen-Token-Format entsprechender Teilzeichenkettenübereinstimmungen zu generieren. In einer bestimmten Ausführungsform kann die erste Kompressionsstufe einen LZ77-Kompressor enthalten. Eine zweite Kompressionsstufe kann einen Prozessorkern zum Ausführen erster Befehle als Entropiecodegenerator enthalten, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen. In einer bestimmten Ausführungsform ist der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen von Token. Eine dritte Kompressionsstufe kann einen Hardware Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes enthalten. In einer bestimmten Ausführungsform kann der Entropiecode-Codierer ein Huffman-Codierer sein, der den endgültigen komprimierten Ausgang aus dem Huffman-Baum generiert.
Mehrere Dekompressionsstufen können in den mehreren Kompressionsstufen eingefügt sein, um die Fehlerprüfung vorzusehen. Zum Beispiel kann der Prozessorkern in einer ersten Dekompressionsstufe zweite Befehle als inverser String Matcher ausführen, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren. Die erste Dekompressionsstufe kann auch einen ersten Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer ersten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms enthalten. Eine zweite Dekompressionsstufe kann einen Hardware-Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs enthalten, um ein Codieren des Entropiecode-Codierers umzukehren, wodurch ein teilweise dekomprimierter Ausgang generiert wird. Die zweite Dekompressionsstufe kann einen zweiten Komparator zum Vergleichen des endgültigen komprimierten Ausgangs mit dem teilweise dekomprimierten Ausgang und zum Generieren einer zweiten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang enthalten.
1 ist eine schematische Darstellung eines beispielhaften Fehlerprüfungssystems 100 mit einer Kompressionsmaschine 108 und einer Dekompressionsmaschine 120, wobei das System 100 als Prozessor oder andere Vorrichtung implementiert sein kann. In diesem Beispiel ist das System 100 mit einer vollständigen Dekompression gestaltet, um eine Fehlerprüfung durchzuführen. Die Kompressionsmaschine 108 kann einen Eingangsstrom komprimieren, um einen endgültigen komprimierten Ausgang zu generieren. Die Dekompressionsmaschine 120 kann den endgültigen komprimierten Ausgang dekomprimieren, um einen dekomprimierten Ausgang zu generieren, um diesen mit dem Eingangsstrom zu vergleichen und eine Störung oder Ausnahme zu generieren, sobald eine Fehlabstimmung zwischen dem dekomprimierten Ausgang und dem Eingangsstrom gefunden wird.
Insbesondere kann die Kompressionsmaschine 108 einen String Matcher 110, einen Entropiecodegenerator 114 und einen Entropiecode-Codierer 118 enthalten. Jeder von dem String Matcher 110, dem Entropiecodegenerator 114 oder dem Entropiecode-Codierer 118 kann durch Ausführung von Befehlen durch zumindest einen Prozessorkern des Systems 100 durchgeführt werden, um z.B. in Software durchgeführt zu werden. Der String Matcher 110 kann diverse Teilzeichenketten des Eingangsstroms einem Zeichenkettenabgleich unterziehen und ein Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen abhängig von übereinstimmenden Teilzeichenketten generieren, z.B. Token für jedes Literal oder jeden Rückverweis erstellen. In einem Beispiel ist der String Matcher 110 ein LZ77-Kompressor. Der Entropiecodegenerator 114 kann einen Entropie- - oder anderen arithmetischen - Algorithmus ausführen, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen. In einer bestimmten Ausführungsform ist der Entropiecodegenerator 114 ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token. Der Entropiecode-Codierer 118 kann dann einen endgültigen komprimierten Ausgang des Eingangsstroms unter Verwendung der Entropiecodes codieren. In einer bestimmten Ausführungsform ist der Entropiecode-Codierer ein Huffman-Codierer, der den endgültigen komprimierten Ausgang aus dem Huffman-Baum generiert.
Die Dekompressionsmaschine 120 kann einen Decodierer 124 und einen Verlaufskopierer 126 enthalten. Der Decodierer 124 kann den endgültigen komprimierten Ausgang decodieren und den Verlaufskopierer 126 verwenden, der auf eine Verlaufskopie zugreift, die in einem History-Puffer der Dekompressionsmaschine 120 gespeichert ist, um einen Ausgangs-Bit-Strom gemäß den Literalen und Rückverweisen zu erstellen, die sich in der Codierung befinden. Insbesondere kann der Decodierer 124 den komprimierten Strom in Token zergliedern, die literalen Bytes oder Verweise aus sich wiederholende Zeichenketten darstellen. Der Verlaufskopierer 126 kann dann Zeichenketten aus den literalen Bytes oder aus den Rückverweisen in den Ausgangsstrom kopieren, wo die Verweise in den letzten 32KB des Verlaufs aufscheinen. Der Decodierer 124 und/oder die Verlaufskopie 126 können in Software durchgeführt werden. Wenn der Verlaufskopie- 126 Block durch eine CPU oder einen anderen Prozessorkern ausgeführt wird, kann der Verlaufskopie- 126 Block eine Dekompressionsmaschine um einen Faktor von etwa 15 verringern.
Das System 100 kann ferner einen Komparator 130 zum Vergleichen des Ausgangs-Bit-Stroms mit dem Eingangsstrom von Daten enthalten, der eine Störung oder Ausnahme (die einen Fehler anzeigt) als Antwort auf ein Feststellen einer Fehlabstimmung zwischen dem Ausgangs-Bit-Strom und dem Eingangsstrom generiert. Der Komparator 130 kann jedes Byte in Eingangs- und Ausgangszwischenspeichern auf Gleichheit vergleichen oder kann eine Prüfsumme (z.B. zyklische Redundanzprüfung (CRC)) der jeweiligen Zwischenspeicher berechnen und dann prüfen um festzustellen, dass die Prüfsummen dieselben sind. Eine dieser Methoden kann von jedem hier beschriebenen Komparator verwendet werden.
Das System 100 kann in einem Beispiel den DEFLATE Standardkompressionsalgorithmus einsetzen, der allgemein verwendet wird. Der DEFLATE bildet die Basis für Formate wie gzip/Zlip™ wie auch Winzip® (oder PKZIP®). Das DEFLATE Standarddatenformat enthält eine Reihe von Blöcken, entsprechend aufeinanderfolgenden Blöcken von Eingangsdaten. Jeder Block wird unter Verwendung einer Kombination des LZ77-Algorithmus und einer Huffman-Codierung komprimiert. Der LZ77-Algorithmus findet sich wiederholende Teilzeichenketten und ersetzt sie mit Rückverweisen, z.B. relativen Distanzverschiebungen. Der LZ77-Algorithmus kann einen Verweis auf eine duplizierte Zeichenkette bis zu 32K Eingangs-Bytes zurück im Zwischenspeicher verwenden, die in denselben oder vorangehenden Blöcken auftritt. Die komprimierten Daten können eine Reihe von Elementen in zwei Arten enthalten: literale Bytes und Hinweise auf replizierte Zeichenketten, wobei ein Hinweis als ein Paar <Länge, Rückwärtsdistanz> dargestellt ist. Andere Codierungsdatenformate können auch verwendet werden und ein Verweis auf das DEFLATE-Format ist nicht als Einschränkung, sondern als Beispiel auszulegen.
2 ist eine schematische Darstellung eines anderen beispielhaften Fehlerprüfungssystems 200 mit einem heterogenen Kompressor 208 und verschachtelten Stufen einer Dekompression zur Fehlerprüfung eines komprimierten Stroms während und nach einer Kompression. Der heterogene Kompressor 208 kann, ähnlich wie die Kompressionsmaschine 108 von 1, mehrere Kompressionsstufen enthalten und kann durch einen Prozessor oder eine andere Verarbeitungsvorrichtung implementiert sein. Diese Kompressionsstufen können zum Beispiel einen String Matcher 210 (erste Kompressionsstufe), einen Entropiecodegenerator 214 (zweite Kompressionsstufe) und einen Entropiecode-Codierer 218 (dritte Kompressionsstufe) mit ähnlicher Funktionalität wie unter Bezugnahme auf 1 besprochen enthalten, um einen endgültigen komprimierten Ausgang zu generieren.
Während in einer bestimmten Ausführungsform der String Matcher 210 ein Hardware String Matcher sein kann und der Entropiecode-Codierer 218 ein Hardware Entropiecode-Codierer sein kann, kann ein Prozessorkern oder eine andere CPU Befehle ausführen, um den Entropiecodegenerator 214 als Software zu implementieren. Da diese zweite Kompressionsstufe rechnerintensiv ist, kann eine Ausführung des Entropiecodegenerators 214 als Software die Größe des heterogenen Kompressors 208 deutlich verringern.
Anders als 1 zeigt 2 jedoch Fehlerprüfungsdekompressionsstufen, die zwischen und nach den Kompressionsstufen verschachtelt sind. Im Speziellen kann eine erste Dekompressionsstufe einen inversen String Matcher 212 enthalten, um eine inverse Operation an einem Ausgang vom String Matcher 210 durchzuführen, um einen Bit-Strom 213 zu generieren. Ein Komparator 216 kann den Bit-Strom 213 mit dem Eingangsstrom vergleichen, wobei eine erste Störung oder Ausnahme 222 als Reaktion auf ein Feststellen einer Fehlabstimmung zwischen dem Bit-Strom 213 und dem Eingangsstrom generiert wird. Falls keine Fehler aus einem Ausgang des String Matchers 210 vorliegen, sollte der Bit-Strom 213 derselbe sein wie der Eingangsstrom. Daher führt der inverse String Matcher 212 dieselbe oder eine ähnliche Funktionalität wie der Verlaufskopierer- 126 Block der Dekompressionsmaschine 120 von 1 aus. In einer bestimmten Ausführungsform führt zumindest ein Prozessorkern Befehle zum Implementieren des inversen String Matchers 212 als Software aus.
Zusätzlich kann eine zweite Dekompressionsstufe den Verlaufskopierer entfernen, der im System 100 von 1 eingesetzt wird. Diese Entfernung hinterlässt einen Decodierer 224 (wie einen Hardware-Decodierer), mit dem der endgültige komprimierte Ausgang teilweise dekomprimiert wird, um eine Codierung umzukehren, die durch den Entropiecode-Codierer 218 durchgeführt wird, wodurch ein teilweise dekomprimierter Ausgang 225 generiert wird. Ein Komparator 236 kann dann einen Ausgang des Entropiecodegenerators 214 mit dem teilweise dekomprimierten Ausgang 225 vergleichen und eine zweite Störung oder Ausnahme 242 generieren, wenn der Ausgang des Entropiecodegenerators 214 nicht mit dem teilweise dekomprimierten Ausgang 225 übereinstimmt. Durch Durchführen des inversen String Matchers 212 in Software und Entfernen der Verlaufskopie (in 1 dargestellt) wird die Gesamtgröße der zur Fehlerprüfung eingesetzten Dekompressionsstufen deutlich verringert und die Fehlerprüfung wird effizienter. Der Decodierer 224 und der Komparator 236 können in einem Beispiel in Spezial-Hardware ausgeführt werden.
Die Störungen oder Ausnahmen können als Maschinenprüfungsarchitekturstörung (MCA) generiert werden, die katastrophal sein kann, was üblicherweise zu einer Meldung von Unterbrechung(en) höchster Priorität führt, um eine Ausbreitung eines Fehlers in Daten in einem Rechensystem zu vermeiden. Sämtliche derartige MCAs können in einem Protokoll aufgezeichnet und einem Administrator oder IT-Personal zur Analyse berichtet werden oder können automatisiert analysiert werden und die Ergebnisse können dem Personal berichtet werden. Vorteilhafterweise sieht das System 200 von 2 eine verbesserte Granularität einer Fehlererfassung vor, da die ersten Störungen oder Ausnahmen 222 protokolliert, verfolgt und getrennt von Störungen oder Ausnahmen 242 berichtet werden können, die im endgültigen komprimierten Ausgang erfasst werden.
Die Beweisführung, dass die Daten des komprimierten Stroms während der Kompression unbeschädigt geblieben sind, ist der Beweis von zwei Teilproblemen mit den Dekompressionsstufen von 2. Erstens sind die tatsächlichen Übereinstimmungen oder literalen Bytes, die der String Matcher 210 findet, korrekt. Daher verwendet die Software den String Matcher Token-Strom und führt eine inverse Operation aus (eine Art von LZ77-„Dekomprimierung“ in einer bestimmten Ausführungsform). Der Betrieb des Komparators 216 kann dann bestätigen, dass diese mit dem ursprünglichen Eingangsstrom übereinstimmen. Zweitens, falls der Bit-Strom 213, der durch den inversen String Matcher 212 ausgegeben wird, keine Fehler enthält, beweist die zweite Dekompressionsstufe, dass der Codierer keinen gestörten komprimierten Strom generiert hat. Hier kann der teilweise Hardware-Dekomprimiererblock (z.B. der Decodierer 224) eine Huffman-Decodierung in einer bestimmten Ausführungsform durchführen und den Ausgang mit dem mit Token behafteten Strom vergleichen, der aus dem Entropiecodegenerator 214 kommt (der in einer bestimmten Ausführungsform ein Huffman-Baumgenerator sein kann).
Es ist zu beachten, dass die erste Dekompressionsstufe (die durch den inversen String Matcher 212 durchgeführt wird) sehr früh erfolgen kann, somit eine frühe MCA-Fehlerprüfung speisen kann. Tatsächlich wird bei einer ausreichend raschen Prüfung diese erste Dekompressionsstufe gratis bereitgestellt (keine zusätzliche Latenz). Die Entropie- (oder Huffman-) Codierungs- und Decodierungsschritte werden später verifiziert, aber immer noch schneller als in 1, da das System 200 von der ersten Stufe des Dekomprimierers an prüft. Die frühe Prüfung kann erfolgen, bevor noch Entropiecodes oder Huffman-Bäume generiert werden, wodurch keine Zeit der Latenz einer normalen Verarbeitung hinzugefügt wird.
Der Zeitablauf zur Erfassung des ersten Fehlers kann durch ein Beispiel veranschaulicht werden. Nehmen wir an, dass wir einen DEFLATE Block für jeweils 128KB Eingangsdaten generieren (eine vernünftige Annahme aus realen Nutzungen). Wie nehmen auch an, dass Eingangszwischenspeicher in 32KB Abschnitten zugeordnet sind und daher vier Kompressionsaufrufe pro Block erfolgen. Unter Annahme eines hohen Niveaus einer zlib™ Kompression läuft der String Matcher 210 etwa 8 Zyklen/Byte, sodass etwa 250K Zyklen pro Kompressionsaufruf (und etwa 1M Zyklen für den vollständigen Block) erforderlich sind. Die Entropiecode- (oder Baum-) Generierung ist etwa 50K Zyklen und wir nehmen eine Latenz durch die Codier- und Decodierblöcke von etwa jeweils 1K Zyklen an und dass der letzte Verlaufskopierer eine Latenz von etwa 20 Zyklen hat.
In dem Kompressions- und vollständigen Dekompressionsdesign von 1 ist der früheste Zeitpunkt, zu dem das System 100 einen Fehler erfassen kann, bei etwa 1M + 50K + 2K + 20 Zyklen. In dem Design von 2 ist, unter der Annahme, dass der Fehler in der String Matcher Stufe liegt (höchstwahrscheinlich ein SER-Ereignis), der Zeitpunkt zum Erfassen des ersten Fehlers: 250K*i Zyklen, wobei i = 1,2,3,4, abhängig davon, bei welchem Kompressionsaufruf das Ereignis aufgetreten ist. Je früher daher die Fehlererfassung erfolgt, umso niedriger ist die Latenz.
Falls in dem Design des Systems 200 von 2 der Fehler während des Codierungsverlaufs des Entropiecode-Codierers 218 auftritt, kann das System 100 den Fehler im schlimmsten Fall bei 1M + 50K + 2K Zyklen berichten. Somit kann das System 200 Fehler viel rascher erfassen (in diesem Beispiel bis zu etwa 4X schneller, wenn der Fehler im ersten Aufruf aufgetreten ist, z.B. nach dem String Matcher 210). Es ist auch zu beachten, dass ein vollständiger Dekomprimierer selbst eine signifikante Wahrscheinlichkeit hinzufügt, dass ein SER-Ereignis im Dekomprimierer auftritt, wodurch falsche Negativwerte in höherem Maße generiert werden.
3 ist ein Flussdiagramm eines beispielhaften Verfahrens zur Fehlerprüfung eines komprimierten Stroms, das das heterogene Design des Systems 200 von 2 einsetzt. Eine Kompressionsmaschine des Systems 200 kann einen Eingangsstrom mit mehreren Kompressionsstufen heterogen in Hardware und Software (310) komprimieren. Das System 200 kann auch zumindest zwei Ausgänge aus den mehreren Kompressionsstufen dekomprimieren, um zumindest zwei dekomprimierte Ausgänge zu generieren (obwohl die Ausgänge nicht vollständig dekomprimiert sein können) (320). Das System 200 kann ferner eine Fehlerprüfung der zumindest zwei komprimierten Ausgängen mit entsprechenden Eingängen durchführen, um etwaige Fehlabstimmungen zu identifizieren (330). Das System 200 kann auch ein Endergebnis oder eine Ausnahme (wie eine MCA) als Reaktion auf eine Fehlabstimmung der Fehlerprüfung (340) generieren.
4 ist ein Flussdiagramm eines anderen beispielhaften Verfahrens zur Fehlerprüfung eines komprimierten Stroms, das das heterogene Design des Systems 200 von 2 einsetzt. Das System 200 kann mit einem Komprimieren eines Eingangsstroms in einer ersten Kompressionsstufe unter Verwendung eines String Matchers (wie eines LZ77-Kompressors) beginnen, um ein Zwischen-Token-Format von Teilzeichenkettenübereinstimmungen zu generieren, mit einem Token für jedes Literal für Einzelne und für jeden Rückverweis auf eine Teilzeichenkettenübereinstimmung (410). Das System 200 kann in einer ersten Dekompressionsstufe eine inverse Operation des String Matchers verwenden, um einen Bit-Strom zu generieren (420). Das System 200 kann dann eine frühe Fehlerprüfung durch Vergleichen des Eingangsstroms mit dem Bit-Strom mit einem Komparator durchführen, um eine erste Störung oder Ausnahme (wie eine MCA) zu generieren (430).
Das Verfahren von 4 kann mit dem System 200 in einer zweiten Kompressionsstufe fortfahren, wobei es mit einem Entropiecodegenerator Entropiecodes aus Frequenzen von Token generiert, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen (440). In einer bestimmten Ausführungsform kann der Entropiecodegenerator ein Baumgenerator sein, der einen Huffman-Baum aus den Frequenzen der Token generiert. In anderen Ausführungsformen können andere arithmetische oder Entropiealgorithmen eingesetzt werden. Das System 200 kann ferner in einer dritten Kompressionsstufe (die z.B. einen Entropiecode-Codierer einsetzt) einen endgültigen komprimierten Ausgang des Eingangsstroms unter Verwendung der Entropiecodes codieren (450). In einer bestimmten Ausführungsform kann die dritte Kompressionsstufe ein Huffman-Codierer sein. In einer anderen Ausführungsform kann die dritte Kompressionsstufe ein arithmetischer oder anderer Entropiecode-Codierer sein.
Das Verfahren von 4 kann in einer zweiten Dekompressionsstufe, unter Verwendung eines Decodierers, mit einer teilweisen Dekomprimierung des endgültigen komprimierten Ausgangs fortfahren, um eine Codierung der dritten Kompressionsstufe umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren (460). Das System 200 kann dann, unter Verwendung eines Komparators, eine Fehlerprüfung des Ausgangs des Entropiecodegenerators gegenüber dem teilweise komprimierten Ausgang durchführen, wodurch eine zweite Störung oder Ausnahme (die eine MCA- oder ähnliche Störung sein kann) infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang generiert wird (470). Das System 200 kann auch jede erste Störung oder Ausnahme und jede zweite Störung oder Ausnahme protokollieren und gegebenenfalls berichten (480), wodurch ein höheres Niveau an Granularität vorgesehen wird, bezüglich wann solche Störungen oder Ausnahmen verursacht wurden und was diese verursacht hat.
5A ist ein Blockdiagramm, das eine Mikroarchitektur für einen Prozessorkern 500 zeigt, der das System 100 von 1 oder das System 200 von 2 ausführen kann. Im Speziellen zeigt der Prozessorkern 500 einen Architekturkern in ursprünglicher Reihenfolge und eine Registerumbenennungslogik, Ausgabe-/Ausführungslogik in einer anderen Reihenfolge, die in einem Prozessor gemäß zumindest einer Ausführungsform der Offenbarung enthalten sein soll. Die Ausführungsformen des Fehlerkorrekturcodes, die zusätzliche Bits tragen, können durch den Prozessorkern 500 implementiert werden.
Der Prozessorkern 500 enthält eine Frontend-Einheit 530, die an eine Ausführungsmaschineneinheit 550 gekoppelt ist, und beide sind an eine Speichereinheit 570 gekoppelt. Der Prozessorkern 500 kann einen Rechenkern mit beschränktem Befehlssatz (RISC-Kern), einen Rechenkern mit komplexem Befehlssatz (CISC-Kern), einen Kern mit sehr langem Befehlswort (VLIW) oder eine hybride oder alternative Kernart enthalten. Als weitere Option kann der Prozessorkern 500 einen Spezialzweckkern, wie zum Beispiel einen Netzwerk-, oder Kommunikationskern, eine Kompressionsmaschine, einen Grafikkern oder dergleichen enthalten. In einer bestimmten Ausführungsform kann der Prozessorkern 500 ein Mehrfachkernprozessor sein oder kann Teil eines Mehrfachprozessorsystems sein.
Die Frontend-Einheit 530 enthält eine Abzweigungsvorhersageeinheit 532, die an eine Befehls-Cache-Einheit 534 gekoppelt ist, die an einen Befehls-Adressenübersetzungspuffer (TLB) 536 gekoppelt ist, der an eine Adressenabrufeinheit 538 gekoppelt ist, die an eine Decodiereinheit 540 gekoppelt ist. Die Decodiereinheit 540 (auch bekannt als Decodierer) kann Befehle decodieren und als Ausgang eine oder mehrere Mikrooperationen, Mikrocodeeintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale generieren, die aus primären Befehlen decodiert werden oder diese auf andere Weise reflektieren oder von diesen abgeleitet sind. Der Decodierer 540 kann unter Verwendung diverser verschiedener Mechanismen implementiert werden. Beispiele für geeignete Mechanismen enthalten, ohne aber darauf beschränkt zu sein, Nachschlagtabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (PLAs), Mikrocode-Nur-Lese-Speicher (ROMs) usw. Die Befehls-Cache-Einheit 534 ist ferner an die Speichereinheit 570 gekoppelt. Die Decodiereinheit 540 ist an eine Umbenennungs-/Zuordnungseinheit 552 in der Ausführungsmaschineneinheit 550 gekoppelt.
Die Ausführungsmaschineneinheit 550 enthält die Umbenennungs-/Zuordnungseinheit 552, die an eine Retirement-Einheit (Ruhezustandseinheit) 554 und einen Satz aus einer oder mehreren Zeitplanereinheit(en) 556 gekoppelt ist. Die Zeitplanereinheit(en) 556 stellen eine beliebige Anzahl verschiedener Zeitplaner dar, einschließlich Reservierungsstationen (RS), eines zentralen Befehlsfensters usw. Die Zeitplanereinheit(en) 556 kann (können) an die physische(n) Registerdateieinheit(en) 558 gekoppelt sein. Jeder der physischen Registerdateieinheiten 558 stellt eine oder mehrere physische Registerdatei(en) dar, von welchen verschiedene eine oder mehrere verschiedene Datenart(en) speichern, wie skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektor-Ganzzahl, Vektor-Gleitkomma usw., Status (z.B. einen Befehlszeiger, der die Adresse der nächsten auszuführenden Adresse ist) usw. Die physische(n) Registerdateieinheit(en) 558 kann (können) von der Retirement-Einheit 554 überlappt sein, um diverse Möglichkeiten zu zeigen, in welchen eine Registerumbenennung und Ausführung in einer anderen Reihenfolge implementiert werden können (z.B. Verwendung eines oder mehrerer Neuordnungspuffer(s) und einer oder mehrerer Retirement-Registerdatei(en), Verwendung eines oder mehrerer Future File(s), eines oder mehrerer History-Puffer(s) und einer oder mehrerer Retirement-Registerdatei(n); Verwendung von Registerkarten und eines Pools von Registern; usw.).
Im Allgemeinen sind die architektonischen Register von außerhalb des Prozessors oder aus der Perspektive eines Programmierers sichtbar. Die Register sind auf keine besondere Art von Schaltung beschränkt. Unterschiedliche verschiedene Arten von Registern sind geeignet, solange sie imstande sind, Daten wie hier beschrieben zu speichern und bereitzustellen. Beispiele für geeignete Register enthalten, ohne aber darauf beschränkt zu sein, physische Register, dynamisch zugeordnete, physische Register unter Verwendung einer Registerumbenennung, Kombinationen zweckbestimmter und dynamisch zugeordneter physischer Register usw. Die Retirement-Einheit 554 und die physische(n) Registerdateieinheit(en) 558 sind an den (die) Ausführungs-Cluster 560 gekoppelt. Der (die) Ausführungs-Cluster 560 enthält (enthalten) einen Satz aus einer oder mehreren Ausführungseinheit(en) 562 und einen Satz aus einer oder mehreren Speicherzugriffseinheit(en) 564. Die Ausführungseinheiten 562 können diverse Operationen ausführen (z.B. Verschiebungen, Addition, Subtraktion, Multiplikation) und diverse Arten von Daten verarbeiten (z.B. skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektor-Ganzzahl, Vektor-Gleitkomma).
Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die für spezielle Funktionen oder Sätze von Funktionen bestimmt sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle Funktionen durchführen. Die Zeitplanereinheit(en) 556, physischen Registerdateieinheit(en) 558, und der (die) Ausführungs-Cluster 560 sind als mögliche Mehrzahl dargestellt, da gewisse Ausführungsformen separate Pipelines für gewisse Arten von Daten/Operationen generieren (z.B. eine skalare Ganzzahl-Pipeline, eine skalare Gleitkomma/gepackte Ganzzahl/gepacktes Gleitkomma/Vektor-Ganzzahl/Vektor-Gleitkomma-Pipeline und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Zeitplanereinheit, physische Registerdateieinheit und/oder ihren eigenen Ausführungs-Cluster haben - und im Fall einer separaten Speicherzugriffs-Pipeline sind gewisse Ausführungsformen implementiert, in welchen nur der Ausführungs-Cluster dieser Pipeline über die Speicherzugriffseinheit(en) 564 verfügt). Es sollte auch klar sein, dass bei Verwendung separater Pipelines eine oder mehrere dieser Pipelines eine Ausgabe/Ausführung in einer anderen Reihenfolge und der Rest in der ursprünglichen Reihenfolge sein kann.
Der Satz von Speicherzugriffseinheiten 564 kann an die Speichereinheit 570 gekoppelt sein, die einen Daten-Prefetcher 580, eine Daten-TLB-Einheit 572, eine Daten-Cache-Einheit (DCU) 574 und eine Level 2 (L2) Cache-Einheit 576 enthalten kann, um nur einige Beispiele zu nennen. In einigen Ausführungsformen ist die DCU 574 auch als Daten-Cache des ersten Levels (L1 Cache) bekannt. Die DCU 574 kann mehrere herausragende Cache-Fehlschläge handhaben und mit der Bedienung eingehender Speicherungen und Lasten fortfahren. Sie unterstützt auch eine Aufrechterhaltung der Cache-Kohärenz. Die Daten-TLB-Einheit 572 ist ein Cache, der zur Verbesserung der virtuellen Adressenübersetzungsgeschwindigkeit durch Abbilden virtueller und physischer Adressräume verwendet wird. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 564 eine Lasteinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit enthalten, von welchen jede an die Daten-TLB-Einheit 572 in der Speichereinheit 570 gekoppelt ist. Die L2 Cache-Einheit 576 kann an einen oder mehrere andere Cache-Level und schließlich an einen Hauptspeicher gekoppelt sein.
In einer bestimmten Ausführungsform führt der Daten-Prefetcher 580 spekulativ ein Laden/Vorabholen von Daten zur DCU 574 durch automatische Vorhersage durch, welche Daten ein Programm konsumieren wird. Prefetching (vorab Abrufen) kann sich auf ein Überführen von Daten, die an einer Speicherstelle (z.B. Position) einer Speicherhierarchie (z.B. Caches oder Speicher tieferen Levels) gespeichert sind, zu einer Speicherstelle höheren Levels beziehen, die dem Prozessor näher ist (z.B. zu geringerer Zugriffslatenz führt), bevor die Daten tatsächlich vom Prozessor verlangt werden. Im Speziellen kann sich Prefetching auf das frühe Abrufen von Daten aus einem der Cache/Speicher tieferen Levels zu einem Daten-Cache und/oder einem Prefetch-Puffer beziehen, bevor der Prozessor einen Bedarf an den speziellen zurückgesendeten Daten meldet.
Der Prozessorkern 500 kann einen oder mehrere Befehlssätze unterstützen (z.B. den x86 Befehlssatz (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt wurden); den MIPS Befehlssatz von Imagination Technologies of Kings Langley, Hertfordshire, UK; den ARM Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings of Sunnyvale, CA).
Es sollte klar sein, dass der Kern ein Multithreading (Ausführung von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen und dies auf unterschiedliche Weisen ausführen kann, einschließlich Zeitscheiben-Multithreading, simultanen Multithreading (wo ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, für die der physische Kern ein simultanes Multithreading ausführt) oder einer Kombination davon (z.B. Abrufen und Decodieren in Zeitscheiben und danach simultanes Multithreading, wie in der Intel® Hyperthreading Technologie).
Während eine Registerumbenennung im Zusammenhang mit einer Ausführung in einer anderen Reihenfolge beschrieben ist, sollte klar sein, dass eine Registerumbenennung in einer Architektur in der ursprünglichen Reihenfolge durchgeführt werden kann. Während die gezeigte Ausführungsform des Prozessors auch eine separate Befehls- und Daten-Cache-Einheit und eine gemeinsame L2 Cache-Einheit enthält, können alternative Ausführungsformen einen einzelnen internen Cache sowohl für Befehle wie auch Daten enthalten, wie zum Beispiel, einen Level 1 (L1) internen Cache oder mehrere Level interner Caches. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Cache und einem externen Cache, der extern zum Kern und/oder zum Prozessor ist, enthalten. Alternativ können alle Caches extern zum Kern und/oder zum Prozessor sein.
5B ist ein Blockdiagramm, das eine Pipeline in ursprünglicher Reihenfolge und eine Registerumbenennungsstufe, Ausgabe-/Ausführungs-Pipeline in einer anderen Reihenfolge, die durch den Prozessorkern 500 von 5A implementiert werden, gemäß einigen Ausführungsformen der Offenbarung zeigt. Die Kästen in Volllinie in 5B zeigen eine Pipeline in ursprünglicher Reihenfolge, während die Kästen in gestrichelter Linie eine Registerumbenennungs-, Ausgabe-/Ausführungs-Pipeline in einer anderen Reihenfolge zeigen. In 5B enthält eine Prozessor-Pipeline 590 eine Abrufstufe 502, eine Längendecodierstufe 504, eine Decodierstufe 506, eine Zuordnungsstufe 508, eine Umbenennungsstufe 510, eine Planungs- (auch bekannt als Versand- oder Ausgabe-) Stufe 512, eine Registerlese-/Speicherlesestufe 514, eine Ausführungsstufe 516, eine Zurückschreib-/Speicherschreibstufe 518, eine Ausnahmehandhabungsstufe 522 und eine Commit-Stufe 524. In einigen Ausführungsformen kann die Reihenfolge von Stufen 502-524 anders als gezeigt sein und ist nicht auf die spezielle, in 5B dargestellte Reihung beschränkt.
6 zeigt ein Blockdiagramm der Mikroarchitektur für einen Prozessor 600, der logische Schaltungen enthält, die das System 100 und/oder das System 200 von 2 ausführen können. In einigen Ausführungsformen kann ein Befehl gemäß einer Ausführungsform implementiert werden, um Datenelemente mit Größen von Byte, Wort, Doppelwort, Quadword usw., wie auch Datenarten, wie Einzel- und Doppelpräzisions-Ganzzahl- und -Gleitkommadatenarten zu bearbeiten. In einer bestimmten Ausführungsform ist das Frontend 601 in der ursprünglichen Reihenfolge ein Teil des Prozessors 600, der auszuführende Befehlen abruft und sie zur späteren Verwendung in der Prozessor-Pipeline aufbereitet.
Das Frontend 601 kann mehrere Einheiten enthalten. In einer bestimmten Ausführungsform ruft der Befehls-Prefetcher 616 Befehle aus dem Speicher ab und speist sie in einen Befehlsdecodierer 618, der diese seinerseits decodiert oder interpretiert. Zum Beispiel decodiert der Decodierer in einer bestimmten Ausführungsform einen empfangenen Befehl in eine oder mehrere Operationen, die als „Mikrobefehle“ oder „Mikrooperationen“ bezeichnet werden (auch als Mikro-op oder uops bezeichnet), die die Maschine ausführen kann. In anderen Ausführungsformen zergliedert der Decodierer den Befehl in einen Opcode und entsprechende Daten und Steuerfelder, die in der Mikroarchitektur zur Durchführung von Operationen gemäß einer Ausführungsform verwendet werden. In einer bestimmten Ausführungsform nimmt der Trace-Cache 630 decodierte uops auf und fügt sie in programmgereihte Sequenzen oder Traces in der uop Warteschlange 634 zur Ausführung zusammen. Wenn der Trace-Cache 630 auf einen komplexen Befehl trifft, kann der Mikrocode ROM (oder RAM) 632 die zur Vollendung der Operation erforderlichen uops bereitstellen.
Einige Befehle werden in eine einzige Mikro-op umgewandelt, während andere mehrere Mikro-ops zur Vollendung der vollständigen Operation benötigen. Falls in einer bestimmten Ausführungsform mehr als vier Mikro-ops zur Vollendung eines Befehls erforderlich sind, greift der Decodierer 618 auf den Mikrocode ROM 632 zu, um den Befehl auszuführen. Für eine Ausführungsform kann ein Befehl in eine geringe Anzahl von Mikro-ops zur Verarbeitung beim Befehlsdecodierer 618 decodiert werden. In einer anderen Ausführungsform kann ein Befehl im Mikrocode ROM 632 gespeichert werden, sollte eine Anzahl von Mikro-ops zum Erledigen der Operation erforderlich sein. Der Trace-Cache 630 bezieht sich auf eine Eintrittspunkt- programmierbare logische Anordnung (PLA) zum Ermitteln eines korrekten Mikrobefehlszeigers zum Auslesen der Mikrocodesequenzen aus dem Mikrocode ROM 632, um einen oder mehrere Befehl(e) gemäß einer Ausführungsform zu vollenden. Sobald der Mikrocode ROM 632 das Sequenzieren von Mikro-ops für einen Befehl beendet hat, nimmt das Frontend 601 der Maschine das Abrufen von Mikro-ops aus dem Trace-Cache 630 wieder auf.
Die Ausführungsmaschine in einer anderen Reihenfolge 603 befindet sich dort, wo die Befehle für die Ausführung aufbereitet werden. Die Ausführungslogik in einer anderen Reihenfolge hat eine Reihe von Zwischenspeichern zum Glätten und Neureihen des Flusses von Befehlen, um Leistung zu optimieren, während sie die Pipeline hinunterlaufen und zur Ausführung geplant werden. Die Zuordnungslogik ordnet den Maschinenzwischenspeicher und Ressourcen zu, die jede uop zur Ausführung benötigt. Die Registerumbenennungslogik benennt Logikregister auf Einträge in einer Registerdatei um. Der Zuordner ordnet auch vor den Befehlsplanern einen Eintrag für jede uop in einer der zwei uop Warteschlangen zu, einen für Speicheroperationen und einen für Nicht-Speicheroperationen: Speicherplaner, schneller Planer 602, langsamer/allgemeiner Gleitkommaplaner 604 und einfacher Gleitkommaplaner 606. Die uop Planer 602, 604, 606 stellen auf Grundlage der Bereitschaft ihrer abhängigen Eingaberegister-Operandquellen und der Verfügbarkeit der Ausführungsressourcen, die die uops zur Vollendung der Operation benötigen, fest, wann eine uop zur Ausführung bereit ist. Der schnelle Planer 602 einer Ausführungsform kann jede Hälfte des Haupttaktzyklus planen, während die anderen Planer nur einmal pro Hauptprozessortaktzyklus planen können. Die Planer schlichten die Versandports zur Planung der uops zur Ausführung.
Die Registerdateien 608, 610 befinden sich zwischen den Planern 602, 604, 606 und den Ausführungseinheiten 612, 614, 616, 618, 620,622, 624 im Ausführung Block 611. Es ist eine separate Registerdatei 608, 610 für Ganzzahl- bzw. Gleitkomma-Operationen vorhanden. Jede Registerdatei 608, 610 einer Ausführungsform enthält auch ein Umgehungsnetzwerk, das soeben fertiggestellte Ergebnisse, die noch nicht in die Registerdatei geschrieben wurden, zu neuen abhängigen uops umleiten oder weiterleiten kann. Die Ganzzahl-Registerdatei 608 und die Gleitkomma-Registerdatei 610 sind auch imstande, Daten miteinander zu kommunizieren. Für eine Ausführungsform wird die Ganzzahl-Registerdatei 608 in zwei separate Registerdateien geteilt, eine Registerdatei für die 32 niederwertigen Bits von Daten und eine zweite Registerdatei für die 32 hochwertigen Bits von Daten. Die Gleitkomma-Registerdatei 610 einer Ausführungsform hat 128 Bit breite Einträge, da Gleitkomma-Befehle typischerweise Operanden mit einer Breite von 64 bis 128 Bits haben.
Der Ausführungsblock 611 beinhaltet die Ausführungseinheiten 612, 614, 616, 618, 620, 622, 624, wo die Befehle tatsächlich ausgeführt werden. Dieser Abschnitt enthält die Registerdateien 608, 610, die die Ganzzahl- und Gleitkomma-Datenoperandwerte speichern, die die Mikrobefehle zur Ausführung benötigen. Der Prozessor 600 einer Ausführungsform besteht aus einer Anzahl von Ausführungseinheiten: Adressengenerierungseinheit (AGU) 612, AGU 614, schnelle ALU 616, schnelle ALU 618, langsame ALU 620, Gleitkomma ALU 622, Gleitkommabewegungseinheit 614. Für eine Ausführungsform führen die Gleitkomma-Ausführungsblöcke 622, 624, Gleitkomma, MMX, SIMD und SSE oder andere Operationen aus. Die Gleitkomma ALU 622 einer Ausführungsform enthält einen 64-Bit-mal-64-Bit Gleitkommateiler zur Ausführung von Divisions-, Quadratwurzel- und restlicher Mikro-ops. Für Ausführungsformen der vorliegenden Offenbarung können Befehle, die einen Gleitkommawert beinhalten, mit der Gleitkomma-Hardware gehandhabt werden.
In einer bestimmten Ausführungsform gehen die ALU Operationen zu Hochgeschwindigkeits-ALU Ausführungseinheiten 616, 618. Die schnellen ALUs 616, 618 einer Ausführungsform können schnelle Operationen mit einer effektiven Latenz eines halben Taktzyklus ausführen. Für eine Ausführungsform gehen die komplexesten GanzzahlOperationen zur langsamen ALU 620, da die langsame ALU 620 Ganzzahl-Ausführungs-Hardware für Operationen der langen Latenzart enthält, wie eine Multiplikator-, Verschiebungs-, Flag-Logik- und Abzweigungsverarbeitung. Speicherlade-/Speicheroperationen werden durch die AGUs 612, 614 ausgeführt. Für eine Ausführungsform sind die Ganzzahl ALUs 616, 618, 620 im Zusammenhang mit der Durchführung von Ganzzahloperationen an 64 Bit-Datenoperanden beschrieben. In alternativen Ausführungsformen können die ALUs 616, 618, 620 implementiert werden, um eine Reihe von Daten-Bits zu unterstützen, einschließlich 16, 32, 128, 256 usw. Ebenso können die Gleitkommaeinheiten 622, 624 implementiert werden, um einen Bereich von Operanden mit Bits diverser Breiten zu unterstützen. Für eine Ausführungsform können die Gleitkommaeinheiten 622, 624 128 Bits breit gepackte Datenoperanden in Verbindung mit SIMD- und Multimedia-Befehlen bearbeiten.
In einer bestimmten Ausführungsform versenden die uops Planer 602, 604, 606 abhängige Operationen, bevor die Stammlast mit der Ausführung fertig ist. Da uops im Prozessor 600 spekulativ geplant und ausgeführt werden, enthält der Prozessor 600 auch eine Logik zur Behandlung von Speicherfehlschlägen. Falls eine Datenlast im Daten-Cache fehlschlägt, können abhängige Operationen im Flug in der Pipeline vorhanden sein, die den Planer mit temporär unrichtigen Daten zurücklassen. Ein Wiedergabemechanismus verfolgt Befehle, die unrichtige Daten verwenden, und führt sie erneut aus. Nur die abhängigen Operationen müssen wiedergegeben werden und die unabhängigen können vollendet werden. Die Planer und Wiedergabemechanismus einer Ausführungsform eines Prozessors sind auch gestaltet, Befehlssequenzen für Testzeichenkettenvergleichsoperationen einzufangen.
Der Prozessor 600 enthält auch eine Logik zum Implementieren einer Kompressions-/Dekompressionsoptimierung in Solid-State-Speichervorrichtungen gemäß einer Ausführungsform. In einer bestimmten Ausführungsform kann der Ausführungsblock 611 des Prozessors 600 eine MCU 115 zur Durchführung einer Kompressions-/Dekompressionsoptimierung in Solid-State-Speichervorrichtungen gemäß der vorliegenden Beschreibung enthalten.
Der Begriff „Register“ kann sich auf bordeigene Prozessorspeicherstellen beziehen, die als Teil von Befehlen zur Identifizierung von Operanden verwendet werden. Mit anderen Worten, Register können jene sein, die von außerhalb des Prozessors (aus einer Perspektive des Programmierers) nutzbar sind. Die Register einer Ausführungsform sollten jedoch nicht in der Bedeutung auf eine bestimmte Art von Schaltung beschränkt sein. Vielmehr ist ein Register einer Ausführungsform imstande, Daten zu speichern und bereitzustellen und die hier beschriebenen Funktionen durchzuführen. Die hier beschriebenen Register können durch einen Schaltkreis in einem Prozessor unter Verwendung einer beliebigen Anzahl unterschiedlicher Techniken implementiert werden, wie zweckbestimmte physische Register, dynamisch zugeordnete physische Register unter Verwendung einer Registerumbenennung, Kombinationen zweckbestimmter und dynamisch zugeordneter physischer Register usw. In einer bestimmten Ausführungsform speichern Ganzzahl-Register zweiunddreißig Bit Ganzzahldaten. Eine Registerdatei einer Ausführungsform beinhaltet auch acht Multimedia-SIMD-Register für gepackte Daten.
Für die vorliegenden Diskussionen wird davon ausgegangen, dass die Register Datenregister sind, die zum Halten gepackter Daten gestaltet sind, wie 64 Bits breite MMX™ Register (in einigen Fällen auch als ‚mm‘ Register bezeichnet) in Mikroprozessoren, die mit der MMX-Technologie von Intel Corporation in Santa Clara, Kalifornien, freigegeben werden. Diese MMX-Register, die sowohl in der Form einer Ganzzahl wie auch eines Gleitkommas verfügbar sind, können mit gepackten Datenelementen arbeiten, die SIMD- und SSE-Befehle begleiten. Ebenso kann auch ein 128 Bits breites XMM-Register, das sich auf eine SSE2-, SSE3-, SSE4- oder höhere (allgemein als „SSEx“ bezeichnet) Technologie bezieht, zum Halten solcher gepackten Datenoperanden verwendet werden. In einer bestimmten Ausführungsform müssen die Register beim Speichern gepackter Daten und Ganzzahldaten nicht zwischen den zwei Datenarten unterscheiden. In einer bestimmten Ausführungsform sind Ganzzahl und Gleitkomma entweder in derselben Registerdatei oder in unterschiedlichen Registerdateien enthalten. Ferner können in einer bestimmten Ausführungsform Gleitkomma- und Ganzzahldaten in unterschiedlichen Registern oder in denselben Registern gespeichert sein.
Ausführungsformen können in vielen unterschiedlichen Systemarten implementiert sein. Unter Bezugnahme nun auf 7, ist ein Blockdiagramm eines Multiprozessorsystems 700 gemäß einer Implementierung dargestellt. Wie in 7 dargestellt, ist das Multiprozessorsystem 700 ein Punkt-zu-Punkt-Verbindungssystem und enthält einen ersten Prozessor 770 und einen zweiten Prozessor 780, die über eine Punkt-zu-Punkt-Verbindung 750 gekoppelt sind. Wie in 7 dargestellt, kann jeder der Prozessoren 770 und 780 ein Multikemprozessor sein, enthaltend erste und zweite Prozessorkerne (d.h., Prozessorkerne 774a und 774b und Prozessorkerne 784a und 784b), obwohl möglicherweise viel mehr Kerne in den Prozessoren vorhanden sein können. Die Prozessoren können jeweils eine hybride Schreibmoduslogik gemäß einer vorliegenden Ausführungsform enthalten. Die Ausführungsformen der Seitenhinzufügungen und Inhaltskopie können im Prozessor 770, Prozessor 780 oder beiden implementiert werden.
Während zwei Prozessoren 770, 780 dargestellt sind, ist klar, dass der Umfang der vorliegenden Offenbarung nicht darauf beschränkt ist. In anderen Implementierungen können eine oder mehrere zusätzliche Prozessoren in einem bestimmten Prozessor vorhanden sein.
Die Prozessoren 770 und 780 enthalten in der Darstellung integrierte Speichersteuereinheiten 772 bzw. 782. Der Prozessor 770 enthält auch als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt- (P-P) Schnittstellen 776 und 788; auf ähnliche Weise enthält der zweite Prozessor 780 P-P-Schnittstellen 786 und 788. Die Prozessoren 770, 780 können Informationen über eine Punkt-zu-Punkt- (P-P) Schnittstelle 750 unter Verwendung von P-P Schnittstellenschaltungen 778, 788 austauschen. Wie in 7 dargestellt, koppeln IMCs 772 und 782 die Prozessoren an jeweilige Speicher, nämlich einen Speicher 732 und einen Speicher 734, die Teile des Hauptspeichers sein können, der örtlich an die jeweiligen Prozessoren angehängt ist.
Die Prozessoren 770, 780 können Informationen mit einem Chipset 790 über einzelne P-P-Schnittstellen 752, 754 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 776, 794, 786, 798 austauschen. Der Chipset 790 kann auch mit einer Hochleistungsgrafikschaltung 738 Informationen über eine Hochleistungsgrafikschnittstelle 739 austauschen.
Ein gemeinsamer Cache (nicht dargestellt) kann entweder in einem Prozessor oder außerhalb beider Prozessoren enthalten sein, aber dennoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass örtliche Cache-Informationen eines Prozessors oder beider Prozessoren im gemeinsamen Cache gespeichert werden können, wenn ein Prozessor in einen stromarmen Modus gebracht wird.
Der Chipset 790 kann über eine Schnittstelle 796 an einen ersten Bus 716 gekoppelt sein. In einer bestimmten Ausführungsform kann der erste Bus 716 ein Peripheral Component Interconnect (periphere Komponentenverbindung, PCI) Bus oder ein Bus wie ein PCI-Expressbus oder ein anderer I/O-Verbindungsbus der dritten Generation sein, obwohl der Umfang der vorliegenden Offenbarung nicht darauf beschränkt ist.
Wie in 7 dargestellt, können diverse I/O-Vorrichtungen 714 an den ersten Bus 716 gekoppelt sein, gemeinsam mit einer Busbrücke 718, die den ersten Bus 716 an einen zweiten Bus 720 koppelt. In einer bestimmten Ausführungsform kann der zweite Bus 720 ein Low Pin Count (LPC) Bus sein. Diverse Vorrichtungen können in einer bestimmten Ausführungsform an den zweiten Bus 720 gekoppelt sein, einschließlich zum Beispiel einer Tastatur und/oder Maus 722, Kommunikationsvorrichtungen 727 und einer Speichereinheit 728 wie ein Festplattenlaufwerk oder eine andere Massenspeichervorrichtung, die Befehle/Code und Daten 730 enthalten kann. Ferner kann ein Audio-I/O 724 an den zweiten Bus 720 gekoppelt sein. Es ist zu beachten, dass andere Architekturen möglich sind. Zum Beispiel kann ein System anstelle der Punkt-zu-Punkt-Architektur von 7 einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.
Unter Bezugnahme nun auf 8, ist ein Blockdiagramm eines dritten Systems 800 gemäß einer Ausführungsform der vorliegenden Offenbarung dargestellt. Gleiche Elemente in 7 und 8 tragen gleiche Bezugszeichen und gewisse Aspekte von 7 wurden in 7 ausgelassen, um eine Verschleierung anderer Aspekte von 8 zu vermeiden.
8 zeigt, dass die Prozessoren 870, 880 einen integrierten Speicher und eine I/O Steuerlogik („CL“) 872 bzw. 882 enthalten können. Für zumindest eine Ausführungsform kann die CL 872, 882 integrierte Speichersteuereinheiten wie hier beschrieben enthalten. Zusätzlich können die CL 872, 882 auch eine I/O-Steuerlogik enthalten. 8 zeigt, dass die Speicher 832, 834 an die CL 872, 882 gekoppelt sind und dass I/O-Vorrichtungen 814 an die Steuerlogik 872, 882 gekoppelt sind. Legacy-I/O-Vorrichtungen 815 sind an den Chipset 890 gekoppelt. Die Ausführungsformen der Seitenhinzufügungen und der Inhaltskopie können in Prozessor 870, Prozessor 880 oder beiden implementiert sein.
9 ist ein beispielhaftes System-on-Chip (SoC) 900, das einen oder mehrere der Kerne 902 enthalten kann. Andere Systemdesigns und -konfigurationen, die nach dem Stand der Technik für Laptops, Desktops, in der Hand gehaltene PCs, persönliche digitale Assistenten, Engineering Workstations, Server, Netzwerkvorrichtungen, Netzwerk-Hubs, Schalter, eingebettete Prozessors, Digitalsignalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top Boxes, Mikrosteuerungen, Mobiltelefone, tragbare Mediaplayer, in der Hand gehaltene Vorrichtungen und diverse andere elektronische Vorrichtungen bekannt sind, sind auch geeignet. Im Allgemeinen ist eine ungeheure Vielfalt an Systemen oder elektronischen Vorrichtungen allgemein geeignet, die einen Prozessor und/oder andere Ausführungslogik wie hier offenbart beinhalten können.
9 ist ein Blockdiagramm eines SoC 900 gemäß einer Ausführungsform der vorliegenden Offenbarung. Kästen in gestrichelten Linien sind Merkmale auf höher entwickelten SoCs. In 9 sind eine oder mehrere Verbindungseinheit(en) 902 gekoppelt an: einen Anwendungsprozessor 917, der einen Satz aus einem oder mehreren Kern(en) 902A-N und gemeinsame(r/n) Cache-Einheit(en) 906 enthält; eine Systemagenteinheit 910; eine oder mehrere Bussteuerungseinheit(en)) 916; eine oder mehrere integrierte Speichersteuereinheit(en) 914; einen Satz aus einem oder mehreren Medienprozessor(en) 920, die eine integrierte Grafiklogik 908, einen Bildprozessor 924 zum Bereitstellen einer Stand- und/oder Videokamerafunktionalität, einen Audioprozessor 926 zum Bereitstellen einer Hardware-Audiobeschleunigung und einen Videoprozessor 928 zum Bereitstellen einer Video-Codierungs-/Decodierungsbeschleunigung enthalten können; eine statische Direktzugriffsspeicher- (SRAM) Einheit 930; eine Direktspeicherzugriffs- (DMA) Einheit 932; und eine Anzeigeeinheit 940 zur Kopplung an eine oder mehrere externe Anzeige(n). Die Ausführungsformen der Seitenhinzufügungen und Inhaltskopie können im SoC 900 implementiert sein.
Unter anschließender Betrachtung von 10 ist eine Ausführungsform eines System-on-Chip- (SoC) Designs gemäß Ausführungsformen der Offenbarung dargestellt. Als ein veranschaulichendes Beispiel ist das SoC 1000 in einem Benutzergerät (UE) enthalten. In einer bestimmten Ausführungsform bezieht sich das UE auf jede Vorrichtung, die von einem Endbenutzer zum Kommunizieren verwendet wird, wie ein in der Hand gehaltenes Telefon, ein Smartphone, ein Tablet, ein ultradünnes Notebook, ein Notebook mit Breitbandadapter oder jede andere ähnliche Kommunikationsvorrichtung. Ein UE kann mit einer Basisstation oder einem Knoten verbunden sein, die in ihrer Art einer Mobilstation (MS) in einem GSM-Netzwerk entsprechen können. Die Ausführungsformen der Seitenhinzufügungen und Inhaltskopie können im SoC 1000 implementiert sein.
Hier enthält das SoC 1000 2 Kerne - 1006 und 1007. Ähnlich wie in der obenstehenden Diskussion können die Kerne 1006 und 1007 einer Instruction Set Architecture entsprechen, wie einem Prozessor mit dem Intel® Architecture Core™, einem Advanced Micro Devices, Inc. (AMD) Prozessor, einem MIPS-basierten Prozessor, einem ARM-basierten Prozessordesign, oder einem Kunden davon, wie auch deren Lizenznehmer oder Adoptoren. Die Kerne 1006 und 1007 sind an eine Cache-Steuerung 1008 gekoppelt, die mit der Bus Schnittstelleneinheit 1009 und dem L2 Cache 1010 verknüpft ist, um mit anderen Teilen des SOC 1000 zu kommunizieren. Die Verbindung 1011 enthält eine On-Chip-Verbindung, wie eine IOSF, AMBA oder andere oben besprochene Verbindungen, die einen oder mehrere Aspekt(e) der beschriebenen Offenbarung implementieren können.
Verbindung 1011 stellt Kommunikationskanäle zu den anderen Komponenten, wie einem Teilnehmeridentitätsmodul (Subscriber Identity Module, SIM) 1030, bereit, um eine Schnittstelle mit einer SIM-Karte zu bilden, einem Boot-ROM 1035, um einen Boot-Code für eine Ausführung durch Kerne 1006 und 1007 zu halten, um das SoC 1000 zu initialisieren und zu booten, einer SDRAM-Steuerung 1040, um eine Schnittstelle mit einem externen Speicher (z.B. DRAM 1060) zu bilden, einer Flash-Steuerung 1045, um eine Schnittstelle mit einem nicht flüchtigen Speicher (z.B. Flash 1065) zu bilden, einer peripheren Steuerung 1050 (z.B. seriellen peripheren Schnittstelle), um eine Schnittstelle mit Peripheriegeräten zu bilden, Video-Codecs 1020 und einer Videoschnittstelle 1025, um einen Eingang (z.B. durch Berührung ermöglichten Eingang) anzuzeigen und zu empfangen, einer GPU 1015, um grafikbezogene Berechnungen durchzuführen usw. Jede dieser Schnittstellen kann Aspekte der hier beschriebenen Ausführungsformen beinhalten.
Zusätzlich zeigt das System Peripheriegeräte zur Kommunikation, wie ein Bluetooth-Modul 1070, 3G-Modem 1075, GPS 1080 und Wi-Fi 1085. Es ist festzuhalten, dass ein UE, wie oben angemerkt, einen Funk zur Kommunikation enthält. Infolgedessen brauchen diese peripheren Kommunikationsmodule gar nicht enthalten sein. In einem UE sollte jedoch eine gewisse Form eines Funks zur externen Kommunikation enthalten sein.
11 zeigt eine schematische Darstellung einer Maschine in der beispielhaften Form eines Rechensystems 1100, in dem ein Satz von Befehlen, der die Maschine veranlasst, eine oder mehrere der hier besprochenen Methodologien durchzuführen, ausgeführt werden kann. In alternativen Ausführungsformen kann die Maschine mit anderen Maschinen in einem LAN, einem Intranet, einem Extranet oder dem Internet verbunden (z.B. vernetzt) sein. Die Maschine kann in der Kapazität eines Servers oder einer Client-Vorrichtung in einer Client-Server-Netzwerkumgebung oder als Peer-Maschine in einer Peer-zu-Peer- (oder verteilten) Netzwerkumgebung arbeiten. Die Maschine kann ein Personal Computer (PC), ein Tablet PC, eine Set-Top Box (STB), ein persönlicher digitaler Assistent (PDA), ein Mobiltelefon, eine Web Appliance, ein Server, ein Netzwerkrouter, ein Schalter oder eine Brücke oder jede Maschine sein, die imstande ist, einen Satz von Befehlen (der Reihe nach oder anders) auszuführen, die Aktionen spezifizieren, die von dieser Maschine ergriffen werden. Während ferner nur eine einzige Maschine dargestellt ist, soll der Begriff „Maschine“ auch so verstanden werden, dass er eine Ansammlung von Maschinen enthält, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Befehlen ausführen, um eine oder mehrere der hier besprochenen Methodologien durchzuführen. Die Ausführungsformen, die das System 100 von 1 oder das System 200 von 2 ausführen, können im Rechensystem 1100 implementiert sein.
Das Rechensystem 1100 enthält eine Verarbeitungsvorrichtung 1102, einen Hauptspeicher 1104 (z.B. einen Flash-Speicher, einen dynamischen Direktzugriffsspeicher (DRAM) (wie synchronen DRAM (SDRAM) oder DRAM (RDRAM) usw.), einen statischen Speicher 1106 (z.B. Flash-Speicher, statischen Direktzugriffsspeicher (SRAM) usw.) und eine Datenspeichervorrichtung 1116, die über einen Bus 1108 miteinander kommunizieren.
Die Verarbeitungsvorrichtung 1102 stellt eine oder mehrere Allzweck-Verarbeitungsvorrichtungen wie einen Mikroprozessor, eine zentrale Verarbeitungseinheit oder dergleichen bereit. Insbesondere kann die Verarbeitungsvorrichtung ein Mikroprozessor mit komplexer Befehlssatzberechnung (CISC), ein Mikroprozessor mit beschränktem Befehlssatzcomputer (RISC), ein Mikroprozessor mit sehr langem Befehlswort (VLIW) oder ein Prozessor sein, der andere Befehlssätze implementiert oder Prozessoren, die eine Kombination von Befehlssätzen implementieren. Die Verarbeitungsvorrichtung 1102 kann auch eine oder mehrere Spezialzweck-Verarbeitungsvorrichtungen wie eine anwendungsspezifische integrierte Schaltung (ASIC), eine feldprogrammierbares Gate-Array (FPGA), ein Digitalsignalprozessor (DSP), ein Netzwerkprozessor oder dergleichen sein. In einer bestimmten Ausführungsform kann die Verarbeitungsvorrichtung 1102 einen oder mehrere Prozessorkern(e) enthalten. Die Verarbeitungsvorrichtung 1102 ist konfiguriert, die Verarbeitungslogik oder Befehle 1126 zur Durchführung der hier besprochenen Operationen durchzuführen.
In einer bestimmten Ausführungsform kann die Verarbeitungsvorrichtung 1102 die Verarbeitungsvorrichtung 100 von 1 sein. Alternativ kann das Rechensystem 1100 andere Komponenten wie hier beschrieben enthalten. Es sollte klar sein, dass der Kern ein Multithreading (Ausführung von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen und dies auf unterschiedliche Weisen ausführen kann, enthaltend ein Zeitscheiben-Multithreading, simultanes Multithreading (wo ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, für die der physische Kern ein simultanes Multithreading ausführt) oder eine Kombination davon (z.B. Abrufen und Decodieren in Zeitscheiben und danach simultanes Multithreading, wie in der Intel® Hyperthreading Technologie).
Das Rechensystem 1100 kann ferner eine Netzwerkschnittstellenvorrichtung 1118 enthalten, die kommunizierbar an ein Netzwerk 1119 gekoppelt ist. Das Rechensystem 1100 kann auch eine Videoanzeigevorrichtung 1110 (z.B. eine Flüssigkristallanzeige (LCD) oder eine Kathodenstrahlröhre (CRT)), eine alphanumerische Eingabevorrichtung 1112 (z.B. eine Tastatur), eine Cursor-Steuervorrichtung 1114 (z.B. eine Maus), eine Signalgenerierungsvorrichtung 1120 (z.B. einen Lautsprecher) oder andere periphere Vorrichtungen enthalten. Ferner kann ein Rechensystem 1100 eine Grafikverarbeitungseinheit 1122, eine Videoverarbeitungseinheit 1128 und eine Audioverarbeitungseinheit 1132 enthalten. In einer anderen Ausführungsform kann das Rechensystem 1100 einen Chipset (nicht dargestellt) enthalten, was sich auf eine Gruppe integrierter Schaltungen oder Chips bezieht, die dazu gestaltet sind, mit der Verarbeitungsvorrichtung 1102 zu arbeiten und Kommunikationen zwischen der Verarbeitungsvorrichtung 1102 und externen Vorrichtungen zu steuern. Zum Beispiel kann der Chipset ein Satz von Chips auf einer Hauptplatine sein, der die Verarbeitungsvorrichtung 1102 mit Vorrichtungen sehr hoher Geschwindigkeit verbindet, wie Hauptspeicher 1104 und Grafiksteuerungen, wie auch die Verarbeitungsvorrichtung 1102 mit peripheren Bussen geringerer Geschwindigkeit von Peripheriegeräten, wie USB, PCI oder ISA Bussen, verbindet.
Die Datenspeichervorrichtung 1116 kann ein computerlesbares Speichermedium 1124 enthalten, auf dem Software 1126 gespeichert ist, die eine oder mehrere der Methodologie(n) von hier beschriebenen Funktionen verkörpert. Die Software 1126 kann auch vollständig oder zumindest teilweise im Hauptspeicher 1104 als Befehle 1126 und/oder in der Verarbeitungsvorrichtung 1102 als Verarbeitungslogik während deren Ausführung durch das Rechensystem 1100 liegen; wobei der Hauptspeicher 1104 und die Verarbeitungsvorrichtung 1102 auch computerlesbare Speichermedien darstellen.
Das computerlesbare Speichermedium 1124 kann auch zum Speichern von Befehlen 1126 unter Verwendung der Verarbeitungsvorrichtung 1102, wie in Bezug auf 1-4 beschrieben, und/oder einer Software-Bibliothek, die Methoden enthält, die die obengenannten Anwendungen aufrufen, verwendet werden. Während das computerlesbare Speichermedium 1124 in einer beispielhaften Ausführungsform als einzelnes Medium dargestellt ist, sollte der Begriff „computerlesbares Medium“ so verstanden werden, dass er ein einzelnes Medium oder mehrere Medien enthält (z.B. eine zentralisierte oder verteilte Datenbank und/oder zugehörige Caches und Server), die einen Satz oder mehrere Sätze von Befehlen speichern. Der Begriff „computerlesbares Speichermedium“ soll auch so verstanden werden, dass er jedes Medium enthält, das imstande ist, einen Satz von Befehlen zur Ausführung durch die Maschine zu speichern, zu codieren oder auszuführen, um eine oder mehrere der Methodologien der vorliegenden Ausführungsformen durchzuführen. Der Begriff „computerlesbares Speichermedium“ soll daher so verstanden werden, dass er Solid-State-Speicher und optische und magnetische Medien enthält, ohne aber darauf beschränkt zu sein.
Die folgenden Beispiele betreffen weitere Ausführungsformen.
Beispiel 1 ist ein Prozessor, umfassend: 1) einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten eines Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; 2) einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und 3) eine Dekompressionsmaschine zum Generieren von zumindest zwei Ausgängen, die Fehlerprüfungen des Eingangsstroms angeben, wenn der Eingangsstrom komprimiert wird, wobei der Prozessorkern zweite Befehle ausführen soll, um einen der zumindest zwei Ausgänge zu generieren.
In Beispiel 2, der Prozessor von Beispiel 1, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
In Beispiel 3, der Prozessor von Beispiel 1, wobei der Prozessorkern die zweiten Befehle ausführen soll, um eine inverse Operation durchzuführen, die einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen generiert, ferner umfassend einen Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms.
In Beispiel 4, der Prozessor von Beispiel 1, ferner umfassend einen Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes.
In Beispiel 5, der Prozessor von Beispielen 1-4, wobei die Dekompressionsmaschine umfasst: a) einen Hardware-Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; und b) einen Komparator zum Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang und zum Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
In Beispiel 6, der Prozessor von Beispielen 1-5, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist.
In Beispiel 7, der Prozessor von Beispiel 6, wobei der Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
Diverse Ausführungsformen können unterschiedliche Kombinationen der oben beschriebenen Strukturmerkmale haben. Beispielsweise können alle optionalen Merkmale des oben beschriebenen Rechensystems auch in Bezug auf das hier beschriebene Verfahren oder den hier beschriebenen Prozess implementiert sein und spezielle Einzelheiten in den Beispielen können anderswo in einer oder mehreren Ausführungsform(en) verwendet werden.
Beispiel 8 ist eine Vorrichtung, umfassend: 1) einen Kompressor zum Komprimieren eines Eingangsstroms von Daten, wobei der Kompressor Folgendes umfasst: a) einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten des Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; b) einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und 2) eine Dekompressionsmaschine, umfassend: a) den Prozessorkern zum Ausführen zweiter Befehle als inverser String Matcher, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren; und b) einen ersten Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer ersten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms.
In Beispiel 9, die Vorrichtung von Beispiel 8, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
In Beispiel 10, die Vorrichtung von Beispielen 9-10, wobei der Kompressor ferner einen Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes umfasst.
In Beispiel 11, die Vorrichtung von Beispiel 10, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist, und wobei der Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
In Beispiel 12, die Vorrichtung von Beispielen 9-11, wobei die Dekompressionsmaschine ferner umfasst: a) einen Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; und b) einen Komparator zum Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang und zum Generieren einer zweiten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
In Beispiel 13, die Vorrichtung von Beispiel 12, wobei die erste Störung oder Ausnahme eine Maschinenprüfungsarchitektur(MCA)-Störung umfasst, die von der zweiten Störung oder Ausnahme unterscheidbar ist, und wobei der zumindest eine Prozessor ferner dient zum: a) Verfolgen, in einem Protokoll, einer ersten Frequenz des Generierens der ersten Störung oder Ausnahme; und b) Verfolgen, in dem Protokoll, einer zweiten Frequenz des Generierens der zweiten Störung oder Ausnahme.
Diverse Ausführungsformen können unterschiedliche Kombinationen der oben beschriebenen Strukturmerkmale haben. Beispielsweise können alle optionalen Merkmale der oben beschriebenen Prozessoren und Verfahren auch in Bezug auf ein hier beschriebenes System implementiert sein und spezielle Einzelheiten in den Beispielen können anderswo in einer oder mehreren Ausführungsform(en) verwendet werden.
Beispiel 14 ist ein Fehlerprüfungs-, Datenkompressionssystem, umfassend: 1) eine Kompressionsmaschine zum Komprimieren eines Eingangsstroms von Daten, wobei die Kompressionsmaschine Folgendes umfasst: a) einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten des Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; b) einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und c) einen Hardware Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes; und 2) eine Dekompressionsmaschine zur Fehlerprüfung der Kompression des Eingangsstroms, wobei die Dekompressionsmaschine Folgendes umfasst: a) den Prozessorkern zum Ausführen zweiter Befehle als inverser String Matcher, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren; b) einen ersten Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer ersten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms; c) einen Hardware-Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; und d) einen zweiten Komparator zum Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang und zum Generieren einer zweiten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
In Beispiel 15, das System von Beispiel 14, wobei die erste Störung oder Ausnahme eine Maschinenprüfungsarchitektur(MCA)-Störung umfasst, die von der zweiten Störung oder Ausnahme unterscheidbar ist, und wobei der zumindest eine Prozessor ferner dient zum: a) Verfolgen, in einem Protokoll, einer ersten Frequenz des Generierens der ersten Störung oder Ausnahme; b) Verfolgen, in dem Protokoll, einer zweiten Frequenz des Generierens der zweiten Störung oder Ausnahme; und c) Berichten der ersten Frequenz und der zweiten Frequenz an einen Systemadministrator.
In Beispiel 16, das System von Beispielen 14-15, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
In Beispiel 17, das System von Beispielen 15-16, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist, und wobei der Hardware Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
Diverse Ausführungsformen können unterschiedliche Kombinationen der oben beschriebenen Strukturmerkmale haben. Beispielsweise können alle optionalen Merkmale der oben beschriebenen Prozessoren und Verfahren auch in Bezug auf ein hier beschriebenes System implementiert sein und spezielle Einzelheiten in den Beispielen können anderswo in einer oder mehreren Ausführungsform(en) verwendet werden.
Beispiel 18 ist ein Verfahren, umfassend: 1) Komprimieren eines Eingangsstroms von Daten mit einem heterogenen Kompressor, wobei ein erster Abschnitt des heterogenen Kompressors Spezial-Hardware umfasst und ein zweiter Abschnitt des heterogenen Kompressors als Software ausgeführt ist; 2) Dekomprimieren von zumindest zwei Ausgängen des Kompressors, um zumindest zwei dekomprimierte Ausgänge zu generieren; und 3) Durchführen einer Fehlerprüfung der zumindest zwei dekomprimierten Ausgänge mit entsprechenden Eingängen, um etwaige Fehlabstimmungen in einem komprimierten Strom zu identifizieren, der durch den Kompressor erzeugt wird.
In Beispiel 19, das Verfahren von Beispiel 18, wobei der heterogene Kompressor umfasst: a) einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten eines Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; b) einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und c) einen Hardware Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes.
In Beispiel 20, das Verfahren von Beispiel 19, wobei der Prozessorkern zweite Befehle ausführen soll, um einen der zumindest zwei Ausgänge zu generieren, wobei das Dekomprimieren ferner umfasst: a) Ausführen einer inversen Operation durch Ausführen der zweiten Befehle, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren, das durch den String Matcher generiert wurde; b) Vergleichen des Eingangsstroms mit dem Bit-Strom; und c) Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms.
In Beispiel 21, das Verfahren von Beispielen 19-20, wobei das Dekomprimieren ferner umfasst: a) teilweises Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; b) Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang; und c) Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
In Beispiel 22, das Verfahren von Beispielen 19-22, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
In Beispiel 23, das Verfahren von Beispielen 19-22, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist, und wobei die dritte Kompressionsstufe einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
Während die vorliegende Offenbarung in Bezug auf eine begrenzte Anzahl von Ausführungsformen beschrieben wurde, werden Fachleute auf dem Gebiet zahlreiche Modifizierungen und Variationen derselben erkennen. Es ist beabsichtigt, dass die beiliegenden Ansprüche alle derartigen Modifizierungen und Variationen abdecken, die in das wahre Wesen und den wahren Umfang dieser vorliegenden Offenbarung fallen.
In den vorliegenden Beschreibungen sind zahlreiche spezielle Einzelheiten angegeben, wie Beispiele spezieller Arten von Prozessoren und Systemkonfigurationen, spezieller Hardware-Strukturen, spezieller architektonischer und mikroarchitektonischer Einzelheiten, spezieller Registerkonfigurationen, spezieller Befehlsarten, spezieller Systemkomponenten, spezieller Abmessungen/Höhen, spezieller Prozessor-Pipeline-Stufen und Operation usw., um ein umfassendes Verständnis der vorliegenden Offenbarung zu ermöglichen. Es ist jedoch für einen Fachmann auf dem Gebiet offensichtlich, dass diese speziellen Einzelheiten nicht zur Umsetzung der vorliegenden Offenbarung in die Praxis verwendet werden müssen. In andere Fällen wurden allgemein bekannte Komponenten oder Verfahren, wie spezielle und alternative Prozessorarchitekturen, spezielle Logikschaltungen/Code für beschriebene Algorithmen, ein spezieller Firmwarecode, eine spezielle Verbindungsoperation, spezielle Logikkonfigurationen, spezielle Herstellungstechniken und -materialien, spezielle Compiler-Implementierungen, ein spezieller Ausdruck von Algorithmen in Code, spezielle Abschalt- und Gating-Techniken/Logik und andere spezielle Einzelheiten von Operationen eines Computersystems nicht im Detail beschrieben, um ein unnötiges Verschleiern der vorliegenden Offenbarung zu vermeiden.
Die Ausführungsformen sind mit Verweis auf eine Kompressions-/Dekompressionsoptimierung in Solid-State-Speichervorrichtungen in speziellen integrierten Schaltungen, wie Rechenplattformen oder Mikroprozessoren, beschrieben. Die Ausführungsformen können auch bei anderen Arten von integrierten Schaltungen und programmierbaren Logikvorrichtungen anwendbar sein. Zum Beispiel sind die offenbarten Ausführungsformen nicht auf Desktop-Computersysteme oder tragbare Computer wie die Intel® Ultrabooks™ Computer beschränkt. Und können auch in anderen Vorrichtungen verwendet werden, wie in von Hand gehaltenen Vorrichtungen, Tablets, anderen dünnen Notebooks, System-on-Chip- (SoC) Vorrichtungen und eingebetteten Anwendungen. Einige Beispiele für in der Hand gehaltene Vorrichtungen enthalten Mobiltelefone, Internet-Protokollvorrichtungen, digitale Kameras, persönliche digitale Assistenten (PDAs) und in der Hand gehaltene PCs. Eingebettete Anwendungen enthalten typischerweise eine Mikrosteuerung, einen Digitalsignalprozessor (DSP), ein System-on-Chip, Netzwerk-Computer (NetPC), Set-Top Boxes, Netzwerk-Hubs, Weitverkehrsnetzwerk- (WAN) Schalter oder jedes andere System, das die in der Folge gelehrten Funktionen und Operationen durchführen kann. Es ist beschrieben, dass das System jede Art von Computer oder eingebettetem System sein kann. Die offenbarten Ausführungsformen können insbesondere für Low-End-Vorrichtungen verwendet werden, wie tragbare Vorrichtungen (z.B. Armbanduhren), elektronische Implantate, sensorische und Steuerungsinfrastrukturvorrichtungen, Steuerungen, Supervisory Control and Data Acquisition (SCADA) Systeme oder dergleichen. Ferner sind die hier beschriebenen Vorrichtungen, Verfahren und Systeme nicht auf physische Rechenvorrichtungen beschränkt, sondern können sich auch auf Software-Optimierungen zur Energieerhaltung und -effizienz beziehen. Wie in der folgenden Beschreibung sofort offensichtlich wird, sind die Ausführungsformen der hier beschriebenen Vorrichtungen, Verfahren und Systeme (ob unter Bezugnahme auf Hardware, Firmware, Software oder eine Kombination davon) für eine zukünftige ‚grüne Technologie‘, die mit Leistungsüberlegungen ausgewogen ist, wichtig.
Obwohl die Ausführungsformen hier unter Bezugnahme auf einen Prozessor beschrieben sind, sind andere Ausführungsformen bei anderen Arten von integrierten Schaltungen und Logikvorrichtungen anwendbar. Ähnliche Techniken und Lehren der Ausführungsformen der vorliegenden Offenbarung können bei anderen Arten von Schaltungen oder Halbleitervorrichtungen angewendet werden, die von einem höheren Pipeline-Durchsatz und einer verbesserten Leistung profitieren können. Die Lehren von Ausführungsformen der vorliegenden Offenbarung sind bei jedem Prozessor oder jeder Maschine anwendbar, der bzw. die Datenmanipulationen durchführt. Die vorliegende Offenbarung ist jedoch nicht auf Prozessoren oder Maschinen beschränkt, die 512 Bit-, 256 Bit-, 128 Bit-, 64 Bit-, 32 Bit- oder 16 Bit-Datenoperationen durchführen, und können bei jedem Prozessor und jeder Maschine angewendet werden, in dem bzw. der eine Manipulation oder eine Verwaltung von Daten durchgeführt wird. Zusätzlich sieht die vorliegende Beschreibung Beispiele vor und die beiliegenden Zeichnungen zeigen diverse Beispiele zur Veranschaulichung. Diese Beispiele sollten jedoch nicht in einem einschränkenden Sinn ausgelegt werden, da sie nur dazu dienen, Beispiele von Ausführungsformen der vorliegenden Offenbarung vorzusehen, anstatt eine umfassende Liste aller möglichen Implementierungen von Ausführungsformen der vorliegenden Offenbarung vorzusehen.
Obwohl die folgenden Beispiele eine Befehlshandhabung und -verteilung im Zusammenhang mit Ausführungseinheiten und Logikschaltungen beschreiben, können andere Ausführungsformen der vorliegenden Offenbarung mittels Daten oder Befehlen erreicht werden, die auf einem maschinenlesbaren, greifbaren Medium gespeichert sind, die, wenn sie durch eine Maschine durchgeführt werden, die Maschine veranlassen, Funktionen durchzuführen, die mit zumindest einer bestimmten Ausführungsform der Offenbarung übereinstimmen. In einer bestimmten Ausführungsform sind Funktionen, die mit Ausführungsformen der vorliegenden Offenbarung verknüpft sind, in maschinenausführbaren Befehlen verkörpert. Die Befehle können verwendet werden, um einen Allgemeinzweck- oder Spezialzweck-Prozessor, der mit den Befehlen programmiert ist, zu veranlassen, die Schritte der vorliegenden Offenbarung durchzuführen. Ausführungsformen der vorliegenden Offenbarung können als Computerprogrammprodukt oder Software vorgesehen sein, das bzw. die ein maschinen- oder computerlesbares Medium enthält, auf dem Befehle gespeichert sind, die zum Programmieren eines Computers (oder anderer elektronischer Vorrichtungen) verwendet werden können, um eine oder mehrere Operation(en) gemäß Ausführungsformen der vorliegenden Offenbarung durchzuführen. Alternativ könnten Operationen von Ausführungsformen der vorliegenden Offenbarung durch spezielle Hardware-Komponenten durchgeführt werden, die Logik festgesetzter Funktion zum Durchführen der Operationen enthalten, oder durch jede Kombination programmierter Computerkomponenten und Hardware-Komponenten festgesetzter Funktion.
Anweisungen, die zum Programmieren von Logik verwendet werden, um Ausführungsformen der Offenbarung durchzuführen, können in einem Speicher im System, wie einem DRAM, Cache, Flash-Speicher oder anderen Speicher, gespeichert werden. Ferner können die Befehle über ein Netzwerk oder mittels anderer computerlesbarer Medien verteilt werden. So kann ein maschinenlesbares Medium jeden Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die durch eine Maschine (z.B. einen Computer) lesbar ist, enthalten, wie, ohne aber darauf beschränkt zu sein, Disketten, optische Platten, Compact Disc, einen Nur-Lese-Speicher (CD-ROMs) und magnetooptische Platten, einen Nur-Lese-Speicher (ROMs), einen Direktzugriffsspeicher (RAM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, einen Flash-Speicher oder einen greifbaren, maschinenlesbaren Speicher, der in der Übertragung von Informationen über das Internet mittels elektrischer, optischer, akustischer oder anderer Formen ausgestrahlter Signale (z.B. Trägerwellen Infrarotsignale, Digitalsignale usw.) verwendet wird. Daher enthält das computerlesbare Medium jede Art von greifbarem maschinenlaserbaren Medium, das zum Speichern oder Übertragen elektronischer Befehle oder Informationen in einer Form geeignet ist, die von einer Maschine (z.B. einem Computer) lesbar ist.
Ein Design kann diverse Stufen durchlaufen, von der Erstellung bis zur Simulierung und Herstellung. Daten, die ein Design darstellen, können das Design auf zahlreiche Weisen darstellen. Zunächst, wie dies in Simulierungen nützlich ist, kann die Hardware unter Verwendung einer Hardware-Beschreibungssprache oder einer anderen Funktionsbeschreibungssprache dargestellt werden. Zusätzlich kann ein Schaltungsebenenmodell mit Logik und/oder Transistor-Gates in gewissen Stufen des Designprozesses produziert werden. Ferner erreichen die meisten Designs, in einer gewissen Stufe, ein Niveau von Daten, das die physische Anordnung diverser Vorrichtungen im Hardware-Modell darstellt. Falls herkömmliche Halbleiterherstellungstechniken verwendet werden, können die Daten, die das Hardware-Modell darstellen, die Daten sein, die das Vorhandensein oder Fehlen diverser Merkmale auf unterschiedlichen Maskenschichten spezifizieren, die zum Produzieren der integrierten Schaltung verwendet werden. In jeder Darstellung des Designs können die Daten in Form eines maschinenlesbaren Mediums gespeichert werden. Ein Speicher oder ein magnetischer oder optischer Speicher wie eine Platte können das maschinenlesbare Medium zum Speichern von Informationen sein, die durch eine optische oder elektrische Welle übertragen werden, die moduliert ist oder auf andere Weise generiert wird, um solche Informationen zu übertragen. Wenn eine elektrische Trägerwelle, die den Code oder das Design angibt oder trägt, in dem Ausmaß übertragen wird, dass ein Kopieren, Puffern oder eine erneute Übertragung des elektrischen Signals durchgeführt wird, wird eine neue Kopie erstellt. Somit kann ein Kommunikationsanbieter oder ein Netzwerkanbieter mit Hilfe von Techniken von Ausführungsformen der vorliegenden Offenbarung, zumindest temporär, einen Artikel wie Informationen, die in eine Trägerwelle codiert sind, auf einem greifbaren, maschinenlesbaren Medium speichern.
Ein Modul, wie hier verwendet, bezieht sich auf jede Kombination von Hardware, Software und/oder Firmware. Beispielsweise enthält ein Modul Hardware, wie eine Mikrosteuerung, die mit einem nicht transitorischen Medium zum Speichern eines Codes verknüpft ist, der dazu ausgebildet ist, von der Mikrosteuerung ausgeführt zu werden. Daher bezieht sich ein Verweis auf ein Modul in einer bestimmten Ausführungsform auf die Hardware, die im Speziellen konfiguriert ist, den Code zu erkennen und/oder auszuführen, der auf einem nicht transitorischen Medium gehalten wird. Ferner bezieht sich in einer anderen Ausführungsform die Verwendung eines Moduls auf das nicht transitorische Medium, das den Code enthält, der im Speziellen ausgebildet ist, durch die Mikrosteuerung ausgeführt zu werden, um vorgegebene Operationen durchzuführen. Wie abgeleitet werden kann, kann sich in einer weiteren Ausführungsform der Begriff Modul (in diesem Beispiel) auf die Kombination aus der Mikrosteuerung und dem nicht transitorischen Medium beziehen. Häufig variieren Modulgrenzen, die als getrennt dargestellt sind, allgemein und überlappen möglicherweise. Zum Beispiel können sich ein erstes und ein zweites Modul Hardware, Software, Firmware oder eine Kombination davon teilen, während möglicherweise eine gewisse unabhängige Hardware, Software oder Firmware beibehalten wird. In einer bestimmten Ausführungsform enthält die Verwendung des Begriffs Logik Hardware, wie Transistoren, Register oder andere Hardware, wie programmierbare Logikvorrichtungen.
Die Verwendung der Phrase ‚konfiguriert zum‘ bezieht sich in einer bestimmten Ausführungsform auf ein Anordnen, Zusammenstellen, Herstellen, Anbieten zum Verkauf, Importieren und/oder Entwerfen einer Vorrichtung, Hardware, Logik oder eines Elements zum Durchführen einer angegebenen oder bestimmten Aufgabe. In diesem Beispiel ist eine Vorrichtung oder ein Element davon, das nicht in Betrieb ist, noch immer ‚konfiguriert‘, eine angegebene Aufgabe durchzuführen, wenn es entworfen, gekoppelt und/oder verbunden ist, die angegebene Aufgabe durchzuführen. Als rein veranschaulichendes Beispiel kann ein Logik-Gate eine 0 oder eine 1 während des Betriebs bereitstellen. Ein Logik-Gate jedoch, das ‚konfiguriert‘ ist, einem Takt ein Freigabesignal bereitzustellen, enthält nicht jedes mögliche Logik-Gate, das eine 1 oder 0 bereitstellen kann. Stattdessen ist das Logik-Gate eines, das in einer gewissen Weise gekoppelt ist, sodass während des Betriebs der 1 oder 0 Ausgang den Takt freigeben kann. Es wird einmal mehr festgestellt, dass die Verwendung des Begriffs ‚konfiguriert zum‘ keinen Betrieb erfordert, sondern sich stattdessen auf den latenten Zustand einer Vorrichtung, Hardware und/oder eines Elements bezieht, wobei die Vorrichtung, Hardware und/oder das Element im latenten Zustand gestaltet ist, eine besondere Aufgabe durchzuführen, wenn die Vorrichtung, Hardware und/oder das Element in Betrieb ist.
Ferner bezieht sich die Verwendung der Phrasen ‚zum‘, ‚imstande zum‘ und oder ‚betreibbar zum‘ in einer bestimmten Ausführungsform auf eine Vorrichtung, Logik, Hardware und/oder ein Element, die bzw. das derart gestaltet ist, dass die Verwendung der Vorrichtung, Logik, Hardware und/oder des Elements in einer speziellen Weise möglich ist. Es wird festgehalten, dass, wie oben, die Verwendung von ‚zum‘, ‚imstande zum‘ oder ‚betreibbar zum‘ sich in einer bestimmten Ausführungsform auf den latenten Zustand der Vorrichtung, Logik, Hardware und/oder des Elements bezieht, wenn die Vorrichtung, Logik, Hardware und/oder das Element nicht in Betrieb ist, aber so gestaltet ist, dass die Verwendung einer Vorrichtung in einer speziellen Weise möglich ist.
Ein Wert, wie hier verwendet, enthält jede bekannte Darstellung einer Zahl, eines Zustands, eines logischen Zustands oder eines binären logischen Zustands. Häufig wird die Verwendung von Logikniveaus, Logikwerten oder logischen Werten auch als 1 und 0 bezeichnet, die einfach binäre logische Zustände darstellen. Zum Beispiel bezieht sich eine 1 auf ein hohes logisches Niveau und 0 bezieht sich auf ein niederes logisches Niveau. In einer bestimmten Ausführungsform kann eine Speicherzelle, wie ein Transistor oder eine Flash-Zelle imstande sein, einen einzelnen logischen Wert oder mehrere logische Werte zu halten. Es werden jedoch andere Darstellungen von Werten in Computersystemen verwendet. Zum Beispiel kann die Dezimalzahl Zehn auch als binärer Wert 1010 und als hexadezimaler Buchstabe A dargestellt werden. Daher enthält ein Wert jede Darstellung von Informationen, die in einem Computersystem gehalten werden können.
Ferner können Zustände durch Werte oder Teile von Werten dargestellt werden. Beispielsweise kann ein erster Wert, wie eine logische Eins, eine Vorgabe oder einen Ausgangszustand darstellen, während einer zweiter Wert, wie eine logische Null, einen Nicht-Vorgabezustand darstellen kann. Zusätzlich beziehen sich die Begriffe Rückstellen und Einstellen in einer bestimmten Ausführungsform auf einen Vorgabe- bzw. einen aktualisierten Wert oder Zustand. Zum Beispiel enthält ein Vorgabewert möglicherweise einen hohen logischen Wert, d.h., Rückstellen, während ein aktualisierter Wert möglicherweise einen niederen logischen Wert, d.h. Einstellen, enthält. Es ist zu beachten, dass jede Kombination von Werten verwendet werden kann, um eine beliebige Anzahl von Zuständen darzustellen.
Die oben angeführten Ausführungsformen von Verfahren, Hardware, Software, Firmware oder Code können mittels Befehlen oder Code implementiert werden, die auf einen maschinenzugänglichen, maschinenlesbaren, computerzugänglichen oder computerlesbaren Medium gespeichert sind, die durch ein Verarbeitungselement ausführbar sind. Ein nicht transitorisches maschinenzugängliches/lesbares Medium enthält jeden Mechanismus, der Informationen in einer Form bereitstellt (d.h. speichert und/oder überträgt), die durch eine Maschine, wie einen Computer oder ein elektronisches System lesbar ist. Zum Beispiel enthält ein nicht transitorisches maschinenzugängliches Medium einen Direktzugriffsspeicher (RAM), wie einen statischen RAM (SRAM) oder dynamischen RAM (DRAM); einen ROM; ein magnetisches oder optisches Speichermedium; Flash-Speichervorrichtungen; elektrische Speichervorrichtungen; optische Speichervorrichtungen; akustische Speichervorrichtungen; eine andere Form von Speichervorrichtungen zum Halten von Informationen, die von transitorischen (ausgestrahlten) Signalen (z.B. Trägerwellen, Infrarotsignalen, digitalen Signalen) erhalten werden; usw., die von den nicht transitorischen Medien zu unterscheiden sind, die daraus Informationen erhalten können.
Befehle, die zum Programmieren von Logik verwendet werden, um Ausführungsformen der Offenbarung durchzuführen, können in einem Speicher im System, wie einem DRAM, einem Cache, einem Flash-Speicher oder einem anderen Speicher gespeichert werden. Ferner können die Befehle über ein Netzwerk oder durch andere computerlesbare Medien verteilt werden. Somit kann ein maschinenlesbares Medium einen Mechanismus zum Speichern oder Übertragen von Informationen in einer Form enthalten, die durch eine Maschine (z.B. einen Computer) lesbar ist, wie Disketten, optische Platten, Compact Disc, Nur-Lese-Speicher (CD-ROMs) und magnetooptische Platten, einen Nur-Lese-Speicher (ROMs), einen Direktzugriffsspeicher (RAM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, einen Flash-Speicher oder einen greifbaren, maschinenlesbaren Speicher, der in der Übertragung von Informationen über das Internet mittels elektrischer, optischer, akustischer oder anderer Formen ausgestrahlter Signale (z.B. Trägerwellen, Infrarotsignale, digitale Signale usw.) verwendet wird. Daher enthält das computerlesbare Medium jede Art von greifbarem maschinenlesbaren Medium, das zum Speichern oder Übertragen elektronischer Befehle oder Informationen in einer Form geeignet ist, die durch eine Maschine (z.B. einen Computer) lesbar ist.
Eine Bezugnahme in dieser Beschreibung auf „eine bestimmte Ausführungsform“ oder „eine Ausführungsform“, bedeutet, dass ein besonderes Merkmal, eine besondere Struktur oder Eigenschaft, die in Verbindung mit der Ausführungsform beschrieben ist, in zumindest einer Ausführungsform der vorliegenden Offenbarung enthalten ist. Somit beziehen sich die Anführungen der Phrasen „in einer bestimmten Ausführungsform“ oder „in einer Ausführungsform“ an diversen Stellen in dieser Beschreibung nicht unbedingt auf dieselbe Ausführungsform. Ferner können die besonderen Merkmale, Strukturen oder Eigenschaften in geeigneter Weise in einer oder mehreren Ausführungsform(en) kombiniert werden.
In der vorangehenden Beschreibung wurde eine ausführliche Beschreibung unter Bezugnahme auf spezielle beispielhafte Ausführungsformen angeführt. Es ist jedoch offensichtlich, dass diverse Modifizierungen und Änderungen vorgenommen werden können, ohne vom breiteren Wesen und Umfang der Offenbarung abzuweichen, wie in den beiliegenden Ansprüchen angeführt. Die Beschreibung und Zeichnungen sind daher in einem veranschaulichenden Sinn und nicht in einem einschränkenden Sinn zu sehen. Ferner bezieht sich die vorangehende Verwendung von Ausführungsform und einer anderen beispielhaften Sprache nicht unbedingt auf dieselbe Ausführungsform oder dasselbe Beispiel, sondern kann sich auf verschiedene und einzelne Ausführungsformen, wie auch möglicherweise dieselbe Ausführungsform beziehen.
Einige Abschnitte der ausführlichen Beschreibung sind im Sinne von Algorithmen und symbolischen Darstellungen von Operationen an Daten-Bits in einem Computerspeicher dargestellt. Diese algorithmischen Beschreibungen und Darstellungen sind die Mittel, die von Fachleuten auf dem Gebiet der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit anderen Fachleuten auf dem Gebiet auf effektivste Weise zu übermitteln. Ein Algorithmus wird hier und im Allgemeinen als in sich stimmige Abfolge von Operationen übermittelt, die zu einem gewünschten Ergebnis führt. Die Operationen sind jene, die physische Manipulationen von physischen Quantitäten erfordern. Üblicherweise, wenn auch nicht unbedingt, nehmen diese Quantitäten die Form elektrischer und magnetischer Signale an, die gespeichert, überführt, kombiniert, verglichen und auf andere Weise manipuliert werden können. Es hat sich gelegentlich als praktisch erwiesen, vorwiegend aus Gründen der allgemeinen Nutzung, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen Terme, Zahlen oder dergleichen zu bezeichnen. Die hier beschriebenen Blöcke können Hardware, Software, Firmware oder eine Kombination davon sein.
Es sollte jedoch berücksichtigt werden, dass alle diese und ähnliche Begriffe mit den richtigen physischen Quantitäten zu verknüpfen sind und lediglich praktische Etiketten sind, die bei diesen Quantitäten angewendet werden. Falls nicht im Speziellen anderes angegeben ist, wie aus der obenstehenden Diskussion hervorgeht, ist klar, dass sich in der gesamten Beschreibung Diskussionen unter Verwendung von Begriffen wie „Definieren“, „Empfangen“, „Feststellen“, „Ausgeben“, „Verbinden“, „Verknüpfen“, „Erhalten“, „Authentifizieren“, „Verhindern“, „Ausführen“, „Anfordern“, „Kommunizieren“ oder dergleichen auf die Aktionen und Prozesse eines Rechensystems oder einer ähnlichen elektronischen Rechenvorrichtung beziehen, die Daten, die als physikalische (z.B. elektronische) Quantitäten in den Registern und Speichern des Rechensystems dargestellt sind, in andere Daten manipuliert und transformiert, die auf ähnliche Weise als physikalische Quantitäten in Speichern oder Registern des Rechensystems oder anderen derartigen Informationsspeicher-, -übertragungs- oder -anzeigevorrichtungen dargestellt sind.
Die Wörter „Beispiel“ oder „beispielhaft“ werden hier in der Bedeutung verwendet, dass sie als ein Beispiel, ein Fall oder eine Veranschaulichung dienen. Jeder hier als “Beispiel’ oder „beispielhaft“ beschriebene Aspekt oder Entwurf ist nicht unbedingt als bevorzugt oder vorteilhaft gegenüber anderen Aspekten oder Entwürfen auszulegen. Vielmehr soll die Verwendung der Wörter „Beispiel“ oder „beispielhaft“ Konzepte in konkreter Weise darstellen. Wie in dieser Anmeldung verwendet, soll der Begriff „oder“ ein inklusives „oder“ anstelle eines exklusiven „oder“ bedeuten. Das heißt, falls nicht anderes angegeben ist oder klar aus dem Kontext hervorgeht, soll „X enthält A oder B“ jede der natürlichen inklusiven Permutationen bedeuten. Das heißt, falls X A enthält; X B enthält; oder X sowohl A wie auch B, enthält dann ist „X enthält A oder B“ unter einem der vorangehenden Beispiele erfüllt. Zusätzlich sollten die Artikel „einer“, „eine“ und „eines“, wie in dieser Anmeldung und in den beiliegenden Ansprüchen verwendet, allgemein in der Bedeutung „eines oder mehrere“ ausgelegt werden, falls nicht anderes spezifiziert ist oder klar aus dem Kontext hervorgeht, der auf eine Singularform gerichtet ist. Ferner soll die Verwendung des Begriffs „eine Ausführungsform“ oder „eine bestimmte Ausführungsform“ oder „eine Implementierung“ oder „eine bestimmte Implementierung“ durchgehend nicht dieselbe Ausführungsform oder Implementierung bedeutet, falls diese nicht als solche beschrieben ist. Ebenso sollen die Begriffe „erste,“ „zweite,“ „dritte,“ „vierte“ usw., wie hier verwendet, als Etiketten verstanden werden, um verschiedene Elemente zu unterscheiden, und können nicht unbedingt eine Bedeutung einer Ordinalzahl ihrer numerischen Bezeichnung entsprechend haben.

Claims

Prozessor, umfassend: einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten eines Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und eine Dekompressionsmaschine zum Generieren von zumindest zwei Ausgängen, die Fehlerprüfungen des Eingangsstroms angeben, wenn der Eingangsstrom komprimiert wird, wobei der Prozessorkern zweite Befehle ausführen soll, um einen der zumindest zwei Ausgänge zu generieren.
Prozessor nach Anspruch 1, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
Prozessor nach Anspruch 1, wobei der Prozessorkern die zweiten Befehle ausführen soll, um eine inverse Operation durchzuführen, die einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen generiert, ferner umfassend einen Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms.
Prozessor nach Anspruch 1, ferner umfassend einen Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes.
Prozessor nach Anspruch 4, wobei die Dekompressionsmaschine umfasst: einen Hardware-Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; und einen Komparator zum Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang und zum Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
Prozessor nach Anspruch 4, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist.
Prozessor nach Anspruch 6, wobei der Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
Vorrichtung, umfassend: einen Kompressor zum Komprimieren eines Eingangsstroms von Daten, wobei der Kompressor Folgendes umfasst: einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten des Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und eine Dekompressionsmaschine, umfassend: den Prozessorkern zum Ausführen zweiter Befehle als inverser String Matcher, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren; und einen ersten Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer ersten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms.
Vorrichtung nach Anspruch 8, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
Vorrichtung nach Anspruch 8, wobei der Kompressor ferner einen Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes umfasst.
Vorrichtung nach Anspruch 10, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist und wobei der Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
Vorrichtung nach Anspruch 10, wobei die Dekompressionsmaschine ferner umfasst: einen Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; und einen Komparator zum Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang und zum Generieren einer zweiten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
Vorrichtung nach Anspruch 12, wobei die erste Störung oder Ausnahme eine Maschinenprüfungsarchitektur(MCA)-Störung umfasst, die von der zweiten Störung oder Ausnahme unterscheidbar ist, und wobei der zumindest eine Prozessor ferner dient zum: Verfolgen, in einem Protokoll, einer ersten Frequenz des Generierens der ersten Störung oder Ausnahme; und Verfolgen, in dem Protokoll, einer zweiten Frequenz des Generierens der zweiten Störung oder Ausnahme.
Fehlerprüfungs-, Datenkompressionssystem, umfassend: eine Kompressionsmaschine zum Komprimieren eines Eingangsstroms von Daten, wobei die Kompressionsmaschine Folgendes umfasst: einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten des Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und einen Hardware Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes; und eine Dekompressionsmaschine zur Fehlerprüfung der Kompression des Eingangsstroms, wobei die Dekompressionsmaschine Folgendes umfasst: den Prozessorkern zum Ausführen zweiter Befehle als inverser String Matcher, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren; einen ersten Komparator zum Vergleichen des Eingangsstroms mit dem Bit-Strom und zum Generieren einer ersten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms; einen Hardware-Decodierer zum teilweisen Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; und einen zweiten Komparator zum Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang und zum Generieren einer zweiten Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
System nach Anspruch 14, wobei die erste Störung oder Ausnahme eine Maschinenprüfungsarchitektur(MCA)-Störung umfasst, die von der zweiten Störung oder Ausnahme unterscheidbar ist, und wobei der zumindest eine Prozessor ferner dient zum: Verfolgen, in einem Protokoll, einer ersten Frequenz des Generierens der ersten Störung oder Ausnahme; Verfolgen, in dem Protokoll, einer zweiten Frequenz des Generierens der zweiten Störung oder Ausnahme; und Berichten der ersten Frequenz und der zweiten Frequenz an einen Systemadministrator.
System nach Anspruch 14, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
System nach Anspruch 14, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist, und wobei der Hardware Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.
Verfahren, umfassend: Komprimieren eines Eingangsstroms von Daten mit einem heterogenen Kompressor, wobei ein erster Abschnitt des heterogenen Kompressors Spezial-Hardware umfasst und ein zweiter Abschnitt des heterogenen Kompressors als Software ausgeführt ist; Dekomprimieren von zumindest zwei Ausgängen des Kompressors, um zumindest zwei dekomprimierte Ausgänge zu generieren; und Durchführen einer Fehlerprüfung der zumindest zwei dekomprimierten Ausgänge mit entsprechenden Eingängen, um etwaige Fehlabstimmungen in einem komprimierten Strom zu identifizieren, der durch den Kompressor erzeugt wird.
Verfahren nach Anspruch 18, wobei der heterogene Kompressor umfasst: einen Hardware String Matcher zum Abgleichen von Zeichenketten diverser Teilzeichenketten eines Eingangsstroms und zum Generieren eines Zwischen-Token-Formats jeweiliger Teilzeichenkettenübereinstimmungen; einen Prozessorkern zum Ausführen erster Befehle als ein Entropiecodegenerator, um Entropiecodes aus Frequenzen von Token zu generieren, die jeweiligen Teilzeichenkettenübereinstimmungen entsprechen; und einen Hardware Entropiecode-Codierer zum Codieren eines endgültigen komprimierten Ausgangs des Eingangsstroms unter Verwendung der Entropiecodes.
Verfahren nach Anspruch 19, wobei der Prozessorkern zweite Befehle ausführen soll, um einen der zumindest zwei Ausgänge zu generieren, wobei das Dekomprimieren ferner umfasst: Ausführen einer inversen Operation durch Ausführen der zweiten Befehle, um einen Bit-Strom aus dem Zwischen-Token-Format jeweiliger Teilzeichenkettenübereinstimmungen zu generieren, das durch den String Matcher generiert wurde; Vergleichen des Eingangsstroms mit dem Bit-Strom; und Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abstimmen des Eingangsstroms und des Bit-Stroms.
Verfahren nach Anspruch 19, wobei das Dekomprimieren ferner umfasst: teilweises Dekomprimieren des endgültigen komprimierten Ausgangs, um ein Codieren des Entropiecode-Codierers umzukehren, um einen teilweise dekomprimierten Ausgang zu generieren; Vergleichen eines Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang; und Generieren einer Störung oder Ausnahme infolge einer Feststellung eines Fehlers beim Abgleichen des Ausgangs des Entropiecodegenerators mit dem teilweise dekomprimierten Ausgang.
Verfahren nach Anspruch 19, wobei der Hardware String Matcher einen LZ77-Kompressor umfasst.
Verfahren nach Anspruch 19, wobei der Entropiecodegenerator ein Baumgenerator zum Generieren eines Huffman-Baums aus den Frequenzen der Token ist und wobei der Hardware Entropiecode-Codierer einen Huffman-Codierer zum Generieren des endgültigen komprimierten Ausgangs aus dem Huffman-Baum umfasst.