RISC-V 命令 / ISA 拡張ピックアップ ― 最近追加されたもの、これから追加されるもの、議論が進みつつあるもの

Copyright © 2023 Tsukasa OI. All Rights Reserved. 2023-03-16: RISC-V
勉強会@Online 1 RISC-V 命令/ISA 拡張ピックアップ最近追加されたものこれから追加されるもの議論が進みつつあるもの 2023-03-16 / RISC-V 勉強会@Online Tsukasa OI

勉強会@Online 2 自己紹介 (1) • 大居司 (Tsukasa OI) – Twitter: @a4lg • 2020-01 – 2023-01 : TRASIO / 研究員 (RISC-V を基盤としたセキュリティ技術開発を行う技術研究組合) • 2023-03 現在: 無職 (自宅療養予定) • TRASIO の活動の中で RISC-V に本格的に入れ込み、業務外で RISC-V 関連のオープンソースソフトウェア開発・拡張に参加 (ボランティア): 以下は影響の大きい例 • Linux kernel (5.18): 複数文字拡張 (Zba/Zbb 等) を Device Tree から抽出する機能検出、下記 QEMU バグ (7.0 以前) を踏みづらいパーサの作成 (当時 Western Digital [現 Rivos] の Atish Patra 氏との共同開発) • QEMU (7.1): 誤ったデフォルト Device Tree を生成するバグの修正 (misa CSR の S および U bit を S / U 拡張としてしまう問題) Linux kernel 5.17 以前 / FreeBSD との互換性オプションの追加

勉強会@Online 3 自己紹介 (2) • RISC-V の策定中 (段階は様々) の拡張を GNU Toolchain に取り込む・テストする contributor となる • 色々あって、現在 (2023-03-16) は GNU Binutils / GDB の Write after Approval Committer • (余談) GNU の Write after Approval Committer とは • 関連領域の、または全体 Maintainer の許可が下りた、または自明な修正コミットを任意のタイミングでリポジトリにコミットする権限を持つ • プロジェクト間での同期を取りやすくなるなどのメリットあり • 私の場合、GNU Binutils の修正が GDB sim を壊した痛い経験から取得を決意 (GDB sim 側パッチは送信していたがコミットの同期が取れなかった) • GDB の場合、2023-03-16 時点で私を含めて 267 人 • Maintainer の推薦と承認システムによってアカウントを得られる。 • 注意点として、「自明な」は相当狭義であり、例えば独断での修正コミットができるバグ修正は原因が typo だったんだろうレベルのものに限られる。

勉強会@Online 4 自己紹介 (3) • RISC-V ソフトウェアエコシステムに関する調整 • 厳密には “H” 拡張という名前が定まっていないハイパーバイザ拡張等を各 RISC-V ISA パーサーでどう扱わせるかの政治的折衝 • Zicbom / Zicboz 拡張のアセンブラ構文に関する三者調整 LLVM (兼アセンブラ構文変更の提案者) / GNU / 規格作成者の三者のうちどういうわけか私が GNU 側の代表みたいな立ち位置兼 (当時の GNU Binutils master ブランチの状況上) 議論を急かす立場に • GNU Binutils に策定中の拡張を実装して問題を探るだけでなく、そもそもの規格文面が潜在的にツールチェーン等に悪影響を与えないかなどの調査、修正活動を行う • 結果、RISC-V の策定中の拡張複数に深く関わることに • なんと、RISC-V CFI 仕様では主に校正を中心とした修正の結果 Contributor 欄に名を連ねることに • もう「RISC-V 規格に一番深く関わる日本人」を自称しても良いですか?

勉強会@Online 5 LT の流れ • 到底通常の LT 時間では追いつきそうにない or 発表の体力が持たないので…… • 後日公開のスライドには載せたい情報を全部入れる (「ピックアップしなかった版」含めた 2 部構成!) • トークでは何とかピックアップして幾つか紹介 • とりあえず、倒れる前に「今の RISC-V」の一端を色々と紹介できれば!

