escm0001
の編集
https://essen.osask.jp/?escm0001
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
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
a24_memo01
a24_osc20240310
a24_osc20241026
a24_raspberrypi01
a24_useSelfMade
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_2024_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-C向けのmemo#1 -(by [[K]], 2020.04.27) ** 2020.04.27 #0 -ES-CとES-BASICは統合する。どうせフロントエンド以外は共通になるし、そもそもそんなに違わない言語だから、別々にメンテナンスすることの方がコストになるはず。 -内部バイトコードフォーマット案 |NOP|00|| |REM1|01 : n|| |REM2|02 : flg : n|| |DEF|04 : flg : id : typ : siz|ローカル変数宣言 / ラベル宣言| |OR |10 : bit : flag : dst : src0 : src1|dst/src0/src1はhh4の24bit形式で足りるだろう| |XOR|11 : bit : flag : dst : src0 : src1|bitはhh4の8bit形式、flagも8bitでいけるだろう| |AND|12 : bit : flag : dst : src0 : src1|命令に16bit形式を採用すると、4+9=13バイト| |ADD|14 : bit : flag : dst : src0 : src1|4+3=7バイトにもできる| |SUB|15 : bit : flag : dst : src0 : src1|| |MUL|16 : bit : flag : dst : src0 : src1|| -bitフィールドはdstなどからわかるので、指定させなくてもいいかもしれない。 -dstに-1を指定させることで、2項形式にできるかもしれない。 --そうすれば、4+4=8バイトにできる。 -符号付きhh4 → (参考) http://osask.net/w/634.html |4bit|00xx|0~3| |8bit|100x:xxxx|0~1f| |12bit|1100:xxxx:xxxx|0~ff| |16bit|1110:0xxx:xxxx:xxxx|0~7ff| |24bit|0111:0100:0xx...xx|0~7fff| |28bit|0111:0101:0xx...xx|0~7ffff| |32bit|0111:0110:0xx...xx|0~7fffff| ** 2020.04.28 #0 |opc(12),flg(4),prm(16)x3|これだと8バイト長になる| |opc(16),flg(16),prm(32)x3|これだと16バイト長になる| -内部でいったん16バイト長に変換すると、その後は楽になるかもしれない。 -prm -- -1:省略値 -- -3:直前テンポラリ -- -4:直後テンポラリ -- -8~-5:直前テンポラリ -- -12~-9:直後テンポラリ -フラグ --bit0:入力値も出力値も正の数だと決めつけてよい(符号付き整数ではあるが) -そのほか --ORでsrc1をつぶして代入文にする --CMPJEでsrc0,src1をつぶして無条件分岐にする --DEFでtyp=1は整数レジスタ変数2のべき(1で1bit、-1でunsignedの1bit) ** 2020.04.29 #0 -だんだんこのレイヤを作る必然性がわからなくなってきたので、まずそこを確認する。 -このレイヤのおかげで、高級言語は実レジスタ数がいくつなのかを気にしなくてよい。 -基本型の対応関係も気にしなくていい。 ** 2020.05.01 #0 -やっと考えがまとまってきた。そしてこのレイヤを独立して作る意義もわかってきた。 -レジスタ割り当ては結構骨の折れる作業なので、それを下位に任せられるのは価値がある。 -上位言語は、分岐予測などの情報も与える。あるラベルに対して、どこからの侵入が一番多くなると想定すべきなのかも教えられる。 -ABIは独自のものにする。 ** 2020.05.02 #0 -ES-Cは以下のような構成にする予定 --ES-CやES-BASICのレイヤ。ここが機種非依存なバイトコードを生成する。 --共通最適化レイヤ。バイトコードに対して簡単な最適化を行う。 --機種依存バイナリ生成レイヤ。ここがx86やx64やARMの機械語を生成する。 -こうすることで、ES-CやES-BASICはかなり作りやすくなるはず。そして複数環境に対応するのも楽になるはず。 -バイトコードはOSECPU-VMの時のものをベースにするかもしれない。 -なぜこんな複雑な構造にするのかといえば、いろんなCPUに簡単に対応できるようにしたいから。 -昨年の、最初にx64向けに作っていて、後になってx86にも対応しなければいけなくなった時のあの「うわーめんどくさいことになったぞ」感をまた味わうのは嫌だ・・・。 -そしてこれは「オレオレLLVMもどき」の開発に近いものがあるなと思い始めた。それはそれで楽しそうだ。 ** 2020.05.03 #0 -結局私には才能があるのだと思う、そのせいで何を作ってもとても小さくなる。それは楽しい才能だけど、でも予測可能すぎてつまらないともいえる。とにかく私は何でも作り直しさえすれば、小さくなる。そしてそれ以上の価値を付与できることはめったにない。 ** 2020.05.04 #0 -テキストエディタでファイルを保存すると、それを自動検出して、勝手にRUNしてくれるような機能は実装できないだろうか。テキストエディタとES-BASICの両方を使っていると、ウィンドウを行ったり来たりする必要があって、結構煩雑で、しかもこれは本質的ではない。 -もしプログラムの編集管理をテキストエディタに任せられるのなら、行番号は必ずしも必要じゃない。そう考えると、この構想は結構魅力を感じる。 -まず最初にLIDEコマンド(ライトIDE)を実行して、どのファイルを監視するかを指定する。するとES-BASICがすぐにロードして実行する。 -これをやるためには、コマンドプロンプトが入力待ちになったらよくない。なぜならそれになってしまうと、コンパイルエラーすら表示できなくなってしまう。 ** 2020.05.12 #0 -今までx86の機械語を調べるためにインターネットで検索していたけど、今はES-BASICのcodedump 1で済ませられるようになった。 -便利になったなあ。・・・そして調べた機械語を使ってES-BASICを改良している。すばらしい。 ** 2020.05.14 #0 -ES-BASICのmkexeを少し拡張して、乱数が利用できるようになった。キャラクター版の迷路作成プログラムを書いたら、コンパイル後の実行ファイルは1592バイトになった。よしよし。 ** 2020.05.15 #0 -ここしばらく、コード生成時にどこまで最適化をするべきかを悩んでいる。 -やっと決心が9割くらい固まった。ES-BASICにおいては最適化なんて重要じゃない。理由は以下の通り。 --どんなに最適化を頑張っても人間がアセンブラで慎重に書いたコードには遠く及ばない(実行速度でもサイズでも)。つまり最適化なんて「やらないよりはマシ」なものでしかない。だからここを頑張るのは不毛。 --最適化を頑張れば、コンパイル時間は長くなり、処理系が複雑になるだけ。そういうものを作りたいわけじゃない。 --私が高級言語でやりたいのは、軽く書いて軽く実行して軽くデバッグできること。本気で最高のものを得る手段はアセンブラでやるので、そことスムーズにリンクできればそれで充分。 --アセンブラができない人にとっては、高級言語だけで最高のバイナリを得られなければ困るかもしれないけど、私はアセンブラができるので困らない。 -この上で、複数の言語を切り替えて記述できるようにすることには一定のメリットがある。そこはがんばりたい。 ** 2020.05.17 #0 -プログラミング言語を自作するとしたら何が差別化要因になるだろう?いわゆる新規性は何になるだろう? -ES-BASICの場合で考えてみる。 -(1)スクリプト言語とコンパイラを統合したのは、世界初ではないと思うけど、結構珍しい方だと思う。 -(2)デバッグ機能重視というのも、最近では珍しいのではないかと思う。 --私の印象では、デバッグ機能を充実させても、初期のころは「そんなのデバッガでできるじゃん」みたいな指摘が多かったように思う。 --それは全くその通りだったのだけど、私はその指摘はあまり重視せずに、言語処理系におけるデバッグ機能の重視にこだわった。ツールを切り替えて使うなんて効率が良くないはずだと信じている。言語処理系と連携することで(統合は強い連携の形式だと思う)、従来のデバッガの延長線上にはない価値が出ると信じていた。今もその信念は変わらない。 -(3)サイズ重視も今では珍しい方針だと思う。これは他ではまず真似できないレベルになってきていると思う。 --もちろん大きなプログラムでは強い最適化を持っている処理系のほうが強いと思うが、それは言語本体が巨大化するので、いろんなバランスを考えると、今のES-BASICは結構うまくできていると思う。 --まあ小さくできても何の役に立つのかという指摘はあるし、それは正論だと思う。しかし一方で、これはES-BASICにはできて他の言語にはできないということも確かだ。 ** 2020.05.17 #1 -きっかけがあったので、ES-BASICを「はりぼてOS」に移植してみようと思います。自作OS上で自作言語を使うなんて、なかなかに夢があるじゃないですか! -きっとそんなには大変ではないはずです。それにもし誰かが移植するのだとしたら、両方に詳しい私がやるのが一番効率がいいはずです。 -ということで、ちょっとやってみます。・・・もし予期せぬ問題があって苦労したら、断念するかもしれないですが(笑)。 ** 2020.05.26 #0 -ES-BASICを「はりぼてOS」に移植する話は、主にこちらでやっています。→ http://hrb.osask.jp/wiki/?esb02b ** 2020.05.27 #0 -ES-BASICの「はりぼてOS」への移植は、結構いい感じになってきました。 -「はりぼてOS」みたいな単純な自作OS上でも、ES-BASICみたいな言語が動いたら、なんかOSが急に立派に見えてきそうですし、言語のほうもOSに頼っていないという証拠になりそうです。すごくいい目標に思えてきました。 ** 2020.06.11 #0 -ES-C ver.0.0が目指していること: --ソースコードはいったんメモリ上で仮想バイナリに変換される。これはintの配列で出力しやすい。 --仮想バイナリから、ターゲットのCPU/OS向けにバイナリ化される。 --バイナリ生成時は、1パスと2パスから選べる。これでJccなどでshort形式を使える頻度が上がるはず。なんなら3パスとかnパスとかでもいいかも。 --x86に対しても、同一の仮想バイナリから実行バイナリを生成したときに、32bitよりも64bitのほうが高速になるとか、そういうことも十分に起こりうるようにする。 ---つまり共通だからといって、最大公約数的に下にそろえるのではなく、力のあるCPUでは速く、そうではないCPUでもそれなりに、みたいにできるようにする。 ** 2020.06.12 #0 -私がES-Cでやろうとしていることって、結局はpコードマシンだよなーって思う。だから新規性はみじんもない。 --https://ja.wikipedia.org/wiki/P%E3%82%B3%E3%83%BC%E3%83%89%E3%83%9E%E3%82%B7%E3%83%B3 -私は新規性がないことを悪いとは思っていない。いいものが昔に発明されていて、それと同じことをしたからといってなぜダメだといわれなければいけないのか。 ** 2020.07.28 #0 -私は以前、言語を機能ブロックでに分割しなければいけないとしたら、どこで分割するべきかをかなり悩んでいたような気がする。それで、jckライブラリとそれ以外で分けると決めたときに、やっとすっきりした記憶がある。 -今、jckライブラリをやめてesvmに切り替えているわけだけど、迷いはない。迷う余地すら感じなかった。jckよりもesvmのほうがずっと筋がいい気がする。 -jckは言語を作りやすくするために、jck側にたくさんの機能を押し付けた。ソースはバイナリではなくテキストだった。ES-BASICを作って分かったことは、テキストではないほうがシンプルかつ高速に作れるということで、今はすっかりバイナリになっている。 -わかってみれば、なんでそんな当たり前のことに長く気付けなかったんだろうって思う。でもそういうことこそうまくいっている証拠なのかなとも思う。 * こめんと欄 #comment
タイムスタンプを変更しない
* ES-C向けのmemo#1 -(by [[K]], 2020.04.27) ** 2020.04.27 #0 -ES-CとES-BASICは統合する。どうせフロントエンド以外は共通になるし、そもそもそんなに違わない言語だから、別々にメンテナンスすることの方がコストになるはず。 -内部バイトコードフォーマット案 |NOP|00|| |REM1|01 : n|| |REM2|02 : flg : n|| |DEF|04 : flg : id : typ : siz|ローカル変数宣言 / ラベル宣言| |OR |10 : bit : flag : dst : src0 : src1|dst/src0/src1はhh4の24bit形式で足りるだろう| |XOR|11 : bit : flag : dst : src0 : src1|bitはhh4の8bit形式、flagも8bitでいけるだろう| |AND|12 : bit : flag : dst : src0 : src1|命令に16bit形式を採用すると、4+9=13バイト| |ADD|14 : bit : flag : dst : src0 : src1|4+3=7バイトにもできる| |SUB|15 : bit : flag : dst : src0 : src1|| |MUL|16 : bit : flag : dst : src0 : src1|| -bitフィールドはdstなどからわかるので、指定させなくてもいいかもしれない。 -dstに-1を指定させることで、2項形式にできるかもしれない。 --そうすれば、4+4=8バイトにできる。 -符号付きhh4 → (参考) http://osask.net/w/634.html |4bit|00xx|0~3| |8bit|100x:xxxx|0~1f| |12bit|1100:xxxx:xxxx|0~ff| |16bit|1110:0xxx:xxxx:xxxx|0~7ff| |24bit|0111:0100:0xx...xx|0~7fff| |28bit|0111:0101:0xx...xx|0~7ffff| |32bit|0111:0110:0xx...xx|0~7fffff| ** 2020.04.28 #0 |opc(12),flg(4),prm(16)x3|これだと8バイト長になる| |opc(16),flg(16),prm(32)x3|これだと16バイト長になる| -内部でいったん16バイト長に変換すると、その後は楽になるかもしれない。 -prm -- -1:省略値 -- -3:直前テンポラリ -- -4:直後テンポラリ -- -8~-5:直前テンポラリ -- -12~-9:直後テンポラリ -フラグ --bit0:入力値も出力値も正の数だと決めつけてよい(符号付き整数ではあるが) -そのほか --ORでsrc1をつぶして代入文にする --CMPJEでsrc0,src1をつぶして無条件分岐にする --DEFでtyp=1は整数レジスタ変数2のべき(1で1bit、-1でunsignedの1bit) ** 2020.04.29 #0 -だんだんこのレイヤを作る必然性がわからなくなってきたので、まずそこを確認する。 -このレイヤのおかげで、高級言語は実レジスタ数がいくつなのかを気にしなくてよい。 -基本型の対応関係も気にしなくていい。 ** 2020.05.01 #0 -やっと考えがまとまってきた。そしてこのレイヤを独立して作る意義もわかってきた。 -レジスタ割り当ては結構骨の折れる作業なので、それを下位に任せられるのは価値がある。 -上位言語は、分岐予測などの情報も与える。あるラベルに対して、どこからの侵入が一番多くなると想定すべきなのかも教えられる。 -ABIは独自のものにする。 ** 2020.05.02 #0 -ES-Cは以下のような構成にする予定 --ES-CやES-BASICのレイヤ。ここが機種非依存なバイトコードを生成する。 --共通最適化レイヤ。バイトコードに対して簡単な最適化を行う。 --機種依存バイナリ生成レイヤ。ここがx86やx64やARMの機械語を生成する。 -こうすることで、ES-CやES-BASICはかなり作りやすくなるはず。そして複数環境に対応するのも楽になるはず。 -バイトコードはOSECPU-VMの時のものをベースにするかもしれない。 -なぜこんな複雑な構造にするのかといえば、いろんなCPUに簡単に対応できるようにしたいから。 -昨年の、最初にx64向けに作っていて、後になってx86にも対応しなければいけなくなった時のあの「うわーめんどくさいことになったぞ」感をまた味わうのは嫌だ・・・。 -そしてこれは「オレオレLLVMもどき」の開発に近いものがあるなと思い始めた。それはそれで楽しそうだ。 ** 2020.05.03 #0 -結局私には才能があるのだと思う、そのせいで何を作ってもとても小さくなる。それは楽しい才能だけど、でも予測可能すぎてつまらないともいえる。とにかく私は何でも作り直しさえすれば、小さくなる。そしてそれ以上の価値を付与できることはめったにない。 ** 2020.05.04 #0 -テキストエディタでファイルを保存すると、それを自動検出して、勝手にRUNしてくれるような機能は実装できないだろうか。テキストエディタとES-BASICの両方を使っていると、ウィンドウを行ったり来たりする必要があって、結構煩雑で、しかもこれは本質的ではない。 -もしプログラムの編集管理をテキストエディタに任せられるのなら、行番号は必ずしも必要じゃない。そう考えると、この構想は結構魅力を感じる。 -まず最初にLIDEコマンド(ライトIDE)を実行して、どのファイルを監視するかを指定する。するとES-BASICがすぐにロードして実行する。 -これをやるためには、コマンドプロンプトが入力待ちになったらよくない。なぜならそれになってしまうと、コンパイルエラーすら表示できなくなってしまう。 ** 2020.05.12 #0 -今までx86の機械語を調べるためにインターネットで検索していたけど、今はES-BASICのcodedump 1で済ませられるようになった。 -便利になったなあ。・・・そして調べた機械語を使ってES-BASICを改良している。すばらしい。 ** 2020.05.14 #0 -ES-BASICのmkexeを少し拡張して、乱数が利用できるようになった。キャラクター版の迷路作成プログラムを書いたら、コンパイル後の実行ファイルは1592バイトになった。よしよし。 ** 2020.05.15 #0 -ここしばらく、コード生成時にどこまで最適化をするべきかを悩んでいる。 -やっと決心が9割くらい固まった。ES-BASICにおいては最適化なんて重要じゃない。理由は以下の通り。 --どんなに最適化を頑張っても人間がアセンブラで慎重に書いたコードには遠く及ばない(実行速度でもサイズでも)。つまり最適化なんて「やらないよりはマシ」なものでしかない。だからここを頑張るのは不毛。 --最適化を頑張れば、コンパイル時間は長くなり、処理系が複雑になるだけ。そういうものを作りたいわけじゃない。 --私が高級言語でやりたいのは、軽く書いて軽く実行して軽くデバッグできること。本気で最高のものを得る手段はアセンブラでやるので、そことスムーズにリンクできればそれで充分。 --アセンブラができない人にとっては、高級言語だけで最高のバイナリを得られなければ困るかもしれないけど、私はアセンブラができるので困らない。 -この上で、複数の言語を切り替えて記述できるようにすることには一定のメリットがある。そこはがんばりたい。 ** 2020.05.17 #0 -プログラミング言語を自作するとしたら何が差別化要因になるだろう?いわゆる新規性は何になるだろう? -ES-BASICの場合で考えてみる。 -(1)スクリプト言語とコンパイラを統合したのは、世界初ではないと思うけど、結構珍しい方だと思う。 -(2)デバッグ機能重視というのも、最近では珍しいのではないかと思う。 --私の印象では、デバッグ機能を充実させても、初期のころは「そんなのデバッガでできるじゃん」みたいな指摘が多かったように思う。 --それは全くその通りだったのだけど、私はその指摘はあまり重視せずに、言語処理系におけるデバッグ機能の重視にこだわった。ツールを切り替えて使うなんて効率が良くないはずだと信じている。言語処理系と連携することで(統合は強い連携の形式だと思う)、従来のデバッガの延長線上にはない価値が出ると信じていた。今もその信念は変わらない。 -(3)サイズ重視も今では珍しい方針だと思う。これは他ではまず真似できないレベルになってきていると思う。 --もちろん大きなプログラムでは強い最適化を持っている処理系のほうが強いと思うが、それは言語本体が巨大化するので、いろんなバランスを考えると、今のES-BASICは結構うまくできていると思う。 --まあ小さくできても何の役に立つのかという指摘はあるし、それは正論だと思う。しかし一方で、これはES-BASICにはできて他の言語にはできないということも確かだ。 ** 2020.05.17 #1 -きっかけがあったので、ES-BASICを「はりぼてOS」に移植してみようと思います。自作OS上で自作言語を使うなんて、なかなかに夢があるじゃないですか! -きっとそんなには大変ではないはずです。それにもし誰かが移植するのだとしたら、両方に詳しい私がやるのが一番効率がいいはずです。 -ということで、ちょっとやってみます。・・・もし予期せぬ問題があって苦労したら、断念するかもしれないですが(笑)。 ** 2020.05.26 #0 -ES-BASICを「はりぼてOS」に移植する話は、主にこちらでやっています。→ http://hrb.osask.jp/wiki/?esb02b ** 2020.05.27 #0 -ES-BASICの「はりぼてOS」への移植は、結構いい感じになってきました。 -「はりぼてOS」みたいな単純な自作OS上でも、ES-BASICみたいな言語が動いたら、なんかOSが急に立派に見えてきそうですし、言語のほうもOSに頼っていないという証拠になりそうです。すごくいい目標に思えてきました。 ** 2020.06.11 #0 -ES-C ver.0.0が目指していること: --ソースコードはいったんメモリ上で仮想バイナリに変換される。これはintの配列で出力しやすい。 --仮想バイナリから、ターゲットのCPU/OS向けにバイナリ化される。 --バイナリ生成時は、1パスと2パスから選べる。これでJccなどでshort形式を使える頻度が上がるはず。なんなら3パスとかnパスとかでもいいかも。 --x86に対しても、同一の仮想バイナリから実行バイナリを生成したときに、32bitよりも64bitのほうが高速になるとか、そういうことも十分に起こりうるようにする。 ---つまり共通だからといって、最大公約数的に下にそろえるのではなく、力のあるCPUでは速く、そうではないCPUでもそれなりに、みたいにできるようにする。 ** 2020.06.12 #0 -私がES-Cでやろうとしていることって、結局はpコードマシンだよなーって思う。だから新規性はみじんもない。 --https://ja.wikipedia.org/wiki/P%E3%82%B3%E3%83%BC%E3%83%89%E3%83%9E%E3%82%B7%E3%83%B3 -私は新規性がないことを悪いとは思っていない。いいものが昔に発明されていて、それと同じことをしたからといってなぜダメだといわれなければいけないのか。 ** 2020.07.28 #0 -私は以前、言語を機能ブロックでに分割しなければいけないとしたら、どこで分割するべきかをかなり悩んでいたような気がする。それで、jckライブラリとそれ以外で分けると決めたときに、やっとすっきりした記憶がある。 -今、jckライブラリをやめてesvmに切り替えているわけだけど、迷いはない。迷う余地すら感じなかった。jckよりもesvmのほうがずっと筋がいい気がする。 -jckは言語を作りやすくするために、jck側にたくさんの機能を押し付けた。ソースはバイナリではなくテキストだった。ES-BASICを作って分かったことは、テキストではないほうがシンプルかつ高速に作れるということで、今はすっかりバイナリになっている。 -わかってみれば、なんでそんな当たり前のことに長く気付けなかったんだろうって思う。でもそういうことこそうまくいっている証拠なのかなとも思う。 * こめんと欄 #comment
テキスト整形のルールを表示する