不懂精简指令集还敢说自己是程序员？

在上一篇文章《CPU进化论：复杂指令集》中我们从历史的角度讲述了复杂指令集出现的必然，随着时间的推移，采用复杂指令集架构的CPU出现各种各样的问题，面对这些问题一部分人开始重新思考指令集到底该如何设计。

在这一时期，两个趋势的出现促成一种新的指令集设计思想。

内存与编译器

时间来到了1980s年代，此时容量“高达”64K的内存开始出现，内存容量上终于不再捉襟见肘，价格也开始急速下降，在1977年，1MB内存的价格高达$5000，要知道这可是1977年的5000刀，但到了1994年，1MB内存价格就急速下降到大概只有$6，这是第一个趋势。

此外在这一时期随着编译技术的进步，编译器越来越成熟，渐渐的程序员们开始依靠编译器来生成汇编指令而不再自己手工编写。

这两个趋势的出现让人们有了更多思考。

化繁为简

19世纪末20世纪初意大利经济学家Pareto发现，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，这就是著名的二八定律，机器指令的执行频率也有类似的规律。

大概80%的时间CPU都在执行那20%的机器指令，同时CISC中一部分比较复杂的指令并不怎么被经常用到，而且那些设计编译器的程序员也更倾向于组合一些简单的指令来完成特定任务。

与此同时我们在上文提到过的一位计算机科学家，被派去改善微代码设计，但后来这老哥发现有问题的是微代码本身，因此开始转过头来去思考微代码这种设计的问题在哪里。

他的早期工作提出一个关键点，复杂指令集中那些被认为可以提高性能的指令其实在内部被微代码拖后腿了，如果移除掉微代码，程序反而可以运行的更快，并且可以节省构造CPU消耗的晶体管数量。

由于微代码的设计思想是将复杂机器指令在CPU内部转为相对简单的机器指令，这一过程对编译器不可见，也就是说你没有办法通过编译器去影响CPU内部的微代码运行行为，因此如果微代码出现bug那么编译器是无能为力的，你没有办法通过编译器生成其它机器指令来修复问题而只能去修改微代码本身。

此外他还发现，有时一些复杂的机器指令执行起来要比等价的多个简单指令要。

这一切都在提示：为什么不直接用一些简单到指令来替换掉那些复杂的指令呢？

精简指令集哲学

基于对复杂指令集的思考，精简指令集哲学诞生了，精简指令集主要体现在以下三个方面：

1，指令本身的复杂度

精简指令集的思想其实很简单，干嘛要去死磕复杂的指令，去掉复杂指令代之以一些简单的指令。