Создать функцию на ST

[Филоненко Владислав]

Вариант 1.
У вас есть, например, загрузчик и разгрузчик. В каждом из которых - несколько заслонок. Поэтому, макрос заслонка - встраивается по нескольку раз и в загрузчик и разгрузчик. Называется - повторное использование кода - не надо каждую заслонку описывать заново.

Вариант 2.
Та же ситуация. Когда смотришь код загрузчика, сразу видишь несколько заслонок, код которых уже посмотрел, и он не захламляет взгляд. Называется - повысить читаемость кода.

Вариант 3.
Та же ситуация. Вы допустили ошибку в алгоритме работы заслонки. Меняете в одном месте и уверены, что не пропустите это исправление где-то среди заслонок загрузчика и разгрузчика. Не помню, как это называется )

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

Хм. Повторное использование кода это когда один экземпляр кода вызывается из разных мест.
В случае макросов N экземпляров кода (пусть и одинакового) вызываются каждый раз отдельно. Т.е. программа в N раз больше и несколько медленнее (т.к. Cache Miss чаще возникает).
Не путаем ФБ/Функции в ST и макросы ОЛ

[keysansa]

Хм. Повторное использование кода это когда один экземпляр кода вызывается из разных мест.
В случае макросов N экземпляров кода (пусть и одинакового) вызываются каждый раз отдельно. Т.е. программа в N раз больше и несколько медленнее (т.к. Cache Miss чаще возникает).
Не путаем ФБ/Функции в ST и макросы ОЛ

Не путаем. Код - он бывает и текстовый и исполняемый. Если знакомы с С, это как вызов обычной функции, и вызов той же функции Inline. И в том и в другом случае, есть повторное использование кода. В разных случаях - для разных задач. В случае inline - для быстродействия, в случае обычной функции - для экономии.
Но изменив код в одном месте - он поменяется при всех вызовах - смотрим снова на все пункты.

ЗЫ. "Убегание кэша" вам вообще ничем не грозит, так как:
1. Вы его не получите, так как булева алгебра очень близка к машинному коду = компактна. Даже при использовании строк.
2. Чем код менее оптимизирован компилятором под размер (меньше переходов, линейный), тем он больше но и быстрее исполняется, так как меньше операций PUSH, POP.
2. Даже, если, вдруг, каким-то чудом, получите множественную очистку кэша, вас, как программиста автоматики, это не должно волновать. Так как у вас есть отведенное технологическим оборудованием время цикла, например, 10мс. И пока вы из него не выбиваетесь - остальное не важно. Прогармма должна выполнить цикл менее или равно, чем за отведенное время. Если нужны короткие циклы, то для этого придумали ПЛИС (я месяца 3 назад решил поизучать - просто восторге от их быстродействия).

[Филоненко Владислав]

Не путаем. Код - он бывает и текстовый и исполняемый. Если знакомы с С, это как вызов обычной функции, и вызов той же функции Inline. И в том и в другом случае, есть повторное использование кода. В разных случаях - для разных задач. В случае inline - для быстродействия, в случае обычной функции - для экономии.
Но изменив код в одном месте - он поменяется при всех вызовах - смотрим снова на все пункты.

ЗЫ. "Убегание кэша" вам вообще ничем не грозит, так как:
1. Вы его не получите, так как булева алгебра очень близка к машинному коду = компактна. Даже при использовании строк.
2. Чем код менее оптимизирован компилятором под размер (меньше переходов, линейный), тем он больше но и быстрее исполняется, так как меньше операций PUSH, POP.
2. Даже, если, вдруг, каким-то чудом, получите множественную очистку кэша, вас, как программиста автоматики, это не должно волновать. Так как у вас есть отведенное технологическим оборудованием время цикла, например, 10мс. И пока вы из него не выбиваетесь - остальное не важно. Прогармма должна выполнить цикл менее или равно, чем за отведенное время. Если нужны короткие циклы, то для этого придумали ПЛИС (я месяца 3 назад решил поизучать - просто восторге от их быстродействия).

быстродействие получают с inline за счёт убирания преамбулы и выхода из функции. Но это работает за счёт размера кода и в какой-то момент код, 100% попадающий в кэш вылазит за него и тут, вдруг, в 3-4 раза начинает медленнее выполняться. И вся "оптимизация" идёт в пустыню Наска. Так что утверждать, что в ПР макросы быстрее функций можно на какой-нибудь нанопрограмме. А вот на больших проектах это не так.