コグノスケ

GCCを調べる - その5 - RTL (Register Transfer Language) の定義

目次: GCC

全てのRTLの定義はgcc/rtl.defに定義されています。例えばinsnの定義は下記のとおりです。

/* An instruction that cannot jump.  */
DEF_RTL_EXPR(INSN, "insn", "uuBeiie", RTX_INSN)

何となくわかるけど、何だこれ？と思いますよね、私は思いました。それもそのはずで、実はこのファイルは単体では意味をなさず、Cファイルから何度も再利用されるからです。Cファイルからrtl.defをインクルードして使いますが、その際にDEF_RTL_EXPR() の意味が変わります。

比較的わかりやすい例を挙げるとしたら、gcc/rtl.cのrtx_formatの定義です。DEF_RTL_EXPR() を定義してから #include "rtl.def" を行う様子がわかるかと思います。

/* Indexed by rtx code, gives a sequence of operand-types for
   rtx's of that code.  The sequence is a C string in which
   each character describes one operand.  */

const char * const rtx_format[NUM_RTX_CODE] = {
  /* "*" undefined.
         can cause a warning message
     "0" field is unused (or used in a phase-dependent manner)
         prints nothing
     "i" an integer
         prints the integer
     "n" like "i", but prints entries from `note_insn_name'
     "w" an integer of width HOST_BITS_PER_WIDE_INT
         prints the integer
     "s" a pointer to a string
         prints the string
     "S" like "s", but optional:
	 the containing rtx may end before this operand
     "T" like "s", but treated specially by the RTL reader;
         only found in machine description patterns.
     "e" a pointer to an rtl expression
         prints the expression
     "E" a pointer to a vector that points to a number of rtl expressions
         prints a list of the rtl expressions
     "V" like "E", but optional:
	 the containing rtx may end before this operand
     "u" a pointer to another insn
         prints the uid of the insn.
     "b" is a pointer to a bitmap header.
     "B" is a basic block pointer.
     "t" is a tree pointer.
     "r" a register.
     "p" is a poly_uint16 offset.  */

#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)   FORMAT ,
#include "rtl.def"		/* rtl expressions are defined here */
#undef DEF_RTL_EXPR
};

このrtx_formatの場合は、第3引数（FORMAT）とカンマを残して、他は無視するようにDEF_RTL_EXPR() を定義しています。

コメントなどを無視して考えるとrtl.defをインクルードしたあとは、コードは下記のようになります。

const char * const rtx_format[NUM_RTX_CODE] = {
DEF_RTL_EXPR(UNKNOWN, "UnKnown", "*", RTX_EXTRA)

DEF_RTL_EXPR(VALUE, "value", "0", RTX_OBJ)

DEF_RTL_EXPR(DEBUG_EXPR, "debug_expr", "0", RTX_OBJ)

...
};

マクロDEF_RTL_EXPR() の展開後はこうなります。

const char * const rtx_format[NUM_RTX_CODE] = {
"*",

"0",

"0",

...
};

最終的にrtx_formatは文字列の配列になります。

私もrtl.defの用途全てを理解しているわけではなく、全てを説明することもできないので、またわかったら書くことにします。

Zephyr - まとめリンク

目次: Zephyr

導入、ブート周り

• Hello! Zephyr OS!!
• Hello! Zephyr OS!! (RISC-V 32bit版)
• Zephyrのダウンロードとモジュール
• Zephyr SMP対応
• Debian TestingとZephyr SDKその1 - 自分でSDKをビルド
• Debian TestingとZephyr SDKその2 - パッチを当ててSDKビルドをする前に
• Debian TestingとZephyr SDKその3 - パッチを当ててSDKビルド
• Debian TestingとZephyr SDKその4 - ローカルパッチの仕組みが0.13で変わった
• Zephyrのエントリアドレス
• Zephyrのブート処理 - C言語と出会うまで
• Zephyrのブート処理 - ドライバの初期化まで
• Zephyrのブート処理 - ドライバの初期化情報の謎
• Zephyrのブート処理 - ドライバの初期化情報とリンカーの妙技
• Zephyrのコンテキストスイッチ
• Zephyr RISC-V向けのマルチコアブートを修正

ボード、ドライバなど

• Zephyr OSで遊ぼう その1 - ボードを追加してcmake
• Zephyr OSで遊ぼう その2 - ボードを追加してビルド
• Zephyr OSで遊ぼう その3 - ボードのデフォルトコンフィグ
• Zephyr OSで遊ぼう その4 - 独自のSoC定義
• Zephyr OSで遊ぼう その5 - 独自のSoC定義（続き）
• Zephyr OSで遊ぼう その6 - 独自のSoC定義でビルド
• Zephyr OSで遊ぼう その7 - 独自のシリアルドライバの枠組み
• Zephyr OSで遊ぼう その8 - 独自のシリアルドライバの実装
• Zephyr OSで遊ぼう その9 - Zephyr 2.2.0に対応する
• Zephyr OSで遊ぼう その10 - QEMUの変化に対応する
• Zephyr OSで遊ぼう その11 - Zephyr 2.3.0に対応する
• Zephyrの16550シリアルドライバ
• ZephyrとRISC-Vとマルチプロセッサ
• Zephyrの16550シリアルドライバ その2
• ZephyrとQEMUのリセット その1 - 準備編
• ZephyrとQEMUのリセット その2 - 実装編
• Zephyr on HiFive Unleashed
• Zephyr on HiFive Unmatched
• Zephyr on HiFive Unmatched/HiFive Unleashed
• ZephyrのDevice Tree Overlay
• ZephyrのDevice Tree Overlayと独自のbindings

SMP対応編

• Zephyr OSで遊ぼう その12 - SMP対応の準備、コンテキストスイッチのコンフィグ
• Zephyr OSで遊ぼう その13 - SMP対応の準備、コンテキストスイッチの実装、前編、ラッパー関数まで実装
• Zephyr OSで遊ぼう その14 - SMP対応の準備、コンテキストスイッチの実装、中編1、既存実装調査
• Zephyr OSで遊ぼう その15 - SMP対応の準備、コンテキストスイッチの実装、中編2、既存実装調査
• Zephyr OSで遊ぼう その16 - SMP対応の準備、コンテキストスイッチの実装、後編1、RISC-Vのコンテキストスイッチ
• Zephyr OSで遊ぼう その17 - SMP対応の準備、コンテキストスイッチの実装、後編2、明示的コンテキストスイッチ
• Zephyr OSで遊ぼう その18 - SMP対応の準備、コンテキストスイッチの実装、後編3、プリエンプション
• Zephyr OSで遊ぼう その19 - SMP対応CPUコア数1、ビルドエラーの対処1
• Zephyr OSで遊ぼう その20 - SMP対応CPUコア数1、ビルドエラーの対処2
• Zephyr OSで遊ぼう その21 - SMP対応CPUコア数1、実行時エラーの対処
• Zephyr OSで遊ぼう その22 - SMP対応CPUコア数1、HART 0以外で動かす、動作確認環境
• Zephyr OSで遊ぼう その23 - SMP対応CPUコア数1、HART 0以外で動かす
• Zephyr OSで遊ぼう その24 - SMP対応CPUコア数4、マルチコアブート
• Zephyr OSで遊ぼう その25 - SMP対応CPUコア数4、IPIの実装
• Zephyr OSで遊ぼう その26 - SMP対応、リグレッションテストの準備
• Zephyr OSで遊ぼう その27 - SMP対応、デグレードの修正

浮動小数点数命令など

• Zephyrと浮動小数点数命令のサポート その1 - ボードの設定とビルド
• Zephyrと浮動小数点数命令のサポート その2 - 実行
• Zephyrと浮動小数点数命令のサポート その3 - ztestの仕組み、前編
• Zephyrと浮動小数点数命令のサポート その4 - ztestの仕組み、後編

その他

• Zephyrのcollaborator
• Zephyrのcollaboratorその2
• ZephyrのMemberになった

ZephyrとRISC-Vとマルチプロセッサ

目次: Zephyr

昨日（2020年2月20日の日記参照）の続きです。

シリアルのみですが、ZephyrをQEMU RISC-V 32のvirtモードに移植しました。やっとZephyrが4 CPUで動くぞ、などと思っていましたが、全然ダメでした。2つ目以降のCPUは全く動きませんでした。

$ riscv64-zephyr-elf-gdb zephyr/build/zephyr/zephyr.elf

(gdb) info threads
  Id   Target Id                    Frame
* 1    Thread 1.1 (CPU#0 [halted ]) 0x80000f70 in arch_cpu_idle ()
    at zephyr/soc/riscv/riscv-privilege/common/idle.c:21
  2    Thread 1.2 (CPU#1 [halted ]) loop_slave_core ()
    at zephyr/arch/riscv/core/reset.S:45
  3    Thread 1.3 (CPU#2 [halted ]) loop_slave_core ()
    at zephyr/arch/riscv/core/reset.S:45
  4    Thread 1.4 (CPU#3 [halted ]) loop_slave_core ()
    at zephyr/arch/riscv/core/reset.S:45

理由は簡単で、ZephyrのRISC-V版はSMPに対応していないからです。何を言ってるんだ？って？ええ、実は私も今この瞬間まで知りませんでした。ビックリしました。

リセット付近のソースコードをみると、

// zephyr/arch/riscv/core/reset.S

/*
 * Remainder of asm-land initialization code before we can jump into
 * the C domain
 */
SECTION_FUNC(TEXT, __initialize)
        /*
         * This will boot master core, just halt other cores.
         * Note: need to be updated for complete SMP support
         */
        csrr a0, mhartid
        beqz a0, boot_master_core

loop_slave_core:
        wfi
        j loop_slave_core

以上のように、はっきり書いてあります。SMPは一番大事な機能だと思っていただけに、未対応とは思わなんだ。

あー、今日の16550との戦いは一体何だったんだろう。しょんぼりですわ……。

メモ: 技術系の話はFacebookから転記しておくことにした。大幅に加筆した。