JP2006500639A - 指定されたメモリアクセスが発生するまでスレッドの実行をサスペンドする方法及び装置 - Google Patents

Abstract

指定されたメモリアクセスが発生するまでスレッドの実行をサスペンドする技術。一実施例では、プロセッサは複数のスレッドを実行することができる複数の実行ユニットを有する。第１スレッドはモニタアドレスを指定する命令を有する。サスペンド論理は第１スレッドの実行をサスペンドし、モニタは指定されたモニタアドレスへのアクセスに応答して、第１スレッドを再開させる。

Description

発明の詳細な説明

［関連出願］
本出願は、以下すべてが本出願と同日に出願された出願整理番号第１０／０３９，７７７号「マルチスレッドプロセッサのスレッドの実行のサスペンド処理（Ｓｕｓｐｅｎｄｉｎｇ Ｅｘｅｃｕｔｉｏｎ ｏｆ ａ Ｔｈｒｅａｄ ｉｎ ａ Ｍｕｌｔｉ−ｔｈｒｅａｄｅｄ Ｐｒｏｃｅｓｓｏｒ）」、出願整理番号第１０／０３９，６５６号「特定のメモリアクセスの発生までスレッドの実行をサスペンドするコヒーレンシーテクニック（Ｃｏｈｅｒｅｎｃｙ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｓｕｓｐｅｎｄｉｎｇ Ｅｘｅｃｕｔｉｏｎ ｏｆ ａ Ｔｈｒｅａｄ Ｕｎｔｉｌ ａ Ｓｐｅｃｉｆｉｅｄ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ Ｏｃｃｕｒｓ）」、及び出願整理番号第１０／０３９，６５０号「特定のメモリアクセスの発生までスレッドの実行をサスペンドする命令シーケンス（Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｑｕｅｎｃｅｓ ｆｏｒ Ｓｕｓｐｅｎｄｉｎｇ Ｅｘｅｃｕｔｉｏｎ ｏｆ ａ Ｔｈｒｅａｄ Ｕｎｔｉｌ ａ Ｓｐｅｃｉｆｉｅｄ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ Ｏｃｃｕｒｓ）」に関連する。
［背景］
１．技術分野
本開示は、プロセッサの技術分野に関する。より詳細には、本開示は、マルチスレッドプロセッサ及びマルチスレッドプロセッサの１つのスレッドの処理を一時的にサスペンドする技術に関する。
２．関連分野の説明
マルチスレッドプロセッサは、複数の異なる命令シーケンスを同時処理することができる。１つのプロセッサにおいて複数の命令ストリームを実行する主要な動機的要因は、それによるプロセッサの利用効率の向上である。何年もの間、高度なパラレルアーキテクチャが開発されてきたが、複数の実行ユニットを利用する１つの命令ストリームから十分な並列性を抽出することはしばしば困難である。同時マルチスレッドプロセッサにより、複数の命令ストリームが異なる実行リソースにおいてこれらリソースのさらなる利用のため同時に実行されるとことを可能にする。マルチスレッド処理は、長い待ち時間による遅延が発生したり、あるいはイベントの発生を頻繁に待つプログラムに対して特に効果的である。あるスレッドが長い待ち時間を要するタスクが終了するのを待機したり、あるいは特定のイベントのため待機しているとき、他のスレッドが処理される。

プロセッサによるスレッド間のスイッチ時における制御のための様々な技術が提案されてきた。例えば、プロセッサの中には、Ｌ２キャッシュミスのような長い待ち時間のイベントを検出し、この検出された長い待ち時間のイベントに応答してスレッドをスイッチするというものがある。このような長い待ち時間のイベントの検出はある状況では効果的かもしれないが、このようなイベントの検出により、スレッドをスイッチすることが効果的なすべてのポイントが検出されるわけではない。特に、イベントベースのスレッドスイッチ処理では、遅延がプログラマーにより意図されているようなプログラムにおいてポイントを検出することは不可能であろう。

実際、プログラマーは、無駄なスピンウェイトループまたは他のリソース消費遅延技術を回避するため、どの時点でスレッドのスイッチングを行うことが効率的かを判断するのにベストなポジションにいる。従って、プログラムによりスレッドのスイッチ処理の制御を可能にすることは、プログラムがより効率的に動作することを可能にするかもしれない。スレッドの選択に影響を与える明示的なプログラム命令はこの目的に関して効果的であるかもしれない。例えば、２０００年１月２１日に出願された米国特許出願０９／４８９，１３０号では、「ポーズ（Ｐａｕｓｅ）」命令が説明されている。ポーズ命令は、あるカウントに達するまで、あるいはある命令がプロセッサパイプラインを通過するまで、スレッドの実行を一時的にサスペンドすることを可能にする。しかしながら、上記参照された出願で説明されているポーズ命令はスレッド分割可能なリソースが放棄されるべきであるということを特定するものではない。プログラマーによるマルチスレッドプロセッサのリソースのより効率的な利用を可能にする様々なテクニックが有益かもしれない。

本発明は、例を用いて示されるが、添付された図面に制限されるものではない。
［詳細な説明］
以下の説明では、マルチスレッドプロセッサのスレッドの実行をサスペンドする技術が示される。以下の説明では、本発明のより完全な理解を提供するため、論理実施形態、オペコード、オペランド指定手段、リソース分割／共有／重複実施形態、システム構成要素のタイプ及び相互関係、及び論理分割／統合選択などの様々な具体的詳細が与えられる。しかしながら、本発明はそのような具体的詳細なしに実践されうるということを当業者は認識するであろう。他の例では、本発明を不明瞭にしないように、制御構造、ゲートレベル回路及び完全なスフとウェア命令シーケンスは詳細には示されていない。当業者は与えられた説明により、過度の実験を行うことなく適切に機能の実現が可能であろう。

開示されるテクニックは、プログラマーが他のスレッドに処理リソースを利用させながら、あるスレッドにおいてサスペンド機構を実現することを可能にするかもしれない。このため、サスペンドされたスレッドに以前に提供された区画が、当該スレッドのサスペンド中放棄されるかもしれない。上記及び／または他の開示されたテクニックは効果的にプロセッサのトータルのスループットを向上させるかもしれない。

図１は、メモリアクセスを監視するメモリアクセスモニタ１１０を有するマルチスレッドプロセッサ１００の一実施例を示す。「プロセッサ」という用語は、いくつかの実施例では単一の集積回路として構成されるかもしれない。他の実施例では、複数の集積回路がまとまって１つのプロセッサを構成するかもしれないし、さらなる他の実施例では、ハードウェア及びソフトウェアルーチン（例えば、バイナリ変換ルーチン）が一緒になってプロセッサを構成するかもしれない。図１の実施例では、バス／メモリコントローラ１２０が実行命令をフロントエンド１３０に提供する。フロントエンド１３０は、命令ポインタ１７０に従って様々なスレッドからの命令の抽出を指示する。命令ポインタ論理は複数のスレッドをサポートするよう複製される。

フロントエンド１３０は、さらなる処理のため命令をスレッド分割可能リソース１４０に供給する。スレッド分割可能リソース１４０は、複数のスレッドがプロセッサ１００内でアクティブであるとき、特定のスレッドに専用の論理的に分離された区画を有する。一実施例では、各分離した区画は、当該区画用のスレッドからの命令のみを有する。スレッド分割可能リソース１４０は、例えば、命令キューを含んでいてもよい。シングルスレッドモードでは、スレッド分割可能リソース１４０の複数の区画が、この１つのスレッドに専用のより大きな１つの区画を形成するよう合成される。

プロセッサ１００はまた複製状態１８０を有する。複製状態１８０は、論理プロセッサのためのコンテクストを維持するのに十分な状態変数を有する。複製状態１８０では、状態変数の格納の競合なく複数のスレッドを実行することができる。さらに、各スレッドにレジスタ割当て論理が複製されてもよい。複製された状態関連の論理は、入力される実行命令のための適切なリソース区画により動作する。

