Возможно, что я не прав, но меня пугает "вредная привычка" всех компиляторов - фривольное обращение со стеком. Типичный размер стека в моих программах = 6 байт (один уровень подпрограмм внутри фоновой задачи + один уровень подпрограмм внутри обработчика прерывания + один вызов обработчика прерывания). Как ни парадоксально, это вписывается в стандарты "хардварного" стека в старых МК (где не было ОЗУ). Да и за счёт человеческой оптимизации кода всю возню с передачей параметров внутрь функции можно сделать не столь прожорливой к ОЗУ.


Как Вам так повезло, однако... Я, помнится, когда переводил программу с Тини15 на Тини13, ой как намучился - из-за того, что в Тини13 один таймер вместо двух и частота ШИМа меньше, пришлось перелопачивать большую часть логики работы программы. И это - различие периферии между очень похожими друг на друга МК.


Хы-хы. А для чего существуют готовые библиотеки подпрограмм, заточенные под разные МК ? В случае, если Вы написали собственный архиватор, Ваша позиция понятна. Но вот касательно Фурье (а также криптографии и т.п.) переносить Си-шную программу - неумный шаг. Для ресурсоёмких вычислений важна оптимизация, которая индивидуальна для каждого проца. То есть, по-хорошему, вычислительные процедурки надо бы переписать на асме (или воспользоваться готовыми, написанными другими авторами для нужного Вам МК). Видимо, вопрос скорости вычислений Вас прежде не волновал...


А что мешает, собственно ? Простенькая утилита, которая переводит определения констант из Си-шного формата записи в АСМ или наоборот, пишется за две минуты. А структуру можно понимать как список констант, равных смещениям переменных относительно начала структуры.

Собственно, удивительного в этом нет; следую правилу максимально отделять логику программы от особенностей работы с периферией, ресурсы используемых м/к это позволяют (используем сравнительно навороченные кристаллы, мега8 и выше). При смене чипа, таким образом, переписываются только модули инициализации и обслуживания периферии, т.е. практически вся программа перекомпилируется с косметическими изменениями.
Так оно в этом случае и получилось. Освоить периферию SAM - это был, конечно, тот ещё цирк, но, кроме этого, в исходниках почти ничего не изменилось, разве что оптимизации, касающиеся разрядности - при том, что прошивка занимала больше пол-меги128, в ней пару кбайт занимают таблицы, строки и т.п. В конечном счёте осталось ещё время повозиться с ассемблерной оптимизацией алгоритмов кодирования, без необходимости, просто ради удовольствия.
В таких вот условиях в преимуществах программирования на Си сомневаться не приходится ни секунды

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


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

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

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


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



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


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

BTW, что меня убивало в 51 это односторонний переход по сравнению
(CJMP ???), из-за чего конструкции типа switch/case приобретали весьма интересный вид
Асм MSP действительно очень хорош благодаря ортогональности.

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

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


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


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


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

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

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


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


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


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



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

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


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



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

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

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

Вот делать будто нечего, тесты придумывать... У MSP430 12 16-битных регистров, каждый из которых может быть источником операции, назначением операции, хранить адреса объектов и функций, адресовать их - все совершенно прозрачно и ортогонально. У AVR по факту полноценных регистров 16 8-битных, т.е. всего 8 регистровых пар - в полтора раза меньше. Указателей из них полноценных только два... Да не спорьте Вы, проходили уже. Я с AVR работал лет пять плотно, тащился даже. Но когда познакомился с MSP430, так сразу увидел всю кривизну - недоделанная архитектура AVR, хотя идеи заложены хорошие. Атмел на AVR учился делать процессоры. Вопросы кривизны AVR я уже озвучивал на форуме, повторять не хочу.


Не аргумент. Каким таким аппаратом? Наличием аппаратного умножителя-аккумулятора? В АРМах он тоже есть. Наличием barrel shifter? В АРМах он тоже есть. Что еще?

Я довольно продолжительное время уделил осмыслению этих моментов - DSP/не DSP, МК/не МК и т.д. и пришел к определенному выводу относительно этой классификации, который мне кажется весьма здравым и правильным. Я его озвучу, если хотите.

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

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

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

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

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



Результат:
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 вполне рулит. В общем, нету ничего белого или черного - все серое.

dxp, спасибо за подробный ответ.

dxp, насколько я знаю применение аппаратного умножителя AVR в операциях с float IAR реализовал только в версии 4.20а.
Если Ваш тест с полиномом делался в предыдущей версии, то он слегка некорректен.

