コンピュータアーキテクチャとRISC-V

Unknown — Fri, 10 Apr 2026 00:00:00 +0000

コンピュータアーキテクチャとRISC-V CPUの構造について見ていきましょう。

本記事の内容は浦項工科大学校のCSED311の内容を基に、授業で扱われなかったいくつかの内容を追加して構成しました。 </blockquote>

アーキテクチャとは？</h1>

コンピュータアーキテクチャは、ハードウェアとソフトウェアの間のインターフェース規約です。具体的にはCPUが理解する命令セット（ISA、Instruction Set Architecture）を中心に、以下の内容を定義します。

命令（インストラクション）：どのような演算（加算、分岐、メモリアクセスなど）をサポートし、どのような形式で表現するか</li>
レジスタ：レジスタがいくつあり、それぞれ何ビットか、それぞれの用途は何か</li>
メモリモデル：アドレス空間のサイズ、バイト順序（エンディアン）</li>

例外/割り込み処理：エラーや外部イベントをどのように処理するか</li> </ul>

アーキテクチャは実際のハードウェア的な実装とは無関係に同一に維持される抽象層 です。コンパイラがこの規約だけを見て当該アーキテクチャに合うコードを生成すれば、そのアーキテクチャを実装したどのチップでも動作します。そのため、製造元が異なってもアーキテクチャが同じであればユーザーは同一のOSとアプリケーションを実行できます。（AMDと Intelのx86-64 CPUを想像できます）

一方、マイクロアーキテクチャはアーキテクチャという「約束」を実際のハードウェアで実現する内部設計です。パイプライン、アウトオブオーダー実行、分岐予測などの最適化や詳細な実装がマイクロアーキテクチャに該当します。

アーキテクチャの種類</h2>
コンピュータアーキテクチャの主な種類には、フォン・ノイマンアーキテクチャ、ハーバードアーキテクチャ、データフローアーキテクチャなどがあります。
フォン・ノイマンアーキテクチャ</h3>
フォン・ノイマンアーキテクチャはジョン・フォン・ノイマンが提案したコンピュータの基本構造で、今日ほぼすべての汎用コンピュータの基盤となっています。フォン・ノイマンアーキテクチャ以前のコンピュータ（ENIACなど）はプログラムを変更するには物理的に配線を変更する必要がありました。
当時ENIACを開発したモークリーとエッカートは後続コンピュータEDVACを設計しながら、プログラムとデータを同じメモリに格納する方法を構想します。こうすることで、プログラムをメモリにロードするだけで一つの配線で異なる作業を実行できるという利点があります。（その後フォン・ノイマンがこのアイデアをまとめた報告書を単独著者として配布したことで、この構造の名前がフォン・ノイマンアーキテクチャとなりました。）
フォン・ノイマンアーキテクチャはCPUがメモリから命令を取得し、解釈し、実行する過程を繰り返してプログラムを実行します。この時、命令とデータが同じメモリ、同じデータバスを共有するため、CPUがいくら高速であってもメモリ帯域幅によって性能が制限されるフォン・ノイマンボトルネック（Von Neumann Bottleneck）が発生します。この理由から、現代のCPUはフォン・ノイマンアーキテクチャを基盤としていますが、伝統的なフォン・ノイマンアーキテクチャの構造をそのまま使用せず、以下のハーバードアーキテクチャの構造と適切に組み合わせて使用しています。
ハーバードアーキテクチャ</h3>
ハーバードアーキテクチャはフォン・ノイマンアーキテクチャと同時期にハーバード大学のMark Iコンピュータに由来するアーキテクチャです。Mark Iは命令をパンチテープから、データを機械式カウンタから別々に読み取っていたため、フォン・ノイマンアーキテクチャとは異なり命令メモリとデータメモリを物理的に完全に分離した構造を持ちます。
ハーバードアーキテクチャは命令とデータのバスを区別して命令とデータを同時に読み取ることができるため、スループットが高いという利点があります。しかし二つのメモリ間の容量を柔軟に分割できず、プログラムを命令メモリに移す別のメカニズムが必要です。現代ではマイクロコントローラ（Arduinoに搭載されるAVRなど）や DSP（デジタル信号処理器）のような一部の分野でハーバードアーキテクチャが利用されています。
修正ハーバードアーキテクチャ</h3>
修正ハーバードアーキテクチャは現代のCPUの大部分が採用している、フォン・ノイマンアーキテクチャとハーバードアーキテクチャの間の折衷案です。L1キャッシュレベルでI-cacheとD-cacheを分離してハーバードアーキテクチャの高い帯域幅という利点を取り、それ以下のメモリは統合してフォン・ノイマンアーキテクチャの柔軟性を維持します。CPU側からはL1キャッシュのメモリが命令とデータに分離されているためハーバードアーキテクチャのように動作しますが、キャッシュを直接扱わないコンパイラやプログラマの観点からは一つのアドレス空間としてコンピュータを扱うことができます。
データフローアーキテクチャ</h3>
データフローアーキテクチャは上記のハーバードアーキテクチャやフォン・ノイマンアーキテクチャとは根本的に異なるアーキテクチャパラダイムです。フォン・ノイマン方式はプログラムカウンタが「次に実行する命令」を順次指定します。データフローアーキテクチャはこのフォン・ノイマン方式の順次的な演算実行という限界を脱却するために設計されたアーキテクチャで、プログラムカウンタがありません。データフローアーキテクチャではプログラムカウンタが順次的にどの命令を実行するか指定しなくても、必要なデータがすべて準備されると命令が即座に実行されます。プログラムの実行順序をプログラマやハードウェアが決めるのではなく、データ自体が実行フローを決定するのです。
データフローアーキテクチャではプログラムは順次的な命令リストではなく、有向グラフで表現されます。(a + b) * (c - d)</code>のような演算を実行する時、加算ノードと減算ノードは互いに依存関係がないため同時に実行されます。二つの演算の結果がどちらも乗算ノードに到着すると乗算演算が発火（fire）します。明示的にプログラマが並列演算を指定しなくても、自動的にすべての演算が並列的に実行されるのです。
1970年代に初めて登場したデータフローアーキテクチャは1980-1990年代に次世代コンピュータとして活発に研究されましたが、様々な限界により商用化には失敗しました。データフローアーキテクチャに必要な演算がハードウェア的に非常にコストが高かったこと、大規模データ構造を扱う際の困難さ、既存のすべてのソフトウェアインフラが順次実行モデルを前提として作成されているという複合的な問題のためでした。
純粋なデータフローコンピュータは現在は姿を消しましたが、アイデアは現代まで残り受け継がれています。フォン・ノイマンモデル内でのアウトオブオーダー実行（OoO）構造、FPGAでの回路設計などでデータフローアーキテクチャの設計思想が受け継がれており、最近ではAI アクセラレータプロセッサがデータフロー原理をハードウェアに再び適用しており、汎用コンピューティングマシンとしては商用化されませんでしたが、様々な特殊目的ハードウェアでデータフローアーキテクチャを利用しようとする研究が続いています。
ISA</h2> ISAはInstruction Set Architectureの略で、ソフトウェアとハードウェアの間のインターフェースと言えます。ISAは以下のような事項を決定します。 命令セットにどのような演算が存在するか、各命令のエンコーディング形式はどうか</li> ハードウェアが直接サポートするデータ型にはどのようなものがあるか、バイト順序はどうか（リトルエンディアン、ビッグエンディアン）</li> レジスタ構成とレジスタの数、ビット幅と用途</li> アドレッシングモード（Addressing Mode）と命令がオペランドの位置をどのように指定するか</li> メモリモデルのアドレス空間サイズ</li> どのような状況（ゼロ除算、ページフォールト、不正な命令）で例外が発生するか、割り込みはどのように処理されるか</li> 権限レベルと保護モード/カーネルモードの区分、各モードでアクセス可能なレジスタと命令の範囲、仮想メモリ関連部分</li> </ul> 一方、ISAの下に位置するマイクロアーキテクチャに関連する部分（クロック速度、パイプライン段数、キャッシュ構造など）とソフトウェア層の規約（ABI、メモリマップ、ファームウェアインターフェース）はISAが指定しません。 Programmer Visible StateはISAでプログラマ（コンパイラ）が命令を通じて直接読み書きできるすべてのハードウェア状態です。プログラムの意味（semantics）はこの状態の変化で定義されます。具体的には汎用レジスタ、プログラムカウンタ、スタックポインタ、フラグレジスタ、メモリアドレス空間全体などが該当します。 これとは反対に見えない状態（microarchitectural state）はキャッシュ内容、分岐予測器のヒストリ、リオーダーバッファ、リザベーションステーション、物理レジスタファイル、TLBエントリなどがあります。これらは性能にのみ影響を与え、プログラムの論理的な結果を変えることはありません。 同じISAを実装したどのチップでもProgrammer Visible Stateの変化が同一であれば正確な実装であり、その他の内部状態は自由に異なることができます。 ISAが提供する命令を機能別に分類すると以下のように分けることができます。 算術/論理演算（Arithmetic/Logical）：レジスタや即値に対して演算を実行します。結果は通常レジスタに格納され、副次的にフラグが更新されます。</li> データ移動（Data Transfer/Memory）：レジスタとメモリ間、またはレジスタ間でデータを移動します。</li> 制御フロー（Control Flow）：プログラムカウンタを変更して実行フローを変えます。無条件分岐（Jump）、条件分岐（Branch）、関数呼び出し/復帰などがあります。</li> システム命令（System/Privileged）：OSやハードウェアの制御のための命令です。ユーザーモードからカーネルへの移行、割り込み制御などがあります。現代のマイクロプロセッサではこのような命令の大部分はカーネルモードでのみ実行可能で、ユーザーモードで実行すると例外が発生します。</li> </ul> これらの命令は必ず**アトミックに（Atomicity）**実行されなければなりません。一つの命令はProgrammer Visible Stateを複数変更できますが、このような中間変更過程はプログラマに公開されてはなりません。実際のハードウェアではパイプラインでレジスタを先に書き込み、PCを後で更新するといった形で命令を段階的に処理することがありますが、これはMicroarchitectural Stateであり、Programmer Visible Stateではありません。 ISAの歴史</h2> EDSAC</h3> EDSACは最初のストアドプログラムコンピュータの一つで、非常に単純なISAを持っています。 命令は5ビットopcode + 予約ビット + 10ビットメモリアドレス（n）で構成され、単一アキュムレータ（Accumulator）構造です。レジスタはAcc一つだけで、すべての演算はこのAcc レジスタを中心に行われます。命令の例は以下の通りです。 A n：M[n]</code>をACC</code>に加算します</li> T n：ACC</code>の内容をM[n]</code>に移し、ACCをクリアします</li> E n：ACC>=0</code>ならば、M[n]</code>にジャンプします</li> I n：テープから次の文字を読み取り、M[n]</code>が指すアドレスに格納します。</li> Z ：プログラムを停止してベルを鳴らします。</li> </ul> すべてのメモリアドレスが命令にハードコーディングされている点が特徴です。しかしこれでは以下のような問題が発生します。 コードで関数を実行する場合、関数は呼び出し元に復帰しなければなりません。しかしEDSACは復帰アドレスが命令にハードコーディングされているため、同じ関数を複数箇所から呼び出す場合、復帰アドレスの指定が困難でした。</li> 配列要素にアクセスする際、配列のアドレスが命令にハードコーディングされているため、ループを回しながら配列にアクセスするには毎回命令自体を修正してアドレスを変更する必要がありました。</li> </ol> ISAの発展</h3> このような問題を解決するため、後代のCPUは様々な方式で進化してきました。 一つ目に、レジスタはアキュムレータレジスタ一つだけを使用する構造から、プログラムのアドレス指定のためのレジスタが追加され、現代では汎用レジスタ（GPR、General Purpose Register）が多数追加されてすべてのレジスタをどのような用途でも使用できるようになりました。 二つ目に、命令に様々なオペランドを指定できるようになりました。EDSACのように命令が暗黙的なオペランド（ACC）を持ち、明示的オペランドは一つだけの構造を Monadic、OP inout, in2</code>のようにオペランドが2つで入力の一つが結果で上書きされる構造をDyadic、OP out, in1, in2</code>のように出力と入力2つをすべて明示する構造をTriadicと呼びます。 後述するCISCアーキテクチャではADD [mem], reg</code>のように命令一つでメモリアクセスと演算を同時に実行できる一方、RISCアーキテクチャではメモリアクセスはload/storeのみで行います。（load-store architecture） 三つ目に、命令に様々なメモリアドレスを指定できるようになりました。 Absoulte - LD rt, 100</code>：EDSACと同様にアドレスが命令に定数として指定される方式です。</li> Register Indirect - LD rt, (r_base)</code>：レジスタに格納されている値をアドレスとして使用します。ポインタのデリファレンスがこの方式です。</li> Displaced - LD rt, offset(r_base)</code>：レジスタの値に定数オフセットを加えてアドレスを作ります。構造体アクセスに有用です。</li> Indexed - LD rt, (r_base, r_index)</code>：二つのレジスタの値を加えてアドレスを作ります。</li> Memory Indirect - LD rt, ((r_base))</code>：メモリアドレスから値を読み取り、その値を再びアドレスとして使用します。二重ポインタのデリファレンスに該当します。</li> Auto increment/decrement - LDR rt, (r_base)</code>：レジスタの値をアドレスとして使用しつつ、アクセス前後にレジスタの値を自動的に増加/減少させます。配列を順次走査する時に有用です。</li> </ul> RISCの登場</h3> 初期のCPUの発展は、単純だったISAを徐々に複雑にし、命令セットに様々な機能を追加する形で進められました。当時はアセンブリで直接プログラミングすることが一般的であり、多様な命令を追加することでプログラマのコーディングを簡便にすることができました。また、メモリのサイズや性能が限られていたため、頻繁に使用される複雑な演算を一度に処理することが有用でした。 しかし、その後コンパイラ技術が発展し、プログラマが直接複雑なアセンブリ命令を使用してプログラミングするケースはほとんどなくなりました。人が直接使用することを想定して作られた複雑な命令はコンパイラが最適化しにくく、命令ごとに実行時間やメモリアクセス回数が大きく異なるためパイプラインを効率的に設計することも困難でした。 このような背景でRISC（Reduced Instruction Set Computer）が登場します。すべての命令のサイズは同じ大きさで、メモリアクセスは必ず指定された命令で、各命令は単純にしつつレジスタを十分に提供するなど、命令セットを単純化するという思想で作られたRISC CPUは、複雑さをハードウェアからコンパイラに移し、ハードウェアを単純にする代わりに、最適化の負担は発展したコンパイラに委ねます。 RISCはパイプラインを容易に構築でき、クロックを上げるにも有利でした。ハードウェアが単純なのでトランジスタをキャッシュ、分岐予測器など性能に貢献する箇所に投資でき、検証とデバッグが容易で設計サイクルも短かったです。 RISCと対比して、RISC以前のアーキテクチャ（x86、M68K、Z80など）を CISC（Complex Instruction Set Computer）と呼びますが、 M68K、Z80など多くのCISCアーキテクチャは消滅しましたが、x86は巨大なソフトウェアエコシステムのため消滅せず、代わりに外部ISAはCISC、内部的にはRISCという折衷案を採用して、複雑な命令をCPU内部でRISCに分解して処理する設計を導入しました。 現代のRISCアーキテクチャの代表格としてはARMがありますが、ARMは初期に簡単な設計による高い電力効率（消費電力あたりの性能比）を武器に新しい分野であるモバイル市場に素早く参入し、2020年代以前まではRISCアーキテクチャはモバイル、組み込みなどの低消費電力設計で、CISCアーキテクチャは高消費電力を費やす代わりに高い性能を必要とするワークステーションやデスクトップ、サーバー環境で利用されてきました。 しかし2020年代以降、Apple SiliconでM1チップを発売したことでこの状況が大きく逆転しました。AppleのM1等のARM CPUはRISCアーキテクチャベースのCPUが高い性能とCISC CPUより改善された電力効率で急速に市場シェアを伸ばしており、Apple以外にもARM Windows/Linuxノートパソコンが販売されるなど、モバイル市場以外でもRISCアーキテクチャがシェアを少しずつ伸ばしています。 RISC-V</h1> RISC-Vは2010年にUC Berkeleyで始まったオープンソースISAです。1981年に設計された最初のRISCプロセッサであるRISC-I、RISC-IIに過去30年間の教訓を反映してレガシーなしにクリーンなRISC ISAをゼロから設計しました。（Vは Berkeleyで開発された5番目のRISC 設計という意味です。RISC-I、RISC-II、SOAR、SPUR、RISC-V） RISC-Vは特定企業に依存するARMやx86とは異なり、誰でも無料でRISC-V ISAを実装したプロセッサを製造でき、スタートアップ、大学、大企業すべてが自由にチップを設計できます。また、モジュール式設計を利用して一つの巨大なISAではなく、最小限の命令を持つ小さなISAに必要な拡張を付加する構造で開発されました。 RISC-VのProgrammer Visible State</h2> RISC-Vには基本的にx0からx31まで32個の整数汎用レジスタがあります。 x0は常に0に固定された状態ですが、これはx0を0に固定することで様々な動作を既存の命令で表現でき、命令の種類数を減らせるためです。（例えば、NOPをADDI x0, x0, 0</code>で、即値ロードをADDI x1, x0, 42</code>で表現できます。） また、汎用レジスタに含まれないPCレジスタと浮動小数点演算を提供するF/D 拡張に含まれる浮動小数点レジスタなどが存在します。 メモリはバイトアドレッシング方式で、基本的にリトルエンディアン方式です。メモリのすべてのバイトはProgrammer Visible Stateであり、基本的にリトルエンディアンアラインメントを使用します。 RISC-Vの拡張体系</h2> RISC-Vは小さな基本ISAに必要な拡張を組み合わせて使用する構造です。 基本となるISAは以下の通りです。 RV32I：32ビット整数基本。整数算術/論理、load/storeなど最小限の命令のみを持ちます。</li> RV64I：64ビット整数基本。RV32Iに64ビット演算とダブルワード命令が追加されます。</li> RV128I：128ビット整数基本。ただし64ビットより大きなアドレス空間がいつ必要になるかはまだ不明確なため、仕様が完全に確定（frozen）されていない状態です。</li> RV32E、RV64E：組み込み用縮小ISA。レジスタを32個から16個に削減して超小型マイクロコントローラのコストを下げます。</li> </ul> ここに以下のような標準Extensionが存在します。 M：整数乗算、除算：MUL</code>、MULH</code>などハードウェア乗算器のネイティブ整数乗算演算命令を追加します。超小型組み込み機器ではハードウェア乗算なしに乗算と除算をビット演算など他の演算で代替できるため、乗算と除算が別の拡張として分離されています。</li> A：アトミック演算：マルチコア環境でコア間メモリ共有のための命令です。メモリへの書き込みや読み取りをアトミックに実行したり、メモリを予約する機能などが定義されています。</li> F：32ビット浮動小数点演算：FPUによるハードウェア浮動小数点演算を追加します。32個の浮動小数点レジスタf0-f31と浮動小数点演算の結果を記録するフラグであるfcsrが追加されます。</li> D、Q：それぞれ64ビット倍精度浮動小数点演算と128ビット4倍精度浮動小数点演算命令を追加します。</li> C：よく使う命令を16ビットでエンコードできるようにします。コードサイズを削減できるため、フラッシュメモリのサイズが大きく制限される組み込み環境で使用できます。</li> V：ベクトル拡張。SIMDと類似した様々なベクトル演算をサポートします。</li> H：ハイパーバイザー拡張。ハイパーバイザーがサポートする仮想化層をサポートします。</li> </ul> これ以外に単一アルファベットの代わりに、拡張名の前にZを付けた細分化された拡張もあります。 Zicsr：CSRアクセス命令</li> Zifencei：命令キャッシュ同期、自己修正コード、JITコンパイル時のI-Cacheと D-Cacheの一貫性保証</li> Zba、Zbb、Zbc、Zbs：アドレス計算高速化、基本ビット演算、キャリーレス乗算などの詳細ビット操作命令</li> Zfinx：浮動小数点演算を整数レジスタで実行</li> Ztso：Total Store Orderingメモリモデル保証。x86バイナリ変換時に有用</li> Zicond：条件付き演算。分岐なしに条件付きで値を選択</li> </ul> 非常に多様な拡張が存在するため、ソフトウェア互換性のためによく使用される拡張をまとめて定義するRISC-Vプロファイルが存在します。例えばRVA20U64はI、M、A、F、D、C、Zicsr、Zifencei拡張を必須として持つように定義されています。 RISC-V命令フォーマット</h2> RISC-Vは6種類の基本命令フォーマットを定義します。RV32Iですべて32ビット固定長であり、opcode、rd、rs1、rs2の位置がフォーマット間で最大限一貫して配置され、デコーディングを単純にします。 R-Type</h3> レジスタ間演算に使用されます。 [31:25] [24:20] [19:15] [14:12] [11:7] [6:0] funct7 rs2 rs1 funct3 rd opcode 7ビット 5ビット 5ビット 3ビット 5ビット 7ビット</code></pre> rs1、rs2の二つのソースレジスタで演算し、結果をrdに格納します。funct7</code>と funct3</code>が具体的な演算の種類を区別します。 例：ADD x1, x2, x3</code>：x1 <- x2 + x3 I-Type</h3> 即値演算、load、JALRなどに使用されます。 [31:20] [19:15] [14:12] [11:7] [6:0] imm[11:0] rs1 funct3 rd opcode 12ビット 5ビット 3ビット 5ビット 7ビット</code></pre> 12ビット即値が符号拡張（sign-extend）されて使用されます。R-typeからfunct7</code>と rs2</code>の位置が即値に置き換わった形式です。 例：ADDI x1, x2, 10</code>：x1 <- x2 + 10 R-typeからfunct7</code>がなくなったため、若干の命令の違いが存在します。例えば R-typeでfunct7</code>で区別されるADD/SUBの場合、I-typeでは負の即値を使えばよいので命令自体が不要となり省かれています。また、Immediate fieldを分割して細分命令を区別するケースもあります。（RV32I基準で即値が最大5ビットまでしか必要ないSLLI、SRLI、SRAIなどのシフト命令は、先頭7ビットを命令指定子として、残り5ビットをシフト即値として使用します。） メモリから値を取得するLoad命令もI-Typeですが、opcode</code>の位置にLoadを意味する0000011</code>を入れ、rs1</code>をベースに、12ビットimm</code>はオフセットとして使用します。funct3</code>に応じて32ビットを読むLW</code>、16ビットを読んで符号拡張するLH</code>、 16ビットを読んでゼロ拡張するLHU</code>、8ビットを読むLB</code>、LBU</code>などが区別されます。 また、即値は常に12ビットに制限されます。プログラムで使用する即値は通常小さな値であり、大きな定数が必要なケースは通常まれであるため、最適化のための意図的な設計です。どうしても大きな定数が必要な場合は後述するU-type命令やAUIPCなどを使用して値を生成します。これは一つの命令ですべてを行おうとせず、簡単な複数の命令の組み合わせで解決しようというRISCの思想に従ったものです。 S-Type</h3> メモリに値を格納するのに使用されます。 [31:25] [24:20] [19:15] [14:12] [11:7] [6:0] imm[11:5] rs2 rs1 funct3 imm[4:0] opcode 7ビット 5ビット 5ビット 3ビット 5ビット 7ビット</code></pre> 結果をレジスタに書き込まないためrd</code>がなく、代わりにrd</code>の位置に即値の下位ビットを、funct7</code>の位置に即値の上位ビットを入れます。 例：SW x3, 12(x2)</code>：MEM[x2 + 12]</code> <- x3 B-Type（SB-Type）</h3> 条件分岐に使用されます。 [31] [30:25] [24:20] [19:15] [14:12] [11:8] [7] [6:0] imm[12] imm[10:5] rs2 rs1 funct3 imm[4:1] imm[11] opcode 1ビット 6ビット 5ビット 5ビット 3ビット 4ビット 1ビット 7ビット</code></pre> S-Typeと類似していますが、即値のビット配置が異なります。即値が分岐オフセットとして使用され、RISC-V命令は最小16ビット単位でアラインされるため、分岐オフセットの最下位ビットは常に0であるためエンコードしません。したがって13ビット範囲の分岐が可能です。 例：BEQ x1, x2, offset</code>：x1 == x2</code>ならPC <- PC + offset ビット配置が独特にねじれている理由は、S-typeと最大限多くのビット位置を共有してハードウェアを単純化するためです。このようなS-Typeとの類似性からB-Typeを SB-Typeと呼ぶこともあります。 U-Type</h3> 上位20ビット即値を使用する命令です。 [31:12] [11:7] [6:0] imm[31:12] rd opcode 20ビット 5ビット 7ビット</code></pre> 20ビット即値が上位20ビットに配置され、下位12ビットは0で埋められます。I-Type 命令で最大12ビットまでの即値を使用できるため、これを補完するために作られた命令です。 LUI（Load Upper Immediate）：rd <- imm << 12、大きな定数を作る時にADDIと組み合わせて使用します。0x12345678</code>を作る時、LUI x1, 0x12345</code>で上位20ビットを埋め、ADDI x1, x1, 0x678</code>で下位12ビットを埋めます。</li> AUIPC（Add Upper Immediate to PC）：rd <- PC + (imm << 12)、PC相対アドレス計算に使用され、JALとloadと組み合わせて現在位置から±2GB範囲のアドレスを作ることができます。</li> </ul> J-Type（UJ-Type）</h3> 無条件ジャンプに使用されます。 [31] [30:21] [20] [19:12] [11:7] [6:0] imm[20] imm[10:1] imm[11] imm[19:12] rd opcode 1ビット 10ビット 1ビット 8ビット 5ビット 7ビット</code></pre> 20ビット即値をジャンプオフセットとして使用し、B-Typeと同様にbit0は常に0であるためエンコードしません。したがって21ビット範囲（±1MB）のジャンプが可能です。 B-Typeと類似して、U-Typeとビット位置を最大限共有するように設計されています。そのためUJ-Typeと呼ばれることもあります。 RV32I命令セット</h2> 整数算術/論理（R-type）</h3> 命令</th> 動作</th> 説明</th></tr></thead> ADD rd, rs1, rs2</code></td> rd ← rs1 + rs2</code></td> 加算</td></tr> SUB rd, rs1, rs2</code></td> rd ← rs1 - rs2</code></td> 減算</td></tr> AND rd, rs1, rs2</code></td> rd ← rs1 & rs2</code></td> ビットAND</td></tr> OR rd, rs1, rs2</code></td> rd ← rs1 | rs2</code></td> ビットOR</td></tr> XOR rd, rs1, rs2</code></td> rd ← rs1 ^ rs2</code></td> ビットXOR</td></tr> SLL rd, rs1, rs2</code></td> rd ← rs1 << rs2[4:0]</code></td> 論理左シフト</td></tr> SRL rd, rs1, rs2</code></td> rd ← rs1 >> rs2[4:0]</code></td> 論理右シフト（0埋め）</td></tr> SRA rd, rs1, rs2</code></td> rd ← rs1 >>> rs2[4:0]</code></td> 算術右シフト（符号維持）</td></tr> SLT rd, rs1, rs2</code></td> rd ← (rs1 < rs2) ? 1 : 0</code></td> 符号あり比較</td></tr> SLTU rd, rs1, rs2</code></td> rd ← (rs1 < rs2) ? 1 : 0</code></td> 符号なし比較</td></tr> </tbody></table> 即値算術/論理（I-type）</h3> 命令</th> 動作</th> 説明</th></tr></thead> ADDI rd, rs1, imm</code></td> rd ← rs1 + sext(imm)</code></td> 即値加算</td></tr> ANDI rd, rs1, imm</code></td> rd ← rs1 & sext(imm)</code></td> 即値AND</td></tr> ORI rd, rs1, imm</code></td> rd ← rs1 | sext(imm)</code></td> 即値OR</td></tr> XORI rd, rs1, imm</code></td> rd ← rs1 ^ sext(imm)</code></td> 即値XOR</td></tr> SLLI rd, rs1, shamt</code></td> rd ← rs1 << shamt</code></td> 即値論理左シフト</td></tr> SRLI rd, rs1, shamt</code></td> rd ← rs1 >> shamt</code></td> 即値論理右シフト</td></tr> SRAI rd, rs1, shamt</code></td> rd ← rs1 >>> shamt</code></td> 即値算術右シフト</td></tr> SLTI rd, rs1, imm</code></td> rd ← (rs1 < sext(imm)) ? 1 : 0</code></td> 即値符号あり比較</td></tr> SLTIU rd, rs1, imm</code></td> rd ← (rs1 < sext(imm)) ? 1 : 0</code></td> 即値符号なし比較</td></tr> </tbody></table> 上位即値（U-type）</h3> 命令</th> 動作</th> 説明</th></tr></thead> LUI rd, imm</code></td> rd ← imm << 12</code></td> 上位20ビットロード</td></tr> AUIPC rd, imm</code></td> rd ← PC + (imm << 12)</code></td> PC基準上位20ビット加算</td></tr> </tbody></table> Load（I-type）</h3> 命令</th> funct3</th> 動作</th> 説明</th></tr></thead> LB rd, imm(rs1)</code></td> 000</code></td> rd ← sext(MEM8[rs1 + sext(imm)])</code></td> バイトロード（符号拡張）</td></tr> LH rd, imm(rs1)</code></td> 001</code></td> rd ← sext(MEM16[rs1 + sext(imm)])</code></td> ハーフワードロード（符号拡張）</td></tr> LW rd, imm(rs1)</code></td> 010</code></td> rd ← MEM32[rs1 + sext(imm)]</code></td> ワードロード</td></tr> LBU rd, imm(rs1)</code></td> 100</code></td> rd ← zext(MEM8[rs1 + sext(imm)])</code></td> バイトロード（ゼロ拡張）</td></tr> LHU rd, imm(rs1)</code></td> 101</code></td> rd ← zext(MEM16[rs1 + sext(imm)])</code></td> ハーフワードロード（ゼロ拡張）</td></tr> </tbody></table> Store（S-type）</h3> 命令</th> funct3</th> 動作</th> 説明</th></tr></thead> SB rs2, imm(rs1)</code></td> 000</code></td> MEM8[rs1 + sext(imm)] ← rs2[7:0]</code></td> バイト格納</td></tr> SH rs2, imm(rs1)</code></td> 001</code></td> MEM16[rs1 + sext(imm)] ← rs2[15:0]</code></td> ハーフワード格納</td></tr> SW rs2, imm(rs1)</code></td> 010</code></td> MEM32[rs1 + sext(imm)] ← rs2</code></td> ワード格納</td></tr> </tbody></table> 条件分岐（B-type）</h3> 命令</th> funct3</th> 動作</th> 説明</th></tr></thead> BEQ rs1, rs2, offset</code></td> 000</code></td> if (rs1 == rs2) PC ← PC + offset</code></td> 等しければ分岐</td></tr> BNE rs1, rs2, offset</code></td> 001</code></td> if (rs1 != rs2) PC ← PC + offset</code></td> 異なれば分岐</td></tr> BLT rs1, rs2, offset</code></td> 100</code></td> if (rs1 < rs2) PC ← PC + offset</code></td> 符号あり未満</td></tr> BGE rs1, rs2, offset</code></td> 101</code></td> if (rs1 >= rs2) PC ← PC + offset</code></td> 符号あり以上</td></tr> BLTU rs1, rs2, offset</code></td> 110</code></td> if (rs1 < rs2) PC ← PC + offset</code></td> 符号なし未満</td></tr> BGEU rs1, rs2, offset</code></td> 111</code></td> if (rs1 >= rs2) PC ← PC + offset</code></td> 符号なし以上</td></tr> </tbody></table> ジャンプ</h3> 命令</th> タイプ</th> 動作</th> 説明</th></tr></thead> JAL rd, offset</code></td> J-type</td> rd ← PC+4, PC ← PC + offset</code></td> 直接ジャンプ（関数呼び出し）</td></tr> JALR rd, rs1, imm</code></td> I-type</td> rd ← PC+4, PC ← (rs1 + sext(imm)) & ~1</code></td> 間接ジャンプ（関数復帰等）</td></tr> </tbody></table> メモリ順序</h3> 命令</th> 説明</th></tr></thead> FENCE pred, succ</code></td> メモリアクセス順序保証（pred/succ：I、O、R、Wの組み合わせ）</td></tr> </tbody></table> システム命令</h3> 命令</th> 動作</th> 説明</th></tr></thead> ECALL</code></td> 環境呼び出しトラップ発生</td> システムコール（OS移行）</td></tr> EBREAK</code></td> デバッグトラップ発生</td> ブレークポイント</td></tr> </tbody></table> 以前はZicsr</code>、Zifencei</code>拡張がRV32Iに含まれていましたが、2.1で別の拡張として分離されたため、現在は合計40個の命令がRV32Iを構成しています。 RISC-V ABIコンベンション</h2> レジスタコンベンション</h3> ISAレベルでは強制されませんが、すべてのシステムで推奨されるレジスタの使用コンベンションです。x0 = 0</code>だけが唯一ISAで強制されるものであり、それ以外はハードウェアの観点では同等です。実際にこのようなコンベンションを遵守するのはABI、Calling Conventionの役割です。 しかし、ほとんどのコンパイラ、OS、デバッガがこのようなコンベンションを遵守しているため、特殊なベアメタル組み込みで外部ライブラリすら使用しない非常に特殊な場合を除いては、このコンベンションを遵守する必要があります。 レジスタ</th> ABI名</th> 用途</th> Caller/Callee saved</th></tr></thead> x0</code></td> zero</code></td> 常に0（ISAレベルで固定）</td> —</td></tr> x1</code></td> ra</code></td> 復帰アドレス（Return Address）</td> Caller</td></tr> x2</code></td> sp</code></td> スタックポインタ（Stack Pointer）</td> Callee</td></tr> x3</code></td> gp</code></td> グローバルポインタ（Global Pointer）</td> —</td></tr> x4</code></td> tp</code></td> スレッドポインタ（Thread Pointer）</td> —</td></tr> x5</code></td> t0</code></td> 一時レジスタ</td> Caller</td></tr> x6</code></td> t1</code></td> 一時レジスタ</td> Caller</td></tr> x7</code></td> t2</code></td> 一時レジスタ</td> Caller</td></tr> x8</code></td> s0</code> / fp</code></td> 保存レジスタ / フレームポインタ</td> Callee</td></tr> x9</code></td> s1</code></td> 保存レジスタ</td> Callee</td></tr> x10</code></td> a0</code></td> 関数引数1 / 戻り値1</td> Caller</td></tr> x11</code></td> a1</code></td> 関数引数2 / 戻り値2</td> Caller</td></tr> x12</code></td> a2</code></td> 関数引数3</td> Caller</td></tr> x13</code></td> a3</code></td> 関数引数4</td> Caller</td></tr> x14</code></td> a4</code></td> 関数引数5</td> Caller</td></tr> x15</code></td> a5</code></td> 関数引数6</td> Caller</td></tr> x16</code></td> a6</code></td> 関数引数7</td> Caller</td></tr> x17</code></td> a7</code></td> 関数引数8</td> Caller</td></tr> x18</code></td> s2</code></td> 保存レジスタ</td> Callee</td></tr> x19</code></td> s3</code></td> 保存レジスタ</td> Callee</td></tr> x20</code></td> s4</code></td> 保存レジスタ</td> Callee</td></tr> x21</code></td> s5</code></td> 保存レジスタ</td> Callee</td></tr> x22</code></td> s6</code></td> 保存レジスタ</td> Callee</td></tr> x23</code></td> s7</code></td> 保存レジスタ</td> Callee</td></tr> x24</code></td> s8</code></td> 保存レジスタ</td> Callee</td></tr> x25</code></td> s9</code></td> 保存レジスタ</td> Callee</td></tr> x26</code></td> s10</code></td> 保存レジスタ</td> Callee</td></tr> x27</code></td> s11</code></td> 保存レジスタ</td> Callee</td></tr> x28</code></td> t3</code></td> 一時レジスタ</td> Caller</td></tr> x29</code></td> t4</code></td> 一時レジスタ</td> Caller</td></tr> x30</code></td> t5</code></td> 一時レジスタ</td> Caller</td></tr> x31</code></td> t6</code></td> 一時レジスタ</td> Caller</td></tr> </tbody></table> 木のリルーティング（全方位木DP） Unknown — Fri, 12 Apr 2024 00:00:00 +0000 AtCoder ABC #348</a>のE - Minimize Sum of Distance</a>で木DP、その中でも全方位木（全方位木（</rp>ぜんほういき</rt>）</rp></ruby>）DPを使うということで調べてみました。 このアルゴリズムは日本国外ではRerootingと呼ばれ、根が定まっていない木で条件に合う根を求める際に便利に使えるテクニックです。韓国では木でのダイナミックプログラミングの一種として扱われますが、海外では名前を付けるほど競技プログラミングで意外と頻出するアルゴリズムのようです。 概念</h2> 木DFS</h3> まず特定のノードについて他のノードまでの辺コストの総和を求める方法を考えましょう。これはDFS+DPで$O(n)$で実装できます。 リルーティング</h3> では他のノードまでの辺コストの総和が最も小さいノードはどう求められるでしょうか？上で説明した木DFSをノード数だけ使えばいいですが、それでは$O(n^2)$かかり、頂点が$10^5$個を超えるとTLEになります。まさにこの時リルーティングテクニックを使います。DFS+DP木の根を移すことが$O(1)$で可能であることを利用するテクニックです。 上の図で、Aノードの総距離和30を使ってBノードの総距離和を求めてみましょう。Aノードとその向こうにあるA(0), C(3), F(7)ノードの距離はA-B辺のコスト5だけ増加してA(5), C(8), F(12)になり、Bノードとその下にあるB(5), D(8), E(7)ノードの距離はA-B辺のコスト5だけ減少してB(0), D(3), E(2)になります。Aノードの増加分とBノードの減少分は相殺されるので、つまり(Aの総距離和) - {(Aノードの向こうのノード数) - (Bノードの下のノード数)} * (A-B辺のコスト)}</code>がBノードの総距離和になるわけです。 この方法でAノードの総距離和を知っている時、Bノードの総距離和を$O(1)$で求められます。このテクニックを根を移すと考えるとリルーティングテクニック、双方向に探索しながらDFSを回すと考えると全方位木DPという名前になります。アルゴリズムは大体そうですが、名前はあまり重要ではありません。 ここでAノードの向こうのノード数とBノードの下のノード数は、Aの総距離和を求める最初のDFSの時にサブノードの個数を一緒に保存しておけば求められます。上の例で言えば、Aのサブノード数</code> - Bのサブノード数</code>がAの向こうのノード数、Bのサブノード数</code>がそのままBノードの下のノード数になりますね。 例題</h2> BOJ 27730 : 牽牛と織女</a></h3> 上の例をそのまま適用できる問題です。木2つに対して実行し、両側で距離和が最も小さいノードを出力すればOKです。 BOJ 7812 : 中央木</a></h3> 中央ノードをリルーティングで求めた後、再度DFSを回して全ノードからの距離を出力すればOKです。 ABC#348 E</a></h3> リルーティングテクニックという名前を初めて知った問題で、辺のコストではなく頂点のコストが与えられます。つまり(該当頂点に行くのに必要な辺数) * (頂点のコスト)</code>が辺のコストになります。この問題は頂点のコスト和c[x]</code>と距離和c[x]*d</code>を両方記憶しながら解けばOKです。整理した正解コードは以下の通りで、解説はエディトリアル</a>を参照してください。 #include <bits/stdc++.h> using namespace std; #define llint long long int int main() { int n; cin >> n; vector<int> a(n - 1), b(n - 1); vector<vector<int>> tree(n); for (int i = 0; i < n - 1; i++) { cin >> a[i] >> b[i]; a[i] -= 1; b[i] -= 1; tree[a[i]].push_back(b[i]); tree[b[i]].push_back(a[i]); } vector<llint> c(n); for (int i = 0; i < n; i++) cin >> c[i]; //sum_c[i]はiを根とする木に対して頂点c[x]の和 //sum_d[i]はiを根とする木に対してc[x] * d(i, x)の和 vector<llint> sub_sum_c(n), sub_sum_d(n); auto dfs =[&](auto &&self, int v, int par) -> pair<llint, llint> { //v: 現在のノード、par: 親ノード for (int t: tree[v]) { //全ての下方向ノードに対して if (t == par) continue; //親方向には行かない auto [child_sum_c, child_sum_d] = self(self, t, v); sub_sum_c[v] += child_sum_c; //下方向cを累積 sub_sum_d[v] += child_sum_d; //下方向dを累積 } sub_sum_d[v] += sub_sum_c[v]; //再帰的にc[x]がd(i, x)回合計される sub_sum_c[v] += c[v]; return {sub_sum_c[v], sub_sum_d[v]}; }; dfs(dfs, 0, -1); //根からdfs、0(1)番ノードを根として扱う //dfsで全ノードに対してf(n)を求める vector<llint> f(n); auto reroot =[&](auto &&self, int v, int par, llint par_sum_c, llint par_sum_d) -> void { //v: 現在のノード、par: 親ノード、par_sum_c: 上方向へのc和、par_sum_d: 上方向へのd和 f[v] = sub_sum_d[v] + par_sum_d; for(int t : tree[v]) { //全ての下方向ノードに対して if(t == par) continue; //親方向には行かない llint nc = par_sum_c //vの上方向へのc和 + sub_sum_c[v] //vの下方向へのc和 //ここまで全ノードのc和 - sub_sum_c[t]; //tの下方向へのc和を引く //nc : tの上方向へのc和 llint nd = par_sum_d //vの上方向へのd和 + sub_sum_d[v] //vの下方向へのd和 - sub_sum_d[t] - sub_sum_c[t] //tの両方向d和を引く //ここまでtがvの位置にいた時のsum_d + nc; //tの上方向へのc和 //nd : tの上方向へのd和 self(self, t, v, nc, nd); } }; reroot(reroot, 0, -1, 0, 0); cout << *min_element(f.begin(), f.end()) << endl; }</code></pre>参照</h2> Codeforces - Rerooting Technique</a></li> nicotina04 - Rerooting Technique on Tree</a></li> Codeforces - Online Query Based Rerooting Technique</a></li> </ul> Dockerを使ったLinux実習環境の構築 Unknown — Tue, 29 Aug 2023 00:00:00 +0000 サークルで後輩たちにLinuxセミナーをすることになりました。となると、実習環境の構築が必要ですよね。 一昨年は先輩たちがVirtualBoxをインストールしてこいと言い、去年は同じく自分がセミナーを担当して、後輩たちに自分のLinuxサーバーのアカウントを一つずつ渡す方式で実習をしました。 今年はLinuxと仮想化の知識がかなり増えたし、サーバーもきれいに再構築した</a>ので、仮想化を通じて一人一サーバーを提供することにしました。 ググる</h3> 元々はコンテナを複数開いてSSHリバースプロキシやジャンプフォワードで構築しようとしていたのですが、思ったより難しくて苦戦していたところ、以下の記事を見つけました。 Replicate and Isolating user environments on the fly</a> まさに求めていたものだったので、この内容をベースに環境に合わせて修正して構築することにしました。 イメージの作成</h3> 上の記事ではコンテナを修正してそれを再びイメージにする過程を経ていますが、それは面倒すぎるのでDockerfileで構成することにしました。 # Dockerfile FROM ubuntu:latest RUN apt-get update RUN apt-get install -y vim sudo man-db gcc RUN yes | unminimize RUN useradd -ms /bin/bash guest RUN echo 'guest:password' | chpasswd RUN usermod -a -G sudo guest USER guest WORKDIR /home/guest</code></pre> 実習に必要なパッケージであるvim</code>、sudo</code>、man-db</code>、gcc</code>をインストールし、unminimize</code>を実行してman</code>が動作するようにします。 そしてguestというユーザーを作成して、コンテナに接続するとrootではなくユーザーとして接続するようにします。これならSSHで直接接続するのとより似た感覚を与えられますよね。 docker build --tag sandbox .</code></pre> でイメージをビルドします。 ユーザーの作成</h3> 次にユーザーを作成して、SSHで接続すると偽のシェルに接続するようにします。 mkdir /home/guest cat > /home/guest/sandbox <<EOF #!/bin/sh exec docker run -t -i --rm=true sandbox /bin/bash EOF chmod +x /home/guest/sandbox # useradd guest -g docker -s /home/guest/sandbox useradd guest -s /home/guest/sandbox chown guest /home/guest passwd guest</code></pre> 私はDockerではなくPodman環境なので、ユーザーにdocker</code>グループを付与しなくてもRootless Podman</a>を実行できました。Dockerで構成する場合はdocker</code>グループの付与が必要ですね。 docker</code>コマンドには--rm=true</code>引数を付けて、Dockerコンテナから出た場合にすぐコンテナが削除されるようにし、ユーザーが入ってくると偽のシェルを実行してDockerを開くようにします。 完成</h3> 上記の設定通りに構築し、guest</code>ユーザーでSSH接続すると、一時的に生成されたコンテナに閉じ込められます。 （ブログに書いたものとユーザー名は異なります。） この環境では好きなだけパッケージをインストールしたり（カーネルに関連するもの以外なら）システムを変更でき、sudo rm -rf /</code>を実行してもコンテナを実行しているシステムには何の影響もありません。 ログアウトして再接続すると全ての内容が初期化され、新しいコンテナが生成されるので、実習に良い環境ですよね。 sudo rm -rf --no-preserve-root /</code></pre> を実行してシステムが壊れないか確認してみましょう。 2024.07.15 追記</h3> 上記のようにコンテナを構築すると、ログアウト時にたまにコンテナが正しく削除されない問題、ログイン時にRefreshing Errorが発生する問題があります。 ERRO[0001] Refreshing container 2e3d121a75ec00add6a35694cdc26e6442bb98a7e993b918569dd7584597bca6: acquiring lock 0 for container 2e3d121a75ec00add6a35694cdc26e6442bb98a7e993b918569dd7584597bca6: file exists</code></pre> ログアウト時にコンテナが削除されない問題は、guest</code>アカウントの.bash_logout</code>ファイルにdocker stop sandbox</code>を記述しました。確実ではありませんが解決したようです。エラーはloginctl enable-linger guest</code>でアカウントのlingering modeを許可すると解決するようです。

zlfn.space

コンピュータアーキテクチャとRISC-V

ISAの歴史</h2>

RV32I命令セット</h2>

木のリルーティング（全方位木DP）

木DFS</h3>
まず特定のノードについて他のノードまでの辺コストの総和</strong>を求める方法を考えましょう。これはDFS+DPで$O(n)$で実装できます。 </p>

参照</h2>

Codeforces - Rerooting Technique</a></li>
nicotina04 - Rerooting Technique on Tree</a></li>
Codeforces - Online Query Based Rerooting Technique</a></li> </ul>

Dockerを使ったLinux実習環境の構築

zlfn.space

コンピュータアーキテクチャとRISC-V

ISAの歴史</h2>

RV32I命令セット</h2>

木のリルーティング（全方位木DP）

木DFS</h3> まず特定のノードについて他のノードまでの辺コストの総和</strong>を求める方法を考えましょう。これはDFS+DPで$O(n)$で実装できます。 </p>

Dockerを使ったLinux実習環境の構築

木DFS</h3>
まず特定のノードについて他のノードまでの辺コストの総和</strong>を求める方法を考えましょう。これはDFS+DPで$O(n)$で実装できます。 </p>