Библиотека программиста

Все, что необходимо начинающему и опытному программисту

Ассемблер крайне просто изучить. Фирменное описание ассемблера для AVR занимает несколько страничек (сравните с фолиантами для изучения С), и его можно скачать с сайта Atmel. Но вообще говоря, его даже не нужно особенно изучать — основные правила нотации мы изложим далее, и они очень быстро постигаются на практике. А вот Особенности использования конкретных команд можно изучать долго (любой программист обязательно имеет под рукой справочник по командам), но к ассемблеру, как таковому, они не имеют отношения, в большинстве случаев эти нюансы точно так же необходимо знать и учитывать при программировании на С.

Как писал классик программирования Дональд Кнут, "каждый, кто всерьез интересуется компьютерами, должен рано или поздно изучить по крайней мере один машинный язык". Ассемблер — это первично, а все остальное вторично. Но ассемблер обладает одним большим недостатком: программы на его основе получаются довольно громоздкими и неудобочитаемыми. Это вызвано тем, что здесь любую операцию приходится разлагать на составляющие. Особенно это характерно для RISC-архитектур (к которым относится и AVR) — например, в системе команд AVR нет даже операции деления (да и операция умножения работает не во всех моделях).

Но в общем случае и наличие расширенного набора команд (CISC-архитектура) не очень помогает. Для примера рассмотрим типовую задачу, реализуемую на языке Pascal в одну строку:
if (var_x>const_l) then begin var_x:=0; prl end else pr2;
(где prl и pr2 — наименования неких процедур, которые выполняются в зависимости от результата сравнения переменной var_x с константой const 1, причем во втором случае переменную еще нужно дополнительно обнулить). А листинг 5.1 иллюстрирует, как то же самое может выглядеть на ассемблере для процессоров л;86 фирмы Intel.

cmp var_x,const_l /сравниваем
ja metkal /если больше, то на метку 1
call рг_2 /иначе вызываем процедуру 2
jrap metka2 /после нее на продолжение
metkal: хог ах,ах /обнуляем регистр ах
raov var_x,ax /переменная = 0
call рг_1 /вызываем процедуру 1
metka2: <продолжение основной программы>

Никакой речи о том, чтобы следовать знаменитому лозунгу Дейкстры "программирование без goto", тут идти не может, т. к. ассемблерная программа, если можно так выразиться, состоит из сплошных "goto" — "лапши", по словам Дейкстры, условных и безусловных переходов (он намекал на многочисленные линии ветвления, которые возникают в блок-схемах таких программ). Таким образом, для работы на ассемблере требуется учить реализацию всех типовых приемов программирования, таких как различные циклы с условными и безусловными переходами, математические операции, самостоятельно организовывать деление на локальные и глобальные переменные и т. п. Это и служит основным аргументом в пользу языков высокого уровня, где подобные вещи в большинстве случаев уже сделаны за вас.

Заметки на полях
"Обычные" программисты, как огня, боятся замкнутых циклов, условие выхода из которых может не выполниться хотя бы теоретически. Бесконечное ожидание прихода символа с клавиатуры или из СОМ-порта, в котором не предусмотрено никаких альтернативных средств выхода из цикла, повесит не только саму программу, но и всю систему, если речь идет об однозадачной DOS или "кооперативной многозадачности" Windows 3.x, может доставить немало неприятностей в "компромиссных" Windows 9х, и даже в настоящих многозадачных ОС, по крайней мере, заставит обрывать работу программы принудительно. Потому в таких задачах программисты "на уровне подкорки" приучены применять средства, позволяющие выйти из такого цикла альтернативными методами: по таймеру, или какими-то пользовательскими действиями (нажатием клавиши или кнопки Cancel). Вся очередь задач в Windows, по сути, есть одно из таких решений, встроенное в систему изначально, и направленное на то, чтобы не позволить приложению зациклиться в ожидании какого-то события.

В программировании для МК подход иной. И в фирменных ".аппнотах", и в примерах в тексте технических описаний контроллеров вы запросто можете встретить бесконечный цикл ожидания очистки какого-нибудь бита, и в теории, если этот бит никогда не очистится, МК так и "повиснет". ПК-программист от такой ситуации пришел бы в ужас. Конечно, есть средства вывести контроллер из этого состояния: наиболее кардинальным будет использование сторожевого таймера, который в конце концов перезапустит систему. Более грамотно было бы заставить контроллер ожидать не самой по себе очистки бита, а связанного с этим прерывания (что позволит выполнять остальные функции без задержек), но далеко не всегда это возможно: например, запись байта во встроенную EEPROM заставляет МК "висеть" несколько миллисекунд, пока этот процесс не закончится, но соответствующее прерывание в ряде моделей просто отсутствует, а если даже имеется, то задействовать на практике его неудобно из-за значительного усложнения логики построения программы.

Однако если вдуматься, стоит задать себе вопрос: а так ли это страшно в случае контроллеров? Если по ходу дела требуется записать что-то в EEPROM, а она оказывается неисправной, то, очевидно, функциональность системы и так окажется нарушенной, и тут уже выходом из "зависания" делу не поможешь. В критичных случаях, разумеется, системы подвергают резервированию с возможностью автоматического переключения между запасными модулями, но для обычных бытовых устройств принятие подобных мер только безосновательно удорожает изделие. Но если вы будете бояться подобных ситуаций, то это только хорошо: понимание, что вы делаете что-то не совсем так, как "надо бы", еще никому не мешало.

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru