Intel命名Sandy Bridge 的微架構是基於Core 2 和Nehalem的第二代設計。在解碼器後面加入了新的uop cache，並且浮點執行單元從128bit擴展到256bit。
Sandy Bridge 有2-8 個core，其中的一些版本可以在每個core上運行雙線程。
支持新的AVX 指令。將16個128bit的XMM寄存器擴展到256bit的YMM寄存器用於支持浮點向量運算。大多數的XMM和YMM指令是AVX指令集中non-destructive three-operand 版本。
9.1 Pipeline
Sandy Bridge 和 Ivy Bridge 與Core2 和 Nehalem的流水線非常類似，但是在譯碼器後面增加了uop cache。
Sandy Bridge 的重排序緩衝區有168項，Ivy Bridge 的有192項。Sandy Bridge 的保留站有54項，Haswell有60項。Sandy Bridge 有160個整數寄存器和144個向量寄存器。Haswell各有168個。
9.2 取指和解碼
預先解碼和解碼器可以每週期處理16byte或者是4條指令。在macro-op fusion的情況下可以處理5條指令。這看上去基本上和Core2 和Nehalem中的基本一致。
任意個數前綴的指令都可以單週期被譯碼掉。
在一些case中，變長前綴的懲罰已經被解決。還有一部分遺留：
- 使用立即數的move指令沒有懲罰
- 使用立即數的算術和邏輯計算有2-3個週期的懲罰
- 單16bit操作數的NEG，NOT，DIV，IDIV，MUL和IMUL指令沒有懲罰
- 地址大小前綴沒有懲罰，即使已經改變了指令長度。
有4個譯碼器，可以在特定模式下處理一條或者多條uops。如下的指令在我個人的測試中，在單週期被成功地解碼。
- 1-1-1-1
- 2-1-1
- 3
- 4
產生3-4條uops的指令被單獨的譯碼。產生超過4條uop的指令由microcode處理，較爲低效。
多byte的NOP指令和操作數0F，1F 只能在Sandy Bridge的第一個譯碼器中譯碼。然而一個簡單的NOP，帶有格外的前綴（opcode 66 66 90）可以被四個譯碼器中的任意一個譯碼。Ivy Bridge 對此沒有限制。在Ivy Bridge 中，長NOPs可以按照每週期4條指令的速度譯碼。
9.3 uop cache
Sandy Bridge 和Ivy Bridge 在decoders之後有一個cache用於存放解碼過的微指令。考慮到平均指令長度超過4byte，fetch和譯碼單元每週期傳輸16byte將會是一個很嚴重的瓶頸。因此這個uop cache將會十分有效。uop cache使吞吐率加倍達到每週期32byte。
uop cache爲32sets * 8 ways * 6uops，總計最多可以存儲1536條uops。它一次最多分配3line * 6uops 給對齊且連續的32-byte 指令。
來自uop cache的code，不會被fetch和解碼單元所限制。它可以實現4uops的吞吐率，等效於每週期32byte的指令。
Uop cache很少能夠用滿1536條uops。無法發揮全部潛能的原因如下：
- uop cache line是被分配到特定的32 byte 指令block。 新的uop cacheline將被分配到新的 32byte 邊界。即使前一條uop cacheline只被部分使用
- 產生多條uops的指令不能佔用兩個uops cache line。如果指令不能完全的被兩條 cacheline所打斷，那麼剩餘的cache line就不會被使用。它會另起一行，放入新的cache line
- 產生超過4條uops的使用microcode ROM。這樣的指令會使用完整的一條cacheline
- 無條件跳轉和調用函數指令通常結束 uop cacheline
- 要求超過32bit的存儲空間的指令可能佔用uop cache 中的兩項，加載時可能會多花費一個週期
- 每週期不能加載超過一條cache line。這在多個指令使用兩項時，可能會造成瓶頸
- 一個32byte 的指令block 產生超過18條uops 或者要求uop cache中的18 項的指令不會被分配到uop cache中
- pipeline頻繁的在譯碼單元和uop cache之間切換，切換可能會花費一個週期。
翻譯自【Microarchitecture of Intel and AMD CPU An optimization guide for assembly programmers and compiler makers】
歡迎關注我的公衆號《處理器與AI芯片》