JP3919764B2

JP3919764B2 - 例外条件を解消するために同時マルチスレッド・プロセッサでディスパッチ・フラッシュを使用する方法

Info

Publication number: JP3919764B2
Application number: JP2004105227A
Authority: JP
Inventors: ウィリアム・イー・バーキー; ロナルド・エヌ・カッラ; バララム・シンハロイ; ジョン・ダブリュ・ワードＩｉｉ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-04-24
Filing date: 2004-03-31
Publication date: 2007-05-30
Anticipated expiration: 2024-03-31
Also published as: JP2004326748A; US7213135B2; US20040215944A1

Description

本発明は、一般に、同時マルチスレッド（ＳＭＴ）モードおよび単一スレッド・オペレーション・モードを有するプロセッサのための方法および回路に関する。

長い間、パフォーマンスを向上させる秘訣は、普通であれば命令レベル並列性（ＩＬＰ／ＩｎｓｔｒｕｃｔｉｏｎＬｅｖｅｌＰａｒａｌｌｅｌｉｓｍ）として知られる、１サイクルについてより多くの命令を実行させること、または命令の待ち時間を減らすことであった。各サイクルに、より多くの命令を実行させるには、より多くの機能ユニット（たとえば、整数、浮動小数点、ロード／ストア・ユニットなど）を追加しなければならない。複数の命令をより一貫して実行するためには、アウトオブオーダ（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）処理（ＯＯＰ）と呼ばれる処理パラダイムを使用することが可能であり、実際、このタイプの処理が主流になりつつある。

ＯＯＰは、多くの命令が、すでに処理パイプラインへ送信された他の命令の結果に依存していることから生じる。この問題の改善を助けるように、即時実行を可能にするために多数の命令が格納される。これが実行される理由は、互いに依存していない、より多くの命令を見つけることである。即時実行する準備の整った命令を格納するために使用される記憶域は、レコーダ・バッファと呼ばれる。１２６もの命令を格納できるようなシステムを備えた最新の市販コンピュータ・アーキテクチャでは、このレコーダ・バッファのサイズが大きくなってきている。レコーダ・バッファのサイズが大きくなる理由は単純であり、空間的に関連するコードは、（複雑なストラクチャおよびリンクされたリストのアレイを除いたとしても）実行の面で時間的にも関連する傾向があるためである。唯一の問題は、これらの命令が以前の命令の結果に依存する傾向も有することである。ＣＰＵが必要とするコードの量が増え続けていることから、依存していない命令をより多く見つけるための現時点での唯一の方法は、レコーダ・バッファのサイズを大きくすることである。

ただし、この技法を使用することで、パフォーマンス向上率が著しく下落する印象を与えてしまい、実際に利益の減少を示している。現在では、同じパフォーマンス向上率を達成するために、さらに多くのトランジスタが使用されている。単一プロセッサＩＬＰ抽出のみに照準を合わせるのではなく、マルチスレッド（マルチプロセッシング）を介するが主な制約としてのシステム・バスは使用せずに、命令またはスレッド・レベルでより粗い形でのパフォーマンス抽出に照準を合わせることができる。

単一チップ上により多くのトランジスタが配置できるようになり、オンチップ・マルチプロセッシング（ＣＭＰ／ｏｎ−ｃｈｉｐｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）が可能になった。このアーキテクチャでは、潜在的なパフォーマンスの向上を利用するために、これら複数のプロセッサを単一プロセッサとして使用することはできず、むしろ命令を並列方式で実行することに依拠したマルチプロセッシングを使用しなければならない。そのためには、ＣＭＰ上で実行されるプログラムを、単に直列または逐次方式で実行するのではなく、並列方式で実行するように作成する必要もある。アプリケーションが並列方式（マルチスレッド方式）で実行するように作成されると想定すると、この様式で作成されたプログラムを、追加されるプロセッサの数に比例してより高速に実行させようとするのに付き物の難しさがある。

複数のコアを１つのダイ上で使用することの背景にある一般的な概念は、２つのスレッドを同時に実行することによってより高いパフォーマンスを引き出すことである。そうすることによって、２つのＣＰＵが共に、機能ユニットのうち、より高い割合の集合数に常時有用な作業を実行させておくことができる。プロセッサがより多くの機能ユニットを有する場合、それらのユニットのうち一度に有用な作業を実行できる割合は低くなる。オンチップ・マルチプロセッサは、プロセッサあたりの機能ユニットの数を少なくし、各プロセッサに別々のタスク（またはスレッド）を分配する。このようにして、組み合わせられた両方のタスク上でより高いスループットを達成することができる。比較した場合の単一プロセッサは、１つのスレッドまたはタスクをＣＭＰチップよりも速く終えることが可能であるが、これは、無駄な機能ユニットはあるが、プロセッサが複数のデータを同時に計算し、使用可能なすべての機能ユニットを使用するときに、アクティビティの「バースト」も生成されるためである。マルチプロセッサの背景にある考え方の１つは、個々のプロセッサにこうしたバースト・アクティビティの時間を経験させないようにし、代わりに各プロセッサに、それが使用できるリソースをより頻繁に、したがって効率的に使用させるようにすることである。クロック・サイクル中に機能ユニットの一部を使用しないことは、「水平浪費（ｈｏｒｉｚｏｎｔａｌｗａｓｔｅ）」として知られており、ＣＭＰはこれを避けるように努める。

ただし、ＣＭＰには問題がある。従来のＣＭＰチップは、２つまたはそれ以上のスレッドの完了を促進するために、単一スレッドのパフォーマンスを犠牲にするものである。このようにして、スレッドが１つしかない場合、（従来のマルチプロセッサ（ＭＰ）システムにおいて、個々にスレッド化されたプログラムを使用するシステムで他のプロセッサを追加しても無用であるのとまったく同様に）割り当てられたリソースの半分がアイドル状態であり、完全に無用であることから、ＣＭＰチップは一般的な用途では比較的柔軟性に乏しい。ＣＭＰにおいて機能ユニットをより効率的にする方法の１つは、粗粒度マルチスレッディング（ＣＭＴ／ｃｏａｒｓｅ−ｇｒａｉｎｅｄｍｕｌｔｉｔｈｒｅａｄｉｎｇ）を使用することである。ＣＭＴは、一定数のクロック・サイクルに対して１つのスレッドを実行することによって、機能ユニットの使用率に関して効率を上げるものである。効率は、「垂直浪費（ｖｅｒｔｉｃａｌｗａｓｔｅ）」の減少によって向上する。垂直浪費とは、１つのスレッドが機能停止（ｓｔａｌｌ）しているために、どの機能ユニットも動作していない状況を表す。

