Коллектив Авторов - Цифровой журнал «Компьютерра» № 92

Опубликовано 24 октября 2011 года

Сердце большинства нынешних персональных компьютеров и их старших братьев, серверных систем, кластеров и суперЭВМ, — это процессор, относящийся к типу CISC (Complex Instruction Set Computing). Апологеты CISC'остроения отлично известны — это компании Intel и AMD, «заклятые друзья», ведущие бесконечный бой за потребителя.

Мобильные гаджеты — совсем другое дело. Почти в каждый из них «имплантирован» процессор типа RISC (Redused Instruction Set Computing) с сокращённым набором команд. Чаще всего такие процессоры базируются на архитектуре, разработанной компанией ARM и лицензируемой великим множеством производителей.

Считается, что CISC-процессоры весьма производительны, но при этом далеко не идеальны в плане энергопотребления и рассеиваемой кристаллом мощности. Их конкуренты с архитектурой RISC пусть и послабее в вычислительном плане, но зато куда умереннее тратят заряд батареи и способны трудиться без лишних охлаждающих «примочек».

Сейчас кажется, что подобная расстановка сил на процессорных фронтах была от начала времён. Однако это ложное представление. На самом деле семидесятые и восьмидесятые годы прошлого столетия были настоящей фабрикой процессорной эволюции, где за место под солнцем воевали различные, и порой весьма причудливые, архитектуры. Многие из них канули в Лету, другие же нашли продолжение в новых разработках.

Эта история об одном из таких процессорных «чебурашек» — уникальном во многих отношениях процессоре по имени Hobbit, который был рождён... нет, не в Средиземье, а в исследовательской лаборатории Bell Labs компании AT&T.

Восьмого октября сего года ушёл из жизни Деннис Ритчи – человек, которого весь мир знал как создателя языка программирования С и соавтора операционной системы Unix.

Вклад, который внёс этот компьютерный гений в облик нынешнего мира цифровых вычислений, трудно переоценить. Язык С, выросший из исследовательских проектов Ритчи, сегодня используется в качестве инструмента для создания кода ядер большинства операционных систем, а его синтаксические и семантические отголоски в той или иной степени присутствуют во многих языках программирования.

Появление же произвело настоящую революцию в программистских умах, сделав возможным написание программ с помощью весьма простых и элегантных правил процедурного программирования, совмещенных со свежепредложенной Эдсгером Дейкстрой структурной методологией создания программ.

Конечно, программисты были влюблены в этот инструмент создания программ, представленный С и его последователями. А вот с исполнением полученного кода на конкретном «железе» всё было далеко не так гладко. Перефразируя поэта, можно сказать: «Любовная лодка эффективности языка программирования разбилась о быт процессорных архитектур». В чём же крылась причина этого кораблекрушения?

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

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

Беда же заключается в том, что языки программирования высокого уровня, подобные С (ассемблеры, вплотную приближенные к архитектуре процессора, не в счёт), создавая программу, используют совершенно другую методологию. Они размещают необходимые программе локальные переменные и иные структуры, необходимые для выполнения основной ветви программы и вызываемых из неё процедур, в области памяти, называемой «стек». Стек устроен по принципу оружейного магазина и на своей вершине содержит наиболее актуальные в данный момент данные.

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

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

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

Именно об этой нестыковке и задумался коллектив исследователей (в его состав входил и Деннис Ритчи, и другие сотрудники Bell Labs), разрабатывая С-машину – гипотетическую безрегистровую процессорную архитектуру, оптимизированную для выполнения С-программ со множеством процедур и стековой организацией хранения данных.

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

Согласно идеологии С-машины, инструкции программы получали доступ к необходимым им данным так, как это задумывалось компилятором языка С, то есть непосредственно обращаясь к находящимся в памяти стекам программы и её процедур и, например, таким элементам, как массивы. Такое неэффективное с точки зрения скорости доступа решение на практике оказывалось более продуктивным, чем постоянное перезаписывание более шустрых регистров.

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

Проект С-машины стал активно развиваться в начале восьмидесятых годов прошлого столетия. Возможно, он так и остался бы эдакой игрой разума, если бы не «железные» амбиции компании AT&T, в недрах которой появился язык С и операционная система Unix.

Восьмидесятые годы прошлого столетия были настоящим Клондайком для разработчиков микропроцессоров. Твори, выдумывай, пробуй! Трудись в поте лица и не забывай скрестить пальцы «на удачу». Глядишь, баловница Судьба и подбросит тебе самородок в виде признания рынком именно твоей процессорной архитектуры.