特許 6058732 ベクトルフレンドリ命令フォーマット及びその実行

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

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

(11)【特許番号】6058732

(24)【登録日】2016年12月16日

(45)【発行日】2017年1月11日

(54)【発明の名称】ベクトルフレンドリ命令フォーマット及びその実行

(51)【国際特許分類】

   G06F 9/355 20060101AFI20161226BHJP

   G06F 9/30 20060101ALI20161226BHJP

   G06F 9/38 20060101ALI20161226BHJP

   G06F 17/16 20060101ALI20161226BHJP

【ＦＩ】

   G06F9/36 320

   G06F9/30 350A

   G06F9/38 370A

   G06F17/16 F

   G06F17/16 A

【請求項の数】12

【外国語出願】

【全頁数】81

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

(22)【出願日】2015年4月22日

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

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

(65)【公開番号】特開2015-158940(P2015-158940A)

(43)【公開日】2015年9月3日

【審査請求日】2015年4月22日

(31)【優先権主張番号】61/471,043

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

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

(73)【特許権者】

【識別番号】593096712

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100091214

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

【氏名】ケヴィン，ロバート，ディー．

(72)【発明者】

【氏名】トール，ブレット，エル．

(72)【発明者】

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

(72)【発明者】

【氏名】ヴィーデマイヤー，ジェフリー，ジー．

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

【氏名】グロコフスキー，エドワード，トーマス

(72)【発明者】

【氏名】ホール，ジョナサン，キャノン

(72)【発明者】

【氏名】ブラッドフォード，デニス，アール．

(72)【発明者】

【氏名】オールド−アハメド−ヴァル，エルムスタファ

(72)【発明者】

【氏名】アベル，ジェイムズ，シー．

(72)【発明者】

【氏名】チャーニー，マーク

(72)【発明者】

【氏名】エイブラハム，セス

(72)【発明者】

【氏名】セイル，スレイマン

(72)【発明者】

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

(72)【発明者】

【氏名】ヨーント，チャールズ

(72)【発明者】

【氏名】ウー，リサ

【審査官】 清木 泰

(56)【参考文献】

【文献】 米国特許第０６６２５７２４（ＵＳ，Ｂ１）

【文献】 特開平１１−１５４１４４（ＪＰ，Ａ）

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

【文献】 特表２０１４−５１３３４１（ＪＰ，Ａ）

【文献】 特表２０１４−５１３３４０（ＪＰ，Ａ）

【文献】 特表２０１４−５１０３５２（ＪＰ，Ａ）

【文献】 特表２０１４−５１０３５１（ＪＰ，Ａ）

【文献】 特表２０１４−５１０３５０（ＪＰ，Ａ）

【文献】 インテル・アーキテクチャ・ソフトウェア・ディベロッパーズ・マニュアル 中巻 命令セット・リファレンス，インテル株式会社，１９９７年，初版，Pages:2-1〜2-6

【文献】 吉田幸作，SH7045Fの命令セットとアセンブラ・プログラミング （SH7045の命令の特徴）と（SH7045の命令セット），トランジスタ技術SPECIAL，CQ出版株式会社，２００３年 １月 １日，No:81，Pages:43〜53

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

Ｇ０６Ｆ ９／３０− ９／３５５

Ｇ０６Ｆ ９／３８

Ｇ０６Ｆ１７／１６

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

【請求項1】

命令セットを実行するよう構成されるプロセッサを有する装置であって、
前記命令セットは、第１命令フォーマットを有し、
前記第１命令フォーマットは、ベース処理フィールド、モディファイアフィールド、データ要素幅フィールド及び拡張処理フィールドを含む複数のフィールドを有し、
前記第１命令フォーマットは、前記ベース処理フィールドの異なる値により複数の異なるベクトル処理の指定をサポートし、
前記複数のベクトル処理の各々は、異なるデータ要素位置の複数のデータ要素を有するデスティネーションベクトルオペランドを生成し、
前記第１命令フォーマットは、前記モディファイアフィールドの異なる値によりメモリアクセス処理及び非メモリアクセス処理の指定をサポートし、
前記モディファイアフィールドのコンテンツがスケーリングされたディスプレースメントによるメモリアクセス処理を指定するとき、前記第１命令フォーマットは、ディスプレースメントファクタフィールドを含み、
前記ベース処理フィールド、前記モディファイアフィールド、前記データ要素幅フィールド及び前記拡張処理フィールドはそれぞれ、前記第１命令フォーマットの命令の各出現に対して１つのみの値を格納可能であり、
前記プロセッサは、命令ストリームに出現する前記第１命令フォーマットの命令を実行するプロセッサパイプラインを含み、
前記パイプラインは、
命令ストリームに出現した前記第１命令フォーマットの命令が有する前記モディファイアフィールドのコンテンツに基づいて、前記出現した前記第１命令フォーマットの命令がスケーリングされたディスプレースメントによるメモリアクセスを指定するものであるか否かを判定し、
前記モディファイアフィールドのコンテンツによりスケーリングされたディスプレースメントによるメモリアクセスを指定する前記第１命令フォーマットの命令が出現したときに、前記出現した前記第１命令フォーマットの命令が有する、前記ベース処理フィールド、前記データ要素幅フィールド及び前記拡張処理フィールドのうちの、２以上のコンテンツに基づき複数のメモリアクセスサイズのうちのいずれか１つである、１つのメモリアクセスサイズを決定し、
前記モディファイアフィールドのコンテンツによりスケーリングされたディスプレースメントによるメモリアクセスを指定する前記第１命令フォーマットの命令が出現したときに、前記出現した第１命令フォーマットの命令のそれぞれについて、前記決定した１つのメモリアクセスサイズと、前記出現した第１命令フォーマットの命令が有する前記ディスプレースメントファクタフィールドのコンテンツとの乗算に基づき前記スケーリングされたディスプレースメントを決定し、決定した前記スケーリングされたディスプレースメントを用いてアドレスを生成するよう構成される装置。

【請求項2】

前記第１命令フォーマットの命令が有する前記モディファイアフィールドのコンテンツが前記メモリアクセス処理を指定するものである場合、当該モディファイアフィールドのコンテンツは、非ディスプレースメントと、スケーリングされないディスプレースメントと、スケーリングされたディスプレースメントのうちの１つを指定することが可能なものである、請求項１記載の装置。

【請求項3】

前記第１命令フォーマットの命令が有する前記モディファイアフィールドのコンテンツがスケーリングされないディスプレースメントによるメモリアクセス処理を指定するものである場合、当該第１命令フォーマットの命令は、前記第１命令フォーマット内に、ディスプレースメントフィールドを有するものである、請求項１又は２記載の装置。

【請求項4】

前記モディファイアフィールドのコンテンツがスケーリングされたディスプレースメントによるメモリアクセス処理を指定するとき、スケール、インデックス及びベースが前記第１命令フォーマットのフィールドからプルされ、
前記スケール、インデックス、ベース及びスケーリングされたディスプレースメントは、前記アドレスを生成するのに利用される、請求項１乃至３何れか一項記載の装置。

【請求項5】

前記スケールは、２ビットスケールフィールドからプルされ、
前記インデックスは、１ビットＸフィールドと３ビットＸＸＸフィールドとの組み合わせからプルされ、
前記ベースは、１ビットＢフィールドと３ビットＢＢＢの組み合わせからプルされる、請求項４記載の装置。

【請求項6】

前記複数のメモリアクセスサイズのうちのいずれか１つである、１つのメモリアクセスサイズを決定するために使用されるフィールドの選択は、前記拡張処理フィールド内のクラスフィールドのコンテンツに基づく、請求項１乃至５何れか一項記載の装置。

【請求項7】

前記クラスフィールドのコンテンツが第１クラスを指定するとき、前記複数のメモリアクセスサイズのうちのいずれか１つである、１つのメモリアクセスサイズを決定するために使用されるフィールドは、前記ベース処理フィールド、前記拡張処理フィールド内のデータ操作フィールド及び前記データ要素幅フィールドのうちの、２以上のフィールドである、請求項６記載の装置。

【請求項8】

前記クラスフィールドのコンテンツが第２クラスを指定するとき、前記複数のメモリアクセスサイズのうちのいずれか１つである、１つのメモリアクセスサイズを決定するために使用されるフィールドは、前記ベース処理フィールド、前記拡張処理フィールド内のブロードキャストフィールド、前記拡張処理フィールド内のベクトル長フィールド及び前記データ要素幅フィールドのうちの、２以上のフィールドである、請求項６又は７記載の装置。

【請求項9】

前記ディスプレースメントファクタフィールドは、シングルバイトである、請求項１乃至８何れか一項記載の装置。

【請求項10】

前記ディスプレースメントファクタフィールドのコンテンツは、−１２８〜１２７までの符号付きの値として解釈される、請求項９記載の装置。

【請求項11】

前記複数のメモリアクセスサイズは、前記メモリアクセスにおけるバイト数に対応する、請求項１乃至１０何れか一項記載の装置。

【請求項12】

前記複数のメモリアクセスサイズは、１バイト、２バイト、４バイト、８バイト、１６バイト、３２バイト及び６４バイトである、請求項１乃至１１何れか一項記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、参照することによりここに援用される２０１１年４月１日に出願された米国仮出願第６１／４７１，０４３号の利益を請求する。
［分野］
本発明の実施例は、コンピュータの分野に関し、より詳細にはプロセッサによりサポートされる命令セットに関する。

【背景技術】

【0002】

命令セット又はＩＳＡ（Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ）は、ネイティブデータタイプ、命令、レジスタアーキテクチャ、アドレッシングモード、メモリアーキテクチャ、インタラプト及び例外処理並びに外部入出力（Ｉ／Ｏ）を含むプログラミングに関するコンピュータアーキテクチャの一部である。命令という用語は一般にここではマクロ命令、すなわち、実行用にプロセッサに提供される命令であり、プロセッサのデコーダがマクロ命令を復号化した結果であるマイクロ命令又はマイクロｏｐｓと対照的なものであることに留意すべきである。

【0003】

ＩＳＡは、命令セットを実現するのに利用されるプロセッサ設計技術のセットであるマイクロアーキテクチャと区別される。異なるマイクロアーキテクチャを有するプロセッサは、共通する命令セットを共有できる。例えば、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標） ４プロセッサ、Ｉｎｔｅｌ Ｃｏｒｅプロセッサ及びカリフォルニア州のＳｕｎｎｙｖａｌｅのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓのプロセッサは、ｘ８６命令セットとほぼ同じバージョン（より新しいバージョンでは拡張が加えられている）を実装するが、異なる内部設計を有している。例えば、ＩＳＡの同一のレジスタアーキテクチャは、専用の物理レジスタ、レジスタリネーミング機構（例えば、米国特許第５，４４６，９１２号に記載されるようなＲＡＴ（Ｒｅｇｉｓｔｅｒ Ａｌｉａｓ Ｔａｂｌｅ、ＲＯＢ（Ｒｅｏｒｄｅｒ Ｂｕｆｆｅｒ）及びリタイアメントレジスタファイルの利用、米国特許第５，２０７，１３２号に記載されるような複数のマップ及びレジスタのプールの利用など）を用いた１以上の動的割当てされた物理レジスタを含む周知の技術を利用した異なるマイクロアーキテクチャにおいて異なる方法により実現される。特段の断りがない場合、レジスタアーキテクチャ、レジスタファイル及びレジスタという用語は、ここではソフトウェア／プログラマに可視的なものと命令がレジスタを指定する方法とについて用いられる。区別が必要な場合、論理的、アーキテクチャ的又はソフトウェア可視的という形容詞が、レジスタアーキテクチャのレジスタ／ファイルを示すのに使用され、異なる形容詞が所与のマイクロアーキテクチャにおける指定レジスタをについて用いられる（例えば、物理レジスタ、リオーダバッファ、リタイアメントレジスタ、レジスタプールなど）。

【0004】

命令セットは、１以上の命令フォーマットを含む。所与の命令フォーマットは、特に実行対象の処理及び当該処理の実行対象のオペランドを指定するための各種フィールド（ビット数、ビット位置）を定義する。いくつかの命令フォーマットはさらに、命令テンプレート（又はサブフォーマット）の定義にもかかわらず分割される。例えば、所与の命令フォーマットの命令テンプレートは、命令フォーマットのフィールドの異なるサブセットを有するよう定義されてもよく（包含されるフィールドは典型的には同一の順序であるが、より少数のフィールドしか含まれていないため、少なくとも一部は異なるビットポジションを有する）、及び／又は所与のフィールドを異なって解釈させるよう定義される。所与の命令は、所与の命令フォーマットを用いて表現され（及び、定義されている場合、当該命令フォーマットの命令テンプレートの所与のものにおいて）、処理及びオペランドを指定する。命令ストリームは、シーケンスの各命令が命令フォーマットの命令の出現である具体的な命令シーケンスである（及び定義されている場合、当該命令フォーマットの命令テンプレートの所与のもの）。

【0005】

科学、金融、自動ベクトル化汎用、ＲＭＳ（Ｒｅｃｏｇｎｉｔｉｏｎ，Ｍｉｎｉｎｇ ａｎｄ Ｓｙｎｔｈｅｓｉｓ）／ビジュアル及びマルチメディアアプリケーション（２Ｄ／３Ｄグラフィックス、画像処理、ビデオ圧縮／伸張、音声認識アルゴリズム及びオーディオ操作など）はしばしば、同一の処理が多数のデータアイテムに対して実行されることを要求する（“データ並列化”と呼ばれる）。ＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）は、プロセッサに同一の処理を複数のデータアイテムに対して実行させる命令タイプを表す。ＳＩＭＤ技術は、各データ要素が別個の値を表す多数の固定サイズのデータ要素にレジスタのビットを論理的に分割可能なプロセッサに特に適している。例えば、６４ビットレジスタのビットは、各データ要素が別個の１６ビット値を表す４つの別個の１６ビットデータ要素に対して実行されるソースオペランドとして指定されてもよい。このタイプのデータは、Ｐａｃｋｅｄデータタイプ又はベクトルデータタイプと呼ばれ、当該データタイプのオペランドはＰａｃｋｅｄデータオペランド又はベクトルオペランドと呼ばれる。すなわち、Ｐａｃｋｅｄデータアイテム又はベクトルはＰａｃｋｅｄデータ要素のシーケンスを表し、Ｐａｃｋｅｄデータオペランド又はベクトルオペランドは、ＳＩＭＤ命令のソース又はデスティネーションオペランドである（Ｐａｃｋｅｄデータ命令又はベクトル命令としても知られる）。

【0006】

例えば、１つのタイプのＳＩＭＤ命令は、同一のデータ要素の順序による同数のデータ要素を有する同一サイズのデスティネーションベクトルオペランド（結果ベクトルオペランドとも呼ばれる）を生成するため、２つのソースベクトルオペランドに対して垂直的に実行される単一のベクトル演算を指定する。ソースベクトルオペランドのデータ要素はソースデータ要素と呼ばれ、デスティネーションベクトルオペランドのデータ要素はデスティネーション又は結果データ要素と呼ばれる。これらのソースベクトルオペランドは、同じサイズを有し、同じ幅のデータ要素を含み、同数のデータ要素を含む。２つのソースベクトルオペランドの同じビットポジションのソースデータ要素は、データ要素のペア（対応するデータ要素とも呼ばれる）を構成する。当該ＳＩＭＤ命令により指定される処理は、一致する個数の結果データ要素を生成するため、これらのソースデータ要素のペアのそれぞれに対して別々に実行され、ソースデータ要素の各ペアは対応する結果データ要素を有する。当該処理は垂直的であり、結果ベクトルオペランドは同じサイズであり、同数のデータ要素を有し、結果データ要素はソースベクトルオペランドと同じデータ要素の順序に格納されるため、結果データ要素は、ソースベクトルオペランドのソースデータ要素のそれらの対応するペアと同じ結果ベクトルオペランドのビットポジションにある。この例示的なタイプのＳＩＭＤ命令に加えて、他の各種タイプのＳＩＭＤ命令がある（例えば、１つのみのソースベクトルオペランドを有するものや２つより多くのソースベクトルオペランドを有するもの、水平的に処理されるもの、異なるサイズを有する結果ベクトルオペランドを生成するもの、異なるサイズのデータ要素を有するもの、及び／又は異なるデータ要素順序を有するものなど）。デスティネーションベクトルオペランド（又はデスティネーションオペランド）は、他の命令により（他の命令による同一位置の指定により）ソースオペランドとしてアクセスされるように、デスティネーションオペランドのある位置への格納（当該命令により指定されるレジスタ又はメモリアドレス）を含む、命令により指定される処理の直接的な実行結果として定義されることが理解されるべきである。

【0007】

ｘ８６、ＭＭＸ^ＴＭ、Ｓｔｒｅａｍｉｎｇ ＳＩＭＤ Ｅｘｔｅｎｓｉｏｎｓ（ＳＳＥ）、ＳＳＥ２、ＳＳＥ３、ＳＳＥ４．１及びＳＳＥ４．２命令を含む命令セットを有するＩｎｔｅｌ（登録商標）Ｃｏｒｅ^ＴＭプロセッサにより利用されるものなどのＳＩＭＤ技術は、アプリケーションのパフォーマンスの大きな向上を可能にした（Ｃｏｒｅ^ＴＭ及びＭＭＸ^ＴＭは、カリフォルニア州Ｓａｎｔａ Ｃｌａｒａのインテルコーポレイションの登録商標又は商標である）。Ａｄｖａｎｃｅｄ Ｖｅｃｔｏｒ Ｅｘｔｅｎｓｉｏｎｓ（ＡＶＸ）と呼ばれ、ＶＥＸ符号化スキームを利用する将来的なＳＩＭＤ拡張のさらなるセットが公開された。

【発明の概要】

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

【0008】

上述した問題点を鑑み、本発明の課題は、ベクトルフレンドリ命令フォーマット及びその実行を提供することである。

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

【0009】

上記課題を解決するため、本発明の一態様は、命令セットを実行するよう構成されるプロセッサを有する装置であって、前記命令セットは、第１命令フォーマットを有し、前記第１命令フォーマットは、ベース処理フィールド、モディファイアフィールド、データ要素幅フィールド及び拡張処理フィールドを含む複数のフィールドを有し、前記第１命令フォーマットは、前記ベース処理フィールドの異なる値により複数の異なるベクトル処理の指定をサポートし、前記複数のベクトル処理の各々は、異なるデータ要素位置の複数のデータ要素を有し、前記第１命令フォーマットは、前記モディファイアフィールドの異なる値によりメモリアクセス処理及び非メモリアクセス処理の指定をサポートし、前記モディファイアフィールドのコンテンツがスケーリングされたディスプレースメントによるメモリアクセス処理を指定するとき、前記第１命令フォーマットは、ディスプレースメントファクタフィールドを含み、前記ベース処理フィールド、前記モディファイアフィールド、前記データ要素幅フィールド及び前記拡張処理フィールドはそれぞれ、前記第１命令フォーマットの命令の各出現に対して１つのみの値を格納可能であり、前記プロセッサは、命令ストリームに出現する前記第１命令フォーマットの命令を実行するプロセッサパイプラインを含み、前記パイプラインは、スケーリングされたディスプレースメントによるメモリアクセスを指定する前記第１命令フォーマットの命令の出現と前記メモリアクセスを指定しない前記第１命令フォーマットの命令の出現とを前記異なる出現における前記モディファイアフィールドのコンテンツに基づき区別し、前記モディファイアフィールドのコンテンツによりスケーリングされたディスプレースメントによりメモリアクセスを指定する出現について、前記ベース処理フィールド、前記データ要素幅フィールド及び前記拡張処理フィールドの２以上のコンテンツに基づき複数のメモリアクセスサイズの間で区別し、前記モディファイアフィールドのコンテンツによりスケーリングされたディスプレースメントによりメモリアクセスを指定する出現の各々について、前記メモリアクセスのサイズと前記ディスプレースメントファクタフィールドのコンテンツとの乗算に基づきスケーリングされたディスプレースメントを決定し、前記スケーリングされたディスプレースメントはアドレスを生成するのに利用されるべきであるよう構成される装置に関する。

【発明の効果】

【0010】

本発明によると、ベクトルフレンドリ命令フォーマット及びその実行を提供することができる。

【図面の簡単な説明】

【0011】

本発明は、本発明の実施例を説明するのに利用される以下の説明及び添付した図面を参照することによって最も良く理解されるであろう。

【図1A】図１Ａは、本発明の一実施例によるベクトルフレンドリ命令フォーマットによる命令をのみを有する命令ストリームを示すブロック図である。

【図1B】図１Ｂは、本発明の一実施例による複数の命令フォーマットによる命令を有する命令ストリームを示すブロック図である。

【図2A】図２Ａは、本発明の実施例による汎用的なベクトルフレンドリ命令フォーマット及びそれのクラスＡ命令テンプレートを示すブロック図である。

【図2B】図２Ｂは、本発明の実施例による汎用的なベクトルフレンドリ命令フォーマット及びそれのクラスＢ命令テンプレートを示すブロック図である。

【図3A】図３Ａは、本発明の実施例による一例となる具体的なベクトルフレンドリ命令フォーマットを示すブロック図である。

【図3B】図３Ｂは、本発明の一実施例によるフルオペコードフィールド２７４を構成する具体的なベクトルフレンドリ命令フォーマット３００のフィールドを示すブロック図である。

【図3C】図３Ｃは、本発明の一実施例によるレジスタインデックスフィールド２４４を構成する具体的なベクトルフレンドリ命令フォーマット３００のフィールドを示すブロック図である。

【図3D】図３Ｄは、本発明の一実施例による拡張処理フィールド２５０を構成する具体的なベクトルフレンドリ命令フォーマット３００のフィールドを示すブロック図である。

【図4A】図４Ａは、本発明の一実施例によるベクトルフレンドリ命令フォーマットのフィールドの一部の内部関係を示すフロー図の一部である。

【図4B】図４Ｂは、本発明の一実施例によるベクトルフレンドリ命令フォーマットのフィールドの一部の内部関係を示すフロー図の第２部分である。

【図4C】図４Ｃは、本発明の一実施例によるベクトルフレンドリ命令フォーマットのフィールドの一部の内部関係を示すフロー図の第３部分である。

【図4D】図４Ｄは、本発明の一実施例によるベクトルフレンドリ命令フォーマットのフィールドの一部の内部関係を示すフロー図の残りの部分である。

【図4E】図４Ｅは、本発明の一実施例によるブロック４１５Ａ〜Ｈのそれぞれの分解図である。

【図5】図５は、本発明の一実施例によるレジスタアーキテクチャ５００のブロック図である。

【図6A】図６Ａは、本発明の実施例による非メモリアクセスタイプ処理のレジスタインデックスフィールド２４４のフロー図である。

【図6B】図６Ｂは、本発明の実施例によるメモリアクセスタイプ処理のレジスタインデックスフィールド２４４、スケールフィールド２６０、ディスプレイスメントフィールド２６２Ａ及びディスプレイスメントファクタフィールド２６２Ｂの利用を示すフロー図である。

【図6C】図６Ｃは、本発明の実施例によるｄｉｓｐ８、ｄｉｓｐ３２及びスケーリングされたディスプレイスメントの変形の間の相違を示すテーブルである。

【図7A】図７Ａは、本発明の実施例によるラウンドコントロールフィールド２５４Ａにより指定されうる可能な処理のグループを示すテーブルである。

【図7B】図７Ｂは、本発明の実施例によるラウンドコントロールフィールド２５９Ａにより指定されうる可能な処理のグループを示すテーブルである。

【図8A】図８Ａは、本発明の実施例によるデータ要素の幅が６４ビットであるときのデータ変換フィールド２５４Ｂにより指定されうる可能なデータ変換処理のグループを示すテーブルである。

【図8B】図８Ｂは、本発明の実施例によるデータ要素の幅が３２ビットであるデータ変換フィールド２５４Ｂにより指定されうる可能なデータ変換処理のグループを示すテーブルである。

【図9】図９は、本発明の実施例によるクロスプロダクトスウィズル８１５を示すブロック図である。

【図10A】図１０Ａは、本発明の実施例による４要素パケット８２０への要素のブロードキャスを示すブロック図である。

【図10B】図１０Ｂは、本発明の実施例による３２ビットデータ要素の１要素粒度のブロードキャスを示すブロック図である。

【図10C】図１０Ｃは、本発明の実施例による３２ビットデータ要素の４要素粒度のブロードキャストを示すブロック図である。

【図11A】図１１Ａは、本発明の実施例によるオペコードマップフィールドにより指定されうる可能なオペコードマップのグループを示すテーブルである。

【図11B】図１１Ｂは、本発明の実施例によるオペコードマップフィールドにより指定されうる可能なプリフィックス符号化のグループを示すテーブルである。

【図12A】図１２Ａは、本発明の実施例によるデータ要素幅が６４ビットであるｌｏａｄ／ｏｐ ｉｎｔについてデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図12B】図１２Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるｌｏａｄ／ｏｐ ｉｎｔについてデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図12C】図１２Ｂは、本発明の実施例によるデータ要素幅が６４ビットであるｌｏａｄ／ｏｐ ｆｐについてデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図12D】図１２Ｄは、本発明の実施例によるデータ要素幅が３２ビットであるｌｏａｄ／ｏｐ ｆｐについてデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図13A】図１３Ａは、本発明の実施例によるデータ要素幅が６４ビットであるｌｏａｄ ｉｎｔについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図13B】図１３Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるｌｏａｄ ｉｎｔについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図13C】図１３Ｃは、本発明の実施例によるデータ要素幅が６４ビットであるｌｏａｄ ｆｐについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図13D】図１３Ｄは、本発明の実施例によるデータ要素幅が３２ビットであるｌｏａｄ ｆｐについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図14A】図１４Ａは、本発明の実施例によるデータ要素幅が６４ビットであるｓｔｏｒｅ ｉｎｔについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図14B】図１４Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるｓｔｏｒｅ ｉｎｔについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図14C】図１４Ｃは、本発明の実施例によるデータ要素幅が６４ビットであるｓｔｏｒｅ ｆｐについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図14D】図１４Ｄは、本発明の実施例によるデータ要素幅が３２ビットであるｓｔｏｒｅ ｆｐについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図15A】図１５Ａは、本発明の実施例によるデータ要素幅が３２ビットであるｌｏａｄ ｇｒａｐｈｉｃｓについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図15B】図１５Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるｌｏａｄ ｐａｃｋｅｄ ｇｒａｐｈｉｃｓについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図15C】図１５Ｃは、本発明の実施例によるデータ要素幅が３２ビットであるｓｔｏｒｅ ｇｒａｐｈｉｃｓについてデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。

