JP5764257B2 - レジスタをアライメントするためのシステム、装置、および方法 - Google Patents

Description

本願発明の分野は一般的にコンピュータプロセッサアーキテクチャに関し、より詳細には、実行されると特定の結果をもたらす命令に関する。

プロセッサのＳｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ，Ｍｕｌｔｉｐｌｅ Ｄａｔａ（ＳＩＭＤ）の幅が大きくなるにつれ、アプリケーション開発者（および編集者）にとって、ＳＩＭＤハードウェアの十分な活用がより難しくなってきている。なぜなら、データ要素が自然には完全なベクトルのサイズに対してアライメントされ、キャッシュメモリ階層の２つの別個の線上にメモリ参照が位置するキャッシュラインのスプリット（ｓｐｌｉｔ）が通常生じるからである。従来、キャッシュラインのスプリットに対処する方法としては、キャッシュラインのスプリットの状況を検出し、２つの異なるＴＬＢルックアップを実行し、２つのキャッシュラインのアクセスを行い、これにより２つの独立したメモリポートを用いること、および／または専用のロジックを用いてメモリからの２つの連続するキャッシュラインから送られてくる複数のデータをマージすること、などが行われてきた。

添付の図面を用いて、本願発明を限定ではなく例示により説明する。図面において同様の参照符号は同様の要素を示す。
図１は、アライメント命令の例示的な実行を示す。 図２は、アライメント命令の例示的な実行を示す。 図３は、アライメント命令の例示的な実行を示す。 図４は、プロセッサでアライメント命令を実行することにより２つのソースからのデータをアライメントし、宛て先位置に当該アライメントされたデータを格納するための方法の実施形態を示す。 図５は、アライメント命令を処理するための方法の実施形態を示す。 図６は、アライメント命令を処理するための方法の実施形態を示す。 図７は、擬似コードでアライメント命令を処理するための方法の実施形態を示す。 図８Ａは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、およびそのクラスＡの命令テンプレートを示すブロック図である。 図８Ｂは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、およびそのクラスＢ命令テンプレートを示すブロック図である。 図９Ａは、本願発明の実施形態に係る例示的な特定のベクトルフレンドリーな命令形式を示すブロック図である。 図９Ｂは、本願発明の実施形態に係る例示的な特定のベクトルフレンドリーな命令形式を示すブロック図である。 図９Ｃは、本願発明の実施形態に係る例示的な特定のベクトルフレンドリーな命令形式を示すブロック図である。 図１０は、本願発明の一実施形態に係るレジスタアーキテクチャを示すブロック図である。 図１１Ａは、本願発明の実施形態に係る、シングルＣＰＵコア、並びに、そのオンダイインターコネクトネットワークへの接続、およびそのレベル２（Ｌ２）キャッシュのローカルサブセットを示すブロック図である。 図１１Ｂは、本願発明の実施形態に係る、図１１ＡのＣＰＵコアの一部の分解図である。 図１２は、本願発明の実施形態に係る例示的なアウトオブオーダーアーキテクチャを示すブロック図である。 図１３は、本願発明の一実施形態に係るシステムを示すブロック図である。 図１４は、本願発明の実施形態に係る第２システムを示すブロック図である。 図１５は、本願発明の実施形態に係る第３システムを示すブロック図である。 図１６は、本願発明の実施形態に係るＳｏＣを示すブロック図である。 図１７は、本願発明の実施形態に係る、集積メモリコントローラおよび集積グラフィックを備えるシングルコアプロセッサ、並びにマルチコアプロセッサを示すブロック図である。 図１８は、本願発明の実施形態に係る、ソース命令セットのバイナリ命令をターゲット命令セットのバイナリ命令に変換するソフトウェア命令コンバータの利用を対比するブロック図である。

以下の説明において、様々な特定的な詳細が示される。しかし、本願発明の実施形態は、これら特定的な詳細を用いずとも実施できる。他の例においては、この説明の理解を曖昧にすることを避けるべく、周知の回路、構造、および技術が詳細には示されていない。

本明細書において「一実施形態」、「実施形態」、「例示的な実施形態」などについて言及した場合、説明される実施形態が特定の特徴、構造、または特性を含んでよいことを示し、全ての実施形態がそれら特定の特徴、構造、または特性を含んでいなければならないことを示すわけではない。さらに、そのような文言は必ずしも同じ実施形態を指すとは限らない。さらに、ある実施形態に関連して特定の特徴、構造、または特性を説明する場合、明示的に説明されていようとされてなかろうと、当業者であれば他の実施形態に関連してそれらの特徴、構造、または特性を実施することが出来る。

上記で詳述したように、従来技術におけるデータ要素のアラインメントにおいては、いくつかの所望されない結果を招くことになるいくつかの処理が必要となる。例えば、いくつかの状況においては、ユーザが特定のニーモニックにより潜在的にミスアライメントとなる動作を指定し（ＶＭＯＶＵＰＳのような命令を実行するなど）、キャッシュラインのスプリットが常に生成されるものと仮定すると、実行が遅くなる、他の状況においては、ハードウェアが実行時にキャッシュのミスアライメントを検出させられ、パフォーマンスにとって不利な条件がさらに生じる。

アライメント
ベクトルアライメント（ＶＡＬＩＧＮ）命令の実施形態、および、それらの命令を実行するのに用いられ得るシステム、アーキテクチャ、命令形式などの実施形態を以下に詳述する。ベクトルアライメント命令は実行されるとプロセッサに対し、当該命令の第１ソースオペランドおよび第２ソースオペランドのデータ要素を連結させ、当該命令のオフセット値（即値）に基づき当該連結されたデータからのデータ要素を右にシフトさせ、シフトされ連結されたデータの要素のうち１以上を宛て先ベクトルレジスタに格納させる。いくつかの実施形態において、宛て先ベクトルレジスタに格納されるべき、シフトされ連結されたデータの要素は、書き込みマスクレジスタの対応するビットに基づき判断される。第１ソースおよび第２ソースは共にレジスタ、メモリ位置、またはこれらの組み合わせであり得る。いくつかの実施形態において、ソースがメモリ位置である場合、そのデータは、連結される前にレジスタにロードされる。

この命令の一例は「ＶＡＬＩＧＮＤ ｚｍｍ１｛ｋ１｝，ｚｍｍ２，ｚｍｍ３／ｍ５１２，ｏｆｆｓｅｔ」である。ここでｚｍｍ１、ｚｍｍ２、ｚｍｍ３はベクトルレジスタ（１２８、２５６、５１２ビットのレジスタなど）であり、ｍ５１２は、レジスタまたは即値に格納される５１２ビットのメモリオペランドであり、ｋ１は、書き込みマスクオペランド（上記にて詳述した１６ビットのレジスタなど）であり、オフセットは、以下に詳述するように連結された後にソースのデータ要素の３２ビットの要素でのアライメントを命令する即値（例えば、８ビットの即値）である。メモリから読み取られるあらゆるものが、メモリアドレスから開始する連続するビットの集合であり、宛て先レジスタのサイズに応じていくつかのサイズ（１２８、２５６、５１２ビットなど）のうちいずれかのサイズを有し得る。サイズは一般的に、宛て先レジスタと同じサイズである。いくつかの実施形態において、書き込みマスクは異なるサイズ（８ビット、３２ビットなど）であり得る加えて、いくつかの実施形態において、書き込みマスクの全てのビットが命令によって用いられるわけではない（例えば、最下位の８つのビットのみが用いられる）。当然ながら、ＶＡＬＩＧＮＤは命令のオペコードである。典型的には、各オペランドは命令において明示的に定められている。データ要素のサイズは、例えば上述したように「Ｗ」などのデータ粒度ビットの表示を用いることにより、命令の「プレフィックス」に定められていてもよい。多くの実施形態において、Ｗは、各データ要素が３２または６４ビットであることを示す。データ要素のサイズが３２ビットであり、ソースのサイズが５１２ビットである場合、ソースあたり１６のデータ要素がある。

図１は、アライメント命令の例示的な実行を示す。この例において、それぞれ１６のデータ要素を有する２つのソースがある。多くの場合、これらのソースのうちの１つはレジスタである（この例に関しては、ソース１ １０１が１６の３２ビットのデータ要素を有するＺＭＭレジスタなどの５１２ビットのレジスタとして扱われるが、ＸＭＭおよびＹＭＭレジスタ、１６または６４ビットのデータ要素など他のデータ要素およびレジスタサイズが用いられ得る）。他方のソース１０３は、レジスタまたはメモリ位置である（この例において、ソース２が他方のソースである）。第２ソースがメモリ位置である場合、多くの実施形態において、第２ソースは、ソースの連結の前に、一時レジスタに入れられる。加えて、メモリ位置のデータ要素は、第２ソースが一時レジスタに入れられる前に、データ変換が行われてもよい。データ１０１は、Ａ〜Ｐまでの１６のデータ要素を含み、データ１０３は、Ｑ〜ＡＦまでの１６のデータ要素を含む。

示されるように、レジスタ１０１、１０３からのデータは、第１データレジスタ１０１の最下位のデータ要素であるＡと連結され、連結されたデータ１０５の最下位のデータ要素が生成される。第１データレジスタ１０１の最上位のデータ要素の直ぐ後には第２データレジスタ１０３の最下位のデータ要素Ｑが続く。連結されたデータ要素１０５は３（命令の即値）だけシフト（アライメント）され、これにより、オリジナルのソースからのデータ要素Ｄ〜ＡＦが残ることになる。当然ながら、ビッグエンディアン形式も用いることが出来、データ要素は対応する即値の分だけ左にシフトされてもよい。

このシフトされ連結されたデータの最下位のデータ要素（Ｄ〜Ｓ）は、命令の宛て先レジスタにデータ要素スロットがなくなるまで、宛て先レジスタへ書き込まれる。他の実施形態において、最上位のデータ要素は宛て先レジスタ１０７に書き込まれる。この書き込みは並行して、または順番に行われてもよい。示されるように、宛て先レジスタにはこのサイズの１６のデータ要素を格納するためのスペースしかないので、１６の最下位のデータ要素が宛て先レジスタに書き込まれる。

図２は、同じソースデータおよびシフトを示すが、連結されシフトされたデータ１０５のうちどの最下位のデータ要素が宛て先レジスタに書き込まれるべきかを、マスクレジスタ２０１のコンテンツを用いて判断している。いくつかの実施形態において、このマスクレジスタは上記にて詳述した「ｋ」マスクレジスタ（ｋ１〜ｋ７）である。マスクレジスタは０ｘ８７８Ｂとして示されている。「１」の値を格納するマスクの各位置に関して、連結されシフトされたデータ１０５からの対応するデータ要素が、宛て先レジスタの対応する位置に書き込まれる。例えば、マスクの位置「０」は「１」なので、シフトされ連結されたデータ要素の対応するデータ要素位置「０」の値Ｄが、宛て先レジスタの位置「０」に格納される。「０」の値を格納するマスクの各位置に関して、宛て先レジスタの対応するデータ要素は上書きされない。例えば、位置「２」においてマスクは「０」なので、宛て先は値Ｆで上書きされずにＤＣのままである。「１」を特定のデータ要素位置が宛て先レジスタに書き込まれるべきであることを示す表示として示し、「０」をそのような書き込みを行うべきでないことを示す表示として示しているが、他の実施形態においては逆の方式を用いてもよい。加えて、いくつかの実施形態においては、最上位のデータ要素が書き込まれ、最下位のデータ要素が書き込まれない。

図３は、同じソースデータおよびシフトを示すが、連結されシフトされたデータ１０５のうちどの最下位のデータ要素が宛て先レジスタに書き込まれるべきかを、マスクレジスタのコンテンツを用いて判断している。このインスタンスにおいて、マスクビットのうち全てが用いられるわけではない。このことは、例えばいくつかの実施形態において、６４ビットのデータ要素、５１２ビットのレジスタの場合に起こり得る。

図４は、プロセッサでアライメント命令を実行することにより２つのソースからのデータをアライメントし、宛て先位置に当該アライメントされたデータを格納するための方法の実施形態を示す。４０１において、宛て先オペランドと、第１ソースオペランドと、第２ソースオペランドと、オフセット値（即値）と、マスクオペランドとを含むアライメント命令が受信される。宛て先オペランドおよびソースオペランドのサイズは同じである。いくつかの実施形態において、これらのサイズは全て５１２ビットである。しかし、他の実施形態においては、これらのサイズは全て、１２８または２５６ビットなどの異なるサイズであってもよい。典型的には、宛て先オペランドおよび第１ソースオペランドは共に、上述したようにベクトルレジスタ（ＸＭＭ、ＹＭＭ、またはＺＭＭ）のうち１つなどのレジスタである。第２ソースオペランドはレジスタまたはメモリオペランドであってよい。いくつかの実施形態において、オフセットは８ビットの即値である。受信されるマスクは、上述した「ｋ」個の書き込みマスクのうちの１つであってよく、または、いくつかの実施形態においては、異なるレジスタまたはメモリ位置である。

４０３においてアライメント命令がデコードされる。命令形式に応じて、この段階では、例えばデータ変換が行われるかどうか、どのレジスタに書き込みどのレジスタから読み取るか、メモリソースオペランドと、含まれる場合にはオフセットとを用いてどのメモリアドレスにアクセスするか、などに関して様々なデータがインタープリトされ得る。

４０５において、ソースオペランド値が読み取られる。両方のソースがレジスタである場合、これらのレジスタが読み取られる。ソースオペランドのうち１つまたは両方がメモリオペランドである場合、当該オペランドに関連付けられたデータ要素が読み取られる。いくつかの実施形態において、メモリからのデータ要素は一時レジスタに格納される。

データ要素の変換（アップコンバート、ブロードキャスト、スウィズルなど）が実施される場合には、４０７において実施されてもよい。例えば、メモリからの１６ビットのデータ要素が３２ビットのデータ要素にアップコンバートされてもよく、または、データ要素が１つのパターンから他のパターンへ（例えば、ＸＹＺＷ ＸＹＺＷ ＸＹＺＷ … ＸＹＺＷからＸＸＸＸＸＸＸＸ ＹＹＹＹＹＹＹＹ ＺＺＺＺＺＺＺＺＺＺ ＷＷＷＷＷＷＷＷへ）スウィズルされてもよい。

４０９において、アライメント命令が実行される。この命令の実行により、第１ソースオペランドおよび第２ソースオペランドのデータ要素の連結、および、当該連結されたデータからのこれらのデータ要素のオフセットに基づいた右へのシフトが行われる。いくつかの実施形態において、第１ソースオペランドのデータ要素は、連結されたデータ要素のうち最下位である。４１１において、書き込みマスクレジスタの対応するビットに応じて、シフトされ連結されたデータのいくつかのデータ要素が宛て先ベクトルレジスタに格納されてもよい。４０９と４１１とは別々に示されているが、いくつかの実施形態においてはそれらの動作は、命令の実行の一部として共に実行されてもよい。

１つのタイプの実行環境について説明してきたが、詳述されるインオーダーおよびアウトオブオード環境などの他の環境に適合させることも容易に可能である。

図５は、アライメント命令を処理するための方法の実施形態を示す。本実施形態においては、動作４０１〜４０７のうち全てではないにしてもいくつかが事前に実施されているものと仮定されており、それらの動作は、以下に示す詳細を曖昧にすることを避けるべく示されていない。例えば、フェッチおよびデコードは示されてない。オペランド（ソースおよび書き込みマスク）の読み取りも以下には示されていない。

５０１において、第１ソースおよび第２ソースのデータ要素が連結され、動作を行うためのより大きな「ベクトル」が作成される。例えば、図１および２に示すように、第１ソースのデータ要素が下位のビットとなり、第２ソースのデータ要素が最上位のビットとなるよう、２つのソースレジスタからのデータが連結される。いくつかの実施形態において、このより大きなベクトルは１０２４ビットである。明らかではあるが、より大きなベクトルのサイズは、ソースのサイズに応じて決められる。

５０３において、第１ソースおよび第２ソースの連結されたデータは、命令の即値によって定められるデータ要素の量だけ、右にシフトされる。

５０５において、書き込みマスクを用いるべきかの判断が行われる。この動作は、基盤となるハードウェアアーキテクチャの実装に応じて行われる任意選択的なものである。例えば、上記にて詳述したｋ０のような書き込みマスクレジスタが用いられる場合、用いられるマスクはない。命令に含まれる場合、ｋ０は書き込みが行われ得るレジスタであるが、このことは、マスキングを実施しないことを意味する（言い換えると、全てのビット位置において実質的に「１」の値である）。当然ながら、他のアーキテクチャにおいて、他のレジスタと同様に書き込みマスクを用いることも出来る。

書き込みマスクが用いられる場合、５０７において、書き込みマスクの各ビット位置に関し、第１ソースおよび第２ソースのシフトされ連結されたデータの対応する要素が宛て先レジスタの対応する位置に格納されるべきであるとビット位置が示すかの判断が行われる。いくつかの実施形態において、この判断、および／または後の格納５１１は順番に行われる。つまり、第１ビット位置（つまりｋ１［０］）に関して判断が行われ、その後、続くビット位置の評価が行われる。他の実施形態において、この判断、および／または後の格納５１１は並行して行われる。つまり、全てのビット位置（つまり、ｋ１［０］〜ｋ１［１５］）に関してこの判断が同時に行われる。加えて、評価されるビット位置の数は、データ要素のサイズに応じて異なる。例えば、３２ビットのデータ要素を含む５１２ビットの実装では、この判断において、マスクの１６のビットが評価される。６４ビットのデータ要素を含む５１２ビットの実装において、マスクの８ビットのみが評価される。このインスタンスにおいて、典型的には、最下位の８つのビットが評価されるが、他の方式を用いてもよい。

宛て先レジスタの対応するデータ要素位置に書き込みを行うべきではないことをマスクのあるビット位置が示す場合、５０９において、宛て先レジスタには書き込みが行われない。シフトされ連結されたデータの対応するデータが宛て先レジスタの対応するデータ要素位置に書き込まれるべきであることをマスクのあるビット位置が示す場合、５１１において、当該対応するデータ要素が、宛て先レジスタの対応するデータ要素位置に書き込まれる。この格納の例は図２に示す。マスクが用いられない場合、５１１において、シフトされ連結されたデータの対応するデータ要素のうち全てが、宛て先レジスタの対応するデータ要素位置に格納される。この格納の例は図１に示す。

確認されるマスクの最後のビット位置が評価されると、または書き込みが行われ得る宛て先のデータ要素位置の全ての書き込みが行われると、方法は終了する。

図６は、アライメント命令を処理するための方法の実施形態を示す。本実施形態においては、動作４０１〜４０７のうち全てではないにしてもいくつかが事前に実施されているものと仮定されており、それらの動作は、以下に示す詳細を曖昧にすることを避けるべく示されていない。例えば、フェッチおよびデコードは示されてない。オペランド（ソースおよび書き込みマスク）の読み取りも以下には示されていない。

６０１において、第１ソースおよび第２ソースのデータ要素が連結され、動作を行うためのより大きな「ベクトル」が作成される。例えば、図１および２に示すように、第１ソースのデータ要素が下位のビットとなり、第２ソースのデータ要素が最上位のデータ要素となるよう、２つのソースレジスタからのデータが連結される。いくつかの実施形態において、このより大きなベクトルは１０２４ビットである。明らかではあるが、より大きなベクトルのサイズは、ソースのサイズに応じて決められる。

６０３において、第１ソースおよび第２ソースの連結されたデータは、命令の即値によって定められるデータ要素の量だけ、右にシフトされる。

書き込みマスクを用いるべきかの判断が行われてもよい（図示せず）。上記にて詳述したように、この動作は、基盤となるハードウェアアーキテクチャの実装に応じて行われる任意選択的なものである。マスクが用いられない場合、６０５または６０７においていずれの確認も行われない。

６０５において、書き込みマスクの第１ビット位置に関し、第１ソースおよび第２ソースのシフトされ連結されたデータの対応する要素が宛て先レジスタの対応する位置に格納されるべきであるとビット位置が示すかの判断が行われる。 宛て先レジスタの対応するデータ要素位置に書き込みを行うべきではないことをマスクの第１ビット位置が示す場合、６０９において、宛て先レジスタには書き込みが行われない。シフトされ連結されたデータの対応するデータが宛て先レジスタの対応するデータ要素位置に書き込まれるべきであることをマスクの第１ビット位置が示す場合、６１１において、当該対応するデータが宛て先レジスタの対応するデータ要素位置に書き込まれる。この格納の例は図２に示す。

６１３において、評価された書き込みマスク位置が書き込みマスクの最後であるか、または宛て先のデータ要素位置のうち全てが埋められたかの判断が行われる。もし最後であるか、埋められていれば、動作が終了する。後者のケースは、例えば、データ要素のサイズの６４ビットであり、宛て先が５１２ビットであり、書き込みマスクが１６ビットを有する場合に起こり得る。このインスタンスにおいては、書き込みマスクの８ビットのみが必要となる。

もし最後でないか、埋められてなければ、６１５において、書き込みマスクの次のビット位置が評価されその値の判断が行われる。６０７において、ビット位置が評価され、その他の動作が実行される。 確認されるマスクの最後のビット位置が評価されると、または書き込みが行われ得る宛て先のデータ要素位置の全ての書き込みが行われると、方法は終了する。

図７は、擬似コードでアライメント命令を処理するための方法の実施形態を示す。

典型的にはプログラムは順番にメモリにアクセスする。例えば、参照（ａ）は、アドレス＠に位置する第１の５１２ビットのベクトルでアクセスされ、参照（ｂ）は、＠＋６４バイトに位置する第２の５１２ビットのベクトルでアクセスされ、参照（ｃ）は、＠＋１２８バイトに位置する第１の５１２ビットのベクトルでアクセスされる。このシナリオにおいて、参照（ａ）はキャッシュラインＡ、Ｂを跨いで位置しており、参照（ｂ）は、キャッシュラインＢ、Ｃを跨いで位置しており、参照（ｃ）は、キャッシュラインＣ、Ｄを跨いで位置している。通常のロードを用いると、キャッシュラインＢ、Ｃは２度アクセスされ、キャッシュラインのアクセス数は全体で６（３ｘ２）となる。

一般的には、キャッシュラインのポートはレジスタのポートよりもより貴重なリソースである。上述したアライメント命令の実施形態は、キャッシュラインではなくレジスタに対しデータアライメントを実施するので、当該アライメント命令は性能の向上を実現する。アライメント命令を用いると、キャッシュラインデータはレジスタ内でアライメントされ、典型的には、１つのベクトル参照毎に新たにフェッチされるキャッシュラインは１つのみである。各キャッシュラインは２度アクセスされるのではなく１度のみ読み取られ、キャッシュのアクセスと同時にアライメントされ、スループットは、ただ１つのメモリポートを用いつつもサイクルごとに１つのベクトルとなる。

上記にて詳述した命令の実施形態は、下記に詳述する「汎用のベクトルフレンドリーな命令形式」で実施することも可能である。他の実施形態において、そのような形式は用いられず、他の命令形式が用いられる。しかし、書き込みマスクレジスタ、様々なデータ変換（スウィズル、ブロードキャストなど）、アドレシングなどに関する以下の説明は一般的に、上述した命令の実施形態の説明に関して適用可能である。加えて、例示的なシステム、アーキテクチャ、およびパイプラインについて以下で詳述する。上述した命令の実施形態は、そのようなシステム、アーキテクチャ、およびパイプラインで実行することが出来るが、それら詳述されるものに限定されない。

ベクトルフレンドリーな命令形式は、ベクトル命令に適した命令形式（例えば、ベクトル演算に特定のいくつかのフィールドがある）である。ベクトルフレンドリーな命令形式によってベクトル演算およびスカラ演算の両方がサポートされる実施形態を説明するが、代替的な実施形態においては、ベクトルフレンドリーな命令形式のベクトル演算のみが用いられる。

例示的な汎用のベクトルフレンドリーな命令形式−図８Ａおよび図８Ｂ
図８Ａおよび図８Ｂは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、および、その命令テンプレートを示すブロック図である。図８Ａは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、および、そのクラスＡの命令テンプレートを示すブロック図である。図８Ｂは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、および、そのクラスＢ命令テンプレートを示すブロック図である。詳細には、汎用のベクトルフレンドリーな命令形式８００には、それぞれが非メモリアクセス８０５命令テンプレートおよびメモリアクセス８２０命令テンプレートを含む、クラスＡおよびクラスＢ命令テンプレートが定義されている。ベクトルフレンドリーな命令形式という表現において汎用という用語は、命令形式が何ら特定の命令セットに関連付けられていないことを意味する。ベクトルフレンドリーな命令形式の命令が、レジスタ（非メモリアクセス８０５命令テンプレート）およびレジスタ／メモリ（メモリアクセス８２０命令テンプレート）のうちいずれかをソースとするベクトルに対して動作する実施形態を説明するが、本願発明の代替的な実施形態においては、これらのうちいずれか一方だけをサポートしてもよい。また、ベクトル命令形式のロード命令および格納命令がある本願発明の実施形態を説明するが、代替的な実施形態においては、代わりに、或いは、加えて、レジスタへ、またはレジスタからベクトル（例えば、メモリからレジスタへ、レジスタからメモリへ、レジスタ間で、など）を移動させる異なる命令形式の命令が用いられる。さらに、２つのクラスの命令テンプレートをサポートする本願発明の実施形態を説明するが、代替的な実施形態においては、これらのうち一方のみ、または３つ以上がサポートされる。

ベクトルフレンドリーな命令形式が、３２ビット（４バイト）、または、６４ビット（８バイト）のデータ要素幅（またはサイズ）を有する６４バイトベクトルオペランドの長さ（またはサイズ）（よって、６４バイトのベクトルは、１６倍長語サイズの要素、および８カッド語サイズの要素のいずれかからなる）、１６ビット（２バイト）、または、８ビット（１バイト）のデータ要素幅（またはサイズ）を有する６４バイトベクトルオペランドの長さ（またはサイズ）、３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）、または、８ビット（１バイト）のデータ要素幅（またはサイズ）を有する３２バイトベクトルオペランドの長さ（またはサイズ）、並びに、３２ビット（４バイト）、６４ビット（８バイト）、１６ビット（２バイト）、または、８ビット（１バイト）のデータ要素幅（またはサイズ）を有する１６バイトベクトルオペランドの長さ（またはサイズ）をサポートする実施形態について説明するが、代替的な実施形態においては、より大きな、より小さな、または異なるデータ要素幅（例えば、１２８ビット（１６バイト）データ要素幅）を有するより大きな、より小さな、および／または異なるベクトルオペランドサイズ（例えば８５６バイトのベクトルオペランド）がサポートされてもよい。

図８ＡのクラスＡの命令テンプレートは、１）非メモリアクセス８０５命令テンプレート内に、非メモリアクセス完全丸め制御タイプ演算８１０命令テンプレート、および非メモリアクセスデータ変換タイプ演算８１５命令テンプレート、並びに２）メモリアクセス８２０命令テンプレート内に、メモリアクセス一時的８２５命令テンプレート、およびメモリアクセス非一時的８３０命令テンプレートを含む。図８ＢのクラスＢ命令テンプレートは、１）非メモリアクセス８０５命令テンプレート内に、非メモリアクセス書き込みマスク制御部分的丸め制御タイプ演算８１２命令テンプレート、および非メモリアクセス書き込みマスク制御ｖｓｉｚｅタイプ演算８１７命令テンプレート、並びに、２）メモリアクセス８２０命令テンプレート内に、メモリアクセス書き込みマスク制御８２７命令テンプレートを含む。

形式
汎用のベクトルフレンドリーな命令形式８００は、図８Ａおよび図８Ｂに示される順序で、以下に列挙するフィールドを含む。

形式フィールド８４０−このフィールド内の特定値（命令形式識別値）は一意的に、ベクトルフレンドリーな命令形式を識別し、よって、命令ストリーム内のベクトルフレンドリーな命令形式の命令の発生を識別する。よって、形式フィールド８４０のコンテンツは、第１命令形式の命令の発生を他の命令形式の命令の発生と区別し、これにより、ベクトルフレンドリーな命令形式を他の命令形式の命令セットへ導入することが可能となる。このため、このフィールドは、汎用のベクトルフレンドリーな命令形式のみを有する命令には必要でないので任意的なものである。

ベース動作フィールド８４２−このコンテンツは、複数の異なるベース動作を区別する。本明細書で以下に説明するように、ベース動作フィールド８４２は、オペコードフィールドを含む、および／または、その一部であってもよい。

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

