ES-VMに関する小さなQ&A集 #1
(0)
- 実際にこういう質問や問い合わせがあったというわけではなく、Q&A形式で書けば読みやすいと思ってそうしているだけです。
(1)
- [Q:0001]なんか第一世代OSASKのころは、今回のようなVM経由じゃなくて、一発変換タイプのドライバを多数そろえるみたいなこと言ってなかったか?そんでもって、その上で、今回のようなVM形式のほうがいいんじゃないかみたいな提案があっても、それだとよくないとか言ってなかったか?
- [A]うう、いきなり核心的なツッコミですね。そうなのです、おっしゃるとおりです。私はN^2個のエミュレータドライバを整備する気でいました、あのときは。だって組み合わせによっては、変換がすごく簡単に行ける場合もあるだろうと思ったからです。しかし私もそれから寿命を20年ほど消費して残りが気になってきたので(註あり)、そういう効率第一かつ実装の苦労を軽視したようなプランは見送って、間にVMをはさむ合理的な設計に切り替えました。つまり前に私に指摘してくれたあの人のほうが断然に正しかったわけです。
- そもそもES-VMはもともとはエミュレータOSをやるために考え出されたものではなく、JITコンパイラを効率よく作るためのものです。今回は、それを流用するだけでエミュレータOSっぽいものが簡単に(まあ前よりは簡単という程度ですが)作れるのではないかと、まあそれだけのことなのです。
- それに技術的には、間にVMが入っている構成のほうが面白いですよね。うまくVMを設計する必要があるので、技術的な難易度は少し上がっているはずです。
- (註)私は難病とかになっているわけではありません。単に一般的なこととして、まあ人生80年程度だとしたら、プログラムをガシガシ作り続けられるのは後どのくらいだろうとか、エミュレータOSもどきができてもその直後に死んだら、使いまくって楽しい思いをする時間がないじゃないかとか、まあそういうことをなんとなく思っただけです。
- [Q:0002]大規模システムは嫌だとか言っているけど、まあ日頃のお前を見ていればその気持ちは本気なんだろうけど、ぶっちゃけ、どのくらいのサイズのものを作るつもりなんだ?あと、どのくらいの時間をかけるつもりなんだ?
- [A]おお、これは即答が難しそうな質問ですね。・・・ええとですね、私としては1年程度で、簡単なコンソールアプリに限定して、Windowsと「はりぼてOS」とで相互に変換できるとか、なんならMS-DOSもOKにしてみるとか、そのくらいのことができるようになりたいとは思っています。
- (えー、なにそれしょぼいって思うかもしれませんが、そこまでできれば、あとは対応APIを増やしていくだけじゃないですか。それは本質的じゃないというか、私がいなくてもAPIに詳しい人が見よう見真似で続きを作れるというか、まあそんな感じですよね。だからそれは急がないでやります。)
- でも、プログラミング言語も作りたいので、そっちに脱線したら1年くらいは遅れるかもしれません。
- サイズですが、上記仕様のものなら、まあシステム合計で100KBとか200KBくらいで何とかなるんじゃないかなーくらいに思っています。見積もりが甘いかもしれませんが・・・。
- [Q:0003]エミュレーションはどのくらいの深さからやるつもりなんだ?qemuみたいに、ページングもセグメンテーションも全部忠実にエミュレーションするとか?
- [A]それはエミュレーション対象によりけりです。たとえばWindowsアプリなら、アプリがセグメンテーションを使うことはないでしょうし、ページテーブルをAPI呼び出しなしで自由に変更することはないと仮定していいでしょう。例外を利用して高度な処理をすることもまずないでしょう。こういう感じで、環境を限定すれば、深いエミュレーションは必ずしも必要ではありません。
- 一方で、qemuみたいにOSを起動して遊びたいみたいな場合は、CPUのモード切替とかも含めた広くて深いレベルのエミュレーションが必要になります。そういうエミュレーションを前提にして、FDのイメージやISOファイルから.exeファイルを作ることも可能でしょう。この場合、その.exeを実行すると、元になったFDイメージやISOから起動した場合がエミュレーションされることになります。
- [Q:0004]これ、もしできたら、WinアプリをES-VMバイトコードにしてさ、そこからまたWinアプリにして、それをまたES-VMバイトコードに変換して・・・みたいなこともできるんだよね?
- [A]もちろんできます。相当に遅くなってデカくはなりそうですが、とにかく原理的には可能です。そういう場合はちゃんと検出して特別処理して元通りになるみたいな、そんな興ざめでつまらない機能を載せる気はないのでご安心ください(笑)。っていうか、こういうのを試してみたくなるのって、いわゆる「男のロマン」みたいなやつですよね。私もそういうのは好きです。
- [Q:0005]これ、どのアプリから変換しても相当に非効率で汚いES-VMバイトコードが出力されるように思うのだけど、本当にそれでいいの?っていうか、きれいなES-VMバイトコードはどうやったら作れるの??
- [A]まずWinアプリやLinuxアプリなど、既存のアプリから作ったES-VMバイトコードが汚いうえに非効率だというのは、全くその通りです。これを自動でそこそこにきれいにするツールを作ればそれはすばらしいですが、でもまあ限界はあるでしょう。これに対して、きれいなES-VMバイトコードは、ES-Cなどの言語で普通に作れる想定です。
- [Q:0006]ES-VMバイトコードをマイコンとかで動かすことってできると思いますか?
- [A]AVRマイコンやPICマイコンでも動く可能性は十分にあります(メモリが足りれば)。ES-VMバイトコードは基本的にシンプルなCPUへの変換を前提に設計しています。ページングやセグメンテーションなどのアドレス変換の機構はを前提にしていませんし、割り込みの仕組みをハードウェアで持っていることも前提にしていません。例外の仕組みがあることも前提にはしていません。
- [Q:0007]なんかさ、ES-VMって既存CPUの最大公約数的な仕様で、シンプル過ぎない?実際のところメジャーなCPUはページングくらいは普通にあるわけでしょ。でもそれらを利用しない前提のバイトコードを作ってさ、そのために必死にアドレス範囲のチェックとかして自衛するようなコードになるわけでしょ。そもそもメジャーなCPUは、「必要だから」ページングとかをハードウェアで持つようになったわけじゃないか。それを全否定している気がするんだよね。それでいいのかな。
- [A]ご指摘のポイントはおおむね理解できます。その方向で考えるとすごくモヤモヤするわけですが、あえて別の角度で考えてみましょう。CPUは確かにページングなどの仮想アドレス機構をハードウェアで持っています。ではその機構を積極的に利用しているのは誰でしょうか。そうOSです。そしてOSはそれぞれのアプリに、十分に広い連続したアドレス空間を提供しているだけです。CPUは特権機構を持っていますが、その特権レベルだってアプリに自由に使わせてくれるわけじゃないです。CPUが優秀でもアプリはそれらの機能を自由に使わせてもらえるわけではないのです。いや、そういうのも全部アプリにいじらせてくれるような奇抜なOSを仮定することはできますし、まあそれが第一世代OSASKの目指すところでもあったのですが、でもそれだと、OSASK以外はES-VMバイトコードを効率よく実行できないということになってしまいます。それだと既存OSにタダ乗りする計画がうまくいかなくなってしまいます。
- そもそも、なぜアドレス変換をハードウェアでやる必要があったのでしょうか。それは本質的にはマルチタスク時にアプリのアドレスが衝突してしまうからだと私は思っています(「30日でできる!OS自作入門」の中でもそんな感じの説明を書きました)。今にして思えば、CPUはそんな機構を持たずに、アプリは全部ダイナミックリンク方式にすればよかったんじゃないかと私は思います。JITコンパイラがこんなに高速に動くのですから、ダイナミックリンクくらい超余裕のはずです。そのほうがCPUはシンプルになって電力効率が良くなって、パイプラインも短くなって、メリットがたくさんあったのではないでしょうか。
- [Q:0008]ES-VMからJavaScriptに変換できますか?もしこれができたらブラウザでも動かせますよね??
- [A]おおなるほど、それは原理的にはできそうな気がします!
- [Q:0009]いっそ、ES-VMバイトコードなんかに変換せずに、JavaScriptを共通の中間形式に採用したらいいんじゃないのかな?そうすればすでにほとんどの環境で動くよね。
- [A]そりゃあブラウザが動くような環境でならJavaScriptは普通に動きますが、自作OSとかにJavaScript処理系を移植できると思いますか?どう考えても大変すぎです。だから私はそのアイデアには乗れません。一方で、ES-VMならOSECPU-VMやES-BASIC程度のものなので、Windows版が完成した後に自作OSなどに横展開するのは容易だと思われます。
- [Q:0010]開発に使っているPCのスペックを教えてください。
- [A]え、これってES-VMに関する質問なのかな?まあいいや。
2015年7月~ | ASUS EeeBook X205TA | 画面:11.6インチ(1366x768)、CPU:Atom Z3735F/1.33GHz/4コア、メモリ:2GB、eMMC:64GB、OS:Win8.1 | 2019年1月~ | mouse MB13ESV | 画面:13.3インチ(1920×1080)、CPU:Celeron N3350、メモリ:4GB、eMMC:64GB、OS:Win10 | 2020年7月~ | HP 14s-dk0000 | 画面:14インチ(1920×1080)、CPU:AMD A4、メモリ:4GB、SSD:128GB、OS:Win10 |
- ということで、基本的に3万円未満(税別)くらいの機種を使っています。解像度が高いやつが好きです(ちなみに会社ではもっといい機種を使っています)。
こめんと欄
|