SSE5

4オペランド命令に対応する。元々AMDは3オペランド命令を想定していた。Intelが追加するFMA命令(積和演算命令)が元4オペランド命令で、実際の実装で3オペランド命令に仕様変更された。これをみたAMDは、3オペランドでは機能が不足すると判断したようである。

そもそも、積和は、二つの乗算に一つの加算をするので、3つのソースオペランドが必要となる。その結果を更に別のレジスターに格納するとなれば、4つのオペランドが必要になるわけである。さもなくば、ソースオペランドのいずれか一つを上書きせねばならない。オペランドが4つ指定できれば、非破壊の演算も、また従来のような破壊される演算も可能ということになり、選択肢が広がる。

これらの機能により、シェーディング計算や写真のレンダリングの高速化が可能としている。

EAX=80000000HでCPUID命令を実行し、返却値EAXの最上位ビットが1となる拡張CPUID対応環境で、かつEAX=80000001HでCPUIDを実行した結果得られたECXレジスターのビット11が1のとき、SSE5に対応するとされていた。

仕様変更され、このフラグはXOP対応かどうかを表わすものとなった。

AMDのSSE5におけるオペコード表現方法は、従来の拡張法を踏襲しており、「治安を乱さない」ものだった。

AMD64 ISAにおけるREXプリフィックスという前例があるので、より短くなるような独創的な拡張も不可能ではなかったと思われるが、AMDはそのような拡張を避けていた。

SSE5は、0F xx xxという標準的なオペコード拡張の手法で表現する仕様だった。Opcodeの後に[ModR/M] [SIB]を続け、その後に3オペランド命令にするためのDREXというバイトを挿入するのが特徴である。

この方式は命令長が非常に長くなるという問題があり、対策として不要の際にはDREXバイトを省けるオペコードも用意されていた。

また、後に発表されるIntel AVXとも、オペランドの使い方に明らかな差があった。

Intel AVXは、ModR/Mのregとr/mをそれぞれデスティネーション、ソース2に使い、プリフィックスのフィールド中にソース1を割り当てる方法を採用した。この方法は、オペランドが二つで済む場合には無駄なビットが生じるという問題はあるものの、従来の仕様を維持した上での拡張となり、スマートな手法である。

一方、SSE5はModR/Mはいずれもソースに使い、拡張した領域でデスティネーションを表現する方法としていた。

いずれAMDがIntel AVXに対応した暁には、全体的に見て統一性を欠くSSE5のオペコードが混入する様相となる。デコーダーの肥大化も免れない。このため、仕様変更を決断することになる。

Intel AVXに対応することで、SIMD演算のベクター長は128ビットから256ビット長に対応可能となった。

また、当初予定されていた0Fから始まるオペコードによる拡張はキャンセルされた。AVXについてはVEXプリフィックスを用いる方法に仕様変更された。ただし、XOPをVEXプリフィックスで表現するといずれIntelとオペコード衝突が起こる可能性があったためこれは避けられ、専用のXOPプリフィックスが用意された。

VEXの1バイト目はC4またはC5だが、XOPは1バイト目が8Fとなる。8FはPOP命令のオペコードだが、2バイト目でXOPかどうかを判断する。VEXほどの拡張性はないが、当面必要な命令は符号化できる。

XOPプリフィックスを用いるXOPのオペコードは、VEXプリフィックスと発想ならびに構造的にはほぼ同じである。

XOPは、8Fhに続く2バイト目をModR/Mとみなし、regフィールドが0ならPOP命令、それ以外の未定義命令だったものをXOPプリフィックスとみなす。

2バイト目はMSBから順に、R/X/B/mmmmmとなり、2バイト目の下位5ビットを命令を識別するmmmmmフィールドとする。