AVR всегда для сегментов DATA и RODATA резервирует флеш. Содержимое сегмента DATA bootloader копирует в RAM, а RODATA - нет. Во флеш не попадает лишь BSS сегмент.

Добавлено after 4 minutes 49 seconds:

Там не ни слова о сегментах кода и данных. Так что опять мимо.

Откройте мануал на avrasm и процитируйте из него свое утверждение.

Добавлено after 2 minutes 38 seconds:

Что такое "AVR", которое что то там "всегда"?

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

Пусть иные. Раз мои утверждения ложные, то эти "иные" это докажут.
Я жду цитаты.

Я не хочу уходит от темы обсуждения того, что, по Вашему утверждению, в сегменте данных содержится код.

Берем Тиньку13. Я с удовольствием посмотрю, как вы из СД-карты загрузите в ОЗУ табличку 256 байт. Или пожертвуете четверть доступного флеша на нее.

Вы нагло лжете. Я ни в каком месте не утверждал, что в сегменте данных находится код. Это принципиально невозможно. Это гарвардская архитектура.
Я утверждал, что ТАБЛИЦЫ находятся во флеше и потому описываются в сегменте кода. Так устроен avrasm.

Это будет уже третье изменение постановки.

Добавлено after 42 minutes 40 seconds:
Поэкспериментировал. Что касается извращений - я явно был не прав. AVR ассемблер не позволяет создать объектный файл с сегментом данных RODATA. Для того, чтобы создать объектный файл с сегментом данных RODATA пришлось извращаться через avr-gcc. Только после этого прошивка всё же собралась линкером.
Так же я был не прав с копированием сегмента DATA из флеша bootloader. В случае ассемблера такого не происходит, только в startup коде GCC.
В итоге, разместить таблицу в сегменте данных RODATA мне удалось, но это оказалось далеко от общепринятого и не средствами avrasm.

ПростоНуб, сегмент DATA - это ОЗУ. а когда ты подаешь питание на МК, в ОЗУ находится хаос, и никакие нужные для работы данные в ОЗУ не появятся.
а чтобы в ОЗУ поместить нужные данные (твою таблицу) нужен кусок кода в программной памяти. так что, любые данные в сегменте данных - это код из программной памяти.
у меня, например, все данные, нужные для работы, находятся в еепром. и при включении эти данные читаются из еепром и копируются в ОЗУ.
и только когда данные (например таблица) лежит во флеши, дополнительный кусок кода для их копирования в ОЗУ не нужен. но при расположении данных во флеши сразу видно, что это часть кода.

Для AVR, с возможностью этого можно не делать. У меня довольно много данных и переписывать их никакого ОЗУ не хватит.

Развели канитель.
Я привёл код - несколько XORов. Кто-то сможет короче и быстрее?

Речь про вот эти несколько XORов?

Gudd-Head, вы привели картинку с текстом. Но не код на avr asm.

Вариант цикла (Starichok51, ваш вариант, я так понимаю +/- такой же)

R1:R0 - исходное значение

R3:R2 - результат.
Длина кода 14 байт.

Кто хочет спорить - тому будет третье. Кто хочет решить задачу - предлагает решения, даже в виде картинок.
В постановке задачи было - - т.е. без привязки к конкретному МК. Значит код должен корректно работать на любой старой доброй 8битной AVRке.

Именно про эти.
Но тут есть маленькое но. Компилятор с ЯВУ зачастую сгенерит не самый оптимальный по размеру код.
Поэтому то я и прошу Gudd-Head показать код на асме, а не скан книжки.
Ибо его код, возможно и быстрее будет выполняться, но никак не короче.
А в постановке задачи было

Но почему то под минимальным все считают самый быстрый, а не самый маленький. Самый быстрый - табличный, но он не маленький )))))

Добавлено after 9 minutes 32 seconds:
Adrift, Кстати, если тупо в лоб циклом, то он компилируется в более короткий код.

А не поменять-ли rol r2 и r3 местами?

Так не честно, в "Алгоритмических трюках для программистов" такого варианта не было )

ДядяВован, да, поменять.
(но размер кода не меняется)

Adrift, вот беда... Шож теперь делать?.....

Кстати, шифты на более чем 1 бит ( >> 2, >> 4...) на AVRках одной командой (в общем случае) не делаются. Нет такой команды....

Первая задача решается «в лоб», поэтому решение появилось.
Вторая задача не совсем в лоб. Вот мой вариант из 5 команд.
Yes – метка перехода, когда в байте один единичный бит.
r0 - исходный байт.

LDI r20, 1
L0:
CP r0, r20
BREQ Yes
LSL r20
BRNE L0

Я на обычном ассемблере, практически, не работал, но как-то так.

Поменять, конечно.
Чтобы не думать о порядке следования байтов, на «хорошем» ассемблере есть команда Shift_R V, которая сдвигает переменную V на один шаг вправо.

Естественно, подразумевался сегмент RODATA, который мне успешно удалось создать и слинковать, хоть и avrasm для этого не хватило.


Это само собой. Просто, так как я пользовался ассемблером исключительно из С, то упустил, что именно его загрузчик перемещает сегмент данных из флеша в оперативку.


Как это видно? Видно, что на них управление передается?
Может здесь принято иначе, но когда я употребляю по отношению к программированию слово "код", это я просто не уточняю, он "машинный", "исходный" или промежуточный (как у LLVM).
То есть, код - это инструкции CPU или то, что привело к их формированию бекэндом-кодогенератором или компилятором.
И если данные были конвертированы из бинарного файла в объектный при помощи objcopy, то когда и как они вдруг превратились в код?
А если я на STM8 загружу код в RAM и выполню его оттуда, это будут данные или код? )))

Добавлено after 2 minutes 49 seconds:

Я пока так и не понял постановку задачи. Требуется оптимизировать размер кода или его производительность? В зависимости от этого задача решается по разному.

Представьте, что у нас один из тех конкурсов где нужно писать программы ограниченные по размеру до 1/4/64...КB. Слышали же про такие? Простые и понятные абсолютному большинству условия и я сомневаюсь что был хоть один случай когда вместо программы размером 1КB приносили программу на 1GB и доказывали, что сама программа то 1KB, а все остальное - данные загружаемые с внешнего носителя )

к размеру кода вопросов нет


Коротко конечно. Но с допущением, что входящее значение имеет только один единичный бит. Если больше или ноль, то зависли.