スレッド分割可能リソース１４０は、共有リソース１５０に命令をわたす。共有リソース１５０は、それらのソースに関係なく命令に応じて動作する。例えば、スケジューラと実行ユニットはスレッドに関しない共有リソースであってもよい。分割可能リソース１４０は、各アクティブスレッドでの持続的な継続によりスレッド間での切り替えにより複数のスレッドから共有リソース１５０への命令を供給するかもしれない。これにより、共有リソースは、スレッドの混合を考慮することなく適切な状態で与えられた命令を実行することができる。

共有リソース１５０は他のスレッド分割可能リソース１６０に続いてもよい。スレッド分割可能リソース１６０は、リオーダーバッファ（ｒｅ−ｏｒｄｅｒ ｂｕｆｆｅｒ）などのリタイアメントリソース（ｒｅｔｉｒｅｍｅｎｔ ｒｅｓｏｕｒｃｅ）を含んでいてもよい。これにより、スレッド分割可能リソース１６０は、各スレッドからの命令の実行が適切に完了し、当該スレッドの適切な状態が適切に更新されることを保証するかもしれない。

上述のように、プログラマーにメモリ配置の定期的なポーリング（ｐｏｌｌｉｎｇ）や命令の実行さえも求めることなく、スピンウェイトループ（ｓｐｉｎ−ｗａｉｔ ｌｏｏｐ）機能を実現するテクニックを与えることが望ましいかもしれない。従って、図１のプロセッサ１００はメモリアクセスモニタ１１０を有する。メモリアクセスモニタ１１０は、モニタ１１０による監視が可能なメモリアクセスサイクルについての情報によりプログラム可能である。従って、モニタ１１０は、比較論理１１４によりバス／メモリコントローラ１２０から受信されるバスサイクル情報と比較されるモニタサイクル情報レジスタ１１２を有する。一致した場合には、再開スレッド信号が生成され、サスペンドしていたスレッドが再開される。プロセッサの内部及び／または外部バスからメモリアクセス情報が取得されてもよい。

モニタサイクル情報レジスタ１１２は、スレッドの再開をトリガーするサイクルタイプ及び／またはアドレスを指定する詳細を含んでもよい。一実施例では、モニタサイクル情報レジスタ１１２は物理的アドレスを格納し、モニタは当該物理的アドレスへの実際または潜在的な書き込みを示すバスサイクルを監視する。そのようなサイクルは、明示的なライト（ｗｒｉｔｅ）サイクルの形式であってもよいし、及び／またはオーナー権限でのリード（ｒｅａｄ）あるいは、外部バス処理なしの当該ラインへの書き込みが可能となるキャッシュ可能ラインの排他的なオーナー権限を取得しようとする他のエージェントによる無効サイクルであってもよい。何れの場合でも、モニタは異なる実施例での様々な処理に関するトリガーとなるようプログラムされるかもしれない。

図２のフロー図を参照して、図１の実施例の動作がさらに説明される。一実施例では、プロセッサ１００の命令セットはモニタ処理情報を設定するＭＯＮＩＴＯＲオペコード（命令）を有する。ブロック２００において、ＭＯＮＩＴＯＲオペコードは第１スレッド（Ｔ１）の命令シーケンスの一部として受信される。ブロック２１０に示されるように、ＭＯＮＩＴＯＲオペコードに応答して、プロセッサ１００はモニタ１１０が指定されたメモリアクセスに対するメモリアクセスを監視することが可能である。メモリアクセスのトリガーは明示的または非明示的オペランドにより指定されてもよい。従って、ＭＯＮＩＴＯＲオペコードの実行は、モニタアドレスが非明示的オペランドとしてレジスタまたは他の領域に予め格納することが可能であるため、当該モニタアドレスの指定が可能であるかもしれない。ブロック２１５に示されるように、モニタはこの指定されたサイクルが検出されるかどうかチェックする。もし検出されなければ、モニタはメモリアクセスの監視を継続する。トリガーとなるサイクルが検出されれば、モニタイベント保留指標がブロック２２０で示されるように設定される。

ＭＯＮＩＴＯＲオペコードの実行はモニタ１１０の起動をトリガーする。モニタ１１０はプロセッサの他の処理とパラレルに動作を開始するかもしれない。一実施例では、ＭＯＮＩＴＯＲ命令が適切なメモリサイクル情報によりモニタ１１０を設定し、モニタイベントを表面化することなくも似た１１０を起動する。言い換えると、本実施例では、ＭＯＮＩＴＯＲオペコードの実行後、モニタイベントが発生するかもしれないが、それらが明示的に表面化されなければ、認識されることはないであろう。

従って、ブロック２２５において、メモリ待機のトリガーは別のイベントとして示される。いくつかの実施例では、メモリ待機（ＭＷＡＩＴ）オペコードはモニタイベントの認識及びＴ１のサスペンドをトリガーするのに利用されるかもしれない。異なる２つの命令を利用して、スレッドサスペンドの設定及びトリガーを行うことは、プログラマーに付加的なフレキシビリティを提供し、より効率的なプログラミングを可能にするかもしれない。しかしながら、他の実施例では、モニタ１１０を設定する第１オペコードからメモリ待機がトリガーされる。何れの場合も、１以上の命令によりモニタは準備され、モニタイベントの認識を可能にする。

異なるオペコードがモニタ１１０の準備とモニタイベントの認識をトリガーするのに利用される実施例では、ブロック２３０に示されるようなスレッドのサスペンド前にモニタが起動されるのを保証するためのチェックが行われることが効果的であるかもしれない。さらに、モニタイベントがすでに保留されているかどうかチェックすることにより（図示せず）、Ｔ１のサスペンドが回避され、ブロック２５０において動作が継続される。モニタ１１０がイネーブル状態にあり、かつモニタイベントの保留がないと仮定すると、Ｔ１はブロック２３５に示されるようにサスペンドされるかもしれない。

Ｔ１のサスペンドにより、プロセッサは他のスレッドがプロセッサリソースをより完全に利用することが可能な実施形態に依存した状態に入る。いくつかの実施例では、プロセッサはＴ１専用の分割可能リソース１４０及び１６０の区画の一部またはすべてを放棄するかもしれない。他の実施例では、ＭＯＮＩＴＯＲオペコードの異なる置換あるいはそれに関する設定により、もしあるとすれば、どのリソースが放棄されるべきか示されるかもしれない。例えば、プログラマーがより短い待機を予想する場合、スレッドはサスペンドされるが、それのリソース区画を維持するかもしれない。共有リソースはスレッドサスペンド期間中の他のスレッドにより排他的に利用されるため、スループットは依然として向上する。より長い待機が予想される場合、サスペンドされているスレッドに関するするすべての区画の放棄は他のスレッドが追加的なリソースを有することを可能とするため、潜在的にその他のスレッドのスループットを増大させる。しかしながら、各スレッドがサスペンド及び再開されるとき、区画の削除及び追加に関するオーバヘッドを犠牲にして追加的なスループットが可能となる。

モニタイベントの保留中、Ｔ１はサスペンド状態を維持する。前述のように、モニタ１１０はモニタイベント（ブロック２１５−２２０）の検出及び合図を行うよう独立に動作する。プロセッサによりブロック２４０において保留中のモニタイベントが検出されると、ブロック２５０に示されるようにＴ１が再開される。モニタイベントがＴ１を覚醒させるＴ１での命令のアクティブな処理の発生が必要である。むしろＴ１はサスペンド状態のままであり、イネーブル状態のモニタ１１０はプロセッサにイベントを合図する。プロセッサは当該イベントを処理し、このイベントがＴ１の再開を示していると認識し、Ｔ１を再開するための適切なアクションを実行する。

