读书笔记：Comments On The Case for the Reduced Instruction Set Computer

最新推荐文章于 2020-08-15 04:04:50 发布

老板这里有皮卡丘

最新推荐文章于 2020-08-15 04:04:50 发布

阅读量652

点赞数 1

分类专栏：高级计算机体系结构文章标签：读书笔记计算机体系结构 RISC CISC

本文链接：https://blog.csdn.net/zzw13327734974/article/details/102695783

版权

高级计算机体系结构专栏收录该内容

1 篇文章 0 订阅

订阅专栏

这三个月正拜读《量化研究方法》。并且读了一些相关的论文。这篇论文是个人翻译的。这篇论文代表了工业界对D.A. Patterson的《n The Case for the Reduced Instruction Set Computer》一些观点的反驳。翻译能力有限，有兴趣的还是看英文吧，已添加附件。

读书笔记：Comments On The Case for the Reduced Instruction Set Computer

Patterson和Ditzel的论文[3]认为简化指令集计算机(RISC)可以像复杂指令集计算机(CISC)一样具有成本效益。在这篇笔记中，我们认为他们的一些观点是误导的，并提出了一些与论点相反的证据。我们和他们一样，严重依赖VAX-iI架构。
RISC相对于相应CISC的优越性很难证明。除非CISC和RISC之间的差异非常大(这是不可能的)，否则对成本和性能的随意评估是不够的。纸上的设计是不够的。在我们看来，对RISC和CISC进行仔细的比较需要对两者的硬件和微代码进行完整的设计、处理器的构造或模拟、编译器(可能还有操作系统)的编写以及各种应用程序的性能度量。如果没有这种程度的努力，RISC成本效益提高的说法就很难得到支持。
然而，他并不是说，在进行如此全面的实验之前，这个问题不值得讨论或争论。Patterson-Ditzel论文中提出的问题很有趣，也很重要，任何一种类型的计算机的架构师都可以从对它们的讨论中获益。

复杂性和规模

论文对“简约”与“复杂”进行了对比。这是一个错误的二分法。指令集复杂度是否可以仅通过指令数来度量?那么指令数除以数据类型的数量呢?完整性(例如操作符和数据类型的正交性)是增加还是减少复杂性?我们对这篇论文最严重的批评是它没有包含RISC或CISC的正式定义。在复杂性缺乏定义的情况下，“……我们将讨论在许多情况下复杂的指令集是有害的而不是有用的”是没有意义的。

代码密度

帕特森和迪泽尔声称，通常被认为是VAX之类的CISC的优点的代码压缩在RISC上同样容易实现，而且在任何情况下，由于廉价的内存，密集的代码已经不像以前那么重要了。但是他们关于RISC的理由可以归结为一句话“我们怀疑通过清理原始的[简单的]指令集就可以很容易地实现代码压缩”，没有支持的证据是不能令人信服的。虽然内存的成本会随着时间的推移而降低，但是少量廉价内存的成本仍然低于大量内存。此外，对于给定的计算机模型，内存是每个系统的成本，而微代码开发(CISC)是一次性成本。
当然，密集的代码还提供了其他优点。如果每个缓存块和每个页面有更多的指令，那么缓存性能和分页性能将会更好。

不同的语言使用不同的指令

这篇论文指出(引用Shustek[4]和其他人的话)“很少的操作码占程序执行的大部分”。真够了。但是不同的语言呢?
例如，Fortran的前20个指令可能根本不会使COBOL大受欢迎。例如，著名的Fortran基准Whetstone显示了VAX-ii/780上常见的指令频率分布:前10条指令占所有指令执行的60%，前20条超过75%，前40条超过90%。但是在一个可比较的合成COBOL基准测试中，前10名的指令执行量仅占指令执行量的8%。Whetstone的前20名获得了COBOL基准测试执行量的21%(而不是75%)。更能说明问题的是，Whetstone的前20名只占COBOL基准测试所用时间的4%。
因此，指令的多样性可以帮助支持多种语言。正如最近的一篇论文[2]所指出的，“对于大多数编程环境，系统必须能够有效地支持多种语言……为一种特定语言定制的单一指令集是有限的，因为它会使其他语言的实现变得困难和低效。”

