- OSASKではメモリレスアーキテクチャをとっており、これはGBAでも引き継がせる予定だが、ということはつまり、メモリイメージというのは、ただのバイナリファイルである。バイナリファイルにこのような型情報がつくわけだ。これは非常に便利である。バイナリファイルに型情報があるのだから、それなりのエディタを作れば、データの任意の部分を人間にわかりやすい形式で表示したり編集したりできるわけだ。
{
view = {
color = white; /* enumであればこのように表示できるはず（ただしこのコメントは実在しない） */
fontsize = 15;
};
history[5] = {
"abc.txt", "def.txt", "ghi.h", "", ""
};
copybuf = "hogehoge";
};
- これはテキストエディタの設定ファイル（兼履歴保存ファイル）の例である。もちろんこれくらいの読みやすい設定ファイルを持つテキストエディタは既にごまんとありkhabaのアドバンテージとはいえないが、しかしこのようなファイルが、実際はただの100バイト前後のバイナリであって、解読ルーチンなしできわめて高速に読めるのである（バイナリなので当然）。これはかなりいけていると思う。しかもただのテキストファイルではないので、viewとかの部分（つまりメンバ名の部分）は編集できないだろうし（無理に編集することもできるだろうけど、その場合違う構造体になってしまうのでもはやこのアプリには読み込めない）、whiteのところはwhiteのほかにblueやredなどを選択すればいいだけにもできる。汎用・バイナリ・バリュー・エディタ？
- これが現在実行中のアプリのスタックやヒープに対してもできるのだから、デバッガなんてもういらないかも。
- 出力についても同じようなことがいえるかもしれない。たとえば、2つの整数aとbを入力して、それらの和であるcを出力するプログラムを考えるとする。普通に書けば、標準入力からscanfして、和を算出し、printfするだろう。もしくは入力をコマンドラインにするかもしれない。なんにせよ、ASCII文字列をバイナリに変換し、計算し、結果をASCIIにしなければいけない。
- khabaならどうだろうか。まずここで述べたように、入力部分をバイナリ化できる。以下C言語で書くが、これは説明のためであって、khaba版Cがこのような文法になることを保証するものではない。
struct IFILE { /* INTが仮に32bitだとすれば、8バイトの構造体（ファイル） */
INT a, b;
};
void main(INT argc, STRING *argv)
{
if (argc >= 2) {
struct IFILE *p = mapping_struct(arg[1], "r", struct IFILE);
if (p != NULL) {
printf("%d\n", p->a + p->b);
unmapping(p);
}
}
return;
}
- とりあえずこれで、scanfはなくなった。しかしprintfは残る。printfは重い関数だし、バイナリで入力したのに結果がASCIIだなんて、なんかみっともない。ということでこうしてみる。
struct IOFILE {
INT a, b, c;
};
void main(INT argc, STRING *argv)
{
if (argc >= 2) {
struct IOFILE *p = mapping_struct(arg[1], "rw", struct IOFILE);
if (p != NULL) {
p->c = p->a + p->b;
unmapping(p);
}
}
return;
}
- これはすごい。結果もバイナリだ。しかも重い関数がない。結果がバイナリなので、汎用バイナリバリューエディタがあれば、10進数に限られることなく好きな進法で表示もできる。
- バイナリだと32bitを超える計算ができないという問題があると思うかもしれないが、上記プログラムのkhabaコードを実コードへ変換する際に、INTをint64とみなして処理せよというオプションをつければ、それだけで解決する。その場合読み書き用のバイナリも型変換してから使う（こんなのはもちろんツールで簡単にできる）。つまり、値が同じなら、int幅が変わった程度でバイナリを手で作り直す必要はまったくない。
![[K Wiki]](k.jpg "[K Wiki]")