勉強会@Online 6 【注意事項】策定完了していない拡張について • 私が話すのが現時点で制限されていることがある • 明示しない限り公開情報のみに依存しているが、話せない話は幾つかあり、それは RISC-V メンバーシップ取得の上で特定タスクグループのメンバーになると垣間見ることができる • 内容が予期せず変わることがある • 時には、Frozen ステートに変わってから比較的大きな変更が加えられることも (例: RISC-V Profiles の拡張名変更) • だいたいは小さい互換性のある変更で済むんだけどなぁ…… (例: Zc* 拡張の freeze 後、拡張セットをまとめるための Zce 拡張を追加) • 仮に今年策定完了したとしても、エンドユーザーが使えるのは基本的には相当先になると思われる • 2025 年の時点で使えるようになっていればまだ早い方

勉強会@Online 7 RISC-V Profiles (1) • RISC-V には拡張が色々ある! • 特にアプリケーションプロセッサ上での開発者にとって、拡張の組み合わせが増えることは悪夢でしかない • フラグメンテーションの危機 • というわけで、ある時点でのスナップショットとして • サポートしなければならない拡張 (mandatory) • サポートしても良い拡張 (optional) • オプション: その他の推奨事項 (2022 年版以降では不採用) • ――をまとめたものを「プロファイル」として定め、開発者向けの分かりやすい目安とする仕様

勉強会@Online 8 • Frozen → 間もなく策定 (ratification) 予定 • RVI20U32 (汎用: アプリ開発者向け [最小セット≒超高互換性]) • RVI20U64 (汎用: アプリ開発者向け [最小セット≒超高互換性]) • RVA20U64 (高機能 CPU : アプリ開発者向け [高互換性]) • 今広く普及するアプリ向け RISC-V プロセッサはだいたいこの水準 • RVA20S64 (高機能 CPU : OS 開発者向け [高互換性]) • RVA22U64 (高機能 CPU : アプリケーション開発者向け) • RVA22S64 (高機能 CPU : OS 開発者向け) 64-bit (RV64) S-mode 用 (OS 開発者向け) 2022 年作成アプリケーションプロセッサ向け RVA22S64 命名例: RISC-V Profiles (2)

勉強会@Online 9 RISC-V Profiles (3) • 既存拡張をまとめるだけではなく、求められる挙動を新たに拡張として定めることも行われた (20 個弱) 1. Ssu64xl : sstatus.UXL に 2 (UXLEN=64) を代入、保持できる (i.e. U-mode で 64-bit コードの実行をサポート) • 64-bit OS では 64-bit ユーザーランドを実行したいのが普通だが、これを Profile 側から強制するために新しく拡張を作成 2. Sstvala : 例外発生時、規格が許す限り stval CSR に非 0 を設定 • stval CSR は例外発生原因の無効アドレス、無効命令本体などを保持するが、 Privileged ISA の基本ドキュメントでは代わりに 0 を設定して OS に処理を任せることも許可されている (この場合、OS 側が例外発生状況を確認し、エミュレーション処理を実装する必要が出てくる) • が、この拡張は “代わりの” 0 設定を許さない制約をかける (OS の負担減少) 3. Zic64b : キャッシュラインが丁度 64 バイトで naturally aligned • Zicbom / Zicboz 拡張の操作単位は「キャッシュライン」であるため、全体的に操作の見通しが上がり、移植性も見込みやすくなる • 特に Zicboz 拡張の CBO.ZERO 命令との組み合わせで、大きなサイズの memset(_, 0, _) をキャッシュライン単位 zero fill で一部賄うことが可能に

勉強会@Online 10 RISC-V Profiles (4) • 2023 年版 RISC-V Profiles の議論開始! • RVA23U64 (アプリケーション開発者向け) • RVA23S64 (OS 開発者向け) • 必須見込みの拡張たち一部 (V 以外は後述): • V (最低 128-bit 長、基本演算命令を全て備えたベクトル拡張) • Zcb (汎用の新圧縮命令) • Zawrs (LR/SC の予約領域に関連した wait 命令) • Zfa (汎用の追加浮動小数点取り扱い命令集) • Zjpm (Pointer Masking)

