Как стать автором
Обновить

Комментарии 12

НЛО прилетело и опубликовало эту надпись здесь
Отход от практики в асме: 1 мнемоника — 1 команда скрывает ситуацию когда прерывание может вклиниваться между командами и нарушать атомарность операции. Этот подход сильно маскирует такие ситуации. Хотя красиво, и почти всегда не критично, но ИМХО ассемблер обязан такие ситуации отражать явно.
В принципе согласен, но из всех неприятностей эта так же вероятна, как смерть от кирпича с крыши.
Хуже другое: отладчик и дизассемблер этого не понимают и показывают истинные команды))
Но это беда всех макрорасширений — в конечном коде можно заблудиться при отладке.
В том то и дело, что в исходнике видно что это макрос и он может скрывать какие-то архитектурные особенности. А вот если это скрыть мнемоникой, и это чья-то библиотека, а вы не причитали аппендикс или еррату на процессор…
Прерывание должно отрабатывать чисто, незаметно для текущего процесса. Ну, в идеале ;)
Да как то не очень получается, если оно контекст переключает или в нем читается ECX. Но кажется что MOV ECX, 10 атомарна. И это еще простой случай.
Бывают такие команды процессора, которые состоят из нескольких шагов, и между шагами тоже может вклиниться прерывание. Например, это команды блочной пересылки и поиска.

Во всех случаях программист должен хорошо знать систему команд процессора, на котором работает. Но если он её знает — то ему не составит труда увидеть, что некоторой команды, которая стоит в программе, в системе команд процессора нет, и учесть последствия.

Код, правильность исполнения которого зависит от количества стоящих в нём машинных команд, даже при программировании на чистом ассемблере встречается довольно редко. А критичные участки, такие, как переключение контекста задач, примитивы синхронизации и т.д. всё равно вылизываются вручную с очень пристальным вниманием, и там обычно не применяются незнакомые макросы.

Когда программировал на ассемблере Z80, я часто с помощью макросов создавал для себя дополнительные, часто встречающийся, «команды процессора». Никаких проблем не было.
Ерунда! Есть высокоуровневый ассемблер, а есть низкоуровневый. Отлаживает в отладчике как раз низкоуровневый. Никогда в этом не видел проблему. Да и причём тут прерывания? Непонятно. Я сейчас только высокоуровневый стиль использую.
А понял! Это вы про микроконтроллеры, а я про компы общего назначения!
Надо ещё добавить возможность операторы :=, +=, -=, *= и другие, во время работы парсера переделываются в соответствующие макросы, например eax:=edx. Макрос assign получает соответствующие параметры, может определить тип и другие параметры, например имя класса указателя, и создаст код mov eax,edx.
Я тут говорю именно про высокоуровневый ассемблер, промежуточный между С/С++ и низким ассемблером.
Давно не занимался, но замена MOV ECX,10 на PUSH 10 и POP ECX по моим воспоминаниям приведёт к увеличению времени выполнения (как минимум вдвое). Почему бы тогда не что-то типа xor ECX,ECX move CL,10 (нет стека — нет цикла записи в память)?
Так понимаю, это чтобы исходники на ассемблере с одного процессора на другой таскать.
Нет какой-то команды — эмулируем. С 80186 на 8086, например.
Нужно быстро с AVR на PIC перетащить — пишем набор макросов, фигак-фигак и старый исходник с минимальными правками — в продакшн.

Да и кто из нас не грешил заменой экзотических мнемоник команд на привычные?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории