Ассемблер (ASM) для AVR в вопросах и ответах

[afz]

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

Угу. Если это моя константа. Я же утверждаю, что так должны были сделать нормальные разработчики тех самых наборов описаний оборудования, которые мы включаем по .include для конкретного камня. А эти курили траву.

И вообще, на фига было обозначать биты их номерами? Сделали бы, как все нормальные люди, hex-маску, и не морочили головы народу. То есть, конечно, командам SBI/CBI, которые позволяют манипулировать отдельными битами регистров ввода-вывода, нужен именно номер бита, но кто мешал добавить псевдофункцию, допустим, BITNO, подобно LOW и HIGH для половинок слова. То есть, нормальные разработчики сделали бы примерно так

Код:

;----------
; Кусочек из содержимого 1200def.inc
.EQU   ACD     =0x80
.EQU   ACO     =0x20
.EQU   ACI     =0x10
.EQU   ACIE    =0x08

.EQU   ADIany  =0x00
.EQU   ADI10   =0x02
.EQU   ADI01   =0x03
;----------

И мы бы писали так:

Код:

.include <1200inc.def>
; мой код

; ...............

          LDI   R16,AD01 | ACD  ; запретим аналоговый компаратор и сделаем прерывания от него по переключению выхода компаратора из 0 в 1
          OUT   ACSR,R16

; .................

          CBI   ACSR,bitno(ACD)   ; включим аналоговый компаратор

; ..................

          SBI   ACSR,bitno(ACI)   ; Разрешим прерывания от аналогового компаратора. 

Здесь, для использования команд SBI/CBI, требующих номер бита, подлежащего установке/сбросу, использована гипотетическая псевдофункция ассемблера, возвращающая номер единственного единичного бита в своем аргументе, или выдающая ошибку, если у аргумента не один единичный бит.

Мне бы пришлось писать эти псевдофункции для каждой команды SBI/CBI, но, учитывая, что эти команды применяются достаточно редко, это мелочи. Зато мне не пришлось бы набирать непосредственные операнды для команд LDI из дурацких сдвигов единиц или нулей на какое-то число разрядов, заданное символически, что встречается во много раз чаще, и каждый раз вызывает злобное раздражение.

Последний раз редактировалось afz Вт мар 10, 2020 21:10:06, всего редактировалось 1 раз.

[BOB51]

Это особенности риск - упрощенной системы команд.
Для набора отсутствующего функционала используются макросы.
Заводим в них недостающие частоупотребимые микропрограммы и работаем.

Касательно *.inc файлов - их также люди пишут.
Помимо прочего появляются модифицированные кристаллы а в применяемом пользователем конкретном компиляторе набор *.inc файлов ОСТАЕТСЯ СТАРЫЙ.
Учитесь редактировать эти файлы самостоятельно согласно даташита на конкретный кристалл!

Использование набора команд и алгоритмов подразумевает опыт работы (и весьма полезные навыки при работе с разными МК и компиляторами).
Со временем никакого раздражения не наблюдается.

[КРАМ]

Alexeyslav писал(а):

КРАМ писал(а):

товарисчи из Микрочипа ничего об этом, вероятно, не знают и потому в MPLAB X обозвали вкладку контроля за темчегонет как Variables

Боюсь спросить, а вкладка имеет отношение к АССЕМБЛЕРУ, или это всё же надстройка IDE для удобства программирования на ассемблере? Кстати, может подскажете где в ассемблере есть КОМАНДА присвоения переменной в памяти значения, или может команда сложения двух ячеек/переменных? Если принять во внимание одно ограничение - что эти переменные находятся в регистрах то да, такие команды есть. Но с памятью на ассембере так не работают, чтобы сложить две переменные, находящиеся в памяти нужно реализовывать алгоритм из нескольких команд, задействуя регистры. При этом понятие "переменная" находится на уровень выше ассемблерного кода - в голове программиста. Для ассемблера же существует только такие понятия как регистр и массив памяти с побайтовым(пословным) доступом.

Алексей, потрудитесь прочесть то, что ранее написано. Я уже устал повторять одному, а уж второму - явный перебор. И про команды и про IDE с вкладкой для АССЕМБЛЕРНОГО проекта - все уже было сказано. Читайте и обрящете.
Но одно скажу точно. Вы говорите совершенно о другом. Даже когда человек рисует кубики блок-схемы алгоритма, то уже тогда он оперирует понятиями переменных (включая переменные-указатели), констант и прочих сущностей программирования. И все при этом нормально. Чем ближе будет АСМ код по строению и понятиям к ЯВУ, тем лучше он читается и тем эффективнее исполняется. А называть термины при этом Вы можете даже обсценной лексикой. Просто термины Си как то понятнее, тем более отличий по сути нет никаких, ибо САМ КОМПИЛЯТОР заменит выражение Си ровно на тот набор инструкций, который Вы напишите сами (с небольшими упрощениями, которые появятся в результате отказа от непринципиальных соглашений в Си).
Впрочем, мне понятна Ваша упертость в этом вопросе. Вы профессионально не пишите на АСМе. Поэтому вам глубоко по барабану манера написания кода на этом языке. Чисто пофлудить...

Добавлено after 9 minutes 40 seconds:

BOB51 писал(а):

А "переменная" в составе мнемоники команды - это оператор или операнд.
Хотя в принципе в комментарии упрощенно мы чаще обобщенно пишем "переменная".

Значит все таки пишите... А раз пишите, то пользуетесь этой сущностью.
Нехорошо, батенька... Очень нехорошо...
Становитесь в угол за такой оппортунизм.
Милостивые господа-законники на пустом месте. Вам не надоело гнать пургу? Или Вы и впрямь не в состоянии понять элементарное? Или коронавирус вас одолел до мозжечка?

[ARV]

Или Вы и впрямь не в состоянии понять элементарное?

за всех не поручучь, но за себя могу сказать: в состоянии.

только как же тебя понять, коли ты не говоришь ничего? ©

КРАМ, стиль оформления программы на ассемблере, никакого отношени к самому языку и его средствам не имеет. и какими именно абстракциями я или кто другой пользуется для ОПИСАНИЯ своего алгоритма - не имеет никакого отношения к ВОЗМОЖНОСТЯМ ЯЗЫКА. если язык не имеет встроенных команд для работы с переменными, то как ни крутись, использовать их СРЕДСТВАМИ ЯЗЫКА не получится, что бы там ни писалось в комментариях или алгоритме. это как раз то элементарное, чего вы не можете понять.

ну нет в ассемблере команд сравнения многобайтных "областей данных", что бы там ни хранилось! и чтобы реализовать эту возможность вы вынуждены пользоваться однобайтными командами, собирая из них целый алгоритм. а в любом языке программирования, поддерживающим настоящие переменные в том смысле, который я в вкладываю в этот термин, оператор > или < всегда будет работать с этими самыми переменными "по умолчанию", без ваших усилий. и это доказывает, что асссемблер лишен и термина "переменная", и инструментария для работы с ним.

с "переменными" работает не ассемблер, а программист на ассемблере может, так вам будет понятнее...

[Starichok51]

Проблема с ЕЕПРОМом не в том, что код содержит более одной инструкции, а в том, что оный ЕЕПРОМ в принципе не расположен в поле определения переменных

а чем "именованная область" в ОЗУ отличается от "именованной области" в ЕЕПРОМе?
а абсолютно ни чем!
если ты утверждаешь, что в ОЗУ есть переменные, тогда переменные точно также есть в ЕЕПРОМе.

Но можно пользоваться и копией, назвав ее подобающим образом

если скопировал ты данные из ЕЕПРОМа в ОЗУ, то и там в AVR не сможешь ими пользоваться напрямую, так как ни сложить, ни вычесть и никакую другую операцию со своей мнимой "переменной" в ОЗУ ты сделать не сможешь, пока не скопируешь ее в регистр.
НЕТ в ассемблере переменных, а твоя "именованная область данных" всего лишь твоя умозрительная конструкция.
попробуй, как в Си, написать в ассемблере X + Y,
где X и Y - именованные области данных в ОЗУ.
и посмотри, что тебе ответит компилятор на твои "переменные" ...

[ARV]

КРАМ, и вы таки пропустили мой вопрос о том, как отнесется ваш код на Си к тому, что в ассемблерном модуле я объявлю глобальную метку для куска памяти с другим размером, нежели внешняя переменная в модуле Си с тем же идентификатором...

Добавлено after 1 minute 50 seconds:

то и там в AVR не сможешь ими пользоваться напрямую

и не только в AVR, а вообще в любом ассемблере (за небольшим исключением системы команд i80x86)

[afz]

Это особенности риск - упрощенной системы команд.

Нет, это особенности мышления отъявленного паскалянта, не видевшего ничего, кроме Паскаля на писюке. И не видевшего ни одного приличного макроассемблера. Да, под современные "большие" процессоры на асме особо не попрограммируешь - что под писюк, что под АРМ - и задачи для них, обычно, такие, что без языка высокого уровня не обойдешься, и требуется взаимодействие с большим количеством "чужого" софта - с операционкой, с библиотеками чужих программ и т.п. Соответственно, и ассемблеры для них не особо показательные. А вот на старых системах были шикарные макроассемблеры - что на Системе-360/370, что на PDP-11. Посмотрели бы, как это делается "по-взрослому", а потом и сочиняли асм для своего АВР...

