Index
/
Reload
Edit on
2006-08-11
このコメントを修正します。
内容を修正した後で投稿時のパスワードを入力してください。
現在、コメントを削除する機能がありません。
コメントを削除したい場合には、 コメント欄を空欄にしておいてください (管理人が後で削除します)。
お名前:
E-mail or URL:
Password:
コメント:
せっかくお付き合いいただいているので、私ももう少し時間をかけて書かなければならないと思っていますが、まずはすぐにコメント可能な点から。 > これが global visibility order かと呼ばれると激しく違和感があります。 > SPARC V9 Spec. 的には正しいのでしょうが。 うーん、いいたいことがいくつか。 2. load [X] → 3. load [Y] → 1. store [X]は、global visibility order 以外の何者にもなりえないと思います。 プロセッサの内部から見た実行順序、というのが、このプロセッサ上のソフトウエアから見たという意味なのだとすると、 これが 2 → 3 → 1 だったら困ります。 きっと、nminoru さんが実行順序といったときには、program-visible な順序ではなく、ハードインプリに依存した処理順序を想定されているだろうと思いますが……。 また、global visible になる時点というのは、バストランザクションが発行される時点という意味ではありません。 バストランザクションそのものは、ソフトウエアには観測されないので。 これは、SPARC V9 であろうと、なかろうと普遍だと思うのですが。 話を戻すと、2. の load が外から直接は観測されないというのは、ご指摘の通りだと思います。間接的に決まる位置を補った結果、2. load [X] → 3. load [Y] → 1. store [X] に見えることになります(global visible 順序として)。 > # IBM はメモリモデルのことを ``Relation between Operand Accesses''と読んでいます。この定義は Global Visibility だけのものです)。 IBM のメモリモデルと SPARC V9 の TSO は同じはずだなんですけど。 会社にいったら、poo を確認してみます。 SPARC V9 の TSO だって、global visibility だけのものですよね。 > SPARC の MEMBAR 命令は V9 になって詳細な設定ができるようになったのはいいのですが、現場のコーダーからすると混乱して溜まらんです。 TSO だけじゃなくて、PSO,RMO においてもきめ細かく制御できるようになっていますからね。 ただ、私がおもうに、SPARC V9 のメモリモデルは、とても明晰に記述されていると思います。
Powered by
くっつき BBS