a21に関する雑記#1
2021.01.25(月)
- 今日はa21_txt01_3のTL-3を書きました。我ながらシンプルにわかりやすく書けた気がします。
- ラベル名をうまく使って、分岐先のpc値を高速に求められるようにしたので、結構高速に動いてくれそうな気がします。
- でもなあ、goto命令だからなあ。やっぱり嫌がられてしまうかなあ・・・。
2021.01.26(火)
- うーん、この先の拡張を考えると、トークンコードの処理は別の関数に切り出しておくほうがよさそうだなあ・・・。じゃあさかのぼってTL-2から修正するかな。
- TL-4で高速化して、TL-5で「式」を扱えるようにして、TL-6で型を導入したらいいかなあ・・・。
2021.01.27(水)
- TL-4での高速化はやっぱりやめます。それはTL-5でやることにします。
- TL-4でやるべきは「REPLの導入」だと思いなおしました。・・・TLシリーズはせっかくのスクリプト言語(インタプリタ)なので、そのメリットを生かさないともったいないです。だからREPLの導入はぜひやるべきだと確信しました!
- その後の予定としては、TL-5で少し高速化して、TL-6でもっと高速化して、TL-7でwihleループやブロックifなどを導入して、TL-8かそれ以降でグラフィック命令を導入します。
- そのあたりまでできたら、次はTJシリーズに移行して、JITコンパイラかな・・・。
- TL-4ができました。REPLできるのはすごく楽しいです。これがたった7.5KBのアプリで実現できるなんて! →a21_txt01
2021.01.28(木)
- TLシリーズでどこまでやるかで少し悩んでいます。たぶんやりすぎないほうがいいんです。道半ばにしておいて、「自分だったらこうするのに」をいくつか残しておくほうが、その後の開発にチャレンジする人が増えると思うのです。
- ということで型も浮動小数点演算も配列も構造体も関数もローカル変数も全部見送ろうかなと思っているのですが、どうかなあ。
- 具体的な改造コードを提示しないまでも、こうすればできそうだよね?くらいの話は書くかなあ。
- [memo]あとでどこか別のところにまとめるつもりだけど、インタプリタ言語のメリット:
- [1] 実行ファイルがいらない。ソースコードだけあればよい。あとで、実行ファイルだけになって、「ソースは失われてしまった」みたいな事故が起きない。
- [2] インタプリタ言語のソースコードは(たいてい)機種依存しないので、移植しなくていい。将来新しいCPUとかOSが出ても無修正で対応できる。
- [3] JITコンパイラとかであれば、それぞれの環境に応じた実行コードを生成して実行してくれる(可能性がある)。
- [4] インタプリタはREPLができる。
- 対応するデメリット:
- [1] ソースがあっても処理系がないと動かない(どのバージョンで動かすかわからなくなったとか)。
- 現在手元で開発中のTL-6ですが、どうせやるならJITコンパイルしない範囲での最速を目指してやろうということで、ちょっと頑張ってみました。結果はgcc比で13.7倍。我ながら、これはなかなかいいんじゃないかなと思いました。
- その後さらに頑張って、11.3倍まで速くできました。
2021.02.02(火)
- 現在、TL-7で、演算子をどこまでサポートするかで悩んでいます。
- たくさんサポートすると、それだけでプログラムはかなり長くなってしまいます。
- でも少なすぎると、おんぼろすぎて、TL-7が魅力的には見えなくなってしまいます。
2021.02.05(金)
- プログラムで変数に対する説明が省略されすぎじゃないかと言われて、その通りだと思ったので少しずつ直していきます!
2021.02.06(土)
- 今になって、lexer()とgetTc()を統合すればもっとすっきりと書けるということに気づきました。
- それで、どういう話の流れにしたら最小の手間で自然にその結論に到達できるかを悩み中です。
2021.02.15(月)
- 私はTL-7でどうにかしてスタックマシンを構成しないで、式の評価をやりたいです。しかもできるだけ自然な感じで。・・・アイデアはあるんです。きっとできると思っています。
2021.02.16(火)
- TL-7が手元ではできた!・・・454行で、9.50KB。これはかなりコンパクトだと自分では思います。それでいて、ちゃんと優先順位を反映して計算できています。やったね!
2021.02.17(水)
- プログラムを差分で書いて説明しているけど、差分ではなく全部が欲しいという人もいるだろうなあ・・・。TL-1から全部をまとめてzipとかでダウンロードできるようにしたらいいのかなあ。
2021.02.18(木)
- 現在、手元では開発中のTL-9で、マンデルブロー集合の描画プログラムが動いています。しかもかなり高速で、同じことをC言語で書いて gcc -O3 でビルドして動かしたものと比べて、4.0倍しか遅くありません。これはすごい!
- 今のTL-9は725行で、実行ファイルでは17.0KBです。グラフィック描画のためにaclライブラリを使っています(17.0KBの中にaclライブラリも含まれます)。
2021.02.19(金)
- TL-9でどこまでやるかを考えています。
- 演算子:%
- 組み込み関数:xorShift()
- 組み込み関数:getPix()
- 組み込み関数:fillRect0()
- この4つがあれば、esbasic02aの (4-3)「迷路作成(穴掘り法)」 が移植できるはずです。演算子も組み込み関数も簡単にできるのでこれは余裕そうです。
- さらに、
- 配列変数のサポート。
- 関数定義と関数呼び出し。
- 演算子:&
- 演算子:/
- 演算子:< >= <=
- 組み込み関数:ff16sin()
- 組み込み関数:ff16cos()
- 組み込み関数:inkey()
- 組み込み関数:wait()
- ここまでやれば、esbasic02aの (4-4)「キューブ回転」 が移植できるはずです。
- その先も、文字列の簡易サポートをして、組み込み関数をさらに増やせば、
- (4-5)「インベーダゲーム」
- (4-6)「ブロック崩し」
- も移植できると思うのですが、そこまでやるかどうかは悩みどころです・・・。
- でも、やったほうがおもしろいかなあとは思います。
- さらに考えを進めて、一つのソースコードで、gccでコンパイルして動かすことができて、かつTL-9でも動作できるような、そんな仕様ができないものかと検討中です。
- [1] lexer()を改造して、#を記号として認識させる。
- [2] ついでにコメントも書けるようにしてやる(おまけ)。
- [3] #ifndef TL9 ~ #endif で囲まれた範囲は、TL-9からはコメントとして無視してやる(gccには認識される)。
- [4] #ifdef TL9 ~ #endif で囲まれた範囲は、TL-9からは通常通り解釈してやる(gccには無視される)。
- [5] #includeは無視する。
- [6] 組み込み関数の名前や仕様をaclライブラリの本来のものに似せる。
こめんと欄