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

2013年01月07日 12時00分更新

　今回は久しぶりに、CPU黒歴史の続編をお届けする。ネタはトランスメタの「Crusoe」と、後継製品の「Efficeon」だ。なおCrusoe/Efficeonの悲しい歴史については、連載58回でも取り上げている。

　58回でも触れているが、CrusoeやEfficeonが成功しなかった最大の理由は、TSMCの0.13μmプロセスを上手く扱えなかったためだ。これによる失速で市場を失った結果として商業的に立ち行かなくなった。Crusoeは第2世代の生産が1年遅延。Efficeonにしても、90nmプロセスで省電力化技術「LongRun2」を実装した製品は、結局登場せず、これが失速の原因となった。

　ようするに、どちらもプロセス技術がボトルネックになっていたわけで、「生産に必要なプロセス技術を十分に持っていなかった」というのが、結果論としてのCrusoe/Efficeonの黒歴史入りの最大の要因である。失敗の原因はこのとおりだが、今回は視点を変えて、Crusoeの内部構造について説明したい。

インテル/AMD CPUとは異なる独特の構造

Crusoe TM5800(右)、左はTM5600

　CrusoeとEfficeonは、独特な内部構造を持っている。覚えている方も多いと思うが、Crusoe/Efficeonは、「受け取った命令を内部で独自命令(Atom)に変換し、これをVLIW式のRISCコアで処理する」という方式になっている。これを同社は「Code Morphing」と称した。Code MorphingがインテルやAMDの「μOp」と根本的に異なるのは、元のx86命令と変換後の独自命令が、1対1の対応にならないことだ。

　x86命令をそのままの形ではなく、内部でRISC命令風に置き換えて処理する方式を、x86プロセッサーとして最初に実用化したのは、NexGenの「Nx586」だ。インテルの「Pentium Pro」やAMDの「K5」がこれに続いた。とはいえ、インテルやAMDはNexGenの方式を真似したわけでない。CPUの開発期間は数年かかることを考えれば、各社が同じ時期に「x86命令のまま処理するのは効率が悪いから、内部変換をかけよう」と思いつき、結果的にNexGenが先行して製品化に成功したという程度の話でしかない。ただし、これらはいずれも命令単位での変換である。

お詫びと訂正：掲載当初、x86でRISC命令への置き換えを実用化したのは「Pentium Pro」としていましたが、正しくはNexGenの「Nx586」でした。ここに訂正するとともに、お詫びいたします。(2013年1月15日)

　トランスメタの方式はそれよりも上のレベルで、「与えられたx86命令を実行した場合と同じ結果になるように、別のアーキテクチャーで処理させる」というアイデアである。一例を挙げると、例えばCrusoeは「Condition Code」をサポートしていない。Condition Codeとは、ある特定のレジスタの状態に応じて、機能を変える命令のことである。条件分岐がその例だ。