はじめに

少し前の話です。2024年10月15日（アメリカ合衆国、カリフォルニア州、サンタクララ現地時間）、IntelとAdvanced Micro Devices（AMD）を含む10団体及び2名の参加で「x86 Ecosystem Advisory Group」が立ち上げられました（Intelによる発表、AMDによる発表）。

これらの影響によって、2024年12月20日（現地時間）にこれまでIntelが単独で提唱していた「X86S External Architectural Specification」という「Intel 64の整理を行う」提案が終息するということが、Tom’s Hardware.のPaul AlcornさんがIntelへと取材した結果として明らかになっています：

"We remain deeply committed to the x86 architecture, as demonstrated by the creation of the x86 Ecosystem Advisory Group in collaboration with AMD and other industry leaders. This initiative reinforces our dedication to securing a strong future for x86, building on decades of software compatibility. While we have pivoted away from the x86S initiative, our focus remains on driving innovation and collaboration within the x86 ecosystem." – Intel spokesperson to Tom’s Hardware.

"AMDや他の業界リーダーと協力して、x86 Ecosystem Advisory Groupが設立されたことからもわかるように、私たちはこれまでと同様にx86アーキテクチャーに対して深くコミットしていきます。このイニシアティブは過去何十年間ものソフトウェアの互換性を構築し、強固な未来をx86に確保することへの私たちの専念を補強するものです。私たちはX86Sイニシアティブから方針転換をしましたが、私たちは引き続きx86エコシステムの中で、イノベーションと協力を推進していくことに焦点を当てています。" – Intel 広報から Tom’s Hardware へ

引用元：Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end | Tom’s Hardware（IntelはX86Sの推進を終了 – x86命令セットの一方的な肥大化解消の探索は終了へ）※日本語部分は筆者の理解による意訳。

今回はこの件について書いてみたいと思います。

当メモにおける過去のX86-S/X86Sに関する話題について

これまで当サイトでは「X86-S」および「X86S」に関して以下のようなメモ（ブログ）を公開しています。

Intelが公表した初期の提案である「X86-S External Architectural Specification Rev. 1.0（X86-S 外部設計仕様書 Rev. 1.0） / Document Number: 351407-001」に基づく内容を私の理解による日本語で書きおこしと私的な分析を行いました：

• Intelが発表したX86-Sについて(1/3) – 概要編
• Intelが発表したX86-Sについて(2/3) – 詳細編
• Intelが発表したX86-Sについて(3/3) – 分析編

続いてIntelが公表した後続の提案である「X86S External Architectural Specification Rev. 1.1（X86S 外部設計仕様書 Rev. 1.1） / Document Number: 351407-001^※1」に基づく内容を私の理解による日本語で書きおこしと私的な分析を行いました：

• Intelが発表したX86S Revision 1.1について(1/2) – 詳細編
• Intelが発表したX86S Revision 1.1について(2/2) – 分析編

その後2024年6月には新たなドキュメント「X86S External Architectural Specification Rev. 1.2（X86S 外部設計仕様書 Rev. 1.2） / Document Number: 351407-002」が提供されました。これについては、私が個人的に読んだ以外、当サイトにおいてWebで日本語訳や私的な分析などを特に書いていません。現時点において今後も書く予定はありません。

余談ですが、同仕様書のうちRev. 1.0とRev. 1.2はダウンロードの時期によって異なる複数のファイル名で公開されていますが、内容的にはそれぞれのRev.ごとに同一です。例えばRev. 1.2の2つのファイル名のものを比較した例を示します：

2つのファイル名で配布されていたが中身は同じ

x86 Ecosystem Advisory Groupとは何か

これまではIntelとAMDはMicrosoftが関与する枠組みの中において「阿吽の呼吸」でx86を拡張してきました。基本的にはIntelがイニシアティブをもって拡張を行っています（MMX、SSE、AVXなど）。一方で64-bit化への重要な局面ではAMDが発表した「x86-64」が業界標準となり、AMDは「AMD64」として製品を発表し、Intelも同仕様をもとに「Intel 64（EM64T/IA-32e）」として採用する状況となっています。

AMDが発表したx86-64が業界標準となったのは、Microsoftとアメリカ合衆国司法省の動きによるものです。当時のAMDの影響力は現在ほどではなく、それゆえにIntelの勢力をそぎたいと考えていたMicrosoftとアメリカ合衆国司法省による影響力の行使により、現在知られている「x86-64」をベースとするAMD64/Intel 64が業界標準（デファクト・スタンダード）の地位を得ることになります^※2。

