Kazuki Ohta
mover****@hct*****
2005年 9月 4日 (日) 08:34:19 JST
太田です。 そろそろScmObjInternalを8byteに圧縮してしまおうかと思います。 ただ、少し悩んでいる所が有るので投げてみます。 まず方針として基本的に、下位3bitをオブジェクト情報に割り当てます。 32bitマシンの場合はこんな感じですかね。(以下話は32bitマシン上の話としています) ScmObjInternal *obj; ScmObjInternal*: [ -- 29 bit -- ] [ABC] (car部) ScmObjInternal*: [ -- 29 bit -- ] [XYZ] (cdr部) 王道ですが、最下位ビット(C と Z)が立っている時は即値と見なします。 [-- 29bit --][001]や[-- 29bit --][101]等の値は全て即値と見なされます。 逆に、即値でない場合は次のようになります。 後残っているのはA,B,X,Yの部分です。ここにgcのデータ(marked or unmarked) とScmObjの型情報(Cons? String? Port?)が入ります。まずAにgc用のデータを 割り当てたとして、残りB,X,Yの部分に型情報を詰め込む必要が有ります。 しかし現在 ScmObjType は15種類有って、少なくとも4bit必要です。どう考えて も足りませんね...これを解決する為に僕が思い付いたのは、次の2つの方法です。 1. mark_tableの作成 gcデータ(mark or unmarked)用に独自のテーブルを持ちます。1ビットの情報しか いらないので、int mark_table[HEAP_SIZE / 32]とする事でスペースを削減でき ます。mark_tableのインデックスは対応するheap上のScmObjInternalのインデック スと対応します。 こうして、Aにgcデータを確保する必要が無くなったので、ABXYを型情報に使用 する事が出来ます。 2. 型毎にヒープを分ける すべてのヒープの開始アドレスと終端アドレスをチェックして、ここのヒープに含まれて いるから、このデータ型だという様に判断する。もの凄く遅そうなので、あまり現実的 では無いかも。 なので1の方式を採用しようかと思っているのですが、どうでしょう？ ------------------------------------------------- Kazuki Ohta : mover****@hct***** -------------------------------------------------
