“网络就是电脑”（The Network Is The Computer）这句格言，是在 1984 年，由 Sun 第 21 名员工 John Gage 创造。别说网络，在连个人电脑都尚未普及的年代，如此独树一帜的另类论点，恐怕让不少人“想问候小朋友”，但今日云端运算普及，却充分印证了 Sun 的另类观点，的确高瞻远瞩。
稍有年纪的读者，还记得 20 多年前，在电脑中心与资讯教室随处可见的 Sun Ultra 系列工作站，那高贵的 Sony 特丽霓虹映像管屏幕、听说手感还不错的键盘、戏称为“Slow-Laris”的 Solaris 操作系统与里面的心脏：UltraSPARC 处理器吗？头发绑马尾的 Jonathan Ian Schwartz 在任职 Sun 首席执行官期间，没事就在官方部落格长篇大论左批 HP 右打 IBM，更是当时资讯业界与科技媒体茶余饭后的必聊话题。
2008 年 4 月 20 日，Sun 董事会通过决议，同意将以每股 9.5 美元价格，将这间拥有 UltraSPARC 处理器、Solaris 操作系统、ZFS 档案系统、Java 程式语言、MySQL 数据库、效能分析工具 DTrace、庞大的服务器工作站产品线、无数大型企业客户、无数软硬件创新（如无人不知的 NFS 网络档案系统和大型多处理器服务器）的硅谷知名公司，出售给以数据库与 ERP 闻名于世的 Oracle。
当时坊间舆论亦不乏对此购并案的担忧，但看在“Oracle 大多数数据库产品都运行在 Solaris，且往往跑得还比 IBM AIX 还快”份上，加上 Oracle 从此晋升为“软硬兼备”的强权，足以跟 IBM 分庭抗礼，所以外界仍抱着“审慎乐观”态度。
很不幸的，继在 2017 年初全球大裁员先砍了一批人，主管旧 Sun 产品线的系统部门执行副总裁 John Fowler，8 月 2 日因不明原因离职，2017 年 9 月初，Oracle 更一口气裁撤所有 SPARC 处理器与 Solaris 操作系统的 964 人，曾在互联网萌芽时代高悬天际的昇阳，终究难逃陨落下场。
那时候网络也不缺替 Oracle“洗白”的言论，像“产品时程表还有‘SPARC.Next’和‘Solaris.Next’这些未来产品”、“Fujitsu 还是会继续推出新 SPARC64 处理器”、“Solaris 11.5 还是会在 2019 年准时发表”，连“Solaris 的技术支援时限直到 2034 年”这种借口都讲得出口。然后随着时间流逝，Solaris 11.4 已是将近两年前的往事，Solaris 12 则看来永远不会出现。曾几何时，这誉为“最普及的商用 RISC 处理器与 Unix 操作系统”无以为继，让人不胜唏嘘。
Oracle 之所以购并 Sun，以事后诸葛的角度，看似无心永续发展技术与价值，反而更像利用 Sun 多年累积的庞大专利权和商标权，让公司法务部门到处兴讼，狂找其他公司“讨债”，例如控告 Google 在 Android 手机使用 Java API 索赔 90 亿美元，结果败诉踢到大铁板。原本今年 3 月 Google 和 Oracle 要在美国最高法院大决战，因武汉肺炎（新冠肺炎，COVID-19）影响，继续歹戏拖棚。
法国漫画家 Manu 曾在 2010 年，画了好几张“奇葩组织图”一次调侃苹果、Google、Oracle、微软、Facebook、亚马逊这 6 家超级公司，Oracle 这张似乎冥冥之中预言了 Sun 的命运。
（Source：Manu Cornet / CC BY-SA）
“相对开放才有出路”的年代
成立于 1982 年 2 月、全名源自“Stanford University Network”（史丹佛大学网络）的 Sun Microsystems，因 3 位创办人都是史丹佛大学研究生，从诞生到往生，一直保有浓浓的学术味。十几年前，Sun 尚未被 Oracle 购并时，曾有 Sun 高阶主管当面对笔者这样形容他们的企业文化：这间公司感觉就很像大学。
从 21 世纪开始，“开源软件”和“开放系统”成为不可质疑的政治正确，你不使用“日用品”等级的 x86 指令集相容处理器或开源操作系统，就是“不够开放”，而 1980 年代以雨后春笋之势蓬勃发展的 Unix 操作系统与他们的 RISC 服务器平台，就纷纷被贴上“昂贵封闭”标签。但讽刺的是，所谓的“开放”到头来也只是相对概念，Sun 能从工作站市场发迹，就是因为“比较放得开”。
这里不得不先提那时的工作站（Workstation）市场。成立于 1980 年的 Apollo Computer（容易让人误认为阿波罗登月计划的导航电脑）是这领域的先驱者，而工作站其实就是比较高阶的通用微型电脑，特别是远优于一般个人电脑的图形处理能力，而电脑辅助设计（Computer Aided Design，CAD）就刚好是最适当的需求。知道 Autodesk 这间公司在做什么的，应该清楚这种应用的大致样貌。
Apollo Computer 最大的客户，也不外乎像电子辅助设计工具业者（Mentor，现今 EDA 工具三大巨头之一，仅次于 Cadence 与 Synopsys，在 2017 年被德国西门子以 45 亿美元现金收购）、汽车业（通用汽车、福特、克莱斯勒）和航空业（波音）等。
即使 Apollo Computer 初代产品 DN100 工作站采用的处理器，是普及到不能再普及的 Motorola 68000，但仍难摆脱 1970 年代的“遗风”，软硬件规格都具强烈封闭性，除了专属硬件规格，连操作系统也是仅提供类似 Unix 操作指令的 Aegis / Domain。不过 Sun 就完全相反，一开始就选择“开放”，不生产客制化硬件，不同工作站都使用统一 Unix 操作系统，再授权给不同公司制造产品。
凭著标准化软硬件，让 Sun 更容易打造价格更低的产品，快速进入市场。短短几年，Apollo Computer 很快就被 Sun 和 DEC 超车，失去工作站市场的龙头地位。1987 年推出的 Sun-4 首度成为采用 SPARC 指令集相容处理器的工作站，当年 Sun 也跃升为工作站市场老大，从 1985 年到 1989 年，年复合成长率是美国企业最高的 145%。Apollo Computer 则在 1989 年被 HP 以 4 亿 7,600 万美元（相当于 2019 年的 9 亿 8,200 万美元）代价购并，慢慢转形成 HP 高效能运算产品线品牌之一。
当然，也可以自行解释成“学生创业就是这样，像什么有名大站和电玩小站，还不是起源于放在学生宿舍或研究室、脚边随时都会不小心踢到而挂站的 DIY 电脑”。Sun 创办人之一 Andy Bechtolsheim 设计的 Sun-1 工作站，第一批的部分料件还是从史丹佛电脑科学系弄来的，你不“开放一点”根本没有其他出路。但如果再回味一次某些资讯业界创业名人的历史，或多或少会感觉到，所谓的“学生英雄”似乎有那么一点令人熟悉的相似性。
名列商用 RISC 处理器始祖精灵之一的 SPARC
这种起源于学校的开放思想背景，自然也影响了 Sun 自行研发的 RISC 指令集处理器。Sun 在 1984 年开始进行 SPARC（Scalable Processor Architecture，可扩展式处理器架构）指令集研究，开发顾问则是大名鼎鼎的 David Patterson，只要正统资讯科班出身，不可能不知道这位两本必读电脑组织结构的作者、RISC 之名的创造者、RISC-V 的发起者。
SPARC 深受早期 RISC“精简”思潮熏陶，希望所有运算动作都可单时脉周期搞定并高度管线化，像整数除法除法之类的“复杂”指令就付之阙如，透过重复的简单运算取代之，这部分到了 1990 年的 SPARC v8 才补完。
Sun 在 1986 年发表 32 位元的 SPARC v7 指令集，但 Sun 并不像其他厂商自己做芯片，而是开放出来并定义严谨版本，让其他厂商也能研制 SPARC 指令集的相容处理器，1987 年问世的 Sun-4 系列工作站，处理器来源是日本 Fujitsu 与 Cypress（分别搭配来自 Weitek 和 TI 的浮点辅助运算器）；世界首颗实做出来的 SPARC 指令集相容处理器，也并非出自于 Sun，而是 1986 年的 Fujitsu MB86900。
1995 年 SPARC v9 扩充到 64 位元与 SIMD 指令集 VIS（Visual Instruction Set），Sun 跟 Fujitsu 在 2002 年联合提出 JPS（Joint Programming Specification）规范并持续演进到 UA（UltraSPARC Architecture）、OSA（Oracle SPARC Architecture）和 Fujitsu 自行定义的高效能运算 HPC-ACE（High Performance Computing – Arithmetic Computational Extensions）。
不限指令集架构，SPARC 也出现开放 VHDL 语言源代码的 LEON 处理器系列（使用针对嵌入式应用而生的 SPARC v8E 指令集），采用 LGPL 授权，并由非营利 SPARC International 组织负责管理。Sun 日后也陆续开源 UltraSPARC T1 与 T2，成为 OpenSPARC T1、S1（单核心的 T1）和 OpenSPARC T2，让更多人发出“啊，原来某种处理器技术的实做细节是长这样，教科书和技术文件根本不会教你怎么下手”的感慨。
总之，有别于 80×86 世界多年来迟迟缺乏公定版本的乱象，关于电脑最基础“语言”的指令集架构，SPARC 一直都有统一标准。也因此，SPARC 指令集相容处理器的发展史，踏满了众多厂商的足迹，让历代 SPARC 处理器的型号总数，海放同时期的 IBM Power（不算 PowerPC）、DEC Alpha、HP PA-RISC 及 MIPS（如果只算高阶处理器的话）等老对手。但这也让公认当代最强大的 SPARC 指令集相容处理器，并非出自创造 SPARC 的 Sun，而是日本 Fujitsu。
如果还记得现在 x86 指令集相容处理器的战场，扣掉英特尔、AMD 双雄加上台湾 VIA 的 Centaur，还有一间俄罗斯 Elbrus，所属的 MCST 公司全名就叫“Moscow Center for SPARC Technologies”（莫斯科 SPARC 技术中心），持续研制一系列应用在俄系军事武器的 SPARC 处理器。
然后网络也随处可见将“指令集架构”与“处理器微架构”混为一谈的高论，讲得好像 Fujitsu、Cypress 和 TI（德州仪器）这些公司“授权生产 Sun 设计的 SPARC 处理器”，但根本就不是这么一回事。如同英特尔和 AMD 在 x86 指令集相容处理器的地位，Sun 和 Fujitsu 身为高效能 SPARC 指令集相容处理器的两大要角，两边的处理器微架构方向根本大相径庭，一边冲多核心多执行绪，另一边则是把 RISC 处理器当成大型主机来做，不会有人敢说技术源流来自 HAL 和 Ross 的 Fujitsu SPARC64 系列，是 Sun 授权的“设计”。
SPARC 历代指令集版本文件封面那句大大的“One Architecture……Multiple Innovative Implementations”（统一的指令集架构，多种创新的微架构实作），就是最佳写照，只是傻傻分不清楚的人还是继续看不懂。
源自“暂存器框格”的可延展性
SPARC 指令集里那个“可延展”（Scalable），起因于独特的“暂存器框格”（Register Window），亦可见于 Berkeley RISC、AMD Am29000、英特尔 i960 与 Itanium，即使名称可能有点不同。
当处理器碰到中断（如外部 I/O 呼叫）、例外（像算术溢位）、行程切换（多工应用环境），须将当前的执行状态，包含所有可存取的暂存器，都以事先定义好的资料结构回存到内存，如 x86 指令集的 TSS（Task Status Segment），当恢复先前状态，再从内存载回处理器。
因近代程式架构都高度模组化，不同副程式间的呼叫动作（Subroutine Call），也会造成频繁的内文交换（Context Switch，亦可称为“程序切换”或“上下文交换”），增加暂存器和内存间的资料传输量。过于庞大的“可见”暂存器档案，也会增加处理器的电路复杂度与内文交换的负担，并伤害提升处理器运作时脉的延展性。
那该如何降低内文交换的负担，减少多余的内容值交换？以“空间换取时间”的“暂存器转转乐”Register Window 为此而生。ARM 指令集的 Banked Register 也是类似方法。英特尔 Itanium 处理器的 IA-64 指令集也具备相同的机制，但命名为 Register Stack，看似比较贴切。
Register Window 借由“重叠”不同程序使用的暂存器，即可交换不同程序的资料，但“软件眼中随时可见”的暂存器数量仍为 32 个，8 个全域（Global），剩下 24 个当作 Register Window，8 个输入（In）、8 个区域（Local）、8 个输出（Out），逻辑上可视为一个巨大堆叠，Register Window 指标器（CWP）一次移动 16 个暂存器的距离，前一个程序的输出变成下一个程序的输入，当程序切换时，无须将专属于特定程序的 8 个区域暂存器搬到内存，也减少了暂存器和内存之间的资料搬移量。
以下举一个 3 个 Register Window 案例，一看就懂。
因此 SPARC 指令集相容处理器的“实际”通用暂存器数量是可变的，从力求最低成本的嵌入式应用到重视多工效率的服务器，一般介于 72~640。假如想要追求副程式互通有无的效率，也愿意付出较多硬件成本（像 8 个 Register Window 的 UltraSPARC I，144 个暂存器拥有多达 7 个读取埠和 3 个写入埠），Register Window 数量就多多益善，但假若想要减少电路成本、又想缩短发生内文交换的处理负担，那就少一点刚刚好。SPARC 名中的“可延展”之意即在此，和日后为人称道的“多处理器延展性”一点关系都没有。
效能最好的 SPARC 处理器并非出自 Sun
由于本文主角是 Sun，后面将聚焦服务器与工作站处理器。但随着时间流逝，一般坊间评价“最好的 SPARC 指令集相容处理器”却不是来自“Sun 本家”，而是日本 Fujitsu（与 1990 年代的 Ross 和 HAL），直到 Oracle 摆明不玩、只剩下这间日本公司，别无分号为止。
先从指令集版本的演进，用一个表格画出 SPARC 发展史的大致轮廓，至于型号相同、制程不同的微缩版就在此不论（UltraSPARC 历代出现过大量的制程改进版本）。如前面所述，Sun 让 SPARC 指令集成为“充分开放的业界标准”，除了 Fujitsu 为了高效能运算而自定义的 HPC-ACE，理论上所有 SPARC 处理器，皆可相容先前所有 SPARC 指令集。
但在踏入主要 SPARC 处理器历史前，笔者必须先厘清 Sun 和其他 SPARC 处理器厂商的最大思想差异，这也是“软件色彩极度浓厚”的 Sun，与“高效能处理器传统路线”的 Fujitsu（与族繁不及备载的众多处理器厂商）最大的不同点。
对于 21 世纪初期略闻 SPARC 处理器的读者，应经历过 Sun 与 Fujitsu 两家组成 APL（Advanced Product Line）联盟的历史。Sun 的处理器时程表上演大风吹，取消双核心 UltraSPARC II“Gemini”及 UltraSPARC V“Millennium”，转战“超多简单核心、超级多执行绪、巨量内存带宽、目标锁定网络应用”的 Throughput Computing，Fujitsu SPARC64 继续专注“较少复杂核心、优秀单执行绪效能、大型主机等级可靠度、应对高效资料处理”，再彼此截长补短，采用对方的处理器推出服务器产品。
当时还被 IBM 公开嘲讽 APL 应改名为“Sujitsu”，这些年来，IBM 对 SPARC 阵营的嘴炮攻势，更是从来没有停过。反正客户永远不嫌多，能挖来一个算一个。
那时刚好英特尔积极推动 Itanium 取代 RISC 处理器、x86 处理器挟著 64 位元这个新兵器在服务器市场四处攻城掠地（AMD 靠着 Opteron 在此崛起）、IBM 的 Power 正展现无穷威力，坊间看法多半是“Sun 本来就不擅长研发高效能处理器，加上先进半导体制程与产品研发的成本持续水涨船高，已无力维持高效能处理器的竞争优势，不得不改弦易辙，另辟出路”，像 UltraSPARC 发展到第四代的 2004 年，依旧缺乏非循序指令预测执行能力，远远落后其他厂商，效能不如对手的事实，也充分展现于 SPEC CPU 等效能测试标竿的平庸表现。
但假若回顾 Sun 这间公司的历史──尤其身为 Java 创造者的身份，以及长年研究高效能 Java 处理器（像对 SPARC 处理器发展影响深远的 MAJC，这以后会有专文介绍）的经验──他们“似乎”从来就不认同近代高效能处理器的诸多重大特色，如高度指令平行化、大型化多层快取内存、动态分支预测、非循序指令预测执行等，执行 Java 这种虚拟机化物件导向程式语言时，能发挥多少实际效用。至于“地球最先进的服务器操作系统”Solaris 的优异多执行绪排程能力，更是 Sun“胆敢”采取激进策略的信心来源。
换言之，Sun 更偏向以软件角度，如 Java 程式语言与 Solaris 操作系统为出发点，思考最合理的处理器架构，结论就不外乎强化多执行绪和内存子系统效能。如果说以 UltraSPARC T1 为起点的 Throuhgput Computing 是“山不转路转”，还不如说是“发扬光大”，甚至“走火入魔”亦不为过。
从遥遥领先到苦苦追赶的历程
软硬兼备的 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 购并后转向台积电。
但商业优异成就，却难以掩盖处理器研发进展逐渐脱队的事实。如果和同期 x86 处理器（与诸多 RISC 老相好）相比，Sun 的高阶 SPARC 处理器发展史，可谓一部从“遥遥领先”到“苦苦追赶”的赛道纪录。各位可好好唤醒尘封已久的回忆，回想一下那一年 x86 处理器有哪些让你印象深刻的产品。
1992 年的 SuperSPARC（0.8μm 制程，时脉 33~60MHz）：那时英特尔 Pentium 尚未上市。
1994 年的 SuperSPARC II（0.8μm 制程，时脉 75~90MHz）：那年已经出现 100MHz 英特尔 Pentium。
1995 年的 UltraSPARC I（0.47μm 制程，时脉 143~167MHz）：英特尔推出 x86 历史首次正面挑战服务器市场的 Pentium Pro，时脉直扑 200MHz，并具备原生四处理器架构与非循序预测指令执行。
当然，对那段往事稍有印象的人，也许会这样指摘：人家 UltraSPARC 可是货真价实的 64 位元处理器（相较 Pentium Pro 看起来很没诚意的 PAE-36），又有 VIS 指令集和更强的多处理器延展性（像 Enterprise 6500 服务器就塞了 30 颗 UltraSPARC I，Ultra 4000 工作站也有 14 颗），但请稍安勿躁，让我们继续慢慢看下去。
1997 年的 UltraSPARC II（0.35μm 制程，时脉 250MHz）：英特尔推出 300MHz 的 Pentium II，而 UltraSPARC II 的微架构基本沿用 UltraSPARC I。
1997 年的 UltraSPARC IIi（0.35μm 制程，时脉 270~360MHz）：整合 PCI 控制器的微幅改进版，从 256kB 激增到 2MB 的 L2 快取内存是最大的亮点。
1998 年的 UltraSPARC IIi（0.25μm 制程，时脉 333~480MHz）：当年 6 月时脉 400MHz 的首款英特尔 Xeon 问世，x86 世界总算有了服务器处理器专用的品牌。
2000 年的 UltraSPARC IIe（0.25μm 制程，时脉 400~500MHz）：AMD 抢先在英特尔之前登顶 1GHz 大关。
2001 年的 UltraSPARC III（0.18μm 制程，时脉 600MHz）：0.18μm 制程的英特尔 Pentum 4 / Xeon 时脉抵达 2GHz。同年发表的 UltraSPARC III Cu，终于靠着 0.13μm 制程和铜导线，冲破了 1GHz，真是可喜可贺。
反观同时期英特尔（P5→P6→P68）和 AMD（K5→K6→K7）的飞跃性演进，UltraSPARC III 在微架构层面的改进幅度并不明显，维持每个时脉周期撷取解码 4 道指令，仍然没有非循序指令预测执行，仅略为扩增处理器内派发指令的宽度与管线深度与追加 VIS 2 指令集。整合内存控制器是最实际的改善点，如同 AMD 的 K8 方法，大幅强化内存带宽并缩减存取延迟。
但即使上市日期整整延宕 2 年，原先设定要对抗 DEC Alpha 21264 和英特尔 Itanium 的 UltraSPARC III 依然“借由优秀的多处理器延展性”获得那年 Microprocessor Report 的最佳服务器／工作站奖项，隔年则轮到原生双核心的 IBM Power4。
另外，取代 Sun Enterprise 的 Sun Fire 服务器产品线，也一起和 UltraSPARC III 登场。Sun Fire 最令人称道之处，莫过于美观又易维护的优异机构设计，理念皆出自于“Sun 天字第一号员工”Andreas Bechtolsheim 之手，其 x86 服务器亦雨露均霑，有接触过 Galaxy 系列 AMD Opteron 产品线（以 Sun Fire X4100 / X4200 为开端）的人，多半都印象深刻。
之后 Sun Fire 和 Fujitsu 的 PrimePower，再一同被 Sun / Fujitsu 携手的 SPARC Enterprise 品牌取代，2010 年后，再统一更名成 SPARC M / T（与后来追加的S）系列。
Sun Fire 也是 UltraSPARC 处理器在高阶服务器的巅峰，Sun Fire 15K 最多支援 106 颗 UltraSPARC III Cu，而 Sun Fire E25K 更是 72 颗 UltraSPARC IV（144 核心）。
2002 年的 UltraSPARC IIe+（0.18μm 制程，时脉 550~650MHz）：0.13μm 制程的英特尔 Pentium 4 / Xeon 已达 3GHz。你没看错，到了这时候，UltraSPARC II 还活着。
2003 年的 UltraSPARC IIIi（0.13μm 制程，时脉 1~1.6GHz）：这年 AMD K8 让 x86 的世界深入 64 位元疆界，Opteron 处理器品牌也从此改变了 AMD 与 Sun 的命运。
2004 年的 UltraSPARC IV（0.13μm 制程，时脉 1~1.3GHz）：UltraSPARC 处理器挤身双核心之列（等于 2 颗改良版 UltraSPARC III），但已经看不到 IBM 的车尾灯，那年刚好是 IBM Power5 在高阶服务器市场的效能战争横扫千军的高峰。
2004 年，Sun 宣布腰斩 UltraSPARC V“Millennium”和双核心 UltraSPARC II“Gemini”，但已不值一提。
2005 年的 UltraSPARC IV+（0.09μm 制程，时脉 1.5~2.1GHz）：“传统”UltraSPARC 处理器的绝响，这时双核心 64 位元英特尔 Xeon 和 AMD Opteron 已在服务器市场杀声震天，再次确立 x86 处理器主导服务器市场和云端资料中心的大势。
爬文至此，各位恐怕不难想见 Sun 在 21 世纪初期被“看衰小”的程度，也难怪会成为英特尔推动 Itanium 取代“封闭 RISC 系统”大战略，第一个锁定“挖墙角”的对象。在 2005 年，英特尔扶植的 Itanium 解决方案联盟，启动 ISV Platform Expansion Program，透过 Transitive 的 QuickTransit 二进制执行档转换技术，鼓励既有使用 SPARC 处理器／Solaris 操作系统的用户，转移至 Itanium 平台。
更糟糕的还在后头：SPARC 处理器阵营的另一位要角 Fujitsu，不但在 2005 年 4 月发表 Itanium 服务器 PrimeQuest 产品线，还是采用自研系统芯片组、最大 32 处理器 64 核心的巨兽，秋季 IDF（Intel Developer Forum）的 Itanium 解决方案联盟发表会，资深行销副总裁 Richard McCormack 更是第一位上台开场致词的来宾，刚好满脸黑线的笔者有幸坐在台下躬逢其盛。
理所当然的，英特尔势必对 Fujitsu 施以重金、诱之以利，大概又是什么行销赞助基金之类的。每当笔者多次在公开场合碰到 Fujitsu 相关人士，偷偷打探英特尔到底付了多少“补助津贴”，总是得到尴尬又不失礼貌的营业式微笑。随着 AMD“逼出英特尔研发 x86 处理器的巨大潜能”而造就 Itanium 边缘化，PrimeQuest 也跟 HP 的旗舰 SuperDome 一样，“转进”到 Xeon 处理器，沉没的 Itanic 号观光邮轮，就再也没有浮出水面。
迈向 Throughput Computing
Sun 在 2004 年逐步重整服务器产品布局，除了短暂推出英特尔 Xeon 处理器的 Sun Fire V60 系列，兵分三路，成果可简述成以下数点：
- 泛用型服务器：Sun 成为率先压宝 AMD Opteron 的一线服务器大厂，并推出“Galaxy”系列服务器，8 颗 Opteron 的 Sun Fire M4600 为象征。这件事对 AMD 也意义深远，不仅提升 AMD 验证产品的能力，更强化企业用户对“AMD 服务器”的信心。
- 高效能服务器：与 Fujitsu 携手 APL（Advanced Product Line），沿用 SPARC64 系列，标榜大型主机等级的可靠性。
- 网站与数据库：Sun 购并 Afara Websystems 后，以追求“像瀑布般的巨大资料吞吐量”的 Throughput Computing 为名，集中资源打造针对网站服务器特化的 UltraSPARC T 系列（Niagara）与数据库导向的 UltraSPARC RK（Rock）。
其中最值得大书特书的就是奠定 Sun SPARC 处理器发展方向的 Throughput Computing：简单多核心、超多执行绪、大量内存带宽。
2005 年的 UltraSPARC T1（0.09μm 制程，时脉 1~1.4GHz）：8 个简单微架构核心（单指令派发）、32 粗质执行绪（碰到内存存取等较长延迟，才会切换执行绪）。
台湾最大的电玩资讯站巴哈姆特，曾测试 Sun Fire T2000 足足一周，一台取代所有前端网站服务器群，瞬间涌入 500 名使用者的系统反应时间，从 8 秒缩短到 0.3 秒，足以见证威力。但 UltraSPARC T1 只有一个浮点运算器，不难想见针对网站服务器“最佳化”的程度。
2007 年的 UltraSPARC T2（65 奈米制程，时脉 1~1.6GHz）：前者的强化版，执行绪倍增至 64 条，每个核心都拥有独立的浮点运算器，因此整数运算加倍，浮点运算提升时倍，更高时脉带来 1.4 倍的单执行绪效能。后继的 UltraSPARC T2+ 则是追加 4 处理器延展性的版本。
2010 年取消的 UltraSPARC RK，就是让人感到极度惋惜的未竟之憾了，16 个 4 指令派发的非循序预测执行核心（Sun 的历史创举），每个核心 2 条同时多执行绪（SMT），总计切成 4 块共享 1 个 32kB 指令快取、2 个 32kB 资料快取、2 个浮点运算器的丛集（Cluster），耗电量高达 250W，也具备了更精细多执行绪内存资料同步的 Transactional Memory（近似英特尔 TSX）。
Sun 曾在 UltraSPARC RK 砸了不少预算，也持续“堆高”规格，导致芯片开发到 2.0 版。或许失控的功耗和经费，就是新东家 Oracle 决定腰斩的主因。Oracle 接手 Sun 后，“Software In Silicon”也成为最常喊的口号。
虽然无缘见证 UltraSPARC RK 的实际威力，但 Oracle 购并 Sun 之后的 SPARC T 系列，却处处可见 Rock 的残影，并同时融合 Niagara 的色彩。像 2011 年的 SPARC T4，就是 8 个双指令派发、非循序预测执行的 S3 核心（代表第三代 SPARC 核心，并追加 VIS 3 指令集），每个核心 8 条同时多执行绪的产物，一路“核心堆堆乐”到 12 核 96 执行绪的 SPARC M6。
SPARC M7 升级成具改良后的快取内存阶层和 VIS 4 指令集的 S4 核心，演进到 2017 年的 32 核心 256 执行绪的 SPARC M8。
- 2010 年的 SPARC T3：40 奈米制程，时脉 1.65GHz，16 核 128 执行绪，可视为 UltraSPARC T2 的加倍版，然后 SPARC Enterprise 服务器品牌也取消，统一称为 SPARC T 系列。
- 2011 年的 SPARC T4：40 奈米制程，时脉 2.85~3GHz，8 核 64 执行绪。
- 2013 年的 SPARC T5：28 奈米制程，时脉 3.6GHz，16 核 128 执行绪。
- 2013 年的 SPARC M5：28 奈米制程，时脉 3.6GHz，6 核 48 执行绪。
- 2013 年的 SPARC M6：28 奈米制程，时脉 3.6GHz，12 核 96 执行绪。
- 2015 年的 SPARC M7：20 奈米制程，时脉 4.133GHz，32 核 256 执行绪，S4 核心。
- 2016 年的 SPARC S7：20 奈米制程，时脉 4.27GHz，8 核 64 执行绪，SPARC M7 的低价微缩版。
- 2017 年的 SPARC M8：20 奈米制程，时脉 5GHz，32 核 256 执行绪，一颗怪物级的大芯片。
下面呢？下面就没有了。
顺道一提，Sun 体系的 SPARC 处理器，从 40 奈米制程的 SPARC T3 开始，转由台积电生产，结束了 Sun 与 TI 的长期合作关系。
按部就班、稳扎稳打的 Fujitsu SPARC64
既然 Oracle 已确定中断 Sun SPARC 处理器的技术血脉，在 1986 年打造出世界第一颗 SPARC 指令集相容处理器 MB86900 的日本 Fujitsu，就成为唯一硕果仅存的高阶 SPARC 处理器供应商。相对于“激进敢冲”的 Sun，Fujitsu 可谓“传统保守”，或许更精确一点，他们的诉求是把 RISC 处理器，做成与大型主机一样“高、上、大”。
但打从一开始仅专注嵌入式应用的 Fujitsu，高效能 SPARC 微架构也并非从头做起，技术源流可追溯至以 hyperSPARC 跟 Sun 正面竞争的 Ross（Cyress 的子公司，后来被 Fujitsu 取得技术与专利）和 Fujitsu 投资的 HAL（由 IBM Power 的主要设计者 Andrew Heller 所创立，有趣的是，HAL 的 3 个字母，下一个就是 IBM）。
SPARC64 之名继承自 HAL，而在 2001 年取消 HAL 原案、基于 Fujitsu GS8900 大型主机而重新开发的 SPARC64 V，则是 Fujitsu 在高阶 SPARC 处理器的最重要里程碑：四指令派发、非循序指令预测执行、大型主机等级的高可靠度，效能也明显优于 Sun UltraSPARC III。
值得一提的是，出自 HAL 的初版 SPARC64 V 是个指令平行化极宽（远高于 4 道指令）并具备和英特尔 NetBurst 微架构大同小异的 Trace Cache（依照分支预测的结果，依序存放解码的指令执行序列），不幸与 Sun 的 UltraSPARC RK 一起变成消逝在历史洪流的遗憾。
SPARC64 V 的后继发展如下：
- 2004 年的 SPARC64 V+：90 奈米制程，时脉 1.65~2.16GHz。
- 2007 年的 SPARC64 VI：90 奈米制程，时脉 2.15~2.4GHz，双核心，导入粗质多执行绪（CMT，Fujitsu 称为 VMT），也是首款引进浮点乘积和指令的 SPARC 处理器。
- 2008 年的 SPARC64 VII：65 奈米制程，时脉 2.4~2.75GHz，四核心，导入同时多执行绪（SMT），强化资料可靠性（整数暂存器资料透过 ECC 保护，错误检查点增加到 3,400 个）。
- 2009 年的 SPARC64 VIIIfx：45 奈米制程，时脉 2GHz，8 核心，为了“京”（K）超级电脑计划而生的高效能运算衍生款，追加 Fujitsu 自行定义的 HPC-ACE 指令集与 256 个浮点运算暂存器。
因为 SPARC v9 指令集的编码位元，不足以定址所有的浮点暂存器，256 个暂存器需要 8 位元，浮点乘积和（FMA，A×B＋C＝D）指令会用到 4 个暂存器，将会吃光 32 位元编码，连运算码都没地方放了，须在运算指令前，排入“补充”暂存器定址位元数的前置指令（SXAR）。
- 2010 年的 SPARC64 VII+：65 奈米制程，时脉提升到 3GHz，L2 快取加倍到 12MB。
- 2011 年的 SPARC64 IXfx：40 奈米制程，时脉 1.85GHz，16 核心，配合 PRIMEHPC FX10 超级电脑而同步发表。总之，只要看到名称内有那个小写的 fx 就知道这是超级电脑特规版了。
- 2012 年的 SPARC64 X：28 奈米制程，时脉 2.8GHz，16 核心 32 执行绪，耗电量冲上 270W，内存控制器也“搬家”到处理器内部了。
- 2013 年的 SPARC64 X+：28 奈米制程，时脉 3.2~3.7GHz，16 核心 32 执行绪，激增的时脉也充分反应在高达 392W 的耗电量。
2014 年的 SPARC64 XIfx：台积电 20 奈米制程，时脉 2.2GHz，34 核心（32 个运算加 2 个辅助），新增 HPC-ACE2 指令集。高度整合内存控制器与总线界面的 SPARC64 XIfx 堪称 SPARC 世界第一颗超级电脑系统单芯片。
近期夺下 Top500 首位的日本理化学研究所超级电脑“富岳”，心脏 Fujitsu A64FX，实际上就是将指令集架构，从 SPARC v9 和 HPC-ACE2，替换成 ARM v8.2A 加 SVE 的进化版。
- 2017 年的 SPARC64 XII：台积电 20 奈米制程，时脉 4.25~4.35GHz，12 核心 96 执行绪（一个核心 8 执行绪，和 IBM Power9 一样）。
目前据闻 Fujitsu 可能将在 2020 年（也没剩几个月了）发表新一代 SPARC64，就让我们拭目以待，但也只能祈祷这不会是高阶 SPARC 处理器的绝响。
SPARC 还有未来吗？
这是没人敢打包票的大哉问，特别当 Fujitsu 在 A64FX 开了“用 ARM 换掉 SPARC”的第一枪，先不提软件解决方案从哪里来，哪天想不开如法泡制，做出一颗货真价实的高阶服务器 ARM 芯片，好像也不是太让人感到奇怪的事，加上 ARM 服务器最近好像声势又有点起色，多少会让人怀疑“会不会哪天 Solaris＋SPARC 将被 Linux＋ARM 取而代之”，步上 OpenVMS＋Alpha（DEC）、Irix＋MIPS（SGI）和 HP-UX＋PA-RISC（HP）一个一个淡出舞台的后尘。
平心而论，毕竟现有使用 SPARC 服务器和 Solaris 操作系统的客户还是这么多（应该吧？），Oracle 也不可能不管商誉而弃之不顾，短期应该不必担心“断粮”（不是说好 Solaris 的技术支援要维持到 2034 年吗？）。但正如 x86 指令集的最重要价值，彻头彻尾建立在“微软 Windows 相容性”上，SPARC 指令集赖以维生的 Solaris 操作系统，假以时日，“老兵不死，只是逐渐凋零”仍是极有可能成真的现实。
回顾 SPARC 指令集相容处理器 30 年来大起大落，总让笔者脑中回荡著已故香港歌手罗文的台视八点档《八月桂花香》主题曲〈尘缘〉，歌词那句“繁华落尽，一身憔悴在风里”，相信曾陪伴那票 Sun 服务器工作站的读者，心中多少也有类似感触。昔日任何 RISC 处理器家族无不像 SPARC，在工作站和服务器，曾独享极盛一时的繁华。
对亲身体验过那段互联网大爆发年代的年长读者，再多千言万语，亦诉不尽 Sun 这间神奇的公司，带给各位的点点滴滴。往事历历在目，至少还记得电脑教室快要冻死人的冷气。
但往好处想，最起码当下 SPARC 还活得好好的，总比 Alpha、PA-RISC 和 Itanium 幸运太多太多了。不过在遥远的将来，不会只剩下 MCST 那票俄罗斯人在做军用 SPARC 处理器吧？
（首图来源：pixabay）
