Не эффективно, это когда "овчинка выделки не стоит". То есть, когда трудозатраты на ассемблерное кодирование оказались больше, чем экономический эффект от них. То есть эффективно - это верно выбранный баланс между тем, какой код проекта следовало писать на ЯВУ, а какой на ассемблере.
Что вы понимаете под ассемблерным кодированием? Писать на классическом ассемблере сложно, трудно, давно на нём не пишу, на мой взгляд, это сейчас анахронизм. На макроассемблере писать просто и в тоже время можно быстро «опуститься» на ассемблерный уровень. Практически,весь текст на макроассемблере представляет собой макрокоманды, вызов подпрограмм (функций, процедур) и т.д. В этом плане говорил, что он приближён к ЯВУ. Пример функции уже приводил — логарифм, вызвав которую сразу получаете более 1 КБ. Это, кстати, не самый большой библиотечный элемент.
ARV писал(а):
на сегодняшний день вопрос прироста производительности не стоит вообще, т.к. быстродействие даже микроконтроллеров AVR достигла такого уровня, что задумываться о быстродействии практически не приходится. если же взять мир 32-битных и тем паче 64-битных контроллеров, то там и подавно. про PC вообще молчу.
«задумываться о быстродействии практически не приходится» Сомнительное утверждение. Электронщику часто приходится сталкиваться с быстродействием. То импульсы нужны микросекундные, то в быстрой следящей системе нужно успеть рассчитать управляющий сигнал, то нужно провести скоростные измерения в быстротекущем процессе. Большей частью с помощью ассемблера и АВР эти задачи легко решаются, зачем применять более сложные и дорогие решения. Благодаря РОН АВР довольно быстро работает. Только, на мой взгляд, в простых микроконтроллерах явно не хватает аппаратного умножения 2 на 2 байта. По цене, наверно, это стоить копейки, а существенно ускорит расчёты.
dimmer писал(а):
Во-первых не нужно извращать мои слова. Я нигде не писал, что 8 - 16 Кб это порог для ассемблера. Дословно было:"Я думаю, что если в будущем понадобится писать что-то больше 8 - 16Кбайт, то одним ассемблером наверно не обойдусь." Имел в виду, что как будет подходящая возможность, то хочется попробовать что-то другое (скорее всего С++). Во-вторых, если коротко по поводу остального, что Вы написали - это по ту сторону Добра и Зла.
Не собирался извращать ваши слова.
«по ту сторону Добра и Зла» - это, вроде как, что-то из большой философии. А программирование на макроассемблере — при некотором навыке это обыденно и просто.
То есть, когда трудозатраты на ассемблерное кодирование оказались больше, чем экономический эффект от них.
Что вы понимаете под ассемблерным кодированием? Писать на классическом ассемблере сложно, трудно, давно на нём не пишу, на мой взгляд, это сейчас анахронизм. На макроассемблере писать просто
Я не знаю, что Вы называете "классическим ассемблером", так как когда я впервые начал писать на ассемблере 8080 в 1984 году, то использовал для этого макроассемблер IBM/370 в режиме кросс-компиляции. То есть каждой машинной команде 8080 соответсвовал свой макрос. С тех пор ни разу, ни для какой платформы мне не макроассемблеры не попадались. Даже тупой ассемблер на Синклере для Z80 был макроассемблером. Исходя из того, что макроассемблер IBM/370 был аннонсирован, и широко использовался для кросс-компиляции, за год до выпуска первого микропроцессора 4004 (1970 vs 1971), я даже не представляю, где и на каких платформах Вы откопали "классический ассемблер", не являющимся макроассемблером.
Другое дело, что на макроассемблере я давно не пишу. За ненадобностью. Механизма ассемблерных вставок в C мне хватает с головой. Не так уж часто необходимо высчитывать такты каждой команды и экономить наносекунды. Так что под ассемлерным кодированием я подразумеваю, в первую очередь, оператор asm языка C.
AQ29 писал(а):
он приближён к ЯВУ.
Категорически не согласен. Код на языке высокого уровня всегда можно написать кроссплатформенным. Код на ассемблере - никогда. Код на ЯВУ может быть автоматизировано проанализирован на предмет надежности и безопасности. Для ассемблера я таких анализаторов не встречал.
Именно потребность в надежном и кросcплатформенном коде и привела к тому, что в рамках промышленного производства ПО для МК все большее количество производителей приходят к стандартам MISRA. IMHO, если планируете профессионально программировать МК, то учите С, а макроассемблеры оставьте в покое. Даже несмотря на то, что использование asm в С требует несколько большей писанины, чем написание модуля на макроассемблере. В итоге, оно окупается сторицей на всех этапах жизненного цикла ПО. Привыкните. Как я, например, уже физически не могу написать даже простейший код без включения его в систему контроля версий. Рефлекс однако )
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
А как конвертится число, лежащее в двух регистрах в 4-х значное десятичное (0000, с разложением в 4 регистра)? Тут катит только способ последовательного приближения через "10" или бывают "умные конверты" "в два счёта"?
Заголовок сообщения: Re: Ассемблер (ASM) для AVR в вопросах и ответах
Добавлено: Ср ноя 23, 2016 10:27:59
Собутыльник Кота
Карма: 29
Рейтинг сообщений: 651
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2708 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
Что-то я не могу создать локальную метку в макросе. И что-то не гуглится правильный синтаксис метки. (gnu preprocessing assembler ) Приму любую помощь по созданию локальных меток в макросе, лучше деньгами .
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.
А как конвертится число, лежащее в двух регистрах в 4-х значное десятичное (0000, с разложением в 4 регистра)? Тут катит только способ последовательного приближения через "10" или бывают "умные конверты" "в два счёта"?
Пока самое лучшее, что применяю. Легко адаптируется.
P.S. А что, религия запрещает пользоваться C? Или родной GCC ассемблер чем-то не устраивает при кодировании ассемблерных вставок в С?
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
Последний раз редактировалось ptr128 Ср ноя 23, 2016 11:14:15, всего редактировалось 2 раз(а).
Офф: Никогда не юзал и не понимаю. В своё время посмотрел на засилие скобок, и уже на этом косвенном основании - оценил язык как неадекватный для восприятия. Фундаменталистика чем-то интересней и для малых проектов катит.
А как же MISRA, категорически запрещающая использовать ассемблер для МК, кроме как в виде ассемблерных вставок на С?
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
1) запрещает только тот, кто в состоянии запрещать 2) MISRA возможно недопонимает, что благодаря "американскому праву", её могут обязать отписать все свои особняки - мне (и вам часть ), если во вставках на C обнаружится хоть немного "сифы" 3) были даже целые запрещающие эпохи, которые... дозапрещались!
С чего бы это? Ассемблерные вставки обрабатываются GNU AVR Assembler. С каких пор он стал оффтопиком здесь?
Серый_ писал(а):
1) запрещает только тот, кто в состоянии запрещать
В состоянии. Ни один из производителей не получит сертификат MISRA, если его исходные тексты не пройдут автоматизированный контроль надежности кода MISRA. Изначально, членами MISRA были только крупнейшие автопроизводители, сейчас это уже совсем не так. "В настоящее время стандарты MISRA используются не только в автомобильной индустрии, но также и в аэрокосмической, телекоммуникационной, разработке медицинских устройств, военных проектах, и других". Будет у Вас заказчик серьезный - потребует сертификации MISRA. И никуда Вы не денетесь.
Значит все же есть какие-то причины, почему ассемблер запрещают использовать вне ассемблерных вставок C?
_________________ Не ошибается только то, кто ничего не делает. Тот, кто признает свои ошибки, на них учится. Глупец же, упорствуя в своих заблуждениях, остается глупцом.
Офф: "Ассемблер (ASM) для AVR в вопросах и ответах" MISRA - не равно ассемблер (а значит и идёт лесом) С - не равно ассемблер
ptr128 писал(а):
Будет у Вас заказчик серьезный - потребует сертификации MISRA.
Серьёзный заказчик не потребует сертификат MISRA, только потому, что MISRA поставила ему бутыль кентуккийского виски, разлива 1865г... Иначе "серьёзность" заказчика встанет под сомнение, а к MISR-е применят антимонопольное право. (Если она и туда бутыль виски не поставит ).
ptr128 писал(а):
Значит все же есть какие-то причины, почему ассемблер запрещают использовать вне ассемблерных вставок C?
Вполне возможно, что какие-то причины есть, MISR-ены причины = MISRA их пусть и скушает.
само собой, речь идет о нормальном асме, как будет в асм. вставках в Си - Hz Неважно, что в листинге будет несколько одноименных меток - компайлер сам понимает, что речь идет именно о метке, "родной" для данного макрорасширения. Справедливо для AVR, в ассемблерах для других архитектур, к примеру, 1806ВМ2 (DEC) - несколько иначе.
В Студиях (дальше 4-й я не продвигался) есть Assembler1 и Assembler2, в обоих вышеописанное работает. Так что проблемы локальных меток для AVR не существует. А о пользе директив условной трансляции - кто же сомневается ? (хотя мне применять не приходилось, бо не нужны были )
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения