design016

2010年度からのOSASK計画の予定

• (by K, 2009.09.24)

(0)

• これは http://osask.jp のページに載せるための文章の下書きです。清書するのは10月以降になると思います（時間が無いので）。
• 毎度のことですが、僕はやるといってもやれなかったことが多いので、ここに書いてあることも信用できないかもしれません。それは基本的に読み手の判断にゆだねます。ただ読んでもらえば分かるように、なんとかして実現できるように工夫がしてあります。

(1) 要点

• 今までOSASK計画にはたくさんの側面がありました。その中のいくつかは計画倒れっぽくなってもいます。しかしそれらのほとんどを一挙に解決できるアイデアを思いつきました。だからやります。エミュレータコアだってやります！ただし2010年度からです。

(2) 背景

• どこから話してもいいのだけど、最初から話すのが一番分かりやすい気がするので、そこから書くことにします。
• OSASK計画は、Kがエミュレータを作ったり他のソフトウェアを書いたりしているうちに出てきたさまざまな問題や不満を、OSから作り直せば全部うまく解決できるんじゃないか、ということで始まったものです。当初はエミュレータで一般的な仮想化の技術をOSでも当たり前に使えるようにしたり、互換性の問題をエミュレータドライバで解決させることで従来の発想に縛られないOSの設計をして、特に性能面（速度とサイズ）でKとしては予想以上の結果を出すことができました。
• そしてそのままサポートデバイスやエミュレータコアを書き始められれば良かったのですが、ここで最初の挫折があります。デバイスドライバを書くための資料がなかなか集まらず、またその作業工程を思うと気が遠くなりました（この頃にはKは自身の実装速度の遅さを自覚し始めている）。それでデバイスドライバを書く苦労は一度だけでいい事にしようということで、汎用のデバイスドライバを提供する仕組みとしてKHBIOSというプロジェクトが生まれました。というのはそのときのOSASKはいろいろとえせ仕様なので、そのOSASKにあわせてドライバを作っていたら、OSASKを本仕様にするときに書き直さなければいけないかもしれないからです。
• しかし今度は、この「汎用」で苦しみます。汎用性を高めるためにやるべきことはたくさんあったのです。どんなOSからもデータ圧縮は必ず必要になると確信したKは、KHBIOSで標準的に使える圧縮形式の設計をしました。これはまあまあ成功し、tek形式が生まれました。また「汎用」というからには、AT互換機のみならず、TOWNSやPC-9801でも共通に使える基盤にしようとしました。そこでさらに欲が出てMacもサポート可能にしようと思い立ち、そうするとx86に限定されないブートスクリプトを記述するための言語がほしくなりました。
• さらにKは当時ARMについても勉強していて、x86のアーキテクチャがあまりKの理想ではないことを悟りました。将来理想のCPUをFPGAなどで作りたいと思いました。それであれこれやっているうちにJavaに影響をうけてkhabaという仮想CPUのバイトコードをKHBIOSでサポートしようと思いました。これがKにとっての理想のCPUの機械語です。
• しかし理想のCPUを設計しようと思うと、湧き上がるさまざまなアイデアをまとめることができず、結局khabaは計画倒れになります。そしてそれにつられてKHBIOSも計画倒れになってしまいました。・・・しかし一方で、自分が書いているコードが理想のCPUのものではないということで、以前のように情熱的にプログラミングをするのが精神的に難しくなりました。何を作ってもえせなのです。いつか書き直さなければいけないのです。
• この前後には「30日でできる！OS自作入門」の執筆やサポートなどもあり、両者の相乗効果で長く何もリリースされない時期が続きました。
• しかし何も作らなければ何も解決しないので、できることから少しずつやっていこうと思い直し、OSASK-HBが始まります。これは職人的な最適化は基本的に封印し、さらに一度で最善の仕様に到達しようという目標をなくし、何度も作っては壊しを繰り返そうという方針を採りました。これは予想以上にうまく行ってx86での最高の機能密度を誇るAPI「ぐいぐい01」を生み出しました。
• ここまでの流れが本流ですが、実は重要な支流もあります。それは開発ツールの整備です。ASKA、nask、GO（C言語）、リンカ、ライブラリアン、アーカイバなど、いろいろ必要に迫られて作ってきました。これは当初おまけというか副産物的な扱いでしたし、ついこの間までも、副産物でしかないと思って疑いもしませんでした。

(3) 計画の内容

