ささだです．

>>>　他の処理系で不安なのと，書き込み時の安全性はやっぱりほしいような
>>>気がするのと，あんまりコストは変わらないような気がするので，volatile
>>>な変数に毎回一緒に代入しようかと考えております．
>>
>>VM 命令 1命令ごと (?) にメモリ (スタック?) に PC を書き込むというのは、
>>性能的にはオッケーなんですか?
> 
> 
> VM命令ごと、というわけではなくて、longjmp()する可能性のある処理(VM
> loopの外にある、メソッドの実体)を呼び出すごと、ですよね。もしVM命令ご
> とだと、そもそもレジスタ割り付けした意味がなくなっちゃいます。

　pc_R (on register) と pc_S (on stack) があったとして，たとえ
ば命令開始時オペランドをフェッチしようとすると，pc_S の値をス
タックからロードするコスト 1命令だけ減るかなー，とか思ってまし
た．pc_S へのストアのコストはある程度減らせないかなあ（命令間
依存があまりないので，IPC はあがりそう）とか．

  まぁ，あんまり変わらないかも．


　実際問題，そもそもそのオーバヘッドが性能に響くかなあ，とか．
あ，これは自己否定だ．


> Cで書いたVMだと、VM loopの外のコードを呼び出す時に、VMの状態(VM loopの
> 局所変数)の一部を渡したり、外から見える場所に書き込む処理は必要になっ
> てくると思います。
> 
> たとえば、私が書いたVMだと、VM loopの外のルーチンでGCが起きた時にVM ス
> タックをスキャンできるように、スタックトップのキャッシュやスタックポイ
> ンタをグローバル変数に書き出しています(exact GCなので)。
> 
> どうせメソッド呼び出しの時には、引数もメモリに書き込んで渡すので、相対
> 的なオーバーヘッドは大したことないかも知れません。

　命令ごとに，ストアするべき，しなくてもいい，などを別々に書い
ておくといいのかもしれませんね．ローカル変数アクセスでは例外発
生しない（と思うけど），文字列を生成する命令 putstring では，
GC が発生して，その中でなんか例外起こる可能性がありますので．

　ちなみに，SP ですが，現在の YARV の実装ではそのスコープで伸
びる限界の箇所を指しています．GC はそれを参考に行います．この
計算はスタックフレームを新しく作るとき，一度計算してストアする
だけで済みます．


>>例外発生時の大域脱出に setjmp/longjmp を使うことに、
>>何か必然性はあるんでしょうか。
>>setjmp/longjmp を使わないように現 Ruby インタプリタを書き換える
>>というのはナシでしょうか?
> 
> 
> これは、すでに存在するCで書かれた拡張ライブラリとの互換性ということで
> はないでしょうか。

　そのとおりです．

> 
> 書き換えて良いなら、「例外が起きた時のPCの値を、longjmpの引数に渡して
> もらう」とするのが良さそうですけどね。

・longjmp の引数はそのジャンプの原因を示す値（互換性の問題）
・callee である C 関数などから，Caller の Ruby PC はわからない

という点で難しいかと思っております．

-- 
// SASADA Koichi at atdot dot net
//

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