【図16】図１６Ａは、本発明の実施例によるデータ要素幅が３２ビットであり、第２ソース及びデスティネーションが同じであるライトマスクレジスタＫ１におけるライトマスクを用いてマージする一例となる処理１６００を示すブロック図であり、図１６Ｂは、本発明の実施例によるデータ要素幅が３２ビットであり、第２ソース及びデスティネーションが同じであるすべて１の配線化マスク（配線ライトマスクはライトマスクレジスタＫ０を指定する命令により利用される）を用いてマージする一例となる処理１６２５を示すブロック図であり、図１６Ｃは、本発明の実施例による８、１６、３２及び６４ビットデータ要素幅の５１２ビットベクトルのデータ要素ポジションとライトマスクレジスタのビットとの対応関係を示すブロック図であり、図１６Ｄは、本発明の実施例によるデータ要素幅が３２ビットであり、第２ソース及びデスティネーションが異なるライトマスクレジスタＫ１におけるライトマスクを用いてマージする一例となる処理１６６０を示すブロック図であり、図１６Ｅは、本発明の実施例によるデータ要素幅が３２ビットであり、第２ソース及びデスティネーションが異なるライトマスクレジスタＫ１におけるライトマスクを用いてゼロにする一例となる処理１６６６を示すブロック図である。

【図17】図１７Ａは、本発明の実施例による一例となる具体的なベクトルフレンドリ命令フォーマットからのフィールドのサブセットを示し、図１７Ｂは、本発明の実施例による図１７Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトル負レイン取り命令からのフィールドのサブセットを示し、図１７Ｃは、本発明の実施例による図１７Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示し、図１７Ｄは、本発明の実施例による図１７Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示す。

【図18】図１８Ａは、本発明の実施例による一例となる具体的なベクトルフレンドリ命令フォーマットからのフィールドのサブセットを示し、図１８Ｂは、本発明の実施例による図１８Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示し、図１８Ｃは、本発明の実施例による図１８Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示し、図１８Ｄは、本発明の実施例による図１８Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示し、図１８Ｅは、本発明の実施例による図１８Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示し、図１８Ｆは、本発明の実施例による図１８Ａの具体的なベクトルフレンドリ命令フォーマットに符号化された一例となる具体的なベクトルフレンドリ命令からのフィールドのサブセットを示す。

【図19】図１９Ａは、本発明の実施例によるクラスＡの非メモリアクセスフルラウンドコントロールタイプ処理２１０の命令テンプレートの何れのフィールドが第１プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図１９Ｂは、本発明の実施例によるクラスＡの非メモリアクセスデータ変換タイプ処理２１５の命令テンプレートの何れのフィールドが第１プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図１９Ｃは、本発明の実施例によるクラスＡのメモリアクセス２２０の命令テンプレートの何れのフィールドが第１プロセッサパイプラインの異なる段階で利用されるか示すブロック図である。

【図20】図２０Ａは、本発明の実施例によるクラスＡの非メモリアクセスフルラウンドコントロールタイプ処理２１０の命令テンプレートの何れのフィールドが第２プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図２０Ｂは、本発明の実施例によるクラスＡの非メモリアクセスデータ変換タイプ処理２１５の命令テンプレートの何れのフィールドが第２プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図２０Ｃは、本発明の実施例によるクラスＡのメモリアクセス２２０の命令テンプレートの何れのフィールドが第２プロセッサパイプラインの異なる段階で利用されるか示すブロック図である。

【図21】図２１Ａは、本発明の実施例によるクラスＡの非メモリアクセスフルラウンドコントロールタイプ処理２１０の命令テンプレートの何れのフィールドが第３プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図２１Ｂは、本発明の実施例によるクラスＡの非メモリアクセスデータ変換タイプ処理２１５の命令テンプレートの何れのフィールドが第３プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図２１Ｃは、本発明の実施例によるクラスＡのメモリアクセス２２０の命令テンプレートの何れのフィールドが第３プロセッサパイプラインの異なる段階で利用されるか示すブロック図である。

【図22】図２２Ａは、本発明の実施例によるクラスＡの非メモリアクセスフルラウンドコントロールタイプ処理２１０の命令テンプレートの何れのフィールドが第４プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図２２Ｂは、本発明の実施例によるクラスＡの非メモリアクセスデータ変換タイプ処理２１５の命令テンプレートの何れのフィールドが第４プロセッサパイプラインの異なる段階で利用されるか示すブロック図であり、図２２Ｃは、本発明の実施例によるクラスＡのメモリアクセス２２０の命令テンプレートの何れのフィールドが第４プロセッサパイプラインの異なる段階で利用されるか示すブロック図である。

【図23A】図２３Ａは、本発明の実施例によるオンダイインターコネクトネットワーク２３０２との接続と共に、レベル２（Ｌ２）キャッシュ２３０４のローカルサブセットを有するシングルＣＰＵコアのブロック図である。

【図23B】図２３Ｂは、本発明の実施例による図２３ＡのＣＰＵコアの一部の分解図である。

【図24】図２４は、本発明の実施例による一例となるアウト・オブ・オーダアーキテクチャを示すブロック図である。

【図25】図２５は、本発明の一実施例によるシステム２５００のブロック図である。

【図26】図２６は、本発明の一実施例による第２システム２６００のブロック図である。

【図27】図２７は、本発明の一実施例による第３システム２７００のブロック図である。

【図28】図２８は、本発明の一実施例によるＳｏＣ２８００のブロック図である。

【図29】図２９は、本発明の実施例による統合されたメモリコントローラ及びグラフィックスを備えたシングルコアプロセッサ及びマルチコアプロセッサ２９００のブロック図である。

【図30】図３０は、本発明の実施例によるソース命令セットのバイナリ命令をターゲット命令セットのバイナリ命令に変換するためソフトウェア命令コンバータの利用する示すブロック図である。

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

【0012】

以下の説明では、ロジック実現形態、オペコード、オペランド指定方法、リソースパーティション化／共有化／複製実現形態、システムコンポーネントのタイプ及び相互関係並びにロジックパーティション化／統合選択などの多数の具体的詳細が、本発明のより完全な理解を提供するため与えられる。しかしながら、本発明はこのような具体的な詳細なしに実施されてもよいことが当業者に理解されるであろう。他の例では、本発明を不明りょうにしないため、制御構造、ゲートレベル回路及びフルソフトウェア命令シーケンスは図示されていない。当業者は、包含された説明によって過度の実験なく適切な機能を実現可能であろう。

【0013】

本明細書を通じた“一実施例”、“実施例”又は“１以上の実施例”などの表現は、ある特徴が本発明の実施例の実現に含まれてもよいが、すべての実施例が当該特徴を必ずしも含む必要がないことを意味することがまた、理解されるべきである。同様に、本説明における各種特徴は、本開示を簡素化し、様々な発明の特徴の理解に資するため、単一の実施例、図面又はその説明に一緒にグループ化されることもある。さらに、ある特徴、構成又は特性がある実施例に関して説明されるとき、明示的に説明されているか否かにかかわらず、他の実施例に関して当該特徴、構成又は特性を実行することは当業者の知識の範囲内であることが主張される。しかしながら、この開示の方法は、各請求項に明示的に記載されるよりも本発明がより多くの特徴を要求する意図を反映するものとして解釈されるべきでない。むしろ、以下の請求項が反映するように、発明の態様は単一の開示された実施例のすべての特徴より少ないものであってもよい。従って、詳細な説明に後続する請求項はこの詳細な説明に明示的に含まれ、各請求項が本発明の独立した実施例として自立する。

【0014】

以下の説明及び請求項では、“結合”及び“接続”という用語が、それらの派生語と共に利用されてもよい。これらの用語は互いに同義語として意図されてないことが理解されるべきである。“結合”は、互いに直接的な物理的又は電気的セッション状態にあってもよいし、又はなくてもよい２以上の要素が互いに連係又はやりとりすることを示すのに利用される。“接続”は、互いに結合された２以上の要素の間の通信の確立を示すのに利用される。

【0015】

フロー図の処理は、ブロック図の例示的な実施例を参照して説明される。しかしながら、フロー図の処理はブロック図を参照して説明された以外の本発明の実施例により実行可能であり、ブロック図を参照して説明される実施例はフロー図を参照して説明されたものと異なる処理を実行可能であることが理解されるべきである。

【0016】

理解を容易にするため、破線はあるアイテムの任意的な性質（例えば、本発明の所与の実現形態によりサポートされていない特徴、所与の実現形態によりサポートされているが、ある状況では利用されるが、他の状況では利用されない特徴など）を示すため図面において利用されている。

【0017】

ベクトルフレンドリ命令フォーマット−図１〜１６
ベクトルフレンドリ命令フォーマットは、ベクトル命令に適した命令である（例えば、ベクトル処理に特有のフィールドがあるなど）。ベクトル処理とスカラ処理との双方がベクトルフレンドリ命令フォーマットを介しサポートされる実施例が説明されるが、他の実施例はベクトルフレンドリ命令フォーマットによるベクトル処理のみを利用する。
［命令フォーマットの個数−図１Ａ〜１Ｂ］
・１つの命令フォーマット−図１Ａ
図１Ａは、本発明の一実施例によるベクトルフレンドリ命令フォーマットによる命令のみを有する命令ストリームを示すブロック図である。命令ストリームは、すべてがベクトルフレンドリフォーマット１００Ａ〜１００ＪによるＪ個の命令のシーケンスを含む。本発明の一実施例では、プロセッサは、ベクトル命令フォーマットのみをサポートし、当該命令ストリームを実行可能である。
・複数の命令フォーマット−図１Ｂ
図１Ｂは、本発明の一実施例による複数の命令フォーマットによる命令を有する命令ストリームを示すブロック図である。命令ストリームの各命令は、ベクトルフレンドリ命令フォーマット、第２フォーマット又は第３フォーマットにより表現される。命令ストリームは、Ｊ個の命令１１０Ａ〜１１０Ｊを有する。本発明の一実施例では、プロセッサは、複数の命令フォーマット（図１Ｂに示されるフォーマットを含む）をサポートし、図１Ａ〜１Ｂの双方の命令ストリームを実行可能である。
［例示的な汎用的ベクトルフレンドリ命令フォーマット−図２Ａ〜Ｂ］
図２Ａ〜Ｂは、本発明の実施例による汎用的ベクトルフレンドリ命令フォーマット及びそれの命令テンプレートを示すブロック図である。図２Ａは、本発明の実施例による汎用的ベクトルフレンドリ命令フォーマット及びそのクラスＡ命令テンプレートを示すブロック図であり、図２Ｂは、本発明の実施例による汎用的ベクトルフレンドリ命令フォーマット及びそのクラスＢ命令テンプレートを示すブロック図である。具体的には、クラスＡ及びクラスＢ命令テンプレートとして定義される汎用的ベクトルフレンドリ命令フォーマット２００は、その双方が非メモリアクセス２０５の命令テンプレートとメモリアクセス２２０の命令テンプレートとを含む。ベクトルフレンドリ命令フォーマットに関する汎用的という用語は、何れか特定の命令セットに結び付けされていない命令フォーマットを参照する。ベクトルフレンドリ命令フォーマットの命令がレジスタ（非メモリアクセス２０５の命令テンプレート）又はレジスタ／メモリ（メモリアクセス２２０の命令テンプレート）をソースとするベクトルに対して実行される実施例が説明される一方、本発明の他の実施例はこれらの１つしかサポートしなくてもよい。また、ベクトル命令フォーマットによるロード及びストア命令がある本発明の実施例が説明される一方、他の実施例はさらに又は代わりに、レジスタに及びレジスタからベクトルを移動する異なる命令フォーマットによる命令を有する（メモリからレジスタへ、レジスタからメモリへ、レジスタ間など）。さらに、２つのクラスの命令テンプレートをサポートする本発明の実施例が説明される一方、他の実施例はこれらの１つのみ又は２より多くをサポートしてもよい。

【0018】

ベクトルフレンドリ命令フォーマットが、３２ビット（４バイト）又は６４ビット（８バイト）データ要素幅（又はサイズ）を有する６４バイトベクトルオペランド長（又はサイズ）（及び６４バイトベクトルは１６ダブルワードサイズ要素又は８クワドワードサイズ要素から構成される）、１６ビット（２バイト）又は８ビット（１バイト）データ要素幅（又はサイズ）を有する６４バイトベクトルオペランド長（又はサイズ）、３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）又は８ビット（１バイト）データ要素幅（又はサイズ）を有する３２バイトベクトルオペランド長（又はサイズ）、３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）又は８ビット（１バイト）データ要素幅（又はサイズ）を有する１６バイトベクトルオペランド長（又はサイズ）をサポートする一方、他の実施例は、より多く、より少なく又は異なるデータ要素幅（１２８ビット（１６バイト）データ要素幅など）を有するより多い、より少ない及び／又は異なるベクトルオペランドサイズ（２５６バイトベクトルオペランドなど）をサポートしてもよい。

【0019】

図２ＡのクラスＡ命令テンプレートは、１）非メモリアクセス２０５の命令テンプレート内には、非メモリアクセスフルラウンド制御タイプ処理２１０の命令テンプレートと、非メモリアクセスデータ変換タイプ処理２１５の命令テンプレートとが示され、２）メモリアクセス２２０の命令テンプレート内には、メモリアクセス一時的２２５命令テンプレートとメモリアクセス非一時的２３０命令テンプレートとが示される、ことを含む。図２ＢのクラスＢ命令テンプレートは、１）非メモリアクセス２０５命令テンプレート内には、非メモリアクセスライトマスク制御パーシャルラウンド制御タイプ処理２１２命令テンプレートと、非メモリアクセスライトマスク制御ｖｓｉｚｅタイプ処理２１２命令テンプレートと、非メモリアクセスライトマスク制御ｖｓｉｚｅタイプ処理２１７命令テンプレートとが示され、２）メモリアクセス２２０命令テンプレート内には、メモリアクセスライトマスク制御２２７命令テンプレートが示される、ことを含む。
・フォーマット
汎用的ベクトルフレンドリ命令フォーマット２００は、図２Ａ〜Ｂに示される順序により以下でリストされたフィールドを含む。

【0020】

フォーマットフィールド２４０−当該フィールドの特定の値（命令フォーマット識別子の値）は、ベクトルフレンドリ命令フォーマットと、命令ストリームのベクトルフレンドリ命令フォーマットの命令の発生とを一意的に特定する。従って、フォーマットフィールド２４０のコンテンツは、第１命令フォーマットの命令の発生と他の命令フォーマットの命令の発生とを区別し、これにより、ベクトルフレンドリ命令フォーマットの他の命令フォーマットを有する命令セットへの導入を可能にする。また、当該フィールドは、それが汎用的ベクトルフレンドリ命令フォーマットしか有さない命令セットについて不要であるという点で任意的である。

【0021】

ベース処理フィールド２４２−それのコンテンツは、異なるベース処理を区別する。後述されるように、ベース処理フィールド２４２は、オペコードフィールドを含み、及び／又はその一部であってもよい。

【0022】

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

【0023】

モディファイアフィールド２４６−それのコンテンツは、メモリアクセスを指定する汎用的ベクトル命令フォーマットの命令の発生と、それを指定しないものとを、すなわち、非メモリアクセス２０５命令テンプレートとメモリアクセス２２０命令テンプレートとの間を区別する。メモリアクセス処理はメモリ階層との間でリード及びライトを実行するが（いくつかのケースでは、レジスタの値を用いたソース及び／又はデスティネーションアドレス）、非メモリアクセス処理はこれらを実行しない（例えば、ソース及びデスティネーションはレジスタである）。一実施例では、当該フィールドはまたメモリアドレス計算を実行するための３つの異なる方法を選択するが、他の実施例は、メモリアドレス計算を実行するためのより多く、より少なく又は異なる方法をサポートしてもよい。

【0024】

拡張処理フィールド２５０−それのコンテンツは、ベース処理に加えて実行される各種の異なる処理の何れかを区別する。当該フィールドは、コンテクストに特有のものである。本発明の一実施例では、当該フィールドは、クラスフィールド２６８、アルファフィールド２５２及びベータフィールド２５４に分割される。拡張処理フィールドは、共通する処理グループが２、３又は４個の命令でなく単一の命令により実行されることを可能にする。拡張フィールド２５０を利用して要求される命令の個数を低減するいくつかの命令の例（これらの名称は以降でより詳細に説明される）が後述される。

【0025】

【表1】

ただし、［ｒａｘ］はアドレス生成用の利用されるベースポインタであり、｛｝はデータ操作フィールドにより指定される変換処理を示す（以下でより詳細に説明される）
スケールフィールド２６０−それのコンテンツは、メモリアドレス生成のためのインデックスフィールドのコンテンツのスケーリングを可能にする（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅを利用するアドレス生成のためなど）。

【0026】

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

【0027】

ディスプレースメントファクタフィールド２６２Ｂ（ディスプレースメントファクタフィールド２６２Ｂ上の直接的なディスプレースメントフィールド２６２Ａの並置は、一方又は他方が利用されることを示すことに留意されたい）−それのコンテンツはアドレス生成の一部として利用され、それはメモリアクセスのサイズ（Ｎ）によってスケーリングされるべきディスプレースメントファクタを指定する−ただし、Ｎはメモリアドレスにおけるバイト数である（例えば、２^{ｓｃａｌｅ}＊ｉｎｄｅｘ＋ｂａｓｅ＋ｓｃａｌｅｄ ｄｉｓｐｌａｃｅｍｅｎｔを利用したアドレス生成のためなど）。冗長な低オーダビットは無視され、ディスプレースメントファクタフィールドのコンテンツが、有効アドレスを計算するのに利用される最終的なディスプレースメントを生成するため、メモリオペランドのトータルサイズ（Ｎ）と乗算される。Ｎの値は、後述されるフルオペコードフィールド２７４（後述される）及びデータ操作フィールド２５４Ｃに基づきランタイム時にプロセッサハードウェアにより決定される。ディスプレースメントフィールド２６２Ａ及びディスプレースメントファクタフィールド２６２Ｂは、それらが非メモリアクセス２０５命令テンプレートのため利用されず、及び／又は異なる実施例がこれら２つの１つしか又は何れも実現しなくてもよいという意味で任意的である。

【0028】

データ要素幅フィールド２６４−それのコンテンツは、データ要素幅の何れの数が利用されるべきか区別する（いくつかの実施例では、すべての命令について、他の実施例では、命令の一部のみについて）。当該フィールドは、１つのデータ要素幅しかサポートされていない場合、及び／又はオペコードのある態様を利用してデータ要素幅がサポートされる場合、それは不要であるという意味で任意的である。

【0029】

ライトマスクフィールド２７０−それのコンテンツは、データ要素位置単位で。デスティネーションベクトルオペランドのデータ要素位置がベース処理及び拡張処理の結果を反映するか制御する。クラスＡ命令テンプレートは、マージング−ライトマスキングをサポートする一方、クラスＢ命令テンプレートは、マージング−ライトマスキングとゼロ化−ライトマスキングとの双方をサポートする。マージングすると、ベクトルマスクは、デスティネーションの何れかの要素セットが（ベース処理及び拡張処理により指定される）何れかの処理の実行中に更新からプロテクトされることを可能にし、他の実施例では、対応するマスクビットが０を有するデスティネーションの各要素の古い値を保存する。他方、ゼロ化のとき、ベクトルマスクは、デスティネーションの何れかの要素セットが（ベース処理及び拡張処理により指定される）何れかの処理の実行中にゼロ化されることを可能にし、一実施例では、デスティネーションの要素は、対応するマスクビットが０の値を有するとき、０に設定される。この機能のサブセットは、実行される処理のベクトル長を制御する能力である（すなわち、要素のスパンが最初から最後まで変更される）。しかしながら、変更される要素は連続的であることは必要でない。従って、ライトマスクフィールド２７０は、ロード、ストア、算術的、論理的などを含むパーシャルベクトル処理を可能にする。また、当該マスキングは、フォルト抑制に利用可能である（すなわち、フォルトを生じさせる可能性のある／生じさせるであろう何れかの処理の結果の受信を防ぐためのデスティネーションのデータ要素位置をマスキングすることによって、−例えば、メモリのベクトルがページ境界をクロスし、第２ページでなく第１ページがページフォルトを生じさせることを仮定すると、第１ページにあるベクトルのすべてのデータ要素がライトマスクによりマスキングされる場合、ページフォルトは無視できる）。さらに、ライトマスクは、特定タイプの条件ステートメントを含む“ループのベクトル化”を可能にする。ライトマスクフィールド２７０のコンテンツが利用すべきライトマスクを含む複数のライトマスクレジスタの１つを選択する本発明の実施例が説明されるが（及びライトマスクフィールド２７０のコンテンツは、実行されるマスキングを間接的に特定する）、他の実施例はさらに又は代わりに、マスクライトフィールド２７０のコンテンツが実行されるマスキングを間接的に指定することを可能にする。さらに、１）レジスタリネーミングパイプライン段階中、デスティネーションはもはやインプリシットなソースでないため、デスティネーションオペランドがまたソースでない命令（非三項命令とも呼ぶ）に対して利用され（処理結果でない何れかのデータ要素（何れかのマスクされたデータ要素）がゼロ化されるため、現在のデスティネーションレジスタからのデータ要素はリネームされたデスティネーションレジスタにコピーされる必要はなく、又は当該処理と共に搬送される必要もない）、２）ライトバック段階中、ゼロが書き込まれているとき、ゼロ化はパフォーマンスの向上を可能にする。

【0030】

即時（Ｉｍｍｅｄｉａｔｅ）フィールド２７２−それのコンテンツは即時の指定を可能にする。当該フィールドは、それが即時をサポートしない汎用的ベクトルフレンドリフォーマットの実現形態に存在せず、即時を利用しない命令に存在しないという意味で任意的である。
・命令テンプレートクラス選択
クラスフィールド２６８−それのコンテンツは命令の異なるクラスを区別する。図２Ａ〜Ｂを参照して、当該フィールドのコンテンツはクラスＡ命令とクラスＢ命令との間で選択する。図２Ａ〜Ｂでは、丸められた四隅が、特定の値がフィールドにあることを示すのに利用される（例えば、図２Ａ〜Ｂにおけるクラスフィールド２６８のクラスＡ２６８Ａ及びクラスＢ２６８Ｂなど）。
・クラスＡの非メモリアクセス命令テンプレート
クラスＡの非メモリアクセス２０５命令テンプレートのケースでは、アルファフィールド２５２はＲＳフィールド２５２Ａとして解釈され、それのコンテンツは、異なる拡張処理タイプの何れが実行されるべきか区別し（例えば、ラウンド２５２Ａ．１及び変換２５２Ａ．２がそれぞれ非メモリアクセスラウンドタイプ処理２１０命令テンプレートと非メモリアクセスデータ変換タイプ処理２１５命令テンプレートとのそれぞれについて指定される）、ベータフィールド２５４は、指定されたタイプの処理の何れが実行されるべきか区別する。図２において、丸められたコーナーブロックは、指定された値が存在することを示すのに利用される（例えば、モディファイアフィールド２４６の非メモリアクセス２４６Ａ、アルファフィールド２５２／ｒｓフィールド２５２Ａのラウンド２５２Ａ．１及びデータ変換２５２Ａ．２など）。非メモリアクセス２０５命令テンプレートでは、スケールフィールド２６０、ディスプレースメントフィールド２６２Ａ及びディスプレースメントスケールフィールド２６２Ｂは存在しない。
・非メモリアクセス命令テンプレート−フルラウンド制御タイプ処理
非メモリアクセスフルラウンド制御タイプ処理２１０命令テンプレートでは、ベータフィールド２５４はラウンド制御フィールド２５４Ａとして解釈され、それのコンテンツはスタティックなラウンド化を提供する。本発明の説明される実施例では、ラウンド制御フィールド２５４Ａは、ＳＡＥ（Ｓｕｐｐｒｅｓｓ Ａｌｌ ｆｌｏａｔｉｎｇ ｐｏｉｎｔ Ｅｘｃｅｐｔｉｏｎｓ）フィールド２５６及びラウンド処理制御フィールド２５８を含むが、他の実施例は、これらのコンセプトを同一のフィールドに符号化することをサポートか、又はこれらのコンセプト／フィールドの一方又は他方のみを有することをサポートしてもよい（例えば、ラウンド処理制御フィールド２５８のみを有してもよい）。

【0031】

ＳＡＥフィールド２５６−それのコンテンツは、例外イベント報告を不可にするか否か区別する。抑制が有効化されていることをＳＡＥフィールド２５６のコンテンツが示すとき、所与の命令は何れのタイプの浮動小数点例外フラグを報告せず、浮動小数点例外ハンドラを起動しない。

【0032】

