ここコダシップでは、お客様のためにRISC-Vコアのコードサイズを小さくすることに情熱を注いでいます、 しかし、なぜでしょうか？状況を改善するために命令を追加することで、コアをより大きく、より複雑にしていないだろうか？つまり、プロセッサーに命令を追加すると、サイズ、複雑さ、消費電力が増大するため、それを正当化するメリットがなければならない。それでは、このブログでRISC-Vのコード・サイズを最適化する方法を見ていこう。
コード・サイズの縮小を検討すべき理由
まず、なぜそれを気にする必要があるのかを説明しよう。
理由1：トータルシステムでのコスト削減
小さな組み込みコアの場合、プロセッサの実際のサイズは、SoC（ブートROMを含む）や外部フラッシュメモリのサイズと比較すると、それほど重要ではありません。私たちが発見したのは、機能を追加するためにプロセッサーのサイズに例えば1～3％を加えることで、コードサイズを最大20％削減できるということだ。これは、ソフトウェアがより小さなROMと外部フラッシュ・メモリに収まることを意味し、プロセッサのサイズとパワーを適度に増加させながら、システムの総コストを大幅に削減する。
理由2：消費電力の削減とパフォーマンスの向上
プログラムのバイト数を減らすことで、コードのフェッチに必要なメモリ・フェッチの回数を減らすことができる。これにより、必要なレイテンシが短縮され、消費電力も削減される。さらに、キャッシュ・ミスが処理されるのを待つ時間や、キャッシュのないプロセッサでダイレクト・メモリ・アクセス（DMA）エンジンによってTCM（Tightly Coupled Memory）が満たされるのを待つ時間が減るため、性能も向上する。
なぜコードサイズを小さくするために努力しなければならないか、お分かりいただけたと思う。
Zc拡張の実装
コダシップが主導するRISC-V Zc拡張は、2023年第2四半期に承認された。もしチェックしたいのであれば、ここにリリースされた仕様へのリンクがある。そうでない場合は、これらが何であるかを簡単に説明しよう。
Zc 拡張とは？
私が代表を務めるRISC-Vコードサイズ削減タスクグループは、Zc拡張を考え出した。Zc拡張は、"C "と名付けられたRISC-V標準の圧縮命令セット拡張の一部であり、一般的な演算に16ビットの短い命令エンコーディングを追加することで、静的および動的なコードサイズを削減している。
私は最近、欧州でのRISC-Vサミットで、Zc拡張と辞書式圧縮のカスタム命令によるRISC-Vコード・サイズの削減に関する論文を発表した。ここでその概要を説明しよう。
作業開始の経緯
これにより、より多くのコードを命令メモリやキャッシュに収めることができるため、RISC-V C-extensionはコードサイズの削減や性能向上に非常に有効である。RISC-Vコアは、特にコストに敏感な小型デバイス（IoTデバイスなど）向けに、コードを格納するためにより多くのオンチップ・メモリ、またはオフチップ・フラッシュを必要とし、システム・コストを増加させる。より大規模なシステムでは、DDRまたはHBMのオフチップ・メモリが搭載されるでしょう。
コード・サイズ削減タスク・グループは、Zc拡張を定義することにより、この状況を改善するために2020年から活動している。
これらの拡張機能は、ハイエンドのアプリケーション・コアからマイクロコントローラまで、RISC-Vの実装範囲をカバーしています。
プロジェクトのスコープ
私が発表した論文では、提案したZc拡張の有効性を、一連のベンチマークを用いて評価し、C拡張とのコードサイズを比較した。
テストケースは、Opus [1]およびLP3 [2]オーディオコーデック、CoreMark [3]、Embench [4]、FPMark [5]、Debianベンチマークなどから抜粋した。コンパイラの依存性を排除するため、GCCとLLVMの両方を使用した。Zc命令の各グループと、辞書式圧縮のためのカスタム命令案を評価した。ベンチマークの詳細については、オンライン[6]を参照されたい。
発表された論文ではもっと多くのことが取り上げられているが、いくつかの最適化を見てみよう。近いうちにもっと長い形式の記事で紹介するかもしれない。ご期待ください！
RISC-V Zc 拡張： Zcb
Zcb 拡張機能はハイパフォーマンスの実装に適しており、RVA23 アプリケーション プロファイルに含まれており、実装コストをほぼゼロにして平均でほぼ 1% のコード サイズを節約する。エンベンチベンチマークの中には、この拡張によって5～6%の恩恵を受けるものもある。大規模なコードベースでは0.5％～2％が一般的だ。
現在、すべてのエンコーディングが予約されているため、アーキテクチャ・プロファイルと互換性がある。12のエンコーディングが含まれています。
命令はすべて、アーキテクチャ・プロファイルにある既存の命令の16ビット版であるため、コストは16ビット命令デコンプレッサー（実装されている場合）で12行追加されるか、16/32ビット命令デコーダーの組み合わせで12行追加され、既存のデコードにマッピングされるだけである。
命令は、符号/ゼロ拡張、乗算、バイトとハーフワードのロード/ストア、および機能性（-1とのXOR）ではないものに拡張される。
辞書式圧縮／命令テーブル
辞書式圧縮は、一般的なパターンをテーブルや辞書の短いインデックスに置き換える古い技法である[7]。これは圧縮アルゴリズムに使用され、少なくとも1990年代からコードサイズ削減のためにコンピュータアーキテクチャに適用されてきた。
このアイデアは、メモリ上にマイクロコードのテーブルを持ち、マイクロコードのエントリーを呼び出す16ビット命令を持つというものだ。最初のバージョンでは、各マイクロコード・シーケンスは単一の32ビット命令でなければならないという、機能のサブセットを提案している。
Zcmt/テーブルジャンプに非常によく似ているが、この最初のバージョンは、16ビットエンコーディングを任意の32ビット命令に展開することを可能にする（任意の32ビット関数アドレスに展開するのとは異なる）。PCとの複雑な関係を避けるため、表中の32ビット命令でPC相対命令のものは実行時に不正となる。
たとえば、これは Embench ベンチマーク picojpeg の関数の 1 つです。lui a5,0x0の32ビット・エンコーディングが2回使われていることがわかるが、これは他の関数でも繰り返されている。したがって、エンコーディング（000007b7）を命令テーブルにアロケートし、すべての使用方法を、テーブルからエンコーディングをフェッチする16ビット命令に置き換えることができる。これにより、この関数から4バイトを節約できる。
全体的な改善案は、CoreMarkで6%、FreeRTOSで7%のコード削減を実現した。
コードサイズ削減の結果
cはベンチマーク・スイート全体で平均約12.5％の節約になる。辞書式圧縮/命令テーブルのカスタム命令によって、さらなる節約が達成される。これらの改善を組み合わせることで、RISC-Vはレガシー・プロセッサ・アーキテクチャと競争力を持つことができる。
References
- [1] Opus audio codec
- [2] LC3 audio codec
- [3] CoreMark
- [4] Embench
- [5] FPMark
- [6] Benchmark results
- [7] C. Lefurgy, P. Bird, I.-C. Chen and T. Mudge, “Improving code density using compression techniques,” Proceedings of 30th Annual International Symposium on Microarchitecture, Research Triangle Park, NC, USA, 1997, pp. 194-203