勉強会@Online 11 Zihintpause / Zawrs : ロック処理の負担軽減 • Zihintpause 拡張 (2021 年策定完了 / RVA22U64 必須) • PAUSE ヒント命令により、スピンロック等の実行時に低負荷・低優先度で回して欲しいことを宣言する • 特に SMT が実装された場合、このヒントは重要となるだろう • 極めて汎用性の高いヒント • Arm での YIELD 命令にほぼ相当 • Zawrs 拡張 (2022 年策定完了 / RVA23U64 必須予定) • マルチコアでの polling ループ (スピンロックの一種となるだろう) をさらに低負荷で回す 2 つの非ヒント命令を定義する • LR/SC 命令で触るメモリアドレス (reservation set = RS) に着目 • WRS.STO : RS が現在の Hart から見て有効なら短い時間待機 • WRS.NTO : RS が現在の Hart から見て有効なら実装依存の (長い) 時間待機 • 実装依存のタイムアウトにより OS が処理を他スレッドに回すこともできる • x86 の MONITOR / MWAIT と立ち位置が近い (同一ではない)

勉強会@Online 12 Zicbom / Zicbop / Zicboz / Zihintntl: キャッシュ操作 • Zicbom / Zicbop / Zicboz (2021 年策定完了) • 主にキャッシュライン単位での操作を行う (Zicbom / Zicboz) • CBO.CLEAN : キャッシュラインを消去 • CBO.FLUSH : キャッシュラインをフラッシュ • CBO.INVAL : キャッシュラインを無効化 • CBO.ZERO : キャッシュラインを zero fill (これのみ Zicboz 拡張) • 特定用途にプリフェッチを行うためのヒント命令 (Zicbop) • PREFETCH.R : データ読み取りのための prefetch • PREFETCH.W : データ書き込みのための prefetch • PREFETCH.I : コード実行のための prefetch • Zihintntl (Frozen → 策定見込み / RVA23U64 必須予定) • 続く load/store 命令を修飾する Non Temporal Locality ヒント (あまりキャッシュに残存しないことを示す) • レベルに応じて 4 種類のヒント (+ 圧縮命令版) を定義 • x86 では load に関して PREFETCHNTA という近い命令が存在 • ただし x86 のこれは prefetch で、Zihintntl の場合実 load 命令と組み合わせ

勉強会@Online 13 圧縮命令あれこれ • コードサイズを当初の C 拡張以上に縮小したい • 当初中国勢の色が強かったが、徐々に国際色豊かな開発に (ただし、ツールチェーン開発 [中国科学院チーム] 除く) • Zc* 拡張 (Frozen → 策定までの最終作業中) • Zca / Zcf / Zcd: 既存の C 拡張を便宜上 3 分割 • それぞれ I/F/D に対応 • Zcmp / Zcmt: CISC 的複合命令 (call / ret / jump 最適化) • Zcd (C 拡張の D 拡張関連部分) と同じ領域を使用 • 通常の C 拡張 + D 拡張とは (意図的に) 非互換 • Zcb: 汎用的な新圧縮命令集 • Zce: Zcmp, Zcmt を含むマイコン向け拡張集合 • Zca+Zcb+Zcmp+Zcmt または F+Zca+Zcb+Zcmp+Zcmt+Zcf

勉強会@Online 14 Zcmp: “超” 圧縮命令 (D 拡張と非互換; 純粋に組込用) 通常の圧縮命令よりさらに圧縮したいというニーズに応えた結果、例えば: cm.popretz {ra,s0-s11}, 112 # RV64_Zcmp: 0xbcf2 (2-bytes) が次の命令列 (16 命令)と同等になる……! ld s11, 104(sp) ld s10, 96(sp) ld s9, 88(sp) ld s8, 80(sp) ld s7, 72(sp) ld s6, 64(sp) ld s5, 56(sp) ld s4, 48(sp) ld s3, 40(sp) ld s2, 32(sp) ld s1, 16(sp) ld s0, 8(sp) ld ra, 0(sp) add a0, zero, zero # a0 := 0 addi sp, sp, 112 # sp += 112 jalr zero, ra, 0 # ret 特に、赤で示した前半部分は割り込みによる中断可 (その場合最初から) 意味的には単純にスタックからレジスタを復元して 0 を返す ――だけではあるが――

