JP6634083B2 - データ処理装置におけるシステムエラー処理 - Google Patents

Description

本開示は、データ処理に関する。より具体的には、本開示は、データ処理装置におけるシステムエラーの処理に関する。

データ処理装置が、実行するデータ処理命令に応答してデータ処理動作を実行している場合、データ処理装置によって試みられた、そのいくつかのデータ処理動作がシステムエラーになり得ることが知られている。このようなシステムエラーは、様々な理由で生じる可能性があるが、一般には、データ処理装置がデータ処理動作を首尾よく完了できなかったことを示している。このようなシステムエラーの発生を処理するために、データ処理装置は例外処理ルーチンを実行するように構成することができることがさらに知られており、これは、システムエラーの発生を信頼性がありかつ一貫した方法で処理するためにプログラマによって提供されたデータ処理命令のセットである。本開示は、データ処理装置がシステムエラーの発生に応答する方法の改良に関する。

第１の態様から見ると、データ処理装置であって、データ処理命令に応答してデータ処理動作を実行し、エラーメモリバリア条件が存在するか否かを判定し、かつ、エラーメモリバリア条件が存在するか否かに依存してエラーメモリバリア手順を実行するための処理回路を備え、処理回路は、データ処理動作が成功しなかったことの検出時に、エラー例外条件を設定することが可能であり、エラーメモリバリア手順は、エラー例外条件が設定されている場合、かつ、エラーマスク条件が設定されている場合、遅延エラー例外条件を設定すること、およびエラー例外条件をクリアすることを含む、データ処理装置が提供される。

第２の態様から見ると、データ処理方法であって、データ処理命令に応答してデータ処理動作を実行するステップと、データ処理動作が成功しなかったことの検出時にエラー例外条件を設定するステップと、エラーメモリバリア条件が存在するか否かを判定するステップと、エラーメモリバリア条件が存在するか否かに依存して、エラーメモリバリア手順を実行するステップと、を含み、エラーメモリバリア手順は、エラー例外条件が設定されている場合、かつ、エラーマスク条件が設定されている場合、遅延エラー例外条件を設定すること、およびエラー例外条件をクリアすることを含む、データ処理方法が提供される。

第３の態様から見ると、データ処理装置であって、データ処理命令に応答してデータ処理動作を実行するための手段と、データ処理動作が成功しなかったことの検出時に、エラー例外条件を設定する手段と、エラーメモリバリア条件が存在するか否かを判定する手段と、エラーメモリバリア条件が存在するか否かに依存して、エラーメモリバリア手順を実行する手段と、を含み、エラーメモリバリア手順は、エラー例外条件が設定されている場合、かつ、エラーマスク条件が設定されている場合、遅延エラー例外条件を設定すること、およびエラー例外条件をクリアすることを含む、データ処理装置が提供される。

本発明は、添付の図面に示された実施形態を参照し、もっぱら例としてさらに説明される。

一実施形態における、データ処理回路の一実施例、および関連するメモリシステムを概略的に示す。 一実施形態における、図１のいくつかの構成要素の構成をより詳細に概略的に示す。 一実施形態における処理回路によって実行され得るデータ処理命令のシーケンス、いくつかの関連するデータ処理動作、およびシステム事象を示す。 一実施形態における処理回路によって実行される例示的な一連のステップを示す。 一実施形態における処理回路により、データ処理命令に応答して実行されるステップのシーケンスを示す。 例示的な一実施形態の仮想化された動作環境を概略的に示す。 仮想化された動作環境で動作する一実施形態において、実行されるステップのシーケンスを示す。 実施形態における複数の例外レジームおよび例外レベル、ならびに例外が行われたときのこれらの例外レベル間のいくつかの遷移例を概略的に示す。 実施形態における複数の例外レジームおよび例外レベル、ならびに例外が行われたときのこれらの例外レベル間のいくつかの遷移例を概略的に示す。 一実施形態において、物理エラーを処理するために使用される、例示的な一連の現在の例外レベルおよび目標例外レベルを、対応するエラー例外条件がどのように処理されるかの定義とともに示す。 仮想エラーを処理するために使用される、例示的な一連の現在の例外レベルおよび目標例外レベルを、対応するエラー例外条件が一実施形態においてどのように処理されるかの定義とともに示す。 仮想化された動作環境で動作する一実施形態における、２つのパラメータの設定に依存して使用される物理目標および仮想目標の表を示す。 一実施形態における、エラーメモリバリア命令を定義する、例示的な一連の擬似コードを示す。 エラーメモリバリア命令を使用するデータ処理命令の例示的なシーケンスを示す。

本技術は、例外処理手順（ルーチン）を実行することによってシステムエラー（非同期アボート）に応答するデータ処理装置において、それが報告されたときに、システムがそのようなエラーの原因を特定することが困難になる可能性があるということを認識している。このことは、これらのエラーの非同期性に関連しており、このシステムエラーを発生させたデータ処理命令が実行されたポイントと、エラーがプロセッサ（処理回路）に折り返し報告されたポイントとの間の相関がほとんどないことを意味する。これは、例えば、特に、メモリアクセスに関連する可能性のあるレイテンシと、それらが様々な方法で失敗する可能性がある場合に、対応するデータ処理命令に応答して処理回路が実行しようとするそのようなメモリアクセスに関する場合である。このようなエラーは、例えば、ロードオペレーション、ストアオペレーション、ページテーブルウォーク、命令フェッチなどによって発生する可能性がある。特に、本技術は、（割り込み要求のような）以前の例外によってトリガーされた例外処理手順を既に実行している間に、（不成功なメモリアクセスに起因するか、または別の原因を有する可能性がある）システムエラーが処理回路に報告されたとき、処理回路は、システムがすぐに処理しなければならないシステムエラーの原因を識別して、例えば適切な修復措置を行えることが有益である、ということを認識している。したがって、エラー例外条件は、装置内の異なるイベントに応答して設定できることに留意されたい。一方では、それは、不成功なメモリアクセス（すなわち、そのメモリアクセスが指示どおりに正しく完了していない場合）に応答して設定され、他方では、（例えば、他のデータ処理動作が実行されている間に）、ランダムイベントまたはアップセットなどのために、装置内の他のタイプのエラー例外条件に応答して設定され得る。

これを行うために、システムエラーの結果、装置内にエラー例外条件が設定され、それに応答して、概して処理回路が例外処理手順を実行するように構成されている場合、本技術は、処理回路がシステムエラーに対する応答に優先順位を付けることを可能にする（例えば、装置に記憶されたエラーマスク値を設定することによって設定することができる）、エラーマスク条件を導入する。特に、処理回路が第１の例外条件に応答して例外処理手順を既に実行している間に、または処理回路が、例外処理手順を実行することによってシステムエラーに応答することができない、予め定義された「重要プログラムコード」を実行している間に、（エラー例外条件の設定によって）システムエラーが処理回路に通知されると、処理回路は、遅延エラー例外条件の設定、およびシステムエラー発生の結果として設定されたエラー例外条件のクリアによって、このシステムエラーに対する応答を遅延することができる。これにより、処理回路は、第１の例外に応答するその例外処理手順または重要プログラムコードを中断することなく継続することができるだけでなく、システムは、システムエラーを発生させた原因（すなわち、データ処理命令または少なくともデータ処理命令のセット）をよりよく区別することができる。特に、システムは、第１の例外に応答した例外処理手順の開始に先行する命令実行に起因するシステムエラー原因と、第１の例外に対する例外処理手順の一部を形成する命令実行とを区別することができる。この機能性は、システムプログラムにより存在する（設定する）ことができるエラーメモリバリア条件によって処理回路内に構成可能である。このエラーメモリバリア条件は、例えば、専用の命令によって、処理回路が例外処理手順の実行を開始するときに存在するように常に定義されることによって、装置の進行中の（例えば、装置内でこの目的のために保持された値によって定義される）「モード」が設定されている場合に処理回路が例外処理手順の実行を開始するときに存在するように定義されることによって、設定できるなど様々な方法がある。この構成は、都合の良いことに、一般には、それらに関連する相当な処理と時間コストを有する、例外処理手順（ルーチン）の開始時に、例えばデータおよび命令同期障壁を利用することを必要とすることなく、そのようなシステムエラーをより効率的に処理することができる装置を提供する。

いくつかの実施形態では、処理回路は、メモリアクセスが成功しなかったという、受信された指示に応答してエラー例外状態を設定する（すなわち、設定するように構成する）ことが可能であるが、これは、処理回路が応答してエラー例外条件を設定するように構成される唯一のタイプのイベントではなく、いくつかの実施形態では、処理回路は、不成功なメモリアクセス以外のイベントに応答してエラー例外条件を設定するように構成される。例えば、処理回路は、不成功なデータ処理動作などに応答してエラー例外条件を設定してもよい。

処理回路は、様々な方法でエラー例外条件に応答してもよく、いくつかの実施形態では、エラー例外条件が設定されており、かつ、エラーマスク条件が設定されていない場合、処理回路が例外処理手順を実行することが可能である。

データ処理動作は様々な形態を採ることが可能であり、いくつかの実施形態では、データ処理動作は、メモリアクセスを含み、処理回路は、メモリアクセスに対するエラー応答を受信することが可能であり、処理回路は、エラー応答が、メモリアクセが成功しなかったことを示す場合に、エラー例外条件を設定することが可能である。

いくつかの実施形態では、処理回路は、データ処理命令内のエラーメモリバリア命令に応答して、エラーメモリバリア条件が存在することを判定することが可能である。エラーメモリバリア命令を提供することは、システムプログラマに、処理回路に対してエラーメモリバリア条件がいつ存在するか（設定される）を決定する柔軟性を提供し、さらに、処理回路がエラーメモリバリア命令に遭遇したときに、エラーメモリバリア条件を設定するだけでなく、他の動作を実行するための構成を有する機会を提供する。

いくつかの実施形態では、処理回路は、例外処理手順の一部として、かつ、遅延エラー例外条件が設定されている場合に、少なくとも１つのデータ処理命令に関して修復応答を開始することが可能であり、少なくとも１つのデータ処理命令は、エラーメモリバリア条件が存在すると判定する前に実行されたデータ処理命令を含む。

処理回路がエラーメモリバリア手順を実行することの一部として遅延エラー例外条件を設定した場合、（例えば、エラーメモリバリア命令の実行によって）エラーメモリバリア条件が存在する処理回路による判定に先立って実行された少なくとも１つのデータ処理命令がエラー応答を引き起こした結果、遅延エラー例外条件が設定されているということと、例えばデータ処理命令の同じシーケンスの後続の再度の実行においてそれが回避されるようにするために、少なくとも１つのデータ処理命令に関して適切な修復応答を得ることができる、ということが推論できる。

いくつかの実施形態では、装置は、さらに、エラーメモリバリアモード値記憶装置をさらに備え、処理回路が例外処理手順の実行を開始するとき、処理回路は、エラーメモリバリアモード値記憶装置に記憶されたエラーメモリバリアモード値に依存して、エラーメモリバリア条件が存在することを判定することが可能である。例えば、エラーメモリバリアモード値記憶装置は、処理回路が、エラーメモリバリア条件が存在するモードで動作している、または例外を行っていないか否かを示す単一のビットを記憶することができる。この値は、処理回路が例外処理手順の実行を開始するときエラーメモリバリア条件が存在すると定義されることに従ってシステムプログラマによって設定されるとおりに、処理回路の進行中のモードを定義することができる。いくつかの実施形態では、エラーメモリバリア条件は、例外処理手順が開始されるたびに存在するように装置内で定義されてもよく、これらの実施形態では、エラーメモリバリア条件が存在すると判定されるために、明示的なアクション（例えば、エラーメモリバリア命令の実行、またはエラーメモリバリアモード値の設定）は不要である。

いくつかの実施形態では、処理回路は、エラーメモリバリア手順を実行するとき、かつ、エラーメモリバリア条件が存在する場合、さらなるデータ処理命令を実行する前にまだ完了していない各メモリアクセスのエラー応答を待つことが可能である。例えば、処理回路に関連するロード／ストアユニットの内容から決定することができる、まだ完了していない各メモリアクセスに対するエラー応答を待つことによって、処理回路は、例えば例外処理手順の途中で以前のエラー例外条件に応答して実行されている間、エラー応答の処理が潜在的に破壊的である可能性がある場合、さらなるデータ処理命令の実行中に、不完全なメモリアクセスが、そのエラー応答を返す可能性を回避することができる。

エラーマスク条件は、様々な方法で設定することができるが、いくつかの実施形態では、装置は、エラーマスク値記憶装置をさらに備え、処理回路は、エラーマスク条件がエラーマスク値記憶装置に記憶されたエラーマスク値に依存して設定されるか否かを判定することが可能である。

いくつかの実施形態では、処理回路は、例外処理手順を開始するときに、エラーマスク値を設定することが可能である。装置およびその処理回路の特定の構成に応じて、例外処理手順を開始するときにエラーマスク条件が常に設定されることが有益な場合があり、その結果、システムエラー（例えば、不成功なメモリアクセス）の発生によりエラー例外条件が設定されることになる場合、処理回路は、エラーメモリバリア手順を実行するときに、後者のシステムエラーに対する応答を遅延することによって応答する。この特定の機能性がどのように実現されるかは、例えば、処理回路が複数のソフトウェア実行特権レベルを有するか否かに依存し、システムエラーの受信表示に応じてそれぞれの例外処理手順の優先順位付けに影響を及ぼし得る。

いくつかの実施形態では、処理回路は、遅延エラー例外条件が設定されていない場合、例外処理手順の一部として、エラーマスク値をクリアすることが可能である。このようにエラーマスク条件をクリアすることにより、エラーマスク値が設定されている間に保留されたエラーまたは後続のエラーに処理回路が直接応答することが可能になる、すなわち、そのようなエラーが直接に例外を発生することができる。

いくつかの実施形態では、処理回路は、遅延エラー例外条件が設定されていない場合、既定の組のデータ処理命令が完了した後に、エラーマスク値を設定し、かつ、エラーマスク値をクリアすることが可能である。この既定のデータ処理命令の設定は、原子的に実行されなければならない、例えば、コードの「重要な」部分であり、したがって、その実行中に、例外処理手順を実行することによってシステムエラーに応答することができない。このようなコードの重要な部分が実行される前に、エラーマスク条件を設定する必要がある。そのようなコードの重要な部分が完了すると、このようにしてエラーマスク条件をクリアすることができ、処理回路は、エラーマスク値が設定されている間に保留されたエラー、または後続のエラーに直接応答することができる、すなわち、そのようなエラーが直接に例外を生成することができる。

