JP2017010573A - 書込マスクを用いて２つのソースオペランドを単一のデスティネーションに融合するシステム、装置及び方法 - Google Patents

Abstract

【課題】コンピュータプロセッサで融合命令を実行するシステム、装置及び方法を提供する。【解決手段】融合命令の実行は、要素のベクトルの比較の結果からの真／偽ビットを格納する１つのマスクレジスタを用い、それらのビットに基づいて、２つの特徴的なベクトルソースの要素間で選択を行う。換言すれば、融合命令の実行は、２つのソース間の要素毎の融合を、これらのソース間のセレクタとして書込マスク（ライトマスク）を用いて、プロセッサに実行させる。その結果がデスティネーションレジスタに書き込まれる。【選択図】図１

Description

本発明の分野は、概してコンピュータプロセッサアーキテクチャに関し、より具体的には、実行されるときに特定の結果を生じさせる命令に関する。

複数のベクトルソースからのデータを制御フロー情報に基づいて融合（ブレンド）することは、ベクトルベースのアーキテクチャの一般的な問題である。例えば、以下のコード：
Ｆｏｒ （ｉ＝０；ｉ＜Ｎ；ｉ＋＋）
｛
Ｃ［ｉ］＝（ａ［ｉ］＞０？ Ａ［ｉ］：Ｂ［ｉ］；
｝
をベクトル化するためには、１）ａ［ｉ］＞０が真であるかを指し示すブール代数のベクトルを生成する手法と、２）そのブール代数のベクトルに基づいて２つのソース（Ａ［ｉ］又はＢ［ｉ］）から何れかの値を選択し、その内容を異なるデスティネーション（Ｃ［ｉ］）に書き込む方法とを必要とする。

コンピュータプロセッサで融合命令を実行するシステム、装置及び方法の実施形態が開示される。

一部の実施形態において、融合命令の実行は、第１及び第２のオペランド間のセレクタとして書込マスクの対応するビット位置を用いた、第１及び第２のソースオペランドのデータ要素毎の選択と、選択されたデータ要素の、デスティネーション内の対応する位置での前記デスティネーションへの格納とを生じさせる。

融合命令の実行の一例を示す図である。 融合命令の実行の他の一例を示す図である。 融合命令の擬似コードの一例を示す図である。 プロセッサにおける融合命令の使用の一実施形態を示す図である。 融合命令を処理する方法の一実施形態を示す図である。 融合命令を処理する方法の一実施形態を示す図である。 本発明の実施形態に従った一般的なベクトルフレンドリー命令フォーマット及びそのクラスＡ命令テンプレートを例示するブロック図である。 本発明の実施形態に従った一般的なベクトルフレンドリー命令フォーマット及びそのクラスＢ命令テンプレートを例示するブロック図である。 本発明の実施形態に従った具体的なベクトルフレンドリー命令フォーマットを例示する図である。 本発明の実施形態に従った具体的なベクトルフレンドリー命令フォーマットを例示する図である。 本発明の実施形態に従った具体的なベクトルフレンドリー命令フォーマットを例示する図である。 本発明の一実施形態に従ったレジスタアーキテクチャを示すブロック図である。 本発明の実施形態に従った、シングルＣＰＵコアを、ダイ上インターコネクトネットワークへのその接続、及びそのレベル２（Ｌ２）キャッシュのサブセットとともに示すブロック図である。 本発明の実施形態に従った図１０Ａ内のＣＰＵコアの部分の分解図である。 本発明の実施形態に従ったアウト・オブ・オーダーアーキテクチャを例示するブロック図である。 本発明の一実施形態に従ったシステムを示すブロック図である。 本発明の一実施形態に従った第２のシステムを示すブロック図である。 本発明の一実施形態に従った第３のシステムを示すブロック図である。 本発明の一実施形態に従ったＳｏＣを示すブロック図である。 本発明の一実施形態に従った、集積化メモリコントローラ及びグラフィックスを備えたシングルコアプロセッサ及びマルチコアプロセッサを示すブロック図である。 本発明の実施形態に従った、ソース命令セット内のバイナリ命令をターゲット命令セット内のバイナリ命令に変換するソフトウェア命令コンバータの使用と対比するブロック図である。

以下の記載においては、数多くの具体的詳細事項が説明される。しかしながら、理解されるように、本発明の実施形態はそれらの具体的詳細事項を用いずに実施されてもよい。また、本明細書の理解を曖昧にしないよう、周知の回路、構造及び技術については詳細に示していない。

本明細書における“一実施形態”、“或る実施形態”、“一実施形態例”などへの言及は、記載される実施形態が特定の機構、構造又は特徴を含み得ることを指し示すものであるが、必ずしも全ての実施形態がその特定の機構、構造又は特徴を含むわけではない。さらに、そのような言い回しは必ずしも同じ実施形態に言及しているわけではない。また、或る特定の機構、構造又は特徴が或る実施形態に関連して説明されるとき、明示的に記載されていようといなかろうと、そのような機構、構造又は特徴を他の実施形態とともに実現することは、当業者の知識の範囲内である。

融合
以下は、一般的に“融合”と呼ばれる実施形態と、そのような命令を実行するために使用され得るシステム、アーキテクチャ、命令フォーマットなどの実施形態であり、背景技術に記載したものを含む様々な分野で有益なものである。融合命令の実行は、要素のベクトルの比較の結果からの真／偽ビットを格納する１つのマスクレジスタを用い、それらのビットに基づいて、２つの特徴的なベクトルソースの要素間で選択を行うことができるので、先述の問題の第２の部分に効率的に対処する。換言すれば、融合命令の実行は、２つのソース間の要素毎の融合を、これらのソース間のセレクタとして書込マスク（ライトマスク）を用いて、プロセッサに実行させる。その結果がデスティネーションレジスタに書き込まれる。一部の実施形態において、これらのソースのうちの少なくとも一方は、例えば１２８ビット、２５６ビット、５１２ビットのベクトルレジスタなどのレジスタである。一部の実施形態において、それらソースオペランドの少なくとも一方は、開始メモリロケーションに関連する複数のデータ要素の集合である。さらに、一部の実施形態において、一方又は双方のソースのデータ要素は、如何なる融合にも先立って、例えばスウィズル、ブロードキャスト、コンバージョンなど（ここで例を述べる）のデータ変換を経る。書込マスクレジスタの例については詳細に後述する。

この命令の典型的な１つのフォーマットは“ＶＢＬＥＮＤＰＳ ｚｍｍ１ ｛ｋ１｝，ｚｍｍ２，ｚｍｍ３／ｍ５１２，ｏｆｆｓｅｔ”であり、オペランドｚｍｍ１、ｚｍｍ２及びｚｍｍ３はベクトルレジスタ（例えば、１２８ビット、２５６ビット、５１２ビットのレジスタなど）であり、ｋ１は書込マスクオペランド（例えば、詳細に後述するもののような１６ビットレジスタなど）であり、ｍ５１２はレジスタ内に格納されるか即値（immediate）として格納されるかの何れかであるメモリオペランドである。ＺＭＭ１はデスティネーションオペランドであり、ＺＭＭ２及びＺＭＭ３／ｍ５１２はソースオペランドである。ｏｆｆｓｅｔ（オフセット）は、存在する場合、レジスタ内の値又は即値からメモリアドレスを決定するために使用される。メモリから取り出されるものは、メモリアドレスから開始する集合的な連続したビットであり、デスティネーションレジスタのサイズに応じて複数のサイズ（１２８ビット、２５６ビット、５１２ビットなど）のうちの１つとなり得る（このサイズは一般にデスティネーションレジスタと同じサイズである）。一部の実施形態において、書込マスクは異なるサイズ（８ビット、３２ビットなど）を有する。また、一部の実施形態において、詳細に後述するように、命令は書込マスクの全てではないビットを使用する。ＶＢＬＥＮＤＭＰＳは、この命令のオペコードである。典型的に、各オペランドは命令によって明示的に規定される。データ要素のサイズは、例えば後述の“Ｗ”のようなデータ粒度ビットが指し示すもの（インジケーション）を使用して、命令の“プレフィックス”内で規定され得る。殆どの実施形態において、Ｗは、各データ要素が３２ビット又は６４ビットの何れであるかを指し示すことになる。データ要素が３２ビットサイズであり、ソースが５１２ビットサイズである場合、ソース当たり１６個のデータ要素が存在する。

融合命令の実行の一例を図１に示す。この例においては、各々が１６個のデータ要素を有する２つのソースが存在している。殆どのケースにおいて、これらのソースのうちの一方はレジスタである（この例では、ソース１が、１６個の３２ビットデータ要素を有する例えばＺＭＭレジスタなどの５１２ビットレジスタとして取り扱われているが、例えばＸＭＭレジスタ及びＹＭＭレジスタと１６ビット又は６４ビットのデータ要素など、その他のサイズのデータ要素及びレジスタも使用され得る）。他方のソースは、レジスタ又はメモリロケーションの何れかである（この例においては、ソース２が他方のソースである）。第２のソースがメモリロケーションである場合、殆どの実施形態において、それは、これらのソースの融合に先立って、一時レジスタ内に置かれる。また、メモリロケーションのデータ要素は、一時レジスタ内にそれを置くことに先立って、データ変換を受けてもよい。図示したマスクパターンは０ｘ５５５５である。

この例において、値“１”を有する書込マスクの各ビット位置は、第１のソース（ソース１）の対応するデータ要素がデスティネーションレジスタの対応するデータ要素位置に書き込まれるべきであることが指し示す。従って、ソース１の１番目、３番目、５番目などのビット位置（Ａ０、Ａ２、Ａ４など）が、デスティネーションの１番目、３番目、５番目などのデータ要素位置に書き込まれる。書込マスクが値“０”を有するところでは、第２のソースのデータ要素がデスティネーションの対応するデータ要素位置に書き込まれる。当然ながら、“１”及び“０”の使用法は実装に応じて反転され得る。また、この図及び以上の説明はそれぞれの１番目の位置が最下位の位置であると見なしているが、一部の実施形態においては一番目の位置は最上位の位置である。

図２は、融合命令の実行の他の一例を示している。この図と図１との間の違いは、各ソースが８個のデータ要素のみを有していることである（例えば、これらのソースは各々が８個の６４ビットデータ要素を有する５１２ビットレジスタである）。この状況において、１６ビットの書込マスクの場合、書込マスクの全てではないビットが使用される。この例においては、融合されるべき各ソースのデータ要素は１６個もないので、最下位側のビットのみが使用されている。

図３は、融合命令の擬似コードの一例を示している。

図４は、プロセッサにおける融合命令の使用の一実施形態を示している。ステップ４０１にて、デスティネーションオペランドと、２つのソースオペランドと、オフセット（あれば）と、書込マスクとを有する融合命令がフェッチされる。一部の実施形態において、デスティネーションオペランドは５１２ビットベクトルレジスタ（例えばＺＭＭ１など）であり、書込マスクは１６ビットレジスタ（例えば、詳細に後述する“ｋ”書込マスクレジスタなど）である。これらのソースオペランドのうちの少なくとも一方はメモリソースオペランドとし得る。

ステップ４０３にて、融合命令がデコードされる。命令のフォーマットに応じて、この段階で、例えば、データ変換があるか、どのレジスタに書き込み及び取り出しを行うべきか、どのメモリアドレスにアクセスすべきかなど、多様なデータが解釈（インタープリット）され得る。

ステップ４０５にて、ソースオペランド値の取り出し／読み出しが行われる。双方のソースがレジスタである場合、それらのレジスタが読み出される。ソースオペランドの一方又は双方がメモリオペランドである場合、そのオペランドに関するデータ要素が取り出される。一部の実施形態において、メモリからのデータ要素は一時レジスタに格納される。

何らかのデータ要素変換（例えば、後述するアップコンバージョン、ブロードキャスト、スウィズルなど）が実行されるべき場合、ステップ４０７でそれが実行され得る。例えば、メモリからの１６ビットデータ要素が３２ビットデータ要素へとアップコンバーとされたり、データ要素が１つのパターンから別の１つのパターンへ（例えば、ＸＹＺＷＸＹＺＷＸＹＺＷＸＹＺＷからＸＸＸＸＸＸＸＸＹＹＹＹＹＹＹＹＺＺＺＺＺＺＺＺＷＷＷＷＷＷＷＷへ）スウィズルされたりし得る。

ステップ４０９にて、融合命令（又は、例えば複数のマイクロオペレーションなどの命令を有する処理）が、実行リソースによって実行される。この実行は、２つのソース間のセレクタとして書込マスクを用いて２つのソース間の要素毎の融合を生じさせる。例えば、第１のソースのデータ要素と、第２のソースのデータ要素とが、書込マスクの対応するビット値に基づいて選択される。このような融合の例が図１及び２に示されている。

ステップ４１１にて、ソースオペランドのこれら適切なデータ要素がデスティネーションレジスタに格納される。この例もやはり図１及び２に示されている。ステップ４０９及び４１１を別々に説明したが、一部の実施形態において、これらのステップはともに命令の実行の一部として実行される。

以上のことは、一種類の実行環境について示されているが、例えば詳述するイン・オーダー環境及びアウト・オブ・オーダー環境など、その他の環境に適合するように容易に変更され得る。

図５は、融合命令を処理する方法の一実施形態を示している。この実施形態においては、ステップ４０１−４０７のうち、全てではないが一部は前もって実行されていると仮定するが、以下にて提示する細部を不明瞭にしないよう、それらは図示していない。例えば、フェッチ及びデコードは図示しておらず、またオペランド（ソース及び書込マスク）の取り出しも図示していない。

ステップ５０１にて、書込マスクの第１のビット位置の値が評価される。例えば、書込マスクにおける値ｋ１［０］が決定される。一部の実施形態において第１のビット位置は最下位ビット位置であり、他の実施形態において第１のビット位置は最上位ビット位置である。以降の説明は、第１のビット位置が最下位であるとして説明するが、それが最上位である場合に為される変更も当業者に容易に理解されるであろう。

ステップ５０３にて、書込マスクのこのビット位置の値が、第１のソースの対応するデータ要素（第１のデータ要素）がデスティネーションの対応する位置に保存されるべきであることを指し示しているか、の決定が為される。第１のビット位置が、第１のソースの第１位置のデータ要素がデスティネーションレジスタの第１位置に格納されるべきであることを指し示している場合、ステップ５０７にて、それが格納される。図１を再び参照するに、そのマスクはこれが当てはまることを指し示しており、第１のソースの第１データ要素がデスティネーションレジスタの第１データ要素位置に格納されている。

第１のビット位置が、第１のソースの第１位置のデータ要素がデスティネーションレジスタの第１位置に格納されるべきでないことを指し示している場合、ステップ５０７で、第２のソースの第１位置のデータ要素が格納される。図１を再び参照するに、そのマスクはこれが当てはまらないことを指し示している。

ステップ５０９にて、評価された書込マスク位置が書込マスクの最後であるか、あるいはデスティネーションのデータ要素位置の全てが充たされたか、の決定が為される。そうである場合、処理は終了する。そうでない場合には、ステップ５１１にて、書込マスクの次のビット位置が評価されて、その値が決定される。

ステップ５０３にて、書込マスクのこの後続ビット位置の値が、第１のソースの対応するデータ要素（第２のデータ要素）がデスティネーションの対応する位置に保存されるべきであることを指し示しているか、の決定が為される。マスクの全ビットが使い尽くされるか、あるいはデスティネーションのデータ要素の全てが充たされるかまで、これが繰り返される。後者のケースは、例えば、データ要素サイズが６４ビットであり、デスティネーションオペランドが５１２ビットであり、且つ書込マスクが１６ビットを有するときに起こり得る。その場合、書込マスクのうちの８ビットを必要とするのみで融合命令が完了されることになる。換言すれば、使用する書込マスクのビット数は、書込マスクサイズと各ソース内のデータ要素数とに依存する。

図６は、融合命令を処理する方法の一実施形態を示している。この実施形態においては、ステップ４０１−４０７のうち、全てではないが一部はステップ６０１に先立って実行されていると仮定する。ステップ６０１にて、使用すべき書込マスクの各ビット位置について、そのビット位置の値が、第１のソースの対応するデータ要素がデスティネーションレジスタの対応する位置に保存されるべきであることを指し示しているか、の決定が為される。

第１のソースのデータ要素がデスティネーションレジスタに保存されるべきであることを指し示している書込マスクの各ビット位置について、ステップ６０５にて、それが適切な位置に書き込まれる。第２のソースのデータ要素がデスティネーションレジスタに保存されるべきであることを指し示している書込マスクの各ビット位置については、ステップ６０３にて、それが適切な位置に書き込まれる。一部の実施形態において、ステップ６０３及び６０５は並行して実行される。

図５及び６は第１のソースに基づいて決定を行うとしているが、どちらのソースが決定に使用されてもよい。また、明確に理解されるように、一方のソースのデータ要素が書き込まれないときには、他方のソースの対応するデータ要素がデスティネーションに書き込まれることになる。

インテル社のＡＶＸは、即値に基づく（ＶＢＬＥＮＤＰＳ）か、第３のベクトルソースの要素の符号ビットに基づく（ＶＢＬＥＮＤＶＰＳ）かの何れかである別バージョンのＢＬＥＮＤベクトル命令を導入している。最初のものは、融合情報が静的であるという欠点を有し、第２のものは、動的な融合情報が他のベクトルレジスタに由来することで、余分なレジスタ読み出しプレッシャー、ストレージの無駄（ブール表現に実際に有用なのは３２ビット毎に１つのみである）及び余分なオーバーヘッド（叙述情報が真データベクトルレジスタにマッピングされる必要があるため）を生じさせるという欠点を有する。ＶＢＬＥＮＤＭＰＳは、真（トゥルー）マスクレジスタに格納される叙述（プレディクション）情報を用いて２つのソースからの値を融合するという概念を導入するものである。これは以下の利点を有する：可変的な融合を可能にし、減結合された算術的な叙述ロジックコンポーネント（計算はベクトル上で実行され、叙述はマスク上で実行され、マスクを用いて算術データが制御フロー情報に基づいて融合される）を用いた融合を可能にし、ベクトルレジスタファイル上での読み出しプレッシャーを軽減し（マスク読み出しは安価であり、且つ分離されたレジスタファイル上である）、且つ無駄なストレージを回避する（実際には要素当たり３２ビット／６４ビットのうち１ビットのみが必要なので、ブール代数をベクトルで格納することは非常に非効率的である）。

以上にて詳述した命令の実施形態は、以下に詳述する“一般的ベクトルフレンドリー命令フォーマット”にて具現化され得る。他の実施形態においては、そのようなフォーマットは使用されずに別の命令フォーマットが使用されるが、書込マスクレジスタ、様々なデータ変換（スウィズル、ブロードキャストなど）、アドレシングなどの以下の説明は、一般的に、上述の命令の実施形態の説明に適用可能である。また、典型的なシステム、アーキテクチャ及びパイプラインを以下にて説明する。上述の命令の実施形態は、そのようなシステム、アーキテクチャ及びパイプライン上で実行され得るが、詳述するものに限定されない。

ベクトルフレンドリー命令フォーマットとは、ベクトル命令に適した命令フォーマットである（例えば、ベクトル演算に特有の特定のフィールドが存在する）。ベクトルフレンドリー命令フォーマットを介してベクトル演算とスカラー演算との双方がサポートされる実施形態を説明するが、他の実施形態はベクトルフレンドリー命令フォーマットを介してベクトル演算のみを使用する。

典型的な一般的ベクトルフレンドリー命令フォーマット ― 図７Ａ−７Ｂ
図７Ａ−７Ｂは、本発明の実施形態に従った一般的ベクトルフレンドリー命令フォーマット及びその命令テンプレートを例示するブロック図である。図７Ａは、本発明の実施形態に従った一般的ベクトルフレンドリー命令フォーマット及びそのクラスＡ命令テンプレートを例示するブロック図であり、図７Ｂは、本発明の実施形態に従った一般的ベクトルフレンドリー命令フォーマット及びそのクラスＢ命令テンプレートを例示するブロック図である。具体的には、どちらもノーメモリアクセス７０５命令テンプレートとメモリアクセス７２０命令テンプレートとを含むクラスＡ命令テンプレート及びクラスＢ命令テンプレートが規定される一般的ベクトルフレンドリー命令フォーマット７００が示されている。ベクトルフレンドリー命令フォーマットの文脈における一般的なる用語は、特定の命令セットに結び付けられていない命令フォーマットを意味する。ベクトルフレンドリー命令フォーマットの命令がレジスタ（ノーメモリアクセス７０５命令テンプレート）又はレジスタ／メモリ（メモリアクセス７２０命令テンプレート）の何れかをソースとするベクトル上で動作する実施形態を説明するが、本発明の他の実施形態は、これらの一方のみをサポートしてもよい。また、ベクトル命令フォーマットのロード・格納命令が存在する本発明の実施形態を説明するが、他の実施形態は、それに代えて、あるいは加えて、ベクトルをレジスタの内／外に（例えば、メモリからレジスタに、レジスタからメモリに、レジスタ間で）移動させる異なる命令フォーマットの命令を有する。さらに、２つのクラスの命令テンプレートをサポートする本発明の実施形態を説明するが、他の実施形態はこれらのうちの一方のみ、又は３つ以上をサポートしてもよい。

ベクトルフレンドリー命令フォーマットが以下：３２ビット（４バイト）若しくは６４ビット（８バイト）のデータ要素幅（すなわちサイズ）を有する６４バイトのベクトルオペランド長（すなわちサイズ）（故に、６４バイトのベクトルは１６個の２倍長ワードサイズの要素若しくは８個の４倍長ワードサイズの要素で構成される）；１６ビット（２バイト）若しくは８ビット（１バイト）のデータ要素幅（すなわちサイズ）を有する６４バイトのベクトルオペランド長（すなわちサイズ）；３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）若しくは８ビット（１バイト）のデータ要素幅（すなわちサイズ）を有する３２バイトのベクトルオペランド長（すなわちサイズ）；及び３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）若しくは８ビット（１バイト）のデータ要素幅（すなわちサイズ）を有する１６バイトのベクトルオペランド長（すなわちサイズ）、をサポートする本発明の実施形態を説明するが、他の実施形態は、より大きい、小さい、あるいは異なるデータ要素幅（例えば、１２８ビット（１６バイト）データ要素幅）を有した、より大きい、小さい、且つ／或いは異なるベクトルオペランドサイズ（例えば、２５６バイトのベクトルオペランド）をサポートしてもよい。

図７ＡのクラスＡ命令テンプレートは：１）ノーメモリアクセス７０５命令テンプレート内に示された、メモリアクセスなしフルラウンド制御型演算７１０命令テンプレートと、メモリアクセスなしデータ変換型演算７１５命令テンプレート；及び２）メモリアクセス７２０命令テンプレート内に示された、メモリアクセスありテンポラル７２５命令テンプレートと、メモリアクセスあり非テンポラル７３０命令テンプレート、を含んでいる。図７ＢのクラスＢ命令テンプレートは：１）ノーメモリアクセス７０５命令テンプレート内に示された、メモリアクセスなし書込マスク制御パーシャルラウンド制御型演算７１２命令テンプレートと、メモリアクセスなし書込マスク制御ｖサイズ（ｖｓｉｚｅ）型演算７１７命令テンプレート；及び２）メモリアクセス７２０命令テンプレート内に示された、メモリアクセスあり書込マスク制御７２７命令テンプレート、を含んでいる。

フォーマット
一般的ベクトルフレンドリー命令フォーマット７００は、図７Ａ−７Ｂに例示した順に以下のフィールドを含む。

フォーマットフィールド７４０ ― このフィールド内の具体値（命令フォーマット識別値）は、ベクトルフレンドリー命令フォーマット、ひいては、命令ストリーム内でのベクトルフレンドリー命令フォーマットの命令の出現を一意的に識別する。故に、フォーマットフィールド７４０のコンテンツは、第１の命令フォーマットの命令の出現を、他の命令フォーマットの命令の出現から区別し、それにより、他の命令フォーマットを有する命令セット内にベクトルフレンドリー命令フォーマットを導入することを可能にする。従って、このフィールドは、一般的ベクトルフレンドリー命令フォーマットのみを有する命令セットには必要とされないという意味で、オプション的なものである。

基本演算フィールド７４２ ― このフィールドのコンテンツは相異なる基本演算を区別する。後述するように、基本演算フィールド７４２は、オペコードフィールドを含んでいてもよいし、オペコードフィールドの一部であってもよい。

レジスタインデックスフィールド７４４ ― このフィールドのコンテンツは、直接的に、あるいはアドレス生成を介して、レジスタ内又はメモリ内であるソースオペランド及びデスティネーションオペランドの位置を指定する。これらは、ＰｘＱ（例えば、３２ｘ５１２）レジスタファイルからＮ個のレジスタを選択するのに十分なビット数を含む。一実施形態において、Ｎは最大で３つのソースレジスタ及び１つのデスティネーションレジスタであるが、他の実施形態は、より多くの、あるいは、より少ないソース及びデスティネーションのレジスタをサポートしてもよい（例えば、最大で２つのソースをサポートし、これらソースのうちの１つがデスティネーションとしても機能してもよく、最大で３つのソースをサポートし、これらソースのうちの１つがデスティネーションとしても機能してもよく、最大で２つのソースと１つのデスティネーションとをサポートしてもよい）。一実施形態においてＰ＝３２であるが、他の実施形態は、より多くの、あるいは、より少ないレジスタ（例えば、１６）をサポートしてもよい。一実施形態においてＱ＝５１２ビットであるが、他の実施形態は、より多くの、あるいは、より少ないビット（例えば、１２８、１０２４）をサポートしてもよい。

モディファイア（modifier）フィールド７４６ ― このフィールドのコンテンツは、メモリアクセスを指定する一般的ベクトル命令フォーマットの命令の出現を、メモリアクセスを指定しないものから区別し、すなわち、ノーメモリアクセス７０５命令テンプレートとメモリアクセス７２０命令テンプレートとの間で区別する。メモリアクセス演算は、（レジスタ内の値を用いてソースアドレス及び／又はデスティネーションアドレスを指定する一部のケースにおいて）メモリ階層への読出し及び／又は書込みを行うが、非メモリアクセス演算はそうではない（例えば、ソース及びデスティネーションがレジスタである）。一実施形態において、このフィールドはまた、メモリアドレス計算を実行するための３つの手法間での選択を行うが、他の実施形態は、メモリアドレス計算を実行するための、より多くの、より少ない、あるいは異なる手法をサポートしてもよい。

増補（augmentation）演算フィールド７５０ ― このフィールドのコンテンツは、多様な異なる演算のうちの何れのものが基本演算に加えて実行されるべきかを識別する。このフィールドはコンテキストスペシフィックである。本発明の一実施形態において、このフィールドは、クラスフィールド７６８と、アルファフィールド７５２と、ベータフィールド７５４とに分割される。増補演算フィールドは、共通グループの複数の演算を、２つ、３つ又は４つといった命令ではなく、単一の命令にて実行することを可能にする。下の表は、必要な命令の数を削減するために増補フィールド７５０を使用する命令群（その命名については、より詳細に後述する）の幾つかの例を示している。

ここで、［ｒａｘ］は、アドレス生成に使用されるベースポインタであり、｛｝はデータ操作フィールド（更に詳細に後述する）によって指定される変換演算を指し示す。

スケール（ｓｃａｌｅ）フィールド７６０ ― このフィールドのコンテンツは、メモリアドレス生成のため（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅを使用するアドレス生成のため）のインデックスフィールドのコンテンツのスケーリングを可能にする。

変位（ｄｉｓｐｌａｃｅｍｅｎｔ）フィールド７６２Ａ ― このフィールドのコンテンツは、メモリアドレス生成の一部として使用される（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅ＋ｄｉｓｐｌａｃｅｍｅｎｔを使用するアドレス生成のため）。

変位係数フィールド７６２Ｂ（なお、変位係数フィールド７６２Ｂの真上に変位フィールド７６２Ａが並置されていることは、一方又は他方が使用されることを指し示す） ― このフィールドのコンテンツは、アドレス生成の一部として使用され、メモリアクセスにおけるバイト数をＮとして、メモリアクセス（Ｎ）のサイズによってスケーリングされる変位係数を指定する（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅ＋スケーリングされたｄｉｓｐｌａｃｅｍｅｎｔを使用するアドレス生成のため）。冗長な低次ビットは無視され、故に、変位係数フィールドのコンテンツにメモリオペランドのトータルサイズ（Ｎ）が乗算されて、実際のアドレスを計算する際に使用される最終的な変位が生成される。Ｎの値は、実行時に、フルオペコードフィールド７７４（後述）とデータ操作フィールド７５４Ｃ（後述）とに基づいて、プロセッサハードウェアによって決定される。変位フィールド７６２Ａ及び変位係数フィールド７６２Ｂは、ノーメモリアクセス７０５命令テンプレートでは使用されず、且つ／或いは他の実施形態はこれら２つのうちの一方のみを実装したり何れをも実装しなかったりし得る、という意味で、変位フィールド７６２Ａ及び変位係数フィールド７６２Ｂはオプション的なものである。

データ要素幅フィールド７６４ ― このフィールドのコンテンツは、数多くある要素幅のうちの何れが使用されるかを識別する（一部の実施形態においては全ての命令についてであり、他の実施形態においては一部の命令についてのみである）このフィールドは、１つのデータ要素幅のみがサポートされ、且つ／或いはデータ要素幅がオペコードの何らかの側面によってサポートされる場合には必要とされないという意味で、オプション的なものである。

書込マスクフィールド７７０ ― このフィールドのコンテンツは、データ要素位置毎を基礎にして、デスティネーションベクトルオペランド内のそのデータ要素位置が基本演算及び増補演算の結果を反映するか制御する。クラスＡ命令テンプレートは融合化書込マスキングをサポートし、クラスＢ命令テンプレートは融合化及びゼロ化の双方の書込マスキングをサポートする。融合化のとき、ベクトルマスクは、デスティネーション内の要素の組（要素セット）を（基本演算及び増補演算によって指定される）演算の実行中に更新から保護することを可能にし、他の一実施形態において、対応するマスクビットが０を有するところのデスティネーションの各要素の古い値を保存する。対照的に、ゼロ化のとき、ベクトルマスクは、デスティネーション内の要素の組を（基本演算及び増補演算によって指定される）演算の実行中にゼロ化することを可能にし、一実施形態において、対応するマスクビットが値０を有するとき、デスティネーションの要素が０に設定される。この機能のサブセットは、実行されている演算のベクトル長（すなわち、最初のものから最後のものまで、変更されている要素のスパン）を制御する能力である。しかし、変更される要素が連続していることは必要ない。故に、書込マスクフィールド７７０は、ロード、格納、算術、論理などを含め、部分的なベクトル演算を可能にする。また、このマスキングは、誤り抑圧（フォールトサプレッション）に使用されることができる（すなわち、誤りを生じるかもしれない、あるいは生じることになる演算の結果を受け取ることを防止するよう、デスティネーションのデータ要素位置をマスキングすることにより、例えば、メモリ内のベクトルがページ境界を跨ぎ、第２ページはそうではないが第１ページがページ誤りを生じさせると仮定すると、第１ページ上にあるベクトルのデータ要素の全てが書込マスクによってマスクされる場合には、そのページ誤りを無視することができる）。また、書込マスクは、特定種類の条件文を含む“ベクトル化ループ”を可能にする。書込マスクフィールド７７０のコンテンツが、多数の書込マスクレジスタのうち使用する書込マスクを含むものを選択する（故に、書込マスクフィールド７７０のコンテンツが間接的に、実行されるマスキングを特定する）本発明の実施形態が説明されるが、他の実施形態は、それに代えて、あるいは加えて、書込マスクフィールド７７０のコンテンツが直接的に、実行されるマスキングを指定することを可能にする。また、ゼロ化は：１）それが有するデスティネーションオペランドがソースでもある命令（非３変数命令とも呼ぶ）でない命令上でレジスタリネーミングが使用されるとき、レジスタリネーミングパイプラインステージにおいてデスティネーションはもはや暗示的なソースでない（演算の結果でないデータ要素（マスクされたデータ要素）はゼロ化されることになるので、現在のデスティネーションレジスタからの如何なるデータ要素も、リネーミング後のデスティネーションレジスタに複製されたり、演算とともに何らかのかたちで運ばれたりする必要がない）ので；及び２）ライトバック段階において、ゼロが書き込まれているので；性能向上を可能にする。

即値フィールド７７２ ― このフィールドのコンテンツは即値を詳述することを可能にする。このフィールドは、即値をサポートしない一般的ベクトルフレンドリー命令フォーマットの実装には存在せず、また、即値を使用しない命令には存在しないという意味で、オプション的なものである。

命令テンプレートクラス選択
クラスフィールド７６８ ― このフィールドのコンテンツは、異なるクラスの命令間で区別を行う。図７Ａ−７Ｂを参照するに、このフィールドのコンテンツは、クラスＡ命令とクラスＢ命令との間で選択を行う。図７Ａ−７Ｂでは、フィールド内に特定の値が存在することを指し示すために、角を丸めた四角を使用している（例えば、図７Ａ−７Ｂそれぞれのクラスフィールド７６８のクラスＡ ７６８Ａ及びクラスＢ ７６８Ｂ）。

クラスＡのノーメモリアクセス命令テンプレート
クラスＡのノーメモリアクセス７０５命令テンプレートの場合、アルファフィールド７５２はＲＳフィールド７５２Ａとして解釈され、そのコンテンツが、様々な増補演算種類のうちのどれが実行されるべきかを識別し（例えば、メモリアクセスなしラウンド型演算７１０命令テンプレート及びメモリアクセスなしデータ変換型演算７１５命令テンプレートに対して、それぞれ、ラウンド７５２Ａ．１及びデータ変換７５２Ａ．２が指定される）、ベータフィールド７５４は、指定された種類の演算のうちのどれが実行されるべきかを識別する。図７において、角を丸めたブロックは、特定の値が存在することを指し示すために使用されている（例えば、モディファイアフィールド７４６内のメモリアクセスなし７４６Ａ；アルファフィールド７５２／ｒｓフィールド７５２Ａ内のラウンド７５２Ａ．１及びデータ変換７５２Ａ．２）。ノーメモリアクセス７０５命令テンプレートには、スケールフィールド７６０、変位フィールド７６２Ａ及び変位係数フィールド７６２Ｂは存在しない。

ノーメモリアクセス命令テンプレート ― フルラウンド制御型演算
メモリアクセスなしフルラウンド制御型演算７１０命令テンプレートにおいて、ベータフィールド７５４はラウンド制御フィールド７５４Ａとして解釈され、そのコンテンツは静的ラウンディングを提供する。本発明の記載の実施形態において、ラウンド制御フィールド７５４Ａは抑圧全浮動小数点例外（suppress all floating point exceptions；ＳＡＥ）フィールド７５６とラウンド演算制御フィールド７５８とを含んでいるが、他の実施形態は、これらの概念の双方を同一フィールドにエンコードしたり、これらの概念／フィールドの一方若しくは他方のみを有したりしてもよい（例えば、ラウンド演算制御フィールド７５８のみを有し得る）。

ＳＡＥフィールド７５６ ― このフィールドのコンテンツは、例外イベント報告を無効にすべきか否かを識別し、ＳＡＥフィールド７５６のコンテンツが、抑圧が有効にされることを指し示すとき、所与の命令は如何なる種類の浮動小数点例外フラグをも報告せず、如何なる浮動小数点例外ハンドラをも呼び出さない。

ラウンド演算制御フィールド７５８ ― このフィールドのコンテンツは、一群の丸め演算（例えば、切り上げ、切り下げ、ゼロ方向への丸め、及び最も近いものへの丸め）のうちの何れを実行すべきかを識別する。故に、ラウンド演算制御フィールド７５８は、命令毎を基礎にした丸めモードの変更を可能にし、故に、それが要求されるときに特に有用である。丸めモードを指定するための制御レジスタをプロセッサが含む本発明の一実施形態において、ラウンド演算制御フィールド７５８のコンテンツはそのレジスタ値を無効にする（そのような制御レジスタ上でセーブ−モディファイ−リストアを実行する必要なく丸めモードを選択可能なことは有利である）。

ノーメモリアクセス命令テンプレート ― データ変換型演算
メモリアクセスなしデータ変換型演算７１５命令テンプレートにおいて、ベータフィールド７５４はデータ変換フィールド７５４Ｂとして解釈され、そのコンテンツは、数多くのデータ変換（例えば、データ変換なし、スウィズル、ブロードキャスト）のうちの何れが実行されるべきかを識別する。

クラスＡのメモリアクセス命令テンプレート
クラスＡのメモリアクセス７２０命令テンプレートにおいて、アルファフィールド７５２は退去ヒント（eviction hint；ＥＨ）フィールド７５２Ｂとして解釈され、そのコンテンツは、複数の退去ヒントのうちの何れが使用されるべきかを識別し（図７Ａでは、メモリアクセスありテンポラル７２５命令テンプレート及びメモリアクセスあり非テンポラル７３０命令テンプレートに対して、それぞれ、テンポラル７５２Ｂ．１及び非テンポラル７５２Ｂ．２が指定されている）、ベータフィールド７５４はデータ操作フィールド７５４Ｃとして解釈され、そのコンテンツは、数多くのデータ操作演算（プリミティブとしても知られる）（例えば、操作なし、ブロードキャスト、ソースのアップコンバージョン、及びデスティネーションのダウンコンバージョン）のうちの何れが実行されるべきかを識別する。メモリアクセス７２０命令テンプレートは、スケールフィールド７６０を含むとともに、必要に応じて変位フィールド７６２Ａ又は変位スケールフィールド７６２Ｂを含む。

ベクトルメモリ命令は、コンバージョンサポートを用いて、メモリからのベクトルのロード及びメモリへのベクトルの格納を実行する。通常のベクトル命令と同様に、ベクトルメモリ命令は、データ要素的にメモリから／へデータを転送し、実際に転送される要素は、書込マスクとして選択されるベクトルマスクのコンテンツによって指示される。図７Ａにおいて、角を丸めた四角は、フィールド内に特定の値が存在することを指し示すために使用されている（例えば、モディファイアフィールド７４６のメモリアクセス７４６Ｂ；アルファフィールド７５２／退去ヒントフィールド７５２Ｂのテンポラル７５２Ｂ．１及び非テンポラル７５２Ｂ．２）。

メモリアクセス命令テンプレート ― テンポラル
テンポラルデータとは、キャッシュすることの恩恵を受けるのに十分な早期に再使用されそうなデータである。これはヒントであるが、異なるプロセッサは、ヒントを完全に無視することを含めて、それを異なるように実装してもよい。

メモリアクセス命令テンプレート ― 非テンポラル
非テンポラルデータとは、第１レベルキャッシュでキャッシュすることの恩恵を受けるのに十分な早期に再使用されそうになく、退去の優先度を与えられるべきデータである。これはヒントであるが、異なるプロセッサは、ヒントを完全に無視することを含めて、それを異なるように実装してもよい。

クラスＢの命令テンプレート
クラスＢの命令テンプレートの場合、アルファフィールド７５２は書込マスク制御（Ｚ）フィールド７５２Ｃとして解釈され、そのコンテンツは、書込マスクフィールド７７０によって制御される書込マスキングが融合化又はゼロ化の何れであるかを識別する。

