JP3048910B2 - 命令スレッドを処理するための方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的には情報処
理システムに関し、より具体的には命令スレッドを処理
するための方法に関する。

【０００２】

【従来の技術】市販のマイクロプロセッサは、現在、単
一プロセッサ・アーキテクチャを使用している。このア
ーキテクチャは、共通する１組のアーキテクチャ上可視
のレジスタを共用する１つまたは複数の機能ユニット
（分岐ユニット、ロード／ストア・ユニット、整数演算
ユニット、浮動小数点演算ユニットなど）を含むことが
できる。（レジスタは、そのプロセッサのアセンブリ・
レベルのプログラマか、またはより上位レベルのプログ
ラムをマシンのアセンブリ・レベルに変換するプロセッ
サのコンパイラにとってアクセス可能であれば、アーキ
テクチャ上可視であると見なされる。）

【０００３】コンピュータ・システムでは、コンパイラ
またはアセンブリ・プログラマにより生成された命令
は、実行時以前に命令メモリに１つのシーケンスとして
置かれ、そこから取り出して実行することができる。こ
のシーケンスは静的順序と呼ばれている。動的順序は、
コンピュータがこのような命令を実行する順序である。
動的順序は静的順序である場合もあれば、そうではない
場合もある。（以下の説明で使用する「コンパイル時」
という表現は、実行時以前の処理のタイミングを意味す
る。ただし、このような処理はコンパイラによって行わ
れる可能性が非常に高いが、アセンブリ・レベル・プロ
グラミングなどの他の手段が代わりに使用されることも
あることに留意されたい。）

【０００４】先行技術のスカラー・コンピュータすなわ
ち非スーパースカラー・コンピュータ、または一度に１
つずつ命令を実行するマシンには、順次追跡順序と呼ば
れる固有の動的実行順序が備わっている。この順次追跡
順序で命令Ａを別の命令Ｂより先行させると、このよう
な命令Ａは、命令Ｂより早期の命令とも呼ばれる。この
ようなコンピュータは、制御命令が検出されるまで、そ
の静的順序で命令を実行する。この検出時点では、元の
順次順序から外れた（不連続）位置から命令を取り出す
ことができる。その後、次の制御命令が検出されるま
で、命令はもう一度、静的順次順序で実行される。制御
命令とは、以降の命令取出しを不連続位置から強制的に
始めさせることにより、順次命令取出しを変更する可能
性のある命令である。制御命令としては、分岐、ジャン
プなどの命令がある。

【０００５】先行技術のマシンの中には、プログラムの
依存関係に違反しなければ、順次追跡順序から外れた命
令を実行できるものもある。このようなマシンは、順次
追跡順序の順に命令を取り出すか、または順次追跡順序
で同時に命令グループを取り出す。しかし、このような
マシンは、順次追跡順序から外れた命令を取り出すこと
はしない。たとえば、順次追跡順序で命令Ａが命令Ｂよ
り先行する場合、先行技術のマシンでは、命令Ａの次に
命令Ｂを順に取り出すか、または命令ＡとＢを同時に取
り出すことができるが、命令Ａより前に命令Ｂを取り出
すことはない。このような制約は単一プログラム・カウ
ンタを備えたマシンの特徴である。したがって、このよ
うな制約のあるマシンは、単一スレッドまたはユニスレ
ッド・マシンと言われている。このようなマシンは、順
次追跡順序で先行する命令を取り出す前に順次追跡順序
で後続の命令を取り出すことができない。

【０００６】発明者らが把握している現行世代の市販マ
イクロプロセッサは、単一スレッドの制御の流れを備え
ている。このようなプロセッサは、所与のプログラムの
様々な部分の制御とデータからの独立性を活用する能力
が制限されている。重要な制限としては、以下のものが
ある。 ○ 単一スレッドとは、マシンが複数の命令からなる単
一シーケンスの取出しに制限され、プログラム制御の複
数の流れ（スレッド）を同時に追跡できないことを意味
する。 ○ さらに単一スレッド制御とは、データ非依存命令が
まとめて取り出すべきスレッド内で時間的に十分接近し
ていて（たとえば、複数の命令を命令バッファに同時に
取り出す場合）、データ独立性を検出するためにまとめ
て検査される場合のみ、データ独立性を活用できること
を意味する。 ○ 上記の制限は、制御非依存命令とデータ非依存命令
をまとめてグループ化するためにコンパイラを頼りにす
ることを意味する。 ○ 先行技術のマイクロプロセッサの中には、制御流れ
予測という何らかの形態の制御命令（分岐）予測を含む
ものがある。この場合、制御命令の結果が正しく予測さ
れたと期待して、順次追跡順序で制御命令に続く命令を
取り出して実行することができる。制御流れの予測は、
より高度の並列性を活用するために必要な技法としてす
でに認められている。しかし、制御への依存性に関する
知識が欠けているため、単一スレッド動的予測は、制御
流れ予測誤り（不良予測）が発生するまで先読みする能
力しか拡張することができない。不良予測が行われる
と、多くの実行サイクルが浪費される可能性がある。制
御依存性分析のハードウェア・コストを無視しても、単
一スレッド制御流れ予測により制御への依存性を実行時
に学習することはよく見ても適用範囲が制限されること
に留意されたい。ここで使用する適用範囲とは、命令間
の制御およびデータの依存関係を同時に検査することが
できる命令の数を意味する。通常、実行時よりコンパイ
ル時に得られる適用範囲の方がかなり大きくなる可能性
がある。 ○ 制御流れに関するコンパイル時予測は、実行時予測
より適用範囲がかなり大きくなる可能性があるが、制御
依存性分析から利益を得る場合もある。しかし、単一ス
レッドの実行時制限により、コンパイラは、実行時に並
列性が活用可能になるように非予測命令とともに予測命
令をまとめてグループ化する必要がある。

【０００７】実行時により多くの並列性を発揮するため
にコンパイル時制御流れ予測を使用することについて
は、上記に述べた。現行マシンのコンパイラは、この予
測をコード化する能力が制限されている。保護（Guar
d）と格上げ（Boost）のような一般に使用される手法で
は、単一スレッド実行の早期に予測実行すべき一部の命
令をパーコレーションするためにコンパイラを頼りにし
ている。また、このような手法では、制御流れ予測を予
測命令にコード化する必要もある。この手法には、次の
ような重要な制限がある。ここで、保護（Guard）と格
上げ（Boost）とは、Smith, Lam, Horowitz著、「Boost
ing Beyond Static Scheduling in a Superscalar Proc
essor」、ISCA 1990に記載されており、これは静的な予
測情報を分岐命令の中に織り込み、シャドウ・レジスタ
を用意しておいて分岐命令を実行して先に進み、結果を
シャドウ・レジスタ二か苦悩し、分岐条件が成立すれば
シャドウ・レジスタの内容を実レジスタにうつし、成立
しなければシャドウ・レジスタの内容を破棄する動作で
ある。また、パーコレーションとは、コンパイル時に命
令コードのストリームにおいてある命令コードを早めに
実行するように順序づけることを言う。 ○ 通常、かなり浅い制御流れ予測をコード化するため
にすべての命令で十分な未使用ビットを見つけることは
非常に難しいことである。逆方向互換性の制約（いかな
る変換も行わずに古い２進コードを実行できる能力）が
あるため、制御流れ予測のコード化を含めるために命令
コード化を任意に再配置（新しいアーキテクチャを意味
する）することができないことに留意されたい。 ○ 前述のパーコレーション技法は、予測誤りを処理す
るために余分なコードまたはコード・コピーあるいはそ
の両方を必要とする場合が多い。その結果、コードが拡
大する。 ○ アーキテクチャ上、予測命令によって発生する例外
の順次処理や、割込みの精密処理が必要になる場合が多
い。しかし、前述のパーコレーション技法は上方予測コ
ード・モーションを使用するので、このような順序外予
測実行のコンテキストでこれらを実施することは非常に
難しい場合が多い。パーコレーションした命令を区別
し、その元の位置を追跡するには、特殊な機構が必要で
ある。ただし、外部割込みの観点から見ると、精密割込
み処理の制約下では順次追跡順序から外れた命令実行は
予測的と見なすことができることに留意されたい。しか
し、制約はあるもののより広く使用される意味では、命
令（より正確には、その命令の特定の動的インスタン
ス）が順次追跡順序の一部であると設定する前に命令処
理が開始される場合、またはある命令のオペランドの妥
当性を確立する前にそのオペランドが提供される場合
に、実行が予測的と見なされる。

【０００８】制御依存性を知らないと、ネストされたル
ープのパフォーマンスにとって特に高価なものになる場
合がある。たとえば、外側反復がデータ依存の内側ルー
プ反復とは無関係の制御とデータであるようなネストさ
れたループについて検討する。外側ループ反復とは無関
係の制御およびデータの知識が活用されない場合は、内
側ループに関する順次制御流れ予測のため、その取出し
および実行を遅延させなければならない。さらに、この
ように制御依存性の知識が欠けているため、制御および
データ非依存の内側ループ反復の１つの予測を誤ったと
きに、外側ループから予測実行される命令を不必要に破
棄する場合もある。また、内側ループの制御流れがデー
タに依存し、そのため、極めて予測不能である場合に
は、内側ループの制御流れ予測について予測誤りが発生
する確率が非常に高くなる可能性があることにも留意さ
れたい。このような例としては、以下のものがある。

【０００９】/* 環境リストを検査する */ for (fp = xlenv; fp; fp = cdr (fp) ) for (ep = car (fp); ep; ep = cdr (ep) ) if (sym == car (car (ep) ) ) cdr (car (ep) ) = new_p;

【００１０】これは二重にネストされたループであっ
て、内側ループは連係リストを詳しく検討し、その反復
はどちらも前の反復に依存する制御とデータである。し
かし、内側ループのそれぞれの活動化（すなわち、外側
ループの反復）は前の反復とは無関係である。［これ
は、SPECint92ベンチマークの１つ（Li）で最も頻繁に
実行されるループの１つ（Xlgetvalue）をわずかに変更
したバージョンである。］

【００１１】前述のように、単一制御流れを備えたマシ
ンは、予測または非予測あるいはその両方のデータ非依
存命令をまとめてグループ化するためにコンパイラに頼
らなければならない。しかし、すべてのデータおよび制
御非依存命令を効率よくまとめてグループ化するには、
コンパイラは、適切なコード化のためにアーキテクチャ
化した十分なレジスタを必要とする。このため、レジス
タ圧力は高まり、追加のスピル・コードのオーバヘッド
のためにこのようなコード・モーションが実を結ばなく
なるような点を上回っている。ここで、スピルとは、あ
るプログラムが現に利用可能なレジスタより多くのレジ
スタを必要とするとき、データを利用可のなレジスタに
現にあるデータと入れ替えてこのレジスタを使用する事
である。これはスピル・ロードと言われる。

【００１２】大規模並列アーキテクチャの実現を主な目
的とする、複数スレッドを備えたプロセッサを構築する
ために、研究の試みがいくつか行われてきた。複数スレ
ッドを管理するというオーバヘッドは、実行の並行性が
追加されるというパフォーマンス上の利得を潜在的に上
回る可能性がある。スレッド管理に関連するオーバヘッ
ドとしては、以下のものがある。 ○ 明示または暗黙同期プリミティブによる、データお
よび制御依存性のための部分順序の管理と通信 ○ 別のスレッドが使用するためにあるスレッドが生成
した値の通信 ○ 静的すなわちコンパイル時のスレッド・スケジュー
リングと、動的すなわち実行時のスレッド・スケジュー
リングとの対照に関連するトレードオフ。静的スレッド
・スケジューリングは、実行時のハードウェアを簡略化
するが、フレキシビリティが低く、実現したマシンのス
レッド資源をコンパイラに公表してしまうため、各種の
実施態様に対応する再コンパイルを必要とする。これに
対して、動的スレッド・スケジューリングは様々な実施
態様に適応可能で、いずれも同じ実行可能命令を共用す
るが、追加の実行時ハードウェア・サポートを必要とす
る。

【００１３】さらに詳述する前に、以下の一連の作業用
定義は非常に有用である。 ○ スレッド：単一命令順序付け制御（単一プログラム
・カウンタを意味するが、必ずしもそれを必要としな
い）と共用される１組のアーキテクチャ上可視のマシン
状態とを使用して実行可能な命令のシーケンス。 ○ 順次追跡順序：プログラム命令の実行シーケンスの
動的順序であって、一度に１つずつ命令を実行する単一
制御スレッド非予測マシン上でそのプログラムを完全実
行した結果得られるもの。 ○ メイン・スレッドと将来スレッド：所与の時点での
１組のスレッドのうち、順次追跡順序で最も早い命令を
実行するスレッドをメイン・スレッドという。残りのス
レッドは将来スレッドという。

【００１４】

【発明が解決しようとする課題】命令スレッドを処理す
るための方法およびシステムにおいて、特定の命令を含
む第１組の命令の実行が処理システムによって開始され
る。特定の命令は第２組の命令の指示を含む。特定の命
令の実行と、第１のタイプである処理システムとに応答
して、処理システムは、第２組の実行を開始しながら第
１組の実行を続行する。特定の命令の実行と、第２のタ
イプである処理システムとに応答して、処理システム
は、第２組の実行を開始せずに第１組の実行を続行す
る。

【００１５】

【課題を解決するための手段】本発明の技術的利点の１
つは、既存の命令セット・アーキテクチャ（「ＩＳ
Ａ」）の基本概念によって整合性が達成される点であ
る。

【００１６】本発明のもう１つの技術的利点は、ＩＳＡ
間で順方向および逆方向互換性が達成される点である。

【００１７】本発明の実施例およびその利点は、以下の
説明と添付図面を参照することによりさらによく理解さ
れる。

【００１８】

【発明の実施の形態】本発明の実施例およびその利点
は、添付図面の図１ないし図２４を参照することにより
さらによく理解される。添付図面の同様の部分および対
応部分には、同様の英数字が使用されている。

【００１９】本発明の一目的は、様々な命令スレッドを
同時に取り出して実行するための改良された方法および
装置である。

【００２０】本発明の一目的は、１つまたは複数の制御
およびデータ依存関係を備えた様々な命令スレッドを同
時に取り出して実行するための改良された方法および装
置である。

【００２１】本発明の一目的は、１つまたは複数の制御
およびデータ依存関係を備えた様々な命令スレッドを同
時に取り出して予測実行するための改良された方法およ
び装置である。

【００２２】本発明の一目的は、コンピュータ・アーキ
テクチャの様々な実施態様上で１つまたは複数の制御お
よびデータ依存関係を備えた様々な命令スレッドを同時
に取り出して予測実行するための改良された方法および
装置である。

【００２３】本発明は、複数の命令スレッドの予測並列
実行を可能にする、コンピュータ内の中央演算処理装置
（ＣＰＵ）の改良策である。本発明では、ＣＰＵの命令
セットに追加され、並列実行のために潜在的将来スレッ
ドを示すために実行時以前にプログラムに挿入される、
新規のフォーク−中断命令を開示する。これは、コンパ
イラによって実行されることが好ましい。

