JP2012514254A - トランザクショナルメモリシステム内でのハードウェア属性のメモリモデル - Google Patents

Abstract

【解決手段】 ハードウェア属性がトランザクション実行をサポートするためのメモリモデルを提供する方法および装置を説明する。読出監視属性、書込監視属性、または、バッファリング属性をロードする監視試験処理等、ハードウェア属性のロードが発生すると、ハードウェア属性が失われたことを損失フィールドが示している場合には、エラーが発行される。また、アドレスの依存関係およびアクセスの種類の依存関係に基づき、属性アクセス処理についてはブロックおよび転送等の依存関係処理が行なわれる。この結果、メモリモデルでは、属性が失われている場合、および、属性を試験する場合には、別の処理が可能となり、制限される。
【選択図】 図１

Description

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

半導体加工およびロジック設計の技術革新が進むにしたがって、集積回路装置に設けるロジックの量を増加させることが可能となった。この結果、コンピュータシステム構成は、１つのシステム内に１または複数の集積回路を含む構成から各集積回路に複数のコアおよび複数の論理プロセッサを設ける構成へと進化した。プロセッサまたは集積回路は通常、１つのプロセッサダイで構成され、プロセッサダイは任意の数のコアまたは論理プロセッサを含むとしてよい。

集積回路に設けられるコアおよび論理プロセッサの数が増加の一途を辿ることによって、同時により多くのソフトウェアスレッドを実行できるようになっている。しかし、同時に実行されるソフトウェアスレッドの数が多くなることによって、複数のソフトウェアスレッド間で共有されるデータの同期化について問題が生じている。マルチコアシステムまたはマルチ論理プロセッサシステムにおいて共有データへのアクセスを可能とする一般的な解決方法の１つとして、共有データへの複数のアクセスの間で相互排除を確実に行なうためにロックを利用する方法がある。しかし、複数のソフトウェアスレッドを実行する機能が高度化する一方であるので、誤って競合する危険性および実行が逐次化されてしまう危険性がある。

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

別の最新のデータ同期化技術を挙げると、トランザクショナルメモリ（ＴＭ）を利用する方法がある。トランザクション実行では、一群を成す複数のマイクロ演算、複数の演算、または複数の命令を実行することが多い。上記の例では、両方のスレッドがいずれもハッシュテーブル内で実行されており、メモリアクセスは監視／追跡されている。どちらのスレッドも同じエントリに対してアクセス／変更を行なう場合、データの有効性を保証するべくコンフリクト解決方法を実行するとしてよい。トランザクションを実行する方法の１つとして、ソフトウェアトランザクショナルメモリ（ＳＴＭ）がある。ＳＴＭでは、メモリアクセスの追跡、コンフリクト解決、アボートタスク、およびその他のトランザクションタスクを、多くの場合にはハードウェアのサポート無しに、ソフトウェアで実行する。

トランザクションを実行する別の方法として、ハードウェアトランザクショナルメモリ（ＨＴＭ）システムがある。ＨＴＭシステムでは、アクセス追跡、コンフリクト解決、および、その他のトランザクションタスクをサポートするべくハードウェアが含まれている。一例として、トランザクション実行のためのバッファリング、書込動作の監視、および、読出動作の監視をサポートするべくハードウェア属性が含まれているとしてよい。しかし、現在のメモリオーダリング（メモリ順序性）の実施例に応じたハードウェア属性を設定および読み出すための命令を利用すると、オーダリング違反が発生する場合がある。また、ハードウェア属性の保持方法が不可逆的である場合、つまり、強制排除（ｅｖｉｃｔｉｏｎ）／書き換え時に失われてしまう場合、監視読出命令／監視試験命令が得る監視データは間違っている場合がある。

添付図面において本発明の例を図示するが、添付図面は本発明を限定するものではない。
複数のソフトウェアスレッドを同時に実行可能な複数の処理素子を備えるプロセッサの実施形態を示す図である。 ハードウェア属性に対するアクセスについてのメモリオーダリング（メモリ順序性）をサポートする構造を備えるプロセッサの実施形態を示す図である。 ハードウェア属性に対するアクセスについてのメモリオーダリング（メモリ順序性）をサポートする構造を備えるプロセッサの別の実施形態を示す図である。 ハードウェア属性に対するアクセスについてのメモリオーダリング（メモリ順序性）をサポートする構造を備えるプロセッサの別の実施形態を示す図である。 ハードウェア属性を読み出す際に適切なメモリオーダリングを行うための方法の実施形態を示すフローチャートである。

以下に記載する説明では、本発明を深く理解していただくべく、トランザクション実行のためのハードウェア構造の具体例、アクセス監視の種類および実施例の具体例、キャッシュの実施例の具体例、キャッシュコヒーレンシモデルの種類の具体例、データ粒度の具体例、属性の種類の具体例、および、依存性を検出するための構造の具体例等、具体的且つ詳細な内容を数多く記載する。しかし、本発明を実施する際に以下に記載する具体的且つ詳細な内容を必ずしも利用する必要はないことは当業者には明らかである。また、ハードウェア監視／属性の実施例の詳細な内容、トランザクションの画定、具体的且つ別のマルチコア型およびマルチスレッド型のプロセッサアーキテクチャ、具体的なコンパイル方法／実施例、および、具体的且つ詳細なマイクロプロセッサの動作等、公知の構成要素または方法は、本発明を不要にあいまいにすることを避けるべく、詳細な説明を省略している。

本明細書に記載する方法および装置は、トランザクションの実行をサポートするためのハードウェア属性のメモリモデルを提供する。具体的には、アクセスバッファを持つアウトオブオーダ・プロセッサを参照しつつメモリモデルを説明する。実際には、図２から図４は、格納バッファ等のバッファを変形した実施形態に関する図である。しかし、ハードウェア属性のメモリモデルを提供する方法および装置は、任意の形式のプロセッサ、例えば、ハードウェア属性に対するアクセスを処理する任意の構造において実施され得るので、これらに限定されるものではない。

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

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

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

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

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

プロセッサ１００は通常、上記以外にも完全に共有化されるリソース、パーティション化によって共有されるリソース、または、特定の処理素子専用のリソースも備える。図１に示すプロセッサの実施形態は完全に一例でしかなく、プロセッサの機能ユニット／リソースも一例である。尚、プロセッサは上述した機能ユニットのうちいずれを備えるとしてもよいし、いずれを省略するとしてもよく、図示していない任意のその他の公知の機能ユニット、ロジック、または、ファームウェアを含むとしてもよい。

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

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

一例によると、割り当て名称変更ブロック１３０は、命令処理結果を格納するレジスタファイル等のリソースを確保する割り当て部を有する。しかし、スレッド１０１ａおよび１０１ｂはアウトオブオーダ実行が可能であり、この場合、割り当て名称変更ブロック１３０はさらに、命令結果を追跡するためのリオーダバッファ等の他のリソースを確保する。ユニット１３０はさらに、プログラム／命令参照レジスタをプロセッサ１００内の他のレジスタへと名称変更するレジスタ名称変更部を含むとしてよい。リオーダ／退避ユニット１３５は、上述したリオーダバッファ、ロードバッファ、および、格納バッファ等の素子を含み、アウトオブオーダ実行をサポートすると共に、アウトオブオーダで実行された命令を後で順序正しく退避させる。

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

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

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

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

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

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