ラウンド処理制御フィールド２５８−それのコンテンツは、ラウンド処理のグループの何れが実行されるか区別する（Ｒｏｕｎｄ−ｕｐ、Ｒｏｕｎｄ−ｄｏｗｎ、Ｒｏｕｎｄ−ｔｏｗａｒｄ−ｚｅｒｏ、Ｒｏｕｎｄ−ｔｏ−ｎｅａｒｅｓｔなど）。従って、ラウンド処理制御フィールド２５８は、命令単位でラウンド化モードの変更を可能にし、これが要求されるときに特に有用である。プロセッサがラウンド化モードを指定するための制御レジスタを有する本発明の一実施例では、ラウンド処理制御フィールド２５０のコンテンツは、当該レジスタ値を上書きする（当該制御レジスタに対して保存−変更―復元を実行する必要なくラウンド化モードを選択可能であることが効果的である）。
・非メモリアクセス命令テンプレート−データ変換タイプ処理
非メモリアクセスデータ変換タイプ処理２１５命令テンプレートでは、ベータフィールド２５４はデータ変換フィールド２５４Ｂとして解釈され、それのコンテンツは、複数のデータ変換の何れが実行されるべきか区別する（例えば、非データ変換、スウィズル（ｓｗｉｚｚｌｅ）、ブロードキャストなど）。
・クラスＡのメモリアクセス命令テンプレート
クラスＡのメモリアクセス２２０命令テンプレートのケースでは、アルファフィールド２５２はイビクトヒントフィールド２５２Ｂとして解釈され、それのコンテンツは、イビクトヒントの何れが利用されるべきか区別し（図２Ａでは、一時的２５２Ｂ．１及び非一時的２５２Ｂ．２がそれぞれ、メモリアクセス一時的２２５命令テンプレートとメモリアクセス非一時的２３０命令テンプレートとについて指定される）、ベータフィールド２５４がデータ操作フィールド２５４Ｃとして解釈され、それのコンテンツは、複数のデータ操作処理（プリミティブとして知られる）の何れが実行されるべきか区別する（例えば、非操作、ブロードキャスト、ソースのアップ変換及びデスティネーションのダウン変換など）。メモリアクセス２２０命令テンプレートは、スケールフィールド２６０と、任意的にはディスプレースメントフィールド２６２Ａ又はディスプレースメントスケールフィールド２６２Ｂとを含む。

【0033】

ベクトルメモリ命令は、変換サポートによるメモリからのベクトルロードとメモリへのベクトルストアとを実行する。通常のベクトル命令について、ベクトルメモリ命令はデータ要素毎にメモリとの間でデータを転送し、実際の転送される要素は、ライトマスクとして選択されたベクトルマスクのコンテンツにより指示される。図２Ａにおいて、丸められた四隅は、特定の値がフィールドに存在することを示すのに利用される（例えば、モディファイアフィールド２４６のメモリアクセス２４６Ｂ、アルファフィールド２５２／イビクトヒントフィールド２５２Ｂの一時的２５２Ｂ．１及び非一時的２５２Ｂ．２など）。
・メモリアクセス命令テンプレート−一時的
一時的データは、キャッシュ処理から利益を享受するのに十分すぐに再利用される可能性のあるデータである。すなわち、しかしながら、ヒント及び異なるプロセッサは、ヒントを完全に無視することを含む異なる方法によりそれを実現してもよい。
・メモリアクセス命令テンプレート−非一時的
非一時的データは、第１レベルキャッシュへのキャッシュ処理から利益を享受するのに十分すぐに再利用される可能性のあるデータであり、イビクションについてプライオリティが与えられるべきである。すなわち、しかしながら、ヒント及び異なるプロセッサは、ヒントを完全に無視することを含む異なる方法によりそれを実現してもよい。
・クラスＢの命令テンプレート
クラスＢの命令テンプレートのケースでは、アルファフィールド２５２はライトマスク制御（Ｚ）フィールド２５２Ｃとして解釈され、それのコンテンツは、ライトマスクフィールド２７０により制御されるライトマスキングがマージング又はゼロ化であるべきであるか区別する。
・クラスＢの非メモリアクセス命令テンプレート
クラスＢの非メモリアクセス２０５命令テンプレートのケースでは、ベータフィールド２５４の一部はＲＬフィールド２５７Ａとして解釈され、それのコンテンツは、異なる拡張処理タイプの何れが実行されるべきか区別し（例えば、ラウンド２５７Ａ．１及びベクトル長（ＶＳＩＺＥ）２５７Ａ．２はそれぞれ、非メモリアクセスライトマスク制御パーシャルラウンド制御タイプ処理２１２命令テンプレートと、非メモリアクセスライトマスク制御ＶＳＩＺＥタイプ処理２１７命令テンプレートとについて指定される）、ベータフィールド２５４の残りは、指定されたタイプの処理の何れが実行されるべきか区別する。図２において、丸められたコーナーブロックは、特定の値が存在することを示すのに利用される（例えば、モディファイアフィールド２４６の非メモリアクセス２４６Ａ、ＲＬフィールド２５７Ａのラウンド２５７Ａ．１及びＶＳＩＺＥ２５７Ａ．２など）。非メモリアクセス２０５命令テンプレートでは、スケールフィールド２６０、ディスプレースメントフィールド２６２Ａ及びディスプレースメントスケールフィールド２６２Ｂはない。
・非メモリアクセス命令テンプレート−ライトマスク制御パーシャルラウンド制御タイプ処理
非メモリアクセスライトマスク制御パーシャルラウンド制御タイプ処理２１０命令テンプレートでは、ベータフィールド２５４の残りはラウンド処理フィールド２５９Ａとして解釈され、例外イベント報告は不可とされる（所与の命令は何れのタイプの浮動小数点例外フラグを報告せず、浮動小数点例外ハンドラを起動しない）。

【0034】

ラウンド処理制御フィールド２５９Ａ−ラウンド処理制御フィールド２５８と同様に、それのコンテンツはラウンド又は丸め処理のグループの何れが実行されるべきか区別する（例えば、Ｒｏｕｎｄ−ｕｐ、Ｒｏｕｎｄ−ｄｏｗｎ、Ｒｏｕｎｄ−ｔｏｗａｒｄ−ｚｅｒｏ及びＲｏｕｎｄ−ｔｏ−ｎｅａｒｅｓｔなど）。従って、ラウンド処理制御フィールド２５９Ａは、命令単位でラウンド化モードの変更を可能にし、これが要求されるときに特に有用である。プロセッサがラウンド化モードを指定するため制御レジスタを有する本発明の一実施例では、ラウンド処理制御フィールド２５０のコンテンツは、レジスタ値を無効にする。（制御レジスタに対して保存・変更・復元を実行する必要なくラウンド化モードを選択できることが効果的である。）
・非メモリアクセス命令テンプレート−ライトマスク制御ＶＳＩＺＥタイプ処理
非メモリアクセスライトマスク制御ＶＳＩＺＥタイプ処理２１７命令テンプレートでは、ベータフィールド２５４の残りはベクトル長フィールド２５９Ｂとして解釈され、それのコンテンツは実行対象の複数のデータベクトル長が何れであるか区別する（例えば、１２８、２５６又は５１２バイトなど）。
・クラスＢのメモリアクセス命令テンプレート
クラスＡのメモリアクセス２２０命令テンプレートのケースでは、ベータフィールド２５４の一部はブロードキャストフィールド２５７Ｂとして解釈され、それのコンテンツはブロードキャストタイプデータ操作処理が実行されるべきか区別し、ベータフィールド２５４の残りはベクトル長フィールド２５９Ｂとして解釈される。メモリアクセス２２０命令テンプレートは、スケールフィールド２６０と、任意的にはディスプレースメントフィールド２６２Ａ又はディスプレースメントスケールフィールド２６２Ｂとを有する。
［フィールドに関する追加コメント］
汎用的ベクトルフレンドリ命令フォーマット２００に関して、フォーマットフィールド２４０、ベース処理フィールド２４２及びデータ要素幅フィールド２６４を含むフルオペコードフィールド２７４が示される。フルオペコードフィールド２７４がこれらのフィールドのすべてを含む一実施例が示されるが、フルオペコードフィールド２７４は、それらのすべてを必ずしもサポートしない実施例においては、これらのフィールドのすべてより少なくしか有さない。フルオペコードフィールド２７４は、処理コードを提供する。

【0035】

拡張処理フィールド２５０、データ要素幅フィールド２６４及びライトマスクフィールド２７０は、これらの特徴が汎用的ベクトルフレンドリ命令フォーマットによる命令単位で指定されることを可能にする。

【0036】

ライトマスクフィールドとデータ要素幅フィールドとの組み合わせは、異なるデータ要素幅に基づきマスクが適用されることを可能にするという点で、タイプ化された命令を生成する。

【0037】

命令フォーマットは、他のフィールドのコンテンツに基づき異なる目的のため異なるフィールドを再利用するため、相対的に少数のビットしか必要としない。例えば、１つの観点は、モディファイアフィールドのコンテンツは図２Ａ〜Ｂの非メモリアクセス２０５命令テンプレートとメモリアクセス２２５０命令テンプレートとの間で選択する一方、クラスフィールド２６８のコンテンツは、これらの非メモリアクセス２０５命令テンプレート内で図２Ａの命令テンプレート２１０／２１５と図２Ｂの２１２／２１７との間で選択し、クラスフィールド２６８のコンテンツは、これらのメモリアクセス２２０命令テンプレート内で図２Ａの命令テンプレート２２５／２３０と図２Ｂの２２７との間で選択する。他の観点から、クラスフィールド２６８のコンテンツは、図２Ａ及び２ＢのクラスＡとクラスＢとの命令テンプレートの間で選択し、モディファイアフィールドのコンテンツは、これらのクラスＡ命令テンプレート内で図２Ａの命令テンプレート２０５と２２０との間で選択し、モディファイアフィールドのコンテンツは、これらのクラスＢ命令テンプレート内で図２Ｂの命令テンプレート２０５と２２０との間で選択する。クラスＡ命令テンプレートを示すクラスフィールドのコンテンツのケースでは、モディファイアフィールド２４６のコンテンツは、アルファフィールド２５２の解釈を選択する（ｒｓフィールド２５２ＡとＥＨフィールド２５２Ｂとの間で）。関連する方法では、モディファイアフィールド２４６とクラスフィールド２６８とのコンテンツは、アルファフィールドがｒｓフィールド２５２Ａ、ＥＨフィールド２５２Ｂ又はライトマスク制御（Ｚ）フィールド２５２Ｃとして解釈されるか選択した。クラスＡ非メモリアクセス処理を示すクラス及びモディファイアフィールドのケースでは、拡張フィールドのベータフィールドの解釈は、ｒｓフィールドのコンテンツに基づき変化し、クラスＢ非メモリアクセス処理を示すクラス及びモディファイアフィールドのケースでは、ベータフィールドの解釈はＲＬフィールドのコンテンツに依存する。クラスＡメモリアクセス処理を示すクラス及びモディファイアフィールドのケースでは、拡張フィールドのベータフィールドの解釈はベース処理フィールドのコンテンツに基づき変化し、クラスＢメモリアクセス処理を示すクラス及びモディファイアフィールドのケースでは、拡張フィールドのベータフィールドのブロードキャストフィールド２５７Ｂの解釈は、ベース処理フィールドのコンテンツに基づき変化する。従って、ベース処理フィールド、モディファイアフィールド及び拡張処理フィールドの組み合わせは、より広範な拡張処理が指定されることを可能にする。

【0038】

クラスＡ及びクラスＢ内に検出される各種命令テンプレートは、異なる状況において有用である。クラスＢは、ゼロ化・ライトマスキング又はより小さなベクトル長がパフォーマンスの理由により所望されるときに有用である。例えば、ゼロ化は、デスティネーションと人工的にマージする必要がもはやなくなるため、リネーム処理が利用されるときの偽の従属性を回避することを可能にし、他の例として、ベクトル長制御は、ベクトルマスクによってより短いベクトルサイズをエミュレートするとき、ストア・ロード転送問題を容易にする。クラスＡは、１）ラウンド化モード制御を同時に使用しながら浮動小数点例外を可能にし（すなわち、ＳＡＥフィールドのコンテンツがｎｏを示すとき）、２）アップ変換、スウィズル、スワップ及び／又はダウン変換を利用可能であり、３）グラフィックスデータタイプに対して実行されることが所望されるときに有用である。例えば、アップ変換、スウィズル、スワップ、ダウン変換及びグラフィックデータタイプは、異なるフォーマットによりソースと動作するときに要求される命令数を低減し、他の例として、例外を可能にすることは、指示されたラウンド化モードとの完全なＩＥＥＥ準拠性を提供する。また、本発明のいくつかの実施例では、異なるプロセッサ又はプロセッサ内の異なるコアは、クラスＡのみ、クラスＢのみ又は双方のクラスをサポートしてもよい。例えば、汎用的な計算に対して意図されたハイパフォーマンス汎用的アウト・オブ・オーダコアはクラスＢのみをサポートし、グラフィック及び／又は科学的（スループット）計算に対して主として意図されたコアは、クラスＡのみをサポートし、双方に対して意図されたコアは双方をサポートしてもよい（もちろん、双方のクラスカラのテンプレートと命令とのある混合を有するが、双方のクラスカラのすべてのテンプレートと命令とを必ずしも有さないコアは、本発明の範囲内である）。また、単一のプロセッサが複数のコアを有してもよく、そのすべてが同一のクラスをサポートするか、又は異なるコアが異なるクラスをサポートしてもよい。例えば、別個のグラフィックコア及び汎用コアを備えたプロセッサにおいて、グラフィック及び／又は科学的計算に対して主として意図されたグラフィックコアの１つはクラスＡしかサポートせず、汎用コアの１以上は、クラスＢのみをサポートする汎用計算に対して意図されたアウト・オブ・オーダ例外及びレジスタリネーム処理を備えたハイパフォーマンス汎用コアであってもよい。別個のグラフィックコアを有しない他のプロセッサは、クラスＡとクラスＢとの双方をサポートする１以上の汎用的なイン・オーダ又はアウト・オブ・オーダコアを有してもよい。もちろん、１つのクラスカラの特徴はまた、本発明の異なる実施例では他のクラスにおいて実現されてもよい。ハイレベル言語により記述されたプログラムは、１）実行用のターゲットプロセッサによりサポートされるクラスの命令のみを有するフォーム、又は２）すべてのクラスの命令の異なる組み合わせを利用して記述された他のルーチンを有し、現在コードを実行中のプロセッサによりサポートされる命令に基づき実行すべきルーチンを選択する制御フローコードを有するフォームを含む各種実行可能なフォームに配置される（例えば、ジャストインタイムでコンパイルされるか、又は静的にコンパイルされるなど）。
・例示的な特定のベクトルフレンドリ命令フォーマット−図３Ａ〜Ｄ
図３Ａは、本発明の実施例による例示的な特定のベクトルフレンドリ命令フォーマットを示すブロック図である。図３Ａは、それがフィールドの位置、サイズ、解釈及び順序と共に、フィールドの一部の値を指定するという点で特有の特定のベクトルフレンドリ命令フォーマット３００を示す。特定のベクトルフレンドリ命令フォーマット３００は、ｘ８６命令セットを拡張するのに利用され、フィールドの一部は既存のｘ８６命令セット及びその拡張（ＡＶＸなど）に利用されるものと類似又は同一である。このフォーマットは、拡張を有する既存のｘ８６命令セットのプリフィックス符号化フィールド、リアルオペコードバイトフィールド、ＭＯＤ Ｒ／Ｍフィールド、ＳＩＢフィールド、ディスプレースメントフィールド及び即値フィールドと整合される。図３Ａからのフィールドがマップする図２からのフィールドが示される。

【0039】

本発明の実施例が例示的に汎用的ベクトルフレンドリ命令フォーマット２００に関して特定のベクトルフレンドリ命令フォーマット３００を参照して説明されるが、本発明は、請求される場合を除き、当該特定のベクトルフレンドリ命令フォーマット３００に限定されるものでない。例えば、汎用的ベクトルフレンドリ命令フォーマット２００は、各種フィールドについて可能な様々なサイズを想定する一方、特定のベクトルフレンドリ命令フォーマット３００は、特定サイズのフィールドを有するとして示される。具体例として、データ要素幅フィールド２６４が特定のベクトルフレンドリ命令フォーマット３００における１ビットのフィールドとして示される一方、本発明はこれに限定されるものでない（すなわち、汎用的ベクトルフレンドリ命令フォーマット２００は、データ要素幅フィールド２６４の他のサイズを想定する）。
・フォーマット−図３
汎用的ベクトルフレンドリ命令フォーマット２００は、図３Ａに示される順序により後述される以下のフィールドを含む。

【0040】

ＥＶＥＸプリフィックス（バイト０〜３）
ＥＶＥＸプリフィックス３０２は４バイト形式に符号化される。

【0041】

フォーマットフィールド２４０（ＥＶＥＸバイト０，ビット［７：０］）−第１バイト（ＥＶＥＸバイト０）はフォーマットフィールド２４０であり、それは０×６２を含む（本発明の一実施例ではベクトルフレンドリ命令フォーマットを区別するのに利用される一意的な値）。

【0042】

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

【0043】

ＲＥＸフィールド３０５（ＥＶＥＸバイト１、ビット［７−５］）は、ＥＶＥＸ．Ｒビットフィールド（ＥＶＥＸバイト１、ビット［７］−Ｒ）、ＥＶＥＸ．Ｘビットフィールド（ＥＶＥＸバイト１、ビット［６］−Ｘ）及び２５７ＢＥＸバイト１、ビット［５］―Ｂ）から構成される。ＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ及びＥＶＥＸ．Ｂビットフィールドは、対応するＶＥＸビットと同じ機能を提供し、１の補完形式を利用して符号化され、すなわち、ＺＭＭ０は１１１１Ｂと符号化され、ＺＭＭ１５は００００Ｂと符号化される。命令の他のフィールドは、Ｒｒｒｒ、Ｘｘｘｘ及びＢｂｂｂがＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ及びＥＶＥＸ．Ｂを加えることによって形成されるように、当該分野で知られるようにレジスタインデックスの下位の３ビットを符号化する（ｒｒｒ、ｘｘｘ及びｂｂｂ）。

【0044】

ＲＥＸ’フィールド３１０−これはＲＥＸ’フィールド３１０の最初の部分であり、拡張された３２レジスタセットの上位１６又は下位１６を符号化するのに利用されるＥＶＥＸ．Ｒ’ビットフィールド（ＥＶＥＸバイト１、ビット［４］−Ｒ’）である。本発明の一実施例では、当該ビットは、後述されるような他のビットと共に、ＢＯＵＮＤ命令と区別するためビット反転フォーマットにより格納され（周知のｘ８６の３２ビットモードによる）、そのリアルオペコードバイトは６２であるが、ＭＯＤフィールドの１１の値をＭＯＤ Ｒ／Ｍフィールド（後述される）を受け付けない。本発明の他の実施例は、当該ビット及び他の指摘されたビットを反転形式により格納しない。１の値は下位の１６レジスタを符号化するのに利用される。すなわち、Ｒ’Ｒｒｒｒは、ＥＶＥＸ．Ｒ’、ＥＶＥＸ．Ｒ及び他のＲＲＲと他のフィールドとを合成することによって形成される。

【0045】

オペコードマップフィールド３１５（ＥＶＥＸバイト１、ビット［３：０］−ｍｍｍｍ）−それのコンテンツは、暗示されたリーディングオペコードバイト（０Ｆ、０Ｆ３８又は０Ｆ３Ａ）を符号化する。

【0046】

データ要素幅フィールド２６４（ＥＶＥＸバイト２、ビット［７］−Ｗ）は、ＥＶＥＸ．Ｗという記号により表現される。ＥＶＥＸ．Ｗは、データタイプの粒度（サイズ）を規定するのに利用される（３２ビットデータ要素又は６４ビットデータ要素）。

【0047】

ＥＶＥＸ．ｖｖｖｖ３２０（ＥＶＥＸバイト２、ビット［６：３］−ｖｖｖｖ）−ＥＶＥＸ．ｖｖｖｖの役割は、１）ＥＶＥＸ．ｖｖｖｖは、反転（１の補完）形式により指定された第１ソースレジスタオペランドを符号化し、２以上のソースオペランドを有する命令について有効であり、２）ＥＶＥＸ．ｖｖｖｖは、特定のベクトルシフトについて１の補完形式により指定されたデスティネーションレジスタオペランドを符号化し、又は３）ＥＶＥＸ．ｖｖｖｖは、オペランドを符号化せず、当該フィールドはリザーブされ、１１１１ｂを含むべくであることを含むものであってもよい。従って、ＥＶＥＸ．ｖｖｖｖフィールド３２０は、反転（１の補完）形式により格納されている第１ソースレジスタ指定子の４つの下位ビットを符号化する。命令に依存して、さらなる異なるＥＶＥＸビットフィールドが、指定子のサイズを３２レジスタに拡張するのに利用される。

【0048】

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

【0049】

プリフィックス符号化フィールド３２５（ＥＶＥＸバイト２、ビット［１：０］−ｐｐ）は、ベース処理フィールドについて追加的なビットを提供する。ＥＶＥＸプリフィックスフォーマットによる従来のＳＳＥ命令のサポートを提供するのに加えて、これはまたＳＩＭＤプリフィックスをコンパクト化する効果を有する（ＳＩＭＤプリフィックスを表現するためバイトを要求するのでなく、ＥＶＥＸプリフィックスは２ビットしか要求しない）。一実施例では、従来のフォーマットとＥＶＥＸプリフィックスフォーマットとの双方によるＳＩＭＤプリフィックス（６６Ｈ、Ｆ２Ｈ、Ｆ３Ｈ）を利用する従来のＳＳＥ命令をサポートするため、これらの従来のＳＩＭＤプリフィックスはＳＩＭＤプリフィックス符号化フィールドに符号化され、デコーダのＰＬＡに提供される前にランタイム時に従来のＳＩＭＤプリフィックスに拡張される（従って、ＰＬＡは変更なくこれらの従来の命令の従来のフォーマットとＥＶＥＸフォーマットとの双方を実行可能である）。より新たな命令はオペコードの拡張としてＥＶＥＸプリフィックス符号化フィールドのコンテンツを直接利用可能であるが、特定の実施例は整合性のため同様の方法により拡張するが、これら従来のＳＩＭＤプリフィックスにより異なる意味が指定されることを可能にする。他の実施例は、２ビットのＳＩＭＤプリフィックス符号化をサポートするようＰＬＡを再設計してもよいが、当該拡張を要求しない。

【0050】

アルファフィールド２５２（ＥＶＥＸバイト３、ビット［７］−ＥＨ、ＥＶＥＸ．ＥＨ、ＥＶＥＸ．ｒｓ、ＥＶＥＸ．ＲＬ、ＥＶＥＸライトマスク制御及びＥＶＥＸ．Ｎとしても知られ、αにより示される）−上述されるように、当該フィールドはコンテクストに固有のものである。以降において追加的な説明が与えられる。

【0051】

ベータフィールド２５４（ＥＶＥＸバイト３、ビット［６：４］−ＳＳＳ、ＥＶＥＸ．ｓ_２−０、ＥＶＥＸ．ｒ_２−０、ＥＶＥＸ．ｒｒ１、ＥＶＥＸ．ＬＬ０、ＥＶＥＸ．ＬＬＢとしても知られ、βββにより示される）−上述されるように、当該フィールドはコンテクストに固有のものである。以降において追加的な説明が与えられる。

【0052】

ＲＥＸ’フィールド３１０−これは、ＲＥＸ’フィールドの残りであり、拡張された３２レジスタセットの上位１６又は下位１６を符号化するのに利用可能なＥＶＥＸ．Ｖ’ビットフィールド（ＥＶＥＸバイト３、ビット［３］−Ｖ’）である。当該ビットは、ビット反転形式により格納される。１の値が、下位１６レジスタを符号化するのに利用される。すなわち、Ｖ’ＶＶＶＶが、ＥＶＥＸ．Ｖ’、ＥＶＥＸ．ｖｖｖｖを合成することによって構成される。

【0053】

ライトマスクフィールド２７０（ＥＶＥＸバイト３、ビット［２：０］−ｋｋｋ）−それのコンテンツは、上述されたようなライトマスクレジスタにおいてレジスタのインデックスを指定する。本発明の一実施例では、特定の値ＥＶＥＸ．ｋｋｋ＝０００は、特定の命令に対してライトマスクが利用されないことを意味する特別な動作を有する（これは、マスキングハードウェアをバイパスするハードウェア又はすべて１に配線化されたライトマスクの利用を含む各種方法により実現されてもよい）。
・リアルオペコードフィールド３３０（バイト４）
これはまた、オペコードバイトとして知られる。オペコードの一部は当該フィールドにおいて指定される。
・ＭＯＤ Ｒ／Ｍフィールド３４０（バイト５）
モディファイアフィールド２４６（ＭＯＤＲ／Ｍ．ＭＯＤ、ビット［７−６］−ＭＯＤフィールド３４２）−上述されるように、ＭＯＤフィールド３４２のコンテンツは、メモリアクセス処理と非メモリアクセス処理とを区別する。当該フィールドは、さらに後述される。

【0054】

ＭＯＤＲ／Ｍ．ｒｅｇフィールド３４４、ビット［５−３］−ＭｏｄＲ／Ｍ．ｒｅｇフィールドの役割は、２つの状況に要約できる。ＭｏｄＲ／Ｍ．ｒｅｇは、デスティネーションレジスタオペランド又はソースレジスタオペランドを符号化するか、又はＭｏｄＲ／Ｍ．ｒｅｇは、オペコードの拡張として扱われ、命令オペランドを符号化するのに利用されない。

【0055】

ＭＯＤＲ／Ｍ．ｒ／ｍフィールド３４６，ビット［２−０］−ＭｏｄＲ／Ｍ．ｒ／ｍフィールドの役割は、ＭｏｄＲ／Ｍ．ｒ／ｍがメモリアドレスを参照する命令オペランドを符号化するか、又はＭｏｄＲ／Ｍ．ｒ／ｍは、デスティネーションレジスタオペランド又はソースレジスタオペランドを符号化する。
・スケール、インデックス、ベース（ＳＩＢ）バイト（バイト６）
スケールフィールド２６０（ＳＩＢ．ＳＳ、ｂｉｔ６と［７−６］）−上述されるように、スケールフィールド２６０のコンテンツは、メモリアドレス生成に利用される。当該フィールドは、さらに後述される。

