В горния израз компилатора(gcc) не следва ли да ползва double аритметика?

Така както си го дал най-вероятно е оптимизирал нещата и се учудвам, че не е останал само на int

реално имаш int на входа и int на изхода и може да се компилира просто като: (a*9 +b)/10

Не, оказа се, че има скрит -fsingle-precision-constant в тая версия на чибито, която ползваме. Което е грешка, оправил си го е човека в по-новите.

Ето тук е описано и що е грешка да се ползва тая опция, нарушава правилата на езика и може да доведе до кофти резултати при някой специфични математики:

https://github.com/ArduPilot/ardupilot/issues/5620

не знам, в случая ще е грешка ако компилаторът не го оптимизира

Ми не го оптимизира. Тоест оптимизира нещо, но пак вика библиотеките за double сметки. Ако я няма въпросната опция. Ако я има вика библиотеките за float (или ползва FPU-то ако е налично).

pPl->dc_ir и dc_ir са int32_t

gcc е версия 6 нещо си, желязото M4F, компилатора е конфигуриран с -mfloat-abi=hard -mfpu=fpv4-sp-d16

На -О2


на -О0



На -О0 -fsingle-precision-constant

А онзи се оплаквахте, че на питона версиите му били досадни....

Е не, тука проблема се оказа в междинния слой. Компилатора се държи адекватно, правилата са стриктни и си ги спазва.

Проблемът е, че 0.1 и 0.9 нямат точно представяне с floating point числа (без значение дали е float или double) и съответно при някои числа ще има разлика с оптимизираният код (ако например го оптимизра до (a*9 +b)/10)

Tакива оптимизации са работа на задклавиатурното устройство, работата на компилатора е стриктно да следва каквото му е подадено като сорс и да оптимизира само там където няма да има странични ефекти.

Аз бих го "оптимизирал" и като (a*7+b)>>3 за да избягам от делението, но само ако това не се отразява на съответния алгоритъм.

Абе за оптимизациите е ясно. Въпроса беше - дробна константа, без спецификатор не се ли приема за double? И ако да, що при мен не се случваше. Намери се обяснението.

Понеже съм запознат с проблема, да си кажа и аз. Добре, че компилаторът не го е оптимизирал, защото резултатът щеше да е грешен. а*9 щеше да препълни размера на типа ( 32 битов без знак е ) и катеричките нямаше да са това, което изглеждат.

Е те затова падат ракетите

Те това би трябвало да не препълва:
(a*9LL +b)/10LL

За по-оптимална компилация може и така:

Това е ясно. За предишното говорехме.

Що зорлен го мъчиш компилатора да се чуди какво си имал в предвид. И кода ти става по труден за четене. Такава оптимизация е платформо зависима, т.е. на процесори които имат хардуерно умножение (т.е. почти всички модерно 16, 32, 64 битово) ще е по бързо да се изпълни една инструкция за умножение отколкото две (преместване и събиране). Модерните компилатори ще се оправят достатъчно добре с оптимизиране на такива сметки там където може и има смисъл. Като бонус ако смениш процесора с друг компилатора ще оптимизира за него, докато ако направиш такава оптимизация му вързваш ръцете винаги да ползва преместване и събиране.

Така е... Някой ден подобни оптимизации излизат през носа, играл съм го и тоя филм.
От друга страна, ако човек работи на определена платформа... както да речем аз последните 20г. може да се каже, че сме вече почти женени
Та в такива случаи, когато по никакъв начин не се очаква генерална смяна си позволявам да се съобразя с конкретната платформа. И само с нея
В случая хардуерно умножение има, но е 32 битово. И което е още по-зле за 64-бит аритметика се разчита на стандартните библиотеки, демек вика се функция с всичките произтичащи негативи от това. Аз даже се учудвам, че по-горе има float аритметики директно без викане на __eabi_.... Или newlib са го пипнали (не знам аз не го ползвам и следя). Но при всички случаи 64-бит шифтване е по-бързо и позволява съчетание със събирането. То и при умножението има multiply and accumulate, обаче ще стане още по-грозно като код.
А другия проблем специално при GCC че не е много гъвкав с типовете. Разчита ти да му ги укажеш, а аз обикновено избягвам в сорса да има двуумене какъв тип трябва да се ползва. Говоря за изрази където трябва да се прецени дали какъв тип са аргументите и какъв тип резултата и т.н. Примерно в случая делението може да е 64 бит /32 бит, което е значително по-бързо от 64/64. Но не съм сигурен в израз дали GCC няма да му хрумне нещо друго, затова - на парче