どっちなんだろうなぁ・・・。命令にフラグを付けるのは嫌。2種類用意するのは・・・。実装が頑張るものであって、VM命令には入れないほうがいいのかもしれない。入れない方針で行こう。駄目ってわかるときまで。要するに、スタックトップだけレジスタに載せてしまえばいいんだろう。久しぶりに、'98年度情報科学実験IIコンパイラ演習に挑戦するも、やはり敗退。東大ってやっぱり凄いんだなぁ。一度授業を受けてみたいものだ。2003)Gaucheでは、継続の作製時に全ての継続フレームと環境フレームをヒープに移し、継続を呼び出した場合はヒープ上のフレームを直接参照します。実行することにより、スタックの内容をヒープに移しています。現在はGCとの絡みで、フレーム毎にコピーしてポインタをつなぎかえるという処理が必要で、これがフレーム数が増えるとボトルネックになっていると見ています。(したがって、スタックがほぼ一杯の時にcall/ccを使うとやっぱり重いのですが、call/ccをヘビーに使うパターンではそれほどスタックが伸びないことが多いので、あまり顕在化しません)。2003)素人考えなんですけど、単純にスタックの長さを倍倍で増やしていったらまずいでしょうか。がオセー、とかあるかもしれませんが。2003)今のGaucheの実装では、いくつか問題が。スタックフレーム間は直接ポインタで指しているので、realloc()してスタックのベースアドレスが変わったらリンクを全部直さなくちゃならない。それを避けるためにスタックをchunkに分けると、境界での処理が面倒。スタック内のポインタと疑似ポインタ(ポインタのように見える整数)は、現在のスタックポインタの値にかかわらず、全てGCのスキャンの対象になる。スタックが大きくなればなるほどGCへの影響が大きい。(popする時や環境がヒープに移された時にnullifyすればGCへの影響は避けられるが、こんどはnullifyのコストがかかるので、性能への影響は複雑)。根本的な解決として考えているのは、次のような戦略です。GCにフックをかけて、スタックエリアのポインタスキャンを賢くやる。それが出来たら、一杯になったスタックを移動させずにそのままヒープとして扱うことが可能になる。call/ccも、継続フレームをコピーせずにスタックベースポインタを動かすだけで可能になる(スタックベースポインタ以下はヒープ扱いになる)。2003)うーん、やっぱりきちんとソースを追わないとわかんないですね。今度読ませていただきます。2003)機会があったらCPSの入門書を紹介してください。幹事の方って、農工大の人じゃないですか。隣の隣の研究室・・・。品川さんとお会いしたことないんですが、これを機に話聞いて見ようかな・・・。ダメだよな、この研究室同士の閉鎖性。SPAを調べていたのは、akrさんの論文を読みたかったからなんですが、置いておらず。春の論文は(Googleで)ひっかけられたんだがなぁ。明日いらっしゃったら聞いてみよう。ポスターだから論文ないんかな。遅刻するかもしれませんが、行きます。女の子と付き合ったことがないんですけど...。あははははははははは。(とてもとても笑えない)前田先生の、「Schemeインタプリタにおける仮想マシンアーキテクチャの最適化」という論文を、どこをどー探しても出てこない。昔見て、しかもプリントアウトした記憶があるような気がするんだけど、見つからない。ウェブ上を探しても見つからない。PRO論文誌を探しても見つからない。うーん、どこいっちゃったんだろうな。研究会報告誌も無いし・・・。