当 IBM 用 5000 人年苦战 OS/360 时，Burroughs 走向了另一条路

B5000 把高级语言做进芯片并实现了商用虚拟内存，却撞上了“没有被漆成蓝色”的现实

1964 年 IBM 宣布推出 System/360 时，确立了统治随后半个世纪的统一指令集标准。但在软件层，为了让一套操作系统驱动全系列的机器，IBM 吞下了长达两年的延期和 5000 人年的代价。

在这场延期背后，核心矛盾出在硬件上：System/360 的体系结构只提供通用的寄存器和平坦的物理内存，硬件本身没有虚拟内存机制。入门款 Model 30 的起步内存只有 8 KB，而高端机型配备了上百 KB 内存；为了让同一套软件在完全不同的内存尺寸下跑起来，多道程序调度、内存覆盖（Overlays）与防止任务相互踩踏的所有复杂度，全部压在了操作系统软件上。

IBM System/360 Model 30. Photo by Dave Ross, CC BY 2.0, via Wikimedia Commons.

在当时的计算机界，这被视为制造大型机的唯一办法。

但早在 System/360 宣布的三年前，另一家计算设备厂商 Burroughs 就拿出过一套截然不同的架构：B5000。

1961 年 2 月，Burroughs 宣布推出大型机 B5000。核心设计者 Robert S. Barton 和产品规划团队换了一个思路：既然操作系统最沉重的负担是维护寄存器分配、调度内存与隔离任务，为什么不让硬件在底层直接承担这些机制？

他们首先取消了通用寄存器。传统体系结构需要依靠编译器或程序员精打细算把变量塞进十几个寄存器，B5000 则直接做成了硬件栈机器。算术表达式天然对应逆波兰记法，运算在栈顶完成；函数调用与局部变量也由硬件栈自动入栈、出栈。

更关键的是内存。B5000 取消了平坦物理地址访问，引入了描述符（Descriptor）与分段机制。程序代码和数据被切成不同长度的段，程序只能通过硬件描述符进行间接寻址。描述符记录着基址、长度、控制位以及一个关键的在位标记（presence bit）。

当程序试图访问超出数组边界的元素时，硬件会在指令执行的瞬间拦截。如果引用的数据段还在外部磁鼓上，硬件会自动触发缺页中断，由系统将数据调入内存并更新描述符，程序即可无缝恢复运行。

这是计算机史上最早投入商用的虚拟内存系统之一。

因为底层硬件接管了调用栈维护、越界检查与按需换页，操作系统的设计完全变了。

在 IBM 那边，因为硬件缺乏地址转换机制，OS/360 必须靠极其庞大复杂的纯软件控制块和人工覆盖区去管理内存与任务队列，系统代码急剧膨胀；而在 Burroughs 这边，操作系统 Master Control Program（MCP）甚至不需要上千人的大团队。

当时 Burroughs 科学系统开发经理 Lloyd Turner 团队原本负责 ALGOL 编译器。他们花了三周时间，把现有编译器的存储分配机制剥离，改造成了一门专门用于编写操作系统的语言 ESPOL。随后，Turner 与 Dahm 等少数几位工程师，直接用高级语言写出了整套 MCP。

这套系统能够全自动完成多道程序并发调度、虚拟内存的换入换出与异步 I/O，交付时的核心代码体积仅约 11,000 个字。Barton 后来回忆，参与重写核心操作系统的人“平均大概只有五个”。

1965 年 1 月，这套系统在 NASA 现场安装并投入运行。

但技术上的超前，并没有换来商业上的胜利。

根据当时 ALGOL 组成员 Richard Waychoff 的回忆，B5000 的盈亏平衡点是 35 台，但实际销量并不理想：第一年卖出 17 台，第二年 15 台，第三年仅卖出 1 台，累计出厂仅约 30 到 40 台。哪怕后来加上外挂磁盘、推出了改进机型 B5500，到 1970 年停产时也只造了约 220 台。与同期 IBM System/360 席卷全球、数以千计的交付规模相比，这只是九牛一毛。

Burroughs nameplate on a cabinet at the Computer History Museum. Photo by Marcin Wichary, CC BY 2.0, via Wikimedia Commons.

为什么一套架构上领先十余年的机器卖不动？

最直接的阻力来自语言生态。Burroughs 团队坚信 ALGOL 是未来，早期坚决不采用 IBM 主导的 FORTRAN。销售人员 Pearson 后来回忆，没有 FORTRAN 是最致命的问题，客户最常见的反应是：“我手里有投入了 500 万美元写好的 FORTRAN 程序，我拿它们怎么办？”Turner 后来也坦承：“如果我们当年问了客户，客户会说：见鬼，给我们 FORTRAN。”

其次是概念过于超前所引起的心理排斥。Dent 提到，推销一台连操作员、用户和程序员自己都不知道程序放在物理内存哪个位置的机器，非常困难。

再加上 IBM 拥有强大的销售网络、设备租赁金融能力和品牌号召力，企业客户更担心购买了一台小众机器后，厂家无法提供后续支持。正如斯坦福大学计算中心主任 Collins 后来所说：

“找上门买 Burroughs 机器的人，远远多于销售人员卖出去的人。那是一个伟大的想法，真正懂行的人非常乐意采用它，但可惜它没有被漆成蓝色。”
（“Considerably more Burroughs machines were bought than sold. It was a great idea, and I think the people that knew were quite willing to go with it, but it wasn't painted blue.”）

这里的蓝色，指的正是深蓝帝国 IBM。

商业上的胜负很明确，但技术的影响并未止步于此。

IBM 沿着 System/360 演化出 System/370、System/390，直到今天的大型机系统 z/OS，给整个软件产业确立了向后兼容与大规模软件工程规范，也把布鲁克斯的《人月神话》刻进了行业记忆。

Fred Brooks. Photo by SD&M, CC BY-SA 3.0, via Wikimedia Commons.

Burroughs 这条血脉也以另一种方式存活了下来。1986 年 Burroughs 与 Sperry 合并成立 Unisys，直到 2025 年 7 月发布的官方目录里，Unisys 企业服务器的旗舰操作系统依然叫 Master Control Program（MCP 22.0），底层依然用源自 ALGOL 的 NEWP 编写。

而在思想上，Robert Barton 后来前往犹他大学任教。当时还在犹他大学攻读研究生的艾伦·凯（Alan Kay）接触到了 B5000 的设计。

Kay 后来回忆， Barton 在一次演讲里说过： “递归设计的基本原则，是让部分拥有与整体同等的能力。”（The basic principle of recursive design is to make the parts have the same power as the whole.）Kay 第一次把“整体”想成整台计算机，开始怀疑为什么要把它拆成数据结构和过程这些更弱的东西。他在 FLEX 机器上处理对象引用的方式，是 B5000 描述符的推广；这个想法后来一路发展到了 Smalltalk 和面向对象编程。

今天的 Java 虚拟机和 WebAssembly 也采用栈式计算模型，B5000 是最早将这种模型引入硬件的商用机器之一。

IBM 证明了，足够庞大的工程队伍可以把系统的复杂度消化掉。

Burroughs 证明的是另一件事：当硬件从设计之初就懂得软件的抽象，系统本来不需要那么复杂。