従って、図１及び２の実施例では、プログラムによりサスペンドされたスレッドが指定されたメモリアクセスの発生により再開されることを可能にするテクニックが提供される。一実施例では、他のイベントがまたＴ１を再開させる。例えば、割込みによりＴ１が再開されるかもしれない。そのような実現形態では、モニタが特定のメモリアクセスや、スレッドの再開を引き起こす他の状態を見逃す（検出しない）という点で完全なものとしないことが効果的である。その結果、Ｔ１はときどき不必要に覚醒されるかもしれない。しかしながら、そのような実現形態では、見逃されたイベントによりＴ１が永遠に凍結される可能性が低減され、ハードウェア設計及び検証を簡素化する。Ｔ１が覚醒する状態が真に発生したかＴ１に二重にチェックさせ、そうでない場合再びＴ１をサスペンドするようループが構成されるため、Ｔ１の不必要な覚醒は軽視できるほどの不便さであるかもしれない。

いくつかの実施例では、スレッド分割可能リソース、複製リソース及び共有リソースが異なって構成されるかもしれない。いくつかの実施例では、共有リソースの両端に分割可能リソースは存在しないかもしれない。いくつかの実施例では、分割可能リソースは厳密には分割されず、むしろある命令により区画の重複が可能となるようにされるか、あるいは当該区画で実行されるスレッドまたは実行される区画の総数に依存して、区画サイズが可変となるようにされるかもしれない。さらに、異なるリソースの組み合わせが共有、複製及び分割リソースとして指定されるかもしれない。

図３は、マルチスレッドプロセッサの一実施例のさらなる詳細を示す。図３の実施例は、コヒーレンシー関連論理３５０と、モニタ３１０の一実施形態と、スレッドサスペンド再開論理３７７の特定の一実施形態とを有する。図３の実施例では、バスインタフェース３００は、バスコントローラ３４０と、イベント検出論理３４５と、モニタ３１０と、コヒーレンシー関連論理３５０とを有する。

バスインタフェース３００は、マイクロ命令からマイクロオペランド（ｕＯＰ）を生成するｕＯＰを生成する命令をフロントエンド３６５に提供する。実行リソース３７０はフロントエンド３６５からｕＯＰを受け取り、バックエンド論理３８０は実行後様々なｕＯＰをリタイヤする。一実施例では、アウトオブオーダー（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）実行が、フロントエンド、バックエンド及び実行リソースによりサポートされる。

図５から９に関して様々な動作の詳細がさらに説明される。しかしながら、簡単には、ＭＯＮＩＴＯＲオペコードがバスインタフェース３００を介しプロセッサに入力され、フロントエンド３６５による実行のため準備されてもよい。一実施例では、実行リソース３７０による実行のため、特別なＭＯＮＩＴＯＲ ｕＯＰが生成される。ＭＯＮＩＴＯＲ ｕＯＰは実行ユニットによるストア処理と同様に処理されてもよく、モニタアドレスがアドレス変換論理３７５により物理的アドレスに変換され、モニタ３１０に提供される。モニタ３１０は、スレッドを再開させるため、スレッドサスペンド再開論理３７７と通信する。スレッドサスペンド再開論理は、アクティブ状態のスレッド数が変化するに従って、分割及びアニール（ａｎｎｅａｌ）リソースを実行してもよい。

例えば、図４は、一実施例によるリソースの分割、複製及び共有を示す。分割リソースは、マシーンのアクティブ状態のスレッドの消長に従って、分割及びアニールされてもよい（他のスレッドによる再利用のためヒューズバックされる）。図４の実施例では、複製リソースは、パイプラインの命令フェッチ部分の命令ポインタ論理、パイプラインのリネーム部分のレジスタリネーム論理、状態変数（図示しないが、パイプラインの様々な段階で参照される）、及び割込みコントローラ（図示しないが、一般にパイプラインに非同期）を有する。図４の実施例における共有リソースは、パイプラインのスケジュール段階のスケジューラ、パイプラインのレジスタリード及びライト部分のレジスタプール、及びパイプラインの実行部分の実行リソースを有する。さらに、トレースキャッシュ及びＬ１データキャッシュは、スレッドのコンテクストに関係なくメモリアクセスに従い配備された共有リソースであってもよい。他の実施例では、スレッドコンテクストがキャッシュ処理の決定において考慮されてもよい。図４の実施例の分割リソースは、パイプラインのキュー処理段階の２つのキュー、パイプラインのリタイアメント段階でのリオーダーバッファ、及びストアバッファを有する。スレッド選択多重化論理は、両方のスレッドへの適切なアクセスを提供する様々な複製及び分割リソース間で交替にする。

例示のため、図４に示される分割、共有及び複製は、図３のプロセッサの一実施例による動作のさらなる説明において、図３の実施例に関して利用される。特に、図３の実施例による動作のさらなる詳細は、図５のフロー図に関して説明される。プロセッサは、アクティブ状態の少なくとも２つのスレッドを有するマルチスレッドモードで実行すると仮定される。

ブロック５００において、第１スレッド（Ｔ１）の実行中、フロントエンド３６５はＭＯＮＩＴＯＲオペコードを受信する。一実施例では、特別なモニタｕＯＰがフロントエンド３６５により生成される。このＭＯＮＩＴＯＲ ｕＯＰは実行リソース３７０にわたされる。モニタｕＯＰは監視対象のアドレスを示す関連付けされたアドレス（モニタアドレス）を有する。この関連付けされたアドレスは、明示的オペランドまたは非明示的オペランドの形式であるかもしれない（すなわち、関連付けされたアドレスは所定のレジスタまたは他の格納領域から取得される）。この関連付けされたアドレスは、モニタアドレスの決定に十分な情報を伝達するという点で、モニタアドレスを「示している」（おそらく他のレジスタまたは情報に関連して）。例えば、関連付けされたアドレスは、適切なモニタアドレスである対応する物理的アドレスを有するリニアアドレス（ｌｉｎｅａｒ ａｄｄｒｅｓｓ）であるかもしれない。あるいは、モニタアドレスはバーチャルなアドレスフォーマットで与えられるかもしれないし、あるいは相対アドレスとして示されるかもしれないし、あるいは他の既知または便利なアドレス指定方法により指定されるかもしれない。バーチャルなアドレスオペランドが利用される場合、一般的保護エラーがブレークイベントとして認識されることを可能にすることが望ましいかもしれない。

モニタアドレスは、監視のための任意の便利なメモリユニットを示すかもしれない。例えば、一実施例では、モニタアドレスはキャッシュラインを示すかもしれない。しかしながら、他の実施例では、モニタアドレスは、キャッシュラインの一部、異なるプロセッサのキャッシュラインサイズに対して異なる関係を生み出す指定／選択されたサイズのメモリ部分またはユニット、あるいは１つのアドレスを示すかもしれない。従って、モニタアドレスは、オペランドにより指定されるデータ（及び複数のデータ）を有するユニットを示すものであってもよいし、あるいは所望のデータユニットのアドレスを具体的に示すものであってもよい。

図３の実施例では、モニタアドレスは、アドレス変換論理３７５に与えられ、モニタ３１０にわたされ、モニタアドレスレジスタ３３５に格納される。ＭＯＮＩＴＯＲオペコードに応答して、ブロック５１０に示され、図６においてさらに詳述されるように、実行リソース３７０はイネーブル状態とされ、モニタ３１０を起動する。図６に関してさらに以下で後述されるように、スレッドサスペンド処理の発生前にストアが処理及び検出されることを保証するため、ＭＯＮＩＴＯＲオペコード後に発生する任意のストア処理を制限することが効果的であるかもしれない。従って、本実施例において以降の任意の命令が開始される前に、モニタ３１０の起動の結果として、いくつかの処理が発生する必要があるかもしれない。しかしながら、本実施例では、モニタ３１０がＭＯＮＩＴＯＲオペコードにより起動されると、モニタ３１０はブレークイベントが発生するまで他の処理とパラレルに動作を継続するため、ブロック５１０はブロック５０５とパラレルに発生するよう示される。

ブロック５０５において、メモリ待機（ＭＷＡＩＴ）オペコードがスレッド１で受信され、実行にわたされる。図５の実施例では、ＭＷＡＩＴオペコードの実行はモニタイベントを表面化する。ＭＷＡＩＴオペコードに応答して、ブロック５１５に示されるように、モニタイベントが保留中であるかチェックされる。モニタイベントが保留中でない場合、ブロック５２０においてモニタがアクティブ状態であることを保証するため、チェックが行われる。例えば、以前にＭＯＮＩＴＯＲを実行することなくＭＷＡＩＴが実行される場合、モニタ３１０はアクティブ状態ではないであろう。モニタがアクティブ上体でない場合、あるいはモニタイベントが保留中である場合、スレッド１の実行がブロック５８０において継続される。

モニタ３１０がアクティブ状態であり、かつモニタイベントが保留中でない場合、ブロック５２５に示されるように、スレッド１の実行はサスペンドされる。スレッドサスペンド／再開論理３７７は、ブロック５３０に示されるように、すべての命令をクリアするため、プロセッサのパイプラインを排出するパイプラインフラッシュ論理３８２を有する。パイプラインが排出されると、分割／アニール論理３８５は、ブロック５３５に示されるように、スレッド１と排他的に関連付けされている任意の分割リソースを他のスレッドによる利用のため放棄させる。これら放棄されたリソースは、残りのアクティブ状態のスレッドが利用するより大きなリソースを形成するようアニールされる。例えば、図４の２つのスレッドの例を参照するに、スレッド１に関するすべての命令は両方のキューから排出される。その後、キューの各ペアがより大きなキューを第２スレッドに提供するため合成される。同様に、レジスタプールからより多くのレジスタが第２スレッドに利用可能となり、ストアバッファからより多くのエントリが第２スレッドに提供され、リオーダーバッファのより多くのエントリが第２スレッドに利用可能となる。本質的に、これらの構成は２倍のサイズの１つの専用構成に返される。もちろん、異なるスレッド数を使った実施形態からは異なる比率のものが生成される。

ブロック５４０、５４５及び５５０において、スレッド１が再開されるべきか決定する様々なイベントがチェックされる。特に、これらのチェックは他のスレッドの処理とパラレルに実行される。図６に関してさらに詳述されるように、モニタはモニタライトイベントが発生したかチェックし、設定によりイベント保留指標を示す。イベント保留指標は、ＥＶＥＮＴ信号を介してサスペンド／再開論理３７７（すなわち、マイクロコード）に提供される。モニタイベントはブロック５０５においてＭＷＡＩＴオペコードにより表面化されていたため、一実施例（ブロック５４０）では、マイクロコードは適切な命令境界においてモニタイベントを認識するかもしれない。イベント検出論理３４５は、割込みのようなブレークイベント（ブロック５４５）として指定される他のイベントを検出するかもしれない。さらに、プロセッサが特定のイベントシーケンスにより凍結されることを保証するため、オプショナルなタイマーがメモリ待機状態から定期的に抜け出すように利用されるかもしれない（ブロック５５０）。これらイベントのどれもがメモリ待機状態への脱出を合図しなければ、スレッド１はサスペンドのままである。

スレッド１が再開されれば、スレッド／サスペンド再開論理３７７が適切なイベントの検出に応じて再び起動される。再び、ブロック５６０に示されるように、間もなく覚醒されるスレッド１を収容するようリソースが再び分割可能となるように、パイプラインから命令を排出するためパイプラインがフラッシュされる。ブロック５７０において、適切なリソースが再分割され、スレッド１がブロック５８０において再開される。

図６ａは、モニタ３１０の起動と動作のさらなる詳細を示す。ブロック６００において、スレッド１のフロントエンドフェッチ処理が、さらなるスレッド１の処理がマシーンに入るのを回避するよう中断される。ブロック６０５において、アドレス変換論理３７５により、関連付けされたアドレスオペランドはリニアアドレスから物理的アドレスに変換される。ブロック６１０において、監視されているアドレスへの書き込みの観察可能性が向上される。一般に、この処理の目的は、モニタ３１０が閲覧可能なモニタアドレスに格納されている情報に影響を与えるライト処理をキャッシュエージェントに実行させることである。図６ｂに関して一実施例のさらなる詳細が説明される。ブロック６１５において、物理的アドレスがこのシーケンスの前後に格納されてもよいが、監視のため格納される。

次にブロック６２０に示されるように、モニタがイネーブル状態にされる。モニタは、モニタアドレスレジスタ３３５に格納されるモニタアドレスである物理的アドレスへの書き込みのためバスサイクルを監視する。図７を参照して、監視処理のさらなる詳細が後述される。モニタがイネーブル状態となった後、ストア制限処理がブロック６２５に示されるように実行される。このストア制限は、マシーンのすべてのストアがＭＯＮＩＴＯＲオペコードの実行完了時に処理されることを保証するのに役立つ。すべてのストアがＭＯＮＩＴＯＲの前にマシーンから排出されることにより、メモリ待機状態が誤って入力される可能性が低減される。しかしながら、このストア制限処理は予防的措置であり、時間のかかる処理となりうる。

このストア制限はオプション的なものである。なぜなら、本実施例のＭＯＮＩＴＯＲ／ＭＷＡＩＴ機構は複数のエグジット機構（ｅｘｉｔ ｍｅｃｈａｎｉｓｍ）として設計されているためである。言い換えると、割込み、システムまたは搭載タイマーなどの様々なイベントは、メモリ待機状態から抜け出させるかもしれない。従って、本実施例では、スレッドが覚醒される唯一の理由は、監視されるデータ値の変更によるものであるということは保証されない。従って、本実施形態では、メモリに格納されている特定の値が変更されたかソフトウェアにより二重にチェックされる（以下の図９ａから９ｃを参照せよ）。一実施例では、ＩＮＴＲ、ＮＭＩ及びＳＭＩ割込み、マシーンチェック割込み及びエラーのアサーションを含むイベントがブレークイベントであり、パワーダウンイベントを含む他のものはブレークイベントではない。一実施例では、Ａ２０Ｍピンのアサーションはまたブレークイベントである。

ブロック６３０に示されるように、モニタはバスサイクルの発生がモニタアドレスへの書き込みを示すか、あるいは示しているらしいかをチェックし続ける。そのようなバスサイクルが検出されると、ブロック６３５に示されるように、モニタイベント保留指標が設定される。ＭＷＡＩＴオペコードの実行後（図５のブロック５０５）、このイベント保留指標はイベントとして機能し、図５のブロック５６０−５８０においてスレッドを再開させる。さらに、アドレス変換を変更するイベントがスレッド１を再開させるかもしれない。例えば、変換ルックアサイドバッファ（ｔｒａｎｓｌａｔｉｏｎ ｌｏｏｋ−ａｓｉｄｅ ｂｕｆｆｅｒ）をフラッシュさせるイベントがスレッド１の再開をトリガーするかもしれない。なぜなら、リニアアドレスから物理的アドレスへのモニタアドレスの生成で行われる変換はもはや有効でないかもしれないためである。例えば、ｘ８６インテルアーキテクチャコンパチブルプロセッサにおいて、制御レジスタＣＲ０、ＣＲ３及びＣＲ４と特定のマシーンに特有のレジスタへの書き込みは、メモリ待機状態の脱出を引き起こすかもしれない。

