Jun Inoue
jun.l****@gmail*****
2006年 4月 18日 (火) 10:11:56 JST
Macro の bug を潰し終わったので compaction に手をつけたんですが、 performance と hackability の二面で不満があります。改造しようとしたん ですが、変更箇所が広すぎるので書き直しました。 で、結構 radical な変更もあるので、どう思うか comment をください。以下 に見てほしいところを示します。なお、完全には書き終えてないのでいくつか stub が入ってます。 (1) せっかく pair の tag が 00 になってるのに strip を bypass してない (ry (2) 関連部分が散らばっている これは fatty にも言えることですが、小さな変更をするにも変更箇所が沢山 あり、全てを把握 & 確実に変更 + coherency を確保するのは大変です。実際、 macro を実装するにあたって型を二つ追加しようとしただけなのに、 -構造体を追加 -検索+移動 -MAKE_* を追加 -検索+移動 -Accessor を追加 -別 file に移動 -SAL_ のついてないものを追加 -別 file に移動 -make_* を書く -別 file に移動 -gc に追加 -code を書いてみると、違う構成を試したくなりました。あるいは収拾がつか なくなってきたので svn revert で reset したくなりました。 振出に戻る×4回 (実話) と実に長々と単調で error-prone な作業をするはめになりました。まず compile を通すまで集中力が続きません。ていうか LISP 系の define を吐け る macro が欲しくてたまりません。 一月以上だらだらと進展せずにやってたのは、まあ macro の semantics が鬼 のように tricky なのが主因ですが、この面倒臭さにかなりやる気を削がれた のも事実です。試行錯誤に時間がかかりすぎ。 GC と make_* がバラけるのは仕方ありませんが、他はなるべく関係のある code を密に集合させて、大局的な構造と局所的な調整を区切るべきです。 SAL_ もやっぱり無駄だと思います。特にこれだけ冗長に prefix を付けてい るなら。 とか言いつつ freecell をどこに置くか決め兼ねてたりします。Misc 型の構 造の抽象は失敗気味ですが、代案が思いつかないし、元のよりは柔軟だと思う のでとりあえずこれで。 (3) 初期化と終期化(?) 専用に macro が欲しい Finalization を header に放りこむのは (2) によります。初期化のときも、 置いて良い仮定が既に初期化された object と食い違う可能性があるので packaging しておきたいところです。Code size も低減できますし。それから ENTYPE() を減らせます。即値には init も fin も作らない方が賢明に思われ ます。 (4) 定数の生成をなるべく parametrize & automate したい #define SCM_IMM_TAG_INT (SCM_TAG_IMM | (0x0 << 3)) #define SCM_IMM_TAG_CHAR (SCM_TAG_IMM | (0x1 << 3)) #define SCM_IMM_TAG_CONSTANT (SCM_TAG_IMM | (0x3 << 3)) #define SCM_IMM_TAG_NULL (SCM_TAG_IMM | (0x3 << 3) | (0x0 << 5)) #define SCM_IMM_TAG_INVALID (SCM_TAG_IMM | (0x3 << 3) | (0x1 << 5)) #define SCM_IMM_TAG_UNBOUND (SCM_TAG_IMM | (0x3 << 3) | (0x2 << 5)) #define SCM_IMM_TAG_FALSE (SCM_TAG_IMM | (0x3 << 3) | (0x3 << 5)) #define SCM_IMM_TAG_TRUE (SCM_TAG_IMM | (0x3 << 3) | (0x4 << 5)) #define SCM_IMM_TAG_EOF (SCM_TAG_IMM | (0x3 << 3) | (0x5 << 5)) #define SCM_IMM_TAG_UNDEF (SCM_TAG_IMM | (0x3 << 3) | (0x6 << 5)) やっぱ magic number が並んでるのを見ると、心の底から沸き上がるような恐 怖が(ry (5) やっぱ名前長すぎ Macro 型を追加するべく storage-compact.h を開いて変更箇所を把握しよう としたとき、「これ……読むの?」って感じだったんですが。初見の人にとっ ては識別子の綴を確認するだけで大変です。いくらなんでも長すぎやしません か。 それに excessive prefixing によって名前が不適切 / inflexible になって る箇所もあります: SCM_IMM_TAG_NULL (Tag というよりは object 全体) SCM_OTHERS_CAR_STRING_MUTATIONBIT_OFFSET (car にある必然性は無い。最大長を犠牲にしても alignment の制約を減らし たいかもしれない。) (6) Terminology 整理 言い出しっぺの私が用語を明確に定義しなかったのが原因で名前が ad-hoc だっ たりわかりにくかったりする箇所がありますね。とりあえず S & 6 → primary tag (ptag) S->y についてる tag → miscellaneous tag (mtag) level 1〜3 即値とその種類を示す tag → immediate tag (itag) itag の内、特に何の種類の即値かを示す部分 → immediate type ID (immid) としてみたんですがどんなもんでしょう。特に others は context-independent な理解が困難なので変えた方がいいと思います。 (7) 即値型への破壊的操作 無い方が良いと思います。Compact か fatty かで動作が変わってしまい、怪 しい bug の温床になります (siod に debug 機能をつけたときに経験済み)。 関数型の incrementer (i.e. inc! じゃなくて inc) はあってもいいかもしれ ません。 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: compact.h.bz2 型: application/octet-stream サイズ: 7135 バイト 説明: storage-compact.h compressed다운로드
