AMDは今後の汎用CPUコアに実装するベクタ演算ユニットのためのインターフェイスを、AMD独自の「SSE5」からIntelの「AVX」互換へと切り替えた。すでに報じられているように、AMDは、Intelが2011年に導入するAdvanced Vector Extensions (AVX)命令拡張を、自社のCPUにも実装して行く。

　これによって、懸念されていたIntelとAMDでの拡張命令の分断は回避されたことになる。また、命令セットの変更は、その命令を実行するCPUハードウェアの設計にも大きな影響を与えたと推定される。AMDは公式ブログで2011年のCPUにAVX命令を実装する計画だと明かしている。2011年のCPUアーキテクチャ「Bulldozer (ブルドーザ)」は、元々SSE5をサポートする予定だった。

　AMDとIntelは、これまで、SIMD型を中心とする命令拡張で、それぞれ異なる命令を提唱していた。AMDが2007年に積和演算も含むSSE5を発表、遅れてIntelも昨年(2008年)春にAVXと積和演算のFMAを発表した。両社とも、汎用CPUコアの中のベクタ演算ユニットを強化して行くという方向は一致しているが、その実現方法と命令セットの実装は大きく異なっていた。IntelはSIMD演算するデータ長を広げることを重視、AMDはデータの操作やデータタイプを増やすことを重視した。もちろん、互換性は全くなかった。

　今回AMDは、Intelに歩み寄りつつ、自社の独自性も維持する方法を採った。Intelの仕様をサポートすると同時に、SSE5で提案した機能の拡張命令も実装することを明らかにした。ある意味で、AMDが実装するのはIntelの仕様のスーパーセットということになる。

　具体的には、AVX命令を実装すると同時に、AMDの独自の拡張命令を追加した。「XOP (eXtended Operations)」、「CVT16 (half-precision floating point converts)」、「FMA4 (four-operand Fused Multiply/Add)」の命令群だ。

　概念を図にすると次のようになる。これまでは、図の上のように、AMDがグリーンの円、Intelがブルーの円の仕様をカバーしており、両社のスペックは共通する部分もあるが異なる部分も大きかった。新しいAMDの方針では、図の下のように、Intelの仕様はカバーし、さらに張り出しで左の仕様を実装する。AMDから見れば、機能的にはSSE5とAVXの両方をカバーすることになる。

AMDの命令拡張計画の変更

　今回の変更で、SIMD演算のベクタ長はSSE5の128-bit長から、AVXの256-bit長へと変わった。32-bit単精度浮動小数点演算なら8並列でSIMD実行できる。SIMDレジスタも128-bit長から256-bit長(YMM0～15)へと拡張された。AMDはAVXに該当する命令があるSSE5の命令はAVXへと切り替えている。

　AVXに該当する命令がない部分については、AMD独自の拡張命令であるXOPとCVT16として実装した。次のような命令群だ。

・Horizontal integer add/subtract 128-bit
・Integer multiply/accumulate 128-bit
・Shift/rotate with per-element counts 128-bit
・Integer compare 128-bit
・Byte permute 128-bit
・Bit-wise conditional move 128/256-bit
・Fraction extract Scalar/128/256-bit
・CVT16 (half-precision floating point converts)

　積和演算については、4オペランドの積和演算をサポートするFMA4を定義した。以前の記事で間違えていたが、IntelのFMAは最初は4オペランドだったが、今は3オペランドフォーマットに変わっている。IntelのFMAフォーマットでは機能的に充分ではないとAMDは判断して、フォーマットを変えたFMA4を導入する。

　積和算では、3つのソースオペランドを必要とする。例えば、2つのレジスタの値のかけ算の結果に1つのレジスタの値を加える。その結果を保存しようとすると、4つ目のオペランドが必要だが、3オペランドフォーマットではそれができない。そのため、ソースオペランドの1つに結果を上書きしなければならない。

