※ 引述《sitos (麥子)》之銘言：
: ※ 引述《dolphinus (鬼扯英吉GTB)》之銘言：
: : "執行後再存回 trace cache" 這段意味著跑玩的東西
: : 還會丟回 trace cache, 基本上不要說 trace cache,
: : 只要是 instruction cache 都是行不通的...
: : 我對這句話大感意外就是...
: 我不懂為什麼行不通? Instruction cache 裡面放的東西至少也是跑過一次的。
: 也就是在第一次要用的時候一起 fetch 進來的，那些 code 不算是跑過的嗎?
: 我不認為有「丟回」這個動作，一面把 code 從 I-cache 送到 decoder ，
: 一面把一份 code 寫進 trace cache 裡面以便下一次用，設計上並沒有困難。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trace-cache 我沒看到有說回寫或 rebuild trace 的這做法在裡面就是.. :/
程式那面要丟回 I-cache 是行不通的,
頂多下 prefetch 讓 Cache 去 reflash 掉..
(除了 486 可以以外..)
: : 不一定是用過的, 搞不好根本沒使用到那段, 沒被用到過
: : 就被替換掉了.
: : 不過我查到的結果是有些是用 LRU 有的是 TC 裡還有自己
: : 的 BTB..
: 我想要問的是，那第一次執行到該 code 的時候，到底有沒有真的執行?
: 如果根本就沒有執行到，為什麼會把那段 code 放到 trace cache?
: 如果有執行到，應該就算是執行過了，即使沒有 reuse 也算是執行過阿?
如果說是給 ALU 的話是 "沒有".
因為 trace cache 沒有很好的分支預測能力, 所以
比較多的狀況是遇上分支時就把兩種結果全 decode
放 TC 裡面等 CPU 看情況去跑哪一段 (雖然看來對
分支是蠻理想的, 不過這很佔 TC 空間..)..
這些 trace 建好了再丟給 CPU 去執行, 所以如果
就 ALU 來講的話, 剛擺上 TC 的東西肯定是沒執行
過的, 而擺上 TC 的東西因分支之故也不一定會跑..
: : 不一定是跑過的喔...
: : 最少在這兩種 TC 設計上都只是擺放而已,
: : 而且 TC 最重大的意義就是讓執行時能一條鞭一直下去
: : (只要 TC 沒滿..), 而已經確定執行過的指令可以存活
: : 在 TC 裡較久這樣...
: 所以有可能把根本不會執行到的指令放到 trace cache 裡面去嗎?
: 意思是說，當 branch prediction 結果出來以後就先拿進去放，
: 但是因為可能 prediction 錯了，所以擺進去的東西根本沒用到?
: 這樣的話擺進去的東西為什麼不用後來知道正確的 branch 結果取代掉呢?
: 或者一開始就應該要把確定已經確定執行順序的 code 放進去?
我所知道是會這樣做, 因為要考慮到萬一 prediction
miss 的狀況 (通常都很慘..), 然後沒被用到的那條
trace slot 在 TC 不夠用時再看用啥方法代換掉..
paper 上用 BTB 當參考, 而 netbrust 家族好像要到
prescott 才有真的實做 TC-BTB...
比較了一下 IA32 programming guide 還有一些講 P4
arch 的文章, 還有那兩篇論文等一些文章後的結論..
: 後期是多後期?
: 我會去問修課老師關於 intel project 的事情，
: 他之前是在 intel 做 compiler 的，應該會知道。
我忘了. 只記得是在 IDF 2006 夏秋那時跟 merom 一
起發表的新架構藍圖, 裡面有用上 trace processor
的概念..
不過從去年年底開始 intel 自己 roadmap 陣腳大亂,
會啥時真的用上我不知道了....
: : 有得罪之處還請見諒嘍. :)
: 沒這回事 :)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 編輯: dolphinus 來自: 61.216.216.190 (05/03 00:24)