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

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

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

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

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

Возможно, что я не прав, но меня пугает "вредная привычка" всех компиляторов - фривольное обращение со стеком. Типичный размер стека в моих программах = 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, МК/не МК и т.д. и пришел к определенному выводу относительно этой классификации, который мне кажется весьма здравым и правильным. Я его озвучу, если хотите.