Я честно написал, что при выключенном умножителе в MSP430 будет проигрыш в полтора раза, т.е. порядка 7.5 тыс. тактов. Что все равно гораздо быстрее AVR'а. И также упомянул, что пример этот полную картину не характеризует, т.к. плавучка - это только полавучка, она больше в реализацию библиотеки упирается. Но поверьте, во всем остальном картина именно такая, как я описал - ядро MSP430 действительно лучше и дает этому МК преимущество как по скорости, так и по размеру кода. И все это при меньшем потреблении.

dxp, тест очень неудачный
Сравнение вычислительных операций всегда будет в пользу проца с большей разрядностью регистров.
Простой пример - умножение чисел двойной разрядности потребует в 4 раза больше времени (используя карацубу - в три раза, но выигрыш от этого получается только при очень большой разрядности). Даже больше, чем в 4 раза (надо ещё прибавить сложения промежуточных результатов)Поэтому 16-битный аналог АВР опережал бы в 4 с лишним раза, а МСП - только в 2. Хы-хы.

Возьми задачку, где разрядность выше 8 бит почти не требуется, и сравни такты. (Типичные задачки МК уровня АВР именно таковы).

"Бы да бы, да бы мешает" (с) пословица. "Если б бабушка была дедушкой..." (с) Если бы у AVR было 8 регистровых пар - аппаратных указателей типа Z, если бы на уровне этих регистровых пар поддерживалась арифметика, если бы AVR имел нормальный указатель стека, если бы AVR имел доступ в память в один такт, если бы он вообще был 16-разрядным, а еще лучше - 32-разрядным... и еще много-много всяких если. Однако текущий факт, что MSP430 быстрее (в тактах), код у него меньше, ассемблер приятнее. Это первое.

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

И кстати, 32-разрядный Blackfin что-то не опережает MSP430 в 4 (!) раза. А уж у него-то все в наличие - и шины, и регистры, и все остальное.


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

dxp
Поддерживаю Вас. В MSP430 ядро несравнено лучше. Хоть сам я до реальных задач на MSP не добрался, однако в АЛУ влюбился сразу, грамотно все сделано, даже АРМ мне меньше понравился. (PDP11 rules )
Вот только ядро, как верно было подмечено - это еще не все, батарейные они mspшки эти, такими видно и останутся. Особенно удручило отсутсвие толерантности к 5V. Ну и еще неудобного есть по мелочи. И дорогие они, в основном.

dxp
Я не говорю, что AVR существенно мощнее )))))))
Однако был приведён всего единственный тест, результат которого мог быть предсказан заранее и не мог отражать реального соотношения производительностей на характерных задачах МК.
Моя критика направлена не на утверждение о соотношении производительностей этих МК, а на метод доказательства этого утверждения.

Несчёт "узкого горлышка", которое Вы обнаружили в малом количестве указателей у AVR и в неполноценном указателе стека. Это действительно нехорошо с точки зрения общепринятого способа компиляции с ЯВУ, но при программировании на АСМе это не вызывает каких-либо затруднений. У меня сложилась практика использовать в качестве указателей только X и Y, а регистр Z - для "временных" целей (то есть, не ассоциировать его с каким-то значением, постоянным по ходу выполнения всей программы). Если обрабатываем два массива - X и Y. Если работаем со структурой - Y+displacement. Если нужно прочитать из флеша (или временно нужен дополнительный указатель) - используем Z. В частности, я никогда не использовал Z для обращений вида Z+displacement, и в этом вижу даже некоторую избыточность. Трёх указателей всегда хватало.

По поводу стека - при правильном распределении регистров использование стека минимально. Пихать в него параметры функций и создавать там локальные переменные - дурная привычка компиляторов с ЯВУ.
Кстати, раньше, как Вы, наверное, помните, в x86 был тот же подход - кроме указателя стека (SP, относительно которого нельзя адресоваться к данным в стеке) для стековых операций резервировался ещё один регистр (BP, полноценный), полную аналогию чему наблюдаем в компиляторах под AVR. Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ? )
Стек хорош для алгоритмов, когда размер данных, помещаемых в стек, предсказать сложно. Например, рекурсий. Для МК это непозволительная роскошь (по крайней мере, пока размер стека исчисляется сотнями байт). И подход к использованию стека в МК должен отличаться от принятого в софте настольных компьютеров.

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

К чему это я ? Просто все "узкие горлышки" куда-то исчезают, как только забываешь про Си и начинаешь писать на ассемблере - под это дело AVR заточен вполне пристойно, и в плане компактности кода, и в плане быстроты выполнения инструкций, и в плане удобства программирования (не идеал, но близко).

