Windows Info 第106回

スマホサイズのPCが登場する!? Windows On ARMを知る

　Windows On ARMは、Windows 10のARMプロセッサ版である。これはマイクロソフト最初の64bit ARM対応となる。これまでのWindows MobileでもARMプロセッサに対応していたが、32bitコードを利用していた。

2017年6月のCOMPUTEXで行なわれたQualcommによるWindows On ARMのデモ

PC向けのOSを動かすにも十分な性能を持つ
ARMの64bitアーキテクチャ

　詳しい話の前にARMの64bit版について簡単に確認しておく。ARMの64bitアーキテクチャは、ARMv8と呼ばれている。

ARMプロセッサのアーキテクチャには32bitのARMv7と64bitのARMv8があり、ARMv8はARMv7の32bitアーキテクチャを含み、実行時にモードを切り替えて動作できる

　これに対して32bitアーキテクチャはARMv7である。ただしARMv8は、32bitアーキテクチャを含んでいる。このため、ARMv8の64bitアーキテクチャ部分はAArch64、同32bitアーキテクチャは、AArch32と呼ばれる。AArchは「ARM Architecture」の略で、ARMv8は64bitアーキテクチャモードと32bitアーキテクチャモードを持ち、64bitアーキテクチャモードでは、32bitアーキテクチャの機械語命令を実行する32bitモードが利用できる。このあたりはインテルの64bitプロセッサと同じだ。

　AArch64とAArch32は、命令セットが完全に異なり、相互に互換性がない。AArch32はどちらかというと組み込み系などを意識した命令セットだったが、AArch64は、汎用的なRISC命令セットになっている。

　逆に言えば、AArch64は汎用的なコンピューターとしての性能が出せるように作られた命令セットであり、過去のアーキテクチャに縛られない。ある意味、最も最後に登場した64bitアーキテクチャであるため、過去に作られたさまざまなプロセッサで得られた知見などを盛り込むことが可能だった。

　たとえば、命令セットによってはアウトオブオーダー実行やスーパースケーラー実行がやりにくい、命令デコードが複雑で、数バイト以上を読み込まないと命令の長さが決定できないといった問題があったが、AArch64はこうした問題があるといった認識の上で設計された命令セットになっている。

　AArch64とAArch32に関しては、マイクロソフトは、ARM64、ARMという表記を用いている（Visual Studio2017など）。しかし「ARM」は、汎用的に使われているため、本記事では、64bit／32bitアーキテクチャを指す場合には、AArch64／AArch32という表記を使うことにする。

　以後の説明では、マイクロソフトの呼び方にならい、インテルの32bitアーキテクチャをx86、64bitアーキテクチャをx64と表記する。

インテルプロセッサには32bit、64bitの実行モードがあり、これを切り替えて実行することができる。このときアドレスの長さが違って来るためWin32、Win64の2つのAPIが対応する

　また、32bitのx86ネイティブコードから呼び出すWindowsのAPIをWin32API、64bitのx64から呼び出すAPIをWin64APIと呼ぶ。この両者は機能的には同等だが、パラメーターとして渡されるアドレスが32bitなのか64bitなのかという違いがある。また、これにともない、メモリ内の位置を示すポインターを含む構造体も意味的には同じだが、アドレス長の違いからメモリ内での配置が変わってしまう。

再び異なるアーキテクチャのCPUに移植されたWindows 10

　Windows On ARMは、Windows 10をAArch64に移植したものとなる。Windows 10の祖先であるWindows NTは、当初から複数プロセッサへの移植を想定してC言語で開発された。

　このため過去には、DEC（当時）のAlphaやインテルのItanium、IBMのPowerアーキテクチャ、MIPSアーキテクチャなどに移植された。そもそも初期の開発段階では、IntelのRISCプロセッサであるi860が対象だった。このため、Windows 10のAArch64への移植自体は、それほど困難なものではなかったと考えられる。

　ただ、マイクロソフトは、ARMプロセッサに関しては、ずっと32bitアーキテクチャを対象としており、Windows 10 Mobileも32bit版しかなかった。また、Windows 8のときに開発されたWindows RTも32bit版だった。

　Windows On ARMのカーネルやシステム自体は、AArch64のネイティブコードとなっている。スマートフォンで使われるようなプロセッサでWindowsを実行して十分な性能が出るのかというと、AArch64の場合には「yes」である。

　AArch64は前述のように汎用的なRISCアーキテクチャであり、アウトオブオーダー実行などでクロックあたりの実行命令数を増やすことが可能。あとはキャッシュメモリなどを使い、さまざまな高速化もできるため、Windowsの実行に対して十分な性能を持つ。また、CPUコアの実装面積が小さく、コア数を増やしやすいというメリットもある。

　ただし、Windows On ARMでは、プロセッサをQualcomm社のSnapdragonに限定している。これはWindows Phoneのときと同じく、SoCを固定とすることで、開発や検証の手数を削減するためだと考えられる。

x86用の32bitアプリが動作するWindows On ARM

　Windows On ARM最大の特徴は、現在多数流通しているx86の32bitネイティブコードのデスクトップアプリケーションを実行可能なことだ。Windows On ARMはWoW（Windows On Windows）の仕組みを使い、実行時にx86ネイティブコードをAArch64コードに変換して実行する。

Windows On ARMは、WoWの仕組みを使って32bitのx86ネイティブコードを変換しながら実行するという（マイクロソフト社ビデオより引用）

　これはWindows RTやWindows 10 Mobileがなぜ普及しなかったか？　と考えた結果であろう。ただし、Windows On ARMが実行できるのはx86の32bitコードのみで、x64つまり64bitのネイティブコードは実行することができない。

　Windows On ARMでは、UWPアプリケーションはそのまま動作する。これは実行ファイルが仮想マシンコード（CLI、Common Language Infrastructure）で作られているからである。ただし、UWPアプリでも、高速化のためネイティブコードを含むことができ、その場合には、ARMプロセッサ用のコードを用意する必要がある。

　CLIは、CLR（Common Language Runtime）によって実行されるが、このとき、ネイティブコードへ変換される。変換は実行時なので、実行先のプラットフォームのプロセッサアーキテクチャにあわせたネイティブコードが生成される。

　またWindows On ARMでは、AArch64のネイティブコードからなるデスクトップアプリケーションが動作する。というのは、現在のWindows 10には、エクスプローラーやメモ帳などWin64に対応した64bitネイティブコードアプリケーションが含まれているからだ。また、その開発も原理的には、Visual Studioでできるはずだ。そもそもVisual StudioでAArch64のデスクトップで動作するプログラムを開発できないとWindows On ARM自体が開発できない。

　もっとも、マイクロソフトがそのことを可能にするかどうかについては別問題だ。過去に提供されたARMプロセッサ用のWindows RTは、マイクロソフトがWindowsに標準で搭載しているAArch32ネイティブコードのデスクトップアプリケーション（Windowsの標準アプリケーションや標準付属のOfficeなど）以外の実行ができない形で出荷されていたからだ。

　Windows RTが登場したときには、マイクロソフトは、従来のデスクトップ環境で動作するアプリケーションと別にWindowsストアで配布するモダン環境（当時はメトロと呼ばれた）アプリケーションの2つがあり、後者を標準的にしようとしていた。また、配布形式が一定でないデスクトップアプリケーションにARM、x86／x64の2つのバイナリ形式ができることを嫌っていたからだと言われている。複数のCPUアーキテクチャのネイティブコードを1つのファイルに格納する、いわゆる「FAT Binary」といった形式もWindowsには存在していなかった。

　Windows以外のプラットフォームでは、複数のプロセッサアーキテクチャに対応した実行ファイルを格納できるFAT Binaryを提供したものものあるが、基本的にはプロセッサアーキテクチャを移行時に存在するもので、最終的には片方に収束させることを目的としたものが多かった。

　また、複数のプロセッサアーキテクチャに対応しているLinuxなどでも、複数のネイティブコードを1つの実行ファイルに入れるといったことは行なわれていない。Linuxの場合、ソフトウェアはどのような形でもインストール可能だが、標準的な手順として「パッケージマネージャ」が使われているため、各ディストリビューションなどが提供するリポジトリから適切なプロセッサアーキテクチャのバイナリ実行ファイルを含むインストールパッケージをもってきてインストールができるため、複数のネイティブコードを1つのファイルにする必要がない。

　これに対して、Windowsのデスクトップアプリケーションは、これまでずっとx86／x64用として配布されてきたため、ここに新たなネイティブコード形式が入ることは、自分のマシンのプロセッサさえ区別できないユーザーが多数いることを考えると大きな混乱が生じ、Windows自体の評判さえ悪くなると、マイクロソフトが考えても不思議ではないだろう。

　ただ、マイクロソフトもUWPしか実行できない「Windows 10S」といったエディションを提供しているように、簡易な利用しかしないユーザーにはUWPのみを使ってもらうという方向性を考えている。こうしたエディションであれば、プロセッサアーキテクチャの違いは問題にはならないだろう。なお、誤解されないように念を押しておくが、Windows On ARMとWindows 10Sはまったく違うものであり、Windows10Sはx86／x64プロセッサの上で動作している。

　Windows RTがハードウェアにプレインストールされた形式のみで販売され、そのアップデートはすべてWindows Update経由だったことを考えると、Windows On ARMもすべてハードウェアにプレインストールされて販売されることになると思われる。このためパッケージなどで入手することはできないだろう。

　さて次回は、Windows On ARMでx86コードを動作させる仕組みを詳しく見ていくことにしよう。