结果和溢流旗在结果中如何表现出来
以下示例应同时设置进位和溢出标志：
mov eax, -120
add al, 140
添加Al，140将类似于以下操作：
10001000
+10001100
---------
= 100010100
因此，结果具有9位，而最大的位可以放入Overflow-flag的方式仅在操作的结果“错误”时设置。例如，当将正数添加到正数时，但是设置了sign-flag，从而产生负面结果。
关于我到目前为止我完成的示例中的随身携带标志，我只有从较大的值中减去较小的值时才设置它。
因此，我的问题归结为当无法在寄存器中表示操作的大小时，进位和溢出标志的行为。
The following example should set both the carry and overflow flag:
mov eax, -120
add al, 140
add al, 140 will resemble the following operation in bit:
10001000
+10001100
---------
= 100010100
So the result has 9 bits while the maximum amount of bits that can be put in al is 8.
But the way I understand the overflow-flag it's only set when the result of an operation is "wrong". For E.g. when adding a positive number to a positive number but then the sign-flag is set so it yields a negative result.
And regarding the carry flag in the examples I've done so far, I only set it when I subtract a smaller value from a bigger value.
So my question boils down to how the carry and overflow flag behaves when the size of the operation can't be represented in the register.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好的，您在这里遇到的问题与计算机数据类型的工作方式和所做的事情不匹配。
通常，计算机可以与（IE添加）签名的数据类型或未签名的数据类型一起使用，但是要求它在未签名的值中添加签名值可能会有问题。
在这里，-120是负面的，因此必须使用签名表示。
但是，140本身并不适合8位签名，因此在8位必须使用未签名的表示。
硬件不支持这种组合 - 虽然添加可以给出截断的结果，但如果您执行8位添加，硬件将不会在标志中为您提供有意义的信息。
（如果两个操作数均签署了8位，则增加8位的标志是有意义的足够大，因此使用了上部，就像-120签名8位和140 无签名的8位一样
）是将两个数字转换为较大的数据大小，该数据大小将容纳两个数字（这将是签名的数据类型，因此可以容纳-120，当然，这两个操作数的转换方法将有所不同，因为它们是不同的数据类型）。
因此，通过符号扩展名将-120从8位转换为16位（或更大）。
并且，通过零扩展名将140从8位转换为16位（或更大）。
然后，您可以执行加法并获得签名结果，并具有有意义的溢出标志。＆nbsp;当然，该特定的计算不会在16位中溢出 - 实际上，以两个8位值开始的16位添加可以溢出。
但是，如果您想将其带回8位，则可以检查它是否适合该尺寸＆amp;数据类型。＆nbsp;出于所有实际目的，在这种情况下，16位结果的上部8位包含有关下部8位结果感兴趣的溢出信息，而不是这些信息在标志中（溢出/携带）。
首先，确定要检查的8位数据类型：签名或未签名。＆nbsp;有几种可以使用的方法，但是一种简单的方法是将16位值截断至8位，将其从8位扩展到16位，看看该新扩展的16是否等于原始的16位结果。
对于已签名的8位，您将16位结果截断为8位，然后签名将其扩展回16位，然后与原始的16位值进行比较。＆nbsp;如果它有所不同，则该值不适合8位签名。
无符号8位相同：将16位结果截断为8位，零将其扩展到16位以与原始相比，如果它不相等，则它不适合8位未签名。
或者，从16位原始结果中，您可以检查低8位值的标志位和上部8位的值。＆nbsp;如果所有上部位与下部8位的符号位相同，则16位结果将适合8位签名而不会损失。
对于未签名，如果上部8位为0，则下部8位将在8位未签名的情况下不丢失。
Ok, the problem that you have here is a mismatch with how computer data types work and what you're doing.
In general the computer can work with (i.e. add) signed data types or unsigned data types — but it can be problematic to ask it to add a signed value to an unsigned value.
Here, -120 is negative, so must use a signed representation.
However, 140 itself does not fit in 8-bit signed, so in 8 bits, must use an unsigned representation.
This combination is not supported by the hardware — while the addition will work to give a truncated result, the hardware will not give you meaningful information in the flags if you perform 8-bit addition.
(The flags for an 8-bit addition are meaningful if both operands are 8-bit signed or else if both operands are 8-bit unsigned, but they are not always meaningful when mixing the two data types: in particular when the values involved are sufficiently large such that the upper bits are in use, as is the case with -120signed 8 bit and 140unsigned 8 bit)
The approach to use to get proper results here is to convert both numbers to a larger data size that will accommodate both numbers (it will be a signed data type so it can accommodate -120, and of course, the method of conversion will differ for the two operands as they are different data types).
So, convert -120 from 8 bit to 16 bit (or larger) by sign extension.
And, convert 140 from 8 bit to 16 bit (or larger) by zero extension.
Then you can perform addition and get a signed result, with a meaningful overflow flag. Of course that particular computation won't overflow in 16 bits — in fact, no addition in 16 bits that started with two 8-bit values can overflow.
However, if you want to take it back to 8 bits, you can check to see if it fits in that size & data type. For all practical purposes, in this scenario the upper 8 bits of the 16-bit result contains the overflow information of interest regarding the lower 8-bit result, rather than that information being in the flags (overflow/carry).
First, decide which 8-bit data type you want to check: as to signed or unsigned. There are several approaches that would work, but a simple one is to truncate the 16-bit value to 8 bits, the expand it back from 8 to 16, and see if that newly expanded 16 equals the original 16-bit result.
For signed 8 bit, you would truncate the 16-bit result to 8 bits and then sign extend it back to 16-bits, then to compare with the original 16-bit value. If it differs the value didn't fit in 8-bits signed.
The same with unsigned 8 bit: truncate the 16-bit result to 8 bits and zero extend it back to 16 bits to compare with the original, if it doesn't compare equal then it doesn't fit in 8-bits unsigned.
Alternately, from the 16-bit original result, you can examine the sign bit of the low 8-bit value and the value of the upper 8 bits. If all the upper bits are the same bit value as the sign bit of the lower 8 bits then the 16-bit result will fit in 8-bits signed without loss.
For unsigned, if the upper 8 bits are 0 the lower 8 will fit in 8-bit unsigned without loss.