Rus Eng
О компании  
Новости компании
Лицензии и сертификаты
Вакансии
Контакты
Публикации
White Paper
Продукты
Технологии
Разработчикам ПО
Производителям микроконтроллеров
Партнеры / Клиенты
Перспективные проекты
| | | |
Главная страница    О компании    Публикации    White Paper
White Paper

Языки программирования, компиляторы, языковые процессоры:
подход компании Интерстрон

4. Эволюция архитектуры компиляции

Традиционная архитектура компиляторов, сложившаяся исторически и описанная в многочисленных источниках, включает набор последовательных преобразований исходного текста программы; конечный результат этих преобразований - последовательность команд некоторого процессора ("исполняемая программа"), реализующая семантику исходной программы на ЯП. Компилятор в целом рассматривается как монолитная программа, устроенная по принципу "черного ящика"; взаимодействие компилятора с окружением сводится к заданию на входе параметров компиляции и текстов с исходной программой и получению на выходе результатов его работы (рис.1).


Рис.1 Традиционная архитектура компиляции

Заметим, что структуры данных, формируемые компилятором в процессе работы (дерево программы, таблицы имен, типов и т.д.), здесь рассматриваются как сугубо внутренняя информация, необходимость в которой исчезает непосредственно после формирования результата компиляции.

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

Справедливости ради, следует отметить, что описанная проблема была осознана достаточно давно; уже в 70-х годах были предожены продвинутые варианты архитектур компиляции, сводящиеся к разделению языко- и пратформенно-независимых компонент компилятора и введению промежуточного представления исходной программы, которое служит интерфейсом между компонентами (рис. 2).


Рис.2 Архитектура компиляции с несколькими целевыми процессорами

Возможно, наиболее известной многоязыковой переносимой архитектурой является система gcc (GNU Compiler Collection), разработанной под эгидой консорциума FSF.

Можно утверждать, что подобная архитектура (которая к настоящему времени уже стала, в свою очередь, классической) вполне практична для целей создания многоязыковых систем программирования для большого спектра аппаратных платформ. Успех gcc позволяет сделать вывод о существенном сокращении затрат в рамках этой архитектуры: добавление компилятора переднего плана для некоторого нового языка автоматически приводит к появлению компиляторов с этого языка для всех аппаратных платформ, поддерживамых архитектурой. Аналогично, включение в систему генератора кода для новой платформы, по существу, означает добавление целого семейства компиляторов со всех имеющихся в системе входных языков для этой новой платформы.

Описанная архитектура получила широкое распространение, а концепция выделения в компиляторе языко-ориентированных и платформенно-ориентированных частей стала повсеместной. Как следствие, особое внимание исследователей и разработчиков было обращено на центральный элемент архитектуры - промежуточное представление (ПП). За последние годы было предложено большое число различных подходов к построению ПП - от низкоуровневых списковых структур, описывающих обобщенные команды типовых процессоров, до реализации ПП в виде реляционной базы данных. Заметим, что появившиеся в последнее время архитектуры Java byte code и Microsoft Intermediate Language (MSIL) платформы .NET также (с некоторыми оговорками) могут быть отнесены к ПП.

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

- Низкий уровень и бедная структура большинства ПП, отсутствие в них существенной информации об исходной программе (прежде всего, семантической информации) и, как следствие

- Поддержка, по существу, единственной задачи - генерации объектного кода.

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

Следующий раздел содержит краткой анализ этих недостатков и описание нашего подхода к концепции ПП.



< пред.                                                                 след. >


ЗАО "Интерстрон" 1998-08.06.2015, ООО "Интерстрон" 09.06.2015 по н.в. Все права защищены.
Москва, Дмитровское шоссе, 1/1
e-mail: interstron-info@mail.ru
web: www.interstron.ru
Тел.: +7 (495) 769-55-68