Ну что же Вы такой вредный? Допустим я сделал какое-то специфическое размещение данных в памяти, скомпилировал исходник и определил, что нужная мне ячейка имеет адрес 0x0120. Но по каким-то причинам (схемотехнические хитрости - как та же внешняя память программ/данных или еще чего поизвратнее) поручить компилятору автоматическое вычисление этого адреса невозможно. Вот тогда я и буду использовать .EQU name = 0x0120 для доступа к той ячейке. Довольно типовое решение к примеру в моей котуинке (биос + подгружаемые во внешнюю совмеенную память программ/данных целевых программ устройства)...
Последний раз редактировалось BOB51 Чт янв 18, 2024 19:46:42, всего редактировалось 1 раз.
Человеку присуща деликатность, критикуешь других, критикуй себя, фифти-фифти. Сначала признайся в собственной глупости, а потом других дураками называй! На каждого мудреца довольно простоты.
Ну что же Вы такой вредный? Допустим я сделал какое-то специфическое размещение данных в памяти, скомпилировал исходник и определил, что нужная мне ячейка имеет адрес 0x0120.
Для этого, внезапно, есть .org Это специально созданный гвоздь для прибивания адреса. И вы это знаете не хуже меня. Кстати, корректное резервирование памяти позволяет любой АСМ код использовать вместе с Си. В отличии от...
И тут я решил изменить размер буфера передачи, на один байт... По-моему нижний вариант просто удобнее. Ну да, я не знаю какой по факту адрес у конкретной переменной, пока в .map или в .lst не посмотрю, но оно не часто и нужно. ИМХО для каждой директивы свое применение.
_________________ Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
Сдается мнение, что критикой занимаются пользователи Си. Я полностью согласен со Старичком, т.к. мы с ним активные Ассемблерщики. А в Ассемблере контроль размера буфера переменных лежит исключительно на программисте, как и расположение их в памяти МК. Тем более при пошаговой отладке знать точное распределение памяти (RAM, EEPROM, Flash) крайне необходимо.
Сдается мнение, что критикой занимаются пользователи Си.
Мнение НЕ верное. Я занимаюсь критикой, но на Си из полусотни проектов для 8 бит (те, что в серийных изделиях - хоббийные не в счет) написан лишь один. Но поскольку я пишу и на Си (это проекты для АРМов), то у меня есть вполне определенный взгляд на написание кода вообще - независимо от языка.
А в Ассемблере контроль размера буфера переменных лежит исключительно на программисте, как и расположение их в памяти МК.
И как это противоречит использованию .byte? Вы очевидно не понимаете, что никакого "принудительного" размещения в ассемблере нет НИ ПРИ КАКИХ синтаксических оборотах. Просто принципиально нет.
Тем более при пошаговой отладке знать точное распределение памяти (RAM, EEPROM, Flash) крайне необходимо.
И что? Именно директива .byte позволяет получить ВИДИМОСТЬ переменных ПО ИМЕНИ. А адрес и так всегда указан рядом с именем. Такшта вы просто пытаетесь критиковать "вкус устриц", ни разу их не пробуя... И это действительно факт. Железобетонный.
Ну да, я не знаю какой по факту адрес у конкретной переменной, пока в .map или в .lst не посмотрю, но оно не часто и нужно.
С чего бы вы не знаете? И смотреть в map или lst нет никакой необходимости. В окне Watch адрес рядом с именем обозначен. В тексте кода имя переменной является ее адресом, поэтому и тут нет необходимости обращаться к численному значению. Ну и достаточно просто обозначить через org начало списка byte.
Gennadiy, а зачем контролировать размещение в памяти переменных, вручную задавая адреса, если среда разработки (в данном случае AVR студия) сама позволяет их расставлять? Я же привел выше пример. Что вы будете делать, если в начале адресов переменных придется изменять их размер или количество? Все следующие адреса вручную пересчитывать и переписывать? И это не только вопрос удобства. Я (да все, кто более менее большие программы пишет) весь код делю на модули, UART - отдельный asm-файл, SPI - отдельный файл, работа с каким-нибудь дисплеем - отдельный файл, так и к ним еще inc файлы. Например UART.inc с константами для определения/вычисления скорости, размерами буферов, кодами команд, и там же - выделяем области памяти в dseg. И не надо среди всего кода искать то что относится именно к UART. И эту пару модулей, можно в другом проекте использовать с минимальными переделками, не боясь что области памяти друг на друга налезут, т.к. все переменные на этапе компиляции сами в нужное место встанут, в зависимости от того, где .inc в тексте основной программы вписать! А в случае использования для резервирования .equ? В одном модуле определил адрес массива в 200 байт, а в другом можно случайно одну переменную для какого-нибудь счетчика в середине этого массива определить, и здравствуйте глюки... Ни кто не запрещает equ для переменных, ну например в целях той-же отладки какой-либо определенной переменной, ну или если нужна какая-либо хитрость, выравнивание, чтобы буфер или массив начинался с адреса хх00, но в 99% случаев этого не нужно.
КРАМ, я отладкой занимаюсь либо протеусе (пока железка не готова), либо в железке, так вот протеус со списком watch из студии подружить не получается, там приходится адреса вручную вбивать
_________________ Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
Можно взглянуть на пример использования (запись/чтение/модификация) переменной, созданной с помощью директивы .byte, в Ассме? И да, у меня тоже есть большие проекты критичные ко времени исполнения (real-time), содержащие до 10 массивов, 206 (на данный момент) переменных и флагов различной размерности. Я не представляю, как во всем этом можно было бы ориентироваться (при пошаговой отладке), не пригвоздив каждую к конкретному месту, полагаясь только на среду разработки. Возможно Ваши примеры направят меня на путь истинный. Без подколов и шуток, покажите преимущество .byte, пожалуйста.
Чтение/запись/модификация будет выглядеть точно также, можете просто переписать весь код определения переменных с .equ на .byte а все что в .cseg - не трогать, оно скомпилируется без ошибок! Что для .equ ИМЯ=АДРЕС, что для ИМЯ: .byte РАЗМЕР, и там и там компилятор генерирует пару ИМЯ-АДРЕС, только в первом случае адрес задает программист (а он может ошибаться), а во втором его вычисляет компилятор автоматически.
_________________ Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
Значит, есть желание контролировать память - .equ, нет желания париться с этим вопросом (пусть компилятор сам решает) - .byte. Так? Спасибо. Тогда в чем весь сыр-бор, устроенный тут? Ведь обработка переменной, длиной отличной от 8 бит, все-равно ляжет на плечи программиста.
Gennadiy, Перечислите случаи, когда вам нужно было "прибивать" переменную гвоздями к конкретному месту в ОЗУ? Вот когда переменная должна лежать только в этом месте и ни в каком другом? equ именно это и делает. Но тогда распределение переменных в ОЗУ становится вашей головной болью. Переносимость кода резко падает. Поскольку в других проектах нужно заново пересчитывать расположение переменных в ОЗУ. И зачем? Есть правильный инструмент, поддерживаемый компиляторами и отладчиками. но нужно придумывать что то свое. Директива equ говорит компилятору, где должна быть переменная. А директива byte - сколько занимает ваша переменная. И к той и к другой можно обращаться одинаково - по имени. Но в случае изменений в проекте, когда надо буферу размерчик добавить, или ввести новую переменную - придется руками пересчитать все equ, которые лежат после новой переменной или обновленного буфера. В случае byte - компилятор сам подвинет все прозрачно для программы.... И в 99.8% случаев это никак не повлияет на программу. Остаются редкие случаи, когда на область ОЗУ проецируется какая то периферия или внешнее ОЗУ - там да, нужно явно указать, откуда оно начинается. Или когда буфер должен начинаться с какого то кратного адреса, что б указатель легче обсчитывать ... Но это блин , настолько редкие случаи.... Откройте любой учебник по асму, прочтите, как резервировать ОЗУ - и радуйтесь жизни
Значит, есть желание контролировать память - .equ, нет желания париться с этим вопросом (пусть компилятор сам решает) - .byte. Так? .
Поток сознания. Компилятор ничего не решает. После привязки через org адреса идут по списку строго последовательно. Так что по сути программирования никакой разницы нет. Если не считать того, о чем я сказал ранее.
Согласен с Вами, по сути программирования никакой разницы нет. В итоге имеем имя к которому обращаемся в программе. Почему прибиваю? Да потому что в отладчике мне удобнее ориентироваться в данных, которые именно я разложил "по полочкам", а не компилятор. По Вашим словам "Именно директива .byte позволяет получить ВИДИМОСТЬ переменных ПО ИМЕНИ. А адрес и так всегда указан рядом с именем." Вопрос. Директива .equ не позволяет сделать то же самое, заменяя имя переменной ее адресом, указанным в листинге? Немного возни с порядком, зато полный контроль за процессом.
Gennadiy, в нормальном отладчике как раз наоборот. Переменные через .byte видны как переменные и их не нужно искать в простыне содержимого памяти. Ну да дело ваше. Кому и *** невеста.
_________________ Платы для HLDI - установки лазерной засветки фоторезиста. ФоторезистыOrdyl Alpha 350 и AM 140. Жидкое олово для лужения плат (видео) - самое лучшее и только у меня. Паяльная маска XV501T-4 и KSM-S6189 (5 цветов). Заказ печатных плат - pcbsmac@gmail.com
Микроконтроллер at90s2313 не имеет команды LPM Rd, Z+ Вопрос чем заменить. Подскажите.
У меня симулятор такую конструкцию проглотил: lpm ; //mov (куда надо), R0 ; ld r16, z+ ; в любой свободный регистр Без проблем читает с конца флеша. Как в реальном мк будет - хз, нет такого в наличии..
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 37
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения