OSASK-WikiのKの落書きの過去ログ

  • 本家:OSA:K
    • 過去ログにコメントしたい人も、本家のこめんと欄に突っ込んでください。
      • そのうちKによって下のこめんと欄に移動しますので。

OSASKのドライバ

  • (2005.04.02)
  • 仕事をサボって多少検討した結果、いろいろ見えてきました。それで下した決定は、wabaのバイトコード(つまりJavaのバイトコード)をそのまま使うのはやめる、ということです。wabaが気に入らない理由は以下のとおりです。

  • アプリケーションは作りやすそうだけど、ドライバは作りにくそうだ。
  • 命令セットが妙に複雑。整理すればもっと少ない命令セットで、しかもコンパクトになりそう。
  • 僕の理想としては、OSASKの中にはたくさんのネイティブドライバがあって、ネイティブのシェルもあって、アプリもほとんどネイティブで、だけど一部にはVM用コード版のアプリやドライバも混ざっている、というものです。さらに、仮に全部をネイティブでそろえた場合は、完全にフルパワーが出てくれないと困ります。共存可能にするために、あれこれオーバーヘッドが増えて、気が付いたらネイティブルーチンだけで使っても、以前のOSASKより遅くなった、なんていうのはだめなのです。
  • そういうことを考えると、どうもwabaは駄目っぽい感じでした。wabaで作った関数同士がデータを交換するのはかなりうまいのですが、ネイティブとデータを交換するのがうまくないのです。それは嬉しくないので、その辺も配慮した命令セットがほしくなりました。
    • それでバイトコードにとって都合が良くて、しかもネイティブのオーバーヘッドにもならないインターフェースを模索していたら、OSASKネイティブのドライバ仕様も改善しました。これにより、OSASKネイティブドライバは、ソースをいじることなく、OS全体をたったひとつのコードセグメントにまとめたり、ワークエリアをたったひとつのデータセグメントにまとめたり、もしくは今までどおり全部バラバラにしたり、そういうことが自由自在にできることになりました。このおかげで、以前から断続的に議論の的になっていた、マルチセグメント化に伴うオーバーヘッドも、測定可能になりそうです。

  • そんなわけで僕は新規にバイトコード命令体系を作ります。基本的な命令セットはwabaに良く似ていて、つまりwabaやJavaで書かれたプログラムに関しては、バイトコード・トランスレータで、ソース無しで簡単に変換できる予定です。これは、アプリやネットワークのプロトコル制御部などはJava/wabaになっているものが多いと思うので、それに配慮したものです。
  • またこのバイトコードのインタプリタはwabaよりもコンパクトなので、任意のバイトコードとインタプリタをくっつけて一つの.exeにするような、そんなツールも作りたいです。また、普通のアプリに関しても、コードの90%はバイトコードで書いて、最適化が必要な10%だけネイティブルーチンを使う、みたいなことができます。もちろんこれはそのネイティブでしか動きませんが、こういう開発スタイルは悪くないと僕は思います。その10%さえ書き換えれば、任意のプラットホームで、しかも十分高速に動くわけですから(その10%さえもバイトコードで書けば、それはそれで遅いけどオールプラットホーム対応ということになる)。こういうことが簡単にできるのも、wabaとは違ってネイティブとのオーバーヘッドが小さくなるようなインタフェースを用意するからです。

  • 今回のこのドライバのVM対応の件を、仮想マシン上でOSを作っちゃおう的な計画や、ドライバのコードを全部VMで書こうよ、と混同する人がいるかもしれませんが、それは根本的に違います。僕の最終的な目的は、オールネイティブであって、オールVMではありません。単に、アプリだけではなくドライバやその他のOSのコンポーネントでも、VMを使えるようにしようというだけのことです。
  • これで他の機種版のOSASKの開発をするときに、全部の移植が完了しなくても、足りない部分は汎用バイトコード版ルーチンを入れておけば、とりあえず動くには動くよね、とそういうものです。しかもドライバとかは他のOSでも流用可能だから、OSASK以外にも新OSを作る際には役に立つかもしれないね、という話です。
  • Javaやwabaや.NETの目指すところは、どの機種でも使えるようなバイトコードだけが流通するようになって、機種依存があるのはJITコンパイラだけ、みたいな感じだと思うのですが、僕の目標は最終的にはすべてのコードがネイティブだけになることであって、VMを使うのはそこに行き着くまでの開発効率を上げることだけなのです。だから高速化のためのネイティブへの転換を前提にしていて、ネイティブルーチンとの高速インターフェースを重視するわけです。JITコンパイラも原理的には簡単に作れると思いますが、今のところは興味がありません。動けばいいのでインタプリタです。僕だったらJITコンパイラではなくて、バイトコードからじっくりていねいにネイティブコードにコンパイルするような、そんなツールを作ると思います。そうすればでかいJITコンパイラが、バイトコードを実行するたびに起動したりしなくていいですからね。
  • そんなわけですので、この辺を誤解して変な期待をしたり、不要な失望をしたりしないでください。

  • とりあえずこのバイトコードですが、kabaという名前にしようかと思っています。wabaに敬意を表して。それで、kaba用のアセンブラと(これはもちろんkaba上で走るのです)、kaba用のC言語(このコンパイラも当然kaba上で走るのです)を作りたいなと思っています。つまり、kabaインタープリタさえあれば、どこでもアセンブラでkabaのバイトコードを生成させたり、C言語でkabaのバイトコードを作ったりできるわけです(ちなみに最適化はやる気ない)。・・・そこまでやる暇があるかどうかが最大の問題ですが。・・・でもそうすれば、kabaインタプリタを載せるだけで、OSASK上でもKH-DOS上でも、Windows上でも、とにかくkabaでプログラム書いて遊べますよ?(笑)
    • なおkabaアプリは、当初から全機種でタスクセーブ対応予定。

リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: 2006-02-16 (木) 18:00:16 (5977d)