【0056】

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

【0057】

ディスプレースメントバイト（バイト７又はバイト７〜１０）
ディスプレースメントフィールド２６２Ａ（バイト７−１０）−ＭＯＤフィールド３４２が１０を有するとき、バイト７−１０はディスプレースメントフィールド２２Ａであり、それは従来の３２ビットディスプレースメントと同様に機能し（ｄｉｓｐ３２）、バイト粒度により機能する。

【0058】

ディスプレースメントファクタフィールド２６２Ｂ（バイト７）−ＭＯＤフィールド３４２が０１を有するとき、バイト７はディスプレースメントファクタフィールド２６２Ｂである。当該フィールドの位置は、バイト粒度で機能する従来のｘ８６命令セットの８ビットディスプレースメントと同じである。ｄｉｓｐ８は符号拡張されているため、それは−１２８〜１２７バイトオフセットの間のみをアドレス指定でき、６４バイトキャッシュラインに関して、ｄｉｓｐ８は、−１２８、−６４、０及び６４の実際に有用な４つの値のみに設定可能な８ビットを利用する。より大きなレンジがしばしば必要とされるため、ｄｉｓｐ３２が利用されるが、ｄｉｓｐ３２は４バイトしか必要としない。ｄｉｓｐ８及びｄｉｓｐ３２と対照的に、ディスプレースメントファクタフィールド２６２Ｂは、ｄｉｓｐ８の再解釈であり、ディスプレースメントファクタフィールド２６２Ｂを利用するとき、実際のディスプレースメントは、メモリオペランドアクセスのサイズ（Ｎ）と乗算されるディスプレースメントファクタフィールドのコンテンツにより決定される。このタイプのディスプレースメントは、ｄｉｓｐ８＊Ｎとして参照される。これは、平均的な命令長を減少させる（はるかに大きなレンジによりディスプレースメントのため利用される単一のバイト）。このような圧縮されたディスプレースメントは、有効なディスプレースメントがメモリアクセスの粒度の乗数であるという仮定に基づくものであり、アドレスオフセットの冗長な下位ビットは符号化される必要はない。すなわち、ディスプレースメントファクタフィールド２６２Ｂは、従来のｘ８６命令セットの８ビットディスプレースメントを置換する。従って、ディスプレースメントファクタフィールド２６２Ｂは、ｄｉｓｐ８がｄｉｓｐ８＊Ｎにオーバロードされるという例外のみによって、ｘ８６命令セットの８ビットディスプレースメントと同様に符号化される（ＭｏｄＲＭ／ＳＩＢ符号化ルールの変更はない）。すなわち、符号化ルール又は符号化長の変更はないが、ハードウェアによるディスプレースメント値の解釈のみの変更となる（バイト単位のアドレスオフセットを取得するため、メモリオペランドのサイズによりディスプレースメントをスケーリングすることを必要とする）。

【0059】

即値（Ｉｍｍｅｄｉａｔｅ）
即値フィールド２７２は上述されたように機能する。

【0060】

フルオペコードフィールド−図３Ｂ
図３Ｂは、本発明の一実施例によるフルオペコードフィールド２７４を構成する特定のベクトルフレンドリ命令フォーマット３００のフィールドを示すブロック図である。具体的には、フルオペコードフィールド２７４は、フォーマットフィールド２４０、ベース処理フィールド２４２及びデータ要素幅（Ｗ）フィールド２６４を有する。ベース処理フィールド２４２は、プリフィックス符号化フィールド３２５、オペコードマップフィールド３１５及びリアルオペコードフィールド３３０を有する。

【0061】

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

【0062】

拡張処理フィールド−図３Ｄ
図３Ｄは、本発明の一実施例による拡張処理フィールド２５０を構成する特定のベクトルフレンドリ命令フォーマット３００のフィールドを示すブロック図である。クラス（Ｕ）フィールド２６８が０を有するとき、それはＥＶＥＸ．Ｕ０（クラスＡ２６８Ａ）を示し、それは１を有するとき、それはＥＶＥＸ．Ｕ１（クラスＢ２６８Ｂ）を示す。Ｕ＝０及びＭＯＤフィールド３４２が１１を有するとき（非メモリアクセス処理を示す）、アルファフィールド２５２（ＥＶＥＸバイト３、ビット［７］―ＥＨ）はｒｓフィールド２５２Ａとして解釈される。ｒｓフィールド２５２Ａが１を有するとき（ラウンド２５２Ａ．１）、ベータフィールド２５４（ＥＶＥＸバイト３、ビット［６：４］−ＳＳＳ）はラウンド制御フィールド２５４Ａとして解釈される。ラウンド制御フィールド２５４Ａは、１ビットのＳＡＥフィールド２５６と２ビットのラウンド処理フィールド２５８とを有する。ｒｓフィールド２５２Ａが０を有するとき（データ変換２５２Ａ），ベータフィールド２５４（ＥＶＥＸバイト３、ビット［６：４］−ＳＳＳ）は、３ビットデータ変換フィールド２５４Ｂとして解釈される。Ｕ＝０及びＭＯＤフィールド３４２が００、０１又は１０（メモリアクセス処理を示す）を有するとき、アルファフィールド２５２（ＥＶＥＸバイト３、ビット［７］−ＥＨ）はイビクションヒント‘ＥＨ）フィールド２５２Ｂとして解釈され、ベータフィールド２５４（ＥＶＥＸバイト３、ビット［６：４］−ＳＳＳ）は３ビットデータ操作フィールド２５４Ｃとして解釈される。

【0063】

Ｕ＝１であるとき、アルファフィールド２５２（ＥＶＥＸバイト３、ビット［７］−ＥＨ）はライトマスク制御（Ｚ）フィールド２５２Ｃとして解釈される。Ｕ＝１及びＭＯＤフィールド３４２が１１（非メモリアクセス処理を示す）を有するとき、ベータフィールド２５４の一部（ＥＶＥＸバイト３、ビット［４］−Ｓ_０）はＲＬフィールド２５７Ａとして解釈され、それが１を有するとき（ラウンド２５７Ａ．１）、ベータフィールド２５４の残り（ＥＶＥＸバイト３、ビット［６−５］−Ｓ_２−１）はラウンド処理フィールド２５９Ａとして解釈され、ＲＬフィールド２５７Ａが０（ＶＳＩＺＥ２５７．Ａ２）を有するとき、ベータフィールド２５４の残り（ＥＶＥＸバイト３、ビット［６−５］−Ｓ_２−１）はベクトル長フィールド２５９Ｂ（ＥＶＥＸバイト３、ビット［６−５］−Ｌ_１−０）として解釈される。Ｕ＝１及びＭＯＤフィールド３４２が００、０１又は１０（メモリアクセス処理を示す）を有するとき、ベータフィールド２５４（ＥＶＥＸバイト３、ビット［６：４］−ＳＳＳ）は、ベクトル長フィールド２５９Ｂ（ＥＶＥＸバイト３、ビット［６−５］−Ｌ_１−０）及びブロードキャストフィールド２５７Ｂ（ＥＶＥＸバイト３、ビット［４］−Ｂ）として解釈される。

【0064】

いくつかの追加的なポイント
ベクトルフォーマットは、レジスタの個数を３２（ＲＥＸ’）に拡張する。

【0065】

非破壊的ソースレジスタ符号化（３及び４オペランドシンタックスに適用可能）：
これは、命令シンタックスにおける最初のソースオペランドである。それはＥＶＥＸ．ｖｖｖｖの表記によって表現される。当該フィールドは、１の補完形式（反転形式）を用いて符号化され、すなわち、ＺＭＭ０は１１１１Ｂとして符号化され、ＺＭＭ１５は００００Ｂとして符号化される。ＥＶＥＸの追加的なビットフィールドはソースを３２レジスタに拡張するのに必要とされることに留意されたい。

【0066】

ＥＶＥＸ．Ｗは、ある命令についてデータタイプサイズ（３２ビット又は６４ビット）を定義する。

【0067】

３２拡張レジスタセット符号化：ＥＶＥＸプリフィックスは、以下の専用のビットフィールド、すなわち、ＥＶＥＸ．Ｒ’及びＥＶＥＸ．Ｖ’（レジスタ・レジスタフォーマットのＥＶＥＸ．Ｘと共に）によりソース単位で３２レジスタを符号化するための追加的なビットフィールドを提供する。

【0068】

ＳＩＭＤプリフィックスのコンパクト化：従来のＳＳＥ命令は、オペコード拡張ｂフィールドとしてＳＩＭＤプリフィックス（６６Ｈ、Ｆ２Ｈ、Ｆ３Ｈ）を効果的に利用する。ＥＶＥＸプリフィックス符号化は、５１２ビットベクトル長を利用して従来のＳＳＥ命令の機能的能力を可能にする。

【0069】

２バイト及び３バイトオペコードのコンパクト化：最近紹介された従来のＳＳＥ命令は、２バイト及び３バイトオペコードを利用する。１又は２のリーディングバイトは、０ＦＨ及び０ＦＨ ３ＡＨ／０ＦＨ ３８Ｈである。１バイトエスケープ（０ＦＨ）及び２バイトエスケープ（０ＦＨ ３ＡＨ，０ＦＨ ３８Ｈ）がまた、オペコード拡張フィールドとして解釈できる。ＥＶＥＸ．ｍｍｍフィールドは、多数の従来の命令が一定バイトのシーケンス０ＦＨ、０ＦＨ ３ＡＨ、０ＦＨ ３８Ｈなしに符号化されることを可能にするためのコンパクト化を提供する。
［ベクトルフレンドリ命令フォーマットのフィールドの一部の相互関係を示す例示的なフロー図−図４Ａ〜４Ｅ］
図４Ａ〜４Ｄは、本発明の一実施例によるベクトルフレンドリ命令フォーマットのフィールドの一部の相互関係を示すフロー図を示し、図４Ｅは、本発明の一実施例によるブロック４１５Ａ〜Ｈのそれぞれの分解図である。ブロック４００において、初期的なフィールド値がベクトルフレンドリ命令フォーマット（０ｘ６２など）を示しているか判断される。初期的なフィールド値がベクトルフレンドリ命令フォーマットを示していない場合、制御はブロック４０２に移行し、当該命令は命令セットの他のフォーマットの１つに従って処理される。初期的なフィールド値がベクトルフレンドリ命令フォーマットを示している場合、制御はブロック４９２に移行する。

【0070】

ブロック４９２において、クラス（Ｕ）フィールドのコンテンツがクラスＡ又はクラスＢ命令テンプレートを示しているか判断される。クラスＡのケースでは、制御は２つの別々のブロック４０４Ａ及び４９０に移行する。そうでない場合、制御は、サークルＢを介し図４Ｃの２つの別々のブロック４０４Ｂ及び４９３に移行する。

【0071】

ブロック４０４Ａにおいて、モディファイアフィールドのコンテンツが非メモリアクセス処理又はメモリアクセス処理を示しているか判断される。非メモリアクセス処理（ＭＯＤフィールド３４２＝１１など）のケースでは、制御はブロック４０６及び４０８に移行する。メモリアクセス処理（ＭＯＤフィールド３４２＝００、０１又は１０など）のケースでは、制御は（サークルＡを介し図４Ｂ上の）ブロック４２２、４３０及び４４０Ａのそれぞれに移行する。

【0072】

アルファフィールド２５２とラベル付けされたラウンド化されたコーナーボックスは、アルファフィールド２５２の異なる解釈を表現するため、ブロック４０８及び４２２を含む。具体的には、ブロック４０８はアルファフィールド２５２の解釈をｒｓフィールド２５２Ａとして表現する一方、ブロック４２２はアルファ２５２の解釈をイビクションヒントフィールド２５２Ｂとして表現する。

【0073】

ブロック４０６において、レジスタインデックスフィールド２４４のコンテンツは、図６Ａに示されるように利用される。

【0074】

ブロック４０８において、ｒｓフィールド２５２Ａのコンテンツがラウンドタイプ処理（ｒｓフィールド２５２Ａ＝１など）又はデータ変換タイプ処理（ｒｓフィールド２５２Ａ＝０など）を示すか判断される。前者では、制御はブロック４１０、４１２Ａ及び４１４のそれぞれに移行する。後者のケースでは、制御はブロック４１６に移行する。

【0075】

ベータ（ラウンド制御）フィールド２５４Ａとラベル付けされたラウンド化されたコーナーボックスは、ブロック４１０及び４１２Ａを含む。ブロック４１０はＳＡＥフィールド２５６のコンテンツに関する判定を示し（浮動小数点例外を抑制するか否か）、ブロック４１２Ａはラウンド処理フィールド２５８のコンテンツに基づく判定を示す（可能なラウンド化処理のグループの１つを区別）。ブロック４１０及び４１２Ａにおいて行われる判定が、図７Ａに示される。

【0076】

ブロック４１４、４１６、４４２、４４８、４５４、４６０、４６８及び４７４はすべて、データ要素幅（ｗ）フィールド２６４のコンテンツに関する判定を示す。図４に示されるように、データ要素幅フィールド２６４は、図３Ａの特定のベクトルフレンドリ命令フォーマット３００における１ビットフィールドである。また、これらのブロックは、データ要素幅が６４ビット（１など）又は３２ビット（０など）であるか判定する。ブロック４１４に関して、当該判定はフローの当該ブランチのエンドをマーク付けする。他方、制御は６４ビットデータ要素幅と３２ビットデータ要素幅とについてそれぞれブロック４１６からブロック４１８又は４２０に移行する。

【0077】

ベータ（データ変換）フィールド２５４Ｂとラベル付けされたラウンド化されたコーナーボックスは、ブロック４１８と４２０との双方を含み、ベータフィールド２５４がデータ変換フィールド２５４Ｂとして解釈されるケースを表す。ブロック４１８及び４２０において、データ変換フィールド２５４Ｂのコンテンツが、複数のデータ変換処理の何れが実行されるべきか区別するのに利用される。ブロック４１８、４２０の可能なデータ変換処理のグループはそれぞれ、図８Ａ及び８Ｂに示される。

【0078】

ブロック４２２において、イビクションヒントフィールド２５２Ｂのコンテンツは、可能なイビクションヒントオプションのグループの何れが利用されるべきか区別するのに利用される。図４は、特定のベクトルフレンドリ命令フォーマット３００からの１ビットイビクションヒントフィー０ルド２５２Ｂの利用を示す。具体的には、イビクションヒントオプションは、非一時的（１）及び一時的（０）である。これは、フロー図の当該ブランチのエンドをマーク付けする。

【0079】

ブロック４３０において、図６Ｂに示されるように、レジスタインデックスフィールド２４４、スケールフィールド２６０及びディスプレースメントフィールド２６２Ａ又はディスプレースメントファクタフィールド２６２Ｂのコンテンツが利用される。

【0080】

ブロック４４０Ａにおいて、ベース処理フィールド２４２のコンテンツが、異なるメモリアクセス処理のグループの何れが実行されるべきか区別するのに利用される。以下のテーブルは、本発明の一実施例によるサポートされたメモリアクセス処理のグループと共に、それぞれのブロック４４０Ａからの制御フローを示す。本発明の他の実施例は、より多く、より少ない又は異なるメモリアクセス処理をサポートしてもよい。

【0081】

【表2】

上述されるように、ブロック４４２、４４８、４５４、４６０、４６８、４７４は、データ要素幅に基づき制御フローの変更を決定する。制御フローは以下のテーブルに示される。

【0082】

【表3】

同様に、ブロック４８０、４８２及び４８４の判定が、図１５Ａ、１５Ｂ及び１５Ｃにそれぞれ示される。ベータ（データ操作）フィールド２５４Ｃにラベル付けされたラウンド化されたコーナーボックスは、ブロック４４４Ａ、４４６Ａ、４５０Ａ、４５２Ａ、４５６、４５８、４６２、４６４、４７０、４７２、４７６、４７８、４８０、４８２、４８４を含み、これにより、データ操作フィールド２５４Ｃのコンテンツは可能なデータ操作処理のグループの何れが実行されるべきか区別することを示す。

【0083】

ブロック４９０において、ライトマスク（ｋ）フィールド２７０のコンテンツとデータ要素幅（ｗ）フィールド２６４のコンテンツとは、当該処理に使用するライトマスクを決定するのに利用される。図４は、８つのライトマスクレジスタがあって、レジスタ０００はライトマスクが利用されるべきでないことを示す実施例を示す。ライトマスクフィールド２７０のコンテンツが０００以外を示す場合、制御は図１６Ａ〜Ｄに移行する。

【0084】

ブロック４０４Ｂにおいて、モディファイアフィールドのコンテンツが非メモリアクセス処理又はメモリアクセス処理を示すか判断される。非メモリアクセス処理のケースでは（ＭＯＤフィールド３４２＝１１など）、制御はブロック４０６（図４ＡのサークルＥを介し）及び４９５に移行する。メモリアクセス処理のケースでは（ＭＯＤフィールド３４２＝００、０１又は１０など）、制御はブロック４９８、４３０（図４ＡのサークルＤを介し）及び４４０Ｂ（図４ＤのサークルＣ７を介し）。

【0085】

ベータフィールド２５４のラウンド化されたコーナーボックスの一部は、ベータフィールド２５４の一部の異なる解釈を表すため、ブロック４９５、４１２Ｂ及び４９８を含む。具体的には、ブロック４９５は、ＲＬフィールド２５７Ａとしてベータフィールド２５４の解釈の一部を表し、図４Ｄのラウンド化されたコーナーボックスによりラベル付けされたブロードキャストフィールド２５７Ｂは、ブロードキャストフィールド２５７Ｂとしてベータフィールド２５４の当該部分の解釈を表す。

【0086】

ブロック４９５において、ＲＬフィールド２５７Ａのコンテンツはラウンドタイプ処理（例えば、ＲＬフィールド２５７Ａ＝１）又はベクトル長タイプ処理（例えば、ＲＬフィールド２５７＝０）を示す。前者では、制御はブロック４１２Ｂ及び４１５Ａのそれぞれに移行する。後者のケースでは、制御はブロック４９８及び４１５Ｂのそれぞれに移行する。

【0087】

ブロック４１２Ｂは、ラウンド処理フィールド２５９Ｂのコンテンツに基づく判定を示す（可能なラウンド化処理のグループの１つを示す）。ブロック４１２Ｂにおいて行われる判定が、図７Ｂに示される。

【0088】

ブロック４１５Ａ〜Ｈは、処理対象のデータ要素の幅に関する判定を示す。図示されるように、クラスＢのサポートされるデータ要素（Ｕ＝１のとき）は６４ビット、３２ビット、１６ビット及び８ビットである。これらのブロックを実行する例示的な方法が、図４Ｅを参照して後述される。ブロック４１５Ａ〜Ｂはそれぞれフロー図のブランチのエンドをマーク付けする。図の４１５Ａに関して、１６ビット及び８ビットのデータ要素幅へのラインは、本発明の一実施例では、これらがサポートされていないため破線により示される。１６ビット又は８ビットデータ要素に対して実行されるクラスＢの非メモリアクセスタイプ処理がある場合、ＲＬフィールド２５７Ａのコンテンツは０であると予想され、ブロック４９５からブロック４１５Ｂ及び４９８に制御を移行させる（すなわち、パーシャルラウンド化は利用可能でない）。

【0089】

ブロック４９８において、ベクトル長（ＬＬ）フィールド２６８のコンテンツは、処理対象のベクトルのサイズを決定するのに利用される。図４は、１）１２８ビット（００）、２）２５６ビット（０１）、５１２ビット（１０）がサポートされる実施例を示す。ただし、（１１）はリザーブされる。リザーブされた１１は、本発明の異なる実施例について又は異なるタイプの処理について異なる目的のため利用されてもよい。例えば、１１は、１）１０２４ビットのベクトル長を示すか、２）ダイナミックベクトル長レジスタが利用されるべきであることを示すのに利用可能である。異なる実施例は、プログラムにより可読及び書き込み可能なベクトル長を符号化するのに利用される特別なレジスタを含む、ダイナミックベクトル長レジスタを異なって実現してもよい。ダイナミックベクトル長レジスタは、命令のベクトル長に利用される値を格納する。異なる実施例はダイナミックベクトル長レジスタを介し複数の異なるベクトル長をサポートしてもよいが、本発明の一実施例は、１２８ビットの倍数（１２８、２５６、５１２、１０２４、２０４８、．．．など）をサポートする。ダイナミックベクトル長レジスタとして機能する１以上のレジスタのセットがある場合、本発明の異なる実施例は、異なる技術（命令のタイプなどに基づく）を利用してこれらのレジスタから選択してもよい。

【0090】

ブロック４４０Ｂにおいて、ベース処理フィールド２４２のコンテンツは、異なるメモリアクセス処理のグループの何れが実行されるべきか示すのに利用される。以下のテーブルは、本発明の一実施例によるサポートされたメモリアクセス処理グループと共に、それぞれについてブロック４４０Ｂからの制御フローを示す。本発明の他の実施例は、より多く、より少なく又は異なるメモリアクセス処理をサポートしてもよい。

【0091】

【表4】

上述されるように、ブロック４１５Ｃ〜Ｈは、データ要素幅に基づく制御フローの変化を決定し、制御フローが以下のテーブルに示される。

【0092】

【表5】

ラウンド化されたコーナーボックスによりラベル付けされたブロードキャストフィールド２５７Ｂは、ブロック４４４Ｂ、４４６Ｂ、４５０Ｂ及び４５２Ｂを含む。これにより、ブロードキャストフィールド２５７Ｂのコンテンツは、ブロードキャスト処理が実行されるべきか区別することを示す。図示されるように、本発明の一実施例は、ブロードキャスト（ｂ）フィールド２５７Ｂのコンテンツがブロードキャスト処理が６４ビット及び３２ビットのデータ要素幅について実行されるべきか選択することを可能にする。それは、１６ビット及び８ビットデータ要素幅のオプションではない。むしろ、１６ビット又は８ビットデータ要素に対して実行されるクラスＢのメモリアクセスタイプ処理がある場合、ブロードキャスト（Ｂ）フィールド２５７Ｂのコンテンツは０であると予想される。

【0093】

ブロック４９３において、アルファフィールド２５２（ライトマスク制御（Ｚ）フィールド２５２Ｃのコンテンツ）、ライトマスク（ｋ）フィールド２７０のコンテンツ及びデータ要素幅の判定が、実行すべきライトマスク処理（マージング又はゼロ化）と処理に利用されるべきライトマスクとを決定するのに利用される。本発明のいくつかの実施例では、アルファフィールド２５２（ライトマスク制御（Ｚ）フィールド２５２Ｃ）は、ストアを実行するメモリアクセス処理に対してゼロになるよう予想される（ゼロマスキングのため）。データ要素幅の判定は、ブロック４１５と同じように実行される。図４は、８つのライトマスクレジスタがあって、ライトマスクが利用されるべきでないことをレジスタ０００が示す実施例を示す。ライトマスクフィールド２７０のコンテンツが０００以外を示す場合、制御は図１６Ｄ〜Ｅに移行する。

【0094】

図４Ｅは、本発明の一実施例によるブロック４１５Ａ〜Ｈのぞれぞれの分解図である。具体的には、ブロック４１５Ａ〜Ｈのそれぞれのフローを示す１つのフロー４１５が示される。ブロック４１７Ａにおいて、リードオペコードフィールド３３０のコンテンツの一部又はすべてが、第１セット４１７Ａ．１（６４ビットと３２ビットなどを含む）と第２セット４１７Ａ．２（１６ビットと８ビットなど）との２つのデータ要素幅のセットの間で選択するのに利用される。データ要素幅が、ブロック４１７Ｂに示されるようなデータ要素幅（ｗ）フィールド２６４に基づき第１セット４１７Ａ．１について決定される一方、第２セット４７１Ａ．２内には、データ要素幅４１７Ａ．２．１（リアルオペコードフィールド３３０のみに基づく）及び４１７Ａ．２．２（ブロック４１７Ｃに示されるようなデータ要素幅（ｗ）フィールド２６４に基づく）を決定する２つの方法がある。図４に示されるように、データ要素幅フィールド２６４は、図３Ａの特定のベクトルフレンドリ命令フォーマット３００における１ビットフィールドである。また、これらのブロック４１７Ｂは、データ要素幅が６４ビット（１など）又は３２ビット（０など）であるか決定し、ブロック４１７Ｃは、データ要素幅が１６ビット（１など）又は８ビット（０など）であるか決定する。図４Ｅはデータ要素幅を決定する際にリアルオペコードフィールド４１７Ａの関与を示すが、他の実施例は、ｗフィールドのみを利用するため実現されてもよい（１ビットのｗフィールドを有し、２つのみのデータ要素サイズをサポートし、２ビットのｗフィールドを有し、４つのデータ要素サイズをサポートするなど）
本発明の実施例が図４を参照して説明されたが、他の実施例は異なるフローを利用してもよい。例えば、ブロック４８０、４８２及び４８４により示されるように、１つのみのデータ要素幅をサポートする処理はデータ要素幅の判定を有する必要はなく（ブロック４４２Ａなど）、２つのベータフィールド判定を必要としない（ブロック４４４Ａ及び４４６Ａなど）。他の実施例は、これらすべての処理について１つのデータ要素のみをサポートし、すべてのタイプの処理に対して双方のデータ要素幅をサポートしてもよく（ロードグラフィック、ロードＰａｃｋｅｄグラフィック及びストアグラフィック処理に対するデータ要素幅及び追加的なベータフィールド判定を要求する）、又はその他の処理のいくつかに対する異なるデータ要素幅をサポートしない（例えば、ロード／ｏｐ処理について異なるデータ要素幅をサポートしないなど）。同様に、他の実施例は、非メモリアクセスラウンドタイプ処理及び非メモリアクセスデータ変換タイプ処理の１以上に対して異なるデータ要素幅をサポートしなくてもよい。（前者では、ブロック４１４及び４１５Ａは存在せず、後者では、ブロック４１５Ｂは存在しないが、ブロック４１６は存在せず、ブロック４１８及び４２０はマージされる。）他の例として、本発明の異なる実施例は、クラス（Ｕ）フィールド２６８を含まず、クラスＡ又はＢ命令テンプレートの一方しかサポートせず、ＳＡＥフィールド２５６を含むが、ラウンド処理フィールド２５８を含まず、ラウンド処理フィールド２５９Ａを含まず、イビクションヒットフィールド２５２Ｂを含まず、クラスＡ及びＢ命令テンプレートの一方又は双方にラウンドタイプ処理を含まず、データ変換タイプ処理を含まず、非メモリアクセス２０５及びメモリアクセス２２０の一方又は双方にベクトル長フィールド２５９Ｂを含まず、ロード／ｏｐ及びロード処理の一方又は他方のみをサポートし、マスクライトフィールド２７０を含まず、ライトマスク制御（Ｚ）フィールド２５２Ｃを含まず、及び／又はベクトル長フィールド２６８を含まなくてもよい。
[例示的なレジスタアーキテクチャ−図５]
図５は、本発明の一実施例によるレジスタアーキテクチャ５００のブロック図である。レジスタアーキテクチャのレジスタファイルファイル及びレジスタが以下に列記される。

