JP6761565B2 - アウトオブオーダーハードウェアソフトウェア協調設計プロセッサにおいてスタック同期命令を用いてプレディケート値のスタックを実装し維持する方法および装置 - Google Patents

Description

本開示は、処理論理と、マイクロプロセッサと、そのプロセッサまたは他の処理論理により実行されたときに論理演算、数値演算、もしくは他の機能演算を行う関連する命令セットアーキテクチャとの分野に関する。

在来のプロセッサアーキテクチャは、論理的分岐を通して条件付き実行を行う。或るプロセッサアーキテクチャは、プログラムにおいて利用し得る命令レベルの並列性を高めるために、命令を投機的に実行することを可能にする。或る分岐予測実装は、大抵の環境において非常に正確である。しかし、予測が間違っていると、回復コストと予測ミスペナルティとは顕著になることがある。命令プレディケーションは、命令の条件付き実行のために使用される（制御依存性をデータ依存性に変換することにより）分岐を除去するアーキテクチャ的機能である。命令プレディケーションが実装されたとき、命令の実行またはリタイアメントは条件付きであって、別のプレディケートレジスタに保持されているプレディケート値に基づく。しかし、命令プレディケーションは、アウトオブオーダーパイプラインに統合するには複雑な機能であり得る。

添付図面の図において実施形態が限定ではなくて例として示されている。

実施形態による典型的なインオーダーフェッチ、デコード、リタイアパイプラインと典型的なレジスタリネーミング、アウトオブオーダー発行／実行パイプラインとの両方を示すブロック図である。

実施形態によるプロセッサに含まれるべきインオーダーフェッチ、デコード、リタイアコアの典型的実施形態と、典型的レジスタリネーミング、アウトオブオーダー発行／実行アーキテクチャコアとの両方を示すブロック図である。

より具体的な典型的インオーダーコアアーキテクチャのブロック図である。 より具体的な典型的インオーダーコアアーキテクチャのブロック図である。

メモリコントローラおよび専用論理が統合されているシングルコアプロセッサおよびマルチコアプロセッサのブロック図である。

一実施形態によるシステムのブロック図を示す。

一実施形態による第２システムのブロック図を示す。

一実施形態による第３システムのブロック図を示す。

一実施形態によるシステムオンチップ（ＳｏＣ（ｓｙｓｔｅｍ ｏｎ ａ ｃｈｉｐ））のブロック図を示す。

実施形態による、ソース命令セット内のバイナリ命令をターゲット命令セット内のバイナリ命令に変換するソフトウェア命令コンバータの使用を対照するブロック図を示す。

レジスタエイリアステーブルを用いてプレディケートリネーミングを実装するアウトオブオーダープロセッサのための典型的パイプラインのブロック図である。

一実施形態による、プレディケートレジスタスタックを実装したアウトオブオーダープロセッサのためのパイプラインのブロック図である。

実施形態を実装し得る典型的プロセッサのブロック図である。

一実施形態による、プレディケートレジスタスタックを実装するためのプロセッサコンポーネントのブロック図である。 一実施形態による、プレディケートレジスタスタックを実装するためのプロセッサコンポーネントのブロック図である。

一実施形態による、プレディケートスタックを管理する命令を含む処理システムのブロック図である。

一実施形態による、典型的プレディケートスタック管理命令を処理する論理の流れ図である。

実施形態による、特定のプレディケートスタック管理命令の流れ図である。 実施形態による、特定のプレディケートスタック管理命令の流れ図である。 実施形態による、特定のプレディケートスタック管理命令の流れ図である。

実施形態による、一般的ベクトルフレンドリ命令フォーマットと、その命令テンプレートとを示すブロック図である。 実施形態による、一般的ベクトルフレンドリ命令フォーマットと、その命令テンプレートとを示すブロック図である。

本発明の実施形態による典型的な特定のベクトルフレンドリ命令フォーマットを示すブロック図である。 本発明の実施形態による典型的な特定のベクトルフレンドリ命令フォーマットを示すブロック図である。 本発明の実施形態による典型的な特定のベクトルフレンドリ命令フォーマットを示すブロック図である。 本発明の実施形態による典型的な特定のベクトルフレンドリ命令フォーマットを示すブロック図である。

一実施形態による、スカラーおよびベクトルレジスタアーキテクチャのブロック図である。

プレディケーションの現行の実装は、通例、プレディケートレジスタを在来のレジスタファイルに類似する仕方で実装する。そのような実装においては、プレディケートレジスタは、論理的レジスタ指定子を用いる命令によって明示的に特定される。論理的レジスタ指定子は、レジスタエイリアステーブル（ＲＡＴ（ｒｅｇｉｓｔｅｒ ａｌｉａｓ ｔａｂｌｅ））に類似する構造を用いるプロセッサパイプラインのリネーミングステージで物理的レジスタ指定子に変換される。特定の論理的レジスタにより保持される物理的レジスタの解放は、論理的レジスタがオーバーライトされるときに起こる。従って、プレディケートレジスタファイルの実装は、汎用レジスタの実装と同様の困難を有する。

数個の実施形態において、軽量のスタックベースのプレディケーションデザインが開示される。このスタックベースのデザインは、アーキテクチャ的およびマイクロアーキテクチャ的構造体にあまり影響を及ぼさずに可能にされ得る。マイクロアーキテクチャ的実装（例えば、レジスタリネーミング、レジスタファイル実装）は、在来のプレディケーションデザインと比べて少ないダイ面積および少ない稼働電力を可能にする。マイクロアーキテクチャ的実装は、一実施形態において分岐予測性能を高める命令パイプラインに対する変更をも可能にする。

以下でプロセッサコアアーキテクチャが記載され、次に、本明細書に記載される実施形態による典型的なプレディケートレジスタおよび命令実装を有する典型的プロセッサおよびコンピュータアーキテクチャが記載される。以下に記載される本発明の実施形態の完全な理解を提供するために、多数の具体的細部が明らかにされる。しかし、それらの実施形態がこれらの具体的細部のうちの幾つかを持たずに実施され得ることは当業者にとっては明らかであろう。他の例において、種々の実施形態の基礎を成す原理を不明確にすることを避けるために、よく知られている構造およびデバイスはブロック図の形で示される。

本明細書に記載される実施形態は、ハードウェア／ソフトウェア協調設計されるプロセッサにおいて実装され得る。

プロセッサコアは様々な目的で、様々なプロセッサにおいて、様々な仕方で実装され得る。例えば、そのようなコアの実装は、１）汎用コンピューティング向けの汎用インオーダーコア、２）汎用コンピューティング向けの高性能汎用アウトオブオーダーコア、３）主としてグラフィクスおよび／または科学（スループット）コンピューティング向けの専用コアを含み得る。

プロセッサは、シングルプロセッサコアデザインまたはマルチプルプロセッサコアデザインを用いて実装され得る。プロセッサの中の複数のプロセッサコアは、アーキテクチャ命令セットに関して同種または異種であり得る。様々なプロセッサの実装は、１）汎用コンピューティング向けの１つまたは複数の汎用インオーダーコアおよび／または汎用コンピューティング向けの１つまたは複数の汎用アウトオブオーダーコアを含むＣＰＵ、および、２）主としてグラフィクスおよび／または科学向けの１つまたは複数の専用コア（例えば、多数の統合されたコアプロセッサ）を含むコプロセッサを含み得る。そのような様々なプロセッサは様々なコンピュータシステムアーキテクチャをもたらし、それらのコンピュータシステムアーキテクチャは、１）ＣＰＵとは別のチップ上のコプロセッサ、２）ＣＰＵと同じパッケージ内の別のダイ上のコプロセッサ、３）ＣＰＵと同じダイ上のコプロセッサ（この場合、そのようなコプロセッサは、時には、統合グラフィクスおよび／または科学（スループット）論理などの専用論理、または専用コアと称される）、および、４）記載されたＣＰＵ（時には１つもしくは複数のアプリケーションコアまたは１つもしくは複数のアプリケーションプロセッサと称される）、上記のコプロセッサ、および追加の機能性を同じダイ上に含み得るシステムオンチップを含み得る。

典型的コアアーキテクチャインオーダーおよびアウトオブオーダーコアのブロック図 図１Ａは、一実施形態による、典型的なインオーダーパイプラインおよび典型的なレジスタリネーミングアウトオブオーダー発行／実行パイプラインを示すブロック図である。図１Ｂは、一実施形態によるプロセッサに含まれるべきインオーダーアーキテクチャコアの典型的実施態様と典型的なレジスタリネーミング、アウトオブオーダー発行／実行アーキテクチャコアとの両方を示すブロック図である。図１Ａ〜１Ｂの実線のボックスはインオーダーパイプラインおよびインオーダーコアを示し、任意に付け加えられた破線ボックスはレジスタリネーミング、アウトオブオーダー発行／実行パイプラインおよびコアを示す。インオーダーアスペクトはアウトオブオーダーアスペクトの部分集合であるものとして、アウトオブオーダーアスペクトが記載されるであろう。

図１Ａにおいて、プロセッサパイプライン１００は、フェッチステージ１０２、長さデコードステージ１０４、デコードステージ１０６、アロケーションステージ１０８、リネーミングステージ１１０、スケジューリング（ディスパッチまたは発行としても知られている）ステージ１１２、レジスタリード／メモリリードステージ１１４、実行ステージ１１６、ライトバック／メモリライトステージ１１８、例外処理ステージ１２２、およびコミットステージ１２４を含む。

図１Ｂは実行エンジンユニット１５０に結合されたフロントエンドユニット１３０を含むプロセッサコア１９０を示し、両者はメモリユニット１７０に結合されている。コア１９０は、縮小命令セットコンピューティング（ＲＩＳＣ（ｒｅｄｕｃｅｄ ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ｃｏｍｐｕｔｉｎｇ））コア、複合命令セットコンピューティング（ＣＩＳＣ（ｃｏｍｐｌｅｘ ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ｃｏｍｐｕｔｉｎｇ））コア、超長命令語（ＶＬＩＷ（ｖｅｒｙ ｌｏｎｇ ｉｎｓｔｒｕｃｔｉｏｎ ｗｏｒｄ））コア、またはハイブリッドもしくは代替コアタイプであり得る。別の選択肢として、コア１９０は、例えば、ネットワークもしくは通信コア、圧縮エンジン、コプロセッサコア、汎用コンピューティンググラフィクス処理ユニット（ＧＰＧＰＵ（ｇｅｎｅｒａｌ ｐｕｒｐｏｓｅ ｃｏｍｐｕｔｉｎｇ ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ））コア、グラフィクスコア、などの専用コアであり得る。

フロントエンドユニット１３０は命令キャッシュユニット１３４に結合されている分岐予測ユニット１３２を含み、命令キャッシュユニット１３４は命令トランスレーションルックアサイドバッファ（ＴＬＢ（ｔｒａｎｓｌａｔｉｏｎ ｌｏｏｋａｓｉｄｅ ｂｕｆｆｅｒ））１３６に結合され、ＴＬＢ１３６は命令フェッチユニット１３８に結合され、命令フェッチユニット１３８はデコードユニット１４０に結合されている。デコードユニット１４０（またはデコーダ）は、命令をデコードし、出力として、原命令からデコードされた、あるいは原命令を別様に反映する、あるいは原命令から導出された、１つまたは複数のマイクロオペレーション、マイクロコードエントリポイント、マイクロ命令、他の命令、または他の制御信号を生成することができる。デコードユニット１４０は、種々の異なるメカニズムを用いて実装され得る。適切なメカニズムの例は、ルックアップテーブル、ハードウェア実装、プログラマブルロジックアレイ（ＰＬＡ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ））、マイクロコード読み出し専用メモリ（ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ））、などを含むが、これらに限定されない。一実施形態では、コア１９０は、或るマイクロ命令のためのマイクロコードを格納するマイクロコードＲＯＭまたは他の媒体を（例えば、デコードユニット１４０内に、あるいはフロントエンドユニット１３０内の他の場所に）含む。デコードユニット１４０は、実行エンジンユニット１５０内のリネーム／アロケータユニット１５２に結合される。

実行エンジンユニット１５０は、リタイアメントユニット１５４とスケジューラユニット１５６のセットとに結合されたリネーム／アロケータユニット１５２を含む。スケジューラユニット１５６は、リザベーションステーション、中央命令ウィンドウなどを含む任意の数の様々なスケジューラを表す。スケジューラユニット１５６は、物理的レジスタファイルユニット１５８に結合されている。物理的レジスタファイルユニット１５８の各々は１つまたは複数の物理的レジスタファイルを表し、そのうちの異なるものは、スカラー整数、スカラー浮動小数点、パックド整数、パックド浮動小数点、ベクトル整数、ベクトル浮動小数点、ステータス（例えば、次に実行されるべき命令のアドレスである命令ポインタ）などの、１つまたは複数の異なるデータタイプを格納する。一実施形態では、物理的レジスタファイルユニット１５８は、ベクトルレジスタユニット、ライトマスクレジスタユニット、およびスカラーレジスタユニットを含む。これらのレジスタユニットは、アーキテクチュラルベクトルレジスタ、ベクトルマスクレジスタ、および汎用レジスタを提供することができる。物理的レジスタファイルユニット１５８は、レジスタリネーミングおよびアウトオブオーダー実行を実装し得る種々の仕方（例えば、リオーダーバッファおよびリタイアメントレジスタファイルを用いる、フューチャーファイル、ヒストリーバッファ、およびリタイアメントレジスタファイルを用いる、レジスタマップおよび予備のレジスタを用いる、等々）を示すためにリタイアメントユニット１５４と一部重ねられている。リタイアメントユニット１５４および物理的レジスタファイルユニット１５８は、実行クラスタ１６０に結合されている。実行クラスタ１６０は、実行ユニット１６２のセットとメモリアクセスユニット１６４のセットとを含む。実行ユニット１６２は、種々のタイプのデータ（例えば、スカラー浮動小数点、パックド整数、パックド浮動小数点、ベクトル整数、ベクトル浮動小数点）に対して種々の演算（例えば、シフト、加算、引き算、掛け算）を行うことができる。幾つかの実施形態は特定の機能または機能のセットに専用の多数の実行ユニットを含み得るが、他の実施形態は、唯一の実行ユニット、あるいはその全てが全ての機能を実行する複数の実行ユニットを含むことができる。スケジューラユニット１５６、物理的レジスタファイルユニット１５８、および実行クラスタ１６０は、一定の実施形態が一定のタイプのデータ／操作のために別々のパイプラインを作るので、複数である可能性があるとして示されている（例えば、それぞれが自分自身のスケジューラユニット、物理的レジスタファイルユニット、および／または実行クラスタを有するスカラー整数パイプライン、スカラー浮動小数点／パックド整数／パックド浮動小数点／ベクトル整数／ベクトル浮動小数点パイプラインおよび／またはメモリアクセスパイプライン − さらに別々のメモリアクセスパイプラインの場合には、このパイプラインの実行クラスタだけがメモリアクセスユニット１６４を有する一定の実施形態が実装される）。別々のパイプラインが使用される場合には、これらのパイプラインのうちの１つまたは複数はアウトオブオーダー発行／実行で他はインオーダーであり得るということも理解されるべきである。

メモリアクセスユニット１６４のセットはメモリユニット１７０に結合され、メモリユニット１７０は、レベル２（Ｌ２）キャッシュユニット１７６に結合されたデータキャッシュユニット１７４に結合されたデータＴＬＢユニット１７２を含む。１つの典型的実施形態では、メモリアクセスユニット１６４はロードユニット、ストアアドレスユニット、およびストアデータユニットを含むことができ、それらの各々はメモリユニット１７０内のデータＴＬＢユニット１７２に結合される。命令キャッシュユニット１３４は、メモリユニット１７０内のレベル２（Ｌ２）キャッシュユニット１７６にさらに結合されている。Ｌ２キャッシュユニット１７６は、１つまたは複数の他のレベルのキャッシュに結合され、結局はメインメモリに結合される。

例を挙げると、典型的レジスタリネーミング、アウトオブオーダー発行／実行コアアーキテクチャはパイプライン１００を次の通りに実装することができる。すなわち、１）命令フェッチ１３８はフェッチステージ１０２および長さデコードステージ１０４を実行し、２）デコードユニット１４０はデコードステージ１０６を実行し、３）リネーム／アロケータユニット１５２はアロケーションステージ１０８およびリネーミングステージ１１０を実行し、４）スケジューラユニット１５６はスケジュールステージ１１２を実行し、５）物理的レジスタファイルユニット１５８およびメモリユニット１７０はレジスタリード／メモリリードステージ１１４を実行し、実行クラスタ１６０は実行ステージ１１６を実行し、６）メモリユニット１７０および物理的レジスタファイルユニット１５８はライトバック／メモリライトステージ１１８を実行し、７）種々のユニットが例外処理ステージ１２２に関係する可能性があり、８）リタイアメントユニット１５４および物理的レジスタファイルユニット１５８はコミットステージ１２４を実行する。

コア１９０は、本明細書に記載された１つまたは複数の命令を含む、１つまたは複数の命令セット（例えば、ｘ８６命令セット（新しいバージョンに対して追加されている幾つかのエクステンションを有する）、カリフォルニア州サニーベールのＭＩＰＳテクノロジーズ（ＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｉｅｓ）のＭＩＰＳ命令セット、英国ケンブリッジのＡＲＭホールディングス（ＡＲＭ Ｈｏｌｄｉｎｇｓ）のＡＲＭ（登録商標）命令セット（ＮＥＯＮなどの任意の追加エクステンションを有する））をサポートすることができる。一実施形態では、コア１９０は、パックドデータ命令セットエクステンション（例えば、ＡＶＸ１、ＡＶＸ２、など）をサポートする論理を含み、多くのマルチメディアアプリケーションにより使用される操作がパックドデータを用いて実行されることを可能にしている。

このコアがマルチスレッディング（操作またはスレッドの並行する２つ以上のセットを実行すること）をサポートすることができ、しかもそれを、タイムスライスマルチスレッディング、同時マルチスレッディング（この場合、単一の物理的コアが、その物理的コアが同時にマルチスレッディングしているスレッドの各々のために論理コアを提供する）、またはそれらの組み合わせ（例えば、Ｉｎｔｅｌ（登録商標）のＨｙｐｅｒ−Ｔｈｒｅａｄｉｎｇ Ｔｅｃｈｎｏｌｏｇｙの場合のようにタイムスライス方式でフェッチおよびデコードを行い、その後に同時マルチスレッディングを行う）を含む多様な仕方で行うことができるということが理解されるべきである。

レジスタリネーミングはアウトオブオーダー実行と関連して記載されるが、レジスタリネーミングはインオーダーアーキテクチャにおいて使用され得ることが理解されるべきである。プロセッサの図示された実施形態は別々の命令キャッシュユニット１３４およびデータキャッシュユニット１７４ならびに共用されるＬ２キャッシュユニット１７６も含むが、代わりの実施形態は、例えばレベル１（Ｌ１）内部キャッシュまたは複数レベルの内部キャッシュなどの、命令およびデータの両方のための単一の内部キャッシュを持つことができる。幾つかの実施形態では、システムは、内部キャッシュと、コアおよび／またはプロセッサの外側の外部キャッシュとの組み合わせを含み得る。あるいは、全てのキャッシュがコアおよび／またはプロセッサの外側にあってもよい。

具体的な典型的インオーダーコアアーキテクチャ 図２Ａ〜２Ｂは、より具体的な典型的インオーダーコアアーキテクチャのブロック図であり、このコアはチップ内の数個の論理ブロック（同じタイプおよび／または異なるタイプの他のコアを含む）のうちの１つであろう。それらの論理ブロックは、用途に応じて、広帯域幅相互接続ネットワーク（例えば、リングネットワーク）を通して或る固定機能論理、メモリＩ／Ｏインターフェースおよび他の所要のＩ／Ｏ論理と通信する。

図２Ａは、一実施形態による、オンダイ相互接続ネットワーク２０２へのコネクションおよびレベル２（Ｌ２）キャッシュ２０４のローカルサブセットを有する単一のプロセッサコアのブロック図である。一実施形態では、命令デコーダ２００は、パックドデータ命令セットエクステンションを有するｘ８６命令セットをサポートする。Ｌ１キャッシュ２０６は、キャッシュメモリに対してスカラーユニットおよびベクトルユニットへの低遅延アクセスを可能にする。一実施形態では（デザインを簡単化するために）、スカラーユニット２０８およびベクトルユニット２１０は別々のレジスタセット（それぞれ、スカラーレジスタ２１２およびベクトルレジスタ２１４）を使用し、これらの間で転送されるデータはメモリに書き込まれ、後にレベル１（Ｌ１）キャッシュ２０６から読み返されるが、代替実施形態は異なるアプローチを使用することができる（例えば、単一のレジスタセットを使用するか、あるいは、データを書き込んで読み返すことをせずにデータを２つのレジスタファイル間で転送できるようにする通信パスを含める）。

Ｌ２キャッシュ２０４のローカルサブセットは、１プロセッサコアに対して１つずつ、別々のローカルサブセットに分割されるグローバルＬ２キャッシュの部分である。各プロセッサコアは、Ｌ２キャッシュ２０４の自分自身のローカルサブセットへの直接アクセスパスを有する。プロセッサコアにより読まれたデータは、そのプロセッサコアのＬ２キャッシュサブセット２０４に格納され、迅速に、かつそれら自身のローカルＬ２キャッシュサブセットにアクセスする他のプロセッサコアと同時に、アクセスされ得る。プロセッサコアにより書きこまれるデータは、そのプロセッサコア自身のＬ２キャッシュサブセット２０４に格納され、必要に応じて他のサブセットからフラッシュされる。リングネットワークは、共用されるデータのコヒーレンシを保証する。リングネットワークは、プロセッサコア、Ｌ２キャッシュおよび他の論理ブロックなどのエージェントがチップ内で互いに通信することを可能にするために双方向性である。各リングデータパスは、１方向につき１０１２ビット幅である。

図２Ｂは、一実施形態による図２Ａのプロセッサコアの部分の拡大図である。図２Ｂは、Ｌ１キャッシュ２０６のＬ１データキャッシュ２０６Ａ部分と、ベクトルユニット２１０およびベクトルレジスタ２１４に関するさらなる詳細とを含む。具体的には、ベクトルユニット２１０は１６幅のベクトル処理ユニット（ＶＰＵ（ｖｅｃｔｏｒ−ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ））（１６幅のＡＬＵ２２８を参照されたい）であり、整数命令、単精度浮動小数点命令、および倍精度浮動小数点命令のうちの１つまたは複数を実行する。このＶＰＵは、スウィズルユニット２２０を用いてレジスタ入力をスウィズルすること、数値変換ユニット２２２Ａ〜Ｂを用いる数値変換、および複製ユニット２２４を用いるメモリ入力に対する複製をサポートする。ライトマスクレジスタ２２６は、生じたベクトルライトをプレディケートすることを可能にする。

統合メモリコントローラおよび専用論理を有するプロセッサ 図３は、一実施形態により、２つ以上のコアを持つことができ、統合メモリコントローラを持つことができ、統合グラフィクスを持つことができるプロセッサ３００のブロック図である。図３の実線のボックスは単一のコア３０２Ａ、システムエージェント３１０、１つまたは複数のバスコントローラユニット３１６のセットを有するプロセッサ３００を示し、任意に追加された破線のボックスは、複数のコア３０２Ａ〜Ｎ、システムエージェントユニット３１０内の１つまたは複数の統合メモリコントローラユニット３１４のセット、および専用論理３０８を有する代替プロセッサ３００を示す。

従って、プロセッサ３００の様々な実装は次のもの、すなわち、１）専用論理３０８が統合されたグラフィクスおよび／または科学（スループット）論理（これは１つまたは複数のコアを含み得る）であり、コア３０２Ａ〜Ｎが１つまたは複数の汎用コア（例えば、汎用インオーダーコア、汎用アウトオブオーダーコア、これら両者の組み合わせ）であるＣＰＵ、２）コア３０２Ａ〜Ｎが主としてグラフィクスおよび／または科学（スループット）向けの多数の専用コアであるコプロセッサ、および３）コア３０２Ａ〜Ｎが多数の汎用インオーダーコアであるコプロセッサ、を含むことができる。従って、プロセッサ３００は、汎用プロセッサ、コプロセッサまたは専用プロセッサ、例えばネットワークもしくは通信プロセッサ、圧縮エンジン、グラフィクスプロセッサ、ＧＰＧＰＵ（ｇｅｎｅｒａｌ ｐｕｒｐｏｓｅ ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ（汎用グラフィクス処理ユニット））、高スループットのメニーインテグレーテッドコア（ＭＩＣ（ｍａｎｙ ｉｎｔｅｇｒａｔｅｄ ｃｏｒｅ））コプロセッサ（３０またはそれ以上のコアを含む）、組み込みプロセッサなど、であり得る。プロセッサは、１つまたは複数のチップ上に実装され得る。プロセッサ３００は、幾つかのプロセス技術、例えばＢｉＣＭＯＳ、ＣＭＯＳ、もしくはＮＭＯＳなど、のうちのいずれかを用いる１つまたは複数の基板の一部であり得、および／または、そのような基板上に実装され得る。

メモリヒエラルキーは、コア内の１つまたは複数のレベルのキャッシュ、１組の１つもしくは複数の共用キャッシュユニット３０６、および統合メモリコントローラユニット３１４のセットに結合されている外部メモリ（図示されていない）を含む。共用キャッシュユニット３０６のセットは、レベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）、もしくは他のレベルのキャッシュ、ラストレベルキャッシュ（ＬＬＣ（ｌａｓｔ ｌｅｖｅｌ ｃａｃｈｅ））、および／またはそれらの組み合わせなどの、１つまたは複数の中間レベルキャッシュを含むことができる。一実施形態においてはリングベース相互接続ユニット３１２が統合グラフィクス論理３０８、共用キャッシュユニット３０６のセット、およびシステムエージェントユニット３１０／１つもしくは複数の統合メモリコントローラユニット３１４を相互に接続するが、代替実施形態はそのようなユニットを相互に接続するために任意の数の公知技術を使用することができる。一実施形態では、１つまたは複数のキャッシュユニット３０６とコア３０２Ａ〜Ｎとの間でコヒーレンシが維持される。

幾つかの実施形態では、コア３０２Ａ〜Ｎのうちの１つまたは複数はマルチスレッディングを行うことができる。システムエージェント３１０は、コア３０２Ａ〜Ｎを調整し操作するコンポーネントを含む。システムエージェントユニット３１０は、例えば、電力制御ユニット（ＰＣＵ（ｐｏｗｅｒ ｃｏｎｔｒｏｌ ｕｎｉｔ））およびディスプレイユニットを含み得る。ＰＣＵは、コア３０２Ａ〜Ｎおよび統合グラフィクス論理３０８の電力状態を調節するために必要な論理およびコンポーネントであるか、またはそのような論理およびコンポーネントを含むことができる。そのディスプレイユニットは、１つまたは複数の外部から接続されたディスプレイを駆動するためのものである。

コア３０２Ａ〜Ｎはアーキテクチャ命令セットに関して同種または異種であり得る。すなわち、コア３０２Ａ〜Ｎのうちの２つ以上は同じ命令セットを実行することができ、他はその命令セットのサブセットだけまたは異なる命令セットを実行することができる。

典型的コンピュータアーキテクチャ 図４〜７は典型的コンピュータアーキテクチャのブロック図である。ラップトップ、デスクトップ、ハンドヘルドＰＣ、パーソナルデジタルアシスタント、エンジニアリングワークステーション、サーバ、ネットワークデバイス、ネットワークハブ、スイッチ、組み込みプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ））、グラフィクスデバイス、ビデオゲームデバイス、セットトップボックス、マイクロコントローラ、携帯電話、ポータブルメディアプレイヤー、ハンドヘルドデバイス、および他の種々の電子デバイスについて当該技術において知られている他のシステムデザインおよび構成も適切である。一般に、本明細書において開示されるプロセッサおよび／または他の実行論理を組み入れることのできるきわめて多様なシステムまたは電子デバイスが一般的に適切である。

図４は、一実施形態によるシステム４００のブロック図を示す。システム４００は、コントローラハブ４２０に結合されている１つまたは複数のプロセッサ４１０、４１５を含み得る。一実施形態では、コントローラハブ４２０はグラフィクスメモリコントローラハブ（ＧＭＣＨ（ｇｒａｐｈｉｃｓ ｍｅｍｏｒｙ ｃｏｎｔｒｏｌｌｅｒ ｈｕｂ））４９０および入力／出力ハブ（ＩＯＨ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｈｕｂ））４５０（これらは別々のチップ上に存在し得る）を含み、ＧＭＣＨ４９０は、メモリ４４０およびコプロセッサ４４５が結合されているメモリおよびグラフィクスコントローラを含み、ＩＯＨ４５０は入力／出力（Ｉ／Ｏ）デバイス４６０をＧＭＣＨ４９０に結合させる。あるいは、メモリおよびグラフィクスコントローラのうちの一方または両方が（本明細書に記載されているように）プロセッサ内に統合され、メモリ４４０およびコプロセッサ４４５はプロセッサ４１０に直接結合され、コントローラハブ４２０はＩＯＨ４５０と共に単一のチップ内に存在する。

追加のプロセッサ４１５の任意性は、図４において破線で示されている。各プロセッサ４１０、４１５は、本明細書に記載された処理コアのうちの１つまたは複数を含むことができ、プロセッサ３００の何らかのバージョンであり得る。

メモリ４４０は、例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ（ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ））、相変化メモリ（ＰＣＭ（ｐｈａｓｅ ｃｈａｎｇｅ ｍｅｍｏｒｙ））、またはこれら二者の組み合わせであり得る。少なくとも１つの実施形態に関しては、コントローラハブ４２０は、フロントサイドバス（ＦＳＢ（ｆｒｏｎｔｓｉｄｅ ｂｕｓ））などのマルチドロップバス、クイックパスインターコネクト（ＱＰＩ（ＱｕｉｃｋＰａｔｈ Ｉｎｔｅｒｃｏｎｎｅｃｔ））などのポイントツーポイントインターフェース、または同様のコネクション４９５を介して１つまたは複数のプロセッサ４１０、４１５と通信する。

一実施形態では、コプロセッサ４４５は、例えば高スループットＭＩＣプロセッサ、ネットワークもしくは通信プロセッサ、圧縮エンジン、グラフィクスプロセッサ、ＧＰＧＰＵ、組み込みプロセッサ、などの専用プロセッサである。一実施形態では、コントローラハブ４２０は統合グラフィクスアクセラレータを含むことができる。

アーキテクチャ特性、マイクロアーキテクチャ特性、熱特性、電力消費特性などを含む、様々なメリット測定基準に関して、物理的リソース４１０、４１５の間には多様な差異があり得る。

一実施形態では、プロセッサ４１０は、一般的タイプのデータ処理操作を制御する命令を実行する。命令の中にコプロセッサ命令を埋め込むことができる。プロセッサ４１０は、これらのコプロセッサ命令を、接続されているコプロセッサ４４５により実行されるべきタイプのものであると認識する。従って、プロセッサ４１０は、これらのコプロセッサ命令（またはコプロセッサ命令を表す制御信号）をコプロセッサバスまたは他のインターコネクトでコプロセッサ４４５へ発行する。コプロセッサ４４５は、受け取ったコプロセッサ命令を受け入れて実行する。

図５は、一実施形態による第１のより具体的な典型的システム５００のブロック図を示す。図５に示されているように、マイクロプロセッサシステム５００は、ポイントツーポイント相互接続システムであり、ポイントツーポイントインターコネクト５５０を介して結合された第１プロセッサ５７０および第２プロセッサ５８０を含む。プロセッサ５７０および５８０の各々は、プロセッサ３００の何らかのバージョンであり得る。本発明の一実施形態では、プロセッサ５７０および５８０はそれぞれプロセッサ４１０および４１５であり、コプロセッサ５３８はコプロセッサ４４５である。別の実施形態では、プロセッサ５７０および５８０はそれぞれプロセッサ４１０およびコプロセッサ４４５である。

プロセッサ５７０および５８０は、統合メモリコントローラ（ＩＭＣ（ｉｎｔｅｇｒａｔｅｄ ｍｅｍｏｒｙ ｃｏｎｔｒｏｌｌｅｒ））ユニット５７２および５８２をそれぞれ含んで示されている。プロセッサ５７０は、自身のバスコントローラユニットの一部としてポイントツーポイント（Ｐ−Ｐ（ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ））インターフェース５７６および５７８も含み、同様に、第２プロセッサ５８０はＰ−Ｐインターフェース５８６および５８８を含む。プロセッサ５７０、５８０は、ポイントツーポイント（Ｐ−Ｐ）インターフェース回路５７８、５８８を用いてＰ−Ｐインターフェース５５０を介して情報を交換することができる。図５に示されているように、ＩＭＣ５７２および５８２はプロセッサをそれぞれのメモリ、すなわちメモリ５３２およびメモリ５３４、に結合させ、これらのメモリは、それぞれのプロセッサに局所的に接続されているメインメモリの部分であり得る。

プロセッサ５７０、５８０は、それぞれ、ポイントツーポイントインターフェース回路５７６、５９４、５８６、５９８を用いて個々のＰ−Ｐインターフェース５５２、５５４を介してチップセット５９０と情報を交換することができる。チップセット５９０は、任意に、高性能インターフェース５３９を介してコプロセッサ５３８と情報を交換することができる。一実施形態では、コプロセッサ５３８は、例えば高スループットＭＩＣプロセッサ、ネットワークまたは通信プロセッサ、圧縮エンジン、グラフィクスプロセッサ、ＧＰＧＰＵ、組み込みプロセッサなどの専用プロセッサである。

プロセッサが低電力モードにされたならばいずれかのまたは両方のプロセッサのローカルキャッシュ情報を共用キャッシュに格納できるように、いずれかのプロセッサの中に、または両方のプロセッサの外部に、Ｐ−Ｐインターコネクトを介してプロセッサと接続される共用キャッシュ（図示されていない）をさらに含めることができる。

チップセット５９０は、インターフェース５９６を介して第１バス５１６に結合され得る。一実施形態では、第１バス５１６はペリフェラルコンポーネントインターコネクト（ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ））バス、またはＰＣＩエクスプレス（ＰＣＩ Ｅｘｐｒｅｓｓ）バスなどのバスまたは別の第３世代Ｉ／Ｏインターコネクトバスであり得るが、本発明の範囲はそのように限定されない。

図５に示されているように種々のＩ／Ｏデバイス５１４が、第１バス５１６を第２バス５２０に結合するバスブリッジ５１８と共に、第１バス５１６に結合され得る。一実施形態では、コプロセッサ、高スループットＭＩＣプロセッサ、ＧＰＧＰＵ、アクセラレータ（例えば、グラフィクスアクセラレータまたはデジタル信号処理（ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ））ユニットなど）、フィールドプログラマブルゲートアレイ、または他の任意のプロセッサなどの追加のプロセッサ５１５が第１バス５１６に結合される。一実施形態では、第２バス５２０はローピンカウント（ＬＰＣ（ｌｏｗ ｐｉｎ ｃｏｕｎｔ））バスであり得る。一実施形態では、例えば、キーボードおよび／またはマウス５２２、通信デバイス５２７、ならびに、命令／コードおよびデータ５３０を含み得るディスクドライブもしくは他の大容量ストレージデバイスなどのストレージユニット５２８を含む種々のデバイスが第２バス５２０に結合され得る。さらに、オーディオＩ／Ｏ５２４が第２バス５２０に結合され得る。他のアーキテクチャが可能であることに留意されたい。例えば、図５のポイントツーポイントアーキテクチャの代わりに、システムはマルチドロップバスまたは他のそのようなアーキテクチャを実装することができる。

図６は、一実施形態による第２のより具体的な典型的システム６００のブロック図を示す。図５および６の類似する要素は類似する参照数字を有し、図５の一定の局面は、図６の他の局面を不明瞭にしないように、図６から省略されている。

