ttwilbの個人ページ
プロジェクトなど
- HeavyOSECPU : OSECPUのソースコードを学習者向けにわかりやすくした派生版。
- osecpu4android : Android上で動くOSECPU実装 (まだ全然できてない)
- airjose
- 現在、高級言語版ASKAを作ろうか、とか思ってたりします。(ASKAの上位互換)
- ASKAの機能が日々向上していることを考えると、ASKA互換言語は不要なのではないだろうか。
自己紹介
OS-Wikiの個人ページへ
osecpuバイナリを直接読むためのメモ(バックエンドコード編)
- ここに書いていることはただのメモで、結構嘘があるため注意してください。
- ファイル先頭の 05 E2 : シグネチャ
- 先頭が 05 E2 00 だと、バックエンドコードを意味します。
- F7 88 : 4バイトのデータが続きます。(ビックエンディアン)
- FC : 次に続く1バイトは命令です。
- 80 : 0 という値を示す。
- F1, F2, F3, F4, F5, F6 : それぞれ命令1, 2, 3, 4, 5, 6
ASKAで文字列を配置した例
// app0111.ose addr: 0x92
LIMM 0x0c 0x37 32 // R37 = 0x0c // 文字列長?
LIMM 0x03 0x3B 32 // R3B = 0x03 // データ型?
talloc 0x3B 32 0x37 32 0x3B // typ=R3B, count=R37, out=P3B
PCP 0x3B 0x31 // P31 = P3B
LIMM 'h' 0x3B 32 // R3B = 'h'
SMEM 0x3B 32 0x3B 3 0 // [P3B] = (typ3) (R3B) // R3BをP3Bの示すメモリ にコピー
LIMM 1 0x3F 32 // R3F = 1
PADD 0x3B 3 0x3F 32 0x3B // P3B = P3B + R3F
LIMM 'e' 0x3B 32
...
- まずtallocで領域を格納し、T_UINT8で1バイトずつメモリに書き込んでいる。その際書き込み先のポインタとしてP3B, 書き込むデータのバッファとして R3B, ポインタを進める量を格納するためR3F, tallocの引数指定のためR37, R3Bを指定している。
- 上のコードでは、文字列が書き込まれたメモリのラベルをP31に出力している。
- 上の命令群は、db2bin処理前でいう
REM38(6,0,0x03,R37,P31);DB('hello, world',0x00);
という記述に対応している。
- これによって、api_drawString()の引数P31に文字列格納先のラベル、R37に文字列長を渡しているようだ。
- R37に代入する文字列長はどうやって取得しているのだろう?
- なぜLB命令を用いてベタに文字列を格納しないのだろう? その方がサイズが小さくて済むはずなのに。
どのようにOSECPUと関わりたいか？
- 手伝えることがあったら---。でも基本受け身で
- でも自分の考えに近い部分があるので、手伝う場合は楽しく手伝えそう
OSECPUと共通する考え方(インデント下は私の考え)
- (開発環境やその他事前の確認ではなく)実行環境側で実行時に安全性を保障すること。
- 安全性が侵されるのは、命令が(開発者やユーザー、もしくは『扱われる情報自身』が)
想定をしない衝動をしたときであると言える。そのため、(多少遅くなったとしても)命令
が動作する実行環境自体が安全を担保するのは的を得ている。
- そもそも、情報技術がこれほど発達した中で、何十年も前の技術であるx86 architecture
によるnativeの安全保障のみで満足する方が辛いと思う。
(「securityに関する考え方」で説明する)
- (もちろん、software layerで実現する以上最終的にはhardwareの機能に一部依存する
ことは避けられないのだが)
- pointer(参照型)の扱いを大きく制限する。
- ほぼすべてのC言語においてはpointerは開発者に柔軟性と自由度を与えてきたが、これが
危なっかしさを形成していることは否定できない。なので当然ポインタ
は機械側で面倒を見てやるべきである。
※誤解などがあったらごめんなさい！
OSECPUと異なる(?)考え方
- 実行したprogramの製作者が「悪意を持って」codingをしていた場合でも、systemおよび
すべての情報の安全性を保障する。
- 例えばGoogle Glassのcameraを使って盗撮しまくるAppなんて誰でも作られるわけで、
そういった状況を防ぎたいと思ったら情報の扱いにsystemが介在
するしかない。
- もちろん、こんな特殊な例以外にも、たとえば見た目は便利道具を装っていながら実は
裏で住所録を・・・（以下略）
- 悪意のある命令によって破壊されたsystemを以前の状態に復元できるようにする。
- むしろprogram終了時にすべての状態を戻すのをdefaultとする。
- systemが保持する(user側に公開される)すべての情報を、programの実行時に完全に複製(!)
する。その複製された(そしてprogramによって読み書きされる)情報を
systemと同期したいかは使用者が決める。
- トランザクション処理で、programが異常終了した場合の情報の冗長性を確保する。
(従来の、例えば設定fileを中途半端に書き込んだ状態、みたいには
ならないようにする。)
- program側で設定をfileに直接書き込んだりせず、必ずsystemの用意する情報管理機能
を使用するようにする。
- systemの情報にprogramによって与えられた変更は、そのprogramを削除することでいつでも無かったことにできる。
- 型指向を強化し、意図しない動作や許さない情報の流れ(例えば、顧客の個人情報がinternet側の
interfaceから送信される、など)が、systemによって拒否
されるようにする。
- 初期状態では、すべての情報には「画面に表示される」許可さえも与えられていない。networkに
放流される許可など言うまでもない
- 関数型言語
- objectは突き詰めて考えればすべて定義である。その定義を指すのか、のみが問題なのであって、
その状態がどうとか、ということを考える必要はない。
- リアルタイム
- 値ではなく式でデータを扱うため、元の値の変化が即座に結果に反映される。（例えば時間が経過すれば再描画処理をしなくても画面の時刻表示が更新される。）
本当に実現できるでしょうか。
- 実現したいですが、おそらく多くについては実現困難であるといえるでしょう。そもそも
自分の考え自体まだあまりまとまっていないので。
- まとめる切っ掛けを与えてくれる意見など、大歓迎です。
- (技術面での不安も・・・)
securityに関する考え方
- 1と0。つまりsecurityの段階は0%か100%しかない
- そもそもsecurityという考え方さえ不要になるかも。だって、特に守ろうとしなくても、意図しない動作、
不正な操作はそもそも実行不可能だから。
- 逆に言うと、正当な操作以外はすべてsystemの段階で拒否される、ということ。
- なんて自信を持って言えるくらいのsystemを100年以内に作りたい。
systemに関する議論
nilium leafについて
- 上の説明に通ずるprogramming interfaceを提供するため、手始めにC#でinterpreterを実装
- いづれFreeBSD上に載せて単独で動くようにする(licensing 形態未定)
- mobile OSからserverまでを想定
ttwilb/leaf?
関連リンク
コメントください
- ページ名に%が入ってしまうので、 ttwilb/leaf はいくないかも・・・。そう書きたい気持ちは分かるのですが・・・ごめんなさい。 -- K 2013-07-16 (火) 14:46:05
- 失礼しました。当該ページはウィキ違い感があったので移動しました。nilium -- ttwilb 2013-07-16 (火) 23:01:24
- REM38()について。バイトコードを調べると分かりますが、REM38()は最終的なバックエンドのバイトコードには表れません。REM38+DBは、それで一つの特殊命令を構成していて、db2binによって正規の状態になります。本来はASKAがREM38()を生成するべきではないのですが（つまり最初から展開後のバイトコードに相当するアセンブラコードを出力すべき）、その処理はdb2binでやったほうが簡単なので、現状のような分業体制になっています。・・・ttwilbさん以外の人にとって何を言っているのかよくわからないかもしれないので、基本的なことから説明すると、まずREM38命令はリマーク命令ではありません。リマーク命令は、それを取り除いても正常動作には影響のない命令ですが、REM38+DBは取り除いたら動作に激しく影響します。他のリマーク命令と番号的に大きく違っているのは、これが本当のリマーク命令ではないからです。ただ命令フォーマット的にはリマーク命令を模倣しているので、リマーク命令に分類されているだけです。db2binを通り抜けた後のバイトコード内には、REM38+DBは一度も出てきません。「REM08+多量の正規命令群」に変換されます。 -- K 2014-07-07 (月) 15:28:57
- ということで「R37に代入する文字列長はどうやって取得しているのだろう?」への回答としては、REM38は後続のDBも含めて1命令を構成しているので、長さを知ることはなんら難しくありません。 -- K 2014-07-07 (月) 15:32:12
- 「なぜLB命令を用いてベタに文字列を格納しないのだろう? その方がサイズが小さくて済むはずなのに。」への回答。もともとREM38命令は、複数のレジスタの値や定数などを並べて一時的に配列を構成するために用意されています（{ R02, 123, R11, 'a' }とか）。それを文字列出力に流用したために、不自然な感じに見えているのだと思います。・・・静的なデータ域を用意してそこへストアさせるというのも魅力的ですが、動的にtallocして使い終わったらtfreeしてくれる仕組みも魅力的で、「どちらかだけを簡略表記できるとしたら、どちらのほうがうれしいか」と考えて、手間のかかるtalloc+tfreeのほうに簡略化表記をつけました。だから自分で文字列をデータ域に確保して文字列表示することもできます。そのときはapi_putString2()などを使います。 -- K 2014-07-07 (月) 15:51:05
- 一晩考えて、data命令方式も選べるようにしようかなと思いましたー。将来対応しようと思います。 -- K 2014-07-08 (火) 06:26:50
- 「ASKAの機能が日々向上していることを考えると、ASKA互換言語は不要なのではないだろうか。」について。いやあ、どうかなあ。ASKA互換でなくてもいいので、まともな高級言語は必要だと思います。ASKAは今後もあまり優秀にはなりそうにありません。 -- K 2014-07-17 (木) 20:30:24
- 何だか、誰も使ってくれないのではないだろうか、という気がするのです。（もちろんコンパイラの出来にもよると思いますが。）ところで、普通C言語でintの値とshortの値を足し算すると、その式の値はintになりますよね。ところがOSECPUの場合はbitが低いshortに合わせるのがデフォルトだと思います。bitが違う値同士を計算させるときは、どちらかを明示的にキャストさせる(SBX)べきなのでしょうか。それとも、式の型を低い方のbitに合わせるべきなのでしょうか。 -- ttwilb 2014-07-20 (日) 10:15:14
- 自問自答になって申し訳有りませんが、やっぱり式の値は最低bitに合わせて、それを例えばint型に代入するときは明示的にキャスト(SBXに対応)させるか、それとも暗黙的に変換を行うかすべきなのでしょうか？ -- ttwilb 2014-07-20 (日) 10:35:48
- しかし、式の型をbitの低い方に合わせると、例えば999999 + (char)16みたいなのが実行時エラーになってしまうような。定数であればコンパイラで検出できるけど、変数だとそれができないし…。やっぱり式の値を大きいbitに合わせるべきなのだろうか。でも毎回SBXかprefix1をたてる処理を入れるのは少し気持ち悪いかも…。 -- ttwilb 2014-07-20 (日) 13:22:00
- でも、OSECPUの標準的なbitは32だからほとんど問題ないかな。でもchar型があったら絶対使いたいだろうし、char + int とか普通にやっておかしくないし。そのたびにキャストするのは不便だし、暗黙にprefix1を立ててbit上げするしかないけど、それも頻発するようなプログラムは良いプログラムと言えないかもしれない。 -- ttwilb 2014-07-21 (月) 00:00:56
- bit問題は悩ましいですね・・・。暗黙のSBXが入るのはもちろんかまいませんが、ただキャストなどをすればそれを部分的にOFFにできるようになっていてはほしいです。その上で、デフォルトを何にするべきなのかは、そもそもどういうプログラムを想定するのか（どういうプログラムを書きやすくしたいのか）という原点を再確認するのがいいのかもしれません。 -- K 2014-07-21 (月) 07:36:26
- 現在、多忙なため、これ以上開発を進める目処が立っていません。現状のソースコードはsourceforgeで公開しています。また、asmi以外のOSECPUに関する活動にも手を着けられない状態です。少しもOSECPUに貢献できていないことを申し訳なく思っています。 -- ttwilb 2014-09-10 (水) 22:11:11
- 貢献できないことは、確かにプラスではないかもしれないけれど、でもマイナスでもないので、申し訳ないなんて思わないでいいですよ。各自が余裕のあるときに、やれることをやるくらいがちょうどいいのです。むしろあまり無理してやってもらっても、私はなんら見返りを提供できないので、かえって申し訳なくなってしまいます・・・。 -- K 2014-09-11 (木) 06:26:26
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