コンパイラは通常、ソーステキスト／ソースコードをターゲットテキスト／ターゲットコードに変換するプログラムまたはプログラム群を持つ。大抵の場合、コンパイラによるプログラム／アプリケーションコードのコンパイルは、複数の段階で実行され、高級プログラミング言語のコードを低級の機械言語またはアセンブリ言語のコードに変換する。しかし、コンパイルが単純な場合にはワンパスコンパイラを依然として利用するとしてよい。コンパイラは、任意の公知のコンパイル技術を利用して任意の公知のコンパイル動作を実行するとしてよい。例えば、字句解析、事前処理、構文解析、意味解析、コード生成、コード変換、および、コード最適化等を実行するとしてよい。

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

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

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

データアイテムに対して、ローカル処理素子および他の処理素子の両方からアクセスおよび要求が為されるとしてよい。トランザクショナルメモリシステムに安全機構がなければ、このようなアクセスのうち一部は、無効なデータに対して為されて実行も無効化される可能性がある。つまり、データ書込によって読出が無効になったり、または、無効なデータの読出が行なわれたりする可能性がある。このため、プロセッサ１００は、コンフリクトの可能性があるか否かを特定するべく、データアイテムに対するメモリアクセスを追跡または監視するロジックを備えるとしてよい。

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

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

一実施形態によると、監視部は、監視対象と決定されたロードおよび格納を追跡する読出監視部および書込監視部を含む。一例を挙げると、ハードウェアの読出監視部および書込監視部は、基礎となる格納構造の粒度には関係なく、データアイテムの粒度でデータアイテムを監視する。一実施形態によると、データアイテムは、少なくともデータアイテム全体が適切に監視されるように、格納構造の粒度で対応付けられている追跡機構によって画定される。読出監視部／属性を利用してデータアイテムを監視する例は、同時係属中の出願第ＸＸ／ＸＸＸ，ＸＸＸ（代理人整理番号第Ｐ２９１３０、発明の名称：「トランザクショナルメモリ（ＴＭ）システムにおける読出および書込の監視属性」、発明者：ガド・シーファー（Ｇａｄ Ｓｈｅａｆｆｅｒ）他）により詳細に記載されている。しかし、監視部、属性、注釈、または、その他の追跡機構は、任意の粒度のデータまたはデータ保持構造を用いて、トランザクション実行に対応付けられるコンフリクトの検出に用いられるとしてもよい。

属性は、データアイテムに対応付けられている状態を保持する任意のロジック、ファームウェア、または、構造を含む。例えば、データアイテムの属性は、ビットベクトルを含む。ビットベクトル内の各ビットが、データアイテムの属性、例えば、トランザクション的にロードされたか、トランザクション的に書き込まれたか、非トランザクション的にロードされたか、非トランザクション的に書き込まれたか、トランザクション的にロードされていないか、トランザクション的に書き込まれていないか、非トランザクション的にロードされていないか、非トランザクション的に書き込まれていないか、バッファリングされているか、バッファリングされていないか、アクセスコンフリクトが検出されているか、アクセスコンフリクトが検出されていないか、読出要求か、読出要求でないか、書込要求か、書込要求でないか、所有権要求か、所有権要求でないか、または、データアイテムあるいはデータアイテムを保持するメモリ位置に対応付けられている任意のその他の属性あるいは状態を表す。別の例として、データアイテムの属性はエンコードされた値を含む。例えば、複数の状態、例えば、（１）読出が監視されている、（２）読出が監視されていない、（３）書込が監視されている、（４）書込が監視されていない、（５）バッファリングされている、（６）バッファリングされていない、という４つの状態が、３つの属性ビット、つまり、０００、００１、０１０、０１１、１００、１０１、１１０という６つのバイナリ値を用いてエンコードされている。

さらに別の例によると、属性は、データキャッシュ１５０等のキャッシュメモリに対応付けられているコヒーレンシ状態アレイの一部として含められる。キャッシュコヒーレンシ状態の例を列挙すると、全てを網羅するものではないが、読出監視属性、書込監視属性、バッファリング属性、別の属性またはこれらの組み合わせを補完または捕捉する、修正済状態、排他的状態、共有状態、または、無効（ＭＥＳＩ）状態がある。このため、新しいコヒーレンシ状態、例えば、読出監視バッファリングコヒーレンシ状態または書込監視バッファリングコヒーレンシ状態を作成する必要がある。したがって、従来から公知のコヒーレンシプロトコルおよび通信／スヌーププロトコルを、コンフリクトを検出するためのハードウェア監視部／属性と組み合わせて、利用するとしてよい。

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

一実施形態によると、アクセスコンフリクト、監視コンフリクトの損失、データコンフリクトの損失等のコンフリクトを効率的に処理するべく、ハードウェアにはハンドラが登録される。一例を挙げると、レジスタは、トランザクションハンドラのアドレスを登録するべく、例えば、トランザクションランタイムまたはアプリケーションコード等を、ソフトウェアによって変更可能である。上述したようなアクセスコンフリクトまたは情報の損失等、対象となるイベントが検出されると、一実施形態によれば、制御フローは、オペレーティングシステム（ＯＳ）等の特権ソフトウェアが介在することなく、レジスタに登録されているトランザクションハンドラへと導かれる。ハードウェアにハンドラを登録する方法は、関連出願（代理人整理番号：Ｐ２９１２９、発明の名称：「トランザクショナルメモリのイベントハンドリングのためにハードウェアにユーザハンドラを登録」、発明者：ガド・シーファー（Ｇａｄ Ｓｈｅａｆｆｅｒ）他に記載されている。

不可逆性データ、つまり、キャッシュから強制排除されると失われる情報として属性が保持されるとしても、または、強制排除に伴って書き戻されるデータの一部として属性が保持されるとしても、一実施形態によると、プロセッサ１００のアーキテクチャは、属性にアクセスするための命令、演算、または、マイクロ演算をサポートする。例えば、監視設定命令は、属性を特定値に設定する命令で、監視クリア命令は、属性をデフォルト値にクリアする命令で、属性試験命令は、属性を読み出す命令である。また、トランザクション的なロードおよびトランザクション的な格納といった特定の処理は、非明示的に、属性を設定するとしてよい。例えば、トランザクション的な格納は、非明示的に、データがバッファリングされる旨を示すようにバッファリング属性を設定すると共に、バッファリングされたデータが書込監視される旨を示すように書込監視属性を設定するとしてよい。