【0095】

ベクトルレジスタファイル５１０−図示された実施例では、５１２ビット幅の３２このベクトルレジスタがあり、これらのレジスタはｚｍｍ０〜ｚｍｍ３１として参照される。下位の１６このｚｍｍレジスタの下位の２５６ビットはレジスタｙｍｍ０〜１６にオーバレイされる。下位の１６個のｚｍｍレジスタの下位の１２８ビット（ｙｍｍレジスタの下位の１２８ビット）は、レジスタｘｍｍ０〜１５にオーバレイされる。特定のベクトルフレンドリ命令フォーマット３００は、以下のテーブルに示されるようなオーバレイされたレジスタに対して実行される。

【0096】

【表6】

すなわち、ベクトル長フィールド２５９Ｂは、最大長と１以上の他のより短い長さとの間で選択する。このようなより短い各長さは先行する長さの１／２であり、ベクトル長フィールド２５９Ｂのない命令テンプレートは最大ベクトル長に対して実行される。さらに、一実施例では、特定のベクトルフレンドリ命令フォーマット３００のクラスＢの命令テンプレートが、Ｐａｃｋｅｄ又はスカラシングル／ダブル精度浮動小数点データ及びＰａｃｋｅｄ又はスカラ整数データに対して実行される。スカラ処理は、ｚｍｍ／ｙｍｍ／ｘｍｍレジスタにおける下位のデータ要素位置に対して実行される処理であり、上位のデータ要素位置は、命令前と同様に左方にあるか、実施例に応じてゼロ化される。

【0097】

ライトマスクレジスタ５１５−図示された実施例では、それぞれが６４ビットのサイズの８つのライトマスクレジスタ（ｋ０〜ｋ７）がある。上述されたように、本発明の一実施例では、ベクトルマスクレジスタｋ０はライトマスクとして利用できず、ｋ０がライトマスクに利用されることを符号化が通常示すとき、それは０ｘＦＦＦＦの配線化されたライトマスクを選択し、当該命令のライトマスキングを有効に不可にする。

【0098】

マルチメディア拡張制御ステータスレジスタ（ＭＸＣSR）５２０−図示された実施例では、当該３２ビットレジスタは、浮動小数点処理において利用される７ステータス及び制御ビットを提供する。

【0099】

汎用レジスタ５２５−図示された実施例では、メモリオペランドをアドレッシングするため既存のｘ８６アドレッシングモードと共に利用される１６個の６４ビットの汎用レジスタがある。これらのレジスタは、ＲＡＸ、ＲＢＸ、ＲＣＸ、ＲＤＸ、ＲＢＰ、ＲＳＩ、ＲＤＩ、ＲＳＰ及びＲ８〜Ｒ１５の名称によって参照される。

【0100】

拡張フラグ（ＥＦＬＡＧＳ）レジスタ５３０−図示された実施例では、当該３２ビットレジスタが、多数の命令の結果を記録するのに利用される。

【0101】

浮動小数点制御ワード（ＦＣＷ）レジスタ５３５及び浮動小数点ステータスワード（ＦＳＷ）レジスタ５４０−図示された実施例では、これらのレジスタは、ＦＣＷのケースではラウンド化モード、例外マスク及びフラグを設定し、ＦＳＷのケースでは例外を追跡するため、ｘ８７命令セット拡張により利用される。

【0102】

ＭＭＸＰａｃｋｅｄ整数フラットレジスタファイル５５０にエイリアシングされるスカラ浮動小数点スタックレジスタファイル（ｘ８７スタック）５４５−図示された実施例では、ｘ８７スタックは、ｘ８７命令セット拡張を利用して３２／６４／８０ビット浮動小数点データに対してスカラ浮動小数点処理を実行するのに利用される８要素スタックであり、ＭＭＸレジスタは、６４ビットＰａｃｋｅｄ整数データに対して処理を実行すると共に、ＭＭＸとＸＭＭレジスタとの間で実行される処理についてオペランドを保持するのに利用される。

【0103】

セグメントレジスタ５５５−図示された実施例では、セグメント化されたアドレス生成について利用されるデータをストアするための６つの１６ビットレジスタがある。

【0104】

ＲＩＰレジスタ５６５−図示された実施例では、当該６４ビットレジスタは命令ポインタを格納する。

【0105】

本発明の他の実施例は、より広い又はより狭いレジスタを利用してもよい。さらに、本発明の他の実施例は、より多く、より少なく又は異なるレジスタファイル及びレジスタを利用してもよい。
［レジスタインデックスフィールド、スケールフィールド、ディスプレースメントフィールド、及びディスプレースメントファクタフィールドフロー−図６Ａ〜６Ｃ］
・モディファイアフィールド＝非メモリアクセス−図６Ａ
図６Ａは、本発明の実施例による非メモリアクセスタイプ処理のためのレジスタインデックスフィールド２４４のフロー図である。図６Ａは、ｍｏｄフィールド３４２（＝１１）に従ってレジスタ間のアドレッシングが実行中であることを示す楕円６００からスタートする。ブロック６００から、制御はブロック６０５に移行する。

【0106】

ブロック６０５において、レジスタをアドレッシングするため、レジスタインデックスフィールド２４４からビットが選択される。特定のベクトルフレンドリ命令フォーマット３００に関して、拡張を有する既存のｘ８６命令セットは、ＲＥＸフィールド３０５、ｒｅｇフィールド３４４、ｒ／ｍフィールド３４６、ＶＶＶVフィールド３２０、ｘｘｘフィールド３５４及びｂｂｂフィールド３５６に基づき広範な異なるレジスタアドレッシングオプションを可能にする。ＲＥＸ’フィールド３１０は、これらのオプションを拡張する。ブロック６０５から、制御はブロック６１０に移行する。

【0107】

ブロック６１０において、レジスタＡが選択され（ｚｍｍ２０など）、制御はブロック６１５に移行する。ブロック６１５において、レジスタＢが選択され（ｚｍｍ５など）、制御は任意的にブロック６２０に移行する。ブロック６２０において、レジスタＣが選択される（ｚｍｍ７など）。レジスタＡはソースオペランドレジスタであってもよく、レジスタＢはソースオペランドレジスタ、デスティネーションオペランドレジスタ又はソース／デスティネーションオペランドレジスタであってもよく、レジスタＣは、ソースオペランドレジスタ、デスティネーションオペランドレジスタ又はソース／デスティネーションオペランドであってもよい。
・モディファイアフィールド＝メモリアクセス−図６Ｂ
図６Ｂは、本発明の実施例によるメモリアクセスタイプ処理のためのレジスタインデックスフィールド２４４、スケールフィールド２６０、ディスプレースメントフィールド２６２Ａ及びディスプレースメントファクタフィールド２６２Ｂの利用を示すフロー図である。図６Ｂは、レジスタ・メモリ間のアドレッシングを示す楕円６３０から始まる（ｍｏｄフィールド３４２＝００、０１又は１０）。６３０から、制御はブロック６３５に移行する。

【0108】

ブロック６３５において、レジスタをアドレッシングするためのビットがレジスタインデックスフィールドから選択され、制御はブロック６４０に移行する。

【0109】

ブロック６４０において、レジスタＡが選択され（ｚｍｍ２０など）、制御は任意的にはブロック６４５に移行する。ブロック６４５において、レジスタＢが選択され（ｚｍｍ３１など）、制御はブロック６５０に移行する。ブロック６４５」が利用されないケースでは、制御はブロック６４０7からブロック６５０に直接移行する。

【0110】

ブロック６５０において、ＲＥＸフィールド３０５、ＲＥＸ’フィールド３１０、ｍｏｄ ｒ／ｍフィールド３４０、ＳＩＢバイト３５０及びディスプレースメントフィールド２６２Ａ又はディスプレースメントファクタフィールド２６２Ｂのコンテンツが、メモリをアドレッシングするのに利用される。具体的には、インデックス及びベースが、ＲＥＸフィールド３０５及びＳＩＢバイト３５０からプルされ、スケールフィールド２６０（ｓｓフィールド３５２）のコンテンツが、ＳＩＢバイト３５０からプルされる。ブロック６５０から、制御はブロック６６０に移行する。

【0111】

ブロック６６０において、メモリアクセスモードが決定される（ｍｏｄフィールド３４２のコンテンツなどに基づき）。メモリアクセスモードが非ディスプレースメントモードである場合（ｍｏｄフィールド３４２＝００）、制御は、アドレスが２^ｓｓ＊インデックス＋ベースとなるように生成されるブロック６６５に移行する。

【0112】

メモリアクセスモードが非スケール化ディスプレースメントモードである場合（ｍｏｄフィールド３４２＝１０）、制御は、アドレスが２^ｓｓ＊インデックス＋ベース＋ｄｉｓｐ３２のように生成されるブロック６７０に移行する。メモリアクセスモードがスケール化ディスプレースメントモードである場合（ｍｏｄフィールド３４２＝０１）、制御は、アドレスが２^ｓｓ＊インデックス＋ベース＋スケール化ディスプレースメントのように生成されるブロック６７５に移行し、スケール化ディスプレースメント（ｄｉｓｐ８＊ｎ）＝ディスプレースメントファクタフィールド２６２Ｂとメモリアクセスサイズ（Ｎ）との乗算のコンテンツであり、Ｎはフルオペコードフィールド２７４（ベース処理フィールド及び／又はデータ要素幅フィールド）及び拡張処理フィールド２５０（クラスフィールド２６８及びデータ操作フィールド２５４Ｃ、ベクトル長フィールド２５９Ｂ及び／又はブロードキャストフィールド２５７Ｂなど）のコンテンツに依存する。
・スケール化ディスプレースメント−図６Ｃ
図６Ｃは、本発明の実施例によるｄｉｓｐ８、ｄｉｓｐ３２及びスケール化ディスプレースメントの変形の間の相違を示すテーブルである。テーブルのカラムは、１）バイトでインクリメントされるアドレスを示す“バイト”、２）−１２８〜１２７をストアするのに利用される１バイトフィールドである“ｄｉｓｐ８フィールド”、３）−２^３１〜２^３１−１をストアするのに利用される４バイトフィールドである“ｄｉｓｐ３２フィールド”、４）−１２８〜１２７をストアするのに利用される１バイトフィールドである“ｄｉｓｐ３２＊Ｎフィールド”であり、当該カラムは“Ｎ＝１”、“Ｎ＝２”及び“Ｎ＝６４”のサブカラムを有する。

【0113】

“バイト”カラムのローの値はカラムの下方に増加する。第２カラム、第３カラム及び各サブカラムは、当該フィールドにより生成可能なアドレスのローにおける黒色のサークルを含む。ｄｉｓｐ８フィールド及びｄｉｓｐ３２フィールドが、Ｎ＝１である場合、当該フィールドがバイトの粒度によりインクリメントすることを示すそれらのレンジによって、すべてのバイトについて黒色のドットを有することは注目すべきである。他方、Ｎ＝２のカラムは、２バイトだけインクリメントし、従ってそれのレンジ内の１つおきのバイトについて黒色のドットしか有さず、また、それはｄｉｓｐ８フィールドと比較してより広いレンジとより粗い粒度とを有する一方、同時にそれはｄｉｓｐ３２フィールドのバイトの１／４しか必要としない。Ｎ＝６４のカラムは、６４バイトだけインクリメントし、従ってそれのレンジ内で６４バイト毎に黒色のドットしか有さず、また、それはｄｉｓｐ８フィールドと比較してより広いレンジとより粗い粒度とを有する一方、同時にそれは再びｄｉｓｐ３２フィールドの１／４バイトしか必要としない。
・ラウンド化フィールドテーブル−図７Ａ〜Ｂ
図７Ａは、本発明の実施例によるラウンド制御フィールド２５４Ａにより指定されうる可能な処理のグループを示すテーブルである。図７Ａは、第１カラムがベータフィールド２５４の可能なコンテンツを有することを示す（ラウンド制御フィールド２５４Ａとして機能し、ＳＡＥフィールド２５６及びラウンド処理フィールド２５８に分割される）。

【0114】

同様に、図７Ｂは、本発明の実施例によるラウンド制御フィールド２５９Ａにより指定されうる可能な処理のグループを示すテーブルである。クラスＢ命令テンプレートのケースでは、ＳＡＥフィールド３５６はなく、浮動小数点例外抑制が常にアクティブである。

【0115】

いくつかの命令がすでに中間ビットを介しラウンド化モードの指定を静的に可能にする一実施例では、中間ビットはラウンド化モード処理フィールド２５８及び２５９Ａに対して優先する。
・データタイプ
以下のテーブルは、ここで用いられる例示的なデータタイプをリストする（その一部は、Ｍｉｓｃｒｏｓｏｆｔ（登録商標）のＤｉｒｅｃｔＸ（登録商標）１０に説明されている（Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＤｉｒｅｃｔＸ（登録商標）、データ変換ルール（２０１０年８月１７日）を参照）。

【0116】

【表7】

ＵＮＯＲＭは、ｎビット数について、すべて０が０．０ｆを意味し、すべて１が１．０ｆを意味することを示す符号なしの正規化された整数を示す。０．０ｆから１．０ｆまでの均等に離間した浮動小数値のシーケンスが表され、例えば、２ビットＵＮＯＲＭは０．０ｆ、１／３、２／３及び１．０ｆを表す。

【0117】

ＳＮＯＲＭは、ｎビット２の補数について、最大値が１．０ｆを意味し（例えば、５ビット値０１１１１は１．０ｆにマップする）、最小値は−１．０ｆを意味する（例えば、５ビット値１００００は−１．０ｆにマップする）ことを示す符号付き正規化された整数を示す。さらに、第２最小数は−１．０ｆにマップする（例えば、５ビット値１０００１は−１．０ｆにマップする）。従って、−１．０ｆについて２つの整数表現がある。０．０ｆについて１つの表現があり、１．０ｆについて１つの表現がある。これは、レンジ（−１．０ｆ．．．０．０ｆ）において均等に離間した浮動小数値の整数表現のセットをもたらし、また、レンジ（０．０ｆ．．．１．０ｆ）における数の補完的な表現セットをもたらす。

【0118】

上述されるように、ＳＩＭＤ技術は、レジスタのビットを各データ要素が別個の値を表す複数の固定的／サイズ化されたデータ要素に論理的に分割可能なプロセッサに特に適している。このタイプのデータは、Ｐａｃｋｅｄデータタイプ又はベクトルデータタイプと呼ばれ、当該データタイプのオペランドはＰａｃｋｅｄデータオペランド又はベクトルオペランドと呼ばれる。典型的には、ベクトルオペランドのデータ要素は、同じデータタイプを有し、所与のデータ要素のデータタイプは、データ要素データタイプと呼ばれる。データ要素のすべてのデータ要素データタイプが同じである場合、ベクトルオペランドは当該データタイプを有するとして参照されてもよい。（例えば、ベクトルオペランドのデータ要素のすべてが３２ビット浮動小数データ要素データタイプを有する場合、ベクトルオペランドは、３２ビット浮動小数点ベクトルオペランドと呼ばれる。）
シングル値データ要素データタイプとマルチ値データ要素データタイプとをサポートする本発明の実施例が説明される。シングル値データ要素データタイプは、各データ要素にシングル値を格納し、本発明のいくつかの実施例において用いられるシングル値データ要素データタイプの具体例は、３２ビット浮動小数点、６４ビット浮動小数点、３２ビット符号なし整数、６４ビット符号なし整数、３２ビット符号付き整数、及び６４ビット符号付き整数である。マルチ値データ要素データタイプは、各データ要素位置に複数の値を有するパケットを格納し、本発明のいくつかの実施例において使用される複数値データ要素データタイプの具体例は、後述されるＰａｃｋｅｄグラフィックデータ要素データタイプである。

【0119】

ＵＮＯＲＭ１０Ａ１０Ｂ１０Ｃ２Ｄ：３つのＵＮＯＲＭ１０値と１つのＵＮＯＲＭ２値の３２ビットパケットは、３２ｂフィールドの最上位ビットにある最後の２ｂ（１０ｂ）フィールドから始まる（例えば、ＵＮＯＲＭ２Ｄ［３１−３０］フロート１０Ｃ［２９−２０］フロート１０Ｂ［２０−１０］フロート１０Ａ［９−０］、ただし、Ｄ〜Ａはスロット位置を示し、先行する名称／数字はフォーマットを示す。）
ＦＬＯＡＴ１１Ａ１１Ｂ１０Ｃ：２つのＦＬＯＡＴ１１値と１つのＦＬＯＡＴ１０値との３２ビットパケットは、より上位のビットにある最後を開始する（例えば、フロート１０Ｃ［３１−２２］フロート１１Ｂ［２１−１１］フロート１１Ａ［１０−０］など）。

【0120】

上記のマルチ値データ要素データタイプのパケットの異なる値は異なる個数のビットにより表現され、他の実施例は異なるコンフィギュレーションを有してもよいことに留意すべきである。（例えば、異なる個数のビットにより表現される値のより多く、同数のビットにより表される値のすべてなど）。

【0121】

シングル値データ要素データタイプとマルチ値データ要素データタイプとの双方をサポートする実施例が説明されたが、他の実施例は一方又は他方をサポートしてもよい。さらに、特定のデータタイプを利用する本発明の実施例が説明されるが、本発明の他の実施例はより多く、より少なく又は異なるデータタイプを利用してもよい。
・データ変換フィールドテーブル−図８Ａ及び８Ｂ
図８Ａ〜８Ｂは、本発明の実施例によるデータ変換フィールドにより指定されうる可能なデータ変換処理のグループを示すテーブルである。双方のテーブルの第１カラムは、データ変換フィールド２５４Ｂのコンテンツの可能な値を示し、第２カラムはファンクションを示し、第３カラムは利用を示す。
・データ要素サイズフィールド＝６４ビット−図８Ａ
図８Ａは、本発明の実施例によるデータ要素幅が６４ビットであるとき、データ変換フィールドにより指定されうる可能なデータ変換処理のグループを示すテーブルである。当該テーブルは、６４ビットレジスタスウィズルアップ変換スウィズルプリミティブと呼ばれ、ブロック４１８の表現である。記号：ｄｃｂａはソースにおいて１つの２５６ビットブロックを形成する６４ビット要素を示し（“ａ”は最下位及び“ｄ”は最上位）、ａａａａは、ソースの２５６ビットブロックの最下位要素がデスティネーションにおける同じ２５６ビットブロックの４つすべての要素に複製され、図示されたパターンは、そのときソース及びデスティネーションにおいて２つの２５６ビットブロックについて繰り返されることを意味する。ただし、“ａ”は最下位要素であり、“ｈ”は最上位要素である。しかしながら、各２５６ビットブロックはレジスタスウィズルについて同じ順列を実行するため、最下位ブロックのみが示される。
・データ要素サイズフィールド＝３２ビット−図８Ｂ
図８Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるときデータ変換フィールドにより指定されうる可能なデータ変換処理のグループを示すテーブルである。当該テーブルは、３２ビットレジスタスウィズルアップ変換スウィズルプリミティブと呼ばれ、ブロック４２０の表現である。記号：ｄｃｂａはソースにおいて１つの１２８ビットブロックを形成する３２ビット要素を示し（“ａ”は最下位及び“ｄ”は最上位）、ａａａａは、ソースにおける１２８ビットブロックの最下位要素がデスティネーションにおける同じ１２８ビットブロックの４つすべての要素に複製され、図示されたパターンは、このときソース及びデスティネーションにおける４つすべての１２８ビットブロックについて繰り返される。“ｐｏｎｍ ｌｋｊｉ ｈｇｆｅ ｄｃｂａ”はソースレジスタを示すのに利用され、“ａ”は最下位要素であり、“ｐ”は最上位要素である。しかしながら、各１２８ビットブロックはレジスタスウィズルについて同じ順列を実行するため、最下位ブロックのみが示される。

【0122】

図８Ｂは、図８Ａ〜８Ｂに示される処理のすべての意味をさらに説明するため２つの例示的な処理を呼び出す。図９において、クロスプロダクトスウィズル８１５が示され、図１０Ａにおいて、４要素パケット８２０におけるブロードキャスト要素が示される。
・例示的なスウィズル処理−図９
図９は、本発明の実施例によるクロスプロダクトスウィズル８１５を示すブロック図である。図９は、双方が５１２ビット幅であり、連続する１２８個のブロックに分割される（パケット位置３−０と呼ばれる）ソースオペランド９００及びデスティネーションオペランド９１０を示し、各ブロックは４つの３２ビットデータ要素に分割される。（例えば、ソースオペランド９００のパケット位置０のコンテンツはＤ０Ｃ０Ｂ０Ａ０であり、デスティネーションオペランド９１０のパケット位置０のコンテンツはＤ０Ａ０Ｃ０Ｂ０である。
・例示的なブロードキャスト処理−図１０Ａ〜１０Ｃ
図１０Ａは、本発明の実施例による４要素パケット８２０にわたる要素のブロードキャストを示すブロック図である。図１０Ａは、双方が５１２ビット幅であり、連続する１２８個のブロック（パケット位置３〜０として参照される）に分割されるソースオペランド１０００及びデスティネーションオペランド１０１０を示し、各ブロックは４つの３２ビットデータ要素に分割される。（例えば、ソースオペランド１０００のパケット位置０のコンテンツはＤ０Ｃ０Ｂ０Ａ０である一方、デスティネーションオペランド９１０のパケット位置０のコンテンツはＡ０Ａ０Ａ０Ａ０であり、ソースオペランド１０００のパケット位置１のコンテンツはＤ１Ｃ１Ｂ１Ａ１であり、デスティネーションオペランド１０１０のパケット位置１のコンテンツはＡ１Ａ１Ａ１Ａ１である。）
図１０Ａは非メモリアクセス処理の一例となるブロードキャストであるが、図１０Ｂ〜１０Ｃはメモリアクセス処理のための一例となるブロードキャストである。ソースメモリオペランドは要素の合計数より少なく含むとき、それは有効なソースオペランドの完全数の要素を形成するためブロードキャスト（繰り返し）可能である（３２ビット命令について１６、６４ビット命令について８）。これらのタイプのブロードキャスト処理は図１２Ａ〜１２Ｄにおいて参照される。２つのブロードキャスト粒度がある。

【0123】

ソースメモリオペランドの１要素が、フル１６要素有効ソースオペランド（３２ビット命令について）を形成するため１６回ブロードキャストされ、又はフル８要素有効ソースオペランド（６４ビット命令について）を形成するため８回ブロードキャストされる。図１０Ｂは、本発明の実施例による３２ビットデータ要素幅の１の要素粒度のブロードキャストを示すブロック図である。当該処理の具体例は、図１２Ｂにおいて１２１０によりラベル付けされる。図１０Ｂは、１つの３２ビットデータ要素（Ａ０）を有するメモリをソースとするソースオペランド１０２０と、５１２ビット幅であり、１６個の３２ビットデータ要素を含むデスティネーションオペランド１０３０とを示す。（データ要素のすべてがデスティネーションオペランド１０３０においてＡ０である。）１の要素のブロードキャストは、ソースの１つが異なる処理に対して共通している場合、ベクトルソースとスカラソースとを混合した命令について有用である。

【0124】

ソースメモリオペランドの４要素が、フル１６要素有効ソースオペランド（３２ビット命令について）を形成するため４回ブロードキャストされるか、又はフル８要素有効ソースオペランド（６４ビット命令について）を形成するため２回ブロードキャストされる４要素粒度である。図１０Ｃは、本発明の実施例による３２ビットデータ要素のブロードキャスト４要素粒度を示すブロック図である。図１２Ｂにおいて、当該処理の具体例が１２２０によりラベル付けされる。図１０Ｃは、４つの３２ビットデータ要素（Ｄ０Ｃ０Ｂ０Ａ０）を有するメモリをソースとするソースオペランド１０４０と、５１２ビット幅であり、連続する１２８個のブロックに分割される（パケット位置３〜０として参照される）デスティネーションオペランド１０５０とを示し、各ブロックは４つの３２ビットデータ要素に分割される。（例えば、デスティネーションオペランド１０５０のパケット位置３〜０のそれぞれにおけるコンテンツはＤ０Ｃ０Ｂ０Ａ０などである。）４〜１６回のブロードキャストは、計算が（カラーコンポーネントＲＧＢＡと同様に）Ｐａｃｋｅｄ値のアレイに対して実行されるＡＯＳ（Ａｒｒａｙ Ｏｆ Ｓｔｒｕｃｔｕｒｅ）にとって大変有用であり、この場合、ベクトル命令の異なる処理に対して共通のパケットが利用されるとき（１６要素ベクトルは４つの要素の４つのパケットのアレイとみなされる）、４〜１６が効果的である。
・ベース処理フィールドテーブル−図１１Ａ及び１１Ｂ
・オペコードマップフィールド−図１１Ａ
図１１Ａは、本発明の実施例によるオペコードマップフィールドにより指定されうる可能なオペコードマップのグループを示すテーブルである。第１カラムは、オペコードマップフィールド３１５のコンテンツの可能な値を示し、第２カラムは、インプライされるリーディングオペコードバイトを示し、第３カラムは、即値があるか示す。
・プリフィックス符号化フィールド−図１１Ｂ
図１１Ｂは、本発明の実施例によるオペコードマップフィールドにより指定されうる可能なプリフィックス符号化のグループを示すテーブルである。第１カラムは、プリフィックス符号化フィールド３２５のコンテンツの可能な値を示し、第２カラムは、当該プリフィックスの意味を示す。
・データ操作フィールドテーブル−図１２〜１５
図１２〜１５は、本発明の実施例によるデータ操作フィールド２５４Ｃと、図１２Ａ〜Ｄについてブロードキャストフィールド２５７Ｂとによりそれぞれ指定されうる可能なデータ操作処理とブロードキャスト処理とのグループを示すテーブルである。テーブルの第１カラムは、データ操作フィールド２５４Ｃのコンテンツの可能な値を示し、第２カラムはファンクションを示し、第３カラムは利用を示す。
・ロード／ＯＰのためのデータ操作フィールドテーブル−図１２Ａ〜１２Ｄ
図１２Ａ〜１２Ｄは、本発明の実施例によるロード／ｏｐ命令のためのデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂによりそれぞれ指定されうる可能なデータ操作処理及びブロードキャスト処理のグループを示すテーブルである。図３Ａ〜Ｄにおける例示的な特定のベクトルフレンドリ命令フォーマットのケースでは、データ操作フィールド２５４Ｃは３ビットフィールドであり、ブロードキャストフィールド２５７Ｂは１ビットフィールドである。図示された実施例では、ブロードキャストフィールド２５７Ｂのコンテンツは、図１２Ａ〜Ｄに示されるテーブルの最初の２つのローの間で選択し、すなわち、それのコンテンツは、データ操作フィールド２５４Ｃにおける０００及び００１の等価なものの間で選択する。これは、テーブルの最初の２つのローしか含まないブラケットを利用して図１２Ａ〜Ｄに示される。
・ロード／ＯＰ整数及びデータ要素サイズフィールド＝６４ビット−図１２Ａ
図１２Ａは、本発明の実施例によるデータ要素幅が６４ビットであるロード／ｏｐ整数についてデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、６４ビットＩｎｔｅｇｅｒＬｏａｄ−ｏｐＳｗｉｚｚＵｐＣｏｎｖ_ｉ６４（クワドワード）スウィズル／変換プリミティブと呼ばれ、ブロック４４４Ａ及び４４４Ｂの表現である。
・ロード／ＯＰ整数及びデータ要素サイズフィールド＝３２ビット−図１２Ｂ
図１２Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるロード／ｏｐ整数のデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、３２ビットＩｎｔｅｇｅｒＬｏａｄ−ｏｐＳｗｉｚｚＵｐＣｏｎｖ_ｉ３２スウィズル／変換プリミティブとして参照され、ブロック４４６Ａ及び４４６Ｂの表現である。
・ロード／ＯＰ浮動小数点及びデータ要素サイズフィールド＝６４ビット−図１２Ｃ
図１２Ｃは、本発明の実施例によるデータ要素幅が６４ビットであるロード／ｏｐ浮動小数点のデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、６４ビットＦｌｏａｔｉｎｇ−ｐｏｉｎｔＬｏａｄ−ｏｐＳｗｉｚｚＵｐＣｏｎｖ_ｆ６４スウィズル／変換プリミティブとして参照され、ブロック４５０Ａ及び４５０Ｂの表現である。
・ロード／ＯＰ浮動小数点及びデータ要素サイズフィールド＝３２ビット−図１２Ｄ
図１２Ｄは、本発明の実施例によるデータ要素幅が３２ビットであるロード／ｏｐ浮動小数点のデータ操作フィールド２５４Ｃ及びブロードキャストフィールド２５７Ｂにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、３２ビットＦｌｏａｔｉｎｇ−ｐｏｉｎｔＬｏａｄ−ｏｐＳｗｉｚｚＵｐＣｏｎｖ_ｆ３２スウィズル／変換プリミティブとして参照され、ブロック４５２Ａ及び４５２Ｂの表現である。
・ロードのためのデータ操作フィールドテーブル−図１３Ａ〜１３Ｄ
図１３Ａ〜１３Ｄは、本発明の実施例によるロード命令のためのデータ操作フィールドにより指定されうる可能なデータ操作処理のグループを示すテーブルである。
・ロード整数及びデータ要素サイズフィールド＝６４ビット−図１３Ａ
図１３Ａは、本発明の実施例によるデータ要素幅が６４ビットであるロード整数のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｉ６４として参照され、ブロック４５６の表現である。
・ロード整数及びデータ要素サイズフィールド＝３２ビット−図１３Ｂ
図１３Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるロード整数のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｉ３２として参照され、ブロック４５８の表現である。
・ロード浮動小数点及びデータ要素サイズフィールド＝６４ビット−図１３Ｃ
図１３Ｃは、本発明の実施例によるデータ要素幅が６４ビットであるロード浮動小数点のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｆ６４として参照され、ブロック４６２の表現である。
・ロード浮動小数点及びデータ要素サイズフィールド＝３２ビット−図１３Ｄ
図１３Ｄは、本発明の実施例によるデータ要素幅が３２ビットであるロード浮動小数点のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｆ３２として参照され、ブロック４６４の表現である。
・追加的ポイント
図１３Ａ〜１３Ｄ（ロード／ｏｐテーブル）のそれぞれにおいて指定される可能なデータ操作処理のグループは、対応する図１２Ａ〜１２Ｄ（ロードテーブル）のもののサブセットである。具体的には、当該サブセットはブロードキャスト処理を含まない。これは、フルオペコードフィールド２７４の特定の値（ギャザー又はブロードキャスト処理を指定するものなど）が、データ操作フィールド２５４Ｃにおおいて指定されたブロードキャストと共に利用できず、フルオペコードフィールド２７４の当該値は、図１２Ａ〜１２Ｄ（ロードテーブル）のロードによってのみ利用可能である。より具体的な例として、ブロードキャスト処理を指定するフルオペコードフィールド２７４に値がある場合、データ操作フィールド２５４Ｃはまたブロードキャスト処理を示すことができない。本発明の特定の実施例は別々のロード／ｏｐテーブルとロードテーブルとを有する別々のロード／ｏｐ及びロード処理を含むが、他の実施例は、当該実施機構を有する必要はない（例えば、それらは、ロード／ｏｐのみをサポートし、ロードのみをサポートし、フルオペコードフィールド２７４のブロードキャストはデータ操作フィールド２５４Ｃのブロードキャストを無視させることを判断してもよい）。
・ストアのためのデータ操作フィールドテーブル−図１４Ａ〜１４Ｄ
図１４Ａ〜１４Ｄは、本発明の実施例によるストア命令のためのデータ操作フィールドにより指定されうる可能なデータ操作処理のグループを示すテーブルである。
・ストア整数及びデータ要素サイズフィールド＝６４ビット−図１４Ａ
図１４Ａは、本発明の実施例によるデータ要素幅が６４ビットであるストア整数のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＤｏｗｎＣｏｎｖ_ｉ６４として参照され、ブロック４７０の表現である。
・ストア整数及びデータ要素サイズフィールド＝３２ビット−図１４Ｂ
図１４Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるストア整数のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＤｏｗｎＣｏｎｖ_ｉ３２として参照され、ブロック４７２の表現である。
・ストア浮動小数点及びデータ要素サイズフィールド＝６４ビット−図１４Ｃ
図１４Ｃは、本発明の実施例によるデータ要素幅が６４ビットであるストア浮動小数点のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＤｏｗｎＣｏｎｖ_ｆ６４として参照され、ブロック４７６の表現である。
・ストア浮動小数点及びデータ要素サイズフィールド＝３２ビット−図１４Ｄ
図１４Ｄは、本発明の実施例によるデータ要素幅が３２ビットであるストア浮動小数点のためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＤｏｗｎＣｏｎｖ_ｆ３２として参照され、ブロック４７８の表現である。
・グラフィックデータタイプのためのデータ操作フィールドテーブル−図１５Ａ〜１５Ｃ
図１５Ａ〜１５Ｃは、本発明の実施例によるグラフィックスデータタイプに対して実行される命令のためのデータ操作フィールドにより指定されうる可能なデータ操作処理のグループを示すテーブルである。
・ロードグラフィック−図１５Ａ
図１５Ａは、本発明の実施例によるデータ要素幅が３２ビットであるロードグラフィックのためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｇ３２として参照され、ブロック４８０の表現である。
・ロードＰａｃｋｅｄグラフィック−図１５Ｂ
図１５Ｂは、本発明の実施例によるデータ要素幅が３２ビットであるロードＰａｃｋｅｄグラフィックのためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｐｇ３２として参照され、ブロック４８２の表現である。
・ストアグラフィック−図１５Ｃ
図１５Ｃは、本発明の実施例によるデータ要素幅が３２ビットであるストアグラフィックのためのデータ操作フィールド２５４Ｃにより指定されうる可能なデータ操作処理のグループを示すテーブルである。当該テーブルは、ＵｐＣｏｎｖ_ｇ３２として参照され、ブロック４８４の表現である。
・ライトマスクフィールド−図１６Ａ〜Ｄ
図１６Ａ〜１６Ｂは、本発明の実施例による異なるライトマスクと、同一の第２ソース及びデスティネーションとにより実行される２つのマージング処理を示す。図１６Ａは、本発明の実施例によるライトマスクレジスタＫ１においてライトマスクを利用してマージする一例となる処理１６００を示すブロック図であり、データ要素幅は３２ビットであり、第２ソース及びデスティネーションが同一である。図１６Ａは、ソースオペランド１６０５、ソース／デスティネーションオペランド１６１０、マスクレジスタＫ１ １６１５のコンテンツ（下位１６ビットは１と０との混合を含む）、及びデスティネーションオペランド１６２０を示す。マスクレジスタＫ１の下位１６ビット位置のそれぞれは、データ要素位置の１つに対応する（Ｋ１［０］はデータ要素位置０に、Ｋ１［１］はデータ要素位置１などに対応する）。デスティネーションオペランド１６２０の各データ要素位置について、それは、マスクレジスタＫ１の対応するビット位置がそれぞれ０又は１であるか否かに依存して、ソース／デスティネーション１６１０のデータ要素位置のコンテンツ又は処理結果（加算として示される）を含む。他の実施例では、ソース／デスティネーションオペランド１６１０は、第２ソースオペランドに置換される。これらの実施例では、デスティネーションオペランド１６２０は、マスクレジスタＫ１の対応するビット位置が０である（存在する場合）データ要素位置に処理前からのデスティネーションオペランド１６２０のコンテンツを含み、マスクレジスタＫ１の対応するビット位置が１である（存在する場合）データ要素位置に処理結果を含む。

【0125】

上述されるように、本発明の一実施例はＫ０を用いて、マスキングが実行されるべきでないことを示す。図１６Ｂは、本発明の実施例によるすべて１の配線化されたマスクを用いてマージする一例となる処理１６２５を示すブロック図であり（配線化されたライトマスクは、ライトマスクレジスタｋ０を指定する命令により利用される）、データ要素幅は３２ビットであり、第２ソース及びデスティネーションは同じである。図１６Ｂは、Ｋ１ １６１５が配線化されたマスク１６３０と置換され、デスティネーションオペランド１６２０がデスティネーションオペランド１６３５と置換されることを除き、図１６Ａと同じである。配線化されたマスク１６３０はすべて１であり、デスティネーションオペランド１６３５は、処理結果を表すデータ要素を含む。

【0126】

図１６Ｃは、本発明の実施例による８、１６、３２及び６４ビットデータ要素幅の５１２ビットベクトルのデータ要素位置とライトマスクレジスタのビットとの対応関係を示すブロック図である。具体的には、６４ビットレジスタＫ_Ｎ１６４０が示され、データ要素幅が８ビットであるとき、６４ビットすべてが利用され、データ要素幅が１６ビットであるとき、最下位の３２ビットのみが利用され、データ要素幅が３２ビットであるとき、最下位１６ビットのみが利用され、データ要素幅が６４ビットであるとき、最下位８ビットのみが利用される。２５６ビットベクトルについて、データ要素幅が８ビットであるとき、最下位３２ビットのみが利用され、データ要素幅が１６ビットであるとき、最下位１６ビットが利用され、データ要素幅が３２ビットであるとき、最下位８ビットのみが利用され、データ要素幅が６４ビットであるとき、最下位４ビットのみが利用される。１２８ビットベクトルについて、データ要素幅が８ビットであるとき、最下位１６びっとのみが利用され、データ要素幅が１６ビットであるとき、最下位８ビットのみが利用され、データ要素幅が３２ビットであるとき、最下位２ビットのみが利用され、データ要素幅が６４ビットであるとき、最下位２ビットのみが利用される。

【0127】

所与のマスクレジスタの値は、ＧＰレジスタから転送されるか、又は２つのマスクの間の論理処理の直接的な結果として計算されるベクトル比較命令の直接的な結果として設定可能である。

【0128】

図１６Ｄは、本発明の実施例によるライトマスクレジスタＫ１におけるライトマスクを利用してマージする一例となる処理１６６０を示すブロック図であり、データ要素幅は３２ビットであり、第２ソース及びデスティネーションは異なる。

【0129】

図１６Ｅは、本発明の実施例によるライトマスクレジスタＫ１におけるライトマスクを利用してゼロ化する一例となる処理１６６６を示すブロック図であり、データ要素幅は３２ビットであり、第２ソース及びデスティネーションは異なる。ゼロ化処理はデスティネーションがソースと異なる処理に対してのみ示されるが、ゼロ化はまた、第２ソース及びデスティネーションが同一である場合に機能する。
・例示的なテンプレート及び命令−図１７〜１８
以下の記号は、図１７〜１８への導入により提供される。

【0130】

【表8】

【0131】

【表9】

【0132】

【表10】

・ＥＶＥＸ．Ｕ０のための例示的な命令符号化−図１７Ａ〜Ｄ
図１７Ａは、本発明の実施例による一例となる特定のベクトルフレンドリ命令フォーマットからのフィールドのサブセットを示す。具体的には、図１７Ａは、ＥＶＥＸプリフィックス３０２、リアルオペコードフィールド３３０及びＭＯＤ Ｒ／Ｍフィールド３４０を示す。本実施例では、フォーマットフィールド２４０は、命令フォーマットがベクトルフレンドリ命令フォーマットであることを示すための０×６２を含む。

【0133】

図１７Ｂ〜１７Ｄはそれぞれ、本発明の実施例による図１７Ａの特定のベクトルフレンドリ命令フォーマットに符号化される一例となる特定のベクトルフレンドリ命令からのフィールドのサブセットを示す。図１７Ｂ〜１７Ｄの説明では、ＶＡＤＤＰＳ命令の各種の例示的なコンフィギュレーションのための一部のフィールドの可能な符号化を示すため、一部のフィールドの具体的な利用が説明される。図１７Ｂ〜１７Ｄのそれぞれにおいて、フォーマットフィールド２４０は、命令がベクトルフレンドリ命令フォーマットにより符号化されていることを示すための０×６２を含み、リアルオペコードフィールド３３０はＶＡＤＤＰＳオペコードを含む。図１７Ｂ〜１７Ｄはそれぞれ、本発明の実施例によるＥＶＥＸ．Ｕ０クラスへのＶＡＤＤＰＳ命令の符号化を示し、図１７Ｂ及び１７Ｃはそれぞれ、非メモリアクセス２０５命令テンプレートへのＶＡＤＤＰＳのＥＸＥＶ．Ｕ０符号化を示し、図１７Ｄは、メモリアクセス２２０命令テンプレートへのＶＡＤＤＰＳのＥＶＥＸ．Ｕ０符号化を示す。ＶＡＤＤＰＳ命令は、第１レジスタ又はメモリオペランド（ｚｍｍ３など）から第２レジスタ（ｚｍｍ２など）へのＰａｃｋｅｄシングル精度浮動小数点値を加算し、結果をライトマスク（ｋ１など）に従って第３レジスタ（ｚｍｍ１など）に格納する。当該命令は、命令の符号化に応じて各種のラウンド処理、データ変換処理又はデータ操作処理を可能にする。当該命令は、以下の命令ニーモニック、ＥＶＥＸ．Ｕ０．ＮＤＳ．５１２．０Ｆ ５８／ｒ ＶＡＤＤＰＳ ｚｍｍ１｛ｋ１｝，ｚｍｍ２，Ｓ_ｆ３２（ｚｍｍ／ｍＶ）｛ｅｈ｝により記述されてもよい。

【0134】

図１７Ｂは、非メモリアクセスフルラウンド制御タイプ処理２１０命令テンプレートにおけるＶＡＤＤＰＳ命令の符号化を示す。データ要素幅フィールド２６４は、３２ビットデータ要素幅を示すため０となる。クラスフィールド２６８（すなわち、ＥＶＥＸ．Ｕ）は、ＥＶＥＸ．Ｕ０クラスを示すため０に設定される。アルファフィールド２５２は、ＲＳフィールド２５２Ａ（すなわち、ＥＶＥＸ．ｒｓ）として解釈され、ラウンド制御タイプ処理を選択するため１（すなわち、ＲＳフィールド２５２Ａ．１）に設定される。アルファフィールド２５２がＲＳフィールド２５２Ａ．１として機能しているため、ベータフィールド２５４はラウンド処理フィールド２５８（すなわち、ＥＶＥＸ．ｒ_２−０）として解釈される。具体的には、ＥＶＥＸ．ｒ_２はＳＡＥフィールド２５６として解釈され、ＥＶＥＸ．ｒ_１−０はラウンド制御フィールド２５４Ａとして機能する。モディファイアフィールド２４６（すなわち、ＭＯＤＲ／Ｍ．ＭＯＤ３４２）は、非メモリアクセスを示すため１１に設定される。（すなわち、レジスタｚｍｍ３は、メモリオペランドの代わりに第１ソースオペランドとなる。）
図１７Ｃは、非メモリアクセスデータ変換タイプ処理２１５命令テンプレートにおけるＶＡＤＤＰＳ命令の符号化を示す。図１７Ｃの符号化は、アルファフィールド２５２及びベータフィールド２５４を除き図１７Ｂと同一である。アルファフィールド２５２はＲＳフィールド２５２Ａ（すなわち、ＥＶＥＸ．ｒｓ）として解釈され、データ変換タイプ処理を選択するため０に設定される（すなわち、ＲＳフィールド２５２Ａ．２）。アルファフィールド２５２はＲＳフィールド２５２Ａ．２として機能するため、ベータフィールド２５４は、データ変換フィールド２５４Ｂ（すなわち、ＥＶＥＸ．ｓ_２−０）として解釈される。

【0135】

図１７Ｄは、メモリアクセス２２０命令テンプレートにおけるＶＡＤＤＰＳ命令の符号化を示す。データ要素幅フィールド２６４は、３２ビットデータ要素幅を示すため０である。クラスフィールド２６８（すなわち、ＥＶＥＸ．Ｕ）は、ＥＶＥＸ．Ｕ０を示すため０に設定される。アルファフィールド２５２は、イビクションヒントフィールド２５２Ｂ（すなわち、ＥＶＥＸ．ＥＨ）として解釈される。ベータフィールド２５４は、データ操作フィールド２５４Ｃ（すなわち、ＥＶＥＸ．ｓ_２−０）として解釈される。モディファイアフィールド２４６（すなわち、ＭＯＤＲ／Ｍ．ＭＯＤ３４２）は、第１ソースオペランドがメモリオペランドであることを示すため、００、０１又は１０に設定される。これは、図１７Ｄにおいて、

【0136】

【数1】

（すなわち、１１を除く任意の入力）として示される。
・ＥＶＥＸ．Ｕ１のための例示的な命令符号化−図１８Ａ〜１８Ｆ
図１８Ａは、本発明の実施例による一例となる特定のベクトルフレンドリ命令フォーマットからのフィールドのサブセットを示す。具体的には、図１＊Ａは、ＥＶＥＸプリフィックス３０２、リアルオペコードフィールド３３０及びＭＯＤ Ｒ／Ｍフィールド３４０を示す。本実施例では、フォーマットフィールド２４０は、命令フォーマットがベクトルフレンドリ命令フォーマットであることを示すため０×６２を含む。

【0137】

図１８Ｂ〜１８Ｆはそれぞれ、本発明の実施例による図１８Ａの特定のベクトルフレンドリ命令フォーマットに符号化された一例となる特定のベクトルフレンドリ命令からのフィールドのサブセットを示す。図１８Ｂ〜１８Ｆの説明では、一部のフィールドの特定の利用は、ＶＡＤＤＰＳ命令の各種の例示的なコンフィギュレーションのため一部のフィールドの可能な符号化を示すため説明される。図１８Ｂ〜１８Ｆのそれぞれでは、フォーマットフィールド２４０は、当該命令がベクトルフレンドリ命令フォーマットに符号化されていることを示すための０×６２を含み、リアルオペコードフィールド３３０は、ＶＡＤＤＰＳオペコードを含む、図１８Ｂ〜１８Ｆはそれぞれ、本発明の実施例によるＥＶＥＸ．Ｕ１クラスにおけるＶＡＤＤＰＳ命令の符号化を示し、図１８Ｂ〜１８Ｅはそれぞれ、非メモリアクセス２０５命令テンプレートにおけるＶＡＤＤＰＳのＥＶＥＸ．Ｕ１符号化を示し、図１８Ｆは、メモリアクセス２２０命令テンプレートにおけるＶＡＤＤＰＳのＥＶＥＸ．Ｕ１符号化を示す。

【0138】

図１８Ｂは、非メモリアクセスライトマスク制御パーシャルラウンド制御タイプ処理２１２命令テンプレートにおけるＶＡＤＤＰＳ命令の符号化を示す。データ要素幅フィールド２６４は、３２ビットデータ要素幅を示すため０である。クラスフィールド２６８（すなわち、ＥＶＥＸ．Ｕ）は、ＥＶＥＸ．Ｕ１クラスを示すため１に設定される。アルファフィールド２５２は、ライトマスク制御フィールド２５２Ｃとして解釈される（マージング又はゼロ化ライトマスクとの間の選択）。ベータフィールド２５４の最下位ビットは、ＲＬフィールド２５７Ａとして解釈され、パーシャルラウンドタイプ処理（すなわち、ラウンド２５７Ａ．１）を示すため１に設定される。ベータフィールド２５４の２つの最上位ビットは、ラウンド処理フィールド２５９Ａとして解釈される。モディファイアフィールド２４６（すなわち、ＭＯＤＲ／Ｍ．ＭＯＤ３４２）は、非メモリアクセスを示すため１１に設定される。（すなわち、レジスタｚｍｍ３はメモリオペランドの代わりの第１ソースオペランドである。）この符号化では、ＶＡＤＤＰＳ命令は、第１レジスタ（ｚｍｍ３など）から第２レジスタ（ｚｍｍ２など）へのＰａｃｋｅｄシングル精度浮動小数点値を加算し、ライトマスク（ｋ１など）に従ってラウンド化された結果を第３レジスタ（ｚｍｍ３など）に格納する。これは、以下のニーモニックにより示される。すなわち、マージング・ライトマスキングのための｛ｚ｝のないゼロ化・ライトマスキング及び同じためのＥＶＥＸ．Ｕ１．ＮＤＳ．５１２．０Ｆ．Ｗ０５８／ｒＶＡＤＤＰＳ ｚｍｍ１である。その他のニーモニックは、このセクションでは、すべてが｛ｚ｝を含むことを示すが、｛ｚ｝のない同じニーモニックがまた同様に可能であることが理解されるべきである。

【0139】

図１８Ｃ〜１８Ｅはそれぞれ非メモリアクセスライトマスク制御ＶＳＩＺＥタイプ処理２１７命令テンプレートにおけるＶＡＤＤＰＳ命令の符号化を示す。図１８Ｃ〜１８Ｅの符号化は、ベータフィールドを除き図１７Ｂと同一である。図１８Ｃ〜１８Ｅのそれぞれにおいて、ベータフィールド２５４の最下位ビットはＲＬフィールド２５７Ａとして解釈され、ＶＳＩＺＥタイプ処理２５７Ａ．２を示すため０に設定される。ベータフィールド２５４の２つの最上位ビットは、ベクトル長フィールド２５９Ｂとして解釈される。

【0140】

図１８Ｃにおいて、ベクトル長フィールド２５９Ｂは、５１２ビットのベクトルサイズを示すため１０に設定される。図１８Ｄにおいて、ベクトル長フィールド２５９Ｂは、２５６ビットのベクトルサイズを示すため０１に設定される。図１８Ｅにおいて、ベクトル長フィールド２５９Ｂは、１２８ビットのベクトルサイズを示すため００に設定される。この符号化では、ＶＡＤＤＰＳ命令は、第１レジスタ（ｚｍｍ３など）から第２レジスタ（ｚｍｍ２など）へのＰａｃｋｅｄシングル精度浮動小数点値を加算し、ライトマスク（ｋ１など）に従って当該結果を第３レジスタ（ｚｍｍ１など）に格納する。図１８Ｃは、以下のニーモニックにより示される。ＥＶＥＸ．Ｕ１．ＮＤＳ．５１２．０Ｆ．Ｗ０ ５８／ｒ ＶＡＤＤＰＳ ｚｍｍ１｛ｋ１｝｛ｚ｝，ｚｍｍ２，ｚｍｍ３である。図１８Ｄは、以下のニーモニックにより示される。ＥＶＥＸ．Ｕ１．ＮＤＳ．２５６．０Ｆ．Ｗ０ ５８／ｒ ＶＡＤＤＰＳ ｙｍｍ１｛ｋ１｝｛ｚ｝，ｙｍｍ２，ｙｍｍ３である。図１８Ｅは、以下のニーモニックにより示される。ＥＶＥＸ．Ｕ１．ＮＤＳ．１２８．０Ｆ．Ｗ０ ５８／ｒ ＶＡＤＤＰＳ ｘｍｍ１｛ｋ１｝｛ｚ｝，ｘｍｍ２，ｘｍｍ３である。

【0141】

図１８Ｆは、メモリアクセスライトマスク制御２２７命令テンプレートにおけるＶＡＤＤＰＳ命令の符号化を示す。データ要素幅フィールド２６４は、３２ビットデータ要素幅を示すため０である。クラスフィールド２６８（すなわち、ＥＶＥＸ．Ｕ）は、ＥＶＥＸ．Ｕ１クラスを示すため１に設定される。アルファフィールド２５２は、ライトマスク制御フィールド２５２Ｃとして解釈される（マージングライトマスク又はゼロ化ライトマスクとの間で選択）。ベータフィールド２５４の最下位ビットは、ブロードキャストフィールド２５７Ｂとして解釈される。ベータフィールド２５４の２つの最下位ビットは、ベクトル長フィールド２５９Ｂとして解釈される。モディファイアフィールド２４６（すなわち、ＭＯＤＲ／Ｍ．ＭＯＤ３４２）は、第１ソースオペランドがメモリオペランドであることを示すため００、０１又は１０に設定される。これは、図１７Ｄにおいて、

【0142】

【数2】

として（すなわち、１１以外の任意の入力）示される。この符号化では、ＶＡＤＤＰＳ命令は、第１レジスタ（ｚｍｍ２など）にロードに応答してブロードキャスト可能なメモリオペランドからのＰａｃｋｅｄシングル精度浮動小数転置を加算し、ライトマスク（ｋ１など）に従って第２レジスタ（ｚｍｍ１など）に結果を格納する。ベクトル長フィールドが５１２ビットのベクトルを示すとき、これは、以下のニーモニックにより示されてもよい。
ＥＶＥＸ．Ｕ１．ＮＤＳ．５１２．０Ｆ．Ｗ０ ５８／ｒ ＶＡＤＤＰＳ ｚｍｍ１｛ｋ１｝｛ｚ｝，ｚｍｍ２，Ｂ_３２（ｍＶ） ベクトル長フィールドが２５６ビットのベクトルを示すとき、これは、以下のニーモニックにより示されてもよい。
ＥＶＥＸ．Ｕ１．ＮＤＳ．２５６．０Ｆ．Ｗ０ ５８／ｒ ＶＡＤＤＰＳ ｙｍｍ１｛ｋ１｝｛ｚ｝，ｙｍｍ２，Ｂ_３２（ｍＶ） ベクトル長フィールドが１２８ビットのベクトルを示すとき、これは、以下のニーモニックにより示されてもよい。
ＥＶＥＸ．Ｕ１．ＮＤＳ．１２８．０Ｆ．Ｗ０ ５８／ｒ ＶＡＤＤＰＳ ｘｍｍ１｛ｋ１｝｛ｚ｝，ｘｍｍ２，Ｂ_３２（ｍＶ）
・例示的なディスプレースメント８＊Ｎ値
本発明の一実施例では、メモリアクセスサイズＮが、使用される命令テンプレートと後述されるような他のファクタとに依存してベース処理フィールド、データ要素幅フィールド及び拡張処理フィールドの２以上のコンテンツに基づき決定される。本発明の一実施例では、Ｕ＝０（クラスＡ）に関して、以下のテーブルは、メモリにおいてアクセスされるベクトル（又は要素）のサイズと、圧縮されたディスプレースメントのディスプレースメントファクタ（ｄｉｓｐ８＊Ｎ）とを示す。いくつかの命令は、メモリのレベルにおいてフルベクトル粒度の代わりに要素粒度により機能し、以下のテーブルにおいて“要素レベル”カラムを利用するべきである。ファンクションカラムのラベル（Ｕ／Ｓ_ｉ６４など）は、ベース処理フィールド（例えば、Ｕ／Ｓ_ｉはロード整数及びロード／ｏｐ整数を示すなど）と、データ要素幅（例えば、６４は６４ビットデータ要素幅である）とにより指定されるメモリアクセスタイプを示す。当該カラムの値は、図３の実施例においてデータ操作フィールド２５４Ｃの可能な値である。図４Ｂを参照して、各種メモリアクセスタイプがそれらのデータ操作図１２Ａ〜１５Ｃにフローして示され（いくつかのケースでは、データ要素幅判定を介し）、各種テーブル１２Ａ〜１５ＣはＮの値の選択を導出し、適切である場合、カラム２及び３に配置される。例えば、ロード／ｏｐ整数６４ビットデータ要素幅メモリアクセス処理は図１２Ａにフローし、データ操作フィールド２５４Ｃのコンテンツは、データ操作処理（図１２Ａに示されるような）とＮの値（以下に示されるような）との双方を選択するのに利用される。他の例として、ロード整数６４ビットデータ要素幅メモリアクセス処理（ベース処理フィールド２４２においてブロードキャストを示す）は図１３Ａにフローし、データ操作フィールド２５４Ｃのコンテンツが、データ操作処理（図１３Ａに示されるように、ブロードキャストデータ変換を含まない）とＮの値（後述される）との双方を選択するため利用される。従って、第２カラムは、ベース処理フィールド２４２がブロードキャスト又は要素レベルメモリアクセスを指定しない命令のためのものであり、第３カラムの第１サブカラムは、ベース処理フィールド２４２がブロードキャストを指定するが、要素レベルメモリアクセスを指定しない命令のためのものであり、第３カラムの第２サブカラムは、ベース処理フィールド２４２がブロードキャスト又は要素レベルメモリアクセスを指定する命令のためのものである。

【0143】

【表11】

【0144】

【表12】

【0145】

【表13】

【0146】

【表14】

【0147】

【表15】

【0148】

【表16】

【0149】

【表17】

【0150】

【表18】

【0151】

【表19】

【0152】

【表20】

【0153】

【表21】

本発明の一実施例では、Ｕ＝１（クラスＢ）に関して、各種命令が、ベクトル長（ベクトル長フィールド２５９Ｂのコンテンツにより決定される）、ベクトル処理のタイプ及びブロードキャストが実行されているか（ベース処理フィールド２４２及び／又はブロードキャストフィールド２５７Ｂの値）、並びにデータ要素幅（図４Ｅに示されるように、リアルオペコードフィールド３３０及び／又はデータ要素幅フィールド２６４のコンテンツにより決定される）に基づき異なるタイプの命令について決定されるメモリアクセスサイズＮに関してｄｉｓｐ８を利用することによって、圧縮されたディスプレースメントを利用可能である。一般に、メモリアクセスサイズＮは、メモリ入力のバイト数に対応する（例えば、フル５１２ビットメモリベクトルにアクセスするとき６４など）。本発明の一実施例では、以下の第１テーブルは、以下の第２テーブルにおける用語の利用の一部を説明し、第２テーブルは各種命令のためのＮの値を与える。以下のテーブルのＴｕｐｌｅは、メモリのデータのＰａｃｋｅｄ構造である。

【0154】

【表22】

【0155】

【表23】

・リザービングビット
また、本発明のいくつかの実施例では、異なるプロセッサ又はプロセッサ内の異なるコアは、クラスＡのみ、クラスＢのみ又は両方のクラスをサポートしてもよい。例えば、汎用計算用のハイパフォーマンス汎用オウト・オブ・オーダコアは、クラスＢのみをサポートし、主としてグラフィック及び／又は科学（スループット）計算用のコアはクラスＡのみをサポートし、双方用のコアは双方をサポートしてもよい（もちろん、双方のクラスカラのテンプレート及び命令の混合を有するが、双方のクラスカラの必ずしもすべてのテンプレート及び命令を有さないコアは、本発明の範囲内である。）また、シングルプロセッサは、そのすべてが同じクラスをサポートするか、又は異なるコアは異なるクラスをサポートする複数のコアを含むものであってもよい。例えば、別個のグラフィック及び汎用コアを備えたプロセッサでは、主としてグラフィック及び／又は科学計算用のグラフィックコアの１つはクラスＡしかサポートせず、汎用コアの１以上は、クラスＢしかサポートしない汎用計算用のハイパフォーマンス汎用アウト・オブ・オーダコアであってもよい。別個のグラフィックコアを有しない他のプロセッサは、クラスＡとクラスＢとの双方をサポートする１以上の汎用イン・オーダ又はアウト・オブ・オーダコアを有してもよい。もちろん、１つのクラスカラの特徴はまた、本発明の異なる実施例における他のクラスにおいて実現されてもよい。ハイレベル言語により記述されたプログラムは、１）実行用のターゲットプロセッサによりサポートされるクラスの命令のみを有する形式、又は２）コードを現在実行中のプロセッサによりサポートされる命令に基づき実行すべきルーチンを選択する制御フローコードを有し、すべてのクラスの命令の異なる組み合わせを用いて記述された他のルーチンを有する形式を含む各種実行可能形式に置かれる（例えば、ジャストインタイムコンパイル又は静的コンパイルされるなど）。

【0156】

【表24】

ロード、ブロードキャスト及びインサートに関して、本発明の一実施例は、ベース処理フィールドによる異なるバージョンのブロードキャストを実現し、このため、ブロードキャストフィールド２５７Ｂは不要である。バイト／ワード処理について、本発明の一実施例は、当該特徴をサポートするハードウェアコストが現在は正当なものでなかっためた、ブロードキャストフィールド２５７Ｂによるブロードキャストをサポートしていない。ギャザーに関して（ロードの一タイプである）、本発明の一実施例は、ベース処理フィールドによる異なるバージョンのブロードキャストを実現し、このため、ブロードキャストフィールド２５７Ｂは不要である。スキャッタ、抽出及びストアに関して、一実施例は、これらのタイプの命令はレジスタソース（メモリソースでない）とメモリデスティネーションとを有するため、ブロードキャストフィールド２５７Ｂによるブロードキャストをサポートせず、メモリがソースであるときのみ、ブロードキャストは意味がある。ギャザー命令のマスクは、完了マスクであり、マージングライトマスク処理は現在所望の処理である。ストア、スキャッタ又は抽出に対するライトマスクのゼロ化の実行は、ベクトルストア、スキャッタ又は抽出が典型的には利用されない処理のメモリの位置をゼロ化する。比較のため、本発明の一実施例では、ライトマスキングのゼロ化は、比較結果が否定的なものである場合、比較はすでに０を書き込んでいるため不自然であり（例えば、比較された２つの要素が等価の比較のケースにおいて等しくないなど）、従って、比較結果が解釈される方法を妨げる。

【0157】

例示的なパイプライン−図１９〜２２
図１９〜２２は、本発明による４つの例示的なプロセッサパイプラインの異なるステージにおいて図２Ａの命令テンプレートの何れのフィールドが利用されるか示すブロック図である。要求される理解レベルにおいて、図示されたパイプラインステージ及びそれらのファンクションは周知であることに留意すべきである。図１９〜２２のそれぞれは、非メモリアクセスフルラウンド制御タイプ処理２１０命令テンプレート、非メモリアクセスデータ変換タイプ処理２１５命令テンプレート及びメモリアクセス２２５／２３０命令テンプレートをそれぞれ示すＡ、Ｂ及びＣ図を含む。図１９〜２２のそれぞれは異なる一例となるパイプラインを示すが、同一のパイプラインは各図番のＡ〜Ｃ図のそれぞれに示される。例えば、図１９Ａは、非メモリアクセスフルラウンド制御タイプ処理２１０命令テンプレートと一例となる第１命令パイプラインとを示し、図１９Ｂは、非メモリアクセスデータ変換タイプ処理２１５と図１９Ａと同じ例示的なパイプラインとを示し、図２０Ａは非メモリアクセスフルラウンドタイプ制御処理２１０命令テンプレートと一例となる第２プロセッサパイプラインとを示す。

【0158】

図１９〜２２はそれぞれ、プロセッサパイプライン１９００、２０００、２１００及び２２００を示す。パイプラインステージ名は異なるパイプラインにわたって同一である場合、同一の参照番号が理解の容易のため利用された。しかしながら、これは、異なるパイプラインにわたって同一名のパイプラインステージが同じであることを意味するのでなく、単に類似する処理を実行することを意味する（それはより多く又はより少ないサブ処理を含むかもしれないが）。
・例示的な汎用パイプライン−図１９
プロセッサパイプライン１９００は、汎用プロセッサパイプラインを表し、フェッチステージ１９１０、復号化ステージ１９２０、レジスタリード／メモリリードステージ１９３０、データ変換ステージ１９４０、実行ステージ１９５０及びライトバック／メモリライトステージ１９６０を含む。

【0159】

命令テンプレートからプロセッサパイプラインステージへのブラケット及び矢印は、パイプラインステージの異なるものによって利用されるフィールドを示す。例えば、図１９Ａにおいて、フィールドのすべてが復号化ステージ１９２０により利用され、レジスタインデックスフィールド２４４がレジスタリード／メモリリードステージ１９３０により利用され、ｒｓフィールド２５２Ａ（ラウンド２５２Ａ．１）、ＳＡＥフィールド２５６、ラウンド処理フィールド２５８及びデータ要素幅フィールド２６４が、実行ステージ１９６０により利用され、データ要素幅フィールド２６４はまたライトバック／ライトメモリステージ１９６０により利用され、ライトマスクフィールド２６８は実行ステージ１９５０又はライトバック／メモリライトステージ１９６０により利用される。（異なる２つのステージにおける任意的なライトマスクフィールド２７０の利用は、ライトマスクフィールドが実行ステージ１９５０におけるマスクされたデータ要素に対する処理の実行を不可にしうるか（これにより、これらのデータ要素位置がライト／メモリライトステージ１９６０において更新されることを防ぐ）、又は実行ステージ１９５０は、当該処理を実行し、ライトマスクがマスクされたデータ要素位置の更新を防ぐため、ライト／メモリライトステージ１９６０中に適用されることを可能にする。）
矢印は異なるフィールドにより利用されるステージのみを必ずしも表すものでなく、当該フィールドが最大のインパクトを有する可能性がある場所を表すことに留意すべきである。Ａ図とＢ図との間では、拡張処理フィールド２５０がラウンド処理のための実行ステージ１９５０により利用され、拡張処理フィールド２５０がデータ変換タイプ処理のためデータ変換ステージ１９４０により利用され、データ要素幅フィールド２６４から実行ステージ１９５０へのラインがデータ変換ステージ１９４０に移されるという大きな相違があることに留意されたい。図１９Ｃは、レジスタリード／メモリリードステージ１９３０に移動するベース処理フィールド２４２、レジスタリード／メモリリードステージ１９３０により利用される拡張処理フィールド２５０のＥＨフィールド２５２Ｂ、スケールフィールド２６０、ディスプレースメントフィールド２６２Ａ／ディスプレースメントファクタフィールド２６２Ｂ、ライトマスクフィールド２７０、及びそれがメモリリード又はメモリライト処理である否かに応じてレジスタリード／メモリリードステージ１９３０又はライトバック／メモリライト１９６０により任意的に利用されるデータ要素幅フィールド２６４を示す。即値フィールド２７２を利用するパイプラインステージは周知であるため、当該フィールドのマッピングは、本発明を不明りょうにしないように表されない。
・例示的なイン・オーダパイプライン−図２０
プロセッサパイプライン２０００は、イン・オーダプロセッサパイプラインを表し、プロセッサパイプライン２０００と同じ名前のパイプラインステージを有するが、フェッチステージ１９１０と復号化ステージ１９２０との間にレングス復号化ステージ２０１２が挿入されている。

【0160】

図２０Ａ〜２０Ｃのマッピングは、実質的に図１９Ａ〜１９Ｃのものと同じである。
・例示的な第１アウト・オブ・オーダパイプライン−図２１
プロセッサパイプライン２１００は、プロセッサパイプライン２０００と同じ名前のパイプラインステージを有する例示的な第１アウト・オブ・オーダパイプラインを表すが、１）割当てステージ２１２２、リネーミングステージ２１２４、及び復号化ステージ１９２０とレジスタリード／メモリリードステージ１９３０との間に挿入されるスケジュールステージ２１２６と、２）リオーダバッファ（ｒｏｂ）リードステージ２１６２、例外処理ステージ２１６４、及びライトバック／メモリライトステージ１９６０の後に追加されるコミットステージ２１６６を有する。

【0161】

図２１Ａ〜２１Ｃにおいて、マッピングは、１）レジスタインデックスフィールド２４４とモディファイアフィールド２４６とがリネーミングステージ２１４２により利用され、２）図２１Ａのみにおいて、ライトマスクフィールド２７０がまた任意的にマスクされたデータ要素位置に対する例外を抑制するため、例外処理ステージ２１６４により任意的に利用され、３）図２１Ａのみにおいて、ＳＡＥフィールド２５６が浮動小数点例外が抑制されているか否かに応じて実行ステージ１９５０及び例外処理ステージ２１６４により任意的に利用される、という例外はあるが、図２０Ａ〜２０Ｃのマッピングと全体的に同じである。
・例示的な第２オウト・オブ・オーダパイプライン−図２２
プロセッサパイプライン２２００は、データ変換及び実行ステージが実行／データ変換ステージ２２４５を形成するようマージされていることを除き、プロセッサパイプライン２１００と同じ名前のプロセッサパイプラインステージを有する例示的な第２アウト・オブ・オーダパイプラインを表す。

【0162】

図２２Ａ〜２２Ｃのマッピングは、データ変換ステージ１９４０及び実行ステージ１９５０に別々に行われたマッピングが実行／データ変換ステージ２２４５４に移行することを除き、図２１Ａ〜２１Ｃと実質的に同じである。
・例示的なパイプライン上のクラスＢ命令テンプレート
以下のテーブルは、本発明の実施例による図２Ｂの命令テンプレートのフィールドを収容するため図１９〜２２を変更する方法を示す。

【0163】

【表25】

・復号化ステージ１９２０
復号化ステージ１９２０において、各種の周知の復号化ユニットが利用可能である。例えば、復号化ユニットは、各マクロ命令をシングル幅マイクロ命令に復号化するものであってもよい。他の例として、復号化ユニットは、いくつかのマクロ命令をシングル幅マイクロ命令に復号化してもよく、他のものをマルチ幅マイクロ命令に復号化してもよい。アウト・オブ・オーダプロセッサパイプラインに特に適した他の例として、復号化ユニットは、各マクロ命令を１以上のマイクロｏｐに復号化してもよく、各マイクロｏｐが発行され、アウト・オブ・オーダに実行される。

【0164】

復号化ユニットは１以上のデコーダにより実現されてもよく、各デコーダは、当該分野において周知なプログラマブルロジックアレイ（ＰＬＡ）として実現されてもよい。例えば、所与の復号化ユニットは、１）異なるマクロ命令を異なるデコーダに誘導するためのステアリングロジック、２）命令セットのサブセットを復号化し（第２、第３及び第４デコーダより多く）、１回に２つのマイクロｏｐを生成する第１デコーダ、３）命令セット全体のサブセットのみを復号化し、１回に１つのマイクロｏｐしか生成しない第２、第３及び第４デコーダ、４）命令セット全体のサブセットのみを復号化し、１回に４つのマイクロｏｐを生成するマイクロシーケンサＲＯＭ、及び５）何れの出力がマイクロｏｐキューに提供されるか決定するマイクロシーケンサＲＯＭ及びデコーダによる多重化ロジックフィードを有してもよい。デコーダの他の実施例は、より多く又はより少ない命令及び命令サブセットを復号化するより多く又はより少ないデコーダを有してもよい。例えば、一実施例は、１回に２つのマイクロｏｐをそれぞれが生成する第２、第３及び第４デコーダを有してもよく、また１回に８つのマイクロｏｐを生成するマイクロシーケンサＲＯＭを有してもよい。

【0165】

例示的なプロセッサアーキテクチャ−図２３〜２４
・例示的なイン・オーダプロセッサアーキテクチャ−図２３Ａ〜２３Ｂ
図２３Ａ〜Ｂは、一例となるイン・オーダプロセッサアーキテクチャのブロック図を示す。当該実施例は、ワイドベクトルプロセッサ（ＶＰＵ）により拡張されたイン・オーダＣＰＵコアの複数のインスタンス化に関して設計されている。コアは、正確なプリケーションに応じて高帯域幅インターコネクトネットワークを介し固定的なファンクションロジック、メモリＩ／Ｏインタフェース及び他の必要なＩ／Ｏロジックと通信する。例えば、本実施例のスタンドアローンＧＰＵとしての実現は、典型的には、ＰＣＩｅバスを含む。

【0166】

図２３Ａは、本発明の実施例によるオンダイインターコネクトネットワーク２３０２への接続とレベル２（Ｌ２）キャッシュ２３０４のローカルサブセットと共にシングルＣＰＵコアのブロック図である。命令デコーダ２３００は、特定のベクトル命令フォーマット３００を含む拡張を備えたｘ８６命令セットをサポートする。本発明の一実施例では、（設計を簡略化するため）スカラユニット２３０８及びベクトルユニット２３１０が別々のレジスタセットを利用し（それぞれスカラレジスタ２３１２及びベクトルレジスタ２３１４）、それらの間で転送されるデータは、メモリに書き込まれ、レベル１（Ｌ１）キャッシュ２３０６からリードバックされ、本発明の他の実施例は、異なるアプローチを利用してもよい（例えば、シングルレジスタセットを利用するか、又はライト及びリードバックなしに２つのレジスタファイルの間でデータが転送されることを可能にする通信パスを含むなど）。

【0167】

Ｌ１キャッシュ２３０６は、スカラユニット及びベクトルユニットへのキャッシュメモリへの低遅延アクセスを可能にする。ベクトルフレンドリ命令フォーマットのロード−ｏｐ命令と共に、これは、Ｌ１キャッシュ２３０６が拡張されたレジスタファイルと同様に扱うことができることを意味する。これは、特にイビクションヒントフィールド２５２Ｂによる多数のアルゴリズムのパフォーマンスを有意に向上させる。

【0168】

Ｌ２キャッシュ２３０４のローカルサブセットは、ＣＰＵコア毎に１つである別々のローカルサブセットに分割されるグローバルＬ２キャッシュの一部である。各ＣＰＵは、Ｌ２キャッシュ２３０４の自らのローカルサブセットへの直接的なアクセスパスを有する。ＣＰＵコアによりリードされたデータは、それのＬ２キャッシュサブセット２３０４に格納され、自らのローカルＬ２キャッシュサブセットにアクセスする他のＣＰＵとパラレルに迅速にアクセス可能である。ＣＰＵコアにより書き込まれるデータは、それ自体のＬ２キャッシュサブセット２３０４に格納され、必要に応じて、他のサブセットからフラッシュされる。リングネットワークは、共有データのコヒーレンシを保障する。

【0169】

図２３Ｂは、本発明の実施例による図２３ＡのＣＰＵコアの一部の分解図である。図２３Ｂは、Ｌ１キャッシュ２３０４のＬ１データキャッシュ２３０６Ａの部分とと共に、ベクトルユニット２３１０及びベクトルレジスタ２３１４に関するさらなる詳細を含む。具体的には、ベクトルユニット２３１０は、整数、シングル精度フロート及びダブル精度フロート命令を実行する１６ワイドベクトル処理ユニット（ＶＰＵ）である（１６ワイドＡＬＵ２３２８を参照）。ＶＰＵは、スウィズルユニット２３２０によるレジスタ入力のスウィズル処理、数値変換ユニット２３２２Ａ〜Ｂによる数値変換、及びメモリ入力に対する複製ユニット２３２４による複製をサポートする。ライトマスクレジスタ２３２６は、結果としてのベクトルライトをプリディケート（ｐｒｅｄｉｃａｔｅ）することを可能にする。

【0170】

レジスタデータは、例えば、マトリックス乗算をサポートするためなど、各種方法によりスウィズル可能である。メモリからのデータは、ＶＰＵレーンにわたって複製可能である。これは、グラフィックと非グラフィックパラレルデータ処理の双方において通常の処理である、キャッシュ効率を有意に増大する。

【0171】

リングネットワークは、ＣＰＵコア、Ｌ２キャッシュ及び他のロジックブロックなどのエージェントがチップ内で互いに通信することを可能にするため双方向である。各リングデータパスは、方向毎に５１２ビットワイドである。
・例示的なアウト・オブ・オーダアーキテクチャ−図２４
図２４は、本発明の実施例による例示的なアウト・オブ・オーダアーキテクチャを示すブロック図である。具体的には、図２４は、ベクトルフレンドリ命令フォーマット及びその実行を含むよう変更された周知の一例となるアウト・オブ・オーダアーキテクチャを示す。図２４において、矢印は２以上のユニットの間の接続を示し、矢印の方向はこれらのユニットの間のデータフローの方向を示す。図２４は、実行エンジンユニット２４１０及びメモリユニット２４１５に接続されるフロントエンドユニット２４０５を有し、実行エンジンユニット２４１０はさらに、メモリユニット２４１５に接続される。

【0172】

フロントエンドユニット２４０５は、レベル２（Ｌ２）ブランチ予測ユニット２４２２に接続されるレベル１（Ｌ１）ブランチ予測ユニット２４２０を有する。Ｌ１及びＬ２ブランチ予測ユニット２４２０、２４２２は、Ｌ１命令キャッシュユニット２４２４に接続される。Ｌ１命令キャッシュユニット２４２４は、命令フェッチプリデコードユニット２４２８にさらに接続される命令変換ルックアサイドバッファ（ＴＬＢ）２４２６に接続される。命令フェッチプリでコードユニット２４２８は、デコードユニット２４３２にさらに接続される命令キューユニット２４３０に接続される。デコードユニット２４３２は、コンプレックスデコーダユニット２４３４と、３つのシンプルデコーダユニット２４３６、２４３８及び２４４０とを有する。デコードユニット２４３２は、マイクロコードＲＯＭユニット２４４２を有する。デコードユニット２４３２は、デコードステージセクションにおいて上述されたように動作してもよい。Ｌ１命令キャッシュユニット２４２４はさらにメモリユニット２４１５のＬ２キャッシュユニット２４４８に接続される。命令ＴＬＢユニット２４２６はさらに、メモリユニット２４１５において第２レベルＴＬＢユニット２４４６に接続される。デコードユニット２４３２、マイクロコードＲＯＭユニット２４４２及びループストリーム検出ユニット２４４４はそれぞれ、実行エンジンユニット２４１０においてリネーム／割当ユニット２４５６に接続される。

【0173】

実行エンジンユニット２４１０は、リタイアメントユニット２４７４及び統合スケジューラユニット２４５８に接続されるリネーム／割当ユニット２４５６を含む。リタイアメントユニット２４７４はさらに、実行ユニット２４６０に接続され、リオーダバッファユニット２４７８を有する。統合スケジューラユニット２４５８はさらに、実行ユニット２４６０に接続される物理レジスタファイルユニット２４７６に接続される。物理レジスタファイルユニット２４７６は、ベクトルレジスタユニット２４７７Ａ、ライトマスクレジスタユニット２４７７Ｂ及びスカラレジスタユニット２４７７Ｃを有し、これらのレジスタユニットは、ベクトルレジスタ５１０、ベクトルマスクレジスタ５１５及び汎用レジスタ５２５を提供し、物理レジスタファイルユニット２４７６は、図示しない追加的なレジスタファイルを有してもよい（例えば、ＭＭＸ Ｐａｃｋｅｄ整数フラットレジスタファイル５５０にエイリアシングされたスカラ浮動小数点スタックレジスタファイル５４５など）。実行ユニット２４６０は、３つの混合されたスカラ及びベクトルユニット２４６２、２４６４及び２４７２、ロードユニット２４６６、ストアアドレスユニット２４６８、ストアデータユニット２４７０を含む。ロードユニット２４６６、ストアアドレスユニット２４６８及びストアデータユニット２４７０はそれぞれ、メモリユニット２４１５のデータＴＬＢユニット２４５２にさらに接続される。

【0174】

メモリユニット２４１５は、データＴＬＢユニット２４５２に接続される第２レベルＴＬＢユニット２４４６を有する。データＴＬＢユニット２４５２は、Ｌ１データキャッシュユニット２４５４に接続される。Ｌ１データキャッシュユニット２４５４はさらに、Ｌ２キャッシュユニット２４４８に接続される。いくつかの実施例では、Ｌ２キャッシュユニット２４４８はさらに、メモリユニット２４１５の内部及び／又は外部においてＬ３及びより上位のキャッシュユニット２４５０に接続される。

【0175】

例えば、例示的なアウト・オブ・オーダアーキテクチャは、１）命令フェッチプリデコードユニット２４２８はフェッチ及び長さ復号化ステージ１９１０及び２０１２、２）デコードユニット２４３２はデコードステージ１９２０を実行し、３）リネーム／割当ユニット２４５６は割当ステージ２１２２及びリネーミングステージ２１２４を実行し、４）統合スケジューラ２４５８はスケジュールステージ２１２６を実行し、５）物理レジスタファイルユニット２４７６、リオーダバッファユニット２４７８及びメモリユニット２４１５はレジスタリード／メモリリードステージ１９３０を実行し、実行ユニット２４６０は実行／データ変換ステージ２２４５を実行し、６）メモリユニット２４１５及びリオーダバッファユニット２４７８はライトバック／メモリライトステージ１９６０を実行し、７）リタイアメントユニット２４７４はＲＯＢリード２１６２ステージを実行し、８）各種ユニットは例外処理ステージ２１６４に関与してもよく、９）リタイアメントユニット２４７４及び物理レジスタファイルユニット２４７６はコミットステージ２１６６を実行することによって、プロセスパイプライン２２００を実現してもよい。
・例示的なシングルコア及びマルチコアプロセッサ−図２９
図２９は、本発明の実施例による統合されたメモリコントローラ及びグラフィックを備えたシングルコアプロセッサ及びマルチコアプロセッサ２９００のブロック図である。図２９における実線のボックスは、シングルコア２９０２Ａ、システムエージェント２９１０及び１以上のバスコントローラユニット２９１６のセットを備えたプロセッサ２９００を示し、破線のボックスの任意的な追加は、複数のコア２９０２Ａ〜Ｎ、システムエージェントユニット２９１０における１以上の統合されたメモリコントローラユニット２９１４のセット及び統合されたグラフィックロジック２９０８を備えた他のプロセッサ２９００を示す。

【0176】

メモリ階層は、コア内の１以上のレベルのキャッシュ、１以上の共有キャッシュユニット２９０６のセット、及び統合されたメモリコントローラユニット２９１４のセットに接続される外部メモリ（図示せず）を有する。共有キャッシュユニット２９０６のセットは、レベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）又は他のレベルのキャッシュなどの１以上の中間レベルキャッシュ、ラストレベルキャッシュ（ＬＬＣ）及び／又はこれらの組み合わせを含むものであってもよい。一実施例では、リングベースインターコネクトユニット２９１２は、統合されたグラフィックロジック２９０８、共有キャッシュユニット２９０６のセット及びシステムエージェントユニット２９１０を相互接続するが、他の実施例は、当該ユニットを相互接続するための何れかの個数の周知の技術を利用してもよい。

【0177】

いくつかの実施例では、コア２９０２Ａ〜Ｎの１以上はマルチスレッド処理が可能である。システムエージェント２９１０は、コア２９０２Ａ〜Ｎを調整及び実行する上記のコンポーネントを含む。システムエージェントユニット２９１０は、例えば、パワー制御ユニット（ＰＣＵ）及びディスプレイユニットなどを含むものであってもよい。ＰＣＵは、コア２９０２Ａ〜Ｎ及び統合グラフィックロジック２９０８の電力状態を調整するのに必要なロジック及びコンポーネントであってもよく、又は含むものであってもよい。ディスプレイユニットは、１以上の外部接続されたディスプレイを分割するためのものである。

【0178】

コア２９０２Ａ〜Ｎは、アーキテクチャ及び／又は命令セットに関して同質又は異質であってもよい。例えば、コア２９０２Ａ〜Ｎの一部はイン・オーダであり（例えば、図２３Ａ及び２３Ｂに示されるものなど）、他のものはアウト・オブ・オーダである（図２４などに示されるものなど）。他の例として、コア２９０２Ａ〜Ｎの２以上は、同じ命令セットを実行可能であってもよく、他のものは当該命令セットのサブセットのみ又は異なる命令セットを実行可能であってもよい。コアの少なくとも１つは、ここに接続されるベクトルフレンドリ命令フォーマットを実行可能である。

【0179】

プロセッサは、カリフォルニア州サンタクララのインテルコーポレイションから入手可能なＣｏｒｅ^ＴＭｉ３，ｉ５，ｉ７，２Ｄｕｏ及びＱｕａｄ、Ｘｅｏｎ^ＴＭ又はＩｔａｎｉｕｍプロセッサなどの汎用プロセッサであってもよい。あるいは、プロセッサは、他の企業からのものであってもよい。プロセッサは、例えば、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックプロセッサ、コプロセッサ、埋め込みプロセッサなどの特定用途プロセッサであってもよい。プロセッサは、１以上のチップ上に実現されてもよい。プロセッサ２９００は、ＢｉＣＭＯＳ、ＣＭＯＳ又はＮＭＯＳなどの複数のプロセス技術の何れかを利用して１以上の基板上に実現されてもよく、及び／又はその一部であってもよい。

【0180】

例示的なコンピュータシステム及びプロセッサ−図２５〜２８
図２５〜２７は、プロセッサ２９００を含むのに適した一例となるシステムであり、図２８は、コア２９０２の１以上を含むものであってもよい一例となるＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）である。ラップトップ、デスクトップ、携帯ＰＣ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、エンジニアリングワークステーション、サーバ、ネットワーク装置、ネットワークハブ、スイッチ、埋め込みプロセッサ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、グラフィック装置、ビデオゲーム装置、セットトップボックス、マイクロコントローラ、携帯電話、ポータブルメディアプレーヤー、携帯装置及び他の各種電子装置について当該分野で知られる他のシステム設計及びコンフィギュレーションがまた適している。一般に、ここに開示されるようなプロセッサ及び／又は他の実行ロジックを搭載可能な各種システム又は電子装置が一般に適している。

【0181】

図２５を参照して、本発明の一実施例によるシステム２５００のブロック図が示される。システム２５００は、ＧＭＣＨ（Ｇｒａｐｈｉｃｓ Ｍｅｍｏｒｙ Ｃｏｎｔｒｏｌｌｅｒ Ｈｕｂ）２５２０に接続される１以上のプロセッサ２５１０、２５１５を含むものであってもよい。図２５において、追加的なプロセッサ２５１５の任意的な性質は破線により示される。

【0182】

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

【0183】

図２５は、ＧＭＣＨがＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などであってもよいメモリ２５４０に接続されてもよいことを示す。ＤＲＡＭは、少なくとも１つの実施例について不揮発性キャッシュに関連付けされてもよい。

【0184】

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

【0185】

さらに、ＧＭＣＨ２５２０は、ディスプレイ２５４５（フラットパネルディスプレイなど）に接続される。ＧＭＣＨ２５２０はさらに、各種周辺装置とシステム２５００とを接続するのに利用されてもよい入出力（Ｉ／Ｏ）コントローラハブ（ＩＣＨ）２５５０に接続される。図２５の実施例などにおいて、他の周辺装置２５７０と共にＩＣＨ２５５０に接続される離散グラフィック装置であってもよい外部グラフィック装置２５６０が示される。

【0186】

あるいは、さらなる又は異なるプロセッサがまた、システム２５００に存在してもよい。例えば、追加的なプロセッサ２５１５は、プロセッサ２５１０と同じ追加的なプロセッサ、プロセッサ２５１０について異質な又は非対称な追加的なプロセッサ、アクセラレータ（グラフィックアクセラレータ又はＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ）ユニットなど）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）又は他の何れかのプロセッサを含むものであってもよい。アーキテクチャ、マイクロアーキテクチャ、サーマル、電力消費特性などを含むメリットのメトリックの範囲に関して物理リソース２５１０、２５１５との間に各種装置が存在しうる。これらの相違は、処理要素２５１０、２５１５の間で非対称性及び異質性として効果的に示される。少なくとも１つの実施例について、各種処理要素２５１０、２５１５は同一のダイパッケージにあってもよい。

【0187】

図２６を参照して、本発明の実施例による第２システム２６００のブロック図が示される。図２６に示されるように、マルチプロセッサシステム２６００はポイント・ツー・ポイントインターコネクトシステムであり、ポイント・ツー・ポイントインターコネクト２６５０を介し接続される第１プロセッサ２６７０と第２プロセッサ２６８０とを含む。図２６に示されるように、プロセッサ２６７０、２６８０の各々はあるバージョンのプロセッサ２９００であってもよい。

【0188】

あるいは、プロセッサ２６７０、２６８０の１以上は、アクセラレータ又はＦＰＧＡなどのプロセッサ以外の要素であってもよい。

【0189】

２つのみのプロセッサ２６７０、２６８０と共に示されるが、本発明の範囲はこれに限定されるものでないことが理解されるべきである。他の実施例では、１以上の追加的な処理要素が所与のプロセッサに存在してもよい。

【0190】

プロセッサ２６７０は、ＩＭＣ（Ｉｎｔｅｇｒａｔｅｄ Ｍｅｍｏｒｙ Ｃｏｎｔｒｏｌｌｅｒ）ハブ２６７２とポイント・ツー・ポイント（Ｐ−Ｐ）インタフェース２６７６、２６７８とを含むものであってもよい。同様に、第２プロセッサ２６８０はＩＭＣ２６８２とＰ−Ｐインタフェース２６８６、２６８８とを有してもよい。プロセッサ２６７０、２６８０は、ＰｔＰインタフェース回路２６７８、２６８８を用いてポイント・ツー・ポイント（ＰｔＰ）インタフェース２６５０を介しデータをやりとりしてもよい。図２６に示されるように、ＩＭＣ２６７２及び２６８２は、プロセッサと各自のメモリ、すなわち、各プロセッサにローカルに付属されるメインメモリの一部であってもよいメモリ２６４２、２６４４とを接続する。

【0191】

プロセッサ２６７０、２６８０はそれぞれ、ポイント・ツー・ポイントインタフェース回路２６７６、２６９４、２６８６、２６９８を用いて個別のＰ−Ｐインタフェース２６５２，２６５４を介しチップセット２６９０とデータをやりとりしてもよい。チップセット２６９０はまた、ハイパフォーマンスグラフィックインタフェース２６３９を介しハイパフォーマンスグラフィック回路２６３８とデータをやりとりしてもよい。

【0192】

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

【0193】

チップセット２６９０は、インタフェース２６９６を介し第１バス２６１６に接続されてもよい。一実施例では、第１バス２６１６は、本発明の範囲はこれに限定されるものでないが、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｎｃｔ（ＰＣＩ）バス、ＰＣＩ Ｅｘｐｒｅｓｓバスや他の第３世代Ｉ／Ｏインターコネクトバスなどのバスであってもよい。

【0194】

図２６に示されるように、各種Ｉ／Ｏ装置２６１４が、第１バス２６１６と第２バス２６２０とを接続するバスブリッジ２６１８と共に、第１バス２６１６に接続されてもよい。一実施例では、第２バス２６２０は、ＬＰＣ（Ｌｏｗ Ｐｉｎ Ｃｏｕｎｔ）バスであってもよい。キーボード／マウス２６２２、通信装置２６２６及び一実施例ではコード２６３０を有してもよいディスクドライブ又は他のマスストレージ装置などのデータストレージユニット２６２８などを含む各種装置が、第２バス２６２０に接続されてもよい。さらに、オーディオＩ／Ｏ２６２４が、第２バス２６２０に接続されてもよい。他のアーキテクチャが可能であることに留意されたい。例えば、図２６のポイント・ツー・ポイントアーキテクチャの代わりに、システムはマルチドロップバス又は他のアーキテクチャを実現してもよい。

【0195】

図２７を参照して、本発明の実施例による第３システム２７００のブロック図が示される。図２６及び２７の同様の要素は同様の参照番号を有し、図２６の特定の態様は、図２７の他の態様を不明りょうにすることを回避するため、図２７から省略された。

【0196】

図２７は、処理要素２６７０、２６８０はそれぞれ統合されたメモリ及びＩ／Ｏ制御ロジック（ＣＬ）２６７２、２６８２を有してもよいことを示す。少なくとも１つの実施例について、ＣＬ２６７２、２６８２は、図２９及び２６に関して上述されたものなどのメモリコントローラハブロジック（ＩＭＣ）を含むものであってもよい。さらに、ＣＬ２６７２、２６８２はまた、Ｉ／Ｏ制御ロジックを有してもよい。図２７は、メモリ２６４２、２６４４がＣＬ２６７２、２６８２に接続されるだけでなく、Ｉ／Ｏ装置２７１４がまた制御ロジック２６７２、２６８２に接続されることを示す。従来のＩ／Ｏ装置２７１５はチップセット２６９０に接続される。

【0197】

図２８を参照して、本発明の実施例によるＳｏＣ２８００のブロック図が示される。図２９の同様の要素は同様の参照番号を有する。また、破線のボックスは、より先進的なＳｏＣに関する任意的な特徴である。図２８において、インターコネクトユニット２８０２は、１以上のコア２９０２Ａ〜Ｎのセットと共有キャッシュユニット２９０６を有するアプリケーションプロセッサ２８１０、システムエージェントユニット２９１０、バスコントローラユニット２９１６、統合されたメモリコントローラユニット２９１４、統合されたグラフィックロジック２９０８を有する１以上のメディアプロセッサ２８０２、スチル及び／又はビデオカメラ機能を提供する画像プロセッサ２８２４、ハードウェアオーディオアクセラレーションを提供するオーディオプロセッサ２８２８、ビデオ符号化／復号化アクセラレーションを提供するビデオプロセッサ２８２８、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）ユニット２８３０、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）ユニット２８３２、及び１以上の外部ディスプレイに接続するためのディスプレイユニット２８４０に接続されてもよい。

【0198】

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

【0199】

図２６に示されるコード２６３０などのプログラムコードは、ここに開示される機能を実行し、出力情報を生成するため入力データに適用されてもよい。出力情報は、既知の方法により１以上の出力装置に適用されてもよい。本出願のため、処理システムは、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）又はマイクロプロセッサなどのプロセッサを有する何れかのシステムを有する。

【0200】

プログラムコードは、処理システムと通信するためハイレベルな手続き型又はオブジェクト指向型プログラミング言語により実現されてもよい。プログラムコードはまた、所望される場合、アセンブリ又は機械言語により実現されてもよい。実際、ここに開示される機構は、何れか特定のプログラミング言語に範囲が限定されるものでない。何れのケースでも、言語はコンパイル又はインタープリットされた言語であってもよい。

【0201】

少なくとも１つの実施例の１以上の態様は、マシーンにより読み込まれると、当該マシーンにここに開示された技術を実行するためのロジックを構成させるプロセッサ内の各種ロジックを表すマシーン可読媒体に格納される命令により実現されてもよい。“ＩＰコア”として知られるこのような表現は、有形なマシーン可読媒体に格納され、ロジック又はプロセッサを実際に作製する製造マシーンにロードするため各種カスタム又は製造施設に供給されてもよい。

【0202】

このようなマシーン可読記憶媒体は、限定することなく、ハードディスクなどの記憶媒体、フロッピー（登録商標）ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−ＲＷ）及び光磁気ディスクを含む他の何れかのタイプのディスク、ＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭなどの半導体装置、磁気若しくは光カード又は電子命令を格納するのに適した他の何れかのタイプの媒体を含む、マシーン又は装置により製造又は形成される非一時的で有形な物の構成を含むものであってもよい。

【0203】

従って、本発明の実施例はまた、ここに開示される構成、回路、装置、プロセッサ及び／又はシステムの特徴を規定するＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などの設計データを含む又はベクトルフレンドリ命令フォーマットの命令を含む非一時的な有形のマシーン可読媒体を含む。このような実施例はまた、プログラムと呼ばれてもよい。

【0204】

いくつかのケースでは、命令コンバータは、ソース命令セットからターゲット命令セットに命令を変換するため利用されてもよい。例えば、命令コンバータは、命令をコアにより処理される１以上の他の命令に変換（例えば、静的バイナリ変換、動的コンパイルを含む動的バイナリ変換などを利用して）、モーフィング、エミュレート又はコンバートしてもよい。命令コンバータは、ソフトウェア、ハードウェア、ファームウェア又はこれらの組み合わせにより実現されてもよい。命令コンバータは、オンプロセッサ、オフプロセッサ、又は部分的にオン及びオフのプロセッサであってもよい。

【0205】

図３０は、本発明の実施例によるソース命令セットのバイナリ命令をターゲット命令セットのバイナリ命令に変換するためのソフトウェア命令コンバータの利用を示すブロック図である。図示された実施例では、命令コンバータは、ソフトウェア、ファームウェア、ハードウェア又はこれらの各種組み合わせにより実現されてもよいが、ソフトウェア命令コンバータである。図３０は、ハイレベル言語３００２のプログラムが、少なくとも１つのｘ８６命令セットコア３０１６によりプロセッサにより直接実行されてもよいｘ８６バイナリコード３００６を生成するため、ｘ８６コンパイラ３００４を利用してコンパイルされてもよい。（コンパイルされた命令の一部はベクトルフレンドリ命令フォーマットによるものであることが仮定される。）少なくとも１つのｘ８６命令セットコア３０１６を備えたプロセッサは、少なくとも１つのｘ８６命令セットコアを備えたインテルプロセッサと実質的に同じ結果を実現するため、（１）インテルｘ８６命令セットコアの命令セットの実質的な一部、又は２）少なくとも１つのｘ８６命令セットコアを備えたインテルプロセッサ上で実行されるよう対象とされたオブジェクトコードバージョンのアプリケーション若しくは他のソフトウェアを互換的に実行又は処理することによって、少なくとも１つのｘ８６命令セットコアを備えたインテルプロセッサと実質的に同じ機能を実行可能な何れかのプロセッサを表す。ｘ８６コンパイラ３００４は、追加的なリンケージ処理によって又はなしに少なくとも１つのｘ８６命令セットコア３０１６を備えたプロセッサ上で実行可能なｘ８６バイナリコード３００６（オブジェクトコードなど）を生成するよう動作可能なコンパイラを表す。同様に、図３０は、少なくとも１つのｘ８６命令セットコア３０１４なしにプロセッサにより直接実行されてもよい他の命令セットバイナリコード３０１０を生成するため、他の命令セットコンパイラ３００８を利用してコンパイルされてもよい（例えば、カリフォルニア州ＳｕｎｎｙｖａｌｅのＡＲＭ ＨｏｌｄｉｎｇｓのＡＲＭ命令セットを実行する、及び／又はカリフォルニア州ＳｕｎｎｙｖａｌｅのＭＩＰＳ ＴｅｃｈｎｏｌｏｇｉｅｓのＭＩＰＳ命令セットを実行するコアを備えたプロセッサなど）。命令コンバータ３０１２は、ｘ８６バイナリコード３００６をｘ８６命令セットコア３０１４なしにプロセッサに直接実行されるコードに変換するのに利用される。この変換されたコードは、これが可能な命令コンバータが生成するのが困難であるため、他の命令セットバイナリコード３０１０と同じである可能性はないが、変換されたコードは全体処理を実行し、他の命令セットからの命令から生成されてもよい。従って、命令コンバータ３０１２は、エミュレーション、シミュレーション又は他の何れかのプロセスを介しｘ８６命令セットプロセッサ又はコアを有しないプロセッサ又は他の電子装置がｘ８６バイナリコード３００６を実行することを可能にするソフトウェア、ファームウェア、ハードウェア又はこれらの組み合わせを表す。

【0206】

ここに開示されるベクトルフレンドリ命令フォーマットによる命令の特定の処理は、ハードウェアコンポーネントにより実行され、当該処理を実行する命令によりプログラムされた回路又は他のハードウェアコンポーネントをもたらす又は少なくとも生じさせるのに利用されるマシーン実行可能な命令により実現されてもよい。当該回路は、２，３例をあげると、汎用又は特定用途プロセッサ又はロジック回路を含むものであってもよい。当該処理はまた、任意的にはハードウェアとソフトウェアとの組み合わせにより実行されてもよい。実行ロジック及び／又はプロセッサは、命令により指定された結果オペランドを格納するため、マシーン命令から導出されるマシーン命令又は１以上の制御信号に対応する特定の回路又は他のロジックを含むものであってもよい。例えば、ここに開示される命令の実施例は、図２５〜２８の１以上のシステムにおいて実行されてもよく、ベクトルフレンドリ命令フォーマットの命令の実施例は、システムにおいて実行されるプログラムコードに格納されてもよい。さらに、これらの図の処理要素は、ここに開示される詳細なパイプライン及び／又はアーキテクチャ（例えば、イン・オーダ及びアウト・オブ・オーダアーキテクチャなど）の１つを利用してもよい。例えば、イン・オーダアーキテクチャのデコードユニットは、命令を復号化し、復号化された命令をベクトル又はスカラユニットなどにわたしてもよい。

【0207】

上記説明は、本発明の好適な実施例を示すためのものである。上記の説明から、特に成長が速く、さらなる発展が容易には予想されない当該技術エリアにおいて、本発明は、添付した請求項及びその均等の範囲内の本発明の原理から逸脱することなく当業者により構成及び詳細について変更可能である。例えば、方法の１以上の処理は組み合わせ又は分離されてもよい。

【0208】

他の実施例
ベクトルフレンドリ命令フォーマットを直接実行する実施例が説明されたが、本発明の他の実施例は、異なる命令セットを実行するプロセッサ（例えば、カリフォルニア州ＳｕｎｎｙｖａｌｅのＭＩＰＳ ＴｅｃｈｎｏｌｏｇｉｅｓのＭＩＰＳ命令セットを実行するプロセッサ、カリフォルニア州ＳｕｎｎｙｖａｌｅのＡＲＭ ＨｏｌｄｉｎｇｓのＡＲＭ命令セットを実行するプロセッサなど）上で実行されるエミュレーションレイヤを介しベクトルフレンドリ命令フォーマットを実行してもよい。また、図のフロー図は本発明の特定の実施例により実行される処理の特定の順序を示しているが、当該順序は一例であることが理解されるべきである。（他の実施例は、異なる順序により処理を実行し、特定の処理を合成し、特定の処理をオーバラップするなどしてもよい）。

【0209】

上記説明では、説明のために多数の具体的な詳細が、本発明の実施例の完全な理解を提供するため提供されている。しかしながら、１以上の他の実施例がこれらの具体的な詳細の一部なしに実現可能であることが、当業者に明らかであろう。開示される特定の実施例は、本発明を限定するものでなく、本発明の実施例を説明するため提供される。本発明の範囲は、上述した特定の具体例でなく以下の請求項により決定される。

【符号の説明】

【0210】

２５００ システム
２５１０、２５１５ プロセッサ

【図1A】

【図1B】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】

【図3D】

【図4A】

【図4B】

【図4C】

【図4D】

【図4E】

【図5】

【図6A】

【図6B】

【図6C】

【図7A】

【図7B】

【図8A】

【図8B】

【図9】

【図10A】

【図10B】

【図10C】

【図11A】

【図11B】

【図12A】

【図12B】

【図12C】

【図12D】

【図13A】

【図13B】

【図13C】

【図13D】

【図14A】

【図14B】

【図14C】

【図14D】

【図15A】

【図15B】

【図15C】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23A】

【図23B】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】