推 lookers:懷舊不要懷到吵起來喔XD 05/02 21:30
推 apomiya:貼論文阿.... 05/02 21:57
推 dolphinus:"A Trace Cache Microarchitecture and Evaluation" 05/02 21:59
※ 編輯: dolphinus 來自: 61.216.216.190 (05/02 23:08)
※ 引述《sitos (麥子)》之銘言：
: ※ 引述《dolphinus (鬼扯英吉GTB)》之銘言：
: The first time a trace is encountered,
: it is allocated a line in the trace cache.
: 第一次碰到的時候，給它一個 cache line 去存。
: 這時候應該有執行，一面執行一面放進 trace cache 的 cache line 。
: If the same trace is encountered again in the course of executing
: the program, i.e. the same starting address and predicted branch outcomes,
: it will be available in the trace cache and is fed directly to the decoder.
: 下一次碰到並且有一樣的 branch prediction 結果時，
: 就把它從 trace cache 中拿出來給 decoder 。
: 看一下論文嘛，又沒有多少，它真的沒有講嗎? 我英文太爛了 orz
所以請你指出那裡有講到 "執行後再存回 trace cache" 這種說法?
有那一個動作可以從已經過 ROB 之後的東西再丟回 I-cache? 沒有吧?
: 上面這一段有些問題，第一，多數的 processor 沒有 L2 "I"-cache ，
: L2 大部份都是 unified cache 。所以我不太清楚這邊說的是什麼。
: 第二，照 paper 所講，的確是在處理 non-continuous basic block 的問題，
: 要把 instruction sequence stream 放成 continuous basic block ，
: 至於要不要存 micro-operation 似乎不是 paper 的重點。
: 我是不知道 x86 是存 micro-instruction 還是 instruction ，
: 但是 cache 如果沒有 reuse 就不叫 cache 只能叫 buffer ，
: 因此 trace cache 即使第一次存放時是未執行的，
: 到了第二次用到同一串 instruction 時就是已經執行過的程式了。
所以我才說你貼的這篇論文只是最早的 trace-cache
論點, 並不是 netbrust arch. 上所使用的 trace-cache,
netbrust 上的 trace cache 的確也是解 non-continuous
的問題, 不過它放的是 uOPs, 不是 instruction, 你這篇
論文裡放的是一般 instruction.
同樣的, 只要執行到同樣 trace 就會抓到 cache 裡已存
的內容, 但這不等於回存.
: 我在 paper 裡面沒有看到這樣，我不知道商用 processor 怎麼做的。
: 不過 trace cache 名字既然是 paper 先定義的，應該以 paper 為準。
netbrust arch 上用的 trace cache 跟你這篇 paper
不同之處還不只是我上面講擺的東西不一樣而已...
第二個不一樣之處, 在於 paper 裡 decoder 是擺在最後
段的, branch prediction 也是跟 trace cache 擺一起,
而 BTB 更會根據實際的執行結果去代換掉某些 trace,
但實際在 netbrust arch 上的做法它沒有根據後端 BTB,
(這上面 TC 有它自己的 BTB..), 不像論文所說, 不會根
據後端的執行結果, 來決定來決定那個 trace slot 該被
換掉, netbrust 上的 trace cache 有自己的參考點.
(記得不同版本 P4 不一樣, 有的用 LRU 非 TC-BTB.)
兩者的巨大差別請先弄清楚, 這串主要討論的也是商用品,
trace cache 裡面放什麼東西是會影響到它遇上 branch
時該去參考那一個分支預測的結果.
: : (不過這個是後來 P68 實做時是這樣, 跟論文有異.)
: : 所以 CPU 還有一個 brench prediction 跟 BTB 存在,
: : 否則如果 trace cache 那麼完善的話, 也就不需要這
: : 兩樣東西了...
: trace cache 並不知道 prediction 的結果，它僅在 prediction 的結果，
: 與上一次執行的 control flow 相同的時候，才能被拿去使用。
: 這兩個東西是獨立的，跟 trace cache 是否完善並沒有關係。
: trace cache 本身本來就沒有 prediction 的能力。
請看 2.1 節那邊對 branch 的敘述, 原始的 trace cache
是擁有 branch prediction 能力的, 但商用品沒有.
(ps.這裡要保留, 查到的結果是不一定..)
這一篇論文跟傳統 I-cache 的觀念還是很接近, 跟最後被
實作的 trace cache 已經相差很遠了.
這篇第二個作者在 1999 年也有發表一篇相關論文, 同樣
也是指出 trace cache 對 branch 上的改善.
特別是替換掉 trace 的判斷做法都不一樣時, 這論文只能
僅供參考而不是當聖經.
: : K7 也有類似的 uOPs cache, 不過那是 cache 已經被
: : 解碼過的 uOPs 出來, 其它像 trace rule 跟 decode
: : 等完全沒有.
: 因為我才疏學淺，所以完全看不懂，我對 K7 不熟，也不知道 trace rule 是什麼。
那請去看幾篇專講 trace processor 的論文...
: : ----
: : 後面看有沒有必要寫個 trace cache 小心得, 個人雖
: : 對 netbrust 家族的東西問題居所有 x86 之冠很反感,
: : 但 trace cache 卻是個很棒的設計...
: : 除了佔用的 die size 以外...
: 我也不知道 netbrust 是什麼，也不知道 x86 的 implementation 是什麼。
: 不過那對 research 不太重要，所以從來沒有認真去了解過。 :)
這...
--
※ 發信站: 批踢踢實業坊(ptt.cc)