Intelが発表したX86-Sについて(3/3) – 分析編

コメントを残す

はじめに

Intelが公開したX86-Sの提案に関する連載における最終回です。掲載が予定・予想よりだいぶ遅れてしまいました。今回は仕様を要約しての簡単な紹介と疑問点、後方互換性の観点からどういうことが起こるのか、仮想化にあたえる影響、AMDの今後の対応としてあり得るシナリオは何かなどを分析したいと思います。

目次

超要約

詳しい内容は第2回の「詳細版」で十分に書いていること、通常の要約については第1回の「概要編」にあることから、今回の第3回目の「詳細編」ではなるべく短い文章でどのようなものかを書いてみたいと思います。

「X86-S」とは何か

今回Intelが提案する「X86-S」は「Intel 64」から「64ビットOSの実行を前提とし、現行の64ビットおよび32ビットのアプリケーションを再コンパイルなしで動作させるために必要な部分を残して、すべてを廃止する」というものです。その際に廃止した部分を「取り外す」形とし、極力それ以外の部分には手をくわえずに構造を含めてそのまま残すことが特徴です。ゼロから環境を再構築したものではありません。これまでのFREDの構想からさらに一歩を踏み出したものであると考えることもできそうです。

OSについてはこれまでのものは動かず、X86-S対応版「レガシーを減少させたOS（legacy-reduced-OS）」を用意する必要があります※1。これはその前段階を担うUEFIについても同様です。

「レガシーを減少させた」が意味すること

実は「詳細編」で訳した「X86-S ISA External Architectural Specification（以下、X86-S EAS）」の中では、何に対して「レガシーを減少させた」のかについて表記が揺れています。将来のCPUID機能ビットにおける名称としてLEGACY_REDUCED_OS_ISAとLEGACY_REDUCED_ISAの2つの記述が存在しているのです。

前者はOSに対して「レガシーを減少させた」として、そのためのISAとしていると読めるのですが、後者は既存のISAから「レガシーを減少させた」ようにも読めます。複数の原ドキュメントの著者の間で、もしかすると認識に差があるのではないかと感じますが、単純な表記ゆれであることも否定できないところではあります。

X86-S EASの2.IntroductionにLEGACY_REDUCED_OS_ISAと表記している。

X86-S EASの2.IntroductionではLEGACY_REDUCED_OS_ISAと表記している。

X86-S EASの64-Bit SIPI / 5L Page Switch Without LEGACY_REDUCED_ISAにおけるLEGACY_REDUCED_ISA表記。

X86-S EASの64-Bit SIPI / 5L Page Switch Without LEGACY_REDUCED_ISAではLEGACY_REDUCED_ISAと表記している。

表で見るIntel 64とX86-S

32ビットから64ビットへ拡張する際にAdvanced Micro Devices（以下、AMD）が提示したモード区分の表を一部修正したもの※2を以下に示します：

動作モード 必要なOS アプリケーションの再コンパイル デフォルト・サイズ レジスター拡張 典型的な汎用レジスター・サイズ
アドレス オペランド
ロング・モード 64ビット・モード 64ビットOS 必要 64 32 あり 64
コンパチビリティー・モード 不要 32 なし 32
16 16 16
レガシー・モード プロテクト・モード 32ビットOS 不要 32 32 なし 32
16ビットOS 16 16 16
仮想8086モード 32ビットOS 16 16 16
リアル・モード 16ビットOS

アプリケーションの再コンパイルについては64ビット・モードの導入時点の話であり、当然現在は十分に64ビット・アプリケーションが蓄積されてきていますので次の表では「不要」に変更します。そしてこの表からX86-Sでも残る部分を以外を消すと以下のようになります：

動作モード 必要なOS アプリケーションの再コンパイル デフォルト・サイズ レジスター拡張 典型的な汎用レジスター・サイズ
アドレス オペランド
ロング・モード 64ビット・モード 64ビットOS（X86-S対応） 不要 64 32 あり 64
コンパチビリティー・モード 不要 32 なし 32

このように多くのレガシーを削減しています。

追加される技術要素

X86-Sの提案の中では技術要素の削除だけではなく、追加をしているものが2つあります。これはX86-Sでは必須ですが、それぞれの技術は独立したもので、将来のIntel 64に追加して実装することも可能な仕様となっています。

64ビットSIPI

現在はプロセッサーの起動時の処理の一環としてSIPIという枠組みが使用されています。これは64ビット・モードにおける処理ではないため、64ビット・モード専用のX86-Sでは実行できません。このため、64ビット・モードで起動するX86-Sが処理できるように64ビットのSIPIを新たに提案しています。将来のIntel 64に対して64ビットSIPIが追加され、この機能が必要とされるのであれば使用することができます。

5レベル・ページ・テーブル・スイッチ

Intel 64には5レベル・ページング仕様が設けられています。この切り替えにはページングを一度無効にする操作が必要になります。しかし、X86-Sではページングを無効にすることは禁止事項の一つです。そこで新たにX86-SでもMSRを通して5レベル・ページ・テーブル・スイッチを行えるような仕様を提案しています。この内容は、将来のIntel 64に対してX86-Sとは切り離して追加することも可能なものとなっています。

一般ユーザーたちへの影響

この提案が我々一般ユーザーに与える影響について考えてみたいと思います。

X86-Sに対応するOSが必要

これは先ほども触れましたが、X86-Sに対応するUEFIとOSが必要になります。しかし、一般に手に入るようになっているころには、X86-Sであるかどうかはあまり注目されない事項となっている可能性が高そうです※3。

通常のアプリケーションへの影響

現在の64ビットOSで実行することができる、一般的なアプリケーションに対する影響は基本的にはありません。そのまま使用し続けることができます。ただし、これはLinuxやWindowsに関しての話であり、一般的ではないOSにおいては異なる反応を示すことがあるかもしれません※4。

仮想化機能への影響

X86-Sを採用したシステムにおいては、通常の仕様通りに仮想化機能を使用する場合にはX86-S対応OS以外を実行することはできません。Intel 64対応OSをゲストとして動作させるにはそれ以上の仕組みを必要とします。

X86-Sの提案の中で、仮想化機能を活用してX86-Sで取り外した機能を再現する方法についていろいろと論じてはいるものの、非常に複雑で、処理コストのかかる、そして一部は完全なエミュレーションを用意する必要のあるもので、なおかつそれでも「完全な互換性」が得られるものとはなっていません。今後、完全な互換性が必要な場合には、100%プログラムによるエミュレーターを使用することになる可能性もありそうです。

Intel VT-xが用意されるより前は、「バイナリー・リライティングによる仮想化（Binary Rewriting Virtualization）」あるいは「バイナリー・トランスレーション（Binary Translation）」のような技術が用いられていました。これらについても完全な互換性が得られるものではありませんでしたが、十分に有用でした。これらと同じレベルを許容できるのであれば仮想化機能を最大限活用しつつ個別機能をエミュレートすることで、ある程度再現することはできるかもしれません。

X86-Sの導入に対するメリットとデメリット

メリットとデメリットを検討してみます。

メリット

  • プロセッサーの設計時の検証作業に対する負荷が大幅に下がるだろう。
  • 結果としてプロセッサーの不具合が減ることが期待できる。
  • 結果として製品開発サイクルが短縮される。
  • プロセッサーの設計変更をする際に考慮する事項が減るため、命令の追加、性能向上などに取り組みやすくなるだろう。
  • 多くのユーザーが使用しない機能のためにかかっていた費用が削減されることにより、販売価格にも影響することが期待できる（かもしれない）。
  • 機能の削減により目が行き届きやすくなることによってセキュリティーが向上する（かもしれない）。

一般ユーザーにとっては直接のメリットはあまりないのではないかと思われます。一方でIntelやAMDでプロセッサーの設計をしている方々にとっては大きな恩恵があるものと思います。それによって製品の品質向上や開発サイクルの短縮が可能となるかもしれません。これは間接的にユーザーの利益につながります。そして、典型的なユーザー（普通にパソコンを使っている一般人）にとっては影響のない部分の削減であることから、そういった一般ユーザーは今回の提案について特別に反対・反応する理由はないものと思います。

デメリット

  • 64ビット環境では動作しない従来のソフトウェアを実行することができない。
  • 一般ユーザーは効果を実感できない。

