知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-07
(54)【発明の名称】監視排他命令
(51)【国際特許分類】
G06F 11/30 20060101AFI20240131BHJP
【ＦＩ】
G06F11/30 155
G06F11/30 140N
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023543145
(86)(22)【出願日】2021-12-10
(85)【翻訳文提出日】2023-08-17
(86)【国際出願番号】 GB2021053238
(87)【国際公開番号】W WO2022162334
(87)【国際公開日】2022-08-04
(31)【優先権主張番号】2101232.3
(32)【優先日】2021-01-29
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】500395107
【氏名又は名称】アーム・リミテッド
(74)【代理人】
【識別番号】110000855
【氏名又は名称】弁理士法人浅村特許事務所
(72)【発明者】
【氏名】ホースネル、マシュー ジェイムズ
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042GA33
5B042JJ17
5B042JJ41
5B042MA08
5B042MA14
5B042MC40
(57)【要約】
装置は、命令デコーダ２０及び処理回路２２を含む。監視回路３６は、監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視し、監視されるアドレスのセットのうちの少なくとも１つに対してイベントが発生したかどうかを示す監視報告インジケーションを、処理回路２２上で実行されるソフトウェアに対してアクセス可能にする。所与のアドレスを指定する排他ステータス設定命令をデコードしたことに応じて、処理回路２２は、所与のアドレスに関連付けられた排他ステータスを設定する。排他ステータスは、所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じてクリアされる。監視排他命令をデコードしたことに応じて、処理回路２２は、排他ステータスがターゲットアドレスに関連付けられているかどうかを判定し、関連付けられている場合、ターゲットアドレスを、監視されるアドレスのセットのうちの１つとなるように割り当てる。
【選択図】図２
【選択図】図２
【特許請求の範囲】
【請求項1】
装置であって、命令をデコードするための命令デコーダと、
前記命令デコーダによってデコードされた前記命令に応じてデータ処理を実行するための処理回路と、
監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視し、前記監視されるアドレスのセットのうちの少なくとも１つに対して前記１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションを、前記処理回路上で実行されるソフトウェアに対してアクセス可能にするための監視回路と、を備え、
前記命令デコーダが、所与のアドレスを指定する排他ステータス設定命令をデコードしたことに応じて、前記処理回路は、前記所与のアドレスに関連付けられた排他ステータスを設定するように構成されており、
前記処理回路は、前記所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、前記所与のアドレスに関連付けられた前記排他ステータスをクリアするように構成されており、
前記命令デコーダが監視排他命令をデコードしたことに応じて、前記処理回路は、
前記排他ステータスがターゲットアドレスに関連付けられているかどうかを判定することと、
前記排他ステータスが前記ターゲットアドレスに関連付けられていると判定されると、前記ターゲットアドレスを、前記１つ以上のイベントが前記監視回路によって監視される前記監視されるアドレスのセットのうちの１つとなるように割り当てることと、を行うように構成されている、装置。
【請求項2】
前記命令デコーダが前記監視排他命令をデコードしたことに応じて、前記処理回路は、ソフトウェアに対してアクセス可能になっている監視割り当てステータスインジケーションを返すように構成されており、前記監視割り当てステータスインジケーションは、前記ターゲットアドレスが、前記監視排他命令に応じて前記監視されるアドレスのセットのうちの１つとなるように正常に割り当てられたかどうかを示す、請求項１に記載の装置。
【請求項3】
前記監視されるアドレスのセットのうちの１つとなるように前記ターゲットアドレスを割り当てることが失敗した場合、前記監視割り当てステータスインジケーションは、前記ターゲットアドレスの割り当ての失敗の理由を示す、請求項２に記載の装置。
【請求項4】
前記監視割り当てステータスインジケーションは、前記排他ステータスが、前記ターゲットアドレスに対してもはや設定されていない、
前記排他ステータスが、前記ターゲットアドレス以外のアドレスに対して設定されている、及び
前記監視回路が、利用不可能であるか、又は前記監視されるアドレスのセットへのアドレスの割り当てを受け入れるようにまだ構成されていない、という理由のうちの少なくとも２つを区別する、請求項３に記載の装置。
【請求項5】
前記監視排他命令は前記ターゲットアドレスを指定する、請求項１～４のいずれか一項に記載の装置。
【請求項6】
前記ターゲットアドレスは、前記監視排他命令よりも前の直近の排他ステータス設定命令によって前記所与のアドレスとして指定されたアドレスを含む、請求項１～４のいずれか一項に記載の装置。
【請求項7】
前記命令デコーダが前記監視排他命令をデコードしたことに応じて、前記排他ステータスが前記ターゲットアドレスに関連付けられていると判定されると、前記処理回路は、前記ターゲットアドレスに対応する識別子ストレージ構造のエントリに、前記監視排他命令のオペランドとして指定された識別子値を割り当てるように構成されている、請求項１～６のいずれか一項に記載の装置。
【請求項8】
前記識別子ストレージ構造は、複数のエントリを含む専用のアドレス監視追跡構造を含み、各エントリは、前記監視されるアドレスのセットのうちの対応する１つに関連付けられた情報を追跡するためのものである、請求項７に記載の装置。
【請求項9】
前記識別子ストレージ構造は、メモリ内にストアされたデータ構造を含む、請求項７に記載の装置。
【請求項10】
前記監視排他命令は、前記識別子ストレージ構造のベースアドレスを識別するための情報を指定する、請求項９に記載の装置。
【請求項11】
前記監視回路は、前記監視回路により前記１つ以上のイベントのいずれかの発生が検出された前記監視されるアドレスのセットのうちの１つに対応する前記識別子ストレージ構造のエントリにストアされている識別子のインジケーションを、ソフトウェアに対してアクセス可能にするように構成されている、請求項７～１０のいずれか一項に記載の装置。
【請求項12】
前記命令デコーダが監視ポーリング命令をデコードしたことに応じて、前記処理回路及び前記監視回路のうちの少なくとも１つは、前記監視されるアドレスのセットのうちのどれが前記１つ以上のイベントに遭遇したかを示す監視ポーリング情報をソフトウェアに対してアクセス可能にするように構成されている、請求項１～１１のいずれか一項に記載の装置。
【請求項13】
前記命令デコーダが監視排他命令をデコードしたことに応じて、前記排他ステータスが前記ターゲットアドレスに関連付けられていると判定されると、前記処理回路は、前記ターゲットアドレスに対応する識別子ストレージ構造のエントリに、前記監視排他命令のオペランドとして指定された識別子値を割り当てるように構成されており、前記監視ポーリング情報は、前記１つ以上のイベントが発生した前記監視されるアドレスのセットのうちの少なくとも１つに関連付けられた前記識別子値を含む、請求項１２に記載の装置。
【請求項14】
前記識別子ストレージ構造は、メモリにストアされたデータ構造を含み、前記監視ポーリング命令は、前記識別子ストレージ構造のベースアドレスを指定する、請求項１３に記載の装置。
【請求項15】
前記監視ポーリング情報は、前記１つ以上のイベントが発生した前記監視されるアドレスのセット内のアドレスの数を示すカウント値を含む、請求項１２及び１３のいずれか一項に記載の装置。
【請求項16】
前記処理回路は、前記監視ポーリング命令によって識別される宛先レジスタに前記監視ポーリング情報を書き込むことによって前記監視ポーリング情報をソフトウェアに対してアクセス可能にするように構成されている、請求項１２～１５のいずれか一項に記載の装置。
【請求項17】
前記排他ステータス設定命令はロード排他命令を含み、前記命令デコーダが前記ロード排他命令をデコードしたことに応じて、前記処理回路は、前記所与のアドレスに関連付けられたデータを前記ロード排他命令によって指定された少なくとも１つの宛先レジスタにロードし、前記所与のアドレスに関連付けられた前記排他ステータスを設定するように構成されている、請求項１～１６のいずれか一項に記載の装置。
【請求項18】
前記命令デコーダが、ストアターゲットアドレス及び少なくとも１つのソースレジスタを指定するストア排他命令をデコードしたことに応じて、前記処理回路は、前記排他ステータスが前記ストアターゲットアドレスに関連付けられているかどうかを判定することと、
前記排他ステータスが前記ストアターゲットアドレスに関連付けられていると判定されると、前記少なくとも１つのソースレジスタからのデータを前記ストアターゲットアドレスに関連付けられたメモリロケーションにストアすることと、を行うように構成されている、請求項１～１７のいずれか一項に記載の装置。
【請求項19】
方法であって、所与のアドレスを指定する排他ステータス設定命令をデコードしたことに応じて、前記所与のアドレスに関連付けられた排他ステータスを設定することと、
前記所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、前記所与のアドレスに関連付けられた前記排他ステータスをクリアすることと、
監視排他命令をデコードしたことに応じて、
前記排他ステータスがターゲットアドレスに関連付けられているかどうかを判定し、
前記排他ステータスが前記ターゲットアドレスに関連付けられていると判定されると、前記ターゲットアドレスを監視されるアドレスのセットのうちの１つとなるように割り当てる、ことと、
前記監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視することと、
前記監視されるアドレスのセットのうちの少なくとも１つに対して前記１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションをソフトウェアに対してアクセス可能にすることと、を含む、方法。
【請求項20】
ホストデータ処理装置上で実行されると、前記ホストデータ処理装置を制御して、ターゲットコードの命令を実行するための命令実行環境を提供するコンピュータプログラムであって、前記コンピュータプログラムは、前記ターゲットコードの命令をデコードして、前記ターゲットコードの前記命令に対応するデータ処理を実行するように前記ホストデータ処理装置を制御するための命令デコードプログラムロジックと、
シミュレーションされたアドレス空間内の監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視し、前記監視されるアドレスのセットのうちの少なくとも１つに対して前記１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションを前記ターゲットコードに対してアクセス可能にするための監視プログラムロジックと、を備え、
前記シミュレーションされたアドレス空間内の所与のアドレスを指定する前記ターゲットコードの排他ステータス設定命令に応じて、前記命令デコードプログラムロジックは、前記ホストデータ処理装置を制御して、前記所与のアドレスに関連付けられた排他ステータスを設定するように構成されており、前記コンピュータプログラムは、前記シミュレーションされたアドレス空間内の前記所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、前記所与のアドレスに関連付けられた前記排他ステータスをクリアするための排他ステータスクリアプログラムロジックを含み、
前記ターゲットコードの監視排他命令に応じて、前記命令デコードプログラムロジックは、前記ホストデータ処理装置を制御して、
前記排他ステータスが、前記シミュレーションされたアドレス空間内のターゲットアドレスに関連付けられているかどうかを判定することと、
前記排他ステータスが前記ターゲットアドレスに関連付けられていると判定されると、前記ターゲットアドレスを、前記１つ以上のイベントが前記監視プログラムロジックによって監視される前記監視されるアドレスのセットのうちの１つとなるように割り当てることと、を行うように構成されている、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本技法は、データ処理の分野に関する。
【0002】
データ処理システムは、共有メモリシステムへのアクセスを共有し得る複数の要求側デバイスを有し得る。時折、所与のリクエスタデバイス上で実行される処理は、別のリクエスタデバイスからの要求に応じてデータがメモリ内で更新されるのを待つ必要があり得る。例えば、ＣＰＵ又は他の処理要素上で実行されるソフトウェアは、メモリ内のデータのキューがネットワークインタフェースコントローラなどの入力／出力デバイスによって更新されるのを待っていることがある。同様の問題は、同じ処理要素上で実行される複数のプロセスがプロセス間通信を提供するためにメモリ内の構造を使用するときにも発生することがある。所与のソフトウェアプロセスによって変化が監視されるメモリ内の別個のアドレスの数が多い場合、ソフトウェアが各アドレスを繰り返しポーリングすることによってこの監視を実行することは非効率的であり得る。
【0003】
少なくともいくつかの例は、命令をデコードするための命令デコーダと、命令デコーダによってデコードされた命令に応じてデータ処理を実行するための処理回路と、監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視し、監視されるアドレスのセットのうちの少なくとも１つに対して１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションを、処理回路上で実行されるソフトウェアに対してアクセス可能にするための監視回路と、を備える装置を提供し、命令デコーダが、所与のアドレスを指定する排他ステータス設定命令をデコードしたことに応じて、処理回路は、所与のアドレスに関連付けられた排他ステータスを設定するように構成されており、処理回路は、所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、所与のアドレスに関連付けられた排他ステータスをクリアするように構成されており、命令デコーダが監視排他命令をデコードしたことに応じて、処理回路は、排他ステータスがターゲットアドレスに関連付けられているかどうかを判定することと、排他ステータスがターゲットアドレスに関連付けられていると判定されると、ターゲットアドレスを、１つ以上のイベントが監視回路によって監視される前記監視されるアドレスのセットのうちの１つとなるように割り当てることと、を行うように構成されている。
【0004】
少なくともいくつかの例は、所与のアドレスを指定する排他ステータス設定命令をデコードしたことに応じて、所与のアドレスに関連付けられた排他ステータスを設定することと、所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、所与のアドレスに関連付けられた排他ステータスをクリアすることと、監視排他命令をデコードしたことに応じて、排他ステータスがターゲットアドレスに関連付けられているかどうかを判定し、排他ステータスがターゲットアドレスに関連付けられていると判定されると、ターゲットアドレスを監視されるアドレスのセットのうちの１つとなるように割り当てる、ことと、監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視することと、監視されるアドレスのセットのうちの少なくとも１つに対して１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションをソフトウェアに対してアクセス可能にすることと、を含む方法を提供する。
【0005】
少なくともいくつかの例は、ホストデータ処理装置上で実行されると、ホストデータ処理装置を制御して、ターゲットコードの命令を実行するための命令実行環境を提供するコンピュータプログラムを提供し、このコンピュータプログラムは、ターゲットコードの命令をデコードして、ターゲットコードの命令に対応するデータ処理を実行するようにホストデータ処理装置を制御するための命令デコードプログラムロジックと、シミュレーションされたアドレス空間内の監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視し、監視されるアドレスのセットのうちの少なくとも１つに対して１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションをターゲットコードに対してアクセス可能にするための監視プログラムロジックと、を備えており、シミュレーションされたアドレス空間内の所与のアドレスを指定するターゲットコードの排他ステータス設定命令に応じて、命令デコードプログラムロジックは、ホストデータ処理装置を制御して、所与のアドレスに関連付けられた排他ステータスを設定するように構成されており、コンピュータプログラムは、シミュレーションされたアドレス空間内の所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、所与のアドレスに関連付けられた排他ステータスをクリアするための排他ステータスクリアプログラムロジックを含み、ターゲットコードの監視排他命令に応じて、命令デコードプログラムロジックは、ホストデータ処理装置を制御して、排他ステータスが、シミュレーションされたアドレス空間内のターゲットアドレスに関連付けられているかどうかを判定することと、排他ステータスがターゲットアドレスに関連付けられていると判定されると、ターゲットアドレスを、１つ以上のイベントが監視プログラムロジックによって監視される前記監視されるアドレスのセットのうちの１つとなるように割り当てることと、を行うように構成されている。
【0006】
コンピュータプログラムは、コンピュータ可読記憶媒体に記憶されてもよい。コンピュータ可読記憶媒体は、非一時的記憶媒体であってもよい。
【図面の簡単な説明】
【0007】
本技法の更なる態様、特徴、及び利点は、添付の図面と併せて読まれる以下の例の説明から明らかとなる。
【図1】複数のリクエスタデバイスと、リクエスタデバイスを結合し、リクエスタデバイスによる共有メモリへのアクセスを制御するためのインターコネクトとを有するデータ処理システムの一例を概略的に示す。
【図2】アドレス監視回路を備える、リクエスタデバイスの１つとして機能する処理要素の一例を示す。
【図3】ロード排他命令の処理を示す。
【図4】排他ステータスのクリアを示す。
【図5】ストア排他命令の処理を示す。
【図6】監視排他命令の複数の変形例、及び監視排他命令を処理する方法を示す。
【図7】監視されるアドレスのセットに関連付けられたデータに対する潜在的な更新を監視することを示す。
【図8】アドレス監視に使用するアドレス追跡構造の代替例を示す。
【図9】アドレス監視に使用するアドレス追跡構造の代替例を示す。
【図10】監視ポーリング命令の２つの変形例、及び監視ポーリング命令を処理する方法を示す。
【図11】監視ポーリング命令の処理をより詳細に示す。
【図12】シミュレーションの例を示す。
【0008】
装置は、命令をデコードするための命令デコーダと、命令デコーダによってデコードされた命令に応じてデータ処理を実行するための処理回路とを有し得る。命令デコーダ及び処理回路は、特定の命令セットアーキテクチャ（ＩＳＡ）に従って定義される命令をサポートし得る。
【0009】
監視回路は、監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示す１つ以上のイベントを監視するために提供され得る。監視回路は、監視されるアドレスのセットのうちの少なくとも１つに対して１つ以上のイベントのいずれかが発生したかどうかを示す監視報告インジケーションを、処理回路上で実行されるソフトウェアに対してアクセス可能にし得る。そのような監視回路は、ソフトウェアが、監視されるアドレスに対して読み取り要求を繰り返し発行することによって特定のアドレスを明示的にポーリングすることを必要とすることなく、そのアドレスが更新されたかどうかを識別することを可能にするため、有用であり得る。監視回路は、ハードウェア内に実装された回路ロジックを有することができ、この回路ロジックは、監視されるアドレスのセットのうちの１つに対する潜在的な更新を示し得る関連イベントを監視し、そのようなイベントが発生したときに監視報告情報をソフトウェアに提供することができる。監視されるアドレスのセットは、ソフトウェアによって構成可能であり得、監視されるセットとして２つ以上のアドレスを指定することが可能であり得、したがって、単一アドレスのみの監視に限定されない。
【0010】
監視回路を有するシステムでは、ソフトウェアが、ハードウェアに設けられた監視回路によってどのアドレスが監視されるべきかを制御するための監視されるアドレスのセットを構成することに関連したいくらかの性能オーバーヘッドが存在する可能性がある。例えば、ソフトウェアは、メモリにストアされた多数のキューに対する更新を監視していることがあるが、全てのキューが所与の時間に監視されることを必要とするわけではないことがあり、場合によっては、ソフトウェアは、キューを監視する必要があるかどうかを決定するために、そのキューがアクティブであるか、又は更新を受け入れる準備ができているかなど、各キューに関する特定のステータス情報を評価することを必要とすることがある。ソフトウェアは、ステータス情報が読み取られる時点から、対応するアドレスを監視するか否かが決定される時点までの間、ステータス情報に対する潜在的な更新を防ぐことを必要とする場合がある。キューを監視し、ステータス情報をチェックするこの例は、ソフトウェアが実装し得る潜在的な使用事例の１つに過ぎず（他にもある）、更新について監視されるべき監視されるアドレスのセットを確立する際にいくらかのオーバーヘッドがあり得る例示的なシナリオを示すことが理解されよう。
【0011】
以下に説明する例では、命令デコーダ及び処理回路は、監視排他命令の処理をサポートする。監視排他命令は、命令デコーダ及び処理回路によってサポートされるＩＳＡによって定義される命令であり得る。命令デコーダが監視排他命令をデコードしたことに応じて、処理は、排他ステータスがターゲットアドレスに関連付けられているかどうかを判定し、排他ステータスがターゲットアドレスに関連付けられていると判定されると、ターゲットアドレスを、１つ以上のイベントが監視回路によって監視される監視されるアドレスのセットのうちの１つとなるように割り当てる。
【0012】
排他ステータスは、排他ステータス設定命令を実行することによって特定のアドレスに対して設定することができる。命令デコーダが、所与のアドレスを指定する排他ステータス設定命令をデコードしたことに応じて、処理回路は、所与のアドレスに関連付けられた排他ステータスを設定し得る。処理回路は、所与のアドレスへの競合するメモリアクセスを示すイベントを検出したことに応じて、所与のアドレスに関連付けられた排他ステータスをクリアし得る。競合するメモリアクセスを示すそのようなイベントの検出は、ハードウェアで実施することができ、排他ステータス設定命令を実行したプロセスによって実行される明示的なソフトウェア命令を必ずしも含む必要はない。排他ステータス設定命令は、ソフトウェアが特定のアドレスに対して排他ステータスを設定することを可能にし、その結果、排他ステータス設定命令と後続命令との間の期間中に競合するメモリアクセスが発生したかどうかを後続命令上でチェックすることができる。しかしながら、実際には、このような排他ステータス設定命令をサポートするプロセッサは、多くの場合、排他ステータスを、比較的少数のアドレス（場合によっては単一のアドレスのみ）に対して設定されるように制限し得、そのため、変更について監視されるべきアドレスの数が大きく（例えば、５０～１００又はそれ以上に）なり得るマルチアドレス監視の使用事例に対処するには、排他ステータスだけでは不十分である場合があり、したがって、監視回路は、複数のアドレスが監視されることを伴う問題に対してより適切なものであり得る。それでも、排他ステータスをアドレスに割り当てることをサポートすることは、監視回路によって監視されるべき監視されるアドレスのセットを構成することの容易さを改善することができる監視排他命令をサポートするのに有用であり得る。
【0013】
したがって、監視排他命令に応じて、排他ステータスがターゲットアドレスに関連付けられているかどうかがチェックされ、依然として排他ステータスがターゲットアドレスに関連付けられていると判定されると（排他ステータスが割り当てられてからそのターゲットアドレスへの競合するメモリアクセスがなかったことを示す）、そのターゲットアドレスは、１つ以上のイベントが監視回路によって監視される、監視されるアドレスのセットのうちの１つとなるように割り当てられる。これは、ステータス情報チェック（ターゲットアドレスが監視されるべきかどうかを決定するためのもの）が、単一の命令で実行できない、より複雑なチェックを必要とするものであっても、アトミックに実装されることを可能にするのに有用である。
【0014】
例えば、監視されるアドレスのセットに特定のアドレスを割り当てる前に、ソフトウェアは、メモリ内の何らかの情報の状態をチェックする必要がある場合があり、これは、特定のアドレスからデータをロードし、１つ以上の命令のシーケンスを使用してデータをチェックすることによって行うことができ、次いで、データの状態が予想通りである場合、そのアドレスを監視されるアドレスのセットに割り当てることによって監視を開始することができる。しかしながら、競合状態（チェックされるアドレスのデータが、アドレスの読み取りからそのアドレスのチェック結果の判定までの間に別のプロセス又はデバイスによって更新される）を回避するために、これらの動作はアトミックに行われる必要があり得る。これは、チェックが単に既知の値に対するデータの単一比較である場合には比較的簡単であり得、その場合、単一の命令がアドレスをロードし、それを比較し、比較が一致した場合はそれを監視されるアドレスのセットに割り当てることが可能であり得る。しかしながら、本発明者は、実際には、ソフトウェアが、アドレスに関連付けられた単一比較条件を超える条件をテストすること、例えば、アドレス指定されたメモリロケーションの異なる部分で複数の要素を潜在的にテストすること、又は単なる単一の同等比較よりも複雑な比較条件を適用することを必要とする場合があり、したがって、これは、監視されるアドレスのセットにアドレスを割り当てるために必要とされる条件が満たされるかどうかを評価するために２つ以上の命令を必要とする場合があることを認識した。上述の監視排他命令のサポートは、排他ステータス設定命令と、それに続くチェックを実装するためのいくつかの命令と、その後の監視排他選択とを含むコードのシーケンスが、アトミックにデータをチェックし、必要な比較動作を実行し、それが成功すると、ターゲットアドレスを、監視回路によって追跡されている監視されるアドレスのセットに昇格させることができるので、ソフトウェアが任意に複雑な比較条件を実装することができる一方で、チェックをアトミックに実行することができることにより依然として競合状態を回避することを意味する。したがって、監視排他命令のＩＳＡサポートを提供することは、依然として任意に複雑なテスト条件を可能にし、データ競合状態を回避するアトミック動作のサポートを提供しながら、監視されるアドレスのセットの構成をソフトウェアのために管理することをより簡単にすることができる。
【0015】
監視回路には、監視されるアドレスのセットのいずれかに関連付けられたデータへの潜在的な更新を示す１つ以上のイベントの監視を実装するための様々な方法が存在し得る。場合によっては、監視回路は、異なる要求側デバイス内のキャッシュ間のコヒーレンシを管理するためにデータ処理システム内に既に提供されている可能性があるいくつかの機能を再利用し得る。そのようなコヒーレンシ方式は、例えば、特定のアドレスのデータがアクセスされるとき、特定のコヒーレンシメッセージ（例えば、メモリアクセス要求／応答又はスヌープ要求／応答）がリクエスタデバイスとインターコネクトとの間で交換されることを必要とする場合があり、インターコネクトは、システム内の異なるロケーションの同じアドレスに対してキャッシュされたデータ間のコヒーレンシを必要に応じて維持する他のリクエスタデバイスにスヌープ要求を送信することができる。場合によっては、監視回路によるイベントの監視は、システム内で交換されるいくつかのスヌープメッセージを傍受し、所与のアドレスが潜在的に更新されているときをスヌープメッセージ／応答から検出することに基づき得る。あるいは、監視回路は、（スヌープ要求自体をチェックするのではなく）そのようなスヌープ要求によってトリガされ得るキャッシュコヒーレンシ状態の変化を検出するために、処理回路に関連付けられたキャッシュ内のキャッシュコヒーレンシ状態の遷移を監視することができる。しかしながら、従来のコヒーレンシ機構とは異なり、特定のリクエスタデバイスでキャッシュされたデータのコヒーレンシ状態の任意の変化、及びコヒーレンシを維持するために異なるデバイス間で交換される任意のスヌープメッセージングが、処理回路上で実行されるソフトウェアに対して透過的であり得、その結果、ソフトウェアは、あるデバイスでキャッシュされたデータが別のデバイスからアクセスされるときに通知されず、監視は監視回路によって実行され、監視回路は、監視されるアドレスのセットのうちの１つ以上に対して任意のイベントが発生したかどうかを示す監視報告インジケーションを、処理回路上で実行されるソフトウェアに対してアクセス可能にすることができる。
【0016】
例えば、この監視報告インジケーションは、処理回路上で現在実行されている処理を中断するために送信される割り込みであってもよく、その結果、処理回路は、どのアドレスが更新された可能性があるかをチェックするための命令（例えば、以下で説明する監視ポーリング命令の１つ以上のインスタンス）を実行することができる。監視報告インジケーション自体が、イベントに遭遇した監視されるアドレスのセットのうちの特定の１つを識別する必要があることは必須ではない。場合によっては、送信される割込みは、どのアドレスがイベントに遭遇したかを区別することなく、監視されるアドレスのセットのいずれか１つに対してイベントが発生したことを示す一般的な割込みであってもよい。あるいは、他のアプローチは、どのアドレスが更新を有したかをチェックするためにチェックされ得る特定のステータス／シンドローム情報（例えば、ソフトウェアアクセス可能なレジスタにストアされ、監視されるアドレスに対してイベントが発生したときに監視回路によって更新される）にも関連付けられている割り込みの形態で監視報告インジケーションを提供し得る。他の例は、イベントが発生したときにプロセッサを中断することはできないが、少なくとも、監視されるアドレスのセットのいずれかが更新に遭遇したかどうかを示すことができ、任意選択で、どのアドレスが更新されたかを報告することもできる、ソフトウェアアクセス可能なレジスタ内のデータを単に利用可能にすることができる。したがって、監視回路が監視報告インジケーションをソフトウェアに対してアクセス可能にすることができる様々な技法があることが理解されよう。
【0017】
場合によっては、監視回路によって検出されるイベントは、アドレスの監視セットのうちの１つに関連付けられたデータが更新されたことを示すこともあるが、データが実際に更新されていない場合であっても別の機会に検出され得る偽陽性イベントである可能性もあるイベントを含む可能性がある。したがって、監視回路によって検出されるイベントは、少なくともいくつかの機会に、データが更新された可能性があるリスクがあることを示し得る任意のイベントであり得る。監視回路は、データが確実に更新されたかどうかを実際に検出することは必須ではない。例えば、時折、監視回路は、対応するデータをまだ更新していないが、他のキャッシュに残っているデータの競合するコピーがないことを保証するためにシステムをプライミングしている（例えば、他のキャッシュのコヒーレンシステータスをチェックする必要がないことにより、複数の後続の更新がより効率的に実行されることができるように、他のリクエスタデバイスにデータへの排他的アクセスを準備させている）だけであり得る別のリクエスタデバイスからの要求の結果として送信されたスヌープ要求に起因して発生した可能性があるキャッシュエントリの無効化（又はキャッシュされたエントリのコヒーレンシ状態の変化）を検出し得る。他の機会には、同じキャッシュエントリの無効化又はコヒーレンシ状態遷移が、実際の更新によって引き起こされる可能性がある。したがって、そのような無効化又はコヒーレンシ状態遷移は、潜在的な更新を示すイベントの例であり得るが、更新がまだ行われていない可能性があるので、偽陽性であり得る。
【0018】
命令デコーダが監視排他命令をデコードしたことに応じて、処理回路は、ソフトウェアに対してアクセス可能になっている監視割り当てステータスインジケーションを返し得、この監視割り当てステータスインジケーションは、ターゲットアドレスが、監視排他命令に応じて監視されるアドレスのセットのうちの１つとなるように正常に割り当てられたかどうかを示す。これは、ターゲットアドレスを、監視されるアドレスのセットに割り当てるための動作を再試行する必要があるかどうかをソフトウェアが決定するのに有用であり得る。
【0019】
監視されるアドレスのセットのうちの１つとなるようにターゲットアドレスを割り当てることが失敗した場合、監視割り当てステータスインジケーションは、割り当ての失敗の理由を示し得る。例えば、監視割り当てステータスインジケーションは、以下の理由のうちの少なくとも２つを区別し得る：排他ステータスが、ターゲットアドレスに対してもはや設定されていない、排他ステータスが、ターゲットアドレス以外のアドレスに対して設定されている、及び監視回路が、利用不可能であるか、又は監視されるアドレスのセットへのアドレスの割り当てを受け入れるようにまだ構成されていない。例えば、監視割り当てステータスインジケーションは、成功した割り当てを示すために割り当てられた１つのエンコーディングと、異なる失敗の理由に対応する複数の他のエンコーディングとを有するマルチビットインジケータであり得る。異なる理由を区別することは、ソフトウェアがどのように進めるべきかを決定するのを助けることができる。
【0020】
いくつかの例では、監視割り当てステータスインジケーションは、それをソフトウェアアクセス可能なレジスタに書き込むことによって、ソフトウェアに対してアクセス可能にされ得る。ソフトウェアアクセス可能なレジスタは、監視排他命令のレジスタフィールドによって指定される宛先レジスタであってもよいし、監視排他命令の命令エンコーディングにおいて指定されているそのレジスタを識別する明示的なレジスタフィールドなしに、監視割り当てステータスインジケーションを書き込むために使用するレジスタであると暗黙的に想定されるデフォルトレジスタであってもよい。
【0021】
ターゲットアドレスは、監視排他命令によって様々な方法で指定することができる。一例では、監視排他命令自体がターゲットアドレスを指定する。例えば、監視排他命令のエンコーディングは、ターゲットアドレスを識別するためのオペランド情報を含み得る。例えば、監視排他命令は、ターゲットアドレスを決定するためのアドレス情報を提供するアーキテクチャレジスタを識別するレジスタ指定子を指定し得る。
【0022】
しかしながら、他の例では、監視排他命令は、それ自体がターゲットアドレスを識別する必要はなく、代わりに、ターゲットアドレスは、監視排他命令よりも前の直近の排他ステータス設定命令によって所与のアドレスとして指定されたアドレスであるとして暗黙的に識別され得る。例えば、特定のアドレスに関連付けられた排他ステータスを追跡するための回路ロジックは、排他ステータスが直近に設定されたアドレスのインジケーションを維持し得、次いで監視排他命令に遭遇すると、このアドレスは、監視排他命令のターゲットアドレスであると想定され得る。排他ステータス追跡ハードウェアによって追跡される直近に設定された排他アドレスのインジケーションは、アドレス自体を明示的に識別する必要はない（ただし、これは１つの選択肢である）。別の選択肢は、アドレスに関連付けられたデータをキャッシュする特定のキャッシュエントリを識別する情報など、アドレスに関連する他の情報を介してアドレスを識別することである。監視排他命令のＩＳＡ定義は、ターゲットアドレスが、以前の排他ステータス設定命令によって排他ステータスが設定された直近のアドレスであることを指定することができるが、どのアドレスが排他ステータスを有する直近のアドレスであったかを処理回路のハードウェアが追跡する特定の方法は、実装固有の方法で様々であり得ることが理解されよう。
【0023】
ターゲットアドレスを、直近の排他ステータス設定命令によって指定された所与のアドレスとして暗黙的に定義することの利点は、これにより、監視排他命令のエンコーディングにおいて他の目的のために使用することができるビット空間が解放されることである。命令エンコーディング空間は多くのＩＳＡにおいて貴重なものであり得、したがって、エンコーディングの効率化は、それらが比較的少数のビットしか節約しないとしても価値があり得る。例えば、ターゲットアドレスに対応するレジスタフィールドをエンコードする必要がないことによって、監視排他命令のエンコーディングは、他の情報を指定するためのレジスタフィールドをサポートすることができる。
【0024】
いくつかの例では、命令デコーダが監視排他命令をデコードしたことに応じて、排他ステータスがターゲットアドレスに関連付けられていると判定されると、処理回路は、ターゲットアドレスに対応する識別子ストレージ構造のエントリに、監視排他命令のオペランドとして指定された識別子値を割り当て得る。例えば、識別子値は、監視排他命令のエンコーディングにおいて即値として指定されてもよいし、監視排他命令のエンコーディングにおいて指定されたレジスタフィールドに基づいて識別されるレジスタから読み出されてもよい。これは、ソフトウェアが、監視されるアドレスのセットに割り当てられているターゲットアドレスを表すための識別子値（ソフトウェアによって任意に選択される）を割り当てることを可能にする。
【0025】
これは、多くの処理システムにおいて、監視を構成しているソフトウェアが仮想アドレスを使用してメモリ内の特定のデータ構造を識別し得ることから有用であり得るが、例えば、監視は、メモリシステム内の特定のロケーションに対応する物理アドレスを使用してアドレスを識別するコヒーレンシメッセージからの情報を再利用し得るため、監視は物理アドレスに基づくこともある。多くのシステムでは、物理アドレスを変換して仮想アドレスに戻す逆アドレス変換のための効率的な機構がない場合があり、したがって、特定の監視される物理アドレスに対して更新が行われたことを監視回路が識別したとき、どの監視されるアドレスが、イベントに遭遇した監視されるセットのアドレスであったかをソフトウェアが識別することを可能にする何らかの情報を監視回路がソフトウェアに対して識別することができる機構を提供することが望ましい場合がある。例えば、ソフトウェアによって割り当てられた識別子は、監視されるメモリ内の複数のキューのうちの１つを識別することができてもよいし、アレイ構造内の要素を識別するためにソフトウェアによって使用されるアレイインデックスであってもよい（識別子の正確な意味はソフトウェア次第であり、データ処理装置のプロセッサアーキテクチャ又はハードウェアの特徴ではない）。
【0026】
したがって、所与の監視されるアドレスに対して１つ以上のイベントのいずれかが発生したことを監視回路が検出すると、監視回路は、イベントが発生した所与の監視されるアドレスに対応する識別子ストレージ構造のエントリにストアされた識別子のインジケーションをソフトウェアに対してアクセス可能にすることができる。これは、（ハードウェア又はソフトウェアにおいてサポートされる範囲に応じて）回路面積及び／又は性能に関してよりコストがかかる可能性がある逆変換機構を実装する必要なく、ソフトウェアが、更新されたメモリ内の関連するロケーションがどれであるかを識別するのに役立つ。
【0027】
識別子ストレージ構造は、異なる方法で実装することができる。場合によっては、識別子ストレージ構造は、複数のエントリを有する専用のアドレス監視追跡構造を含み得、各エントリは、対応する１つの他の監視されるべきアドレスのセットに関連付けられた情報を追跡するためのものである。例えば、アドレス監視追跡構造は、データキャッシュとは別個の、ハードウェアに実装された専用の構造であり得る。アドレス監視追跡構造は、監視される各アドレスに関連付けられたソフトウェア定義識別子を受け入れるのに十分な大きさのエントリを有し得る。アドレス監視追跡構造はまた、特定のエントリ内の監視されるアドレスに対して何らかのイベントが発生したか否かなど、他の情報を追跡してもよい。
【0028】
一方で、他の例では、識別子ストレージ構造は、メモリにストアされたデータ構造を含み得る。例えば、監視排他命令は、識別子ストレージ構造のベースアドレスを識別するための情報を指定するメモリアドレスを提供するレジスタを識別することができるレジスタフィールドを指定し得る（レジスタ内の値は、ベースアドレスを直接識別することができてもよいし、ベースアドレスを決定することができる他の情報、例えば、固定の暗黙的に定義されるオフセットで識別子ストレージ構造のベースアドレスが決まる別のアドレスを識別することができてもよい）。監視排他命令に応じて、アドレス割り当て動作が成功した場合、処理回路は、ベースアドレス（及びターゲットアドレスから導出されたオフセット、又はターゲットアドレスに対応するキャッシュエントリを示すキャッシュセット／ウェイ情報など、ターゲットアドレスに関連する他の情報）を使用して、割り当てられたターゲットアドレスに対応する識別子で更新される識別子ストレージ構造の関連エントリのアドレスを識別することができる。
【0029】
メモリにストアされたデータ構造として識別子ストレージ構造を提供することにより、ソフトウェア提供識別子をストアするための専用のストレージ構造をハードウェア内に設ける必要がないので、監視をサポートするハードウェアコストはより低くなる。識別子ストレージ構造を表すデータ構造からの識別子は、最終的にメモリにストアされ得るが、基礎となるメモリよりも速くアクセスできるようにキャッシュされてもよいことに留意されたい（場合によっては、ライトバックキャッシュにキャッシュされる場合、監視されるアドレスに対してイベントが発生した後、監視回路が後で識別子を読み戻す時点で、メモリ内のバッキングストアが識別子で更新されていることは必須ではない）。例えば、識別子ストレージ構造のサイズは、レベル１（又は後続のレベル）データキャッシュの容量全体を占有しないように選択され得、その結果、レベル１データキャッシュ内に、識別子ストレージ構造の少なくとも一部、並びに監視されるアドレスのデータに対応するキャッシュラインなどの妥当な数の他のデータラインのための余地がある。識別子ストレージ構造がメモリ内の構造である（潜在的にキャッシュされる）アプローチは、ハードウェアで実装するのにより効率的であり得る。
【0030】
ターゲットアドレス直近の排他ステータス設定命令によって指定された所与のアドレスとして暗黙的に指定する、上述の監視排他命令の変形例は、ターゲットアドレス自体を監視排他命令のオペランドとして指定する必要性を回避することにより、命令エンコーディング内の空間が、識別子ストレージ構造のベースアドレスを識別するためのアドレスを識別するためのレジスタフィールドなど、他の情報のために解放されるので、識別子ストレージ構造がメモリベースの構造として実装されることを可能にするのに特に有用であり得る。
【0031】
上述したように、監視されるアドレスのセットに対して関連イベントが発生したときにソフトウェアに対してアクセス可能にされる監視報告インジケーションは様々な形態を有し得るが、場合によっては提供される情報が比較的限定され得、例えば、どのアドレスがイベントに遭遇したかに関するより多くの情報を具体的に識別することなく、単に、監視されるアドレスのセットのいずれかに対して少なくとも１つのイベントが発生したというインジケーションを提供し得る。したがって、いくつかの実装形態では、どのアドレスがイベントに遭遇したかに関するより多くの情報を提供することができる監視ポーリング命令をサポートすることが有用であり得る。命令デコーダが監視ポーリング命令をデコードしたことに応じて、処理回路及び監視回路のうちの少なくとも１つは、監視されるアドレスのセットのうちのどれが１つ以上のイベントに遭遇したかを示す監視ポーリング情報をソフトウェアに対してアクセス可能にし得る。例えば、監視ポーリング情報は、監視ポーリング命令によって識別される宛先レジスタに書き込むことによって、ソフトウェアに対してアクセス可能にすることができる。それから、ソフトウェアは、その宛先レジスタをソースレジスタとして使用して、監視ポーリング命令を処理し、次いで、監視されるアドレスのセットのうちのどれがイベントに遭遇したかに応じてどのように応答するかを決定する、更なる命令を含むことができる。
【0032】
監視排他命令がソフトウェア定義識別子を指定することができ、このソフトウェア定義識別子が、上述のようにアドレス割り当て動作が成功したときに識別子ストレージ構造に割り当てられる実装形態では、監視ポーリング情報はまた、監視回路によって１つ以上のイベントが発生すると判定された監視されるアドレスのセットのうちの少なくとも１つに関連付けられた識別子値も含み得る。したがって、イベントが発生した監視されるアドレスに関連付けられた識別子値は、イベントが発生したことをソフトウェアに通知するために最初に提供される監視報告インジケーションとして必ずしも提供される必要はないが、ソフトウェアがその後監視ポーリング命令を実行すると、ソフトウェアに対して利用可能にされた監視ポーリング情報内に提供され得る。識別子ストレージ構造がメモリベースの構造である実装形態においてこの使用事例をサポートするために、監視ポーリング命令の変形例は、上述のようにこのベースアドレスを識別するための情報を指定する監視排他命令と同様に、識別子ストレージ構造のベースアドレスを指定するための情報をそのオペランドの１つとして指定し得る。
【0033】
監視ポーリング情報に含められ得る別の情報は、１つ以上のイベントが発生した、監視されるアドレスのセット内のアドレスの数を示すカウント値であり得る。場合によっては、このカウント値は、イベントが発生したアドレスの総数を示すことができてもよいし、１つ以上のイベント（ｅｖｅｔｓ）が発生し、ソフトウェアが監視ポーリング命令を実行することによってその特定のアドレスに関する情報の返信をまだトリガしていない、監視されるアドレスのセット内の残りのアドレスの数を示すことができてもよい。例えば、場合によっては、監視ポーリング命令の単一のインスタンスに応じて返される監視ポーリング情報は、一度に単一の監視されるアドレスに関する情報を返すことができ、したがって、監視されるアドレスのセットのうちの２つ以上に対してイベントが発生した場合、これは、イベントが発生した更新アドレスに関する識別子又は他の情報を返すために、監視ポーリング命令の複数のインスタンスが実行されることを必要とし得る。例えば、ソフトウェアは、イベントが発生したと判定された監視される各アドレスに対して反復するループを含み得る。したがって、イベントが発生した、まだチェックされていないアドレスの総数又は残りの数を示すカウント値を返すことによって、監視ポーリング動作の更なる反復を実行することがまだ必要かどうかを判定するために、このカウント値をソフトウェアによって使用することができる。
【0034】
排他設定命令は、所与のアドレスに対して排他ステータスを設定するように処理回路を制御することができる任意の命令とすることができる。しかしながら、一例では、排他ステータス設定命令はロード排他命令である。命令デコーダがロード排他命令をデコードしたことに応じて、処理回路は、所与のアドレスに関連付けられたデータを、ロード排他命令によって指定された少なくとも１つの宛先レジスタにロードし、所与のアドレスに関連付けられた排他ステータスを設定し得る。排他ステータスを設定するとともに、排他ステータスが設定されたアドレスに関連付けられているデータをロードする排他ロード命令をサポートすることによって、所与のアドレスからデータをロードし、そのアドレスを排他としてマークするために別々の命令を発行する必要がないので、これは、監視されるアドレスのセットの構成について上述したものなど、アトミックな動作のセットをサポートするのに有用であり得る。
【0035】
排他ステータス設定命令によって構成することができる排他ステータスを使用する命令の種類は、監視排他命令だけでなくてもよい。ＩＳＡでサポートされる別の種類の命令は、ストアターゲットアドレス及び少なくとも１つのソースレジスタを指定するストア排他命令であり得る。命令デコーダによるストア排他命令のデコードに応じて、処理回路は、排他ステータスがストアターゲットアドレスに関連付けられているかどうかを判定し、関連付けられている場合、少なくとも１つのソースレジスタからのデータをストアターゲットアドレスに関連付けられたメモリロケーションにストアし得る。したがって、監視排他命令は、ロード／ストア排他命令対を処理するために既にサポートされている可能性がある排他ステータスを追跡するために同じインフラストラクチャを再利用し得、それゆえ、ロード／ストア排他的命令を既にサポートしているアーキテクチャと比較して、比較的少ない追加コストで実装することができる。
【0036】
上述の技法は、上述の命令デコーダ、処理回路及び監視回路を実装するために設けられたハードウェア回路を有するデータ処理装置内で実装され得る。しかしながら、同じ技法はまた、ホストデータ処理装置上で実行されてターゲットコードの実行のための命令実行環境を提供するコンピュータプログラムで実装されてもよい。そのようなコンピュータプログラムは、ホストデータ処理装置自体がそのアーキテクチャをサポートしていなくても、特定の命令セットアーキテクチャを実際にサポートするハードウェア装置上に提供されるアーキテクチャ環境をシミュレーションするようにホストデータ処理装置を制御し得る。よって、コンピュータプログラムは、ターゲットコードのプログラム命令をデコードして、ターゲットコードのプログラム命令に応じてデータ処理を実行するようにホストデータ処理装置を制御する（例えば、ターゲットコードの各命令を、同等の機能性を実行するホストのネイティブ命令セット内の１つ以上の命令のシーケンスにマッピングする）命令デコードプログラムロジックを含み得る。命令デコードプログラムロジックは、上述したように、監視排他命令及び排他ステータス設定命令をサポートし得る。また、命令デコードプログラムロジックは、前述した他の命令（例えば、監視ポーリング命令、ロード排他命令、ストア排他命令）もサポートし得る。計算プログラムはまた、上述の処理回路によって実行されるクリアに相当する方法で排他ステータスをクリアする排他ステータスクリアプログラムロジックと、上述の監視回路の機能に相当する監視プログラムロジックとを含み得る。シミュレーションプログラムでは、ターゲットコードによってアドレス指定されたアドレス空間は、ホストプロセッサによって使用されるホストアドレス空間と同じではない可能性があるシミュレーションされたアドレス空間におけるものである可能性があるので、メモリへのアクセスは、シミュレーションされた形でエミュレートされ得る。また、シミュレーションは、シミュレーションされたアーキテクチャによって定義されるレジスタを、ホストプロセッサのホストストレージ（例えば、ホストレジスタ又はホストメモリ）へのアクセスを使用してシミュレーションし得る。そのようなシミュレーションプログラムは、例えば、ある命令セットアーキテクチャに対して書き込まれたレガシーコードが、異なる命令セットアーキテクチャをサポートするホストプロセッサ上で実行されている場合に有用である。また、シミュレーション実行環境上でソフトウェアを実行することにより、新しいアーキテクチャをサポートするハードウェアの進行中の開発と並行してソフトウェアのテストを可能にすることができるため、シミュレーションは、新しいアーキテクチャバージョンをサポートするハードウェアを処理する前に、命令セットアーキテクチャの新しいバージョンのソフトウェア開発を開始することを可能にすることができる。シミュレーションプログラムは記憶媒体に記憶されてもよく、この記憶媒体は、非一時的記憶媒体であってもよい。
【0037】
図１は、複数のリクエスタデバイス４、６、８と、それぞれのリクエスタデバイスのキャッシュ１２にキャッシュされたデータ間のコヒーレンシを管理するためのインターコネクト１０とを含むデータ処理システム２（例えば、集積回路又はシステムオンチップ）の一例を概略的に示す。インターコネクト１０はまた、共有メモリ１４へのアクセスを制御する。図１に示すように、リクエスタデバイス４、６、８のいずれかからアクセスすることができる、インターコネクト１０に結合された２つ以上のメモリモジュール１４があってもよい。この例では、リクエスタデバイスは、特定の命令セットアーキテクチャ（ＩＳＡ）に従って定義された命令の実行をサポートする要素である１つ以上の処理要素４、６を含む。処理要素４、６は、１つ以上のキャッシュ１２を含むことができる（図１は、簡潔にするために単一のキャッシュのみを示すが、キャッシュは、キャッシュの複数レベルの階層構造として実装され得る）。処理要素４、６は、例えば、汎用処理を実行するための中央処理ユニット（ＣＰＵ）、又はグラフィックス処理を実行するためのグラフィックス処理ユニット（ＧＰＵ）であり得る。システムはまた、自身のキャッシュ１２を有さないかもしれないが、処理要素４、６によって明示的に制御されることなくメモリにアクセスする要求を発行することができるようにメモリ１４へのダイレクトメモリアクセス（ＤＭＡ）を有し得る、１つ以上のリクエスタデバイス８を含んでもよい。例えば、デバイス８は、ほんの数例を挙げると、ネットワークを介したデータの送信及び受信を制御するためのネットワークインタフェースコントローラ（ＮＩＣ）、画面上のデータの表示を制御するためのディスプレイコントローラ、メモリと周辺デバイスとの間のデータの転送を制御するためのダイレクトメモリアクセス（ＤＭＡ）コントローラなどの入力／出力（Ｉ／Ｏ）デバイスであり得る。
【0038】
インターコネクト１０は、キャッシュ１２にキャッシュされたデータ間のコヒーレンシを維持する役割を果たす。コヒーレンシプロトコルは、１つのリクエスタが所与のアドレスにアクセスしたことに対してシステムがどのように応じるかを支配する規則を定義するために使用され、他のリクエスタからの同じアドレスへの後続のアクセスが最初のリクエスタからの要求の結果と一致するデータを見ることを保証し得る。例えば、コヒーレンシプロトコルは、キャッシュ１２に、又はインターコネクト１０内に設けられたシステムキャッシュ１６にストアされたデータに関連付けられ得る複数のコヒーレンシ状態を定義するだけでなく、複数の要求及び応答メッセージ、並びに様々な種類のメッセージがいつ生成されるべきかについてのプロトコルを定義し得る（システムキャッシュ１６は、リクエスタ間で共有され、データをメモリ１４から取得しなければならない場合と比較してデータへのより高速なアクセスを提供する）。例えば、１つの処理要素４が、そのキャッシュ１２内の特定のアドレスからデータを読み出すか又は書き込む要求を開始するとき、現在のコヒーレンシ状態に応じて、これは、必要であれば、他のリクエスタ内のキャッシュ１２にスヌープ要求を送信して、そのリクエスタのキャッシュにおけるデータのコヒーレンシ状態を照会するか、又は必要であれば、そのリクエスタのキャッシュからのデータの無効化をトリガし得る、インターコネクトへの様々な要求をトリガし得る。場合によっては、インターコネクトは、どのリクエスタが所与のアドレスからのデータをキャッシュしているかを少なくとも部分的に追跡し、あるリクエスタのキャッシュ１２が特定のアドレスからのデータをキャッシュしていないことが分かっている場合、一部のスヌープトラフィックが除去されることを可能にする、スヌープフィルタ（図１に示すように、システムキャッシュ１６と組み合わせることができるが、別個の要素とすることもできる）を有し得る。コヒーレンシを維持するために、任意の既知のコヒーレンシプロトコルを使用することができる。使用され得るコヒーレンシプロトコルの例は、英国、ケンブリッジのＡｒｍ（登録商標）Ｌｉｍｉｔｅｄによって提供されるＡＭＢＡ（登録商標）４ ＡＣＥ及びＡＭＢＡ（登録商標）５ ＣＨＩコヒーレンシプロトコルであるが、コヒーレンシを維持するために他のコヒーレンシプロトコルも使用され得ることが理解されよう。
【0039】
図１に示されるようなシステムでは、異なるリクエスタ間の相互作用は、メモリシステム内の共有データ構造にアクセスすることによって実行され得る。例えば、デバイス８がネットワークインタフェースコントローラである場合、データがネットワークから受信されると、データのキューが、受信されたパケットに基づいて更新され得る。処理要素４、６のうちの１つの上で実行されるソフトウェアは、処理されるべき利用可能なデータがあるかどうかをチェックし、もしあれば、対応するアクションを実行するために、これらのキューをチェックすることを必要とし得る。監視されるキューの数が特に多くない場合、ソフトウェアが単にロード命令を周期的に実行して、各キューにマッピングされたメモリ内のアドレスを読み取り、処理を必要とするものが変化したかどうかをチェックすることは、実現可能であり得る。しかしながら、監視されるキューの数は、例えば１００を超えるほど、大きい場合があり、したがって、メモリ内のアドレスのそのようなポーリングは、大きなオーバーヘッドを招き得る。以下の例は、メモリ内のアドレスを監視してアドレスが更新されたかどうかをチェックする性能コスト及び電力コストを低減するために、処理要素４、６のハードウェア実装アーキテクチャにおいてサポートされ得るアドレス監視機能を説明する。特定のアドレスに対する更新を監視し、その結果、それらのアドレスのいずれかが更新されたときにインジケーションがソフトウェアに提供されるように、ソフトウェアによって構成することができるいくつかのハードウェアを提供することにより、これは、ソフトウェアがそれらのアドレスを繰り返し読み取ることを明示的に必要とすることを回避する。実行される他の処理が存在しない場合、これは、処理要素４、６が、ある時間省電力モードに入ることを可能にし、監視されるアドレスの１つが更新されたときにイベントが報告されるのを待ち、その結果、電力を節約することができ、これは、ソフトウェアが、監視されるアドレスに対応するメモリ内のロケーションにアクセスするために、明示的な読み取り要求を発行し続ける必要がある場合には不可能であろう。
【0040】
図１は、処理要素４、６上で実行されるソフトウェアが、ネットワークコントローラなどの別のリクエスタデバイス８によってデータ構造が更新されるのを待っているシナリオを示すが、同じ処理要素４、６上で実行される複数のソフトウェアプロセスが、共有メモリ１４内のアドレスにおけるデータに対する更新を使用して通信しているときに、同様のアドレス監視問題が生じる可能性があり、したがって、監視が別のリクエスタデバイスによる変更に対するものであることは必須ではない。
【0041】
図２は、処理要素４、６のうちの１つの特徴をより詳細に示す。システム内の処理要素４、６の全てが同じ設計を有することは必須ではなく、例えば、同じＩＳＡをサポートするが異なるマイクロアーキテクチャ実装を有する処理要素を含む非対称型マルチプロセッサシステムを提供することが可能であることは理解されるであろう。したがって、全ての処理要素が図２に示す特徴を有することは必須ではない。例えば、全ての処理要素がアドレス監視回路３６を含む必要はない。
【0042】
処理要素４、６は、メモリ１４から又は命令キャッシュ（命令キャッシュは図１及び図２に示されていないが、処理要素内に設けられ得る）からフェッチされたプログラム命令（特定の命令セットアーキテクチャに従って定義される）を受信するための命令デコーダ２０を含む。命令デコーダ２０は、フェッチされた命令をデコードして、命令により表された動作を実行するように処理回路２２を制御するための制御信号を生成する。処理回路２２は、命令のオペランド及び処理回路２２によって処理された命令の結果をストアするために使用され得るレジスタ２４へのアクセスを有する。処理回路２２は、算術命令又は論理命令を実行するための算術／論理ユニット（ＡＬＵ）、又は分岐命令を実行するための分岐ユニットなど、異なるタイプの命令を実行するための複数の実行ユニットを含み得る。簡潔にするために、メモリシステム（メインメモリ１４及び任意のキャッシュ１２、１６を含む）からレジスタ２４にデータをロードするためのロード命令、又はレジスタ２４からメモリシステム１２、１４、１６にデータをストアするためのストア命令を実行するためのロード／ストアユニット２６を示す以外は、異なるタイプの実行ユニットは図２に示されていない。メモリ管理ユニット２８は、メモリ保護及び／若しくはアドレス変換機能を提供して、メモリアドレス空間内のどのアドレスが、処理回路２２上で実行される特定のソフトウェアによってアクセスされることを許可されるかを制御し、かつ／又はソフトウェアによって指定される仮想アドレスと、メモリシステム内のロケーションを識別するために使用される物理アドレスとの間の変換を管理するために提供され得る。図２は、処理要素のキャッシュの一例として単一のデータキャッシュ１２を示しているが、レベル１データキャッシュ及びレベル２キャッシュ（又は追加のレベルのキャッシュ）など、複数レベルのキャッシュを特定の処理要素専用に設けることが可能であることは理解されよう。したがって、キャッシュ１２への参照は、マルチレベルのキャッシュ階層構造を含み得る。
【0043】
処理要素は、特定のアドレスに関連付けられた排他ステータスを追跡するための排他ステータス追跡回路３０を有する。排他ステータスのために選択されるアドレスは、処理回路２２上で排他ステータス設定命令（例えば、図３に関して以下で説明されるようなロード排他命令）を実行することによって選択され得る。所与のアドレスを指定して排他ステータス設定命令が実行されると、その所与のアドレスを示す追跡アドレスインジケーション３２がストアされ、排他ステータスインジケーション３４は、追跡アドレスインジケーション３２によって示される所与のアドレスが排他ステータスを有することを示すように設定される。その後、排他ステータス追跡回路３０は、追跡アドレスへの競合するメモリアクセスを示す可能性のあるイベントを監視し、そのうちの１つのイベントが検出されると、排他ステータスは、排他ステータスインジケータ３４の状態を変更することによってクリアされる。特定の命令は、追跡アドレスが依然として排他ステータスを有するものとして示されているか否かをテストし得、そのアドレスが排他ステータスを有するものとして示されたままであるか否かを条件とする動作を実行するように処理回路２２を制御し得る。これは、追跡アドレスを伴う最初の動作と、後続の動作との間で特定の命令のシーケンスがアトミックに実行されることを確実にするのに有用であり得、これは、複数のリクエスタがメモリ内のアドレスへの競合アクセスを行い、それらのアクセスのうちの１つが失われる、又はそれらのアクセスのうちの１つが潜在的に期限切れのデータにアクセスするという影響をもたらし得るときに、データ競合状態を回避するのに有用であり得る。
【0044】
しかしながら、排他ステータス追跡回路３０は、それが監視することができるアドレスの数において比較的制限され得、例えば、一度に単一のアドレスを追跡することに制限される。したがって、より広い監視されるアドレスのセットの監視を実行し、以前に構成された監視されるアドレスのセットのうちの１つがそのアドレスにおけるデータに対する潜在的な更新を示すイベントに遭遇したときにソフトウェアに報告するために、アドレス監視回路３６もまた提供される。例えば、図２に示すように、アドレス監視回路３６は、処理回路２２に割り込み信号を送信して、現在実行されている処理を中断し得（あるいは、処理回路が省電力状態にあった場合、割り込みは処理回路をウェイクアップさせ得る）、その結果、ソフトウェアは、どのアドレスが状態を変更したかを識別し、どのアドレスが更新されたかに基づいて後続の処理を実行するための命令を実行することによって、割り込みに応じ得る。これは、上述の（discussed approve）キュー監視使用事例をサポートするのに有用であり得るが、他の目的のためにも使用され得る。アドレス監視回路３６については以下でより詳細に説明するが、最初に排他ステータス追跡についてより詳細に説明する。
【0045】
図３は、排他ステータス設定命令の一例であるロード排他命令ＬＤＸＲの処理を示す。ロード排他命令は、宛先レジスタＸｄと、所与のアドレスを示す値をストアするアドレスオペランドレジスタＸｎとを指定する。図３のステップＳ１００において、命令デコーダ２０はロード排他命令をデコードする。ロード排他命令に応じて、命令デコーダは、図３の後続のステップを実行するように処理回路２２を制御する。ステップＳ１０２において、処理回路は、所与のアドレスに関連付けられた排他ステータスを設定する。例えば、追跡アドレスインジケーション３２は、所与のアドレスが識別されることを可能にする情報を指定するように更新され得、排他ステータスインジケータ３４は、排他ステータスが存在することを示す特定の値に設定され得る。場合によっては、追跡アドレスインジケーション３２は、所与のアドレスに対応する物理アドレスを指定するように更新されてもよい。一方で、追跡アドレスインジケーションが、例えば、所与のアドレスのデータに関連付けられたデータキャッシュ１２内の特定のエントリを識別することによって、所与のアドレスを間接的に識別することも可能である。例えば、追跡アドレスインジケーション３２は、セットアソシアティブ割り当てポリシーを使用して実装されたキャッシュ内の関連エントリを識別するためのキャッシュセット／ウェイ識別子を指定する情報であってもよい。追跡アドレスインジケーションのためのそのようなフォーマットは、いくつかの実装形態では、排他ステータスがクリアされる必要があるかどうかを識別するために、スヌープ又はコヒーレンシ状態遷移が特定のアドレスに対して検出されたときにキャッシュから返された情報と比較するのに、より簡単であり得る。ロード排他命令、及びその命令によって表される排他ステータス設定動作のエンコーディングは、処理システムによってサポートされるＩＳＡで指定され得るが、排他ステータスが特定のアドレスに対して設定されているかどうかを追跡するために使用される排他ステータス追跡情報３２、３４の正確なフォーマットは、アーキテクチャによって規定されないことがあり、実装ごとに異なり得ることは理解されよう。したがって、情報３２、３４の正確なフォーマットは必須の特徴ではない。一般に、所与のアドレスに対して排他ステータスが依然として設定されているか否かをシステムが判定することを可能にし得る任意の情報がストアされ得る。
【0046】
ステップＳ１０４において、ロード排他命令に応じて、処理回路６のロード／ストアユニット２６は、ロード動作を実行して、所与のアドレスに関連付けられたデータを、キャッシュ１２又はメモリ１４から、ロード排他命令において指定されたレジスタ指定子Ｘｄに基づいて識別される宛先レジスタにロードする。図３のステップＳ１０２及び１０４は順番に示されているが、他の実装形態は、これらのステップを逆の順序で、又は並列に実行し得ることは理解されよう。
【0047】
図３は、排他ステータス設定命令の一例としてロード排他命令を示す。いくつかのＩＳＡはまた、ターゲットアドレスに関連付けられたデータのロードをトリガすることなく、排他ステータスがアドレスに対して設定されることを可能にする排他ステータス設定命令もサポートし得る。
【0048】
図４は、競合するメモリアクセスを示し得るイベントを監視しながら排他ステータスインジケータ３４を維持するために、排他ステータス追跡回路３０によって実行されるステップを示す。ステップＳ１１０において、排他ステータス追跡回路３０は、排他ステータスが設定されている、追跡アドレスインジケーション３２によって示される所与のアドレスに対して、競合するメモリアクセスが行われた可能性があることを示すイベントが検出されたかどうかを検出する。例えば、このイベントは、別のリクエスタが、所与のアドレスに関連付けられたロケーションへのデータの書込みを要求したこと、又は所与のアドレスに関連付けられてキャッシュされている可能性がある、キャッシュ１２からの任意のキャッシュされたデータの無効化若しくはクリアを要求したことを示す、インターコネクト１０から受信されたスヌープ要求の検出であってもよい。また、競合するメモリアクセスを示すイベントは、所与のアドレスに関連付けられたデータキャッシュ１２内のキャッシュエントリの無効化（これは、そのアドレスのデータを更新し得る別のデバイスからのスヌープによって潜在的にトリガされ得る）、又は所与のアドレスに関連付けられたキャッシュエントリのコヒーレンシ状態の特定の遷移（例えば、「排他」コヒーレンシ状態から「共有」又は「無効」コヒーレンシ状態への遷移であり、「排他」コヒーレンシ状態は、対応するキャッシュされたデータが、そのキャッシュを所有するリクエスタによって、インターコネクトにスヌープを発行して他のキャッシュ１２内に対応するキャッシュされたデータがあるかどうかをチェックすることなく、更新され得ることを示し、「共有」コヒーレンシ状態は、対応するキャッシュされたデータは有効であるが、このキャッシュを所有するリクエスタがそのキャッシュされたデータを更新するには、他のリクエスタが対応するデータを保持しているかどうかのチェックを可能にするためのメッセージがインターコネクト１０に送信されることを必要とすることを示し、「無効」コヒーレンシ状態は、対応するアドレスの有効なデータをキャッシュが保持していないことを示す）であり得る。ここで言及される「排他」コヒーレンシ状態は、インターコネクト１０及びキャッシュ１２、１６によって使用されるコヒーレンシプロトコルに従って定義されるコヒーレンシ状態のセットのうちの１つを指し、これは、排他ステータス追跡回路３０によって示される排他ステータスに対して直交性の特性であることに留意されたい。したがって、キャッシュエントリは、対応するアドレスが排他ステータス追跡回路３０によって排他として追跡されない場合であっても、排他コヒーレンシ状態を有するものとしてマークされ得る。同様に、アドレスは、キャッシュ１２内の対応するキャッシュデータが排他コヒーレンシ状態を有するものとしてマークされていない場合であっても、排他ステータス追跡回路３０によって排他として追跡され得る。
【0049】
排他ステータスが設定されている所与のアドレスへの競合するメモリアクセスを示すそのようなイベントがステップＳ１１０において検出されると、ステップＳ１１２において、排他ステータス追跡回路３０は、排他ステータスインジケータ３４の状態を切り替えることによって、そのアドレスの排他ステータスをクリアする。これにより、処理回路は、排他ステータスが依然として設定されていることを条件として動作が実行されることを示すエンコーディングを有する後続の命令に対して、その動作が実行されるべきでないことを決定することができる。これは、条件付き動作の実行が、ロード排他命令又は他の排他ステータス設定命令以降に所与のアドレスへの介在するメモリアクセスがなかったことに依存し得ることを意味し、これは、アトミックな動作のセットを実装するために有用であり得る。競合するメモリアクセスを示すイベントは、追跡アドレスに対して排他ステータスがクリアされることにつながり得る唯一のタイプのイベントではない場合があることは理解されよう。排他ステータス追跡回路３０は、限られた数のアドレス（例えば、図２の例では単一のアドレスのみ）に対して排他ステータスを追跡するための有限の容量しか有しないことがあるので、異なるアドレスを指定する別のロード排他命令を実行すると、以前に追跡されたアドレスのインジケーション３２が新しいアドレスに対するインジケーションで上書きされることにより、以前に追跡されたアドレスに対する排他ステータスがクリアされる可能性がある。また、割り込み又は例外が発生すると、これにより、排他ステータス追跡回路３０は、以前に追跡されたアドレスの排他ステータスをクリアする可能性がある。したがって、追跡アドレスへの競合するメモリアクセス以外に、排他ステータスを失わせる他のイベントが存在する可能性がある。
【0050】
図５は、ストアターゲットアドレスによって識別されるメモリシステムロケーション１２、１４、１６にデータをストアするためのストア動作を処理回路２２が実行することを要求するためにソフトウェアによって使用され得るストア排他命令ＳＴＸＲの処理を示し、ストアは、そのストアターゲットアドレスが排他ステータス追跡回路３０によって依然として排他と識別されていることを条件とする。ステップＳ１２０において、命令デコーダ２０はストア排他命令をデコードする。ストア排他命令は、宛先レジスタＸｄ、ソースレジスタＸｓ、及びアドレスオペランドレジスタＸｎを指定する。アドレスオペランドレジスタは、ストアターゲットアドレスを決定するために使用され得る値をストアする。ストア排他命令に応じて、ステップＳ１２２において、処理回路２２は、排他ステータスが依然としてストアターゲットアドレスに関連付けられているか否かを判定するように制御される。したがって、追跡アドレスがストアターゲットアドレスと一致するかどうかを判定するために、追跡アドレスインジケーション３２内の情報が、ストアターゲットアドレスから導出された情報と比較され得、また、排他ステータスインジケータ３４も、排他ステータスが設定されていることを示す値を有するかどうかを判定するためにチェックされる。排他ステータスが設定されているとともに、ストアターゲットアドレスが、排他ステータスが設定されているアドレスと一致する場合、ステップＳ１２４において、ロード／ストアユニット２６は、続けてストア動作を実行して、ソースレジスタＸｓからのデータを、ストアターゲットアドレスに関連付けられたメモリロケーションにストアする。ステップＳ１２６において、ストアターゲットアドレスに対する排他ステータスがクリアされ、ステップＳ１２８において、宛先レジスタＸｄが、ストア動作が成功したことを示すステータス値に設定される。 対照的に、ステップＳ１２２において、ストアターゲットアドレスが排他として設定されていないと判定された場合（例えば、ストアターゲットアドレスが、追跡アドレスインジケーション３２によって示された追跡アドレスと一致しなかった場合、又は排他ステータスインジケータ３４がクリアされた場合）、ステップＳ１３０において、ストア動作が省略され、Ｓ１３２において、宛先レジスタＸｄが、ストア動作が失敗したことを示すステータス値に設定される。
【0051】
したがって、宛先レジスタＸｄに書き込まれたステータス値は、ストアが成功したかどうか、ひいてはストアを再試行する必要がある（及び場合によっては以前の動作も再試行する必要があり得る）かどうか、又はストア以降も処理を続けることができるかどうかを判定するためにソフトウェアによって使用され得る。これは、ロード以降に介在するメモリアクセスが存在しなかった場合にのみストアが行われることを保証するために、ロード排他命令及びストア排他命令によって境界付けられた、アトミックな動作のセットが定義されることを可能にするのに有用であり得る。
【0052】
排他ステータス追跡回路３０によって追跡される排他ステータスはまた、特定のアドレスに対する更新を監視するようにアドレス監視回路３６をソフトウェアが構成することを可能にするために使用され得る監視排他命令のために使用されてもよい。図６は、監視排他命令ＭＯＮＸの３つの代替的な変形例を示す。異なる実装形態は異なる選択肢をサポートし得、したがって、これらの変形例のいずれか１つ以上が所与の実装形態においてサポートされ得る。
【0053】
第１の変形例では、監視排他命令ＭＯＮＸは、ステータスインジケーションで更新される宛先レジスタＸｄを指定する。上述のストア排他命令と同様に、ステータスインジケーションは、監視排他動作が成功したか否かのインジケーションを提供し得るが、上述のストア排他命令とは異なり、監視排他命令では、ステータスインジケーションは、パス／フェイルのバイナリインジケーションを提供するだけでなくそれ以上のことを行い得るが、失敗の場合には、２つ以上の異なる可能な失敗の理由を潜在的に区別する、失敗の理由に関する情報を提供することができる。変形例１では、監視排他命令はまた、監視回路３６によって追跡される、監視されるアドレスのセットに割り当てられることが求められるターゲットアドレスを決定するための情報をストアするアドレスレジスタＸｎを識別するレジスタフィールドも指定する。
【0054】
変形例２では、宛先レジスタＸｄ及びアドレスレジスタＸｎは変形例１と同じであるが、監視排他命令はまた、識別子構造に割り当てることができるソフトウェア定義識別子値を提供するために使用することができる追加のソースレジスタＸｓも指定するので、監視されるアドレスに対してデータが更新されたことを監視回路３６が識別すると、どのアドレスが変化したかをソフトウェアが識別できるように、ソフトウェア定義識別子を返すことができる。
【0055】
監視排他命令ＭＯＮＸの変形例３は、変形例２と同じように宛先レジスタ及びソースレジスタＸｄ、Ｘｓを指定するが、変形例３では、アドレスレジスタＸｎを使用して示されるアドレスは、ターゲットアドレス自体を示す代わりに、（以下で図９に関して更に説明されるように）ソフトウェア定義識別子を追跡するために使用される識別子ストレージ構造のベースアドレスを識別するための情報を示す。この例では、監視されるアドレスのセットに割り当てられるターゲットアドレスは、監視排他命令自体にエンコードされないが、その代わりに暗黙的であり、直近に実行された排他ステータス設定命令によって指定されたアドレス（例えば、監視排他命令と同じスレッド内の直近のロード排他命令によって指定されたアドレス）として定義される。例えば、ターゲットアドレスは、排他ステータス追跡回路３０によって識別された追跡アドレスインジケーション３２に基づいて識別され得る。
【0056】
図６のフローチャートは、監視排他命令ＭＯＮＸの３つの変形例のいずれかの処理を示す。ステップＳ１５０において、命令デコーダ２０は、監視排他命令をデコードし、処理回路２２、及びアドレス監視回路３６又は排他ステータス追跡回路３０などのシステムの他の要素を、図６の残りのステップに示される動作を実行するように制御するための信号を生成する。
【0057】
ステップＳ１５２において、監視排他命令に応じて、処理回路は、排他ステータスが監視排他命令に関連付けられたターゲットアドレスに関連付けられているか否かを判定する。変形例１及び２では、ターゲットアドレスは、監視排他命令によって指定されたアドレスオペランドレジスタＸｎにストアされた値に基づいて識別される。変形例３では、ターゲットアドレスは、直近の排他ステータス設定命令によって指定された所与のアドレスである。したがって、変形例１又は２では、追跡アドレスインジケーション３２と監視排他命令のターゲットアドレスとの間の比較を実行して、それらが一致するかどうかをチェックし得、また、排他ステータスインジケータ３４をチェックして、ターゲットアドレスが排他ステータスを有するかどうかを判定し得る。変形例３では、監視排他命令のターゲットアドレスが、直近に追跡された排他アドレスと一致することが暗に示され得、したがって、変形例３では、排他ステータスインジケーション３４をチェックすることはアドレス比較なしで十分であり得る。いずれにしても、排他ステータスが、監視排他命令に関連付けられたターゲットアドレスに関連付けられていると判定されると、ステップＳ１５４において、処理回路はまた、監視回路３６が利用可能であり、監視のアドレスのセットへのアドレスの割り当てを受け入れるように構成されているかどうかも判定する。いくつかのシステムは、電力を節約するために、アドレス監視回路３６が無効にされるか又はパワーダウンされることをサポートし得、したがって、アドレス監視回路３６は常に利用可能であるとは限らないことがある。また、場合によっては、アドレス監視回路３６を使用できるようになる前に、特定の制御パラメータをセットアップする必要がある場合があり、したがって、それがまだ行われていないと、監視回路は、監視されるアドレスのセットへのアドレスの割り当てを受け入れるようにまだ構成されていないことがある。
【0058】
ステップＳ１５４において、監視回路が利用可能であり、監視されるアドレスのセットへのアドレスの割り当てを受け入れるように構成されていると判定されると、ステップＳ１５６において、アドレス割り当て動作を実行することができ、したがって、ターゲットアドレスは、アドレス監視がアドレス監視回路３６によって実行される、監視されるアドレスのセットのうちの１つとなるように割り当てることができる。監視排他命令が変形例２又は３である場合、ステップＳ１５８において、処理回路はまた、命令のソースレジスタＸｓから読み取られた識別子値を、ターゲットアドレスに対応する識別子ストレージ構造のエントリに割り当てる。以下で図８及び図９に関して説明するように、この識別子ストレージ構造を実装する様々な方法が存在し得る。また、アドレス割り当て動作を実行することができる場合、ステップＳ１６０において、排他ステータス追跡回路３０によって追跡される排他ステータスは、ターゲットアドレスに対してクリアされる（監視排他命令が、排他ステータスインジケーションを使用して管理されているアトミックな動作のセットを完了しているので）。また、ステップＳ１６２において、命令の宛先レジスタＸｄは、アドレス割り当て動作が成功したことを示す監視割り当てステータスインジケーションに設定される。
【0059】
一方、ステップＳ１５２において、ターゲットアドレスが排他ステータスを有していないと判定された場合、又はステップＳ１５４において、監視回路が利用不可能であったか、若しくはアドレスの割り当てを受け入れるように構成されていなかった場合、ステップＳ１６４において、アドレス割り当て動作は省略され、したがって、ステップＳ１５６、Ｓ１５８、Ｓ１６０、及びＳ１６２のいずれも実行されず、代わりに、ステップＳ１６６において、宛先レジスタＸｄは、アドレス割り当て動作が失敗したことを示す異なる値を有する監視割り当てステータスインジケーションに設定される。
【0060】
場合によっては、監視割り当てステータスインジケーションは、成功したアドレス割り当て動作を示す１つの値（例えば、０）と、失敗したアドレス割り当て動作を示す別の値（例えば、１）とを有し得る単一ビット値であり得る。
【0061】
しかしながら、アドレス割り当て動作を実行できなかった場合、失敗の理由に関するより多くの情報を提供し得るマルチビットの割り当てステータスインジケーションを提供することも可能である。例えば、監視割り当てステータスインジケーションが０に設定されると、これは、成功したアドレス割り当て動作を示すことができ、一方、非０の値は、失敗の様々な理由を示し得る。例えば、排他ステータスがターゲットアドレスに関連付けられていないと判定されたことにより、アドレス割り当て動作が失敗した場合、監視割り当てステータスインジケーションは１に設定されることができ、一方、ステップＳ１５４において監視回路が利用不可能である若しくは構成されていないと判定された、又は、変形例１若しくは２の場合、監視排他命令のターゲットアドレスが、排他ステータス追跡回路３０の追跡アドレスインジケーション３２によって追跡されたアドレスと一致しないなどの他の理由に対して、２以上の監視割り当てステータスインジケーションが使用され得る。当然のことながら、監視割り当てステータスインジケーションの他のエンコーディングも使用され得る。
【0062】
図６は連続的なステップのシーケンスを示しているが、ステップは並べ替えられてもよいし、並列に実行されてもよいことは理解されるであろう。例えば、ステップＳ１５２及びＳ１５４は、交換されてもよいし、並列に実行されてもよい。また、割り当て動作が成功すると実行されるステップＳ１５６、Ｓ１５８、Ｓ１６０、Ｓ１６２における様々な動作は、任意の順序で、又はこれらのステップのうちの２つ以上を並列にして実行されてもよい。
【0063】
この監視排他命令は、ソフトウェアが、監視されるアドレスのセット内で特定のアドレスが監視を必要とするかどうかを判定するために、所与のアドレスにおける単一の値を単に比較するよりも複雑なチェックを実行することを可能にするのに有用であり得る。例えば、これは、メモリ内の特定のソフトウェアキューが監視を必要とするかどうかを解明するために、データ構造の複数の要素をテストするのに有用であり得る。そのようなより複雑なチェックは、単一の命令で実行することができない可能性がある比較的柔軟な比較動作を必要とする可能性がある。したがって、チェックを実行するためにデータがメモリから読み取られる必要がある場合、チェックが完了する時間まで、他のリクエスタがその間に関連データの一部を更新していなければ、結果として得られる結論は信頼可能であり得るので、どのようにそれらの比較をアトミックに実行するかについての課題が生じ得る。
【0064】
したがって、ここで説明する監視排他命令のための命令セットアーキテクチャサポートを定義することによって、ソフトウェアは次のように一連のコードを定義することができる。
・上で論じたロード排他命令を使用して、チェックされるデータをロードし、関連するアドレスを排他としてマークすることができる。
・１つ以上の更なる命令を実装して、関連する比較動作を定義することができる。例えば、これは、様々な算術命令、論理命令、又は比較命令を含んでもよい。
・比較動作が成功した場合、監視排他命令を使用して、ロード排他動作に関連付けられているアドレスを、そのアドレスが依然として排他ステータスを有するものとしてマークされていることを条件として、アドレス監視機能実装３６に昇格させることができる。
・上で論じたロード排他命令を使用して、チェックされるデータをロードし、関連するアドレスを排他としてマークすることができる。
・１つ以上の更なる命令を実装して、関連する比較動作を定義することができる。例えば、これは、様々な算術命令、論理命令、又は比較命令を含んでもよい。
・比較動作が成功した場合、監視排他命令を使用して、ロード排他動作に関連付けられているアドレスを、そのアドレスが依然として排他ステータスを有するものとしてマークされていることを条件として、アドレス監視機能実装３６に昇格させることができる。
【0065】
監視排他命令は、監視されるアドレスのセットにアドレスを割り当てるために命令デコーダ２０及び処理回路２２によってサポートされる唯一の命令である必要はない。アドレスを、そのアドレスが排他ステータスを有するかどうかに依らず、監視されるセットに割り当てる命令をサポートすることも可能であり得、これは、監視されるアドレスを設定することが、メモリ内の状態データを比較するアトミックな動作のセットに依存しないときに使用することができる。
【0066】
図７は、アドレス監視回路３６による監視を示す。ステップＳ１７０において、監視回路３６は、以前に構成された監視されるアドレスのセットのいずれかに関連付けられたデータに対する潜在的な更新を示すイベントを検出する。例えば、監視回路によって検出されるイベントは、監視されるアドレスのコヒーレンシ状態が「排他」から「無効」若しくは「共有」のいずれかに変化すべきであることを示す、インターコネクト１０からのスヌープ要求の受信、又はキャッシュ１２におけるそのようなコヒーレンシ状態遷移の検出であり得る。イベントの検出に応じて、ステップＳ１７２において、監視回路は、監視されるアドレスのセットのうちのどれがステップＳ１７０において検出されたイベントに遭遇したかを示す情報を設定する。例えば、以下に示すように、アドレス監視３６は、監視されるアドレスのセットのうちのどれがイベントに遭遇したアドレスであるかを追跡するデータ構造を、ハードウェア内に、又はメモリにストアされたデータを使用して、維持し得る。ステップＳ１７４において、アドレス監視回路３６は、イベントが発生したことを示す監視報告情報を、処理回路２２上で実行されるソフトウェアに対してアクセス可能にする。例えば、これは、処理回路２２を省電力状態からウェイクアップさせるか、又は割り込みハンドラの処理に切り替えさせ得る、割り込みの生成であってもよく、その結果、アドレスが監視されることを必要とするソフトウェアが、更新に応じることができる。
【0067】
イベントが発生したことを示すために示される割り込みは、イベントが発生するたびに生成される必要はない。例えば、既に割り込みを発生させた後であって、処理回路が割り込みを処理する前であるとき、割り込みがクリアされる前に、監視されるアドレスのセットのうちの１つに対して更なるイベントが検出されると、第２の割り込みを生成する必要がない場合がある。また、いくつかの実装形態では、割り込みを発生させる以外に、監視されるアドレスに対してイベントが発生したことをソフトウェアに通知するために別の機構が使用され得る。例えば、ソフトウェアによって読み取ることができるレジスタに情報がストアされ得る。しかしながら、割り込みベースの機構は、監視されるアドレスのうちの１つに対してイベントが発生したことを示す割り込みが受信されるまで処理回路２２が省電力モードに入るべきであることをシグナリングする「イベント待ち」命令を処理回路２２が使用することを可能にするのに有用であり得る。これは、処理回路２２が、監視されるアドレスのうちの１つに対してイベントが発生するまで、実行すべき他の機能処理を有しない場合に有用であり得る。
【0068】
図８及び図９は、アドレス監視回路３６、及び監視されるアドレスを追跡するための様々な構造を実装する異なる方法を示す。これらは２つの例に過ぎず、どのアドレスが監視されているか、及びそれらのアドレスの中でどのアドレスがイベントに遭遇したかを追跡するための情報を構造化する他の方法もあり得ることが理解されよう。
【0069】
図８は、監視排他命令の変形例１又は２を使用する実装形態のために使用され得る第１のアプローチを示し、監視されるアドレスに関する情報の追跡用にメタデータ構造を提供するためのメモリ内のアドレスを指定することに対するサポートがない。したがって、図８に示すアプローチでは、監視されるアドレスに関する情報を追跡するためのアドレス追跡構造として機能する専用バッファ２００が、ハードウェア内に設けられ得る。また、アドレス監視回路３６は、データキャッシュ１２内にストアされた状態情報を使用して、特定のアドレスに関連付けられたデータに対する更新を監視し得る。
【0070】
この例では、データキャッシュ１２は複数のエントリ１３を含み、各エントリがメモリシステム内の特定のアドレスからのデータ２１０をキャッシュすることができる。タグ値２１２は、各エントリでストアされて、対応するデータに関連付けられたアドレスを識別するための情報を示し、有効フラグ２１４は、各エントリ内に提供されて、データが有効であるかどうかを示すことができる。また、各エントリ１３は、データがクリーンであるかダーティであるか、又は上述したようにデータが排他コヒーレンシ状態にあるか共有コヒーレンシ状態にあるかを識別するために使用されるコヒーレンシ状態２１６を指定し得る。場合によっては、コヒーレンシ状態２１６及び有効フラグ２１４は、単一のインジケータに組み合わせることができる（「無効」が、コヒーレンシ状態フィールド２１６によって示されるコヒーレンシ状態のうちの１つとみなされる）。
【0071】
図８に示すように、各キャッシュエントリには、そのキャッシュエントリに関連付けられたアドレスが、監視排他命令、又は監視されるセットにアドレスを割り当てる他の命令の実行によって以前に構成された、監視されるアドレスのセット内にあるかどうかを示す、「監視」インジケーション２１８を設けることもできる。したがって、この例では、図６のステップＳ１５６が実行されるとき、これは、監視されるアドレスのセット内にターゲットアドレスがあることを示すために、ターゲットアドレスに関連付けられたデータに対応するキャッシュエントリ内に監視インジケーション２１８を設定することを含み得る。
【0072】
アドレス監視回路３６はまた、監視される各アドレスに関する更なる情報を追跡するために、データキャッシュ１２自体とは別の別個のキャッシュ構造としてアドレス追跡構造２００を維持する。例えば、アドレス追跡構造は、監視されるアドレスに対応するものとして示されている特定のキャッシュエントリ１３にそれぞれ対応する一定数のエントリを有し得る。アドレス追跡構造２００内のエントリの数は、キャッシュ１２内のエントリの数ほど大きくなくてもよい。アドレス追跡構造の各エントリは、例えば、対応するキャッシュエントリを識別するキャッシュエントリ識別子２２０と、対応するアドレスに対して図６のステップＳ１５８において識別子ストレージ構造に割り当てられた識別子であり得るソフトウェア識別子２２２と、対応する監視されるアドレスに対して関連するイベント（例えば、スヌープによってトリガされるコヒーレンシ状態遷移）が検出されたか否かを示し得る「スヌープ」インジケーション２２４とを指定し得る。アドレス監視回路３６はまた、監視されるセット内のいくつのアドレスが、対応するアドレスが更新されたことを示すスヌープイベントに遭遇したかを追跡するカウント値２３０を維持することもできる。
【0073】
したがって、監視されるアドレスのセットにアドレスを割り当てるとき、対応する監視インジケーション２２８が、関連するキャッシュエントリに設定され得、更にソフトウェア定義識別子値が、アドレス追跡構造２００の対応するエントリに割り当てられ得る。関連するアドレス追跡構造エントリのフィールド２２０は、例えば、データキャッシュ１２内の対応するキャッシュエントリの位置を識別するキャッシュセット／ウェイ情報に設定され得る。監視排他命令の変形例１が実行される場合、ソフトウェア識別子２２２がサポートされる必要はない。
【0074】
一方、インターコネクト１０から受信されたスヌープが、データキャッシュに関連付けられた制御回路ロジック２４０によって検出されると、キャッシュ制御ロジック２４０は、データキャッシュ１２をチェックして、スヌープ要求によって指定されたアドレスに関連付けられている対応するエントリがあるかどうかを判定し得る（１つ以上のキャッシュエントリのタグフィールド２１２を比較することによる）。スヌープ要求によって指定されたアドレスが、監視インジケーション２１８が設定されている有効なキャッシュエントリと一致して、対応するアドレスが監視されるアドレスのセットの一部であることを示すと、アドレス監視回路３６は、イベントが発生したことを示すためにソフトウェアへの割り込み又は他の通知を生成し、監視されるセット内で検出されているスヌープされたアドレスの数のカウント２３０を１増やす。また、アドレス監視回路３６は、スヌープされた監視されるアドレスに対応するアドレス追跡構造２００のエントリ内のスヌープインジケーション２２４を更新する。これは、後続の監視ポーリング命令が、どの特定のアドレスがスヌープされたかをチェックし、対応するソフトウェアＩＤ ２２２を取得することを可能にする。
【0075】
図８に示されるアプローチは、アドレス追跡用にメモリ内の空間を消費することを回避するのに有用であり得るが、追加のアドレス追跡構造を提供するためのハードウェア実装を必要とし得る。あるいは、図８はアドレス追跡構造２００をデータキャッシュ１２とは別個のものとして示しているが、他の実装形態は、ソフトウェアＩＤ ２２２及びスヌープインジケーション２２４を追跡するための追加のフィールドを各キャッシュエントリ１３に提供し得る。いずれにしても、これは、追加の回路ハードウェアが提供されることを必要とし得る。
【0076】
図９は、この追加のハードウェア構造２００を設ける必要がないように、代わりにアドレス監視データ構造をメモリシステム自体にストアする（及び必要であればデータキャッシュ１２にキャッシュする）ことができる代替アプローチを示す。これは、上記の監視排他命令の変形例３をサポートする実装形態においてサポートされ得、この命令は、そのアドレスレジスタＸｎを使用して、メモリシステムにストアされた識別子ストレージ構造２６０のベースアドレス２５０を指定するための情報を識別する。識別子ストレージ構造２６０は、監視排他命令の変形例３によって割り当てられる、対応する監視されるアドレスに対するソフトウェア識別子２２２をストアし得る。識別子構造２６０は、データキャッシュ１２内のキャッシュラインごとの識別子を含むことができ、この構造へのインデックス付けは、スヌープされるデータキャッシュ１２のエントリ（又は、監視のためにアドレスを割り当てるときに識別子２２２が構造２６０にストアされる場合、監視されるアドレスが割り当てられるエントリ）に基づいて決定されるベースアドレスに対するオフセットを使用し得る。アドレス監視回路３６はまた、監視される各アドレスがスヌープされたか、そうでなければソフトウェアへの報告を必要とするイベントに遭遇したかを示す「スヌープ」フラグの「スヌープ」ビットマップ２７０を、メモリにストアされる更なるデータ構造２７０として維持することもでき、これは、所与の監視命令に対して指定された識別子ストアベースアドレス２５０に対して同じく決定され得るアドレスにストアされ得る。例えば、スヌープビットマップ２７０は、識別子ストア１６０の終わりから連続して続くことができる。
【0077】
したがって、このアプローチでは、データキャッシュ１２自体は、所与のキャッシュラインが監視されているか否かを追跡する監視フィールド２１８を含む、図８に示すフィールドと同様のフィールドを用いて実装することができる。監視されるセットに新しいアドレスが割り当てられると、関連するキャッシュエントリの監視フィールド２１８を設定するだけでなく、そのキャッシュエントリのキャッシュセット／ウェイＩＤは、識別子ストアのベースアドレス２５０に加算されるオフセットを導出するために使用することができ、そのベースアドレスとオフセットの和に対応するアドレスを有するメモリロケーションは、監視排他命令の変形例３によって提供されるソフトウェア提供識別子で更新することができる。
【0078】
キャッシュコントローラ２４０が、監視されているとマークされたキャッシュエントリにコヒーレンシ状態２１６を排他から共有又は無効のいずれかに変更させる、インターコネクト１０からのスヌープを検出すると、これは、（処理回路２２に割り込みをかけるだけでなく）スヌープされた監視アドレスの数のカウント２３０を１増やし、また、スヌープされた特定の監視されるアドレスを示すようにビットマップ２７０内の関連するスヌープインジケータを更新する、アドレス監視回路３６にシグナリングされる。再び、更新されるべきスヌープビットマップ２７０内のフラグを識別するための関連するオフセットは、スヌープされた監視されるアドレスに対応するキャッシュエントリのセット及びウェイから導出され得る。以下で更に説明する監視ポーリング命令が、イベントに遭遇した可能性のある任意のアドレスに関する情報をポーリングするために実行されると、スヌープビットマップ２７０は、イベントに遭遇する監視されるアドレスに対応するソフトウェアにどのソフトウェア識別子が返されるべきであるかについて、識別子ストア２６０内の位置を識別するためにパースされ得る。
【0079】
図９に示されるアプローチは、図８に示される構造２００など、アドレス追跡のための専用のハードウェア構造を実装する際の回路面積コストを負う必要がないことを意味する。メモリにストアされる必要がある構造のサイズは、アドレス監視構造２６０、２７０をストアし、性能を改善するのに役立つ妥当な数の監視されるキャッシュライン自体もストアするための空間がデータキャッシュ１２に存在するように、データキャッシュ１２にキャッシュされるデータの全体量と比較して相対的に小さいものとすることができる。例えば、６４ｋＢのキャッシュを仮定すると、これは、監視され得る１０２４個のキャッシュラインを有し得る。ソフトウェア提供識別子をこれらのキャッシュラインの各々に関連付けることが望ましい場合、これは、識別子が１０２４個の異なるキャッシュラインを区別することができるために少なくとも１０ビットを必要とし、したがって、例えば、２バイト（１６ビット）の識別子が使用され得る。１６ビットの識別子を仮定すると、識別子構造２６０は、２ｋＢのメモリ空間を占有し得、したがって、これは、６４ｋＢのキャッシュ内に容易に収まることができる。１２８バイト（１０２４×スヌープフラグ当たり１ビット）に相当し得るスヌープビットマップ２７０のために、キャッシュ内のいくらかの追加の空間も必要とされ得る。いくつかの例では、カウント値２３０もメモリに追い出され、キャッシュされ得るが、依然として、監視されるキャッシュラインのために十分な追加の空間がレベル１データキャッシュ内に残存し得る。これは、様々なアドレス監視構造の最大範囲に対応するキャッシュの部分を示し得る図９の影付き部分３００によって示され、他の部分は、監視されるキャッシュライン及び監視されていないアドレスの他のデータのために残される。図９は、この影付き部分を単一の連続ブロックとして示しているが、実際には、アドレス監視構造は、キャッシュの複数の不連続に配置されたエントリにキャッシュされ得ることを理解されよう。
【0080】
上に示した変形例３の命令は、図９に示す使用事例をサポートするのに特に有用である。変形例３では、直近に遭遇した排他ステータス設定命令によって指定されたアドレスを参照してターゲットアドレスを暗黙的に定義することにより、これは、識別子ストレージ構造のベースアドレス２５０をレジスタフィールドが代わりに提供する命令エンコーディング内の空間を解放し、その結果、図９に示すアプローチを使用することができる。しかしながら、他の例では、ターゲットアドレスが命令に明示的にエンコーディングされる場合であっても、更なるレジスタフィールドが識別子構造ベースアドレスを識別するための十分な空間もある場合、明示的に示されたターゲットアドレスでエンコードされた監視排他命令の例はまた、ソフトウェアＩＤを追跡するためのメモリ内のデータ構造を提供する図９に示されたアプローチを使用することもできる。
【0081】
また、上述した例では、変形例３の監視排他命令において、レジスタＸｎ内のアドレスは、識別子ストレージ構造２６０のベースアドレス２５０を識別するが、他の例では、このレジスタ内の値は、識別子ストアベースアドレスが決定されることを可能にする他の情報を提供してもよい。例えば、スヌープビットマップ２７０、カウント値２３０、及び識別子ストレージ構造２６０が、アドレス空間内で互いに対して固定オフセットに位置する場合、監視排他命令によって指定されたレジスタ内の値は、これらの構造のうちのいずれか１つを指すことができ、他の構造のアドレスは、レジスタＸｎ内のアドレス及び暗黙的に定義される固定オフセットから導出することができる。
【0082】
図１０は、イベントが検出された監視されるアドレスのいずれかに関する情報を返すように監視回路３６に要求するためにソフトウェアによって使用され得る監視ポーリング命令の処理を示す。図１０は、監視ポーリング命令の２つの変形例を示す。第１の変形例では、命令は、監視ポーリング命令に応じて監視ポーリング情報が書き込まれる宛先レジスタＸｄを指定する。第２の変形例では、監視ポーリング命令は、宛先レジスタＸｄに加えて、図９に関して説明した識別子ストレージ構造２６０のベースアドレスを識別するための情報を提供するアドレスレジスタＸｎを指定する。変形例２は、図８の場合のように専用ハードウェア構造を提供する代わりに、識別子ストレージ構造をメモリにストアすることが望ましい例において、サポートされ得る。変形例１は、図８に示される実装形態とともに使用することができる。
【0083】
両変形例では、ステップＳ２００において、命令デコーダ２０は、監視ポーリング命令をデコードし、それに応じて、ステップＳ２０２において、処理回路を制御して、監視されるアドレスのセットのうちのどれがデータに対する潜在的な更新を示す１つ以上のイベントに遭遇したかを示す監視ポーリング情報をソフトウェアに対してアクセス可能にする。監視ポーリング情報は、監視ポーリング命令によって指定された宛先レジスタＸｄに書き込むことができる。
【0084】
したがって、ソフトウェアが、監視されるアドレスのセットのいずれか１つに対する更新をソフトウェアに通知するアドレス監視回路３６からの割り込みを受信した後に実行することができる、監視ポーリング命令が提供され得る。割り込み自体は、どの特定のアドレスが更新されたかを区別しないので、監視ポーリング命令は、どのアドレスが更新されたかに関するより多くの情報を示す監視ポーリング情報を宛先レジスタに返すために使用され得る。
【0085】
いくつかの実装形態では、２つ以上のアドレスがイベントに遭遇した場合に、監視ポーリング情報が、監視されるアドレスのセット内の複数の異なるアドレスに関する情報を提供することが可能であり得る。しかしながら、実際には、この情報は、１つのレジスタ内に収まらない場合があり、また、（回路実装及びタイミングの理由で）複数のアドレスに関するそれぞれのソフトウェアＩＤ又は他の情報を収集することは、単一の命令において効率的でない場合があり、したがって、一例では、監視ポーリング命令は、イベントが発生した単一の監視されるアドレスに関連付けられたデータの単一のログを返すように意図される場合があり、複数のアドレスに対するアドレス監視から情報を読み取ることが必要である場合は、複数の監視ポーリング命令を含むループが必要とされ得る。
【0086】
図１１は、複数の監視されるアドレスがイベントに遭遇した場合であっても、監視ポーリング情報が１つの監視されるアドレスに関する情報のみを返すと仮定される場合の監視ポーリング命令の処理についてより詳細に示す。ステップＳ２１０において、命令デコーダは監視ポーリング命令を再びデコードする。ステップＳ２１２に応じて、アドレス監視回路３６は、図８のアドレス追跡構造２００内のスヌープインジケータ２２４又は図９のスヌープビットマップ２７０をチェックして、監視中にイベントが検出された監視されるセット内の次のアドレスを識別する。アドレス監視回路は、対応するソフトウェア識別子２２２を（ハードウェア内の専用ストレージ構造として提供されるアドレス追跡構造２００のエントリから、又はメモリ若しくはキャッシュ１２内にストアされた識別子データ構造２６０内の関連オフセットから）読み出す。メモリベースの構造２６０の場合、識別子構造２６０内のオフセットは、スヌープビットマップ２７０から読み取られたスヌープビットの位置に対応する。ソフトウェアＩＤは、監視ポーリング命令の宛先レジスタＸｄに書き込まれる監視ポーリング情報に含まれている。一例として以下に示すように、他の情報を含めることも可能である。例えば、監視ポーリング命令の任意の更なるインスタンスを実行する必要があるかどうかをソフトウェアが決定することを可能にするために、ソフトウェア識別子が返されているアドレス以外に、１つ以上のイベントに遭遇した任意の更なるアドレスがあるかどうかのインジケーションを提供することが有用であり得る。
【0087】
ステップＳ２１４において、処理回路はまた、監視ポーリング命令のデコードに応じて、ステップＳ２１２において識別子が返された特定の監視されるアドレスに対して１つ以上のイベントが発生したというインジケーションをクリアする（例えば、アドレス追跡構造２００の関連エントリのスヌープフィールド２２４がクリアされるか、又はビットマップ２７０内の対応するビットがクリアされる）。また、カウント２３０が、監視ポーリング命令によってまだポーリングされていない残りのアドレスの数を追跡している場合には、ステップＳ２１４において、カウント２３０を１減らすこともでき、その結果、カウントが０に戻ると、ソフトウェアは、ポーリングされるべきアドレスは残っていないと判定する。
【0088】
宛先レジスタＸｄで返される監視ポーリング情報の例示的なフォーマットは、以下の通りであり得る。
｜６３：４８ ｍｏｎＩｄ｜４７：３２ ｌｏｇＬｅｎ｜３１：１６ ｍｏｎＬｅｎ｜１５：０ ｓｔａｔｕｓ｜
｜６３：４８ ｍｏｎＩｄ｜４７：３２ ｌｏｇＬｅｎ｜３１：１６ ｍｏｎＬｅｎ｜１５：０ ｓｔａｔｕｓ｜
【0089】
これから、ソフトウェアは以下を読み取ることができる。
ｍｏｎＩｄ－スヌープとマークされたアドレスに関連付けられた第１のエントリに関連付けられた識別子２２２か、又は何らかの理由でエラーが発生した場合は、既知のデフォルト値（例えば、０ｘｆｆｆｆ）。
ｌｏｇＬｅｎ－アドレス追跡構造２００、２６０から識別子２２２が返されたアドレスを含む、スヌープとマークされた残りのアドレスの数。
ｍｏｎＬｅｎ－監視されるアドレスのセット内のアドレスの総数。
ｓｔａｔｕｓ－監視ポーリング動作が成功したかどうかを示すステータス情報（例えば、ｏｋに対して０、エラーに対して１であり、異なるエンコーディングのステータスフィールドを使用してエラーの複数の理由を示すことも可能であり得る）。
当然のことながら、これは一例に過ぎず、他の実装形態は、異なるタイプの監視ポーリング情報返すことも、異なるフォーマットで返すこともあり得る。
ｍｏｎＩｄ－スヌープとマークされたアドレスに関連付けられた第１のエントリに関連付けられた識別子２２２か、又は何らかの理由でエラーが発生した場合は、既知のデフォルト値（例えば、０ｘｆｆｆｆ）。
ｌｏｇＬｅｎ－アドレス追跡構造２００、２６０から識別子２２２が返されたアドレスを含む、スヌープとマークされた残りのアドレスの数。
ｍｏｎＬｅｎ－監視されるアドレスのセット内のアドレスの総数。
ｓｔａｔｕｓ－監視ポーリング動作が成功したかどうかを示すステータス情報（例えば、ｏｋに対して０、エラーに対して１であり、異なるエンコーディングのステータスフィールドを使用してエラーの複数の理由を示すことも可能であり得る）。
当然のことながら、これは一例に過ぎず、他の実装形態は、異なるタイプの監視ポーリング情報返すことも、異なるフォーマットで返すこともあり得る。
【0090】
図１２は、使用され得るシミュレータ実装形態を例示する。上記の実施形態は、当該技法をサポートする特定の処理ハードウェアを動作させる装置及び方法の点において本発明を実装しているが、コンピュータプログラムの使用によって実装される本明細書に記載の実施形態による命令実行環境を提供することも可能である。このようなコンピュータプログラムは、コンピュータプログラムがハードウェアアーキテクチャのソフトウェアベースの実装形態を提供する限り、シミュレータとしばしば称される。様々なシミュレータコンピュータプログラムは、エミュレータ、仮想マシン、モデル、及び動的バイナリトランスレータを含むバイナリトランスレータを含む。典型的に、シミュレータ実装形態は、シミュレータプログラム３１０をサポートする、任意選択でホストオペレーティングシステム３２０を実行する、ホストプロセッサ３３０上で動作し得る。いくつかの配置では、ハードウェアと提供されている命令実行環境との間に複数のレイヤのシミュレーションがあってもよく、及び／又は、同じホストプロセッサ上に提供されている複数の異なる命令実行環境があってもよい。歴史的に、強力なプロセッサが、合理的な速度で実行されるシミュレータ実装形態を提供するのに必要とされてきたが、このようなアプローチは、互換性又は再使用の理由から別のプロセッサにネイティブなコードを実行することが望まれるようなときなど一定の状況では、正当化され得る。例えば、シミュレータ実装形態は、ホストプロセッサハードウェアによってサポートされていない追加の機能性を有する命令実行環境を提供し得るか、又は典型的には異なるハードウェアアーキテクチャに関連付けられた命令実行環境を提供し得る。シミュレーションの概要は、「Ｓｏｍｅ Ｅｆｆｉｃｉｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｉｍｕｌａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ」、Ｒｏｂｅｒｔ Ｂｅｄｉｃｈｅｋ、１９９０年冬ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ、５３～６３頁に記載されている。
【0091】
これまで、特定のハードウェア構成物又は特性を参照して実施形態を説明してきたが、シミュレーションされた実施形態では、適切なソフトウェア構成物又は特性によって同等の機能性を提供することができる。例えば、特定の回路構成は、シミュレーションされた実施形態で、コンピュータプログラムロジックとして実装されてもよい。同様に、レジスタ又はキャッシュなどのメモリハードウェアは、シミュレーションされた実施形態で、ソフトウェアのデータ構造として実装されてもよい。前述の実施形態で参照されているハードウェア要素のうちの１つ以上がホストハードウェア（例えば、ホストプロセッサ３３０）に存在する配置では、いくつかのシミュレーションされる実施形態は、適する場合、ホストハードウェアを使用してもよい。
【0092】
シミュレータプログラム３１０は、（非一時的媒体であってもよい）コンピュータ可読記憶媒体に記憶され得、（アプリケーション、オペレーティングシステム、及びハイパーバイザを含み得る）ターゲットコード３００に、シミュレータプログラム３１０によってモデル化されるハードウェアアーキテクチャのインタフェースと同じであるプログラムインタフェース（命令実行環境）を提供する。上で説明される監視排他命令、監視ポーリング命令、排他ステータス設定命令（例えばロード排他命令）及びストア排他命令を含むターゲットコード３００のプログラム命令は、シミュレータプログラム３１０を使用する命令実行環境内から実行され得、それによって、上で考察される装置２のハードウェア機能を実際には有していないホストコンピュータ３３０は、これらの機能をエミュレートすることができる。
【0093】
ターゲットコード３００のプログラム命令の命令エンコーディングをチェックし、各タイプの命令を、デコードされた命令によって表される機能性に対応する機能性を実行するホストハードウェア３３０によってサポートされるネイティブ命令セット内の１つ以上のプログラム命令の対応するセットにマッピングする命令を含む命令デコードプログラムロジック３１１をシミュレータプログラム３１０は有し得る。命令デコードプログラムロジック３１１は、上述の様々なタイプの命令のデコードをサポートする。
【0094】
シミュレータプログラム３１０はまた、ホストストレージ（例えば、ホストデータ処理装置３３０の仮想アドレス空間又はホストデータ処理装置３３０のレジスタ）内にレジスタシミュレーションデータ構造を維持する命令のセットを含み得るレジスタシミュレーションプログラムロジック３１２を含む。レジスタシミュレーションデータ構造は、ハードウェアで提供されるとターゲットコードは期待するが、実際にはホスト装置３３０のハードウェアで提供されない可能性があるレジスタ２４のレジスタ内容を表す。ターゲットコード３００内の命令は、特定のレジスタを参照すると期待されるシミュレーションされた命令セットアーキテクチャにおいて、レジスタシミュレーションプログラムロジック３１２に、ホスト装置のネイティブ命令セット内のロード／ストア命令を生成させて、ホスト装置のメモリ内にストアされたレジスタシミュレーションデータ構造からの対応するシミュレーションされたレジスタ状態の読み取り／書き込みを要求し得る。同様に、シミュレーションプログラム３１０は、ターゲットコード３００によって使用される仮想アドレス空間と、ターゲットコード３００の観点から、実際の物理メモリストレージを参照すると期待されるが、実際には、現実のホストデータ処理装置３３０によって使用される仮想アドレス空間内の仮想アドレスの領域に、メモリシミュレーションプログラムロジック３１３によってマッピングされるシミュレーションされた物理アドレス空間（これは、ホストメモリを参照するために使用される現実の物理アドレス空間への更なるアドレス変換をそれ自体が受け得る）との間の仮想－物理アドレス変換（ページテーブルデータに基づく）を実装する、メモリシミュレーションプログラムロジック３１３を含み得る。
【0095】
また、シミュレーションコードは、排他ステータス追跡回路３０及びアドレス監視回路３６と同等の機能をそれぞれ実行するようにホストハードウェア３３０を制御するソフトウェア命令のセットを含む排他ステータスクリアプログラムロジック３１４及び監視プログラムロジック３１５を含む。
【0096】
本出願において、「～ように構成された（configured to...）」という用語は、装置の要素が、定義された動作を実施することが可能である構成を有することを意味するために使用される。この文脈において、「構成」とは、ハードウェア又はソフトウェアの配設又は相互接続の方法を意味する。例えば、装置は、定義された動作を提供する専用ハードウェアを有し得るか、又はプロセッサ若しくは他の処理デバイスが、機能を実行するようにプログラムされ得る。「～ように構成された」は、装置要素が、定義された動作を提供するために何らかの変更がなされる必要があることを意味しない。
【0097】
本発明の例示的な実施形態が添付の図面を参照して本明細書で詳細に説明されているが、本発明はこれらの正確な実施形態に限定されないこと、及び様々な変更及び修正が、当業者によって、添付の特許請求の範囲によって定義されている本発明の範囲から逸脱することなく、実施形態に行われ得ることが理解されよう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【国際調査報告】