特許 6109910 メモリ・ソースを宛先レジスタに展開し、ソース・レジスタを宛先メモリ位置に圧縮するためのシステム、装置および方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6109910

(24)【登録日】2017年3月17日

(45)【発行日】2017年4月5日

(54)【発明の名称】メモリ・ソースを宛先レジスタに展開し、ソース・レジスタを宛先メモリ位置に圧縮するためのシステム、装置および方法

(51)【国際特許分類】

   G06F 9/30 20060101AFI20170327BHJP

   G06F 17/16 20060101ALI20170327BHJP

【ＦＩ】

   G06F9/30 350B

   G06F17/16 Q

【請求項の数】20

【外国語出願】

【全頁数】41

(21)【出願番号】特願2015-233642(P2015-233642)

(22)【出願日】2015年11月30日

(62)【分割の表示】特願2014-502545(P2014-502545)の分割

【原出願日】2011年12月9日

(65)【公開番号】特開2016-29598(P2016-29598A)

(43)【公開日】2016年3月3日

【審査請求日】2015年11月30日

(31)【優先権主張番号】13/078,896

(32)【優先日】2011年4月1日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】サン アドリアン，ヘスース コルバル

(72)【発明者】

【氏名】サンス，ロヘル，エスパーサ

(72)【発明者】

【氏名】ヴァレンタイン，ロバート，シー．

(72)【発明者】

【氏名】デュラン，サンティアゴ，ハラン

(72)【発明者】

【氏名】ウィーデマイア，ジェフリー，ジー．

(72)【発明者】

【氏名】サムドララ，スリダール

(72)【発明者】

【氏名】ギルカール，ミリンド，バブラオ

(72)【発明者】

【氏名】フォーサイス，アンドリュー，トマス

(72)【発明者】

【氏名】リー，ヴィクター，ダブリュー

【審査官】 三坂 敏夫

(56)【参考文献】

【文献】 米国特許出願公開第２００９／０１７２３４９（ＵＳ，Ａ１）

【文献】 特開平０３−１９６２５７（ＪＰ，Ａ）

【文献】 特開昭６２−２２６２７５（ＪＰ，Ａ）

【文献】 特開昭６２−２３３８８４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／００４７３６０（ＵＳ，Ａ１）

【文献】 特開昭５９−１８８７７９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００３／０１７２２５２（ＵＳ，Ａ１）

【文献】 Michael ABRASH，"A First Look at the Larrabee New Instructions (LRBni)"，［ｏｎｌｉｎｅ］，米国，United Business Media，２００９年 ４月 １日，pages:1-16，［平成２６年９月１８日検索］インターネットＵＲＬ：http://www.cs.cmu.edu/afs/cs/academic/class/15869-

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／３０

Ｇ０６Ｆ １７／１６

(57)【特許請求の範囲】

【請求項1】

コンピュータ・プロセッサにおいて命令を実行する方法であって：
前記命令をフェッチする段階であって、前記命令は、オペコード、プレフィックス、宛先オペランド、ソース・オペランドおよび書き込みマスク・オペランドを含む、段階と；
前記フェッチされた命令をデコードする段階と；
前記デコードされた命令を実行して、前記書き込みマスク・オペランドの値に基づいて前記ソース・オペランドからのどのデータ要素が前記宛先オペランドにおいて記憶されるべきかを選択する段階と；
前記ソース・オペランドの前記選択されたデータ要素を、シーケンシャルにパックされたデータ要素として前記宛先オペランド中に記憶する段階とを含み、
前記ソース・オペランドの前記データ要素のサイズが、前記命令の前記プレフィックスの単一のビットによって定められ、前記実行に使用される前記書き込みマスク・オペランドの値の個数が、前記ソース・オペランドの前記データ要素サイズによって決定され、前記書き込みマスク・オペランドは、複数の書き込みマスク・レジスタのうちの１つである、
方法。

【請求項2】

前記宛先オペランドがメモリであり、前記ソース・オペランドがレジスタである、請求項１記載の方法。

【請求項3】

前記ソースおよび宛先オペランドがレジスタである、請求項１記載の方法。

【請求項4】

前記実行がさらに：
前記書き込みマスク・オペランドの第一のビット位置の値が、対応する第一ソース・データ要素が前記宛先オペランドのある位置中に記憶されるべきであることを示していることを判別する段階と；
前記対応する第一ソース・データ要素を前記宛先オペランドの前記位置中に記憶する段階とを含む、
請求項１記載の方法。

【請求項5】

前記実行がさらに：
前記書き込みマスク・オペランドの第一のビット位置の値が、対応する第一ソース・データ要素が前記宛先オペランドのある位置中に記憶されるべきでないことを示していることを判別する段階と；
前記第一ソース・データ要素を前記宛先オペランドのある位置中に記憶することなく、前記書き込みマスク・オペランドの前記第一のビット位置に続く第二のビット位置の値を評価する段階とを含む、
請求項１記載の方法。

【請求項6】

前記宛先オペランド中に記憶されるべきデータ要素を、前記宛先オペランド中に記憶するのに先立って下方変換する段階をさらに含む、
請求項１記載の方法。

【請求項7】

前記データ要素が32ビット値から16ビット値に下方変換される、請求項６記載の方法。

【請求項8】

コンピュータ・プロセッサにおいて命令を実行する方法であって：
前記命令をフェッチする段階であって、前記命令は、オペコード、プレフィックス、宛先オペランド、ソース・オペランドおよび書き込みマスク・オペランドを含む、段階と；
前記命令をデコードする段階と；
前記命令を実行して、前記書き込みマスク・オペランドの値に基づいて前記ソース・オペランドからのどのデータ要素が前記宛先オペランドにおいて疎に記憶されるべきかを選択する段階と；
前記ソース・オペランドの各選択されたデータ要素を、疎なデータ要素としてある宛先位置中に記憶する段階であって、該宛先位置は、前記ソース・オペランドの対応するデータ要素が記憶されるべきであることを示す各書き込みマスク・オペランド・ビット位置に対応する、段階とを含み、
各宛先位置は、前記ソース・オペランドの対応するデータ要素が記憶されるべきであることを示す各書き込みマスク・オペランド・ビット位置に対応し、前記ソース・オペランドの前記データ要素のサイズが、前記命令の前記プレフィックスの単一のビットによって定められ、前記実行に使用される前記書き込みマスク・オペランドの値の個数が、前記ソース・オペランドの前記データ要素サイズによって決定され、前記書き込みマスク・オペランドは、複数の書き込みマスク・レジスタのうちの１つである、
方法。

【請求項9】

前記宛先オペランドがレジスタであり、前記ソース・オペランドがメモリである、請求項８記載の方法。

【請求項10】

前記ソースおよび宛先オペランドがレジスタである、請求項８記載の方法。

【請求項11】

前記実行がさらに：
前記書き込みマスク・オペランドの第一のビット位置の値が、対応する第一ソース・データ要素が前記宛先オペランドの対応する位置中に記憶されるべきであることを示していることを判別する段階と；
前記対応する第一ソース・データ要素を前記宛先オペランドの前記対応する位置中に記憶する段階とを含む、
請求項８記載の方法。

【請求項12】

前記実行がさらに：
前記書き込みマスク・オペランドの第一のビット位置の値が、対応する第一ソース・データ要素が前記宛先オペランドの対応する位置中に記憶されるべきでないことを示していることを判別する段階と；
前記第一ソース・データ要素を前記宛先オペランドの対応する位置中に記憶することなく、前記書き込みマスク・オペランドの前記第一のビット位置に続く第二のビット位置の値を評価する段階とを含む、
請求項８記載の方法。

【請求項13】

前記宛先オペランド中に記憶されるべきデータ要素を、前記宛先オペランド中に記憶するのに先立って上方変換する段階をさらに含む、
請求項８記載の方法。

【請求項14】

前記データ要素が16ビット値から32ビット値に上方変換される、請求項１３記載の方法。

【請求項15】

第一の命令および／または第二の命令をデコードするハードウェア・デコーダであって、前記第一の命令は、第一のオペコード、第一のプレフィックス、第一の書き込みマスク・オペランド、第一の宛先オペランド、第一のソース・オペランドを含み、前記第二の命令は、第二のオペコード、第二のプレフィックス、第二の書き込みマスク・オペランド、第二の宛先オペランド、第二のソース・オペランドを含む、ハードウェア・デコーダと；
実行論理とを有する装置であって、
前記実行論理は、
デコードされた第一の命令を実行して、前記第一の書き込みマスク・オペランドの値に基づいて前記第一のソース・オペランドからのどのデータ要素が前記第一の宛先オペランドにおいて疎に記憶されるべきかを選択し、前記第一のソース・オペランドの各選択されたデータ要素を、疎なデータ要素としてある宛先位置中に記憶し、前記宛先位置は、前記第一のソース・オペランドの対応するデータ要素が記憶されるべきであることを示す各第一の書き込みマスク・オペランド・ビット位置に対応し、
前記実行論理は、
デコードされた第二の命令を実行して、前記第二の書き込みマスク・オペランドの値に基づいて前記第二のソース・オペランドからのどのデータ要素が前記第二の宛先オペランドにおいて記憶されるべきかを選択し、前記第二のソース・オペランドの選択されたデータ要素を、シーケンシャルにパックされたデータ要素として前記第二の宛先オペランド中に記憶し、
前記第一のソース・オペランドの前記データ要素のサイズが、前記第一の命令の前記第一のプレフィックスによって定められ、前記第二のソース・オペランドの前記データ要素のサイズが、前記第二の命令の前記第二のプレフィックスによって定められ、前記実行論理によって使用される前記第一および第二の書き込みマスク・オペランドの値の個数が、それぞれ、前記第一および第二のソース・オペランドの前記データ要素サイズによって決定され、前記第一および第二の書き込みマスク・オペランドは各々、複数の書き込みマスク・レジスタのうちの１つである、
装置。

【請求項16】

請求項１５記載の装置であって、さらに：
前記第一または第二の書き込みマスク・オペランドを記憶する16ビット書き込みマスク・レジスタと；
前記選択されたデータ要素を記憶する第一の512ビット・レジスタとを有する、
装置。

【請求項17】

請求項１６記載の装置であって、さらに：
前記第一および第二の命令のためのソース・オペランドとしてはたらく第二の512ビット・レジスタを有する、
装置。

【請求項18】

前記データ要素が、前記第一の命令の実行中に16ビット値から32ビット値に上方変換される、請求項１５記載の装置。

【請求項19】

命令をデコードするデコーダであって、前記命令は、オペコード、プレフィックス、書き込みマスク・オペランド、宛先オペランド、及びソース・オペランドを含む、デコーダと；
前記デコードされた命令を実行して、前記書き込みマスク・オペランドの値に基づいて前記ソース・オペランドからのどのデータ要素が前記宛先オペランドにおいて疎に記憶されるべきかを選択し、前記ソース・オペランドの各選択されたデータ要素を、疎なデータ要素としてある宛先位置中に記憶する実行論理であって、前記宛先位置は、前記ソース・オペランドの対応するデータ要素が記憶されるべきであることを示す各書き込みマスク・オペランド・ビット位置に対応し、前記ソース・オペランドの前記データ要素のサイズが、前記命令の前記プレフィックスによって定められ、前記実行論理によって使用される前記書き込みマスク・オペランドの値の個数が、前記ソース・オペランドの前記データ要素サイズによって決定され、前記書き込みマスク・オペランドは、複数の書き込みマスク・レジスタのうちの１つである、実行論理と；
を有する装置。

【請求項20】

命令をデコードするデコーダであって、前記命令は、オペコード、プレフィックス、書き込みマスク・オペランド、宛先オペランド、及びソース・オペランドを含む、デコーダと；
前記デコードされた命令を実行して、前記書き込みマスク・オペランドの値に基づいて前記ソース・オペランドからのどのデータ要素が前記宛先オペランドにおいて記憶されるべきかを選択し、前記ソース・オペランドの前記選択されたデータ要素を、シーケンシャルにパックされたデータ要素として前記宛先オペランド中に記憶する実行論理であって、前記ソース・オペランドの前記データ要素のサイズが、前記命令の前記プレフィックスによって定められ、前記実行論理によって使用される前記書き込みマスク・オペランドの値の個数が、前記ソース・オペランドの前記データ要素サイズによって決定され、前記書き込みマスク・オペランドは、複数の書き込みマスク・レジスタのうちの１つである、実行論理と；
を有する装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は概括的にはコンピュータ・プロセッサ・アーキテクチャに関し、より詳細には実行されたときに特定の結果を引き起こす命令に関する。

【背景技術】

【0002】

データ構造レイアウトを操作することによってメモリ利用を改善するいくつかの方法がある。3D変換および照明のようなある種のアルゴリズムについては、バーテックス・データを配置する二つの基本的方法がある。伝統的な方法は、構造配列（AoS: array of structure）の配置であり、各バーテックスについて構造をもつ。もう一つの方法は、配列構造（SoA: structure of arrays）において、各座標についての配列中にデータを配置する。

【0003】

AoSフォーマットでのデータのコンピューティングには二つのオプションがある。AoS配置にある通りのデータに対して処理を実行するか、SoA配置に再配置（かきまぜ〔スウィズル〕）する。もとのAoS配置に対するSIMD処理の実行はより多くの計算を要求することがあり、処理の一部は利用可能なSIMD要素すべてを活用しない。よって、このオプションは一般には効率がより低い。

【0004】

SoA配置は単一命令複数データ（SIMD: Single Instruction, Multiple Data）技術の並列性をより効率的に利用することを許容する。データが、より最適な垂直の仕方で計算のために準備ができているからである。対照的に、AoSデータに対して直接的に計算を行うことは、先のコード・サンプルにおける多くの「どうでもいい」（DC: don't-care）スロットによって示されるように、SIMD実行スロットを消費するが単一のスカラー結果のみを生じる水平処理につながることができる。

【発明の概要】

【発明が解決しようとする課題】

【0005】

SIMD技術の到来により、データ編成の選択はより重要になり、データに対して実行されるべき処理に注意深く基づくべきである。いくつかのアプリケーションでは、伝統的なデータ配置は最大パフォーマンスにつながらないことがある。アプリケーション開発者は、効率的な計算のために、種々のデータ配置およびデータ・セグメンテーション方針を探求することが推奨されてきた。これは所与のアプリケーションにおいてAoS、SoAまたさらにはハイブリッドSoAの組み合わせを使うことを意味しうる。

【課題を解決するための手段】

【0006】

本発明は、限定ではなく例として、付属の図面において示される。図面において、同様の参照符号は同様の要素を示す。

【図面の簡単な説明】

【0007】

【図1】展開命令の実行の例が示されている。

【図2】レジスタ・オペランドをソースとしての展開命令の実行の例を示す。

【図3】展開命令を実行するための擬似コードの例を示す。

【図4】プロセッサにおける展開命令の使用のある実施形態を示す。

【図5】展開命令を処理する方法のある実施形態を示す。

【図6】プロセッサにおける圧縮命令の実行の例を示す。

【図7】プロセッサにおける圧縮命令の実行のもう一つの例を示す。

【図8】展開命令を実行するための擬似コードの例を示す。

【図9】プロセッサにおける圧縮命令の使用のある実施形態を示す。

【図10】圧縮命令を処理する方法のある実施形態の例を示す。

【図11A】本発明の諸実施形態に基づく、汎用ベクトル・フレンドリー命令フォーマットおよびそのクラスA命令テンプレートを示すブロック図である。

【図11B】本発明の諸実施形態に基づく、汎用ベクトル・フレンドリー命令フォーマットおよびそのクラスB命令テンプレートを示すブロック図である。

【図12】Ａ〜Ｃは、本発明の諸実施形態に基づく例示的な個別ベクトル・フレンドリー命令フォーマットを示す図である。

【図13】本発明のある実施形態に基づく、レジスタ・アーキテクチャのブロック図である。

【図14】Ａは、本発明の諸実施形態に基づく、単一CPUコアを、そのダイ上相互接続ネットワークへの接続およびそのレベル２（L2）キャッシュのローカル・サブセットとともに示すブロック図であり、Ｂは、本発明の諸実施形態に基づく、ＡのCPUコアの一部の分解図である。

【図15】本発明の諸実施形態に基づく、例示的な順序外（out-of-order）アーキテクチャを示すブロック図である。

【図16】本発明のある実施形態に基づくシステムのブロック図である。

【図17】本発明のある実施形態に基づく第二のシステムのブロック図である。

【図18】本発明のある実施形態に基づく第三のシステムのブロック図である。

【図19】本発明のある実施形態に基づくSoCのブロック図である。

【図20】本発明の諸実施形態に基づく統合されたメモリ・コントローラおよびグラフィックスをもつ、単一コア・プロセッサおよび複数コア・プロセッサのブロック図である。

【図21】本発明の諸実施形態に基づく、ソース命令セット中のバイナリー命令をターゲット命令セット中のバイナリー命令に変換するソフトウェア命令コンバーターの使用を対照するブロック図である。

【発明を実施するための形態】

【0008】

以下の記述では、数多くの個別的詳細が記載されるが、本発明の諸実施形態がこうした個別的詳細な四で実施されうることは理解される。他方、よく知られた回路、構造および技法は、本記述の理解を埋没させないために詳細に示しはしなかった。

【0009】

本明細書における「一つの実施形態」、「ある実施形態」、「例示的な実施形態」などへの言及は、記載される実施形態が特定の特徴、構造または特性を含みうることを示すが、すべての実施形態が必ずその特定の特徴、構造または特性を含むとは限らない。さらに、そのような表現は必ずしも同じ実施形態を指すのではない。さらに、ある特定の特徴、構造または特性がある実施形態との関連で記述されているときは、明示的に記載されているか否かによらず、そのような特徴、構造または特性を、他の実施形態との関連で実施することは当業者の知識の範囲内であることを述べておく。

【0010】

「展開」および「圧縮」命令のいくつかの実施形態ならびにそのような命令を実行するために使用されうるシステム、アーキテクチャ、命令フォーマットなどの実施形態が以下で詳述される。展開および圧縮は、AoSおよびSoA配置の変換を含め、いくつかの異なる領域で有益である。たとえば、XYZW XYZW XYZW…XYZWというパターンからXXXXXXXX YYYYYYYY ZZZZZZZZZZ WWWWWWWWのたぐいのパターンに移行する。もう一つのそのような領域は行列転置である。長さ16のベクトルは要素の4×4の配列と見ることができる。展開命令により、四つの相続く要素の行M[0]、M[1]、M[2]およびM[3]がフェッチされ、（配列を構築するのを保つためのマージを用いて）4×4配列の行の一つに展開されることができる（たとえばベクトル要素１，３，７および１１）。

【0011】

さらに、動的条件に基づいて相続く諸位置にメモリを記憶する汎用コードは、圧縮および展開命令から裨益する。たとえば、場合によっては、一般的でない条件をもつまれな要素を時間的メモリ・スペース中に圧縮することが有利である。それらを一緒にパックして記憶しておくことは、計算の密度を増す。それを行う一つの方法は、下記で詳述する圧縮の使用を通じてである。時間的なメモリ・スペース（またはFIFO）を処理したのち、それらのまれな要素をもとの位置に復元するために展開が利用されてもよい。展開は、待ち行列中にパックされたデータを展開し直すためにも使われる。

【0012】

展開（expand）
展開から始めると、展開の実行は、プロセッサに、ソース・オペランド（メモリまたはレジスタ・オペランド）からの相続くデータ要素を宛先オペランド（典型的にはレジスタ・オペランド）中の（疎な）データ要素位置に、書き込みマスク・オペランドによって決定されるアクティブ要素に基づいて書き込ませる。さらに、ソース・オペランドのデータ要素は、そのサイズおよびどのサイズのデータ要素が宛先レジスタ内にあるかに依存して上方変換されてもよい。たとえば、ソース・オペランドがメモリ・オペランドであり、そのデータ要素が16ビットのサイズであり、宛先レジスタのデータ要素が32ビットであれば、宛先に記憶されるべきメモリ・オペランドのデータ要素は32ビットになるよう上方変換される。上方変換およびそれらがどのように命令フォーマット中にエンコードされるかについての例はのちに詳述する。

【0013】

この命令のフォーマットは「VEXPANDPS zmm1{k1} zmm2/U(mem)」である。ここで、zmm1およびzmm2はそれぞれ宛先およびソース・ベクトル・レジスタ・オペランドであり（128、256、512ビット・レジスタなどのような）、k1は書き込みマスク・オペランドであり（16ビット・レジスタのような）、U(mem)はソース・メモリ位置オペランドである。メモリから取得されるものは何であれ、当該メモリ・アドレスから始まる相続くビットの集合であり、宛先レジスタのサイズに依存していくつかのサイズ（128、256、512ビットなど）の一つであってもよい――そのサイズは一般に、宛先レジスタと同じサイズである。いくつかの実施形態では、書き込みマスクは異なるサイズでもある（8ビット、32ビットなど）。さらに、いくつかの実施形態では、書き込みマスクのすべてのビットが命令によって利用されるのではない（たとえば、低位の８個の最下位ビットだけが使われる）。もちろん、VEXPANDPSは命令のオペコードである。典型的には、各オペランドは命令において明示的に定義される。データ要素のサイズは、後述する「W」のようなデータ粒度ビットの指示の使用を通じてなど、命令の「プレフィックス」において定義されてもよい。たいていの実施形態では、Wは、各データ要素が32ビットまたは64ビットであることを示す。データ要素が32ビットのサイズであり、ソースが512ビットのサイズであれば、ソース当たり16個のデータ要素がある。

【0014】

この命令は、通常、書き込みマスクされる。それにより、対応するビットが書き込みマスク・レジスタ（上記の例ではk1）においてセットされている要素のみが宛先レジスタにおいて修正される。対応するビットが書き込みマスク・レジスタにおいてクリアである宛先レジスタ中の要素は前の値を保持する。しかしながら、書き込みマスクを使わないとき（またはすべて1にセットされた書き込みマスクを使うとき）、この命令は、メモリ参照がキャッシュライン・スプリットを生じる高い確信がある、より高いパフォーマンスのベクトル・ロードについて使われてもよい。

【0015】

展開命令の実行の一例が図１に示されている。この例では、ソースはメモリは、RAXレジスタ中に見出されるアドレスにおいてアドレッシングされる。もちろん、メモリ・アドレスは、他のレジスタ中に記憶されていても、あるいは命令中の直定数（immediate）として見出されてもよい。この例での書き込みマスクは0x4DB1として示されている。「1」の値をもつ書き込みマスクの各ビット位置について、メモリ・ソースからのデータ要素は宛先レジスタにおいて対応する位置のところに記憶される。たとえば、書き込みマスクの第一の位置（たとえばk2[0]）が「1」であり、このことは、対応する宛先データ要素位置（たとえば宛先レジスタの第一のデータ要素）がそこに記憶されているソース・メモリからのデータ要素をもつことを示す。この場合、それはRAXアドレスに関連付けられたデータ要素となる。マスクの次の三つのビットは「0」であり、これは宛先レジスタの対応するデータ要素がそのままにされることを示す（図では「Y」として示されている）。書き込みマスク中の次の「1」の値は第五のビット位置（たとえばk2[4]）にある。これは、RAXレジスタに関連付けられたデータ要素のあとの（それに連続する）データ要素が宛先レジスタの第五のデータ要素スロットに記憶されるべきであることを示す。残りの書き込みマスク・ビット位置は、メモリ・ソースのどのさらなるデータ要素が宛先レジスタ内に記憶されるべきかを決定するために使用される（この例では、８個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい）。さらに、メモリ・ソースからのデータ要素は、宛先における記憶に先立って16ビットの浮動小数点値から32ビット値に移行するなど、宛先のデータ要素サイズにフィットするよう上方変換されてもよい。上方変換およびそれらをいかにして命令フォーマット中にエンコードするかの例は上記で詳述した。さらに、いくつかの実施形態では、メモリ・オペランドの相続くデータ要素が展開に先立ってレジスタ中に保存される。

【0016】

図２は、レジスタ・オペランドをソースとする展開命令の実行の例を示している。先の図と同様に、この例での書き込みマスクは0x4DB1である。「1」の値をもつ書き込みマスクの各ビット位置について、レジスタ・ソースからのデータ要素が対応する位置において宛先レジスタ内に記憶される。たとえば、書き込みマスクの第一の位置（たとえばk2[0]）が「1」であり、このことは、対応する宛先データ要素位置（たとえば宛先レジスタの第一のデータ要素）がそこに記憶されているソース・レジスタからのデータ要素をもつことを示す。この場合、それはソース・レジスタの第一のデータ要素となる。マスクの次の三つのビットは「0」であり、これは宛先レジスタの対応するデータ要素がそのままにされることを示す（図では「Y」として示されている）。書き込みマスク中の次の「1」の値は第五のビット位置（たとえばk2[4]）にある。これは、ソース・レジスタの第一の記憶されたデータのあとの（それに連続する）データ要素が宛先レジスタの第五のデータ要素スロットに記憶されるべきであることを示す。残りの書き込みマスク・ビット位置は、レジスタ・ソースのどのさらなるデータ要素が宛先レジスタ内に記憶されるべきかを決定するために使用される（この例では、８個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい）。

【0017】

図３は、展開命令を実行するための擬似コードの例を示している。

【0018】

図４は、プロセッサ中の展開命令の使用のある実施形態を示している。宛先オペランド、ソース・オペランド（メモリまたはレジスタ）、書き込みマスクおよびオフセット（もし含まれていれば）をもつ展開命令が４０１においてフェッチされる。いくつかの実施形態では、宛先オペランドは512ビットのベクトル・レジスタであり（ZMM1のような）、書き込みマスクは16ビットのレジスタである（k1のような）。メモリ・ソース・オペランドがある場合、それはアドレス（もしくはその一部）を記憶するレジスタまたはアドレスもしくはその一部を表す直定数であってもよい。典型的には、宛先およびソース・オペランドは同じサイズである。いくつかの実施形態では、それらはみな512ビットのサイズである。しかしながら、他の実施形態では、それらはみな128または256ビットのような異なるサイズであってもよい。

【0019】

展開命令は４０３においてデコードされる。命令のフォーマットに依存して、多様なデータがこの段階で解釈されうる。上方変換（もしくは他のデータ変換）があるべきか、どのレジスタに書き込みをし、どのレジスタを取り出すか、メモリ・アドレスはソースからの何かなど。

【0020】

ソース・オペランド値が４０５において取り出される／読み出される。たいていの実施形態では、メモリ・ソース位置アドレスおよび相続く（その後の）アドレス（およびそのデータ要素）に関連付けられたデータ要素がこの時点で読み出される。（たとえば、キャッシュライン全体が読み出される。）ソースがレジスタである諸実施形態では、ソースはこの時点で読み出される。

【0021】

実行されるべき何らかのデータ要素変換（上方変換など）があれば、それは４０７において実行されてもよい。たとえば、メモリからの16ビット・データ要素は32ビット・データ要素に上方変換されてもよい。

【0022】

展開命令（またはマイクロオペレーションのようなそのような命令を含む処理）が４０９において実行リソースによって実行される。この実行により、ソース・オペランドからのどの値が疎なデータ要素として宛先に記憶されるべきかが、書き込みマスクの「アクティブ」な要素（ビット位置）に基づいて決定される。そのような決定の例を図１および図２に示した。

【0023】

ソース・オペランドの適切なデータ要素が宛先レジスタ中に、書き込みマスクの「アクティブ」な要素に対応する位置において、４１１で記憶される。ここでもまた、この例は図１および図２に示されている。４０９および４１１は別個に図示したが、いくつかの実施形態では、それらは前記命令の実行の一部として一緒に実行される。

【0024】

図５は、展開命令を処理する方法のある実施形態を示している。この実施形態では、処理４０１〜４０７の全部ではないまでもいくつかが以前に実行されたことが想定される。だが、それらは以下に呈示する詳細を埋没させないよう、示されていない。たとえば、フェッチおよびデコードは示されていないし、オペランド（ソースおよび書き込みマスク）取り出しも示されていない。

【0025】

５０１では、第一のビット位置における書き込みマスクが、対応するソース位置が宛先レジスタの対応するデータ要素位置に記憶されるべきかの決定がなされる。たとえば、第一の位置における書き込みマスクは、宛先レジスタの第一のデータ要素位置がソースからの値（この場合、ソース・オペランドを通じてアクセスされる相続くデータ要素のうち第一のデータ要素）で上書きされるべきであることを示す「1」のような値をもつか？
この第一のビット位置における書き込みマスクが宛先レジスタにおける変化があるべきであることを示さないときは、書き込みマスクにおける次のビット位置が評価され、何の変更もされない。第一のビット位置における書き込みマスクが宛先の第一のデータ要素位置における変化があるべきであることを示すときは、第一のソース・データ要素（たとえば、メモリ位置またはソース・レジスタの最下位のデータ要素）が５０７において第一のデータ要素位置に記憶される。実装に依存して、５０５では、メモリ・データ要素は、宛先のデータ要素サイズに変換される。これは、５０１の評価の前に行われていてもよい。宛先レジスタ中に書き込まれてもよい、ソースからのその後の（連続する）データ要素が５１１で準備される。

【0026】

評価された書き込みマスク位置が書き込みマスクの最後であったかどうかまたは宛先のデータ要素位置のすべてが満たされたかどうかの判定が５１３においてなされる。もし真であれば、処理は終了である。

【0027】

真でなければ、５１５における書き込みマスク中の次のビット位置が評価されることになる。この評価は５０３で行われ、５０１の判定と同様であるが、書き込みマスクの第一のビット位置についてではない。判定が肯定であれば、データ要素は記憶などされる（５０７、５０９および５１１）。判定が否定であれば、宛先のデータ要素は５０５においてそのままにされる。

【0028】

さらに、この図および上記の記述はそれぞれの第一の位置が最下位であると考えているが、いくつかの実施形態では、第一の位置は最上位である。

【0029】

