-
Bezugnahme auf
verwandte Anmeldungen
-
Die vorliegende Anmeldung wird gleichzeitig mit
der gemeinsam zugewiesenen U.S.-Patentanmeldung Serien-Nr. [HP-Anwaltsaktenzeichen 10871852-1
durch Jack D. Mills, u. a.] mit dem Titel „Recovery from exception deferred
by speculative instructions" eingereicht.
-
Technisches
Gebiet der Erfindung
-
Diese Anmeldung bezieht sich allgemein
auf eine Befehlssatzarchitektur und Computerprogrammoptimierungen
und insbesondere auf eine Softwaresteuerung des Mechanismus, um
Ausnahmebedingungen (Ausnahmesituationen, Ablaufunterbrechungen)
von spekulativen Befehlen zurückzustellen.
-
Hintergrund
der Erfindung
-
Ein „Basisblock" ist ein zusammenhängender
Befehlssatz, der durch Zweige und/oder Zweigziele begrenzt ist,
der keine Zweige oder Zweigziele enthält. Dies impliziert, daß wenn ein
Befehl in einem Basisblock ausgeführt wird, alle Befehle in dem
Basisblock ausgeführt
werden, d. h. die Befehle, die innerhalb eines Basisblocks enthalten
sind, werden auf einer Alles-oder-Nichts-Basis ausgeführt. Die
Befehle innerhalb eines Basisblocks werden für eine Ausführung aktiviert, wenn die Steuerung
durch eine vorangehende Verzweigung an den Basisblock weitergeleitet
wird, die auf den Basisblock zielt. („Zielen", wie es hierin verwendet wird, umfaßt sowohl
das ausdrückliche
Zielen über
eine genommene Verzweigung sowie das implizite Zielen über eine
nichtgenommene Verzweigung). Das vorangehende besagt, daß alle Befehle
in dem Basisblock ausgeführt
werden müssen, wenn
die Steuerung zurück
zu einem Basisblock übertragen
wird; wenn die Steuerung nicht zurück zu dem Basisblock übertragen
wird, dann müssen
alle Befehle in dem Basisblock nicht ausgeführt werden. Die Handlung des
Ausführens oder
des Spezifizierens der Ausführung
eines Befehls, bevor die Steuerung an den Befehl weitergeleitet
wird, wird „Spekulation" genannt. Eine Spekulation,
die durch den Prozessor während
der Programmlaufzeit durchgeführt
wird, wird „dynamische
Spekulation" genannt,
während
eine Spekulation, die durch den Kompilierer spezifiziert wird „statische
Spekulation" genannt
wird. Die dynamische Spekulation ist in der Technik bekannt.
-
Zwei Befehle werden als „unabhängig" betrachtet, wenn
einer das Ergebnis des anderen nicht benötigt; wenn ein Befehl das Ergebnis
des anderen benötigt,
werden dieselben als „abhängige" Befehle bezeichnet.
Unabhängige
Befehle können
parallel ausgeführt
werden, während
abhängige
Befehle auf serielle Art und Weise ausgeführt werden müssen. Ein
Programmverhalten wird durch Identifizieren unabhängiger Befehle
und durch paralleles Ausführen von
so vielen derselben wie möglich
verbessert. Die Erfahrung zeigt, daß mehr unabhängige Befehle durch
Suchen über
mehrere Basisblöcke
gefunden werden können,
als durch Suchen innerhalb von nur einem einzelnen Basisblock gefunden
werden können,
wobei das gleichzeitige Ausführen
von Befehlen aus mehreren Basisblöcken Spekulation erfordert. Ein
Identifizieren und Planen unabhängiger
Befehle und dadurch ein Verbessern des Verhaltens ist eine der Hauptaufgaben
von Kompilierern und Prozessoren. Der Trend beim Kompilierer- und
Prozessor-Entwurf
war, den Umfang der Suche nach unabhängigen Befehlen bei jeder aufeinanderfolgenden
Erzeugung zu bewirken. Bei bekannten Befehlssätzen kann ein Befehl, der eine
Ausnahmebedingung erzeugen kann, durch den Kompilierer nicht spekuliert
werden, da das Programm fehlerhafterweise eine Ausnahmebedingung
erzeugen kann, wenn das Programm dies nicht tun sollte, wenn der
Befehl eine Ausnahmebedingung verursacht. Dies schränkt den
nützlichen Umfang
der Suche des Kompilierers nach unabhängigen Befehlen ein und macht
es notwendig, daß eine
Spekulation während
der Programmlaufzeit durch den Prozessor über eine dynamische Spekulation
durchgeführt
wird. Eine dynamische Spekulation zieht jedoch einen bedeutenden
Betrag an Hardwarekomplexität
mit sich und ferner erhöht
sich die Komplexität
exponential mit der Anzahl von Basisblöcken, über die eine dynamische Spekulation
angewendet wird – dies
erlegt dem Umfang der dynamischen Spekulation eine praktische Grenze
auf. Im Gegensatz dazu ist der Bereich, über den der Kompilierer nach
unabhängigen
Befehlen suchen kann, viel größer potentiell
das gesamte Programm. Ferner, sobald der Kompilierer entworfen wurde,
um eine statische Spekulation über
eine einzelne Basisblockgrenze durchzuführen, wird sehr wenig zusätzliche
Komplexität
durch statistisches Spekulieren über
mehrere Basisblockgrenzen hinzugefügt.
-
Wenn eine statische Spekulation unternommen
werden soll, dann müssen
mehrere Probleme gelöst
werden, wobei eines der wichtigsten das Handhaben von Ausnahmebedingungszuständen ist, die
durch statisch spekulierte Befehle angetroffen werden. Nachfolgend,
außer
eindeutig anderweitig angegeben, sollen hierin nachfolgend Bezugnahmen auf
die Spekulation, spekulative Befehle etc. genommen werden, um auf
statische und nicht dynamische Spekulation Bezug zu nehmen.
-
Da wie oben erwähnt Ausnahmebedingungen von
spekulativen Befehlen zu der Zeit der Ausführung der Befehle nicht geliefert
werden können, wird
ein kompilierersichtbarer Mechanismus benötigt, um die Lieferung der
Ausnahmebedingungen zurückzustellen,
bis die Steuerung an den Basisblock übertragen wird, von dem die
Befehle spekuliert wurden (bekannt als der „Ausgangsbasisblock"). Mechanismen, die
eine ähnliche
Funktion durchführen, existieren
in der Technik zum Zurückstellen
und zum späteren
Liefern von Ausnahmebedingungen von dynamisch spekulierten Befehlen,
die Mechanismen sind jedoch nicht durch Definition für den Kompilierer sichtbar
und können
daher durch den Kompilierer nicht manipuliert werden, um eine Rolle
bei der kompilierergeleiteten Spekulation zu spielen. Kein bekanntes
Verfahren oder keine Vorrichtung zum Zurückstellen und späteren Liefern
von Ausnahmebedingungszuständen
von statisch spekulierten Befehlen wurde in der bekannten Technik
ermöglicht.
Eingeschränkte
Formen statischer Spekulation existieren jedoch in der bekannten
Technik: (1) die Formen umfassen keine Zurückstellung und spätere Wiedergewinnung
der Ausnahmebedingungszustände,
und (2) diese Formen aktivieren keine statische Spekulation über die
Breite und den Schutzbereich der vorliegenden Erfindung.
-
Ein Beispiel einer eingeschränkten statischen
Spekulation gemäß dem Stand
der Technik ist eine Spezialhandhabung von Ladevorgängen von der
Speicherseite beginnend bei der Adresse Null – genannt „Seite Null". Bei den meisten
Systemen ist der Zugriff auf Seite Null illegal und verursacht üblicherweise
eine Schutzverletzungs-Ausnahmebedingung. Bei bestimmten bekannten
Systemen willigen der Kompilierer und das Betriebssystem (OS = Operating
System) beiderseits ein, daß Ausnahmebedingungen
betreffend Ladevorgängen
von Seite Null unterdrückt
(und nicht zurückgestellt)
werden müssen, und
daß in
dem Fall der Unterdrückung
der Zielort des Ladens mit Null geschrieben werden muß. Dies ermöglicht es
dem Kompilierer Ladevorgänge
zu spekulieren, die die Charakteristik besitzen, daß, wenn
dieselben auf illegalen Speicher zugreifen, dieselben dies nur über Seite
Null tun. Die Charakteristik tritt auf, da die Zahl Null manchmal
verwendet wird, um die Grenze von Datenstrukturen zu markieren und
ein Laden, das über
die Grenze hinaus geht, wird daher versuchen, auf die Adresse Null
zuzugreifen. Es sollte darauf hingewiesen werden, daß die eingeschränkte Form
der Spekulation, die soeben beschrieben wurde, keine Zurückstellung
und spätere Lieferung
von Ausnahmebedingungen umfaßt
oder ermöglicht,
und nur für
die schmale Klasse von Ladevorgängen
zutrifft, die die Charakteristik besitzen, wenn illegal, nur auf
Seite Null zuzugreifen. In dem Fall, daß das Laden definiert ist,
um Hilfsoperationen zusätzlich
zum Lesen des Speichers durchzuführen, z.
B. Hinzufügen
eines Werts zu einem Adreßregister,
ist das OS verantwortlich für
das softwaremäßige Emulieren
der Hilfsoperationen, wobei die Emulation das Programmverhalten
reduziert.
-
Ein anderes Beispiel einer eingeschränkten statischen
Spekulation gemäß dem Stand
der Technik ist die Spekulation von Befehlen, die keine Ausnahmebedingungen
verursachen. Der Vergleichsbefehl ist z. B. üblicherweise derart definiert,
daß er
keine Ausnahmebedingungen erzeugt. Ein ordnungsgemäß entworfener
Kompilierer kann dann den Vergleich spekulieren, da der einzige
Nebeneffekt das Schreiben eines Zielorts ist . In dem Fall, daß die Steuerung
nicht an den Ausgangsbasisblock des Vergleichs übertragen wird, wird der Zielort
einfach verworfen. Ein anderes Beispiel ist ein Ladebefehl von einer
Adresse, von der bekannt ist, daß dieselbe zu der Zeit des
Kompilierens gültig
ist, und daß dieselbe
während
der Laufzeit konstant bleibt, z. B. eine globale Variable. Diese
Bedingungen garantieren, daß,
wenn Ausnahmebedingungszustände
auftreten, dieselben nicht fatal sind und spekulativ ohne Nebeneffekte
gehandhabt werden können – obwohl
die Handhabung der spekulativen Ausnahmebedingungen das Gesamtverhalten
reduzieren kann. Es sollte wiederum darauf hingewiesen werden, daß die eingeschränkten Formen
der Spekulation, die soeben beschrieben wurden, keine Zurückstellung
umfassen und nur für
eine eingeschränkte
Klasse von Befehlen gelten. Daher, wenn eine statische Spekulation
unternommen wird, besteht ein Bedarf in der Technik, einen Mechanismus
zu aktivieren, um Ausnahmebedingungen in Bezug auf spekulative Befehle
zurückzustellen,
der an so viele Formen von Spekulationen angewendet werden kann,
wie möglich.
Der Mechanismus muß eine
sehr niedrige Latenz besitzen, da ansonsten das Verhalten eines
Programms, das mit einer Spekulation kompiliert ist, tatsächlich niedriger sein
kann, als das des selben Programms, das ohne Spekulation kompiliert
ist. Der Mechanismus muß der Form
und dem Aufbau der Software ferner minimale Ein schränkungen
auferlegen, um die Ausführung
von Ursprungssoftware zu ermöglichen,
um die Auswirkung auf Softwareentwickler zu minimieren und um den
Bereich der Softwareimplementierungsauswahlmöglichkeiten zu maximieren.
Eine gewünschte
Charakteristik des Mechanismus ist es, es dem Computersystem zu
ermöglichen,
sich dynamisch an das Programmverhalten anzupassen, um das Verhalten über den
breitest möglichen
Softwarebereich zu maximieren.
-
Die GB2294341A offenbart ein Verfahren zum
Unterstützen
der spekulativen Ausführung
in einer zentralen Verarbeitungseinheit. Das Verfahren umfaßt das Bezeichnen
von Operationen in der CPU (CPU = Central Processing Unit) als spekulativ
oder nichtspekulativ und dann das Zurückstellen von Ausnahmebedingungen,
die durch spekulative Operationen erzeugt werden, während die
Ausnahmebedingungen sofort berichtet werden, die durch nichtspekulative
Operationen erzeugt werden.
-
Während
die vorliegenden Erfindung für
einen Typ eines spekulativen Befehls gilt, verwendet die nachfolgende
Erörterung
den spekulativen Ladebefehl als Beispiel. Die Daten zeigen an, daß Ladevorgänge eine
der wichtigsten Befehlsklassen sind, um zu spekulieren. Es ist ferner
der Fall, daß Ladevorgänge den
breitesten Bereich von Ausnahmebedingungszuständen einnehmen, einschließlich Translationscachefehlgriffe,
erster Zugriff auf eine Seite, Schutzverletzungen und nichtvorhandene
Seite. Es wird ferner erwartet, daß spekulative Ladevorgänge relativ
zu nichtspekulativen Ladevorgängen dazu
neigen, mehr Ausnahmebedingungszustände anzutreffen. Dies liegt
an der Tatsache, daß die
Speicheradresse, auf die durch spekulative Ladevorgänge zugegriffen
wird, eine größere Wahrscheinlichkeit aufweist,
unsinnig zu sein, da laut Definition das spekulative Laden früher ausgeführt wird
als vom Programmierer beabsichtigt war.
-
Ein kompilierersichtbarer Mechanismus,
um Ausnahmebedingungszustände
zu handhaben, die durch spekulierte Befehle angetroffen werden,
ist der Gegenstand der IDEA-Anmeldung „Recovery from exceptions
deferred by speculative instructions", [HP Anwaltsaktenzeichen 10971852-1]
von Jack D. Mills, u. a., die gemeinsam eingereicht wird. Befehle
werden in zwei Klassen unterteilt: Spekulativ und nichtspekulativ.
Anfänglich
werden alle Befehle als nichtspekulativ gekennzeichnet. Wenn der
Kompilierer einen Befehl außerhalb
des Basisblocks des Befehls plant, markiert der Kompilierer den
Befehl als spekulativ. Spekulative Befehle, die einen Ausnahmebedingungszustand
antreffen, erzeugen keine Ausnahmebedingung, sondern schreiben ein „Zurückgestellte-Ausnahmebedingung-Token" (DET = Deferred
Exception Token) in ihren Zielort, eine Anmerkung, daß der Zielort
an diesem Punkt nicht das korrekte Ergebnis enthält. Ein nichtspekulativer Befehl,
der ein Zurückgestellte-Ausnahmebedingung-Token liest, erzeugt
eine Ausnahmebedingung. Ein spekulativer Befehl, der ein DET liest,
schreibt ein DET in den Zielort des Befehls (der Zielort enthält wiederum
nicht das korrekte Ergebnis), wobei dieses Verhalten „Ausbreitung" genannt wird. Durch
Plazieren eines nichtspekulativen Befehls in dem Ursprungsbasisblock
eines gegeben spekulativen Befehls und durch Konfigurieren des nichtspekulativen
Befehls, um einen Zielort des spekulativen Befehls zu lesen (oder
einen Ort, in den sich ein DET ausbreiten kann), kann dann ein DET,
das durch den spekulativen Befehl erzeugt wurde, in eine Ausnahmebedingung
umgewandelt werden, an dem Punkt, an dem die Steuerung an den Ursprungsbasisblock
weitergegeben wird. Nachdem ein DET in eine Ausnahmebedingung umgewandelt wird
und der Ausnahmebedingungszustand korrigiert ist, ist es notwendig,
alle vorangehend erzeugten DETs durch korrekte Ergebnisse zu ersetzen.
Dies wird durch einen Prozeß erreicht,
der „Erholung" genannt wird. Eine
Erholung erfordert, daß das
Programm mit einem zusätzlichen
Code vergrößert wird, der
durch den Kompilierer erzeugt wird. Ein Kompilierer kann wählen, keinen
Erholungscode zu umfassen, z. B. um die Programmgröße zu mini mieren,
wobei in diesem Fall die Möglichkeit,
Ausnahmebedingungen zurückzustellen,
dramatisch eingeschränkt wird.
-
Es ist denkbar, einen extremen Ausnahmebedingungszustand,
der durch jedes spekulative Laden angetroffen wird, eine Ausnahmebedingung
in dem OS erzeugen zu lassen, und das OS den Ausnahmebedingungszustand
entweder korrigieren zu lassen (wenn die Korrektur keine programmsichtbaren
Nebeneffekte aufweist) oder manuell ein DET in den Zielort des Ladens
schreiben zu lassen, wodurch die Ausnahmebedingung zurückgestellt
wird. Der Nachteil dieses Lösungsansatzes
ist, daß das
Erzeugen von Ausnahmebedingungen in den OS eine hochlatente Operation
ist, die üblicherweise
Prozessorpipelinespülungen
und Cachefehlgriffe verursacht. Zusätzlich dazu wäre es erforderlich,
daß das OS
softwaremäßig Hilfsoperationen
des Ladens emuliert, wie z. B. ein Adreß-Nach-Inkrementieren, das
die Gesamtlatenz weiter verschlimmert. Wenn diese Hochlatenzoperation
bei jedem Ausnahmebedingungszustand bei jedem spekulativen Laden
auftritt, kann das Verhalten eines Programms mit einer Spekulation
weit unter das Verhalten des selben Programms ohne Spekulation fallen.
Was erwünscht
ist, ist ein Mechanismus, um die schnelle Erzeugung von Zurückgestellte-Ausnahmebedingung-Token
ohne OS-Eingriff zu ermöglichen.
-
Um dies zu erreichen, ist ein System
bereitgestellt, wie hierin nachfolgend in Anspruch 1 beansprucht
ist. Das System verwendet einen Mechanismus in der Prozessorhardware,
um ein DET in einen Zielort eines Befehls zu schreiben, ohne eine
Ausnahmebedingung in einem Prozeß zu erzeugen, der „eifrige
Zurückstellung" genannt wird. Zusätzlich dazu
bringt die vorliegende Erfindung einen neuen Prozessorzustand ein,
um die Operation der eifrigen Zurückstellung zu steuern, in der
Form von mehreren Ausnahmebedingungszurückstellbits, die in den voreingestellten
Steuerregister (DCR = Default Control Register) enthalten sind.
Wie vorangehend erwähnt wurde,
können
Ladevorgänge
einen breiten Bereich von Ausnahmebedingungszuständen erfahren.
-
Zusätzlich dazu werden die Aktionen,
die bestimmten Ausnahmebedingungszuständen zugeordnet sind, durch
die Computerarchitektur nicht spezifiziert, sondern werden durch
die Implementierung des OS bestimmt. Somit ist es wünschenswert,
daß der Eifrige-Zurückstellung-Mechanismus
eine Zurückstellung
an einer Ausnahmebedingung auf Ausnahmebedingungsbasis ermöglicht,
wodurch eine maximale OS-Implementierungsfreiheit
erlaubt wird. Um diesen Vorteil zu erreichen, definiert das bevorzugte Ausführungsbeispiel
ein Bit in dem DCR pro Ladeausnahmebedingung oder Klasse verwandter
Ausnahmebedingungen. Es wird darauf hingewiesen, daß andere
Abbildungen von Bits auf Ausnahmebedingungen möglich sind, z. B. ein einzelnes
Bit, das mehrere Ausnahmebedingungsklassen steuert. Bei dem bevorzugten
Ausführungsbeispiel
bestimmt jedes DCR-Bit, ob eine bestimmte Ausnahmebedingung oder
eine Klasse von verwandten Ausnahmebedingungen eifrig zurückgestellt
werden kann, oder ob eine Ausnahmebedingung in dem OS erzeugt werden
soll.
-
Ein einzelnes Programm ist üblicherweise aus
mehreren „Kompilierungseinheiten" oder „Modulen" zusammengesetzt.
In vielen Fällen
werden alle Module nicht zur selben Zeit oder durch den selben Kompilierer
kompiliert. Durch einen Prozeß,
der als „dynamisches
Verbinden" bekannt
ist, ist es ferner möglich,
daß bestimmte
Module nur während
der Laufzeit identifiziert werden und daher zu der Kompilierungszeit
nicht bekannt sind. Das gemeinschaftliche Verwenden von Modulen
ist allgemein bei der Softwareentwicklung üblich, z. B. von Bibliotheken, und
es ist möglich,
daß unterschiedliche
Module mit unterschiedlichen Erholungscodegraden kompiliert sind,
z. B. Erholung für
alle spekulativen Ladevorgänge über gar
keine Erholung. Die DCR-Bits der vorliegenden Erfindung treffen
gleichermaßen
für alle
Module in einem Programm zu. In dem Fall von variierenden Graden
eines Erholungscodes müssen
die DCR-Bits für
den kleinsten gemeinsamen Nenner unter allen Modulen gesetzt werden – und potentiell
das schlechteste Verhalten. Module sind an Speicherseitengrenzen
in dem virtuellen Adreßraum plaziert.
Virtuelle Speicherseiten werden auf physikalische Speicherseiten
abgebildet, über
eine OS-gesteuerte Datenstruktur, die „Seitentabelle" genannt wird, die
eine Mehrzahl von Einträgen
enthält,
wobei jeder derselben auf eine einzelne Seite abbildet. Die Seitentabelle
bildet Seiten ab, die sowohl Befehle als auch Daten enthalten, und üblicherweise
verwenden Befehle und Daten die selbe Seite nicht gemeinschaftlich.
Um das Verhalten zu verbessern, speichert der Prozessor ferner die
Seitentabelle in einer Struktur zwischen, die Translations-Seitengriffpuffer
(TLB = Translation Lookaside Buffer) genannt wird. Moderne Prozessoren
speichern Seitentabelleneinträge,
die Befehle abbilden, üblicherweise
getrennt cachemäßig von
Seitentabelleneinträgen,
die Daten abbilden – erstere
in dem ITLB und letztere in dem DTLB. Die vorliegende Erfindung
bringt einen zusätzlichen
Prozessorzustand ein, der in Seitentabelleneinträgen enthalten ist, die Befehle
abbilden (und daher cachemäßig in dem
ITLB gespeichert ist), der das ITLB-gespeicherte Bit (ITLB.ed-Bit)
genannt wird, d. h. jeder Seitentabelleneintrag (und daher jede
Seite) weist ihr eigenes ITLB.ed-Bit auf. Der Wert des ITLB.ed-Bits
für eine bestimmte
Seite steuert die eifrige Zurückstellung
für spekulative
Ladevorgänge,
die auf der Seite enthalten sind. Das ITLB.ed-Bit spezifiziert,
ob nie eifrig zurückgestellt
oder ob eifrig zurückgestellt
werden soll, basierend auf dem Wert der DCR-Bits. Dies liefert den Vorteil des unterschiedlichen
Steuerns der eifrigen Zurückstellung
für unterschiedliche
Module. Wenn z. B. ein Modul A einen Erholungscode umfaßt, während ein
Modul B dies nicht tut, dann können
die ITLB.ed-Bits auf den Seiten, die das Modul A enthalten, eingestellt
sein, um eifrig zurückzustellen,
basierend auf dem Wert der DCR-Bits, während die ITLB.ed-Bits auf
den Seiten, die das Modul B enthalten, eingestellt sein können, um
nie eifrig zurückzustellen.
Somit ermöglicht
dieser Mechanismus ein individuelles Maßschneidern einer eifrigen
Zurückstellung
auf einer Modul-für-Modul-Basis
und plaziert daher eine minimale Einschränkung auf Form und Konstruktion
von Softwareprogrammen. Der Wert der DCR- und ITLB.ed-Bits wird
durch zwei Informationen bestimmt: (1) Kenntnis des Kompilierers über den
Zustand des Erholungscodes, der zu dem OS übertragen wird, über den
Zustand in dem Lademodul, das durch die OS-Programmladevorrichtung
interpretiert ist; und (2) OS-Selbstkenntnis der Verwendung von
Ausnahmebedingungen und der Implementierung von Ausnahmebedingungshandhabungseinrichtungen.
Es wird darauf hingewiesen, daß alternative
Ausführungsbeispiele
von DCR- und ITLB.ed-Bits möglich
sind, z. B. könnten
mehrere ITLB.ed-Bits definiert sein, die aus mehreren Kopien von
DCR-Bits auswählen.
-
Um das Verhalten zu verbessern, speichert das
OS üblicherweise
Informationen cachemäßig, die
für die
Befehlsausführung
relevant sind. Diese cachemäßig gespeicherten
Informationen sind für
die Hardware nicht sichtbar und können daher nicht in die Entscheidung
darüber
eingerechnet werden, ob eifrig zurückgestellt wird, da eine eifrige
Zurückstellung
ohne Bezugnahme auf das OS durchgeführt wird – dies kann verursachen, daß die DCR-Bits
vorsichtig gesetzt werden. Zusätzlich
dazu kann das OS eine größere Sichtweite über das
Programmverhalten aufweisen als Hardware und kann die Sichtweite verwenden,
um das Programmverhalten abzustimmen. Aus diesen Gründen ist
es in bestimmten Situationen wünschenswert,
das OS in die Ausnahmebedingungszurückstellungsentscheidung einzubinden. Bei
der vorliegenden Erfindung wird dies durch Setzen der DCR-Bits implementiert,
um zu verursachen, daß eine
Ausnahmebedingung in dem OS erzeugt wird, für jene Ausnahmebedingungen,
bei denen das OS Informationen cachemäßig speichert. Das OS kann
dann den Ausnahmebedingungszustand basierend auf den cachemäßig gespeicherten
Informationen korrigieren oder kann wiederum entscheiden, daß eine Zurücksetzung
der ordnungsgemäße Handlungsverlauf
ist. Wie vorangehend erwähnt
wurde, würde
dies erfordern, daß das
OS manuell ein DET in den Zielort des Befehls schreibt und Hilfsoperationen
des Befehls emuliert. Um die Latenz dieser Situation zu reduzieren,
bringt die vorliegende Erfindung einen zusätzlichen Prozessorstatus ein,
um dem OS zu ermöglichen,
die Hardware zu informieren, daß ein
DET in den Zielort eines spekulativen Ladens geschrieben werden
sollte, und daß alle
anderen Hilfsoperationen durchgeführt werden sollten. Dieses
Bit wird das ISR.ed-Bit genannt.
-
Dementsprechend ist es ein technischer
Vorteil der Erfindung, dem Betriebssystem zu ermöglichen, fehlerspezifische
Optimierungen zu implementieren, die durch das DCR-Register aktiviert
werden.
-
Es ist ein weiterer technischer Vorteil
der Erfindung, daß unterschiedliche
Erholungsmodell unter den verschiedenen Modulen eines Programms
unterstützt
werden können.
-
Es ist ein wiederum weiterer technischer
Vorteil der Erfindung, daß bestimmte
fehlgeschlagene Operationen schnell ohne Softwareunterbrechungen zurückgestellt
werden können,
insbesondere ohne teure Pipelinezusammenbrüche und Softwarefehler.
-
Es ist ein wiederum weiterer technischer
Vorteil der Erfindung, daß dieselbe
eine aggressivere Verwendung von softwarestatischer Spekulation
ermöglicht,
da die Zurückstellung
einer ausgefallenen Spekulation weniger teuer ist.
-
Kurze Beschreibung
der Zeichnungen
-
Für
ein umfassenderes Verständnis
der Erfindung und der Vorteile derselben wird nun Bezug auf die
nachfolgenden Beschreibungen genommen, die in Verbindung mit den
beiliegenden Zeichnungen gegeben werden, in denen:
-
1 ein
Flußdiagramm
für eine
Hardwareausnahmebedingungszurückstellung
darstellt; und
-
2 ein
Flußdiagramm
für eine
Softwareauflösung
von Ausnahmebedingungen darstellt, die eine software geleitete Zurückstellung
von Ausnahmebedingungen spekulativer Ladevorgänge umfaßt.
-
3 stellt
ein schematisches Diagramm dar, wobei das System die Flußdiagramme
aus den 1 und 2 implementiert.
-
Beschreibung
der bevorzugten Ausführungsbeispiele
-
3 stellt
den Mechanismus 300 dar, der die Flußdiagramme aus 1 und 2 implementiert. Das
System entscheidet, ob die Hardware ein Zurückgestellte-Ausnahmebedingung-Token
in das bezeichnete Register des Ladebefehls schreiben soll oder
ob eine Ausnahmebedingung erzeugt werden sollte. Der Mechanismus
verwendet verschiedene Prozessorstatusbits oder gespeicherte Informationen,
um verschiedene Funktionen auszuführen. Eines der Bits ist das
Eintrittsbit des Befehlstranslations-Nebengriffpuffers 331 ITLB,
genannt ITLB.ed (die Endung .ed steht für Ausnahmebedingungszurückstellung
= exception deferral). Dieses Bit steuert, ob eine Ausnahmebedingung
bezüglich
einer der spekulativen Ladevorgänge,
die in der aktuellen Seite enthalten sind, in Hardware zurückgestellt
werden kann. Durch Definieren eines Bits 321 in dem TLB-Eintrag,
um die Hardwareausnahmebedingungszurückstellung zu steuern, können unterschiedliche
Softwaremodule (die auf unterschiedliche Seiten in dem Speicher
abbilden) dieses Bit unabhängig
setzen, wodurch es jedem Modul ermöglicht wird, unabhängig einen
Erholungscode zu umfassen. Der Mechanismus verwendet ferner mehrere Bits
in einem Steuerregister (DCR = Control Register) 332. Das
bevorzugte Ausführungsbeispiel
muß ein
Bit pro Ausnahmebedingungstyp aufweisen. Es wird darauf hingewiesen,
daß andere
Abbildungen von Bits auf Ausnahmebedingungstypen möglich sind,
z. B. ein einzelnes Bit, das mehrere Ausnahmebedingungstypen steuert.
Bei dem bevorzugten Ausführungsbeispiel
bestimmt jedoch jedes Bit, ob ein bestimmter Ausnahmebedingungstyp
in Hardware zurückgestellt
werden kann. Unter Voraussetzung der Eins-Zu-Eins-Entsprechung zwischen
den DCR-Bits und den Ausnahmebedingungstypen, weist das Betriebssystem
(OS) 320 die Flexibilität auf,
auszuwählen
322, welche Ausnahmebedingungstypen in Hardware zurückgestellt
werden können
und welche nicht.
-
Ausnahmebedingungsklassen stellen
die unterschiedlichen Ausnahmebedingungen dar, die während einer
Befehlsausführung
auftreten können.
Eine Klasse von Fehlern ist die Klasse von datentranslationsbezogenen
Fehlern. Andere Ausnahmebedingungsklassen würden Fehler beim Translatieren
des Ladens, gleitbezogene Fehler und befehlsabrufbezogene Fehler
aufweisen. Innerhalb der Daten-TLB-Fehlerklasse würden alle
Datenbezugnahmefehlertypen in dem DCR definiert werden, da diese
Fehler durch spekulatives Laden bewirkt werden. Jeder der unterschiedlichen
Fehlertypen hätte
ein zugeordnetes Bit in dem DCR für spekulative Ladevorgänge.
-
Es wird darauf hingewiesen, daß der Mechanismus
für jede
fehlerverursachende spekulative Operation arbeitet, einschließlich von
Nicht-Laden-Operationen. Somit wird die Ladeoperation ausschließlich als
Beispiel verwendet. Ferner ist der Mechanismus für nichtspekulative Operationen
wirksam, insbesondere in 2, wo die
Fehlerauflösung sowohl
bei spekulativen als auch nichtspekulativen Operationen (einschließlich Nicht-Laden-Operationen)
versucht werden kann.
-
Der Mechanismus 100 definiert
Ausnahmebedingungen von Ladezuständen,
wenn virtuelle Translationen aktiviert sind. Wie in 1 gezeigt ist, bezieht sich der Kasten 101 oder
der Anfang der Ladeausführung
auf einen Befehl, der aus einem Speicher und als Teil des Programmbefehlsstroms
abgerufen wird. Dieser Befehl spezifiziert eine normale Ladeoperation,
die eine Referenz für
den Speicher ist. Kasten 102 wird später im Hinblick auf rekursive
Aspekte des Mechanismus 100 erörtert. Kasten 103 führt einen
Test durch, um zu bestimmen, ob eine Ausnahmebedingung während der
Ladeoperation aufgetreten ist. Kasten 103 umfaßt alle
normalen TLB-Prüfungen,
die das Vorhandensein einer virtuellen Adreßtranslation prüfen, und
ob die spezifizierte Referenz zulässig ist. Andere Statusprüfungen werden
ebenfalls durchgeführt,
die für
das Betriebssystem notwendig sind, um das korrekte Bild in dem Speicher
beizubehalten und weiterhin andere Operationen durchzuführen, wie
z. B. Seitenadressierung (Paging), modifizierte Bitreferenzen oder
ob auf die Seite tatsächlich
Bezug genommen wird oder ob ein Korrekturfehler dieser Ausnahmebedingung
zugeordnet ist. Somit treten alle diese Prüfungen in dem Kasten 103 auf.
-
Es wird darauf hingewiesen, daß wenn keine Ausnahmebedingung
aufgetreten ist, was heißt,
daß die
Ladeoperation erfolgreich war, es wirklich nichts ausmacht, ob dies
ein spekulatives Laden oder ein nichtspekulatives Laden war, da
der Nein-Pfad von Kasten 103 nach unten zu Kasten 108 genommen wird.
Kasten 108 stellt ein erfolgreiches Laden dar, und die
Rücklaufergebnisse
aus der Ladeoperation werden in das Zielortregister des Ladens geschrieben.
Nach Abschluß des
Schreibens und der anderen Nebeneffekte wird die Ladeausführung beendet 111 und
das System ist bereit fortzufahren und den nächsten Befehl abzurufen. Es
wird darauf hingewiesen, daß ein
Teil des Schreibens des Zielortregisters 108 die Zurückgestellte-Ausnahmebedingung-Anzeige für das Zielregister
löscht.
-
Wenn bei Kasten 103 eine
Ausnahmebedingung aufgetreten ist, dann wird der Ja-Pfad zu Kasten 104 verfolgt,
wo bestimmt wird, ob das Laden ein spekulatives Laden oder ein nichtspekulatives
Laden ist. Wenn das Laden nichtspekulativ ist, dann arbeitet keiner
der Hardware-Zurückstellmechanismen
aus 1, da dieselben
nur eine Wirkung für
spekulatives Laden haben. Wenn das Laden nichtspekulativ ist, dann
ist die Ausnahmebedingung in dem Ursprungsbasisblock aufgetreten
und somit kann die Ausnahmebedingung nicht zurückge stellt werden, sondern
muß durch
Fehlererholungsmechanismen adressiert werden, die in dem Betriebssystem
oder Basisblock vorhanden sind. Somit wird der Nein-Pfad nach unten
zu Kasten 110 genommen, der die Ausnahmebedingung in dem
Betriebssystem erzeugt. Die Ausnahmebedingung, die erzeugt wird,
ist abhängig
von dem Typ der Ausnahmebedingung. Es wird darauf hingewiesen, daß die Softwaremechanismen
aus 2 an diesem Punkt arbeiten, beginnend bei
Kasten 201.
-
Wenn das Laden ein spekulatives Laden
ist, dann wird der Ja-Pfad von Kasten 104 zu Kasten 105 verfolgt,
wo bestimmt wird, ob ein Hardwarezurückstellen durchgeführt werden
kann. Das Ausnahmebedingungszurückstellbit
ITLB.ed, das in dem Befehl-TLB-Format definiert ist, spezifiziert,
ob Ausnahmebedingungen, die durch spekulatives Laden unter Verwendung
dieses Translationseintrags bewirkt wurden, automatisch durch den
Prozessor zurückgestellt
werden können
oder durch ein OS für
nichtfatale Ausnahmebedingungen zurückgestellt werden können. Anders
ausgedrückt,
prüft das
ITLB.ed-Bit, um zu sehen, ob die Anwendung 310, 311 die
Fähigkeit
für eine
eifrige Zurückstellung
aufweist, oder ob das System versuchen muß, die Ausnahmebedingung vor
dem Setzen der Zurückgestellte-Ausnahmebedingung-Anzeige
zu lösen.
Es wird darauf hingewiesen, daß sich
das ITLB-Bit nicht auf den TLB für
die Daten des Ladens bezieht, auf dem das Laden durchgeführt wird,
sondern sich auf den TLB für
den Befehl bezieht, der ausgeführt
wird 334. Dies ist wichtig, da der Erholungscode dem Befehl
zugeordnet wird, der ausgeführt
wird, und nicht den Daten zugeordnet wird, die geladen werden. Daher,
muß durch
das Attribut des ITLB bestimmt werden, ob eine eifrige Zurückstellung
ermöglicht
ist. Eine eifrige Zurückstellung
ist, wenn das System bestimmt hat, daß es einen großen Betrag
an Arbeit benötigt,
um zu bestimmen, ob die Ausnahmebedingung gelöst werden kann, und somit,
um Zeit zu sparen, führt
das System eine automatische Zurückstellung
durch.
-
Statistisch besteht jedoch eine gute
Chance, daß diese
Ausnahmebedingung nie bearbeitet werden muß, und somit ist es wirtschaftlicher,
diese Typen von Ausnahmebedingungen automatisch zurückzustellen.
Somit werden dieselben eifrig zurückgestellt, die Zurückgestellte-Ausnahmebedingung-Anzeige gesetzt wird,
und wenn die Ergebnisse später
wirklich benötigt
werden, dann wird der Ausnahmebedingungszustand durch den Erholungscode gehandhabt.
-
Wenn der Anwendung jedoch ein Erholungscode
für diesen
Typ von Ausnahmebedingung fehlt, dann wird das System nicht versuchen,
diese Ausnahmebedingung später
zu lösen,
und somit sollte der Ausfall besser wirklich ein schwerwiegender
Fehler sein und das Betriebssystem sollte versuchen, diese Ausnahmebedingungen
so gut wie möglich
zu lösen.
Dies wird aus der Anwendung sowohl der Hardware als auch dem Betriebssystem
durch das ITLB.ed-Bit angezeigt.
-
Somit wird das ITLB-Bit verwendet,
um den Status des Erholungscodes in der laufenden Anwendung von
der Anwendung an sowohl das OS als auch die Hardware zu kommunizieren.
Wenn die Anwendung nicht die Fähigkeit
aufweist, eine eifrig zurückgestellte
Ausnahmebedingung zu handhaben, dann ist das ITLB.ed-Bit Null. Dies
bedeutet, daß die
Hardware diese Ausnahmebedingung nicht zurückstellen kann, da dieselbe
etwas sein könnte,
das das Betriebssystem lösen
könnte.
Somit wird von dem Kasten 105 zu dem Kasten 110 der
Nein-Pfad genommen,
wo derselbe durch Erzeugen einer Ausnahmebedingung in dem Betriebssystem
in das OS fehlschlagen wird. Wenn die Anwendung jedoch eine Ausnahmebedingung
eifrig zurückstellen
kann, dann wird der Ja-Pfad aus dem Kasten 105 in den Kasten 106 genommen,
der ein Bit aus dem Steuerregister (DCR) auswählt.
-
Das Steuerregister (DCR) ist der
Mechanismus, den das OS verwendet, um mit der Hardware darüber zu kommunizieren,
ob dieselbe fehlerspezifische Optimierungen durchgeführt hat.
Zurückstellbits werden
in dem DCR definiert, die Ausnahme bedingungen klassifizieren, die
durch spekulative Ladevorgänge
bewirkt werden können.
Diese Bits werden als eines der Kennzeichen für Hardware verwendet, um eine
Ausnahmebedingungszurückstellung
eines automatischen spekulativen Ladens durchzuführen.
-
Sobald das DCR-Bit ausgewählt wurde,
bestimmt Kasten 107, ob das OS spezifiziert hat, daß eine Optimierung
(oder ein anderer Erholungsmechanismus) mit diesem spezifischen
Fehler oder der Ausnahmebedingung zugeordnet ist, und dies wird dadurch
angezeigt, daß das
DCR-Bit gleich Null ist. Somit zeigt dies an, welche Fehler das
Betriebssystem für
spekulative Ladevorgänge
handhaben möchte.
-
In diesem Fall, wenn das DCR-Bit
gleich Null ist, dann wird der Nein-Pfad von Kasten 107 zu
Kasten 110 verfolgt, und es wird eine Ausnahmebedingung
in dem Betriebssystem erzeugt. Dies ermöglicht es dem Betriebssystem,
seine Optimierung für diesen
Fehler durchzuführen,
ohne eine Ausnahmebedingungszurückstellung
durchzuführen,
siehe 2 Kasten 201. Als Beispiel,
wenn ein Seitenfehler aufgetreten wäre, dann hätte das Betriebssystem eine
Chance, die Seitentabellen durchzugehen und nach einer Translation
zu suchen und dieselbe in dem TLB zu installieren, bevor es eine
zurückgestellte
Ausnahmebedingung erzeugt. Ein anderes Beispiel ist ein Schlüsselfehlgriff.
Hier hat das Betriebssystem eine Chance, durch einen Schlüsselcache
in der Tabelle zu gehen, bevor eine Zurückstellung erzeugt wird.
-
Wenn das Betriebssystem keine Optimierungen
aufweist, die diesen bestimmten Fehlern zugeordnet sind, und das
einzige was es tun will das Zurückstellen
der Ausnahmebedingung durch Emulieren des Ladens und das Setzen
der Zurückgestellte-Ausnahmebedingung-Anzeige
ist, dann zeigt es dies der Hardware an, durch Setzen des DCR-Bits
in dem Steuerregister auf Eins. Somit, wenn das Ergebnis des Tests
in dem Kasten 107 wahr ist, dann ist sowohl die Anwendung
bereit für
eine Zurückstellung und
das Betriebssystem keine Opti mierungen zum Abspielen aufweist, dann
wird der Ja-Pfad von Kasten 107 zu Kasten 109 genommen.
Kasten 109 schreibt die Zurückgestellte-Ausnahmebedingung-Anzeige
in das Register, und fährt
dann mit dem Ende der Ladeausführung 111 fort,
ohne einen Fehler in dem Betriebssystem zu erzeugen. Somit, wenn
ein spekulatives Laden eine Ausnahmebedingung bewirkt und das DCR-Zurückstellungsbit
für diese
Ausnahmebedingung auf Eins gesetzt ist, und das ITLB.ed-Bit für die Befehlsseite
des spekulativen Ladens auf Eins gesetzt ist, dann führt die
Hardware eine automatische Zurückstellung
der Ausnahmebedingung durch. Ein Kompilierer/Verbinder kann Textsegmente
mit einem Attribut kennzeichnen, das das OS verwendet, um das ITLB.ed-Bit
zu setzen.
-
Es wird darauf hingewiesen, daß die Kästen in 1 alle während der Laufzeit durchgeführt werden.
Während
der Kompilierungszeit werden die Attributbits, die in dem ITLB.ed-Bit
reflektiert werden, gesetzt.
-
Das Bit in dem Kasten 107 wird
durch das Betriebssystem entweder statisch oder auf einer Prozeß-Für-Prozeß-Basis
gesetzt. Somit kann das Betriebssystem zu unterschiedlichen Zeiten
unterschiedliche Zurückgestellte-Ausnahmebedingung-Policen für unterschiedliche
Anwendungen aufweisen. Daher wird dies nicht zur Kompilierungszeit gesetzt,
sondern wird basierend auf dem aktuell laufenden Prozeß durch
das Betriebssystem gesetzt. Der Test in dem Kasten 104,
ob das Laden spekulativ ist oder nicht, wird zur Kompilierungszeit
mit der Planung des statischen Codes bestimmt. Es liegt eine statische
Bestimmung durch die Optimierungsphase der Programmkompilierung
darüber
vor, ob dieses Laden spekulativ ausgegeben werden soll, und dies wird
in dem Kasten 104 getestet.
-
In 1 führen die
Nein-Pfade von den Kästen 104, 105 und 107 alle
zu dem Kasten 110, der Erzeugung einer Ausnahmebedingungen
in dem OS, die zu Kasten 201 von 2 führt, dem
Starten der OS-Ausnahmebedingungshandhabungseinrich tung. Der Softwaremechanismus 200,
der in 2 dargestellt ist, ermöglicht es
dem Betriebssystem, verschiedene Virtueller-Speicher-Optimierungen
und verschiedene Verbesserungen an der Hardwarestruktur in dem Kasten 202 durchzuführen. Die
Software versucht Erste-Ebene-Fehlerauflösungstechniken.
Zum Beispiel das Gehen durch Seitentabellen, Ausfüllen von
Schutzschlüsselcaches
und andere Dinge, für
die die Hardware keine Strukturen zum Durchführen aufweist. Dies ist eine
nichterschöpfende
Liste der Dinge, die das Betriebssystem tun könnte, aber nur zwei Beispiele
von Optimierungstypen, die an spekulativen Ladevorgängen durchgeführt werden
könnten.
-
Nachdem die ersten Pegeloptimierungen
in dem Kasten 202 versucht wurden, bestimmt Kasten 203,
ob dieselben den Fehler oder die Ausnahmebedingung erfolgreich aufgelöst haben.
Falls erfolgreich aufgelöst,
wird der Ja-Pfad von Kasten 203 zu Kasten 204 verfolgt,
und die Anwendung kehrt zurück
zu dem unterbrochenen Befehl für
einen Wiederversuch des Befehls. Der Befehl in Kasten 204 (sowie
Kasten 213) ist ebenfalls als RFI oder Rückkehr von
Unterbrechung (Return From Interrupt) bekannt. Dieses Mal sollte
sich der Befehl hin zum Abschluß bewegen,
da der Fehlerzustand aufgelöst
wurde. Andere Fehler können
während
des Wiederversuchs entstehen. Es wird darauf hingewiesen, daß Kasten 202 während der
Laufzeit durchgeführt
wird, aber durch das Betriebssystem statisch in den Code kompiliert wird.
Dies ist nicht etwas, das die Hardware dynamisch basierend auf dem
Fehler ausführt.
-
Wenn der Fehler durch Kasten 202 nicht
aufgelöst
wird, dann wird der Nein-Pfad von Kasten 203 zu Kasten 205 verfolgt,
wo bestimmt wird, ob das Laden spekulativ oder nichtspekulativ ist.
Es wird darauf hingewiesen, daß Kasten 205 die
Software parallel zu Kasten 104 ist. Somit weist die Software
die Fähigkeit
auf, die selben Arten von Tests durchzuführen, die die Hardware durchführt. Das
ISR.sp-Bit des Unterbrechungsstatusregisters 303 spezifiziert,
daß sich die
Unterbrechung auf eine Operation des spekulativen Ladens bezieht.
Das ISR.sp-Bit ermöglicht es
dem OS, schnell zu bestimmen, ob ein Fehler durch ein spekulatives
Laden erzeugt wurde. Der Kompilierer verwendet einen unterschiedlichen
Befehl für
spekulative Ladevorgänge
als für
nichtspekulative Ladevorgänge.
Wenn der Fehlerbefehl ein spekulatives Laden ist, wird diese Tatsache
automatisch durch die Hardware in dem Unterbrechungsstatusregister
berichtet, die das Bit in dem Kasten 205 setzt.
-
Kasten 205 ist eine Vorab-Prüfung um
zu bestimmen, ob die Ausnahmebedingung eifrig zurückgestellt
werden kann. Nur spekulative Ladevorgänge können zurückgestellt werden.
-
Somit, wenn das Laden nichtspekulativ
ist, dann ist ISR.sp gleich Null und der Nein-Pfad zu Kasten 208 wird
verfolgt, wo die Zweite-Ebene-Fehlerauflösung versucht wird. Wenn das
Laden spekulativ ist, dann ist das ISR.sp-Bit gleich Eins, dann
wird der Ja-Pfad zu Kasten 206 verfolgt, wo bestimmt wird,
ob das ISR.ed auf Eins gesetzt ist. Der Kasten 206 ist ferner
eine Vorab-Prüfung,
um zu bestimmen, ob die Ausnahmebedingung eifrig zurückgestellt
werden kann. Das ISR.ed zeigt an, ob die Anwendung, die läuft, eine
eifrig zurückgestellte
Ausnahmebedingung handhaben kann. Das ISR.ed ist eine Kopie des ITLB.ed-Bit
für den
Befehl, der die Ausnahmebedingung bewirkt. Das Bit wird bei einer
Unterbrechung kopiert. Es wird darauf hingewiesen, daß Kasten 206 die
Software parallel zu Kasten 105 ist. Somit wird die Prüfung in
Kasten 105 in der Software mit Kasten 206 gespiegelt.
Somit ermöglichen
es die Kästen 205 und 206 der
Software schnell zu bestimmen, daß dies ein spekulatives Laden
war, und ferner sehr schnell zu bestimmen, welche Art des Verhaltens
für ein
spekulatives Zurückstellen
durch das Anwendungsprogramm erwartet wird.
-
Wenn die Anwendung eifrig zurückgestellte Ausnahmebedingungen
nicht handhaben kann, mit ISR.ed gleich Null, dann wird der Nein-Pfad
von Kasten 206 zu Kasten 208 verfolgt, um eine
Zweite-Ebene-Fehlerauflösung
zu versuchen. Wenn die Anwendung die eifrige Zurückstellung von Fehlern handhaben
kann, ist Kasten 206 Ja, da ISR.ed gleich Eins ist, dann
wird der Ja-Pfad zu Kasten 207 verfolgt, wo das OS einen
Teil seiner eigenen Taktik auferlegen kann. Wenn das OS entscheidet,
diesen Fehler eifrig zurückzustellen,
dann wird der Ja-Zweig von Kasten 207 zu Kasten 212 verfolgt,
und die Softwarezurückstellung
der Ausnahmebedingung wird begonnen. Das 05 kann jedoch entscheiden,
daß obwohl
eine eifrige Zurückstellung
von der Anwendung erlaubt werden würde und es sich um ein spekulatives
Laden handelt, es trotzdem eine Zweite-Ebene-Fehlerauflösung für ein spekulatives
Laden versuchen möchte. Dann
wird der Nein-Pfad von Kasten 207 zu Kasten 208 verfolgt.
-
Die Zweite-Ebene-Fehlerauflösungstechniken
sind die höhergewichtigen
Techniken, wie z. B. eine Seitenfehler-Handhabungseinrichtung oder
eine Zugriffsrechte-Handhabungseinrichtung oder andere Virtueller-Speicher-Fehlerauflösungsroutinen.
Diese werden wiederum als Beispiele bereitgestellt und sollen keine
erschöpfende
Liste darstellen. Nach dem Versuchen dieser Zweite-Ebene-Fehlerauflösung bei Kasten 208 wird
der Erfolg bei Kasten 209 bestimmt. Wenn die Auflösung erfolgreich
ist, dann wird der Ja-Pfad von Kasten 209 zu Kasten 204 verfolgt,
was der Rückweg
zu dem unterbrochenen Befehl ist. Wenn der Fehler durch die Zweite-Ebene-Fehlerauflösungstechniken
nicht gelöst
wird, dann wird der Nein-Pfad von Kasten 208 zu Kasten 210 verfolgt.
-
Bei Kasten 210 wird bestimmt,
ob der fehlerverursachende Originalbefehl ein spekulatives Laden war,
durch Kontrollieren des ISR.sp-Bits. Falls es kein spekulatives
Laden war und somit ISR.sp gleich Null ist, dann wird der Nein-Pfad von Kasten 210 zu Kasten 211 verfolgt,
wo ein Fehler zu dem unterbrochenen Kontext geliefert wird (dem
Code, der das spekulative Laden ausgegeben hat). Dies kann die Prozeßausführung beenden.
Daher bewegt sich ein nichtspekulatives Laden durch den Mechanismus 200,
durch die Zweite- Ebene-Fehlerauflösung 208, und
wenn dieselbe nichtaufgelöst
ist, bestimmt der Kasten 210, daß es sich um eine nichtspekulative Ausführung handelt
und leitet Verfahren ein, um das Verfahren bei Kasten 211 zu
beenden. Wenn es sich jedoch um ein spekulatives Laden handelt und
sowohl die erste als auch die zweite Ebene der Fehlerauflösung nicht
erfolgreich sind, wird ein Fehler zu der Software nicht bewirkt
und der Ja-Pfad von Kasten 210 zu Kasten 212 wird
verfolgt.
-
Bei Kasten 212 wird das
IPSR.ed-Bit auf Eins gesetzt. Das IPSR.ed-Steuerbit leitet den Prozessor
an, die Zurückgestellte-Ausnahmebedingung-Anzeige
für den
nächsten
Befehl (falls es sich um ein spekulatives Laden handelt) zurückzustellen. Dieses
Bit kann nur durch den Befehl „Rückkehr von Unterbrechung" (RFI = Return From
Interruption) bei Kasten 212 gesetzt werden und wird durch
die Hardware nach der Ausführung
des aktuellen Befehls gelöscht.
Das PSR stellt das Prozessorstatusregister dar. Dies zeigt der Hardware
an, daß das
Laden fehlgeschlagen ist, und der Fehler oder die Ausnahmebedingung
nicht gelöst
wurde, entweder weil das OS nicht über die Kästen 203 und 209 gehen
konnte oder weil das OS denselben/dieselbe nicht über den
Kasten 207 auflösen
wollte. Aus Kasten 212 fährt der Mechanismus 200 mit
Kasten 213 fort, welcher die Ausführung des Befehls Rückkehr von
Unterbrechung (RFI) ist und den Ladebefehl erneut ausführt. Die Hardware
wird nicht versuchen, die Speicherreferenz erneut auszugeben, wenn
PSR.ed gesetzt ist (IPSR wird zu PSR durch RFI kopiert), was der
Hauptaspekt des zusammengesetzten Ladebefehls ist. Statt dessen
setzt die Hardware die Zurückgestellte-Ausnahmebedingung-Anzeige
in dem Zielregister und führt die
anderen Ladenebeneffekte des spekulativen Ladens durch, was eine
Basisadreßmodifizierung
und ALAT-Aktualisierungen (Advance Load Address Table = Vorladeadreßtabelle-Hardwarestruktur)
umfaßt. Somit
verursacht das OS, daß die
Hardware die Zurückgestellte-Ausnahmebedingung-Anzeige
für alle Fehler
setzt, die durch spekulative Ladevorgänge erzeugt werden, die nicht
gelöst werden
können.
Daher, wenn ein OS eine Spekulatives-Laden-Ausnahmebedingung zurückstellt,
muß dieselbe
das IPSR.ed-Bit
setzen und den RFI-Befehl ausgeben. Die Zurückgestellte-Ausnahmebedingung-Anzeige wird
durch Hardware gesetzt und alle anderen Nichtspeicherkomponenten
der zusammengesetzten Spekulatives-Laden-Operation werden ausgeführt.
-
Es wird darauf hingewiesen, daß die Kästen 204 und 213 beides
RFI-Kästen
sind. Der Unterschied zwischen diesen zwei ist, daß in dem
Kasten 204 das IPSR.ed-Bit auf Null gesetzt bleibt, dem
Anfangszustand, der in dem Kasten 202 durch die Hardware
gesetzt ist. In dem Kasten 213 ist das IPSR.ed-Bit gleich
Eins. Dieses Bit weist die Hardware an, die Zurückgestellte-Ausnahmebedingung-Anzeige
in dem Zielregister zu setzen und nur die Ladenebenwirkungen durchzuführen und
nicht zu versuchen, den Speicherzugriff durchzuführen. Somit zeigt Kasten 204 an,
daß ein
Fehler aufgelöst wurde,
aber in Kasten 213 ist der Fehler unaufgelöst. Der
Fehler wird bis zu einer späteren
Zeit zurückgestellt,
wenn (und falls) das Programm seinen Ausgangsbasisblock erreicht.
Somit ist es die Verantwortlichkeit des Codes in dem Basisblock,
einen Prüfbefehl
an dem Zielregister dieser spekulativen Kette durchzuführen. Der
Prüfbefehl
verursacht, daß der
Erholungscode aufgerufen wird, wenn eine Zurückgestellte-Ausnahmebedingung-Anzeige
vorliegt. Es wird darauf hingewiesen, daß der Erholungscode statisch
oder zur Kompilierungszeit vorliegt.
-
Somit ist die Zurückgestellte-Ausnahmebedingung-Anzeige
ein Weg zum Bestimmen, daß das spekulative
Laden fehlgeschlagen ist, wenn man sich in dem Basisblock befindet.
Der andere Weg wird nichtspekulativer Verbrauch des Zielregisters
genannt. Beispiele eines nichtspekulativen Verbrauchs eines Registers
umfassen: Versuchen, den Wert zu einem Steuerregister zu bewegen,
oder Versuchen, denselben zu einem Zweigregister zu bewegen oder denselben
in dem Speicher zu speichern. Diese werden nichtspekulative Operationen
genannt, und wenn dieselben versucht werden und fehlschlagen, dann
bewegt der Prozessor einen unterschiedlichen Typ einer Softwareunterbrechung
hoch, die dann eine Anzeige ist, daß das Programm nicht korrekt
geschrieben wurde und es wird wiederum ein Fehler zu dem unterbrochenen
Kontext bewirkt, aber dieses Mal von dem Ausgangsbasisblock, nicht
von dem Punkt, an den das spekulative Laden gehoben wurde.
-
Bei Kasten 212 ist IPSR.ed
auf Eins gesetzt, was bedeutet, daß die Software der Hardware
anzeigt, daß sie
die Zurückgestellte-Ausnahmebedingung-Anzeige
gesetzt haben möchte.
Es wird darauf hingewiesen, daß die
tatsächliche
Zurückgestellte-Ausnahmebedingung-Anzeige
für ein
spekulatives Laden unterschiedlich ist, das auf die Gleitkommaregisterdatei
gerichtet ist, als sie für
ein spekulatives Laden ist, das auf die allgemeine Registerdatei
gerichtet ist. Bei einer bestimmten Implementierung liegt ein 65.
Bit an der allgemeinen Registerdatei vor, das für eine Zurückgestellte-Ausnahmebedingung-Anzeige
verwendet wird, während
ein reserviertes Codieren in der Gleitkommaregisterdatei vorliegt,
um zu bestimmen, daß eine
zurückgestellte Ausnahmebedingung
bei dem spekulativen Laden in dieses Register vorliegt. Einer der
Vorteile dieser Erfindung ist, daß die Software das IPSR.ed-Bit
setzt und es der Hardware überläßt, das
Zurückstellen durchzuführen, und
es somit nicht mehr aufwendig ist, zu bestimmen, ob es sich um ein
Gleitkomma- oder ein allgemeines Registerziel handelt. Es wird darauf
hingewiesen, daß nirgendwo
bei dem Mechanismus 100 und 200 eine Prüfung über den
Typ der spekulativen Operation vorliegt, d. h. allgemein oder Gleitkomma,
und da die Hardware die Zurückstellung handhabt,
kein weiterer Bedarf besteht, weiter zwischen allgemeinen oder Gleitkomma-Ladevorgängen zu
unterscheiden.
-
Es wird darauf hingewiesen, daß beide
Kästen 204 und 213 zurück zu Kasten 101 aus 1 kehren. Wie vorangehend
erörtert
wurde, wird das IPSR.ed-Bit in Kasten 202 auf Eins gesetzt,
und somit durch Kasten 213 als Eins an Kasten 101 weitergeleitet,
während
das IPSR.ed-Bit in Kasten 202 auf Null gesetzt ist und
im Verlauf von 200 unverändert bleibt
und somit als Null durch Kasten 204 an Kasten 101 weitergeleitet
wird. Das IPSR-Bit wird in PSR kopiert. Somit, bei Kasten 102,
wenn PSR.ed gleich Eins ist und die Operation ein spekulatives Lasen
ist, dann wird der Ja-Pfad von Kasten 102 zu Kasten 109 verfolgt,
was der Hardwarezurückstellung
der Ausnahmebedingung entspricht. Wenn entweder das PSR.ed-Bit gleich
Null ist oder die Operation ein nichtspekulatives Laden oder eine
Nichtladeoperation ist, dann wird der Nein-Pfad zu Kasten 103 verfolgt,
für weitere
Operationen, wie oben erörtert
wurde.
-
Der einzige Fall, in dem der Kasten
Ladeausführung
beenden 111 nicht erreicht wird, ist, wenn die Anwendung
bei Kasten 211 beendet wird, weil ein Fehler für einen
nichtspekulativen Befehl nicht gelöst werden konnte, wobei in
diesem Fall der Fehler zu dem unterbrochenen Kontext bewirkt wird,
was zum Abschluß des
Programms oder der Anwendung führen
kann.
-
Es wird darauf hingewiesen, daß der Eintritt in
den Kasten 101 entweder von Kasten 204 oder Kasten 213 anzeigt,
daß die
Ausführung
wiederholt wird. Indem ein Fehler in dem OS bei Kasten 201 verursacht
wird, ist die Neustartposition, die dem Betriebssystem angezeigt
wird, der fehlerverursachende Befehl. Somit kehrt die Anwendung
nach der Rückkehr
zu diesem Befehl zurück
und spielt denselben erneut durch. Der Befehl wird entweder mit
dem PSR.ed-Bit aus Kasten 213 auf Eins gesetzt oder aus Kasten 204 auf
Null gesetzt erneut durchgeführt. Folglich
liegen mehrere Gründe
vor, warum ein Laden fehlschlagen kann, und dieselben werden nacheinander
dem Betriebssystem berichtet. Somit führt die rekursive Art dieses
Mechanismus wiederum eine Prüfung
durch, um zu bestimmen, ob ein weiterer Fehler bei dem nächsten sequentiellen
Aspekt der Ladeoperation vorliegt. Es wird darauf hingewiesen, daß Aspekte
in einer Reihenfolge von der höchsten Priorität zu der
niedrigsten Priorität
vorliegen.
-
Somit, wenn ein Aspekt höherer Priorität einen
Fehler aufweist, der nicht aufgelöst ist, wird sich der Mechanismus
nicht darum kümmern,
eine Kontrolle für
einen Aspekt niedrigerer Priorität
durchzuführen
und/oder denselben aufzulösen.
In vielen Fällen,
wenn ein Fehler höherer
Priorität
nicht aufgelöst werden
kann, dann können
solche mit niedrigerer Priorität
nicht aufgelöst
werden. Wenn z. B. ein Seitenfehler höherer Priorität nicht
gelöst
werden kann und zurückgestellt
wird, dann kann eine Zugriffsrechteverletzung nicht gelöst werden,
da die Anwendung keine Seite aufweist. Daher stellt der Mechanismus alle
Aspekte niedrigerer Priorität
zusätzlich
zu dem fehlerhaften Aspekt höherer
Priorität
zurück.
Der Mechanismus kann jedoch durch Aspekte höherer Priorität fortschreiten
und die Aspekte niedrigerer Priorität zurückstellen. Es wird z. B. angenommen,
daß der obige
Seitenfehler gelöst
wird, dann kontrolliert der Mechanismus nach Zugriffsrechten und
bestimmt, daß die
Anwendung versucht, eine Nur-Ausführen-Seite zu lesen. An diesem
Punkt kann der Mechanismus entscheiden, das Lösen dieser Fehlerverletzung
zurückzustellen.
-
Ein Beispiel des Mechanismus 100, 200,
das Schutzschlüssel
umfaßt,
ist gegeben. Es wird angenommen, daß ein Betriebssystem keine
Schutzschlüssel
verwendet, was einer der Mechanismen ist, die bei der Verwaltung
von virtuellem Speicher verwendet werden. Folglich, wenn ein Betriebssystem den
Schlüsselmechanismus
nicht verwendet, dann sollte eine Transaktion, die einen Schlüsselfehler
aufweist, ungültig
sein. In dem Fall, daß das
Betriebssystem in dem DCR anzeigen würde, alle Schlüsselfehlgriffehler
die aus spekulativen Ladevorgängen
resultieren, zurückzustellen,
hätte das
Betriebssystem den Schlüsselfehlgriff
für den
Ladebefehl nicht aufgelöst,
wenn ein Schlüsselfehlgriff
angetroffen worden wäre,
und dieser Fehler in das Betriebssystem bewirkt worden wäre. Somit,
durch Setzen des Bits auf Eins in dem DCR, das diesem Fehler entspricht,
kann das OS der Hardware anzeigen, diesen Typ von Fehler zurückzustellen,
und nicht durch die teurere Operation des Erzeu gens einer Pipelineunterbrechung
zu gehen, die eine Softwareausnahmebedingung berichtet, die die
Emulation des Befehls erfordern wird, und dann zurückzukehren.
-
Andererseits sei angenommen, daß ein Betriebssystem
Schlüssel
als Teil seiner Verwaltung virtueller Adressen verwendet. Ein TLB
ist ein Translationsseitengriffpuffer, der ein Hardwaremechanismus ist,
der Virtuelle-Translation-Informationen und Schutz-Informationen
cachemäßig speichert.
Derselbe kann diese Operation sehr schnell durch einen Befehl-Für-Befehl-Zyklus
durchführen,
ohne eine Softwareintervention zu verursachen. Das Betriebssystem
kann die Schlüsselregister
als einen Cache definieren, der einen Teilsatz aller Fähigkeiten
der aktuellen Anwendung aufweist. Somit, wenn ein Schlüsselfehlgriffehler
vorliegt, dann kann das Betriebssystem wünschen, eine Fehlerauflösung zu versuchen,
durch Durchsehen eines größeren speicherbasierten
Caches, der den Schlüssel
für diese
Referenz anordnet, durch Bewegen desselben in das Schutzschlüsselregister,
und dann erneut das spekulative Laden ausgibt, das erfolgreich sein
kann. Somit führt
das Betriebssystem in diesem Fall ein cachemäßiges Speichern der Ressourcen
und bestimmte Optimierungen durch, die mehr als die Ressourcen sind,
die in dem Prozessor gebaut sind. Somit würde das Betriebssystem wahrscheinlich
die automatische Hardwarezurückstellung
in dem DCR für Schlüsselfehler
nicht setzen, da es versuchen möchte,
die Fehler aufzulösen,
bevor die Hardware die Zurückstellung
ausführt.
-
Ferner weist jede Seite in den Translationsseitengriffpuffern
(TLB = Translation Lookaside Buffer) ein zugeordnetes Feld auf,
das den Schutzschlüssel
für diese
Seite angibt. Der Zugriff zu dieser Seite wird nur gewährt, wenn
dieser Schutzschlüssel auch
in einem Schutzschlüsselregister
existiert, das ein weiteres privilegiertes Statusregister in dem
Prozessor ist. Somit ist dies ein Weg zum Ermöglichen von Schutz, anders
als durch Adreßraumisolierung. Somit
können
zwei unterschiedliche Benutzer eine Adresse zu einer Position erzeugen,
aber nur einer von ihnen hat Zugriff zu derselben, da dieser Benutzer
den Schlüssel
in den Schlüsselregistern
hat, während
der andere den Schlüssel
nicht hat und somit keinen Zugriff hat. Wenn nun auf eine Seite
Bezug genommen wird und der Schlüssel
aus dem TLB gezogen wird, und der Schlüssel aber in der Schutzschlüsselregisterdatei
nicht gefunden wird, dann wird ein Schlüsselfehler erzeugt. Falls dies
nun mit einem spekulativen Laden durchgeführt wurde, wird an dem Punkt,
an dem der Schlüsselfehler
bewirkt worden wäre,
das DCR abgefragt. Falls die Software angezeigt hat, daß sie keinen
Erholungscode aufweist, oder falls das Betriebssystem gesagt hat,
daß es
die Schlüsselfehler
sehen möchte,
dann wird dieser Fehler zu dem OS bewirkt. Dann kann das Betriebssystem
tatsächlich
bestimmte Optimierungen durchführen.
Wenn die Anwendung jedoch Erholungsmechanismen aufweist und dies
in dem Befehls-TLB angezeigt ist, und das Betriebssystem Schlüsselfehlgriffsfehler
nicht handhaben möchte,
dann wird dieser Fehler in der Hardware automatisch zurückgestellt.
-
Daher ermöglicht das ITLB.ed-Bit eine
Kommunikation zwischen der Anwendung und dem Betriebssystem und
kommuniziert Informationen über die
Spekulative-Erholung-Fähigkeit
einer Anwendung. Dies ermöglicht
es einem OS, teure Ausnahmebedingungen zu einer spekulativen Ladezeit
zurückzustellen,
wobei bekannt ist, daß,
wenn die nichtspekulative Verwendung der Daten auf der Ausführungsspur
erfolgt, der spekulative Erholungscode existiert. Bei einer spekulativen
Ausnahmebedingung wird das ISR.sp-Bit gesetzt, um ein spekulatives
Laden anzuzeigen, und ISR.ed wird auf den Wert des ITLB.ed-Feldes
des fehlerverursachenden Befehls gesetzt. Die DCR-Bits ermöglichen
eine Kommunikation zwischen dem OS und der Hardware und sind eine
Anzeige darüber,
welche Spekulatives-Laden-Ausnahmebedingungen automatisch zurückgestellt
werden sollten. Das PRS.ed-Bit ermöglicht eine Kommunikation zwischen
dem OS und der Hardware und zeigt an, daß ein Spekulatives-Laden-Befehl eine
Zurückgestellte-Ausnahmebedingung-Anzeige erzeugen
sollte und alle Nichtspeicherkomponenten der zusammengesetzten Operationen
durchführen sollte,
die in der aktuellen Spekulatives-Laden-Operation spezifiziert sind.
-
Der Mechanismus ermöglicht ein
verbessertes Verhalten von Programmen unter Verwendung einer spekulativen
Ausführung.
Betriebssystem-Taktikentscheidungen und cachemäßiges Speichern von Translationsinformationen
kann beim Vorhandensein einer spekulativen Ausführung ohne den Aufwand unnötig zurückgestellter
Ausnahmebedingungen oder den Aufwand von Emulierungsbefehlen arbeiten,
um teure Ausnahmebedingungen zurückzustellen.
Somit kann das Ermöglichen
einer automatischen Hardwarezurückstellung
bestimmter Ausnahmebedingungen und eine effiziente Hardwarezurückstellung
unter ausdrücklicher
Softwaresteuerung zu einem besseren Verhalten durch eine reduzierte
Anzahl von spekulativen Prüffehlern
führen,
die leichter zu einer spekulativen Ladezeit gelöst werden können als die nichtspekulative
Verwendung der Ladedaten. Ein besseres Verhalten entsteht ferner
aus effizienteren Mechanismen zum Zurückstellen von Ausnahmebedingungen,
die zu teuer sind, um zu der Zeit des spekulativen Ladens gelöst zu werden,
oder müssen
bis zu einer nichtspekulativen Verwendung zurückgestellt werden.