図６は、プロセッサ５７０、５８０が統合メモリおよびＩ／Ｏ制御論理（ＣＬ（ｃｏｎｔｒｏｌ ｌｏｇｉｃ））５７２および５８２をそれぞれ含み得ることを示している。従って、ＣＬ５７２、５８２は、統合メモリコントローラユニットを含み、Ｉ／Ｏ制御論理を含む。図６は、メモリ５３２、５３４がＣＬ５７２、５８２に結合されることだけではなくて、Ｉ／Ｏデバイス６１４も制御論理５７２、５８２に結合されることを示す。レガシーＩ／Ｏデバイス６１５はチップセット５９０に結合される。

図７は、一実施形態によるＳｏＣ７００のブロック図を示す。図３の類似要素は同様の参照数字を有する。さらに、破線のボックスは、より進化したＳｏＣ上の任意的特徴物である。図７において、インターコネクトユニット７０２は、１つまたは複数のコア３０２Ａ〜Ｎのセットおよび共用キャッシュユニット３０６を含むアプリケーションプロセッサ７１０と、システムエージェントユニット３１０と、バスコントローラユニット３１６と、統合メモリコントローラユニット３１４と、統合グラフィクス論理、イメージプロセッサ、オーディオプロセッサ、およびビデオプロセッサを含み得る１組の１つもしくは複数のコプロセッサ７２０と、スタティックランダムアクセスメモリ（ＳＲＡＭ（ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ））ユニット７３０と、ダイレクトメモリアクセス（ＤＭＡ（ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓ））ユニット７３２と、１つまたは複数の外部ディスプレイに結合されるべきディスプレイユニット７４０とに結合される。一実施形態では、コプロセッサ７２０は、例えば、ネットワークまたは通信プロセッサ、圧縮エンジン、ＧＰＧＰＵ、高スループットＭＩＣプロセッサ、組み込みプロセッサ、などの専用プロセッサを含む。

本明細書に開示されたメカニズムの実施形態は、ハードウェア、ソフトウェア、ファームウェア、またはそのような実装アプローチの組み合わせで実装される。実施形態は、少なくとも１つのプロセッサ、ストレージシステム（揮発性および不揮発性メモリおよび／またはストレージ素子を含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含むプログラマブルなシステム上で実行するコンピュータプログラムまたはプログラムコードとして実装される。

図５に示されているコード５３０などのプログラムコードは、本明細書に記載されている機能を実行して出力情報を生成する入力命令に対して適用され得る。出力情報は、公知の仕方で１つまたは複数の出力デバイスに対して適用され得る。この適用を行う目的のために、処理システムは、例えばデジタルシグナルプロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ））、またはマイクロプロセッサなどのプロセッサを有する任意のシステムを含む。

プログラムコードは、処理システムと通信するために高レベルの手続き型のまたはオブジェクト指向のプログラミング言語において実装され得る。プログラムコードは、希望に応じてアセンブリ言語または機械語でも実装され得る。実際、本明細書に記載されるメカニズムの範囲はどんな特定のプログラミング言語にも限定されない。いずれにせよ、言語は、コンパイル済みまたは翻訳済みの言語であり得る。

少なくとも１つの実施形態の１つまたは複数の局面は、プロセッサ内の種々の論理を表す機械可読媒体に格納された代表的データにより実装され得、そのデータは、機械によって読まれると、その機械に、本明細書に記載されている技術を実行する論理を作らせる。「ＩＰコア」として知られているそのような表現は、有形の機械可読媒体（テープ）に格納されることができ、実際にその論理またはプロセッサを作る製造機械にロードするために種々のカスタマまたは製造設備に供給され得る。例えば、ＡＲＭホールディングス社（ＡＲＭ Ｈｏｌｄｉｎｇｓ Ｌｔｄ．）および中国科学アカデミーのコンピューティング技術研究所（ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｃｏｍｐｕｔｉｎｇ Ｔｅｃｈｎｏｌｏｇｙ （ＩＣＴ） ｏｆ ｔｈｅ Ｃｈｉｎｅｓｓｅ Ａｃａｄｅｍｙ ｏｆ Ｓｃｉｅｎｃｅｓ）により開発されたプロセッサなどのＩＰコアは、種々のカスタマまたはライセンシーにライセンスまたは販売されて、これらのカスタマまたはライセンシーにより製造されるプロセッサにおいて実装され得る。

そのような機械可読記憶媒体は、ハードディスク、フロッピー（登録商標）ディスク、光ディスク、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ ｄｉｓｋ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ））、リライタブルコンパクトディスク（ＣＤ−ＲＷ（ｒｅｗｒｉｔａｂｌｅ ＣＤ））、および光磁気ディスクを含む他の任意のタイプのディスク、読み出し専用メモリ（ＲＯＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ（ｄｙｎａｍｉｃ ＲＡＭ））、スタティックランダムアクセスメモリ（ＳＲＡＭ（ｓｔａｔｉｃ ＲＡＭ））、などのランダムアクセスメモリ（ＲＡＭ）、消去可能でプログラマブルな読み出し専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ））、フラッシュメモリ、電気的に消去可能でプログラマブルな読み出し専用メモリ（ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ））、相変化メモリ（ＰＣＭ）などの半導体デバイス、磁気もしくは光カード、または他の任意のタイプの、電子的命令を格納するのに適する媒体などの記憶媒体を含む、機械またはデバイスによって製造または形成される物品の非一時的な有形の装置を、無制限に、含み得る。

従って、実施形態は、本明細書に記載されている構造、回路、装置、プロセッサおよび／またはシステム特徴を定義するハードウェア記述言語（ＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ））などの、命令を含むかまたはデザインデータを含む非一時的な有形の機械可読媒体をも含む。そのような実施形態は、プログラム製品とも称され得る。

エミュレーション（バイナリ変換、コードモーフィングなどを含む） 或る場合には、命令をソース命令セットからターゲット命令セットに変換するために命令コンバータが使用され得る。例えば、命令コンバータは、命令を、コアにより処理されるべき１つまたは複数の他の命令に変換（例えば、スタティックバイナリ変換、ダイナミックコンパイルを含むダイナミックバイナリ変換を用いて）し、モーフィングし、エミュレートし、あるいは別の仕方で変換することができる。命令コンバータは、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組み合わせにおいて実装され得る。命令コンバータはオンプロセッサ、オフプロセッサ、またはパートオンパートオフプロセッサであり得る。

図８は、一実施形態による、ソース命令セット中のバイナリ命令をターゲット命令セット中のバイナリ命令に変換するソフトウェア命令コンバータの使用を対照させるブロック図である。図示されている実施形態では、命令コンバータはソフトウェア命令コンバータであるが、代わりに、命令コンバータはソフトウェア、ファームウェア、ハードウェア、またはこれらの様々な組み合わせにおいて実装され得る。図８は、少なくとも１つのｘ８６命令セットコアを有するプロセッサ８１６によりネイティブに実行され得るｘ８６バイナリコード８０６を生成するために高レベル言語８０２のプログラムがｘ８６コンパイラ８０４を用いてコンパイルされ得ることを示す。

少なくとも１つのｘ８６命令セットコアを有するプロセッサ８１６は、少なくとも１つのｘ８６命令セットコアを有するＩｎｔｅｌ（登録商標）プロセッサと実質的に同じ結果を達成するために、（１）Ｉｎｔｅｌ（登録商標）ｘ８６命令セットコアの命令セットの相当の部分または（２）少なくとも１つのｘ８６命令セットコアを有するＩｎｔｅｌ（登録商標）プロセッサ上で動作するように設定されたアプリケーションもしくは他のソフトウェアのオブジェクトコードバージョンをコンパチブルに実行しまたは別の仕方で処理することによって少なくとも１つのｘ８６命令セットコアを有するＩｎｔｅｌ（登録商標）プロセッサと実質的に同じ機能を実行することのできる任意のプロセッサを表す。ｘ８６コンパイラ８０４は、少なくとも１つのｘ８６命令セットコアを有するプロセッサ８１６上で、追加のリンケージ処理を伴ってあるいは伴わずに、実行され得るｘ８６バイナリコード８０６（例えば、オブジェクトコード）を生成するように動作し得るコンパイラを表す。同様に、図８は、高レベル言語８０２のプログラムが、少なくとも１つのｘ８６命令セットコア８１４を持たないプロセッサ（例えば、カリフォルニア州サニーベールのＭＩＰＳテクノロジーズのＭＩＰＳ命令セットを実行するおよび／または英国ケンブリッジのＡＲＭホールディングスのＡＲＭ命令セットを実行するコアを有するプロセッサ）によってネイティブに実行され得る代替命令セットバイナリコード８１０を生成するために代替命令セットコンパイラ８０８を用いてコンパイルされ得ることを示す。

命令コンバータ８１２は、ｘ８６バイナリコード８０６を、ｘ８６命令セットコアを持たないプロセッサ８１４によってネイティブに実行され得るコードに変換するために使用される。この変換後のコードは代替命令セットバイナリコード８１０とは、これを実行できる命令コンバータが製造困難であるために、同じではない可能性があるが、変換後のコードは、大体の動作を成し遂げ、代替命令セットからの命令から組み立てられるであろう。従って、命令コンバータ８１２は、ｘ８６命令セットプロセッサまたはコアを持たないプロセッサまたは他の電子デバイスがｘ８６バイナリコード８０６を実行することを、エミュレーション、シミュレーションまたは他の任意のプロセスを通して、可能にするソフトウェア、ファームウェア、ハードウェア、またはこれらの組み合わせを表す。

軽量なスタックベースのプレディケーション 軽量なスタックベースのプレディケーションの実施形態が記載されるであろう。実施形態は、既存のプレディケートレジスタ実装よりハードウェアの複雑さが小さいプレディケートスタック実装を得るためにレジスタとリネーミング論理とを含む。さらに、プレディケートレジスタのリネーミングとプレディケートレジスタの再利用とは、在来のプレディケートレジスタ実装と比べると簡単化された論理を用いて実行され得る。

一実施形態では、プレディケート命令は、プレディケーション値を生成し、この値を、後の命令による条件付き実行を可能にするために、プレディケートスタックへプッシュする。命令は、スタック上の指定されたプレディケート値に基づいて条件付きで実行する。一実施形態では、条件付きで実行されるブランチにわたってスタック整合性を維持するためにプレディケートスタック管理および同期命令が設けられる。

一実施形態では、プレディケートレジスタスタックのためのレジスタリネーム論理はプロセッサ命令パイプラインにおいて初めの方に移される。初めの方のプレディケートレジスタリネームは、プレディケートされた命令のためのプレディケートを包含する物理的レジスタが命令デコードステージと同じく早くに使用されることを可能にし、在来のプレディケートレジスタ実装より早く分岐結果計算が行われるとともに分岐予測ミスからの回復が改善されるという結果を伴う。

これらの性能改善は、既存の実装と比べてプレディケートレジスタのためのダイ面積要求条件を低減することによる実装コストの低減をも伴って実現され得る。ダイ面積の低減は、プロセッサのダイナミックキャパシタンスが減少するとともに、それと関連してプロセッサの電力消費量が減少するという結果をもたらし得る。さらに、命令コード化スペース要求条件は、プレディケート値を生成する命令については、その命令のために明示的プレディケートデスティネーションレジスタが要求されなくてよいので、低減され得る。

一実施形態では、プレディケーション実装は、アウトオブオーダーハードウェアソフトウェア協調設計プロセッサにおける実装に適するように改められる。プレディケートレジスタのためのソフトウェアサポートは、プログラムにコンパイルされるか、あるいはコンパイル後に実行のためにバイナリ変換システムによって挿入され得る。簡単化されたハードウェア論理は、既存のプレディケートレジスタ実装と比べて、プロセッサダイ面積のさらなる節約と、プロセッサのダイナミックキャパシタンスのさらなる低減とをもたらす。

プレディケートレジスタスタック概観 様々な実施形態において、プレディケート値はレジスタスタックにおいて編成される。従って、ソースおよびデスティネーション論理レジスタは、プレディケート値を消費し生成する命令によって明示的に参照されない。代わりに、プレディケートリードおよびライトは、プレディケートスタック内の、トップオブスタック（ＴｏＳ（Ｔｏｐ−ｏｆ−Ｓｔａｃｋ））レジスタに関して特定の位置の値をアドレス指定する。一実施形態では、プレディケート値への参照は現在のＴｏＳ値に関して相対的に行われる（例えば、ＴｏＳ、ＴｏＳ−１、ＴｏＳ＋２）。一実施形態では、スタック参照は、値をスタックへプッシュし（例えば書き込む）またはスタックからポップする（例えば、読み出す）ことにより行われる。プッシュまたはポップ操作のタイプに応じて、操作はＴｏＳに対して副作用を及ぼし得る。

一実施形態では、プレディケートスタックの状態を明示的に管理し維持するための命令が設けられる。例えば、分岐再収束後のプレディケートスタック値の一貫したビューを維持する命令が設けられる。一実施形態では、種々のソフトウェア制御フローパスにおけるプレディケートスタックの整合性を維持するためにプレディケートスタック管理機能が使用され得る。コードは様々な制御フローパスをたどるので、プレディケートスタックに対して異なる数のプッシュおよびポップが生じ得る。或る状況においては、再収束後コードは分岐前のプレディケート値にアクセスすることができないであろう。例えば、再収束後コードの位置は、その前の制御フローパスのうちのどれが取られたかによって変化し得る。以下で図１３〜１５Ｃと関連して典型的制御フロー命令が記載される。

早期分岐計算および予測ミス回復 一実施形態では、スタックベースのプレディケーション実装は、プロセッサパイプライン内でのプレディケートレジスタの論理−物理マッピングの早期実現を可能にする。従って、その分岐が実行される前に分岐の結果を計算するかあるいはその予測ミスを訂正するために、早期に計算されたプレディケート値が使用され得る。より伝統的な編成を使用してそのようにすることは、リネーミングがプロセッサパイプライン内で後に行われるので、もっと著しく複雑であろう。

図９は、レジスタエイリアステーブルを使用してプレディケートリネーミングを実装するアウトオブオーダープロセッサのための典型的パイプラインのブロック図である。レジスタエイリアステーブル（ＲＡＴ（ｒｅｇｉｓｔｅｒ ａｌｉａｓ ｔａｂｌｅ））は、レジスタリネームへの在来のアプローチである。図示されているパイプラインは、例示的なものであり、いかなる特定のプロセッサアーキテクチャのプロセッサパイプラインを示すことも意図してはおらず、アウトオブオーダーレジスタリネーミングプロセッサの処理パイプラインの一部分の一般的な例として提示されている。簡潔を目的として、パイプラインの幾つかの部分は、典型的インオーダーパイプラインの構成要素と図１Ｂの典型的レジスタリネーミングアウトオブオーダー発行／実行アーキテクチャとを用いて示されている。

前に図示された図１Ｂの分岐予測ユニット１３２、命令フェッチユニット１３８、デコードユニット１４０、および実行ユニット１６２が示されている。加えて、エイリアスコンポーネント９４２、命令キューコンポーネント９４４、リネームコンポーネント９５２、プレディケートＲＡＴコンポーネント９５４、およびシャドウＲＡＴコンポーネント９５６が示されている。エイリアスコンポーネント９４２およびリネームコンポーネント９５２は、図１Ｂに示されているリネーム／アロケータユニット１５２の部分であり得る。プレディケートＲＡＴ９５４およびシャドウＲＡＴ９５６は、図１Ｂに示されている物理的レジスタファイルユニット１５８のうちの１つまたは複数の中に存在し得る。

当該技術において知られているプレディケーション実装においては、プレディケートＲＡＴコンポーネント９５４は、レジスタエイリアスが物理的レジスタ内の物理的レジスタのうちの１つに対して命令により明示的に特定される論理レジスタ指定子の間に生成される当該技術において知られている他のＲＡＴとして実装される。論理レジスタ指定子は、プロセッサパイプラインのリネーミングステージにおいて物理的レジスタ指定子に変換される。レジスタリネーミング中に、一群の命令がリネーミングコンポーネント９５２に入る。これらの命令の間のデータ依存性が判定され、１セットの可能性のあるソースオペランド物理的レジスタが、エイリアステーブル（例えば、ＲＡＴ）を用いて判定される。分岐投機中に、プレディケートＲＡＴ９５４は、レジスタリネーミングのための投機的エイリアス情報を格納する。シャドウＲＡＴ９５６は、分岐予測ミスの場合にデータ回復のために使用される、投機性がより低いシャドウ状態を格納する。

実行中、プレディケートレジスタの物理的ＩＤはリネームコンポーネント９５２までは不明である。従って、プレディケートレジスタの物理的レジスタＩＤの知識に依拠する分岐予測または分岐予測ミス訂正は遅延させられる。或る場合には、予測ミス回復パス９７０は実行ユニット１６２まで遅延させられ得る。従って、アウトオブオーダー、レジスタリネーミングパイプラインにおいてプレディケーションを使用すると、稀に分岐予測が正しい予測に失敗した場合には深刻な分岐予測ミスペナルティが生じ得る。

図１０は、一実施形態による、プレディケートレジスタスタックを実装したアウトオブオーダープロセッサのためのパイプラインのブロック図である。一実施形態では、スタックベースのプレディケーション実装は、プレディケートレジスタのための物理的レジスタの実現をプロセッサパイプラインの初めの方へ移すことによって予測ミスペナルティを著しく低減する。

一実施形態を実装するために構成された更新済みプロセッサコンポーネントが示されている。更新済みコンポーネントは、分岐予測ユニット１０３２、命令フェッチユニット１０３８、デコードユニット１０４０、エイリアスコンポーネント１０４２、命令キューコンポーネント１０４４、リネームコンポーネント１０５２、および実行ユニット１０６２を含む。

プレディケートリネーム操作はオフセットが既知となったならばすぐに実行され得、リネーム論理１０５４は、在来のレジスタリネーム論理より著しく低減されたハードウェア論理を用いて実装され得る。一実施形態では、オフセットは、パイプラインの命令デコードステージの間にデコードユニット１０４０の中で既知となる。オフセットが既知となると、プレディケートＴｏＳレジスタおよびリネーム論理１０５４はプレディケート物理的レジスタＩＤを決定することができる。プレディケートレジスタリネームを命令パイプライン内でもっと前の方へ移せば、前に計算されたプレディケート値に基づいて分岐予測ミス回復を行う追加の機会が得られる。従って、実行ユニット１０６２は依然として予測ミス回復パス１０７０上に存在し得るノードであるが、早期予測ミス検出ポイント１０７２がデコードユニット１０４０、エイリアスコンポーネント１０４２、命令キューコンポーネント１０４４、またはリネームコンポーネント１０５２において作動可能にされ得る。

一実施形態では、シャドウプレディケートレジスタ１０５６のセットが含められる。分岐予測ミスの結果としてパイプラインの全体または部分がフラッシュされる場合、正しいＴｏＳ物理的レジスタ識別子はシャドウプレディケートレジスタ１０５６のうちの１つから回復され得る。一実施形態では、ＴｏＳ識別子のシャドウコピーが各々のあり得るパイプラインフラッシュポイントにおいて維持される。例えば、１つのシャドウコピーがコミットにおいて完全パイプラインフラッシュを処理するために使用され、追加の１つのシャドウコピーが部分的パイプラインフラッシュからの回復のためにパイプライン内のもっと前の方のポイントにおいて、例えばあり得る早期予測ミス検出ポイント１０７２のうちの１つにおいて、保持され得る。

典型的プレディケートレジスタスタック実装 図１１は、実施形態が実装され得る典型的プロセッサのブロック図である。簡潔性を目的として単一のプロセッサコア１１９０（例えばコア０）の細部が図示されているが、他のコア（例えば、コア１〜Ｎ）は同様の論理を持つことができる。一実施形態では、プロセッサコア１１９０は、図１Ｂの典型的プロセッサ１９０に図示されているプロセッサコンポーネントを含む。さらに、各コアは、少なくとも、改善された分岐予測ユニット１１３２、命令フェッチユニット１１３８およびデコードユニット１１４０を含む改善されたフロントエンドユニット１１３０を含み得る。一実施形態では、各コアは、リネーム／アロケータユニット１１５２、スケジューラユニット１１５６、および物理的レジスタファイルユニット１１５８を含む改善されたアウトオブオーダー実行エンジンユニット１１５０を含む。

一実施形態では、プロセッサコア１１９０は、図１０のスタックベースのプレディケートシステムを実装する。そのような実施形態では、分岐予測ユニット１０３２は分岐予測ユニット１１３２内に実装される。命令フェッチユニット１０３８は命令フェッチユニット１１３８内に実装される。デコードユニット１０４０はデコードユニット１１４０内に実装される。一実施形態では、エイリアスコンポーネント１０４２およびリネームコンポーネント１０５２はリネーム／アロケータユニット１１５２内に実装される。実行ユニット１０６２は、実行ユニット１６２のうちのいずれか１つまたは複数であり得る。命令キュー１０４４は、スケジューラユニット１１５６のうちの１つまたは複数のものの中でリザベーションステーションとして実装され得る。

一実施形態では、ＴｏＳレジスタおよびリネーム論理１０５４はデコードユニット１１４０の中に、またはデコードユニット１１４０と関連して、実装される。しかし、もしプレディケートレジスタハードウェアがプロセッサコアの他のコンポーネント内に実装されるならば、依然として早期プレディケートレジスタ決定が行われ得る（例えば、デコードステージの間に）。一実施形態では、ＴｏＳレジスタおよびリネーム論理１０５４は、フロントエンドユニット１１３０によりアクセスされ得る簡単化されたリネーミング論理を用いるリネーム／アロケータユニット１１５２の中に実装される。一実施形態では、プレディケートＴＯＳレジスタおよびリネーム論理１０５４は、物理的レジスタファイルユニット１１５８のうちの１つまたは複数のものの中に実装される。

図１２Ａ〜１２Ｂは、プレディケートレジスタスタックの一実施形態を実装するためのプロセッサコンポーネントのブロック図である。それらのプロセッサコンポーネントは、図１１のプロセッサコア１１９０のコンポーネントとして図示されている。特に、図１２Ａは、実行エンジンユニット１１５０および物理的レジスタファイルユニット１１５８を示す。物理的レジスタファイルユニット１１５８は、個々の実行ユニット（図示されていない）のうちの１つまたは複数のものに接続され得る。図１２Ｂは、物理的レジスタファイルユニット１１５８の拡大図を示す。

図１２Ａに示されているように、一実施形態では、レジスタリネームコンポーネント１１５２．１およびレジスタアロケーションコンポーネント１１５２．２は実行エンジンユニット１１５０のリネーム／アロケータユニット１１５２の中に含まれる。スケジューラユニット１１５６の中のリザベーションステーション１２５７は、図１０のアウトオブオーダー命令キュー１０４４を実装するために使用され得る。一実施形態では、物理的レジスタファイルユニット１１５８は、プレディケートＴｏＳレジスタおよびリネーム論理１２５４を、実行エンジンユニット１１５０内で使用される他の物理的レジスタと共に、含む。プレディケートＴｏＳレジスタおよびリネーム論理１２５４は、プレディケートレジスタセット１２１０内のレジスタのレジスタＩＤを選択するために使用される。プレディケートレジスタセット１２１０内のレジスタは、プレディケートレジスタスタックのレジスタの代わりに使用される。

一実施形態では、物理的プレディケートレジスタセット１２１０内の各プレディケートレジスタは、１ビットのプレディケート値（例えば、真のための０ｂ１または偽のための０ｂ０）を保持するように構成されたシングルビットレジスタである。一実施形態では、プレディケートレジスタセット１２１０はマルチビットレジスタ（例えば、１６ビット、３２ビット）から構成され、レジスタ論理はそれらのマルチビットレジスタのシングルビットをシングルプレディケートレジスタとして与えるように構成される。

図１２Ｂは、物理的レジスタファイルユニット１１５８の拡大図を示す。任意の所与時点でのライブプレディケートレジスタのセットは［ＴｏＳ−ＭＡＸ＿ＯＦＦＳＥＴ，ＴｏＳ＋ＭＡＸ＿ＯＦＦＳＥＴ］として定義され、ここで図１２Ａ〜１２Ｂの＋Ｎおよび−ＮはプレディケートレジスタスタックについてＴｏＳ１２０６からの＋ＭＡＸ＿ＯＦＦＳＥＴおよび−ＭＡＸ＿ＯＦＦＳＥＴを示す。ＭＡＸ＿ＯＦＦＳＥＴは、実施形態によりさまざまである。プレディケート値が計算されると、それらの値はプレディケートスタックの頂部へ（例えば、ＴｏＳ１２０６の上のレジスタへ）プッシュされ、ＴｏＳはその新しい値まで進められる。

一実施形態では、プレディケートレジスタリネーミング論理１２５４は、ＴｏＳレジスタのレジスタＩＤを格納するレジスタ１２０４と、そのＴｏＳ ＩＤから要求されたオフセットを計算するＡＬＵ１２０２とを含む。前に計算されたプレディケートは、現在のプレディケートＴｏＳレジスタに関して相対的に特定される（例えば、ＴｏＳ＋１、ＴｏＳ−２など）。特定の値の論理名は、時間が経つにつれて変化するであろう。例えば、ＴｏＳにある特定のプレディケートレジスタは、次のプレディケート値がプレディケートレジスタスタックへプッシュされた後、ＴｏＳ−１にアドレス指定されるであろう。ＴｏＳレジスタが増大するごとに、プレディケート（例えば、ＴｏＳ−（ＭＡＸ＿ＯＦＦＳＥＴ＋１）の位置にあるプレディケート）のうちの１つは、ライブプレディケート値の範囲の外へ出る。これが生じると、ＴｏＳ−（ＭＡＸ＿ＯＦＦＳＥＴ＋１）位置にあるプレディケート値は無効とみなされる。その論理レジスタと関連付けられている物理的レジスタは、その論理レジスタが無効になると再利用される。

パイプラインの全体または部分がフラッシュされる場合、正しいＴｏＳ値はシャドウＴｏＳレジスタ１２５６内のシャドウコピーから回復される。一実施形態では、将来フラッシュが起こり得る各々のパイプラインポイントでシャドウコピーが維持される。一実施形態では、論理的に［ＴｏＳ−ＭＡＸ＿ＯＦＦＳＥＴ，ＴｏＳ＋ＭＡＸ＿ＯＦＦＳＥＴ］の外側にあるプレディケート値は、もしパイプラインをフラッシュしてプロセッサの状態をそのプレディケート値が依然として有効なままであるはずのポイントまで後退させる可能性が残っているならば、解放されるべきではないということに注意して、ソフトウェアは開発される。一実施形態では、プロセッサ状態の後退後にそのレジスタがライブになる可能性がありそうならば、論理レジスタが解放されることを阻止する論理が含められる。プレディケートレジスタのコストは割合に少ないので、一実施形態では、プレディケートレジスタのアウトオブバウンズ問題の可能性を制限するために、物理的レジスタの数を十分に多く保つことができる。１つの実装では最大１６個のライブプレディケートレジスタを包含するプレディケートレジスタスタックで十分である。しかし、任意の時点におけるライブプレディケートレジスタの数は、プロセッサまたはプロセッサコアの命令パイプラインの長さに基づいて調整され得る。

新しいプレディケート値は、或る程度の比較命令を用いて、明示的に、または、何らかの方法で試験され得る値を計算する任意の命令によって暗に、計算されてスタックへプッシュされ得る。例えば、アーキテクチャフラグを改変する既存の命令は、プレディケート値をプレディケートスタックへプッシュする可能性がある。所与の命令に関してプッシュまたは比較するプレディケート値としてどのアーキテクチャフラグを用いるかは、命令コード化の一部として指定され得、常に０とあるいは他の任意の条件と対照して試験すると想定され得る。一実施形態では、任意の生成された値が常にスタックの頂部へプッシュされる。従って、命令コード化において、明示的デスティネーションプレディケートレジスタは指定されない。

一実施形態では、ＴｏＳは常に増大すると想定され得、明示的ポップ命令は設けられない。しかし、一実施形態では、スタックから値を除去して、ポップされた値の数だけＴｏＳを小さくするようにポップ命令が実装され得る。一実施形態では、スタック同期命令の結果としてＴｏＳを以前のポイントへ移す暗示的ポップ命令が設けられる。

プレディケートレジスタスタック管理命令 或るスタックベースのデザインでは、プログラムが様々な制御パスを取り得るとき、制御パスが収束したときスタックは整合した状態にあるべきである。換言すれば、プレディケートＴｏＳレジスタおよびどのＴＯＳ−Ｎ参照も、どのパスが取られたかによらずに同じプレディケートレジスタを参照するべきである。スタックへプッシュされたプレディケート値の数が制御フローパスによって異なるならば、プレディケートレジスタスタックは整合しなくなる。プレディケートレジスタスタックを整合しない状態に置く命令の典型的セットが以下の表１に示されている。

上の表１において、２つの分岐パスのうちの１つが、第２行のＴｏＳにより示されるプレディケートレジスタ内の値に基づいて実行される。ｐｒｅｄｅｉｃａｔｅ＿ｆａｌｓｅパスは、２つのプレディケート値をプレディケートスタックへプッシュする。ｐｒｅｄｉｃａｔｅ＿ｔｒｕｅパスは、１つのプレディケート値をプレディケートスタックへプッシュする。従って、第７行の分岐は、前の分岐パスのうちのどれが取られたかによって異なるプレディケート値を用いて評価されるであろうが、これは意図された結果ではない可能性がある。

一実施形態では、異なる数のプレディケート値をプレディケートレジスタスタックへプッシュする分岐パスにおいてスタック整合性を（例えば、コンパイラまたはデベロッパーが）維持することを可能にする専用の命令が含められる。

プレディケートスタックプッシュ命令 一実施形態では、１つまたは複数の値をプレディケートスタックへ明示的にプッシュし、ＴｏＳを適宜前進させる命令（例えば、ｐｐｕｓｈ）が設けられる。スタックへプッシュされる値は、真または偽であり得る。一実施形態では、「ｄｏｎ'ｔ−ｃａｒｅ」値がプッシュされ得る。ｄｏｎ'ｔ−ｃａｒｅ値をプッシュすると、ＴｏＳがアップデートされるとともに、新しい値をセットすることなくプレディケートレジスタ内に存在する既存の値が再使用されることになるであろう。プレディケートレジスタスタック整合性を維持するためにプレディケートスタックプッシュ命令を利用する命令の典型的セットが下の表２に示されている。

上の表２において、追加の「ｐｐｕｓｈ ０ｘ１」命令が第６ａ行に示されている。一実施形態では、ｐｐｕｓｈ ０ｘ１命令は、０ｘ１値をプレディケートスタックへプッシュし、ＴｏＳをその挿入された値へアップデートする。その結果、スタックへプッシュされたプレディケート値の数は両方のブランチにおいて等しくなるであろう。従って、第７行のブランチは、前のブランチ実行を顧慮せずに同じプレディケート値を用いて評価されるであろう。単一のビットのプッシュが示されているが（例えば、０ｘ１）、一実施形態は、命令のソースオペランドのビット値に基づいて数個のビットをスタックへプッシュすることを可能にする。例えば、ソース値が０ｘ３（例えば、０ｂ１１）であるならば、一実施形態は２つの真プレディケートをスタックへプッシュする。

プレディケートスタックキューおよび同期命令 一実施形態では、プレディケートキュー（例えば、ｐｑｕｅｕｅ）およびプレディケート同期（例えば、ｐｓｙｎｃ）命令が設けられる。ｐｑｕｅｕｅ命令は、１つまたは複数のプレディケートの明示的系列を、ＴｏＳをこれらの値を通過させて前へ進めることなく、スタックへプッシュすることができる。従って、将来の値がスタックへプッシュされると、その将来の値は、ｐｑｕｅｕｅ命令によりプッシュされた値をオーバーライトする。ｐｑｕｅｕｅ命令は、ＴｏＳの現在の位置を、後にｐｓｙｎｃ命令により使用され得るように、保存することもできる。

ｐｓｙｎｃ命令は、一実施形態では、ＴｏＳをキュー命令以前にＴｏＳがあった位置へ移動させ（例えばｐｓｙｎｃ ｂｏｔｔｏｍ、ｐｓｙｎｃ．ｂ）またはＴｏＳを、ＴｏＳが前のｐｑｕｅｕｅ命令により書きこまれた最後のプレディケート値を指すまで前進させる（例えばｐｓｙｎｃ ｔｏｐ、ｐｓｙｎｃ．ｔ）。例えば、様々な制御フローパスにおいて計算されたプレディケートのいずれもが分岐再収束ポイントを超えてライブであるように意図されていなければｐｓｙｎｃ ｂｏｔｔｏｍ命令を使用することができて、ｐｑｕｅｕｅによりプッシュされた任意の値ならびにｐｑｕｅｕｅとｐｓｙｎｃ ｂｏｔｔｏｍとの間にスタックへプッシュされた他の任意の値の暗黙のポッピングをもたらす。反対に、変化し得る数のプッシュが分岐の間に発生し、これらの値のうちの幾つかが再収束ポイントを超えてライブであるように意図されるならば、ｐｓｙｎｃ ｔｏｐ命令を使用することができる。プレディケートレジスタスタックの整合性を維持するためにプレディケートスタックキューおよび同期命令を利用する命令の典型的セットが下の表３に示されている。

上の表３において、第１ａ行は０ｘ３（例えば、０ｂ１１）の値をスタックへプッシュするｐｑｕｅｕｅ命令を示す。これに応じて、２つの真プレディケート値がプッシュされる。一実施形態では、このｐｑｕｅｕｅ命令は、ＴｏＳ位置を後の使用のために保存するけれども、新たにキューに入れられた値を反映するようにＴｏＳ位置をアップデートすることはない。ＴｏＳ位置はｐｑｕｅｕｅ命令の結果としてアップデートされないので、第２行におけるｂｒ．ｐ命令によるＴｏＳへの参照は、第１行のａｄｄ．ｐ命令によりプッシュされたプレディケート値への参照である。第２行の分岐の後、第３行および第４行の命令により２つの値がプレディケートスタックへプッシュされ、または第６行の命令により１つの値がプレディケートスタックへプッシュされる。このブランチにおける各プッシュは、第１ａ行のｐｑｕｅｕｅ命令によって挿入された値をオーバーライトし、各プッシュ後にスタックを前進させる。

第６ｂ行で、プレディケートスタックを同期させるためにｐｓｙｎｃ命令が使用される。ｐｓｙｎｃ．ｔまたはｐｓｙｎｃ．ｂのうちのいずれか一方が使用され得る。ｐｓｙｎｃ．ｔ命令は、直前のｐｑｕｅｕｅ命令により書き込まれた最後の値までＴｏＳを前進させるために使用される。表３のコードにおいて、第１ａ行のｐｑｕｅｕｅ ０ｘ３は２つのプレディケート値をプレディケートスタックへプッシュした。従って、一実施形態では、第６ａ行のｐｓｙｎｃ．ｔは、前のＴｏＳ位置を読み出して、第１ａ行のｐｑｕｅｕｅ命令によって格納された前のＴｏＳ値を２位置通過させてＴｏＳを前進させる。代わりに、ＴｏＳをｐｑｕｅｕｅ命令以前の位置へ復帰させるためにｐｓｙｎｃ．ｂ命令を使用することができ、この復帰は、前のブランチにおいてプッシュされたいかなるプレディケート値をも本質的に廃棄する。いずれの場合にも、デベロッパーまたはコンパイラは、分岐収束後、プレディケートスタックの状態を確信することができる。

図１３は、一実施形態による、プレディケートスタックを管理する命令を含む処理システムのブロック図である。この典型的処理システムは、メインメモリ１３００に結合されたプロセッサ１３５５を含む。プロセッサ１３５５は、プレディケートスタック管理命令をデコードするためのデコード論理１３３１を有するデコードユニット１３３０を含む。加えて、プロセッサ実行エンジンユニット１３４０は、プレディケートレジスタスタック命令を実行するための追加の実行論理１３４１を含む。レジスタ１３０５は、実行ユニット１３４０が命令ストリームを実行するときオペランド、制御データおよび他のタイプのデータのためのレジスタストレージを提供する。一実施形態では、レジスタ１３０５は、本明細書に記載された論理的プレディケートレジスタスタックを実装するために使用される物理的レジスタも含む。

簡潔性を目的として、単一のプロセッサコア（コア０）の細部が図１３に示されている。しかし、図１３に示されている各コアがコア０と同じ論理のセットを持ち得ることが理解されるであろう。図示されているように、各コアは、所定のキャッシュ管理ポリシーに従って命令およびデータをキャッシュするための専用レベル１（Ｌ１）キャッシュ１３１２およびレベル２（Ｌ２）キャッシュ１３１１も含み得る。Ｌ１キャッシュ１３１１は、命令を格納するための独立した命令キャッシュ１３２０とデータを格納するための独立したデータキャッシュ１３２１とを含む。種々のプロセッサキャッシュの中に格納された命令およびデータは、固定したサイズ（例えば、６４、１２８、５１２バイト長）であり得るキャッシュラインのグラニュラリティで管理される。この典型的実施形態の各コアは、メインメモリ１３００および／または共用レベル３（Ｌ３）キャッシュ１３１６から命令をフェッチするための命令フェッチユニット１３１０と、その命令をデコードするためのデコードユニット１３３０と、その命令を実行するための実行ユニット１３４０と、その命令をリタイアさせて結果をライトバックするためのライトバック／リタイアユニット１３５０とを有する。

命令フェッチユニット１３１０は、メモリ１３００（またはキャッシュのうちの１つ）から次にフェッチされるべき命令のアドレスを格納するための次命令ポインタ１３０３と、アドレス変換を高速化するために最近使われた仮想−物理命令アドレスのマップを格納するための命令変換ルックアサイドバッファ（ＩＴＬＢ（ｉｎｓｔｒｕｃｔｉｏｎ ｔｒａｎｓｌａｔｉｏｎ ｌｏｏｋ−ａｓｉｄｅ ｂｕｆｆｅｒ））１３０４と、命令分岐アドレスを投機的に予測するための分岐予測ユニット１３０２と、ブランチアドレスおよびターゲットアドレスを格納するための分岐ターゲットバッファ（ＢＴＢ（ｂｒａｎｃｈ ｔａｒｇｅｔ ｂｕｆｆｅｒ））１３０１と、を含む種々の公知コンポーネントを含む。フェッチされると、命令は次に、デコードユニット１３３０、実行ユニット１３４０、およびライトバック／リタイアユニット１３５０を含む命令パイプラインの残りのステージへ流される。

図１４は、一実施形態による、典型的プレディケートスタック管理命令を処理する論理についての流れ図である。ブロック１４０２において、命令パイプラインは、プレディケートレジスタスタックを改変するかまたは別様にアクセスする命令のフェッチから始まる。命令は、プレディケートレジスタスタックを改変する命令、または、その命令により実行された計算の結果としてセットされることもセットされないこともあるアーキテクチャステータスフラグとの比較に基づいてプレディケートレジスタスタックを改変する命令であり得る。

ブロック１４０４で、プロセッサは命令をデコードしてデコード済み命令とする。一実施形態では、デコード済み命令は単一の操作である。一実施形態では、デコード済み命令は、この命令の各サブエレメントを実行する１つまたは複数の論理的マイクロ操作を含む。それらのマイクロ操作はハードワイヤードであることができ、あるいは、マイクロコード操作はプロセッサの実行ユニットなどのコンポーネントに該命令を実装する種々の操作を実行させることができる。

ブロック１４０６で、プロセッサの実行ユニットは、プレディケートレジスタスタックにアクセスする操作を実行するためにデコード済み命令を実行する。一実施形態では、命令は、スタック内の論理的位置（例えば、ＴｏＳ、ＴｏＳ−１、ＴｏＳ＋１）を含むオペランドにより指定されるプレディケートスタック上の位置からのリードを行わせる。一実施形態では、命令は、プレディケートレジスタスタックへのプッシュを行わせる。値をプレディケートレジスタスタックへプッシュする命令については、一実施形態において、生成された値がスタックの頂部へプッシュされるので、値をプレディケートスタックへプッシュする命令のために命令コード化において明示的デスティネーションプレディケートレジスタは指定されない。

ブロック１４０８において、命令は、プレディケートレジスタスタックを、該命令により示された通りに、プロセッサに改変させる。一実施形態では、命令は、プロセッサの実行ユニットに、命令実行中にセットされる１つまたは複数のアーキテクチャフラグ（例えば、ｃａｒｒｙ、ｚｅｒｏ ｏｖｅｒｆｌｏｗ、ｎｅｇａｔｉｖｅ）に基づいて値を生成させてその値をプレディケートレジスタスタックへプッシュさせる。一実施形態では、命令は、明示的プレディケートスタック管理操作を行う命令である。命令は、ＴｏＳ値を前進させずに１つまたは複数の値をプレディケートスタックへプッシュする操作、ＴｏＳ値を前進させるのと同時に１つまたは複数の値をプレディケートスタックへプッシュする操作、またはＴｏＳを前のプレディケートスタック操作に基づく位置に同期させる操作を含む、プレディケートスタックに対する任意の数の操作を実行することができる。

図１５Ａ〜１５Ｃは、実施形態による、特定のプレディケートスタック管理命令についての流れ図である。図１５Ａは、一実施形態によるプレディケートスタックプッシュ命令（例えば、ｐｐｕｓｈ）についての論理を示す。図１５Ｂは、一実施形態によるプレディケートスタックキュー命令（例えば、ｐｑｕｅｕｅ）についての論理を示す。図１５Ｃは、一実施形態によるプレディケートスタック同期命令（例えば、ｐｓｙｎｃ．ｂ、ｐｓｙｎｃ．ｔ）についての論理を示す。本明細書に記載された実施形態と矛盾しない、明示的プレディケートスタック管理を実行する他の命令が考えられ得るということが理解されるであろう。

図１５Ａのブロック１５０４に示されているように、一実施形態では、デコードユニットが、第１オペランドを有する第１命令（例えば、プレディケートプッシュ命令）をデコードして第１デコード済み命令とする。ブロック１５０６において、プロセッサ実行ユニットなどのプロセッサコンポーネントは第１オペランドのための第１オペランド値を取り出す操作を実行し、その第１オペランド値は１つまたは複数のプレディケート値を含む。ブロック１５０８において、プロセッサは、オペランド値のビットに基づいて１つまたは複数のプレディケート値をデコードする。例えば、０ｘ４というオペランド値は、０ｂ１００にデコードされ得、３つのプレディケート値（例えば、０ｂ１、０ｂ０、および０ｂ０）をプレディケートスタックへプッシュするという結果をもたらし得る。

ブロック１５１０において、プロセッサ実行論理はデコード済みプレディケート値をプレディケートスタックへプッシュする。プレディケート値をプッシュすることは、一実施形態では、プレディケートスタックの論理的レジスタと関連付けられた物理的レジスタＩＤを決定するためにプレディケートレジスタリネーム論理を使用する。ブロック１５１２において、プレディケートレジスタリネーム論理は、プレディケートスタックの頂部を、プレディケートレジスタスタックへプッシュされた最後の値まで前進させるために使用される。

図１５Ｂのブロック１５１４に示されているように、一実施形態では、デコードユニットは、第１オペランドを有する第２命令（例えば、プレディケートキュー命令）をデコードして第２デコード済み命令とする。ブロック１５１６において、プロセッサ実行ユニットなどのプロセッサコンポーネントは第１オペランドのための第１オペランド値を取り出す操作を実行し、その第１オペランド値は１つまたは複数のプレディケート値を含む。ブロック１５１８において、プロセッサはオペランド値から少なくとも１つのプレディケート値の系列をデコードする。

ブロック１５２０において、プロセッサ実行論理はそのプレディケート値の系列をプレディケートスタックへプッシュする。一実施形態では、ブロック１５２１において示されているように、プレディケートキュー命令は、後に同期命令によって使用され得るように現在のＴｏＳ位置（例えば、ＴｏＳレジスタＩＤ）を明示的に保存することができる。しかし、前のキュー命令と関連付けられたプレディケートＴｏＳを判定する他の方法が使用され得るので、必ずしも全ての実施形態がキュー命令によるプレディケートＴｏＳ位置の明示的保存に依拠するわけではない。第２命令については、ブロック１５１２においてプレディケートキュー命令は明示的にはプレディケートスタックの頂部を前進させない。従って、プレディケートキュー命令によってプッシュされたプレディケート値は、これらの値が、プレディケートプッシュからの明示的プッシュによって、または、プレディケート値をプレディケートスタックへその命令の操作結果もしくは副作用としてプッシュするようにコード化された命令からのプッシュによって、オーバーライトされるまでは、ＴｏＳ＋Ｎ個の論理識別子を用いてアクセスされ得る。

図１５Ｃのブロック１５２４において示されているように、一実施形態では、デコードユニットは第３命令（例えば、プレディケート同期命令）をデコードする。一実施形態では、１５２６において示されているように、第３命令は前に格納されたＴｏＳ位置を取り出す。前に格納されたＴｏＳ位置は、そのような実施形態では、前に実行されたプレディケートスタックキュー命令により格納される。しかし、前のキュー命令と関連付けられているプレディケートＴｏＳを判定する他の方法が使用され得るので、必ずしも全ての実施形態がキュー命令によるプレディケートＴｏＳ位置の明示的保存に依拠するわけではない。ブロック１５２８に示されているように、プロセッサは、その命令のための同期モードを決定する。一実施形態では、同期モードは、命令デコード中にデコードユニットによって決定される。一実施形態では、プロセッサは、プレディケート同期命令の実行中に同期モードを決定する。ブロック１５３０に示されているように、プレディケートレジスタリネーム論理は、プレディケート同期命令のタイプまたはコード化に基づいてプレディケートＴｏＳレジスタを「ボトム」または「トップ」モードで同期させる。ブロック１５３２はボトム同期操作を示し、この場合、リネーム論理はＴｏＳを前のプレディケートキュー命令より前の位置へ移動させる。ブロック１５３３はトップ同期操作を示し、この場合、リネーム論理はＴｏＳを前のプレディケートキュー命令により書き込まれた最後のプレディケートまで移動させる。一実施形態では、前のプレディケートキュー命令により書き込まれた最後のプレディケートへのＴｏＳの移動は、論理的分岐の間に書き込まれたプレディケート値の数を越えてＴｏＳを前進させる。一実施形態では、前のプレディケートキュー命令によりプッシュされたプレディケート値より多くのプレディケート値が分岐中にプッシュされるならば、ＴｏＳの移動は１つまたは複数の命令の暗黙のポップをもたらす結果となる。

典型的命令フォーマット 本明細書に記載された１つまたは複数の命令の実施形態は、様々なフォーマットで具体化され得る。さらに、典型的なシステム、アーキテクチャ、およびパイプラインが以下に詳しく記載される。１つまたは複数の命令の実施形態は、そのようなシステム、アーキテクチャ、およびパイプラインにおいて実行され得るが、これらの細部には限定されない。

ベクトルフレンドリな命令フォーマットとは、ベクトル命令（例えば、ベクトル操作に特有の一定のフィールドがある）に適する命令フォーマットである。ベクトルフレンドリな命令フォーマットによってベクトル操作およびスカラー操作の両方がサポートされる実施形態が記載されるが、代替実施形態はベクトル操作ベクトルフレンドリな命令フォーマットだけを使用する。

図１６Ａ〜１６Ｂは、一実施形態による一般的なベクトルフレンドリ命令フォーマットとその命令テンプレートとを示すブロック図である。図１６Ａは一実施形態による一般的ベクトルフレンドリ命令フォーマットとそのクラスＡ命令テンプレートとを示すブロック図であり、図１６Ｂは一実施形態によるこの一般的ベクトルフレンドリ命令フォーマットとそのクラスＢ命令テンプレートとを示すブロック図である。具体的には、クラスＡおよびクラスＢ命令テンプレートが定義されている一般的ベクトルフレンドリ命令フォーマット１６００、その両方の命令テンプレートがメモリアクセス無し１６０５命令テンプレートとメモリアクセス１６２０命令テンプレートとを含む。ベクトルフレンドリ命令フォーマットの文脈において一般的という用語は、いかなる特定の命令セットにも結び付けられていない命令フォーマットに関連する。

ベクトルフレンドリな命令フォーマットが３２ビット（４バイト）もしくは６４ビット（８バイト）のデータエレメント幅（もしくはサイズ）を有する６４バイトのベクトルオペランド長（もしくはサイズ）（従って、６４バイトのベクトルは１６個のダブルワード−サイズエレメントもしくは、代わりに、８クワッドワード−サイズエレメントから成る）、１６ビット（２バイト）もしくは８ビット（１バイト）のデータエレメント幅（もしくはサイズ）を有する６４バイトのベクトルオペランド長（もしくはサイズ）、３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）、もしくは８ビット（１バイト）のデータエレメント幅（もしくはサイズ）を有する３２バイトのベクトルオペランド長（もしくはサイズ）、および、３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）、もしくは８ビット（１バイト）のデータエレメント幅（もしくはサイズ）を有する１６バイトのベクトルオペランド長（もしくはサイズ）をサポートする実施形態が記載されるであろう。しかし、代替実施形態は、もっと大きな、もっと小さな、または様々なデータエレメント幅（例えば、１２８ビット（１６バイト）のデータエレメント幅）を有するもっと大きな、もっと小さなおよび／または様々なベクトルオペランドサイズ（例えば、２５６バイトのベクトルオペランド）をサポートする。

図１６ＡのクラスＡ命令テンプレートは次を含む、１）メモリアクセス無し１６０５命令テンプレートの中にはメモリアクセス無し、完全丸め制御タイプ操作１６１０命令テンプレートとメモリアクセス無し、データ変換タイプ操作１６１５命令テンプレートとが示されており、２）メモリアクセス１６２０命令テンプレートの中にはメモリアクセス、一時的１６２５命令テンプレートとメモリアクセス、非一時的１６３０命令テンプレートとが示されている。図１６ＢのクラスＢ命令テンプレートは次を含む、１）メモリアクセス無し１６０５命令テンプレートの中にはメモリアクセス無し、ライトマスク制御、部分的丸め制御タイプ操作１６１２命令テンプレートとメモリアクセス無し、ライトマスク制御、ｖｓｉｚｅタイプ操作１６１７命令テンプレートとが示されており、２）メモリアクセス１６２０命令テンプレートの中にはメモリアクセス、ライトマスク制御１６２７命令テンプレートが示されている。

一般的ベクトルフレンドリ命令フォーマット１６００は、下にリストされている下記のフィールドを、図１６Ａ〜１６Ｂに示されている順に含む。

フォーマットフィールド１６４０ − このフィールド内の具体的値（命令フォーマット識別子値）は、ベクトルフレンドリ命令フォーマットを、従って命令ストリームにおけるベクトルフレンドリ命令フォーマット内の命令の出現を、一意的に特定する。そのような次第で、このフィールドは、一般的ベクトルフレンドリ命令フォーマットだけを有する命令セットのためにはこのフィールドは必要でないという意味において、任意的である。

ベース操作フィールド１６４２ − その内容は、様々なベース操作を識別する。

レジスタインデックスフィールド１６４４ − その内容は、直接にまたはアドレス生成を通して、ソースおよびデスティネーションオペランドの位置を、それらがレジスタ内にあるにせよメモリ内にあるにせよ、指定する。これらの位置は、Ｐ×Ｑ（例えば、３２×５１２、１６×１２８、３２×１０２４、７４×１０２４）レジスタファイルからＮ個のレジスタを選択するのに十分な数のビットを含む。一実施形態ではＮは最大３個のソースおよび１個のデスティネーションレジスタであり得るが、代替実施形態はもっと多くのあるいはもっと少ないソースおよびデスティネーションレジスタをサポートすることができる（例えば、最大２個のソースをサポートすることができ、この場合それらのソースのうちの１つはデスティネーションの役割も果たし、あるいは、最大３個のソースをサポートすることができ、この場合それらのソースのうちの１つはデスティネーションの役割も果たし、あるいは、２個のソースと１個のデスティネーションとをサポートすることができる）。

モディファイアフィールド１６４６ − その内容は、メモリアクセスを指定する一般的ベクトル命令フォーマット内の命令の出現を、指定しない命令から区別する、すなわち、メモリアクセス無し１６０５命令テンプレートとメモリアクセス１６２０命令テンプレートとを区別する。メモリアクセス操作はメモリヒエラルキーを読みおよび／またはメモリヒエラルキーに書き込むが（或る場合には、レジスタ内の値を用いてソースおよび／またはデスティネーションアドレスを指定する）、メモリアクセス無し操作はそうはしない（例えば、ソースおよびデスティネーションはレジスタである）。一実施形態では、このフィールドはメモリアドレス計算を行う３つの異なる仕方のうちからの選択も行うが、代替実施形態は、メモリアドレス計算を行うもっと多くの、もっと少ない、あるいは様々な仕方をサポートすることができる。

増補操作フィールド１６５０ − その内容は、ベース操作の他に多様な操作のうちのどの１つを実行するべきかを識別する。このフィールドはコンテキスト特有である。本発明の一実施形態では、このフィールドはクラスフィールド１６６８、アルファフィールド１６５２、およびベータフィールド１６５４に分割される。増補操作フィールド１６５０は、２個、３個、または４個の命令ではなくて単一の命令で共通のグループの操作を実行することを可能にする。

スケールフィールド１６６０ − その内容は、メモリアドレス生成のための（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅを使用するアドレス生成のための）インデックスフィールドの内容のスケーリングに備える。

ディスプレースメントフィールド１６６２Ａ − その内容は、メモリアドレス生成の一部として使用される（例えば２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅ＋ｄｉｓｐｌａｃｅｍｅｎｔを使用するアドレス生成のために）。