いくつかの実施形態では、処理回路は、複数の例外レベルから選択された現在の例外レベルで例外処理手順を実行することが可能であり、複数の例外レベルは、複数のソフトウェア実行特権レベルに対応する。処理回路内に複数のソフトウェア実行特権レベルを設けることにより、本文脈では、複数のソフトウェア実行特権レベルに関連する複数の例外レベルの異なるレベルで例外処理手順の優先順位付けを行うことが可能になり、これは、例えば、それが実行されるべき例外レベルが現在例外レベルよりも高いソフトウェア実行特権レベルに対応する場合、後で例外処理応答（すなわち、手順）を直接行う（すなわち、遅延させない）ことを可能にするために使用することができる。

いくつかの実施形態では、処理回路は、（第１の）例外処理手順が、さらなるエラー例外条件に応答するさらなる例外処理手順が実行されるべきである例外レベル以上である例外レベルで、処理回路によって実行されるべきである場合に、（第１の）例外処理手順を開始するとき、エラーマスク条件を設定することが可能である。したがって、エラーマスク条件の設定を使用して、より高い例外レベル（ソフトウェア実行特権レベル）で実行される（第１の）例外処理手順が、同じ、またはより低い例外レベルで処理されるべき、任意のその後のエラー例外条件（例えば、処理回路へのエラー応答の通知）の設定によって妨げられないようにすることができる。したがって、ある例外レベルでは、どれが保護を必要とするコードの「重要領域」であるかをソフトウェアが判定することができ、この手法を使用してその保護を実現することができる。

いくつかの実施形態では、処理回路は、（第１の）例外処理手順が、さらなるエラー例外条件に応答するさらなる例外処理手順が実行されるべきである例外レベル未満の例外レベルである例外レベルで、処理回路によって実行されるべきである場合に、第１の例外処理手順を開始するとき、エラーマスク条件を設定しないことが可能である。このようにエラーマスク条件を設定しないことにより、処理回路がより低いソフトウェア実行特権レベルで例外処理手順を実行しているとき、例外処理手順は、エラー例外条件の後続の設定に応答して直接実行される（つまり、例外が生成される）ということを確実にすることができる。

いくつかの実施形態では、装置は、少なくとも１つの仮想マシンが動作する仮想化された動作環境を提供することが可能であり、仮想マシンが、処理回路との相互作用により、データ処理命令に応答してデータ処理動作を実行することが可能である。したがって、装置によって実行されるデータ処理命令は、仮想マシンハードウェアとの相互作用をモデル化する仮想マシンプログラムと相互に作用することができる。

いくつかの実施形態では、装置は、仮想エラー例外条件を設定することが可能であり、仮想エラー例外条件が設定され、かつ、仮想エラーマスク条件が設定されていない場合、処理回路は例外処理手順を実行することが可能である。仮想エラー例外条件の設定は、様々な方法で行うことができ、いくつかの実施形態では、ハードウェアによって設定され、また、いくつかの実施形態では、装置は、仮想化オペレーティング環境の動作を制御するハイパーバイザを動作させることが可能であり、そして、ハイパーバイザは仮想エラー例外条件を設定することができる。これにより、ハードウェアまたはハイパーバイザは仮想システムエラーをシステムに「注入」することができ、これらの仮想エラーは様々な目的で使用される可能性がある。処理回路が物理エラーに応答するのと同じ方法で例外処理手順を実行することによって、処理回路がそのとき仮想エラーに応答できるという事実は、そのときエラーの性質がゲスト（すなわち仮想ハイパーバイザの制御下で動作するマシン）にとって透過的であるため、有益である。

いくつかの実施形態では、エラーメモリバリア手順は、仮想エラー例外条件が設定されている場合、かつ、仮想エラーマスク条件が設定されている場合、仮想遅延エラー例外条件を設定すること、および仮想エラー例外条件をクリアすることをさらに含む。この構成は、仮想化された動作環境内で本技術にさらなるサポートを提供する。例えば、エラーメモリバリア命令がエラーメモリバリア命令の実行によって設定される場合、例外エントリー毎にコストがかかる、ハイパーバイザにおけるエラーメモリバリア命令のトラップし、かつエミュレートする必要がなくなる。

いくつかの実施形態では、装置は、処理回路が、遅延エラー例外条件が設定されているか否を判定しようとしているとき、遅延エラー例外条件の値の代わりに仮想遅延エラー例外条件の値を提供することが可能である。この値の提供は様々な方法で行うことができ、いくつかの実施形態ではハードウェアによって提供され、また、いくつかの実施形態ではハイパーバイザがこの値を提供する。したがって、ハードウェアまたはハイパーバイザは、このようにして（上記の利点を有する）仮想遅延エラー例外条件の値を維持することができるが、仮想遅延エラー例外条件と、処理回路（すなわち、ゲスト仮想マシン）から完全に隠された遅延エラー例外条件との間のこの（仮想）差異を維持することもできる。

図１には、処理回路４、命令デコーダ６、レジスタ８のバンクおよびメモリシステム１０を備えるデータ処理装置２が概略的に示される。メモリシステム１０は、１つ以上のキャッシュまたはメモリデバイスを備える。処理回路４は、加算器１２、乗算器１４、およびシフタ１６などの多数の処理要素を備える。データを処理するとき、命令デコーダ６はプログラム命令に応答して、処理回路４を制御し、レジスタ８に記憶されたデータを処理し、かつ、処理結果をレジスタ８に返すための制御信号を生成する。命令デコーダ６の制御下で、データ処理装置２は、レジスタ８とメモリシステム１０との間でデータを転送するように制御することもできる（このような転送は、本明細書で言及する「メモリアクセス」の一例である）。

図１の実施例では、処理回路４は、レジスタ８に記憶されたデータを処理し、かつ、データ処理の結果をレジスタ８に戻して記憶するものとして示されているが、他の種類の記憶位置をレジスタ８の代わりに使用してもよいことは明らかである。データ処理装置２、具体的には処理回路４は、一般的に、図１に示されていない他の要素を含んでもよいことは明らかである。

図２には、図１のデータ処理装置２のいくつかの構成要素のさらなる詳細が示される。プロセッサコア２０、ロード／ストアユニット２２、メモリ管理ユニット（ＭＭＵ）２４、およびメモリシステム１０が示されている。図の明瞭化のために図２にはレジスタ８のみが示されているが、プロセッサコア２０は、（図１を参照すると）処理回路４、デコーダ６およびレジスタ８を備える。プロセッサコア２０（そして、具体的には、その内部の処理回路）は、パイプライン化されたロード／ストアユニット２２を使用して、対応するデータ処理命令に応答して発行するメモリアクセス要求を処理する。このようなメモリアクセスに関連するレイテンシのために、ロード／ストアユニット２２はメモリシステムとの相互作用を管理し、後でプロセッサコア２０に応答を提供するが、プロセッサコア２０は、その間に他のデータ処理命令の実行を暫く継続することができる。例えば、図示されるように、プロセッサコア２０は、ロード／ストアユニット２２に、アクセス（例えば、そのメモリ位置からロード）しようとするメモリアドレス（Ａ）を提供することができる。命令は図示のように左から右に移動し、したがってメモリアドレス（Ａ）は１サイクルで消失し、データ（Ｄ）が後に返される（したがって、上述の非同期が生じることになる）。

