■元麻布春男の週刊PCホットライン■ “サンフランシスコ最大の秘密”の衝撃

●“サンフランシスコ最大の秘密”は64bit拡張

　2月17日からのIDF 2004 Springは、今回から場所をSan Franciscoに変えてスタートした。これまで開催地の選択のせいもあり、雨とは無縁だったIDFだが、今回は時折の雨と強風で嵐のような天候での開催となってしまった。

　その天候のせいでもないだろうが、IDFの中身にもちょっとした嵐があった。いわずとしれた“64-bit extension technology”である。それは初日のクレイグ・バレット会長兼CEOのキーノートで、実にさりげなく、すでに公表済みの技術とともにステージ上に現れた。

　64-bit extension technologyはバレット氏から「サンフランシスコ最大の秘密」と紹介されたが、プレゼンテーションもスライド1枚だけと簡潔なものだ。

　事前には「Yamhill」というコード名やCTといった名称が取りざたされていたが、紹介された名称は単に「64-bit extension technology」あるいは「64-bit memory extension technology」であり、キャッチーな商標はない。

　しかも、Intelはまもなくリリースされる次世代のXeon DP(Nocona)を皮切りに、サーバー/ワークステーション向けプロセッサにこの64bit拡張技術を採用していく、というだけで、詳細については触れられなかった。

　このバレット会長のキーノートだけでなく、64-bit extension technologyについては特に関連したセッションが用意されているわけでもない。64-bit extension technologyの登場時期が近いこと、ソフトウェアによる対応を必要とすること、しかもその対応はサードパーティ(ISV)だけでなく、コンパイラベンダでもあるIntel自身の対応を必要とするものであるにもかかわらず、何も言わないというのはむしろ不自然な気さえする。

　だが、その答えはキーノート後のQ&Aにあった。バレット会長は、AMDとの互換性に対する質問への回答として、AMDのプロセッサ(Opteron/Athlon 64)とIntelのプロセッサは基本的にアーキテクチャが異なると前置きしながらも、同じOSやアプリケーションを両社のプロセッサ上で動かすことは大半の場合可能だ、としたのである。

　これは、IntelのWebサイトに上にある「64-bit extension technology」のページに用意されたFAQに書かれているのとほぼ同じ回答で、おそらくは想定問答集通りの答えなのだろう。いずれにしても、AMDとIntelの64bit拡張プロセッサは互換性を持つことが明らかにされた。

キーノートスピーチに立ったクレイグ・バレット会長	64-bit extension technologyに関する唯一のスライド

●メインストリーム事業で初の妥協

　IntelがIntelアーキテクチャ事業というメインストリームの事業において、他社の実装に倣うのは、これが初めてのことではないかと思われる。

　プロセッサのRISC化など、他社がすでにインプリメントした技術的アイデアをIntelが採用することはそれほど珍しくないが、他社が策定した仕様を後追いで採用するのは、珍しいことだ。

　奇しくもバレット会長が述べた通り、両社のマイクロアーキテクチャは異なる。にもかかわらず、たとえば64bit拡張におけるレジスタ仕様の拡張(追加する汎用アドレスおよびSIMD命令用のXMMレジスタの数や名称など)の類似性は、明らかに互換性を持たせるように調整したとしか思えないものだ(もちろん、互換性をなくすための恣意的な違いを作り出していては、業界からの反発は避けられないところだが、そう思われないだけの違いを打ち出す方法はあっただろう)。

　そもそもIntelアーキテクチャのプロセッサというのは、Intelが知的所有権(IP)を持つ技術をトランジスタで表現したものであり、いわゆるx86互換である必要すらないのはIA-64を考えれば明らかだ。そうであるからこそ筆者は前回IntelはAMD互換にはしないだろうと考えたのだが、どうやらその前提が崩れてしまった。

　もちろんIntelはIA-32そのものがIntelのIPであり、64-bit extension technologyが加わってもそれに変わりはない、というのだろう。IA-32プロセッサに対する64bit拡張部分のIPを持つのが誰かは明らかにされていないが、一般的に考えてAMDが保有すると考えるのが自然だ。既存の動作モードであるIA-32モードに対し、64bit拡張が有効になる動作モードをIA-32eモードとしているがIA-32Aモード(もちろんAはAMDのA)と言われても仕方がないのではないか。64bit拡張部のIPの取り扱いについては、IntelとAMDの2社間で話し合われ、その内容が外部に公表されることはないだろうが、AMDが点数を稼いだことは間違いない(両社は定期的にクロスライセンス契約を更新しているが、これがAMDに有利になっても不利になることはないだろう)。