このような力比べ的なエコシステムの改編ではなく、合理的な視点に立ってエコシステムの関係者の意見/要望を取り入れる形での改編を行おうということで設立されたのが「x86 Ecosystem Advisory Group」です。これまでにIntelが立ち上げた組織、例えばPCI/PCI Expressを定義する「PCI-SIG」やUSBを定義する「USB Implementers Forum」のように運営していこうということなのでしょう。

実際、IntelとAMDによる共同プレス・リリースの中に以下のような文脈があります：

As vigorous competitors, Intel and AMD at the same time share a history of industry collaboration focused on platform-level advancements, the introduction of standards, and security vulnerability mitigation within the x86 ecosystem. Their joint efforts have shaped key technologies, including PCI, PCIe, Advanced Configuration and Power Interface (ACPI). Both companies also played a pivotal role in developing USB, a vital connectivity standard for all computers regardless of the processor. This advisory group takes this industry collaboration to the next level for the benefit of the entire computing ecosystem and as a catalyst for product innovation.

IntelとAMDは、強力な競争相手として、プラットフォームレベルにおける拡張、標準の導入、x86エコシステム内におけるセキュリティー脆弱性の軽減に焦点をあてた業界内の協力体制を共有します。共同する取り組みとしてPCI、PCIe、Advanced Configration and Power Interface（ACPI）などの主要な技術を（これまで）形作ってきました。両社はまた、プロセッサーに関係なく、すべてのコンピューターにとって重要なUSBの開発において極めて重要な役割を果たしています。このアドバイザリー・グループは、これらの業界コラボレーションを次のレベルへと引き上げ、コンピューティング・エコシステム全体の利益と製品のイノベーションとして作用します。

引用元：Intel and AMD Form x86 Ecosystem Advisory Group to Accelerate Innovation for Developers and Customers（IntelとAMDが86 Ecosystem Advisory Groupを設立し、開発者と顧客のイノベーションを加速する ）※日本語部分は筆者の理解による意訳。

ここでうたわれているような実績を残せるかどうか。今後の活躍が期待されていくところです。

これらにメンバーに連ねているのは以下の個人あるいは団体です：

• Linus Torvalds（個人）
• Tim Sweeney（個人）
• Broadcom
• Dell
• Google
• Hewlett Packard Enterprise
• HP Inc.
• Lenovo
• Meta
• Microsoft
• Oracle
• Red Hat

各メンバーがどのような意図をもってx86 Ecosystem Advisory Groupへ招かれ、また参加したのかを少し考えてみましょう。

個人としてはLinus Torvaldsさんは言わずと知れたLinuxカーネルの開発リーダーであり、ご当人がどのように考えているのかは別として、結果として各種ISA（Instruction Set Architecture：命令セット・アーキテクチュアー）の実質的な取捨選択権を持つ最大の権限を有しています。つまり、言い換えるならLinuxカーネル・レベルでのISAを取り仕切る最大の権力者ということができます。一方でTim SweeneyさんはUnreal Engineの開発者として、アプリケーション・レベルでのISAについて意見することで影響を与えうる人物であるといえるでしょう。

このように役割の異なる個人である両者がこのグループに入っているというのは、カーネルとアプリケーションのバランスの面でよい選択であるように思います。^※3

法人であるBroadcomはやはりVMware関連での参加でしょうか。ISAの改編は彼らのビジネスにも影響を与えます。Dell、Hewlett Packard Enterprise、HP Inc.およびLenovoはサーバーおよびパソコン・メーカーとしての参加であることは間違いないでしょう。GoogleとMeta、Oracleはクラウド分野としての参加、Red HatはLinuxベンダーとしての参加でしょう。Microsoftは幅広い意味を持ちそうです。WindowsやOfficeのソフトウェア開発ベンダーであったり、Azureを擁するクラウド分野としての立場もあります。

一方で名を連ねていても不思議ではないいくつかの会社が入っていません。こちらのほうが気になるといえば気になります。

例えばAmazon.comは世界最大のクラウド・サービスであるAmazon Web Servicesを展開しています。近年は独自設計の「AWS Gravitonプロセッサー・シリーズ（Armアーキテクチャー）」推しが進んではいますが、それでもx86-64の方の数が多いことから、参加しても不思議ではなかったように感じられます。また、これまでの経緯から、Intelが声をかけていないとは考えづらいので、何らかの理由でメンバーに入ることをAmazon.com側が断ったのではないかという憶測あるいは妄想が膨らみます。

またInternational Business Machines（IBM）はどうでしょうか。クラウド分野ではある程度ビジネス的な関与がありますが、今回はメンバーに入っていません。傘下のRed Hatが参加しているので控えたのでしょうか？

私はこれまでもIntelとAMDの間には「阿吽の呼吸」が必要であると何度か書いてきました。これまではアメリカ合衆国独占禁止法の制約もあり、IntelとAMD「だけ」の間でコミュニケーションを持つことが難しかったことを鑑み、多くの利害関係者を一堂に会すことにより、これらの法的な問題点を回避しつつ、未来を語る場を設けるための手段としてx86 Ecosystem Advisory Groupが設置されたのではないかと私は考えています。

結局X86Sとはなんであったのか？

私は当初の「X86-S」は規格としても実現対象としても比較的シンプルであったという感想を持っています。内容はIntelとAMDの両方で実現不可能ではないようであったように考えており、当初の考察の中でもそのように書いています。

その後、Intel社内の各セクションからフィードバックがあったのだろうと思いますが、結果として、Intel社内で提案されている各種仕様や枠組みが内容に盛り込まれるとともに、この機会に「他のISAと同じようにシンプルにしたい」という勢力が参加してきたことで「単純に機能を外すだけではない仕様変更」がRev. 1.1で組み込まれ始めます。この追加された変更は同ドキュメントの後半にある、Intel 64互換の仮想化の枠組みとしての考察を壊す内容となっているのですが、そちらは手つかずで、結果としてドキュメントの一貫性が失われていました。これはRev. 1.2でも修正されていません。

つまり、Intel内部のアーキテクチャーとの互換性をとりつつも、現状で使われていないモードや機能を削減するというシンプルな目的から、この機会に現行のISAで修正したい部分を同時に仕様変更する、そんな目的へと変化をしていったのが最終的なIntel X86Sなのではないかと、私は見ています。

振り返ってみれば、x86-64の最大の強みは「互換性」にあったわけです。それをIntel自らが損ねるような独自提案を持ち出したのはあまり筋がよくない手であったのかもしれません。このことをIntelが認識した、というのが冒頭で引用したIntel 広報からTom’s Hardwareへの回答の中で言及されている「互換性」に関する意味合いではないかとも思えるのです。

x86-64、AMD64、Intel 64

AMDが発表した「x86-64」、その後実際にAMDが製品化した「AMD64」、そしてMicrosoftとアメリカ合衆国司法省の圧力によってIntelが取り入れたx86-64互換の「Intel 64（IA-32e/EM64T）」はそれぞれが若干異なる仕様となっています。もう少し言及するなら、「x86-64」から「AMD64」が派生し、同様に「Intel 64」も「x86-64」から派生したISAとなっています。このことから、現在のISAを表現するときに「AMD64」あるいは「Intel 64」と表記するよりも、「x86-64」と表記するほうが中立的なのではないかと私は考えています。^※4

実際にいくつかのLinuxディストリビューションはそうしていますし、AMD64と表記しているケースも少なくありません。これはIntelがIntel 64をリリースしたのがAMDによってAMD64がリリースされたことよりも遅かったという時系列的な影響によるもので、特別な意味はおそらくないのでしょう。パッケージ名のルールを決めた後にそれを変更するコストは簡単には正当化できないものがあるからです。

ここで重要なのは、これまでAMD64とIntel 64はプラットフォームのレベルで互換性の問題を起こさない範囲で独自の拡張を続けてきたことにあります。これが私がこれらのメモで言及するところの「阿吽の呼吸」です。それでも一部は両社で異なる仕様となっています。特に仮想化技術に関してはIntelの「Intel VT-x」とAMDの「AMD-V」における、ISAレベルでの互換性の無さは「言及するに値する」部分だと考えています。また、近年のx86-64に対するセキュリティー関連の対応における取り組みについては、Intelによる「Intel Flexible Return and Event Delivery（FRED）」とAMDによる「AMD Supervisor Entry Extensions」との互換性のなさについて、これまでも言及してきました。そして、さらに別の側面での提案あるいは仕様が両者の間で互換性が得られない形のものが増え続けていました。

