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

[OlegIvanov]

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

[CD_Eater]

Поправьте, если я ошибаюсь, но, на мой взгляд, требования к ОЗУ одинаковы что у ассемблерной программы, что у сишной, и определяются исключительно потребностями алгоритма.

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

Свежий пример - возникла необходимость добавить функций в устройство; заменили в приборе мегу128 на SAM7S, т.к. перестало хватать ОЗУ под алгоритм. Весь перенос софта в результате был сведён к освоению новой периферии. Сколько бы я переносил его, будь он написан на ассемблере - страшно и представить

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

сложные математические алгоритмы (фурье, сжатие) не зависят от используемого железа.

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

Знаете ли быват очень приятно, общие константы и структуры расшарить между софтом МК и РС.
Одно изменение попадает сразу в оба проекта

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

[vet]

Свежий пример - возникла необходимость добавить функций в устройство; заменили в приборе мегу128 на SAM7S, т.к. перестало хватать ОЗУ под алгоритм. Весь перенос софта в результате был сведён к освоению новой периферии. Сколько бы я переносил его, будь он написан на ассемблере - страшно и представить

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

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