На досуге интересует мнение всех кто занимается программированием МК - коль долго еще возможно будет использовать ASM в разработках. Понимаю что тапочки и нужно спешить осваивать C (аппаратные возможности растут и проще написать A*B, например...). Но как сейчас какие плюсы - пишешь то что надо, не зависишь от уровня тупости разработчиков C компилятора, т.е. все на виду (предпочитаю надежность быстроте разработки). Но бесит реализация арифметики на ASMе. Ваше мнение, господа?

ИМХО Асм в разработках будет использоваться всегда, потому как есть круг задач, для которых использование Си малоопроавдано, а порой и невозможно. В то же время большинство задач, наоборот, лучше создавать изначально на Си. Универсальность, легкость понимания, внедрение новых модулей, скорость разработки etc... Можно долго перечислять достоинства языка Си (и не только Си) перед Ассемблером

1. Какой тип МК имеется в виду?
2. Будут ли Ваши проекты развиваться в будущем? Если да, то не исключен переход на другие архитектуы, тогда нужно писать на СИ.

А вообще в инете много "религиозных" тем "АСМ vs. СИ"
Рекомендую почитать:
1. Это.
2. Это.

Даже программируя на асме не всегда можно получить что хотел - вмешивается компилятор. Иногда неудачно.
Согласен с предыдущими высказываниями - асм будет жить для определенных задач. Будут расти в мк объемы памяти, производительность повышаться, но найдутся задачи где нужен асм (например на с тяжело обеспечить точные интервалы, сопостовимые с временем выполнения команд. например 50-30 тактов для АВР)

Сильно на C разгонишься когда памяти 512 байт.

2 arttab:
Первый раз слышу, чтобы компилятор мешал при компиляции ассемблерного кода. Может примерчик.

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

К тому же, когда есть ограничения по объему ни один компилятор си не будет оптимальнее кода написаного человеком.

Почти не слабее, чем на асме. На AT90S8515 все программы писались на С. В течение нескольких лет (с 1998 до 200х) пока не появились недорогие меги. Сам С никаких особых требований к памяти не предъявляет. Разве что стек для данных. Но это не мешает и даже наоборот способствует экономии памяти - память шарится под локальные объекты. Обычно стека в 50-80 байт хватало за глаза. В остальном память тратится ровно столько же, сколько и в асмовой программе - сколько глобальных/статических объектов там разместил, столько и съелось.

Попутно в те же времена и на AT90S2313 со 128 байтами ОЗУ вполне успешно писались программы на С без какого-либо напряга по памяти данных - там больше размер флеши напрягал, 2 килобайта маловато. А уж 512 байт ОЗУ - это даже роскошно было.

Глюки компилятора неисключены. и ошибки юзера, которые он не выдал.
Попробую чеговспомнить:
использовал мнемонику вида (1 << х) и для части команд она интарпитировалась неправильно. Помоему с портом работал и получалось что я хочу выставить бит 2^х в порте в 1. До х =3 не ругался и делал не то что я хотел. и с вводом цифр раз накасячил, а он ошибок не выдал и присвоил 0 значения.
Оптимизация в студии есть - вместо загрузки в рон 0, поменял на обнуление регистра рон

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

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

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





Согласен. И будет существовать от экономии. взять стромный по памяти мк (дешевый) и сваять на нем на асме, то что на с не влезет.
Знаю людей, которые мегу 128 асемблерным кодом забили и им этой меги столо не хватать

Ассемблер будет жить ВСЕГДА. А что касается арифметики, то все арифметические операции можно оформить в виде подпрограмм, это делается только один раз. Дальше ими только пользуешься.
Есть свои ++ при программировании как на ассемблере, так и на Си. Хотя я Использую Си больше 20 лет, но ассемблер не забываю. Ассемблер - это для души.
Если говорить о Си, то современные компиляторы генерируют код не намного хуже, чем это сделал бы программист. Мне, например, удается соптимизировать код, сгенерированный компилятором, от силы % на 10. Естественно, что прогаммист должен "прочувствовать" используемый им компилятор и помогать ему генерировать эффективный код.

ИМХО если бы писали на С, еще и место бы осталось.

