mspgcc 中出现意外结果

Question

我用 C 编写了一个简单的代码，但是当我将其移植到 mspgcc 时，它没有给我正确的值。这是我代码的一部分：

unsigned short int xk=3588, yk=47541, yk1, sig=10, de=1;

unsigned long int xk1;

xk1=( xk+(sig*(yk-xk)*de));

yk1=xk1 % 65535;

我期望的结果是 xk1=443118 和 yk1=49908，但在 mspgcc 中它给了我 xk1=yk1=49902。 不知道类型选择的问题可能出在哪里？

编辑

这是我的完整代码

#include <stdio.h>
#include "uart1.h"
#include <stdlib.h> 
#include <stdint.h>
#include <string.h>
#include <math.h>

int putchar(int c)
{
   return uart1_putchar(c);
}

int main(void) 
{
   //variables
   unsigned short int xk=3588, yk=47541, yk1, sig=10, de=1;
   unsigned long xk1;
   uart1_init();
   xk1=( xk+(sig*((unsigned long)yk-xk)*de));
   yk1=xk1 % 65536;
   printf("xk1=%6lx\t\n,",xk1);
   printf("yk1=%u\t\n,",yk1);
}

Answer 1

对于这个编译器来说，整数的大小必须是 16 位，这是一个完全合法的系统。

您预计 xk1 为 443118。443118 % 65536 为 49902。

由于计算：

unsigned short int xk=3588, yk=47541, yk1, sig=10, de=1;

unsigned long int xk1;

xk1=( xk+(sig*(yk-xk)*de));

仅涉及 unsigned Short 值，因此这些值将提升为 unsigned int ，然后将结果计算为 unsigned int，最后将该值分配给 unsigned long。但多余的位早已丢失......计算是通过 16 位无符号算术完成的。

---

实验

在装有 GCC 4.1.2 的 64 位 RHEL5 (AMD x86/64) 机器上进行。为了模拟 16 位整数计算，我在表达式（的第二个副本）中随意添加了 ((unsigned Short)(...)) 强制转换。双重乘法仅得到一次强制转换；无论两次乘法的执行顺序如何，结果都不会改变（由于被乘数之一为 1，因此不会改变）。我已经将表达式（的第三个副本）包含在 (unsigned long) 转换中。

测试程序：

#include <stdio.h>

int main(void)
{
    unsigned short int xk=3588, yk=47541, sig=10, de=1;
    unsigned long int xk1;

    xk1 = (xk+(sig*(yk-xk)*de));
    printf("No Cast: %6lu = (%u+(%u*(%u-%u)*%u))\n", xk1, xk, sig, yk, xk, de);
    xk1 = ((unsigned short)(xk+((unsigned short)(sig*((unsigned short)(yk-xk))*de))));
    printf("US Cast: %6lu = (%u+(%u*(%u-%u)*%u))\n", xk1, xk, sig, yk, xk, de);
    xk1 = (xk+(sig*((unsigned long)yk-xk)*de));
    printf("UL Cast: %6lu = (%u+(%u*(%u-%u)*%u))\n", xk1, xk, sig, yk, xk, de);
    return 0;
}

输出是：

$ gcc -Wall -Wextra -g -O3 -std=c99 xx.c -o xx && ./xx
No Cast: 443118 = (3588+(10*(47541-3588)*1))
US Cast:  49902 = (3588+(10*(47541-3588)*1))
UL Cast: 443118 = (3588+(10*(47541-3588)*1))
$

我认为第二个几乎不可读的表达式准确地反映（或足够准确地反映）16 位编译器评估该表达式的方式 - 并且与您所看到的一致。

(47541-3588) 的结果是 43953。(10 * 43953) % 65536 的结果是 46314。加上 3588，结果应该是 49902。

我还添加了一个 (unsigned long ) 转换为 yk 并运行表达式。也许为了完全保真您的 32 位 unsigned long 机器，我应该使用 unsigned int，但结果不会改变。我不知道你从哪里获得替代价值 - 我需要查看你的完整工作程序（与我的类似）以获得任何想法。看起来好像你的计算的某些部分“变成负数”，给你留下了大的（正的）无符号值，但是没有明显的理由让计算变成负数。

---

从注释中获取代码：

#include <stdio.h>
// -unused- #include "uart1.h"
// -unused- #include <stdlib.h>
// -unused- #include <stdint.h>
// -unused- #include <string.h>
// -unused- #include <math.h>

// -unused- int putchar(int c) { return uart1_putchar(c); }

int main(void)
{
    //variables
    unsigned short int xk=3588, yk=47541, yk1, sig=10, de=1;
    unsigned long xk1;
    // -not-needed-in-demo uart1_init();
    xk1=( xk+(sig*((unsigned long)yk-xk)*de));
    yk1=xk1 % 65535;
    //printf("xk1=%6lx\t\n,",xk1);
    //printf("yk1=%u\t\n,",yk1);
    printf("xk1 = %6lx = %6u\n", xk1, xk1);
    printf("yk1 = %6x = %6u\n", yk1, yk1);
}

65535 应该是 65536。行尾的制表符是不必要的，下一个开头的逗号也是不必要的（但这些都是纯粹的装饰）。

更严重的是（但对当前问题无关紧要，因为它未使用）， 定义了一个名为 putchar() 的函数（通常也是宏） >。您可能不应该定义自己的名为 putchar 的函数，但如果必须，您通常应该从 中取消定义宏（假设有一个） 。我承认代码在我的机器上编译正常 - 没有链接，但这是预期的；也许有一天，我会找出这台机器上的 putchar() 到底是什么。

显示的代码产生正确/预期的答案。

我能看到产生观察到的错误行为的唯一方法是这样的，我删除了多余的代码：

#include <stdio.h>

int main(void)
{
    unsigned short int xk=3588, yk=47541, yk1, sig=10, de=1;
    unsigned long xk1;
    xk1=( xk+(sig*((unsigned long)yk-xk)*de));
    yk1=xk1 % 65536;
    printf("xk1= %6lx = %6lu\n", xk1, xk1);
    printf("yk1= %6x = %6u\n", yk1, yk1);

    xk1=( xk+(sig*((short)yk-xk)*de));
    yk1=xk1 % 65536;
    printf("xk1= %6lx = %6lu\n", xk1, xk1);
    printf("yk1= %6x = %6u\n", yk1, yk1);
}

当在我的 64 位机器（当前为带有 GCC 4.6.0 的 MacOS X 10.6.7）上运行时，我得到：

xk1=  6c2ee = 443118
yk1=   c2ee =  49902
xk1= fffffffffffcc2ee = 18446744073709339374
yk1=   c2ee =  49902

忽略十六进制值中的 8 个额外 F，我得到 0xFFFCC2EE，而不是您得到的 0xFFFBC2EE。我对这种差异没有任何解释。但您可以看到，如果中间结果是带符号的 16 位数量，那么您最终几乎可以得到您所看到的结果。

那么问题来了：为什么里面会有签名操作呢？我没有很好的解释。我认为您可能需要查看汇编代码并弄清楚发生了什么；您甚至可能会发现编译器中的错误。