• OSとユーザの接点はどこでしょうか。そうですシェルです。もっというと応答性（レスポンス）も含めてシェルの挙動さえ同じなら、カーネルやドライバなんて別になんだって同じなのです、ユーザから見れば。逆にカーネルやドライバがどんなに高機能で高性能でも、それをシェルが生かさなければ、ユーザはそのOSを便利だとは思わないはずです。また無能極まりないカーネルであっても、それらの機能を極力使わずにシェル側で自前で処理すれば、それなりのものにはなるはずです。
• こういう話をすると、いやOSとユーザとの接点はアプリもあるというかもしれません。まあそれはそうなのですが、その場合優秀なのはアプリなのであって、OSではないと思うかもしれません。そもそもシェルはOSの一部と見なされますが、アプリはOSの一部ではないというのが普通の見解でしょう。もしくはもはやほとんどシェル代わりになるほど使っているアプリがあるのなら、それはむしろシェルと解釈したらいいかもしれません。
• このような考えは以前から漠然とあって、そのためかKはOSの中心をカーネルではなくシェルに置こうとしました。カーネルにあわせてシェルを作るのではなく、シェルにあわせてカーネルは設計されるべきだ、と。
• ここからがKにとっては新しいのですが、実用的なシェルは何らかのスクリプトを実行する能力を有しているような気がします。DOSにはバッチファイルがあり、Linuxでもシェルスクリプトがあります。OSASKも.PSFというバッチファイルを実行する機能がありました。ということであえて強弁すると、シェルは言語処理系なのです。これが何を意味しているのかといえば、OSには言語処理系をサポートすることが重要だということです。たぶんこれは圧縮のサポートよりも重要なのでしょう。
• 思い返してみれば、昔のマイクロソフトBASIC（F-BASICやMSX-BASICやN88-BASICなどのこと）は、BASICインタプリタという言語処理系でしたが、しかし同時にOSとしての役目（シェルとしての役目）も十分にこなしていました。またKが好きだったOS-9というOSは元はといえばBASIC09という言語があって、それを載せるためのOSとして設計されたといううわさを聞いたこともあります（その真偽はどうでもいいので、コメント欄に書かないでください）。
• ということでKは、OSASKに言語処理系のための支援機能を付けることを前提にして、設計を見直してみました。するとどうでしょう、今までとは全然違う設計が見えてきました。
• たとえばkhabaはバイトコードの実行処理系ですが、これもある意味で言語処理系です。必要な部分のバイトコードを必要に応じて実マシンの命令に変換し、実行していきます。そういえばエミュレータだって（Kが想定していた動的コンパイル方式なら）全く同じ動作原理です。しかしそれを言ったら、naskがやっているアセンブル処理も、naskのソースをx86の機械語に変換しているだけです。データの圧縮や展開も結局はただの変換です。変換した後にプログラムとして実行するか、ファイルに保存するか、データとして次の処理をするか、そのあたりは少々違いますが、しかしなんかこう根底に流れるものは同じだと思えないでしょうか。・・・Kには同じに思えます。
• こういうことを前提にするとどうなるでしょう。OSのコアはただの動的コンパイラマネージャになります。その上でさまざまな形式の言語やデータフォーマットが動いていますが、それらは必ずしもコンパイル（or展開）してある必要はなく、必要に応じて必要な形式に変換されます。変換した結果はどんどんキャッシュされ、実行速度の低下を防ぎます。スクリプトもプログラミング言語も特に区別は無くなり、シェルのコマンドラインでC++の文法を使ってOSを制御することもできるはずです。デバッグ支援機能も統合したいので、動作しているものを一時的に止めてソースを改変して動作を再開することもできるでしょう（マルチタスクなので、動作させたままでやることも不可能ではない・・・タスクセーブしてコピーをとって一方を再開、もう一方を止めてソース改変など）。変数もwatchできるでしょう。たぶんバージョン管理的なことも支援するでしょう。変換ルールを変更すれば、その変更も速やかに反映されます。
• また言語処理系もとても作りやすくなるはずです。今のnaskはx86用のアセンブラとしては世界最小をうたっていますが、このOS用に書かれたnaskはそれよりもずっと小さくなるはずです。構文解析などをOSが支援してくれるからです。ASKAもGOも同様でしょう。そしてこれらは単にアセンブルやコンパイルができるというだけではなく、ほぼ自動的に逐次実行もできるようになるというわけです。

(4) できるの？

• こんなに景気のいい事を言っていると、当然「本当にできるんだろうか」と心配になるわけですが、まず今までの性能重視（速度やサイズ）を少し抑えて、代わりに実装時間を短くする手法や全部完成しなくてもそれなりに段階的に使えるようになる手法を優先して採用するつもりです。今までは「どんなに早く完成しても性能が悪ければ意味がない、そんなものは役に立たない」としてきましたが、今回は「どんなに高性能で理想的でも、動くところまで行かなければ意味がない」という立場です。だからきっとなんとかなります。
• そうはいっても、2009年度いっぱいは忙しすぎて開発ができるとは思えません。だから2010年度からです。そこから2～3年もすれば、「ああ、Kが言っていたことはこういうことなのか」くらいの部分はできるのではないかと思っています。

(5) 補足

• なんか全然うまく書けません。こんな程度のものじゃないんですが、どう書いたら分かってもらえるのかが分かりません。それが説明できたら、ああなるほど、それなら2～3年でできそうだね、って分かってもらえると思うのですが・・・。まあ、苦労して説明を考えるよりも、作ってしまうほうが早そうです。

こめんと欄

• 昔からちょくちょく拝見していますが、なかなか形にならないですね。紆余曲折しているようですが、死ぬまでに完成できるといいですね -- おさ 2009-09-26 (土) 14:49:57
• どうもありがとうございます。でもすべてが形になっていないだけで、部分的には予定以上の成果をあげてもいるので、本質的に深刻な問題だとは思っていません。死ぬまでにできることはもちろんできないことよりもいいことですが、仮に現状以上のものが今後何一つできなくても、僕は失敗だとは思いません。というか（本来の目的とは違うかもしれなくても）何か一つでも結果が残せたのですから、大成功なのです。成功だからいつやめてもいいのですが、僕は欲張りなので、さらに成功を付け足すために、思いついたことへの挑戦を続けているだけなのです。・・・そのあたりの見解の相違があるような気がしたので、あえて書きました。 -- K 2009-09-27 (日) 00:14:57
• TAOのELATEは無くなっちゃいましたね -- 通りすがり 2009-10-02 (金) 13:36:38