escm0001 のバックアップ(No.12) - essen-wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

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においては最適化なんて重要じゃない。理由は以下の通り。
- どんなに最適化を頑張っても人間がアセンブラで慎重に書いたコードには遠く及ばない（実行速度でもサイズでも）。つまり最適化なんて「やらないよりはマシ」なものでしかない。だからここを頑張るのは不毛。
- 最適化を頑張れば、コンパイル時間は長くなり、処理系が複雑になるだけ。そういうものを作りたいわけじゃない。
- 私が高級言語でやりたいのは、軽く書いて軽く実行して軽くデバッグできること。本気で最高のものを得る手段はアセンブラでやるので、そことスムーズにリンクできればそれで充分。
- アセンブラができない人にとっては、高級言語だけで最高のバイナリを得られなければ困るかもしれないけど、私はアセンブラができるので困らない。
この上で、複数の言語を切り替えて記述できるようにすることには一定のメリットがある。そこはがんばりたい。

こめんと欄

コメント	お名前	NameLink