OSECPUシェル
(0)
- （ここに書いていることは2014年度内には実現しません！）
- OSECPU-VMの数年単位の目標として、「OSECPU-VMの中で暮らす」というのがあります。・・・つまりOSECPU-VMのアプリだけでいろいろなことができるようにしたいのです。テキストエディタ、コンパイラ、ファイル操作、アプリの起動、などなど。
- このうちのシェルに相当する部分が、OSECPUシェルです。OSECPUシェルは他のOSECPU-VMのアプリを起動したり、強制終了したり、スクリプトを解釈したりします。
(1)
- スクリプトを解釈するとはいっても、新規にスクリプト処理系を作る気は全くなくて、OSECPU-VMのバイトコードがシェルスクリプトです。16進数などではバイトコードは書きにくいかもしれませんが、適当な言語を使えばバイトコードも簡単に作れるでしょう。
- 以下に書くのは、このシェルのためのアイデアです。
- なお、このシェルはPC向けを想定しています。他の環境向けを考えたら、また別の仕様のほうがいいかもしれません。
(2)
- OSECPUシェルでは、ファイルとオブジェクトを区別しない。「オブジェクトは全てファイルである」。つまりOSECPU-VMアプリが適当なオブジェクトを作って、アプリが終了すると、ファイルシステム上にそのオブジェクトが残る。邪魔なら捨てなければいけない。
- mallocはしたがfreeしていないオブジェクトは、全て残る。静的オブジェクト（グローバル変数）も残る。レジスタの値も終了時の値が全て残っている。
- これらは次回実行時に消えるわけではない。同じアプリを3度実行すれば、同じものが3つできてしまうことになる。うっとうしいかもしれないが、そういうものなのだ。
- アプリを起動すると、内部では適当な番号が割り振られる。これはプロセスのUUIDかそれに相当するものである。このUUIDさえ分かれば、そのプロセスが何時何分に始まって、何時何分に終了したかが分かるし、そのプロセスがfreeしなかった全てのオブジェクトは、そのUUIDの名前のフォルダに全部入っている。ユーザはこのフォルダをコピーしてもいいし、自分の区別のためにリネームしてもいい。
- プロセスのUUIDが分かれば、起動時のコマンドラインも分かる。
- これらの情報は、もちろん電源を切っても消えない。
- mallocしたオブジェクトには名前がないだろう。となればしょうがないのでやはり適当なUUIDをファイル名とする。中身はもちろん型情報がついた状態で保存されている。
- そしてユーザはこれらの増え続ける「ログ」を暇なときに消去すればいい。「終了後30日以上経ったもので、リネームしてないものは全て消去」のように。まあ自動で消す設定があってもいいのかもしれないが。
- この仕様の意図を説明したい。・・・まず、現状のPC環境を考えてみると、テラバイト級の記憶容量は容易に手に入る状況で、これらをはっきりいって「もてあましている」。それならばもう何も考えずになんでも残せばいいではないか。あふれて困ったら消せばいいのだ。・・・消すことなんていつでもできる。しかし消してしまったものは戻ってこない。だからできるだけ勝手には消さない方針なのだ。
- ファイル名もディレクトリ名も本当にめちゃくちゃなのであるが、それは参考にできそうなデータがないのだからしょうがない。しかし、malloc命令のときのDRレジスタの値やFEリマークなどを使って、変数名を反映させることはできるかもしれない。仮にそれができなくても、データの中身を使って検索はできるから、もしデータを探しているのなら見つけることはできるだろう。
- 世間の一般的なシェルでは「標準出力」というものがあって、そこにアプリが出力結果を出すことになっている。どんなにたくさんの情報があっても、標準の出力結果は一つしか出せない。そんなのって不便だと僕は思う。アプリはいくつでも好きなだけ結果を出力できるべきだ。オブジェクトならいくつでも残せる。しかも出力がテキストでなければいけないというのもおかしい。バイナリでいいではないか。型情報があればバイナリでも十分見やすくできる。
- 標準出力にhelloと書くのと、文字列オブジェクトにhelloを書き込んでおくのと、いったどっちが応用しやすいだろう。オブジェクトに決まっている。オブジェクトに入っていれば、他のオブジェクトに結合することできるし、ハッシュ値を計算することもできる。標準出力に出してしまったら、それは入力しなければいけない。つまりファイル処理をやっている。これはムダだ。数値オブジェクトならなおさらで、テキストにするために10進表記をして、それをまた戻したりしている。
- OSECPU-VMアプリには、ファイルを読み書きする機構が本質的には不要である。なぜならファイルとオブジェクトは同じものだから。つまりPxxレジスタは、ファイルの○○バイト目を指すことができるし、そこから読んだり書いたりできる。
- OSECPU-VMで何か適当な関数を書いたとしよう。それはおそらくR30～R3BのレジスタやP30～P3Bを使って何か引数を渡して、何か計算されて、最後に結果がR30～R3BやP30～P3Bに返ってくるだろう。これはそのまま、OSECPUシェルの「外部コマンド」になりうる。P31が指しているオブジェクトは自動でファイル化されているのだから。ユーザは関数が返したオブジェクトをゆっくりと見ることができる（スクロールで流れたりはしないし）。P32やP33が指しているオブジェクトだって同様に見られる。R30の値だって確認できる。全く問題がない。もはや画面出力とかをする気が起きない。勝手に出力なんかされたら、画面が汚れて応用しにくくなってしまうだけだ。画像のオブジェクトを返すことだってできる。
- 標準出力では、アプリが終了する前でも途中までの出力をリアルタイムに見られる。OSECPUシェルのコマンドでもそれを実現したい。・・・そのためには、終了前のプロセスでもオブジェクトの中身が見えればいいのだ。それは難しいことじゃない。多分できる。
- ファイルがオブジェクトなら、ファイル名は変数名みたいなものである。つまり変数を宣言するとファイルができる。代入するとコピーされる。
- OSECPUシェルには環境変数はない。それは普通の変数を使えばいいのだから。
- OSECPU-VMアプリがセキュリティ例外などで異常終了したとしても、オブジェクトは残っていて全部見える。だからデータを救うこともできる。UNIX系ならコアダンプから救出できるのかもしれないけど、Windows系ではそういうことはできないほうが普通なので、これはありがたいはず。
- シェルのコマンドラインで16進数を書くのはさすがに泣けるので、R00=3;くらいの構文は解釈できなければいけない。となると、言語処理系との連携を前提にして、シェル自身は基本機能だけを提供するべきなのかも。
- つまりコマンドライン解釈部は、FulynやOSECPU-Lispなどなんでもよい。要するにOSECPU-VMのバイトコードを出力できるコンパイラならなんでもよい。
- 好きな言語で快適に操作できる。
- OSECPUシェルは、マイクロソフトのPowerShellに似ているかもしれない。
(3)
- これらの実現にはもちろんいろいろと問題があるだろう。それは解決しなければいけない。
- ディスクを使いすぎるという問題もあるかもしれない。同一内容のファイルはディスク内で共通化されて、容量を節約するようになっているべきかもしれない。
- しかしとにかく、僕はこんな感じのシェルを作りたい。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
