a25_kharc01 のバックアップ(No.6)

kharc #01

(by K, 2025.05.30)

↑

(0) これはなに？

buntan-pcで遊んでいるうちに思い付いたもの。もはや言葉ではうまく説明できない。
だから短期間で作って、こういうのあったらいいよね？と見せたい。

なんて読めばいいの？「カーク」・・・ KH-Architecture が語源。
仮想マシン(VM)なの？・・・そうとも言えるけど、そうではないともいえる。
Cコンパイラなの？・・・ある意味ではそう。
トランスパイラじゃないかな？・・・そうかもしれない。でもC言語をC言語にするんだけどね・・・。

何ができるの？・・・CPUに依存しないデバッグ機能の提供。
たぶんものができれば、「ああなるほどこういうことがやりたかったのね。じゃあ確かにこう作るしかなかったね」ってわかってもらえる。

↑

2025.05.30 Fri #0

とりあえずの方針：
- 不便でも何でもいいので、とにかく動くものを作る。便利にする、きれいにするのは後回し。
- 詳しく考えるのがめんどくさいので、x86っぽい構成にする。Rev2で真面目に設計すればいい。

設計：
- レジスタマシン。整数レジスタ4本(R)。アドレスレジスタ4本(A)。浮動小数点レジスタ4本(F)。コンパイラではレジスタ変数を考えないので、たぶんこれで足りる。
- なんか不安になってきたので、アドレスレジスタだけは8本にしよう。
- RxとAxはこのバージョンでは32bitということにする。
まずはアセンブラを作る。
- MovRR(Rx,Rx); MovAA(Ax,Ax); MovFF(Fx,Fx); // レジスタ間転送
- MovRI(Rx,imm32);
- AddRI(Rx,imm32); SubRI(Rx,imm32);
関数呼び出し規則としては、基本的にどのレジスタも破壊可能だけど、スタックポインタであるA0とグローバルベースのA1は破壊しない。
ただ123を返すだけの関数。
```
MovRI(R0,123); Ret();
```

1から10までの和を計算する関数。

MovRI(R0,0); MovRI(R1,1);
LbI(0); AddRR(R0,R1); AddRI(R1,1); CmpJneRII(R1,11,0);
Ret(); // == JmpA(A2);

再帰でフィボナッチ数を計算する関数。スタックトップに引数がある。

LbI(0);
  LodRMd(R0,A0,0); // R0=[A0+0];
  CmpJgRII(R0,1,1); // if (R0>1) goto 1;
  Ret();
LbI(1);
  SubAI(A0,16);
  StoAMd(A2,A0,8); // [A0+8]=A2;
  SubRI(R0,1);
  StoRMd(R0,A0,0);
  CalII(0,2); // == MovAI(A2,2); JmpI(0); LbI(2);
  StoRMd(R0,A0,12);
  LodRMd(R0,A0,16);
  SubRI(R0,2);
  StoRMd(R0,A0,0);
  CalII(0,3);
  LodRMd(R1,SP,12);
  AddRR(R0,R1);
  LodAMd(A2,A0,8);
  AddAI(A0,16);
  Ret();

kharcのアセンブラは、機械語ではなくC言語のソースコードを出力する。

↑

2025.06.02 Mon #0

もしかしたら説明できるかもしれないので、ちょっと説明してみます。

[1]何かプログラムを書いたとして、そのプログラムがある関数f()を何回呼んでいるか知りたくなったとします（たとえばデバッグ中だと考えてください）。その場合、関数f()の中にprintf()を仕込めば、関数が呼ばれたログを簡単に作ることができます。
- 俗にいうprintfデバッグです。これのいいところは、ある条件を満たしているときにf()を呼んだケースのみを検出したいとか、そういう複雑な条件をいくらでも記述できるところです。
ではこのプログラムがどういうタイミングでメモリアクセスしているか、それを全部追跡したくなったとしましょう。そうすれば「なんで今このオブジェクトが壊れているのか。壊したやつは誰だ？！」みたいなバグもすぐに追跡できます。
でもそこで気づくのです。メモリアクセスなんてコード内にありふれていて、とてもじゃないけど簡単には追跡できないな、と。
ほかにもいろいろありえます。すべての加算命令が怪しくて意図しないオーバーフローを検出したいけど、検出できないので探しようがない、とか・・・。

[2]こういうとき、私には必殺技があります。それはエミュレータを使うことです。エミュレータなら、すべてのメモリアクセスを監視するとか、加算命令を監視するとか、そんなの余裕なのです。
なぜエミュレータが必殺技なのかと言えば、私はもともとエミュレータが大好きで、エミュレータがすべての問題を解決するのだ、がははは！みたいなことをいつも言っているような人間だったからです。
エミュレータ教の信者、いや教祖かもしれません。大学生の時には実際にエミュレータを一つ書いたこともありました（事実上のデビュー作です）。

[3]ということで、x86エミュレータを適当に入手して改造すればいいわけですが、既存のx86エミュレータはどれもかなり巨大です。エミュレーション速度を上げるためにたくさんの工夫が入っていて、複雑になっています。というかそもそもx86の命令体系が複雑なんです。
私はただデバッグ支援のために気軽に改造したいだけなのに、やらなきゃいけないことが多くて、「うーんそれだったらエミュレータを使わない方法でデバッグしようかな」と心が折れてしまいます。

[4]でもそうやって何回も心を折ってきたわけですが、さすがにこの繰り返しはアホだと自覚しました。シンプルで改造しやすいエミュレータを作ればいいのです。エミュレータ教の信者なのだからそれくらいできないでどうしますか。
もちろんx86やARMなどとの互換性はないです。エミュレータが作りやすいようなシンプルなやつにします。
名前がないと説明しにくいので、これをkharcアーキテクチャと呼ぶことにします（kharcの語源の中にアーキテクチャがあるので、アーキテクチャが2個になっているところがダサいけど）。
アセンブラしかないっていうのは不便すぎるので、kharc用のCコンパイラも作ります。

[5]普通にエミュレータを作ると大変だし、その割に速度が出ないので、kharcのアセンブラからC言語に変換するツールを作ります。そのC言語をgccやVCなどの普通のCコンパイラにかけると、実行ファイルができて実行できます。
Cコンパイラは最適化をやってくれるので、この方法ならそこそこの速度が出るかもしれません。
アセンブラからC言語に変換の際には変換ルールみたいなものを決めておくわけですが、そこを改造することで、すべてのメモリアクセスを監視するとか、すべての加算命令を監視するとか、何でもできるようになります。

↑

2025.06.02 Mon #1

整数レジスタ R0～R7 : R7はデバッグ用のレジスタで、今ソースコードのどこを実行中なのか記憶するためのもの（例えば行番号が入るイメージ）。リリース時はこのレジスタは使わない。
アドレスレジスタ A0～A7 : A7はPC, A6はSP, A5はリターンアドレス（5/30版とは違っている）
浮動小数点レジスタ F0～F7 :