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

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

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

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

Сообщение отредактировал Сергей Борщ - Jun 21 2006, 16:28

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 команды

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

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

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

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