JP6318440B2 - 無制限トランザクショナルメモリ（ｕｔｍ）システムの最適化 - Google Patents

Description

本発明は、プロセッサの実行に関する。具体的には、命令群の実行に関する。

半導体プロセスおよびロジック設計が進化したことによって、集積回路素子に設けられるロジックの量を増加させることが可能となった。この結果、コンピュータシステム構成は、１つのシステム内に１以上の集積回路を設ける構成から、各集積回路に複数のコアおよび複数の論理プロセッサが設けられる構成へと進化を遂げた。通常、プロセッサまたは集積回路は１つのプロセッサダイを備え、プロセッサダイは任意の数のコアまたは論理プロセッサを有するとしてよい。

集積回路に設け得るコアおよび論理プロセッサの数は増加の一途を辿っているので、同時に実行可能なソフトウェアスレッドの数も増加している。しかし、同時に実行するソフトウェアスレッドの数が増加すると、複数のソフトウェアスレッド間で共有しているデータの同期に関して問題が発生する。マルチコアシステムまたはマルチ論理プロセッサシステムにおいて共有データにアクセスするための一般的な解決策の１つとして、共有データに対して複数アクセスがある場合に相互排除を保証するためロックを用いる方法がある。しかし、複数のソフトウェアスレッドを実行する機能は進化する一方であり、誤って競合が発生する可能性や実行がシリアル化してしまう可能性がある。

例えば、共有データを保持しているハッシュテーブルを考えられたい。ロックシステムを利用する場合、プログラマは、ハッシュテーブル全体をロックして、１つのスレッドがハッシュテーブル全体にアクセスできるようにする場合がある。しかし、他のスレッドはロックが解除されるまでハッシュテーブルのどのエントリにもアクセスできないので、他のスレッドのスループットおよび性能に悪影響が出る。これに代えて、ハッシュテーブルをエントリ毎にロックするとしてもよい。いずれにしても、この単純な例に基づき大きくスケーラブルなプログラムを考えると、ロック競合、シリアル化、細粒度の同期、およびデッドロック回避の複雑さはプログラマによって非常に面倒な負担となることが明らかである。

近年利用されている別のデータ同期技術には、トランザクショナルメモリ（ＴＭ）を利用するものがある。トランザクション的実行では多くの場合、複数のマイクロ演算、演算または命令のグループ分けを実行する。上記の例では、両方のスレッドを同一ハッシュテーブル内で実行し、それぞれのメモリアクセスを監視／追跡する。両方のスレッドが同一エントリにアクセス／変更を実行すると、データの有効性を保証するべくコンフリクト解決を実行するとしてよい。トランザクション的実行の一種には、ソフトウェアトランザクショナルメモリ（ＳＴＭ）があり、ＳＴＭでは、メモリアクセスの追跡、コンフリクト解決、アボートタスク、および、その他のトランザクション的タスクは、多くの場合はハードウェアのサポート無しに、ソフトウェアで実行される。

別の種類のトランザクション的実行には、ハードウェアトランザクショナルメモリ（ＨＴＭ）システムがあり、ＨＴＭシステムでは、アクセスの追跡、コンフリクト解決、および、他のトランザクション的タスクをサポートするべくハードウェアを含める。以前は、実際のメモリデータアレイを追加ビットで拡張して、読出、書込およびバッファリングを追跡するためにハードウェア属性等の情報を保持していた。このため、データはこのデータと共にプロセッサからメモリまで転送される。この情報は、持続的情報と呼ばれることが多く、つまり、キャッシュ・エビクションが発生しても失われない。これは、この情報がメモリヒエラルキー内をデータと共に移動するためである。しかし、このような持続性のために、メモリヒエラルキーシステムにおいてオーバーヘッドが増加してしまう。

また、従来のハードウェアトランザクショナルメモリ（ＨＴＭ）システムは多くの非効率性を抱えている。第１の例を挙げると、ＨＴＭでは現時点において、トランザクションのコミット前にコンシステンシを保証するために、バッファされていない状態またはバッファされているが監視されていない状態からバッファされており且つ監視されている状態への遷移を効率的に行なう方法がない。別の例を挙げると、ＨＴＭのソフトウェアに対するインターフェースには非効率な点が多く見られる。具体的には、ハードウェアは、トランザクション的処理と非トランザクション的処理との間の強アトミック性および弱アトミック性についてさまざまな形態を考慮しているソフトウェアメモリアクセスバリアを適切に加速するメカニズムを提供していない。また、ハードウェアは、トランザクションをコミットしようとする場合、監視情報、バッファリング情報および/またはその他の属性情報の損失に基づきトランザクションをアボートまたはコミットするタイミングを判断するメカニズムを提供しない。同様に、このような従来のＨＴＭのための命令群は、トランザクションのコミット時に保持すべき情報またはクリアすべき情報を定義するコミット命令を実現できない。他にも非効率性の例を挙げると、ＨＴＭではコンフリクトまたは情報の損失を検出した場合に効率的に実行を誘導またはジャンプさせるための命令がない点、および、現時点のＨＴＭではトランザクション実行時にリングレベル優先遷移を処理することが出来ない点がある。

添付図面の図示内容は、本発明を限定するのではなく例示するものである。
複数のソフトウェアスレッドを同時に実行可能な複数の処理要素を備えるプロセッサの実施形態を示す図である。 データアイテムについてメタデータを対応付ける実施形態を示す図である。 複数の処理要素における複数の別個のソフトウェアサブシステムの複数の直交するメタフィジカルアドレス空間の実施形態を示す図である。 データに対してメタデータを圧縮する実施形態を示す図である。 メタデータにアクセスする方法の実施形態を説明するフローチャートである。 強アトミック性環境および弱アトミック性環境においてトランザクションの加速をサポートするメタデータ格納要素の実施形態を示す図である。 トランザクション的環境におけるアトミック性を維持しつつ非トランザクション的処理を加速するための実施形態を示すフローチャートである。 トランザクションのコミット前にデータのブロックをバッファされており監視されている状態へと効率的に遷移させる方法の実施形態を示すフローチャートである。 トランザクションステータスレジスタのステータス値に基づきデスティネーションラベルにジャンプする損失命令をサポートするハードウェアの実施形態を示す図である。 コンフリクトまたは特定情報の損失の基づきデスティネーションラベルにジャンプする損失命令を実行する方法の実施形態を説明するためのフローチャートである。 コミット命令においてコミット条件およびクリア制御の定義をサポートするハードウェアの実施形態を示す図である。 コミット条件およびクリア制御を定義するコミット命令を実行する方法の実施形態を説明するためのフローチャートである。 トランザクション実行中の特権レベル遷移の処理をサポートするハードウェアの実施形態を示す図である。

以下に記載する説明では、本発明の完全な理解を目的として、トランザクション的実行のための特定のハードウェア構造、アクセス監視部の特定の種類および実装、アクセスコンフリクトを検出する特定の種類のキャッシュコヒーレンシモデル、特定のデータ粒度、および、特定の種類のメモリアクセスおよびメモリ位置等の例等、具体的且つ詳細な内容を数多く記載する。しかし、本発明を実施する際に以下に記載する具体的且つ詳細な内容を採用する必要はないことは当業者には明らかである。また、ソフトウェアでのトランザクションのコーディング、コンパイラによるエニュメレーションされた機能を実行する処理の挿入、トランザクションの境界画定、特定および他のマルチコアプロセッサアーキテクチャおよびマルチスレッドプロセッサアーキテクチャ、特定のコンパイラ方法／実装、および、マイクロプロセッサの特定の処理の詳細内容等の公知の構成要素または方法は、本発明を不要にあいまいにすることを避けるべく詳細な説明を省略している。

本明細書で説明する方法および装置は、無制限トランザクショナルメモリ（ＵＴＭ）を実装するハードウェアおよびソフトウェアを最適化する方法および装置である。具体的には、ＵＴＭシステムをどのようにサポートするかに主に関連付けて最適化を説明する。しかし、本明細書で説明する方法および装置は、任意の形態のトランザクショナルメモリシステムで利用されるとしてもよく、例えば、ソフトウェアトランザクショナルメモリシステム（ＳＴＭ）をサポートまたは加速するハードウェア、純粋なハードウェアトランザクショナルメモリシステム（ＨＴＭ）、または、これらを組み合わせたものであって、ＵＴＭシステムとは実装方法が異なるハイブリッド型で利用されるとしてもよい。

図１は、複数のスレッドを同時に実行可能なプロセッサの実施形態を示す図である。尚、プロセッサ１００は、ハードウェアトランザクション的実行についてのハードウェアサポートを備えるとしてよい。プロセッサ１００はまた、ハードウェアトランザクション的実行と組み合わせて、または、これとは別個に、ソフトウェアトランザクショナルメモリ（ＳＴＭ）のハードウェア加速、ＳＴＭの独立実行、または、これらの組み合わせ、例えば、ハイブリッド型のトランザクショナルメモリ（ＴＭ）システムについてハードウェアサポートを提供するとしてよい。プロセッサ１００は、任意のプロセッサを備え、例えば、マイクロプロセッサ、組み込みプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、ネットワークプロセッサ、または、その他のコード実行デバイスを備える。プロセッサ１００は、図示しているように、複数の処理要素を備える。

一実施形態によると、処理要素は、スレッドユニット、プロセスユニット、コンテクスト、論理プロセッサ、ハードウェアスレッド、コア、および／または、プロセッサの状態、例えば、実行状態またはアーキテクチャ状態を保持可能な任意のその他の要素を意味する。言い換えると、一実施形態に係る処理要素は、ソフトウェアスレッド、オペレーティングシステム、アプリケーション等のコードと独立して対応付け可能な任意のハードウェアを意味する。物理プロセッサは通常、コアまたはハードウェアスレッド等の他の処理要素を任意の数だけ有する集積回路を意味する。

「コア」は、独立したアーキテクチャ状態を維持可能な、集積回路に設けられているロジックを意味することが多く、独立して維持されるアーキテクチャ状態はそれぞれ、少なくとも幾つかの専用実行リソースと対応付けられている。コアとは対照的に、「ハードウェアスレッド」は通常、独立したアーキテクチャ状態を維持可能な、集積回路に設けられている任意のロジックを意味するが、複数の独立して維持されるアーキテクチャ状態は実行リソースへのアクセスを共有する。以上から分かるように、所定のリソースが共有されており、他のリソースが一のアーキテクチャ状態の専用である場合、ハードウェアスレッドと呼ぶか、コアと呼ぶかの境界は重複している。しかし多くの場合、コアおよびハードウェアスレッドは、オペレーティングシステムからは別個の論理プロセッサとして認識され、オペレーティングシステムは論理プロセッサ毎に別個に処理をスケジューリング可能である。

物理プロセッサ１００は、図１に示すように、高位レベルキャッシュ１１０へのアクセスを共有しているコア１０１およびコア１０２の２つのコアを備えている。プロセッサ１００は、複数の非対称なコア、つまり、構成、機能部および／またはロジックが異なる複数のコアを備えるとしてもよいが、図示しているのは複数の対称なコアである。このため、コア１０１と同一であるものとして図示されているコア１０２は、説明が繰り返しになるのを避けるべく、詳細な説明は省略する。また、コア１０１は２つのハードウェアスレッド１０１ａおよび１０１ｂを有し、コア１０２は２つのハードウェアスレッド１０２ａおよび１０２ｂを有する。このため、オペレーティングシステム等のソフトウェアエンティティは、プロセッサ１００を４つの別個のプロセッサと見なす。つまり、４つのソフトウェアスレッドを同時に実行可能な４つの論理プロセッサまたは処理要素があると見なす。

ここで、第１のスレッドはアーキテクチャ状態レジスタ１０１ａに対応付けられ、第２のスレッドはアーキテクチャ状態レジスタ１０１ｂに対応付けられ、第３のスレッドはアーキテクチャ状態レジスタ１０２ａに対応付けられ、第４のスレッドはアーキテクチャ状態レジスタ１０２ｂに対応付けられている。図示しているように、アーキテクチャ状態レジスタ１０１ａはアーキテクチャ状態レジスタ１０１ｂで複製されているので、論理プロセッサ１０１ａおよび論理プロセッサ１０１ｂについて別個のアーキテクチャ状態／コンテクストを格納することができる。他のこれより小規模のリソース、例えば、リネーム割り当てロジック１３０の命令ポインタおよびリネームロジックも、スレッド１０１ａおよび１０１ｂについて複製するとしてよい。一部のリソース、例えば、リオーダ／リタイア部１３５のリオーダバッファ、ＩＬＴＢ１２０、ロード／格納バッファ、および、待ち行列は、パーティション化を利用して共有するとしてよい。他のリソース、例えば、汎用内部レジスタ、ページテーブルベースレジスタ、低レベルデータキャッシュおよびデータＴＬＢ１１５、実行部１４０、および、アウトオブオーダ部１３５の一部は、完全に共有され得る。

プロセッサ１００は多くの場合、他に完全に共有されるリソース、パーティション化を利用して共有されるリソース、または、ある処理要素に専用のリソースを備える。図１で図示する機能部／リソースを備えるプロセッサの実施形態は、単に一例に過ぎない。尚、プロセッサは、上記の機能部のうちいずれを備えるとしてもよいし、省略するとしてもよいし、図示していない任意のその他の公知の機能部、ロジック、または、ファームウェアを備えるとしてもよい。

図示しているように、プロセッサ１００は、プロセッサ１００の外部のデバイス、システムメモリ１７５、チップセット、ノースブリッジ、または、その他の集積回路等と通信するためにバスインターフェースモジュール１０５を備えている。メモリ１７５は、プロセッサ１００の専用であるとしてもよいし、システム内のほかのデバイスとの間で共有するとしてもよい。高位レベルキャッシュまたはその上位のキャッシュ１１０は、高位レベルキャッシュ１１０から最近フェッチされた要素をキャッシュする。尚、「高位レベル」または「その上位」とは、実行部から離れるにしたがって高くなるキャッシュレベルを意味する。一実施形態によると、高位レベルキャッシュ１１０は第２レベルデータキャッシュである。しかし、高位レベルキャッシュ１１０は、これに限定されるものではなく、命令キャッシュに対応付けられているとしてもよいし、命令キャッシュを有するとしてもよい。これに代えて、トレースキャッシュ、つまり、命令キャッシュの一種を、最近デコードされたトレースを格納するべく、デコーダ１２５の後段に結合するとしてもよい。モジュール１２０はさらに、実行／採用すべき分岐を予測する分岐ターゲットバッファ、および、命令用のアドレス変換エントリを格納する命令変換バッファ（Ｉ−ＴＬＢ）を有する。

デコードモジュール１２５は、フェッチ部１２０に結合されており、フェッチされた要素をデコードする。一実施形態によると、プロセッサ１００は、プロセッサ１００で実行可能な命令を定義／規定している命令セットアーキテクチャ（ＩＳＡ）に対応付けられている。ここにおいて、ＩＳＡで認識される機械コード命令は多くの場合、実行すべき命令または演算を参照／規定しているオペコードと呼ばれる部分を含む。

一例を挙げると、割り当て／リネームブロック１３０は、命令処理結果を格納するためのレジスタファイル等のリソースを確保する割り当て部を有する。しかし、スレッド１０１ａおよび１０１ｂはアウトオブオーダでの実行が可能であり、この場合には、割り当て／リネームブロック１３０は、命令結果を追跡するためのリオーダバッファ等の他のリソースも確保する。割り当て／リネームブロック１３０はさらに、プログラム／命令参照レジスタをプロセッサ１００の内部のほかのレジスタへとリネームするレジスタリネーム部を有するとしてよい。リオーダ／リタイア部１３５は、アウトオブオーダ実行およびアウトオブオーダで実行された命令のインオーダでのリタイアをサポートするべく、上述したリオーダバッファ、ロードバッファ、および、格納バッファ等の構成要素を有している。

スケジューラおよび実行部ブロック１４０は、一実施形態によると、実行部に対して命令／演算をスケジューリングするスケジューラ部を有する。例えば、浮動小数点命令は、利用可能な浮動小数点実行部を持つ実行部のポートにスケジューリングされる。命令処理結果に関する情報を格納するべく、実行部に対応付けられているレジスタファイルも含まれる。実行部の例を挙げると、浮動小数点実行部、整数実行部、ジャンプ実行部、ロード実行部、格納実行部、および、その他の公知の実行部が含まれる。

低位レベルデータキャッシュおよびデータ変換バッファ（Ｄ−ＴＬＢ）１５０は、実行部１４０に結合されている。データキャッシュは、最近利用された／演算が行なわれた要素を格納している。例えば、メモリコヒーレンシ状態で保持されているデータオペランドを格納している。Ｄ−ＴＬＢは、最近の仮想／線形アドレスから物理アドレスへの変換を格納している。具体例を挙げると、プロセッサは、物理メモリを複数の仮想ページに分割するページテーブル構造を備えるとしてよい。

一実施形態によると、プロセッサ１００では、ハードウェアトランザクション的実行、ソフトウェアトランザクション的実行、または、これらを組み合わせたハイブリッド型の実行が可能である。トランザクションは、コードのクリティカル部分またはアトミック部分とも呼ばれるが、アトミック群として実行されるべき命令群、演算群またはマイクロ演算群を含む。例えば、命令または演算を用いて、トランザクションまたはクリティカル部分を画定するとしてよい。一実施形態によると、より詳細に後述するが、このような命令は、上述したデコーダ等、プロセッサ１００のハードウェアによって認識可能な命令群アーキテクチャ（ＩＳＡ）等の命令群の一部を成している。多くの場合、このような命令は、高級言語からハードウェアで認識可能なアセンブリ言語へとコンパイルされると、オペレーションコード（オペコード）または命令のうちデコーダがデコード段階で認識するその他の部分を含む。

トランザクションの実行中、メモリへの更新は、当該トランザクションがコミットされるまで、グローバルには可視化されないのが普通である。一例を挙げると、ある位置へのトランザクション的書込は、ローカルスレッドには可視であるが、当該トランザクション的書込を含むトランザクションがコミットされるまでは、他のスレッドからの読出に応じて書込みデータを転送することはない。トランザクションがまだ実行中である間は、メモリからロードされるデータアイテム／データ要素およびメモリに書き込まれるデータアイテム／データ要素を追跡する。これについては、より詳細に後述する。トランザクションがコミット点に到達すると、当該トランザクションに関してコンフリクトが検出されなければ、当該トランザクションをコミットして、トランザクション実行中に行なわれた更新をグローバルに可視化する。

しかし、実行中にトランザクションが無効化されると、トランザクションをアボートして、更新をグローバルに可視化することなく再開する。このため、「トランザクションの実行中」という表現は、本明細書で用いる場合、実行が開始されており、コミットまたはアボートされていない、つまり、実行中のトランザクションを意味するものとする。

ソフトウェアトランザクショナルメモリ（ＳＴＭ）システムは通常、アクセス追跡、コンフリクト解決、または、その他のトランザクショナルメモリのタスクを、ソフトウェア内で、または、少なくとも部分的にソフトウェア内で実行することを意味する。一実施形態によると、プロセッサ１００は、トランザクション的実行をサポートするべくプログラムコードをコンパイルするコンパイラを実行することができる。ここにおいて、コンパイラは、演算、呼び出し、関数、および、トランザクションの実行を可能とするその他のコードを挿入するとしてよい。

コンパイラは通常、ソーステキスト／コードをターゲットテキスト／コードに変換するプログラムまたはプログラム群を含む。プログラム／アプリケーションコードをコンパイラでコンパイルする場合には、複数の段階およびパスに分けて行い、高級プログラミング言語コードを低級の機械言語コードまたはアセンブリ言語コードに変換することが多い。しかし、コンパイルを簡略化するべく１パス型のコンパイラを利用するとしてもよい。コンパイラは、任意の公知のコンパイル方法を利用して任意の公知のコンパイラ処理を実行するとしてよい。例えば、字句解析、前処理、構文解析、意味解析、コード生成、コード変換、および、コード最適化を実行するとしてよい。

コンパイラが大型になると複数の段階を含むことが多いが、一般的には２段階が最も多い。（１）フロントエンド段階、つまり、構文処理、意味処理、および、一部の変換／最適化を行なう段階と、（２）バックエンド段階、つまり、分析、変換、最適化、および、コード生成を実行する段階とに分けられる。一部のコンパイラでは、コンパイラのフロントエンド段階とバックエンド段階との間の境界があいまいなミドルエンドが見られる。このため、挿入、対応付け、生成、または、その他のコンパイラの処理は、上述した段階またはパス、および、任意のその他の公知のコンパイラの段階またはパスのうちいずれの段階またはパスで行われるとしてもよい。説明のために一例を挙げると、コンパイラは、コンパイルの１以上の段階にトランザクション的な演算、呼び出し、関数等を挿入するが、例えば、コンパイルのフロントエンド段階に呼び出し／演算を挿入し、トランザクショナルメモリ変換段階において呼び出し／演算をより低級なコードに変換する。

しかし、コンパイラの動的または静的な性格および実行環境に関わらず、コンパイラは、一実施形態によると、トランザクション的な実行を可能にするべくプログラムコードをコンパイルする。このため、プログラムコードの実行という場合、一実施形態によると、（１）メインプログラムコードをコンパイルするため、トランザクション的構造を維持するため、または、他のトランザクション関連の処理を実行するために、コンパイラプログラムを動的または静的に実行すること、（２）トランザクション的な演算／呼び出しを含むメインプログラムコードを実行すること、（３）メインプログラムコードと対応付けられているライブラリ等の他のプログラムコードを実行すること、または、（４）これらの組み合わせを意味する。

コンパイラは、ソフトウェアトランザクショナルメモリ（ＳＴＭ）システムでは多くの場合、一部の演算、呼び出し、および、他のコードを、コンパイルされるべきアプリケーションコードにしたがって挿入するために用いられる。一方、他の演算、呼び出し、関数、および、コードはライブラリ内で別に提供される。このような構成とすることによって、アプリケーションコードを再度コンパイルすることなく、ライブラリを最適化および更新するライブラリ分配部の機能が得られる。具体例を挙げると、コミット関数の呼び出しは、アプリケーションコード中のトランザクションのコミット点に応じて挿入され、当該コミット関数は別に、更新可能なライブラリで提供されるとしてよい。また、特定の演算および呼び出しをどこに配置するかの選択は、アプリケーションコードの効率に影響を及ぼす。例えば、図６を参照しつつアクセスバリアに関連付けてより詳細に後述するフィルタリング処理をコードにしたがって挿入する場合、当該フィルタリング処理は、バリアに誘導してからフィルタリング処理を実行するという非効率的なやり方ではなく、バリアに向けて実行を誘導する前に行われるとしてよい。

一実施形態によると、プロセッサ１００は、ハードウェア／ロジックを利用してトランザクションを実行可能である。つまり、ハードウェアトランザクショナルメモリ（ＨＴＭ）システムにおいて実行可能である。ＨＴＭを実現する場合にはアーキテクチャおよびマイクロアーキテクチャの両方の観点から見て具体的な実現に関する詳細な内容が数多くあり、その大半は、本発明を不要にあいまいにすることを避けるべく、本明細書では説明を省略する。しかし、一部の構造および実施例については例示を目的として開示する。しかし、開示する構造および実施例は必須ではなく、実施の際の詳細な内容が異なる他の構造を追加しても、および／または、そのような他の構造と置換するとしてもよいことに留意されたい。

組み合わせとして、プロセッサ１００は、ＳＴＭシステムおよびＨＴＭシステムの両方の長所を利用しようとする無制限トランザクショナルメモリ（ＵＴＭ）システムでトランザクションを実行可能であるとしてもよい。例えば、ＨＴＭは多くの場合、小規模のトランザクションを高速且つ効率的に実行することに適している。これは、アクセス追跡、コンフリクト検出、認証およびトランザクションのコミットの全てを実行するためにソフトウェアを利用しないためである。しかし、ＨＴＭは通常、比較的小規模のトランザクションを処理することしか出来ない。一方、ＳＴＭは、処理できるトランザクションのサイズに制限はない。このため、一実施形態によると、ＵＴＭシステムは、比較的小規模のトランザクションを実行するためにはハードウェアを利用し、ハードウェアには大きすぎるトランザクションを実行するためにはソフトウェアを利用する。以下の説明から分かるように、ソフトウェアがトランザクションを処理している場合であっても、ソフトウェアを支援および加速させるためにハードウェアを利用するとしてもよい。さらに、重要なポイントであるが、純粋なＳＴＭシステムをサポートおよび加速するために利用されるハードウェアは同じである点にも留意されたい。

上述したように、トランザクションは、プロセッサ１００内のローカルな処理要素および他の処理要素による、データアイテムへのトランザクション的なメモリアクセスを含む。トランザクショナルメモリシステムに安全メカニズムが無い場合、このようなアクセスのうち一部は、無効なデータおよび実行となってしまう。つまり、読出を無効化するようなデータへの書込、または、無効なデータの読出等となってしまう。このため、プロセッサ１００は、コンフリクトが発生する可能性を特定するべく、データアイテムに対するメモリアクセスを追跡または監視するロジックを備える。例えば、後述するように、読出監視部および書込監視部を備える。

データアイテムまたはデータ要素とは、ハードウェア、ソフトウェアまたはこれらの組み合わせが定義する任意の粒度レベルのデータを含むとしてよい。データ、データ要素、データアイテムまたはこれらへの参照の例を挙げると、全てを網羅しているものではないが、メモリアドレス、データオブジェクト、クラス、動的言語コードの型のフィールド、動的言語コードの型、変数、オペランド、データ構造、および、メモリアドレスへの間接的な参照がある。しかし、任意の公知のデータ群を、データ要素またはデータアイテムと呼ぶとしてもよい。上記の例のうちの数例、例えば、動的言語コードの型のフィールドおよび動的言語コードの型とは、動的言語コードのデータ構造を指している。説明すると、サン・マイクロシステムズ・インコーポレーテッド（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．）社製のＪａｖａ（登録商標）等の動的言語コードは、型付けの程度が高い言語である。各変数は、コンパイル時に明らかとなる型を持つ。型は、プリミティブ型（ブーリアンおよび数値、例えば、整数、浮動小数点）および参照型（クラス、インターフェース、およびアレイ）という２つのカテゴリーに分けられる。参照型の値は、オブジェクトへの参照である。Ｊａｖａ（登録商標）では、オブジェクトは、複数のフィールドから成り、クラスインスタンスまたはアレイであってよい。クラスＡのオブジェクトａについては、Ａ：：ｘという表記方法を用いて型Ａのフィールドｘを表し、ａ．ｘという表記方法でクラスＡのオブジェクトａのフィールドｘを表すのが通常である。例えば、数式はａ．ｘ＝ａ．ｙ＋ａ．ｚ等で表されるとしてよい。この場合、フィールドｙおよびフィールドｚをロードして加算し、その結果をフィールドｘに書き込む。

このため、データアイテムへのメモリアクセスの監視／バッファリングは、任意のデータレベル粒度で実行するとしてよい。例えば、一実施形態によると、データへのメモリアクセスは、型のレベルで監視する。ここで、フィールドＡ：：ｘへのトランザクション的書込およびフィールドＡ：：ｙの非トランザクション的ロードは、同じデータアイテム、つまり、型Ａに対するアクセスとして監視されるとしてよい。別の実施形態によると、メモリアクセスの監視／バッファリングは、フィールドのレベルの粒度で実行される。この場合、Ａ：：ｘへのトランザクション的書込およびＡ：：ｙの非トランザクション的ロードは、別のフィールドを参照しているので、同じデータアイテムへのアクセスとしては監視されない。尚、データアイテムへのメモリアクセスの追跡については、他のデータ構造またはプログラミング技術を考慮に入れるとしてもよい。一例を挙げると、クラスＡのオブジェクトのフィールドｘおよびフィールドｙ、つまり、Ａ：：ｘおよびＡ：：ｙが、クラスＢのオブジェクトを指定しており、新たに割り当てられたオブジェクトに初期化され、初期化の後は書き込みが決して行われないと仮定する。一実施形態によると、Ａ：：ｘによって指定されたオブジェクトのフィールドＢ：：ｚへのトランザクション的書込は、Ａ：：ｙによって指定されているオブジェクトのフィールドＢ：：ｚの非トランザクション的ロードと同じデータアイテムへのメモリアクセスとしては監視されない。上記の例から、監視部は任意のデータ粒度レベルで監視／バッファリングを実行するものと推察され得る。

一実施形態によると、プロセッサ１００は、データアイテムに対応付けられているアクセス、および、その後に発生し得るコンフリクトを検出または追跡する監視部を備える。一例を挙げると、プロセッサ１００のハードウェアは、監視対象と判断されるロードおよびストアを追跡する読出監視部および書込監視部を有する。一例を挙げると、ハードウェアの読出監視部および書込監視部は、基本格納構造の粒度に関わらず、データアイテムを当該データアイテムの粒度で監視する。一実施形態によると、データアイテムは、少なくとも当該データアイテム全体が適切に監視されるように、格納構造の粒度で対応付けられている追跡メカニズムによって画定されている。

説明するために具体例を挙げると、読出監視部および書込監視部は、キャッシュ位置、例えば、低レベルデータキャッシュ１５０内の位置に対応付けられている属性を、当該位置に対応付けられているアドレスに対するロードおよびストアを監視するために含む。この場合、データキャッシュ１５０のキャッシュ位置の読出属性は、当該キャッシュ位置に対応付けられているアドレスに対する読出イベントに応じて、同じアドレスに対して競合する書込を監視するために設定される。ここにおいて、書込属性は、同じアドレスに対して読出および書込が競合していないか監視するべく、書込イベントについて同様に操作される。この例に基づいてさらに説明すると、ハードウェアは、キャッシュ位置に対する読出および書込をスヌープして、当該キャッシュ位置が監視されている旨を示すべく読出属性および／書込属性を設定することによってコンフリクトを検出することができる。逆に、一実施形態によると、読出監視部および書込監視部を設定することによって、または、キャッシュ位置をバッファ済み状態に更新することによって、読出要求または所有権読出要求等のスヌープが実行される。これによって、他のキャッシュの監視されているアドレスについてのコンフリクトを検出することができる。

このため、設計に応じて、キャッシュラインの監視対象コヒーレンシ状態およびキャッシュコヒーレンシ要求の組み合わせによっては、コンフリクトが発生する可能性がある。例えば、共有されており読出監視の対象である状態のデータアイテムを保持しているキャッシュラインと、当該データアイテムに対する書込要求を示すスヌープである。逆に、バッファ済み書込状態のデータアイテムを保持するキャッシュラインと、当該データアイテムに対する読出要求を示す外部スヌープは、コンフリクトを発生させる可能性があると見なされるとしてよい。一実施形態によると、このようにアクセス要求と属性状態との組み合わせを検出するべく、スヌープロジックは、コンフリクト検出／報告ロジック、例えば、コンフリクトの検出／報告のための監視部および／またはロジック、ならびに、コンフリクトの報告のためのステータスレジスタ等に結合されている。

しかし、条件およびシナリオの組み合わせによっては、コミット命令等の命令によって定義され得るトランザクションについて無効であると見なされるとしてもよい。これについては、図１１および図１２を参照しつつより詳細に後述する。トランザクションをコミットしないと見なす要因の例には、トランザクション的なアクセスが実行されたメモリ位置に対するコンフリクトの検出、監視情報の損失、バッファ済みデータの損失、トランザクション的なアクセスが実行されたデータアイテムに対応付けられているメタデータの損失、および、割り込み、リング遷移、または、明示的なユーザ命令等の他の無効イベントの検出が含まれる。

一実施形態によると、プロセッサ１００のハードウェアは、バッファされた状態で、トランザクション的な更新を保持する。上述したように、トランザクション的書込は、トランザクションがコミットされるまで、グローバルに可視化されない。しかし、トランザクション的書込に対応付けられているローカルソフトウェアスレッドは、後続のトランザクション的アクセスのために、トランザクション的更新にアクセスすることができる。第１の例を挙げると、プロセッサ１００にはバッファされている更新を保持する別個のバッファ構造が設けられており、ローカルスレッドには更新を供給することができるが、他の外部のスレッドには供給できない。しかし、別個のバッファ構造を備えると、コストが増加し、複雑化してしまう。

別の例を挙げると、これとは対照的に、データキャッシュ１５０のようなキャッシュメモリを用いて、同様にトランザクション的処理の機能を維持しつつ、更新をバッファリングする。ここにおいて、キャッシュ１５０は、データアイテムをバッファ済みコヒーレンシ状態で保持することができる。あるケースでは、新しくバッファ済みコヒーレンシ状態を、ＭＥＳＩ（変更、排他、共有、無効：Ｍｏｄｉｆｉｅｄ Ｅｘｃｌｕｓｉｖｅ Ｓｈａｒｅｄ Ｉｎｖａｌｉｄ）プロトコル等のキャッシュコヒーレンシプロトコルに追加して、ＭＥＳＩＢプロトコルを作成する。キャッシュ１５０は、バッファされているデータアイテム、つまり、バッファ済みコヒーレンシ状態で保持されているデータアイテムについてのローカル要求に応じて、データアイテムをローカル処理要素に供給して、内部でのトランザクションの逐次的順序を保証する。しかし、外部からのアクセス要求に対しては、ミス応答を供給して、トランザクション的に更新されたデータアイテムがコミットまではグローバルに可視化されないようにする。さらに、キャッシュ１５０のあるラインがバッファ済みコヒーレンシ状態で保持されておりエビクションの対象に選択されると、このバッファされている更新は高位レベルのキャッシュメモリには書き戻されない。このバッファされている更新はメモリシステム内で拡散されない。つまり、コミットが完了するまではグローバルに可視化されない。コミットが完了すると、バッファされているラインは、修正済み状態に遷移して、データアイテムをグローバルに可視化する。

尚、「内部」および「外部」という用語は通常、トランザクションの実行に対応付けられているスレッドまたはキャッシュを共有している複数の処理要素の観点から見た「内部」および「外部」である。例えば、トランザクションの実行に対応付けられているソフトウェアスレッドを実行する第１の処理要素をローカルスレッドと呼ぶ。このため、上記の説明では、第１のスレッドによって以前に書込が行われ、対応するキャッシュラインがバッファ済みコヒーレンシ状態で保持されているアドレスに対するストアまたはロードを受信すると、ローカルスレッドである第１のスレッドには当該キャッシュラインのバッファ済みバージョンを提供する。対照的に、同じプロセッサの別の処理要素において実行されている第２のスレッドは、バッファ済み状態で保持されているキャッシュラインに対応するトランザクションの実行に対応付けられておらず、外部スレッドとなる。このため、第２のスレッドからこのアドレスへのロードまたはストアは、このキャッシュラインのバッファ済みバージョンはミスして、通常のキャッシュ置換を利用してより高位レベルのメモリからこのキャッシュラインの未バッファバージョンを取得する。

ここにおいて、「内部／ローカル」スレッドおよび「外部／リモート」スレッドは、同じプロセッサで実行されており、一部の実施形態では、プロセッサの同じコアにおける、キャッシュへのアクセスを共有している別個の処理要素で実行されるとしてもよい。しかし、これらの用語の意味は上記の内容に限定されない。上述したように、「ローカル」は、トランザクションの実行に対応付けられている１つのスレッドに限定されるのではなく、キャッシュへのアクセスを共有している複数のスレッドを意味するとしてよい。一方、「外部」または「リモート」は、キャッシュへのアクセスを共有していない複数のスレッドを意味するとしてよい。

図１について最初に言及したように、プロセッサ１００のアーキテクチャは説明のための例示的なものに過ぎない。同様に、メタデータの参照のためにデータアドレスを変換する具体例も一例に過ぎず、同一メモリの別個のエントリにおいてデータとメタデータとを対応付けるには、どのような方法を用いるとしてもよい。

＜メタデータのためのメタフィジカルアドレス空間＞
＜メタデータ＞
図２を参照すると、プロセッサにおいてデータアイテムのメタデータを保持する実施形態を図示している。同図に示すように、データアイテム２１６のメタデータ２１７はメモリ２１５においてローカルに保持されている。メタデータは、データアイテム２１６に対応付けられている任意の特性または属性、例えば、データアイテム２１６に関するトランザクション的情報を含む。説明のためにメタデータの例を幾つか後述する。しかし、開示しているメタデータの例は、例示的なものに過ぎず、全てを網羅しているものではない。また、メタデータ位置２１７は、後述する例と、具体的には説明しないがデータアイテム２１６の他の属性とを組み合わせて保持するとしてもよい。

第１の例を挙げると、メタデータ２１７は、データアイテム２１６が以前に、トランザクションにおいてアクセスされたか、バッファされたか、および／または、バックアップされたかしている場合には、トランザクション的に書き込まれたデータアイテム２１６のバックアップ位置またはバッファ位置への参照を含む。この場合、一部の実施例では、データアイテム２１６の以前のバージョンのバックアップコピーが別の位置で保持されているので、メタデータ２１７はこのバックアップ位置へのアドレス等の参照を含む。これに代えて、メタデータ２１７自体がデータアイテム２１６のバックアップ位置またはバッファ位置として機能するとしてもよい。

別の例を挙げると、メタデータ２１７は、データアイテム２１６への繰り返しのトランザクション的アクセスを加速するためのフィルタリング値を含む。多くの場合、ソフトウェアを用いたトランザクションの実行時には、コンシステンシおよびデータ有効性を保証するためにトランザクション的メモリアクセスではアクセスバリアが実行される。例えば、トランザクション的ロード処理の前に、読出バリアを実行して読出バリア処理を実施する。例えば、データアイテム２１６がロックされていないか否かを試験したり、当該トランザクションの現在の読出設定が依然として有効か否かを判断したり、フィルタリング値を更新したり、後に検証できるように当該トランザクションの読出設定のバージョン値を記録したりする。しかし、当該トランザクションの実行中にこの位置の読出が既に実行されている場合、同じ読出バリア処理は不要である。

このため、解決方法の１つとして、読出フィルタを利用して、データアイテム２１６または当該アドレスに対する読出は当該トランザクションの実行中には実施されていない旨を示す第１のデフォルト値を保持して、データアイテム２１６または当該アドレスに対するアクセスが既に当該トランザクションの実行中に行なわれている旨を示す第２のアクセス済み値を保持する。基本的に、第２のアクセス済み値は、読出バリアを加速すべきか否かを示す。本例では、トランザクション的ロード処理を受信して、メタデータ位置２１７の読出フィルタリング値がデータアイテム２１６が既に読み出されていることを示す場合、一実施形態では、読出バリアを省略して、実施せず、不要で冗長な読出バリア処理を実行しないことによって、トランザクション的実行を加速する。尚、書込フィルタリング値も、書込処理について同じような構成を持つとしてよい。しかし、各フィルタリング値は例示的なものに過ぎず、一実施形態によると、１つのフィルタリング値を用いて、あるアドレスについて書込または読出のいずれであろうともアクセスが既に行なわれたか否かを示す。ここにおいて、データアイテム２１６のメタデータ２１７をロードおよびストアの両処理について確認するメタデータアクセス処理ではこのような１つのフィルタリング値を利用する。これは、メタデータ２１７が読出フィルタリング値および書込フィルタリング値を別々に含む上記の例とは対照的である。説明のために具体的な実施形態を挙げると、メタデータ２１７の４ビットを、対応付けられているデータアイテムについて読出バリアを加速すべきか否かを示す読出フィルタ、対応付けられているデータアイテムについて書込バリアを加速すべきか否かを示す書込フィルタ、取消処理を加速すべきか否かを示す取消フィルタ、および、ソフトウェアによって任意の方法でフィルタリング値として用いられる雑則フィルタに割り当てる。

メタデータの例を他にも幾つか挙げると、データアイテム２１６に対応付けられているトランザクションに固有のハンドラまたは汎用ハンドラ用のアドレスの指定、説明または参照、データアイテム２１６に対応付けられているトランザクションの取消不能度／強固度、データアイテム２１６の損失、データアイテム２１６の監視情報の損失、データアイテム２１６に関するコンフリクトの検出、データアイテム２１６に対応付けられている読出設定の読出エントリまたは読出設定のアドレス、以前に記録されたバージョンのデータアイテム２１６、現在のバージョンのデータアイテム２１６、データアイテム２１６へのアクセスを許可するロック、データアイテム２１６のバージョン値、データアイテム２１６に対応付けられているトランザクションのトランザクション記述子、および、その他の公知のトランザクションに関連する記述情報がある。さらに、上述したように、メタデータの用途はトランザクションの情報に限定されない。このため、メタデータ２１７はさらに、トランザクションに関連しない、データアイテム２１６に対応付けられている情報、特性、属性または状態を含むとしてもよい。

メタデータについての説明を続けると、上述したハードウェアの監視部およびバッファ済みコヒーレンシ状態もまた、一部の実施形態ではメタデータと見なされる。監視部は、ある位置に対する外部読出要求または外部所有権読出要求を監視すべきか否かを示し、バッファ済みコヒーレンシ状態はデータアイテムを保持している対応データキャッシュラインがバッファされているか否かを示す。しかし、上記の例では、監視部は、キャッシュラインに付加されている属性ビットまたはキャッシュラインと直接対応付けられている属性ビットとして維持され、バッファ済みコヒーレンシ状態は、キャッシュラインコヒーレンシ状態ビットに追加される。このため、この場合には、ハードウェアの監視部およびバッファ済みコヒーレンシ状態は、キャッシュライン構造の一部を成しており、メタデータ２１７と図示しているような別のメタフィジカルアドレス空間では保持されない。しかし、他の実施形態では、監視部は、データアイテム２１６とは別のメモリ位置においてメタデータ２１７として保持されているとしてもよく、同様に、メタデータ２１７は、データアイテム２１６がバッファ済みデータアイテムである旨を示す参照を含むとしてもよい。逆に、データアイテム２１６が更新されてバッファ済み状態で保持される上述のその場更新アーキテクチャの代わりに、メタデータ２１７がバッファ済みデータアイテムを保持して、データアイテム２１６のグローバルに可視のバージョンは元々の位置で維持されるとしてもよい。この場合、コミットされると、メタデータ２１７に保持されているバッファ済み更新でデータアイテム２１６を置換する。

＜損失の多いメタデータ＞
バッファ済みキャッシュコヒーレンシ状態に関して上述したように、一実施形態によると、メタデータ２１７は損失が多く、メモリ２１５のドメインの外部からの外部要求には提供されないローカル情報である。一実施形態においてメモリ２１５が共有キャッシュメモリであると仮定すると、メタデータアクセス処理に対するミスは、キャッシュメモリ２１５のドメインの外部では提供されない。基本的に、損失が多いメタデータ２１７は、キャッシュドメイン内でローカルにのみ保持されており、メモリサブシステム全体で通用するデータとしては存在しないので、ミスを外部に渡して高位レベルメモリからの要求に答える理由はない。このため、損失の多いメタデータについてのミスは、高速且つ効率的に提供され、メタデータに対する外部要求が生成または提供されるまで待機することなく、プロセッサにおけるメモリが即座に割り当てられるとしてよい。

＜メタフィジカルアドレス空間＞
図示した実施形態で示すように、メタデータ２１７は、データアイテム２１６とは別のメモリ位置、つまり、異なるアドレスに保持されており、メタデータには別のメタフィジカルアドレス空間が存在することになる。メタフィジカルアドレス空間は、データアドレス空間と直交する空間で、メタフィジカルアドレス空間に対するメタデータアクセス処理が、物理的データエントリをヒットまたは修正することはない。しかし、メタデータがメモリ２１５等の同一メモリに保持されている実施形態では、メタフィジカルアドレス空間は、メモリ２１５における割り当てに関する競合のために、データアドレス空間に影響を及ぼす可能性がある。一例を挙げると、データアイテム２１６はメモリ２１５のエントリにキャッシュされており、データ２１６のメタデータ２１７はキャッシュの別のエントリに保持されている。この場合、後続のメタデータ処理では、データアイテム２１６のメモリ位置をエビクションの対象として選択して、別のデータアイテムのメタデータを代わりに保持する可能性がある。このため、メタデータ２１７のアドレスに対応付けられている処理はデータアイテム２１６をヒットしないことになり、メモリ２１５内のデータアイテム２１６等の物理データの代わりにメタデータ要素のメタデータアドレスが保持される。

本例ではメタデータとデータとがキャッシュメモリ内の空間について競合するが、メタデータをローカルに保持できると、メモリヒエラルキー全体において通用するメタデータを拡散する高コストを必要とすることなく、メタデータが効率的にサポートされる。メタデータは同一メモリ、つまりメモリ２１５に保持されるこの例の仮定から推定されるように、別の実施形態では、データアイテム２１６の／データアイテム２１６に対応付けられているメタデータ２１７は、別のメモリ構造で保持される。この場合、メタデータのアドレスおよびデータのアドレスは同じであるが、メタデータアドレスのメタフィジカル部分によって、データストレージ構造の代わりに別のメタデータストレージ構造に導かれる。

メタデータとデータとの割合が１対１である場合、メタフィジカルアドレス空間は、データアドレス空間にシャドウするが、上述したように直交となる。これとは対照的に、以下に説明するが、メタデータを物理データに対して圧縮するとしてよい。この場合、メタデータ用のメタフィジカルアドレス空間のサイズは、データアドレス空間のサイズにシャドウしないが、依然として直交となる。

＜メタフィジカルアドレス変換＞
メタフィジカルアドレス空間の説明を続けると、データアドレス空間内のデータアドレス、例えば、データアイテム２１６のアドレスを、メタフィジカルアドレス空間内のメタフィジカルアドレス、例えば、メタデータ２１７用のメタデータアドレスに変換する場合には任意の方法を利用するとしてよい。一実施形態によると、メタフィジカル変換ロジック２１０を用いて、データアドレス２００等のアドレスをメタデータアドレスに変換する。図示しているように、アドレス２００は、データアイテム２１６に対応付けられているアドレス、または、データアイテム２１６を参照するアドレスを含む。通常のデータ変換、例えば、物理アドレスまたは線形アドレスと、仮想アドレスとの間での変換を利用して、メモリ２１５においてデータアイテム２１６にインデックスを付与するとしてよい。また、メタデータ２１７とデータアイテム２１６との対応付けは、データアイテム２１６を参照するアドレス２００から、メタデータ２１７を参照する別の異なるアドレスへの同様の変換を含むので、アドレス２００をデータ変換ロジック２０５でデータアドレスに変換すること、および、メタフィジカル変換ロジック２１０で別のメタフィジカルアドレスに変換することは、互いに干渉し合うことのない別々のアクセスとなり、これら２つのアドレス空間が直交することとなる。より詳細に後述するが、データ変換ロジック２０５またはメタフィジカル変換ロジック２１０は、一実施形態によると、アドレス２００に対するアクセス処理の種類に応じて利用され、データアイテム２１６にアクセスする通常のデータアクセス処理の場合はデータ変換ロジック２０５を利用し、メタデータ２１７にアクセスするメタデータアクセス処理ではメタフィジカル変換ロジック２１０を利用する。これは、命令／処理のオペレーションコード（オペコード）の一部分で特定され得る。

別の実施形態では、命令は、そのオペコードで特定されるように、所与のメタデータアドレスについてメタデータおよびデータの両方にアクセスする場合があるので、複雑な処理、例えば、メタデータに基づくデータへの条件付きストアを実行するとしてよい。一例を挙げると、命令は、メタデータを試験してある値に設定するためのメタデータ試験および設定処理にデコードされると共に、メタデータの試験が成功した場合にはデータをある値に設定する追加処理にデコードされる。別の例によると、データアイテムを、データメモリから読み出したデータに基づき、一致するメタデータアドレスに移動させるとしてよい。

データアドレス２００をメタデータ２１７用のメタデータアドレスに変換する例を以下で説明する。第１の例として、データアドレスをメタデータアドレスに変換することは、通常のデータ変換ロジック２０５の処理後に、物理アドレスまたは仮想アドレスを利用することと、メタデータアドレスからデータアドレスを分離するメタフィジカル変換ロジック２１０でメタフィジカル値を追加することとを含む。変換を行なうことなく仮想アドレスを利用する場合には、メタフィジカル変換ロジック２１０は、仮想アドレスとメタフィジカル値とを組み合わせるロジックを含む。しかし、通常の仮想−物理アドレス変換が利用される場合には、通常のデータ変換ロジック２０５を用いてアドレス２００から変換後のアドレスを取得し、メタフィジカル変換ロジック２１０が備えるロジックで、変換後のアドレスとメタフィジカル値とを組み合わせてメタデータアドレスを生成する。別の例を挙げると、データアドレス２００は、メタフィジカル変換ロジック２１０内の別個の変換構造、変換テーブルおよび／または変換ロジックを利用して変換され、区別可能なメタデータアドレスを取得するとしてよい。この場合、メタフィジカル変換ロジック２１０は、データ変換ロジック２０５と比較して、アドレス２００をメタフィジカル値と組み合わせるロジック等の別のロジックをミラーリングしているか、または、有しているが、メタフィジカル変換ロジック２１０は、アドレス２００を別の区別可能なメタデータアドレスに変換するためのページテーブル情報を含む。メタデータアドレスに情報を追加すること、メタデータアドレスに付加した情報で拡張すること、メタデータアドレスに含まれる情報を置換すること、または、データアドレスを変換してメタデータアドレスを取得することによって、結果として得られる区別可能なメタデータアドレスは、データアイテムを間違って更新したり読み出すことに対して直交性を維持しつつ、追加、拡張、置換または変換のためのアルゴリズムを用いて、データアイテムに対応付けられることが分かる。

説明のために、データアドレスをメタデータアドレスに変換する処理、つまり、データアドレスに基づきメタデータアドレスを決定する処理の具体例を幾つか以下で挙げる。

（１）通常の仮想−物理アドレス変換を用いて第１のデータアドレスを第２のデータアドレスに変換し、メタフィジカル値を当該データアドレスに追加、付加、または、含めてメタデータアドレスを形成する。
（２）仮想−物理アドレス変換をデータアドレスに対して実行せず、メタフィジカル値をデータアドレスに追加、付加、または含めて、メタデータアドレスを形成する。
（３）メタフィジカル変換テーブルロジックを用いてデータアドレスを変換後メタデータアドレスに変換する。必ずしも必要ではないが、メタフィジカル値を変換後メタデータアドレスに追加、付加、または含めて、メタデータアドレスを形成する。さらに、上述した変換方法はいずれも、データ対メタデータの圧縮比を組み込み、つまり、当該圧縮比に基づいて行なわれ、圧縮比毎にメタデータを別個に格納する。

この場合、変換および／または圧縮のためにアドレスを修正するとしてよい。例えば、アドレスの特定のビットを無視したり、アドレスの特定のビットを削除したり、データの粒度を選択するためにどのビット範囲をアドレスにおいて利用するかを変更したり、特定のビットを変換したり、特定のビットを追加するかまたはメタデータ関連情報で置換したりするとしてよい。圧縮については図４を参照しつつ詳細に後述する。

＜複数のメタフィジカルアドレス空間＞
図３では、複数のメタフィジカルアドレス空間をサポートする実施形態を図示している。一実施形態によると、処理要素毎に１つのメタフィジカルアドレス空間に対応付けられており、各処理要素は独立したメタデータを維持可能である。４つの処理要素３０１−３０４を図示している。上述したように、処理要素は、図１を参照しつつ上述した要素のうちいずれを含むとしてもよい。第１の例を挙げると、複数の処理要素は、１つのプロセッサの複数のコアを含む。しかし、以下に記載する説明のための例から分かるように、処理要素３０１−３０４は、１つのプロセッサにおける複数のハードウェアスレッド（スレッド）に関連付けて説明する。各ハードウェアスレッドは、１つのソフトウェアスレッドおよび複数のソフトウェアサブシステムを実行する。

このため、スレッド３０１−３０４の各スレッドに別個のメタデータを維持させるのが有益である。一実施形態によると、メタフィジカル変換ロジック３１０は、複数の異なるスレッド３０１−３０４からのアクセスを、適切なメタフィジカルアドレス空間に対応付ける。一例を挙げると、メタデータアクセス処理によって参照されるアドレスと共に利用されるスレッド識別子（ＩＤ）によって、正しいメタフィジカルアドレス空間へと導かれる。

説明のために、スレッド３０２に対応付けられており、データアイテム３１６のデータアドレス３００を参照するメタデータアクセス処理を受信したと仮定する。上述したように任意の変換方法を利用して、データアイテム３１６用のデータアドレスをメタデータアドレスに変換するとしてよい。しかし、この変換処理はさらに、スレッドＩＤ３０２を組み合わせることを含む。スレッドＩＤ３０２は、例えば、スレッド３０２用の制御レジスタから取得するとしてもよいし、または、スレッド３０２から受信した命令のオペコードから受信するとしてもよい。この組み合わせ処理は、スレッドＩＤ３０２をアドレスに付加すること、アドレスに含まれるビットを置換すること、または、その他の公知のスレッドＩＤとアドレスとを対応付ける方法を実行することを含むとしてよい。このようにして、メタフィジカル変換ロジック３１０は、処理要素３０２について、データアイテム３１６に対応付けられているメタフィジカルアドレス空間を選択することができる／当該メタフィジカルアドレス空間に誘導され得る。

この例から推測すると、メタフィジカルアドレスへの変換の一環としてスレッド３０１−３０４についてスレッドＩＤを利用することによって、処理要素３０１−３０４はそれぞれ、データアイテム３１６について、独立してメタデータを維持可能である。しかし、プログラマは、複数のメタフィジカルアドレス空間を別個に管理する必要はない。これは、ハードウェアが、ソフトウェアに対してトランスペアレントに、スレッドＩＤを用いて複数のメタフィジカルアドレス空間を分離することが可能なためである。また、メタデータアクセス毎に、一意的なスレッドＩＤへの参照を含む別個のアドレス群に対応付けられているので、複数のメタフィジカルアドレス空間は直交しており、あるスレッドからのあるメタデータアクセスは別のスレッドからのメタデータにアクセスすることはない。

しかし、後述するように、メタデータにアクセスする命令／処理に関して、あるスレッドからのメタデータアクセスが別のスレッドのメタデータへのアクセスを提供される場合があり得る。つまり、一部の実施例では、複数のＰＥＩＤおよび／またはＭＤＩＤ（後述する）にわたるアクセスが有益である場合がある。例えば、ハードウェアがコンフリクトを検出したか否かを判断するために、別のスレッドからのメタデータの監視を確認して、対応付けられているデータアイテムを別のスレッドが監視しているか否かを判断するために、他のスレッドのメタデータをクリアするために、または、スレッドが確認する必要があるコミット条件を判断するために、データアイテム３１６に対応付けられている他のスレッドのメタデータを修正またはクリアする。

この場合、別のスレッドのメタデータにアクセスするための処理についての特定のオペコードが認識されるので、メタフィジカル変換ロジック３１０は、アドレス３００の変換を実行して、アクセスすべきメタデータについて全てのメタデータアドレスを得る。説明のために具体例を挙げると、４ビットがアドレス３００に付加されており、各ビットは処理要素３０１−３０４のうちの１つを表しており、クリア処理等のメタデータアクセス処理はデータアイテム３１６についての全てのメタデータをクリアして、メタフィジカル変換ロジック３１０は全てのメタデータ３１７にアクセスするように４ビットの各ビットを設定する。この場合、メモリ３１５用のルックアップロジックは、４ビット全てが設定されている１つのアクセスで全てのメタデータ３１７にアクセスするように設計されているか、または、メタフィジカル変換ロジック３１０は、４つの別個のアクセスを生成して、全てのメタデータ３１７にアクセスするように、それぞれにおいて４ビットのうち異なるスレッドＩＤビットを設定するとしてよい。説明のために一例を挙げると、マスクをアドレス値に適用して、１つのスレッドに別のスレッドのメタデータをヒットさせるとしてもよい。

また、図示しているように、処理要素３０１−３０４はそれぞれ、複数のメタフィジカルアドレス空間に対応付けられており、１つのスレッドにおける複数のコンテクストまたはソフトウェアサブシステムを、複数のメタデータアドレス空間に対してインターリーブするとしてよい。例えば、１つの処理要素の複数のソフトウェアサブシステムに複数の独立したメタデータ集合を維持させることが有益である場合がある。このため、一例を挙げると、直交するメタデータアドレス空間は、さまざまな処理要素レベルで提供されるとしてよい。例えば、コアレベル、ハードウェアスレッドレベル、および／または、ソフトウェアサブシステムレベルで提供されるとしてよい。図中では、処理要素３０１−３０４はそれぞれ、２つのメタフィジカルアドレス空間に対応付けられており、これら２つのメタフィジカルアドレス空間はそれぞれ、処理要素のうち何れか１つで実行される複数のソフトウェアサブシステムと対応付けられる。

ソフトウェアサブシステムは、別個のメタフィジカルアドレス空間を利用する処理要素で実行されるべき任意のタスクまたはコードを含む。説明のための例を挙げると、個別にメタフィジカルアドレス空間に対応付けられる４つのサブシステムは、１つの処理要素で実行されるトランザクショナルランタイムサブシステム、ガベージコレクションランタイムサブシステム、メモリ保護サブシステム、および、ソフトウェア変換サブシステムを含む。この場合、ソフトウェアサブシステムはそれぞれ、この処理要素の制御を持つタイミングが異なるとしてよい。別の例を挙げると、１つのソフトウェアサブシステムは、１つの処理要素で実行される複数の別個のトランザクションを含む。実際には、同一スレッドで実行される複数のネスト化されたトランザクションは別々のメタフィジカルアドレス空間に対応付けられることが望ましいとしてよい。説明すると、外側のトランザクションにおけるデータアイテムへのアクセスについてのフィルタリング試験は失敗に終わる可能性があるが、内側のネスト化されたトランザクションにおける同じデータアイテムに対するアクセスについての第２の別のフィルタを提供するのは有益である。この第２の別のフィルタは別に、内側のトランザクションにおけるアクセスを加速することに成功する可能性がある。さらに、ネスト化された内側のトランザクションがアボートされると、外側のトランザクションのためにメタデータを維持するために、ネスト化されたトランザクション、つまり、サブシステムはそれぞれ、異なるメタデータ空間と対応付けられており、内側のネスト化されたトランザクションのメタデータのクリアが外側のトランザクションのメタデータに影響を及ぼさないようにする。しかし、ソフトウェアサブシステムは、メタデータを管理することが出来る任意のタスクまたはコードであってよく、これに限定されない。

一実施形態によると、ソフトウェアサブシステムのレベルにおいて直交するメタフィジカルアドレス空間を提供するために、アドレスは、上述したように処理要素ＩＤ（ＰＥＩＤ）と組み合わせて、さらにメタデータＩＤ（ＭＤＩＤ）またはコンテクストＩＤと組み合わせる。このため、別のメタデータを、処理要素内のサブシステムについて一意的に特定するとしてよい。上記の例を用いて、処理要素３０１−３０４がハードウェアスレッドであり、スレッド３０２が外側トランザクションおよびこの外側トランザクションの内側にネスト化されている内側トランザクションを実行していると仮定する。外側トランザクションについて、メタデータ３１７ｃが、データアイテム３１６のデータアドレス３００をアドレスおよびスレッドＩＤ（ＴＩＤ）と、メタデータ３１７ｃを参照する外側トランザクションのためのメタデータＩＤ（ＭＤＩＤ）とに変換するメタフィジカル変換ロジック３１０によってデータアイテム３１６に対応付けられている。

説明のための一例に過ぎないが、メタデータ３１７ｃは、読出フィルタリング値、書込フィルタリング値、取消フィルタリング値、および、雑則フィルタリング値の４つのフィルタリング値、データアイテム３１６のバックアップ位置に対するポインタまたはその他の参照、データアイテム３１６に対する監視部が失われたか否かを示す監視値、トランザクション記述子値、および、データアイテム３１６のバージョン値を含む。同様に、内側トランザクションは、メタデータ３１７ｃと同じメタデータフィールドを含む、データアイテム３１６のためのメタデータ３１７ｄと対応付けられている。上述したように、メタフィジカル変換ロジック３１０は、データアイテム３１６のためのデータアドレス３００を、メタデータ３１７ｄを参照する内側トランザクションのメタデータＩＤおよびスレッドＩＤと組み合わせたアドレスに変換する。

この場合、メタデータ３１７ｃを参照しているメタデータアドレスと、メタデータ３１７ｄを参照しているメタデータアドレスとの間の相違点は、外側トランザクションおよび内側トランザクションのためのメタデータＩＤだけであるが、アドレスについてのこの相違点によって、アドレス空間同士が互いに別個となる／直交することとなり、内側トランザクションからのアクセスのＭＤＩＤは、外側トランザクションからのアクセスのものとは異なるので、内側トランザクションからのメタデータへのアクセスは、外側トランザクションからのメタデータに影響を及ぼすことはない。上述したように、これは、ネスト化されたトランザクションをロールバックする上で、または、トランザクションのレベル毎に異なるメタデータ値を保持する上で有益である場合がある。具体的には、内側トランザクションがアボートされると、メタデータ３１７ｄに保持されているデータアイテム３１６のバックアップデータは、クリアされるか、または、クリアすることなくあるいはメタデータ３１７ｃに保持されている外側トランザクションのバックアップデータに影響を与えることなく、データアイテム３１６を内側トランザクション前のエントリポイントにロールバックするために用いられるとしてよい。

尚、ソフトウェアサブシステムメタフィジカルアドレス空間同士を分離するためのメタデータＩＤ（ＭＤＩＤ）は、任意のサイズであってよく、さまざまなソースから得られるとしてよい。非常に簡略した例を説明のために挙げると、４つの処理要素（ＰＥ）３０１−３０４がある場合、ＰＥＩＤは２ビットの組み合わせ、００、０１、１０、１１であるとしてよい。同様に、４つの別個のメタフィジカルアドレス空間がサポートされている場合、２ビットから成るＭＤＩＤ、００、０１、１０、１１で同様に４つのサブシステムを区別可能である。説明すると、処理要素３０２およびＰＥ３０２内の第２のサブシステムを表す値は、０１０１を含む（最初の２ビットの０１はＰＥ３０２を表し、続く２ビットの０１は第２のサブシステムを表す）。本例では、メタフィジカル変換ロジックは、この値と、データアドレス３００またはデータアドレス３００の変換後の値とを組み合わせて、メタデータ位置３１７ｄを含むＰＥ３０２のＭＤＩＤである０１を参照する。

しかし、スレッドＩＤおよびＭＤＩＤは共に、より複雑であってもよい。例えば、スレッド３０１−３０２がメモリ３１５へのアクセスを共有しており、スレッド３０３−３０４がメモリ３１５へのアクセスを共有していないリモート処理要素であると仮定する。また、スレッド３０１−３０２はそれぞれ２つのソフトウェアサブシステムをサポートしており、スレッド３０１−３０２については、ＰＥ３０１ ＭＤ０、ＰＥ３０１ ＭＤ１、ＰＥ３０２ ＭＤ０、およびＰＥ３０２ ＭＥ１という合計で４つの直交するアドレス空間がサポートされていると仮定する。この場合、メタデータアドレスを取得するために用いられるスレッドＩＤとＭＤＩＤとを組み合わせた値は、オペコード、制御レジスタ、または、これらの組み合わせから得られるとしてよい。説明すると、オペコードは、コンテクスト／ＭＤＩＤのために１ビットを提供し、制御レジスタは、処理要素は２つのみと仮定して、処理要素ＩＤ（ＰＥＩＤ）のために１ビットを提供し、ＭＤＣＲ３２０等のメタデータ制御レジスタは、細粒化のために特定のソフトウェアサブシステム／コンテクストを特定するための４ビットを提供する。このため、データアイテム３１６のアドレス３００を参照しているメタデータアクセス処理を第２のスレッドＰＥ３０２から受信すると、オペコードからの１ビット、つまり、第２のコンテクストを示す１を含む第１のビット、および、処理要素３０２の制御レジスタからの第２のビット、処理要素３０２を示す１を含む第２のビットを、第２のスレッドに対応付けられているメタデータ制御レジスタ（ＭＤＣＲ）３２０からのＭＤＩＤと組み合わせる。ＭＤＣＲは、受信した処理に対応付けられている適切なサブシステムを特定するべく、第２のスレッド「００１０」を制御している現在のサブシステムのＭＤＩＤで既に更新されている。メタフィジカル変換ロジックは、組み合わせた値、例えば「１１００１０」を取得して、さらに参照されているデータアドレス３００またはデータアドレス３００の変換後の値と組み合わせて、メタデータアドレスを取得する。しかし、メタデータアドレスの「１１００１０」部分は、アクセス処理の出所であるサブシステムについて一意的であるので、第２のスレッドおよびその他のスレッドにおけるその他のサブシステムのメタフィジカルアドレス空間であって互いに直交しているメタデータアドレス３１７ａ、ｂ、ｃ、ｅ、ｆ、ｇ、ｈをヒットまたは影響を与えることなく、メモリ３１５内のメタデータアドレス３１７ｄのみをヒットまたは修正する。

説明のために具体例を挙げて、ＭＤＣＲの具体的な形態を説明する。一部の実施形態によると、ＩＳＡは、ＭＤＩＤをＭＤＩＤ依存性メタデータロード／ストア／試験／設定命令へと供給するスレッド毎のメタデータ識別子レジスタ（ＭＤＩＤレジスタ）で拡張されるとしてよい。一部の実施形態によると、このようなレジスタを複数備えると便利である。例えば、メタデータ制御レジスタ（ＭＤＣＲ）は、現在のメタデータコンテクストＩＤ（ＭＤＩＤ）を保持する３２ビットの読み書きレジスタである。ＣＲ ＭＯＶで更新されるとしてよい。ビットフィールドの定義の一例を以下に示す。

ＭＤＩＤ０およびＭＤＩＤ１は、命令群で同時にアクセス可能なメタデータＩＤである。これらのフィールドのうち実際に利用されるビット数は、ＭＤＩＤ＿ｓｉｚｅである。一実施形態によると、このフィールドは、プロセッサ設計で仕様が定められているので、許可レベルでのみ読み出される。しかし、他の実施形態によると、他のレベルの特権レベルでこのサイズを修正可能であるとしてもよい。ＭＤＩＤがこの割り当てられたビットサイズに収まっていることを確認するハードウェア確認メカニズムはないとしてよい。一実施形態によると、ＭＤＩＤ０およびＭＤＩＤ１は、任意の許可レベルで読み書きが可能である。また、読出結果が常に０または１となる特別なメタデータ空間を指定する特別なＭＤＩＤ値を利用することも可能であるとしてよい。これは、図６および図７を参照して説明するメタデータ値を強制するレジスタと同様に、あるブロック内の全てのメタデータ試験を真または偽に強制するソフトウェアによって利用されるとしてよい。

しかし、別の例では、上述したように、メタフィジカル変換ロジック３１０は、デコーダ（不図示）と共に、スレッド３０１のメタデータアドレス空間のメタデータにアクセスすることを意図している、スレッド３０２からのメタデータアクセス処理を認識することができ、このような特定の命令／処理のアクセスに対してスレッド３０１のメタデータの読出または修正を許可する。

＜データに対するメタデータの圧縮＞
上記では、データ対メタデータを１対１でマッピングする場合、圧縮されていないメタデータを説明した。しかし、データに比べて量が削減されたメタデータを利用すること、メタデータのサイズをデータのサイズよりも小さくするメタデータの圧縮がより効率的である場合もある。尚、図２および図３に示すメタフィジカルアドレス変換ロジック２１０および３１０は、アドレスの変換および修正を行なう際には、圧縮を考慮に入れて、圧縮メタデータを参照するようにするとしてよい。図４は、メタデータの圧縮を実現するようにアドレスを修正する実施形態を示す。具体的には、データ対メタデータの圧縮比が８である実施形態を示す。図２および図３のメタフィジカルアドレス変換ロジック２１０および３１０等の制御ロジックは、メタデータアクセス処理によって参照されているデータアドレス４００を受信する。一例を挙げると、圧縮は、アドレス４００においてｌｏｇ２（Ｎ）個のビットをシフト、または、アドレス４００からｌｏｇ２（Ｎ）個のビットを削除することを含む。尚、Ｎは、データ対メタデータの圧縮比を表す。図示している例では、圧縮比が８の場合、メタデータアドレス４０５について、３ビットを下位シフトさせて削除する。基本的に、６４ビットを含み、メモリ内の特定のデータバイトを参照するアドレス４００は、３ビットを切り捨てて、バイトの粒度でメモリ内のメタデータを参照するために用いられるメタデータバイトアドレス４０５を形成する。このうち、メタデータバイトアドレスを形成するためにアドレスから既に削除された３ビットを用いてメタデータの１ビットが選択される。

一実施形態によると、シフト／削除されたビットの代わりに他のビットを利用する。図示しているように、アドレス４００がシフトされた後の高位ビットは、代わりにゼロを用いる。しかし、削除／シフトされたビットの代わりに他のデータまたは情報を用いるとしてもよい。例えば、メタデータアクセス処理に対応付けられているメタデータＩＤ（ＭＤＩＤ）、コンテクスト識別子（ＩＤ）および／または処理要素ＩＤを用いるとしてよい。本例では最下位ビットからの所定数ビットを削除したが、キャッシュ組成、キャッシュ回路タイミング、データに対するメタデータのローカル度、および、データとメタデータとの間のコンフリクトを最小限に抑える等、任意の数の要因に基づき、どの位置のビットを削除および置換するとしてもよい。

例えば、データアドレスはｌｏｇ２（Ｎ）だけシフトさせるのではなく、アドレスビット０：２をゼロにするとしてもよい。このため、同じである物理アドレスおよび仮想アドレスのビットは、上記の例のようにシフトされず、ビット１１：３等の修正されないビットでセットおよびバンクを事前に選択することが可能となる。

尚、変換に関する説明については、圧縮を組み合わせるとしてもよい。言い換えると、圧縮比は、図２および図３のメタフィジカルアドレス変換ロジック２１０および３１０に入力されるとしてよく、当該変換ロジックは、ＰＥＩＤ、ＣＩＤ、ＭＤＩＤ、メタフィジカル値、または、データアドレスをメタデータアドレスに変換するためのほかの情報と共に圧縮比を用いる。メタデータアドレスはこの後、メタデータを保持しているメモリにアクセスするために用いられる。上述したように、メタデータはローカルに生成されるものであるので、損失が多く、メタデータアドレスに基づきメモリに対してミスが発生すれば、即座に且つ効率的に対応され、メモリ位置の割り当ては、外部ミス対応要求を発生させることなく、且つ、対応すべき外部要求を待機することなく行なわれる。ここで、エントリは、通常のやり方で、メタデータについて割り当てられる。例えば、メタデータアドレス４０５および最長時間未使用（ＬＲＵ）アルゴリズム等のキャッシュ置換アルゴリズムに基づいて、図２に示すエントリ２１７等のエントリを選択して、割り当てて、メタデータデフォルト値に初期化する。このため、メタデータと通常のデータは空間について競合するが、メタデータは圧縮した状態を維持し、他のソフトウェアサブシステム／処理要素とは別のままである。

尚、圧縮比を８にするというのは一例に過ぎず、圧縮比は任意の値に設定するとしてよい。別の例を挙げると、圧縮比は、メタデータの１ビットがデータの６４バイトを表す５１２：１とする。上記と同様に、データアドレスを変換／修正して、ｌｏｇ２（５１２）ビット、つまり、９ビットだけデータアドレスを下位シフトすることによって、メタデータアドレスを形成する。この場合、ビット０：２の代わりに、ビット６：８は変わらず１ビットを選択するために利用され、５１２ビットの粒度で選択することによって効率的に圧縮が行われる。データアドレスが９ビットシフトされるので、データアドレスの高位部分には、９個のビット位置が空き、情報が保持され得る。一実施形態によると、この９ビットでは、コンテクストＩＤ、スレッドＩＤ、および／または、ＭＤＩＤ等の識別子を保持する。また、メタフィジカル空間値もまた、これらのビットで保持されているとしてよい。または、このアドレスをメタフィジカル値で拡張するとしてもよい。

一実施形態によると、複数の同時圧縮比がハードウェアでサポートされている。この場合、圧縮比を表す情報は、メタデータアドレスを取得するべくデータアドレスと組み合わせられたメタフィジカル値の一部として保持される。このため、このデータアドレスでメモリを検索する際には、圧縮比が考慮に入れられ、さまざまな圧縮比のアドレスと一致してしまうことはない。また、ソフトウェアは、ストア情報を、別の圧縮比のロードに転送しないように、ハードウェアを利用することができるとしてよい。

一実施形態によると、１つの圧縮比を利用してハードウェアを実現するが、当該ハードウェアはソフトウェアに対して複数の圧縮比を提示する他のハードウェアサポートを含む。一例を挙げると、図４に示すように、キャッシュハードウェアが８：１の圧縮比を用いて実現されていると仮定する。しかし、複数の異なる粒度でメタデータにアクセスするメタデータアクセス処理は、メタデータのうちデフォルト量を読み出すマイクロ処理と、メタデータ読出のうち適切な部分を試験する試験マイクロ処理とを含むようにデコードされる。一例を挙げると、メタデータ読出のデフォルト量は３２ビットである。しかし、８：１という異なる粒度／圧縮についての試験処理は、アドレスのうち所定数のビット、例えば、メタデータアドレスのＬＳＢから所定数のビットおよび／またはコンテクストＩＤに基づき、メタデータ読出の３２ビットのうち正しいビットを試験する。

説明として、データ１バイトにつきメタデータ１ビットというメタデータとデータとがアライメントされていない方式では、メタデータアドレスの下位３ビットに基づいて、メタデータの３２個の読み出したビットのうち下位８ビットから１ビットを選択する。１ワードのデータについては、２つの連続したメタデータビットを、アドレスの下位３ビットに基づいて、読み出したメタデータの３２ビットのうち下位１６ビットから選択し、１２８ビットのメタデータサイズについては１６ビットとなるまで同様に続く。

＜メタデータアクセス命令／処理＞
図５は、データに対応付けられているメタデータにアクセスする方法を説明するためのフローチャートである。図５に示すフローチャートの各ステップは実質的に逐次的に実行されるものとして図示されているが、少なくとも一部のステップを並行して実行するとしてよいし、順序を変更して実行するとしてもよい。

ステップ５０５において、所与のデータアイテムのデータアドレスを参照しているメタデータ処理を発見する。上記の説明では、メタデータ命令／処理は、メタデータの読出、修正および／またはクリアを実行するハードウェアでサポートされていると説明した。つまり、命令はプロセッサの命令セットアーキテクチャ（ＩＳＡ）でサポートされているので、プロセッサのデコーダはデータにアクセスする命令のオペレーションコード（オペコード）およびアクセスを実行するロジックを認識するとしてよい。尚、命令を利用するということも処理を意味するとしてよい。一部のプロセッサでは、それぞれ個別のタスクを実行する複数のマイクロ処理にデコードされ得るマクロ命令という概念を利用する。例えば、メタデータ試験および設定マクロ命令は、メタデータを試験するためのメタデータ試験処理／マイクロ処理にデコードされ、試験処理の結果として正しいブール値が取得されれば、設定処理でメタデータを特定の値に更新する。

しかし、メタデータアクセス処理は、メタデータにアクセスする明示的なソフトウェア命令に限定されず、メタデータに対応付けられているデータアイテムへのアクセスを含むより大型でより複雑な命令の一部としてデコードされた非明示的なマイクロ処理を含むとしてよい。ここにおいて、データアクセス命令は、複数の処理に、例えば、データアイテムにアクセスする処理および対応付けられているメタデータを非明示的に更新する処理にデコードされるとしてよい。

先述したように、一実施形態によると、ハードウェアでのメタデータとデータとの物理的マッピングは、ソフトウェアには直接見えない。このため、本例では、メタデータアクセス処理は、データアドレスを参照し、ハードウェアを利用して正しく変換、つまり、マッピングを実行して、メタデータに適切にアクセスする。しかし、メタデータアクセス処理はそれぞれ、出所のスレッド、コンテクストおよび／またはソフトウェアサブシステムによって、参照するメタフィジカルアドレス空間がそれぞれ異なり得る。このため、メモリは、ソフトウェアに対してトランスペアレントに、データアイテムのメタデータを保持するとしてよい。ハードウェアがメタデータへのアクセス処理を検出すると、明示的なオペレーションコード（命令のオペコード）によって、または、命令をメタデータアクセスマイクロ処理にデコードすることによって、当該ハードウェアは、メタデータにアクセスするためのアクセス処理が参照しているデータアドレスについて必要な変換を実行する。

この例で説明するように、プログラムは、図２および図３に示すデータアイテム２１６および３１６等のデータアイテムの同一アドレスを参照しているデータアクセス処理またはメタデータアクセス処理等の複数の別個の処理を含むとしてよく、ハードウェアは、これらのアクセスを、物理アドレス空間およびメタフィジカルアドレス空間等の異なるアドレス空間にマッピングするとしてよい。一部の実施形態によると、ＩＳＡは、所与の仮想アドレス、ＭＤＩＤ、圧縮比、および、オペランド幅のために、メタデータをロード／ストア／試験／設定する命令で拡張するとしてよい。これらのパラメータは何れかが、明示的な命令オペランドであってよく、オペコードにエンコードされているとしてよく、または、別個の制御レジスタから取得されるとしてよい。命令では、メタデータロード／ストア処理と他の処理とを組み合わせるとしてよい。例えば、一部のデータをロードして、そのうち一部のビットを試験して、後続の条件付きジャンプのための条件コードを設定するとしてよい。また、命令では、全メタデータ、または、特定のＭＤＩＤのメタデータのみをフラッシュするとしてもよい。以下にメタデータアクセス処理の一例を列挙する。尚、例として挙げる命令の一部は、具体的に６４Ｘの圧縮比の命令に関するものがあるが、具体的に開示していなくても、同様の命令を他の圧縮比に利用するとしてもよく、圧縮していないメタデータを利用するとしてもよい。

＜メタデータビット試験および設定（ＭＤＬＴ）＞
メタデータロードおよび試験命令（ＭＤＬＴ）は、引数を２つ含む。つまり、ソースオペランドとしてメタデータが対応付けられているデータアドレス、および、バイト、ワード、ｄワード、ｑワードまたはその他のサイズのビットを含むメタデータが書き込まれるレジスタ（デスティネーションオペランド）である。試験されたメタデータビットの値は、レジスタに書き込まれる。プログラマは、ＭＤＬＴ命令のデスティネーションレジスタに格納されているデータに関する知識について何も仮定すべきではなく、このレジスタを操作すべきではない。このレジスタは、同一アドレスへのメタデータストアおよび設定命令（ＭＤＳＳ）に対するソースオペランドとしてのみ利用される。一実施形態によると、ＭＤＬＴ命令は、試験処理および設定処理を組み合わせるが、試験が成功すれば、設定処理を破棄する。

＜メタデータストアおよび設定（ＭＳＳ）＞
メタデータストアおよび設定命令（ＭＤＳＳ）は、引数を２つ持つ。メタデータが対応付けられているデータアドレス、および、メモリに格納するべきバイト、ワード、ｄワード、ｑワードまたは他のサイズのビットを含むメタデータを格納しているレジスタ（ソースオペランド）である。ＭＤＳＳ命令は、ソースオペランドからの値において正しいビットを設定する。

＜メタデータストアおよびリセット命令（ＭＤＳＲ）＞
ＭＤＳＲ命令は、ソース引数を２つ持つ。ソースオペランドとしてメタデータが対応付けられているデータアドレス、および、リセットすべきバイト、ワード、ｄワード、ｑワードまたは他のサイズのビットを含むメタデータを格納しているレジスタ（ソースオペランド）である。ＭＤＳＲ命令は、ソースオペランドからの値において正しいビットをリセットする。

メタデータアドレスは、参照されているデータアドレスから決定される。メタデータアドレスを決定する例は、メタフィジカルアドレス変換および複数のメタフィジカルアドレス空間について説明した上記の内容に含まれている。しかし、圧縮比毎にメタデータを別々に格納するべく、変換にはデータ対メタデータの圧縮比を組み込む、つまり、データ対メタデータの圧縮比に基づいて変換を行なうことに留意されたい。

ＣＭＤＴ命令は、処理系依存の圧縮マッピング関数でメモリデータアドレスをメモリメタデータアドレスに変換して、当該メモリメタデータアドレスに対応するメタデータビットが設定されているか否かを試験する。一例を挙げると、圧縮比ＣＲは、８バイトについて１ビットである。メタデータアドレスの算出では、ＭＤＣＲレジスタのコンテクストＩＤのうち１つを組み込んで、各コンテクストＩＤについて一意的なＭＤ群を提供して、ＭＤＢＬＫ［ＣＲ］［ＭＤＣＲ．ＭＤＩＤ［ＭＤＩＤ番号］］．ＭＥＴＡをアドレス指定する。当該命令は、アドレス「ｍｅｍ」を特定されたデータサイズにアラインメントさせて、強制的にアラインメントされる。当該命令は、メタデータが設定されているか否かを試験する。

以下に、ＣＤＭＴ（ＺＦフラグはゼロのメタデータ値を表すように設定されている。他のフラグは全てクリアされている。）に関連する擬似コードの一例を記載する。

ＣＭＤＳ命令は、処理系依存の圧縮マッピング関数でメモリデータアドレスをメモリメタデータアドレスに変換する。圧縮比は、８バイトのデータについて１ビットである。ｉｍｍ８値のエンコードは、以下の通りである。０→ＭＤ＿Ｖａｌｕｅ；ＭＤに格納されるべき値および７：１→確保済み；未使用

以下に、ＣＭＤＳに対応付けられている擬似コードの一例を記載する。

ＣＭＤＣＬＲ命令は、ＭＢＬＫ（ｍｅｍ）にわたる範囲内の任意のデータに対応する全てのＭＤＢＬＫ［ＣＲ］［ＭＤＣＲ．ＭＤＩＤ［ＭＤＩＤ番号］］．ＭＥＴＡをリセットする。

ＣＭＤＣＬＲに関連する擬似コードの例を以下に記載する。

続いて、ステップ５１０では、圧縮比、処理要素ＩＤ、コンテクストＩＤ、ＭＤＩＤ、メタフィジカル値、オペランドサイズ、および／または、その他のメタフィジカルアドレス空間の変換に関連する値に基づいて、メタデータアクセス処理で参照されているデータアドレスに基づきメタデータアドレスを決定する。上述した方法、例えば、データアドレスを変換することなく、データアドレスを通常通りに変換して、または、データアドレスに別にメタフィジカルアドレス変換を実行して複数のＩＤ値を組み合わせる方法のいずれかを用いて、適切なメタデータアドレスを取得するとしてよい。

さらに、上述したように、一部の例では、あるバージョンの試験命令、設定命令、クリア命令等の命令は、１つのスレッドまたはメタデータコンテクストに他のスレッドまたはメタデータコンテクストのメタデータを試験、設定、またはクリアさせる。このため、メタデータアドレスへの変換は、あるスレッドまたはコンテクストのＩＤからのアクセスに別のスレッドまたはコンテクストのＩＤにアクセスさせるべく、マスクの適用等、アドレスの修正を含むとしてもよい。

ステップ５１５では、メタデータアドレスが参照しているメタデータにアクセスする。通常の場合は、要求元のローカルなスレッドまたはコンテクストのＩＤに対応付けられているメタデータの独立した位置にアクセスして、試験、設定およびクリア等の適切な処理を実行する。しかし別の場合には、上述したように、このステップにおいて、別のスレッドまたはコンテクストのＩＤのメタデータにアクセスするとしてもよい。

＜抽象化＞
以下ではソフトウェアの抽象化の実施形態を説明する。所与のＣＲは、メタデータの１ビットにマッピングされているデータのビット数を示す２の累乗である。利用する場合はどのＣＲ値を利用するかは実施系で定義されている。ＣＲ＞１は、圧縮されたメタデータを意味する。ＣＲ＝１は、圧縮されていないメタデータを意味する。

ＭＤＢＬＫ［ＣＲ］［＊］は、サイズがｃｅｉｌ（ＣＲ／８）バイトであって、自然にアラインメントされている。ＭＤＢＬＫは、自身の線形仮想アドレスではなく、物理データに対応付けられている。同じｆｌｏｏｒ（Ａ／ＭＤＢＬＫ［ＣＲ］［＊］＿ＳＩＺＥ）値を持つ有効な物理アドレスＡは全て、同じＭＤＢＬＫ群を指定する。

所与のＣＲについては、任意の数の識別可能なＭＤＩＤを設けることが可能で、各ＭＤＩＤは一意的なメタデータのインスタンスを指定している。所与のＣＲおよびＭＤＩＤのメタデータは、任意のその他のＣＲまたはＭＤＩＤのメタデータとは識別可能である。例えば、Ｔｈｄ＃０について、ａｄｄｒがＱＷＯＲＤでアラインメントされていると仮定すると、ＭＤＢＬＫ［ＣＲ＝６４］［ＭＤＩＤ＝３］（ａｄｄｒ）で指定されるメタデータブロックは、ＭＤＢＬＫ［ＣＲ＝６４］［ＭＤＩＤ＝３］（ａｄｄｒ＋７）と同じであるが、ＭＤＢＬＫ［ＣＲ＝６４］［ＭＤＩＤ＝４］（ａｄｄｒ）およびＭＤＢＬＫ［ＣＲ＝５１２］［ＭＤＩＤ＝３］（ａｄｄｒ）とは識別可能である。

所与の実施例では、複数のコンテクストを同時にサポートするとしてよい。この場合、コンテクスト数は、プロセッサが一部を成している特定のシステムに関する所定の設定情報およびＣＲに応じて決まる。圧縮されていないメタデータの場合、物理データのＱＷＯＲＤ毎に、メタデータのＱＷＯＲＤが設けられている。

メタデータを解釈するのは、ソフトウェアのみである。ソフトウェアは、特定のＭＤＢＬＫ［ＣＲ］［ＭＤＩＤ］のＭＥＴＡを設定、リセットまたは試験するとしてよく、または、全てのＴｈｄのＭＤＢＬＫ［＊］［＊］のＭＥＴＡをリセットするとしてよく、または、所与のＭＢＬＫ（ａｄｄｒ）と交差する全てのＴｈｄのＭＤＢＬＫ［ＣＲ］［ＭＤＩＤ］のＭＥＴＡをリセットするとしてよい。

メタデータの損失について、ＴｈｄのＭＥＴＡ特性は、自発的に０にリセットされる場合があり、この場合にはメタデータ損失イベントが発生する。

＜強制されたメタデータ値＞
図６は、強制されたメタデータ値に対するハードウェアサポートを提供する実施形態を説明するための図である。ＳＴＭは通常、アクセスバリアを用いてメモリアクセス処理間でのコンシステンシを保証する。例えば、データアイテムへのメモリアクセスに先立って、当該データアイテムに対応付けられているメタデータ位置またはロック位置を確認して、当該データアイテムが利用可能であるか否かを判断する。他のバリア処理としては、メタデータ位置またはロック位置にあるデータアイテムに対する読出ロック、書込ロック等のロックを取得する処理、データアイテムのあるバージョンを、トランザクションの読出設定または書込設定に記録／格納する処理、そのポイントへのトランザクションの読出設定が依然として有効か否かを判断する処理、データアイテムの値をバッファリングまたはバックアップする処理、監視部を設定する処理、フィルタリング値を更新する処理、および、任意のその他のトランザクション的処理が含まれ得る。

しかし、トランザクションでは、同じデータアイテムに対する後続のアクセスによって、当該データアイテムに対するアクセスが発見される度に、対応するトランザクション的バリアを実行するというオーバーヘッドが発生することが多い。説明すると、アドレスＡに対する書込みがあるトランザクションにおいて３回行なわれると、アドレスＡに対する書込ロックを取得する書込バリアを３回別個に実行することになる。しかし、アドレスＡに対するロックは最初のトランザクション的書込での書込バリアを実行することで既に取得されており、その後に続く２回のトランザクション的書込の前に書込バリアを２回実行することは冗長であり、アドレスＡに対するロックは再度取得する必要はない。

このため、一実施形態によると、ハードウェアは、これらのバリアに対応付けられている実行を加速するフィルタリング値を保持する。このフィルタリング値は、キャッシュに、読出監視部および書込監視部等の注釈ビットとして含められるとしてよいし、または、上述したようにメタフィジカルアドレス空間内のメタデータ位置に保持されるとしてもよい。上記の例に基づいて説明すると、最初の書込バリアが発見されると、書込フィルタリング値を未アクセス値からアクセス済値に更新して、アドレスＡに対する書込バリアが既に同一トランザクションにおいて発見されている旨を示す。このため、同一トランザクションにおいて続いてトランザクション的書込処理が２回発生すると、書込バリアに誘導される前に、アドレスＡの書込フィルタリング値を確認する。この場合、このフィルタリング値は、書込バリアを実行する必要はない、つまり、書込バリアは既に同一トランザクション内で実行されている旨を示すアクセス済値を含んでいる。このため、続く２つの書込処理については実行を書込バリアに誘導しない。つまり、このフィルタリング値はトランザクション的実行を加速する。つまり、フィルタリングを利用しない前述の例に対して、続く２つのアクセスでは書込バリアの実行を削除するかまたは含めない。

尚、ロード／読出のための読出フィルタ、取消処理のための取消フィルタ、および、一般的なフィルタリング処理のための雑則フィルタを、上記の書込フィルタを書込／ストア処理について利用したのと同じやり方で用いるとしてよい。

さらに、トランザクション的バリアには、非トランザクション的処理からトランザクション的処理を分離することに関連する強アトミック性および弱アトミック性の概念が対応付けられている。この場合、トランザクション的にロードされるメモリ位置に対するトランザクション的書込はコンフリクトとなる可能性があるように、非トランザクション的にロードされるメモリ位置に対するトランザクション的書込もコンフリクトとなる可能性があり、非トランザクション的ロード処理で利用されるデータは無効なデータとなってしまう。弱アトミック性のシステムでは、非トランザクション的処理にはバリアが挿入されないか、または、挿入されるバリアは最低限に抑えられるので、弱アトミック性のシステムは実行が無効になる危険性を抱える。対照的に、強アトミック性のシステムでは、非トランザクション的処理にもトランザクション的バリアが挿入されるので、トランザクション的処理と非トランザクション処理との間が分離および保護されるが、非トランザクション処理全てについてトランザクション的バリアを実行しなければならないという代償を伴う。

このため、一実施形態によると、上述したフィルタは、非トランザクション的処理における強アトミック性バリアと共に利用されて、強アトミック性処理および弱アトミック性処理というさまざまなモードをサポートするとしてよい。説明のために、簡略化した実施形態例を図６に示す。この場合、メタデータ６１０は、上述したように、データ６０５のハードウェアに保持されている。メタデータ６１０にアクセスするためのメタデータアクセス６００を受信する。一実施形態によると、メタデータアクセスは、読出フィルタ、書込フィルタ、取消フィルタ、または、雑則フィルタ等のフィルタを試験する試験メタデータ処理を含む。

フィルタを試験するための試験メタデータ処理は、トランザクション的または非トランザクション的なアクセス処理から発行されるとしてよい。一実施形態によると、コンパイラは、アプリケーションコードをコンパイルする際に、アプリケーションコードに応じた試験フィルタ処理を、条件として、トランザクション的アクセスおよび非トランザクション的アクセスにおけるトランザクション的バリアの呼び出しの実行に挿入する。このため、トランザクションにおいては、バリアの呼び出しの前にフィルタ処理を実行して、成功すればトランザクション的バリアへの呼び出しは実行せず、上述したように加速化を実行する。

しかし、非トランザクション的処理の場合、一実施形態では、非トランザクション的処理におけるトランザクション的バリアが実行されない弱アトミック性モード、および、トランザクション的バリアが実行される強アトミック性モードでハードウェアが動作可能である。

処理または制御６２５のモードは、メタデータ制御レジスタ（ＭＤＣＲ）６１５で設定されるとしてよい。ＭＤＣＲ６１５は、上述したＭＤＩＤを保持するＭＤＣＲのバージョンと組み合わせられるか、または、別の制御レジスタであってもよい。別の実施形態によると、動作モードの制御６２５は、一般的なトランザクション的制御レジスタまたはステータスレジスタで保持されるとしてよい。この場合、第１の実行モードは、非トランザクション的処理でトランザクション的バリアが実行される強アトミック性モードを含む。この場合、制御６２５は、「００」等の第１の値を示し、強アトミック性および非トランザクション的動作モードを表す。一例としてマルチプレクサが挙げられる応答ロジック６２０において、メタデータアクセス６００のデスティネーションレジスタ６５０に供給されるべきデータアドレスＡに対応付けられているハードウェアで維持されているメタデータ６１０からメタデータ値を選択する。基本的に、強アトミック性モードでは、実際にハードウェアに保持されているメタデータに基づいてバリアを加速する。これに代えて、弱アトミック性および非トランザクション的モード等の第２の実行モードでは、「０１」等の第２の値を示す制御６２５で指定されるように、メタデータアクセス６００に応じて、ハードウェアに保持されているメタデータ６１０ではなく、ＭＤＣＲからの固定値または強制値をデスティネーションレジスタ６５０に提供する。

基本的に、弱アトミック性モードでは、フィルタ試験処理６００に応じて強制値をデスティネーションレジスタ６５０に提供して、フィルタ値の試験が常に成功して、非トランザクション的メモリアクセスの前にトランザクション的バリアに対する呼び出しが実行されないようにする。尚、この説明では、フィルタ試験処理が、フィルタ試験が成功（バリアが実行されない）したか、失敗（バリアが実行される）したかを示すためにブール値を返すものと仮定している。このため、フィルタ値に基づいてバリアを削除することによってトランザクションを加速する同じフィルタリングソフトウェア構成を利用して、非トランザクション処理では全てのバリアを削除する第１の動作モード、つまり、弱アトミック性モード、および、ハードウェアで維持されているメタデータに基づいて非トランザクション的処理におけるバリアを実行または加速する第２の動作モード、つまり、強アトミック性モードを提供する。別の実施形態によると、モード毎に異なる強制値を提供するとしてよい。この場合、強アトミック性モードでは、強制値によって、フィルタ試験処理は必ず失敗するのでバリアが常に実行されるが、弱アトミック性モードでは、強制値によってフィルタ試験処理が常に成功するので、バリアが実行されない。

制御６２５等の制御情報に基づいてＭＤＣＲ６１５等の制御レジスタから強制値または固定値を提供することを、処理モードに応じて固定値／強制値またはメタデータ値を提供することに関連付けて説明したが、強制値または固定値を提供することは、一般的なメタデータの利用にも適用されるとしてよい。例えば、データが変わらないことを利用して、要求に応じてイネーブルが可能なメモリアクセスのデバッグおよび一般的な監視を行うとしてもよい。

図７は、トランザクション的環境においてアトミック性を維持しつつ非トランザクション的処理を加速する実施形態を説明するためのフローチャートを示す。ステップ７０５において、データアドレスを参照しているメタデータ（ＭＤ）アクセス処理を発見する説明のために具体例を１つ挙げると、ＭＤアクセス処理は、試験の結果第１の値が返答されれば（成功すれば）非トランザクション的メモリアクセスでのトランザクション的バリアを削除し、試験の結果第２の値が返答されれば（失敗すれば）バリアを実行するべく、コンパイラによってアプリケーションコードに応じて既に挿入された試験処理を含む。しかし、ＭＤ試験処理は、これに限定されるものではなく、ブール値である成功値または失敗値を返す試験処理であればどのような試験処理を含むとしてもよい。

ステップ７１０では、動作モードを判断する。この場合、動作モードの例としては、トランザクション的または非トランザクション的と強アトミック性または弱アトミック性とを組み合わせた動作モードが挙げられる。このため、１のレジスタまたは２つの別個のレジスタが、トランザクション的動作モードまたは非トランザクション的動作モードを示す第１のビット、および、強アトミック性動作モードまたは弱アトミック性動作モードを示す第２のビットを保持するとしてよい。

動作モードがトランザクション的または非トランザクション的で強アトミック性の動作モードである場合、ハードウェアで維持されているメタデータ値をメタデータアクセス処理に対して提供する。つまり、ハードウェアで維持されている値が、ＭＤアクセス処理で特定されているデスティネーションレジスタに入れられる。これとは対照的に、動作モードが、非トランザクション的且つ弱アトミック性の動作モードである場合、ハードウェアで維持されているＭＤ値に代えて、ＭＤＣＲの強制固定値をＭＤアクセス処理に対して提供する。このため、強アトミック性モードでは、ハードウェアで維持されているＭＤ値に基づきバリアが加速されず、弱アトミック性モードでは強制ＭＤＣＲ値に基づいてバリアが加速される。

＜バッファされており監視されている状態への効率的な遷移＞
続いて図８は、トランザクションをコミットする前にデータブロックをバッファされており監視されている状態に効率的に遷移させる方法の実施形態を説明するためのフローチャートである。上述したように、メモリの中の複数のブロック、例えば、データアイテムまたはメタデータを保持しているキャッシュラインは、バッファリングおよび／または監視されることがある。例えば、キャッシュラインのコヒーレンシビットは、バッファされている状態を表し、キャッシュラインの属性ビットは、当該キャッシュラインが、監視されていないか、読出監視されているか、または、書込監視されているかを示す。

一部の実施形態によると、キャッシュラインはバッファされているが、監視されていない。監視が適用されていないので、当該キャッシュラインに保持されているデータが損失が多く、当該キャッシュラインに対するコンフリクトは検出されないことを意味する。例えば、トランザクションに対してローカルでコミットされないデータ、例えば、メタデータは、バッファされているが監視されていない状態で保持されるとしてよい。

バッファされているデータと同じアドレスへの書込との間でコンフリクトが検出される場合、このデータには読出監視が適用される。この後、キャッシュラインは、バッファされており読出監視されている状態へと移行するが、この状態に移行するには、その他のコピー全てを共有状態へと強制的に移行させる読出要求が外部処理要素に送信される。このような外部読出要求によって、同じブロック／キャッシュラインに対して書込監視部を維持している別の処理要素との間でコンフリクトが発生する可能性がある。

同様に、バッファされているデータと同じメモリブロックへの読出との間でコンフリクトが検出される場合、当該キャッシュラインには書込監視を適用する。この後、当該キャッシュラインは、バッファされており書込監視されている状態に遷移する。この遷移は、他の処理要素に所有権読出要求を送信して、他の全てのコピーを強制的に無効状態に移行させることによって、実現する。同様に、同じメモリブロックに対して読出監視または書込監視を維持している処理要素との間でもコンフリクトが検出される。

しかし、トランザクション的なコンフリクトを最小限に抑えるべく、トランザクションによって更新される必要はあるが最終的なコミットはされないメモリブロックは、上述したように、バッファされているが監視されていない状態で維持されるとしてよい。しかし、バッファされているが監視されていない状態で保持されているブロックがコミットされるべきと判断されると、一実施形態では、図８に示すように、バッファされているが監視されていない状態からコミット可能な状態へと遷移するための効率的な経路が提供される。

一例を挙げると、ステップ８０５において、キャッシュラインが保持するメモリブロックに対するバッファ済み更新を受信する。バッファ済み更新の前、または、バッファ済み更新と同時に、読出監視を当該ブロックに適用する。例えば、当該キャッシュラインのための読出属性を、読出監視値に設定して、当該ブロックが読出監視されている旨を示す。しかし、読出監視を適用するためには、ステップ８１５において、読出要求をまず他の処理要素に送信する。他の処理要素は、この読出要求を受信すると、ステップ８２０において、既に当該キャッシュラインを書込監視状態で維持しているのでコンフリクトを検出するか、または、コピーを共有状態へと移行させる。ステップ８２５において、コンフリクトがない場合、キャッシュラインはバッファされており読出監視されている状態へと移行する。つまり、キャッシュラインのコヒーレンシビットをバッファ済みコヒーレンシ値に更新して、読出監視属性を設定する。

ステップ８３０では、読出監視に基づき、キャッシュラインに対して競合する書込を検出する。一実施形態によると、読出属性はスヌープロジックに結合されており、キャッシュラインへの外部からの所有権読出要求は、キャッシュラインに設定されている読出監視との間でコンフリクトを検出する。

この後、ステップ８３５においてトランザクションの状態の一部としてブロックがコミットされるべきである場合には、ステップ８４０において書込監視を適用する。この場合、ステップ８４５において所有権読出要求が他の処理要素に送信され、当該要求は、ステップ８５０において、読出監視状態または書込監視状態でキャッシュラインを保持することに応じてコンフリクトを検出するか、または、コピーを無効状態に移行させる。このため、所有権読出要求でコンフリクトを検出することによって、この時点でどのようなコンフリクトも検出されるので、キャッシュラインがコミット可能な状態となる。

この結果、バッファされているが監視されていないブロックをコミット可能な状態に２段階で、つまり、ステップ８１０およびステップ８４０で移行させることは、有益である。所有権の取得を、読出監視および書込監視の取得を段階的に行うことによって引き延ばすことによって、複数の同時トランザクションは、コンフリクトの発生率を低減しつつ、同一ブロックを更新できるようになる。トランザクションがコミット段階まで何らかの理由で到達しない場合には、バッファされており読出監視されている状態にブロックを更新しても、コミット段階に到達する別のトランザクションが不要にアボートされることはない。また、このため、ブロックの唯一の所有権の取得をコミット段階まで引き延ばすのは、データの有効性を犠牲にすることなくスレッド間での同時性を高める１つの方法である。

以下に記載する表８は、２つの処理要素Ｐ０およびＰ１の間におけるコンフリクトの一実施形態を示す。例えば、Ｐ１によってバッファされており読出監視されている状態に保持されているライン（Ｒ−Ｂ列で示す）と、キャッシュラインが書込監視部で維持されているＰ０の任意の状態（−Ｗ−、ＲＷ−、ＷＢ、ＲＷＢで示す）は、交差するセルで×印で示すように、コンフリクトしている。

また、以下に示す表９は、Ｐ０の列に列挙している処理に応じて、処理要素Ｐ１の対応付けられている特性が失われることを示す。例えば、Ｐ１がラインをバッファされており読出監視されている状態で保持している（Ｒ−Ｂ列で示す）場合、Ｐ０においてストア処理または書込監視設定処理が発生すると、Ｐ１では、ストア／設定ＷＭ行とＲ−Ｂ列が交差している箇所のｘ−ｘで示すように、当該ラインの読出監視属性およびバッファリング属性が失われる。

＜トランザクション的データの損失またはコンフリクトに対する分岐命令（ＪＬＯＳＳ）＞
図９は、トランザクションステータスレジスタのステータス値に基づいてデスティネーションラベルに損失命令がジャンプするようにサポートしているハードウェアの実施形態を図示している。一実施形態によると、ハードウェアは、トランザクションのコンシステンシを確認する手順を加速する。一例として、ハードウェアは、監視あるいはバッファリングされているデータのキャッシュからの損失、つまり、バッファリングあるいは監視されているラインのエビクションを追跡するメカニズム、または、このようなデータに対する競合アクセスを追跡するメカニズム、つまり、監視されているラインへの所有権読出要求等、競合するスヌープを検出する監視部を提供することによってコンシステンシ確認手順をサポートするとしてよい。

また、一実施形態によると、ハードウェアは、監視またはバッファリングされているデータのステータスに基づきソフトウェアにこれらのメカニズムにアクセスさせるためのアーキテクチャインターフェースを提供する。このようなインターフェースとして、（１）実行中にソフトウェアに明示的にレジスタをポーリングさせる、ステータスレジスタを読み書きするための命令、（２）ステータスレジスタがコンシステンシが失われた可能性を示す場合には常に読み出されるハンドラをソフトウェアに設定させるインターフェースの２つが挙げられる。

別の実施形態によると、ハードウェアは、ＨＷの監視またはバッファリングされているデータのステータスに基づき条件付き分岐を実行するＪＬＯＳＳと呼ばれる新しい命令をサポートする。ＪＬＯＳＳ命令は、監視またはバッファリングされているデータがキャッシュから失われたことをハードウェアが検出すると、または、監視またはバッファリングされているデータに関するコンフリクトを検出すると、ラベルに分岐する。ラベルは、ハンドラのアドレス、または、データ損失またはコンフリクト検出の結果実行されるべきその他のコード等、任意のデスティネーションを含む。

説明のための実施形態として、図９は、プロセッサＩＳＡの一部としてＪＬＯＳＳを認識して、プロセッサのロジックにトランザクションのステータスに基づいて条件付き分岐を実行させる命令をデコードするデコーダ９１０を示す。一例を挙げると、トランザクションのステータスは、トランザクションステータスレジスタ９１５に保持されている。トランザクションステータスレジスタは、トランザクションのステータス、例えば、ハードウェアがコンフリクトまたは、本明細書では損失イベントと呼ぶデータ損失を検出したことを表すとしてよい。説明すると、ＴＳＲ９１５のコンフリクトフラグは、監視対象のアドレスへのスヌープと組み合わせてアドレスが監視されている旨を監視部が示すと設定される。ＴＳＲ９１２のコンフリクトフラグは、コンフリクトが検出された旨を示す。同様に、損失フラグは、トランザクション的データまたはメタデータを含むラインのエビクション等、データの損失に応じて設定される。

このため本明細書では、ＪＬＯＳＳは、デコードされて実行されると、ステータスレジスタのフラグを試験して、損失イベント、つまり、損失および／またはコンフリクトがある場合には、ロジック９２５がＪＬＯＳＳが参照しているラベルを実行リソース９３０に対してジャンプ先アドレスとして提供する。このため、１つの命令で、ソフトウェアはトランザクションのステータスを識別することができ、このステータスに基づいて、当該命令が特定しているラベルに実行を誘導することができる。ＪＬＯＳＳはコンシステンシを確認するので、偽のコンフリクトを報告しても許容され得る。ＪＬＯＳＳは、「従来の方法でコンフリクトが発生したと報告するとしてよい。

一実施形態によると、コンパイラ等のソフトウェアは、コンシステンシについてポーリングするために、プログラムコードにＪＬＯＳＳ命令を挿入する。しかし、ＪＬＯＳＳはメインアプリケーションコードに応じて利用され、ＪＬＯＳＳ命令は、要求に応じてコンシステンシを判断するために、ライブラリ内で提供される読出バリアおよび書込バリアで利用されることが多い。このため、プログラムコードの実行は、コンパイラがＪＬＯＳＳをコードに挿入すること、または、プログラムコードからＪＬＯＳＳを実行すること、任意のその他の形態での命令の挿入または実行を含むとしてよい。ＪＬＯＳＳによるポーリングはステータスレジスタの明示的な読出よりもはるかに高速であると考えられる。これは、ＪＬＯＳＳ命令は追加レジスタを必要としない、つまり、デスティネーションレジスタが明示的読出のステータス情報を受信する必要がないためである。この命令の実施形態では、コンシステンシを確認するための条件は、命令内に明示的に記載されているか、または、別の制御レジスタに非明示的に記載されている。

一例を挙げると、トランザクションステータスレジスタ９１５またはその他の格納要素は、特定のコンフリクトステータス情報および損失ステータス情報を保持している。例えば、読出監視されている位置に別のエージェントが書込を行なえば読出コンフリクトで、書込監視されている位置に別のエージェントが読出または書込を行なえば書込コンフリクトで、物理的なトランザクション的データの損失、または、メタデータの損失といった情報を保持している。このため、さまざまなバージョンのＪＬＯＳＳ命令を利用するとしてよい。例えば、ＪＬＯＳＳ．ｒｍ＜ｌａｂｅｌ＞命令は、読出監視されている位置に別のエージェントが書込を行なった場合にラベルに分岐する。ハードウェアで加速されるＳＴＭ（ＨＡＳＴＭ）は、このＪＬＯＳＳ．ｒｍ命令を用いて、コンシステンシの確認を加速することができる。読出設定のコンシステンシを確認する場合は常に、例えば、ネイティブコードのＴＭシステムでの各トランザクション的ロードの後に、ＪＬＯＳＳ．ｒｍを用いて読出設定への競合する更新を短時間で確認する。この場合、読出設定は、読出バリアにあるＪＬＯＳＳを用いて検証されるとしてよいので、ＪＬＯＳＳ命令は、ライブラリ内の読出バリアに挿入されるか、または、メインアプリケーションコードに応じてロード処理の後に挿入される。読出監視されている位置への書込を検出するＪＬＯＳＳ．ｒｍ命令と同様に、ＪＬＯＳＳ．ｗｍ命令は、書込監視されている位置への読出または書込を検出するために用いられるとしてよい。さらに別の例として、位置をバッファリング出来るプロセッサでは、ＪＬＯＳＳ．ｂｕｆ命令を用いて、バッファされているデータが失われたので特定のラベルにジャンプするか否かを判断するとしてよい。

以下に記載する擬似コードは、擬似コードＡとするが、コンシステンシを持つ読出設定を提供すると共にＪＬＯＳＳを利用する、ネイティブコードのＳＴＭの読出バリアを示す。ｓｅｔｒｍ（ｖｏｉｄ＊ａｄｄｒｅｓｓ）関数は、所与のアドレスに対して読出監視を設定し、ｊｌｏｓｓ＿ｒｍ（）関数は、読出監視されている位置に対して競合するアクセスが発生した場合に真を返すＪＬＯＳＳ命令の組み込み関数である。この擬似コードは、ロードされたデータを監視するが、代わりにトランザクションの記録（所有権の記録）を監視することもできる。読出監視の設定とデータのロードとを組み合わせる命令、例えば、データのロードおよび監視の両方を行うｍｏｖｘｍ命令を利用することが可能である。監視に加えてフィルタリングを実行する読出バリアでこれを利用することも可能であり、さらに、読出設定の検証のためにハードウェア監視のみを利用するＳＴＭシステムで、つまり、ソフトウェア読出記録およびＳＷ検証を実行しないＳＴＭシステムでこれを利用することも可能である。

＜擬似コードＡ：その場更新のＳＴＭ、楽観的読出、ネイティブコードの読出バリア＞

同様に、読出設定コンシステンシを維持しないＳＴＭシステム、例えば、管理されているコード用のＳＴＭは、無限ループまたはその他の不正確な制御フローを回避するとしてよい。つまり、ループバックエッジまたはその他の重要な制御フロー点、例えば、例外が上がる命令においてＪＬＯＳＳ．ｒｍ命令を挿入することによってコンシステンシが失われるので、例外を回避するとしてよい。

以下に記載する擬似コードは、擬似コードＢと示すが、コンシステンシを実現する別のネイティブコードの読出バリアを示す。このバージョンのＴＭシステムは、トランザクション内の書込についてバッファされている更新を用いてキャッシュに存在する書込設定を利用する。バッファされた後に削除された位置からの読出はコンシステンシが無いので、コンシステンシを維持するために、この読出バリアでは削除されたバッファ済み位置からの読出を回避する。ＣＯＭＭＩＴ＿ＬＯＣＫＩＮＧフラグは、ＳＴＭがバッファ済み位置についてコミット時間ロックを利用している場合に真となる。ｊｌｏｓｓ＿ｂｕｆ（）の確認は、コミット時間ロックを利用しない場合に以前にロックされた位置からの読出について利用されるが、利用しない場合には全ての読出に対して利用される。

＜擬似コードＢ：その場更新、ネイティブコードのＳＴＭの読出バリア＞

ＴＭシステムは、上述したように、読出監視とバッファリングおよび書込監視とを組み合わせるとしてよいので、コンシステンシを維持するために監視されているラインまたはバッファリングされているラインに対するコンフリクトを確認することをさらに含むとしてよい。このようなシステムに対応するべく、異なる実施形態では、ＪＬＯＳＳ．ｒｍ．ｂｕｆ（読出監視されている位置またはバッファリングされている位置に対するコンフリクト）、ＪＬＯＳＳ．ｒｍ．ｗｍ（読出監視されている位置または書込監視されている位置に対するコンフリクト）、または、ＪＬＯＳＳ．＊（読出監視されている位置、書込監視されている位置、または、バッファリングされている位置に対するコンフリクト）等のさまざまな監視イベントおよびバッファリングイベントを論理的に組み合わせて分岐するＪＬＯＳＳフレーバーを提供するとしてよい。

別の実施形態によると、アーキテクチャインターフェースは、ソフトウェアに別の制御レジスタで条件、つまり、読出／書込監視されているラインまたはバッファリングされているラインに対するコンフリクトを設定させることによって、分岐する条件からＪＬＯＳＳ命令を切り離す。この実施形態では、必要なＪＬＯＳＳ命令のエンコードは１回のみであり、ＪＬＯＳＳが分岐すべきイベント群を将来に拡張することもサポートできる。

図１０は、コンフリクトまたは特定の情報の損失に基づいてデスティネーションラベルにジャンプする損失命令を実行する方法の実施形態を説明するためのフローチャートである。一実施形態によると、ステップ１００５において、ＪＬＯＳＳ命令を受信する。上述したように、ＪＬＯＳＳ命令は、プログラマまたはコンパイラによって、メインコード中に、例えば、ロード処理後に読出設定のコンシステンシを実現するために挿入されたり、または、バリア内に、例えば、読出バリアまたは書込バリア内に挿入されるとしてよい。ＪＬＯＳＳ命令および上述したその変形は、一実施形態によると、プロセッサのＩＳＡの一部として認識可能である。この場合、デコーダは、ＪＬＯＳＳ命令のオペコードをデコード可能である。

ステップ１０１０において、コンフリクトまたは情報の損失が発生したか否かを判断する。一実施形態によると、コンフリクトまたは損失の種類は、ＪＬＯＳＳ命令のバージョンに応じて決まる。例えば、受信したＪＬＯＳＳ命令がＪＬＯＳＳ．ｒｍ命令の場合、読出監視されているラインと外部からの書込アクセスとの間でコンフリクトが発生したか否かを判断する。しかし、上述したように、ユーザに制御レジスタで条件を指定させるＪＬＯＳＳ命令を始めとして、どのバージョンのＪＬＯＳＳを受信するとしてもよい。

このため、条件が確立すれば、制御レジスタまたはＪＬＯＳＳ命令の種類のいずれかに基づき、確立した条件を満たしているか否かを判断する。第１の例を挙げると、ＴＳＲ９１５等のトランザクションステータスレジスタにある情報を用いて、条件を満たしているか否かを判断する。ここにおいて、ＴＳＲ９１５は、デフォルトでは無コンフリクト値に設定されており、且つ、コンフリクトが発生すればその旨を示すべくコンフリクト値に更新される読出監視ステータスフラグを含むとしてよい。しかし、コンフリクトが発生したか否かを判断するための方法はステータスレジスタを利用する方法に限定されず、損失またはコンフリクトの判断を行なうためには任意の公知の方法を利用するとしてよい。

コンフリクトが検出されないことに応じて、例えば、ＴＳＲ９１５の読出監視コンフリクトフラグが依然としてデフォルト値に設定されている場合、ステップ１０２５において、「偽」を表す値を返して実行は通常通りに継続する。しかし、コンフリクトまたは損失が検出されれば、例えば、読出監視コンフリクトフラグが設定されれば、ステップ１０１５において、ＪＬＯＳＳは「真」を表す値を返して、ステップ１０２０において、受信したＪＬＯＳＳ命令が定義しているラベルに実行をジャンプさせる。

＜トランザクショナルメモリのコミットに対するハードウェアサポート＞
上述したように、ハードウェアでサポートされているトランザクションは、グローバルに可視化することなくキャッシュ内にトランザクション的な書込をバッファリングすることによって、ソフトウェアのバージョン管理を加速するとしてよい。この場合、バッファされている値を全てのプロセッサに対して可視化させる単純なコミット命令を用いるとしてよいが、バッファされているラインの何れかが失われている場合には失敗に終わってしまう。しかし、冗長なバリアを削除／フィルタリングするためのフィルタ等、ソフトウェアが加速化のために利用可能なメタデータをハードウェアが保持することができるので、ハードウェアがコンフリクトを検出すれば、コミット命令が失敗することが望ましい。また、コミットされると、トランザクションのためにハードウェアで保持される情報のさまざまな組み合わせ、例えば、メタデータ、監視部、または、バッファされているラインをクリアすることが望ましい。

このため、一実施形態によると、ハードウェアは、さまざまな形態のコミット命令をサポートして、コミット命令に、コミットするための条件およびコミット時にクリアする情報の両方を特定させる。図１１は、ハードウェアがコミット命令でコミット条件およびクリア制御の定義をサポートする一般的な場合の実施形態を示す。

同図に示すように、コミット命令１１０５は、プロセッサのＩＳＡの一部として認識可能な、つまり、デコーダ１１１５がデコード可能であるオペコード１１１０を含む。図示している例では、オペコード１１１０は、コミット条件１１１１およびクリア制御１１１２の２つの部分を含む。コミット条件１１１１は、コミットすべきトランザクションの条件を特定しており、コミットクリア制御１１１２は、トランザクションのコミット時にクリアすべき情報を特定している。

一実施形態によると、どちらの部分も、読出監視（ＲＭ）、書込監視（ＷＭ）、バッファリング（Ｂｕｆ）、および、メタデータ（ＭＤ）という４つの値を含む。基本的に、これら４つの値のうちいずれかが部分１１１１で設定されている場合、つまり、対応付けられている属性／特性がコミット条件である旨を示す値を含む場合、対応する特性はコミットするための条件となる。言い換えると、条件１１１１のうち読出監視情報に対応する第１のビットが設定されている場合、トランザクションに対応付けられている監視部１１３５の読出監視データの損失はアボートとなる。つまり、コミット命令の特定の条件が満たされていないので、コミットしない。同様に、１１１２のある値が設定されていれば、対応する特性はコミット時にクリアされる。この例で説明を続けると、部分１１１２のＲＭが設定されている場合、トランザクションの監視部１１３５の読出監視情報は、当該トランザクションがコミットされる場合にクリアされる。このため、本例では、コミット条件およびクリア制御としてそれぞれ４通りの設定が可能で、コミット命令のバージョンとしては２５６通りが可能となる。一実施形態によると、コミット条件をオペコードで特定させるので、ハードウェアは全てのバージョンをサポート可能である。さまざまなタイプのコミット命令を理解していただくため、そして、コミット命令がどのように用いられるかを説明するため、以下で数バージョンを説明する。

＜ＴＸＣＯＭＷＭ＞
第１の例として、Ｔｘｃｏｍｗｍ命令を説明する。この命令は、書込監視されているデータがいずれも失われていなければ（成功）、トランザクションを終了させて、書込監視されておりバッファリングされている全てのデータをグローバルに可視化する命令である。書込監視されているデータが失われていれば、失敗となる。Ｔｘｃｏｍｗｍは、フラグを設定（またはリセット）して、成功（または失敗）を示す。Ｔｘｃｏｍｗｍは、成功すると、書込監視されている全てのデータのバッファ済み状態をクリアする。Ｔｘｃｏｍｗｍは、読出監視状態または書込監視状態には影響を与えないので、ソフトウェアは読出監視状態または書込監視状態を後続のトランザクションで再利用することができる。また、バッファリングされているが書込監視されていない位置の状態にも影響を与えないので、ソフトウェアはこのような位置に維持されている情報を保持することができる。以下に記載する擬似コードは、擬似コードＣと示すが、Ｔｘｃｏｍｗｍをアルゴリズム的に説明している。ＴＳＲ．ＬＯＳＳ＿ＷＭが０の場合、書込監視されておりバッファされているＢＢＬＫは全て、ＢＦ特性がアトミックにクリアされ、このバッファリングされているデータは全て他のエージェントにも可視となる。ＴＣＲ．ＩＮ＿ＴＸがクリアされる。バッファリングされているがＷＭされていないブロックは、影響を受けず、バッファリングされたままとなる。ＣＦフラグは、完了すると設定される。ＴＳＲ．ＬＯＳＳ＿ＷＭが１である場合には、ＣＦフラグはクリアされ、ＴＣＲ．ＩＮ＿ＴＸがクリアされる。ＣＦフラグは、処理が成功すると１に設定され、失敗すると０に設定される。ＯＦフラグ、ＳＦフラグ、ＺＦフラグ、ＡＦフラグおよびＰＦフラグは０に設定される。

＜擬似コードＣ：Ｔｘｃｏｍｗｍ処理のアルゴリズムの実施形態＞

以下に記載する擬似コードは、擬似コードＤとして示すが、ＨＡＳＴＭシステムがどのようにＴｘｃｏｍｗｍ命令を利用して、その場更新型のＳＴＭにおいて記録の取消を回避するべくハードウェア書込バッファリングを利用するトランザクションをコミットするのか説明する。ＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＷＲＩＴＥＳフラグは、この実行モードを示す。

＜擬似コードＤ：Ｔｘｃｏｍｗｍ命令を利用するための擬似コードの実施形態＞

＜ＴＸＣＯＭＷＭＲＭ＞
変形例の１つであるｔｘｃｏｍｗｍｒｍは、Ｔｘｃｏｍｗｍ命令を拡張した命令で、読出監視されている位置も失われていれば、失敗となる。この変形例は、読出設定コンフリクトを検出する際にハードウェアのみを利用するトランザクションについて有用である。以下に記載する擬似コードは、擬似コードＥとして示すが、Ｔｘｃｏｍｗｍｒｍをアルゴリズム的に説明する。ＴＳＲ．ＬＯＳＳ＿ＷＭおよびＴＳＲ．ＬＯＳＳ＿ＲＭが０の場合、書込監視されておりバッファされているＢＢＬＫは全て、ＢＦ特性がアトミックにクリアされ、このバッファリングされているデータは全て他のエージェントにも可視となる。ＴＣＲ．ＩＮ＿ＴＸがクリアされる。バッファリングされているがＷＭされていないブロックは、影響を受けず、バッファリングされたままとなる。ＣＦフラグは、完了すると設定される。ＴＳＲ．ＬＯＳＳ＿ＷＭまたはＴＳＲ．ＬＯＳＳ＿ＲＭが１である場合には、ＣＦフラグはクリアされ、ＴＣＲ．ＩＮ＿ＴＸがクリアされる。ＣＦフラグは、処理が成功すると１に設定され、失敗すると０にクリアされる。ＯＦフラグ、ＳＦフラグ、ＺＦフラグ、ＡＦフラグおよびＰＦフラグは０に設定される。

＜擬似コードＥ：Ｔｘｃｏｍｗｍｒｍのアルゴリズムによる記述の実施形態＞

続く擬似コードは、擬似コードＦと示すが、トランザクション的書込のバッファリングおよび読出設定コンフリクトの検出の両方にハードウェアを利用するＳＴＭシステムについてｔｘｃｏｍｗｍｒｍ命令を利用するコミットアルゴリズムを表す。ＨＷ＿ＲＥＡＤ＿ＭＯＮＩＴＯＲＩＮＧフラグは、このアルゴリズムが読出設定コンフリクト検出のためにハードウェアのみを利用するか否かを示す。

＜擬似コードＦ：ｔｘｃｏｍｗｍｒｍ命令を利用する擬似コードの実施形態＞

＜ＴＸＣＯＭＷＭＩＲＭＣ＞
第３の変形例を、以下に擬似コードＦとしてアルゴリズムで説明する。ＴＳＲ．ＬＯＳＳ＿ＷＭおよびＴＳＲ．ＬＯＳＳ＿ＩＲＭが０の場合、書込監視されておりバッファされているＢＢＬＫは全て、ＢＦ特性がアトミックにクリアされ、このバッファリングされているデータは全て他のエージェントにも可視となる。ＲＭ、ＷＭおよびＩＲＭ、ならびに、ＴＣＲ．ＩＮ＿ＴＸがクリアされる。バッファリングされているがＷＭされていないブロックは、影響を受けず、バッファリングされたままとなる。ＣＦフラグは、完了すると設定される。ＴＳＲ．ＬＯＳＳ＿ＷＭまたはＴＳＲ．ＬＯＳＳ＿ＲＭが１である場合には、ＣＦフラグはクリアされ、ＴＣＲ．ＩＮ＿ＴＸがクリアされる。ＣＦフラグは、処理が成功すると１に設定され、失敗すると０にクリアされる。ＯＦフラグ、ＳＦフラグ、ＺＦフラグ、ＡＦフラグおよびＰＦフラグは０に設定される。

＜擬似コードＦ：Ｔｘｃｏｍｗｍｉｒｍｃ命令のアルゴリズムによる説明の実施形態＞

図１２は、コミット条件およびクリア制御を定義しているコミット命令を実行する方法の実施形態を示すフローチャートである。ステップ１２０５において、コミット命令を受信する。上述したように、コンパイラは、プログラムコードにコミット命令を挿入するとしてよい。説明のために具体例を挙げると、コミット関数の呼び出しはメインコードに挿入され、上記の擬似コードに含まれているようなコミット関数はライブラリにおいて提供されており、コンパイラはさらに、ライブラリ内のコミット関数にコミット命令を挿入するとしてもよい。

コミット命令を受信すると、デコーダはコミット命令をデコードすることが可能である。ステップ１２１０では、デコードされた情報に基づき、コミット命令のオペコードで特定されている条件を判断する。上述したように、オペコードは、一部のフラグを設定する一方他のフラグをリセットすることによって、コミットの際にどの条件を利用するか示すとしてよい。条件を満たしていない場合には、「偽」を返して、トランザクションは別個にアボートされるとしてよい。しかし、コミットのための条件が満たされていれば、例えば、読出監視、書込監視、メタデータおよび／またはバッファリングのうち任意の組み合わせが失われていない場合には、ステップ１２１５において、クリア条件／制御を判断する。一例を挙げると、トランザクションの読出監視、書込監視、メタデータおよび／またはバッファリングのうち任意の組み合わせを、クリアすべきと判断する。このため、ステップ１２２５において、クリアすべきと判断された情報をクリアする。

＜ＵＴＭのメモリ管理の最適化＞
上述したように、無制限トランザクショナルメモリ（ＵＴＭ）のアーキテクチャおよびそのハードウェア実装は、監視、バッファリング、および、メタデータという特性を導入することによって、プロセッサアーキテクチャを拡張したものである。このような構成とすることによって、多岐にわたるトランザクショナルメモリ設計を始めとする、さまざまな高度なアルゴリズムを実装するのに必要な手段がソフトウェアに提供される。それぞれの特性は、キャッシュを実装する際に既存のキャッシュプロトコルを拡張するか、または、独立した新しいハードウェアリソースを割り当てるかによって、ハードウェアで実装されるとしてよい。

ＵＴＭの特性をＨＷで実装する場合、ＵＴＭアーキテクチャおよびそのハードウェア実装によって、ＵＴＭトランザクションアボートおよびそれに続くトランザクション再試行処理等の発生を回避して最小限に抑えることができれば、トランザクションに関してソフトウェアのみを利用する場合（ＳＴＭ）に比べて、性能が向上する可能性がある。ハードウェアトランザクションアボートの主な原因の１つとして、外部割込、システム呼び出しイベント、および、ページフォールトに起因してリング遷移が頻繁に発生することが挙げられていた。

現在実行中の特権レベル（ＣＰＬ）に基づく一時停止メカニズムは、ハードウェアトランザクションをアクティブ状態とし（バッファリングおよび監視等のＵＴＭ特性を持つハードウェアで加速されたトランザクションをイネーブルし、放出メカニズムをイネーブルする）、プロセッサの動作モードは、特権レベル３（ユーザモード）である。リング３からのリング遷移によって、現在アクティブなトランザクションは自動的に一時停止してしまう（ＵＴＭ特性を生成するために停止して、放出メカニズムをディセーブルする）。同様に、リング３に戻るリング遷移によって、以前に一時停止したハードウェアトランザクションを、アクティブであったならば、自動的に再開する。この手法の欠点は、カーネルコードまたはリング３を除くリングレベルでのハードウェアトランザクショナルメモリのリソースの利用が、ほとんど排除されていることである。

別の手法では、リング０のトランザクション制御レジスタ（ＴｘＣＲ）等のＴＭ制御リソースを複製して、この別個に用意されたＴＭリソースを用いてリング０コードのハードウェアトランザクションをイネーブルできるようにする。しかし、この手法では、リング０のトランザクション処理でのネスト化された割り込みおよび例外を効率的に処理することができない。

このため、図１３は、トランザクションの実行時に特権レベルの遷移の処理をサポートするハードウェアの実施形態を示す。当該実施形態では、ユーザモード（リング３）のトランザクションに加えてリング０のトランザクションをイネーブルするが、仮想マシンモニタ（ＶＭＭ）等のハイパーバイザおよびＯＳも提供して、リング０のトランザクションが存在している状態で、無限の階層のネスト化された割り込みおよびＮＭＩを処理する。

ＥＦＬＡＧＳレジスタ１３１０等の格納要素は、トランザクションイネーブルフィールド（ＴＥＦ）１３１１を含む。ＴＥＦ１３１１は、アクティブ値を保持する場合には、トランザクションが現在アクティブでありイネーブルされている旨を示し、非アクティブ値を保持する場合には、トランザクションが一時停止している旨を示す。

一実施形態によると、トランザクション開始処理、または、トランザクション開始時の別の処理によって、ＴＥＦフィールド１３１１をアクティブ値に設定する。ステップ１３００において、割り込み、例外、システム呼び出し、仮想マシン終了、または、仮想マシン開始等のリングレベル遷移イベントが発生すると、ステップ１３０１において、ＰＥ０のＥｆｌａｇｓレジスタ１３１０の状態がカーネルスタック１３２０にプッシュされる。ステップ３０２において、ＴＥＦフィールド１３１１は、トランザクションを一時停止するべく、非アクティブ値にクリア／更新される。リングレベル遷移イベントについては、トランザクションが一時停止している間に、適切に処理または対応する。ステップ１３０３において戻りイベントを検出すると、ステップ１３０１においてスタックにプッシュされたＥｆｌａｇｓレジスタ１３１０の状態は、ステップ１３０４においてポップされて、Ｅｆｌａｇｓレジスタ１３１０に以前の状態を戻す。以前の状態に戻すことによって、ＴＥＦ１３１１にはアクティブ値が再び設定され、アクティブ状態且つイネーブル状態にあるものとしてトランザクションを再開する。

リングレベル遷移イベントに対する処理の具体例を以下に記載する。割り込みおよび例外が発生すると、プロセッサは、ＥＦＬＡＧＳレジスタをカーネルスタックにプッシュして、「トランザクションイネーブル」ビットを、設定されていれば、クリアして、以前にイネーブルされていたトランザクションを一時停止させる。ＩＲＥＴが発生すると、プロセッサは、カーネルスタックに基づき、「トランザクションイネーブル」ビットを含む、割り込みが発生したスレッドのＥＦＬＡＧＳレジスタの状態を全て元に戻して、以前にイネーブルされていればトランザクションの一時停止を解除する。

ＳＹＳＣＡＬＬが発生すると、プロセッサは、ＥＦＬＡＧＳレジスタをプッシュして、「トランザクションイネーブル」ビットを、設定されていれば、クリアして、以前にイネーブルされたトランザクションを一時停止する。ＳＹＳＲＥＴが発生すると、プロセッサは、カーネルスタックに基づいて、「トランザクションイネーブル」ビットを含む、割り込みが発生したスレッドのＥＦＬＡＧＳレジスタの状態を全て元に戻して、以前にイネーブルされていれば、トランザクションの一時停止を解除する。

ＶＭ−Ｅｘｉｔが発生すると、プロセッサは、「トランザクションイネーブル」ビットの状態を含む、ゲストのＥＦＬＡＧＳレジスタを仮想マシン制御構造（ＶＭＣＳ）に保存して、「トランザクションイネーブル」ビットの状態がクリア状態であるホストのＥＦＬＡＧＳレジスタの状態をロードして、以前にイネーブルされているゲストのトランザクションを、イネーブルされていれば、一時停止させる。

ＶＭ−Ｅｎｔｅｒが発生すると、プロセッサは、ＶＭＣＳから、「トランザクションイネーブル」ビットの状態を含むゲストのＥＦＬＡＧＳレジスタを元に戻して、以前にイネーブルされたゲストのトランザクションを、イネーブルされていた場合には、一時停止を解除する。

このような構成とすることによって、ハードウェアで加速されたユーザモード（リング３）のＵＴＭトランザクションに加えて、ハードウェアで加速されたカーネルモード（リング０）のＵＴＭトランザクションがイネーブルされるが、ＯＳおよびＶＭＭの両方が、リング０のトランザクションが存在する中で、無限の階層のネスト化された割り込みおよびＮＭＩを処理できるようになる。先行技術では、このようなメカニズムは提供されていない。

「モジュール」は、本明細書で用いる場合、任意のハードウェア、ソフトウェア、ファームウェア、または、これらの組み合わせを意味する。多くの場合、別々のものとして示されるモジュールの境界は、変更されるのが普通で、重複する可能性がある。例えば、第１のモジュールおよび第２のモジュールは、一部のハードウェア、ソフトウェア、または、ファームウェアを別個に保有しつつも、ハードウェア、ソフトウェア、ファームウェア、または、これらの組み合わせを共有するとしてもよい。一実施形態によると、「ロジック」という用語を用いる場合、トランジスタ、レジスタ等のハードウェア、または、プログラム可能ロジックデバイス等のその他のハードウェアを含む。しかし、別の実施形態では、「ロジック」はさらに、ハードウェアと一体化したソフトウェアまたはコード、例えば、ファームウェアまたはマイクロコードを含む。

「値」は、本明細書で用いる場合、数、状態、論理状態、または、バイナリ論理状態を表す任意の公知の方法を含む。多くの場合、「論理レベル」、「ロジック値」、または、「論理値」は、１および０で表現することもあり、これは単にバイナリロジック状態を表したものである。例えば、「１」は論理Ｈｉｇｈレベルを意味し、「０」は論理Ｌｏｗレベルを意味する。一実施形態によると、トランジスタまたはフラッシュセル等のストレージセルは、１または複数の論理値を保持可能であるとしてよい。しかし、コンピュータシステムでは他の方法で値を表現することもある。例えば、１０進法の「１０」は、バイナリ値では「１０１０」と表現され、１６進法では文字「Ａ」で表現される。このため、「値」は、コンピュータシステムで保持可能な情報の表現方法であればどのような表現方法も含む。

また、値または値の一部で状態を表現するとしてもよい。一例として、論理値「１」等の第１の値は、デフォルト状態または初期状態を表す一方、論理値「０」等の第２の値はデフォルトでない状態を表すとしてよい。また、「リセット」および「設定」という用語はそれぞれ、一実施形態によると、デフォルト値またはデフォルト状態、および、更新後の値または更新後の状態を意味する。例えば、デフォルト値は論理Ｈｉｇｈ値、つまり、リセット値を含み、更新後の値は論理Ｌｏｗ値、つまり、設定値を含む。尚、値を任意に組み合わせて、任意の数の状態を表現するとしてよい。

上述した方法、ハードウェア、ソフトウェア、ファームウェア、または、コードの実施形態は、処理要素で実行可能な機械アクセス可能媒体または機械可読媒体に格納されている命令またはコードで実装されるとしてよい。機械アクセス可能／可読媒体は、コンピュータまたは電子システム等の機械が読出可能な状態で情報を提供する（つまり、格納および／または送信する）任意のメカニズムを含む。例えば、機械アクセス可能媒体は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックＲＡＭ（ＤＲＡＭ）等のＲＡＭ、ＲＯＭ、磁気格納媒体または光格納媒体、フラッシュメモリデバイス、電気ストレージデバイス、光ストレージデバイス、音響ストレージデバイスまたはその他の形態の伝播信号（例えば、搬送波、赤外線信号、デジタル信号）ストレージデバイス等を含む。例えば、機械は、搬送波等の伝播信号を、当該伝播信号で送信される情報を保持可能な媒体から受信することによってストレージデバイスにアクセスするとしてよい。

本明細書において「一実施形態」または「ある実施形態」という場合、当該実施形態に関連付けて説明している特定の特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれることを意味するものである。このため、「一実施形態において」または「ある実施形態において」という表現は本明細書で繰り返し用いられるが、必ずしも全てが同じ実施形態を意味するものではない。また、特定の特徴、構造、または、特性は、一以上の実施形態において適宜組み合わせるとしてもよい。

