* acl4の開発ログ
-(by [[K]], 2026.03.14)
-''acl4開発のもくじ → [[a4_i01]]''
-開発ログの過去ログのもくじ → [[a4_log00]]
-一番新しい過去ログ（＝このページの直前の話題） → [[a4_log07]](2026.03.04(水)#0～2026.03.13(金)#5): a4vmの命令体系を試作。mandel描画でテスト。さらに再起呼び出しのテストを階乗とフィボナッチ数で行う。
-一番新しい過去ログ（＝このページの直前の話題） → [[a4_log08]](2026.03.14(土)#0～2026.03.17(火)#2): プリプロセッサ的な置換ルールだけで、コンパイラの大半の処理をやってしまえば、コンパイラはすごく作りやすくなるかもしれないという構想を思いつく。
** 2026.03.18(水) #0
-（主に自分のために）構想の全体像をまとめておきます。
-[1]ソースコードをプリプロセッサ向きの形式に変換する（tt0003b.cのMiniCompilerの後継の関数がそれをやる）。
--これは上記に雑なサンプルがあるので、雰囲気はわかってもらえると思います。
-[2]ローカル変数・ローカルラベルなどを解決して、すべてグローバルな名前に置換する。
--関数funcの中のabcというローカル変数なら _@func_@abc とかに置換します（置換ルールは仮のものですが、元の名前が推測できるようなものにはしたいです）。
-[3]改造プリプロセッサにより前方参照とマクロ展開をやる。
--一時変数の型を決めるためのマクロの適用・型を決めた上での演算に対応したマクロの適用・変数の割り付けなどの処理をやる。
** 2026.03.18(水) #1
-ちょっと最適化が必要そうだなあと思ったところ：
Add(tmp5, s, tmp4);
Let(s, tmp5);
→ Add(s, s, tmp4);
Add(tmp3, j, 1);
Let(j, tmp3);
→ Add(j, j, 1);
Add(tmp1, i, 1);
Let(i, tmp1);
→ Add(i, i, 1);
-このレベルの最適化だけをぱぱっとやってしまうレイヤ（＝関数）を作ればいいのかな？
** 2026.03.18(水) #2
-自分用にアイデアメモ：
--まず変数 i が、 Int:memstk+1234 に変換される。
--Add(i, i, ConstInt:1); が Add_IntMemstk_IntMemstk_ConstInt(1234, 1234, 1); に変換される。
--Mov_RS(EAX,1234); Add_RI(EAX,1); Mov_SR(1234,EAX); に変換される。Sは[ESP+disp]の意味。
** 2026.03.26(木) #0
-大変唐突ですが、変数宣言とかしなくてもデフォルトで有理数型を標準的に扱える言語処理系が欲しくなりました（笑）。
-（いや本気で作るわけではないです。ネタです。）
-たぶんここまでで作ったものを生かせば簡単に作れるはず。
-よし今日はそれで遊ぼう！
-そもそも発端は、以下の連立方程式を、xにいろんな数を入れてみて、総当たりで解いてしまおうと思ったことでした。
a=x/2+3
b=(x-a)/3+2
c=(x-a-b)/4+2
x=a+b+c+7
** 2026.03.26(木) #1
-Python のライブラリに limit_denominator というメソッドがあるのをさっき知りました。
-浮動小数点数を与えると、指定した分母の範囲で一番近い有理数を探し出して答えてくれます。
-これはいいなと思いました。これが使えるなら、普段はdoubleで計算しておいて、答えを出すときに有理数に直せばいいからです。
-それなら有理数型はなくても平気です。
-しかもこの関数があれば、sqrt(2)とか円周率とかに対して、適当な有理数で近似するとしたら何がいいのか、みたいな遊びにも使えます。
//-有理数型の強みとしては、桁落ち誤差が全く生じないということがあります。似たようなことをやりたいとすれば、引き算をする前に双方を有利化して a/b - c/d に変形して、(ad-bc)/bd を計算すればいいわけです。有理数化するときにそれなりに時間はかかりますが、とにかく正確さは得られます。
** 2026.03.26(木) #2
-とりあえず、こんなプログラムを書いてアルゴリズムが正しいか確認してみました。
// tt0004a.c
#define a_Version 1
#include <acl4.c>
int64_t limit_denominator_sub(int64_t *ary, int n, int64_t *pb)
// nは配列の長さではなく、それよりも1小さい数を渡す. つまり ary[n]が最後のデータ.
{
int i;
int64_t a = ary[n], b = 1, t;
for (i = n - 1; i >= 0; i--) {
t = ary[i] * a + b;
b = a;
a = t;
}
*pb = b;
#if 0
printf("n=%d [", n);
for (i = 0; i <= n; i++) printf("%d ", (int) ary[i]);
printf("] %d/%d\n", (int) a, (int) b);
#endif
return a;
}
int64_t limit_denominator(double x, int64_t bMax, int64_t *pb)
{
if (x == 0.0) { *pb = 1; return 0; }
int sign = 1, i;
if (x < 0.0) { sign = -1; x *= -1.0; }
int64_t ary[1024], a = 0, b = 0, ta, tb;
for (i = 0; i < 1024; i++) {
ary[i] = (int64_t) x;
ta = limit_denominator_sub(ary, i, &tb);
if (tb > bMax) break;
a = ta; b = tb;
if (i == 1023) break;
x -= (double) ary[i];
if (x < 1e-12) break;
x = 1.0 / x;
}
*pb = b;
return a * sign;
}
int main()
{
int64_t a, b;
double x = 3.14159265358979323;
a = limit_denominator(x, 10, &b); printf("%d/%d\n", (int) a, (int) b);
a = limit_denominator(x, 100, &b); printf("%d/%d\n", (int) a, (int) b);
a = limit_denominator(x, 1000, &b); printf("%d/%d\n\n", (int) a, (int) b);
x = sqrt(2);
a = limit_denominator(x, 10, &b); printf("%d/%d\n", (int) a, (int) b);
a = limit_denominator(x, 100, &b); printf("%d/%d\n", (int) a, (int) b);
a = limit_denominator(x, 1000, &b); printf("%d/%d\n\n", (int) a, (int) b);
x = exp(1);
a = limit_denominator(x, 10, &b); printf("%d/%d\n", (int) a, (int) b);
a = limit_denominator(x, 100, &b); printf("%d/%d\n", (int) a, (int) b);
a = limit_denominator(x, 1000, &b); printf("%d/%d\n\n", (int) a, (int) b);
return 0;
}
// 実行結果
>tt0004a
22/7
22/7
355/113
7/5
99/70
1393/985
19/7
193/71
1457/536
-とりあえずそれっぽく動いているので、アルゴリズムは悪くなさそうです。
-このアルゴリズムを一応説明しておくと、与えられた実数を連分数形式に変換して、それを有理数に直して返しています。
--連分数についてはこちらを参考にしています。 https://ja.wikipedia.org/wiki/%E9%80%A3%E5%88%86%E6%95%B0
-なぜこのアルゴリズムにしたのかというと、計算量が少なそうに思えたからです。
** 2026.03.26(木) #3
-ということでこれで行けそうと思ったのですが、このページの結果とは少し違っていました。
-https://note.nkmk.me/python-fractions-usage/#pie
--（こういう情報があるのはとてもありがたいです。）
-違うのは、円周率に対して、 print(pi.limit_denominator(100)) をしたときに、 311/99 を返してくれるところです。 tt0004a.c だと 22/7 の次は 333/106 で、その次が 355/113 なので、 311/99 は出てこないのです。
-それ以外の結果は一致しています。
-つまり Python は違うアルゴリズムを採用しているのだと思います。
** 2026.03.26(木) #4
-この結果を踏まえると、 Python と同じ結果を出すことを頑張るのではなく、少し仕様を変えようと思います。分母の最大値を渡すのではなく、「分母がこの値を超えたら打ち切る」つまり最大値ではなく最小値を渡す感じにしようと思います。
--そのほうがプログラムは簡単になります。
// tt0004b.c
int64_t limit_denominator2(double x, int64_t bMin, int64_t *pb)
{
if (x == 0.0) { *pb = 1; return 0; }
int sign = 1, i;
if (x < 0.0) { sign = -1; x *= -1.0; }
int64_t ary[1024], a, b;
for (i = 0; i < 1024; i++) {
ary[i] = (int64_t) x;
a = limit_denominator_sub(ary, i, &b);
if (b >= bMin || i == 1023) break;
x -= (double) ary[i];
if (x < 1e-12) break;
x = 1.0 / x;
}
*pb = b;
return a * sign;
}
-そもそもは、「無理数をいい感じに近似できる有理数を探す」ことではなく、「真値は有理数なのだけど、浮動小数点演算のせいで多少の誤差があり、それを乗り越えて真値である有理数を求めたい」ということなのです。だから打ち切り条件を厳密に守るために演算量が増えるのは本意ではないのです。
-と思ったのですが、 limit_denominator2() は実用的ではないとわかりました。
-たとえば総当たり方式で解を探すと、 3x=1 に対する仮の答えとして x=0.33 とかが得られるかもしれません。
-ここから有理数に戻そうと limit_denominator2(10) とかすると、 33/100 になってしまうのです。まあ当然ですよね。
-これに対して、 limit_denominator(99) なら正しく 1/3 が得られます。
** 2026.03.26(木) #5
-以下を見ると Python の limit_denominator() は複雑なアルゴリズムを使って最適な分母を探しているようです。
-https://stackoverflow.com/questions/13437589/how-is-pythons-fractions-limit-denominator-implemented
** 2026.03.27(金) #0
-ええとまず「失言ドリブン」という話をさせてください。
-私はかつて TONWS用PC98エミュレータ「V98」というソフトウェアを作りました。これは富士通のFM-TOWNSというパソコンで、NECのPC-9801というパソコン用のソフトウェアを動かすという、そういうものでした。
-なぜこれを作ったのかということですが、まず自分の家には98もTOWNSもあって、だからこのソフトがないと自分が困るということは特にはなかったのです。だけど作ったわけです。
-当時の私はTOWNSが大好きで（今も好きですよ、もちろん）、PC-9801よりもTOWNSのほうが高性能なんだと固く信じておりました。私は学校でも「パソコンに詳しい人」というイメージがあったので、何人かの友人が私にどんなパソコンを買ったらいいかなと相談に来ることがあって、「まあ世間的な普及度を考えたらお勧めするべきはPC-9801だろうけど、私はTOWNSが好きだなー」とか答えていたわけです。
-それで「ちょっと迷ったけど、たぶんわからないことがあったら君に聞くことになると思うから、オレもTOWNSにしたよー」「うわーいいなー、最新モデルじゃん！」みたいな展開が何回か発生したわけです。
-それで友人たちが後悔するとかそういうことはなかったのですが（たぶん）、私は調子に乗って「TOWNSのほうが性能はいいんだ。PC-9801にできることならTOWNSにもできるんだ。たぶんエミュレータだって作れるはずだ」などと何かの拍子に言ってしまい（笑）、さらにいくつかの失言がつながって成り行きで私がそのエミュレータを作って見せるという話になったのです。
-言ったからにはやらなきゃいけないわけです（とはいえ、友人たちはそんな話、ろくに覚えていなかったわけですが）。ということで私は頑張って「V98」を作ってフリーソフトとして公開したのでした。
-この話で私が伝えたいのは「軽率な失言をすると、やむを得ないという状況が発生して、それによって開発が促される（こともある）」ということです。
~
-私は今年に入ってから、軽率な約束を2つしています。それをここに書いておいて、将来の自分を「やむを得ないという状況」に追い込もうと思っています（笑）。
--Buntan-PCプロジェクトのためのCコンパイラを、私が年内に作る。
--OSASKのアプリケーションのkaodunを逆アセンブルなどで解析して、Windowsなど、他の環境でも動くようにする（ソースコードがあれば自作のOSに移植したいなーという声は、時々耳にするのです）。
** 2026.03.27(金) #1
-なんか適当に1時間くらいやれば、浮動小数点を基本型にもつインタプリタくらい作れるだろうと思っていたのですが、なんかいろいろ足りてなくて、今は自分の見積もりの甘さを反省しております・・・。
** 2026.03.29(日) #0
-a4vmの本番用の仮想マシンを作っているのですが、再帰処理で苦戦しています。フィボナッチ数の計算すらうまくいかない状況で、ちょっと途方に暮れています。まあたぶんもうすぐ直ると思いますが・・・。
** 2026.03.29(日) #1
-よし直ったー。
** 2026.03.30(月) #0
-[[a4_0014]]に書いたサンプルプログラムの t0014a.c は、思っていたよりも優秀なので楽しいです。
-明日にはプログラム例を書きます。
** 2026.03.31(火) #0
-[[a4_0014]]（A4vm_exec0など）を書きました。これで何ができるのかを明らかにするために、サンプルコードをたくさんつけました。
** 2026.03.31(火) #1
-ここから、プリプロセッサの連鎖でコンパイラを構築するっていうのをやりたいわけだけど、これは初めての挑戦だから、きっと少し時間がかかるだろうなあ・・・。
** 2026.04.01(水) #0
-今日は病気でお休み。
** 2026.04.01(水) #1
-いきなり理想形を考えるのではなく、まずは現状のプリプロセッサだけでまねごとをするとしたらどうすればいいかを考えるのがよさそうだなあ。
** 2026.04.02(木) #0
-変換手順（妄想・暫定版）
[1]
int i, s;
for (i = 0; i < 10; i++)
s += i;
[2]
#define i Int:R00
#define s Int:R01
Lod(i, CInt:0); Lbl(Txt:LT0001);
Add(s, i);
Add(i, CInt:1); Jlt(i, CInt:10, Txt:LT0001);
[3]
Lod(Int:R00, CInt:0); Lbl(Txt:LT0001); Add(Int:R01, Int:R00); Add(Int:R00, CInt:1); Jlt(Int:R00, CInt:10, Txt:LT0001);
[4]
Lod_RI(R00, 0); Lbl_T(LT0001); Add_RR(R01, R00); Add_RI(R00, 1); Jlt_RIT(R00, 10, LT0001);
[5]
Lod_RI(R00, 0); Lbl_T(LT0001); Add_RRR(R01, R01, R00); Add_RRI(R00, R00, 1); Jlt_RIT(R00, 10, LT0001);
-うん、これくらいなら作れそうな気がします。
-まず[4]→[5]は簡単です。
#define Add_RR(r, s) Add_RRR(r, r, s)
-みたいなのをたくさん書けばいいだけだからです。
-それで[3]→[4]をやるには、型付きdefineを作らないといけません。
#typedDef Lod(Int:r, CInt:i) Lod_RI(r, i)
#typedDef Lod(Int:r, Int:s) Lod_RR(r, s)
-では[2]→[3]はどうかというと、これは普通のプリプロセッサです。
-残った[1]→[2]は、これはプリプロセッサではなくて言語です。
** 2026.04.02(金) #1
-[Q] これでCコンパイラができそうなことはなんとなくわかりますが、これにどんなメリットを感じているのかよくわかりません。
-[A] [1]→[2]の変換を見てください。コンパイラはiやsの型を意識するのはdefineの時だけで、それ以降は完全に忘れています。代入はLod、加算はAddと機械的に変換しているだけです。これならコンパイラを作るのは楽でしょう。
-一方で、この型の組み合わせの加算の時はこれに変換する、というルールを後付けで（＝コンパイラの改変をすることなく）、いくらでも追加できるわけです。
-型の追加だって思いのままです。String型やComplex型、VectorやMatrixなどの型を追加してもコンパイラはそのままでいいわけです。それらに対してどんな演算を定義するか、後で好きに決めていいし、変えてもいいということです。
-C++のoperatorっぽいことができるわけです。
** 2026.04.02(金) #2
-[1]自分の作品に「主要なテーマ」があるととてもいいと思っています。
-たとえば料理を作るのなら、「〇〇産のこの野菜がとてもおいしいから、この野菜のおいしさが最大限生かされるように、お肉やお魚や調味料を選びたい。調理法も工夫したい」みたいに料理を工夫していけば、何のテーマもなくお料理をする場合よりもずっとおいしいものができると思うのです。
-絵を描くにしても、「この笑顔が忘れられない。これを最大限に生かせるような色合いや背景にしたい。」って考えて描いていけば、ただ場面を切り取ってそれを精密に写し取るよりも印象深い絵になると思うのです。
-[2]私がOS自作をしようと思ったとき（第一世代OSASKのとき）、私にはテーマがありました。私はi386/i486というCPUに感動したのです。
-まず32bitというレジスタ幅に感動しました。16bitでは64KBを超えるアクセスが素直には書けません。一方で、16bitカラーで640x480ピクセルを扱おうと思えば、600KBにアクセスする必要があって、386は夢のような仕様だったのです。
-そもそもメモリが64KBとか1MBしか使えないっていう8086は狭いなと思っていました。これが4GBになるわけです。これならやりたいことは全部できる！って思いました。
-新しくなったセグメンテーションもとても感激しました。メモリ領域をOSが移動したとしても、セグメントの設定も一緒に変更すれば、アプリケーションは一切影響を受けずに動き続けることができるわけです。
-実行速度は高速でした。特にi486はとんでもなく速いと感じました。
-私はこのCPUの機能を生かし切るためのOSを作ってやろう！と思ったのです。
-結果としてとても面白いOSができたと思っています。
-[3]最近は移植性が大事で、特定のハードウェアや特定のOSに依存しないほうがよいという風潮があるので「これを生かし切るプログラムを書いてやるぞ！」とはなりにくいかもしれません。もったいないですね。
-[4]acl4は何がテーマでしょうか。・・・まず、テーマより前に目的を書いておくと、それは私が私自身の開発力を底上げすることです。「このライブラリさえあれば、あれもこれもちょこっと書くだけでできる」という状態を実現することです。
-じゃあテーマは何かというと、C言語だけでもここまでできるということ示すことです。C言語には足りない部分があって、それゆえに後続の言語が生まれてきたわけですが、それはC言語に不得意な処理があるということです。そこを責めずに得意な部分をうまく使えば、C言語だってまだまだやれるんです。
* こめんと欄
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