时间是至关重要的

正如Shustek在他的论文[4]中所指出的，对于性能来说，执行一条指令所花费的时间比它的执行频率更重要。他给出了一些使用大量执行时间的很少执行的指令的例子。用多指令序列替换这样的指令会使情况变得更糟，而且只优化那些频繁执行的指令会有明显的风险。
下面是来自VAX-ii/780的一个例子:在一个分时基准测试中，指令MOVC3(字符移动指令)占不到0.4%的指令执行，但占13%的时间;频率排名第60，时间排名第1。

易于Compiler-Writing

大型指令集可以通过保持操作符和数据类型正交来实现。因此，例如，VAX体系结构包括6个不同的异或指令:字节、单词和长单词的两个和三个操作数版本。其中一些毫无疑问很少被使用。但是VAX编译器中的代码生成可以通过拥有它们来简化(这是由VAX编译器编写器验证的)。此外，一旦你对其中一些有了微码，其他的就可以很便宜地实现了

微码大小

这篇论文的PDP-ii/40 -VAX-ii/780微码大小的比较是似是而非的。尽管指令集是相同的，但11/60的微代码量几乎是11/40的10倍。微代码的增加反映了(a)性能的提高，(b)用微代码替换硬件，以及©更复杂的诊断和控制台功能。11/780还支持三个指令集(PDP-Ii、VAX-ii和EDIT)，并具有更复杂的内存管理功能

增加设计时

本文的PDP-i - VAX-iI/780设计时间比较也是似是而非的。完全忽略指令集，VAX-ii/780硬件系统和VMS软件要比PDP-i处理器复杂得多。此外，大公司为大批量生产设计产品需要大量的时间，而小公司为小批量生产设计产品则不存在这样的过程。

增加的设计错误

毫无疑问，在其他条件相同的情况下，大量的微码比少量的微码出现更多的错误。但是如果有少量(RISC)，就必须有人在某处实现复杂的函数。在RISC中，编译器和运行时系统将承担以前由微代码承担的负担，并且在这个软件中可能会出现实现错误。
现在有人可能会说，软件比微代码更容易编写，更容易修改。有人可能会反驳说，微程序开发工具(如微代码编译器)将改变这种情况。但是用户程序需要的复杂函数必须以某种方式实现，这样就会出现错误。
设计误差的检测在很大程度上取决于正式和非正式的测试过程。编译器和处理器都是如此。这样的过程可以很容易地为处理器开发。(帕特森和迪策尔如何比较VAX-i /780微代码和优化编译器的复杂性?)

接口层

高级软硬件接口(CISC)相对于低级接口(RISC)的优势之一是，有更多的机会使用专门的硬件来实现改进的成本/性能。例如，考虑有乘法指令的CISC和没有乘法指令的RISC。乘法函数将通过一系列的移动、分支、移位和加法在RISC上执行。为了提高RISC上的乘法运算速度，需要提高整个处理器的速度，而CISC上的乘法指令可以通过增加专门的数据路径和控制来实现。对于某些技术和性能级别，后者可能比前者便宜得多。

RISC and VLSI

在没有度量标准的情况下，Patterson-Ditzel论文的这一部分是没有说服力的。当然，一个简单的指令集可以用比复杂指令集更少的硅来实现。但是，这并不意味着通过减少指令集的复杂性可以提高系统的成本效益

VAX索引指令

关于非理性实现的传闻当然很有趣。然而，复合指令是否比等效的简单指令序列运行得更低?本文报告了几个简单的指令序列可以代替VAX索引指令，使780的速度提高45%。这是实现的问题，而不是架构的问题。毕竟，如果假设两种情况下的硬件都是相同的，那么使用一条以上的指令来实现INDEX函数所花费的时间肯定不会少于一条指令的版本。这种异常的解释是780的浮点加速器加速了多指令实现中的乘法运算，但是根本没有看到索引。