科科們應該還記得Sun這間公司打從創業以來就很堅持「開放」路線,SPARC指令集也不是Sun的私產。本質上骨子裡是軟體公司的Sun,其號稱三千人的處理器研發團隊,卻被公認打不過Fujitsu的「三百壯士」。
隨著時間流逝,一般坊間評價「最好的SPARC指令集相容處理器」不是來自「Sun本家」,而是日本的Fujitsu (與1990年代的Ross和HAL),直到併購Sun的Oracle在2017年9月擺明不玩,一口氣裁撤了所有SPARC處理器與Solaris作業系統的964人,只剩下這間日本公司和少人知悉的俄羅斯MCST以外,別無分號為止。
指令集版本 |
發布年份 |
改進重點 |
對應處理器 |
發表年份 |
SPARC v7 |
1986 |
開天闢地 |
MB86900 |
1986 |
SPARC v8 |
1990 |
整數乘除法 128位元四倍精度浮點數格式 |
microSPARC I SuperSPARC I hyperSPARC I microSPARC II SuperSPARC II hyperSPARC II hyperSPARC III TurboSPARC hyperSPARC IV |
1992 1992 1993 1994 1994 1994 1995 1996 1996 |
SPARC v8E |
1992 |
嵌入式應用 |
在此不列 |
1992 ↓ 2019 |
SPARC v9 |
1993 |
64位元 VIS (Visual Instruction Set) 1 |
UltraSPARC I SPARC64 SPARC64 II SPARC64 III UltraSPARC IIs UltraSPARC IIi UltraSPARC IIe SPARC64 GP SPARC64 IV |
1995 1995 1996 1998 1997 1997 1999 2000 2000 |
JPS1 |
2002 |
VIS 2 |
UltraSPARC III UltraSPARC III Cu UltraSPARC IIIi SPARC64 V SPARC64 V+ |
2001 2001 2003 2003 2004 |
JPS2 |
2003 |
支援多核心處理器 |
UltraSPARC IV UltraSPARC IV+ SPARC64 VI SPARC64 VII SPARC64 VII+ |
2004 2005 2007 2008 2010 |
UA2005 |
2006 |
UltraSPARC T1的實作項目,包含: VIS 1與VIS 2和相關暫存器 切成多個層級的全域暫存器 四個特權模式指令 存取版本暫存器須特權模式 軟體重啟系統指令須特權模式 |
UltraSPARC T1 |
2005 |
UA2007 |
2007 |
UltraSPARC T2的實作項目 |
UltraSPARC T2 UltraSPARC RK SPARC T3 |
2007 被腰斬 2010 |
HPC-ACE JPS2 |
2009 |
Fujitsu自行定義的128位元SIMD運算指令集 |
SPARC64 VIIIfx SPARC64 IXfx |
2009 2012 |
HPC-ACE OSA2011 |
SPARC64 X SPARC64 X+ |
2012 2014 |
||
HPC-ACE OSA2015 |
SPARC64 XII |
2017 |
||
OSA2011 |
2012 |
VIS 3 升級虛擬機Hypervisor模式 |
SPARC T4 SPARC T5 SPARC M5 SPARC M6 |
2011 2013 2013 2013 |
HPC-ACE2 OSA2011 |
2014 |
Fujitsu自行定義的256位元SIMD運算指令集 |
SPARC64 XIfx |
2014 |
OSA2015 |
2015 |
VIS 4 硬體加密 硬體記憶體保護 |
SPARC M7 SPARC S7 |
2015 2016 |
OSA2017 |
2017 |
還有人關心嗎? |
SPARC M8 |
2017 |
「軟硬兼備」的Sun,在1980年代的工作站市場在1990年代的伺服器市場,均獲得極為重大的商業成功,這從處理器業界效能指標SPEC CPU的參考基準,即可略見一斑:SPEC CPU 95是SuperSPARC,SPEC CPU 2000是UltraSPARC I,SPEC CPU 2006則是時脈296MHz的UltraSPARC II。有別於IBM、Intel、AMD和DEC,Sun並沒有自建晶圓廠,自行研發的SPARC處理器均交由TI代工製造,被Oracle併購後則轉向台積電。
但商業上的優異成就,卻難以掩蓋其處理器研發進展逐漸「脫隊」的事實。有別於其他的曾在效能排名風光一時的眾多「RISC諸神」,如一度威鎮四方的DEC Alpha和IBM Power,Sun自己的SPARC處理器卻是打從一開始就沒有明顯的單核效能競爭力,到了2004年,UltraSPARC IV竟然還沒有非循序指令預測執行 (OOOE) 核心,落後x86陣營近十年 (x86第一顆OOOE處理器是1994年的Nx586),僅仰仗多處理器延展性與Solaris作業系統的優勢,守住高階伺服器市場,最終也不得不導入x86處理器去彌補產品線的漏洞。
在本世紀初期,「軟體色彩極度濃厚」的Sun,與「高效能傳統路線」的Fujitsu,就互通有無的組成被IBM公開嘲笑 “Sujitsu” 的APL (Advanced Product Line) 聯盟。Sun轉戰「超多簡單核心、超級多執行緒、巨量記憶體頻寬、目標鎖定網路應用」的Throughput Computing,Fujitsu SPARC64繼續專注於「較少複雜核心、優秀單執行緒效能、大型主機等級可靠度、應對高效資料處理」,再彼此截長補短,採用對方的處理器推出伺服器產品。
2008年4月20日,Oracle併購Sun,繼承了龐大的遺產。在之後原先Sun的SunFire和Fujitsu的PrimePower,再一同被兩家攜手的SPARC Enterprise品牌取代。2010年後,再統一更名成SPARC M/T (與後來追加的S)系列。
只不過,SPARC處理器的商業價值依舊奠基於Solaris作業系統之上,當Oracle停止發展Solaris之後,SPARC指令集的未來就註定烏雲罩頂。從2017年的Fujitsu SPARC64 XII和Oracle SPARC M8後,就毫無高階SPARC處理器的動靜。更何況,Fujitsu在A64FX開了「用ARM換掉SPARC」的第一槍,天知道會不會哪天Solaris + SPARC將被Linux + ARM取而代之,步上諸多RISC諸神的後塵,只剩下MCST的俄羅斯人繼續做軍用的SPARC處理器。
硬科技:Arm邁向高階伺服器最偉大的一步:Fujitsu A64FX
在計算機工業的歷史洪流,從來沒有任何一套指令集架構,能夠比歷經網際網路大爆發的SPARC,更有資格得到「繁華落盡」的稱號,相信各位歷經那段歲月的科科都懂。RISC指令集在伺服器領域的「文藝復興」能否出現在我們的眼前,就得瞧瞧ARM與RISC-V陣營的努力了。
1 則回應