fl
"РЛ" - Н АЧИ Н АЮ Щ И М
о-
Продолжение. Начало в N21-6/2007
Глава 14. Еще об ассемблере
Продолжим разговор об ассемблере.
Несколько слов о стиле программирования. В од-
ной из предыдущих глав я этого вопроса вскользь ка-
сался, но важность этой проблемы требует от меня уде-
лить ей больше внимания. Я не раз встречал горе-про-
граммистов, которые действуют по принципу “лишь бы
работало”. Проявляется этот принцип в том, что офор-
мление своих программ они делают крайне небрежно,
комментарии либо вообще не пишут, либо пишут не-
что маловразумительное, понятное только им и только
в данный момент. Кроме того, в качестве меток тоже
используют по одной-две буквы, не используют сим-
вольные обозначения констант и т.п. Делается это, по
их объяснению, ради экономии времени. Но в резуль-
тате через месяц-два разобраться в их программе не
под силу даже им самим.
. Я настоятельно советую не
брать на вооружение такой подход. Даже если по ва-
шему мнению решаемая задача не стоит того, чтобы
стараться (а такое вполне возможно), все-таки жела-
тельно оформлять свою программу тщательно и акку-
ратно. В моей практике часто бывало, когда пустяко-
вая программка спустя пару месяцев оказывалась край-
не необходимой, и тут я был очень рад, когда мог легко
вспомнить ее алгоритмы благодаря подробным коммен-
тариям и прочим “затратам времени”.
Так как же лучше всего оформлять свои програм-
мы? Во-первых, рекомендую в самых первых строках
в комментариях указывать дату разработки, название
проекта, перечень сопутствующих файлов (например,
схем и т.п.) и другую важную для разрабатываемого
устройства информацию. Очень неплохо, когда ука-
зывается кратко суть или алгоритм работы устройства.
Вогвторых, рекомендую разделять смысловые участ-
ки программы комментариями из целых строк одина-
ковых символов, например звездочек, минусов и Т.п.
В-третьих, о чем я уже говорил, использовать коммен-
тарии как можно чаще и как можно более подробные.
Для экономии времени лучше использовать понятные
сокращения^ нежели пренебрегать комментариями.
Этими рекомендациями не исчерпывается список
принципов хорошего стиля программирования, но для
начала и этих достаточно, а к остальным мы подой-
дем чуть позже, прямо в этой главе, возможно, неко-
торые из них окажутся вам уже знакомыми по преды-
дущим главам.
А теперь поговорим о новых директивах ассембле-
ра, без которых не получится сделать свою программу
“стильной” ©. Я не стану знакомить вас со всеми ди-
рективами, т.к. их много в стандарте ассемблера, но
далеко не все из них остаются актуальными в настоящее
время, да и не все реально могут вам потребоваться.
Роман Абраш
г. Новочеркасск
E-mail:
Например, лет десять назад актуальными были специ-
альные директивы, оформляющие текст программы при
печати, но сегодня распечатывать собственную програм-
му для поиска ошибок в ней вряд ли кому придет в голо-
ву, особенно если пользоваться интегрированной средой
MCStudio или аналогичной.
Перед знакомством с директивами договоримся об ус-
ловных обозначениях. Условимся обозначать в треуголь-
ных скобках параметры, которые должны быть обязатель-
но, а в квадратных - те, которые могут и отсутствовать.
Сами параметры я буду приводить в виде смыслового сло-
весного описания. Символы без скобок- это как раз обя-
зательная неизменная часть директивы. Напомню, что
регистр символов не имеет значения, я буду приводить
директивы в верхнем регистре исключительно для выде-
ления их из общего текста.
Директива EQU. Ее мнемоника образована от слова
“эквивалент”, и по своей сути эта директива равнознач-
на знаку равенства. Используется эта директива для при-
своения константам символьных обозначений. Формат
директивы следующий:
<Имя константы>
EQU
<Выражение>
Как видите, очень похоже на обычную команду с мет-
кой, но обратите внимание на отсутствие двоеточия пос-
ле первого параметра - это важно! Эта директива никак
не отражается на памяти программы, т.е. используется
исключительно компилятором при обработке остальной
части программы. Для чего эта директива может быть
нужна? Простой пример. Так как все временные интер-
валы, формируемые в программе, зависят от частоты
кварцевого резонатора, то при разработке своей програм-
мы вы так или иначе часто будете использовать какие-то
константы, прямо связанные с частотой примененного
кварца. Конечно, можно просто эту константу вписывать
в нужных командах программы напрямую в виде числа,
но делать этого не надо. Правильнее будет присвоить этой
константе символьное имя, и использовать его в своей
программе вместо конкретного числа
(таблица 11).
Не смотря на то, что директиву EQU можно разме-
щать в любом месте программы, рекомендуется собрать
их все в самом начале. Дело в том, что использование
символьных имен вместо констант позволяет мгновен-
но внести изменения в работу программы путем изме-
нения единственной директивы EQU. Если вам захочет-
ся использовать свою программу с другим кварцевым
резонатором, чем тот, для которого программа написа-
на, вы измените соответствующее число только в одной
строке с директивой EQU, а не в неизвестно скольких
строках, если бы директива не использовалась.
Таблица 11
Нежелательно
Рекомендуется
MOV
R1, #126
CONST
EQU
126
MOV
R1, «CONST
40
У Радиолюбитель - 0 7 /2 0 0 7
предыдущая страница 40 Радиолюбитель 2007-07 читать онлайн следующая страница 42 Радиолюбитель 2007-07 читать онлайн Домой Выключить/включить текст