Intel、64ビットモードオンリーアーキテクチャ『x86S(仮称)』のビジョンを公開 130
ストーリー by nagazou
IA-64のことは忘れよう 部門より
IA-64のことは忘れよう 部門より
Intelが命令セットを64ビット専用アーキテクチャに最適化する「x86S」構想を公開した（Intel開発者ブログ、Tom's Hardware、TEXAL、自作ユーザーが解説するゲーミングPCガイド）。
この内容を記したIntelの開発者ブログによると、MicrosoftもWindows 11の32ビット版の出荷を停止、すでにOSは64ビットが事実上の標準となっている。こうした背景もあり、Intelはすでに時代遅れの実行モードを削除するなどのハードウェアとソフトウェアを簡素化する必要があると考えているという。そこで今回、Intelはプロセッサ命令セットアーキテクチャ (ISA) の簡素化を想定した「Intel x86S」アーキテクチャに関連したホワイトペーパー[PDF]を公開したとしている。
現状のIntel 64アーキテクチャでは、システムリセット後にオリジナルの8086と同じ状態になり、64ビットモードに入るためには一連のコード遷移が必要となっている。今回提示された「Intel x86S」では、32ビットアプリケーションのセグメンテーションサポートに64ビットの簡略化されたセグメンテーションモデルを使用し、現代のオペレーティングシステムがすでに使用しているものと一致させる。最近のソフトウェアでは使用されていないリング1およびリング2、ゲートのような旧式のセグメンテーション機能を削除する。古い16ビットアドレッシングのサポートを削除、ストリングポートI/Oを廃止、APICの使用をX2APICに制限、レガシー8259のサポートを削除するなどといった変更を提示している。
この内容を記したIntelの開発者ブログによると、MicrosoftもWindows 11の32ビット版の出荷を停止、すでにOSは64ビットが事実上の標準となっている。こうした背景もあり、Intelはすでに時代遅れの実行モードを削除するなどのハードウェアとソフトウェアを簡素化する必要があると考えているという。そこで今回、Intelはプロセッサ命令セットアーキテクチャ (ISA) の簡素化を想定した「Intel x86S」アーキテクチャに関連したホワイトペーパー[PDF]を公開したとしている。
現状のIntel 64アーキテクチャでは、システムリセット後にオリジナルの8086と同じ状態になり、64ビットモードに入るためには一連のコード遷移が必要となっている。今回提示された「Intel x86S」では、32ビットアプリケーションのセグメンテーションサポートに64ビットの簡略化されたセグメンテーションモデルを使用し、現代のオペレーティングシステムがすでに使用しているものと一致させる。最近のソフトウェアでは使用されていないリング1およびリング2、ゲートのような旧式のセグメンテーション機能を削除する。古い16ビットアドレッシングのサポートを削除、ストリングポートI/Oを廃止、APICの使用をX2APICに制限、レガシー8259のサポートを削除するなどといった変更を提示している。
トランジスタはどれくらい節約できるんだろう？ (スコア:4, 参考になる)
32bit専用の論理回路・トランジスタを削除できるので
CPUがスリムになり省電力化・低価格化に繋がりますね。一般ユーザにもメリットがあります。
開発者には特にデメリットはないように見えます。ざっとpdfを眺めた限りでは、既存の64bitのOS・ソフトは大きな変更は不要そうです。
コンパイラとかOSの細かい部分は修正が必要です。しかしこれは過去インテルが新しいCPUを出すたびにインテルの社員が修正してきた作業と同じなので
これはインテルに任せておけば解決します。
BIOSは書き換えが必要です。でもチップセットもCPUも新しくなるんだから、これはマザボメーカが対応すればいい話だし
ブートシーケンスは今までのCPUよりも x86S の方がシンプルで実装も簡単そうです。開発者はさっと実装すれば良くて、消費者はそれを買うだけです。
ということでポイントはどれくらいトランジスタ数が節約できるか、だと思います。省電力化・低価格化に寄与するならx86Sは売れるでしょうし、すぐに普及すると思います。
Re: (スコア:0)
トランジスタ数を減らすことより、開発・検証・デバッグの手間を減らすことの方が大きいのでは？
レガシー機能を削除することにより、これらの手間がごっそり減る
Re: (スコア:0)
正直この程度の回路削減では省電力化にも低価格化にも繋がらん気がする。
コンパイラレベルの話をするとアプリ層とかドライバ層だと何もしなくても理論上問題ない気もする。
まあ理論上はあくまで理論の上の話でだいたい阿鼻叫喚になるのだが。
Re: (スコア:0)
トランジスタが減るかと言われればあまり減らないと思います。
演算器は共通のものだし、影響するのはデコーダの一部ではないでしょうか。
デコーダ部のトランジスタが減ったとしても、モードで動作切り替えてるだろうから消費電力は減らなそう。
主に削減できるのは、CPU設計後の検証・実機テストのコストではないでしょうか。
この辺は機能が減れば素直にコスト減りますし、昨今面倒になってるセキュリティ関連では組み合わせの数が減れば劇的に楽になると思います。
Re: (スコア:0)
命令デコードはマイクロコードで行われているため、回路規模への影響はほとんどないでしょう。
回路を簡略化できそうなのは16ビットアドレッシング廃止によるアドレス計算/MMU関係やセグメンテーション簡略化の方かなぁ。
それにしても16アドレッシング廃止ということは、ついにMS-DOS用のプログラムは一切動かなくなるってこと？
それとも以前から動かない？
Re:トランジスタはどれくらい節約できるんだろう？ (スコア:1)
それにしても16アドレッシング廃止ということは、ついにMS-DOS用のプログラムは一切動かなくなるってこと？
それとも以前から動かない？
「グラフィック等の周辺機器からして実PCで動かすほうが辛くなってきたろうから、MS-DOS用プログラムは仮想PCで使え」という、公式（どこ？）からのお達しかもしれません。
でも、今でもMS-DOS用プログラムが必要になる場面というと、Windows用ドライバが供給されてない古い周辺機器を動かし続けるためぐらいだろうから、実PCで動けないと無意味ですかね。
Re:トランジスタはどれくらい節約できるんだろう？ (スコア:2)
Re: (スコア:0)
KVM等PCIパススルーやUSBパススルー機能がある仮想マシンはホストを通さずゲストが直接ハードウェア叩けるので、なんとかなるかも。
ISAバスボードやCバスボードは、USBなりPCIeなりに変換するアダプターを作るんでしょうね。
今ならFPGA使えばカスタムチップは作らないで済むでしょうし。
Re: (スコア:0)
まずはXeonからでどうだろう (スコア:4, 参考になる)
X64#動作モード [wikipedia.org]でいうところの、Legacy モード（386 プロテクトモード、仮想 8086 モード、リアルモード）の切り捨てという認識で良いのだろうか。
つまり、OS とデバイスドライバは 64bit が必須だけども、アプリケーションは 32bit で動作可能。なら、問題は少なそう。32bit OS をハードウェア支援ありの仮想環境で動かすことができるかどうかぐらいかな。
16 bit アプリケーションも CPU 的には動作可能なのかな（OS がサポートすれば、だけど）。
前からサーバ用途に 386 プロテクトモードとかいらないよなと思っていた。macOS が一番先に全ての 32bit を切り捨てたけど、Apple シリコン Arm に移行してしまったから関係なくなってしまった。
Arm 系統なら Snapdragon 8 Gen 2 [impress.co.jp] のように 64bit 専用コアと 32/64bit 対応コアを混載できるわけだから、Intel だって E コアのみ従来アーキテクチャとかできるかもしれないけど、必要性は感じられない。
Re:まずはXeonからでどうだろう (スコア:2)
なるほど。ありがとうございます。
"Removal of 16-Bit and 32-Bit Protected Mode" というのは（全ての）16 bit モードと 32 bit プロテクトモード、という意味なんですね。それとは別に "32-bit submode of Intel64 (compatibility mode)" があって、これは still exists. だと。
AMDを除外する何かがなければ問題ない (スコア:1)
Intel一人勝ち時代には絶対に戻って欲しくないので。
Re: (スコア:0)
x64を作ったのはAMDなのでむしろAMD一人勝ちになったのかもしれない
隠し玉 (スコア:0)
AMDが次の世代リリースでポンとこんな感じな実物を「ほれ」と出して来たら
笑える。
Re: (スコア:0)
AMDが次の世代リリースでポンとこんな感じな実物を「ほれ」と出して来たら
笑える。
昔のAMDならすっぽんてな感じで逝けてた
Re: (スコア:0)
AMDも追従するとおもう
Intelのx86Sとほぼ同じものを作って合わせてくるのでは？
Re: (スコア:0)
AMD除外は肝心のMSが納得しないだろうな。
そもそもXBOXはAMDだし。
たくさんコアがあるんだから.... (スコア:1)
16bit用のコアを一つ用意しておいて、
いざというときには、16bit で動くといいな...
まあ、たぶん使わないけど。
消費電力が上がるとか、速度が上がるとか、価格が下がるとか、
メリットがあればいいな。
Re:たくさんコアがあるんだから.... (スコア:2)
8086コア内蔵CPUとかですか。
16bitモードもありますので、32bitの80386内蔵でもいいかもしれません。
Re:たくさんコアがあるんだから.... (スコア:2)
Re:たくさんコアがあるんだから.... (スコア:1)
確かに....
32bitアプリが多数あるのでヤダ (スコア:0)
Windowsは64bit版を使ってるが、32bitアプリを多数使ってる
しかも、その中には更新停止されて64bit化が期待できないものが多い
なので32bitアプリが使えなくなるのは非常に困る
いっそ、64bit専用コアと、32/64コアを乗せて、
32bitアプリは両対応のほうで動かすとかやってほしいな
Re:32bitアプリが多数あるのでヤダ (スコア:1)
Using the simplified segmentation model of 64-bit for segmentation support for 32-bit applications, matching what modern operating systems already use.
って書いてある。何を意味するのかは知らないが。
Re: (スコア:0)
64ビットOSで動く32ビットアプリの互換動作向け機能は残ると
Re:32bitアプリが多数あるのでヤダ (スコア:1)
64bit OS上で32bitアプリは動くよ。
Supported Operating Modesに、
User32 (restricted ring 3 compatibility mode)
とあるので。
動かないのは32 bit OS。
64bit OS上で32bitアプリは従来と同様、ハードウェアで実行されるので、速度低下とかない。
Re:32bitアプリが多数あるのでヤダ (スコア:1)
仮想32bit互換モードを持つというからOSや仮想環境ソフトが対応すれば、仮想環境モードで純粋な32bitアプリならば動作するようだ。でも、一部で16bitコードが残っているから使えないとかインストールできないとかはありそうだ。今からでも、5年計画ぐらいで32bit依存のアプリは代替していけという話だろう。次々世代のWindowsでは動かない可能性が大ということでな。
Re: (スコア:0)
XP 64の時代から64ビット版Windowsでも16bitコードは動かんから、よほど特殊な環境以外ではユーザーにとっては何も変わらん。
Re:32bitアプリが多数あるのでヤダ (スコア:1)
Windows 11限定でいえば、x86コアなんて搭載もしてないWindows on ARMでWindows95時代のソフトが普通に使えてるので、よっぽと異例なことをしてるソフトじゃなければ大丈夫じゃない？
Re: (スコア:0)
多分そういう話にはならない。古いOS(現行のOS全部)とかOS使わずCPUを直接操作するソフト以外は多分問題ない。
仮想化ソフトもだめかな？
Re: (スコア:0)
32bitアプリは多分問題ない。というか多分影響を受けるのはMSDOSからWindows 3.1までとひょっとしたら全ての16bitアプリ。
16bitアプリは既に64bitWindows上では動かないので問題ないかと。
これ結局ブートローダーしか影響ないのは？現行のOSもブートローダー内で64bitモードに遷移するまでのおまじないはいい感じに互換性保ってくれるだろうし。
Re: (スコア:0)
64bitOS上では32bitのソフトは
WOW64で64bitに変換されているから
既にそのまま実行してないだろ
Re:32bitアプリが多数あるのでヤダ (スコア:1)
安心しろ
間違ってるのはお前ら二人だ
Re: (スコア:0)
32bitのソフトウェア資産を活用するなら仮想マシンを使って丸ごと32bit OS動かしてね～という方向ですね
ただし32bit OSのインストールCD/DVDは自前で用意してね～ということで、結局32bitは消え去る運命
＃Windows2000以降のOSの仮想マシン用インストール・イメージをしっかり保存している俺は勝ち組（さすがにWindows95/95/Me系の出番は無い）
Itaniumだっけ (スコア:0)
あれ的な何かって事？
Re:Itaniumだっけ (スコア:1)
どっちかというと80376か？
Re: (スコア:0)
まあだいたいあってる。いっち率は3割くらい？
Re: (スコア:0)
全然違う
新命令セットの開発じゃなくて16ビットモード廃止・32ビットモードの簡略化・起動時から64ビット(AMD64)モードで動くってだけ
いいんじゃないかな (スコア:0)
アプリにしろソフトにしろドライバにしろ現状で64bit化できていないものなんて更新の見込み薄な脆弱環境なんだし
切捨て予告は早めに耳タコな刷り込みしていくのはいいことではないかと
ブートシーケンスがシンプルになるかな (スコア:0)
今は64ビットに移行するまでが面倒くさいよね？
#わかっている人にはどうってことないのかもしれんが
OS (スコア:0)
対応するLinuxはすぐにでも出てきそうだな。
対応するWindowsはいつ出てくるのか?
Windows 12 x86S Editionとか出てきそうだな。
Windows 12の名称は確度が高そうだが、13の数字を避けるとしたら、名称を変えるとともにアーキテクチャも変わる可能性は高い。
歴史は繰り返すで、数年後にはアップグレードできないという恨み節が聞かれそうである。
Re: (スコア:0)
Windows Boot Managerの変更だけで動く可能性が高いんじゃないかな
Re:OS (スコア:1)
緊急時 (スコア:0)
いざという時FreeDOSが動かないと困る場面がありそうですが、FreeDOSで出来ることの大半はUEFIシェルでできる世の中だから影響はないかも。
それはさておきbashっぽい挙動とコマンドのUEFIシェルは作っては駄目なのでしょうか。DOSっぽくても我慢します。
Appleができてるのにできないはずがない。 (スコア:0)
Appleはあれだけコロコロ変えてどうにかなっているんだからIntel + MS でできないはずがないよね。
Re:Appleができてるのにできないはずがない。 (スコア:2)
まあ、ハードもソフトもコントロールできてるからこそなんだけど。
そのレガシー切り捨てのポリシーのお陰で、仮想化環境の構築が必要な場面は出てくるが、
環境がレガシー化するころには、仮想化のオーバーヘッドは無視できる程度にはなってるので無問題ではある。
Re: (スコア:0)
なんとかなってるんじゃなくて、ユーザ側でなんとかしてるだけでは？
遠慮なく切り替えられるなら、x86_64なんて存在してないさ。
Re:Appleができてるのにできないはずがない。 (スコア:2)
ROMだったりインストールCDとか手元にあるわけですし。
今回のケースは、Appleのポリシーが間違ってなかったよねーというお話ではないでしょうか。
ユーザーコストは確かにありますが、20年以上のレガシーサポートはどうよ、という気もします。
AS/400のような特殊な環境ならいざ知らず、コンシューマ製品でのサポートはさすがに過剰品質な気がします。
16ビット32ビットサポート切ってもエミュレーターで大方解決しますので、まあ判断が遅かったぐらいじゃないですかね。
UEFI出した辺りでやっておくべきだったように思う。
WIndows8あたりなんて、UEFIとレガシーBIOSが入り乱れてて、非常に素人向けサポートが大変だった記憶が。
Re: (スコア:0)
Intel + MS
インターネット老人会「ウィンテル [wikipedia.org]と言えば、一単語なんじゃよ」
検索性 (スコア:0)
「x86S」は、「x86」と分けて検索したいときにひと手間かかるかも。
なんでX86-Sなんだろう (スコア:2)
事実上 Intel64 の制限モードなんだから Intel64-S とでもすればいいと思うんだけど。
x86 と x64 とで分けるのが一般的なところに x86-S が登場したら、混乱する人は多いのでは？