圧縮（compress）
圧縮命令の実行は、プロセッサに、ソース・オペランド（典型的にはレジスタ・オペランド）からのデータ要素を宛先オペランド（メモリまたはレジスタ・オペランド）中の相続く要素中に、書き込みマスク・オペランドによって決定されるアクティブな要素に基づいて、記憶（パック）させる。さらに、ソース・オペランドのデータ要素は、そのサイズおよびソースがメモリである場合にどのサイズのデータ要素があるかに依存して、下方変換されてもよい。たとえば、メモリ・オペランドのデータ要素が16ビットのサイズであり、ソース・レジスタのデータ要素が32ビットであれば、メモリに記憶されるべきレジスタのデータ要素は16ビットになるよう下方変換される。下方変換およびそれらがどのように命令フォーマット中にエンコードされるかについての例はのちに詳述する。圧縮の実行は、要素整列されたアドレスにおいて始まって論理的にマップされたバイト／語／倍長語のストリームを生成するものと見ることもできる。マスクによって無効にされる要素はストリームに加えられないので、ストリームの長さは書き込みマスクに依存する。圧縮は典型的には、疎なデータを待ち行列中に圧縮するために使われる。さらに、書き込みマスクを使わないとき（またはすべて1にセットされた書き込みマスクを使うとき）、この命令は、メモリ参照がキャッシュライン・スプリットを生じる高い確信がある、より高いパフォーマンスのベクトル・ストアについて使われてもよい。

【0030】

この命令のフォーマットは「VCOMPRESSPS zmm2/mem{k1},D(zmm1)」である。ここで、zmm1およびzmm2はそれぞれソースおよび宛先ベクトル・レジスタ・オペランドであり（128、246、512ビット・レジスタのような）、k1は書き込みマスク・オペランドであり（16ビット・レジスタのような）、memはメモリ位置である。前記命令に含まれるメモリ・オペランドについてのオフセットもあってもよい。メモリに記憶されるものは何であれ、当該メモリ・アドレスから始まる相続くビットの集合であり、いくつかのサイズ（128、256、512ビットなど）の一つであってもよい。いくつかの実施形態では、書き込みマスクは異なるサイズでもある（8ビット、32ビットなど）。さらに、いくつかの実施形態では、書き込みマスクのすべてのビットが命令によって利用されるのではない（たとえば、低位の８個の最下位ビットだけが使われる）。もちろん、VCOMPRESSPSは命令のオペコードである。典型的には、各オペランドは命令において明示的に定義される。データ要素のサイズは、本稿で記述する「W」のようなデータ粒度ビットの指示の使用を通じてなど、命令の「プレフィックス」において定義されてもよい。たいていの実施形態では、Wは、各データ要素が32ビットまたは64ビットであることを示す。データ要素が32ビットのサイズであり、ソースが512ビットのサイズであれば、ソース当たり16個のデータ要素がある。

【0031】

プロセッサにおける圧縮命令の実行の一例が図６に示されている。この例では、宛先メモリは、RAXレジスタ中に見出されるものに関連付けられたアドレスにおいてアドレッシングされる。もちろん、メモリ・アドレスは、他のレジスタ中に記憶されていても、あるいは命令中の直定数（immediate）として見出されてもよい。この例での書き込みマスクは0x4DB1である。書き込みマスクが「1」の値をもつ各インスタンスについて、ソース（ZMMレジスタのような）からのデータ要素はメモリ中に相続いて記憶（パック）される。たとえば、書き込みマスクの第一の位置（たとえばk2[0]）が「1」であり、このことは、対応するソース・データ要素位置（たとえば宛先レジスタの第一のデータ要素）がメモリ中に書き込まれるべきであることを示す。この場合、それはRAXアドレスに関連付けられたデータ要素として記憶される。マスクの次の三つのビットは「0」であり、これはソース・レジスタの対応するデータ要素がメモリに記憶されないことを示す（図では「Y」として示されている）。書き込みマスク中の次の「1」の値は第五のビット位置（たとえばk2[4]）にある。これは、RAXレジスタに関連付けられたデータ要素のあとの（それに連続する）データ要素位置が、そこに記憶されているソース・レジスタの第五のデータ要素スロットをもつべきであることを示す。残りの書き込みマスク・ビット位置は、ソース・レジスタのどのさらなるデータ要素がメモリ内に記憶されるべきかを決定するために使用される（この例では、８個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい）。さらに、レジスタ・ソースからのデータ要素は、記憶に先立って32ビット浮動小数点値から16ビット値に移行するなど、メモリのデータ要素サイズにフィットするよう下方変換されてもよい。

【0032】

図７は、プロセッサにおける圧縮命令の実行のもう一つの例を示している。この例では、宛先はレジスタである。この例での書き込みマスクはやはり0x4DB1である。書き込みマスクが「1」の値をもつ各インスタンスについて、ソース（ZMMレジスタのような）からのデータ要素が宛先レジスタ中に相続いて記憶（パック）される。たとえば、書き込みマスクの第一の位置（たとえばk2[0]）が「1」であり、このことは、対応するソース・データ要素位置（たとえばソース・レジスタの第一のデータ要素）が宛先レジスタに書き込まれるべきであることを示す。この場合、それは宛先レジスタの第一のデータ要素として記憶される。マスクの次の三つのビットは「0」であり、これはソース・レジスタの対応するデータ要素が宛先レジスタ中に記憶されないことを示す（図では「Y」として示されている）。書き込みマスク中の次の「1」の値は第五のビット位置（たとえばk2[4]）にある。これは、第一のデータ要素のあとの（それに連続する）データ要素位置がそこに記憶されるソース・レジスタの第五のデータ要素スロットをもつべきであることを示す。残りの書き込みマスク・ビット位置は、ソース・レジスタのどのさらなるデータ要素が宛先レジスタ内に記憶されるべきかを決定するために使用される（この例では、８個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい）。

【0033】

図８は、展開命令を実行するための擬似コードの例を示している。

【0034】

図９は、プロセッサ中の圧縮命令の使用のある実施形態を示している。宛先オペランド、ソース・オペランドおよび書き込みマスクをもつ圧縮命令が９０１においてフェッチされる。いくつかの実施形態では、ソース・オペランドは512ビットのベクトル・レジスタであり（ZMM1のような）、書き込みマスクは16ビットのレジスタである（k1のような）。宛先は、レジスタ内にまたは直定数もしくはレジスタ・オペランドとして記憶されるメモリ位置であってもよい。さらに、圧縮命令はメモリ・アドレスについてのオフセットを含んでいてもよい。

【0035】

圧縮命令は９０３においてデコードされる。命令のフォーマットに依存して、多様なデータがこの段階で解釈されうる。下方変換があるべきか、どのレジスタを取り出すか、メモリ・アドレスは宛先オペランドからの何か（そしてもしあればオフセット）など。

【0036】

ソース・オペランド値が９０５において取り出される／読み出される。たとえば、ソース・レジスタの少なくとも第一のデータ要素が読み出される。

【0037】

実行されるべき何らかのデータ要素変換（下方変換など）があれば、それは９０７において実行されてもよい。たとえば、レジスタからの32ビット・データ要素は16ビット・データ要素に下方変換されてもよい。

【0038】

圧縮命令（またはマイクロオペレーションのようなそのような命令を含む処理）が９０９において実行リソースによって実行される。この実行により、ソース・オペランドからのどの値がパックされたデータ要素として宛先にロードされるべきかが、書き込みマスクの「アクティブ」な要素（ビット位置）に基づいて決定される。そのような解析の例を図６に示した。

【0039】

書き込みマスクの「アクティブ」な要素に対応する、ソース・オペランドの適切なデータ要素が、９１１で宛先中に記憶される。ここでもまた、これの例は図６および図７に示されている。９０９および９１１は別個に図示したが、いくつかの実施形態では、それらは前記命令の実行の一部として一緒に実行される。

【0040】

図１０は、圧縮命令を処理する方法のある実施形態の例を示している。この実施形態では、処理９０１〜９０７の全部ではないまでもいくつかが以前に実行されたことが想定される。だが、それらは以下に呈示する詳細を埋没させないよう、示されていない。たとえば、フェッチおよびデコードは示されていないし、オペランド（ソースおよび書き込みマスク）取り出しも示されていない。

【0041】

１００１では、第一のビット位置における書き込みマスクが、対応するソース・データ要素が宛先オペランドによって初期に示される宛先位置（最低位の位置）の中に記憶されるべきかの決定がなされる。たとえば、第一の位置におけるマスクは、ソース・レジスタの第一のデータ要素位置がメモリ中に書き込まれるべきであることを示す「1」のような値をもつか？
この第一のビット位置における書き込みマスクが宛先レジスタにおける変化があるべきであることを示さないときは（第一のデータ要素はソース・レジスタの第一のデータ要素によって不変のままであるべき）、書き込みマスクにおける次のビット位置が評価され（もしそのようなビット位置があれば）、何の変更もされない。第一のビット位置における書き込みマスクが宛先の第一のデータ要素位置における変化があるべきであることを示すときは、１００７において、ソース・データ要素が宛先の第一のデータ要素位置の中に記憶される。実装に依存して、１００５では、ソース・データ要素は、宛先のデータ要素サイズに変換される。これは、１００１の評価の前に行われていてもよい。書き込みされてもよいその後の（連続する）宛先位置が１００９で準備される。

【0042】

評価された書き込みマスク位置が書き込みマスクの最後であったかどうかまたは宛先のデータ要素位置のすべてが満たされたかどうかの判定が１０１１においてなされる。もし真であれば、処理は終了である。真でなければ、１０１３における書き込みマスク中の次のビット位置が評価されることになる。この評価は１００３で行われ、１００１の判定と同様であるが、書き込みマスクの第一のビット位置についてではない。判定が肯定であれば、データ要素は記憶などされる（１００５、１００７および１００９）。

【0043】

さらに、この図および上記の記述はそれぞれの第一の位置が最下位であると考えているが、いくつかの実施形態では、第一の位置は最上位である。

【0044】

上記で詳述した命令の実施形態は、以下で詳述する「汎用ベクトル・フレンドリー命令フォーマット」において具現されてもよい。他の実施形態では、そのようなフォーマットは利用されず、別の命令フォーマットが使われるが、書き込みマスク・レジスタ、さまざまなデータ変換（スウィズル、ブロードキャストなど）、アドレッシングなどの以下の記述は一般に、上記の命令の実施形態の記述に適用可能である。さらに、例示的なシステム、アーキテクチャおよびパイプラインが下記で詳述される。上記の命令の実施形態はそのようなシステム、アーキテクチャおよびパイプライン上で実行されてもよいが、詳述されるものに限定されるものではない。

【0045】

ベクトル・フレンドリー命令フォーマットは、ベクトル命令に好適な命令フォーマットである（たとえば、ベクトル演算に固有のある種のフィールドがある）。ベクトルおよびスカラー処理の両方がベクトル・フレンドリー命令フォーマットを通じてサポートされる実施形態が記述されるが、代替的な実施形態はベクトル・フレンドリー命令フォーマットのベクトル処理のみを使う。

【0046】

例示的な汎用ベクトル・フレンドリー命令フォーマット――図１１Ａ〜Ｂ
図１１Ａ〜Ｂは、本発明の諸実施形態に基づく、汎用ベクトル・フレンドリー命令フォーマットおよびその命令テンプレートを示すブロック図である。図１１Ａは、本発明の諸実施形態に基づく、汎用ベクトル・フレンドリー命令フォーマットおよびそのクラスＡ命令テンプレートを示すブロック図であり、一方、図１１Ｂは、本発明の諸実施形態に基づく、汎用ベクトル・フレンドリー命令フォーマットおよびそのクラスＢ命令テンプレートを示すブロック図である。具体的には、汎用ベクトル・フレンドリー命令フォーマット１１００について、クラスＡおよびクラスＢ命令テンプレートが定義されており、その両方は、メモリ・アクセスなし１１０５命令テンプレートおよびメモリ・アクセス１１２０命令テンプレートを含む。ベクトル・フレンドリー命令フォーマットのコンテキストにおける汎用（generic）という用語は、いかなる特定の命令セットにも結び付けられていない命令フォーマットをいう。ベクトル・フレンドリー命令フォーマット中の命令が、レジスタ（メモリ・アクセスなし１１０５命令テンプレート）またはレジスタ／メモリ（メモリ・アクセス１１２０命令テンプレート）のいずれかをソースとするベクトルに対して作用する実施形態が記述されるが、本発明の代替的な実施形態はこれらの一つのみをサポートしてもよい。また、ベクトル命令フォーマット中にロードおよびストア命令がある本発明の実施形態が記述されるが、代替的な実施形態はその代わりにまたはそれに加えて、ベクトルをレジスタに入れたり出したりする（たとえばメモリからレジスタに、レジスタからメモリに、レジスタ間の移動）異なる命令フォーマット中の命令を有する。さらに、二つのクラスの命令テンプレートをサポートする本発明の実施形態が記述されるが、代替的な実施形態はこれらの一方のみまたは三つ以上をサポートしてもよい。

【0047】

ベクトル・フレンドリー命令フォーマットが以下をサポートする本発明の実施形態が記述される：すなわち、64バイトのベクトル・オペランド長（またはサイズ）と32ビット（4バイト）もしくは64ビット（8バイト）のデータ要素幅（またはサイズ）（よって、64バイトのベクトルは16個の倍長語サイズの要素または代替的に8個の四倍長語サイズの要素からなる）；64バイトのベクトル・オペランド長（またはサイズ）と16ビット（2バイト）もしくは8ビット（1バイト）のデータ要素幅（またはサイズ）；32バイトのベクトル・オペランド長（またはサイズ）と32ビット（4バイト）、64ビット（8バイト）、16ビット（2バイト）もしくは8ビット（1バイト）のデータ要素幅（またはサイズ）；ならびに16バイトのベクトル・オペランド長（またはサイズ）と32ビット（4バイト）、64ビット（8バイト）、16ビット（2バイト）もしくは8ビット（1バイト）のデータ要素幅（またはサイズ）がサポートされる。だが、代替的な実施形態は、より多くの、より少数のおよび／または異なるベクトル・オペランド・サイズ（たとえば1156バイトのベクトル・オペランド）と、より多くの、より少数のおよび／または異なるデータ要素幅（たとえば128ビット（16バイト）のデータ要素幅）をサポートしてもよい。

【0048】

図１１ＡにおけるクラスＡ命令テンプレートは：１）メモリ・アクセスなし１１０５命令テンプレート内には、メモリ・アクセスなしのフル丸め制御型の処理１１１０命令テンプレートと、メモリ・アクセスなしのデータ変換型の処理１１１５命令テンプレートが示されており；２）メモリ・アクセス１１２０命令テンプレート内には、メモリ・アクセスの時間的１１２５命令テンプレートと、メモリ・アクセスの非時間的１１３０命令テンプレートが示されている。図１１ＢにおけるクラスＢ命令テンプレートは：１）メモリ・アクセスなし１１０５命令テンプレート内には、メモリ・アクセスなしの書き込みマスク制御の部分丸め制御型処理１１１２命令テンプレートと、メモリ・アクセスなしの書き込みマスク制御、vsize型の処理１１１７命令テンプレートが示されており；２）メモリ・アクセス１１２０命令テンプレート内には、メモリ・アクセスの書き込みマスク制御１１２７命令テンプレートが示されている。

【0049】

フォーマット
汎用ベクトル・フレンドリー命令フォーマット１１００は、図１１Ａ〜１１Ｂに示されている順で下記に挙げる以下のフィールドを含む。

【0050】

