OR EAX, 0xFFFFFFFF
，并且在寄存器
EAX中该程序存储了一个字符串。我在理解如何与字符串和类似值进行比较时遇到问题。执行该指令后，
EAX的值为0xFFFFFFFF。有人可以告诉我这是什么目的操作有？是汇编代码中经常出现的一行吗？ （例如，行
XOR EAX, EAX是制作EAX = 0的有效方法吗？是这样吗？）#1 楼
我认为，为了理解编译器为什么这样做，请研究以下反汇编：B8 FF FF FF FF mov eax, 0FFFFFFFFh
83 C8 FF or eax, 0FFFFFFFFh
编译器试图完成的工作可能是将
eax寄存器设置为-1使用尽可能少的字节以便于缓存友好。只要您不介意弄乱这些标志，OR的吞吐量就大约是MOV指令的两倍。 这可能是一个初始化为-1的变量。
评论
如果将0视为该范围内的有效值，则通常使用-1来指示错误或其他特殊保留值。我当然在推测。
–彼得·安德森（Peter Andersson）
14年6月13日在20:03
由于OP提到了字符串，因此牵涉到strcmp或其弟兄也是可行的，在这种情况下，-1可以是普通的返回值。但是我同意，如果不查看输入是什么会产生此结果以及该结果如何在以后的代码中使用，就不可能给出“为什么”的非推测性答案。
– DCoder
14年6月13日在20:17
@DCoder非常正确。它可能是比较函数的完全正常的返回值，该值小于-1（<0），等于0，大于1（> 0），这也不罕见。
–彼得·安德森（Peter Andersson）
14年6月13日在20:22
@ user3097712 -1以2补码方式表示为0xFFFFFFFF（所有位均置1）。
– glglgl
14年6月14日在12:06
“或者，只要您不介意弄乱这些标志，OR的吞吐量也大约是MOV指令的两倍。”好吧，不，那不是真的。就CPU或eax而言，-1取决于eax寄存器的先前值，与使用mov相比，这会延长代码的依赖关系链，并会显着降低性能。如您所展示的，代码大小减少了，但是速度却大大减少了。它几乎永远不值得2个字节。 （是的，可以想象芯片会在所有位都置为“或”的情况下出现特殊情况，但事实并非如此。）
–科迪·格雷
17年5月29日在11:49
#2 楼
抱歉，我无法发表评论，但是几个快速（且并非详尽无遗）的测试显示以下内容：gcc（4.6.3）使用
or而不是mov在优化大小（/Os）时msvc（13）使用
or而不是mov，无论哪种优化设置（包括禁用）clang（3.0）使用
mov不管哪种优化设置海湾合作委员会的行为尤其支持彼得·安德森的回答。
评论
谢谢！我没想到要在gcc中使用/ O，但是那当然是很合理的。
–爱德华
14年6月16日在21:13
令人惊讶的结果：MSVC CL19发出或带有/ O2发出，但带有/ Os发出。优化大小时，ICC 17和Clang 4.0使用xor eax，eax，dec eax
–phuclv
17年4月28日在4:34
@LưuVĩnhPhúc令人惊讶的是，必须将/ O（例如其表亲/ Ot）与/ Og组合在一起才能启用MSVC中的优化。否则，它将被完全忽略。 :-)您的示例并不是一个特别好的测试案例。在正常情况下，当在较大代码块内的寄存器中需要-1时，/ O1将导致MSVC发出OR，而/ O2将导致MSVC发出MOV。我只能假设它在此处始终使用OR，因为考虑到函数调用的相对开销，它不担心对EAX的任何数据依赖都会降低性能。
–科迪·格雷
17年5月29日在11:53
#3 楼
这将始终导致将EAX寄存器设置为等于0xFFFFFFFF，并且还会产生适当设置标志（即N = 1，Z = 0等）的副作用。这不是一个常见的习惯用法。评论
N标志是什么（期望进位，溢出，零等，但是N代表什么）？
– jww
14年6月15日，0：12
“ ...这不是常见的习惯用法”-实际上非常普遍，尤其是在较旧的软件中。 OR指令小于MOV指令。节省640K或1MB内存的机器（是的，它可以追溯到那时）。出于相同的原因，XOR曾经（现在仍然）用于将寄存器清零。
– jww
14年6月15日，0：15
@jww：抱歉，我使用许多不同的处理器。我的意思是Intel称之为SF（标志）。其他制造商将其称为N表示负数。如果可以指定生成该序列的编译器，则对OP可能有用。我方便的人都没有这样做。
–爱德华
2014年6月16日在11:42
@jww：谢谢您的解释。我不知道OR小于MOV的事实。现在我知道了。谢谢！从这篇文章中，我学到了很多东西。
–user3097712
2014年6月18日23:02
评论
本来可以影响标志的。数据移动指令通常不会影响标记