使用 avr-g++ 的 8b uC 中的 32b 乘法与使用 gcc 的 X86 上的 32b 乘法
Posted
技术标签:
【中文标题】使用 avr-g++ 的 8b uC 中的 32b 乘法与使用 gcc 的 X86 上的 32b 乘法【英文标题】:32b multiplication in 8b uC with avr-g++ vs 32b multiplication on X86 with gcc 【发布时间】:2020-02-08 07:57:27 【问题描述】:问题:
我正在做一个定点 c++ 类来在 8b 微控制器上执行一些闭环控制系统。 我编写了一个 C++ 类来封装 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\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-g++.exe$(QUOTE) -funsigned-char -funsigned-bitfields -DNDEBUG -I"E:\Programs\AVR\7.0\Packs\atmel\ATmega_DFP\1.3.300\include" -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -pedantic -mmcu=atmega4809 -B "E:\Programs\AVR\7.0\Packs\atmel\ATmega_DFP\1.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++ 编译器的怪癖?
更新:
各种解决方案的调试器输出
【问题讨论】:
res = (int32_t)0 +op1 *op2;
是 res = (int32_t)0 + (op1 * op2);
。在+
之前计算乘法。但(int32_t) op1 * op2
应该可以工作
【参考方案1】:
这是编译器的预期行为。
当您编写A + B * C
时,由于运算符优先级,这相当于A + (B * C)
。 B * C
术语是单独评估的,而不考虑以后将如何使用它。 (否则,很难查看 C/C++ 代码并理解实际会发生什么。)
在 C/C++ 标准中有整数提升规则,有时通过在执行乘法之前将 B 和 C 提升为 int
或 unsigned int
类型来帮助您。这就是为什么您在 x86 gcc 上获得预期结果的原因,其中 int
有 32 位。但是,由于 avr-gcc 中的 int
只有 16 位,因此整数提升对您来说还不够好。因此,您需要将B
或C
转换为int32_t
,以确保乘法的结果也是int32_t
。例如,您可以这样做:
A + (int32_t)B * C
【讨论】:
以上是关于使用 avr-g++ 的 8b uC 中的 32b 乘法与使用 gcc 的 X86 上的 32b 乘法的主要内容,如果未能解决你的问题,请参考以下文章
OpenCV 中的 CV_8UC1 到 CV_32FC1 的转换
GrabCut 中的错误参数(图像必须具有 CV_8UC3 类型)
如何将 OpenCV 中的adaptiveThreshold 用于大于 255 的值(即类型 CV_8UC1)?