フォーマット・フィールド１１４０――このフィールド内の特定の値（命令フォーマット識別子値）はベクトル・フレンドリー命令フォーマットを、よって命令ストリームにおけるベクトル・フレンドリー命令フォーマット中の命令の発生を一意的に同定する。よって、フォーマット・フィールド１１４０の内容は第一の命令フォーマット中の命令の発生を、他の命令フォーマット中の命令の発生から区別し、それによりベクトル・フレンドリー命令フォーマットの、他の命令フォーマットをもつ命令セット中への導入を許容する。よって、このフィールドは、汎用ベクトル・フレンドリー命令フォーマットのみをもつ命令セットについては必要とされないという意味で任意的である。

【0051】

基本処理フィールド１１４２――その内容は、種々の基本処理を区別する。本稿で後述するように、基本処理フィールド１１４２は、オペコード・フィールドを含むおよび／またはオペコード・フィールドの一部であってもよい。

【0052】

レジスタ・インデックス・フィールド１１４４――その内容は、直接的にまたはアドレス生成を通じて、レジスタ内であれメモリ内であれソースおよび宛先オペランドの位置を指定する。これらは、PxQ（たとえば32×1312）レジスタ・ファイルからN個のレジスタを選択するのに十分な数のビットを含む。ある実施形態ではNは三つまでのソースおよび一つの宛先レジスタであってもよいが、代替的な実施形態はより多数またはより少数のソースおよび宛先レジスタをサポートしてもよい（たとえば、二つまでのソースをサポートして該ソースの一つが宛先としても機能するのでもよいし、三つまでのソースをサポートして該ソースの一つが宛先としても機能するのでもよいし、二つまでのソースおよび一つの宛先をサポートしてもよい）。ある実施形態ではP＝32だが、代替的な実施形態はより多数またはより少数のレジスタ（たとえば16）をサポートしてもよい。ある実施形態ではQ＝1312ビットだが、代替的な実施形態はより多数またはより少数のビットをサポートしてもよい（たとえば128、1024）。

【0053】

修正子フィールド１１４６――その内容は、メモリ・アクセスを指定する汎用ベクトル命令フォーマット中の命令の発生を、メモリ・アクセスを指定しない命令の発生から区別する。すなわち、メモリ・アクセスなし１１０５命令テンプレートとメモリ・アクセス１１２０命令テンプレートとの間の区別をする。メモリ・アクセス処理は、メモリ階層構造に読み出しおよび／または書き込みをする（いくつかの場合には、レジスタ内の値を使ってソースおよび／または宛先アドレスを指定する）。一方、非メモリ・アクセス処理はそれをしない（たとえばソースおよび宛先がレジスタである）。ある実施形態ではこのフィールドはメモリ・アドレス計算を実行する三つの異なる方法の間の選択もするが、代替的な実施形態は、メモリ・アドレス計算を実行するためのより多数、より少数または異なる方法をサポートしてもよい。

【0054】

増強処理フィールド１１５０――その内容は、多様な異なる処理のうちどの一つが基本処理に加えて実行されるべきであるかを区別する。このフィールドはコンテキスト固有である。本発明のある実施形態では、このフィールドは、クラス・フィールド１１６８、アルファ・フィールド１１５２およびベータ・フィールド１１５４に分割される。増強処理フィールドは、２個、３個または４個の命令ではなく、単一の命令において実行されるべき処理の共通グループを許容する。下記は、必要とされる命令の数を減らすために増強フィールド１１５０を使う命令（その命名法は本稿でのちにより詳しく述べる）のいくつかの例である。

【0055】

【表1】

ここで、[rax]はアドレス生成に使われるべき基本（base）ポインタであり、{ }はデータ操作フィールド（本稿でのちにより詳しく述べる）によって指定される変換処理を示す。

【0056】

スケール（scale）・フィールド１１６０――その内容は、メモリ・アドレス生成のためのインデックス（index）・フィールドの内容のスケーリングを許容する（たとえば、2^scale×index＋baseを使うアドレス生成について）。

【0057】

変位（displacement）フィールド１１６２Ａ――その内容は、メモリ・アドレス生成の一部として使われる（たとえば、2^scale×index＋base＋displacementを使うアドレス生成について）。

【0058】

変位因子フィールド１１６２Ｂ（変位因子フィールド１１６２Ｂのすぐ上に変位フィールド１１６２Ａを並置しているのは、一方または他方のどちらかが使われることを示すことに注意）――その内容はアドレス生成の一部として使われる；メモリ・アクセスのサイズ（N）によってスケーリングされるべき変位因子を指定する――ここで、Nはメモリ・アクセスにおけるバイト数である（たとえば、2^scale×index＋base＋displacementを使うアドレス生成について）。冗長な低位ビットは無視され、よって、実効アドレスを計算する際に使うべき最終的な変位を生成するために、変位因子フィールドの内容はメモリ・オペランド全サイズ（N）を乗算される。Nの値は、フル・オペコード・フィールド１１７４（本稿で後述）およびデータ操作フィールド１１５４Ｃ（本稿で後述）に基づいてランタイムでプロセッサ・ハードウェアによって決定される。変位フィールド１１６２Ａおよび変位因子フィールド１１６２Ｂは、メモリ・アクセスなし１１０５命令テンプレートについては使用されない、および／または異なる実施形態は両者のうち一方だけを実装したりいずれも実装しなかったりしてもよいという意味で任意的である。

【0059】

データ要素幅フィールド１１６４――その内容はいくつかのデータ要素幅のどの一つが使用されるべきかを区別する（いくつかの実施形態では、すべての命令について；他の実施形態では、命令のうちいくつかのみについて）。このフィールドは、一つのデータ要素幅だけがサポートされるおよび／または諸データ要素幅がオペコードの何らかの側面を使ってサポートされる場合には必要とされないという意味で任意的である。

【0060】

書き込みマスク・フィールド１１７０――その内容は、データ要素位置ごとに、宛先ベクトル・オペランド中のそのデータ要素位置が基本処理および増強処理の結果を反映するかどうかを制御する。クラスＡ命令テンプレートは併合書き込みマスクをサポートし、一方、クラスＢ命令テンプレートは併合（merging）および零化（zeroing）書き込みマスクの両方をサポートする。併合するときは、ベクトル・マスクは、宛先中の要素の任意の集合が、（基本処理および増強処理によって指定される）何らかの処理の実行中の更新から保護されることを許容する；他の一つの実施形態では、対応するマスク・ビットが0をもつところでは宛先の各要素の古い値を保持する。対照的に、零化するときは、ベクトル・マスクは、宛先中の要素の任意の集合が、（基本処理および増強処理によって指定される）何らかの処理の実行中にゼロにされることを許容する；ある実施形態では、対応するマスク・ビットが0値をもつときには宛先の各要素が0に設定される。この機能のサブセットは、実行されている処理のベクトル長さ（すなわち、最初のものから最後のものへの、修正されている要素のスパン）を制御する能力である；しかしながら、修正される要素が連続していることは必要ではない。このように、書き込みマスク・フィールド１１７０は、ロード、ストア、算術、論理などを含む部分ベクトル処理を許容する。また、このマスキングは、障害抑制（fault suppression）のために使われることができる（すなわち、障害を引き起こしうる／引き起こす何らかの処理の結果の受領を防止するために宛先のデータ要素位置をマスクすることによる――たとえばメモリ中のあるベクトルがページ境界をまたぎ、最初のページがページ障害（page fault）を引き起こすが、第二のページは引き起こさないとする。ページ障害は、最初のページにある当該ベクトルのすべてのデータ要素が書き込みマスクによってマスクされるならば無視できる）。さらに、書き込みマスクは、ある型の条件付き文を含む「ベクトル化ループ」を許容する。書き込みマスク・フィールド１１７０の内容がいくつかの書き込みマスク・レジスタのうち使用されるべき書き込みマスクを含む一つを選択する（よって書き込みマスク・フィールド１１７０の書き込みマスク・レジスタが間接的に実行されるべきマスキングを同定する）本発明の実施形態が記述されているが、代替的な実施形態はその代わりにまたはそれに加えて、書き込みマスク・フィールド１１７０の内容が直接的に実行されるべきマスキングを指定することを許容する。さらに、零化は次の場合にパフォーマンス改善を許容する。１）宛先オペランドがソースを兼ねていない命令（非三元命令ともいう）に対してレジスタ名称変更が使われるとき。レジスタ名称変更パイプライン段の間、宛先はもはや暗黙的なソースではないからである（現在の宛先レジスタからのデータ要素が名称変更された宛先レジスタにコピーされたり、あるいは何らかの仕方で処理とともに担持される必要がない。処理の結果ではないデータ要素（任意のマスクされたデータ要素）は零化されるので）。２）書き戻し段の間。ゼロが書き込まれるからである。

【0061】

直定数（immediate）フィールド１１７２――その内容は、直定数の指定を許容する。このフィールドは、直定数をサポートしない汎用ベクトル・フレンドリー・フォーマットの実装においては存在せず、直定数を使わない命令においては存在しないという意味で任意的である。

【0062】

命令テンプレート・クラス選択
クラス・フィールド１１６８――その内容は命令の異なるクラスの間の区別をする。図２Ａ〜２Ｂを参照するに、このフィールドの内容は、クラスＡ命令とクラスＢ命令の間の選択をする。図１１Ａ〜１１Ｂでは、特定の値がフィールドに存在していることを示すために角丸の四角が使われている（たとえば、それぞれ図１１Ａ〜１１Ｂにあるクラス・フィールド１１６８についてのクラスＡ １１６８ＡおよびクラスＢ １１６８Ｂ）。

【0063】

クラスＡのメモリ・アクセスなし命令テンプレート
クラスＡの非メモリ・アクセス１１０５命令テンプレートの場合、アルファ・フィールド１１５２はRSフィールド１１５２Ａとして解釈され、その内容は種々の増強処理型のどの一つが実行されるべきかを区別する（たとえば、メモリ・アクセスなしの丸め型処理１１１０およびメモリ・アクセスなしのデータ変換型処理１１１５命令テンプレートについて、丸め１１５２Ａ．１およびデータ変換１１５２Ａ．２がそれぞれ指定されている）。一方、ベータ・フィールド１１５４は、指定された型の処理のどれが実行されるべきかを区別する。図１１では、特定の値が存在していることを示すために角丸のブロックが使われている（たとえば、修正子フィールド１１４６内のメモリ・アクセスなし１１４６Ａ；アルファ・フィールド１１５２／rsフィールド１１５２Ａについての丸め１１５２Ａ．１およびデータ変換１１５２Ａ．２）。メモリ・アクセスなし１１０５命令テンプレートでは、スケール・フィールド１１６０、変位フィールド１１６２Ａおよび変位スケール・フィールド１１６２Ｂは存在しない。

【0064】

メモリ・アクセスなし命令テンプレート――フル丸め制御型動作
メモリ・アクセスなしのフル丸め制御型処理１１１０命令テンプレートでは、ベータ・フィールド１１５４は丸め制御フィールド１１５４Ａとして解釈され、その内容は、静的な丸めを指定する。本発明の記載される実施形態では、丸め制御フィールド１１５４Ａは、全浮動小数点例外抑制（SAE: suppress all floating point exceptions）フィールド１１５６および丸め処理制御フィールド１１５８を含むが、代替的な実施形態は、これらの概念両方を同じフィールドにエンコードすること、あるいはこれらの概念／フィールドの一方または他方のみを有することをサポートしてもよい（たとえば丸め処理制御フィールド１１５８のみを有していてもよい）。

【0065】

SAEフィールド１１５６――その内容は、例外イベント報告を無効にするか否かを区別する。SAEフィールド１１５６の内容が抑制が有効にされていることを示すとき、所与の命令はいかなる種類の浮動小数点例外フラグも報告せず、いかなる浮動小数点例外ハンドラも立ち上げない。

【0066】

丸め処理制御フィールド１１５８――その内容は、一群の丸め処理（たとえば、切り上げ、切り下げ、0に近いほうへの丸めおよび直近への丸め）のうちどの一つを実行すべきかを区別する。こうして、丸め処理制御フィールド１１５８は、命令ごとに丸めモードの変更を許容し、これが必要なときにきわめて有用である。プロセッサが丸めモードを指定するための制御レジスタを含む本発明のある実施形態では、丸め処理制御フィールド１１５０の内容はレジスタ値をオーバーライドする（そのような制御レジスタ上で保存‐修正‐復元を実行する必要なしに丸めモードを選ぶことができるのは有利である）。

【0067】

メモリ・アクセスなし命令テンプレート――データ変換型処理
メモリ・アクセスなしデータ変換型処理１１１５命令テンプレートでは、ベータ・フィールド１１５４はデータ変換フィールド１１５４Ｂとして解釈され、その内容はいくつかのデータ変換のうちどの一つが実行されるべきかを区別する（たとえばデータ変換なし、スウィズル、ブロードキャスト）。

【0068】

クラスＡのメモリ・アクセス命令テンプレート
クラスＡのメモリ・アクセス１１２０命令テンプレートの場合、アルファ・フィールド１１５２は放逐ヒント（eviction hint）フィールド１１５２Ｂとして解釈され、その内容は放逐ヒントのどの一つが使用されるべきかを区別する（図１１Ａでは、メモリ・アクセスの時間的１１２５命令テンプレートおよびメモリ・アクセスの非時間的１１３０命令テンプレートについて、時間的１１５２Ｂ．１および非時間的１１５２Ｂ．２がそれぞれ指定されている）。一方、ベータ・フィールド１１５４は、データ操作フィールド１１５４Ｃとして解釈され、その内容はいくつかのデータ操作処理（プリミティブとしても知られる）のどの一つが実行されるべきかを区別する（たとえば、操作なし；ブロードキャスト；ソースの上方変換；および宛先の下方変換）。メモリ・アクセス１１２０命令テンプレートはスケール・フィールド１１６０を含み、任意的に、変位フィールド１１６２Ａまたは変位スケール・フィールド１１６２Ｂを含む。

【0069】

ベクトル・メモリ命令は、メモリからのベクトル・ロードおよびメモリへのベクトル・ストアを実行し、変換サポートがある。通常のベクトル命令と同様に、ベクトル・メモリ命令は、データ要素ごとの仕方で、メモリから／メモリへデータを転送する。実際に転送される要素は、書き込みマスクとして選択されるベクトル・マスクの内容によって指定される。図１１Ａでは、特定の値がフィールドに存在していることを示すために角丸の四角が使われている（たとえば、修正子フィールド１１４６のためのメモリ・アクセス１１４６Ｂ；アルファ・フィールド１１５２／放逐ヒント・フィールド１１５２Ｂについての時間的１１５２Ｂ．１および非時間的１１５２Ｂ．２）。

【0070】

メモリ・アクセス命令テンプレート――時間的
時間的（temporal）データは、キャッシュすることから裨益するのに十分早く再使用される可能性が高いデータである。しかしながら、これはヒントであり、異なるプロセッサは、該ヒントを完全に無視することを含め、これを異なる仕方で実装してもよい。

【0071】

メモリ・アクセス命令テンプレート――非時間的
非時間的（non-temporal）データは、第一レベルのキャッシュにキャッシュすることから裨益するのに十分早く再使用される可能性が高くないデータであり、放逐のために優先されるべきである。しかしながら、これはヒントであり、異なるプロセッサは、該ヒントを完全に無視することを含め、これを異なる仕方で実装してもよい。

