ES-BASIC #16
はじめに
そもそもES-BASICとは？
- ここを読む方はおそらく「ES-BASIC」（イーエス・ベーシック）なんて初めて聞く言葉でしょう。ES-BASICは川合が2019年の7月から作っているプログラミング言語です。
- コンパイラでは「ない」ので、ソースコードを食わせて実行ファイルを得る、みたないことはできません。ソースコードを入力するかもしくはロードして、「RUN」することで実行します。つまりインタプリタ型言語（もしくはスクリプト言語）です。
- 実際、かなり手軽に実行できます。
- スクリプト言語としては、PyhthonやRubyが非常に有名ですが、それと同じタイプになります。しかしこれらの言語と比較すると、ES-BASICは実行速度がかなり高速でもあります。
ES-BAISCと自作OSとの関係(1)
- ES-BASICはかなり小さな言語処理系です（100KB程度です）。またグラフィック処理がOSに依存していますが（Windows）、それ以外はCPUにしか依存していません。
- だからこれを「はりぼてOS」に移植するのはそんなには難しくないでしょう。ただ、オリジナルの「はりぼてOS」は「アプリがメモリ上に機械語を生成して、それを実行する」機能をまだ持っていないので（オリジナルでは実行できるのはディスクから読み込んだ部分だけ）、そこは少し拡張してやる必要がありそうです。
- 使ってみると分かりますが、ES-BASICはけっこう楽しい言語なので（それはesbasic0014の画像とかを見ても察してもらえると思いますが）、これが自作OSで動いたらかなり楽しそうです！
ES-BASICと自作OSとの関係(2)
- 私がプログラム言語を分類するときに注目しているポイントの一つに「その言語でOSは作れるのか」というのがあります（笑）。
- ES-BASICがただのコンパイラ言語なら、生成した機械語をOSの中で利用できさえすれば、それで一応「OSが作れる言語」になります。ES-BASICはそもそも機械語生成能力を持っているので、ただのコンパイラにしてしまうことはとても簡単なことですが、しかしそれだとスクリプト言語だからできること（非常に複雑な定数式のコンパイル時評価）などができなくなってしまい、あまり面白くありません。
- もしスクリプト言語のまま、自作OSに使えるようになったら、起動時の環境によって生成する機械語を変化させ、最適な状態で動くことも可能になりそうですし、アプリももう機械語にする必要はなくなって、ES-BASICで書くだけでよくなります。そうすれば、アプリはもうCPUに依存しないで書けるようになるかもしれず（一つの実行ファイルで、すべてのCPUに対応できる！）、夢はかなり膨らみます！！
- スクリプト言語のままであれば、強力なデバッグ機能もそのまま使えるかもしれないので、デバッグは相当にはかどりそうです。
- これって、かつて話題になったJavaOSに似たところがあって、つまりそれを「自作OS＋自作言語」でやってしまおうということで、わくわくが止まらないわけです。
- はたしてどこまでできるのか、どうしたらできるのか、実はまだよくわかっていないのですが、とりあえずES-BASICのコアがOSより先にロードされて、その上でOSやアプリケーションが動くことはほぼ確実だろうと思っています。できればデバイスドライバもES-BASICで書きたいので、そのあたりも悩みどころです。
課題
- この方針での最大の問題は、このための開発をする時間がなかなか確保できそうにないことです。だからまあいつになることやら・・・。
- いやでも、(1)だけならそんなに時間はかからないだろうから、やりたいなー。
追記#1 - [思考実験]バイナリは本当に必要なのか？
- すみません。あえて暴論じみたところから議論を吹っ掛けます。その方が簡潔に書けそうなので。
- 私はOSの自作が好きです。OSを作るときの考えどころの一つとして、「アプリケーションの実行ファイルはどんなものにするか」というのがあると思います。「はりぼてOS」の場合、x86のバイナリをベースとして.hrb形式というのを導入していました。
- これに対し、私は今ES-BASICというJITコンパイラ型の言語を自作していて、これを使うとソースから実行しても、gccで生成した実行ファイルを実行する場合と比べて、14%程度の速度低下で済ませられるという実績を得ています。これをもっとも改良して「平均1%未満にしろ言われたらできるか？」というと、ええ、まあ、たぶんできると思います。そのためのテクニックは頭の中にはあります。まあセコイ技の組み合わせなので、まだやっていないのですが、とにかくできそうな気はしています。
- さてじゃあもし仮にそんなことができたとしたら、私が次に作る自作OSでは、アプリケーションの実行ファイル形式はES-BASICのソースコードにすべきなんでしょうか。それとも、それでもバイナリを採用すべきなんでしょうか。
- ソースコードなら、人間からの可読性は圧倒的に上ですし、機種依存の全くない仕様を策定することも容易でしょう。
- もうバイナリなんて、CPUの中にあるμOp（マイクロオペコード）みたいなもので、人類が気にする必要なんてなくなるのでしょうか？
- だとしたら、コンパイラとかは組み込み屋さんが使うだけになって、基本はみんなJITコンパイラになるのでしょうか？
- ああ、組み込み屋さんだけではなく、OS屋さんもコンパイラ使うかもしれないか・・・。
- いや待て、そもそもOSの構成方法も変わりそうだな・・・。
- まず、言語層がOSよりも下に来ます。このレイヤより上はすべてES-BASICみたいな言語のソースコードだけで書けて、機種依存がなくなります。
- もしこれが実現したら、みんなOSもES-BASICみたいな言語で書けばよくなります。そしたらもうOSを移植しないで済みます。
- ・・・おおお？！これは私が10年以上前に夢想して大失敗したKHBIOS構想にそっくりではないですか！！
- これはJavaのVMにかなり近いです。Javaのアイデアとのわずかな違いは、Javaがバイトコードを「共通のもの」とするのに対して、私のアイデアではもはやソースコードがそのまま「共通のもの」なのです。
- こういう未来がもし来たら、OSの自作は2方向に分裂するかもしれません。
- [1]とにかく低レイヤが好きでたまらない人は、私のようにJITコンパイラ屋さんになる（笑）。
- [2]OSでこういうことがやりたいんだという夢を持つ人は、言語の上でOSを作って夢を叶える。
- [3]何でも自分でやってみたいので、[1]と[2]の両方をやる！！（笑）
- ついでなので書いておきます。セコイ高速化テクニック（笑）についてです。
- [1] JITコンパイル結果をキャッシュする仕組みを作ります。つまり、「このソースを機械語にするとこうなる」的なものをメモリやHDD/SSDに記録しておき、必要に応じてJITコンパイラを介さずにこれを使うようにするわけです。これでコンパイラ時間は初回の1回だけ必要になり、その後は体感できなくなります。
- [2] C言語などでは普通に行われていますが、条件コンパイル的な構文を言語に導入します。これで、速度に敏感なごく一部だけを機種依存な命令列を使って書くことができるようになります。これで特定のCPUやハードだけが持つすてきな機能もちゃんと生かせるようになります。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