やはり後方互換性を失わせる仕様の提案ですから、それがそのままデメリットといえるでしょう。X86-Sの提案の中で「使われていない」と表現していますが、実際には主に業務用途でかつての環境で動くソフトウェアを仮想化して32ビットOSごと仮想マシンとして維持している例は少なくないように思います※5。それだけに、今回の提案では削除した機能を再現する方法についても入念に検討をしています。ただ、その提案に含まれるエミュレーションの方法はやや強引な部分もあり、また従来のハードウェアで直接仮想化して実行する場合と比較してかなりの速度的なペナルティーが発生するような内容も含まれています。それだけに、仮想化関連ソフトウェアの開発者および使用者は、この提案を吟味し、必要に応じて質問や提案をフィードバックをした方がいいかもしれません。

X86-S EASに対する雑感

疑問点

SMSWの取り扱い

かつて80286においてモードを切り替える際に使用していたLMSW命令については言及がある（削除され#UDになる）のですが、それを読み取るSMSW命令については言及がありません。これも#UDになるという予想をしますが、それであっているのかがちょっと気になります。明示されていないのでX86-S EASが差分のみの構成であることから残る可能性もなくもないでしょう。なぜならこの命令はリング3でも実行できることから、アプリケーションがこの命令を含んでいると#UDで落ちることになるからです。もっともSMSW命令を使用する意味など、ほとんどのアプリケーション・プログラムではありえないとは思いますので、非常にまれな事象となるでしょう。

LMSWのレガシーにおける実行可能リング

「表15. 命令の変更」において、LMSW命令が、レガシーにおけるリングとして「リング3、1、2、0」と記述されているのは誤りで「リング0」でのみ実行可能な命令です。一方でSMSW命令は「リング3、1、2、0」で実行可能です。このことから、実はこの表はSMSW命令と取り違えて記載をしたのか、などとも考えはしたのですが、単純に記載ミスをしたという可能性が高いと最終的には考えるようになりました。

余談ですが「リング3、1、2、0」という書き方が面白いと思いませんか？

普通に書くと「リング3、2、1、0」と書きそうです。しかし「リング3、1、2、0」としています。これはおそらく「リング3」および「リング0」の2つに削減したX86-Sの検討資料を元に、新たにレガシー部分との比較資料を書き起こした際に、間に「、1、2」と書き足したのだろうなと私は想像しています。

問題点

この提案は従来の仕様とX86-Sとの差分だけが抽出された構成となっているため、若干のサポートはあるものの読みにくさはかなりのものがあります。ただし、一方で短くまとまっているので事前知識が十分にあれば全体を把握しやすいという側面もあるかと思います。初見殺しといっても過言ではないでしょう。とはいえ、初見の人がどのくらい読むのか、ということもありますが。

謎な点

システム・マネージメント・モード（SMM : System Management Mode）の処遇について（RSM命令についての記述と疑似コードの中に若干の言及はあるものの）明確な記載がありません。「ビッグ・リアル・モード」の中にSMMは含まれるのでしょうか？つまり、今後は削除が予定されているということになるのでしょうか？それとも残るのでしょうか？書き方的には残りそうな雰囲気がありますが、はたしてどちらなのでしょうか？X86-S EASが差分について説明する資料であることを考えると残る可能性の方が高いと読むべきなのでしょうか…？

AMDへ対する側面

言葉の選択

前述において、あえてIntelによる発表ではなくAMDによるAMD64の仕様に基づく表を引用しました。本来のIntelの資料では「IA-32eモード（IA-32e Mode）」と表記されるものが、AMDの資料では「ロング・モード（Long Mode）」と表記されています。そして、今日（こんにち）の資料では、Intelも「ロング・モード（Long Mode）」と表記しています。この表記への変更は、全面的ではないにしても少なくとも10年以上前に始まっています。現在においては重要なIntel製品の発表資料の中でも見かけることができます。

今回のX86-S EASにおいても「ロング・モード（Long Mode）」と表記しています。また、64ビット・モードへの切り替えを行うMSRについてもIA32_EFERではなくEFERと表記しています。これ以外にページ単位で実行不可を指定することができる機能を、従来はXDビットと表現していましたが、現在はNXビットと表現しています。これらはAMDによる表現と同じです。

