コグノスケ

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版へのリンク）が大変参考になるのですが、この文書は用語の説明がイマイチ甘くて、正式な用語がわかりません。いつも困ります……。

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

目次: 車

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

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

手続きの概要

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

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

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

詳細な手続き

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

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

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

管轄の警察

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

管轄の警察

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

市役所

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

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

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

運輸局

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

自動車税事務所

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

運輸局

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

運輸局

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

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

感想

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

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

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

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ってちょっとしたことでも、ものすごく複雑にできていて、読むのが辛いというか、読んでも意味不明なことが多いです。うーん、辛い。