page0049 のバックアップ(No.2) - osecpu-wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
page0049 へ行く。
- 1 (2013-07-05 (金) 06:44:11)
- 2 (2013-07-05 (金) 09:44:18)

OSECPUのjitcというAPIについて

(by K, 2013.07.05)

(0) はいけい

OSECPU ver.0.56 から junkApi_jitc2() というAPIが追加されます。
これは T_UINT8 の配列を与えると、それをOSECPUのバイトコードに見立ててJITコンパイルして実行可能な状態にして、指定されたPxxに分岐先を返すというものです。

例

02 01 01 02 03 04
という6バイトを junkApi_jitc2() して、その結果をP01で受け取って、 PCALL(P01); とすれば、R01レジスタは0x01020304になります。

例では1命令しか書いていませんが、複数の命令を自由に組み合わせることができます。

これができることで、どんな可能性がOSECPUにもたらされるかを紹介したいと思います。

(1) 設定ファイル

ある程度以上の規模のプログラムでは、設定ファイルを利用することがあります。Windowsでいえば、～.iniというファイルです。
- 参考： http://ja.wikipedia.org/wiki/INI%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB
これは文法がアプリごとにまちまちで、しかも各アプリはそれぞれ専用のパーサを持ち、僕から見ればこれは非効率この上ないものです。

もしこれがこんな風に書けたらどうでしょうか？

SInt32 quickStart:R08, safeMode:R09;
/* 以下で自由に値を設定してください。設定しなければデフォルト値が使われます。 */
/* R00～R07レジスタは参照しないので自由に使ってかまいません。 */

quickStart = 0;
safeMode = 1;

これは可読性において一般的な設定ファイルにそう負けてはいないと思います。
これをASKAでアセンブルして、そのバイナリを設定ファイル代わりにするのです。もちろんアプリがファイルを開いてメモリに読み込んでjitcするのです。アプリ側はパーサもインタプリタも何も要りません。設定値がおかしくないかのチェックをしながら、値を自分の変数の中にコピーしていくだけです。

設定ファイルの中で、あれとこれとそれは必ず同じ値に設定したいんだけどなあ・・・と思っても、普通の設定ファイルでは #define すらできません。しかしjitcを使う方法なら、変数だって自由に使えます。ループだってOKです。ifもできます。
しかもこれらを好きな言語で書けます。というのは、現状ではOSECPUはASKAしか記述言語がありませんが、将来はもっと記述言語が増えると思っているからです。LISPで書いてもいいし、日本語プログラミング言語で書いてもいいでしょう。
上記の例では説明を簡単にするためにレジスタに設定値を代入させていますが、メモリに入れさせてもいいでしょう。構造体を使うことだってできます（ちなみにASKAの構造体サポートは将来の予定です）。

(2) プラグイン

プラグインを独自言語で記述させるアプリも世間ではちらほらありますが、jitcはそれも不要にさせます。OSECPUで書かせればいいんです。

(3) エミュレータやインタプリタ

jitcというAPIがあれば、エミュレータやインタプリタで、動的コンパイル方式を実現できるようになります。これは性能向上に有利です。x86用の動的コンパイラは当然x86上でしか動きませんが、OSECPUを使った動的コンパイラなら、OSECPUの動く環境全てに対応できることになります。

(4) シェルスクリプトやMakefileスクリプト

僕はシェルスクリプトも不要だと思っています。不要というのは、シェルがスクリプトインタプリタを持つことが不要だという意味です。
シェルスクリプトの構文は、それはそれで便利かもしれません。それは結構なことなので、シェルスクリプトからOSECPUのバイトコードに変換するコンパイラを作ればいいと思います。これができれば、シェルスクリプトをシェルスクリプトで書けるのはもちろんのこと、(1)の設定ファイルもシェルスクリプトの構文で書けるわけです。これはいいことだと思います。

Makefileスクリプトも同様です。

(98) セキュリティ問題

jitcはよい面をたくさん持っていますが、反面悪い面もあります。それはセキュリティ問題です。
- jitcはシステムを破壊したりはしないでしょうか？
- 子プログラムが親プログラムを破壊したりはしないでしょうか？
- 子プログラムが無限ループに落ちてしまったら？
- 子プログラムがシステムや親プログラムからセキュリティ情報を盗み出してしまったら？
- 子プログラムはAPIを勝手気ままに呼び出して、親アプリに迷惑をかけてしまったら？
しかし皆さん安心してください。そうOSECPUは「セキュアなOS」なのです。

OSECPUのjitcは、マルウェア（悪意あるプログラム）の開発者にとっては、一見すれば天国です。マルウェアは一般にスタックオーバーフローなどを駆使して苦労して自作の「悪意あるプログラム」を実行させています。しかしOSECPUではそんな苦労は一切不要で、設定ファイルやプラグインの中に悪意あるプログラムを混ぜ込んでおけばいいからです。既存OSと比べたら「ノーガード戦法？」といいたくなるほど無防備です。
しかしOSECPUはそこから先を圧倒的にガードするのです。つまり入り込むことはできるけど、悪さができない、というか悪ささせない自信があるからこそ、入り口を必死に守る必要がない、とまあそういうわけなのです。

詳細は開発が進むにつれて明らかにしていきますので、ご期待ください。

(99) 参考リンク

page0006の「テーマ5」の(16)
- 「データポインタにJMPすることはできません。しかしOSを使えばメモリ上にOSECPUのバイトコードを並べた状態で、それにJITコンパイラをかけることができ、その際は結果として分岐可能なポインタが返されます。」というまさに今回のjitcそのものへの言及があります。
memo0001の「2013.03.19 Tue」
- 「プラグイン機構は子プロセスで十分」なOS、という基本的なアイデアが書かれています。

こめんと欄

コメント	お名前	NameLink