ささだです。
　先日はどうも。

Yuya Kato wrote:
> Yuyaです。
> YARVで遊びはじめました。
> 
> 　YARVはword code、、、という話を聞いたことがありますが、
> そのword codeを入出力するインタフェースは、既に実装
> されていますでしょうか？

　まだ無いです。

　コンパイル結果を出力にはいくつか課題があるんですが、一番大きな問題は
「何を出力するべきか」です。

　今のコンパイラは、次のような動作を行います。

1. NodeTree -> YARV Basic Instruction (YBI)

　ノードツリーを YARV 命令列にします。これは、多分どの VM も共通になります。

2. YBI -> Operands Unification (OU)

　オペランド融合を行います（A op1 => A_op1）。現在のところ、1 の段階でオ
ペランド融合をしてるんですが、tail call optimization がうまくできなかっ
たのでフェーズを分けようと考えています。多分、3 と同時にやります。

　どのオペランドを融合するか、は VM 生成時の最適化オプションによります。

3. OU -> Instructions Unification (IU)

　命令融合を行います（A B => A_B）。

　どの命令同士を融合するか、は VM 生成時の最適化オプションによります。

4. IU -> Instruction Address / Function Address

　スレッデッドコードにするために、direct threaded code ならば命令のアド
レス、call threaded code なら関数のアドレスに置換します。

　(命令1) (命令2) ...
=>
　(命令1 を実行する機械語のアドレス) (命令2 を実行する機械語のアドレス) ...

　VM が shared library だと、実行ごとに番地は変わる？


----

　ちなみに、最適化オプションによっては、2 〜 4 はしません。つまり、VM の
バイナリによって 2 〜 4 に対応してたりしなかったりします。

----


　戦略としては、

a. 他の VM （その他のバイナリ、その他のマシンのバイナリ）に命令列を送り
たいなら 1 の段階の結果を出力
   読み込んだとき、2 〜 4 を行う。

b. そのコンパイルした VM でしか動かさないなら、3 の段階の結果を出力
   読み込んだときに 4 を行う。

c. a と b 両方出力しておく
   ひとつのファイルに両方記録する。（hoge.rbc ?）
   a は必須にして、b はオプション、切り離しを容易にしておけばいいかも？
   b が存在する、かつ b は自分の VM で実行可能、であったらそれを利用、み
たいな。

d. a と b 、両方出力できるようにしておく
   それぞれ別のファイルに記録する。（hoge.rbg, hoge.rbc ？）


　こんな感じ。VM のバイナリ依存でよければ b を、汎用性を目指すなら a
を、ってことになると思います。2 〜 4 を省略できる gain がどれくらいある
か見極めてからってことになると思います（ざっとこないだ計ったときは、1 が
コンパイル時間の半分を占めていたような）。

　ちなみに 1 はグラフ構造なので、出力時にちょびっと工夫が要ります。

　re-compile まで標的に入れると、元のスクリプト、または元の NodeTree も
出力しないといけないかなー、とか考えているんですが、よくわかりません。a
さえあればいいのかも。

　とりあえず c が現実的かなぁ。そのためにはそのファイルの構造をきちっと
考えないと駄目ですけど。


-- 
SASADA Koichi at atdot dot net

--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml