При работе потребовалась обработка данных типа money. Это 64 битное целое, представляющее дробное число с фиксированным количеством знаков после запятой - 4. Вопрос стоит об оптимизированной библиотеке под IAR. Понятно, что неоптимизированную на С я и сам напишу достаточно быстро.

А встроенный тип signed long long или unsigned long long чем не подходит?
Смотри EWARM_CompilerReference.pdf, Part 2. Compiler Reference, Data Representation, Basic data types.

тем более что вряд ли эти money надо умножать друг на друга? (не представляю рубль в квадрате )
Скорее всего складывать/вычитать, да умножать на количество (т.е. на целое)
Если так то long long вполне рулит, а то и сразу int64_t.

В общем-то это и есть тот тип, базируясь на котором и можно написать нужное. В принципе, остаются только вопросы округления при делении и умножении, поскольку 4 знака после запятой в этих операциях превращаются в 8. Потому и спрашивал уже готвое. Ладно, наверно проще написать.

Спасибо.

Умножать и делить надо. Например, дробное количество умножить на дробную цену.

Если уже собрались писать свою библиотеку для "денежного", рекомендую хранить в BCD-формате - и точность не теряется, и преобразования при печати практически отсутствуют...

А делить то точно надо??

Да. Например, может прийти сумма и количество.
При печати свои заморочки вылазят, превышени размеров окон вывода... Потому бинарный формат мне интегрально удобней.

А кол-во тоже в этом же типе данных?
И кстати какая максимальная сумма возможна?
Знаковый инт64 может хранить ln(2^63)/ln(10) = 18,96488972683 десятичных разрядов.
Если в промежуточном вычислении 8 из них после запятой, то максимальная сумма будет порядка десятков миллиардов. Иначе в промежуточных вычислениях придётся использовать более широкие переменные.
В BCD есть свои плюсы. Но есть и минусы.
Можно ещё поизвращаться, выделив на дробную часть целое число бит (типа 50.14 или 48.16), но тут другой гемор вылезет (типа 5копеек+5копеек=11копеек).


ИМХО вот тут то и может вылезти весь гемор с округлениями. Цена за единицу не всегда совпадёт с исходной.

Я с этими округлениями на финансовых вещах с 93 года столько собак съел, что сыт по горло. Тип money стандартный для виндов и с ним мы уже научились корректно работать, что бы не копить по копейке на старость. Вообще, тут все дробное, и цена и количество и сумма и скидка. А еще есть бухгалтерские правила округления. В конце концов, всегда можно действовать как в старом анекдоте.
Алкаш подходит к продавщице в рюмочной: "Скажите, сколько стоит капля водки" - "Ни сколько" - "Так накапайте мне стаканчик!"

И чё у человека не 8 пальцев на руках?
Считали бы всё в шестнадцатеричке и не жужжали б!