はじめてのにき(2012-04)

2012-04-09

_ boost context

http://partake.in/events/313b563f-acf7-47b9-908c-ee0461b77fc0

に行った。

@ytomino さんが boost_fcontext_align で -16 しているとさわいでいたので読んでいた。ごにょごにょと読んでいた結果として、これを読んでるコードは ss_base のアラインにしか使われておらず、これは確保した直後のメモリ領域をアラインする用途にしか使われてないから 16B ほど無駄な領域がある程度で無害なんじゃ、と思った。

なんかうさんくさいコードがあるとそのコードを読むわけで、うさんくさいコードを残しておくと他の人のコードリーディングをうながせるので素晴らしい、という持論が証明された感じである。 github とかにコード上げる人はうさんくさいポイントを残しておくといいよ! とアドバイスしたい。

x86-64 が読めない、ということだったけど、 @ytomino さんほどの方からすればそんなわけがなくて、単に引数の順が素頓狂だ、というだけ覚えておけば良いと思っている。どうせアセンブリを読んでる時は付近に printf があるわけで、その printf に渡ってる変数を信じると良いと思う。つまり、 printf の直前で文字列引数を入れているレジスタが %rdi = 第一引数であり、フォーマットにあったものをつっこんでるところが第二引数 = %rsi である。

そのへんのコードを何度か書いただけあって、僕個人としては、 RDI RSI RDX RCX R8 R9 という順はなんとなく覚えてる (@ytomino さんに適当に言った順があっていることに僕自身驚いた) ものの、まぁこんなもん当然のことながら長期的に覚えれるわけなくて、まぁ付近の printf を探すのが良いと思っています。 printf が無ければ単に「その付近の GCC が生成したコードは正しく引数渡しをしている」と仮定すれば良い。

そもそも x86-64 が真に難解なのはもちょいややこしいケースの引数渡し ABI と、バイナリに落としていてアセンブリを見にくいとか、アセンブリが信じれない時の rex prefix に入ってるレジスタの上位ビットであって、そうでなければ僕的にはわけわからん 0x4(%esp) とかのオフセットを把握しないといかん x86 より読みやすい。 GCC が x86 で push/pop で引数を渡すようになるオプションを用意してくれればなぁ…とか思うくらいに。あーあと stack のアラインはちゃんとやってくださいね、って程度。そいう意味で boost_fcontext_align はぱっと見どう見てもアライン気をつけてなくて気になったけど今回は関係ない…

変数無しで 1 から n までの変数を合計するという問題を考えたり。個人的には libc に依存した時点でなんか複数解候補が思いついたので、 libc を封印して解けるだろーと考えてたものの、なかなか思いつかなかった。というのは色々方法はあるものの、 libc 許すと getenv/setnev あたりで自明以外の何者でもない解があるわけだよね。未だに考えている。

