处理器设计的谬误(1)

　　在计算机发展的整个70年期间，曾经出现了各种各样的分立和嵌入式处理器种群，它们已经进化，并且有些种群已经逐渐消失。从这一进化中产生了许多新奇的设计。有些新奇的概念继续生存，有些几乎立即消亡，而一些概念仅仅存活了短暂的时间就销声匿迹了，但是，继承他们基因的技术在后续的种群中再次出现。

　　本系列深度分析文章将调查13种不成功的处理器种群。这些文章探索了造成每一个处理器种群死亡的主要设计错误。每一个主要设计错误还用一个或几个例子来阐述。然而，随着技术使得许多老的概念焕发新生、重塑辉煌并再次成为新概念而获得无止境的重复利用，也许不知什么时候，勇猛的探索者/设计师将接下来遇见这些处理器种群当中的哪一个呢？这些种群可能被当成是恐龙：许多基于这些概念的处理器曾经就是它们那个时代的优势种群，或者，已经曾经大放光芒并极其繁荣而引起了大量的关注。正是因为不断进化的世界造成了我们的处理器种群的必然演化甚至灭绝，但这并不意味着一个处理器种群在它存在的鼎盛时期不能合理地适应世界。

错误1：设计高水平的计算机指令集架构以支持特殊的语言或语言域(Myopisaur)。

　　从最早的计算时代起，人们不断推动在抽象级解决编程问题，从接线板编程、拨动开关输入、机器语言输入、汇编语言到整个一大群“高级”编程语言(HLL)，从上世纪50年代的Fortran和Cobol，乃至上下半叶研究出来的几百或上千种编程语言。

　　HLL一被开发出来，人们就开始担心用于捕获编程问题的答案HLL描述与被在目标机上执行的由HLL编译器产生的实际指令之间的语义差异。每一种编译器常常产生不好的结果—有时候非常糟糕。即使现在，尽管编译器的开发经历了50多年，但是，对于许多算法来说，最高技能的人类汇编语言编码员所获得的编译结果的质量，要比由最佳的HLL编程器与最佳的可用最优化编译器所产生的代码高一个数量级(或一个数量级以上)。

　　计算机研究人员和商用计算机供应商不可避免地开始研究根据特殊的HLL或语言种群调节一种特殊处理器的可行性，以期把处理器的指令集与语言的要求更为紧密地匹配起来，并缩小语义差异。其理论就是以那些目标HLL编写的程序应该在这些经调整的机器上更为高效地执行。

一系列不合适的努力

　　为了实现这一方法—出现在从主机、微型机、分立微处理器IC到嵌入式处理器内核—的几十年经验以及努力，已经再三地确定这种方法是一个重大架构错误。的确，在Hennessy和Patterson关于计算机架构的开创性图书中可以发现这是典型的“谬误和缺陷”之一[HEN, p. 142]。

　　这一方法存在的基本问题是多方面的：尽管已经被调整为一种语言，但是，处理器可能(而且非常可能将)被用于运行于其它语言编写的程序。经调整的处理器将—因其针对特定语言的调整—在运行采用这些其它HLL编写的程序时效率比较低。

　　在较早时代，硬件资源很少被花费在极少被采用的指令的有效执行上—这是对昂贵的架构资本的一种劣质应用。

　　因一种HLL构造的一些非常特殊的应用，针对特定语言的指令可能终止执行，并且对于典型和最常见的应用是没有用的。因此，对这种指令的硬件本质上是一种浪费。

　　语言演化。基于固定、针对特殊HLL硬件的计算机架构较之于语言本身趋向于在非常长的时间内维持不变，因为软件比硬件更加易于变化。

　　针对特殊HLL的处理器的流行被目标HLL的普及而被无情地终结。在各种语言中的少数体验造成一种处理器具有最少的市场诉求。

　　因此，这种架构方法的缺陷花了很长时间才显现出来。从上世纪60年代至80年代中期，在RISC架构方法发源以前，基于复杂指令集计算机(CISC)、针对特殊HLL的计算机架构激起了巨大的兴趣。研究人员撰写了几百或上千的论文，关于这个课题的专题研讨会和座谈会相当流行，而各个公司根据这一设计哲学向市场推出各种真实的机器。

E-mode意味着缓慢的模式

　　Burroughs公司的"E-mode"机可能是被设计为支持特殊语言的最著名的机器系列。这个系列包括从上世纪60年代初至90年代的B5000/6000/7000 和A-series机(一些兼容的处理器仍然在供货)1。这些机器被设计为直接执行Algol 60。这种计算机家族还具有许多其它重要的功能，包括基于堆栈的架构、非平存储器的利用、无汇编语言、操作系统和专用的管理子系统采用与Algol 60的直接对话编写、并且采用的是48比特的存储字(加上标签比特)。的确，在上世纪60年代和70年代期间，Burroughs几乎成为了针对特殊HLL的计算机设计方法的偶像。

　　在这个时期，这家公司生产了中等规模和小型的针对Cobol的主机(B2000/3000/4000)，以及一种被用于B1700/1800机的有趣的微码架构，其中，包括一组可以被进出交换以匹配不同语言的解释指令集组。正如关于B5000的最热心评论所说，Burroughs“专注于采用较高级的编程注释以实际地排斥机器或汇编语言”[EAR]。

　　遗憾的是，Burroughs E-mode机因HLL机的若干缺点而受损。它们在标准科学和商务处理语言—FORTRAN和COBOL—上的表现肯定是缺乏活力的。后来，为这些机器构建C编译器以及把Unix引入它们的根本架构上的尝试被证明是困难的，因架构的分层存储结构没有小的部分。要尝试把针对特定HLL的指令集扩展至较低端的机器(包括由Burroughs的接任者Unisys在1989年推出的一种单芯片实现—称为单芯片A系列主机处理器(SCAMP) [UNI])需要大量的微码。遗憾的是，Algol 60从未真正以流行的编程语言起飞。这毫无疑问减少了Burroughs机的普及程度。

　　注释：关于E-mode机—[ORG73]、[CHU-CAR]和[CHU-DOR]—有几篇参考文选可用，这里仅仅给出了其中几篇。

　　如上所述，Burroughs以面向B2000/3000/ 4000计算机的COBOL语言继续它的针对特殊HLL的设计哲学，它至少具有针对更为流行、锁定商务的HLL的有点。

许多语言，同样差的结果

　　针对特定HLL的处理器设计的吸引力，还导致人们开发直接运行用APL [HAS]、Lisp [WHO]、Prolog [FAG]以及其它直接针对Basic、Fortran、Pascal、PL/I和Snobol [DIT80]编写的程序的机器。的确，针对特定HLL的计算机架构设计方法所存在的问题导致人们在1980年[DIT80]对它们进行了深刻的反思，只是在CISC工作站出现之前、以及后来在上世纪80年代中期RISC处理器和工作站出现之时。

　　从主机时代向着小型和微型计算机时代的迁移，见证了上述针对特定HLL的计算机架构设计方法以Burroughs B1700/1800获得重复使用，它为若干语言提供了微码指令集(COBOL、RPG以及其中的Fortran) [ORG77]和许多专用的工作站级机器。被设计来直接执行LISP的机器就是一个特别著名的例子(LISP机、Symbolics)。

　　分立微处理器时代也看到了若干针对特定HLL的微处理器架构，包括：被设计来运行Occam的Inmos Transputer；由贝尔实验室设计的用于直接执行C程序的CRISP处理器[DIT87a, DIT87b]；在所有这类微处理器当中，也许最为著名(或声名狼藉)的就是英特尔公司的432，它被设计为运行以Ada语言编写的程序[GEH]。Transputer及其Occam描述了一种针对特定HLL的处理器的功能之一，有时候，它的开发者对于特殊的计算理论以信奉宗教般或准宗教般的热爱投入，从而以奴性的方式证明它自己对于一种编程语言的奉献，并尽力进行实质努力以开发一种支持它的机器。

　　尽管Transputer编译器后来形成为更加传统的HLL，但是，Transputer是以Occam推出的，这是一种基于Tony Hoare的计算序列处理概念。Transputer就是特定为Occam构建的。Inmos的领导人Iann Barron是Occam的最高牧师。Transputer的历史描述了前面所列出的针对HLL的架构所存在的问题之一。它的成功高度依赖于找到一个对Occam有足够兴趣的市场，以购买为它而设计的处理器，或者，对Transputer有足够的兴趣以采纳它作为与众不同的语言。这听起来很像一次宗教对话。

　　英特尔公司的432被设计为执行Ada，Ada在更为一般的意义上说是面向对象的语言。英特尔公司的432可能代表针对特定HLL处理器的极端情况，它对任何语言均无法实现足够的性能，包括用来设计它的Ada语言。实际上，英特尔公司的432微处理器整个冗长的故事一直遭受设计错误的折磨。在[GEH]中引证了一些设计错误，我们发现它们分别是：

—Ada编译器产生谬误的指令；
—Ada编译器并不执行通用的子表达式消除；
—编译器由数值/结果通过参数，即使对于大的阵列(而不是由参考值)；
—编译器总是采用非常慢的模块间调用，即使当不必要时；
—指令以比特排列，因此，解码速度慢；
—从字面上看，不允许一个以上的指令流；
—机器的程序调用效率极低—超过1000个时钟周期，包括282个等待状态；相比之下，在那个时代的其它处理器采用不到100个时钟周期。

　　因此，英特尔的432执行通用的基准比Vax 11/780要慢10~26倍，而比8MHz 8086要慢2~23倍。对于英特尔来说，幸运的是，x86处理器以及用于IBM PC的接任者的演化取得了成功，从而让英特尔的432完全消失，它已经被当今大多数的计算从业者所遗忘。

Java: 最新注定要失败的努力