Хм, надо же.
Опять подняли религиозную тему!
Накняпали уже 11 постов и не переругались
Растём!
Теперь по теме.
Знать асм и писать на асме это далеко не одно и то же.
Здесь я где-то согласен с beer_warrior, что отлаживать тонкости, особенно связанные с железом, зная асм легче.
Другое дело - писать. Стараюсь в своих проектах избегать этого где только возможно.

Пожалуйста. сделайте RJMP на +0x400 слов (переход из таблицы векторов Boot-области в Application). Согласно описанию AVR Instruction Set в качестве аргумента RJMP берет смещение в словах. Однако "втюхать" это смещение ассемблеру от IAR "в лоб" невозможно. Асм от WinAVR такое тоже есть отказался.

Попробовал asm, ничего, не страшный совсем

Счас играю с видеовыводом на МК. Среди реализаций есть полностью на Си, однако помогает знать что генерит компилятор.

В Вашем случае предполагается "сворачивание" адреса через 0.
В EWAWR_AssemblerReference сказано:

и ещё:

Это следствие. Я прошу сделать RJMP вперед на 0x400 слов.
Syntax: Operands:
RJMP k -2K <k <2K
16-bit Opcode:
1100 kkkk kkkk kkkk
так вот я хочу получить после ассемблирования 16-битный opcode 1100 0100 0000 0000
Я не прошу (для меги-8) компилятор догадаться что для перехода с адреса 0x1802 в адрес 0x0002 нужно использовать wrap, я об этом уже догадался за него. Я хочу получить вполне легитимный опкод 0xC400. Исходно вопрос стоял: Вот я и привожу пример: согласно описанию системы команд RJMP k, k может быть +-2К, а ассемблер не дает мне подставить это самое k. Решение есть, но через одно место.

Это понятно, разработчики компиляторов тоже люди, и тоже допускают ошибки. Но как это связано с самим ассемблером?
Я уже молчу тогда что вытворяют иногда компиляторы си, особенно с высоким уровнем оптимизации кода.

Да это не ошибка. Если на нужном адресе поставить метку и сделать RJMP на метку все будет отассемблировано как надо. С ассемблером это связано напрямую (именно с тем "компилятором" с языка ассемблера, каламбур :-)) ). Вот если бы мы писали сразу в кодах, тогда да - никаких ограничений, кроме времени жизни и психического здоровья разработчика.

начинал на С, (cv) потом для тини12 пришлось поизучать асм, потом вернулся к си, уже с ассемблерными вставками- на 8мгц на си с тв сигналом работать было трудновато.

Апсолютно верно...

с уважением
(круглый)

Все там нормально рулит +/-2k нужно понимать +/-2047 (байт) = +/-1023 (слов)

1) Relative jump to an address within PC - 2K +1 and PC + 2K (words) Таки +- 2К слов.
2) речь не о превышении разрядной сетки, а о невозможности указания значения операнда "в лоб"
Решение есть, но оно "через задницу":
И все эти извращения компилируются в одинаковые опкоды C400

Он не просто не страшный совсем, я бы сказал AVR-ASM самый удачный и простой в использовании среди всех других ассемблеров MK. Писать программы (без математики с плавающей точкой) на Avr-ASM не сложнее чем на C. Порой даже проще (вчастности обработку прерываний проще и качественнее делать на asm).

Простите, может я не понял вопроса, а что вариант
RJMP PC+$400
не катит?

Вообще такие вещи, я так не делаю. Предлагаю вариант.

ComExe:
ldi Zl, low(TabCom) ; Загрузить адрес
ldi Zh, high(TabCom) ; таблицы комманд в Z
add Zl, wl ; прибавить смещение
adc Zh, Yh ; скорректировать (Yh=0)
ijmp ; и перейти на выполнение комманды
.....

; Набор основных комманд

rjmp a0 ; a(0)
rjmp Ok2 ; b(0-1) (для совместимости)
rjmp Ok2 ; с(0-1) (для совместимости)
rjmp d0 ; d
rjmp e0 ; e(0-1)
.....

; *** Установить соединение (A0) ***
a0: cpi wh, 1
brsh errC
rjmp ata ; перейти на установление соединения

; *** Набор номера ***
d0: rcall swup ; Поднять трубку
ld wl, Y
andi wl, $df
.....

Очень спорный тезис. Меня так после асма 51-го AVR'овский просто ломал. Немного лучше стало, когда слепил кучу макросов, чтобы уменьшить объем писанины. Когда перешел на С (а это оказалось оченно правильным, т.к. С код на AVR ложится очень неплохо), то началась просто другая жизнь. Хотя асм AVR'овский не забывал - частенько инспектировал кодогенерацию по листингам. На сегодня могу сказать, что и асм MSP430 куда как удобнее и приятнее, чем AVR'овский.


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


Качественнее в смысле быстродействия и размера кода - да. Проще - нет.

Ответ - всегда, однозначно. При этом знать Ц и Ц++ тоже. Можно програмить на ЯВУ в основном, но асм знать - обязательно, особенно на МК.

Это товарищ вредничает.

Одной мнемоникой все переходы и вызовы (это относиться и к условным переходам):
rjmp Lable
rjmp 0x400
rjmp pc+0x400
rjmp pc-0x400

.equ JmpShift=Lable1-Lable2
rjmp pc+JmpShift
rjmp pc-JmpShift

Только относительные скачки на конкретно заданное число шагов (+0х400) применять очень не удобно, поскольку при вводе одной команды по средине надо все поправлять ручками, вычисляя на калькуляторе.



Правильный вариант, особенно если в программе есть некая переменная, которая соответствует текущему состоянию системы и используется как смещение в таблице rjmp'ов. Экономит код и время.


Ругает народ AVR assembler. А в версии 2 очень не плохие макросы можно делать, передавая в них имена регистров и регистровых пар.
Хочешь - систему команд перепиши, хочешь - собери библиотеку и одним движением настрой ее на свои регистры, память и процессор:
--------------------------------------------------
.macro LDI2
ldi @0,low(@2)
ldi @1,high(@2)
.endm

----------------------------------------------------
.macro CPI2_2
cpi @1,high(@2)
brne _quit
cpi @0,low(@2)
_quit:
.endm

---------------------------------------------------------
.macro ADD2_1
add @0,@2
brcc _ADD2
subi @1,-1
_ADD2:
.endm

И пишется быстрее, и читается нормально.

ldi2 zl,zh, JmpTable
add2_1 zl,zh,rStatus
cpi2_2 zl,zh, JmpTableEnd
brsh Error
ijmp

ASM никогда не прикажет долго жить, хотя бы по тому, что для создания компилятора С он тоже нужен.

Не обязательно, пару лет назад мы с ребятами баловались над созданием расширения C#. По началу все (парсер, генерация) писалось на самом C#, а потом расширение парсило и генерировало само себя Вроде даже есть название такому подходу.

2 OlegIvanov. Слухи о смерти асма сильно преувеличены. Почти 30 лет на нём пишу. Начинал с КР580 (до чего приятный ассемблер), потом Зилог, 286, пик (гадость редкая) MSP (напомнило 8080),
сейчас АВР. Если не страдаешь склерозом, можно спокойно на нём писать. И на коментарии не скупиться. Всё сказанное, ясное дело, ИМХО.

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

Проверил. Действительно сработало (для IAR получилось RJMP $+800). Запомню. А я как только ни пробовал...

P.S. Для тех кто писал позже: Я знаю что в общем случае использовать вычисленную самостоятельно константу смещения - это грязный хак, и что транслятор с языка ассемблера предоставляет для решения этой проблемы очень удобное средство - метки, но в том конкретном случае расстояние между одноименными векторами в boot и application областях фиксировано и одинаковое, а программа писалась с расчетом чтобы можно безболезненно поделить ее на две - для application и для boot области. И чтобы при этом будучи залиты в один кристалл они дружили между собой пользуя куски кода друг друга. Ну в общем "так было надо!"

1) Такой вариант написания часто используется при написании макросов. Ну например:
.MACRO LongBREQ
brne PC+2
rjmp @1
.ENDMACRO
Иногда для этих же целей используются локальные метки.