見せてもらった開発が終わった iOS アプリが普通に面白かった。国名言われて場所を当てるみたいなの。国名ってごく最近全部覚えたんだけど、ずいぶんと忘れてしまった(僕の記憶というのは実装が悪いらしく、一時期 196/196 だった http://www.sporcle.com/games/g/world が今ではたぶん 100/196 程度だろうとおもう) というのもあるけど、それ以前にモンゴルとか言われて場所正確に示すのが案外むずくて面白かった。

記憶と言えば putty の coroutine の話が出て、あれってかなり壊れた時系列を持っていて、

2005-06-28: 自分自身でポータブルなコルーチンライブラリが書けた! と喜ぶ http://d.hatena.ne.jp/shinichiro_h/20050628#1119942495 (しかし今見ると __LINE__ じゃなくて boost.pp 使ってるんだな…)
2006-11-23: kikx さんに教えてもらって、 C のマクロでコルーチン的なものが作れると教えてもらって喜ぶ http://shinh.skr.jp/m/?date=20061123#c04
2010-06-03: このスライド (http://d.hatena.ne.jp/shinichiro_h/20100603#1275573793a) を書いてる最中に、あれ紹介されたもののきちんと読んでないなーと思って、ちゃんと読んでるうちに、なんかこれに似たコード書いたことあるなーと 2005 年に書いたコードを思い出す

という感じだった。こういう時に忘れっぽいのは本当に幸せなことだと思う。

context 的に僕が言いたいのはとにかく、いいかげんデバッグについて真面目に考えやがれクソ boost って話で、 C/C++ ってヤツはいいかげんデバッガとやりとりする API を真剣に標準で用意してほしい。つまり context を作るコードなんて誰でも(少なくともちょっと勉強すれば)書けるわけだけど、しかしサーバアプリとかで context がからみあってそれがデバッグできるんですか、っていう。

プログラマはデバッグの時間をマジメに考えれバカってのは本当にマトモでかつ残念なくらい意識されてないアドバイスで、少なくとも君が8時間労働なら8時間コードを書くのは君の健康にとって間違いなく悪い。「オマエが限界のパフォーマンスでコードを書いた場合、その2倍の時間がデバッグに必要である」っていう (たしか ken thompson の) 認識は悲しいくらい正しくて、多くともオマエがコードを書ける時間ってのは3時間程度しか確保できないんだという覚悟が必要だと思う。それ以上働く必要があるなら雇用体制に問題があるのであって、断じて働くべきでない。

という余談はともかく、少なくともコード書いてる以上の時間をデバッグに費してるんだから、コード以上にデバッグに言語標準におかれましてはマジメに考えて欲しい、ってのは最近壊れたオモチャのように繰り返し言っている。最近本当にそれしか主張してない気すらする。 POSIX てヤツはこのへんのサポートが windows より遅れまくってるっていう認識で、しかし最近は pthread_setname とかいうのがいつのまにかできてて、 gdb はこの値ちゃんと表示してて、まぁ少しずつマシになってて感心ではある。 pthread_create が stacktrace を保持するのも近いと思う。まぁそのへん無視して context とか言ってもキチガイ(褒め言葉ではあるが)以外誰も使わない気しかしないんだよなぁ。

予想以上に疲れが溜まってたらしく、飲み会でぐっすり寝てた。いつものことながら大江戸線は本当にありえんくらい遠くてムカつく上に、飯田橋からだと乗り換えまで必要で絶望的。しかし行く時は乗り過したのに帰る時はきちんと乗り換えできたりして、酔っ払いの挙動というのは謎ですね…

(00:46)

_ おもいだしたようにマラソンメモ

https://www.e-run.jp/v-marathon/index.html

に3月半ば頃に参加した。リアルマラソンである。

僕のマラソン歴というのは

中学校まで: サッカーとかラグビーとかやってた関係で、結構走ってるはず。遅かったけど。
7年くらい前?: バイト先の人に誘われて山梨を走る。高低差デカくてしんどかった。たぶん 70mins/10km くらい。
今回: 60mins/10km をわずかに下まわる。途中まで android で速度確認してて1時間で走り切るのは無理だなーと思ってたんだけど何故か…

という感じで、まぁ要するに全然走ってない。まぁいきなり 10km 走った割には案外速かったな…という印象。中学校まででそれなりに使ったせいか、足は割と強いようである…

なんか普段着で走ってて、他にそんな人がいなかったのですごい不自然だった気がする。普段着で走ってたから 2,3km くらい走ったあたりで帰りたくなってそのまま帰ろうか…っていう衝動が強かった。

(01:08)

_ ウテナ

を光栄にもウテナの登場人物をプロジェクト名にした残念な人に借りて見てた。

これはすごい面白いですね…

(02:47)

本日のツッコミ(全5件) [ツッコミを入れる]

_ yt [昨日はありがとうございました。随分買い被りで、私のアセンブラの知識はcmovが登場したあたりから既に時代について..]

_ shinh [ABI はなんか VC で違うってのと、 SysV ABI は何故か RAX に SSE レジスタ数入れるってのもあ..]

_ Rui [RAXに引数の浮動小数点数の個数を渡すのはva_argsを呼ぶときのレジスタを保存するオーバーヘッドを減らすためっぽ..]

_ shinh [あーそうなんですね。よくわからずいじってたのがよくわかりますね。 TCC は必ず RAX 入れてるぽいですし…ところ..]

_ Rui [XMMて16個あるんじゃなかったっけ？と思ったんですが引数渡しにつかうのはXMM0~7だけでしたね・・。RAXはやっ..]

2012-04-20

_ GSL

おい Z が RO16 で絶滅かよ…

雰囲気的に P がこの世の春という感じだけど、まだ PT の人数は同じなんだよな…

僕の感覚では Pimba っていうよりかは T の強みに対して P が適切な対処をするようになって、 T が似たようなことばっかやってるから今の状況になったという気がしている。がまぁ P 使いの欲目かもしれぬ

(01:43)

[ツッコミを入れる]

2012-04-22

_ nacl-mounts

使い方かわったようだ。

これだろうなー

http://code.google.com/p/chromium/issues/detail?id=123876

http://code.google.com/p/naclports/source/detail?r=574

よくわからんけど nmf を inject 用の IRT 入れてもらうように作りなおせばいいのかな…

うーんよくわからんが newlib じゃ動かないとかな気がしないでもないなこれ…

よくわからんので古いやつを使うことに

(06:13)

_ メモ

xor の対象があからさまにおかしいように見える

    e20:       8b 05 08 00 04 10       mov    0x10040008,%eax
    e26:       01 d0                   add    %edx,%eax
    e28:       ba 00 00 00 00          mov    $0x0,%edx
    e2d:       11 ca                   adc    %ecx,%edx
    e2f:       8b 08                   mov    (%eax),%ecx
    e31:       83 c0 04                add    $0x4,%eax
    e34:       89 8d 00 ff ff ff       mov    %ecx,-0x100(%ebp)
    e3a:       90                      nop
    e3b:       90                      nop
    e3c:       90                      nop
    e3d:       90                      nop
    e3e:       90                      nop
    e3f:       90                      nop
    e40:       89 95 04 ff ff ff       mov    %edx,-0xfc(%ebp)
    e46:       8b 08                   mov    (%eax),%ecx
    e48:       b8 ff ff ff ff          mov    $0xffffffff,%eax
    e4d:       ba ff ff ff ff          mov    $0xffffffff,%edx
    e52:       31 c1                   xor    %eax,%ecx
    e54:       31 d1                   xor    %edx,%ecx
    e56:       8b 05 d8 c6 05 10       mov    0x1005c6d8,%eax
    e5c:       90                      nop
    e5d:       90                      nop

(06:13)

_ うごいた

long long おかしいメモ

3LL<<-1 とかの、負の値の long long shift がおかしい、というか GCC と一致してない。

long long __ashldi3(long long a, int b)
{
    b &= 63;
#ifdef __TINYC__

とかで対処できる。

long long の ~ というか xor でおかしなことが起きていた。どうも xor だけじゃなくてレジスタが足りなくなって、 long long もう二個目のレジスタを確保する時に一個目のレジスタがメモリに飛ぶ。定数が入ってるヤツが vstack に積まれてると起きるのかな…謎。

               /* allocate second register */
               r2 = get_reg(rc2);
               printf("%s r=%d r2=%d\n", r==r2?"oops":"OK",vtop[-1].r,r2);

として oops は出ちゃいかん気がする。

しゃーないので、 __xordi3 とかを

long long __xordi3(long long u, long long v)
{
    DWunion uu, vv, ww;

    uu.ll = u;
    vv.ll = v;
    ww.s.high = uu.s.high ^ vv.s.high;
    ww.s.low = uu.s.low ^ vv.s.low;

    return ww.ll;
}

という感じで定義してやってそれを呼ぶことにした。つーか TCC の long long は x64 以外で動いてるのが不思議すぎるし、 git blame しても誰も全くいじってないあたりから、たぶん fabrice 以外誰も理解してない気がする。かっこつけず全部関数で定義すればいいのに…

あとは僕サイドの問題だけど、 libtcc1.a を読んだ時のシンボル解決がおかしい、というかシンボルが全く解決されてない。そしてよくわからない。しゃーないので tcc から libtcc1.a をリンクしてやって、 __divdi3 とかそのへんを全部 i686-nacl-tccsyms.tab につっこんでやるという荒技で解決。

(08:06)

[ツッコミを入れる]