このように、現在はIntel 64とAMD64の間での表現上の差異もだいぶ「レガシーを減少させた」状態となっています。当時のMicrosoftからの圧力と米国司法省などの外部環境/状況から結果的に飲むしかなかったAMD64との互換性を確保したIntel 64を採用するという事態の影響は、とっくに過去になったということなのかもしれません。

今回の「X86-S」という暫定名称も、中立性を感じる響きを持っているように思います。

AMD64に対するX86-Sの適合性

一般ユーザーはあまり意識することはないとは思います。しかし今回はだいぶ細かい話なので言及しますが、Intel 64とAMD64は部分互換性のある別のアーキテクチャーです。このことは一般のユーザーには理解しがたいかもしれませんが、事実です。ここではX86-Sに垣間見える要素として、Intel FREDおよびIntel VT-xのAMD側の側面について書いてみたいと思います。

Intel FREDとAMD Supervisor Entry Extensions

X86-S EASではIntel 64の視点から差分を組み立てている関係で、例えば【PDF】Intel FREDにおける動作も規定しています。一方で同じ方向性を向いたAMDの技術は【PDF】AMD Supervisor Entry Extensionsです（このドキュメントにおいて仕様に対するコメントをAMDは求めています）。

これらの技術については、それぞれ互換性がありません。ですから、X86-SのFRED関連の部分をAMD64がそのまま取り込むことはないのではないかと考えるのが、現時点での妥当な判断と多くの人たちは考えるのではないでしょうか。もちろん、実際の結果を予言することはできません。

この両社の技術をLinuxカーネル開発リーダーのLinus Torvaldsさんの視点での論評した英語の記事「Linus Torvalds on how AMD and Intel are changing how processor interrupts are handled | ZDNET」が第三者視点として参考になります。

Intel VT-xとAMD-V

仮想化については命令セット・レベルで互換性がありません。このようなことから、それぞれ別のソフトウェアが必要になります。例えばMicrosoftの仮想化技術「Hyper-V」において、Intel VT-xの対抗であるAMD-VはWindows 11によって、ようやくNestedのサポートを得られるようになるなど、機能的にサポートが後手にまわる結果となっています※6。

X86-S EASでは仮想化によるレガシーとの互換性確保について、Intel VT-xベースの考察を重ねています。これと同じような考察をAMD-Vベースで行ってみる必要があるでしょう。これがどの程度の仮想化に関する互換性を持つのかどうかにより、ソフトウェア・レベルでのサポートの度合いが変わってくることになるかもしれません。

X86-SにおいてIntelが検討しているレガシーのサポート方法はだいぶアクロバティックです。X86-SをAMDが採用するとしても、同様にアクロバティックなものとなるでしょう。この際、両社とも仮想化機能におけるレガシーのサポートをあきらめるというのも1つの選択肢になり得るかもしれません。

X86-SをAMDを採用するだろうか？

X86-Sの仕様をAMDがもし取り込むのであれば、これらの類似する仕様に対する別の調整が必要となりますが、取り込みが不可能な設計仕様ではないと私は考えています。

Intelがことさらエコシステムに言及して提案書を出したのは、AMDに対する「この仕様をサポートしてほしい」というメッセージでしょう。そして、それとともにWindowsやLinuxなどの開発者に向けて支持（日本語としての「支持」と「サポート」の両方の意味を含む）を呼びかけているのではないかと思います。AMDがx86-64を発表したときと同じような状況の再来をIntelとAMDの役割を入れ替えて実行することを考えているのかもしれません。前回はIntel側が折れてx86-64を採用しましたが、今度はAMD側が折れてX86-Sを採用するのかどうかが注目点となるでしょう。そして、そこにFREDが含まれるかどうかも。

一般ユーザー、OS開発者、ファームウェアの開発者などはIntelとAMDがそれぞれの異なる仕様を製品化して戦うような状況は望まないでしょう。X86のエコシステムの維持のためには、それぞれのハードウェアにおいて各種ソフトウェアがある程度互換性が取れる一本化された仕様が必要です。それが実現できるのかどうか。今回もx86-64の時と同様に、Microsoftの立ち位置はとても重要なものになりそうです※7。