　4オペランドフォーマットでは、結果を4つ目のオペランドに書き込むことができるため、ソースオペランドのデータを破壊することがない。非破壊的なフォーマットだ。それに対して3オペランドフォーマットでは、必ずオペランドの1つのデータが破壊されてしまう。破壊的なフォーマットだ。そのため、3オペランドフォーマットでは、レジスタの値を移すといった操作が必要な場合が出てくる。

　AMDはFMA4が優位にあると確信を持っているようだ。ちなみに、IntelのCPUロードマップではFMA命令はAVX命令より遅れてサポートする計画になっている。FMA命令のサポート時期でもAMDは先行できるため、FMA4が支持されると見ているのかもしれない。

　皮肉なことに、この関係は当初のフォーマットとは逆転している。当初は、AMDのSSE5は3オペランドで、IntelのFMAは4オペランドだった。Intelは3オペランドのLarrabee New Instructionに引っ張られるようにフォーマットを変更し、AMDは命令エンコーディングを変えるのと同時に4オペランドになった。

Intel命令セットアーキテクチャの進化

　AVXのサポートは、SSE5を実装する予定だった2011年の次世代CPU Bulldozerアーキテクチャの開発にインパクトを与えた。あるAMD関係者は、2008年春にBulldozerの計画が2010年から2011年へと後退した一因が、AVX発表を受けた命令セットの再検討にあると示唆した。AMDは、その時点から新しいベクタ演算ユニットのフロントエンドの命令セットをどうするのか、真剣に検討を行なっていたと見られる。ただし、AMDはごくごく最近までSSE5という名称を顧客とのミーティングでも使っていた。

　また、あるAMD関係者は、AVXの256-bit SIMD演算のハードウェア実装は、Bulldozerではやらないだろうとも語っていた。これも納得できる話だ。理由の1つは、Bulldozerの設計はすでにかなり進んでいたため、演算ユニット自体を再設計することは難しいと推定されること。2011年にCPUのリリースを遅らせても、2010年にCPUのシリコンサンプルを完成させなければならず、2008年春から検討を始めて変更をかけるのでは、時間的な余裕はあまりない。通常は、シリコンの完成前に4年の開発期間がある。

　もう1つは、AMDが汎用CPUコアの中でのSIMD演算ユニットは比較的ベクタ長が短く実装しやすいものにとどめて、ある程度以上のデータ並列は汎用CPUコアの外へオフロードすることを考えていたこと。AMDの元CTOだったPhil Hester(フィル・へスター)氏は、最終的にSSE5拡張命令を、CPUに融合させたベクタエンジンにマップしてしまう可能性も示していた。ベクタエンジンと汎用CPUの統合が進めば、そうした実装形態も考えられる。Intelと較べるとAMDの方が、汎用コアからベクタコアへとオフロードすることに積極的なビジョンを持っており、そのため、汎用CPUコアの中のベクタ演算ユニットのベクタ長の拡張へのモチベーションは相対的に低いと推定される。

　実際、AMDはAVXの256-bit SIMDをサポートしても、最初の実装では、演算ユニット自体は128-bit幅のままに止める可能性はある。過去にもAMDとIntelともに、SSEの実装では128-bit SIMD演算を64-bit幅の演算ユニットで実行していた例がある。性能面での利点はないが、演算ユニット自体は128-bit SIMDのまま大きく変更しないでサポートが可能だ。256-bit SIMD命令を命令デコード時点で128-bit SIMDのuOPsのペアに変換すれば対応できるからだ。もちろん、レジスタは256-bit幅に拡張する必要があり、レジスタのシャッフルエンジンなども拡張する必要があると推定される。

Intel AVXの概要

　Bulldozerはクラスタ(Clustered)型マイクロアーキテクチャを取ると推定されるため、将来的にはもっと柔軟な実装も可能だ。

　ある業界関係者によると、BulldozerのCPUコアは複数のスレッドを並列に走らせることができるが、Intelのマルチスレッディングとは大きく異なると、AMDが説明しているという。Intelのマルチスレッディングのように2つのスレッドが、1つのCPUコアの実行リソースを完全に共有するのではなく、各スレッドがそれぞれ実行パイプを持つ。そのため、互いにリソースを奪い合うことなく、スレッドを並列に走らせることができる。しかし、マルチコアのように完全に独立したコアでスレッドを並列化するのではなく、コアの中で、ある意味で共有されていると説明したという。

　この説明は、AMDの米国での特許群(United States Patent Application 20090006814, 20090024836)から推定されるBulldozerマイクロアーキテクチャの姿と一致する。CPUコア自体がクラスタ化されており、2つの分割されたリソースが、それぞれ個別のスレッドを走らせることができるが、リソースを結合して単一スレッドを走らせることもできるようなアーキテクチャだ。単純な例では、2命令発行のCPUコアを2つクラスタ化して、最大4命令/スレッド発行を可能にするといった実装が挙げられる。

　IntelのSMT(Simultaneous Multithreading)と較べると、必要とするトランジスタ数は多いが、マルチスレッド性能もより高くなる。比較的シンプルな制御で、高いマルチスレッド性能と高いシングルスレッド性能を効率よく両立できると見られる。クラスタ型マイクロアーキテクチャに関連する特許の発明者リストには、過去にK8のアーキテクチャ発表の際のプレゼンテーション等に出てきた開発者の名前が見られる。

　クラスタードマイクロアーキテクチャをベクタ演算ユニットに当てはめると次のような予想ができる。CPUコアに1個の256-bit SIMDユニットを備え、256-bit SIMD命令が来た時には1個の256-bit SIMDユニットとして働かせ、128-bit SIMD命令が来た時には、2個の128-bit SIMDユニットに分割して2スレッドで並列に使うといった実装ができるだろう。これなら、256-bit時でなくても、ベクタ演算ユニットをフル稼働させやすい。

　Bulldozerが、推定されるようなマイクロアーキテクチャであるなら、こうした柔軟性を持つことになる。

　もっとも、Bulldozer世代のCPUの本質的に重要な部分は、CPUコア内部よりむしろ、次第にCPUにシステムレベル統合でさまざまな機能を統合し、それらを連携させて行くことにある。ベクタ演算で言えば、オフロードエンジンとどう連携させるかがカギとなる。x86命令ストリームの中のベクタ演算のインターフェイスが、SSE5からAVX+XOPへと変わった今も、その点は変わっていないだろう。

　AMDはBulldozerコアのCPUとして、サーバーでは「Interlagos (インテルラゴス)」を、パフォーマンスデスクトップPCでは「Orochi (オロチ)」を2011年にリリースすることを明らかにしている。ただし、AVX+XOP+FMA4がBulldozerコアCPUの登場時点から有効にされるかどうかはわからない。Intelは2011年のSandy Bridge(サンディブリッジ)からAVXを実装する予定だ。

Bulldozerのマルチスレッド構造の推測

AMD CPU 移行予想図

IntelとAMDのCPUアーキテクチャ移行予想図

　SSE5からAVXの変更で、ハードウェア設計に与える影響が大きいと考えられるのは命令エンコード方式の変更だ。Intelは、2008年春のIntel Developer Forum (IDF)でのAVXの説明の際に、AVXで重要な点は命令エンコードの改革にあると強調していた。AVXでは「VEX (Vector Extension)」と呼ばれる、新しい命令エンコーディングスキムを採用している。

　x86命令は可変長であるため、命令セットを拡張することが容易だ。これまでは、新命令拡張を加えたり、新データタイプを加える度に、1 byte分のプリフィックスを加え続けてきた。しかし、その方式は命令セットの複雑化と命令長の伸長という弊害をもたらしていたとIntelは説明した。その結果として、バイナリの肥大化とCPUの命令デコード&デコードハードウェアの複雑化を招いていた。

　特に、可変長のx86命令では、命令長を判定して次の命令の頭を見つけることが難しい。固定命令長のRISC(Reduced Instruction Set Computer)では、決め打ちで次の命令の頭を見つけることができることと比較すると、大きな違いだ。実行ユニットに対する命令発行数を増やすと、複数命令と1サイクルにデコードしなければならないため、短時間で命令区切りを見つける必要がある。命令の複雑化は、こうしたx86 CPUにとって大きな問題だった。

　VEXは、この問題を解決するために新たに作られたエンコーディング方式だ。VEXでは、2bytesまたは3bytesのVEXプリフィックスの中に、複数の従来プリフィックスの情報を圧縮してエンコードしたとIntelは説明していた。具体的には、VEXでは先頭バイトが「C4h」か「C5h」(64-bitモードでは空いている)で、C4hに続く2bytes、C5hに続く1byteが命令の情報を格納するペイロードとなっている。ペイロード部分に、従来のプリフィックスに含まれていた情報と、さらに256-bit長データタイプなどの新しい情報も格納される。VEXは、命令圧縮のテクニックだ。

　また、IntelはVEXが、今後の命令拡張を包含できるだけの余裕が充分にあるエンコーディング方式だと説明していた。C4hのペイロードには、まだ3bits分の予約ビットがあり、1,000以上の新命令やデータタイプを追加することができると言う。

AVXの構造

　VEXのもう1つの利点は、プリフィックス部分の命令フォーマットが固定されること。これによって命令デコードが従来より容易になることだという。C4hなら4bytes目、C5hなら3bytes目に必ずModRMがあり、比較的簡単に全体の命令長を割り出すことができる。フォーマットが今後の拡張命令の追加でも同じであるため、デコーダを複雑にせずに命令拡張を続けることができる。

　実際にはAMDのSSE5のフォーマットもある程度は似たような考え方で作られていた。こちらは3-byteオペコード方式で、最初の2bytes分が新しいプリフィックスとなっていて、命令長の予想がつきやすいようになっている。

　しかし、SSE5の3-byteオペコード方式は、IntelのVEXと異なるエンコーディング方式であるため、AMDにとって難しい問題を引き起こしていた。もし、命令デコーダをSSE5とAVXの両方式に互換にしようとするとデコーダが複雑になってしまうからだ。両対応は、ただでさえ大きくて消費電力の多いデコーダの複雑化を招く。そのため、AMDは、もしSSE5が普及しなければ、SSE5とAVXの両互換にするといった対応を取りにくい。

　AMDは、こうした要素を考えた結果か、SSE5のエンコーディングを完全に捨て去り、VEXエンコーディング方式に移行した。それは、AMDの独自拡張であるXOP命令群についても同様で、XOPをSSE5のエンコード方式で実装することはせず、VEXに近い方式にした。つまり、今回の移行で、CPUハードウェア側にとっては、命令デコードアルゴリズムが大きく変わった。

　IntelのVEXエンコーディングには余裕があるため、AMDはVEXのリザーブビットを使って自社のXOP拡張をマップすることも可能だった。しかし、AMDはIntelのVEXスペースの中にXOPを格納する方法は避けた。これは、Intel自身の今後の命令拡張により、オペコードスペースが干渉してしまう可能性を避けるためだと思われる。

　その代わりに、AMDが採用したのはVEXと同じコーディング方式で、VEXとは別のプリフィックスを使うことだった。VEXの場合は、プリフィックス部分の先頭バイトがC4hかC5hだ。それに対して、XOPでは先頭バイトが「8Fh」になっている。先頭バイトは異なるが、それに続くペイロード部分のフォーマットはVEXと同じになっている。

　ちなみに、8FhにはPOP命令が割り当てられているが、これは8Fhの次のバイトのmmmmmフィールドの値で、POP命令かXOPかを判定する(8未満ならPOP)ようになっている。IntelのVEXほどの拡張性の余裕はないが充分な命令をマップできる。

　エンコーディング方式が基本的にほぼ同じであるため、XOPの命令デコードでは、VEXと似たアルゴリズムを使うことができると考えられる。先頭バイトがC4hか8Fh(かつmmmmmが8以上)なら、その後のフォーマットがほぼ同じであると判明するので、同じアルゴリズムで対応できる。そのため、XOPという新しい命令群を加えても、命令プリデコーダとデコーダは、相対的にシンプルに止めることができる。

AVXとXOPの命令書式