Вобще затраты производительности процессора на обслуживание очереди сообщений для менюшек правильно расчитывать для пустой очереди, именно пустые её проходы составляют более 99% и следовательно, ни её длина ни скорость работы полной особой роли не играют. Согласны? ;)
Я совсем не понял о каких очередях сообщений для менюшек идёт речь...
У меня нет никаких сведений об исследовании заполняемости очередей. Очевидно, этот показатель очень сильно различается в различных задачах и даже в различных фазах задачи. Например, FIFO буфер COM порта может большу часть своей жизни быть пустым и тут, вдруг, юзверь нажал кнопку отправить в COM порт дамп памяти, который значительно, на порядки превосходит по объему буффер порта и до окончания передачи буфер будет загружен полностью.
Кроме того, очередь может использоваться не только для хранения данных о действиях юзверя, которые некогда проглотить. Например, прорисовка или рендеринг графического изображения выполняется в буффере, а потом оптом выливается. Причём, не просто один кусок нарисовали, его отправили, и потом уже второй кусок рисовать на месте прежнего, а нарисовали кусок, запустии отправку, следом второй кусок рисуем в продолжение, пока первый отправляется. В условиях ограниченности объема памяти и с целью её максимально эффектианого использоваия, кольцевой буффер эффективнее в этом случае - нет необходимости создавать буффер на два кадра, ибо, после запуска отправки, происходящей быстрее заполнения, можно заворачивать уже на начало отправляемых данных, уже улетевших, новую прорисовку.
И ещё массу примеров можно привести, где требуется накапливать блоки\кадры информации до начала их обработки и эти кадры формируются в виде очереди. В таких случаях чаще всего использутся цепочки или коллекции, управляемые указателями или индексами. И, вот Вы не поверите - двигают указатели, а не куски памяти. :)
Пора бы уже согласиться, что дубовым способом было проще реализовать очередь - никаких проверок заворачивания указателtй (индексов)... Надо добавить - толканул кусок памяти, надо удалить - стянул обратно. :)
Вобще затраты производительности процессора на обслуживание очереди сообщений для менюшек правильно расчитывать для пустой очереди, именно пустые её проходы составляют более 99% и следовательно, ни её длина ни скорость работы полной особой роли не играют. Согласны? ;)
Я совсем не понял о каких очередях сообщений для менюшек идёт речь...
Например, прорисовка или рендеринг графического изображения выполняется в буффере, а потом оптом выливается.....
Вы это серезно предлагаете для МК с 2КБ ОЗУ?!
faeton пишет:
И ещё массу примеров можно привести, где требуется накапливать блоки\кадры информации до начала их обработки и эти кадры формируются в виде очереди. В таких случаях чаще всего использутся цепочки или коллекции, управляемые указателями или индексами. И, вот Вы не поверите - двигают указатели, а не куски памяти. :)
Действительно не поверю про двигают. Т.к. как правило там вобще ничего никуда не двигают. Просто передают указатели и через них выполняют доступ к статическим или динамически распределенным данным. Но только то на ПК. И я так делаю когда данные большие. Может про "двигают указатели" Вы имели в виду указатель-итератор "пробегает" про данным, тогда да, обычный подход. Но то ПК, и не путайте его с МК. Этим грешат многие, особенно веб-дизайнеры ;) берущиеся за ардуино. Здесь указатель 2 байта а разрядность - один. Вот и выходит, что работа с указателями не так быстра как хотелось бы. Это конечно не мешает их использовать там, где это оправдано, (например калбек загнать вглубь библиотеки и качать данные через него), но существенно влияет на вопрос где оправдано, а где нет. Очень заметно при передаче параметров в функцию по значению, указателю или глобально.
faeton пишет:
Пора бы уже согласиться, что дубовым способом было проще реализовать очередь - никаких проверок заворачивания указателtй (индексов)... Надо добавить - толканул кусок памяти, надо удалить - стянул обратно. :)
О точно, тоже недосмотрел и на говнокодил .. бывает. В отличии от вас (и вы тут не одиноки), детишек с недоразвитым ЧСВ, прибегающих оскорблять всех и вся (кстати - извиняться планируете или так и пожелаете остаться уродом в глазах читателей?), мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. Нашли ошибку? Искренне благодарю, спасибо.
А на поставленные вопросы - отвечать БУДЕТЕ или ПРЕДПОЧИТАЕТЕ посидеть в лужах? Уже двух, между прочим .. :)
О точно, тоже недосмотрел и на говнокодил .. бывает. В отличии от вас (и вы тут не одиноки), детишек с недоразвитым ЧСВ, прибегающих оскорблять всех и вся (кстати - извиняться планируете или так и пожелаете остаться уродом в глазах читателей?), мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. Нашли ошибку? Искренне благодарю, спасибо.
А на поставленные вопросы - отвечать БУДЕТЕ или ПРЕДПОЧИТАЕТЕ посидеть в лужах? Уже двух, между прочим .. :)
Даже жирным не грешно процитировать.
"мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. "
Вот - замечательно сформулировали свою позицию на форуме!! О чем вобще разгаваривать...
ПС. Сылочку на неотвеченые Ваши вопросы пожалуста. Последний вопрос был "почему инкремент на 2" два, ответ "Так автор нагомнокодил". Вы признали правильность ответа.. усьо..
А вот Вы Arhat109-2 на вопросы не отвечаете. Это у Вас тактика такая, переваливать свои грехи на опонента? Здесь смотрите http://arduino.ru/forum/programmirovanie/ochered-sobytii#comment-188849 особенно интересует про 3 такта на команду для чтения/записи памяти с сылкой на даташит для 328-го;)
Logik писал "Вот - замечательно сформулировали свою позицию на форуме!! О чем вобще разгаваривать..."
Да, это позиция и не только на форумах, и даже не только везде, а на этом конкретно в частности. Это разъяснение таким как вы, что ваши наезды и попытки перейти на обсуждения личностей, а равно как жажда и стремление (из-за собственной низкой самооценки) оценивать чьи-то мозги и прочие запчасти - меня не интересуют и не волнуют. Уродство - исправить нельзя: "горбатого -могила исправит" (с) народная мудрость. Об чем вам и отписал: или вы извиняетесь, или остаетесь уродом в глазах форумчан.
А обсуждать, на форумах, ваще-то обсуждают вопросы, решения, их корректность полезность и т.д. Вот это - готов обсуждать сколько угодно. Не путайте "теплое с мягким".
Logik писал: "особенно интересует про 3 такта на команду для чтения/записи памяти с сылкой на даташит для 328-го"
И ещё раз, напомню: работаю с мегой 2560. 328-ые меня мало интересуют, я их даташит смотрю только когда внезапно "не работает" то, что писано под мегу. Меня ваще мало интересуют "обрезанные" микроконтроллеры для промышленного применения в конкретных изделиях. У меня "домашнее" применение и Мегу2560 больше рассматриваю как SoC "в сборе"... устраивает полностью.
Тем не менее, посмотрел: у 328 - 2 такта на цикл памяти, у 2560 - внутренняя память 2 такта, внешняя 3-6. Был не прав, когда писал про 3 такта. Это относится к конкретно моей меге с моим расширителем памяти в +64кб. Не уточнил, виноват.
Ваши не отвеченные вопросы находятся тут выше, пост #37 и даже выделены жирным шрифтом.
Простите за вмешательство в высоконаучную дискуссию.
Я хотел заметить только г-ну Логику, по поводу частой аппеляции к тяжеловесности адресной арифметики.
Ведь необязательно напрямую с указателями работать, можно только со смещением, а для него хватит одного байта. Вся арифметика - 8-ми битная и быстрая. И только ОДИН раз нужно воспользоваться командой "косвенная загрузка со смещением". Которая выполняется за 2 такта. И, "О чудо", именно в нее gcc превращает обычное обращение к массиву.
То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
Простите за вмешательство в высоконаучную дискуссию.
Я хотел заметить только г-ну Логику, по поводу частой аппеляции к тяжеловесности адресной арифметики.
Ведь необязательно напрямую с указателями работать, можно только со смещением, а для него хватит одного байта. Вся арифметика - 8-ми битная и быстрая. И только ОДИН раз нужно воспользоваться командой "косвенная загрузка со смещением". Которая выполняется за 2 такта. И, "О чудо", именно в нее gcc превращает обычное обращение к массиву.
То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
Более того, добавлю г-ну Логику, что перемещение данных требует их чтение и запись, для которой точно так же надо использовать 16-ти битные адреса, причём не два раза для четния и 1 раз для записи головы и хвоста, а на каждый перемещаемый байт по 2 раза. Да ещё и процессору придётся в цикле попрыгать с выборкой из памяти команд. Боюсь, меня запозорят незнанием асм'а меги - вроде есть автоинкремент адреса, ещё не курил досканально асм, но строковой команды перемещения точно нету, аналогичной movsb. Кстати, про х86 - там шина 20-ти разрядная вообще при 16-ти разрядных регистрах и используются сегментные регистры, в которые можно лишь из РОН писать значение, тем не менее, никому в голову не приходит толкать даже с использованием строковых команд куски памяти колцевого буфера. :)
Кстати, а конвейер команд у меги есть кто-то знает? Догадываюсь, что нет, ну, а вдруг? :)))
А за меню - простите... Как обычно и бывает, про ТС уже подзабыли... :)))
... Я хотел заметить только г-ну Логику, по поводу частой аппеляции к тяжеловесности адресной арифметики. Ведь необязательно напрямую с указателями работать, можно только со смещением, а для него хватит одного байта. ... То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
Верно, именно это и изложено в #37 детально. :)
Ещё поправлюсь. В ПК, проверку закольцовки такого буфера не делают вовсе, про что и написал. Ибо операция "остаток от деления" как раз и производит такую закольцовку автоматически. Тут, правильнее сделать проверку, ибо "деления нет вовсе".
То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
Втом то и дело. Я у себя написал 2 варианта работы циклического буфера, через указатели и через индексы, выбрал тот что короче и его запостил. От второго осталась одно упоминание указателя, которое и было замечено как ошибка)))
Более того, добавлю г-ну Логику, что перемещение данных требует их чтение и запись, для которой точно так же надо использовать 16-ти битные адреса, причём не два раза для четния и 1 раз для записи головы и хвоста, а на каждый перемещаемый байт по 2 раза. Да ещё и процессору придётся в цикле попрыгать с выборкой из памяти команд.
стати, а конвейер команд у меги есть кто-то знает? Догадываюсь, что нет, ну, а вдруг? :)))
Инкрементит быстро, в одной команде с записю/чтением. Конвеера нет, прыжки не сказываются. Ну не совсем, долго обяснять, читайте даташит (не в плане послал, просто там все описано лучше чем я тут смогу).
Ну, так может на этом и остановимся в переходе на личности и будем обсуждать то, что полезно, нет? :)
Причём тут твоя личность, кому она интересна? Просто отметил, что если у кого-то ещё были какие-то иллюзии насчёт твоего уважения к участникам форума, читающим твой говнокод, то теперь их не осталось. Когда уважают читателя, не бывает пофигу сколь говнокода в постах. Ты ясно сказал, что на участников форума тебе класть и всё, что тебя интересует в этой жизни - это твоя великая личность. Так что обсуждай, что тебе полезно с кем нибудь другим. Я никакой пользы от обсуждений чего либо с тобой не вижу.
Как понимаю, ответов от вас ожидать не приходится. :)
Я уже старательно обходил тему "ответов" дабы не розвивать срач. Я уточнял, где вопросы, какие вопросы... Получил
Arhat109-2 пишет:
Ваши не отвеченные вопросы находятся тут выше, пост #37 и даже выделены жирным шрифтом.
Смотрим 37-й... В полном обёме
Arhat109-2 пишет:
faeton, писал: "Двигать кусок памяти менее эфективно, нежели указатели, если кусок памяти более размера указателей."
Верно, что я и пытался объяснить. Индексирование кольцевого буфера на массиве требует проверки для каждого индекса (головы и хвоста): выход за конец массива - "закольцовка" и "догон друг друга", чтобы голова не обогнала хвост и наоборот. То есть имеем 2*2 = 4 проверки. Да, их надо делать и при вставке и при извлечении из очереди. Итого 8 проверок. Для байтового индекса (буфер до 256 элементов) имеем короткие регистровые операции, вместо составных.
Для буфера "со сдвигом" элементов проверки выхода за границу массива - тоже необходимы. И точно также И на вставке И на удалении элементов. Тут, наверное, указатель тоже правильней делать индексом массива, а не как показано в говно-примере, ибо он становится байтовым. Но не уверен, надо смотреть. Лично мне - нафиг не надо (потому и не проверяю, ибо вполне достаточно оценочного анализа), ибо предпочитаю код не требующий буферизаций от слова "вовсе" - затратно оно "буферизация" и тормозит нещадно в целом, а для МК - это может ещё и быть критичным.
Далее. Буфер со сдвигом гарантировано требует переноса данных, и каждая операция переноса требует ЧТЕНИЯ из памяти и ЗАПИСИ в неё, элемента данных буфера (хотя бы 1 байта). [Такие операции у Атмела выполняются ЗА 3 ТАКТА каждая, о чем хорошо написано в даташитах (не все читают)] Исправлено: Операции чтения-записи исполняются нормально за 2 такта, соответственно ниже пересчитано тоже[]. Плюсом требуется посчитать и проверить счетчик переноса .. что ещё добавляет 1 операцию (посчитать) и 1 проверку и ветвление (переход - 2 такта!). То есть имеем гарантированные 5 операций на элемент переноса. Итого имеем 2+2+1+2 = 7 тактов на каждый байт переноса. Для более сложных элементов буферизации - тут все существенно усложняется.
Итого, в сравнении у нас остается 6 проверок (посчитать и перейти = по 3 такта = 18 тактов) против переноса данных (по 9 тактов на элемент).
Отсюда вывод: буфер со сдвигом становится эквивалентен буферу на индексах "голова","хвост" при его размере .. 2-3 байта. Что [практически] полностью совпадает с утверждением, цитированным выше:
"Двигать кусок памяти менее эфективно, нежели указатели, если кусок памяти более размера указателей."
Оно конечно же очевидное, как и предыдущий урок по обработчику TWI (I2C):
"Всякий неблокирующий код предпочтительнее любого блокирующего и, тем более, при равных или похожих затратах на время и место"
Но .. видимо не для каждого. :)
Из них жирным
Arhat109-2 пишет:
faeton, писал: .....
Исправлено: Операции чтения-записи исполняются .....
"Двигать кусок памяти менее эфективно, нежели указатели, если кусок памяти более размера указателей."
"Всякий неблокирующий код предпочтительнее любого блокирующего и, тем более, при равных или похожих затратах на время и место"
Просто уникал, он пока 3 раза не облажается - не успокоится. И так каждый раз. Т.е. пока два раза - обязательно требует третий 8)))) Может бот какой, мазохистской направлености?
Слышь, дятел? Ты свои фантазии, мне не приписывай, ладно? А заодно, притуши свою манию величия, тебя ВСЕ читатели, отвечать за них - не упономачивали. Так - ясно? Ещё один укурок.
Logik, слив - засчитан. Осталось научиться признаваться в собственных ошибках (ошибаются все, не все способны это признавать) и вопрос необходимости бороться за собственно ЧСВ, постепенно отпадет "сам собой". Мужайте. :)
ЕвгенийП, давайте читать фразу в контексте, а не выравывать отдельные слова из него. Было так:
"В отличии от вас (и вы тут не одиноки), детишек с недоразвитым ЧСВ, прибегающих оскорблять всех и вся (кстати - извиняться планируете или так и пожелаете остаться уродом в глазах читателей?), мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. Нашли ошибку? Искренне благодарю, спасибо."
Так что речи про то что мне пофигу на мнение читателей - не было ни разу. Не надо меня ДОПОЛНЯТЬ.
Мне - глубоко пофигу, на те подколы и оскорбления которые регулярно сыпятся из уст говнокодеров в мой адрес или в адрес моего кода в постах - весь смысл той фразы.
Вас никто не дополняет. Я лишь пытаюсь Вам обяснить, что из этой фразы люди деают вывод, что Вам пофиг насколько качественные вещи Вы ИМ (людям) пишете. Вполне допускаю, что Вы это не имели в виду, но я уже третий человек, который воспринял именно так и сделал такой вывод - третий! Просто подумайье о том, что Вы пишете и как это воспринимается людьми. Хотя, конечно, проще подумать, что мы все трое восприняли неправильно (народ плохой попался).
Господа, а давайте жить дружно? :) Ну, пацапались немного, а теперь уже успокоиться пора бы. Логик всё равно никогда не признается, что двигать память некузяво и фигню ляпнул, но почитал и себе втихоря вывод сделал. :) Ну, и ладно - лишь бы человеку на пользу пошло. :) А то уже как в анекдоте: - Илюшенька, а может быть, ну её нафиг эти разборки? :)
К тому же, к суровому спору по сути, на шум уже подтянулся и тот, кому просто что-то ляпнуть надо..., и нравоучения пошли от других участников... :)
Этот бессмысленный холивар (он же срач) Вы называете "спором по сути"? :))) Спасибо, повеселили с утра.
О сути таких споров замечательно сказал классик:
«Насчитывают до одиннадцати тысяч фанатиков, которые в течение этого времени пошли на казнь, лишь бы не разбивать яйца с острого конца. Были напечатаны сотни огромных томов, посвящённых этой полемике, … Между тем это просто насильственное толкование текста, подлинные слова которого гласят: «Все истинно верующие да разбивают яйца с того конца, с какого удобнее»
Вот, скажите, вам троим продавцы попкорна приплачивают? Или Вы им (попкорном) сами торгуете?
Вот, скажите, вам троим продавцы попкорна приплачивают? Или Вы им (попкорном) сами торгуете?
Речь в обсуждении шла о плохом приёме программирования со сдвигом кусков памяти. Если Вы ищите в обсуждении форму выражения, но не суть - Ваше право. :)
Вобще затраты производительности процессора на обслуживание очереди сообщений для менюшек правильно расчитывать для пустой очереди, именно пустые её проходы составляют более 99% и следовательно, ни её длина ни скорость работы полной особой роли не играют. Согласны? ;)
Я совсем не понял о каких очередях сообщений для менюшек идёт речь...
У меня нет никаких сведений об исследовании заполняемости очередей. Очевидно, этот показатель очень сильно различается в различных задачах и даже в различных фазах задачи. Например, FIFO буфер COM порта может большу часть своей жизни быть пустым и тут, вдруг, юзверь нажал кнопку отправить в COM порт дамп памяти, который значительно, на порядки превосходит по объему буффер порта и до окончания передачи буфер будет загружен полностью.
Кроме того, очередь может использоваться не только для хранения данных о действиях юзверя, которые некогда проглотить. Например, прорисовка или рендеринг графического изображения выполняется в буффере, а потом оптом выливается. Причём, не просто один кусок нарисовали, его отправили, и потом уже второй кусок рисовать на месте прежнего, а нарисовали кусок, запустии отправку, следом второй кусок рисуем в продолжение, пока первый отправляется. В условиях ограниченности объема памяти и с целью её максимально эффектианого использоваия, кольцевой буффер эффективнее в этом случае - нет необходимости создавать буффер на два кадра, ибо, после запуска отправки, происходящей быстрее заполнения, можно заворачивать уже на начало отправляемых данных, уже улетевших, новую прорисовку.
И ещё массу примеров можно привести, где требуется накапливать блоки\кадры информации до начала их обработки и эти кадры формируются в виде очереди. В таких случаях чаще всего использутся цепочки или коллекции, управляемые указателями или индексами. И, вот Вы не поверите - двигают указатели, а не куски памяти. :)
Пора бы уже согласиться, что дубовым способом было проще реализовать очередь - никаких проверок заворачивания указателtй (индексов)... Надо добавить - толканул кусок памяти, надо удалить - стянул обратно. :)
Вобще затраты производительности процессора на обслуживание очереди сообщений для менюшек правильно расчитывать для пустой очереди, именно пустые её проходы составляют более 99% и следовательно, ни её длина ни скорость работы полной особой роли не играют. Согласны? ;)
Я совсем не понял о каких очередях сообщений для менюшек идёт речь...
Так для тех, пример которых ТС выложил в втором сообщении темы, и еще потом выкладывал. Тема же не о абстрактной очереди а о используемой здесь http://arduino.ru/forum/programmirovanie/prostoe-menyu-dlya-simvolnogo-displeya-2#comment-186709. И об этом первые 7 постов темы. Ну собственно до Вашего категоричного ИМХО.
Например, прорисовка или рендеринг графического изображения выполняется в буффере, а потом оптом выливается.....
Вы это серезно предлагаете для МК с 2КБ ОЗУ?!
И ещё массу примеров можно привести, где требуется накапливать блоки\кадры информации до начала их обработки и эти кадры формируются в виде очереди. В таких случаях чаще всего использутся цепочки или коллекции, управляемые указателями или индексами. И, вот Вы не поверите - двигают указатели, а не куски памяти. :)
Пора бы уже согласиться, что дубовым способом было проще реализовать очередь - никаких проверок заворачивания указателtй (индексов)... Надо добавить - толканул кусок памяти, надо удалить - стянул обратно. :)
Релокейт шоле?! Фиии. Фрагментирует кучу, тормозит дико.
О точно, тоже недосмотрел и на говнокодил .. бывает. В отличии от вас (и вы тут не одиноки), детишек с недоразвитым ЧСВ, прибегающих оскорблять всех и вся (кстати - извиняться планируете или так и пожелаете остаться уродом в глазах читателей?), мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. Нашли ошибку? Искренне благодарю, спасибо.
А на поставленные вопросы - отвечать БУДЕТЕ или ПРЕДПОЧИТАЕТЕ посидеть в лужах? Уже двух, между прочим .. :)
Кстати, да ещё маленькое уточнение: один тип проверки в байтовых индексах можно не делать, а именно "закольцовку буфера". Итого 6 проверок. :)
О точно, тоже недосмотрел и на говнокодил .. бывает. В отличии от вас (и вы тут не одиноки), детишек с недоразвитым ЧСВ, прибегающих оскорблять всех и вся (кстати - извиняться планируете или так и пожелаете остаться уродом в глазах читателей?), мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. Нашли ошибку? Искренне благодарю, спасибо.
А на поставленные вопросы - отвечать БУДЕТЕ или ПРЕДПОЧИТАЕТЕ посидеть в лужах? Уже двух, между прочим .. :)
Даже жирным не грешно процитировать.
"мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. "
Вот - замечательно сформулировали свою позицию на форуме!! О чем вобще разгаваривать...
ПС. Сылочку на неотвеченые Ваши вопросы пожалуста. Последний вопрос был "почему инкремент на 2" два, ответ "Так автор нагомнокодил". Вы признали правильность ответа.. усьо..
А вот Вы Arhat109-2 на вопросы не отвечаете. Это у Вас тактика такая, переваливать свои грехи на опонента? Здесь смотрите http://arduino.ru/forum/programmirovanie/ochered-sobytii#comment-188849 особенно интересует про 3 такта на команду для чтения/записи памяти с сылкой на даташит для 328-го;)
Logik писал "Вот - замечательно сформулировали свою позицию на форуме!! О чем вобще разгаваривать..."
Да, это позиция и не только на форумах, и даже не только везде, а на этом конкретно в частности. Это разъяснение таким как вы, что ваши наезды и попытки перейти на обсуждения личностей, а равно как жажда и стремление (из-за собственной низкой самооценки) оценивать чьи-то мозги и прочие запчасти - меня не интересуют и не волнуют. Уродство - исправить нельзя: "горбатого -могила исправит" (с) народная мудрость. Об чем вам и отписал: или вы извиняетесь, или остаетесь уродом в глазах форумчан.
А обсуждать, на форумах, ваще-то обсуждают вопросы, решения, их корректность полезность и т.д. Вот это - готов обсуждать сколько угодно. Не путайте "теплое с мягким".
Logik писал: "особенно интересует про 3 такта на команду для чтения/записи памяти с сылкой на даташит для 328-го"
И ещё раз, напомню: работаю с мегой 2560. 328-ые меня мало интересуют, я их даташит смотрю только когда внезапно "не работает" то, что писано под мегу. Меня ваще мало интересуют "обрезанные" микроконтроллеры для промышленного применения в конкретных изделиях. У меня "домашнее" применение и Мегу2560 больше рассматриваю как SoC "в сборе"... устраивает полностью.
Тем не менее, посмотрел: у 328 - 2 такта на цикл памяти, у 2560 - внутренняя память 2 такта, внешняя 3-6. Был не прав, когда писал про 3 такта. Это относится к конкретно моей меге с моим расширителем памяти в +64кб. Не уточнил, виноват.
Ваши не отвеченные вопросы находятся тут выше, пост #37 и даже выделены жирным шрифтом.
Слова не чайника, но истинного прогера!
Кстати, нам - читателям, тоже пофигу количество гавнокод в твоих постах, прогах и либах.
Ну, так может на этом и остановимся в переходе на личности и будем обсуждать то, что полезно, нет? :)
Простите за вмешательство в высоконаучную дискуссию.
Я хотел заметить только г-ну Логику, по поводу частой аппеляции к тяжеловесности адресной арифметики.
Ведь необязательно напрямую с указателями работать, можно только со смещением, а для него хватит одного байта. Вся арифметика - 8-ми битная и быстрая. И только ОДИН раз нужно воспользоваться командой "косвенная загрузка со смещением". Которая выполняется за 2 такта. И, "О чудо", именно в нее gcc превращает обычное обращение к массиву.
То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
Простите за вмешательство в высоконаучную дискуссию.
Я хотел заметить только г-ну Логику, по поводу частой аппеляции к тяжеловесности адресной арифметики.
Ведь необязательно напрямую с указателями работать, можно только со смещением, а для него хватит одного байта. Вся арифметика - 8-ми битная и быстрая. И только ОДИН раз нужно воспользоваться командой "косвенная загрузка со смещением". Которая выполняется за 2 такта. И, "О чудо", именно в нее gcc превращает обычное обращение к массиву.
То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
Более того, добавлю г-ну Логику, что перемещение данных требует их чтение и запись, для которой точно так же надо использовать 16-ти битные адреса, причём не два раза для четния и 1 раз для записи головы и хвоста, а на каждый перемещаемый байт по 2 раза. Да ещё и процессору придётся в цикле попрыгать с выборкой из памяти команд. Боюсь, меня запозорят незнанием асм'а меги - вроде есть автоинкремент адреса, ещё не курил досканально асм, но строковой команды перемещения точно нету, аналогичной movsb. Кстати, про х86 - там шина 20-ти разрядная вообще при 16-ти разрядных регистрах и используются сегментные регистры, в которые можно лишь из РОН писать значение, тем не менее, никому в голову не приходит толкать даже с использованием строковых команд куски памяти колцевого буфера. :)
Кстати, а конвейер команд у меги есть кто-то знает? Догадываюсь, что нет, ну, а вдруг? :)))
А за меню - простите... Как обычно и бывает, про ТС уже подзабыли... :)))
Верно, именно это и изложено в #37 детально. :)
Ещё поправлюсь. В ПК, проверку закольцовки такого буфера не делают вовсе, про что и написал. Ибо операция "остаток от деления" как раз и производит такую закольцовку автоматически. Тут, правильнее сделать проверку, ибо "деления нет вовсе".
То есть код кольцевого буфера для контроллера следует писать не как для ПК, напрямую используя указатели, а как работу с 8-ми битными индексами массива. И тогда, вполне разумная аргументация господина Логика, перестанет быть актуальной, для буфера длиннее 6-8 объектов.
))))
А Вы вобще код смотрели? Из http://arduino.ru/forum/programmirovanie/ochered-sobytii#comment-188776 немножко выдеру сюда.
Втом то и дело. Я у себя написал 2 варианта работы циклического буфера, через указатели и через индексы, выбрал тот что короче и его запостил. От второго осталась одно упоминание указателя, которое и было замечено как ошибка)))
Более того, добавлю г-ну Логику, что перемещение данных требует их чтение и запись, для которой точно так же надо использовать 16-ти битные адреса, причём не два раза для четния и 1 раз для записи головы и хвоста, а на каждый перемещаемый байт по 2 раза. Да ещё и процессору придётся в цикле попрыгать с выборкой из памяти команд.
стати, а конвейер команд у меги есть кто-то знает? Догадываюсь, что нет, ну, а вдруг? :)))
Инкрементит быстро, в одной команде с записю/чтением. Конвеера нет, прыжки не сказываются. Ну не совсем, долго обяснять, читайте даташит (не в плане послал, просто там все описано лучше чем я тут смогу).
Как понимаю, ответов от вас ожидать не приходится. :)
Ну, так может на этом и остановимся в переходе на личности и будем обсуждать то, что полезно, нет? :)
Причём тут твоя личность, кому она интересна? Просто отметил, что если у кого-то ещё были какие-то иллюзии насчёт твоего уважения к участникам форума, читающим твой говнокод, то теперь их не осталось. Когда уважают читателя, не бывает пофигу сколь говнокода в постах. Ты ясно сказал, что на участников форума тебе класть и всё, что тебя интересует в этой жизни - это твоя великая личность. Так что обсуждай, что тебе полезно с кем нибудь другим. Я никакой пользы от обсуждений чего либо с тобой не вижу.
Как понимаю, ответов от вас ожидать не приходится. :)
Я уже старательно обходил тему "ответов" дабы не розвивать срач. Я уточнял, где вопросы, какие вопросы... Получил
Ваши не отвеченные вопросы находятся тут выше, пост #37 и даже выделены жирным шрифтом.
Смотрим 37-й... В полном обёме
faeton, писал: "Двигать кусок памяти менее эфективно, нежели указатели, если кусок памяти более размера указателей."
Верно, что я и пытался объяснить. Индексирование кольцевого буфера на массиве требует проверки для каждого индекса (головы и хвоста): выход за конец массива - "закольцовка" и "догон друг друга", чтобы голова не обогнала хвост и наоборот. То есть имеем 2*2 = 4 проверки. Да, их надо делать и при вставке и при извлечении из очереди. Итого 8 проверок. Для байтового индекса (буфер до 256 элементов) имеем короткие регистровые операции, вместо составных.
Для буфера "со сдвигом" элементов проверки выхода за границу массива - тоже необходимы. И точно также И на вставке И на удалении элементов. Тут, наверное, указатель тоже правильней делать индексом массива, а не как показано в говно-примере, ибо он становится байтовым. Но не уверен, надо смотреть. Лично мне - нафиг не надо (потому и не проверяю, ибо вполне достаточно оценочного анализа), ибо предпочитаю код не требующий буферизаций от слова "вовсе" - затратно оно "буферизация" и тормозит нещадно в целом, а для МК - это может ещё и быть критичным.
Далее. Буфер со сдвигом гарантировано требует переноса данных, и каждая операция переноса требует ЧТЕНИЯ из памяти и ЗАПИСИ в неё, элемента данных буфера (хотя бы 1 байта). [Такие операции у Атмела выполняются ЗА 3 ТАКТА каждая, о чем хорошо написано в даташитах (не все читают)] Исправлено: Операции чтения-записи исполняются нормально за 2 такта, соответственно ниже пересчитано тоже[]. Плюсом требуется посчитать и проверить счетчик переноса .. что ещё добавляет 1 операцию (посчитать) и 1 проверку и ветвление (переход - 2 такта!). То есть имеем гарантированные 5 операций на элемент переноса. Итого имеем 2+2+1+2 = 7 тактов на каждый байт переноса. Для более сложных элементов буферизации - тут все существенно усложняется.
Итого, в сравнении у нас остается 6 проверок (посчитать и перейти = по 3 такта = 18 тактов) против переноса данных (по 9 тактов на элемент).
Отсюда вывод: буфер со сдвигом становится эквивалентен буферу на индексах "голова","хвост" при его размере .. 2-3 байта. Что [практически] полностью совпадает с утверждением, цитированным выше:
"Двигать кусок памяти менее эфективно, нежели указатели, если кусок памяти более размера указателей."
Оно конечно же очевидное, как и предыдущий урок по обработчику TWI (I2C):
"Всякий неблокирующий код предпочтительнее любого блокирующего и, тем более, при равных или похожих затратах на время и место"
Но .. видимо не для каждого. :)
Из них жирным
faeton, писал: .....
Исправлено: Операции чтения-записи исполняются .....
"Двигать кусок памяти менее эфективно, нежели указатели, если кусок памяти более размера указателей."
"Всякий неблокирующий код предпочтительнее любого блокирующего и, тем более, при равных или похожих затратах на время и место"
Где здесь вопрос?
Ты совсем больной?
Справка о состоянии верхнего конца туловища есть?
Просто уникал, он пока 3 раза не облажается - не успокоится. И так каждый раз. Т.е. пока два раза - обязательно требует третий 8)))) Может бот какой, мазохистской направлености?
не обижайте бурята, русофобы.
Слышь, дятел? Ты свои фантазии, мне не приписывай, ладно? А заодно, притуши свою манию величия, тебя ВСЕ читатели, отвечать за них - не упономачивали. Так - ясно? Ещё один укурок.
Logik, слив - засчитан. Осталось научиться признаваться в собственных ошибках (ошибаются все, не все способны это признавать) и вопрос необходимости бороться за собственно ЧСВ, постепенно отпадет "сам собой". Мужайте. :)
У как развнерничался то! ))))
Хотели ответов сильно - так где вопросы в #37 жирным шрифтом? ;)
"Когда меня режут - я терплю, но когда дополняют .. это становится нестерпимо" (с) Барон Мюнхаузен. :)
тебя ВСЕ читатели, отвечать за них - не упономачивали.
Простите, что вмешиваюсь., Не знаю "все или не все", но фраза
меня тоже неприятно резанула. И я тоже считаю её признаком неуважения к читателю.
Вы, иногда хотя бы, думайте, что говорите.
ЕвгенийП, давайте читать фразу в контексте, а не выравывать отдельные слова из него. Было так:
"В отличии от вас (и вы тут не одиноки), детишек с недоразвитым ЧСВ, прибегающих оскорблять всех и вся (кстати - извиняться планируете или так и пожелаете остаться уродом в глазах читателей?), мне - пофигу как ваше мнение про меня так и количество говнокода в моих постах. Нашли ошибку? Искренне благодарю, спасибо."
Так что речи про то что мне пофигу на мнение читателей - не было ни разу. Не надо меня ДОПОЛНЯТЬ.
Мне - глубоко пофигу, на те подколы и оскорбления которые регулярно сыпятся из уст говнокодеров в мой адрес или в адрес моего кода в постах - весь смысл той фразы.
Не надо меня ДОПОЛНЯТЬ.
Вас никто не дополняет. Я лишь пытаюсь Вам обяснить, что из этой фразы люди деают вывод, что Вам пофиг насколько качественные вещи Вы ИМ (людям) пишете. Вполне допускаю, что Вы это не имели в виду, но я уже третий человек, который воспринял именно так и сделал такой вывод - третий! Просто подумайье о том, что Вы пишете и как это воспринимается людьми. Хотя, конечно, проще подумать, что мы все трое восприняли неправильно (народ плохой попался).
Господа, а давайте жить дружно? :) Ну, пацапались немного, а теперь уже успокоиться пора бы. Логик всё равно никогда не признается, что двигать память некузяво и фигню ляпнул, но почитал и себе втихоря вывод сделал. :) Ну, и ладно - лишь бы человеку на пользу пошло. :) А то уже как в анекдоте: - Илюшенька, а может быть, ну её нафиг эти разборки? :)
К тому же, к суровому спору по сути, на шум уже подтянулся и тот, кому просто что-то ляпнуть надо..., и нравоучения пошли от других участников... :)
К тому же, к суровому спору по сути,
Этот бессмысленный холивар (он же срач) Вы называете "спором по сути"? :))) Спасибо, повеселили с утра.
О сути таких споров замечательно сказал классик:
Вот, скажите, вам троим продавцы попкорна приплачивают? Или Вы им (попкорном) сами торгуете?
Вот, скажите, вам троим продавцы попкорна приплачивают? Или Вы им (попкорном) сами торгуете?
Речь в обсуждении шла о плохом приёме программирования со сдвигом кусков памяти. Если Вы ищите в обсуждении форму выражения, но не суть - Ваше право. :)
Нашел статейку по теме, может пригодится кому.
Нашел статейку по теме
тут, что, кроме срача ещё и тема была? Или статейка по теории срачей?