僕の抱いている野望
(OSASK計画)
− 僕がいつか実現させたいと思っているＯＳの話 −
目次
計画の概要
概容／あらすじ
計画の目的
コンピューター文化の統合
プログラム言語の統合
そしてより高度な世界へ
実現への技術
エミュレーション技術
最適化の技術
計画の進行状況
製作の障害
現状
概容／あらすじ
このＯＳＡＳＫ計画は、僕が今までパソコンを使ってきて、不便な思いを
したのがきっかけでした。この計画は、以下のような環境を構築しようとい
う試みです。
１．エミュレーターの完備により、機種、言語、環境
の差を気にしないで、ソフトウェアが使える。
２．エミュレーターには最適化技術を導入するため、
うまくすれば、自身のエミュレーションをする事
により既存のソフトウェアが高速化される。
３．最適化はエミュレーターに任せてしまえば、プロ
グラマーはより汎用的なアルゴリズムで記述すれ
ばいいということになる。これにより、プログラ
マーの負担が減る。
４．上記の様なエミュレーターを作るには現存のＯＳ
では足かせが多く、もっとシンプルで高速なＯＳ
が是非とも必要である。ゆえに、そういうＯＳも
あわせて開発する。
コンピューター文化の統合
今まで、多様な開発思想に基づいたいろいろなコンピューターが開発され
てきました。そしてそれらはさまざま評価を受け、競争を繰り返していまし
た。そういうところへ、ウィンドウズが普及し、それに伴いＡＴ互換機の普
及が加速され、各社は独自仕様のコンピューターを生産しなくなってしまい
ました。それでは、ウィンドウズ以外のＯＳ、ＡＴ互換機以外のコンピュー
ターは劣っていたのでしょうか？僕は違うと思います。
もちろん、ウィンドウズが普及したのはそれなりに長所があるためであり
また、ＡＴ互換機が普及したのもそれなりに理由はあります。僕の考えると
ころでは、ウィンドウズ普及の最大の原因はほとんどのソフトウェアがウィ
ンドウズ対応で開発されるようになったからだと思います。またＡＴ互換機
普及の理由は、ウィンドウズさえ動けば基本的にどんな機種でもよく、そう
なると生産コストが安いＡＴ互換機の人気が高くなるのは当然なのです。
僕は、今ではＡＴ互換機も使っていますが、以前まではＦＭ−ＴＯＷＮＳ
という機種を使っていました。当時このパソコンを選んだ理由に、先進的な
開発思想に基づく基本性能の高さがありました。ＯＳは僕の満足する機能を
提供してくれたわけではありませんでしたが、それでも他のものに比べれば
見劣りするわけではなく、僕は満足でした。しかし、この機種は市場で充分
なシェアがとれませんでした。そのせいで、この機種に対応したソフトウェ
アの増加の伸びも頭打ちになり、その後ウィンドウズに押されてシェアはど
んどん下がり、今ではほとんど見かけません。
僕には、どうしてもこの機種が開発思想や基本性能で負けたとは思えませ
ん。単に、シェア取りに破れただけなのではないでしょうか？そして、もし
そうだとしたら、そんなことだけでこの機種は市場から姿を消してもいいの
でしょうか？
僕が他にも思い当たるのはＸ６８０００シリーズです。僕は、この機種を
直接使ったことはありませんが、大変に先見のある基本性能を備えていたと
思います。この機種も今はあまり見かけません。・・・僕は、不勉強のせい
か他の例をあまり知らないのですが、他にも優れた性能を持っていたのにシ
ェアにおいて大勢になれず、そしてそれだけの理由で市場に顔を見せなくな
った機種は数多いと思われます。
僕は、各機種の性能の違いが生み出すソフトウェアの多様性の違いは一つ
の文化を構成していると考えています。機種ごとに個性があり、得意分野が
あり、それらはお互いに違ったり、また重なったりしているのです。僕はこ
れをコンピューター文化だと考えています。ですから、新しい開発思想によ
り新しいコンピューターが開発されたときは新しいコンピューター文化の開
花であり、そして、競争に勝てずに市場から姿を消し、さらにみんなが見捨
ててしまったときにそのコンピューター文化は滅びます。
僕の印象では、今の競争システムでは新規参入のコンピューター文化はそ
の善し悪しにかかわらず、競争に生き残るのは困難だと思います。それは、
単なるシェア取りがメインであり、性能の優劣は二の次だからです。よって
もし、シェア争いと競争が無縁になれば、性能の優劣による競争が実現でき
ると考えます。そしてもしそのような競争が可能ならば、旧来のコンピュー
ター文化も再度競争の場に復帰する資格は充分あると思います。
そして、僕はそのシェア争いと性能による競争を分離する一つの方法を考
案しました。それがエミュレーターです。エミュレーターというのは、本来
その機種では実行不可能なソフトウェアを実行可能にするソフトウェアです
。これにより、機種の差があってもソフトウェアにはなんの変更をも加える
ことなく実行できます。従って、ソフトウェアを開発する側は、素直にその
ソフトウェアを開発しやすいコンピューターを選択して、そのコンピュータ
ー専用に開発すればいいことになります。そして、それを選んで使う人は、
自分にもっとも適したソフトウェアを使えばいい訳です。
ウィンドウズをもって、コンピューター文化は統合されると考える人もお
られると思います。しかし、僕はそれには異議を唱えます。ウィンドウズは
ある一つのコンピューター文化に過ぎず、ウィンドウズの目指す文化の統合
はその一つの文化を残して残りの文化を絶滅させることです。僕は、そんな
ことで統合なんて言って欲しくありません。僕の考える統合は全ての文化が
互いに共存し、共生していく中で長所を生かしあう状態なのです。
プログラム言語の統合
現在、たくさんのコンピュータープログラム言語が存在します。今ではコ
ンパイラ型の言語が大変に普及していますが、以前はインタープリタ型の言
語もたくさんありました。一般に、コンパイラ型はデバッグは困難であるが
実行速度は高速で、インタープリタ型はデバッグは容易だが実行速度が遅い
と言われています。しかし、僕は基本的にはインタープリタ型でありながら
比較的高速に実行できる言語翻訳形態を考案しました。
この言語翻訳形態は、少しでもエミュレーターを高速に実行できないか、
ということを考えているときに思いついたものです。そして僕の計画では多
様な言語のそれぞれが互いにリンクできるように配慮し、プログラム言語を
統合します。これにより、プログラマーはアルゴリズムを記述する言語をル
ーチンごとに選択できるようになり、先の新しい言語翻訳形態とあわせて、
僕はプログラマーの負担が減少すると考えています。
そしてより高度な世界へ
僕の計画では、上記に掲げたエミュレーター／言語をスムーズに実現する
ために土台となるＯＳから作り直すことにしました。このＯＳの最大のポイ
ントはＯＳとしての基本性能の充実であります。すなわち、完全な安定性、
柔軟性、そして、仕様の完全公開を製作の信念に据えています。このＯＳが
ＯＳＡＳＫなのでありますが、特徴を簡単に説明します。当然のことながら
以下に述べていることは机上の計算や直感的な見通しが含まれているので、
実物ができるまでは、本当のところは分かりません。
ＯＳＡＳＫは大変コンパクトです。カーネルや主要なルーチンは全てアセ
ンブラで書かれます。システム全体で、１Ｍバイトを越えることはないはず
です（もちろん、壁紙などのデーターの容量はこの中には含まれていない）
。ＯＳＡＳＫは再起動／リセットを必要としません。まず、アプリケーショ
ンがどんなに暴走しようとも、他のタスクには全く干渉しないという環境を
保証します。無論、こんなことはＯＳとして当たり前のことで、それを実現
しない既存のいくつかのＯＳはＯＳとしては未完成だと思っています。また
システム環境の変更などがあった場合も再起動を要求しないようにするつも
りです。
仮想記憶にも当然対応しています。僕の思いつく中でもっとも高速なアル
ゴリズムを採用しますが、それがどの程度の高速性を発揮するのかまだ分か
りません。完成してから評価して下さい。ネットワークやセキュリティーの
サポートも可能です。また、既存のメディアのフォーマットは相互に読み書
き可能になるようにしていきますが、このＯＳＡＳＫに最適化した専用のフ
ォーマットも開発します。
プログラマーには以下のメリットがあります。アプリケーションが暴走し
た場合でも、ワークエリアなどを含めて、アクセスしたデーターは可能な限
り温存できます。これはデバッグ中は便利であると考えます。また、機種に
依存するようなソフトウェアもサポートします（適合機種でない場合は、エ
ミュレーターが自動起動します）ので、マシンパワーを要求するようなもの
は、積極的に機種に依存して記述できます。また、このＯＳＡＳＫの資料は
ソースも含めて全て公開の予定です。もちろんシェアウェアにはしません。
ですから、完成した暁には、是非おためし下さい。
さて、このＯＳＡＳＫ計画が完了したとき、僕は自分が想像しなかった、
より高度な方向にコンピューター文化が進歩していくと確信しています。コ
ンピューター文化の進歩はいつもそうです。いくつかの技術が進歩すれば、
その和以上のものが生まれています。マルチメディアはその典型的な例でし
ょう。僕はその日が来ることを夢みて、今日もプログラムを続けています。
エミュレーション技術
今までのエミュレーターは（僕の作った９８エミュレーターも含めて）、
エミュレーション対象コードをインタープリタ的に解釈しながら実行するの
が基本でした。しかし、この方法では速度的な限界はすぐに現れ、実際のマ
シンパワーの１割が出せればかなり上出来な方です。ＣＰＵの実行時間のほ
とんどは対象コードの解釈にさかれてしまうためです。そうかといって、コ
ンパイラ的に解釈しようとしても、プログラムは自己の転送や自己書き換え
を起こしうるためにうまくいきません。
僕が今回考案したエミュレーションアルゴリズムはコンパイラ方式を改変
したものといえます。抽象的な言い方をすれば、若干の実行速度を犠牲にし
て、自己書き換えの問題を克服したのです。
具体的にはエミュレーション対象コードをコンパイラ的に翻訳して代替命
令を決定し、「翻訳キャッシュ（仮称）」と名付けられたメモリ領域に書き
込みます。そして、翻訳キャッシュ内のコードを実行します。普段はこれを
繰り返しますが、ループなどで同じコードが実行されるような場合は、実行
キャッシュ内へ分岐するように翻訳すれば、ループ中は翻訳のオーバーヘッ
ドはありません。また、自己書き換えが起こりうると思われるコードを翻訳
する時はチェックルーチンも翻訳内容に盛り込ませます。そして、自己書き
換えが起こったときには、翻訳キャッシュをフラッシュします。
このアルゴリズムは、翻訳キャッシュがかなりヒットしないと、効果があ
りません。ミスヒット時の処理のコストは従来のインタープリタ型エミュレ
ーターの何倍もあります（キャッシュの管理をするため）。しかし、僕は翻
訳キャッシュは猛烈にヒットすると考えています。根拠は以下の通りです。
概算方法を紹介します。仮に１Ｍバイトのプログラムコードがあったとし
ます（これ以上でかいコードはそうそう存在しないと思われます）。もし、
ＣＰＵが１命令あたりに平均４クロックを消費して、１命令の平均コード長
は４バイトであると仮定しましょう。そしてもしいっさい分岐せずに頭から
最後まで実行した場合（このコードをエミュレーションするとなると、全く
翻訳キャッシュはヒットしません。最悪のケースです）、消費クロック数は
たったの１Ｍクロックです。つまり、２０ＭＨｚのＣＰＵなら、こんなのは
１秒もかかりません（実は僕はこの概算結果をにわかには信じられませんで
した。ＣＰＵって１Ｍくらいのコードなら１秒もかからずに実行できる・・
・ペンタの２００なら、２００Ｍバイトで１秒？？？）。しかし、１Ｍバイ
トものコードをたったの１秒で終了するということはきわめて希です。そう
なると残りの実行時間は以前の実行箇所と同じところを実行していることに
なります。つまり「翻訳キャッシュ」はヒットするのです。この前提を仮定
すれば３０分の実行時間に対して（自己書き換えがないものとして）、実に
キャッシュヒット率は９９．９９７％になります。ですから、翻訳さえうま
くやれば、移植されたものと遜色ない速度が出せると考えられます。
僕のエミュレーションアルゴリズムではエミュレーション対象コードや必
要なデーターの他に翻訳キャッシュやそれを管理するワークエリアが必要で
す。おそらく、従来のエミュレーターの２倍以上のメモリを必要とするでし
ょう。それゆえに高速な仮想メモリをサポートする必要があります。そして
それをフォローするのがＯＳＡＳＫというＯＳなのです。
上記のアルゴリズムは、友人に、インタープリタとコンパイラの説明をし
ているときに考案されました。そのとき僕は以下のように説明しました。
インタープリタ言語っていうのは、一つずつ翻訳して実行するから、実行
に先立って準備することは何もいらないけど、遅いんだ。逆にコンパイラ言
語は最初にどかっと翻訳してしまうから直接マシン語で書いたように速い。
でも、最初に翻訳しないといけないから、結構まとまった時間がかかって、
それが面倒なんだよね。一般には、コンパイラは実行が速いけどデバッグが
面倒、インタープリタは実行は遅いがデバッグは容易、というところかな？
ここまで説明したときに思ったんです。考えてみるとコンピューターって
バカだよな、インタープリタで翻訳したことを覚えておいて、同じところを
実行するときは翻訳結果をそのまま使えばいいのに・・・。そして、僕はそ
れを「翻訳キャッシュ」と名付け、そういう言語を作ったらどうなるかな？
と考えました。そのため、このアルゴリズムは言語の翻訳方法としても有効
であります。そして、このアルゴリズムをそっくりエミュレーターに応用し
たのが僕のエミュレーターアルゴリズムなのです。
現在のところ、机上の計算ばかりが先行していて、実試験は行っていませ
ん。ですからこのアルゴリズムが絵に描いた餅に終わる可能性はあります。
僕はとにかく製作に向けて励んでおります。動作するようになったら、是非
お試し下さい。
最適化の技術
エミュレーターはそのままエミュレーションしただけではどうやっても本
物よりも遅くなります。しかし、それは嫌なのであれこれ考えています。
エミュレーション中は、通常コンパイル時に行われる最適化とはまた違っ
た最適化ができるのではないかと考えています。なぜなら、エミュレーショ
ン中は実行状況を調査しながら動的な最適化が可能だからです。しかし、こ
れは両刃の剣で、実行状況の調査を詳しくやりすぎると、処理が重くなりエ
ミュレーション性能が低下していまいます。・・・僕はまだこの方面での決
定的なアイデアは持っていません。ただ、よく呼ばれる汎用ルーチンが検出
されて、さらにそのパラメーターが固定的なら、そのパラメーターに特化し
て高速に処理できるルーチンを生成し、パラメーターによってはそこへ分岐
させることで高速化がねらえるかな？・・・という漠然な印象はあります。
またこれは動的ではありませんが、ＣＰＵの並列処理が効率的に処理できる
ように命令の並べ替えを行ってもいいと思います。
製作の障害
最大の障害は「時間がない」、これに尽きます。もちろん、他にも、
もっと僕の頭を賢くしてほしい
Windows95がハングしてメンテに時間を割かれるのはもういやだ
というのがあります。どうにかなりませんかね？
現状
現在、ＴＯＷＮＳ版のＯＳＡＳＫを開発中です。これが出来次第、デバイ
スドライバを入れ替えてＡＴ版も製作予定です。その次はエミュレーターか
な？
| 日付 | 開発状況 |
|---|
| 1997年03月 | 仕様を煮詰めて、プログラミングに取りかかった。 |
|---|
| 1997年04月 | システムコール周りの仕様を作り始めた。プログラミングはいったん中断。 |
|---|
| 1997年05月 | ファイル管理関係／メモリ管理関係の仕様の改善。プログラミングは９月以降に予定。 |
|---|
| 1997年06月 | ネットワーク関係の仕様についての考察。 |
|---|
| 1997年07月 | セキュリティー関連・仕様の総括。 |
|---|
| 1997年08月 | ODPがグラフィック関係のプログラムを書いた。川合は試験勉強に集中。 |
|---|
このページに関するお問い合わせは川合秀実(kawai＠osask.jp)まで
川合秀実のホームページへ戻る