ディスプレースメントファクタフィールド１６６２Ｂ（ディスプレースメントファクタフィールド１６６２Ｂの直ぐ上にディスプレースメントフィールド１６６２Ａが並置されていることは、一方または他方が使用されることを示す） − その内容はアドレス生成の一部として使用され、メモリアクセスのサイズ（Ｎ）だけ調整されるべきディスプレースメントファクタを明示し、ここでＮはメモリアクセス内のバイトの数である（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅ＋ｓｃａｌｅｄ ｄｉｓｐｌａｃｅｍｅｎｔを使用するアドレス生成のための）。冗長な下位ビットは無視されるので、実効アドレスを計算するときに使用されるべき最終のディスプレースメントを生成するためにディスプレースメントファクタフィールドの内容にメモリオペランドの合計サイズ（Ｎ）が掛けられる。Ｎの値は、フルオペコードフィールド１６７４（本明細書において後に記載される）とデータ処理フィールド１６５４Ｃとに基づいて実行時にプロセッサハードウェアによって決定される。ディスプレースメントフィールド１６６２Ａおよびディスプレースメントファクタフィールド１６６２Ｂは、この両者がメモリアクセス無し１６０５命令テンプレートのためには使用されずおよび／または様々な実施形態がこの両者のうちの１つだけを使用するかまたはそのいずれをも使用しなくてよいという意味において、任意的である。

データエレメント幅フィールド１６６４ − その内容は数個のデータエレメント幅のうちのどの１つが使用されるべきかを識別する（或る実施形態では全ての命令のために、他の命令においては一部の命令だけのために）。このフィールドは、唯一のデータエレメント幅がサポートされおよび／またはオペコードの何らかの局面を用いて複数のデータエレメント幅がサポートされるならばこのフィールドは不要であるという意味において、任意的である。

ライトマスクフィールド１６７０ − その内容は、データエレメント位置に応じて、デスティネーションベクトルオペランド内でのそのデータエレメント位置がベース操作および増補操作の結果を反映するかどうかを制御する。クラスＡ命令テンプレートはマージングライトマスキングをサポートし、クラスＢ命令テンプレートはマージングライトマスキングとゼロイングライトマスキングとの両方をサポートする。マージングの時には、ベクトルマスクはデスティネーション内のエレメントの任意のセットを任意の操作（ベース操作および増補操作により指定される）の実行中にアップデートされないように保護することを可能にし、他の１つの実施形態においては、対応するマスクビットが０を有するデスティネーションの各エレメントの古い値を保存する。対照的に、ゼロイング時には、ベクトルマスクは任意の操作（ベース操作および増補操作により指定される）の実行中にデスティネーション内のエレメントの任意のセットがゼロ化されることを可能にし、一実施形態では、デスティネーション内のエレメントは、対応するマスクビットが０値を有するときには０にセットされる。この機能性の１つのサブセットは、実行されている操作のベクトル長を制御する能力であるが（すなわち、最初のエレメントから最後のエレメントまでの、エレメントの範囲が、改変される）、改変されるエレメントが連続している必要はない。このように、ライトマスクフィールド１６７０は、ロード、ストア、算術、論理などを含む部分的ベクトル操作に配慮している。ライトマスクフィールド１６７０の内容が数個のライトマスクレジスタのうちの、使用されるべきライトマスクを包含する１つを選択する（従ってライトマスクフィールド１６７０の内容が、その実行されるべきマスキングを間接的に特定する）実施形態が記載されたが、代替実施形態は、その代わりにあるいはそれに加えて、マスクライトフィールド１６７０の内容が実行されるべきマスキングを直接指定することを可能にする。

イミディエイトフィールド１６７２ − その内容は、イミディエイトの指定に備える。このフィールドは、イミディエイトをサポートしない一般的ベクトルフレンドリフォーマットの実装の中には存在しなくて、イミディエイトを使用しない命令の中には存在しないという意味において、任意的である。

クラスフィールド１６６８ − その内容は、命令の様々なクラスを区別する。図１６Ａ〜１６Ｂを参照すると、このフィールドの内容はクラスＡおよびクラスＢ命令のうちから選択をする。図１６Ａ〜１６Ｂにおいては、特定の値がフィールド内に存在することを示すために角の丸い四角形が使用されている（例えば、図１６Ａ〜１６Ｂにおいてクラスフィールド１６６８に対してそれぞれクラスＡ １６６８ＡおよびクラスＢ １６６８Ｂ）。

クラスＡの命令テンプレート クラスＡのメモリアクセス無し１６０５命令テンプレートの場合、アルファフィールド１６５２はＲＳフィールド１６５２Ａと解釈され、その内容は様々な増補操作タイプのうちのどの１つが実行されるべきかを識別し（例えば、丸め１６５２Ａ．１とデータ変換１６５２Ａ．２とは、それぞれ、メモリアクセス無し、丸めタイプ操作１６１０命令テンプレートとメモリアクセス無し、データ変換タイプ操作１６１５命令テンプレートとのために指定される）、ベータフィールド１６５４は、指定されたタイプの操作のうちのどれが実行されるべきかを識別する。メモリアクセス無し１６０５命令テンプレートにおいては、スケールフィールド１６６０、ディスプレースメントフィールド１６６２Ａ、およびディスプレースメントスケールフィールド１６６２Ｂは存在しない。

メモリアクセス無し命令テンプレート − 完全丸め制御タイプ操作 メモリアクセス無し完全丸め制御タイプ操作１６１０命令テンプレートにおいては、ベータフィールド１６５４は丸め制御フィールド１６５４Ａと解釈され、その１つまたは複数の内容は静的丸めを提供する。記載される実施形態においては丸め制御フィールド１６５４Ａは全浮動小数点例外抑制（ＳＡＥ（ｓｕｐｐｒｅｓｓ ａｌｌ ｆｌｏａｔｉｎｇ ｐｏｉｎｔ ｅｘｃｅｐｔｉｏｎｓ））フィールド１６５６と丸め操作制御フィールド１６５８とを含むが、代替実施形態は、これらのコンセプトの両方をサポートすることができ同じフィールドにコード化することができ、あるいはこれらのコンセプト／フィールドのうちの一方だけを持つことができる（例えば、丸め操作制御フィールド１６５８だけを持つことができる）。

ＳＡＥフィールド１６５６ − その内容は例外イベント報告を無効にするべきかどうかを識別する。抑制が使用可能にされていることをＳＡＥフィールド１６５６の内容が示しているならば、所与の命令は、どんな種類の浮動小数点例外フラグも報告せず、どんな浮動小数点例外ハンドラも起動しない。

丸め操作制御フィールド１６５８ − その内容は１群の丸め操作のうちのどれを実行するべきかを識別する（例えば、切り上げ、切り捨て、ゼロへの丸めおよび最も近い整数への丸め）。このように、丸め操作制御フィールド１６５８は、命令に従っての丸めモードの変更に備えている。プロセッサが丸めモードを指定するための制御レジスタを含む本発明の一実施形態では、丸め操作制御フィールドの１６５０の内容はそのレジスタ値をオーバーライドする。

メモリアクセス無し命令テンプレート − データ変換タイプ操作 メモリアクセス無しデータ変換タイプ操作１６１５命令テンプレートにおいて、ベータフィールド１６５４はデータ変換フィールド１６５４Ｂと解釈され、その内容は、数個のデータ変換のうちのどの１つが実行されるべきかを識別する（例えば、データ変換無し、スウィズル、ブロードキャスト）。

クラスＡのメモリアクセス１６２０命令テンプレートの場合、アルファフィールド１６５２はエビクションヒントフィールド１６５２Ｂと解釈され、その内容は、エビクションヒントのうちのどの１つが使用されるべきかを識別し（図１６Ａでは、一時的１６５２Ｂ．１および非一時的１６５２Ｂ．２がそれぞれメモリアクセス、一時的１６２５命令テンプレートおよびメモリアクセス、非一時的１６３０命令テンプレートのために指定される）、ベータフィールド１６５４はデータ処理フィールド１６５４Ｃと解釈され、その内容は、数個のデータ処理操作（プリミティブとしても知られている）のうちのどの１つが実行されるべきかを識別する（例えば、処理無し、ブロードキャスト、ソースのアップコンバート、デスティネーションのダウンコンバート）。メモリアクセス１６２０命令テンプレートはスケールフィールド１６６０を含むとともに、任意にディスプレースメントフィールド１６６２Ａまたはディスプレースメントスケールフィールド１６６２Ｂを含む。

ベクトルメモリ命令は、変換サポートを用いてメモリからのベクトルロードおよびメモリへのベクトルストアを実行する。正規のベクトル命令に関してと同じく、ベクトルメモリ命令はデータエレメント関連の仕方でデータをメモリから／メモリへ転送し、実際に転送されるエレメントは、ライトマスクとして選択されたベクトルマスクの内容によって規定される。

メモリアクセス命令テンプレート − 一時的 一時的データとは、キャッシングから利益を得るために十分早く再使用されると見込まれるデータである。しかし、この見込みはヒントであって、様々なプロセッサが、そのヒントを完全に無視することを含めて、様々な仕方でこのキャッシングを実装することができる。

メモリアクセス命令テンプレート − 非一時的 非一時的データとは、第１レベルのキャッシュでのキャッシングから利益を得るのに十分早くに再使用されるとは見込まれないデータであり、優先的にエビクションされる権利を与えられるべきである。しかし、この見込みはヒントであり、様々なプロセッサが、そのヒントを完全に無視することを含めて、様々な仕方でこのキャッシングを実装することができる。

クラスＢの命令テンプレート クラスＢの命令テンプレートの場合、アルファフィールド１６５２はライトマスク制御（Ｚ）フィールド１６５２Ｃと解釈され、その内容は、ライトマスクフィールド１６７０により制御されるライトマスキングがマージングであるべきかゼロイングであるべきかを識別する。

クラスＢのメモリアクセス無し１６０５命令テンプレートの場合、ベータフィールド１６５４の一部はＲＬフィールド１６５７Ａと解釈され、その内容は様々な増補操作タイプのうちのどの１つが実行されるべきかを識別し（例えば、メモリアクセス無し、ライトマスク制御、部分的丸め制御タイプ操作１６１２命令テンプレートとメモリアクセス無し、ライトマスク制御、ＶＳＩＺＥタイプ操作１６１７命令テンプレートとのために丸め１６５７Ａ．１とベクトル長（ＶＳＩＺＥ）１６５７Ａ．２とがそれぞれ指定される）、ベータフィールド１６５４の残りの部分は、指定されたタイプの操作のうちのどれが実行されるべきかを識別する。メモリアクセス無し１６０５命令テンプレートにおいては、スケールフィールド１６６０、ディスプレースメントフィールド１６６２Ａ、およびディスプレースメントスケールフィールド１６６２Ｂは存在しない。

メモリアクセス無し、ライトマスク制御、部分的丸め制御タイプ操作１６１２命令テンプレートにおいては、ベータフィールド１６５４の残りの部分は丸め操作フィールド１６５９Ａと解釈され、例外イベント報告は無効にされる（所与の命令はどんな種類の浮動小数点例外フラグも報告せず、どんな浮動小数点例外ハンドラも起動しない）。

丸め操作制御フィールド１６５９Ａ − 丸め操作制御フィールド１６５８と全く同様に、その内容は１群の丸め操作のうちのどの１つが実行されるべきかを識別する（例えば、切り上げ、切り捨て、ゼロへの丸めおよび最も近い整数への丸め）。このように、丸め操作制御フィールド１６５９Ａは、命令に従っての丸めモードの変更に備えている。プロセッサが丸めモードを指定するための制御レジスタを含む本発明の一実施形態では、丸め操作制御フィールドの１６５０の内容はそのレジスタ値をオーバーライドする。

メモリアクセス無し、ライトマスク制御、ＶＳＩＺＥタイプ操作１６１７命令テンプレートにおいては、ベータフィールド１６５４の残りの部分はベクトル長フィールド１６５９Ｂと解釈され、その内容は数個のデータベクトル長のうちのどの１つが実行されるべきかを識別する（例えば、１２８、２５６、または５１２バイト）。

クラスＢのメモリアクセス１６２０命令テンプレートにおいては、ベータフィールド１６５４の一部はブロードキャストフィールド１６５７Ｂと解釈され、その内容はブロードキャストタイプのデータ処理操作が実行されるべきか否かを識別し、ベータフィールド１６５４の残りの部分はベクトル長フィールド１６５９Ｂと解釈される。メモリアクセス１６２０命令テンプレートは、スケールフィールド１６６０を含むとともに、任意にディスプレースメントフィールド１６６２Ａまたはディスプレースメントスケールフィールド１６６２Ｂを含む。

一般的ベクトルフレンドリ命令フォーマット１６００に関して、フォーマットフィールド１６４０、ベース操作フィールド１６４２、およびデータエレメント幅フィールド１６６４を含むフルオペコードフィールド１６７４が示されている。フルオペコードフィールド１６７４がこれらのフィールドの全てを含んでいる一実施形態が示されているが、これらの全てをサポートするわけではない実施形態ではフルオペコードフィールド１６７４はこれらのフィールドの一部だけを含む。フルオペコードフィールド１６７４は、操作コード（オペコード）を提供する。

増補操作フィールド１６５０、データエレメント幅フィールド１６６４、およびライトマスクフィールド１６７０は、一般的ベクトルフレンドリ命令フォーマットにおいてこれらの特徴事項が命令通りに指定されることを可能にする。

ライトマスクフィールドとデータエレメント幅フィールドとの組み合わせは、これらのフィールドが様々なデータエレメント幅に基づいてマスクが適用されることを可能にするという点で、類別された命令を生み出す。

クラスＡおよびクラスＢの中に見出される種々の命令テンプレートは、様々な状態において有利である。或る実施形態では、様々なプロセッサまたはプロセッサ内の様々なコアは、クラスＡだけ、クラスＢだけ、または両方のクラスをサポートすることができる。例えば、汎用コンピューティング向けの高性能汎用アウトオブオーダーコアはクラスＢだけをサポートすることができ、主にグラフィクスおよび／または科学（スループット）コンピューティング向けのコアはクラスＡだけをサポートすることができ、両方向けのコアは両方をサポートすることができる（もちろん、両方のクラスのテンプレートおよび命令の何らかの混合物を有するが両方のクラスのテンプレートおよび命令の全ては有しないコアは本発明の範囲内にある）。さらに、単一のプロセッサは複数のコアを含むことができ、その全てが同じクラスをサポートするかまたは異なるコアが異なるクラスをサポートする。例えば、別々のグラフィクスコアと汎用コアとを有するプロセッサにおいて、主にグラフィクスおよび／または科学コンピューティング向けのグラフィクスコアのうちの１つはクラスＡだけをサポートすることができ、汎用コアのうちの１つまたは複数の汎用コアは、クラスＢだけをサポートする汎用コンピューティング向けのアウトオブオーダー実行およびレジスタリネーミングを行う高性能汎用コアであり得る。独立のグラフィクスコアを持っていない別のプロセッサは、クラスＡおよびクラスＢの両方をサポートするもう１つの汎用インオーダーまたはアウトオブオーダーコアを含み得る。もちろん、一方のクラスの特徴事項は様々な実施形態において他方のクラスに実装されることもできる。高レベル言語で書かれたプログラムは、１）実行のためのターゲットプロセッサによりサポートされる１つまたは複数のクラスの命令だけを有する形、または２）全てのクラスの命令の様々な組み合わせを用いて書かれた代替ルーチンを有するとともに、現在そのコードを実行しているプロセッサによりサポートされる命令に基づいて実行するルーチンを選択する制御フローコードを有する形、を含む多様な実行可能の形に変換（例えばジャストインタイムにコンパイルされまたは静的にコンパイル）されるであろう。

典型的な特定ベクトルフレンドリ命令フォーマット 図１７Ａは、一実施形態による典型的な特定ベクトルフレンドリ命令フォーマットを示すブロック図である。図１７Ａは、フィールドの位置、サイズ、解釈、および順序、ならびにこれらのフィールドのうちの或るものの値を明示するという意味において特定的である特定ベクトルフレンドリ命令フォーマット１７００を示す。特定ベクトルフレンドリ命令フォーマット１７００はｘ８６命令セットを拡張するために使用されることができ、従って、そのフィールドのうちの或るものは既存のｘ８６命令セットおよびそのエクステンション（例えば、ＡＶＸ）に使用されるフィールドと類似するかまたは同一である。このフォーマットは、エクステンションを有する既存のｘ８６命令セットのプレフィックスコード化フィールド、実オペコードバイトフィールド、ＭＯＤ Ｒ／Ｍフィールド、ＳＩＢフィールド、ディスプレースメントフィールド、およびイミディエイトフィールドと依然として矛盾しない。図１７Ａのフィールドが対応する図１６Ａまたは１６Ｂのフィールドが具体的に説明される。

説明を目的として一般的ベクトルフレンドリ命令フォーマット１６００と関連して特定ベクトルフレンドリ命令フォーマット１７００について実施形態が記載されるけれども、本発明は特許請求の範囲に記載される場合を除いて特定ベクトルフレンドリ命令フォーマット１７００に限定されないということが理解されるべきである。例えば、一般的ベクトルフレンドリ命令フォーマット１６００は種々のフィールドについて多様なサイズが可能であると考えているが、特定ベクトルフレンドリ命令フォーマット１７００は特定のサイズのフィールドを有するものとして示されている。特定の例を挙げると、データエレメント幅フィールド１６６４は特定ベクトルフレンドリ命令フォーマット１７００において１ビットのフィールドとして図示されているが、本発明はそのようには限定されない（すなわち、一般的ベクトルフレンドリ命令フォーマット１６００はデータエレメント幅フィールド１６６４の他のサイズを考慮している）。

一般的ベクトルフレンドリ命令フォーマット１６００は、以下にリストされている次のフィールドを、図１７Ａに示されている順に含む。

ＥＶＥＸプレフィックス（バイト０〜３）１７０２ − ４バイトの形にコード化される。

フォーマットフィールド１６４０（ＥＶＥＸバイト０、ビット［７：０］） − 第１バイト（ＥＶＥＸバイト０）は、フォーマットフィールド１６４０であり、０ｘ６２（本発明の一実施形態においてベクトルフレンドリ命令フォーマットを識別するために使用される一意の値）を含む。

第２バイト〜第４バイト（ＥＶＥＸバイト１〜３）は、特定の機能を提供する数個のビットフィールドを含む。

ＲＥＸフィールド１７０５（ＥＶＥＸバイト１、ビット［７〜５］） − ＥＶＥＸ．Ｒビットフィールド（ＥＶＥＸバイト１、ビット［７］〜Ｒ）、ＥＶＥＸ．Ｘビットフィールド（ＥＶＥＸバイト１、ビット［６］〜Ｘ）、および１６５７ＢＥＸバイト１、ビット［５］〜Ｂ）から成る。ＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ、およびＥＶＥＸ．Ｂビットフィールドは対応するＶＥＸビットフィールドと同じ機能を提供し、１の補数の形を用いてコード化される、すなわち、ＺＭＭ０は１１１１Ｂにコード化され、ＺＭＭ１５は００００Ｂにコード化される。命令の他のフィールドはレジスタインデックスの下位３ビットを当該技術において知られている通りにコード化するので（ｒｒｒ、ｘｘｘ、およびｂｂｂ）、Ｒｒｒｒ、Ｘｘｘｘ、およびＢｂｂｂはＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ、およびＥＶＥＸ．Ｂを加えることにより形成され得る。

ＲＥＸ'フィールド１６１０ − これは、ＲＥＸ'フィールド１６１０の第１部分であり、拡張３２レジスタセットの上位１６または下位１６をコード化するために使用されるＥＶＥＸ．Ｒ'ビットフィールド（ＥＶＥＸバイト１、ビット［４］〜Ｒ'）である。本発明の一実施形態では、このビットは、以下に示される他のビットと共に、その実オペコードバイトが６２であるＢＯＵＮＤ命令から（よく知られているｘ８６の３２ビットモードで）区別するためにビット反転フォーマットで格納されるけれども、ＭＯＤ Ｒ／Ｍフィールド（以下に記載される）においてＭＯＤフィールドにおける１１という値を認めず、代替実施形態は、このビットと以下に示される他のビットとを反転フォーマットで格納しない。１という値は下位１６個のレジスタをコード化するために使用される。換言すれば、Ｒ'ＲｒｒｒはＥＶＥＸ．Ｒ'、ＥＶＥＸ．Ｒ、および他のフィールドからの他のＲＲＲを結合させることによって形成される。

オペコードマップフィールド１７１５（ＥＶＥＸバイト１、ビット［３：０］〜ｍｍｍｍ） − その内容は、暗に示された先頭のオペコードバイト（０Ｆ、０Ｆ３８、または０Ｆ３）をコード化する。

データエレメント幅フィールド１６６４（ＥＶＥＸバイト２、ビット［７］〜Ｗ） − ＥＶＥＸ．Ｗという表記で表される。ＥＶＥＸ．Ｗは、データタイプのグラニュラリティ（サイズ）（３２ビットのデータエレメントまたは６４ビットのデータエレメント）を定義するために使用される。

ＥＶＥＸ．ｖｖｖｖ１７２０（ＥＶＥＸバイト２、ビット［６：３］〜ｖｖｖｖ） − ＥＶＥＸ．ｖｖｖｖの役割は、次のものを含み得る、すなわち、１）ＥＶＥＸ．ｖｖｖｖは、反転（１の補数）形で明示される、第１ソースレジスタオペランドをコード化し、２つ以上のソースオペランドを有する命令のために有効である、２）ＥＶＥＸ．ｖｖｖｖは、一定のベクトルシフトのために１の補数の形で明示される、デスティネーションレジスタオペランドをコード化する、または３）ＥＶＥＸ．ｖｖｖｖはいかなるオペランドもコード化せず、このフィールドはリザーブされて１１１１ｂを含むべきである。ＥＶＥＸ．ｖｖｖｖフィールド１７２０は、反転（１の補数）形で格納された第１ソースレジスタ指定子の４個の下位ビットをコード化する。命令に応じて、指定子サイズを３２レジスタまで拡張するために余分の異なるＥＶＥＸビットフィールドが使用される。

ＥＶＥＸ．Ｕ１６６８クラスフィールド（ＥＶＥＸバイト２、ビット［２］〜Ｕ） − もしＥＶＥＸ．Ｕ＝０ならば、それはクラスＡまたはＥＶＥＸ．Ｕ０を示し、もしＥＶＥＸ．Ｕ＝１ならば、それはクラスＢまたはＥＶＥＸ．Ｕ１を示す。

プレフィックスコード化フィールド１７２５（ＥＶＥＸバイト２、ビット［１：０］〜ｐｐ − ベース操作フィールドのために追加のビットを提供する。ＥＶＥＸプレフィックスフォーマットのレガシーＳＳＥ命令のためにサポートを提供するほかに、このフィールドはＳＩＭＤプレフィックスを圧縮するという長所を有する（ＳＩＭＤプレフィックスを表現するために１バイトを必要とするのではなくて、ＥＶＥＸプレフィックスは２ビットを必要とするだけである）。一実施形態では、ＳＩＭＤプレフィックス（６６Ｈ、Ｆ２Ｈ、Ｆ３Ｈ）をレガシーフォーマットおよびＥＶＥＸプレフィックスフォーマットの両方で使用するレガシーＳＳＥ命令をサポートするために、これらのレガシーＳＩＭＤプレフィックスは、ＳＩＭＤプレフィックスコード化フィールドにコード化され、実行時に、デコーダのＰＬＡに提供される前に（ＰＬＡがこれらのレガシー命令のレガシーフォーマットおよびＥＶＥＸフォーマットの両方を修正なしに実行できるように）レガシーＳＩＭＤプレフィックスに拡張される。より新しい命令はＥＶＥＸプレフィックスコード化フィールドの内容を直接オペコードエクステンションとして使用できるであろうけれども、或る実施形態は整合性を目的として同様の仕方で拡大するが、これらのレガシーＳＩＭＤプレフィックスによってさまざまな意味が明示されることを見越している。代替実施形態は、２ビットＳＩＭＤプレフィックスコード化をサポートし、従ってそのような拡大を必要としないようにＰＬＡを設計し直すであろう。

アルファフィールド１６５２（ＥＶＥＸバイト３、ビット［７］〜ＥＨ、ＥＶＥＸ．ＥＨ、ＥＶＥＸ．ｒｓ、ＥＶＥＸ．ＲＬ、ＥＶＥＸ．ｗｒｉｔｅ ｍａｓｋ ｃｏｎｔｒｏｌ、およびＥＶＥＸ．Ｎとも称され、αを用いても図示される） − 前述のように、このフィールドはコンテキスト特有である。

ベータフィールド１６５４（ＥＶＥＸバイト３、ビット［６：４］〜ＳＳＳ、ＥＶＥＸ．Ｓ_２−０、ＥＶＥＸ．ｒ_２−０、ＥＶＥＸ．ｒｒ１、ＥＶＥＸ．ＬＬ０、ＥＶＥＸ．ＬＬＢとも称され、βββを用いても図示される） − 前述のように、このフィールドはコンテキスト特有である。

ＲＥＸ'フィールド１７１０ − これはＲＥＸ'フィールドの残りであり、拡張された３２レジスタセットの上位１６個または下位１６個をコード化するために使用され得るＥＶＥＸ．Ｖ'ビットフィールド（ＥＶＥＸバイト３、ビット［３］〜Ｖ'）である。このビットはビット反転フォーマットで格納される。１の値は下位１６個のレジスタをコード化するために使用される。換言すれば、ＥＶＥＸ．Ｖ'、ＥＶＥＸ．ｖｖｖｖを結合させることによってＶ'ＶＶＶＶが形成される。

ライトマスクフィールド１６７０（ＥＶＥＸバイト３、ビット［２：０］〜ｋｋｋ） − その内容は、前述のようにライトマスクレジスタのうちのレジスタのインデックスを指定する。本発明の一実施形態では、特定の値ＥＶＥＸ．ｋｋｋ＝０００は特定の命令のためにライトマスクが使用されないことを暗に示す特別の挙動を有する（この挙動は、オール１に配線されたライトマスク、またはマスキングハードウェアを迂回するハードウェアの使用を含む様々な仕方で実装され得る）。

実オペコードフィールド１７３０（バイト４）は、オペコードバイトとも称される。オペコードの一部はこのフィールドで明示される。

ＭＯＤ Ｒ／Ｍフィールド１７４０（バイト５）は、ＭＯＤフィールド１７４２、Ｒｅｇフィールド１７４４、およびＲ／Ｍフィールド１７４６を含む。前述のように、ＭＯＤフィールド１７４２の内容はメモリアクセス操作とメモリアクセス無し操作とを区別する。Ｒｅｇフィールド１７４４の役割は２つの事態、すなわち、デスティネーションレジスタオペランドもしくはソースレジスタオペランドをコード化するという事態、または、オペコードエクステンションとして扱われていかなる命令オペランドをコード化するためにも使用されないという事態、に要約され得る。Ｒ／Ｍフィールド１７４６の役割は、メモリアドレスを参照する命令オペランドをコード化すること、または、デスティネーションレジスタオペランドもしくはソースレジスタオペランドをコード化することを含み得る。

スケール（Ｓｃａｌｅ）、インデックス（Ｉｎｄｅｘ）、ベース（Ｂａｓｅ）（ＳＩＢ）バイト（バイト６） − 前述のように、スケールフィールド１６５０の内容は、メモリアドレス生成のために使用される。ＳＩＢ．ｘｘｘ１７５４およびＳＩＢ．ｂｂｂ１７５６ − これらのフィールドの内容は、レジスタインデックスＸｘｘｘおよびＢｂｂｂに関して前に言及されている。

ディスプレースメントフィールド１６６２Ａ（バイト７〜１０） − ＭＯＤフィールド１７４２が１０を含むとき、バイト７〜１０はディスプレースメントフィールド１６６２Ａであり、レガシー３２ビットディスプレースメント（ｄｉｓｐ３２）と同様に働いてバイトグラニュラリティで働く。

ディスプレースメントファクタフィールド１６６２Ｂ（バイト７） − ＭＯＤフィールド１７４２が０１を含むとき、バイト７はディスプレースメントファクタフィールド１６６２Ｂである。このフィールドの位置は、バイトグラニュラリティで働くレガシーｘ８６命令セット８ビットディスプレースメント（ｄｉｓｐ８）の位置と同じである。ｄｉｓｐ８は符号拡張されるので−１２８と１２７バイトの間のオフセットでアドレス指定することができるに過ぎず、６４バイトキャッシュラインに関してはｄｉｓｐ８は４つの真に有益な値−１２８、−６４、０、および６４、にセットされ得るにすぎない８ビットを使用し、もっと大きな範囲がしばしば必要なのでｄｉｓｐ３２が使用されるが、ｄｉｓｐ３２は４バイトを必要とする。ｄｉｓｐ８およびｄｉｓｐ３２とは対照的に、ディスプレースメントファクタフィールド１６６２Ｂはｄｉｓｐ８の再解釈であり、ディスプレースメントファクタフィールド１６６２Ｂを使用するときには実際のディスプレースメントはメモリオペランドアクセスのサイズ（Ｎ）を掛けられたディスプレースメントファクタフィールドの内容によって決まる。このタイプのディスプレースメントはｄｉｓｐ８＊Ｎと称される。このタイプのディスプレースメントは平均命令長を小さくする（ディスプレースメントのために単一バイトが、もっとはるかに大きな範囲を伴って、使用される）。このような圧縮されたディスプレースメントは、実際のディスプレースメントはメモリアクセスのグラニュラリティの倍数であり、従ってアドレスオフセットの冗長な下位ビットをコード化する必要はないという想定に基づいている。換言すれば、ディスプレースメントファクタフィールド１６６２Ｂはレガシーｘ８６命令セットの８ビットディスプレースメントに取って代わる。従ってディスプレースメントファクタフィールド１６６２Ｂは、ｄｉｓｐ８がｄｉｓｐ８＊Ｎに多重定義されることを唯一の例外として、ｘ８６命令セットの８ビットディスプレースメントと同様にコード化される（従ってＭｏｄＲＭ／ＳＩＢコード化規則に変更はない）。換言すれば、ハードウェアによるディスプレースメント値の解釈における変更（これはバイト単位のアドレスオフセットを得るためにディスプレースメントをメモリオペランドのサイズだけスケーリングすることを必要とする）を除けばコード化規則やコード化長における変更はない。

イミディエイトフィールド１６７２は、前述のように働く。

フルオペコードフィールド 図１７Ｂは、本発明の一実施形態による、フルオペコードフィールド１６７４を構成する特定ベクトルフレンドリ命令フォーマット１７００のフィールドを示すブロック図である。具体的には、フルオペコードフィールド１６７４は、フォーマットフィールド１６４０、ベース操作フィールド１６４２、およびデータエレメント幅（Ｗ）フィールド１６６４を含む。ベース操作フィールド１６４２は、プレフィックスコード化フィールド１７２５、オペコードマップフィールド１７１５、および実オペコードフィールド１７３０を含む。

レジスタインデックスフィールド 図１７Ｃは、本発明の一実施形態によるレジスタインデックスフィールド１６４４を構成する特定ベクトルフレンドリ命令フォーマット１７００のフィールドを示すブロック図である。具体的には、レジスタインデックスフィールド１６４４は、ＲＥＸフィールド１７０５、ＲＥＸ'フィールド１７１０、ＭＯＤＲ／Ｍ．ｒｅｇフィールド１７４４、ＭＯＤＲ／Ｍ．ｒ／ｍフィールド１７４６、ＶＶＶＶフィールド１７２０、ｘｘｘフィールド１７５４、およびｂｂｂフィールド１７５６を含む。

増補操作フィールド 図１７Ｄは、本発明の一実施形態による増補操作フィールド１６５０を構成する特定ベクトルフレンドリ命令フォーマット１７００のフィールドを示すブロック図である。クラス（Ｕ）フィールド１６６８が０を含むとき、それはＥＶＥＸ．Ｕ０（クラスＡ １６６８Ａ）を意味し、このフィールドが１を含むとき、それはＥＶＥＸ．Ｕ１（クラスＢ １６６８Ｂ）を意味する。Ｕ＝０でＭＯＤフィールド１７４２が１１を含むとき（メモリアクセス無し操作を意味する）、アルファフィールド１６５２（ＥＶＥＸバイト３、ビット［７］〜ＥＨ）はｒｓフィールド１６５２Ａと解釈される。ｒｓフィールド１６５２Ａが１を含むとき（丸め１６５２Ａ．１）、ベータフィールド１６５４（ＥＶＥＸバイト３、ビット［６：４］〜ＳＳＳ）は丸め制御フィールド１６５４Ａと解釈される。丸め制御フィールド１６５４Ａは、１ビットＳＡＥフィールド１６５６および２ビット丸め制御フィールド１６５８を含む。ｒｓフィールド１６５２Ａが０を含むとき（データ変換１６５２Ａ．２）、ベータフィールド１６５４（ＥＶＥＸバイト３、ビット［６：４］〜ＳＳＳ）は３ビットデータ変換フィールド１６５４Ｂと解釈される。Ｕ＝０でＭＯＤフィールド１７４２が００、０１、または１０を含むとき（メモリアクセス操作を意味する）、アルファフィールド１６５２（ＥＶＥＸバイト３、ビット［７］〜ＥＨ）はエビクションヒント（ＥＨ）フィールド１６５２Ｂと解釈されベータフィールド１６５４（ＥＶＥＸバイト３、ビット［６：４］〜ＳＳＳ）は３ビットデータ処理フィールド１６５４Ｃと解釈される。

Ｕ＝１であるとき、アルファフィールド１６５２（ＥＶＥＸバイト３、ビット［７］〜ＥＨ）はライトマスク制御（Ｚ）フィールド１６５２Ｃと解釈される。Ｕ＝１でＭＯＤフィールド１７４２が１１を含むとき（メモリアクセス無し操作を意味する）、ベータフィールド１６５４の一部（ＥＶＥＸバイト３、ビット［４］〜Ｓ_０）はＲＬフィールド１６５７Ａと解釈され、ＲＬフィールドが１を含むとき（丸め１６５７Ａ．１）ベータフィールド１６５４の残り（ＥＶＥＸバイト３、ビット［６〜５］〜Ｓ_２〜１）は丸め操作フィールド１６５９Ａと解釈され、ＲＬフィールド１６５７Ａが０を含むとき（ＶＳＩＺＥ１６５７Ａ．２）ベータフィールド１６５４の残り（ＥＶＥＸバイト３、ビット［６〜５］〜Ｓ_２〜１）はベクトル長フィールド１６５９Ｂ（ＥＶＥＸバイト３、ビット［６〜５］〜Ｌ_１〜０）と解釈される。Ｕ＝１でＭＯＤフィールド１７４２が００、０１、または１０を含むとき（メモリアクセス操作を意味する）、ベータフィールド１６５４（ＥＶＥＸバイト３、ビット［６：４］〜ＳＳＳ）はベクトル長フィールド１６５９Ｂ（ＥＶＥＸバイト３、ビット［６〜５］〜Ｌ_１〜０）およびブロードキャストフィールド１６５７Ｂ（ＥＶＥＸバイト３、ビット［４］〜Ｂ）と解釈される。

典型的レジスタアーキテクチャ 図１８は、本発明の一実施形態によるレジスタアーキテクチャ１８００のブロック図である。図示されている実施形態では、５１２ビット幅である３２個のベクトルレジスタ１８１０があり、これらのレジスタはｚｍｍ０からｚｍｍ３１までとして参照される。下位１６個のレジスタの下位２５６ビットはレジスタｙｍｍ０〜１６にオーバーレイされる。下位１６個のｚｍｍレジスタの下位１２８ビット（ｙｍｍレジスタの下位１２８ビット）はレジスタｘｍｍ０〜１５にオーバーレイされる。特定ベクトルフレンドリ命令フォーマット１７００は、下記の表４に示されているように、これらのオーバーレイされたレジスタファイル上で動作する。

換言すれば、ベクトル長フィールド１６５９Ｂは最大長および１つまたは複数の他のもっと短い長さのうちから選択をし、そのようなもっと短い長さの各々は先行する長さの半分であり、ベクトル長フィールド１６５９Ｂを有しない命令テンプレートは最大べクトクル長で作用する。さらに、一実施形態では、特定ベクトルフレンドリ命令フォーマット１７００のクラスＢ命令テンプレートはパックドまたはスカラーの単精度／倍精度浮動小数点データおよびパックドまたはスカラーの整数データに対して作用する。スカラー演算はｚｍｍ／ｙｍｍ／ｘｍｍレジスタにおいて最下位データエレメント位置に対して行われる演算であり、より高位のデータエレメント位置は、実施形態に依存してその命令の前にそれらのデータ位置があったのと同じままにされるかまたはゼロイングされる。

