17年ぶりの backquote の実装

とある日、2~3時間ほど空きができたので、
TinyCL 用に backquote を C++ を実装することにした。

これまでは頑なに lisp で実装した backquote を使ってきたけど、
backquote を実装するために、多くの関数とマクロを実装しなくてはならないので、TinyCL では genesis を使いたくないからである。

で、evcl の実装をみたら何かよくわからないので、CLtL2を焼きなおすことにした。

が、これが問題で CLtL2 のやつはネストした backquoteを展開してしまうので、
これをそのまま macro expander としては使えないことに、実装が終わってテストしている時に気がついた。orz

う～ん、それでまったく違う実装していたのね。

まぁ、parse の部分だけを返れば simplifier は使えそうだなと思って parse を書き換えたが、あまり効率の良いコードに展開してくれないので、
simplifier を improve しようとしたけど、基本が append form の単純かなので、list form を処理しなくてはいけないので面倒くさい。

あとは maptree, reverse, every, notany とか lispy なのは、どうにもしっくりこなにので、parse の出力をコードリストに代えた。

これで simplification がやりやすくなって、結果 30KB ほど function object を小さくすることができた。

まぁ、reverse とか maptree とか使っていないので、処理もメモリ効率もよくなり速度も速くなったとおもうけど、これらは未計測。ほとんど測定誤差の範疇になると思うけど。

こんど時間ができたら destructuring-bind でも見直すかな。でもこれは何の効果もなさそうだな。

Quotes of Brian Kernighan

• First make it run, then make it run fast.
• The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
• Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
• Controlling complexity is the essence of computer programming.

See http://en.wikiquote.org/wiki/Brian_Kernighan

64bit Lisp ってのろい？

ついでにアーキテクチャ別も metering してみた。
o 32bit Lisp + 64bit Listener: 4,657ms (User: 4,359ms, Sys: 0ms)
o 32bit Lisp + 32bit Listener: 4,721ms (User: 4,265ms, Sys: 0ms)
o 64bit Lisp + 32bit Listener: 6,113ms (User: 5,750ms, Sys: 0ms)
o 64bit Lisp + 64bit Listener: 6,191ms (User: 5,609ms, Sys: 0ms)

100ms は測定誤差だから、明らかに 64bit lisp の方が遅い。
このベンチはメモリスキャンが主な処理なので、
アクセス量が64bitの場合は倍になっている。

そう考えると速度は24%しかダウンしていないので、
64bit版は速いとも言えるかもしれない。

32bit => 64bit の window message の変換のオーバヘッドがあまりない。
HWNDとかHDCがどちらも同じレンジにあることを考えると、
message の変換は行われていないのだろう。

64bit 化成功

と言うわけで、64bit化は成功しました。kernelは13日は動いていたのですが、
o CG の factoring
o Register Allocator のバグと言うか勘違い
o C/C++ スタックフレームの仕様の読み間違い

により、今日まで掛かってしまｓった。

Factoring は、template化によったが、一部 #ifdef が残っているので、
将来的にはクリーンアップする必要がある。

x64-asm.h/x64-asm.cpp は、動いている物に手を加えないと言うルールから、
x86版とは完全に分離されている。ここでも、REX プリフィックスの読み間違えがあった。orz

RA も読み間違えと言うか、記述があいまいな部分を明確化して勘違いに気が付いた。Resolution パスのテストもできた。

C/C++のスタックフレームは、最低でも 32byte + 8 byte 必要。32byte は、レジスタパラメタのセーブ用だけではなくて、callee のワークエリアにも使われる。
debugビルドでは使われたいなかったが、releaseビルドでは使われているので、
発覚した。

さらに debug ビルドでは rbp が C/C++では、CallLispが呼ばれるパスでは、
使われていなかったが、release ビルドでは当然使われていて、
CallLispでrbpを保存し忘れていたことが判明。

logical-pathname の parse-namestring が、落ちていたのは alphanumericp を
呼び出していた部分で、スタックフレームのサイズが足りなかったことによる。

あと、GCというか FunObj::FetchVal で、array-total-size-limit をうまく読めていなかった。

GCに起因するバグは、これ一つで、後は全てRA。予想通り m06-loop.lispで発生してくれた。RAのデバックは、やはりつらい。

まぁ、幾つかコードのクリーンアップも出来たので、これはよかった。

イメージサイズは x86=27MB, x64=50MB。

次は GCMap か、Copy Propagation. BBlock Layouter も見直したい。


genesis に掛かる時間は、x86,x64 とも 7秒。
デバッグビルドだと 88秒と108秒。

64bit Pointer Constant

MSC14(VS2005)では、
o Val const nil = reinterpret_cast<Val>(0x123456789ABCDEFull) は、32bit としてコンパイルされた。
o (Val) (0x123456789ABCDEFull) は、64bit としてコンパイルされた。

これは、バグだよね。