(57)【要約】【課題】アウトオブオーダー・プロセッサにおいて発生する例外のイベントを、精密に報告し、処理すること【解決手段】プロセッサにおける例外を処理する方法は、例外を検出したときに状態を設定するステップと、状態が設定された場合に、例外のためのトラップを合図するステップと、トラップを合図する前に、例外のクラスに基づいて、異なるように例外を処理するステップとを有する。方法は、例外のためのトラップを合図する前に、例外のクラスに基づいて、例外を発生する命令をリプレイするステップを含んでもよい。方法は、例外を発生する命令が、最古で、リタイアしていない命令となった後に、例外を発生する命令をリプレイするステップを含んでもよい。方法は、例外を発生する命令が、最古で、リタイアしていない命令となった後に、例外のためのトラップを合図するステップを含んでもよい。方法は、例外を発生する命令を発行することなく、完了した、例外を発生する命令であるとしてマーキングするステップを含んでもよい。プロセッサにおいて例外を処理するための装置は、例外を検出したときに状態を設定するため及び状態が設定された場合に例外のためのトラップを合図するための命令スケジューラを含む。命令スケジューラは、トラップを合図する前に、例外のクラスに基づいて、異なるように例外を処理する。【選択図】図３
2004501471.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサにおける例外を処理する方法であって、
例外を検出したときに状態を設定するステップと、
前記状態が設定された場合に、前記例外のためのトラップを合図するステップと、
前記トラップを合図する前に、前記例外のクラスに基づいて、それぞれ異なるように前記例外を処理するステップと
を備えた方法。
【請求項２】
前記例外のための前記トラップを合図する前に、前記例外の前記クラスに基づいて、前記例外を発生する命令をリプレイするステップを更に備えた請求項１に記載の方法。
【請求項３】
前記例外を発生する前記命令が、最古で、リタイアしていない命令となった後に、前記例外を発生する前記命令をリプレイするステップを更に備えた請求項２に記載の方法。
【請求項４】
前記例外を発生する命令が、最古で、リタイアしていない命令となった後に、前記例外のための前記トラップを合図するステップを更に備えた請求項１に記載の方法。
【請求項５】
前記例外を発生する前記命令を発行することなく、完了した、例外を発生する命令であるとしてマーキングするステップを更に備えた請求項１に記載の方法。
【請求項６】
プロセッサにおいて例外を処理するための装置であって、
例外を検出したときに状態を設定するため、及び状態が設定された場合に前記例外のためのトラップを合図するための命令スケジューラを備え、
前記命令スケジューラは、前記トラップを合図する前に、前記例外のクラスに基づいて、それぞれ異なるように前記例外を処理する装置。
【請求項７】
前記命令スケジューラは、更に、前記例外の前記クラスに基づいて前記例外のための前記トラップを合図する前に、前記例外を発生する命令をリプレイするためのものである請求項６に記載の装置。
【請求項８】
前記命令スケジューラは、更に、前記例外を発生する前記命令が、最古で、リタイアしていない命令となった後に、前記例外を発生する前記命令をリプレイするためのものである請求項７に記載の装置。
【請求項９】
前記命令スケジューラは、更に、前記例外を発生する命令が、最古で、リタイアしていない命令となった後に、前記例外のための前記トラップを合図するためのものである請求項６に記載の装置。
【請求項１０】
前記命令スケジューラは、前記例外を発生する前記命令を発行することなく、完了した前記例外を発生する命令であるとしてマーキングするためのものである請求項６に記載の装置。
【請求項１１】
プロセッサにおいて例外を処理するための装置であって、
例外を検出したときに状態を設定する手段と、
前記状態が設定された場合に、前記例外のためのトラップを合図する手段と、
前記トラップを合図する前に、前記例外のクラスに基づいて、それぞれ異なるように前記例外を処理する手段と
を備えた装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、投機的な実行を用いたアウトオブオーダー・プロセッサにおける精密な例外を配達する機構に関する。特に本発明は、アウトオブオーダー・プロセッサにおいて発生する例外のイベントが、精密に報告され、処理されることができる、投機的な実行を用いたアウトオブオーダー・プロセッサにおける精密な例外を配達する機構に関する。
【０００２】
【従来の技術】
コンピュータプロセッサは、コンピュータプログラムからの命令を翻訳して実行する演算、論理、及び制御回路を含む。プロセッサの性能を向上するために、設計者は、演算を速くすることと、更に多くの演算を並列に処理するという２つの主なゴールを捜し求めてきた。演算を速くすることは、様様な方法で取り組むことができる。例えば、半導体プロセスの向上により、トランジスタのスイッチ速度を速くすることにより、信号の伝達速度を速くしてもよい。実行ユニットの待ち時間は、設計においてトランジスタの数を増やすことにより減少することができる。速度を速めるために、与えられた機能の実施するために設計上必要とされる論理のレベルを最小にすることができる。更に多くの演算を並列に実行するためには、設計者は、主にパイプライン及びスーパースカラ技術の一つ、又は組み合わせに依存する。パイプラインされたプロセッサは、共通の実行資源における時間の中で命令をオーバーラップさせる。スーパースカラ・プロセッサは、別々の資源における空間の中で、命令をオーバーラップさせる。
【０００３】
パイプライン失速は、並列処理に関して主な性能阻害因子である。失速は、データ依存の状態、プログラムのフローの変化、及びハードウェア資源の衝突から生じる。たまに、パイプライン失速は、命令の組について実行の順序を再配置することにより避けることができる。静的に命令をリスケジュールするためにコンパイラーを、使用することができる。しかしながら、実行時情報の不完全な知識は、静的リスケジュールの効果を減少する。インオーダー・プロセッサ、すなわち厳密なプログラムの順序で命令を発行し、実行し、完了し、リタイアするプロセッサは、静的リスケジュールに完全に依存しなければならないので、パイプライン失速になりやすい。
【０００４】
【発明が解決しようとする課題】
その結果、設計者は、アウトオブオーダー・プロセッサを使用して動的命令リスケジュールを実施することを求めるようになった。最も単純なアウトオブオーダー・プロセッサは、順番に命令を発行するが、狂った順に命令が実行及び完了されることを許容する。対応する命令がリタイアする前に結果をリオーダーするために、これらの単純なアウトオブオーダー・プロセッサでさえも複雑なハードウェアを必要とする。厳密な結果の順序は、データフローの観点から必要とされない。しかし、このような整理は、精密な例外を維持し、誤って予測された投機的な実行から回復するために必要である。
【０００５】
よく知られたリオーダーの方法は、リオーダーバッファ、すなわちプログラムの順序でレジスター・ファイルに書き込まれるまで結果を維持するバッファ、の使用によるものである。設計者は、履歴バッファ及び未来ファイルなどの、他のタイプのリオーダーハードウェアをも使用する。歴史バッファは、原始オペランド履歴を記録する。そのため、プロセッサは、精密なアーキテクチャ状態、及びプロセッサが精密なチェックポイント状態にレストアされることを許容する、別々のレジスタ・ファイルに現在の状態及びアーキテクチャ状態を格納する未来ファイルにバックトラックすることができる。
【０００６】
分岐予測及び投機的な実行は、パイプライン失速を減少するために用いられる追加的な技術である。パイプランされたプロセッサにおいて、条件付の分岐の結果は、しばしば続きの命令をフェッチした後に決定される。従って、解決されていない分岐の正確な方向を予測することができれば、使用される可能性が高い、十分な命令を、命令キューに保持することができる。いくつかのプロセッサでは、命令は、解決されていない条件付の分岐を越えて、投機的に実際に実行される。分岐が予測された方向に進行しているときに、この技術は、パイプライン失速を完全に回避する。一方、分岐方向が誤って予測された場合は、パイプラインは、フラッシュされ、命令のフェッチは方向を変えられ、パイプラインは再び満たさなければならない。
【０００７】
例外の命令、すなわち与えられた命令のために正規の処理を一時停止するイベント、を効果的に処理し、取り扱うことも重要である。例外の命令に遭遇したときに、制御のフローは、一時的にトラップハンドラーを通して転換される。トラップハンドラーは、例外の原因を調査し、例外を放出する必要のある全てのプロセスを完了するルーチンである。一般的にプロセッサは、トラップハンドラーにより必要とされる、ある情報を格納する。この情報は、実行されているプログラムの現在の状態、例外のソースの識別情報などを含む。
【０００８】
例外の命令は、比較的まれである。しかしながら、もし遭遇した場合、命令が実行される前のままの、プロセッサの状態を精密に保存しておくことは、極めて有用である。このような精密な例外は、トラップハンドラーによる例外の診断を容易にすることを許容する。しかしながら、例外と遭遇しない状態で、共有のケースの速度をおとさずに精密な例外を達成することは困難な作業である。これは、命令が非常に若い場合に、すなわち他の与えられた命令よりも最近にフェッチされた場合に、例外を生成する命令が発行されて実行される、アウトオブオーダー・プロセッサにおいて特に真実である。
【０００９】
図１を参照して、典型的なコンピュータシステムは、他の物の中で、ＣＰＵ１２、ロード／ストア部１４、ボード上のキャッシュメモリ１６を有するマイクロプロセッサ１０を含む。マイクロプロセッサ１０は、両方ともマイクロプロセッサ１０により実行されるべきデータ及びプログラム命令を保持する外部のキャッシュメモリ１７及びメインメモリ１８に接続される。内部的には、プログラム命令の実行は、ＣＰＵ１２により実行される。命令を実行するためにＣＰＵ１２が必要とするデータは、ロード／ストア部１４によりフェッチされ、ＣＰＵ１２の内部レジスタ１５にロードされる。メモリキュー（不図示）は、未解決のメモリー要求のリストを維持する。ロード／ストア部は、メモリキューに要求を追加し、更にメモリキューからの値をレジスタにロードする。ＣＰＵ１２からの命令にともなって、ロード／ストア部１４は、最初に速いボード上のキャッシュメモリ１６で、次に外部のキャッシュメモリ１７で、最後に遅いメインメモリ１８でデータを探す。キャッシュメモリ内のデータを見つけることは、「ヒット」と呼ばれる。キャッシュメモリ内のデータを見つけることができないことは、「ミス」と呼ばれる。
【００１０】
【課題を解決するための手段】
一つの態様では、プロセッサにおける例外を処理する方法は、例外を検出したときに状態を設定するステップと、状態が設定された場合に、例外のためのトラップを合図するステップと、トラップを合図する前に、例外のクラスに基づいて異なるように例外を処理するステップとを備える。
【００１１】
方法は、例外のためのトラップを合図する前に、例外のクラスに基づいて、例外を発生する命令をリプレイするステップを備えてもよい。方法は、例外を発生する命令が、最古で、リタイアしていない命令となった後に、例外を発生する命令をリプレイするステップを備えてもよい。方法は、例外を発生する命令が、最古で、リタイアしていない命令となった後に、例外のためのトラップを合図するステップを備えてもよい。方法は、例外を発生する命令をすることなく、完了した、例外を発生する命令であるとしてマーキングするステップを備えてもよい。
【００１２】
一つの態様では、プロセッサにおいて例外を処理するための装置は、例外を検出したときに状態を設定するため及び状態が設定された場合に例外のためのトラップを合図するための命令スケジューラを備える。命令スケジューラは、トラップを合図する前に、例外のクラスに基づいて、異なるように例外を処理する。
【００１３】
命令スケジューラは、例外のためのトラップを合図する前に、例外のクラスに基づいて例外を発生する命令をリプレイしてもよい。命令スケジューラは、例外を発生する命令が、最古で、リタイアしていない命令となった後に、例外を発生する命令をリプレイしてもよい。命令スケジューラは、更に、例外を発生する命令が、最古で、リタイアしていない命令となった後に、例外のためのトラップを合図してもよい。命令スケジューラは、例外を発生する命令を発行することなく、完了した、例外を発生する命令であるとしてマーキングしてもよい。
【００１４】
一つの態様では、プロセッサにおいて例外を処理するための装置は、例外を検出したときに状態を設定する手段と、状態が設定された場合に、例外のためのトラップを合図する手段と、トラップを合図する前に、例外のクラスに基づいて、異なるように例外を処理する手段とを備える。
【００１５】
他の態様及び発明の長所は、下記及び添付の請求項から明らかである。
【００１６】
【発明の実施の形態】
様様な発明の形態を、付随する図面を参照して説明する。図２を参照して、一般的に、一つ又は更に多くの実施形態では、発明は、フェッチ部１１及び命令スケジューラ１３を有するプロセッサの設計において具体化されることができる。命令スケジューラ１３は、発行部１５及びリタイアロジック１７を含む。発行部１５は、発行命令及び前発行処理を処理する。一方、リタイアロジック１７は、命令の後発行処理を処理する。後で更に詳細に説明するように、フロントエンド例外は、例外を発生する命令の発行の前、及び例外を発生する命令の防止の即座に発生する。一方、バックエンド例外は、例外を発生する命令が発行された後で処理される。
【００１７】
フェッチ部１１は、命令をフェッチし、フェッチされた命令１９を、命令スケジューラ１３に渡す。命令スケジューラ１３の発行部１５は、次にフェッチされた命令１９を、発行された命令２１として発行する。発行された命令は、実行部２３に送られ、次に、リタイアするためにリタイアロジック１７に戻る。命令と関連する例外がいつ発生するかに従って、例外の処理は、異なる一連のステップを通して進行する。例外がフロントエンド例外である場合、フェッチ部は、例外を検出して、適切なビットをマークする。例外がバックエンド例外である場合、実行部は、例外を検出して、適切なビットをマークする。例外の処理するためにとられる手段及びマークされたビットを、図３を参照して以下に説明する。いかなる場合であっても、命令スケジューラ１３は、検出された命令をフェッチ部１１に伝達し、それが次にトラップハンドラー（不図示）を呼ぶ。トラップハンドラーは、例外を解決するためのソフトウェアツールである。トラップハンドラーを呼ぶためにフェッチ部１１に例外の発生を伝達する場合、これを、トラップを合図すると呼ぶ。当業者は、複数の命令が連続してフェッチされ、プロセッサの設計に基づいて他のユニットにより記載された機能が実行されることを認識する。
【００１８】
図３を参照して、一つの実施形態によるアウトオブオーダー・プロセッサにおける精密な例外の報告を可能にするプロセスを示す。第１に、例外を受理したときに（ステップ２０）、例外は、クラスが割り当てられる（ステップ２２）。示された例では、各例外は、２つの可能なクラスのうちの一つが割り当てられる。例外は、例外のタイプに基づいてフロントエンド例外又はバックエンド例外のいずれかである。当業者が多くの変形が可能であることを認識するとして、例としてのプロセスは、クラスの一つを検出するステップ（例えばフロントエンド例外）及び他にデフォルトするステップ（バックエンド例外）を含む。フロントエンド例外は、発行キュー又は複数のキュー中に命令が挿入される前に検出される。これらの例外は、典型的に非常に高い優先順位であり、従って、その命令のために全ての他の可能な例外に先行して取られる。一方、バックエンド例外は、命令が実行部に発行された後で発生する。本質的に、フロントエンド例外は、命令の発行前に発生するものであり、命令の発行を防止する即座に生じるものである。一方、バックエンド例外は、命令の発行後に生じるものである。
【００１９】
従って、プロセスは、例外がフロントエンド例外であるか否かを決定することにより継続する（ステップ２４）。そうであれば、精密な方法でフロントエンド例外が報告されることを保証するために、命令発行ロジックが命令を発行しないようなやり方で、命令はマークされる。これは、間違っていることが既に知られている命令が、発行、実行、又はリタイアにより他のいかなる状態にも壊れないことを保証する。このような命令が、命令キューに入るとき、命令は、例外を有するが、完了したとしてマークされる（ステップ２６）。例外を有さず、完了したとマークされた命令が、ついにはリタイアする。例外を有し、完了したとマークされた命令が、一旦最古で、リタイアしていない命令（ステップ２８）になると、例外が報告され（ステップ３０）、プロセッサの状態は、全ての古い命令の実行のみを反映する。
【００２０】
バックエンド例外を発生する命令は、アウトオブオーダーに発行され完了されるので、バックエンド例外は、更に複雑である。従って、バックエンド例外に遭遇した場合、例外リプレイ・ビット、例えば命令キュー中の命令のエントリー中のビット、がバックエンド例外を生成する命令のために設定される（ステップ３２）。プロセッサ内で、命令が最古でリタイアしていない命令となるまで、他のいかなるアクションも取られない（ステップ３４）。一旦、命令が最古でリタイアしていない命令であると、命令は再発行又はリプレイされる（ステップ３６）。もし、リプレイ時に、例外が生成されない場合（ステップ３７）、プロセスは終了し、命令は正常にリタイアすることを許される。一方、リプレイ中に例外が生成された場合、命令が完了したときに例外情報は、記録される（ステップ３８）。例外を生成する命令をリプレイすることは、使用されるトラップ情報を記録するための単一のレジスタを許容することを、当業者は認識する。さもなければ、命令毎に一つのレジスタが必要となる可能性がある。また、例外のリプレイは、不正確な投機的処理、データキャッシュミス等により、命令リタイアロジックの外部で維持されるエラーレジスタが、壊れないことを保証する。最後に、命令フェッチロジックにトラップが通知され、全ての命令がトラップハンドラーをフェッチする前に、フラッシュされる（ステップ４０）。
【００２１】
もし、何らかの理由で、命令を２回実行することができなかった場合、実行部は、これを検出して、例外ビットを伴う「例外をリプレイしないこと」のビットを設定する。リタイアロジックは、「例外をリプレイしないこと」のビットが設定されているときに、単純に命令をリプレイしない。これは、Ｉ／Ｏスペースへのロード／ストア操作などの副作用を有する命令において必要とされる。更に、もし命令が再発行されたときに、命令が例外に遭遇しなかった場合、命令は正常にリタイアすることを許されることを特筆する。例外ビット及び例外リプレイ・ビットが、同一のビットを用いて実行されること、及び、このような場合、タイミング又は例外検出のソースの違いは、どのアクションを取るべきか命じるために用いられることを、当業者は認識する。
【００２２】
フロントエンド例外が一時停止中である場合、古い命令により生成された、全てのバックエンド例外により、フロントエンド例外が、オーバーライトされる可能性がある。これは、トラップがプログラムの順序で合図される必要があるからである。従って、古い命令からのバックエンド例外に遭遇した場合、バックエンド例外は、どの若いフロントエンド例外よりも前に処理されなければならない。また、２つの例外が互いに関連しない場合、一旦バックエンド例外のためのトラップハンドラーが完了して、若い命令が再フェッチされると、フロントエンド例外は、再び報告される。
【００２３】
命令が発行される度に、プロセッサのリネーム状態が変更されるが、プロセッサのアーキテクチャの状態は変更されないことを特筆することは、重要である。これは、例外が精密な方法で報告されることを許容する。レジスタリネーム以外の機構も適切であるが、トラップハンドラーがフェッチされる前に、プロセッサの正確なアーキテクチャの状態がレストアされることが必要であることを、当業者は認識する。
【００２４】
本発明は、下記の一つ又は更に多くの長所を含む。アウトオブオーダー・プロセッサにおいて発生する例外のイベントが、精密に報告され、処理されることができる。検出及びマーキングの点から見て、フロントエンド例外は、発行されない。更に、バックエンド例外がリプレイされ、単一のフロントエンド例外のみが与えられた時間に処理されるので、単一のトラップレジスタのみが必要である。
【００２５】
本発明は、限られた数の実施形態に関して説明されたが、当業者は、ここに開示された発明の範囲から離れずに、他の実施形態が考案され得ることを認識する。従って、発明の範囲は、添付された請求項のみにより限定されるべきである。
【００２６】
【発明の効果】
上記説明から明らかなように、本発明によればアウトオブオーダー・プロセッサにおいて発生する例外のイベントが、精密に報告され、処理されることができる。
【図面の簡単な説明】
【図１】典型的なコンピュータシステムを示す。
【図２】本発明の実施形態に従ったブロック図である。
【図３】本発明の実施形態に従ったプロセスを示すフローチャートである。
【符号の説明】
１１　フェッチ部、１３　命令スケジューラ、１４　ロード／ストア部、１５　発行部、１７　リタイアロジック、１８　メインメモリ、１９　フェッチされた命令、２１　発行された命令、２３　実行部
【図１】
2004501471.tif 000003
【図２】
2004501471.tif 000004
【図３】
2004501471.tif 000005
【国際公開パンフレット】
2004501471.tif 000006
2004501471.tif 000007
2004501471.tif 000008
2004501471.tif 000009
2004501471.tif 000010
2004501471.tif 000011
2004501471.tif 000012
2004501471.tif 000013
2004501471.tif 000014
2004501471.tif 000015
2004501471.tif 000016
2004501471.tif 000017
2004501471.tif 000018
2004501471.tif 000019
2004501471.tif 000020
【国際調査報告】
2004501471.tif 000021
2004501471.tif 000022