こんにちは、川合です。
FORM-Akkie さんは 2005/07/22 11:42:12 の「[osask 7220] [ 内容：
感想等長文 ] 本日 OSASK を知った件 ...」で書きました：
>貴重な機会に感謝します。
>はじめまして、私は剛と申します。
はじめまして。ご感想をありがとうございました。
>"互換性"についてですが、恐らく、意味合いとしては互換性の是非というよりも
>膨大な互換調整ファイルの肥大化による容量の圧迫傾向
>またシンプル・クリーンなデザインに反する要素あるという事で
>互換性について述べているのだろうと理解しました。
>それが故の"エミュレーター"なのですよね。
はい、そういうことです。
まず過去との互換性というのは非常に大切です。これを完全否定して
も、得るものよりも失うもののほうが多いでしょう。しかし一方で、こ
の互換性を意識しすぎて、まず互換ありきでOS開発をはじめてしまった
せいで、個性のない、ぶくぶくに太って小回りの利かないOSばかりにな
っていると僕は考えます。
もし最初から100%の互換性を第一に考えるのなら、既存のOSを用意し
てそれに付け足す方法（orそれを改良する方法）で設計していくのが一
番妥当でしょう。実際互換性を維持しているOSはどれもこれも似たよう
な基本構造のものばかりです。そしてこの方法で作っていく限り、OSは
太る一方で複雑になっていくだけです。
僕が目指しているのはそのような手法ではなく、まずすべてをいっさ
いご破算にして、ソフトウェアは如何に書かれるべきかを再検討し、そ
の役割分担においてOSのなすべきことを考え、そのOSがなすべきことを
ストレートにプログラムにするということです。OSの設計の際には、エ
ミュレーションを受け入れやすくするということ以外は何も考えず、既
存のOSとの親和性は無視します。
そうした結果、OSの進化の過程で不要になった部分はすべてきれいに
無くなり、シンプルで必要十分でかつ高速な基本構造をもつOSが見えて
きたわけです。それがOSASKなのです。
---
移植性に関する問題については、率直に言って、僕の不明をお詫びし
ようと思います。
従来の僕は、移植性を意識するということは全機種で共通に使える機
能しか使わないということだから、それは各機種が新規に搭載した有用
な新しい機能を一切利用できない（少なくとも利用機会は減少する）と
いうことであり、それぞれの機種が持つ性能を充分に発揮できないから
駄目だ、と主張しておりました。そんなことをするくらいなら、ターゲ
ットにしている機種専用で開発して、他の機種についてはエミュレーシ
ョンでフォローするほうがずっといいだろうと考えたわけです。
最近の僕は、この考えを改めつつあります。最初から移植性を全く考
えないで、固有の機能を細部に至るまで活用してしまうと、エミュレー
ションで動かしたときにはかなりの性能低下があります。従来の僕なら
、「エミュレータの速度で困るときは、移植を検討すればいいじゃない
か」と言っておりましたが、移植はそれなりに骨が折れます。特に自分
のプログラム能力の乏しさを実感するようになってからは、「問題があ
ればなんでも移植すればいいじゃないか」と豪語するのは、現実的では
ないかもしれないと思いはじめました。
そこで少し妥協（？）して、性能に強く影響する部分については今ま
でどおり移植性を配慮する必要はない、としつつも、性能にあまり影響
しない部分については移植性を重視してもいいのではないかという考え
方に変わりました。たいていプログラムのうちの20%が実行時間の80%を
占めるといわれていますので、この方針にするだけで移植の手間は80%
減少します。そしてそれが性能に及ぼす寄与はせいぜい20%程度で済み
ます。
世間では「一度書いたらどこでも動く」的な移植性重視に傾いていて
その性能の悪さは悲嘆しても足りないくらいです。むしろそれを知って
いたから、僕は当初移植性に反旗を翻したわけです。しかし今は、移植
性のよさも認めて、両者のバランスをとることが理想的だと考えている
わけです。
この（僕にとっては新しい）考えのためには、ネイティブコードとの
親和性が保証された形式の仮想マシンが必要で、Javaや.NETではそのよ
うなことを一切考えていないため、新規に仕組みを考える必要があると
判断しました（Javaや.NETではタスクセーブすら困難です。現仕様のま
ま可能にするとさらに遅くなります）。この新しい仕組みをkhabaと呼
んでいて、少しずつ設計をつめています（この先数ヶ月は忙しいのであ
まり進まなそうですが）。
ここで一応補足しておくと、この流れは相対的にOSASKにおけるエミ
ュレータの必要性を弱めるものではありますが、その必要性は無くなり
はしません。既に現在存在する（そして多分これからも僕以外の人が作
るであろう）機種依存のソフトウェア資産については、それを人手によ
ってkhabaに書き直させるよりも、エミュレーションするほうが、格段
に現実的だからです。
khabaがそれなりになれば、OSASK自身もkhabaを前提に書き直すこと
ができるはずで、そうすればx86以外でもOSASKが動くようにできると考
えています。そうなれば、以前から各方面で期待されていた組み込み用
OSASKへの道が開けると思っています。
今までOSASKはFDという（現在では）貧弱ともいえる環境に縛られた
せいで、さらに少ないメモリ・遅いCPUの機種をサポート対象に入れつ
づけたおかげで、鍛えられてきました。過酷な条件を与えられたから、
それに耐えられるようになったわけです。ぬるま湯に浸れば、安易な妥
協を繰り返し、他のOSと似たり寄ったりな結論で終わってしまったかも
しれません。
もし組み込み用という、さらに厳しい環境にさらされることになれば
、OSASKはきっとさらに強くなるチャンスを得ると思うのです。
khaba用OSASKを作るというのは、今まで何度も企画されては潰えてき
た「仮想マシン上OS」構想の一つともいえるわけで、心配に思われるか
もしれません。この最大の障害は性能低下であって、khabaは性能低下
を最小に食い止めるための仮想マシンといえますから、きっと何とかで
きると期待しています。しかし、やっぱりだめかもしれません。もし駄
目だったら、その時点であきらめて、x86用のOSASK上でkhabaアプリケ
ーションを動かす、という普通の構成でがんばろうと思っています。や
りもしないであきらめることはできない、という僕の性分のため、とに
かく一度はkhaba用OSASKに挑戦しないではいられないのです。
>単純に概念を視覚化すると、デスクトップマシンをあたかもPPCやHPC
>等のモバイルマシンのように扱える環境(エミュレートも含め、その起動速度やタスクセーブ)
>が提供され、且つ、ワンハード上でのエミュレーションプロセスによるクロス実行環境
>が提供される事ということが出来るんじゃないかと思います。
>ただ、拡張性や可能性、フレキシブルな側面を加味すれば
>上記以上のオープンプラットフォームの動きの主流になるような
>潜在的可能性があると思います。
まあ、主流になれるかどうかは気にしないで、飽くまでも自分の理想
を追い求めて、妥協のなくやっていきたいです。その結果として、主流
になればそれは素晴らしいことですし、なれければそれでもいいです。
とにかく、自分が使っていて満足できるものにしたいです。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! osask.jp
Homepage http://osask.jp/