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 - нет.

[vet]

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

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

[dxp]

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

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

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

Далее стал сравнивать. Для сравнения использовал не какие-то непонятные тесты, а прямо свои рабочие проекты. Надо сказать, что код там вполне обычный, контроллерный - проверка флагов, вызов функций (прямо и по адресу (индексу) из массива указателей), работа с одиночными переменными 8-, 16-, 32-бит, работа с агрегатными типами вроде структур и массивов, и, конечно, работа с объектами классов. Компиляторы в обоих случаях были от IAR. Ожидал увидеть одно, а на деле увидел другое.

Оказалось, что и на 8-битных данных AVR не блещет, а показывает даже немного худший результат. Анализ причин показал следующее (как раз то, что в голову не приходило, пока не увидел это на сравнении): у AVR неортогональный регистровый файл, очень мало аппаратных указателей. Это первая причина, которая и сводит на нет преимущества гарварда по доступу в память. Вторая причина - это отсутствие нормального указателя стека - это усугубляет предыдущий момент - отъедает одну полноценную регистровую пару (указатель стека - Y). В итоге при реальной работе в программе приходится гонять адреса через Z-указатель, получается своего рода "бутылочное горлышко". Например, зашли в функцию, надо обратиться к объекту по адресу - грузим его адрес в Z (две инструкции), обратились; теперь надо обратиться к другому объекту, а с предыдущим работа еще не закончена - в него в конце будет помещен результат; но как быть с адресом? Либо забить на него и в конце еще раз грузить, либо сохранить куда-то временно - т.е. копирование, накладные расходы в том и другом случае примерно одинаковы. И вся программа буквально изобилует такими примерами, когда надо адреса гонять через Z-pointer. Для сравнения - у MSP430 такой проблемы вообще нет - берем и адресуемся с любого из 12 РОН. Надо один объект - адресуемся с одного регистра, надо другой - с другого, а предыдущий никуда не делся, хранится до момента своего следующего использования. Если бы у AVR был бы еще хоть один указатель типа Y или Z, а еще лучше два - то это была бы совсем другая картина. И разрядность данных тут не много значит - адресная арифметика все равно в подавляющем количестве случаев 16-битная.

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Код

float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
    float X_2 = x*x;
    float Y_2 = y*y;

    return a[9]*X_2*x + a[8]*Y_2*y +
           a[7]*X_2*y + a[6]*x*Y_2 +
           a[5]*X_2   + a[4]*Y_2   +
           a[3]*x*y   + a[2]*x     + a[1]*y + a[0];
}

Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

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

В целом MSP430 за счет более прямого ядра оказывается быстрее AVR'а даже несмотря на свою неймановость. Кстати, обращение в память у AVR - 2 такта, - тоже не впечатляет, медленно это. Должен за такт лазить, принципиально этому ничего не мешает. Этот момент я тоже уже озвучивал здесь на форуме, вступал в дискуссию с некоторыми уважаемыми коллегами, просьба к ним не поднимать тут в очередной раз спор не эту тему.

Надеюсь, я ответил на Ваш вопрос удовлетворительно.

Чтобы не подумали, что лажаю AVR, скажу, что ядро ядром, но есть и другие факторы - корпус, наличие флеши и ЕЕПРОМ, диапазон напряжений питания, цена и многое другое - по совокупности характеристик AVR выплядит очень даже неплохо! И хотя по многим (большинству) параметров он уступает тому же MSP430, есть несколько позиций, где MSP430 не предлагает адекватную замену. Прежде всего это диапазон питаний - MSP430 имеют диапазон 1.8-3.6 В, если надо 5-вольтовость, то AVR рулит. Второе - наличие поддержки аппаратной внешней шины в некоторых чипах (мега8515, мега128), у MSP430 этого нет вообще. Третье - наличие байтовоадресуемой, стираемой и записываемой энергонезависимой памяти - EEPROM. В MSP430 такого нет, там только флешь, стереть можно только блоком. Правда, при такой организации есть свои преимущества - блоков много и можно произвольно их стирать/записывать прямо на рантайме. Ну, и у AVR есть чипы с большим объемом флеши (ТИ, правда, тоже обещал в MSP430 нового поколения расширения адресного пространства и многих других фич, но это пока обещания). Вот если какие-то из этих моментов актуальны, то AVR вполне рулит. В общем, нету ничего белого или черного - все серое.