※ 引述《dolphinus (鬼扯英吉GTB)》之銘言：
: [43] 雖然這篇跟後來實作的 trace cache 已經有很大的出入..
: : The first time a
: : trace is encountered, it is allocated a line in the trace cache.
: : The line is filled as instructions are fetched from the instruction
: : cache. 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. Otherwise,
: : fetching proceeds normally from the instruction cache.
: : 第一次碰到 trace 的時候，會將 instruction 從 instruction cache 存到
: : Trace cache 當中。當同一個 trace 再被遇到的時候，就會直接從 Trace cache
: : 直接把 instruction 拿給 processor 來 decode 。
: : 其它不再 trace cache 當中的 instruction 則還是從 instruction cache 當中拿。
: : 事實上這就是把一段執行過的程式碼存起來，等又碰到的時候再拿出來用。
: : 當然也有可能是因為我英文太爛看錯了，如果講得不對麻煩幫忙指出來。
: 我想在原文中並沒有提及 "執行後再存回 trace cache"
: 這種說法, 也沒有那一個 instruction cache 可以讓你
: 回寫指令的...
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 簡單的講它是一個 decoder + cache,
: 主要是從 L2 I-cache 抓進來的東西 decode 後再存放
: 到 L1 I-cache (trace cache) 裡, 這時 trace cache
: 裡面放的是 uOP, CPU 只需要直接抓來執行就可以.
: 所以這裡面存放的都是"未"被執行的 uOPs, 而非"已"
: 被執行的 uOPs.
上面這一段有些問題，第一，多數的 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 時就是已經執行過的程式了。
: 這時就有一個衝突了, 有 brench 怎麼辦? 不是 CPU
: 實際執行過才會知道是走那一條路嗎?
: trace decoder 在遇到這種狀況時, 它會盡可能兩種路
: 徑都去 decode, 因為 prediction 並不在 trace cache
: 裡面做, 一個分支就處理成一組 trace, 同時可以計算
: 好在 trace cache 裡的 jump offset 要多少, 再丟下
: 去給 CPU 執行..
我在 paper 裡面沒有看到這樣，我不知道商用 processor 怎麼做的。
不過 trace cache 名字既然是 paper 先定義的，應該以 paper 為準。
: (不過這個是後來 P68 實做時是這樣, 跟論文有異.)
: 所以 CPU 還有一個 brench prediction 跟 BTB 存在,
: 否則如果 trace cache 那麼完善的話, 也就不需要這
: 兩樣東西了...
trace cache 並不知道 prediction 的結果，它僅在 prediction 的結果，
與上一次執行的 control flow 相同的時候，才能被拿去使用。
這兩個東西是獨立的，跟 trace cache 是否完善並沒有關係。
trace cache 本身本來就沒有 prediction 的能力。
: K7 也有類似的 uOPs cache, 不過那是 cache 已經被
: 解碼過的 uOPs 出來, 其它像 trace rule 跟 decode
: 等完全沒有.
因為我才疏學淺，所以完全看不懂，我對 K7 不熟，也不知道 trace rule 是什麼。
: ----
: 後面看有沒有必要寫個 trace cache 小心得, 個人雖
: 對 netbrust 家族的東西問題居所有 x86 之冠很反感,
: 但 trace cache 卻是個很棒的設計...
: 除了佔用的 die size 以外...
我也不知道 netbrust 是什麼，也不知道 x86 的 implementation 是什麼。
不過那對 research 不太重要，所以從來沒有認真去了解過。 :)
--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.248.178.71