我正在阅读Tracy Kidder的“新机器的灵魂”，Data General的团队在其中设计了新机器（代号为“ Eagle”，后来称为MV / 8000）。它是先前体系结构（16位Eclipse）的32位扩展。不断变化的主题之一似乎是，他们不想创建带有模式位的机器，并且他们成功做到了这一点。
但是，它没有说明如何从技术上实现这一点，也没有涉及为什么创建没有模式位的机器如此吸引人的原因。这本书不是一本技术性的书，因此细节可能以某种方式被扭曲了。但是，您会在阅读本书时感到“模式位”解决方案在当时很普遍（因此很可行），但工程师可能出于美学原因认为它没有吸引力。这本书还使得创建没有模式位的设计似乎是一项艰巨的任务，而这个特定团队却以某种方式克服了这一难题。
我发现了如何实现的描述：
http://people.cs.clemson.edu/~mark/330/kidder/no_mode_bit.txt
这似乎基本上是关于将操作码空间的先前未使用的部分用于新指令。我必须承认，我对“就是那样”感到有些失望。我也认为这仍然使一些问题无法解决：
首先，16位进程如何生活在32位地址空间中？因为我认为这是“不带模式位”进行32位扩展的关键挑战。另一方面，扩展指令集是一项相对常见的工作。由于没有描述它是如何发生的，因此可以假设16位代码像往常一样简单地访问内存，也许它看到某种类型的内存虚拟化/存储视图（由新的CPU寄存器控制第一个地址在哪里）或这样的事情。但是我不知道还有什么。在那种情况下，可以说它是一种“模式位”解决方案。16位模式进程可以通过添加到CPU的特殊功能与其他进程一起运行。
其次，为什么创建没有模式位的机器如此吸引人？书中吹捧的许多好处是客户希望运行旧软件。但这似乎并不反对使用模式位，因为使用模式位的全部目的是为了具有向后兼容性。当AMD将x86扩展到64位时，至少根据我对“模式位”一词的理解，他们所做的就是添加一个模式位。一个特殊的位，它将使CPU处于64位模式。还有一点将使进程在64位模式的“子模式”中执行（以实现与32位应用程序的兼容性）。子模式的本质是CPU将指令流解释为旧的32位指令，但是使用新的页表格式（由64位可识别的操作系统设置）可解决对32位存储器的访问。映射到完整的物理地址空间。同样，32位代码可以被64位代码取代。与Data General解决方案一样，这也允许32位程序在64位程序下运行（在DG情况下为16位vs 32位）。因此，从客户的角度看，根本没有区别。因此，唯一的好处可能是实现，简化了设计，但是书中并未讲到这就是要关注的问题，因为即使在那时，模式位似乎仍然很常见（而且以后的架构似乎也如x64案例所示使用它）。
我敢肯定我错过了一些东西，所以如果有人可以讨论更多有关这种“无模式位”设计的技术细节和优点的信息，那将是很棒的。