上述のように、図６ｂは、モニタアドレスへの書き込みの観察可能性の拡張のさらなる詳細を示す（図６ａのブロック６１０）。一実施例では、ブロック６５０に示されるように、プロセッサはモニタアドレスに関連付けされたキャッシュラインをプロセッサのすべての内部キャッシュからフラッシュする。このフラッシュ処理の結果として、モニタアドレスへの以降の任意の書き込みがバスインタフェース３００に届き、バスインタフェース３００に含まれるモニタ３１０による検出を可能にする。一実施例では、ＭＯＮＩＴＯＲ ｕＯＰがモデル化され、ｘ８６命令セットの既存の命令であるキャッシュラインフラッシュＣＬＦＬＵＳＨ命令と同じエラーモデルを有する。モニタｕＯＰは、リニアを介してアドレスの物理的変換に進み、ＣＬＦＬＵＳＨと同様の内部キャッシュのフラッシュ処理が行われる。しかしながら、バスインタフェースはＭＯＮＩＴＯＲとＣＬＦＬＵＳＨとの差異を認識し、適切にＭＯＮＩＴＯＲ ｕＯＰを処理する。

次にブロック６５５に示されるように、バスインタフェース３００のコヒーレンシー関連論理３５０は、プロセッサバス上でリードライン処理を生成するためリードライン生成論理３５５を起動する。モニタアドレスへのリードライン処理は、バス上のプロセッサの他のキャッシュが、共有状態または排他的状態の何れかでモニタアドレスのデータを格納することを保証する（羞恥のＭＥＳＩプロトコルに従って）。他のプロトコルでは、他の状態が利用されるかもしれない。しかしながら、この処理はモニタ３１０による閲覧可能でなくとも他のエージェントがモニタアドレスに書き込みを行うことができる可能性を低減するよう設計されている。言い換えると、ライトまたは書き込みを示す処理がモニタにより検出することができるように、以降において配信される。リードライン処理が実行されると、モニタ３１０はバス上の処理の監視を開始する。

バス上で追加的な処理が発生すると、コヒーレンシー関連論理は、バスエージェントが監視されているアドレスに関連付けされたキャッシュラインのオーナー権限を取得することを回避しようとすることにより、モニタアドレスの閲覧可能性を保持し続ける。１つのバスプロトコルによると、これは、ブロック６６０に示されるように、モニタアドレスのリードの探索段階においてＨＩＴ＃信号をアサートするヒット生成論理３６０により達成されるかもしれない。ＨＩＴ＃のアサート処理は、他のキャッシュがＭＥＳＩプロトコルにおける共有状態を越えて、排他的及び潜在的には変更
状態に移行するのを回避する。その結果、ブロック６６５に示されるように、選ばれたコヒーレンシー領域（コヒーレンシーを維持するメモリ部分）のどのエージェントも変更または排他的状態（またはそれらと等価なもの）でデータを有することが可能である。本実施例では内部キャッシュからフラッシュされたとしても、プロセッサはモニタキャッシュのキャッシュラインを効果的にキャッシュするようである。

図７を参照するに、図６ａのブロック６２０に関する処理のさらなる詳細が説明される。特に図７は、モニタ３１０の処理のさらなる詳細を示す。ブロック７００において、モニタ３１０はバス処理のためバスコントローラ３４０からリクエストとアドレス情報を受信する。ブロック７１０に示されるように、モニタ３１０はバスサイクルタイプと影響を得けるアドレスを調べる。特に、サイクル比較論理３２０はバスサイクルが指定されたサイクルであるか判断する。一実施例では、アドレス比較回路３３０は、バス処理アドレスとモニタアドレスレジスタ３３５に格納されているモニタアドレスとを比較し、ライト検出論理３２５は書き込みが発生したか検出するため、バスコントローラ３４０からサイクルタイプ情報を復号する。モニタアドレスへの書き込みが発生すると、ブロック７２０に示されるように、モニタイベント保留指標が設定される。イベントを合図するため、信号（ＷＲＩＴＥ ＤＥＴＥＣＴＥＤ）がスレッドサスペンド／再開論理３７７に提供される（そして、ＭＷＡＩＴを実行することによりイネーブル状態になったと仮定して提供される）。最後に、モニタ３１０がブロック７３０に示されるように停止される。モニタの停止は電力を節約するが、エラーモニタイベントが隠されている限り、そうでなければ生成されない限り、それは重要ではない。モニタイベント指標はまたこの時点でリセットされてもよい。典型的には、モニタイベントの提供は、ＭＷＡＩＴが再び実行されるまで、さらなるモニタイベントの認識を隠す。

モニタアドレスへのリードの場合、コヒーレンシー関連論理３５０が起動される。ブロック７４０に示されるように、コヒーレンシー配信を行うことなく以降の書き込みを可能にするオーナー権限を他のエージェントが取得することを防ぐため、信号（ＨＩＴ＃のような）がアサートされる。モニタ３１０は、アクティブ状態を維持し、ブロック７００に戻って、モニタアドレスの読み出しにより影響を受けない。さらに、処理がモニタアドレスに対する読み出し及び書き込みのどちらでもなければ、モニタはアクティブ状態を維持し、ブロック７００に戻る。

いくつかの実施例では、あるアクセスタイプのみが監視されるようにＭＯＮＩＴＯＲ命令が制限される。これらのアクセスは効率的なプログラミングテクニックを示すものとして選ばれたものであってもよいし、あるいは他の理由により選ばれたものであってもよい。例えば、一実施例では、メモリアクセスは自然と揃えられたライトバックメモリ（ｗｒｉｔｅ−ｂａｃｋ ｍｅｍｏｒｙ）のキャッシュ可能なストアでなければならない。自然に揃えられた要素は、Ｎで割り切れるアドレスから始まるＮビットの要素である。自然に揃えられた要素を利用した結果、監視されているアドレスに書き込みため、１つのキャッシュラインがアクセスされる必要がある（データが２つのキャッシュラインに分割される場合に必要とされる２つのキャッシュラインではなく）。その結果、自然に揃えられたメモリアドレスを利用することはバスの観察を簡素化するであろう。

図８は、開示されたマルチスレッドメモリ待機テクニックを利用するシステムの一実施例を示す。図８の実施例では、プロセッサ８０５−１から８０５−ＮまでのＮ個のマルチスレッドプロセッサ群がバス８０２に接続される。他の実施例では、シングルプロセッサ、またはマルチスレッドプロセッサとシングルスレッドプロセッサとを組み合わせたものが利用されてもよい。さらに、他の既知のシステム構成または利用可能なシステム構成が利用されてもよい。例えば、これらのプロセッサはポイント・ツー・ポイント形式で接続され、メモリインタフェースのようなパーツが各プロセッサに統合されてもよい。

図８の実施例では、バスに接続されたメモリインタフェース８１５はメモリ８３０とメディアインタフェース８２０に接続される。メモリ８３０は、マルチプロセッシングレディ（ｍｕｌｔｉ−ｐｒｏｃｅｓｓｉｎｇ ｒｅａｄｙ）オペレーティングシステム８３５と、第１スレッド８４０に対する命令と、第２スレッド８４５に対する命令とを含む。命令８３０は、開示された技術に従ったアイドルループを有し、その様々な変形が図９ａから９ｃに示される。

これら様々な機能を実行する適切なソフトウェアが、様々なマシーン読み出し可能媒体の何れかにより提供されるかもしれない。メディアインタフェース８２０は、そのようなソフトウェアへのインタフェースを提供する。メディアインタフェース８２０は、記憶媒体（例えば、ディスクドライブ、光ドライブ、テープドライブ、揮発性メモリ、不揮発性メモリなど）とのインタフェース、または送信媒体インタフェース（例えば、ネットワークインタフェースまたは他のデジタルあるいはアナログ通信インタフェース）であってもよい。メディアインタフェース８２０は媒体（例えば、記憶媒体７９２あるいは送信媒体７９５）からソフトウェアルーチンを読み出すかもしれない。マシーン読み出し可能媒体は、マシーンインタフェースによる読み出しのため、少なくとも一時的に情報を格納することができる任意の媒体である。これには、信号送信（媒体として有線、光、空気を介し）、及び／または様々なタイプのディスク及びメモリ記憶装置のような物理的記憶媒体７９２が含まれる。

