[[klog/essay094]]
 * OSASK-WikiのKの落書きの過去ログ
 -本家：[[OSA:K]]
 --過去ログにコメントしたい人も、本家のこめんと欄に突っ込んでください。
 ---そのうちKによって下のこめんと欄に移動しますので。
 
 *** OS依存であるべきもの、そうでないもの
 -(2005.03.31)
 -最近、いろいろなことを考えてます。
 -もとはといえば、ネットワークの話でした。各OSを見てみると、LinuxにはLinuxの、BSDにはBSDのネットワーク実装があり、これらはOSへの依存が避けられない部分（デバイスドライバなど）もあるのですが、いっぽうでTCP/IPスタックなど、とりあえず効率を無視していいとすれば、OS依存である必要が特にないものもあります。
 -なぜOSに依存する必要のないものまで、OS依存でかかれなければいけないのか。それは開発効率の観点からは非効率だ。という見解を有している人たちがいて、僕も大いに賛成しています。その人たちに協力することで、OSASKにネットワーク機能をつけようと、今あれこれ画策しています。
 -しかし考えてみると、これは何もネットワークだけの問題ではないような気がしてきました。ファイルシステムにしたって、現状ではOSに依存しなくていい部分まで、各OSに依存している気がします。アプリケーションのAPIだってそうです。
 -なんかそういうことを考えているうちに、新しい考えに到達しそうなのですが、まだきれいにはまとまっていません。しかしとにかくこの考えを押し進めてみます。
 ~
 ~
 -OSASKはエミュレータOSであって、だから効率を際限なく重視できる、これはいいのです。この面では（機能の充実度を除けば）成功していると思います。しかし一方で、機能の充実を各方面から求められるあまりに、なにもかもえせで実装していかないと追いつかなくなり（というか、えせでも全く追いついていない）、これは僕としては十分に満足な結果とはいえません。
 -しかしいっぽうで、「できない」ということは、非常に切実な問題です。「できない」よりは、「遅いけど一応できる」ほうが格段にマシなのであります。遅すぎて使ってられない、というのはありえますが、しかしどんなに速いマシンを準備してもやっぱりできない、というのはいくらなんでもあんまりだよな、と思えてきました。
 -たとえばVESAというものを考えてみます。VESAという仕組みは、ビデオモードのサポート方法としては最低最悪といえるものです。なぜなら、VRAMがただどべーっと渡されて、ここに好きなように書き込んでください、後は知りません、というものだからです。アクセラレータを使えないのでとても遅いです。でも遅いけど、とにかく1280x1024の24bitカラーとか、そういうのはできるのです。
 -これはいいことだと僕は思うのです。おかげで、OSASKやMonaは、とりあえずVESAをサポートすることで、効率以外の面では満足することができるのです。OSASK流に言えば、えせができるということです（MonaはVESA以上を求めていないかもしれないけど）。そしてあとから、対応したいチップのアクセラレータ機能を使うためのルーチンを書き、対応カードだったらそのルーチンを使い、対応カードじゃなければVESAをそのまま使えばいいでしょう。これで後から効率も問題なく追求できる、と、こういうわけです。
 -しかしネットワークにはVESAのようなものがありません。そういうものがどうしてないのでしょうか。あってもいいと思うのです。いや、あったほうがいいと思うのです。・・・それだけではありません、VESAだって十分な仕組みではありません。VESAだけに対応すればなんでもOKかというとそうではなく、VGAはまた別の機構ですし、VESA1.2はこれまたややこしい仕組みでないと動かせないなど、もう問題たっぷりなのです。
 ~
 ~
 -さてないなら作ってしまえというのが僕の基本姿勢ですから、作ろうと思います。そしてやるからには徹底的にというのも僕の基本姿勢なので、あらゆる観点から互換性を重視しようと思います。効率なんてどうでもいいのです。となると、VMしかありません。IA-32に限定する意味はないと思います。新規に効率の良いVMを考えるということも考えましたが、効率なんてどうでもいいので、既存のものをそのまま使えばいいと考えました。
 -今考えているのは、僕がwabaを猛勉強してwabaのアセンブラを探してきて、こいつでVESA2.0/VESA1.2/VGA統合ドライバを書こうかということです（しかもこれはOSASK用というわけではなく、とりあえず単純なものにします）。そのうえでOSASKは現在のネイティブドライバかそれともwabaを使ったドライバにするかを選べるようにしてしまおうと思います。もちろんI/O命令やwait処理はwabaから関数を呼び出す形に統一され、wabaコード内には対象ハードウェア以外の機種依存コードは一切ありません。
 -wabaの実行エンジンはOSASKにオプショナルな形で導入されて（つまりVMドライバを一つも使わなければなくてもいい）、これはJITコンパイラとかそういうものものしい仕組みは入れないで、インタープリタ的に実行することにします。理由は簡単で、このほうが簡単ですし、効率の追求はどうでもいいからです。もちろんJITコンパイラとかを入れたい人は勝手に改造して入れればいいと思いますが、僕だったらそんなことをするくらいなら、速くしたいドライバをIA-32に書き直します。で、今回は、これを通じてOSASKのVESA1.2対応もついでにやってしまおうというわけです。
 -そして僕としては、この仕組みを画面やネットワークだけに限定しないで、全てに適用可能にしたいわけです。つまり、今までOSASKではアプリケーションだけがVM利用可能とされたわけですが、それをOS全域にして、なんなら、アプリからOSのすべてまでwabaだけで記述されていても構わない、とそういうわけです（多分かなり遅いでしょうけど。これって結果的にはJavaOSなのかもしれないですね）。
 ~
 ~
 -このアイデアのいいところは、他のOS開発者もこのwaba実行エンジンさえ移植すれば、OSASKで使われている汎用ドライバが利用できるということです。waba実行エンジンはごく普通のものですし、インタープリタタイプなので、今のOSASKのwabaを見る限り、サイズの問題はなさそうです。最初はこれをみんなで使って、最後はみんな卒業するわけです。IA-32なwabaインタープリタに関しては僕が最適化してもっと小さく手軽にしようと思います。
 -tek5のデコードエンジンもwaba化して、どんなCPUのどんなOSからも利用できるようにして（でもOSASKにはIA-32の展開ルーチンがあるから使わないけど）、OSASKのネイティブのファイルシステムもwaba化して、他のOSからも（対応させたければ）対応できるようになるわけです。一方で、OSASKも他のOS開発者が作ったファイルシステムに（とりあえず）対応させるのは、wabaドライバが出ていればすぐにできますよーという、なんか今まで以上にエミュレータOSらしさが満ち溢れた、そんなのをやりたいわけです。
 -APIもwabaで書けるようにしたいです。僕が作るとしたら、たぶんWindowsのAPIもLinuxのAPIもMonaのAPIも、そしてもちろんOSASKのAPIもすべてハンドル可能な仕組みにします、仕様としては。もちろんそれは全然速くないのですが、しかし動くこということは大事なことなので、それでいいのです。その上で、みなさんが忙しい僕の代わりにエミュレータを作り始めてもいいですし、それは他のOS/CPUでも使えるエミュレータになりえます。
 ~
 ~
 -なんかこんな説明を書くよりも、さっさと作りたくなってきたので、早く作り始めるためにも、まずは今やっている仕事をがんばることにします。
リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS