препроцессор буэээ (проблема решена)

[wizzard]

#define R_PU_33 17890UL
#define R_PD_33 988UL
#define ADC_V_REF 2560UL

#define MV_TO_ADC(MV,  R_PU, R_PD) (((MV)*(unsigned long)1024UL*(R_PD))/((ADC_V_REF)*((R_PU)+(R_PD))))

int _tmain(int argc, _TCHAR* argv[])
{
    unsigned long i=0;
    i=MV_TO_ADC(33000UL, R_PU_33, R_PD_33);
    printf("%l", i);
    return 0;
}

Этот код печатает “68” из-за integer overflow в числителе, несмотря на то, что везде где можно воткнуты unsigned long, и правильный ответ 690.

Что делать? Вручную раскрывать макросы не хочется, их подобных много. Проверено на msvc, gcc и avr-gcc (ATMEL).

Comments

[sashman.livejournal.com]

про long long спасибо, благо avr-gcc хавает нотацию типа 33000ULL

---

какбэ речь про 8-битные микроконтроллеры о сотнях байт ОЗУ и килобайтах флеша под код, так что порнуха иногда необходима.

кстати, если параметры макроса переменные - имеем инлайн-вычисление. Константы - константу.
в случае же заворачивания в функцию - набоум компилятора, заоптимизирует - не заоптимизирует.

[faceted-jacinth.livejournal.com]

Ну, я не знаю насчёт GCC, а вот какому-нибудь Кейловскому компилятору я бы скорее доверил самому решать насчёт необходимости инлайна inline функции и прочего. Он сцуко умный был! Ну и кстати если уж жалко флеша под код, то инлайнить довольно часто наоборот не нужно ни за что, а вот на способность компилятора узреть одинаковую структуру после раскрытия макросов и вынести её в функцию я бы надеяться не стал, теоретически он это умеет, практически - как повезёт.

[sashman.livejournal.com]

1. Keil не выпускает компилятор под эту платформу. Выбор есть между gcc, IAR (переход gcc ↔ IAR сопровождается переписыванием архитектурно-зависимого кода, т.к. разумеется либы у них разные). И православным ассемблеромъ.

2. Макрос/функция - на самом деле, не столь принципиально. И в любом случае будет переписано для хранение констант в ээпроме.