他のスレッドに切り替える場合、プロセッサはそのスレッドの状態（すなわち、どこで命令がパイプラインに入るか、どのユニットが使用中であるか）を保存した後、他のスレッドに切り替える。これは、複数のレジスタ・セットを使用することで実行される。このように実行することの利点は、スレッドはキャッシュ・ミス（ｃａｃｈｅｍｉｓｓ）になるまで、または実行する独立した命令がなくなるまでに、長い時間がかかることが多い、という事実によるものである。このようにしてＣＭＴプロセッサは、サポートしている異なるスレッドだけを実行できる。したがって、これらスレッドのそれぞれについて、それらの実行状態を格納するための物理位置があるスレッドだけを格納することができる。したがって、ＮウェイのＣＭＴプロセッサは、Ｎ個のスレッドの状態を格納する機能を有する必要がある。

この概念の変形は、その時点でシステムが他のスレッドに切り替えるキャッシュ・ミス（通常、Ｌ２（２次）キャッシュ・ミス）になるまで、１つのスレッドを実行することである。これは、前のスレッドが機能停止するとすぐに他のスレッドに切り替えるだけであるため、プロセッサを介してスレッドを循環（ｒｏｔａｔｅ）させるのに必要な論理を簡略化する利点がある。要求されたブロックがキャッシュに返送されてくるまで待機するという不利な点が緩和される。これは、一部のプロセッサによって使用されるヒット・アンダー・ミス（ｈｉｔｕｎｄｅｒｍｉｓｓ）（またはヒット・アンダー・マルチプル・ミス（ｈｉｔｕｎｄｅｒｍｕｌｔｉｐｌｅｍｉｓｓ））キャッシュ方式と同様であるが、命令ではなくスレッドに対して動作する点が異なる。ＣＭＰを介したＣＭＴの利点は、ＣＭＴが単一スレッドのパフォーマンスを犠牲にしないこと、およびハードウェアの重複が少ない（２つのプロセッサを同等のＣＭＴと「等しく」するために、半分にされるハードウェアが少ない）ことである。

より積極的なマルチスレッド方法は、細粒度（ｆｉｎｅ−ｇｒａｉｎｅｄ）マルチスレッディング（ＦＭＴ）と呼ばれる。ＣＭＴと同様に、ＦＭＴの基本は、スレッドを迅速に切り替えることである。ただしＣＭＴとは異なり、その考え方は、サイクルごとおよびあらゆるサイクルで切り替えることである。ＣＭＴおよびＦＭＴはどちらも実際に１つのスレッドの完了を遅くさせるが、ＦＭＴは動作中のすべてのスレッドの完了を促進するものであって、これが一般に最も重要な全体スループットである。

ＣＭＰは、元来およびそれ自体の水平浪費の一部を除去することができる。ＣＭＴおよびＦＭＴは、一部（またはすべて）の垂直浪費を除去することができる。ただし、同時マルチスレッディング（ＳＭＴ）と呼ばれる高度な形のマルチスレッディングを含むアーキテクチャを使用して、水平および垂直の両方の浪費を減らすことができる。ＳＭＴの第１の目標は、所与の時間に、および所与の機能ユニットで、異なるスレッドからの命令を実行する機能を持つことである。ＳＭＴアーキテクチャは、スレッドを循環することによってＦＭＴプロセッサと同様に働き、異なるスレッドからの命令を同時に実行することによってＣＭＰと同様に働く。そのため設計者達は、利益の減少を心配することなく、より広いコアを設計することができる。ＳＭＴには、「未使用」の機能ユニットを異なるスレッド間で共用する機能があるため、ＦＭＴよりも高い効率を達成することは妥当であり、このようにして、ＳＭＴはＣＭＰマシンの効率を達成する。ただし、ＣＭＰシステムとは異なり、ＳＭＴシステムは単一スレッドのパフォーマンスについて、ほとんど、またはまったく犠牲を払うことはない（わずかな犠牲については後述する）。その理由は簡単である。ＣＭＰプロセッサの多くは、単一スレッドの実行中にアイドル状態のままであり、ＣＭＰチップ上のプロセッサが多いほどこの問題は顕著であるが、ＳＭＴプロセッサはすべての機能ユニットを単一スレッドに専念させることができる。これは、複数スレッドを実行できることほど明らかに重要ではないが、単一スレッド環境とマルチスレッド環境とのバランスをとることができるのは、非常に有用な機能である。すなわちこれは、ＳＭＴプロセッサが、スレッド・レベル並列性（ＴＬＰ）が存在する場合にはこれを活用することが可能であり、存在しない場合には命令レベル並列性（ＩＬＰ）だけに留意することになることを意味する。

ＳＭＴプロセッサは、複数スレッドをサポートするために、従来のスーパースカラ（ｓｕｐｅｒｓｃａｌａｒ）プロセッサよりも多くのレジスタを必要とする。一般的な目標は、サポートしているスレッドそれぞれについて、単一プロセッサ用と同じだけのレジスタを提供することである。従来の縮小命令セット・コンピュータ（ＲＩＳＣ）チップの場合、これは、３２×Ｎ個のレジスタ（Ｎは、ＳＭＴプロセッサが１サイクルで処理できるスレッド数）に、必要な名前変更レジスタ（ｒｅｎａｍｉｎｇｒｅｇｉｓｔｅｒ）をすべて加えたものを示唆する。４ウェイＳＭＴプロセッサのＲＩＳＣプロセッサの場合、これは、１２８レジスタに必要な名前変更レジスタを加えたものを意味する。

ほとんどのＳＭＴモデルは、従来のアウトオブオーダ・プロセッサを単純に拡張したものである。実際のスループットが増加すると、命令発行の幅に対する需要も多くなり、したがってこれも増加するはずである。前述のレジスタ・ファイル・サイズの増加により、ＳＭＴパイプラインの長さは、クロック・サイクルの長さを減速させないように、２段階（１つはレジスタ・バンクの選択、１つは読取りまたは書込みの実行）増加する可能性がある。したがって、レジスタ読取りおよびレジスタ書込みの段階は、どちらも２つのパイプライン段階に分けられる。

いずれか１つのスレッドにパイプラインを支配させないようにするために、他のスレッドが実行時間およびリソースの現実的なスライスを確実に取得するように努めなければならない。機能ユニットが実行する作業を要求すると、フェッチ・メカニズムは、すでにパイプライン内にある最も少ない命令を有するスレッドに、高い優先順位を与える。もちろん、他のスレッドが実行できる命令をほとんど持たない場合は、そのスレッドからのより多くの命令がすでにパイプラインを支配していることになる。

ＳＭＴは、可能なものはほぼすべて共用している。ただし、場合によっては、これが従来のデータ編成、ならびに命令流れを混乱させる。分岐予測ユニットは、共用されると効率が悪くなるが、これはより多くの命令によってより多くのスレッドを追跡しなければならないためであり、その結果、正確な予測をするという点で効率が悪くなる。これは、予測ミスによってより頻繁にパイプラインをフラッシュする必要が生じることを意味するが、複数スレッドを実行する機能はこの欠点を十二分に補うものである。

ＳＭＴアーキテクチャが（２段階で）使用するパイプラインが長いほど、必要なレジスタ・ファイルが大きくなるために、予測ミスに関する損失は大きくなる。ただし、ＳＭＴアーキテクチャでは、スレッドあたりの必要なレジスタ数を最小限にするための技法が開発されてきた。これは、レジスタのより適切な割振り解除のための、より効率的なオペレーティング・システム（ＯＳ）およびハードウェア・サポート、ならびに他のスレッドがどのレジスタも使用していない場合は、他のスレッドのコンテキストからレジスタを共用する機能によって実行される。

他の問題は、キャッシュのサイズ、キャッシュのライン・サイズ、およびそれらによって与えられる帯域幅に関連した、スレッドの数である。単一スレッド・プログラムの場合と同様に、キャッシュのライン・サイズが増加すると、ミスの割合は減少するが、ミスによる損失は増加する。この問題は、より様々なデータを使用するより多くのスレッドをサポートすることによって悪化するため、それぞれのスレッドにとっては、キャッシュが少ないほど事実上有用である。キャッシュに関するこの競合は、マルチスレッドの作業負荷を介してマルチプログラムの作業負荷を処理する場合に、より顕著である。したがって、より多くのスレッドが使用中であれば、キャッシュも大きくなければならない。これは、共用Ｌ２キャッシュを備えたＣＭＰプロセッサにも当てはまる。

使用中のスレッドが多いほど、結果として全体のパフォーマンスが高くなり、メモリ・データの連係における相違点がより容易に明らかになる。Ｌ１（１次）キャッシュ・サイズが一定に保たれている場合、最高レベルのパフォーマンスは、より連係しやすいキャッシュを使用して達成されるが、アクセス時間は長くなる。スレッドの数が変化する間、連係して変わるブロック・サイズの変化に伴うパフォーマンスを決定するためのテストが行われている。以前と同様に、ブロックの連係レベルが上がると、必ずパフォーマンスも上がったが、２つより多くのスレッドが使用中であった場合、ブロック・サイズが大きくなるとパフォーマンスは下がった。これは、ブロックの連係度が上がっても、ブロック・サイズが大きくなりミスの損失が大きくなることによって生じた欠点を補うことができないほど大きなものであった。

ＳＭＴプロセッサは、広くリソースと呼ばれる様々な要素を有する。リソースは実行ユニット、レジスタ名前変更アレイ、完了テーブルなどであってよい。リソースの一部はスレッド特有のものであり、たとえば各スレッドは、各スレッドに対する命令がバッファに入れられるそれ自体の命令待ち行列を有することができる。実行ユニットは、各スレッドからの命令が実行される共用リソースである。同様に、完了ユニットのレジスタ名前変更アレイおよび完了テーブルも共用リソースであってよい。共用レジスタ名前変更アレイ内のエントリの大部分が１つのスレッドに割り当てられている場合、そのスレッドは、この共用リソースを使用し過ぎている可能性がある。他のスレッドが名前変更レジスタを処理する必要がある場合、リソース要件のためにブロックされ、ディスパッチできない場合がある。ＳＭＴプロセッサを備えたシステム内の他の要素はリソースと呼ばれる場合があり、それらのリソースが複数のスレッドからの命令の実行を遅くしない場合、本発明によって対処される問題には当てはまらない場合がある。

ＳＭＴプロセッサには、複数の実行ユニットでアウトオブオーダ命令実行を実行するためのより大きなパイプライン・プロセスの一部である、インオーダ（ｉｎ−ｏｒｄｅｒ）共用パイプラインがある場合がある。たとえば、２つのスレッドからの命令は、命令フェッチ・ユニット（ＩＦＵ）および命令ディスパッチ・ユニット（ＩＤＵ）を備える共用パイプラインに、交互にロードすることができる。命令・アドレスは、ＩＦＵ内の命令フェッチ・アドレス・レジスタ（ＩＦＡＲ）に交互にロードされる。この場合、共用パイプライン内の１つのスレッドが「機能停止」されると、その結果、他方のスレッドがパイプラインを介して進むのをブロックする可能性がある。第１のスレッドの第１の命令が、ディスパッチに達していない同じ第１のスレッドの次に続く第２の命令からの例外アドレスが例外条件を解消する必要のある例外条件を、実行中に生成するという、追加の条件がある。例外条件を生成している第１の命令が、第２の命令がディスパッチに進む前に、第２のスレッドからのブロック命令をディスパッチできるようにするために解放する必要のある共用リソースを有する場合、共用パイプラインをさらにブロックすることができる。

さらに、第２の命令がディスパッチに進まないようにする第２のスレッドからのブロック命令が、待ち時間の長いリソース要件を有し、非常に長い間潜在的にブロックできるタイプのものである場合もある。これによって、例外条件の解消も妨げられる。第２のスレッドのブロック命令が単にフラッシュおよび再フェッチされるだけの場合、第２の命令が進むのを機能停止しているブロックの除去はほとんど進まない。したがって、進むための例外条件を備えた他のスレッドのための場所を空けるために、パイプラインからのブロック命令を使用して、この条件を検出し、スレッドをフラッシュするための方法および回路が求められている。さらに、長いリソース待ち時間ブロック命令が、そのリソース要件が解消されるか、またはブロックされている例外条件が解消されるまで、再フェッチされないようにする、ホールドオフ・メカニズムが求められている。

