khaba/memo001 のバックアップ(No.7)

khabaのメモ

(by K, 2007.02.02)

↑

(1)

GBA（GameBoyAdvance）で動くOSASKを作りたい。でもそしたらx86用OSASKとバイナリ互換はできない（当たり前）。ソース互換ならできるかもしれない。
しかし仮にソース互換にするにしても、エンディアンの問題とかで、完全互換はできないかもしれない（ARM7だけならx86との間にエンディアンの問題は起きないかもしれないが、いずれは他のCPUのことだって考えたい）。それに人によってはソースを公開するのはいやかもしれない。
それなら中間コード（いわゆるVMのバイトコード）みたいなものを考えて、それを実行時に各CPUのネイティブコードに変換すればいいのではないか。これならエンディアンとかの問題はない。CPUのビット数が違って機種によってint幅が異なる、という問題も起こらずに済ませられる。
これをkhabaとする。

↑

(2)

khabaでは最適化に執着しない。プログラムの2割の部分が実行時間の8割を占めるといわれるが（人によっては1-9ともいうが）、khabaが目指しているのはこのコードのうちの残りの8割の部分の移植の手間をなくすことである。速度が求められる2割の部分については、それぞれのCPU向けのコンパイラ（やアセンブラ）で最適なコードを生成すればよい（つまり手作業で移植する）。もちろんプログラム全体をkhabaだけで書くことはできるが、その場合、実行速度には不満が残るかもしれない。しかしそれは今検討するべき問題ではないと考える。
khabaは、ネイティブコードと簡単に（＝少ないロスで）交信できる。関数とかも気軽に呼べる。これが担保できないと、上記理想が実現できない。

↑

(3)

khabaはスタックマシンではなく、レジスタマシンである。総レジスタ数は128個か、もしくはそれより多くする（上限を設けないかもしれない）。レジスタのビット数も規定されない。レジスタを使い始める前に、そのレジスタを何ビットレジスタとして使いたいのかを宣言する。宣言は1bitでも2bitでも27bitでもよい。この宣言には、最低ビット数と最大ビット数がある。たとえば最低ビット数8、最大ビット数指定なし、の場合、8bit以上のレジスタ（もしくはメモリ）が割り当てられると仮定してよい。 for (i = 0; i < 100; i++) { hoge...; } のiのために割り当てるレジスタであれば、まさにこのような指定でいいわけである。符号なしで扱うなら7bitで十分だ。
レジスタマシンにしたのは、khabaをネイティブコードに変換するプログラムに楽をさせ、しかもネイティブコードとの交信をやりやすくするため。たとえばIA-32の場合、レジスタ番号0は、EAXに割り当てられる。レジスタ番号1はECX（本当にEAXやECXにするかどうかは未定。翻訳をやりやすくするため、EAXとかをリザーブにする可能性もあるから・・・MUL/DIV命令やIN/OUT命令を考えると、EAXでしかできないことが結構あり、もしEAXがレジスタ0として利用可能だとすると、DIVをPUSH(EAX);、POP(EAX);ではさまないといけない。リザーブしておけば、EAXは常に破壊可能と想定していいことになるから、このようなPUSH/POPはいらなくなる）。
レジスタ番号8番以降はIA-32には割り当てるべきレジスタが存在しない。これはメモリに割り当てられる。リザーブレジスタがあれば、8番よりももっと若い番号でもメモリに割り当てられることになりそうだ。何番からメモリ行きになるかは、動的に決まるわけではない。khaba/IA-32仕様に記載され、確定する。レジスタ番号nがどのレジスタになるのかについても、仕様で決める。
bit数が仕様で規定されずにプログラムで指定するようにした理由は次のとおり。javaや.NETのように32bit固定ということにすると、286やZ80でこれらを実行する際に、本来は8bitもあれば十分なものをあえて32bit処理することになりかねないからである（キャリーフラグなどを使って多倍長処理することになる）。こんなのは無駄なので、多倍長処理は必要なときだけで済ませられるように、このような仕様にした。最大bit数については、おそらくたいていは指定しないことになるだろうが、繰り上がりによるキャリーフラグの挙動を利用する際には指定することになる。
IA-32で33bit以上のレジスタを使用する場合、上位部分はメモリに割り当てられる。
リンクするネイティブコードを書く場合、データのやり取りをするとか、どのレジスタを破壊してはいけないかを意識するとき以外で、この仕様を気にする必要はない。

