Nasm - 乘以 2 个值时的奇怪结果

Question

编辑：我使用this 计算器检查结果，但似乎计算器本身计算了错误的值，导致了这个问题。

在使用mul 指令时，我注意到将两个高数相乘会导致错误的值。例子：

mov eax, 0ffffffffh
mov ebx, 0ffffffffh
mul ebx
; eax:00000001 I expected eax to be 0
; edx:FFFFFFFE

mov eax, 0ffffff00h
mov ebx, 0ffffffffh
mul ebx
; eax:00000100 I expected eax also to be 0
; edx:FFFFFEFF

我知道-1 * -1 是1 而ffffffffh 是减一。但是在无符号乘法中将这两个数字相乘不会得到1，或者是吗？另一个例子也是如此。

另外，当使用imul 指令时，我也会得到奇怪的数字，但我认为这是因为有符号乘法：

mov eax, 0fffffff0h
mov ebx, 5
imul ebx
; eax:FFFFFFB0
; edx:FFFFFFFF ; I expected edx to be 4

Answer 1

你的结果是正常的，你的期望是错误的。 IDK 你的错误期望来自哪里，但是 32 位 mul 的 64 位结果进入 EDX:EAX。

原来它来自一个可能使用 Javascript 数字的在线计算器，即带有 53 位尾数的 double-precision 浮点数，它将 0xfffffffe00000001 舍入为最接近的可表示双精度数，即 0xfffffffe00000000。

对于已签名的情况，您只是完全错误地使用了计算器，期望它将您的输入解释为 32 位 2 的补码。

---

乘法结果的下半部分不取决于您是否将输入解释为有符号，所以是的，我们可以使用-1 * -1 = 1 来获取这里的下半部分。 （这就是为什么英特尔只费心为imul 添加有效的非扩展形式，例如imul eax, edx, -1）。

如果我们只是在像 calc 这样的扩展精度计算器中尝试它（在 Ubuntu 中打包为 apcalc，在 Arch 中打包为 calc）：

; base2(16)    // ask for hex output as well as decimal

; 0x0ffffffff ^ 2
        18446744065119617025 /* 0xfffffffe00000001 */

; 0x0ffffff00 * 0x0ffffffff
        18446742969902956800 /* 0xfffffeff00000100 */

所以这证实了 CPU 的结果。请记住，奇数乘以奇数是奇数，因此您对 0xffffffff * 0xffffffff 的 EAX=0 猜测也可以这样排除。

---

对于有符号的，使用任意精度的计算器有点棘手：

; (0xfffffff0 - 2^32) * 5
        -80 /* -0x50 */
; . + 2^64                  // get the 64-bit 2's complement bit-pattern for that negative number
        18446744073709551536 /* 0xffffffffffffffb0 */

这个小的无符号数当然分为0xffffffff 和0xffffffb0，EDX 只是全1，与EAX 的高位相同，因为这就是符号扩展的工作原理。