 附录D MIPS的演化
MIPS16是一个1997年面世的可选的指令集扩展，它能减少二进制程序尺寸的30-40%。实现者希望这种CPU能够在很关心代码尺寸的场合中更有吸引力–这种场合通常就是指低成本系统。由于只应用于特定实现，它是一个多厂商标准：LSI, NEC和Philips都生产支持MIPS16的CPU。
在前面1.2节中我们说过，使MIPS二进制代码比其他架构的并不是MIPS指令集干的活少了, 而是他们的尺寸更大一些–每个指令4字节长，相比之下某些CISC架构一般平均只有3个字节。
MIPS增加了一种模式，在这种模式下CPU可以对16位固定大小的指令进行解码。大多数MIPS16指令扩展成正常的MIPS III指令，所以很明显这将是一个相当受限制的指令子集。窍门就在于使这个子集对足够多的程序充分的进行高效编码，以使整个程序的大小得到大大的压缩。
当然，16位指令并不会使其变成一个16位指令集。MIPS16 CPU是实际存在的带有32位或者64位寄存器的的CPU，MIPS16 CPU的运算也都在这些寄存器上。
MIPS16远不是一个完整的指令集—例如它既没有CPU控制指令，也没有浮点运算指令。但没有关系，因为每一个MIPS16 CPU也必须要运行完整的MIPS ISA。你能运行MIPS16和正常的MIPS代码的混合指令。每个函数调用或者跳转-寄存器指令都能改变运行模式。
1．并不是MIPS发明了提供一种可选的使部分指令只有一半大小的创意。Advanced RISC Machine（ARM）公司的Thumb版本的ARM CPU首先提出这个想法的。
在MIPS16中把指令地址编码成最低有效位(Least Significant Bit, LSB)模式是既方便又高效的。MIPS16指令必须偶字节对齐，所以bit 0不再是指令指针(instruction pointer, 就是程序计数器PC)的组成部分了；取而代之的是，每条跳到奇数地址的指令开始执行MIPS16，每条跳到偶数地址的指令回到正常的MIPS。MIPS子程序调用指令jal的目标地址总是字对齐的，所以新指令jalx隐藏了指令的模式间转换。
为了把指令压缩到一半大小，对于大多数指令我们只分配了3 bit来选择寄存器，这样只有8个通用寄存器允许自由访问；在许多MIPS指令中可以见到的16 bit常数域也被压缩，通常变成了5 bit。许多MIPS16指令只指明两个寄存器，而不是三个。另外，还有一些特别的编码规则将在下一节描述。
D.1.1 MIPS16中的特殊编码格式和指令
被缩减的通用指令没有什么问题，但有两个特定的弱点会加大程序尺寸；5 bit的立即数域构造常量是不够的，在load/store操作中也没有足够的地址范围。三种新的指令和一种特别规定有助于解决这些问题。
extend是一条特殊的MIPS16指令，它由5 bit的代码和11 bit的域构成。这个11 bit的域可以和后续指令中的立即数域相连接，这样就允许使用一个指令对来对16 bit立即数编码。这条指令在汇编语言中看起来就像一个指令前缀。
装载(load)常量在正常的MIPS模式下都需要额外的指令，在MIPS16模式下更是巨大的负担；把常量放在内存中然后再读它们会更快一些。MIPS16对相对于指令自身位置的装载操作(PC-relative loads， PC相关装载)增加了支持，允许常量被嵌到代码段中(典型情况就是在函数的起始处前面)。这些是仅有的不是严格对应于正常的MIPS指令的MIPS16指令—MIPS没有PC相关的数据操作。
许多MIPS load/store操作是直接在栈帧(stack frame)里，$29/mp可能是最普通的基寄存器。MIPS16定义了一组隐式使用mp的指令，允许我们把函数的栈帧引用地址也编进去而不需要一个分离的寄存器域。
MIPS的Load指令总是生成32位的全地址。由于装载字(load word)指令只有当地址是4的倍数是才合法，最低两位就被浪费了。MIPS16的Load指令是可以伸缩的：地址的偏移量会根据被load/store的对象的大小左移，这样就增加了指令中可用的地址范围。
作为一种额外的应急机制，MIPS16定义了一些指令，允许在8个MIPS16可访问的的寄存器中的一个与32个MIPS通用寄存器中的任何一个间任意做数据移动。
D.1.2 对MIPS16的评价
MIPS16对于汇编语言编程来说不是一种合适的语言，我们也不准备对它详细说明。这些是编译器的工作。大多数使用MIPS16模式编译的程序的尺寸都会缩小到用MIPS模式编译的 60-70%。MIPS16比32位CISC架构的代码更紧凑，和ARM的Thumb代码差不多，和纯16位CPU相比相当有竞争力。
但是没有免费的午餐；MIPS16程序可能比MIPS增加40-50%的指令。这意味着在CPU核上运行一个程序会多用40-50%的时钟周期。但是低端CPU经常主要被存储器所限制，而不是被CPU核所限制。较小的MIPS16程序需要较低的带宽来取指令，这样就得到更低的cache缺失率。在cache很小并且程序的存储器有限时，MIPS16将会弥补差距，还有可能要重新改写正常的MIPS代码。
由于性能的降低，MIPS16代码在有大的存储器资源和很宽总线的计算机中没有吸引力。这就是为什么它只是一种可选扩展的原因。
在应用范围的另一端, MIPS16将会与软件压缩技术展开竞争。在放进ROM存储器之后，使用通常的文件压缩算法压缩的正常MIPS程序将会比未压缩的同等MIPS16代码小，而稍大于压缩过的MIPS16同等代码(注1)；如果你的系统拥有足够的内存能够把ROM当做文件系统使用，而把代码解压缩到RAM中执行，那么全ISA软件解压很可能会带来更好的总体性能。
也有这样一种趋势来构造系统，那就是大量使用以字节编码的解释语言(Java或者它的后续者)来书写大量在时间上要求不严格的程序。那种中间代码非常小，在尺寸方面比任何二进制机器码都高效的多。如果只有解释器和一些对性能要求严格的程序留在机器中ISA中，那么更密集的指令集编码格式将只会影响程序的一小部分。当然解释器(特别是Java)本身会非常大，但是应用复杂度的无情增长将很快使它减少重要性。
我预料在1998-2003年将会看到MIPS16小范围的应用于低能量、小尺寸和成本受限制的系统中。它还是值得发明的，因为有些系统—比如”智能”移动电话—可能会大量生产。
——————————————————————————————————-
1．更密集的编码格式在使用上比压缩算法有更低的冗余度。
D.2 MIPSV/MDMX
MIPS V和MDMX是在1997年早些时候一起公布的。它们本来是为一种新的准备在1998年发布MIPS/SGI的CPU中的指令而设计的。但是那个CPU后来被取消了，关于它们的未来存在疑问。
二者都是为了克服一些已知的传统指令集的不足，这些不足是在ISA面向多媒体应用中产生的。象软调制解调器的语音编/解码、或流媒体应用、或图像/视频的压缩/解压缩这样的任务采用一些过去只有专用数字信号处理器(digital signal processor, DSP)才用的数学算法。在这种计算等级，多媒体任务通常都包括重复进行一些对大向量或者数组数据的相同操作。
在基于寄存器的机器内部，通常采用的方案是把多媒体数据项封装到一个机器寄存器中，然后执行一条寄存器-寄存器指令，这条指令对于每个寄存器中的每个域做同样的工作。这是一种非常明显的并行处理形式，被称为单指令，多数据(single instruction, multiple data. SIMD)。
这个想法首先见于一款Intel的业已消失的i860架构的微处理器(circa 88)中。作为对Intel x86指令集进行扩展的MMX在1996年投放市场后，SIMD重新登场时更加引人注目。
MDMX对操纵在一个64位寄存器中8×8-bit的整数组提供了一组操作，这些操作能够对所有的8小片做同样的事情。这些指令包括通常的算术操作(加，减，乘)，也有乘法-累加指令能把结果放在一个巨大的累加器中，这个累加器有足够的精度防止溢出。
由于这些指令被用于特定数据类型被相当清楚的从正常的程序变量分离开来的场合中，MDMX指令集与浮点寄存器一起工作就变得有意义。以这种方式重复利用现有的寄存器意味着现有的操作系统不需要改变(在任务切换时操作系统已经保存和恢复浮点寄存器了)。
与MDMX相似，Intel的MMX为封装进一个64bit的8个8bit数提供了”octibyte”八路(eight-way)指令。MIPS MDMX也定义了4×16位(四个短整数操作)和2×32位(两个字操作)格式，但是早期的情况是一些MDMX实现可能认定octibyte格式和指令足够了。
当对8bit的数做算术运算时, 结果经常下溢和上溢。如果我们必须为众多的溢出测试条件编写处理程序，那么多媒体应用的性能将不会得到提高。而只简单截去最大的和最小的数(对于无符号8-bit数来说，就是255和0)的上溢和下溢结果，对于机器运算来说会更加有帮助。这个处理过程叫做”饱和”(saturating)算法。MDMX拥有这种能力。
这就给我们带来了MIPS V。尽管从名字上看好像意思是指一个升级的指令集–就像MIPS I到IV那样，MIPS V在浮点领域跟MDMX很相似，提供了paired-single操作。paired-single对一对被封装进64-bit的浮点寄存器中的单精度数做两次FP动作。
MIPS V没有MDMX那么古怪；MIPS IV包含了一个相当广泛的浮点运算集合，并且直接为其中的绝大部分提供了paired-single版本的指令；甚至成对比较(paired-compare)也可以做到，这是因为MIPS IV的CPU已经有了多个浮点条件位来接收结果。但MIPS V没有提供复杂多周期指令的成对操作版本的指令，这些多周期指令会需要非常多新的资源(例如没有求平方根和除法)。
D.2.1 编译器能用多媒体指令吗？
引入SIMD多媒体指令的原因和70年代晚期以前在超级计算机中提供向量处理单元的原因相似。很容易为向量处理器构造一个手工矩阵算术包。而用向量运算来编译一个用高级语言写成的程序就难得多了，尽管超级计算机提供商在这上面也取得一些成果。通常这些成果都集中在Fortran上；对于常规编程来说语义上的弱点使Fortran成为一种可怜的语言，但是这让它变成了一种很容易优化的语言，因为边际效应非常明显。
人们一致认为向量化的Fortran编译器在旧的程序上工作的不是很好(“dusty decks”, 一句迷人的Fortran行话)。这样的编译器要求编程人员书写或者修改程序中的循环来使适应优化器的要求，这样才能带来显著的好处。这样可能是一种好的分工：循环可以使用固定格式，但程序员还可以将它们理解为顺序代码，但实际上这些循环编译的结果是一些很难懂的并行代码。术语”optimizer friendly”是含糊不清的：并行处理理论将会把它定义为: “特定种类的边际效应的缺少，尽管实际的编译器可以查找遵循一些严格的多的规定的循环，这样哑模式匹配器就可以将它们安全的识别出来，然后进行向量化处理”。
C的向量化困难的多。这是因为它使用的内存和基于指针的模型，这种模型对于任何数组访问都是隐式操作的。这使得除了最简单的循环以外很难消除其他的边际作用。在产品化上还没有做多少工作。
由于这段历史，开发能够采用多媒体SIMD指令成功优化程序的C/C++编译器的前景如何呢？我猜测在最近前景不好。Intel的MMX是最广泛使用的现代SIMD指令集，但当前也只有汇编语言用户才会使用（注1）。我不希望看到使用x86 MMX的编译器。如果MMX得到大规模的成功使用，并且依赖于汇编子程序，结果就会是这些程序被x86架构所束缚住了；this would hardly be something that Intel would be in a hurry to change.
很多人预测在1998年或者1999年Intel会引入一种更好的ISA扩展。这种扩展将会增加更多的数据格式到”MMX的后代”中，包括成对的单精度浮点数。如果这种能力更强的指令得到编译器的支持，那就可能出现很多同时适用于MIPS V的软件。
D.2.2 使用MDMX的应用程序
就像x86 MMX, MDMX对3D图像和视频应用将会比较有用，在这些应用中CPU把像素值推给软调制解调器所需的低精度信号处理单元。
不幸的是，”near display”3D渲染的性能依赖于谨慎的与显存的集成。 甚至配置很好的CPU也竞争不过廉价的PC世界的加速器，这些加速器与大显存之间无缝结合(注2)。图像和视频处理应用确实在这个等级上运行访问像素的程序，尽管这些这都是些桌面PC应用。
软调制解调器可能对那些希望使用电话的低端消费品设备会比较有用。它们和便宜的集成式调制解调器设备展开竞争，在更大范围里它们要与不断发展的进入家庭的数字电话竞争。
在我看来MDMX在游戏控制台上与CPU/视频系统紧密结合将会是最好的机会。
D.2.3 MIPS V的应用
成对单精度浮点指令和格式是为在高端图像和多媒体应用中出现的重复浮点计算增加带宽。尽管看起来象是硅图像公司(SGI)的市场，3D图像使用的增长会使这种能力在更广的范围里更有有用。
对于MIPS有限的编译器支持看起来比对MDMX的支持更为真实。尽管成对操作看起来好像是超标量CPU的双发射指令的一种替代，它们实际上是相互补充的。SIMD指令采用的并行机制来自于编译器中的更高一级操作，而低级调度还可以可能同时发射两条指令：一条对式浮点指令，另外一条指令负责整数或者管理操作。
—————————————————————————————————-
1．一个愤世嫉俗的人可能会说由于任何x86的克隆都需要MMX，那么MMX够用了。他还会说MMX到底是不是真的在用的问题已经离题太远了。而且从中受益的游戏和图像程序都是那些疯狂的汇编爱好者编写的。
2．如果有人使用与大内存和集成式视频刷新数据通道无缝结合的方式构造CPU的话，它们还有可能展开竞争。但是我没有看到那种MIPS产品的更多迹象。
D.2.4 MDMX/MIPS V有可能成功
SGI 1997年做出的放弃发展它的H1高端处理器项目的决定使这两种指令集(译者注：MDMX 和MIPS V)一直没能正式发布。但是我相信至少有一种面向嵌入式市场的CPU会支持MDMX。到底会发生什么是很有趣的。
在目前为止没有CPU支持MIPS V；但是它比MDMX有更长的生存周期，将还会是1999年发布的CPU有用的附属物。
| 