一実施形態によると、明示的アクセスまたは非明示的アクセスを含む、属性に対するアクセスを適切にオーダリングするメモリモデルが提供される。例えば、属性の第１のロードおよび第２のロードがアウトオブオーダで実行されると、不正なメモリオーダリングが可能となる場合がある。アウトオブオーダ実行プロセッサにおける擬似コードおよび予測結果を以下に説明する。
Ｓｅｔ＿ｍｏｎｉｔｏｒ［Ｍ］
Ｒ０＝ｔｅｓｔ＿ｍｏｎｉｔｏｒ［Ｍ］
Ｒ１＝ｔｅｓｔ＿ｍｏｎｉｔｏｒ［Ｍ］
１）Ｒ０＝ＴＲＵＥおよびＲ１＝ＦＡＬＳＥは許可
２）Ｒ０＝ＦＡＬＳＥおよびＲ１＝ＴＲＵＥは禁止
３）Ｒ０＝ＴＲＵＥおよびＲ１＝ＴＲＵＥは許可
４）Ｒ０＝ＦＡＬＳＥおよびＲ１＝ＦＡＬＳＥは許可

一実施形態によると、ケース１）、３）、および４）は許可されていることに留意されたい。しかし、ケース２）に関しては、アドレスＭに対応付けられている読出属性（Ｒ０）の第１の試験の前に、アドレスＭが読出監視されている旨を示すように読出監視が設定されていると仮定している。また、アドレスＭに対応付けられているキャッシュラインおよび読出監視が、読出属性の第２の試験（Ｒ１）の前に、強制排除されている。ここにおいて、第１の試験および第２の試験がアウトオブオーダで実行されると、第１の試験（Ｒ０）は強制排除のために読出監視は無しと返し（ＦＡＬＳＥ）、第２の試験が読出監視が有りと返す（ＴＲＵＥ）場合がある。このケースは、一実施形態によると、不正なケースであり、アウトオブオーダで実行されたプログラム順序の試験処理間で矛盾が生じる可能性がある。

このため、一実施形態によると、キャッシュセット、キャッシュライン、キャッシュロケーション、または、キャッシュエントリ等のキャッシュ素子は、損失フィールドと対応付けられている。一例を挙げると、損失フィールドは、データキャッシュの一部に含められ、強制排除時に情報が失われないようにする。ここにおいて、損失フィールドが損失値に設定されていて、属性情報が失われており誤りである可能性がある旨を示している場合には、次のロード処理等の後続アクセスが為された際に一貫性が得られる。上述した例を再度用いて説明する。上述したように、第２の試験処理（Ｒ１）が最初に実行された後に、強制排除によって読出属性が失われた結果、損失フィールドが損失値に設定される。損失フィールドが設定された状態で、第１の試験処理（Ｒ０）が続いてアウトオブオーダで実行されると、コンフリクトが検出される。一例を挙げると、この場合にはＲ０はエラーとなる。エラーに応じて、メモリモデルが壊れないようにするべく、どちらの処理も再開される。つまり、上記のうちケース２）は禁止である。

従前のプロセッサアーキテクチャでは、属性情報が失われることに加えて、ほかにもメモリの一貫性に違反する事象が発生する可能性がある。例えば、外部アクセスに関して属性アクセス命令／処理に起因して発生する非一貫性が挙げられる。一例を挙げると、アドレスＡのロード処理の前に、アドレスＡに対応付けられている読出監視設定処理を実行すると仮定する。尚、読出監視のバッファリングがイネーブルされている場合、読出監視設定処理は、リタイアした後、ロード処理がリタイアした後に読出監視を更新するとしてよい。ロード処理のリタイアと読出属性の実際の更新との間の時間は、脆弱性がある。

この時間において外部スヌープを受け取ると仮定して説明する。ここで、ローカル処理素子は、アドレスＡが読出監視されている旨を示すように読出属性が設定されていると考えているが、読出属性はまだマーキングされていないので、外部スヌープはアドレスＡが読出監視されていないものと考える。基本的に、読出監視／属性について一貫した見方はない。このため、一実施形態によると、スヌープに応じて、上記の読出監視設定処理等の格納処理等の先の格納がインフライトで、読出属性をマーキングしていないか否かを判断するべく、格納バッファに対してスヌープが行なわれる。例えば、格納バッファ内のエントリがヒットすれば、つまり、ハードウェア属性に対するインフライトな格納があれば、当該エントリからの属性情報の転送、および、読出属性の更新は禁止される。

属性アクセス命令と外部アクセスとの間で一貫性について問題が発生する可能性があることに加えて、属性アクセスをアウトオブオーダで実行する場合も一貫性に問題が発生する可能性がある。例えば、トランザクション的なロードが非明示的に読出監視を設定して、監視試験命令が続いて読出監視を試験して、処理がアウトオブオーダで実行される場合を考えられたい。この結果、監視試験命令は、処理実行タイミングに応じて、「監視あり」または「監視なし」という答えを返すとしてよい。この問題を緩和するべく数多くのメモリモデル実施例が利用されるとしてよい。

第１の例として、読出監視設定処理等の読出監視を設定する処理は、読出監視を設定する処理が読出監視を更新するまで、読出監視試験処理等の読出監視をロードする処理をブロック／禁止する。このため、上述した脆弱性の問題は、後続の試験処理が読出監視のマーキングが行なわれるまでブロックされるので、解決される。別の例を挙げると、監視されている情報は監視を設定する命令から、当該監視を試験する命令へと転送される。また、読出監視のバッファリングを、実際に読出監視をバッファリングすることなく、エミュレーションするとしてよい。

転送または実行をブロックするためには、格納バッファおよび／またはロードバッファを含むメモリオーダバッファが生成側の処理と消費側の処理との間の依存関係を検出する。しかし、依存関係は、アドレスの依存関係だけに応じて決まるのではなく、アクセス種類の依存関係、つまり、生成側アクセスという属性種類および消費側アクセスという属性種類に応じても決まり得る。以下に示す表１に、属性アクセス命令間での依存関係の一例を示す。

尚、上記の表は、命令／処理およびその依存関係を全て網羅して列挙したものではない。表１では、「１」という値は依存関係が存在することを表し、上述したように、依存関係処理として転送またはブロックが行なわれるとしてよい。転送またはブロックをサポートする構造は、図３および図４を参照しつつ、後述する。依存関係が検出されると、生成側からの情報は転送されるべきか否か、または、生成側が当該情報で属性を更新するまで消費側はブロックされるべきか否かが判断される。

最初に図１を参照して上述したように、プロセッサ１００のアーキテクチャは説明のために例示的に挙げられているに過ぎない。同様に、さまざまな粒度のデータ項目に対してハードウェア監視／属性を対応付ける方法はどのような方法を用いるとしてもよいので、属性とデータ項目／要素とを対応付ける具体例もまた例に過ぎない。

図２は、トランザクション実行のためのハードウェア属性をサポートするメモリモデルを実装する構造を備えるプロセッサの実施形態を示す図である。プロセッサ２５０は、トランザクション実行が可能な処理素子を任意の数有する任意の種類の公知のプロセッサを含む。図示していないが、プロセッサ２５０は、ほかのシステム構成要素に結合されているとしてよい。例えば、チップセット、つまり、メモリコントローラハブおよび入出力（Ｉ／Ｏ）コントローラハブ、ならびに、システムメモリに結合されているとしてよい。コンピュータシステムが備えるＩ／Ｏデバイスの一般的な例としては、ネットワークコントローラ、ビデオディスプレイアダプタ、グラフィクスプロセッサ、オーディオコントローラ、または、その他の入出力デバイスが挙げられる。

