RISC-V：彼らはもっと賢くあるべきだった
RISC-V: They Should Have Known Better
RISC-Vは安価な組み込みマイコン市場を支配すると予想されるが、そのISA設計は優れているからではない。割り込み処理のオーバーヘッドはCortex-M0より3分の1以上大きく、圧縮命令のオフセット範囲は貧弱で、配列アクセスに必要な命令が3つに分かれるなど、設計上の欠陥が目立つ。拡張規格の乱立は標準の断片化を招き、高性能コアには不向きだ。著者はRISC-Vの将来に懐疑的だが、安価なマイコン分野では成功するだろうと認めている。
RISC-Vは、安っぽい単一目的のマイクロコントローラ市場を最終的には支配するだろう。それはISA設計のおかげではなく、設計にもかかわらずだ。
HNでの議論
424- wren6991
RISC-Vは…まあ悪くない。趣味のCPU設計者として、私がISAに求める条件は2つだけだ。
1. メインラインのLLVMとGCCでサポートされていること。
2. 弁護士からラブレターが届かずに実装できること。
それ以外は、後で何とでもなる。拡張機能には良いアイデアが十分に散らばっていて、シンプルな実装で競争力のある性能とコード密度を持つ、ちゃんとまとまった組み込み向けISAを組み立てられる。
Dmitryの指摘は概ね的を射ていると思うが、いつものように文句を言わせてもらえば、RISC-VのJ形式のビットフィールド図を載せるなら、ArmのT32 BLエンコーディングの同様の図も併記すべきだ。
- camel-cdr
この記事への私の反論は、主に以下の通りだ。
RISC-VはISAではなく、ISA生成フレームワークである。
もしRISC-Vがaarch64を1対1で標準化していたとしても、結局は巨大な拡張の混乱になっていただろう。なぜなら、多くの人々（RVIメンバー）は異なる要件を持ち、自分たちのサブセットを構築することに非常に積極的で、複数のベンダーが同じサブセットと互換性を望むため、それがアップストリームに取り込まれるからだ。もちろん、RVA23が最初から完成した状態でRISC-Vが始まっていれば良かっただろうが、開発には時間がかかるし、RISC-V Internationalが始まったのは、人々がすでにRISC-Vを使っていたからだ。
RISC-Vはまた、最もDoS攻撃されやすいISAであり、人々がクレイジーな提案を行う。つい先日も、最大のVLENで1命令で最大2^30回の16ビット比較を行う命令を提案する人がいた。文字列処理のユースケースを改善したいからだ。
---
私の経験では、RVA23はaarch64やx86とuop数（融合なし）で同等であり、コード密度は良く、命令数はわずかに多い。aarch64がRVA23に対して命令数で優位に立つ最大の要因は、load-pairという単一の命令であり、これは高性能実装ではデコード時にクラックされる。なぜなら2つのレジスタに書き込むからだ。
Armのコード密度へのアプローチは、クラックしなければならない複数のライトバック命令を使用することで、RISC-VのアプローチはRVCである。どちらも並列デコードの単純な線形スケーリングを妨げるため、コード密度はArmにとって十分に重要だったようだ。
- jack_h
> 安価なマイコンコアには何が必要か？それらが何に使われるかを見てみよう。典型的なユースケースは、MP3プレーヤーやSDカード、USBメモリなど、より大きなチップ内のハードウェアブロックとインターフェースし、素早く再構成することだ。ハードな処理はカスタムIPが行い、CPUコアはたまにレジスタを叩いたり設定したりするだけだ。
これはマイコンを使う唯一の理由ではないし、そうであればマイコンベンダー（例：STM）の製品の75%は顧客がいなくなるだろう。誰もがすべての処理を行うカスタムIPを持っているわけではない。それは実際にはかなり稀だ。割り込みレイテンシについて長々と論じるために、マイコンをこのように分類するのは奇妙だ。まるでRISC-Vが非常に多様なアプリケーション空間に不適切であるかのように。おそらく記事の残りの部分にはもっと良い議論があるだろうが、最初の議論に感銘を受けなかったので、これ以上読む気にならない。
- xiphias2
RISC-VがAMDがGPUのコントローラに使うのに十分優れていて、ARMより安くなり、NVIDIAが多くの場所で使っているなら、ARM/x86のライセンス変更をJim Kellerに承認してもらうよりも、それを基盤にする方が良かった。
結局、ISAの変更を何年も待つコストは、どんな問題を修正するよりも大きいのだ。
- Neywiny
理解できた気がする。私はしばらくmicroblaze-vを試してきた。そして、彼らの割り込みハンドラを見てほしい。https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... 。コンパイル時にFPUを有効にすると、割り込みあたり128回以上のメモリ操作がある。NVICやチェーン、その他が無いことを考えると、これは非常識だ。私のレイテンシは天文学的で、最大割り込み周波数は悲惨だった。結局、arm-mのように動作させるために（ソフトウェアとハードウェアのオプションで）作業を行ったが、arm-mではその作業は不要だ。NVICは常にNVICであり、NVICは優れている。
- bjornnn
risc-vの重要性と魅力、そして中国が今それに多額の投資をしている理由は、内部の技術的な詳細とはほとんど関係なく、知的財産法に縛られないオープンな標準であるという事実だ。たとえ技術的に最高の汎用プロセッサアーキテクチャでなくても、ライセンス料を請求する多国籍企業や、関税や制裁を課す地政学的超大国に搾取されることなく、世界がコンピューティングデバイスを構築するために使えるオープンな公開アーキテクチャを開発することが可能であることを証明する、重要な前例となる。
- Retr0id
最近RV64IMAエミュレータを書いた。Linuxを起動できる仮想CPUコアが必要だっただけで、RV64IMAがそれを実現する最もシンプルな方法だと思った。それはほぼ正しいと思う。
しかしその後、既製のツールチェーンやバイナリと互換性を持たせたいと思い、ISAプロファイルをRV64GCに拡張する必要があることに気づいた。それほど大変ではなかったが、softfloatライブラリを取り込む必要があった。それでAlpine Linuxを起動できるようになった。
そしてUbuntuを起動できるようにしたいと思い、RVA23が必要になった。これは比較的大きな作業で、ベクトル命令セットなど多くのものが含まれた。この時点で、aarch64をエミュレートする方が良かったのではないかと思う。
- daishi55
私たちはAIアクセラレータにRISC-Vを使用して大きな成功を収めている。
https://ai.meta.com/blog/meta-mtia-scale-ai-chips-for-billio...
RISC-Vはカスタマイズ性と拡張性に優れているため、素晴らしい選択だった。
- camel-cdr
この記事への私の反論は、主に以下の通りだ。
RISC-VはISAではなく、ISA生成フレームワークである。
もしRISC-Vがaarch64を1対1で標準化していたとしても、結局は巨大な拡張の混乱になっていただろう。なぜなら、多くの人々（RVIメンバー）は異なる要件を持ち、自分たちのサブセットを構築することに非常に積極的で、複数のベンダーが同じサブセットと互換性を望むため、それがアップストリームに取り込まれるからだ。もちろん、RVA23が最初から完成した状態でRISC-Vが始まっていれば良かっただろうが、開発には時間がかかるし、RISC-V Internationalが始まったのは、人々がすでにRISC-Vを使っていたからだ。
RISC-Vはまた、最もDoS攻撃されやすいISAであり、人々がクレイジーな提案を行う。つい先日も、最大のVLENで1命令で最大2^30回の16ビット比較を行う命令を提案する人がいた。文字列処理のユースケースを改善したいからだ。
---
私の経験では、RVA23はaarch64やx86とuop数（融合なし）で同等であり、コード密度は良く、命令数はわずかに多い。aarch64がRVA23に対して命令数で優位に立つ最大の要因は、load-pairという単一の命令であり、これは高性能実装ではデコード時にクラックされる。なぜなら2つのレジスタに書き込むからだ。
Armのコード密度へのアプローチは、クラックしなければならない複数のライトバック命令を使用することで、RISC-VのアプローチはRVCである。どちらも並列デコードの単純な線形スケーリングを妨げるため、コード密度はArmにとって十分に重要だったようだ。
- kev009
基本的にMIPSの再来だ。
結論は正直だし、もちろんどんなISAでもどんな役割にも無理やり押し込むことはできる。以前はその理由でx86を嫌っていたが、年を取った今はそのゲームを尊重している。