後藤弘茂のWeekly海外ニュース

徹底してロスをなくすBaniasのアーキテクチャ


●Baniasアーキテクチャは節約家のアーキテクチャ

 Baniasの目的は、CPUの効率を高め、消費電力あたりのパフォーマンスを高めることにある。そして、CPUの効率を良くする大きなポイントは、余計な命令実行を増やさないことだ。そのため、Baniasのマイクロアーキテクチャ(内部アーキテクチャ)では、効率化のための様々な仕組みが取り入れられている。

 Intelは、9月10日から開催されている開発者向けカンファレンス「IDF(Intel Developer Forum) Fall 2002」の技術セッションで、Baniasのマイクロアーキテクチャの概要をかいつまんで説明した。

 Baniasのアーキテクチャのポイントは大きく分けると4つある。

(1)ムダなマイクロOPs(Micro-OPs)の削減
・マイクロオプスフュージョン(Micro-Ops Fusion)
・スタック専用マネージャ(Dedicated Stack Manager)

(2)ムダな投機実行や分岐予測ミスの削減
・分岐予測の強化
・投機実行の最適化

(3)強力な電力管理
・細分化されたハードウェアクロックゲーティング

(4)拡張されたデータ供給
・低消費電力のFSB(フロントサイドバス)
・低消費電力の大容量L2キャッシュ
・改良されたプリフェッチ

 この中でまず目立つのはBaniasがムダなMicro-OPsを徹底して削減していることだ。今のPC向けCPUは、x86命令をいったんデコードして内部命令(マイクロOPs:Micro-OPs)を生成する。CPUの実行ユニットが実際に実行するのは、そのMicro-OPsだ。Baniasでは、このMicro-OPsを減らす、つまりムダなMicro-OPsを発生させないことで省電力化を図る。

 「それぞれのMicro-OPsがマシンリソースと電力を消費する。だからMicro-OPsを減らすことで効率を上げ、電力消費を抑える」と、IntelのOfri Wechsler氏(Director of CPU Architecture, Mobile Platform Group)は説明する。ムダなMicro-OPsがなくなれば、スケジューラや実行ユニットといったCPUリソースの消費が減り、その結果、パフォーマンス当たりの電力消費が抑えられるというわけだ。そのため、Baniasは今分かっている限りでは2つの技術を採用する。
・マイクロオプスフュージョン(Micro-Ops Fusion)
・スタック専用マネージャ(Dedicated Stack Manager)


●メモリアクセスと演算をひとつのMicro-OPsに

Micro-OPs Fusion概念図
 Micro-OPs Fusionは、2つのMicro-OPsをひとつに融合させる手法だ。タクシーに2組の客を相乗りさせた場合、1組の客しか乗せなかった場合と比べて格段に速く多くの客を運べるようになるのと同じ理屈だ。具体的には、メモリアクセスMicro-OPsと演算Micro-OPsをひとつのMicro-OPsにしてしまう。

 今のPC向けCPUは、RISCアーキテクチャの影響を受けており、x86命令をロードストア型アーキテクチャのMicro-OPsに分解するCPUが多い。つまり、x86命令には、メモリアクセスをともなう演算命令があるが、それをCPU内部でメモリアクセスMicro-OPsと演算Micro-OPsに分解してしまう。例えば、加算命令で、オペランドの片方がメモリ、もう片方がレジスタである場合、CPUはメモリからデータをロードして、それをレジスタの値に加算する処理を行う。そのため、今のCPUは、この命令を、ロードMicro-OPsと、加算Micro-OPsに分解する。

 分解する目的は、並列化された演算ユニットで実行するスーパースカラ実行をする時に、円滑に処理できるようにするためだ。ロードストア型アーキテクチャのMicro-OPsに分解してしまえば、演算Micro-OPsは演算ユニットで、ロードやストアMicro-OPsはロードストアユニットでといったように、実行ユニットを役割ごとに単純化できる。各ユニットに対して、Micro-OPsを実行できる順番に発行するアウトオブオーダ(Out-of-Order)制御を行うことで、並列実行を行う。

 この方法は非常に有効なのだが、難点もある。それは、x86命令を分解することでMicro-OPsが増えてしまうため、CPU内部のリソースやMicro-OPs帯域がより消費されてしまうことだ。つまり、ムダが多いわけだ。

 そこで、Baniasでは、メモリアクセスをともなう演算命令を、デコーダの段階では2つのMicro-OPsに分解しない。メモリ操作と演算の2つのオペレーションを含むMicro-OPsを生成する。そして、実際に実行ユニットにMicro-OPsを発行する段階で、2つのMicro-OPsに分解して、実行する。つまり、デコーダから実行ユニットまでの間で、2つのMicro-OPsが占有するリソースを1つに減らすことができるわけだ(その意味で、Micro-OPs Fusionは、実際にはフュージョン(融合)というより、分解しないと言った方が合っている)。

 Intelによると、これで10%のMicro-OPsを減らすことができるという。つまり、10%分、実行ユニットやスケジューラの効率が向上し、電力消費が減るわけだ。


