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

[jcxz]

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

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

[AlexandrY]

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

Обещать не могу.

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

[jcxz]

Или самомодифицирующийся - это код который вот именно сам себя модифицирует, т.е. инструкция STR вот прямо по своему адресу что-то и пишет и сама себя таким образом затирает.

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

PS: Вот уже сколько откликов получил, а на собственно единственный вопрос, поставленный в первом сообщении, так никто и не ответил. И видимо забыли все в чём был вопрос.....
Вопрос был собственно в том: использовал кто-нить из здесь присутствующих самомодифицирующийся код (именно такой код, который или сам своё тело правит или строит другой код (а не просто копирует из одного места в другое))? Именно на платформе ARM в embedded?
И, если использовали, то для какой задачи?

[AlexandrY]

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

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

[Николай Семёнови...]

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

Попытаюсь объяснить (как я это понял), что подразумевать под "самомодифицирующимся кодом" топикстартер.

Не.

Не буду. Боюсь всё равно не поймёте
А разжигать холивар не хочу

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

[jcxz]

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

Вот именно. Даже полностью строит процедуру. Вот такой примерно должен быть результат (код) работы генератора:

CODE

;Назначение регистров в динамически генерируемой функции.
dstReg EQU c_R0 ;указатель на целевой буфер для записи (вх.аргумент)
tblReg EQU c_R1 ;указатель на таблицу адресов переменных (вх.аргумент)
tmpReg0 EQU c_R2 ;рабочий регистр 0
tmpReg1 EQU c_R3 ;рабочий регистр 1
;сама функция
;f0 LDR tmpReg0, [tblReg, #bit1*4]; где bit1 - номер первого единичного бита в мл.слове бит-карты
;f0 LDR tmpReg1, [tblReg, #bit2*4]; где bit2 - номер второго единичного бита в мл.слове бит-карты
;f1 LDR/LDRH tmpReg0, [tmpReg0]
;f2 STR/STRH tmpReg0, [dstReg], #step; где step==4 для STR и step==2 для STRH
;f0 LDR tmpReg0, [tblReg, #bit3*4]; где bit3 - номер 3-го единичного бита в мл.слове бит-карты
;f1 LDR/LDRH tmpReg1, [tmpReg1]
;f2 STR/STRH tmpReg1, [dstReg], #step; где step==4 для STR и step==2 для STRH
;f0 LDR tmpReg1, [tblReg, #bit4*4]; где bit4 - номер 4-го единичного бита в мл.слове бит-карты
;f1 LDR/LDRH tmpReg0, [tmpReg0]
;f2 STR/STRH tmpReg0, [dstReg], #step; где step==4 для STR и step==2 для STRH
; ...
;f3 ADDS tblReg, tblReg, #32*4; вставляется при переходе к ст.слову бит-карты если в нём есть единицы
;f0 LDR tmpReg0, [tblReg, #bit1*4]; где bit1 - номер 1-го единичного бита в ст.слове бит-карты
;f1 LDR/LDRH tmpReg1, [tmpReg1]
;f2 STR/STRH tmpReg1, [dstReg], #step; где step==4 для STR и step==2 для STRH
;f0 LDR tmpReg1, [tblReg, #bit2*4]; где bit2 - номер 2-го единичного бита в ст.слове бит-карты
;f1 LDR/LDRH tmpReg0, [tmpReg0]
;f2 STR/STRH tmpReg0, [dstReg], #step; где step==4 для STR и step==2 для STRH
; ...
;f1 LDR/LDRH tmpReg1, [tmpReg1]
;f2 STR/STRH tmpReg1, [dstReg], #step; где step==4 для STR и step==2 для STRH
;f4 BX LR

LDR или LDRH использовать - определяется весом бита, заданным в таблице. Генератор формирует код глядя в эту таблицу.

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

Блин, коллега, позвольте пожать Вашу руку! Вы - похоже почти единственный человек на этом форуме сходу понявший все нюансы!!!

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

Как будто заглянули в мои исходники!