我正在做一个定点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)。在X86机器上,gcc的内部字宽至少为32b,因此这可能是我在台式机上看不到人工制品的原因。
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 ++编译器的怪癖?
当您写入A + B * C
时,由于运算符优先级,因此等效于A + (B * C)
。 B * C
术语是单独评估的,而与以后如何使用无关。 (否则,将很难查看C / C ++代码并了解实际发生的事情。)
C / C ++标准中存在整数提升规则,有时在执行乘法运算之前可以通过将B和C提升为int
或unsigned int
类型来帮助您。但是,由于avr-gcc中的int
仅为16位,并且您需要32位结果,因此整数提升对您来说还不够好。因此,您需要将B
或C
强制转换为int32_t,以确保乘法结果也将为int32_t
。例如,您可以这样做:
A + (int32_t)B * C