　　针对特定处理器的最后劫掠一直就在当今的嵌入式时代，利用由Sun、ARM以及其它供应商设计的特殊硬件来执行Java(Sun公司的picoJava处理器以及ARM公司的Jazelle处理器等等)。这些针对Java的处理器鼓动起一些兴趣，但是，并未激发狂热。在当代的嵌入式世界中，设计工程师为了陈述Java应用，在传统的高性能处理器以及即时(JIT)编译上解释Java已经被证明是更加引人兴趣的路线。此外，在嵌入式处理器性能上的持续改善常常证明对于在嵌入式产品中的许多Java应用来说是相当足够的，这些应用主要是面向控制和用户界面。如果针对特定语言的处理器路线通过四个计算时代已经证明它自身就是最令人误导的方法的话，对于那些希望利用硬件以超越通用目的处理器的方式加速语言、以及用那些语言编写的应用程序的人来说，有什么其它的选项是不受限制的？

　　要抛弃的第一个概念一定是“一切关于语言”这个概念。的确，对于数据处理加强的应用来说，它更多的“一切关于”计算以及通信内核和嵌入在程序中的算法。如果一个应用程序涉及重复地执行大矢量的标量积，那么，对于不采用具有规模适当的硬件乘法器或者更好的乘法-累加器(MAC)单元的处理器来说，不论采用Fortran、Ada、C、Java、Basic或是COBOL编写的程序来执行这一应用，其速度均会很慢。如果对于所采用的语言来说，处理器具有合适功能的单元和良好HLL编译器(或解释器)，那么，以这些语言当中的任何一种表达的算法应该执行得相当快速，不论采用什么语言。

　　正是算法的特征—而不是语言的特征—被用于设计、修改或选择正确的处理器。对于这一应用，你或者可以搜寻一种具有乘法器或MAC单元的处理器(和或零开销的循环)—DSP可能是良好的选择，或者—甚至更好的—你可以采用指令集扩展以裁剪一个可配置的处理器内核，使之更为精确地满足应用的性能和通信要求。在这种意义上说，搜寻一种针对特定HLL的计算机架构现在可以由搜寻一种面向特定应用的指令集处理器(ASIP)来取代。

　　注释*：本系列文章以“Processor Design: System-On-Chip Computing for ASICs and FPGAs, Jari Nurmi (editor), Springer, June 2007. ”一书的其中一章为基础。

　　注释1：作者之一Grant Martin为Burroughs工作。在这篇系列文章中一再采用E-mode机作为例子，可以被视为对令人感兴趣的那个时代的有点怀旧和充满深情的回忆。

参考文献：

[CHU] Yaohan Chu 编，High-Level Language Computer Architecture，Academic Press, 纽约, 1975
[CHU-CAR] 上述[CHU]的第三章，Carl R. Carlson, High-Level Language Computer Architecture
[CHU-DOR] 上述[CHU]的第四章，Robert W. Doran, Architecture of Stack Machines
[DIT80] David R. Ditzel和David A. Patterson, Retrospective on High-Level Language Computer Architecture, Proceedings of the 7th Annual Symposium on Computer Architecture, La Baule, 法国 (1980年6月), pp. 97104
[DIT87a] David R. Ditzel, Hubert R. McLellan和Alan D. Berenbaum, Design Tradeoffs to Support the C Programming Language in the CRISP Microprocessor, ASPLOS 1987, pp. 158163
[DIT87b] David R. Ditzel, Hubert R. McLellan和Alan D. Berenbaum, The Hardware Architecture of the CRISP Microprocessor, Proceedings of the 14th Annual International Symposium on Computer Architecture, Pittsburgh, Pennsylvania, 美国, 1987, pp. 309319
[EAR] E. Dean Earnest, Twenty years of Burroughs high-level language machines, Proceedings of the International Workshop on High-Level Language Computer Architecture, June 1980, pp. 6471
[FAG] Barry Fagin, Yale Patt, Vason Sirni, Alvin Despain, Compiling Prolog into Microcode: A Case Study Using the NCR/32-000, Proceedings of the 18th IEEE Microprogramming Workshop, 1985年12月
[GEH] Edward F. Gehringer and Robert P. Colwell, Fast Object-oriented procedure calls: lessons from the Intel 432, Proceedings of the 13th Annual International Symposium on Computer Architecture, 日本东京, 1986, pp. 92101
[HAS] A. Hassitt, J. W. Lageschulte和L.E. Lyon, Implementation of a High Level Language Machine, Communications of the ACM,1973年4月, Volume 16, Number 4, pp. 199212
[HEN] John L. Hennessy and David A. Patterson, Computer Architecture: A Quantitative Approach, 3rd edition (2003), Elsevier Morgan Kaufmann, 旧金山
[ORG73] E.I. Organick, Computer Systems Organization: The B5700/B6700 Series, Academic Press, 纽约, 1973
[ORG77] Elliott I. Organick, James A. Hinds, Architecture and Programming of the B1700/B1800 Series, North-Holland, 纽约, 1977.
[UNI] Reuters新闻, Unisys Introduces Micro A Computer, 1989年1月19日 URL:http://query.nytimes.com/gst/fullpage.html res=950DE2DE113AF93AA25752C0A96F948260
[WHO] Skef Wholey和Scott F. Fahlman, The Design of an Instruction Set for Common Lisp, ACM Symposium on LISP and Functional Programming, 1984, pp. 150158