Index
/
Reload
Edit on
2006-08-11
このコメントを修正します。
内容を修正した後で投稿時のパスワードを入力してください。
現在、コメントを削除する機能がありません。
コメントを削除したい場合には、 コメント欄を空欄にしておいてください (管理人が後で削除します)。
お名前:
E-mail or URL:
Password:
コメント:
お返事が遅くなってすいません。 まず言い訳をしておくと、もともとこの考察は IBM/370 「TSO」 と IA-64 の TSO (ld.acq と st.rel だけを使うモデル)の違いを考えることから出発していて、SPARC は念頭にありませんでした。IBM System/370 は store ← load の追い越しを許すが、store forwarding がないメモリモデルです。 # IBM はメモリモデルのことを ``Relation between Operand Accesses''と読んでいます。この定義は Global Visibility だけのものです)。 ネット上には IBM/370 メモリモデルも TSO に含める文献があって TSO と store forwarding は独立していると考えていたのですが、Total Store Ordering を考案した P.Sindhu の 1990 年の論文(``Formal Specification of Memory Models'')を読んでみると store forwarding を許さないものはそもそも TSO ではないとありました。 どうもこの私の勘違いが、うんのさんと噛み合わない問題点です。 SPARC プロセッサで、そのプロセッサの内部から見た実行順序が 2. load [X] → 3. load [Y] → 1. store [X] となるのは理解しているのですが、これが global visibility order かと呼ばれると激しく違和感があります。SPARC V9 Spec. 的には正しいのでしょうが。 実際のところ 2. の load はプロセッサの中で折り返してしまうので、メモリバスからは 3. load [Y] → 1. store [X] の 2 つしか見えないでしょう。プロセッサの外側から見える(見えない部分は補足する)メモリ・オーダーとしては 3. load [Y] → 1. store [X] → 2. load [X] の順になると思うのですどうでしょう。 # IA-64 は、load に global load と local load があるという形で visibility に折り合いをつけています。 P.S. SPARC の MEMBAR 命令は V9 になって詳細な設定ができるようになったのはいいのですが、現場のコーダーからすると混乱して溜まらんです。他のアーキテクチャのメモリバリアは MEMBAR の #Lookaside の効果が付与されたものが多いようです。
Powered by
くっつき BBS