使用 avr-g++ 的 8b uC 中的 32b 乘法与使用 gcc 的 X86 中的 32b 乘法

32b multiplication in 8b uC with avr-g++ vs 32b multiplication on X86 with gcc

问题:

我正在做定点 C++ class 以在 8b 微控制器上执行一些闭环控制系统。
我写了一个 C++ class 来封装 PID,并使用现代 gcc 编译器在 X86 桌面上测试了算法。一切顺利。
当我使用现代 avr-g++ 编译器在 8b 微控制器上编译相同的代码时,我遇到了奇怪的人工制品。经过一些调试,问题是 16b*16b 乘法被截断为 16b。下面是一些显示我正在尝试做的事情的最小代码。

我在桌面系统上使用-O2优化,在嵌入式系统上使用-OS优化,没有其他编译标志。

#include <cstdio>
#include <stdint.h>

#define TEST_16B    true
#define TEST_32B    true

int main( void )
{
    if (TEST_16B)
    {
        int16_t op1 = 9000;
        int16_t op2 = 9;
        int32_t res;
        //This operation gives the correct result on X86 gcc (81000)
        //This operation gives the wrong result on AVR avr-g++ (15464)
        res = (int32_t)0 +op1 *op2;
        printf("op1: %d | op2: %d | res: %d\n", op1, op2, res );
    }

    if (TEST_32B)
    {
        int16_t op1 = 9000;
        int16_t op2 = 9;
        int32_t res;
        //Promote first operand
        int32_t promoted_op1 = op1;
        //This operation gives the correct result on X86 gcc (81000)
        //This operation gives the correct result on AVR avr-g++ (81000)
        res = promoted_op1 *op2;
        printf("op1: %d | op2: %d | res: %d\n", promoted_op1, op2, res );
    }

    return 0;
}

解决方案:

只要用一个局部变量将一个操作数提升为32b就可以解决问题。

我的期望是 C++ 会保证数学运算将以与第一个操作数相同的宽度执行,所以在我看来 res = (int32_t)0 +... 应该告诉编译器无论后面发生什么都应该在int32_t分辨率。
事实并非如此。 (int16_t)*(int16_t) 操作被截断为 (int16_t).
gcc 在 X86 机器中的内部字宽至少为 32b,所以这可能是我在桌面上没有看到人工制品的原因。

AVR 命令行

E:\Programs\AVR.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-g++.exe$(QUOTE) -funsigned-char -funsigned-bitfields -DNDEBUG -I"E:\Programs\AVR.0\Packs\atmel\ATmega_DFP.3.300\include" -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -pedantic -mmcu=atmega4809 -B "E:\Programs\AVR.0\Packs\atmel\ATmega_DFP.3.300\gcc\dev\atmega4809" -c -std=c++11 -fno-threadsafe-statics -fkeep-inline-functions -v -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" -o "$@" "$<"

问题:

这是兼容 C++ 编译器的实际预期行为吗,也就是说我做错了,或者这是 avr-g++ 编译器的一个怪癖?

更新:

各种解决方案的调试器输出

这是编译器的预期行为。

当您写 A + B * C 时,由于运算符优先级,它等同于 A + (B * C)B * C 项是单独评估的,而不考虑以后如何使用它。 (否则,很难查看 C/C++ 代码并理解实际发生的情况。)

C/C++ 标准中有整数提升规则,有时可以通过在执行乘法之前将 B 和 C 提升为 intunsigned int 类型来帮助您解决问题.这就是为什么您在 x86 gcc 上获得预期结果的原因,其中 int 有 32 位。然而,由于 avr-gcc 中的 int 只有 16 位,整数提升对你来说不够好。因此,您需要将 BC 转换为 int32_t 以确保乘法的结果也是 int32_t。例如,您可以这样做:

A + (int32_t)B * C