反对采用微码的案例 - 处理器种群及种群设计错误详解

反对采用微码的案例

　　微码还具有若干缺点：

　　·与具有较为简单的ISA的机器相比，低端中间ISA机器的性能常常非常差，因为中间ISA机器的分层常常证明并不是最优化地使用计算资源。

　　·与针对真实的目标机器能够实现的根本简单的ISA的编译器相比，在中间ISA上生成代码的编译器无法做到同一程度的最优化。对编译的最优化只能在两个独立的层面上完成。瞄准一个家族中直接实现中间ISA的高端处理器的HLL编译器无法为该家族中的低端处理器进行最优化，除非为它们做特别的修改，这样会打消它们的一些优点。

　　·为了满足若干不同的语言的要求，一种针对若干不同ISA的机器可能结合不稳定的设计折中，从而为所有的目标语言提供差的性能。

　　·微码编译器、翻译器或生成器(把固定的中间ISA翻译为根本的目标、简单的ISA)可能极度简单或者难以适应，因为它并不打算频繁地运行。此外，微码可能难以改变，特别是如果被存储在ROM之中的话(当然一些机器在片上RAM存储的部分微码允许改变)。

　　中间ISA概念的一些领先的支持者把它们具体表达在Burroughs处理器中 (如上所述)，但是，在文献中可以发现许多其它的努力，由多年来构建的许多不同的微可编程计算机的可用性来支持。Carlson2讨论的一种微编程 Fortran计算机代表了Fortran语言的接近直接实现，并且仅仅需要一个简单的翻译器，此外，他还讨论了一种微编程的EULER处理器(EULER是Algol 60的变种)。Hassitt、Lageschulte和Lyon3讨论的APL机器就采用了微编程。

　　在上世纪80年代，Flynn4调查了许多架构方法，其中，包括微码概念，并试图定义直接执行HLL的理想的语言机器。Moulton5研究了 支持HLL编译和执行的微编程及其的一般设计。在用微编程支持的许多其它HLL当中(见前一节更多的讨论)有LISP6和Prolog7。可能说明这一概 念的最早代表就是Burroughs机器的B1700/1800系列，它支持面向Cobol、Fortran和RPG8的中间ISA。最近，我们已经看到 这一方法的元素被用于解释方法之中，如具有P代码的Pascal和具有其虚拟机的Java;尽管具有足够的动机来改善性能并且经过足够的时间，但是，这些 语言的固有编译器仍然会出现。在任何情况下，这些方法可能不必要采用在现代处理器上的微码。

　　过去残留下来的概念

　　你可能会推想，上世纪80年代VLSI的出现已经缩减了微编程。的确，行业标准微处理器ISA的出现，那些ISA的多个世代的实现，以及利用现代IC制造工艺可用纯晶体管数的增加，似乎已经减少了微码方法的应用。然而，这一技术的几个发育不全的残迹已经在最近几年浮出表面。例如，在上世纪80年代末，Unisys推出了所谓的单芯片A系列主机处理器(SCAMP)9，其中结合的相对低端的RISC处理器类似于该公司在小型、低端的A3和A4主机上采用的处理器，它里面采用的几百K微码就是沿用从上世纪50年代以来在最初的B5000出现时所采用的Burroughs "E-model"指令集。SCAMP被用于"Micro-A"计算机，在此，SCAMP芯片利用许多微码ROM芯片被汇编至2英寸×2英寸的多芯片模块之中。

　　这一方法的另一个有趣的遗迹以及这一问题的一个反例就是在从AMD K610开始的、现在的奔腾级处理器之中发现的问题。在这些处理器中，以前x86处理器世代的CISC指令利用RISC指令集实现。处理器的指令解码单元把CISC指令分解为RISC操作，然后，汇编并把这些更为简单的操作按组流出至处理器的并行执行单元。它并不是严格的微码，但是，它在一定程度上明显从微码而来。

　　这种设计方法还减轻了为更新的处理器创建新的CISC指令。它创建了一种混合CISC/RISC架构。显然，微架构/微码机器仍然具有一定的作用和位置，它随着半导体技术和处理器架构的不断演化而兴衰。或许，这一蜥蜴类家族树的遗迹将在当今更为敏捷的哺乳类机器上延续下去。

　　尽管依然存在一些中间ISA的残留应用，如上所述，微码已经证明在进化上走入了死胡同，因为它不如直接用硬件高效地执行一个ISA。一旦硬件电路丰富，微码的硬件效率就会由它的执行低效而超越。在当今的处理器设计中，让大量比较简单的机器通过微码仿效更为复杂的机器显然应用不广泛，尽管存在偶然的例外。新的编程语言常常最初通过比较简单的中间表示法进行解释，但是，如果该语言普及并且如果性能成问题，那么，不可避免地会出现针对“裸金属”处理器的有效的编译器，因此，仍然需要采用微编程。