* 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
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