勉強会@Online 15 Zcb: 汎用的な新圧縮命令集 (RVA23U64 必須予定) • 汎用性と効果の点から注意深く選定された • Zcm* 拡張と異なり、C+D 拡張と互換 • バイト (1B) / ハーフワード (2B) 単位でのメモリ読み書き / ゼロ拡張 / 符号拡張命令 • メモリ読み書きに指定可能なオフセットはかなり狭い • 乗算 / NOT 演算 • NOT 演算は C 拡張に対応命令が無い XORI 命令の、特に必要とされるサブセットとして新規定義 • Profiles のひとつ、RVA23U64 では必須となる見込み • 今後、圧縮命令のスタンダードになっていきそう

勉強会@Online 16 CFI (Control Flow Integrity) とは (1) • CFI (Control Flow Integrity) • バッファオーバーフローに起因する任意コードの実行を防止するためのソフトウェア・ハードウェア面からの策 (広義) • ハードウェアが一部機能を肩代わりすることが期待されている 1. リターンアドレス書き換えの阻止 2. 間接分岐先 (ポインタ) 書き換えの阻止 (間接分岐先を特定命令に制限する Landing Pads が有力) • x86 では 1. Shadow Stack: 既存命令のモードによる拡張 + 管理命令各種 2. Indirect Branch Tracking: ENDBR32, ENDBR64 (タグ無し) • Arm (AArch64) では 1. Shadow Stack の代わりに Pointer Authentication (PAC) (ポインタを「認証付き暗号化」し、復号可能なら OK と判断) 2. Branch Target Identification: BTI 命令 (分岐命令種別認証付き)

勉強会@Online 17 CFI (Control Flow Integrity) とは (2) • RISC-V CFI 仕様では、Zisslpcfi 拡張として CFI に関連する 2 つの機能を提供する 1. Shadow Stack 2. Landing Pads • この仕様は Rivos (RISC-V CPU 設計が主らしいが具体的な活動が不明なステルス企業) の中の人が推進している • これを含む表に見える活動から察するに、Rivos が出そうとしているプロセッサの一つは超ハイエンドのアプリケーション向けプロセッサだと思われる • (余談) なんか私が Contributor 欄に入ってしまった • エンコーディング問題、明確に説明するべき部分の指摘、アセンブラ命令としてのオペランド順序の問題指摘などの校正を行っていたらいつの間にか

勉強会@Online 18 CFI の前に: ヒント命令では無理!? (1) • RISC-V の設計方針は全てが完璧だとは言えない • 途中修正を余儀なくされることも複数回あった • 4 モードのうちハイパーバイザ向けに予約してきた H-mode 利用の見直し • ハイパーバイザー拡張は S / U-mode を分割、拡張して実装された • I 拡張の “逆後方互換性” • I (version 2.2) → I / Zicsr / Zifencei の 3 拡張と Counters (非拡張) へ分割 (version 20190608) (Counters を非拡張のままにしてしまったのは手酷いミスだったとか) → I / Zicsr / Zifencei / Zicntr / Zihpm の 5 拡張へ分割予定 (次期 unprivileged ISA) • RISC-V は数多くの “実質 NOP” をヒント命令として予約してきた • ゼロレジスタに対する出力、あるいは実質意味のない算術演算など • 当然ヒント命令の CFI (Control Flow Integrity) への応用も期待されたが……