大手IT/PC系ニュース・サイトにおける報道内容について

私が時間をかけて3回の連載を書いている間に、IT/PC系のニュースを書いているライターの方々は即時にその内容を記事にして伝えています。その内容について確認してみたいと思います。今回は大手と（勝手に）判断しているニュース・サイトから2つの記事に注目をしてみました。

X86-S EASの内容は非常に専門的で理解が難しい内容となっています。それがどのように報道されたのか、私の目から見てその内容は正しいのかを見てみましょう。

インプレス PC Watch

まずは「Intel、新「X86-S」アーキテクチャで8086互換を切り捨て（著者・劉 尭さん）」です。こちらを確認してみると、読みやすくよくまとまっていると思いますが、やや気になる記述が確認できます。

2004年に投入した64bitモード(Long Mode)を導入した際にVM86モードが削除され

この書き方だと誤解を招きやすいのではないかと思います。あくまでも2004年のIntel 64導入時にはロング・モードでのみ、仮想8086モードのサポートが打ち切られたのであり、レガシー・モードであれば引き続き仮想8086モードは使用可能です。

VM86モードとして知られている32bit ring 0を削除

これは理解に誤りがあります。32ビット・プロテクト・モードのリング0からタスクとしてサブモードの仮想8086モードを呼び出すことができるというというのが正しい理解です。VM86モードが32ビット・リング0ということではありません。今回、X86-Sにおいて32ビット・リング0が廃止されて仮想8086モードへ入る手段がなくなった（＝削除された）こととロング・モードで以前から仮想8086モードが使用できないのは別の話です。

廃止されたCRアクセス命令の削除

LMSW命令のことですが、これはIntel 64でも依然として使用可能（廃止されていない）で、X86-Sにおいて削除されるものです。

アイティメディア PC USER

続いて「16bit／32bitサポートの“終息”でより高性能なCPUを――Intelが64bitオンリーの「X86-Sアーキテクチャ」の仕様を初公開　意見募集中（著者・井上翔さん）」です。こちらについても確認をしてみると気になる内容があります。

2004年に64bit命令に対応したCPU以降は「仮想86モード（VM386）」をサポートしておらず

これは上の記事と同じ誤解をされています。英語原文がややわかりにくい表現なのかもしれません。Intel 64に対応したCPUにおいても32ビットOSの中で仮想8086モードは引き続き使用可能です。また「VM386」は「VM86」の入力ミスかと思われます。

そしてx86プロセッサにおける16bit／32bit命令のサポートは“不要”な状態となった。

これは誤りです。正しくは「16ビット・モード、および32ビット・モードのリング0が不要になった」です。16ビット命令、32ビット命令はもちろん、8ビット命令にいたるまで、これまでの64ビット・モードにおいてはもちろん、X86-Sにおいても存在しています。つまりモードとその中で使用できる命令のビット数は別の概念です。ただし、64ビット命令が使用できるのは64ビット・モード（SupervisorまたはUser64モード）に限られます。

X86-Sアーキテクチャでは、このようなモード切り替えが不要となるため、CPUの構造や命令をシンプルにできる。その分だけ、CPUの純粋な性能アップに注力しやすくもなる。

これは著者の推測であり（一方で将来的にはある程度寄与する可能性があることには同意します）、今回のX86-S EASでは性能アップについては一切触れていません。記事のタイトルに「16bit／32bitサポートの“終息”でより高性能なCPUを」と書いてしまったのは誤解を招く（ミスリード）表現だと思います。

まとめ

この「分析編」は2度書き直しています。1度目は「詳細編」の要約に近いものでした。しかし、読者はそんなものを求めていないだろうと考えて要約は最低限とし、ほぼ全体を文字通り「分析」に充てることにしました。しかし、2度目の時点では技術的な枝葉末節にとらわれる結果となりました。そこで、さらに客観的な視点を追い求め、今回のX86-S EASという提案をAMDを含めて関係各所はどう受け止めるだろうかということについて、私見を書いてみることにしました。結果として、それなりに現時点での視点で論じることができたのではないかと思います。将来、このメモを振り返って自分がどう思うのか、少し楽しみです。