2) Применение значка $ для обозначения PC является "более стандартным". Практически во всех ASM я использовал такой вариант. Например нижеследующий вариант считается стандартной командой стоп.
jmp $

3) Я действительно избегаю всех чисел. Если необходим косвенный переход, то использую разность меток. Типа
step1:
....
rjmp $+(step2-step1)
....
step2:

Ещё чаще использую другой приём.
Очень часто в голове крутятся несколько задач. Назовём их к примеру step1,2,3,... Я пишу их таким образом чтобы был один вход и один выход. Поэтому они получаются перемещаемыми. Делаю я это так...

// Шаг 1
step1:
...
// тело
...
step1_end:

// Шаг 2
step2:
...
// тело
...
step2_end:

.....

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


Теперь по теме. Мне кажется предсказывать, - дело не благодарное. Конечно производительность и ресурсы камней растут. С др. стороны написание на Си строки типа:
PORTE &= ~(1<<DIR_RS485)
Которое так "грамотно" компилится на IAR AVR, может оказаться не таким грамотным для другого МП. Всвязи с этим хочется сказать, что программирование на С не так уж и независимо, как этого бы хотелось. А знание ассемблера частенько помогает понять действия компилятора, и соответственно подход к написанию прог на языке высокого уровня. С др. стороны, возможно иногда бывает сложно абстрагироваться, избавится от лишних знаний и подойти к написанию "чистым".
Как всегда - дуальность. А выбирать только Вам!

Я тоже мигрировал с 51-го на AVR, первую неделю плевался, а потом разобравшить понял насколько порядков AVR-Asm лучше. Слепил макросы в стиле x86 и стало вообще все просто.
чем меньше команд имеется в арсенале программиста, тем сложнее писать программу на ассемблере. У MSP всего 27 мнемоник, если не ошибаюсь, и операнды перевернуты (аргументы идут первыми параметром, рез-тат записывает во второй). Следовательно для программиста MSP-Asm просто не может быть куда удобнее и приятнее AVR-овского у которого 130+ мнемоник.



"Технически Вы не король" © Шрек
Высмысле, технически Blackfin не МК.
По поводу сложнее и дольше - возможно.
По поводу запутанности кода, это смотря как писать, можно на C написать так, что через пару месяцев в коде не разберется даже автор. А можно написать на ассемблере так, что сходу будет все понятно.

Всегда писал для AVR-ок на АСМе и не собираюсь переходить на Си. Типичный размер программы - неск.тыс.строк. Поскольку всегда приходится что-то экономить (иногда флешь, а чаще всего ОЗУ), то доверить это компилятору не хочу. Да и в голове держать особенностей реализации нужно меньше, если используется АСМ - меньше сюрпиризов при компиляции.

Большой минус АСМа - плохая переносимость на другие МК. Но зачем переходить, если область применимости каждой программы ограничена одним проектом и соответствующим железом ? Пока не сталкивался с задачами, которые формулировались бы так: "написать программу, которую потом можно будет откомпилировать под любой МК". Обычно сначала выбирают железо+алгоритм, потом определяют оптимальный МК, и только после этого пишут программу.

CD_Eater
Поправьте, если я ошибаюсь, но, на мой взгляд, требования к ОЗУ одинаковы что у ассемблерной программы, что у сишной, и определяются исключительно потребностями алгоритма.
Память программ - да, расходуется экономнее, но совсем ненамного, да и критично это только на мелких контроллерах. К тому же, по отзывам, на больших проектах тот же IAR начинает создавать более плотный код, чем человек на ассемблере. Здесь это обсуждалось в одной из тем.
Что до переносимости - лично я занимаюсь переносом программ постоянно по мере появления новых МК и наращивания возможностей разрабатываемых устройств. Свежий пример - возникла необходимость добавить функций в устройство; заменили в приборе мегу128 на SAM7S, т.к. перестало хватать ОЗУ под алгоритм. Весь перенос софта в результате был сведён к освоению новой периферии. Сколько бы я переносил его, будь он написан на ассемблере - страшно и представить

bootstrap.
Или вытягивания себя за шнурки.

Вот и попробуйте сделать компилятор хотя бы для AVR. Лексический анализ, парсер, оптимизация на машинно-независимом уровне, все это можно без всякого ассемблера сделать. А вот дальше, кодогенератор (back-end часть) невозможно сделать без знания архитектуры целевого процессора. А архитектура процессора - это тот же самый ассемблер. Только не для программирования, а для описания. Да и отлаживать кодогенератор проще, если видеть какой он ассемблерный код генерирует.

Дело не в количестве мнемоник, а в удобстве системы команд. На 51-м если мне надо проинкрементировать счетчик - inc var, и все, а на AVR - три команды. И при этом вся операция получается неатомарной - если этот счетчик является разделяемым ресурсом, то придется дополнительний защитный код городить. И об этом надо всегда помнить. Макрос, конечно, писанину уменьшит, но зато способствует сокрытию проблемы неатомарности операции. В общем, по любому появляется дополнительний геморрой.

И таких примеров можно привести кучу. Что касается MSP430, то разложите его 27 инструкций на способы адресации - там еще больше варинатов выйдет. У MSP430 система команд куда ортогональнее, чем на AVR, и именно это обстоятельство делает работу с его асмом значительно проще и приятнее. Порядок операндов - вообще мелочь и дело привычки. Скажите - Вы писали на асме для MSP430?


Хе. А как называется микросхема, у которой процессорное ядро, несколько таймеров с возможностями Compare/Capture/PWM, UART[s], SPI, многофункциональные последовательные порты (в т.ч. способные работать и как SPI), ноги на ввод/вывод, есть варианты с CAN и другими периферийными устройствами? Сейчас уже анонсированы чипы с набортной флешью. Есть режимы с пониженным энергопотреблением, в т.ч. и 200 МГц при 50 мВт потребления по ядру - по удельному потреблению мелкий МК, который бы мог тут поспорить, еще поискать.

Если АРМы считаются МК, в том числе и АРМ9, то уж Blackfin тут ничем не хуже. Это однокристальная микроЭВМ ака микроконтроллер. Конечно, весовая категория у него не та же, что у AVR, MSP430, PIC и другая мелкая братия, но тем не менее.


Можно. Все можно. Но на С, в отличие от асма, можно написать практически самодокументирующися код. А на асме для хорошей понимаемости придется комментария наворотить больше самого исходного кода. Разница, как грицца, половая.

Т.ч. каждому свое - основной объем на ЯВУ, критичные по скорости/размеру куски, а также сильно платформеннозависимые - асму.

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

Так а в AVR не сложнее.

Операция самая что ни на есть атомарная, и требуется всего лишь одна команда.

чтение из ОЗУ
инкремент
запись в ОЗУ

3 команды

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

Знаете ли быват очень приятно, общие константы и структуры расшарить между софтом МК и РС.
Одно изменение попадает сразу в оба проекта

Зачем, если можно хранить счетчик в регистре?

Случаи они разные бывают. Регистров может и не хватить.

Само собой. Но это бывает сравнительно редко. Как правило, регистров вполне хватает.

Я знаю одно исключение из этого правила.
Это Форт-процессоры. Т. е. такие МК, для которых ЯВУ Форт является собственно ассемблером.
Такой вот каламбур. И кстати сразу заметил, что этот пример не только исключение из правил, но и в то же время (как это ни парадоксально) - подтверждение.
Второй (грядущий вскоре) вариант, это Java-процессоры, зачатки которого есть по-моему в AVR32.
Так что всё сводится к тому, что и ассемблеры и ЯВУ существовали, существуют и ещё долго существовать будут в том или ином весовом соотношении в каждом отдельном проекте на самых разных платформах и на AVR в частности.

IgorKossak,
ну, Java-процессор выполняет всё-таки не исходник, а скомпилированный байт-код. В этом смысле он не отличается от обычных процессоров.

Безоговорочно согласен

Был ещё в начале 80-х у нас такой суперкомпуктер "Эльбрус", для него "ассемблером" являлся ЯВУ "ЭЛЬ". Насколько мне известно, это было первой в мире успешной попыткой реализовать ЯВУ аппаратно. Правда, приставку "микро" к процессору "Эльбруса" не приклеишь...