クラスＢのノーメモリアクセス命令テンプレート
クラスＢのノーメモリアクセス７０５命令テンプレートの場合、ベータフィールド７５４の一部はＲＬフィールド７５７Ａとして解釈され、そのコンテンツは、様々な増補演算種類のうちの何れが実行されるべきかを識別し（例えば、メモリアクセスなし書込マスク制御パーシャルラウンド制御型演算７１２命令テンプレート、及びメモリアクセスなし書込マスク制御ＶＳＩＺＥ型演算７１７命令テンプレートに対して、それぞれ、ラウンド７５７Ａ．１、及びベクトル長（ＶＳＩＺＥ）７５７Ａ．２が指定される）、ベータフィールド７５４の残部は、指定された種類の複数の演算のうちの何れが実行されるべきかを識別する。図７において、角を丸めたブロックは、特定の値が存在することを指し示すために使用されている（例えば、モディファイアフィールド７４６内のメモリアクセスなし７４６Ａ；ＲＬフィールド７５７Ａのラウンド７５７Ａ．１及びＶＳＩＺＥ７５７Ａ．２）。ノーメモリアクセス７０５命令テンプレートには、スケールフィールド７６０、変位フィールド７６２Ａ及び変位スケールフィールド７６２Ｂは存在しない。

ノーメモリアクセス命令テンプレート ― 書込マスク制御パーシャルラウンド制御型演算
メモリアクセスなし書込マスク制御パーシャルラウンド制御型演算７１２命令テンプレートにおいて、ベータフィールド７５４の前記残部はラウンド演算フィールド７５９Ａとして解釈され、且つ例外イベント報告が無効にされる（所与の命令は、如何なる種類の浮動小数点例外フラグをも報告せず、如何なる浮動小数点例外ハンドラをも呼び出さない）。

ラウンド演算制御フィールド７５９Ａ ― ラウンド演算制御フィールド７５８と同じように、このフィールドのコンテンツは、一群の丸め演算（例えば、切り上げ、切り下げ、ゼロ方向への丸め、及び最も近いものへの丸め）のうちの何れを実行すべきかを識別する。故に、ラウンド演算制御フィールド７５９Ａは、命令毎を基礎にした丸めモードの変更を可能にし、故に、それが要求されるときに特に有用である。丸めモードを指定するための制御レジスタをプロセッサが含む本発明の一実施形態において、ラウンド演算制御フィールド７５９Ａのコンテンツはそのレジスタ値を無効にする（そのような制御レジスタ上でセーブ−モディファイ−リストアを実行する必要なく丸めモードを選択可能なことは有利である）。

ノーメモリアクセス命令テンプレート ― 書込マスク制御ＶＳＩＺＥ型演算
メモリアクセスなし書込マスク制御ＶＳＩＺＥ型演算７１７命令テンプレートにおいて、ベータフィールド７５４の前記残部はベクトル長フィールド７５９Ｂとして解釈され、そのコンテンツは、数多くのデータベクトル長変換（例えば、１２８バイト、２５６バイト、又は５１２バイト）のうちの何れが実行されるべきかを識別する。

クラスＢのメモリアクセス命令テンプレート
クラスＢのメモリアクセス７２０命令テンプレートの場合、ベータフィールド７５４の一部はブロードキャストフィールド７５７Ｂとして解釈され、そのコンテンツは、ブロードキャスト型データ操作演算が実行されるべきか否かを識別し、ベータフィールド７５４の残部はベクトル長フィールド７５９Ｂとして解釈される。メモリアクセス７２０命令テンプレートは、スケールフィールド７６０を含むとともに、必要に応じて変位フィールド７６２Ａ又は変位スケールフィールド７６２Ｂを含む。

フィールドに関する付言
一般的ベクトルフレンドリー命令フォーマット７００に関し、フォーマットフィールド７４０と、基本演算フィールド７４２と、データ要素幅フィールド７６４とを含むフルオペフィールド７７４が示されている。フルオペコードフィールド７７４がこれらのフィールドの全てを含む一実施形態を示したが、フルオペコードフィールド７７４は、これらのフィールドの全てをサポートしない実施形態において、これらのフィールドの全てより少ないフィールドを含む。フルオペコードフィールド７７４はオペレーションコードを提供する。

増補演算フィールド７５０、データ要素幅フィールド７６４、及び書込マスクフィールド７７０は、これらの特徴が、一般的ベクトルフレンドリー命令フォーマットにて、命令毎を基礎として指定されることを可能にする。

書込マスクフィールドとデータ要素幅フィールドとの組合せは、異なるデータ要素幅に基づいてマスクを適用することを可能にするタイプの命令を作り出す。

この命令フォーマットは、異なる目的の異なるフィールドを他のフィールドのコンテンツに基づいて再利用するので、比較的少ない数のビットを必要とする。例えば、１つの見方は、モディファイアフィールドのコンテンツが図７Ａ−７Ｂのノーメモリアクセス７０５命令テンプレートと図７Ａ−７Ｂのメモリアクセス７２０命令テンプレートとの間で選択を行い、クラスフィールド７６８のコンテンツが、図７Ａの命令テンプレート７１０／７１５と図７Ｂの命令テンプレート７１２／７１７との間で、ノーメモリアクセス７０５命令テンプレート内での選択を行い、また、クラスフィールド７６８のコンテンツが、図７Ａの命令テンプレート７２５／７３０と図７Ｂの命令テンプレート７２７との間で、メモリアクセス７２０命令テンプレート内での選択を行う、というものである。別の見方からは、クラスフィールド７６８のコンテンツが、図７Ａ及び７ＢそれぞれのクラスＡ命令テンプレートとクラスＢ命令テンプレートとの間での選択を行い、モディファイアフィールドのコンテンツが、図７Ａの命令テンプレート７０５と７２０との間で、クラスＡ命令テンプレート内での選択を行い、また、モディファイアフィールドのコンテンツが、図７Ｂの命令テンプレート７０５と７２０との間で、クラスＢ命令テンプレート内での選択を行う。クラスフィールドのコンテンツがクラスＡ命令テンプレートを指し示す場合、モディファイアフィールドのコンテンツが（ｒｓフィールド７５２ＡとＥＨフィールド７５２Ｂとの間で）アルファフィールド７５２の解釈を選択する。関連した手法において、モディファイアフィールド７４６及びクラスフィールド７６８のコンテンツが、アルファフィールドがｒｓフィールド７５２Ａ、ＥＨフィールド７５２Ｂ又は書込マスク制御（Ｚ）フィールド７５２Ｃの何れであるかを選択する。クラスフィールド及びモディファイアフィールドがクラスＡのノーメモリアクセス命令を指し示す場合、増補演算フィールドのベータフィールドの解釈はｒｓフィールドのコンテンツに基づいて変化し、クラスフィールド及びモディファイアフィールドがクラスＢのノーメモリアクセス命令を指し示す場合、ベータフィールドの解釈はＲＬフィールドのコンテンツに依存する。クラスフィールド及びモディファイアフィールドがクラスＡのメモリアクセス命令を指し示す場合、増補演算フィールドのベータフィールドの解釈は基本演算フィールドのコンテンツに基づいて変化し、クラスフィールド及びモディファイアフィールドがクラスＢのメモリアクセス命令を指し示す場合、増補演算フィールドのベータフィールドのブロードキャストフィールド７５７Ｂの解釈は、基本演算フィールドのコンテンツに基づいて変化する。故に、基本演算フィールド、モディファイアフィールド及び増補演算フィールドの組合せは、更に多様な増補演算が指定されることを可能にする。

クラスＡ及びクラスＢ内に見出される様々な命令テンプレートは、様々な状況で有益である。クラスＡは、性能上の理由によりゼロ化書込マスキング又は小さいベクトル長が望まれるときに有用である。例えば、ゼロ化は、リネーミングが使用されるとき、我々が人為的にデスティネーションと融合することはもはや必要ないで、偽の依存性を回避することを可能する。他の一例として、ベクトル長制御は、ベクトルマスクを用いて、より短いベクトルサイズを競うとき、格納−ロード転送問題を容易にする。クラスＢは、１）丸めモード制御を同時に用いながら浮動小数点例外を可能にする（すなわち、ＳＡＥフィールドのコンテンツがｎｏ（ノー）を指し示すとき）こと；２）アップコンバージョン、スウィズル、スワップ及び／又はダウンコンバージョンを使用できること；３）グラフィックデータタイプ上で動作すること；が望ましいときに有用である。例えば、アップコンバージョン、スウィズル、スワップ、ダウンコンバージョン、及びグラフィックデータタイプは、異なるフォーマットのソースと協働するときに必要な命令数を削減し、他の一例として、例外を可能にできることは、指示される丸めモードとの完全なるＩＥＥＥ準拠を提供する。

典型的な具体的ベクトルフレンドリー命令フォーマット
図８Ａ−８Ｃは、本発明の実施形態に従った具体的なベクトルフレンドリー命令フォーマットを例示している。図８Ａ−８Ｃは、フィールドの位置、サイズ、解釈及び順序と、それらのフィールドの一部の値とを詳述しているという意味で具体的なベクトルフレンドリー命令フォーマット８００を示している。具体的なベクトルフレンドリー命令フォーマット８００は、ｘ８６命令セットを拡張するために使用されることができ、故に、フィールドの一部は既存のｘ８６命令セット及びそのエクステンション（例えば、ＡＶＸ）で使用されているものと同様あるいは同じである。このフォーマットは、拡張を有する既存のｘ８６命令セットのプレフィックスエンコーディングフィールド、リアルオペコードバイトフィールド、ＭＯＤ Ｒ／Ｍフィールド、ＳＩＢフィールド、変位フィールド及び即値フィールドと一貫性を有するままである。図８Ａ−８Ｃからのフィールドがマッピングされる図７からのフィールドが例示される。

理解されるように、例示目的で一般的ベクトルフレンドリー命令フォーマット７００の文脈にて具体的なベクトルフレンドリー命令フォーマット８００を参照して本発明の実施形態を説明するが、本発明は、請求項に記載されるところを除いて、この具体的なベクトルフレンドリー命令フォーマット８００に限定されるものではない。例えば、一般的ベクトルフレンドリー命令フォーマット７００は様々なフィールドに多様な可能性あるサイズを企図するものであるが、具体的なベクトルフレンドリー命令フォーマット８００は特定のサイズのフィールドを有するものとして示される。具体例として、データ要素幅フィールド７６４は具体的なベクトルフレンドリー命令フォーマット８００においては１ビットのフィールドとして示されるが、本発明はそのように限定されるものではない（すなわち、一般的ベクトルフレンドリー命令フォーマット７００はその他のサイズのデータ要素幅フィールド７６４をも企図するものである）。

フォーマット ― 図８Ａ−８Ｃ
一般的ベクトルフレンドリー命令フォーマット７００は、図８Ａ−８Ｃに例示する順序にて以下のフィールドを含む。

ＥＶＥＸプレフィックス８０２（バイト０−３）
ＥＶＥＸプレフィックス８０２は４バイトの形態でエンコードされる。

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

２−４番目のバイト（ＥＶＥＸバイト１−３）は、特定の能力を提供する多数のビットフィールドを含んでいる。

ＲＥＸ８０５（ＥＶＥＸバイト１、ビット［７：５］）は、ＥＶＥＸ．Ｒビットフィールド（ＥＶＥＸバイト１、ビット［７］−Ｒ）、ＥＶＥＸ．Ｘビットフィールド（ＥＶＥＸバイト１、ビット［６］−Ｘ）、及びＥＶＥＸ．Ｂビットフィールド（ＥＶＥＸバイト１、ビット［５］−Ｂ）からなる。これらＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ、及びＥＶＥＸ．Ｂビットフィールドは、対応するＶＥＸビットフィールドと同じ機能を提供し、１ｓ相補形態を用いてエンコードされる。すなわち、ＺＭＭ０は１１１１Ｂとしてエンコードされ、ＺＭＭ１５は０００Ｂとしてエンコードされる。命令のその他のフィールドは、技術的に知られたレジスタインデックスの下位側の３ビット（ｒｒｒ、ｘｘｘ及びｂｂｂ）をエンコードし、故に、ＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ、及びＥＶＥＸ．Ｂを追加することによってＲｒｒｒ、Ｘｘｘｘ及びＢｂｂｂが形成され得る。

ＲＥＸ’フィールド８１０ − これはＲＥＸ’フィールド８１０の最初の部分であり、拡張３２レジスタセットの上位１６又は下位１６の何れかをエンコードするために使用されるＥＶＥＸ．Ｒ’ビットフィールド（ＥＶＥＸバイト１、ビット［４］−Ｒ’）である。本発明の一実施形態において、このビットは、以下に示すその他のビットとともにビット反転形態で格納されて、（周知のｘ８６ ３２ビットモードにおいて）そのリアルオペコードバイトが６２であるＢＯＵＮＤ命令から区別されるが、ＭＯＤ Ｒ／Ｍフィールド（後述）内にＭＯＤフィールドの１１の値を受け入れない。本発明の他の実施形態は、このビット、及び以下に示すその他のビットを反転形態では格納しない。下位１６レジスタをエンコードするために１の値が使用される。換言すれば、ＥＶＥＸ．Ｒ’、ＥＶＥＸ．Ｒ、及びその他のフィールドからのその他のＲＲＲを結合することによって、Ｒ’Ｒｒｒｒが形成される。

オペコードマップ８１５（ＥＶＥＸバイト１、ビット［３：０］−ｍｍｍｍ） ― このフィールドのコンテンツは、暗黙のリーディングオペコードバイト（０Ｆ、０Ｆ３８、又は０Ｆ３）をエンコードする。

データ要素幅フィールド７６４（ＥＶＥＸバイト２、ビット［７］−Ｗ） ― これはＥＶＥＸ．Ｗなる表記によって表される。ＥＶＥＸ．Ｗはデータタイプの粒度（サイズ）を定義するために使用される（３２ビットデータ要素又は６４ビットデータ要素の何れか）。

ＥＶＥＸ．ｖｖｖｖ８２０（ＥＶＥＸバイト２、ビット［６：３］−ｖｖｖｖ） ― ＥＶＥＸ．ｖｖｖｖの役割は、以下を含み得る：１）ＥＶＥＸ．ｖｖｖｖは、反転（１ｓ相補）形態で指定される第１のソースレジスタオペランドをエンコードし、２つ以上のソースオペランドを有する命令に有効である；２）ＥＶＥＸ．ｖｖｖｖは特定のベクトルシフトに関して１ｓ相補形態で指定されるデスティネーションレジスタオペランドをエンコードする；あるいは３）ＥＶＥＸ．ｖｖｖｖは如何なるオペランドをもエンコードせず、このフィールドはリザーブされて１１１１ｂを格納する。故に、ＥＶＥＸ．ｖｖｖｖフィールド８２０は、反転（１ｓ相補）形態で格納される第１のソースレジスタスペシファイアの４つの低次ビットをエンコードする。命令に依存して、スペシファイアサイズを３２レジスタまで拡張するために追加の異なるＥＶＥＸビットフィールドが使用される。

ＥＶＥＸ．Ｕクラスフィールド７６８（ＥＶＥＸバイト２、ビット［２］−Ｕ） ― ＥＶＥＸ．Ｕ＝０の場合、これはクラスＡ又はＥＶＥＸ．Ｕ０を指し示し、ＥＶＥＸ．Ｕ＝１の場合、これはクラスＢ又はＥＶＥＸ．Ｕ１を指し示す。

プレフィックスエンコーディングフィールド８２５（ＥＶＥＸバイト２、ビット［１：０］−ｐｐ） ― これは、基本演算フィールドのための追加ビットを提供する。ＥＶＥＸプレフィックスフォーマットのレガシーＳＳＥ命令のサポートを提供することに加えて、これはまた、ＳＩＭＤプレフィックスをコンパクトにするという利益を有する（ＳＩＭＤプレフィックスを表現するのに１バイトを必要とするのと異なり、ＥＶＥＸプレフィックスは２ビットのみを必要とする）。一実施形態において、レガシーフォーマット及びＥＶＥＸプレフィックスフォーマットの双方でＳＩＭＤプレフィックス（６６Ｈ、Ｆ２Ｈ、Ｆ３Ｈ）を使用するレガシーＳＳＥ命令をサポートするため、それらのレガシーＳＩＭＤプレフィックスがＳＩＭＤプレフィックスエンコーディングフィールドにエンコードされ、実行時に、デコーダのＰＬＡに提供されるのに先立って、レガシーＳＩＭＤプレフィクスへと展開される（故に、ＰＬＡは、レガシーフォーマット及びＥＶＥＸフォーマットの双方のこれらレガシー命令を変更なしで実行することができる）。より新しい命令は、ＥＶＥＸプレフィックスエンコーディングフィールドのコンテンツを直接的にオペコード拡張として使用し得るが、特定の実施形態は、一貫性のために同様にして展開し、しかし、異なる意味がこれらレガシーＳＩＭＤプレフィックスによって指定されることを可能にする。他の実施形態は、２ビットＳＩＭＤプレフィックスエンコーディングをサポートするように再設計し、故に展開を必要としない。

アルファフィールド７５２（ＥＶＥＸバイト３、ビット［７］−ＥＨ；ＥＶＥＸ．ＥＨ、ＥＶＥＸ．ｒｓ、ＥＶＥＸ．ＲＬ、ＥＶＥＸ．書込マスク制御、及びＥＶＥＸ．Ｎとしても知られており、また、αを用いて示される） ― 先述のように、このフィールドはコンテキストスペシフィックである。更なる説明は後に行う。

ベータフィールド７５４（ＥＶＥＸバイト３、ビット［６：４］−ＳＳＳ；ＥＶＥＸ．ｓ_２−０、ＥＶＥＸ．ｒ_２−０、ＥＶＥＸ．ｒｒ１、ＥＶＥＸ．ＬＬ０、ＥＶＥＸ．ＬＬＢとしても知られており、また、βββを用いて示される） ― 先述のように、このフィールドはコンテキストスペシフィックである。更なる説明は後に行う。

ＲＥＸ’フィールド８１０ − これは上記ＲＥＸ’フィールドのリマインダであり、拡張３２レジスタセットの上位１６又は下位１６の何れかをエンコードするために使用され得るＥＶＥＸ．Ｖ’ビットフィールド（ＥＶＥＸバイト３、ビット［３］−Ｖ’）である。このビットはビット反転形態で格納される。下位１６レジスタをエンコードするために１の値が使用される。換言すれば、ＥＶＥＸ．Ｖ’とＥＶＥＸ．ｖｖｖｖとを結合することによって、Ｖ’ＶＶＶＶが形成される。

書込マスクフィールド７７０（ＥＶＥＸバイト３、ビット［２：０］−ｋｋｋ） ― このフィールドのコンテンツは、先述のように、複数の書込マスクレジスタ内の１つのレジスタのインデックスを指定する。本発明の一実施形態において、具体値ＥＶＥＸ．ｋｋｋ＝０００は特別に振る舞い、特定の命令に対して書込マスクが使用されないことを意味する（これは、全て１に接続された書込マスクの使用、又はマスキングハードウェアを迂回するハードウェアの使用を含む多様な手法にて実現され得る）。

リアルオペコードフィールド８３０（バイト４）
これはオペコードバイトとしても知られる。オペコードの部分がこのフィールドで指定される。

ＭＯＤ Ｒ／Ｍフィールド８４０（バイト５）
モディファイアフィールド７４６（ＭＯＤＲ／Ｍ．ＭＯＤ、ビット［７：６］−ＭＯＤフィールド８４２） ― 先述のように、ＭＯＤフィールド８４２のコンテンツは、メモリアクセス演算と非メモリアクセス演算との間の区別を行う。このフィールドについては更に後述する。

ＭＯＤＲ／Ｍ．ｒｅｇフィールド８４４、ビット［５：３］ ― ＭｏｄＲ／Ｍ．ｒｅｇフィールドの役割は、２つの状況にまとめることができる：ＭｏｄＲ／Ｍ．ｒｅｇはデスティネーションレジスタオペランド又はソースレジスタオペランドの何れかをエンコードし、あるいはＭｏｄＲ／Ｍ．ｒｅｇはオペコード拡張として扱われて、命令オペランドをエンコードすることには使用されない。

ＭＯＤＲ／Ｍ．ｒ／ｍフィールド８４６、ビット［２：０］ ― ＭｏｄＲ／Ｍ．ｒ／ｍフィールドの役割は以下を含み得る：ＭｏｄＲ／Ｍ．ｒ／ｍは、メモリアドレスを参照する命令オペランドをエンコードし、あるいはＭｏｄＲ／Ｍ．ｒ／ｍは、デスティネーションレジスタオペランド又はソースレジスタオペランドの何れかをエンコードする。

スケール、インデックス、ベース（ＳＩＢ）バイト（バイト６）
スケールフィールド７６０（ＳＩＢ．ＳＳ、ビット［７：６］） ― 先述のように、スケールフィールド７６０のコンテンツはメモリアドレス生成に使用される。このフィールドについては更に後述する。

ＳＩＢ．ＸＸＸ８５４（ビット［５：３］）及びＳＩＢ．ｂｂｂ８５６（ビット［２：０］） ― これらのフィールドのコンテンツについては、レジスタインデックスＸｘｘｘ及びＢｂｂｂに関して上述した。

変位バイト（バイト７又はバイト７−１０）
変位フィールド７６２Ａ（バイト７−１０） ― ＭＯＤフィールド８４２が１０を格納するとき、バイト７−１０は変位フィールド７６２Ａであり、レガシー３２ビット変位（ｄｉｓｐ３２）と同じに作用し、バイトの粒度にて作用する。

変位係数フィールド７６２Ｂ（バイト７） ― ＭＯＤフィールド８４２が０１を格納するとき、バイト７は変位係数フィールド７６２Ｂである。このフィールドの位置は、バイトの粒度で作用するものであるレガシーｘ８６命令セットの８ビット変位（ｄｉｓｐ８）と同じである。ｄｉｓｐ８は符号拡張されているので、−１２８と１２７との間のバイトオフセットのみをアドレスすることができ、６４バイトキャッシュラインに関して、ｄｉｓｐ８は、−１２８、−６４、０及び６４という４つの実際に有用な値のみに設定されることが可能な８ビットを使用する。より広い範囲がしばしば必要であるのでｄｉｓｐ３２が使用されるが、ｄｉｓｐ３２は４バイトを必要とする。ｄｉｓｐ８及びｄｉｓｐ３２とは異なり、変位係数フィールド７６２Ｂはｄｉｓｐ８の再解釈であり、変位係数フィールド７６２Ｂを使用するとき、実際の変位は、変位係数フィールドのコンテンツにメモリオペランドアクセス（Ｎ）のサイズを乗じたものによって決定される。このタイプの変位は、ｄｉｓｐ８＊Ｎとして参照される。これは、平均命令長を短縮する（１バイトのみが変位に使用されるが遙かに広い範囲を有する）。このような圧縮変位は、実効的な変位はメモリアクセスの粒度の倍数であり、故にアドレスオフセットの冗長な低次ビットはエンコードされる必要がないという仮定に基づく。換言すれば、変位係数フィールド７６２Ｂは、レガシーｘ８６命令セットの８ビット変位の代用となる。故に、変位係数フィールド７６２Ｂは、ｄｉｓｐ８がｄｉｓｐ８＊Ｎへとオーバーロードされることのみを除いて、ｘ８６命令セットの８ビット変位と同様にエンコードされる（故に、ＭｏｄＲＭ／ＳＩＢエンコーディングルールに変更はない）。換言すれば、エンコーディングルール又はエンコーディング長に変更はなく、ハードウェアによる変位値の解釈に変更があるのみである（ハードウェアは、バイトに関してのアドレスオフセットを取得するために、メモリオペランドのサイズによって変位をスケーリングする必要がある）。

即値
即値フィールド７７２は上述のように作用する。

典型的なレジスタアーキテクチャ ― 図９
図９は、本発明の一実施形態に従ったレジスタアーキテクチャ９００のブロック図である。レジスタアーキテクチャのレジスタファイル及びレジスタを以下に列挙する。

ベクトルレジスタファイル９１０ ― 図示した実施形態には、５１２ビット幅の３２個のベクトルレジスタが存在する。これらのレジスタをｚｍｍ０−ｚｍｍ３１として参照する。下位１６個のｚｍｍレジスタの低次２５６ビットは、レジスタｙｍｍ０−１６上にオーバーレイされている。下位１６個のｚｍｍレジスタの低次１２８ビット（ｙｍｍレジスタの低次１２８ビット）は、ｘｍｍレジスタ０−１５上にオーバーレイされている。具体的なベクトルフレンドリー命令フォーマット８００は、下の表に例示するようなこれらオーバーレイされたレジスタファイル上で作用する。

換言すれば、ベクトル長フィールド７５９Ｂが、最大長と、１つ以上のその他の、より短い長さとの間で選択を行い、そのような短い長さの各々は、先行する長さの半分の長さであり、ベクトル長フィールド７５９Ｂを有しない命令テンプレートは最大ベクトル長で作用する。また、一実施形態において、具体的なベクトルフレンドリー命令フォーマット８００のクラスＢ命令テンプレートは、パックト若しくはスカラー単精度／倍精度浮動小数点データ、及びパックト若しくはスカラー整数データ上で作用する。スカラー演算は、ｚｍｍ／ｙｍｍ／ｘｍｍレジスタ内の最も低次のデータ要素位置で実行される演算であり、より高次のデータ要素位置は、実施形態に応じて、命令前と同じままに残されるか、ゼロ化されるかの何れかである。

書込マスクレジスタ９１５ ― 図示した実施形態には、各々６４ビットサイズの８個の書込マスクレジスタ（ｋ０−ｋ７）が存在する。先述のように、本発明の一実施形態において、ベクトルマスクレジスタｋ０は書込マスクとして使用されることができず、ｋ０を通常は指し示すエンコーディングが書込マスクに使用されるとき、０ｘＦＦＦＦのハードワイヤード書込マスクを選択して、その命令に対する書込マスキングを実効的に無効にする。

マルチメディア・エクステンションズ・コントロール・ステータス・レジスタ（ＭＸＣＳＲ）９２０ ― 図示した実施形態において、この３２ビットレジスタは、浮動小数点演算に使用されるステータス・制御ビットを提供する。

汎用レジスタ９２５ ― 図示した実施形態には、メモリオペランドをアドレス指定するために既存のｘ８６アドレシングモードとともに使用される１６個の６４ビット汎用レジスタが存在する。これらのレジスタは、ＲＡＸ、ＲＢＸ、ＲＣＸ、ＲＤＸ、ＲＢＰ、ＲＳＩ、ＲＤＩ、ＲＳＰ、及びＲ８−Ｒ１５という名称で参照される。