И вообще, если на АВР-ке задача перестаёт влезать в 8-ю Мегу, пора задумываться о смене платформы. А перестанет влезать в 32-ю Мегу - однозначно надо переходить на что-то, вроде STM32. Собственно, не считая мелких тинек, единственное преимущество АВР-ок перед STM32 - это возможность 5-вольтового питания. В частности, возможность кормить их напрямую от литиевых аккумуляторов. STM-кам от 4.2 В свежезаряженного аккумулятора точно поплохеет, а для АВР-ок (особенно тех, которые с буквой А) это штатный режим.

[КРАМ]

ARV писал(а):

с "переменными" работает не ассемблер, а программист на ассемблере может, так вам будет понятнее...

А что, собственно, это меняет, особенно если учесть, что ассемблер и Си существуют в одном логическом пространстве ОДНОВРЕМЕННО?
Вы предлагаете непрерывно переключаться с переменной на метку и обратно при работе со смешанным исходником?
А я то все никак не пойму баттхерта относительно АСМа... А тут вононочо....
Но одно я с удовлетворением для себя отметил - Вы в общем то верно ДЛЯ СЕБЯ заключили обсуждение.
Но лучше так, чем никак...

[ARV]

А что, собственно, это меняет

если по-вашему это не меняет ничего, то нет разницы вот вообще никакой и между разными языками программирования вообще - от ассемблера не отличается ни паскаль, ни Си, ни даже php... так? подумаешь, идеология языков разная - программист-то все равно один и тот же...

если у меня (ассемблера) нет велосипеда (переменных), это не означает, что я не смогу добраться из пункта А в пункт Б. но если я могу туда добраться, это так же не означает, что я не отличаюсь от владельца велосипеда (Си).

[КРАМ]

ARV писал(а):

если по-вашему это не меняет ничего, то нет разницы

У Вас отвратительная манера вести спор. Вы постоянно подменяете предмет обсуждения.
Разница между языками высокого уровня никакого отношения к разнице между ассемблером и ЯВУ не имеет. Потому что ассемблер не относится к ЯВУ, во первых, и потому что ассемблер является связующим звеном между ЯВУ и загружаемым кодом, во вторых. То есть ассемблер так или иначе должен сублимировать абстракции того ЯВУ с которым он взаимодействует.
Поскольку написание на ассемблере связано с рядом известных сложностей, программист вынужден применять методы и абстракции ЯВУ. Причем не важно какого. Скажем того, который ему ближе и который он использует чаще всего помимо ассемблера.
Без этого код полученный на ассемблере будет безобразным во всех отношениях, а реализация на нем задач чуть более сложных, чем условное "мигание светодиодом", будет вызывать значительные проблемы.
К тому же есть еще один аспект. Это миграция с платформы на платформу.
Если программист понимает логику взаимодействия системы команд МК с ЯВУ, переход на другую платформу не вызовет никаких сложностей - нужно будет лишь найти и понять аналогичную логику в этой другой.
И оная логика ВСЕГДА СУЩЕСТВУЕТ, ибо система команд МК (начиная с некоторых пор, естественно) всегда адаптирована под компиляторы ЯВУ.

ARV писал(а):

если у меня нет велосипеда, это не означает, что я не смогу

Для примитивных задач не означает, а для чуть более сложных - очень вероятно, что к финишу Вас привезут вперед ногами...

ЗЫ. Немного флуда.
Место, которое на мой взгляд занимает 16-битная платформа Микрочипа (PIC24/dsPIC33), весьма примечательно тем, что она, В СИЛУ ЛИНЕЙНОСТИ АРХИТЕКТУРЫ, с одной стороны и наличию большого количества очень "взрослых" особенностей этой архитектуры, позволяет быть учебным полигоном для генетических "железячников", которые и являются основным эшелоном АСМистов. Лично я понял как правильно писать на АСМе лишь после того, как начал заниматься этими МК.
И лишь потом я взглянул на свои прежние "нетленки" в восьмибитниках другим взглядом. И ужаснулся...

Последний раз редактировалось КРАМ Ср мар 11, 2020 09:04:21, всего редактировалось 1 раз.

[ARV]

Вы постоянно подменяете предмет обсуждения.