修飾子フィールド８４６−このコンテンツは、メモリアクセスを特定する汎用ベクトル命令形式の命令の発生を、メモリアクセスを特定しない命令形式の命令の発生と区別する。つまり、非メモリアクセス８０５命令テンプレートとメモリアクセス８２０命令テンプレートとを区別する。メモリアクセス動作は、メモリ階層から読み出す、および／または、メモリ階層へ書き込む（場合によっては、レジスタ内の値を用いて、ソース、および／または宛て先アドレスを特定する。他方、メモリアクセス動作はこれらを特定しない（例えば、ソースおよび宛て先がレジスタである）。一実施形態においては、このフィールドはメモリアドレス計算を実行する３つの異なる方法からの選択も行うが、代替的な実施形態においては、メモリアドレス計算を実行するより多くの、より少ない、または複数の異なる方法をサポートする。

オーグメンテーション動作フィールド８５０−このコンテンツは、ベース動作に加えて、様々な複数の異なる動作のうち何れを実行するかを区別する。このフィールドはコンテキスト特有のものである。本願発明の一実施形態において、このフィールドは、クラスフィールド８６８、アルファフィールド８５２、および、ベータフィールド８５４に分けられる。オーグメンテーション動作フィールドは、複数の動作からなる共通のグループを、２、３、または４つの命令ではなく１つの命令で実行することを可能とする。以下に示すのは、必要な命令の数を減らすべくオーグメンテーションフィールド８５０を用いる命令（用いられる用語の意味は、本明細書において以下により詳細に説明する）のいくつかの例である。

ここで、［ｒａｘ］はアドレス生成に用いられるベースポインタであり、｛｝は、データ操作フィールド（本明細書で以下により詳細に説明する）で特定される変換動作を示す。

スケールフィールド８６０−このコンテンツは、メモリアドレスの生成のための（例えば、２スケール＊インデックス＋ベースを用いるアドレス生成のための）インデックスフィールドのコンテンツのスケーリングを可能とする。

変位フィールド８６２Ａ−このコンテンツは、メモリアドレスの生成（例えば、２スケール＊インデックス＋ベース＋変位を用いるアドレス生成）の一部として用いられる。

変位係数フィールド８６２Ｂ（いずれか一方のみが用いられるので、変位フィールド８６２Ａは変位係数フィールド８６２Ｂの直接上に配置されている）−このコンテンツは、アドレス生成の一部として用いられる。このフィールドは、メモリアクセス（Ｎ）のサイズでスケーリングされる変位係数を特定する。ここでＮは、メモリアクセス（例えば、２スケール＊インデックス＋ベース＋スケーリングされた変位を用いるアドレス生成のための）のバイト数である。冗長下位ビットは無視され、よって、有効アドレスを計算するのに用いられる最終的な変位を生成すべく変位係数フィールドのコンテンツがメモリオペランドの合計サイズ（Ｎ）で乗算される。Ｎの値は、本明細書で以下に説明するようにフルオペコードフィールド８７４（本明細書で以下に説明する）およびデータ操作フィールド８５４Ｃに基づいて実行時にプロセッサハードウェアによって求められる。変位フィールド８６２Ａおよび変位係数フィールド８６２Ｂは非メモリアクセス８０５命令テンプレートには用いられない、並びに／或いは、異なる実施形態においては、いずれか一方が用いられる、または両方とも用いられないので、任意的なものである。

データ要素幅フィールド８６４−このコンテンツは、複数のデータ要素幅のうち何れを用いるかを区別する（いくつかの実施形態においては全ての命令に関して。他の実施形態においては、命令のうちいくつかに関して）。１つだけのデータ要素幅がサポートされる場合、および／または、オペコードのいくつかの態様を用いて複数のデータ要素幅がサポートされる場合には必要ではないので、このフィールドは任意的なものである。

書き込みマスクフィールド８７０−このコンテンツは、データ要素の位置毎に、宛て先ベクトルオペランドのデータ要素の位置に、ベース動作およびオーグメンテーション動作の結果を反映させるかどうかを制御する。クラスＡ命令テンプレートはマージング−書き込みマスキングをサポートし、クラスＢ命令テンプレートは、マージング−書き込みマスキング、およびゼロ化−書き込みマスキングの両方をサポートする。マージングの際、ベクトルマスクにより、宛て先の複数の要素からなる何れのセットも、（ベース動作およびオーグメンテーション動作によって特定される）いかなる動作の実行の間であっても、更新から保護をすることが可能となる。他の一実施形態において、対応するマスクのビットが０を有する宛て先の各要素の古い値が維持される。対照的に、ベクトルマスクをゼロ化する際、（ベース動作およびオーグメンテーション動作によって特定される）いかなる動作の実行の間であっても、宛て先の複数の要素からなる何れのセットもゼロにされる。一実施形態において、対応するマスクのビットが０の値を有する宛て先の要素が０に設定される。この機能のサブセットは、実行されている動作のベクトル長さを制御する能力である（つまり、最初から最後までの、修飾されている要素のスパン）。しかし、修飾される要素が連続している必要はない。よって、書き込みマスクフィールド８７０は、ロード、格納、アリズマティック、ロジカルなどを含む部分的なベクトル演算を可能とする。また、このマスキングをフォルトの抑制に用いることも出来る（つまり、フォルトを引き起こし得る／引き起こす何らかの動作の結果の受信を避けるべく宛て先のデータ要素の位置をマスキングすることにより。例えば、メモリのベクトルがページの境界を跨ぎ、２番目のページではなく最初のページがページフォルトを引き起こすことを想定すると、最初のページにあるベクトルの全てのデータ要素が書き込みマスクによりマスキングされた場合、ページフォルトを無視することが出来る）。さらに、書き込みマスクは、特定のタイプの条件ステートメントを含む「ベクトル化ループ」を可能とする。書き込みマスクフィールド８７０のコンテンツが、用いられる書き込みマスクを含む複数の書き込みマスクレジスタのうちの１つを選択する（よって、書き込みマスクフィールド８７０のコンテンツが、実行されるマスキングを間接的に識別する）本願発明の実施形態を説明したが、代替的な実施形態においては、代替的または追加的に、書き込みマスクフィールド８７０のコンテンツが、実行されるマスキングを直接的に特定することを可能とする。さらに、１）レジスタリネームパイプライン段階において宛て先は明示的なソースではないので、宛て先オペランドがソースでもない命令（ノンターナリ命令とも呼ばれる）に対してレジスタリネーミングが用いられる（動作の結果でない何れかデータ要素（何れのマスキングされたデータ要素）もゼロにされるので、現在の宛て先レジスタからのデータ要素の何れもリネームされた宛て先レジスタにコピーされる必要がなく、或いは、何らかの方法で動作を実行される必要がない）場合、および、２）ゼロが書き込まれているので、書き戻し段階の間、ゼロ化により性能の向上が可能となる。

即値フィールド８７２−このコンテンツは即値の特定を可能とする。即値をサポートしない汎用のベクトルフレンドリーな形式の実施では存在せず、即値を用いない命令では存在しないので、このフィールドは任意的なものである。

命令テンプレートクラス選択
クラスフィールド８６８−このコンテンツは複数の異なるクラスの命令を区別する。図２を参照すると、このフィールドのコンテンツは、クラスＡの命令およびクラスＢの命令のうちから選択する。図８Ａおよび図８Ｂにおいて、角が丸められた正方形は、特定値がフィールド内に存在することを示すのに用いられている（例えば、図８ＡのクラスＡ８６８Ａ、および図８ＢのクラスＢ８６８Ｂ）。

クラスＡの非メモリアクセス命令テンプレート
クラスＡの非メモリアクセス８０５命令テンプレートの場合、アルファフィールド８５２は、含まれるコンテンツが複数の異なるオーグメンテーション動作タイプのうち何れが実行されるかを区別する（例えば、丸め８５２Ａ．１およびデータ変換８５２Ａ．２がそれぞれ、非メモリアクセス丸めタイプ演算８１０および非メモリアクセスデータ変換タイプ演算８１５命令テンプレートに関して特定される）ＲＳフィールド８５２Ａとして解釈され、ベータフィールド８５４は、特定されたタイプの動作のうち何れが実行されるかを区別する。図８Ａおよび図８Ｂにおいて、角が丸められたブロックは、特定値が存在することを示すのに用いられている（例えば、修飾子フィールド８４６の非メモリアクセス８４６Ａ、アルファフィールド８５２／ＲＳフィールド８５２Ａの丸め８５２Ａ．１およびデータ変換８５２Ａ．２）。非メモリアクセス８０５命令テンプレートにおいて、スケールフィールド８６０、変位フィールド８６２Ａ、および変位スケールフィールド８６２Ｂは存在しない。

非メモリアクセス命令テンプレート−完全丸め制御タイプ演算
非メモリアクセス完全丸め制御タイプ演算８１０命令テンプレートにおいて、ベータフィールド８５４は、含まれるコンテンツが静的な丸めを提供する丸め制御フィールド８５４Ａとして解釈される。本願発明の説明される実施形態においては、丸め制御フィールド８５４Ａは全浮動小数点例外抑制（ＳＡＥ）フィールド８５６、および、丸め演算制御フィールド８５８を含むが、代替的な実施形態においては、これらのコンセプトの両方を同じフィールドにエンコードする、または、これらのコンセプト／フィールドのうち一方、または他方のみを有する（例えば、丸め演算制御フィールド８５８のみを有する）。

ＳＡＥフィールド８５６−このコンテンツは、例外イベント報告を無効化するかどうかを区別する。抑制が有効であることをＳＡＥフィールド８５６のコンテンツが示す場合、任意の命令はあらゆるタイプの浮動小数点例外フラグを報告せず、浮動小数点例外ハンドラを立ち上げない。

丸め演算制御フィールド８５８−このコンテンツは、複数の丸め演算（例えば、端数切り上げ、端数切り捨て、ゼロに丸め、および最も近い値に丸め）からなるグループのうち何れを実行するかを区別する。よって、丸め演算制御フィールド８５８は、命令毎に丸めモードを変更することを可能とし、よって、このようなことが必要である場合に特に有用である。丸めモードを特定するための制御レジスタをプロセッサが含む本願発明の一実施形態において、丸め演算制御フィールド８５０のコンテンツは、レジスタ値よりも優位である（そのような制御レジスタに対し格納−変更−復元を実行する必要なく丸めモードを選択出来るということは有利である）。

非メモリアクセス命令テンプレート−データ変換タイプ演算
非メモリアクセスデータ変換タイプ演算８１５命令テンプレートにおいて、ベータフィールド８５４は、複数のデータ変換（例えば、データ変換、スウィズル、ブロードキャスト）のうち何れが実行されるかを含まれるコンテンツが区別するデータ変換フィールド８５４Ｂとして解釈される。

クラスＡのメモリアクセス命令テンプレート
クラスＡのメモリアクセス８２０命令テンプレートの場合、アルファフィールド８５２は、含まれるコンテンツが削除ヒントのうちいずれが用いられるかを区別する（図８Ａにおいて、一時的８５２Ｂ．１および非一時的８５２Ｂ．２がそれぞれ、メモリアクセス一時的８２５命令テンプレートおよびメモリアクセス非一時的８３０命令テンプレートに関して特定される）削除ヒントフィールド８５２Ｂとして解釈され、ベータフィールド８５４は、含まれるコンテンツが複数のデータ操作動作（プリミティブとしても知られる）のうちいずれが実行されるか（例えば、操作なし、ブロードキャスト、ソースのアップコンバート、および宛て先のダウンコンバート）を区別するデータ操作フィールド８５４Ｃとして解釈される。メモリアクセス８２０命令テンプレートは、スケールフィールド８６０を含み、場合によっては、変位フィールド８６２Ａまたは変位スケールフィールド８６２Ｂを含む。

ベクトルメモリ命令は、変換のサポートと共に、メモリからのベクトルロード、およびメモリへのベクトル格納を実行する。通常のベクトル命令と同様に、ベクトルメモリ命令は、データ要素毎に、書き込みマスクとして選択されたベクトルマスクのコンテンツによって指示されて実際に転送される要素と共に、メモリから、またはメモリへデータを転送する。図８Ａにおいて、角が丸められた正方形は、フィールド内に特定値が存在することを示すのに用いられている（例えば、修飾子フィールド８４６のメモリアクセス８４６Ｂ、アルファフィールド８５２／削除ヒントフィールド８５２Ｂの一時的８５２Ｂ．１、および非一時的８５２Ｂ．２）。

メモリアクセス命令テンプレート−一時的
一時的データは、キャッシュするのが有利である程度に直ぐに再度用いられる可能性が高いデータである。しかし、これはヒントであり、複数の異なるプロセッサが、ヒントを全く無視するなど複数の異なるやり方で実行し得る。

メモリアクセス命令テンプレート−非一時的
非一時的データは、第１レベルキャッシュでキャッシュするのが有利ではない程度に直ぐには再度用いられる可能性が低く、削除に関して高い優先度を与えられるべきデータである。しかし、これはヒントであり、複数の異なるプロセッサが、ヒントを全く無視するなど複数の異なるやり方で実行し得る。

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

クラスＢの非メモリアクセス命令テンプレート
クラスＢの非メモリアクセス８０５命令テンプレートの場合、ベータフィールド８５４の一部は、含まれるコンテンツが複数の異なるオーグメンテーション動作タイプのうちいずれが実行されるのかを区別する（例えば、丸め８５７Ａ．１およびベクトル長さ（ＶＳＩＺＥ）８５７Ａ．２がそれぞれ、非メモリアクセス書き込みマスク制御部分的丸め制御タイプ演算８１２命令テンプレート、および非メモリアクセス書き込みマスク制御ＶＳＩＺＥタイプ演算８１７命令テンプレートに関して特定される）ＲＬフィールド８５７Ａとして解釈され、ベータフィールド８５４の残りは、特定されたタイプの動作のうちいずれが実行されるのかを区別する。図８Ａおよび８Ｂにおいて、角が丸められたブロックは、特定値（例えば、修飾子フィールド８４６の非メモリアクセス８４６Ａ、ＲＬフィールド８５７Ａの丸め８５７Ａ．１およびＶＳＩＺＥ８５７Ａ．２）が存在することを示すのに用いられている。非メモリアクセス８０５命令テンプレートにおいて、スケールフィールド８６０、変位フィールド８６２Ａ、および、変位スケールフィールド８６２Ｂは存在しない。

非メモリアクセス命令テンプレート−書き込みマスク制御部分的丸め制御タイプ演算
非メモリアクセス書き込みマスク制御部分的丸め制御タイプ演算８１０命令テンプレートにおいて、ベータフィールド８５４の残りは、丸め演算フィールド８５９Ａとして解釈され、例外イベント報告が無効化される（任意の命令はあらゆるタイプの浮動小数点例外フラグを報告せず、浮動小数点例外ハンドラを立ち上げない）。