上述の説明では、具体的な実施形態例を参照しつつ詳細に本発明を説明した。しかし、特許請求の範囲に記載している本発明のより広義の意図および範囲から逸脱することなく、上述した具体的な実施形態例をさまざまな点で変形および変更し得ることは明らかである。したがって、明細書および図面は、本発明を限定するものではなく例示するものと解釈されたい。また、上述したような「実施形態」等の例示的な表現は、必ずしも同じ実施形態または同じ例を指しているものではなく、同じ実施形態に言及している可能性もあるが異なる別個の実施形態に言及している場合もある。
本実施形態によれば、以下の各項目もまた開示される。
（項目１）
複数の処理要素と、
メタフィジカルロジックと
を備え、
前記複数の処理要素のうち一の処理要素は、複数のソフトウェアサブシステムと対応付けられ、
前記メタフィジカルロジックは、前記複数のソフトウェアサブシステムのうち一の現行ソフトウェアサブシステムと対応付けられ、且つ、データアドレスを参照するメタデータアクセス処理を、前記現行ソフトウェアサブシステムに対応付けられているメタデータ識別子（ＭＤＩＤ）および前記データアドレスに少なくとも基づいて、前記現行ソフトウェアサブシステムに対応付けられているメタフィジカルアドレス空間に対応付ける、装置。
（項目２）
前記現行ソフトウェアサブシステムに対応付けられている前記メタフィジカルアドレス空間は、前記複数のソフトウェアサブシステムのうち第２のソフトウェアサブシステムに対応付けられている少なくとも１つのほかのメタフィジカルアドレス空間、および、前記データアドレスを含むデータアドレス空間に対して直交する項目１に記載の装置。
（項目３）
前記複数のソフトウェアサブシステムはそれぞれ、トランザクショナル・ランタイム・サブシステム、ガベージ・コレクション・ランタイム・サブシステム、メモリ保護サブシステム、ソフトウェア変換サブシステム、ネスト化された一群のトランザクションのうち一の外側トランザクション、および、ネスト化された一群のトランザクションのうち一の内側トランザクションから成る群から選択される項目２に記載の装置。
（項目４）
前記メタデータアクセス処理をデコードするデコードロジックをさらに備え、
前記メタデータアクセス処理は、前記デコードロジック内でサポートされた複数の処理のうちの１つとして認められるオペレーションコード（オペコード）を含む項目１に記載の装置。
（項目５）
前記メタフィジカルロジックは、前記データアドレスを、少なくとも前記ＭＤＩＤに基づいて、前記現行ソフトウェアサブシステムに対応付けられている前記メタフィジカルアドレス空間内のメタデータアドレスに変換するメタフィジカル変換ロジックを含む項目１に記載の装置。
（項目６）
前記メタフィジカル変換ロジックは、前記データアドレスを、さらに前記処理要素に対応付けられている処理要素識別子（ＰＥＩＤ）に基づいて、前記現行ソフトウェアサブシステムに対応付けられている前記メタフィジカルアドレス空間内のメタデータアドレスに変換する項目５に記載の装置。
（項目７）
前記メタフィジカル変換ロジックは、前記データアドレスを、さらにデータ対メタデータの圧縮比に基づいて、前記現行ソフトウェアサブシステムに対応付けられている前記メタフィジカルアドレス空間内のメタデータアドレスに変換する項目６に記載の装置。
（項目８）
前記現行ソフトウェアサブシステムによって修正可能なレジスタをさらに備え、
前記レジスタは、前記現行ソフトウェアサブシステムからの書込みに応じて、前記ＭＤＩＤを保持して、前記現行ソフトウェアサブシステムが現在前記処理要素で実行されている旨を示し、
前記メタフィジカル変換ロジックが、前記データアドレスを、前記ＰＥＩＤおよび前記ＭＤＩＤに基づいて、前記現行ソフトウェアサブシステムに対応付けられている前記メタフィジカルアドレス空間内のメタデータアドレスに変換することは、前記メタフィジカル変換ロジックが、前記データアドレスを表す情報と、前記ＰＥＩＤおよび前記ＭＤＩＤとを組み合わせることを含む項目６に記載の装置。
（項目９）
前記メタフィジカル変換ロジックは、前記データアドレスを表す情報と前記ＰＥＩＤおよび前記ＭＤＩＤとを組み合わせる場合に、前記ＰＥＩＤおよび前記ＭＤＩＤを前記データアドレスに追加して前記メタデータアドレスを形成するアルゴリズム、通常のデータ変換テーブルを用いて前記データアドレスを変換後データアドレスに変換して、前記ＰＥＩＤおよび前記ＭＤＩＤを前記変換後データアドレスに追加して前記メタデータアドレスを形成するアルゴリズム、および、通常のデータ変換テーブルとは別のメタフィジカル変換テーブルを用いて前記データアドレスを変換後メタデータアドレスに変換して、前記ＰＥＩＤおよび前記ＭＤＩＤを前記変換後メタデータアドレスに追加して前記メタデータアドレスを形成するアルゴリズムから成る群から選択される組み合わせアルゴリズムに基づいて行う項目８に記載の装置。
（項目１０）
データアドレス空間内にあるデータアドレスであって、キャッシュメモリのデータエントリに保持されているデータアイテムに対応付けられているデータアドレスを参照するメタデータ処理を発見する段階と、
前記データアドレス空間とは別個のメタフィジカルアドレス空間内のメタデータアドレスを、前記データアドレス、前記メタデータ処理に対応付けられている処理要素の処理要素識別子（ＰＥＩＤ）、および、前記処理要素に対応付けられているソフトウェアサブシステムのメタデータ識別子（ＭＤＩＤ）に基づいて決定する段階と、
前記メタデータアドレスに基づいて、前記キャッシュメモリのメタデータエントリにアクセスする段階と
を備える方法。
（項目１１）
前記メタフィジカルアドレス空間は、同様に前記処理要素に対応付けられている追加ソフトウェアサブシステムに対応付けられている追加メタフィジカルアドレス空間からも別個である項目１０に記載の方法。
（項目１２）
前記ソフトウェアサブシステムは、トランザクショナル・ランタイム・サブシステム、ガベージ・コレクション・ランタイム・サブシステム、メモリ保護サブシステム、ソフトウェア変換サブシステム、ネスト化された一群のトランザクションのうち一の外側トランザクション、および、ネスト化された一群のトランザクションのうち一の内側トランザクションから成る群から選択される項目１０に記載の方法。
（項目１３）
前記処理要素で現在実行されている前記ソフトウェアサブシステムに応答した、前記ソフトウェアサブシステムからの、前記処理要素に対応付けられている制御レジスタへの書込み処理を発見することに応じて、前記制御レジスタに前記ＭＤＩＤを書き込む段階と、
前記制御レジスタに基づき前記ＭＤＩＤを決定する段階と
をさらに備える項目１０に記載の方法。
（項目１４）
前記メタデータ処理のオペコードの一部分に基づき前記ＰＥＩＤを決定する段階をさらに備える項目１３に記載の方法。
（項目１５）
前記メタデータアドレスを前記データアドレス、前記ＰＥＩＤ、および、前記ＭＤＩＤから決定する段階は、前記ＰＥＩＤおよび前記ＭＤＩＤを前記データアドレスに追加して前記メタデータアドレスを形成するアルゴリズム、通常のデータ変換テーブルを用いて前記データアドレスを変換後データアドレスに変換して、前記ＰＥＩＤおよび前記ＭＤＩＤを前記変換後データアドレスに追加して前記メタデータアドレスを形成するアルゴリズム、および、通常のデータ変換テーブルとは別のメタフィジカル変換テーブルを用いて前記データアドレスを変換後メタデータアドレスに変換して、前記ＰＥＩＤおよび前記ＭＤＩＤを前記変換後メタデータアドレスに追加して前記メタデータアドレスを形成するアルゴリズムから成る群から選択されたアルゴリズムと、前記データアドレス、前記ＰＥＩＤおよび前記ＭＤＩＤとを組み合わせる段階を有する項目１３に記載の方法。
（項目１６）
データアイテムのデータアドレスを参照するメタデータアクセス命令をデコードするデコードロジックと、
前記データアドレスをソフトウェアに対してトランスペアレントに別個のメタデータアドレスに変換し、前記デコードロジックが前記メタデータアクセス命令をデコードすることに応じて前記別個のメタデータアドレスによって参照されているメタデータにアクセスするメタデータロジックと
を備え、
前記メタデータアクセス命令は、前記デコードロジックが適切にデコード可能な命令群の一部として認識可能なオペコードを含む、装置。
（項目１７）
前記メタデータアクセス命令は、メタデータ・ビット試験および設定（ＭＤＬＴ）命令、メタデータストアおよび設定（ＭＳＳ）命令、および、メタデータストアおよびリセット命令（ＭＤＳＲ）から成る命令群から選択される項目１６に記載の装置。
（項目１８）
前記メタデータアクセス命令は、圧縮メタデータ試験（ＣＭＤＴ）命令、圧縮メタデータストア（ＣＭＳ）命令、および、圧縮メタデータクリア（ＣＭＤＣＬＲ）命令から成る命令群から選択される項目１６に記載の装置。
（項目１９）
前記メタデータロジックが前記データアドレスをソフトウェアに対してトランスペアレントに別個のメタデータアドレスに変換することは、前記メタデータアクセス命令に対応付けられている、ソフトウェアサブシステムによって制御レジスタにおいて特定されているメタデータ識別子（ＭＤＩＤ）に少なくとも基づいて前記データアドレスを変換することを含む項目１６に記載の装置。
（項目２０）
前記メタデータアクセス命令はさらに、デスティネーションレジスタへの参照を含み、
前記メタデータロジックが前記別個のメタデータアドレスによって参照されているメタデータにアクセスすることは、前記メタデータロジックが、参照されている前記別個のメタデータアドレスにおける前記メタデータを前記デスティネーションレジスタにロードすることを含む項目１６に記載の装置。
（項目２１）
前記オペコードは、前記メタデータアクセス命令を発行したスレッドを特定するスレッド識別子フィールドを含む項目２０に記載の装置。
（項目２２）
前記メタデータロジックが前記別個のメタデータアドレスによって参照されているメタデータにアクセスすることは、前記メタデータロジックが、前記デスティネーションレジスタにロードされた前記メタデータが未設定値であることに応じて、参照されている前記別個のメタデータアドレスにおける前記メタデータを設定値に設定することをさらに含む項目２０に記載の装置。
（項目２３）
前記設定値および前記未設定値は、前記メタデータアクセス命令で定められている項目２２に記載の装置。
（項目２４）
プログラムコードを保持する機械可読媒体であって、前記プログラムコードが機械によって実行されると、前記機械は、
データアドレスを参照するデータアクセス処理に応じて、前記データアクセス処理において前記データアドレスを参照するメタデータアクセス処理を生成して、
前記メタデータアクセス処理が前記機械によって実行されると、前記機械は、
前記データアドレスを、前記データアドレスとは別個のメタデータアドレスに変換して、
前記メタデータアドレスに基づき、前記データアドレスにおけるデータアイテムのメタデータにアクセスする機械可読媒体。
（項目２５）
前記メタデータアクセス処理は、メタデータ・ビット試験および設定（ＭＤＬＴ）命令、メタデータストアおよび設定（ＭＳＳ）命令、および、メタデータストアおよびリセット命令（ＭＤＳＲ）から成る命令群から選択される項目２４に記載の機械可読媒体。
（項目２６）
前記メタデータアクセス処理は、圧縮メタデータ試験（ＣＭＤＴ）命令、圧縮メタデータストア（ＣＭＳ）命令、および、圧縮メタデータクリア（ＣＭＤＣＬＲ）命令から成る圧縮命令群から選択される項目２４に記載の機械可読媒体。
（項目２７）
前記メタデータアクセス処理が前記機械によって実行されると、前記機械が前記データアドレスをメタデータアドレスへと変換することは、前記メタデータアクセス処理が前記機械によって実行されると、前記機械が、データ対メタデータの圧縮比に基づき、前記データアドレスと、前記メタデータアクセス処理に対応付けられている処理要素識別子（ＰＥＩＤ）、および、前記メタデータアクセス処理に対応付けられているメタデータデータ識別子（ＭＤＩＤ）とを組み合わせることを含む項目２６に記載の機械可読媒体。
（項目２８）
前記データアドレスは、前記データアイテムを参照するべく、前記機械が有する仮想−物理アドレス変換ロジックによっても変換可能である項目２７に記載の機械可読媒体。
（項目２９）
前記メタデータアクセス処理はさらに、オペランドレジスタを参照し、
前記メタデータアクセス処理が前記機械によって実行されると前記機械が前記データアイテムのメタデータにアクセスすることは、前記メタデータアクセス処理が前記機械によって実行されると、前記機械は前記オペランドレジスタに保持されている値で前記データアイテムの前記メタデータを更新することを含む項目２４に記載の機械可読媒体。
（項目３０）
前記プログラムコードはコンパイラコードを含み、
前記コンパイラコードは、前記データアクセス処理を含むアプリケーションコードをコンパイルし、
前記データアクセス処理において前記メタデータアクセス処理を生成することは、前記アプリケーションコードのコンパイル後のバージョンにおいて前記メタデータアクセス処理を生成することを含む項目２４に記載の機械可読媒体。
（項目３１）
プログラムコードを保持する機械可読媒体であって、前記プログラムコードが機械で実行されると、前記機械は、
前記プログラムコードに含まれるメタデータアクセス命令によって参照されるデータアドレスを、前記メタデータアクセス命令に対応付けられている処理要素において現在アクティブであるソフトウェアサブシステムと対応付けられているメタデータ識別子（ＭＤＩＤ）に基づいて、メタデータアドレスに変換し、
前記メタデータアドレスに基づいてメタデータにアクセスする機械可読媒体。
（項目３２）
前記メタデータアクセス命令は、前記メタデータをロードするメタデータロード命令、前記メタデータにストアするメタデータストア命令、および、前記メタデータをリセットするメタデータクリア命令から成る命令群から選択される項目３１に記載の機械可読媒体。
（項目３３）
前記ソフトウェアサブシステムは、トランザクショナル・ランタイム・サブシステム、ガベージ・コレクション・ランタイム・サブシステム、メモリ保護サブシステム、ソフトウェア変換サブシステム、ネスト化された一群のトランザクションのうち一の外側トランザクション、および、ネスト化された一群のトランザクションのうち一の内側トランザクションから成る群から選択される項目３１に記載の機械可読媒体。
（項目３４）
前記プログラムコードに含まれるメタデータアクセス命令によって参照されるデータアドレスを、前記メタデータアクセス命令に対応付けられている処理要素において現在アクティブであるソフトウェアサブシステムと対応付けられているメタデータ識別子（ＭＤＩＤ）に基づいて、メタデータアドレスに変換することは、前記ＭＤＩＤを前記データアドレスに追加して前記メタデータアドレスを形成するアルゴリズム、通常のデータトランザクションテーブルを用いて前記データアドレスを変換後データアドレスに変換して、前記ＭＤＩＤを前記変換後アドレスに追加して前記メタデータアドレスを形成するアルゴリズム、および、通常のデータ変換テーブルとは別のメタフィジカル変換テーブルを用いて前記データアドレスを変換後メタデータアドレスに変換して、前記ＭＤＩＤを前記変換後メタデータアドレスに追加して前記メタデータアドレスを形成するアルゴリズムから成る群から選択される組み合わせアルゴリズムに基づき、前記ＭＤＩＤと前記データアドレスとを組み合わせることを含む項目３１に記載の機械可読媒体。
（項目３５）
前記ＭＤＩＤを追加することは、前記ＭＤＩＤをＭＳＢ位置に付加するアルゴリズム、前記ＭＤＩＤをＬＳＢ位置に付加するアルゴリズム、アドレスビットを前記ＭＤＩＤで置換するアルゴリズムから成る群から選択される前記ＭＤＩＤを追加するアルゴリズムを含む項目３４に記載の機械可読媒体。
（項目３６）
前記プログラムコードを前記機械で実行すると、前記機械はさらに、前記処理要素で現在アクティブである現行ソフトウェアサブシステムを示す、前記処理要素のための制御レジスタに基づき前記ＭＤＩＤを決定する項目３４に記載の機械可読媒体。
（項目３７）
データアイテムに対応付けられているデータメモリアドレスを参照するメタデータアクセス命令を含むプログラムコードを保持するメモリと、
前記メモリに対応付けられているプロセッサと
を備え、
前記プロセッサは、
前記メタデータアクセス命令の実行に対応付けられる複数の処理要素のうちの一の処理要素と、
前記メモリから前記メタデータアクセス命令をフェッチするフェッチロジックと、
前記メタデータアクセス命令を少なくとも一のメタデータアクセス処理にデコードするデコードロジックと、
前記処理要素におけるアクティブコンテクストに対応付けられているメタデータ識別子（ＭＤＩＤ）を保持する制御レジスタと、
前記データアイテムを保持するためのデータエントリを含むデータキャッシュメモリと、
前記メタデータアクセス処理を実行する実行ロジックと
を有し、
前記実行ロジックが前記メタデータアクセス処理を実行することは、前記プロセッサが有するメタフィジカルアドレス変換ロジックが、前記制御レジスタに保持されている前記ＭＤＩＤに基づいて、前記データメモリアドレスをメタデータメモリアドレスに変換することを含み、前記データキャッシュメモリに結合されているキャッシュ制御ロジックが、前記メタデータメモリアドレスに基づいて、前記データキャッシュメモリの別のエントリに対して前記メタデータアクセス処理を実行することを含むシステム。
（項目３８）
前記メタデータアクセス命令は、前記メタデータをロードするメタデータロード命令、前記メタデータにストアするメタデータストア命令、および、前記メタデータをリセットするメタデータクリア命令から成る命令群から選択される項目３７に記載のシステム。
（項目３９）
前記アクティブコンテクストは、トランザクショナル・ランタイム・サブシステム、ガベージ・コレクション・ランタイム・サブシステム、メモリ保護サブシステム、ソフトウェア変換サブシステム、ネスト化された一群のトランザクションのうち一の外側トランザクション、および、ネスト化された一群のトランザクションのうち一の内側トランザクションから成る群から選択される項目３７に記載のシステム。
（項目４０）
前記プロセッサが有する前記メタフィジカルアドレス変換ロジックが前記データメモリアドレスをメタデータメモリアドレスに変換することはさらに、前記処理要素のための処理要素識別子（ＰＥＩＤ）に基づいて行われ、
前記プロセッサが有する前記メタフィジカルアドレス変換ロジックが、前記ＰＥＩＤおよび前記制御レジスタに保持されている前記ＭＤＩＤに基づいて、前記データメモリアドレスをメタデータメモリアドレスに変換することは、前記ＰＥＩＤおよび前記ＭＤＩＤを前記データメモリアドレスに追加して前記メタデータメモリアドレスを形成するアルゴリズム、通常のデータトランザクションテーブルを用いて前記データメモリアドレスを変換後データメモリアドレスに変換して、前記ＰＥＩＤおよび前記ＭＤＩＤを前記変換後データメモリアドレスに追加して前記メタデータメモリアドレスを形成するアルゴリズム、および、通常のデータ変換テーブルとは別のメタフィジカル変換テーブルを用いて前記データメモリアドレスを変換後メタデータメモリアドレスに変換して、前記ＰＥＩＤおよび前記ＭＤＩＤを前記変換後メタデータメモリアドレスに追加して前記メタデータメモリアドレスを形成するアルゴリズムから成る群から選択される組み合わせアルゴリズムに基づいて、前記ＰＥＩＤおよび前記ＭＤＩＤと前記データメモリアドレスとを組み合わせることを含む項目３７に記載のシステム。
（項目４１）
プロセッサであって、
アドレスを参照するメタデータロード処理を実行する実行モジュールと、
前記メタデータロード処理に応じて、前記プロセッサが第１のモードで動作している場合にはアドレスに対応付けられているメタデータ値を提供し、前記プロセッサが第２のモードで動作している場合には固定値を提供する強制モジュールと
を備えるプロセッサ。
（項目４２）
前記第１のモードは強アトミック性モードを含み、前記第２のモードは弱アトミック性モードを含む項目４１に記載のプロセッサ。
（項目４３）
前記固定値を保持する第１のレジスタをさらに備える項目４２に記載のプロセッサ。
（項目４４）
モード値を保持する第２のレジスタをさらに備え、
前記モード値は、前記プロセッサが前記強アトミック性モードで動作している旨を示す場合には第１の値を表し、
前記モード値は、前記プロセッサが前記弱アトミック性モードで動作している旨を示す場合には第２の値を表す項目４３に記載のプロセッサ。
（項目４５）
前記第１のレジスタおよび前記第２のレジスタは、同じメタデータ制御レジスタである項目４４に記載のプロセッサ。
（項目４６）
前記強制モジュールが、前記プロセッサが前記強アトミック性モードで動作している場合にはアドレスに対応付けられているメタデータ値を提供し、前記プロセッサが前記弱アトミック性モードで動作している場合には固定値を提供することは、前記強制モジュールが、前記第２のレジスタに保持される前記モード値が前記プロセッサが前記強アトミック性モードで動作している旨を示す前記第１の値を表している場合には、前記メタデータロード処理が定めるデスティネーションレジスタに前記メタデータ値をロードして、前記第２のレジスタに保持される前記モード値が前記プロセッサが前記弱アトミック性モードで動作している旨を示す前記第２の値を表す場合には、前記第１のレジスタから前記デスティネーションレジスタへと前記固定値をロードすることを含む項目４４に記載のプロセッサ。
（項目４７）
アドレスを参照するメタデータアクセス処理を発見する段階と、
プロセッサの実行モードを判断する段階と、
前記プロセッサの実行モードが第１の実行モードであると判断されると、前記メタデータアクセス処理に対して、前記アドレスに対応付けられているメタデータ値を提供する段階と、
前記プロセッサの実行モードが第２の実行モードであると判断されると、前記メタデータアクセス処理に対して、レジスタから固定値を提供する段階と
を備える方法。
（項目４８）
前記プロセッサの実行モードを判断する段階は、第１の制御レジスタからモードフラグを読み出す段階を有し、
前記モードフラグは、前記プロセッサの実行モードが第１の実行モードである旨を示す第１の値を保持し、前記プロセッサの実行モードが第２の実行モードである旨を示す第２の値を保持する項目４７に記載の方法。
（項目４９）
前記メタデータアクセス処理に対して、前記アドレスに対応付けられているメタデータ値を提供する段階は、前記アドレスに対応付けられているメモリ位置から、前記メタデータアクセス処理が参照しているデスティネーションレジスタへと、前記メタデータ値をロードする段階を有する項目４７に記載の方法。
（項目５０）
前記メタデータアクセス処理に対して、レジスタから固定値を提供する段階は、前記レジスタから前記デスティネーションレジスタへと前記固定値をロードする段階を有する項目４９に記載の方法。
（項目５１）
アドレスおよびデスティネーションレジスタを参照するメタデータロード処理を保持するメモリと、
前記メモリに対応付けられているプロセッサと
を備え、
前記プロセッサは、
前記メタデータロード処理を実行する実行ロジックと、
強制値を保持するメタデータレジスタと、
前記アドレスに対応付けられているメタデータ値を保持するキャッシュメモリと、
前記実行ロジックが前記メタデータロード処理を実行すると、前記プロセッサが第１のモードで動作する場合には前記メタデータ値を前記デスティネーションレジスタに提供し、前記プロセッサが第２のモードで動作している場合に前記メタデータレジスタから前記デスティネーションレジスタへと前記強制値を提供する強制ロジックと
を有するシステム。
（項目５２）
前記強制ロジックはさらに、前記プロセッサが前記第１のモードまたは前記第２のモードのいずれで動作しているかを判断する項目５１に記載のシステム。
（項目５３）
前記第１のモードは、強アトミック性モードを含み、前記第２のモードは、弱アトミック性モードを含む項目５２に記載のシステム。
（項目５４）
前記メタデータレジスタはさらに、モード値を保持し、
前記モード値は、前記プロセッサが前記第１のモードで動作している場合に第１の値を示し、前記プロセッサが前記第２のモードで動作している場合に第２の値を示し、
前記強制ロジックがさらに前記プロセッサが前記第１のモードまたは前記第２のモードのいずれで動作しているかを判断することは、前記強制ロジックが前記メタデータレジスタの前記モード値を解釈することを含む項目５２に記載のシステム。
（項目５５）
モード値を保持する制御レジスタをさらに備え、
前記モード値は、前記プロセッサが前記第１のモードで動作している場合に第１の値を示し、前記プロセッサが前記第２のモードで動作している場合に第２の値を示し、
前記強制ロジックがさらに前記プロセッサが前記第１のモードまたは前記第２のモードのいずれで動作しているかを判断することは、前記強制ロジックが前記制御レジスタの前記モード値を解釈することを含む項目５２に記載のシステム。
（項目５６）
前記メモリは、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、および、不揮発性メモリから成る群から選択される項目５１に記載のシステム。
（項目５７）
キャッシュエントリを保持するデータキャッシュアレイと、
前記データキャッシュアレイに結合されているキャッシュ制御ロジックと
を備え、
前記キャッシュ制御ロジックは、
前記キャッシュエントリに対するバッファ済み更新に応じて、前記キャッシュエントリを、監視されていない状態からバッファ済みコヒーレンシ状態および読出監視状態へと遷移させて、
その後に、前記バッファ済み更新をコミットするために前記キャッシュエントリを修正済み状態に遷移させる前に、前記キャッシュエントリを、バッファ済みコヒーレンシ状態および書込監視状態に遷移させる、装置。
（項目５８）
前記キャッシュエントリに対する前記バッファ済み更新は、前記キャッシュエントリに保持されるデータアイテムのデータアドレスに対するトランザクショナルメモリアクセス、前記キャッシュエントリに保持されるメタデータに対応付けられているデータアドレスへのメタデータアクセス、および、前記キャッシュエントリへのローカル更新から成る群から選択される更新を含む項目５７に記載の装置。
（項目５９）
前記キャッシュ制御ロジックが、前記キャッシュエントリを、監視されてない状態からバッファ済みコヒーレンシ状態および読出監視状態へと遷移させることは、前記キャッシュ制御ロジックが前記キャッシュエントリに対応付けられているコヒーレンシビットをバッファ済み値に更新して前記バッファ済みコヒーレンシ状態を表し、前記キャッシュエントリに対応付けられている読出監視属性ビットを読出監視値に更新して前記読出監視状態を表すことを含む項目５７に記載の装置。
（項目６０）
前記キャッシュ制御ロジックが、前記バッファ済み更新をコミットするために前記キャッシュエントリを修正済み状態に遷移させる前に、前記キャッシュエントリを、バッファ済みコヒーレンシ状態および書込監視状態に遷移させることは、前記キャッシュ制御ロジックが、前記キャッシュエントリに対応付けられている前記コヒーレンシビットの前記バッファ済み値を維持して前記バッファ済みコヒーレンシ状態を表し、前記キャッシュエントリに対応付けられている書込監視属性ビットを書込監視値に更新して前記書込監視状態を表すことを含む項目５９に記載の装置。
（項目６１）
前記キャッシュ制御ロジックが前記キャッシュエントリを前記修正済み状態に遷移させることは、前記キャッシュ制御ロジックが、前記キャッシュエントリに対応付けられている前記コヒーレンシビットを修正済み値に更新して前記修正済みコヒーレンシ状態を表すことを含む項目６０に記載の装置。
（項目６２）
前記バッファ済み更新を実行した後にコミット処理を実行する実行ロジックをさらに備え、
前記キャッシュ制御ロジックが、前記バッファ済み更新をコミットするために前記キャッシュエントリを修正済み状態に遷移させる前に、前記キャッシュエントリをバッファ済みコヒーレンシ状態および書込監視状態に遷移させることは、前記実行ロジックが前記コミット処理を実行することに応じて行なう項目５７に記載の装置。
（項目６３）
キャッシュメモリのブロックに対するバッファ済み更新を発見する段階と、
前記キャッシュメモリの前記ブロックに対する前記バッファ済み更新を発見すると、前記ブロックに対して読出監視を適用する段階と、
前記読出監視を適用する段階の後に、前記ブロックをコミットする前に、前記ブロックに書込監視を適用する段階と
を備える方法。
（項目６４）
前記キャッシュメモリの前記ブロックに対する前記バッファ済み更新は、前記キャッシュメモリの前記ブロックに対するトランザクション的書込を含む項目６３に記載の方法。
（項目６５）
前記読出監視を適用する段階と同時に前記キャッシュメモリの前記ブロックに対して前記バッファ済み更新を実行する段階をさらに備え、
前記ブロックは、前記バッファ済み更新を実行した後は、バッファ済みコヒーレンシ状態で保持される項目６３に記載の方法。
（項目６６）
前記読出監視を適用する段階の後に前記キャッシュメモリの前記ブロックに対して前記バッファ済み更新を実行する段階をさらに備え、
前記ブロックは、前記バッファ済み更新を実行した後は、バッファ済みコヒーレンシ状態で保持される項目６３に記載の方法。
（項目６７）
前記キャッシュメモリの前記ブロックに対する前記バッファ済み更新を発見すると、前記ブロックに対して読出監視を適用する段階は、
前記キャッシュメモリのキャッシュドメインの外部の複数の処理要素に対して、前記ブロックに対する読出要求を生成する段階と、
前記ブロックに対する前記読出要求に応じて前記キャッシュドメインの外部の前記複数の処理要素からコンフリクトがないことを検出すると、前記キャッシュメモリの前記ブロックに対応付けられている読出監視属性を読出監視値に更新して前記ブロックに読出監視を適用する段階と
を有する項目６３に記載の方法。
（項目６８）
前記読出監視を適用する段階の後に、前記ブロックをコミットする前に、前記ブロックに書込監視を適用する段階は、
前記キャッシュメモリの前記キャッシュドメインの外部の前記複数の処理要素に対して、前記ブロックについての所有権読出要求を生成する段階と、
前記ブロックについての前記所有権読出要求に応じて前記キャッシュドメインの外部の前記複数の処理要素からコンフリクトがないと検出することに応じて、前記キャッシュメモリの前記ブロックに対応付けられている書込監視属性を書込監視値に更新して、前記ブロックに書込監視を適用する段階と
を有する項目６７に記載の方法。
（項目６９）
前記ブロックをコミットすることは、前記ブロックのキャッシュコヒーレンシ状態を、バッファ済みコヒーレンシ状態から修正済みコヒーレンシ状態へと遷移させることを含む項目６８に記載の方法。
（項目７０）
プログラムコードを保持する機械アクセス可能媒体であって、
前記プログラムコードを機械が実行すると、前記機械は、
キャッシュメモリのブロックへのバッファ済み書込があると、前記ブロックに読出監視を適用し、
前記ブロックに対して前記バッファ済み書込を実行し、
前記読出監視を適用した後、且つ、前記ブロックをコミットする前に、前記ブロックに書込監視を適用する機械アクセス可能媒体。
（項目７１）
前記キャッシュメモリの前記ブロックへの前記バッファ済み書込があると、前記ブロックに読出監視を適用することは、
前記キャッシュメモリのキャッシュドメインの外部の複数の処理要素に対して前記ブロックについての読出要求を生成することと、
前記ブロックについての前記読出要求に応じて前記キャッシュドメインの外部の前記複数の処理要素からコンフリクトがないことを検出することに応じて、前記キャッシュメモリの前記ブロックに対応付けられている読出監視属性を読出監視値に更新して前記ブロックに対して読出監視を適用することと
を含む
項目７０に記載の機械アクセス可能媒体。
（項目７２）
前記読出監視を適用した後、且つ、前記ブロックをコミットする前に、前記ブロックに書込監視を適用することは、
前記キャッシュメモリの前記キャッシュドメインの外部の前記複数の処理要素に対して前記ブロックについての所有権読出要求を生成することと、
前記ブロックについての前記所有権読出要求に応じて前記キャッシュドメインの外部の前記複数の処理要素からコンフリクトがないと検出することに応じて、前記キャッシュメモリの前記ブロックに対応付けられている書込監視属性を書込監視値に更新して前記ブロックに書込監視を適用することと
を含む項目７１に記載の機械アクセス可能媒体。
（項目７３）
コミット処理を発見することに応じて、前記読出監視を適用した後、且つ、前記ブロックをコミットする前に、前記ブロックに書込監視を適用する項目７０に記載の機械アクセス可能媒体。
（項目７４）
前記ブロックをコミットすることは、前記ブロックのキャッシュコヒーレンシ状態を修正済みコヒーレンシ状態に遷移させることを含む項目７０に記載の機械アクセス可能媒体。
（項目７５）
メモリアドレスを参照するトランザクション的書込、および、コミット処理を保持するシステムメモリと、
キャッシュメモリを有し、前記システムメモリに対応付けられているプロセッサと
を備え、
前記プロセッサが有する前記キャッシュメモリは、
前記トランザクション的書込を受信することに応じて前記メモリアドレスに対応付けられているキャッシュラインについての読出要求を生成し、
前記読出要求に基づきコンフリクトが検出されないことに応じて、バッファされており読出監視されている状態に前記キャッシュラインを遷移させ、
前記コミット処理を受信することに応じて所有権読出要求を生成し、前記所有権読出要求に基づきコンフリクトが検出されないことに応じて、バッファされており書込監視されている状態に前記キャッシュラインを遷移させ、
前記バッファされており書込監視されている状態に前記キャッシュラインを遷移させることに応じて、修正済み状態に前記キャッシュラインを遷移させる、システム。
（項目７６）
前記キャッシュメモリが、バッファされており読出監視されている状態に前記キャッシュラインを遷移させることは、前記キャッシュメモリが、前記キャッシュラインに対応付けられているコヒーレンシビットをバッファ済み値に更新して、前記バッファされており読出監視されている状態のうちバッファされている状態の部分を表し、前記キャッシュラインに対応付けられている読出監視属性ビットを読出監視値に更新して、前記バッファされており読出監視されている状態のうち読出監視されている状態の部分を表すことを含む項目７５に記載のシステム。
（項目７７）
前記キャッシュメモリが、バッファされており書込監視されている状態に前記キャッシュラインを遷移させることは、前記キャッシュメモリが、前記キャッシュラインに対応付けられている前記コヒーレンシビットの前記バッファ済み値を維持して、前記バッファされており書込監視されている状態のうちバッファされている状態の部分を表し、前記キャッシュラインに対応付けられている書込監視属性ビットを書込監視値に更新して、前記バッファされており書込監視されている状態のうち書込監視されている状態部分を表すことを含む項目７６に記載のシステム。
（項目７８）
前記キャッシュメモリが、前記キャッシュラインを前記バッファされており書込監視されている状態に遷移させることに応じて、前記キャッシュラインを修正済み状態に遷移させることは、前記コヒーレンシビットを修正済み値に更新して前記修正済み状態を表すことを含む項目７７に記載のシステム。
（項目７９）
前記メモリは、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、および、不揮発性メモリから成る群から選択される項目７５に記載のシステム。
（項目８０）
損失命令をデコードしてデコード済み要素を提供するデコードロジックと、
損失イベントが検出された旨を示す損失値を保持する損失フィールドを有するステータス格納要素と、
前記ステータス格納要素に結合されているジャンプロジックと
を備え、
前記損失命令は、ラベルを参照しており、オペレーションコード（オペコード）を含み、前記デコードロジックによって認識可能な命令群の一部となり、
前記ジャンプロジックは、前記デコード済み要素、および、前記損失イベントが検出された旨を示す前記損失値に基づいて前記ラベルに制御を渡す、装置。
（項目８１）
前記ラベルはジャンプ先アドレスを含み、
損失イベントは、読出監視されているキャッシュラインへの書込みが発生した旨を示す読出監視コンフリクト、書込監視されているキャッシュラインへのアクセスが発生した旨を示す書込監視コンフリクト、および、バッファされているキャッシュラインの損失から成る群から選択される項目８０に記載の装置。
（項目８２）
前記ステータス格納要素はレジスタを有し、
前記損失値を保持する前記損失フィールドは、読出監視コンフリクトが検出されると設定される第１のビットと、書込監視コンフリクトが検出されると設定される第２のビットと、バッファされている物理データの損失が検出されると設定される第３のビットと、バッファされているメタデータの損失が検出されると設定される第４のビットとを含む項目８０に記載の装置。
（項目８３）
前記損失命令は読出監視損失命令を含み、前記オペコードは読出監視損失イベント型を規定し、
前記ジャンプロジックが、前記デコード済み要素、および、前記損失イベントが検出された旨を示す前記損失値に基づいて前記ラベルに制御を渡すことは、前記ジャンプロジックが、発生した前記損失イベントの種類が、前記読出監視損失命令の前記オペコードによって規定されている前記読出監視損失イベント型である旨を示す前記損失値を前記損失フィールドが保持していることに応じて、前記ラベルに実行をジャンプさせることを含む項目８０に記載の装置。
（項目８４）
前記損失命令は書込監視損失命令を含み、前記オペコードは書込監視損失イベント型を規定し、
前記ジャンプロジックが、前記デコード済み要素、および、前記損失イベントが検出された旨を示す前記損失値を保持する前記損失フィールドに基づいて前記ラベルに制御を渡すことは、前記ジャンプロジックが、発生した前記損失イベントの種類が、前記書込監視損失命令の前記オペコードによって規定されている前記書込監視損失イベント型である旨を示す前記損失値を前記損失フィールドが保持していることに応じて、前記ラベルに実行をジャンプさせることを含む項目８０に記載の装置。
（項目８５）
前記損失命令はバッファ済み損失命令を含み、前記オペコードはバッファ済み損失イベント型を規定し、
前記ジャンプロジックが、前記デコード済み要素、および、前記損失イベントが検出された旨を示す前記損失値を保持する前記損失フィールドに基づいて前記ラベルに制御を渡すことは、前記ジャンプロジックが、発生した前記損失イベントの種類が、前記バッファ済み損失命令の前記オペコードによって規定されている前記バッファ済み損失イベント型である旨を示す前記損失値を前記損失フィールドが保持していることに応じて、前記ラベルに実行をジャンプさせることを含む項目８０に記載の装置。
（項目８６）
プログラムコードを保持する機械アクセス可能媒体であって、
前記プログラムコードを機械が実行すると、前記機械は、
損失命令に応じて、
前記損失命令によって規定されており、前記機械に設けられているトランザクションステータスレジスタに保持されているトランザクションのステータスを判断して、
前記損失命令に対応付けられている損失イベントが検出された旨を前記トランザクションの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導する機械アクセス可能媒体。
（項目８７）
前記ラベルはジャンプ先アドレスを含み、
損失イベントは、読出監視されているキャッシュラインへの書込みが発生した旨を示す読出監視コンフリクト、書込監視されているキャッシュラインへのアクセスが発生した旨を示す書込監視コンフリクト、および、バッファされているキャッシュラインの損失から成る群から選択される項目８６に記載の機械アクセス可能媒体。
（項目８８）
前記損失命令は、前記損失イベントを読出監視コンフリクトと規定する読出監視ジャンプ損失（ＪＬＯＳＳ）命令を含み、
前記トランザクションステータスレジスタに保持されているトランザクションのステータスを判断することは、前記トランザクションステータスレジスタに保持されている読出監視コンフリクトビットのステータスを判断することを含み、
前記損失命令に対応付けられている損失イベントが検出された旨を前記トランザクションの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導することは、読出監視コンフリクトが検出された旨を、前記トランザクションステータスレジスタに保持されている前記読出監視コンフリクトビットの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導することを含む項目８６に記載の機械アクセス可能媒体。
（項目８９）
前記損失命令は、前記損失イベントを書込監視コンフリクトと規定する書込監視ジャンプ損失（ＪＬＯＳＳ）命令を含み、
前記トランザクションステータスレジスタに保持されているトランザクションのステータスを判断することは、前記トランザクションステータスレジスタに保持されている書込監視コンフリクトビットのステータスを判断することを含み、
前記損失命令に対応付けられている損失イベントが検出された旨を前記トランザクションの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導することは、書込監視コンフリクトが検出された旨を、前記トランザクションステータスレジスタに保持されている前記書込監視コンフリクトビットの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導することを含む項目８６に記載の機械アクセス可能媒体。
（項目９０）
前記損失命令は、前記損失イベントをバッファ済み監視コンフリクトと規定するバッファ済み監視ジャンプ損失（ＪＬＯＳＳ）命令を含み、
前記トランザクションステータスレジスタに保持されているトランザクションのステータスを判断することは、前記トランザクションステータスレジスタに保持されているバッファ済み監視コンフリクトビットのステータスを判断することを含み、
前記損失命令に対応付けられている損失イベントが検出された旨を前記トランザクションの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導することは、バッファ済み監視コンフリクトが検出された旨を、前記トランザクションステータスレジスタに保持されている前記バッファ済み監視コンフリクトビットの前記ステータスが示していることに応じて、前記損失命令によって規定されているラベルに実行を誘導することを含む項目８６に記載の機械アクセス可能媒体。
（項目９１）
プロセッサにおいて損失命令を発見する段階と、
前記損失命令を発見する段階に応じて、前記プロセッサにおいて前記損失命令に対応付けられている損失イベントが検出されたか否かを判断する段階と、
前記損失命令を発見する段階に応じて前記損失命令が参照しているラベルに分岐して、前記損失命令に対応付けられている前記損失イベントが前記プロセッサにおいて検出されたと判断する段階と
を備える方法。
（項目９２）
前記ラベルはジャンプアドレスを含む項目９１に記載の方法。
（項目９３）
前記損失命令は読出監視損失命令を含み、
前記読出監視損失命令に対応付けられている前記損失イベントは、読出監視されているキャッシュラインへの書込を含む項目９１に記載の方法。
（項目９４）
前記損失命令は書込監視損失命令を含み、
前記書込監視損失命令に対応付けられている前記損失イベントは、書込監視されているキャッシュラインへのアクセスを含む項目９１に記載の方法。
（項目９５）
前記損失命令はバッファ済み損失命令を含み、
前記バッファ済み損失命令に対応付けられている前記損失イベントは、バッファされているキャッシュラインのエビクションを含む項目９１に記載の方法。
（項目９６）
前記プロセッサにおいてバッファされているキャッシュラインのエビクションが検出されたか否かを判断することは、トランザクションステータスレジスタのバッファ済み損失ステータスビットを確認して、前記バッファ済み損失ステータスビットが損失値に設定されていることに応じて、バッファされているキャッシュラインのエビクションが検出されたと判断することを含む項目９５に記載の方法。
（項目９７）
トランザクションのコミット命令をデコードしてデコード済み要素を提供するデコードロジックと、
前記デコード済み要素に応じて、前記コミット命令が規定するコミット条件が前記トランザクションについて満たされるか否かを判断するコミットロジックと
を備え、
前記コミット命令は、前記コミット条件を規定しており、オペレーションコード（オペコード）を含み、前記デコードロジックによって認識可能な命令群の一部となる、装置。
（項目９８）
前記コミット条件は、読出監視データの損失無し、書込監視データの損失無し、バッファデータの損失無し、および、メタデータの損失無しのうち任意の規定された組み合わせを含み、
前記コミットロジックが前記コミット条件が満たされていると判断することは、読出監視データの損失無し、書込監視データの損失無し、バッファデータの損失無し、および、メタデータの損失無しのうち前記規定された組み合わせが発生したと判断することを含む項目９７に記載の装置。
（項目９９）
前記コミット条件を規定する前記コミット命令は、４ビットを保持する前記コミット命令を含み、前記４ビットのうち、第１のビットは、設定されると、読出監視データの損失がコミットすべき条件であることを示し、第２のビットは、設定されると、書込監視データの損失がコミットすべき条件であることを示し、第３のビットは、設定されると、バッファデータの損失がコミットすべき条件であることを示し、第４のビットは、設定されると、メタデータの損失がコミットすべき条件であることを示す項目９７に記載の装置。
（項目１００）
前記４ビットは、前記オペコードに含まれる項目９９に記載の装置。
（項目１０１）
前記コミットロジックが前記コミット命令が規定する前記コミット条件が前記トランザクションについて満たされているか否か判断することは、前記コミットロジックが、前記コミット命令で設定される前記４ビットの各ビットについてトランザクションステータスレジスタの対応ステータスビットを確認して、確認した前記トランザクションステータスレジスタの前記対応ステータスビットのいずれも対応する損失を示すべく設定されていない場合に、前記コミット条件が満たされていると判断することを含む 項目９９に記載の装置。
（項目１０２）
前記コミット命令はさらに、読出監視データ、書込監視データ、バッファ済みデータ、および、メタデータのうちコミット時にクリアすべき組み合わせを示すクリア制御を規定しており、
前記コミットロジックは、前記コミット命令で規定する前記コミット条件が前記トランザクションについて満たされていると判断することに応じて前記トランザクションをコミットした後で、読出監視データ、書込監視データ、バッファデータ、および、メタデータのうち規定された前記組み合わせをクリアする項目９７に記載の装置。
（項目１０３）
プログラムコードを保持する機械可読媒体であって、
前記プログラムコードを機械が実行すると、前記機械は、
前記プログラムコードに含まれるトランザクションについて、少なくとも１つのコミット失敗条件を規定しているコミット命令を発見し、
前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたか否かを判断し、
前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたと判断したことに応じて、前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたことを示す値を提供する
機械可読媒体。
（項目１０４）
前記少なくとも１つのコミット失敗条件は、読出監視データの損失、書込監視データの損失、バッファデータの損失、および、メタデータの損失から成る群から選択される項目１０３に記載の機械可読媒体。
（項目１０５）
前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたことを示す値を提供することは、前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたことを示す値をデスティネーションレジスタにロードすることを含む項目１０３に記載の機械可読媒体。
（項目１０６）
前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたか否かを判断することは、
前記少なくとも１つのコミット失敗条件に対応付けられているトランザクションステータスレジスタのステータスビットを確認することと、
前記少なくとも１つのコミット失敗条件に対応付けられている前記ステータスビットが、前記トランザクションの実行中に前記少なくとも１つのコミット失敗条件が検出された旨を示すように設定されていることに応じて、前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されたと判断することと、
前記少なくとも１つのコミット失敗条件に対応付けられている前記ステータスビットが、前記トランザクションの実行中に前記少なくとも１つのコミット失敗条件が検出されなかった旨を示すようにリセットされていることに応じて、前記トランザクションの実行中に、前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されなかったと判断することと
を含む項目１０３に記載の機械可読媒体。
（項目１０７）
前記トランザクションの実行中に前記コミット命令が規定する前記少なくとも１つのコミット失敗条件が検出されなかったと判断することに応じて、前記トランザクションをコミットすることをさらに含む項目１０６に記載の機械可読媒体。
（項目１０８）
トランザクションにおいて、前記トランザクションについての複数のコミット失敗条件を規定しているオペレーションコード（オペコード）を含むコミット命令を発見する段階と、
前記トランザクションの実行中に前記コミット命令の前記オペコードにおいて規定されている前記トランザクションについての前記複数のコミット失敗条件がいずれも検出されなかったと判断する段階と、
前記トランザクションの実行中に前記コミット命令の前記オペコードにおいて規定されている前記トランザクションについての前記複数のコミット失敗条件がいずれも検出されなかったと判断することに応じて、前記トランザクションをコミットする段階と
を備える方法。
（項目１０９）
前記トランザクションについての前記複数のコミット失敗条件を規定している前記オペコードは、設定されると読出監視データの損失がコミット失敗条件であると規定する前記オペコードの第１のビットと、設定されると書込監視データの損失がコミット失敗条件であると規定する前記オペコードの第２のビットと、設定されるとバッファデータの損失がコミット失敗条件であると規定する前記オペコードの第３のビットと、設定されるとメタデータの損失がコミット失敗条件であると規定する前記オペコードの第４のビットとを含む項目１０８に記載の方法。
（項目１１０）
前記トランザクションの実行中に前記コミット命令の前記オペコードにおいて規定されている前記トランザクションについての前記複数のコミット失敗条件がいずれも検出されなかったと判断する段階は、
前記オペコードの前記第１のビットが設定されていることに応じて、トランザクションステータスレジスタの読出監視ビットが設定されておらず読出監視データの損失無しを示していると判断する段階と、
前記オペコードの前記第２のビットが設定されていることに応じて、前記トランザクションステータスレジスタの書込監視ビットが設定されておらず書込監視データの損失無しを示していると判断する段階と、
前記オペコードの前記第３のビットが設定されていることに応じて、前記トランザクションステータスレジスタのバッファ済みビットが設定されておらずバッファデータの損失無しを示していると判断する段階と、
前記オペコードの前記第４のビットが設定されていることに応じて、前記トランザクションステータスレジスタのメタデータビットが設定されておらずメタデータの損失無しを示していると判断する段階と
を有する項目１０９に記載の方法。
（項目１１１）
前記オペコードはさらに、クリア制御を規定しており、
前記クリア制御を規定している前記オペコードは、設定されると読出監視データをコミット時にクリアすることを規定している前記オペコードの第５のビットと、設定されると書込監視データをコミット時にクリアすることを規定している前記オペコードの第６のビットと、設定されるとバッファデータをコミット時にクリアすることを規定している前記オペコードの第７のビットと、設定されるとメタデータをコミット時にクリアすることを規定している前記オペコードの第８のビットとを含む項目１０９に記載の方法。
（項目１１２）
前記トランザクションをコミットする段階は、前記第５のビットが設定されている場合に読出監視データをクリアする段階と、前記第６のビットが設定されている場合に書込監視データをクリアする段階と、前記第７のビットが設定されている場合にバッファデータをクリアする段階と、前記第８のビットが設定されている場合にメタデータをクリアする段階を含む項目１１１に記載の方法。
（項目１１３）
トランザクションのためのコミット命令であって、クリア制御情報および前記トランザクションについての複数のコミット失敗条件を規定するオペレーションコード（オペコード）を含むコミット命令を含むプログラムコードを保持するメモリと、
前記コミット命令の前記オペコードをデコードするデコードロジック、および、コミットロジックを有するプロセッサと
を備え、
前記コミットロジックは、前記オペコードで規定される前記複数のコミット失敗条件のいずれも前記トランザクションの実行中に検出されなかったか否かを判断し、前記コミットロジックが前記トランザクションの実行中に前記複数のコミット失敗条件のいずれも検出されなかったと判断することに応じて、前記トランザクションをコミットし、
前記コミットロジックが前記トランザクションをコミットすることは、前記コミットロジックが、前記コミット命令の前記オペコードで規定される前記クリア制御情報に基づいてトランザクション情報をクリアすることを含む、システム。
（項目１１４）
前記コミット失敗条件は、読出監視データの損失、書込監視データの損失、バッファデータの損失、および、メタデータの損失を組み合わせて決まる項目１１３に記載のシステム。
（項目１１５）
前記コミット失敗条件は、書込監視データの損失、読出監視データの損失または書込監視データの損失、書込監視データの損失またはバッファデータの損失、書込監視データの損失またはメタデータの損失、および、書込監視データの損失、読出監視データの損失、バッファデータの損失またはメタデータの損失から成る群から選択される項目１１４に記載のシステム。
（項目１１６）
前記オペコードが前記クリア制御情報を規定することは、読出監視、書込監視、バッファ済みコヒーレンシおよびメタデータのうちどれがコミット時にクリアされるかを前記オペコードが規定していることを含み、
前記コミットロジックが前記コミット命令の前記オペコードに規定される前記クリア制御情報に基づいてトランザクション情報をクリアすることは、前記コミットロジックが前記読出監視、前記書込監視、前記バッファ済みコヒーレンシ、および、前記メタデータのうち前記オペコードでクリアされるべきことが規定されているものをクリアすることを含む項目１１３に記載のシステム。
（項目１１７）
トランザクションイネーブルフィールド（ＴＥＦ）を有する格納要素と、
リングレベル遷移イベントに応じて少なくとも前記ＴＥＦの状態を格納構造に保存し、リターンイベントに応じて少なくとも前記ＴＥＦの状態を前記格納構造から前記格納要素へと戻すロジックと
を備え、
前記ＴＥＦは、アクティブ値を保持している場合には対応付けられているトランザクションがアクティブでイネーブルされている旨を示し、非アクティブ値を保持している場合には対応付けられているトランザクションが一時停止している旨を示す、装置。
（項目１１８）
前記リングレベル遷移イベントは、割り込み、例外、システム呼び出し、仮想マシン開始、仮想マシン終了から成る群から選択されるイベントを含む項目１１７に記載の装置。
（項目１１９）
前記リターンイベントは、割り込みリターン（ＩＲＥＴ）、システムリターン（ＳＹＳＲＥＴ）、仮想マシン（ＶＭ）開始、および、仮想マシン（ＶＭ）終了から成る群から選択されるイベントを含む項目１１７に記載の装置。
（項目１２０）
前記格納要素はフラグレジスタを含み、
前記ＴＥＦはトランザクションイネーブルフラグを含む項目１１７に記載の装置。
（項目１２１）
前記格納構造はスタックを含み、前記ロジックが前記スタックに少なくとも前記ＴＥＦの状態を保存することは、プッシュロジックが少なくとも前記ＴＥＦの状態を前記スタックにプッシュすることを含み、前記ロジックが前記スタックから前記格納要素に少なくとも前記ＴＥＦの状態を戻すことは、ポップロジックが少なくとも前記ＴＥＦの状態を前記スタックからポップして前記ＴＥＦを前記格納要素に戻すことを含む項目１１７に記載の装置。
（項目１２２）
実行されるとリングレベル遷移イベントを発生させるコードを保持するメモリと、
レジスタおよびスタックロジックを有するプロセッサと
を備え、
前記レジスタは、対応付けられているトランザクションがアクティブである旨を示すアクティブ値を保持するためのトランザクションイネーブルフィールド（ＴＥＦ）を含み、
前記スタックロジックは、前記リングレベル遷移イベントに応じて前記レジスタの以前の状態をスタックにプッシュして、前記ＴＥＦを非アクティブ値にクリアして前記対応付けられているトランザクションが一時停止している旨を示し、リターンイベントに応じて、前記スタックから前記レジスタに前記レジスタの前記以前の状態を戻すシステム。
（項目１２３）
前記リングレベル遷移イベントは、割り込み、例外、システム呼び出し、仮想マシン開始、および、仮想マシン終了から成る群から選択されるイベントを含む項目１２２に記載のシステム。
（項目１２４）
前記リターンイベントは、割り込みリターン（ＩＲＥＴ）、システムリターン（ＳＹＳＲＥＴ）、仮想マシン（ＶＭ）開始、および、仮想マシン（ＶＭ）終了から成る群から選択されるイベントを含む項目１２２に記載のシステム。
（項目１２５）
前記レジスタはフラグレジスタを含み、前記ＴＥＦはトランザクションイネーブルフラグを含み、前記アクティブ値は前記トランザクションイネーブルフラグの論理Ｈｉｇｈ値を含み、前記非アクティブ値は前記トランザクションイネーブルフラグの論理Ｌｏｗ値を含む項目１２２に記載のシステム。
（項目１２６）
現在のリングレベルからのリングレベル遷移イベントを検出する段階と、
トランザクションイネーブルフィールドを含むレジスタの以前の状態を格納構造に保存する段階と、
前記トランザクションイネーブルフィールドをクリアして対応付けられているトランザクションが一時停止している旨を示す段階と、
前記現在のリングレベルへのリターンイベントを検出する段階と、
前記現在のリングレベルへの前記リターンイベントを検出する段階に応じて、前記格納構造から前記レジスタの前記以前の状態を戻す段階と
を備える方法。
（項目１２７）
前記格納構造はカーネルスタックを含み、前記レジスタの前記以前の状態を前記カーネルスタックに保存する段階は、前記レジスタの前記以前の状態を前記カーネルスタックにプッシュする段階を有し、前記カーネルスタックから前記レジスタの前記以前の状態を戻す段階は、前記カーネルスタックから前記レジスタの前記以前の状態をポップして、前記以前の状態を前記レジスタに戻す段階を有する項目１２６に記載の方法。
（項目１２８）
前記現在のリングレベルは、ユーザリングレベルを含む項目１２６に記載の方法。
（項目１２９）
前記リングレベル遷移イベントは、割り込み、例外、システム呼び出し、および、仮想マシン開始から成る群から選択されるイベントを含む項目１２８に記載の方法。
（項目１３０）
前記現在の特権レベルへの前記リターンイベントは、割り込みリターン（ＩＲＥＴ）、システムリターン（ＳＹＳＲＥＴ）、および、仮想マシン（ＶＭ）終了から成る群から選択されるイベントを含む項目１２９に記載の方法。

