大原雄介の半導体業界こぼれ話
雑談2題～X86-Sのメリット、業界標準の上手な作り方
2023年6月29日 06:13
5月末からCOMPUTEX/TAIPEIが開催されたものの、Intel/AMDは基調講演もブースも設けないという寂しさで、PC機器メーカーなどは気を吐いていたものの、会場の面積そのものも2019年に比べて大幅削減(TaiNEX 1で2フロアとTaiNEX 2で1フロアの半分弱)となっていた。
特に減ったのは小さな企業で、組み込み系企業はコロナ禍の間に出展の場所をCOMPUTEX以外に移してしまったようで、そうした組み込み系を期待していた筆者には結構肩透かしであった。それでもArmの新製品発表とかAMDのExectiveとのインタビューなどの時間は取れたので、辛うじて取材経費はペイした気はするのだが、来年以降どうするかちょっと悩んでいる。
ということで、ちょっと今月は大ネタがないので雑談を2つほど。
16bitを削ることでIntelにメリットはあるのか?
5月22日に、Intelが16bitのサポートを廃したx86-Sに関するプロポーザルを公開したのはちょっとだけ物議をかもしたが、未だに古いOSを使い続けているというごく少数のユーザーを除くと、あまり大きな影響はないということもあって、割とすぐに落ち着いたように思う。
実際のところ、完全に32bitのサポートを切ったArmのTCS23と異なり、まだ32bitのアプリケーションはそのまま動作する(さすがに16bitアプリケーションは動かないが、既にOS側のサポートがなくなってるようなものだから、これで困る人はほとんどいないハズ)から、影響を受けるのはOSとかBIOSを書いているエンジニアであって、しかもブートの際に16/32bitモードでの動作を想定する必要がないからむしろ楽になる、という話である。
もちろん実際にはいきなり「x86-S未サポートのCPUは対応しません」とはできないから、仮にx86-S対応CPUが出て来た場合には、x86-S対応と未対応の両方をカバーする必要があるため、一時的には面倒なことになるとは思うのだが。
さて、この変更で「Intelにはどんなメリットがあるのか?」を考えてみた。最初に思いついたのは、「16bit命令を省くことでオペコードに空きが生まれる」ことだ。
ご存じのようにx86命令は、そうでなくても64bit拡張を行なった時点でかなりの命令数なのに加え、MMX/SSE/SSE2/SSE3/AVX/AVX2/AVX512と拡張命令セットをどんどん加えており、結果既に1Byteオペコードテーブルは完全に埋まり、2Byteオペコードテーブルも半分以上が使用済。3Byteオペコードテーブルも結構使われている(ついでにオペコード拡張まで定義されている)。この中で16bit命令は、一番高価な(なにせ1Byteのデコードで命令が特定できる)1Byteオペコードテーブルを占有しているわけで、これが空けば将来の命令拡張に効果的なのでは? と思ったのだが、結果はノーだった。
調べてみたら、確かに16bit命令は1Byteオペコードにマッピングされており、しかも64bitモードでは動作しない(Photo01)。ところがこれらの命令は32bit(つまりCompatibility sub mode ring 3)では動作するのだ。だから、16bitをサポートしないからといって排除するわけにはいかない。
ではオペコードが空くわけでもないし、命令セットを省けるわけではない(16bitモードの動作をサポートしなくても良いといっても、それはアドレス生成部の実装だけで、命令の実行部そのものに変化はない)から、実質Intelが得られるものはそれほどないと考えて良い。
では何もメリットがないのか? といえばそういうわけでもなく、少なくともこれでブートシーケンスは数ms程度高速になるだろう。下図でも分かるように、従来は初期化あるいはリセットが入ると、一度16bitに戻ってそこから(場合によっては32bitモードを挟んで)64bitモードに移行していたわけで、このモード切り替えに相応の時間が掛かる。
最近だとセキュアブートが必須になってきた関係もあり、そうでなくてもシステムブートには時間が掛かる。Intelは2021年に“Early Platform Hardening Technology For Slimmer And Faster Boot”という、迅速なセキュアブートを実現するためのハードウェア構成を特許出願するほどに、ブートの高速化を追求している。何もしなくても最低でも数msかそこらを短縮できるx86-Sは、この目的にはありがたいのは間違いないだろう。
もっとも、Intelのメリットとして思いつくのはせいぜいがこの程度。もちろん16bit/32bitの実装や検証の手間が省けるというメリットもあるが、それはもはや大きな負荷になっていたとは思えない。
どちらかと言えば、未だに16/32bitのハンドリングを余儀なくされるOSのブートローダとかBIOSの設計者から「いい加減止めてくれ」の声が大きかったかもしれないが、ここのロジックは今更改良しようもないし、それこそROM BIOSの時代はともかくUEFIの時代だとメモリが節約できるといってもその効果はわずかである。
要するにこの16/32bitモードを利用したブートというのは、いわばx86の盲腸みたいなものであって、それを削減してスッキリさせたという以上の話ではないのかもしれない。
標準規格の上手な作り方
話は変わるが、最近RISC-Vの興隆を目にしつつ、それにソフトウェアエコシステムの整備が追い付いてないあたりに、RISC-V Internationalの中の運営委員会の難しさを色々考えていた。
なんて話をJim Keller氏とのインタビューの中でぽろっと漏らしたら偉い勢いで色々反論というか「いやそんなことはないんだ」的説明を受けたりしたのだが、まぁ実際RISEのように取り組みが始まっているあたりは、現状(筆者の主観ではArmの10年遅れ)が5年も待たずに現状のArmのServer Ecosystemに追いつけるようになるかもしれない。
もっともサーバーはともかく、MCUのマーケットに関して言えば野放しというか無法状態が引き続きまかり通っており、2月の記事で触れたRVM-CSIが使われている気配がさっぱりないあたりが、今後チップ数が増えてゆく中での混乱を予想させる。
まぁ今回は別にRISC-Vの話をしたいわけではなく、もっと一般的な話である。
一般論として標準化には猛烈に時間が掛かる。再びRISC-Vの話で恐縮だが、RISC-VのVEE(Vector Extention)が最初に言及されたのは2017年のRISC-V 7th Workshopだった(この時はVersion 0.1)。これの標準化が完了した(というか、Version 1.0が出た)したのは2022年6月のことで、実に5年も掛かっている。たかがベクター拡張命令ですらこれである。
実は標準規格をスクラッチから作る場合、数年を要するというのは珍しい話ではない。Internet Watchの方で連載している「期待のネット新技術」で2021年に取り上げた光Ethernetの規格だが、IEEEの方で標準化されたものは大体3年とか4年を標準化に要している。
もっとひどい例はUWBで、3年あまりを討議に費やした挙句、規格不成立として終了している。そして、標準化に時間が掛かった規格は、他に代替案がなければそれでも使われる事はあるが、代替案があったりするとそちらに流れる傾向が強い。
PCの業界でも、たとえばCCIXは2016年にCCIX Consortiumが形成されたものの、「Base Specification 1.0」がリリースされるまでに2年を要した。2019年にはFPGAやAMDのEPYCプロセッサでサポートされたものの、現実問題としてCCIXを利用したアプリケーションはほとんどなし。強いて言えば2020年にリリースされたAmpere ComputingのAlter/Alter MAXが、2ソケット構成の場合のソケット間の接続にCCIXを使うという程度に留まっている。
それでもCCIXはまだコンソーシアムや規格が残ってるだけマシで、同じようなターゲットを目指した「Gen-Z Consortium」とか、IBMが中心になって開発されたOpenCAPIから派生した「OMI(Open Memory Interface)」や「OpenCAPI」そのものも、全てCXLに吸収合併されてしまい、既に規格が残っていない(CCIXも結構厳しいのだが、CCIXの「ホスト同士の接続」機能をCXLが提供していないので、辛うじて生きながらえているというのが正確なところだ)。
それでもPCの世界はまだいい方で、IoTの世界だと生き残ってる標準規格がほとんどないというか、さまざまな標準規格が全部廃れた後で、matterが出て来て「さてこれは生き残れるのでしょうか?」というのが現状だったりする。かくのごとく、標準規格というのは策定までに猛烈に手間暇とコストが掛かる割に、標準化されたからといって使って貰えるとは限らないという厄介なものである。
ではどうしたら成功率を上げられるか? つまり標準化を実現し、それを広範に使ってもらえるようになるか? という話であるが、筆者が見る限り一番手っ取り早いのは「独自で規格を作り、それを寄贈(contribute)して標準化プロセスに掛けること」である。
一番分かりやすい例がCXLで、Intel Accelerator Linkという名称で開発していた独自規格をContributeしてCXL Consortiumを立ち上げるとともに、以降の仕様拡張を民主的なスタイルで決めていくと宣言したことで、たちまちコヒーレントな周辺機器へのインターコネクトの座を奪い取ることに成功した。同じ例はPCIやPCI Express、USBなど多数存在する。
Ethernetの世界でも、IEEEの標準化の完了を待っていられないベンダーが独自にMSA(Multi-Source Agreement)を結成して独自規格を完成、ついでにそのMSAに準拠した形で製品出荷まで始めた上で、おもむろにその規格をIEEEに標準規格案として提案するというやり方が結構多い。
あるいはMSAではなく独自規格が標準規格化されたものとしては、BroadcomのBroadR-Reachがこれで、PAR(Project Application Request:標準化プロジェクト開始の提案)からわずか1年5カ月でIEEE 802.3bwとして標準化完了するという例のない迅速さを示している。
これに先立ちBroadR-Reachは自動車業界で車載Ethernetとして広く利用され始めており、これが今後は100BASE-T1として認知されていくというわけで、USBとかPCI/PCIeと同じように成功した標準規格になったわけだ。
またRISC-Vの話に戻るのは恐縮だが、米SiFiveは5月24日に、同社が開発したWorldGuardと呼ばれるRISC-V上のTEE(Trust Execution Environment)のモデルをRISC-V Internationalに寄贈したことを発表した。もう運営委員会を結成して、そこでTEEの実行モデルの共通化を訴えて民主的に作業を開始するよりも、ちゃんと動作するモデルを寄贈して、それを叩き台として以後の拡張などを民主化するという方が早い、と見切っての動きかと思われる。
なんというか民主化モデルの抜け道という感じではあるのだが、この業界(半導体業界というよりもコンピュータ業界全般)ではこうした抜け道を使うケースが非常に多い。
そもそも論で言えば、x64(x86の64bit拡張)を提案したAMD(x86-64)もこれにあたるし、IBM-PCのISAバスだって、それをどこかの団体に寄贈したわけではないのだが、バスプロトコルに著作権とかうるさいことを言わずに開放した(まぁプロトコルそのものは8086のデータバスそのものという話はあるので、その意味ではIntelが8086のバスプロトコルに妙な制限を付けなかった、と言い換えても良いのだろうが)ことで、広範に利用され標準のポジションを獲得したというあたり、こういう「根回し」が標準化規格として成功するためには重要、というのが実情と考えて良いかと思う。
もちろんこれを実現するためには、まず元になる規格を自力で策定し、ついでにインプリメントまで行なえるだけの技術力と資金力、エンジニアが必要である。その意味では弱小メーカーにはとても行なえる動き方ではない。RISC-Vでこうした動きをしているのが、抜群に資金力のあるSiFiveだけ、というのもうなずけるものがある。