はじめてのにき

_ 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)