一実施形態によると、プロセッサ２５０はキャッシュメモリを備える。キャッシュの最も一般的な例としては、図１に示すように、第１レベルキャッシュまたは第２レベルキャッシュ等のデータキャッシュが挙げられる。しかし、キャッシュはさらに、命令キャッシュ、トレースキャッシュ、または、その他の公知のキャッシュを含むとしてもよい。キャッシュアーキテクチャについては本発明の説明を不要にあいまいにすることを避けるべく詳細な説明を省略するが、キャッシュの編成方法には数多くの方法があるとしてよい。例えば、キャッシュは、メモリアドレスをキャッシュ内のいずれの箇所でも保持するフルアソシアティブ型、または、所定範囲のメモリアドレスはキャッシュのうち特定セットに制限されるセットアソシアティブ型、または、キャッシュ内の１つの箇所に複数のアドレスが保持されるダイレクトマップ型であってもよい。尚、本明細書で説明する方法および装置は、任意のキャッシュ編成を用いて実現するとしてもよい。

図示しているように、キャッシュは、キャッシュメモリまたはデータアレイとも呼ばれるデータ部分２０５と、キャッシュメモリ２０５と対応付けられている制御ロジック２３０とを有する。キャッシュメモリ２０５は、素子２１０、２１５、２２０および２２５を含む。「キャッシュ素子」という用語は、本明細書で用いる場合、キャッシュの構造素子のうち任意の粒度のものを意味し、例えば、キャッシュライン、キャッシュエントリ、キャッシュロケーション、または、キャッシュセットを意味する。例えば、素子２１０は、セットアソシアティブ型キャッシュの場合に複数のラインから構成されるキャッシュセットを含むとしてよい。これとは対照的に、別の実施形態では、素子２１０は、同様にアレイ２３５に対応付けられている一のセットが含む複数のエントリのうちの一のエントリを含む。

制御ロジック２３０は、それぞれキャッシュ素子２１０、２１５、２２０、および２２５に対応付けられている／対応しているエントリ２１１、２１６、２２１、および２２６から構成されるアレイ２３５を含む。また、ハードウェアの読出属性、書込属性、および、バッファリング属性２１１ｒ、２１１ｗ、２１１ｂ、２１６ｒ、２１６ｗ、２１６ｂ、２２１ｒ、２２１ｗ、２２１ｂ、２２６ｒ、２２６ｗおよび２２６ｂも同様に、キャッシュ素子２１０、２１５、２２０および２２５に対応付けられている。ハードウェア監視部およびそのさまざまな実施形態は同時係属出願（代理人整理番号：Ｐ２９１３０、発明の名称：「トランザクショナルメモリ（ＴＭ）システムにおける読出監視属性および書込監視属性」、発明者：ガド・シーファー（Ｇａｄ Ｓｈｅａｆｆｅｒ）他）でより詳細に説明されているが、本明細書でも簡単に属性の実施形態について説明する。

一実施形態によると、読出監視部および書込監視部は、データを保持する物理的構造の粒度に関わらず、データアイテム２０１等のデータの監視を画定する。上記の記載から、データアイテムは任意の粒度であるとしてよいことに留意されたい。実際のところ、プログラマは、開始アドレスおよびデータアイテムを構成する追加バイト数を指定することによって、データアイテムを定義するとしてよい。ここで、要素２１０は、キャッシュの１ラインを含むものと仮定する。この結果、データアイテムは、キャッシュ２０５のライン２１０等の１ライン、つまり、キャッシュ２０５の１キャッシュラインのサイズよりも小さいとしてもよいし、キャッシュ２０５の１キャッシュラインよりも大きいとしてもよい。同様に、キャッシュ２０５の１キャッシュラインの開始境界および終了境界とは位置合わせされていないとしてもよい。

図２に示す例では、データアイテム２０１の範囲は、１キャッシュラインにわたっている。上記の特許出願（代理人整理番号：Ｐ２９１３０）では監視属性の動的割り当てについて説明しているが、本例では、キャッシュ素子毎に、属性２１１ｒ、２１１ｗ、２１１ｂ、２１６ｒ、２１６ｗ、２１６ｂ、２２１ｒ、２２１ｗ、２２１ｂ、２２６ｒ、２２６ｗおよび２２６ｂが設けられている。このため、データアイテム２０１が読出監視される場合、読出監視２１１ｒが監視状態に更新されて、対応する素子２１１が読出監視される旨を示す。

一実施形態によると、属性２１１ｒ、２１１ｗ、２１１ｂ、２１６ｒ、２１６ｗ、２１６ｂ、２２１ｒ、２２１ｗ、２２１ｂ、２２６ｒ、２２６ｗおよび２２６ｂは不可逆性データと見なされる。多くの場合、「不可逆性データ」とは、キャッシュ素子２１０のうち少なくとも一部の強制排除、および、より高次のレベルのキャッシュへの書き戻し等のイベントが発生すると失われるローカルデータを意味する。一実施形態によると、アレイ２３５は、エントリ２１１、２１６、２２１、および２２６がそれぞれ、キャッシュ素子２１０、２１５、２２０、および２２５に対応するコヒーレンシ状態値を保持するコヒーレンシエントリであるコヒーレンシ状態アレイを含む。一般的なキャッシュコヒーレンシ状態には、ＭＥＳＩがある。つまり、変更（Ｍｏｄｉｆｉｅｄ）、排他（Ｅｘｃｌｕｓｉｖｅ）、共有（Ｓｈａｒｅｄ）、および、無効（Ｉｎｖａｌｉｄ）というキャッシュコヒーレンシ状態がある。しかし、図示した３つの属性ビットを追加すると基本的に、読出監視、書込監視、および、バッファリングに基づき新たにコヒーレンシ状態が作成されることになる。

このため、キャッシュ素子２１０が１つのキャッシュラインを含むと仮定すると、キャッシュライン２１０の強制排除に応じて、これに対応付けられた、属性２１１ｂ、２１１ｒ、および、２１１ｗを含むエントリ２１１を持つ状態情報が失われる。つまり、書き戻しは行なわれない。この結果、ローカル素子は属性が設定されていると考えているがその属性が失われている場合に、一貫性について問題が発生し得る。ここで、一貫性に関する問題は、別の属性に対するアクセスまたは外部アクセスの場合にも、適切な情報が失われているので、発生し得る。

このため、一実施形態によると、要素２１０、２１５、２２０、および２２５のそれぞれには、損失フィールド２１２、２１７、２２２、および、２２７が対応付けられている。図示しているように、損失フィールド２１２、２１７、２２２、および２２７は、要素２１０、２１５、２２０、および２２５内に含められる。しかし、損失フィールドは、強制排除が実行されても失われない箇所であればどこに保持するとしてもよい。例えば、損失フィールド２１２は、ライン２１０の強制排除が実行されても失われないデータキャッシュ構造、または、記録が容易でキャッシュライン２１０に対応付けられ得るデータキャッシュ構造に含められるとしてもよい。

