コグノスケ


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

link もっと前
2020年5月18日 >>> 2020年5月9日
link もっと後

2020年5月18日

航空科学博物館を支援

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

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

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

編集者:すずき(2020/05/23 02:56)

コメント一覧

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



2020年5月17日

GCCを調べる - その10-2 - ベクトル型への対応(TARGET_VECTOR_MODE_SUPPORTED_P追加編)

目次: GCC

前回(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の問題はまた今度です。

編集者:すずき(2023/09/24 11:49)

コメント一覧

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



2020年5月16日

GCCを調べる - その10-1 - ベクトル型を使うとエラー(TARGET_VECTOR_MODE_SUPPORTED_P追加編)

目次: GCC

以前(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になってしまうようです。

編集者:すずき(2023/09/24 11:49)

コメント一覧

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



2020年5月13日

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

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

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

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

ThinkPadの裏蓋

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

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

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

コメント一覧

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



2020年5月12日

GCCを調べる - その9 - ベクトル型用マシンモードの追加

目次: GCC

以前(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では珍しい部類の、わかりやすさ&親切さです。自動生成コードには気を使っているんでしょうか?他のところもこれくらい親切だと嬉しいんですけどねえ。

編集者:すずき(2023/09/24 11:48)

コメント一覧

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



2020年5月11日

ヤマザキ春のパン祭り

今年のヤマザキ春のパン祭りは、2枚もゲットできました。


2020年、春のパン祭りの戦利品

去年は品川勤務かつコンビニ昼飯がメインだったので、ヤマザキパンを買う機会がほぼなく、お皿をもらえるほど点がたまりませんでした。今年はCOVID-19による在宅勤務で、近所のスーパーでパンを買う機会が大幅に増えたため、2枚も手に入ったわけです。在宅勤務の意外な効果です。

コンビニに行かない人にとっては意外かもしれませんが、コンビニはヤマザキパンをほとんど置いていません。自社のプライベートブランドのパンばかりです。10年位前は他社のパンも置いていたんですが、今やコンビニは9割方がプライベートブランドのパンです。

コンビニのプライベートブランドのパンは、大手メーカー(ヤマザキパン、敷島製パン、フジパンなど)が作っていますが、コストの都合か何だか知りませんが、味に劣る気がします。好みの問題なのかな……?

強化ガラス

パン祭りのお皿、裏側に何か書いてるなーと思って写真を撮ってみました。


お皿の裏の説明

ちょっと見づらいので文字に起こすと、

ARTICLE YAMAZAKI
MADE IN FRANCE

ZENMEN
BUTSURIKYOUKA
GARASU

「全面物理強化ガラス」ってローマ字で書いてありますね。フランス製なのに何でローマ字?フランス語で書かれても読めないから?

見ていて素朴な疑問が沸きました。あえて「全面」と強調する理由はなんでしょうね?皿のように厚みのない製品で「片面」物理強化ガラスにすることは可能?可能だったとしてもやる意味がある?

編集者:すずき(2020/05/13 23:29)

コメント一覧

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



2020年5月10日

Pythonの変なAPI

Pythonの文字列置換は "string".replace() ですが、正規表現ライブラリreだと、なぜかre.sub() です。同じ機能なのに、APIの名前も、引数の指定順序も違います。どうしてこうなった。

改定の度に魔界化するC/C++ に比べると、Pythonは明瞭に思えます。とはいえPythonも何だかんだ長い歴史ですし、祓いきれない闇があるんでしょうねえ。

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

編集者:すずき(2020/05/13 21:44)

コメント一覧

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



2020年5月9日

Kindle for PCはダウンロードが遅い?

目次: Kindle

KindleのアプリはKindle Fire版、Android版、PC版など、いくつか種類があります。普段使っているのはKindle FireとKindle for PCです。どうもKindle for PCのダウンロードが遅い気がします。

Kindle Fireも決して速いとは思いませんが、大抵はマンガ1冊が1〜2分でダウンロードできているので、5Mbpsくらいは出ているんじゃないかと思います。

Kindle for PCはかなり遅い(1〜2Mbpsくらい、日によって違う)です。同じネットワークを使っているのに、差が出るものですかね?PC向けだけ帯域ケチるとか、そんな面倒なことしないよなあ?うーん?

Kindleアプリの動きがまた変わったけど、いつもどこかがダメ

Kindle Fire HDのアプリはたまにアップデートされて動きが変わります。今年の頭くらいだったか?覚えてないですけど、また動作が変わりました。

良くなったところ
フィルター「すべて」を選択したとき、本が多すぎると、数十秒フリーズしたり、アプリがクラッシュするバグが直ったこと
悪くなったところ
本のグループが意図せず表示されてしまうバグが埋め込まれたこと

新たなバグは再現率100%です。再現方法も簡単です。

  • ホーム → 「本」のタブ → すべての本を表示、をタップ
  • 本の一覧が表示される
  • グループ化された本をタップ(マンガの1〜最新巻までをグルーピングする機能)を選択
  • ホームボタンでホームへ → 「本」のタブ → すべての本を表示、をタップ
  • 先ほど見ていたグループ化された本が表示される(バグ)

この順に操作したとき、本来は本の一覧が出なければなりませんが、グループ化された本が再表示されてしまいます。明らかにバグってます。

このバグは、ユーザー側の操作で回避可能です。

  • グループ化された本が意図せず表示される(バグ)
  • ホームボタン「ではなく」戻るボタンでホームに戻る
  • もう一度、すべての本を表示、をタップ
  • 本の一覧が表示される

ユーザーの操作に影響が出るバグですし、テスターに触らせたら数分で見つけそうなのにね?KindleってUIのテストしてないのかなあ??

編集者:すずき(2021/12/08 03:49)

コメント一覧

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



link もっと前
2020年5月18日 >>> 2020年5月9日
link もっと後

管理用メニュー

link 記事を新規作成

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

最近のコメント20件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」
  • link 24年1月24日
    すずきさん (02/13 11:48)
    「ありがとうございます。\n私のPCはもう...」
  • link 24年1月24日
    えはらさん (02/12 15:00)
    「Powershellのスクリプトは以下の...」
  • link 24年2月2日
    すずきさん (02/02 18:17)
    「サーバー側の設定はとても簡単でした。ちょ...」
  • link 24年2月2日
    hdkさん (02/02 08:54)
    「さくらのレンタルサーバの設定でLet's...」
  • link 24年1月24日
    すずきさん (01/28 11:35)
    「ご指摘ありがとうございます。確かに間違っ...」
  • link 24年1月24日
    通りすがりさん (01/27 14:05)
    「Powershellで解決しなかったのは...」
  • link 23年11月29日
    すずきさん (12/04 00:38)
    「あ、そうか。1nsですね。ありがとうござ...」
  • link 23年11月29日
    hdkさん (12/03 18:49)
    「>(本来1usなのに1msになって...」
  • link 23年11月29日
    すずきさん (12/03 00:35)
    「大山先生、お久しぶりです。コメントありが...」
  • link 23年11月29日
    大山恵弘さん (12/02 18:53)
    「すずきさんのX(旧Twitter)へのポ...」
  • link 20年7月12日
    すずきさん (10/19 11:17)
    「ご指摘ありがとうございます。9月の編集は...」
  • link 20年7月12日
    通り縋りさん (10/18 19:08)
    「上の記事2023年9月編集という事ですが...」
  • link 23年9月22日
    すずきさん (09/23 21:14)
    「そうなんですよ。賢いなーと思って自分でも...」
  • link 23年9月22日
    hdkさん (09/23 14:56)
    「+1だから、繰り上がる時は必ず下のほうに...」
  • link 23年9月2日
    すずきさん (09/06 18:21)
    「dアカウント自体はMNPと関係なく存在す...」

最近の記事3件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
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 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

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

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20