2026年9月1日(火)掲載 3,963本日 0
HN214288

RISC-Vの設計思想に物申す:なぜ彼らはもっと上手くやれなかったのか?

RISC-V: They Should Have Known Better

dmitrygr17日前

議論

10
0dmitrygrスレ主21417日前

RISC-Vアーキテクチャの現状と将来について、設計上の判断が最適だったのかどうかという議論が再燃しています。本来、シンプルでクリーンな命令セットを目指していたはずが、なぜ現在の複雑化を招いてしまったのでしょうか。本稿では、RISC-Vが抱える設計のジレンマと、技術者が直面している現実について深く考察します。

1wren699117日前

RISC-Vは……まあ、いいんじゃないかな。趣味でCPUを設計している身からすると、ISA(命令セットアーキテクチャ)に必要な条件は以下の2点だけなんだ。1つ目は、メインラインのLLVMとGCCでサポートされていること。2つ目は、弁護士から「ラブレター」(警告書)を受け取ることなく実装できること。それ以外のことは、あとでどうとでもなる。拡張機能全体に良いアイデアがたくさん散らばっているから、それを集めて、シンプルに実装できる、競争力のあるパフォーマンスとコード密度を備えた、独自の組み込みISAをうまく作り上げることができるよ。Dmitryの指摘は概ね的を射ていると思う。ただ、RISC-VのJフォーマットのビットフィールド図を載せて愚痴るなら、ArmのT32 BLエンコーディングの図も併記すべきだという、いつもの文句を言わせてもらうよ。

2bjornnn17日前

RISC-Vの重要性と魅力、そして今中国が多額の投資をしている理由は、内部でどう動いているかという技術的な詳細とはほとんど関係がないんだ。重要なのは、知的財産権に縛られないオープンな標準だという事実だよ。たとえ技術的に最高の汎用プロセッサアーキテクチャではないとしても、多国籍企業からライセンス料を搾り取られたり、超大国から関税や制裁を課されたりすることなく、世界中がコンピューティングデバイスを構築できるオープンな公共アーキテクチャを開発可能だと証明した点で、極めて重要な前例を作ったと言える。

3Neywiny17日前

言いたいことはわかる。私もMicroBlaze-Vをしばらく使ってみたけど、割り込みハンドラを見てみてよ。https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/riscv/trap_handler.S コンパイル時にFPUを有効にすると、1回の割り込みで128回以上のメモリアクセスが発生するんだ。これはひどい。NVICもチェイニング機能もない環境では特にね。レイテンシは天文学的だし、最大割り込み周波数も悲惨なものだった。結局、Arm-Mのように動作させるためにソフトとハードの両面で苦労して調整する羽目になったけど、Arm-Mならそんな細工は不要だ。NVICは常にNVICであり、そしてNVICは優秀だからね。

4camel-cdr16日前

記事に対する私の反論は主に以下の通り。RISC-VはISAそのものではなく、ISA生成フレームワークであるということ。もしRISC-Vがaarch64を1対1で標準化していたとしても、結果は同じように拡張機能の混乱を招いていただろう。RVI(RISC-V International)のメンバーはそれぞれ異なる要求を持っていて、独自のサブセットを作るのが大好きだからだ。それらのサブセットは、複数のベンダーが同じものを必要とし、互換性を求めるために最終的にメインラインに取り込まれていくだろう。RVA23が最初から完成していたら確かにマシだっただろうけど、開発には時間がかかるし、RISC-V Internationalが発足したのは、すでに人々がRISC-Vを使い始めていたからだ。それにRISC-Vは、クレイジーな提案が次々と出てくる、最もDoS攻撃(過剰な提案)を受けているISAでもある。つい先日も、最大VLENにおいて1命令で2の30乗個の16bit比較を行う命令を提案した人がいたよ。文字列処理のユースケースを改善したかったかららしい。私の経験上、RVA23のuop数は(融合なしで)aarch64やx86に匹敵するし、コード密度は良く、命令数はわずかに多い程度だ。aarch64がRVA23に対して命令数で優位に立つ最大の要因は「load-pair」命令だけど、これはレジスタへの書き込みが2つあるため、高性能な実装ではデコード時に分解されてしまう。Armのコード密度に対するアプローチは、分解が必要な複数の書き込み命令を使うことで、RISC-VはRVCを使うことだ。どちらも単純な線形スケーリングの並列デコードを妨げるから、コード密度はArmにとってもトレードオフを受け入れる価値があるほど重要な問題なんだろうね。

5xiphias216日前

AMDがGPUのコントローラに採用してARMより安価になり、NVIDIAも多くの場所で使っているんだから、RISC-Vはベースとして構築する価値があるってことだよね。ARMやx86で仕様変更をライセンスしてJim Kellerの承認を得るよりずっといい。ISAの変更を何年も待つコストは、それにある問題を修正するコストよりもはるかに大きいってことさ。

7jack_h16日前

「安価なマイコンコアに何が必要か?用途を調べよう。典型的なのは、MP3プレイヤーやSDカード、USBメモリのような大きなチップ内のハードウェアブロックとインターフェースを取り、高速に再構成することだ。難しい作業はカスタムIPが行い、CPUコアはたまにレジスタを叩いたり設定したりするだけだ」。マイコンを使う理由はそれだけじゃないよ。もしそうなら、STMのようなベンダーの製品の75%には顧客がいないことになる。全員がすべての処理を行うカスタムIPを持っているわけじゃないし、それは実際かなり稀だ。割り込みレイテンシについて長々と愚痴を言うためだけにマイコンをこのように決めつけるのはおかしいし、それだけでRISC-Vが極めて多様なアプリケーション空間に適していないかのように語るのはどうかと思うね。記事の続きにはもっと良い議論があるのかもしれないけど、最初の論点で読み進める気が失せてしまったよ。

8random316日前

とはいえ、ロイヤリティフリーで、ESP32のメーカーであるEspressifが全面的にRISC-VのオープンソースISAに移行する[1]くらいには十分優秀だよ。「完璧なISA+ロイヤリティ」よりも「そこそこ優秀なISA+ライセンス料ゼロ」の方が、組み込みの世界では勝つんだ。それに、世界がフォン・ノイマン型アーキテクチャの上に築かれているのは、それが無料で利用可能だったからだということも忘れてはいけないね。 [1] - https://www.eenewseurope.com/en/espressif-moves-exclusively-to-risc-v/

9climate_denier_16日前

エッセイの最後の方で、著者はバークレーの連中がOpenRISCを検討していたことに触れている。それに大量の時間や金、R&Dを投入していたら、もっと良い結果になっていたのかな。それとも、ディレイスロット以外に、あの設計には本質的に悪いところがあったんだろうか?どれほど頭のいい人間でも、利用可能な土台があれば、それが崩れかけていたとしても素晴らしいものを築こうとするものだよね。NASAがRISC-Vを採用したり、誰かがC言語でセキュリティバイデザインなソフトウェアを書こうと決意したりするのを見るとそう思うよ。