SASADA Koichi <ko1 atdot.net> writes:

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

ハンドラは64バイトおきに置いてあるんですよね．
64バイトにハンドラが収まらなかったら，他へ飛ぶんでしょう．
で，たいてい収まるし，「他へ飛ぶ」場合は分岐予測がヒットする．

> 2.2 stack caching

> 　ここでの（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 だ？

たとえば iload a とかの話では．

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

飛び先アドレスをプッシュしてRETとか，ダメかな．
ダメだろうな．

> 4.2 Improvement by PHC
> 
> 　凄い速くなってますね。パックしておくとこんなに有利なのか。
> 
> 5.1 Reduction of Memory Access
> 
> 　PHC によってメモリアクセスが劇的に減ってますね。SC よりもフェッチ部分
> のほうがアクセスがあるってことか。

dynamic superistructionでも，フェッチはかなり減りますからね．まあいろ
んな方法があると．

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

スタック状態には偏り(局所性)があるけど，バイトコードのアラインメントに
は偏りがないってことでは．

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

POWER3のhardware performance monitorを使ったとか書いてあるけど．

				前田敦司

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