【００２４】ＣＰＵは、１つまたは複数の命令キャッシ
ュ・ポートを備えた命令キャッシュと、その命令キャッ
シュ内の命令を独立してアドレス指定できる１つまたは
複数のプログラム・カウンタからなるバンクとを有す
る。プログラム・カウンタが１つの命令をアドレス指定
すると、アドレス指定された命令は、命令キャッシュ・
ポートにポートされる。さらにＣＰＵは、１つまたは複
数のディスパッチャも有する。ディスパッチャは、命令
キャッシュ・ポートにポートされた命令をそのディスパ
ッチャに関連する命令バッファで受け取る。また、ディ
スパッチャは、そのバッファ内の命令間の依存関係も分
析する。ＣＰＵ内のスレッド管理ユニットは、すべての
スレッド間通信を管理し、プログラム依存関係に違反す
る将来スレッドを破棄する。ＣＰＵスケジューラは、Ｃ
ＰＵ内のすべてのディスパッチャから命令を受け取り、
ＣＰＵ内の１つまたは複数の機能ユニットでの命令の並
列実行をスケジューリングする。通常、メイン・プログ
ラム・スレッド内の命令の実行は１つのプログラム・カ
ウンタが追跡し、将来スレッドの並列実行は残りのプロ
グラム・カウンタが追跡することになる。命令のポーテ
ィングとその機能ユニット上での実行は、予測方式で実
行することができる。

【００２５】本発明は、複数のプログラム位置からの命
令を同時に取り出して、予測し、実行し、その結果、複
数の制御スレッドを追跡するように従来の単一スレッド
予測スーパースカラーＣＰＵを強化するために、フォー
ク−中断命令を提案している。

【００２６】図１は、本発明で提案した方法を実行する
と思われる典型的なプロセッサ編成のハードウェアのブ
ロック図である。実行方法については、後述する。図１
の詳細説明は以下の通りである。

【００２７】ブロック１００は、プロセッサ上で実行す
るためのプログラム・データおよび命令を保持する、プ
ロセッサの中央演算処理装置（ＣＰＵ）のメモリ・ユニ
ットである。このメモリ・ユニットは、このメモリ・ユ
ニットの頻繁に使用する命令およびデータ部分が通常、
命令キャッシュ・ユニット（ブロック１１０）とデータ
・キャッシュ・ユニット（ブロック１７０）にそれぞれ
保管されるように、キャッシュ・ユニットとのインタフ
ェースが取られている。あるいは、命令キャッシュとデ
ータ・キャッシュは、単一一体化ユニットに統合するこ
とができる。キャッシュ・ユニットのアクセス時間は、
通常、メモリ・ユニットのアクセス時間よりかなり短
い。上記のようなメモリ・ユニットとキャッシュ・ユニ
ットは当技術分野では周知のものである。たとえば、メ
イン・メモリとそのポートをキャッシュ・メモリとその
ポートに使用することにより、キャッシュ・ユニットを
置き換えることができる。また、キャッシュは、周知の
ように、複数のキャッシュまたは１つまたは複数のレベ
ルを備えたキャッシュで構成することもできる。

【００２８】ブロック１１０は、プロセッサ上で実行す
るためのプログラム命令を保持する、プロセッサ（ＣＰ
Ｕ）の命令キャッシュ・ユニットである。これは、FOR
K、SKIP、SUSPEND、UNCOND_SUSPEND（ブロック１１２）
など、本発明で提案した新しい命令を含む。上記および
その他の新しい命令の意味の詳細については、後述す
る。

【００２９】命令キャッシュの複数ポートＰ１、Ｐ２、
・・・、ＰＮ（ブロック１１５−１、１１５−２、・・
・、１１５−Ｎ）を含むブロック１１５は、現行技術で
は新規のものである。この複数ポートにより、並列実行
される命令スレッドへの命令の同時ポーティングが可能
になる。あるいは、単一幅広ポートを使用して所与のス
レッドに複数の命令をポートし、そのスレッドがポート
された命令を実行していて使用中の間に、同じポートを
使用して、複数の命令を別のスレッドにポートすること
も可能である。

【００３０】ブロック１２０は、プログラム・カウンタ
ＰＣ１、ＰＣ２、・・・、ＰＣＮ（ブロック１２０−
１、１２０−２、・・・、１２０−Ｎ）からなるバンク
である。これらのカウンタは、当技術分野で周知であれ
ば、どのカウンタであってもよい。それぞれのプログラ
ム・カウンタは所与のスレッドの実行を追跡する。現在
までに設計されたすべての商用ＣＰＵは、所与のプログ
ラムについて、単一命令スレッドの実行だけを制御する
必要がある。このため、現行技術および従来技術は単一
プログラム・カウンタに制限されており、したがって、
複数プログラム・カウンタからなるバンクは本発明の新
規の態様である。それぞれのプログラム・カウンタは、
命令キャッシュ内の１つまたは複数の連続命令をアドレ
ス指定することができる。図１および図２のブロック図
に示す好ましい実施例では、それぞれのプログラム・カ
ウンタが１つの命令キャッシュ・ポートに関連づけられ
ている。あるいは、各種のプログラム・カウンタが１つ
の命令キャッシュ・ポートを共用することもできる。

【００３１】さらに、好ましい実施例では、特定のプロ
グラム・カウンタがメイン・スレッドに関連づけられ、
残りのプログラム・カウンタが将来スレッドの実行を追
跡する。図１のＰＣ１（ブロック１２０−１）は、メイ
ン・スレッド・プログラム・カウンタである。残りのプ
ログラム・カウンタは、将来スレッド・プログラム・カ
ウンタ（ブロック１２０−２、・・・、１２０−Ｎ）と
呼ぶ。

【００３２】ブロック１３０は新規のスレッド管理（Ｔ
Ｍ）ユニットを示しているが、これは、新しいスレッド
をフォークすることができる新しい命令の実行と、組合
せプロセス（後述する）によるスレッド間通信の処理と
を担当する。

【００３３】また、このユニットは、１つまたは複数の
将来スレッドの命令の一部または全部を破棄することも
できる。さらにこのユニットは、１つまたは複数の予測
の結果として、いずれかの将来スレッドが実行した１つ
または複数の命令をプログラム依存関係の違反のために
破棄する必要があるかどうかを判定することもできる。
実行時に予測が行われる場合は、予測ユニットによって
ＴＭユニットにそれが連絡される。たとえば、ディスパ
ッチャ・ブロック（後述するブロック１４０）内の分岐
命令結果の予測は、ＴＭユニットに連絡する必要があ
る。コンパイル時に予測が行われ、命令としてコード化
される場合は、このような命令をデコードするブロック
１４０のディスパッチャによってそれがＴＭユニットに
連絡される。その結果、予測方式で複数スレッドを実行
できるようになることは、本発明の固有の特徴である。

【００３４】また、メイン・スレッドと将来スレッドの
並列取出しおよび実行とは、提案したマシンがその順次
追跡順序から外れる命令を取り出して実行できることを
意味することにも留意されたい。このマシンのこのよう
な固有の特徴により、単一プログラム・カウンタのため
にその順次追跡順序から外れる命令を取り出すことがで
きない先行技術のマシンとは区別される。

【００３５】ブロック１４０は、ディスパッチャ−１、
ディスパッチャ−２、・・・、ディスパッチャ−Ｎ（ブ
ロック１４０−１、１４０−２、・・・、１４０−Ｎ）
という複数のディスパッチャからなるバンクを示し、そ
れぞれのディスパッチャは１つの特定のプログラム・カ
ウンタに関連づけられ、その結果、そのディスパッチャ
に関連する命令バッファ（ブロック１４１−１、１４１
−２、・・・、１４１−Ｎ）で命令キャッシュ・ポート
の１つから命令を受け取ることができる。また、ディス
パッチャは、そのバッファ内の命令間の依存関係をデコ
ードして分析することもできる。さらにディスパッチャ
は、後述するSKIP、FSKIP、またはSKPMGの各命令の意味
の実現も担当する。

【００３６】ディスパッチャが検出する命令は、スレッ
ドをフォークまたは中断することができるが、スレッド
管理ユニット（ブロック１３０）に転送される。このＴ
Ｍユニットは、対応するプログラム・カウンタに適切な
開始命令をロードすることにより、将来スレッドの活動
化を担当する。また、ＴＭユニットは、UNCOND_SUSPEND
命令を検出したときに将来スレッド・ディスパッチャを
中断する。

【００３７】順序外実行のための実行時依存性分析の実
施技法は、当技術分野では周知である。メイン・プログ
ラム・カウンタに関連し、そのため、メイン・スレッド
に関連するディスパッチャは、メイン・スレッド・ディ
スパッチャと呼ばれる。図１のディスパッチャ−１（ブ
ロック１４０−１）はメイン・スレッド・ディスパッチ
ャである。残りのディスパッチャ（ブロック１４０−
２、・・・、１４０−Ｎ）は将来プログラム・カウンタ
および将来スレッドに関連し、将来スレッド・ディスパ
ッチャと呼ばれる。

【００３８】本発明で提案するディスパッチャのバンク
の新規の態様は、１つのディスパッチャのバッファ内の
命令の実行時依存性分析を他のディスパッチャのものと
は無関係に（したがって並列に）実行できる点である。
これは、指定の条件下で命令スレッドの非依存性を保証
することができるコンパイル時依存性分析によって可能
になる。したがって、一方で、実行時依存性分析はコン
パイル時分析の方が潜在的に適用範囲がかなり広いこと
による恩恵を受けることになる（適用範囲が広いという
ことは、相互依存性について多数の命令を同時に検査で
きる能力を意味する）。もう一方で、コンパイル時分析
はフォーク−中断機構による恩恵を受けるが、この機構
により実行時結果に関する予測によって独立スレッドを
明示的に識別することができる。実行時またはコンパイ
ル時の依存性分析技法は当技術分野では周知であるが、
実行時依存性分析ハードウェアにコンパイル時依存性分
析を明示予測方式で連絡することは、本発明の新規な点
である。

【００３９】ブロック１５０は、ディスパッチャのバン
ク（ブロック１４０）内のすべてのディスパッチャから
命令を受け取って、機能ユニット（ブロック１８０）の
１つで実行するためにそれぞれの命令をスケジューリン
グする、スケジューラである。１つまたは複数のディス
パッチャから同一サイクル中に受け取ったすべての命令
は、互いに独立していると想定する。このようなスケジ
ューラも、スーパースカラー・マシンの先行技術では周
知である。代替実施例では、このスケジューラを１組の
スケジューラに分割し、それぞれが機能ユニット（ブロ
ック１８０）の規定のサブセットを制御するようにする
こともできる。

【００４０】ブロック１６０は、１組のレジスタ・セッ
トを含むレジスタ・ファイルである。このセットは、ア
ーキテクチャ上可視のレジスタ・セットと、アーキテク
チャ上不可視のレジスタとにさらに分割される。アーキ
テクチャ上可視すなわちアーキテクチャ化したレジスタ
とは、マシンのアセンブリ・レベルのプログラマ（また
はコンパイラ）にとってアクセス可能なレジスタの固定
セットを意味する。レジスタ・ファイルのアーキテクチ
ャ上可視のサブセットは、通常、すべてのスレッド（メ
イン・スレッドと将来スレッド）に共通するはずであ
る。アーキテクチャ上不可視のレジスタはＣＰＵの様々
な物理レジスタを含み、そのサブセットはアーキテクチ
ャ化したレジスタにマッピングされる。すなわち、アー
キテクチャ化したレジスタに関連する値を含む。レジス
タ・ファイルは、多くの命令を実行するための機能ユニ
ットにオペランドを提供し、実行の結果も受け取る。こ
のようなレジスタ・ファイルは先行技術では周知であ
る。

【００４１】組合せプロセス（後述する）の実施態様の
一部として、ＴＭユニット（ブロック１３０）はレジス
タ・ファイルとやりとりし、組合せ後にすべてのアーキ
テクチャ化したレジスタが適切な非アーキテクチャ化物
理レジスタに関連づけられるようにする。

【００４２】ブロック１７０は、命令によってソース・
オペランドとして使用されるデータ値の一部と、実行さ
れた命令によって生成されるデータ値の一部とを保持す
る、プロセッサのデータ・キャッシュ・ユニットであ
る。複数の機能ユニットが複数のメモリ常駐データ値を
同時に要求し、複数のメモリ束縛結果を同時に生成する
可能性があるので、データ・キャッシュは通常、マルチ
ポート化されているはずである。マルチポート化データ
・キャッシュは先行技術では周知である。

【００４３】ブロック１８０は、複数の機能ユニット
（機能ユニット−１、機能ユニット−２、機能ユニット
−Ｋ）からなるバンクであり、それぞれのユニットは一
部またはすべてのタイプの命令を実行することができ
る。機能ユニットは、レジスタ・ファイル（ブロック１
６０）またはデータ・キャッシュ（ブロック１７０）か
ら入力ソース・オペランドを受け取り、そこに出力結果
を書き込む。図１および図２に示す好ましい実施例で
は、すべての機能ユニットが同一であり、そのため、ど
のような命令も実行することができる。あるいは、バン
ク内の複数の機能ユニットを非対称にして、特定のユニ
ットが所与のサブセットの命令だけを実行できるように
することもできる。スケジューラ（ブロック１５０）
は、この非対称を認識し、適切に命令をスケジューリン
グする必要がある。このようなトレードオフも先行技術
では一般的である。

【００４４】ブロック１９０は、アーキテクチャによっ
て有効な順序と見なされる順序での命令実行の完了を担
当する命令完了ユニットである。ＣＰＵが順序外の命令
を実行できるとしても、それを同一順序で完了できるか
どうかは、アーキテクチャ上の制約による。将来スレッ
ド・ディスパッチャによる実行のためにスケジューリン
グされた命令は、予測スレッドの場合にＴＭユニット
（ブロック１３０）が将来スレッドの妥当性を確認した
あとでのみ、完了ユニットによる完了の対象となる。

【００４５】本発明では、コンパイル時に命令シーケン
スに挿入可能な新しい命令をいくつか提案する。このよ
うな命令の意味の詳細は以下の通りである。

【００４６】１．FORK この命令は、１つまたは複数の命令スレッドの開始アド
レス（複数も可）を識別する。識別されたそれぞれの命
令スレッドは将来スレッドと呼ばれる。このような将来
スレッドは、FORKのあとに順に続く一連の命令シーケン
スを引き続き実行するフォーキング・スレッドと同時に
実行することができる。将来スレッド用の開始ＣＰＵ状
態は、FORK命令を検出した時点のＣＰＵ状態のコピーで
ある。

【００４７】２．UNCOND_SUSPEND（無条件中断） この命令を検出すると、将来スレッドは、無条件にその
スレッドを中断し、フォーキング・スレッドとの組合せ
を待たなければならない。これは、たとえば、無条件中
断命令後の命令が別のスレッド上の何らかの命令との重
要なデータ依存性を有する場合に必要になる可能性があ
る。提案したこの命令は他のいかなる属性も必要としな
いので、SUSPEND命令（後述する）とも組み合わせるこ
とが可能である。すなわち、SUSPEND命令のコード化の
１つは単に無条件中断を指定することができるだけにな
る。

【００４８】３．SUSPEND（中断） この命令を検出すると、将来スレッドは、引き続きその
命令取出しと実行を続行することができるが、第１のSU
SPEND命令に関連するコンパイル時指定条件が実行時に
偽と評価された場合は、そのプログラムの順次追跡順序
での第１のSUSPEND命令と第２のSUSPEND命令またはUNCO
ND_SUSPEND命令との間の一連の命令シーケンスの結果が
破棄される。

【００４９】以下の命令を簡略化するため、SUSPEND命
令の依存領域という用語は、SUSPEND命令後の最初の命
令から始まり、他のSUSPEND命令を検出した時点またはU
NCOND_SUSPEND命令を検出時点に終了する、順次追跡順
序での一連の命令シーケンスであると定義する。

【００５０】４．SKIP この命令を検出すると、将来スレッドは、次のコンパイ
ル時指定数の命令（通常はスピル・ロード）をデコード
するだけで、対応するソース・レジスタと宛先レジスタ
に有効のマークを付けることによってこれらの命令の実
行を引き受けることができるが、このスレッドはその命
令に関連する動作を実際に実行する必要はない。メイン
・スレッドはこの命令をＮＯＰとして取り扱う。

【００５１】５．FORK_SUSPEND（FORK−中断） この命令の命令コードは、将来スレッドの先頭を識別す
るアドレスと、一連の数値（Ｎ１、Ｎ２、・・・、Ｎ
ｎ）とに関連づけられ、それぞれの数値には条件が付い
ている場合もあれば付いていない場合もある。所与の一
連のｎ個の数値は、FORK命令に関連するアドレスから始
まる命令のｎ個の連続グループを意味する。関連条件が
一切付いていない数値は、対応するグループの命令を将
来スレッドとして無条件に実行できることを意味する。
関連条件が付いている数値は、コンパイル時指定条件が
実行時に真と評価された場合のみ、対応するグループの
命令の将来スレッドによる実行が有効になるはずである
ことを意味する。

【００５２】６．FORK_S_SUSPEND この命令の命令コードは、将来スレッドの先頭を識別す
るアドレスと、数値ｓと、一連の数値（Ｎ１、Ｎ２、・
・・、Ｎｎ）とに関連づけられ、それぞれの数値には条
件が付いている場合もあれば付いていない場合もある。
所与の一連のｎ個の数値は、FORK命令に関連するアドレ
スから始まる命令のｎ個の連続グループを意味する。関
連条件が一切付いていない数値は、対応するグループの
命令を将来スレッドとして無条件に実行できることを意
味する。関連条件が付いている数値は、コンパイル時指
定条件が実行時に真と評価された場合のみ、対応するグ
ループの命令の将来スレッドによる実行が有効になるは
ずであることを意味する。関連数値ｓは、スレッドの先
頭にあるｓ個の命令を意味するが、これらの命令は単に
デコードされるだけで、対応するソース・レジスタと宛
先レジスタに有効のマークを付けるだけで良く、このス
レッドはその命令に関連する動作を実際に実行する必要
はない。

【００５３】７．FORK_M_SUSPEND この命令の命令コードは、将来スレッドの先頭を識別す
るアドレスと、１組のマスク（Ｍ１、Ｍ２、・・・、Ｍ
ｎ）とに関連づけられ、それぞれのマスクには条件が付
いている場合もあれば付いていない場合もある。関連条
件が一切付いていないマスクは、将来スレッドの実行用
の有効なソース・オペランドを無条件に保持する、１組
のアーキテクチャ化レジスタを表している。関連条件が
付いているマスクは、コンパイル時指定条件が実行時に
真と評価された場合のみ、将来スレッドの実行用の有効
なソース・オペランドを保持すると想定することができ
る、１組のアーキテクチャ化レジスタを意味する。

【００５４】８．FSKIP この命令の命令コードは、１つのマスクと、数値ｓとに
関連づけられている。この命令を検出すると、将来スレ
ッドは、次のｓ個の命令の取出し、デコード、実行をス
キップすることができる。さらに将来スレッドは、１組
の定義済みレジスタ・セットに有効なオペランドを保持
しているというマークを付けるためにこのマスクを使用
する。メイン・スレッドはこの命令をＮＯＰとして取り
扱う。

【００５５】９．SKPMG この命令を検出すると、将来スレッドは、次のコンパイ
ル時指定数の命令（通常はスピル・ロード）をデコード
し、対応するソース・レジスタと宛先レジスタに有効の
マークを付けることができるが、このスレッドはその命
令に関連する動作を実際に実行する必要はない。この命
令がメイン・スレッドによって検出された場合は、将来
スレッドが個のSKPMG命令のアドレスの先頭に事前にフ
ォークされているかどうかを判定するために検査が行わ
れる。フォークされている場合は、メイン・スレッドと
対応する将来スレッドという２つのスレッドのマシン状
態を適切に組み合わせることにより、メイン・スレッド
が対応する将来スレッドと組み合わされ、メイン・スレ
ッドは、将来スレッドが中断された命令に続く命令から
実行を再開する。このアドレスへの事前フォークが一切
ない場合は、メイン・スレッドは、この命令に続く一連
の命令シーケンスを引き続き実行する。このような命令
の重要性については後述する。

【００５６】新しい命令の形式の詳細説明： 新しい命令の形式を示す図５ないし図１３の詳細説明は
以下の通りである。

【００５７】１．FORK <addr_1>, <addr_2>, ..., <add
r_n> 図５のFORK命令（ブロック１０）は、１つの命令コード
・フィールド（ブロック１１）と、それぞれが１つの将
来スレッドの開始命令アドレスを識別する１つまたは複
数のアドレス・フィールドaddr_1、addr_2、・・・、ad
dr_n（ブロック１２−１、１２−２、・・・、１２−
Ｎ）とを含む。

【００５８】２．UNCOND_SUSPEND 図６のUNCOND_SUSPEND命令（ブロック２０）は、１つの
命令コード・フィールドを含む。

【００５９】３．SUSPEND <mode>, <cond_1> <cond_2>
... <cond_n> 図７のSUSPEND命令（ブロック３０）は、SUSPEND命令コ
ード・フィールド（ブロック３１）と、モード・フィー
ルド（ブロック３２）と、条件フィールド（ブロック３
３）とを含む。本発明の好ましい実施例では、１つまた
は複数の分岐からなるシーケンスの結果に関するコンパ
イル時予測をcond_1、cond_2、・・・、cond_n（ブロッ
ク３３−１、３３−２、・・・、３３−ｎ）としてコー
ド化するために条件フィールドを使用することができ
る。この特定の条件フィールド・コード化の意味につい
ては、以下に詳述する。

【００６０】モード・フィールドは、２通りの方法のう
ちの１つで条件フィールド内の１組の条件を解釈するた
めに使用する。モード・フィールドが有効（Ｖ）に設定
されている場合は、スレッド管理ユニットは、SUSPEND
命令に関連する<cond_1>〜<cond_n>のうち、コンパイル
時指定条件のいずれか１つが実行時に偽と評価された場
合に、SUSPEND命令に関連する依存領域内の１組の命令
の結果を破棄する。モード・フィールドが無効（Ｉ）に
設定されている場合は、スレッド管理ユニットは、SUSP
END命令に関連する<cond_1>〜<cond_n>というコンパイ
ル時指定条件のすべてが実行時に真と評価された場合
に、SUSPEND命令に関連する依存領域内の１組の命令の
結果を破棄する。直観的に言えば、コンパイラは、フォ
ーク点から組合せ点までの優良経路をコード化するため
に有効モード設定を使用し、フォーク点から組合せ点ま
での不良経路をコード化するために無効モード設定を使
用するはずである。

【００６１】一連の条件のうちの第１の条件cond_1は、
SUSPEND命令を含む将来スレッドをフォークしたあとで
実行時にフォーキング・スレッドによって検出された第
１の固有の条件付き分岐に関連づけられ、一連の条件の
うちの第２の条件cond_2は、SUSPEND命令を含む将来ス
レッドをフォークしたあとで実行時にフォーキング・ス
レッドによって検出された第２の固有の条件ブランチに
関連づけられ、以下同様になる。異なる命令位置に常駐
する分岐だけが固有と見なされる。さらに、好ましい実
施例では特定の分岐結果のコンパイル時予測をコード化
する条件は、実行（Ｔ）、非実行（Ｎ）、無指定（Ｘ）
のいずれかにすることができる。あるいは、これらの条
件に関連する予測は、実行（Ｔ）または非実行（Ｎ）の
いずれかになるように制限することができる。

【００６２】条件コード化形式をさらに明確にするた
め、以下のコード化例を検討する。

【００６３】○ SUSPEND V, T X N このコード化は、予測が該当する場合のみ、この条件付
き中断命令のあとに続く命令が有効であることを意味す
る。すなわち、SUSPEND命令に関連する<cond_1>〜<cond
_n>というコンパイル時指定条件のすべてが実行時に真
と評価された場合に、SUSPEND命令に関連する依存領域
内の１組の命令の結果が有効であることを意味する。第
１の制御流れ条件では、SUSPEND命令を含むスレッドを
フォークしたあとで実行時にフォーキング・スレッドに
よって検出された第１の固有の条件付き分岐が実行され
ると想定する。第２のこのような分岐は、どちらに進ん
でもよい（すなわち、制御非依存分岐）とコンパイラに
よって認められ、第３のこのような分岐は、非実行であ
るとコンパイラによって想定されている。

【００６４】○ SUSPEND I, N T X N T X T このコード化は、予測が該当する場合のみ、この条件付
き中断命令のあとに続く命令が無効であることを意味す
る。すなわち、SUSPEND命令に関連する<cond_1>〜<cond
_n>というコンパイル時指定条件のすべてが実行時に真
と評価された場合にのみ、SUSPEND命令に関連する依存
領域内の１組の命令の結果が破棄される。第１の制御流
れ条件では、SUSPEND命令を含むスレッドをフォークし
たあとで実行時にフォーキング・スレッドによって検出
された第１の固有の条件付き分岐が実行されないと想定
する。第２のこのような分岐は、実行であるとコンパイ
ラによって想定され、第３のこのような分岐は、どちら
に進んでもよい（すなわち、制御非依存分岐）とコンパ
イラによって認められ、第４のこのような分岐は、非実
行であるとコンパイラによって想定され、第５のこのよ
うな分岐は、実行であると想定され、第６のこのような
分岐は、どちらに進んでもよいと認められ、第７のこの
ような分岐は、実行であると想定されている。

【００６５】ただし、フォーク後で組合せ前の領域内の
フォーキング・スレッド・コードがループなしになるよ
うに制限されている場合は、フォーク後にフォーキング
・スレッド内で検出される分岐の動的シーケンスがすべ
て固有のものになるはずであることに留意されたい。す
なわち、このような状況では、第１の固有の条件付き分
岐は単に第１の動的検出条件付き分岐になり、第２の固
有の条件付き分岐は単に第２の動的検出条件付き分岐に
なり、以下同様になるはずである。

【００６６】上記の条件形式は、FORK_SUSPEND、FORK_S
_SUSPEND、FORK_M_SUSPENDの各命令の場合にコンパイル
時予測条件を指定する際にも使用する。好ましい実施例
では、FORK_SUSPEND、FORK_S_SUSPEND、FORK_M_SUSPEND
の各命令で使用する条件フィールド・コード化におい
て、SUSPEND命令に関連する<cond_1>〜<cond_n>のう
ち、コンパイル時指定条件のいずれか１つが実行時に偽
と評価された場合に、スレッド管理ユニットがSUSPEND
命令に関連する依存領域内の１組の命令の結果を破棄す
ることを意味する、有効モード・フィールド設定を想定
している。

【００６７】４．FORK_SUSPEND <addr>, <N1,cond_1>
... <Nn,cond_n> 図８のFORK_SUSPEND命令（ブロック４０）は、命令コー
ド・フィールド（ブロック４１）と、アドレス・フィー
ルド（ブロック４２）と、それぞれが１つのカウント・
フィールドと１つまたは複数の条件とに関連づけられて
いる１つまたは複数の条件フィールド（ブロック４３−
１、４３−２、・・・、４３−ｎ）とを含む。条件用の
好ましい形式は、有効モード・フィールドを想定し、SU
SPEND命令のコンテキストで前述したものと同じであ
る。

【００６８】５．SKIP <n> 図９のSKIP命令（ブロック５０）は、命令コード（ブロ
ック５１）と、SKIP命令のコンテキストで前述したよう
に、この命令以降で実行をスキップすることができる命
令の数を指定するカウント・フィールド（ブロック５
２）とを含む。

【００６９】６．FORK_S_SUSPEND <addr>, <n>, <N1,co
nd_1> ... <Nn,cond_n> 図１０のFORK_S_SUSPEND命令（ブロック６０）は、命令
コード・フィールド（ブロック６１）と、アドレス・フ
ィールド（ブロック６２）と、（SKIP命令のコンテキス
トで）前述した意味で実行をスキップすることができ
る、スレッドの先頭にある命令の数を指定するカウント
・フィールド（ブロック６３）と、それぞれが１つのカ
ウント・フィールドと１つまたは複数の条件とに関連づ
けられている１つまたは複数の条件フィールド（ブロッ
ク６４−１、６４−２、・・・、６４−ｎ）とを含む。
条件用の好ましい形式は、有効モード・フィールドを想
定し、SUSPEND命令のコンテキストで前述したものと同
じである。

【００７０】７．FORK_M_SUSPEND <addr>, <M1,cond_1>
... <Mn,cond_n> 図１１のFORK_M_SUSPEND命令（ブロック７０）は、命令
コード・フィールド（ブロック７１）と、アドレス・フ
ィールド（ブロック７２）と、それぞれが１つのマスク
・フィールドと１つまたは複数の条件とに関連づけられ
ている１つまたは複数の条件フィールド（ブロック７３
−１、７３−２、・・・、７３−ｎ）とを含む。それぞ
れのマスク・フィールドは、有効なソース・オペランド
を保持する１組のアーキテクチャ化レジスタを指定する
レジスタ・マスクを含むが、関連条件は実行時に適用さ
れるものとする。条件用の好ましい形式は、有効モード
・フィールドを想定し、SUSPEND命令のコンテキストで
前述したものと同じである。

【００７１】８．FSKIP <mask> <n> 図１２のFSKIP命令（ブロック８０）は、命令コード・
フィールド（ブロック８１）と、１組のレジスタを定義
するマスク・フィールド（ブロック８２）と、FSKIP命
令のコンテキストで前述したように、完全にスキップす
ることができる命令の数を指定するカウント・フィール
ド（ブロック８３）とを含む。

【００７２】９．SKPMG <n> 図１３のSKPMG命令（ブロック９０）は、命令コード・
フィールド（ブロック９１）と、SKPMG命令のコンテキ
ストで前述したように、この命令以降で実行をスキップ
することができる命令の数を指定するカウント・フィー
ルド（ブロック9２）とを含む。

【００７３】組合せアクション：フォーク済みスレッド
とフォーキング・スレッドとの組合せ：対応するフォー
キング・スレッド（たとえば、メイン・スレッド）がフ
ォーク済み（将来）スレッドの先頭に達すると、フォー
ク済み将来スレッドがフォーキング・スレッドと組み合
わされる。この組合せは、フォーク済みスレッドによっ
て定義されたＣＰＵ状態に置き換わり、置き換えられな
い残りの状態がフォーキング・スレッドの状態のまま保
持されるように、２つのスレッドのＣＰＵ状態を組み合
わせることによって実施される。通常、あるスレッドの
ＣＰＵ状態は、そのスレッドによって使用され定義され
るアーキテクチャ上可視のレジスタを含むはずである。
フォーキング・スレッド・プログラム・カウンタは、組
み合わされたフォーク済みスレッドによって正しく実行
された命令が再実行されず、組み合わされたフォーク済
みスレッドによって実行されていない命令が適切に実行
されるように実行を続行するために更新される。この場
合、正しく実行された命令とは、重要なプログラム依存
関係に違反しないような命令を意味する。フォーキング
・スレッドは、組み合わされたスレッドの最新実行点を
過ぎても実行を続行し、組み合わされた将来スレッドに
よって正しく実行された命令は、組合せプロセスの終わ
りに完了の対象となる。組み合わされた将来スレッドに
関連する資源は、組合せプロセスの終わりに解放され
る。ただし、組合せの時点では、フォーク済み将来スレ
ッドがすでに中断されているか、まだ活発に実行中であ
るかのいずれかであることに留意されたい。いずれも場
合も、組合せプロセスが終わると、組み合わされた将来
スレッドが効果的に存在を停止する。また、UNCOND_SUS
PENDなどの明示的な中断プリミティブがない場合は、組
合せが行われるまでフォーク済み将来スレッドがいつも
実行を続けるはずであることにも留意されたい。

【００７４】フォークの任意選択性：本発明で提案した
命令の新規の特徴は、コンパイル時にそれを使用する場
合、実行時ＣＰＵ資源に関するいかなる想定も必要とし
ない点である。実際の実施態様の積極性に応じて、特定
のＣＰＵが将来スレッドを実際にフォークできる場合も
あれば、できない場合もある。すなわち、ＣＰＵの観点
から見ると、FORK命令の検出に応答して実行時に実際に
フォークするかどうかは、完全に任意選択である。この
ような命令のユーザ（たとえば、コンパイラ）は、保留
の将来スレッドの数を追跡する必要がなく、また、実行
時に確かに従う（すなわち、将来スレッドをフォークす
る）べき特定のフォークを想定することもできない。

【００７５】コンパイラは、個別の（将来）スレッドと
して実行可能な制御およびデータ非依存コード領域を識
別する。ただし、コンパイラは、このようなスレッドが
並列実行されることを想定するような追加の再構造化ま
たは最適化を一切実行しない。たとえば、コンパイラ
は、挿入されたFORK命令のいずれかが実行時にＣＰＵに
よって無視されたとき、正しいプログラム実行を保証す
るのに必要になるはずのスピル・コードを保持する。ス
ピル・コードとは、アーキテクチャ上可視のＣＰＵレジ
スタの内容を命令キャッシュ内の所与の位置に格納し、
その後、別の格納動作をその間に行うことなくこの同じ
位置の内容を再ロードするためにコンパイル時に挿入さ
れる１組の命令を意味する。ただし、スピル・コードの
実行は、将来スレッドとしてそれを実行している間は冗
長になる可能性があることに留意されたい。将来スレッ
ド実行中のこのようなスピル・コードの処理を最適化す
るため、本発明はSKIP命令とFSKIPおよびSKPMGなどのそ
の変形態様を追加している。これらは、冗長なスピル・
コードの実行を低減または解消するためのコンパイル時
のヒントを可能にするものである。この新しい命令の意
味の詳細は、前述の通りである。

【００７６】FORK命令の任意選択性の直接的な結果とし
て、それぞれが０個またはそれ以上のスレッドをフォー
クできる、この強化型マシン・アーキテクチャの各種実
施態様に応じて再コンパイルする必要がないことに留意
されたい。同様に、新しい命令のいずれも含まない古い
２進コードについても、再コンパイルの必要はない。

【００７７】将来スレッドでの複数条件付き中断の解
釈：FORK命令に応答してフォークされた将来スレッド
が、無条件中断を検出する前に一連の条件付き中断を検
出する可能性がある。それぞれの条件付き中断は、いま
だに共通のフォーク点に関連してしかも他の条件付き中
断とは無関係に解釈されている。したがって、各種の制
御流れ予測を将来スレッドの様々な部分に関連づけるこ
とは可能である。ここでSUSPEND命令Ａについて検討す
る。FORK、SUSPEND、UNCOND_SUSPEND、FORK_S_SUSPEN
D、FORK_M_SUSPEND、またはSKPMG命令以外のいくつかの
命令の後で、別のSUSPEND命令ＢがＡの後に続くと想定
する。通常、SUSPEND命令Ｂの後にはUNCOND_SUSPEND命
令が続くはずである。ここで、SUSPEND命令Ａに関連す
るコンパイル時条件が実行時に偽になると判定されてい
ると想定する。コンパイルを簡略化し、将来スレッドで
の状態維持を低減するために、本発明の好ましい実施例
では、破棄の時期を命令ＡとＢとの間に限定するのでは
なく、命令ＡとUNCOND_SUSPEND命令との間にすべての命
令の結果を単純に破棄することができる。

【００７８】組合せ点の識別の簡略化：コンパイル時に
は、将来スレッド内のすべてのスピル・ロードをグルー
プ化し、そのグループを将来スレッドの実行が始まるブ
ロックの先頭に移動させることが可能な場合もある。す
べての潜在的将来スレッドの最初の実行が新しいSKPMG
命令になるようにさらにコンパイラが保証する場合、こ
の命令は、スキップ可能なスピル・ロードの標識ならび
に将来スレッドの開始用のマーカの両方の役割を果た
す。この命令の意味については、前述の通りである。た
だし、（SKPMGの形での）このような将来スレッド・マ
ーカがない場合、メイン・スレッドは、絶えずその命令
アドレスをすべての事前フォーク済み将来スレッドと照
らし合わせて検査し、組合せが必要かどうかを検出する
必要がある場合もあることに留意されたい。また、スキ
ップされる命令の数がゼロであっても、この解釈では将
来スレッド・マーカの追加機能を果たすので、コンパイ
ラはこのSKPMG命令を挿入しなければならない。

【００７９】図３および図４は、１次実行方法（ＰＥ
Ｍ）と呼ばれる本発明の実行方法の諸ステップを示す流
れ図である。本発明の方法の説明とともに、図３および
図４の詳細説明を以下に示す。

【００８０】１．フォーク点の検出（ブロック２１
０）：本発明で提案した新しい命令とは無関係に、当技
術分野で既知の技法を使用して静的順序の命令シーケン
スを生成する。この命令シーケンスを分析して、１組の
フォーク点を判定する。フォーク点とは、静的命令シー
ケンス中の位置であって、使用可能なマシン状態が順次
追跡順序で後から（ただし、フォーク点の直後ではな
い）現れる１組または複数組の命令の並列実行を開始で
きる位置を意味する。フォーク点の識別には、先行技術
で既知の技法を使用して対応するプログラム依存性グラ
フ（制御依存性グラフとデータ依存性グラフの組合せ）
の一部または全部に基づいて行う、データおよび制御依
存性分析が含まれる。たとえば、分岐命令を解決する
と、実質的に分岐命令に制御依存している命令のスレッ
ド用のフォーク点に到達することができる。

【００８１】２．FORKの挿入（ブロック２２０）：コン
パイル時に潜在的フォーク点のうちの０個またはそれ以
上に０個またはそれ以上のFORK命令を挿入する。この位
置では、FORK命令は、フォーク点に関連する０個または
それ以上の潜在的将来スレッドの開始アドレスを識別す
ることができる。特定のFORK命令とそのフォーク済み将
来スレッド（複数も可）との関連づけがある場合は、そ
の関連づけが前述のＴＭユニットによって管理される。

【００８２】３．静的シーケンスのロード（ブロック２
３０）：固定位置から始まるメモリ・システム（図１の
ブロック１００）に前のステップ（FORKの挿入、ブロッ
ク２２０）後に生成した静的順序の命令シーケンスをロ
ードする。この固定位置では、メモリ・システムと中央
演算処理装置の命令キャッシュとのインタフェースが取
られ、静的シーケンスの続きが定期的に命令キャッシュ
に転送される。

【００８３】４．取出しと組合せ検査（ブロック２４
０）：現行アドレス以降について、メイン・プログラム
・カウンタ（すなわち、メイン・スレッドとして）によ
りシーケンスをアドレス指定し、プログラム・カウンタ
を更新することにより、命令キャッシュから命令シーケ
ンスを取り出す。命令キャッシュ内で見つからない命令
はメイン・メモリからキャッシュに取り出される。命令
の取出しとともに、現行命令取出しアドレス以降につい
て、組み合わされていない１つまたは複数の将来スレッ
ドがあるかどうかを判定するための検査も行われる。こ
の暗黙の組合せ検査の実行は、ＴＭユニット（図１のブ
ロック１３０）も担当する。この検査は通常、組み合わ
されていない（保留）すべての将来スレッドの開始アド
レスとそれぞれの命令取出しアドレスとの比較を含むは
ずである。

【００８４】５．スレッド妥当性検査（ブロック２５
０）：１つまたは複数の将来スレッドが別の実行スレッ
ド（たとえば、メイン・スレッド）の命令取出しアドレ
スに事前にフォークされていると前のステップ（ブロッ
ク２４０）で判定された場合は、１つまたは複数の予測
の結果、プログラム依存関係の違反のためにこのような
将来スレッドのそれぞれによって実行された命令の一部
または全部を破棄する必要があるかどうかを確認するた
めに、追加の検査がＴＭユニットによって行われる。

【００８５】６．組合せ（ブロック２６０）：前のステ
ップ（スレッド妥当性検査、ブロック２５０）で識別さ
れたフォーク済み将来スレッドのうち、有効に実行され
た部分が、前述の組合せ動作によりメイン・スレッドと
組み合わされる。

【００８６】７．デコード（ブロック２７０）：取り出
した命令をディスパッチャでデコードする。その命令の
うちの１つまたは複数がFORK命令としてデコードされた
かどうかを確認するために検査する。

【００８７】８．メイン・スレッドの実行（ブロック２
８０）：前のステップ（デコード、ブロック２７０）で
いずれかの命令がFORK以外の命令としてデコードされた
場合、（図１のブロック１４０を使用して）命令依存関
係を分析し、適切な機能ユニット（図２のブロック１８
０）上で実行するために（図１のブロック１５０を使用
して）それらをスケジューリングすることにより、実行
を続行する。

【００８８】９．完了（ブロック２９０）：前述のよう
に、完了ユニット（図２のブロック１９０）により命令
実行を完了する。ステップ４〜９に記載した取出し、デ
コード、実行のプロセスは続行される。

【００８９】１０．フォーク能力の判定（ブロック３０
０）：上記のブロック２７０に関連するステップ（デコ
ード）で命令がFORK命令としてデコードされた場合は、
追加の将来スレッドをフォークするために使用可能なマ
シン資源があるかどうかを判定するための検査が行われ
る。将来スレッドをフォークするのに必要なマシン資源
としては、使用可能なプログラム・カウンタと、スレッ
ド状態を保管するために使用可能な内部バッファ空間な
どがある。

【００９０】１１．フォーク（ブロック３１０）：使用
可能な資源がある場合は、FORK命令に関連するアドレス
（複数も可）を将来プログラム・カウンタ（複数も可）
にロードすることにより、ＴＭユニットが将来スレッド
（複数も可）をフォークする。これにより将来スレッド
（複数も可）の実行が始まるが、将来スレッドの開始マ
シン状態（プログラム・カウンタを除く）は、フォーク
点でのメイン・スレッド（関連FORK命令をデコードする
スレッド）のものと同じになる。

【００９１】１２．将来スレッドの実行（ブロック３２
０）：上記のステップ（４）〜（８）と同様に、フォー
キング・スレッドの実行と並行して将来スレッドの実行
が続行される。ただし、メイン・プログラム・カウンタ
とメイン・スレッド・ディスパッチャの代わりに、将来
プログラムカウンタの１つと将来スレッド・ディスパッ
チャの１つをそれぞれ使用し、メイン・スレッドをフォ
ーキング・スレッドと呼ぶ。

【００９２】１３．将来スレッドの停止（ブロック３３
０）：将来スレッドがフォーキング・スレッドと組み合
わされた後、または将来スレッドがＴＭユニットによっ
て破棄された後、将来スレッドの実行が中断され、関連
資源が解放される。

【００９３】前述の１次実行方法（ＰＥＭ）の強化例を
いくつか以下に説明する。

【００９４】代替実施例１： １．ＰＥＭのステップ（２）は、以下の追加サブステッ
プを有する。 ○ すべての将来スレッドの終わりにUNCOND_SUSPEND命
令が挿入される。

【００９５】２．ＰＥＭのステップ（１２）は、以下の
追加サブステップを有する。UNCOND_SUSPEND命令を検出
すると、その対応将来スレッドの実行中に将来スレッド
は無条件にそのスレッドを中断する。

【００９６】３．ＰＥＭのステップ（８）は、以下の追
加サブステップを有する。 ○ その対応将来スレッド以外のスレッドが（たとえ
ば、メイン・スレッド内で）実行するためにUNCOND_SUS
PEND命令が検出された場合は、その命令は無視される。

【００９７】代替実施例２： １．代替実施例１を含むＰＥＭのステップ（１）は、以
下の追加サブステップを有する。 ○ すべてのUNCOND_SUSPEND命令に対応して、対応将来
スレッドに０個またはそれ以上のSUSPEND命令を挿入す
ることができ、そこでそれぞれのSUSPEND命令が１つの
条件に関連づけられる。

【００９８】２．代替実施例１を含むＰＥＭのステップ
（２）は、以下の追加サブステップを有する。 ○ SUSPEND命令に関連するコンパイル時指定条件が実
行時に真と評価される場合のみ、SUSPEND命令に関連す
る依存領域内の１組の命令が対応将来スレッドでの実行
に有効であると見なされる。したがって、将来スレッド
の実行が条件付き中断命令を検出するときまでに関連予
測が無効であると分かっている場合には、条件付き中断
点で（ＴＭユニットによって）将来スレッドを強制的に
中断することもできる。

【００９９】３．代替実施例１を含むＰＥＭのステップ
（３）は、以下の追加サブステップを有する。 ○ その対応将来スレッド以外のスレッドが（たとえ
ば、メイン・スレッド内で）実行するためにSUSPEND命
令が検出された場合は、その命令は無視される。

【０１００】代替実施例３： １．代替実施例２を含むＰＥＭのステップ（１）は、以
下の追加サブステップを有する。 ○ ０個またはそれ以上のSKIP命令を将来スレッドに挿
入することができ、そこで、それぞれのSKIP命令が数値
ｓに関連づけられる。

【０１０１】２．代替実施例２を含むＰＥＭのステップ
（２）は、以下の追加サブステップを有する。 ○ その対応将来スレッドの実行中に関連数値ｓを含む
SKIP命令を検出すると、この命令に続く次のｓ個の命令
をデコードすることが必要なだけで、これらの命令のそ
の後の実行はスキップすることができる。これらの命令
で使用するソース・レジスタと宛先レジスタは、有効オ
ペランドを保持するものとしてマークを付けることがで
きるが、いずれかの機能ユニット上で実行するためにこ
れらのｓ個の命令をスケジューリングする必要はない。

【０１０２】３．代替実施例２を含むＰＥＭのステップ
（３）は、以下の追加サブステップを有する。 ○ その対応将来スレッド以外のスレッドが（たとえ
ば、メイン・スレッド内で）実行するためにSKIP命令が
検出された場合は、その命令は無視される。

【０１０３】代替実施例４： １．代替実施例２を含むＰＥＭのステップ（１）は、以
下の追加サブステップを有する。 ○ ０個またはそれ以上のFSKIP命令を将来スレッドに
挿入することができ、そこで、それぞれのFSKIP命令
が、１組のアーキテクチャ化レジスタを定義するマスク
と、数値ｓとに関連づけられる。

【０１０４】２．代替実施例２を含むＰＥＭのステップ
（２）は、以下の追加サブステップを有する。 ○ その対応将来スレッドの実行中にマスクと数値ｓを
含むFSKIP命令を検出すると、この命令に続く次のｓ個
の命令をスキップすることができる。すなわち、これら
の命令は、取出し、デコード、または実行を行う必要が
ない。マスクで識別されたレジスタは、有効オペランド
を保持するものとしてマークを付けることができる。

【０１０５】３．代替実施例２を含むＰＥＭのステップ
（３）は、以下の追加サブステップを有する。 ○ その対応将来スレッド以外のスレッドが（たとえ
ば、メイン・スレッド内で）実行するためにFSKIP命令
が検出された場合は、その命令は無視される。

