DE19534752A1 - Verfahren und System zum Liefern einer Unterstützung für eine spekulative Ausführung - Google Patents
Verfahren und System zum Liefern einer Unterstützung für eine spekulative AusführungInfo
- Publication number
- DE19534752A1 DE19534752A1 DE19534752A DE19534752A DE19534752A1 DE 19534752 A1 DE19534752 A1 DE 19534752A1 DE 19534752 A DE19534752 A DE 19534752A DE 19534752 A DE19534752 A DE 19534752A DE 19534752 A1 DE19534752 A1 DE 19534752A1
- Authority
- DE
- Germany
- Prior art keywords
- speculative
- exception
- operations
- delayed
- central processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 238000012545 processing Methods 0.000 claims abstract description 29
- 230000003111 delayed effect Effects 0.000 claims description 58
- 238000001356 surgical procedure Methods 0.000 claims description 15
- 238000012552 review Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 4
- 238000004891 communication Methods 0.000 claims 2
- 230000011664 signaling Effects 0.000 claims 1
- 230000000644 propagated effect Effects 0.000 abstract description 4
- 238000005457 optimization Methods 0.000 description 18
- 230000008569 process Effects 0.000 description 14
- 230000006399 behavior Effects 0.000 description 9
- 238000012795 verification Methods 0.000 description 7
- 238000013459 approach Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 238000001514 detection method Methods 0.000 description 4
- 238000003860 storage Methods 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000005055 memory storage Effects 0.000 description 3
- 230000001934 delay Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000008030 elimination Effects 0.000 description 2
- 238000003379 elimination reaction Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000011112 process operation Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 101100149256 Mus musculus Sema6b gene Proteins 0.000 description 1
- 230000000454 anti-cipatory effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 150000001768 cations Chemical class 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 150000002500 ions Chemical class 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000000746 purification Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000009420 retrofitting Methods 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000003892 spreading Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
- G06F9/3865—Recovery, e.g. branch miss-prediction, exception handling using deferred exception handling, e.g. exception flags
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30072—Arrangements for executing specific machine instructions to perform conditional operations, e.g. using predicates or guards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
- G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3842—Speculative instruction execution
Description
Diese Erfindung bezieht sich allgemein auf eine Codeoptimie
rung bei einer Computer-Ablaufplanung und insbesondere auf
die architektonische Unterstützung für eine solche Optimie
rung.
Das Verhalten eines Computersystems kann durch das Optimie
ren des Codes eines Computerprogramms verbessert werden,
derart, daß der Computer das Programm schneller ausführen
kann. Einer der Schritte beim Optimieren eines Programms ist
ein Prozeß, der Ablaufplanung (Scheduling) genannt wird. Die
Ablaufplanung ist ein Verfahren, bei der die Reihe von Com
puteroperationen, die ein Programm aufweist, für die Ausfüh
rung organisiert wird. Während des Ablaufplanungsverfahrens
können Operationen des Programms angeordnet, eliminiert oder
bewegt werden, um zu bewirken, daß das Programm für einen
speziellen CPU-Entwurf (CPU = central processing unit = zen
trale Verarbeitungseinheit) effizienter abläuft. Im allge
meinen gibt es zwei Formen von Ablaufplanungen: eine dynami
sche Ablaufplanung, die während der Ausführung eines Pro
gramms durch die Hardware durchgeführt wird, und eine stati
sche Ablaufplanung, die vor der Ausführung durch einen Com
piler durchgeführt wird. Jede dieser Techniken, oder eine
Kombination von beiden, kann verwendet werden, um den Ablauf
von Operationen in einem Computerprogramm zur Verarbeitung
durch ein Computersystem zu planen.
Ein Computerprogramm besteht aus einer Reihe von Befehlen,
die durch eine zentrale Recheneinheit (CPU) in dem Compu
tersystem ausgeführt werden sollen. Ein typisches Programm
ist in einer problemorientierten Programmiersprache ge
schrieben und wird dann in eine Reihe von Befehlen compi
liert, die mit der Befehlssatzarchitektur der CPU kompatibel
sind. Ein Programm kann jedoch auch direkt in einer "Maschi
nensprache" gemäß der Befehlssatzarchitektur des Computers
geschrieben werden. Die Befehlssatzarchitektur definiert das
Format oder die Codierung der Operationen, einschließlich
der Operatoren und Operanden in einem Befehl. Abhängig von
der Struktur der CPU und den eingeschlossenen Ablaufpla
nungstechniken kann jeder Befehl eine oder mehrere Operatio
nen aufweisen. Eine Operation schließt einen Operator ein,
der in einem Operationscode codiert ist, welcher Funktionen
darstellt, beispielsweise addieren, subtrahieren, laden,
speichern, verzweigen, usw . . Außerdem identifiziert eine
Operation die Operanden und die Ergebnisse der Operation. Um
dies zu erreichen, schließt die Operation typischerweise ei
nen Code ein, der den Ort, beispielsweise ein Register, ei
nes Operanden oder mehrerer Operanden identifiziert. Es sind
diese Operationen, die zur Ausführung durch die CPU unter
Verwendung der Optimierungstechniken organisiert werden.
Es gibt unterschiedliche Ebenen der Optimierung. Eine Opti
mierungsebene ist eine lokale Optimierung, bei der ein Code
in einem geradlinigen (gestreckten) Codefragment oder "Ba
sisblock" manipuliert wird, um effizienter abzulaufen. Bei
spiele lokaler Optimierungstechniken sind eine Beseitigung
gemeinsamer Unterausdrücke und eine konstante Ausbreitung.
Eine weitere Optimierungsebene ist eine globale Optimierung,
die das Erweitern lokaler Optimierungstechniken über beding
te Verzweigungen in einem Programm erweitert und ferner
Transformationen für Optimierungsschleifen einschließt. Eine
Form der globalen Optimierung ist die Codebewegung. Ein Bei
spiel der Codebewegung ist das Entfernen eines Codes aus ei
ner Schleife, die bei jeder Iteration einer Schleife den
gleichen Wert berechnet. Eine dritte Optimierungsebene ist
eine Maschinen-abhängige Optimierung. Die Maschinen-abhängi
ge Optimierung schließt die Manipulation eines Codes ein, um
spezifische architektonische Attribute der CPU auszunutzen.
Wenn die CPU beispielsweise eine Pipeline-Funktionseinheit
zum gleichzeitigen Ausführen von Befehlen aufweist, kann der
Code umsortiert werden, um das Pipeline-Verhalten zu verbes
sern.
Um ein Programm zu optimieren, kann ein Code über eine be
dingte Verzweigung in einem Ablaufplanungsverfahren bewegt
werden, was als spekulative Codebewegung bezeichnet wird.
Die spekulative Codebewegung bezieht sich auf die Bewegung
eines Befehls über eine bedingte Verzweigung, die dessen
Ausführung steuert. Die Ausführung eines "spekulativen" Be
fehls kann als eine spekulative oder vorgreifende Ausführung
bezeichnet werden, da der Befehl ausgeführt wird, bevor be
kannt ist, ob der Befehl tatsächlich in dem Programm verwen
det werden wird. Die spekulative Codebewegung kann einen Be
fehlsebenen-Parallelismus verbessern. Da viele Instruktionen
eine lange Latenz aufweisen, was bedeutet, daß sie für die
Ausführung mehrere Taktzyklen benötigen, ist es vorteilhaft,
einen Befehl spekulativ auszuführen. Die Verzögerung, die
ein Befehl andernfalls bewirken würde, kann minimiert wer
den, indem der Befehl im voraus erteilt wird. Die spekulati
ve Codebewegung kann auch bei anderen Optimierungen, bei
spielsweise einer Redundanzbeseitigung, brauchbar sein.
Obwohl die spekulative Ausführung das Potential zum Verbes
sern des Verhaltens aufweist, wurde sie aufgrund der Proble
me beim Behandeln von Fehlern bei spekulativen Befehlen
nicht effektiv implementiert. Wenn ein spekulativer Befehl
einen Fehler erzeugt, sollte der Fehler verzögert und nur
berichtet werden, wenn der spekulative Befehl tatsächlich in
dem Programm verwendet wird. Andernfalls würden Fehler, die
in dem ursprünglichen Programm nicht berichtet worden wären,
berichtet werden, wobei das Verhalten des Programms geändert
würde.
Bestehende Optimierungstechniken begegneten den Problemen
beim Bewegen eines Codes über bedingte Verzweigungen nicht
wirksam. Eine Art, um dem Fehlerproblem zu begegnen, besteht
darin, eine spekulative Codebewegung für Befehle, die einen
Fehler erzeugen können, zu verhindern. Diese Lösung weist
schwerwiegende Begrenzungen auf, da nur Nicht-Fehler-erzeu
gende Operationen bewegt werden können. Eine weitere mögli
che Lösung besteht darin, alle Fehler zu ignorieren. Diese
Lösung ist nicht zufriedenstellend, da sie das Handhaben
oder Berichten von Fehlern verhindert.
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren
und ein System zum Unterstützen einer spekulativen Ausfüh
rung zu schaffen, die das zufriedenstellende Handhaben oder
Berichten von Fehlern ermöglichen.
Diese Aufgabe wird durch Verfahren gemäß Anspruch 1 und An
spruch 14 und ein System gemäß Anspruch 17 gelöst.
Um den Nachteilen und Begrenzungen existierender Optimie
rungstechniken zu begegnen, schafft die vorliegende Erfin
dung ein Verfahren und ein System zum Liefern einer Unter
stützung für eine spekulative Ausführung. Bei einem Ausfüh
rungsbeispiel schließt das Verfahren das Liefern zweier Ver
sionen von Operationen in dem Befehlssatz, eine spekulative
Version und eine nicht-spekulative Version, ein. Operatio
nen, die über bedingte Verzweigungen bewegt werden, werden
als spekulative Operationen codiert. Sowohl spekulative als
auch nicht-spekulative Operationen werden dann durch eine
CPU ausgeführt. Wenn eine spekulative Operation eine Aus
nahme erzeugt, wird die Ausnahme verzögert. Eine Ausnahme
von einer spekulativen Operation kann verbreitet werden,
wenn das Ergebnis einer ersten spekulativen Operation als
eine Eingabe zu einer zweiten spekulativen Operation verwen
det wird. Wenn eine nicht-spekulative Operation eine Ausnah
me erzeugt, wird die Ausnahme unmittelbar gehandhabt oder
berichtet. Der Schritt der Ausführung eines nicht-spekulati
ven Befehls kann das Überprüfen nach verzögerten Ausnahmen
einschließen. Wenn eine verzögerte Ausnahme erfaßt wird,
wird die Ausnahme berichtet.
Bei einem zweiten Ausführungsbeispiel weist das Verfahren
das Liefern von von Natur aus spekulativen Operationen in
dem Befehlssatz auf. Diese von Natur aus spekulativen Opera
tionen werden als spekulative Operationen für die Ablaufpla
nung und für das Verzögern von Ausnahmen behandelt. Jedoch
müssen diese Operationen nicht durch das Codieren derselben
als solche in den Operationscodes als spekulative Operatio
nen identifiziert werden. Vielmehr behandelt die CPU einen
vorbestimmten Satz von Operationen als von Natur aus speku
lativ. Um die Kompatibilität der CPU mit bestehenden Pro
grammen zu verbessern, kann die CPU zwei Betriebsmodi auf
weisen: einen ersten Modus, bei dem der vorbestimmte Satz
von Operationen von Natur aus spekulativ ist, und einen
zweiten Modus, bei dem der vorbestimmte Satz von Operationen
nicht-spekulativ ist. Wie bei dem obigen ersten Ausführungs
beispiel werden Ausnahmen für spekulative Operationen verzö
gert, während Ausnahmen für nicht-spekulative Operationen
unmittelbar berichtet werden.
Ein System zum Unterstützen einer spekulativen Ausführung
kann in einer CPU implementiert sein, die eine Funktions
einheit und eine Registerdatei aufweist. Während der Aus
führung von Operationen in einem Programm erkennt die Funk
tionseinheit der CPU, ob eine Operation spekulativ oder
nicht-spekulativ ist. Wenn eine spekulative Operation eine
Ausnahme erzeugt, speichert die Funktionseinheit Informa
tionen in einem Register in der Registerdatei, welche an
zeigen, daß eine Ausnahme verzögert wurde. Bei einer Imple
mentierung können die Register in der Registerdatei eine
Fehler-Kennung zum Identifizieren, ob eine Ausnahme verzö
gert wurde, aufweisen. Eine nicht-spekulative Operation kann
verwendet werden, um auf verzögerte Ausnahmen zu überprü
fen. Bei dem Verfahren des Ausführens einer derartigen Ope
ration überprüft die Funktionseinheit die Registerdatei, um
zu bestimmen, ob eine Ausnahme verzögert wurde. Wenn eine
Ausnahme verzögert wurde, berichtet die Funktionseinheit die
Ausnahme.
Das Verfahren und das System zum Liefern einer Unterstützung
für eine spekulative Ausführung liefert mehrere Vorteile.
Ausnahmen, die durch spekulative Operationen erzeugt werden,
werden ignoriert, es sei denn, die spekulative Operation
wird tatsächlich in dem Programm verwendet. Folglich erhält
das Computersystem die Verhaltensgewinne, die durch eine
spekulative Ausführung geliefert werden, ohne die vollstän
digen Fähigkeiten einer Fehlererfassung und des Berichtens
derselben zu verlieren. Beim Verwenden des Lösungsansatzes
eines Ausführungsbeispiels kann eine spekulative Ausführung
in einer Befehlssatzarchitektur implementiert sein, bei der
spekulative und nicht-spekulative Versionen für mehrere Ope
rationen vorgesehen sind. Wenn jedoch ein solcher Lösungs
ansatz in einer speziellen Befehlssatzarchitektur nicht mög
lich ist, kann eine spekulative Ausführung unterstützt wer
den, indem mehrere Operationen also von Natur aus spekulativ
behandelt werden, ohne Operationscodes zu ändern oder spe
ziell zu codieren.
Dieser alternative Lösungsansatz ist speziell beim Nachrü
sten einer existierenden Befehlssatzarchitektur, um eine
spekulative Ausführung zu unterstützen, nützlich. Um ein
existierendes System nachzurüsten, kann die Hardware einer
CPU modifiziert werden, um eine spekulative Ausführung zu
unterstützen, während die Kompatibilität mit Programmen, die
für eine existierende Befehlssatzarchitektur geschrieben
wurden, beibehalten wird. Der Befehlssatz wird nicht mate
riell geändert, sondern statt dessen wird die Hardware-Se
mantik der Operationen geändert, um eine Unterstützung zum
Verzögern und Überprüfen auf verzögerte Ausnahmen, die durch
spekulative Operationen erzeugt werden, hinzuzufügen. Bei
diesem Lösungsansatz unterstützt die CPU zwei Betriebsmodi:
einen ersten Modus, bei dem die Operationen nicht-spekulativ
sind; und einen zweiten Modus, bei dem einige Operationen
als von Natur aus spekulativ behandelt werden. Der zweite
Modus unterscheidet sich von dem ersten dahingehend, daß
Ausnahmen für von Natur aus spekulative Operationen verzö
gert werden. Durch das Unterstützen dieser zwei Betriebsmodi
ist die CPU mit der binären Form von Programmen, die für
eine existierende Befehlssatzarchitektur compiliert wurden,
kompatibel, ungeachtet dessen, ob die Programme unter Ver
wendung einer spekulativen Codebewegung optimiert wurden.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung
werden nachfolgend bezugnehmend auf die beiliegenden Zeich
nungen näher erläutert. Es zeigen:
Fig. 1 ein Blockdiagramm eines Computersystems, in dem ein
Ausführungsbeispiel der Erfindung implementiert
sein kann;
Fig. 2 ein Blockdiagramm einer zentralen Verarbeitungsein
heit gemäß einem Ausführungsbeispiel der Erfindung;
Fig. 3 ein Diagramm eines Befehls mit mehreren Operatio
nen; und
Fig. 4 ein Flußdiagramm eines Verfahrens zum Unterstützen
einer spekulativen Ausführung gemäß einem Ausfüh
rungsbeispiel der Erfindung.
Ein Ausführungsbeispiel der Erfindung liefert allgemein ein
Verfahren und ein System zum Unterstützen einer spekulativen
Ausführung. Die folgende Beschreibung beginnt mit einer all
gemeinen Erklärung einer spekulativen Ausführung. Als näch
stes werden Systeme zum Unterstützen einer spekulativen Aus
führung beschrieben. Schließlich wird ein Verfahren zum Un
terstützen einer spekulativen Ausführung gemäß den Ausfüh
rungsbeispielen der Erfindung beschrieben.
Eine spekulative Codebewegung kann wirksam in CPUs verwendet
werden, die die Fähigkeit einer gleichzeitigen Verarbeitung
aufweisen. Eine CPU kann eine Reihe von Operationen schnel
ler ausführen, indem getrennte Operationen gleichzeitig aus
gegeben werden, oder sich die Ausführung von Operationen
überlappt. Eine typische CPU führt eine Operation in Phasen
aus. Bei einer CPU, die mehr als eine Funktionseinheit zum
Ausführen von Operationen aufweist, kann die CPU mehrere
Operationen ausgeben und die gleiche Phase für mehrere Ope
rationen gleichzeitig durchführen. Bei einem Pipeline-Pro
zessor weist die CPU eine Pipeline zum Verarbeiten jeder
Phase in einer Operation wie ein Fließband auf. Die Pipe
line-Verarbeitung reduziert die Gesamtverarbeitungszeit
eines Programms, indem ermöglicht wird, daß der Prozessor
unterschiedliche Phasen mehrerer Befehle gleichzeitig aus
führt. Eine CPU kann entweder mehrere Funktionseinheiten
oder eine Pipeline-Verarbeitung einschließen, oder kann bei
de Merkmale kombinieren.
In CPUs mit gleichzeitiger Verarbeitung kann eine spekula
tive Codebewegung das Verhalten optimieren, indem dem La
tenzproblem begegnet wird. Die Latenz ist die Zeit, die für
die CPU erforderlich ist, um eine Operation abzuschließen.
Eine Operation mit einer langen Latenz kann die Ausführung
eines Programms blockieren oder verzögern, während die CPU
wartet, um eine Operation abzuschließen, bevor eine weitere
begonnen wird. Ohne eine spekulative Codebewegung muß die
CPU eine Verzweigungsbedingung auswerten, bevor irgendeine
der Operationen nach der Verzweigung ausgegeben wird. Durch
das Bewegen einer Operation über die bedingte Verzweigung
kann die CPU die Operation als eine spekulative Operation im
voraus ausgeben. Bei einer CPU mit mehreren Funktionsein
heiten oder einer Pipeline-Verarbeitung kann die CPU die
spekulative Operation gleichzeitig mit anderen Operationen
verarbeiten. Wenn die Verzweigung, an der die Operation ih
ren Ursprung hat, verfolgt wird, wird die Operation entweder
teilweise oder vollständig zu der Zeit abgeschlossen, zu der
das Programm die ursprüngliche Position der Operation er
reicht. Die spekulative Codebewegung begegnet dem Latenzpro
blem, indem das Blockieren bei der Ausführung einer Opera
tion reduziert oder sogar beseitigt wird. Die spekulative
Codebewegung ist besonders bei Prozessoren mit der Fähigkeit
einer gleichzeitigen Verarbeitung nützlich, da die CPUs in
derartigen Systemen die Kapazität besitzen, mehrere Opera
tionen gleichzeitig durchzuführen.
Das Verfahren des Ausführens spekulativer Befehle wird als
spekulative Ausführung bezeichnet. Die spekulative Codebewe
gung kann auf eine Vielzahl von Ablaufplanungstechniken im
plementiert werden, um eine Unterstützung für die spekula
tive Ausführung zu liefern. Die spekulative Codebewegung
kann in Verbindung mit CPUs mit mehreren Funktionseinheiten
oder Pipeline-CPUs verwendet werden, um den Parallelismus
auszunutzen und dadurch ein Programm zu optimieren. Die spe
kulative Codebewegung kann in Verbindung mit einer teilwei
sen Redundanzbeseitigung verwendet werden, um ein Programm
für tatsächlich jeden CPU-Typ zu optimieren. Zusätzlich zu
der Unterstützung der Ablaufplanung erfordert die spekula
tive Ausführung auch eine architektonische Unterstützung.
Um eine spekulative Ausführung zu implementieren, muß zwei
primären Problemen begegnet werden: der spekulativen Code
bewegung und dem Erfassen und Berichten von Ausnahmen. In
diesem Zusammenhang bezieht sich die spekulative Codebewe
gung auf die Ablaufplanungstechnik, die verwendet wird, um
Operationen über ihre zugehörigen Verzweigungen zu bewegen.
Die Erfassung und das Berichten von Ausnahmen bezieht sich
auf die Ablaufplanung bezüglich der Möglichkeit, daß eine
spekulative Operation einen Fehler erzeugen kann. Außerdem
bezieht sie sich auf die Erfassung und das Berichten von
Fehlern, die durch spekulative Operationen erzeugt werden.
Da diese Probleme sich stark auf die Ablaufplanung beziehen,
werden dieselben zuerst im Zusammenhang mit der Ablaufpla
nung, um eine spekulative Ausführung zu unterstützen, erör
tert. Als nächstes wird ein bevorzugtes Verfahren der Erfas
sung und des Berichtens von Ausnahmen erläutert.
Bevor ein Programm ausgeführt wird, optimiert eine Ablauf
planungseinheit das Programm durch die Verwendung einer spe
kulativen Codebewegung oder vielleicht anderer Optimierungs
techniken, um die Verarbeitungszeit des Programms zu senken.
Die Ablaufplanungseinheit kann dynamisch oder statisch sein,
oder kann eine Kombination einer Compiler- und einer Hard
ware-Ablaufplanung einschließen. Jede einer Anzahl von gut
bekannten Ablaufplanungstechniken kann verwendet werden,
einschließlich aber nicht begrenzt auf eine Spurablaufpla
nung, eine Modulo-Ablaufplanung und eine verbesserte Pipe
line-Verarbeitung. Ungeachtet der verwendeten Ablaufpla
nungstechnik sollte die Ablaufplanungseinheit eine Unter
stützung für eine spekulative Codebewegung einschließen.
Eine spekulative Codebewegung schließt das Bewegen einer
Operation von ihrem Heim-Basisblock zu einem vorherigen Ba
sisblock ein. Ein Basisblock ist eine geradlinige (unver
zweigte) Sequenz von Operationen, denen eine einzelne Ver
zweigung folgt. Der Heim-Basisblock einer Operation ist der
Basisblock, in dem sich dieselbe in dem ursprünglichen Pro
gramm befindet. Die vorherigen Basisblöcke für einen gegebe
nen Basisblock sind alle Basisblöcke, die zu dem gegebenen
Basisblock verzweigen können, oder die dem Basisblock se
quentiell vorangehen. Während einer Ablaufplanung kann eine
Operation über eine Verzweigung zu einem Satz von vorherge
henden Basisblöcken bewegt werden. Die Operation wird derart
bewegt, daß die Operation stets ausgeführt wird, bevor ir
gendeine Verwendung ihres Ergebnisses auftreten wird. Um
dieser Anforderung zu genügen, kann die Operation zu mehre
ren vorhergehenden Basisblöcken bewegt werden. Diese allge
meine Technik einer spekulativen Codebewegung kann in einer
Vielzahl von Ablaufplanungsverfahren verwendet werden.
Ein Verfahren zur Ablaufplanung über Basisblöcke ist die
Superblock-Ablaufplanung. Ein Superblock ist ein Block von
Operationen, den die Steuerung nur von oben betreten kann,
jedoch an einem oder mehreren Punkten verlassen kann. Die
Superblock-Ablaufplanung besteht aus zwei Schritten: einem
Abhängigkeitsgraph-Aufbau und einer Listen-Ablaufplanung.
Der Abhängigkeitsgraph stellt die Steuerungs- und Daten-Ab
hängigkeiten zwischen Operationen in einem Superblock dar.
Unter Verwendung der Steuerabhängigkeiten kann die Ablauf
planungstechnik Beschränkungen bezüglich einer spekulativen
Codebewegung begegnen. In diesem Zusammenhang sind die zwei
primären Beschränkungen auf die Bewegung einer Operation
über eine Verzweigung: 1) Das Ergebnis der Operation wird
nicht verwendet, bevor es neu definiert wird, wenn die
Verzweigung durchgeführt wird; und 2) der Operation wird
keine Ausnahme bewirken, die die Ergebnisse des Programms
ändert, wenn die Verzweigung durchgeführt wird.
Verschiedene Ablaufplanungstechniken unter Verwendung des
Superblockmodells können diesen allgemeinen Beschränkungen
bezüglich der spekulativen Codebewegung begegnen. Bei den
meisten Ablaufplanungstechniken kann die erste Beschränkung
unter Verwendung von Compilierzeit-Umbenennungstransforma
tionen überwunden werden. Nachdem Steuerabhängigkeiten eli
miniert sind, kann eine Listen-Ablaufplanung unter Verwen
dung des Abhängigkeitsgraphs, der Befehlslatenzen und der
Betriebsmittelbeschränkungen durchgeführt werden, um zu be
stimmen, wie der Ablauf der Operationen geplant wird. Das
Problem von Ausnahmen kann unterschiedlich gehandhabt wer
den, abhängig von der Ablaufplanungstechnik.
Eine Ausnahme ist ein Fehler, beispielsweise ein arithmeti
scher Unterlauf oder Überlauf, ein undefinierter Befehl oder
ein Speicherzugriffsfehler. Wenn eine Operation eine Ausnah
me in einem nicht-spekulativen System erzeugt, wird die Aus
nahme typischerweise unmittelbar berichtet, wobei die CPU zu
einer Ausnahmenhandhabungsroutine des Betriebssystems ver
zweigt. Wenn spekulative Operationen unmittelbar eine Aus
nahme berichten, müßte die CPU eine möglicherweise unnötige
und semantisch falsche Fehlerhandhabung für spekulative Ope
rationen durchführen, die schließlich nicht in dem Ausfüh
rungsweg des Programms sein müssen.
Die bevorzugte Art, Ausnahmen in spekulativen Operationen zu
behandeln, besteht darin, daß Berichten der Ausnahmen zu
verzögern.
Die Ausnahme wird nur berichtet, wenn die Operation tatsäch
lich in ihrem Heim-Basisblock ausgeführt wird. Durch das
Verzögern derartiger Ausnahmen wird eine unnötige Ausnah
men-Handhabung vermieden. Das Computersystem liefert ein
verbessertes Verhalten und bewahrt die Semantik des ur
sprünglichen Programms.
Wenn das Ergebnis einer spekulativen Operation, die eine
Ausnahme erzeugt, als eine Eingabe zu einer zweiten speku
lativen Operation verwendet wird, wird die Ausnahme zu der
zweiten Operation verbreitet. Eine Ausnahme wird durch alle
spekulativen Operationen verbreitet, die das Ergebnis einer
spekulativen Operation, die einen Fehler erzeugt, verwenden.
Diese verbreiteten Ausnahmen werden nur berichtet, wenn die
Ausnahme zu einer Operation verbreitet wird, die tatsächlich
in dem Ausführungsweg des Programms verwendet wird.
Um ein verzögertes Berichten von Ausnahmen zu unterstützen,
weist ein System gemäß einem Ausführungsbeispiel der Erfin
dung eine Einrichtung zum Verzögern der Ausnahme auf. Eine
Ausnahme kann unter Verwendung eines Puffers oder einer Ken
nung in dem Register, um eine Aufzeichnung, daß ein Fehler
aufgetreten ist, zu halten, verzögert werden. Das System
weist ferner eine Einrichtung zum Berichten einer verzöger
ten Ausnahme auf. Der Heimblock eines spekulativen Befehls
schließt eine Operation zum Überprüfen ein, ob eine Ausnahme
aufgetreten ist. Diese Operation kann eine zusätzliche
Überprüfungsoperation sein, die in den Heimblock eingefügt
ist, oder kann in eine nicht-spekulative Operation in dem
Heimblock eingebaut sein. Eine Implementierung dieser As
pekte eines Computersystems wird nachfolgend beschrieben.
Zum Überblick zeigt Fig. 1 ein verallgemeinertes Blockdia
gramm eines Computersystems 20, in dem ein System gemäß der
Erfindung verkörpert sein kann. Das Computersystem 20 weist
eine CPU 22 auf, die mit einem Speicher 24 und einem oder
mehreren peripherischen Geräten 26 über einen Systembus 28
gekoppelt ist. Der Systembus 28 kann Daten und Steuersignale
zu der CPU 22, dem Speicher 24 und den peripherischen Gerä
ten 26 leiten. Der Speicher 24 weist vorzugsweise einen Di
rektzugriffsspeicher (RAM; RAM = Random Access Memory), kann
jedoch auch mit einem Nur-Lese-Speicher (ROM; ROM = Read
Only Memory), oder einer Kombination von RAM und ROM imple
mentiert sein. Der Speicher 24 speichert Daten für ein oder
mehrere Programme, die in dem Computersystem 20 ausgeführt
werden können.
Fig. 2 ist ein Blockdiagramm einer CPU 22 gemäß einem Aus
führungsbeispiel der Erfindung. Die CPU 22 weist mehrere
Funktionseinheiten 30, ein oder mehrere Registerdateien 32
und eine Befehlseinheit 34 auf. Die Registerdateien 32 ent
halten typischerweise mehrere Universalregister 36 zum Spei
chern von Werten, Adressen und möglicherweise anderen Daten.
Außerdem können die Register 32 in der Registerdatei 36 ein
Fehler-Kennungsbit 38 einschließen, um zu identifizieren, ob
eine Aufnahme aufgetreten ist. Die Verwendung des Fehler-
Kennungsbits 38 bei einer spekulativen Ausführung wird de
taillierter nachfolgend erläutert.
Die Architektur der CPU 22 kann variieren. Diese spezielle
Architektur zeigt nur den groben Hardwareentwurf einer CPU
22 gemäß einem möglichen Ausführungsbeispiel. Eine spekula
tive Ausführung, die gemäß der Erfindung implementiert ist,
kann eine Verhaltensverbesserung in einer Vielzahl von CPU-
Entwürfen liefern, die speziell CPUs mit mehreren Funktions
einheiten oder CPUs mit mehreren Pipeline-Funktionseinheiten
einschließen. Eine spekulative Ausführung ist besonders
wirksam beim Verbessern des Verhaltens in Superscalar- oder
VLIW-Computern (VLIW = Very Long Instruction Word = sehr
langes Befehlswort).
Bei dem Verfahren, ein Programm auszuführen, führt die CPU
22 eine Reihe von Befehlen aus, die im Speicher 24 gespei
chert sind. Die Befehlseinheit 34 ruft über den Systembus 28
einen Befehl von dem Speicher ab und decodiert nachfolgend
den Befehl. Abhängig vom Typ der CPU und/oder des verwende
ten Ablaufplanungsverfahrens kann ein Befehl mehr als eine
Operation aufweisen. Die Befehlseinheit 34 gibt Operationen
zu einer Funktionseinheit 30 oder zu mehreren Funktionsein
heiten (die in Fig. 2 als gestapelte Blöcke gezeigt sind)
aus. Die Befehlseinheit 34 sendet Steuersignale zu einer
Funktionseinheit 30, um die Operation oder die Operationen
in einem Befehl auszuführen. Als Reaktion auf diese Steuer
signale liest die Funktionseinheit 30 Daten, beispielsweise
eine Adresse oder einen Wert, aus den geeigneten Registern
in der Registerdatei 32 und führt eine Operation durch. Für
einige Operationen schreibt die Funktionseinheit 30 ein Er
gebnis zurück in die Registerdatei 32. Für eine Speicher-
Speicherungsoperation liest die Funktionseinheit 30 eine
Speicheradresse und einen Wert, die in der Registerdatei 32
gespeichert sind, und überträgt den Wert direkt zu dem Spei
cher 24.
Fig. 3 zeigt das Format eines Befehls mit mehreren Operatio
nen. Der Befehl schließt drei Operationen ein, die jeweils
einen Operationscode und einen oder mehrere Operanden auf
weisen. Beginnend von links weist die erste Operation in dem
Befehl einen Operationscode 42, ein Bestimmungsregisterfeld
44 und zwei Quellenregisterfelder 46, 48 auf. Die zweite
Operation besitzt einen Operationscode 50 zwei Quellenregi
sterfelder 52, 54. Schließlich weist die dritte Operation
einen Operationscode 56 und nur ein einziges Quellenregi
sterfeld 58 auf. Die Quellenregisterfelder spezifizieren den
Ort der Eingaben in die Operation, während das Bestimmungs
registerfeld den Ort des Ergebnisses spezifiziert.
Diese drei Operationen liefern ein Beispiel eines typischen
Befehls. Die erste Operation ist eine arithmetische Addier-
Operation, bei der die Funktionseinheit 30 Werte, die in den
Registern R1 und R2 gespeichert sind, liest, dieselben ad
diert und das Ergebnis in ein Register R3 schreibt. Die
zweite Beispieloperation ist eine Speicheroperation 50
(MEM-Operation), bei der das erste Register R4 eine Adresse
speichert, während das zweite Register R5 einen Wert spei
chert. Die Funktionseinheit 30 liest die Adresse und den
Wert aus den Registern und speichert den Wert in dem Spei
cher 24 an der spezifizierten Adresse. Die dritte Beispiel
operation ist eine einfache Bewegungsoperation (MOV-Opera
tion). Um eine spekulative Ausführung zu unterstützen, kann
die Hardware-Semantik dieser Operation modifiziert werden,
derart, daß die Operation verwendet werden kann, um auf ver
zögerte Ausnahmen zu überprüfen.
Die Funktionseinheit 30 liest beispielsweise das Quellenre
gister R6 und initiiert, wenn eine Ausnahme aufgetreten ist,
eine Verzweigungsoperation zu einer Fehlerhandhabungsrou
tine. Das Quellenregister für die Überprüfungsoperation ist
das gleiche wie das Register, das bezüglich einer verzöger
ten Ausnahme überprüft werden soll. Das Quellenregister der
Überprüfungsoperation kann das Bestimmungsregister einer
spekulativen Operation sein, die eine Ausnahme erzeugt und
verzögert hat, oder einer spekulativen Operation, die die
verzögerte Ausnahme verbreitet hat. In jedem Fall enthält
das Quellenregister, das überprüft wird, Informationen über
die Verzögerung der Ausnahme.
Ein System zum Unterstützen einer spekulativen Ausführung
kann in einem Computersystem gemäß der Beschreibung bezüg
lich der Fig. 1 bis 3 implementiert sein. Es gibt mehrere
alternative Arten, ein System gemäß der Erfindung zu imple
mentieren. Obwohl zwei spezifische Ausführungsbeispiele
nachfolgend beschrieben werden, ist es offensichtlich, daß
andere Variationen möglich und Fachleuten offensichtlich
sind.
Ein erstes Ausführungsbeispiel der Erfindung schließt das
Codieren spekulativer und nicht-spekulativer Versionen von
Operationen in der Befehlssatzarchitektur der CPU ein. Bei
diesem Ausführungsbeispiel identifizieren die Operations
codes, ob eine Operation nicht-spekulativ oder spekulativ
ist. Der Operationscode 42 der Addier-Operation in Fig. 3
könnte beispielsweise codiert sein, um die Operation als
entweder spekulativ oder nicht-spekulativ zu bezeichnen. Die
Version der Operationen bewirkt, ob eine Ausnahme, die durch
die Operation erzeugt wird, berichtet oder verzögert wird.
Wenn eine nicht-spekulative Operation einen Fehler erzeugt,
berichtet die Funktionseinheit 30 den Fehler unmittelbar.
Wenn ein spekulativer Befehl eine Ausnahme erzeugt, wird die
Funktionseinheit 30 die Ausnahme andererseits verzögert be
richten. In dem letzteren Fall wird die Ausnahme nur berich
tet, wenn das Ergebnis der Operation tatsächlich in seinem
Heim-Basisblock verwendet wird.
Ein zweites Ausführungsbeispiel der Erfindung liefert ein
System zum Unterstützen einer spekulativen Ausführung bei
einer minimalen Befehlssatzarchitektur. Im Gegensatz zu dem
ersten Ausführungsbeispiel unterstützt dieses zweite Ausfüh
rungsbeispiel eine spekulative Ausführung ohne das Ein
schließen von Operationscodes für spekulative Operationen.
Statt dessen behandelt das System eine Anzahl von vorbestimm
ten Operationen in einem Befehlssatz als spekulativ, ohne zu
erfordern, daß die Operationen speziell codiert sind. Wie
bei dem ersten Ausführungsbeispiel weist dieses zweite Aus
führungsbeispiel ebenfalls eine architektonische Unterstüt
zung zum Verzögern von Ausnahmen von spekulativen Opera
tionen und zum Berichten dieser verzögerten Ausnahmen auf.
Bei dem zweiten Ausführungsbeispiel können die Ablaufpla
nungseinheit und die CPU einen vorbestimmten Satz von Opera
tionen als spekulativ behandeln. Dieser Satz von Operationen
kann möglicherweise jede Operation in dem Befehlssatz ein
schließen. Jedoch sollten Operationen, deren Wirkungen
schwierig rückgängig zu machen sind, beispielsweise Verzwei
gungsoperationen oder Operationen, die außerhalb der CPU
sichtbar sind, im allgemeinen nicht spekulativ ausgeführt
werden. Alle Operationen, die nicht außerhalb der CPU sicht
bar sind, können als von Natur aus spekulative Operationen
behandelt werden, indem die Hardware-Semantik in der Funk
tionseinheit 30 geändert wird. Um eine spekulative Ausfüh
rung bei diesem Ausführungsbeispiel zu unterstützen, wird
der Ablauf von Natur aus spekulativen Operationen als speku
lative Operationen geplant, wobei die CPU-Hardware eine Un
terstützung zum Verzögern und Berichten von verzögerten Aus
nahmen von diesen Operationen aufweist. Obwohl ein vorbe
stimmter Satz von Operationen in der CPU als von Natur aus
spekulativ behandelt wird, bleiben Operationen, die außer
halb der CPU sichtbar sind, nicht-spekulativ. Ein Beispiel
einer Operation, die außerhalb der CPU sichtbar ist, ist
eine Speicher-Speicherung. Diese wird als außerhalb der CPU
sichtbar betrachtet, da sie eine Wechselwirkung mit einem
Speicher außerhalb der CPU durchführt, und spezieller das
Überschreiben eines Ortes in dem Speicher 24 einschließt. Es
ist nicht bevorzugt, eine derartige Operation spekulativ
durchzuführen, da dieselbe einen weiteren Prozeß beeinflus
sen kann, der eine Wechselwirkung mit dem gleichen Speicher
ort aufweist. Es ist ferner sehr schwierig, einen Fehler zu
korrigieren, der durch eine Operation erzeugt wurde, die den
Zustand von externer Hardware beeinflußt. Aus diesen Gründen
ist es bevorzugt, Operationen, die außerhalb des Prozessors
sichtbar sind, als nicht-spekulativ zu behandeln.
Unter Verwendung des Lösungsansatzes des zweiten Ausfüh
rungsbeispiels erfordert ein Befehlssatz keine spekulativen
und nicht-spekulativen Versionen von Operationen. Folglich
kann eine spekulative Ausführung auf eine Art unterstützt
werden, die die Kompatibilität mit einer existierenden Be
fehlssatzarchitektur beibehält. Die Operationen, die als von
Natur aus spekulativ und nicht-spekulativ behandelt werden,
variieren mit der Architektur der CPU. In einigen Systemen
können alle Operationen, mit Ausnahme derer, die außerhalb
der CPU sichtbar sind, spekulativ behandelt werden. Alterna
tiv könnten alle Operationen als von Natur aus spekulativ
behandelt werden. Bei einer weiteren Alternative könnten
einige Operationen von Natur aus spekulativ sein, während
andere als sowohl spekulativ als auch nicht-spekulativ vor
gesehen sind.
Ein System gemäß dem zweiten Ausführungsbeispiel kann ent
worfen sein, um mit der binären Form eines Programms kompa
tibel zu sein, ungeachtet dessen, ob es unter Verwendung ei
ner spekulativen Codebewegung optimiert wurde. Um die spe
kulative Ausführung, die in der CPU unterstützt wird, auszu
nutzen, werden Programme unter Verwendung einer spekulativen
Codebewegung optimiert, um Operationen zu bewegen, für die
die CPU eine spekulative Version aufweist. Es können daher
zwei Kategorien von Programmen existieren: existierende Pro
gramme, die nicht unter Verwendung einer spekulativen Code
bewegung optimiert wurden, und neue Programme, die für die
spekulative Ausführung, die durch die CPU unterstützt wird,
spezifisch optimiert wurden. Um die Kompatibilität mit bei
den Programmen beizubehalten, kann die CPU einen Schaltungs
aufbau aufweisen, um einen nicht-spekulativen Modus und ei
nen von Natur aus spekulativen Modus zu unterstützen.
Wenn die CPU beide Betriebsmodi unterstützen soll, muß sie
einen Schaltungsaufbau zum Erkennen dessen, ob ein Programm
für eine spekulative Ausführung optimiert wurde, aufweisen.
Dieser Schaltungsaufbau kann ein Register, beispielsweise
das Statuswortregister, in dem ein Modusbit gespeichert wer
den kann, aufweisen. Bevor die CPU die Ausführung eines Pro
gramms beginnt, liest sie dieses Register und schaltet auf
den geeigneten Modus. Das Modusbit kann auf eine Vielzahl
von Arten gesetzt werden. Wenn ein Programm beispielsweise
compiliert wurde, um ein spekulative Ausführung auszunutzen,
die in der CPU unterstützt wird, kann das Betriebssystem
programmiert sein, um das Modusbit zu setzen. Alternativ
kann der Compiler des Programms das Modusbit setzen, indem
er den Modus in einer Statusoperation, die in der binären
Form des Programms plaziert ist, identifiziert. Viele andere
Arten zum Spezifizieren des Betriebsmodus sind möglich und
sind Fachleuten offensichtlich.
Obwohl ein System gemäß dem zweiten Ausführungsbeispiel kei
ne zwei Betriebsmodi unterstützen muß, ist es vorteilhaft,
zwei Betriebsmodi zu unterstützen, um eine Kompatibilität
mit existierenden Programmen beizubehalten. Wenn die CPU nur
Programme ausführen soll, die für eine spekulative Ausfüh
rung spezifisch optimiert wurden, muß die CPU nicht einen
nicht-spekulativen Modus unterstützen. Ein Vorteil des zwei
ten Ausführungsbeispiels besteht jedoch darin, eine Kompa
tibilität mit existierenden Befehlssatzarchitekturen und
Programmen, die bereits compiliert wurden, um auf CPUs zu
laufen, die auf diesen Architekturen basieren, beizubehal
ten. Wenn eine Kompatibilität mit existierenden Programmen
wichtig ist, sollte die CPU sowohl einen spekulativen als
auch einen nicht-spekulativen Betriebsmodus unterstützen.
Das erste und das zweite Ausführungsbeispiel weisen eine
architektonische Unterstützung zum Verzögern und Berichten
von Ausnahmen auf. Dies kann ein Fehler-Kennungsbit 38 in
den Registern der Registerdateien einschließen. Wenn in ei
ner spekulativen Operation eine Ausnahme auftritt, kann die
Funktionseinheit das Fehler-Kennungsbit setzen, um anzuzei
gen, daß eine Ausnahme aufgetreten ist. Die Ausnahme wird
nicht unmittelbar berichtet, sondern wird vielmehr verzö
gert. Informationen über die Ausnahme können in das Bestim
mungsregister geschrieben werden, um die Fehlerhandhabung zu
unterstützen. Diese Informationen können den Befehl und die
Operation in dem Befehl, die die Ausnahme erzeugt hat, iden
tifizieren. Beispielsweise können die Informationen eindeu
tig den Programm-Zählerwert der Operation identifizieren,
die eine Ausnahme erzeugt hat. Sie können ferner den Ausnah
metyp, beispielsweise eine Adressverletzung, einen arithme
tischen Unterlauf und Überlauf, usw., identifizieren. Wenn
eine weitere spekulative Operation das Ergebnis dieser Ope
ration als eine Eingabe verwendet, wird die Ausnahme ver
breitet. Um die Ausnahme zu verbreiten, wird das Fehler-Ken
nungsbit 38 in dem Bestimmungsregister gesetzt, und die Aus
nahmeinformationen werden in das Bestimmungsregister ko
piert. Auf diese Weise kann das System Ausnahmen verzögern,
die durch spekulative Operationen erzeugt wurden, bis das
Ergebnis der Operation tatsächlich in dem Ausführungsweg des
Programms verwendet wird.
Ein Fehler-Kennungsbit 38 ist nur eine Art des Verzögerns
einer Ausnahme. Genauso kann eine andere Hardware verwendet
werden. Beispielsweise kann eine spekulative Operation, die
eine Ausnahme erzeugt, Informationen in einen Puffer schrei
ben, die identifizieren, daß eine Ausnahme aufgetreten ist,
und Ausnahmeinformationen, die bei der Fehlerhandhabung ver
wendet werden, einschließen. Wenn der spekulative Befehl
tatsächlich in dem Ausführungsweg des Programm verwendet
wird, können die Fehlerinformationen aus dem Puffer gelesen
werden, wobei die Ausnahme entsprechend gehandhabt wird.
Ein System, das entweder gemäß dem ersten oder dem zweiten
Ausführungsbeispiel der Erfindung aufgebaut ist, weist fer
ner eine architektonische Unterstützung zum Berichten ver
zögerter Ausnahmen auf. Diese Unterstützung kann eine Über
prüfungsfunktion einschließen, die in eine nicht-spekulative
Operation eingebaut ist, oder kann die Hinzufügung einer ge
trennten Überprüfungsoperation einschließen. Wenn Operatio
nen, die außerhalb der CPU sichtbar sind, nicht-spekulativ
sind, könnte eine Überprüfungsoperation in eine dieser Ope
rationen eingebaut werden. Beispielsweise könnte die Funk
tionseinheit 30 als Teil einer Speicher-Speicherungsopera
tion auf verzögerte Ausnahmen überprüfen. Wie oben beschrie
ben wurde, weist eine Speicher-Speicherungsoperation zwei
Quellenregister auf - eines, das die Date, die im Speicher
gespeichert werden soll, enthält, und eines, das die Spei
cheradresse enthält. Eine Speicher-Speicherungsoperation
überprüft, wenn sie als Überprüfungsoperation wirkt, ihre
beiden Quellenregister auf verzögerte und/oder verbreitete
Ausnahmen.
Bezugnehmend auf den Beispielbefehl von Fig. 3 könnte eine
Speicher-Speicherungsoperation eine Ausnahmenerfassungs-Se
mantik einschließen. Als Teil der Speicher-Speicherungsope
ration würde die Funktionseinheit 30 das Ausnahme-Kennungs
bit 38 der Quellenregister der Speicher-Speicherungsopera
tion lesen, um zu bestimmen, ob eine Ausnahme verzögert wur
de. Wenn eine Ausnahme verzögert wurde, würde die Speicher-
Speicherungsoperation dann eine Verzweigung zu einer Fehler
handhabungsroutine durchführen.
Als ein weiteres Beispiel könnte eine getrennte Überprü
fungsoperation erzeugt werden. Dies würde das Codieren nur
eines zusätzlichen Operationscodes für eine Überprüfungs
operation einschließen. Diese Überprüfungsoperationen können
während des Ablaufplanungsverfahrens eingefügt sein. Die
Überprüfungsoperationen sollten derart eingefügt sein, daß
jede spekulative Operation, die eine Ausnahme erzeugen oder
verbreiten kann, überprüft werden kann. Das Quellenregister
der Überprüfungsoperation kann das Bestimmungsregister der
eine Ausnahme erzeugenden Operation sein. Ferner kann das
Quellenregister ein Bestimmungsregister der letzten Opera
tion in einer Kette von verbreiteten Ausnahmen sein. Um si
cherzustellen, daß die spekulativen Operationen überprüft
werden, können Überprüfungsoperationen nach einen spekulati
ven Operation oder nach eine Kette spekulativer Operationen
eingefügt sein. Da eine Ausnahme zu allen Operationen, die
das Ergebnis einer spekulativen Operation verwenden, die ei
nen Fehler erzeugt hat, verbreitet werden, muß die Überprü
fungsoperation nicht für jede spekulative Operation einge
fügt sein.
Wiederum bezugnehmend auf Fig. 3 ist die dritte Operation
ein Beispiel einer Überprüfungsoperation, die verwendet wer
den kann, um auf verzögerte Ausnahmen zu überprüfen. Diese
Operation besitzt nur ein Quellen- und kein Bestimmungs-Re
gister. Wenn eine Ausnahme verzögert wurde, enthält das
Quellenregister einer Überprüfungsoperation Informationen,
die den Ausnahmetyp und die Operation, die die Ausnahme
erzeugt hat, identifizieren. Wenn eine Ausnahme erfaßt ist,
können die Informationen in dem Quellenregister der Über
prüfungsoperation verwendet werden, um die Ausnahme zu hand
haben. Typischerweise verzweigt die CPU zu einer Ausnahme
handhabungsroutine, wenn eine Ausnahme erfaßt wird.
Es sollte offensichtlich sein, daß die vorhergehende Er
läuterung eine von vielen möglichen Arten des Erfassens und
Berichtens einer verzögerten Ausnahme beschreibt. Als eine
weitere Alternative könnte eine Überprüfungsoperation eine
Operation an einem Speicherort überprüfen, um zu bestimmen,
ob die Operation an diesem Ort einen Fehler erzeugte. Die
Überprüfungsoperation könnte beispielsweise eine Operation
im Speicher überprüfen, die durch deren Programmzähleradres
se identifiziert ist. Die Überprüfungsoperation kann codiert
sein, um eine Programmzähleradresse zu überprüfen, bei
spielsweise "Überprüfe Operation bei PC-Adresse 535" oder
"Überprüfe die drittletzte Operation". Diese Form einer
Überprüfungsoperation könnte eine Alternative sein, um das
Bestimmungsregister einer spekulativen Operation zu über
prüfen. Da diese Überprüfungsoperation nicht das Überprüfen
eines Bestimmungsregister für eine verzögerte Ausnahme ein
schließen würde, kann ein zusätzlicher Puffer verwendet wer
den, um Informationen über den Ausnahmetyp zu speichern, die
verwendet werden, um die Fehlerhandhabung zu unterstützen.
Fig. 4 ist ein Flußdiagramm eines Verfahrens zum Unterstüt
zen einer spekulativen Ausführung gemäß einem Ausführungs
beispiel der Erfindung. Dieses Diagramm zeigt die Operation
eines Systems zum Unterstützen einer spekulativen Ausführung
gemäß dem ersten und dem zweiten Ausführungsbeispiel der Er
findung.
In dem ersten Schritt 62 wird der Ablauf der Operationen ge
plant. Wie oben dargelegt wurde, kann der Ablauf der Opera
tionen entweder dynamisch oder statisch oder vielleicht un
ter Verwendung einer Kombination der beiden geplant werden.
Als Teil des Ablaufplanungsschritts 62 wird eine Überprü
fungsoperation in die Heim-Basisblöcke von Operationen ein
gefügt, die über eine bedingte Verzweigung bewegt wurden.
Bei dem ersten Ausführungsbeispiel werden die Operationsco
des spekulativer Operationen codiert, um dieselben von einer
nicht-spekulativen Version der gleichen Operation zu unter
scheiden. Bei dem zweiten Ausführungsbeispiel wird eine An
zahl von vorbestimmten Operationen als spekulativ behandelt,
ohne als solche codiert zu sein. Sobald der Ablauf des Pro
gramms geplant ist, beginnt die CPU Operationen zur Ausfüh
rung auszugeben.
Eine Operation wird im nächsten Schritt 64 ausgeführt. In
einer CPU mit mehreren Funktionseinheiten 30, wie in Fig. 2
gezeigt ist, können Operationen ausgegeben werden, um Funk
tionseinheiten gleichzeitig zu trennen. Wenn die Funktions
einheiten 30 ferner eine pipelineartige Verarbeitung durch
führen, können mehrere Operationen für jede Pipeline gleich
zeitig bei verschiedenen Ausführungsstufen sein.
Wenn eine Ausnahme während der Ausführung einer Operation
(66) auftritt, reagiert das System abhängig vom Typ der Ope
ration (68) unterschiedlich. Für spekulative Operationen
wird die Ausnahme verzögert (70). Für nicht-spekulative Ope
rationen wird die Ausnahme jedoch berichtet und eine Fehler
handhabungsroutine wird initiiert (72). Nicht-spekulative
Operationen sind diejenigen Operationen, die nicht über eine
bedingte Verzweigung bewegt wurden, sondern vielmehr in ih
rem Heim-Basisblock bleiben. Abhängig von der Implementie
rung können nicht-spekulative Operationen einen beliebigen
Operationstyp einschließen. Beispiele nicht-spekulativer
Operationen schließen Speicher-Speicherungsoperationen, die
nicht über eine Verzweigung bewegt wurden, da sie außerhalb
der CPU sichtbar sind, oder eine Überprüfungsoperation, die
in den Heim-Basisblock von spekulativen Operationen einge
fügt ist, um auf eine verzögerte Ausnahme zu überprüfen,
ein.
Abhängig davon, wie das System implementiert ist, wird eine
Operation auf verschiedene Arten als spekulativ oder nicht
spekulativ identifiziert. Bei dem ersten Ausführungsbeispiel
unterscheiden sich spekulative und nicht-spekulative Opera
tionen durch ihre Operationscodes. Bei dem zweiten Ausfüh
rungsbeispiel wird eine vorbestimmte Anzahl von Operationen
als spekulative Operationen behandelt, ohne eine spezielle
Codierung der Operationscodes für diese spekulativen Opera
tionen zu erfordern. Die CPU erkennt diese von Natur aus
spekulativen Operationen und verzögert Ausnahmen, die von
denselben erzeugt werden. In gleicher Weise erkennt die CPU
die Operationen, die von Natur aus nicht-spekulativ sind,
und berichtet alle Fehler, die von denselben erzeugt werden,
unmittelbar.
Um eine Kompatibilität mit existierenden Programmen beizube
halten, kann die CPU bei dem zweiten Ausführungsbeispiel
zwei Betriebsmodi aufweisen: einen spekulativen Modus und
einen nicht-spekulativen Modus. Bei dem spekulativen Modus
wird der vorbestimmte Satz von Operationen als von Natur aus
spekulativ behandelt. Ausnahmen werden für diese von Natur
aus spekulativen Operationen verzögert. Bei dem nicht-spe
kulativen Modus wird der vorbestimmte Satz von Operationen
als nicht-spekulativ behandelt, wobei Ausnahmen für diese
Operationen nicht verzögert werden.
Es ist möglich eine Anzahl von Operationen als von Natur aus
spekulativ zu behandeln, während spekulative und nicht-spe
kulative Operationen ebenfalls spezifisch codiert werden.
Beispielsweise könnten alle Operationen, die nicht außerhalb
der CPU sichtbar sind, von Natur aus spekulativ sein, wäh
rend alle anderen Operationen, beispielsweise eine Spei
cher-Speicherung in spekulativen und nicht-spekulativen Ver
sionen vorgesehen sein könnten. Dieser Lösungsansatz ist den
Begrenzungen der speziellen Befehlssatzarchitektur unter
worfen, die eine ausreichende Flexibilität aufweisen kann
oder nicht, um zusätzliche Operationscodes hinzuzufügen.
Die Sequenz der Schritte (64-70) kann das Verbreiten
einer verzögerten Aufnahme einschließen. Bei dem Ausfüh
rungsschritt 64 liest die Funktionseinheit 30 die Fehler-
Kennung, um zu bestimmen, ob eine Ausnahme vorher aufgetre
ten ist (66). Wenn die Operation spekulativ ist (68), wird
die Ausnahme durch Setzen des Fehler-Kennungsbits des Ergeb
nisregisters und durch Übertragen der Ausnahmeinformationen
zu dem Ergebnis verbreitet. Beim Verbreiten einer Ausnahme
auf diese Art, verzögert das System die Ausnahme (70) und
berichtet sie nur, wenn sie in einer nicht-spekulativen Ope
ration verwendet wird.
Die Sequenz der Schritte (64-72) kann das Erfassen und Be
richten einer verzögerten Ausnahme einschließen. Eine Aus
nahme wird erfaßt, indem eine nicht-spekulative Operation 64
mit der Fähigkeit einer Fehlerüberprüfung durchgeführt wird.
Das Ausführen dieses Operationstyps schließt das Überprüfen
auf eine verzögerte Ausnahme (66) ein. Die Einrichtung zum
Überprüfen auf eine verzögerte Ausnahme variiert abhängig
von der Implementierung. Nicht-spekulative Operationen kön
nen derart implementiert sein, daß sie auf eine verzögerte
Ausnahme überprüfen, indem das Fehler-Kennungsbit eines Ein
gabe- oder Quellen-Registers gelesen wird. Beispielsweise
kann ein Speicher-Speicherungsbefehl als Teil seiner Seman
tik das Fehler-Kennungsbit lesen, um auf eine verzögerte
Ausnahme zu überprüfen, und eine Ausnahme berichten, wenn
eine solche verzögert wurde. Als ein anderes Beispiel kann
eine Überprüfungsoperation, die in einen Heim-Basisblock
eingefügt ist, auf eine Ausnahme überprüfen, indem das Feh
ler-Kennungsbit eines Ergebnisregisters oder mehrerer Regi
ster der spekulativen Operationen von dem Heim-Basisblock
gelesen wird. Wenn eine Ausnahme verzögert wurde, wird die
Ausnahme unmittelbar berichtet (72). Auf diese Weise verzö
gert das System zum Unterstützen einer spekulativen Ausfüh
rung Ausnahmen, die in spekulativen Operationen erzeugt wer
den.
Obwohl das System und die Verfahren der Erfindung detail
liert im Zusammenhang der alternativen Ausführungsbeispiele
beschrieben wurde, sollte es offensichtlich sein, daß die
Erfindung auf eine Vielzahl von Arten implementiert werden
kann, ohne vom Bereich der Erfindung abzuweichen. Beispiels
weise kann die Befehlssatzarchitektur nicht-spekulative und
spekulative Versionen von Operationen, von Natur aus speku
lative Operationen oder eine Kombination von beiden ein
schließen. Die Einrichtung zum Verzögern einer Ausnahme kann
abhängig von der CPU-Architektur variieren. Beispielsweise
kann ein einzelnes Fehler-Kennungsbit zu Universalregistern
in einer Registerdatei hinzugefügt werden, wobei alternativ
vielleicht ein Puffer verwendet werden könnte, um verzögerte
Ausnahmen zu verfolgen. Die Einrichtung zum Überprüfen auf
verzögerte Ausnahmen kann ebenfalls variieren. Wie beschrie
ben wurde, kann die Hardware-Semantik einer CPU entworfen
sein, um auf verzögerte Ausnahmen zu überprüfen, wenn ein
oder mehrere Typen von nicht-spekulativen Operationen ausge
führt werden. Alternativ könnte eine getrennte Überprüfungs
operation zu der Befehlssatzarchitektur hinzugefügt werden.
Viele weitere Variationen zu den Ausführungsbeispielen sind
möglich, ohne vom Bereich der Erfindung abzuweichen.
Claims (21)
1. Verfahren zum Unterstützen einer spekulativen Ausfüh
rung mit folgenden Merkmalen:
Bereitstellen einer Befehlssatzarchitektur für eine zentrale Verarbeitungseinheit (22), die nicht-speku lative und spekulative Operationen einschließt, wobei zumindest eine der spekulativen Operationen von Natur aus spekulativ ist, derart, daß die zumindest eine von Natur aus spekulative Operation nicht als eine spekula tive Operation codiert ist;
Planen des Ablaufs der Operationen in einem Computer programm einschließlich des Schritts des Bewegens spe kulativer Operationen über bedingte Verzweigungen (62);
Ausführen der Operationen in der zentralen Verarbei tungseinheit (22), wobei das Ausführen folgende Schrit te einschließen:
wenn die Operation eine spekulative Operation ist und eine Ausnahme (66) erzeugt, Verzögern der Ausnahme (70); und
Berichten der Ausnahme, wenn die Operation eine nicht spekulative Operation ist und eine Ausnahme erzeugt.
Bereitstellen einer Befehlssatzarchitektur für eine zentrale Verarbeitungseinheit (22), die nicht-speku lative und spekulative Operationen einschließt, wobei zumindest eine der spekulativen Operationen von Natur aus spekulativ ist, derart, daß die zumindest eine von Natur aus spekulative Operation nicht als eine spekula tive Operation codiert ist;
Planen des Ablaufs der Operationen in einem Computer programm einschließlich des Schritts des Bewegens spe kulativer Operationen über bedingte Verzweigungen (62);
Ausführen der Operationen in der zentralen Verarbei tungseinheit (22), wobei das Ausführen folgende Schrit te einschließen:
wenn die Operation eine spekulative Operation ist und eine Ausnahme (66) erzeugt, Verzögern der Ausnahme (70); und
Berichten der Ausnahme, wenn die Operation eine nicht spekulative Operation ist und eine Ausnahme erzeugt.
2. Verfahren gemäß Anspruch 1, bei dem der Schritt des Be
reitstellens das Bereitstellen eines vorbestimmten Sat
zes von Operationen in der Befehlssatzarchitektur ein
schließt, die von Natur aus spekulative Operationen
sind.
3. Verfahren gemäß Anspruch 1, bei dem der Schritt des Be
reitstellens das Bereitstellen eines vorbestimmten Sat
zes von Operationen in der Befehlssatzarchitektur für
die zentrale Verarbeitungseinheit (22) einschließt,
welche entweder alle von Natur aus spekulativ oder alle
nicht-spekulativ sind, abhängig von einem Modus der
zentralen Verarbeitungseinheit (22); und das ferner
folgende Schritte aufweist:
Spezifizieren des Modus der zentralen Verarbeitungsein heit (22) durch Setzen eines Modusbits in einem Zu standsregister der zentralen Verarbeitungseinheit;
und Lesen des Modusbits in dem Zustandsregister, um den Modus der zentralen Verarbeitungseinheit (22) zu be stimmen.
Spezifizieren des Modus der zentralen Verarbeitungsein heit (22) durch Setzen eines Modusbits in einem Zu standsregister der zentralen Verarbeitungseinheit;
und Lesen des Modusbits in dem Zustandsregister, um den Modus der zentralen Verarbeitungseinheit (22) zu be stimmen.
4. Verfahren gemäß Anspruch 1, bei dem der Schritt des Be
reitstellens das Bereitstellen einer spekulativen und
einer nicht-spekulativen Version eines Satzes von Ope
rationen in der Befehlssatzarchitektur aufweist.
5. Verfahren gemäß Anspruch 4, bei dem die spekulative und
die nicht-spekulative Version des Satzes von Operatio
nen in einem Satz von Operationscodes codiert werden.
6. Verfahren gemäß einem Ansprüche 1 bis 5, bei dem der
Schritt des Verzögerns einer Ausnahme das Speichern von
Informationen einschließt, die anzeigen, daß ein Fehler
aufgetreten ist.
7. Verfahren gemäß Anspruch 6, bei dem der Schritt des
Verzögerns einer Ausnahme das Setzen eines Fehler-Ken
nungsbits in einem Ergebnisregister einer spekulativen
Operation, die eine Ausnahme erzeugt, einschließt.
8. Das Verfahren gemäß einem der Ansprüche 1 bis 7, bei
dem der Schritt des Ausführens einer Operation das
Überprüfen auf eine verzögerte Ausnahme einschließt.
9. Verfahren gemäß einem der Ansprüche 1 bis 8, bei dem
der Schritt des Ausführens einer Operation das Ver
breiten einer verzögerten Ausnahme aufweist, wenn die
Eingabe einer zweiten spekulativen Operation ein Ergeb
nis einer ersten spekulativen Operation ist, welche ei
ne Ausnahme erzeugt hat.
10. Verfahren gemäß einem der Ansprüche 1 bis 9, bei dem
der Schritt des Ausführens einer Operation das Ausfüh
ren einer nicht-spekulativen Operation, um auf eine
verzögerte Ausnahme zu überprüfen, einschließt.
11. Verfahren gemäß Anspruch 10, bei dem die nicht-speku
lative Operation eine Überprüfungsfunktion zum Über
prüfen auf verzögerte Ausnahmen einschließt.
12. Verfahren gemäß Anspruch 10, bei dem die nicht-speku
lative Operation eine Überprüfungsoperation ist, die in
einen Heim-Basisblock einer dazugehörigen spekulativen
Operation eingefügt ist, um auf eine verzögerte Aus
nahme von der dazugehörigen spekulativen Operation zu
überprüfen.
13. Verfahren gemäß einem der Ansprüche 1 bis 7, bei dem
der Ablaufplanungsschritt das Einfügen einer Überprü
fungsoperation in einen Heim-Basisblock einer spekula
tiven Operation einschließt, um auf verzögerte Ausnah
men zu überprüfen.
14. Verfahren zum Unterstützen einer spekulativen Ausfüh
rung, mit folgenden Merkmalen:
Bereitstellen einer vorbestimmten Anzahl von spekula tiven Operationen in einer Befehlssatzarchitektur einer zentralen Verarbeitungseinheit (22);
Planen des Ablaufs der spekulativen Operationen unter Verwendung einer spekulativen Codebewegung, um speku lative Operationen über da zugehörige bedingte Verzwei gungen zu bewegen (62);
Ausführen spekulativer Operationen und, wenn eine Aus nahme von einer spekulativen Operation erzeugt wird (66), Ausführen folgender Schritte:
Verzögern der Ausnahme durch Speichern von Informatio nen, die identifizieren, daß eine Ausnahme aufgetreten ist (70);
Ausführen einer nicht-spekulativen Operation, die eine Überprüfungsoperation einschließt, um auf eine verzö gerte Ausnahme zu überprüfen;
Überprüfen auf eine verzögerte Ausnahme durch das Lesen eines Bestimmungsregisters einer spekulativen Opera tion; und
wenn eine Ausnahme in einer nicht-spekulativen Opera tion erfaßt ist, Berichten der Ausnahme.
Bereitstellen einer vorbestimmten Anzahl von spekula tiven Operationen in einer Befehlssatzarchitektur einer zentralen Verarbeitungseinheit (22);
Planen des Ablaufs der spekulativen Operationen unter Verwendung einer spekulativen Codebewegung, um speku lative Operationen über da zugehörige bedingte Verzwei gungen zu bewegen (62);
Ausführen spekulativer Operationen und, wenn eine Aus nahme von einer spekulativen Operation erzeugt wird (66), Ausführen folgender Schritte:
Verzögern der Ausnahme durch Speichern von Informatio nen, die identifizieren, daß eine Ausnahme aufgetreten ist (70);
Ausführen einer nicht-spekulativen Operation, die eine Überprüfungsoperation einschließt, um auf eine verzö gerte Ausnahme zu überprüfen;
Überprüfen auf eine verzögerte Ausnahme durch das Lesen eines Bestimmungsregisters einer spekulativen Opera tion; und
wenn eine Ausnahme in einer nicht-spekulativen Opera tion erfaßt ist, Berichten der Ausnahme.
15. Verfahren gemäß Anspruch 14, bei dem die vorbestimmte
Anzahl spekulativer Operationen als nicht-spekulative
Operationen arbeiten kann, abhängig von einem Modus der
Zentralverarbeitungseinheit; und das ferner folgende
Schritte aufweist:
Spezifizieren des Modus der zentralen Verarbeitungsein heit (22) durch Einstellen eines Modusbits in einem Re gister der zentralen Verarbeitungseinheit (22);
Lesen des Modusbits in dem Register, um den Modus der zentralen Verarbeitungseinheit (22) zu bestimmen; und
wenn das Modusbit anzeigt, daß der vorbestimmte Satz spekulativer Operationen als nicht spekulative Opera tionen betrieben werden soll, Betreiben der spekulati ven Operationen als nicht-spekulative Operationen.
Spezifizieren des Modus der zentralen Verarbeitungsein heit (22) durch Einstellen eines Modusbits in einem Re gister der zentralen Verarbeitungseinheit (22);
Lesen des Modusbits in dem Register, um den Modus der zentralen Verarbeitungseinheit (22) zu bestimmen; und
wenn das Modusbit anzeigt, daß der vorbestimmte Satz spekulativer Operationen als nicht spekulative Opera tionen betrieben werden soll, Betreiben der spekulati ven Operationen als nicht-spekulative Operationen.
16. Verfahren gemäß Anspruch 14, bei dem der Schritt des
Bereitstellens das Bereitstellen einer spekulativen und
einer nicht-spekulativen Version eines Satzes von Ope
rationen in einer Befehlssatzarchitektur einschließt,
indem Operationscodes der Operationen in dem Satz spe
zifisch codiert werden, um zu identifizieren, ob eine
Operation spekulativ oder nicht-spekulativ ist.
17. System zum Unterstützen einer spekulativen Ausführung
in einer zentralen Verarbeitungseinheit (22), mit fol
genden Merkmalen:
einer Registerdatei (36), die Universalregister (32) einschließt;
einer Funktionseinheit (30) in Kommunikation mit der Registerdatei (36) zum Ausführen von Operationen, wobei die Funktionseinheit (30) einen Schaltungsaufbau zum Erkennen spekulativer und nicht-spekulativer Operatio nen aufweist, wobei die Funktionseinheit (30) in Kom munikation mit der Registerdatei (36) ist, um Informa tionen zu speichern, die anzeigen, daß eine Ausnahme verzögert wurde, wenn eine spekulative Operation die Ausnahme erzeugt, und zum Überprüfen auf verzögerte Ausnahmen.
einer Registerdatei (36), die Universalregister (32) einschließt;
einer Funktionseinheit (30) in Kommunikation mit der Registerdatei (36) zum Ausführen von Operationen, wobei die Funktionseinheit (30) einen Schaltungsaufbau zum Erkennen spekulativer und nicht-spekulativer Operatio nen aufweist, wobei die Funktionseinheit (30) in Kom munikation mit der Registerdatei (36) ist, um Informa tionen zu speichern, die anzeigen, daß eine Ausnahme verzögert wurde, wenn eine spekulative Operation die Ausnahme erzeugt, und zum Überprüfen auf verzögerte Ausnahmen.
18. System gemäß Anspruch 17, bei dem der Schaltungsaufbau
zum Erkennen spekulativer und nicht-spekulativer Ope
rationen einen Schaltungsaufbau zum Lesen eines Opera
tionscodes einer Operation aufweist, um zu bestimmen,
ob der Operationscode eine spekulative oder eine
nicht-spekulative Version der Operation ist.
19. System gemäß Anspruch 17, bei dem der Schaltungsaufbau
zum Erkennen spekulativer und nicht-spekulativer Opera
tionen ein Register zum Speichern eines Modusbits auf
weist, das einen Modus der zentralen Verarbeitungsein
heit (22) identifiziert, und ferner einen Schaltungs
aufbau zum Lesen des Modusbits aufweist, um zu bestim
men, ob eine Operation als eine spekulative oder eine
nicht-spekulative Operation behandelt werden soll.
20. System gemäß einem der Ansprüche 17 bis 19, bei dem die
Funktionseinheit einen Schaltungsaufbau zum Signalisie
ren einer verzögerten Ausnahme aufweist.
21. System gemäß einem der Ansprüche 17 bis 20, bei dem die
Register in der Registerdatei ein Fehler-Kennungsbit
(38) zum Anzeigen, ob eine Ausnahme verzögert wurde,
aufweisen.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/324,940 US5692169A (en) | 1990-12-14 | 1994-10-18 | Method and system for deferring exceptions generated during speculative execution |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19534752A1 true DE19534752A1 (de) | 1996-04-25 |
Family
ID=23265788
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19534752A Withdrawn DE19534752A1 (de) | 1994-10-18 | 1995-09-19 | Verfahren und System zum Liefern einer Unterstützung für eine spekulative Ausführung |
Country Status (4)
Country | Link |
---|---|
US (1) | US5692169A (de) |
JP (1) | JPH08123685A (de) |
DE (1) | DE19534752A1 (de) |
GB (1) | GB2294341A (de) |
Families Citing this family (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5778219A (en) * | 1990-12-14 | 1998-07-07 | Hewlett-Packard Company | Method and system for propagating exception status in data registers and for detecting exceptions from speculative operations with non-speculative operations |
DE69430018T2 (de) | 1993-11-05 | 2002-11-21 | Intergraph Corp | Befehlscachespeicher mit assoziativem Kreuzschienenschalter |
US5740391A (en) * | 1996-03-01 | 1998-04-14 | Hewlett-Packard Co. | Preventing premature early exception signaling with special instruction encoding |
US5748936A (en) * | 1996-05-30 | 1998-05-05 | Hewlett-Packard Company | Method and system for supporting speculative execution using a speculative look-aside table |
US5854928A (en) * | 1996-10-10 | 1998-12-29 | Hewlett-Packard Company | Use of run-time code generation to create speculation recovery code in a computer system |
US5850553A (en) * | 1996-11-12 | 1998-12-15 | Hewlett-Packard Company | Reducing the number of executed branch instructions in a code sequence |
GB2361082B (en) * | 1996-11-13 | 2002-01-30 | Intel Corp | Processor |
US6631454B1 (en) | 1996-11-13 | 2003-10-07 | Intel Corporation | Processor and data cache with data storage unit and tag hit/miss logic operated at a first and second clock frequencies |
US5881280A (en) * | 1997-07-25 | 1999-03-09 | Hewlett-Packard Company | Method and system for selecting instructions for re-execution for in-line exception recovery in a speculative execution processor |
US5915117A (en) * | 1997-10-13 | 1999-06-22 | Institute For The Development Of Emerging Architectures, L.L.C. | Computer architecture for the deferral of exceptions on speculative instructions |
EP1031076A1 (de) * | 1997-10-13 | 2000-08-30 | Institute for the Development of Emerging Architectures, L.L.C. | Verfahren und vorrichtung zur optimierung der ausführung von lade-/speicherbefehlen |
US6205491B1 (en) * | 1997-12-18 | 2001-03-20 | Sun Microsystems, Inc. | Method and apparatus for deferred throwing of exceptions in C++ |
US6076154A (en) * | 1998-01-16 | 2000-06-13 | U.S. Philips Corporation | VLIW processor has different functional units operating on commands of different widths |
JP3663881B2 (ja) * | 1998-02-09 | 2005-06-22 | 富士ゼロックス株式会社 | 機器情報管理装置 |
US6216222B1 (en) * | 1998-05-14 | 2001-04-10 | Arm Limited | Handling exceptions in a pipelined data processing apparatus |
US6151706A (en) * | 1998-06-16 | 2000-11-21 | Silicon Graphics, Inc. | Method, system, and computer program product for extending sparse partial redundancy elimination to support speculative code motion within an optimizing compiler |
US6260190B1 (en) * | 1998-08-11 | 2001-07-10 | Hewlett-Packard Company | Unified compiler framework for control and data speculation with recovery code |
US6301705B1 (en) * | 1998-10-01 | 2001-10-09 | Institute For The Development Of Emerging Architectures, L.L.C. | System and method for deferring exceptions generated during speculative execution |
JP2000122875A (ja) * | 1998-10-19 | 2000-04-28 | Internatl Business Mach Corp <Ibm> | 例外処理方法およびシステム |
US6519694B2 (en) | 1999-02-04 | 2003-02-11 | Sun Microsystems, Inc. | System for handling load errors having symbolic entity generator to generate symbolic entity and ALU to propagate the symbolic entity |
US6463579B1 (en) * | 1999-02-17 | 2002-10-08 | Intel Corporation | System and method for generating recovery code |
US6453463B1 (en) | 1999-06-07 | 2002-09-17 | Sun Microsystems, Inc. | Method and apparatus for providing finer marking granularity for fields within objects |
US6640315B1 (en) | 1999-06-26 | 2003-10-28 | Board Of Trustees Of The University Of Illinois | Method and apparatus for enhancing instruction level parallelism |
US7761857B1 (en) | 1999-10-13 | 2010-07-20 | Robert Bedichek | Method for switching between interpretation and dynamic translation in a processor system based upon code sequence execution counts |
US6658555B1 (en) * | 1999-11-04 | 2003-12-02 | International Business Machines Corporation | Determining successful completion of an instruction by comparing the number of pending instruction cycles with a number based on the number of stages in the pipeline |
US20020100031A1 (en) * | 2000-01-14 | 2002-07-25 | Miguel Miranda | System and method for optimizing source code |
US6732363B1 (en) * | 2000-02-28 | 2004-05-04 | Sun Microsystems, Inc. | Supporting inter-process communication through a conditional trap instruction |
US6594821B1 (en) | 2000-03-30 | 2003-07-15 | Transmeta Corporation | Translation consistency checking for modified target instructions by comparing to original copy |
US6615300B1 (en) | 2000-06-19 | 2003-09-02 | Transmeta Corporation | Fast look-up of indirect branch destination in a dynamic translation system |
US6895527B1 (en) * | 2000-09-30 | 2005-05-17 | Intel Corporation | Error recovery for speculative memory accesses |
WO2002101548A1 (en) * | 2001-06-08 | 2002-12-19 | Equator Technologies, Inc. | System for compiling a computer program |
US7584425B2 (en) * | 2001-07-31 | 2009-09-01 | Verizon Business Global Llc | Systems and methods for generating reports |
US6931515B2 (en) * | 2002-07-29 | 2005-08-16 | Hewlett-Packard Development Company, L.P. | Method and system for using dynamic, deferred operation information to control eager deferral of control-speculative loads |
US7051238B2 (en) * | 2002-07-30 | 2006-05-23 | Hewlett-Packard Development Company, L.P. | Method and system for using machine-architecture support to distinguish function and routine return values |
US20040024992A1 (en) * | 2002-08-02 | 2004-02-05 | Shan-Chyun Ku | Decoding method for a multi-length-mode instruction set |
US7000091B2 (en) * | 2002-08-08 | 2006-02-14 | Hewlett-Packard Development Company, L.P. | System and method for independent branching in systems with plural processing elements |
US7310723B1 (en) * | 2003-04-02 | 2007-12-18 | Transmeta Corporation | Methods and systems employing a flag for deferring exception handling to a commit or rollback point |
US20060224869A1 (en) * | 2005-03-31 | 2006-10-05 | Flachs Brian K | Combination of forwarding/bypass network with history file |
US8413162B1 (en) | 2005-06-28 | 2013-04-02 | Guillermo J. Rozas | Multi-threading based on rollback |
US7996662B2 (en) * | 2005-11-17 | 2011-08-09 | Apple Inc. | Floating point status/control register encodings for speculative register field |
US7721076B2 (en) * | 2006-12-18 | 2010-05-18 | Intel Corporation | Tracking an oldest processor event using information stored in a register and queue entry |
US8566780B2 (en) * | 2007-06-26 | 2013-10-22 | Microsoft Corporation | Object model based mapping |
US7747899B2 (en) * | 2007-06-26 | 2010-06-29 | Microsoft Corporation | Providing mapping fault processing |
WO2012107800A1 (en) * | 2011-02-11 | 2012-08-16 | Freescale Semiconductor, Inc. | Integrated circuit devices and methods for scheduling and executing a restricted load operation |
JP6726136B2 (ja) * | 2017-06-22 | 2020-07-22 | ルネサスエレクトロニクス株式会社 | データアクセス装置及びアクセスエラーの通知方法 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS5299034A (en) * | 1976-02-17 | 1977-08-19 | Nippon Telegr & Teleph Corp <Ntt> | Control system for micro program |
US4287562A (en) * | 1979-09-06 | 1981-09-01 | Honeywell Information Systems Inc. | Real time adapter unit for use in a data processing system |
US4539635A (en) * | 1980-02-11 | 1985-09-03 | At&T Bell Laboratories | Pipelined digital processor arranged for conditional operation |
JPS5748139A (en) * | 1980-09-04 | 1982-03-19 | Nec Corp | Microprogram control device |
US4396906A (en) * | 1980-10-31 | 1983-08-02 | Sri International | Method and apparatus for digital Huffman encoding |
US5021945A (en) * | 1985-10-31 | 1991-06-04 | Mcc Development, Ltd. | Parallel processor system for processing natural concurrencies and method therefor |
US4881194A (en) * | 1987-11-16 | 1989-11-14 | Intel Corporation | Stored-program controller for equalizing conditional branch delays |
GB8828817D0 (en) * | 1988-12-09 | 1989-01-18 | Int Computers Ltd | Data processing apparatus |
US5487156A (en) * | 1989-12-15 | 1996-01-23 | Popescu; Valeri | Processor architecture having independently fetching issuing and updating operations of instructions which are sequentially assigned and stored in order fetched |
GB2284493B (en) * | 1993-12-01 | 1998-04-01 | Intel Corp | Exception handling in a processor that performs speculative out-of-order instruction execution |
US5546599A (en) * | 1994-03-31 | 1996-08-13 | International Business Machines Corporation | Processing system and method of operation for processing dispatched instructions with detected exceptions |
-
1994
- 1994-10-18 US US08/324,940 patent/US5692169A/en not_active Expired - Lifetime
-
1995
- 1995-09-08 JP JP7230907A patent/JPH08123685A/ja active Pending
- 1995-09-19 DE DE19534752A patent/DE19534752A1/de not_active Withdrawn
- 1995-10-09 GB GB9520626A patent/GB2294341A/en not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
MAHLKE, Scott A. u.a.: Sentinel Scheduling for VLIW and Superscalar Processors. In: ASPLOS V - Oct. 1992/MA, USA 1992, ACM 0-89791-535-6/92/0010/0238, S. 238-247 * |
Also Published As
Publication number | Publication date |
---|---|
JPH08123685A (ja) | 1996-05-17 |
US5692169A (en) | 1997-11-25 |
GB2294341A (en) | 1996-04-24 |
GB9520626D0 (en) | 1995-12-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19534752A1 (de) | Verfahren und System zum Liefern einer Unterstützung für eine spekulative Ausführung | |
DE19506435C2 (de) | Verfahren und Einrichtung zum Vermeiden von Rückschreibkonflikten zwischen einen gemeinsamen Rückschreibpfad verwendenden Ausführungseinheiten | |
DE60115976T2 (de) | Rechnersystem und Interruptvorgang | |
Knoop et al. | Partial dead code elimination | |
DE112011101364B4 (de) | Fehlerbehebung in Multithread-Code | |
EP0689694B1 (de) | Verfahren zur maschinellen erzeugung von nebenläufig bearbeitbaren befehlsgruppen aus einem programm für superskalare mikroprozessoren | |
Aiken et al. | Perfect pipelining: A new loop parallelization technique | |
DE4222776C2 (de) | Parallelverarbeitungseinheit und Verfahren zum Ausführen von Befehlen | |
DE4206062C2 (de) | Pipelineverarbeitung von Instruktionen | |
DE60306937T2 (de) | Synchronisierung von pipelines in einem datenverarbeitungsgerät | |
DE69722138T2 (de) | Code-Optimierer für Pipeline-Rechner | |
DE69933088T2 (de) | Vliw-verarbeiter verarbeitet befehle von verschiedenen breiten | |
DE69534148T2 (de) | Rechnersystem zur Ausführung von Verzweigungsbefehlen | |
DE19983476B4 (de) | Verfahren und Schaltungsanordnung zur Einplanung von Operationen unter Verwendung einer Abhängigkeitsmatrix | |
DE69636861T2 (de) | Mikroprozessor mit Lade-/Speicheroperation zu/von mehreren Registern | |
DE60005860T2 (de) | Ablaufsteuerung zum ausgeben und wiederausgeben von ketten abhängiger befehle | |
DE69831344T2 (de) | Effiziente verarbeitung von gebündelten sprungbefehlen | |
DE112010004322T5 (de) | Vorhersagen und Vermeiden von Operand-Speichervorgang-Vergleich-Gefahren in Mikroprozessoren mit abweichender Reihenfolge | |
DE4409586C2 (de) | Verfahren und Verarbeitungssystem zum Vereinfachen von Verknüpfungshardware | |
DE102004013676A1 (de) | Schleifenbetrieb mit null Overhead in einem Mikroprozessor mit Anweisungspuffer | |
DE102014003799A1 (de) | Systeme und Verfahren zur Übertragungseliminierung mit Bypass-Mehrfachinstanziierungstabelle | |
DE4434895A1 (de) | Verfahren und Vorrichtung zur Erholung von Ablaufunterbrechungen in einem Computersystem | |
DE602004010265T2 (de) | Load-store-einheit mit wiederholungsmechanismus | |
EP0825540B1 (de) | Prozessor mit Pipelining-Aufbau | |
DE69837138T2 (de) | Unterbrechbare mehrfache Ausfuehrungseinheitverarbeitung waehrend mehrfacher Zuweisung von Register verwendenden Operationen |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8130 | Withdrawal |