реклама на сайте
подробности

 
 
5 страниц V  < 1 2 3 4 > »   
Reply to this topicStart new topic
> Самомодифицирующийся код в экосистеме Cortex-M., есть ли право на жизнь?
AlexandrY
сообщение Jun 29 2018, 07:05
Сообщение #16


Ally
******

Группа: Модераторы
Сообщений: 6 059
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(jcxz @ Jun 29 2018, 10:03) *
Ну хорошо - придумайте своё название. rolleyes.gif Не в терминах суть.

Динамически генерируемый код - вот так будет лучше, на мой взгляд.
Отладка такого кода будет адской.

Нет, я лучше возьму i.MX RT и закрою тему одним махом.

Кста, кто придумает для RT лучшую аппликацию получит плату с RT бесплатно.
Может там ваша динамика и прокатит. biggrin.gif
Go to the top of the page
 
+Quote Post
aaarrr
сообщение Jun 29 2018, 07:24
Сообщение #17


Гуру
******

Группа: Свой
Сообщений: 10 619
Регистрация: 11-12-04
Пользователь №: 1 448



Цитата(AVI-crak @ Jun 29 2018, 07:47) *
Cortex, да и почти все arm чипы - используют внеочередное исполнение кода. Он может загружать адреса для двух функций одновременно. Просчитывать данные которые будут применяться где-то внутри функции до её реального вызова. Размазывать циклы на всю портянку. Обращать переменные в другое значение чем было назначено в пользовательской программе -без потери целостности алгоритма, и ещё много много чего. Это их главная фишка.
Фактически код в отладчике выполняется по строкам программы, а в реальности прыгает как бешеный сайгак.

Вообще-то тема про Cortex-M, а не старшие Cortex-A. И даже на последних это нисколько не мешает писать самомодифицирующийся код: сбросили кэш, установили барьеры - и вперед.
Go to the top of the page
 
+Quote Post
Serge V Iz
сообщение Jun 29 2018, 07:35
Сообщение #18


Частый гость
**

Группа: Участник
Сообщений: 129
Регистрация: 3-05-18
Пользователь №: 103 639



Использовал хранимые в ОЗУ участки кода, которые загружались извне в виде обезличенных произвольных массивов данных в ходе работы системы, а в местах обращений к ним трактовались как подпрограммы с заранее известным адресом точки входа. А что ему может помешать так работать?
Go to the top of the page
 
+Quote Post
AVR
сообщение Jun 29 2018, 07:43
Сообщение #19


фанат Linux'а
*****

Группа: Свой
Сообщений: 1 298
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008



Цитата(jcxz @ Jun 29 2018, 01:54) *
Есть мысль использовать самомодифицирующийся код для оптимизации решения одной задачи.

Оптимизация по скорости? А то я хотел microPython предложить, для best-in-class супер простой самомодификации кода.


--------------------
Go to the top of the page
 
+Quote Post
RadiatoR
сообщение Jun 29 2018, 07:54
Сообщение #20


Местный
***

Группа: Свой
Сообщений: 270
Регистрация: 8-08-15
Из: Москва
Пользователь №: 87 901



Вопрос к ТС - а каков предполагаемый размер генерируемой функции? Может имеет смысл просто в RAM зарезервировать буфер и в нем генерировать код. Если функция генератор уже создана, то можно смело пробовать...
Go to the top of the page
 
+Quote Post
_4afc_
сообщение Jun 29 2018, 08:23
Сообщение #21


Профессионал
*****

Группа: Свой
Сообщений: 1 216
Регистрация: 13-10-05
Из: Санкт-Петербург
Пользователь №: 9 565



Мой опыт показывает что оптимизация по скорости самомодифицирующимся кодом неэффективна.
Потому что очевидно, что такой код будет находится в ОЗУ.
А в Cortex-M3,M4 у меня код быстрее выполнялся из flash тк у Atmel там 128 битная шина доступа на частоте более 25МГц...
Т.е. даже при наличии кеша данные или код из flash обрабатывались быстрее чем из озу.
А поскольку флеша пихают теперь в кристалы просто дикое количество - то необходимости что-то копировать в ОЗУ нет, разве что для снижения потребления.

Что касается ускорения - проще расписать циклы.

Есть ещё TDM для ускорения и на старых ARM - режим FIQ со своим набором регистров.

Единственный оправданный вариант применения самогенерирующегося кода - некий софтпроцессор.
Т.е. программа в МК зашита давно, но иногда удалённо в него прилетает новая функция и он её выполняет.
Go to the top of the page
 
+Quote Post
VladislavS
сообщение Jun 29 2018, 08:38
Сообщение #22


Местный
***

Группа: Свой
Сообщений: 446
Регистрация: 14-04-05
Из: Москва
Пользователь №: 4 140



_4afc_, не стоит быть столь категоричным. Если говорить в общем, а задачу ТС поставил именно "а поговорить", то этих кортексов в природе хоть попой кушай и у всех разные скоростные характеристики блоков памяти. Рассуждать где что разместить можно только после того как будет произнесено вслух название чипа.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2018, 08:43
Сообщение #23


Гуру
******

Группа: Свой
Сообщений: 4 863
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Serge V Iz @ Jun 29 2018, 10:35) *
Использовал хранимые в ОЗУ участки кода, которые загружались извне в виде обезличенных произвольных массивов данных в ходе работы системы, а в местах обращений к ним трактовались как подпрограммы с заранее известным адресом точки входа. А что ему может помешать так работать?

Это называется "оверлеи". Пользовал такое на LPC4370, в котором нет флешь, ОЗУ не так уж много, и были оверлеи (редко выполняемые), подгружаемые из внешней SPI-флешь в один и тот же буфер в ОЗУ.
Тут несколько иная задача. AlexandrY уже придумал более точное название: "Динамически генерируемый код".

Цитата(AVR @ Jun 29 2018, 10:43) *
Оптимизация по скорости? А то я хотел microPython предложить, для best-in-class супер простой самомодификации кода.

По скорости. Ну если у меня оптимизация на таком уровне (генерация маш.кода), то это совсем другой порядок скоростей, чем смогут всякие явы и питоны laughing.gif
Go to the top of the page
 
+Quote Post
Kabdim
сообщение Jun 29 2018, 08:44
Сообщение #24


Знающий
****

Группа: Свой
Сообщений: 512
Регистрация: 26-11-14
Из: Зеленоград
Пользователь №: 83 842



Имхо сейчас время такое что проще взять более мощный чип. Вообще полиморфы родились как способ обдурить антивирус. Разработчики, которым нужна подобная оптимизация (без криминала) обычно делают N *.dll'ек, которые загружаются исходя и потребностей.
Так что на мой взгляд толстый проц с большим кол-вом флеша и с помощью темплейтов скомпилировать все комбинации кода.
Впрочем подозреваю что идея о самопишущемся коде это скорее спортивный интерес. В этом случае надо просто делать и получать удовольствие.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2018, 09:08
Сообщение #25


Гуру
******

Группа: Свой
Сообщений: 4 863
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(RadiatoR @ Jun 29 2018, 10:54) *
Вопрос к ТС - а каков предполагаемый размер генерируемой функции? Может имеет смысл просто в RAM зарезервировать буфер и в нем генерировать код. Если функция генератор уже создана, то можно смело пробовать...

Так и есть. Размер функции переменный, в зависимости от заданных входных аргументов: от одной команды BX LR (пустой список) до примерно полусотни команд.
Генератор сейчас в процессе создания cool.gif

Цитата(_4afc_ @ Jun 29 2018, 11:23) *
А в Cortex-M3,M4 у меня код быстрее выполнялся из flash тк у Atmel там 128 битная шина доступа на частоте более 25МГц...

А теперь возьмите калькулятор в руки и посчитайте: 128/8*25=400МБ/сек; т.е. - если CPU работает на хотя-бы 100МГц тактовой, то 4-байтовые чтения из 0-wait-state ОЗУ уже дадут такую скорость. Так что на частотах >100МГц выполнение из ОЗУ у Вас должно быть быстрее. Конечно тут нужно ещё учесть влияние кеша FLASH и пересечение prefetch-ей с обращениям за данными по этой же шине (можно вынести такой код в отдельный регион SRAM с отдельной шиной для скорости).

Но у меня МК с шиной к FLASH программ == 256 бит, кешем FLASH и тактовой 144МГц. Но зато есть регион PSRAM (program SRAM) с отдельной шиной к нему от ядра. И существенной разницы в скорости выполнения между FLASH и PSRAM я не замечаю.

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

Цитата(_4afc_ @ Jun 29 2018, 11:23) *
Т.е. даже при наличии кеша данные или код из flash обрабатывались быстрее чем из озу.
А поскольку флеша пихают теперь в кристалы просто дикое количество - то необходимости что-то копировать в ОЗУ нет, разве что для снижения потребления.

Ещё раз внимательнее перечитайте мои посты: я уже много раз написал, что говорю не о копировании заранее подготовленных кусков (оверлеев) в ОЗУ, а о динамической генерации кода.

Цитата(VladislavS @ Jun 29 2018, 11:38) *
Рассуждать где что разместить можно только после того как будет произнесено вслух название чипа.

XMC4700 rolleyes.gif
Go to the top of the page
 
+Quote Post
_4afc_
сообщение Jun 29 2018, 09:53
Сообщение #26


Профессионал
*****

Группа: Свой
Сообщений: 1 216
Регистрация: 13-10-05
Из: Санкт-Петербург
Пользователь №: 9 565



Цитата(jcxz @ Jun 29 2018, 13:08) *
А теперь возьмите калькулятор в руки и посчитайте: 128/8*25=400МБ/сек; т.е. - если CPU работает на хотя-бы 100МГц тактовой, то 4-байтовые чтения из 0-wait-state ОЗУ уже дадут такую скорость. Так что на частотах >100МГц выполнение из ОЗУ у Вас должно быть быстрее. Конечно тут нужно ещё учесть влияние кеша FLASH и пересечение prefetch-ей с обращениям за данными по этой же шине (можно вынести такой код в отдельный регион SRAM с отдельной шиной для скорости).

Но у меня МК с шиной к FLASH программ == 256 бит, кешем FLASH и тактовой 144МГц. Но зато есть регион PSRAM (program SRAM) с отдельной шиной к нему от ядра. И существенной разницы в скорости выполнения между FLASH и PSRAM я не замечаю.

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

У меня для ускорения, часть алгоритма была заранее посчитана и использовались таблицы поиска (LUT).
Так вот, наибольшей скорости я добился при нахождении LUT во FLASH, а кода в ОЗУ в виде расписанных циклов.

В микроконтроллерах Атмела wait-state устанавливается на всю систему памяти и на FLASH и на ОЗУ (хотя теперь про это не пишут)
Поэтому для того чтобы выполнять программу с 0-wait-state из ОЗУ - надо сгенерить весь исполняемый код в ОЗУ и
на 100МГц во флеш даже носа не показывать, даже ради таблицы векторов.

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

Вероятно генерация (даже распаковка из внешней FLASH), при отключенной внутренней, в небольшое PSRAM на максимальной частоте кусков кода при 0-wait-state - это хорошая экономия ОЗУ под буфера данных...
Go to the top of the page
 
+Quote Post
Arlleex
сообщение Jun 29 2018, 13:08
Сообщение #27


Местный
***

Группа: Участник
Сообщений: 358
Регистрация: 12-11-11
Пользователь №: 68 264



Интересная тема для меня, тема СМК. Ни разу не применял, однако небольшие размышления в этой части заставили признать, что в практике программирование были моменты, где удобно было бы иметь самомодификацию. Приведу пример, где бы я использовал СМК (опять же, в реальной практике была уйма таких задач).
Пусть есть некий цикл, но внутри этого цикла подряд идут условно выполняемые команды:
Код
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 такта, а после модификации останутся только "нужные" инструкции. Останется только условие продолжения цикла и нужные команды, без этих паршивых проверок. Я ж, надеюсь, никому святую тайну не открыл? biggrin.gif Повторюсь, это лишь мои хотелки, было много ситуаций где хотелось бы сейчас это реализовать, но оно работает да и зачем туда лезть, тем более там, где во времени я сильно не ограничен...
Go to the top of the page
 
+Quote Post
RadiatoR
сообщение Jun 29 2018, 13:23
Сообщение #28


Местный
***

Группа: Свой
Сообщений: 270
Регистрация: 8-08-15
Из: Москва
Пользователь №: 87 901



Цитата(Arlleex @ Jun 29 2018, 16:08) *
2. На основании этих флагов сформировать СМК-последовательность инструкций без условных инструкций.

Так тут будет тот же
if()...if()...if()...
Go to the top of the page
 
+Quote Post
a123-flex
сообщение Jun 29 2018, 13:27
Сообщение #29


Профессионал
*****

Группа: Свой
Сообщений: 1 514
Регистрация: 11-01-05
Из: Москва
Пользователь №: 1 884



Цитата(jcxz @ Jun 29 2018, 01:54) *
Есть мысль использовать самомодифицирующийся код для оптимизации решения одной задачи.
Именно самомодифицирующийся - программа строит часть самой себя по некоему алгоритму, а не просто копирует куски кода из одной области памяти в другую.
И вот я что-то не смог вспомнить чтобы здесь на форуме вообще когда-то поднималась эта тема.
Кто-то вообще использует такой код на ARM-ах в своих проектах? Просто интересно... rolleyes.gif

Может Вам будет проще в контроллере python поднять ? Или любой другой интерпретатор...


--------------------
Если хочешь узнать, что ждет тебя на дороге впереди, спроси у тех, кто возвращается по ней.
Go to the top of the page
 
+Quote Post
twix
сообщение Jun 29 2018, 14:35
Сообщение #30


Местный
***

Группа: Участник
Сообщений: 279
Регистрация: 4-11-15
Пользователь №: 89 174



Цитата(a123-flex @ Jun 29 2018, 14:27) *
Может Вам будет проще в контроллере python поднять ? Или любой другой интерпретатор...

действительно, интерпретатор намного эффективнее и проще в реализации.


Сообщение отредактировал twix - Jun 29 2018, 16:06
Go to the top of the page
 
+Quote Post

5 страниц V  < 1 2 3 4 > » 
Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th July 2018 - 14:01
Рейтинг@Mail.ru


Страница сгенерированна за 0.01107 секунд с 7
ELECTRONIX ©2004-2016