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

[OlegIvanov]

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

[CD_Eater]

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

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

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

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

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

[spf]

Трёх указателей всегда хватало.

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

По поводу стека - при правильном распределении регистров использование стека минимально.

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

Пихать в него параметры функций и создавать там локальные переменные - дурная привычка компиляторов с ЯВУ.

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

Кстати, раньше, как Вы, наверное, помните, в x86 был тот же подход - кроме указателя стека (SP, относительно которого нельзя адресоваться к данным в стеке) для стековых операций резервировался ещё один регистр (BP, полноценный), полную аналогию чему наблюдаем в компиляторах под AVR.

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

Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ?

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

Стек хорош для алгоритмов, когда размер данных, помещаемых в стек, предсказать сложно. Например, рекурсий. Для МК это непозволительная роскошь (по крайней мере, пока размер стека исчисляется сотнями байт). И подход к использованию стека в МК должен отличаться от принятого в софте настольных компьютеров.

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

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

[Kopa]

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

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

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

[SpiritDance]

А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

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

[Kopa]

А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

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

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

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

[SpiritDance]

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

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