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

[OlegIvanov]

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

[beer_warrior]

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

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

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

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

[dxp]

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

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