向日葵教授 提到...嗯啊，我懶得去翻硬碟裡面的pdf了，隨便用Google喚起模糊的回憶。
Rock團隊也不知道在幹什么。
65nm的設計，拖到現在都看不到。
哇塞！超過兩年了耶！
In Jan 2007, Sun announced the tape-out of Rock.[12]
In April 2007, Sun CEO Jonathan I. Schwartz blogged an image of a fabricated and BGA-packaged Rock chip, labeled UltraSPARC RK, and disclosed that it can address 256 terabytes of virtual memory in a single system running Solaris.[13]
In May 2007, Sun announced the first silicon of Rock booting Solaris successfully.[14]
As a result of the ISSCC more information is coming out.[15]
Rock Arrived(2007/4/10)
Sunがサーバー向けハイエンドプロセッサ「Rock」の概要を公表(2008/2/4)
當然，這種算是很高檔、而且針對特定應用程式最佳化的server CPU，從CPU試作品到實際系統產品整機出貨有很大的時間差，也不是什麼讓人訝異的事情，更何況Rock最少也有2.0版了。
不過我很期待Rock（尤其當幕後黑手Oracle併購Sun之後）跑database和ERP的表現，如果真的可以做到Sun當初的預期，那高階server市場的遊戲規則可能就要被改寫，特別是製造業用的機器。
1. 一看到名稱，就認定因為AMD命名SSE5，而且維持128 bits XMM register，所以就只是過去SSE的結構性延伸：
這點完全是錯的。
AMD想克服自己搞出來的REX大包，順便弄出3 operand format/4 operand syntax，大規模更動encoding結構，光這點就可以讓這種「直覺反應」完全不成立。講難聽一點，AMD搶先註冊SSE5只是故意搞Intel一下，200%的行銷宣傳目的。
2. AVX對SSE5的優越性僅有「256 bits YMM vs 128 bits XMM」：
這點也完全是錯的。
Intel發展AVX的最主要目的，並不是只為了新增256bits YMM與後來被取消的4 operand format，而是想進一步克服x86指令encoding系統的老問題。如此一來，Intel未來的產品設計就可精簡Front-end，降低耗電量，保留日後更寬issue rate的延展性。
但AMD SSE5完全是疊床架屋，為了解決REX，卻又創造出複雜的DREX + Opcode3結構，人家Intel都把所有重要資訊集中在前方的VEX了，一收到就馬上開工，你卻要讀取大半個指令再玩配對遊戲，然後SSE5的1/2 operand指令encoding方式簡直讓我看到髒話都快罵出來，毫無邏輯可尋，要我畫出圖解根本是一種虐待。
假如AMD堅持下去，姑且不論早在2007年八月就公開的SSE5能不能被市場接受，光就CPU端效率和耗電而言，Bulldozer核心就大概保證打不過Sandy Bridge了。
In April 2007, Sun CEO Jonathan I. Schwartz blogged an image of a fabricated and BGA-packaged Rock chip, labeled UltraSPARC RK, and disclosed that it can address 256 terabytes of virtual memory in a single system running Solaris.[13]
In May 2007, Sun announced the first silicon of Rock booting Solaris successfully.[14]
As a result of the ISSCC more information is coming out.[15]
Rock Arrived(2007/4/10)
Sunがサーバー向けハイエンドプロセッサ「Rock」の概要を公表(2008/2/4)
當然，這種算是很高檔、而且針對特定應用程式最佳化的server CPU，從CPU試作品到實際系統產品整機出貨有很大的時間差，也不是什麼讓人訝異的事情，更何況Rock最少也有2.0版了。
不過我很期待Rock（尤其當幕後黑手Oracle併購Sun之後）跑database和ERP的表現，如果真的可以做到Sun當初的預期，那高階server市場的遊戲規則可能就要被改寫，特別是製造業用的機器。
向日葵教授 提到...這三個月下來，我發現很多人對AVX/SSE5有很大的「直覺性」誤解：
128bit對256bit怎么比
跟當年的3Dnow！一樣呀
功能被SSE包，而且是64bit對128bit，當時咬牙堅持下來了。結果沒人用，還搞到現在的U都要消費電晶體給3DNow！兼容用。
1. 一看到名稱，就認定因為AMD命名SSE5，而且維持128 bits XMM register，所以就只是過去SSE的結構性延伸：
這點完全是錯的。
總而言之，AVX和SSE5的關鍵，在於修正x86指令encoding系統的問題，沿用或創造哪些阿貓阿狗暫存器都完全不是重點。
請大家再跟我復頌一次，x86指令encoding三大問題：
1. Prefix: F3h / F2h / 66h
2. Escape opcode: 0Fh / 0F 38h / 0F 3Ah
3. REX: 去怪AMD吧...
AMD想克服自己搞出來的REX大包，順便弄出3 operand format/4 operand syntax，大規模更動encoding結構，光這點就可以讓這種「直覺反應」完全不成立。講難聽一點，AMD搶先註冊SSE5只是故意搞Intel一下，200%的行銷宣傳目的。
2. AVX對SSE5的優越性僅有「256 bits YMM vs 128 bits XMM」：
這點也完全是錯的。
Intel發展AVX的最主要目的，並不是只為了新增256bits YMM與後來被取消的4 operand format，而是想進一步克服x86指令encoding系統的老問題。如此一來，Intel未來的產品設計就可精簡Front-end，降低耗電量，保留日後更寬issue rate的延展性。
VEX整合Prefix/Escape opcode/REX，也創造「AVX體系舊x64/SIMD指令」，讓「舊」指令也能享受高速解碼的快感。實際上，大多數AVX指令都是「舊指令的升級版」，以FMA為主的新增指令反而只有48個。換言之，只要修改assembler，在既有指令的opcode前方加掛VEX（如VEX.NDS.128.66.0F38 DC /r），更換成AVX指令，即可大幅加速指令的解碼效率，Opcode Map還是一樣的，這也是AVX的核心精神之所在，也保留日後讓其他舊指令脫胎換骨的空間舊的指令欄位亦可保留日後擴充新指令之用。（這段話之前沒寫清楚...當時寫的太high了，後來連我自己也看不懂自己在寫什麼...）
但AMD SSE5完全是疊床架屋，為了解決REX，卻又創造出複雜的DREX + Opcode3結構，人家Intel都把所有重要資訊集中在前方的VEX了，一收到就馬上開工，你卻要讀取大半個指令再玩配對遊戲，然後SSE5的1/2 operand指令encoding方式簡直讓我看到髒話都快罵出來，毫無邏輯可尋，要我畫出圖解根本是一種虐待。
假如AMD堅持下去，姑且不論早在2007年八月就公開的SSE5能不能被市場接受，光就CPU端效率和耗電而言，Bulldozer核心就大概保證打不過Sandy Bridge了。
倒是AMD皈依AVX後，將XOP長度訂死在3 Bytes，也許是比較好的作法，畢竟x86指令長短粗細肥瘦不一，一直都是很令人討厭的缺點。
反正我人微言輕、才疏學淺，講再多都還是會被人當外行人耍，自己就去看後藤一年多前的文章是怎麼寫的：
x86からの脱却を図るIntelの新ロードマップ(2008/4/7)
x86 CPUの弱点が浮き彫りになったNehalemマイクロアーキテクチャ(2008/4/28)
不過話說回來，Intel要到22nm的Haswell才會有AVX的FMA體系指令，AMD該不會想搶先在Interlagos就提供吧...
3. LRBni是很優越的設計：
如果我印象沒錯，Intel到現在都還沒公開LRBni的encoding，連長的怎樣都不知道，這種「結論」大概只有看到暫存器很長、數量很多就爽起來，信奉「數大就是美」的鄉民才會有的生理反應吧。要蓋棺論定，我覺得起碼該等到LRBni-2...反正好像也沒多少人把第一代LaughabeeLarrabee當作一回事。
喔喔喔喔喔～快高潮了～
沒有留言:
張貼留言