図９ａは、一実施例によるアイドルループを示す。ブロック９０５において、ＭＯＮＩＴＯＲコマンドがそれのオペランドであるモニタアドレスとしてアドレス１により実行される。同様のスレッドにおいて、ブロック９１０でＭＷＡＩＴコマンドが実行される。前述のように、ＭＷＡＩＴ命令により、他の状態が適切に満たされると仮定して、スレッドがサスペンドされる。ブロック９１５においてブレークイベントが発生すると、当該ルーチンはモニタアドレスに格納されている値が変更されたかどうか判断するためブロック９２０に移行する。モニタアドレスの値が変更している場合、ブロック９２２に示されるように、スレッドの実行が継続される。値が変更されていない場合、エラー覚醒イベントが発生したことになる。当該覚醒イベントは、ＭＷＡＩＴがモニタアドレスへのメモリ書き込みの発生なく終了されたという意味でエラーである。値が変更されていない場合、モニタが再び設定されるブロック９０５にループは戻る。このループソフトウェアの実施形態では、モニタがエラー覚醒イベントを可能とするよう設計されている。

図９ｂは、他のアイドルループを示す。図９ｂの実施例は、ＭＷＡＩＴ命令が監視されているメモリアドレスへの書き込みを捉えることができない可能性をさらに低減するため、追加的な１つのチェックを加える。再び、図９ｂのフローは、ブロック９２５に示されるように、ＭＯＮＩＴＯＲ命令がそれのオペランドとしてアドレス１により実行されることから開始される。さらに、ブロック９３０において、ソフトウェアルーチンは、モニタアドレスにおけるメモリ値を読み出す。ブロック９３５において、ソフトウェアはメモリ値がスレッドをアイドル状態にすべきであると示す値から変更されていないことを保証するため二重チェックする。値が変更されている場合、ブロック９５２に示されるように、スレッドの実行が継続される。値が変更されていない場合、ブロック９４０に示されるように、ＭＷＡＩＴ命令が実行される。前述のように、ブロック９４５でブレークイベントが発生するまで、スレッドはサスペンドされる。しかしながら、再び、エラーブレークイベントが可能であるため、値が変更されたかブロック９５０でチェックされる。値が変更されていない場合、ブロック９２５に戻ることにより、モニタによるアドレス１の追跡を可能にするためループが戻る。値が変更されている場合、ブロック９５２においてスレッドの実行が継続される。いくつかの実施例では、ＭＷＡＩＴ命令がスレッドを再びサスペンドするよう実行される前のエラー覚醒イベント後、ＭＯＮＩＴＯＲ命令が再び実行される必要はないかもしれない。

図９ｃは、ＭＯＮＩＴＯＲ命令とＭＷＡＩＴ命令を利用したソフトウェアシーケンスの他の例を示す。図９ｃの例では、スレッド内の２つの異なるタスクがすべき作業を有する場合、ループはアイドルとはされない。第１ルーチンにより行われるべき作業がある場合には、定数ＣＶ１が作業領域ＷＬ１に格納される。同様に、第２ルーチンにより行われるべき作業がある場合には、定数ＣＶ２が作業領域ＷＬ２に格納される。１つのモニタアドレスを利用するため、ＷＬ１とＷＬ２が同じキャッシュラインのメモリ領域となるよう選ばれる。あるいは、複数のタスクのための状態指標を格納するのに１つの作業領域が利用されてもよい。例えば、１バイトあるいは他の単位において１以上のビットがそれぞれ異なるタスクを表してもよい。

ブロック９５５に示されるように、Ｗ１を監視するためモニタが設定される。ブロック９６０において、ＷＬ１が実行すべき作業を有する定数を格納しているかどうかチェックされる。格納している場合、ブロック９６５に示されるように、ＷＬ１に関する作業が実行される。格納されていない場合、ブロック９７０において、ＷＬ２に関して実行されるべき作業があることを示すＣＶ２をＷＬ２が格納しているかチェックされる。格納されている場合、ブロック９７５に示されるように、ＷＬ２に関する作業が実行される。格納されていない場合、ブロック９８０において電力管理ハンドラを呼び出すことが適当であるか決定するためループが進むかもしれない。例えば、決められた時間が経過すると、論理プロセッサが低減された電力消費状態に置かれてもよい（例えば、本出願の出願と同様にｗｗｗ．ａｃｐｉ．ｉｎｆｏで利用可能な１９９９年２月８日に発行されたＡＣＰＩ（Ａｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ）仕様バージョン１．０ｂ（あるいはそれ以降）により定義された「Ｃ」状態群の１つ）。時間が経過している場合、ブロック９８５において電力管理ハンドラが呼び出される。行うべき作業がある９６５、９７５及び９８５の何れの場合においても、スレッドは当該作業を行い、ブロック９５５においてモニタの設定後再び同一の決定を行うためループバックする。他の実施例では、モニタがアクティブ状態を維持する限り、ブロック９６５、９７５及び９８５からのループバックはブロック９６０となるかもしれない。

ブロック９６５、９７５及び９８５を通じて行うべき作業がなければ、ブロック９９０に示されるように、ＭＷＡＩＴ命令が実行される。ブロック９９５に示されるように、ブレークイベントが発生するとき、ＭＷＡＩＴにより生じるスレッドサスペンド状態が最終的に終了される。この時点で、モニタの設定のためループはブロック９５５に戻り、その後ＷＬ１またはＷＬ２が行うべき作業が存在することを示している決定する。行うべき作業が存在しない場合（すなわち、エラー覚醒イベントの場合には）、ブロック９９０においてループはＭＷＡＩＴに戻り、ブレークイベントが発生するまで再びスレッドをサスペンドする。

図１０は、モニタ値がＬ１キャッシュにキャッシュされた状態を維持することを可能にするプロセッサの他の実施例を示す。図１０のプロセッサは、実行ユニット１００５と、Ｌ１キャッシュ１０１０と、Ｌ１キャッシュと包括されたＬ２キャッシュ１０３０との間のライト合成バッファとを有する。ライト合成バッファ１０２０は、バスインタフェース１０４０によりバス１０４５から受信された処理を介して他のメモリとの内部キャッシュのコヒーレンシーを保証する探索ポート１０４４を有する。コヒーレンシーに影響を及ぼす処理がライト合成バッファ１０２０に探索ポート１０４４を介し届くため、モニタはＬ１キャッシュレベルに置かれ、メモリライトイベントがバス１０４５で発生するときを決定するのに十分な情報を受信する。従って、モニタアドレスに対応するメモリラインがＬ１キャッシュに保持されてもよい。モニタは、実行ユニットからＬ１キャッシュへの書き込みと、探索ポート１０４４を介したバス１０４５からの書き込みの両方を検出することができる。

他の実施例では、２オペランドモニタ命令がサポートされている。１つのオペランドは前述のようにメモリアドレスを示す。第２オペランドは、メモリ待機状態からブレークしない様々なイベントのどれがこの特定のメモリ待機からブレークさせるかを示すマスクである。例えば、１つのマスクビットは、隠された割込みが当該割込みが隠されているという事実にもかかわらずメモリ待機をブレークすることを可能にすべきということを示すかもしれない（すなわち、ＥＦＬＡＧＳビットＩＦが割込みを隠すよう設定されているときでさえ、覚醒イベントを可能にする）。前提として、メモリ待機状態後に実行される命令の１つが、提供されるように割込むブレークされた表面化処理である。メモリ待機状態をブレークしない他のイベントは、メモリ待機のブレークをイネーブルとすることが可能であり、あるいは逆にメモリ待機状態を通常ブレークするイベントはイネーブル解除されうる。第１オペランドに関して説明したように、第２オペランドは明示的あるいは非明示的であってもよい。

図１１は、開示された技術を利用した設計のシミュレーション、エミュレーション及び製造のための様々な設計表現または形式を示す。設計を表すデータは当該設計を様々な方法により表せるかもしれない。まず、シミュレーションに有益なものとして、ハードウェアはハードウェア記述言語または設計されたハードウェアの期待される実行方法のコンピュータ化されたモデルを実質的に提供する他の機能記述言語を利用して表現されるかもしれない。ハードウェアモデル１１１０は、当該モデルが意図した通りの機能を行うか決定するため、特定のテストスーツ１１３０をハードウェアモデル１１１０に適用するシミュレーションソフトウェア１１２０を利用することによりシミュレートできるように、ハードウェアモデル１１１０はコンピュータメモリのような記憶媒体に格納されてもよい。いくつかの実施例では、シミュレーションソフトウェアは、記録、キャプチャあるいは媒体に含まれない。

さらに、論理及び／またはトランジスタゲートを有する回路レベルモデルが設計プロセスのいくつかの段階において生成されるかもしれない。このモデルは、ときにはプログラム可能な論理を利用したモデルを構成する専用ハードウェアシミュレータにより同様にシミュレートされるかもしれない。さらに進んだこのタイプのシミュレーションはエミュレーション技術であるかもしれない。どの場合でも、再構成可能なハードウェアは、開示された技術を利用したモデルを格納するマシーン読み出し可能媒体に関する他の実施例である。

さらに、大部分の設計は、ある段階において、ハードウェアモデルでの様々なデバイスの物理的配置を表すデータレベルに達する。従来の半導体製造技術が利用される場合には、ハードウェアモデルを表すデータは集積回路の製造に利用されるマスクの異なるマスクレイヤに関する様々な特徴の有無を特定するデータであるかもしれない。再び、集積回路を表すこのデータは、データにおける回路または論理が開示された技術を実行スｒためシミュレートまたは製造されうるという点でこれら技術を実現する。

設計の任意の表現において、データは任意の形式のコンピュータ読み出し可能媒体に格納されるかもしれない。情報を送信するため変調あるいは生成される光あるいは電子波１１６０、メモリ１１５０、ディスクのような磁気または光記憶装置１１４０は媒体であるかもしれない。設計または当該設計の一部を記述するビット群は、それ自体が販売される物品であるかもしれないし、あるいはさらなる設計または製造のため他に利用される物品であるかもしれない。

指定されたメモリアクセスが発生するまで、スレッドの実行をサスペンドする技術が開示された。例示された実施例は添付された図面において説明及び例示されたが、このような実施例は単なる例示であり、広範な本発明を限定するものではなく、本開示を研究することにより当業者には様々な他の変更が想起されるため、本発明は例示及び説明された特定の攻勢及び配置に限定されるものではないということは理解されるであろう。

図１は、メモリアクセスを監視するモニタを有するマルチスレッドプロセッサの一実施例を示す。 図２は、一実施例による図１のマルチスレッドプロセッサの動作を示すフロー図である。 図３は、マルチスレッドプロセッサの一実施例のさらなる詳細を示す。 図４は、一実施例によるリソース分割、共有及び複製を示す。 図５は、一実施例によるスレッドの実行をサスペンド及び再開処理を示すフロー図である。 図６ａは、一実施例による論理の起動及び関し処理を示すフロー図である。 図６ｂは、一実施例による書き込みの観察可能性の拡張を示すフロー図である。 図７は、一実施例による監視処理を示すフロー図である。 図８は、一実施例によるシステムを示す。 図９ａは、開示されたプロセッサ命令及び技術を利用したソフトウェアシーケンスの様々な実施例を示す。 図９ｂは、開示されたプロセッサ命令及び技術を利用したソフトウェアシーケンスの様々な実施例を示す。 図９ｃは、開示されたプロセッサ命令及び技術を利用したソフトウェアシーケンスの様々な実施例を示す。 図１０は、監視されているアドレスがキャッシュに残されることを可能にする他の実施例を示す。 図１１は、開示された技術を利用した設計のシミュレーション、エミュレーション及び製造のための様々な設計表現または形式を示す。

Claims (69)

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. 請求項２８記載のプロセッサであって、さらに、
    前記モニタからモニタイベントを表面化し、第２命令に応答して前記第１スレッドをサスペンドする論理を有することを特徴とするプロセッサ。
34. 複数のスレッドを実行する複数の実行ユニットと、
    前記複数のスレッドの第１スレッドから命令を受信するフロントエンド論理と、
    保留中のモニタイベントがない場合、前記命令に応答して前記第１スレッドをサスペンドし、前記複数のスレッドの他のスレッドの実行を可能にするサスペンド論理とを有することを特徴とするプロセッサ。
35. 請求項３４記載のプロセッサであって、前記サスペンド論理は、すでに保留中のモニタイベントを含むモニタイベントの認識を可能にすることを特徴とするプロセッサ。
36. 請求項３５記載のプロセッサであって、さらに、
    複数の分割可能リソースを有し、
    前記サスペンド論理は、前記命令に応答して前記第１スレッドをサスペンドすることに加えて、前記第１スレッドに関する前記複数の分割可能リソースのそれぞれの区画を放棄することを特徴とするプロセッサ。
37. 命令を受信する複数のスレッド分割可能リソースと、
    前記複数のスレッド分割可能リソースと協調して命令を実行する複数の共有リソースと、
    第１スレッドの命令に応答して前記第１スレッドをサスペンドし、該第１スレッドのサスペンドに加えて、前記第１スレッドに関する前記複数のスレッド分割可能リソースの部分を放棄するスレッドサスペンド論理と、
    前記複数のスレッド分割可能リソースを再分割させ、前記第１スレッドにより示されるメモリアドレスへのアクセスに応答して、前記第１スレッドの実行を再開させるモニタとを有することを特徴とするプロセッサ。
38. 請求項３７記載のプロセッサであって、前記メモリアドレスへのアクセスは前記第１スレッドで実行される第１命令により指定され、前記モニタは前記スレッドサスペンド論理が前記第１スレッドをサスペンドするのに応答して、前記命令によるスレッドの再開させるモニタイベントを合図するよう表面化されることを特徴とするプロセッサ。
39. 実行の複数のスレッドの第１スレッドをサスペンドする手段と、
    メモリ領域へのアクセスを検出する手段と、
    前記メモリ領域へのアクセスを検出する手段に応答して、前記第１スレッドを再開する手段とを有することを特徴とする装置。
40. 請求項３９記載の装置であって、前記メモリ領域へのアクセスを検出する手段は前記第１スレッドにおいて実行される第１命令に応答してイネーブル状態とされ、前記第１スレッドをサスペンドする手段は前記第１スレッドにおいて実行される第２命令に応答して前記第１スレッドをサスペンドすることを特徴とする装置。
41. 請求項４０記載の装置であって、さらに、
    前記メモリ領域へのアクセスの検出を簡素化するコヒーレンシー手段を有することを特徴とする装置。
42. 請求項４１記載の装置であって、前記メモリ領域へのアクセスはライトまたは無効アクセスであることを特徴とする装置。
43. 請求項４１記載の装置であって、さらに、
    前記第１スレッドの実行をサスペンドする手段に応答してリソースをアニールし、前記複数のスレッドの他のスレッドによる利用のため前記第１スレッドに関する分割リソースを解放する手段と、
    前記第１スレッドの再開を受け入れるため、リソースを再分割するためにリソースを分割する手段とを有することを特徴とする装置。