丸め演算制御フィールド８５９Ａ−丸め演算制御フィールド８５８とちょうど同じようにこのコンテンツは、複数の丸め演算（例えば、端数切り上げ、端数切り捨て、ゼロに丸め、および最も近い値に丸め）からなるグループのうち何れを実行するかを区別する。よって、丸め演算制御フィールド８５９Ａは、命令毎に丸めモードを変更することを可能とし、よって、このようなことが必要である場合に特に有用である。丸めモードを特定するための制御レジスタをプロセッサが含む本願発明の一実施形態において、丸め演算制御フィールド８５０のコンテンツは、レジスタ値よりも優位である（そのような制御レジスタに対し格納−変更−復元を実行する必要なく丸めモードを選択出来るということは有利である）。

非メモリアクセス命令テンプレート−書き込みマスク制御ＶＳＩＺＥタイプ演算
非メモリアクセス書き込みマスク制御ＶＳＩＺＥタイプ演算８１７命令テンプレートにおいて、ベータフィールド８５４の残りは、複数のデータベクトル長さ（例えば、１２８、８５６、または１０１２バイト）のうち何れで実行されるかを含まれるコンテンツが区別するベクトル長さフィールド８５９Ｂとして解釈される。

クラスＢのメモリアクセス命令テンプレート
クラスＡのメモリアクセス８２０命令テンプレートの場合、ベータフィールド８５４の一部は、ブロードキャストタイプデータ操作が実行されるかどうかを含まれるコンテンツが区別するブロードキャストフィールド８５７Ｂとして解釈され、ベータフィールド８５４の残りは、ベクトル長さフィールド８５９Ｂとして解釈される。メモリアクセス８２０命令テンプレートは、スケールフィールド８６０を含み、場合によっては、変位フィールド８６２Ａまたは変位スケールフィールド８６２Ｂを含む。

フィールドについての追加の説明
汎用のベクトルフレンドリーな命令形式８００に関し、フルオペコードフィールド８７４は、形式フィールド８４０、ベース動作フィールド８４２、およびデータ要素幅フィールド８６４を含むものとして示した。フルオペコードフィールド８７４がこれらのフィールド全てを含む一実施形態を示したが、これらのフィールド全てをサポートしない実施形態においては、フルオペコードフィールド８７４はこれらのフィールドの全ては含まない。フルオペコードフィールド８７４は演算コードを提供する。

オーグメンテーション動作フィールド８５０、データ要素幅フィールド８６４、および書き込みマスクフィールド８７０は、汎用のベクトルフレンドリーな命令形式で、命令毎にこれらの特徴全てを特定することを可能とする。

書き込マスクフィールドおよびデータ要素幅フィールドを組み合わせると、複数の異なるデータ要素幅に基づいたマスクの適用を可能とするタイプ化された命令が生成される。

当該命令形式は、他のフィールドのコンテンツに基づいて異なる目的のために異なるフィールドを再利用するので、必要なビット数が比較的少なくて済む。例えば、一つの見方としては、修飾子フィールドのコンテンツが、図８Ａおよび図８Ｂの非メモリアクセス８０５命令テンプレートと、図８Ａおよび図８Ｂのメモリアクセス８２５０命令テンプレートとの間で選択と行い、クラスフィールド８６８のコンテンツが、それら非メモリアクセス８０５命令テンプレートのうち、図８Ａの命令テンプレート８１０／８１５、および、図８Ｂの命令テンプレート８１２／８１７から選択を行い、クラスフィールド８６８のコンテンツが、それらメモリアクセス８２０命令テンプレートのうち、図８Ａの命令テンプレート８２５／８３０、および、図８Ｂの命令テンプレート８２７から選択を行う。他の見方では、クラスフィールド８６８のコンテンツが、図８Ａおよび図８ＢのうちそれぞれのクラスＡおよびクラスＢ命令テンプレートから選択を行い、修飾子フィールドのコンテンツが、それらクラスＡの命令テンプレートのうち、図８Ａの命令テンプレート８０５、８２０から選択を行い、修飾子フィールドのコンテンツが、それらクラスＢ命令テンプレートのうち、図８Ｂの命令テンプレート８０５、８２０から選択を行う。クラスフィールドのコンテンツがクラスＡの命令テンプレートを示す場合、修飾子フィールド８４６のコンテンツが、アルファフィールド８５２（ＲＳフィールド８５２ＡおよびＥＨフィールド８５２Ｂ）の解釈を選択する。同様に、修飾子フィールド８４６およびクラスフィールド８６８のコンテンツが、アルファフィールドがＲＳフィールド８５２Ａ、ＥＨフィールド８５２Ｂ、または書き込みマスク制御（Ｚ）フィールド８５２Ｃとして解釈されるかの選択を行う。クラスフィールドおよび修飾子フィールドがクラスＡのメモリアクセス動作を示す場合、オーグメンテーションフィールドのベータフィールドの解釈は、ＲＳフィールドのコンテンツに基づいて変化し、クラスフィールドおよび修飾子フィールドがクラスＢの非メモリアクセス動作を示す場合には、ベータフィールドの解釈は、ＲＬフィールドのコンテンツに依存する。クラスフィールドおよび修飾子フィールドがクラスＡのメモリアクセス動作を示す場合には、オーグメンテーションフィールドのベータフィールドの解釈は、ベース動作フィールドのコンテンツに基づいて変化し、クラスフィールドおよび修飾子フィールドがクラスＢのメモリアクセス動作を示す場合には、オーグメンテーションフィールドのベータフィールドのブロードキャストフィールド８５７Ｂの解釈は、ベース動作フィールドのコンテンツに基づいて変化する。よって、ベース動作フィールド、修飾子フィールド、および、オーグメンテーション動作フィールドの組み合わせにより、さらに幅広いタイプのオーグメンテーション動作を特定することが可能となる。

複数の異なる状況において、クラスＡおよびクラスＢに関し様々な命令テンプレートを用いるのが有益である。クラスＡは、性能上の理由によりゼロ化−書き込みマスキング、または、より短いベクトル長さが所望される場合に有用である。例えば、ゼロ化により、人工的に宛て先とマージングを行う必要がなくリネームが用いられる場合に偽の依存性を避けることが可能となる。他の例として、ベクトル長さの制御は、ベクトルマスクを用いてより短いベクトルサイズをエミュレートする際に格納−ロード転送に関する課題を緩和する。クラスＢは、１）浮動小数点の例外を可能とし（つまり、ＳＡＥフィールドのコンテンツがＮｏを示す）、同時に丸めモード制御を用いる、２）アップコンバート、スウィズル、スワップ、および／または、ダウンコンバートを用いることが出来る、並びに、３）グラフィックデータタイプで動作することが所望される場合に有用である。例えば、アップコンバート、スウィズル、スワップ、ダウンコンバート、およびグラフィックデータタイプは、異なる形式のソースを処理する際に必要となる命令の数を減らす。他の例としては、例外を可能とする性能により、指示される丸めモードでＩＥＥＥの規格に完全に準拠することが可能となる。

例示的な特定のベクトルフレンドリーな命令形式
図９Ａ、図９Ｂ、および図９Ｃは、本願発明の実施形態に係る例示的な特定のベクトルフレンドリーな命令形式を示すブロック図である。図９Ａ、図９Ｂ、および図９Ｃは、フィールドの場所、サイズ、解釈、および順序、並びに、これらのフィールドのうちいくつかの値を特定するという意味で特定的である、特定のベクトルフレンドリーな命令形式９００を示す。特定のベクトルフレンドリーな命令形式９００を用いて、ｘ８６命令の拡張を行ってもよく、よって、フィールのうちいくつかは、既存のｘ８６命令のセット、およびその拡張（例えばＡＶＸ）に用いられるものと同様、または同じである。この形式は、拡張された既存のｘ８６命令のセットのプレフィックスエンコードフィールド、リアルオペコードバイトフィールド、ＭＯＤ Ｒ／Ｍフィールド、ＳＩＢフィールド、変位フィールド、および、即値フィールドに対応したままである。図９Ａ、図９Ｂ、および図９Ｃからのフィールドがマッピングされる図８Ａおよび図８Ｂのフィールドが示されている。

なお、本願発明の実施形態は、例示を目的とし、汎用のベクトルフレンドリーな命令形式８００の文脈で特定のベクトルフレンドリーな命令形式９００に関して説明するが、本願発明は、特に記される場合を除き、特定のベクトルフレンドリーな命令形式９００に限定されない。例えば、特定のベクトルフレンドリーな命令形式９００は特定のサイズのフィールドを有するものとして示されているが、汎用のベクトルフレンドリーな命令形式８００に関しては様々なフィールドが様々なサイズを有し得る。特定の例として、データ要素幅フィールド８６４は特定のベクトルフレンドリーな命令形式９００において１ビットのフィールドとして示されているが、本願発明はそのように限定されない（つまり、汎用のベクトルフレンドリーな命令形式８００のデータ要素幅フィールド８６４は他のサイズを有し得る）。

形式−図９Ａ、図９Ｂ、および図９Ｃ
汎用のベクトルフレンドリーな命令形式８００は、図９Ａ、図９Ｂ、および図９Ｃで示される順序で以下に列挙するフィールドを含む。

ＥＶＥＸ Ｐｒｅｆｉｘ（Ｂｙｔｅｓ ０−３）ＥＶＥＸ Ｐｒｅｆｉｘ９０２−４バイト形式でエンコードされている。

形式フィールド８４０（ＥＶＥＸ Ｂｙｔｅ０，ｂｉｔｓ［７：０］）−第１バイト（ＥＶＥＸ Ｂｙｔｅ ０）は、形式フィールド８４０であり、０ｘ６２（本願発明の一実施形態において、ベクトルフレンドリーな命令形式を区別するのに用いられる一意の値）を含む。

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

ＲＥＸフィールド９０５（ＥＶＥＸ Ｂｙｔｅ １，ｂｉｔｓ［７−５］）−ＥＶＥＸ．Ｒ ｂｉｔ ｆｉｅｌｄ（ＥＶＥＸ Ｂｙｔｅ １，ｂｉｔ［７］−Ｒ），ＥＶＥＸ．Ｘ ｂｉｔ ｆｉｅｌｄ（ＥＶＥＸ ｂｙｔｅ１，ｂｉｔ［６］−Ｘ）、および８５７ＢＥＸ ｂｙｔｅ １，ｂｉｔ［５］−Ｂ）からなる。ＥＶＥＸ．Ｒ，ＥＶＥＸ．ＸおよびＥＶＥＸ．Ｂビットフィールドは、対応するＶＥＸビットフィールドと同様の機能を提供し、１の補数形式を用いてエンコードされる。つまり、ＺＭＭ０は、１１１１Ｂとしてエンコードされ、ＺＭＭ１５は、００００Ｂとしてエンコードされる。当分野で公知のように命令の他のフィールドは、レジスタインデックスの下位３ビット（ｒｒｒ、ｘｘｘ、およびｂｂｂ）をエンコードするので、ＥＶＥＸ．Ｒ、ＥＶＥＸ．Ｘ、およびＥＶＥＸ．Ｂを加えることにより、Ｒｒｒｒ、Ｘｘｘｘ、およびＢｂｂｂが形成され得る。

ＲＥＸ'フィールド９１０−このフィールドは、ＲＥＸ'フィールド９１０の最初の部分であり、拡張された３２レジスタセットの上位１６および下位１６のうちいずれかをエンコードするのに用いられるＥＶＥＸ．Ｒ'ビットフィールド（ＥＶＥＸ Ｂｙｔｅ １，ｂｉｔ［４］−Ｒ'）である。本願発明の一実施形態において、以下に示す他のビットと共にこのビットは、リアルオペコードバイトが６２であるＢＯＵＮＤ命令と（周知のｘ８６ ３２ビットモードで）区別すべくビット反転形式で格納されるが、ＭＯＤフィールドの１１の値をＭＯＤ Ｒ／Ｍフィールド（以下に説明する）で受け入れない。代替的な実施形態においては、このビット、および以下に示された他のビットは反転形式で格納されない。１の値を用いて下位１６のレジスタをエンコードする。言い換えると、ＥＶＥＸ．Ｒ'、ＥＶＥＸ．Ｒ、および他のフィールドからの他のＲＲＲを組み合わせて、Ｒ'Ｒｒｒｒが形成される。

オペコードマップフィールド９１５（ＥＶＥＸ ｂｙｔｅ １，ｂｉｔｓ［３：０］−ｍｍｍｍ）−このコンテンツは、示唆された先頭のオペコードバイト（０Ｆ、０Ｆ ３８、または、０Ｆ ３）をエンコードする。

データ要素幅フィールド８６４（ＥＶＥＸ ｂｙｔｅ ２，ｂｉｔ［７］−Ｗ）−ＥＶＥＸ．Ｗと表記される。ＥＶＥＸ．Ｗは、データタイプの粒度（サイズ）を定義するのに用いられる（３２ビットのデータ要素、または６４ビットのデータ要素）。

ＥＶＥＸ．ｖｖｖｖ９２０（ＥＶＥＸ Ｂｙｔｅ ２，ｂｉｔｓ［６：３］−ｖｖｖｖ）−ＥＶＥＸ．ｖｖｖｖの役割には、以下のものが含まれ得る。１）ＥＶＥＸ．ｖｖｖｖは、反転された（１の補数）形式で特定される第１ソースレジスタオペランドをエンコードし、２以上のソースオペランドの命令に有効である、２）ＥＶＥＸ．ｖｖｖｖは、特定のベクトルシフトに関し、１の補数形式で特定される宛て先レジスタオペランドをエンコードする、３）ＥＶＥＸ．ｖｖｖｖは、何れのオペランドもエンコードせず、当該フィールドは残しておかれ、１１１１ｂを含む。よって、ＥＶＥＸ．ｖｖｖｖフィールド９２０は、反転された（１の補数）形式で格納される第１ソースレジスタ指定子の４つの下位ビットをエンコードする。命令に応じて、追加の異なるＥＶＥＸビットフィールドが、指定子のサイズを３２レジスタに拡張するのに用いられる。

ＥＶＥＸ．Ｕ８６８クラスフィールド（ＥＶＥＸ ｂｙｔｅ ２，ｂｉｔ［２］−Ｕ）−ＥＶＥＸ．Ｕ＝０の場合、クラスＡ、またはＥＶＥＸ．Ｕ０を示し、ＥＶＥＸ．Ｕ＝１の場合、クラスＢ、またはＥＶＥＸ．Ｕ１を示す。

