Есть одна большая функция в программе - которую можно поделить на много мелких ...
Вопрос как выгоднее по скорости исполнения - разделить ее на 18 мелких (по смыслу) или оставить как есть?

Если мелкие сделать принудительно встраиваемыми - то по скорости будет одинаково. А читаемость исходника повысится.

А если и не делать - может, ничего страшного и не произойдёт.
(какая разница, сколько процессор бездельничает в цикле IDLE - 97 или 98%..)

Эээ про Idle можно поподробнее?

ps эта функция исполняется раз в секунду но - ее исполнение может быть критичным по скорости ибо после нее идет обработка буфера uart (если он получил маркер - передача окончена) и посылка ответа

Я обычно большую массивную функцию (например, обсчёт данных с логарифмами, фильтрацией и формулами на полстраницы) делю на множество мелких подзадач, вешаю их на стейт-машину и запускаю всё это в общем цикле.
То есть, при каждой следующей итерации выполняется следующая подзадача, а в конце вся система переходит в IDLE.
В результате время отклика в общем суперцикле существенно уменьшается, а требования к быстродействию вычислений снижаются.

Естественно, это всё при отсутствии RTOS.

богатая идея...
надо обмуслить...
тока общаяя схема у меня порушится т.к. 1 секундный маркер....
и втом теле еще несколько обработчиков...

Ничего не порушится.
Маркер пусть запускает процесс.
Вот для затравки:


CalculateParameters() вставляете в общий суперцикл, флажок TimeToCalc запускает процесс и обнуляется в конце.
Хотя, можно его "вынести за скобки"... Вариаций множество.

И нафига оно такое надо?


И где тут Protothreads, который я "при каждом удобном случае пиарю" ? ЫЫЫ!

Достаточно их сделать статическими и компилятор их сам встроит если они вызываются лишь по разу.
2ТС:
Разбивайте всё по функциям на отдельные законченные логические блоки, чтобы была видна структура и прозрачны взаимосвязи.
Размер кода при этом не увеличиться ни на йоту.

размер кода пока не пугает ...
оперативки уже мало 95% занято (структурой данных и 2мя буферами uart) ... тока на стэк как я понимаю осталось
с ассемблером я практически не знаком - но каждый вызов функции это прыжок по коду - занимающий циклы процессора если я не ошибаюсь
но если написать что она- inline без static то она интегрируется в то место где вызывается?

Static inline делается для того, чтоб описать в хедере - тогда нету разницы, где и сколько раз оно описано. Все равно будет при вызове встроено

Не всегда, а по усмотрению компилятора.

Для всех функций не представленных в интерфейсе модуля (использующихся внутри одного модуля, иначе говоря файла) считается правилом хорошего тона присваивать квалификатор static. Это сообщает компилятору о возможности встраивания кода функции при оптимальных на его взгляд условиях. А компиляторы нынче весьма и весьма умные.

Использовать квалификатор inline имеет смысл лишь для замены макросов функциями по большей части в заголовочных файлах.

Придерживаясь этих нехитрых правил можно получить не только оптимальный но и самодокументированный код.

Для гарантированного встраивания функции при любых условиях можно использовать особенности различных компиляторов.
В gcc например есть механизм атрибутов:
В других компиляторах используют механизм #pragma ...
Альтернатива - вечно зелёные и неувядающие макросы на все времена года:-)

static inline - не компилируется... пишет что линкер не нашел функций...
inline - все нормально работает
в чем подвох?

1. static inline функцию надо писать в h-файле, который надо подключить (#include) туда, где она будет вызываться

2. Пример написания static inline функции в h-файле (WinAVR)

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




Можно и в .c, но только "для внутреннего употребления"
Короче говоря, static объявление действительно только внутри модуля, в котором оно объявлено.

еще раз для тупого...
чем лучше static inline
по сравнению с просто inline?

Есть поверье, что оптимизируется лучше, т.к. все связи у компилятора на виду и ему не надо подразумевать возможности внешних вызовов

меня интересует встроится ли код или нет если оставить просто inline ( все эти функции я вывел в отдельный файл и обозвал с inline)

ps про поверье это пять...

Это надежда, а не поверье. Пока что с оптимизацией как раз "болезни роста"

Встроится или нет.
Я же Вам написал что нужно сделать чтобы всегда встраивалось.
Вы что-то не смогли осознать?

Думается что это бесконечная болезнь, во всяком случае хочется в это верить.

В общем случае нет гарантированного способа "заставить" компилятор встроить inline функцию. Может встроить, а может - нет. Все пляски с прагмами и атрибутами повышают вероятность встраивания.

C++, C99, and GNU C each have support for inline functions. Different compilers vary in how complex a function they can manage to inline. Mainstream C++ compilers like Microsoft Visual C++ and GCC support an option that lets the compilers automatically inline any suitable function, even those not marked as inline functions.

выдержка из википедии (может конечно врут...) но про static ни слова....
про статик более менее понятно стало из другой статья .....что это локальные функции
но честно говоря все очень запутано.....

А что Вам мешает объявить функцию в разных вариантах и самому понять, что почём? И не мучать людей, не являющихся преподами.

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

имхо:
Результат в моем случае проверить сложно т.к. размер кода - будет один и тотже -функции используются по разу
а скорость отклика - уарта мне точно померять пока не представляется возможным - точность +/- 1 ms уже не устроит

а вот результат по разбиению исполнения массива данных - был виден и дал выигрыш как раз ~1ms - спасибо за наводку

Всем спасибо дальше как говориться куда кривая выведет

Всегда есть варианты решения задачи. Самое главное найти в своей программе "буталочное горлышко", тогда его можно расширить десятком разных способов.

Если вы удовлетворены своими inline изысками - отлично. Но вы, наверное, поняли, что это вариант слегка от лукавого. Я к тому, что вы в данном случае не на 100% контролируете ситуацию. А это не есть хорошо.

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

С чего такой пессимизм?
Насколько я знаю если в gcc дал атрибут, так он отрабатывает по полной.
Не встречалось в моей практике исключений (я сейчас про gcc только говорю).
Приведите примерчик кода с листингом для убедительности.

Если разить вашу теорию, то и данные предназначенные для помещения в секции EEPROM (это при помощи атрибутов в gcc происходит) ИНОГДА могут оказаться в другой секции.
Это абсурд!

Поспокойнее сэр!

Это не моя теория.

Читаем, например, http://msdn.microsoft.com/en-us/library/z8...=vs.80%29.aspx:




чуть ниже:

У микрософта сносная документация, но не лучшие компиляторы.
Если по теме, то надо приводить выдержки из "С99".
В gcc насколько помню есть атрибут с говорящим названием always_inline.
На моей практике при "-O3" даже inline в большинстве случаев указывать не надо, само автоматически встроится.

Да ладно уж! А на чем написано большинство программ под windows всех мастей? По крайней мере их компиляторы достаточно прогнозируемо себя ведут.

Само указание ключевого слова inline в декларации функции является подсказкой/предложением компилятору встроить тело функции в точке вызова. Но компилятор имеет полное право сделать по своему усмотрению. Это стандартное поведение.

Некоторые компиляторы вводят расширения (само собой нестандартные) для управления поведением компилятора. Про GCC уже сказали выше, у IAR в документации недвусмысленно сказано:

Т.е. при использовании этой прагмы компилятор обязан встроить функцию. Если он не может по техническим причинам этого реализовать, он должен выдать сообщение об ошибке. Это весьма полезное свойство для embedded области применения.

Что характерно - чем вопрос элементарнее, тем дискуссия более оживленная

А это всё в точности по Паркинсону ("Законы Паркинсона", занятная книжка). Там был на эту тему пример про обсуждение на совете директоров трех вопросов: 1. про приобретение какого-то очень дорогостоящего оборудования (на миллионы); 2. строительство навеса для стоянки велосипедов сотрудников; 3. сколько стаканчиков для кофе класть в кофейный автомат. По первому вопросу затраты времени 10 минут, по второму - минут 40, и по третьему - три часа. Объяснение логичное: чем проще вопрос, тем больше народу в нём разбирается. И у каждого есть мнение.

Кстати, вопрос про инлайны не такой простой для начинающих, как может показаться. Инлайновые функции должны удовлетворять ряду требований, и для них делаются определённые послабления. Кроме того, обсуждаемые расширения тоже несут с собой часть нюансов использования. Поэтому я бы не считал обсуждение всего этого ненужным.

Ну так забейте на inline если оно настолько некритично для вашего проекта.
Кстати inline'нинье функций далеко не гарантия наиболее высокой скорости исполнения. Например, в процессорах с кеш памятью команд - бездумное инлайнинье там и сям приведет только к замедлению за счет раздувания кода при константном объеме кеш памяти.


обилие прагм и атрибутов в проекте - это говнокод, а не абсурд, и - кстати таки да данные могут оказаться совсем не в той секции где ожидаешь, при переносе такого проекта на другой проц.

Идеологически согласен.
Кстати, Вы видели в моём примере много прагм и атрибутов?
Человек спросил как это сделать - я дал однозначный рецепт.
Потом сюда приплели даже микрософтовский компилятор и кеш инструкций, хотя тема находится в подфоруме микроконтроллеры/AVR
и вопрос касался avr-gcc...

Какие Ваши предложения на сей счёт? Отказаться от использования PROGMEM, EEMEM, ISR и вообще не включать компьютер?
Атрибуты в gcc - это почти что основополагающий механизм в случае кросс-компиляции для avr.
Если Вы внимательно читали мои посты, то могли бы подметить, что я рекомендовал оставить лишь квалификатор static, ибо это и необходимо и достаточно для локальных функций.

Да static для локальных функций это просто "хороший тон", чтобы не "заси...ть" пространство имен большого проекта, а вовсе не какая-то необходимость. С одной стороны - хорошо, с другой, их не найдешь в map файле, если понадобится найти точку зависания программы. То, что static - помощь компилятору в деле инлайнинга, вопрос спорный. В одном компиляторе может так, в другом этак.

Повторюсь, я говорю о avr-gcc и о контроллерах в которых флеша всегда маловато и рассуждать о удобстве поиска "зависшей программы" мне лично и в голову не приходит. Отладка через консоль на 99 процентов решает любые непонятки, а остальное решается просмотром asm листинга если терзают сомнения в качестве компилятора или в качестве собственной черепушки - что тоже надо признать бывает:-) Это моё ИМХО.

Что-то мы уже по второму кругу пошли...

Это очень хорошо, что вы знаток avr-gcc. Но я все равно не понимаю, какое отношение имеет объявление локальной функции как static к объему flash памяти на борту. Что это дает на практике? Расскажите, поделитесь сокровенным.

В gcc, да и думаю во всех современных компиляторах, идёт однозначное встраивание статической функции если она вызывается лишь один раз и отсутствует её вызов по указателю. Также статическая функция, которая при встраивании сопоставима по сложности с загрузкой аргументов, выполнении инструкций call+ret и выгрузкой её результата, может быть встроена даже при неоднократном её вызове. Естественно баланс оптимизации сильно зависит от грамотности настроек компилятора. Вся эта оптимизация на круг даёт существенный выигрыш как по объёму так и по скорости, за что собственно и ратую.

Про все современные компиляторы, как выше упоминалось, это вовсе не факт. А раз это так устроено для AVR - намотаем на ус.

Вообще многие гуру программирования отмечают, что хорошим стилем является написание коротких функций. Компилятор сам может потом решить встраивать их или нет. Да и их тело оптимизировать проще.

+1
В любом случае, чем меньше повторений кода - тем меньше ошибок, ибо исправления вносятся только один раз. А вложенность статиков пугать не должна, вот с количеством передаваемых параметров - это да, надо с ним воевать.

ИМХО
Разделяется по функциональности. Например функция:
check_port_a() {
i2c_byte_read();
uart2_send_data();
}
на мой взгляд выглядит не плохо.
Что плохо бы смотрелось, это пример:
check_port_a() {
start_i2c_bit();
set_i2c_address();
set_i2c_cmd_byte();
get_i2c_byte();
stop_i2c_bit();
uart2_send_data();
}

По скорости будет примерно одинаково.

Небольшая поправочка:
Это устроено в gcc вообще и в avr-gcc в частности.

Свет клином на gcc не сошелся. Он, конечно, не стоит на месте, но заморочек с ним все равно хватает.

Каких?