Как правильно использовать в IAR ?
Процессор Texas Instruments CC3200
Хочу присвоить переменной время в наносекундах или микросекундах
пишется какая то лажа - printf ничего не выводит, хотя пытаюсь и %lld и %Ld
компилятор C99 и вроде должен поддерживать все эти вещи

б-р-р, это вообще не причем.
Что стоит в General Options->LibraryOptions->Printf formatter ?

ставил и normal и full - ничего не помогает

1) Какая версия IAR?
2) У IAR несколько библиотек так-что нужно выбрать нужную Вашем случае Full, но кроме этого есть еще отдельные настройки полноты формата printf() - там тоже чего-нибудь типа Full
3) "пишется какая то лажа - printf ничего не выводит" - лажа и ничего, все-же разные вещи.
4) Есть докуменация на конкретный тип контрорллера+компилятора - там есть информация, что поддерживавется, что нет и в каких вариантах библиотек.

с библиотеками возица не стал - просто разбил длинное число на 2 u32 и вывожу
в 16-тиричном виде.
компилятор работает - заполняет переменные правильно.

дело не в компиляторе, а в том, какую версию pfintf из библиотеки он берет (точнее - что за библиотека) - то есть, насколько сложный "парсер" строки формата (то есть размер кода, который разбирает "%4.2f %+.0e %E" ) в этой функции реализован

в микрокотроллере памяти мало и полный формат, как в ман-е написано не всегда поддерживается

сколько не смотрел код сгенерированный ИАРом, то всегда было одно:
SP минус число ( в зависимости от версии FULL LARGE etc ) а потом переход на реализацию принтфа. Никаких проверок "много памяти, мало памяти" чойта не видел.

Это линкер проверит . Полная IAR библиотека совершенно невразумительного количества памяти требует - буквально килобайты. Тупо не влезает. В мелкие контроллеры даже принципиально не лезет.

речь про экономию памяти для кода

Он и поддерживает. Должно быть так:


Остальное по аналогии можно найти самостоятельно. См. например тут или тут.

И лучше отойти от всех этих неопределенных short, long и т.п. В Це99 существуют более внятные типы, вроде uint32_t, uint64_t, int64_t...

Находясь в твердом уме "так" писать не надо. Почему у Автора не получилсь - уже объяснили. По этой причине и использование макросов-оберток вместо явного описания формата ничего не изменит.

Прежде чем лезть умничать, неплохо бы проверить/почитать. В IAR, даже с "правильной" библиотекой, действительно могут не работать %lld и %Ld, при этом PRIu64 работает без проблем. За давностью времени, сейчас уже не помню, на каком из IAR с этим сталкивался, возможно ARM, возможно AVR. Но это факт.

Что у автора получилось - я видел. Костыль, да еще и кривой. Мой вариант - рабочий. Причем в отличии от ворчания отдельных граждан, проверено непосредственно в IAR. Почему "так" писать надо, следует из ссылки, что я дал.



Терминал:

А то, что муть " PRIu64 " есть ни что иное, как макрос-обертка llu это никакой мыслью в Вас в голове не отозвалось?


Так что "проверяй" не проверяй.


Увы, но это бред .

Не сочтите за труд выкинуть муть " PRIu64 " и написать llu и получите точно такой-же рабочий вариант.

Вот на данной, конкретной версии EWARM? Вполне допускаю, что так оно и будет. Но это будет вариант "здесь играем, здесь не играем, здесь рыбу заворачивали"(с), в EWARM работает, в каком-нить EWAVR нет... Меня такой вариант не устраивает. Не хватало еще париться со всякой ерундой. Стандартная библиотека C99 предписывает использовать PRIxxx/SCNxxx? Значит их и буду использовать. Да, мне тоже не нравится и не привычно. Но меня никто не спрашивал.

Пользуйте, если их уродство глаз не режет, только не надо фантазий о их чудодейственной силе.

Я ж сказал, что глаз режет.

А вот за собственным языком лучше следить. На эти "фантазии" день-два убил, пока выяснил. А все претензии и ворчания рекомендую адресовать не мне, а тем, кто занимался стандартной билиотекой. Уверен, они с удовольствием выслушают и примут меры по мотивам этой чрезвычайно конструктивной критики.


Да-да, конечно-конечно. Осталось только самая малость, убедиться, что в _любом_ компилере это выглядит точно так же.

Ну выглядит по разному, например, так:


А знаете почему ВСЕГДА в результате такое для <64bit платформ, а для 64bit просто без ll? Потому, что все эти PRIu64 пишутся в разрыве кавычек текстовой строки. Это из-за того, что это макроподстановка текстовой строки в текстовую строку. И НИКАК иначе. Если-бы эти чудотворящие корявобуквоцифросочетания были-бы не макросами, то все выгдядело:

printf( "ll = %PRIu64\n", ll );

а не:
printf( "ll = %" PRIu64 "\n", ll );

Вот такой прикол
Вообще это просто кое как сделанная "стандартная" заплатка для обеспечения портирования между 32 и 64bit платформами более ни для чего ненужная.

Ага. "Я гарантирую это" (с).

А "не приходило в голову"(с) более очевидное: это для того, что бы _иметь_возможность_ реализовать в виде макроподстановки? Есть гарантия, что всегда и везде это реализовано именно в виде макроподстановки? Гарантия, разумеется, не от zltigo, а нечто более официальное.

И небольшой намек, как может быть реализовано.

О господи. Вот:

Это C99. Официальнее некуда. Советую заглядывать туда иногда прежде чем гнуть пальцы. А то как-то комично получается.

Господи да каким боком-то здесь intrinsic функции. Уж не сочтите за труд без намеков разверуться, так сказать, во всей своей красе и показать все глубины своих представлений о языке.

Вы можете продолжать спорить, но когда после перехода на 64-битную ОС у меня компилятор начал ругаться на printf("%lu", uint64_t_var), который прекрасно собирался на 32-битной системе (поскольку uint64_t из unsigned long превратился в unsigned int), для меня вопрос использования форматных макросов PRIxxx решился сам собой. Еще раньше я накалывался на аналогичное с uint32_t при переносе кода AVR<->PC, но поскольку на AVR я printf использую крайне редко, это не сильно напрягало. Я никого не убеждаю, каждый сам ест свой кактус.

Вопрос ведь не в использовании заплатки, где надо, а в ее использовании где НЕ НАДО и о том, что работа этого чудотворящего макроса НИЧЕМ не отличается от llu в контексте 32bit ARM. Так что твоя реплика не по делу. Ну и по хорошему, а не через заплатку, такой вопрос решается через новые префиксы типа I64, но это пока отдано на откуп компилятору, хотя многие уже поддерживают.

Можно озвучить критерии надо/не надо? Мне очень трудно заранее предугадать - будет код переноситься (хотя бы для тестирования) на другую платформу или нет. Поэтому сразу использую описанный в стандарте путь - PRIxx. Он работает всегда в отличие от. Так же как сразу использую (u)intXX_t, из "голых" типов у меня в программах остался только char для хранения символов. Это тоже описанный в стандарте путь и работает он всегда.

P.S. Я то сначала думал, что придирка к сообщению №10 пошла из-за объявления переменной long long и дальнейшего использования в строке формата PRIu64, т.е. если объявили long long, то и в строке формата надо использовать llu, а если хотим использовать PRIu64, то и переменную надо было объявлять как uint64_t ("Вы или трусы наденьте, или крестик снимите"), а потом смотрю - нет, тут оказывается сам факт использования PRIu64 объявлен ересью. С этим я согласиться не могу.

Ну вот если "трудно", тогда и используй. Мне пока совершенно не тудно предугадывать, что даже пренося для тестирования на 64bit платформу мне незачем компилировать, как 64bit приложение. Зато ломать глаза об эти заплатки, действительно трудно. Ну b на пути портирования printf() и других проблем, типа полноты реализаций , хватает.

С этим проще, чем с printf() - я тоже "голых" типов почти не использую (char и int, int полезен тем, что нативный для платформы и может использован де-факто для всего, чему достаточно от 8 до 16bit ), но и (u)intXX_t в явном виде тоже по причине того, что есть typedef
Ведь проблемы с портированием 8->16->32->64 появилист ЗАДОЛГО до C99. Так что решал я эти проблемы уже 80-x годах и посему у меня с тех пор "свои" типы:
uchar, bint, ushort... Пишется-читается мне легче, а из "проблем" портирования редактирование одного *.h файла, тем более, что все равно часто при смене платформы меняется не только разрядность, и вот просто так ничего совсем не делая не получится. Да и новыми типами все не так радужно. При том-же портировании 8->16 большая пробоема в изобилии 8bit переменных, которых на других платформах 8bit корявы и приводят к тормознутости. Так у меня появилась 'bint', которая для все не восьмибитовых является int. C появлением C99 компиляторов я у себя в хидере заменил ее на "least" - поверил, работает, но оказалось НЕ всегда. Компилятор на свое усмотрение то 8, то 32 бита таки переменные делал. Так что сначала заменил ее на "fast", а потом и обратно на тупой int.

Ересью НЕ объявлен. Просто назван тем, чем он является на самом деле - ЗАПЛАТКОЙ. Примитивной заплаткой для того, что-бы хоть создать какую-то видимость решения ЯВНОЙ ПРОБЛЕМЫ заложенной отцом-основателем языка. Как и ЛЮБУЮ ЗАПЛАТКУ ее надо использовать только в вынужденых случаях, а не где попало, типа на всякий случай.
Такое заплаточное "решение" лежит на поверхности и для его реализации совершенно не требуется C99 компилятора - достаточно любого голого препроцессора. Единственное нормальное решение это ОБЯЗАТЕЛЬНОЕ введение однозначных префиксов.

Я СВОИ дефиниции именно так и реализовал

#define u64 int64_t

итд

Вообще-то это ужасно, когда так пишут.
1) int64_t это никак не unsigned
2) О typedef Автору слышать не приходилось

Для его реализации необходим препроцессор. Но достаточно C99 компилятора, в котором это реализовано совершенно однозначно и одинаково у всех компиляторописателей для всех архитектур. Творить свой велосипед нет никакой необходимости - он будет ничем не лучше. Можно просто посмотреть на календарь и выкинуть уже компилятор, цепляющийся за стандарт 26-летней давности. Уже под все архитектуры существуют компиляторы, поддерживающие 16-летний стандарт.

ну да ошибся
конечно uint64_t

хм, как то странно отработал printf c long long
Нажмите для просмотра прикрепленного файла

P.S. исправил - заработало. Стек задачи для теста забыл выровнять на 8. Топик-стартер, учел это ?

Все с точностью до наоборот. Необходимы изменения в компиляторе.

Компилятор к этой заплатке ни сном ни духом - просто дефайны в хидере заменяющие на классические "u" и "ull". В ранее приведенном примере как раз дефайны из GCC.
Так-что латать можно абсолютно все.

Про "свой" речь не идет, поскольку это должен быть компилятор, но лучше будет тем, что это будет поддерживаться железно, не потребует разборок и коррекций в хидере с тем, каков
сейчас размер int, ну и в конце-концов будет смотреться естественно, без дополнительный "". Минус тоже есть - разборка строки становится больше. Но я все-же за новые форматы типа %I64 и компиляторы их поддерживающие.

К заплаткам компилятор не имеет отношения. А вот то, что за 26 лет так и не ввели в ОБЯЗАТЕЛЬНЫЙ стандарт однозначных форматов, а ограничились заплатками через препроцессор, это печально.

Неужели . Увы, нет . Даже формальное наличие, например, GCC компилятора котрый кто-то сваял, например, под M8C не позволит мне на него перейти с какого-нибудь Image Craft. Ибо отличия в диалекте весьма велики, а в каких-нибудь Intrinsic, да и поросто ASM, просто фатальны. Такая-же история даже с казалось-бы массовыми PIC16 и Hi-Tech компиляторами. Так-что с C99 все не так благостно.

P.S. исправил - заработало. Стек задачи для теста забыл выровнять на 8. Топик-стартер, учел это ?

Для этого есть не менее стандартные типы аля int_fast8_t и int_fast16_t - и сразу из текста программы ясно что было достаточно (двух)байтовой переменной в отличии от char'а / int'а на том же месте.

Не канают. Ибо char как-бы может быть и signed. Правда за такие фокусы с char скорее руки отрывать надо , но тем неменее. Ну а про "fast" я уже писал http://electronix.ru/forum/index.php?showt...t&p=1363201 . Да он в отличие от "least" не замечен был в неоднозначностях, но поскольку писать и читать все эти сложносочиненные типы ломает (других причин нет), то продолжаю использовать уже более 30 лет, свои typedef в специальном хидере, где задаются все нюансы платформы. Что, как уже писал, на самом деле и правильнее для embedded решений, ибо нюансов дофига и кроме разрядности. Ну а для абстракных приложений, там да - достаточно использовать такие сложносочиненные типы.