メモリシステム１０は、図２に示され、Ｌ１キャッシュ（Ｌ１＄）、Ｌ２キャッシュ（Ｌ２＄）およびメインＤＲＡＭメモリを含んでいる。メモリシステム１０は、例えば、プロセッサコア２０によって使用される仮想アドレスと、メモリシステム１０等内で使用される物理アドレスとの間のアドレス変換を提供するために、プロセッサコア２０とメモリシステム１０との間の相互作用の特定の態様を管理する連想ＭＭＵ２４を備えてもよい。ロード／ストアユニット２２によってメモリシステム１０に発行されたメモリアクセスは、ＭＭＵ２４によって受け取ることができ、アクセス要求を首尾よく実行することができないとＭＭＵ２４によって識別された場合には、既にロード／ストアユニット２２にエラーが返されており（破線の経路によって示されるように、たぶん直接にプロセッサコア２０に戻っている）、これは、例えば、ＭＭＵ２４内のページテーブルに格納された許可情報がこの特定のメモリアクセスを許可しないためである。メモリシステム１０内の記憶位置に到達するメモリアクセス要求は、ロード／ストアユニット２２に返されるエラー応答をもたらし、成功（メモリアクセスによってそのように定義される）した場合、対応するメモリ位置（アドレス）から検索されたデータが伴う。したがって、本明細書で使用される「エラー応答」という用語は、必ずしもエラーが発生したことを意味するものではなく、常に受信されるエラー応答の内容からエラーが発生したか否かを判定することができるということが明らかである。このデータおよびエラー応答は、例示的データＤについて図２に示すように、ロード／ストアユニット２２からプロセッサコア２０にパスすることができる。

本文脈では、これが、特にメモリアクセスが成功しなかったことをプロセッサコア２０に示す場合に、エラー応答の内容は特に関連している。この状況では、プロセッサコア２０内の処理回路は、対応する例外処理手順をトリガーするために（レジスタ値ＩＳＲ．Ａを１に設定することによって）エラー例外条件を設定する。それにもかかわらず、プロセッサコア２０は、以下の図に関して以下でより詳細に説明する状況の下で、エラー例外条件の設定によってトリガーされる例外処理手順を直ちに実行することはできない。この機能がプロセッサコア２０によって提供されるために、レジスタ８内に様々な値を格納するように構成されている。図２のレジスタ８は、（現在のプロセッサ状態、例えば、スタックポインタ、リンクレジスタ、プログラムカウンタ、および他の汎用レジスタ値を設定する）様々な状態レジスタとＰＳＴＡＴＥ．Ａ、ＩＳＲ．Ａ、ＤＩＳＲ．Ａ、ＡＭＯ、ＶＳＥ、ＶＤＩＳＲ．ＡおよびＥＭＢ ｍｏｄｅ値を保持して示されている、さらなるレジスタを概略的に示すが、接尾辞「．Ａ」によってラベル付けされた値を保持して示されたＤＩＳＲおよびＶＤＩＳＲレジスタは、さらに関連する値をも保持できることに留意すべきである。例えば、ＤＩＳＲ．Ａは、この「遅延エラー例外条件」が設定されているか否かを示す値を保持するが、ＤＩＳＲレジスタの他の部分は、エラーシンドローム情報のような、関連するエラー例外を処理するときに、使用に関するさらなる情報を格納することができる。このエラーシンドローム情報は、例えば、エラーのタイプの詳細および／またはエラーの影響の詳細をプロセッサの状態に含めることができる。これらのレジスタおよび値の使用については、以下にさらに詳細に説明する。

図３は、システムの処理回路によって実行され得るデータ処理命令の例示的なシーケンスを示す。データ処理命令の第１の部分に対して、処理回路は、最低のソフトウェア実行特権レベルに対応するその最低の例外レベル（ＥＬ０）で動作している。その後、例外処理ルーチンに対応するものとしてラベル付けされたデータ処理命令に対して、データ処理回路は最高のソフトウェア実行特権レベルに対応するその最高の例外レベル（ＥＬ３）で動作している。図に見られるように、データ処理命令の第１の部分で実行されるロード（ＬＤＲ）命令は、メモリアクセスをもたらし、この図示された実行例では、最終的に、それぞれのメモリアクセスが首尾よく完了していない、すなわちシステムエラーが発生したことを示すエラー応答が結果として生じる。したがって、この応答は非同期アボートを表し、処理回路によるアボートの受信タイミングは、対応するメモリアクセスを開始した命令が実行されたときとほとんど相関がない可能性がある。例えば、図３の例に基づくと、ＬＤＲ命令から生じるエラー応答は、ＩＲＱ（割り込み要求）後に処理回路によって受信されている。したがって、ＬＤＲ命令からのエラー応答が受信される前に第１の例外条件を設定させる（したがって例外処理ルーチンが開始される）ＩＲＱが受信され、そして、プロセッサコア２０は、（ＥＬ０例外レベルで実行される）ＬＤＲからのエラー応答が受信されるとき、ＥＬ３例外レベルで第１の例外処理ルーチンを処理している。

例外処理ルーチンの最初に示されているように、（処理回路ハードウェアによって実行される）第１の動作は、第１の例外処理ルーチンが、この例では、さらなるエラー例外条件に応答するさらなる例外処理手順が実行されるべき例外レベル以上である、最高の例外レベル（ＥＬ３）で処理されるため、エラーマスク値ＰＳＴＡＴＥ．Ａを１に設定することであり、かつ、このエラーマスク値はエラーマスク条件が設定されることを示す、ということに留意されたい。エラーマスク条件のこの設定は、本技術に従って使用され、システムエラーが発生した（したがってエラー例外条件を設定する）ことを示す処理回路によって受信される後続のエラー応答は、直ちに、さらなる例外を生成するのではなく、むしろ保留される（すなわち遅延される）。このメカニズムは、後の図を参照して以下にさらに説明する。

図３に示す例では、例外処理ルーチンの早い段階で処理回路が遭遇する命令は、本技術によって提供されるＥＭＢ（エラーメモリバリア）命令である。このＥＭＢ命令に遭遇すると、処理回路は、装置（システム）内にエラーメモリバリア条件がそのとき存在すると判定する。他の実施形態では、処理回路は、例外処理ルーチンが開始されるときはいつでもデフォルトによってエラーメモリバリア条件が存在すると判定することができ（すなわち、ＥＭＢ命令の明示的な包含は必要でない）、または処理回路は、プロセッサコアのレジスタ（図２のアイテム８）に格納されたＥＭＢモード値を参照することによってエラーメモリバリア条件が存在するか否かを判定することができ、このようにして、特定のシステム要件に従ってこのモードを設定する柔軟性をシステムプログラマに与える。最後に、例外処理ルーチンの後に、ＤＩＳＲ．Ａ＝１がチェック（この実施形態ではソフトウェアによって実行されたステップ）され、これは、例外処理ルーチンの間にシステムエラーを示すエラー応答が受信されたか否かを装置が判定することを可能にする。これのさらなる詳細については、後の図を参照して以下に説明する。

図４には、一実施形態における処理回路（すなわち、システムハードウェア）によって行われる一連のステップが示される。これらのステップは、例えば図３に示されるように例外処理ルーチンの開始時にＥＭＢ命令に遭遇したとき、またはＥＭＢモードが設定されている間に例外処理ルーチンが入力（開始）されたときに行われるアクションに対応する。ＥＭＢ命令に遭遇することは、図４に示される最初のステップ、すなわちステップ４０に対応する。それに応答して、処理回路は、保留中のメモリアクセス、すなわち図２に示されるロード／ストアユニット２２内に占有された対応するエントリーを有し、まだ完了していないメモリアクセスからの未解決のエラー応答を待つ（ステップ４２）。例外処理ルーチンを実行している間に、さらなるシステムエラーが処理回路に通知される可能性が残る。

ステップ４４において、処理回路は、エラー（すなわち、保留中のメモリアクセスが最終的には不成功であったこと）を示す（物理）エラー応答が様々な保留中のメモリアクセスの１つから受信されたか否かを判定する。そうでない場合には、フローはステップ５４に直接進み、そこで（初めのうちは例外処理ルーチン内の）さらなる命令実行が継続する。しかしながら、エラー応答がステップ４４でエラーを示している場合には、処理回路によってエラー例外条件が設定（ＩＳＲ．Ａ＝１）され、フローはステップ４６に進み、そこで、処理回路は、エラーマスク条件が設定されているか否かをチェックすることによって、このエラーはマスクされるか否かを判定する。

エラーがマスクされていない場合、フローはステップ４８に進み、そこで、このエラーに応答する例外が生成され、このような例外を処理するための通常の手順、例えば、別の例外処理ルーチンへの分岐が実行される。この例外を行うことは、例外シンドロームレジスタにエラーシンドローム情報を書き込むことを含むことができ、このエラーシンドローム情報は、プロセッサのプログラマ可視状態が、正しいか、または実際にエラーに感染しているかを示す情報を含む。逆に、ステップ４６でエラーがマスクされていると判定される場合、フローはステップ５０に進み、そこで、処理回路はＤＩＳＲ．Ａの値を１に設定し、かつ／またはエラーに関する上記のシンドローム情報をＤＩＳＲレジスタの他の部分に記録する。このエラーシンドローム情報は、エラーのタイプの詳細および／またはプロセッサの状態に対するエラーの影響の（上記のような）詳細を含む。エラータイプ情報は、エラーがエラーメモリバリアによって隔離することができるタイプであるか否かを示すこともできる。例えば、（前述のように）ステップ４２で、エラーメモリバリアは、すべてのメモリアクセスが完了してエラー状態を返すのを待つが、メモリアクセスによって誘発されなかったエラーが生じた場合、エラーメモリバリアは、このエラーを「分離」しない可能性がある。これに対処するために、例外処理手順がエラーのシンドローム情報を記録するとき、エラーがエラーメモリバリアによって分離できるタイプであるか否かを記録する。

ＤＩＳＲ．Ａの設定および／またはエラーシンドローム情報の記録は、本明細書では、遅延エラー例外条件が設定されていると呼ばれる。次に、フローはステップ５２に進み、そこで、処理回路はＩＳＲ．Ａの値を０に設定する（すなわち、エラー例外条件はクリアされる）。その後、処理回路は、命令実行、すなわち、図３に示す例の文脈において、例外処理ルーチンのＥＭＢ命令に続く命令を継続する。しかしながら、システムプログラマは、必ずしも例外処理ルーチンの中（または実際には始め）ではなく、データ処理命令内の任意のポイントに命令を追加する自由を有し、そして、そのような状況において、ステップ５４に示される命令実行の継続は、そのＥＭＢ命令が見つかるべきところであれば、ＥＭＢ命令に続く命令になることに留意されたい。

図５は、図４に示されたものと相補的であるステップのシーケンスを示しており、これは、例示的な一実施形態における例外処理ルーチンを提供するソフトウェアによって実行される。図５に示す第１ステップは、例外処理ルーチンの開始である（ステップ６０）。このポイントで、（例えば、以下でより詳細に説明するように、例外レベルに基づいて）ハードウェアはマスク条件を適切に設定することに留意されたい。次に、ステップ６２で、エラーメモリバリア条件を設定するＥＭＢ命令に遭遇する。他の実施形態では、ＥＭＢモードが設定されている可能性があり、（ステップ６０で）例外処理ルーチンを開始するとき、エラーメモリバリア条件がハードウェアによって設定され、ステップ６２をスキップすることができることに留意されたい。ステップ６４で、ソフトウェアによって実行される次のステップは、汎用レジスタの内容、例外シンドロームレジスタなどを含む任意の揮発性のプロセッサ状態を（例えばスタックに）保存することである。これにより、後の例外の分析、および例外が行われたポイントへの回復が可能になる。

プロセッサの揮発性状態が保存されると、ステップ６６において、ＤＩＳＲ．Ａの値が現在、１であるか否かが判定される。これが当てはまらない場合、命令実行が、処理回路によって受信されているシステムエラーなしにＥＭＢ動作のポイントに達したと推論することができ、ステップ６８でソフトウェアは、ＰＳＴＡＴＥ．Ａの値をクリア（すなわち、０に設定）する、つまり、このエラーマスク値はクリアされる。次に、フローはステップ７０に進み、そこで命令の実行が継続し、前述したように、受信された任意のシステムエラーが通常の方法でシステムエラー例外を生成する。そのようなシステムエラーが処理回路によって受信されたときに命令実行がＥＭＢ動作のポイントを通過したと推測することができる。しかしながら、ステップ６６においてＤＩＳＲ．Ａの値が現在、１であると判定された場合、システムエラーが処理回路によって受信され、かつ保留（遅延）されていることが分かり、フローはステップ７２に進み、そこでは、ＥＭＢ命令（またはエラーメモリバリア条件が存在するという決定がなされた少なくとも命令実行のポイント）に先行するコード（少なくとも１つのデータ処理命令を含むデータ処理命令の部分）に関して修復措置を行うために、専用のエラー回復ルーチンへの分岐が行われる。ＥＭＢ命令が例外処理ルーチンの始めにある図３に示す例では、これは、例外処理ルーチンの前のコード、すなわち例外処理ルーチンの前に示された命令のシーケンスにおいて、コードに関して行われる修復措置に対応する。

図６には、仮想化された動作環境が提供される実施形態が概略的に示される。ここで、システムハードウェアと直接に相互作用するオペレーティングシステムの制御下で実行される、アプリケーション２００のデータ処理命令の代わりに、データ処理命令は、ホストオペレーティングシステム２２０の制御下でシステムハードウェア２３０と間接的に相互作用するゲストオペレーティングシステム（仮想マシン２１０）の制御下で実行される。ホストオペレーティングシステム上で動作するハイパーバイザは、仮想化されたオペレーティング環境の全体的な制御を維持し、かつ、仮想マシン（すなわち、ゲストオペレーティングシステム）がシステム内で何を見ることができ、何と相互作用することができるかを指示する。仮想マシンプログラム２１０は、実際のハードウェアによって提供されるアプリケーションプログラムインターフェース（ＡＰＩ）と同じアプリケーションプログラムインターフェースをアプリケーションプログラム２００にサポートする。

この「仮想」ＡＰＩのいくつかの態様は、ＡＰＩを高速化するために、ハードウェア、特に仮想エラー条件、仮想エラーマスク条件、およびＶＤＩＳＲレジスタによって提供されることに留意すべきである。ハイパーバイザは、ＡＭＯ値を１に設定することによって、例外レベルＥＬ２を物理エラー例外の目標例外レベルになるように設定できる。ハイパーバイザは、システム内で「仮想エラー例外条件」を作成することもできる。これは、ＡＭＯ値が１に設定されている場合、ＶＳＥの値を１に設定するハイパーバイザによって行われる。仮想エラー例外の目標例外レベルは常にＥＬ１、すなわちゲストオペレーティングシステムである。したがって、この仮想エラーは、（前述のように）ＰＳＴＡＴＥ．Ａエラーマスク値を使用するゲストオペレーティングシステムによってマスクすることができる。したがって、ＡＭＯ値が１に設定されるとき、ＰＳＴＡＴＥ．Ａエラーマスク値は、ＥＬ１における「仮想エラーマスク条件」、およびＥＬ２における「物理エラーマスク条件」を定義する。事実、物理エラーと同じ方法でこれらの仮想エラーを処理するゲストオペレーティングシステムの機能は、ゲストオペレーティングシステムの構成を２つのタイプに対して異ならせる必要がないため、それらは同じように処理されるので、事実上、ゲストオペレーティングシステムに対して（物理エラーとは対照的に）透過的に使用される。

このように、ＡＭＯ値は、本明細書では、装置が物理エラーと仮想エラーそれぞれに応答する方法を制御するために使用される。この例示的な実施形態では、ＡＭＯ値を１に設定すると、ハイパーバイザによる少なくとも初期処理のために、すべてのシステムエラー（非同期アボート）がＥＬ２に引き継がれることが定義される。したがって、例外レベルＥＬ１では、物理エラー条件が「より高い」例外レベルで処理されるため、物理エラーマスク条件は設定されない。ＡＭＯ＝１は、仮想エラーが例外レベルＥＬ１で処理されることも意味する。したがって、例外レベルＥＬ１の場合、物理エラー条件は「より低い、または同じ」例外レベルで処理され、それで、仮想エラーマスク条件が設定される。

図７は、この例示的な実施形態におけるＥＬ１割り込み例外ハンドラの開始時にＥＭＢ命令に遭遇したことに応答して行われるステップの例示的なシーケンスを示す。図７に示す第１ステップは、ＥＭＢ命令がこの仮想化システム内のゲストオペレーティングシステムによって遭遇される（ステップ８０）ポイントを表す。したがって、これは、図４の例のステップ５２に続くということと、さらに、ＡＭＯビットが設定されているため、エラーマスク値にかかわらず、物理エラーマスク条件が設定されないということに留意されたい。その後、ＥＭＢ命令に応答して、仮想システムエラーが保留中であるか否か（すなわち、ＶＳＥ＝１かつＡＭＯ＝１であるか否か）が判定される。そうでなければ、フローは直接ステップ９２に進み、そこでは、ＥＭＢ命令に続くデータ処理命令の通常の命令実行が継続する。しかしながら、ＶＳＥ＝１かつＡＭＯ＝１であれば、フローはステップ８４に進み、そこでは、仮想エラーマスク条件が設定されているか否か、すなわちＰＳＴＡＴＥ．Ａ＝１およびＡＭＯ＝１であるか否かが判定される。そうでない場合には、フローはステップ８６に進み、そこでは、仮想エラー例外が生成され、ＥＬ１のゲストオペレーティングシステムによって適切な仮想エラー例外処理ルーチンが実行される。しかしながら、ステップ８４でこの仮想エラーがマスクされていると判定された場合、フローはステップ８８および９０に進み、そこで、仮想遅延エラー例外条件が設定（ＶＤＩＳＲ．Ａが１に設定）され、かつ仮想システムエラー例外条件指示（ＶＳＥ）は０にリセットされる。さらなるシンドローム情報は、例えば、エラーのタイプの詳細および／またはエラーの影響の詳細をプロセッサの状態に含めるＶＤＩＳＲに（ＤＩＳＲを参照して上述したように）記録することもできる。

次に、フローは、継続的な命令実行（すなわち、ＥＭＢ命令に続く命令の実行）のためにステップ９２に進む。したがって、図７に示すステップにより、仮想化システムは、ホストＯＳの一部として動作するハイパーバイザによって作成された仮想システムエラーをホストによる物理エラーと同じ方法でゲストＯＳが処理できる環境を提供することができる。特に、ゲストＯＳは、ホストＯＳがＰＳＴＡＴＥ．Ａ値の設定によって物理エラーをマスクするのと同じ方法で、仮想エラーをマスクすることができる。また、図８Ａおよび図８Ｂを参照すると、ＥＬ１割り込みハンドラの後の段階で、ソフトウェアは、図５を参照して説明したようにＤＩＳＲ．Ａが現在設定されているか否かなどをチェックするが、ＡＭＯ値が１に設定されている、この仮想化された実施形態では、ＤＩＳＲ．Ａの値がチェックされるとき、ハードウェアが介入してＶＤＩＳＲ．Ａの値を返す、ということに留意されたい。

図８Ａは、このような仮想化された動作環境がデータ処理装置によって提供される例示的な実施形態に対応する。この示された例示的な実施形態では、３つの例外領域（ＥＬ０およびＥＬ１は１つの例外領域を形成する）に対応する４つの例外レベル（ＥＬ０〜ＥＬ３）が提供され、そこでは、仮想マシンの動作を管理しているハイパーバイザは、ゲストオペレーティングシステムよりも高いソフトウェア実行特権レベルで動作し、それ自身、そのゲストオペレーティングシステム上で実行しているアプリケーションよりも高いソフトウェア実行特権レベルで動作する。図８Ａの右手部分は、例示的なイベントセットに対応する例外レベル間の遷移を概略的に示す。示された第１のイベントは、ゲストオペレーティングシステムで動作しているアプリケーションが最低の例外レベル（ＥＬ０）で実行されている間に処理回路によって受信された物理（すなわち仮想ではない）エラーの受信である。対応する物理エラー例外は目標例外レベルＥＬ２を有する、すなわち、物理エラー例外ハンドラはハイパーバイザによって実行される。この例示的な実施形態では、この構成は、ＡＭＯ値が１に設定され、ハイパーバイザによる少なくとも初期処理のためにすべてのシステムエラー（非同期アボート）がＥＬ２に引き継がれることを定義する、という事実によって整えられる。

しかしながら、ハイパーバイザは、システム内に「仮想エラー」を設定することによって行うことができるが、ゲストオペレーティングシステムに例外処理を委任できるように、さらに構成されているため、受信したシステムエラーに対するエラー応答を完全に実行する必要はない。これは、ＡＭＯ値が１に設定されている場合、ハイパーバイザがＶＳＥの値を１に設定することによって行われる。これは非同期イベントではないが、それにもかかわらず、この仮想エラーは（上述のように）エラーマスク値ＰＳＴＡＴＥ．Ａを使用してゲストオペレーティングによってマスクすることができる。ＡＭＯ値が１に設定されると、エラーマスク値ＰＳＴＡＴＥ．Ａは「仮想エラーマスク条件」を定義する。事実、これらの仮想エラーを物理エラーと同じ方法で処理するゲストオペレーティングシステムの機能は、ゲストオペレーティングシステムの構成を２つのタイプに対して異ならせる必要がないため、それらは同じように処理されるので、実際にはゲストオペレーティングシステムに対してこれらの仮想エラーを（物理エラーとは対照的に）透過的に使用する。この透明性がどのように達成されるかのさらなる詳細を、以下に示す。

したがって、アプリケーションが引き継ぐためにハイパーバイザが例外レベルをＥＬ０に返すと、仮想エラー例外の目標は、すぐＥＬ１になり、ゲストオペレーティングシステムによって処理される。しかしながら、エラーハンドラがＥＬ２でハイパーバイザの制御下で動作していた間に、割り込み要求（ＩＲＱ）がシステムによって受信されたことに留意されたい。したがって、ソフトウェア実行特権レベルがＥＬ０に戻ると、保留中の２つの例外、（ＶＳＥの設定によってハイパーバイザによって設定された）１つの仮想システムエラーと、より最近受信された物理割り込み（ＩＲＱ）がある。これら２つの保留中の例外が行われる順序は、システム設計者が特定のシステム要件（すなわち、それは定義された実施形態である）に依存して定義することができる。図８Ａに示す例では、それは、最初に行われるのはＩＲＱに対する応答であり、これはＥＬ１の目標を有する。ＥＬ１で実行された割り込みハンドラ（例外処理ルーチン）が次に実行される。この例外処理ルーチンは、図示されているようにＥＭＢ命令で始まり、したがって、仮想マシンによって実行されるステップは、この仮想化された実施形態に適応して、図４に示されたステップに関連する。

図８Ｂは別の例示的な実施形態に対応し、この例ではＥＬ０，ＥＬ１およびＥＬ２のみが説明されるが、そのような仮想化された動作環境が、再び４つの例外レベルを有するデータ処理装置によって提供される。これは、（ＥＬ２が、到達する最高の例外レベルという違いがあるが）、図３の例に対応する。図８Ｂの右手部分には、別の例示的なイベントセットに対応する例外レベル間の遷移が概略的に示される。示された最初のイベントは、ＥＬ０でのＬＤＲ命令の実行である。このメモリアクセスに対する応答が生じる前に、ＥＬ１（すなわち、ゲストＯＳ）に対してＩＲＱ例外が行われる。ＥＬ１では、ゲストＯＳの制御下でＥＭＢ命令が実行される。ＥＭＢ動作により、物理エラー例外条件が検出され、（ＡＭＯが設定されているので）、（図４に示したように）エラーはマスクされないため、エラー例外が即座に生成される。エラー例外はＥＬ２（すなわち、ホストＯＳ／ハイパーバイザ）に受け取られる。ホストＯＳ／ハイパーバイザは、（エラーハンドラのアクションによって）エラーを分類し、ＶＳＥを１に設定して「仮想エラー」を設定することによって、処理をＥＬ１に委任する。命令実行が戻り、ＥＭＢ命令が再実行される。

この時点で、物理エラー（ＩＲＱ）が処理されているので、すぐにＥＭＢは仮想エラーを処理する。仮想エラーはＰＳＴＡＴＥ．Ａによってマスクされるので、ＶＤＩＳＲ．Ａが上記のように設定される。したがって、委任された仮想エラーは、ＥＭＢ命令によって遅延される。図８Ｂの例において（図８Ａの例とは対照的に）、ＥＬ０に戻る際に保留中の仮想エラーよりもＩＲＱに優先順位を付ける（任意の）選択肢がないことと、さらに仮想事例ではＥＭＢ命令が仮想エラーおよび物理エラーの両方をどのように妨げるかを示すことに留意されたい。

図９Ａは、（一実施例の）仮想化されたシステムを提供する例示的な実施形態における、現在の例外レベルと目標例外レベルとの間の対応を与えるテーブルを示す。これらは、これらの状況のそれぞれで物理エラー例外条件がどのように処理されるかを示し、すなわち、それは（Ｐ）常に保留される、すなわちマスクされているとして自動的に扱われる、（Ｍ）ＰＳＴＡＴＥ．Ａが設定されている（すなわち、物理システムエラーがマスクされている）場合には保留され、そうでない場合は行われる、または、それは（Ｔ）常に行われる（すなわち、ＰＳＴＡＴＥ．Ａによるマスキングを受けない）であり得る。図９Ｂは、仮想システムエラーの対応テーブルを示しており、それは、示されるように、仮想システムエラーが遭遇する（すなわち、ハイパーバイザによって設定される）とき現在の例外レベルに関係なく、（すなわち、ゲストＯＳによって処理される）ＥＬ１の目標例外レベルを常に有する。図９Ｃは、物理システムエラーの目標を定義するために仮想化システム内のハイパーバイザによるＡＭＯおよびＶＳＥ値の使用を提示する表を示す。

図１０Ａは、例示的な一実施形態におけるエラーメモリバリア命令の構成を定義する、例示的な一連の擬似コードを示す。図１０Ａの擬似コードでは、以下の関数および略語が使用される。
ＨａｖｅＥＬ（ｅｘｃｅｐｔｉｏｎ ｌｅｖｅｌ）−この例外レベルが存在する場合は真を返す。
ＳＣＲ＿ＥＬ３．ＥＡ−例外レベルＥＬ３になるようにシステムエラー（非同期アボート）の目標を定義するように設定される。
ＩｓＳｅｃｕｒｅ（）−現在、（例えば、ＡＲＭ Ｌｉｍｉｔｅｄ Ｃａｍｂｒｉｄｇｅ，ＵＫ提供のＴｒｕｓｔＺｏｎｅテクノロジによって提供される）安全状態で動作している場合、真を返す。
ＰＳＴＡＴＥ．ＥＬ−現在の例外レベルを定義する。
ＨＣＲ＿ＥＬ２．ＴＧＥ−（ＥＬ１とは対照的に）すべての例外がＥＬ２で処理されることを定義するように設定される。
ＨＣＲ＿ＥＬ２．ＡＭＯ−実行レベルＥＬ２に対して定義された上述のＡＭＯ値。
ＤＩＳＲ＿ＥＬ１．Ａ−遅延エラー例外条件を例外レベルＥＬ１で記録する。
ＩＳＲ＿ＥＬ１．Ａ−エラー例外条件を記録する。
ＨＣＲ＿ＥＬ２．ＶＳＥ−例外レベルＥＬ２で設定された上述のＶＳＥ値。
ＶＤＩＳＲ ＥＬ２．Ａ−上述のＶＤＩＳＲ値。

したがって、図１０Ａに示す擬似コードの例は、ＳＣＲ＿ＥＬ３．ＥＡビットを使用して、図９Ｃに示す原理をＥＬ３に拡張することに留意されたい。このビットの値は、物理エラー例外の目標例外レベルをＥＬ３に設定し、ＨＣＲ＿ＥＬ２．ＡＭＯよりも優先される。しかしながら、この例示的な実施形態では、さらなる「仮想エラー」条件、すなわち「ＳＣＲ＿ＥＬ３．ＶＳＥ」ビットが存在しないことに留意されたい。

図１０Ｂには、例外ハンドラが発呼者にエラーを分離したい場合の、例外エントリーのための命令の例示的なシーケンスが示される。このシーケンスの開始時のＥＭＢ命令と、示されたシーケンスの最後のＭＲＳ／ＴＢＮＺペア（図５のステップ６６と７２に対応する）の使用に留意されたい。例えば、ＭＲＳ（「システムレジスタからレジスタへの移動」）は、一対のレジスタをメモリに格納するために使用されるＤＩＳＲ，ＳＴＰ（「ハンドラストアペア」）の値を読み取るために使用され、かつ、ＴＢＮＺ（テストしてゼロ以外の場合は分岐）は、レジスタ内のビットをテストして、値がゼロ以外の場合は分岐するために使用されることに留意されたい。

