zoukankan      html  css  js  c++  java
  • 2.1.2 指令执行(译)

          CPU执行每个指令时都有一系列小步骤。粗略地,步骤如下:

    1.从内存中读取下个指令,放入指令寄存器
    2.改变程序计数器,指向下个指令
    3.决定该指令的类型
    4.如果指令在内存中用字来存储,决定它的位置
    5.读取该字,如果需要的话,读取到CPU寄存器
    6.执行该指令
    7.回到步骤1,执行下面的指令

          这些步骤通常被称作“读取-解码-执行”循环,是所有计算机的核心操作。
          上述关于CPU工作原理的描述看起来像是用英语编写的程序。
          2.3展示了这个非正式程序的Java重写版本,称为解释器。这个被解释的机器对用户程序来说有两个可见寄存器:程序计数器(PC),掌握下个待请求指令的地址,还有累加器(AC),用于累加算术结果.还有的寄存器用于保存当前指令,当前指令的类型,指令操作数的地址,以及当前操作数本身(数据)。指令假设包含一个简单的内存地址。内存定位地址包括操作数,比如要加到累加器上的操作数。
          事实上,可以编写一个模仿CPU功能的程序来表明:程序不是由一个布满电子器件的盒子(CPU)的硬件所执行的。反而,一个程序可以被一个叫做解释器的程序执行,解释器请求,检查和执行另一个程序的指令,正如第一章所提及。

          这种硬件处理器和解释器之间的等价性对计算机组成和计算机系统设计有着重要影响.在详述机器语言之后,对于一个新的计算机L,设计团队可以决定是构建硬件处理器来直接执行L上的程序还是写一个解释器来解释程序.如果他们决定编写解释器,他们也必须提供一些硬件机器来运行解释器。确实,混合构建也可以,一些用硬件执行同时一些用软件解释。

          一个解释器把目标机器上的指令拆分成小步骤。因此,使用解释器的机器可以做的比硬件处理器更简单、代价更小。这种资源的节省在那些有大量指令的机器上表现的尤为明显。节省的必要性来自于这样的事实:硬件正逐渐被软件(解释器)替代,并且复制硬件比复制软件的代价要大得多。

          早期计算机有着精简的指令集。但是对更强大的计算机的渴望导致了更强大、独特的指令。很早以前,已经发现复杂指令通常有着更快的执行速度,即使这种独特的指令可能导致更大的执行开销。浮点指令就是一种复杂指令。支持直接连接到数组元素的指令也是复杂指令。有时很容易观察到连续执行两个相同指令的情况,所以一个简单指令可以实现两份工作。

          指令越复杂越好,因为单独执行操作有时会重叠,或者用不同的硬件同时执行。在高性能计算机中,这种额外的硬件消耗自然有其合理性。在这个例子中,高性能计算机比低消耗计算机有更多的指令.然而,对指令兼容性的需求和软件开发越来越高昂的代价加剧了对复杂指令的需要,即使在执行代价比执行速度更重要的低端计算机上,也是如此.

          上世纪50年代末,IBM(那时主要的计算机公司)承认推出一小批计算机,它们执行相同的指令,无论对于IBM公司还是它的用户来说,这批计算机都有很多优势。IBM推出术语architecture来描述兼容性的水平.新的一批计算机虽然将只有一个architecture,但是不同的设备可能执行相同的程序,仅仅是在价格和速度上有所不同。但怎样来构建一个低成本计算机,能让它执行高性能计算机上的所有复杂指令呢?

          答案就藏在解释器中。第一个提倡这种技术的是Maurice Wilkes(1951),解释器允许设计出虽然简单便宜,但是能执行大量指令的计算机.成果就是IBM System/360 体系结构,一批兼容的计算机。直接硬件实现(即非解释器实现)只被用在最贵的模型上。

    那些使用解释指令的简单计算机也有一些其他优点.其中最重要的一些是:
    1. 能修复未正确执行的指令,甚至能弥补基础硬件上的设计缺陷
    2. 能以最小代价增加新指令,即使在机器交付以后.
    3. 有组织的设计指令,对复杂指令能高效的开发,测试和编写文档

          由于20世纪70年代计算机市场的显著扩张和计算能力的急剧增长,对低端计算机的需求推动了在解释器在计算机设计领域的应用。在处理器设计中,为一个特殊的指令集定制硬件和解释器是很划算的。由于基础半导体技术的急速进步,节约成本比提升性能更重要,基于解释器的体系结构成为了计算机设计领域的一种惯例。几乎所有在70年代设计出来的新计算机,从微型机到大型商用服务器,都是基于解释器的。

          70年代末,基于解释器的简单处理器得到广泛使用,除了那些最贵,最高性能的设计,比如Cray-1和Control Data Cyber系列。解释器消解了那些制约着复杂指令的内部代价,因此设计者开始扩展很多更复杂的指令,尤其拓展了对操作数的描述方式。

          伴随着数字设备公司VAX计算机的诞生,这种趋势达到了顶点,该机器有着几百种指令和超过两百种不同的方式来指定每条指令使用的操作数。不幸的是,VAX体系结构的设想中,从开始到解释器的实现,几乎没有考虑要实现一个高性能模型。这种设想导致许多有临界值和难以直接执行的指令的加入。这种疏忽对于VAX来说是毁灭性的,对于DEC也一样(康柏在1998年提出DEC,2001年惠普收购康柏)。

          虽然最早的八进制微处理器只是有着简单指令集的简单机器,七十年代末,即使是微处理器也演变成了基于编译器的设计。在这段时期,微处理器设计者所面临的最大挑战之一,就是由集成电路导致的日益增长的复杂度。使用编译器的一个主要优势在于能简化处理器的设计,因为巨大的复杂度被限制在编译器所占用的内存中。所以复杂的硬件设计可能会变成复杂的软件设计。

          摩托罗拉68000十分成功,它有着巨大的解释指令集,同时期的齐格洛Z8000却失败了(Z8000有着同等数量的指令集,但没有用解释器),Z8000的失败证明了解释器在快速生产市场所需的微处理器上确有优势。这种成功动摇了齐格洛的先发优势(Z8000的前辈,Z80要比68000的前辈6800受欢迎得多).当然,其他因素也起到了作用,比如摩托罗拉作为芯片制造商的漫长历史和艾克森石油公司(齐格洛的拥有者)作为石油公司而不是芯片制造商的漫长历史。

          在那个年代,另一个有利于解释器的因素就是快速只读内存的存在,又称作控制存储器,用于保存解释器。假设一个典型的解释指令耗费解释器10条指令(称作微指令,每条执行100纳秒),并且访问两次主存(每次500纳秒)。总执行时间2000纳秒,不到直接执行最快速度的一半。如果不用控制存储器,该指令将会耗费6000纳秒。

  • 相关阅读:
    网站统计中的数据收集原理及实现
    启动hadoop报ERROR org.apache.hadoop.hdfs.server.namenode.FSImage: Failed to load image from FSImageFile
    淘宝(大数据库应用)--转载
    MapReduce作业的map task和reduce task调度参数
    Spark和Hadoop作业之间的区别
    分析MapReduce执行过程
    MapReduce框架Partitioner分区方法
    LVS+keepalived实现负载均衡
    Tomcat 详解
    linux Tomcat restart脚本简单版
  • 原文地址:https://www.cnblogs.com/xihui/p/11622127.html
Copyright © 2011-2022 走看看