勉強会@Online 19 CFI の前に: ヒント命令では無理!? (2) • まさかの大問題に! • 一部 CFI 命令はトラップ (例外) を投げる必要がある (任意コード実行の前にプログラムを止めるため) • が、ヒント命令の当初の前提である「アーキテクチャ上の状態を (表面上は) 変更しない」 (i.e. ヒント命令は元の命令自体のセマンティクスを変更しない) に真正面からぶつかってしまうことになる • 激論の末、CFI に対してはヒント命令が使えないと結論 • ヒントではない “実質 NOP” の割り当て → Zimop 拡張 (“May Be Ops”) • デフォルト動作: rd ← 0 の新命令領域を定義 • 他の拡張によりこの動作を任意で変更可能になる予定 (当然トラップを投げることも許可) • Special Thanks: Dr. Andrew Waterman (現在未公開の、Zimop 拡張スケッチの提供と発表許可)

勉強会@Online 20 CFI の前に: Zimop (“May Be Ops”) の問題 • “May Be Ops” は新しい命令であるため、 CFI 命令などを使用するソフトウェアは CFI 無効の場合でも Zimop 拡張に対応している必要がある • 通常のヒントではないため、非対応プロセッサでは “May Be Ops” は未定義命令になってしまう • RISC-V Profiles 等における Zimop 拡張の早期義務化に期待

勉強会@Online 21 Zisslpcfi: Shadow Stack (1) • 通常のスタックの他に、通常命令では読み書きできない特殊なメモリ領域に戻りアドレス “専用” の Shadow Stack を確保し、適宜比較する • ISA 拡張的には “専用” ではないが、そのように扱うのが無難 • SSPUSH / SSPOP 命令で Shadow Stack の値管理 • SSCHKRA 命令で値を比較 (不一致ならトラップ) • その他管理系命令や CSR 等 • Shadow Stack と通常スタックの戻りアドレスが不一致ならトラップを発生させ、プログラムを止める • Arm とは異なり (x86 と同じく) 専用スタックを使用 (ポインタ認証のアーキテクチャ的な副作用を警戒?) • x86 と異なり Shadow Stack 操作や値の比較等は別命令で管理 (RISC-V が専用 call / ret 命令を持たないことが影響?)

勉強会@Online 22 Zisslpcfi: Shadow Stack (2-1) some_function: addi sp, sp, -32 sd ra, 24(sp) # Push return addr ... ... ... ld ra, 24(sp) # Pop return addr addi sp, sp, 32 jalr zero, 0(ra) この間にスタック上の ra が書き換えられていないことを保証したい

勉強会@Online 23 Zisslpcfi: Shadow Stack (2-2) some_function: sspush ra # Push RA to SS addi sp, sp, -32 sd ra, 24(sp) # Push return addr ... ... ... ld ra, 24(sp) # Pop return addr sspop t0 # Pop RA from SS sschkra t0, ra addi sp, sp, 32 jalr zero, 0(ra) この間にスタック上の ra が書き換えられていないことを保証したい Shadow Stack に保存しておいた値と比較。違っていればスタック上書きが発生している

勉強会@Online 24 Zisslpcfi: Landing Pads (1) • JALR 命令を拡張し、間接分岐の直後は 4-byte aligned な LPCLL (Landing Pads: Check Lower Label?) 命令しか実行できないようにする (異なればトラップ) • この点は Intel の IBT や Arm の BTI とそっくりだが…… • 典型的には間接分岐命令の直前に LPSLL 命令 (Landing Pads: Set Lower Label?) 命令等で分岐先の “ラベル” を指定する • 9-bit : LPSLL 命令 • 17-bit : LPSLL + LPSML 命令 • 25-bit : LPSLL + LPSML + LPSUL 命令 • 間接分岐先の LPCLL 命令は LPSLL 命令等で設定されたラベルの下位 9-bit が即値と一致するかチェック • 後続 LPCML / LPCUL 命令でさらに上位ビットをチェック可能 • 当然、即値と事前設定されたラベルが異なればトラップ

