ASM: приказали долго жить?, Сколько еще продержится Опции

[OlegIvanov]

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

[white.wind]

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

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

[defunct]

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

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

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

[dxp]

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

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

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

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

Писать программы (без математики с плавающей точкой) на Avr-ASM не сложнее чем на C.

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

Порой даже проще (вчастности обработку прерываний проще и качественнее делать на asm).

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

[defunct]

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

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

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

Писать программы (без математики с плавающей точкой) на Avr-ASM не сложнее чем на C.

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

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

[dxp]

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

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

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

"Технически Вы не король" © Шрек
Высмысле, технически Blackfin не МК.

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

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

По поводу запутанности кода, это смотря как писать, можно на C написать так, что через пару месяцев в коде не разберется даже автор. А можно написать на ассемблере так, что сходу будет все понятно.

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

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

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

[defunct]

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

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

Ну хорошо с inc'ом допустим 51-й в выигрыше, и то сомнительно, т.к. никто не заставляет Вас хранить особо важный, разделяемый несколькими задачами счетчик в памяти (не на Cи ж пишем). Ему можно жестко назначить любой регистр из нижнего "бестолково-бесполезного" ряда R2-R15. Во-вторых никто не заставляет Вас строить программу так, чтобы появлялась необходимость в дополнительной синхронизации.
Как контр аргумент вашему примеру - целый класс задач, интенсивно использующих целочисленную арифметику и логические операции. Здесь 51-й явно будет в проигрыше со своим обязательным регистром Acc для всех арифметико-логических операций.

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

Это понятно, согласен. Просто этот дополнительный геморрой надо единожды учесть, и строить структуру программы таким образом, чтобы никогда не иметь геморроя.

И таких примеров можно привести кучу.

Вы возможно согласитесь, что таких примеров будет больше для 51-го. Тому способствует и Acc, и оствутствие команд сравнения, и многоуровневый КП (при необходимости могу привести больше аргументов).

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

Спорить не буду.

Скажите - Вы писали на асме для MSP430?

Серьезного ничего не писал. А разве что баловался - простейшие программки типа настройки DCO, инициализации таймера и мигания светодиодом в прерывании. Меня сразу отпугнул непривычный для меня порядок следования операндов.

"Технически Вы не король" © Шрек
Высмысле, технически Blackfin не МК.

Хе. А как называется микросхема, у которой процессорное ядро....

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

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

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

Согласен и поддерживаю это высказывание.

[dxp]

Ну хорошо с inc'ом допустим 51-й в выигрыше, и то сомнительно, т.к. никто не заставляет Вас хранить особо важный, разделяемый несколькими задачами счетчик в памяти (не на Cи ж пишем). Ему можно жестко назначить любой регистр из нижнего "бестолково-бесполезного" ряда R2-R15. Во-вторых никто не заставляет Вас строить программу так, чтобы появлялась необходимость в дополнительной синхронизации.

Во-от! Уже всякие "если" полезли. "Если" уж на то пошлО, то писать на С/С++ основной объем и не парить мозги. Я в свое время вполне успешно писал на С целиком под 2313. Кодогенерацию анализировал, не находил там такого, что бы дало хоть какой-то значимый выигрыш при писании на асме. Но возвращясь к начальной точке - я оспаривал тезис, что AVR'овский ассемблер является самым удобным и легким в использовании. Утверждаю, что это не так, что у 51-го и MSP430 (особенно у последнего) ассемблер значительно проще и приятнее в использовании.

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

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

Скажите - Вы писали на асме для MSP430?

Меня сразу отпугнул непривычный для меня порядок следования операндов.

И зря. Вон мотороллеры, насколько знаю, традиционно имели такой порядок, и ничего. Если вдуматься, то он и более логичен. Но это, повторяю, мелочь - очень быстро осваиваешься и проблем это не доставляет. Даже когда работаешь параллельно с двумя архитектурами - например, AVR и MSP430, приходится то и дело то в том копаться, то в этом - нету проблемы, по самим мнемноникам уже автоматом правильно переключаешься на порядок операндов.

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

К сожалению, я не помню Вашего мнения на эту тему. Хотелось бы услышать техническое обоснование, почему, скажем АРМ9 является МК, а Blackfin - нет.

[defunct]

Во-от! Уже всякие "если" полезли. "Если" уж на то пошлО, то писать на С/С++ основной объем и не парить мозги.

е-мае! кто ж с этим спорить-то будет.

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

Я в свое время подружил 2313 с RTL8019AS, и воткнул в нее крохотных IP стек с поддержкой ICMP/UDP ну и естессно, что-то over UDP т.к. IP стек не был самоцелью. Фичи, которые с успехом реализуются на асм и криво реализуются на C, - например копирование из одного source в два dest, что является чуть ли не ключевой операцией при обработке ARP и IP пакетов (использование всех трех указателей под собственные нужды, без организации стека данных вообще).

Но возвращясь к начальной точке - я оспаривал тезис, что AVR'овский ассемблер является самым удобным и легким в использовании. Утверждаю, что это не так, что у 51-го и MSP430 (особенно у последнего) ассемблер значительно проще и приятнее в использовании.

Выглядит Ваше утверждение также голословно, как мое утверждение, что AVR-асм самый лучший.
Предлагаю придумать кукую-то несложную задачу и реализовать ее на всех названных асмах (A51, MSP-Asm, AVR-Asm), там и посмотрим, на каком асме решение получится наиболее красивым и понятным.

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

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

Драсти, надобность постоянно копировать один операнд в Acc это уже специфика не только архитектуры, но также и дебильности асма, сопровождающего эту архитектуру.

Скажите - Вы писали на асме для MSP430?

Меня сразу отпугнул непривычный для меня порядок следования операндов.

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

Согласен, что мелочь, но мне вероятно уже не доведется плотно работать с MSP-асмом, время ушло, сейчас решаю другие задачи для которых хватает avr, а там где нехватает применяется arm. 16-битный msp как бы посередине и совсем неактуален для решения моих задачь.

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

Это понятно, у меня тоже никогда не возникало проблем при копании параллельно с 51-м и Avr. Правда на переключение уходило пару часиков. Нет-нет да и вставишь вместо ldi - mov или наоборот.

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

К сожалению, я не помню Вашего мнения на эту тему. Хотелось бы услышать техническое обоснование, почему, скажем АРМ9 является МК, а Blackfin - нет.

since eh... because! ;>
Встроенным мат. аппаратом.

...Часть аппарата в целях экономии была реализована программным путем, из-за чего СуперЭВМ превратилась в СуперТормоза и не получила практического применения.

Глубочайшее заблуждение. Более 10^8 инструкций ЯВУ в секунду при 64 битной суперскалярной (кстати, тоже первой в мире) архитектуре - это и по нынешним временам довольно круто.
Эльбрус-2 выпускался серийно и применялся, насколько мне известно, в военных и космических целях.

Серийно в двух экземплярах?

"Машины "Эльбрус 1" и "Эльбрус 2"
......
....
Как только убрали аппаратную поддержку интерпретации производительность машины резко снизилась, что привело к прекращению развития этого семейства" ©