"コンピュータプロセッサにおいて圧縮命令を実行する方法であって:圧縮命令をフェッチする段階であって、前記圧縮命令は宛先オペランド、ソースオペランドおよび書き込みマスクオペランドを含む、段階と;フェッチされた圧縮命令をデコードする段階と;デコードされた圧縮命令を実行して、前記書き込みマスクの値に基づいてソースからのどのデータ要素が宛先において記憶されるべきかを選択する段階と;ソースの選択された要素を、シーケンシャルにパックされたデータ要素として宛先中に記憶する段階とを含む、方法。前記宛先オペランドがメモリであり、前記ソースオペランドがレジスタである、請求項1記載の方法。前記ソースおよび宛先オペランドがレジスタである、請求項1記載の方法。前記実行がさらに:前記書き込みマスクの第一ビット位置値が、対応する第一ソースデータ要素が宛先のある位置中に記憶されるべきであることを示していることを判別する段階と;前記対応する第一ソースデータ要素を宛先の前記位置中に記憶する段階とを含む、請求項1記載の方法。前記実行がさらに:前記書き込みマスクの第一ビット位置値が、対応する第一ソースデータ要素が宛先のある位置中に記憶されるべきでないことを示していることを判別する段階と;前記第一ソースデータ要素を宛先のある位置中に記憶することなく、前記書き込みマスクの第二ビット位置値を評価する段階とを含む、請求項1記載の方法。宛先中に記憶されるべき各ソースデータ要素がまずストリーム中に入れられ、そのストリームが前記宛先中に記憶される、請求項1記載の方法。宛先中に記憶されるべきデータ要素を、宛先中に記憶するのに先立って下方変換する段階をさらに含む、請求項1記載の方法。コンピュータプロセッサにおいて展開命令を実行する方法であって:展開命令をフェッチする段階であって、前記展開命令は宛先オペランド、ソースオペランドおよび書き込みマスクオペランドを含む、段階と;前記展開圧縮命令をデコードする段階と;前記展開圧縮命令を実行して、前記書き込みマスクの値に基づいてソースからのどの要素が宛先において疎に記憶されるべきかを選択する段階と;ソースの各選択されたデータ要素を、疎なデータ要素としてある宛先位置中に記憶する段階であって、前記宛先位置は、ソースの対応するデータ要素が記憶されるべきであることを示す各書き込みマスクビット位置に対応する、段階とを含む方法。前記宛先オペランドがレジスタであり、前記ソースオペランドがメモリである、請求項9記載の方法。前記ソースおよび宛先オペランドがレジスタである、請求項9記載の方法。前記実行がさらに:前記書き込みマスクの第一ビット位置値が、対応する第一ソースデータ要素が宛先の対応する位置中に記憶されるべきであることを示していることを判別する段階と;前記対応する第一ソースデータ要素を宛先の前記対応する位置中に記憶する段階とを含む、請求項9記載の方法。前記実行がさらに:前記書き込みマスクの第一ビット位置値が、対応する第一ソースデータ要素が宛先の対応する位置中に記憶されるべきでないことを示していることを判別する段階と;前記第一ソースデータ要素を宛先の対応する位置中に記憶することなく、前記書き込みマスクの第二ビット位置値を評価する段階とを含む、請求項9記載の方法。宛先中に記憶されるべき各ソースデータ要素がまずストリーム中に入れられ、そのストリームが前記宛先中に記憶される、請求項1記載の方法。宛先中に記憶されるべきデータ要素を、宛先中に記憶するのに先立って上方変換する段階をさらに含む、請求項1記載の方法。前記データ要素が16ビット値から32ビット値に上方変換される、請求項7記載の方法。展開命令および/または圧縮命令をデコードするハードウェアデコーダであって、前記展開命令は第一の書き込みマスクオペランド、第一の宛先オペランド、第一のソースオペランドを含み、前記圧縮命令は第二の書き込みマスクオペランド、第二の宛先オペランド、第二のソースオペランドを含む、ハードウェアデコーダと;実行論理とを有する装置であって、前記実行論理は、デコードされた展開命令を実行して、前記書き込みマスクの値に基づいてソースからのどのデータ要素が宛先において疎に記憶されるべきかを選択し、ソースの各選択されたデータ要素を、疎なデータ要素としてある宛先位置中に記憶し、前記宛先位置は、ソースの対応するデータ要素が記憶されるべきであることを示す各書き込みマスクビット位置に対応し、前記実行論理は、デコードされた圧縮命令を実行して、前記書き込みマスクの値に基づいてソースからのどのデータ要素が宛先において記憶されるべきかを選択し、ソースの選択されたデータ要素を、シーケンシャルにパックされたデータ要素として宛先中に記憶する、装置。請求項17記載の装置であって、さらに:前記第一または第二の書き込みマスクを記憶する16ビット書き込みマスクレジスタと;選択されたデータ要素を記憶する第一の512ビットレジスタとを有する、装置。請求項18記載の装置であって、さらに:前記展開および圧縮命令のためのソースとしてはたらく第二の512ビットレジスタを有する、装置。前記データ要素が、展開命令の実行中に16ビット値から32ビット値に上方変換される、請求項17記載の装置。SIMD技術の到来により、データ編成の選択はより重要になり、データに対して実行されるべき処理に注意深く基づくべきである。いくつかのアプリケーションでは、伝統的なデータ配置は最大パフォーマンスにつながらないことがある。アプリケーション開発者は、効率的な計算のために、種々のデータ配置およびデータセグメンテーション方針を探求することが推奨されてきた。これは所与のアプリケーションにおいてAoS、SoAまたさらにはハイブリッドSoAの組み合わせを使うことを意味しうる。本発明は、限定ではなく例として、付属の図面において示される。図面において、同様の参照符号は同様の要素を示す。以下の記述では、数多くの個別的詳細が記載されるが、本発明の諸実施形態がこうした個別的詳細な四で実施されうることは理解される。他方、よく知られた回路、構造および技法は、本記述の理解を埋没させないために詳細に示しはしなかった。本明細書における一つの実施形態、ある実施形態、例示的な実施形態などへの言及は、記載される実施形態が特定の特徴、構造または特性を含みうることを示すが、すべての実施形態が必ずその特定の特徴、構造または特性を含むとは限らない。さらに、そのような表現は必ずしも同じ実施形態を指すのではない。さらに、ある特定の特徴、構造または特性がある実施形態との関連で記述されているときは、明示的に記載されているか否かによらず、そのような特徴、構造または特性を、他の実施形態との関連で実施することは当業者の知識の範囲内であることを述べておく。展開および圧縮命令のいくつかの実施形態ならびにそのような命令を実行するために使用されうるシステム、アーキテクチャ、命令フォーマットなどの実施形態が以下で詳述される。展開および圧縮は、AoSおよびSoA配置の変換を含め、いくつかの異なる領域で有益である。たとえば、XYZWXYZWXYZW...XYZWというパターンからXXXXXXXXYYYYYYYYZZZZZZZZZZWWWWWWWWのたぐいのパターンに移行する。もう一つのそのような領域は行列転置である。長さ16のベクトルは要素の4×4の配列と見ることができる。展開命令により、四つの相続く要素の行M0、M1、M2およびM3がフェッチされ、配列を構築するのを保つためのマージを用いて4×4配列の行の一つに展開されることができるたとえばベクトル要素1,3,7および11。さらに、動的条件に基づいて相続く諸位置にメモリを記憶する汎用コードは、圧縮および展開命令から裨益する。たとえば、場合によっては、一般的でない条件をもつまれな要素を時間的メモリスペース中に圧縮することが有利である。それらを一緒にパックして記憶しておくことは、計算の密度を増す。それを行う一つの方法は、下記で詳述する圧縮の使用を通じてである。時間的なメモリスペースまたはFIFOを処理したのち、それらのまれな要素をもとの位置に復元するために展開が利用されてもよい。展開は、待ち行列中にパックされたデータを展開し直すためにも使われる。展開expand展開から始めると、展開の実行は、プロセッサに、ソースオペランドメモリまたはレジスタオペランドからの相続くデータ要素を宛先オペランド典型的にはレジスタオペランド中の疎なデータ要素位置に、書き込みマスクオペランドによって決定されるアクティブ要素に基づいて書き込ませる。さらに、ソースオペランドのデータ要素は、そのサイズおよびどのサイズのデータ要素が宛先レジスタ内にあるかに依存して上方変換されてもよい。たとえば、ソースオペランドがメモリオペランドであり、そのデータ要素が16ビットのサイズであり、宛先レジスタのデータ要素が32ビットであれば、宛先に記憶されるべきメモリオペランドのデータ要素は32ビットになるよう上方変換される。上方変換およびそれらがどのように命令フォーマット中にエンコードされるかについての例はのちに詳述する。この命令のフォーマットはVEXPANDPSzmm1k1zmm2Uである。ここで、zmm1およびzmm2はそれぞれ宛先およびソースベクトルレジスタオペランドであり128、256、512ビットレジスタなどのような、k1は書き込みマスクオペランドであり16ビットレジスタのような、Uはソースメモリ位置オペランドである。メモリから取得されるものは何であれ、当該メモリアドレスから始まる相続くビットの集合であり、宛先レジスタのサイズに依存していくつかのサイズ128、256、512ビットなどの一つであってもよい――そのサイズは一般に、宛先レジスタと同じサイズである。いくつかの実施形態では、書き込みマスクは異なるサイズでもある8ビット、32ビットなど。さらに、いくつかの実施形態では、書き込みマスクのすべてのビットが命令によって利用されるのではないたとえば、低位の8個の最下位ビットだけが使われる。もちろん、VEXPANDPSは命令のオペコードである。典型的には、各オペランドは命令において明示的に定義される。データ要素のサイズは、後述するWのようなデータ粒度ビットの指示の使用を通じてなど、命令のプレフィックスにおいて定義されてもよい。たいていの実施形態では、Wは、各データ要素が32ビットまたは64ビットであることを示す。データ要素が32ビットのサイズであり、ソースが512ビットのサイズであれば、ソース当たり16個のデータ要素がある。この命令は、通常、書き込みマスクされる。それにより、対応するビットが書き込みマスクレジスタ上記の例ではk1においてセットされている要素のみが宛先レジスタにおいて修正される。対応するビットが書き込みマスクレジスタにおいてクリアである宛先レジスタ中の要素は前の値を保持する。しかしながら、書き込みマスクを使わないときまたはすべて1にセットされた書き込みマスクを使うとき、この命令は、メモリ参照がキャッシュラインスプリットを生じる高い確信がある、より高いパフォーマンスのベクトルロードについて使われてもよい。展開命令の実行の一例が図1に示されている。この例では、ソースはメモリは、RAXレジスタ中に見出されるアドレスにおいてアドレッシングされる。もちろん、メモリアドレスは、他のレジスタ中に記憶されていても、あるいは命令中の直定数immediateとして見出されてもよい。この例での書き込みマスクは0x4DB1として示されている。1の値をもつ書き込みマスクの各ビット位置について、メモリソースからのデータ要素は宛先レジスタにおいて対応する位置のところに記憶される。たとえば、書き込みマスクの第一の位置たとえばk20が1であり、このことは、対応する宛先データ要素位置たとえば宛先レジスタの第一のデータ要素がそこに記憶されているソースメモリからのデータ要素をもつことを示す。この場合、それはRAXアドレスに関連付けられたデータ要素となる。マスクの次の三つのビットは0であり、これは宛先レジスタの対応するデータ要素がそのままにされることを示す図ではYとして示されている。書き込みマスク中の次の1の値は第五のビット位置たとえばk24にある。これは、RAXレジスタに関連付けられたデータ要素のあとのそれに連続するデータ要素が宛先レジスタの第五のデータ要素スロットに記憶されるべきであることを示す。残りの書き込みマスクビット位置は、メモリソースのどのさらなるデータ要素が宛先レジスタ内に記憶されるべきかを決定するために使用されるこの例では、8個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい。さらに、メモリソースからのデータ要素は、宛先における記憶に先立って16ビットの浮動小数点値から32ビット値に移行するなど、宛先のデータ要素サイズにフィットするよう上方変換されてもよい。上方変換およびそれらをいかにして命令フォーマット中にエンコードするかの例は上記で詳述した。さらに、いくつかの実施形態では、メモリオペランドの相続くデータ要素が展開に先立ってレジスタ中に保存される。図2は、レジスタオペランドをソースとする展開命令の実行の例を示している。先の図と同様に、この例での書き込みマスクは0x4DB1である。1の値をもつ書き込みマスクの各ビット位置について、レジスタソースからのデータ要素が対応する位置において宛先レジスタ内に記憶される。たとえば、書き込みマスクの第一の位置たとえばk20が1であり、このことは、対応する宛先データ要素位置たとえば宛先レジスタの第一のデータ要素がそこに記憶されているソースレジスタからのデータ要素をもつことを示す。この場合、それはソースレジスタの第一のデータ要素となる。マスクの次の三つのビットは0であり、これは宛先レジスタの対応するデータ要素がそのままにされることを示す図ではYとして示されている。書き込みマスク中の次の1の値は第五のビット位置たとえばk24にある。これは、ソースレジスタの第一の記憶されたデータのあとのそれに連続するデータ要素が宛先レジスタの第五のデータ要素スロットに記憶されるべきであることを示す。残りの書き込みマスクビット位置は、レジスタソースのどのさらなるデータ要素が宛先レジスタ内に記憶されるべきかを決定するために使用されるこの例では、8個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい。図3は、展開命令を実行するための擬似コードの例を示している。図4は、プロセッサ中の展開命令の使用のある実施形態を示している。宛先オペランド、ソースオペランドメモリまたはレジスタ、書き込みマスクおよびオフセットもし含まれていればをもつ展開命令が401においてフェッチされる。いくつかの実施形態では、宛先オペランドは512ビットのベクトルレジスタでありZMM1のような、書き込みマスクは16ビットのレジスタであるk1のような。メモリソースオペランドがある場合、それはアドレスもしくはその一部を記憶するレジスタまたはアドレスもしくはその一部を表す直定数であってもよい。典型的には、宛先およびソースオペランドは同じサイズである。いくつかの実施形態では、それらはみな512ビットのサイズである。しかしながら、他の実施形態では、それらはみな128または256ビットのような異なるサイズであってもよい。展開命令は403においてデコードされる。命令のフォーマットに依存して、多様なデータがこの段階で解釈されうる。上方変換もしくは他のデータ変換があるべきか、どのレジスタに書き込みをし、どのレジスタを取り出すか、メモリアドレスはソースからの何かなど。ソースオペランド値が405において取り出される/読み出される。たいていの実施形態では、メモリソース位置アドレスおよび相続くその後のアドレスおよびそのデータ要素に関連付けられたデータ要素がこの時点で読み出される。たとえば、キャッシュライン全体が読み出される。ソースがレジスタである諸実施形態では、ソースはこの時点で読み出される。実行されるべき何らかのデータ要素変換上方変換などがあれば、それは407において実行されてもよい。たとえば、メモリからの16ビットデータ要素は32ビットデータ要素に上方変換されてもよい。展開命令またはマイクロオペレーションのようなそのような命令を含む処理が409において実行リソースによって実行される。この実行により、ソースオペランドからのどの値が疎なデータ要素として宛先に記憶されるべきかが、書き込みマスクのアクティブな要素ビット位置に基づいて決定される。そのような決定の例を図1および図2に示した。ソースオペランドの適切なデータ要素が宛先レジスタ中に、書き込みマスクのアクティブな要素に対応する位置において、411で記憶される。ここでもまた、この例は図1および図2に示されている。409および411は別個に図示したが、いくつかの実施形態では、それらは前記命令の実行の一部として一緒に実行される。図5は、展開命令を処理する方法のある実施形態を示している。この実施形態では、処理401~407の全部ではないまでもいくつかが以前に実行されたことが想定される。だが、それらは以下に呈示する詳細を埋没させないよう、示されていない。たとえば、フェッチおよびデコードは示されていないし、オペランドソースおよび書き込みマスク取り出しも示されていない。501では、第一のビット位置における書き込みマスクが、対応するソース位置が宛先レジスタの対応するデータ要素位置に記憶されるべきかの決定がなされる。たとえば、第一の位置における書き込みマスクは、宛先レジスタの第一のデータ要素位置がソースからの値この場合、ソースオペランドを通じてアクセスされる相続くデータ要素のうち第一のデータ要素で上書きされるべきであることを示す1のような値をもつかこの第一のビット位置における書き込みマスクが宛先レジスタにおける変化があるべきであることを示さないときは、書き込みマスクにおける次のビット位置が評価され、何の変更もされない。第一のビット位置における書き込みマスクが宛先の第一のデータ要素位置における変化があるべきであることを示すときは、第一のソースデータ要素たとえば、メモリ位置またはソースレジスタの最下位のデータ要素が507において第一のデータ要素位置に記憶される。実装に依存して、505では、メモリデータ要素は、宛先のデータ要素サイズに変換される。これは、501の評価の前に行われていてもよい。宛先レジスタ中に書き込まれてもよい、ソースからのその後の連続するデータ要素が511で準備される。評価された書き込みマスク位置が書き込みマスクの最後であったかどうかまたは宛先のデータ要素位置のすべてが満たされたかどうかの判定が513においてなされる。もし真であれば、処理は終了である。真でなければ、515における書き込みマスク中の次のビット位置が評価されることになる。この評価は503で行われ、501の判定と同様であるが、書き込みマスクの第一のビット位置についてではない。判定が肯定であれば、データ要素は記憶などされる507、509および511。判定が否定であれば、宛先のデータ要素は505においてそのままにされる。さらに、この図および上記の記述はそれぞれの第一の位置が最下位であると考えているが、いくつかの実施形態では、第一の位置は最上位である。圧縮compress圧縮命令の実行は、プロセッサに、ソースオペランド典型的にはレジスタオペランドからのデータ要素を宛先オペランドメモリまたはレジスタオペランド中の相続く要素中に、書き込みマスクオペランドによって決定されるアクティブな要素に基づいて、記憶パックさせる。さらに、ソースオペランドのデータ要素は、そのサイズおよびソースがメモリである場合にどのサイズのデータ要素があるかに依存して、下方変換されてもよい。たとえば、メモリオペランドのデータ要素が16ビットのサイズであり、ソースレジスタのデータ要素が32ビットであれば、メモリに記憶されるべきレジスタのデータ要素は16ビットになるよう下方変換される。下方変換およびそれらがどのように命令フォーマット中にエンコードされるかについての例はのちに詳述する。圧縮の実行は、要素整列されたアドレスにおいて始まって論理的にマップされたバイト/語/倍長語のストリームを生成するものと見ることもできる。マスクによって無効にされる要素はストリームに加えられないので、ストリームの長さは書き込みマスクに依存する。圧縮は典型的には、疎なデータを待ち行列中に圧縮するために使われる。さらに、書き込みマスクを使わないときまたはすべて1にセットされた書き込みマスクを使うとき、この命令は、メモリ参照がキャッシュラインスプリットを生じる高い確信がある、より高いパフォーマンスのベクトルストアについて使われてもよい。この命令のフォーマットはVCOMPRESSPSzmm2memk1Dである。ここで、zmm1およびzmm2はそれぞれソースおよび宛先ベクトルレジスタオペランドであり128、246、512ビットレジスタのような、k1は書き込みマスクオペランドであり16ビットレジスタのような、memはメモリ位置である。前記命令に含まれるメモリオペランドについてのオフセットもあってもよい。メモリに記憶されるものは何であれ、当該メモリアドレスから始まる相続くビットの集合であり、いくつかのサイズ128、256、512ビットなどの一つであってもよい。いくつかの実施形態では、書き込みマスクは異なるサイズでもある8ビット、32ビットなど。さらに、いくつかの実施形態では、書き込みマスクのすべてのビットが命令によって利用されるのではないたとえば、低位の8個の最下位ビットだけが使われる。もちろん、VCOMPRESSPSは命令のオペコードである。典型的には、各オペランドは命令において明示的に定義される。データ要素のサイズは、本稿で記述するWのようなデータ粒度ビットの指示の使用を通じてなど、命令のプレフィックスにおいて定義されてもよい。たいていの実施形態では、Wは、各データ要素が32ビットまたは64ビットであることを示す。データ要素が32ビットのサイズであり、ソースが512ビットのサイズであれば、ソース当たり16個のデータ要素がある。プロセッサにおける圧縮命令の実行の一例が図6に示されている。この例では、宛先メモリは、RAXレジスタ中に見出されるものに関連付けられたアドレスにおいてアドレッシングされる。もちろん、メモリアドレスは、他のレジスタ中に記憶されていても、あるいは命令中の直定数immediateとして見出されてもよい。この例での書き込みマスクは0x4DB1である。書き込みマスクが1の値をもつ各インスタンスについて、ソースZMMレジスタのようなからのデータ要素はメモリ中に相続いて記憶パックされる。たとえば、書き込みマスクの第一の位置たとえばk20が1であり、このことは、対応するソースデータ要素位置たとえば宛先レジスタの第一のデータ要素がメモリ中に書き込まれるべきであることを示す。この場合、それはRAXアドレスに関連付けられたデータ要素として記憶される。マスクの次の三つのビットは0であり、これはソースレジスタの対応するデータ要素がメモリに記憶されないことを示す図ではYとして示されている。書き込みマスク中の次の1の値は第五のビット位置たとえばk24にある。これは、RAXレジスタに関連付けられたデータ要素のあとのそれに連続するデータ要素位置が、そこに記憶されているソースレジスタの第五のデータ要素スロットをもつべきであることを示す。残りの書き込みマスクビット位置は、ソースレジスタのどのさらなるデータ要素がメモリ内に記憶されるべきかを決定するために使用されるこの例では、8個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい。さらに、レジスタソースからのデータ要素は、記憶に先立って32ビット浮動小数点値から16ビット値に移行するなど、メモリのデータ要素サイズにフィットするよう下方変換されてもよい。図7は、プロセッサにおける圧縮命令の実行のもう一つの例を示している。この例では、宛先はレジスタである。この例での書き込みマスクはやはり0x4DB1である。書き込みマスクが1の値をもつ各インスタンスについて、ソースZMMレジスタのようなからのデータ要素が宛先レジスタ中に相続いて記憶パックされる。たとえば、書き込みマスクの第一の位置たとえばk20が1であり、このことは、対応するソースデータ要素位置たとえばソースレジスタの第一のデータ要素が宛先レジスタに書き込まれるべきであることを示す。この場合、それは宛先レジスタの第一のデータ要素として記憶される。マスクの次の三つのビットは0であり、これはソースレジスタの対応するデータ要素が宛先レジスタ中に記憶されないことを示す図ではYとして示されている。書き込みマスク中の次の1の値は第五のビット位置たとえばk24にある。これは、第一のデータ要素のあとのそれに連続するデータ要素位置がそこに記憶されるソースレジスタの第五のデータ要素スロットをもつべきであることを示す。残りの書き込みマスクビット位置は、ソースレジスタのどのさらなるデータ要素が宛先レジスタ内に記憶されるべきかを決定するために使用されるこの例では、8個の全データ要素が記憶されるが、書き込みマスクに依存してより少数のまたはより多数があってもよい。図8は、展開命令を実行するための擬似コードの例を示している。図9は、プロセッサ中の圧縮命令の使用のある実施形態を示している。宛先オペランド、ソースオペランドおよび書き込みマスクをもつ圧縮命令が901においてフェッチされる。いくつかの実施形態では、ソースオペランドは512ビットのベクトルレジスタでありZMM1のような、書き込みマスクは16ビットのレジスタであるk1のような。宛先は、レジスタ内にまたは直定数もしくはレジスタオペランドとして記憶されるメモリ位置であってもよい。さらに、圧縮命令はメモリアドレスについてのオフセットを含んでいてもよい。圧縮命令は903においてデコードされる。命令のフォーマットに依存して、多様なデータがこの段階で解釈されうる。下方変換があるべきか、どのレジスタを取り出すか、メモリアドレスは宛先オペランドからの何かそしてもしあればオフセットなど。ソースオペランド値が905において取り出される/読み出される。たとえば、ソースレジスタの少なくとも第一のデータ要素が読み出される。実行されるべき何らかのデータ要素変換下方変換などがあれば、それは907において実行されてもよい。たとえば、レジスタからの32ビットデータ要素は16ビットデータ要素に下方変換されてもよい。圧縮命令またはマイクロオペレーションのようなそのような命令を含む処理が909において実行リソースによって実行される。この実行により、ソースオペランドからのどの値がパックされたデータ要素として宛先にロードされるべきかが、書き込みマスクのアクティブな要素ビット位置に基づいて決定される。そのような解析の例を図6に示した。書き込みマスクのアクティブな要素に対応する、ソースオペランドの適切なデータ要素が、911で宛先中に記憶される。ここでもまた、これの例は図6および図7に示されている。909および911は別個に図示したが、いくつかの実施形態では、それらは前記命令の実行の一部として一緒に実行される。図10は、圧縮命令を処理する方法のある実施形態の例を示している。この実施形態では、処理901~907の全部ではないまでもいくつかが以前に実行されたことが想定される。だが、それらは以下に呈示する詳細を埋没させないよう、示されていない。たとえば、フェッチおよびデコードは示されていないし、オペランドソースおよび書き込みマスク取り出しも示されていない。1001では、第一のビット位置における書き込みマスクが、対応するソースデータ要素が宛先オペランドによって初期に示される宛先位置最低位の位置の中に記憶されるべきかの決定がなされる。たとえば、第一の位置におけるマスクは、ソースレジスタの第一のデータ要素位置がメモリ中に書き込まれるべきであることを示す1のような値をもつかこの第一のビット位置における書き込みマスクが宛先レジスタにおける変化があるべきであることを示さないときは第一のデータ要素はソースレジスタの第一のデータ要素によって不変のままであるべき、書き込みマスクにおける次のビット位置が評価されもしそのようなビット位置があれば、何の変更もされない。第一のビット位置における書き込みマスクが宛先の第一のデータ要素位置における変化があるべきであることを示すときは、1007において、ソースデータ要素が宛先の第一のデータ要素位置の中に記憶される。実装に依存して、1005では、ソースデータ要素は、宛先のデータ要素サイズに変換される。これは、1001の評価の前に行われていてもよい。書き込みされてもよいその後の連続する宛先位置が1009で準備される。評価された書き込みマスク位置が書き込みマスクの最後であったかどうかまたは宛先のデータ要素位置のすべてが満たされたかどうかの判定が1011においてなされる。もし真であれば、処理は終了である。真でなければ、1013における書き込みマスク中の次のビット位置が評価されることになる。この評価は1003で行われ、1001の判定と同様であるが、書き込みマスクの第一のビット位置についてではない。判定が肯定であれば、データ要素は記憶などされる1005、1007および1009。さらに、この図および上記の記述はそれぞれの第一の位置が最下位であると考えているが、いくつかの実施形態では、第一の位置は最上位である。上記で詳述した命令の実施形態は、以下で詳述する汎用ベクトルフレンドリー命令フォーマットにおいて具現されてもよい。他の実施形態では、そのようなフォーマットは利用されず、別の命令フォーマットが使われるが、書き込みマスクレジスタ、さまざまなデータ変換スウィズル、ブロードキャストなど、アドレッシングなどの以下の記述は一般に、上記の命令の実施形態の記述に適用可能である。さらに、例示的なシステム、アーキテクチャおよびパイプラインが下記で詳述される。上記の命令の実施形態はそのようなシステム、アーキテクチャおよびパイプライン上で実行されてもよいが、詳述されるものに限定されるものではない。ベクトルフレンドリー命令フォーマットは、ベクトル命令に好適な命令フォーマットであるたとえば、ベクトル演算に固有のある種のフィールドがある。ベクトルおよびスカラー処理の両方がベクトルフレンドリー命令フォーマットを通じてサポートされる実施形態が記述されるが、代替的な実施形態はベクトルフレンドリー命令フォーマットのベクトル処理のみを使う。例示的な汎用ベクトルフレンドリー命令フォーマット――図11A~B図11A~Bは、本発明の諸実施形態に基づく、汎用ベクトルフレンドリー命令フォーマットおよびその命令テンプレートを示すブロック図である。図11Aは、本発明の諸実施形態に基づく、汎用ベクトルフレンドリー命令フォーマットおよびそのクラスA命令テンプレートを示すブロック図であり、一方、図11Bは、本発明の諸実施形態に基づく、汎用ベクトルフレンドリー命令フォーマットおよびそのクラスB命令テンプレートを示すブロック図である。具体的には、汎用ベクトルフレンドリー命令フォーマット1100について、クラスAおよびクラスB命令テンプレートが定義されており、その両方は、メモリアクセスなし1105命令テンプレートおよびメモリアクセス1120命令テンプレートを含む。ベクトルフレンドリー命令フォーマットのコンテキストにおける汎用genericという用語は、いかなる特定の命令セットにも結び付けられていない命令フォーマットをいう。ベクトルフレンドリー命令フォーマット中の命令が、レジスタメモリアクセスなし1105命令テンプレートまたはレジスタ/メモリメモリアクセス1120命令テンプレートのいずれかをソースとするベクトルに対して作用する実施形態が記述されるが、本発明の代替的な実施形態はこれらの一つのみをサポートしてもよい。また、ベクトル命令フォーマット中にロードおよびストア命令がある本発明の実施形態が記述されるが、代替的な実施形態はその代わりにまたはそれに加えて、ベクトルをレジスタに入れたり出したりするたとえばメモリからレジスタに、レジスタからメモリに、レジスタ間の移動異なる命令フォーマット中の命令を有する。さらに、二つのクラスの命令テンプレートをサポートする本発明の実施形態が記述されるが、代替的な実施形態はこれらの一方のみまたは三つ以上をサポートしてもよい。ベクトルフレンドリー命令フォーマットが以下をサポートする本発明の実施形態が記述される:すなわち、64バイトのベクトルオペランド長またはサイズと32ビット4バイトもしくは64ビット8バイトのデータ要素幅またはサイズよって、64バイトのベクトルは16個の倍長語サイズの要素または代替的に8個の四倍長語サイズの要素からなる;64バイトのベクトルオペランド長またはサイズと16ビット2バイトもしくは8ビット1バイトのデータ要素幅またはサイズ;32バイトのベクトルオペランド長またはサイズと32ビット4バイト、64ビット8バイト、16ビット2バイトもしくは8ビット1バイトのデータ要素幅またはサイズ;ならびに16バイトのベクトルオペランド長またはサイズと32ビット4バイト、64ビット8バイト、16ビット2バイトもしくは8ビット1バイトのデータ要素幅またはサイズがサポートされる。だが、代替的な実施形態は、より多くの、より少数のおよび/または異なるベクトルオペランドサイズたとえば1156バイトのベクトルオペランドと、より多くの、より少数のおよび/または異なるデータ要素幅たとえば128ビット16バイトのデータ要素幅をサポートしてもよい。図11AにおけるクラスA命令テンプレートは:1メモリアクセスなし1105命令テンプレート内には、メモリアクセスなしのフル丸め制御型の処理1110命令テンプレートと、メモリアクセスなしのデータ変換型の処理1115命令テンプレートが示されており;2メモリアクセス1120命令テンプレート内には、メモリアクセスの時間的1125命令テンプレートと、メモリアクセスの非時間的1130命令テンプレートが示されている。図11BにおけるクラスB命令テンプレートは:1メモリアクセスなし1105命令テンプレート内には、メモリアクセスなしの書き込みマスク制御の部分丸め制御型処理1112命令テンプレートと、メモリアクセスなしの書き込みマスク制御、vsize型の処理1117命令テンプレートが示されており;2メモリアクセス1120命令テンプレート内には、メモリアクセスの書き込みマスク制御1127命令テンプレートが示されている。フォーマット汎用ベクトルフレンドリー命令フォーマット1100は、図11A~11Bに示されている順で下記に挙げる以下のフィールドを含む。フォーマットフィールド1140――このフィールド内の特定の値命令フォーマット識別子値はベクトルフレンドリー命令フォーマットを、よって命令ストリームにおけるベクトルフレンドリー命令フォーマット中の命令の発生を一意的に同定する。よって、フォーマットフィールド1140の内容は第一の命令フォーマット中の命令の発生を、他の命令フォーマット中の命令の発生から区別し、それによりベクトルフレンドリー命令フォーマットの、他の命令フォーマットをもつ命令セット中への導入を許容する。よって、このフィールドは、汎用ベクトルフレンドリー命令フォーマットのみをもつ命令セットについては必要とされないという意味で任意的である。基本処理フィールド1142――その内容は、種々の基本処理を区別する。本稿で後述するように、基本処理フィールド1142は、オペコードフィールドを含むおよび/またはオペコードフィールドの一部であってもよい。レジスタインデックスフィールド1144――その内容は、直接的にまたはアドレス生成を通じて、レジスタ内であれメモリ内であれソースおよび宛先オペランドの位置を指定する。これらは、PxQたとえば32×1312レジスタファイルからN個のレジスタを選択するのに十分な数のビットを含む。ある実施形態ではNは三つまでのソースおよび一つの宛先レジスタであってもよいが、代替的な実施形態はより多数またはより少数のソースおよび宛先レジスタをサポートしてもよいたとえば、二つまでのソースをサポートして該ソースの一つが宛先としても機能するのでもよいし、三つまでのソースをサポートして該ソースの一つが宛先としても機能するのでもよいし、二つまでのソースおよび一つの宛先をサポートしてもよい。ある実施形態ではP=32だが、代替的な実施形態はより多数またはより少数のレジスタたとえば16をサポートしてもよい。ある実施形態ではQ=1312ビットだが、代替的な実施形態はより多数またはより少数のビットをサポートしてもよいたとえば128、1024。修正子フィールド1146――その内容は、メモリアクセスを指定する汎用ベクトル命令フォーマット中の命令の発生を、メモリアクセスを指定しない命令の発生から区別する。すなわち、メモリアクセスなし1105命令テンプレートとメモリアクセス1120命令テンプレートとの間の区別をする。メモリアクセス処理は、メモリ階層構造に読み出しおよび/または書き込みをするいくつかの場合には、レジスタ内の値を使ってソースおよび/または宛先アドレスを指定する。一方、非メモリアクセス処理はそれをしないたとえばソースおよび宛先がレジスタである。ある実施形態ではこのフィールドはメモリアドレス計算を実行する三つの異なる方法の間の選択もするが、代替的な実施形態は、メモリアドレス計算を実行するためのより多数、より少数または異なる方法をサポートしてもよい。増強処理フィールド1150――その内容は、多様な異なる処理のうちどの一つが基本処理に加えて実行されるべきであるかを区別する。このフィールドはコンテキスト固有である。本発明のある実施形態では、このフィールドは、クラスフィールド1168、アルファフィールド1152およびベータフィールド1154に分割される。増強処理フィールドは、2個、3個または4個の命令ではなく、単一の命令において実行されるべき処理の共通グループを許容する。下記は、必要とされる命令の数を減らすために増強フィールド1150を使う命令その命名法は本稿でのちにより詳しく述べるのいくつかの例である。ここで、raxはアドレス生成に使われるべき基本baseポインタであり、はデータ操作フィールド本稿でのちにより詳しく述べるによって指定される変換処理を示す。スケールscaleフィールド1160――その内容は、メモリアドレス生成のためのインデックスindexフィールドの内容のスケーリングを許容するたとえば、2scale×indexbaseを使うアドレス生成について。変位displacementフィールド1162A――その内容は、メモリアドレス生成の一部として使われるたとえば、2scale×indexbasedisplacementを使うアドレス生成について。変位因子フィールド1162B変位因子フィールド1162Bのすぐ上に変位フィールド1162Aを並置しているのは、一方または他方のどちらかが使われることを示すことに注意――その内容はアドレス生成の一部として使われる;メモリアクセスのサイズNによってスケーリングされるべき変位因子を指定する――ここで、Nはメモリアクセスにおけるバイト数であるたとえば、2scale×indexbasedisplacementを使うアドレス生成について。冗長な低位ビットは無視され、よって、実効アドレスを計算する際に使うべき最終的な変位を生成するために、変位因子フィールドの内容はメモリオペランド全サイズNを乗算される。Nの値は、フルオペコードフィールド1174本稿で後述およびデータ操作フィールド1154C本稿で後述に基づいてランタイムでプロセッサハードウェアによって決定される。変位フィールド1162Aおよび変位因子フィールド1162Bは、メモリアクセスなし1105命令テンプレートについては使用されない、および/または異なる実施形態は両者のうち一方だけを実装したりいずれも実装しなかったりしてもよいという意味で任意的である。データ要素幅フィールド1164――その内容はいくつかのデータ要素幅のどの一つが使用されるべきかを区別するいくつかの実施形態では、すべての命令について;他の実施形態では、命令のうちいくつかのみについて。このフィールドは、一つのデータ要素幅だけがサポートされるおよび/または諸データ要素幅がオペコードの何らかの側面を使ってサポートされる場合には必要とされないという意味で任意的である。書き込みマスクフィールド1170――その内容は、データ要素位置ごとに、宛先ベクトルオペランド中のそのデータ要素位置が基本処理および増強処理の結果を反映するかどうかを制御する。クラスA命令テンプレートは併合書き込みマスクをサポートし、一方、クラスB命令テンプレートは併合mergingおよび零化zeroing書き込みマスクの両方をサポートする。併合するときは、ベクトルマスクは、宛先中の要素の任意の集合が、基本処理および増強処理によって指定される何らかの処理の実行中の更新から保護されることを許容する;他の一つの実施形態では、対応するマスクビットが0をもつところでは宛先の各要素の古い値を保持する。対照的に、零化するときは、ベクトルマスクは、宛先中の要素の任意の集合が、基本処理および増強処理によって指定される何らかの処理の実行中にゼロにされることを許容する;ある実施形態では、対応するマスクビットが0値をもつときには宛先の各要素が0に設定される。この機能のサブセットは、実行されている処理のベクトル長さすなわち、最初のものから最後のものへの、修正されている要素のスパンを制御する能力である;しかしながら、修正される要素が連続していることは必要ではない。このように、書き込みマスクフィールド1170は、ロード、ストア、算術、論理などを含む部分ベクトル処理を許容する。また、このマスキングは、障害抑制faultsuppressionのために使われることができるすなわち、障害を引き起こしうる/引き起こす何らかの処理の結果の受領を防止するために宛先のデータ要素位置をマスクすることによる――たとえばメモリ中のあるベクトルがページ境界をまたぎ、最初のページがページ障害pagefaultを引き起こすが、第二のページは引き起こさないとする。ページ障害は、最初のページにある当該ベクトルのすべてのデータ要素が書き込みマスクによってマスクされるならば無視できる。さらに、書き込みマスクは、ある型の条件付き文を含むベクトル化ループを許容する。書き込みマスクフィールド1170の内容がいくつかの書き込みマスクレジスタのうち使用されるべき書き込みマスクを含む一つを選択するよって書き込みマスクフィールド1170の書き込みマスクレジスタが間接的に実行されるべきマスキングを同定する本発明の実施形態が記述されているが、代替的な実施形態はその代わりにまたはそれに加えて、書き込みマスクフィールド1170の内容が直接的に実行されるべきマスキングを指定することを許容する。さらに、零化は次の場合にパフォーマンス改善を許容する。1宛先オペランドがソースを兼ねていない命令非三元命令ともいうに対してレジスタ名称変更が使われるとき。レジスタ名称変更パイプライン段の間、宛先はもはや暗黙的なソースではないからである現在の宛先レジスタからのデータ要素が名称変更された宛先レジスタにコピーされたり、あるいは何らかの仕方で処理とともに担持される必要がない。処理の結果ではないデータ要素任意のマスクされたデータ要素は零化されるので。2書き戻し段の間。ゼロが書き込まれるからである。直定数immediateフィールド1172――その内容は、直定数の指定を許容する。このフィールドは、直定数をサポートしない汎用ベクトルフレンドリーフォーマットの実装においては存在せず、直定数を使わない命令においては存在しないという意味で任意的である。命令テンプレートクラス選択クラスフィールド1168――その内容は命令の異なるクラスの間の区別をする。図2A~2Bを参照するに、このフィールドの内容は、クラスA命令とクラスB命令の間の選択をする。図11A~11Bでは、特定の値がフィールドに存在していることを示すために角丸の四角が使われているたとえば、それぞれ図11A~11Bにあるクラスフィールド1168についてのクラスA1168AおよびクラスB1168B。クラスAのメモリアクセスなし命令テンプレートクラスAの非メモリアクセス1105命令テンプレートの場合、アルファフィールド1152はRSフィールド1152Aとして解釈され、その内容は種々の増強処理型のどの一つが実行されるべきかを区別するたとえば、メモリアクセスなしの丸め型処理1110およびメモリアクセスなしのデータ変換型処理1115命令テンプレートについて、丸め1152A.1およびデータ変換1152A.2がそれぞれ指定されている。一方、ベータフィールド1154は、指定された型の処理のどれが実行されるべきかを区別する。図11では、特定の値が存在していることを示すために角丸のブロックが使われているたとえば、修正子フィールド1146内のメモリアクセスなし1146A;アルファフィールド1152/rsフィールド1152Aについての丸め1152A.1およびデータ変換1152A.2。メモリアクセスなし1105命令テンプレートでは、スケールフィールド1160、変位フィールド1162Aおよび変位スケールフィールド1162Bは存在しない。メモリアクセスなし命令テンプレート――フル丸め制御型動作メモリアクセスなしのフル丸め制御型処理1110命令テンプレートでは、ベータフィールド1154は丸め制御フィールド1154Aとして解釈され、その内容は、静的な丸めを指定する。本発明の記載される実施形態では、丸め制御フィールド1154Aは、全浮動小数点例外抑制SAEsuppressallfloatingpointexceptionsフィールド1156および丸め処理制御フィールド1158を含むが、代替的な実施形態は、これらの概念両方を同じフィールドにエンコードすること、あるいはこれらの概念/フィールドの一方または他方のみを有することをサポートしてもよいたとえば丸め処理制御フィールド1158のみを有していてもよい。SAEフィールド1156――その内容は、例外イベント報告を無効にするか否かを区別する。SAEフィールド1156の内容が抑制が有効にされていることを示すとき、所与の命令はいかなる種類の浮動小数点例外フラグも報告せず、いかなる浮動小数点例外ハンドラも立ち上げない。丸め処理制御フィールド1158――その内容は、一群の丸め処理たとえば、切り上げ、切り下げ、0に近いほうへの丸めおよび直近への丸めのうちどの一つを実行すべきかを区別する。こうして、丸め処理制御フィールド1158は、命令ごとに丸めモードの変更を許容し、これが必要なときにきわめて有用である。プロセッサが丸めモードを指定するための制御レジスタを含む本発明のある実施形態では、丸め処理制御フィールド1150の内容はレジスタ値をオーバーライドするそのような制御レジスタ上で保存‐修正‐復元を実行する必要なしに丸めモードを選ぶことができるのは有利である。メモリアクセスなし命令テンプレート――データ変換型処理メモリアクセスなしデータ変換型処理1115命令テンプレートでは、ベータフィールド1154はデータ変換フィールド1154Bとして解釈され、その内容はいくつかのデータ変換のうちどの一つが実行されるべきかを区別するたとえばデータ変換なし、スウィズル、ブロードキャスト。クラスAのメモリアクセス命令テンプレートクラスAのメモリアクセス1120命令テンプレートの場合、アルファフィールド1152は放逐ヒントevictionhintフィールド1152Bとして解釈され、その内容は放逐ヒントのどの一つが使用されるべきかを区別する図11Aでは、メモリアクセスの時間的1125命令テンプレートおよびメモリアクセスの非時間的1130命令テンプレートについて、時間的1152B.1および非時間的1152B.2がそれぞれ指定されている。一方、ベータフィールド1154は、データ操作フィールド1154Cとして解釈され、その内容はいくつかのデータ操作処理プリミティブとしても知られるのどの一つが実行されるべきかを区別するたとえば、操作なし;ブロードキャスト;ソースの上方変換;および宛先の下方変換。メモリアクセス1120命令テンプレートはスケールフィールド1160を含み、任意的に、変位フィールド1162Aまたは変位スケールフィールド1162Bを含む。ベクトルメモリ命令は、メモリからのベクトルロードおよびメモリへのベクトルストアを実行し、変換サポートがある。通常のベクトル命令と同様に、ベクトルメモリ命令は、データ要素ごとの仕方で、メモリから/メモリへデータを転送する。実際に転送される要素は、書き込みマスクとして選択されるベクトルマスクの内容によって指定される。図11Aでは、特定の値がフィールドに存在していることを示すために角丸の四角が使われているたとえば、修正子フィールド1146のためのメモリアクセス1146B;アルファフィールド1152/放逐ヒントフィールド1152Bについての時間的1152B.1および非時間的1152B.2。メモリアクセス命令テンプレート――時間的時間的temporalデータは、キャッシュすることから裨益するのに十分早く再使用される可能性が高いデータである。しかしながら、これはヒントであり、異なるプロセッサは、該ヒントを完全に無視することを含め、これを異なる仕方で実装してもよい。メモリアクセス命令テンプレート――非時間的非時間的nontemporalデータは、第一レベルのキャッシュにキャッシュすることから裨益するのに十分早く再使用される可能性が高くないデータであり、放逐のために優先されるべきである。しかしながら、これはヒントであり、異なるプロセッサは、該ヒントを完全に無視することを含め、これを異なる仕方で実装してもよい。クラスBの命令テンプレートクラスBの命令テンプレートの場合、アルファフィールド1152は書き込みマスク制御Zフィールド1152Cとして解釈され、その内容は、書き込みマスクフィールド1170によって制御される書き込みマスクが併合または零化のどちらであるべきかを区別する。クラスBのメモリアクセスなし命令テンプレートクラスBの非メモリアクセス1105命令テンプレートの場合、ベータフィールド1154の一部がRLフィールド1175Aとして解釈され、その内容は種々の増強処理型のどの一つが実行されるべきかを区別するたとえば、丸め1157A.1とベクトル長VSIZE1157A.2はそれぞれ、メモリアクセスなしの書き込みマスク制御の部分丸め制御型処理1112命令テンプレートと、メモリアクセスなしの書き込みマスク制御のVSIZE型処理1117命令テンプレートとについて指定される。一方、ベータフィールド1154の残りは、指定された型の処理のどれが実行されるべきかを区別する。図11では、特定の値が存在することを示すために、角丸のブロックが使われているたとえば、修正子フィールド1146内のメモリアクセスなし1146A;RLフィールド1157Aについての丸め1157A.1およびVSIZE1157A.2。メモリアクセスなし1105命令テンプレートでは、スケールフィールド1160、変位フィールド1162Aおよび変位スケールフィールド1162Bは存在しない。メモリアクセスなし命令テンプレート――書き込みマスク制御、部分丸め制御型処理メモリアクセスなしの書き込みマスク制御の部分丸め制御型処理1110命令テンプレートでは、ベータフィールド1154の残りは丸め処理フィールド1159Aとして解釈され、例外イベント報告が無効化される所与の命令がいかなる種類の浮動小数点例外フラグも報告せず、いかなる浮動小数点例外ハンドラも立ち上げない。丸め処理制御フィールド1159A――丸め処理制御フィールド1158と同様に、その内容は、一群の丸め処理のうちどの一つを実行すべきかたとえば、切り上げ、切り下げ、0に近いほうへの丸めおよび直近への丸めを区別する。こうして、丸め処理制御フィールド1159Aは、命令ごとに丸めモードの変更を許容し、これが必要なときにきわめて有用である。プロセッサが丸めモードを指定するための制御レジスタを含む本発明のある実施形態では、丸め処理制御フィールド1150の内容はレジスタ値をオーバーライドするそのような制御レジスタ上で保存‐修正‐復元を実行する必要なしに丸めモードを選ぶことができるのは有利である。メモリアクセスなし命令テンプレート――書き込みマスク制御、VSIZE型処理メモリアクセスなし書き込みマスク制御VSIZE型処理1117命令テンプレートでは、ベータフィールド1154の残りはベクトル長フィールド1159Bとして解釈され、その内容はいくつかのデータベクトル長のうちどの一つが実行対象とされるべきかを区別するたとえば128、1156または1312バイト。クラスBのメモリアクセス命令テンプレートクラスAのメモリアクセス1120命令テンプレートの場合、ベータフィールド1154の一部はブロードキャストフィールド1157Bとして解釈され、その内容はブロードキャスト型データ操作処理が実行されるべきか否かを区別する。一方、ベータフィールド1154の残りは、ベクトル長フィールド1159Bと解釈される。メモリアクセス1120命令テンプレートはスケールフィールド1160を含み、任意的に、変位フィールド1162Aまたは変位スケールフィールド1162Bを含む。フィールドに関する追加的コメント汎用ベクトルフレンドリー命令フォーマット1100に関し、フォーマットフィールド1140、基本処理フィールド1142およびデータ要素幅フィールド1164を含むフルオペコードフィールド1174が示されている。フルオペコードフィールド1174がこれらのフィールドのすべてを含む一つの実施形態が示されているが、フルオペコードフィールド1174は、そのすべてをサポートするのでない実施形態では、これらのフィールドの全部より少ないものを含む。増強処理フィールド1150、データ要素幅フィールド1164および書き込みマスクフィールド1170は、これらの機能が、汎用ベクトルフレンドリー命令フォーマットにおいて命令ごとに使用されることを許容する。書き込みマスクフィールドおよびデータ要素幅フィールドの組み合わせは、種々のデータ要素幅に基づいてマスクが適用されることを許容するという意味で、型のあるtyped命令を生成する。前記命令フォーマットは、種々のフィールドを他のフィールドの内容に基づいて種々の目的のために再利用するので、比較的少数のビットを必要とする。たとえば、一つのパースペクティブは、修正子フィールドの内容が、図11A~11B上のメモリアクセスなし1105命令テンプレートと、図11A~11B上のメモリアクセス11250命令テンプレートとの間の選択をするというものである;一方、クラスフィールド1168の内容は、それら非メモリアクセス1105命令テンプレート内では、図11Aの命令テンプレート1110/1115と図11Bの1112/1117との間で選択をする;また一方では、クラスフィールド1168の内容は、それらメモリアクセス1120命令テンプレート内では、図11Aの命令テンプレート1125/1130と図11Bの1127との間で選択をする。もう一つのパースペクティブからは、クラスフィールド1168の内容は、それぞれ図11Aおよび11BのクラスA命令テンプレートとクラスB命令テンプレートとの間で選択をする。一方、修正子フィールドの内容は、クラスA命令テンプレート内では、図11Aの命令テンプレート1105と1120との間の選択をする;また一方では、修正子フィールドの内容は、クラスB命令テンプレート内では、図11Bの命令テンプレート1105と1120との間の選択をする。クラスフィールドの内容がクラスA命令テンプレートを示す場合、修正子フィールド1146の内容がアルファフィールド1152の解釈を選ぶrsフィールド1152AとEHフィールド1152Bとの間で。関連した仕方で、修正子フィールド1146およびクラスフィールド1168の内容は、アルファフィールドがrsフィールド1152A、EHフィールド1152Bまたは書き込みマスク制御Zフィールド1152Cのどれとして解釈されるかを選ぶ。クラスおよび修正子フィールドがクラスAのメモリアクセスなし処理を示す場合には、増強フィールドのベータフィールドの解釈が、rsフィールドの内容に基づいて変わる;一方、クラスおよび修正子フィールドがクラスBのメモリアクセスなし処理を示す場合には、ベータフィールドの解釈はRLフィールドの内容に依存する。クラスおよび修正子フィールドがクラスAのメモリアクセス処理を示す場合には、増強フィールドのベータフィールドの解釈は、基本処理フィールドの内容に基づいて変わる;一方、クラスおよび修正子フィールドがクラスBのメモリアクセス処理を示す場合には、増強フィールドのベータフィールドの解釈は基本処理フィールドの内容に基づいて変わる。このように、基本処理フィールド、修正子フィールドおよび増強処理フィールドの組み合わせは、一層幅広い多様な増強処理が指定されることを許容する。クラスAおよびクラスB内で見出されるさまざまな命令テンプレートは種々の状況で有益である。クラスAは、零化書き込みマスクをするときに有用であり、より小さなベクトル長はパフォーマンス上の理由で望ましい。たとえば、零化は、名称変更が使われるときの偽の依存性を回避することを許容する。宛先と人工的に併合する必要がなくなるからである。もう一つの例として、ベクトル長制御は、ベクトルマスクを用いてより短いベクトルサイズをエミュレートするときに、ストア‐ロード転送問題を緩和する。クラスBは、1同時に丸めモード制御を使いながら、浮動小数点例外を許容するすなわちSAEフィールドの内容が否を示す;2上方変換、スウィズル、スワップおよび/または下方変換を使える;3グラフィックデータ型に対して作用する、ことが望ましいときに有用である。たとえば、上方変換、スウィズル、スワップ、下方変換およびグラフィックデータ型は、異なるフォーマットにあるソースと協働するときに必要とされる命令の数を減らす;もう一つの例として、例外を許容する能力は、指揮される丸めモードとの完全なIEEE準拠を提供する。例示的な個別的なベクトルフレンドリー命令フォーマット図12のA~Cは、本発明の諸実施形態に基づく、例示的な個別的なベクトルフレンドリー命令フォーマットを示している。図12のA~Cは、諸フィールドの位置、サイズ、解釈および順序およびそれらのフィールドのいくつかについては値を特定しているという意味で個別的である、個別的なベクトルフレンドリー命令フォーマット1200を示している。この個別的なベクトルフレンドリー命令フォーマット1200は、x86命令セットを拡張するために使われてもよく、よってフィールドのいくつかは既存のx86命令セットおよびその拡張において使われているものと同様または同じであるたとえばAVX。このフォーマットは、拡張を含む既存のx86命令セットのプレフィックスエンコードフィールド、リアルオペコードバイトフィールド、MODRMフィールド、SIBフィールド、変位フィールドおよび直定数フィールドと整合するままである。図12のA~Cからのフィールドが対応する図11のフィールドが示されている。本発明の実施形態は、例解目的のために汎用ベクトルフレンドリー命令フォーマット1100のコンテキストにおいて個別的なベクトルフレンドリー命令フォーマット1200を参照しつつ記述されるが、本発明は、請求項に記載される場合のほかは、この個別的なベクトルフレンドリー命令フォーマット1200に限定されない。たとえば、汎用ベクトルフレンドリー命令フォーマット1100は、さまざまなフィールドについて多様な可能なサイズを考えている。一方、個別的なベクトルフレンドリー命令フォーマット1200は特定のサイズのフィールドをもつものとして示されている。個別的な例として、データ要素幅フィールド1164が個別的なベクトルフレンドリー命令フォーマット1200における一ビットのフィールドとして示されているが、本発明はそれに限定されない汎用ベクトルフレンドリー命令フォーマット1100は、データ要素幅フィールド1164の他のサイズも考えている。フォーマット――図12A~C汎用ベクトルフレンドリー命令フォーマット1100は、図12A~Cに示される順で下記に挙げる以下のフィールドを含む。EVEXプレフィックスバイト0~3EVEXプレフィックス1202――これは四バイトの形でエンコードされる。フォーマットフィールド1140EVEXバイト0、ビット70――第一バイトEVEXバイト0はフォーマットフィールド1140であり、0x62本発明のある実施形態においてベクトルフレンドリー命令フォーマットを識別するために使われる一意的な値を含む。第二~第四バイトEVEXバイト1~3は、個別的な機能を提供するいくつかのビットフィールドを含む。REXフィールド1205EVEXバイト1、ビット75――これはEVEXRビットフィールドEVEXバイト1、ビット7――R、EVEXXビットフィールドEVEXバイト1、ビット6――Xおよび1157BEXバイト1、ビット5――Bからなる。EVEXR、EVEXXおよびEVEXBビットフィールドは、対応するVEXビットフィールドと同じ機能を提供し、1の補数の形を使ってエンコードされる。すなわち、ZMM0は1111Bとしてエンコードされ、ZMM15は0000Bとしてエンコードされる。命令の他のフィールドは、当技術分野で既知のように、レジスタインデックスの下位三ビットをエンコードするrrr、xxxおよびbbb。それにより、EVEXR、EVEXXおよびEVEXBを加えることによって、Rrrr、XxxxおよびBbbbが形成されうる。REXフィールド1210――これはREXフィールド1210の第一の部分であり、拡張された32レジスタセットの上位16または下位16のいずれかをエンコードするために使われるEVEXRビットフィールドEVEXバイト1、ビット4――Rである。本発明のある実施形態では、このビットは、下記に示される他とともに、よく知られたx8632ビットモードにおいて真のオペコードバイトが62であるBOUND命令から区別するためにビット反転したフォーマットで記憶される。だがMODRMフィールド後述においてMODフィールド中の値11を受け入れない。本発明の代替的な実施形態は、これおよびその他の下記で示されるビットを反転フォーマットで記憶しない。下位16個のレジスタをエンコードするために値1が使われる。換言すれば、EVEXR、EVEXRおよび他のフィールドからの他のRRRを組み合わせることによって、RRrrrが形成される。オペコードマップフィールド1215EVEXバイト1、ビット30――mmmm――その内容は含意される先頭オペコードバイトをエンコードする0F、0F38または0F3。データ要素幅フィールド1164EVEXバイト2、ビット7――W――これは記号EVEXWによって表される。EVEXWは、データ型の粒度サイズ32ビットデータ要素か64ビットデータ要素かを定義するために使われる。EVEXvvvv1220EVEXバイト2、ビット63――vvvv――EVEXvvvvの役割は以下のものを含む:1EVEXvvvvは、判定した1の補数形で指定されている第一のソースレジスタオペランドをエンコードし、二つ以上のソースオペランドをもつ命令について有効である;2EVEXvvvvは、ある種のベクトルシフトについて1の補数の形で指定されている宛先レジスタオペランドをエンコードする;または3EVEXvvvvはいかなるオペランドもエンコードせず、当該フィールドはリザーブされ、1111bを含むべきである。このように、EVEXvvvvフィールド1220は、反転された1の補数形で記憶されている第一のソースレジスタ指定子の下位四ビットをエンコードする。命令に依存して、指定子サイズを32レジスタに拡張するために、追加の異なるEVEXビットフィールドが使われる。EVEXU1168クラスフィールドEVEXバイト2、ビット2――U――EVEU=0であれば、それはクラスAまたはEVEXU0を示す;EVEXU=1であれば、それはクラスBまたはEVEXU1を示す。プレフィックスエンコードフィールド1225EVEXバイト2、ビット10――pp――これは、基本処理フィールドについての追加的な諸ビットを提供する。EVEXプレフィックスフォーマット中のレガシーSSE命令のためのサポートを提供することに加えて、これはSIMDプレフィックスをコンパクト化するという恩恵もあるSIMDプレフィックスを表すために一バイトを要求するのではなく、EVEXプレフィックスは2ビットしか要求しない。ある実施形態では、レガシーフォーマットおよびEVEXプレフィックスフォーマットの両方においてSIMDプレフィックス66H、F2H、F3Hを使うレガシーSSE命令をサポートするため、これらのレガシーSIMDプレフィックスがSIMDプレフィックスエンコードフィールド中にエンコードされ;ランタイムには、デコーダのPLAに与えられるのに先立ってレガシーSIMDプレフィックス中に展開されるこれにより、PLAは、修正なしでこれらのレガシー命令のレガシーおよびEVEXフォーマットの両方を実行できる。より新しい命令はEVEXプレフィックスエンコードフィールドの内容を直接、オペコード拡張として使うことができるが、ある種の実施形態は、整合性のために同様の仕方で展開するが、これらのレガシーSIMDプレフィックスによって異なる意味が指定されることを許容する。ある代替的な実施形態は、2ビットSIMDプレフィックスエンコードをサポートするようPLAを設計し直し、よって展開を必要としなくてもよい。アルファフィールド1152EVEXバイト3、ビット7――EH;EVEXEH、EVEXrs、EVEXRL、EVEX書き込みマスク制御およびEVEXNとしても知られる;αとも記す――先述したように、このフィールドはコンテキスト固有である。さらなる説明は本稿で後述する。ベータフィールド1154EVEXバイト3、ビット64――SSS;EVEXs20、EVEXr20、EVEXrr1、EVEXLL0、EVEXLLBとしても知られる;βββとも記す――先述したように、このフィールドはコンテキスト固有である。さらなる説明は本稿で後述する。REXフィールド1210――これはREXフィールドの残りであり、拡張された32レジスタセットの上位16または下位16のいずれかをエンコードするために使用されうるEVEXVビットフィールドEVEXバイト3、ビット3――Vである。このビットはビット反転したフォーマットで記憶される。1の値は下位16個のレジスタをエンコードするために使われる。換言すれば、EVEXV、EVEXvvvvを組み合わせることによって、VVVVVが形成される。書き込みマスクフィールド1170EVEXバイト3、ビット20――kkk――その内容は、先述したように、書き込みマスクレジスタ中のレジスタのインデックスを指定する。本発明のある実施形態では、特定の値EVEXkkk=000は特別な振る舞いをもち、その特定の命令について書き込みマスクが使用されないことを含意するこれは、すべて1に固定構成された書き込みマスクまたはマスクハードウェアをバイパスするハードウェアを使うことを含め、多様な仕方で実現されうる。リアルオペコードフィールド1230バイト4これはオペコードバイトとしても知られる。オペコードの一部はこのフィールドにおいて指定される。MODRMフィールド1240バイト5修正子フィールド1146MODRMMOD、ビット76――MODフィールド1242――先述したように、MODフィールド1242の内容は、メモリアクセスと非メモリアクセス処理の間の区別をする。このフィールドについては本稿でさらに後述する。MODRMregフィールド1244、ビット53――ModRMregフィールドの役割は、二つの状況に要約できる:ModRMregは宛先レジスタオペランドまたはソースレジスタオペランドのいずれかをエンコードする、あるいはModRMregはオペコード拡張として扱われ、いかなる命令オペランドをエンコードするためにも使用されない。MODRMrmフィールド1246、ビット20――ModRMrmフィールドの役割は、以下を含んでもよい:ModRMrmは、メモリアドレスを参照する命令オペランドをエンコードする、あるいはModRMrmは宛先レジスタオペランドまたはソースレジスタオペランドのいずれかをエンコードする。スケール、インデックス、ベースSIBバイトバイト6スケールフィールド1160SIBSS、ビット76――先述したように、スケールフィールド1160の内容はメモリアドレス生成のために使われる。このフィールドについては本稿でさらに後述する。SIBxxx1254ビット53およびSIBbbb1256ビット20――これらのフィールドの内容は、レジスタインデックスXxxxおよびBbbbに関して左記に参照された。変位バイト単数または複数バイト7またはバイト710変位フィールド1162Aバイト710――MODフィールド1242が10を含むとき、バイト710は変位フィールド1162Aであり、レガシーの32ビット変位disp32と同じはたらきをし、バイト粒度ではたらく。変位因子フィールド1162Bバイト7――MODフィールド1242が01を含むとき、バイト7は変位因子フィールド1162Bである。このフィールドの位置は、バイト粒度ではたらくレガシーのx86命令セットの8ビット変位disp8の位置と同じである。disp8は符号拡張されているので、-128から127バイトまでの間のオフセットしかアドレッシングできない。64バイトのキャッシュラインの点では、disp8は、四つの本当に有用な値-128、-64、0および64のみに設定されることができる8ビットを使う。より大きな範囲がしばしば必要とされるので、disp32が使われる。しかしながら、disp32は四バイトを必要とする。disp8およびdisp32と対照的に、変位因子フィールド1162Bはdisp8を解釈し直したものである;変位因子フィールド1162Bを使うとき、実際の変位は、変位因子フィールドの内容にメモリオペランドアクセスのサイズNを乗算したものによって決定される。この型の変位はdisp8Nと称される。これは、平均命令長を短縮する単一のバイトが変位のために使われるが、ずっと大きな範囲をもつ。そのような圧縮された変位は、有効変位がメモリアクセスの粒度の倍数であり、よってアドレスオフセットの冗長な低位ビットはエンコードされる必要がないという想定に基づいている。換言すれば、変位因子フィールド1162Bはレガシーx86命令セットの8ビット変位の代わりになる。このように、変位因子フィールド1162Bは、disp8はdisp8Nに加重されるという唯一の例外を除いて、x86命令セットの8ビット変位と同じようにエンコードされるよって、ModRMSIBのエンコード規則には何の変更もない。換言すれば、エンコード規則やエンコード長には何の変更もなく、変更は、ハードウェアによる変位値の解釈のみであるハードウェアは、メモリオペランドのサイズによって変位をスケーリングしてバイトごとのアドレスオフセットを得る必要がある。直定数immediate直定数フィールド1172は先述したように機能する。例示的なレジスタアーキテクチャ――図13図13は、本発明のある実施形態に基づくレジスタアーキテクチャ1300のブロック図である。レジスタアーキテクチャのレジスタファイルおよびレジスタを下記に挙げる。ベクトルレジスタファイル1310――図示した実施形態では、1312ビット幅の32個のベクトルレジスタがある。これらのレジスタはzmm0ないしzmm31と参照符号を付けられている。低位16個のzmmレジスタの低位1156個のビットは、レジスタymm016に重ねられる。低位16個のzmmレジスタの低位128ビットymmレジスタの低位128ビットはレジスタxmm015に重ねられる。個別的なベクトルフレンドリー命令フォーマット1200はこれらの重ねられたレジスタファイルに対して、下記のテーブルに示されるように作用する。換言すれば、ベクトル長フィールド1159Bは、最大長と一つまたは複数の他のより短い長さとの間で選択を行う。ここで、そのようなより短い長さのそれぞれは、先行する長さの半分の長さである。ベクトル長フィールド1159Bのない命令テンプレートは最大ベクトル長に対して作用する。さらに、ある実施形態では、この個別的ベクトルフレンドリー命令フォーマット1200のクラスB命令テンプレートは、パックされたまたはスカラーの単精度/倍精度浮動小数点データおよびパックされたまたはスカラーの整数データに作用する。スカラー演算は、zmmymmxmmレジスタ中の最低位のデータ要素位置に対して実行される処理である。より高位のデータ要素位置は、実施形態に依存して、当該命令前と同じままにされるか、0にされる。書き込みマスクレジスタ1315――図示した実施形態では、それぞれ64ビットのサイズの8個の書き込みマスクレジスタがあるk0ないしk7。先述したように、本発明のある実施形態では、ベクトルマスクレジスタk0は書き込みマスクとして使われることはできない。通常k0を示すエンコードが書き込みマスクについて使われるときは、0xFFFFの固定構成された書き込みマスクが選択されて、事実上、その命令について書き込みマスク処理を無効にする。マルチメディア拡張制御状態レジスタMXCSRMultimediaExtensionsControlStatusRegister1320――図示した実施形態では、この32ビットレジスタは、浮動小数点演算において使われる状態および制御ビットを提供する。汎用目的レジスタ1325――図示した実施形態では、メモリオペランドにアドレッシングするために既存のx86アドレッシングモードとともに使われる16個の64ビット汎用目的レジスタがある。これらのレジスタは名前RAX、RBX、RCX、RDX、RBP、RSI、RDI、RSPおよびR8ないしR15によって参照される。拡張されたフラグEFLAGSレジスタ1330――図示した実施形態では、この32ビットレジスタは多くの命令の結果を記録するために使われる。浮動小数点制御語FCWFloatingPointControlWordレジスタ1335および浮動小数点状態語FSWFloatingPointStatusWordレジスタ1340――図示した実施形態では、これらのレジスタはx87命令セット拡張によって、FCWの場合には丸めモード、例外マスクおよびフラグを設定し、FSWの場合には例外を追跡するために使用される。スカラー浮動小数点スタックレジスタファイルx87スタック1345この上にMMXのパックされた整数のフラットなレジスタファイル1350がエイリアスされている。――図示した実施形態では、x87スタックは、x87命令セット拡張を使って326480ビット浮動小数点データに対してスカラーの浮動小数点演算を実行するために使われる8要素のスタックである。一方、MMXレジスタは64ビットのパックされた整数データに対して処理を実行するとともに、MMXとXMMレジスタの間で実行されるいくつかの処理のためのオペランドを保持するために使われる。セグメントレジスタ1335――図示した実施形態では、セグメント分割されたアドレス生成のために使われるデータを記憶するために使われる6個の16ビットレジスタがある。RIPレジスタ1365――図示した実施形態では、この64ビットレジスタは命令ポインタを記憶する。本発明の代替的な実施形態は、より幅広いまたはより狭いレジスタを使ってもよい。さらに、本発明の代替的な実施形態はより多くの、より少数のまたは異なるレジスタファイルおよびレジスタを使ってもよい。例示的な順序内プロセッサアーキテクチャ――図14A~B図14A~Bは、例示的な順序内プロセッサアーキテクチャのブロック図を示している。これらの例示的な実施形態は、幅広のベクトルプロセッサVPUをもって増強される順序内CPUコアの複数のインスタンス化のまわりに設計される。コアは広帯域幅の相互接続網を通じて、e16tアプリケーションに依存して、何らかの固定機能論理、メモリIOインターフェースおよび他の必要なIO論理と通信する。たとえば、この実施形態のスタンドアローンGPUとしての実装は典型的にはPCIeバスを含む。図14Aは、本発明の諸実施形態に基づき、単一のCPUコアを、そのダイ上相互接続ネットワーク1402とともにまたそのレベル2L2キャッシュ1404のローカルサブセットともに、ブロック図として示している。命令デコーダ1400はx86命令セットを、個別的なベクトル命令フォーマット1200を含む拡張とともにサポートする。本発明のある実施形態では、設計を簡単にするためスカラーユニット1408およびベクトルユニット1410が別個のレジスタセットそれぞれスカラーレジスタ1412およびベクトルレジスタ1414を使っており、それらの間で転送されるデータはメモリに書き込まれて、その後レベル1L1キャッシュ1406から読み戻されるが、本発明の代替的な諸実施形態は、異なる手法を使ってもよいたとえば、単一レジスタセットを使うまたは書き込まれて読み戻されることなく二つのレジスタファイルの間でデータが転送されることを許容する通信経路を含めてもよい。L1キャッシュ1406は、スカラーおよびベクトルユニット中へのキャッシュメモリへの低遅延アクセスを許容する。ベクトルフレンドリー命令フォーマットにおけるロード処理命令と一緒に、これは、L1キャッシュ1406が、どこか拡張されたレジスタファイルのように扱われることができることを意味する。これは、特に放逐ヒントフィールド1152Bに関し、多くのアルゴリズムのパフォーマンスを著しく改善する。L2キャッシュ1404のローカルサブセットは、CPUコア当たり一つとなるよう別個の複数のローカルサブセットに分割されたグローバルなL2キャッシュの一部である。各CPUはL2キャッシュ1404の自らのローカルサブセットへの直接的なアクセス経路をもつ。CPUコアによって読まれるデータは、そのL2キャッシュサブセット1404に記憶され、迅速にアクセスされることができる。これは、他のCPUが自らのローカルなL2キャッシュサブセットにアクセスするのと並行してである。CPUコアによって書き込まれるデータは自らのL2キャッシュサブセット1404に記憶され、必要であれば他のサブセットからフラッシュflushされる。リングネットワークが、共有されるデータの一貫性を保証する。図14のBは、本発明の諸実施形態に基づく図14のAにおけるCPUコアの一部の分解図である。図14のBは、L1キャッシュ1404のL1データキャッシュ1406A部分と、ベクトルユニット1410およびベクトルレジスタ1414に関するさらなる詳細とを含んでいる。具体的には、ベクトルユニット1410は16幅のベクトル処理ユニットVPUvectorprocessingunitである16幅のALU1428参照。これは整数、単精度浮動小数点および倍精度浮動小数点の命令を実行する。VPUは、メモリ入力に対する、スウィズルユニット1420によるレジスタ入力のスウィズル、数値変換ユニット1422A~Bによる数値的な変換および複製ユニット1424による複製をサポートする。書き込みマスクレジスタ1426は、結果として得られるベクトル書き込みを予測することを許容する。レジスタデータは、たとえば行列乗算をサポートするために、多様な仕方でスウィズルされることができる。メモリからのデータはVPUレーンを横断して複製されることができる。これは、グラフィックおよび非グラフィックの並列データ処理の両方における共通の処理であり、これはキャッシュ効率を著しく高める。リングネットワークは、CPUコア、L2キャッシュおよび他の論理ブロックのようなエージェントがチップ内で互いと通信することを許容するよう双方向である。各リングデータ経路は一方向当たり1312ビットの幅である。例示的な順序外アーキテクチャ――図15図15は、本発明の諸実施形態に基づく、例示的な順序外アーキテクチャを示すブロック図である。具体的には、図15は、よく知られた例示的な順序外アーキテクチャを、ベクトルフレンドリー命令フォーマットおよびその実行を組み込むよう修正したものである。図15では、矢印は二つ以上のユニットの間の結合を表し、矢印の向きはそれらのユニット間でのデータの流れの向きを示す。図15は、実行エンジンユニット1510およびメモリユニット1515に結合されたフロントエンドユニット1505を含む。実行エンジンユニット1510はさらにメモリユニット1515に結合されている。フロントエンドユニット1505は、レベル2L2分岐予測ユニット1522に結合されたレベル1L1分岐予測ユニット1520を含む。L1およびL2分岐予測ユニット1520および1522はL1命令キャッシュユニット1524に結合されている。L1命令キャッシュユニット1524は、命令トランスレーションルックアサイドバッファTLBtranslationlookasidebuffer1526に結合され、TLB1526はさらに命令フェッチおよびプレデコードユニット1528に結合されている。命令フェッチおよびプレデコードユニット1528は命令待ち行列ユニット1530に結合されており、命令待ち行列ユニット1530はさらにデコードユニット1532に結合されている。デコードユニット1532は複雑なデコーダユニット1534と、三つの単純なデコーダユニット1536、1538、1540とを有する。デコードユニット1532は、マイクロコードROMユニット1542を含む。デコードユニット1532は、デコード段セクションにおいて上記で先述したように動作してもよい。L1命令キャッシュユニット1524はさらに、メモリユニット1515中のL2キャッシュユニット1548に結合される。命令TLBユニット1526はさらに、メモリユニット1515中の第二レベルTLBユニット1546に結合される。デコードユニット1532、マイクロコードROMユニット1542およびループストリーム検出器ユニット1544はそれぞれ、実行エンジンユニット1510中の名称変更/割り当て器ユニット1556に結合されている。実行エンジンユニット1510は、リタイアメントユニット1574および統一スケジューラユニット1558に結合されている前記名称変更/割り当て器ユニット1556を含む。リタイアメントユニット1574はさらに諸実行ユニット1560に結合され、並べ替えバッファユニット1578を含む。統一スケジューラユニット1558はさらに物理レジスタファイルユニット1576に結合され、該物理レジスタファイルユニット1576は諸実行ユニット1560に結合されている。物理レジスタファイルユニット1576は、ベクトルレジスタユニット1577A、書き込みマスクレジスタユニット1577Bおよびスカラーレジスタユニット1577Cを有し、これらのレジスタユニットが上記のベクトルレジスタ1310、ベクトルマスクレジスタ1315および汎用目的レジスタ1325を提供してもよい。物理レジスタファイルユニット1576は図示されていない追加的なレジスタファイルを含んでいてもよいたとえば、MMXパックされた整数フラットレジスタファイル1350上にエイリアスされたスカラー浮動小数点スタックレジスタファイル1345。諸実行ユニット1560は三つの混合スカラー兼ベクトルユニット1562、1564、1572;ロードユニット1566;アドレスストアユニット1568;データストアユニット1570を含む。ロードユニット1566、アドレスストアユニット1568およびデータストアユニット1570はそれぞれさらに、メモリユニット1515中のデータTLBユニット1552に結合される。メモリユニット1515は、データTLBユニット1552に結合された第二レベルのTLBユニット1546を含む。データTLBユニット1552はL1データキャッシュユニット1554に結合されている。L1データキャッシュユニット1554はさらにL2キャッシュユニット1548に結合されている。いくつかの実施形態では、L2キャッシュユニット1548はさらに、メモリユニット1515の内部および/または外部のL3およびより高次のキャッシュユニット1550に結合されている。例として、例示的な順序外アーキテクチャは、次のようにプロセスパイプラインを実装してもよい:1命令フェッチおよびプレデコードユニット1528がフェッチおよび長さデコード段を実行する;2デコードユニット1532がデコード段を実行する;3名称変更/割り当て器ユニット1556が割り当て段および名称変更段を実行する;4統一スケジューラ1558がスケジュール段を実行する;5物理レジスタファイルユニット1576、並べ替えバッファユニット1578およびメモリユニット1515がレジスタ読み出し/メモリ読み出し段を実行する;実行ユニット1560は実行/データ変換段を実行する;6メモリユニット1515および並べ替えバッファユニット1578が書き戻し/メモリ書き込み段を実行する;7リタイアメントユニット1574がROB読み出し段を実行する;8さまざまなユニットが実行ハンドリング段に関わってもよい;9リタイアメントユニット1574および物理レジスタファイルユニット1576がコミット段を実行する。例示的な単一コアおよび複数コアプロセッサ――図20図20は、本発明の諸実施形態に基づく統合されたメモリコントローラおよびグラフィクスをもつ単一コアプロセッサおよび複数コアプロセッサ2000のブロック図である。図119における実線の四角は単一コア2002A、システムエージェント2010、一つまたは複数のバスコントローラユニットの組2016をもつプロセッサ20000を示している。一方、破線の四角の任意的な付加は、複数のコア2002A~N、システムエージェントユニット2010内の一つまたは複数の統合されたメモリコントローラユニット2014の組および統合されたグラフィック論理2008をもつ代替的なプロセッサ2000を示す。メモリ階層構造は、コア内のキャッシュの一つまたは複数のレベル、一つまたは複数の共有されるキャッシュユニットの組2006および統合されたメモリコントローラユニットの組2014に結合された外部メモリ図示せずを含む。共有されるキャッシュユニットの組2006は、レベル2L2、レベル3L3、レベル4L4または他のレベルのキャッシュのような一つまたは複数の中間レベルキャッシュ、最終レベルキャッシュLLClastlevelcacheおよび/またはそれらの組み合わせを含んでいてもよい。ある実施形態では、リングベースの相互接続ユニット2012が統合されたグラフィック論理2008、共有されるキャッシュユニットの組2006およびシステムエージェントユニット2010を相互接続するが、代替的な実施形態は、そのようなユニットを相互接続するためのいくつもあるよく知られた技法を使用してもよい。いくつかの実施形態では、コア2002A~Nの一つまたは複数はマルチスレッド機能をもつ。システムエージェント2010は、コア2002A~Nを協調させ、動作させるコンポーネントを含む。システムエージェントユニット2010はたとえば、電力制御ユニットPCUpowercontrolunitおよび表示ユニットを含んでいてもよい。PCUは、コア2002A~Nおよび統合されたグラフィック論理2008の電力状態を制御するために必要とされる論理およびコンポーネントであってもよいし、そのような論理およびコンポーネントを含んでいてもよい。表示ユニットは一つまたは複数の外部接続されたディスプレイを駆動するためである。コア2002A~Nは、アーキテクチャおよび/または命令セットの点で均一であっても不均一であってもよい。たとえば、コア2002A~Nのいくつかが順序内たとえば、図14AおよびBに示したものようにであってもよく、一方、他のものは順序外たとえば図15に示したもののようにであってもよい。もう一つの例として、コア2002A~Nの二つ以上が同じ命令セットを実行する機能を有していてもよく、一方、他のものはその命令セットのサブセットのみまたは異なる命令セットを実行する機能を有していてもよい。前記コアの少なくとも一つは、本稿に記載されるベクトルフレンドリー命令フォーマットを実行する機能をもつ。プロセッサは、Core商標i3、i5、i7、2DuoおよびQuad、Xeon商標またはアイテニアム商標プロセッサのような汎用目的プロセッサであってもよい。これらは米国カリフォルニア州サンタクララのインテル社から発売されている。あるいはまた、プロセッサは別の会社からのものであってもよい。プロセッサは、ネットワーク通信プロセッサ、圧縮エンジン、グラフィクスプロセッサ、コプロセッサ、組み込みプロセッサなどといった特殊目的プロセッサであってもよい。プロセッサは一つまたは複数のチップ上に実装されてもよい。プロセッサ2000は、たとえばBiCMOS、CMOSまたはNMOSといったいくつもあるプロセス技術の任意のものを使って一つまたは複数の基板であってもよいし、および/または一つまたは複数の基板上に実装されてもよい。例示的なコンピュータシステムおよびプロセッサ――図16~図19図16~図18は、プロセッサ2000を含むのに好適な例示的なシステムであり、図19はコア2002の一つまたは複数を含みうる例示的なシステムオンチップSoCsystemonachipである。ラップトップ、デスクトップ、ハンドヘルドPC、携帯情報端末personaldigitalassistant、エンジニアリングワークステーション、サーバー、ネットワークデバイス、ネットワークハブ、スイッチ、組み込みプロセッサ、デジタル信号プロセッサDSP、グラフィクスデバイス、ビデオゲーム装置、セットトップボックス、マイクロコントローラ、携帯電話、携帯メディアプレーヤー、ハンドヘルドゲーム装置および他のさまざまな電子装置のための、当技術分野で知られている他のシステム設計および構成も好適である。一般に、本稿に開示されるプロセッサおよび/または他の実行論理を組み込むことのできる実に多様なシステムまたは電子装置が一般に好適である。ここで図16を参照するに、本発明のある実施形態に基づくシステム1600のブロック図が示されている。システム1600は、グラフィクスメモリコントローラハブGMCH1620に結合されている一つまたは複数のプロセッサ1610、1615を含んでいてもよい。追加的なプロセッサ1615の任意的な性質は図16では破線で表されている。各プロセッサ1610、1615はプロセッサ2000の何らかのバージョンであってもよい。しかしながら、統合されたグラフィクス論理および統合されたメモリ制御ユニットがプロセッサ1610、1615内に存在する可能性は低いことを注意しておくべきである。図16は、GMCH1620が、たとえば動的ランダムアクセスメモリDRAMであってもよいメモリ1640に結合されていてもよいことを示している。DRAMは少なくとも一つの実施形態については不揮発性キャッシュと関連付けられてもよい。GMCH1620はチップセットまたはチップセットの一部であってもよい。GMCH1620はプロセッサ1610、1615と通信し、プロセッサ1610、1615とメモリ1640との間の対話を制御してもよい。GMCH1620は、プロセッサ1610、1615とシステム1600の他の要素との間の加速されたバスインターフェースとしてもはたらいてもよい。少なくとも一つの実施形態については、GMCH1620はプロセッサ1610、1615と、フロントサイドバスFSBfrontsidebus1695のようなマルチドロップバスを介して通信する。さらに、GMCH1620はフラットパネルディスプレイのようなディスプレイ1645に結合される。GMCH1620は統合されたグラフィクスアクセラレータを含んでいてもよい。GMCH1620はさらに、入出力IOコントローラハブICH1650に結合される。ICH1650は、さまざまな周辺機器をシステム1600に結合するために使われてもよい。図16の実施形態においては、たとえば外部グラフィクス装置1660が示されている。これは、別の周辺機器1670とともにICH1650に結合されている離散的なグラフィクス装置であってもよい。あるいはまた、追加的なまたは異なるプロセッサもシステム1600内に存在していてもよい。たとえば、追加的なプロセッサ単数または複数1615は、プロセッサ1610と同じである追加的なプロセッサ、プロセッサ1610に対して不均一なまたは非対称な追加的なプロセッサ、アクセラレータたとえばグラフィクスアクセラレータまたはデジタル信号処理DSPユニットのような、フィールドプログラマブルゲートアレイまたは他の任意のプロセッサを含んでいてもよい。アーキテクチャ上、マイクロアーキテクチャ上、熱的、電力消費の特性などを含む一連の性能指数の点で、物理的なリソース1610、1615の間には多様な相違があることがある。これらの相違は、処理要素1610、1615の間の非対称および不均一性として事実上現れてもよい。少なくとも一つの実施形態について、さまざまな処理要素1610、1615は同じダイパッケージ上に存在していてもよい。ここで図17を参照するに、本発明のある実施形態に基づく第二のシステム1700のブロック図が示されている。図17に示されるように、マルチプロセッサシステム1700は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続1750を介して結合された第一のプロセッサ1700および第二のプロセッサ1780を含む。図17に示されるように、プロセッサ1770および1780のそれぞれは、プロセッサ2000の何らかのバージョンであってもよい。あるいはまた、プロセッサ1770、1780の一つまたは複数は、アクセラレータまたはフィールドプログラマブルゲートアレイのようなプロセッサ以外の要素であってもよい。プロセッサ1770、1780の二つのみをもって示しているが、本発明の範囲はそれに限定されないことは理解しておくべきである。他の実施形態では、一つまたは複数の追加的な処理要素が所与のプロセッサ内に存在していてもよい。プロセッサ1770はさらに、統合されたメモリコントローラハブIMC1772およびポイントツーポイントPPインターフェース1776および1778を含んでいてもよい。同様に、第二のプロセッサ1780はIMC1782およびPPインターフェース1786および1788を含んでいてもよい。プロセッサ1770、1780は、PtPインターフェース回路1778、1788を使ってポイントツーポイントPtPインターフェース1759を介してデータを交換してもよい。図17に示されるように、IMCの1772および1782はプロセッサをそれぞれのメモリ、すなわちメモリ1742およびメモリ1744に結合する。これらのメモリは、それぞれのプロセッサにローカルに取り付けられたメインメモリの一部であってもよい。プロセッサ1770、1780はそれぞれ、ポイントツーポイントインターフェース回路1776、1794、1786、1798を使って個別のPPインターフェース1752、1754を介してチップセット1790とデータを交換してもよい。チップセット1790は高パフォーマンスグラフィクスインターフェース1739を介して高パフォーマンスグラフィクス回路1738とデータを交換してもよい。共有されるキャッシュ図示せずは、両プロセッサの外側だがPP相互接続を介して両プロセッサと接続されているどちらかのプロセッサに含まれていてもよい。それにより、プロセッサが低電力モードに置かれる場合、一方または両方のプロセッサのローカルキャッシュ情報が共有キャッシュに記憶されてもよい。チップセット1790は、インターフェース1796を介して第一のバス1716に結合されていてもよい。ある実施形態では、第一のバス1716は周辺コンポーネント相互接続PCIバスまたはPCIエクスプレスのようなバスまたは他の第三世代のIO相互接続バスであってもよい。ただし、本発明の範囲はそれに限定されるものではない。図17に示されるように、さまざまなIO装置1714が、第一のバス1716を第二のバス1720に結合するバスブリッジ1718とともに第一のバス1716に結合されていてもよい。ある実施形態では、第二のバス1720は低ピンカウントLPCバスであってもよい。さまざまな装置が第二のバス1720に結合されていてもよい。そうしたさまざまな装置は、たとえば、キーボード/マウス1722、通信装置1726およびある実施形態ではコード1730を含んでいてもよいディスクドライブもしくは他の大容量記憶装置のようなデータ記憶ユニット1728を含む。さらに、オーディオIO1724が第二のバス1720に結合されていてもよい。他のアーキテクチャが可能であることを注意されたい。たとえば、図17のポイントツーポイントアーキテクチャの代わりに、システムはマルチドロップバスまたは他のそのようなアーキテクチャを実装してもよい。ここで図18を参照するに、本発明のある実施形態に基づく第三のシステム1800のブロック図が示されている。図17および図18における同様の要素は、同様の参照符号を帯びており、図17のある種の側面は、図18の他の側面を埋没させるのを避けるため、図18からは省略されている。図18は、処理要素1770、1782が統合されたメモリおよびそれぞれIO制御論理CL1772および1782を含んでいてもよいことを示している。少なくとも一つの実施形態について、CL1772、1782は、図119および17との関連で上述したもののようなメモリコントローラハブ論理IMCを含んでいてもよい。さらに、CL1772、1782はIO制御論理をも含んでいてもよい。図18は、メモリ1742、1744がCL1772、1782に結合されるだけでなく、IO装置1814も制御論理1772、1782に結合されていることを示している。レガシーIO装置1815はチップセット1790に結合されている。ここで図19を参照するに、本発明のある実施形態に基づくSoC1900のブロック図が示されている。図119における同様の要素は同様の参照符号を帯びている。また、破線にした四角は、より高度なSoCでは任意的な特徴である。図19では、相互接続ユニット単数または複数1902は:一つまたは複数のコア2002A~Nの組および共有されるキャッシュユニット単数または複数2006を含むアプリケーションプロセッサ1910と;システムエージェントユニット2010と;バスコントローラユニット単数または複数2016と;統合されたメモリコントローラユニット単数または複数2014と;統合されたグラフィクス論理2008、スチールおよび/またはビデオカメラ機能を提供する画像プロセッサ1924、ハードウェアオーディオ加速を提供するオーディオプロセッサ1926およびビデオエンコード/デコード加速を提供するビデオプロセッサ1928を含んでいてもよい一つまたは複数のメディアプロセッサの組と;静的ランダムアクセスメモリSRAMユニット1930;直接メモリアクセスDMAユニット1932と;一つまたは複数の外部ディスプレイに結合するための表示ユニット1940とに結合されている。本稿に開示される諸機構の諸実施形態は、ハードウェア、ソフトウェア、ファームウェアまたはそのような実装手法の組み合わせにおいて実装されてもよい。本発明の諸実施形態は、少なくとも一つのプロセッサ、記憶システム揮発性および不揮発性メモリおよび/または記憶要素を含む、少なくとも一つの入力装置および少なくとも一つの出力装置を有するプログラム可能なシステム上で実行されるコンピュータプログラムまたはプログラムコードとして実装されてもよい。プログラムコードは、本稿に記載される機能を実行し、出力情報を生成するよう入力データに適用されてもよい。出力情報は、既知の仕方で一つまたは複数の出力装置に適用されてもよい。本願の目的のためには、処理システムは、たとえばデジタル信号プロセッサDSP、マイクロコントローラ、特定用途向け集積回路ASICまたはマイクロプロセッサのようなプロセッサを有する任意のシステムを含む。プログラムコードは、処理システムと連絡するために高レベルの手続き型またはオブジェクト指向のプログラミング言語で実装されてもよい。プログラムコードはまた、望むならアセンブリまたは機械語で実装されてもよい。実際、本稿に記載される機構はいかなる特定のプログラミング言語にも範囲において限定されない。いずれにせよ、言語はコンパイルされるまたはインタープリットされる言語であってもよい。少なくとも一つの実施形態の一つまたは複数の側面は、プロセッサ内でのさまざまな論理を表し、機械によって読み込まれたときに該機械に本稿に記載される技法を実行する論理を作らせる、機械可読媒体上に記憶される代表的な命令によって実装されてもよい。IPコアとして知られるそのような表現は、有体の機械可読媒体上に記憶され、さまざまな顧客または製造設備に供給されて、実際に論理もしくはプロセッサをなす製造機械にロードされもよい。そのような機械可読記憶媒体は、限定なしに、機械またはデバイスによって製造または形成される物品の、非一時的な、有体の構成を含みうる。それには、ハードディスク、フロッピー登録商標ディスク、光ディスクコンパクトディスク読み出し専用メモリCDROM、書き換え可能型コンパクトディスクCDRWおよび光磁気ディスクを含む他の任意の型のディスク、読み出し専用メモリROM、動的ランダムアクセスメモリDRAM、静的ランダムアクセスメモリSRAM、消去可能型プログラマブル読み出し専用メモリEPROM、フラッシュメモリ、電気的に消去可能なプログラマブル読み出し専用メモリEEPROMといったランダムアクセスメモリRAMといった半導体デバイス、磁気カードもしくは光カードまたは電子的な命令を記憶するのに好適な他の任意の型の媒体といった記憶媒体が含まれる。よって、本発明の実施形態は、ベクトルフレンドリー命令フォーマットの命令を含む、または、本稿に記載される構造、回路、装置、プロセッサおよび/またはシステム特徴を定義するハードウェア記述言語HDLのような設計データを含む、非一時的な有体名機械可読媒体をも含む。そのような実施形態はプログラムプロダクトとも称されうる。いくつかの場合には、命令をソース命令セットからターゲット命令セットに変換するために命令変換器が使われてもよい。たとえば、命令変換器は、命令を、コアによって処理されるべき一つまたは複数の他の命令に翻訳たとえば静的バイナリー変換、動的コンパイルを含む動的バイナリー変換、変形、エミュレートまたは他の仕方で変換してもよい。命令変換器は、ソフトウェア、ハードウェア、ファームウェアまたはその組み合わせにおいて実装されてもよい。命令変換器は、プロセッサ上で、プロセッサ外でまたは部分的にプロセッサ上かつ部分的にプロセッサ外であってもよい。図21は、本発明の実施形態に基づく、ソース命令セット中のバイナリー命令をターゲット命令セット中のバイナリー命令に変換するソフトウェア命令変換器の使用を対照させるブロック図である。図示した実施形態では、命令変換器は、ソフトウェア命令変換器である。ただし、代替的に、命令変換器はソフトウェア、ファームウェア、ハードウェアまたはそのさまざまな組み合わせにおいて実装されてもよい。図21は、高レベル言語2102のプログラムがx86コンパイラー2104を使って、少なくとも一つのx86命令セットコアをもつプロセッサ2116によってネイティブに実行されうるx86バイナリーコード2106を生成するようコンパイルされうることを示しているコンパイルされた命令のいくつかはベクトルフレンドリー命令フォーマットであることが想定されている。少なくとも一つのx86命令セットコアをもつプロセッサ2116は、1インテルx86命令セットコアの命令セットの実質的な部分または2少なくとも一つのx86命令セットコアをもつインテルプロセッサ上で走るようターゲットを定められたアプリケーションまたは他のソフトウェアのオブジェクトコードバージョンを互換的に実行するまたは他の仕方で処理することによって、少なくとも一つのx86命令セットコアをもつインテルプロセッサと実質的に同じ機能を実行して、少なくとも一つのx86命令セットコアをもつインテルプロセッサと実質的に同じ結果を達成できる任意のプロセッサを表す。x86コンパイラー2104は、追加的なリンク処理とともにまたは追加的なリンク処理なしで少なくとも一つのx86命令セットコアをもつプロセッサ2116上で実行されることのできるx86バイナリーコード2106たとえばオブジェクトコードを生成するよう動作できるコンパイラーを表す。同様に。図21は、高レベル言語2102のプログラムが代替的な命令セットコンパイラー2018を使って、少なくとも一つのx86命令セットコアをもたないプロセッサ2114たとえば、米国カリフォルニア州サニーヴェールのMIPSテクノロジーズのMIPS命令セットを実行するおよび/または米国カリフォルニア州サニーヴェールのARMホールディングズのARM命令セットを実行するコアをもつプロセッサによってネイティブに実行されうる代替的な命令セットのバイナリーコード2110を生成するようコンパイルされうることを示している。命令変換器2112は、x86バイナリーコード2106を、x86命令セットコアをもたないプロセッサ2114によってネイティブに実行されうるコードに変換するために使われる。この変換されたコードは、代替的な命令セットバイナリーコード2110とは同じである可能性は高くない。というのも、これができる命令変換器は作るのが難しいからである。しかしながら、変換されたコードは、一般的な動作を達成し、代替的な命令セットからの命令から構成されることになる。このように、命令変換器2112は、エミュレーション、シミュレーションまたは他の何らかのプロセスを通じてx86命令セットプロセッサもしくはコアをもたないプロセッサまたは他の電子装置がx86バイナリーコード2106を実行することを許容するソフトウェア、ファームウェア、ハードウェアまたはその組み合わせを表す。本稿に開示されるベクトルフレンドリー命令フォーマットにおける命令単数または複数のある種の動作はハードウェアコンポーネントによって実行されてもよく、機械実行可能な命令において具現されてもよい。該命令は、該命令をプログラムされた回路または他のハードウェアコンポーネントが前記動作を実行することを引き起こす、または少なくともそのような結果を生じるために使われる。回路は、ほんの数例のみ挙げれば、汎用目的または特殊目的のプロセッサまたはロリ回路を含んでいてもよい。前記動作は、任意的に、ハードウェアとソフトウェアの組み合わせによって実行されてもよい。実行論理および/またはプロセッサは、機械命令または該機械命令から導出される一つまたは複数の制御信号に応答して、命令に指定された結果オペランドを記憶する個別的または特定の回路または他の論理を含んでいてもよい。たとえば、本稿に開示される命令の実施形態は、図16~図19のシステムの一つまたは複数において実行されてもよく、ベクトルフレンドリー命令フォーマットにおける命令の実施形態は前記システムにおいて実行されるべきプログラムコード中に記憶されてもよい。さらに、これらの図の処理要素は、本稿で詳述される詳細なパイプラインおよび/またはアーキテクチャたとえば順序内および順序外アーキテクチャの一つを利用してもよい。たとえば、順序内アーキテクチャのデコードユニットは、命令をデコードし、デコードされた命令をベクトルまたはスカラーユニットに渡すなどしてもよい。上記の記述は、本発明の好ましい実施形態を例解することを意図している。上記の議論から、特に成長が速く、さらなる進歩が簡単には予見されない技術分野においては、本発明が、付属の請求項およびその等価物の範囲内の本発明の原理から外れることなく、構成および詳細において、当業者によって修正されてもよいことも明白となるはずである。たとえば、ある方法の一つまたは複数の処理が組み合わされたり、さらに分解されたりしてもよい。代替的な実施形態ベクトルフレンドリー命令フォーマットをネイティブに実行する実施形態を記述してきたが、本発明の代替的な実施形態はベクトルフレンドリー命令フォーマットを、異なる命令セットを実行するプロセッサたとえば、米国カリフォルニア州サニーヴェールのMIPSテクノロジーズのMIPS命令セットを実行するプロセッサ、米国カリフォルニア州サニーヴェールのARMホールディングズのARM命令セットを実行するプロセッサ上で走るエミュレーション層を通じて実行してもよい。また、図面における流れ図は、本発明の諸実施形態によって実行される処理の特定の順序を示しているが、そのような順序が例示的であることは理解しておくべきであるたとえば、代替的な実施形態はそれらの処理を異なる順序で実行したり、ある種の処理を組み合わせたり、ある種の処理をオーバーラップさせたりしてもよい。上記の記述では、説明の目的のために、本発明の実施形態の十全な理解を与えるよう、数多くの個別的詳細を述べた。しかしながら、当業者には、こうした個別的詳細のいくつかがなくても、一つまたは複数の他の実施形態が実施されてもよいことは明白であろう。記載される特定の実施形態は、本発明を限定するためではなく、本発明の実施形態を例解するために与えられている。本発明の範囲は、上記で与えた個別的な例によって決定されるものではなく、下記の請求項によってのみ決定される。"