Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.Dominic(2008-06-23 05:05)
2.CheapestCheapOEMoem(2008-06-17 03:00)
3.NewDownloadCreativAdobOEM(2008-06-12 20:00)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
前回はprintint()という関数が正常に動くところまで進めたが、今週はこれを使って真面目に動 作確認を行う。まずは配列の初期化と内容の参照は問題なくクリア。続いてレコード型の確認に進む。文字列と整数のメンバをそれぞれ一つずつ持つレコード型 を定義し、正しく値が格納されているかを確認するテストプログラムを用意する。
/* a record type and a record variable */
let function printint(i: int) = (...6月15日の日記参照...)
type rectype = {name:string, age:int}
var rec1:rectype := rectype {name="Nobody", age=1000}
in print("rec1.name = ");print(rec1.name);print("\n");
print("rec1.age = ");printint(rec1.age)
end
こ れをコンパイル後、実行すると…
$ ./a.exe
Segmentation fault (core dumped)
ク ラッシュする（もはや驚くほどのことではないが…）。さらに調べてみると、print()関数を取り除いたり、順序を変更すると正 常に動作することが分かった。どうやら関数呼出し後にレジスタの内容が上書きされているのが問題であるらしい。
IA32 アーキテクチャには、EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESPという名前のついた、合計8つの汎用レジスタがある。これらのうち（スタック上に置いた値の管理に使う）EBPとESPを除いた6つのレジスタをや りくりしながら計算を進めていく。関数の呼び出し前後でレジスタの値が上書きされることも当然発生しうるので、これに対応するためのルールも決められてい る。
今回問題となったのは、"caller save", "callee save"というルールにまつわる部 分であった。簡単にまとめると、ある関数が関数呼び出しを行うときに、
である。先に述べたIA32のレジスタのうち、 どれを"caller save"あるいは"callee save"させるかはハードウェア的には決められておらず、OSやコンパイラが決めたルールに従うことになる。ところがIntelの資料を眺めてみてもそ のあたりの手がかりが見つからない。
ということでネット上を探し回ってそれらしい資料を当たる。"Calling conventions for different C++ compilers and operating systems" や"yunoの雑記 帳wiki - IA32"を見ると、どうやらWindows, Linux共にEBX, EBP, ESI, EDIを"callee save"のルールに従い、呼び出された関数で値を保存しておく必要があるらしい。GCCでやや大めなプログラムのアセンブリリストを出力させると、やは りこれら4つのレジスタを退避させていることが分かった。
ということで関数呼び出しの前後を以下のように修正する ことで対応した。修正部分とコメントは赤字で示されている。
_L1:
pushl %ebp ← EBPは今回の修正前から退避されている
movl %esp, %ebp
pushl %edi ← EBX, ESI, EDIを退避
pushl %esi
pushl %ebx
subl $8, %esp ← 引数とローカル変数の領域分だけESPを補正
(...) ← 関数本体を実行
addl $8, %esp
popl %ebx ← EBX, ESI, EDIを復元
popl %esi
popl %edi
leave
ret
動 作確認の結果も良好。これでなんとかなりそうだ。本当はEBX, ESI, EDIの各レジスタのうち関数本体では使われていないものについては、退避と復元を省略することができる（現にGCCではそのようにしている）のである が、今回は無条件で退避・復元を行っている。これについてはまた改めて考えることにしよう。
関数末尾にleave命令があるのに冒頭にenter命令がないのはわざと?
関連して、ローカル変数が破壊レジスタの退避(しかも将来的には省略もあるんだろ?)に上下挟まれているというのはあまり気持ちよくないな。スタックフレームの構造をもう少し整理したいところだ。
あと、つまんないことだが、calling conventionはOSやコンパイラが決めることなんだから、Intelの資料(ってどの範囲だか分からないけど多分プロセッサのマニュアルだよね)にないのは当たり前であって、「ところが」じゃないよね。
アプリケーションノートならわからないでもないけどさ。
スタックフレームの解放にleave は使うけど、確保はenterを使わずに自前でebpの操作をするのは良くある手段だと思いますが(enterが遅いから)。
そうですね。遅いからenterを使わないというのは8086時代からのある意味定石だと思います。最近のIA32 Optimization Referenceとかを見るとleaveも使うなと書いてあったりします。
で、実際そこまで読み切った上でこういうコード生成にしたのか、それともとりあえずGCCなんかにならってみただけなのか、その辺りの意図が聞きたかったなと。
ええと、墓穴を掘りましたが、8086にはENTER/LEAVE命令はないんでした。
コメント(というかまさにツッコミと呼ぶにふさわしいレスポンス :) ありがとうございます ＞ 三浦氏、通りすがりさん
まずenter命令を使っていないのはなぜか?の件ですが、単にGCCの出すコードにならった結果このようにした…というのが実際のところです。このあたりの情報というか、定石が整理されているドキュメントなどが見つかればよいのですが。
スタックフレームについてもGCCのコードを参考にしたつもり…だったのですが、改めて見直してみるとなんか変ですね。というか、かなり怪しい。ここは改めてスタックフレームの絵を描いて見直さなければいかんな＞自分
ええと、あとはcalling conventionについてか。日記の本文に挙げた資料とかは非常に参考になったのですが、そもそもあれってどうやって調べたんでしょうね。MicrosoftとかGNUとかのドキュメントをもっと探すと、もっとオフィシャルっぽい情報が出てくるのかなぁ…
ということでとりあえず。無知なまま書いていたり、突き進んでいたりするところも恐らくたくさんありますので、気が向いたらまた遠慮なくツッコんでやってください。