Страница 42 из 46
В 1995 году два норвежских студента из г. Тронхейма, Альф Боген и Вегард Воллен, выдвинули идею 8-разрядного RISC-ядра, которую предложили руководству Atmel. Ядро это, названное AVR по именам разработчиков (Alf - Vergard - RISC), было разработано без оглядок на существовавшие решения, и вполне заслуживает название революционного. В AVR-ядре типовые инструкции выполняются за один такт, причем в обеспечение этого имеется элементарный конвейер с одновременным выполнением инструкции и выборкой следующей (потому команды ветвления выполняются за два такта - конвейер "тупо" полагает, что условие ветвления не выполнится). Первоначальное ядро состояло всего из 32 тысяч транзисторов.
В работе над ядром приняла участие упоминавшаяся фирма IAR System, разработчик С-компиляторов. Возможно, поэтому главной особенностью AVR стал решительный разрыв с характерными для существовавших ранее архитектур с инструкциями, выполнявшимися через специальный регистр-аккумулятор: большинство команд здесь может непосредственно оперировать с регистрами общего назначения (которых имеется аж 32 штуки), в ряде случаев вообще не нуждаясь в обращении к ОЗУ. Потому структура ассемблерных программ для AVR стала подозрительно напоминать программы на языке высокого уровня, где операторы работают не с ячейками памяти и регистрами, а с абстрактными переменными и константами. Мало того, в ряде младших моделей нельзя даже напрямую работать со стеком - для программы он при таком количестве регистров-переменных оказывается попросту ненужным, и используется лишь аппаратно при вызове подпрограмм.
Сделать шажок к переходу от ассемблера на С при такой архитектуре значительно проще: фактически оставалось лишь упаковать то, что знаменитый программист Дейкстра назвал "лапшой условных и безусловных переходов", в привычные циклы с предусловием/постусловием или операторы выбора. Именно по этим причинам архитектура AVR считается наиболее приспособленной к программированию на С.
Причем различные способы адресации, имеющие такое важное значение в архитектуре х51, здесь разбросаны по совершенно разным командам, и программист вообще может не изучать соответствующий раздел инструкции. Количество команд в архитектуре AVR довольно большое, 120-130 штук, но противоречия с RISC-концепцией здесь нет - 30-40% команд есть лишь псевдонимы, введенные для удобства программиста. Причем инструкций деления и умножения, в полном соответствии с RISC-концепцией, канонический AVR не предусматривает: лишь позднее для более "продвинутых" моделей появилась возможность аппаратного умножения.
Другим большим плюсом AVR стал впервые введенный последовательный интерфейс занесения программы в память кристалла, благодаря чему МК стало можно программировать прямо в готовой схеме, без каких-либо специальных программаторов: в принципе достаточно чисто софтверного решения на ПК, соединяющегося через LPT со схемой пятью проводочками. Не стоит и говорить, что из-за подобной фичи AVR снискали себе горячую любовь отечественных (и не только) радиолюбителей. Позднее таким интерфейсом были вынуждены обзавестись и другие популярные семейства МК.
К недостаткам AVR можно отчасти отнести то, что электрически выводы портов по уровням сигналов являются КМОП-совместимыми: это повышает помехоустойчивость (порог различения низкого-высокого уровня лежит в районе середины питания, а не ближе к нулю, как у х51), но вызывает ряд проблем (вполне, впрочем, решаемых) совместимости с различными стандартными интерфейсами. Не очень логично и построение некоторых команд в области операций с битами. Но в целом архитектура AVR, несомненно, более прогрессивна и если бы в этой отрасли моды менялись так же быстро, как это происходит в области ПК, то AVR имела бы все шансы на первенство.
По счастью, отрасль производства МК гораздо более консервативна: в рекламе стиральной машины не запишешь, что она построен на "новейшем 32-разрядном чипе", и никого по большому счету не волнует, какую архитектуру предпочитает разработчик данного бытового устройства. Потому у инженера оказывается значительно больше свободы применять то, что ему привычно и нравится, и меньше зависимости от рекламных веяний и монополизма производителей платформ. В области МК исключена ситуация, когда кто-то впаривает недоработанный и неудобный стандарт, пользуясь своим положением на рынке: разработчики просто пожмут плечами и отвернутся к другому производителю, или будут продолжать применять то, что применяли издавна. И это несомненный плюс отрасли, который в конечном итоге играет на руку потребителям, удешевляя и упрощая конечные устройства.
Это вопрос в отношении программирования МК имеет совершенно иной оттенок, нежели идиотские споры "писишников" 1980-х годов (сейчас, правда, давно забытые). Культура программирования МК и ПК различается, как небо и земля. Инженер, работающий с МК, всегда в большей степени электронщик, чем программист: для него программа не самоцель, а средство заставить систему работать. В программах для МК, например, вполне допустимо то, что в случае однозадачной DOS запросто повесит весь компьютер и для "писишников" служит признаком профнепригодности: ожидание события в бесконечном цикле без возможности его прервать. Между тем в системах на МК сам факт, что событие не состоялось, нередко означает неисправность всего устройства, и в таком случае бывает совершенно безразлично, зациклится программа или нет.
Подобные особенности программирования МК делают, в общем, не слишком актуальным вопрос о том, как программист добивается своих целей. Правда, память программ в МК исчисляется килобайтами, а скорость работы их не очень-то велика, и потому тут на первый план нередко выходят соображения компактности кода или скорости выполнения процедур: нередко специально составляются библиотеки подпрограмм, оптимизированные либо по количеству команд, либо по времени выполнения - смотря, что важнее. В общем случае, разумеется, программы, написанные на С, дают менее компактный код (даже для AVR, система команд которой специально оптимизирована для программирования на С), и это стоит учитывать.