kono@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

> 分岐予測に関してはそうですね。でも、サブルーチン・コールの爲
> に外部メモリに触るってのは限界があるだろうってことです。
> 
> PowerPC の link register は、優れていると思う。けど、SPARCの
> 方式は外れ。いつかは外部メモリに触れるとしても、それをコンパ
> イラなりハードウェアなりが「隠れてこそこそ」やりたい。

えっと，leaf procedure以外では必ずlink registerをスタックにセーブする
んじゃないでしょうか? それはPowerPCもMIPSもAlphaも同じでは．

CISCだと，leafへのcallでもメモリへの参照が起きる．
SPARCだと，leaf以外でもメモリに書かないこともある．

戻りPCに関するメモリへの参照の回数だけで言ったら，
CISC > PowerPC = MIPS = Alpha = ... >= SPARC
では?

(もっとも，引数や局所変数も考えると 他のRISC >= SPARCとは必ずしも言え
ないけど．)

> > データパスを考えると分かりますが，PCは特別扱いした方がほとんどの場合有
> > 利だと思います．
> 
> 予測に関しては、命令部で予測するかオペランドで予測するかの違
> いだけだと思うんだけど... 
> 
> なんていうのかな、
>     a = b?3:4 
>         cmp b
>         jz _2
>         move r10,3
>         j _1
>     _2: move r10,4
>     _1: st   a,r10
> より分岐を計算に書き換える 
>     a = b*3+(!b)*4 
...
> の方が速いってのは、分岐に演算が関わってないからであって、本
> 来は前者の方が速いべきなんじゃないかなと思います。...

偏りがあるなら分岐予測が効いて，分岐でやった方が速くなるんじゃないです
か．

同じくらいの確率だとすると，分岐だけで頑張るには，分岐の両方向について
投機的に命令の実行を始めないといけないと思うのですが，そのアプローチだ
と無駄な(投機に失敗する)命令が指数関数的に増えてしまって，プロセッサ資
源の無駄使いになります．

> データパス的には「PCにかけ算する」なんてのは確かに出て来ない
> ので、無駄なのかも知れない。でも、Shard Library とかの
> PIC (Position Independent Code) とか、オブジェクト指向的な
> 間接コールが多量に出て来る状況では、結構、汎用的に使われてます。

問題は頻度ですね．そういう使い方が(SPEC INTのベンチマークで高い頻度に
なるくらい)良く出てくるなら，プロセッサもそれに対応すると思います．

> PowerPC は良くできてます。ただ、
>       cmp flag1
>       cmp flag2
>       cmp flag3
>       jcond flag1,_1
>       jcond flag2,_2
>       jcond flag3,_3
> みたいなのって、いかにもIPCのためであって、実性能とは関係ない
> って感じがしませんか?
>       cmp 
>       jcond _1
>       cmp 
>       jcond _2
>       cmp 
>       jcond _3
> でできるはずだってわけです。

むしろ，下のコードで3つのcmp ... jcond ペアの間の依存性を無くそうとい
うのが狙いでしょう．flagが1つだと逆依存(や出力依存)が出てきてしまいま
す．renaming すれば良いという話もありますが，ここはscoreboarding風な集
中制御にしてあります．この辺はdesign decisionでしょう．

> > # いわゆる「アセンブリ言語プログラマから見たきれいさ」は，あまり性能に
> > # 結び付かないように思います．
> 
> コンパイラは静的予測を行ない、CPUは動的予測を行なう。その間
> の橋渡しがアセンブラ言語の予測に対する機能ですね。
> 
> 予測と動作記述を分ける方が良いってことなのかな。

いや，そのー「link registerを汎用レジスタにする」とか「PCを汎用レジス
タにする」とか，「直交したアドレッシングモード」とかは，別に速くならな
いことが多いということです．あとは「OOの効率良い実装のための命令」とか
も．
                                前田敦司