У топикстартера
tavrasm,
а большинство местных мастеров ассемблера работают под AVRASM2
(АВР студио 4.19 или более поздняя 7/микрочип студия).
Оттого возможны весьма существенные разночтения - не изучать же детально описание tavrasm для разовой консультации...

относительно GAS GCC это вообще "отдельно садомазохистская тема"

У меня есть небольшой проект выходного дня, некий отладчик по USART. Практического смысла, возможно, не имеет, но мне просто интересно. Задумок по нему очень много, реализовано пока далеко не всё. Не буду вдаваться в подробности парсига, после обработки принятых по USART данных есть номер элемента в массиве адресов, после чтения которого выполняется косвенный переход.
Адресов в массиве в виде:
Table_Vectors_Registers_Array:

.dw R0_Array
.dw R1_Array
.dw R2_Array
.dw R3_Array
.dw R4_Array
.dw R5_Array
.dw R6_Array
...................
больше сотни. Считать их вручную - сдохнуть можно.
.equ Count_Register_Const = PC-Table_Vectors_Registers_Array - решает эту проблему. Данная константа нужна для парсинга данных. Этот способ придумал не я, подсмотрел на каком-то забугорном форуме, концов уже не найти.
Если у Вас есть способ, как это можно сделать по другому, поделитесь, пожалуйста, возьму на вооружение

Вот несколько скриншотов, что умеет делать моя сырая прога, но это не весь реализованный функционал на данный момент)

Всего-то обмен с терминалкой в ПК?

Я чуток получше, но на MCS51, делал (включая командный режим)...
viewtopic.php?f=62&t=156720
На АВРках или МК с достаточным ОЗУ или меги с внешним ОЗУ-накопителем аналогом могут быть.
Смысл построчно каждый байт DW прописывать-то(вместо одной строки)?
Это ведь простая таблица векторов размером в слово (а не побайтовые таблицы смещения/скоростных перекодировщиков).

Командный режим тоже есть)
Для удобства восприятия информации) памяти в обоих случаях расходуется одинаково)

А не проще "база + смещение" (Z+N и IJMP/ICALL)?
При вычисляемом (принимаемом) смещении (или готовом 2-байтовым адресом в теле команды)?

Да и целая тема по АВР ассемблеру уже есть:
viewtopic.php?f=57&t=5931

Именно так и реализованно.
Чтение 2 байт "адрес массива+номер адреса необходимой подпрограммы" и icall)

Но в таком случае размер массива векторов не требуется.
Достаточно указания имен точек входа...

А как тогда парсеру понять, что мы прочли последний адрес массива?
Там ведь какой принцип работы:

на каждый адрес массива
.dw R0_Array
.dw R1_Array
.dw R2_Array
.dw R3_Array

идёт массив данных и адреса
R0_Array:
.db "R0 ",0x00
R1_Array:
.db "R1 ",0x01
R2_Array:
.db "R2 ",0x02
R3_Array:
.db "R3 ",0x03

этот массив сравнивается побайтно с буфером в RAM (куда складывались данные из USART) и если он совпал, то номер элемента из массива адресов сохраняется куда-то для последующей работы. По этому алгоритму нужно знать, сколько адресов в массиве, чтобы не улететь чёрт знает куда)

Иван Михайлович, вы забыли главный закон инженера. Обьект. Свойства объекта. А это определенный склад ума. Так что фора есть.

Я давно уже на асме толком не писал. Лет 10. Так. Баловство. Я тогда на си перешёл. Окончательно и бесповоротно.

Мой способ тоже костыльный. Но. Ошибок не будет.

Способ очень похож, но более понятен, спасибо!

А зачем все эти навороты?
Строку файла intel hex8 даже 51я на 1МГц успевает и развернуть и проверить и разместить во внешнем ОЗУ накопителе (при скорости обмена 9600). При том, что еще и эхо возвращает в окно терминала...

Рад был помочь. От PC в вашем случае уходите. Чревато.

Разве это навороты?
Просто алгоритм, который мне в голову пришёл

Считаю тему закрытой. На асме определения размера массива способов больше нет. Одна из причин ухода на си.

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

Но то уже "отклонение от темы".
потопаю дрематки.

Я не очень понял, это как?

Иван Михайлович, Что то ваши способы мне не нравятся. Если будут в дальнейшем вопросы, затруднения. Пишите в личку. Либо подробнейше поясняйте ваши мотивы.

И я вас не сразу понял. Почему. Зачем. А главное, на куа так через (_._).

Я делал нечто подобное. Вынос состояния регистров, ячеек памяти МК. Периферии МК. Состояние регистров периферийных модулей. Ртк, АЦП и так далее. И делал это по другому.

Добавлено after 3 minutes 4 seconds:
1. В дефайнах компилятора все регистры МК уже как то обозначены и пронумерованы.
2. Отсюда. Вы делаете лишнюю работу по нумерации регистров и это чревато ошибками при переходе на другие МК. Задача инженера ИСКЛЮЧИТЬ челоческий фактор и ошибки ещё даже на этапе помыслов.

Понимаете?

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

Модераторы. Просьба оторвать уши Мартину. За то что влез со своими сапогами из навоза в мой рейтинг. Я вас давно просил. Отключите к едреней фене у меня функцию кармы и рейтинга. Мне это не интересно. Зато любая сволочь рада при своей неправоте нагадить мне в рейтинг и в карму.

Добавлено after 27 minutes 46 seconds:
Про художника не нужно. Если у вас нетрадиционные взгляды (не глумление! я сказал как есть) на вещи и они приносят результат, это только приветствуется. Но привносение хаоса в инженерные вещи не приветствуется.

Я бы назвал их не стандартными