Index
/
Reload
Edit on
2006-08-11
このコメントを修正します。
内容を修正した後で投稿時のパスワードを入力してください。
現在、コメントを削除する機能がありません。
コメントを削除したい場合には、 コメント欄を空欄にしておいてください (管理人が後で削除します)。
お名前:
E-mail or URL:
Password:
コメント:
うんのさんのコメント[24]へ: (I) > > PoO の一番素直な解釈では「a conceptually subsequent storage-operand > > fetch from the same main-storage location が storage-operand store > > を追い越した状態」とは、self-consistency が壊れた状態ですよ。 > > わたしはこれには同意しません。 > > 私が同意しない理由は、段落の最初、"As observed by other CPUs and > by channel programs" が効いているので、この文を認め、かつ、その CPU 自身 > からみれば conceptually order が見えるという両立が成り立つから。 うんのさんは、(B) の文は conceptual order 則を含んでおらず、もっと前にある 5.13.1 Conceptual Sequence 節などに書かれた原則が適用できるという解釈なのだと思います。 私が元コメント[20]のように書いた理由を述べておきます。 一つ目はコメント[26]で述べている IBM 370 自身の古さや、先行の IBM 360 のメモリモデルの問題です。 二つ目は PoO の中に書かれた (B) 以外の記述との整合性です。 私は PoO は重要な規約は繰り返し具体的に述べられていると考えます。メモリ操作をオーバーラップする CPU の中で conceptual sequence を守るためには memory disambiguation が必要です。これに該当する記述は、5.13.10 節の (B) の以外では 5.13.8.2 節 "Storage-Operand Store References" の以下のパラグラフになるはずです。 (C) The CPU does not fetch operands, ART-table entries, or DAT-table entries from a storage location until all information destined for that location by the CPU has been stored. Prefetched instructions may appear to be updated before the information appears in storage. System/370 PoO の "Storage-Operand Store References" は、やはり同様の記述を含んでいます。 (C') A CPU does not fetch operands, or dynamic-address-translation table entries, from a main-storage location until all information destined for that real main-storage location by that CPU has been placed in main storage. Prefetrched instructions may appear to be updated prior to the information appearing in storage. この二つのパラグラフは、ある CPU に立った動作として store が終わるまで fetch を行わないというものですから、CPU の内側からの conceptual order に関する記述と読めます。なおかつ CPU が store を完了し "all information destined for that location" になる時点まで待つので、外側から見た場合の順序も規定することになるでしょう。 問題の ESA/390 PoO の 5.13.10 節の (A), (B) の記述は、5.13.8.1 節 "Storage-Operand Fetch References" と 5.13.8.2 節 "Storage-Operand Store References" を合わせたものの要約になっています。(B) の記述は上の (C) のパラグラフを端的に言ったものだと私は考えます。そのため (B) は store forwarding の禁止則であると同時に、self-consistency に関する規則でもあると判断するのです。 # 小さな点ですが、コメント[26] で述べた 370 PoO には段落の最初の # "As observed by other CPUs and by channel programs," がありません。 ----- (II) > 1: STORE [X] = 1 > 2: LOAD r1 = [X] > 3: if r1 == 1 { LOAD r2 = [Y] } > のようにしてみては、どうでしょう。 コメント[8]の例ですね。 まずこれは 3: → 1: の追い越しが起こっていると考えていいですね。 この場合、私のやり方で外側からプロセッサを観察をすると、 ・メモリのアクセス順序を 3: → 1: → 2: と判断して、3: が制御を越えて先行してしまった矛盾を抱える。 ・メモリのアクセス順序を 2: → 3: → 1: と判断して、2: と 3: が逆転してしまった矛盾を抱える。 のどちらかだと思います。 矛盾があるようではダメだと言われるかも知れません。 ただこの矛盾は、元の日記の 1: STORE [X] = 1 2: LOAD r1 = [X] 3: LOAD r2 = [Y] が 3: → 1: → 2: に見えて、TSO と較べると 2: と 3: の逆転が起きるように見えて困ったねというのと同根だと思います。 # 外からブラックボックスとしてプロセッサ見ていると、local load のような in-flight な操作を見切れないと問題 ----- > (III) (横道だとは思いますが、)わたしが、いつ、poo に > store forwarding を導入しようとした場合の困難について言及しましたか? > 「この一文が store forwarding の禁止に相当する」という主張と、 > 下の主張には随分隔たりがあるように思います。 うんのさんの主張は「この一文が store forwarding の禁止に相当する」だけではなく、例えばコメント[13]の「Store forwarding をした場合、後続の load が先行の store を追い抜くことになるという私と同じ言葉使いを IBM もしてます」とおっしゃっています。 過去のうんのさんの発言から、私は以下のように推論しています。 1. うんのさんは ESA/390 PoO の 5.13.10 節 の (B) は store forwarding の禁止則であると認めている。 2. うんのさんは IBM S/370 のメモリモデルに store forwarding を導入することを検討された。 3. 2. は PoO の書き換えと同義である。 4. うんのさんは (B) の記述から S/370 のメモリモデルに store forwarding を導入した場合「a conceptually subsequent storage-operand fetch from the same main-storage location が storage-operand store を追い越させる効果がある」(コメント[17])と考えられている。 5. 1.〜 4. より、うんのさんは IBM S/370 メモリモデルに store forwarding を導入しようとし、PoO から (B) を削除あるいは変更し、PoO の中に 4. の同一アドレスの load が store を追い越せるいうルールを加える必要があると判断したと考えられる。 6. コメント[13]などから判断して、うんのさんは、storage-operand fetech reference が store forwarding によって local load のように扱われても構わないと考えていると思われる。その場合には 4. は 5.13.10 節の (A) 則に含まれるので、5. は (B) を削るだけで実現できる。 1.〜4. には合意いただけると思います。 5. は納得いただけませんか? 5. → 6. は私の推論ですので、うんのさんが違うとおっしゃられれば謝るほかありません。
Powered by
くっつき BBS