HN 日本語サマリー

← 一覧へ戻る
プログラミング

RISC-V:もっとよく知っておくべきだった

RISC-V: They Should Have Known Better (dmitry.gr)

355 pointsby dmitrygr396 コメント

要約

この記事は、RISC-VのISA(命令セットアーキテクチャ)設計に対する批判を展開しています。著者は、RISC-VがハイエンドCPUと低コストマイクロコントローラーのどちらのユースケースにも最適化されておらず、特にマイクロコントローラー分野ではCortex-M0のような競合製品よりも割り込み処理のオーバーヘッドが大きいと主張しています。また、圧縮命令セットの設計も、オフセット範囲が狭いなど、実用的でない点を指摘しています。

全文翻訳

Dmitry.GR/ Thoughts/ RV RISC-V:もっとよく知っておくべきだった 目次 すべての人に、すべてを オプション性 明らかな要素の欠如 馬鹿げたエンコーディング alleged Fixes どうしてこうなったのか、そしてこれからどこへ向かうのか? これはRISC-Vが破滅したことを意味するのか? コメント... 私はしばしば、RISC-Vに対する私の嫌悪感を説明するように求められ、断片的に説明することがよくあります。その反応はしばしば「君はそれに込められた素晴らしさを理解していないだけだ」という形をとりますが、それはもちろん、全く議論になりません。何度目かに説明を求められたので、次に尋ねられたときに単にリンクできるように、すべてを一つの場所にまとめることにしました。さらに、もし誰かが首尾一貫した反論を形成したいのであれば、このテキストを参照として、私のポイントを明確かつ詳細に参照できるでしょう。ここに述べられているすべての意見は私の個人的なものであり、私の雇用主、いかなる神、または私の大家の見解を表すものではありません。私の猫たちは一部賛成し、一部反対し、後で彼らの意見を発表するでしょう。すべての人に、すべてを RISC-Vは最終的に、非常に安価な使い捨てマイクロコントローラーの分野を制するでしょう。そのISA設計のおかげではなく、それにもかかわらずです。最初で最も理解しやすい問題は、すべてのユースケースに最適であることはできないということです。RISC-Vのファンは、RISC-Vがすぐにすべてのスーパーコンピューターを所有し、同時にすべての小さなマイクロコントローラーのユースケース、そしてその間のすべてのものを所有するようになると信じさせようとするでしょう。これは不可能であり、どのISAにとっても同様に不可能です。簡単に言えば、ハイエンドCPUが必要とするものは、小さなコスト削減マイクロコントローラーコアが必要とするものとは正反対です。設計上の選択は単なるマイクロアーキテクチャの問題ではなく、実際には(そして必然的に)CPUアーキテクチャ自体に影響を与えます。参考までに、RISC-Vが最終的に非常に安価な使い捨てマイクロコントローラーの分野を制すると100%確信しています。そのISA設計のおかげではなく、それにもかかわらずです。それは、8051を改善することによって、その役割を引き継ぐでしょう――そのバーは非常に低く、単なるスピードバンプに過ぎません。安価なマイクロコントローラーコアには何が必要でしょうか?それらが何に使われているかを調べてみましょう。典型的なユースケースは、MP3プレーヤー、SDカード、USBスティックなどのより大きなチップ内のハードウェアブロックとインターフェースし、迅速に再構成することです。ハードな作業はカスタムIPによって行われ、CPUコアはレジスタを一時的に操作したり、何かを設定したりするためだけに存在します。この場合、重要なのは割り込みレイテンシ(低いほど良い)とサイズ(小さいほど良い)です。通常、そのようなコアで多くの計算が行われることは期待できません。大量生産されるコスト削減デバイスでは、コードは実際のROM(更新不可の場合)またはRAM(更新可能の場合)から実行されます。NORフラッシュは高価すぎ、本当に大量生産されるものには選択肢がありません。ROMから実行する場合、ROMはそれほどコンパクトではないため、コードサイズが重要になります。SRAMもダイ上でかなりのスペースを占めるため、RAMから実行する場合もコードサイズが重要になります。したがって、これらのユースケースではコード密度が重要です。多くの計算は期待されないため、ハードウェア除算器(あるいは乗算器)などは削除できます。単一用途の状況では、特権分離も必要ありません――外部の信頼できないコードがフェッチされることは決して期待されません。「しかし」と言うかもしれません、「あなたはまさにRV32IC(またはRV32EC)を説明しただけだ!」と。したがって、そのような組み込みコアが持つほぼ唯一の目的に対して、RISC-Vは既存の主要な競合製品よりも著しく劣っています。実際、それはかなり近いですが、実際には割り込みを処理するためにRV32I_Zicsrが必要になります。Zicsrなしでは、レジスタを一時的に保存して残りを保存できるようにする場所がないため、割り込みを処理する仕様に準拠した方法がありません。MIPSはこれのために2つのケグ($k0と$k1)を予約しました。それらがないと、RISC-Vはmscratch/sscratchを必要とします。Zicsrがないと、それらを持たず、物事を処理するための奇妙な他の方法に立ち往生します。そして、私たちは再び8051の領域に戻ります――それは奇妙なことをすることに特化しています。小さな組み込みコアは、アウトオブオーダーモンスターではありません。それらから1サイクルあたり1つの命令を取得できれば、幸運だと考えるでしょう。これを考慮して、ABIで要求されるレジスタをスタッシュし、Cで書かれたハンドラーを呼び出すための割り込みハンドラーに必要なサイクル数を楽観的に数えてみましょう。まず、CSRRWを使用してレジスタ(説明のためにt0としましょう)をスタッシュし、残りをスタッシュできる場所の基本アドレスを取得します。次に、ra、sp、gp、tp、t1-t6、a0-a7をスタッシュする必要があります。その後、古いt0値を再度取得してスタッシュするために、別のCSSRWを使用する必要があります。これは少なくとも21サイクルです。出るときも、計算は似ています:スタッシュされたレジスタのアドレスを読み取るための1つのCSRRWと、それらをロードするための19回のロード。これは少なくとも20サイクルです。しかし、それだけではありません。これはアセンブリで行う必要があるため、CハンドラーへのJALとそこからのRETを実際に考慮する必要があります。それらがそれぞれ2サイクルであると寛大に仮定しましょう。したがって、Cハンドラーで作業が行われる前に、各割り込みには少なくとも44サイクルのコストがかかります。Cortex-M0(競合する安価な32ビットコア)は、割り込みエントリに15サイクル、終了に12サイクルかかります。ABIで破壊されるレジスタはハードウェアでプッシュされるため、ハンドラーは直接Cで書かれます。したがって、各割り込みのコストはわずか27サイクルです。うわー...それはずっと速いですね!RV32Eを考慮していないのは不公平だと抗議するかもしれません。レジスタの数が半分であるため、最初のプッシュを6サイクル速く、ポップも速く行うことができ、割り込みオーバーヘッドは38サイクルになります。それでもCortex-M0より3分の1以上多いです。うわー...したがって、そのような組み込みコアが持つほぼ唯一の目的に対して、RISC-Vは既存の主要な競合製品よりも著しく劣っています。CLICやさまざまな独自の「高速IRQ」/自動スタッキング拡張機能の存在は、さらなる非難です。ベースISAは、ベンダーに、10年前のCortex-M0に匹敵するために、標準外のシリコンを発明することを強制します。それは、さらに「標準」(もしそう呼べるなら)を断片化させます。おかしいことに、圧縮拡張機能を使用しても、典型的なIRQプロローグは、Cortex-M0のゼロバイトハードウェアパスよりも大きく、遅いです。さて、圧縮命令についてです。それらを詳細に見てみましょう。それらは、おかしくも設計が悪いです。レジスタとオフセットへのバイトの格納をしたいとしましょう。16ビット命令でエンコードできるオフセットの範囲はどれくらいですか?ゼロから3までです。33でも303でもありません。3です!まあ、半語を格納するのにはもっと良いかもしれませんか?いいえ...ゼロまたは2です。一体何?単語を格納する場合、ゼロから124バイトという妥当な範囲が得られますが、他のものについてはどうなっているのですか?さらに悪いことに、半語を格納するための命令は、バイトを格納するための命令と似たようにエンコードされていますが、オフセットのオプションはさらに少ないようです?なぜ?まあ、バイトを格納するためにオフセットを格納するために使用されるビットの1つはゼロにハードワイヤードされています...それは少なくとも6まで範囲を拡張するために使用できたはずですが、そうしません!比較すると、Cortex-M0は、バイトに対してゼロから31、半語に対してゼロから62、単語に対してゼロから124のオフセットを喜んで使用させます――明らかにこれはより多くのユースケースをカバーしています。それで何が起こったのでしょうか?本当に、私にはわかりませんが、正当化するのは確かに困難です。典型的な決まり文句は、これらのより大きなオフセットにはフルレングスの命令を使用することです。確かに、しかし密度は低下します――RISC-VファンがC拡張機能を誇示していたときに最近自慢していたまさにその密度です。しかし待ってください、まだあります。バイトと半語を格納するためのそれらの命令は、C拡張機能にさえ含まれていません。それらはZcbと呼ばれる別の拡張機能に含まれているため、たとえそれらのわずかな範囲があなたの状況で使用するのに十分であったとしても、あなたはそれらにアクセスできないかもしれません。後で「拡張機能」について説明します...サーバーコアには何が必要でしょうか?生の処理能力です。ここでは、シリコンが多かれ少なかれ無料であるアウトオブオーダーコアの世界にいます。コアのサイズがどれほど大きくても、キャッシュはそのサイズをはるかにしのぐからです。最新のアウトオブオーダーコアは、一度に8つ、時には10個の命令をデコードし、それらを複数のポートに並行して発行します。多くの最新コアは、同じサイクルで複数の分岐を処理できます(少し考えてみてください、それが心に響くように...はい)。コード密度は実際にはそれほど重要ではありません