DE19534752A1 - Verfahren und System zum Liefern einer Unterstützung für eine spekulative Ausführung - Google Patents

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.

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.

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.

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.

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.

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.