x86-64を除けば、IntelはAMDの仕様を取り込まず、自身で仕様を決定し、実装をする形をとり続けてきました。Intelは「Intel 64」の取り込みを行う時点で「AMD 3D Now!」を無視しました。その後AMDはIntelが追加した「Intel SSE」を取り込む形で「AMD 3D Now! Professional」をリリースしますが、最終的に当初の「AMD 3D Now!」を放棄しています。その後、IntelはSSEシリーズの更新、AVXシリーズのリリースと更新を続けています。そしてAMDもこれらの仕様を自身の製品に取り込む形で追従を続けているのが2024年末時点での現在位置です。

そして現状に目を向けると、Intelはほかにも計画を今回話題の対象となっている「X86S」を含めて複数発表しています。：

• Envisioning a Simplified Intel® Architecture（X86S）（※本文のダウンロード提供は終了済み）
• Intel® Advanced Vector Extensions 10.1
• Intel® Advanced Performance Extensions (Intel® APX) Architecture Specification
• Flexible Return and Event Delivery (FRED) Specification

私が現時点で把握しているだけでもこれだけあります。実際にはまだ多くあるのかもしれません。今回終了したX86Sだけではなく、その他のx86アーキテクチャーへの変更も今後は「x86 Ecosystem Advisory Group」への提案を経て審議され、仕様を確定し、製品に実装していくことになるのでしょう。そして、AMD側が提案している「AMD Supervisor Entry Extensions」などの関連技術も同様になるのであろうと思われます。

少し話がそれることになりますが、ISAに関するIntelの興味深い主張をここで紹介したいと思います。

IntelがAPXの概要を説明する「Introducing Intel® Advanced Performance Extensions (Intel® APX)」というページ本文の最後部に以下のような記述があります：

Intel APX demonstrates the advantage of the variable-length instruction encodings of x86: New features enhancing the entire instruction set can be defined with only incremental changes to the instruction-decode hardware. This flexibility has allowed Intel architecture to adapt and flourish over four decades of rapid advances in computing, and it enables the innovations that will keep it thriving into the future.

Intel APXは、x86の可変長命令エンコーディングの利点を提示しています：命令セット全体を強化する新機能は、命令デコード・ハードウェアを段階的に変更するだけで定義できます。この柔軟性により、インテル・アーキテクチャーは、40年にわたるコンピューティングの急速な進歩に適応し、繁栄することができ、また将来にわたって繁栄し続けるためのイノベーションを獲得できます。

引用元：Introducing Intel® Advanced Performance Extensions (Intel® APX)（Intel Advanced Performance Extensions (Intel® APX)の紹介）※日本語部分は筆者の理解による意訳。

かつて1990年代にRISC・CISC論争というものがありました。これは固定長の命令がいいのか、可変長の命令がいいのかといった部分も包含していました。いま現在は命令デコード・ハードウェアの実装はかつてほどプロセッサーの中で大きな割合（トランジスター・バジェット）を占めません。そして当時よりも相当にリッチな実装とすることが可能となっています。また、アウト・オブ・オーダー実行するために、命令デコード・ハードウェアと命令実行ハードウェアを別レイヤーとする実装が一般的になったということもあります。結果としてアウト・オブ・オーダーで実行可能なオン・ザ・フライの命令の数が増加したという現実があります。こうしたことを踏まえて、可変長の命令の方が優位な面がある、という立場に基づいてIntel APXは設計されたということを「わざわざ」表明しているわけです。

私はこれを読んでニヤっとしてしまいました。いったいどちら方面に対して向けられている主張なのでしょうか。

x86 Ecosystem Advisory Groupに求められる役割

「x86 Ecosystem Advisory Group」に求められる役割はいったいどういったものがあるのでしょうか？

1つはIntelとAMDそれぞれから出てくる新たなx86アーキテクチャーへの改編要求に対するエコシステムの維持、すなわち両社におけるアーキテクチャー分裂の回避、すなわち互換性の維持を可能とするための審議が考えられるでしょう。例えばIntelが提案する「Intel FRED」とAMDが提案する「AMD Supervisor Entry Extensions」に存在する齟齬をどのように解消・統合し、そもそもそれぞれが目的としていたターゲットから外れないレベルでの解決を図ることができるのかどうか。そのあたりが最初の試金石となるのではないかと思われます。

個人的な感触では「Intel FRED」の方が「AMD Supervisor Entry Extensions」よりも根本的な改修を行うことにつながることから、両社が未実装であれば「Intel FRED」へ寄せる側への実装のほうが今後のx86エコシステムへ資するのではないかと考えます。

そして、最後に指摘をしておかなければならないことがあります。それぞれの知的所有権はIntelとAMDがそれぞれ個別に所有しています。現在はそれらをクロス・ライセンスとして両者の間で結んでいるという現実です。つまり「x86 Ecosystem Advisory Group」で議決したことをIntelとAMDが受け入れなければならないという法的根拠はありません。この辺りは両社が歩調を合わせている間は問題はないのですが、もしも今後予期しない理由で対立することとなった時にはいささかの不安が残ります。これはまた、クロス・ライセンスを締結していないIntelとAMD以外の企業がx86-64へ参入する障壁がそれなりに高くなる副次的な効果があるのではないかと思えるのですがいかがでしょうか^※5。

先にも取り上げましたが、現時点においてIntelが事実上の盟主となっているPCI/PCI ExpressのPCI-SIGやUSBシリーズのUSB Implementers Forumのように、これらの運営が良い方向で進んでいくことを期待します。とはいえ、Intelの企業経営資源の根幹である「x86」に対して、長年にわたって同様にニュートラルでいられるかどうかを現時点で予想するのは難しいところです。

各組織における強力な実行者の必要性

今回の合意の当事者である、AMDのCEOであるリサ・スーさんは当事者としても、またAMD社内の権限保持者として十分だとして、Intelでこの合意をした前CEOであるパトリック・ゲルシンガーさんはCEOを退任してしまっています。後任者がこの枠組みを受け入れて、Intel社内に対して必要な権限委譲とコミットメントを与えるのかどうかは現時点では何とも言えないように思えます。次のIntelの経営者がこれらの枠組みを理解して同意するかどうかは、現時点では不透明だからです。次の経営者がx86というものをどれくらい理解している人物になるかも明確ではありません。これが、x86 Ecosystem Advisory Groupの現時点における最大の懸念点ではないでしょうか。

まとめ

一言でいえば「x86 Ecosystem Advisory Group」が生まれ、「X86S」は終わりました。今後「X86S」について考える必要はありません。

現在の「x86-64」のライバルである「Arm」との比較についても少し書いてみましょう。

Armは32-bitのArm32と64-bitのArm64ではいささか異なるISAを採用しています。そしてArm系のプロセッサーには32-bitをサポートしないものも存在しています。これは整理が実行された一例ということができます。では、x86-64ではどうでしょうか。ここが興味深いのですが、x86からx86-64へは「後方互換性を多く提供する」という形で行われたことでメインストリームになることができました。その反面、x86（IA-32）と互換性がほとんどないIA-64は明確に失敗しました^※6。しかし、前述のようにArmでは様相が異なり、32-bitと64-bitでは互換性がx86ほどありません。それでも移行に成功したのです。プラットフォームがスマートフォンとパソコンおよびサーバーということで異なる点もありますが、ISAの移行の例としては無視できない事例と言えるでしょう。

歴史が長いx86は多種多様なソフトウェア資産とそれに伴うレガシーを持っていて、それゆえにこれらを完全に払しょくするのが難しいという立場なのかもしれません。

Appleのようにすべてを自社でコントロール可能な状態で保有しているのであれば、この程度のISAの改編は簡単であったのかもしれませんが…。

• ^※1

  本来のIntelの対応であれば「001」の部分が更新されるごとにインクリメントされていくのですが、この更新では異例でインクリメントされていませんでした。
• ^※2

  このことは2013年8月に「Intelが予定していたIA-32の独自64ビット拡張の仕様を推測する」というメモの脚注で考察しています。
• ^※3

  個人的にはゲーム・エンジン双璧といえるUnity側の参加者がいないことについて興味深く見ています。これは両プロジェクトに対する個人の影響力を検討したうえで人選をしたということかもしれません。
• ^※4

  一方でMicrosoftによる「x64」という表現はIntelとAMDの間に立って調整役を務めることになった綱引きの結果であると私は考えています。もっとも、当初は「AMD64」用に開発していたということで、現在でも「AMD64」という文字列があちこちに出ているですけれども。
• ^※5

  ネイティブのプロセッサーがx86/x64-64以外でエミュレートする場合を一定程度含みます。
• ^※6

  中期までのIA-64はIA-32をハードウェアで実行することができますが、性能は出ません。その後IA-32ELというソフトウェア実装ベースのIA-32実行エンジンへと切り替えられました。こちらのほうが性能が出たとのことです。