■後藤弘茂のWeekly海外ニュース■ 命令フォーマットの改良で効率をアップしたEfficeon

●トランスレーションキャッシュの効率を高める命令フォーマット

　EfficeonもCrusoeと同様に、メインメモリ上にCMS用のトランスレーションキャッシュ領域を確保する。CMSが変換したVLIWのネイティブコードや、新たに加わった様々な付加情報がここに格納される。Transmetaアーキテクチャの鍵はこのキャッシュ量で、Efficeonデモでは32MBを確保していた。Efficeon世代ではメインメモリ量が増える分、キャッシュ領域も増やすと見られる。

Efficeon

　「Efficeonのトランスレーションキャッシュの量は、Crusoeと同様に完全にフレキシブルだ。フラッシュの中にセットしたパラメータで自在に調整できる。考え方としては、メインメモリの量が増えるにつれて、同程度のパーセンテージでトランスレーションキャッシュもある程度増やしていく。今日ではメインメモリの容量は256MBが一般的で、すぐに512MBがミニマムになる時代が来る。だから、トランスレーションキャッシュもちょっと増やすことになるだろう」(Ditzel氏)

　結局は、オンメモリにあるコードのうちどれだけを変換してキャッシュするかという話になるわけで、Transmetaとしては一定比率でキャッシュ量を維持したいと思われる。もっとも、キャッシュの中身の効率は、Efficeonの方がずっと高くなるという。それは、Efficeonではコードエクスパンション(code expansion)を抑えられるからだという。

　VLIW型アーキテクチャの弱点の1つはコードエクスパンション、つまりバイナリコードの大きさが増大してしまうことだ。例えばEfficeonの場合、たった1つしか命令スロットが埋まっていないようなケースがあると、本来32bitで済む命令長が256bitに拡張されることになってしまう。それだけ、モーフィングキャッシュ(CMSが変換した命令のキャッシュ)が食われてしまう上に、メモリ帯域も必要になる。

　Efficeonでは、Crusoeから命令長が2倍になったことで、この問題は非常にクリティカルになった。特に、1段ギアのインタプリタの生成するコードは、1サイクルで1～2個程度のatomしか生成されないケースが多いと思われるため、問題が大きい。そこで、TransmetaはEfficeonでは一種の可変長フォーマットを取ることでこれを解決する。

　「Efficeonは、Crusoeと比べてコード効率も非常に改善された。どちらもatomは32bitフォーマットだが、Crusoeの時は、atom 4個の128bit長とatom 2個の64bit長の2つのフォーマットしかなかった。そのため無駄が生じていた。しかし、Efficeonでは8サイズになった。つまり、atomが1個でも2個でも、3/4/5/6/7/8個のどのサイズにでもできる。そのため、キャッシュもずっと効率的になった」とDitzel氏は言う。

　Crusoeでは2つの命令長で、命令スロットの内容が異なる6つの命令フォーマットがあったが、Efficeonではこの仕組みはどうなっているか、今のところわからない。また、オリジナルのVLIWの発想は固定長の命令フォーマットで、各命令スロットに入るオペレーションを固定することで、命令フェッチと命令発行をごくシンプルにしていた。つまり、利点と難点のトレードオフだったわけだ。IntelはVLIWのこの弱点を克服するために、IA-64では3命令バンドルというシステムを導入した。Efficeonの場合こうした柔軟なフォーマットにした場合、フェッチや発行には余計な手間がかかるはずだ。

TransmetaのVLIW命令のフォーマット PDF版はこちら	VLIWのコードエクスパンション問題 PDF版はこちら

●フェッチを含めても比較的短いパイプライン

　もっとも、それでもEfficeonのフェッチユニット自体は「非常にシンプル」(Ditzel氏)だという。L1命令キャッシュからの、フェッチ処理はキューも合わせて3段だという。整数演算は下のように6段なので、プラス3段で最大9段のパイプラインとなる。

IS: 命令発行(Instruction Issue)
DR: 命令デコード(Instruction Decode)
RM: レジスタリード(Register Read for ALU operands)
EM: 実行(Execute ALU operation)
CM: コンプリーション(ALU Condition flag completion)
WB: ライトバック(Write Back results to integer register file)

　パイプラインでのCrusoeとの違いで目立つのは、命令発行+デコードで2段になっていることで、より命令発行が複雑になっていることをうかがわせる点だ。しかし、「依然として、他のアーキテクチャと比べたらずっと短いパイプラインで、ペナルティが少ない」(Ditzel氏)。

　ロード命令の場合は、上のパイプラインに1段ステージが増える。ちなみに、Crusoeではload＋addタイプのx86命令は、loadとALUの2つのユニットに分ける必要があった。しかし、Efficeonではload/storeユニットが整数add機能を持っているため、x86命令を分割せずに実行できるようだ。これも、インタプリタ性能を高めるのに役立っていると思われる。

●レジスタ総数は各112本づつ

　Efficeonは、膨大なレジスタリソースを備えることも特徴だ。レジスタは整数レジスタが32bit幅で64本。浮動小数点レジスタが80bit幅で64本。これはいずれもCMSのリアルタイムコンパイラが直接扱えるレジスタ空間で、x86命令のレジスタを、各64本の物理レジスタ群にCMSがマップする。Transmetaアーキテクチャではatomのサイズは32bitで、レジスタは6bitで表現するため、64本が論理レジスタ数の限界となる。

　このほかに、整数/浮動小数点レジスタとも、それぞれ48本づつのシャドウレジスタを備える。演算結果はこのシャドウレジスタにも書き込んでおいて、例外処理が発生した場合は表のレジスタに書き戻す。この裏レジスタを合わせると、合計では両レジスタとも112本づつを備えることになる。ほとんど、IA-64 CPU並みの数だが、これはコンパイラでの最適化の自由度のために必要だと思われる。

　ちなみに、Intelアーキテクチャでは、SSE2のために128bit幅の専用レジスタXMM(8本)を設けている。しかし、Efficeonでは128bitレジスタは持たない。

　「64bitの浮動小数点レジスタを2つ組み合わせて対応する。その方が効率的だからだ。実際のオペレーションでは、128bitだけでなく、64bitや32bitもある。少ないオペレーションのために、128bit幅のレジスタを新設するのは非効率になってしまう」とDitzel氏は説明する。

　膨大なEfficeonのレジスタリソースだが、実際には、今のx86系CPUも、見かけ上の論理レジスタ以上の数の物理レジスタは備えている。CPU内部でレジスタリネーミングを行ない、物理レジスタにマップすることで、レジスタの衝突を避けている。同じことをTransmetaアーキテクチャではCMSが行うため、論理上のレジスタ数も多いわけだ。

EfficeonのVLIW命令 PDF版はこちら	x86とEfficeionのレジスタ PDF版はこちら

●ようやくハードウェアDMAを搭載してI/O性能を向上

　EfficeonではCrusoeより性能がよくなる理由が、マイクロアーキテクチャ以外の部分でもある。それはI/O性能だ。

　「Crusoeの秘密をひとつ教えよう。Crusoeが時々遅かった理由のひとつは、全てのI/Oアクティビティ、これはDMAをコールするのだが、それをソフトウェアで実現していたからだ。DMAアクティビティが走っている間は、プログラムを実行できない。それが性能に影響していた。じつは、CMS自身が遅かったわけではない。

　それに対して、EfficeonではハードウェアDMAを備えているため、DMAアクティビティとソフトウェア実行は並列で行なえるようになった。そのため、性能は大きく向上している。

　なぜCrusoeでそんな設計にしたのか? それは、市場に迅速に導入するためだ。I/Oシステムにバグはつきもので、そのため、我々が経験を積むまではソフトウェアで実現する方が容易だった。問題が見つかっても、ハードではなくソフトを直せば済んだからだ。パフォーマンスでは、不利なのはわかっていたが、仕方がなかった。

　Efficeonでは、AGPも備えたため、PCIしか持たなかったCrusoeと比べるとグラフィックスも速くなる。I/Oでの並列処理度が増したために、全体のスループットは向上した」

　こうDitzel氏は説明する。

　こうして見ると、じつはCrusoeは、かなり習作的な部分があったことがわかる。CMSの最適化の手法や、マイクロアーキテクチャを見ても、Efficeonの方がCrusoeよりはるかに成熟している。その意味では、Efficeonこそ、Transmetaのアーキテクチャの完成形だと言えるだろう。つまり、もっと前に登場すべきチップだったと思われる。

□関連記事
【11月4日】【海外】なぜEfficeonはCrusoeよりも効率が高いのか
http://pc.watch.impress.co.jp/docs/2003/1104/kaigai041.htm

□バックナンバー

(2003年11月6日)

[Reported by 後藤 弘茂(Hiroshige Goto)]