拡張フラグ（ＥＦＬＡＧＳ）レジスタ９３０ ― 図示した実施形態において、この３２ビットレジスタは、多数の命令の結果を記録するために使用される。

浮動小数点ステータスワード（ＦＳＷ）レジスタ９３５及び浮動小数点コントロールワード（ＦＣＷ）レジスタ９４０ ― 図示した実施形態において、これらのレジスタは、丸めモード、例外マスク、及びＦＣＷの場合のフラグを設定するため、また、ＦＳＷの場合に例外を追跡するために、ｘ８７命令セットエクステンションによって使用される
ＭＭＸパックト整数（ＩＮＴ）フラットレジスタファイル９５０が上にエイリアスされたスカラー浮動小数点（ＦＰ）スタックレジスタファイル（ｘ８７スタック）９４５ ― 図示した実施形態において、ｘ８７スタックは、ｘ８７命令セットエクステンションを用いて３２／６４／８０ビット浮動小数点データについてスカラー浮動小数点演算を実行するために使用される８要素スタックであり、ＭＭＸレジスタは、６４ビットパックト整数データについて演算を実行することと、ＭＭＸレジスタとＸＭＭレジスタとの間で実行される演算に関するオペランドを保持することとのために使用される。

セグメントレジスタ９５５ ― 図示した実施形態には、セグメント化アドレス生成に使用されるデータを格納するために使用される６個の１６ビットレジスタが存在する。

ＲＩＰレジスタ９６５ ― 図示した実施形態において、この６４ビットレジスタは命令ポインタを格納する。

本発明の他の実施形態は、より広い、あるいは狭いレジスタを使用してもよい。また、本発明の他の実施形態は、より多い、少ない、あるいは異なるレジスタファイル及びレジスタを使用してもよい。

典型的なイン・オーダープロセッサアーキテクチャ ― 図１０Ａ−１０Ｂ
図１０Ａ−１０Ｂは、典型的なイン・オーダー型のプロセッサアーキテクチャのブロック図を示している。これらの例示実施形態は、ワイドベクトルプロセッサ（ＶＰＵ）で増強されるイン・オーダーＣＰＵコアの複数のインスタンス化にのっとって設計されている。コアは、ｅ１２ｔアプリケーションに応じて、高帯域インターコネクトネットワークを介して、固定機能ロジック、メモリＩ／Ｏインタフェース、及びその他の必要なＩ／Ｏロジックと通信する。例えば、スタンドアローンＧＰＵとしてのこの実施形態の実装は、典型的に、ＰＣＩｅバスを含むことになる。

図１０Ａは、本発明の実施形態に従った、シングルＣＰＵコアを、ダイ上インターコネクトネットワーク１００２へのその接続、及びそのレベル２（Ｌ２）キャッシュのサブセット１００４とともに示すブロック図である。命令デコーダ１０００は、具体的なベクトル命令フォーマット８００を含むエクステンションを備えたｘ８６命令セットをサポートしている。本発明の一実施形態においては、（設計を単純化するため）スカラーユニット１００８とベクトルユニット１０１０とが別々のレジスタセット（それぞれ、スカラーレジスタ１０１２、ベクトルレジスタ１０１４）を使用し、且つそれらの間で転送されるデータがメモリに書き込まれてレベル１（Ｌ１）キャッシュ１００６から読み戻されるが、本発明の他の実施形態は、異なるアプローチを使用してもよい（例えば、単一のレジスタセットを使用する、あるいは、書き込まれて読み戻されることなくデータが２つのレジスタファイル間で転送されることを可能にする通信パスを含む）。

Ｌ１キャッシュ１００６は、スカラーユニット及びベクトルユニットへのメモリのキャッシュのための低レイテンシアクセスを可能にする。ベクトルフレンドリー命令フォーマットのｌｏａｄ−ｏｐ命令と一緒になり、これは、Ｌ１キャッシュ１００６が拡張レジスタファイルのように取り扱われ得ることを意味する。これは、数多くのアルゴリズム、特に退去ヒントフィールド７５２Ｂを有するアルゴリズムの性能を有意に向上させる。

Ｌ２キャッシュのローカルサブセット１００４は、ＣＰＵコア毎に１つの別々のローカルサブセットに分割されるグローバルＬ２キャッシュの一部である。各ＣＰＵは、それ自身のＬ２キャッシュローカルサブセット１００４への、直接アクセス経路を有する。ＣＰＵコアによって読み出されたデータはそのＬ２キャッシュサブセット１００４に格納され、その他のＣＰＵがそれら自身のＬ２キャッシュローカルサブセットにアクセスするのと並行して、迅速にアクセスされることが可能である。ＣＰＵによって書き込まれたデータはそれ自身のＬ２キャッシュサブセット１００４に格納され、必要に応じて、その他のサブセットからフラッシュされる。リングネットワークは共有データのコヒーレンシーを確実にする。

図１０Ｂは、本発明の実施形態に従った図１０Ａ内のＣＰＵコアの部分の分解図である。図１０Ｂは、Ｌ１キャッシュ１００６のＬ１データキャッシュ部分１００６Ａと、ベクトルユニット１０１０及びベクトルレジスタ１０１４に関する更なる細部とを含んでいる。具体的には、ベクトルユニット１０１０は、１６ワイドのベクトルプロセッシングユニット（ＶＰＵ）（１６ワイドのベクトルＡＬＵ１０２８参照）であり、これが整数命令、単精度浮動小数点命令、及び倍精度浮動小数点命令を実行する。このＶＰＵは、スウィズルユニット１０２０を用いてレジスタ入力をスウィズルすること、数値化ユニット１０２２Ａ−Ｂを用いた数値化、及びメモリ入力についての複製ユニット１０２４を用いた複製をサポートしている。書込マスクレジスタ１０２６が、結果のベクトル書込を決定することを可能にする。

レジスタデータは、例えば行列乗算を支援するためなどのために、多様な手法でスウィズルされることができる。メモリからのデータは複数のＶＰＵレーンに複製されることができる。これは、グラフィックス及び非グラフィックスの双方の並列データ処理で一般的な処理であり、キャッシュ効率を有意に高めるものである。

リングネットワークは双方向であり、例えばＣＰＵコア、Ｌ２キャッシュ及びその他の論理ブロックなどのエージェントがチップ内で相互に通信することを可能にする。各リングデータパスは方向当たり５１２ビット幅である。

典型的なアウト・オブ・オーダーアーキテクチャ ― 図１１
図１１は、本発明の実施形態に従ったアウト・オブ・オーダーアーキテクチャを例示するブロック図である。具体的には、図１１は、周知の代表的なアウト・オブ・オーダーアーキテクチャが、ベクトルフレンドリー命令フォーマット及びその実行を組み込むように変更されたものを示している。図１１において、矢印は２つ以上のユニット間の結合を表しており、矢印の向きはそれらのユニット間のデータフローの向きを指し示している。図１１は、実行エンジンユニット１１１０とメモリユニット１１１５とに結合されたフロントエンドユニット１１０５を含んでいる。実行エンジンユニット１１１０は更にメモリユニット１１１５に結合されている。

フロントエンドユニット１１０５は、レベル２（Ｌ２）分岐予測ユニット１１２２に結合されたレベル１（Ｌ１）分岐予測ユニット１１２０を含んでいる。Ｌ１及びＬ２の分岐予測ユニット１１２０及び１１２２は、Ｌ１命令キャッシュユニット１１２４に結合されている。Ｌ１命令キャッシュユニット１１２４は命令トランスレーション・ルックアサイド・バッファ（ＴＬＢ）１１２６に結合されており、さらに、命令ＴＬＢユニット１１２６は命令フェッチ・プレデコードユニット１１２８に結合されている。命令フェッチ・プレデコードユニット１１２８は命令キュー（待ち行列）ユニット１１３０に結合されており、さらに、命令キューユニット１１３０はデコードユニット１１３２に結合されている。デコードユニット１１３２は、複合デコーダユニット１１３４と、３つの単純デコーダユニット１１３６、１１３８及び１１４０とを有している。デコードユニット１１３２は、マイクロコードＲＯＭユニット１１４２を含んでいる。デコードユニット１１３２は、デコード段階のセクションで上述したように動作し得る。Ｌ１命令キャッシュユニット１１２４は更に、メモリユニット１１１５内のＬ２キャッシュユニット１１４８に結合されている。命令ＴＬＢユニット１１２６は更に、メモリユニット１１１５内の第２レベルＴＬＢユニット１１４６に結合されている。デコードユニット１１３２、マイクロコードＲＯＭユニット１１４２、及びループストリーム検出ユニット１１４４は各々、実行エンジンユニット１１１０内のリネーム／アロケータユニット１１５６に結合されている。

実行エンジンユニット１１１０は、リタイアメントユニット１１７４と統合（ユニファイド）スケジューラユニット１１５８とに結合されたリネーム／アロケータユニット１１５６を含んでいる。リタイアメントユニット１１７４は、更に実行ユニットに結合されるとともに、リオーダーバッファユニット１１７８を含んでいる。統合スケジューラユニット１１５８は更に、実行ユニット１１６０に結合された物理レジスタファイルユニット１１７６に結合されている。物理レジスタファイルユニット１１７６は、ベクトルレジスタユニット１１７７Ａ、書込マスクレジスタユニット１１７７Ｂ及びスカラーレジスタユニット１１７７Ｃを有しており、これらのレジスタユニットが、ベクトルレジスタ９１０、ベクトルマスクレジスタ９１５及び汎用レジスタ９２５を提供し得る。物理レジスタファイルユニット１１７６は、図示されない更なるレジスタファイル（例えば、ＭＭＸパックト整数フラットレジスタファイル９５０がエイリアスされたスカラー浮動小数点スタックレジスタファイル９４５）を含んでいてもよい。実行ユニット１１６０は、３つの混合スカラー・ベクトルユニット１１６２、１１６４及び１１７２と、ロードユニット１１６６と、アドレス格納ユニット１１６８と、データ格納ユニット１１７０とを含んでいる。ロードユニット１１６６、アドレス格納ユニット１１６８及びデータ格納ユニット１１７０の各々は更に、メモリユニット１１１５内のデータＴＬＢユニット１１５２に結合されている。

メモリユニット１１１５は、データＴＬＢユニット１１５２に結合された第２レベルＴＬＢユニット１１４６を含んでいる。データＴＬＢユニット１１５２はＬ１データキャッシュユニット１１５４に結合されている。Ｌ１データキャッシュユニット１１５４は更にＬ２キャッシュユニット１１４８に結合されている。一部の実施形態において、Ｌ２キャッシュユニット１１４８は更に、メモリユニット１１１５の内部及び／又は外部のＬ３及び更なる階層のキャッシュユニット１１５０に結合される。

例として、例示のアウト・オブ・オーダーアーキテクチャは、以下のようなプロセスパイプラインを実装し得る：１）命令フェッチ・プレデコードユニット１１２８がフェッチ・長さデコード段階を実行し；２）デコードユニット１１３２がデコード段階を実行し；３）リネーム／アロケータユニット１１５６が割当て段階及びリネーム段階を実行し；４）統合スケジューラ１１５８がスケジュール段階を実行し；５）物理レジスタファイルユニット１１７６、リオーダーバッファユニット１１７８及びメモリユニット１１１５が、レジスタ読出し／メモリ読出し段階を実行し；実行ユニット１１６０が実行／データ変換段階を実行し；６）メモリユニット１１１５及びリオーダーバッファユニット１１７８が書戻し／メモリ書込み段階を実行し；７）リタイアメントユニット１１７４がＲＯＢ読出し段階を実行し；８）様々なユニットが例外ハンドリング段階で関与し；そして９）リタイアメントユニット１１７４及び物理レジスタファイルユニット１１７６がコミット段階を実行する。

典型的なシングルコアプロセッサ及びマルチコアプロセッサ
図１６は、本発明の実施形態に従った、集積化メモリコントローラ及びグラフィックスを備えたシングルコアプロセッサ及びマルチコアプロセッサのブロック図である。図１６内の実線のボックスは、単一のコア１６０２Ａと、システムエージェント１６１０と、一組の１つ以上のバスコントローラユニット１６１６とを有するプロセッサ１６００を示し、必要に応じての破線のボックスの追加は、複数のコア１６０２Ａ−Ｎと、システムエージェント１６１０内の一組の１つ以上の集積メモリコントローラユニット１６１４と、集積グラフィックロジック１６０８とを有する代替的なプロセッサ１６００を示す。

メモリ階層は、コア内の１つ以上のレベルのキャッシュと、一組又は１つ以上の共有キャッシュユニット１６０６と、一組の集積メモリコントローラユニット１６１４に結合された外部メモリ（図示せず）とを含む。一組の共有キャッシュユニット１６０６は、例えばレベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）若しくはその他のレベルのキャッシュなどの１つ以上の中間レベルのキャッシュ、最終レベルのキャッシュ（ＬＬＣ）、及び／又はこれらの組合せを含み得る。一実施形態において、リングベースのインターコネクトユニット１６１２が、集積グラフィックスロジック１６０８、一組の共有キャッシュユニット１６０６、及びシステムエージェントユニット１６１０を相互接続するが、他の実施形態は、これらのユニットを相互接続するために如何なる周知技術を用いてもよい。

一部の実施形態において、コア１６０２Ａ−Ｎのうちの１つ以上はマルチスレッド処理を行うことが可能である。システムエージェント１６１０は、コア１６０１Ａ−Ｎを連携させて動作させるコンポーネントを含んでいる。システムエージェントユニット１６１０は、例えば、電力制御ユニット（ＰＣＵ）及び表示ユニットを含んでいてもよい。ＰＣＵはコア１６０２Ａ−Ｎ及び集積グラフィックスロジック１６０８の電力状態を安定化させるのに必要なロジック及びコンポーネントであるか、それらを含むかし得る。表示ユニットは、１つ以上の外部接続されたディスプレイを駆動する。

コア１６０２Ａ−Ｎは、アーキテクチャ及び／又は命令セットの観点で同種あるいは異種とし得る。例えば、コア１６０２Ａ−Ｎのうちの一部は、イン・オーダー（例えば、図１０Ａ及び１０Ｂに示したようなもの）であり、他の一部はアウト・オブ・オーダー（例えば、図１１に示したようなもの）であってもよい。他の一例として、コア１６０２Ａ−Ｎのうちの２つ以上は同じ命令セットを実行することができ、その他はその命令セットのうちのサブセットのみ又は異なる命令セットのみを実行することができてもよい。複数のコアのうちの少なくとも１つは、ここに記載のベクトルフレンドリー命令フォーマットを実行することができる。

プロセッサは、例えばインテル社から入手可能な、Ｃｏｒｅ（登録商標）ｉ３、ｉ５、ｉ７、２Ｄｕｏ及びＱｕａｄ、Ｘｅｏｎ（登録商標）、若しくはＩｔａｎｉｕｍ（登録商標）プロセッサなどの汎用プロセッサとし得る。他の例では、プロセッサはその他の会社からのものであってもよい。プロセッサは、例えばネットワークプロセッサ若しくは通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、コプロセッサ、埋込プロセッサ、又はこれらに類するものなどの特殊用途のものであってもよい。プロセッサ１６００は、例えばＢｉＣＭＯＳ、ＣＭＯＳ又はＮＭＯＳなどの数多くあるプロセス技術のうちの何れかを用いて１つ以上の基板上に実装され得る。

典型的なコンピュータシステム及びプロセッサ
図１２−１４は、プロセッサ１６００を含めるのに適した典型的なシステムであり、図１５は、コア１６０２のうちの１つ以上を含み得る典型的なシステム・オン・チップ（ＳｏＣ）である。ラップトップＰＣ、デスクトップＰＣ、手持ち式ＰＣ、携帯情報端末、エンジニアリングワークステーション、サーバ、ネットワーク装置、ネットワークハブ、スイッチ、内蔵プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、グラフィックス装置、ビデオゲーム装置、セットトップボックス、マイクロコントローラ、携帯電話、ポータブルメディアプレイヤ、手持ち式装置、及び様々なその他の電子機器に関して技術的に知られたその他のシステム設計及び構成も適し得る。一般に、ここに開示されるようなプロセッサ及び／又はその他の実行ロジックを組み込むことが可能な多様なシステム又は電子機器は概して適している。

図１２を参照するに、本発明の一実施形態に従ったシステム１２００のブロック図が示されている。システム１２００は、グラフィックメモリコントローラハブ（ＧＭＣＨ）１２２０に結合された１つ以上のプロセッサ１２１０、１２１５を含み得る。図１２では、更なるプロセッサ１２１５のオプション性が破線で示されている。

各プロセッサ１２１０、１２１５は、プロセッサ１６００の何らかのバージョンとし得る。しかしながら、集積グラフィックスロジック及び集積メモリコントローラユニットはプロセッサ１２１０、１２１５内に存在しなくてもよい。

図１２は、ＧＭＣＨ１２２０が、例えばダイナミックランダムアクセスメモリ（ＤＲＡＭ）とし得るメモリ１２４０に結合され得ることを示している。ＤＲＡＭは、少なくとも１つの実施形態において、不揮発性のキャッシュと結合され得る。

ＧＭＣＨ１２２０はチップセット又はその一部とし得る。ＧＭＣＨ１２２０は、プロセッサ１２１０、１２１５と通信し、プロセッサ１２１０、１２１５とメモリ１２４０との間のインタラクションを制御し得る。ＧＭＣＨ１２２０はまた、プロセッサ１２１０、１２１５とシステム１２００のその他の要素との間の加速バスインタフェースとして機能し得る。少なくとも１つの実施形態において、ＧＭＣＨ１２２０は、例えばフロントサイドバス（ＦＳＢ）１２９５などのマルチドロップバスを介してプロセッサ１２１０、１２１５と通信する。

また、ＧＭＣＨ１２２０はディスプレイ１２４５（例えば、フラットパネルディスプレイなど）に結合されている。ＧＭＣＨ１２２０は更に、様々な周辺装置をシステム１２００に結合するために使用され得る入力／出力（Ｉ／Ｏ）コントローラハブ（ＩＣＨ）１２５０に結合されている。例えば、図１２の実施形態には、ＩＣＨ１２５０に結合される個別グラフィックス装置とし得る外部グラフィックス装置１２６０が、別の周辺装置１２７０とともに示されている。

他の例では、システム１２００内に、更なるプロセッサ又は異なるプロセッサが存在していてもよい。例えば、更なるプロセッサ１２１５は、プロセッサ１２１０と同じ更なるプロセッサ、プロセッサ１２１０とは異種あるいは非対称な更なるプロセッサ、アクセラレータ（例えば、グラフィックスアクセラレータ又はデジタル信号処理（ＤＳＰ）ユニットなど）、フィールド・プログラマブル・ゲート・アレイ、又は何らかのその他のプロセッサを含み得る。物理リソース１２１０、１２１５間には、アーキテクト的特徴、マイクロアーキテクト的特徴、熱的特性、電力消費特性などを含む利点の指標の範囲に関して、様々な相違が存在し得る。それらの相違は実効的に、処理要素１２１０、１２１５間の非対称性及び異種性として現れ得る。少なくとも１つの実施形態において、同一のダイパッケージ内に様々な処理要素１２１０、１２１５が存在し得る。

次に図１３を参照するに、本発明の一実施形態に従った第２のシステム１３００のブロック図が示されている。図１３に示されるように、マルチプロセッサシステム１３００は、二点間（ポイント・ツー・ポイント）インターコネクトシステムであり、二点間インターコネクト１３５０を介して結合された第１のプロセッサ１３７０及び第２のプロセッサ１３８０を含んでいる。図１３に示されるように、プロセッサ１３７０及び１３８０の各々はプロセッサ１６００の何らかのバージョンとし得る。

他の例では、プロセッサ１３７０及び１３８０のうちの１つ以上は、例えばアクセラレータ又はフィールド・プログラマブル・ゲート・アレイなど、プロセッサ以外の要素であってもよい。

２つのプロセッサ１３７０、１３８０のみが示されるが、理解されるように、本発明の範囲はそのように限定されるものではない。他の実施形態において、１つ以上の更なる処理要素が所与のプロセッサ内に存在し得る。

プロセッサ１３７０は更に、集積メモリコントローラハブ（ＩＭＣ）１３７２と、二点間（Ｐ−Ｐ）インタフェース１３７６及び１３７８とを含み得る。同様に、第２のプロセッサ１３８０は、ＩＭＣ１３８２とＰ−Ｐインタフェース１３８６及び１３８８とを含み得る。プロセッサ１３７０、１３８０は、ＰｔＰインタフェース回路１３７８、１３８８を用いて、二点間（ＰｔＰ）インタフェース１３５０を介してデータを交換し得る。図１３に示されるように、ＩＭＣ１３７２及び１３８２はプロセッサをそれぞれのメモリ、すなわち、メモリ１３３２及びメモリ１３３４に結合する。メモリ１３３２及びメモリ１３３４は、それぞれのプロセッサにローカルに取り付けられたメインメモリの部分であってもよい。

プロセッサ１３７０、１３８０は各々、チップセット１３９０と、二点間インタフェース回路１３７６、１３９４、１３８６、１３９８を用いて、個々のＰ−Ｐインタフェース１３５２、１３５４を介してデータを交換し得る。チップセット１３９０はまた、高性能グラフィックス回路１３３８と高性能グラフィックスインタフェース１３３９を介してデータを交換し得る。

何れかのプロセッサ内又は双方のプロセッサの外側に、Ｐ−Ｐインターコネクトを介してこれらのプロセッサに接続されて、共有キャッシュ（図示せず）が含められてもよく、それにより、プロセッサが低電力モードに置かれる場合に、何れか又は双方のプロセッサのローカルキャッシュ情報が共有キャッシュに格納され得る。

チップセット１３９０は、インタフェース１３９６を介して第１のバス１３１６に結合され得る。一実施形態において、第１のバス１３１６は、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バス、又は例えばＰＣＩ Ｅｘｐｒｅｓｓバス若しくはその他の第３世代Ｉ／Ｏインターコネクトバスなどのバスとし得るが、本発明の範囲はそのように限定されるものではない。

図１３に示されるように、第１のバス１３１６には、第１のバス１３１６を第２のバス１３２０に結合するバスブリッジ１３１８とともに、様々なＩ／Ｏ装置１３１４が結合され得る。一実施形態において、第２のバス１３２０はローピンカウント（low pin count；ＬＰＣ）バスとし得る。第２のバス１３２０には、一実施形態において、例えばキーボード／マウス１３２２、通信装置１３２６及びデータストレージユニット１３２８を含む様々な装置が結合され得る。データストレージユニット１３２８は、例えばディスクドライブ若しくはその他の大容量記憶装置などであり、コード１３３０を含み得る。また、音声Ｉ／Ｏ１３２４が第２のバス１３２０に結合されてもよい。なお、その他のアーキテクチャも可能である。例えば、図１３のポイント・ツー・ポイントアーキテクチャに代えて、システムはマルチドロップバス又はその他のそのようなアーキテクチャを実装してもよい。

次に図１４を参照するに、本発明の一実施形態に従った第３のシステム１４００のブロック図が示されている。図１３及び１４における同様の要素は似通った参照符号を付されており、図１３の特定の側面は、図１４のその他の側面を不明瞭にしないよう、図１４から省かれている。

図１４は、処理要素１３７０、１３８０がそれぞれ、集積メモリ・Ｉ／Ｏコントロールロジック（“ＣＬ”）１３７２、１３８２を含み得ることを示している。少なくとも１つの実施形態において、ＣＬ１３７２、１３８２は、上述したもののようなメモリコントローラハブロジック（ＩＭＣ）を含み得る。さらに、ＣＬ１３７２、１３８２はまたＩ／Ｏコントロールロジックを含み得る。図１４は、メモリ１３３２、１３３４だけでなくＩ／Ｏ装置１４１４もＣＬ１３７２、１３８２に結合されることを示している。レガシーＩ／Ｏ装置１４１５はチップセット１３９０に結合されている。

次に図１５を参照するに、本発明の一実施形態に従ったＳｏＣ１５００のブロック図が示されている。その他の図と同様の要素は似通った参照符号を付されている。また、破線のボックスは、より先端的なＳｏＣにおけるオプション機能である。図１５において、インターコネクトユニット１５０２が、一組の１つ以上のコア１６０２Ａ−Ｎと共有キャッシュユニット１６０６とを含むアプリケーションプロセッサ１５１０；システムエージェントユニット１６１０；バスコントローラユニット１６１６；集積メモリコントローラユニット１６１４；集積グラフィックスロジック１６０８と、スチルカメラ及び／又はビデオカメラの機能を提供する画像プロセッサ１５２４と、ハードウェア音声アクセラレーションを提供する音声プロセッサ１５２６と、ビデオエンコード／デコードアクセラレーションを提供するビデオプロセッサ１５２８とを含み得る一組若しくは１つ以上のメディアプロセッサ１５２０；スタティックランダムアクセスメモリ（ＳＲＡＭ）ユニット１５３０；ダイレクトメモリアクセス（ＤＭＡ）ユニット１５３２；及び１つ以上の外部ディスプレイを結合するための表示ユニット１５４０；に結合されている。

ここに開示される機構の実施形態は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの実装手法の組合せにて実装され得る。本発明の実施形態は、少なくとも１つのプロセッサと、ストレージシステム（揮発性メモリと不揮発性のメモリ及び／又は記憶素子を含む）と、少なくとも１つの入力装置と、少なくとも１つの出力装置とを有するプログラム可能なシステム上で実行されるコンピュータプログラム又はプログラムコードとして実装され得る。

プログラムコードが入力データに適用されて、ここに記載の機能が実行されて出力情報が生成され得る。出力情報は既知のように１つ以上の出力装置に与えられ得る。この適用の目的で、処理システムは、例えばデジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）又はマイクロプロセッサなどのプロセッサを有する何らかのシステムを含んでいる。

プログラムコードは、処理システムとの伝達のため、ハイレベルの手続き型又はオブジェクト指向のプログラミング言語で実装され得る。プログラムコードはまた、必要に応じて、アセンブリ言語又は機械語で実装されてもよい。実際、ここに記載の機構は、範囲的に、如何なる特定のプログラミング言語にも限定されない。何れの場合も、その言語はコンパイルあるいはインタープリットされた言語であってもよい。

少なくとも１つの実施形態の１つ以上の態様は、機械読み取り可能媒体に格納され、プロセッサ内で様々なロジックを表す表現命令であって、機械によって読み出されるときに該機械にここに記載の技術を実行するロジックを作成させる表現命令によって実装され得る。そのような表現物は、“ＩＰコア”として知られるものであり、有形の機械読み取り可能媒体に格納されて様々な顧客又は製造設備に供給され、実際にロジック又はプロセッサを作成する製造機械にロードされる。

