Инлайновая функция Опции

[Jenya7]

Если я определяю функцию как инлайн

Код

файл .h
inline uint32_t SYSTIME_GetSystemTime(void);
файл .с
inline uint32_t SYSTIME_GetSystemTime(void)
{  
    //do something
}

то при вызове функции IAR ругается Error[Li005]: no definition for "SYSTIME_GetSystemTime"
то есть функцию надо разместить в .h файле по другому никак?

Сообщение отредактировал Jenya7 - Jul 5 2018, 10:37

[VladislavS]

Начиная с C++11 в каждой новой спецификации добавляются всё новые возможности выполнения кода на этапе компиляции. Это сейчас модно, а не инлайны, с которыми компиляторы уже давным-давно научились сами разбираться. Попереключайте настройки оптимизатора и посмотрите результаты компиляции. Адептам секты пресвятого инлайна смотреть результат оптимизации с ключом Size на максимуме не рекомендую , чтобы при виде сплошного антиинлайна не возникли суицидалные мысли.

Сейчас мэинстрим чтобы программа вообще не порождала run-time кода Модно написать программу на несколько страниц и получить пару ассемблерных команд. Даже соревнования проходят кто больше кода на этапе компиляции выполнит.

И тут очередной такой ТС с давно уже неактуальным инлайном на белом коне въезжает. Совет ТС - если у вас есть место где не проходите по скорости, а иначе зачем гнаться за инлайном, то лучше перепишите этот кусок более оптимально наблюдая за результатом компиляции. Может даже с уходом в ASM. Но надеяться на инлайн не стоит. Даже если вы директиву принудительного инлайна поставите, компилятор может её проигнорировать. Не из вредности, а из-за продвинутости оптимизатора.

Кстати, приёмов оптимизации в арсенале компилятора очень много, но почему-то только инлайн так волнует души неокрепших программистов Почему вас раскручивание циклов вообще не волнует, а?

[jcxz]

Почему вас раскручивание циклов вообще не волнует, а?

Это точно
Мне здесь на форуме один товарищ недавно рассказывал и пытался убеждать, что копирование через memcpy() в любом случае быстрее, чем написать это копирование простым циклом на си. Сколько я ему не намекал, что оптимизирующий компилятор может и этот цикл и даже саму memcpy(!) раскрутить в несколько ассемблерных инструкций (в зависимости от размера пересылки, выравниваний и известности параметров пересылки на этапе компиляции), а может и то и другое заменить просто оптимальным циклом с копированием внутри - так и не убедил его. Он только обиделся. Он приводил в доказательство какие-то частные случаи, в определённых созданных им условиях.
Так он и не понял, что при включении максимальной оптимизации и чем лучше и продвинутее компилятор, тем результат будет больше зависеть от реализуемого действия (алгоритма), а не от способа его реализации (цикл-ли, инлайн или даже memcpy).
Так и ТС здесь - уверен что что-то зависит от того, с inline он напишет функцию или без.
Так что как я неоднократно убеждался - понимание принципов работы оптимизаторов ускользает от основной массы программистов, сколько не описывай это в мануалах. Ну и в результирующий ассемблерный код тоже как видно мало кто смотрит и понимает его. Иначе бы даже без мануалов всё было понятно.

PS: Кстати - вдогонку, в тему: Иногда возникает желание сказать компилятору (IAR в частности), чтобы он не inline-ил функцию. Так это сделать посложнее чем сказать inline.
А вот сделать функцию жёстко "не inline" вне зависимости от работы оптимизатора - это имхо гораздо полезнее чем сделать её inline.

[scifi]

Мне здесь на форуме один товарищ недавно рассказывал и пытался убеждать, что копирование через memcpy() в любом случае быстрее, чем написать это копирование простым циклом на си. Сколько я ему не намекал, что оптимизирующий компилятор может и этот цикл и даже саму memcpy(!) раскрутить в несколько ассемблерных инструкций (в зависимости от размера пересылки, выравниваний и известности параметров пересылки на этапе компиляции), а может и то и другое заменить просто оптимальным циклом с копированием внутри - так и не убедил его. Он только обиделся. Он приводил в доказательство какие-то частные случаи, в определённых созданных им условиях.

Был случай, когда хотелось, чтобы memcpy был маленький и медленный. Скорость не нужна, а байтов жалко. Библиотечный memcpy шибко умный, видимо. Ускоренный настолько, что весит сотни байт :-( Хоть заменяй своим.

PS: Кстати - вдогонку, в тему: Иногда возникает желание сказать компилятору (IAR в частности), чтобы он не inline-ил функцию. Так это сделать посложнее чем сказать inline.
А вот сделать функцию жёстко "не inline" вне зависимости от работы оптимизатора - это имхо гораздо полезнее чем сделать её inline.

Очевидно же: взять адрес функции, загнать его в указатель volatile, не? И вызывать через этот указатель для верности.

[jcxz]

Был случай, когда хотелось, чтобы memcpy был маленький и медленный. Скорость не нужна, а байтов жалко. Библиотечный memcpy шибко умный, видимо. Ускоренный настолько, что весит сотни байт :-( Хоть заменяй своим.

Когда хочется иметь определённый ассемблерный результат, вне зависимости от умности компилятора, то есть только один надёжный выход - ассемблер. И не нужно его бояться.

Очевидно же: взять адрес функции, загнать его в указатель volatile, не? И вызывать через этот указатель для верности.

Не уверен что это прокатит с любым компилятором. Да, указатель он создаст, и пожалуй даже поставит команду LDR Rx, указатель. Но кто дальше ему мешает просто вставить код функции? Ведь все условия volatile указателя он уже выполнил: создал его, и чтение его выполнил.

PS: Про #pragma inline=never знаю и его сейчас и использую в IAR. Но это компиляторо-зависимо.

[demiurg_spb]

А в IAR разве нет атрибутов наподобие gcc и keil?
У меня написан compiler.h в котором все нюансы компиляторов запрятаны. Типа

Код

#if defined(__GNUC__)
#      define __is_always_inline   __inline__ __attribute__((__always_inline__))
#endif

А пользовательский код никаких специфических вещей компиляторов не использует - только свою прослойку.

Код

static __is_always_inline void foo(void)
{
    // do something
}

ИМХО прагмы в коде последнее дело...

[jcxz]

А в IAR разве нет атрибутов наподобие gcc и keil?

Атрибутов не знаю, знаю только прагмы. И тогда Ваш compiler.h - неверный.

ИМХО прагмы в коде последнее дело...

Согласен. Но я не знаю другого способа явно указать IAR-у - инлайнить или нет.

[VladislavS]

Но я не знаю другого способа явно указать IAR-у - инлайнить или нет.

Не знаю с какой версии, но

In extended language mode, the IAR C/C++ Compiler also supports a limited selection
of GCC-style attributes. Use the __attribute__ ((attribute-list)) syntax for
these attributes.
The following attributes are supported in part or in whole. For more information, see the
GCC documentation.
● alias
● aligned
● always_inline
● cmse_nonsecure_call
● cmse_nonsecure_entry
● constructor
● deprecated
● noinline
● noreturn
● packed
● pcs (for IAR type attributes used on functions)
● section
● target (for IAR object attributes used on functions)
● transparent_union
● unused
● used
● volatile
● weak

[demiurg_spb]

Немного погуглив нашёл _Pragma(...)

Код

#ifdef IAR
        #define NO_OPT _Pragma ("optimize=none")
#endif

NO_OPT void some_func(void)
{
…
}