彼らはもっと分かっていたはずだ — RISC-V 設計への辛辣な批判
彼らはもっと分かっていたはずだ — RISC-V 設計への辛辣な批判
オープンな標準という達成は、そのまま良い設計を保証するのか。それとも「誰でも作れる」という自由と「うまく作られている」という品質は、最初から別の軸だったのか。ロイヤリティのない命令セットという理想は、その理想が生んだ設計の欠陥までを免除してはくれない。
導入
RISC-V(リスクファイブ)は、ここ数年で半導体業界において最も頻繁に口にされる名前の一つである。ロイヤリティのないオープンな命令セットアーキテクチャ(ISA)という旗印のもと、スタートアップから国家主導のプロジェクトまで、それぞれが「次世代の標準」を自任して群がってきた。ところが、低レベルソフトウェアとハードウェアのリバースエンジニアリングで名を知られたエンジニア Dmitry Grinberg が、「RISC-V: They Should Have Known Better(彼らはもっと分かっていたはずだ)」という挑発的な題の長文批判を公開し、この楽観に真正面から水を差した。彼の論旨は意外にも単純である。RISC-V が失敗作だというのではなく、数十年分の先行事例 — ARM、x86、MIPS — が目の前に広がっていたにもかかわらず、十分に避けられたはずの失敗を繰り返したというのだ。Hacker News に載ったこの記事は 451 件のコメントを集め、RISC-V の支持者と懐疑論者が真っ向からぶつかる場となった。興味深いのは対立の性格である。一方は命令エンコーディングの細部まで踏み込んで「設計が怠慢だ」と言い、もう一方は「オープン性と採用の勢いが細部の瑕疵を圧倒する」と応じる。本稿はその批判の具体的な項目を、検証可能な仕様上の事実と著者の意見に分けて整理し、反論までを並べて置くことで、「オープンな標準」という達成がそのまま「良い設計」を意味するのかを問い直す。
何を批判しているのか:圧縮命令から割り込みまで
まず Grinberg が突いた具体的な設計判断を、事実の層で整理しよう。ここでいう「事実」とは RISC-V の仕様書に明記されたエンコーディングや拡張の構成そのものを指し、その上に載る数値や評価は、著者の分析と意見として別に区別する。
第一は割り込み処理である。RISC-V の基本整数コアには、割り込み進入時に自動でレジスタを退避してくれるハードウェアがなく、MIPS の $k0/$k1 のようにカーネルが自由に使えるよう予約されたレジスタもない。そのため割り込みハンドラは CSRRW 系の命令でレジスタを手作業で退避し、また復元しなければならない。著者はこの経路を実際に数え、Cortex-M0 が 27 サイクルで終える割り込みの進入/復帰を、RISC-V は最低 44 サイクルで行うと主張する(レジスタ保存に 21 サイクル、復元に 20 サイクル、そこに JAL/RET のオーバーヘッドが加わるという計算だ)。ここで「CSR を介した迂回が必要である」ことは仕様から確認できる事実であり、「27 対 44 サイクル」は彼が特定の条件で算出した測定値であるという点は分けておく必要がある。
第二は圧縮命令(C 拡張)のエンコーディングである。圧縮命令は命令を 16 ビットに縮めてコード密度を高める仕組みだが、著者から見ればその設計が拙い。圧縮されたバイトストア命令はオフセットを 0〜3 バイトしかサポートせず(ARM は同じ箇所で 0〜31 を使う)、ハーフワードストアは 0〜2 バイトにビット制約まで恣意的だ。しかも、いざ密度に効きそうな命令はオプションの Zcb 拡張へ追いやられており、「密度のための拡張」という名分が色あせてしまう。
第三は、存在しない命令と存在しないアドレッシングモードである。RISC-V の基本 ISA には、ビットを検査して分岐する test-bit-and-branch(ARM の TBZ/TBNZ)がなく、ビットフィールドの挿入・抽出も基本にはない。著者は aarch64 でビルドされた Linux カーネルのバイナリを分析し、TBZ/TBNZ が 35,393 回、ビットフィールド挿入が 6,284 回、ビットフィールド抽出が 8,881 回使われていたと集計した — つまり決して珍しい命令ではないというのだ。RISC-V で配列インデックスを助ける SHxADD(Zba 拡張)は、仕様が出てから 2 年も経ってようやく追加され、それすら ARM が 4 バイトで済ませる仕事を 6〜8 バイトの命令列で処理する。ここで「基本 ISA に当該命令がない」ことと「Zba が後から追加された」ことは検証可能な事実であり、カーネルバイナリの使用回数は著者が特定のバイナリで数えた値である。彼が「配列が存在すると気づくのに 2 年かかった」と皮肉った箇所は、明らかに彼の意見だ。
第四は即値(immediate)のエンコーディングである。RISC-V は命令の中に埋め込まれる定数のビットを順に並べず、ばらまいて配置する。たとえば J 形式の即値のビット順は 20・10・9・8・7・6・5・4・3・2・1・11・19・18・17・16・15・14・13・12 であり、圧縮分岐 C.J はまた別の入り乱れた順序を使う。命令形式(I/S/B)ごとに即値を取り出す位置がまちまちで、圧縮命令には 9 種類を超えるエンコーディング形式がある。仕様の公式な弁明は「同じビットを常に同じ位置から取り出せばハードウェアが単純になる」というものだが、著者はこれを「愚かだ(idiotic)」と一蹴する。ハードウェアのマルチプレクサにとってビット順とは単なる配線にすぎず、順序が入り乱れたところでゲートは増えない、というのだ。エンコーディング自体は事実であり、「愚かだ」という判定は彼の意見である。
なぜこうなったのか:オプション性、断片化、そして自らを検出できない標準
個々の瑕疵を超えて著者が本当に狙うのは、RISC-V の設計哲学、とりわけ「極端なオプション性」である。RISC-V では乗算・除算(M 拡張)、圧縮命令(C)、CSR アクセス(Zicsr)、さらにはユーザ/スーパーバイザモードまで、相当数がオプションだ。著者の中心命題はこうである — 「何かをオプションにするたびに、あなたは実装可能なものを互いに互換性のない二つの群に割ってしまう」。一つのカーネルを複数のコアで動かそうとするなら、どの機能があるかを知る必要があるのに、RISC-V ではそれを知ること自体が罠にはまる。
最も印象的な逆説は機能検出である。RISC-V でどの拡張が実装されているかを教えてくれるレジスタ MISA は、それ自体が CSR だ。つまり CSR があるかを知るには CSR を読まねばならないのに、CSR のサポート自体がオプションである。しかも MISA はマシンモードでしか見えず、スーパーバイザ・ユーザのコードからは見えず、実装がこのレジスタを丸ごと 0 として読ませても仕様違反ではない。x86 の CPUID や ARM の機能レジスタが当然のように解決する問題を、RISC-V は原理的に解けなくしてしまったわけである。加えて著者はエンコーディングの衝突も突く。同じ 16 ビット値 0xA002 が、D 拡張があれば C.FSDSP(浮動小数点ストア)を、Zcmp 拡張があれば CM.JT(ジャンプテーブル)を意味する。0xAC66 もまた拡張の組み合わせ次第でまったく別の命令になる。彼の表現では「プロセッサをアップグレードしたら、正しかったバイナリが意味の異なる正しいバイナリに変わる」ことが起きる。x86 はエンコーディングがどれほど汚くても、50 年間この意味的な安定性だけは守ってきた、というのが彼の対比点だ。
断片化を縫合しようと作った仕組みすら断片化を生む、という指摘もある。RISC-V 財団は特定用途に必要な拡張の組み合わせを束ねた「プロファイル」(RVA23 など)を導入したが、著者が数えてみると市場のボードの大半が RVA23 を満たさない。VisionFive 2、Banana Pi BPI-F3、Lichee Pi 4A、Orange Pi RV2、HiFive Premier P550 はいずれも非準拠であり、準拠例として挙げられたのは SpacemiT K3 程度だった。結局、市場は「ほぼ RVA23」と「RVA23 以降」に再び割れ、Android と Linux が非準拠ハードウェアを切り捨てる結末が来るという。彼は「断片化を解こうと作ったプロファイルが RISC-V の世界を断片化する」とまとめる。これらすべての失敗の根として、彼は「ここで作られていないもの(Not Invented Here)」症候群を名指しする。遅延スロットもなく既に存在していた OpenRISC を改良する代わりに白紙から作り直すという決定が、ばらまかれたビットエンコーディングと衝突する拡張と欠けた命令を生んだ、という論理だ。
もっとも反論も手強かった。HN の議論では、プロファイルこそ断片化の解だという擁護が出た — RVA23 のようなプロファイルが用途別の拡張の組み合わせを標準化するのだから、プロファイルを狙ったソフトウェアはどの機能があるかを正確に知る、というのだ。「検出する方法がない」という主張は誇張だという指摘もあった。Linux のデバイスツリーブロブと misa レジスタが、実際の配備シナリオでは拡張の発見を十分にこなす、という反駁である。散らばった即値のエンコーディングについても、それが怠慢ではなくカスタムベンダ拡張のためのエンコーディング空間を将来の衝突なく残しておくための意図的な選択だという説明が出て、ある参加者は実際に三つの位置から取り出されるビットはたった 1 個だけで、マルチプレクサの複雑さは扱える範囲だという統計を示した。x86 を理想化するなという声もあった — AVX-512 の断片化、SSE4.x 対 SSE4a の衝突、Intel と AMD の仮想化の非互換を挙げて、RISC-V の拡張モデルだけが際立って悪いわけではない、という均衡論である。コード密度の論争では、AArch64 が複雑な命令を複数のマイクロオペレーションへ「クラッキング」して密度を得る一方、RISC-V は可変長エンコーディングで得ており、両方ともフロントエンドのコストを払っているという整理が出た。ただし擁護論者すら「拡張の検出が x86 の CPUID ほど滑らかではない」点は、おおむね認める空気だった。
オープン性は品質ではない:展望と実務への示唆
この論争の底には一つの文がある。著者が繰り返し強調するように、オープンな仕様が良い実装を無償で生んでくれるわけではない。ARM の閉じた・独占的な設計が RISC-V を上回るのはライセンス料のためではなく設計判断がより優れているからであり、したがって「RISC-V の仕様がオープンである」という事実は性能とは無関係だ、というのだ。これはオープンソース文化が長く抱いてきた暗黙の等式 — オープンなものは優れている — を真正面から否定する。オープン性はアクセス性と統制権の軸であり、設計品質はそれとは別の軸だ、という冷静な切り分けである。
では RISC-V はどこで勝ち、どこで負けるのか。著者の展望は意外にも具体的だ。RISC-V は安価な使い捨てマイクロコントローラの市場 — 古い 8051 を押しのける場所 — を結局は制するだろう。ただし ISA が優れているからではなく、ISA にもかかわらず、ひとえに値が安いからである。また機械学習アクセラレータの制御部(演算ではなく DMA の設定といった裏方仕事)や、広いベクトル補助プロセッサのコントローラのように、整数パイプラインの効率が律速でない場所でもよく使われるだろう。逆にゲームやブラウジングのようなデスクトップ・SBC の対話型コンピューティングと高性能コンピューティングでは、マーケティングの掛け声とは裏腹に、アウトオブオーダーのコアにうまく合わず苦戦するという予測だ。彼の寸評はこう圧縮される — 「『十分に良い』はこの場合、低い基準であり、RISC-V はちょうどその基準に届く背丈だ」。改めて強調するが、この市場予測は検証された事実ではなく著者の判断であり、採用の勢いとエコシステムのロックインが設計の瑕疵をどこまで相殺するかは、開かれた問いである。
実務のエンジニアにとって、この論争は抽象的な趣味の争いではない。RISC-V を狙って移植性のある低レベルコードやカーネルを書こうとする者なら、「どの拡張があるかを実行時に安全に知り得るか」という問いが実際の制約として返ってくる。プロファイル(RVA23)をターゲットにすれば相当部分は解消されるが、市場のハードウェアがそのプロファイルを満たさない過渡期には、「ほぼ準拠」のボードのための例外処理がコードを蝕む。楽観シナリオはプロファイルが速やかに広がって事実上の共通基準線が立ち、コンパイラや配布版がその上で安定することだ。悲観シナリオはベンダごとのカスタム拡張が乱立し、「RISC-V 互換」という言葉が実質を失うことである。現実はその間のどこか — プロファイルが徐々に標準を締め上げつつ、低価格の組み込みでは依然としてまちまちなコアが共存する姿になる公算が大きい。要点は一つだ。RISC-V へ行くという決定は「一つの CPU」ではなく「拡張のスペクトラム」を相手にするという決定であり、そのスペクトラムのどの地点を支えるかをまず釘刺しておかねばならない。
結論
リードの問いに戻ろう。オープンな標準という達成は、そのまま良い設計を意味するのか。Grinberg の答えは断固たる「否」だ。そしてこの点で、彼の批判は単なる揚げ足取りを超える。オープン性は誰でも作れるようにする力であって、うまく作るよう強いる力ではない。ばらまかれた即値、自らを検出できない MISA、アップグレードがバイナリの意味を変えるエンコーディングの衝突 — これらはライセンスが自由だからといって消える問題ではない。むしろ自由に拡張できるからこそ、いっそう容易に割れる問題なのだ。
しかし著者の批判を認めることと、RISC-V を諦めることは別の話である。反論が思い出させるように、x86 も ARM もそれぞれの汚さを抱えたまま市場を支配してきたし、生きている標準はプロファイルと拡張によって事後に瑕疵を埋める余地がある — 既に固定された ISA がもはや直せない失敗を抱えて凝り固まっていくのとは対照的に。結局、残る問いはエンジニア各自のものだ。あなたが次のプロジェクトで RISC-V を選ぶなら、それは設計が優雅だからか、それとも値が安くロイヤリティがないからか。その二つの理由を自らに正直に区別することが、「オープンである」という言葉に設計品質までをこっそり上乗せしない第一歩である。
出典: