Ага. Взял эдак, скопипастил, грохнул бездумно 256 байт RAM на AVR, и пользуешься. А что, зато "переносимо".

Я решаю задачи (взяв AVR с большим количеством памяти, чем нужно будет когда то), а уже потом оптимизирую. Вы видимо в обратном порядке, ну что же, флаг в руки.

А во вторых человек настолько хреново разбирается в том, что вы ему пытаетесь объяснить, что помоему тут разговор не об экономии 256 байтах RAM'a...

С таким подходом к решению AVR'а с достаточным количеством памяти может и не найтись. Сначала надо продумать, потом написать, а затем оптимизировать. В предложенном вами решении первая часть отсутствует совершенно.

Я, кстати, тоже использовал табличку для разворота порядка битов на AVR. Только табличка была расположена во флеш с выравниванием по границе 256, а вся операция сводилась к одной команде lpm.

Вы правы, действительно ошибся.
lsl надо заменить на rol, lsr на ror.
11 тактов и получится. Перепроверьте.
Соответственно код на Си тоже надо подправить.

Поправленный код

Вот приучится в тупую делать простые вещи и так и будет по табличке всю жизнь. Не на столько сложная задача.

Понятно, что оптимизация просто ради оптимизации - никому не нужна. Но тут другой разговор идет.
AVR - это всё таки не PC и разбрасываться ресурсами(а в конечном итоге и деньгами) ИМХО не стОит.
И что плохого, если люди вступили в дискуссию и пытаются создать максимально оптимальный код под задачу?
Лично я ничего плохого не вижу в этом. Вон с 13 тактов уже на 11 переползли. Может быть некоторые бы и до конца жизни не знали, что это возможно )))))))

И флаг Вам в руки, когда вы с такой привычкой реализуете что-нибудь на меге 128, а другой разработчик сделает тоже самое на тиньке какой-нибудь вшивой

Нет, все равно ошибка.
Смотрите:

получили agfedcbx
а нужно hgfedcba

Да, облажался. Мне показалось, АВР делает циклический сдвиг регистра, ступил.

Такое впечатление, что все ваши начальники понимают, о чем здесь речь и оценивают вашу работу по количеству использованной памяти в мк, а не по результату (работает / не работает). Тоже самое относится ко времени, которое дается на разработку...

Я например не могу объяснить своему начальнику, что такого прекрасного в экономии 256 бит памяти на начальном этапе разработке. А уж тем более почему я потратил на это половину своего рабочего дня.

А Вы думаете, что большинство делает иначе?

Ничего плохого в этом нет. Просто я бы это все в отдельную тему выделил. Новичек в этой куче сообщений не найдет простого решения (которое будет работать с любым мк).

Сколько времени у Вас уйдет, чтобы переписать этот код на ассемблере для другого Вам неизвестного ранее мк? А при этом Вы профессионал своего дела, а новичек скорее пойдет в соседний форум и найдет там как раз самое просто решение и использует его.

256 Байт.

А этот уже страшно . На эту задачу на 'C' надо тратить 10 минут, даже если ночью разбудить. Набивать таблицу на 256 байт дольше и ошибиться легче.
При этом на 'C', если чуть чуть думать, это будет достаточно портируемый вариант.

Спокойнее, как выяснилось, писать на ассемблере практически бесполезно.

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

sergeeff Jr
Тут речь не оптимизации ради оптимизации.
Проинвертировать биты в байте таблицей не факт, что проще. Причин несколько:
- размер кода;
- время на кодирование (или тупое набивание таблицы);
- количество вызовов функции в общем времени работы программы.
Предложенный алгоритм с xor работает быстро.
Более того, в некоторых случаях он вообще будет работать быстрее, чем таблица (если таблицу хранить во внешней медленной памяти).
Отлаженный и качественный алгоритм с одного МК на другой на ассемблере (свежий пример - с 8051 на ARM9) переноситься за 1 день. И даёт выигрыш в производительности 3-8 раз по сравнению с кодом, написанным на C.
Для устройств, где важен каждый милливатт, это зачастую важно. Если Ваше устройство работает от аккумулятора 10 дней (с "вылизанным" ПО на ассемблере), а у конкурентов только 2 дня (на "copypaste'ном" С), то тендер Вы, очень вероятно, проиграете.
Зато потом будет масса времени объяснить своему начальнику, что такого прекрасного в экономии.

Байт конечно, очепятался я.

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

А тот, кто создал эту тему вообще скорее всего вникать не будет.

А урезателям бонусов еще раз скажу: когда вас поставят в положение - сделай плату, сделай прошивку, подготовь макет с прогой на компе, летим за тридевять земель к клиенту через неделю, тогда я посмотрю что вы будет в коде вылизывать, а главное когда.

А "тупое набивание таблицы" кто-то сделал до меня.

Если обратите внимание, в последних книгах по программированию, серьезные авторы предупреждают о вреде преждевременной оптимизации. Сначала получи работоспособную программу (устройство), а затем, при необходимости, займись оптимизацией узких мест.
Очевидно, что у каждого программиста со стажем накоплено оптимизированных функций и модулей на 95 % случаев. Автор топика, судя по задаваемому вопросу, программист молодой. Если он над каждым простым вопросом будет сидеть по две недели, конечное устройство не будет разработано в обозримом будущем никогда.

Думаете, "урезатели бонусов" не умеют работать быстро и качественно?


Да, а применение таблицы "из интернета" - это как раз отличный пример преждевременной оптимизации. С соответствующими побочными эффектами

Это все на тему - сделать работоспособное устройство (программу) в отведенные для этого временные рамки или развести дискуссию вроде "А не посоветуюте ли какой язык высокого уровня эффективнее использовать в моей разработке?" Жаркие дебаты будут будоражить пытливые умы не одну неделю, разработка будет стоять в ожидании этого самого оптимального ЯВУ. И самое забавное, что дискуссия ничем и не закончится.