Код
inline bool Timer_check(void) {
return (TIM6->SR); // Check Update Interrupt Flag in Status
}
return (TIM6->SR); // Check Update Interrupt Flag in Status
}
С inline, кстати, не компилируется.
Или надо было ее написать в виде макро?
Полная версия этой страницы: Можно ли задать inline функцию, если она определена в другом файле?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > Keil
Об этом уже говорили, и выходит, что нельзя. Или все же есть способ? Или компилятор (Keil для Cortex) не дурак, сам встроит функцию, если она окажется небольшой? Например, такой:
С inline, кстати, не компилируется.
Или надо было ее написать в виде макро?
С inline, кстати, не компилируется.
Или надо было ее написать в виде макро?
Цитата(ViKo @ Nov 15 2012, 15:40) 
Или надо было ее написать в виде макро?
Написать static inline и расположить в .h файле
а как компилятор узнает, какой код ему инлайнить?
в h файле ее можно описать и инклюдить и в этот файл и в другой
в h файле ее можно описать и инклюдить и в этот файл и в другой
Если последний вопрос ко мне, то у меня есть заголовочный файл (упрощенно говоря) fun.h, который подключается к main.c файлу, и где был описан прототип функции:
bool Timer_check(void);
А если добавить inline и к прототипу, и к определению функции, то не компилируется.
А если всю функцию перенести в заголовочный файл fun.h, то работает, независимо, static или без... только размерчик получился больше (!), чем когда функция была определена в fun.c файле. Code = 29744 вместо 29224.
upd. не ту функцию показал, поправил.
P.S. А если добавляю inline только к прототипу или к определению, то компилируется, но уже с размером 29232!
(А-а-а-а-а! зачем же я пьянствовал вчера, надо было бы сегодня!)
bool Timer_check(void);
А если добавить inline и к прототипу, и к определению функции, то не компилируется.
А если всю функцию перенести в заголовочный файл fun.h, то работает, независимо, static или без... только размерчик получился больше (!), чем когда функция была определена в fun.c файле. Code = 29744 вместо 29224.
upd. не ту функцию показал, поправил.
P.S. А если добавляю inline только к прототипу или к определению, то компилируется, но уже с размером 29232!
(А-а-а-а-а! зачем же я пьянствовал вчера, надо было бы сегодня!)
Цитата(ViKo @ Nov 15 2012, 15:10)
размерчик получился больше (!), чем когда функция была определена в fun.c файле. Code = 29744 вместо 29224.
Дался Вам этот кейл... В ГЦЦ
Код
static inline __attribute__((always_inline)) void somefunc(const int argument)
И всё. Ничего не растет без спроса у хозяина битов
Цитата(_Pasha @ Nov 15 2012, 14:34)
Дался Вам этот кейл... В ГЦЦ
Но функция в другом файле находится не может?
Цитата(_Pasha @ Nov 15 2012, 15:34)
Дался Вам этот кейл... В ГЦЦ
И в Keil есть такие штуки (эквивалентны):
__attribute__((always_inline))
__forceinline
Добавляются к прототипу функции.
Цитата(ViKo @ Nov 15 2012, 17:15)
И в Keil есть такие штуки (эквивалентны):
__attribute__((always_inline))
__forceinline
Добавляются к прототипу функции.
__attribute__((always_inline))
__forceinline
Добавляются к прототипу функции.
это к функциям в файле относится, у gcc тоже есть always_inline
http://gcc.gnu.org/onlinedocs/gcc/Inline.html
Цитата(ViKo @ Nov 15 2012, 16:10)
Если последний вопрос ко мне, то у меня есть заголовочный файл (упрощенно говоря) fun.h, который подключается к main.c файлу, и где был описан прототип функции:
для инлайна ему нужен не прототип, а код функции. вопрос был риторический
я для каких-то извращенных архитектур, где вообще стека нету, сталкивался с тем, что инлайлинье делает линкер при сборке "экзешника", но это исключительное извращение, по-моему в нынешних компиляторах нет такой фазы, чтобы шарится по всем объектникам и искать там коды для инлайнов
-----------
btw: static к определению фукнции (или переменной) дописывают чтобы не загаживать пространство имен, она как бы локальная получается и линкер такой функции не видит (это для больших проектов полезно)
у фукнции или не стековой (обычно называют глобальной) переменной это больше ни на что не влияет.
Цитата(yes @ Nov 15 2012, 16:23)
это к функциям в файле относится, у gcc тоже есть always_inline
А зачем они тогда вообще нужны, чем inline не годится?
А, наверное, задавать принудительно, даже если это и не оптимально.
Цитата(ViKo @ Nov 15 2012, 17:27)
А зачем они тогда вообще нужны, чем inline не годится?
А, наверное, задавать принудительно, даже если это и не оптимально.
А, наверное, задавать принудительно, даже если это и не оптимально.
Патамушо always_inline не помещает тело функции в объектник если функция ни разу не вызывалась. А без него - помещает.
Цитата(_Pasha @ Nov 15 2012, 17:40)
Патамушо always_inline не помещает тело функции в объектник если функция ни разу не вызывалась. А без него - помещает.
объектник - это одно. Линкер разве помещает ее в код, если она не вызывалась ни разу?
Цитата(toweroff @ Nov 15 2012, 20:53)
объектник - это одно. Линкер разве помещает ее в код, если она не вызывалась ни разу?
Я неправильно выразился.
Инлайнит независимо от уровня оптимизации, так по стандарту.
Цитата(yes @ Nov 15 2012, 17:27)
по-моему в нынешних компиляторах нет такой фазы, чтобы шарится по всем объектникам и искать там коды для инлайнов
Не совсем так. Есть режим компиляции (в gcc он называется LTO, в других компиляторах whole program optimization или нечто подобное), который позволяет заинлайнить функцию, даже если ее тело находится в другой единице компиляции и даже если ей там inline не писали.Но реализуется это конечно не поиском кода в объектниках (в этом режиме в объектниках вообще кода может и не быть)
Цитата(ViKo @ Nov 15 2012, 16:10)
А если всю функцию перенести в заголовочный файл fun.h, то работает, независимо, static или без...
Стоит подключить fun.h к нескольким модулям, и сразу станет понятен смысл static.
Без него линкер выдаст ошибку "Multiple definition" - одноименный объект создается в разных модулях.
Цитата(MrYuran @ Nov 16 2012, 13:33)
Стоит подключить fun.h к нескольким модулям, и сразу станет понятен смысл static.
Без него линкер выдаст ошибку "Multiple definition" - одноименный объект создается в разных модулях.
Без него линкер выдаст ошибку "Multiple definition" - одноименный объект создается в разных модулях.
Это заменяет
Код
#ifndef FUN_H
#define FUN_H
...
#endif
#define FUN_H
...
#endif
?
не совсем
Вам уже про LTO советовали, а я повторюсь, что и у Кейла есть галочка типа "link-time code generation" - это фактически аналог LTO от gcc.
В таком режиме все функции рассматриваются компилятором как static...
Вам уже про LTO советовали, а я повторюсь, что и у Кейла есть галочка типа "link-time code generation" - это фактически аналог LTO от gcc.
В таком режиме все функции рассматриваются компилятором как static...
Цитата(demiurg_spb @ Nov 16 2012, 14:19)
не совсем
Вам уже про LTO советовали, а я повторюсь, что и у Кейла есть галочка типа "link-time code generation" - это фактически аналог LTO от gcc.
В таком режиме все функции рассматриваются компилятором как static...
Вам уже про LTO советовали, а я повторюсь, что и у Кейла есть галочка типа "link-time code generation" - это фактически аналог LTO от gcc.
В таком режиме все функции рассматриваются компилятором как static...
Не галочка - опция.
Цитата
--ltcg
This option instructs the compiler to create objects in an intermediate format so that Link-Time Code Generation (LTCG) optimizations can be performed. The optimizations applied include cross-module inlining to improve performance, and sharing of base addresses to reduce code size.
Note
This option might significantly increase link time and memory requirements. For large applications it is recommended that you do the code generation in partial link steps with a subset of the objects.
The LTCG feature is deprecated. As an alternative ARM recommends you use the --multifile option.
Example
The following example shows how to use the --ltcg option.
armcc -c --ltcg file1.c
armcc -c --ltcg file2.c
armlink --ltcg file1.o file2.o -o prog.axf
This option instructs the compiler to create objects in an intermediate format so that Link-Time Code Generation (LTCG) optimizations can be performed. The optimizations applied include cross-module inlining to improve performance, and sharing of base addresses to reduce code size.
Note
This option might significantly increase link time and memory requirements. For large applications it is recommended that you do the code generation in partial link steps with a subset of the objects.
The LTCG feature is deprecated. As an alternative ARM recommends you use the --multifile option.
Example
The following example shows how to use the --ltcg option.
armcc -c --ltcg file1.c
armcc -c --ltcg file2.c
armlink --ltcg file1.o file2.o -o prog.axf
Из галочек есть
Use Cross-module optimization
Понял, нужно читать помощь по Кейлу!
Цитата(ViKo @ Nov 16 2012, 14:41)
Это заменяет
?
?
Нет, это просто защита от повторного включения внутри единицы компиляции, коей является c/cpp файл.
аналог #pragma once
А речь идет о включении в разные модули, которые скомпилируются независимо и без вопросов, а в результате в разных объектных файлах окажутся одинаковые имена объектов, и уже линкер начнет вопить.
Цитата(MrYuran @ Nov 16 2012, 14:57)
Нет, это просто защита от повторного включения внутри единицы компиляции, коей является c/cpp файл.
аналог #pragma once
А речь идет о включении в разные модули, которые скомпилируются независимо и без вопросов, а в результате в разных объектных файлах окажутся одинаковые имена объектов, и уже линкер начнет вопить.
аналог #pragma once
А речь идет о включении в разные модули, которые скомпилируются независимо и без вопросов, а в результате в разных объектных файлах окажутся одинаковые имена объектов, и уже линкер начнет вопить.
То, что я показал, позволяет мне в одном общем file.h собрать заголовочные файлы для всех составляющих проекта, и потом подключать только его во все files.c.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.