advcal20161205
の編集
https://khfdpl.osask.jp:443/wiki/?advcal20161205
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2016_10
2016_11
2016_12
BracketName
Essen
Essen0
Essen1
Essen2
Essen3
Essen4
EssenMemo0001
EssenMemo0002
EssenMemo0003
EssenMemo0004
EssenMemo0005
EssenMemo0006
EssenMemo0007
EssenMemo0008
EssenMemo0009
EssenMemo0010
EssenMemo0011
EssenR2
EssenR2_ess03f
EssenR2_ess03h
EssenR2_ess03i
EssenR2_ideas
EssenR2_jit00
EssenR2_jit01
FormattingRules
FrontPage
Help
IP
InterWiki
InterWikiName
InterWikiSandBox
K
KHPC
KHPC_v000doc01
KHPC_v001doc01
KHPC_v002doc01
KHPC_v003doc01
MenuBar
OSC
OSC20181027
OSC20190222
OSC20191123
OSC20230401
OSC20230528
OSC20231021
OSC20240310
OSC20241026
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
SltVA
VariableArray
WikiEngines
WikiName
YukiWiki
advcal20161205
advcal20161206
advcal20161209
advcal20161210
advcal20161215
eoml0001
eoml0002
essen_ex01_0001
impressions
kcl_malloc
khfdpl_result1
members
memo0001
memo0002
note0001
note0002
note0003
note0004
note0005
note0006
oldworks
oldworks00
oldworks06
oldworks12
oldworks13
osaskjp_index
persistent_C
populars
pr20161105
pr20161105b
scsc
seccamp2017
spam_test
uxf
uxf_01
uxf_02
uxp
* エミュレータOSの夢はどうなったのか? -(by [[K]], 2016.12.05) ** (0) -この記事は、「自作OS Advent Calendar 2016」の12/05が空欄だったので急きょ書くことにした記事です。本当は、次回のOSCくらいまで寝かせておこうかと思っていました。 --http://www.adventar.org/calendars/1666 -なんというかせっかく12/04まで続いてきたのに、さらにはあの「neriring2」さんまで書いてくれているのに、私が何もしなかったらきっと後悔するだろうなーと思ったのです。 -ということで、出し惜しみをしないでネタを使います。 ** (1) -そもそもエミュレータOSとはなんなのか?・・・きっと最近の若い人たちはそこからしてわかりませんよね。 -私が最初に作り始めた「第一世代OSASK(おさすく)」はまさに「世界初のエミュレータOS」となることを目指して開発されたものでした。エミュレータOSというのは私がその時に考えた言葉で、つまりエミュレータOSとはなんであるかの定義は私が自由に決められる立場にありました(笑)。 ~ -私は1994年からFM-TOWNSという富士通のパソコンを使って毎日楽しくプログラミングをしていました。しかしその後のTOWNSのシェアはどんどん下がっていき、1995年の冬頃に最終機種が発表された後、新機種が出ることはなくなってしまいました。いわゆるWindowsPC(正確にはIBM PC/AT互換機)に負けてしまったのです。 -私はこれがどうしても納得できませんでした。だってハードウェアの仕様を見る限り、TOWNSの方が圧倒的によくできていたのです(註:当時の見解です)。しかし''ハードウェアにどれほど良い機能があろうとも、その機能を使いこなさなければ、そんな機能は無いのと同じ''です。多くのプログラマは二言目には「移植性」などと言い、つまり特定の機種にしかない機能を活用するプログラマは「いけてない」プログラマということになり、だからTOWNSの機能は活用されませんでした。 -私はそんなTOWNSや富士通の技術者が不憫でなりませんでした。 -私は当時から「いけてない」プログラマだったので、何の未練もなく、ハードウェア性能を全部使ってやろうと思いました。まず手始めに「NECのPC-9801VX2のソフトウェアをTOWNSで動かしちゃうよー」というプログラムを書きました。いわゆるエミュレータです。これを1996年に発表しました。TONWSのハードウェア機能を使えばPC-98シリーズのエミュレータなんて簡単に作れると当時の私は豪語しており、その失言の責任を取る形で作りました(笑)。 -これは大成功で、十分な速度で動きました。60KBくらいのサイズでした。この速度もサイズも当時のエミュレータとしては驚異的で、多くの人にほめられました。 -私はやはり自分の考えに間違いはなかったと確信し、ついにエミュレータOSという構想を持つようになります。これは、OSはエミュレータ技術を取り入れて再設計すべきで、そうすればもっともっとよくなる、という主張です。 -もしエミュレータの存在をあてにしてよければ、OSの開発者は過去のバージョンとの互換性を気にしなくてよくなるはずです。いつでも「この設計こそ最善である」と信じる設計を採用できます。おそらく速度も速くメモリの使用効率もよく、何もかも理想的になるはずです。そしてアプリケーションはエミュレーションによって実行されます。エミュレーションとはいっても、QEMUのようにウィンドウの中に別のPCがあるようなものでは使いやすくはないと思いますので、普通のウィンドウとして機能し、コピー&ペーストなども自由にできて、つまりエミュレーションしていることをほとんど意識しないわけです。自分が使っているのはTOWNS上のOSASKだけど、気づいたら今遊んでいるゲームはMacOS用のゲームだったとか、そんな感じで、どのバイナリがどの機種のどのOSのものかなんて気にしないで使えたらいいと思ったのです。移植なんていう非生産的な作業を終わらせたかったのです。 -特定の機種にしかないマイナーなハードウェア機能であっても遠慮なく使えます。もしそのハードウェアを持っていない機種で実行した場合は自動でエミュレーションされるので問題ないのです。エミュレータOSさえあれば、すべてのハードウェアですべてのソフトウェアが実行できる、そんな未来を描いていました。 -私がこのエミュレータOSの構想で実現したかったことは何か?それは本当の一番が誰なのか決めようということでした。つまり(たとえば)TOWNSはAT互換機に負けてないということを証明したかったのです。ソフトがないからとかいうくだらない理由でハードウェアの勝ち負けが決まるのが納得できなかったのです。 -そしてそういう時代が来れば、ハードウェア屋さんも腕によりをかけていいハードウェアを作ってくれると信じていました。「こんな機能作ってもどうせソフトが使ってくれないからなー」とか言って最初からいじけていて、せっかくのアイデアをカタチにしてくれないのは悲しすぎるじゃないですか。そういうことを終わらせたかったのです。 ** (2) -こうして夢いっぱいのOSASKの開発が始まり、応援してくれる人も増えてコミュニティはどんどん大きくなってきたのですが、あるとき私は疑問を感じます。 -たとえば「hello, world」を表示するプログラムがあったとします。これがたまに100KBとかになっているわけですが、それを見てムムムと思いました。なんだこのプログラムは!・・・実行速度が遅いプログラムに関しては、エミュレーションするときに静的&動的に解析すれば、実機よりも速いエミュレータも作れるだろうから問題ないけど、サイズが大きいプログラムっていうのはどうなんだろうと。エミュレータ内部で最適化によってプログラムが小さくできても、結局はこの大きなプログラムがそのまま流通するわけで、つまりサイズの大きくて出来のよくないプログラムが普及するだけじゃないかと。 -エミュレータOSによって全てのソフトウェアがすべてのハードウェアで十分に高速に動くとしたら、プログラムはどこで優劣が決まるべきなんだろう。それは内容とサイズじゃないか。もし同じ処理結果になるのだったら、小さいプログラムのほうがいいだろう。そうでなければディスクの無駄だし、ネットワーク回線の無駄だ。そういう目で見ると、世間のプログラムはどいつもこいつも太ってぶよぶよしていないだろうか?こんなものを延命させるためにエミュレータOSを書いている場合なんだろうか?そもそもエミュレータを書いてまで延命させたいプログラムってどのくらいあるんだろうか?それ以外のものについては、まずは全部書き直すべきなんじゃないだろうか? -となると、今私がやるべきことはエミュレータOSの開発ではなく、ソフトウェアを小さく作るための技術の確立なんじゃないだろうか。といっても魔法みたいなことをしたり限界を超える必要はない。要するに無駄がなければいいんだ。 -こうして私は取りつかれたようにアプリのサイズを小さくすることに情熱をかけました。 --第二世代OSASK(OSASK-HB)[2008年04月~] --第三世代OSASK(OSECPU-VM)[2013年03月~] → [[oldworks13]] -第三世代OSASKまできて、ついに私は自分がそれなりに納得できるレベルに到達しました。第三世代OSASKでは、私以外の人がプログラムを書いても簡単に小さいプログラムが作れました。作った本人も驚くくらいの非常識な小ささです。 -そしてこの第三世代OSASKはJavaのような仮想バイトコードを採用していたので、いかなる実機でもそのままで動かすことはできず、つまりどの機種上でもエミュレータ(バーチャルマシン)が必須でした(既存のCPUの命令セットはどれもこれも無駄が多くて話にならなかったのです)。そして第三世代OSASKのためのVMは、Windows用、MacOS用、Linux用が作られて、ついにはラズベリーパイにまで移植されました。つまり、エミュレータOSの夢は、当初の形とはやや異なっていますが、しかしある程度は実現し始めているのです。 ** (3) -現在私はEssen(えっせん)という名前のプログラミング言語を作っています。いや、プログラミング言語を自作するぜ!なんていう話はよくある話なので聞き飽きるくらいに聞いていると思いますが、EssenはエミュレータOSちっくなプログラミング言語です(というか、私はもう一生エミュレータOS的な発想から抜けられないと思います)。 -エミュレータOSに理想があったように、Essenにも理想があります。Essenは「本当にいいプログラミング言語とはなんなのか」を追求したいのです。 -まず最初に私がEssenに要求したことは、「Essenが他の言語をエミュレーションできるか」ということでした。たとえばC言語では関数を定義することで「命令」を増やしていけます。C++ではclassを定義することで型を増やしていけます。じゃあ構文は?演算子は?そういうものを自由に追加定義できたら、EssenがC言語みたいになったり、Pascalみたいになったり、Lispみたいになったり、BASICみたいになったり、そういうふうに「化けられる」でしょうか?既存言語に変身できるくらいの自由度があれば、Essenの中で最高のプログラミング記法を探す旅ができそうです。 -しかし、結論からいうと、Essenでは完全なエミュレーションはできないと分かりました。自由度を上げていくと統一的な方法ではパースできなくなり、今の私のプログラミングスキルでは実現が難しいのです。ということで、それっぽい記法までは使えるけど、完全に既存言語に互換というほどじゃないです。・・・でも、既存言語そのものを部分的に混ぜることはできそうです。つまりインラインアセンブラのように、インラインC++とかインラインRubyとかそういうものです。 -エミュレータOSでは、すべてのハードウェアですべてのソフトウェアが問題なく動くことを目指していました。Essenでは「どうぞ好きな言語で書いてください、それを実行します」を目指しています。完全にはできないかもしれないけど、限界まではやり切りたいです。 -このプログラム、なんかすごくいい感じなんだけど、どうしてもこの部分だけいけてない。だから直したいんだけど、Haskellだからどう直せばいいのかわからない。この部分だけC言語で直せたらなー、みたいな夢をかなえたいのです。 -(ちなみにEssenに至る前にEssenとほぼ同じ理想を持ったKH-FDPLというプログラミング言語の開発プロジェクトがありましたが、それは失敗しました・・・。) ** (4) おまけの余談 -http://www.adventar.org/calendars/1666 はご覧のとおり空きがいっぱいあります。だから全部埋めようという気持ちになりきれないのですが、でも埋まってきてあと少しになったら、頑張りたい気持ちになると思うんです。もし残り5マスとかになって、でも書き手が見つからなくて困ったら、私もまた何か書こうと思っています。 -ということで、協力者募集! * こめんと欄 #comment
タイムスタンプを変更しない
* エミュレータOSの夢はどうなったのか? -(by [[K]], 2016.12.05) ** (0) -この記事は、「自作OS Advent Calendar 2016」の12/05が空欄だったので急きょ書くことにした記事です。本当は、次回のOSCくらいまで寝かせておこうかと思っていました。 --http://www.adventar.org/calendars/1666 -なんというかせっかく12/04まで続いてきたのに、さらにはあの「neriring2」さんまで書いてくれているのに、私が何もしなかったらきっと後悔するだろうなーと思ったのです。 -ということで、出し惜しみをしないでネタを使います。 ** (1) -そもそもエミュレータOSとはなんなのか?・・・きっと最近の若い人たちはそこからしてわかりませんよね。 -私が最初に作り始めた「第一世代OSASK(おさすく)」はまさに「世界初のエミュレータOS」となることを目指して開発されたものでした。エミュレータOSというのは私がその時に考えた言葉で、つまりエミュレータOSとはなんであるかの定義は私が自由に決められる立場にありました(笑)。 ~ -私は1994年からFM-TOWNSという富士通のパソコンを使って毎日楽しくプログラミングをしていました。しかしその後のTOWNSのシェアはどんどん下がっていき、1995年の冬頃に最終機種が発表された後、新機種が出ることはなくなってしまいました。いわゆるWindowsPC(正確にはIBM PC/AT互換機)に負けてしまったのです。 -私はこれがどうしても納得できませんでした。だってハードウェアの仕様を見る限り、TOWNSの方が圧倒的によくできていたのです(註:当時の見解です)。しかし''ハードウェアにどれほど良い機能があろうとも、その機能を使いこなさなければ、そんな機能は無いのと同じ''です。多くのプログラマは二言目には「移植性」などと言い、つまり特定の機種にしかない機能を活用するプログラマは「いけてない」プログラマということになり、だからTOWNSの機能は活用されませんでした。 -私はそんなTOWNSや富士通の技術者が不憫でなりませんでした。 -私は当時から「いけてない」プログラマだったので、何の未練もなく、ハードウェア性能を全部使ってやろうと思いました。まず手始めに「NECのPC-9801VX2のソフトウェアをTOWNSで動かしちゃうよー」というプログラムを書きました。いわゆるエミュレータです。これを1996年に発表しました。TONWSのハードウェア機能を使えばPC-98シリーズのエミュレータなんて簡単に作れると当時の私は豪語しており、その失言の責任を取る形で作りました(笑)。 -これは大成功で、十分な速度で動きました。60KBくらいのサイズでした。この速度もサイズも当時のエミュレータとしては驚異的で、多くの人にほめられました。 -私はやはり自分の考えに間違いはなかったと確信し、ついにエミュレータOSという構想を持つようになります。これは、OSはエミュレータ技術を取り入れて再設計すべきで、そうすればもっともっとよくなる、という主張です。 -もしエミュレータの存在をあてにしてよければ、OSの開発者は過去のバージョンとの互換性を気にしなくてよくなるはずです。いつでも「この設計こそ最善である」と信じる設計を採用できます。おそらく速度も速くメモリの使用効率もよく、何もかも理想的になるはずです。そしてアプリケーションはエミュレーションによって実行されます。エミュレーションとはいっても、QEMUのようにウィンドウの中に別のPCがあるようなものでは使いやすくはないと思いますので、普通のウィンドウとして機能し、コピー&ペーストなども自由にできて、つまりエミュレーションしていることをほとんど意識しないわけです。自分が使っているのはTOWNS上のOSASKだけど、気づいたら今遊んでいるゲームはMacOS用のゲームだったとか、そんな感じで、どのバイナリがどの機種のどのOSのものかなんて気にしないで使えたらいいと思ったのです。移植なんていう非生産的な作業を終わらせたかったのです。 -特定の機種にしかないマイナーなハードウェア機能であっても遠慮なく使えます。もしそのハードウェアを持っていない機種で実行した場合は自動でエミュレーションされるので問題ないのです。エミュレータOSさえあれば、すべてのハードウェアですべてのソフトウェアが実行できる、そんな未来を描いていました。 -私がこのエミュレータOSの構想で実現したかったことは何か?それは本当の一番が誰なのか決めようということでした。つまり(たとえば)TOWNSはAT互換機に負けてないということを証明したかったのです。ソフトがないからとかいうくだらない理由でハードウェアの勝ち負けが決まるのが納得できなかったのです。 -そしてそういう時代が来れば、ハードウェア屋さんも腕によりをかけていいハードウェアを作ってくれると信じていました。「こんな機能作ってもどうせソフトが使ってくれないからなー」とか言って最初からいじけていて、せっかくのアイデアをカタチにしてくれないのは悲しすぎるじゃないですか。そういうことを終わらせたかったのです。 ** (2) -こうして夢いっぱいのOSASKの開発が始まり、応援してくれる人も増えてコミュニティはどんどん大きくなってきたのですが、あるとき私は疑問を感じます。 -たとえば「hello, world」を表示するプログラムがあったとします。これがたまに100KBとかになっているわけですが、それを見てムムムと思いました。なんだこのプログラムは!・・・実行速度が遅いプログラムに関しては、エミュレーションするときに静的&動的に解析すれば、実機よりも速いエミュレータも作れるだろうから問題ないけど、サイズが大きいプログラムっていうのはどうなんだろうと。エミュレータ内部で最適化によってプログラムが小さくできても、結局はこの大きなプログラムがそのまま流通するわけで、つまりサイズの大きくて出来のよくないプログラムが普及するだけじゃないかと。 -エミュレータOSによって全てのソフトウェアがすべてのハードウェアで十分に高速に動くとしたら、プログラムはどこで優劣が決まるべきなんだろう。それは内容とサイズじゃないか。もし同じ処理結果になるのだったら、小さいプログラムのほうがいいだろう。そうでなければディスクの無駄だし、ネットワーク回線の無駄だ。そういう目で見ると、世間のプログラムはどいつもこいつも太ってぶよぶよしていないだろうか?こんなものを延命させるためにエミュレータOSを書いている場合なんだろうか?そもそもエミュレータを書いてまで延命させたいプログラムってどのくらいあるんだろうか?それ以外のものについては、まずは全部書き直すべきなんじゃないだろうか? -となると、今私がやるべきことはエミュレータOSの開発ではなく、ソフトウェアを小さく作るための技術の確立なんじゃないだろうか。といっても魔法みたいなことをしたり限界を超える必要はない。要するに無駄がなければいいんだ。 -こうして私は取りつかれたようにアプリのサイズを小さくすることに情熱をかけました。 --第二世代OSASK(OSASK-HB)[2008年04月~] --第三世代OSASK(OSECPU-VM)[2013年03月~] → [[oldworks13]] -第三世代OSASKまできて、ついに私は自分がそれなりに納得できるレベルに到達しました。第三世代OSASKでは、私以外の人がプログラムを書いても簡単に小さいプログラムが作れました。作った本人も驚くくらいの非常識な小ささです。 -そしてこの第三世代OSASKはJavaのような仮想バイトコードを採用していたので、いかなる実機でもそのままで動かすことはできず、つまりどの機種上でもエミュレータ(バーチャルマシン)が必須でした(既存のCPUの命令セットはどれもこれも無駄が多くて話にならなかったのです)。そして第三世代OSASKのためのVMは、Windows用、MacOS用、Linux用が作られて、ついにはラズベリーパイにまで移植されました。つまり、エミュレータOSの夢は、当初の形とはやや異なっていますが、しかしある程度は実現し始めているのです。 ** (3) -現在私はEssen(えっせん)という名前のプログラミング言語を作っています。いや、プログラミング言語を自作するぜ!なんていう話はよくある話なので聞き飽きるくらいに聞いていると思いますが、EssenはエミュレータOSちっくなプログラミング言語です(というか、私はもう一生エミュレータOS的な発想から抜けられないと思います)。 -エミュレータOSに理想があったように、Essenにも理想があります。Essenは「本当にいいプログラミング言語とはなんなのか」を追求したいのです。 -まず最初に私がEssenに要求したことは、「Essenが他の言語をエミュレーションできるか」ということでした。たとえばC言語では関数を定義することで「命令」を増やしていけます。C++ではclassを定義することで型を増やしていけます。じゃあ構文は?演算子は?そういうものを自由に追加定義できたら、EssenがC言語みたいになったり、Pascalみたいになったり、Lispみたいになったり、BASICみたいになったり、そういうふうに「化けられる」でしょうか?既存言語に変身できるくらいの自由度があれば、Essenの中で最高のプログラミング記法を探す旅ができそうです。 -しかし、結論からいうと、Essenでは完全なエミュレーションはできないと分かりました。自由度を上げていくと統一的な方法ではパースできなくなり、今の私のプログラミングスキルでは実現が難しいのです。ということで、それっぽい記法までは使えるけど、完全に既存言語に互換というほどじゃないです。・・・でも、既存言語そのものを部分的に混ぜることはできそうです。つまりインラインアセンブラのように、インラインC++とかインラインRubyとかそういうものです。 -エミュレータOSでは、すべてのハードウェアですべてのソフトウェアが問題なく動くことを目指していました。Essenでは「どうぞ好きな言語で書いてください、それを実行します」を目指しています。完全にはできないかもしれないけど、限界まではやり切りたいです。 -このプログラム、なんかすごくいい感じなんだけど、どうしてもこの部分だけいけてない。だから直したいんだけど、Haskellだからどう直せばいいのかわからない。この部分だけC言語で直せたらなー、みたいな夢をかなえたいのです。 -(ちなみにEssenに至る前にEssenとほぼ同じ理想を持ったKH-FDPLというプログラミング言語の開発プロジェクトがありましたが、それは失敗しました・・・。) ** (4) おまけの余談 -http://www.adventar.org/calendars/1666 はご覧のとおり空きがいっぱいあります。だから全部埋めようという気持ちになりきれないのですが、でも埋まってきてあと少しになったら、頑張りたい気持ちになると思うんです。もし残り5マスとかになって、でも書き手が見つからなくて困ったら、私もまた何か書こうと思っています。 -ということで、協力者募集! * こめんと欄 #comment
テキスト整形のルールを表示する