本発明の例示的な実施形態を添付の図面を参照して本明細書に詳細に説明したが、本発明はこれらの厳密な実施形態に限定されず、添付の特許請求の範囲によって規定される本発明の範囲および趣旨から逸脱することなく、様々な変更、追加および修正を当業者によって行うことができることを理解されたい。例えば、本発明の範囲から逸脱することなく、従属請求項の特徴の様々な組み合わせを独立請求項の特徴と組み合わせることができる。

Claims (20)

1. データ処理装置であって、
   データ処理命令に応答してデータ処理動作を実行し、エラーメモリバリア条件が存在するか否かを判定し、かつ、前記エラーメモリバリア条件が存在するか否かに依存してエラーメモリバリア手順を実行するための処理回路を備え、
   前記処理回路は、データ処理動作が成功しなかったことの検出時に、エラー例外条件を設定することが可能であり、
   前記エラーメモリバリア手順は、前記エラー例外条件が設定されている場合、かつ、エラーマスク条件が設定されている場合、
   遅延エラー例外条件を設定すること、および
   前記エラー例外条件をクリアすることを含む、データ処理装置。
2. 前記処理回路は、前記エラー例外条件が設定されており、かつ、前記エラーマスク条件が設定されていない場合、例外処理手順を実行することが可能である、請求項１に記載の装置。
3. 前記データ処理動作は、メモリアクセスを含み、
   前記処理回路は、メモリアクセスのためのエラー応答を受信することが可能であり、前記エラー応答が、前記メモリアクセスが成功しなかったことを示す場合に、前記エラー例外条件を設定することが可能である、請求項１または請求項２に記載の装置。
4. 前記処理回路は、前記データ処理命令内のエラーメモリバリア命令に応答して、前記エラーメモリバリア条件が存在することを判定することが可能である、請求項１〜３のいずれか１つに記載の装置。
5. 前記処理回路は、例外処理手順の一部として、かつ、前記遅延エラー例外条件が設定されている場合に、少なくとも１つのデータ処理命令に関して修復応答を開始することが可能であり、前記少なくとも１つのデータ処理命令は、前記エラーメモリバリア条件が存在すると判定する前に実行されたデータ処理命令を含む、請求項２〜４のいずれか１つに記載の装置。
6. エラーメモリバリアモード値記憶装置をさらに備え、前記処理回路が例外処理手順の実行を開始するとき、前記処理回路は、前記エラーメモリバリアモード値記憶装置に記憶されたエラーメモリバリアモード値に依存して、前記エラーメモリバリア条件が存在することを判定することが可能である、請求項２〜５のいずれか１つに記載の装置。
7. 前記処理回路は、前記エラーメモリバリア手順を実行するとき、かつ、前記エラーメモリバリア条件が存在する場合、さらなるデータ処理命令を実行する前にまだ完了していない各メモリアクセスのエラー応答を待つことが可能である、請求項３〜６のいずれか１つに記載の装置。
8. エラーマスク値記憶装置をさらに備え、前記処理回路は、前記エラーマスク条件が、前記エラーマスク値記憶装置に記憶されたエラーマスク値に依存して設定されるか否かを判定することが可能である、請求項１〜７のいずれか１つに記載の装置。
9. 前記処理回路は、例外処理手順を開始するときに、エラーマスク値を設定することが可能である、請求項２〜８のいずれか１つに記載の装置。
10. 前記処理回路は、前記遅延エラー例外条件が設定されていない場合、例外処理手順の一部として、エラーマスク値をクリアすることが可能である、請求項２〜９のいずれか１つに記載の装置。
11. 前記処理回路は、前記遅延エラー例外条件が設定されていない場合、既定の組のデータ処理命令が完了した後に、エラーマスク値を設定し、かつ、前記エラーマスク値をクリアすることが可能である、請求項１〜１０のいずれか１つに記載の装置。
12. 前記処理回路は、複数の例外レベルから選択された現在の例外レベルで例外処理手順を実行することが可能であり、前記複数の例外レベルは、複数のソフトウェア実行特権レベルに対応する、請求項２〜１１のいずれか１つに記載の装置。
13. 前記処理回路は、前記例外処理手順が、さらなるエラー例外条件に応答するさらなる例外処理手順が実行されるべきである前記例外レベル以上である例外レベルで、前記処理回路によって実行されるべきである場合に、前記例外処理手順を開始するとき、前記エラーマスク条件を設定することが可能である、請求項１２に記載の装置。
14. 前記処理回路は、前記例外処理手順が、さらなるエラー例外条件に応答するさらなる例外処理手順が実行されるべきである前記例外レベル未満である例外レベルで、前記処理回路によって実行されるべきである場合に、前記例外処理手順を開始するとき、前記エラーマスク条件を設定しないことが可能である、請求項１２または請求項１３に記載の装置。
15. 少なくとも１つの仮想マシンが動作する仮想化された動作環境を提供することができ、前記仮想マシンが、前記処理回路との相互作用により、前記データ処理命令に応答して前記データ処理動作を実行することが可能である、請求項１〜１４のいずれか１つに記載の装置。
16. 請求項２に従属する場合、前記装置は、仮想エラー例外条件を設定することが可能であり、前記処理回路は、前記仮想エラー例外条件が設定されており、かつ、仮想エラーマスク条件が設定されていない場合、前記例外処理手順を実行することが可能である、請求項１５に記載の装置。
17. 仮想エラー例外条件が設定されている場合、かつ、仮想エラーマスク条件が設定されている場合、前記エラーメモリバリア手順は、
    仮想遅延エラー例外条件を設定すること、および
    前記仮想エラー例外条件をクリアすることをさらに含む、請求項１５または請求項１６に記載の装置。
18. 前記装置は、前記処理回路が、前記遅延エラー例外条件が設定されているか否を判定しようとしているとき、前記遅延エラー例外条件の値の代わりに、前記仮想遅延エラー例外条件の値を提供することが可能である、請求項１７に記載の装置。
19. データ処理方法であって、
    データ処理命令に応答してデータ処理動作を実行するステップと、
    データ処理動作が成功しなかったことの検出時にエラー例外条件を設定するステップと、
    エラーメモリバリア条件が存在するか否かを判定するステップと、
    前記エラーメモリバリア条件が存在するか否かに依存して、エラーメモリバリア手順を実行するステップと、を含み、
    前記エラーメモリバリア手順は、前記エラー例外条件が設定されている場合、かつ、エラーマスク条件が設定されている場合、
    遅延エラー例外条件を設定すること、および
    前記エラー例外条件をクリアすることを含む、方法。
20. データ処理装置であって、
    データ処理命令に応答してデータ処理動作を実行するための手段と、
    データ処理動作が成功しなかったことの検出時に、エラー例外条件を設定するための手段と、
    エラーメモリバリア条件が存在するか否かを判定するための手段と、
    前記エラーメモリバリア条件が存在するか否かに依存して、エラーメモリバリア手順を実行するための手段と、を備え、
    前記エラーメモリバリア手順は、前記エラー例外条件が設定されている場合、かつ、エラーマスク条件が設定されている場合、
    遅延エラー例外条件を設定すること、および
    前記エラー例外条件をクリアすることを含む、装置。