第46回 IA-32の64bit化は福音か？：頭脳放談

IA-32の64bit拡張について思うところをコメントする。IntelがAMDの後追いとなった理由や、64bit拡張の意味について想像を交えながら解説しよう。

» 2004年03月30日 05時00分公開

　発表されて1カ月も経ってしまったが、Intelがついに踏み出したIA-32アーキテクチャ（x86プロセッサ）の64bit拡張＊1について、遅ればせながらひと言コメントさせていただく。すでに多くの論評がなされているのに申し訳ないのだが、筆者はその昔、x86互換プロセッサを設計していたこともあり、x86プロセッサには特別な思い入れがある。Intelが、なぜx86プロッサの64bit化を選択したのか、想像を交えながら解説しよう。

＊1　64bit拡張を行ったIntel Xeon（開発コード名：Nocona）は、2004年第2四半期に出荷される予定だ。64bit拡張に対応したOSとして、Red Hat Enterprise Linux 3とSuSE Linuxが2004年第2四半期にリリースされる。Windows Server 2003はService Pack 1と、Windows XPはService Pack 2のリリース・タイミングでIA-32アーキテクチャの64bit拡張とAMD64に対応するとしている。

苦渋の選択を行ったIntelの思惑

　今回の発表は、Intelにしたら「苦渋の」選択であったと評されている。何せ、もう10年近く推進してきているItaniumプロセッサ・ファミリ（IPF）という立派な64bitプロセッサがあるのに、それと一部で市場が重なるプロセッサの投入である。また、一時期は不倶戴天（ふぐたいてん）のごとく争っていた相手であるAMDに、本家のIntelが合わせざるを得なかったこともその理由として挙げられている。

　しかし、顧客満足を考えれば、もっと早くに踏み出してもよかった一歩かもしれない。多分Intelには、IPFにおけるx86系ソフトウェアの実行性能の低さを批判する声が多数届いていたはずである。IPFのx86系ソフトウェア実行にいろいろと改良を施してきているのが、その証拠である。ソフトウェア・エミュレーションによるx86系ソフトウェア実行環境の「IA-32 EL」なども、将来的なx86系ソフトウェアの性能向上を目指したてこ入れの1つだ。だが、IPFのx86実行エンジンに小手先の改良を施しても、現時点では、なかなかユーザーを納得させられる性能が得られないことも痛感していたはずである。IPFは、x86系ソフトウェアを高速に実行するためのプロセッサではなく、32bitから64bitへのスムーズな移行のために、「x86系ソフトウェアも実行できる」プロセッサとして計画されたからだ。設計当初から、x86系ソフトウェアの実行性能は、それほど重視していかなったのだから、いまさら性能向上を目指しても、自ら限界がある。

　多分、IPFを計画した当初、IntelはIA-32アーキテクチャ（x86）からIPFへの急速な移行を確信していたはずである。圧倒的な市場シェアを獲得する中でのIPFの導入であったからだ。しかし、この移行プランはスムーズに行かず、いつのころからか、サーバ側はIPF、クライアントPC側はIA-32アーキテクチャという「すみ分け」に戦略を転換せざるを得なくなっていく。こういう戦略の転換をしたこと自体、元の計画に市場とそぐわないものがあった証拠だ。にもかかわらず、市場を先導するのは自分たちだという意識があるせいか、自らの計画にないものを受け入れるのに時間がかかったようだ。結果、AMDがx86プロセッサの64bit化を発表し、それが市場に受け入れられてしまうまで、x86プロセッサの64bit化に踏み出せなくなっていたのではないかと思う。自社の大戦略に手足を縛られていたために動きがとれなくなっていたのだ。

IntelのAMD互換で面白い市場が生まれた？

　ここに来て64bit化に踏み出したのは、予想より早かったという声がもっぱらのようである。だが、AMDの64bitプロセッサ（AMD OpteronとAMD Athlon 64）の普及予測を考えればギリギリの線であったのではないだろうか（AMDの64bitプロセッサについては「第35回 AMDの64bit拡張に見るアーキテクチャの発散を考える」参照のこと）。IBM、Sun Microsystemsに続き、Hewlett-PackardまでもがサーバにAMD Opteronを搭載することを発表している。Dellを除けば、大手サーバ・ベンダのほとんどが採用を決めたことになる。

　仕様をAMDに合わせざるを得なかったことにも、大きな決断が必要であったと予想する。いまの時点でいえば、AMD互換を採用したことは、ソフトウェア的に考えると当然の判断である。x86という世界の中で2つ異なる64bitアーキテクチャが並び立つようなひどいことにならずに済んで本当によかった。IA-32アーキテクチャの個性を考えれば、だれが64bit化をしようと似たようなものになるだろうが、オブジェクト・コード・レベルの互換性がとれるほど似るとは思えない。もし、Intelが自分のメンツにこだわって独自方法で64bit化していたら、Intelが一敗地にまみれるところが見られたかもしれない。

　しかし、もしもである、AMDにやや遅れた程度の時期にIntelもx86の64bit化を考えていたならば、AMDに合わせるどころか逆にIntelが主導権をとり、先に64bit化したAMDがIntelの64bit仕様に合わせて直さざるを得ないような状況に追い込むことだって可能だったはずだ。ちょうどAMDがSIMD拡張命令の3DNow!をリリース後に、IntelがストリーミングSIMD拡張命令（SSE）をリリースし、その結果、AMDがSSEをサポートした3DNow! Professionalをリリースせざるを得なかったのと同じだ。AMDにとっては、x86の64bit化は必然かつ唯一の活路であった。一方Intelは、それをするだけの十分なリソースがあったが、自分の立てた戦略と違うのでそれをしなかっただけである。「土俵」を変えて、1人不戦勝を決め込もうとしたのが間違いであった。

　ようやくIntelもx86の64bit化にのった結果、第三者から見れば非常に面白い「土俵」が出来上がった。AMDとIntelのガチンコ勝負は続くのである。競争が続けば、進歩は早い。まだIntelはIPFとのすみ分けにこだわっているそぶりであるが、ぼやぼやしているとIPFの居場所がなくなるところまで競争が進む可能性だってある。もし、IPFが失敗したとすると、Intelにしては3度目の挫折となる。1度目は8086から32bit化を行う時点でリリースした「iAPX432」、2度目はRISCプロセッサの対抗としてリリースした「i860」である。いずれもx86プロセッサとは異なるアーキテクチャで、高度な世界を開くことを狙った戦略プロセッサであった。だが、残念ながら市場は、多くの資産を持つx86プロセッサとの互換性を選んだ（それ以外にも理由はあるのだが）。つまり、これまでIntelの歴史の中で、x86プロセッサと異なるアーキテクチャを採用したプロセッサは、ことごとく失敗している。x86プロセッサの64bit対応を行うことで、IPFがその轍を踏む可能性も出てきたわけだ。

　AMDにすれば、折角よい稼ぎ場所を見つけた矢先に、別な場所に行ったはずのIntelが舞い戻ってきて残念というところだろうか。しかし、Intel参戦でx86の寿命はますます延びることは間違いない。また対応アプリケーションも次々とリリースされることになるだろう。この事態はAMDにとってもある意味望むところといえるかもしれない。

　それにしてもx86の寿命の長さには恐れ入る。アセンブラ・レベルの互換性までいうならば、実に8008以来の伝統となり、その歴史はマイクロプロセッサの歴史とほぼ重なる。この先どこまで命脈を保つのか末の末まで見届けたいものだ。

■関連記事