プレフィックスエンコードフィールド９２５（ＥＶＥＸ ｂｙｔｅ ２，ｂｉｔｓ［１：０］−ｐｐ）−ベース動作フィールドに追加のビットを提供する。ＥＶＥＸプレフィックス形式のレガシーＳＳＥ命令のサポートを提供するのに加え、このフィールドは、ＳＩＭＤプレフィックスをコンパクト化するのに有用である（ＳＩＭＤプレフィックスを表現するのに１バイトを必要とせず、ＥＶＥＸ Ｐｒｅｆｉｘは２ビットのみ必要とする）。一実施形態において、レガシー形式、およびＥＶＥＸプレフィックス形式の両方のＳＩＭＤプレフィックス（６６Ｈ、Ｆ２Ｈ、Ｆ３Ｈ）を用いるレガシーＳＳＥ命令をサポートするべく、これらのレガシーＳＩＭＤプレフィックスは、ＳＩＭＤプレフィックスエンコードフィールドにエンコードされ、実行時には、デコーダのＰＬＡに提供される前に、レガシーＳＩＭＤプレフィックスに拡張される（つまり、ＰＬＡは修正を加えることなくこれらのレガシー命令のレガシー形式およびＥＶＥＸ形式を実行することが出来る）。より新しい命令はＥＶＥＸプレフィックスエンコードフィールドのコンテンツを直接的にオペコード拡張として用いることが出来るが、特定の実施形態においては、一貫性を保つべく同様のやり方で拡張が行われるが、これらのレガシーＳＩＭＤプレフィックスによる異なる意味の特定を可能とする。代替的な実施形態において、２ビットのＳＩＭＤプレフィックスエンコードをサポートするようＰＬＡを再設計し、よって、拡張が必要とされない。

アルファフィールド８５２（ＥＶＥＸ ｂｙｔｅ ３，ｂｉｔ［７］−ＥＨ。ＥＶＥＸ．ＥＨ、ＥＶＥＸ．ｒｓ、ＥＶＥＸ．ＲＬ、ＥＶＥＸ．ｗｒｉｔｅ ｍａｓｋ ｃｏｎｔｒｏｌおよびＥＶＥＸ．Ｎとしても知られる。αを用いても示される−上述したように、このフィールドはコンテンツ固有のものである。追加の説明は本明細書において以下に示す。

ベータフィールド８５４（ＥＶＥＸ ｂｙｔｅ ３，ｂｉｔｓ［６：４］−ＳＳＳ。ＥＶＥＸ．ｓ２−０、ＥＶＥＸ．ｒ２−０、ＥＶＥＸ．ｒｒ１、ＥＶＥＸ．ＬＬ０、ＥＶＥＸ．ＬＬＢとしても知られる。βを用いても示される）−上述したように、このフィールドはコンテンツ固有のものである。追加の説明は本明細書において以下に示す。

ＲＥＸ'フィールド９１０−このフィールドはＲＥＸ'フィールドの残りであり、拡張された３２レジスタセットの上位１６および下位１６のうちいずれかをエンコードするのに用いられ得るＥＶＥＸ．Ｖ'ビットフィールド（ＥＶＥＸ Ｂｙｔｅ ３，ｂｉｔ［３］−Ｖ'）である。このビットはビット反転形式で格納される。下位１６のレジスタをエンコードするのに１の値が用いられる。言い換えると、ＥＶＥＸ．Ｖ'とＥＶＥＸ．ｖｖｖｖとを組み合わせてＶ'ＶＶＶＶが形成される。

書き込みマスクフィールド８７０（ＥＶＥＸ ｂｙｔｅ ３，ｂｉｔｓ［２：０］−ｋｋｋ）−このコンテンツは、上述したように書き込みマスクレジスタのレジスタのインデックスを特定する。本願発明の一実施形態において、特定値ＥＶＥＸ．ｋｋｋ＝０００は特定の命令に対し書き込みマスクが用いられないことを示唆する特別な挙動を示す（このことは、全ての１にハードワイヤされた、またはマスキングハードウェアをバイパスするハードウェアにハードワイヤされた書き込みマスクを用いることを含む様々なやり方で実装することが出来る）。

リアルオペコードフィールド９３０（Ｂｙｔｅ ４）このフィールドは、オペコードバイトとしても知られる。オペコードの一部はこのフィールドで特定される。

ＭＯＤ Ｒ／Ｍフィールド９４０（Ｂｙｔｅ ５）修飾子フィールド８４６（ＭＯＤＲ／Ｍ．ＭＯＤ，ｂｉｔｓ［７−６］−ＭＯＤフィールド９４２）−上述したように、ＭＯＤフィールド９４２のコンテンツは、メモリアクセス動作と非メモリアクセス動作とを区別する。このフィールドは本明細書において以下にさらに説明する。

ＭＯＤＲ／Ｍ．ｒｅｇフィールド９４４，ｂｉｔｓ［５−３］−ＭｏｄＲ／Ｍ．ｒｅｇフィールドの役割は、２つの状況に要約することが出来る。ＭｏｄＲ／Ｍ．ｒｅｇが、宛て先レジスタオペランド、およびソースレジスタオペランドのうちいずれかをエンコードする。または、ＭｏｄＲ／Ｍ．ｒｅｇが、オペコード拡張として扱われ、いずれの命令オペランドをエンコードするのにも用いられない。

ＭＯＤＲ／Ｍ．ｒ／ｍフィールド９４６，ｂｉｔｓ［２−０］−ＭｏｄＲ／Ｍ．ｒ／ｍフィールドの役割には以下のものが含まれ得る。ＭｏｄＲ／Ｍ．ｒ／ｍが、メモリアドレスを参照する命令オペランドをエンコードする。または、ＭｏｄＲ／Ｍ．ｒ／ｍが、宛て先レジスタオペランド、およびソースレジスタオペランドのいずれかをエンコードする。

スケール、インデックス、ベース（ＳＩＢ）バイト（Ｂｙｔｅ ６）スケールフィールド８６０（ＳＩＢ．ＳＳ，ｂｉｔｓ［７−６］−上述したように、スケールフィールド８６０のコンテンツは、メモリアドレスの生成に用いられる。このフィールドは本明細書において以下にさらに説明する。

ＳＩＢ．ｘｘｘ９５４（ｂｉｔｓ［５−３］）、および、ＳＩＢ．ｂｂｂ９５６（ｂｉｔｓ［２−０］）−これらのフィールドのコンテンツは、レジスタインデックスＸｘｘｘおよびＢｂｂｂに関連して上記にて参照した。

変位バイト（Ｂｙｔｅ ７、または、Ｂｙｔｅｓ ７−１０）変位フィールド８６２Ａ（Ｂｙｔｅｓ ７−１０）−ＭＯＤフィールド９４２が１０を含む場合、バイト７−１０は変位フィールド８６２Ａであり、レガシー３２ビットの変位（ｄｉｓｐ３２）と同じく動作し、バイト粒度で動作する。

変位係数フィールド８６２Ｂ（Ｂｙｔｅ ７）−ＭＯＤフィールド９４２が０１を含む場合、バイト７は変位係数フィールド８６２Ｂである。このフィールドの場所は、バイト粒度で動作するレガシーｘ８６命令セットの８ビット変位（ｄｉｓｐ８）の場所と同じである。ｄｉｓｐ８は符号が拡張されているので、−１２８〜１２７バイトのオフセットのみに対応出来る。６４バイトのキャッシュに関しては、ｄｉｓｐ８は、−１２８、−６４、０、および６４の４つの実際に有用な値にのみ設定され得る８ビットを用いる。さらに大きな範囲が必要とされることが多いので、ｄｉｓｐ３２が用いられる。しかし、ｄｉｓｐ３２は４バイトを必要とする。ｄｉｓｐ８およびｄｉｓｐ３２と対照的に、変位係数フィールド８６２Ｂはｄｉｓｐ８の再解釈である。変位係数フィールド８６２Ｂを用いる場合、実際の変位は、変位係数フィールドのコンテンツにメモリオペランドアクセスのサイズ（Ｎ）を乗算して求められる。このタイプの変位は、ｄｉｓｐ８＊Ｎと示される。これにより、平均の命令長さが短くなる（変位に関して用いられるよりも１つのバイトがより大きな範囲に対して用いられる）。そのような圧縮された変位は、有効な変位はメモリアクセスの粒度の倍数であり、よって、アドレスオフセットの冗長下位ビットは、エンコードされる必要がないという仮定に基づいている。言い換えると、変位係数フィールド８６２Ｂはレガシーｘ８６命令セットの８ビット変位に置き換わる。よって、変位係数フィールド８６２Ｂは、ｘ８６命令セットの８ビット変位と同じやり方でエンコードされ（つまり、ＭｏｄＲＭ／ＳＩＢのエンコードルールには変更がない）、ｄｉｓｐ８がｄｉｓｐ８＊Ｎにオーバーロードされる（ｏｖｅｒｌｏａｄｅｄ）点だけが異なる。言い換えると、エンコードルールまたはエンコード長さには変化がないが、（バイトごとのアドレスオフセットを得るには、メモリオペランドのサイズで変位をスケーリングする必要がある）ハードウェアによる変位値の解釈にのみ変化がある。

即値
即値フィールド８７２は上述したように動作する。

例示的なレジスタアーキテクチャ−図１０
図１０は、本願発明の一実施形態に係るレジスタアーキテクチャ１０００のブロック図である。レジスタアーキテクチャのレジスタファイルおよびレジスタを以下に列挙する。

ベクトルレジスタファイル１０１０ 示される実施形態において、１０１２ビットの幅を有する３２個のベクトルレジスタがある。これらのレジスタをｚｍｍ０〜ｚｍｍ３１と呼ぶ。最初の１６個のレジスタの下位８５６ビットは、レジスタｙｍｍ０〜１６にオーバーレイされて（ｏｖｅｒｌａｉｄ）いる。最初の１６ｚｍｍレジスタの下位１２８ビット（ｙｍｍレジスタの下位１２８ビット）は、レジスタｘｍｍ０〜１５にオーバーレイされている。特定のベクトルフレンドリーな命令形式９００は以下の表に示すようにこれらオーバーレイされたレジスタファイルに対して動作する。

言い換えると、ベクトル長さフィールド８５９Ｂは、最大長さおよび１以上の他のより短い長さのうちから選択を行う。ここでそのようなより短い長さのそれぞれは先行する長さの半分である。ベクトル長さフィールド８５９Ｂを有さない命令テンプレートは、最大ベクトル長さで動作する。さらに、一実施形態において、特定のベクトルフレンドリーな命令形式９００のクラスＢ命令テンプレートは、パックされた、またはスカラの単／倍精度浮動小数点データ、およびパックされた、またはスカラの整数データに対し動作する。スカラ演算は、ｚｍｍ／ｙｍｍ／ｘｍｍレジスタの下位のデータ要素の位置に対して行われる演算である。上位のデータ要素の位置は命令の前の位置と同じままである、または実施形態によってはゼロにされる。

書き込みマスクレジスタ１０１５−示される実施形態において、それぞれサイズが６４ビットである８個の書き込みマスクレジスタ（ｋ０〜ｋ７）がある。上述したように、本願発明の一実施形態において、ベクトルマスクレジスタｋ０は書き込みマスクとして用いることが出来ない。エンコードの際には、このフィールドは通常ｋ０が書き込みマスクに用いられることを示し、０ｘＦＦＦＦのハードワイヤされた書き込みマスクを選択し、効果的に当該命令の書き込みマスクを無効化する。

マルチメディア拡張制御ステータスレジスタ（ＭＸＣＳＲ）１０２０−示される実施形態において、この３２ビットのレジスタは浮動小数点演算に用いられるステータスおよび制御ビットを提供する。

汎用レジスタ１０２５−示される実施形態において、メモリオペランドに対応する既存のｘ８６アドレシングモードと用いられる１６個の６４ビット汎用レジスタがある。これらのレジスタはＲＡＸ、ＲＢＸ、ＲＣＸ、ＲＤＸ、ＲＢＰ、ＲＳＩ、ＲＤＩ、ＲＳＰ、および、Ｒ８〜Ｒ１５で示される。

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

浮動小数点制御ワード（ＦＣＷ）レジスタ１０３５、および、浮動小数点ステータスワード（ＦＳＷ）レジスタ１０４０−示される実施形態において、これらのレジスタは、ＦＣＷの場合に丸めモード、例外マスク、およびフラグを設定し、ＦＳＷの場合に例外の記録をつけるべく、ｘ８７命令セット拡張によって用いられる。

ＭＭＸパックド整数フラットレジスタファイル１０５０がエイリアスされるスカラ浮動小数点スタックレジスタファイル（ｘ８７スタック）１０４５−示される実施形態において、ｘ８７スタックは、ｘ８７命令セット拡張を用いる３２／６４／８０ビット浮動小数点データに対するスカラ浮動小数点演算を実行するのに用いられる８個の要素のスタックであり、ＭＭＸレジスタは、６４ビットのパックされた整数データに対する演算を実行し、ＭＭＸレジスタとＸＭＭレジスタとの間で実行されるいくつかの演算のオペランドを保持するのに用いられる。

セグメントレジスタ１０５５−示される実施形態において、セグメント化されたアドレス生成に用いられるデータを格納するのに用いられる６個の１６ビットのレジスタがある。

ＲＩＰレジスタ１０６５−示される実施形態において、この６４ビットのレジスタは、命令ポインタを格納する。

本願発明の代替的な実施形態においては、より広い、またはより狭いレジスタが用いられる。加えて、本願発明の代替的な実施形態においては、より多くの、より少ない、または異なるレジスタファイルおよびレジスタが用いられる。

例示的なインオーダープロセッサアーキテクチャ−図１１Ａおよび図１１Ｂ
図１１Ａおよび図１１Ｂは、例示的なインオーダープロセッサアーキテクチャのブロック図を示す。これらの例示的な実施形態は、ワイドベクトルプロセッサ（ＶＰＵ）で補強されたインオーダーＣＰＵコアの複数のインスタンシエイションに基づいて設計されている。コアはｅ１３ｔアプリケーションに応じて、何らかの所定の関数ロジック、メモリＩ／Ｏインタフェース、および、他の必要なＩ／Ｏロジックと高帯域幅インターコネクトネットワークを介して通信を行う。例えば、スタンドアローンＧＰＵとしての本実施形態の実施は、典型的にはＰＣＩｅバスを含む。