●Athlonと似たアプローチ

 Micro-OPs削減では有効なMicro-Ops Fusionだが、ある程度似たような技術はすでに存在する。それは、Athlon(K7)/Hammer(K8)系アーキテクチャだ。Athlon/Hammerも、メモリアクセスを含む演算命令は、ひとつのMicro-OPsに変換、実行時に2つのMicro-OPsに分解する。基本的なアプローチは非常に似ているように見える。

 この手法のためにAthlon/Hammerでは、演算ユニットは整数演算ユニット(ALU)とロード/ストアアドレス生成ユニット(AGU)が1個づつペアになった、3組のユニットペアで構成されている。つまり、各ペアが演算Micro-OPsとメモリアクセスMicro-OPsの統合されたMicro-OPs1個に対応するようになっている。そして、各ペアの前に、Out-of-Orderのキュー(Hammerでは8段)があり、そこでMicro-OPsは待機する。

 キューがあるのは、メモリアクセスMicro-OPsと演算Micro-OPsの間に依存関係がある場合があるからだ。先ほどの加算命令の例だと、ロードMicro-OPsを実行して、その結果を待って加算Micro-OPsを実行しなければならない。そのため、ロードMicro-OPsを実行したあと、実際にデータがロードされるまで、演算Micro-OPsはキューに待機している。

 Athlon/Hammerはこの構造のため、ALUとAGUをそれぞれ3個づつ搭載するという冗長な構造になっている。では、Baniasの場合はどうなるのか。これについては、今回は何もヒントがない。しかし、Athlon/Hammerのような単純な構造ではないような気がする。


●スタック操作を専門に行うユニットを搭載

Dedicated Stack Manager概念図
 もうひとつのMicro-OPs削減手法、スタック専用マネージャ(Dedicated Stack Manager)も革新的な技術だ。

 もともと、x86アーキテクチャの弱点は、煩雑なスタック操作のオーバーヘッドにあった。x86命令は、古い命令セットアーキテクチャであるため、スタック操作命令(PUSH、POP、RET、CALLなど)を多く使う。これらは、スタックポインタの操作を行う必要があるため、CPUの高速化上の妨げであるだけでなく、CPUの効率を下げていた。

 「スタック操作は、典型的にはメインの実行ステップで処理されていた。デコーダはスタック操作のためのMicro-OPsを生成し、32bit ALUは、単にスタック操作のために動作していた。非常に非効率的なマシンリソースの使い方だった」とIntelのWechsler氏は説明する。

 そこで、Baniasではスタック操作を専用に処理するハードウェアユニットを設けることで、この問題を解決する。つまり、スタック操作を伴う命令が来た場合、デコーダはスタック操作Micro-OPsを生成するのではなく、スタック操作専用に作られたDedicated Stack Managerと通信する。そして、Dedicated Stack Managerがスタック操作を行なうことで、ムダなMicro-OPs生成を削減する。また、Dedicated Stack Managerはスタック操作だけに特化して作られているため、ALUよりも消費電力が少ないというわけだ。

□関連記事
【9月12日】【海外】7,700万トランジスタを電力効率向上に費やす「Banias」
http://pc.watch.impress.co.jp/docs/2002/0912/kaigai01.htm

バックナンバー

(2002年9月13日)

[Reported by 後藤 弘茂]

【PC Watchホームページ】


PC Watch編集部 pc-watch-info@impress.co.jp
個別にご回答することはいたしかねます。

Copyright (c) 2002 Impress Corporation All rights reserved.