ささだです。

Kazunori Ogata et al, Bytecode Fetch Optimization for a Java
Interpreter, ASPLOSX, 10/02
http://www.csc.uvic.ca/~csc586a/papers/p58-ogata.pdf

　もついでに読んでるんで、そっちも。今度はダラダラと読書感想文になってま
すが。

2.1 base intepreter

　threaded code だけど、一回のロードでオペランドと次の命令をどかっと読み
込む。で、デコードがきちんとできると言っているんだけど、何でできるかよく
わからない。

　It avoids using a decode table by laying out ... で、デコードテーブル
要らないって言ってるんだけどなんでだろう。

　各命令のハンドラが 64bit 境界にあるから、base_addr + (insn << 6) でハ
ンドラのアドレスがわかる -> だからデコードテーブル不要、という意味だろう
か。それだと 16384 byte の領域しか指せないけど、それで十分なのかな。


2.2 stack caching

　write-through top-of-stack caching (WT) というのは、

・スタックへ値を push するとき、
  stack[++sp] = top_of_stack_register = val;

・スタックから値を pop するとき、
  top_of_stack_register = stack[--sp];

・スタックトップを参照するとき
　top_of_stack_register だけ

　という感じですか。

　楽でいいなぁ。

　Gauche がこんな感じ？　ちょっと違うかな。

　I-Cache miss が問題になるくらい命令数が多いとか、組み込み系だとこっち
のほうがよさそうだなぁ。

　ここでの（WB: Write-backと比較しての）利点として、load -> store という
順番になって、WB だと store-load という順番になって、ロードが遅れてしま
うらしい、という話が書いてあるんだけど、何処の時点の話をしているのかわか
らない。

・スタックへ値を push
  stack[++sp] = top_of_stack_register; // store
  top_of_stack_register = val;         // load

　この順番で、store-load という順番になってしまい、load の遅延が隠蔽でき
なくてよろしくない、という話？　しかし、load って何を load だ？


2.3 Position-based Handler Customization

　BPRs (bytecode prefetch registers) というレジスタに、バイトコード列を
格納しておいて、ロード回数を減らそうという話。

　しかし、現在位置がわからないのでなんとかしないといけない。命令ごとに分
岐はコストが高いので嫌だ。

　そこで、Dynamic stack caching みたいに、キャッシュのどの位置から始まる
かで状態遷移マシンを作って、それぞれに命令ハンドラを作ってしまおう（この
論文だと4状態）、という話。豪快だなぁ。

　これを、PHC: Position-based handler custimization という。

　しかし、BPRs が 2 レジスタ 64bit だった場合、4状態じゃ足りないと思うん
だけれど。

　って、BRRs は、順次レジスタをシフトしていくんですね。

  BPR[0] = BPR[1];
  BPR[1] = seq[pc];

　なんとなく、オプコード、オペランドロード部分（つまり、状態遷移部分）
と、実際の命令ハンドラを分けてしまったほうが早そうな気がするんだけどどう
なんだろう。そうすると、間接ジャンプが一個増えてしまうか（あと、命令ハン
ドラへジャンプする部分が集中してしまうので分岐予測が利かなくなる、と）。


2.4 Position-based Speculative Decoding

　これは、x86 には間接ジャンプのヒントを渡す方法が無いから（無いですよ
ね？）無視しておこう。


　しかし、レジスタが沢山あるから出来る話だな、これらは。x86_64 だとどう
なっていくんだろう。いいなぁPPC。


4.2 Improvement by PHC

　凄い速くなってますね。パックしておくとこんなに有利なのか。

5.1 Reduction of Memory Access

　PHC によってメモリアクセスが劇的に減ってますね。SC よりもフェッチ部分
のほうがアクセスがあるってことか。


5.2 Increase in I-Cache Miss Ratios

　DS よりも PHC のほうがミスが増えているのはなんでだろう。DS は 3 状態
で、PHC は 4 状態だからか？　でも、ミス率は DS の 2 倍くらいになっている
気がする。


　しかし、これらの評価はいったいどうやってとったんだろう。とても詳しい評
価になっているんだけど。

-- 
// SASADA Koichi at atdot dot net
//


--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml