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

CPU黒歴史 改めて振り返るCrusoe/Efficeon失敗の理由

パイプラインはわずか6段!?
シンプルなCrusoeの構造

　Crusoeは命令単位ではなく、複数命令にまたがって処理の意味を解釈するため、トランスメタの方式はインタプリタであると理解されている。CPUコア以外で近いものとしては、Javaの仮想マシンやMac OS Xに搭載されていた「Rosetta」^※1、あるいはRosettaの元になったと言われている、Transitive Technologies社の「Dynamite」などが挙げられよう。もっとも、Dynamiteは「Software version of Transmeta's Code Morphing」(トランスメタのCode Morphingをソフトウェアで実現したもの)なんて言われたように、Code Morphingの方が先に登場している。
^{※1 インテルCPU搭載MacでPowerPC用プログラムを動かす変換処理技術。}

　当然ながらこうしたインタプリタを使う場合、処理のオーバーヘッドは避けられない。それは単に処理性能を落とすだけでなく、インタプリタを動かす分だけ消費電力も増加することになる。それにも関わらずCrusoeがこれを搭載したのは、「Code Morphingで最適化したら、あとは圧倒的に低い消費電力で処理を実現できる」という目算があったためだ。ではそれはいかなるものか。

図1 Crusoeの命令フォーマット

　図1はCrusoeの命令フォーマットである。Crusoeは128bitの命令幅で、32bit命令を同時に4つ処理可能となっている。ただし、この4つの命令がどういう組み合わせになるかは、厳密に決まっている。例えば「Atom 1」に入るのはMemory命令だけで、ここにALU命令を入れることはできない。その意味では、4命令同時発行といいつつも、この4つのAtomを同時に処理するというケースは非常にまれである。平均では1.x～2.x Atom/サイクルというのが、当時のトランスメタの発表であった(アプリケーションによって変わる)。

図2 Crusoeのパイプライン構造

　命令を処理するパイプラインは、図2のようにわずか6段しかない。文献によっては、「Writeback」の後に「Commit」というフェーズを入れて7段としていることもあるが、処理にはあまり関係ないので、ここでは割愛する。

　パイプラインの最初にFetchが2つ入るが、これは128bit長の命令を、64bitずつ2回に分けて取り込むためだ。次のDecodeは命令の解釈である。といっても、CrusoeはVLIW方式で、しかもAtomごとに処理が限られているので、複雑な命令がまとめられている「Compute」に当たる「Atom 2」以外は、比較的簡単である。また、同時にレジスタからの読み込みを行なう。

　次に、Atomごとに2サイクルずつを使って、それぞれを処理する。ちなみにAtom 2に関しては、整数演算に関しては1サイクルで実行できるが、浮動小数点演算だと5サイクルを要する。逆に、Atom 4の分岐は1サイクルで実行できるので、1サイクル分のウェイトを入れて帳尻を合わせている。

　これらが終ったら、最後にWritebackで結果をレジスタに書き戻して終了である。x86プロセッサーのパイプラインを見慣れた人にはあっさりしているというか、こんなにシンプルでいいのかと思えるほど、簡単な構造である。x86が面倒なのは、デコード後にスケジューラーが入って命令実行順の並び替えをしたり、「ROB」(Re-Order Buffer)を使って完了した命令を管理したりといった処理を動的に行なう必要があるからだ。VLIWの場合、そうした処理をあらかじめプログラムを記述する段階で済ませるのが前提だから、ハードウェアそのものは非常にシンプルですむ。