Index
/
Reload
Edit on
2006-08-11
このコメントを修正します。
内容を修正した後で投稿時のパスワードを入力してください。
現在、コメントを削除する機能がありません。
コメントを削除したい場合には、 コメント欄を空欄にしておいてください (管理人が後で削除します)。
お名前:
E-mail or URL:
Password:
コメント:
こんにちわ。連休中は子守りモードにて、すっかりオフラインでした。 > おそらく global visibility order の定義が、私とうんのさんで異なるのだと思 > います。 そうですね、nminoru さんが、ハードの動作を正しく理解されているのは当初から 明らかなので、言葉遣いの問題になっています。 ただし、私は SPARC V9 に書かれているとおりの言葉で話しているはずですし、 私の確認したところ、それは IBM P.O.O. とも異なっていません。 (具体的な用語は別のものが定義されていたりしますが、用いられている概念は 同じ。)おそらくですが、TSO に関して話す文脈においては、そんなに変な言葉使い にはなっていないはずです。 日常的な言語感覚とかけはなれているかもしれないのは、なにかをフォーマルに定義 しようとする場合に珍しいことではないでしょう。 > パターンとしては (a),(b),(c) でしょうか。 > > (a) あるプロセッサの立場に立って、そのプロセッサが行った global なメモリ操 > 作(store buffer からデータを bypass された local load を除く)の順序関係。 > (b) あるプロセッサの立場に立って、そのプロセッサが行ったロード命令がデータ > の供給を受ける事象と、store 命令がデータをメモリに書き込む事象の順序関係。 > (c) あるプロセッサが行った全てのメモリ操作が「仮想的に」メモリに反映された > と考えた場合、それをその外側のプロセッサが観察していたと考えた場合の順序関 > 係。 > > うんのさんは (b) の立場で、私は (c) の立場なのだと思います。 いいえ。(a),(b) は明らかにあやまってますね。 Global visibility order というからには、あるプロセッサのメモリ操作を「外部か ら」観測したものです。 ただ、外部から観測されるというのがどういうことなのかという点で大幅に齟齬が ある模様です。 観測されるのは順序であって、各 load/store がそれぞれ global visible になった 瞬間に「あ、いまだ」と観測されるわけではありません。 結果的にプログラムがどう動いたか(だれの、いつの時点の store 値を load が受 け取ったか)を通じて、順序が観測されるのです。 > (a) なら簡単です。 > SPARC の memory ordering の定義を調べてみると (a) が近そうです。 > SPARC V8 Spec. は (Figure 6-1 Model of Memory の図を見ると明らかのように) > Single-Port Memory へのメモリアクセスの順序、つまりメモリトランザクション > の順序が memory ordering だと定義しています。そのため store forwarding を > 受けた load 命令(以下、local load と呼ぶことにします)は memory ordering に > よる順序付けの適用外になります。以下のように記述されています。 > -------- > A load by a processor first checks its Store Buffer to see if it contains > a store to the same location (atomic load-stores do not need to be checked > for because they block the processor). If it does, then the load returns > the value of the most recent such store; otherwise the load goes directly > to memory. SINCE NOT ALL LOADS GO TO MEMORY, LOADS IN GENERAL DO NOT > APPEAR IN THE MEMORY ORDER. A processor is blocked from issuing further > memory operations until the load returns a value. > -------- V8 が手元になかったので(手抜きですみません)、V9 と言葉使いが変わらないもの として。 SPARC の用語定義においては、Memory order と
memory model (こちらは global visibility に関する)
global visiblility order とは別の概念です。 Memory order の方は、ほぼ dependency order / self-consistency と同じ意味で 定義されています (V9 manual で D.2) したがって、上記引用のキャピタル強調部分の意味合いは、 「すべての load がメモリに出るわけではないので(つまり、store forwarding が許容されるので)、一般に、load が global visible になる順序は命令順 とは一致しない」 という程度のものになります。 nminoru さんのいうところの、「memory ordering による順序付けの適用外になりま す」がどのような意図のものか不明ですが、「TSO の守備範囲である」という解釈は 不可能です。 > SPARC V9 Spec も memory ordering は memory transaction がメモリに届く順序 > だと規定しています。 そんなことないでしょう。SPARC V9 では、D章にトランザクションは明にでてこない はず。(8章が description, D 章が形式的定義となっています) > 私は(ソフト屋ですから) local load 命令が global visible になったと考えるな > ら、仮想的に local load 命令がメモリから読み込んだと考えます。その場合、コ > メント[9] のプログラムだと 5: → 1: → 2: → 3: → 4: の順にならざる得ない > と思うのですよ。4: → 5: → 1: → 2: → 3: ではデータの消費(4:r2=[X] の読 > み込み)がデータの生成(3:[X}=1)に先立つと言う、因果律に反した事態になります。 ソフト屋さんの「生得的な」ボキャブラリと、Memory model 定義に用いられるボキャ ブラリが異なるであろうことは、私も、おそらく仕様書の執筆者も理解しています。 だから、SPARC V9 マニュアルでは、最初に用語の定義を行っているはずです。 「因果律に反した事態になります。」というあたり、私が最初に指摘したつもり だったのですが、self-consistency (あるプロセッサの立場にたって、自身のメモリ 操作を見たときに、命令順との矛盾がないこと)と global visibility を区別 していないようにしか見えません。 Processor 1 は、nminoru さんの提示実行例では、 1: → 4: → 5: → 2: → 3: の順で global visible になっています(記憶頼り)。 4: の実行時点において、3: のストアはまだ global visible でなかったというだけ であって、そのことはストアが未実行であることを示唆しないので、当然ながら、因 果律に反してはいません。まあ、因果律を持ち出す必要はなくて、memory model に 反していません。 Store には、未実行の状態(だれにも store 値は観測され得ない)、実行されたが global visible でない状態(ローカルからは見える)、global visibe になった 状態の3つがある、と。 > うんのさんは、 > > 4: は、2:,3: がいずれも global visible になっていなくても、 > > それらを追い越して global visible になれて、 > > 実際にそうなっているケースです。 > とおっしゃっておられるので、別の定義を採用されているのだと思いますが… というわけで、一貫して、スタンダードな定義を採用しているつもりです。 > > ちょっと話題は変わりますが、IBM のアーキが store forwarding を認めていな > > いというのは、おっしゃるとおりでした。 > (snip) > > しかし、この文章を store forwarding の禁止であると認めるのであれば(認め > > るのが正解だと思いますが)、 > > store forwarding した場合には、4: が 3: を追い越すのだと解釈することにな > > ると思います。 > > IBM System/370 には呪われし storage key という仕組みがあるためにちょっと特 > 殊なことになると思われます。load 命令が store 命令を追い越すと、そのこと > を他のプロセッサから検出可能なので… 「IBM System/370 には呪われし storage key という仕組みがあるため…」以下の説 明は、store forwarding を採用できなかった理由の説明としてはあり得ると思いま す。 が、Store forwarding をした場合、後続の load が先行の store を追い抜くことに なるという私と同じ言葉使いを IBM もしてますよという私の指摘に対する反論には なっていないはずですが。 ---- ひとまず、受身的に反応してみました。 しかし、nminoru さんは繰り返し同じ疑問を提示されていて、私も同じようなことを 言い続けているので、すっかり平行線ですね。 なにかきちんと述べられないか、少し考えてみます……。
Powered by
くっつき BBS