この実績をベースに、次にIntelの前に立ちはだかったのがMicrosoftである。Microsoftとしては、なるべくアーキテクチャを収斂させたかった。そうでなくてもIntel向けには既にItanium向けのサポートを行っており、加えてAMDのx86-64のサポートをほぼ決めていた。ここに来て、さらにYamhillのサポートを行うのはMicrosoftとしては避けたい事態なので、Intelに対してYamhillではなくx86-64の採用を強く働きかけることになった。
もともと2002年のCOMPUTEX TAIPEI 2002ではWindows.NET Serverのx86-64版プロトタイプを、やはりプロトタイプのOpteron上で動作させて見せるデモが公開されていた(写真3)が、2003年にはそのx86-64に対応した64bit Windows XPの動作デモを公開して、Microsoftはx86-64をサポートする(≒Yamhillはサポートしない)ことをアピールするなど、プレッシャーを掛けまくった。
公式な場でこれだけプレッシャーを掛けるのだから、非公開な場ではさらに強く押したであろうことは疑う余地もない。最終的にIntelはYamhillを放棄、EM64Tという名前でx86-64を受け入れるに至る(写真4)。
ちなみにこの名称も変遷が多く、最初はCT(Clakamas Technology)、次にIA-32e(extensions)、EM64Tと来て、最後にIntel 64に落ち着いている。
ただ、名前の変遷はともかくインプリメントそのものは割とすんなり行われた。最初の搭載製品は2004年6月に発表されたNoconaで、これに続きデスクトップ向けにも2005年2月にE0 SteppingのPrescottがPentium 4の600番台で投入されている。
これが可能になったのは、Prescottの特異なパイプライン構成のお蔭である。元々Willametteに始まるPentium 4というかNetburst Architectureは、パイプライン段数を長大にすることで動作周波数を高く引き上げられる。言い換えると動作周波数を高く引き上げることで性能を確保する、いわば高回転型エンジンであり、Willametteやこれに続くNorthwoodはパイプライン段数が20段を超えていた。ところがPrescottはこれを凌ぐ30段以上のパイプライン構成であった。何故かといえば、命令デコーダをHard-wired(回路を完全にハードウェア的に作り込む)ではなく、完全にMicrocodeでの実装になっていたことに起因する。
要するに、Microcodeを入れ替えるだけで、ハードウェアを全く変更することなく、異なるアーキテクチャに対応させることが可能になる訳だ。おそらくはYamhillと並行してPrescottのアーキテクチャ開発は始まっていたはずだが、この時点で既にx86-64の情報は公開されていた訳で、Intelの中ではPlan C(これがClakamas Technology)も並行して走っていた、というか念のために走らせざるを得なかったのだろう。ただYamhillとClakamas Technologyの両方に対応するデコーダなんて作っていたら規模が馬鹿でかくなりすぎる。
であれば、Microcodeの入れ替えで両方に対応できるように作る方が賢明、という判断だったのだろう。代償は性能と消費電力で、実際90nmに移行させたにも関わらず性能そのものはNorthwoodと大差ないというか、むしろ落ちるシーンも少なくなかった。消費電力はどちらかと言うと90nmプロセスそのものが問題であったが、30段を超えるパイプラインで省電力化というのが土台無理な話で、ユーザー目線から見れば落第に近い製品扱いされている。ただIntelからすれば、x86-64をキャッチアップするために無くてはならない存在であり、イスラエルの設計チームがConroeベースのCore 2を完成させるまでの間を繋いでくれる貴重な存在であった。
サーバ向けにはそんな訳で2004年以降は急速に64bitへの移行が始まるが、普通のコンシューマー向けで明確に移行が始まったのは2009年のWindows 7から。2015年に登場したWindows 10で「何かやむを得ない理由がない限り、32bitはお勧めしない」となり、Windows 11で「32bitはサポートしない」にたどり着いた。x86-64の登場から20年以上掛けて、やっとPCは32bitから64bitに移行した訳だ。
Copyright © ITmedia, Inc. All Rights Reserved.
Special
PR