Index
/
Reload
Edit on
2006-08-11
このコメントを修正します。
内容を修正した後で投稿時のパスワードを入力してください。
現在、コメントを削除する機能がありません。
コメントを削除したい場合には、 コメント欄を空欄にしておいてください (管理人が後で削除します)。
お名前:
E-mail or URL:
Password:
コメント:
# コメント[22]の続き まず一番最初の日記部分に戻ります。 私は store forwarding を認める TSO(*1) の memory model で 1:store [X] → 2:load[X] → 3:load[Y] を実行した場合、その memory order が 2: → 3: → 1: になることは認めています。また、それが TSO Memory Model の仕様に反しているとは言っていません。 「問題がどこにあるかというと、プログラマーがこの挙動を外側から見ると、… このタイプのロード→ロードの追い抜きは発生する。」の述べているように、TSO に従った動作をするプログラムであっても外側からプロセッサを観察するとロード→ロードの追い抜きが発生しているように見えると言っています (私の書き方が悪くて誤解を生じているかもしれませんが)。 # (*1) この表現には問題があることは認めます。コメント[5] で述べているように Store forwarding を認めないと TSO にはなりません。 私の認識: 外側からのプロセッサの観察 = global visibility order ≠ TSO うんのさんの認識: 外側からのプロセッサの観察 ≠ global visibility order = TSO なのだと思います。 上で「外側からのプロセッサの観察」と言っているのは、以下のようなモデルを基に "order" がどうなるのかを逆算したものです。表現は面倒ですが以前のコメントで言っていることと同じで、ソフト屋が普通に考えるプロセッサ実行の推論モデルだと思います。 ・プロセッサが実行した命令列は判明している。 ・プロセッサは以下のルールを守る限り命令を自由に入れ替えて実行する可能性がある。 ただし命令は1命令づつ逐次的に実行され、その度に完了したと考える。 a) レジスタに依存関係がある場合はその順序に従い実行された。 b) 制御に依存関係がある場合はその順序に実行された。 c) ロード・ストア命令は "order" の順序に従い実行された。 ・実行結果(メモリの内容とレジスタの最終値)は、現状と一致すること。 おそらくそれでも、うんのさんは「外側からプロセッサを見ても、そのメモリ操作の順序は memory ordering に従うというのが正しい」とおっしゃりたいでしょう。しかし最初の日記部分はもともと似て異なるメモリモデル間のプロセッサの間でメモリ操作の "order" を考えていたわけで、モデル依存しすぎる定義では意味をなさないのです。 > 私が示したような理解は、SPARC-V9 の記述を素直に読めば > 得られるものだと思います。 > それ以外の解釈(たとえば nminoru さんのような)は、 > SPARC-V9 の記述は不完全なのではないかという偏見なしには > 得られないものだと思います。 > > IBM poo と同じく、SPARC-V9 のメモリモデルも、 > ソフトから観測される振る舞いのみに着眼してかかれています。 > > そうではないと考えた根拠、 > また、SPARC-V9 TSO の記述が不完全だと考えた > (こう考えているから、どこからともなく規則をもちだしたの > だと理解しています)根拠は何なんでしょうか。 SPARC V9 TSO のメモリモデルに関しては、(SPARC V9 Architecture Manual の表現のぶれはあると考えますが) 全体として不完全だと考えていません。 問題は「外側からのプロセッサの観察した場合のメモリ順序」で、この順序の解釈が私とうんのさんで違う理由はコメントの前半部分でご理解いただけませんか?
Powered by
くっつき BBS