Евгений Зуев - Редкая профессия

* некоторые базовые алгоритмы были заметно улучшены в плане эффективности; компилятор заработал быстрее.

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

Но ведь мы не можем распространять от себя то, что формально нам не принадлежит! Следовательно, нужно сделать компилятор нашим . Из того, что рассказано выше, можно понять, что у нас давно чесались руки многое переделать. Теперь для этого возникли все условия. Часть пути уже пройдена, следует определить последующие шаги в этом направлении. Несколько дней мы провели в подробных обсуждениях. Мы не специалисты в юридических аспектах, относящихся к проблемам собственности, но нам было понятно, что изменения в компиляторе должны, с одной стороны, затрагивать если не все, то большинство его основных алгоритмов, и с другой — "внешний вид" программного текста также должен быть сильно модифицирован. Функциональность программы, естественно, останется (все компиляторы, по большому счету, делают одно и то же), но ее внутренности должны в значительной степени измениться. Это должен был быть новый компилятор.

Читатель простит некоторую сдержанность при описании этих аспектов работы. Скажу только, что в новой версии мы умудрились изменить даже стиль программирования, не говоря уже о более простых вещах. Что же касается переработки алгоритмов, то, помимо уже описанных выше изменений, мы оптимизировали формальное описание синтаксиса входного языка, сделав разбор выражений примерно на 20-25% быстрее, доработали механизм шаблонов, включив в него массу нововведений, появившихся за последнее время, реализовали новую схему работы с именами (см. главку "Как отремонтировать подгнивший дом") и усовершенствовали как компиляцию исключений, так и алгоритмы времени выполнения, связанные с обработкой исключительных ситуаций. Сделано еще много заметных изменений, и эта работа продолжается.

Мы перенесли компилятор на персоналки и заставили его работать в среде Windows’95 (правда, без формирования объектного кода — генератора для платформы Intel у нас пока нет).

Наконец, мы решили проблему с форматом промежуточного представления, которое порождает компилятор. Это очень интересная история. Читайте дальше.

Наша система — не традиционный компилятор, порождающий объектный код, а так называемый компилятор переднего плана(front-end compiler), который в качестве результата своей работы формирует образ исходной программы на некотором промежуточном языке. Далее этот образ обрабатывается отдельной компонентой — генератором кода (back-end). Это обычная схема, давно принятая в многоязыковых системах программирования. Так как промежуточное представление выбирается единым для всех входных языков, то в системе достаточно единственного генератора кода, что исключает затраты на реализацию генератора для каждого отдельного компилятора. Кроме того, можно разработать несколько генераторов кода с единого внутреннего представления для различных аппаратных платформ, получив тем самым многоплатформную систему программирования. По этой схеме организована система gcc, похожим образом устроены и продукты семейства TopSpeed и десятки других.

Промежуточное представление, которое использовали бельгийцы в своих компиляторах (это, по существу, специальный язык, который можно назвать обобщенным ассемблером), было разработано довольно давно, выглядело несколько архаично, но для него было сделано несколько работающих генераторов для платформ Intel, Motorola, Sparc и менее известных процессоров. Спарковский генератор они и передали нам для использования совместно с создаваемым компилятором, специально оговорив недопустимость его копирования. На документации по промежуточному языку красовались жирные штампы "Confidential". Это вызывало уважение и некоторый трепет. Перед нами как бы приоткрыли дверь в святая святых компании — поделились своим ноу-хау.

Когда произошло все то, о чем было написано выше, и мы начали интенсивно переделывать и дорабатывать компилятор, стремясь сделать его полностью "нашим", перед нами, словно чугунный рельс,-- ни обойти, ни сдвинуть — все время стояло это безальтернативное, как хлопок двери, слово,-- "Confidential". В самом деле, пусть мы переписали компилятор, пусть его исходный текст сильно изменился, но он, тем не менее, порождает код, формат которого является чужой собственностью,-- как мы можем считать такой компилятор своим? Придумать собственное промежуточное представление или адаптировать, например, внутренний код gcc — он, как и весь проект GNU, имеет статус freeware — конечно, можно, но сколько времени это займет? А соответствующая переделка компилятора сравнима с созданием нового.

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

Был краткий период моральной усталости от отладочной гонки, которая выглядела бесконечной (последние пять процентов ошибочных тестов поддавались с невероятным трудом и требовали все новых правок). Мы задумались о будущем и начали прикидывать, как могла бы выглядеть совсем новая версия компилятора. Мы начали интенсивно искать в Интернете все, что так или иначе касалось компиляции, генерации кода и языка Си++. Как ни странно, больше всего информации оказалось о методах генерации. И вот в один прекрасный день Саша натолкнулся на работу Джонсона [3] C.S.Johnson. A Tour Through the Portable C Compiler. http://plan9.bell-labs.com/7thEdMan/vol2/porttour.bun. о реализации одного из первых компиляторов Си — проекте Portable C, относящегося к концу 70-х годов. Это была статья в каком-то древнем формате с подробным описанием проектных решений и описывающая, в частности, подход к генерации кода. Мы не глядя распечатали ее и ахнули: в ней были расписаны основные коды бельгийского внутреннего представления, который мы помнили наизусть! Два дня ушло на лихорадочный поиск и запросы во все стороны, где можно найти исходники Portable C. Нашлись, родимые, рядышком, у какого-то коллекционера в Финляндии! И что же? Похожие названия команд, те же кодировки и почти те же самые заголовочные файлы, что и у бельгийцев!

Теперь мы поняли причины неуверенности в ответах на вопросы об особенностях промежуточного представления — это был не их формат. Многие детали так и остались тогда непроясненными. В начале работы нам приходилось познавать промежуточное представление, по существу, полностью самостоятельно, если угодно, используя "проекционный подход" В.Ш.Кауфмана: мы написали больше сотни тестов на Си, пропускали их через фирменный компилятор Си и изучали порождаемый промежуточный код, сравнивая "проекцию" с оригиналом — исходным текстом.