未定义操作码对（原始）Intel 8086/88 的影响
由于原始 8086 和 8088 没有针对非法指令的软件异常，因此当输入此类指令（例如“FF FF”）（不是操作码）时，它们会如何表现？它们是否停止，是否自行重置，是否可能在其控制总线上发出特殊的周期指示？
Since the original 8086 and 8088 do not have a software exception for illegal instructions, how do they behave when fed such, for instance "FF FF" (not an opcode) ? Do they stall, do it reset itself, possibly emitting a special cycle indication on its control bus ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果没记错的话，Intel 的官方说法是他们都是 NOP。
实际上，至少有一些未定义的操作码确实作为产生结果的真实指令执行。例如，AAD 或 AAM 的第二个字节是 00001010。转换为十进制的 10。如果您执行的指令与其中一个字节具有相同的第一个字节（分别为 11010101 或 11010100），但将第二个字节更改为另一个值（例如 00000100），它将执行相同的基本操作，但在基础中您已经指定（八进制 00000100）。
编辑：您似乎有意将您的问题变成几乎没有人能够真正回答的问题。您首先询问未定义的操作码，然后将其限制为英特尔所说的未定义的操作码的某些子集，并且只想了解那些真正未定义的操作码（根据某些定义，显然只存在于你的头脑中）。
唯一可以回答的问题是“ffff 做了什么？”曾经我也许能够回答这个问题，但我只能说“显然没有什么值得纪念的”。
至于声称这不可能是正确的，您似乎误认为这是英特尔真正关心的事情。在大多数情况下，未记录的操作码就是这样：未记录。他们付出了相当大的努力来记录当你遵循“规则”时事情会如何运作，但大多忽略了否则会发生什么。
从表面上看，真正能让您满意的就是一个真正的 8088/8086，它仍然可以运行，您可以使用它进行测试。我祝你找到那个好运。
If memory serves, Intel's official claim was that they were all NOPs.
In reality, at least a few of the undefined op-codes do execute as real instructions that produce results. For example, the second byte of AAD or AAM is 00001010. That converts to 10 in decimal. If you execute an instruction with the same first byte as one of those (11010101 or 11010100 respectively), but change the second byte to another value (say 00000100), it'll do the same basic thing, but in the base you've specified (octal for 00000100).
Edit: You seem intent on turning your question into one that almost nobody can really answer. You started by asking about undefined op-codes, but then restrict it to some subset of those Intel said were undefined, and only want to know about those that were really, truly undefined (by some definition that apparently exists only in your head).
The only question that seems answerable at all is "what did ffff do?" At one time I might have been able to answer that, but about all I can say any more is "apparently nothing memorable."
As for claiming it can't be right, you seem to be mistaking this for something Intel really cared about. For the most part, undocumented op codes were exactly that: undocumented. They went to considerable effort to document how things would work when you followed the "rules", but mostly ignored what would happen otherwise.
From the sound of things, about all that will satisfy you is a real 8088/8086 that's still operational that you can test with. I wish you the best of luck with finding that.
好吧，我们知道一些未定义的操作码的作用。我的朋友 reenigne，或者 Andrew Jenner，为我进行了硬件测试操作码 0x60-0x6F。事实证明它们只是 0x70-0x7F 的别名，或者条件跳转。
编辑：换句话说，它们可能不是 NOP，并且经过测试的肯定不是 NOP。
Well, we know what some undefined opcodes do. My friend reenigne, or Andrew Jenner, hardware tested opcodes 0x60-0x6F for me. Turns out they're just aliases of 0x70-0x7F, or the conditional jumps.
EDIT: In other words, they are probably not NOPs, and the tested ones definitely aren't NOPs.