EAXはリザーブにすることにした。ARMでもR0とR1はリザーブにする。EDXとR2もリザーブにするかもしれない。ECXがレジスタ番号0になるのはほぼ確定。

↑

(4)

khabaではレジスタは原則として汎用ではない。(3)で言っているレジスタはデータレジスタであり、メモリアドレスやI/Oアドレス指定のために使用することはできない。アドレスレジスタのbit数はプログラマによって意識されない。たとえばこれは32bitのnearポインタかもしれないし、48bitのfarポインタかもしれないし、V86の16bit:16bitのfarポインタかもしれない。khabaは実際のネイティブコードを生成するときに、対象となるCPUやOSに応じて、アドレスレジスタのbit数を決定する。したがってネイティブプログラムがkhabaのプログラムとアドレスとやり取りする場合は、CPUが同じでもOSによって書き換える必要が出てくることは十分にありうる。
IA-32の場合、ESPとEBPとESIとEDIがリザーブされており、実レジスタに対応するアドレスレジスタはEBXだけである。他はすべてメモリに置かれる。
```
    (int) [A0] = 1; /* A0（アドレスレジスタ0）で示されたメモリを1にする。 */
    (int) [A1] = 2;
    (int) [A2] = D0;
```

もしintがリトルエンディアンの16bitであるとしたら（intのエンディアンやビット数はプログラムのどこかで定義してある）、

    MOV WORD [EBX],1
    MOV ESI,[EBP+?(A1のある場所)] ←これはもっと複雑になるかもしれない
    MOV WORD [ESI],2
    MOV ESI,[EBP+?(A2のある場所)] ←これはもっと複雑になるかもしれない
    MOV WORD [ESI],ECX

D0 = A1; のような、アドレスレジスタの値をデータレジスタへ取得しようとする行為はすべて禁止する。また A9 = D4; のような、アドレスレジスタへ普通のデータを入れることも禁止する。 A9 += D4; や D0 = A1 - A0; のようなことは許される。

↑

(5)

アドレッシングの一般型は、[An+(Dn*定数)+(定数)]である。括弧内は省略可能。この式にも現れているが、アドレスレジスタを用いないアドレッシングは許さない。これは次のような設計思想を反映している。
GBAには256KBのRAMと32KBのRAMがあるが、256KBのほうは回路的にCPUからは遠く、アクセスには2クロックのウェイトが入る。32KBのほうはノーウェイト。これはこう考えたらいいだろう、つまり32KBは可視化されたキャッシュメモリである、しかしメモリのどの部分をキャッシュに入れるかとかはハードウェアによる自動制御がなされない。したがってOSなどが面倒を見るべきだと考える（OSがある場合の話）。
メモリのある部分がこの速い32KBの範囲内にコピーされることはあるし、また256KBのほうへスワップアウト（というかキャッシュアウト？）されることもありうる。これらの場合OSは、そのメモリ域を指しているレジスタ（やメモリ）をアプリに気づかれることなくすべて更新する。
- メモリを更新する必要があるかどうかは、ポインタをどのようにメモリに格納させるかにもよる。
こういうことをやるためには、アドレッシング形式にアドレスレジスタを必ず含ませる必要がある。

↑

memo

GBAには（自動の）キャッシュ（制御回路）がない・そもそもRAMも少ない→アクセスウィンドウ→メモリアクセスに制限をつける
エンディアンの問題・ポインタ変数の自動補正→構造体（データタイプ）の把握→非線形配列アクセス→自動型変換？ファイルシステム？
CPU機能を削除（割り込み機能は不要？）
これらの長所を完全に生かすためには、リンクするネイティブコードにも多少のしきたりを押し付けるべき。
レジスタスタック（sparcに似ている？：むしろAMD 29000に近い）、レジスタ間連続代入
khabaが効率よく動かせるCPUとは？それは理想のCPUか？
コンパイラは、ポインタが不要な変数（だから配列はダメ）以外の変数を全部レジスタ変数にする。
JITに限定しない。クロスでもいい。PICマイコンなどでやろうとするとJITはインタプリタ式にしかできないから、非JITを認めるのは現実的。

↑

こめんと欄

このページは誰かに意見を求めるためではなく、自分の記憶の整理のためにあるので、こめんと欄はありません。