[jcxz 350]

7 минут назад, dimka76 сказал:

1. почему нельзя данные в dev->null выфлушивать в тот же реальный буфер, просто просто потом ничего с этими данными не делать ?

Потому что его нет. Он либо есть (и тогда данные пишутся в него), либо его нет (тогда данные выфлушиваются).

7 минут назад, dimka76 сказал:

2. данные в dev->null. Завести отдельный буфер единичного размера в реальном ОЗУ и выфлушивать в него, просто индекс не менять, а писать всегда в один и тот же индекс.

"Менять или не менять" - это как раз лишние куча ветвлений (в каждой точке записи). Для избавления от которых и был добавлен fake-буфер.

[_3m 19]

4 часа назад, dimka76 сказал:

Любопытства ради, а для чего такое вообще может понадобится ?
Писать в никуда.

Да регулярно нужно. Например алгоритм получает на вход один массив данных, обсчитывает их и в процессе создает несколько выходных массивов а также статистику. На время отладки может быть достаточно только статистики а сами выходные массивы не нужны. Проверки на nullptr в куче мест съедают производительность, в этом случае будет полезна несуществующая область адресного пространства. 

[jcxz 350]

10 минут назад, _3m сказал:

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

Да, именно так. Алгоритм не может быть пропущен весь (в случае флуша). Нужно или дублировать отдельно весь алгоритм для случая флуша; или делать кучу ветвлений; или использовать fake-буфер.

И всё это в ISR и частично - при запрещённых прерываниях.

 

Странно что такое применение неочевидно....

[VladislavS 46]

4 минуты назад, jcxz сказал:

Нужно или дублировать отдельно весь алгоритм для случая флуша

Размер кода <---> производительность. Так всегда было...

[Arlleex 320]

13 минут назад, _3m сказал:

Да регулярно нужно. Например алгоритм получает на вход один массив данных, обсчитывает их и в процессе создает несколько выходных массивов а также статистику. На время отладки может быть достаточно только статистики а сами выходные массивы не нужны. Проверки на nullptr в куче мест съедают производительность, в этом случае будет полезна несуществующая область адресного пространства. 

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

[VladislavS 46]

Колбэк тоже не басплатен. И алгоритм должен вызваться нисмотря ни на что.

18 минут назад, jcxz сказал:

или дублировать отдельно весь алгоритм

if constexpr в помощь. Поручите дублирование компилятору.

[jcxz 350]

14 минут назад, VladislavS сказал:

Размер кода <---> производительность.

Всё в меру. Излишне загромождать код на ровном месте - так себе идея. Его же ещё и отлаживать нужно.

14 минут назад, Arlleex сказал:

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

Вроде речь шла о единицах тактов. "Подмена колбэками" - сразу КРАТНО затормозит весь код. Это намного хуже ветвлений.

 

[VladislavS 46]

8 минут назад, jcxz сказал:

Излишне загромождать код на ровном месте

Лишних пара строк. Остальное забота компилятора. Зато совсем много тактов сэкономите, так как ни куда вообще писать не надо будет.

[jcxz 350]

4 минуты назад, VladislavS сказал:

Лишних пара строк. Остальное забота компилятора. Зато совсем много тактов сэкономите, так как ни куда вообще писать не надо будет.

Не всё так просто. Ветвление - не внутри одной функции или одного участка кода, а в разных функциях/местах. Не в едином блоке кода и не в едином времени исполнения. Размазано по многим функциям, вызываемым из разных мест.

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

[Arlleex 320]

#ifdef RELEASE
  #define WRITE(struct, member, value) (struct->member = (value))
#elifdef DEBUG
  #define WRITE(struct, member) __ASM volatile ("nop")
#endif

...

if (...)
  WRITE(Param, speed, 100);

 

Эмуляция записи обычным NOP-ом?

Или надо в рантайме?

[dimka76 89]

On 10/13/2025 at 2:40 PM, jcxz said:

Не всё так просто. Ветвление - не внутри одной функции или одного участка кода, а в разных функциях/местах.

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

[jcxz 350]

14 минут назад, Arlleex сказал:

Или надо в рантайме?

runtime only - of course.

4 минуты назад, dimka76 сказал:

Как выше предложили с разными функциями доступа к буферу, только использовать указатель на функцию.

Всё равно это всё будет более громоздким и медленным.

[Arlleex 320]

28 минут назад, jcxz сказал:

runtime only - of course.

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

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

P.S. И кстати, инструкцию IT иногда можно уложить в 0 тактов, как будто ее нет, поэтому сравнение на nullptr может быть не так плохо.

[jcxz 350]

22 минуты назад, Arlleex сказал:

Тогда можно подумать над заменяющим все инструкции STR в назначенный кусок памяти на NOP перед входом в отладочный режим.

И как предлагаете поступать для read-modify-write операций для формирования "назначенного куска"? Если скажем - в этом куске нужны какие-то манипуляции с битовыми полями?

 

PS: Есть FIFO. В которое пишутся пакеты (структуры). В realtime. FIFO читается задачей ОС. Пишется - в ISR. Запись идёт формированием целевого пакета сразу в памяти FIFO. Без дополнительных копирований. Условно: функция void volatile *InFramePrepare() определяет объём свободного места в FIFO и его положение. Если места в FIFO достаточно для записи нового пакета - возвращает указатель на это место (и опционально - изменяет внутренние указатели позиций FIFO); если недостаточно - возвращает указатель на фейковый буфер. Этот указатель запоминается. Далее - идёт формирование результирующего пакета. Которое выполняется не в одном месте кода. Завершается всё вызовом void InFrameComplete(). Которая дописывает данные в пакет, закрывает его, перемещает указатели позиций FIFO (и опционально - взводит флаг переполнения, если запись шла в фейковый буфер), пингует принимающую задачу, чтобы она могла прочитать FIFO.

Пакеты - не совсем структуры. Имеют переменный размер.

Перед формированием каждого нового пакета в FIFO вызывается InFramePrepare(), после - InFrameComplete().

Вроде как всё логично...

[Arlleex 320]

4 минуты назад, jcxz сказал:

И как предлагаете поступать для read-modify-write операций для формирования "назначенного куска"? Если скажем - в этом куске нужны какие-то манипуляции с битовыми полями?

Назначенный кусок - в смысле тот, где находится тот "не нужный" буфер. Фейковая память. В нее же не планировали делать никаких RMW-операций?

4 минуты назад, jcxz сказал:

PS: Есть FIFO. В которое пишутся пакеты (структуры). В realtime...

Понятно, тогда все советы - ерунда.