推 chiwa:branch? 05/02 18:29
我也是憑印像寫.
※ 引述《sitos (麥子)》之銘言：
: ※ 引述《sitos (麥子)》之銘言：
: : 反正只要能提高 hit rate 的手段幾乎都會用上去。
在 trace cache 上, 其實命中率的提高不是它主要重點.
: : 不過我也不知道 code cache 是什麼。
: "Trace Cache: a Low Latency Approach to High Bandwidth Instruction Fetching"
: (Tech Report 1310, CS DEpt., Univ. of Wisc. -Madison Apr 1996)
: 一文
[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 可以讓你
回寫指令的...
trace cache 簡單的講它是一個 decoder + cache,
主要是從 L2 I-cache 抓進來的東西 decode 後再存放
到 L1 I-cache (trace cache) 裡, 這時 trace cache
裡面放的是 uOP, CPU 只需要直接抓來執行就可以.
所以這裡面存放的都是"未"被執行的 uOPs, 而非"已"
被執行的 uOPs.
這時就有一個衝突了, 有 brench 怎麼辦? 不是 CPU
實際執行過才會知道是走那一條路嗎?
trace decoder 在遇到這種狀況時, 它會盡可能兩種路
徑都去 decode, 因為 prediction 並不在 trace cache
裡面做, 一個分支就處理成一組 trace, 同時可以計算
好在 trace cache 裡的 jump offset 要多少, 再丟下
去給 CPU 執行..
(不過這個是後來 P68 實做時是這樣, 跟論文有異.)
所以 CPU 還有一個 brench prediction 跟 BTB 存在,
否則如果 trace cache 那麼完善的話, 也就不需要這
兩樣東西了...
K7 也有類似的 uOPs cache, 不過那是 cache 已經被
解碼過的 uOPs 出來, 其它像 trace rule 跟 decode
等完全沒有.
----
後面看有沒有必要寫個 trace cache 小心得, 個人雖
對 netbrust 家族的東西問題居所有 x86 之冠很反感,
但 trace cache 卻是個很棒的設計...
除了佔用的 die size 以外...
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.241.239.20