ライトマスクレジスタ１８１５ − 図示されている実施形態では、各々６４ビットのサイズのライトマスクレジスタ（ｋ０からｋ７まで）が８個ある。１つの代替実施形態では、ライトマスクレジスタ１８１５のサイズは１６ビットである。前に記載されたように、本発明の一実施形態では、ベクトルマスクレジスタｋ０はライトマスクとしては使用され得ず、通常ｋ０を示すコード化がライトマスクのために使用されるときには、そのコード化は０ｘＦＦＦＦのハードワイヤードライトマスクを選択して、その命令のためのライトマスキングを実際上無効にする。

汎用レジスタ１８２５ − 図示されている実施形態では、メモリオペランドをアドレス指定する既存のｘ８６アドレス指定モードと共に使用される６４ビットの汎用レジスタが１６個ある。これらのレジスタは、ＲＡＸ、ＲＢＸ、ＲＣＸ、ＲＤＸ、ＲＢＰ、ＲＳＩ、ＲＤＩ、ＲＳＰ、およびＲ８からＲ１５までという名前で参照される。

ＭＭＸパックド整数フラットレジスタファイル１８５０がその上でエイリアシングされるスカラー浮動小数点スタックレジスタファイル（ｘ８７スタック）１８４５ − 図示されている実施形態では、ｘ８７スタックはｘ８７命令セットエクステンションを用いて３２／６４／８０−ビット浮動小数点データに対してスカラー浮動小数点演算を行うために使用される８エレメントのスタックであり、ＭＭＸレジスタは、６４ビットのパックド整数データに対して演算を行うためにも、ＭＭＸレジスタおよびＸＭＭレジスタの間で行われる幾つかの演算のためにオペランドを保持するためにも使用される。

代替実施形態は、もっと幅の広いまたは狭いレジスタを使用することができる。さらに、代替実施形態は、もっと多い、少ない、または異なるレジスタファイルおよびレジスタを使用することができる。

前述の明細書において、本発明はその特定の典型的実施形態と関連して記載されている。しかし、添付されている特許請求の範囲において明らかにされる発明のもっと広い趣旨および範囲から逸脱せずにそれらの実施形態に対して種々の改変および変更を加え得ることは明らかであろう。従って、明細書および図面は、限定的意味においてではなくて例示的意味において評価されるべきである。

本明細書に記載されているのは、特定の操作または動作を、それらの動作をシステムに行わせるべくソフトウェア、ファームウェア、ハードウェアまたはこれらの組み合わせをシステムに組み込んだおかげで、行うように構成され得る１つまたは複数のコンピュータのシステムである。一実施形態では、処理装置は、第１の命令を、第１オペランドを含むデコード済み第１命令にデコードするデコード論理と、プレディケートレジスタスタック上のプレディケート値にアクセスするためにそのデコード済み第１命令を実行する実行ユニットとを含む。

一実施形態では、機械可読媒体は、少なくとも１つの機械により実行されるとその少なくとも１つの機械に、命令をデコード済み第１命令にデコードすること、プレディケートレジスタスタックから第１プレディケート値を取り出すこと、およびその第１プレディケート値に基づいてデコード済み第１命令を条件付きで実行することを含む操作を実行する少なくとも１つの集積回路を製造させるデータを格納する。

一実施形態では、プロセッサは、第１オペランドを有する命令をデコード済み第１命令にデコードすること、１つまたは複数のプレディケート値を含む第１オペランド値を取り出すこと、およびその１つまたは複数のプレディケート値をスタックの頂部識別子により示されるプレディケートスタック内の位置へプッシュすることを含む方法をこのプロセッサに実行させる命令を実行する。

本明細書に記載されている命令は、一定の操作を実行するように構成されているかまたは所定の機能性を有する特定用途向け集積回路（ＡＳＩＣ）などのハードウェアの特定の構成に関連している。そのような電子デバイスは、通例、１つまたは複数のストレージデバイス（非一時的機械可読記憶媒体）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、および／またはディスプレイ）、およびネットワークコネクションなどの１つまたは複数の他のコンポーネントに結合された１つまたは複数のプロセッサのセットを含む。プロセッサのセットと他のコンポーネントとの結合は、通例、１つまたは複数のバスおよびブリッジ（バスコントローラとも称される）による。ストレージデバイスとネットワークトラフィックを伝える信号とは、それぞれ、１つまたは複数の機械可読記憶媒体と機械可読通信媒体とを代表する。従って、所与の電子デバイスのストレージデバイスは、通例、その電子デバイスの１つまたは複数のプロセッサのセット上での実行のためのコードおよび／またはデータを格納する。

この詳細な記載の全体にわたって、説明の目的上、本発明の完全な理解を提供するために多数の具体的な細部が明らかにされた。しかし、これらの具体的細部の幾つかが無くても本発明を実施し得ることは明らかであろう。或る場合には、本発明の主題を不明瞭にするのを避けるために周知の構造および機能は精密には記載されなかった。従って、本発明の範囲および趣旨は、以下の特許請求の範囲の見地から判断されるべきである。
本願によれば、以下の各項目もまた開示される。
［項目１］
第１命令を、第１オペランドを含むデコード済み第１命令にデコードするデコード論理と、
プレディケートレジスタスタック上のプレディケート値にアクセスするために上記デコード済み第１命令を実行する実行ユニットと、
を含む処理装置。
［項目２］
上記第１命令は上記プレディケートレジスタスタック上のプレディケートレジスタの論理識別子を含む第１オペランドを含む、項目１に記載の処理装置。
［項目３］
上記プレディケートレジスタスタック上の上記プレディケートレジスタの上記論理識別子はスタックの頂部識別子に関する、項目２に記載の処理装置。
［項目４］
上記実行ユニットは、上記論理識別子により示されるプレディケート値を読み出して上記プレディケート値に基づいて上記デコード済み第１命令を条件付きで実行するものである、項目３に記載の処理装置。
［項目５］
上記実行ユニットは、上記論理識別子により示されるプレディケート値を読み出して上記プレディケート値に基づいて上記デコード済み第１命令を条件付きでコミットするものである、項目３または４に記載の処理装置。
［項目６］
上記論理識別子を物理的レジスタ識別子にリネームするレジスタリネーム論理をさらに含む、項目３から５のいずれか１項に記載の処理装置。
［項目７］
上記レジスタリネーム論理は、上記物理的レジスタ識別子を計算する算術論理ユニットと、上記スタックの頂部識別子を格納するためのスタックの頂部レジスタとを含む、項目６に記載の処理装置。
［項目８］
上記スタックの頂部識別子を格納するための１つまたは複数のシャドウスタックの頂部レジスタをさらに含む、項目７に記載の処理装置。
［項目９］
上記実行ユニットは、さらに、上記デコード済み第１命令の実行中に生成済みプレディケート値を生成して上記生成済みプレディケート値を上記プレディケートレジスタスタックへプッシュするものである、項目１から８のいずれか１項に記載の処理装置。
［項目１０］
上記実行ユニットは、さらに、上記生成済みプレディケート値の上記プッシュの後にスタックの頂部インジケータを前進させるものである、項目９に記載の処理装置。
［項目１１］
少なくとも１つの機械により実行されると、上記少なくとも１つの機械に、
命令をデコード済み第１命令にデコードすることと、
プレディケートレジスタスタックから第１プレディケート値を取り出すことと、
上記第１プレディケート値に基づいて上記デコード済み第１命令を条件付きで実行することと、
を実行させるための、コンピュータプログラム。
［項目１２］
上記プレディケートレジスタスタックはスタックの頂部識別子を含み、上記プレディケートレジスタスタックから上記第１プレディケート値を取り出すことは上記スタックの頂部識別子からのオフセットに基づいて上記プレディケートレジスタスタックにおける論理位置を判定することを含む、項目１１に記載のコンピュータプログラム。
［項目１３］
上記少なくとも１つの機械に、
プレディケートレジスタリネーム論理を介して上記プレディケートレジスタスタックにおける上記論理位置の物理レジスタＩＤを判定することをさらに実行させるための、項目１２に記載のコンピュータプログラム。
［項目１４］
上記少なくとも１つの機械に、
少なくとも部分的に第２プレディケート値に基づいて投機的分岐実行を行うことをさらに実行させるための、項目１１から１３のいずれか１項に記載のコンピュータプログラム。
［項目１５］
上記少なくとも１つの機械に、
上記プレディケートレジスタスタック上の第３プレディケート値を読み出すことと、上記第３プレディケート値に基づいて投機的分岐実行をアボートすることとをさらに実行させるための、項目１４に記載のコンピュータプログラム。
［項目１６］
上記少なくとも１つの機械に、
上記投機的分岐実行を行う前にスタックの頂部識別子をシャドウスタックの頂部レジスタに格納することをさらに実行させるための、項目１４または１５に記載のコンピュータプログラム。
［項目１７］
上記少なくとも１つの機械に、
分岐投機ミスからの回復後に上記プレディケートレジスタスタックのための上記スタックの頂部識別子をシャドウスタックの頂部レジスタから復元することをさらに実行させるための、項目１６に記載のコンピュータプログラム。
［項目１８］
項目１１から１７のいずれか１項に記載のコンピュータプログラムを格納する、コンピュータ可読記録媒体。
［項目１９］
第１オペランドを有する命令をデコード済み第１命令にデコードすることと、
１つまたは複数のプレディケート値を含む第１オペランド値を取り出すことと、
スタックの頂部識別子により示されるプレディケートスタック内の位置へ上記１つまたは複数のプレディケート値をプッシュすることと、
を含むプロセッサ実行される方法。
［項目２０］
上記第１オペランドを上記１つまたは複数のプレディケート値にデコードすることをさらに含む、項目１９に記載の方法。
［項目２１］
上記命令は第１命令であり、上記スタックの頂部識別子は上記１つまたは複数のプレディケート値をプッシュした後に前進させられる、項目１９または２０に記載の方法。
［項目２２］
上記命令は第２命令であり、上記スタックの頂部識別子は、上記１つまたは複数のプレディケート値を上記プレディケートスタックへプッシュした後に、前進させられない、項目１９から２１のいずれか１項に記載の方法。
［項目２３］
上記命令は、上記第２命令をデコードする前に部分的に上記スタックの頂部識別子の位置に基づいて上記スタックの頂部識別子を改変する第３命令である、項目２２に記載の方法。
［項目２４］
上記第３命令は、上記第２命令によりプッシュされた上記１つまたは複数のプレディケート値のうちの最後のものに基づいて上記スタックの頂部識別子を改変するものである、項目２３に記載の方法。
［項目２５］
項目１９から２４のいずれか１項に記載の方法を実行するための手段を含む処理システム。

Claims (23)

1. 第１命令を、第１オペランドを含むデコード済み第１命令にデコードするデコード論理と、
   プレディケートレジスタスタック上のプレディケート値にアクセスするために前記デコード済み第１命令を実行する実行ユニットと、
   プロセッサパイプラインのリネーミングステージよりも前に、前記第１オペランドに含まれる前記プレディケートレジスタスタック上のプレディケートレジスタの論理識別子を物理的レジスタ識別子にリネームするレジスタリネーム論理と、
   を含む処理装置。
2. 前記プレディケートレジスタスタック上の前記プレディケートレジスタの前記論理識別子はスタックの頂部識別子に対して相対的なものである、請求項１に記載の処理装置。
3. 前記実行ユニットは、前記論理識別子により示されるプレディケート値を読み出して前記プレディケート値に基づいて前記デコード済み第１命令を条件付きで実行するものである、請求項２に記載の処理装置。
4. 前記実行ユニットは、前記論理識別子により示されるプレディケート値を読み出して前記プレディケート値に基づいて前記デコード済み第１命令を条件付きでコミットするものである、請求項２に記載の処理装置。
5. 前記レジスタリネーム論理は、前記物理的レジスタ識別子を計算する算術論理ユニットと、前記スタックの頂部識別子を格納するためのスタックの頂部レジスタとを含む、請求項２から４のいずれか１項に記載の処理装置。
6. 第１命令を、第１オペランドを含むデコード済み第１命令にデコードするデコード論理と、
   プレディケートレジスタスタック上のプレディケート値にアクセスするために前記デコード済み第１命令を実行する実行ユニットと、
   前記第１オペランドに含まれる前記プレディケートレジスタスタック上のプレディケートレジスタの論理識別子を物理的レジスタ識別子にリネームするレジスタリネーム論理と、
   を含み、
   前記プレディケートレジスタスタック上の前記プレディケートレジスタの前記論理識別子はスタックの頂部識別子に対して相対的なものであり、
   前記レジスタリネーム論理は、前記物理的レジスタ識別子を計算する算術論理ユニットと、前記スタックの頂部識別子を格納するためのスタックの頂部レジスタとを含み、
   前記スタックの頂部識別子を格納するための１つまたは複数のシャドウスタックの頂部レジスタをさらに含む、処理装置。
7. 前記実行ユニットは、さらに、前記デコード済み第１命令の実行中に生成済みプレディケート値を生成して前記生成済みプレディケート値を前記プレディケートレジスタスタックへプッシュするものである、請求項１から６のいずれか１項に記載の処理装置。
8. 前記実行ユニットは、さらに、前記生成済みプレディケート値の前記プッシュの後にスタックの頂部識別子を前進させるものである、請求項７に記載の処理装置。
9. 少なくとも１つの機械により実行されると、前記少なくとも１つの機械に、
   命令を、第１オペランドを含むデコード済み第１命令にデコードすることと、
   プロセッサパイプラインのリネーミングステージよりも前に、前記第１オペランドに含まれるプレディケートレジスタスタック上のプレディケートレジスタの論理識別子を物理的レジスタ識別子にリネームすることと、
   前記プレディケートレジスタスタックから第１プレディケート値を取り出すことと、
   前記第１プレディケート値に基づいて前記デコード済み第１命令を条件付きで実行することと、
   を実行させるための、コンピュータプログラム。
10. 前記プレディケートレジスタスタックはスタックの頂部識別子を含み、前記プレディケートレジスタスタックから前記第１プレディケート値を取り出すことは前記スタックの頂部識別子からのオフセットに基づいて前記プレディケートレジスタスタックにおける論理位置を判定することを含む、請求項９に記載のコンピュータプログラム。
11. 前記少なくとも１つの機械に、
    プレディケートレジスタリネーム論理を介して前記プレディケートレジスタスタックにおける前記論理位置の物理レジスタＩＤを判定することをさらに実行させるための、請求項１０に記載のコンピュータプログラム。
12. 前記少なくとも１つの機械に、
    少なくとも部分的に第２プレディケート値に基づいて投機的分岐実行を行うことをさらに実行させるための、請求項９から１１のいずれか１項に記載のコンピュータプログラム。
13. 前記少なくとも１つの機械に、
    前記プレディケートレジスタスタック上の第３プレディケート値を読み出すことと、前記第３プレディケート値に基づいて投機的分岐実行をアボートすることとをさらに実行させるための、請求項１２に記載のコンピュータプログラム。
14. 少なくとも１つの機械により実行されると、前記少なくとも１つの機械に、
    命令を、デコード済み第１命令にデコードすることと、
    プレディケートレジスタスタックから第１プレディケート値を取り出すことと、
    前記第１プレディケート値に基づいて前記デコード済み第１命令を条件付きで実行することと、
    少なくとも部分的に第２プレディケート値に基づいて投機的分岐実行を行うことと、
    前記投機的分岐実行を行う前にスタックの頂部識別子をシャドウスタックの頂部レジスタに格納することと、を実行させるための、コンピュータプログラム。
15. 前記少なくとも１つの機械に、
    分岐投機ミスからの回復後に前記プレディケートレジスタスタックのための前記スタックの頂部識別子をシャドウスタックの頂部レジスタから復元することをさらに実行させるための、請求項１４に記載のコンピュータプログラム。
16. 請求項９から１５のいずれか１項に記載のコンピュータプログラムを格納する、コンピュータ可読記録媒体。
17. 第１オペランドを有する命令をデコード済み第１命令にデコードすることと、
    プロセッサパイプラインのリネーミングステージよりも前に、前記第１オペランドに含まれるプレディケートスタック上のプレディケートレジスタの論理識別子を物理的レジスタ識別子にリネームすることと、
    １つまたは複数のプレディケート値を含む第１オペランド値を取り出すことと、
    スタックの頂部識別子により示される前記プレディケートスタック内の位置へ前記１つまたは複数のプレディケート値をプッシュすることと、
    を含むプロセッサに実行される方法。
18. 前記第１オペランド値を前記１つまたは複数のプレディケート値にデコードすることをさらに含む、請求項１７に記載の方法。
19. 前記命令の一種であるプレディケートスタックプッシュ命令を実行する場合に、前記１つまたは複数のプレディケート値を前記プレディケートスタックにプッシュした後に、前記スタックの頂部識別子を前進させることをさらに含む、請求項１７または１８に記載の方法。
20. 第１オペランドを有する命令をデコード済み第１命令にデコードすることと、
    １つまたは複数のプレディケート値を含む第１オペランド値を取り出すことと、
    スタックの頂部識別子により示されるプレディケートスタック内の位置へ前記１つまたは複数のプレディケート値をプッシュすることと、
    前記命令の一種であるプレディケートスタックキュー命令を実行する場合に、前記１つまたは複数のプレディケート値を前記プレディケートスタックへプッシュした後に、前記スタックの頂部識別子を前進させないことと、
    を含むプロセッサに実行される方法。
21. ボトムモードにおけるプレディケートスタック同期命令を実行する場合に、当該ボトムモードにおける当該プレディケートスタック同期命令よりも前の前記プレディケートスタックキュー命令以前における前記スタックの頂部識別子の位置を指し示すように、前記スタックの頂部識別子を改変することをさらに含む、請求項２０に記載の方法。
22. トップモードにおけるプレディケートスタック同期命令を実行する場合に、当該トップモードにおける当該プレディケートスタック同期命令よりも前の前記プレディケートスタックキュー命令を実行することによりプッシュされた最後のプレディケート値を指し示すように、前記スタックの頂部識別子を改変することをさらに含む、請求項２０または２１に記載の方法。
23. 請求項１７から２２のいずれか１項に記載の方法を実行するための手段を含む処理システム。

Images