Умножение 32b в 8b u C с умножением avr-g ++ против умножения 32b на X86 с gcc - PullRequest
Новая
       14

Умножение 32b в 8b u C с умножением avr-g ++ против умножения 32b на X86 с gcc

1 голос
/ 08 февраля 2020

ПРОБЛЕМА:

Я делаю класс c ++ с фиксированной точкой для выполнения некоторой замкнутой системы управления l oop на микроконтроллере 8b.
Я написал класс C ++ для инкапсуляции PID и протестировал алгоритм на рабочем столе X86 с современным компилятором g cc. Все хорошо.
Когда я скомпилировал один и тот же код на микроконтроллере 8b с современным компилятором avr-g ++, у меня появились странные артефакты. После некоторой отладки проблема заключалась в том, что умножение 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).
g cc имеет внутреннюю ширину слова не менее 32b в машине X86, поэтому это может быть причиной, по которой я не вижу артефактов на мой рабочий стол.

Командная строка 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 ++?

ОБНОВЛЕНИЕ:

Вывод отладчика различных решений Cast Comparison

1 Ответ

1 голос
/ 08 февраля 2020

Это ожидаемое поведение компилятора.

Когда вы пишете A + B * C, это эквивалентно A + (B * C) из-за приоритета оператора. Термин B * C оценивается сам по себе, независимо от того, как он будет использоваться позже. (В противном случае было бы очень сложно взглянуть на код C / C ++ и понять, что на самом деле произойдет.)

В стандартах C / C ++ существуют целочисленные правила продвижения, которые иногда помогают вам, продвигая B и C будет иметь тип int или, возможно, unsigned int перед выполнением умножения. Вот почему вы получите ожидаемый результат на x86 g cc, где int имеет 32 бита. Однако, поскольку int в avr-g cc имеет только 16 битов, целочисленное продвижение недостаточно для вас. Поэтому вам нужно привести либо B, либо C к int32_t, чтобы результат умножения также равнялся int32_t. Например, вы можете сделать: 

A + (int32_t)B * C
...