Знание асма для программиста ЯВУ никто не отменял. Язык Си - это инструмент, которы позволяет лишь ускорить разработку программы, сделать ее более наглядной, обеспечить переносимость на другие платформы.
И не могли бы Вы пояснить, почему насаживание ЯВУ (напр., Си) на МК по своей природе противоестественно? В принципе МК - компьютер (ИМХО) и стандарт на язык Си не огаваривает аппаратную платформу.


Голословное утверждение (ИМХО).


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

Видимо задачи большего не требовали или желание всегда ограничивалось на корню.

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

ИМХО. Подобные мысли можно обосновать только плохой реализацией в проце работы со стеком.

Аналогия с x86 не впользу AVR, x86 разрабатывали 40 лет назад а AVR 10 и далеко не ушли...

Есть и такое, например у всей линейки МК от Fujitsu, начиная с 8-ми битников.

Чаще необходима реентерабильность, которая без полноценногог стека нереализуема. Эта самая вещь позволяет экономить память и не ломать голову по ручному распределению памяти - экономия времени/нервов и крохотных ресурсов RAM МК.

ИМХО: Тащиться от асма в в век когда межпланетные корабли бороздят просторы вселенной как то не серьезно...

Отчасти согласен, но в альтернативе кроме Си использую Forth ( при всей его непопулярности
Что гораздо ближе к внутренностям контроллеров.
Есть мнение, что Си это высокоуровневый ассемблер заметно
удалившийся от прародителя.

P.S. MSP не было бы без PDP11. Жаль что урезали от способов адресации больше чем нужно.
На асме есть любители писать ОС для PC.
Если бы не переносимость, то это было бы оправдано.
А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

Все изобретено до нас. IL из .NET вполне годится под определение универсального ассемблера. Универсальность просто как проавило достигается за счет уменьшения эффективности кода, то есть его заточенности под конкретную архитектуру. Так что ЯВУ как раз и выступают в роли таких универсальных ассемблеров.
Ну а собственно ассемблер мной лично используется уже довольно редко, только в тех участках кода где надо по максимуму использовать особенности аппаратной платформы, или там где без него просто не обойтись, как например совсем недавно в загрузчике для AVR.

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

P.S. Встречный вопрос.
Подходит ли Форт под понятие универсального ассемблера из сравнения с IL:)
( промежуточного языка )

Вспомнилось, в загрузщике по UART от Fujitsu кода на 800 байт написанном на асме изпользуется аж 6 (шесть) указателей. Хотя код как сами понимаете простейший.

Честно говоря о форте знаю только то что он есть. И знаю что он уже довольно долгое время после своего появления остается экзотическим языком, так что за его универсальность я бы не поручился. Однако, повторюсь, с языком не знаком.

Да, пятью указателями там явно не обойтись

Сомневаюсь, что оптимизацию кода, выполняемую вручную, можно описать простым алгоритмом. К тому же это зависит от опыта программиста. Лично мне доставляет неописуемое удовольствие процесс "утаптывания" программы, с целью получить сэкономленные байты и такты. Когда кажется, что всё уже минимизировано дальше некуда, приходит очередная хитрая идея, как изменить подход или алгоритм. Не понимаю тех, кто придерживается коммерческого подхода - побольше килобайт кода на скорую руку. Программирование превращается из искусства в ремесло.
Сорри, отвлёкся. Если бы "правильное" распределение регистров (а также много чего ещё "правильного") можно было бы описать алгоритмически, это бы давно уже вставили в компиляторы. Но компиляторы используют обобщённые методы оптимизации, дающие средний результат на типичных задачах. А когда к каждой задаче подходишь индивидуально, с одной стороны есть семантика исходной задачи, с другой - особенности аппаратуры, и твоя задача - прокинуть наиболее элегантный мостик между этими берегами. Мне именно это и нравится в программировании - заставляет шевелить извилинами.
Сорри, опять отвлёкся. Короче, обобщённого "правильного" распределения не существует, т.к. оптимизация существенно использует как особенности задачи, так и железа. А универсальность всегда получается в ущерб оптимальности.



Не проверял, но сомневаюсь, что в МК засунут инструкцию, выполняющуюся сотни тактов.
Для справки: у интеловской x86 инструкции enter есть параметр level, который может изменяться от 0 до 31. Именно об этой вложенности я и говорю. А Вы, вероятно, только про случай level=0. Если ошибаюсь - поправьте.



Почему сразу стек ? Удобнее каждому экземпляру давать структуру, в которой будут все локальности (а также входные параметры), а функциям передавать единственный параметр - адрес этой структуры. Располагая эти структуры в глобальной памяти, можно ограничивать одновременную количество экземпляров, которые сможет обработать МК. (Экземпляр - это ветвь и т.п.). А стек оставьте исключительно для push/pop, call/ret

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


Может быть о разном говорим хотя названия похожи, асма на x86 под рукой нет. Для справки по МК от Fujitsu:
ENTER #N - Function entry processing (где N - объем резервируемой памяти)
LEAVE - Function exit processing
Первая резервирует память в стеке для локальных переменных, вторая освобождает. При этом определенный регистр получает значение адреса начала локальных переменных в стеке, через этот регистр выполняются все операции с локальными переменными.

Зашибись, еще осталось определить union этих структур для каждого уровня вложенности вызовов функций и экономия памяти будет на уровне... про оптимизацию кода и говорить нечего. Титанический труд, сложность сопровождения, т.п. и т.д. и ни какой практической выгоды данного метода. А если OS потребуется запустить то там вообще туши свет, этож придется для каждой задачи объявлять отдельные экземпляры структуры и везде таскать указатели на них. Что-то я не пойму в чем удобство?!
Написал считалку стека для MB9X, достаточно много анализировал расход памяти (стека в том числе) при разных подходах ее распределения. Пришел к выводу что ручное/статическое распределения памяти не дает экономии, часто даже проигрывает варианту с локальными переменными. Не думаю что для других процессоров ситуация будет иная.

Вы не любите котов? Вы просто не умеете их готовить
Сам долго исповедывал взгляды сходные вашим....Пока жизнь не заставила хорошенько покопаться в Сишных листингах. Итак, чем же код генерируемый компилятором отличается от написанного ручками?
1.Стартапом
2.Вызовами/завершениями функций.
Циклы, ветвления, присваивания итп. это и есть тривиальные задачи, котроые мало-мальски нормальный компилятор сгенерит также, как и самый искушенный программист.
Стартап освобождает от совершенно рутинной и тривиальной задачи начальной инициализации памяти.Если у вас на этот счет свои соображения - никто не запрещает вам подключать собственный стартап или вообще обходиться без такового.
Наиболее больной вопрос - вызовы функций и передача аргументов.
Да, нужно это или нет, компилятор приведет все вызовы к стандартному виду. Это дает вполне очевидное преимущество - не задумываться о порядке вызова функций - аргументы передаются гарантировано, гарантировано сохраняется контекст. Расплата за это - несколько больший расход стека и снижение быстродействия.
Однако, если вы более-менее хорошо знаете свой компилятор, это не есть проблема - вы четко знаете, сколько аргументов передастся через регистры, сколько раз вызовется push/pop. Дальше все в ваших руках - минимизация передаваемых аргументов, минимизация локальных переменных, привязка переменных к регистрам, inline -функции.Если вы правильно описали задачу - С быстро сгенерит вам работоспособный код, избавив от рутины и ошибок связанных с ней.
Если время позволяет ее вылизывать - вы можете сделать это не хуже , чем на ассемблере. Если нет, можете оставить все как есть. Меньшее количество текста и недоступные явно метки и распределение памяти сильно облегчит модификцию кода методом copy/paste. Вместе с тем они не будут представлять из себя черный ящик - на физические адреса вы сможете посмотреть в любой момент.

P.S.Здесь длинный спор между мной и dxp на тему оптимизации
у gcc и IAR. Приводится ассемблерный код, можете ознакомится.
http://electronix.ru/forum/index.php?showtopic=12284&st=75

Интересным является два подхода к оптимизации - прямолинейный у gcc и с вывертами у IAR. Так что, и компилятор можно подыскать по вкусу.

Данный ответ был мной предугадан
Жаль, знание возможностей данного языка не было бы лишним.
Экзотичность языка, прежде всего, связана с его малой известностью( если не сказать почти 0-й)
среди российских разработчиков аппаратуры и непониманием его идеалогии.

Если писать на том же асме код значительного размера, то приходишь к той же схеме - придумываешь сам себе соглашения о вызове и свято их придерживаешься! Иначе программа делается не сопровождаемоей даже автором, когда в каждом вызове свои "нюансы". Т.е. залог успеха - формализация подхода. Отсюда и небольшие накладные расходы в некоторых случаях на дополнительное копирование аргументов между регистрами. В подавляющем большинстве случаев роли это сегодня не играет никакой.

Судя по объёму флуда, - асм жив, и более того - alive forever.
Даже те, кто кодят на ЯВУ - всё равно его знают, хотя бы для того чтобы убедится, что высокоуровневый копмилятор не наворотил чего лишнего.

Про альтернативные соглашения при передаче аргументов в асмовской программе - полностью за и тоже использую этот метод.

Со всем уважением к Вам. Не надо никаких если, давайте просто оценим, что же показывает ваш тест!
8 битный AVR - 11+тыс. тактов.
16-битный MSP - 5+ тыс. тактов.
Только с учетом того, что рабочая частота AVR в два раза выше чем MSP, то 8-ми разрядный AVR по суммарной производительности практически равен производительности 16-ти разрядного MSP. Теперь об аппаратном умножителе. Судя по всему аппаратный умножитель AVR не применялся, следовательно для чистоты сравнения надо брать результат для MSP без аппаратного умножителя. Как Вы говорите, без аппаратного умножителя MSP справляется с задачей в 1.5 раза дольше, т.е. 7.5+ тыс. тактов. AVR - 11+ (~12) тыс. тактов
Теперь давайте учтем соотношение частот AVR-16Mhz, MSP-8Mhz.
Сведем все к MSPшным тактам. Один такт AVR равен 8/16 = 1/2 такта MSP.
Домножаем 12 тыс на 1/2
12 * 1/2 = 6тыс. MSPшных тактов.
И получаем, что AVR справляется с задачей за 6 тыс MSPшных тактов, а MSP за 7.5 тыс. тактов.
LOL, так получается AVR еще и "сделал" MSP на 25%.


Если РОНы "шире" - неизбежно операции с плавающей точкой потребуют меньше тактов для исполнения. Поэтому все законно и ожидаемо на 16-bit РОНах FP операции выполняются быстрее, чем на 8 битных. И более того, я сказал бы, что результаты этого теста больше в пользу AVR, т.к. имея в два раза меньшую разрядность, наблюдается замедлениние в два раза (практически линейная зависимость, что вполне естественно).


Я из вашего теста могу построить следующий вывод:
На одинаковых тактовых частотах AVR проигрывает MSP приблизительно в два раза (в большинстве задач - меньше чем в два раза). В реальных задачах AVR работает быстрее чем MSP430 за счет более высокой тактовой частоты ядра, поэтому добавив еще и факт, что AVR дешевле MSP - целесообразнее применять именно AVR.


Вы хотите сказать, что Bf будет 1.25+ тыс тактов выполнять код из Вашего теста?

Да что вы все прицепились к этому тесту?! Я сразу сказал и повторил, что это, во-первых, не тест как таковой, во-вторых, он не характеризует картину в полной мере - тут плавучка, а значит тут доминируют два фактора: 1) реализация библиотек, где определены подпрограммы операций с плавающей точкой; 2) эффективность ядра, т.к. операции в ядре доминируют над операциями с памятью. У MSP430, как и у любого фон Неймана, работа с памятью - слабое место. А вот ядро у него хорошее - регистровый файл, каждая операция в регистрах за один такт. Никакой 8-битных процессор тут не поспорит. Вот и все. И давайте уже оставим этот фрагмент кода.

На деле, как уже неоднократно сказал, MSP430 быстрее почти везде. При равных тактовых, ессно, т.к. сравнивается эффективность ядра.


Какую-то Вы тут софистику устроили. Зачем это? В реальных проектах MSP430 быстрее почти везде. Не в два раза, конечно, но процентов на 10-20. Это неоднократно установленный мной факт. Хотите поисследовать - пожалуйста, все в Ваших силах. Начать можете с того примера, который я уже предлагал, там почти одинаковый код. Очень хорошо видна реализация в обоих случаях. Упора на 16-битность данных там нет.


Вы еще забыли про потребление. Вот тот полином у меня вычислялся в проце, работающем на 5 МГц - хватало, - при этом весь МК побреблял около 2.4 мА при питании от 3 В. Дивайс батарейный. Найдите-ка мне такой AVR? В реальных задачах надо не максимальную скорость - тут главное, чтоб успевал с некоторым запасом. А вот потребление частенько требуется как можно меньше. Вот у меня МК посчитал результат, отправил его на вывод, и на боковую (в Idle). А из Idle он просыпается за 6 мкс. Таким образом, почти все неактивное время он спит, переход ко сну и обратно почти ничего не занимает. Эффективность максимальная.

Насчет того, дешевле ли AVR - это еще вопрос! AVR не предлагает полноценной замены MSP430 почти во всем: он медленее, он больше потребляет, у него почти во всем хуже периферия, у него нет такой удобной и гибкой системы распределения тактовых частот. Кроме того, у MSP430 на борту встроенный отладчик, который требует копеечного адаптера, в отличие от AVR, которому нужен недешевый JTAG-ICE, работающий к тому же нестабильнее и медленнее. Возможности отладчика в MSP430 новых моделей несравенно богаче - до 8 аппаратных брейкоинтов, не только на код, но и на данные, всякие условные брейкпоинты и т.д.