勉強会@Online 25 Zisslpcfi: Landing Pads (2) • RISC-V CFI 仕様の Landing Pads は、最低 9-bit 精度のタグによって、分岐元と分岐先が想定された組み合わせかどうかを判別することができる • x86 IBT : 想定する実行モード (32-bit / 64-bit) のみ (1-bit) • Arm BTI : 分岐元命令の種類のみ (2-bit) • これはセキュリティ上有用である程度柔軟である一方、特有のパフォーマンスペナルティを発生させるかも • ただ実際のハードウェア実装を見ないと何とも言えない • 圧縮命令 (C) 拡張との組み合わせで Landing Pads との組み合わせで問題のあるコードシーケンスが偶然生成される可能性も指摘されている • x86 IBT よりはマシだが、場合によってはツールチェーン側で何らかの対処を要求される可能性がある

勉強会@Online 26 Zisslpcfi: Landing Pads (3-1) # Indirect call auipc ra, 0x12345 jalr ra, 0x678(ra) ptr to some_function ポインタ上書きが発生すると任意コード実行の可能性 some_function: c.addi sp, -32 ...

勉強会@Online 27 Zisslpcfi: Landing Pads (3-2) # Indirect call lpsll 0x0ef auipc ra, 0x12345 jalr ra, 0x678(ra) ptr to some_function ポインタ上書きが発生すると任意コード実行の可能性 .align 2 # 4-byte align some_function: lpcll 0x0ef c.addi sp, -32 ... 事前にコール先のラベル指定先頭は 4-byte aligned な LPCLL 命令。同時にラベルを比較。

勉強会@Online 28 Zisslpcfi: Landing Pads (3-3) # Indirect call lpsll 0x0ef lpsml 0xdf auipc ra, 0x12345 jalr ra, 0x678(ra) ptr to some_function ポインタ上書きが発生すると任意コード実行の可能性 .align 2 # 4-byte align some_function: lpcll 0x0ef lpcml 0xdf c.addi sp, -32 ... 事前にコール先のラベル指定 (高精度 17-bit) 先頭は 4-byte aligned な LPCLL 命令。同時にラベルを比較。後続の LPCML もラベルを比較。

勉強会@Online 29 Zisslpcfi: Landing Pads (3-4) # Indirect call lpsll 0x0ef lpsml 0xdf lpsul 0x56 auipc ra, 0x12345 jalr ra, 0x678(ra) ptr to some_function ポインタ上書きが発生すると任意コード実行の可能性 .align 2 # 4-byte align some_function: lpcll 0x0ef lpcml 0xdf lpcul 0x56 c.addi sp, -32 ... 事前にコール先のラベル指定 (高精度 25-bit) 先頭は 4-byte aligned な LPCLL 命令。同時にラベルを比較。後続の LPC[MU]L もラベルを比較。

勉強会@Online 30 Zfa: 思わぬ動的言語への影響 (1) • Zfa: 一見すると、普通の雑多な浮動小数点演算拡張 (現在は Draft だが、RVA23U64 必須予定) 1. 32 種の定数のうちひとつをロードする 1 命令 2. IEEE 754-2019 標準に完全準拠した MIN / MAX 命令 3. NaN の取り扱いがやや異なる浮動小数点数の比較命令 4. 浮動小数点数を整数に丸め、浮動小数点数として受け取る操作 (一部数学ライブラリでは round 関数等の形で知られる) 5. RV32 + D / RV64 + Q 拡張前提、倍サイズ FPR の上位半分と GPR 間の移動命令 6. …………!? • 6 を見た瞬間抱腹絶倒してしまった

勉強会@Online 31 Zfa: 思わぬ動的言語への影響 (2) JavaScript において、Number の表現を FP64 → Int32 に変換する操作は結構複雑。 (ECMAScript 抽象操作: ToInt32 / ToUint32) V8 ソースコードより引用: src/numbers/conversions-inl.h // Implements most of https://tc39.github.io/ecma262/#sec-toint32. int32_t DoubleToInt32(double x) { if ((std::isfinite(x)) && (x <= INT_MAX) && (x >= INT_MIN)) { // All doubles within these limits are trivially convertable to an int. return static_cast<int32_t>(x); } base::Double d(x); int exponent = d.Exponent(); uint64_t bits; if (exponent < 0) { if (exponent <= -base::Double::kSignificandSize) return 0; bits = d.Significand() >> -exponent; } else { if (exponent > 31) return 0; // Masking to a 32-bit value ensures that the result of the // static_cast<int64_t> below is not the minimal int64_t value, // which would overflow on multiplication with d.Sign(). bits = (d.Significand() << exponent) & 0xFFFFFFFFul; } return static_cast<int32_t>(d.Sign() * static_cast<int64_t>(bits)); }

勉強会@Online 32 Zfa: 思わぬ動的言語への影響 (3) • ToInt32 / ToUint32 抽象操作の内容 • FP64 値が有限でない値 (無限 / NaN) なら 0 を返す • FP64 値をゼロ方向に丸める • 結果の整数値がオーバーフローする場合に 2^32 の剰余を取る (2 種の値域は 2 の補数表現が使えるなら共有) • 以上を行うために先の V8 のコードでは結構技巧と行数を消費していたが…… • Zfa 拡張の FCVTMOD.W.D 命令が全てを過去にした • 以上の操作を全て 1 命令で行う • どころか、これが JavaScript 向けであることが明言されている (そういう命令を入れてもいいのか……!) • エンコーディング的には丸めモード rtz [0 方向]でのみ定義される • 繰り返しだが、Profile RVA23U64 では必須拡張の予定

勉強会@Online 33 Zjpm: Pointer Masking (1) • Zjpm: 動的言語のため、データアクセスにアドレスにマスクをかける拡張 (Draft; RVA23U64 必須予定) • 注: 一度完全に設計が変わっているので参照資料に注意。 • v0.4 の場合: 実効アドレスの下位 n ビットまでにマスクし、データアクセス (実装はオプションだが命令等も) をそのマスクされたアドレス範囲に限定 • 通常データアクセスのみを限定し、命令等はその外に置くことで動的言語のアクセスできるアドレス範囲を効果的に制限 • あるいはポインタの一部をタグ目的に使うなどの応用も複数存在する • 動的言語以外だと HWASAN への応用も期待されている • v0.3 までの場合は BASE アドレスを指定可能で、同一アドレス空間内で複数のサンドボックスをホストしやすかったが、この設計は v0.4 で単純化され、下位 n ビットまでのマスクという単純な形となった。

勉強会@Online 34 Zjpm: Pointer Masking (1) • ただ、アドレスにマスクをかけるという概念が RISC-V にとって新しく、トラップやその他アドレスが関わる部分にどう反映させるかなど、議論すべき点は盛りだくさん • ――という訳で、策定まで結構時間がかかりそうに見える。

勉強会@Online 35 P (Packed SIMD) 拡張: 話せないというか…… • 元々 Andes 提供の主に DSP 用途を想定した拡張 • 飽和演算や、一般レジスタを使用した小規模 SIMD、レジスタペア (偶数 / 奇数) を用いたワイド幅演算などを実装 • 何度か大規模な変更 (少なくとも 2 度) を受けていて、 2023年3月の今まさにさらなる大規模変更の真っ最中 • 初期のエンコーディング (v0.6 時点) は酷いもので、これを RISC-V は受け入れるつもりなのかとショックだったのを記憶 • ある程度の大規模変更の後 (v0.9.2-) はエンコーディング的には整理され、既存拡張 (Bit Manipulation 系) との重複も削除され、拡張としての体裁も整ってきていたが、機能的な直交性の問題や、 RISC-V 的でない命令名の Andes 色などがある • ――そして今さらなる改修の真っ最中! • そのため、現在 GitHub にて公開されているマニュアルは最終版の学習の上では (機能の概略を知る以外) ほとんど何の参考にもならない (一部非公開議論)

