K.Maebashi's BBS

>はい、一つ目は文字列バッファーにある関数名インデックスを示し、二つ目はコン >パイル単位カウンター、三つ目は関数ID＝インデックス、四つ目はパラメターの数 >です。P2，P3は実行時に埋め込まれます。コンパイルカウンターは、１～最大値ま >でのループカウンターで動的コンパイル実行時かコンパイル単位の消滅処理時に >＋１されます。コード上は最初は0そしてカウンターは1なので、値が違うためP1の >関数名から動的リンクをしてP2に１、P3に関数インデックスが埋めこめられ、この >関数インデックスで直接関数が起動されます。以後、P2のコンパイルカウンターが >一緒なら、P3で直接関数起動です。直接起動の前にIF文が一回入る程度です。 うーん、いまいちわかりませんが、 ・call_functionのふたつめのオペランドを「P2」として、 ・「コンパイルカウンター」は、「動的コンパイル実行時かコンパイル単位の 　消滅処理時に＋１」というくらいだから、VMにひとつだけ存在するカウンタですよね? つまり、動的コンパイルが動いたり、逆にバイトコードを破棄したりするたびに VMの状態が変わるわけですが、この「状態」に対して、1から始まる連番が振られて いるわけですね。 で、call_functionごとに、それがリンクされた時点の連番(コンパイルカウンター)が 埋め込んであり、呼び出しごとに現在のコンパイルカウンターと比較して違っていたら 再リンクする、と。 この方法だと、コンパイル単位が増えてきたとき、プログラムの端のほうでちょろっと 動的リンクが発生しただけで、それこそprint()みたいにあちこちで使われる関数の 呼び出し箇所すべて(通るところだけですが)に対し再リンクが必要になるような…… ちなみにDiksamでは、バイトコード中の関数インデックスはコンパイル時に 決めています。これは「バイトコードごと」の関数インデックスであり、 ver.0.2～0.3系列では、リンク時に、これを「DVMごと」のインデックスに置き換えます。 ver.0.4では、置換は行わず、変換テーブルをバイトコードごとに持っています。 今のところ動的なバイトコードのアンリンクは実装していません。実装する場合、 DVM上のFunctionテーブルのis_implementedをfalseにすることになるかと思います。