design017 :: OSASK計画

2010年度からのOSASK計画の予定の続き(1)

• (by K, 2009.10.11)

(0)

• これは http://wiki.osask.jp/?design016 の文章の続きです。でもこれが http://osask.jp に清書されて載るかどうかは未定です。
• design016をもっと詳しく書いてほしいみたいな問い合わせがあったので、もう少し書くことにしました。

(1) 結局2～3年のうちにどういうことをできるようにしたいのか

• まず、グラフィックとかサウンドとかネットワークとか、そういうものは全部どうでもよい。実用性とかもとりあえずどうでもよい。そんな本質的でないことは初期の数年ではやらない。当面はこのOS（？）はefg01用のアプリ（つまり.g01）として記述されるだけであり、グラフィックやサウンドやネットワークやその他「普通のOSでできること」の全ては、他のOSでやればいいじゃないか、という非常に投げやりな態度を取る。この開発の初期段階としては、他のOSではできないことを追求したり、仮に同じことをやったら効率がどのくらい違うのかを確認する、そういうことがメインになる。
• というか、デバイスの制御とかは後ででもできることだし、やればなんとかなりそうなことでもある。そういうことに初期の時間をかける気はない。それよりも、本当にこのアイデアが実用的なのかどうかとか、可能性はどのくらいあるのかを確認することが先である。
• 効率（性能追求）についても似たようなことがいえる。khaba（はば）のバイトコード仕様など、表の性能に影響する部分については、ややまじめに検討する。しかし、そこから最終的に生成されるx86のコードや、x86をkhabaのバイトコードに逆変換した場合のコードの（性能的な）品質などは、基本的にどうでもよい。最適化も多分やると思うが、それも不要な命令を見つけて削除する程度で、それ以上の積極的な最適化はたぶん着手しない。それはこの開発の全体が見えるようになってからやればいいことだ。
• というか、そもそもコンパイラやエミュレータコアが生成するコードの最適化については、Kはやや否定的な見解を持っている。高級言語やエミュレータを使う状況というのは、それほど速度が重視されない状況である。なぜならもし本当に速度が必要なら、肝心なところだけでも各CPU向けにネイティブコードを書けばよい。そしてkhabaはそういう記述もサポートしているのだ。だからそれ以外の部分が多少非効率で遅くて大きくても、そんなことは大きな問題ではない。問題だと思うのなら移植すればいいのだ。
  • 逆に言うと、アセンブラのような言語がプログラマの意図する最適なコードを出力できない場合がある、などというのは言語道断である。
• 比較的早めに解決すべきなのは、とにかくkhaba0.00の仕様を決めることだ。決めてしまえばアセンブラやコンパイラやインタプリタが準備できる。そうすればkhabaを使った開発ができる。これなら作ったものはCPUに依存しない資産になる。またkhaba0.00はもちろんいろいろとえせで将来性には問題があるのは避けられないだろう。しかしそんなことは気にしなくていい。なぜならkhaba0.01が出たときに、khaba0.00→khaba0.01の変換ツールを用意すれば済むからだ。それはたいした手間ではない。
• そして全く同じような発想で、エミュレータも作られる。つまりx86→khaba0.00への変換ツールがあれば、それはエミュレータの代わりになるではないか。x86のバイナリは確かに少々面倒だけど、しかしこういうコンバータを作ることは可能に思えるし、効率を考えなくていいのなら、そんなに難しいようにも見えない。
• しかしそうであるのなら、x86そのものをkhaba0.00ということにしてしまえばいいではないかというアイデアが思いつく。これならkhaba0.00向けのアセンブラやコンパイラを作る必要がなくなる。いくらx86がKの理想の命令セットではないといっても、命令セットとして必要なものは一通りそろっているわけだ。それならそれでよさそうにも思える。
• でもこれは使えない案なのだ。なぜなら、x86はいくつかの「Kが不適切だと思う命令」を含んでいる上に、既存のコンパイラやアセンブラはそれらを使ったコードを生成する。それらの命令のために、x86は（仮に命令がバイナリレベルでほぼ互換だったとしても）レジスタのビット数に依存して動いたり動かなかったりするし、エンディアンの違うCPUでもそのままではうまく行かない。
• もう少し具体的に説明しよう。x86に限らず、世間の多くのバイナリプログラムは対象機種のCPUのレジスタ幅に依存している。絶対に依存しているとまでは言い切れないが、中規模以上のプログラムならまず間違いなく依存している。またメモリへのリードやストアが伴う命令では、それが実際はどういう構造体へのどの部分へのアクセスなのかを知ることがバイナリからの解析では非常に難しい。つまりそれらの情報が失われているのだ。バイナリに含まれていないのだ。こういうものは、任意のCPUの機械語へ効率よく変換することが非常に難しい。非効率でいいのならもちろんできる。
• これに対し、khabaはそのような情報をバイナリでも保持する。いうなればこのプログラムはintの幅が8bit以上なら問題なく動くように作られている、みたいな情報があるのだ。もちろんこれらの情報は各変数ごとにtypedefすることで別々にも与えられるから、かなりきめ細かく指定することもできる。このようになっているので、4GB以上のファイルを扱うかもしれないアプリに対しては、ファイルサイズを保持する変数を64bitするように決めてからJITを始めればいい（ファイルレスアーキテクチャを採用するので、ここでファイルの話をするのは最適ではないのだが、これが一番分かりやすいと思われたので、これを例にした）。逆にそういう大規模ファイルを扱うことがまずないようなコンパクトな組み込みシステムでは、同じkhabaのバイトコードからファイルサイズ32bit版のコードを生成して使えばいいのだ。
• khabaではデータファイルも全て構造情報を持つ。なぜならあるアプリがファイルサイズをデータにバイナリで記録したとしよう。しかしそのビット幅は32bitなのか64bitなのか128bitなのか。それはそのデータファイルがどのような環境で作られたのかによってしまう。エンディアンもどうなっているのか分からない。これらの問題を解決しなければ、機種を超えたタスクセーブなどただの空想に過ぎない。だから全てのファイルには構造情報がある。構造情報があるから、実際にopenされる前にフォーマットを変換し、問題なく読み書きできるようになるのだ。
• 世間ではこういうとき新しいフォーマットを定めてそれを使わせようとするが、Kはそういうふうには考えない。フォーマットというのはデータ構造であり、特定のデータ構造やエンコードをプログラマに押し付けるのは、将来にそのせいで性能が頭打ちになるかもしれないという危険を残すだけだ。データ構造をどうするかはプログラミングの大事な要素であって、プログラマの自由を残すべきだ。それをOSなどが一方的に標準化するべきではない。その代わり、そのフォーマットがどういう内部構成になっているのかを、記録できるようにしておくべきなのだ。そうすれば、互換性の問題はない。
• このような機構のため、本システムにおいては一般のバイナリファイルの保守性や可読性は、それぞれのデータがテキストでエンコードされて出力されたファイルになんら劣ることはない。
• とにかくそういうプログラミング＆実行環境を何でもいいから実現することが必要だ。それさえできれば、khaba0.00→khaba0.01の変換ツールみたいなものを用意するだけで、あとはなんとでもなる。

• （書き途中：続きをいつ書くか、そもそも続きを書くのかどうかさえ未定）

こめんと欄