はるか昔(2007年6月7日の日記参照)に購入したピアノ音源PMI Boesendorfer 290を現在使っているPCにインストールしました。
当時の日本代理店はクリプトンでしたが、2008年に違う会社に変わったようです。
それはさておき、ソフトは古くても(13年前!)音源自体はインストールでき、音も正常に鳴ります。Windowsの後方互換性は本当に素晴らしいなと思います。しかしアクティベーションだけがどうしてもできなくて困っています。
Boesendorfer 290はインストール時にシリアル番号の入力が必要で、インストール後はアクティベーションが必要です。アクティベーションは各PC固有の番号と紐付いていて、別のPCにインストールしたときは再アクティベーションが必要となります。面倒くさいですね。
アクティベーションをしない状態で使い続けると、インストール後5日間に動かなくなってしまいます。
購入当時はアクティベート画面の「REGISTER NOW」を押せば、オンラインでアクティベーションできましたが、現在このボタンを押すとエラーになります。
アクティベーション用のサイトのURLが変わったのか、ブラウザの接続警告が出ますし、転送先のサイトでは「そんなページは知らない」って言われます。これはひどい。
オンラインがダメならオフラインアクティベーションを試そうと思い「FILL OUT FORM」を押してみましたが、やっぱりダメでした。
エラーメッセージを見てもInternet browserの何がダメかわかりません。当然、ユーザーとしても対処しようがありません。このソフトを開発した人たちも、まさか13年後にアクティベーションする奴がいるとは思っていなかったでしょう。
これ以上どうにもならないので、サポートに連絡することにしました。Boesendorfer 290の販売はNative Instruments社、開発はEastWest社とありますが、どこに連絡すれば良いかわかりません。とりあえず販売Native Instruments社のサポートに連絡してみようと思います。
目次: Kindle
割と昔からですがKindle Fireがストアで買った本を認識しない(ダウンロードしない、一覧に出てこない)病気が頻発し、買ったはずの本が消えて、非常に困っています。
Kindle Fireがロストした本は、Kindle for PCだとあっさり捕捉できますから(「新しい商品」順に並べると確認しやすい)、Kindle Fireのバグだと思われます。
根本対策は不明ですが、対症療法はいくつかあります。お手軽な順に、
Kindleストアも割と曲者で、複数のダウンロードボタンがある変な仕様(2018年11月17日の日記参照)です。1回押してダメでも諦めず、他の種類のダウンロードボタンも押してください。どれかが成功すればラッキーです。
最終手段ファクトリリセットには1度だけお世話になりました。しかし再設定、再ダウンロードにかなり時間を浪費して辛いので、できればもう二度とやりたくありません。
Kindle Fireはちょっと変な挙動が多いです。仕様かバグか良くわからないものもあります。
Kindleのメインであるはずの本の機能さえ、この有様なので、本以外(アプリ、ミュージック、ムービーなど)の機能は一体どうなっていることやら??
メモ: 技術系の話はFacebookから転記しておくことにした。大幅に追記。
目次: GCC
FSF (Free Software Foundation) のCopyright Assignmentにサインしてみました。とりあえずGCCとbinutilsです。ツールチェーン仲間としてはglibcもやっておけば良かったかも??まあいいか。
手続きは特に難しくなく、
これで完了です。
FSFからの返事はそれぞれ数日〜1週間程度、という感じでした。GNUのソフトウェアにパッチを送りたいときは、個人でこの契約を交わす(今回はこっち)か、会社の業務で作成している場合は、会社でこの契約を交わす(こっちのやり方は知らない)必要があります。
FSFがなぜこんな面倒なことをしているのかについては、なぜFSFは貢献者に著作権の譲渡をお願いしているのか - GNUプロジェクトに書いてあります。過去に訴えられたり何か嫌なことがあったんでしょうね。
テンプレートは Copyright Papers (Information for Maintainers of GNU Software) を見るとGNUのメンテナーに要求してくれと書いてあります。gnulibのリポジトリにも入っていて、私はこのファイルを送ったらOKでした(gnulibのgitリポジトリにあるrequest-assign.future)
FSFのCopyright Assignmentにはいろいろ書いてありますが、
読んでいると割と怖い内容ですが、会社で書いたコードを投稿しなければ問題はないです。
契約の範囲はソフトウェア毎(GCC, binutils, glibc, などなど)に契約する必要があります。契約の種類は「1回限り(request-assign.changes)」と「今後ずっと(request-assign.future)」があります。ソフトウェアを改善し続ける場合、毎回契約するのは面倒なので「今後ずっと」を選択すると思います。
契約の種類によってFSFに送るメールのテンプレートが異なります。詳細は Copyright Papers (Information for Maintainers of GNU Software) に書いてあります。和訳ないのかなあ、これ。
目次: GCC
以前(2020年5月24日の日記参照)、変数の代入操作をexpandで展開する際、代入を分割するか分割しないか、を決める条件の1つとして、optab_handler() という関数が出てきました。この関数の動作に関わるgenopinitというツールの動作を調べます。
前回(2020年6月3日の日記参照)は分岐条件に関わるenum optab_tagの生成について調べました。今回はもう少し複雑なpats[].scodeの生成について調べます。
突然pats[].scodeと言われても何だかわからないと思います。私もこんなひどい名前の変数、全く覚えられません。復習も兼ねてoptab_handler() を見直します。
// gcc/optabs-query.h
/* Return the insn used to implement mode MODE of OP, or CODE_FOR_nothing
if the target does not have such an insn. */
inline enum insn_code
optab_handler (optab op, machine_mode mode)
{
unsigned scode = (op << 16) | mode; //★★scodeの意味はここにある通り
gcc_assert (op > LAST_CONV_OPTAB);
return raw_optab_handler (scode); //★★これ
}
// build_gcc/insn-opinit.c
enum insn_code
raw_optab_handler (unsigned scode)
{
int i = lookup_handler (scode); //★★これ
return (i >= 0 && this_fn_optabs->pat_enable[i]
? pats[i].icode : CODE_FOR_nothing);
}
static int
lookup_handler (unsigned scode)
{
int l = 0, h = ARRAY_SIZE (pats), m;
while (h > l)
{
m = (h + l) / 2;
if (scode == pats[m].scode) //★★これ
return m;
else if (scode < pats[m].scode) //★★これ
h = m;
else
l = m + 1;
}
return -1;
}
//★★pats[] の定義
struct optab_pat {
unsigned scode;
enum insn_code icode;
};
static const struct optab_pat pats[NUM_OPTAB_PATTERNS] = {
{ 0x010405, CODE_FOR_extendqihi2 },
{ 0x010406, CODE_FOR_extendqisi2 },
{ 0x010407, CODE_FOR_extendqidi2 },
{ 0x010505, CODE_FOR_extendhihi2 },
...
{ 0x021c1b, CODE_FOR_truncdfsf2 }, //★★この変な数字(scode)0x021c1bは誰が作るのか?
...
コードからscodeの意味、上位16ビットがoptabで、下位16ビットがmachine mode、は理解できると思います。patsにはscodeが無数に並んでいますが、この数字を誰が作るかというとgenopinitです。
前に見たoptabsの定義は色々ありますが、必ず2つ以上の引数を取り、1番目がname(mov_optab, trunc_optabなど)、2番目がpatternとなっており、この2つは全ての定義に存在します。
// gcc/optabs.def
OPTAB_CL(trunc_optab, "trunc$b$a2", TRUNCATE, "trunc", gen_trunc_conv_libfunc)
'-- name `-- pattern
このうちnameはenum optab_tagの変数名として使っていました。その他にもcode_to_optab_[] という配列の定義にも使いますが、今はどうでもいいです。前後に文字が付くくらいで、基本的に名前がそのまま使われます。
一方2番目のpattern(例えば "mov$a", "trunc$b$a2" など)はちょっと変わっています。$aや $bという不思議な文字が入ります。
前回説明したとおりgenopinitの入力はgcc/common.md, gcc/config/riscv/riscv.md, build_gcc/insn-conditions.mdの3つの *.mdファイルです(mdはmachine descriptorの略)。Lispっぽい記法で、define_insnやdefine_expandを追加したファイルです。
基本的なgenopinitの動作は、
パターンマッチのコードはこんな感じです。
// gcc/gensupport.h
/* Information about an .md define_* rtx. */
class md_rtx_info {
public:
/* The rtx itself. */
rtx def;
/* The location of the first line of the rtx. */
file_location loc;
/* The unique number attached to the rtx. Currently all define_insns,
define_expands, define_splits, define_peepholes and define_peephole2s
share the same insn_code index space. */
int index;
};
// gcc/genopinit.c
int
main (int argc, const char **argv)
{
...
if (!init_rtx_reader_args_cb (argc, argv, handle_arg)) //★★ *.mdを解析
return (FATAL_EXIT_CODE);
...
/* Read the machine description. */
md_rtx_info info;
while (read_md_rtx (&info)) //★★RTXを1つずつ取り出す
switch (GET_CODE (info.def))
{
case DEFINE_INSN: //★★define_insn, define_expandだけ注目
case DEFINE_EXPAND:
gen_insn (&info); //★★これ
break;
static void
gen_insn (md_rtx_info *info)
{
optab_pattern p;
if (find_optab (&p, XSTR (info->def, 0))) //★★これ
patterns.safe_push (p);
}
// gcc/gensupport.c
bool
find_optab (optab_pattern *p, const char *name)
{
...
/* See if NAME matches one of the patterns we have for the optabs
we know about. */
for (unsigned int pindex = 0; pindex < ARRAY_SIZE (optabs); pindex++) //★★全てのpatternを試す
{
p->m1 = p->m2 = 0;
if (match_pattern (p, name, optabs[pindex].pattern)) //★★これ
{
p->name = name;
p->op = optabs[pindex].op;
p->sort_num = (p->op << 16) | (p->m2 << 8) | p->m1; //★★scodeを作る
return true;
}
// gcc/gensupport.h
/* Information about an instruction name that matches an optab pattern. */
struct optab_pattern
{
/* The name of the instruction. */
const char *name;
/* The matching optab. */
unsigned int op;
/* The optab modes. M2 is only significant for conversion optabs;
it is zero otherwise. */
unsigned int m1, m2;
/* An index that provides a lexicographical sort of (OP, M2, M1).
Used by genopinit.c. */
unsigned int sort_num;
};
申し訳ないですが *.mdファイルの解析関数init_rtx_reader_args_cb(), read_md_rtx() 辺りは調べる予定がありません。どなたか調べてくれたら嬉しいです。
パターンマッチはnameに対して行われ、全てのpatternとマッチするか試します。マッチしなければmatch_pattern() はfalseを返しますから、次のpatternを試します。マッチしたら、結果はoptab_pattern *pに格納され、match_patter() が作り出すp->m1, p->m2という謎の数からscodeが生成されます。
なぜgenopinitではsort_numという変数名にしたんでしょうね?scodeにすればもう少しわかりやすいのに。
パターンマッチのルールと、m1, m2が何者か?については、文章で説明できる気がしないので、例としてname = "truncdfsf2" を見ながら説明したいと思います。マッチするpatternは "trunc$b$a2" です。他のpatternはマッチしません。
// gcc/config/riscv/riscv.md
//★★nameの例
(define_insn "truncdfsf2" ★★名前
[(set (match_operand:SF 0 "register_operand" "=f")
(float_truncate:SF
(match_operand:DF 1 "register_operand" " f")))]
"TARGET_DOUBLE_FLOAT"
"fcvt.s.dt%0,%1"
[(set_attr "type" "fcvt")
(set_attr "mode" "SF")])
// gcc/optab.def
//★★ マッチするpatternの定義部分(2番目の引数)
OPTAB_CL(trunc_optab, "trunc$b$a2", TRUNCATE, "trunc", gen_trunc_conv_libfunc)
// gcc/gensupport.c
//★★
//pは結果格納用の変数
//name = "truncdfsf2"
//pat = "trunc$b$a2"
static bool
match_pattern (optab_pattern *p, const char *name, const char *pat)
{
...
★★match_pattern() がtrueを返した後、find_optab() がreturn trueで終了する直前でダンプ (gdb) p optabs[pindex] $13 = { name = 0x4574b5 "trunc_optab", pattern = 0x4574c1 "trunc$b$a2", base = 0x4574cc ""trunc"", suffix = 0x457478 "'\0'", libcall = 0x4574d4 "gen_trunc_conv_libfunc", op = 2, fcode = TRUNCATE, rcode = UNKNOWN, kind = 1 } (gdb) p/x *p $15 = { name = 0x4dd270, op = 0x2, m1 = 0x1b, m2 = 0x1c, sort_num = 0x21c1b } pは結果格納用のoptab_pattern *p
この定義のpatternは2番目の引数 "trunc$b$a2" です。全部繋がっていてわかりにくいですが、下記の4つの要素から構成されます。
このうち $aや $bはmachine modeの名前にマッチします。具体的には下記のようになります。
nameとpatが name = "truncdfsf2" pat = "trunc$b$a2" の場合、 $b -> df $a -> sf にマッチします。$a, $bのマッチを調べるときはmode_nameを先頭から検索(大文字小文字の違いは無視)します。 全モードの名前はmode_name[] という配列に入っています。 $bはmode_name[28] = "DF" と一致する。 $aはmode_name[27] = "SF" と一致する。 match_pattern() は一致したモードの番号をm1, m2に格納します。 つまりoptab_patternのm1, m2の意味はそれぞれ m1: $aがマッチしたモードのインデックス、今回だと27 = 0x1b (E_SFmode) m2: $bがマッチしたモードのインデックス、今回だと28 = 0x1c (E_DFmode) 結果scodeはこうなります。 p->sort_num = (p->op << 16) | (p->m2 << 8) | p->m1; = (2 << 16) | (28 << 8) | 27; = 0x21c1b // build_gcc/insn-opinit.c static const struct optab_pat pats[NUM_OPTAB_PATTERNS] = { ... { 0x021c1b, CODE_FOR_truncdfsf2 }, //★★この値が生成された
謎のpats[].scodeはこんな仕組みで生成されていたのでした。ややこしいですね。
目次: GCC
以前(2020年5月24日の日記参照)、変数の代入操作をexpandで展開する際、代入を分割するか分割しないか、を決める条件の1つとして、optab_handler() という関数が出てきました。optab_handler() の動作を決めるgenopinitというツールの動作を調べます。
バイナリはbuild_gcc/build/genopinitに生成されます(以降build_gccはGCCのビルドディレクトリを指すものとします)。実行する際の引数は下記の通りです。
# build_gcc/Makefile
s-opinit: $(MD_DEPS) build/genopinit$(build_exeext) insn-conditions.md
$(RUN_GEN) build/genopinit$(build_exeext) $(md_file) \
insn-conditions.md -htmp-opinit.h -ctmp-opinit.c
# ビルドログ
build/genopinit ./gcc/gcc/common.md ./gcc/gcc/config/riscv/riscv.md \
insn-conditions.md -htmp-opinit.h -ctmp-opinit.c
上記のビルドログでは一時ファイルに出力していますが、最終的にはbuild_gcc/insn-opinit.h, build_gcc/insn-opinit.cの2つのファイルを生成します。
前回はoptab_handler() にブレークポイントを設定するため、enum optab_tagの値を使いました。この値はgenopinitが生成しています。
// gcc/optabs-query.h
/* Return the insn used to implement mode MODE of OP, or CODE_FOR_nothing
if the target does not have such an insn. */
inline enum insn_code
optab_handler (optab op, machine_mode mode)
{
unsigned scode = (op << 16) | mode; //★★以前はop = mov_optab, mode = E_V64SImodeでブレークを掛けた
gcc_assert (op > LAST_CONV_OPTAB);
return raw_optab_handler (scode); //★★次回以降、調べます
}
// build_gcc/insn-opinit.h
enum optab_tag {
unknown_optab,
sext_optab,
...
mov_optab, //★★この値のこと
...
};
...
typedef enum optab_tag optab;
これらの値はgensupport.cのoptab_defから生成されています。実際にoptab_defの中身を定義するのはoptabs.defファイルです。この *.defファイルは、C言語で素直に書くと重複、冗長になる情報を簡潔に表すための、いわゆるDSL(Domain Specific Language)だと思われます。
DSLっぽいものを使うとき、下記のような邪悪なincludeの使い方をします。GCC凶悪デザインパターンの1つですね。良い子は真似してはいけません。
// gcc/gensupport.c
#define OPTAB_DC(o, p, c) { #o, p, NS, ZS, NS, o, c, c, 4 },
#define OPTAB_D(o, p) { #o, p, NS, ZS, NS, o, UNKNOWN, UNKNOWN, 4 },
...
/* An array of all optabs. Note that the same optab can appear more
than once, with a different pattern. */
optab_def optabs[] = {
{ "unknown_optab", NULL, NS, ZS, NS, unknown_optab, UNKNOWN, UNKNOWN, 0 },
#include "optabs.def" //★★上記のようにoptabs.def内で使われるマクロを、都合の良い定義に変えてからinclude
};
// gcc/optabs.def
OPTAB_DC(mov_optab, "mov$a", SET) //★★マクロの定義はincludeされる場所によって違うので、展開後の結果は場所による
OPTAB_DC(movstrict_optab, "movstrict$a", STRICT_LOW_PART)
OPTAB_D (movmisalign_optab, "movmisalign$a")
...
// gcc/genopinit.c
int
main (int argc, const char **argv)
{
...
/* Emit the optab enumeration for the header file. */
fprintf (h_file, "enum optab_tag {\n");
for (i = j = 0; i < n; ++i)
{
optabs[i].op = i;
fprintf (h_file, " %s,\n", optabs[i].name); //★★optabsの名前を出力
if (optabs[i].kind != j)
last_kind[j++] = i - 1;
}
fprintf (h_file, " FIRST_CONV_OPTAB = %s,\n", optabs[last_kind[0]+1].name);
...
せっかくDSLっぽいものがあるのに、genopinitのようにコード自動生成ツールも混ぜて使うのはどうしてなんでしょう?GCCは理解不能です。
< | 2020 | > | ||||
<< | < | 06 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | - | - | - | - |
合計:
本日: