-
Hintergrund der Erfindung
-
Ausführungsformen
der vorliegenden Erfindung betreffen ein Prozessorgestütztes System
und insbesondere ein System mit mehreren Sortierern mit verschiedenen
Befehlssatz-Architekturen.
-
Computersysteme
haben verschiedene Komponenten zum Verarbeiten und Kommunizieren von
Daten. Typische Systeme haben einen oder mehrere Prozessoren, die
jeweils mehrere Kerne haben können,
sowie zugehörige
Speicher, Eingabe-/Ausgabe(E/A)-Geräte und andere
derartige Komponenten. Zum Verbessern der Rechenleistung können Rechenbeschleuniger,
Eingabe-/Ausgabe-Spezialgeräte
und andere derartige spezialisierte Einheiten über eine oder mehrere spezialisierte
Komponenten bereitgestellt werden, die hier unter dem Oberbegriff „Helfereinheiten" zusammengefasst
werden. Bei der Verwendung solcher Helfereinheiten können jedoch
Unzulänglichkeiten
auftreten, da in einer typischen Rechenumgebung, die einen Mehrzweckprozessor
und eine Industriestandard-Betriebssystem(OS)-Umgebung
implementiert, ein Software-Stapel eine effiziente Nutzung behindern kann.
Das heißt,
in einer typischen OS-Umgebung wird System-Software über unterschiedliche
Privileg-Ebenen von Anwendungssoftware getrennt, und Operationen
in jeder dieser unterschiedlichen Privileg-Ebenen sind, neben anderen
Beschränkungen, von
Speicher- und Umspeicher-Operationen
im OS-Kontext abhängig.
Darüber
hinaus sind Helfereinheiten normalerweise nicht in der Lage, Ausnahmen
und Fehler zu behandeln, was ein stabiles Verarbeiten bestimmter
Ereignisse während
der Abarbeitung gestattet
-
Klassische
Beispiele für
einen Rechenbeschleuniger sind Coprozessoren, wie etwa mathematische
Coprozessoren wie die sogenannten x87-Floating-Point-Coprozessoren
für die
frühen
Intel®-Architektur(IA)-32-Prozessoren.
Normalerweise sind diese Coprozessoren mit einem Hauptprozessor [z.
B. einer Zentraleinheit (CPU)] über
eine Coprozessor-Schnittstelle verbunden, die die gleiche Befehlssatz-Architektur
(instruction set architecture; ISA) wie der Hauptprozessor hat.
Vor kurzem sind getrennte Ressourcen mit unterschiedlichen Befehlssatz-Architekturen (ISAs)
in Systemen aufgetaucht.
-
Wenn
mehrere Ressourcen mit unterschiedlichen ISAs in einem System vorhanden
sind, das auf einem Einbild-OS (z. B. dem Industriestandard-OS) läuft, das
für eine
einzige ISA geschrieben ist, wird das Behandeln von Ausnahmen oder
Fehlern, die bei der Code-Abarbeitung
auf der oder den Ressource(n) mit einer heterogenen ISA auftreten,
normalerweise nur begrenzt oder gar nicht unterstützt. Auch wenn
diese Behandlung vorläge,
würden
potentiell ungleiche Architekturmechanismen der unterschiedlichen
ISAs ein umfangreiches Neuschreiben des OS erfordern. Daher unterstützen heterogene
Ressourcen im Allgemeinen nicht die Behandlung von Ausnahmen und
Fehlern, was ihre Eignung für
verschiedene Tasks verringert.
-
Kurze Beschreibung der Zeichnungen
-
1 ist
ein Blockdiagramm eines Prozessors nach einer Ausführungsform
der vorliegenden Erfindung.
-
2 ist
ein Blockdiagramm eines Teils eines Systems nach einer Ausführungsform
der vorliegenden Erfindung.
-
3 ist
ein Ablaufdiagramm eines Verfahrens zum Behandeln eines Fehlerzustands
in einer heterogenen Ressource nach einer Ausführungsform der vorliegenden
Erfindung.
-
4 ist
ein Blockdiagramm eines Teils eines Systems nach einer weiteren
Ausführungsform der
vorliegenden Erfindung.
-
5 ist
ein Ablaufdiagramm eines Verfahrens zum Behandeln einer Ausnahme
in einer heterogenen Ressource nach einer Ausführungsform der vorliegenden
Erfindung.
-
6 ist
ein Blockdiagramm eines Systems nach einer Ausführungsform der vorliegenden
Erfindung.
-
Detaillierte Beschreibung
-
In
verschiedenen Ausführungsformen
werden Mechanismen zum Ermöglichen
einer Befehlssatz-Architektur(ISA)-gestützten Ausnahmenbehandlung und
Adressübersetzungsmechanismen
bereitgestellt. „Sortierer" bedeutet hier eine
selbständige
Thread-Abarbeitungs-Ressource und kann jede physische oder logische
Einheit sein, die einen Thread abarbeiten kann. Ein Sortierer kann
eine logische Thread-Einheit oder eine physische Thread-Einheit
sein und kann eine Nächster-Befehls-Pointer-Logik
haben, um den nächsten
Befehl zu bestimmen, der für
den gegebenen Thread ausgeführt
werden soll.
-
Bei
zahlreichen Implementierungen kann ein System einen ersten Sortierer
mit einer ersten ISA und eine zweite Rechenressource (die ein Sortierer oder
ein Nicht-Sortierer sein kann) mit einer heterogenen Beschaffenheit
haben. Das heißt,
die zweite Ressource kann ein Sortierer mit einer anderen ISA sein
oder kann eine Nicht-Sortierer-Ressource sein, wie etwa eine Fixed-Function-Einheit
(fixed function unit, FFU), eine anwendungsspezifische integrierte Schaltung
(ASIC) oder eine andere vorprogrammierte Logik. Bei verschiedenen
Ausführungsformen kann
eine Zwischenstufe oder Schnittstelle, die hier als „Exo-Skelett" bezeichnet wird,
die Kommunikation zwischen diesen heterogenen Ressourcen ermöglichen.
Bei anderen Ausführungsformen
kann ein Exo-Skelett verschiedene Formen annehmen, unter anderem
Software, Hardware und/oder Firmware. Bei einigen Ausführungsformen
kann das Exo-Skelett in einem endlichen Automaten (finite-state
machine, FSM) implementiert sein, der eng mit der heterogenen Ressource
verbunden ist. Natürlich
sind auch andere Implementierungen möglich.
-
Kommen
wir nun zu 1, wo ein Blockdiagramm eines
Prozessors nach einer Ausführungsform
der vorliegenden Erfindung gezeigt ist. Wie in 1 gezeigt
ist, weist ein Prozessor 10 verschiedene Ressourcen auf.
Bei anderen Implementierungen kann der Prozessor 10 ein
Einkernprozessor oder ein Mehrkernprozessor sein. Ein solcher Prozessor
kann in verschiedenen Arten von Systemen implementiert sein, unter
anderem einem Chip-Multiprozessor(CMP)-System,
einem Simultanes-Multithreading(SMT)-System oder einem Switch-on-event-Multithreading(SoeMT)-System.
-
Wie
in 1 gezeigt ist, weist der Prozessor 10 mehrere
Sortierer 20a, 20b, 20c und 20d (d.
h. Sortierer 1–4
und allgemein Sortierer 20) auf. In der Ausführungsform
von 1 ist er zwar mit vier derartigen Sortierem gezeigt,
aber es ist klar, dass der Schutzumfang der vorliegenden Erfindung
nicht hierauf beschränkt
ist. Wie in 1 gezeigt ist, implementieren
die Sortierer 20 in dem Prozessor 10 eine ISA 30,
die bei einer Ausführungsform
eine Intel®-Architektur(IA)-32-Befehlssatz-Architektur
und/oder ihre 64-Bit-Erweiterung [auch als 64-Bit-Technologie für erweiterten
Intel®-Speicher
(EM64T) bezeichnet] sein kann. Der Prozessor 10 weist weiterhin
andere Ressourcen auf, unter anderem eine erste Ressource (d. h.,
eine Ressource 1) 50a, eine zweite Ressource (d. h., eine
Ressource 2) 50b und eine dritte Ressource (d. h., eine
Ressource 3) 50c (und allgemein Ressourcen 50).
Diese Ressourcen können
heterogene Ressourcen sein, die nicht die ISA 30 des Prozessors 10 implementieren.
In der Ausführungsform
von 1 ist der Prozessor 10 zwar mit drei
dieser Ressourcen gezeigt, aber bei anderen Ausführungsformen sind auch mehr
oder weniger Ressourcen möglich.
-
Jede
Ressource 50 hat einen Sortierer (der eine andere ISA als
die ISA 30 implementieren kann), eine Nicht-Sortierer-Verarbeitungsmaschine
oder eine andere spezialisierte Funktionslogik, die hier allgemein
als Beschleuniger bezeichnet wird. Bei anderen Ausführungsformen
können
andere Arten von Ressourcen als Beschleuniger implementiert werden,
unter anderem ein Grafikprozessor (graphics processing unit; GPU)
(normalerweise ein Sortierer), eine Verschlüsselungseinheit (normalerweise
ein Nicht-Sortierer), ein Physikbeschleuniger (physics processing
unit; PPU) (normalerweise ein Nicht-Sortierer), eine Fixed-Function-Einheit
(FFU) (normalerweise ein Nicht-Sortierer) und dergleichen. Wie in 1 gezeigt
ist, kann jede Ressource 50 einen Beschleuniger 52 (allgemein)
und insbesondere Beschleuniger 52a, 52b und 52c aufweisen,
die jeweils mit einer der Ressourcen 50a–50c assoziiert
sind. Die Beschleuniger 52 werden hier auch als Helfereinheiten
bezeichnet. Da die Beschleuniger 50a–50c eine andere ISA
haben können
oder sogar ein Nicht-Sortierer sein können und als solche in Bezug auf
die Sortierer 20 heterogen sein können, kann eine Schnittstelle
verwendet werden, um eine Kommunikation mit diesen Ressourcen zu
ermöglichen. Wie
in 1 gezeigt ist, können insbesondere Exo-Skelette 54a, 54b und 54c (allgemein
Exo-Skelett 54) mit jeder der Ressourcen 50 assoziiert
sein. Jede Ressource 50 kann somit als „Exo-Sortierer" bezeichnet werden,
was auf die enge Verbindung zwischen dem Exo-Skelett 54 und seinem zugehörigen Beschleuniger 52 hinweist.
Auf diese Weise können
diese heterogenen Ressourcen mit homogenen Sortierer-Ressourcen
in einem einheitlichen ISA-Rahmen
integriert werden, der eine Zwischen-Sortierern-Kommunikation unterstützt.
-
Bei
anderen Ausführungsformen
können
jedoch die Ressourcen 50 homogene Sortierer-Ressourcen
in Bezug auf die Sortierer 20 sein und können symmetrische
Kerne sein, sodass sie die gleiche oder eine ähnliche Architektur wie die
Sortierer 20 haben. Auf diese Weise können nebeneinander bestehende
Lichtleitfasern implementiert werden, und die Legacy-OS-Skalierbarkeit kann
verbessert werden. Darüber
hinaus können
bei anderen Implementierungen die Ressourcen 50 asymmetrische
Kerne sein. Mit anderen Worten, diese Ressourcen können die
gleiche ISA wie die Sortierer 20, aber eine andere Mikroarchitektur
haben. Diese Ausführungsformen können dazu
beitragen, die Asymmetrie zu bewältigen
und die Kompatibilität
zu einem Legacy-OS herzustellen.
-
Bei
Ausführungsformen,
die heterogene Ressourcen implementieren, kann ein Exo-Skelett die
Illusion vermitteln, dass diese heterogenen Ressourcen eine gemeinsame
ISA haben, um eine minimale Konformität für die Zwischen-Sortierern-Kommunikation
zu erreichen.
-
Somit
kann bei verschiedenen Ausführungsformen
eine heterogene Ressource als Funktionseinheitsressource auf Nutzer-Ebene
(anstatt als Gerät auf
System-Ebene) arbeiten.
-
Der
Prozessor 10 ist zwar in der Ausführungsform von 1 mit
den speziellen Ressourcen dargestellt, aber es ist klar, dass er
ein einzelner physischer Prozessor sein kann, der mehrere Hardware-Thread-Kontexte
unterstützen
kann (ohne Verlust an Klarheit auch als „Thread-Kontext" bezeichnet; man
beachte, dass das nicht das Gleiche wie Software-Thread-Kontext ist), die
jeweils einen Satz des Architekturzustands haben. Bei einigen Ausführungsformen
können
bestimmte Ressourcen für
diese Thread-Kontexte sichtbar sein, während andere Ressourcen unsichtbar
sind. Somit kann, wie in 1 gezeigt ist, jeder der Sortierer
20 einem Thread-Kontext entsprechen. Wenn mindestens einige dieser
Thread-Kontexte
(z. B. m von n, m ≤ n)
für das
Betriebssystem sichtbar gemacht werden, werden diese Thread-Kontexte
gelegentlich als Logikprozessoren oder OS-verwaltete Sortierer (OS-managed
sequencers; OMSs) bezeichnet. Jeder Thread-Kontext hält jeweils
einen Satz der Architekturzustände
AS1 bis ASn. Der
Architekturzustand umfasst zum Beispiel Datenregister, Segmentregister, Steuerregister,
Debugging-Register und den größten Teil
der modellspezifischen Register. Die Thread-Kontexte können die
meisten Mikroarchitektur-Ressourcen
des physischen Prozessors gemeinsam verwenden, wie etwa Caches,
Abarbeitungseinheiten, Branch-Predictors, Steuerlogik und Busse. Obwohl
diese Funktionen gemeinsam verwendet werden können, kann jeder Thread-Kontext
des Prozessors 10 unabhängig
eine nächste
Befehlsadresse erzeugen (und zum Beispiel einen Abruf aus einem Befehlscache,
einem Ausführungsbefehlscache
oder einem Trace-Cache durchführen).
Jeder der Sortierer 20, der einem Thread-Kontext entspricht,
ist mit einem entsprechenden Architekturzustand 40 (allgemein)
assoziiert. Insbesondere kann zum Beispiel ein Architekturzustand
(AS1) 40a mit dem Sortierer 20a assoziiert
sein, ein AS2 40b kann mit dem
Sortierer 20b assoziiert sein, ein AS3 40c kann
mit dem Sortierer 20c assoziiert sein, und ein AS4 40d kann mit dem Sortierer 20d assoziiert
sein.
-
Unter
Verwendung des Prozessors 10 oder eines ähnlichen
derartigen Prozessors kann eine ISA-gestützte Zwischen-Sortierern-Kommunikation ohne
Einbeziehung eines OS erfolgen. Zum Beispiel kann in einem Shared-Memory-Multiprocessing-Paradigma
ein Anwendungsprogrammierer ein Software-Programm (d. h., eine Anwendung
oder einen Prozess) in mehrere gleichzeitig abzuarbeitende Tasks unterteilen,
um eine Parallelität
auszudrücken.
Alle Threads desselben Software-Programms („Prozess") verwenden eine gemeinsame Logikdarstellung
des Speicheradressraums. Ein OS-Thread kann jedoch mit mehreren
Nutzer-Ebenen-Threads
assoziiert sein, die von dem Betriebssystem nicht erzeugt, geschedult
oder in anderer Weise verwaltet werden können. Diese Nutzer-Ebenen-Threads
können
als „Shreds" bezeichnet werden,
um sie von OS-Threads zu unterscheiden. Diese Shreds sind möglicherweise für den OS-Scheduler
nicht sichtbar, und daher verwaltet das OS nicht, wann oder wie
der assoziierte OS-Thread einen Shred so schedult, dass er auf einer
zugewiesenen Adresse eines logischen Sortierers läuft. Der
OS-Thread ist normalerweise selbst dafür verantwortlich, zu schedulen,
warm und wie einer seiner Shreds laufen soll.
-
Die
Architektur-Unterstützung
für eine ISA-gestützte Zwischen-Sortierem-Kommunikation kann
Erweiterungen auf eine ISA so umfassen, dass ein oder mehrere Befehle
bereitgestellt werden, um es einem Nutzer zu gestatten, Steuer-
und Zustandsübertragungen
zwischen Sortierem direkt zu manipulieren. Diese Befehle können Befehle
sein, die es einem ersten Sortierer ermöglichen, einem anderen (d. h.,
einem zweiten) Sortierer ein Signal zu senden (ein Befehl wird hier
als Shred-Übertragungs-
oder „SXFR"-Befehl bezeichnet,
der Ausgangssteuerinformationen senden kann, was als Ausgangsszenario bezeichnet
wird, und der auch eine Daten-Payload übertragen kann), oder die das
Einrichten eines zweiten Sortierers zum Überwachen auf ein solches Signal
ermöglichen
(hier als Shred-Monitor- oder „SEMONITOR"-Befehl bezeichnet) und nach dem asynchronen
Empfang des Signals (als Eingangsszenario bezeichnet) die Übertragung
der Steuerung auf einen Handler durchführen.
-
Bei
Ausführungsformen,
bei denen der Beschleuniger 52 eine heterogene ISA hat
oder ein Nicht-Sortierer ist, kann das entsprechende Exo-Skelett 54,
das ein endlicher Automat (FSM) oder eine Virtualisierungsschicht
sein kann, implementiert werden (in Hardware, Firmware oder sogar in
Software, je nach den speziellen Ausführungsformen), sodass der Beschleuniger 52 an
der Zwischen-Sortierer-Kommunikation teilnehmen kann. Diese ISA-gestützte Zwischen-Sortierer-Kommunikation
stellt ein Signalisierungsprotokoll in einer Eingangsrichtung in
den Beschleuniger 52 bereit, sodass er Eingangsszenarios,
die mittels SXFR von einem anderen Sortierer oder Exo-Sortierer
gesendet werden, unter anderem GET- und/oder SET-Befehle für den Architekturzustand
des Exo-Sortierers, überwachen
und darauf reagieren kann. Darüber
hinaus enthalten die Signalisierungsprotokolle die Ausgangskommunikation
von dem Beschleuniger 52, um einem entsprechenden Sortierer 20 ein
Ausgangsszenario mit einem Hinweis auf eine Ausnahmenbehandlung
mitzuteilen, wie etwa eine Proxy-Abarbeitungsanforderung
für solche
Ereignisse wie Seitenfehler.
-
Um
den Overhead zu reduzieren, erfordert die ISA-gestützte Kommunikation
zwischen dem Sortierer 20 und dem Beschleuniger 52 über Befehle,
die der Sortierer kennt, möglicherweise
nicht die Verwendung eines OS. Auf diese Weise kann ein Gerätetreiberstapel des
OS vermieden werden, und stattdessen kann eine direkte Kommunikation
zwischen dem Sortierer 20 und dem Beschleuniger 52 erreicht werden.
-
Bei
verschiedenen Ausführungsformen
können
Adressübersetzungs-Remapping (address translation
re-mapping; ATR) und kollaborative Ausnahmenbehandlung (collaborative
exception handling; CEH) in einem System, wie etwa einem CMP-System,
implementiert werden, das mit anwendungsverwalteten Exo-Sortierern
mit heterogenen ISAs integriert ist, auf denen bei der Programm-Abarbeitung
Seitenfehler oder Ausnahmen entstehen können. Unter Verwendung von
Ausführungsformen der
vorliegenden Erfindung können
Seitenfehler und Ausnahmen, die auf den anwendungsverwalteten Exo-Sortierern
auftreten, mit dem OMS und dem OS, das auf dem OMS läuft, elegant
behandelt werden. Um zum Beispiel die Programmierung eines CMP mit Exo-Sortierern
mit unterschiedlichen ISAs (und insbesondere in einer Einbild-OS-Umgebung)
zu erleichtern, kann ein gemeinsamer virtueller Speicher für den OMS
und die Exo-Sortierer auch dann unterstützt werden, wenn die Exo-Sortierer
andere Adressübersetzungs-Hardware-Mechanismen
als die des OMS haben. Wenn bei einem Code, der auf einem Exo-Sortierer
läuft,
ein Architektur- oder Mikroarchitektur-Fehlerzustands in Bezug auf
eine Übersetzung
von einer virtuellen in eine physische Adresse auftritt, können Ausführungsformen
den (Architektur- oder Mikroarchitektur-)Fehlerzustand mit dem auf
dem OMS laufenden OS beheben.
-
Ebenso
können
Operationen an unterschiedlichen Datentypen in den unterschiedlichen
Sortierern ausgeführt
werden. Als Beispiel können
die verschiedenen Sortierer in einem Parallelmodus arbeiten, zum
Beispiel in einem Single-Instruction-Multiple-Data(SIMD)-Modus oder einem Multiple-Instruction-Multiple-Data(MIMD)-Modus,
sodass jede Ressource gleichzeitig verwendet werden kann, um die Leistung
zu verbessern. Wenn an dem Exo-Sortierer Ausnahmen auftreten, können sie
an den OMS weitergeleitet werden. Die unterschiedlichen Datentypen können das
jedoch erschweren. Daher kann bei einigen Ausführungsformen ein Exo-Sortierer
Hardware zum Unterstützen
der Umwandlung von nativen Datentypen des Exo-Sortierers in ein
Format haben, das für
den OMS besser geeignet ist. Zum Beispiel kann ein Exo-Skelett mit
dem Exo-Sortierer gekoppelt werden, um diese Daten-Umwandlungen zu bewerkstelligen
und eine Zwischen-Sortierern-Kommunikation zu ermöglichen.
Als ein Beispiel können
SIMD-Datentypen eines Exo-Sortierers in skalare Werte zur Ausnahmenbehandlung
auf dem OMS umgewandelt werden.
-
Kommen
wir mm zu 2. Hier ist ein Blockdiagramm
eines Teils eines Systems nach einer Ausführungsform der vorliegenden
Erfindung gezeigt. Wie in 2 gezeigt,
weist ein System 100 einen Prozessor 110 auf,
der ein CMP mit mehreren Sortierern sein kann.
-
Insbesondere
weist die Ausführungsform von 2 vier
Sortierer 120a–120d (allgemein
Sortierer 120) auf. Der Prozessor 110 ist zu Erläuterungszwecken
zwar mit vier derartigen Sortierern dargestellt, aber es ist klar,
dass der Schutzumfang der vorliegenden Erfindung in dieser Hinsicht
nicht beschränkt
ist. Bei zahlreichen Implementierungen können ein oder mehrere Sortierer 120a–120d eine heterogene
ISA oder eine andere heterogene Ressource in Bezug auf eine native
ISA 115 des Systems 100 haben. Zu Zwecken der
Erläuterung
kann der erste Sortierer 120a ein Sortierer mit der nativen
ISA sein. Zum Beispiel kann bei einer Ausführungsform der erste Sortierer 120a eine
IA-32-CPU sein, obwohl der Schutzumfang der vorliegenden Erfindung
in dieser Hinsicht nicht beschränkt
ist. Daher arbeitet der erste Sortierer 120a als OMS. Ein
oder mehrere weitere Sortierer 120 können ebenfalls IA-32-gestützte Sortierer
sein, die einen nativen ISA-Betrieb implementieren. Mindestens einer
der Sortierer 120, z. B. der dritte Sortierer 120c,
kann jedoch ein heterogener Sortierer sein. Zu Zwecken der Erläuterung
kann ein dritter Sortierer 120c eine heterogene Ressource sein,
z. B. ein Grafikprozessor (GPU) oder eine andere derartige heterogene
Maschine mit einer anderen (nicht-nativen) ISA. Als solcher arbeitet der
dritte Sortierer 120c als anwendungsverwalteter Exo-Sortierer. Als Beispiel
kann der erste Sortierer 120a auf einem IA-32-gestützten Einbild-OS
wie WindowsTM oder LinuxTM laufen
und kann über
Zwischen-Sortierern-Signalisierungs-Mechanismen allein oder kompatibel mit
dem dritten Sortierer 120c arbeiten, z. B. über SXFR-gestützte Zwischen-Sortierern-Signalisierungs-Mechanismen.
Um eine ISA-gestützte
Zwischen-Sortierern-Kommunikation
zu ermöglichen, kann
der dritte Sortierer 120c ein Exo-Skelett haben. Das Exo-Skelett
und sein zugrunde liegender dritter Sortierer 120c werden
hier gemeinsam auch als Exo-Sortierer bezeichnet.
-
Bei
verschiedenen Ausführungsformen
kann ein Adressübersetzungs-Remapping (ATR) implementiert
werden, um einen gemeinsamen virtuellen Speicher für mehrere
Sortierer über
eine Proxy-Durchführung
der Seitenfehlerbehandlung zu unterstützen. Insbesondere können Zwischen-Sortierern-Kommunikations-Mechanismen
zwischen dem dritten Sortierer 120c und dem ersten Sortierer 120a verwendet
werden, um diese Seitenfehlerbehandlung in dem ersten Sortierer 120a in
einem Proxy-Abarbeitungsmodus durchzuführen. Daher kann, wenn beim
Abarbeiten eines Codes auf dem dritten Sortierer 120c ein
Architekturfehler (z. B. ein Seitenfehler) oder ein Mikroarchitektur-Fehlerzustand
(z. B. ein TLB-Miss) [TLB(translation look-aside buffer)-Miss: verlorengegangener Übersetzungs-Lookaside-Puffer)
z. B. in Bezug auf Übersetzungen
von virtuellen in physische Adressen auftritt, der Fehlerzustand
an dem dritten Sortierer 120c über Adressübersetzungsmechanismen an dem
ersten Sortierer 120a behandelt werden, die von dem nativen
OS implementiert werden. Wie in
-
2 gezeigt,
sendet daher bei einem derartigen Fehlerzustand der dritte Sortierer 120c eine Nachricht,
z. B. über
eine SXFR-Nachricht, an den ersten Sortierer 120a. Der
erste Sortierer 120a kann wiederum ein Fehlerbehandlungsverfahren
durchführen,
das Hardware-, Software- oder
Firmware-gestützt
oder eine Kombination davon sein kann, um zu ermitteln, ob die fehlerhafte
Adresse in einem mit dem Prozessor 110 verbundenen ersten Übersetzungs-Lookaside-Puffer
(TLB) 130 vorhanden ist. Wenn nicht, wird ein Page-Walk-Mechanismus
initiiert, damit die angeforderte Seite aus einer Seitentabelle 135 erhalten
wird und in dem ersten TLB 130 gespeichert wird. Man beachte,
dass der Page-Walk-Mechanismus von dem ersten TLB 130 zu der
Seitentabelle 135 entsprechend einem OS-aktivierten Page-Walk-Mechanismus
implementiert ist, der in der Hardware, die ein herkömmliches
Prozessor-TLB-Design hat, und in der OS-Software unterstützt wird,
die das virtuelle Speichersystem hat. Daher wird diese Übersetzung
von virtuellen in physische Adressen (z. B. Seitentabellen-Eintrag)
in dem Format des Sortierers 120a entsprechend einem Adressübersetzungs-Remapping-Mechanismus
(Remapper) 145 in ein Format geremappt, das dem dritten
Sortierer 120c nativ ist. Diese geremappte Seiten-Übersetzung
kann dann für
einen zweiten TLB 140 bereitgestellt werden, der mit dem
dritten Sortierer 120c verbunden ist. Der dritte Exo-Sortierer 120c kann
nun wiederum auf die physische Seite zugreifen, die von dem ersten
Sortierer 120a bereitgestellt wird. Dadurch können die
Sortierer 120a und 120c den normalen virtuellen
Adressraum trotz der Heterogenität
zwischen den beiden Sortierer gemeinsam verwenden. Der Remapper 145 kann
in Hardware, Software oder Firmware oder einer Kombination davon
implementiert werden. Wie durch den Strichlinienkasten in 2 dargestellt
ist, kann darüber
hinaus die Funktionalität
des Remappers 145 zum Beispiel als Teil des ersten Sortierers 120a oder
des dritten Sortierers 120c implementiert werden. Auf diese Weise
wird der Fehlerzustand in einem nativen Modus behandelt, und die
angeforderten Informationen werden für den dritten Sortierer 120c bereitgestellt, sodass
ein Fehlerzustand einer heterogenen Ressource, z. B. des dritten
Sortierers 120c, mit einem OS, das auf einem OMS läuft, z.
B. dem ersten Sortierer 120a, elegant behandelt werden
kann.
-
Man
beachte bei der Ausführungsform
von 2 weiterhin, dass weitere Ebenen einer Speicherhierarchie
vorhanden sind. Wie in 2 gezeigt, ist insbesondere
ein Cache-Speicher 150 mit dem ersten TLB 130 verbunden,
und ein entsprechender Cache-Speicher 160 ist
mit dem zweiten TLB 140 verbunden. Die Caches 150 und 160 sind
wiederum mit einem Speicher 170 verbunden, der bei einer Ausführungsform
ein dynamischer Schreib-Lese-Speicher
(DRAN) sein kann. Zwar sind die Caches 150 und 160 bei
der Ausführungsform von 2 mit
dieser speziellen Implementierung gezeigt, aber es ist klar, dass
der Schutzumfang der vorliegenden Erfindung in dieser Hinsicht nicht
beschränkt ist.
-
Bei
verschiedenen Implementierungen können andere Verfahren zur Durchführung der
Fehlerbehandlung realisiert werden. Kommen wir nun zu 3.
Hier ist ein Ablaufdiagramm eines Verfahrens zur Behandlung eines
Fehlerzustands bei einer heterogenen Ressource nach einer Ausführungsform
der vorliegenden Erfindung gezeigt. Wie in 3 gezeigt,
kann ein Verfahren 200 damit beginnen, dass ermittelt wird,
ob ein Übersetzungsfehler
bei einem Exo-Sortierer aufgetreten ist (Rhombus 210).
Dieser Übersetzungsfehler
kann einem Architektur- oder Mikroarchitektur-Fehlerzustand hinsichtlich
einer Übersetzung
von virtuellen in physische Adressen entsprechen. Beim Auftreten
eines solchen Fehlers kann der Exo-Sortierer seine Code-Abarbeitung
aussetzen und Informationen zu dem Fehler aufzeichnen (Block 220).
insbesondere kann der Exo-Sortierer den fehlerhaften Befehlszustand
aufzeichnen, der die fehlerhafte(n) virtuelle(n) Adresse(n) enthält. Diese
fehlerhaften Adressen können
einer oder mehreren virtuellen Adressen entsprechen, die in einem Übersetzungspuffer,
wie etwa einem TLB des Exo-Sortierers, nicht verfügbar sind.
Wenn kein solcher Fehler auftritt, geht die Steuerung zum Block 215 weiter,
wo die weitere Ausführung
von Befehlen in dem Exo-Sortierer erfolgen kann, wobei die Steuerung
zu dem Rhombus 210 zurückgeht.
-
Wir
beziehen uns immer noch auf 3. Hier
geht die Steuerung von dem Block 220 zu einem Block 230.
Hier kann der Fehler einem OMS mitgeteilt werden (Block 230).
Insbesondere kann der Exo-Sortierer dem OMS ein Signal senden, um
ihm den Fehler mitzuteilen. Bei einer Ausführungsform kann ein Proxy-Abarbeitungsanforderungssignal
gesendet werden. Ein solches Signal kann mit Nachrichten-Informationen
zu dem Fehler gesendet werden. Diese Informationen können eine
Identifikation des Fehlertyps und die fehlerhafte(n) Adresse oder Adressen
enthalten. Bei einigen Ausführungsformen können die
Informationen zu dem Fehler in der Nachricht einen Zeiger auf eine
Speicherzelle liefern, auf die der Exo-Sortierer und der OMS zugreifen
können, wie
etwa ein Register oder ein physischer Speicher, in dem Deskriptoren
mit Einzelheiten des Fehlers gespeichert sind. Diese Informationen
können
dann von dem OMS während
seiner Proxy-Abarbeitung abgerufen werden, und umgekehrt kann das
Ergebnis der Proxy-Abarbeitung dort gespeichert werden, damit es
der Exo-Sortierer später
abrufen kann. Bei einigen Ausführungsformen
kann ein nativer adressentragender Datentyp für den Exo-Sortierer für den fehlerhaften
Befehl mehrere Adressen haben, die Fehler haben. Zum Beispiel könnte ein
GPU-Exo-Sortierer einen Übersetzungsfehler
in einem nativen Datentyp eines Vektors oder einer Matrix haben,
während
der OMS (wie etwa ein IA-32-Prozessor) normalerweise nur skalare
Datentypen, wie etwa Wort, Byte usw., für den Speicherzugriff unterstützt. Daher
kann bei diesen Ausführungsformen
der Exo-Sortierer dafür
verantwortlich sein, dem OMS die Art und Weise mitzuteilen, in der
die Fehlerbehandlung erfolgen sollte, z. B. eine Adresse auf einmal
oder Bündeln
von mehreren Adressen in einer gesamten Proxy-Abarbeitungsanforderung.
-
In
Reaktion auf das Proxy-Abarbeitungsanforderungssignal kann der OMS
den Übersetzungsfehler
behandeln (Block 240). Insbesondere kann ein nativer Übersetzungsfehler-Behandlungsmechanismus
des OMS zum Durchführen
der Behandlung aktiviert werden. Der Handler kann einen Zugriff
auf eine fehlerhafte Adresse durchführen, um zu gewährleisten,
dass der Fehler an dem OMS behoben wird. Wenn der gewünschte Speicherbereich,
der der fehlerhaften Adresse (z. B. einer Seite) entspricht, nicht in
einem mit dem OMS assoziierten Übersetzungspuffer
(wie etwa einem TLB) resident ist, kann bei dem Handler ein TLB-Miss-Fehler auftreten,
wenn er den Zugriff ausführt.
Das kann wiederum den Page-Walker des OMS dazu aktivieren, den angeforderten
Seiteneintrag aus dem Speicher zu erhalten und den TLB entsprechend
zu aktualisieren. Wenn stattdessen bei dem Zugriff ein Seitenfehler
auftritt, wird der OS-Paging-Mechanismus an dem OMS aktiviert, wodurch
die angeforderte Seite aus dem externen Speicher, wie etwa einer
Platte, in den Hauptspeicher gebracht wird und die Seitentabellen
entsprechend aktualisiert werden, und der entsprechende Seiteneintrag
wird in dem TLB des OMS gespeichert. In jedem Fall kann der Seitentabellen-Eintrag,
der der angeforderten Seite entspricht, dann in das Format des Exo-Sortierers übersetzt
werden (Block 250). Auf diese Weise kann ein Adressübersetzungs-Remapping-Verfahren
durchgeführt
werden. Das heißt,
wegen des Format-Unterschieds bei Paging-Systemen zwischen dem OMS
und dem Exo-Sortierer kann das Seitentabellen-Eintragsformat für den OMS
in das Format des Exo-Sortierers „transformiert" oder „transcodiert" werden. Bei verschiedenen
Ausführungsformen
kann dieser Prozess von dem OMS oder dem Exo-Sortierer oder einer
Zwischenstufe durchgeführt
werden.
-
Wir
beziehen uns immer noch auf 3. Wenn
der OMS die Proxy-Abarbeitung
beim Zugreifen auf die fehlende Seite beendet, kann er dem Exo-Sortierer
die Beendigung der Proxy-Abarbeitung mitteilen (Block 260).
Dadurch kann die Abarbeitung an dem Exo-Sortierer wieder aufgenommen
werden. Daher kann der Exo-Sortierer die ausgesetzte Abarbeitung
wieder aufnehmen und kann den fehlerhaften Befehl neu ausführen (Block 270).
Wie in 3 gezeigt, geht die Steuerung von dem Block 270 zu dem
Block 215 für
eine weitere Exo-Sortierer-Abarbeitung. Über die von dem OMS durchgeführte Seiten-Aktualisierung
dürfte
der zuvor fehlerhafte Befehl keinen Fehler mehr haben und der Exo-Sortierer kann
vorankommen. Andernfalls kann bei dem Rhombus 210 das Auftreten
eines anderen Übersetzungsfehlers
festgestellt werden und das Verfahren 200 kann weiter abgearbeitet
werden. Es ist zwar diese spezielle Implementierung bei der Ausführungsform
von 3 beschrieben worden, aber es ist klar, dass der
Schutzumfang der vorliegenden Erfindung in dieser Hinsicht nicht
beschränkt
ist.
-
Unter
Verwendung des Verfahrens 200 oder eines ähnlichen
derartigen Verfahrens zum Behandeln von Übersetzungsfehlern in einem
OMS eines Systems können
Seitenfehler oder TLB-Fehler an einem Exo-Sortierer von einem Universal-OMS
in einem Proxy-Abarbeitungsmodus trotz unterschiedlicher Übersetzungsmechanismen
behandelt werden. Daher braucht der Exo-Sortierer das Emulieren
oder anderweitige Durchführen
von exakten Adressübersetzungen
mit der nativen ISA des OMS nicht zu unterstützen. Auf diese Weise braucht
der Exo-Sortierer nicht mit dem nativen Page-Walk-Mechanismus des OMS
erweitert zu werden. Zum Beispiel braucht bei einem IA-32-OMS ein
GPU-Exo-Sortierer mit einer ATR-Unterstützung keine
IA-32-Paging-Mechanismus-Unterstützung
direkt in seiner Hardware zu implementieren. Stattdessen braucht
er nur einen Seitenfehler oder ein TLB-Miss in seinem eigenen Paging-Unterstützungsmechanismus
zu erkennen und dann den ATR-Mechanismus zu aktivieren und auf die
Proxy-Abarbeitung des OMS auszuweichen, um das OS auf dem OMS zum
Durchführen
der Adressübersetzung
für den
Exo-Sortierer zu verwenden. Nach der Proxy-Abarbeitung kann der Seiteneintrag auf
das Format der GPU geremappt werden und in dem TLB der GPU installiert
werden. Wenn die geremappten Übersetzungen
(z. B. Seitentabellen-Eintrag) von dem OMS für den Exo-Sortierer bereitgestellt
werden, kann der native Page-Walk-Mechanismus (z. B. ein GPU-Seiteneintragsformat
einer Microsoft®-Windows-Advanced-SchedulerTM-Konfiguration) des Exo-Sortierers so implementiert
werden, dass die Übersetzung
von virtuellen in physische Adressen der richtigen Speicherstelle
an einem Speicherplatz oder in einem Adressraum des gemeinsamen
virtuellen Speichers entspricht. Dadurch können der OMS und der Exo-Sortierer
trotz des Unterschieds in ihren Hardware-Mechanismen zur Unterstützung der
Adressübersetzung
einen gemeinsamen virtuellen Speicher implementieren.
-
Kommen
wir nun zu 4. Hier ist ein Blockdiagramm
eines Teils eines Systems nach einer weiteren Ausführungsform
der vorliegenden Erfindung gezeigt. Wie in 4 gezeigt,
weist ein System 300 einen Prozessor 110 auf,
der dem Prozessor 110 von 2 entsprechen
kann. Zur Erleichterung der Erläuterung
sind in 4 nur die Sortierer 120a–d und die
ISA 115 für
den Prozessor 110 gezeigt.
-
Zum
Behandeln von Ausnahmen [z. B. Gleitkomma(FP)-Überlauf oder -Unterlauf], die
an dem Exo-Sortierer auftreten, über
OMS-Mechanismen als Strukturausnahmenbehandlung (structural exception handlung,
SEH) in dem OMS-Code-Ablauf kann die Proxy-Abarbeitung Ausnahmen,
die an dem Exo-Sortierer auftreten, über einen CEH-Mechanismus (CEH:
collaborative exception handler; kollaborativer Ausnahmen-Handler)
unterstützen.
Ein CEH kann in bestimmten Situationen verwendet werden, da einerseits
eine bestimmte Ausnahmenbehandlung [z. B. die Doppelpräzisions-FP-Ausnahmenbehandlung
des IEEE (Institute of Electrical and Electronics Engineers)] eine
signifikante Komplexität
bei der Hardware-(sowie Software-)Implementierung erfordert und
andererseits Industriestandard-Mikroprozessoren
und herkömmliche
Betriebssysteme die Ausnahmenbehandlung bereits umfangreich unterstützen. Bei
einem gegebenen Exo-Sortierer kann mit einem CEH die Hardware dadurch
vereinfacht werden, dass der OMS (normalerweise ein Universalprozessor,
wie etwa ein IA-32-Prozessor) dazu gewonnen wird, einen bestehenden
OMS-Mechanismus, wie etwa die Strukturausnahmenbehandlung, zum Behandeln
der Ausnahme für
den Exo-Sortierer zu verwenden. Die Exo-Sortierer-Hardware kann
die Ausnahme erkennen und den OMS davon benachrichtigen, damit er
eine Proxy-Abarbeitung anfordert.
-
Bei
verschiedenen Implementierungen kann der dritte Sortierer 120c andere
native Datentypen haben, an denen Operationen ausgeführt werden. Wenn
Ausnahmen während
Operationen an dem dritten Sortierer 120c auftreten, bewirken
daher diese anderen nativen Datentypen eine andere Ausnahmenbehandlung
als die Ausnahmenbehandlung, die in dem ersten Sortierer 120a durchgeführt wird.
Zum Beispiel können
der erste Sortierer 120a und das native OS die Standard-Gleitkomma(FP)-Ausnahmenbehandlung
unterstützen,
da FP ein nativer Datentyp auf dem ersten Sortierer 120a ist.
Einige Implementierungen des dritten Sortierers 120c können jedoch Vektoren
von FPs unterstützen,
und somit können SIMD-Operationen
für diese
zusammengesetzten Datentypen auf dem dritten Sortierer 120c verwendet werden.
Wenn eine Ausnahme auftritt, impliziert daher die Behandlung der
Ausnahme einen zusammengesetzten nativen Datentyp, der von dem ersten Sortierer 120a oder
dem zugrunde liegenden OS nicht verstanden wird.
-
Um
eine andere Ausnahmenbehandlung in den Sortierern zu bewirken, kann
ein erster Ausnahmen-Handler 320, der mit dem ersten Sortierer 120a assoziiert
ist, andere Mechanismen als ein zweiter Ausnahmen-Handler 350 haben,
der mit dem dritten Sortierer 120c assoziiert ist. Um die
Unterstützung
zu reduzieren, die in dem dritten Sortierer 120c erforderlich
ist, kann die Ausnahmenbehandlung auf den ersten Sortierer 120a übertragen
werden. Daher sendet der dritte Sortierer 120c ein Signal
an den ersten Sortierer 120a und teilt ihm die Ausnahme
mit. In Fällen, in
denen der native Datentyp, an dem die Ausnahme entstanden ist, von
dem Datentyp an dem ersten Sortierer 120a abweicht, für den die
Ausnahme hinsichtlich der Architektur behandelt werden kann, kann eine
Transformation durchgeführt
werden, z. B. durch Zerlegen von Vektor-FPs in skalare FPs und durch Mappen
der Ausnahmezustände
an den Vektor-FPs zu Skalare-FP-Ausnahmen, die von dem ersten Sortierer 120a verstanden
werden können.
Dann kann der dritte Sortierer 120c dem ersten Sortierer 120a ein
Signal für
die Proxy-Verarbeitung
der Anforderung der Ausnahme senden. Bei einigen anderen Ausführungsformen
kann der dritte Sortierer 120c die Abarbeitung aussetzen
und sich darauf verlassen, dass der erste Sortierer 120a seine
Zustände
(über einen
Zustands-SAVE-Mechanismus) später
anfordert und dann Software-Verfahren verwendet, um das Auftreten
von Ausnahmen an dem dritten Sortierer zu emulieren. Außerdem kann
ohne Verlust der Allgemeingültigkeit
angenommen werden, dass der erste Sortierer 120a ein OMS
ist, obwohl er im Allgemeinen ein anwendungsverwalteter Sortierer
sein kann, der die Ausnahme ohne Einbeziehung eines OS-Dienstes
behandeln kann (zum Beispiel kann das Festlegen einer bestimmten
Ausnahme über eine
Anwendungs-Software-Emulation
erfolgen).
-
Wenn
das Proxy-Abarbeitungsanforderungssignal von dem dritten Sortierer 120c an
dem ersten Sortierer 120a verarbeitet wird, kann der Handler
auf den Ausnahmenbericht zugreifen und gewährleisten, dass die Ausnahme
dort behoben wird. Die Behandlung der Ausnahme auf dem OMS kann über Hardware,
Firmware oder Software erfolgen, die auf dem ersten Sortierer 120a läuft (unter
anderem z. B. über einen
OS-Ausnahmen-Handler und einen SEH-Behandlungs-Software-Stapel).
-
Aufgrund
von Format-Unterschieden in nativen Datentypen zwischen dem ersten
Sortierer 120a und dem dritten Sortierer 120c kann
es erforderlich sein, das Ausnahmenfestlegungs-Datenformat auf dem
ersten Sortierer 120a in das Format des dritten Sortierer 120c zu „transformieren" oder zu „transcodieren". Diese Transformation
kann in Abhängigkeit von
dem mit der Ausnahme assoziierten Datentyp (mit einfacher Genauigkeit,
mit doppelter Genauigkeit usw.) in der Hardware, Firmware oder Software erfolgen.
Wenn der erste Sortierer 120a die Proxy-Abarbeitung zum
Festlegen der Ausnahme beendet, teilt er dem dritten Sortierer 120c die
Beendigung der Proxy-Abarbeitung mit, und die ausgesetzte Abarbeitung
wird an dem dritten Sortierer 120c fortgesetzt. Dadurch
nimmt der dritte Sortierer 120c die Abarbeitung wieder
auf, als ob das Festlegen lokal erfolgt wäre, und er kommt weiter voran.
-
Wie
in 4 gezeigt, kann ein Übersetzungsmechanismus, der
als CEH 340 bezeichnet wird, das angeforderte Ausnahmen-Ergebnis
in dem ersten Ausnahmen-Handler 320 für den zweiten Ausnahmen-Handler 350 in
seinem nativen Format bereitstellen. Wie durch den Strichlinienkasten
in 4 dargestellt ist, kann die Funktionalität des CEH 340 zum
Beispiel als Teil des ersten Sortierers 120a oder des dritten
Sortierers 120c implementiert werden. Auf diese Weise wird
ein Ausnahmezustand in einem Modus so behandelt, dass eine Ausnahme
einer heterogenen Ressource, z. B. des dritten Sortierers 120c,
von einem OS, das auf einem OMS läuft, elegant behandelt werden
kann, und das Ergebnis der Proxy-Abarbeitung wird für den dritten
Sortierer 120c bereitgestellt.
-
Bei
verschiedenen Implementierungen können andere Verfahren zur Durchführung der
Ausnahmenbehandlung realisiert werden. Kommen wir nun zu 5,
wo ein Ablaufdiagramm eines Verfahrens zur Behandlung eines Ausnahmezustands
in einer heterogenen Ressource nach einer Ausführungsform der vorliegenden
Erfindung gezeigt ist. Wie in 5 gezeigt,
kann ein Verfahren 400 damit beginnen, dass ermittelt wird,
ob eine Ausnahme in einem Exo-Sortierer aufgetreten ist (Rhombus 410).
Diese Ausnahme kann einer numerischen Ausnahme, z. B. einer FP-Ausnahme,
entsprechen. Beim Auftreten einer solchen Ausnahme kann der Exo-Sortierer
seine Code-Abarbeitung aussetzen und Informationen zu der Ausnahme
aufzeichnen (Block 420). Insbesondere kann der Exo-Sortierer
den Befehl, der den Ausnahmezustand verursacht hat, und einen Ausnahmenbericht
aufzeichnen. Wenn keine solche Ausnahme auftritt, geht die Steuerung
zum Block 415, wo die Weiterausführung von Befehlen in dem Exo-Sortierer erfolgen
kann, wobei die Steuerung zu dem Rhombus 410 zurückgeht.
-
Wir
beziehen uns immer noch auf 5. Hier
geht die Steuerung von dem Block 420 zu einem Block 430.
Hier kann die Ausnahme einem OMS mitgeteilt werden (Block 430).
Insbesondere kann der Exo-Sortierer dem OMS ein Signal senden, um
ihm die Ausnahme mitzuteilen. Bei einer Ausführungsform kann ein Proxy-Abarbeitungsanforderungssignal
gesendet werden. Ein solches Signal kann mit Nachrichten-Informationen
zu der Ausnahme gesendet werden. Diese Informationen können eine
Identifikation des Ausnahmentyps und die Adresse des die Ausnahme
verursachenden Befehls enthalten. Es können auch andere Verfahren
zum Weiterleiten einer Ausnahme an den OMS realisiert werden. Bei
einigen Ausführungsformen
kann zum Beispiel der Exo-Sortierer eine Zwischen-Sortierern-Kommunikation mit
der Identifikation einer Ausnahme zusammen mit einem Befehlszeiger
(z. B. EIP) senden, damit der OMS die Ausnahme behandeln kann, oder
es kann auch ein Zeigergestütztes
Verfahren, das vorstehend dargelegt worden ist, implementiert werden.
-
In
Reaktion auf das Proxy-Abarbeitungsanforderungssignal kann der OMS
die Ausnahme behandeln (Block 440). Insbesondere kann ein
nativer Ausnahmenbehandlungsmechanismus des OMS zum Durchführen der
Behandlung aktiviert werden. Der Handler kann auf den Ausnahmenbericht
zugreifen und die Ausnahme beheben. Als Beispiel kann der OMS den
Befehl, auf den der Befehlszeiger zeigt, wiedergeben und die angeforderte
Operation in der Software emulieren. Bei einigen Ausführungsformen kann
diese Emulation in das native OS integriert werden. Nach Beendigung
der Proxy- Ausnahmenbehandlung
auf dem OMS kann das Ausnahmen-Ergebnis in das Format des Exo-Sortierers übersetzt werden
(Block 450). Dadurch kann eine kollaborative Ausnahmenbehandlungsübersetzung
erfolgen. Bei verschiedenen Ausführungsformen
kann dieser Prozess von dem OMS oder dem Exo-Sortierer oder einer
Zwischenstufe durchgeführt
werden, um das Ergebnis in ein Format des Exo-Sortierers zu transformieren.
Zum Beispiel kann bei einer Ausführungsform
der OMS ein Speicherbild des Exo-Sortierers nach dem Festlegen der
Ausnahmenbehandlung aktualisieren und dann mit einem Rückspeicherbefehl das
Speicherbild wieder zurück
in den Exo-Sortierer speichern, bevor er seine Abarbeitung wieder
aufnimmt.
-
Wir
beziehen uns immer noch auf 5. Wenn
der OMS die Proxy-Abarbeitung
beim Behandeln der Ausnahme beendet, kann er ein Signal über die
Beendigung der Proxy-Abarbeitung an den Exo-Sortierer senden (Block 460).
Dadurch kann die Abarbeitung an dem Exo-Sortierer weitergehen (Block 415).
Es ist zwar diese spezielle Implementierung bei der Ausführungsform
von 5 beschrieben worden, aber es ist klar, dass der
Schutzumfang der vorliegenden Erfindung in dieser Hinsicht nicht beschränkt ist.
Unter Verwendung des Verfahrens 400 oder eines ähnlichen
derartigen Verfahrens zum Behandeln von Ausnahmen in einem OMS eines Systems
können
Ausnahmen auf einem Exo-Sortierer von einem Universal-OMS in einem Proxy-Abarbeitungsmodus
trotz unterschiedlicher Ausnahmenbehandlungsmechanismen behandelt
werden. Daher braucht der Exo-Sortierer das Emulieren oder anderweitige
Durchführen
der Ausnahmenbehandlung nicht zu unterstützen.
-
Dadurch
kann unter Verwendung von Ausführungsformen
in der vorliegenden Erfindung die Gestaltung der Hardware und/oder
Software eines Exo-Sortierers vereinfacht werden und die Funktionalität zum Behandeln
verschiedener Ausnahmen, wie etwa Architektur-Gleitkomma-Ausnahmen oder Ausnahmen
zu anderen Architektur-Ereignissen, kann über die Proxy-Abarbeitung zurück auf einen OMS übertragen
werden. Auf diese Weise kann der Exo-Sortierer so konfiguriert und optimiert
werden, dass er die Rechenverarbeitung bestimmter Funktionen, wie
etwa Grafikverarbeitung oder anderen Fixed-Function-Operationen,
durchführt,
ohne die Logik zu erhöhen
oder kritische Pfade mit Unterstützung
für die
Ausnahmenbehandlung zu verzögern. Stattdessen
kann der Exo-Sortierer eine Ausnahme aufstellen, wenn ein solches
Architektur-Ereignis auftritt, und kann die Behandlung auf den OMS übertragen.
-
Bei
weiteren Ausführungsformen
kann eine Unterstützung
für künftige Verbesserungen
der Hardware eines Exo-Sortierers durch Ausnahmenbehandlung nach
einer Ausführungsform
der vorliegenden Erfindung realisiert werden. Das heißt, es können Befehle
oder andere Programmierungskonstrukte implementiert werden, um neue
Funktionen bei der Hardware zu ermöglichen. Um jedoch verschiedene Entwicklungsprozesse,
wie etwa frühe
Software-Aktivierung, zu unterstützen,
können
diese Befehle oder Konstrukte definiert werden und verfügbar sein,
bevor die Hardware vollständig
in einem Exo-Sortierer implementiert worden ist.
-
Um
nun die Ausführung
dieser Befehle oder Konstrukte zu ermöglichen und Entwicklungszyklen zu
beschleunigen, können
Ausführungsformen
eine Ausnahmenbehandlung implementieren, um eine Emulation dieser
Operationen durchzuführen.
Wenn ein Exo-Sortierer mit einem solchen Befehl oder Konstrukt konfrontiert
wird, kann der Exo-Sortierer eine Ausnahme aufstellen, die über CEH,
z. B. über
eine Zwischen-Sortierern-Kommunikation, für den OMS bereitgestellt wird.
Der OMS kann diese Ausnahme behandeln, z. B. durch Emulieren des
Betriebs in der Software auf dem OMS. Dadurch können Entwicklungszyklen verbessert
werden, da zahlreiche Patches, die die Emulation neuer Exo-Sortierer-Funktionen
ermöglichen,
implementiert werden können, ohne
dass das Patchen des begrenzten Mikrocode-Raums eines Exo-Sortierers
oder mehrere Hardware-Revisionen erforderlich sind, die die Verzögerungen
erfordern, die mit neuen Masken und neuer Waferfertigung verbunden
sind.
-
Um
zum Beispiel eine Entwicklung zu ermöglichen, kann ein Exo-Sortierer
einen Befehlsdecodierungsmechanismus für neue Befehle bereitstellen. Alles,
was zu tun ist, ist jedoch, diese Befehle zu decodieren, damit der
Exo-Sortierer eine Ausnahme aufstellen kann, sodass der OMS die
Ausnahme behandeln kann. Auf diese Weise kann die Software-Entwicklung weitergehen,
bevor wirklich die volle Hardware-Funktionalität in dem Exo-Sortierer bereitgestellt
wird.
-
Unter
Verwendung von Ausführungsformen der
vorliegenden Erfindung kann ein gemeinsamer virtueller Speicherplatz
von dem Exo-Sortierer und dem OMS genutzt werden. Dadurch kann die
Notwendigkeit von OS-gestützten
Treibern und dem damit verbundenen Overhead vermieden werden. Darüber hinaus
kann auch der Overhead von gesonderten Adressräumen für einen OMS und einen Exo-Sortierer
eliminiert werden. Dadurch können
ineffiziente DMA-Übertragungen
von Daten zwischen dem Exo-Sortierer und dem OMS über OS-Mechanismen
vermieden werden (DMA: direct memory access; direkter Speicherzugriff).
Stattdessen können Datenübertragungen
von dem Exo-Sortierer zu dem OMS (und umgekehrt) durch Weiterleiten
von Zeigern zu Zellen in dem gemeinsamen Speicher implementiert
werden, ohne dass Daten tatsächlich übertragen
werden müssen,
was Zeit spart und die Kompensationskosten senkt. An und für sich können die Kommunikation
zwischen Sortierern und die Datenmanipulation zwischen ihnen in
einer OS-unabhängigen
Weise erfolgen, was die Komplexität und den Overhead verringert.
-
Sortierer
mit unterschiedlichen Fehler- und Ausnahmenstrukturen können somit
hinsichtlich der Architektur so integriert werden, dass ein Einbild-OS verschiedene
Ausnahmen behandeln kann, um bekannte (d. h. Legacy-)Ausnahmenbehandlungsmodelle,
wie etwa SEH und dergleichen, zu unterstützen, und dass ein gemeinsames
virtuelles Speichersystem stabil unterstützt werden kann. Dadurch braucht
die Exo-Sortierer-Hardware nicht die Funktionalität und Komplexität der ISA
eines OMS zu haben oder zu replizieren, um Ausnahme- und Fehlerzustände autonom
zu behandeln. Vielmehr braucht der Exo-Sortierer nur seinen eigenen
Fehler und seine eigene Ausnahme zu erkennen, und ein Veneer-Stub
(z. B. ein Exo-Skelett)
oder ein anderer Mechanismus kann das Datenformat übersetzen
und den Ausnahmeoder Fehlerzustand an den OMS melden, der eine umfassende
Behandlung durchführen kann.
Das Ergebnis wird dann in das native Format des Exo-Sortierers (z.
B. Seitentabellen-Eintragsformat
oder natives zusammengesetztes Datenformat) zurück übersetzt.
-
Somit
braucht die Hardware eines Exo-Sortierers nicht die Logik und Komplexität des Paging-Mechanismus
und/oder des Ausnahmenbehandlungsmechanismus eines OMS zu replizieren. Stattdessen
kann der Exo-Sortierer einen minimalen Aufhänger zum Erkennen einer Ausnahme/eines Fehlers
liefern, die Abarbeitung aussetzen, dem OMS mitteilen, dass es die
Proxy-Abarbeitung durchführen
soll, und Ergebnisse empfangen und zurück zu dem Exo-Sortierer übertragen.
Diese Aktivitäten können mit
minimalen Kosten und außerhalb
des kritischen Pfads durchgeführt
werden. Daher kann aus der Perspektive des Programmierungsmodells
ein Exo-Sortierer, der einen virtuellen Speicher gemeinsam mit dem
OMS verwendet, viel leichter zu programmieren sein, da Synchronisations-Software-Paradigmen, die auf
dem gemeinsamen Speicher basieren, verwendet werden können. Darüber hinaus können Anwendungen
Rechenfähigkeiten
des Exo-Sortierers direkt erschließen, ohne sich auf einen OS-Treiber
verlassen müssen,
der einen viel größeren Overhead
nach sich ziehen kann und die Vorteile der Integration zunichte
machen kann. Zum Beispiel müsste
ohne gemeinsamen Speicher ein Teil des Datenrechenverkehrs außerhalb
des Chips und über
z. B. einen Eingangsbus zwischen dem OMS und dem Exo-Sortierer ablaufen,
und das, obwohl der OMS und der Exo-Sortierer einen Last-Level Cache
gemeinsam verwenden. Im Gegensatz dazu kann bei einem Modell mit
gemeinsamem Speicher, das durch Ausführungsformen der vorliegenden Erfindung
ermöglicht
wird, der gemeinsame Arbeitssatz des OMS und des Exo-Sortierers in dem
kohärenten
Last-Level Cache resident sein, und es ist nicht erforderlich, den
Chip zu verlassen, um zu kommunizieren. Dadurch kann eine Anwendung,
die einen OMS und einen Exo-Sortierer in dem gleichen Thread-Kontext
verwendet, von der Bandbreite einer Chipintegrierter-Speicher-Hierarchie
profitieren und kann eine Leistung erzielen, die eine Treiber-gestützte Lösung nicht
erreichen kann.
-
Ausführungsformen
können
in vielen verschiedenen Systemtypen implementiert werden. Kommen
wir nun zu 6, wo ein Blockdiagramm eines
Systems nach einer Ausführungsform
der vorliegenden Erfindung gezeigt ist. Wie in 6 gezeigt, ist
ein Mehrprozessorensystem 500 ein Punkt-zu-Punkt-Verbindungssystem
und weist einen ersten Prozessor 570 und einen zweiten
Prozessor 580 auf, die über
eine Punkt-zu-Punkt-Verbindung 550 verbunden sind. Wie
in 6 gezeigt, kann jeder der Prozessoren 570 und 580 ein
Mehrkemprozessor mit einem ersten und einem zweiten Prozessorkern (d.
h. Prozessorkernen 574a und 574b und Prozessorkernen 584a und 584b)
sein. Jeder der Prozessoren 570 und 580 kann weiterhin
einen Exo-Sortierer, d. h. einen ersten Exo-Sortierer 575 und
einen zweiten Exo-Sortierer 585,
aufweisen. Wie vorstehend dargelegt worden ist, können die
Exo-Sortierer 575 und 585 heterogene Ressourcen
in Bezug auf die übrigen
Ressourcen der Prozessorkerne 570 und 580 sein.
Hier ist zwar nur ein einziger Exo-Sortierer pro Prozessor dargestellt,
aber es ist klar, dass der Schutzumfang der vorliegenden Erfindung
nicht hierauf beschränkt
ist und dass mehrere Exo-Sortierer in einem gegebenen Prozessor
vorhanden sein können.
-
Der
erste Prozessor 570 weist weiterhin einen Speichersteuer-Hub
(MCH) 572 und Punkt-zu-Punkt(P-P)-Schnittstellen 576 und 578 auf. Ebenso
weist der zweite Prozessor 580 einen MCH 582 und
P-P-Schnittstellen 586 und 588 auf. Wie in 6 gezeigt,
verbinden die MCHs 572 und 582 die Prozessoren
mit entsprechenden Speichern, und zwar einem Speicher 532 und
einem Speicher 534, die Teile eines Hauptspeichers sein
können,
der lokal an den entsprechenden Prozessoren angebracht ist.
-
Der
erste Prozessor 570 und der zweite Prozessor 580 können über eine
P-P-Verbindung 552 bzw. 554 mit
einem Chipsatz 590 verbunden werden. Wie in 6 gezeigt,
weist der Chipsatz 590 P-P-Schnittstellen 594 und 598 auf.
Darüber
hinaus weist der Chipsatz 590 eine Schnittstelle 592 zum Verbinden
des Chipsatzes 590 mit einer Hochleistungs-Grafikmaschine 538 auf.
Bei einer Ausführungsform
kann ein AGP-Bus 539 (AGP: Advanced Graphics Port) zum
Verbinden der Grafikmaschine 538 mit dem Chipsatz 590 verwendet
werden. Der AGP-Bus 539 kann die „Accelerated Graphics Port Interface
Specification, Revision 2.0" („Spezifikation für die Accelerated-Graphics-Port-Schnittstelle,
Fassung 2.0"), einhalten,
die am 4. Mai 1998 von Intel Corporation, Santa Clara, Kalifornien,
veröffentlicht wurde.
Alternativ kann eine Punkt-zu-Punkt-Verbindung 539 diese
Komponenten verbinden.
-
Der
Chipsatz 590 kann wiederum über eine Schnittstelle 596 mit
einem ersten Bus 516 verbunden werden. Bei einer Ausführungsform
kann der erste Bus 516 ein PCI-Bus (PCI: Peripheral Component
Interconnect) sein, der von der „PCI Local Bus Spezifikation,
Production Version, Revision 2.1" („Spezifikation
für den
lokalen PCI-Bus, Produktionsversion, Fassung 2.1") vom Juni 1995 definiert wird, oder
kann ein Bus wie der PCI-Expressbus oder ein anderer Eingabe-/Ausgabe(E/A)-Verbindungsbus der
dritten Generation sein, aber der Schutzumfang der vorliegenden
Erfindung ist nicht hierauf beschränkt.
-
Wie
in 6 gezeigt, können
zusammen mit einer Busbrücke 518,
die den ersten Bus 516 mit einem zweiten Bus 520 verbindet,
verschiedene Eingabe-/Ausgabe-Geräte 514 mit dem ersten
Bus 516 verbunden werden. Bei einer Ausführungsform
kann der zweite Bus 520 ein LPC-Bus (LPC: Low Pin Count;
geringe Anzahl von Anschlussstiften) sein. An den zweiten Bus 520 können verschiedene
Geräte angeschlossen
werden, unter anderem zum Beispiel eine Tastatur/Maus 522,
Kommunikationsgeräte 526 und
eine Datenspeichereinheit 528, wie etwa ein Plattenlaufwerk
oder eine andere Massenspeichervorrichtung, die bei einer Ausführungsform
einen Code 530 haben kann. Darüber hinaus kann ein Ton-Eingabe-/-Ausgabegerät 524 an
den zweiten Bus 520 angeschlossen werden. Man beachte,
dass auch andere Architekturen möglich
sind. Zum Beispiel kann ein System statt der Punkt-zu-Punkt-Architektur von 6 eine
Mehrpunktbus- oder eine andere derartige Architektur implementieren.
-
Ausführungsformen
können
in einem Code implementiert werden und können in einem Speichermedium
gespeichert werden, in dem Befehle gespeichert sind, die dazu verwendet
werden können, ein
System so zu programmieren, dass es die Befehle ausführt. Das
Speichermedium kann unter anderem jede Art von Platte umfassen,
wie etwa Disketten, optische Platten, CD-ROMS (Compact Disk Read-Only
Memories), CD-RWs (Compact Disk Rewritables) und magneto-optische
Platten, Halbleiteranordnungen, wie etwa ROMs (Read-Only Memories), RAMs
(Random Access Memories), wie etwa DRAMs (Dynamic Random Access
Memories), SRAMs (Static Random Access Memories), EPROMs (Erasable
Programmable Read-Only Memories), Flash-Speicher, EEPROMs (Electrically Erasable
Programmable Read-Only
Memories), magnetische oder optische Karten, oder jede andere Art von
Medien, die zum Speichern von elektronischen Befehlen geeignet sind.
-
Die
vorliegende Erfindung ist zwar anhand einer begrenzten Anzahl von
Ausführungsformen
beschrieben worden, aber Fachleute dürften zahlreiche Modifikationen
und Abwandlungen davon erkennen. Die beigefügten Ansprüche sollen alle diese Modifikationen
und Abwandlungen als innerhalb der Grundgedanken und des Schutzumfangs
dieser vorliegenden Erfindung liegend erfassen.
-
Zusammenfassung
-
Bei
einer Ausführungsform
umfasst die vorliegende Erfindung ein Verfahren zum Senden einer Anforderung
zum Behandeln eines Fehlers oder einer Ausnahme, der/die in einem
Beschleuniger auftritt, an einen mit diesem verbundenen ersten Befehlssortierer.
Der Beschleuniger kann eine heterogene Ressource in Bezug auf den
ersten Befehlssortierer sein, z. B. kann er eine andere Befehlssatz-Architektur
haben. In Reaktion auf die Anforderung kann der Fehler oder die
Ausnahme in dem ersten Befehlssortierer behandelt werden. Es werden
weitere Ausführungsformen
beschrieben und beansprucht.