Это как раз и имелось ввиду, т.к. ещё не встречал архитектуры с порядком следования байт отличным от формата младший-старший. Например, код команды LPM Load Program Memory 0x95C8 в листинге видится как 0xC895.

Спойлер

Директива .DB позволяет нарушить этот формат, в отличие от директивы .DW Можете попробовать.

akl, спасибо.

Я и не писал, что он что-то считывает...Он считает -- поэтому и "счетчик"

Ок, не буду морочить голову. Теперь вопрос более прикладной. Командой .db заносится массив чисел, который в процессе работы программы, выгружается, например, в порты. Но с тем же успехом, я мог бы занести этот массив в ячейки ОЗУ (которые идут после адресов РОН и РВВ) и считывать массив оттуда.

Зачем ОЗУ, предначенном для врЕменного хранения данных использовать для хранения констант.

Ясно, для экономии ОЗУ и единообразия логики работы с данными. Просто я сперва решил, что косвенная адресация -- это необходимость, а оказалось, что для удобства.

Из ОЗУ выборка быстрее

Да, быстрее, но всю скорость съест загрузка.

Так и остальное надо оптимизировать.
Копейка - рубль бережет.

Если речь о неизменных константах - предпочтение ПЗУ, если в процессе работы программы данные изменяются - предпочтение массиву в ОЗУ. При том, что в некоторых ситуациях размещение будет равноценным (просто прийдется использовать иные наборы команд для доступа и использования данных).

Здесь я полностью согласен, если не критично время выполнения.

не надо путать счетчик команд и указатель адреса (в данном случае регистровую пару Z).
указатель адреса адресует побайтно.
тем более, что есть команды длиной больше 1 слова. поэтому счетчик команд считает команды, а не слова.

Я не соглашусь с такой формулировкой. Организация памяти программ в AVR n*16. Я не видел подробной схемы организации памяти и шин AVR, но все указывает на то (по моему разумению) что шина данных для памяти программ 16 битная, возможность (физическая) чтения данных побайтно отсутствует. Считайте что ячейки памяти 16 битные. Записи побайтной тоже нет.

Т.е. счетчик команд адресует именно слова (а не считает команды) и не потому что нет команд однобайтных, а потому что ячейки памяти 16 битные. Изменение счетчика команд производит декодер команд.

присутствует.
меня не волнует, как команда lpm выбирает всего один байт из программной памяти. скорее всего, точно также, как из ОЗУ - побайтно, а не из слова.
а что нет записи в программную память - это всем известно.

да, счетчик команд выбирает слова. но сколько слов он выберет, зависит от длины команды. именно поэтому он считает КОМАНДЫ, а не слова.
и в отладчике ты НИКОГДА не сможешь сделать точку останова внутри двухсловной команды.

То что программиста не должен волновать этот вопрос, я обозначал. В ДШ указано что организация памяти программ 16 битная. Равно как при 8ми битной организации, не читает ядро ниблами, так и тут не читает байтами. Кроме того, не кажется странным, что МК выбирает 16битную команду за один такт, а один байт данных читает аж за три? Точно также биториентированные команды не работают с битами по факту. Выборка байта из СОЗУ и модификация бита, запись байта обратно или Вы думаете для каждого бита есть свой адрес ? Это ж какая шина адреса должна быть? Счетчик ничего не выбирает, это всего-лишь указаетель. Этим занимается декодер команд и значение программного счетчика тоже меняет декодер команд, в зависимости от команды и ее результата. Конечно нельзя, первый раз вижу что такое можно даже обсуджать. Есть, но только по словно, опять же из-за 16 битной организации флеш, перед этим стирая страницы.

Побайтовое чтение данных (не команд!!) для АВРок обычное дело.
Только вот... Всегда внимательно надо смотреть как на исходное содержимое указателя в Z, так и на применяемое смещение. В смысле когда непосредственно используем, а когда со смещением на один бит.
Вечное нервотрепство - НО...
ДАНЬ МК с ФИКСИРОВАННЫМ РАЗМЕРОМ КОМАНД.
Счетчик команд всегда кратен размеру команды, а доступ к данным (в основном) байту.
Разница при обращении к ПЗУ в табличном режиме заметна в случаях:
обращение к ПЗУ как к содержимому символьной строки данных (побайтовое считывание)
обращение к ПЗУ как к скоростному шифратору/дешифратору кода (побайтовое считывание)
обращение к ПЗУ как к таблице векторов (вычисляемый прерход) - пословное соответствие в случае, когда в таблице расставлены вектора (смещение вырабатывает программа) и побайтовое чтение, когда таблица содержит смещение к вектору (программа задает условие выбора смещения. том числе относительно текущего счетчика команд). Вот в последнем случае действительно мозготрепка и повышенное внимание к содержимому требуется - какой способ применить зависит от конкретики задачи.

Вообще-то AVR-овцы конкретно лопухнулись с командами LPM. По-хорошему, надо было вместо одной LPM сделать две команды - что-то, вроде LPLB (загрузить младший байт из программной памяти) и LPHB (старший) и не морочить голову программистской общественности. Да, несколько сложнее организовать подпрограмму последовательного чтения вроде getch(), зато никаких проблем с адресами. Адрес в программной памяти был бы всегда словным, и никаких вопросов, включая и 128-К контроллеры.

А по-моему было бы не удобно считывать некий массив данных разными командами. Возможно не хватает команды LPW (считать слово), но не вместо LPM, а плюсом.

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

Насчет команд LPM - все весьма удобно.
Кому чего добавить хочется - имеем макросы самодельные (как пожелаем назвать/матюкнуть - так и будет).
Это особенность архитектуры с минимальным набором команд (да и не только -макросы всюду имеются).
Гораздо хуже некоторая разница в функционале определения значения в Z между командами
LPM и IJMP/ICALL, также использующими Z в качестве указателя адреса.
Хотя... и это в принципе преодолимо...

Кто предложит расчет логарифма 16 бит на асме ?

Вопрос из серии "на деревню - дедушке" . Двоичный, десятичный, натуральный ? Логарифм имеет практический смысл для float арифметики, а какая float на 16 битах ?