【文献】
Michael ABRASH,"A First Look at the Larrabee New Instructions (LRBni)",[online],米国,United Business Media,2009年 4月 1日,pages:1-16,[平成26年9月18日検索]インターネットURL:http://www.cs.cmu.edu/afs/cs/academic/class/15869-
(58)【調査した分野】(Int.Cl.,DB名)
最後のビット位置に関して、前記シフトされた連結された第1セットのデータ要素および第2セットのデータ要素のうち対応するデータ要素を前記宛て先の対応する位置に格納されるかを判断するべく評価された時点を判断し、前記命令を完了する段階をさらに備える、請求項10に記載の方法。
【発明を実施するための形態】
【0004】
以下の説明において、様々な特定的な詳細が示される。しかし、本願発明の実施形態は、これら特定的な詳細を用いずとも実施できる。他の例においては、この説明の理解を曖昧にすることを避けるべく、周知の回路、構造、および技術が詳細には示されていない。
【0005】
本明細書において「一実施形態」、「実施形態」、「例示的な実施形態」などについて言及した場合、説明される実施形態が特定の特徴、構造、または特性を含んでよいことを示し、全ての実施形態がそれら特定の特徴、構造、または特性を含んでいなければならないことを示すわけではない。さらに、そのような文言は必ずしも同じ実施形態を指すとは限らない。さらに、ある実施形態に関連して特定の特徴、構造、または特性を説明する場合、明示的に説明されていようとされてなかろうと、当業者であれば他の実施形態に関連してそれらの特徴、構造、または特性を実施することが出来る。
【0006】
上記で詳述したように、従来技術におけるデータ要素のアラインメントにおいては、いくつかの所望されない結果を招くことになるいくつかの処理が必要となる。例えば、いくつかの状況においては、ユーザが特定のニーモニックにより潜在的にミスアライメントとなる動作を指定し(VMOVUPSのような命令を実行するなど)、キャッシュラインのスプリットが常に生成されるものと仮定すると、実行が遅くなる、他の状況においては、ハードウェアが実行時にキャッシュのミスアライメントを検出させられ、パフォーマンスにとって不利な条件がさらに生じる。
【0007】
アライメント
ベクトルアライメント(VALIGN)命令の実施形態、および、それらの命令を実行するのに用いられ得るシステム、アーキテクチャ、命令形式などの実施形態を以下に詳述する。ベクトルアライメント命令は実行されるとプロセッサに対し、当該命令の第1ソースオペランドおよび第2ソースオペランドのデータ要素を連結させ、当該命令のオフセット値(即値)に基づき当該連結されたデータからのデータ要素を右にシフトさせ、シフトされ連結されたデータの要素のうち1以上を宛て先ベクトルレジスタに格納させる。いくつかの実施形態において、宛て先ベクトルレジスタに格納されるべき、シフトされ連結されたデータの要素は、書き込みマスクレジスタの対応するビットに基づき判断される。第1ソースおよび第2ソースは共にレジスタ、メモリ位置、またはこれらの組み合わせであり得る。いくつかの実施形態において、ソースがメモリ位置である場合、そのデータは、連結される前にレジスタにロードされる。
【0008】
この命令の一例は「VALIGND zmm1{k1},zmm2,zmm3/m512,offset」である。ここでzmm1、zmm2、zmm3はベクトルレジスタ(128、256、512ビットのレジスタなど)であり、m512は、レジスタまたは即値に格納される512ビットのメモリオペランドであり、k1は、書き込みマスクオペランド(上記にて詳述した16ビットのレジスタなど)であり、オフセットは、以下に詳述するように連結された後にソースのデータ要素の32ビットの要素でのアライメントを命令する即値(例えば、8ビットの即値)である。メモリから読み取られるあらゆるものが、メモリアドレスから開始する連続するビットの集合であり、宛て先レジスタのサイズに応じていくつかのサイズ(128、256、512ビットなど)のうちいずれかのサイズを有し得る。サイズは一般的に、宛て先レジスタと同じサイズである。いくつかの実施形態において、書き込みマスクは異なるサイズ(8ビット、32ビットなど)であり得る加えて、いくつかの実施形態において、書き込みマスクの全てのビットが命令によって用いられるわけではない(例えば、最下位の8つのビットのみが用いられる)。当然ながら、VALIGNDは命令のオペコードである。典型的には、各オペランドは命令において明示的に定められている。データ要素のサイズは、例えば上述したように「W」などのデータ粒度ビットの表示を用いることにより、命令の「プレフィックス」に定められていてもよい。多くの実施形態において、Wは、各データ要素が32または64ビットであることを示す。データ要素のサイズが32ビットであり、ソースのサイズが512ビットである場合、ソースあたり16のデータ要素がある。
【0009】
図1は、アライメント命令の例示的な実行を示す。この例において、それぞれ16のデータ要素を有する2つのソースがある。多くの場合、これらのソースのうちの1つはレジスタである(この例に関しては、ソース1 101が16の32ビットのデータ要素を有するZMMレジスタなどの512ビットのレジスタとして扱われるが、XMMおよびYMMレジスタ、16または64ビットのデータ要素など他のデータ要素およびレジスタサイズが用いられ得る)。他方のソース103は、レジスタまたはメモリ位置である(この例において、ソース2が他方のソースである)。第2ソースがメモリ位置である場合、多くの実施形態において、第2ソースは、ソースの連結の前に、一時レジスタに入れられる。加えて、メモリ位置のデータ要素は、第2ソースが一時レジスタに入れられる前に、データ変換が行われてもよい。データ101は、A〜Pまでの16のデータ要素を含み、データ103は、Q〜AFまでの16のデータ要素を含む。
【0010】
示されるように、レジスタ101、103からのデータは、第1データレジスタ101の最下位のデータ要素であるAと連結され、連結されたデータ105の最下位のデータ要素が生成される。第1データレジスタ101の最上位のデータ要素の直ぐ後には第2データレジスタ103の最下位のデータ要素Qが続く。連結されたデータ要素105は3(命令の即値)だけシフト(アライメント)され、これにより、オリジナルのソースからのデータ要素D〜AFが残ることになる。当然ながら、ビッグエンディアン形式も用いることが出来、データ要素は対応する即値の分だけ左にシフトされてもよい。
【0011】
このシフトされ連結されたデータの最下位のデータ要素(D〜S)は、命令の宛て先レジスタにデータ要素スロットがなくなるまで、宛て先レジスタへ書き込まれる。他の実施形態において、最上位のデータ要素は宛て先レジスタ107に書き込まれる。この書き込みは並行して、または順番に行われてもよい。示されるように、宛て先レジスタにはこのサイズの16のデータ要素を格納するためのスペースしかないので、16の最下位のデータ要素が宛て先レジスタに書き込まれる。
【0012】
図2は、同じソースデータおよびシフトを示すが、連結されシフトされたデータ105のうちどの最下位のデータ要素が宛て先レジスタに書き込まれるべきかを、マスクレジスタ201のコンテンツを用いて判断している。いくつかの実施形態において、このマスクレジスタは上記にて詳述した「k」マスクレジスタ(k1〜k7)である。マスクレジスタは0x878Bとして示されている。「1」の値を格納するマスクの各位置に関して、連結されシフトされたデータ105からの対応するデータ要素が、宛て先レジスタの対応する位置に書き込まれる。例えば、マスクの位置「0」は「1」なので、シフトされ連結されたデータ要素の対応するデータ要素位置「0」の値Dが、宛て先レジスタの位置「0」に格納される。「0」の値を格納するマスクの各位置に関して、宛て先レジスタの対応するデータ要素は上書きされない。例えば、位置「2」においてマスクは「0」なので、宛て先は値Fで上書きされずにDCのままである。「1」を特定のデータ要素位置が宛て先レジスタに書き込まれるべきであることを示す表示として示し、「0」をそのような書き込みを行うべきでないことを示す表示として示しているが、他の実施形態においては逆の方式を用いてもよい。加えて、いくつかの実施形態においては、最上位のデータ要素が書き込まれ、最下位のデータ要素が書き込まれない。
【0013】
図3は、同じソースデータおよびシフトを示すが、連結されシフトされたデータ105のうちどの最下位のデータ要素が宛て先レジスタに書き込まれるべきかを、マスクレジスタのコンテンツを用いて判断している。このインスタンスにおいて、マスクビットのうち全てが用いられるわけではない。このことは、例えばいくつかの実施形態において、64ビットのデータ要素、512ビットのレジスタの場合に起こり得る。
【0014】
図4は、プロセッサでアライメント命令を実行することにより2つのソースからのデータをアライメントし、宛て先位置に当該アライメントされたデータを格納するための方法の実施形態を示す。401において、宛て先オペランドと、第1ソースオペランドと、第2ソースオペランドと、オフセット値(即値)と、マスクオペランドとを含むアライメント命令が受信される。宛て先オペランドおよびソースオペランドのサイズは同じである。いくつかの実施形態において、これらのサイズは全て512ビットである。しかし、他の実施形態においては、これらのサイズは全て、128または256ビットなどの異なるサイズであってもよい。典型的には、宛て先オペランドおよび第1ソースオペランドは共に、上述したようにベクトルレジスタ(XMM、YMM、またはZMM)のうち1つなどのレジスタである。第2ソースオペランドはレジスタまたはメモリオペランドであってよい。いくつかの実施形態において、オフセットは8ビットの即値である。受信されるマスクは、上述した「k」個の書き込みマスクのうちの1つであってよく、または、いくつかの実施形態においては、異なるレジスタまたはメモリ位置である。
【0015】
403においてアライメント命令がデコードされる。命令形式に応じて、この段階では、例えばデータ変換が行われるかどうか、どのレジスタに書き込みどのレジスタから読み取るか、メモリソースオペランドと、含まれる場合にはオフセットとを用いてどのメモリアドレスにアクセスするか、などに関して様々なデータがインタープリトされ得る。
【0016】
405において、ソースオペランド値が読み取られる。両方のソースがレジスタである場合、これらのレジスタが読み取られる。ソースオペランドのうち1つまたは両方がメモリオペランドである場合、当該オペランドに関連付けられたデータ要素が読み取られる。いくつかの実施形態において、メモリからのデータ要素は一時レジスタに格納される。
【0017】
データ要素の変換(アップコンバート、ブロードキャスト、スウィズルなど)が実施される場合には、407において実施されてもよい。例えば、メモリからの16ビットのデータ要素が32ビットのデータ要素にアップコンバートされてもよく、または、データ要素が1つのパターンから他のパターンへ(例えば、XYZW XYZW XYZW … XYZWからXXXXXXXX YYYYYYYY ZZZZZZZZZZ WWWWWWWWへ)スウィズルされてもよい。
【0018】
409において、アライメント命令が実行される。この命令の実行により、第1ソースオペランドおよび第2ソースオペランドのデータ要素の連結、および、当該連結されたデータからのこれらのデータ要素のオフセットに基づいた右へのシフトが行われる。いくつかの実施形態において、第1ソースオペランドのデータ要素は、連結されたデータ要素のうち最下位である。411において、書き込みマスクレジスタの対応するビットに応じて、シフトされ連結されたデータのいくつかのデータ要素が宛て先ベクトルレジスタに格納されてもよい。409と411とは別々に示されているが、いくつかの実施形態においてはそれらの動作は、命令の実行の一部として共に実行されてもよい。
【0019】
1つのタイプの実行環境について説明してきたが、詳述されるインオーダーおよびアウトオブオード環境などの他の環境に適合させることも容易に可能である。
【0020】
図5は、アライメント命令を処理するための方法の実施形態を示す。本実施形態においては、動作401〜407のうち全てではないにしてもいくつかが事前に実施されているものと仮定されており、それらの動作は、以下に示す詳細を曖昧にすることを避けるべく示されていない。例えば、フェッチおよびデコードは示されてない。オペランド(ソースおよび書き込みマスク)の読み取りも以下には示されていない。
【0021】
501において、第1ソースおよび第2ソースのデータ要素が連結され、動作を行うためのより大きな「ベクトル」が作成される。例えば、
図1および2に示すように、第1ソースのデータ要素が下位のビットとなり、第2ソースのデータ要素が最上位のビットとなるよう、2つのソースレジスタからのデータが連結される。いくつかの実施形態において、このより大きなベクトルは1024ビットである。明らかではあるが、より大きなベクトルのサイズは、ソースのサイズに応じて決められる。
【0022】
503において、第1ソースおよび第2ソースの連結されたデータは、命令の即値によって定められるデータ要素の量だけ、右にシフトされる。
【0023】
505において、書き込みマスクを用いるべきかの判断が行われる。この動作は、基盤となるハードウェアアーキテクチャの実装に応じて行われる任意選択的なものである。例えば、上記にて詳述したk0のような書き込みマスクレジスタが用いられる場合、用いられるマスクはない。命令に含まれる場合、k0は書き込みが行われ得るレジスタであるが、このことは、マスキングを実施しないことを意味する(言い換えると、全てのビット位置において実質的に「1」の値である)。当然ながら、他のアーキテクチャにおいて、他のレジスタと同様に書き込みマスクを用いることも出来る。
【0024】
書き込みマスクが用いられる場合、507において、書き込みマスクの各ビット位置に関し、第1ソースおよび第2ソースのシフトされ連結されたデータの対応する要素が宛て先レジスタの対応する位置に格納されるべきであるとビット位置が示すかの判断が行われる。いくつかの実施形態において、この判断、および/または後の格納511は順番に行われる。つまり、第1ビット位置(つまりk1[0])に関して判断が行われ、その後、続くビット位置の評価が行われる。他の実施形態において、この判断、および/または後の格納511は並行して行われる。つまり、全てのビット位置(つまり、k1[0]〜k1[15])に関してこの判断が同時に行われる。加えて、評価されるビット位置の数は、データ要素のサイズに応じて異なる。例えば、32ビットのデータ要素を含む512ビットの実装では、この判断において、マスクの16のビットが評価される。64ビットのデータ要素を含む512ビットの実装において、マスクの8ビットのみが評価される。このインスタンスにおいて、典型的には、最下位の8つのビットが評価されるが、他の方式を用いてもよい。
【0025】
宛て先レジスタの対応するデータ要素位置に書き込みを行うべきではないことをマスクのあるビット位置が示す場合、509において、宛て先レジスタには書き込みが行われない。シフトされ連結されたデータの対応するデータが宛て先レジスタの対応するデータ要素位置に書き込まれるべきであることをマスクのあるビット位置が示す場合、511において、当該対応するデータ要素が、宛て先レジスタの対応するデータ要素位置に書き込まれる。この格納の例は
図2に示す。マスクが用いられない場合、511において、シフトされ連結されたデータの対応するデータ要素のうち全てが、宛て先レジスタの対応するデータ要素位置に格納される。この格納の例は
図1に示す。
【0026】
確認されるマスクの最後のビット位置が評価されると、または書き込みが行われ得る宛て先のデータ要素位置の全ての書き込みが行われると、方法は終了する。
【0027】
図6は、アライメント命令を処理するための方法の実施形態を示す。本実施形態においては、動作401〜407のうち全てではないにしてもいくつかが事前に実施されているものと仮定されており、それらの動作は、以下に示す詳細を曖昧にすることを避けるべく示されていない。例えば、フェッチおよびデコードは示されてない。オペランド(ソースおよび書き込みマスク)の読み取りも以下には示されていない。
【0028】
601において、第1ソースおよび第2ソースのデータ要素が連結され、動作を行うためのより大きな「ベクトル」が作成される。例えば、
図1および2に示すように、第1ソースのデータ要素が下位のビットとなり、第2ソースのデータ要素が最上位のデータ要素となるよう、2つのソースレジスタからのデータが連結される。いくつかの実施形態において、このより大きなベクトルは1024ビットである。明らかではあるが、より大きなベクトルのサイズは、ソースのサイズに応じて決められる。
【0029】
603において、第1ソースおよび第2ソースの連結されたデータは、命令の即値によって定められるデータ要素の量だけ、右にシフトされる。
【0030】
書き込みマスクを用いるべきかの判断が行われてもよい(図示せず)。上記にて詳述したように、この動作は、基盤となるハードウェアアーキテクチャの実装に応じて行われる任意選択的なものである。マスクが用いられない場合、605または607においていずれの確認も行われない。
【0031】
605において、書き込みマスクの第1ビット位置に関し、第1ソースおよび第2ソースのシフトされ連結されたデータの対応する要素が宛て先レジスタの対応する位置に格納されるべきであるとビット位置が示すかの判断が行われる。 宛て先レジスタの対応するデータ要素位置に書き込みを行うべきではないことをマスクの第1ビット位置が示す場合、609において、宛て先レジスタには書き込みが行われない。シフトされ連結されたデータの対応するデータが宛て先レジスタの対応するデータ要素位置に書き込まれるべきであることをマスクの第1ビット位置が示す場合、611において、当該対応するデータが宛て先レジスタの対応するデータ要素位置に書き込まれる。この格納の例は
図2に示す。
【0032】
613において、評価された書き込みマスク位置が書き込みマスクの最後であるか、または宛て先のデータ要素位置のうち全てが埋められたかの判断が行われる。もし最後であるか、埋められていれば、動作が終了する。後者のケースは、例えば、データ要素のサイズの64ビットであり、宛て先が512ビットであり、書き込みマスクが16ビットを有する場合に起こり得る。このインスタンスにおいては、書き込みマスクの8ビットのみが必要となる。
【0033】
もし最後でないか、埋められてなければ、615において、書き込みマスクの次のビット位置が評価されその値の判断が行われる。607において、ビット位置が評価され、その他の動作が実行される。 確認されるマスクの最後のビット位置が評価されると、または書き込みが行われ得る宛て先のデータ要素位置の全ての書き込みが行われると、方法は終了する。
【0034】
図7は、擬似コードでアライメント命令を処理するための方法の実施形態を示す。
【0035】
典型的にはプログラムは順番にメモリにアクセスする。例えば、参照(a)は、アドレス@に位置する第1の512ビットのベクトルでアクセスされ、参照(b)は、@+64バイトに位置する第2の512ビットのベクトルでアクセスされ、参照(c)は、@+128バイトに位置する第1の512ビットのベクトルでアクセスされる。このシナリオにおいて、参照(a)はキャッシュラインA、Bを跨いで位置しており、参照(b)は、キャッシュラインB、Cを跨いで位置しており、参照(c)は、キャッシュラインC、Dを跨いで位置している。通常のロードを用いると、キャッシュラインB、Cは2度アクセスされ、キャッシュラインのアクセス数は全体で6(3x2)となる。
【0036】
一般的には、キャッシュラインのポートはレジスタのポートよりもより貴重なリソースである。上述したアライメント命令の実施形態は、キャッシュラインではなくレジスタに対しデータアライメントを実施するので、当該アライメント命令は性能の向上を実現する。アライメント命令を用いると、キャッシュラインデータはレジスタ内でアライメントされ、典型的には、1つのベクトル参照毎に新たにフェッチされるキャッシュラインは1つのみである。各キャッシュラインは2度アクセスされるのではなく1度のみ読み取られ、キャッシュのアクセスと同時にアライメントされ、スループットは、ただ1つのメモリポートを用いつつもサイクルごとに1つのベクトルとなる。
【0037】
上記にて詳述した命令の実施形態は、下記に詳述する「汎用のベクトルフレンドリーな命令形式」で実施することも可能である。他の実施形態において、そのような形式は用いられず、他の命令形式が用いられる。しかし、書き込みマスクレジスタ、様々なデータ変換(スウィズル、ブロードキャストなど)、アドレシングなどに関する以下の説明は一般的に、上述した命令の実施形態の説明に関して適用可能である。加えて、例示的なシステム、アーキテクチャ、およびパイプラインについて以下で詳述する。上述した命令の実施形態は、そのようなシステム、アーキテクチャ、およびパイプラインで実行することが出来るが、それら詳述されるものに限定されない。
【0038】
ベクトルフレンドリーな命令形式は、ベクトル命令に適した命令形式(例えば、ベクトル演算に特定のいくつかのフィールドがある)である。ベクトルフレンドリーな命令形式によってベクトル演算およびスカラ演算の両方がサポートされる実施形態を説明するが、代替的な実施形態においては、ベクトルフレンドリーな命令形式のベクトル演算のみが用いられる。
【0039】
例示的な汎用のベクトルフレンドリーな命令形式−
図8Aおよび
図8B
図8Aおよび
図8Bは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、および、その命令テンプレートを示すブロック図である。
図8Aは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、および、そのクラスAの命令テンプレートを示すブロック図である。
図8Bは、本願発明の実施形態に係る、汎用のベクトルフレンドリーな命令形式、および、そのクラスB命令テンプレートを示すブロック図である。詳細には、汎用のベクトルフレンドリーな命令形式800には、それぞれが非メモリアクセス805命令テンプレートおよびメモリアクセス820命令テンプレートを含む、クラスAおよびクラスB命令テンプレートが定義されている。ベクトルフレンドリーな命令形式という表現において汎用という用語は、命令形式が何ら特定の命令セットに関連付けられていないことを意味する。ベクトルフレンドリーな命令形式の命令が、レジスタ(非メモリアクセス805命令テンプレート)およびレジスタ/メモリ(メモリアクセス820命令テンプレート)のうちいずれかをソースとするベクトルに対して動作する実施形態を説明するが、本願発明の代替的な実施形態においては、これらのうちいずれか一方だけをサポートしてもよい。また、ベクトル命令形式のロード命令および格納命令がある本願発明の実施形態を説明するが、代替的な実施形態においては、代わりに、或いは、加えて、レジスタへ、またはレジスタからベクトル(例えば、メモリからレジスタへ、レジスタからメモリへ、レジスタ間で、など)を移動させる異なる命令形式の命令が用いられる。さらに、2つのクラスの命令テンプレートをサポートする本願発明の実施形態を説明するが、代替的な実施形態においては、これらのうち一方のみ、または3つ以上がサポートされる。
【0040】
ベクトルフレンドリーな命令形式が、32ビット(4バイト)、または、64ビット(8バイト)のデータ要素幅(またはサイズ)を有する64バイトベクトルオペランドの長さ(またはサイズ)(よって、64バイトのベクトルは、16倍長語サイズの要素、および8カッド語サイズの要素のいずれかからなる)、16ビット(2バイト)、または、8ビット(1バイト)のデータ要素幅(またはサイズ)を有する64バイトベクトルオペランドの長さ(またはサイズ)、32ビット(4バイト)、64ビット(8バイト)、16ビット(2バイト)、または、8ビット(1バイト)のデータ要素幅(またはサイズ)を有する32バイトベクトルオペランドの長さ(またはサイズ)、並びに、32ビット(4バイト)、64ビット(8バイト)、16ビット(2バイト)、または、8ビット(1バイト)のデータ要素幅(またはサイズ)を有する16バイトベクトルオペランドの長さ(またはサイズ)をサポートする実施形態について説明するが、代替的な実施形態においては、より大きな、より小さな、または異なるデータ要素幅(例えば、128ビット(16バイト)データ要素幅)を有するより大きな、より小さな、および/または異なるベクトルオペランドサイズ(例えば856バイトのベクトルオペランド)がサポートされてもよい。
【0041】
図8AのクラスAの命令テンプレートは、1)非メモリアクセス805命令テンプレート内に、非メモリアクセス完全丸め制御タイプ演算810命令テンプレート、および非メモリアクセスデータ変換タイプ演算815命令テンプレート、並びに2)メモリアクセス820命令テンプレート内に、メモリアクセス一時的825命令テンプレート、およびメモリアクセス非一時的830命令テンプレートを含む。
図8BのクラスB命令テンプレートは、1)非メモリアクセス805命令テンプレート内に、非メモリアクセス書き込みマスク制御部分的丸め制御タイプ演算812命令テンプレート、および非メモリアクセス書き込みマスク制御vsizeタイプ演算817命令テンプレート、並びに、2)メモリアクセス820命令テンプレート内に、メモリアクセス書き込みマスク制御827命令テンプレートを含む。
【0042】
形式
汎用のベクトルフレンドリーな命令形式800は、
図8Aおよび
図8Bに示される順序で、以下に列挙するフィールドを含む。
【0043】
形式フィールド840−このフィールド内の特定値(命令形式識別値)は一意的に、ベクトルフレンドリーな命令形式を識別し、よって、命令ストリーム内のベクトルフレンドリーな命令形式の命令の発生を識別する。よって、形式フィールド840のコンテンツは、第1命令形式の命令の発生を他の命令形式の命令の発生と区別し、これにより、ベクトルフレンドリーな命令形式を他の命令形式の命令セットへ導入することが可能となる。このため、このフィールドは、汎用のベクトルフレンドリーな命令形式のみを有する命令には必要でないので任意的なものである。
【0044】
ベース動作フィールド842−このコンテンツは、複数の異なるベース動作を区別する。本明細書で以下に説明するように、ベース動作フィールド842は、オペコードフィールドを含む、および/または、その一部であってもよい。
【0045】
レジスタインデックスフィールド844−このコンテンツは、直接的またはアドレス生成を介して、レジスタまたはメモリなどの、ソースおよび宛て先オペランドの位置を特定する。これらは、PxQ(例えば32x1012)レジスタファイルからN個のレジスタを選択するのに十分な数のビットを含む。一実施形態において、Nは3つのソースおよび1つの宛て先レジスタであるが、代替的な実施形態においては、より多く、またはより少ない宛て先レジスタをサポートしてもよい(例えば最大2つのソースをサポートしてもよく、これらソースのうち1つは宛て先としても動作する。例えば最大3つのソースをサポートしてもよく、これらソースのうち1つは宛て先としても動作する。例えば2つのソースおよび1つの宛て先をサポートしてもよい)。一実施形態においてはP=32であるが、代替的な実施形態においては、より多く、またはより少ないレジスタ(例えば16の)をサポートしてもよい。一実施形態においてはQ=1012ビットであるが、代替的な実施形態においては、より多く、またはより少ないビット(例えば128、1024の)をサポートしてもよい。
【0046】
修飾子フィールド846−このコンテンツは、メモリアクセスを特定する汎用ベクトル命令形式の命令の発生を、メモリアクセスを特定しない命令形式の命令の発生と区別する。つまり、非メモリアクセス805命令テンプレートとメモリアクセス820命令テンプレートとを区別する。メモリアクセス動作は、メモリ階層から読み出す、および/または、メモリ階層へ書き込む(場合によっては、レジスタ内の値を用いて、ソース、および/または宛て先アドレスを特定する。他方、メモリアクセス動作はこれらを特定しない(例えば、ソースおよび宛て先がレジスタである)。一実施形態においては、このフィールドはメモリアドレス計算を実行する3つの異なる方法からの選択も行うが、代替的な実施形態においては、メモリアドレス計算を実行するより多くの、より少ない、または複数の異なる方法をサポートする。
【0047】
オーグメンテーション動作フィールド850−このコンテンツは、ベース動作に加えて、様々な複数の異なる動作のうち何れを実行するかを区別する。このフィールドはコンテキスト特有のものである。本願発明の一実施形態において、このフィールドは、クラスフィールド868、アルファフィールド852、および、ベータフィールド854に分けられる。オーグメンテーション動作フィールドは、複数の動作からなる共通のグループを、2、3、または4つの命令ではなく1つの命令で実行することを可能とする。以下に示すのは、必要な命令の数を減らすべくオーグメンテーションフィールド850を用いる命令(用いられる用語の意味は、本明細書において以下により詳細に説明する)のいくつかの例である。
【0048】
【表1】
ここで、[rax]はアドレス生成に用いられるベースポインタであり、{}は、データ操作フィールド(本明細書で以下により詳細に説明する)で特定される変換動作を示す。
【0049】
スケールフィールド860−このコンテンツは、メモリアドレスの生成のための(例えば、2スケール*インデックス+ベースを用いるアドレス生成のための)インデックスフィールドのコンテンツのスケーリングを可能とする。
【0050】
変位フィールド862A−このコンテンツは、メモリアドレスの生成(例えば、2スケール*インデックス+ベース+変位を用いるアドレス生成)の一部として用いられる。
【0051】
変位係数フィールド862B(いずれか一方のみが用いられるので、変位フィールド862Aは変位係数フィールド862Bの直接上に配置されている)−このコンテンツは、アドレス生成の一部として用いられる。このフィールドは、メモリアクセス(N)のサイズでスケーリングされる変位係数を特定する。ここでNは、メモリアクセス(例えば、2スケール*インデックス+ベース+スケーリングされた変位を用いるアドレス生成のための)のバイト数である。冗長下位ビットは無視され、よって、有効アドレスを計算するのに用いられる最終的な変位を生成すべく変位係数フィールドのコンテンツがメモリオペランドの合計サイズ(N)で乗算される。Nの値は、本明細書で以下に説明するようにフルオペコードフィールド874(本明細書で以下に説明する)およびデータ操作フィールド854Cに基づいて実行時にプロセッサハードウェアによって求められる。変位フィールド862Aおよび変位係数フィールド862Bは非メモリアクセス805命令テンプレートには用いられない、並びに/或いは、異なる実施形態においては、いずれか一方が用いられる、または両方とも用いられないので、任意的なものである。
【0052】
データ要素幅フィールド864−このコンテンツは、複数のデータ要素幅のうち何れを用いるかを区別する(いくつかの実施形態においては全ての命令に関して。他の実施形態においては、命令のうちいくつかに関して)。1つだけのデータ要素幅がサポートされる場合、および/または、オペコードのいくつかの態様を用いて複数のデータ要素幅がサポートされる場合には必要ではないので、このフィールドは任意的なものである。
【0053】
書き込みマスクフィールド870−このコンテンツは、データ要素の位置毎に、宛て先ベクトルオペランドのデータ要素の位置に、ベース動作およびオーグメンテーション動作の結果を反映させるかどうかを制御する。クラスA命令テンプレートはマージング−書き込みマスキングをサポートし、クラスB命令テンプレートは、マージング−書き込みマスキング、およびゼロ化−書き込みマスキングの両方をサポートする。マージングの際、ベクトルマスクにより、宛て先の複数の要素からなる何れのセットも、(ベース動作およびオーグメンテーション動作によって特定される)いかなる動作の実行の間であっても、更新から保護をすることが可能となる。他の一実施形態において、対応するマスクのビットが0を有する宛て先の各要素の古い値が維持される。対照的に、ベクトルマスクをゼロ化する際、(ベース動作およびオーグメンテーション動作によって特定される)いかなる動作の実行の間であっても、宛て先の複数の要素からなる何れのセットもゼロにされる。一実施形態において、対応するマスクのビットが0の値を有する宛て先の要素が0に設定される。この機能のサブセットは、実行されている動作のベクトル長さを制御する能力である(つまり、最初から最後までの、修飾されている要素のスパン)。しかし、修飾される要素が連続している必要はない。よって、書き込みマスクフィールド870は、ロード、格納、アリズマティック、ロジカルなどを含む部分的なベクトル演算を可能とする。また、このマスキングをフォルトの抑制に用いることも出来る(つまり、フォルトを引き起こし得る/引き起こす何らかの動作の結果の受信を避けるべく宛て先のデータ要素の位置をマスキングすることにより。例えば、メモリのベクトルがページの境界を跨ぎ、2番目のページではなく最初のページがページフォルトを引き起こすことを想定すると、最初のページにあるベクトルの全てのデータ要素が書き込みマスクによりマスキングされた場合、ページフォルトを無視することが出来る)。さらに、書き込みマスクは、特定のタイプの条件ステートメントを含む「ベクトル化ループ」を可能とする。書き込みマスクフィールド870のコンテンツが、用いられる書き込みマスクを含む複数の書き込みマスクレジスタのうちの1つを選択する(よって、書き込みマスクフィールド870のコンテンツが、実行されるマスキングを間接的に識別する)本願発明の実施形態を説明したが、代替的な実施形態においては、代替的または追加的に、書き込みマスクフィールド870のコンテンツが、実行されるマスキングを直接的に特定することを可能とする。さらに、1)レジスタリネームパイプライン段階において宛て先は明示的なソースではないので、宛て先オペランドがソースでもない命令(ノンターナリ命令とも呼ばれる)に対してレジスタリネーミングが用いられる(動作の結果でない何れかデータ要素(何れのマスキングされたデータ要素)もゼロにされるので、現在の宛て先レジスタからのデータ要素の何れもリネームされた宛て先レジスタにコピーされる必要がなく、或いは、何らかの方法で動作を実行される必要がない)場合、および、2)ゼロが書き込まれているので、書き戻し段階の間、ゼロ化により性能の向上が可能となる。
【0054】
即値フィールド872−このコンテンツは即値の特定を可能とする。即値をサポートしない汎用のベクトルフレンドリーな形式の実施では存在せず、即値を用いない命令では存在しないので、このフィールドは任意的なものである。
【0055】
命令テンプレートクラス選択
クラスフィールド868−このコンテンツは複数の異なるクラスの命令を区別する。
図2を参照すると、このフィールドのコンテンツは、クラスAの命令およびクラスBの命令のうちから選択する。
図8Aおよび
図8Bにおいて、角が丸められた正方形は、特定値がフィールド内に存在することを示すのに用いられている(例えば、
図8AのクラスA868A、および
図8BのクラスB868B)。
【0056】
クラスAの非メモリアクセス命令テンプレート
クラスAの非メモリアクセス805命令テンプレートの場合、アルファフィールド852は、含まれるコンテンツが複数の異なるオーグメンテーション動作タイプのうち何れが実行されるかを区別する(例えば、丸め852A.1およびデータ変換852A.2がそれぞれ、非メモリアクセス丸めタイプ演算810および非メモリアクセスデータ変換タイプ演算815命令テンプレートに関して特定される)RSフィールド852Aとして解釈され、ベータフィールド854は、特定されたタイプの動作のうち何れが実行されるかを区別する。
図8Aおよび
図8Bにおいて、角が丸められたブロックは、特定値が存在することを示すのに用いられている(例えば、修飾子フィールド846の非メモリアクセス846A、アルファフィールド852/RSフィールド852Aの丸め852A.1およびデータ変換852A.2)。非メモリアクセス805命令テンプレートにおいて、スケールフィールド860、変位フィールド862A、および変位スケールフィールド862Bは存在しない。
【0057】
非メモリアクセス命令テンプレート−完全丸め制御タイプ演算
非メモリアクセス完全丸め制御タイプ演算810命令テンプレートにおいて、ベータフィールド854は、含まれるコンテンツが静的な丸めを提供する丸め制御フィールド854Aとして解釈される。本願発明の説明される実施形態においては、丸め制御フィールド854Aは全浮動小数点例外抑制(SAE)フィールド856、および、丸め演算制御フィールド858を含むが、代替的な実施形態においては、これらのコンセプトの両方を同じフィールドにエンコードする、または、これらのコンセプト/フィールドのうち一方、または他方のみを有する(例えば、丸め演算制御フィールド858のみを有する)。
【0058】
SAEフィールド856−このコンテンツは、例外イベント報告を無効化するかどうかを区別する。抑制が有効であることをSAEフィールド856のコンテンツが示す場合、任意の命令はあらゆるタイプの浮動小数点例外フラグを報告せず、浮動小数点例外ハンドラを立ち上げない。
【0059】
丸め演算制御フィールド858−このコンテンツは、複数の丸め演算(例えば、端数切り上げ、端数切り捨て、ゼロに丸め、および最も近い値に丸め)からなるグループのうち何れを実行するかを区別する。よって、丸め演算制御フィールド858は、命令毎に丸めモードを変更することを可能とし、よって、このようなことが必要である場合に特に有用である。丸めモードを特定するための制御レジスタをプロセッサが含む本願発明の一実施形態において、丸め演算制御フィールド850のコンテンツは、レジスタ値よりも優位である(そのような制御レジスタに対し格納−変更−復元を実行する必要なく丸めモードを選択出来るということは有利である)。
【0060】
非メモリアクセス命令テンプレート−データ変換タイプ演算
非メモリアクセスデータ変換タイプ演算815命令テンプレートにおいて、ベータフィールド854は、複数のデータ変換(例えば、データ変換、スウィズル、ブロードキャスト)のうち何れが実行されるかを含まれるコンテンツが区別するデータ変換フィールド854Bとして解釈される。
【0061】
クラスAのメモリアクセス命令テンプレート
クラスAのメモリアクセス820命令テンプレートの場合、アルファフィールド852は、含まれるコンテンツが削除ヒントのうちいずれが用いられるかを区別する(
図8Aにおいて、一時的852B.1および非一時的852B.2がそれぞれ、メモリアクセス一時的825命令テンプレートおよびメモリアクセス非一時的830命令テンプレートに関して特定される)削除ヒントフィールド852Bとして解釈され、ベータフィールド854は、含まれるコンテンツが複数のデータ操作動作(プリミティブとしても知られる)のうちいずれが実行されるか(例えば、操作なし、ブロードキャスト、ソースのアップコンバート、および宛て先のダウンコンバート)を区別するデータ操作フィールド854Cとして解釈される。メモリアクセス820命令テンプレートは、スケールフィールド860を含み、場合によっては、変位フィールド862Aまたは変位スケールフィールド862Bを含む。
【0062】
ベクトルメモリ命令は、変換のサポートと共に、メモリからのベクトルロード、およびメモリへのベクトル格納を実行する。通常のベクトル命令と同様に、ベクトルメモリ命令は、データ要素毎に、書き込みマスクとして選択されたベクトルマスクのコンテンツによって指示されて実際に転送される要素と共に、メモリから、またはメモリへデータを転送する。
図8Aにおいて、角が丸められた正方形は、フィールド内に特定値が存在することを示すのに用いられている(例えば、修飾子フィールド846のメモリアクセス846B、アルファフィールド852/削除ヒントフィールド852Bの一時的852B.1、および非一時的852B.2)。
【0063】
メモリアクセス命令テンプレート−一時的
一時的データは、キャッシュするのが有利である程度に直ぐに再度用いられる可能性が高いデータである。しかし、これはヒントであり、複数の異なるプロセッサが、ヒントを全く無視するなど複数の異なるやり方で実行し得る。
【0064】
メモリアクセス命令テンプレート−非一時的
非一時的データは、第1レベルキャッシュでキャッシュするのが有利ではない程度に直ぐには再度用いられる可能性が低く、削除に関して高い優先度を与えられるべきデータである。しかし、これはヒントであり、複数の異なるプロセッサが、ヒントを全く無視するなど複数の異なるやり方で実行し得る。
【0065】
クラスB命令テンプレート
クラスB命令テンプレートの場合、アルファフィールド852は、書き込みマスクフィールド870により制御される書き込みマスキングがマージングであるかゼロ化であるかを含まれるコンテンツが区別する書き込みマスク制御(Z)フィールド852Cとして解釈される。
【0066】
クラスBの非メモリアクセス命令テンプレート
クラスBの非メモリアクセス805命令テンプレートの場合、ベータフィールド854の一部は、含まれるコンテンツが複数の異なるオーグメンテーション動作タイプのうちいずれが実行されるのかを区別する(例えば、丸め857A.1およびベクトル長さ(VSIZE)857A.2がそれぞれ、非メモリアクセス書き込みマスク制御部分的丸め制御タイプ演算812命令テンプレート、および非メモリアクセス書き込みマスク制御VSIZEタイプ演算817命令テンプレートに関して特定される)RLフィールド857Aとして解釈され、ベータフィールド854の残りは、特定されたタイプの動作のうちいずれが実行されるのかを区別する。
図8Aおよび8Bにおいて、角が丸められたブロックは、特定値(例えば、修飾子フィールド846の非メモリアクセス846A、RLフィールド857Aの丸め857A.1およびVSIZE857A.2)が存在することを示すのに用いられている。非メモリアクセス805命令テンプレートにおいて、スケールフィールド860、変位フィールド862A、および、変位スケールフィールド862Bは存在しない。
【0067】
非メモリアクセス命令テンプレート−書き込みマスク制御部分的丸め制御タイプ演算
非メモリアクセス書き込みマスク制御部分的丸め制御タイプ演算810命令テンプレートにおいて、ベータフィールド854の残りは、丸め演算フィールド859Aとして解釈され、例外イベント報告が無効化される(任意の命令はあらゆるタイプの浮動小数点例外フラグを報告せず、浮動小数点例外ハンドラを立ち上げない)。
【0068】
丸め演算制御フィールド859A−丸め演算制御フィールド858とちょうど同じようにこのコンテンツは、複数の丸め演算(例えば、端数切り上げ、端数切り捨て、ゼロに丸め、および最も近い値に丸め)からなるグループのうち何れを実行するかを区別する。よって、丸め演算制御フィールド859Aは、命令毎に丸めモードを変更することを可能とし、よって、このようなことが必要である場合に特に有用である。丸めモードを特定するための制御レジスタをプロセッサが含む本願発明の一実施形態において、丸め演算制御フィールド850のコンテンツは、レジスタ値よりも優位である(そのような制御レジスタに対し格納−変更−復元を実行する必要なく丸めモードを選択出来るということは有利である)。
【0069】
非メモリアクセス命令テンプレート−書き込みマスク制御VSIZEタイプ演算
非メモリアクセス書き込みマスク制御VSIZEタイプ演算817命令テンプレートにおいて、ベータフィールド854の残りは、複数のデータベクトル長さ(例えば、128、856、または1012バイト)のうち何れで実行されるかを含まれるコンテンツが区別するベクトル長さフィールド859Bとして解釈される。
【0070】
クラスBのメモリアクセス命令テンプレート
クラスAのメモリアクセス820命令テンプレートの場合、ベータフィールド854の一部は、ブロードキャストタイプデータ操作が実行されるかどうかを含まれるコンテンツが区別するブロードキャストフィールド857Bとして解釈され、ベータフィールド854の残りは、ベクトル長さフィールド859Bとして解釈される。メモリアクセス820命令テンプレートは、スケールフィールド860を含み、場合によっては、変位フィールド862Aまたは変位スケールフィールド862Bを含む。
【0071】
フィールドについての追加の説明
汎用のベクトルフレンドリーな命令形式800に関し、フルオペコードフィールド874は、形式フィールド840、ベース動作フィールド842、およびデータ要素幅フィールド864を含むものとして示した。フルオペコードフィールド874がこれらのフィールド全てを含む一実施形態を示したが、これらのフィールド全てをサポートしない実施形態においては、フルオペコードフィールド874はこれらのフィールドの全ては含まない。フルオペコードフィールド874は演算コードを提供する。
【0072】
オーグメンテーション動作フィールド850、データ要素幅フィールド864、および書き込みマスクフィールド870は、汎用のベクトルフレンドリーな命令形式で、命令毎にこれらの特徴全てを特定することを可能とする。
【0073】
書き込マスクフィールドおよびデータ要素幅フィールドを組み合わせると、複数の異なるデータ要素幅に基づいたマスクの適用を可能とするタイプ化された命令が生成される。
【0074】
当該命令形式は、他のフィールドのコンテンツに基づいて異なる目的のために異なるフィールドを再利用するので、必要なビット数が比較的少なくて済む。例えば、一つの見方としては、修飾子フィールドのコンテンツが、
図8Aおよび
図8Bの非メモリアクセス805命令テンプレートと、
図8Aおよび
図8Bのメモリアクセス8250命令テンプレートとの間で選択と行い、クラスフィールド868のコンテンツが、それら非メモリアクセス805命令テンプレートのうち、
図8Aの命令テンプレート810/815、および、
図8Bの命令テンプレート812/817から選択を行い、クラスフィールド868のコンテンツが、それらメモリアクセス820命令テンプレートのうち、
図8Aの命令テンプレート825/830、および、
図8Bの命令テンプレート827から選択を行う。他の見方では、クラスフィールド868のコンテンツが、
図8Aおよび
図8BのうちそれぞれのクラスAおよびクラスB命令テンプレートから選択を行い、修飾子フィールドのコンテンツが、それらクラスAの命令テンプレートのうち、
図8Aの命令テンプレート805、820から選択を行い、修飾子フィールドのコンテンツが、それらクラスB命令テンプレートのうち、
図8Bの命令テンプレート805、820から選択を行う。クラスフィールドのコンテンツがクラスAの命令テンプレートを示す場合、修飾子フィールド846のコンテンツが、アルファフィールド852(RSフィールド852AおよびEHフィールド852B)の解釈を選択する。同様に、修飾子フィールド846およびクラスフィールド868のコンテンツが、アルファフィールドがRSフィールド852A、EHフィールド852B、または書き込みマスク制御(Z)フィールド852Cとして解釈されるかの選択を行う。クラスフィールドおよび修飾子フィールドがクラスAのメモリアクセス動作を示す場合、オーグメンテーションフィールドのベータフィールドの解釈は、RSフィールドのコンテンツに基づいて変化し、クラスフィールドおよび修飾子フィールドがクラスBの非メモリアクセス動作を示す場合には、ベータフィールドの解釈は、RLフィールドのコンテンツに依存する。クラスフィールドおよび修飾子フィールドがクラスAのメモリアクセス動作を示す場合には、オーグメンテーションフィールドのベータフィールドの解釈は、ベース動作フィールドのコンテンツに基づいて変化し、クラスフィールドおよび修飾子フィールドがクラスBのメモリアクセス動作を示す場合には、オーグメンテーションフィールドのベータフィールドのブロードキャストフィールド857Bの解釈は、ベース動作フィールドのコンテンツに基づいて変化する。よって、ベース動作フィールド、修飾子フィールド、および、オーグメンテーション動作フィールドの組み合わせにより、さらに幅広いタイプのオーグメンテーション動作を特定することが可能となる。
【0075】
複数の異なる状況において、クラスAおよびクラスBに関し様々な命令テンプレートを用いるのが有益である。クラスAは、性能上の理由によりゼロ化−書き込みマスキング、または、より短いベクトル長さが所望される場合に有用である。例えば、ゼロ化により、人工的に宛て先とマージングを行う必要がなくリネームが用いられる場合に偽の依存性を避けることが可能となる。他の例として、ベクトル長さの制御は、ベクトルマスクを用いてより短いベクトルサイズをエミュレートする際に格納−ロード転送に関する課題を緩和する。クラスBは、1)浮動小数点の例外を可能とし(つまり、SAEフィールドのコンテンツがNoを示す)、同時に丸めモード制御を用いる、2)アップコンバート、スウィズル、スワップ、および/または、ダウンコンバートを用いることが出来る、並びに、3)グラフィックデータタイプで動作することが所望される場合に有用である。例えば、アップコンバート、スウィズル、スワップ、ダウンコンバート、およびグラフィックデータタイプは、異なる形式のソースを処理する際に必要となる命令の数を減らす。他の例としては、例外を可能とする性能により、指示される丸めモードでIEEEの規格に完全に準拠することが可能となる。
【0076】
例示的な特定のベクトルフレンドリーな命令形式
図9A、
図9B、および
図9Cは、本願発明の実施形態に係る例示的な特定のベクトルフレンドリーな命令形式を示すブロック図である。
図9A、
図9B、および
図9Cは、フィールドの場所、サイズ、解釈、および順序、並びに、これらのフィールドのうちいくつかの値を特定するという意味で特定的である、特定のベクトルフレンドリーな命令形式900を示す。特定のベクトルフレンドリーな命令形式900を用いて、x86命令の拡張を行ってもよく、よって、フィールのうちいくつかは、既存のx86命令のセット、およびその拡張(例えばAVX)に用いられるものと同様、または同じである。この形式は、拡張された既存のx86命令のセットのプレフィックスエンコードフィールド、リアルオペコードバイトフィールド、MOD R/Mフィールド、SIBフィールド、変位フィールド、および、即値フィールドに対応したままである。
図9A、
図9B、および
図9Cからのフィールドがマッピングされる
図8Aおよび
図8Bのフィールドが示されている。
【0077】
なお、本願発明の実施形態は、例示を目的とし、汎用のベクトルフレンドリーな命令形式800の文脈で特定のベクトルフレンドリーな命令形式900に関して説明するが、本願発明は、特に記される場合を除き、特定のベクトルフレンドリーな命令形式900に限定されない。例えば、特定のベクトルフレンドリーな命令形式900は特定のサイズのフィールドを有するものとして示されているが、汎用のベクトルフレンドリーな命令形式800に関しては様々なフィールドが様々なサイズを有し得る。特定の例として、データ要素幅フィールド864は特定のベクトルフレンドリーな命令形式900において1ビットのフィールドとして示されているが、本願発明はそのように限定されない(つまり、汎用のベクトルフレンドリーな命令形式800のデータ要素幅フィールド864は他のサイズを有し得る)。
【0079】
EVEX Prefix(Bytes 0−3)EVEX Prefix902−4バイト形式でエンコードされている。
【0080】
形式フィールド840(EVEX Byte0,bits[7:0])−第1バイト(EVEX Byte 0)は、形式フィールド840であり、0x62(本願発明の一実施形態において、ベクトルフレンドリーな命令形式を区別するのに用いられる一意の値)を含む。
【0081】
第2〜4バイト(EVEX Bytes 1−3)は特定の機能を提供する複数のビットフィールドを含む。
【0082】
REXフィールド905(EVEX Byte 1,bits[7−5])−EVEX.R bit field(EVEX Byte 1,bit[7]−R),EVEX.X bit field(EVEX byte1,bit[6]−X)、および857BEX byte 1,bit[5]−B)からなる。EVEX.R,EVEX.XおよびEVEX.Bビットフィールドは、対応するVEXビットフィールドと同様の機能を提供し、1の補数形式を用いてエンコードされる。つまり、ZMM0は、1111Bとしてエンコードされ、ZMM15は、0000Bとしてエンコードされる。当分野で公知のように命令の他のフィールドは、レジスタインデックスの下位3ビット(rrr、xxx、およびbbb)をエンコードするので、EVEX.R、EVEX.X、およびEVEX.Bを加えることにより、Rrrr、Xxxx、およびBbbbが形成され得る。
【0083】
REX'フィールド910−このフィールドは、REX'フィールド910の最初の部分であり、拡張された32レジスタセットの上位16および下位16のうちいずれかをエンコードするのに用いられるEVEX.R'ビットフィールド(EVEX Byte 1,bit[4]−R')である。本願発明の一実施形態において、以下に示す他のビットと共にこのビットは、リアルオペコードバイトが62であるBOUND命令と(周知のx86 32ビットモードで)区別すべくビット反転形式で格納されるが、MODフィールドの11の値をMOD R/Mフィールド(以下に説明する)で受け入れない。代替的な実施形態においては、このビット、および以下に示された他のビットは反転形式で格納されない。1の値を用いて下位16のレジスタをエンコードする。言い換えると、EVEX.R'、EVEX.R、および他のフィールドからの他のRRRを組み合わせて、R'Rrrrが形成される。
【0084】
オペコードマップフィールド915(EVEX byte 1,bits[3:0]−mmmm)−このコンテンツは、示唆された先頭のオペコードバイト(0F、0F 38、または、0F 3)をエンコードする。
【0085】
データ要素幅フィールド864(EVEX byte 2,bit[7]−W)−EVEX.Wと表記される。EVEX.Wは、データタイプの粒度(サイズ)を定義するのに用いられる(32ビットのデータ要素、または64ビットのデータ要素)。
【0086】
EVEX.vvvv920(EVEX Byte 2,bits[6:3]−vvvv)−EVEX.vvvvの役割には、以下のものが含まれ得る。1)EVEX.vvvvは、反転された(1の補数)形式で特定される第1ソースレジスタオペランドをエンコードし、2以上のソースオペランドの命令に有効である、2)EVEX.vvvvは、特定のベクトルシフトに関し、1の補数形式で特定される宛て先レジスタオペランドをエンコードする、3)EVEX.vvvvは、何れのオペランドもエンコードせず、当該フィールドは残しておかれ、1111bを含む。よって、EVEX.vvvvフィールド920は、反転された(1の補数)形式で格納される第1ソースレジスタ指定子の4つの下位ビットをエンコードする。命令に応じて、追加の異なるEVEXビットフィールドが、指定子のサイズを32レジスタに拡張するのに用いられる。
【0087】
EVEX.U868クラスフィールド(EVEX byte 2,bit[2]−U)−EVEX.U=0の場合、クラスA、またはEVEX.U0を示し、EVEX.U=1の場合、クラスB、またはEVEX.U1を示す。
【0088】
プレフィックスエンコードフィールド925(EVEX byte 2,bits[1:0]−pp)−ベース動作フィールドに追加のビットを提供する。EVEXプレフィックス形式のレガシーSSE命令のサポートを提供するのに加え、このフィールドは、SIMDプレフィックスをコンパクト化するのに有用である(SIMDプレフィックスを表現するのに1バイトを必要とせず、EVEX Prefixは2ビットのみ必要とする)。一実施形態において、レガシー形式、およびEVEXプレフィックス形式の両方のSIMDプレフィックス(66H、F2H、F3H)を用いるレガシーSSE命令をサポートするべく、これらのレガシーSIMDプレフィックスは、SIMDプレフィックスエンコードフィールドにエンコードされ、実行時には、デコーダのPLAに提供される前に、レガシーSIMDプレフィックスに拡張される(つまり、PLAは修正を加えることなくこれらのレガシー命令のレガシー形式およびEVEX形式を実行することが出来る)。より新しい命令はEVEXプレフィックスエンコードフィールドのコンテンツを直接的にオペコード拡張として用いることが出来るが、特定の実施形態においては、一貫性を保つべく同様のやり方で拡張が行われるが、これらのレガシーSIMDプレフィックスによる異なる意味の特定を可能とする。代替的な実施形態において、2ビットのSIMDプレフィックスエンコードをサポートするようPLAを再設計し、よって、拡張が必要とされない。
【0089】
アルファフィールド852(EVEX byte 3,bit[7]−EH。EVEX.EH、EVEX.rs、EVEX.RL、EVEX.write mask controlおよびEVEX.Nとしても知られる。αを用いても示される−上述したように、このフィールドはコンテンツ固有のものである。追加の説明は本明細書において以下に示す。
【0090】
ベータフィールド854(EVEX byte 3,bits[6:4]−SSS。EVEX.s2−0、EVEX.r2−0、EVEX.rr1、EVEX.LL0、EVEX.LLBとしても知られる。βを用いても示される)−上述したように、このフィールドはコンテンツ固有のものである。追加の説明は本明細書において以下に示す。
【0091】
REX'フィールド910−このフィールドはREX'フィールドの残りであり、拡張された32レジスタセットの上位16および下位16のうちいずれかをエンコードするのに用いられ得るEVEX.V'ビットフィールド(EVEX Byte 3,bit[3]−V')である。このビットはビット反転形式で格納される。下位16のレジスタをエンコードするのに1の値が用いられる。言い換えると、EVEX.V'とEVEX.vvvvとを組み合わせてV'VVVVが形成される。
【0092】
書き込みマスクフィールド870(EVEX byte 3,bits[2:0]−kkk)−このコンテンツは、上述したように書き込みマスクレジスタのレジスタのインデックスを特定する。本願発明の一実施形態において、特定値EVEX.kkk=000は特定の命令に対し書き込みマスクが用いられないことを示唆する特別な挙動を示す(このことは、全ての1にハードワイヤされた、またはマスキングハードウェアをバイパスするハードウェアにハードワイヤされた書き込みマスクを用いることを含む様々なやり方で実装することが出来る)。
【0093】
リアルオペコードフィールド930(Byte 4)このフィールドは、オペコードバイトとしても知られる。オペコードの一部はこのフィールドで特定される。
【0094】
MOD R/Mフィールド940(Byte 5)修飾子フィールド846(MODR/M.MOD,bits[7−6]−MODフィールド942)−上述したように、MODフィールド942のコンテンツは、メモリアクセス動作と非メモリアクセス動作とを区別する。このフィールドは本明細書において以下にさらに説明する。
【0095】
MODR/M.regフィールド944,bits[5−3]−ModR/M.regフィールドの役割は、2つの状況に要約することが出来る。ModR/M.regが、宛て先レジスタオペランド、およびソースレジスタオペランドのうちいずれかをエンコードする。または、ModR/M.regが、オペコード拡張として扱われ、いずれの命令オペランドをエンコードするのにも用いられない。
【0096】
MODR/M.r/mフィールド946,bits[2−0]−ModR/M.r/mフィールドの役割には以下のものが含まれ得る。ModR/M.r/mが、メモリアドレスを参照する命令オペランドをエンコードする。または、ModR/M.r/mが、宛て先レジスタオペランド、およびソースレジスタオペランドのいずれかをエンコードする。
【0097】
スケール、インデックス、ベース(SIB)バイト(Byte 6)スケールフィールド860(SIB.SS,bits[7−6]−上述したように、スケールフィールド860のコンテンツは、メモリアドレスの生成に用いられる。このフィールドは本明細書において以下にさらに説明する。
【0098】
SIB.xxx954(bits[5−3])、および、SIB.bbb956(bits[2−0])−これらのフィールドのコンテンツは、レジスタインデックスXxxxおよびBbbbに関連して上記にて参照した。
【0099】
変位バイト(Byte 7、または、Bytes 7−10)変位フィールド862A(Bytes 7−10)−MODフィールド942が10を含む場合、バイト7−10は変位フィールド862Aであり、レガシー32ビットの変位(disp32)と同じく動作し、バイト粒度で動作する。
【0100】
変位係数フィールド862B(Byte 7)−MODフィールド942が01を含む場合、バイト7は変位係数フィールド862Bである。このフィールドの場所は、バイト粒度で動作するレガシーx86命令セットの8ビット変位(disp8)の場所と同じである。disp8は符号が拡張されているので、−128〜127バイトのオフセットのみに対応出来る。64バイトのキャッシュに関しては、disp8は、−128、−64、0、および64の4つの実際に有用な値にのみ設定され得る8ビットを用いる。さらに大きな範囲が必要とされることが多いので、disp32が用いられる。しかし、disp32は4バイトを必要とする。disp8およびdisp32と対照的に、変位係数フィールド862Bはdisp8の再解釈である。変位係数フィールド862Bを用いる場合、実際の変位は、変位係数フィールドのコンテンツにメモリオペランドアクセスのサイズ(N)を乗算して求められる。このタイプの変位は、disp8*Nと示される。これにより、平均の命令長さが短くなる(変位に関して用いられるよりも1つのバイトがより大きな範囲に対して用いられる)。そのような圧縮された変位は、有効な変位はメモリアクセスの粒度の倍数であり、よって、アドレスオフセットの冗長下位ビットは、エンコードされる必要がないという仮定に基づいている。言い換えると、変位係数フィールド862Bはレガシーx86命令セットの8ビット変位に置き換わる。よって、変位係数フィールド862Bは、x86命令セットの8ビット変位と同じやり方でエンコードされ(つまり、ModRM/SIBのエンコードルールには変更がない)、disp8がdisp8*Nにオーバーロードされる(overloaded)点だけが異なる。言い換えると、エンコードルールまたはエンコード長さには変化がないが、(バイトごとのアドレスオフセットを得るには、メモリオペランドのサイズで変位をスケーリングする必要がある)ハードウェアによる変位値の解釈にのみ変化がある。
【0101】
即値
即値フィールド872は上述したように動作する。
【0102】
例示的なレジスタアーキテクチャ−
図10
図10は、本願発明の一実施形態に係るレジスタアーキテクチャ1000のブロック図である。レジスタアーキテクチャのレジスタファイルおよびレジスタを以下に列挙する。
【0103】
ベクトルレジスタファイル1010 示される実施形態において、1012ビットの幅を有する32個のベクトルレジスタがある。これらのレジスタをzmm0〜zmm31と呼ぶ。最初の16個のレジスタの下位856ビットは、レジスタymm0〜16にオーバーレイされて(overlaid)いる。最初の16zmmレジスタの下位128ビット(ymmレジスタの下位128ビット)は、レジスタxmm0〜15にオーバーレイされている。特定のベクトルフレンドリーな命令形式900は以下の表に示すようにこれらオーバーレイされたレジスタファイルに対して動作する。
【表2】
【0104】
言い換えると、ベクトル長さフィールド859Bは、最大長さおよび1以上の他のより短い長さのうちから選択を行う。ここでそのようなより短い長さのそれぞれは先行する長さの半分である。ベクトル長さフィールド859Bを有さない命令テンプレートは、最大ベクトル長さで動作する。さらに、一実施形態において、特定のベクトルフレンドリーな命令形式900のクラスB命令テンプレートは、パックされた、またはスカラの単/倍精度浮動小数点データ、およびパックされた、またはスカラの整数データに対し動作する。スカラ演算は、zmm/ymm/xmmレジスタの下位のデータ要素の位置に対して行われる演算である。上位のデータ要素の位置は命令の前の位置と同じままである、または実施形態によってはゼロにされる。
【0105】
書き込みマスクレジスタ1015−示される実施形態において、それぞれサイズが64ビットである8個の書き込みマスクレジスタ(k0〜k7)がある。上述したように、本願発明の一実施形態において、ベクトルマスクレジスタk0は書き込みマスクとして用いることが出来ない。エンコードの際には、このフィールドは通常k0が書き込みマスクに用いられることを示し、0xFFFFのハードワイヤされた書き込みマスクを選択し、効果的に当該命令の書き込みマスクを無効化する。
【0106】
マルチメディア拡張制御ステータスレジスタ(MXCSR)1020−示される実施形態において、この32ビットのレジスタは浮動小数点演算に用いられるステータスおよび制御ビットを提供する。
【0107】
汎用レジスタ1025−示される実施形態において、メモリオペランドに対応する既存のx86アドレシングモードと用いられる16個の64ビット汎用レジスタがある。これらのレジスタはRAX、RBX、RCX、RDX、RBP、RSI、RDI、RSP、および、R8〜R15で示される。
【0108】
拡張フラグ(EFLAGS)レジスタ1030−示される実施形態において、この32ビットのレジスタは、多くの命令の結果を記録するのに用いられる。
【0109】
浮動小数点制御ワード(FCW)レジスタ1035、および、浮動小数点ステータスワード(FSW)レジスタ1040−示される実施形態において、これらのレジスタは、FCWの場合に丸めモード、例外マスク、およびフラグを設定し、FSWの場合に例外の記録をつけるべく、x87命令セット拡張によって用いられる。
【0110】
MMXパックド整数フラットレジスタファイル1050がエイリアスされるスカラ浮動小数点スタックレジスタファイル(x87スタック)1045−示される実施形態において、x87スタックは、x87命令セット拡張を用いる32/64/80ビット浮動小数点データに対するスカラ浮動小数点演算を実行するのに用いられる8個の要素のスタックであり、MMXレジスタは、64ビットのパックされた整数データに対する演算を実行し、MMXレジスタとXMMレジスタとの間で実行されるいくつかの演算のオペランドを保持するのに用いられる。
【0111】
セグメントレジスタ1055−示される実施形態において、セグメント化されたアドレス生成に用いられるデータを格納するのに用いられる6個の16ビットのレジスタがある。
【0112】
RIPレジスタ1065−示される実施形態において、この64ビットのレジスタは、命令ポインタを格納する。
【0113】
本願発明の代替的な実施形態においては、より広い、またはより狭いレジスタが用いられる。加えて、本願発明の代替的な実施形態においては、より多くの、より少ない、または異なるレジスタファイルおよびレジスタが用いられる。
【0114】
例示的なインオーダープロセッサアーキテクチャ−
図11Aおよび
図11B
図11Aおよび
図11Bは、例示的なインオーダープロセッサアーキテクチャのブロック図を示す。これらの例示的な実施形態は、ワイドベクトルプロセッサ(VPU)で補強されたインオーダーCPUコアの複数のインスタンシエイションに基づいて設計されている。コアはe13tアプリケーションに応じて、何らかの所定の関数ロジック、メモリI/Oインタフェース、および、他の必要なI/Oロジックと高帯域幅インターコネクトネットワークを介して通信を行う。例えば、スタンドアローンGPUとしての本実施形態の実施は、典型的にはPCIeバスを含む。
【0115】
図11Aは、本願発明の実施形態に係る、シングルCPUコア、当該シングルCPUコアのオンダイインターコネクトネットワーク1102との接続、およびレベル2(L2)キャッシュ1104のローカルサブセットを示すブロック図である。命令デコーダ1100は、特定のベクトル命令形式900を含む拡張を有するx86命令セットをサポートする。本願発明の一実施形態においては、(設計を単純にするべく)スカラユニット1108およびベクトルユニット1110は別個のレジスタセットを用い(それぞれ、スカラレジスタ1112、およびベクトルレジスタ1114)、これらの間で転送されるデータはメモリへ書き込まれ、レベル1(L1)キャッシュ1106から読み出されるが、本願発明の代替的な実施形態においては、異なるアプローチが用いられる(例えば、1つのレジスタセットが用いられる、または、書き込みおよび読み出しが行われることなく2つのレジスタファイル間でデータの転送を可能とする通信パスが含まれる)。
【0116】
L1キャッシュ1106は、メモリのスカラユニットおよびベクトルユニットへのキャッシュのための短いレイテンシでのアクセスを可能とする。ベクトルフレンドリーな命令形式のロードオペランド命令と併せて、このことは、拡張されたレジスタファイルと幾分同じようにL1キャッシュ1106を扱えることを意味する。このことにより、多くのアルゴリズム、特に削除ヒントフィールド852Bのアルゴリズムに関して性能を向上させられる。
【0117】
L2キャッシュ1104のローカルサブセットは、CPUコア毎に1つの、別個のローカルサブセットへ分割されるグローバルなL2キャッシュの一部である。各CPUは、L2キャッシュ1104の自身のローカルサブセットへの直接的なアクセスパスを有する。CPUコアによって読み出されたデータは、そのL2キャッシュサブセット1104に格納され、それぞれ自身のローカルL2キャッシュサブセットにアクセスする他のCPUと並行して迅速にアクセスすることが出来る。CPUコアによって書き込まれたデータは、自身のL2キャッシュサブセット1104に格納され、必要であれば他のサブセットからフラッシュされる。リングネットワークによって、共有されるデータの一貫性が確保される。
【0118】
図11Bは、本願発明の実施形態に係る、
図11AのCPUコアの一部を示す分解図である。
図11BはL1キャッシュ1104のL1データキャッシュ1106A部分、並びに、ベクトルユニット1110およびベクトルレジスタ1114の詳細を示す。詳細には、ベクトルユニット1110は整数、単精度浮動小数点、および倍精度浮動小数点命令を実行する16ワイドベクトル処理ユニット(VPU)(16ワイドALU1128を参照)である。VPUは、スウィズルユニット1120のレジスタインプットのスウィズル、数値変換ユニット1122A、1122Bの数値変換、およびメモリインプットの複製ユニット1124の複製をサポートする。書き込みマスクレジスタ1126により、結果として生じるベクトル書き込みの予測が可能となる。
【0119】
レジスタデータは、例えば行列の乗算をサポートするなど、様々なやり方でスウィズル出来る。メモリからのデータは、複数のVPUレーンに対して複製出来る。このことはグラフィックおよび非グラフィック両方の並列データ処理に共通の演算であり、キャッシュの効率性をはるかに向上させる。
【0120】
リングネットワークは、CPUコア、L2キャッシュ、および他のロジックグロックなどのエージェントが互いにチップ内で通信を行えるよう双方向性である。各リングデータパスは、一方向あたり1012ビット幅である。
【0121】
例示的なアウトオブオーダーアーキテクチャ−
図12
図12は、本願発明の実施形態に係る例示的なアウトオブオーダーアーキテクチャを示すブロック図である。詳細には、
図12は、ベクトルフレンドリーな命令形式およびその実行に対応するよう修正された周知の例示的なアウトオブオーダーアーキテクチャを示す。
図12において、矢印は2以上のユニットの結合を示し、矢印の方向はそれらユニット間のデータフローの方向を示す。
図12は、実行エンジンユニット1210およびメモリユニット1215に結合されたフロントエンドユニット1205を含む。実行エンジンユニット1210はさらに、メモリユニット1215に結合されている。
【0122】
フロントエンドユニット1205は、レベル2(L2)分岐予測ユニット1222に結合されたレベル1(L1)分岐予測ユニット1220を含む。L1およびL2分岐予測ユニット1220、1222は、L1命令キャッシュユニット1224に結合されている。L1命令キャッシュユニット1224は、命令トランスレーションルックアサイドバッファ(TLB)1226に結合され、命令トランスレーションルックアサイドバッファ(TLB)1226はさらに、命令フェッチ/プリデコードユニット1228に結合されている。命令フェッチ/プリデコードユニット1228は、命令キューユニット1230に結合され、命令キューユニット1230はさらにデコードユニット1232に結合されている。デコードユニット1232は、1個の複雑なデコーダユニット1234、および3個の単純なデコーダユニット1236、1238、1240を備える。デコードユニット1232は、マイクロコードROMユニット1242を含む。デコードユニット1232は、デコード段階について述べたセクションで上述したように動作してもよい。L1命令キャッシュユニット1224はさらに、メモリユニット1215内のL2キャッシュユニット1248に結合されている。命令TLBユニット1226はさらに、メモリユニット1215内の第2レベルTLBユニット1246に結合されている。デコードユニット1232、マイクロコードROMユニット1242、およびループストリーム検出ユニット1244はそれぞれ、実行エンジンユニット1210内のリネーム/アロケータユニット1256に結合されている。
【0123】
実行エンジンユニット1210は、リネーム/アロケータユニット1256を含み、リネーム/アロケータユニット1256は、リタイヤユニット1274および統合スケジューラユニット1258に結合されている。リタイヤユニット1274はさらに、実行ユニット1260に結合され、リオーダバッファユニット1278を含む。統合スケジューラユニット1258はさらに、物理レジスタファイルユニット1276に結合され、物理レジスタファイルユニット1276は実行ユニット1260に結合されている。物理レジスタファイルユニット1276は、ベクトルレジスタユニット1277A、書き込みマスクレジスタユニット1277B、および、スカラレジスタユニット1277Cを備える。これらのレジスタユニットは、ベクトルレジスタ1010、ベクトルマスクレジスタ1015、および、汎用レジスタ1025を提供してもよく、物理レジスタファイルユニット1276は、示されていない追加のレジスタファイルを含んでもよい(例えば、MMXパックド整数フラットレジスタファイル1050に対しエイリアスされたスカラ浮動小数点スタックレジスタファイル1045)。実行ユニット1260は3個のミックスされたスカラおよびベクトルユニット1262、1264、1272、ロードユニット1266、格納アドレスユニット1268、および、格納データユニット1270を含む。ロードユニット1266、格納アドレスユニット1268、および、格納データユニット1270はそれぞれさらに、メモリユニット1215内のデータTLBユニット1252に結合されている。
【0124】
メモリユニット1215は、第2レベルTLBユニット1246を含み、第2レベルTLBユニット1246は、データTLBユニット1252に結合されている。データTLBユニット1252はL1データキャッシュユニット1254に結合されている。L1データキャッシュユニット1254はさらに、L2キャッシュユニット1248に結合されている。いくつかの実施形態において、L2キャッシュユニット1248はさらに、メモリユニット1215内、および/または外のL3およびさらに高いレベルのキャッシュユニット1250に結合されている。
【0125】
例として、例示的なアウトオブオーダーアーキテクチャは、次のように処理パイプライン8200を実施する。1)命令フェッチ/プリデコードユニット1228がフェッチおよび長さデコード段階を実行する、2)デコードユニット1232がデコード段階を実行する、3)リネーム/アロケータユニット1256がアロケーションおよびリネーム段階を実行する、4)統合スケジューラユニット1258がスケジューリング段階を実行する、5)物理レジスタファイルユニット1276、リオーダバッファユニット1278、およびメモリユニット1215がレジスタ読み出し/メモリ読み出し段階を実行し、実行ユニット1260が実行/データ変換段階を実行する、6)メモリユニット1215およびリオーダバッファユニット1278が、書き戻し/メモリ書き込み段階1960を実行する、7)リタイヤユニット1274がROB読み出し段階を実行する、8)様々なユニットが例外取り扱い段階に関わってもよい、9)リタイヤユニット1274および物理レジスタファイルユニット1276がコミット段階を実行する。
【0126】
例示的なシングルコアおよびマルチコアプロセッサ−
図17
図17は、本願発明の実施形態に係る、集積メモリコントローラおよび集積グラフィックを備えたシングルコアプロセッサおよびマルチコアプロセッサ1700を示すブロック図である。
図17において、実線の四角はシングルコア1702A、システムエージェント1710、および1以上のバスコントローラユニット1716からなるセットを含むプロセッサ1700を示し、破線の四角は、複数のコア1702A〜N、システムエージェントユニット1710内の1以上の集積メモリコントローラユニット1714からなるセット、および集積グラフィックロジック1708を含む代替的なプロセッサ1700を任意的な追加として示す。
【0127】
メモリ階層は、コア内の1以上のレベルのキャッシュ、1以上の共有キャッシュユニット1706からなるセット、複数の集積メモリコントローラユニット1714からなるセットに結合された外部メモリ(図示せず)を含む。複数の共有キャッシュユニット1706からなるセットは、レベル2(L2)、レベル3(L3)、レベル4(L4)、または他のレベルのキャッシュなど1以上の中間レベルのキャッシュ、最後のレベルのキャッシュ(LLC)、および/またはこれらの組み合わせを含んでよい。一実施形態においては、リングベースのインターコネクトユニット1712が集積グラフィックロジック1708、複数の共有キャッシュユニット1706からなるセット、および、システムエージェントユニット1710を相互接続するが、代替的な実施形態においては、そのようなユニットを相互接続する周知の技術をいくつか用いてもよい。
【0128】
いくつかの実施形態において、1以上のコア1702A〜Nは、マルチスレッドに対応可能である。システムエージェント1710は、コア1702A〜Nの調整を行い動作させるコンポーネントを含む。システムエージェントユニット1710は、例えば、電力制御ユニット(PCU)、およびディスプレイユニットを含む。PCUは、コア1702A〜Nおよび集積グラフィックロジック1708の電力状況を制御するのに必要なロジックおよびコンポイーネントであるか、それらを含んでもよい。ディスプレイユニットが1以上の外部接続されたディスプレイを駆動する。
【0129】
コア1702A〜Nは、アーキテクチャ、および/または命令セットに関して、同質、または異質のものであってもよい。例えば、コア1702A〜Nのうちいくつかはインオーダー(例えば、
図11Aおよび
図11Bで示すような)であり、他のコアは、アウトオブオーダー(例えば、
図12に示すような)であってもよい。他の例として、コア1702A〜Nのうち2以上は、同じ命令セットを実行可能であり、他のコアは、その命令セットのサブセットのみ、または異なる命令セットを実行可能である。少なくとも1つのコアが、本明細書で説明するベクトルフレンドリーな命令形式を実行可能である。
【0130】
プロセッサは、米国カリフォルニア州サンタクララのIntel Corporationにより販売されるCore(登録商標)i3、i5、i7、2 Duo、およびQuad、Xeon(登録商標)、またはItanium(登録商標)プロセッサなどの汎用プロセッサであってよい。代替的に、プロセッサは他の企業が販売するものであってもよい。プロセッサは、例えば、ネットワークまたは通信プロセッサ、圧縮エンジン、グラフィックプロセッサ、コプロセッサ、埋め込み型プロセッサなどの特定用途プロセッサであってもよい。プロセッサは1以上のチップ上で実装されてもよい。プロセッサ1700は、BiCMOS、CMOS、またはNMOSなどの処理技術をいくつか用い、1以上の基板の一部である、および/または、それら基板上で実装されてもよい。
【0131】
例示的なコンピュータシステムおよびプロセッサ−
図13〜15
図13〜15は、プロセッサ1700を含めるのに適した例示的なシステムを示す。
図16は、1以上のコア1702を含み得る例示的なシステムオンチップ(SoC)を示す。ラップトップ、デスクトップ、ハンドヘルドPC、パーソナルデジタルアシスタント、エンジニアリングワークステーション、サーバ、ネットワークデバイス、ネットワークハブ、スイッチ、埋め込み型プロセッサ、デジタル信号プロセッサ(DSP)、グラフィックデバイス、ビデオゲームデバイス、セットトップボックス、マイクロコントローラ、携帯電話、携帯型メディアプレーヤ、ハンドヘルドデバイス、および様々な他の電子デバイスに関する当分野で公知の他のシステム設計および構成も適している。一般的に、本明細書で開示されるプロセッサ、および/または他の実行ロジックを組み込むことが可能な非常に幅広い種類のシステムまたは電子デバイスが適している。
【0132】
図13は、本願発明の一実施形態に係るシステム1300を示すブロック図である。システム1300は、1以上のプロセッサ1310、1315を含み、1以上のプロセッサ1310、1315はグラフィックメモリコントローラハブ(GMCH)1320に結合されている。追加のプロセッサ1315は任意で用いられるので、
図13において破線で示されている。
【0133】
各プロセッサ1310、1315はプロセッサ1700の何らかのバージョンであってよい。しかし、集積グラフィックロジックおよび集積メモリ制御ユニットがプロセッサ1310、1315内に存在するということは考えられにくい。
【0134】
図13は、GMCH1320が、例えばダイナミックランダムアクセスメモリ(DRAM)であってよいメモリ1340に結合されていてよいことを示す。DRAMは、少なくとも一実施形態において、非揮発性キャッシュに関連付けられている。
【0135】
GMCH1320は、チップセットである、またはチップセット一部である。GMCH1320はプロセッサ1310、1315と通信を行い、プロセッサ1310、1315とメモリ1340との間の相互作用を制御してもよい。またGMCH1320は、プロセッサ1310、1315と、システム1300の他の要素との間の加速バスインタフェースとして動作してもよい。少なくとも一実施形態において、GMCH1320は、フロントサイドバス(FSB)1395などのマルチドロップバスを介してプロセッサ1310、1315と通信を行う。
【0136】
さらに、GMCH1320は、ディスプレイ1345(フラットパネルディスプレイなど)に結合されている。GMCH1320は、集積グラフィックアクセラレータを含んでもよい。GMCH1320はさらに、様々な周辺デバイスをシステム1300に結合するのに用いられ得る、入力/出力(I/O)コントローラハブ(ICH)1350に結合されている。
図13の実施形態においては、他の周辺デバイス1370と併せて、ICH1350に結合されている独立したグラフィックデバイスであってよい外部グラフィックデバイス1360が例として示されている。
【0137】
代替的に、追加的な、または異なるプロセッサもシステム1300に存在してもよい。例えば、追加のプロセッサ1315には、プロセッサ1310と同じ追加のプロセッサ、プロセッサ1310と異質の、または対称的な追加のプロセッサ、アクセラレータ(例えば、グラフィックアクセラレータ、またはデジタル信号処理(DSP)ユニットなど)、フィールドプログラマブルゲートアレイ、または他の何らかのプロセッサが含まれてよい。アーキテクチャ、マイクロアーキテクチャ、熱、電力消費特性などの面で、物理リソース1310、1315毎に様々な利点がある。これらの利点の差は、処理要素1310、1315間の対称性または異質性を利用し有効に活用される。少なくとも一実施形態において、様々な処理要素1310、1315が同じダイパッケージに存在してもよい。
【0138】
図14は、本願発明の実施形態に係る第2システム1400を示すブロック図である。
図14に示すようにマルチプロセッサシステム1400は、ポイントツーポイントインターコネクトシステムであり、ポイントツーポイントインターコネクト1450で結合された第1プロセッサ1470および第2プロセッサ1480を含む。
図14に示すように各プロセッサ1470、1480はプロセッサ1700の何らかのバージョンであってよい。
【0139】
代替的に、1以上のプロセッサ1470、1480は、アクセラレータまたはフィールドプログラマブルゲートアレイなど、プロセッサ以外の要素であってよい。
【0140】
2つのプロセッサ1470、1480のみが示されているが、本願発明の態様はこのことに限定されない。他の実施形態において、1以上の追加的な処理要素が任意のプロセッサに存在してもよい。
【0141】
プロセッサ1470はさらに、集積メモリコントローラハブ(IMC)1472、およびポイントツーポイント(P−P)1476、1478を含んでもよい。同様に、第2プロセッサ1480は、IMC1482およびP−Pインタフェース1486、1488を含んでもよい。プロセッサ1470、1480は、PtPインタフェース回路1478、1488を用いてポイントツーポイント(PtP)インタフェース1450を介してデータを交換してもよい。
図14に示すようにIMC1472、1482は各プロセッサを、対応するメモリ、つまり各プロセッサにローカルに取り付けられた主メモリの一部であってもよいメモリ1442およびメモリ1444に結合する。
【0142】
プロセッサ1470、1480はそれぞれ、ポイントツーポイントインタフェース回路1476、1494、1486、1498を用いて個々のP−Pインタフェース1452、1454を介しチップセット1490とデータを交換してもよい。またチップセット1490は、高性能グラフィックインタフェース1439を介して高性能グラフィック回路1438とデータを交換してもよい。
【0143】
プロセッサが低電力モードにされた場合、いずれか、または両方のプロセッサのローカルキャッシュ情報が共有キャッシュに格納されるように、共有キャッシュ(図示せず)は、両プロセッサ外でいずれかのプロセッサに含まれ、かつ、P−Pインターコネクトを介しプロセッサと接続されていてもよい。
【0144】
チップセット1490は、インタフェース1496を介して第1バス1416に結合されていてもよい。一実施形態において、第1バス1416は、Peripheral Component Interconnect(PCI)バス、或いは、PCI Expressバスまたは他の第3世代I/Oインターコネクトバスなどのバスであってもよい。ただし、本願発明の態様はこのことに限定されない。
【0145】
図14に示すように、第1バス1416を第2バス1420へ結合するバスブリッジ1418と併せて、様々なI/Oデバイス1414が第1バス1416に結合されていてもよい。一実施形態において、第2バス1420はlow pin count(LPC)バスであってもよい。一実施形態において、キーボード/マウス1422、通信デバイス1426、並びに、ディスクドライブまたは、コード1430を含んでよい他の大容量記憶装置などのデータ格納ユニット1428など様々なデバイスが第2バス1420に結合されていてもよい。さらに、オーディオI/O1424が第2バス1420に結合されていてもよい。なお他のアーキテクチャを用いることも可能である。例えば、
図14のポイントツーポイントアーキテクチャの代わりに、システムは、マルチドロップバスまたは他の同様のアーキテクチャを実装してもよい。
【0146】
図15は、本願発明の実施形態に係る第3システム1500を示すブロック図である。
図14および
図15において同様の要素は、同様の参照符号が付されており、
図14の特定の態様は、
図15の他の態様を曖昧にすることを避けるべく
図15において省略されている。
【0147】
図15は、処理要素1470、1480がそれぞれ集積メモリ−I/O制御ロジック(「CL」)1472、1482を含んでよいことを示す。少なくとも一実施形態において、CL1472、1482は
図13および
図14に関連して上述したようなメモリコントローラハブロジック(IMC)を含んでもよい。加えて、CL1472、1482はI/O制御ロジックも含んでよい。
図15は、メモリ1442、1444のみがCL1472、1482に結合されているのではなく、I/Oデバイス1514も制御ロジック1472、1482に結合されていることを示す。レガシーI/Oデバイス1515がチップセット1490に結合されている。
【0148】
図16は、本願発明の実施形態に係るSoC1600のブロック図を示す。
図17の同様の要素には同様の参照符号が付されている。また破線の四角はより高度なSoCの、任意で用いられる特徴を示す。
図16において、インターコネクトユニット1602は、1以上のコア1702A〜Nからなるセットおよび共有キャッシュユニット1706を含むアプリケーションプロセッサ1610と、システムエージェントユニット1710と、バスコントローラユニット1716と、集積メモリコントローラユニット1714と、集積グラフィックロジック1708、スチールカメラ、および/またはビデオカメラ機能を提供するイメージプロセッサ1624、ハードウェアオーディオアクセラレーションを提供するオーディオプロセッサ1626、および、ビデオエンコード/デコードアクセラレーションを提供するビデオプロセッサ1628を含み得る1以上のメディアプロセッサ1620からなるセットと、スタティックランダムアクセスメモリ(SRAM)ユニット1630と、ダイレクトメモリメモリアクセス(DMA)ユニット1632と、1以上の外部ディスプレイに結合されるディスプレイユニット1640とに結合されている。
【0149】
本明細書で開示するメカニズムの実施形態は、ハードウェア、ソフトウェア、ファームウェア、またはそのような実装アプローチの組み合わせにより実施されてもよい。本願発明の実施形態は、少なくとも1つのプロセッサ、記憶システム(揮発性、および非揮発性のメモリ、および/または記憶要素を含む)、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスを備えるプログラム可能なシステムで実行されるコンピュータプログラムまたはプログラムコードとして実施されてもよい。
【0150】
プログラムコードは、本明細書で開示される機能を実行し、出力情報を生成する入力データに適用されてもよい。出力情報は、公知の方式で、1以上の出力デバイスに適用されてもよい。この適用の目的において、処理システムは、例えば、デジタル信号プロセッサ(DSP)、マイクロコントローラ、特定用途集積回路(ASIC)、またはマイクロプロセッサなどのプロセッサを有する何らかのシステムを含む。
【0151】
プログラムコードは、処理システムと通信を行う高水準の手続き型プログラミング言語またはオブジェクト指向のプログラミング言語で実施されてもよい。またプログラムコードは、所望される場合、アセンブリ言語または機械言語で実施されてもよい。事実、本明細書で開示されるメカニズムは、何らかの特定のプログラミング言語に限定されない。いずれの場合であっても、言語はコンパイラ型言語、またはインタープリタ型言語であってもよい。
【0152】
少なくとも1つの実施形態の1以上の態様は、機械によって読み出されると当該機械に本明細書で開示される技術を実施するロジックを作成させる、プロセッサ内の様々なロジックを表す機械可読媒体に格納された表現命令によって実施されてもよい。「IPコア」とし知られるそのような表現は、有形の機械可読媒体に格納され、ロジックまたはプロセッサを実際に作成する製造機械にロードされるべく様々な顧客または製造施設に提供されてもよい。
【0153】
そのような機械可読媒体には、これらに限定されるわけではないが、機械またはデバイスによって製造または形成される、ハードディスク、フロッピー(登録商標)ディスク、光学式ディスク(コンパクトディスク読み取り専用メモリ(CD−ROM)、コンパクトディスクリライタブル(CD−RW)、および光磁気ディスクなどを含む他の何らかのタイプのディスク、リードオンリーメモリ(ROM)などの半導体デバイス、ダイナミックランダムアクセスメモリ(DRAM)などのランダムアクセスメモリ(RAM)、スタティックランダムアクセスメモリ(SRAM)、消去可能プログラム可能リードオンリーメモリ(EPROM)、フラッシュメモリ、電気的消去可能プログラム可能リードオンリーメモリ(EEPROM)、磁気または光学式カード、または、電子命令を格納するのに適した他の何らかのタイプの媒体などの記憶媒体を含む物品の非一時的な有形構造を含み得る。
【0154】
したがって、本願発明の実施形態は、本明細書で説明される構造、回路、装置、プロセッサ、および/またはシステム特徴を定めるベクトルフレンドリーな命令形式の命令を保持する、またはHardware Description Language(HDL)などの設計データを保持する非一時的有形機械可読媒体も含む。そのような実施形態は、プログラム製品とも呼ばれ得る。
【0155】
場合によっては、命令コンバータを用いて、ソース命令セットからターゲット命令セットへ命令が変換される。例えば、命令コンバータは、命令をコアによって処理される1以上の他の命令にトランスレートする(スタティックバイナリトランスレーション、ダイナミックコンパイルを含むダイナミックバイナリトランスレーションを用いて)、モーフィングする、エミュレートする、または変換してもよい。命令コンバータは、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組み合わせによって実施されてもよい。命令コンバータは、プロセッサ上、プロセッサ外、または一部がプロセッサ上で一部がプロセッサ外であってもよい。
【0156】
図18は、本願発明の実施形態に係る、ソース命令セットのバイナリ命令をターゲット命令セットのバイナリ命令に変換するソフトウェア命令コンバータの利用を対比するブロック図である。示される実施形態において、命令コンバータはソフトウェア命令コンバータであるが、代替的に、命令コンバータは、ソフトウェア、ファームウェア、ハードウェア、またはこれらの様々な組み合わせで実施されてもよい。
図18は、少なくとも1つのx86命令セットコアを備えるプロセッサ1816によりネイティブに実行され得るx86バイナリコード1806を生成するべくx86コンパイラ1804を用いてコンパイルされている高水準言語1802のプログラムを示す(コンパイルされた命令のうちいくつかがベクトルフレンドリーな命令形式であるものと想定されている)。少なくとも1つのx86命令セットコアを備えるプロセッサ1816は、(1)Intelx86命令セットコアの命令の実質的な部分、または、(2)少なくとも1つのx86命令セットコアを備えるIntelプロセッサと実質的に同じ結果を得るべく、少なくとも1つのx86命令セットコアを備えるIntelプロセッサで実行されることを目的とするアプリケーションのオブジェクトコードバージョンまたは他のソフトウェアに適合して実行する、または処理することにより、少なくとも1つのx86命令セットコアを備えるIntelプロセッサと実質的に同じ機能を実行出来るプロセッサを表す。x86コンパイラ1804は、少なくとも1つのx86命令セットコアを備えるプロセッサ1816で追加のリンク処理あり、またはなしで実行され得るx86バイナリコード1806(例えばオブジェクトコード)を生成するべく動作可能なコンパイラを表す。同様に、
図18は、少なくとも1つのx86命令セットコアを備えないプロセッサ1814(例えば、米国カリフォルニア州サニーベールのMIPS TechnologiesのMIPS命令セットを実行するコアを備えるプロセッサ、および/または米国カリフォルニア州サニーベールのARM HoldingsのARM命令セットを実行するコアを備えるプロセッサなど)によってネイティブに実行され得る代替的な命令セットバイナリコード1810を生成するべく、代替的な命令セットコンパイラ1808を用いてコンパイルされ得る高水準言語1802のプログラムを示す。命令コンバータ1812を用いて、x86命令セットコアを備えないプロセッサ1814によってネイティブに実行され得るコードへx86バイナリコード1806を変換する。この変換されたコードが、代替的な命令セットバイナリコード1810と同じであることは考えられにくい。なぜなら、このことに対応可能な命令コンバータは作成しにくいからである。しかし、変換されたコードは、一般的な動作を実行し、代替的な命令セットからの命令によって構成されているであろう。よって、命令コンバータ1812は、エミュレーション、シミュレーション、または他の何らかの処理により、プロセッサ、或いは、x86命令セットプロセッサまたはコアを有さない他の電子デバイスがx86バイナリコード1806を実行することを可能とする、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組み合わせを表す。
【0157】
本明細書で開示されるベクトルフレンドリーな命令形式の命令の特定の動作は、ハードウェアコンポーネントで実行されてもよく、当該命令をプログラムされた回路または他のハードウェアコンポーネントによるそれらの動作の実行を引き起こす、または少なくともそのような結果をもたらすのに用いられる機械可読命令として実施され得る。回路には、ほんの数例を上げると、汎用プロセッサ、特定用途プロセッサ、またはロジック回路が含まれる。また動作は、場合によっては、ハードウェアとソフトウェアとの組み合わせによって実施されてもよい。実行ロジック、および/またはプロセッサは、命令によって特定される結果オペランドを格納するよう指示する機械命令、または当該機械命令から抽出された1以上の制御信号に応答する特定的な、または特定の回路または他のロジックを含んでもよい。例えば、本明細書で開示される命令の実施形態は、
図13〜16の1以上のシステムで実行されてもよく、ベクトルフレンドリーな命令形式の命令の実施形態は、システムによって実行されるプログラムコードに格納されてもよい。加えて、これら図面の処理要素は、本明細書で詳述されたパイプライン、および/またはアーキテクチャ(例えば、インオーダーアーキテクチャ、およびアウトオブオーダーアーキテクチャ)のうち1つを用いてもよい。例えば、インオーダーアーキテクチャのデコードユニットは、命令をデコードし、デコードされた命令をベクトルユニットまたはスカラユニットに渡すなどしてもよい。
【0158】
上記の説明は、本願発明の好ましい実施形態を示すことを目的として提供された。上記の説明から、成長が早くさらなる進歩の予測が容易ではない当技術分野において特に、本願発明は構造に関して、また詳細部分において、当業者によって本願発明の原理から逸脱することなく、添付の請求項およびそれらの同等物の範囲内で本願発明に修正が加えられ得ることは明らかである。例えば、方法の1以上の動作は組み合わせられ得る、またはさらに分割され得る。
【0159】
代替的な実施形態
ベクトルフレンドリーな命令形式がネイティブに実行される実施形態を説明してきたが、代替的な実施形態においては、異なる命令セットを実行する(例えば、米国カリフォルニア州サニーベールのMIPS TechnologiesのMIPS命令セットを実行するプロセッサ、米国カリフォルニア州サニーベールのARM HoldingsのARM命令セットを実行するプロセッサなどの)プロセッサ上で実行されるエミュレーションレイヤーを介してベクトルフレンドリーな命令形式を実行してもよい。また、図中のフロー図は本願発明の特定の実施形態によって実行される動作の特定の順序を示すが、そのような順序は例示であることが理解されるべきである(例えば、代替的な実施形態においては、それらの動作を異なる順序で実行する、特定の動作を組み合わせる、または特定の動作を同時に行うなど)。
【0160】
以上の説明において、説明を目的とし、本願発明の実施形態をよりよく理解いただけるように様々な特定の詳細を示してきた。しかし当業者であれば、それら特定の詳細のいくつかを用いずとも1以上の他の実施形態が実施可能であることを理解されよう。説明された特定の実施形態は、本願発明を限定するのではなく、本願発明の実施形態を例示するべく示されている。本願発明の態様は上記された特定の例によっては定められず、以下の請求項によってのみ定められる。
本明細書によれば、以下の各項目に記載の構成もまた開示される。
[項目1]
コンピュータプロセッサでアライメント命令を実行する方法であり、
書き込みマスクオペランドと、宛て先オペランドと、第1ソースオペランドと、第2ソースオペランドと、オフセット値とを含む前記アライメント命令をフェッチする段階と、
フェッチされた前記アライメント命令をデコードする段階と、
前記第1ソースオペランドの第1の複数のデータ要素と、前記第2ソースオペランドの第2の複数のデータ要素とを連結し、
連結された前記第1の複数のデータ要素および前記第2の複数のデータ要素を前記オフセット値に基づき右にシフトし、
右にシフトされた前記連結された第1の複数のデータ要素および第2の複数のデータ要素のうち宛て先の対応する位置に格納されるデータ要素を書き込みマスクの対応するビットに基づき判断する
ことにより、デコードされた前記アライメント命令を実行する段階と、
前記宛て先に格納されると判断された前記右にシフトされた連結された第1の複数のデータ要素および第2の複数のデータ要素のうちの前記データ要素を前記宛て先の前記対応する位置に格納する段階と
を備える方法。
[項目2]
前記書き込みマスクは16ビットのレジスタである、項目1に記載の方法。
[項目3]
前記オフセットは8ビットの即値である、項目1または2に記載の方法。
[項目4]
前記書き込みマスクが用いられるかどうかを判断する段階と、
前記書き込みマスクが用いられない場合、前記右にシフトされた連結された第1の複数のデータ要素および第2の複数のデータ要素のうち前記宛て先の前記対応する位置に格納される前記データ要素を前記書き込みマスクの前記対応するビットに基づき判断することなく、前記宛て先の前記対応する位置に前記右にシフトされた連結された第11の複数のデータ要素および第2の複数のデータ要素のうちの前記データ要素を格納する段階と
をさらに備える、項目1から3のいずれか1項に記載の方法。
[項目5]
前記宛て先に格納されるとの判断は、前記書き込みマスクの各ビット位置に関して並行して行われる、項目1から4のいずれか1項に記載の方法。
[項目6]
前記第1ソースオペランドおよび前記第2ソースオペランドは512ビットのレジスタである、項目1から5のいずれか1項に記載の方法。
[項目7]
前記第2ソースオペランドは512ビットのメモリ位置であり、
前記メモリ位置からの前記データ要素は、ソースの前記連結の前に一時的な512ビットのレジスタへロードされる、項目1から6のいずれか1項に記載の方法。
[項目8]
前記第1ソースオペランドの前記データ要素は、前記右にシフトされた連結された第1の複数のデータ要素および第2の複数のデータ要素のうち最下位のデータ要素である、項目1から7のいずれか1項に記載の方法。
[項目9]
第1ソースオペランドと、第2ソースオペランドと、宛て先オペランドと、書き込みマスクオペランドと、オフセットとを含むアライメント命令に応答し、
前記第1ソースオペランドの第1セットのデータ要素と、前記第2ソースオペランドの第2セットのデータ要素とを連結する段階と、
連結された前記第1セットのデータ要素および前記第2セットのデータ要素をX個のデータ要素の分だけ右にシフトする段階であり、Xは前記アライメント命令が示す即値である段階と、
書き込みマスクの第1ビット位置に関し、
シフトされた前記連結された第1セットのデータ要素および第2セットのデータ要素のうち対応するデータ要素が宛て先の対応する位置に格納されることを前記第1ビット位置が示すか判断し、
前記シフトされた連結された第1セットのデータ要素および第2セットのデータ要素のうち前記対応するデータ要素が格納されることを前記書き込みマスクの前記第1ビット位置が示す場合、前記対応するデータ要素を前記宛て先の前記対応する位置に格納し、
前記対応するデータ要素が前記宛て先に格納されないことを前記書き込みマスクの前記第1ビット位置が示す場合、前記宛て先の前記対応する位置のデータ要素に変更を加えない
段階と
を備える方法。
[項目10]
前記書き込みマスクの第2ビット位置に関し、
前記シフトされた連結された第1セットのデータ要素および第2セットのデータ要素のうち対応するデータ要素が前記宛て先の対応する位置に格納されることを前記第2ビット位置が示すか判断し、
前記シフトされた連結された第1セットのデータ要素および第2セットのデータ要素のうち前記対応するデータ要素が格納されることを前記書き込みマスクの前記第2ビット位置が示す場合、前記対応するデータ要素を前記宛て先の対応する位置に格納し、
前記対応するデータ要素が前記宛て先に格納されないことを前記書き込みマスクの前記第2ビット位置が示す場合、前記宛て先の前記対応する位置のデータ要素に変更を加えない
段階と
をさらに備える、項目9に記載の方法。
[項目11]
最後のビット位置に関して、前記シフトされた連結された第1セットのデータ要素および第2セットのデータ要素のうち対応するデータ要素を前記宛て先の対応する位置に格納されるかを判断するべく評価された時点を判断し、前記アライメント命令を完了する段階をさらに備える、項目10に記載の方法。
[項目12]
前記書き込みマスクの前記第1ビット位置は前記書き込みマスクの最下位のビットである、項目9から11のいずれか1項に記載の方法。
[項目13]
前記書き込みマスクは16ビットのレジスタである、項目9から12のいずれか1項に記載の方法。
[項目14]
前記オフセットは8ビットの即値である、項目9から13のいずれか1項に記載の方法。
[項目15]
前記第1ビット位置が示すかの判断は、前記書き込みマスクの各ビット位置に関して並行して行われる、項目9から14のいずれか1項に記載の方法。
[項目16]
前記第1ソースオペランドおよび前記第2ソースオペランドは512ビットのレジスタである、項目9から15のいずれか1項に記載の方法。
[項目17]
前記第2ソースオペランドは512ビットのメモリ位置であり、
前記メモリ位置からの前記データ要素は、ソースの前記連結の前に一時的な512ビットのレジスタへロードされる、項目9から16のいずれか1項に記載の方法。
[項目18]
書き込みマスクオペランドと、宛て先オペランドと、第1ソースオペランドと、第2ソースオペランドと、オフセット値とを含むアライメント命令をデコードするハードウェアデコーダと、
実行ロジックと
を備え、
前記実行ロジックは、
前記第1ソースオペランドの第1の複数のデータ要素と、前記第2ソースオペランドの第2の複数のデータ要素とを連結し、
連結された前記第1の複数のデータ要素および前記第2の複数のデータ要素を前記オフセット値に基づき右にシフトし、
右にシフトされた前記連結された前記第1の複数のデータ要素および前記第2の複数のデータ要素のうち宛て先の対応する位置に格納されるデータ要素を書き込みマスクのうち対応するビットに基づき判断し、
前記宛て先に格納されると判断された前記右にシフトされた連結された第1の複数のデータ要素および第2の複数のデータ要素のうちの前記データ要素を前記宛て先の前記対応する位置に格納する、
装置。
[項目19]
前記書き込みマスクを格納する16ビットの書き込みマスクレジスタと、
前記第1ソースオペランドおよび前記第2ソースオペランドの前記データ要素を格納する少なくとも2つの512ビットのレジスタと
をさらに備える項目18に記載の装置。