page0049
の編集
http://osecpu.osask.jp/wiki/?page0049
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
FormattingRules
FrontPage
Fulyn
Fulyn-v2
Fulyn_Samples
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KOR_PIT8254
KWVM.NET
Liva
MANA
MenuBar
OSECPU_FPGA
PG_MANA
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
hikalium
hikarupsp
hikarupsp_ELCHNOS
hikarupsp_ELCHNOS_IDE
hikarupsp_FrontEndCode
hikarupsp_WebCPU-VM
hikarupsp_WebCPU-VM_internal
hikarupsp_study_hh4
impressions
impressions0000
jpag0000
jpag0001
jpag0002
jpag0003
jpag0004
jpag0005
lambdalice
mandel59
members
memo0000
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0007
memo0008
memo0009
memo0010
osask
osecpu4android
page0000
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
page0024
page0025
page0026
page0027
page0028
page0029
page0030
page0031
page0032
page0033
page0034
page0035
page0036
page0037
page0038
page0039
page0040
page0041
page0042
page0043
page0044
page0045
page0046
page0047
page0048
page0049
page0050
page0051
page0052
page0053
page0054
page0055
page0056
page0057
page0058
page0059
page0060
page0061
page0062
page0063
page0064
page0065
page0066
page0067
page0068
page0069
page0070
page0071
page0072
page0073
page0074
page0075
page0076
page0077
page0078
page0079
page0080
page0081
page0082
page0083
page0084
page0085
page0086
page0087
page0088
page0089
page0090
page0091
page0092
page0093
page0094
page0095
page0096
page0097
page0098
page0099
page0100
page0101
page0102
page0103
page0104
page0105
page0106
page0107
page0108
page0109
pagenames
populars
seccamp2013
seccamp2014
seccamp2017
ttwilb
ttwilb-asmi
yao
* 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を使う方法なら、 #define はもちろんできますし、変数だって自由に使えます。ループだって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、という基本的なアイデアが書かれています。 * こめんと欄 #comment
タイムスタンプを変更しない
* 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を使う方法なら、 #define はもちろんできますし、変数だって自由に使えます。ループだって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、という基本的なアイデアが書かれています。 * こめんと欄 #comment
テキスト整形のルールを表示する