ptr128 писал(а):Я не знаю, что Вы называете "классическим ассемблером", так как когда я впервые начал писать на ассемблере 8080 в 1984 году, то использовал для этого макроассемблер IBM/370 в режиме кросс-компиляции.
Под классическим ассемблером понимаю написание программ обычными ассемблерными командами: mov, ldi и т.д.
Макроассемблером условно называю язык АБ (Algorithm Builder), в котором широко используются макрокоманды и подпрограммы с параметрами. Встроенные макрокоманды расширяют действия обычных ассемблерных команд на многобайтные переменные. Скажем, а — 4-хбайтная переменная в SRAM, b - 4-хбайтная переменная в EEPROM, сложить эти переменные можно одной встроенной макрокомандой: a + b, наглядно и просто.
ptr128 писал(а):IMHO, если планируете профессионально программировать МК, то учите С, а макроассемблеры оставьте в покое. Даже несмотря на то, что использование asm в С требует несколько большей писанины, чем написание модуля на макроассемблере.
В итоге, оно окупается сторицей на всех этапах жизненного цикла ПО
На мой взгляд, на макроассемблере АБ будет не «несколько меньше писанины», а глобальное упрощение программирования. Без примера такое заявление звучит неубедительно. Приведу простой пример из практики, измерительный прибор, который по затуханию сигнала определяет концентрацию вещества М.
Для такого измерения центральный МК должен считать с периферийного МК (расположен в блоке 1) опорный сигнал Vopor и измеренный после затухания сигнал Vizmer. Затем разделить один сигнал на другой, взять логарифм, провести калибровку, упаковать для вывода на индикатор и вывести на индикатор. Упрощённо на АБ программа будет выглядеть следующим образом:
Read_Blok_1 (Read_Vopor, Vopor, 4)
Delenie (Vopor, Vizmer, Itog_Delenia, 1)
Log_10 (Itog_Delenia, M)
Kalibrovka_1024 (M, ee_Koef_M)
Upakovka (M, Indicator)
Vyvod_Indikator
Это всё библиотечные элементы, только надо несколько настроить под параметры задачи.
Написать и отладить по времени займет, наверно день, два.
Объём будет довольно приличный . Один логарифм займет более 1 КБ, Read_Blok_1 (чтение данных от другого МК с проверкой, повторными запросами при неудачном обмене, чтением состояния периферийного МК и т.д.), вроде бы, ещё более мощный элемент.
Это, практически, ассемблер с его скоростью, гибкостью и небольшим объёмом кода.
Думаю, если бы АБ развили для других семейств МК, можно было бы программы без проблем переносить на другие семейства. Сошлюсь на вашу фразу: «Все особенности структуры ядра и системы адресации без проблем учитываются при написании макроса, формирующего машинную команду».
ptr128 писал(а):Код на ЯВУ может быть автоматизировано проанализирован на предмет надежности и безопасности. Для ассемблера я таких анализаторов не встречал.
Думаю, можно было развить и анализ на надёжность и безопасность и прочее. Вопрос в том, кто будет это делать. Труда много, а этот труд денег не принесёт. Более того, для производителей МК будет ещё и убыток, ведь объём написанных программ будет значительно меньше, значит, будут покупать более дешёвые МК.
Получается, наработались, а прибыли упали. Капиталисты деньги считают.
По сравнению с тем же fasm-ом GAS убог по части макроязыка. Вероятнее всего потому что он не ориентирован на использование в качестве самостоятельного инструмента.
Кто утверждает обратное - тот очевидно не знаком с fasm.
