多年来我读过很多次你应该做 XOR ax, ax 因为它更快......或者在 C 编程时使用 counter++ 或 counter+=1 因为它们会 INC 或 ADD ......或者在 Netburst Pentium 4 INC 比 ADD 1 慢，因此必须警告编译器您的目标是 Netburst，因此它将所有 var++ 转换为 ADD 1 ...
我的问题是：为什么 INC 和 ADD 有不同的表现？例如，为什么声称 INC 在 Netburst 上速度较慢，而在其他处理器中却比 ADD 快？
对于 x86 架构，INC 更新条件代码的子集，而 ADD 更新整个条件代码集。（其他架构有不同的规则，所以这个讨论可能适用也可能不适用）。
因此，INC 指令必须等待更新条件代码位的其他先前指令完成，然后才能修改该先前值以产生其最终条件代码结果。
ADD 可以产生最终的条件码位，而不考虑之前的条件码值，因此它不需要等待之前的指令完成计算它们的条件码值。
结果：您可以与许多其他指令并行执行 ADD，并与更少的其他指令并行执行 INC。因此，ADD 在实践中似乎更快。
（我相信在全宽寄存器（例如，EAX）的上下文中使用 8 位寄存器（例如，AL）存在类似的问题，因为 AL 更新需要先完成先前的 EAX 更新）。
我不再在我的高性能汇编代码中使用 INC 或 DEC。如果您对执行时间不是特别敏感，那么 INC 或 DEC 就可以了，并且可以减少指令流的大小。
问题是，我收集XOR ax, ax了几年过时的数据，现在分配零胜过它（有人告诉我）。
C 位大约counter++而不是counter+=1已经过时了几十年。确实。
第一个使用汇编的简单原因是，所有指令都将被转换为 CPU 的某种操作，虽然设计人员总是试图让一切尽可能快，但他们会做得更好与一些人一起工作而不是与其他人一起工作。不难想象 INC 怎么能更快，因为它只需要处理一个寄存器，尽管这太简单了（但我对这些东西不太了解，所以我只能做的就是过度简化）部分）。
但是，C 是很久以前的废话。如果我们有一个 INC 优于 ADD 的特定 CPU，那么编译器设计者究竟为什么不使用 INC 而不是 ADD，对于counter++和counter+=1？编译器做了很多优化，而这种变化远非最复杂的。