нет, я использую разные аналогии из предметной темы и вне её для более красочной демонстрации собственных мыслей.

Разница между языками высокого уровня никакого отношения к разнице между ассемблером и ЯВУ не имеет.

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

поэтому вполне корректно сравнивать ассемблер с ЯВУ по "постоянным и неизменным" критериям.

То есть ассемблер так или иначе должен сублимировать абстракции того ЯВУ с которым он взаимодействует.

нет. ассемблер МОЖЕТ это делать, но НЕ ОБЯЗАН. ассемблер - вполне самостоятельный язык для создания проектов без привлечения ЯВУ, примеров множество.

Поскольку написание на ассемблере связано с рядом известных сложностей, программист вынужден применять методы и абстракции ЯВУ

программист - может. но из-за этого в ЯЗЫКЕ эти абстракции не появляются.

Без этого код полученный на ассемблере будет безобразным во всех отношениях, а реализация на нем задач чуть более сложных, чем условное "мигание светодиодом", будет вызывать значительные проблемы.

это несущественно для разбора ЯЗЫКА. в неумелых руках ЛЮБОЙ код, даже на ЯВУ, будет безобразным, и будет вызывать проблемы.

Если программист понимает логику взаимодействия системы команд МК с ЯВУ, переход на другую платформу не вызовет никаких сложностей

модули ассемблера с ЯВУ взаимодействуют только одним способом - через соглашение о вызовах и передачи параметров, более никакой логики не требуется. это интерфейс между модулями, и, как правило, при этом используется именно термин "область памяти", а не "переменные". даже для реализации взаимодействия между модулями на разных ЯВУ, например, Си и Паскаля.

И оная логика ВСЕГДА СУЩЕСТВУЕТ, ибо система команд МК (начиная с некоторых пор, естественно) всегда адаптирована под компиляторы ЯВУ.

логика существует, кто ж спорит.
но вот если в Си нет понятия "ссылка", то не стоит и использовать этот термин, даже если есть большая привычка работы со ссылками в С++. аналогично и для ассемблера - не надо вносить путаницу, применяя термин "переменная", который в парадигме ассемблера отсутствует. есть отличные и правильные термины - область памяти и адрес (метка) её начала, их и следует применять.

[КРАМ]

ARV писал(а):

нет, я использую разные аналогии из...

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

ARV писал(а):

ассемблер - вполне самостоятельный язык программировния с давным-давно устоявшимися "традициями".

Так "традициями" или нормативными сущностями? Вы уж как нибудь определитесь... Если речь о "традициях", то есть смысл обсудить ментальность носителей этих "традиций", особенно тех, которые пробовали устрицы из сурими...
По мне, так обсуждение еще одного макроса, как полезной фичи, - не более чем поиск красивой ракушки на берегу моря. Пользы - никакой.

ARV писал(а):

нет. ассемблер МОЖЕТ это делать, но НЕ ОБЯЗАН.

Как обычно. Подмена предмета. Ассемблер, как этап компиляции, - обязан. Ассемблер, как самостоятельный язык, - вообще никому ничего не обязан. Программы на нем лепит программист как ему Бог на душу положит. Результат примерно такой же.

ARV писал(а):

в неумелых руках ЛЮБОЙ код, даже на ЯВУ, будет безобразным

А мы и обсуждаем те самые приемы, которые сделают эти руки умелыми. В данном случае на АСМе.
В этом смысле очень важно найти единую логику транслятора от текста на ЯВУ до загружаемого кода.
Это ровно то, чем большинство или ленится, или брезгует заниматься.

ARV писал(а):

модули ассемблера с ЯВУ взаимодействуют только одним способом - через соглашение о вызовах и передачи параметров, более никакой логики не требуется

Формально - да. Для тех, кто не желает ничего знать кроме этой формы.

[BOB51]

НУ И ПОЦАРАПС УСТРОИЛИ!

Давайте начнем с того, что есть язык машинных команд и ПРЕПРОЦЕССОР КОМПИЛЯТОРА.
Где в абревиатуре машинной команды классического ассемблера имеется такая штука как "переменная"?
код операции, оператор, операнд.
источник данных - приемник данных.
метка - синоним адреса источника/приемника данных в соответствующем адресном пространстве.
непосредственные данные (данные, адрес, смещение относительно текущего адреса).
И ВСЁ.
Остальное добавляет препроцессор компилятора.
А оный чем более поздний тем понавороченнее в сторону ЯВУ

И у каждого производителя компилятора свои дополнения/особенности для как можно большей разницы с "иным семейством" - абы посложнее пользователю оперативный переход "в стан врага" выполнить было.

Вспоминайте ка как писали и компилировали при помощи бумажна листочка и карандашика...

Последний раз редактировалось BOB51 Ср мар 11, 2020 10:05:16, всего редактировалось 1 раз.

[ARV]

По мне, так ... Пользы - никакой.

спишем это на эффект от переедания устриц

Как обычно. Подмена предмета.

обратите свой взор вверх страницы - тему видите? разве там упомянут ассемблер, как этап компиляции? как этап он вообще мало кого интересует, т.к. ассемблерный код порождается, используется и уничтожается компилятором Си (или иного ЯВУ), и пролетает мимо программиста со свистом. а вот как инструмент разработки - очень даже.

Программы на нем лепит программист как ему Бог на душу положит. Результат примерно такой же.

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

Это ровно то, чем большинство или ленится, или брезгует заниматься.

это по большей части просто никому не нужно, т.к. проблема взаимодействия ассемблерных модулей с модулями на ЯВУ беспокоит явное меньшинство всех разработчиков...

Для тех, кто не желает ничего знать кроме этой формы

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

Добавлено after 18 minutes 41 second:
я еще немного "подменю тему".

сам термин "ассемблер" произошел от слова assembling, которое, если верить гуглопереводчику, означает "монтаж, сборку, установку". то есть роль ассемблера в проекте - это роль каменщика на стройке: из небольших (и фактически "неделимых") элементов собирать нечто сложное по замыслу архитектора. и этот каменщик абсолютно не беспокоится тем, что кирпичи для более высокого уровня "строителей" (того же архитектора, прораба, логиста и т.п. участников проекта) сами по себе не интересны - на более высоких уровнях все работают со "стройматериалами", палеттами кирпичей, грузовиками, контейнерами и т.п. абстракными обозначениями. любой каменщик скажет вам, что сложил дом из 10,5 тысяч кирпичей, а про тот же дом логист скажет "понадобилось 2,5 грузовика кирпичей". а архитектор вообще ограничится фразой "я спроектировал и построил этот дом".

все это и говорит о необходимом и достаточном уровне абстракций: ассемблеру - байты и такты, линкеру - области памяти, ЯВУ - переменные и классы, программисту - модули и алгоритмы. и на каждом уровне принципиальной необходимости понимать "устройство проекта" в целом, а так же сущность терминологии на уровне выше/ниже, нет: достаточно знать и понимать/использовать только собственный уровень и "интерфейс" между уровнями. каменщик должен знать лишь тот факт, что к началу его смены кирпич будет подан, и марка его будет той, что надо, а помощники поднесут раствор нужного качества.

[КРАМ]

ARV писал(а):

проблема взаимодействия ассемблерных модулей с модулями на ЯВУ беспокоит явное меньшинство всех разработчиков...

Очень много слов. Я утомился.
Если Вы относитесь к большинству, тогда зачем пишите всякую ерунду про макросы для меньшинства?
На том я и закончу, пожалуй.
No more comments.

[BOB51]

МЛИН...
Сказал же , что "обсасывание косточек" это не тут, а у меня на КОТУИНКЕ делать надо - там обсуждения "взаимовыгодного восприятия" с попытками вытрясти из имеющегося лучшие крупинки для всеобщей пользы.

Как кстати и "слэнг" по многофайловикам на ассемблере.
Я а АВРкины проекты добавил шапку по подобию микрочипа с описанием конфигурации по умолчанию и для текущего проекта.
Правда как блок комментария - это все же не аналогия для компилятора. Однако таки штука весьма полезная!

[ARV]

Если Вы относитесь к большинству, тогда зачем пишите всякую ерунду про макросы для меньшинства?

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

[Мяукните!]

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

Но когда этот фикс выйдет, неизвестно..

Ассемблер шикарный, на мой взгляд.


p.s. попробовал сам собирать исходники - бесполезно.. у меня это никогда не получалось...

Добавлено after 2 hours 35 minutes 39 seconds:
p.s. Альфред выпустил новую сборку 1.42Bld158 (2020-03-21).

В идеале, должны поддерживаться на русском:

- имена меток (подпрограмм)
- имена макросов
- имена параметров в макросах

Вечером потестирую. И если всё работает, этот ассемблер становится близок к идеалу.

Одно непонятно, как получилось, что за столько лет, я впервые о нём слышу??

[shonty]

В идеале, должны поддерживаться на русском:

- имена меток (подпрограмм)
- имена макросов
- имена параметров в макросах

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

[BOB51]

На сегодня более актуальной является возможность/навыки/методы написания многофайловых проектов под "чистым ассемблером".