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

インテルCPU進化論　パイプラインを大幅改良したCore 2

図1 Meromの内部構造図。赤枠内がYonahからの主な変更部分

　物理的な側面で言えば、64bit対応とは64bit幅のアドレスと、64bit幅のデータの両方に対応する必要がある。Yonah世代ではALUは32bit幅のものしか実装していないので、Meromではこれを倍増させる必要があった。

　ALUそのものは32bit幅が64bit幅になったからといって、回路規模が大幅に増えるわけではない(加減算なら単純に2倍になるだけ)。しかし乗算など複雑なものは、32bitの時と同じ速度を実現するためには、4倍＋αの回路が必要になる。内部のレジスタもサイズが倍(32bit→64bit)になるし、レジスタと演算器をつなぐデータパスも幅が2倍になるので、そう簡単な作業ではない。

　純粋に回路の規模そのもので言えば、AMDが「x86-64」を発表した際に、「64bit化に必要なダイサイズの増加分は数％」と説明している。実際もこれに近いと見られるが、配線の引き回しや回路レイアウトなどはそれなりに影響を受ける。インテルがEM64Tを発表した2004年春には、Yonahの設計はもう終わっていて、初期サンプルの製造に掛かっていた段階であった。この時点から64bitに対応するのはまったく不可能だし、Meromもかなりあわてて設計のやり直しをかけることになったのは間違いない。

　結果として、64bit環境におけるCore 2の性能は高いものではなかった。それでも64bit命令が使えるようになっただけマシであり、インテルも「とりあえず動けばよし」としていた節がある。

x86命令を合体させるMacro Fusion

　最後が「Macro Fusion」の導入である。当初は「Macro Ops Fusion」と呼ばれていたと記憶するが、すぐにMacro Fusionに名称が切り替わった。冷静に考えると「μOpsの結合」ではなく「x86命令レベルでの結合」なので、Macro Ops Fusionはわかりにくいと判断されたのかもしれない。

　Macro Fusionの動作をまとめたのが次の2枚の画像で、以下の処理プログラムを Macro Fusionを使わない場合が左、右は使う場合である。

• ①load eax,[mem1]　mem1のアドレスの内容をEAXレジスタにコピー
• ②cmp eax,[mem2]　EAXレジスタの内容とmem2のアドレスの内容を比較
• ③jne targ　②の結果が一致してなければ、targで示されるアドレスに分岐
• ④store [mem3], ebx　EBXレジスタの内容をmem3にコピー
• ⑤inc esp　ESPレジスタの値をスタックひとつ分(この場合は4)増やす

お詫びと訂正：掲載当初、⑤の項目で(この場合は8)と記載していましたが、正しくは4でした。ここに訂正するとともに、お詫びいたします。(2012年8月30日)

Macro Fusionを使わない場合

Macro Fusionを使う場合

　Macro Fusionを使わない場合、最初のサイクルでは①～④までの命令が「DEC 0」から「DEC 3」までのデコードエンジンにロードされて解釈され、⑤の命令は次のサイクルに処理される。しかし、②と③は基本的に対になる命令である。そこでデコードエンジンにx86命令を喰わす前に、Macro Fusionで②と③を合体させてしまえば、①～⑤までの命令を1サイクルで処理できる。

　μOpsに変換する「前に」命令を整理することで、実効処理命令数を増やす、というのがMacro Fusionの働きである。この作業をEarly Decode(DEC3)に追加したのが、Yonahに対するMeromの改良点のひとつというわけだ。

　Meromに続くPenrynも、基本的には大きなパイプライン構造の差はない。SSE周りの命令拡張やFPUの高速化、ターボ・ブーストの搭載といった程度が機構的な差である。むしろ65nmから45nmへのプロセス微細化と、これにともなう2次キャッシュの大型化の方が、性能面で大きなインパクトがあった。次なる大変更は「Nehalem」ことCore iシリーズからとなる。