* 私にとってのOS #1
-(by [[K]], 2023.05.31)

** (0) はじめに
-私はかつて、OSASKという自作OSを作っていました。今はこれは第一世代OSASKと呼ばれています。AT互換機（いわゆるWindowsパソコン）とFM-TOWNS、NEC PC-98シリーズで動作しました。
-この第一世代OSASKは、「30日でできる！OS自作入門」で作るような普通のOSでした。ここまでは何の問題もないと思います。

-でもその後、第二世代OSASK（efg01）、第三世代OSASK（OSECPU-VM）と進むにつれて、私の目指すOS像は、容易には理解できないものになっていると思います。それを説明したいです。

** (1) 第一世代OSASK（エミュレータOS）
-私のOS開発の最初の動機は、「互換性の問題を解決したい」でした。でも同時に性能も追求したいと思っていました。また省メモリで動作するとか、フロッピィディスク（というかなり低速かつ容量の小さなストレージデバイス）でも快適に動作する、みたいなことも追求していました。

-開発は基本的にはうまくいっていましたが、デバイスの進歩が速いのについていくのが大変になり、グラフィックカードの機能はほとんど生かせず、サウンドの制御方法もわからず、USBもわからず、ネットワークもわからないという状況に至りました。デバイスの動かし方を探求して開発を続けていければ楽しいだろうとは思っていましたが、でも私のやりたいことはこれではない気もして、開発は停滞しました。

** (2) 第二世代OSASK（efg01, OSASK-HB）
-あるとき、ちょっとした思い付きで、適当な機械語ファイルをメモリにロードしてそこにJMPすればローダーみたいなことができると思いました。これはもちろんうまくいきました。これを推し進めて、OSASKのAPIを見直して新しいアプリ形式を考えました。
--第一世代OSASKでは、システムコールはx86のLDTのコールゲートを使っていました（Linuxのソフトウェア割込み方式だと、アプリごとにシステムコールの行き先を変えるのが難しくなります。まあ割り込みハンドラの中で分岐すればできますが、その分速度は落ちます）。でもコールゲートの設定はOSの管轄なので、この仕様のままだとWindows上でローダを作るのが大変になります。そこで、CALL EBPでシステムコールするという仕様に変えました。
-この新しい形式のOSASKアプリは、efg01というローダさえ使えばWindows上やLinux上でほとんどオーバーヘッドなく動きました。これを私は第二世代OSASKとしました。
-そしてこの実行形態であれば、私がデバイスドライバを整備する必要は一切なくなり、システムコールの受付ルーチンがWindowsやLinuxのAPIをたたくだけでよくなりました。つまり第二世代OSASKからみれば、「Windows＝超巨大で32bitモードでも使えるBIOS」なのです。

-私はこのやり方に手ごたえを感じましたし、その後もこの路線を突き進むのですが、しかしあまり大きな声では言わないようにしていました。なぜなら当時はOS開発を楽しむ人が多くいてしかもその人たちはデバイス制御ルーチンを書くことを心から楽しんでいたからです。そんな状況でOS自作の第一人者の私が、「デバイス制御なんか既存OSに丸投げして、自分たちはもっとOSとしてオリジナリティがある部分の開発に専念しようよ！」なんていったら、水を差してしまうことになるのではないかと恐れたためです。
-私の知る範囲ではneriさんだけが、既存OSの上にローダを載せて独自アプリを動かすやりかたに理解を示していました。

** (3) 第三世代OSASK（OSECPU-VM）
-JITコンパイラ技術を使えば、もはやアプリのコードをx86で書いておく必要はないのではないか？とある時思いました。でも私はこのアイデアに自力で到達したのではなく、さきにneriさんがやっていて、それがうらやましくてたまらなくなって真似し始めたのが最初だった気がします。まあJavaはもっとずっと前からそうしていたのですが。
-この方式なら、システムコールをコールゲートにするかソフトウェア割込みにするかnear-CALLにするかとかも、ローダが自由に決められることになります。アプリがx86の機械語に縛られることもなくなり、32bitモードでも64bitモードでもJITコンパイラさえ書き直せばなんでもOKになります。

-x86の制約がなくなったおかげでアプリの小ささは別次元に突入し、私は手ごたえを感じました。すごく満足もしました。

** (4) 第四世代OSASKにむけて
-今も私はJITコンパイラ技術をOSASKのコア技術だと考えています。JITコンパイラを使えば、たとえばMS-DOSのアプリだって64bit上で動かせるはずです（おそらく多くのDOSエミュレータはすでにそうしていると思います）。
-また、OSASKアプリはわざわざバイナリ形式にしなくてもいいのではないかと思っています（サイズを追求したいときはバイナリ形式も使うと思いますが）。ソースコードを書いたらそのまま実行です。・・・ [[easy-C>a23_ec002]] がまさにそんな使い勝手になりつつあります。
--easy-Cより前に作っていたES-BASICやHLXだとまともなJITコンパイラが入っていて速かったのですが、今のeasy-C（つまりHL-9）は、そのあたりをgcc実行モードへ逃げてごまかしているので十分ではありません。でも使い勝手としてはそれほどは違わない印象です。
--浅草のOSCや名古屋のOSCでeasy-Cアプリを5個くらい同時起動してデモしましたが、その画面はかつての第一世代OSASKのデモみたいな感じでした（アプリは全部違いましたが）。・・・結局私のやっていることは変わらないなーなんて思いました（笑）。
--いや、キューブ回転アプリだけは共通でした！

-これはもはやOSなのか言語処理系VMなのか説明しがたい状況ですが、とにかく私がやりたいことはこういうことなのです。

~
-もしアプリケーションをソースコードのままで実行できるのだとしたら、もはやシェルスクリプトはいらなくなると思われます。
-でも、それ以上のことは特にない？？

** (5) まとめというか感想
-結局私は一番最初のOSASKに、高速性と互換性の両立という目標を設定していました。そうするとバイナリトランスレーションが一番現実的な方法になります。これを実行時にシームレスにやることにすれば、それはまさにJITコンパイラで、そうしたらプログラミング言語処理系に近づくのは必然かもしれません。
-他のOSがこのやり方にあまり近づいてこないのは、互換性の追求をあまり優先していないというか、それはOSじゃなくてアプリケーションの仕事だと割り切っているからなのかな？
-他のOSがこのやり方にあまり近づいてこないのは、互換性の追求をあまり優先していないというか、それはOSじゃなくてアプリケーションの仕事だと割り切っているからなのでしょうか？


* こめんと欄
-掲示板をご利用ください。→[[a23_bbs]]
トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS