С# это условно копи пасте Java, но попозже. Сишники с двумя плюсами погнались за явовскими вкусностями типа гарбаш коллектора и тд и накатали свою решётку. TCP стек на ассемблер ну месяц от силы на М4, знаю американских перцев, которые только и пишут на асе под кортексы. Чуть дольше писать, чем на си, но такие челы имеются, и ценятся. Думаю от прикладных задач зависит.


Архитектура то да, а вот фасад с заборами и решетками у каждого свой.

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

Надо заметить что в этом случае код написанный на Ассемблере завязнет гораздо капитальнее

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

На сях это бы в память не влезло, а тут еще 250 байт осталось!

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



Понятно, хотя считаю динамическое выделение памяти злом, особенно в работе с хардварными девайсами и в режимах хотплаг, особенно, но это о пичках, в ООП без нее не обойтись. А вот "процесоро-независимым" считаю вообще не особо актуальным, т.к. 99% програм на дотнетах пишутся под винду на х86 машинах...

Сообщение отредактировал mantech - Mar 30 2015, 19:30

А смартфоны? А планшеты? Пополз микрософт и на другие платформы...



Откуда взялся миф что код на С всегда больше чем на Ассемблере?
Он больше когда пишут быстро и просто, но если задаться целью убиться об размер.... Не забываем опять же что есть оптимизация, которая иногда делает удивительные чудеса)

В некоторых случаях ручками можно получить код компактнее, но эти случаи очень уникальны. Например, 24-битная арифметика на AVR (из жизни).
В мелких задачах (а именно такие задачи решают "моргальщики светодиодом"), КПД можно поднять чуть ли не в разы, но в серьезных проектах С-оптимизация уделает любой asm-код начального уровня.

Помницо... лет 5 назад... мерялся с С в части подсчета md5 (Cortex-M3): взял алгоритм из описания и сбацал его на Си за пару минут. На asm пыхтел дольше и... проиграл. В итоге удалось чуть-чуть победить С, когда использовал команды групповой загрузки регистров из памяти. С учетом полного объема кода выигрыш оказался мизерным.

Вывод: asm в серьезных проектах нужно знать для чтения листингов, а не для разработки.
Кста, в avr мне до сих под проще написать на asm (не забуду войну с С, когда нужно было написать с точностью до тактов soft-UART передатчик).
Кста2, а генерацию VGA картинки (прием символов по UART и отображение их на VGA-мониторе) для cortem-m3 делал на C без единой asm-строчки.

Я смотрю развиваются несколько стандартных войн:
1) AVR vs ARM / Cortex
2) IAR vs KEIL
3) ASM vs C (как же без этого)

Правда развиваются вяло, так как энтузиастов уже маловато. )))
По моему сейчас уже даже оптимизацией вручную на среднем проекте нет смысла заниматься. Компилятор хорошо оптимизирует наиболее распространённые языковые конструкции.
Начинаешь умничать - иди смотри результат компиляции. Не факт, что он будет лучше.
А в целом, самое дорогое - это время. Тратить год на перенос проекта под ASM, по моему преступление против себя. Выигрыш будет ровно такой, какой будет за счёт выхода нового проца за это же время. ))

Я M7 позиционирую для работы с TFT. В своё время был знаменитый LPC2478 - сделал на нём проект. Потом появился нога в ногу LPC1788 на кортексе, так только за счёт шинной архитектуры был выигрыш процентов на 20%. Это было даже визуально видно на дисплее 4.3" 480x272x16. Поскольку в целом даже этого камня хватало для более менее приличного проекта, то думаю М7 потянет 7", естественно без всякого видео. Ну я про stm. На М4 даже и не успел с TFT поработать. Уж больно сложный проект был. Более 2-ух лет. )))

А это зависит от того какие ошибки чаще делаете.

90% времени это отладка.
Если по любому во время отладки все смотрят скомпиленный код, то не лучше ли его сразу писать на asm?
Здесь еще отягчающее обстоятельство может быть в том, что человек не использует нормальные инструменты для отладки вроде IAR или Keil-а, а сидит на голом GCC.
У того тоже могут быть серьезные причины.

Так что у каждой войны свой контекст, просто надо в нем разобраться.

Это вялое разжигание указанных войн, но неплохой вброс для следующей.

У меня больше времени уходит на архитектуру. А при хорошей архитектуре отладка занимает мизерное время. Дольше тратиться на написание стандартных тестов, проверки функциональности устройства.

Из всего этого мне ни разу не удобнее на АСМе потому что дольше, и текст хуже читаем.

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

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

SAM V71 Xplained Ultra Evaluation Kit



Atmel уже выпустил демо-плату для V71 (это почти как E7, только автомобильный)!
Цена $136.25 в партии из 10 шт.

Тут User Guide для нее, а тут на нее схемы, герберы и прочая документация.

Под S70 и E70 тоже обещают такого же вида платы выпустить, но пока ничего конкретного не нашла.

Но плата получилась очень симпатичная. На нее сверху, как на Arduino, можно свою самоделку водрузить, благо разъемчики для этого есть.

http://www.atmel.com/tools/ATSAMV71-XULT.aspx

Тут, наверно, ачипятка - SAM7S всё же ARMv4T, полноценный ARM

Зависит. Вот sdcc для CC2530 (8051) такой код производит, что хочется обнять и плакать..
Ну понятно, он же клепает дженерик и не пользует все его свистульки для облегчения жизни:
второй DPTR, восемь банков Rx регистров..

Но когда читаю асм код.. Не знаю, не пробовал IAR для этого..

Да, по ошибке вместо SAM S7 написала SAM7S.
Свой пост поправила.

Да пусть ползет куда хочет, но львиная доля - это псишники под виндой.

Миф берется из реальности, ибо та же самая прога, с учетом оптимизации и т.п. не влезала на 100 байт...
Мое предположение - происходила инициализация "по умолчанию" того, что мне было не нужно, си, как правило много bitbang-операций заменяет на код "прочитал-изменил-записал", когда нативно это делается 1 командой, ну и вход-выход в прерывания, как правило сохраняет больше регистров, а на асме можно сэкономить, выделив регистры в "глобальное" использование, без сохранения...




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

Для всего остального есть консоль, либо жк-индикатор, или экран.

За такты и байты не борюсь, но если есть возможность сделать код оптимальнее - не отказываюсь.




Слабоваты они для дисплеев, разве, что только в качестве более расширенных жк-индикаторов. Чтоб был нормальный дисплей и на нем не было слайд-шоу, нужно по крайней мере ддр2или3 и какой-либо апп. ускоритель.



Каждое для своей категории:
1) авр для мелких задач, арм для задач быстродействия, сети, дисплеев
2) на любителя, я выбрал иар, т.к. считаю, что у него более путная иде и неплохой компилятор.
3) си уже дефакто везде, на чистом асме "ваяют" только маньяки...



Ну если сам делал это на меге128, на асме правда, то уж кортекс-то с этим на раз-два справится

Хорошие RTOS-ы (MQX) имеют спец опции для управления объемом сохраняемого контекста.



Не забываем про поддержку очень старого оборудования.
Например в RTOS NuttX штатно идет эмулятор команд Z80.
Вот эмуляция всяких зайлогов тоже интересная тема для M7.