勉強会@Online 36 ベクトル暗号拡張 (RVA23U64 では optional 予定) • スカラ暗号拡張が策定 (ratification) されてから、引き続きベクトル暗号拡張も議論が続けられてきた • 扱うことができるデータ幅の都合上、スカラ暗号拡張では十分効率的でない場合が存在することが明らか • x86 の場合、XMM レジスタ等を使った効率的な暗号拡張がすでに複数存在している • ベクトル暗号拡張では、プリミティブと思われる比較的小さなデータ型をグループ化したものを、ひとつの暗号関連操作の対象とする • EEW (ベクトル拡張の 1 要素の幅) * EGS (ベクトル暗号拡張の 1 操作に必要な要素数) ――を EGW (Element Group Size) とし、操作の 1 単位となる • この概念は次期 V 拡張周りでも議論が進んでいる • AES / SM4 (ブロック暗号) のようにベクトル並列化を効かせることに意味がある (場合がある) ものと、SHA-2 / SM3 (ハッシュ) のように、基本それに意味がないものの両方が存在することに注意。

勉強会@Online 37 Zvknha / Zvknhb: RISC-V 初かもしれない事態? (1) • Zvknha: SHA-256 (64 ラウンド) ベクトル暗号拡張 • Zvknhb: SHA-512 (80 ラウンド) ベクトル暗号拡張 • 専用アクセラレータと言えない範囲で最大限の抽象化を行っており、VSHA2MS.VV 命令が 4 ラウンド分のメッセージスケジュール、VSHA2CH.VV / VSHA2CL.VV がそれぞれ 2 ラウンド分 (2 命令 4 ラウンドが標準) の完全な SHA-2 圧縮計算を実施する • vsha2ms.vv : 最低 100 基本命令 (スカラ暗号拡張: 最低 20 命令?) • vsha2c{h,l}.vv : 最低 72 基本命令 (スカラ暗号拡張: 最低 36 命令?) • ――と、圧倒的な圧縮率と効率を手に入れることができる • ……のだが……この構成、どこかで見たことがあるぞ?

勉強会@Online 38 Zvknha / Zvknhb: RISC-V 初かもしれない事態? (2) • Intel SHA Extensions にそっくりだ! • ……しかも、同拡張の行う SHA-2 計算のコンピュータ命令としての抽象化方法が、Intel の特許になっている! • US20140185793A1 (対応する国際特許は米国および、中国、ドイツ、韓国にて成立) • 特許の対象となっている claim が抽象化方法 (SHA-2 にとって効率的なデータの並べ替え方含む) そのものであるため、特定 ISA に依存していない • そして、RISC-V の同拡張 Draft の命令設計がこの claim を見事に踏んでいるように見える • 命令の商用ハードウェア実装そのものに特許ライセンスが必要となる RISC-V としては初の事態になるかも? • 高性能実装に特許ライセンスが必要になること自体は珍しくはないが、こういう「命令そのもの」という形は RISC-V 初の可能性が高く、今後の各所の動きに注目。

勉強会@Online 39 その他ピックアップしなかったもの色々…… • ベクトル命令での FP16 対応 (FP32 との変換もしくはネイティブ演算) • Bfloat16 への部分対応 (FP32 との変換命令) • S-mode PMP などなどなどなど………… RISC-V はまだまだ進化中!

勉強会@Online 40 GNU Toolchain + RISC-V への関わり方について • 次以降 LT でできれば話したい話題ではあるんですが…… • どういうニーズがあるのかコメント頂けると助かります • カスタム RISC-V 命令 / カスタム CSR の追加方法? • アップストリームの開発者として活動にするにあたりのあれこれ? • ベンダー固有命令をアップストリームに入れる周りの議論?

勉強会@Online 41 Thanks! Any comments?

RISC-V 命令 / ISA 拡張ピックアップ ― 最近追加されたもの、これから追加されるも...

RISC-V 命令 / ISA 拡張ピックアップ ― 最近追加されたもの、これから追加されるもの、議論が進みつつあるもの

More Decks by a4lg

Other Decks in Programming

Featured

Transcript