また「分析編」を書きながら「詳細編」を再々々（中略）々々度見直して、その中で「詳細編」の内容の誤りに気付いて修正をしたりもしました。

これらの作業をしつつ、改めて「現在のx86（Intel 64/AMD64）」というものを見直す、いい機会となり、また勉強となりました。

X86-Sは「レガシーを減少させた」とは言っていますが、基本的にはこれまでのIntel 64の延長線上にあります。一部機能の状態を固定し、一部の仕様を変更したものです。おそらく短期的に必要とするトランジスター数に影響を与えることはないでしょう。マイクロコードによって処理されている特権やセグメンテーションの内容が簡略化されることで、そのプログラミングと検証の工数が大幅に減少するであろう点が最大のメリットとなるでしょう。そして、Intel 64/AMD64のみが持っていて、ArmやRISC-Vには存在しない部分（リング1と2や#SS、#NPなど）を削除し、また挙動を一致させることで、LinuxやWindowsの移植性と記述性を向上させる結果になっているようにも感じました。他のCPUが持っているモード種別と同様に、Supervisor（Kernel）モードとUser32/User64モードに集約され、セグメントを起因とする専用の例外がなくなります。

今回のX86-Sがどのくらい先の将来に具体化されるのかはわかりませんが、これがIntelとAMDの対立軸にならないとよいと思っています。巨大な2社がこのような新しい「エコシステム」を築くにあたっては、ある種の「阿吽の呼吸」が必要になるものでしょう。よりよい落としどころが決まることを心から願っています。

将来的にUser32がなくなるとき、もしかするとその時にFPUもなくなるのかもしれません。そうなるとMMXも一緒になくなるということで、今まで以上に無くなるものが出てくるのかもしれません。しかし、そこに至るにはまだまだ時間を必要とするでしょう。

補足事項

X86-Sの提案を読み解くために必要となる、代表的な資料へのリンクを共有します。ただ、これがすべてというわけではありません。非常に多くのドキュメントがあり、すべてを示すのは難しいことと、あまり多くの資料を紹介しても読み切れないだろうと考えて、筆者の選択で代表的なものに絞ってみました。

インテル株式会社（IJKK）による日本語ドキュメントです。ただし最終更新が2004年から2005年と古いので、現代ではこれだけを参考にするのではなく、この後に紹介するSDMを並行して読む必要があります。

IA-32（32ビット・モード）に関する解説

X86-S EASを読むうえでは、4つのうち「システム・プログラミング・ガイド」がとても参考になりました。

EM64T/Intel 64（64ビット・モード）に関する解説

  • ※1
    今回のこの提案を見る限り、OSカーネルがX86SとIntel 64を見分けて両対応とすることは不可能ではないように思われます。ただ、個人的な意見としては、無駄に複雑化するのでやらないほうがいいとは思います。
  • ※2
    私が明確に間違っていると考えている部分を修正しています。レガシー・モードの16ビット・プロテクト・モードで必要なOSがオリジナルでは32ビットOSとなっていた部分を16ビットOSへと変更、典型的な汎用レジスター・サイズについても32ビットから16ビットへと変更しています。
  • ※3
    X86-Sが本当に一般化するかどうかは別の話です。
  • ※4
    私がLinuxとWindows以外についてあまり詳しくないので言い切ることができません。
  • ※5
    私個人としては、Oracle VirtualBoxで32ビットWindowsを動かして、古いUSB機器をその仮想マシン内で認識させて使用するなどということをしています。なので、主に業務用途だろうとは思いますが、古くからパソコンを扱っている人の中には影響を受ける人が皆無ではないだろうなと思います。
  • ※6
    別の件としては約10年前にAndroid開発環境の構築時に困ったことを「Androidアプリの開発環境にはAMD CPUよりIntel CPUの方が相性が良い」というメモにまとめて公開したことがあります。
  • ※7
    以前に書いたメモ「Intelが予定していたIA-32の独自64ビット拡張の仕様を推測する」における脚注で、このことについてまとめています。
  • ※8
    機密情報であるという表示が赤字（Intel Confidential）で入っていますが、普通にダウンロードして閲覧することが可能です。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です