【0072】

クラスＢの命令テンプレート
クラスＢの命令テンプレートの場合、アルファ・フィールド１１５２は書き込みマスク制御（Ｚ）フィールド１１５２Ｃとして解釈され、その内容は、書き込みマスク・フィールド１１７０によって制御される書き込みマスクが併合または零化のどちらであるべきかを区別する。

【0073】

クラスＢのメモリ・アクセスなし命令テンプレート
クラスＢの非メモリ・アクセス１１０５命令テンプレートの場合、ベータ・フィールド１１５４の一部がRLフィールド１１７５Ａとして解釈され、その内容は種々の増強処理型のどの一つが実行されるべきかを区別する（たとえば、丸め１１５７Ａ．１とベクトル長（VSIZE）１１５７Ａ．２はそれぞれ、メモリ・アクセスなしの書き込みマスク制御の部分丸め制御型処理１１１２命令テンプレートと、メモリ・アクセスなしの書き込みマスク制御のVSIZE型処理１１１７命令テンプレートとについて指定される）。一方、ベータ・フィールド１１５４の残りは、指定された型の処理のどれが実行されるべきかを区別する。図１１では、特定の値が存在することを示すために、角丸のブロックが使われている（たとえば、修正子フィールド１１４６内のメモリ・アクセスなし１１４６Ａ；RLフィールド１１５７Ａについての丸め１１５７Ａ．１およびVSIZE １１５７Ａ．２）。メモリ・アクセスなし１１０５命令テンプレートでは、スケール・フィールド１１６０、変位フィールド１１６２Ａおよび変位スケール・フィールド１１６２Ｂは存在しない。
メモリ・アクセスなし命令テンプレート――書き込みマスク制御、部分丸め制御型処理
メモリ・アクセスなしの書き込みマスク制御の部分丸め制御型処理１１１０命令テンプレートでは、ベータ・フィールド１１５４の残りは丸め処理フィールド１１５９Ａとして解釈され、例外イベント報告が無効化される（所与の命令がいかなる種類の浮動小数点例外フラグも報告せず、いかなる浮動小数点例外ハンドラも立ち上げない）。

【0074】

丸め処理制御フィールド１１５９Ａ――丸め処理制御フィールド１１５８と同様に、その内容は、一群の丸め処理のうちどの一つを実行すべきか（たとえば、切り上げ、切り下げ、0に近いほうへの丸めおよび直近への丸め）を区別する。こうして、丸め処理制御フィールド１１５９Ａは、命令ごとに丸めモードの変更を許容し、これが必要なときにきわめて有用である。プロセッサが丸めモードを指定するための制御レジスタを含む本発明のある実施形態では、丸め処理制御フィールド１１５０の内容はレジスタ値をオーバーライドする（そのような制御レジスタ上で保存‐修正‐復元を実行する必要なしに丸めモードを選ぶことができるのは有利である）。

【0075】

メモリ・アクセスなし命令テンプレート――書き込みマスク制御、VSIZE型処理
メモリ・アクセスなし書き込みマスク制御VSIZE型処理１１１７命令テンプレートでは、ベータ・フィールド１１５４の残りはベクトル長フィールド１１５９Ｂとして解釈され、その内容はいくつかのデータ・ベクトル長のうちどの一つが実行対象とされるべきかを区別する（たとえば128、1156または1312バイト）。

【0076】

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

【0077】

フィールドに関する追加的コメント
汎用ベクトル・フレンドリー命令フォーマット１１００に関し、フォーマット・フィールド１１４０、基本処理フィールド１１４２およびデータ要素幅フィールド１１６４を含むフル・オペコード・フィールド１１７４が示されている。フル・オペコード・フィールド１１７４がこれらのフィールドのすべてを含む一つの実施形態が示されているが、フル・オペコード・フィールド１１７４は、そのすべてをサポートするのでない実施形態では、これらのフィールドの全部より少ないものを含む。

【0078】

増強処理フィールド１１５０、データ要素幅フィールド１１６４および書き込みマスク・フィールド１１７０は、これらの機能が、汎用ベクトル・フレンドリー命令フォーマットにおいて命令ごとに使用されることを許容する。

【0079】

書き込みマスク・フィールドおよびデータ要素幅フィールドの組み合わせは、種々のデータ要素幅に基づいてマスクが適用されることを許容するという意味で、型のある（typed）命令を生成する。

【0080】

前記命令フォーマットは、種々のフィールドを他のフィールドの内容に基づいて種々の目的のために再利用するので、比較的少数のビットを必要とする。たとえば、一つのパースペクティブは、修正子フィールドの内容が、図１１Ａ〜１１Ｂ上のメモリ・アクセスなし１１０５命令テンプレートと、図１１Ａ〜１１Ｂ上のメモリ・アクセス１１２５０命令テンプレートとの間の選択をするというものである；一方、クラス・フィールド１１６８の内容は、それら非メモリ・アクセス１１０５命令テンプレート内では、図１１Ａの命令テンプレート１１１０／１１１５と図１１Ｂの１１１２／１１１７との間で選択をする；また一方では、クラス・フィールド１１６８の内容は、それらメモリ・アクセス１１２０命令テンプレート内では、図１１Ａの命令テンプレート１１２５／１１３０と図１１Ｂの１１２７との間で選択をする。もう一つのパースペクティブからは、クラス・フィールド１１６８の内容は、それぞれ図１１Ａおよび１１ＢのクラスＡ命令テンプレートとクラスＢ命令テンプレートとの間で選択をする。一方、修正子フィールドの内容は、クラスＡ命令テンプレート内では、図１１Ａの命令テンプレート１１０５と１１２０との間の選択をする；また一方では、修正子フィールドの内容は、クラスＢ命令テンプレート内では、図１１Ｂの命令テンプレート１１０５と１１２０との間の選択をする。クラス・フィールドの内容がクラスＡ命令テンプレートを示す場合、修正子フィールド１１４６の内容がアルファ・フィールド１１５２の解釈を選ぶ（rsフィールド１１５２ＡとEHフィールド１１５２Ｂとの間で）。関連した仕方で、修正子フィールド１１４６およびクラス・フィールド１１６８の内容は、アルファ・フィールドがrsフィールド１１５２Ａ、EHフィールド１１５２Ｂまたは書き込みマスク制御（Z）フィールド１１５２Ｃのどれとして解釈されるかを選ぶ。クラスおよび修正子フィールドがクラスＡのメモリ・アクセスなし処理を示す場合には、増強フィールドのベータ・フィールドの解釈が、rsフィールドの内容に基づいて変わる；一方、クラスおよび修正子フィールドがクラスＢのメモリ・アクセスなし処理を示す場合には、ベータ・フィールドの解釈はRLフィールドの内容に依存する。クラスおよび修正子フィールドがクラスＡのメモリ・アクセス処理を示す場合には、増強フィールドのベータ・フィールドの解釈は、基本処理フィールドの内容に基づいて変わる；一方、クラスおよび修正子フィールドがクラスＢのメモリ・アクセス処理を示す場合には、増強フィールドのベータ・フィールドの解釈は基本処理フィールドの内容に基づいて変わる。このように、基本処理フィールド、修正子フィールドおよび増強処理フィールドの組み合わせは、一層幅広い多様な増強処理が指定されることを許容する。

【0081】

クラスＡおよびクラスＢ内で見出されるさまざまな命令テンプレートは種々の状況で有益である。クラスＡは、零化書き込みマスクをするときに有用であり、より小さなベクトル長はパフォーマンス上の理由で望ましい。たとえば、零化は、名称変更が使われるときの偽の依存性を回避することを許容する。宛先と人工的に併合する必要がなくなるからである。もう一つの例として、ベクトル長制御は、ベクトル・マスクを用いてより短いベクトル・サイズをエミュレートするときに、ストア‐ロード転送問題を緩和する。クラスＢは、１）同時に丸めモード制御を使いながら、浮動小数点例外を許容する（すなわちSAEフィールドの内容が否を示す）；２）上方変換、スウィズル、スワップおよび／または下方変換を使える；３）グラフィック・データ型に対して作用する、ことが望ましいときに有用である。たとえば、上方変換、スウィズル、スワップ、下方変換およびグラフィック・データ型は、異なるフォーマットにあるソースと協働するときに必要とされる命令の数を減らす；もう一つの例として、例外を許容する能力は、指揮される丸めモードとの完全なIEEE準拠を提供する。

【0082】

例示的な個別的なベクトル・フレンドリー命令フォーマット
図１２のＡ〜Ｃは、本発明の諸実施形態に基づく、例示的な個別的なベクトル・フレンドリー命令フォーマットを示している。図１２のＡ〜Ｃは、諸フィールドの位置、サイズ、解釈および順序およびそれらのフィールドのいくつかについては値を特定しているという意味で個別的である、個別的なベクトル・フレンドリー命令フォーマット１２００を示している。この個別的なベクトル・フレンドリー命令フォーマット１２００は、x86命令セットを拡張するために使われてもよく、よってフィールドのいくつかは既存のx86命令セットおよびその拡張において使われているものと同様または同じである（たとえばAVX）。このフォーマットは、拡張を含む既存のx86命令セットのプレフィックス・エンコード・フィールド、リアル・オペコード・バイト・フィールド、MOD R/Mフィールド、SIBフィールド、変位フィールドおよび直定数フィールドと整合するままである。図１２のＡ〜Ｃからのフィールドが対応する図１１のフィールドが示されている。

【0083】

本発明の実施形態は、例解目的のために汎用ベクトル・フレンドリー命令フォーマット１１００のコンテキストにおいて個別的なベクトル・フレンドリー命令フォーマット１２００を参照しつつ記述されるが、本発明は、請求項に記載される場合のほかは、この個別的なベクトル・フレンドリー命令フォーマット１２００に限定されない。たとえば、汎用ベクトル・フレンドリー命令フォーマット１１００は、さまざまなフィールドについて多様な可能なサイズを考えている。一方、個別的なベクトル・フレンドリー命令フォーマット１２００は特定のサイズのフィールドをもつものとして示されている。個別的な例として、データ要素幅フィールド１１６４が個別的なベクトル・フレンドリー命令フォーマット１２００における一ビットのフィールドとして示されているが、本発明はそれに限定されない（汎用ベクトル・フレンドリー命令フォーマット１１００は、データ要素幅フィールド１１６４の他のサイズも考えている）。

【0084】

フォーマット――図１２Ａ〜Ｃ
汎用ベクトル・フレンドリー命令フォーマット１１００は、図１２Ａ〜Ｃに示される順で下記に挙げる以下のフィールドを含む。

【0085】

EVEXプレフィックス（バイト0〜3）
EVEXプレフィックス１２０２――これは四バイトの形でエンコードされる。

【0086】

フォーマット・フィールド１１４０（EVEXバイト0、ビット[7:0]）――第一バイト（EVEXバイト0）はフォーマット・フィールド１１４０であり、0x62（本発明のある実施形態においてベクトル・フレンドリー命令フォーマットを識別するために使われる一意的な値）を含む。

【0087】

第二〜第四バイト（EVEXバイト1〜3）は、個別的な機能を提供するいくつかのビット・フィールドを含む。

【0088】

REXフィールド１２０５（EVEXバイト1、ビット[7-5]）――これはEVEX.Rビット・フィールド（EVEXバイト1、ビット[7]――R）、EVEX.Xビット・フィールド（EVEXバイト1、ビット[6]――X）および1157BEXバイト1、ビット[5]――B）からなる。EVEX.R、EVEX.XおよびEVEX.Bビット・フィールドは、対応するVEXビット・フィールドと同じ機能を提供し、1の補数の形を使ってエンコードされる。すなわち、ZMM0は1111Bとしてエンコードされ、ZMM15は0000Bとしてエンコードされる。命令の他のフィールドは、当技術分野で既知のように、レジスタ・インデックスの下位三ビットをエンコードする（rrr、xxxおよびbbb）。それにより、EVEX.R、EVEX.XおよびEVEX.Bを加えることによって、Rrrr、XxxxおよびBbbbが形成されうる。

【0089】

REX'フィールド１２１０――これはREX'フィールド１２１０の第一の部分であり、拡張された32レジスタ・セットの上位16または下位16のいずれかをエンコードするために使われるEVEX.R'ビット・フィールド（EVEXバイト1、ビット[4]――R'）である。本発明のある実施形態では、このビットは、下記に示される他とともに、（よく知られたx86 32ビット・モードにおいて）真のオペコード・バイトが62であるBOUND命令から区別するためにビット反転したフォーマットで記憶される。だがMOD R/Mフィールド（後述）においてMODフィールド中の値11を受け入れない。本発明の代替的な実施形態は、これおよびその他の下記で示されるビットを反転フォーマットで記憶しない。下位16個のレジスタをエンコードするために値1が使われる。換言すれば、EVEX.R'、EVEX.R'および他のフィールドからの他のRRRを組み合わせることによって、R'Rrrrが形成される。

【0090】

オペコード・マップ・フィールド１２１５（EVEXバイト1、ビット[3:0]――mmmm）――その内容は含意される先頭オペコード・バイトをエンコードする（0F、0F38または0F3）。

【0091】

データ要素幅フィールド１１６４（EVEXバイト2、ビット[7]――W）――これは記号EVEX.Wによって表される。EVEX.Wは、データ型の粒度（サイズ）（32ビット・データ要素か64ビット・データ要素か）を定義するために使われる。

【0092】

EVEX.vvvv １２２０（EVEXバイト2、ビット[6:3]――vvvv）――EVEX.vvvvの役割は以下のものを含む：１）EVEX.vvvvは、判定した（1の補数）形で指定されている第一のソース・レジスタ・オペランドをエンコードし、二つ以上のソース・オペランドをもつ命令について有効である；２）EVEX.vvvvは、ある種のベクトル・シフトについて1の補数の形で指定されている宛先レジスタ・オペランドをエンコードする；または３）EVEX.vvvvはいかなるオペランドもエンコードせず、当該フィールドはリザーブされ、1111bを含むべきである。このように、EVEX.vvvvフィールド１２２０は、反転された（1の補数）形で記憶されている第一のソース・レジスタ指定子の下位四ビットをエンコードする。命令に依存して、指定子サイズを32レジスタに拡張するために、追加の異なるEVEXビット・フィールドが使われる。

【0093】

EVEX.U １１６８クラス・フィールド（EVEXバイト2、ビット[2]――U）――EVE.U＝0であれば、それはクラスＡまたはEVEX.U0を示す；EVEX.U＝1であれば、それはクラスＢまたはEVEX.U1を示す。

【0094】

プレフィックス・エンコード・フィールド１２２５（EVEXバイト2、ビット[1:0]――pp）――これは、基本処理フィールドについての追加的な諸ビットを提供する。EVEXプレフィックス・フォーマット中のレガシーSSE命令のためのサポートを提供することに加えて、これはSIMDプレフィックスをコンパクト化するという恩恵もある（SIMDプレフィックスを表すために一バイトを要求するのではなく、EVEXプレフィックスは2ビットしか要求しない）。ある実施形態では、レガシー・フォーマットおよびEVEXプレフィックス・フォーマットの両方においてSIMDプレフィックス（66H、F2H、F3H）を使うレガシーSSE命令をサポートするため、これらのレガシーSIMDプレフィックスがSIMDプレフィックス・エンコード・フィールド中にエンコードされ；ランタイムには、デコーダのPLAに与えられるのに先立ってレガシーSIMDプレフィックス中に展開される（これにより、PLAは、修正なしでこれらのレガシー命令のレガシーおよびEVEXフォーマットの両方を実行できる）。より新しい命令はEVEXプレフィックス・エンコード・フィールドの内容を直接、オペコード拡張として使うことができるが、ある種の実施形態は、整合性のために同様の仕方で展開するが、これらのレガシーSIMDプレフィックスによって異なる意味が指定されることを許容する。ある代替的な実施形態は、2ビットSIMDプレフィックス・エンコードをサポートするようPLAを設計し直し、よって展開を必要としなくてもよい。

【0095】

アルファ・フィールド１１５２（EVEXバイト3、ビット[7]――EH；EVEX.EH、EVEX.rs、EVEX.RL、EVEX.書き込みマスク制御およびEVEX.Nとしても知られる；αとも記す）――先述したように、このフィールドはコンテキスト固有である。さらなる説明は本稿で後述する。

【0096】

ベータ・フィールド１１５４（EVEXバイト3、ビット[6:4]――SSS；EVEX.s_2-0、EVEX.r_2-0、EVEX.rr1、EVEX.LL0、EVEX.LLBとしても知られる；βββとも記す）――先述したように、このフィールドはコンテキスト固有である。さらなる説明は本稿で後述する。

【0097】

REX'フィールド１２１０――これはREX'フィールドの残りであり、拡張された32レジスタ・セットの上位16または下位16のいずれかをエンコードするために使用されうるEVEX.V'ビット・フィールド（EVEXバイト3、ビット[3]――V'）である。このビットはビット反転したフォーマットで記憶される。1の値は下位16個のレジスタをエンコードするために使われる。換言すれば、EVEX.V'、EVEX.vvvvを組み合わせることによって、V'VVVVが形成される。

【0098】

書き込みマスク・フィールド１１７０（EVEXバイト3、ビット[2:0]――kkk）――その内容は、先述したように、書き込みマスク・レジスタ中のレジスタのインデックスを指定する。本発明のある実施形態では、特定の値EVEX.kkk＝000は特別な振る舞いをもち、その特定の命令について書き込みマスクが使用されないことを含意する（これは、すべて1に固定構成された書き込みマスクまたはマスク・ハードウェアをバイパスするハードウェアを使うことを含め、多様な仕方で実現されうる）。

【0099】

リアル・オペコード・フィールド１２３０（バイト4）
これはオペコード・バイトとしても知られる。オペコードの一部はこのフィールドにおいて指定される。

【0100】

MOD R/Mフィールド１２４０（バイト5）
修正子フィールド１１４６（MODR/M.MOD、ビット[7-6]――MODフィールド１２４２）――先述したように、MODフィールド１２４２の内容は、メモリ・アクセスと非メモリ・アクセス処理の間の区別をする。このフィールドについては本稿でさらに後述する。

【0101】

MODR/M.regフィールド１２４４、ビット[5-3]――ModR/M.regフィールドの役割は、二つの状況に要約できる：ModR/M.regは宛先レジスタ・オペランドまたはソース・レジスタ・オペランドのいずれかをエンコードする、あるいはModR/M.regはオペコード拡張として扱われ、いかなる命令オペランドをエンコードするためにも使用されない。

【0102】

MODR/M.r/mフィールド１２４６、ビット[2-0]――ModR/M.r/mフィールドの役割は、以下を含んでもよい：ModR/M.r/mは、メモリ・アドレスを参照する命令オペランドをエンコードする、あるいはModR/M.r/mは宛先レジスタ・オペランドまたはソース・レジスタ・オペランドのいずれかをエンコードする。

【0103】

スケール、インデックス、ベース（SIB）バイト（バイト6）
スケール・フィールド１１６０（SIB.SS、ビット[7-6]）――先述したように、スケール・フィールド１１６０の内容はメモリ・アドレス生成のために使われる。このフィールドについては本稿でさらに後述する。

【0104】

SIB.xxx １２５４（ビット[5-3]）およびSIB.bbb １２５６（ビット[2-0]）――これらのフィールドの内容は、レジスタ・インデックスXxxxおよびBbbbに関して左記に参照された。

【0105】

変位バイト（単数または複数）（バイト7またはバイト7-10）
変位フィールド１１６２Ａ（バイト7-10）――MODフィールド１２４２が10を含むとき、バイト7-10は
変位フィールド１１６２Ａであり、レガシーの32ビット変位（disp32）と同じはたらきをし、バイト粒度ではたらく。

【0106】

変位因子フィールド１１６２Ｂ（バイト7）――MODフィールド１２４２が01を含むとき、バイト7は変位因子フィールド１１６２Ｂである。このフィールドの位置は、バイト粒度ではたらくレガシーのx86命令セットの8ビット変位（disp8）の位置と同じである。disp8は符号拡張されているので、−128から127バイトまでの間のオフセットしかアドレッシングできない。64バイトのキャッシュラインの点では、disp8は、四つの本当に有用な値−128、−64、0および64のみに設定されることができる8ビットを使う。より大きな範囲がしばしば必要とされるので、disp32が使われる。しかしながら、disp32は四バイトを必要とする。disp8およびdisp32と対照的に、変位因子フィールド１１６２Ｂはdisp8を解釈し直したものである；変位因子フィールド１１６２Ｂを使うとき、実際の変位は、変位因子フィールドの内容にメモリ・オペランド・アクセスのサイズ（N）を乗算したものによって決定される。この型の変位はdisp8*Nと称される。これは、平均命令長を短縮する（単一のバイトが変位のために使われるが、ずっと大きな範囲をもつ）。そのような圧縮された変位は、有効変位がメモリ・アクセスの粒度の倍数であり、よってアドレス・オフセットの冗長な低位ビットはエンコードされる必要がないという想定に基づいている。換言すれば、変位因子フィールド１１６２Ｂはレガシーx86命令セットの8ビット変位の代わりになる。このように、変位因子フィールド１１６２Ｂは、disp8はdisp8*Nに加重されるという唯一の例外を除いて、x86命令セットの8ビット変位と同じようにエンコードされる（よって、ModRM/SIBのエンコード規則には何の変更もない）。換言すれば、エンコード規則やエンコード長には何の変更もなく、変更は、ハードウェアによる変位値の解釈のみである（ハードウェアは、メモリ・オペランドのサイズによって変位をスケーリングしてバイトごとのアドレス・オフセットを得る必要がある）。

【0107】

直定数（immediate）
直定数フィールド１１７２は先述したように機能する。

【0108】

例示的なレジスタ・アーキテクチャ――図１３
図１３は、本発明のある実施形態に基づくレジスタ・アーキテクチャ１３００のブロック図である。レジスタ・アーキテクチャのレジスタ・ファイルおよびレジスタを下記に挙げる。

【0109】

ベクトル・レジスタ・ファイル１３１０――図示した実施形態では、1312ビット幅の32個のベクトル・レジスタがある。これらのレジスタはzmm0ないしzmm31と参照符号を付けられている。低位16個のzmmレジスタの低位1156個のビットは、レジスタymm0-16に重ねられる。低位16個のzmmレジスタの低位128ビット（ymmレジスタの低位128ビット）はレジスタxmm0-15に重ねられる。個別的なベクトル・フレンドリー命令フォーマット１２００はこれらの重ねられたレジスタ・ファイルに対して、下記のテーブルに示されるように作用する。

【0110】

【表2】

換言すれば、ベクトル長フィールド１１５９Ｂは、最大長と一つまたは複数の他のより短い長さとの間で選択を行う。ここで、そのようなより短い長さのそれぞれは、先行する長さの半分の長さである。ベクトル長フィールド１１５９Ｂのない命令テンプレートは最大ベクトル長に対して作用する。さらに、ある実施形態では、この個別的ベクトル・フレンドリー命令フォーマット１２００のクラスＢ命令テンプレートは、パックされたまたはスカラーの単精度／倍精度浮動小数点データおよびパックされたまたはスカラーの整数データに作用する。スカラー演算は、zmm/ymm/xmmレジスタ中の最低位のデータ要素位置に対して実行される処理である。より高位のデータ要素位置は、実施形態に依存して、当該命令前と同じままにされるか、0にされる。

【0111】

書き込みマスク・レジスタ１３１５――図示した実施形態では、それぞれ64ビットのサイズの８個の書き込みマスク・レジスタがある（k0ないしk7）。先述したように、本発明のある実施形態では、ベクトル・マスク・レジスタk0は書き込みマスクとして使われることはできない。通常k0を示すエンコードが書き込みマスクについて使われるときは、0xFFFFの固定構成された書き込みマスクが選択されて、事実上、その命令について書き込みマスク処理を無効にする。

【0112】

マルチメディア拡張制御状態レジスタ（MXCSR: Multimedia Extensions Control Status Register）１３２０――図示した実施形態では、この32ビット・レジスタは、浮動小数点演算において使われる状態および制御ビットを提供する。

【0113】

汎用目的レジスタ１３２５――図示した実施形態では、メモリ・オペランドにアドレッシングするために既存のx86アドレッシング・モードとともに使われる１６個の64ビット汎用目的レジスタがある。これらのレジスタは名前RAX、RBX、RCX、RDX、RBP、RSI、RDI、RSPおよびR8ないしR15によって参照される。

【0114】

拡張されたフラグ（EFLAGS）レジスタ１３３０――図示した実施形態では、この32ビット・レジスタは多くの命令の結果を記録するために使われる。

【0115】

浮動小数点制御語（FCW: Floating Point Control Word）レジスタ１３３５および浮動小数点状態語（FSW: Floating Point Status Word）レジスタ１３４０――図示した実施形態では、これらのレジスタはx87命令セット拡張によって、FCWの場合には丸めモード、例外マスクおよびフラグを設定し、FSWの場合には例外を追跡するために使用される。

【0116】

スカラー浮動小数点スタック・レジスタ・ファイル（x87スタック）１３４５ この上にMMXのパックされた整数のフラットなレジスタ・ファイル１３５０がエイリアスされている。――図示した実施形態では、x87スタックは、x87命令セット拡張を使って32/64/80ビット浮動小数点データに対してスカラーの浮動小数点演算を実行するために使われる８要素のスタックである。一方、MMXレジスタは64ビットのパックされた整数データに対して処理を実行するとともに、MMXとXMMレジスタの間で実行されるいくつかの処理のためのオペランドを保持するために使われる。

【0117】

セグメント・レジスタ１３３５――図示した実施形態では、セグメント分割されたアドレス生成のために使われるデータを記憶するために使われる６個の16ビット・レジスタがある。

【0118】

RIPレジスタ１３６５――図示した実施形態では、この64ビット・レジスタは命令ポインタを記憶する。

【0119】

本発明の代替的な実施形態は、より幅広いまたはより狭いレジスタを使ってもよい。さらに、本発明の代替的な実施形態はより多くの、より少数のまたは異なるレジスタ・ファイルおよびレジスタを使ってもよい。

【0120】

例示的な順序内プロセッサ・アーキテクチャ――図１４Ａ〜Ｂ
図１４Ａ〜Ｂは、例示的な順序内プロセッサ・アーキテクチャのブロック図を示している。これらの例示的な実施形態は、幅広のベクトル・プロセッサ（VPU）をもって増強される順序内CPUコアの複数のインスタンス化のまわりに設計される。コアは広帯域幅の相互接続網を通じて、e16tアプリケーションに依存して、何らかの固定機能論理、メモリI/Oインターフェースおよび他の必要なI/O論理と通信する。たとえば、この実施形態のスタンドアローンGPUとしての実装は典型的にはPCIeバスを含む。

【0121】

図１４Ａは、本発明の諸実施形態に基づき、単一のCPUコアを、そのダイ上相互接続ネットワーク１４０２とともにまたそのレベル２（L2）キャッシュ１４０４のローカル・サブセットともに、ブロック図として示している。命令デコーダ１４００はx86命令セットを、個別的なベクトル命令フォーマット１２００を含む拡張とともにサポートする。本発明のある実施形態では、（設計を簡単にするため）スカラー・ユニット１４０８およびベクトル・ユニット１４１０が別個のレジスタ・セット（それぞれスカラー・レジスタ１４１２およびベクトル・レジスタ１４１４）を使っており、それらの間で転送されるデータはメモリに書き込まれて、その後レベル１（L1）キャッシュ１４０６から読み戻されるが、本発明の代替的な諸実施形態は、異なる手法を使ってもよい（たとえば、単一レジスタ・セットを使うまたは書き込まれて読み戻されることなく二つのレジスタ・ファイルの間でデータが転送されることを許容する通信経路を含めてもよい）。

【0122】

L1キャッシュ１４０６は、スカラーおよびベクトル・ユニット中へのキャッシュ・メモリへの低遅延アクセスを許容する。ベクトル・フレンドリー命令フォーマットにおけるロード処理命令と一緒に、これは、L1キャッシュ１４０６が、どこか拡張されたレジスタ・ファイルのように扱われることができることを意味する。これは、特に放逐ヒント・フィールド１１５２Ｂに関し、多くのアルゴリズムのパフォーマンスを著しく改善する。

【0123】

L2キャッシュ１４０４のローカル・サブセットは、CPUコア当たり一つとなるよう別個の複数のローカル・サブセットに分割されたグローバルなL2キャッシュの一部である。各CPUはL2キャッシュ１４０４の自らのローカル・サブセットへの直接的なアクセス経路をもつ。CPUコアによって読まれるデータは、そのL2キャッシュ・サブセット１４０４に記憶され、迅速にアクセスされることができる。これは、他のCPUが自らのローカルなL2キャッシュ・サブセットにアクセスするのと並行してである。CPUコアによって書き込まれるデータは自らのL2キャッシュ・サブセット１４０４に記憶され、必要であれば他のサブセットからフラッシュ（flush）される。リング・ネットワークが、共有されるデータの一貫性を保証する。

【0124】

図１４のＢは、本発明の諸実施形態に基づく図１４のＡにおけるCPUコアの一部の分解図である。図１４のＢは、L1キャッシュ１４０４のL1データ・キャッシュ１４０６Ａ部分と、ベクトル・ユニット１４１０およびベクトル・レジスタ１４１４に関するさらなる詳細とを含んでいる。具体的には、ベクトル・ユニット１４１０は16幅のベクトル処理ユニット（VPU: vector processing unit）である（16幅のALU １４２８参照）。これは整数、単精度浮動小数点および倍精度浮動小数点の命令を実行する。VPUは、メモリ入力に対する、スウィズル・ユニット１４２０によるレジスタ入力のスウィズル、数値変換ユニット１４２２Ａ〜Ｂによる数値的な変換および複製ユニット１４２４による複製をサポートする。書き込みマスク・レジスタ１４２６は、結果として得られるベクトル書き込みを予測することを許容する。

【0125】

レジスタ・データは、たとえば行列乗算をサポートするために、多様な仕方でスウィズルされることができる。メモリからのデータはVPUレーンを横断して複製されることができる。これは、グラフィックおよび非グラフィックの並列データ処理の両方における共通の処理であり、これはキャッシュ効率を著しく高める。

【0126】

リング・ネットワークは、CPUコア、L2キャッシュおよび他の論理ブロックのようなエージェントがチップ内で互いと通信することを許容するよう双方向である。各リング・データ経路は一方向当たり1312ビットの幅である。

【0127】

例示的な順序外アーキテクチャ――図１５
図１５は、本発明の諸実施形態に基づく、例示的な順序外アーキテクチャを示すブロック図である。具体的には、図１５は、よく知られた例示的な順序外アーキテクチャを、ベクトル・フレンドリー命令フォーマットおよびその実行を組み込むよう修正したものである。図１５では、矢印は二つ以上のユニットの間の結合を表し、矢印の向きはそれらのユニット間でのデータの流れの向きを示す。図１５は、実行エンジン・ユニット１５１０およびメモリ・ユニット１５１５に結合されたフロント・エンド・ユニット１５０５を含む。実行エンジン・ユニット１５１０はさらにメモリ・ユニット１５１５に結合されている。

【0128】

フロント・エンド・ユニット１５０５は、レベル２（L2）分岐予測ユニット１５２２に結合されたレベル１（L1）分岐予測ユニット１５２０を含む。L1およびL2分岐予測ユニット１５２０および１５２２はL1命令キャッシュ・ユニット１５２４に結合されている。L1命令キャッシュ・ユニット１５２４は、命令トランスレーション・ルックアサイド・バッファ（TLB: translation lookaside buffer）１５２６に結合され、TLB １５２６はさらに命令フェッチおよびプレデコード・ユニット１５２８に結合されている。命令フェッチおよびプレデコード・ユニット１５２８は命令待ち行列ユニット１５３０に結合されており、命令待ち行列ユニット１５３０はさらにデコード・ユニット１５３２に結合されている。デコード・ユニット１５３２は複雑なデコーダ・ユニット１５３４と、三つの単純なデコーダ・ユニット１５３６、１５３８、１５４０とを有する。デコード・ユニット１５３２は、マイクロコードROMユニット１５４２を含む。デコード・ユニット１５３２は、デコード段セクションにおいて上記で先述したように動作してもよい。L1命令キャッシュ・ユニット１５２４はさらに、メモリ・ユニット１５１５中のL2キャッシュ・ユニット１５４８に結合される。命令TLBユニット１５２６はさらに、メモリ・ユニット１５１５中の第二レベルTLBユニット１５４６に結合される。デコード・ユニット１５３２、マイクロコードROMユニット１５４２およびループ・ストリーム検出器ユニット１５４４はそれぞれ、実行エンジン・ユニット１５１０中の名称変更／割り当て器ユニット１５５６に結合されている。

【0129】

実行エンジン・ユニット１５１０は、リタイアメント・ユニット１５７４および統一スケジューラ・ユニット１５５８に結合されている前記名称変更／割り当て器ユニット１５５６を含む。リタイアメント・ユニット１５７４はさらに諸実行ユニット１５６０に結合され、並べ替えバッファ・ユニット１５７８を含む。統一スケジューラ・ユニット１５５８はさらに物理レジスタ・ファイル・ユニット１５７６に結合され、該物理レジスタ・ファイル・ユニット１５７６は諸実行ユニット１５６０に結合されている。物理レジスタ・ファイル・ユニット１５７６は、ベクトル・レジスタ・ユニット１５７７Ａ、書き込みマスク・レジスタ・ユニット１５７７Ｂおよびスカラー・レジスタ・ユニット１５７７Ｃを有し、これらのレジスタ・ユニットが上記のベクトル・レジスタ１３１０、ベクトル・マスク・レジスタ１３１５および汎用目的レジスタ１３２５を提供してもよい。物理レジスタ・ファイル・ユニット１５７６は図示されていない追加的なレジスタ・ファイルを含んでいてもよい（たとえば、MMXパックされた整数フラット・レジスタ・ファイル１３５０上にエイリアスされたスカラー浮動小数点スタック・レジスタ・ファイル１３４５）。諸実行ユニット１５６０は三つの混合スカラー兼ベクトル・ユニット１５６２、１５６４、１５７２；ロード・ユニット１５６６；アドレス・ストア・ユニット１５６８；データ・ストア・ユニット１５７０を含む。ロード・ユニット１５６６、アドレス・ストア・ユニット１５６８およびデータ・ストア・ユニット１５７０はそれぞれさらに、メモリ・ユニット１５１５中のデータTLBユニット１５５２に結合される。

【0130】

メモリ・ユニット１５１５は、データTLBユニット１５５２に結合された第二レベルのTLBユニット１５４６を含む。データTLBユニット１５５２はL1データ・キャッシュ・ユニット１５５４に結合されている。L1データ・キャッシュ・ユニット１５５４はさらにL2キャッシュ・ユニット１５４８に結合されている。いくつかの実施形態では、L2キャッシュ・ユニット１５４８はさらに、メモリ・ユニット１５１５の内部および／または外部のL3およびより高次のキャッシュ・ユニット１５５０に結合されている。

【0131】

例として、例示的な順序外アーキテクチャは、次のようにプロセス・パイプラインを実装してもよい：１）命令フェッチおよびプレデコード・ユニット１５２８がフェッチおよび長さデコード段を実行する；２）デコード・ユニット１５３２がデコード段を実行する；３）名称変更／割り当て器ユニット１５５６が割り当て段および名称変更段を実行する；４）統一スケジューラ１５５８がスケジュール段を実行する；５）物理レジスタ・ファイル・ユニット１５７６、並べ替えバッファ・ユニット１５７８およびメモリ・ユニット１５１５がレジスタ読み出し／メモリ読み出し段を実行する；実行ユニット１５６０は実行／データ変換段を実行する；６）メモリ・ユニット１５１５および並べ替えバッファ・ユニット１５７８が書き戻し／メモリ書き込み段を実行する；７）リタイアメント・ユニット１５７４がROB読み出し段を実行する；８）さまざまなユニットが実行ハンドリング段に関わってもよい；９）リタイアメント・ユニット１５７４および物理レジスタ・ファイル・ユニット１５７６がコミット段を実行する。

【0132】

例示的な単一コアおよび複数コア・プロセッサ――図２０
図２０は、本発明の諸実施形態に基づく統合されたメモリ・コントローラおよびグラフィクスをもつ単一コア・プロセッサおよび複数コア・プロセッサ２０００のブロック図である。図１１９における実線の四角は単一コア２００２Ａ、システム・エージェント２０１０、一つまたは複数のバス・コントローラ・ユニットの組２０１６をもつプロセッサ２００００を示している。一方、破線の四角の任意的な付加は、複数のコア２００２Ａ〜Ｎ、システム・エージェント・ユニット２０１０内の一つまたは複数の統合されたメモリ・コントローラ・ユニット２０１４の組および統合されたグラフィック論理２００８をもつ代替的なプロセッサ２０００を示す。

【0133】

メモリ階層構造は、コア内のキャッシュの一つまたは複数のレベル、一つまたは複数の共有されるキャッシュ・ユニットの組２００６および統合されたメモリ・コントローラ・ユニットの組２０１４に結合された外部メモリ（図示せず）を含む。共有されるキャッシュ・ユニットの組２００６は、レベル２（L2）、レベル３（L3）、レベル４（L4）または他のレベルのキャッシュのような一つまたは複数の中間レベル・キャッシュ、最終レベル・キャッシュ（LLC: last level cache）および／またはそれらの組み合わせを含んでいてもよい。ある実施形態では、リング・ベースの相互接続ユニット２０１２が統合されたグラフィック論理２００８、共有されるキャッシュ・ユニットの組２００６およびシステム・エージェント・ユニット２０１０を相互接続するが、代替的な実施形態は、そのようなユニットを相互接続するためのいくつもあるよく知られた技法を使用してもよい。

【0134】

いくつかの実施形態では、コア２００２Ａ〜Ｎの一つまたは複数はマルチスレッド機能をもつ。システム・エージェント２０１０は、コア２００２Ａ〜Ｎを協調させ、動作させるコンポーネントを含む。システム・エージェント・ユニット２０１０はたとえば、電力制御ユニット（PCU: power control unit）および表示ユニットを含んでいてもよい。ＰＣＵは、コア２００２Ａ〜Ｎおよび統合されたグラフィック論理２００８の電力状態を制御するために必要とされる論理およびコンポーネントであってもよいし、そのような論理およびコンポーネントを含んでいてもよい。表示ユニットは一つまたは複数の外部接続されたディスプレイを駆動するためである。

【0135】

コア２００２Ａ〜Ｎは、アーキテクチャおよび／または命令セットの点で均一であっても不均一であってもよい。たとえば、コア２００２Ａ〜Ｎのいくつかが順序内（たとえば、図１４ＡおよびＢに示したものように）であってもよく、一方、他のものは順序外（たとえば図１５に示したもののように）であってもよい。もう一つの例として、コア２００２Ａ〜Ｎの二つ以上が同じ命令セットを実行する機能を有していてもよく、一方、他のものはその命令セットのサブセットのみまたは異なる命令セットを実行する機能を有していてもよい。前記コアの少なくとも一つは、本稿に記載されるベクトル・フレンドリー命令フォーマットを実行する機能をもつ。

【0136】

プロセッサは、Core（商標）i3、i5、i7、2 DuoおよびQuad、Xeon（商標）またはアイテニアム（商標）プロセッサのような汎用目的プロセッサであってもよい。これらは米国カリフォルニア州サンタクララのインテル社から発売されている。あるいはまた、プロセッサは別の会社からのものであってもよい。プロセッサは、ネットワーク通信プロセッサ、圧縮エンジン、グラフィクス・プロセッサ、コプロセッサ、組み込みプロセッサなどといった特殊目的プロセッサであってもよい。プロセッサは一つまたは複数のチップ上に実装されてもよい。プロセッサ２０００は、たとえばBiCMOS、CMOSまたはNMOSといったいくつもあるプロセス技術の任意のものを使って一つまたは複数の基板であってもよいし、および／または一つまたは複数の基板上に実装されてもよい。

【0137】

例示的なコンピュータ・システムおよびプロセッサ――図１６〜図１９
図１６〜図１８は、プロセッサ２０００を含むのに好適な例示的なシステムであり、図１９はコア２００２の一つまたは複数を含みうる例示的なシステム・オン・チップ（SoC: system on a chip）である。ラップトップ、デスクトップ、ハンドヘルドPC、携帯情報端末（personal digital assistant）、エンジニアリング・ワークステーション、サーバー、ネットワーク・デバイス、ネットワーク・ハブ、スイッチ、組み込みプロセッサ、デジタル信号プロセッサ（DSP）、グラフィクス・デバイス、ビデオ・ゲーム装置、セットトップボックス、マイクロコントローラ、携帯電話、携帯メディアプレーヤー、ハンドヘルド・ゲーム装置および他のさまざまな電子装置のための、当技術分野で知られている他のシステム設計および構成も好適である。一般に、本稿に開示されるプロセッサおよび／または他の実行論理を組み込むことのできる実に多様なシステムまたは電子装置が一般に好適である。

【0138】

ここで図１６を参照するに、本発明のある実施形態に基づくシステム１６００のブロック図が示されている。システム１６００は、グラフィクス・メモリ・コントローラ・ハブ（GMCH）１６２０に結合されている一つまたは複数のプロセッサ１６１０、１６１５を含んでいてもよい。追加的なプロセッサ１６１５の任意的な性質は図１６では破線で表されている。

【0139】

各プロセッサ１６１０、１６１５はプロセッサ２０００の何らかのバージョンであってもよい。しかしながら、統合されたグラフィクス論理および統合されたメモリ制御ユニットがプロセッサ１６１０、１６１５内に存在する可能性は低いことを注意しておくべきである。

【0140】

図１６は、GMCH １６２０が、たとえば動的ランダム・アクセス・メモリ（DRAM）であってもよいメモリ１６４０に結合されていてもよいことを示している。DRAMは少なくとも一つの実施形態については不揮発性キャッシュと関連付けられてもよい。

【0141】

GMCH １６２０はチップセットまたはチップセットの一部であってもよい。GMCH １６２０はプロセッサ１６１０、１６１５と通信し、プロセッサ１６１０、１６１５とメモリ１６４０との間の対話を制御してもよい。GMCH １６２０は、プロセッサ１６１０、１６１５とシステム１６００の他の要素との間の加速されたバス・インターフェースとしてもはたらいてもよい。少なくとも一つの実施形態については、GMCH １６２０はプロセッサ１６１０、１６１５と、フロントサイド・バス（FSB: frontside bus）１６９５のようなマルチドロップ・バスを介して通信する。

【0142】

さらに、GMCH １６２０は（フラットパネル・ディスプレイのような）ディスプレイ１６４５に結合される。GMCH １６２０は統合されたグラフィクス・アクセラレータを含んでいてもよい。GMCH １６２０はさらに、入出力（I/O）コントローラ・ハブ（ICH）１６５０に結合される。ICH １６５０は、さまざまな周辺機器をシステム１６００に結合するために使われてもよい。図１６の実施形態においては、たとえば外部グラフィクス装置１６６０が示されている。これは、別の周辺機器１６７０とともにICH １６５０に結合されている離散的なグラフィクス装置であってもよい。

【0143】

あるいはまた、追加的なまたは異なるプロセッサもシステム１６００内に存在していてもよい。たとえば、追加的なプロセッサ（単数または複数）１６１５は、プロセッサ１６１０と同じである追加的なプロセッサ、プロセッサ１６１０に対して不均一なまたは非対称な追加的なプロセッサ、アクセラレータ（たとえばグラフィクス・アクセラレータまたはデジタル信号処理（DSP）ユニットのような）、フィールド・プログラマブル・ゲート・アレイまたは他の任意のプロセッサを含んでいてもよい。アーキテクチャ上、マイクロアーキテクチャ上、熱的、電力消費の特性などを含む一連の性能指数の点で、物理的なリソース１６１０、１６１５の間には多様な相違があることがある。これらの相違は、処理要素１６１０、１６１５の間の非対称および不均一性として事実上現れてもよい。少なくとも一つの実施形態について、さまざまな処理要素１６１０、１６１５は同じダイ・パッケージ上に存在していてもよい。

【0144】

ここで図１７を参照するに、本発明のある実施形態に基づく第二のシステム１７００のブロック図が示されている。図１７に示されるように、マルチプロセッサ・システム１７００は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続１７５０を介して結合された第一のプロセッサ１７００および第二のプロセッサ１７８０を含む。図１７に示されるように、プロセッサ１７７０および１７８０のそれぞれは、プロセッサ２０００の何らかのバージョンであってもよい。

【0145】

あるいはまた、プロセッサ１７７０、１７８０の一つまたは複数は、アクセラレータまたはフィールド・プログラマブル・ゲート・アレイのようなプロセッサ以外の要素であってもよい。

【0146】

プロセッサ１７７０、１７８０の二つのみをもって示しているが、本発明の範囲はそれに限定されないことは理解しておくべきである。他の実施形態では、一つまたは複数の追加的な処理要素が所与のプロセッサ内に存在していてもよい。

【0147】

