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

[Мяукните!]

[uquote="ARV",url="/forum/viewtopic.php?p=3804826#p3804826"]рекомендую обратить свой взор на avr-as (gnu-as) с его мощной (хоть и несколько устаревшей) системой макросов[/uquote]Скорей всего, она или не была мощная. Или действительно устарела. До сих пор я писал исключительно на as из набора binutils. Но чем плотнее пишешь, тем больше натыкаешься на ограничения макросов.... И не только... Моя заветная мечта была, избавиться от binutils раз и навсегда.

Но когда я увидел AS то аж прыгал до потолка!

Изучаю документацию

[Demiurg]

Расскажу про свой опыт. В 2007 году я понял, что пора переходить на микроконтроллеры. В Новосибе была такая фирма Аргуссофт. И в офисе этой фирмы мне попался каталог комплектухи. В этом каталоге был краткий обзор основных архитектур МК. По этим кратким описаниям я понял, что мне подходят AVR. Я купил отладочную плату STK-500 и несколько книг по МК AVR. Уже не помню подробностей, но си я не рассматривал, я его тогда вообще не знал, как-то сразу остановился на ассемблере, и книги были с примерами на ассемблере. И я писал свои программы на ассемблере несколько лет. Был ярым его поклонником. Через несколько лет у меня набралось много своих наработок, я активно использовал макросы и конечные автоматы. В определенный момент я понял, что ассемблер себя исчерпал. Особенно при создании проектов с развитыми меню. Здесь наступил предел. Потому что, на таком уровне уже идет оперирование объектами. Я поступил так, продолжал делать проекты на ассемблере, параллельно стал изучать си. Было сложно, скажу честно. Несколько раз бросал, возвращался. Когда появились первые успехи, я остановил все проекты на ассемблере и углубился в си. Получилось. Позже перевел многие наработки с ассемблера на си. Когда я это сделал, снова взялся за проекты, но уже на си.
Так вот, к чему я все это написал. Ассемблер нужно знать. Знание ассемблера очень сильно меня выручало, когда были затыки на си, и мне приходилось в дизассемблере разбираться, где проблемы, косяки. Когда вы начинаете осознавать, что ассемблер исчерпал себя, переходите на ЯВУ. Не бойтесь - это главное. Останавливает страх сложностей и инерция. Когда я перешел на си, и у меня появились первые успехи, я жалел лишь об одном, что страх сложностей застил мне глаза, что я не сделал этого раньше.

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

[Gudd-Head]

[uquote="Demiurg",url="/forum/viewtopic.php?p=3816532#p3816532"]переходите на ЯВУ[/uquote]
Надеюсь, это язык высокого уровня, а не Java?

[shonty]

Что ЯВУ, что JAVA, чем выше любовь уровень, тем выше требования к ресурсам.

Немного прооффтоплю: вспоминаю время, когда winXP летал на 256 оперативы и одноядерном 1,6 проце. И большего счастья и не желалось. Сейчас уже не знаешь какое железо покупать, причём чтобы через пару лет оно не устарело. И это лишь для того, что бы решать простые задачи.

Тоже самое и с МК. А забить 8 или даже 32кб кодом на ассемблере ни разу не влом, тем более основные ресурсы (у меня) ест графика под дисплеи.

[AQ29]

[uquote="afz",url="/forum/viewtopic.php?p=3805057#p3805057"]А вот на старых системах были шикарные макроассемблеры - что на Системе-360/370, что на PDP-11. Посмотрели бы, как это делается "по-взрослому", а потом и сочиняли асм для своего АВР...[/uquote]
Что «шикарного» есть в этих макроассемблерах? Хочется писать «по-взрослому».
[uquote="ARV",url="/forum/viewtopic.php?p=3805259#p3805259"]а про макросы пишу в строгом соответствии с темой топика: максимальное использование доступных в ассемблере возможностей для упрощения решения задач. без привнесения лишних сущностей вроде ООП и переменных [/uquote]
Неясно, почему вы против переменных в ассемблере.
Использование переменных резко упрощает написание программ. Время написания программы меньше, читаемость лучше, отладка проще - почему же их не использовать?
Конечно, в ассемблере для переменных определены все необходимые операции: копирования, сравнения, сложения, сдвига и т.д.
[uquote="ARV",url="/forum/viewtopic.php?p=3805250#p3805250"]сам термин "ассемблер" произошел от слова assembling, которое, если верить гуглопереводчику, означает…
все это и говорит о необходимом и достаточном уровне абстракций: ассемблеру - байты и такты, линкеру - области памяти, ЯВУ - переменные и классы, программисту - модули и алгоритмы.[/uquote]
Думаю, «гуглопереводчик» не определяет «необходимый и достаточный уровень абстракций».
При использовании ассемблера в качестве самостоятельного языка должна быть написана вся программа в целом, а не только «байты и биты».
Я использовал понятие ассемблер в расширенном толковании - это язык, в котором есть все ассемблерные команды и, соответственно, есть вся гибкость ассемблера.
[uquote="Мяукните!",url="/forum/viewtopic.php?p=3816038#p3816038"]Встретился довольно любопытный ассемблер.
Ассемблер шикарный, на мой взгляд.
В идеале, должны поддерживаться на русском:
- имена меток (подпрограмм)
- имена макросов
- имена параметров в макросах
Вечером потестирую. И если всё работает, этот ассемблер становится близок к идеалу.[/uquote]
Вызов подпрограмм с параметрами есть в бесплатном российском ассемблере для АВР уже лет 15.
Что шикарного в этом ассемблере?

[BOB51]

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

В противном случае потребуется многокомпонентный компилятор с линкером и библиотекарем да с прописыванием командной строки с учетом всех входящих в состав проекта компонентов (каждый раз заново ручками).
Там свои заморочки.

[Starichok51]

Неясно, почему вы против переменных в ассемблере.

а что такое "переменная" в ассемблере?
а то тут многие, в том числе и я, считают, что в ассемблере нет переменных.

Использование переменных резко упрощает написание программ

каким образом? и в чем заключается эта "резкость"?

Я использовал понятие ассемблер в расширенном толковании - это язык, в котором есть все ассемблерные команды и, соответственно, есть вся гибкость ассемблера.

а что такое ассемблер в узком толковании? и сколько толкований существует у ассемблера?

[shonty]

[uquote="AQ29",url="/forum/viewtopic.php?p=3819085#p3819085"]Неясно, почему вы против переменных в ассемблере.
Использование переменных резко упрощает написание программ. Время написания программы меньше, читаемость лучше, отладка проще - почему же их не использовать?[/uquote]
Если край как нужны переменные, то нет проблем. Вполне реализуемо через макросы:

LCD_FIELD 25, 305, 230, 230
Поле определяет область дисплея для заливки или вывода изображения/символов.

А вот вам строковая:
LOAD_COLOR_FRONT yellow

Конечно нет привычного для яву предварительного декларирования. Но опять же: переменная - это абстракция и всяк её может воспринимать по разному. А восприятие, как известно, важнее реальности.

[ARV]

Неясно, почему вы против переменных в ассемблере.

потому что они, как сущность, в ассемблере отсутствуют.

Я использовал понятие ассемблер в расширенном толковании - это язык, в котором есть все ассемблерные команды и, соответственно, есть вся гибкость ассемблера.

ну понятно... рекурсивное определение через самого себя... я еще со времен аббревиатуры GNU (расшифровка рекурсивная: GNU Not Unix) был подобным определением шокирован. это ведь масло масляное...

Если край как нужны переменные, то нет проблем. Вполне реализуемо через макросы

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

[shonty]

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

[COKPOWEHEU]

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

[shonty]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=3819356#p3819356"]как именно должны записываться ваши переменные и что из себя представлять?[/uquote]
2. ".... переменная определяется как имя, с которым может быть связано значение, или даже как место (location) для хранения значения." ©
"... либо адресуемая иным способом область памяти, адрес которой можно использовать для осуществления доступа к данным. Данные, находящиеся в переменной (то есть по данному адресу памяти), называются значением этой переменной." ©

1. sts var, Rx
lds Rx, var

Кто как, но я воспринимаю это именно как переменную.
В ЯВУ же понятие "переменная" размыто.

[COKPOWEHEU]

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

[ARV]

