引用:
|
作者nanri
instruction decoder，其實這部分之前的CPU就做得夠多了，
例如指令預解碼，
甚至是到了P4那階段，還用uOps cache來存之前解碼過的產生的uOps，
ALU的執行速度還是時脈的兩倍呢，
只不過單核效能還是上不去。
|
netburst之所以上不去除了pipeline太長外, 重要的是它並不是super scalar!! 只有一個issue port與一條20~31 stage pipeline(C2D開始一直是四條 12 stage pipeline除了短而有效率外 因issuer多而容錯率高也是重點), 可笑的是連個decoder都沒有! 一切instruction都塞給sequencer去解operand效率多好才怪更不用說這種實做方式超操branch prediction 也就是因為只有一條pipeline一旦出錯就GG了 而trace cache也算是這種設計的fail save 不過不像砂橋的uops cache那樣可以存取所有coding, trace cache的實作是有條件的也就是只能存取與上一個micro op有關聯的code 事後把好不容易取來的micro op照順序排列等下次不用解直接用 可是一旦遇到非data dependency就完了 一切重頭來. 之後的pipeline stall也是意料之中 這也是為什麼i社盡量鼓勵compiler使用simd來實作的原因 另外netburst並沒有真正意義的OoOE. 整個back end 就只有一堆shift register 跟 physical register file. 沒有OoOe 所必須要有的scheduler quote, reservation station, 以及能夠不按順序存取的 reorder buffer. 而physical register file能做的也只剩renaming而已 能夠把一直僅存於 out of order execution中的register renaming獨立出來也算是奇蹟
引用:
|
作者nanri
x86先天有很多eax,[記憶體位址]指令，
一旦執行到該指令，就卡，
就算解碼階段能避開，甚至是遇到要搬記憶體資料的指令就先跳過做別的(oooe)，
不過還是卡卡卡，最終還是得要把記憶體頻寬加得很大，
既然這樣，再多的issue，再好的scheduler，也是沒用。
|
x86先天上太過於依賴accumulator這個stack machine時代遺留的余毒 之前老外也談到這個問題而結論只能在long mode/flat mode/abi x32上解決對accumulator的依賴 但是長久之計便是要改寫整個isa來解決其根本問題 畢竟x86在long mode 下仍然有 register starve問題 增加register也只能算是必要之惡
引用:
|
作者nanri
工程的東西，
其實極限就在那邊，
有些東西，你在設計圖上面畫得很爽、很漂亮、功能很好很完美，
可是在實際製作上，得要考慮到現有材料的特性到哪，
想要超越這個極限，就得要改用別的材料，
這時成本又不同了，甚至是找不到這種材料來做；
甚至是你畫得出來，製作過程根本會無法施工，
只能改設計，改一改原本的功能...
|
是因為IA32太過沒效率了才會用暴力硬上 基本上你絕對看不到有哪一個isa會比ia32更燒錢而且更疊床架屋. 雖然x64解決了些386一直以來的問題 但是效率還是很不好