コンパイラをVMに内蔵する - Scheme VM を書く

compiler.scmc (コンパイル済みコード)を VM で eval する。

evaluteFile("./compiler.scmc");

compiler.scmc 中で定義された compile 手続きを C++ コード中から呼び出しコンパイル時に使う。
おお!動いた。
コンパイラScheme で書くという大きなメリットを残しつつ、C++ だけで動作が完結するようになった。
これはうれしいね。

課題

トリッキィに動かすのではなく目についた問題点を修正しよう。
サボるとあとで痛い目にあう。

  • エラーハンドラの呼出しの仕組みとコンパイラ呼出しの仕組みを共通化
  • free 手続きを毎回 push するのは無駄
  • VM内からコード呼出しするとスタックを壊してしまう(ので load や const-compile が安全に呼べない)
    • テンポラリィのスタックで実行しようと思ったが load がネストしたら破綻する
    • まだ使われていない部分のスタックを利用するのが良さそうだ
  • *primitive-names* や *vm-instructions* が複数ファイルにまたがってしまっている問題をどうにかする(loadを実装?)
    • load を実装したが問題が。 load のためには compiler.scm が必要で compiler.scm には load が必要とループになってしまった。
  • コマンドライン引数によって動作をどう変えるかをきちんとまとめる(デバッグようにいくつかの機能を残すべきだろう)
  • wiki が動かない?
    • 動かないのではない。死ぬほど遅いのだ。下に続く。
  • コンパイラの実行が死ぬほど遅い
    • まずは gprof してみよう。
    • 全体的に関数の call 回数がありえないことになっている気が。例)scheme::VM::operand1(scheme::ObjectRecord*) 5300万回
    • コンパイルコードを見てみるか。
      • set-cons の参照がコンパイル済みコードだと36箇所。コンパイル前は2箇所。
      • これは if の分岐のせいだな。ref 対応するか?でもここが遅いのか?
  • 簡単なコードでコンパイルコードと VM トレースをするか。