Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Ring bufer
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
k155la3
Для работы с архивами в флеш использую колцевой буфер.
Контроль диапазона индекса буфера реализован на if.
-----------------
Есть решения, где для ограничения выхода за размер буфера
используется операция остатка от деления %

Я для работы буфера использую:
- указатель индекса
- кол-во данных в буфере

В буфер идет только запись, удалять данные из него не требуется.

(?) На сколько лучше-хуже для контроля границы индекса использовать операцию % ?

(для размеров буфера, кратных степени 2 можно использовать двоичную маску, это мы знаем. Но размеры заданы и не кратные 2).
haker_fox
QUOTE (k155la3 @ Jan 24 2017, 22:54) *
(?) На сколько лучше-хуже для контроля границы индекса использовать операцию % ?

А это имеет значение? rolleyes.gif Что вам важно: скорость исполнения кода, размер? Я вообще использую арифметические операции при работе с указателями. Пока на скорость не жалуюсь rolleyes.gif
k155la3
Цитата(haker_fox @ Jan 24 2017, 18:09) *
А это имеет значение? rolleyes.gif Что вам важно: скорость исполнения кода, размер? Я вообще использую арифметические операции при работе с указателями. Пока на скорость не жалуюсь rolleyes.gif


Жить ЭТО будет в MSP430, но ни быстродействие ни размер особого значения не имеют.
(в разумных пределах). Хотелось бы уменьшить размер и логику-читабельность исходного текста.

Стоит ли мой "ифовый-if" колхоз переделывать на %.

haker_fox
QUOTE (k155la3 @ Jan 24 2017, 23:19) *
Стоит ли мой "ифовый-if" колхоз переделывать на %.

По-мне так главное вам было понятно, что делает этот код. Во вторую очередь - вашим коллегам (им-то вы сами сможете объяснить, при помощи комментариев))) Ну если вас что-то смущает, поглядите как буфер этот сделан в Boost'е)
У меня сделан шаблоном под произвольный тип данных. Правда в контексте FreeRTOS, что не есть гуд, но работает. Даже на приличной скорости: данные с АЦП ложаться каждые 100 мкс в буфер, и вычитываются оттуда со скорость 8 МБит в SPI. При этом размер данных с АЦП 8 байт.
toweroff
Если буфер кратен 2, то вообще 1 операция И с маской
сорь, не увидел
x893
Если вас волнует разница между if, % и маской по модулю 2
Посмотрите код ассемблерный (минут 5-10 это занимает) и не стоит разводить бессмысленных обсуждение на 2-3 дня.
jcxz
Цитата(k155la3 @ Jan 24 2017, 17:54) *
(?) На сколько лучше-хуже для контроля границы индекса использовать операцию % ?
(для размеров буфера, кратных степени 2 можно использовать двоичную маску, это мы знаем. Но размеры заданы и не кратные 2).

Если таких операций - одна-две - то неважно как.
Но как правило операций контроля выхода индекса за пределы массива бывает очень много, тогда всё-же лучше писать оптимально.
Обычно на большинстве embedded-процессоров оптимальнее условный оператор if.
У меня обычно это выглядит так:
Код
#define ncell(m) (sizeof(m) / sizeof((m)[0]))  //кол-во элементов массива m
int ix; //индекс
char buf[N];
if (--ix < 0) ix += ncell(buf);

На Cortex-M с оптимизацией как правило компилится в 3 команды.
На Classic-ARM - может быть всего 2 команды.
Да - как видно - оптимальнее декрементировать индекс. Хотя если хочется можно и в прямом направлении работать, с отрицательными индексами.
Так что даже вариант с размером кратным степени двойки и логическим AND в этом случае может быть не лучше.
Не помню уже как там на MSP430, но лучше можно сделать только на DSP где поддерживается аппаратная циклическая адресация - там вообще 0 команд будет.
k155la3
Цитата(haker_fox @ Jan 24 2017, 19:51) *
. . . .
вас что-то смущает, поглядите как буфер этот сделан в Boost'е)
. . . .

Ok. Спасибо.
Цитата(x893 @ Jan 24 2017, 19:54) *
Если вас волнует разница между if, % . . . .
Посмотрите код ассемблерный . . . .

Так и собираюсь сделать. А может и нет.
тк. Операция целочисленного деления, скорее всего, делается на аппаратном умножителе,
и отличаться от if будет мало, если не быстрее.
Идея вопроса - что логичнее - правилнЕЕ по оптимальности построения алгоритма.
Понятно, что тема - "баян", но меня интересуют просто мнения знатоков (да/нет) а не результат холивара на эту тему sm.gif
Цитата(jcxz @ Jan 24 2017, 20:20) *
Если таких операций - одна-две - то неважно как.
Но как правило операций контроля выхода индекса за пределы массива бывает очень много, тогда всё-же лучше писать оптимально.
. . . .
Не помню уже как там на MSP430, но лучше можно сделать только на DSP где поддерживается аппаратная циклическая адресация - там вообще 0 команд будет.

Спасибо за инф. и пример.
ps - поюзать DSP - моя мечта, как у Шуры Балоганова sm.gif
sigmaN
Лично я бы делал if.
В отрыве от предположений об аппаратном множителе и т.д. - операция % дороже сравнения!

Вам тут уже подсказали вариант
Цитата
#define ncell(m) (sizeof(m) / sizeof((m)[0])) //кол-во элементов массива m
int ix; //индекс
char buf[N];
if (--ix < 0) ix += ncell(buf);

Я голосую за него.

Так же в плане оптимальности не забывайте, что сравнение с нулем в 90% выгоднее сравнения с любым другим числом.
Об этом даже Александреску в своих лекциях не раз рассказывал. Ибо 0 всегда где-то есть. Либо есть отдельная инструкция для теста на 0 либо в регистре где-то уже есть 0 и компилятор его подсунет в операцию. А любое другое число придется сначала куда-то положить, а потом сравнить. 0 - ваш лучший друг, говорил Александреску и я с ним полностью согласен wink.gif
ViKo
Работаю с буферами через указатель. Для сравнения с границей буфера создаю переменную (даже не переменную, а константу, но она в некий регистр загружается, естественно) buflim, указывающую на конец буфера. Сравниваю указатель с этим пределом. Если указатель вышел за предел, загружаю его снова началом буфера.
jcxz
Цитата(k155la3 @ Jan 25 2017, 10:43) *
ps - поюзать DSP - моя мечта, как у Шуры Балоганова sm.gif

Так зачем себе отказывать? Хочется - побалуйте себя. :-)
Отладки с DSP сейчас найти думаю не проблема, какое-то время назад на C5535 (вроде) даже бесплатно раздавали.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.