Index
/
Reload
Edit on
2006-08-11
このコメントを修正します。
内容を修正した後で投稿時のパスワードを入力してください。
現在、コメントを削除する機能がありません。
コメントを削除したい場合には、 コメント欄を空欄にしておいてください (管理人が後で削除します)。
お名前:
E-mail or URL:
Password:
コメント:
いつぞや唐突に乱入した、うんのです。(「リアルでは会ったことがある」とか、なんとか) 実用的には、大筋まちがっていないともいえますが、TSO の説明には誤りが見られるので、またでしゃばって来ました(すんません…)。急いで書いて、書きかたが失礼な個所があるかもしれません。あらかじめお詫びします(←ちょっとずるい) >その TSO でも store forwarding を認めていると > このタイプのロード→ロードの追い抜きは発生する。 これは、かなり典型的な混乱具合なのですが、Multi processor システムにおける global visible 順序と、self-consistency (綴りあってるかな)をごちゃまぜにされています。 Global visible の観点からみると、依存関係のある store と後続の load があった場合に、後続の load は先行の store を追い越すことができます。(文面通り、TSO はこれを禁止していません) この追い越しを self-consistency を維持したまま実現するのが、store forwarding なのですが。 繰り返すと、1. store , 2. load, 3. load があったときに、 2 の load が 1 の store を追い越しているのです。 だから、「TSO でも store forwarding を認めているとこのタイプのロード→ロードの追い抜きは発生する。」というのは、誤りですね。 > 難儀な話だ。こういう状況の解決策は、メモリフェンス命令を > 余計に入れたりアトミックなメモリアクセスが必要だったり > する。アーキテクチャ毎にやり方が異なるので要注意。 だから、「余計に」入れなくても、必要十分なだけ入れとけばいいのです。余計に感じるのは、TSO について少し混乱しているせいでしょう。 難儀な問題があるのは、確かですね。SPARC V8 なんて、TSO のくせに、適切な「フェンス」命令がなくて、アトミック命令で代用せざるを得なかったという噂ですし。
Powered by
くっつき BBS