ASM问题,二进制补码
所以这本书“一步一步的汇编语言”真的很棒,但是它对于在处理实际内存和寄存器数据时二进制补码如何工作有点神秘。除此之外,我也不确定有符号的值在内存中是如何表示的,我觉得这可能是让我感到困惑的原因。任何人......
它说:“-1 = $FF,-2 = $FE 等等”。现在我明白了,一个数字的补码本身乘以-1,加到原来的值上就会得到0。所以,FF 相当于二进制的 11111111 和十进制的 255 的十六进制。所以我的问题是:当书上说“-1 = $FF”时,它在说什么?这是否意味着 -255 + -1 会给你 0 但也没有明确设置 OF 标志?
所以在实践中...假设我们有 11h,十进制为 17,二进制为 00100001。这个值在 AL 中。 那么我们 NEG AL,这将设置 CF 和 SF,并将 AL 中的值更改为...十进制 239,二进制 11101111,还是 EFh?我只是不明白那会是 17 * -1 吗?或者这只是书中措辞不当的解释,它实际上意味着它为您提供了导致溢出所需的值?
谢谢!
so this book "assembly language step by step" is really awesome, but it was sort of cryptic about how two's complement works when working on actual memory and register data. along with that, i'm not sure how signed values are represented in memory either, which i feel might be what's keeping me confused. anywho...
it says: "-1 = $FF, -2 = $FE and so on". now i understand that the two's complement of a number is itself multiplied by -1 and when added to the original will give you 0. so, FF is the hex equivalent of 11111111 in binary, and 255 in decimal. so my question is: what's the book saying when it says "-1 = $FF"? does it mean that -255 + -1 will give you 0 but also, which it didn't explicitly, set the OF flag?
so in practice... let's say we have 11h, which is 17 in decimal, and 00100001 in binary. and this value is in AL.
so then we NEG AL, and this will set the CF and SF, and change the value in AL to... 239 in decimal, 11101111 in binary, or EFh? i just don't see how that would be 17 * -1? or is that just a poorly worded explanation by the book, where it really means that it gives you the value you would need to cause an overflow?
thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果仅考虑一个字节,则
1
的二进制补码为0xff
(如果对十六进制数字使用该格式,则为$FF
)。分解一下,
1
的补码(或一个补码)是0xfe
,然后添加1
即可获得两个补码:0xff
与
2
类似:补码是0xfd
,添加1
即可得到二进制补码:0xfe
现在让我们看一下十进制的 17。正如你所说,那是
0x11
。补码是0xee
,二进制补码是0xef
- 所有这些都与您在问题中所述一致。现在,尝试一下将这些数字相加时会发生什么。首先是十进制:
现在是十六进制:
由于我们处理的数字对象只有一个字节大小,因此
0x100
中的1
被丢弃(有人在这里挥手。 ..),我们的结果是:为了处理“挥手”(不幸的是,我可能不会以一种可以理解的方式这样做):因为溢出标志(
OF
或有时称为< code>V(出于我不知道的原因)与进位标志(C
)相同,可以忽略进位(这表明有符号算术正确发生)。一种可能不太精确但我发现有用的思考方式是,负二进制补码中的前导零与非负二进制补码中的前导零“相同”。If considering a byte only, the two's complement of
1
is0xff
(or$FF
if using that format for hex numbers).To break it down, the complement (or one's complement) of
1
is0xfe
, then you add1
to get the two's complement:0xff
Similarly for
2
: the complement is0xfd
, add1
to get the two's complement:0xfe
Now let's look at 17 decimal. As you say, that's
0x11
. The complement is0xee
, and the two's complement is0xef
- all that agrees with what you stated in your question.Now, experiment with what happens when you add the numbers together. First in decimal:
Now in hex:
Since we're dealing with numeric objects that are only a byte in size, the
1
in0x100
is discarded (some hand waving here...), and we result in:To deal with the 'hand waving' (I probably won't do this in an understandable manner, unfortunately): since the overflow flag (
OF
or sometimes calledV
for reasons that I don't know) is the same as the carry flag (C
) the carry can be ignored (it's an indication that signed arithmetic occurred correctly). One way to think of it that's probably not very precise, but I find useful, is that leading ones in a negative two's complement number are 'the same as' leading zeros in a non-negative two's complement number.在二进制补码中,对于字节,
(-x)
==(256 - x)
==(~x + 1)
。 (~
是 C'ish 的 NOT 运算符,它翻转其操作数中的所有位。)假设我们有 11h。
请注意,256 使用字节,因为它们的大小为 8 位。对于 16 位字,您将使用 2^16 (65536),对于双字,您将使用 2^32。另请注意,所有数学运算对于字节都是 mod 256,对于 Shorts 是 65536,等等。
或者,使用 not/+1,
此方法适用于所有大小的字。
In two's complement, for bytes,
(-x)
==(256 - x)
==(~x + 1)
. (~
is C'ish for the NOT operator, which flips all the bits in its operand.)Let's say we have 11h.
Note, the 256 works with bytes, cause they're 8 bits in size. For 16-bit words you'd use 2^16 (65536), for dwords 2^32. Also note that all math is mod 256 for bytes, 65536 for shorts, etc.
Or, using not/+1,
This method works for words of all sizes.