コグノスケ

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の用途全てを理解しているわけではなく、全てを説明することもできないので、またわかったら書くことにします。

GCCを調べる - その6 - ベクトルレジスタ用のregister constraintを足す

目次: GCC

GCCのインラインアセンブラでは __asm__("ins %0" : "=r"(aaa) : : ); のように、"=r" という不思議な文字列が出てきます。

これはconstraintsと呼ばれ（GCCのマニュアルへのリンク）、引数がレジスタ（r）なのかメモリアドレス（m）なのか、書き換えられるのか（=）などを説明しています。

どんな文字でも書けるわけではなく、変な文字（例えば 'v'）を指定すると「impossible constraint in 'asm'」と怒られます。これは一体どこでチェックしているのでしょう？また、どうやって足せばよいでしょうか？

エラーを出している箇所

このエラーを出すのは、パスでいうと234r.vregsです。

ちなみにbuild_gccというディレクトリ名はGCCのビルドディレクトリのことです。GCCは自動生成コードをかなりの量出力するので、そちらも合わせて見る必要があります。

// gcc/function.c

static void
instantiate_virtual_regs_in_insn (rtx_insn *insn)
{
...
  if (asm_noperands (PATTERN (insn)) >= 0)
    {
      if (!check_asm_operands (PATTERN (insn)))  //★★このエラーチェックに引っかかっている
	{
	  error_for_asm (insn, "impossible constraint in %<asm%>");  //★★このエラーメッセージが出ている


// gcc/recog.c

int
check_asm_operands (rtx x)
{
...
  for (i = 0; i < noperands; i++)
    {
      const char *c = constraints[i];
      if (c[0] == '%')
	c++;
      if (! asm_operand_ok (operands[i], c, constraints))  //★★このエラーチェックに引っかかっている
	return 0;
    }

このチェックは何をしているのかというと、lookup_constraint() で文字（例えば 'v'）をテーブルから探し、constraintの種類に変換します。未知の文字の場合はCONSTRAINT_UNKNOWNになります。

次にget_constraint_type() でどのカテゴリに属するか見ます。この関数はおかしくて、なぜかCONSTRAINT__UNKNOWNをCT_REGISTERと判定します。レジスタじゃないですよね？意味不明です。

// gcc/recog.c

int
asm_operand_ok (rtx op, const char *constraint, const char **constraints)
{
  int result = 0;
...
  while (*constraint)
    {
      enum constraint_num cn;
      char c = *constraint;
      int len;
      switch (c)
	{
...
	default:
	  cn = lookup_constraint (constraint);  //★★文字からconstraint_numに変換
						//    未知の文字の場合CONSTRAINT__UNKNOWNになる
	  switch (get_constraint_type (cn))
	    {
	    case CT_REGISTER:  //★★なぜかここに行く
	      if (!result
		  && reg_class_for_constraint (cn) != NO_REGS  //★★レジスタのconstraintがNO_REGSになるとNG
		  && GET_MODE (op) != BLKmode
		  && register_operand (op, VOIDmode))
		result = 1;
	      break;


// build_gcc/gcc/tm-preds.h

static inline enum constraint_num
lookup_constraint (const char *p)
{
  unsigned int index = lookup_constraint_array[(unsigned char) *p];  //★★この配列がカギ
  return (index == UCHAR_MAX
          ? lookup_constraint_1 (p)
          : (enum constraint_num) index);
}

enum constraint_num
{
  CONSTRAINT__UNKNOWN = 0,
  CONSTRAINT_r,
  CONSTRAINT_f,
...

static inline enum constraint_type
get_constraint_type (enum constraint_num c)
{
  if (c >= CONSTRAINT_p)
    {
      if (c >= CONSTRAINT_G)
        return CT_FIXED_FORM;
      return CT_ADDRESS;
    }
  if (c >= CONSTRAINT_m)
    return CT_MEMORY;
  if (c >= CONSTRAINT_I)
    return CT_CONST_INT;
  return CT_REGISTER;  //★★cがCONSTRAINT__UNKNOWNつまり0の場合、どれにも当てはまらずCT_REGISTERと判断される
}


// build_gcc/insn-preds.c

const unsigned char lookup_constraint_array[] = {
  CONSTRAINT__UNKNOWN,
  CONSTRAINT__UNKNOWN,
...
  MIN ((int) CONSTRAINT_r, (int) UCHAR_MAX),
  MIN ((int) CONSTRAINT_s, (int) UCHAR_MAX),
  CONSTRAINT__UNKNOWN,
  CONSTRAINT__UNKNOWN,
  CONSTRAINT__UNKNOWN,  //★★'v' は未定義、未知の文字の場合は全てCONSTRAINT__UNKNOWNになる
  CONSTRAINT__UNKNOWN,
...


// build_gcc/gcc/tm-preds.h

static inline enum reg_class
reg_class_for_constraint (enum constraint_num c)
{
  if (insn_extra_register_constraint (c))
    return reg_class_for_constraint_1 (c);  //★★ここで見つからないとNO_REGSが返されてNG
  return NO_REGS;
}


// build_gcc/gcc/insn-preds.c

enum reg_class
reg_class_for_constraint_1 (enum constraint_num c)
{
  switch (c)
    {
    case CONSTRAINT_r: return GENERAL_REGS;
    case CONSTRAINT_f: return TARGET_HARD_FLOAT ? FP_REGS : NO_REGS;
    case CONSTRAINT_j: return SIBCALL_REGS;
    case CONSTRAINT_l: return JALR_REGS;
    default: break;  //★★CONSTRAINT__UNKNOWNはどのcaseにも当てはまらないのでNO_REGSが返されてNG
    }
  return NO_REGS;
}

明らかにレジスタとは思えないCONSTRAINT__UNKNOWNが返ってきますが、なぜかCT_REGISTERだと思って処理し始め、最終的にエラーとして弾きます。結果オーライですがこれで良いんでしょうか。GCCのコードは訳がわかりません……。

register_constraintの足し方

ではvを正当なconstraintの一員にするにはどうしたら良いでしょうか？

第一歩としてはGCCのconfigディレクトリの下にある *.mdファイル（MarkdownではなくMachine Descriptorです）を編集します。

;; config/riscv/riscv.md

(include "predicates.md")
(include "constraints.md")


;; config/riscv/constraints.md

(define_register_constraint "v" "TARGET_VECTOR ? VP_REGS : NO_REGS"
  "A vector register (if available).")

これを足すと（他にも色々やらないといけないんですけど）、先程のreg_class_for_constraint_1() に変化が生じます。

// build_gcc/gcc/insn-preds.c

enum reg_class
reg_class_for_constraint_1 (enum constraint_num c)
{
  switch (c)
    {
    case CONSTRAINT_r: return GENERAL_REGS;
    case CONSTRAINT_f: return TARGET_HARD_FLOAT ? FP_REGS : NO_REGS;
    case CONSTRAINT_j: return SIBCALL_REGS;
    case CONSTRAINT_v: return TARGET_VECTOR ? VP_REGS : NO_REGS;  //★★これが足されて通過するようになる
    case CONSTRAINT_l: return JALR_REGS;
    default: break;
    }
  return NO_REGS;
}

GCCはこの手のピタゴラスイッチの塊で、何を変えると望みの機能が実装できるか、全くわかりません。こんなもの良くメンテナンスできるなあ、と思います。

TinkerBoardが起動しなくなった

目次: ROCK64/ROCKPro64

ASUS TinkerBoardで動かしているlinux-nextを最新版に更新したところ、下記のようなエラーを出力して起動しなくなりました。

[    0.000000] __clk_core_init: Failed to get phase for clk 'sdmmc_drv'
[    0.000000] rockchip_clk_register_branches: failed to register clock sdmmc_drv: -22
[    0.000000] rockchip_clk_register_branches: failed to register clock sdmmc_sample: -17
[    0.000000] rockchip_clk_register_branches: failed to register clock sdio0_drv: -17
[    0.000000] rockchip_clk_register_branches: failed to register clock sdio0_sample: -17
[    0.000000] rockchip_clk_register_branches: failed to register clock sdio1_drv: -17
[    0.000000] rockchip_clk_register_branches: failed to register clock sdio1_sample: -17
[    0.000000] rockchip_clk_register_branches: failed to register clock emmc_drv: -17
[    0.000000] rockchip_clk_register_branches: failed to register clock emmc_sample: -17

エラーメッセージで検索しても、特にめぼしい報告やパッチに引っかかりません。うーん。困りましたね。

原因解析

仕方ないので、更新履歴をgit bisectすると2/13から2/14の間にクロックドライバが変更されたことが原因だとわかりました。

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dc8bdfbd6a0c..ed1797857bae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3457,7 +3457,12 @@ static int __clk_core_init(struct clk_core *core)
 	 * Since a phase is by definition relative to its parent, just
 	 * query the current clock phase, or just assume it's in phase.
 	 */
-	clk_core_get_phase(core);
+	ret = clk_core_get_phase(core);
+	if (ret < 0) {
+		pr_warn("%s: Failed to get phase for clk '%s'\n", __func__,
+			core->name);
+		goto out;
+	}
 
 	/*
 	 * Set clk's duty cycle.

しかしこの変更は真っ当に見えます。今までエラーを無視していたところをエラーチェックするようにしているだけだからです。

どの辺りでエラーが出るか調べるためprintkを適当に入れたりしながら追ってみると、下記の場所で躓いていました。

// drivers/clk/clk.c

static int __clk_core_init(struct clk_core *core)
{
...
	/*
	 * Set clk's phase by clk_core_get_phase() caching the phase.
	 * Since a phase is by definition relative to its parent, just
	 * query the current clock phase, or just assume it's in phase.
	 */
	phase = clk_core_get_phase(core);  //★★変更が影響している場所
	if (phase < 0) {
		ret = phase;
		pr_warn("%s: Failed to get phase for clk '%s'\n", __func__,
			core->name);
		//goto out;
	}


// drivers/clk/clk.c

static int clk_core_get_phase(struct clk_core *core)
{
	int ret;

	lockdep_assert_held(&prepare_lock);
	if (!core->ops->get_phase)
		return 0;

	/* Always try to update cached phase if possible */
	ret = core->ops->get_phase(core->hw);  //★★ここでエラーが発生していた
	if (ret >= 0)
		core->phase = ret;

	return ret;
}

独自のget_phaseを持っているドライバがエラーを返すと、clk_core_get_phase() もエラーを返し、先程のエラーメッセージが表示されるみたいです。しかし、この処理自体におかしな箇所はないように思います。真っ当です。

おそらく実装がおかしいのはRockchipのMMCドライバのクロック周りの方でしょう。エラーメッセージに出ているsdmmc_drvを頼りにコードを追います。

// drivers/clk/rockchip/clk-rk3228.c

PNAME(mux_mmc_src_p)		= { "cpll", "gpll", "xin24m", "usb480m" };
...
	COMPOSITE(SCLK_SDMMC, "sclk_sdmmc", mux_mmc_src_p, 0,
			RK2928_CLKSEL_CON(11), 8, 2, MFLAGS, 0, 8, DFLAGS,
			RK2928_CLKGATE_CON(2), 11, GFLAGS),
	...
	//★★sdmmc_drvはこの部分由来です
	MMC(SCLK_SDMMC_DRV,    "sdmmc_drv",    "sclk_sdmmc", RK3228_SDMMC_CON0, 1),


// drivers/clk/rockchip/clk.h

#define MMC(_id, cname, pname, offset, shift)			\
	{							\
		.id		= _id,				\
		.branch_type	= branch_mmc,			\  //★★この値がカギかな？
		.name		= cname,			\
		.parent_names	= (const char *[]){ pname },	\
		.num_parents	= 1,				\
		.muxdiv_offset	= offset,			\
		.div_shift	= shift,			\
	}


// drivers/clk/rockchip/clk-rk3228.c

static void __init rk3228_clk_init(struct device_node *np)
{
...
	rockchip_clk_register_branches(ctx, rk3228_clk_branches,  //★★ここでbranch_typeを見ている箇所がある
				  ARRAY_SIZE(rk3228_clk_branches));
...
}
//★★注: rk3228_clk_initはRK3228のクロックコア初期化関数
//    デバイスツリー内のcompatible = "rockchip,rk3228-cru" を持つノードに応じて呼ばれる
CLK_OF_DECLARE(rk3228_cru, "rockchip,rk3228-cru", rk3228_clk_init);


// drivers/clk/rockchip/clk.c

void __init rockchip_clk_register_branches(
				      struct rockchip_clk_provider *ctx,
				      struct rockchip_clk_branch *list,
				      unsigned int nr_clk)
{
...
	for (idx = 0; idx < nr_clk; idx++, list++) {
		flags = list->flags;

		/* catch simple muxes */
		switch (list->branch_type) {
		...
		case branch_mmc:  //★★branch_type == branch_mmcだったら
			clk = rockchip_clk_register_mmc(  //★★クロックの登録をしている
				list->name,
				list->parent_names, list->num_parents,
				ctx->reg_base + list->muxdiv_offset,
				list->div_shift
			);
			break;
		...


// drivers/clk/rockchip/clk-mmc-phase.c

struct clk *rockchip_clk_register_mmc(const char *name,
				const char *const *parent_names, u8 num_parents,
				void __iomem *reg, int shift)
{
...
	init.name = name;
	init.flags = 0;
	init.num_parents = num_parents;
	init.parent_names = parent_names;
	init.ops = &rockchip_mmc_clk_ops;  //★★クロックの操作関数を登録している
...


// drivers/clk/rockchip/clk-mmc-phase.c

static const struct clk_ops rockchip_mmc_clk_ops = {
	.recalc_rate	= rockchip_mmc_recalc,
	.get_phase	= rockchip_mmc_get_phase,  //★★get_phaseはこの関数
	.set_phase	= rockchip_mmc_set_phase,
};


// drivers/clk/rockchip/clk-mmc-phase.c

static int rockchip_mmc_get_phase(struct clk_hw *hw)
{
	struct rockchip_mmc_clock *mmc_clock = to_mmc_clock(hw);
	unsigned long rate = clk_hw_get_rate(hw);
	u32 raw_value;
	u16 degrees;
	u32 delay_num = 0;

	/* See the comment for rockchip_mmc_set_phase below */
	if (!rate)
		return -EINVAL;  //★★エラーを返している
...

原因らしき箇所が見つかりました。クロック周波数（rate）が設定されていなくても、エラーを返す必要はなく、phaseの初期値0を返せば良いはずですから、return -EINVALをreturn 0にすれば良さそうです。

変更すると無事linux-nextが起動できるようになりました。良かった良かった。

またこのパターン！

こんなバグを2週間以上放置するなんてlinuxらしくないなと思って、パッチを送ろうとしましたが……、なんだかとっても嫌な予感がしたので、rochchip_mmc_get_phaseでLKMLを検索してみました。

検索してびっくり、なんと、全く同じ指摘をしているパッチが先週LKMLに送られています（LKMLへのリンク）。しかも既にclk-nextに取り込まれているじゃないですか。ですがlinux-nextへの反映はまだのようです。

明日まで待っていればclk-nextがlinux-nextに取り込まれるので、何もしなくても解決していたんです。パッチ投稿が3/4なので、今回は本当に気づくタイミングが悪かったです。

Author: Jerome Brunet < >
Date:   Tue Mar 3 20:29:56 2020 +0100

    clk: rockchip: fix mmc get phase
    
    If the mmc clock has no rate, it can be assumed to be constant.
    In such case, there is no measurable phase shift. Just return 0
    in this case instead of returning an error.
    
    Fixes: 2760878662a2 ("clk: Bail out when calculating phase fails during clk
    registration")
    Tested-by: Markus Reichl <m.reichl@fivetechno.de>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>

diff --git a/drivers/clk/rockchip/clk-mmc-phase.c b/drivers/clk/rockchip/clk-mmc-phase.c
index 4abe7ff31f53..975454a3dd72 100644
--- a/drivers/clk/rockchip/clk-mmc-phase.c
+++ b/drivers/clk/rockchip/clk-mmc-phase.c
@@ -51,9 +51,9 @@ static int rockchip_mmc_get_phase(struct clk_hw *hw)
 	u16 degrees;
 	u32 delay_num = 0;
 
-	/* See the comment for rockchip_mmc_set_phase below */
+	/* Constant signal, no measurable phase shift */
 	if (!rate)
-		return -EINVAL;
+		return 0;
 
 	raw_value = readl(mmc_clock->reg) >> (mmc_clock->shift);

前にも、原因を突き止めたら、解決済みだったというパターン（2018年12月4日の日記、2019年9月18日の日記）がありました。

またこの「鶏と卵のパターン」にやられました。ついてない。

コードに特攻する前に、ちゃんと探せば？って思われるかもしれませんが、困ったことにエラーメッセージで検索してもパッチに辿り着けないんです。調べに調べて原因と対策がわかった後に、はぁ？もうパッチあるじゃん！？と気づくから、徒労感が激しい……。

誕生日

37歳になりました。おめでとう俺、ありがとう俺。30代も残りわずかです。

何歳になろうが、本人は特に何も変わってませんが、周りから見ると確実にオジサンです。若者へ説教と昔の自慢話だけは絶対しないように気をつけます。

今に始まったことじゃないんですが、いつも何歳だか良くわからなくなります。もちろん (現在の西暦) - (生まれた西暦) で、1月1日〜3月9日は -1すれば良いのはわかってますが、ぱっと答えられません。なぜなのか……。

GCCを調べる - その7 - machine mode定義ファイルの場所

目次: GCC

GCCはアーキテクチャごとに設定ファイルがあってgcc/config/(アーキテクチャ名)/ という名前のディレクトリ下に配置されています。

その中にmachine modeを設定するファイルがあります。例えばRISC-Vならgcc/config/riscv/riscv-modes.defですし、AArch64ならgcc/config/aarch64/aarch64-modes.defです。machine modeとは何かはちょっと横に置いて、このファイルの探し方が割と不思議な作りだったので紹介します。

GCCのビルドプロセスは非常にややこしいです。xxxx-modes.defはGCCのコードで直接使われず、前処理で使われます。GCCのビルドディレクトリを (build_dir) と書くとすると、

• genmodes.cから (build_dir)/build/genmodesというプログラムを作成
• genmodesの出力を使い (build_dir)/insn-modes.cを生成
• insn-modes.cをGCCのビルドに使う

こんな仕組みになっています。起点となるgenmodes.cから見ます。

// gcc/genmodes.c

static void
create_modes (void)
{
#include "machmode.def"  //★★これに全てのモードが定義されている


// gcc/machmode.def

/* Allow the target to specify additional modes of various kinds.  */
#if HAVE_EXTRA_MODES
# include EXTRA_MODES_FILE  //★★追加のファイルがあればinclude
#endif


// gcc/genmodes.c

#ifdef EXTRA_MODES_FILE
# define HAVE_EXTRA_MODES 1
#else
# define HAVE_EXTRA_MODES 0
# define EXTRA_MODES_FILE ""
#endif

EXTRA_MODES_FILEというマクロにファイル名が定義されていれば、そのファイルもincludeする仕組みになっています。C言語を見慣れている人もかなり面食らう書き方ですが、GCCは「*.defファイルをincludeする」という技を乱発します。メチャクチャすぎる。

EXTRA_MODES_FILEをマクロを定義するのはconfig.gccとconfigureです。

# gcc/config.gcc

extra_modes=
if test -f ${srcdir}/config/${cpu_type}/${cpu_type}-modes.def
then
	extra_modes=${cpu_type}/${cpu_type}-modes.def    # ★★aarch64-modes.defのような名前のファイルが存在すればそのファイルを使う
fi


# gcc/configure

# Collect target-machine-specific information.
. ${srcdir}/config.gcc || exit 1    # ★★config.gccの設定を取り込む

...

# Look for a file containing extra machine modes.
if test -n "$extra_modes" && test -f $srcdir/config/$extra_modes; then
  extra_modes_file='$(srcdir)'/config/${extra_modes}    # ★★extra_modesはconfig.gccで定義したものが導入される


cat >>confdefs.h <<_ACEOF
#define EXTRA_MODES_FILE "config/$extra_modes"    # ★★config/aarch64/aarch64-modes.defのような値になる
_ACEOF

fi

やっとたどり着きました。GCCってちょっとしたことでも、ものすごく複雑にできていて、読むのが辛いというか、読んでも意味不明なことが多いです。うーん、辛い。

ナンバープレート変更（大阪→品川）

目次: 車

引っ越してから1年もの間、車検証の住所変更をせずにほったらかしていました（本当は良くない）が、重い腰を上げ、大阪ナンバーにお別れを告げて、品川ナンバーになりました。

手続きに興味があったので、あえてディーラーにお任せせず自分でやってみました。面白かったですが相当面倒くさいです。もう自分でやることはないでしょうね。

手続きの概要

今回は「変更登録」という手続きをしました。車検証の住所変更＆ナンバープレートの変更です。他県から東京都に引っ越した人が該当します。手続きはざっくりいうと、

• 警察（車庫証明）1回目
• （3日〜1週間後）
• 警察（車庫証明）2回目
• 市役所（住民票）1回
• 陸運局（車検証）1回

どうがんばって圧縮しても、平日を2回消費します。普通は警察、警察、陸運局、の3回消費すると思います。警察も陸運局も平日しか受け付けしていないので、勤め人にはなかなか辛いです。

詳細な手続き

興味のある人は居なさそうですが、メモ代わりに書いておきます。まずは車庫証明用の書類が必要です。

• （借家の場合）大家さんに「保管場所使用承諾証明書」を書いてもらう
• 自分で「自動車保管場所証明申請書」を書く
• 自分で「保管場所標章交付申請書」を書く
• 自分で「保管場所の所在図・配置図」を書く

ここまでの書類は全部の警視庁のサイト（保管場所証明申請手続 - 警視庁）からゲットできます。

管轄の警察

上記の「4つの書類」を出して「領収証書」を貰います。「何月何日にもう一回来てね」と教えてくれます。
私の場合は「蒲田警察署」でした。それと金額は忘れましたが、収入印紙を買う必要があります。その場で手に入るので、財布だけあれば特に準備不要です。

管轄の警察

「領収証書」を渡すと「車庫証明」を貰います。私は3日後でしたが、場合によるらしくだいたい3日〜1週間後みたいです。

市役所

「住民票」を貰います。窓口に行ってお金払うとくれます。

運輸局（陸運局）に「車で」行く

私の場合は「関東運輸局 東京運輸支局」でした。鮫洲にあります。免許センターの隣と言った方がわかるかも。
超大事なことなのですが、ナンバープレートを交換しなければならないので、車で行きましょう、でないと窓口で追い返されます。
国土交通省のサイトにある「1号様式」が申請書類です（自動車：OCR申請書各種様式について - 国土交通省）が、正直訳わかんないです。書類は事前に書きましたが、事前相談の窓口でめっちゃ直されました。

運輸局

「1号様式」と「車庫証明（警察でもらう）」と「住民票」と「古い車検証」を出すと「新たな車検証」と「スタンプが押された紙」がもらえます。
古い車検証は没収されます。次は自動車税事務所に行ってねと言われます。建物は隣接しているので楽です。

自動車税事務所

「変更登録の書類」と「スタンプが押された紙」を出すと、スタンプが増えて帰ってきます。
書類は事務所内にあります。旧住所を聞かれますので、どこかにメモしておいた方がいいかも。思い出せる人は問題ないです。

運輸局

「古いナンバー」と「新しい車検証」と「スタンプが押された紙」を出すと「新しいナンバー」をくれます。
関東運輸局は「自分でナンバーを交換する」方式みたいで、自分でナンバーの封印を破壊するのはなかなか出来ない体験です。工具は普通のドライバーです、運輸局で貸してくれます。
ナンバーの封印は思ったよりもヘナヘナしていて、あっさり壊れました。慣れている人は数秒で壊せそうでした。

運輸局

「新しいナンバー」と「車」を運輸局の建物の前に持っていくと「ナンバーの封印」と「新しい車検証」をくれます。
車体番号見るのでボンネット開けてくれっていわれます。封印はおっちゃんが付けてくれます。

ナンバーの封印を付けてもらったら、そのまま車で運輸局からおさらばです。

感想

やってみた感想は「RPGのクエストみたい」です。書類と書類を交換していくと、最後に車検証とナンバープレートが貰えます、みたいな感じですね。車のナンバー（と自動車税）管理の一環が垣間見えて、なかなか面白い社会科見学でした。

個人的にはナンバープレートの封印を破壊するのは、普段やらない体験で「え？自分で壊すの？？」と緊張しました（関東運輸局だけセルフで、他地域ではやらないみたいです）。私の車は粗雑に扱っているせいなのか、フロント側のナンバーのネジが錆びて固着しており、あやうくネジをなめそうでした。次はもう外せないかもしれない。

昨今のコロナ騒ぎのせいか、いずれの窓口もガラッガラに空いていて快適でした。混んでいたら地獄だったと思います。

GCCを調べる - その8-1 - ベクトルレジスタ定義を足す

目次: GCC

前回（2020年3月6日の日記参照）はレジスタ制約（register_constraints）を追加しました。これだけでは何もできませんので、今回はベクトルレジスタの定義を追加してみます。長そうなので分割して書きます。

RISC-Vには汎用レジスタ（GP_REGS）と浮動小数点レジスタ（FP_REGS）が既に定義されているため、それらを参考にします。

変更するファイルはgcc/config/riscv/riscv.c, riscv.hです。FP_REGくらいで検索すると、下記の関数、マクロに名前が見当たりますので、真似して追加します。（詳細は パッチファイルもご覧ください、内容の正しさは全く保証できませんけど）

// gcc/config/riscv/riscv.c

riscv_regno_to_class[FIRST_PSEUDO_REGISTER]  //32個レジスタを足す
riscv_hard_regno_nregs    //どのマシンモードでもレジスタを1つだけ使う、よくわからん、また今度調べる
riscv_hard_regno_mode_ok  //どのマシンモードでも許可する、よくわからん、また今度調べる
riscv_class_max_nregs     //どのクラスでもレジスタを1つだけ使う、よくわからん、また今度調べる


// gcc/config/riscv/riscv.h

FIRST_PSEUDO_REGISTER  //32個分ずれてもらう
FIXED_REGISTERS        //32個足す、今回は0にした、固定された役目（スタックポインタなど）はない
CALL_USED_REGISTERS    //32個足す、今回は0にした（関数呼び出しにより内容を破壊されない、s0 - s11と同じ扱い）

enum reg_class
#define REG_CLASS_NAMES     //新たなレジスタクラスを足す
#define REG_CLASS_CONTENTS  //後述する
#define REG_ALLOC_ORDER	    //レジスタの割当順、レジスタ番号で指定する
#define REGISTER_NAMES      //レジスタの名前
#define ADDITIONAL_REGISTER_NAMES

初歩の初歩的な変更の割に必要な変更点はかなり多いです。どの変更が何に効くか完全にわかっていないので、合っているかわかりませんし、説明し難い変更もあります。後日、要調査ですね。

GCCの2つのレジスタ

変更した中のriscv_regno_to_classをみるとFIRST_PSEUDO_REGISTERというマクロが出てきます。GCCはレジスタを2種類使い分けていて、レジスタ番号で区別できます。

• 物理レジスタ: 0〜 (FIRST_PSEUDO_REGISTER - 1)
• 疑似レジスタ(pseudo register): FIRST_PSEUDO_REGISTERより大きな値

正式な名前がわからない（※）ので、名付けは適当です。GCCはRTLのフェーズで命令の引数にレジスタを割り当てます。その際、いきなりメモリや物理レジスタを割り当てるのではなく、まず疑似レジスタを割り当てます。

疑似レジスタには数の制限がないので、最初の方の最適化パスで必要なだけ割り当てます。その後の最適化パスで物理レジスタや、メモリにうまく割り当てを考える二段構成になっています。

今回は32個の物理レジスタを足そうとしているので、FIRST_PSEUDO_REGISTERにも32個分だけズレてもらう必要があります。

今回の変更の要はREG_CLASS_CONTENTSです。このマクロの効き目についてはまた今度。

（※）GCCのヘンテコなマクロの意味を調べる際、GCC Internals（HTML版へのリンク）が大変参考になるのですが、この文書は用語の説明がイマイチ甘くて、正式な用語がわかりません。いつも困ります……。

GCCを調べる - その8-2 - レジスタとレジスタクラス

目次: GCC

レジスタ追加の変更の要はREG_CLASS_CONTENTSです。このマクロは32ビット整数の配列で、各レジスタ番号がどのレジスタの仲間（enum reg_class）に属するかを指定するテーブルです。こんな風に変更します。

 #define REG_CLASS_CONTENTS						\
 {									\
-  { 0x00000000, 0x00000000, 0x00000000 },	/* NO_REGS */		\
-  { 0xf003fcc0, 0x00000000, 0x00000000 },	/* SIBCALL_REGS */	\
-  { 0xffffffc0, 0x00000000, 0x00000000 },	/* JALR_REGS */		\
-  { 0xffffffff, 0x00000000, 0x00000000 },	/* GR_REGS */		\
-  { 0x00000000, 0xffffffff, 0x00000000 },	/* FP_REGS */		\
-  { 0x00000000, 0x00000000, 0x00000003 },	/* FRAME_REGS */	\
-  { 0xffffffff, 0xffffffff, 0x00000003 }	/* ALL_REGS */		\
+  { 0x00000000, 0x00000000, 0x00000000, 0x00000000 },	/* NO_REGS */		\
+  { 0xf003fcc0, 0x00000000, 0x00000000, 0x00000000 },	/* SIBCALL_REGS */	\
+  { 0xffffffc0, 0x00000000, 0x00000000, 0x00000000 },	/* JALR_REGS */		\
+  { 0xffffffff, 0x00000000, 0x00000000, 0x00000000 },	/* GR_REGS */		\
+  { 0x00000000, 0xffffffff, 0x00000000, 0x00000000 },	/* FP_REGS */		\
+  { 0x00000000, 0x00000000, 0xffffffff, 0x00000000 },	/* VP_REGS */		\
+  { 0x00000000, 0x00000000, 0x00000000, 0x00000003 },	/* FRAME_REGS */	\
+  { 0xffffffff, 0xffffffff, 0xffffffff, 0x00000003 }	/* ALL_REGS */		\
 }
                              ↑ここの3列目を足した

行方向は、ビットフィールドになっており非常にわかりにくいです。0要素目の0ビット目、0要素目の1ビット目、…という順に見ます。整数内では右から左（右が上位ビット）、要素間では左から右（左が0要素目）に見ます。

列方向はenum reg_classの整数値と一致しますのでさほど難しくはないでしょう。

行と列の意味

  →→ 行方向、レジスタ番号（0〜FIRST_PSEUDO_REGISTER - 1まで）
↓
↓
列方向、enum reg_classを整数に直したもの


行方向の見方

例えば3行目（GR_REGS）がこうなっていたとすると、
{ 0x0000000f, 0x0000000c, },

- 0要素目（レジスタ番号0〜31のクラス）: 0x0000000f
  - 0, 1, 2, 3ビット目が1 = レジスタ番号0〜3はGR_REGS
  - 他のレジスタについては言及しない
- 1要素目（レジスタ番号32〜63のクラス）: 0x0000000c
  - 2, 3ビット目が1 = レジスタ番号34〜35はGR_REGS
  - 他のレジスタについては言及しない

ALL_REGSは全レジスタに1をセットしますので、ビットフィールドのルールがわかりやすいと思います。今回はレジスタが98本なので、3要素（32 * 3 = 96）+ 最後の要素は2ビット分だけ1にセットしています。

今回はVR_REGSという新たなレジスタクラスを足したいので、行が一つ増えます。レジスタの総数も増えるので、列方向も増えます。ちょうど良いことに新規に追加するレジスタは32本なので、整数1要素分を増やすだけです。

コード上での扱い

このマクロは直接使用されるわけではなく、別の配列にコピーされます。

// gcc/reginfo.c

static const unsigned int_reg_class_contents[N_REG_CLASSES][N_REG_INTS]
  = REG_CLASS_CONTENTS;

...

/* Function called only once per target_globals to initialize the
   target_hard_regs structure.  Once this is done, various switches
   may override.  */
void
init_reg_sets (void)
{
  int i, j;

  /* First copy the register information from the initial int form into
     the regsets.  */

  for (i = 0; i < N_REG_CLASSES; i++)
    {
      CLEAR_HARD_REG_SET (reg_class_contents[i]);

      /* Note that we hard-code 32 here, not HOST_BITS_PER_INT.  */
      for (j = 0; j < FIRST_PSEUDO_REGISTER; j++)
	if (int_reg_class_contents[i][j / 32]    //★★ここで参照している
	    & ((unsigned) 1 << (j % 32)))
	  SET_HARD_REG_BIT (reg_class_contents[i], j);
    }


// gcc/reginfo.c

struct target_hard_regs default_target_hard_regs;


// gcc/hard-reg-set.h

#if SWITCHABLE_TARGET  //★★x86, ARM, MIPSなどはSWITCHABLE_TARGET = 1, RISC-Vは0のようだ
extern struct target_hard_regs *this_target_hard_regs;
#else
#define this_target_hard_regs (&default_target_hard_regs)
#endif

#define reg_class_contents \r  (this_target_hard_regs->x_reg_class_contents)

難しそうに見えてやっていることはint_reg_class_contentsからdefault_target_hard_regs->x_reg_class_contentsへビットを移し替えているだけです。違いはint_reg_class_contentsが必ず32ビット幅であるのに対し、x_reg_class_contentsはアーキテクチャ最速の整数幅（x86_64なら64bitになるでしょう）である点です。

個人的には可読性を殺してまでやる意味あるの……？と疑問ですが、きっとGCC内で頻繁に呼ばれ速度的に重要なポイントだったのでしょう。

GCCを調べる - その8-3 - レジスタconstraint判定

目次: GCC

インラインアセンブラで "v" constraintsを指定すると、何も実装していない場合はimpossible constraint in 'asm' と怒られました。レジスタのconstraintsだけ足すとinconsistent operand constraints in an asmと怒られるはずです。エラーをチェックしている箇所は、

static bool
curr_insn_transform (bool check_only_p)
{

...

  if (process_alt_operands (reused_alternative_num))  //★★これが成立してalt_p = trueが期待値だが
    alt_p = true;

...

  if (! alt_p && ! sec_mem_p)
    {
      /* No alternative works with reloads??  */
      if (INSN_CODE (curr_insn) >= 0)
	fatal_insn ("unable to generate reloads for:", curr_insn);
      error_for_asm (curr_insn,
		     "inconsistent operand constraints in an %<asm%>");  //★★ここに到達しエラーが出る
      lra_asm_error_p = true;
      /* Avoid further trouble with this insn.  Don't generate use
	 pattern here as we could use the insn SP offset.  */
      lra_set_insn_deleted (curr_insn);
      return true;
    }

...

このcurr_insn_transform() 関数はやたら長くて（700行）訳のわからない構造です。うまく行く場合（rなどを渡したとき）を観察すると、alt_pがtrueになるのが期待値と思われます。幸いなことにalt_pの設定は一箇所だけ、条件もprocess_alt_operands() 関数だけです。

そう思ってprocess_alt_operands() 関数を見ると、これがまたもの凄い実装で、目を覆いたくなります（1200行！！）。GCC見ていると、クソコードには事欠かないです。これはひどい。

コードの一部を抜粋しても全く意味不明で、そもそもこの関数自体がかなりゴチャゴチャで意味不明です。全て追うのは不可能です。なので"r" がどの辺りを通るかをもって、当たりを付けました。下記のところが分岐点になっているようです。

static bool
process_alt_operands (int only_alternative)
{

...

	  do
	    {
              //★★pは "=&v" が入っていて、cに先頭から一文字ずつ取って解析している
	      switch ((c = *p, len = CONSTRAINT_LEN (c, p)), c)
		{
		case '\0':
		  len = 0;
		  break;

...

		default:
		  cn = lookup_constraint (p);  //★★ 'v' に対しては、CONSTRAINT_vが返る
		  switch (get_constraint_type (cn))
		    {
		    case CT_REGISTER:
		      cl = reg_class_for_constraint (cn);  //★★CONSTRAINT_vに対してはVP_REGSが返る
		      if (cl != NO_REGS)
			goto reg;    //★★このジャンプで飛ぶ
		      break;

...

		reg:
		  if (mode == BLKmode)
		    break;
		  this_alternative = reg_class_subunion[this_alternative][cl];
		  this_alternative_set |= reg_class_contents[cl];  //★★どこかでみたreg_class_contentsが登場
		  if (costly_p)
		    {
		      this_costly_alternative
			= reg_class_subunion[this_costly_alternative][cl];
		      this_costly_alternative_set |= reg_class_contents[cl];
		    }
		  winreg = true;
		  if (REG_P (op))
		    {
		      if (hard_regno[nop] >= 0
			  && in_hard_reg_set_p (this_alternative_set,
						mode, hard_regno[nop]))  //★★これが成立しない
			win = true;  //★★少なくともwin = trueにならないと関数が失敗を返す（条件は他にもあるが）
		      else if (hard_regno[nop] < 0
			       && in_class_p (op, this_alternative, NULL))
			win = true;
		    }
		  break;
		}

...

	    }
	  while ((p += len), c);  //★★基本は次の文字に行くが、スキップすることもある模様

どこかでみたアイツです。このエラーはreg_class_contentsを見に行った結末に起きているようです。

試してみたら、色々おかしい

REG_CLASS_CONTENTSを正しく設定すると、下記のコードがコンパイルできるはずです。雰囲気を出すためRISC-Vのベクトル命令を書いていますが、ぶっちゃけコンパイラは命令を全く見ないので、実はabcdでも何でも通ります。コンパイルのみ（*.sを出力）であればアセンブラすら要りません（※）。

// a.c

void _start()
{
	int b[100];
	int v;

	__asm__ volatile ("vlw.v %0, %1\n"
		: "=&v"(v) : "A"(b[10]));
}

ビルドして、逆アセンブルしてみます。

$ riscv32-unknown-elf-gcc -Wall -g -march=rv32gcv -mabi=ilp32f -nostdlib -O2 a.c

$ riscv32-unknown-elf-objdump -drS a.out

a.out:     file format elf32-littleriscv

Disassembly of section .text:

00010054 <_start>:
void _start()
{
   10054:       7165                    addi    sp,sp,-400
        int b[100];
        int v;

        __asm__ volatile ("vlw.v %0, %1\n"
   10056:       103c                    addi    a5,sp,40
   10058:       1207e007                vlw.v   v0,(a5)
                : "=&v"(v) : "A"(b[10]));
}
   1005c:       6159                    addi    sp,sp,400
   1005e:       8082                    ret

それらしきベクトルレジスタ（v0）が出力されているようです。めでたし、めでたし。と言いたいところですが、実は全然ダメです。

• 変数がintなのでsizeof(v) が4になる、ベクトルを扱いたい
• 最適化オプションをO0にするとコンパイラがinternal errorを出す

まだまだ改善の余地があります。これも今後、調べていこうと思います。

（※）もしアセンブルまで実行したければ、RISC-VのGitHubにあるbinutilsを使ってください（GitHubへのリンク）。ビルド方法はUpstreamのコードとほぼ同じ（2019年4月19日の日記参照）です。唯一の違いはconfigure時に --with-system-readlineを付けないと、readlineがないと言われてエラーになる点です。