Помоги проекту - поделись книгой:
Компьютерра
24.10.2011 - 30.10.2011
Статьи
Микропроцессор Hobbit: на каком языке говорили полурослики
Сердце большинства нынешних персональных компьютеров и их старших братьев, серверных систем, кластеров и суперЭВМ, — это процессор, относящийся к типу 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.
Восьмидесятые годы прошлого столетия были настоящим Клондайком для разработчиков микропроцессоров. Твори, выдумывай, пробуй! Трудись в поте лица и не забывай скрестить пальцы «на удачу». Глядишь, баловница Судьба и подбросит тебе самородок в виде признания рынком именно твоей процессорной архитектуры.
Именно поэтому в процессорной гонке принимала участие и до мозга костей коммуникационная компания AT&T. Её исследовательский центр Bell Labs заслуженно считался кузницей гениальных идей и решений. Именно там получили путёвку в жизнь забытые ныне AT&T-процессоры.
Как и большинство компаний, AT&T начинала с четырёх и восьмиразрядных CISC-процессоров. Первым процессором, разработанным Bell Labs, был Mac-8 – восьмиразрядный процессор общего назначения, представленный 17 февраля 1977 года. В отличие от большинства конкурентов (например, Intel), использовавших для производства технологию NMOS, AT&T в содержащем всего 7500 транзисторов процессоре, MAC-8 применила более сложную для того времени, но эффективную технологию CMOS.
Процессор Mac-8 не нашёл признания на массовом рынке, но широко использовался в коммуникационном оборудовании, выпускаемом AT&T. И именно в нём проклюнулись первые ростки С-машины. Уникальной особенностью Mac-8 была возможность прямого отображения его регистров на адреса оперативной памяти и зачатки оптимизации процессорной архитектуры под особенности языка С.
Наследником Mac-8 стал процессор BellMac-32, который AT&T решила пустить в серию. Этот тридцатидвухразрядный процессор содержал сто пятьдесят тысяч транзисторов и имел в своём составе модуль управления памятью (MMU – Memory Management Unit). В модификации BellMac-32B, которая вышла на рынок под именем WE32100, впервые в истории микропроцессров на микросхему была интегрирована кэш-память на 256 команд.
И именно этот процессор послужил прототипом для создания «железной» реализации С-машины – архитектуры CRISP (C-language Redused Instruction Set Computing). Закоперщиком стал инженер Дэйв Дитцель (Dave Ditzel). Его энтузиазм помог убедить коллег в перспективности не очень популярной в то время RISC-архитектуры применительно к идеям С-машины.
В период с 1983 по 1985 группа Дитцеля разработала фотолитографические матрицы первого варианта CRISP-процессора исключительно для исследовательских целей. В 1986 году CRISP был реализован в кремнии. Среди его уникальных особенностей были функция предсказания ветвлений и способность осуществлять ветвление одновременно с исполнением другой инструкции. Как и положено RISC-процессору, прототип CRISP выполнял большинство инструкций за один такт и, конечно же, в лучших традициях С-машины содержал специальную кэш-память для стека программы.
Эксперименты с лабораторными вариантами CRISP показали, что, выигрывая в производительности, CRISP-аритектура была весьма энергоэкономичной.
Дитцель начал активно искать пути внедрения своей разработки. Первой откликнулась… компания Apple.
В 1988 году Apple, впечатлённая разрекламированными Дитцелем результатами тестирования прототипа CRISP-процессора, официально заказала AT&T партию этих микросхем. В недрах «яблочной компании» вызревал легендарный Newton — устройство, которое можно считать предшественником карманных компьютеров и даже современных планшетов. Именно в нём предполагалось использовать процессор CRISP.
Два года потребовалось команде Дэйва Дитцеля, чтобы наладить промышленное производство CRISP. Результат был назван Hobbit. Вероятнее всего, потому, что в сравнении с CISC-процессорами RISC-микросхемы казались полуросликами. К тому же Hobbit даже среди RISC-собратьев был странным С-говорящим созданием.
Полурослик содержал 413 000 транзисторов, размещённых на площади 95 квадратных миллиметров. Для его производства использовалась самая прогрессивная в то время 0,9 микронная технология. Идеология С-машины, на которой базировалась логика работы Hobbit, обеспечивала достаточно высокую производительность и беспрецедентно низкое энергопотребление.
Первая модель нового процессора официально именовалась AT&T 92010 и содержала три килобайта кэш-памяти для инструкций. В её модификации 92020, выпущенной в 1994 году, кэш был увеличен до четырёх килобайт. Вместе с процессором общего назначения AT&T выпустила и обвязку: контроллер дисплея и периферийного оборудования (клавиатура, мышь, коммуникационные порты) и контроллер карт расширения PCMCIA.
Готовый комплект был предложен Apple, которая... благополучно от него отказалась, отдав предпочтение своему новому инвестиционному проекту – молодой компании ARM. Как выяснилось позже, решение это было из числа провидческих. Инвестировав в ARM в 1990 году всего два с половиной миллиона долларов, спустя десять лет Apple заработала почти миллиард.
А что же Hobbit? Брошенным полуросликом заинтересовалась британская компания Go, которая и сделала его основой своего уникального коммуникационного планшета EO Personal Communicator. AT&T на правах создателя Hobbit даже приобрела Go Сorporation вместе с её детищем, но быстро забросила. В девяностых рынок ещё не был готов к планшетной революции.
Чуть позже Hobbit чуть было не нашёл пристанище в уникальной персоналке BeBox. Hobbit-конфигурации BeBox тестировались, но в серийное производство так и не пошли.
Создатель Hobbit Дэйв Дитцель вскоре покинул AT&T, чтобы основать собственную компанию Transmeta. К разработке его нового детища, процессора Crusoe, приложил руку главный линуксоид планеты Линус Торвальдс. Позже Дитцель стал одним из вице-президентов Intel.
Хотя Hobbit зачах на складах AT&T, заложенные в нём идеи не пропали. Архитектурные решения CRISP-процессора Hobbit были применены компанией Lucent для первых вариантов цифровых сигнальных процессоров. Развитие этого направления привело к созданию специализированного процессора CPP (Communication Protocol Processor), вариант которого имеется в подавляющем большинстве современных мобильников. Вот так странный С-говорящий Hobbit из девяностых продолжает жить в современных цифровых гаджетах.
Интервью
Валентин Макаров (РУССОФТ) о тендере на создание НПП
Недавно мы опубликовали серию интервью с руководителями российских ИТ-компаний, посвящённую проблеме создания национальной программной платформы (НПП). Картина едва ли будет полной без мнения представителей крупных отраслевых ассоциаций. О своем видении путей развития НПП корреспонденту «Компьютерры» рассказывает Валентин Макаров, президент некоммерческого партнёрства РУССОФТ.
- Удовлетворены ли вы результатами тендера «Минкомсвязи»?
- На мой взгляд, результаты тендера отражают отсутствие согласованности в деле создания и развития НПП среди разных ведомств. Они демонстрируют также несовершенство ФЗ №94 в отношении принятия решений в категории сложных многоэтапных проектов. И ещё они демонстрируют, что существует подковёрная борьба. Такое впечатление, что было бы лучше не проводить этот тендер в такие сроки и в подобной обстановке.
- Какова роль РУССОФТ в создании НПП? Вы принимали активное участие в создании «Маршрутной карты», РПП и т.д. Будете ли вы и дальше участвовать в процессе?
- Да, мы будем продолжать принимать участие в создании НПП. Пока наша активность сводилась к тому, что РУССОФТ подготовил необходимый пакет документов для участия в качестве учредителя АНО НПП, и мы много общались с Леонидом Ухлиновым, чтобы понять намерения Госкорпорации «Ростехнологии». У нас самих был большой разговор в июне 2011 года, когда после бизнес-завтрака на Экономическом Форуме в Петербурге мы собрались вместе с коллегами из АРПП в офисе «Digital Design», обсудили ситуацию с НПП и выработали общие подходы.
Они сводятся к следующему. НПП уже существует как проект. В первую очередь он будет реализован в проекте среды (платформы) для государственных проектов, на которую будут затем устанавливаться все другие пакеты, которые захотят работать с государственными программами. Поэтому отсутствие игроков рынка в процессе формирования НПП обязательно приведёт к тому, что для подключения наших программ к НПП придётся слепо выполнять все требования, которые будут кем-то заложены в НПП без учёта интересов разработчиков. Лучше участвовать в этом процессе изначально и стараться включать свои требования в этот процесс.
НПП дает шанс разработчикам ПО реализовать комплексный подход к развитию индустрии, включая постановку задач, выбор приоритетов, концентрацию усилий и средств бизнеса и государства на проведения НИОКР на этих приоритетах. То есть можно реально попробовать выполнить работу, аналогичную той, что делается в Европе.
Индустрия уже достаточно сильна, в том числе на уровне государства (и об этом говорят назначения в Комиссию по модернизации). И это понимают все участники процесса. Всем будет лучше, если представители индустрии будут реально интегрированы в процесс создания НПП и экспертизы проектов и тем самым помогут реализовать проект в целом.
- Недавно созданы ТП НПП и АНО НПП. Будет ли РУССОФТ принимать участие в работе этих организаций, и насколько необходимо их создание? Нет ли опасности, что "Концерн «Сириус» монополизирует рынок?
- Рабочая группа ТП НПП послужила сообществу, подготовив заявку в Минэкономразвития и получив положительное решение. Теперь ТП НПП останется официальным названием программы, но прекратит существование в качестве организационного субъекта. АНО НПП становится продолжателем деятельности рабочей группы ТП НПП и полностью её заменяет.
Что касается «Сириуса», то пока агрессивности, о которой вы говорите, он не проявляет. Но до сих не появилось и тендеров на другие компоненты НПП. Поживём — увидим.
- Продукты и решения, созданные в рамках НПП, должны быть свободными? Какова роль разработчиков проприетарного ПО (прежде всего Microsoft) в развитии НПП?
- Платформа, к которой должны подсоединяться приложения, должна быть свободной — так продекларировано в НПП. Стандарты, протоколы и процедуры подключения должны быть открыты. Но в отношении приложений никаких ограничений нет. Выбор приложений будет делаться пользователем, и главным критерием при выборе приложений должна быть совокупная стоимость владения ПО, учитывающая суммарные затраты пользователя на приобретение ПО, на его поддержку и развитие. В ряде областей применения решение о выборе СПО или лицензионного ПО будет приниматься с учётом политики, но с участием АНО НПП. На мой взгляд, участие Microsoft вряд ли станет главным риском проекта в целом.
- Как вы в целом оцениваете нынешнюю ситуацию НПП? Есть ли у проекта шансы на успех и что необходимо, чтобы НПП не постигла судьба некоторых других государственных инициатив в области ИТ?
- Учитывая на данный момент невысокий уровень координации работы по НПП между министерствами и уже существующий опыт работы государственных проектов, можно предположить, что у проекта впереди много рисков. Пока бизнес действует в этом проекте «вторым номером». Мы будем поддерживать предпринимаемые «Сириусом» шаги. Если они будут давать хотя бы небольшой результат, надеюсь, что бизнес будет действовать более активно.
Терралаб
Обзор NAS Buffalo Link Station Pro Duo 2 ТВ
Поделиться книгой: