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

[ARV]

упомянутые принципы широко и повсеместно использют вирусописатели, а так же всевозможные самомодифицирующиеся программы. в МК это менее полезно. и, при всем том, что так делать МОЖНО, я продолжаю говорить, что делать так НЕ НУЖНО.

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

[afz]

во-первых, уже в начале 80-х, найти IBM/360 было нереально.

Ага, два раза. Первую ЕС-ку, конкретно - ЕС 1022, наш Политех получил около 77-го, с 256К ферритовой памяти и двумя болгарскими клонами IBM2311, диски 6.25М, не помню, как их звали у нас. Вторую, тоже 1022, в 80-м. Чуть поновее - с 512К электронной памяти ( куча м/с К565РУ1) и тремя ЕС5061, болгарский клон IBM2314, диски 29М. А первую из Ряда 2 - кажется 1036, точно не помню, я уже там не работал - в 86 или 87. И наш Политех был довольно продвинутый: на ВЦ ПО Карагандауголь - самая наша крутизна тех времен - были те же самые машинки, только числом поболее.

Во-вторых, мне совершенно непонятно, нахрена было усложнять сборку проекта

Это было разовое действие, была какая-то "железная" формула, что-то связанное с учетом заданий в ДОС ЕС aka DOS/TOS 360, подробностей совсем не помню. А цеплять туда куски фортрановской ран-тайм системы и соблюдать соглашения о связях не было ни малейшего желания.

2All: Чего еще не хватает большинству ЯВУ - это "внутренних подпрограмм", т е. возможности выполнить кусок программы, как подпрограмму, в общем контексте. Я знаю два таких языка - классический Бейсик (оператор GOSUB) и ДИАМС, в котором оператор DO может выполнить что угодно - от внешней программы до нескольких специально отмеченных строк за ним. А на асме, опять же, без вопросов. Вот, например, для AVR:

Код:

; R4 to HEX

; Вход: R4 - исходный байт
; Выход - два байта по X+
; Рабочий регистр - R18

HEX:
        add     r2,r4
        mov     r18,r4
        swap    r18
        rcall   hex1
        mov     r18,r4
HEX1:   andi    r18,0x0F
        cpi     r18,10
        brlt    hex2
        subi    r18,('0'-'A'+10)
HEX2:   subi    r18,0xD0        ; -'0'
        st      x+,r18
        ret


Здесь еще веселее. Подпрограмма HEX сначала меняет нибблы в R18, затем вызывает подпрограмму HEX1, которая преобразует младший ниббл R18 (исходно - старший ниббл исходного числа в R4) в HEX-цифру, затем восстанавливает в R18 исходный байт и просто "наезжает" выполнением на программу HEX1, которая снова преобразует младший ниббл числа в R18 (действительный младший ниббл исходного числа) и выходит теперь уже из программы HEX. Какой ЯВУ на такое способен? И какого размера у вас выйдет программуля, исполняющая ту же функцию, но написанная на ЯВУ ?

Последний раз редактировалось afz Сб сен 21, 2019 21:20:03, всего редактировалось 1 раз.

[ARV]

Какой ЯВУ на такое способен?

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

[ПростоНуб]

afz, 1036 - это уже ряд-3 или IBM/380. Она выпускалась с 1983 по 1989 год. Ряд-2 или IBM/370 начался с ЕС1035, выпускавшейся с 1977 по 1986. Вы же указали 1983-86 годы, когда ряд-1 уже почил в бозе. Я же в 1984 уже 1046 осваивал.

И вы так и не объяснили необходимость ручных операций при сборке проекта. К тому же уж с математикой на ассемблере IBM/370 проблем не было. 64-битный блок арифметики с плавающей запятой легко позволял вычислять что угодно машинными командами. Это не 8-битный AVR без аппаратной операции деления, где элементарные математические операции с 32-битными операндами уже представляют собой проблему.

[VladislavS]

afz писал(а):

И какого размера у вас выйдет программуля, исполняющая ту же функцию, но написанная на ЯВУ ?

А давай попробуем? Мне на ЯВУ не надо сохранять результат через X+, поэтому прокрутим через регистры

Код:

#include <ioavr.h>
#include <stdint.h>

uint8_t NibleToHex(uint8_t x)
{
  return x<10?x+'0':x+'A'-10;
}

uint16_t ToHex(uint8_t x)
{
  return (NibleToHex(x>>4)<<8) + NibleToHex(x&0xF);
}

int main()
{ 
  return ToHex(PINB);
}

Листинг

Спойлер

Код:

//uint8_t NibleToHex(uint8_t x)
??NibleToHex:
//{
//  return x<10?x+&#39;0&#39;:x+&#39;A&#39;-10;
        CPI     R16, 10
        BRCC    ??NibleToHex_1
        SUBI    R16, 208
        RET
??NibleToHex_1:
        SUBI    R16, 201
        RET
//}

//uint16_t ToHex(uint8_t x)
??ToHex:
//{
//  return (NibleToHex(x>>4)<<8) + NibleToHex(x&0xF);
        MOV     R17, R16
        SWAP    R17
        ANDI    R17, 0x0F
        CPI     R17, 10
        BRCC    ??ToHex_1
        SUBI    R17, 208
        RJMP    ??ToHex_2
??ToHex_1:
        SUBI    R17, 201
??ToHex_2:
        ANDI    R16, 0x0F
        CPI     R16, 10
        BRCC    ??ToHex_3
        SUBI    R16, 208
        RET
??ToHex_3:
        SUBI    R16, 201
        RET
//}

//int main()
main:
//{ 
//  return ToHex(PINB);
        IN      R18, 0x16
        MOV     R17, R18
        SWAP    R17
        ANDI    R17, 0x0F
        CPI     R17, 10
        BRCC    ??main_0
        SUBI    R17, 208
        RJMP    ??main_1
??main_0:
        SUBI    R17, 201
??main_1:
        ANDI    R18, 0x0F
        CPI     R18, 10
        BRCC    ??main_2
        SUBI    R18, 208
        RJMP    ??main_3
??main_2:
        SUBI    R18, 201
??main_3:
        MOV     R16, R18
        RET
//}

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

Добавлено after 49 minutes 29 seconds:

afz писал(а):

Какой ЯВУ на такое способен?

Вот ты на малюсеньком кусочке кода обошёл ЯВУ. И то, чистую победу я бы тут не отдал. А способен ты сделать это на реальном проекте? Ведь оптимизатор ЯВУ без устали молотит каждую строку кода. И даже разные единицы компиляции на этапе lto дооптимизирует.

Добавлено after 24 minutes 56 seconds:
А теперь берём и лёгким движерием руки переносим этот код на STM8, к примеру. Или может на STM32? Засекаем время или результат понятен?

[afz]

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

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

А тот прием, с которого я включился в дискуссию - выход из драйвера путем вызова процедуры выхода, как сопрограммы с манипуляциями стеком, я сочинил сам, модифицируя драйвер простого матричного принтера для наших клонов PDP-11. Казалось бы банальность: отправил в порт данных очередной байт, и жди следующего прерывания. Как говорит молодёжь, "Ага, щазз!.." Во-первых оно буферизованное, т.е., пока не забит буфер, только переслал байт, оно уже готово к приему следующего, а, значит, выходить и ждать прерывания - напрасная потеря времени.

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

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

1036 - это уже ряд-3 или IBM/380. Она выпускалась с 1983 по 1989 год. Ряд-2 или IBM/370 начался с ЕС1035, выпускавшейся с 1977 по 1986. Вы же указали 1983-86 годы, когда ряд-1 уже почил в бозе. Я же в 1984 уже 1046 осваивал.

Во-первых, я указал 83-85. И при этом погорячился, надо было указать 83-84. Поскольку (вспомнил точнее) в первой половине 84-го я уже переключился на Электронику-60 (PDP-11/рус.) и за ЕС-ками больше не следил. Во-вторых, мало ли что-то где-то выпускалось? Я рассказал реальное положение, которое было в нашей глубинке в 84-м.

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

Ага, больше всего в полтора раза. 11 команд против 16. Я не считаю первую команду у себя - это подсчет байтовой контрольной суммы, и у тебя - моя программа получает байт сразу в R4, а ты его еще добываешь откуда-то.

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

[VladislavS]

afz писал(а):

Ага, больше всего в полтора раза. 11 команд против 16.

Это называется манипуляция данными. При таком малом размере кода одна команда даёт дикий прирост в процентах. А если будет код хотя бы в сотню строк? Зато код из-под компилятора выполняется быстрее и это за частую куда важнее. Я то всегда могу галку с оптимизации по скорости переставить в оптимизацию по размеру, а ты?

afz писал(а):

моя программа получает байт сразу в R4, а ты его еще добываешь откуда-то.

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

afz писал(а):

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

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

ЗЫ: Поверь, нет никакого желания холиварить. Просто ты так сказал, будто там компилятор ужас-ужас сделает. Нет, всё вполне сопотавимо и никакой убийственной разницы нет. Это как раз та небольшая плата за все преимущества ЯВУ, и она вполне адекватна.

[afz]

А если будет код хотя бы в сотню строк?

Тогда компилятор не станет его разворачивать дважды, а сгенерит два нормальных вызова. Не знаю, учтет ли он, что не нужны массовые сохранения/восстановления регистров и пр.

....

Собственно, сейчас вопрос: писать или не писать на асме в общем-то и не встает. На асме сейчас имеет смысл писать только что-то в сверхмелкий камушек с полукилобайтом флеши или куда-то еще в том же духе, поскольку совет "возьми камень потолще" трудно отменить.

Я же не зря ссылаюсь не древние системы. Допустим, та же PDP-11. На ее младших моделях применялась ОС RT-11, целиком написанная на асме. Драйвера и служебные программы для нее писались тоже на асме, всякое управляющее хозяйство - то, для чего сейчас применяются МК - тоже писалось на асме. Нет, Си для нее был (на ней его и сочинили), но программы из-под него выходили слишком уж тяжеловесными, а остальные ЯВУ вообще для этого не годились.

И при написании драйверов под нее жестко экономили каждый байт - то, что ты займешь своим драйвером, отнимется у программы пользователя, ведь у младших моделей было всего 56К памяти, даже не 64 - последние 8К занимала страница ввода-вывода.

Сейчас всё это, конечно, на фиг не нужно - написал пару-тройку мелких программуль на асме, чтобы прочувствовать новый камень, и хватит, дальше есть СИ.

Хотя лично мне тот старый опыт программирования на асме для PDP-11 и DOS-360 временами весьма помогает. В частности, многие решения, подсмотренные в недрах тех старых операционок, актуальны до сих пор. Например, при сочинении многозадачности собственными средствами (без чужой RTOS)...

[VladislavS]

У меня первым был вот такой двухпроцессорный PDP-11 зверь.

[afz]

Оффтопик, конечно...

Спойлер

А я под него недавно сочинил контроллер псевдодиска на карточке микро-SD. STM32F407VET6 + логика и мелкие ПЛИС для связи с Q-bus/МПИ. Собственно, я сочинил схему и софтину в STM-ку, а СуперМакс развел два варианта плат - сначала для "больших" клонов этой LSI-11, т.е. наших ДВК, а потом и для вот этой самой машинки. Вот здесь. Там, собственно, сам контроллер, а на первой страницы той темы есть куча ссылок на смежные темы.

[Jack_A]

О, подтянулись бывшие коллеги. Мне тоже довелось с DEC-овскими клонами (СМ-4, ДВК-2,3) потрудиться. Сделали ооочень серьезную АСК для негражданских . На асме. Почему не на Фортране, к примеру ? Исполняющую систему, конечно, без асма никак, микросекунды экономили. Но компилятор можно было бы и на Фортране (Си появился, по крайней мере, у нас несколько позже, на ДВК). Не знаю.
Как смешные воспоминания с той поры (расцвет заката социализма и одновременно фирмы DEC) остался межмашинный интерфейс СМ-4 и ДВК, слепленный за день в железе и софтово, и Бейсик, которого я учил выполнять программы пользователя в реальном времени, скармливая ему машинный код.
Щас другие времена и другие песни, и потому всыпят нам по самое не могу за оффтоп. Ну мне не привыкать...

[afz]

Вообще-то те, кому интересна PDP-11 и наши ее клоны, тусуются вот здесь. И коллекционеры, и профи тех времен, и просто любители... Welcome!

[ПростоНуб]

afz, меня как-то от PDP-11 бог миловал. Нет, конечно экзамен по ее программированию на ассемблере я сдал. Но непосредствнно на ДВК-2 я провел на 2-3 порядка меньше времени, чем на IBM/370 (ЕС-1035/61/46). Ну и на 1-2 порядка меньше, чем на ZX Spectrum. Даже инженерная графика была на СМ-1800 (i8080) или СМ-1700(VAX).

[AQ29]

motorist82 писал(а):

Имеем пятибайтную константу, например

.equ NAME=0xE7E6E5E4E3

Как из неё взять старший байт для загрузки в РОН?

На хорошем ассемблере для AVR это будет:
V = Name#4
Если надо скопировать, скажем, 2 байта, то для 2-х байтной переменной V это будет:
V = Name#4N2
Переменная V может быть и RON, и SRAM, и EEPROM.

ПростоНуб писал(а):

ARV, проще, но менее универсальна. Она применима только в случае, если во всем коде есть только один длительный расчет, способный занять ресурсы CPU на длительное время. Если же необходимость в таких расчетах возникает асинхронно, то приходится реализовывать мультизадачность. А кооперативная мультизадачность, при всех ее недостатках, экономит и память, и ресурсы CPU, в сравнении с мультизадачностью по таймеру.

Сомнительно насчёт универсальности.
Во-первых, если уж требуются длительные расчёты, плохо стыкующиеся с основной программой, для них можно поставить отдельный МК, он стоит копейки.
Во-вторых, в длительной задаче можно в удобном месте сделать «окна» для программной обработки прерываний.
МК последовательно выполняет задачи – это, как писали, в 100500 раз упрощает разработку и отладку, что очень существенно.

[ARV]

На хорошем ассемблере для AVR это будет:
V = Name#4

прошу вас, не томите, дайте ссылку на хороший ассемблер!

[BOB51]

В "чистом ассемблере" ПЕРЕМЕННАЯ?

Разве что если разговор вести о работе препроцессора...
ДЫК...
там вроде есть средства полегче (avrasm2)

40001917A_AVR Assembler_User Guides.pdf

(312.32 KiB) Скачиваний: 607

стр.33....

[AQ29]

ARV писал(а):

прошу вас, не томите, дайте ссылку на хороший ассемблер!

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

BOB51 писал(а):

В "чистом ассемблере" ПЕРЕМЕННАЯ?

Разве что если разговор вести о работе препроцессора...
ДЫК...
там вроде есть средства полегче (avrasm2)

40001917A_AVR Assembler_User Guides.pdf

стр.33....

С переменными работать намного удобней, а то, что это «чистый» или «нечистый» ассемблер – неважно.
Переменные – не единственный плюс хорошего ассемблера.

[ARV]

С которым я сейчас разбираюсь - его нет в общем доступе. Пока нет.

интрига! любопытство накалено до предела
думаю, в общем доступе его и не будет никогда - кому он нужен-то будет когда-то "потом"?!

[BOB51]

То, что имеется в наличии (avrasm2) вполне достаточно для качественной работы.
Остальное - удел ЯВУ.

[ARV]

вполне достаточно для качественной работы

я остаюсь при мнении, что avrasm2 - очень убогий ассемблер, которому крайне далеко до звания "приличного". я уже писал, что gnu-as, точнее, в контексте нашей темы, avr-as на самом деле представляет собой "приличный" ассемблер. как с моего дилетантского взгляда, так практически лучший из.