newt をつくっていて感じたのは VM の効率の悪さである。Apple がつくった NewtonScript のバイトコード仕様に改善の余地が沢山あるというのは置いておくとしても、どんなによくできた VM であろうと汎用であるかぎり特定の分野（例えば数値計算）に特化された VM にくらべればどうしても無駄が多い。適用される分野に応じて複数の VM を使い分けることによりこの問題を打破できるのではないかと考えている。
幸いなことに NewtonScript では関数オブジェクトごとにバイトコードを保持している。つまり関数オブジェクトごとにバイトコード仕様が違っても問題の少ないつくりになっているのである。また実際につくってみると一般にイメージしているよりも VM の実装コスト(*1)はあまり高くないことがわかる。複数の VM が混在してもそれほど負担にはならないのである。
さて、まっさきに考えられるのは数値計算に特化した VM である。特に NewtonScript の場合オブジェクトシステムの設計上 30bit の符号あり整数しか扱えないが、数値計算 VM 上でのみ 32bit で扱えるようにできる(*2)のではないかと期待できる。
Multi VM を実装する上での一番の問題はどうやって最適な VM を選択するかである。考えられる方法としては native キーワード(3)のような特定のキーワードで明示的に指示する方法がひとつ。あるいは、NewtonScript では int, array タイプ(*4)の指定ができるのでソースコードを的確に判断して int と array しか使われていない場合は自動的に数値計算 VM 用のバイトコードを生成する方法が考えられる。
ネイティブコンパイルができない代わりにこのような Multi VM でそれを補完するというのもひとつの手ではないかと思うのだがどうだろう。実行速度ではネイティブコンパイルに到底敵わないがネイティブコンパイルのような機種依存性は発生しないというメリットがある。
*1) 純粋にバイトコードの処理部分のみのはなし
*2) 通常の関数に戻る場合は 30bit に丸められることになると思う
*3) ネイティブコンパイルのためのキーワードだが newt/0 では無視される
*4) newt/0 では無視される
Tags: NewtonScript