したがって、リソースの使用による例外条件の機能停止を検出し対処するための方法および回路が求められている。さらに、長い待ち時間のリソース要件を備えた命令が再フェッチされる時点を制御し、ディスパッチ・パイプラインに再入する、ホールドオフ・メカニズムが求められている。

ディスパッチ・フラッシュ・オペレーションは、通常、パイプラインの機能停止を発生させている共用ディスパッチ・パイプライン内のスレッドの命令をフラッシュするのが望ましい場合に発行される。ディスパッチ・フラッシュは、ＳＭＴプロセッサのより小さな部分に影響を与えるため、一般のフラッシュよりも効果的である。第１のスレッドの第１の命令は、例外を解消するために第１のスレッドの第２の命令のアドレスを必要とする例外条件を発生させることができる。この場合、第２の命令は、それを、獲得されるアドレスのためのパイプラインのディスパッチ段階に実行しなければならない。単一のスレッド・モードでは、数サイクル内に必要な命令がディスパッチ段階に現われ、例外が解消できるため、これは問題ではない。第１の命令が、完了するまで解放されないリソースを使用している場合、これらのリソースを同様に必要とする第２のスレッドのブロック命令は、共用パイプラインをブロックして、第１のスレッドの第２の命令がディスパッチ・パイプラインに達するのを妨げることができる。この条件が、第１のスレッドをフラッシュすること、またはブロックを解消できる何らかのタイプの例外ハンドラを使用することによって解消できる、パイプラインの機能停止を発生させる。

第１のスレッドの第１の命令が、例外を解消するために第１のスレッドの第２の命令のアドレスを必要とする例外条件を発生させると、本発明の実施形態は、ディスパッチ・フラッシュ・オペレーションを使用してこの条件を解消する。ディスパッチ・フラッシュは、第２のスレッドの命令に対して発行される。これによって、第１のスレッドの命令が進めるようになり、第１のスレッドの第２の命令は、例外を解消するためにディスパッチできるようになる。

第２のスレッドのブロック命令が、長い待ち時間を有するリソース要件を備えているという理由で共用パイプラインをブロックしている場合、第１のスレッドに対する第２の命令は長い間発行することができないため、例外の解消も妨げる。この場合、フラッシュされる第２のスレッドの命令が再フェッチされ、リソースの待ち時間を満たすことのできるようにパイプラインに再入する時点を制御する、ホールドを発行することができる。

以上、以下の本発明の詳細な説明をより良く理解できるように、本発明の特徴および技術的な利点について、おおまかに概説してきた。次に、本発明の特許請求の範囲の主題となる本発明の追加の特徴および利点について説明する。

本発明およびその利点をより完全に理解するために、添付の図面と共に以下の説明を参照する。

以下の説明では、本発明を完全に理解するために、多数の特定の細部が示される。ただし、当分野の技術者であれば、本発明がこうした特定の細部なしでも実施可能であることが明らかであろう。その他の場合には、不必要に詳細に示して本発明を不明瞭にしないために、良く知られた回路をブロック図の形で示すことができる。ほとんどの部分について、タイミング、通信プロトコル内のデータ・フォーマットなどに関する細部は、こうした細部が本発明を完全に理解するために必要ではなく、関連分野の通常の技術者の技術範囲内であるため、省略されている。

次に図を参照すると、記載された要素は必ずしも一定の縮尺で示されておらず、同じかまたは同様の要素にはいくつかの図面を通じて同じ参照番号が指定されている。

図１を参照すると、ＣＰＵ４１０が詳細に示されている。ＣＰＵ４１０は、クロック・サイクルごとに複数の命令を実行するように設計されている。したがって、複数の命令は、任意の１クロック・サイクル中に、実行ユニット、固定小数点ユニット（ＦＸＵ）１１４、浮動小数点ユニット（ＦＰＵ）１１８、およびロード／ストア・ユニット（ＬＳＵ）１１６のうちのいずれかで実行中であってよい。同様に、ＣＰＵ４１０は、ＳＭＴモードで複数のスレッドからの命令を同時に実行することができる。

プログラム・カウンタ（ＰＣ）１３４は、実行に関する命令を有するスレッド・ゼロ（Ｔ０）およびスレッド１（Ｔ１）に対応する。スレッド・セレクタ１３３は、命令アドレスを命令フェッチ・ユニット（ＩＦＵ）１０８に結合するために、Ｔ０とＴ１を交互に選択する。命令アドレスは、命令フェッチ・アドレス・レジスタ（ＩＦＡＲ）１０３にロードされる。ＩＦＡＲ１０３は、命令キャッシュ（Ｉ−Ｃａｃｈｅ）１０４から各スレッドに関する命令を交互にフェッチする。命令は、Ｔ０用の命令待ち行列（ＩＱ）１３５およびＴ１用のＩＱ１３６にバッファリングされる。ＩＱ１３５およびＩＱ１３６は、命令ディスパッチ・ユニット（ＩＤＵ）１３２に結合される。スレッド優先順位セレクタ１３７の制御の下で、命令が選択され、ＩＱ１３５およびＩＱ１３６から読み取られる。通常、スレッド優先順位セレクタ１３７は、各スレッドのプログラム制御優先順位にほぼ比例して、ＩＱ１３５およびＩＱ１３６から命令を読み取る。

命令は、ＩＤＵ１３２の復号器（図示せず）で復号される。次に命令シーケンサ１１３は、命令を様々なアルゴリズムによって決定された順にグループ単位で配置することができる。命令のグループは、ディスパッチ段階１４０によって、命令発行待ち行列（ＩＩＱ）１３１にディスパッチされる。命令シーケンサ１１３は、両方のスレッドからプログラム順に命令を受け取るが、命令は、どちらかのスレッドからプログラム順ではなくＩＩＱ１３１から発行される場合がある。汎用レジスタ（ＧＰＲ）ファイル１１５および浮動小数点レジスタ（ＦＰＲ）ファイル１１７は、複数の実行ユニットによって使用され、システムのプログラム状態を表す。これらのハードウェア・レジスタは、「設計済み（ａｒｃｈｉｔｅｃｔｅｄ）」レジスタと呼ばれることがある。命令が発行待ち行列にディスパッチされると、各設計済みレジスタは名前変更される。修正中の各設計済みレジスタには物理レジスタが割り当てられ、対応するルックアップ・テーブルが、設計済みレジスタに関連付けられた物理レジスタを識別する。したがって、発行待ち行列では、設計済みレジスタの複数のコピーが同時に存在可能なように、設計済みレジスタが名前変更される。これによって、ソース・オペランドが使用可能な限り、命令をアウトオブオーダで実行することができる。レジスタ名前変更ユニット１５０は、特定の物理レジスタを参照しているすべての命令が完了し、物理レジスタが最新の設計済み状態を含んでいない場合に、未使用の物理レジスタを再割当て可能なように、レジスタを名前変更およびマッピングする。

命令は、該当する実行ユニット内で実行するために、ＩＩＱ１３１の待ち行列に入れられる。命令が固定小数点オペレーションを含む場合、複数の固定小数点ユニット（ＦＸＵ）１１４のうちのいずれかを使用することができる。実行ユニット、ＦＸＵ１１４、ＦＰＵ１１８、およびＬＳＵ１１６のすべてが、発行済命令のうちのいずれが完了したか、および他の状況情報を示す、完了テーブル（図示せず）を有する完了ユニット１１９に結合される。完了ユニット１１９からの情報はＩＦＵ１０８に転送される。ＩＤＵ１３２も、完了ユニット１１９に情報を送ることができる。ＬＳＵ１１６からのストア・オペレーションからのデータは、データ・キャッシュ（Ｄ−Ｃａｃｈｅ）１０２に結合される。このデータは、近いうちに使用するためにＤ−Ｃａｃｈｅ１０２に格納することができ、かつ／または、バス４１２を介してメモリ１３９にデータを送信するバス・インターフェース・ユニット（ＢＩＵ）１０１に転送することができる。ＬＳＵ１１６は、実行ユニット（たとえばＦＸＵ１１４）が使用するために、Ｄ−Ｃａｃｈｅ１０２からのデータをロードすることができる。

ＳＭＴプロセッサ４１０は、ＩＦＵ１０８の回路と、２つのスレッド間で共用されるＩＤＵ１３２の回路とを含む、パイプライン段階を有する。命令は、プログラム順に各スレッドから交互にパイプライン段階にロードされる。命令はＩ−Ｃａｃｈｅ１０４からアクセスされると、Ｔ０待ち行列１３５およびＴ１待ち行列１３７に入れられる。命令は、等しく、またはスレッドの優先順位にほぼ比例して各スレッドから選択するスレッド優先順位セレクタ１３７に従って、これらの待ち行列から選択される。ＩＤＵ１３２中の命令シーケンサ１１３は、各スレッドからの命令を、１グループにつき命令が５つまでの命令グループに組み合わせる。スレッド・グループからの命令は、複数の実行ユニット（たとえば１１４、１１６、および１１８）に送り込む命令発行待ち行列１３１に対して発行される。命令グループ中の命令は、命令発行待ち行列１３１、および完了ユニット１１９内の完了テーブル（図示せず）にディスパッチされる場合、プログラム順である。ただし、命令は、実行ユニットに対してアウトオブオーダで発行される場合もある。

命令が実行ユニット（たとえばＦＰＵ１１８）で実行中の場合、命令が完了するのを妨げることになる、例外条件（たとえばＦＰＵ１１８でゼロで割る）が存在する場合がある。命令が完了しないと、共用リソース（たとえばグループ完了テーブル・エントリ）を解放しない。ディスパッチ段階１４０からのディスパッチを待っている命令がこのリソースを必要とする場合、その命令は、共用リソース要件が原因でディスパッチできないことになる。

図２は、本発明の実施形態を使用するＳＭＴプロセッサ４１０において、スレッドからの命令グループのディスパッチに使用される方法ステップを示す流れ図である。ステップ２０１では、ＩＤＵ１３２内の共用パイプラインのディスパッチ段階１４０に命令グループがあるかどうかを判定するためのテストが実行される。ステップ２０１でテストの結果が「いいえ」である場合、分岐はステップ２０１の入力に戻される。ステップ２０１でテストの結果が「はい」である場合、ステップ２０２で、（ＩＤＵ１３２の）ディスパッチ段階で命令グループに関する特定のスレッドを識別するために、スレッド識別（ＩＤ）がチェックされる。ステップ２０３では、適宜ＩＤＵ１３２から投機的にディスパッチするためにグループが待ち行列に入れられる。ステップ２０４では、命令グループに必要な共用リソースが使用可能であるかどうかを判定するためのテストが実行される。共用リソースが使用可能でない場合、ステップ２０９で、ＩＤＵ１３２からの命令グループのディスパッチが拒否される。共用リソースが使用可能な場合、ステップ２０５で、スレッド特有のリソースが使用可能であるかどうかを判定するためのテストが実行される。必要なスレッド特有のリソースが使用可能でない場合、ステップ２０９が実行され、ディスパッチは拒否される。ステップ２０６では、ＩＤＵ１３２内のいずれかのディスパッチ・フラッシュがすでに進行中であるかどうかを判定するためのテストが実行される。ディスパッチ・フラッシュがすでに進行中である場合、ステップ２０９でディスパッチは拒否される。進行中のディスパッチ・フラッシュがない場合、ステップ２０７で、ディスパッチ段階の命令グループに対応するスレッドのいずれかのフラッシュが進行中であるかどうかを判定するためのテストが実行される。ステップ２０７のテストの結果が「はい」である場合、ステップ２０９でディスパッチは拒否される。ステップ２０７のテストの結果が「いいえ」である場合、ステップ２０８で、ディスパッチ段階１４０から命令グループがディスパッチされる。

図３は、スレッド間での共用リソース内の矛盾によって、ディスパッチ・フラッシュを使用する命令流れを管理するために、本発明の実施形態で使用される方法ステップを示す流れ図である。ステップ３０１では、ＩＤＵ１３２でディスパッチ段階１４０に達していない第１のスレッドの第２の命令からの例外アドレスを必要とする、第１のスレッドに対する第１の命令を実行する間、実行ユニット（たとえばＦＸＵ１１４、ＬＳＵ１１６、またはＦＰＵ１１８）で例外条件が検出される。ステップ３０２では、第１のスレッドに対する第２の命令のディスパッチが、第２のスレッドのブロック命令によって、ディスパッチ段階１４０で機能停止されているかどうかを判定するためのテストが実行される。ステップ３０２のテストの結果が「いいえ」である場合、分岐はステップ３０３で、ディスパッチ段階１４０からの第２の命令のディスパッチが例外アドレスをディスパッチできるようになる、ステップ３０８に渡される。ステップ３０２のテストの結果が「はい」である場合、ステップ３０４で、ブロック命令が、例外条件を伴う第１のスレッドの第１の命令によって保持されているリソースを必要とするかどうかを判定するためのテストが実行される。ステップ３０４のテストの結果が「はい」である場合、ステップ３０９で、第２のスレッドのディスパッチ・フラッシュがＩＤＵ１３２に対して発行され、次いでステップ３０８で、ＩＤＵ１３２からの命令のディスパッチが続行される。ステップ３０４のテストの結果が「いいえ」である場合、ステップ３０５では、ブロック命令が長い待ち時間のリソース要件を有するかどうかを判定するためのテストが実行される。ステップ３０５のテストの結果が「いいえ」である場合、ステップ３０８に戻る。ステップ３０５のテストの結果が「はい」である場合、ステップ３０６で、ブロック命令を含む第２のスレッドに関するＩＤＵ１３２に対するディスパッチ・フラッシュが発行される。ステップ３０７では、ホールド・オペレーションが発行され、第２のスレッドのフラッシュ済み命令が再フェッチされる時点、およびＳＭＴ４１０の共用パイプラインに再入する時点を制御するホールドが生成される。次にステップ３０８で、ＩＤＵ１３２からの命令のディスパッチが続行される。

図５は、本発明の実施形態を使用するＳＭＴプロセッサ４１０において、ディスパッチ・フラッシュ・オペレーションを処理する際に使用される方法ステップを示す流れ図である。ステップ５００では、選択されたスレッドに関するディスパッチ・フラッシュ要求が、ＩＤＵ１３２に対して発行される。ステップ５０１では、要求されたディスパッチ・フラッシュで選択されたスレッドがＩＤＵ１３２からの命令グループをディスパッチしているかどうかのテストが実行される。選択されたスレッドが命令グループをディスパッチしていない場合、ディスパッチ・フラッシュは発行されず、分岐はステップ５０１の入力に戻される。選択されたスレッドが命令グループをディスパッチしている場合、ステップ５０２で、選択されたスレッド内のいずれかのグループ命令がマイクロ・コードであるか、スレッドが例外アドレスを必要とするか、またはＳＭＴモードが選択されていないかを判定するためのテストが実行される。ステップ５０２のテストの結果が「はい」の場合、ステップ５０４で、ディスパッチ・フラッシュは発行されない。ステップ５０２のテストの結果が「いいえ」の場合、ステップ５０３で、選択されたスレッドが進行中のいずれかのフラッシュを有するかどうかを判定するためのテストが実行される。ステップ５０３のテストの結果が「はい」の場合、ステップ５０４が再度実行される。ステップ５０３のテストの結果が「いいえ」の場合、ステップ５０５で、選択されたスレッドに関していずれかのタイプのフラッシュが起動されたかどうかを判定するためのテストが実行される。この時点で、何のフラッシュも起動されていない場合、ステップ５０６で、選択されたスレッドに関するディスパッチ・フラッシュがＩＤＵ１３２に対して発行される。ステップ５０５のテストの結果が「はい」の場合、ステップ５０４が再度実行され、選択されたスレッドに関するＩＤＵ１３２に対するディスパッチ・フラッシュは発行されない。

本発明を実施するための代表的なハードウェア環境が図４に示されており、これは、同時マルチスレッド（ＳＭＴ）処理を備えた中央処理ユニット（ＣＰＵ）４１０およびシステム・バス４１２を介して相互接続された他のいくつかのユニットを有する、本発明に従ったワークステーションの典型的なハードウェア構成を示すものである。図４に示されたワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）４１４と、読取り専用メモリ（ＲＯＭ）４１６と、ディスク・ユニット４２０およびテープ・ドライブ４４０などの周辺デバイスをバス４１２に接続するための入力／出力（Ｉ／Ｏ）アダプタ４１８と、キーボード４２４、マウス４２６、スピーカ４２８、マイクロフォン４３２、および／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・インターフェース・デバイスをバス４１２に接続するためのユーザ・インターフェース・アダプタ４２２と、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ４３４と、バス４１２をディスプレイ・デバイス４３８に接続するためのディスプレイ・アダプタ４３６とを含む。

以上、本発明およびその利点について詳細に説明してきたが、本明細書では、添付の特許請求の範囲に定義された本発明の精神および範囲を逸脱することなく、様々な変更、置換、および修正が可能であることを理解されたい。

まとめとして、本発明の構成に関して以下の事項を開示する。

