また、2010年秋のIDFにおいて、図1.28に示すようにIntelのSandy Bridgeも単一の物理レジスタファイルを使いコミット時にデータのコピーを行わない構造になっていると発表された。Sandy BridgeではAVXをサポートし、AVXレジスタは256ビット幅であるので、コミット時にこの256ビットをROBから読み出してアーキテクチャレジスタに書き込むのはかなりのエネルギーを消費するので、電力が一番問題となっている昨今の設計では当然の方針である。

なお、Intelのブロック図ではReorder Buffersというブロックが書かれているが、これはリネームによりアーキテクチャレジスタ番号と物理レジスタ番号の対応を切り替える論理的なROBで、図1.26のようなデータを保持するタイプのROBではないと考えられる。

図1.28 IntelのSandy Bridgeも単一物理レジスタファイルを使う構造となった

そして、Sandy Bridgeの新機能の1つとしてZeroing Idiomsというのが謳われている。これはXOR　EAX、EAXやSUB EAX、EAXのような命令でEAXレジスタをゼロにするということが良く行われているのであるが、このような命令は命令デコードの時点でその動作が分かるので、 XOR命令のディスティネーションレジスタであるEAXを固定したゼロの値を持つ物理レジスタにリネームするという動作を行う。

このようなゼロ生成命令はデコードの時点で検出され、リネームだけで処理されてμOPが削除されてしまいスケジューラにも送られない。したがって、EAXを物理レジスタファイルから読む必要もXORやSUB演算をして結果を物理レジスタファイルに書き込むということもする必要がなくなり、消費電力も減るし、これらのリソースを他の命令の実行に使えるので性能が上がる。特に256ビット長のymmレジスタをクリアするVXORPS命令の場合などは効果が大きい。

また、これらのゼロ生成命令は入力オペランドのレジスタの値が何であっても結果がゼロになるので、入力オペランドは先行する命令に対するデータ依存性がないものとして即時に実行を行う。なお、Sandy Bridgeでは、CMPEQ XMM1、XMM1のように比較を行って前ビットを"1"にする命令もデータ依存性が無い命令として認識する。

これらのZeroing Idiom命令は無視できない程度に出てくるとは言え、それほど頻度が多い訳ではないので、全体として大幅に電力の削減や性能向上に貢献しているとは思われないが、ほとんど実装コストがかからない追加であるので、やらない手はないという感じである。

このリネームで後続の命令がEAXレジスタを参照すると、実際にはリネーム先の固定のゼロを保持しているレジスタを読むことになる。そして、その後にEAXレジスタに値を書き込む命令が出てきたときにはEAXレジスタは別の物理レジスタにリネームされるので、まったく問題がない。

ただし、通常のRISCプロセサでは整数レジスタのR0は固定のゼロというアーキテクチャが一般的であり、レジスタのクリアやゼロを読むのはコストがかからない作りになっており、Sandy Bridgeのこの機能は整数レジスタに関してはRISCに追いついたということになる。一方、RISCアーキテクチャでは浮動小数点レジスタに関しては固定のゼロというレジスタはなく、Sandy Bridgeが256ビット長のymmレジスタもこの機能でクリアできるようになっているのは進んでいると言える。

そして、Sandy Bridgeに採用された新機構で省電力効果が大きいと思われるのが、x86命令から内部のμOPに変換した命令を格納するDecoded ICacheである。従来から、μOPを格納する命令バッファは存在したが、18命令分という小さな容量であった。この中に納まる小規模なループの場合はバッファ内の命令を繰り返し使うことで、x86→μOP変換を省いて消費電力を減らし、また、命令フェッチを高速化するということができたが、Sandy Bridgeではこれをもう1段進めて、μOP用のキャッシュが設けられた。

このDecoded ICacheは、8Way×32Setという構成で、それぞれのキャッシュラインに6μOP命令を格納できる。したがって、最大では1536μOPを格納することができる。このキャッシュの詳細は明らかになっていないが、おおむね、図1.29のような構造になっていると推定される。

図1.29 Sandy BridgeのDecoded ICacheの構造(筆者による推定)

各キャッシュラインの先頭のμOPの元のx86命令のアドレスでインデックスされ、無条件分岐命令が出てくるまで最大6命令をキャッシュラインに入れる。そして、その6命令が実行された後に実行するx86命令のアドレスが書かれている。また、連続して実行されるμOPが長い場合は、3wayを連続させて18命令までを一連の命令として格納する機能も持っている。この次のx86命令のアドレスを使ってDecode ICacheをアクセスしてヒットする範囲では、このキャッシュから途切れなく命令を供給し続けられる構造となっている。

このDecode ICacheのヒット率は80%程度と言われており、80%の命令でx86→μOP変換のエネルギーを削減し、さらに、実行が高速になるということは、一定の仕事を行うのに必要なエネルギーが削減できるということであり、Decode ICacheの消費電力を差し引いても省電力効果は大きいと思われる。