Преимущества AVR я уже перечислял выше - возможность 5 В питания, если кому актуально (мне,например, никогда это не было актуально - наоборот, от 5 В только лишнее энергопотребление), возможность внешней аппаратной шины у некоторых МК (опять же это только пара чипов, да и на MSP430 можно программно это организовать, написав класс-шлюз, чтобы работа со стороны программы была прозначной по отношению к этой шине), наличие EEPROM (здесь удобство AVR неоспоримо, но с MSP430 большого головняка не вышло - тоже написал класс, который манагит запись данных в блоки флеши попеременно, пользоваться этим просто и безопасно. С EEPROM'ом, кстати, тоже для надежности надо дополнительный код писать, с резервированием значений и проверкой при записи/чтении, т.ч. оно где-то одно к одному и выходит). Это практически все.

На деле существуют ситуации, когда AVR выгоднее и без этих оговорок - когда требования проекта удовлетворяются возможностями МК. Например, если хватает меги8, то и замечательно, ничего больше не нужно, даже если есть и более замечательные МК. Фактически же главным фактором является даже не возможности МК, а владение конкретным разработчиком тем или иным МК. Если человеку, работающему с AVR что-то в нем не хватает, он в большинстве случаев поставит недостающую часть снаружи (вплоть до применения второго МК), но не будет переходить на MSP430. Это психология и инертность мышления. А также требования по времени к выполнению работы на фоне внутренней увереннности в результате. По этой причине до сих пор жив 51-й (конечно, есть тут и другая причина - поддержка старых разработок, но старые разработки требуют старых МК, на оригинальном 12-тактовом ядре, а вот все новые, с новой периферией и новыми возможностями - это исключительно психология).


Что Вас удивляет? У него нет аппаратной поддержки плавающей точки.

Ссылка на интересную статью и ресурс для роботостроителей.
( в проекте используется ATMEGA128 )

http://rema.44.ru/about/persons/dobrinin/

P.S. Не ассемблер, но тоже интересный подход.
Не знаю, в какой топик лучше поместить.?

Еше 2 года назад писал Vxd драйверы под windows на асм.Умер 98 и умер ассемблер.Последнее за,
что он цеплялся , так это Vxd драйверы.Кто из вас пишет WDM драйверы на асм.?Хотя на WASM.ru
еще остались защитники ассемблера.Сидят и переписывают всю майкрософтскую библиотеку под
асм.Зачем? Также будет и микроконтроллерами.Меня уже не заставить писать на асм.Программу,
которую я напишу на Си за 1 час ,на асм. буду писать около месяца.Для меня это уже недопустимо.
Вспомните как противились использованию калькуляторов в школах.Боялись, что ученик разучится
умножать в столбик.Хотя калькулятор его избавил от того, что он мог не решить основную задачу
если не умножил бы 2х2.
Прощай асм.

Интересно, как, например, Вы будете делать сохранение констакста при переключении задач ОС без асма? Таких примеров еще можно найти. Поэтому давайте различать асм, как основной инструмент для написания программ, и как вспомогательный. Как основной он уже умер (за исключением отдельных случаев типа DSP, но и там тенденция однозначная). Как вспомогательный инструмент он жив и будет жив до тех пор, пока живы процессоры.

Ну вот ещё пример - о вечном. Совершенно прикладная прога - огромный объём вычислений с плавучкой - обработка больших объёмов экспериментальных данных. Среда разработки - даже никакой не МК, не ДСП -а борланд Ц++ под виндой 2000 - казалось бы какой в баню ассемблер - это даже не системный уровень.
Ан нет - мне показалось не влом потратить день на переписывание трёх строчек Ц на 18 строк асма х86 и сократить время обработки блока данных с 12 минут до 2. Временные затраты на отладу отбились за неделю использования проги. Опять же код переносим на любой х86 проц с FPU - то есть практически работает на любой машине.

Дык если с умом писать то разгонишся очень сильно
Было у меня куча проектов достаточно сложных и объемных и в 512байт влезал аж бегом.Асм нужен для того чтобы тока критические секции писать.

У AVR регистр-регистр тоже за один такт. А ещё за один такт - вывод в порт, в отличие от 3-х тактов MSP. Не знаю, как у кого, а на моих задачах MSP всегда оказывался медленнее AVR. Правда, DMA я не использовал. Поэтому я потренировался немного на нём, да и передумал с AVR на MSP переходить.

Что касается цены, то MSP-149 стоит в районе $3.5, а AtMega8 $0.8.
Единственное, что остаётся у MSP - энергопотребление. Но если исполнительные устройства едят на два порядка больше проца, то какая разница?

Только у MSP430 16 бит, а не 8. :-Р Потому и сказано было, что никакой 8-битник тут не угонится, не нужно из контекста выдирать.


У MSP430 это не вывод в порт, а обращение в память. А то, что порты и другие регистры на память отмаплены - это очень правильное, здравое и зрелое решение. AVR из-за своих in/out, во-первых, ввел еще одно адресное пространство - трех имеющихся ему мало, во-вторых, на меге128 и других толстых чипах имеем форменный геморрой, когда регистры специальных функций не помещаются в это маленькое адресное пространство. Кроме того, за сколько тактов выполняется инверсия пина на AVR? И не забываем весь связанный с этим геморрой, когда нужно использовать два регистра - а если это делается в прерывании, то их надо сохрянять - еще оверхед, когда операция эти неатомарна и т.д. :-Р


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


Ха! Нашли что сравнивать! Да MSP430F149 кроет ATmega8 как бык овцу! У меги скока флеши? 8 кил, а у F149 - 60! ОЗУ у меги 1 килобайт (и это много для такого чипа, непропорционально, я бы сказал, много), у F149 - 2 килобайта. У F149 12-разрядный АЦП с 200 К выборок в секунду, с секвенсором на 16 значений, с индивидуальными настройками опорных напряжений для каждого канала, с различными режимами запуска и т.д. Тут вообще ни один AVR близко не стоял! У F149 два полноценных таймера с суммарно 10 модулями Compare/Capture/PWM. У F149 два USART'а, каждый из которых может быть сконфигурирован либо как UART, либо как SPI. Наконец, у F149 6 8-битных портов, т.е. 48 ног на ввод/вывод.

Кроме того, откуда такие сведения про цены? MSP430F149 стоит существенно дороже - порядка 7-10 баксов. Мега8 тоже больше бакса - порядка двух баксов. Но в любом случае это МК разной весовой категории уже по объему флеши. Одноклассником MSP430F149 является Мега64, и стоит она примерно те же пятаки. А по периферии все так же пролетает. Кстати, MSP430F149 - это уже старый чип, сегодня за почти такие же деньги есть MSP430F169, у которого помимо вышеперечисленного еще есть два 12-битных аналоговых ЦАПа, DMA.


Да уж конечно! Особенно если забыть, что ни у одного AVR нет такого АЦП, ни у одного AVR нет таких ЦАПов (если вообще есть какие-то, я уже перестал за ними следить), если забыть про десяток ШИМов, в том числе и 3 синхронных парафазных с мертвыми зонами, если забыть про аппаратный умножитель-аккумулятор 16х16, которого в AVR нет и, очевидно, не будет.

В заключение, имея пятилетний опыт плотной работы с AVR, имея 3-летний опыт не менее плотной работы с MSP430 (т.е. не потренировался, а именно поработал, сделал эн проектов на нем), могу ответственно сказать, что работать с MSP430 намного приятнее во всех смыслах. Благодаря более стройной архитектуре с одним адресным пространством вместо четырех у AVR, и благодаря более прямой, гибкой и богатой периферии.

Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.587 я программировал.
И менчя до сих пор в жар бросает.
Ваши споры полезны в отдельном форуме по максимальному, рациональному использованию МК и
его компиляторов , а не о вечности ассемблера.

Ну вот например смотрим в ДШ на ATmega 48/88/168 и видим
ACTIVE SUPPLY CURRENT vs. VCC
INTERNAL RC OSCILLATOR, 8 MHz
на 3V примерно 2,7ma

А еще у него есть такой регистр CLKPR который позволяет делить тактовую в
1,2,4,8,16,32,64,128,256 раз. (с соответствующим уменьшением потребления)

ИМХО: как раз для батарейных девайсов актуально писать на ASM, т.к. это позволяет
быстрее сваливаться в Idle или Power Down и экономить энергию.

Бейсик изучать точно не буду.

Когда внутрь микропроцессора засунут Бейсик/Паскаль/С/С++/Питон/др., это будут уже не Бейсик/Паскаль/С/С++/Питон/др - это будут уже ассемблеры, похожие на Бейсик/Паскаль/С/С++/Питон/др. Сегодня (и уже давно) фирма ADI применяет для своих DSP ассемблер с алгебраическим синтаксисом, он очень похож на С. И тем не менее, это ассемблер. Не думаете же Вы в самом деле, что появится процессор, у которого на асме можно будет написать TSlon *p = new TSlon;? В любом случае это будет язык элементарных операций данного процессора - его инструкций. И если мнемоники типа mov и jmp будут заменены на свои аналоги из ЯВУ, ассемблер от этого ассемблером быть не перестанет. Уровень абстракции все равно низок, переносимости и стандартности все равно нет.

Вот когда на уровень железа процессоров перенесут абстракции высокого уровня, т.ч. не будет никаких байтов и битов, а будут только объекты в памяти, не будет никаких разных адресных пространств, а будет просто память, где лежат объекты, когда работа с этими объектами - создание, удаление, инкапсуляция (сокрытие внутренней реализации) и многое другое, что свойственно ЯВУ будет реализована на уровне железа процессора, вот тогда можно будет говорить о смерти ассемблера. Только это будет (если будет) уже совсем другой процессор, и вряд ли мы дождемся наступления этих времен.


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

Абсолютно необоснованное. Тяжкое наследие ПДП-11.


Я тут не трактую за всех, только лишь за себя. На моих задачах хватает и 4К флеша. Зато не хватает быстродействия у MSP. Его сильно шустрый АЦП и вовсе членомерия, поскольку сделать сколько-нибудь осмысленную обработку отсчётов, прущих на такой скорости, MSP всё равно не успевает. И периферия его замечательная меня не лечит. В последней задаче каналов ШИМ мне надо 12. А входной сигнал имеет Ft=19кГц. Его надо фильтровать и шевелить каналами ШИМ.

Ну,в общем я с вами согласен.Мы говорим об одном и том.
Только я не согласен со временем.Все наступит намого быстрее.

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


PDP-11 был прекрасный процессор, гибкий, продуманный. Жаль, что развития эта ветка не получила. Во мне говорит не ностальгия, я с ним не работал, не застал уже. И если сегодня уже давно смогли соорудить 1-тактовый 51-й, то и PDP-11 реализовать на быстром ядре было бы возможно.


Быстродействия какого? Вычислительного? Это вряд ли. Ногодрыгания? Вот на это похоже. Для формирования жестких времянок вообще надо периферию использовать. Делать это с помощью программной реализации - хакерство, чреватое гемором.


Никакая не членомерия. Для таких быстрых потоков там у АЦП есть секвенсор, который собирает сразу до 16 отсчетов, благодаря чему не надо прыгать за каждым отсчетом отдельно, имея оверхед, что и происходит с AVR'ом, а один раз пошли и забрали сразу все 16. Получается для максимальной скорости 5 мкс * 16 = 80 мкс период поступления прерываний, вполне реально. Насчет "делать осмысленную обработку отсчетов, прущих на такой скорости" - есть задачи, когда надо собрать данные, собирать надо на максимальной скорости. А обсчитать их можно и потом. В любом случае AVR тут курит в уголке.


Кто ж спорит, не на все случаи жизни MSP430 годится. Для этой вашей последней задачи самое оно TMS320F28xx. Или Вы хотите сказать, что мега8 здесь замечательно справляется?

[quote name='dxp' date='Jun 29 2006, 11:17' post='129281']
Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.[/quote]

Когда внутрь микропроцессора засунут Бейсик/Паскаль/С/С++/Питон/др., это будут уже не Бейсик/Паскаль/С/С++/Питон/др - это будут уже ассемблеры, похожие на Бейсик/Паскаль/С/С++/Питон/др. Сегодня (и уже давно) фирма ADI применяет для своих DSP ассемблер с алгебраическим синтаксисом, он очень похож на С. И тем не менее, это ассемблер. Не думаете же Вы в самом деле, что появится процессор, у которого на асме можно будет написать TSlon *p = new TSlon;? В любом случае это будет язык элементарных операций данного процессора - его инструкций. И если мнемоники типа mov и jmp будут заменены на свои аналоги из ЯВУ, ассемблер от этого ассемблером быть не перестанет. Уровень абстракции все равно низок, переносимости и стандартности все равно нет.

Вот когда на уровень железа процессоров перенесут абстракции высокого уровня, т.ч. не будет никаких байтов и битов, а будут только объекты в памяти, не будет никаких разных адресных пространств, а будет просто память, где лежат объекты, когда работа с этими объектами - создание, удаление, инкапсуляция (сокрытие внутренней реализации) и многое другое, что свойственно ЯВУ будет реализована на уровне железа процессора, вот тогда можно будет говорить о смерти ассемблера. Только это будет (если будет) уже совсем другой процессор, и вряд ли мы дождемся наступления этих времен.

[/quote]

Сейчас одно из основных напрвлений разработки, например с Soft процессорами в этом и состоит
под конкретную задачу выбирается система команд создается необходимый инструментарий
поддержки. В итоге стирается грань между софт и железными процессорами.

ЯВУ уже вставляли и вставляют в процы. Например Java, Forth:)

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

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

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