Claims (6)

1. キャッシュエントリを保持するデータキャッシュアレイと、
   前記データキャッシュアレイに結合されているキャッシュ制御ロジックと
   を備え、
   前記キャッシュ制御ロジックは、
   前記キャッシュエントリに対するバッファ済み更新に応じて、前記キャッシュエントリを、監視されていない状態からバッファ済みコヒーレンシ状態および読出監視状態へと遷移させて、
   その後に、前記バッファ済み更新をコミットするために前記キャッシュエントリを修正済み状態に遷移させる前に、前記キャッシュエントリを、バッファ済みコヒーレンシ状態および書込監視状態に遷移させ、
   前記バッファ済み更新は、命令の実行に応じて生成され、ローカルスレッドには利用可能であるが、グローバルには可視化されない
   装置。
2. 前記キャッシュエントリに対する前記バッファ済み更新は、前記キャッシュエントリに保持されるデータアイテムのデータアドレスに対するトランザクショナルメモリアクセス、前記キャッシュエントリに保持されるメタデータに対応付けられているデータアドレスへのメタデータアクセス、および、前記キャッシュエントリへのローカル更新から成る群から選択される更新を含む請求項１に記載の装置。
3. 前記キャッシュ制御ロジックが、前記キャッシュエントリを、監視されてない状態からバッファ済みコヒーレンシ状態および読出監視状態へと遷移させることは、前記キャッシュ制御ロジックが前記キャッシュエントリに対応付けられているコヒーレンシビットをバッファ済み値に更新して前記バッファ済みコヒーレンシ状態を表し、前記キャッシュエントリに対応付けられている読出監視属性ビットを読出監視値に更新して前記読出監視状態を表すことを含む請求項１に記載の装置。
4. 前記キャッシュ制御ロジックが、前記バッファ済み更新をコミットするために前記キャッシュエントリを修正済み状態に遷移させる前に、前記キャッシュエントリを、バッファ済みコヒーレンシ状態および書込監視状態に遷移させることは、前記キャッシュ制御ロジックが、前記キャッシュエントリに対応付けられている前記コヒーレンシビットの前記バッファ済み値を維持して前記バッファ済みコヒーレンシ状態を表し、前記キャッシュエントリに対応付けられている書込監視属性ビットを書込監視値に更新して前記書込監視状態を表すことを含む請求項３に記載の装置。
5. 前記キャッシュ制御ロジックが前記キャッシュエントリを前記修正済み状態に遷移させることは、前記キャッシュ制御ロジックが、前記キャッシュエントリに対応付けられている前記コヒーレンシビットを更新して前記修正済みコヒーレンシ状態を表すことを含む請求項４に記載の装置。
6. 前記バッファ済み更新を実行した後にコミット処理を実行する実行ロジックをさらに備え、
   前記キャッシュ制御ロジックが、前記バッファ済み更新をコミットするために前記キャッシュエントリを修正済み状態に遷移させる前に、前記キャッシュエントリをバッファ済みコヒーレンシ状態および書込監視状態に遷移させることは、前記実行ロジックが前記コミット処理を実行することに応じて行なう請求項１に記載の装置。

Images