x86 CPUはPC&サーバーからモバイルへ。ARMなど組み込みCPUは、モバイル&組み込みからコンピューティングへ。その狭間のタブレットが主戦場に。そして、PC OSを握るMicrosoftは、次期WindowsをARMにも載せる。様相はx86対ARMのCPU戦争へと進み始めた。

　これは、かつてのx86対RISC(Reduced Instruction Set Computer)群のCPU戦争を思い起こさせる展開だ。10数年前にも、Alpha、PowerPC、MIPS、PA-RISCといったハイパフォーマンスRISC CPU群が勃興。Microsoftも、Windows NTで、x86だけでなく、Alpha、MIPS、さらにPowerPCをサポートした(IA-64もサポート)。x86の覇権を脅かす構図という意味では、当時の再現のように見える。

　しかし、今回はちょっと話が違うかもしれない。それは、今回は「どちらの命令セットアーキテクチャ(ISA)がいいか」の戦いではなく、最終的に「命令セットアーキテクチャは重要なのか」という問いかけへと進む可能性があるからだ。

　つまり、ISAとしてのARMがx86に取って代わろうとするという展開ではなく、ISAの重要性が低下し、それに応じて、命令セットに依存するバイナリコード資産の重要性も下がるという流れになる可能性がある。よりコンピュータ技術的に言えば、ハードウェアの仮想化が進む方向へと進む。もちろん、完全にマシンの仮想化へと進むわけではなく、あくまでも重要性が下がるというレベルだが。

　もっとも、こんな話は、ソフトウェア業界では、もう聞き飽きたストーリだろう。Javaが登場した時も、Microsoftが.NETで対抗した時も、同じ話が出た。しかし、パーソナルコンピューティングの市場だけは、依然としてx86バイナリコードに縛られたままで、そこからさほど進まなかった。そして、x86 CPUメーカーは、x86バイナリ資産の上での繁栄を享受してきた。だが、スマートフォンとタブレットによって、x86 PCの未来が揺らいできた今、風向きが変わってきた。

　MicrosoftはARMアーキテクチャベースのSoC(System on a Chip)を、次期Windows(Windows 8世代?)でサポートすることを表明した。これで、MicrosoftがARMをライセンスした理由が解き明かされた。Microsoftによると、NVIDIAやQualcomm、Texas Instruments(TI)などが提供するARM SoCをサポートするという。ARM版Windowsでは、PC向けWindowsと同じユーザーインターフェイスを実現し、“ARMネイティブ”のMicrosoft Officeも提供する。

　ただし、現状の計画では、ARM版Windows上ではネイティブx86バイナリのWindowsソフトウェアはサポートしない。つまり、x86からの動的なバイナリトランスレーションは行なわない。Microsoftが作ろうとしているのは、x86上のWindowsアプリケーション資産を受け継ぐARM版Windowsではなく、Windowsの見た目(Look & Feel)とソフトウェア開発上の類似性を備えたOSだ。

　では、Microsoftはこれからどのように進むのか。単純にARMバイナリとx86バイナリが別ファイルになるのか、それともx86とARMのファットバイナリ(FAT Binary)化に挑戦するのか(多くの課題がある)、最終的にx86→ARMのバイナリトランスレーションも対応する可能性はあるのか。

　異なるバイナリのコードを変換することは、パフォーマンストレードオフもあり、やっかいだ。それも、RISC→x86ではなく、その逆のx86→RISCになると、ハードルが高い。命令フォーマットと命令長が単純なRISCからのトランスレーションより、複雑なx86からの変換の方が処理が複雑になるからだ。しかも、通常は、シングルスレッドのスカラ処理の性能が必要になるので、現状のARM系コアには荷が重い。

　しかし、ARMは急速に変化している。ARMは、現在、シングルスレッドのスカラ性能を高める方向へと向かうと説明しており、次のCortex-A15では3-wayスーパースカラのOut-of-Order実行エンジンになる。NVIDIAが開発するARMコアもそうした高いスカラパフォーマンス路線に沿っている。しかも、ARM系SoCはマルチコアへと向かっているため、バイナリ変換の重さも、将来的にはある程度軽減できる。また、ARMはARMv7-Aで、仮想化支援も追加する。

　こうしたARMハードウェアの流れを考えれば、バイナリトランスレーションも可能になって行く。しかし、問題は、その意味があるのかどうか。ハードウェアフォームファクタも変わり目(デスクトップ/ノートからスマートフォン/タブレット)の時に、x86バイナリ資産の継承に性能上の犠牲を払うことに意味があるのか。

ARMコアの概要	ARMv7-Aの仮想化と40bitアドレッシング

ARM Cortex A-15のパイプライン

　それよりは、むしろ、Microsoftが、今後、アプリケーションの.NETのマネージドコードへの移行を推進する可能性が高いだろう。そもそも、.NETによるハードウェア依存の解消は、10年前にMicrosoftが目指したゴールだった。

　遡ると、MicrosoftはWindowsでx86以外のISAサポートに、それなりに積極的だった。DECから引き抜いたチームが開発したWindows NTでは、それまでのWindows系OSから一新、マイクロカーネル化とHardware Abstract Layer(HAL)でハードウェアを抽象化する方式を取った。HALがハードウェアの差異を隠蔽するため、ポータビリティの高いOS構造になり、RISC系CPU群をサポートできた。この時点では、Microsoft自身が、RISCに未来があると信じていたためもある。

　その一方で、こちらもWindows系OSとは異なる、組み込みOSとしてWindows CEが誕生した。MicrosoftはWindows CEをリアルタイムOSとカテゴライズし、こちらもARMを初めとする複数のISAに対応した。Windows CEでの戦略は、PC向けWindowsとのAPI類似性を持たせることで開発を容易にするというものだった。

　とはいえ、こうした非x86 ISAへのMicrosoftの対応も、PCでのx86の覇権を脅かすまでには至らなかった。どころか、サーバーにもx86が浸透するようになった。Microsoft自身も、x86バイナリ資産の上で、安寧をむさぼっていた。

.NET Frameworkの環境

　プログラミングモデル上での大きな転換点となったのは、Javaの登場だった。バーチャルマシン上で中間コードを走らせるモデルは、ISAへの呪縛を解き放つ。そのため、Microsoftも対抗して「NGWS(Next Generation Windows Service)」と呼ばれていたWindows.NET戦略を打ち出した。当初のWindows.NETは、事実上Windowsを再構築するプランで、ハードウェアの抽象化をぐっと推し進めるものだった。

　知られているように、.NETではランタイム「CLR(Common Language Runtime)」が、中間言語をネイティブにJITコンパイルする。Microsoftは、CLRの上にC#のクラスライブラリを載せた.NET Frameworkを提供している。本来の予定では、Windows Vista世代では、新アプリケーションはWin32 APIを叩かず、.NET Frameworkの上に載るようになるはずだった。

　その時点の構想では、新しいアプリが全て.NETへと移行することで、Windows PCだけでなく、携帯電話を含めた多様なデバイスで同じアプリが走るようになるとされていた。.NET Frameworkは、OSもCPUもラップしてしまうので、OSとCPUは何でもよくなる。Windows CEである必要すらない。また、足りないコンポーネントは、ネットワーク上から動的にダウンロードすることで、ローカルのコンポーネントを削って携帯機器に載せることも容易になる。

　この流れでは、最終的に、ランタイムの下にあるのがWindowsではなく、ランタイムの上に構築されるのがWindowsになる。レガシーAPIを叩くアプリケーションは、徐々に消えて行く。ソフトウェア層を厚くすることで、ハードウェアを完全抽象化するというのがゴールだった。

　ところが、Windows Vistaでは、途中で、構想が大きく後退。結局、今まで通りWin32 APIベースのアプリケーションが主流のままになってしまった。.NETによる抽象化は、中途半端な状態のままに残された。レガシーの圧力が強かったのと、Javaの脅威がクライアントPCでは遠のいたことが大きな原因だ。

バイナリから仮想マシンへの構想

　しかし、流れは急変し、今やスマートフォンとタブレットの波が、怒濤のようにコンピューティングデバイスの世界に押し寄せている。ここで存在感を持つのはx86/64 ISAとWindowsとx86/64バイナリ資産ではなく、ARM ISAでありiOSとAndroidであり、そしてプログラミングモデルも部分的に変革されつつある。

　例えば、Androidでは、「Dalvik VM(Virtual Machine)」(Javaから変換した.dexバイナリを実行する)によるハードウェア仮想化でポータビリティを確保。それと平行して、ネイティブのパフォーマンスが欲しいソフトに対してはNDK(Native Development Kit)も提供するという路線を取った。完全に仮想化だけに限定しないところが現実解かも知れない。Androidでは、ハードウェアを仮想化したモデルの方が主で、ネイティブのプログラミングモデルはサブになっている。

　加えて、GPUの並列コンピューティングの波があり、こちらもランタイムが中間コードをGPUネイティブに変換するモデルを取っている。また、大枠を見ると、Low Level Virtual Machine (LLVM)のようなプラットフォームも登場している。つまり、流れを見ると、プログラミングモデルは、一歩一歩と抽象化を高める方向へと進んでいる。

　この状況での“Windows”のARM対応。ここでMicrosoftが、ARM版Windowsで、ARMバイナリネイティブよりも、.NETベースへの移行を推すのなら、Microsoftの世界でもハードウェアの抽象化の度合いが高くなって行く。そうした流れになると、ソフトウェア側だけでなく、ハードウェア側にも大きな影響を及ぼすだろう。