44. 実行の第１スレッドにおいてモニタアドレスを示す関連するアドレスオペランドを有する第１オペコードを受信するステップと、
    前記第１スレッドをサスペンドするステップと、
    前記モニタアドレスへのメモリアクセスを検出するステップと、
    前記モニタアドレスへのメモリアクセスの検出に応答して前記第１スレッドを再開するステップとを有することを特徴とする方法。
45. 請求項４４記載の方法であって、前記第１スレッドのサスペンドは、該第１スレッドにおいて第２命令を受信し、該第２命令に応答して前記第１スレッドをサスペンドすることからなることを特徴とする方法。
46. 請求項４５記載の方法であって、前記メモリアクセスはライトアクセスであることを特徴とする方法。
47. 請求項４５記載の方法であって、さらに、
    前記関連するアドレスオペランドを監視対象の物理的アドレスに変換するステップを有し、
    前記モニタアドレスへのメモリアクセスを検出するステップは前記監視対象の物理的アドレスへのライトアクセスを検出することからなることを特徴とする方法。
48. 請求項４４記載の方法であって、さらに、
    他のエージェントが前記モニタアドレスに格納されている情報のオーナー権限を取得することを回避するステップを有することを特徴とする方法。
49. 請求項４４記載の方法であって、前記メモリアクセスを検出するステップは、外部バス処理からサイクル情報を受信し、前記モニタアドレスへの書き込みを検出することからなることを特徴とする方法。
50. 請求項４４記載の方法であって、さらに、
    前記モニタアドレスへのメモリアクセス以外のイベントに応答して前記第１スレッドを再開するステップを有することを特徴とする方法。
51. 請求項５０記載の方法であって、前記イベントは割込みであることを特徴とする方法。
52. 請求項５１記載の方法であって、前記割込みは第２オペランドによりブレークイベントとみなされるように示されるマスクされた割込みであることを特徴とする方法。
53. 実行の第１スレッドにおいて実行される第１オペコードを受信するステップと、
    前記第１オペコードに関するリニアアドレスを物理的アドレスに変換するステップと、
    監視バスエージェントにより、他のどのバスエージェントも前記監視バスエージェントに通知することなく他のバスエージェントが前記物理的アドレスに関するデータを変更することを可能にするだけの前記データの十分なオーナー権限を所持しないことを保証するため、バス処理を実行するステップと、
    前記物理的アドレスへのライトアクセスを監視するステップと、
    他のバスエージェントが前記物理的アドレスを読み出す場合、ヒットを合図するステップと、
    前記実行の第１スレッドにおいて第２オペコードを受信するステップと、
    前記第２オペコードに応答して、前記実行の第１スレッドをサスペンドし、モニタイベントの認識をイネーブル状態にするステップと、
    前記ライトアクセスが発生する場合、前記第１スレッドを再開するステップと、
    第１イベント群の何れかに応答して前記第１スレッドの実行を再開するステップと、
    第２イベント群を無視するステップとを有することを特徴とする方法。
54. 請求項５３記載の方法であって、前記第２オペコードに応答して前記実行の第１スレッドをサスペンドするステップは、前記モニタイベントが保留中であるかチェックし、モニタがアクティブ状態であるかチェックし、前記モニタがアクティブ状態であり、かつ保留中のモニタイベントが存在しない場合、第１スレッドサスペンド状態に入ることからなることを特徴とする方法。
55. 請求項５４記載の方法であって、前記第１スレッドサスペンド状態に入ることは、レジスタプールの複数のレジスタを放棄し、命令キューの複数の命令キューエントリを放棄し、ストアバッファの複数のストアバッファエントリを放棄し、リオーダーバッファの複数のリオーダーバッファエントリを放棄することからなることを特徴とする方法。
56. 第１スレッドからモニタアドレスを示す関連するアドレスオペランドを有する第１命令を格納するメモリと、
    前記メモリに接続され、前記第１命令に応答してメモリ処理を監視するモニタによる前記モニタアドレスへのメモリアクセスの検出を可能にし、前記モニタアドレスへのメモリアクセスに応答して前記第１スレッドを再開させる第１プロセッサとを有するシステム。
57. 請求項５６記載のシステムであって、前記メモリは前記第１スレッドからの第２命令を格納し、前記第１プロセッサは前記第２命令に応答して前記第１スレッドをサスペンドすることを特徴とするシステム。
58. 請求項５７記載のシステムであって、前記モニタは前記メモリアクセスの発生に応答して、前記第１プロセッサに前記第２命令により表面化されたスレッドを再開させるも似たイベント保留指標を設定することを特徴とするシステム。
59. 請求項５６記載のシステムであって、前記第１プロセッサは第１キャッシュを有し、該システムはさらに、
    第２キャッシュを有する第２プロセッサを有し、
    前記第１プロセッサは前記第２プロセッサに前記第２キャッシュのモニタアドレスに格納されているデータの変更を可能にする処理を前記第１プロセッサに配信させるため、前記第２プロセッサに対するバス処理を駆動することを特徴とするシステム。
60. 請求項５９記載のシステムであって、前記第１プロセッサは、前記第２プロセッサにより変更の発生を配信することなく前記第２キャッシュのモニタアドレスに格納されているデータの変更を可能にする状態において、前記モニタアドレスにおけるデータを前記第２プロセッサがキャッシュすることを回避する信号をアサートすることを特徴とするシステム。
61. 請求項６０記載のシステムであって、前記信号は、キャッシュヒットを示し、前記第２キャッシュが排他的状態で前記モニタアドレスにおけるデータを格納することを回避することを特徴とするシステム。
62. 請求項５８記載のシステムであって、前記第１プロセッサはさらに、代わりのイベントが発生した場合、前記第１スレッドを再開することを特徴とするシステム。
63. 請求項６２記載のシステムであって、前記代わりのイベントは割込みであることを特徴とするシステム。
64. 請求項６２記載のシステムであって、前記メモリに格納されている第１スレッドは、前記第１命令と前記第２命令とを有するループと、前記モニタアドレスにおけるデータが変更されたか決定し、前記モニタアドレスにおけるデータが変更されていなければ前記ループを再開するテストとを有することを特徴とするシステム。
65. コンピュータ読み出し可能な媒体を有し、プロセッサを表す物品であって、
    モニタアドレスを示す関連するアドレスオペランドを有する第１命令を有する第１スレッドを含む複数のスレッドの実行を可能にする複数の実行ユニットと、
    前記第１スレッドの実行をサスペンドするサスペンド論理と、
    前記モニタアドレスへのメモリアクセスに応答して前記第１スレッドを再開させるモニタとを有することを特徴とする物品。
66. 請求項６５記載の物品であって、前記メモリアクセスが前記メモリアドレスへの実際的または潜在的書き込みを示す場合にのみ、前記モニタは前記メモリアクセスに応答して再開させることを特徴とする物品。
67. 請求項６５記載の物品であって、前記第１スレッドがサスペンドされ、かつモニタイベントが表面化されている場合、前記モニタは前記モニタアドレスへのメモリアクセスに応答して前記第１スレッドを再開させることを特徴とする物品。
68. 請求項６５記載の物品であって、さらに、
    前記メモリアクセス以外のイベントに応答して前記第１スレッドを再開させるイベント検出論理を有することを特徴とする物品。
69. 請求項６８記載の物品であって、さらに、
    複数のスレッドがアクティブ状態であるとき、前記複数のスレッドの各アクティブ状態のスレッドに各分割可能リソースの一部を提供するよう分割される複数の分割可能リソースを有し、
    前記サスペンド論理は前記第１スレッドの実行のサスペンドに応答して、前記第１スレッドに提供された前記複数の区画の何れかを放棄することを特徴とする物品。

Images