为什么这些应该对无符号整数进行操作的指令仍然会影响处理有符号数字时使用的标志?

发布于 2024-10-17 08:16:04 字数 117 浏览 9 评论 0原文

据记录,“INC”、“DEC”和“MUL”指令应该用于无符号整数,但前两个指令仍然会影响溢出和符号标志,而“MUL”会影响溢出标志,这些标志是处理有符号数时使用的标志,并且它不会影响溢出标志。该文档没有意义,那为什么呢?

It's documented that "INC", "DEC" and "MUL" instructions should be used on unsigned integers but still two first instructions affect overflow and sign flags and "MUL" affects overflow flag which are flags used when dealing with signed numbers and it doesn't make sense with that documentation, So why ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

眸中客 2024-10-24 08:16:04

我不确定您从哪里得到 incdec 应该限制为无符号整数的想法。请指出相关文档。

一般,8086 处理器对于有符号/无符号操作没有不同的指令。处理器内置了关于如何在“签名”世界中查看操作结果的知识,但也仅此而已。这一点一直延续到 x86 处理器设计的最新迭代中。

使用仅适用于无符号值的 inc 指令没有什么意义,因为这样一来,增加有符号值的成本就会非常昂贵(您必须使用 add code> 或 adc 指令添加 1),否则在执行 inc(或 dec)后检查溢出的成本将非常昂贵。

I'm not sure where you get the idea that inc and dec should be restricted to unsigned integers. Please point me at the pertinent documentation.

In general, the 8086 processor didn't have different instructions for signed/unsigned operations. The processor had built-in knowledge of how the result of an operation would be viewed in a "signed" world, but that's pretty much as far as it went. And that has been carried through to the latest iterations of the x86 processor design.

It would make little sense to have an inc instruction that worked only with unsigned values, as then it would be either very expensive to increment a signed value (you would have to use the add or adc instruction to add 1), or it would be very expensive to check for overflow after doing the inc (or dec).

时常饿 2024-10-24 08:16:04

假设我们在这里谈论 x86,关于溢出标志的维基百科页面 表示它是由所有算术运算设置的。您所指的哪些文档有其他暗示?

Assuming we are talking x86 here, the Wikipedia page on the overflow flag says it's set by all arithmetic operations. Which documentation are you referring to that suggests otherwise?

云淡月浅 2024-10-24 08:16:04

它的工作原理如下:

考虑两个字节值 0x65 和 0x31。无论您从有符号还是无符号的角度来看它们,它们都是无符号值。

然后将它们相加:

0x65 + 0x31 变成 0x96,从无符号的角度来看这很好(总和适合一个字节,因此没有设置进位标志)。然而,从有符号的角度来看,两个正数相加会产生负数,因此设置了溢出和符号标志。事实上,对于所有有符号数,如果最高有效位由于操作而改变,则溢出标志被设置,否则被清除。

通过为无符号加法和有符号加法设置适用的标志,您可以看到 CPU 对每条指令执行两个操作。之后,由编译器(或汇编程序员)决定是无符号条件分支(使用标志零和进位)还是有符号条件分支(使用标志零、符号和溢出)。

那么有什么意义呢?

关键是,如果不以这种方式完成,处理器将需要一组指令用于有符号操作(仅影响零、符号和溢出标志),而另一组指令用于无符号操作(影响零和进位)。

This is how it works:

Consider two byte values 0x65 and 0x31. They are both unsigned values regardless of whether you look at them from a signed or unsigned point of view.

Then you add them:

0x65 + 0x31 becomes 0x96 which is fine from the unsigned point of view (the sum fits in a byte so no carry flag was set). However from the signed view the addition of two positive numbers resulted in a negative number, hence the overflow and sign flags were set. In fact, for all signed numbers the overflow flag is set if the most significant bit changes as a result of the operation, otherwise it is cleared.

You can see it as if the cpu performs two operations for every instruction by setting the applicable flags for both the unsigned and the signed add. After that it is up to the compiler (or assembly programmer) to decide if an unsigned conditional branch (using flags zero and carry) or a signed conditional branch (using flags zero, sign and overflow).

So what's the point?

The point is that if it were not done in this way the processor would need one set of instructions for signed operations (that would only affect the zero, sign and overflow flags) and another for unsigned operations (affecting zero and carry).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文