●Windowsサポートが互換性の理由

　さて、前回の筆者の予想の前半部の骨子は、Intelは自社のメインストリーム事業に他社のIPを持ち込まない、というもので、これが外れた以上、後半部も外れるのが必然なわけだが、あえて書いておくと、それはMicrosoftのサポートをアテにするな、というものであった。もちろんこれはMicrosoftのサポート(要するにMicrosoftによるOSの対応)が不要であるということではない。実際は逆でクリティカルなのだが、アテにするなといったのはMicrosoftからの援軍は到着に非常に長い時間がかかるのが常であるからだ。

　たとえば386プロセッサがリリースされたのは'85年10月のことだが、Microsoftが386 Enhancedモードを備えたWindows 3.0をリリースしたのは'90年5月(英語版)のことだ(その少し前にWindows 386をリリースしているが売れたとは言いがたい)。

　Windows NTがリリースされてから(日本語版のWindows NT 3.1が'94年1月)、量販店にならぶPCにその流れをくむOSが普通にプリインストールされるまで(2001年1月のWindows XPリリースまで)7年を要している。OSがリリースされてから、ドライバが整備され、対応アプリケーションが揃うにはそれくらい長い時間がかかる、ということだ。

　逆にいえば、そのプロセスを握っているからこそMicrosoftは強いのであり、IntelもMicrosoftの要請(64bit拡張では仕様を統一するように)に従わざるを得なかった、ということかもしれない。今回バレット会長は、クライアントにおける64bit拡張については一切触れなかったし、Intelからは当面の間において否定的なニュアンスの発言が聞こえてきているが、それはこうした時間のかかるプロセスを必要とすることが理由の1つだろう(ただしVanderpoolテクノロジ等を考えれば、たとえ単独のアプリケーションが必要としなくても、プラットフォームとして大容量のメモリはクライアントでも必要になるだろう)。逆にIntelが64bit拡張をサーバー/ワークステーションに限定する理由は、クライアントに比べれば、ドライバサポートやアプリケーションのサポートが限定的でも何とかなる、と考えているからかもしれない。ちょうどItaniumがそうであるように。

　前回も触れたように規模の劣るAMDは、孤立すると不利な立場に陥りやすい。これは自前の3DNOW!路線から事実上SSE互換路線へと転進せざるを得なかった事情とも共通する。IntelがAMDと64bit拡張プラットフォームを共有する意思を見せたことで、AMDは3DNOW!の二の舞を避けることができた。これは大きなプラスだろう。加えてIntelがAMDに従った、というイメージアップ効果も期待できる。

　Intelで微妙なのはIA-64プロセッサの位置づけだ。IA-64に関してIntelは、性能やスケーラビリティの違いで両者は住み分けるとしているが、圧倒的に数で上回るであろうXeon製品系列とAMDのOpteronが共通のソフトウェアプラットフォームとなることで、ニッチプロセッサ的な印象が強まることは否定できない。IntelはIA-64のライバルをOpteronではなく、SunやIBMのRISCプロセッサだとしているが、位置づけまでRISCプロセッサのよう(安価なIAプロセッサの攻勢を受ける高価なプロセッサ)になってしまう危険性をはらんでいる。

□Intelのホームページ(英文)
http://www.intel.com/
□IDFのホームページ(英文)
http://www.intel.com/idf/us/spr2004/index.htm
□Intel 64bit Extension Techonology
http://www.intel.com/technology/64bitextensions/
□関連記事
【2月18日】【IDF】64bitアドレス拡張を実装したXeonを第2四半期に出荷
http://pc.watch.impress.co.jp/docs/2004/0218/idf02.htm
【2月13日】【元麻布】Yamhillについてのもう一つの予想
http://pc.watch.impress.co.jp/docs/2004/0213/hot302.htm

□バックナンバー

(2004年2月19日)

[Text by 元麻布春男]