図１１Ａは、本願発明の実施形態に係る、シングルＣＰＵコア、当該シングルＣＰＵコアのオンダイインターコネクトネットワーク１１０２との接続、およびレベル２（Ｌ２）キャッシュ１１０４のローカルサブセットを示すブロック図である。命令デコーダ１１００は、特定のベクトル命令形式９００を含む拡張を有するｘ８６命令セットをサポートする。本願発明の一実施形態においては、（設計を単純にするべく）スカラユニット１１０８およびベクトルユニット１１１０は別個のレジスタセットを用い（それぞれ、スカラレジスタ１１１２、およびベクトルレジスタ１１１４）、これらの間で転送されるデータはメモリへ書き込まれ、レベル１（Ｌ１）キャッシュ１１０６から読み出されるが、本願発明の代替的な実施形態においては、異なるアプローチが用いられる（例えば、１つのレジスタセットが用いられる、または、書き込みおよび読み出しが行われることなく２つのレジスタファイル間でデータの転送を可能とする通信パスが含まれる）。

Ｌ１キャッシュ１１０６は、メモリのスカラユニットおよびベクトルユニットへのキャッシュのための短いレイテンシでのアクセスを可能とする。ベクトルフレンドリーな命令形式のロードオペランド命令と併せて、このことは、拡張されたレジスタファイルと幾分同じようにＬ１キャッシュ１１０６を扱えることを意味する。このことにより、多くのアルゴリズム、特に削除ヒントフィールド８５２Ｂのアルゴリズムに関して性能を向上させられる。

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

図１１Ｂは、本願発明の実施形態に係る、図１１ＡのＣＰＵコアの一部を示す分解図である。図１１ＢはＬ１キャッシュ１１０４のＬ１データキャッシュ１１０６Ａ部分、並びに、ベクトルユニット１１１０およびベクトルレジスタ１１１４の詳細を示す。詳細には、ベクトルユニット１１１０は整数、単精度浮動小数点、および倍精度浮動小数点命令を実行する１６ワイドベクトル処理ユニット（ＶＰＵ）（１６ワイドＡＬＵ１１２８を参照）である。ＶＰＵは、スウィズルユニット１１２０のレジスタインプットのスウィズル、数値変換ユニット１１２２Ａ、１１２２Ｂの数値変換、およびメモリインプットの複製ユニット１１２４の複製をサポートする。書き込みマスクレジスタ１１２６により、結果として生じるベクトル書き込みの予測が可能となる。

レジスタデータは、例えば行列の乗算をサポートするなど、様々なやり方でスウィズル出来る。メモリからのデータは、複数のＶＰＵレーンに対して複製出来る。このことはグラフィックおよび非グラフィック両方の並列データ処理に共通の演算であり、キャッシュの効率性をはるかに向上させる。

リングネットワークは、ＣＰＵコア、Ｌ２キャッシュ、および他のロジックグロックなどのエージェントが互いにチップ内で通信を行えるよう双方向性である。各リングデータパスは、一方向あたり１０１２ビット幅である。

例示的なアウトオブオーダーアーキテクチャ−図１２
図１２は、本願発明の実施形態に係る例示的なアウトオブオーダーアーキテクチャを示すブロック図である。詳細には、図１２は、ベクトルフレンドリーな命令形式およびその実行に対応するよう修正された周知の例示的なアウトオブオーダーアーキテクチャを示す。図１２において、矢印は２以上のユニットの結合を示し、矢印の方向はそれらユニット間のデータフローの方向を示す。図１２は、実行エンジンユニット１２１０およびメモリユニット１２１５に結合されたフロントエンドユニット１２０５を含む。実行エンジンユニット１２１０はさらに、メモリユニット１２１５に結合されている。

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

実行エンジンユニット１２１０は、リネーム／アロケータユニット１２５６を含み、リネーム／アロケータユニット１２５６は、リタイヤユニット１２７４および統合スケジューラユニット１２５８に結合されている。リタイヤユニット１２７４はさらに、実行ユニット１２６０に結合され、リオーダバッファユニット１２７８を含む。統合スケジューラユニット１２５８はさらに、物理レジスタファイルユニット１２７６に結合され、物理レジスタファイルユニット１２７６は実行ユニット１２６０に結合されている。物理レジスタファイルユニット１２７６は、ベクトルレジスタユニット１２７７Ａ、書き込みマスクレジスタユニット１２７７Ｂ、および、スカラレジスタユニット１２７７Ｃを備える。これらのレジスタユニットは、ベクトルレジスタ１０１０、ベクトルマスクレジスタ１０１５、および、汎用レジスタ１０２５を提供してもよく、物理レジスタファイルユニット１２７６は、示されていない追加のレジスタファイルを含んでもよい（例えば、ＭＭＸパックド整数フラットレジスタファイル１０５０に対しエイリアスされたスカラ浮動小数点スタックレジスタファイル１０４５）。実行ユニット１２６０は３個のミックスされたスカラおよびベクトルユニット１２６２、１２６４、１２７２、ロードユニット１２６６、格納アドレスユニット１２６８、および、格納データユニット１２７０を含む。ロードユニット１２６６、格納アドレスユニット１２６８、および、格納データユニット１２７０はそれぞれさらに、メモリユニット１２１５内のデータＴＬＢユニット１２５２に結合されている。

メモリユニット１２１５は、第２レベルＴＬＢユニット１２４６を含み、第２レベルＴＬＢユニット１２４６は、データＴＬＢユニット１２５２に結合されている。データＴＬＢユニット１２５２はＬ１データキャッシュユニット１２５４に結合されている。Ｌ１データキャッシュユニット１２５４はさらに、Ｌ２キャッシュユニット１２４８に結合されている。いくつかの実施形態において、Ｌ２キャッシュユニット１２４８はさらに、メモリユニット１２１５内、および／または外のＬ３およびさらに高いレベルのキャッシュユニット１２５０に結合されている。

例として、例示的なアウトオブオーダーアーキテクチャは、次のように処理パイプライン８２００を実施する。１）命令フェッチ／プリデコードユニット１２２８がフェッチおよび長さデコード段階を実行する、２）デコードユニット１２３２がデコード段階を実行する、３）リネーム／アロケータユニット１２５６がアロケーションおよびリネーム段階を実行する、４）統合スケジューラユニット１２５８がスケジューリング段階を実行する、５）物理レジスタファイルユニット１２７６、リオーダバッファユニット１２７８、およびメモリユニット１２１５がレジスタ読み出し／メモリ読み出し段階を実行し、実行ユニット１２６０が実行／データ変換段階を実行する、６）メモリユニット１２１５およびリオーダバッファユニット１２７８が、書き戻し／メモリ書き込み段階１９６０を実行する、７）リタイヤユニット１２７４がＲＯＢ読み出し段階を実行する、８）様々なユニットが例外取り扱い段階に関わってもよい、９）リタイヤユニット１２７４および物理レジスタファイルユニット１２７６がコミット段階を実行する。

例示的なシングルコアおよびマルチコアプロセッサ−図１７
図１７は、本願発明の実施形態に係る、集積メモリコントローラおよび集積グラフィックを備えたシングルコアプロセッサおよびマルチコアプロセッサ１７００を示すブロック図である。図１７において、実線の四角はシングルコア１７０２Ａ、システムエージェント１７１０、および１以上のバスコントローラユニット１７１６からなるセットを含むプロセッサ１７００を示し、破線の四角は、複数のコア１７０２Ａ〜Ｎ、システムエージェントユニット１７１０内の１以上の集積メモリコントローラユニット１７１４からなるセット、および集積グラフィックロジック１７０８を含む代替的なプロセッサ１７００を任意的な追加として示す。

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

いくつかの実施形態において、１以上のコア１７０２Ａ〜Ｎは、マルチスレッドに対応可能である。システムエージェント１７１０は、コア１７０２Ａ〜Ｎの調整を行い動作させるコンポーネントを含む。システムエージェントユニット１７１０は、例えば、電力制御ユニット（ＰＣＵ）、およびディスプレイユニットを含む。ＰＣＵは、コア１７０２Ａ〜Ｎおよび集積グラフィックロジック１７０８の電力状況を制御するのに必要なロジックおよびコンポイーネントであるか、それらを含んでもよい。ディスプレイユニットが１以上の外部接続されたディスプレイを駆動する。

コア１７０２Ａ〜Ｎは、アーキテクチャ、および／または命令セットに関して、同質、または異質のものであってもよい。例えば、コア１７０２Ａ〜Ｎのうちいくつかはインオーダー（例えば、図１１Ａおよび図１１Ｂで示すような）であり、他のコアは、アウトオブオーダー（例えば、図１２に示すような）であってもよい。他の例として、コア１７０２Ａ〜Ｎのうち２以上は、同じ命令セットを実行可能であり、他のコアは、その命令セットのサブセットのみ、または異なる命令セットを実行可能である。少なくとも１つのコアが、本明細書で説明するベクトルフレンドリーな命令形式を実行可能である。

プロセッサは、米国カリフォルニア州サンタクララのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎにより販売されるＣｏｒｅ（登録商標）ｉ３、ｉ５、ｉ７、２ Ｄｕｏ、およびＱｕａｄ、Ｘｅｏｎ（登録商標）、またはＩｔａｎｉｕｍ（登録商標）プロセッサなどの汎用プロセッサであってよい。代替的に、プロセッサは他の企業が販売するものであってもよい。プロセッサは、例えば、ネットワークまたは通信プロセッサ、圧縮エンジン、グラフィックプロセッサ、コプロセッサ、埋め込み型プロセッサなどの特定用途プロセッサであってもよい。プロセッサは１以上のチップ上で実装されてもよい。プロセッサ１７００は、ＢｉＣＭＯＳ、ＣＭＯＳ、またはＮＭＯＳなどの処理技術をいくつか用い、１以上の基板の一部である、および／または、それら基板上で実装されてもよい。

例示的なコンピュータシステムおよびプロセッサ−図１３〜１５
図１３〜１５は、プロセッサ１７００を含めるのに適した例示的なシステムを示す。図１６は、１以上のコア１７０２を含み得る例示的なシステムオンチップ（ＳｏＣ）を示す。ラップトップ、デスクトップ、ハンドヘルドＰＣ、パーソナルデジタルアシスタント、エンジニアリングワークステーション、サーバ、ネットワークデバイス、ネットワークハブ、スイッチ、埋め込み型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、グラフィックデバイス、ビデオゲームデバイス、セットトップボックス、マイクロコントローラ、携帯電話、携帯型メディアプレーヤ、ハンドヘルドデバイス、および様々な他の電子デバイスに関する当分野で公知の他のシステム設計および構成も適している。一般的に、本明細書で開示されるプロセッサ、および／または他の実行ロジックを組み込むことが可能な非常に幅広い種類のシステムまたは電子デバイスが適している。

図１３は、本願発明の一実施形態に係るシステム１３００を示すブロック図である。システム１３００は、１以上のプロセッサ１３１０、１３１５を含み、１以上のプロセッサ１３１０、１３１５はグラフィックメモリコントローラハブ（ＧＭＣＨ）１３２０に結合されている。追加のプロセッサ１３１５は任意で用いられるので、図１３において破線で示されている。

各プロセッサ１３１０、１３１５はプロセッサ１７００の何らかのバージョンであってよい。しかし、集積グラフィックロジックおよび集積メモリ制御ユニットがプロセッサ１３１０、１３１５内に存在するということは考えられにくい。

図１３は、ＧＭＣＨ１３２０が、例えばダイナミックランダムアクセスメモリ（ＤＲＡＭ）であってよいメモリ１３４０に結合されていてよいことを示す。ＤＲＡＭは、少なくとも一実施形態において、非揮発性キャッシュに関連付けられている。

ＧＭＣＨ１３２０は、チップセットである、またはチップセット一部である。ＧＭＣＨ１３２０はプロセッサ１３１０、１３１５と通信を行い、プロセッサ１３１０、１３１５とメモリ１３４０との間の相互作用を制御してもよい。またＧＭＣＨ１３２０は、プロセッサ１３１０、１３１５と、システム１３００の他の要素との間の加速バスインタフェースとして動作してもよい。少なくとも一実施形態において、ＧＭＣＨ１３２０は、フロントサイドバス（ＦＳＢ）１３９５などのマルチドロップバスを介してプロセッサ１３１０、１３１５と通信を行う。

さらに、ＧＭＣＨ１３２０は、ディスプレイ１３４５（フラットパネルディスプレイなど）に結合されている。ＧＭＣＨ１３２０は、集積グラフィックアクセラレータを含んでもよい。ＧＭＣＨ１３２０はさらに、様々な周辺デバイスをシステム１３００に結合するのに用いられ得る、入力／出力（Ｉ／Ｏ）コントローラハブ（ＩＣＨ）１３５０に結合されている。図１３の実施形態においては、他の周辺デバイス１３７０と併せて、ＩＣＨ１３５０に結合されている独立したグラフィックデバイスであってよい外部グラフィックデバイス１３６０が例として示されている。

代替的に、追加的な、または異なるプロセッサもシステム１３００に存在してもよい。例えば、追加のプロセッサ１３１５には、プロセッサ１３１０と同じ追加のプロセッサ、プロセッサ１３１０と異質の、または対称的な追加のプロセッサ、アクセラレータ（例えば、グラフィックアクセラレータ、またはデジタル信号処理（ＤＳＰ）ユニットなど）、フィールドプログラマブルゲートアレイ、または他の何らかのプロセッサが含まれてよい。アーキテクチャ、マイクロアーキテクチャ、熱、電力消費特性などの面で、物理リソース１３１０、１３１５毎に様々な利点がある。これらの利点の差は、処理要素１３１０、１３１５間の対称性または異質性を利用し有効に活用される。少なくとも一実施形態において、様々な処理要素１３１０、１３１５が同じダイパッケージに存在してもよい。

図１４は、本願発明の実施形態に係る第２システム１４００を示すブロック図である。図１４に示すようにマルチプロセッサシステム１４００は、ポイントツーポイントインターコネクトシステムであり、ポイントツーポイントインターコネクト１４５０で結合された第１プロセッサ１４７０および第２プロセッサ１４８０を含む。図１４に示すように各プロセッサ１４７０、１４８０はプロセッサ１７００の何らかのバージョンであってよい。

代替的に、１以上のプロセッサ１４７０、１４８０は、アクセラレータまたはフィールドプログラマブルゲートアレイなど、プロセッサ以外の要素であってよい。

２つのプロセッサ１４７０、１４８０のみが示されているが、本願発明の態様はこのことに限定されない。他の実施形態において、１以上の追加的な処理要素が任意のプロセッサに存在してもよい。

プロセッサ１４７０はさらに、集積メモリコントローラハブ（ＩＭＣ）１４７２、およびポイントツーポイント（Ｐ−Ｐ）１４７６、１４７８を含んでもよい。同様に、第２プロセッサ１４８０は、ＩＭＣ１４８２およびＰ−Ｐインタフェース１４８６、１４８８を含んでもよい。プロセッサ１４７０、１４８０は、ＰｔＰインタフェース回路１４７８、１４８８を用いてポイントツーポイント（ＰｔＰ）インタフェース１４５０を介してデータを交換してもよい。図１４に示すようにＩＭＣ１４７２、１４８２は各プロセッサを、対応するメモリ、つまり各プロセッサにローカルに取り付けられた主メモリの一部であってもよいメモリ１４４２およびメモリ１４４４に結合する。

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

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

チップセット１４９０は、インタフェース１４９６を介して第１バス１４１６に結合されていてもよい。一実施形態において、第１バス１４１６は、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス、或いは、ＰＣＩ Ｅｘｐｒｅｓｓバスまたは他の第３世代Ｉ／Ｏインターコネクトバスなどのバスであってもよい。ただし、本願発明の態様はこのことに限定されない。

図１４に示すように、第１バス１４１６を第２バス１４２０へ結合するバスブリッジ１４１８と併せて、様々なＩ／Ｏデバイス１４１４が第１バス１４１６に結合されていてもよい。一実施形態において、第２バス１４２０はｌｏｗ ｐｉｎ ｃｏｕｎｔ（ＬＰＣ）バスであってもよい。一実施形態において、キーボード／マウス１４２２、通信デバイス１４２６、並びに、ディスクドライブまたは、コード１４３０を含んでよい他の大容量記憶装置などのデータ格納ユニット１４２８など様々なデバイスが第２バス１４２０に結合されていてもよい。さらに、オーディオＩ／Ｏ１４２４が第２バス１４２０に結合されていてもよい。なお他のアーキテクチャを用いることも可能である。例えば、図１４のポイントツーポイントアーキテクチャの代わりに、システムは、マルチドロップバスまたは他の同様のアーキテクチャを実装してもよい。

図１５は、本願発明の実施形態に係る第３システム１５００を示すブロック図である。図１４および図１５において同様の要素は、同様の参照符号が付されており、図１４の特定の態様は、図１５の他の態様を曖昧にすることを避けるべく図１５において省略されている。

図１５は、処理要素１４７０、１４８０がそれぞれ集積メモリ−Ｉ／Ｏ制御ロジック（「ＣＬ」）１４７２、１４８２を含んでよいことを示す。少なくとも一実施形態において、ＣＬ１４７２、１４８２は図１３および図１４に関連して上述したようなメモリコントローラハブロジック（ＩＭＣ）を含んでもよい。加えて、ＣＬ１４７２、１４８２はＩ／Ｏ制御ロジックも含んでよい。図１５は、メモリ１４４２、１４４４のみがＣＬ１４７２、１４８２に結合されているのではなく、Ｉ／Ｏデバイス１５１４も制御ロジック１４７２、１４８２に結合されていることを示す。レガシーＩ／Ｏデバイス１５１５がチップセット１４９０に結合されている。

図１６は、本願発明の実施形態に係るＳｏＣ１６００のブロック図を示す。図１７の同様の要素には同様の参照符号が付されている。また破線の四角はより高度なＳｏＣの、任意で用いられる特徴を示す。図１６において、インターコネクトユニット１６０２は、１以上のコア１７０２Ａ〜Ｎからなるセットおよび共有キャッシュユニット１７０６を含むアプリケーションプロセッサ１６１０と、システムエージェントユニット１７１０と、バスコントローラユニット１７１６と、集積メモリコントローラユニット１７１４と、集積グラフィックロジック１７０８、スチールカメラ、および／またはビデオカメラ機能を提供するイメージプロセッサ１６２４、ハードウェアオーディオアクセラレーションを提供するオーディオプロセッサ１６２６、および、ビデオエンコード／デコードアクセラレーションを提供するビデオプロセッサ１６２８を含み得る１以上のメディアプロセッサ１６２０からなるセットと、スタティックランダムアクセスメモリ（ＳＲＡＭ）ユニット１６３０と、ダイレクトメモリメモリアクセス（ＤＭＡ）ユニット１６３２と、１以上の外部ディスプレイに結合されるディスプレイユニット１６４０とに結合されている。

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

プログラムコードは、本明細書で開示される機能を実行し、出力情報を生成する入力データに適用されてもよい。出力情報は、公知の方式で、１以上の出力デバイスに適用されてもよい。この適用の目的において、処理システムは、例えば、デジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途集積回路（ＡＳＩＣ）、またはマイクロプロセッサなどのプロセッサを有する何らかのシステムを含む。

プログラムコードは、処理システムと通信を行う高水準の手続き型プログラミング言語またはオブジェクト指向のプログラミング言語で実施されてもよい。またプログラムコードは、所望される場合、アセンブリ言語または機械言語で実施されてもよい。事実、本明細書で開示されるメカニズムは、何らかの特定のプログラミング言語に限定されない。いずれの場合であっても、言語はコンパイラ型言語、またはインタープリタ型言語であってもよい。

少なくとも１つの実施形態の１以上の態様は、機械によって読み出されると当該機械に本明細書で開示される技術を実施するロジックを作成させる、プロセッサ内の様々なロジックを表す機械可読媒体に格納された表現命令によって実施されてもよい。「ＩＰコア」とし知られるそのような表現は、有形の機械可読媒体に格納され、ロジックまたはプロセッサを実際に作成する製造機械にロードされるべく様々な顧客または製造施設に提供されてもよい。

そのような機械可読媒体には、これらに限定されるわけではないが、機械またはデバイスによって製造または形成される、ハードディスク、フロッピー（登録商標）ディスク、光学式ディスク（コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスクリライタブル（ＣＤ−ＲＷ）、および光磁気ディスクなどを含む他の何らかのタイプのディスク、リードオンリーメモリ（ＲＯＭ）などの半導体デバイス、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、消去可能プログラム可能リードオンリーメモリ（ＥＰＲＯＭ）、フラッシュメモリ、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、磁気または光学式カード、または、電子命令を格納するのに適した他の何らかのタイプの媒体などの記憶媒体を含む物品の非一時的な有形構造を含み得る。

したがって、本願発明の実施形態は、本明細書で説明される構造、回路、装置、プロセッサ、および／またはシステム特徴を定めるベクトルフレンドリーな命令形式の命令を保持する、またはＨａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＨＤＬ）などの設計データを保持する非一時的有形機械可読媒体も含む。そのような実施形態は、プログラム製品とも呼ばれ得る。

場合によっては、命令コンバータを用いて、ソース命令セットからターゲット命令セットへ命令が変換される。例えば、命令コンバータは、命令をコアによって処理される１以上の他の命令にトランスレートする（スタティックバイナリトランスレーション、ダイナミックコンパイルを含むダイナミックバイナリトランスレーションを用いて）、モーフィングする、エミュレートする、または変換してもよい。命令コンバータは、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組み合わせによって実施されてもよい。命令コンバータは、プロセッサ上、プロセッサ外、または一部がプロセッサ上で一部がプロセッサ外であってもよい。

図１８は、本願発明の実施形態に係る、ソース命令セットのバイナリ命令をターゲット命令セットのバイナリ命令に変換するソフトウェア命令コンバータの利用を対比するブロック図である。示される実施形態において、命令コンバータはソフトウェア命令コンバータであるが、代替的に、命令コンバータは、ソフトウェア、ファームウェア、ハードウェア、またはこれらの様々な組み合わせで実施されてもよい。図１８は、少なくとも１つのｘ８６命令セットコアを備えるプロセッサ１８１６によりネイティブに実行され得るｘ８６バイナリコード１８０６を生成するべくｘ８６コンパイラ１８０４を用いてコンパイルされている高水準言語１８０２のプログラムを示す（コンパイルされた命令のうちいくつかがベクトルフレンドリーな命令形式であるものと想定されている）。少なくとも１つのｘ８６命令セットコアを備えるプロセッサ１８１６は、（１）Ｉｎｔｅｌｘ８６命令セットコアの命令の実質的な部分、または、（２）少なくとも１つのｘ８６命令セットコアを備えるＩｎｔｅｌプロセッサと実質的に同じ結果を得るべく、少なくとも１つのｘ８６命令セットコアを備えるＩｎｔｅｌプロセッサで実行されることを目的とするアプリケーションのオブジェクトコードバージョンまたは他のソフトウェアに適合して実行する、または処理することにより、少なくとも１つのｘ８６命令セットコアを備えるＩｎｔｅｌプロセッサと実質的に同じ機能を実行出来るプロセッサを表す。ｘ８６コンパイラ１８０４は、少なくとも１つのｘ８６命令セットコアを備えるプロセッサ１８１６で追加のリンク処理あり、またはなしで実行され得るｘ８６バイナリコード１８０６（例えばオブジェクトコード）を生成するべく動作可能なコンパイラを表す。同様に、図１８は、少なくとも１つのｘ８６命令セットコアを備えないプロセッサ１８１４（例えば、米国カリフォルニア州サニーベールのＭＩＰＳ ＴｅｃｈｎｏｌｏｇｉｅｓのＭＩＰＳ命令セットを実行するコアを備えるプロセッサ、および／または米国カリフォルニア州サニーベールのＡＲＭ ＨｏｌｄｉｎｇｓのＡＲＭ命令セットを実行するコアを備えるプロセッサなど）によってネイティブに実行され得る代替的な命令セットバイナリコード１８１０を生成するべく、代替的な命令セットコンパイラ１８０８を用いてコンパイルされ得る高水準言語１８０２のプログラムを示す。命令コンバータ１８１２を用いて、ｘ８６命令セットコアを備えないプロセッサ１８１４によってネイティブに実行され得るコードへｘ８６バイナリコード１８０６を変換する。この変換されたコードが、代替的な命令セットバイナリコード１８１０と同じであることは考えられにくい。なぜなら、このことに対応可能な命令コンバータは作成しにくいからである。しかし、変換されたコードは、一般的な動作を実行し、代替的な命令セットからの命令によって構成されているであろう。よって、命令コンバータ１８１２は、エミュレーション、シミュレーション、または他の何らかの処理により、プロセッサ、或いは、ｘ８６命令セットプロセッサまたはコアを有さない他の電子デバイスがｘ８６バイナリコード１８０６を実行することを可能とする、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組み合わせを表す。

本明細書で開示されるベクトルフレンドリーな命令形式の命令の特定の動作は、ハードウェアコンポーネントで実行されてもよく、当該命令をプログラムされた回路または他のハードウェアコンポーネントによるそれらの動作の実行を引き起こす、または少なくともそのような結果をもたらすのに用いられる機械可読命令として実施され得る。回路には、ほんの数例を上げると、汎用プロセッサ、特定用途プロセッサ、またはロジック回路が含まれる。また動作は、場合によっては、ハードウェアとソフトウェアとの組み合わせによって実施されてもよい。実行ロジック、および／またはプロセッサは、命令によって特定される結果オペランドを格納するよう指示する機械命令、または当該機械命令から抽出された１以上の制御信号に応答する特定的な、または特定の回路または他のロジックを含んでもよい。例えば、本明細書で開示される命令の実施形態は、図１３〜１６の１以上のシステムで実行されてもよく、ベクトルフレンドリーな命令形式の命令の実施形態は、システムによって実行されるプログラムコードに格納されてもよい。加えて、これら図面の処理要素は、本明細書で詳述されたパイプライン、および／またはアーキテクチャ（例えば、インオーダーアーキテクチャ、およびアウトオブオーダーアーキテクチャ）のうち１つを用いてもよい。例えば、インオーダーアーキテクチャのデコードユニットは、命令をデコードし、デコードされた命令をベクトルユニットまたはスカラユニットに渡すなどしてもよい。

上記の説明は、本願発明の好ましい実施形態を示すことを目的として提供された。上記の説明から、成長が早くさらなる進歩の予測が容易ではない当技術分野において特に、本願発明は構造に関して、また詳細部分において、当業者によって本願発明の原理から逸脱することなく、添付の請求項およびそれらの同等物の範囲内で本願発明に修正が加えられ得ることは明らかである。例えば、方法の１以上の動作は組み合わせられ得る、またはさらに分割され得る。

代替的な実施形態
ベクトルフレンドリーな命令形式がネイティブに実行される実施形態を説明してきたが、代替的な実施形態においては、異なる命令セットを実行する（例えば、米国カリフォルニア州サニーベールのＭＩＰＳ ＴｅｃｈｎｏｌｏｇｉｅｓのＭＩＰＳ命令セットを実行するプロセッサ、米国カリフォルニア州サニーベールのＡＲＭ ＨｏｌｄｉｎｇｓのＡＲＭ命令セットを実行するプロセッサなどの）プロセッサ上で実行されるエミュレーションレイヤーを介してベクトルフレンドリーな命令形式を実行してもよい。また、図中のフロー図は本願発明の特定の実施形態によって実行される動作の特定の順序を示すが、そのような順序は例示であることが理解されるべきである（例えば、代替的な実施形態においては、それらの動作を異なる順序で実行する、特定の動作を組み合わせる、または特定の動作を同時に行うなど）。