（１）共用ディスパッチ・パイプラインを有するＳＭＴプロセッサにおいて命令流れを管理するための方法であって、前記方法は
第１のスレッドの第１の命令において例外条件を検出するステップを含み、前記第１の命令は、前記第１の命令に続く前記第１のスレッドの第２の命令のディスパッチを必要とするものであって、
さらに前記方法は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドの命令に関してディスパッチ・フラッシュ・オペレーションを発行するステップを含み、前記第２の命令は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドのブロック命令によってディスパッチをブロックされる方法。
（２）前記ブロック命令は、前記第１の命令が完了するまで解放されない前記第１の命令によって使用されるリソース要件を有することを理由に、前記第２の命令をブロックしている、請求項１に記載の方法。
（３）前記ブロック命令が、いずれかの命令が前記共用ディスパッチ・パイプラインからディスパッチされる前に合致しなければならない長い待ち時間の共用リソース要件を有するかどうかを判定するステップと、
前記第２のスレッドのフラッシュ済み命令が再フェッチされる時点、および前記フラッシュ済み命令中で選択された命令に応答して共用ディスパッチ・パイプラインに再入する時点を制御する、選択済みホールドを設定するホールド・コマンドを発行するステップとを含む、請求項１に記載の方法。
（４）前記選択済みホールドは、前記第２のスレッドの命令が、前記ディスパッチ・パイプライン内のディスパッチ待ち行列からフラッシュし、前記ディスパッチ待ち行列に入るが、前記ＣＬＢホールドが除去されるまでディスパッチされないことを可能にする、キャッシュ・ライン・バッファ（ＣＬＢ）ホールドである、請求項３に記載の方法。
（５）前記ブロック命令は、変換索引バッファ例外無効化（ＴｒａｎｓｌａｔｉｏｎＬｏｏｋＡｓｉｄｅＢｕｆｆｅｒＩｎｖａｌｉｄａｔｅＥｘｃｅｐｔｉｏｎ）命令またはＳｙｎｃ命令を含む、請求項３に記載の方法。
（６）共用ディスパッチ・パイプラインを有する同時マルチスレッド（ＳＭＴ）プロセッサであって、前記プロセッサは、
第１のスレッドの第１の命令において例外条件を検出するための回路を含み、前記第１の命令は、前記第１の命令に続く前記第１のスレッドの第２の命令のディスパッチを必要とするものであって、
さらに前記プロセッサは、前記共用ディスパッチ・パイプライン内の前記第２のスレッドの命令に関してディスパッチ・フラッシュ・オペレーションを発行する回路を含み、前記第２の命令は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドのブロック命令によってディスパッチをブロックされるプロセッサ。
（７）前記ブロック命令は、前記第１の命令が完了するまで解放されない前記第１の命令によって使用されるリソース要件を有することを理由に、前記第２の命令をブロックしている、請求項６に記載のプロセッサ。
（８）前記ブロック命令が、いずれかの命令が前記共用ディスパッチ・パイプラインからディスパッチされる前に合致しなければならない長い待ち時間の共用リソース要件を有するかどうかを判定するための回路と、
前記第２のスレッドのフラッシュ済み命令が再フェッチされる時点、および前記フラッシュ済み命令中で選択された命令に応答して共用ディスパッチ・パイプラインに再入する時点を制御する、選択済みホールドを設定するホールド・コマンドを発行するための回路とを含む、請求項６に記載のプロセッサ。
（９）前記選択済みホールドは、前記第２のスレッドの命令が、前記ディスパッチ・パイプライン内のディスパッチ待ち行列からフラッシュし、前記ディスパッチ待ち行列に入るが、前記ＣＬＢホールドが除去されるまでディスパッチされないことを可能にする、キャッシュ・ライン・バッファ（ＣＬＢ）ホールドである、請求項８に記載のプロセッサ。
（１０）前記ブロック命令は、変換索引バッファ例外無効化命令またはＳｙｎｃ命令を含む、請求項８に記載のプロセッサ。
（１１）１つまたは複数の同時マルチスレッド（ＳＭＴ）プロセッサを有する中央処理ユニット（ＣＰＵ）と、
ランダム・アクセス・メモリ（ＲＡＭ）と、
入力出力（Ｉ／Ｏ）アダプタと、
通信アダプタと、
前記ＣＰＵ、ＲＡＭ、Ｉ／Ｏアダプタ、および前記通信アダプタを結合するバスと、
第１のスレッドの第１の命令において例外条件を検出するための回路とを含む、データ処理システムであって、前記第１の命令は、前記第１の命令に続く前記第１のスレッドの第２の命令のディスパッチを必要とするものであって、
さらに前記データ処理システムは、前記共用ディスパッチ・パイプライン内の前記第２のスレッドの命令に関してディスパッチ・フラッシュ・オペレーションを発行する回路を含み、前記第２の命令は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドのブロック命令によってディスパッチをブロックされるデータ処理システム。
（１２）前記ブロック命令は、前記第１の命令が完了するまで解放されない前記第１の命令によって使用されるリソース要件を有することを理由に、前記第２の命令をブロックしている、請求項１１に記載のデータ処理システム。
（１３）前記ブロック命令が、いずれかの命令が前記共用ディスパッチ・パイプラインからディスパッチされる前に合致しなければならない長い待ち時間の共用リソース要件を有するかどうかを判定するための回路と、
前記第２のスレッドのフラッシュ済み命令が再フェッチされる時点、および前記フラッシュ済み命令中で選択された命令に応答して共用ディスパッチ・パイプラインに再入する時点を制御する、選択済みホールドを設定するホールド・コマンドを発行するための回路とを含む、請求項１１に記載のデータ処理システム。
（１４）前記選択済みホールドは、前記第２のスレッドの命令が、前記ディスパッチ・パイプライン内のディスパッチ待ち行列からフラッシュし、前記ディスパッチ待ち行列に入るが、前記ＣＬＢホールドが除去されるまでディスパッチされないことを可能にする、キャッシュ・ライン・バッファ（ＣＬＢ）ホールドである、請求項１３に記載のデータ処理システム。
（１５）前記ブロック命令は、変換索引バッファ例外無効化命令またはＳｙｎｃ命令を含む、請求項１３に記載のデータ処理システム。

本発明の実施形態に従ったＳＭＴプロセッサの機能ユニットを示すブロック図である。ＳＭＴプロセッサにおいて、命令グループをディスパッチする際に使用される方法のステップを示す流れ図である。本発明の実施形態に従った方法のステップを示す流れ図である。本発明を実施するための代表的なハードウェア環境を示す図である。ＳＭＴプロセッサにおいて、ディスパッチ・フラッシュ・オペレーションに使用される方法のステップを示す流れ図である。

符号の説明

１０１バス・インターフェース・ユニットＢＩＵ
１０２Ｄ−Ｃａｃｈｅ
１０３ＩＦＡＲ
１０４Ｉ−Ｃａｃｈｅ
１０８ＩＦＵ
１１３命令シーケンサ
１１４ＦＸＵ
１１５ＧＰＲファイル
ＧＰ名前変更バッファ
１１６ＬＳＵ
１１７ＦＰＲファイル
ＦＰ名前変更バッファ
１１８ＦＰＵ
１１９完了ユニット
１３１命令発行待ち行列
１３２ＩＤＵ
１３３スレッド・セレクタ
１３４プログラム・カウンタ
１３５待ち行列Ｔ０
１３６待ち行列Ｔ１
１３７スレッド優先順位セレクタ
１３９メモリ
１４０ディスパッチ段階
１５０レジスタ名前変更
４１０ＣＰＵ（ＳＭＴプロセッサ）
４１２バス

Claims

共用ディスパッチ・パイプラインを有し、複数のスレッドが共用リソース要件を共用するＳＭＴプロセッサにおいて命令流れを管理するための方法であって、前記方法は、
第１のスレッドの第１の命令において例外条件を検出するステップを含み、前記第１の命令は、前記第１の命令に続く前記第１のスレッドの第２の命令のディスパッチを必要とするものであって、
さらに前記方法は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドの命令に関してディスパッチ・フラッシュ・オペレーションを発行するステップを含み、前記第２の命令は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドが前記共用リソース要件を使用するために発行するブロック命令によってディスパッチをブロックされており、命令ディスパッチ・ユニット（ＩＤＵ）に対して前記ディスパッチ・フラッシュ・オペレーションを発行して前記第２のスレッドの命令をフラッシュすることにより、前記第１のスレッドの前記第２の命令をディスパッチする方法。
前記ブロック命令が、いずれかの命令が前記共用ディスパッチ・パイプラインからディスパッチされる前に合致しなければならない長い待ち時間の共用リソース要件を有するかどうかを判定するステップと、
前記第２のスレッドのフラッシュ済み命令が再フェッチされる時点、および前記フラッシュ済み命令中で選択された命令に応答して共用ディスパッチ・パイプラインに再入する時点を制御する、選択済みホールドを設定するホールド・コマンドを発行するステップとを含む、請求項１に記載の方法。
前記選択済みホールドは、前記第２のスレッドの命令が、前記ディスパッチ・パイプライン内のディスパッチ待ち行列からフラッシュし、前記ディスパッチ待ち行列に入るが、前記ＣＬＢホールドが除去されるまでディスパッチされないことを可能にする、キャッシュ・ライン・バッファ（ＣＬＢ）ホールドである、請求項２に記載の方法。
前記ブロック命令は、変換索引バッファ例外無効化（ＴｒａｎｓｌａｔｉｏｎＬｏｏｋＡｓｉｄｅＢｕｆｆｅｒＩｎｖａｌｉｄａｔｅＥｘｃｅｐｔｉｏｎ）命令またはＳｙｎｃ命令を含む、請求項２に記載の方法。
共用ディスパッチ・パイプラインを有し、複数のスレッドが共用リソース要件を共用する同時マルチスレッド（ＳＭＴ）プロセッサであって、前記プロセッサは、
第１のスレッドの第１の命令において例外条件を検出するための回路を含み、前記第１の命令は、前記第１の命令に続く前記第１のスレッドの第２の命令のディスパッチを必要とするものであって、
さらに前記プロセッサは、前記共用ディスパッチ・パイプライン内の前記第２のスレッドの命令に関してディスパッチ・フラッシュ・オペレーションを発行する回路を含み、前記第２の命令は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドが前記共用リソース要件を使用するために発行するブロック命令によってディスパッチをブロックされており、命令ディスパッチ・ユニット（ＩＤＵ）に対して前記ディスパッチ・フラッシュ・オペレーションを発行して前記第２のスレッドの命令をフラッシュすることにより、前記第１のスレッドの前記第２の命令をディスパッチするプロセッサ。
前記ブロック命令が、いずれかの命令が前記共用ディスパッチ・パイプラインからディスパッチされる前に合致しなければならない長い待ち時間の共用リソース要件を有するかどうかを判定するための回路と、
前記第２のスレッドのフラッシュ済み命令が再フェッチされる時点、および前記フラッシュ済み命令中で選択された命令に応答して共用ディスパッチ・パイプラインに再入する時点を制御する、選択済みホールドを設定するホールド・コマンドを発行するための回路とを含む、請求項５に記載のプロセッサ。
前記選択済みホールドは、前記第２のスレッドの命令が、前記ディスパッチ・パイプライン内のディスパッチ待ち行列からフラッシュし、前記ディスパッチ待ち行列に入るが、前記ＣＬＢホールドが除去されるまでディスパッチされないことを可能にする、キャッシュ・ライン・バッファ（ＣＬＢ）ホールドである、請求項６に記載のプロセッサ。
前記ブロック命令は、変換索引バッファ例外無効化命令またはＳｙｎｃ命令を含む、請求項６に記載のプロセッサ。
１つまたは複数の同時マルチスレッド（ＳＭＴ）プロセッサを有する中央処理ユニット（ＣＰＵ）と、
ランダム・アクセス・メモリ（ＲＡＭ）と、
入力出力（Ｉ／Ｏ）アダプタと、
通信アダプタと、
前記ＣＰＵ、ＲＡＭ、Ｉ／Ｏアダプタ、および前記通信アダプタを結合するバスと、
第１のスレッドの第１の命令において例外条件を検出するための回路とを含む、データ処理システムであって、前記第１の命令は、前記第１の命令に続く前記第１のスレッドの第２の命令のディスパッチを必要とするものであって、
さらに前記データ処理システムは、前記共用ディスパッチ・パイプライン内の前記第２のスレッドの命令に関してディスパッチ・フラッシュ・オペレーションを発行する回路を含み、前記第２の命令は、前記共用ディスパッチ・パイプライン内の前記第２のスレッドが共用リソース要件を使用するために発行するブロック命令によってディスパッチをブロックされており、命令ディスパッチ・ユニット（ＩＤＵ）に対して前記ディスパッチ・フラッシュ・オペレーションを発行して前記第２のスレッドの命令をフラッシュすることにより、前記第１のスレッドの前記第２の命令をディスパッチするデータ処理システム。
前記ブロック命令が、いずれかの命令が前記共用ディスパッチ・パイプラインからディスパッチされる前に合致しなければならない長い待ち時間の共用リソース要件を有するかどうかを判定するための回路と、
前記第２のスレッドのフラッシュ済み命令が再フェッチされる時点、および前記フラッシュ済み命令中で選択された命令に応答して共用ディスパッチ・パイプラインに再入する時点を制御する、選択済みホールドを設定するホールド・コマンドを発行するための回路とを含む、請求項９に記載のデータ処理システム。
前記選択済みホールドは、前記第２のスレッドの命令が、前記ディスパッチ・パイプライン内のディスパッチ待ち行列からフラッシュし、前記ディスパッチ待ち行列に入るが、前記ＣＬＢホールドが除去されるまでディスパッチされないことを可能にする、キャッシュ・ライン・バッファ（ＣＬＢ）ホールドである、請求項１０に記載のデータ処理システム。
前記ブロック命令は、変換索引バッファ例外無効化命令またはＳｙｎｃ命令を含む、請求項１０に記載のデータ処理システム。