link もっと前
   2020年 5月 21日 -
      2020年 5月 12日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

link 編集する

さようなら SeaMonkey

かつての Mozilla のころからずっと使っていた SeaMonkey ですが、最近のサイトだと知らない子扱いされて悲しいのと、Cookie の削除がしづらくてたまらないので、ブラウザを Firefox に変えました。

SeaMonkey 今までありがとう。大変お世話になりました。

こんにちは Firefox

ブラウザに限らず、あまりアプリケーションのカスタマイズはしない方ですが、今の Windows 版 Firefox は 1点だけ嫌なところがあります。Ctrl+Tab を押したときにタブの一覧が出る挙動です。

Windows のウインドウ切り替えと似ていますが、ブラウザのタブは元から横一直線に並んでいるので、リストを出す必要はないです。隣のタブに迅速に切り替えてほしい。

調べてみると browser.ctrlTab.recentlyUsedOrder を false にすると Ctrl+Tab を押した瞬間に隣のタブに移る挙動に戻せることを知りました。とても嬉しい。これだよこれ!

[編集者: すずき]
[更新: 2020年 5月 23日 02:45]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

超えろ、新宿駅

Steam で新たなゲームを買いました。2020年 4月ローンチの STATIONflow(開発: DMM GAMES)です。その名の通り地下鉄の駅を作るゲームです。


STATIONflow ロゴ

新宿や渋谷のようなモンスター駅の作り、使いづらさに憤慨したことはありませんか?「使いづらい!俺様に任せればスマートに作ってやる」と思う方はぜひチャレンジしてください。

私もそう思ってたのですが、ゲームをやってみて「思い上がりでした、ごめんなさい、JR さん尊敬してます。」反省しました。油断するとすぐに、客を何度も上り下りさせて、べらぼうに長距離歩かせて、挙句迷子になるクソ駅が爆誕します。

良いところ、嫌なところ

(気に入ったところ)

  • 動作が非常に快適。特に起動が超速くて、ノート PC でも数秒で起動します。Transport Fever 2 は寝そうなくらい遅くて辛かったので、これは嬉しいです。

(気に入らないところ)

  • 今年のゲームの割にグラフィックスがショボい。殺人現場の再現グラフィックみたいに見えます。
  • 操作方法が変。カメラワークも変ですし、一番嫌なのがマップスクロールで、なぜかミドルドラッグです。右ドラッグが普通では?

ゲームはまだ始めたばかりなので、主に操作性の面での感想です。

ゲームシステム紹介

プレイ時間が 10時間未満で、序盤しか体験してませんが、STATIONflow のシステム紹介もしておきます。システムはそんなに難しくないです。

システム紹介: 客の動きと構内案内

マップには地下鉄の改札口と、電車の到着ホームが固定で置かれます。お客さんの行動は基本的に 3つです。

  • 改札←→改札(通過)
  • ホーム←→改札(乗降車)
  • ホーム←→ホーム(乗り換え)

他の交通系ゲームと大きく違う点は、客は「最適経路を知らない」ことです。客は「構内案内」を見て行動します。目的地への経路が存在しても、構内案内を間違えると客は目的地に行けなくて迷います。視界の広さがお客さんによって違い、遠いところに構内案内を置くと、客によっては構内案内を見失って迷います。


駅のホーム、ところどころにある黄色い矢印が構内案内

遠回りで変なシステムに見えますが、よく考えると、すべての客が駅構内の経路を知り尽くしていて、常に最短経路で移動するって変じゃないですか?そんなエスパーみたいな客いませんよね。

正直いって構内案内のメンテナンスはかなり面倒ですが、ゲームとして理不尽にならないレベル(※)で現実に寄せた、素敵なアイデアだと思います。

(※)実世界だと、構内案内をあえて無視して迷う、目の前の構内案内に気づかない、話の通じないクレーマー、など不条理ばかりですが、そんなの再現してもクソゲーにしかなりません。現実に寄せれば良いってものじゃない。

システム紹介: ランクアップと構内施設

乗降客数が増えて、お客さんの不満が少ないとランクアップし、ホームと改札口が勝手に増えます。大抵は予想していない変なところにホームが勝手に増えるので、駅のレイアウトと合わなくなります。つじつま合わせが必要です。ここは腕の見せどころです。

ランクアップに伴い、トイレやレストランなどの構内施設の種類が増えます。エスカレーターしか乗らない高齢客、エレベーターしか乗らない車いす客、などお客さんのバリエーションも増えます。序盤は簡単で、ランクアップによって難易度が段々上がっていく設計に見えます。

ホームと改札の位置はマップにより固定のようです。最後まで進めて最初からやり直せば、綺麗な駅が作れるかもしれません(まだそこまで見てないので断言はできませんけど)。

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

[編集者: すずき]
[更新: 2020年 5月 23日 03:16]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

航空科学博物館を支援

Twitter で「収入ほぼゼロ」「来館者9割減」 危機に陥っている「航空科学博物館」がクラウドファンディングで支援募集 - ねとらぼ、の記事を目にしたので、微力ながら 5,000円を支援しました。後で入場券が 2枚送られてくるそうな。

100万円のコースはさすがに高すぎなのか支援者がまだ現れていませんが、30万円のコースは 3人ほど支援者がいました。愛されていますね。

公営の博物館(公益財団法人 航空科学博物館)は、国や自治体が支援するのが筋だろう、という意見も目にしましたし、言い分はわかるんですが、うだうだ言っている間に潰れてしまっては元も子もないです。クラウドファンディングで助けを求めるのは良い手段だと思います。

[編集者: すずき]
[更新: 2020年 5月 23日 02:56]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

GCC を調べる - その 10-2 - ベクトル型への対応

前回(2020年 3月 27日の日記参照)の調査により、targetm.vector_mode_supported_p() が false を返すことが原因だとわかりました。この関数ポインタが指す先は、アーキテクチャターゲット(ARM とか i386 とか riscv とか)ごとに違います。RISC-V の場合は下記のようにすれば良いです。

vector_mode_supported_p の追加

// gcc/config/riscv/riscv.c

static bool
riscv_vector_mode_supported_p (machine_mode mode)
{
  if (TARGET_VECTOR)  //★★本当は mode の値を確認したほうが良いが、今回は手抜き
    return true;

  return false;
}

...

#undef TARGET_VECTOR_MODE_SUPPORTED_P
#define TARGET_VECTOR_MODE_SUPPORTED_P riscv_vector_mode_supported_p

この targetm もやや魔界感があるので、何でこの define で実装が切り替わるのか、についても調べたいところですね。それはさておいて、上記の実装を追加すると無事ベクトル型が使えるようになります。

追加後の 236r.expand の抜粋

(insn 70 2 69 2 (set (reg:V64SI 105 [ v1 ])  ★★reg:V64SI になっている
        (asm_operands/v:V64SI ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 99 virtual-stack-vars)
                        (const_int -360 [0xfffffffffffffe98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))

バイナリも正しく出力されます。sizeof(v1) も 256 が返されます。ちなみにアセンブルしなくても、オプション -S でアセンブラを見てもほぼ同じです。

追加後のバイナリ
a.out:     file format elf32-littleriscv

Disassembly of section .text:

00010054 <_start>:
   10054:       7165                    addi    sp,sp,-400
   10056:       103c                    addi    a5,sp,40
   10058:       1207e007                vlw.v   v0,(a5)
   1005c:       6159                    addi    sp,sp,400
   1005e:       8082                    ret

良かった良かった。オプション O0 の問題はまた今度です。

[編集者: すずき]
[更新: 2020年 5月 17日 22:42]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

GCC を調べる - その 10-1 - ベクトル型を使うとエラー

以前(2020年 3月 27日の日記2020年 3月 28日の日記2020年 3月 29日の日記参照)ベクトルレジスタを扱えるようにした際に、下記の問題が残っていました。

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

前回(2020年 5月 12日の日記参照)はベクトル型に向けてマシンモードを追加しました。引き続き、1つ目の問題に取り組んでいきたいと思います。

ベクトル型は基本型(SI, DI, SF, DF など)が複数連結されているデータ型です。個数は 2のべき乗(2, 4, 8, 16, ...)でなければなりません、3 個や 10 個はダメです。型は通常 GCC の実装で定義します。ベクトル型も当然同じで GCC の実装で定義しますが、ベクトル型はやや特殊で、GCC の attribute でも定義することができます。今回は attribute を使ってみます。

ベクトル型を使ったコード

typedef int __v64si __attribute__((__vector_size__(256)));

void _start()
{
	int b[100];
	__v64si v1;

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

ベクトル型を使ってインラインアセンブラを書くとエラーが出ます。

ベクトル型を使うと impossible constraint エラー
$ riscv32-unknown-elf-gcc -Wall -march=rv32gcv b.c -O2 -nostdlib -S

b.c: In function '_start':
b.c:7:2: error: impossible constraint in 'asm'
    7 |  __asm__ volatile ("vlw.v %0, %1\n"
      |  ^~~~~~~

このエラーは以前(2020年 3月 6日の日記参照)、register constraint に 'v' を追加したときに解析した部分で見ました。詳細は昔の日記を見ていただくとして、以前との差を示します。

エラーになる箇所

// gcc/recog.c

int
asm_operand_ok (rtx op, const char *constraint, const char **constraints)
{

...

	default:
	  cn = lookup_constraint (constraint);
	  switch (get_constraint_type (cn))
	    {
	    case CT_REGISTER:
	      if (!result
		  && reg_class_for_constraint (cn) != NO_REGS  //★★以前引っかかっていたのはこちら
		  && GET_MODE (op) != BLKmode        //★★今回はこちらの条件に引っかかる
		  && register_operand (op, VOIDmode))
		result = 1;
	      break;

新たなマシンモード V64SImode を追加(2020年 5月 12日の日記参照)を追加したのに、どうして BLKmode が選択されてしまうのでしょう?

オプション --dump-tree-all --dump-rtl-all を付けて、BLKmode が選ばれるタイミングを追うと、パス expand が終わった時点で BLKmode になっていました。

236r.expand の抜粋

(insn 26 7 10 2 (set (mem/c:BLK (plus:SI (reg/f:SI 99 virtual-stack-vars)  ★★mem/c:BLK になっている
                (const_int -1168 [0xfffffffffffffb70])) [1  A128])
        (asm_operands/v:BLK ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 99 virtual-stack-vars)
                        (const_int -872 [0xfffffffffffffc98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))

パス expand は GIMPLE から RTL という中間表現に変換するパスです。RTL に変換した直後から BLKmode ですから、かなり最初の方からダメだってことがわかります。何が悪いかわからないので expand 辺りのコードを探ってみます。

BLKmode になる箇所

// gcc/cfgexpand.c

static void
expand_asm_stmt (gasm *stmt)
{

...

  for (i = 0; i < noutputs; ++i)
    {
      tree val = output_tvec[i];
      tree type = TREE_TYPE (val);
      bool is_inout, allows_reg, allows_mem, ok;
      rtx op;

...

      if ((TREE_CODE (val) == INDIRECT_REF && allows_mem)
	  || (DECL_P (val)
	      && (allows_mem || REG_P (DECL_RTL (val)))
	      && ! (REG_P (DECL_RTL (val))
		    && GET_MODE (DECL_RTL (val)) != TYPE_MODE (type)))
	  || ! allows_reg
	  || is_inout
	  || TREE_ADDRESSABLE (type))
	{

...
	}
      else
	{
	  op = assign_temp (type, 0, 1);  //★★これ
	  op = validize_mem (op);
	  if (!MEM_P (op) && TREE_CODE (val) == SSA_NAME)
	    set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (val), op);

	  generating_concat_p = old_generating_concat_p;

	  push_to_sequence2 (after_rtl_seq, after_rtl_end);
	  expand_assignment (val, make_tree (type, op), false);
	  after_rtl_seq = get_insns ();
	  after_rtl_end = get_last_insn ();
	  end_sequence ();
	}


// gcc/function.c

rtx
assign_temp (tree type_or_decl, int memory_required,
	     int dont_promote ATTRIBUTE_UNUSED)
{
  tree type, decl;
  machine_mode mode;
#ifdef PROMOTE_MODE
  int unsignedp;
#endif

  if (DECL_P (type_or_decl))
    decl = type_or_decl, type = TREE_TYPE (decl);
  else
    decl = NULL, type = type_or_decl;

  mode = TYPE_MODE (type);  //★★これ


// gcc/tree.h

#define TYPE_MODE(NODE) \
  (VECTOR_TYPE_P (TYPE_CHECK (NODE)) \
   ? vector_type_mode (NODE) : (NODE)->type_common.mode)    //★★これ


// gcc/tree.c

/* Vector types need to re-check the target flags each time we report
   the machine mode.  We need to do this because attribute target can
   change the result of vector_mode_supported_p and have_regs_of_mode
   on a per-function basis.  Thus the TYPE_MODE of a VECTOR_TYPE can
   change on a per-function basis.  */
/* ??? Possibly a better solution is to run through all the types
   referenced by a function and re-compute the TYPE_MODE once, rather
   than make the TYPE_MODE macro call a function.  */

machine_mode
vector_type_mode (const_tree t)
{
  machine_mode mode;

  gcc_assert (TREE_CODE (t) == VECTOR_TYPE);

  mode = t->type_common.mode;  //★★このモードは V64SImode になる
  if (VECTOR_MODE_P (mode)
      && (!targetm.vector_mode_supported_p (mode)  //★★この判定文が偽になる
	  || !have_regs_of_mode[mode]))
    {
      scalar_int_mode innermode;

      /* For integers, try mapping it to a same-sized scalar mode.  */
      if (is_int_mode (TREE_TYPE (t)->type_common.mode, &innermode))  //★★256バイトの Int はないから、偽になる
	{
	  poly_int64 size = (TYPE_VECTOR_SUBPARTS (t)
			     * GET_MODE_BITSIZE (innermode));
	  scalar_int_mode mode;
	  if (int_mode_for_size (size, 0).exists (&mode)
	      && have_regs_of_mode[mode])
	    return mode;
	}

      return BLKmode;  //★★BLKmode になってしまう
    }

  return mode;
}

条件式にある targetm.vector_mode_supported_p() が false のため、BLKmode になってしまうようです。

[編集者: すずき]
[更新: 2020年 5月 17日 22:41]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

ノート PC のファンがうるさい

ノート PC(ThinkPad E480)の冷却ファンが回り続けていてうるさいです。特に何かしている訳でもないのに、良い勢いでファンが回ってます。

ここ最近、ノート PC を酷使(ゲーム、在宅勤務など)したため、ファンに埃が詰まって、冷却能力が下がったか?と予想して、頑張って ThinkPad の裏蓋を開けました。しかし思ったほど汚れていません。

どうしてファンが回りっぱなしなんでしょう?純粋に冷却能力が足りないだけなんだろうか??

ThinkPad の裏蓋

ThinkPad E480 の裏蓋はめちゃくちゃ開けにくいです。ネジ 9か所と爪で止まっているので、ネジを緩めた後、マイナスドライバーでこじ開けるしかありません。

爪を外すとき、バキっ!ベキっ!というすごい嫌な音がします。案の定、ヒンジ付近(ノート PC とノート PC ディスプレイが接続されている方)の爪が 4か所ほど折れました。

せっかく裏蓋まで開けたにも関わらず、何も収穫がありませんでした。裏蓋を止める爪が 4か所壊れただけです。相変わらずファンはうるせーし、嬉しくない結末です。
[編集者: すずき]
[更新: 2020年 5月 14日 00:24]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

GCC を調べる - その 9 - マシンモードの追加

以前(2020年 3月 27日の日記2020年 3月 28日の日記2020年 3月 29日の日記参照)ベクトルレジスタを扱えるようにした際に、下記の問題が残っていました。

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

1つ目の問題に取り組んでいきたいと思います。RISC-V 32 の場合、int の変数は 32bit 整数のデータ型として扱われます。GCC 内部の表現(RTL)では SImode というマシンモード(※)で表されます。他の大きさのデータ型を示すマシンモードも当然存在していて 8, 16, 64bit 整数はそれぞれ BImode, HImode, DImode で表されます。

普通の型に対応するモードは GCC が定義済みですが、ベクトル型を表すモードは標準では存在しないため、自分で新規に定義する必要があります。

(※)マシンモード(Machine Mode)については、GCC Internals の 14.6 Machine Modes に簡単な説明と標準的なモードの一覧が載っています。これによれば SI は Single Integer の略らしいです。変な名前だなあ。

マシンモードはどこにある?

以前(2020年 3月 14日の日記参照)説明したとおりですが、軽くおさらいすると、標準的なマシンモードは gcc/machmode.def、アーキテクチャ固有のマシンモードは gcc/config/arch/arch-modes.def にあります。例えば RISC-V なら gcc/config/riscv/riscv-modes.def です。

現在のところ RISC-V 固有のマシンモードは 1つしか定義されていません。

riscv-modes.def

FLOAT_MODE (TF, 16, ieee_quad_format);

このファイルにベクトル型を表すマシンモードを追加します。

riscv-modes.def に追加したモード

VECTOR_MODE (INT, SI, 8);
VECTOR_MODE (INT, SI, 16);
VECTOR_MODE (INT, SI, 32);
VECTOR_MODE (INT, SI, 64);

とりあえず整数(INT, SI)が 8, 16, 32, 64(それぞれ 32, 64, 128, 256 バイト)個連結されているデータ型を想定して作りました。ベクトル型を語る上では浮動小数点型も大事ですが、とりあえず今回は整数型のみを定義しています。

マシンモード追加できたかな

マシンモードを正しく追加できたか確かめる方法は色々あるのでしょうけど、個人的に簡単だと思うのは一旦ビルドしてしまう方法です。

GCC をビルドするとビルド用のディレクトリ(以降 build_gcc と呼びます)に、モードが全部書いてあるヘッダ insn-modes.h が生成されます。生成されたヘッダを検索すれば一発です。

モードが定義されているヘッダ

// gcc/build_gcc/insn-modes.h

enum machine_mode
{
  E_VOIDmode,              /* machmode.def:189 */
#define HAVE_VOIDmode
#ifdef USE_ENUM_MODES
#define VOIDmode E_VOIDmode
#else
#define VOIDmode ((void) 0, E_VOIDmode)
#endif
  E_BLKmode,               /* machmode.def:193 */
#define HAVE_BLKmode
#ifdef USE_ENUM_MODES
#define BLKmode E_BLKmode
#else
#define BLKmode ((void) 0, E_BLKmode)
#endif

...

  E_V32SImode,             /* config/riscv/riscv-modes.def:26 */
#define HAVE_V32SImode
#ifdef USE_ENUM_MODES
#define V32SImode E_V32SImode
#else
#define V32SImode ((void) 0, E_V32SImode)
#endif
  E_V64SImode,             /* config/riscv/riscv-modes.def:27 */
#define HAVE_V64SImode
#ifdef USE_ENUM_MODES
#define V64SImode E_V64SImode
#else
#define V64SImode ((void) 0, E_V64SImode)
#endif

...

新たなマシンモード V64SImode(SI が 64個連結されたデータ型)が追加されたことがわかると思います。コメントにマシンモードの定義されている場所も書かれていて、とても親切です。

ほぼ全域に渡って意味不明コードだらけの GCC では珍しい部類の、わかりやすさ&親切さです。自動生成コードには気を使っているんでしょうか?他のところもこれくらい親切だと嬉しいんですけどねえ。

[編集者: すずき]
[更新: 2020年 5月 13日 21:32]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2020年 5月 21日 -
      2020年 5月 12日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 5/31 01:18

カレンダー

<2020>
<<<05>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント 5件

  • link 20年05月02日
    すずき 「ちょっと調べたところ、コアが焼けると騒ぎ...」
    (更新:05/08 15:43)
  • link 20年05月02日
    すずき 「結構、怖い制御に見えますね&hellip...」
    (更新:05/08 15:23)
  • link 20年05月02日
    hdk 「デスクトップ用のNVIDIA Quadr...」
    (更新:05/07 20:30)
  • link 20年01月27日
    すずき 「詳細は調べていないので、コード中のコメン...」
    (更新:04/18 23:05)
  • link 20年01月27日
    superzeros 「少し気になったのでglibcの履歴を調べ...」
    (更新:04/16 21:07)

最近の記事 3件

link もっとみる
  • link 20年06月01日
    すずき 「[GCC を調べる - その 13-4 - ベクトル命令のオフ] ...」
    (更新:05/31 01:18)
  • link 20年05月31日
    すずき 「[GCC を調べる - その 13-3 - オフセット付きアド] ...」
    (更新:05/30 22:00)
  • link 20年05月30日
    すずき 「[GCC を調べる - その 13-2 - オフセット付きアド] ...」
    (更新:05/30 21:53)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報