0.4.11までは(実は0.4.11は試験的に違うが)Schemeで書かれたVM上でコンパイラをコンパイルしてCのコードを生成していたのだが、これだとVMのコードを変更するたびにC側とScheme側の両方を変更しなければならなくて正直面倒だった。そこで、とりあえずの下地として、コンパイルされたコードをCに変換するライブラリを0.4.11では導入した。
とまぁ、Sagittariusが変なことをしていない処理系だったらこれで話は終わるんだけど、実は変なことをしている処理系なのでここで話が終わらないことに気づいたのだ。SagittariusのコンパイラはVMが使用するフレームのワード数を知っていて(VMから取るんだけど)、コンパイル時に余計な環境の束縛を行わないようにしている(多分以前そうしたっていう記事書いた)。これが問題になる。ちょっといい例が思いつかなかったので微妙な例だが、こんなの。
(disasm (lambda (x) (let ((y (get x z))) (print (let ((w (get y z))) (get w (let ((e (get x))) (get e x)))))))) ;; size: 40 ;; 0: FRAME 6 ;; 2: LREF_PUSH(0) ;; 3: GREF_PUSH #<identifier z#user (0x80501990)>; z ;; 5: GREF_CALL(2) #<identifier get#user (x805019d8)>; (get x z) ;; 7: PUSH ;; 8: FRAME 6 ;; 10: LREF_PUSH(1) ;; 11: GREF_PUSH #<identifier z#user (0x805018b8)>; z ;; 13: GREF_CALL(2) #<identifier get#user (0x80501900)>; (get y z) ;; 15: PUSH ;; 16: FRAME 18 ;; 18: LREF_PUSH(2) ;; 19: FRAME 4 ;; 21: LREF_PUSH(0) ;; 22: GREF_CALL(1) #<identifier get#user (0x80501810)>; (get x) ;; 24: PUSH ;; 25: FRAME 5 ;; 27: LREF_PUSH(10) <-- !!! this !!! ;; 28: LREF_PUSH(0) ;; 29: GREF_CALL(2) #<identifier get#user (0x805017b0)>; (get e x) ;; 31: LEAVE(1) ;; 32: PUSH ;; 33: GREF_CALL(2) #<identifier get#user (0x80501870)>; (get w (let ((e (get x))) (get ... ;; 35: LEAVE(1) ;; 36: PUSH ;; 37: GREF_TAIL_CALL(1) #<identifier print#user (0x80501948)>; (print (let ((w (get y z))) (g ... ;; 39: RET普通ならLREF_PUSH(10)というのはスタックに詰まれた変数の10番目をスタックに積むという意味なのだが、この場合は途中にあるフレームを考慮したら10番目になった変数の参照を意味している。なんでこんな風になっているかと言えば、まぁ歴史的理由が大きいのだが、Sagittariusには一つ外側の環境という概念が存在しないからである(その方がパフォーマンス的に有利だったから)。VMのスタックはプッシュとポップ以外では基本変更されないので、そこを(個人的には)上手く使った(と思っている)トリックである。
では、普通のセルフホスティングでは何が嬉しくないかといえば、コンパイラやビルトインライブラリにこういったケースが無いとは言い切れないため、先に計算されたオフセットがずれる可能性があるからである。となれば、解決策は一つで、ホストはまずターゲットコンパイラAをコンパイルしてそのコンパイラでもう一回コンパイルするというものだろう。Aは一つ前のVMインストラクションで構成されるが、吐き出すインストラクションはターゲットが必要とするものになるといった寸法である。多少回りくどいなぁとは思うが、仕組み上回避不可っぽいので諦めるしかないだろう。
とりあえず、メモとして記録。
2 comments:
基本的に、現在のバージョンのコンパイラでもって、次のバージョンの環境をホストかつターゲットとするコードを出す、というクロスコンパイルになるんですよね。Gaucheでもバージョン間で変わり得る値を定数として埋め込んじゃわないようにかなり気をつけています。
まさにそれです。このケースだとコンパイル結果に入り込んでしまっているので、VMを将来にわたって変更しないか、なんらかの方法でターゲット側に変更を入れ込むか、プリコンパイルされたコードにはこのケースを入れないようにするかのどれかが必要で(最初は無いとして)どれがいいかなぁと思っているところです。
Post a Comment