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