esvm0001
の編集
https://essen.osask.jp/?esvm0001
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
EssenRev4
FormattingRules
FrontPage
Help
InterWiki
InterWikiName
InterWikiSandBox
K
MenuBar
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
SDL2_01
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
a21
a21_acl01
a21_bbs01
a21_challengers
a21_count
a21_edu01
a21_edu02
a21_edu03
a21_edu04
a21_edu05
a21_edu06
a21_edu07
a21_edu08
a21_edu09
a21_edu10
a21_edu11
a21_hlx000
a21_hlx001
a21_hlx001_1
a21_hlx001_2
a21_hlx001_3
a21_hlx002
a21_hlx002_1
a21_hlx003
a21_hlx003_1
a21_hlx004_1
a21_memo01
a21_opt
a21_opt02
a21_opt03
a21_p01
a21_special
a21_tl9a
a21_todo
a21_txt01
a21_txt01_10
a21_txt01_1a
a21_txt01_2
a21_txt01_2a
a21_txt01_2b
a21_txt01_3
a21_txt01_4
a21_txt01_5
a21_txt01_6
a21_txt01_6a
a21_txt01_7
a21_txt01_8
a21_txt01_8a
a21_txt01_9
a21_txt01_9a
a21_txt02
a21_txt02_10
a21_txt02_10a
a21_txt02_10b
a21_txt02_11
a21_txt02_11a
a21_txt02_12
a21_txt02_12a
a21_txt02_12b
a21_txt02_1a
a21_txt02_1b
a21_txt02_2
a21_txt02_2a
a21_txt02_3
a21_txt02_3a
a21_txt02_4
a21_txt02_4a
a21_txt02_5
a21_txt02_5a
a21_txt02_6
a21_txt02_6a
a21_txt02_6b
a21_txt02_6b_rev0
a21_txt02_6x
a21_txt02_7
a21_txt02_7a
a21_txt02_8
a21_txt02_8a
a21_txt02_9
a21_txt02_9a
a22_acl2_01
a22_acl2_02
a22_edu12
a22_intro01
a22_intro02
a22_intro03
a22_memman01
a22_memman02
a22_memman03
a22_memman04
a22_memman05
a22_memman06
a22_memman07
a22_memo01
a22_mingw_debug
a22_txt03
a22_txt03_1a
a22_txt03_1b
a22_txt03_2
a22_txt03_2a
a22_ufcs01
a23_bbs
a23_ec001
a23_ec002
a23_intro00
a23_intro000
a23_intro01
a23_intro02
a23_intro03
a23_intro04
a23_intro05
a23_intro06
a23_intro07
a23_intro08
a23_intro09
a23_intro10
a23_intro10wk1
a23_intro10wk2
a23_intro10wk3
a23_intro11
a23_intro12
a23_intro13
a23_intro13wk1
a23_intro14
a23_intro15
a23_intro16
a23_intro90
a23_intro91
a23_neopixel1
a23_os01
a23_useSelfMade
a23_usm001
a23_usm002
a23_usm003
a23_usm004
a23_usm005
a23_usm006
a23_usm007
a23_usm008
a23_usm009
aclib00
aclib01
aclib02
aclib03
aclib04
aclib05
aclib06
aclib07
aclib08
aclib09
aclib10
aclib11
aclib12
aclib13
aclib14
aclib15
aclib16
aclib17
aclib18
aclib19
aclib20
aclib21
aclib22
aclib23
aclib24
aclib25
aclib_bbs
arm64_01
avm0001
edu0001
edu0002
edu0003
esb02b_hrb
esb_dbg
esbasic0001
esbasic0002
esbasic0003
esbasic0004
esbasic0005
esbasic0006
esbasic0007
esbasic0008
esbasic0009
esbasic0010
esbasic0011
esbasic0012
esbasic0013
esbasic0014
esbasic0015
esbasic0016
esbasic0017
esbasic02a
esc0001
escm0001
essen_hist
esvm0001
esvm0002
esvm0003
esvm0004
esvm0005
esvm0006
esvm_i0
hh4a
idea0001
idea0002
idea0003
impressions
jck_0000
jck_0001
kawai
kbcl0_0000
kbcl0_0001
kbcl0_0002
kbcl0_0003
kbcl0_0004
kbcl0_0005
kbcl0_0006
kbcl0_0007
kclib1_0000
kclib1_0001
kclib1_0002
kclib1_0003
kclib1_0004
kclib1_0005
kclib1_0006
kclib1_0007
kclib1_0008
kclib1_0009
kclib1_0010
kpap0001
members
memo0001
osask4g
osask4g_r2
p20200311a
p20200610a
p20200610b
p20200624a
p20200711a
p20200716a
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
populars
seccamp
seccamp2019
sechack
sechack2019
seclang01
sh3_2020
sh3_2020_kw
sh3_2020_nk
sh3_2021_kw
sh3_2021_nk
sh3_2022_kw
sh3_2023_kw
sh3_kw_hist
termux001
termux002
text0001
text0001a
text0002
text0002a
text0003
text0004
text0005
text0006
text0006a
text0007
text0008
text0010
text0011
text0012
text0013
text0014
text0015
text0016
text0017
text0018
text0019
text0020
text0021
tl1c
tl2c
tl3c
tl3d
* ES-VM #1 -(by [[K]], 2020.06.13) ** (1) -ES-Cでは、いきなりx86の機械語を生成するのではなく、仮想的なCPU(=VM)の機械語を生成して、そのVM用のコードから実CPUの機械語を生成するという仕組みを採用しようと思っています。 -これはx86だけを考えるのなら明らかに無駄です。x86だけ考えていればよいのであれば、こんな余計な中間レイヤはないほうが速いし、処理系は小さくできるのです。・・・しかしx86以外も考えるのであれば、この仕組みは理にかなっています。 -今はx86やx64が主流ですが、今後もそうであるかは不明です。私は将来自作CPUを作るのかもしれません。そうなったら、自作のCPU上でES-Cを動かしたいです。もしこのVMレイヤがあれば、最小限の手間で自作CPUに移植できるでしょう。 -そういうVMレイヤがあったほうがよいのだとしても、自分でわざわざ独自仕様を考えたりせずに、それこそx86の仕様をそのまま使うか、もしくはそのサブセットでいいじゃないかという考え方もできます。この場合、x86であればVM用のコードはそのままかもしくは軽微な変換ですぐに実行できることになります。そして他のCPU上で動かす場合は、変換して動かすことになります。 -しかしこれはうまい方法ではないと思います。なぜならx86よりもレジスタを多く持つCPUはいくつかありますが、x86からこれに変換するとすべてのレジスタを活用しない機械語になってしまうからです。 -またx86は32bitもしくは64bitですが、遠い将来はもっと幅の広いCPUがでてくるかもしれません。そのときに32bitや64bitを前提にしている、ちまちまと計算するプログラムは、広いビット幅を十分には活用できません。 -ということで、VMレイヤの機械語の仕様は、ビット幅に上限がなく、またレジスタ数にも上限がないようなそういうものであるべきです。そしてそれぞれのCPUの実際の仕様に合わせて、必要に応じて多倍長演算したり、レジスタに乗りきらないものはメモリに置くなどして、機械語を生成することになります。 -x86やx64の仕様ではこれらを表現できないので、独自の機械語を考えようと思います。これがES-VMです。 ** (2) -さてES-VMはコンパイラの移植性を高めるためだけの、単なる中間コードなのでしょうか。・・・そういう設計で作ることもできると思いますが、私は直感的にそれでは不十分だと感じています。 -ES-VMは、レイヤとして最下層であるべきです。つまり、実CPUの知識がなくても何も困らないようになっているべきです。 -たとえて言うなら、x86は世代によって内部構成が異なっていますが、それでも最適化の時以外はその内部構成に配慮する必要はありません。実にうまくできています。 -つまりデバッグの際にx86の機械語を見たり、x86のマシンのレジスタの値を見たりするというのはダメだということです。例外で止まったりブレークポイントで止まったりしたときは、ES-VMの命令のどこで止まったのか、その時のES-VMのレジスタはどうなっているのか、メモリはどうなのかなど、すべてES-VMの知識の範囲内で説明できなければいけないという意味です。 --「とりあえずES-VMの機械語からx86に変換したよー、それじゃあとはよろしくねー」はダメだというわけです。 -私は数年前からJITコンパイラを何度か作っていますが、その時に思ったのは、「なぜ21世紀にもなって、x86の機械語の知識がなければやりたいことができないのか」ということでした。プログラミング言語は何度も何度も大きな進化を遂げてきたはずなのに、そして普段はC++とかを使うだけで十分に高度なプログラムが書けるのに、JITコンパイラを作ろうと思ったとたんにすべてのメッキははがれて、機械語の知識が必要になってしまったのです。 gcc → アセンブラ → リンカ → 機械語 --こうなっているおかげで、アセンブラはWindowsの実行ファイル形式がどうなのかとかに煩わされることなく、x86のことだけを考えて作られている(そこはリンカがやってくれる) --gccは、機械語のことを気にしないで、アセンブラを出力すればいい --こういう積み重ねで、プログラミング言語は進化してきた --それなのに、JITコンパイラを作ろうとすると、これらのツールは誰一人としてプログラマを助けてはくれなくて、プログラマは自力で機械語を生成しなければいけないのが現状。 --つまり、既存ツールは、「より下位の知識が全く不要な世界」を十分には構築できていなかった。 //-gccは内部で何度か変換を繰り返して、最終的にアセンブラのソースを出力し、それがx86のアセンブラに入って、それがリンカに入って機械語が出てきます。つまり、JITではない普通のコンパイラに限れば、リンカの上にアセンブラ、その上にコンパイラ、とどんどん積み重ねられて正常進化してきたのです。でもJITコンパイラを作ろうとすると、何も積み重なってなくて、むき出しの地面だったのです。こういうのはいけないのです。 -だからもういかなる時もES-VMより下のレイヤの知識がなくてもいいようにする、それが目標です。 ** (3) -今更なのですが、結局私が第一世代OSASKで掲げたエミュレータOSという構想は、究極的には「移植作業のいらない世界」を作ることでした。そのためのエミュレータOSでした。 -今は、Javaがあり、.NETがあり、Monoがあり、LLVMがあり、JavaScriptがあり、WebAsmがあります。しかしどれも大変に巨大です。私から見れば、絶対にもっと小さくできるはずだと確信するには十分すぎるほど巨大です。 -私はES-VMによって、「移植作業のいらない世界」を作りたいのです。これは私の長年の夢なのです。 ** (4) 提供される機能 -[1]ES-VMのバイトコードとターゲット情報を渡すと、機械語を生成して返してくれる。そういう関数がある。 --これは純粋に単純なフィルタでしかないので、このプログラム自身も究極的にはES-VMのバイトコードで記述可能なはず。これができれば、爆発的な早さでクロスコンパイラを整備できる。 --ターゲットを現在動作中のものにして、返された関数をすぐに呼び出せばJITコンパイラになるし、ファイルとして出力すれば、普通のコンパイラやアセンブラになる。 --どのラベルがどのアドレスになったかなどの情報も提供する。変数やレジスタの割り当て状況なども報告する。型の対応関係も。 --変換に際しては、安全モードと高速モードを提供。 --またステップ実行的なこともできるようにしたい(そういうモードがある)。 --任意の時点で、ES-VMにおけるレジスタや、ES-VMにおけるメモリの状態を確認できる。 -[2](これは年内に作る予定はないけど)x86の機械語を渡すとES-VMのバイトコードを生成する機能もいつか作りたい。 --これができると、Windowsの実行ファイルが「はりぼてOS」で動くとか、ラズベリーパイで動くとか、そういうことができるようになる・・・はず。 --もちろんx86だけではなく、他のCPUやWindows以外のファイルにも対応する。 --まあ、5年後とか10年後だよな、たぶん。 -文章にして書いてみると、かなりかつての「エミュレータOS」がやろうとしていたことに近いなーと思う。 -ES-VMは言語処理系のバックエンドとして考えていたけど、エミュレータOSのバックエンドとしても相当に魅力的な気がしてきた・・・。 ** (5) エミュレータOSとの対応関係 -エミュレータOSでは、OSとエミュレータドライバが連携することで、いろんなソフトウェアをエミュレータOS上でシームレスに実行できるということになっていた。 -ES-VMによる「エミュレータOSもどき」では、たとえばFM-TOWNS用の実行ファイル(~.EXPファイル)が「ソースコード」であって、それをJITコンパイラで即実行してもいいし(これは単なるエミュレータに見える)、コンパイラでWindowsの.exeEファイルにしてもいいし、「はりぼてOS」の.hrbファイルにしてもいい。つまり、言語の考え方でエミュレータOS的なことを実現している。 -つまりこれは言語処理系からエミュレータに発展させたというわけなんだなー。 -この場合、仮にバイトコードコンパイラが完備していれば、すべてのOSがエミュレータOSっぽいものになる。 -そしてエミュレータOSの予言のように、OSは性能で競われるようになるってことか。いい世界だ! * こめんと欄 -今こそ私は Inferno OS を勉強するべきなんじゃないかという気はする。 -- [[K]] SIZE(10){2020-06-25 (木) 17:24:15} #comment
タイムスタンプを変更しない
* ES-VM #1 -(by [[K]], 2020.06.13) ** (1) -ES-Cでは、いきなりx86の機械語を生成するのではなく、仮想的なCPU(=VM)の機械語を生成して、そのVM用のコードから実CPUの機械語を生成するという仕組みを採用しようと思っています。 -これはx86だけを考えるのなら明らかに無駄です。x86だけ考えていればよいのであれば、こんな余計な中間レイヤはないほうが速いし、処理系は小さくできるのです。・・・しかしx86以外も考えるのであれば、この仕組みは理にかなっています。 -今はx86やx64が主流ですが、今後もそうであるかは不明です。私は将来自作CPUを作るのかもしれません。そうなったら、自作のCPU上でES-Cを動かしたいです。もしこのVMレイヤがあれば、最小限の手間で自作CPUに移植できるでしょう。 -そういうVMレイヤがあったほうがよいのだとしても、自分でわざわざ独自仕様を考えたりせずに、それこそx86の仕様をそのまま使うか、もしくはそのサブセットでいいじゃないかという考え方もできます。この場合、x86であればVM用のコードはそのままかもしくは軽微な変換ですぐに実行できることになります。そして他のCPU上で動かす場合は、変換して動かすことになります。 -しかしこれはうまい方法ではないと思います。なぜならx86よりもレジスタを多く持つCPUはいくつかありますが、x86からこれに変換するとすべてのレジスタを活用しない機械語になってしまうからです。 -またx86は32bitもしくは64bitですが、遠い将来はもっと幅の広いCPUがでてくるかもしれません。そのときに32bitや64bitを前提にしている、ちまちまと計算するプログラムは、広いビット幅を十分には活用できません。 -ということで、VMレイヤの機械語の仕様は、ビット幅に上限がなく、またレジスタ数にも上限がないようなそういうものであるべきです。そしてそれぞれのCPUの実際の仕様に合わせて、必要に応じて多倍長演算したり、レジスタに乗りきらないものはメモリに置くなどして、機械語を生成することになります。 -x86やx64の仕様ではこれらを表現できないので、独自の機械語を考えようと思います。これがES-VMです。 ** (2) -さてES-VMはコンパイラの移植性を高めるためだけの、単なる中間コードなのでしょうか。・・・そういう設計で作ることもできると思いますが、私は直感的にそれでは不十分だと感じています。 -ES-VMは、レイヤとして最下層であるべきです。つまり、実CPUの知識がなくても何も困らないようになっているべきです。 -たとえて言うなら、x86は世代によって内部構成が異なっていますが、それでも最適化の時以外はその内部構成に配慮する必要はありません。実にうまくできています。 -つまりデバッグの際にx86の機械語を見たり、x86のマシンのレジスタの値を見たりするというのはダメだということです。例外で止まったりブレークポイントで止まったりしたときは、ES-VMの命令のどこで止まったのか、その時のES-VMのレジスタはどうなっているのか、メモリはどうなのかなど、すべてES-VMの知識の範囲内で説明できなければいけないという意味です。 --「とりあえずES-VMの機械語からx86に変換したよー、それじゃあとはよろしくねー」はダメだというわけです。 -私は数年前からJITコンパイラを何度か作っていますが、その時に思ったのは、「なぜ21世紀にもなって、x86の機械語の知識がなければやりたいことができないのか」ということでした。プログラミング言語は何度も何度も大きな進化を遂げてきたはずなのに、そして普段はC++とかを使うだけで十分に高度なプログラムが書けるのに、JITコンパイラを作ろうと思ったとたんにすべてのメッキははがれて、機械語の知識が必要になってしまったのです。 gcc → アセンブラ → リンカ → 機械語 --こうなっているおかげで、アセンブラはWindowsの実行ファイル形式がどうなのかとかに煩わされることなく、x86のことだけを考えて作られている(そこはリンカがやってくれる) --gccは、機械語のことを気にしないで、アセンブラを出力すればいい --こういう積み重ねで、プログラミング言語は進化してきた --それなのに、JITコンパイラを作ろうとすると、これらのツールは誰一人としてプログラマを助けてはくれなくて、プログラマは自力で機械語を生成しなければいけないのが現状。 --つまり、既存ツールは、「より下位の知識が全く不要な世界」を十分には構築できていなかった。 //-gccは内部で何度か変換を繰り返して、最終的にアセンブラのソースを出力し、それがx86のアセンブラに入って、それがリンカに入って機械語が出てきます。つまり、JITではない普通のコンパイラに限れば、リンカの上にアセンブラ、その上にコンパイラ、とどんどん積み重ねられて正常進化してきたのです。でもJITコンパイラを作ろうとすると、何も積み重なってなくて、むき出しの地面だったのです。こういうのはいけないのです。 -だからもういかなる時もES-VMより下のレイヤの知識がなくてもいいようにする、それが目標です。 ** (3) -今更なのですが、結局私が第一世代OSASKで掲げたエミュレータOSという構想は、究極的には「移植作業のいらない世界」を作ることでした。そのためのエミュレータOSでした。 -今は、Javaがあり、.NETがあり、Monoがあり、LLVMがあり、JavaScriptがあり、WebAsmがあります。しかしどれも大変に巨大です。私から見れば、絶対にもっと小さくできるはずだと確信するには十分すぎるほど巨大です。 -私はES-VMによって、「移植作業のいらない世界」を作りたいのです。これは私の長年の夢なのです。 ** (4) 提供される機能 -[1]ES-VMのバイトコードとターゲット情報を渡すと、機械語を生成して返してくれる。そういう関数がある。 --これは純粋に単純なフィルタでしかないので、このプログラム自身も究極的にはES-VMのバイトコードで記述可能なはず。これができれば、爆発的な早さでクロスコンパイラを整備できる。 --ターゲットを現在動作中のものにして、返された関数をすぐに呼び出せばJITコンパイラになるし、ファイルとして出力すれば、普通のコンパイラやアセンブラになる。 --どのラベルがどのアドレスになったかなどの情報も提供する。変数やレジスタの割り当て状況なども報告する。型の対応関係も。 --変換に際しては、安全モードと高速モードを提供。 --またステップ実行的なこともできるようにしたい(そういうモードがある)。 --任意の時点で、ES-VMにおけるレジスタや、ES-VMにおけるメモリの状態を確認できる。 -[2](これは年内に作る予定はないけど)x86の機械語を渡すとES-VMのバイトコードを生成する機能もいつか作りたい。 --これができると、Windowsの実行ファイルが「はりぼてOS」で動くとか、ラズベリーパイで動くとか、そういうことができるようになる・・・はず。 --もちろんx86だけではなく、他のCPUやWindows以外のファイルにも対応する。 --まあ、5年後とか10年後だよな、たぶん。 -文章にして書いてみると、かなりかつての「エミュレータOS」がやろうとしていたことに近いなーと思う。 -ES-VMは言語処理系のバックエンドとして考えていたけど、エミュレータOSのバックエンドとしても相当に魅力的な気がしてきた・・・。 ** (5) エミュレータOSとの対応関係 -エミュレータOSでは、OSとエミュレータドライバが連携することで、いろんなソフトウェアをエミュレータOS上でシームレスに実行できるということになっていた。 -ES-VMによる「エミュレータOSもどき」では、たとえばFM-TOWNS用の実行ファイル(~.EXPファイル)が「ソースコード」であって、それをJITコンパイラで即実行してもいいし(これは単なるエミュレータに見える)、コンパイラでWindowsの.exeEファイルにしてもいいし、「はりぼてOS」の.hrbファイルにしてもいい。つまり、言語の考え方でエミュレータOS的なことを実現している。 -つまりこれは言語処理系からエミュレータに発展させたというわけなんだなー。 -この場合、仮にバイトコードコンパイラが完備していれば、すべてのOSがエミュレータOSっぽいものになる。 -そしてエミュレータOSの予言のように、OSは性能で競われるようになるってことか。いい世界だ! * こめんと欄 -今こそ私は Inferno OS を勉強するべきなんじゃないかという気はする。 -- [[K]] SIZE(10){2020-06-25 (木) 17:24:15} #comment
テキスト整形のルールを表示する