【０１０６】代替実施例５： １．代替実施例２を含むＰＥＭのステップ（１）は、以
下の追加サブステップを有する。 ○ すべての将来スレッドの先頭に１つのSKPMG命令が
挿入され、そこで、それぞれのSKPMG命令が数値ｓに関
連づけられる。

【０１０７】２．代替実施例２を含むＰＥＭのステップ
（２）は、以下の追加サブステップを有する。 ○ その対応将来スレッドの実行中に関連数値ｓを含む
SKPMG命令を検出すると、この命令に続く次のｓ個の命
令をデコードすることが必要なだけで、これらの命令の
その後の実行はスキップすることができる。これらの命
令で使用するソース・レジスタと宛先レジスタは、有効
オペランドを保持するものとしてマークを付けることが
できるが、いずれかの機能ユニット上で実行するために
これらのｓ個の命令をスケジューリングする必要はな
い。

【０１０８】３．代替実施例２を含むＰＥＭのステップ
（３）は、以下の追加サブステップを有する。 ○ その対応将来スレッド以外のスレッドが（たとえ
ば、メイン・スレッド内で）実行するためにSKPMG命令
が検出された場合は、SKPMG命令の命令アドレス以降に
ついて、将来スレッドがすでにフォークされているかど
うかを判定するための組合せ検査が行われる。

【０１０９】４．ＰＥＭのステップ（４）の暗黙の組合
せ検査はここでは不要であり、そのため除去される。

【０１１０】代替実施例６： １．ＰＥＭのFORKの挿入ステップ（すなわち、ステップ
３）は、以下のステップに置き換えられる。 ○ ０個またはそれ以上の潜在的フォーク点に０個また
はそれ以上のFORK_SUSPEND命令を挿入する。その場合、
FORK_SUSPEND命令は、関連の潜在的将来スレッドの開始
アドレスを識別するアドレスと、一連の数値とを含み、
それぞれの数値には条件が付いている場合もあれば付い
ていない場合もある。所与の一連の数値は、FORK_SUSPE
ND命令に関連するアドレスから始まる命令の連続グルー
プを意味する。特定のFORK_SUSPEND命令とそのフォーク
済み将来スレッドとの関連づけがある場合は、前述のＴ
Ｍユニットによってその関連づけが管理される。

【０１１１】２．ＰＥＭのフォーク能力の判定ステップ
（すなわち、ステップ１０）は、以下のステップに置き
換えられる。 ○ 命令がFORK_SUSPEND命令としてデコードされた場合
は、追加の将来スレッドをフォークするために使用可能
なマシン資源があるかどうかを判定するための検査が行
われる。

【０１１２】３．ＰＥＭのフォーク・ステップ（すなわ
ち、ステップ１１）は、以下のステップに置き換えられ
る。 ○ 使用可能な資源がある場合は、FORK_SUSPEND命令に
関連するアドレス（複数も可）を将来プログラム・カウ
ンタ（複数も可）にロードすることにより、将来スレッ
ドをフォークする。

【０１１３】４．ＰＥＭの将来スレッドの実行ステップ
（すなわち、ステップ１２）は、以下の追加サブステッ
プを有する。 ○ FORK_SUSPEND命令に関連する数値列は、以下のよう
に対応将来スレッドの実行を制御する。数値たとえばｎ
に関連条件が一切付いていない場合は、ｎ個の命令から
なる対応グループを将来スレッドとして無条件に実行で
きることを意味し、数値たとえばｍに関連条件が付いて
いる場合は、コンパイル時指定条件が実行時に真と評価
される場合のみ、ｍ個の命令からなる対応グループの将
来スレッド実行が有効になるはずである。

【０１１４】代替実施例７： １．ＰＥＭのFORKの挿入ステップ（すなわち、ステップ
３）は、以下のステップに置き換えられる。 ○ ０個またはそれ以上の潜在的フォーク点に０個また
はそれ以上のFORK_S_SUSPEND命令を挿入する。その場
合、FORK_S_SUSPEND命令は、関連の潜在的将来スレッド
の開始アドレスを識別するアドレスと、数値たとえばｓ
と、一連の数値とを含み、それぞれの数値には条件が付
いている場合もあれば付いていない場合もある。所与の
一連の数値は、FORK_S_SUSPEND命令に関連するアドレス
から始まる命令の連続グループを意味する。

【０１１５】２．ＰＥＭのフォーク能力の判定ステップ
（すなわち、ステップ１０）は、以下のステップに置き
換えられる。 ○ 命令がFORK_S_SUSPEND命令としてデコードされた場
合は、追加の将来スレッドをフォークするために使用可
能なマシン資源があるかどうかを判定するための検査が
行われる。

【０１１６】３．ＰＥＭのフォーク・ステップ（すなわ
ち、ステップ１１）は、以下のステップに置き換えられ
る。 ○ 使用可能な資源がある場合は、FORK_S_SUSPEND命令
に関連するアドレス（複数も可）を将来プログラム・カ
ウンタ（複数も可）にロードすることにより、将来スレ
ッドをフォークする。

【０１１７】４．ＰＥＭの将来スレッドの実行ステップ
（すなわち、ステップ１２）は、以下の追加サブステッ
プを有する。 ○ FORK_S_SUSPEND命令に関連する数値列は、以下のよ
うに対応将来スレッドの実行を制御する。対応スレッド
を将来スレッドとして実行している間は最初のｓ個の命
令をデコードするだけで、これらの命令で使用するソー
ス・レジスタと宛先レジスタは、有効オペランドを保持
するものとしてマークを付けることができるが、いずれ
かの機能ユニット上で実行するためにこれらのｓ個の命
令をスケジューリングする必要はない。さらに、数値た
とえばｎに関連条件が一切付いていない場合は、ｎ個の
命令からなる対応グループを将来スレッドとして無条件
に実行できることを意味し、数値たとえばｍに関連条件
が付いている場合は、コンパイル時指定条件が実行時に
真と評価される場合のみ、ｍ個の命令からなる対応グル
ープの将来スレッド実行が有効になるはずである。

【０１１８】代替実施例８： １．ＰＥＭのFORKの挿入ステップ（すなわち、ステップ
３）は、以下のステップに置き換えられる。 ○ ０個またはそれ以上の潜在的フォーク点に０個また
はそれ以上のFORK_M_SUSPEND命令を挿入する。その場
合、FORK_M_SUSPEND命令は、関連の潜在的将来スレッド
の開始アドレスを識別するアドレスと、１組のマスクと
を含み、それぞれのマスクには条件が付いている場合も
あれば付いていない場合もある。

【０１１９】２．ＰＥＭのフォーク能力の判定ステップ
（すなわち、ステップ１０）は、以下のステップに置き
換えられる。 ○ 命令がFORK_M_SUSPEND命令としてデコードされた場
合は、追加の将来スレッドをフォークするために使用可
能なマシン資源があるかどうかを判定するための検査が
行われる。

【０１２０】３．ＰＥＭのフォーク・ステップ（すなわ
ち、ステップ１１）は、以下のステップに置き換えられ
る。 ○ 使用可能な資源がある場合は、FORK_M_SUSPEND命令
に関連するアドレス（複数も可）を将来プログラム・カ
ウンタ（複数も可）にロードすることにより、将来スレ
ッドをフォークする。

【０１２１】４．ＰＥＭの将来スレッドの実行ステップ
（すなわち、ステップ１２）は、以下の追加サブステッ
プを有する。 ○ FORK_M_SUSPEND命令に関連するマスク列は、以下の
ように対応将来スレッドの実行を制御する。対応スレッ
ドを将来スレッドとして実行している間、FORK_M_SUSPE
NDに関連し、条件が一切付いていないマスクは、将来ス
レッドの実行のための有効ソース・オペランドを無条件
に保持する１組のアーキテクチャ化レジスタを表し、条
件に関連するマスクは、コンパイル時指定条件が実行時
に真と評価される場合のみ、将来スレッドの実行のため
の有効ソース・オペランドを保持すると想定することが
できる１組のアーキテクチャ化レジスタを意味する。命
令のソース・レジスタ・オペランドに関連するコンパイ
ル時指定条件が実行時に真に該当しない場合は、ＴＭユ
ニットが将来スレッド内の命令の一部または全部の結果
を破棄する。

【０１２２】代替実施例９： １．ＰＥＭのメイン・スレッドの実行ステップ（すなわ
ち、ステップ８）は、以下の追加サブステップを有す
る。 ○ スレッド実行中のすべての分岐解決（すなわち、条
件付き分岐を実行するかどうかの判定と、関連目標アド
レス）はＴＭユニットに連絡される。ＴＭユニットはこ
の情報を使用して、間違った分岐アドレスにフォークさ
れた将来スレッドと依存スレッドを破棄する必要がある
かどうかを判定する。これにより、後述するように命令
の制御依存ブロックの同時実行が可能になる。

【０１２３】代替実施例１０： １．ＰＥＭの取出しと組合せ検査ステップ（すなわち、
ステップ４）は、以下の追加サブステップを有する。 ○ 事前にフォークされたスレッドのいずれかが既定の
タイムアウト期間より長い間、組み合わされずにいたか
どうかを確認する検査を含むように、組合せ検査が拡張
される。このようなスレッドはすべてＴＭユニットによ
って破棄される。

【０１２４】新しい命令のコード化の詳細説明： 図１４ないし図１７は、新しい命令の一部の好ましいコ
ード化例を示している。ビット位置０は最上位ビット位
置を意味し、ビット位置３１は最下位ビット位置を意味
する。

【０１２５】１．FORK（図１４） この命令（ブロック１１１）では、ビット０〜５を使用
して１次命令コード４を使用している。将来スレッドの
開始アドレスの相対アドレスはビット位置６〜２９の２
４ビットのアドレス・フィールドにコード化される。最
後の２ビットであるビット位置３０と３１は、FORK命令
の代替形式のコード化を行うための拡張命令コード・フ
ィールドとして使用される。この２ビットは、FORK命令
のこのバージョンでは０に設定される。

【０１２６】２．UNCOND_SUSPEND（図１５） この命令（ブロック２２２）では、ビット位置０〜５の
１次命令コード１９を使用している。拡張命令コード・
フィールドのビット２１〜３０は、それを同じ１次命令
コードを含む他の命令と区別するために５１４に設定さ
れている。ビット３１は、この無条件中断命令を条件付
き中断（SUSPEND）命令と区別するために０に設定され
ている。

【０１２７】３．SUSPEND（図１６） この命令（ブロック３３３）では、ビット位置０〜５の
１次命令コード１９を使用している。拡張命令コード・
フィールドのビット２１〜３０は、それを同じ１次命令
コードを含む他の命令と区別するために５１４に設定さ
れている。ビット３１は、この条件付き中断命令を無条
件中断（UNCOND_SUSPEND）命令と区別するために１に設
定されている。コンパイル時分岐予測は、実行、非実
行、無指定のいずれかになる。したがって、ビット位置
７〜２０を使用して７つのコンパイル時分岐予測Ｃ１〜
Ｃ７のそれぞれについて、２ビットずつ使用する。この
シーケンスの第１の条件Ｃ１（ビット７と８）は、SUSP
END命令を含む将来スレッドのフォーク後に実行時にフ
ォーキング・スレッドによって検出される第１の固有の
条件付き分岐に関連づけられ、このシーケンスの第７の
条件Ｃ７は、SUSPEND命令を含む将来スレッドのフォー
ク後に実行時にフォーキング・スレッドによって検出さ
れる第７の固有の条件付き分岐に関連づけられている。
モード・フィールドはビット位置６にコード化される。
このコード化に関連する意味については、SUSPEND命令
のコンテキストで既に前述した通りである。

【０１２８】４．FORK_SUSPEND（図１７） この命令（ブロック４４４）でも、ビット位置０〜５で
上記のFORK命令に使用したものと同じ１次命令コード４
を使用している。しかし、拡張命令コード・フィールド
（ビット３０と３１）は、それをFORK命令と区別するた
めに１に設定されている。将来スレッドの開始アドレス
の相対アドレスはビット位置２０〜２９の１０ビットの
アドレス・フィールドにコード化される。コンパイル時
分岐予測は、実行、非実行、無指定のいずれかになる。
したがって、４つのコンパイル時分岐予測Ｃ１〜Ｃ４の
それぞれについて、２ビットずつ使用する。このシーケ
ンスの第１の条件Ｃ１は、SUSPEND命令を含む将来スレ
ッドのフォーク後に実行時にフォーキング・スレッドに
よって検出される第１の固有の条件付き分岐に関連づけ
られ、このシーケンスの第４の条件Ｃ４は、SUSPEND命
令を含む将来スレッドのフォーク後に実行時にフォーキ
ング・スレッドによって検出される第４の固有の条件付
き分岐に関連づけられている。第１の数値Ｎ１（ビット
６〜８）は、Ｃ１（ビット９と１０）とＣ２（ビット１
１と１２）の両方に関連する条件が実行時に真に該当す
ると評価されると想定して、将来スレッドの開始アドレ
スから始まる有効な命令の数を意味する。これに対し
て、Ｎ２（ビット１３〜１５）は、Ｃ３（ビット１６と
１７）とＣ４（ビット１８と１９）の両方に関連する条
件が実行時に真に該当すると評価されると想定して、将
来スレッドの開始アドレスから始まる有効な命令＋Ｎ１
個の命令の数を意味する。

【０１２９】例 図１８ないし図２０は、本発明で提案した命令の一部を
コード・シーケンスのサンプルで使用した場合を示して
いる。図示のコード・シーケンスは、任意で分岐命令で
終わる、非分岐命令のブロックに分割されている。使用
する命令ニーモニックは、本発明で導入したもの（たと
えば、FORK）か、またはＰｏｗｅｒＰＣアーキテクチャ
（ＰｏｗｅｒＰＣはＩＢＭの商標である）のものかのい
ずれかである。条件付き分岐で終わるコードシーケンス
のブロックは、分岐を実行しない場合に制御の転送先に
なるブロックに続く辺Ｎと、分岐を実行する場合に制御
の転送先になるブロックに続くもう１つの辺Ｔとを有す
る。

【０１３０】図１８および図１９は、複数の命令からな
る制御非依存ブロック間で予測するために本発明で提案
した命令を使用する場合を示している。図１８および図
１９のＢ１とＢ１２のような様々な制御非依存ブロック
の同時取出し、デコード、予測、実行を可能にするため
に、FORK、SUSPEND、UNCOND_SUSPENDの各命令が使用さ
れている。制御がブロックＢ０からＢ１に達すると、ブ
ロックＢ１のFORK命令を使用して、制御非依存ブロック
Ｂ１２とＢ１との並行実行を開始する。ただし、Ｂ１を
実行するメイン・スレッドはいくつかの経路の１つをた
どることができるが、それらの経路はいずれも将来スレ
ッドとして実行されるブロックＢ１２に到達することに
留意されたい。同様に、ブロックＢ１の終わりにある分
岐の解決によってＢ３に至る場合には、制御非依存Ｂ９
の並行実行のためにFORK命令が使用される。ブロックＢ
３を実行するスレッドは、ブロックＢ６またはＢ７の実
行後にＢ９から始まる将来スレッドと組み合わされる。

【０１３１】アーキテクチャ化レジスタ２とメモリ位置
ｍｅｍ６それぞれの更新の結果発生する重要な依存関係
を観察するために、ブロックＢ９とＢ１２を実行する将
来スレッドで無条件中断すなわちUNCOND_SUSPEND命令が
使用される。ブロックＢ３の終わりにある分岐の結果と
して、フォーキング・スレッド（ブロックＢ３を実行す
るもの）が実行時にブロックＢ７に移行し、ブロックＢ
６（レジスタ３を更新するもの）を回避すると想定し
て、次の２つの命令を予測実行するために、ブロックＢ
９では条件付き中断すなわちSUSPEND命令が使用され
る。同様に、制御がブロックＢ１０（レジスタ４を更新
するもの）に移行しないと想定して、次の４つの命令を
予測実行するためにSUSPEND命令が使用される。ただ
し、回避される経路、すなわちブロックＢ２とＢ１０を
介してブロックＢ１のフォーク点からブロックＢ１２の
組合せ点に至る経路は、経路表現ＴＸＴを使用してコン
パイル時にコード化されることに留意されたい。この表
現は、フォーク点後の第１の固有の条件付き分岐すなわ
ちＢ１の終わりにある分岐が実行され、第２の分岐すな
わちＢ２の終わりにある分岐はどちらにも進むことがで
き、Ｂ８の終わりにある分岐も実行されることを意味す
る。ただし、この場合、複数の優良経路（すなわち、レ
ジスタ４を一切更新しない経路）が存在することに留意
されたい。ブロックＢ２の終わりにある分岐はブロック
Ｂ４またはブロックＢ５のいずれかに進むことができ、
Ｂ８の終わりにある分岐が実行されず、Ｂ１１に至る場
合はこれらの経路のいずれも優良と見なされるはずであ
る。

【０１３２】フォークの任意選択性を保証するために、
図１９のブロックＢ１２の先頭にあるスピル・ロードが
コンパイラによって保存されていることに留意された
い。また、Ｂ１２が将来スレッドとして実行される場合
は、スピル・ロードの冗長実行を最適化するために図１
９でSKIP命令が使用されることにも留意されたい。

【０１３３】図２０は、複数の命令からなる制御依存ブ
ロック間で予測するためにFORK命令とSUSPEND命令を使
用する場合を示している。FORK命令は、ブロックＢ１０
０から制御依存ブロックＢ２００とＢ３００にフォーク
するために使用されている。制御依存ブロックＢ２００
とＢ３００が実行され、並列である。メイン・スレッド
はブロックＢ１００を実行するが、フォーク済み将来ス
レッドはブロックＢ２００とブロックＢ３００を実行す
る。ブロックＢ１００の終わりにある分岐を解決する
と、ＴＭユニットは間違った分岐結果に関して条件付け
された将来スレッドを破棄する。たとえば、分岐を実行
する場合、Ｂ２００から始まる将来スレッドが破棄され
る。

【０１３４】潜在的利点 この項では、上記で提案した命令が前述の諸問題を解決
するのにどのように役立つかを詳しく説明する。

【０１３５】１．命令取出しのボトルネックの緩和 上記の例に示したように、提案したフォーク命令と中断
命令は、現行スーパースカラー・プロセッサの命令取出
しのボトルネックに対処する新規の方法を提供する。コ
ンパイラは、これらの命令を使用して、任意の距離にあ
る（動的に）制御非依存ブロックを指し示すことができ
る。制御非依存とは、プログラム制御がフォーク点に達
した場合に、これらの将来ブロックに達するように拘束
される（当然のことながら、予測できないような流れの
変更を行うことができる割込みは一切ないものと想定す
る）ことを意味する。したがって、そのブロックの制御
依存性が解決されるとただちに（制御の流れを待たず
に）命令を取り出すことができる。また、その制御依存
性が得られる分岐（制御の流れが得られる分岐ではな
い）が間違って予測された場合には、予測方式で取り出
した命令を破棄されるだけである。たとえば、ブロック
Ｂ９の命令は、ブロックＢ１でのその共用制御依存性が
解決されるか、予測された直後に、ブロックＢ３の命令
とともに取り出すことができる。さらに、ブロックＢ９
からの命令は、ブロックＢ３の終わりにある分岐が間違
って予測された場合ではなく、ブロックＢ１の終わりに
ある制御依存分岐が間違って予測された場合のみ、無駄
な取出しと見なすか、破棄しなければならない。制御依
存性の概念を持たない従来のスーパースカラーは、ブロ
ックＢ７とＢ９がブロックＢ３の終わりにある分岐の従
来の制御流れ予測により取り出され、その後、これが予
測謝りであると判明した場合、ブロックＢ７（またはＢ
６）ならびにＢ９のその予測取出しを破棄するはずであ
る。

【０１３６】２．制御非依存ブロック間でのデータ非依
存性の活用 これらのブロックに至る可能性のあるすべての制御流れ
経路とはデータ非依存でもある制御非依存ブロックの命
令は、このような制御非依存ブロックへの複数フォーク
を介して、同時かつ非予測方式で実行することができ
る。たとえば、ブロックＢ９（Ｂ３とは制御非依存であ
る）の最初の３つの命令は、ブロックＢ３、Ｂ６、Ｂ７
（Ｂ３からＢ９への１組の制御流れ経路上の１組の基本
ブロック）の命令とはデータ非依存である。したがっ
て、これらの命令は、提案したフォーク命令と中断命令
を使用して、非予測方式で取り出して実行することがで
きる。

【０１３７】３．制御非依存ブロック間でのデータ依存
性の予測 将来スレッドの活動とメイン・スレッドの活動とのオー
バラップを高めるためには、将来スレッド内の潜在的デ
ータ依存性に関する何らかの形式の予測が必要である。
図１８および図１９の例を検討する。この場合、ブロッ
クＢ１〜Ｂ１１にはレジスタ４の定義が１つしかない。
これはブロックＢ１０で定義されている。メイン・スレ
ッドの制御の流れについて予測する、すなわち、メイン
・スレッドの制御の流れがブロックＢ１０に達しないと
想定すると、ブロックＢ１２の先頭から始まる将来スレ
ッドとブロックＢ１に継続するメイン・スレッドとのオ
ーバラップを高めることが可能である。ブロックＢ１０
の違反命令に至る正確な制御の流れは、提案した条件付
き中断命令の一部として、＜ＴＸＴ＞としてコード化さ
れる。ただし、制御流れの予測はコンパイル時に行わ
れ、このため、静的分岐予測（またはプロファイル主導
あるいはその両方）の技法だけに基づいて行われること
に留意されたい。また、この場合の正味効果は、条件付
き中断命令と無条件中断命令との間の命令を予測方式で
格上げすることと同様であることにも留意されたい。し
かし、それぞれの保護された（格上げされた）命令の一
部として制御流れ条件をコード化する、保護された（ま
たは格上げされた）命令の既知の技法とは異なり、提案
した技法では、条件付き中断命令と無条件中断命令とを
使用して１群の命令用の条件をコード化する。この手法
の重要な利点としては以下のものがある。

【０１３８】○ アーキテクチャ上の影響が小さいこと 前に示したように、提案した方式の主な利点は、そのア
ーキテクチャ上の影響が相対的に最小限であることであ
る。フォーク命令と中断命令（そのうち、フォーク命令
だけが１次命令コード空間を必要とする）の追加を除
き、既存の命令コード化は影響を受けない。したがっ
て、格上げ手法とは異なり、提案した方式では、制御流
れの予測をコード化するために格上げしたそれぞれの命
令の命令コードで使用可能なビット数に依存しない。

【０１３９】○ 予測した制御流れのコード化の正確さ 新しい（中断）命令では制御流れの予測が排他的にコー
ド化されるので、より多くのビット数を使用してそれを
正確にコード化することができる。たとえば、格上げ方
式では、想定した流れ経路に沿って格上げした命令の深
さをコード化するためにのみ、ある妥協点に達しなけれ
ばならなかった（それぞれの分岐は想定した結果ビット
を有し、最も可能性の高い追跡経路を示していた）。こ
の妥協点は、格上げしたそれぞれの命令の命令コードに
収容できるように、予測した制御流れを簡潔にコード化
するために必要であった。この妥協点の結果、制御非依
存分岐の予測を誤ると、予測方式で実行し格上げした命
令が不必要に破棄されてしまった。本明細書で提案した
手法では、予測した制御流れ経路に沿った制御非依存分
岐が、ＮまたはＴではなくＸによって正しくコード化さ
れる。このため、将来スレッドで予測方式で実行された
命令は、制御非依存分岐の予測を誤っても破棄されな
い。

【０１４０】○ 小規模なコード拡大 典型的なパーコレーションおよび格上げ技法では、想定
した追跡から外れる経路でのコード・コピーまたはパッ
チアップ・コードが必要になる場合が多い。これは、コ
ード・サイズの大幅な拡大に至る可能性がある。提案し
た技法はこれらのオーバヘッドのいずれも持たないの
で、唯一のコード拡大は、１組の命令によって共用され
るフォーク命令と中断命令によるものである。

【０１４１】○ 順次例外処理の実施の単純化 提案した技法には上方コード・モーションが一切なく、
予測方式で実行したコードは依然としてその元の位置だ
けにとどまっている。したがって、メイン・スレッドが
命令の原因である例外を含む将来スレッドと組み合わさ
れるまで、例外処理を容易に遅延させることができる。
すなわち、例外を引き起こす可能性のある予測命令の元
の位置に明示的にマークを付ける必要もなく、正しい順
序で例外を処理することができる。

【０１４２】○ 正確な割込みの実施の単純化 この提案の固有のメイン・スレッドは、順次プログラム
順序で完了する最後の命令をいつも正確に把握してい
る。したがって、割込みを正確に処理するために重要な
余分なハードウェアを設ける必要は全くない。

【０１４３】４．コンパイルとマシン実施態様との結合
解除 前述のように、フォークの任意選択性のため、提案した
アーキテクチャのコンパイルは、多数の活動スレッドが
可能なマシンを想定して行うことができることに留意さ
れたい。しかも、実際のマシン実施態様は、使用可能な
マシン資源に応じて、このようなフォークのほとんどま
たはこのようなフォークの一部に従うか、このようなフ
ォークのいずれにも従わないかを選択することができ
る。したがって、このコンテキストの大部分では、マシ
ン実施態様からコンパイルを結合解除することができ
る。これは、少数または多数の活動スレッドが可能なマ
シンについて個別に再コンパイルする必要がないことも
意味する。

【０１４４】５．ループ反復の並列実行 提案したフォーク命令と中断命令は、ネストしたループ
での反復並列性を効率よく活用するためにも使用するこ
とができる。たとえば、SPECint92ベンチマークの１つ
から前述したサンプル・ループについて検討する。この
ループの内側ループ反復は、前の反復に対して制御とデ
ータの両面で依存している。しかし、内側ループのそれ
ぞれの活動化（すなわち、外側ループ反復）は前のもの
とは無関係である。このため、前のものが完了するまで
待たずに、しかも内部ループの何らかの制御およびデー
タ非依存反復の予測を誤ったときに外側ループ反復から
実行した命令を不必要に破棄せずに、マシンが内側ルー
プの活動化を何度も開始できるようにするため、提案し
たフォーク命令（外側ループ・ボディを開始する）をコ
ンパイラが使用することは可能である。

【０１４５】６．レジスタ・プレッシャの緩和 互いにデータ非依存でもある制御非依存基本ブロック内
の命令は、取り出すことも実行することもできない。起
こりうる明らかな疑問は、このようなデータおよび制御
非依存命令が、同一基本ブロック内にまとめて入れるの
に十分なほどパーコレーションされていないのかという
ことである。優良コンパイラはこのようなパーコレーシ
ョンを実施しようと最善を尽くすはずであるが、必ずこ
れらの命令をまとめてグループ化できるわけではない。
前述のように、すべてのデータおよび制御非依存命令を
効率よくまとめてグループ化できるようにするには、コ
ンパイラは、適切なコード化を行うのに十分なアーキテ
クチャ化レジスタを有する必要がある。たとえば、図１
８および図１９で使用する例の予測上のマシンが４つの
アーキテクチャ化レジスタ、すなわちレジスタ１〜レジ
スタ４しか提供しないものと想定する。このようなマシ
ン用のコンパイラは、追加のスピル・コードを挿入せず
に、制御およびデータ非依存命令を基本ブロックＢ１お
よびＢ１２に単純にグループ化することはできない。フ
ォーク機構により、コンパイラは追加のスピル・コード
がなくても基礎となるデータ非依存性を伝えることがで
きる。事実、既存のスピル・コードの一部は、Ｂ１２が
実行時に実際にフォークされると冗長（たとえば、基本
ブロックＢ１２内の最初の２つのロード）になる可能性
がある。このようなスピル・コードは、前述のようにSK
IP命令を使用して最適化することができる。

【０１４６】７．制御依存ブロック間の予測 これまでの説明でフォークを使用したのは、制御非依存
ブロックの並列実行の場合だけであった。この概念は、
制御依存ブロックを含むようにさらに拡張することがで
きる。さらにこれは、両方の分岐経路を予測方式で実行
できる能力を意味する。追加の実施コストが必要ではあ
るが、このような予測はいずれもアーキテクチャに対し
てこれ以上影響を及ぼすことはない。この形式の予測の
追加の有用性は、ある程度は（１つの分岐経路に沿っ
て）現行予測スーパースカラーにすでに使用されている
が、さらに検討する必要がある。図２０で使用する例
は、どちらもＢ１００に対して制御依存しているブロッ
クＢ２００およびＢ３００のような制御依存ブロック間
で予測するためにフォーク命令と中断命令を使用する場
合を示している。ブロックＢ１００のフォークも、両方
の分岐経路に沿って予測し、実行時の実際の制御の流れ
（Ｂ２００またはＢ３００）に基づいて適切に命令を破
棄するためのものである。

【０１４７】８．スレッド管理の簡略化 ○ スレッド間の同期：固有のメイン・スレッドと残り
の将来スレッドという概念は、スレッド間の同期を簡略
化した機構を提供し、低いオーバヘッドを意味する。明
示的な中断点では、将来スレッドは単にそれ自体を中断
し、メイン・スレッドの制御が将来スレッドに到達する
のを待つだけである。あるいは、その実行中の様々な時
点で将来スレッドが他のスレッドとの明示的スレッド間
同期を試みることもできる。しかし、このようにスレッ
ド間同期がさらに精巧になると、ハードウェア／ソフト
ウェアのオーバヘッドが増すことを意味する。

【０１４８】○ スレッド間通信：アーキテクチャ化マ
シン状態のコピーによるフォークと、前述の組合せ動作
の概念により、オーバヘッドの低いスレッド間通信の機
構が提供される。オーバヘッドがこれよりかなり高い代
替機構は、たとえば、メッセージにより、活動スレッド
間の連続通信プロトコルを提供する明示通信プリミティ
ブをもたらすことができる。

【０１４９】○ スレッドのスケジューリング：本発明
で提案した機構では、結果的に（前述のように）フォー
クの任意選択性が得られるが、FORK命令に応答してスレ
ッドをスケジューリング（フォーク）するために実行時
スレッド・スケジューリング・ハードウェアを必要とし
ないので、動的スレッド・スケジューリングも簡略化さ
れる。したがって、スレッド・スケジューリング・ハー
ドウェハは、すべてのFORK命令が暗示する将来スレッド
（複数も可）の待ち行列化と管理を負担する必要がな
い。このため、再コンパイルせずに各種のマシン実施態
様に適合できることなど、その他の利点により、静的ス
レッド・スケジューリングに対する動的スレッドのハー
ドウェア・オーバヘッドが引き下げられている。

【０１５０】代替実施例１１： 以下の説明は、例示のアーキテクチャ内でのマルチスカ
ラー（マルチスレッド化）処理の順方向および逆方向互
換実施態様について説明するものである。

【０１５１】その分岐プロセッサ命令セット内の例示の
命令セット・アーキテクチャ（「ＩＳＡ」）はローカル
分割（フォーク）命令を含む。このローカル分割命令
は、それ以外には使用されない分岐オプション（「Ｂ
Ｏ」）フィールドにコード化される。あるいは、このロ
ーカル分割命令は、「ノー・オペレーション」（「ＮＯ
Ｐ」）命令にコード化することもできる。プログラムさ
れた命令シーケンスの制御の流れでのローカル分割命令
の検出に応答して、プロセッサは、複数の命令からなる
指定のコード・ブロック（または「セット」）の予測実
行を開始する。

【０１５２】このようにして、ローカル分割命令はプロ
セッサにとって「ヒント」として機能する。ローカル分
割命令は、プロセッサがもっと遅い時期に制御の流れで
指定のコード・ブロックを検出する可能性があること
と、そのもっと遅い時期に先立って指定のコード・ブロ
ックの実行を予測方式で開始する方がプロセッサにとっ
て有利になる可能性があることをプロセッサに示す。し
たがって、プロセッサ（第１のタイプのプロセッサ）が
もっと遅い時期に制御の流れで指定のコード・ブロック
を検出した場合、プロセッサはすでに指定のコード・ブ
ロックの少なくとも一部を実行しており、指定のコード
・ブロックを並列コードとして実行することになる。に
もかかわらず、プロセッサは指定のコード・ブロックを
予測方式で実行するので、その指定のコード・ブロック
は順次コードの効果を達成する。

【０１５３】この実施例の重要な態様では、ローカル分
割命令は、それより旧型のプロセッサ・アーキテクチャ
による処理との互換性を有している。かなり旧型のプロ
セッサ・アーキテクチャでは、プロセッサは分割命令を
無条件分岐命令として（あるいはＮＯＰ命令として）解
釈する。

【０１５４】ＰｏｗｅｒＰＣマイクロプロセッサ・アー
キテクチャでは、ローカル分割命令内でのＢＯコード化
例は、ＢＯ＝１ｚ１１ｚ、００１１ｙ、０１１１ｙであ
る。旧型のプロセッサ・アーキテクチャでは、このよう
なＢＯのコード化は無効である。にもかかわらず、この
実施例の重要な態様では、旧型のプロセッサ・アーキテ
クチャにより動作するプロセッサは、制御の流れでこの
ような無効なＢＯのコード化をプロセッサが検出したこ
とに応答して「無効動作」割込みを生成することはな
い。むしろ、制御の流れでこのような無効なＢＯのコー
ド化を検出したことに応答して、プロセッサ（旧型のプ
ロセッサ・アーキテクチャにより動作する）は、そのＢ
Ｏのコード化がそれぞれ１ｚ１ｚｚ、００１ｚｙ、また
は０１１ｚｙである場合と同じように命令を処理する。

【０１５５】したがって、この実施例の重要な態様で
は、プロセッサ（旧型のプロセッサ・アーキテクチャに
より動作する第２のタイプのプロセッサ）が制御の流れ
でローカル分割命令を検出したことに応答して、プロセ
ッサは、より基本的な分岐機能を実行し、その結果、通
常の命令処理は順次経路（第１組の命令）または目標経
路（第２組の命令）のいずれかに沿って続行され、両方
に沿って続行されることはない。

【０１５６】比較すると、プロセッサがこの実施例のよ
り進歩したプロセッサ・アーキテクチャにより動作する
場合、プロセッサ（第１のタイプのプロセッサ）は、制
御の流れでのローカル分割命令の検出に応答して、より
有利に動作する。このようなプロセッサの場合、通常の
命令実行は、目標経路または順次経路のいずれかの指定
経路（第１組の命令）に沿って続行される。さらに、指
定外経路に沿った第１のアドレスが予測取出しアドレス
として使用されるように、予測経路命令実行が指定外経
路（第２組の命令）に沿って開始される。したがって、
この状況では、プロセッサは２つの経路に沿って同時に
命令を実行し、一方の経路（第１組の命令）は非予測方
式で実行され、もう一方の経路（第２組の命令）は予測
方式で実行される。これは、特定の時期に単一経路（第
１組の命令）だけが非予測方式で実行される、旧型のプ
ロセッサ・アーキテクチャにより動作するプロセッサと
は区別可能である。

【０１５７】実施例のより進歩したプロセッサ・アーキ
テクチャによれば、プロセッサが制御の流れで複数のロ
ーカル分割命令を検出した場合、プロセッサは３つ以上
の経路を同時に実行することができる。この実施例で
は、ローカル分割命令の意味が、ネストされた分割命令
と、単一非予測経路からの複数の分割命令を完全にサポ
ートしている。

【０１５８】実施例の進歩したプロセッサは、予測経路
が非予測になるまで、その経路に沿って実行したどの命
令についてもその結果を（アーキテクチャ化レジスタ
に）コミットしない。むしろ、このような結果は、アー
キテクチャ化レジスタにコミットされるまで、一時的に
名前変更バッファに格納される。順次プログラム順序と
一致して、非予測経路と予測経路との依存関係は、予測
経路命令が非予測経路命令の後に続く場合と同じように
ハードウェアによって検出され処理される。プロセッサ
が非予測経路に沿ってすべての命令を取り出し、予測経
路の第１の命令を取り出そうと試み、予測経路の第１の
命令の前にすべての命令の結果を（アーキテクチャ化レ
ジスタに）コミットしたことに応答して、プロセッサ
は、予測経路に沿って実行した命令の結果のうち使用可
能なものを（アーキテクチャ化レジスタに）コミットす
る。このようにして、予測経路は非予測経路になる。プ
ロセッサは予測経路に沿ってすでに命令を実行している
ので、このような命令の再取出しは行わない。これは、
予測経路の「結合」と呼ばれる。どのような特定の時期
でも、単一マイクロプロセッサで実行される非予測経路
はせいぜい１つである。にもかかわらず、実施例の進歩
したプロセッサでは、非予測経路によって１つまたは複
数の予測経路を同時に（並列に）予測方式で実行するこ
とができる。最適化したソフトウェアはプロセッサが処
理可能な予測経路の数を参照して設計することができる
が、プロセッサが処理可能な予測経路の数とは無関係に
ソフトウェアを設計できることは有利である。

【０１５９】代替実施例１１に関連する依存関係の前提
事項と実施上の問題： パフォーマンスを改善するため、実施例では様々なプロ
トコルをサポートしている。ローカル分割命令の目標
は、現在の非予測命令経路の後でプロセッサが検出する
可能性のある１つまたは複数の命令経路についてプロセ
ッサにソフトウェア上の「ヒント」を提供することであ
る。これは、明示ソフトウェア分岐予測の変形である。
通常、ハードウェアは（資源およびサイクル時間によっ
て）複数の命令を並列に同時処理するための機会を検出
する際に使用する小さい時間ウィンドウに限定されるの
で、これは有利である。比較すると、ソフトウェア・コ
ンパイラは通常、もっと大きい時間ウィンドウを自由に
分析することができる。

【０１６０】このような大きい時間ウィンドウ内では、
ハードウェアに比べ、ソフトウェアの方がより多くの情
報を分析することができ、複数命令経路（またはスレッ
ド）の実行時に並列性を達成するためにより容易に命令
コード・シーケンスを操作することができる。

【０１６１】代替実施例１１ａ： この代替実施例では、プロセッサ・ハードウェアが依存
関係の前提事項を頼りにしない。ハードウェアは、予測
経路と非予測経路とのレジスタおよびメモリ両方の依存
関係を調整する。ただし、２つの経路間に依存関係があ
る場合は、ローカル分割プリミティブを実施してもパフ
ォーマンスの向上がほとんどまたはまったく達成されな
いこともあり得る。

【０１６２】この代替実施例では、プロセッサは予測方
式でのメモリへの格納を行わない。プロセッサが予測ス
トア用のストア待ち行列を含むことは可能である。ま
た、プロセッサは、同時に実行した予測コード経路と非
予測コード経路とのメモリ依存関係も調整する。したが
って、プロセッサが非予測経路でストア動作を検出し、
予測経路でロード動作を検出する場合、プロセッサは、
ロード動作が正しい情報を含むように２つの動作を解決
する。メモリの別名化が起こるとプロセッサのパフォー
マンスが最適レベルを下回る可能性があるが、プロセッ
サのこのパフォーマンス態様は、ローカル分割プリミテ
ィブを実施してもマイナスの影響を受けることはない。

【０１６３】さらにプロセッサは、予測経路と非予測経
路とのレジスタ依存関係を調整する。プロセッサ・ハー
ドウェアは、２つの経路間のレジスタ依存関係を検出
し、このような依存関係を適当に解決する。プロセッサ
が予測経路と非予測経路とのレジスタ依存関係を調整で
きる能力は、ローカル分割プリミティブを実施してもマ
イナスの影響を受けることはない。

【０１６４】代替実施例１１ｂ： この代替実施例では、プロセッサ・ハードウェアが様々
な依存関係の前提事項を実施する。ハードウェアは、予
測経路と非予測経路とのメモリ依存関係を調整する。た
だし、２つの経路間にメモリ依存関係が存在する場合
は、ローカル分割プリミティブを実施してもパフォーマ
ンスの向上がほとんどまたはまったく達成されないこと
もあり得る。

【０１６５】この代替実施例では、プロセッサは予測方
式でのメモリへの格納を行わない。プロセッサが予測ス
トア用のストア待ち行列を含むことは可能である。ま
た、プロセッサは、同時に実行した予測コード経路と非
予測コード経路とのメモリ依存関係も調整する。したが
って、プロセッサが非予測経路でストア動作を検出し、
予測経路でロード動作を検出する場合、プロセッサは、
ロード動作が正しい情報を含むように２つの動作を解決
する。メモリの別名化が起こるとプロセッサのパフォー
マンスが最適レベルを下回る可能性があるが、プロセッ
サのこのパフォーマンス態様は、ローカル分割プリミテ
ィブを実施してもマイナスの影響を受けることはない。

【０１６６】プロセッサは、予測経路と非予測経路との
レジスタ依存関係を認めない。プログラムがレジスタ依
存関係を頼りにする場合、ローカル分割プリミティブを
実施するプロセッサ・ハードウェアが生成する結果は、
ローカル分割プリミティブを実施しないプロセッサ・ハ
ードウェアとは異なる可能性がある。

【０１６７】代替実施例１１ｃ： この代替実施例では、プロセッサ・ハードウェアがより
多くの依存関係の前提事項を実施する。ハードウェア
は、予測経路と非予測経路とのメモリ依存関係もレジス
タ依存関係も調整しない。

【０１６８】プロセッサは、予測方式でのメモリへの格
納を行わない。プロセッサが予測ストア用のストア待ち
行列を含むことは可能である。

【０１６９】プロセッサは、予測経路と非予測経路との
依存関係を認めない。プログラムがこのような依存関係
を頼りにする場合、ローカル分割プリミティブを実施す
るプロセッサ・ハードウェアが生成する結果は、ローカ
ル分割プリミティブを実施しないプロセッサ・ハードウ
ェアとは異なる可能性がある。

【０１７０】代替実施例１１のコード構造例： ローカル分割プリミティブでの使用に適した（制御流れ
の観点から見た）コード構造の例を以下に示す。

【０１７１】図２１を参照すると、ローカル分割プリミ
ティブの主な使い方は、制御流れ図の２つの独立強接続
領域（「ＳＣＲ」）の並列実行である。図２１のＢとＣ
は、２つの独立ＳＣＲである。Ｂの最後の命令は、Ｃ周
辺で分岐するための条件付き分岐命令である。ローカル
分割命令はＡの終わり、Ｂの上に追加される。このロー
カル分割命令は、目標予測ブロックとしてＣの先頭を指
し示す（図２１の薄いグレイの点線は予測経路であ
る）。このようにして、ソフトウェアは、介入分岐の数
または２つのＳＣＲであるＢとＣの初期アドレス間の距
離にかかわらず、Ｂと並列にＣの予測実行を開始するよ
う、プロセッサ・ハードウェアに命令する。Ｂの終わり
の条件付き分岐が実行されると、Ｃの予測実行による結
果はいずれもプロセッサのアーキテクチャ化レジスタに
コミットされない。しかし、Ｂの終わりの条件付き分岐
が実行されない場合は、Ｃの実行による予測結果はプロ
セッサのアーキテクチャ化レジスタにコミットされ、プ
ロセッサはＣの経路から命令の実行を続行する。このプ
ロセッサはＢとＣとの依存関係を調整する。

【０１７２】図２２を参照すると、ローカル分割プリミ
ティブのもう１つの使い方はループのアンロールであ
る。ループの早い時期に反復間依存関係を解決すること
は可能である。その場合、ローカル分割命令はハードウ
ェアでループをアンロールするのに有用である。このル
ープは、２つのセクション、すなわちＢとＣに分割され
る。この例では、反復ｎ＋１（Ｂ（ｎ＋１））のＢ部分
は反復ｎ（Ｂ（ｎ））のＢ部分に依存するが、反復ｎ
（Ｃ（ｎ））のＣ部分には依存しない。そのような状況
では、Ｂ（ｎ）が完了するとただちにＢ（ｎ＋１）を開
始することができる。

【０１７３】このような状況の例としては、プロセッサ
がループの開始時にアドレス・レジスタを更新し、次に
レジスタにデータをロードし、データを操作し、ループ
の第２部でそのデータをメモリに書き戻すというループ
がある。この場合、アドレス・レジスタの更新後に、ル
ープの次の反復の実行を予測方式で開始することができ
る。このようにして、プロセッサは、長い遅延事象にも
かかわらず、命令の実行を続行する。たとえば、単一予
測経路の実行を開始することにより、プロセッサは、反
復ｎでキャッシュまたは変換索引バッファ（「ＴＬ
Ｂ」）のミスが発生しても、ループの反復ｎ＋１を開始
することができる。ｎとｎ＋１の両方の反復でキャッシ
ュ・ミスが発生した場合、ローカル分割命令は、（適当
にパイプライン化したバスにより）直列ではなく並列に
そのミスを解決するよう、プロセッサに命令することが
できる。

【０１７４】したがって、図２２では、ローカル分割命
令がＢの終わり、Ｃの上に追加される。このローカル分
割命令は、目標予測ブロックとしてＢの先頭を指し示す
（図２２の薄いグレイの点線は予測経路である）。この
ようにして、ソフトウェアは、Ｃ（ｎ）と並列にＢ（ｎ
＋１）の予測実行を開始するよう、プロセッサ・ハード
ウェアに命令する。ループ閉鎖分岐が実行されると、Ｂ
（ｎ＋１）の実行による予測結果はいずれもプロセッサ
のアーキテクチャ化レジスタにコミットされ、プロセッ
サは反復ｎ＋１の経路から命令の実行を続行する。しか
し、ループ閉鎖分岐が実行されない場合は、反復ｎ＋１
の予測実行による結果はいずれもプロセッサのアーキテ
クチャ化レジスタにコミットされない。このプロセッサ
はＢ（ｎ＋１）とＣ（ｎ）との依存関係を調整する。

【０１７５】代替実施例１１のハードウェア実現例： 複数の命令スレッドを並列に実行するためのプロセッサ
・ハードウェアの例を以下に示す。実施例のローカル分
割技法を実施するために、様々な代替ハードウェアが可
能である。複数の命令スレッドを並列に実行するため、
命令キャッシュは２重ポートにすることができる。ある
いは、以下の例のように、プロセッサが２つのスレッド
間を仲裁する。実施例によるローカル分割プリミティブ
の場合、幅広いスーパースカラー・プロセッサ実施態様
でより積極的に実行ユニットを使用することにより、プ
ロセッサ全体の命令処理スループットを大幅に増加する
ことが可能である。

【０１７６】図２３を参照すると、命令取出し器は、一
度に２つの異なる命令スレッドから取り出すことができ
る。それぞれの命令には１ビット・タグが関連づけられ
ている。この１ビット・タグは、その関連命令が属する
スレッドを指定する。いずれかの特定の時期に、２つの
スレッドのうちの一方が最も可能性の高い経路と見なさ
れるので、そのスレッド方が命令取出しと実行資源スケ
ジューリングの両方について優先順位が高くなる。

【０１７７】プロセッサは１次取出し経路に沿って命令
を実行するので、プロセッサが第１のスレッドと並列に
第２のスレッドの実行を開始するような状況が２通りあ
る。第１の状況では、プロセッサが未解決の条件付き分
岐を検出する。その場合、最も可能性の高い（予測）経
路が１次取出し器（非予測経路命令取出し器）で取り出
され、可能性の低い経路が２次取出し器（予測経路命令
取出し器）で取り出される。第２の状況では、プロセッ
サが１次取出し器でローカル分割命令を検出する。１次
取出し器でのローカル分割命令の検出に応答して、２次
取出し器が（２次取出し器によって取り出された命令の
影響とともに）除去され、２次取出し器がローカル分割
命令に指定した予測取出しアドレスにリセットされる。
プロセッサが（このような分割の結果得られる）予測経
路命令スレッドのアドレスをレジスタに保管することは
注目に値する。

【０１７８】プロセッサが命令スレッドを予測方式で実
行している間に、プロセッサが追加のローカル分割命令
を検出する場合、プロセッサは新しい命令スレッドへの
追加の分割を開始しない。むしろ、プロセッサは、追加
のローカル分割命令後も続行し、それを通常の分岐命令
と同じように処理する。これは、プロセッサには２つの
取出し器しか含まれていないので、新しい命令スレッド
に使用可能な取出し器資源がそれ以上存在しないからで
ある。にもかかわらず、プロセッサは、（追加のローカ
ル分割命令に指定された）新しい命令スレッド・アドレ
スを保管し、スレッドが結合され、空いている取出し器
資源が使用可能になったときに、その追加分割を開始す
ることができる。分岐ユニットは、（１次取出し器から
と２次取出し器内の）両方のスレッド用の分岐プロセッ
サ命令を処理し、サイクル当たり２つの取出しアドレス
を生成する。プロセッサはこの２つの取出しアドレスを
仲裁して命令キャッシュ（たとえば、インタリーブ・キ
ャッシュ）に入れ、（待ち行列が満杯になる程度に応じ
て）一般に非予測アドレスの方が優先順位が高くなる。

【０１７９】図２４を参照すると、プロセッサは、命令
待ち行列から複数の整数実行ユニットと浮動小数点実行
ユニットに命令をディスパッチする。明確にするため、
図２４では整数ユニットのみ示している。ｎ個の整数実
行ユニットがある場合、プロセッサは単一サイクルでｎ
個の整数命令をディスパッチすることが好ましい。特定
のサイクル中に１次（非予測）命令待ち行列から（ｎ−
ｋ）個の命令しかディスパッチ可能ではない場合、２次
（予測）待ち行列がｋ個の命令をディスパッチして
「穴」を埋める。このようにして、プロセッサは、本来
はアイドル状態のサイクル中にその資源をより十分に使
用することにより、全体的なスループットの向上を達成
する。第２のスレッドを処理できる能力を持たない同様
のプロセッサが達成する最大パフォーマンスに比べ、１
次（非予測）経路の実行時間が増えないことは注目に値
する。２つまたはそれ以上の整数実行ユニットと１つの
分岐ユニットを備えた典型的なプロセッサは、１〜１．
５（整数コードの場合）の平均ＩＰＣを達成するので、
このようなプロセッサには（平均で）０．５を上回るア
イドル実行ユニットが存在する。追加の実行ユニットを
使用中の状態に維持するための技法がある場合は、この
ようなユニットを追加すると有利である可能性がある。

【０１８０】プロセッサは、命令をディスパッチする場
合、その命令にタグを割り当てる。そのタグは、命令が
発生した経路を識別するものである。さらに、その命令
が予測実行経路または非予測実行経路の一部であるかど
うかを示すために、そのタグにマークが付けられる。プ
ロセッサの完了ユニットが非予測実行経路からの命令を
完了すると、プロセッサは命令の結果（複数も可）をプ
ロセッサのアーキテクチャ化汎用レジスタ（「ＧＰ
Ｒ」）またはメモリに書き戻す。完了ユニットが予測実
行経路からの命令を完了すると、プロセッサは命令の結
果（複数も可）をシャドウ・レジスタ（複数も可）に格
納する。

【０１８１】この例のシャドウ構造は、予測ＧＰＲと予
測ストア待ち行列である。経路が予測から非予測に変化
すると、プロセッサは、その経路の命令の結果（シャド
ウ構造に格納されているもの）をコミットし、予測ＧＰ
ＲがアーキテクチャＧＰＲにコピーされ、予測ストア待
ち行列がメモリにコピーされるようにする。プロセッサ
は予測ストア待ち行列のメモリの一貫性を維持する。ス
トア待ち行列が満杯で、プロセッサが予測実行経路でス
トア命令を検出する場合、プロセッサは予測ストア命令
を実行しない。むしろ、プロセッサは、予測経路の結合
（その時点でプロセッサはストア待ち行列をメモリにコ
ピーする）または取消し（その時点でプロセッサはスト
ア待ち行列を除去する）ができるようになるまで、予測
経路の実行を停止する。

【０１８２】さらにこの例のプロセッサは、予測実行経
路と非予測実行経路とのデータ依存関係を検出し、その
依存関係から回復する。このためにプロセッサは、予測
方式で読み取られたレジスタと、予測方式で読み取られ
たメモリ・アドレスを監視し、依存関係を検出する。

【０１８３】ある例では、プロセッサが依存関係を検出
したことに応答して、プロセッサは単に予測経路を破棄
するだけである。より好ましい例では、プロセッサは予
測経路を破棄し、次に予測経路の先頭（すなわち、ロー
カル分割命令の予測目標アドレス）から同じ予測経路を
再実行する。この予測目標アドレスは、結合アドレスと
して使用した経路タグとしてそのマシン状態にプロセッ
サによって事前に格納されている。この２つの例には同
じ欠点がある。すなわち、ソフトウェアが独立コード・
ブロックの終わりを識別するための明示的な同期機構が
存在しないことである。したがって、プロセッサが依存
命令を取り出して実行し、それにより、予測経路全体が
破棄されることが起こりうる。この結果、難しいスケジ
ューリング問題が発生するが、それは、（この２つの例
によれば）ソフトウェアによるローカル分割命令のスケ
ジューリングの時期を、独立コードの何らかの予測実行
を可能にするために十分早い時期だが、経路が結合され
るかまたは依存関係が解決される前にデータ依存関係を
有する命令まで予測実行が及ばないように十分遅い時期
にする必要があるからである。

【０１８４】実施例における依存関係回復の最小限の要
件は以下の通りである。プログラムのデータ依存関係グ
ラフは、「＜」を使用した部分命令順序付けとして示す
ことができる。この場合、Ａ＜Ｂ（Ａ小なることＢ）
は、ＡがＢに依存するか、またはＡがＣに依存し、Ｃ＜
ＢになるようなＣが存在することを意味する。依存関係
が検出された場合、プロセッサはその依存関係の原因と
なる命令より先行する命令だけを再実行することが好ま
しい。また、注目すべきことに、制御依存関係は別の部
分命令順序付けを定義し、再実行された命令が別の制御
経路を取る場合はプロセッサが制御依存関係を適当に処
理する（たとえば、正確な割込みと分岐が適当に処理さ
れる）。したがって、実施例のプロセッサは、その依存
関係の影響を受ける命令だけを再実行する。これによ
り、前述のスケジューリング問題が緩和される。

【０１８５】代替実施例１１の要約： ローカル分割命令は、極端に複雑かつ高価なハードウェ
アを使用せずにプロセッサが複数の独立命令経路を処理
できるようにすることにより、並列性をアンロックする
ために使用するプリミティブである。このプリミティブ
により、プロセッサ・ハードウェアが並列実行するため
の独立経路をコンパイル済みソフトウェアで指定するこ
とができる。このプリミティブを既存の命令セット・ア
ーキテクチャ（「ＩＳＡ」）を追加して細密並列性をア
ンロックできることは有利である。

【０１８６】この技法はいくつかの利点を達成する。第
１に、この技法は既存ＩＳＡの基本概念との一貫性を達
成する。第２に、この技法は順方向および逆方向の互換
性を達成する。したがって、コンパイル済みソフトウェ
アがローカル分割プリミティブを含むか、除外するかに
かかわらず、また、プロセッサがローカル分割プリミテ
ィブ自体を実行できるほど十分に進歩したものであるか
どうかにかかわらず、このようなソフトウェアは既存Ｉ
ＳＡと一致するどのプロセッサでも（再コンパイルなし
に）実行可能である。第３に、コンパイル済みソフトウ
ェアがローカル分割プリミティブを含む場合、このよう
なソフトウェアは、ローカル分割プリミティブ自体を実
行できるほど十分に進歩していないプロセッサでも（再
コンパイルなしに）実行可能であり、ローカル分割プリ
ミティブを除外するコンパイル済みソフトウェアと比較
して、パフォーマンスの低下はほとんどまたはまったく
発生しない。

【図面の簡単な説明】

【図１】本発明の方法を実行すると思われる典型的なプ
ロセッサ編成のハードウェアのブロック図である。

【図２】本発明の方法を実行すると思われる典型的なプ
ロセッサ編成のハードウェアのブロック図である。

【図３】本発明の方法の諸ステップを示す流れ図であ
る。

【図４】本発明の方法の諸ステップを示す流れ図であ
る。

【図５】FORK命令の形式構造を示すブロック図である。

【図６】UNCOND_SUSPEND命令の形式構造を示すブロック
図である。

【図７】SUSPEND命令の形式構造を示すブロック図であ
る。

【図８】FORK_SUSPEND命令の形式構造を示すブロック図
である。

【図９】SKIP命令の形式構造を示すブロック図である。

【図１０】FORK_S_SUSPEND命令の形式構造を示すブロッ
ク図である。

【図１１】FORK_M_SUSPEND命令の形式構造を示すブロッ
ク図である。

【図１２】FSKIP命令の形式構造を示すブロック図であ
る。

【図１３】SKPMG命令の形式構造を示すブロック図であ
る。

【図１４】FORK、UNCOND_SUSPEND、SUSPEND、FORK_SUSP
ENDの各命令の形式構造のコード化の好ましい実施例を
示す１組のブロック図である。

【図１５】FORK、UNCOND_SUSPEND、SUSPEND、FORK_SUSP
ENDの各命令の形式構造のコード化の好ましい実施例を
示す１組のブロック図である。

【図１６】FORK、UNCOND_SUSPEND、SUSPEND、FORK_SUSP
ENDの各命令の形式構造のコード化の好ましい実施例を
示す１組のブロック図である。

【図１７】FORK、UNCOND_SUSPEND、SUSPEND、FORK_SUSP
ENDの各命令の形式構造のコード化の好ましい実施例を
示す１組のブロック図である。

【図１８】本発明で提案した命令の一部をアセンブリ・
コード・サンプルで使用した場合を示す図である。

【図１９】本発明で提案した命令の一部をアセンブリ・
コード・サンプルで使用した場合を示す図である。

【図２０】本発明で提案した命令の一部をアセンブリ・
コード・サンプルで使用した場合を示す図である。

【図２１】２つの独立した強接続領域（「ＳＣＲ」）を
並列実行するためにローカル分割命令を使用する方法を
示す図である。

【図２２】ループ・アンロールのためにローカル分割命
令を使用する方法を示す図である。

【図２３】代替実施例１１による命令取出しユニットの
ブロック図である。

【図２４】代替実施例１１による完了制御論理装置のブ
ロック図である。

【符号の説明】

１００ メモリ １１０ 命令キャッシュ １１５ ポート １２０ プログラム・カウンタ １３０ スレッド管理ユニット １４０ ディスパッチャ １４１ 命令バッファ １５０ スケジューラ １６０ レジスタ・ファイル １７０ データ・キャッシュ １９０ 完了ユニット

───────────────────────────────────────────────────── フロントページの続き (72)発明者 チャールズ・ロバーツ・モア アメリカ合衆国78750 テキサス州オー スチン ロイヤルウッド・ドライブ 8802 (72)発明者 テレンス・マシュー・ポター アメリカ合衆国78731 テキサス州オー スチン トゥイン・レッジ・コーヴ 6107 (56)参考文献 特開 平５−233283（ＪＰ，Ａ) 特開 平５−265755（ＪＰ，Ａ) 情報処理学会研究報告、ＶＯＬ．94、 ＮＯ．66（94−ＡＲＣ−107）、Ｐ．89 〜112（1994年) 電子情報通信学会論文誌、ＶＯＬ．Ｊ 77−Ｄ−Ｉ、ＮＯ．５、Ｐ．343〜353 （1994年) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/46 G06F 9/38 G06F 15/16 G06F 9/45 ＩＮＳＰＥＣ（ＤＩＡＬＯＧ) ＪＩＣＳＴファイル（ＪＯＩＳ) ＣＳＤＢ（日本国特許庁)

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】命令セットアーキテクチャを同じくするが
   特定の命令に対して異なる応答をする第１のタイプの処
   理システムおよび第２のタイプの処理システムの何れに
   おいても特定の命令を処理する方法において、 処理システムによる特定の命令を含む第１スレッドの命
   令の実行を開始するステップであって、前記特定の命令
   が前記第１スレッドの後にある第２スレッドの最初の命
   令の指示を含むステップと、 前記特定の命令の実行および前記処理システムが第１の
   タイプであることに応答して、前記第２スレッドの最初
   の命令およびこれに続く命令の実行を開始しながら、前
   記処理システムによる前記第１スレッドの実行を続行す
   るステップと、 前記処理システムが第１のタイプであるとき前記第１ス
   レッドの実行の結果に応答して、前記第２スレッドの前
   記実行の結果を１つまたは複数のアーキテクチャ化レジ
   スタに選択的にコミットするステップと、 を含み、 前記特定の命令が前記第２のタイプの処理システムで実
   行されるときには、前記第２スレッドの実行を開始せず
   に前記第１スレッドの実行を続行するようにデコードさ
   れることを特徴とする、命令スレッドを処理する方法。
2. 【請求項２】前記選択的にコミットするステップは、前
   記処理システムによる前記第１スレッドの実行の経路を
   判定し、判定の結果により前記実行の結果を１つまたは
   複数のアーキテクチャ化レジスタに選択的にコミットす
   るステップを含むことを特徴とする、請求項１に記載の
   方法。
3. 【請求項３】前記特定の命令が複数の第２スレッドの最
   初の命令の指示を含むことを特徴とする、請求項１に記
   載の方法。
4. 【請求項４】前記特定の命令は第２のタイプの処理シス
   テムでは無条件分岐命令としてデコードされることを特
   徴とする、請求項１に記載の方法。
5. 【請求項５】前記特定の命令は第２のタイプの処理シス
   テムではＮＯＰ命令としてデコードされることを特徴と
   する、請求項１に記載の方法。