Редкая профессия - [18]

Confidential

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

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

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

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

Был краткий период моральной усталости от отладочной гонки, которая выглядела бесконечной (последние пять процентов ошибочных тестов поддавались с невероятным трудом и требовали все новых правок). Мы задумались о будущем и начали прикидывать, как могла бы выглядеть совсем новая версия компилятора. Мы начали интенсивно искать в Интернете все, что так или иначе касалось компиляции, генерации кода и языка Си++. Как ни странно, больше всего информации оказалось о методах генерации. И вот в один прекрасный день Саша натолкнулся на работу Джонсона[3] о реализации одного из первых компиляторов Си — проекте Portable C, относящегося к концу 70-х годов. Это была статья в каком-то древнем формате с подробным описанием проектных решений и описывающая, в частности, подход к генерации кода. Мы не глядя распечатали ее и ахнули: в ней были расписаны основные коды бельгийского внутреннего представления, который мы помнили наизусть! Два дня ушло на лихорадочный поиск и запросы во все стороны, где можно найти исходники Portable C. Нашлись, родимые, рядышком, у какого-то коллекционера в Финляндии! И что же? Похожие названия команд, те же кодировки и почти те же самые заголовочные файлы, что и у бельгийцев!

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

Не будем гадать о том, почему фирма взяла за основу своего промежуточного представления формат Джонсона. Для своего времени это было естественное и, наверное, правильное решение, и, конечно, их нельзя упрекнуть в некорректности — статья известна всем, она до сих пор входит в комплект документации по "Seventh Edition release of the UNIX operating system" компании Bell Telephone Laboratories, а исходные тексты Portable C общедоступны.

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