以上の説明において、説明を目的とし、本願発明の実施形態をよりよく理解いただけるように様々な特定の詳細を示してきた。しかし当業者であれば、それら特定の詳細のいくつかを用いずとも１以上の他の実施形態が実施可能であることを理解されよう。説明された特定の実施形態は、本願発明を限定するのではなく、本願発明の実施形態を例示するべく示されている。本願発明の態様は上記された特定の例によっては定められず、以下の請求項によってのみ定められる。
本明細書によれば、以下の各項目に記載の構成もまた開示される。
［項目１］
コンピュータプロセッサでアライメント命令を実行する方法であり、
書き込みマスクオペランドと、宛て先オペランドと、第１ソースオペランドと、第２ソースオペランドと、オフセット値とを含む前記アライメント命令をフェッチする段階と、
フェッチされた前記アライメント命令をデコードする段階と、
前記第１ソースオペランドの第１の複数のデータ要素と、前記第２ソースオペランドの第２の複数のデータ要素とを連結し、
連結された前記第１の複数のデータ要素および前記第２の複数のデータ要素を前記オフセット値に基づき右にシフトし、
右にシフトされた前記連結された第１の複数のデータ要素および第２の複数のデータ要素のうち宛て先の対応する位置に格納されるデータ要素を書き込みマスクの対応するビットに基づき判断する
ことにより、デコードされた前記アライメント命令を実行する段階と、
前記宛て先に格納されると判断された前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうちの前記データ要素を前記宛て先の前記対応する位置に格納する段階と
を備える方法。
［項目２］
前記書き込みマスクは１６ビットのレジスタである、項目１に記載の方法。
［項目３］
前記オフセットは８ビットの即値である、項目１または２に記載の方法。
［項目４］
前記書き込みマスクが用いられるかどうかを判断する段階と、
前記書き込みマスクが用いられない場合、前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうち前記宛て先の前記対応する位置に格納される前記データ要素を前記書き込みマスクの前記対応するビットに基づき判断することなく、前記宛て先の前記対応する位置に前記右にシフトされた連結された第1１の複数のデータ要素および第２の複数のデータ要素のうちの前記データ要素を格納する段階と
をさらに備える、項目１から３のいずれか１項に記載の方法。
［項目５］
前記宛て先に格納されるとの判断は、前記書き込みマスクの各ビット位置に関して並行して行われる、項目１から４のいずれか１項に記載の方法。
［項目６］
前記第１ソースオペランドおよび前記第２ソースオペランドは５１２ビットのレジスタである、項目１から５のいずれか１項に記載の方法。
［項目７］
前記第２ソースオペランドは５１２ビットのメモリ位置であり、
前記メモリ位置からの前記データ要素は、ソースの前記連結の前に一時的な５１２ビットのレジスタへロードされる、項目１から６のいずれか１項に記載の方法。
［項目８］
前記第１ソースオペランドの前記データ要素は、前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうち最下位のデータ要素である、項目１から７のいずれか１項に記載の方法。
［項目９］
第１ソースオペランドと、第２ソースオペランドと、宛て先オペランドと、書き込みマスクオペランドと、オフセットとを含むアライメント命令に応答し、
前記第１ソースオペランドの第１セットのデータ要素と、前記第２ソースオペランドの第２セットのデータ要素とを連結する段階と、
連結された前記第１セットのデータ要素および前記第２セットのデータ要素をＸ個のデータ要素の分だけ右にシフトする段階であり、Ｘは前記アライメント命令が示す即値である段階と、
書き込みマスクの第１ビット位置に関し、
シフトされた前記連結された第１セットのデータ要素および第２セットのデータ要素のうち対応するデータ要素が宛て先の対応する位置に格納されることを前記第１ビット位置が示すか判断し、
前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち前記対応するデータ要素が格納されることを前記書き込みマスクの前記第１ビット位置が示す場合、前記対応するデータ要素を前記宛て先の前記対応する位置に格納し、
前記対応するデータ要素が前記宛て先に格納されないことを前記書き込みマスクの前記第１ビット位置が示す場合、前記宛て先の前記対応する位置のデータ要素に変更を加えない
段階と
を備える方法。
［項目１０］
前記書き込みマスクの第２ビット位置に関し、
前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち対応するデータ要素が前記宛て先の対応する位置に格納されることを前記第２ビット位置が示すか判断し、
前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち前記対応するデータ要素が格納されることを前記書き込みマスクの前記第２ビット位置が示す場合、前記対応するデータ要素を前記宛て先の対応する位置に格納し、
前記対応するデータ要素が前記宛て先に格納されないことを前記書き込みマスクの前記第２ビット位置が示す場合、前記宛て先の前記対応する位置のデータ要素に変更を加えない
段階と
をさらに備える、項目９に記載の方法。
［項目１１］
最後のビット位置に関して、前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち対応するデータ要素を前記宛て先の対応する位置に格納されるかを判断するべく評価された時点を判断し、前記アライメント命令を完了する段階をさらに備える、項目１０に記載の方法。
［項目１２］
前記書き込みマスクの前記第１ビット位置は前記書き込みマスクの最下位のビットである、項目９から１１のいずれか１項に記載の方法。
［項目１３］
前記書き込みマスクは１６ビットのレジスタである、項目９から１２のいずれか１項に記載の方法。
［項目１４］
前記オフセットは８ビットの即値である、項目９から１３のいずれか１項に記載の方法。
［項目１５］
前記第１ビット位置が示すかの判断は、前記書き込みマスクの各ビット位置に関して並行して行われる、項目９から１４のいずれか１項に記載の方法。
［項目１６］
前記第１ソースオペランドおよび前記第２ソースオペランドは５１２ビットのレジスタである、項目９から１５のいずれか１項に記載の方法。
［項目１７］
前記第２ソースオペランドは５１２ビットのメモリ位置であり、
前記メモリ位置からの前記データ要素は、ソースの前記連結の前に一時的な５１２ビットのレジスタへロードされる、項目９から１６のいずれか１項に記載の方法。
［項目１８］
書き込みマスクオペランドと、宛て先オペランドと、第１ソースオペランドと、第２ソースオペランドと、オフセット値とを含むアライメント命令をデコードするハードウェアデコーダと、
実行ロジックと
を備え、
前記実行ロジックは、
前記第１ソースオペランドの第１の複数のデータ要素と、前記第２ソースオペランドの第２の複数のデータ要素とを連結し、
連結された前記第１の複数のデータ要素および前記第２の複数のデータ要素を前記オフセット値に基づき右にシフトし、
右にシフトされた前記連結された前記第１の複数のデータ要素および前記第２の複数のデータ要素のうち宛て先の対応する位置に格納されるデータ要素を書き込みマスクのうち対応するビットに基づき判断し、
前記宛て先に格納されると判断された前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうちの前記データ要素を前記宛て先の前記対応する位置に格納する、
装置。
［項目１９］
前記書き込みマスクを格納する１６ビットの書き込みマスクレジスタと、
前記第１ソースオペランドおよび前記第２ソースオペランドの前記データ要素を格納する少なくとも２つの５１２ビットのレジスタと
をさらに備える項目１８に記載の装置。

Claims (20)

1. コンピュータプロセッサで命令を実行する方法であり、
   明示的書き込みマスクレジスタオペランドと、宛て先オペランドと、第１ソースオペランドと、第２ソースオペランドと、オフセット値とを含む前記命令をフェッチする段階と、
   フェッチされた前記命令をデコードする段階と、
   前記第１ソースオペランドの第１の複数のデータ要素と、前記第２ソースオペランドの第２の複数のデータ要素とを連結し、
   連結された前記第１の複数のデータ要素および前記第２の複数のデータ要素を前記オフセット値に基づき右にシフトし、
   右にシフトされた前記連結された第１の複数のデータ要素および第２の複数のデータ要素のうち宛て先の対応する位置に格納されるデータ要素を前記明示的書き込みマスクレジスタオペランドの対応するビット位置の値に基づき判断する
   ことにより、デコードされた前記命令を実行する段階と、
   前記宛て先に格納されると判断された前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうちの前記データ要素を、前記明示的書き込みマスクレジスタオペランドに基づいて、前記宛て先の前記対応する位置に格納する段階と
   を備え、
   前記判断することにおいて用いられるビット位置の数は、前記命令のプレフィックスに定められる前記第１ソースオペランドおよび前記第２ソースオペランドの前記データ要素のサイズならびに前記第１ソースオペランドおよび前記第２ソースオペランドのサイズに依存し、前記明示的書き込みマスクレジスタオペランドは、複数の専用の書き込みマスクレジスタの１つを示す
   方法。
2. 前記明示的書き込みマスクレジスタオペランドは１６ビットのレジスタである、請求項１に記載の方法。
3. 前記オフセット値は８ビットの即値である、請求項１または２に記載の方法。
4. 前記明示的書き込みマスクレジスタオペランドが用いられないか判断する段階と、
   前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうち前記宛て先の対応する位置に格納される前記データ要素を前記明示的書き込みマスクレジスタオペランドの対応するビットに基づき判断することなく、前記宛て先の前記対応する位置に前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうちの前記データ要素を格納する段階と
   をさらに備える、請求項１から３のいずれか１項に記載の方法。
5. 前記宛て先に格納されるとの判断は、前記明示的書き込みマスクレジスタオペランドの各ビット位置に関して並行して行われる、請求項１から４のいずれか１項に記載の方法。
6. 前記第１ソースオペランドおよび前記第２ソースオペランドは５１２ビットのレジスタである、請求項１から５のいずれか１項に記載の方法。
7. 前記第２ソースオペランドは５１２ビットのメモリ位置であり、
   前記メモリ位置からの前記データ要素は、前記第１ソースオペランドおよび前記第２ソースオペランドの前記連結の前に一時的な５１２ビットのレジスタへロードされる、請求項１から６のいずれか１項に記載の方法。
8. 前記第１ソースオペランドの前記データ要素は、前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうち下位側のデータ要素である、請求項１から７のいずれか１項に記載の方法。
9. 第１ソースオペランドと、第２ソースオペランドと、宛て先オペランドと、明示的書き込みマスクレジスタオペランドと、オフセット値とを含む命令に応答し、
   前記第１ソースオペランドの第１セットのデータ要素と、前記第２ソースオペランドの第２セットのデータ要素とを連結する段階と、
   連結された前記第１セットのデータ要素および前記第２セットのデータ要素をＸ個のデータ要素の分だけ右にシフトする段階であり、Ｘは前記命令が示す即値である段階と、
   前記明示的書き込みマスクレジスタオペランドの第１ビット位置に関し、
   シフトされた前記連結された第１セットのデータ要素および第２セットのデータ要素のうち対応するデータ要素が前記宛て先の対応する位置に格納されることを前記第１ビット位置が示すか判断し、
   前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち前記対応するデータ要素が格納されることを前記明示的書き込みマスクレジスタオペランドの前記第１ビット位置が示す場合、前記対応するデータ要素を前記宛て先の前記対応する位置に格納し、
   前記対応するデータ要素が前記宛て先に格納されないことを前記明示的書き込みマスクレジスタオペランドの前記第１ビット位置が示す場合、前記宛て先の前記対応する位置のデータ要素に変更を加えない
   段階とを備え
   前記判断することにおいて用いられるビット位置の数は、前記命令のプレフィックスに定められる前記第１ソースオペランドおよび前記第２ソースオペランドの前記データ要素のサイズならびに前記第１ソースオペランドおよび前記第２ソースオペランドのサイズに依存し、前記明示的書き込みマスクレジスタオペランドは、複数の専用の書き込みマスクレジスタの１つを示す
   方法。
10. 前記明示的書き込みマスクレジスタオペランドの第２ビット位置に関し、
    前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち対応するデータ要素が前記宛て先の対応する位置に格納されることを前記第２ビット位置が示すか判断し、
    前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち前記対応するデータ要素が格納されることを前記明示的書き込みマスクレジスタオペランドの前記第２ビット位置が示す場合、前記対応するデータ要素を前記宛て先の対応する位置に格納し、
    前記対応するデータ要素が前記宛て先に格納されないことを前記明示的書き込みマスクレジスタオペランドの前記第２ビット位置が示す場合、前記宛て先の前記対応する位置のデータ要素に変更を加えない
    段階と
    をさらに備える、請求項９に記載の方法。
11. 最後のビット位置に関して、前記シフトされた連結された第１セットのデータ要素および第２セットのデータ要素のうち対応するデータ要素を前記宛て先の対応する位置に格納されるかを判断するべく評価された時点を判断し、前記命令を完了する段階をさらに備える、請求項１０に記載の方法。
12. 前記明示的書き込みマスクレジスタオペランドの前記第１ビット位置は前記明示的書き込みマスクレジスタオペランドの最下位のビットである、請求項９から１１のいずれか１項に記載の方法。
13. 前記明示的書き込みマスクレジスタオペランドは１６ビットのレジスタである、請求項９から１２のいずれか１項に記載の方法。
14. 前記オフセット値は８ビットの即値である、請求項９から１３のいずれか１項に記載の方法。
15. 前記第１ビット位置が示すかの判断は、前記明示的書き込みマスクレジスタオペランドの各ビット位置に関して並行して行われる、請求項９から１４のいずれか１項に記載の方法。
16. 前記第１ソースオペランドおよび前記第２ソースオペランドは５１２ビットのレジスタである、請求項９から１５のいずれか１項に記載の方法。
17. 前記第２ソースオペランドは５１２ビットのメモリ位置であり、
    前記メモリ位置からの前記データ要素は、前記第１ソースオペランドおよび前記第２ソースオペランドの前記連結の前に一時的な５１２ビットのレジスタへロードされる、請求項９から１６のいずれか１項に記載の方法。
18. 明示的書き込みマスクレジスタオペランドと、宛て先オペランドと、第１ソースオペランドと、第２ソースオペランドと、オフセット値とを含む命令をデコードするハードウェアデコーダと、
    実行ロジックと
    を備え、
    前記実行ロジックは、
    前記第１ソースオペランドの第１の複数のデータ要素と、前記第２ソースオペランドの第２の複数のデータ要素とを連結し、
    連結された前記第１の複数のデータ要素および前記第２の複数のデータ要素を前記オフセット値に基づき右にシフトし、
    右にシフトされた前記連結された前記第１の複数のデータ要素および前記第２の複数のデータ要素のうち宛て先の対応する位置に格納されるデータ要素を前記明示的書き込みマスクレジスタオペランドのうち対応するビット位置の値に基づき判断し、
    前記宛て先に格納されると判断された前記右にシフトされた連結された第１の複数のデータ要素および第２の複数のデータ要素のうちの前記データ要素を、前記明示的書き込みマスクレジスタオペランドに基づいて、前記宛て先の前記対応する位置に格納し、
    前記判断することにおいて用いられるビット位置の数は、前記命令のプレフィックスに定められる前記第１ソースオペランドおよび前記第２ソースオペランドの前記データ要素のサイズならびに前記第１ソースオペランドおよび前記第２ソースオペランドのサイズに依存し、前記明示的書き込みマスクレジスタオペランドは、複数の専用の書き込みマスクレジスタの１つを示す
    装置。
19. 前記明示的書き込みマスクレジスタオペランドを格納する１６ビットの書き込みマスクレジスタと、
    前記第１ソースオペランドおよび前記第２ソースオペランドの前記データ要素を格納する少なくとも２つの５１２ビットのレジスタと
    をさらに備える請求項１８に記載の装置。
20. 前記命令は、前記第１ソースオペランドおよび前記第２ソースオペランドのデータ要素のそれぞれのサイズ、および右にシフトされた前記データ要素のうち前記宛て先に格納されるデータ要素を判断することにおいて用いられる前記明示的書き込みマスクレジスタオペランドのビット数を定めるオペコードを含む、請求項１から１７のいずれか一項に記載の方法。

Images