Самомодифицирующийся код в экосистеме Cortex-M., есть ли право на жизнь? Опции

[jcxz]

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

PS: И пожалуйста - без религиозной нетерпимости.

[Arlleex]

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

Код

while(условие)
{
    if(условие 1)
        инструкция 1;

    if(условие 2)
        инструкция 2;

    if(условие 3)
        инструкция 3;

    ...

    if(условие N)
        инструкция N;
}

Так вот, условие 1, условие 2, условие 3, ..., условие N являются флаговыми переменными и определяются где-то выше по коду. В итоге ассемблерный код будет содержать условные операции выполнения и переходы, если инструкции не представляются в машинных кодах до 4 реальных инструкций для Cortex-M. Это долго, на это тратятся такты процессора, сбрасывается конвейер инструкций... в общем, одни минусы. В приложениях с хитрой математикой или логикой, которую надо быстро просчитать, было бы удобно использовать СМК в следующем виде:
1. Просчитать все условные флаги.
2. На основании этих флагов сформировать СМК-последовательность инструкций без условных инструкций.
3. Отдать эту последовательность на выполнение.

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

[adnega]

1. Просчитать все условные флаги.
2. На основании этих флагов сформировать СМК-последовательность инструкций без условных инструкций.
3. Отдать эту последовательность на выполнение.

Простите, а пункты 1 и 2 не требуют тактов разве?

[Arlleex]

Так тут будет тот же
if()...if()...if()...

Нет, не будет.

Простите, а пункты 1 и 2 не требуют тактов разве?

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

Код

while(условие)
{
    if(условие 1)
        инструкция 1;
    if(условие 2)
        инструкция 2;
    if(условие 3)
        инструкция 3;
}

Как видно, будут всегда выполняться инструкции, реализующие условия проверки внутри if(...).
Если применить СМК, и вычислить условия в if(...)-ах до цикла, то в ОЗУ построится, допустим, следующий код (примем, что условия 1 и 3 истинны)

Код

while(условие)
{
    инструкция 1;
    инструкция 3;
}

Или же, если все условия истинны, то

Код

while(условие)
{
    инструкция 1;
    инструкция 2;
    инструкция 3;
}

Или же, если первое условие истинно, то

Код

while(условие)
{
    инструкция 1;
}

Как видно, в любом случае нет больше в цикле инструкций проверки условий в if(...)-ах (а они же ведь по сути Bxx в ассемблерном представлении) (да и куда лучше вовсе не проверять заранее ложные условия по списку), а выполняются только нужные инструкции сразу, как будто условных конструкций и нет. А п. 1 и 2, конечно, требуют тактов, только для моего случая п. 1. требуется выполнить только 1 раз для всех итераций цикла, на этапе составления списка инструкций СМК.
Надеюсь, моя мысль будет так понятнее.

Сообщение отредактировал Arlleex - Jun 29 2018, 16:23

[adnega]

Надеюсь, моя мысль будет так понятнее.

Условия в рантайме меняются или нет?
Если нет, то компилятор сам выкинет заведомо ложные и исполнит заведомо истинные условия.
А если они меняются в рантайме, то и ваш генератор СМК должен все эти условия проверить,
сгенерить год и исполнить его.
По моему, даже если вы выиграете на исполнении СМК, то скорее всего проиграете на подготовке СМК.

[Arlleex]

Условия в рантайме меняются или нет?

Конечно меняются. Это обычные переменные, которые взводятся/сбрасываются где-то выше по коду или вовсе в других его частях.

А если они меняются в рантайме, то и ваш генератор СМК должен все эти условия проверить, сгенерить год и исполнить его.

Так выигрыш то огромен, если список таких условных ветвей достаточно большой. Даже из 10 условных команд, в случае, если эти команды нужно выполнить все (худший случай с точки зрения затраченного времени выполнения), понадобится 20 тактов (при условии, что все команды однотактные и условно выполняемая инструкция одна) без СМК. А применив СМК - цикл сократится до 10 тактов (без накладных расходов на проверку условия цикла). В лучшем случае, если только 1 условие верно, нужно выполнить только 1 инструкцию вместо 20 (10 связок "команда сравнения - команда самого условно выполняемого действия") выигрыш в 20 раз! Это ли не здорово?

По моему, даже если вы выиграете на исполнении СМК, то скорее всего проиграете на подготовке СМК.

Достаточно написать перед этим интересующие участки на ассемблере, скомпилировать их и видеть в бинарнике готовые инструкции в виде машинных слов. Easy же

Потрясающе!!!! Вы угадали прямо в точку! Именно такой алгоритм я и хочу переделать на СМК! Потрясающая проницательность!

Я просто телепат

Сообщение отредактировал Arlleex - Jun 29 2018, 17:22