Windows Info 第293回

Windows 11ではARM版も改良が進んだ

　Windows 11にはARM版もある。Windows 10のとき最初は騒がれたが、そのあとARMの人以外で実際に使っている様子を実は見たことがない。とはいえ仕事なので、Surface Pro Xを購入した。このマシンにもWindows Insider ProgramのBeta Channelでプレビュー版がやってきた。ARM版のWindows 11は強化されており、Windows 10のときにはプレビュー版でしか提供されていなかったx64コードのバイナリ変換機能が搭載されている。今回は、このあたりを含めて、ARM版Windows 11の状況について解説しておこう。

Windows 11はARMプロセッサもサポートしている

ARMプロセッサについてあらためて整理

　話が少しややこしいので、最初にちょっと用語を整理させていただく。まずはARMプロセッサについてである。インテルやAMDのCPUは、「世代」と「マイクロアーキテクチャ」名で区別されるが、ARMプロセッサでは、アーキテクチャにバージョン番号がついている。とはいえ、番号が整理されたのは、ARMv7から。PC関連ではこれ以降のアーキテクチャだけ考えればいい。なお、かつてインテルがDECから“譲り受け”て、うまく行かずに売り払ったXscaleはARMv5世代である。Androidも最初はこの世代をサポートしていたが、現在では、ARMv7以降のみが対象となっている。

　簡単に言えば、ARMv7が32bitアーキテクチャで、ARMv8が64bitアーキテクチャである。現在では、ARMv9というアーキテクチャもあるが、これはARMv8-Aを強化したものと考えればよく、少なくともWindows 10、Windows 11のレベルでは両者の違いは問題にならない。

　なお、ARMv8にはARMv7の命令セットや実行環境が含まれていて、これをAArch32と呼んでいる。

　この32bit命令セットをA32命令セットと言う。なお、ARMv7の時代には、AArch32やA32命令セットという呼び方はなく、ARMアーキテクチャなどと呼ばれていた。ARMv8で64bit環境が出てきたとき、ARMv7とは異なるA64命令セットを導入し、レジスタなどを追加してAArch64として定義した。この際にARMv7までの32bit実行環境をAArch32と呼ぶことにした。このため、ARMv7のオリジナルの定義は、AArch32とは呼ばれていなかったのだが、話が面倒になるので、ARMv7に対してもAArch32やA32といった呼び方を使う。

　ARMv8は、AArch32/A32とAArch64/A64の両方に対応している。これは、AMDやインテルのCPUが32bitモードと64bitモードの両方を持っているのと同じである。ここで明確にしたいのは、A32とA64という異なる命令セットを持っている点である。一般に1つのCPUが異なる命令セットを持っている場合、プログラムはどちらかの命令セットを使って作ることになる。プログラムの途中でモードを切り替えることは、ハードウェアとして不可能ではないが、モードの切り替えは特権命令であったり、実行環境の設定などが必要なことが多く、1つのプログラムの中で勝手にモードを切り替えるようなことはOSが許さないのが普通である。なので、一般にアプリケーションはどれか1つの命令セットだけで作られる。

　OSはAPIを呼び出す手順などの基本的なルールを決めている。これをABI（Application Binary Interface）という。ハードウェア上、プログラムはさまざまな構造を持つことができるが、アプリケーションプログラムは、OSの提供するAPIを使わないと、ファイルも読めなければ、画面に何かを表示することもできない。

　ABIには、API呼び出し時のルール（Calling Conventionと呼ばれる）やデータやプログラムをメモリに置くときの境界合わせ（アライメントという）やAPI呼び出し時のスタックの使い方などが定められている。たとえば、高速化のためにレジスタを使って引数を渡すときにどのレジスタに置くか、スタックには何を入れておくかといったルールが定めれている。そのほか、一部の汎用レジスタに固有の役割を持たせる、保存しておく必要があるレジスタなど、さまざまなルールがある。

　ただし、このABIに関しては、CやC++などの高級言語でアプリケーションを記述する場合には、コンパイラが処理してくれるため、開発者があまり心配する必要はない。しかし、アセンブラでプログラムを記述する場合、開発者はABIに準拠してプログラムを書かねばならない。

　ARM版Windows 10用にMicrosoftが定義したABIは、ARM64 ABIと呼ばれている。これはWindows固有のABIである。ARMプロセッサでは、Linuxなども動作するし、AndroidやChromebookなどもARMプロセッサを使う。しかし、ABIはMicrosoftのARM64 ABIとは異なっている。ただし、ARM64 ABIはARM社が定義したABIをベースに作られた。

　これに対して、従来のAMDやインテルCPU用に定義したABIもある。これらは、x86 ABIやx64 ABIと呼ばれている。ARM64 ABIは、同じ64bit用のx64 ABIとCalling Conventionやアライメントのアルゴリズム、スタック利用方法で異なる部分がある。多くの場合ABIは、それぞれのCPUに最適化して作るため、アーキテクチャが異なれば違うものになるのが普通である。

Windowsとコードタイプ

　一般にアプリケーションプログラムは、このABIに準拠して、特定のCPUのアーキテクチャの命令セットを使って作られる。ここではこれを「コードタイプ」と呼ぶことにする。Windowsのコードタイプには、以下の表のようなものがある。

　64bit版Windowsは、x86コードとx64コードの実行が可能だ。これに対してARM版Windows 10は、従来のx86コードを「バイナリ変換」により、A64命令セットに変換して実行することが可能だが、もちろんARM64コードの実行もできる。

　Microsoftのドキュメントによれば、ARM版Windows 10は、ARM64で作られているという。しかし、x86／x64コードは、ARM64とは違うABIを持つ。ということは、アライメントやCalling Convention、スタックの使い方が違っていることになる。x86／x64コードをバイナリ変換でA64命令セットのプログラムに変換できたとしても、ABIまでは変換できない。どういうアルゴリズムやコードでABI対応させているかが不明だからだ。これを変換するのには、プログラムの「意味」を知る必要がある。

　しかし、変換されたx86／x64コードは、APIを呼び出した瞬間には、スタックやアライメントなどがx86／x64 ABIに準拠した状態になっているはずなので、これを機械的にARM64に変換することは可能だ。ソフトウェアでは、こうした変換をする小さなプログラムを「スタブ」と呼ぶことがある。おそらく、ARM版WindowsではAPIに入る前にスタブが置かれ、ここでARM64 ABIに準拠させたうえでAPI呼び出しをしていたと考えられる。なお、WindowsのAPIは、DLLの中にあるため、API呼び出しはDLLの呼び出しと同じである。

　ARM版Windows 10では、フックやエクスプローラー拡張で、アプリケーションが組み込むx86コードのコンポーネント（DLL）をロードできない。これらは、API呼び出しではないためにスタブを挿入することができず、Windows側のモジュールはARM64 ABIに準拠し、バイナリ変換されたx86コードは、x86 ABIに準拠しているため、正しく動かないためだ。ARM版Windows 10で、ATOKや一部のエクスプローラー拡張などがうまく動かなかったのは、これが原因だ。

　さらに、ARM版Windows 10ではx86に限定したとはいえ、サードパーティの対応があまり進んでいない。その理由の1つは、ARM64版を作りにくいタイプのアプリケーションがあるからだ。それは、コードの一部にx86／x64のアセンブラを使って記述されたアプリケーションだ。これは完全にx86／x64の命令なので、A64命令で書き直す必要がある。しかし、CPUのアーキテクチャが違うために簡単な作業ではない。