Действия над переменными обеспечиваются средствами языка, как действия над неделимыми сущностями. Например, переменная типа "строка" может быть присвоена другой такой же переменной "в одно действие", будто там не 100500 символов, а один. И именно в такой "лёгкости" манипуляций над данными кроется смысл самого термина "переменная". В ассемблере в принципе нет подобных манипуляций над данными " ненативного" размера. Вот и весь сказ.

[shonty]

Про 100500:
Сейчас пишу, практически написал, дело за дизайном, метеостанцию, с переписываемым/сдвигаемым графиком температуры. В ОЗУ как раз массив из 90 байт. Помимо этого есть ещё многобайтовые "переменные".
Одно дело, что их не принято называть "переменными", но по сути это одно и тоже. Тут с какого ракурса взглянуть.
Насчёт манипуляций, то конечно да, не в одну команду 90 байт передвигаю а потом вывожу на дисплей. А то что в ЯВУ это делается в одну команду - то это иллюзия, за кулисами там тоже писанины хватает. И вот тут то за упрощение часто приходится расплачиваться ресурсами.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=3819444#p3819444"]В ассемблере это делается метками в .dseg
Но поскольку метка ничего не говорит о размере или типе данных,...[/uquote]
Ну про размер вы погорячились.

[ARV]

Причём тут иллюзия?! ЯВУ именно в том и заключается, что делает ассемблерную иллюзию явью! В ассемблере нет переменных, а в яву они есть, но нет ассемблера. В том и смысл!

О метках: вы знаете способ в ассемблере по метке узнать размер области памяти, которую эта метка "помечает"?

Добавлено after 2 minutes 55 seconds:
Метка в .dseg ничем для ассемблера от метки в .cseg не отличается, и даже многие equ и set запросто могут стать на место меток в командах. И как быть с их "размерами"?!

[COKPOWEHEU]

[uquote="shonty",url="/forum/viewtopic.php?p=3819470#p3819470"]А то что в ЯВУ это делается в одну команду - то это иллюзия, за кулисами там тоже писанины хватает. И вот тут то за упрощение часто приходится расплачиваться ресурсами.[/uquote]
Именно этим язык более высокого уровня отличается от языка менее высокого уровня - сложностью абстракций. И чем дальше терминология языка уходит от машинной, тем выше уровень. Скажем, функций или объектов в ассемблере тоже нет. Конечно, никто не мешает их реализовать самому программисту. Правда, язык в этом помогать не будет, для доступа к локальным переменным все равно придется прокручивать адресную магию. То есть программист на ассемблере всегда работает с конкретным процессором, конкретными регистрами и адресами. А уже на С++ пользователь может даже не знать что делает оператор сложения - вдруг он для логов предназначен.

[shonty]

[uquote="ARV",url="/forum/viewtopic.php?p=3819557#p3819557"]О метках: вы знаете способ в ассемблере по метке узнать размер области памяти, которую эта метка "помечает"?[/uquote]
Вы мне что-то левое пытаетесь приписать. Речь вообще о другом шла. Предыдущий участник высказался что:

"В ассемблере это делается метками в .dseg"

В .dseg ставятся не метки, а резервируется пространство ОЗУ с указанием размера в байтах. Конкретного размера. И этот размер будет зарезервирован в независимости от того, будет он использоваться или нет.
А за все метки в коде программы я отвечать не подписывался.

Код: Выделить всё

.equ BAR_counter	= 95	; число бар по координате X
.........
.dseg
graph:	.BYTE Bar_counter	; данные графика 

Касаемо .dseg-а - 95 байт

[ARV]

И как метка связана с размером области? Никак. Что и было вам сказано, и на что вы сказали "погорячились"

[shonty]

[uquote="ARV",url="/forum/viewtopic.php?p=3819574#p3819574"]И как метка связана с размером области? Никак. Что и было вам сказано, и на что вы сказали "погорячились"[/uquote]
Речь шла не столько о метках, сколько о .dseg, а точнее использования этой области в качестве временного хранения данных.
В .dseg как раз и задаётся и размер сохраняемых данных, и согласно этого размера определена адресация последующего резервированного пространства. С .dseg-ом можно работать и без меток, а с прямой адресацией.
"погорячились" я говорил именно про .dseg а не все .equ, label, loop... etc.