制御ロジック２３０は通常、スヌープロジック、置換ロジック、状態ロジック、および、任意の公知のキャッシュ処理を実行するその他のキャッシュ関連ロジックを含む。一実施形態によると、制御ロジック２３０は、単独またはプロセッサ２５０内のほかのロジックと共同で、対応付けられている不可逆性データが失われると判断すると、損失フィールドを損失値に更新する。例えば、不可逆性データがコヒーレンシエントリ２１１内の属性２１１ｂ、２１１ｒ、および、２１１ｗを含むと仮定する。ここにおいて、制御ロジック２３０は、２１１ｂ等の属性が設定されておりキャッシュ素子２１０が強制排除の対象として選択されると、損失フィールド２１２を更新する。一実施形態によると、失うデータがない場合、つまり、不可逆性データが存在しない場合、例えば、属性２１１ｂ、２１１ｒ、および、２１１ｗが設定されていない場合、強制排除が行なわれても損失フィールド２１２は設定されないことに留意されたい。言い換えると、失うデータがない場合には損失を指し示す理由がない。

一実施形態によると、上述したように、損失に対処するハンドラが呼び出されるとしてよい。しかし、別の実施形態によると、後続のアクセスが為されると一貫性が確保される。例えば、トランザクション的なロードが行なわれた結果、属性２１１ｒが設定されて読出監視を示し、その後にライン２１０が強制排除の対象として選択されると仮定する。この場合、制御ロジック２３０は損失フィールド２１２を損失値に設定する。ここにおいて、強制排除後にエントリ２１０のアドレスが変わるので、一種のアドレスハッシングが用いられるとしてよい。強制排除前は、ライン２１０のタグ等の不可逆性データは別個に格納されているか、または、フルアソシアティブ型でないキャッシュアレイにおける設定ビット等、強制排除されるラインと新しく割り当てられるラインとで同じ情報を損失フィールド２１２に用いる。従来は、損失フィールド２１２が無く、監視試験処理等のロードが続いて行なわれると、２１１ｂから不正確な監視情報を受け取ってしまっていた。これは、強制排除によって監視情報が失われるためである。これに代えて、一実施形態によると、読出監視試験処理が続いて行なわれると、フィールド２１２に保持されている損失値に応じて、エラーとなる。このため、次のアクセス処理において一貫性が確保される。

図３は、ハードウェア属性に対するアクセスについてのメモリオーダリングをサポートする構造を備えるプロセッサの実施形態を示す図である。図示の便宜上、プロセッサのうち幾つかの構造のみを選択して図示していることに留意されたい。一実施形態によると、プロセッサ３０５は、適切な依存関係処理が実行されるように、ハードウェア属性に対する格納処理と、ハードウェア属性に対する後続のロード処理との間に依存関係があるか否かを判断するロジックを備える。

一例を挙げると、生成側処理と消費側処理との間の依存関係の判断は、属性アクセスの種類に応じて為される。上述したように、属性の例としては、読出監視属性、書込監視属性、および、バッファリング属性がある。ここにおいて、対応するアクセスの種類には、読出監視アクセス、書込監視アクセス、および、バッファリングアクセスがある。従来は、蓄積転送はアドレスの依存関係にのみ基づき実現されていた。

しかし、一実施形態によると、生成側処理および消費側処理のアクセスの種類、ならびに、生成側処理および消費側処理のアドレスを組み合わせて用いて、依存関係を判断する。表１を参照しつつ上述したように、同じアドレスに対するアクセス同士でも、種類が異なれば、依存関係は無いとしてよい。この結果、一実施形態によると、書込監視設定アクセスと読出監視試験アクセスとの間には依存関係はない。

処理がどの種類のアクセスかに基づき依存関係を判断する一実施形態を図３に図示している。ここにおいて、メモリオーダバッファは、特に図示していないが、格納バッファ３１０およびロードバッファ３５０を含むものである。どちらのバッファも、対応する処理に対応付けられているエントリを保持するバッファである。図示されているように、エントリ３２５は、属性データ３２６を格納するための、属性アクセスの種類３２７を持ち、アドレス３２８を参照する格納処理と対応付けられる。格納バッファは２つの別個のアレイ、つまり、格納データバッファ３２０および格納アドレスバッファ３１５を持つものとして例示的に図示されているが、格納バッファは任意の公知の実施例を利用するとしてよい。

基本的に、格納バッファロジック３１０は、格納処理に対応付けられている属性アクセスの種類３２７を、格納バッファのエントリ３２５の格納アドレスバッファ３１５内に、保持する。ロードバッファ３５０も、ロード処理に関して、同様に動作する。図示されているように、エントリ３５５は、データエントリ３５６、および、アクセスの種類３５７が対応付けられているアドレス３５８を保持している。説明のために、エントリ３２５が、先行するインフライトの読出監視設定処理等の格納処理に対応付けられており、読出監視属性等のハードウェア属性を更新後の属性情報３２６で更新すると仮定する。この後、ロード処理が発生する。ここにおいて、バッファエントリ３５５は、この後続のロード処理に対応付けられている。

依存関係／ブロック実行ロジック３６０は、後続のロード処理のアクセスの種類３５７およびアドレス３５８と、先行する格納処理のアクセスの種類３２７およびアドレス３２８とを比較する。一実施形態によると、この比較は、検索によって実行する。つまり、アクセスの種類３５７をアドレス３５８に付加して、格納アドレスバッファ３１５を検索する。付加して生成された検索基準全てが格納バッファ３１０内のエントリでヒットすれば、依存関係が存在する。ここにおいて、アクセスの種類３５７をアドレス３５８に付加して得られた組み合わせがアクセスの種類３３７をアドレス３３８に付加して得られた組み合わせと一致すれば、格納処理とその後続のロード処理との間には依存関係があると判断される。

言い換えると、アクセスの種類、つまり、読出監視アクセス、書込監視アクセス、または、バッファアクセスが一致して、アドレスが一致するので、生成側の格納処理と後続の消費側のロード処理との間に依存関係が存在するのである。一実施形態によると、「後続」とはプログラム順序を意味し、格納バッファ３１０の検索は、対象となるロードバッファのエントリよりプログラム順序で前の格納バッファのエントリに対してのみ行なうことに留意されたい。

また、転送ロジック３７０は、依存関係／ブロック実行ロジック３６０と結合されており、単独または依存関係／ブロック実行ロジックと共同で依存関係処理を行なう。一実施形態によると、依存関係処理は、ブロック処理を含む。一例を挙げると、読出監視は転送されないとしてよい。このため、アクセスの種類が読出監視アクセスを含むと共に依存関係が検出されると、後続のロード処理は、エントリ３２５に対応付けられている格納処理がアドレス３２８の適切な読出監視を更新後の属性情報３２６に更新するまで、ブロックされる。一例として、ブロック実行ロジック３６０は、ロードバッファエントリ３５５内のブロックフィールドをブロック値に更新するロジックを含む。エントリ３５５のブロックフィールドがブロック値を保持している場合には、ブロック値がクリアされるまではロードを回さない。

これとは対照的に、別の依存関係処理には、監視データ転送処理が含まれる。ここにおいて、依存関係ロジック３６０によって依存関係があると判断されると、ロジック３７０は更新後のデータ３２６をロード処理に転送する。しかし、依存関係ロジック３６０が依存関係は無いと判断すると、依存関係処理は実行されない。しかし、監視データの転送が許可されている場合、一実施形態によると、スヌープロジックが外部アクセス要求に応じて格納バッファ３１０をスヌープする。ここにおいて、外部アクセス要求に応じて行なわれたスヌープがヒットした場合、例えば、エントリ３２５でヒットすると、転送ロジック３７０は更新後の属性データ３２６を転送しない。また、監視設定処理等の格納処理は、外部スヌープがヒットすると、対応する監視を更新することは禁止されるとしてよい。

図４は、属性アクセス処理間の依存関係を判断する別の実施形態を説明するための図である。尚、図３では、明示的な属性アクセスの種類、例えば、オプコードを検討することによって特定される種類が格納エントリと対応付けられている。アクセスの種類は基本的にアドレスの拡張部分である。例えば、２ビットの拡張部分が上述した３つの状態を表す。さらに、依存関係を確認する際には、アドレスの一部として２ビットの拡張部分の検索／比較も行なわれる。

これとは対照的に、一実施形態によると、アクセスの種類に基づく依存関係の確認は非明示的に行なわれる。図示されているように、プロセッサ４０５は、図３に示すプロセッサ３０５と同様の構造を持つ。しかし、格納バッファ３２０のエントリの１つの位置に、読出監視属性情報、書込監視属性情報、または、バッファリング属性情報をまとめて更新後の属性情報として保持することに代えて、位置４３１、４３２、および、４３３に属性情報が保持されている。このため、従来のアドレス依存関係確認処理は、属性情報の位置の確認をさらに行なうとしてよい。

説明のために、属性情報位置４３１は読出監視情報を保持する位置であり、属性情報位置４３２は書込監視情報を保持する位置であり、属性情報位置４３３はバッファリング属性情報を保持する位置であると仮定する。ロードが発生すると、従来のアドレス依存関係確認処理が実行される。つまり、アドレス４５８を用いて格納アドレスバッファ４１５内を検索する。エントリ４２５でヒットすると、つまり、アドレス４５８およびアドレス４２８が一致すると、格納バッファ４２０内で保持されているデータの位置に基づきアクセスの種類を比較する。一実施形態によると、アクセスの種類の比較は、アドレスが一致するか否かの確認と並行して実行されるとしてよい。ここでさらに、バッファリング属性設定処理がエントリ４２５に対応付けられていると仮定される。この場合、アドレス４２８に対応付けられているバッファリング属性の更新後の属性情報は位置４３３、例えば、最下位から３つ目のビットに保持されている。

後続のロード処理、例えば、書込監視試験処理の際、依存関係ロジック４６０がアドレスを比較する。書込監視試験処理は種類が書込監視アクセスであり、バッファエントリ４２５はバッファリングアクセスを示す位置４３３に更新情報を保持しているので、依存関係の一致はない。しかし、後続のロード処理がバッファリング属性試験処理でアドレスが一致する場合、格納データバッファエントリ４２５内の情報の位置に基づいて決まるアクセスの種類が一致し、依存関係が存在すると判断される。依存関係が存在する、または、存在しないと判断されると、転送／ブロック実行ロジック４７０は、図３を参照して上述したのと同様の処理を実行する。

図５は、ハードウェア（ＨＷ）属性の読出、ロード、または試験の際に適切なメモリオーダリングを実現する方法の実施形態を説明するためのフローチャートである。図５のフローチャートでは、各ステップは略シリアルに図示されていることに留意されたい。しかし、同図を参照しつつ説明する方法は、順次実行することに限定されるものではなく、任意の順序で行なわれ、少なくとも一部のステップが並行に行なわれるとしてよい。

ステップ５０５では、ハードウェア属性を読み出すロード処理が発生する。ロード処理の例には、ほかの処理／マイクロ処理を実行するより大規模な命令の一部である監視試験命令、監視試験処理、または、監視試験マイクロ処理がある。一例を挙げると、ロード処理は、属性の種類に対応付けられており、ハードウェア属性に対応付けられているアドレスを参照する。上述したように、ハードウェア属性の例には、読出監視属性、書込監視属性、および、バッファリング属性がある。しかし、属性は、データまたはアドレスに対応付けられている状態を格納するとしてもよい。

ステップ５０６では、ハードウェア属性に対応付けられている損失フィールド、つまり、ハードウェア属性に対応付けられているロード処理が参照するアドレスが損失値に設定されているか否かを判断する。属性情報等の不可逆性データが失われたことを意味する損失値を損失フィールドが保持している場合、ステップ５０７において、適切なデータ一貫性を確保するべくこのロード処理についてエラーが開始される。

しかし、損失フィールドが損失値を保持していない場合、ステップ５１０に進む。ステップ５１０において、ロード処理と先行するインフライトの格納処理との間に依存関係があるか否かを判断する。格納処理の例としては、ハードウェア属性設定命令、ハードウェア属性設定処理、または、ハードウェア属性マイクロ設定処理がある。ステップ５１０はステップ５１１およびステップ５１２を含むことに留意されたい。本例では、依存関係の確認は両ステップで行なうものとする。

ステップ５１１では、ロード処理と先行するインフライトの格納処理との間でアドレスが一致するか否かを判断する。ステップ５１２では、ロード処理と先行するインフライトの格納処理との間でアクセスの種類が一致するか否かを判断する。一実施形態によると、これらのステップは、図３で説明したように、例えば、アクセスの種類がアドレスの拡張部分として保持される場合には、同時に実行される。この場合、属性の種類、つまり、アドレス拡張ビットをアドレスに付加したものを提示して、格納アドレスバッファを検索する。アドレスにアクセスの種類を付加した組み合わせがヒットすると、ロード処理と先行する格納処理はアドレスおよびアクセスの種類の両方が一致するので、依存関係が存在すると判断される。

図４で説明したように、格納データの位置に基づいてアクセスの種類が決まる等、設計ではアクセスの種類が非明示的である別の実施形態によると、ステップ５１１および５１２は別々に行なわれるとしてよい。この場合、ステップ５１１では、ロードが参照するアドレスに対応付けられている格納バッファエントリを格納バッファ内で検索する。ヒットすると、つまり、アドレスが一致すると、格納バッファのうちヒットした格納バッファエントリにおいて保持されている格納データの位置を特定する。例えば、最下位から３つ目のビット等と表される格納データの位置に基づき、格納の属性の種類、例えば、バッファリング、読出監視、または、書込監視かを決定する。決定された格納アクセスの種類がロードの種類と同じであれば、依存関係があると判断される。

いずれの場合も、依存関係が存在しない場合、ステップ５１５において、属性に関連した依存関係処理を実行することなく、通常通りロードを実行する。しかし、依存関係が検出されれば、ステップ５２０において、適切な依存関係処理を実行する。一実施形態によると、依存関係処理は、先行するインフライトの格納処理と対応付けられている格納データを転送することを含む。ここにおいて、先行する格納処理が、更新値で書込監視を更新する書込監視設定処理を含む場合、依存関係を持つ、書込監視値を読み出すための監視試験処理に更新値が転送される。

別の実施形態によると、依存関係処理は、先行するインフライトの格納処理によってハードウェア属性が更新されるまで、ロード処理をブロックすることを含む。説明のために、先行する格納処理が読出監視を更新値に更新する読出監視設定処理を含み、ロード処理が読出監視値をロードする読出監視試験処理を含むと仮定する。この場合、読出監視値をロードするロード処理は、読出監視設定処理が実際に読出監視を更新するまで、ブロックされる。いずれの場合も、つまり、転送またはブロックのいずれを行なう場合でも、本発明に係るメモリモデルによってデータ一貫性が維持される。

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

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

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

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

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

上記の説明では、具体的な実施形態例を参照しつつ詳細に説明している。しかし、特許請求の範囲に記載する本発明のより大きな意図および範囲から逸脱することなく、上記の具体的な実施形態例をさまざまな点で変形および変更し得ることは明らかである。したがって、本明細書および添付図面は、本発明を限定するものではなく例示するものと解釈されたい。また、上の説明では「実施形態」等の例示的な意味を持つ用語を用いているが、同じ実施形態または同じ例を必ずしも意味するものではなく、同じ実施形態の場合もあるが、別の識別可能な実施形態を意味するとしてもよい。

Claims (33)

1. 不可逆性データに対応付けられる予定のキャッシュ素子を有するデータキャッシュメモリと、
   前記キャッシュ素子に対応付けられている損失フィールドと、
   前記データキャッシュメモリおよび前記損失フィールドに結合されており、前記不可逆性データが失われる予定であると判断される場合に、損失値を保持するように前記損失フィールドを更新する制御ロジックと
   を備える装置。
2. 前記キャッシュ素子は、キャッシュセットを含む請求項１に記載の装置。
3. 前記キャッシュ素子に対応付けられている前記損失フィールドは、前記キャッシュセット用の前記データキャッシュメモリ内の損失ビットを有し、
   前記損失値を保持するように前記損失フィールドを前記制御ロジックが更新することは、第１の論理値の前記損失ビットを前記制御ロジックが更新することを含む請求項２に記載の装置。
4. 前記キャッシュ素子は、キャッシュセットのキャッシュエントリを含む請求項１に記載の装置。
5. 前記キャッシュ素子に対応付けられている前記損失フィールドは、前記キャッシュセット用の前記データキャッシュメモリ内の複数のビットを有し、
   前記複数のビットのうち１つのビットが前記キャッシュエントリに対応付けられる予定であり、
   前記損失値を保持するように前記損失フィールドを前記制御ロジックが更新することは、前記複数のビットのうち前記１つのビットを前記制御ロジックが第１の論理値に更新することを含む請求項４に記載の装置。
6. 前記不可逆性データに対応付けられる予定の前記キャッシュ素子は、前記キャッシュ素子に対応付けられている不可逆性のハードウェア属性を含む請求項１に記載の装置。
7. 前記不可逆性のハードウェア属性は、バッファリングされているハードウェア属性、前記データキャッシュメモリに対応付けられている状態アレイに保持されているハードウェア属性、および、前記データキャッシュメモリにおいて不可逆性のメタデータとして保持されているハードウェア属性から成る群から選択されるハードウェア属性を含む請求項６に記載の装置。
8. 前記不可逆性データが失われる予定であると判断される場合に、前記損失値を保持するように前記制御ロジックが前記損失フィールドを更新することは、前記制御ロジックが前記データ要素の少なくとも一部を強制排除の対象として選択する結果、前記キャッシュ素子に対応付けられている前記不可逆性データが失われることを含む請求項１に記載の装置。
9. 前記制御ロジックはさらに、前記損失フィールドが前記損失値を保持している場合に、前記キャッシュ素子から読み出すための後続のロード処理のエラーを開始する請求項１に記載の装置。
10. 属性に対応付けられているキャッシュ素子を有するキャッシュメモリと、
    前記キャッシュメモリに結合されており、前記属性を更新する格納処理に対応付けられている格納バッファエントリを保持する格納バッファと、
    前記格納バッファに対応付けられており、前記格納処理に応じて前記属性が更新されるまで、前記属性から読み出すための後続のロード処理をブロックする制御ロジックと
    を備える装置。
11. 前記キャッシュ素子は、前記キャッシュメモリのセット、前記キャッシュメモリのライン、および、前記キャッシュメモリのエントリから成る群から選択される請求項１０に記載の装置。
12. 前記属性に対応付けられている前記キャッシュ素子は、前記属性を保持しており前記キャッシュ素子に対応するコヒーレンシ状態エントリを有し、
    前記属性は、読出監視、書込監視、および、バッファリング監視から成る群から選択されるハードウェア監視を含む請求項１１に記載の装置。
13. 前記属性は、読出監視属性を含み、
    前記格納処理は、前記読出監視属性を更新するための読出監視属性設定命令を含む請求項１０に記載の装置。
14. 前記後続のロード処理は、前記読出監視属性を読み出す読出監視試験命令を含み、
    前記読出監視試験命令は、プログラム順序で、前記読出監視属性設定命令の後に位置する請求項１３に記載の装置。
15. 一のキャッシュメモリの一のキャッシュ素子に対応付けられている複数のハードウェア属性と、
    前記複数のハードウェア属性のうち少なくとも１つに対する格納処理と、前記複数のハードウェア属性のうち少なくとも１つに対する後続のロード処理との間に依存関係が存在するか否かを、少なくとも前記格納処理の第１の属性アクセスの種類および前記後続のロード処理の第２の属性アクセスの種類に基づいて判断するロジックと、
    前記ロジックに結合されており、前記格納処理と前記後続のロード処理との間に前記依存関係が存在すると判断される場合に、前記格納処理の更新済み属性データを前記後続のロード処理に転送する転送ロジックと
    を備える装置。
16. 前記格納処理と、前記後続のロード処理との間に依存関係が存在するか否かを、少なくとも前記格納処理の前記第１の属性アクセスの種類および前記後続のロード処理の前記第２の属性アクセスの種類に基づいて判断する前記ロジックは、前記格納処理に対応付けられている前記第１の属性アクセスの種類を保持する格納バッファロジックと、前記格納バッファロジックに結合されており、少なくとも前記第１の属性アクセスの種類および前記第２の属性アクセスの種類を比較する依存関係ロジックとを有する請求項１５に記載の装置。
17. 前記第１の属性アクセスの種類および前記第２の属性アクセスの種類はそれぞれ別個に、読出監視アクセス、書込監視アクセス、および、バッファリングアクセスから選択される請求項１６に記載の装置。
18. 前記格納処理に対応付けられている前記第１の属性アクセスの種類を保持する前記格納バッファロジックは、前記第１の属性アクセスの種類が付加されている前記格納処理に対応付けられている格納アドレスを保持する格納アドレスバッファロジックを含み、
    前記格納バッファロジックおよび前記転送ロジックに結合されている前記依存関係ロジックが少なくとも前記第１の属性アクセスの種類および前記第２の属性アクセスの種類を比較することは、前記依存関係ロジックが前記第１の属性アクセスの種類が付加されている前記格納アドレスと、前記第２の属性アクセスの種類が付加されている前記後続のロード処理に対応付けられているロードアドレスとを比較することを含む請求項１６に記載の装置。
19. 外部アクセス要求に応じて前記格納バッファロジックをスヌープするスヌープロジックをさらに備え、
    前記転送ロジックは、前記外部アクセス要求が前記格納アドレスを参照している場合に、前記更新済み属性データを転送しない請求項１８に記載の装置。
20. 前記依存関係ロジックはさらに、前記第１の属性アクセスの種類が付加されている前記格納アドレスが前記第２の属性アクセスの種類が付加されている前記ロードアドレスに一致する場合に、前記格納処理と前記後続のロード処理との間に前記依存関係が存在すると判断する請求項１８に記載の装置。
21. 前記依存関係ロジックはさらに、前記第１の属性アクセスの種類が付加されている前記格納アドレスが、前記第２の属性アクセスの種類が付加されている前記ロードアドレスに一致しない場合に、前記格納処理と前記後続のロード処理との間に前記依存関係が存在しないと判断し、
    前記転送ロジックは、前記依存関係ロジックが前記格納処理と前記後続のロード処理との間に前記依存関係が存在しないと判断する場合に、前記更新済みの属性データを転送しない請求項２０に記載の装置。
22. 前記格納処理と、前記後続のロード処理との間に前記依存関係が存在するか否かを、少なくとも前記格納処理の前記第１の属性アクセスの種類および前記後続のロード処理の前記第２の属性アクセスの種類に基づいて判断する前記ロジックは、前記格納処理に対応付けられている格納データバッファエントリにおける一の位置に前記更新済みの属性データを保持する格納データバッファロジックを有し、
    前記格納データバッファエントリにおける前記一の位置は、前記第１の属性アクセスの種類を表している請求項１５に記載の装置。
23. 前記格納処理と、前記後続のロード処理との間に前記依存関係が存在するか否かを、少なくとも前記格納処理の前記第１の属性アクセスの種類および前記後続のロード処理の前記第２の属性アクセスの種類に基づいて判断する前記ロジックはさらに、前記格納データバッファおよび前記転送ロジックに結合されており、前記格納処理に対応付けられている格納アドレスが前記後続のロード処理に対応付けられているロードアドレスに一致し、且つ、前記格納データバッファエントリ内に保持されている前記更新済みのデータの前記一の位置に基づいて決まる前記第１の属性アクセスの種類が前記第２の属性アクセスの種類と同じである場合に、前記格納処理と前記後続のロード処理との間に前記依存関係が存在すると判断する依存関係ロジックを有する請求項２２に記載の装置。
24. 前記依存関係ロジックは、前記格納処理に対応付けられている前記格納アドレスが前記後続のロード処理に対応付けられている前記ロードアドレスに一致しない場合、または、前記格納データバッファエントリに保持されている前記更新済み属性データの前記一の位置に基づいて決まる前記第１の属性アクセスの種類が前記第２の属性アクセスの種類と同じである場合に、前記格納処理と前記後続のロード処理との間に前記依存関係が存在しないと判断し、
    前記転送ロジックは、前記格納処理と前記後続のロード処理との間に前記依存関係が存在しないと前記依存関係ロジックが判断する場合に、前記更新済み属性データを転送しない請求項２３に記載の装置。
25. ハードウェア属性を読み出すための処理であり、属性の種類と対応付けられており、前記属性の種類のハードウェア属性に対応付けられているアドレスを参照するロード処理が発生する段階と、
    先行するインフライトの格納処理が、前記属性の種類と対応付けられているか否か、および、前記ハードウェア属性に対応付けられている前記アドレスを参照しているか否かを判断する段階と、
    前記先行するインフライトの格納処理が、前記属性の種類と対応付けられており、且つ、前記ハードウェア属性に対応付けられている前記アドレスを参照していると判断される場合に、依存関係処理を実行する段階と
    を備える方法。
26. 前記ロード処理は、ハードウェア属性試験処理を含み、
    前記先行するインフライトの格納処理は、ハードウェア属性設定処理を含む請求項２５に記載の方法。
27. 前記属性の種類は、読出監視属性、書込監視属性、および、バッファリング属性から成る群から選択される請求項２５に記載の方法。
28. 前記先行するインフライトの格納処理が、前記属性の種類と対応付けられているか否か、および、前記ハードウェア属性に対応付けられている前記アドレスを参照しているか否かを判断する段階は、前記属性の種類が付加されている前記アドレスについて格納アドレスバッファを検索し、前記属性の種類が付加されている前記アドレスを保持している前記格納アドレスバッファの格納アドレスバッファエントリが発見される場合に、前記先行するインフライトの格納処理が前記属性の種類に対応付けられており、且つ、前記ハードウェア属性に対応付けられている前記アドレスを参照していると判断する段階を有する請求項２５に記載の方法。
29. 前記先行するインフライトの格納処理が、前記属性の種類と対応付けられているか否か、および、前記ハードウェア属性に対応付けられている前記アドレスを参照しているか否かを判断する段階は、
    前記アドレスに対応付けられている格納バッファエントリを発見するべく格納バッファを検索する段階と、
    前記アドレスに対応付けられている前記格納バッファエントリが発見される場合に、前記格納バッファの格納バッファエントリに保持されている前記ハードウェア属性に対応付けられている格納データの位置を特定する段階と、
    前記格納バッファエントリに保持されている前記格納データの前記位置に基づき格納の属性の種類を特定する段階と、
    前記格納の属性の種類が前記ロード処理に対応付けられている前記属性の種類と同じであると判断される場合に、前記先行するインフライトの格納処理が、前記属性の種類と対応付けられており、且つ、前記ハードウェア属性に対応付けられている前記アドレスを参照していると判断する段階と
    を有する請求項２５に記載の方法。
30. 前記依存関係処理を実行する段階は、前記先行するインフライトの格納処理に対応付けられている格納データを転送する段階を有する請求項２５に記載の方法。
31. 前記依存関係処理を実行する段階は、前記先行するインフライトの格納処理によって前記ハードウェア属性が更新されるまで、前記ロード処理をブロックする段階を有する請求項２５に記載の方法。
32. 前記ハードウェア属性に対応付けられているキャッシュ位置の強制排除が発生した結果、前記ハードウェア属性が失われる場合に、前記ハードウェア属性に対応付けられている損失フィールドを損失値へと更新する段階をさらに備える請求項２５に記載の方法。
33. 前記ロード処理は、前記ハードウェア属性を読み出す前記ロード処理が発生し、前記損失フィールドが前記損失値を保持している場合に、エラーとなる請求項３２に記載の方法。

Images