浮点到有符号整数的转换不匹配浮点到无符号整数

Question

下面的宏

#define MS_TO_TICKS(ms) ( ( (float)(ms)/ MILLISECONDS_PER_SECOND) * clkRate() )

将以毫秒为单位的值转换为正确的时钟滴答数。出于某种原因，如果我将结果存储在有符号整数中，有时会得到与存储在无符号整数中不同的值。

下面的代码说明了问题，并输出如下：

Milliseconds: 7
Expected val: 14 
Signed Int  : 14 //OK
Unsigned Int: 14 //Still OK
Floating Pnt: 14.0000000000000
Double Precn: 14.0000004321337
Direct Macro: 14.0000004321337


Milliseconds: 10
Expected val: 20
Signed Int  : 20 //Expected value, looks like it rounded up
Unsigned Int: 19 //Rounded Down? What?????
Floating Pnt: 20.0000000000000
Double Precn: 19.9999995529652
Direct Macro: 19.9999995529652

这是在 Core i7 处理器上运行，并使用 gcc 编译如下：

ccpentium -g -mtune=pentium4 -march=pentium4 -nostdlib -fno-builtin -fno-defer-pop \
    -ansi  -Wall  -Werror -Wextra  -Wno-unused-parameter -MD -MP

我没有看到使用 https://ideone.com/HaJVSJ 的相同行为

发生了什么事？？

int clkRate()
{
    return 2000;
}
const int MILLISECONDS_PER_SECOND = 1000;
#define MS_TO_TICKS(ms) ( ( (float)(ms)/ MILLISECONDS_PER_SECOND) * clkRate() )


void convertAndPrint(int ms)
{
    int  ticksInt;
    unsigned ticksUint;
    double ticksDbl;
    float ticksFlt;

    ticksInt = MS_TO_TICKS(ms);
    ticksUint= MS_TO_TICKS(ms);
    ticksFlt = MS_TO_TICKS(ms);
    ticksDbl = MS_TO_TICKS(ms);

    printf("Milliseconds: %i\n", ms);
    printf("Expected val: %i\n",ms*2);
    printf("Signed Int  : %2i\n"
           "Unsigned Int: %2u\n"
           "Floating Pnt: %.13f\n"
           "Double Precn: %.13f\n"
           "Direct Macro: %.13f\n",
           ticksInt,ticksUint,ticksFlt, ticksDbl, MS_TO_TICKS(ms));
}

void weirdConversionDemo(void)
{
    convertAndPrint(7);
    convertAndPrint(10);        
}

==EDIT==

根据要求，汇编作为编译器的输出。我将代码稍微简化为：

int convertToSigned(int ms)
{
    return MS_TO_TICKS(ms);
}

unsigned int convertToUnsigned(int ms)
{
    return MS_TO_TICKS(ms);
}

convertToSigned 的汇编程序 (sn-p)：

fildl   8(%ebp)
movl    MS_PER_SECOND, %eax
pushl   %eax
fildl   (%esp)
leal    4(%esp), %esp
fdivrp  %st, %st(1)
fstps   -4(%ebp)
call    clkRate
pushl   %eax
fildl   (%esp)
leal    4(%esp), %esp
fmuls   -4(%ebp)
fstps   -8(%ebp)
movss   -8(%ebp), %xmm0
cvttss2si   %xmm0, %eax

对于 convertToUnsigned

fildl   8(%ebp)
movl    MS_PER_SECOND, %eax
pushl   %eax
fildl   (%esp)
leal    4(%esp), %esp
fdivrp  %st, %st(1)
fstps   -20(%ebp)
call    clkRate
pushl   %eax
fildl   (%esp)
leal    4(%esp), %esp
fmuls   -20(%ebp)
fnstcw  -2(%ebp)
movzwl  -2(%ebp), %eax
movb    $12, %ah
movw    %ax, -4(%ebp)
fldcw   -4(%ebp)
fistpll -16(%ebp)
fldcw   -2(%ebp)
movl    -16(%ebp), %eax
movl    -12(%ebp), %edx

Answer 1

0.01，10 / 1000 的数学结果，不能精确地用二进制表示。对于中间浮点结果，一个编译器可能使用比类型（此处为float）所需的精度更高的精度。在 C99 中以精确定义的方式允许这样做，只要编译器将 FLT_EVAL_METHOD 定义为 1 或 2。一些非 c99 编译器也让中间结果具有过高的精度，这一次没有明确定义何时可以舍入或不可能发生。

在二进制中，0.01 的最接近表示可能在一种精度上高于 0.01，而在另一种精度下则更低。这将解释 19 与您的编译器和 20 与 ideone。

一个遵守 C99 规则的编译器没有理由为 ticksInt 和 ticksUint 生成不同的值。但是，不遵守这些规则的编译器可能会生成导致这种情况发生的代码。

将-std=c99 添加到命令行选项使GCC 尊重C99 标准关于浮点表达式的超精度的字母。如果没有这个选项，GCC 关于超精度的行为（当必须有超精度时，即为 387 FPU 生成代码时）是非常“随意”的：结果保存在 80 位寄存器中并溢出到 64-或者编译器随心所欲地在堆栈上设置 32 位插槽，无需程序员干预，从而导致不可预测、不稳定的结果。

这可以完全解释您在家编译时观察到的情况：出于某种深不可测的原因，该值直接从 80 位寄存器转换为 int，但已从 80 位寄存器变为 32 位转换为unsigned int 时的槽。

如果这是正确的解释，您的解决方案是：

• 不生成 387 代码：使用 GCC 选项-msse2 -mfpmath=sse；

• 使用-std=c99，在最近的 GCC 中，可以合理解释“超精度”的含义，从而使浮点代码可预测；

• 以long double 类型进行所有计算。

请参阅this answer 的“This Said”部分了解更多详情。