そのような機械読み取り可能記憶媒体は、限定ではなく、機械又は装置によって製造あるいは形成される、非一過性の、有形構成の品目を含み得る。そのような品目は、例えばハードディスクなどの記憶媒体、フロッピーディスク（登録商標）、光ディスク（コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、書換可能コンパクトディスク（ＣＤ−ＲＷ））、磁気光ディスクを含むその他の種類のディスク、例えば読み出し専用メモリ（ＲＯＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）やスタティックランダムアクセスメモリ（ＳＲＡＭ）のようなランダムアクセスメモリ（ＲＡＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、フラッシュメモリ、電気的消去可能プログラム可能読み出し専用メモリ（ＥＥＰＲＯＭ）などの半導体デバイス、磁気カード若しくは光カード、又は電子的な命令を格納するのに適したその他の種類の媒体を含む。

従って、本発明の実施形態はまた、ベクトルフレンドリー命令フォーマットの命令、又はここに記載の構成、回路、装置、プロセッサ及び／又はシステムの機能を規定する例えばハードウェア記述言語（ＨＤＬ）などの設計データを格納した、非一過性の有形の機械読み取り可能媒体をも含む。このような実施形態はプログラム製品とも呼ばれている。

一部のケースにおいて、命令をソース命令セットからターゲット命令セットへと変換するために命令コンバータが使用され得る。例えば、命令コンバータは、命令を、コアによって処理される１つ以上のその他の命令へと、翻訳し（例えば、静的なバイナリトランスレーションや、動的コンパイルを含む動的なバイナリトランスレーションを用いて）、変形し、エミュレートし、あるいはその他の方法で変換し得る。命令コンバータは、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組合せにて実装され得る。命令コンバータは、ｏｎプロセッサ、オフプロセッサ、又は部分的にオンプロセッサ且つ部分的にオフプロセッサとし得る。

図１７は、本発明の実施形態に従った、ソース命令セット内のバイナリ命令をターゲット命令セット内のバイナリ命令に変換するソフトウェア命令コンバータの使用と対比するブロック図である。図示した実施形態において命令コンバータはソフトウェアの命令コンバータであるが、他の例では命令コンバータはソフトウェア、ファームウェア、ハードウェア、又はこれらの様々な組合せにて実装され得る。図１７は、ハイレベル言語１７０２のプログラムが、ｘ８６コンパイラ１７０４を用いてコンパイルされて、少なくとも１つのｘ８６命令セットコアを有するプロセッサ１７１６によって実行され得るｘ８６バイナリコード１７０６が生成され得ることを示している（コンパイルされた命令の一部はベクトルフレンドリー命令フォーマットでのものであると仮定する）。少なくとも１つのｘ８６命令セットコアを有するプロセッサ１７１６とは、少なくとも１つのｘ８６命令セットコアを有するインテルプロセッサと実質的に同じ結果を達成するために、（１）インテルｘ８６命令セットコアの命令セットの実質的部分、又は（２）少なくとも１つのｘ８６命令セットコアを有するインテルプロセッサ上で実行するターゲットのアプリケーション若しくはその他のソフトウェアのオブジェクトコード版、を互換的に実行あるいはその他の方法で処理することによって、少なくとも１つのｘ８６命令セットコアを有するインテルプロセッサと実質的に同じ機能を実行することが可能な如何なるプロセッサをも意味する。ｘ８６コンパイラ１７０４とは、更なるリンケージ処理を用いて、あるいは更なるリンケージ処理を用いずに少なくとも１つのｘ８６命令セットコアを有するプロセッサ１７１６上で実行されることができるｘ８６バイナリコード１７０６（例えば、オブジェクトコード）を生成するよう動作可能なコンパイラを意味する。同様に、図１７は、ハイレベル言語１７０２が、他の命令セットコンパイラ１７０８を用いてコンパイルされて、ｘ８６命令セットコアを１つも有しないプロセッサ１７１４（例えば、ＭＩＰＳテクノロジ社のＭＩＰＳ命令セットを実行し且つ／或いはＡＲＭホールディング社のＡＲＭ命令セットを実行するコアを有するプロセッサ）によって実行され得る他の命令セットバイナリコード１７１０が生成され得ることを示している。命令コンバータ１７１２は、ｘ８６バイナリコード１７０６を、ｘ８６命令セットコアを有しないプロセッサ１７１４によって実行され得るコードへと変換するために使用される。この変換を為されたコードは、他の命令セットバイナリコード１７１０とは同じにならない可能性がある。それが可能な命令コンバータは製造困難である。しかしながら、変換されたコードは全体的な処理を達成するとともに、他の命令セットからの命令で構成されることになる。故に、命令コンバータ１７１２とは、ｘ８６命令セットプロセッサ若しくはコアを有しないプロセッサ又はその他の電子装置がｘ８６バイナリコード１７０６を実行することを、エミュレーション、シミュレーション又はその他の処理を介して可能にするソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せを意味する。

ここに開示されるベクトルフレンドリー命令フォーマットの命令の特定の演算は、ハードウェアコンポーネントによって実行されてもよく、また、その演算を実行する命令でプログラムされた回路又はその他のハードウェアコンポーネントを生じさせる、あるいは少なくとももたらすように機械実行可能命令にて具現化され得る。回路は、数例を挙げれば、汎用若しくは特殊用途のプロセッサ又はロジック回路を含み得る。演算はまた、場合により、ハードウェアとソフトウェアとの組合せによって実行され得る。実行ロジック及び／又はプロセッサは、機械命令又はそれから得られる１つ以上の制御信号に応答して、命令により指定される結果オペランドを格納する具体的あるいは特定の回路又はその他のロジックを含み得る。例えば、ここに開示される命令の実施形態は、図１２−１５の１つ以上のシステムで実行され、ベクトルフレンドリー命令フォーマットの命令の実施形態は、システムにて実行されるプログラムコード内に格納され得る。また、これらの図の処理要素は、ここに詳述されるパイプライン及び／又はアーキテクチャ（例えば、イン・オーダーアーキテクチャ及びアウト・オブ・オーダーアーキテクチャ）のうちの１つを利用し得る。例えば、イン・オーダーアーキテクチャのデコードユニットは、命令をデコードし、デコードした命令をベクトルユニット又はスカラーユニットに渡すことなどを行い得る。

以上の説明は、本発明の好適実施形態を例示することを意図したものである。以上の説明から、明らかなように、特に成長が速く更なる前進が容易に予測できないこのような技術分野において、本発明は、添付の請求項の範囲及びその均等範囲内で、本発明の原理を逸脱することなく、当業者によって構成及び細部を変更され得るものである。例えば、方法の１つ以上の処理は、結合されることもあるし、更に細分化されることもある。

代替実施形態
ベクトルフレンドリー命令フォーマットを生来的に実行し得る実施形態を説明してきたが、本発明の他の実施形態は、異なる命令セットを実行するプロセッサ（例えば、ＭＩＰＳテクノロジ社のＭＩＰＳ命令セットを実行するプロセッサ、ＡＲＭホールディング社のＡＲＭ命令セットを実行するプロセッサ）上で動作するエミュレーション層を介して、ベクトルフレンドリー命令フォーマットを実行してもよい。また、図面のフロー図は本発明の特定の実施形態によって実行される特定の順序の処理を示しているが、理解されるように、そのような順序は例示である（例えば、他の実施形態は、異なる順序でそれらの処理を実行したり、特定の複数の処理を結合したり、特定の複数の処理を重ね合わせたり、等々し得る）。

以上の説明においては、本発明の実施形態の完全なる理解を提供するために、説明目的で、数多くの具体的詳細事項を説明した。しかしながら、当業者に明らかなように、それらの具体的詳細事項の一部を用いずに、１つ以上のその他の実施形態が実施され得る。記載された具体的な実施形態は、本発明を限定するためではなく、本発明の実施形態を例示するために提供されたものである。本発明の範囲は、以上にて提供された具体例によって決定されるべきものではなく、請求項によってのみ決定されるものである。

Claims (22)

1. コンピュータプロセッサで融合命令を実行する方法であって：
   前記融合命令をフェッチするステップであり、前記融合命令は、書込マスクオペランド、デスティネーションオペランド、第１のソースオペランド、及び第２のソースオペランドを含む、ステップ；
   前記フェッチされた融合命令をデコードするステップ：
   前記デコードされた融合命令を実行して、前記第１及び第２のソースオペランドのデータ要素のデータ要素毎の選択を、前記書込マスクの対応するビット位置を前記第１及び第２のソースオペランド間のセレクタとして用いて実行するステップ；及び
   前記選択されたデータ要素を、前記デスティネーション内の対応する位置にて、前記デスティネーションに格納するステップ；
   を有する方法。
2. 前記書込マスクは１６ビットレジスタである、請求項１に記載の方法。
3. 前記書込マスクは１６ビットレジスタであり、８個の最下位ビット位置のみがセレクタとして使用され、前記データ要素は６４ビットサイズである、請求項１に記載の方法。
4. 前記第１のソースは５１２ビットレジスタであり、前記第２のソースはメモリである、請求項１に記載の方法。
5. 前記第２のソースのデータ要素は１６ビットから３２ビットにアップコンバートされる、請求項４に記載の方法。
6. 前記第１及び第２のソースは５１２ビットレジスタである、請求項１に記載の方法。
7. 前記選択は、前記書込マスクの各ビット位置に対して並行して行われる、請求項１に記載の方法。
8. 前記第１及び第２のソースオペランドは５１２ビットレジスタである、請求項１に記載の方法。
9. 前記第２のソースオペランドは５１２ビットメモリロケーションであり、前記第１及び第２のソースの融合に先立って、前記メモリロケーションからのデータ要素が５１２ビットの一時レジスタにロードされる、請求項１に記載の方法。
10. 前記データ要素は３２ビットである、請求項１に記載の方法。
11. 第１及び第２のソースオペランドと、デスティネーションオペランドと書込マスクオペランドとを含む融合命令に応答して、
    第１のビット位置の前記書込マスクの値を評価し、
    前記第１のビット位置の前記値が、前記第１のソースの対応する第１のデータ要素が前記デスティネーション内の対応する第１のデータ要素位置に保存されるべきであることを指し示しているか、あるいは前記第２のソースの対応する第１のデータ要素が前記デスティネーション内の前記対応する第１のデータ要素位置に保存されるべきであることを指し示しているか、を決定し、且つ
    前記第１のビット位置の前記値によって指し示された第１のデータ要素を、前記デスティネーション内の前記第１のデータ要素位置に格納する、
    ことを有する方法。
12. 第２のビット位置の前記書込マスクの値を評価し、
    前記第２のビット位置の前記値が、前記第１のソースの対応する第２のデータ要素が前記デスティネーション内の対応する第２のデータ要素位置に保存されるべきであることを指し示しているか、あるいは前記第２のソースの対応する第２のデータ要素が前記デスティネーション内の前記対応する第２のデータ要素位置に保存されるべきであることを指し示しているか、を決定し、且つ
    前記第２のビット位置の前記値によって指し示された第２のデータ要素を、前記デスティネーション内の前記第２のデータ要素位置に格納する、
    ことを更に有する請求項１１に記載の方法。
13. 前記書込マスクの全てのビット位置が評価されて、前記融合命令の終了を指し示していることを決定する、
    ことを更に有する請求項１２に記載の方法。
    を有する方法。
14. 前記書込マスクは１６ビットレジスタである、請求項１１に記載の方法。
15. 前記書込マスクは１６ビットレジスタであり、８個の最下位ビット位置のみがセレクタとして使用され、前記データ要素は６４ビットサイズである、請求項１１に記載の方法。
16. 前記第１のソースは５１２ビットレジスタであり、前記第２のソースはメモリである、請求項１１に記載の方法。
17. 前記第２のソースのデータ要素は１６ビットから３２ビットにアップコンバートされる、請求項１４に記載の方法。
18. 前記第１及び第２のソースは５１２ビットレジスタである、請求項１１に記載の方法。
19. 前記第１及び第２のソースオペランドは５１２ビットレジスタである、請求項１１に記載の方法。
20. 前記第２のソースオペランドは５１２ビットメモリロケーションであり、前記第１及び第２のソースの融合に先立って、前記メモリロケーションからのデータ要素が５１２ビットの一時レジスタにロードされる、請求項１１に記載の方法。
21. 融合命令をデコードするハードウェアデコーダであり、前記融合命令は、書込マスクオペランド、デスティネーションオペランド、第１のソースオペランド、及び第２のソースオペランドを含む、ハードウェアデコーダ；及び
    前記第１及び第２のソースオペランドのデータ要素のデータ要素毎の選択を、前記書込マスクの対応するビット位置を前記第１及び第２のソースオペランド間のセレクタとして用いて実行し、且つ、前記選択されたデータ要素を、前記デスティネーション内の対応する位置にて、前記デスティネーションに格納する実行ロジック；
    を有する装置。
22. 前記書込マスクを格納する１６ビット書込マスクレジスタ；及び
    前記第１及び第２のソースのデータ要素を格納する少なくとも２つの５１２ビットレジスタ；
    を更に有する請求項２１に記載の装置。

Images