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

> 河野真治 @ 琉球大学情報工学です。
> 
> In article <m3brs479jh.fsf@maedapc.cc.tsukuba.ac.jp>, MAEDA Atusi <maeda@cc.tsukuba.ac.jp> writes
> > inlineしないspecializationって，specializeした色んなバージョンのサブルー
> > チンを作るってことでしょうか．だったらinliningしても良いような．
> 
> 実はおんなじ引数で呼ぶってのがたくさんあるからinlineにしたい
> わけなので、それらが共用される可能性があるからspecialization
> の方が優れていると思います。(subroutine のoverhead が小さければ...)

「おんなじ引数で呼ぶってのがたくさんある」というのは良く分からないなあ．
それも静的にですよね．そんなことがそれほどあるのかしらん．

「polymorphicな関数を型についてspecializeする」とかなら価値はあると思
うけど．

> In article <m37k2s760a.fsf@maedapc.cc.tsukuba.ac.jp>,MAEDA Atusi <maeda@cc.tsukuba.ac.jp> writes
> > 他のRISC(SPARC, Alpha, PA-RISC, MIPS)は汎用レジスタをcallのlinkageに使
> > いますね．Pentium4やAthlonは，オンチップにreturn address stackをそれぞ
> > れ16, 12エントリー持っていて，RET命令の分岐先を予測するのに使います．
> 
> スタックトップが大域メモリにあるとそこを書き換える可能性を否
> 定できないので限界はあると思います。結局、スタックマシンは、
> 階層型メモリに対応できてないってのが僕の考えなんだけど。

分岐予測は，外れても遅くなるだけなので，「可能性が否定できない」程度の
頻度しか外れないなら，やる利益の方が大きいのです．(メモリの参照を減ら
すための仕組みではないです．)

> 一方で、return とか分岐判断用の専用のレジスタがあった方がい
> いかというと、それも少し疑問に思ってます。VAX みたいに、PC 
> が汎用レジスタって方がやっぱりいいんじゃないかな。昔は、予測
> や依存関係の解消にハードウェアを割けなかったから、だめだった
> んだけど... 

データパスを考えると分かりますが，PCは特別扱いした方がほとんどの場合有
利だと思います．

> > link registerが専用レジスタだと，整数演算とcall/returnの間に依存関係が
> > なくなります．また，PowerPCは条件call(すべての分岐命令はlink bit が1だ
> > とPC を保存), 条件return(branch conditional link register命令)があると
> > いう意味では，普通のアーキテクチャより汎用性があります．
> 
> 整数演算とcall/return/branchには、結局、依存関係はあります。
>    if (i+3===hoge) do_process();
> みたいな感じですよね。むしろ積極的に依存関係を使って動作を予
> 測して良く方が良い。逆に、ハードウェア量に制限があるなら、命
> 令の種類を増やすのはまずい選択だと思う。

そういう間接的な依存関係はもちろんありますが，例えば100^2よりも
50^2 + 50^2が小さくなるように，命令の種類を分ける意味はあります．

例えば最初のPowerPC601は機能ユニットごとに別々のリザベーションステーショ
ンを持ち，命令の種類でまずそれぞれのリザベーションステーションにディス
パッチしています．分岐ユニットのリザベーションステーションには整数演算
が入ってこず，link registerと条件コードに関してのみの依存関係を調べま
す．

条件コードを書き換える整数演算の後に，それに依存した条件分岐がある場合，
フラグビットにinterlockがかかった状態で分岐がディスパッチされます．フ
ラグの値が十分早く確定しなかった場合は，(601では静的)分岐予測を用いて
処理を進めます．

また，逆に，分岐がlink registerやcount registerを書き換え，先行する整
数演算命令がそれらに依存している場合は，renamingで依存を取り除きます．

>      r10 = 0x234234234+r11
>      pc = r10
> みたいなのと、switch (i) みたいなのって、あんまり変わりません
> よね。

そういう計算型gotoみたいなのばっかり実際のアプリで使われるならそうでしょ
うね．

> 条件callや条件returnが使えないのは、コンパイラを書いてみると
> わかるんだけど、
>      call する前にしなければならないこと
>      return する時にしなければならないこと
> が山程あるからです。

さあ，specializeしたsubroutineなんかは，使う絶好のチャンスに見えますが…

いずれにせよ，PowerやARMがこれらの命令セットを決める際には統計的な根拠
に基づいて決めたはずです．定量的な値なしでは何とも私には言えません．

> さらにPowerPCの複数あるフラグとかで分岐予測しやすいようにし
> てやると、早めの分岐という意味では逆に遅くなります。また、C 
> のような言語だと計算と分岐の順序をいじるのは危険すぎる。なの
> で、結局、フラグは一つしか使わないってことになりがち。

これは，分岐予測じゃなくて資源競合による偽の依存を避けるためでは?  効
けん過ぎると言うのは何のことか良く分かりませんが，最新のプロセッサはど
れも分岐を越えて投機的な計算を行なっています．

> たぶん、PowerPC には「速くしたい特定のアプリケーション」
> ってのがあったので、ああいう命令になったんだと思います。
> しかし裏目に出てるような気がするな。

兄貴分のPowerは常にIPCではトップクラスの値を誇っており(懐かしい言葉で
言えばbrainiac approach)，性能的にもトップグループにいます．その後を追
うPowerPCも，特に今度の970はクロックも上げてきてなかなか頑張っていると
思いますが．

# いわゆる「アセンブリ言語プログラマから見たきれいさ」は，あまり性能に
# 結び付かないように思います．

                                前田敦司