プロセッサ１７７０はさらに、統合されたメモリ・コントローラ・ハブ（IMC）１７７２およびポイントツーポイント（P-P）インターフェース１７７６および１７７８を含んでいてもよい。同様に、第二のプロセッサ１７８０はIMC １７８２およびP-Pインターフェース１７８６および１７８８を含んでいてもよい。プロセッサ１７７０、１７８０は、PtPインターフェース回路１７７８、１７８８を使ってポイントツーポイント（PtP）インターフェース１７５９を介してデータを交換してもよい。図１７に示されるように、IMCの１７７２および１７８２はプロセッサをそれぞれのメモリ、すなわちメモリ１７４２およびメモリ１７４４に結合する。これらのメモリは、それぞれのプロセッサにローカルに取り付けられたメイン・メモリの一部であってもよい。

【0148】

プロセッサ１７７０、１７８０はそれぞれ、ポイントツーポイント・インターフェース回路１７７６、１７９４、１７８６、１７９８を使って個別のP-Pインターフェース１７５２、１７５４を介してチップセット１７９０とデータを交換してもよい。チップセット１７９０は高パフォーマンス・グラフィクス・インターフェース１７３９を介して高パフォーマンス・グラフィクス回路１７３８とデータを交換してもよい。

【0149】

共有されるキャッシュ（図示せず）は、両プロセッサの外側だがP-P相互接続を介して両プロセッサと接続されているどちらかのプロセッサに含まれていてもよい。それにより、プロセッサが低電力モードに置かれる場合、一方または両方のプロセッサのローカル・キャッシュ情報が共有キャッシュに記憶されてもよい。

【0150】

チップセット１７９０は、インターフェース１７９６を介して第一のバス１７１６に結合されていてもよい。ある実施形態では、第一のバス１７１６は周辺コンポーネント相互接続（PCI）バスまたはPCIエクスプレスのようなバスまたは他の第三世代のI/O相互接続バスであってもよい。ただし、本発明の範囲はそれに限定されるものではない。

【0151】

図１７に示されるように、さまざまなI/O装置１７１４が、第一のバス１７１６を第二のバス１７２０に結合するバス・ブリッジ１７１８とともに第一のバス１７１６に結合されていてもよい。ある実施形態では、第二のバス１７２０は低ピン・カウント（LPC）バスであってもよい。さまざまな装置が第二のバス１７２０に結合されていてもよい。そうしたさまざまな装置は、たとえば、キーボード／マウス１７２２、通信装置１７２６およびある実施形態ではコード１７３０を含んでいてもよいディスク・ドライブもしくは他の大容量記憶装置のようなデータ記憶ユニット１７２８を含む。さらに、オーディオI/O １７２４が第二のバス１７２０に結合されていてもよい。他のアーキテクチャが可能であることを注意されたい。たとえば、図１７のポイントツーポイント・アーキテクチャの代わりに、システムはマルチドロップ・バスまたは他のそのようなアーキテクチャを実装してもよい。

【0152】

ここで図１８を参照するに、本発明のある実施形態に基づく第三のシステム１８００のブロック図が示されている。図１７および図１８における同様の要素は、同様の参照符号を帯びており、図１７のある種の側面は、図１８の他の側面を埋没させるのを避けるため、図１８からは省略されている。

【0153】

図１８は、処理要素１７７０、１７８２が統合されたメモリおよびそれぞれI/O制御論理（「CL」）１７７２および１７８２を含んでいてもよいことを示している。少なくとも一つの実施形態について、CL １７７２、１７８２は、図１１９および１７との関連で上述したもののようなメモリ・コントローラ・ハブ論理（IMC）を含んでいてもよい。さらに、CL １７７２、１７８２はI/O制御論理をも含んでいてもよい。図１８は、メモリ１７４２、１７４４がCL １７７２、１７８２に結合されるだけでなく、I/O装置１８１４も制御論理１７７２、１７８２に結合されていることを示している。レガシーI/O装置１８１５はチップセット１７９０に結合されている。

【0154】

ここで図１９を参照するに、本発明のある実施形態に基づくSoC １９００のブロック図が示されている。図１１９における同様の要素は同様の参照符号を帯びている。また、破線にした四角は、より高度なSoCでは任意的な特徴である。図１９では、相互接続ユニット（単数または複数）１９０２は：一つまたは複数のコア２００２Ａ〜Ｎの組および共有されるキャッシュ・ユニット（単数または複数）２００６を含むアプリケーション・プロセッサ１９１０と；システム・エージェント・ユニット２０１０と；バス・コントローラ・ユニット（単数または複数）２０１６と；統合されたメモリ・コントローラ・ユニット（単数または複数）２０１４と；統合されたグラフィクス論理２００８、スチールおよび／またはビデオ・カメラ機能を提供する画像プロセッサ１９２４、ハードウェア・オーディオ加速を提供するオーディオ・プロセッサ１９２６およびビデオ・エンコード／デコード加速を提供するビデオ・プロセッサ１９２８を含んでいてもよい一つまたは複数のメディア・プロセッサの組と；静的ランダム・アクセス・メモリ（SRAM）ユニット１９３０；直接メモリ・アクセス（DMA）ユニット１９３２と；一つまたは複数の外部ディスプレイに結合するための表示ユニット１９４０とに結合されている。

【0155】

本稿に開示される諸機構の諸実施形態は、ハードウェア、ソフトウェア、ファームウェアまたはそのような実装手法の組み合わせにおいて実装されてもよい。本発明の諸実施形態は、少なくとも一つのプロセッサ、記憶システム（揮発性および不揮発性メモリおよび／または記憶要素を含む）、少なくとも一つの入力装置および少なくとも一つの出力装置を有するプログラム可能なシステム上で実行されるコンピュータ・プログラムまたはプログラム・コードとして実装されてもよい。

【0156】

プログラム・コードは、本稿に記載される機能を実行し、出力情報を生成するよう入力データに適用されてもよい。出力情報は、既知の仕方で一つまたは複数の出力装置に適用されてもよい。本願の目的のためには、処理システムは、たとえばデジタル信号プロセッサ（DSP）、マイクロコントローラ、特定用途向け集積回路（ASIC）またはマイクロプロセッサのようなプロセッサを有する任意のシステムを含む。

【0157】

プログラム・コードは、処理システムと連絡するために高レベルの手続き型またはオブジェクト指向のプログラミング言語で実装されてもよい。プログラム・コードはまた、望むならアセンブリまたは機械語で実装されてもよい。実際、本稿に記載される機構はいかなる特定のプログラミング言語にも範囲において限定されない。いずれにせよ、言語はコンパイルされるまたはインタープリットされる言語であってもよい。

【0158】

少なくとも一つの実施形態の一つまたは複数の側面は、プロセッサ内でのさまざまな論理を表し、機械によって読み込まれたときに該機械に本稿に記載される技法を実行する論理を作らせる、機械可読媒体上に記憶される代表的な命令によって実装されてもよい。「IPコア」として知られるそのような表現は、有体の機械可読媒体上に記憶され、さまざまな顧客または製造設備に供給されて、実際に論理もしくはプロセッサをなす製造機械にロードされもよい。

【0159】

そのような機械可読記憶媒体は、限定なしに、機械またはデバイスによって製造または形成される物品の、非一時的な、有体の構成を含みうる。それには、ハードディスク、フロッピー（登録商標）ディスク、光ディスク（コンパクトディスク読み出し専用メモリ（CD-ROM）、書き換え可能型コンパクトディスク（CD-RW））および光磁気ディスクを含む他の任意の型のディスク、読み出し専用メモリ（ROM）、動的ランダム・アクセス・メモリ（DRAM）、静的ランダム・アクセス・メモリ（SRAM）、消去可能型プログラマブル読み出し専用メモリ（EPROM）、フラッシュメモリ、電気的に消去可能なプログラマブル読み出し専用メモリ（EEPROM）といったランダム・アクセス・メモリ（RAM）といった半導体デバイス、磁気カードもしくは光カードまたは電子的な命令を記憶するのに好適な他の任意の型の媒体といった記憶媒体が含まれる。

【0160】

よって、本発明の実施形態は、ベクトル・フレンドリー命令フォーマットの命令を含む、または、本稿に記載される構造、回路、装置、プロセッサおよび／またはシステム特徴を定義するハードウェア記述言語（HDL）のような設計データを含む、非一時的な有体名機械可読媒体をも含む。そのような実施形態はプログラム・プロダクトとも称されうる。

【0161】

いくつかの場合には、命令をソース命令セットからターゲット命令セットに変換するために命令変換器が使われてもよい。たとえば、命令変換器は、命令を、コアによって処理されるべき一つまたは複数の他の命令に翻訳（たとえば静的バイナリー変換、動的コンパイルを含む動的バイナリー変換）、変形、エミュレートまたは他の仕方で変換してもよい。命令変換器は、ソフトウェア、ハードウェア、ファームウェアまたはその組み合わせにおいて実装されてもよい。命令変換器は、プロセッサ上で、プロセッサ外でまたは部分的にプロセッサ上かつ部分的にプロセッサ外であってもよい。

【0162】

図２１は、本発明の実施形態に基づく、ソース命令セット中のバイナリー命令をターゲット命令セット中のバイナリー命令に変換するソフトウェア命令変換器の使用を対照させるブロック図である。図示した実施形態では、命令変換器は、ソフトウェア命令変換器である。ただし、代替的に、命令変換器はソフトウェア、ファームウェア、ハードウェアまたはそのさまざまな組み合わせにおいて実装されてもよい。図２１は、高レベル言語２１０２のプログラムがx86コンパイラー２１０４を使って、少なくとも一つのx86命令セット・コアをもつプロセッサ２１１６によってネイティブに実行されうるx86バイナリー・コード２１０６を生成するようコンパイルされうることを示している（コンパイルされた命令のいくつかはベクトル・フレンドリー命令フォーマットであることが想定されている）。少なくとも一つのx86命令セット・コアをもつプロセッサ２１１６は、（１）インテルx86命令セット・コアの命令セットの実質的な部分または（２）少なくとも一つのx86命令セット・コアをもつインテル・プロセッサ上で走るようターゲットを定められたアプリケーションまたは他のソフトウェアのオブジェクト・コード・バージョンを互換的に実行するまたは他の仕方で処理することによって、少なくとも一つのx86命令セット・コアをもつインテル・プロセッサと実質的に同じ機能を実行して、少なくとも一つのx86命令セット・コアをもつインテル・プロセッサと実質的に同じ結果を達成できる任意のプロセッサを表す。x86コンパイラー２１０４は、追加的なリンク処理とともにまたは追加的なリンク処理なしで少なくとも一つのx86命令セット・コアをもつプロセッサ２１１６上で実行されることのできるx86バイナリー・コード２１０６（たとえばオブジェクト・コード）を生成するよう動作できるコンパイラーを表す。同様に。

【0163】

図２１は、高レベル言語２１０２のプログラムが代替的な命令セット・コンパイラー２０１８を使って、少なくとも一つのx86命令セット・コアをもたないプロセッサ２１１４（たとえば、米国カリフォルニア州サニーヴェールのMIPSテクノロジーズのMIPS命令セットを実行するおよび／または米国カリフォルニア州サニーヴェールのARMホールディングズのARM命令セットを実行するコアをもつプロセッサ）によってネイティブに実行されうる代替的な命令セットのバイナリー・コード２１１０を生成するようコンパイルされうることを示している。命令変換器２１１２は、x86バイナリー・コード２１０６を、x86命令セット・コアをもたないプロセッサ２１１４によってネイティブに実行されうるコードに変換するために使われる。この変換されたコードは、代替的な命令セット・バイナリー・コード２１１０とは同じである可能性は高くない。というのも、これができる命令変換器は作るのが難しいからである。しかしながら、変換されたコードは、一般的な動作を達成し、代替的な命令セットからの命令から構成されることになる。このように、命令変換器２１１２は、エミュレーション、シミュレーションまたは他の何らかのプロセスを通じてx86命令セット・プロセッサもしくはコアをもたないプロセッサまたは他の電子装置がx86バイナリー・コード２１０６を実行することを許容するソフトウェア、ファームウェア、ハードウェアまたはその組み合わせを表す。

【0164】

本稿に開示されるベクトル・フレンドリー命令フォーマットにおける命令（単数または複数）のある種の動作はハードウェア・コンポーネントによって実行されてもよく、機械実行可能な命令において具現されてもよい。該命令は、該命令をプログラムされた回路または他のハードウェア・コンポーネントが前記動作を実行することを引き起こす、または少なくともそのような結果を生じるために使われる。回路は、ほんの数例のみ挙げれば、汎用目的または特殊目的のプロセッサまたはロリ回路を含んでいてもよい。前記動作は、任意的に、ハードウェアとソフトウェアの組み合わせによって実行されてもよい。実行論理および／またはプロセッサは、機械命令または該機械命令から導出される一つまたは複数の制御信号に応答して、命令に指定された結果オペランドを記憶する個別的または特定の回路または他の論理を含んでいてもよい。たとえば、本稿に開示される命令の実施形態は、図１６〜図１９のシステムの一つまたは複数において実行されてもよく、ベクトル・フレンドリー命令フォーマットにおける命令の実施形態は前記システムにおいて実行されるべきプログラム・コード中に記憶されてもよい。さらに、これらの図の処理要素は、本稿で詳述される詳細なパイプラインおよび／またはアーキテクチャ（たとえば順序内および順序外アーキテクチャ）の一つを利用してもよい。たとえば、順序内アーキテクチャのデコード・ユニットは、命令をデコードし、デコードされた命令をベクトルまたはスカラー・ユニットに渡すなどしてもよい。

【0165】

上記の記述は、本発明の好ましい実施形態を例解することを意図している。上記の議論から、特に成長が速く、さらなる進歩が簡単には予見されない技術分野においては、本発明が、付属の請求項およびその等価物の範囲内の本発明の原理から外れることなく、構成および詳細において、当業者によって修正されてもよいことも明白となるはずである。たとえば、ある方法の一つまたは複数の処理が組み合わされたり、さらに分解されたりしてもよい。

【0166】

代替的な実施形態
ベクトル・フレンドリー命令フォーマットをネイティブに実行する実施形態を記述してきたが、本発明の代替的な実施形態はベクトル・フレンドリー命令フォーマットを、異なる命令セットを実行するプロセッサ（たとえば、米国カリフォルニア州サニーヴェールのMIPSテクノロジーズのMIPS命令セットを実行するプロセッサ、米国カリフォルニア州サニーヴェールのARMホールディングズのARM命令セットを実行するプロセッサ）上で走るエミュレーション層を通じて実行してもよい。また、図面における流れ図は、本発明の諸実施形態によって実行される処理の特定の順序を示しているが、そのような順序が例示的であることは理解しておくべきである（たとえば、代替的な実施形態はそれらの処理を異なる順序で実行したり、ある種の処理を組み合わせたり、ある種の処理をオーバーラップさせたりしてもよい）。

【0167】

上記の記述では、説明の目的のために、本発明の実施形態の十全な理解を与えるよう、数多くの個別的詳細を述べた。しかしながら、当業者には、こうした個別的詳細のいくつかがなくても、一つまたは複数の他の実施形態が実施されてもよいことは明白であろう。記載される特定の実施形態は、本発明を限定するためではなく、本発明の実施形態を例解するために与えられている。本発明の範囲は、上記で与えた個別的な例によって決定されるものではなく、下記の請求項によってのみ決定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】