ロードマップでわかる！当世プロセッサー事情 第71回

x86を高速化する切り札技術「命令変換」の仕組み

x86でのμOp変換の仕組み

　さて話を戻す。RISCの概念は、スーパースカラーやアウトオブオーダーと非常に親和性が高かった。スーパースカラーにせよアウトオブオーダーにせよ、キーになるのは「命令の依存性をいかに減らすか」である。x86をそのまま処理するのは、依存関係の解消にかなり手間取るのは明白で、これを解決するには「一度x86をRISC風の命令に分解して、この命令をスーパースカラー/アウトオブオーダーで実行すればよい」ということになる。

　命令の分解とは、まさしく前ページで示したRISCでの加算処理のような方法だ。つまり、メモリーアクセスなどをともなう命令は、レジスターへのロード命令と、それを使っての演算命令の2つに分解し、それぞれを個別に実行する。これにより、依存関係の解消が、x86命令のままに比べて容易になった。またレジスタ・リネーミングなども効果的に使えるようになるというわけだ。

　ちなみに、スーパースカラー/アウトオブオーダーに関しては、命令変換がほぼ必須である。例外は旧Cyrixの「MII」で、これはインオーダーのままスーパースカラーを実装した。しかし、やはり依存関係の解消などが困難であり、これもあって当時のCyrixは、「スーパースカラーは2命令が性能の限界で、3命令以上にしても効果がない」と主張していたほどだ。

　こうしたx86命令とRISC命令の変換は、通常はDecode段で実装される。図1のように、命令1次キャッシュにはあくまでx86命令のまま保持されて、Fetchもx86命令のまま実施される。これをDecodeで解釈する段になって、初めてμOpに変換される。以後はスケジューラーを経てALUなりLoad/Storeに投入される。

図1 x86からμOpへの変換の流れ

　ちなみに、μOpと呼び方こそ一緒であっても、その中身は当然アーキテクチャーごとに異なる。例えばインテルの場合、「Pentium Pro」が最初にこれを実装し、その後「Pentium II/III」に進化するが、これらのCPUには細かな違いがあり^※1、μOpにも当然反映されているはずだ。

^{※1 Pentium IIでは16bit命令の扱いやMMX命令、Pentium IIIではSSE命令が追加されている。}

　その次に出た「Pentium 4」は、当然まったく異なるμOpの構成となっている。しかも同じPentium 4でも、Willamette/NorthwoodとPrescott/CederMill(関連記事)では内部構造が完全に異なっているため、μOpも当然変わっていると思われる。とはいえ、x86命令は1～2個のμOpに変換され、また比較的簡単なx86命令はほぼ1個のμOpに割り当てられるという特徴は、インテルだけでなくAMDのK6～Phenom II世代でも共通である。

μOpの進化した活用法
MicroOps FusionとMacro Fusion

　ちなみに、このμOpの持ち方を一歩進化させたのが、インテルがPentium Mで実装した「MicroOps Fusion」と、Core 2で実装した「Macro Fusion」である。例えば以下の加算命令を例に考える。

• ADD　reg, mem

　これはmemで指し示したアドレスのメモリーからデータを読み込み、regで示すレジスターの値と加算するものだ。これを普通に処理する場合、図2のようになる。

図2 加算命令の分解と処理の流れ

　もともとのADD命令はFetchを経てDecodeに読み込まれ、これが「ld」(load)と「add」の2つのμOpに分解される。これがそのままスケジューラーに格納され、その後それぞれALUとLoad/Storeに渡されて実行される。ところがx86の場合、こうした「ld＋何か」という組み合わせが非常に多い。

　そこで、こうした煩雑に出る組み合わせについては専用μOpを用意し、スケジューラー段まではひとつのμOpとして扱うようにした(図3)。これにより、スケジューラーにより多くの命令を格納できるようになるし、DecodeからスケジューラーまではひとつのμOpとして扱われるので、データ移動量が減って結果的に省電力化も可能になる。また、結果的にDecode段で同時に処理できるx86命令を増やす効果もあるため、性能向上にも役立つというのが、MicroOps Fusionの効果だ。

図3 MicroOps Fusionの例。「ADD」を「ld＋add」というひとつのμOpに変換し、スケジューラーから実行ユニットに渡す際に分割している