Z_h_e писал(а):AQ29 писал(а):Макросы банальные, имеют минимальный объём, пользоваться просто.
Это некорректное утверждение, макрос по сути это оператор ЯВУ и имеет значение во что он скомпилируется. Не скажу что мне понравились макросы ENTER LEAVE, но второй сам восстанавливает сохраненное, не нужно параметры указывать.
Скомпилируется в точно те же команды, которые пришлось бы писать «вручную».
Макрос очень прост, можно даже здесь привести:
IN_Stek_3 (aa, bb, cc)
~aa →
~bb →
~cc →
→ это в АБ операция записи в стек. Второй макрос аналогичен.
Часто при написании подпрограмм использую сохранение в стеке. Писал «вручную», ARV подтолкнул к мысли, что можно ввести небольшую автоматизацию.
Для вызова второго макроса нужно просто скопировать команду первого макроса и изменить буквы в имени с IN на OUT, поэтому параметры указывать не надо. Вот при изменении параметров придётся, конечно, корректировать второй макрос, но это мелочь.
Z_h_e писал(а):AQ29 писал(а):Я без проблем писал программу 32 КБ
Безо всякого намерения как-то принизить Ваши результаты работы, но скажу, большой размер кода не показатель успешного программирования.
Пожалуйста только не развивайте тему, какой язык круче. Этого тут и так хватает и членами все давно перемерялись.
Это понятно. Здесь токмо в плане занижения возможностей ассемблера. Порог 8 - 16 КБ — явно мало. Скажем, в программе нужно взять логарифм. Секунд за 15 написал команду (вызов библиотечного элемента)
Log_10 (a, b)
и готово, кажется, более 1 КБ отлаженного ассемблерного кода.
Здесь двухбайтная переменная a – аргумент логарифма, b – итог вычисления логарифма.
BOB51 писал(а):
Да и задачи для большого объёма кода иные. Тут даже наоборот - преимущество за малыми по объёму фрагментами при их последующей "склейке" в нечто более объёмистое.
Насчёт преимущества не понял. И небольшие подпрограммы (хорошо написанные) хороши, и большие хороши. Скажем, из нескольких небольших библиотечных элементов написал большой библиотечный элемент - логарифм. У кого какое преимущество?
BOB51 писал(а):
Насчет макросов... более показатель недостатка стандартных команд для пишущего прожку.
Частенько от оных избавляет точно продуманный алгоритм с использованием уже имеющегося в наличии арсенала команд и правильно подобранного для конкретной цели МК.
В АБ нет библиотеки, поэтому стандартные команды (умножение, деление, тот же логарифм) приходится искать или создавать самому.
Reflector писал(а):
Одно из основных отличий ЯВУ - это переносимость программ. Допустим завтра ты решишь переходить на STM32, а там нет АБ, ассемблер совсем другой и практически никто на нем не пишет. В итоге все свои наработки на авр-м ассме придется переписывать на С(или опять на ассме, что еще хуже).
У АВР широкая номенклатура микроконтроллеров, обещают поддержку 10 лет, так что не вижу смысла переносить программы.
ptr128 писал(а):
Во-первых, на ассемблере пишутся программы любого размера. Сам на IBM/370 участвовал в создании кода на несколько сот килобайт. Но там просто не было ЯВУ позволящего эффективно использовать ресурсы каналов и стоек управления. Наилучшее приближение обеспечивал COBOL, но писать на нем - еще то удовольствие.
Во-вторых, ассемблер ну никак не может быть приближен к языку высокого уровня. Хотя бы потому, что ЯВУ обязан быть не зависящим от платформы и заниматься оптимизацией, а ассемблер никогда этим не занимается. И если для какого-то участка кода ассемблер кажется приближен к ЯВУ, то вы используете ассемблер не по назначению и эффективней этот код было бы написать, например, на С.
COKPOWEHEU писал(а):Что считать эффективностью. Затраты на написание программы или затраты на ее исполнение. По первому пункту ЯВУ обычно уделывают ассемблер, по второму - наоборот.
Насчёт приближения к ЯВУ сказал не в теоретическом, а в практичном смысле.
Переносимость программ в пределах семейства АВР хорошая, а на другие семейства переходить не вижу смысла.
Зачем нужна оптимизация для хорошо написанной на АБ программе?
Насчёт эффективности тоже вопрос.
При наличии нужных библиотечных элементов время написания, думаю схоже. Отладка в АБ, думаю, намного проще. Ну а про скорость выполнения и объём — все знают.
Это как-то связано с этими самыми прерываниями? Я только "первый раз сказал Мяу". Какие вкладки в AVR Studio 4.19 надо открыть, чтобы этот процесс отследить, понять и избежать?
И вааще на С пишут те, кто на бейсике писать не умеет. 
