Parrot, или Почему мы долго ожидаем Perl 6

Как известно, впервые Perl был представлен на суд общественности Ларри Уоллом (Larry Wall) еще в конце 1987 г. В последующие несколько лет язык бурно развивался, одна за другой выходили новые версии, и уже в 1994 г. программисты работали с Perl 5. Однако с тех пор прошло тринадцать лет, и хотя за это время появлялись очередные релизы, номер текущей версии по-прежнему начинается с пятерки. Значит ли это, что Perl идеален? Спору нет, он очень хорош, но и предела совершенствованию, как известно, нет. А одна из причин задержки шестой версии состоит в том, что в ней ожидается поистине революционное новшество – переход на новую систему промежуточного представления кода.

Бытует мнение, что интерпретация Perl-программ осуществляется на уровне исходного текста. Это не так. Подобно Java, исходный код Perl сначала преобразуется в промежуточное представление, или байтовый код, который затем обрабатывается интерпретатором. Такой же подход использован в Python, Tcl и многих других интерпретируемых языках. Но если технология подготовки и выполнения Java-программ извест-на практически всем, то в случае с Perl порой остаются в неведении даже опытные специалисты. Подобное заблуждение вполне объяснимо. Компилятор Perl, генерирующий байтовый код, и виртуальная машина, предназначенная для его обработки, объединены в общем файле, да и промежуточные результаты компиляции до недавнего времени не были доступны пользователям. Лишь начиная с релиза 5.6.1 в порядке эксперимента в состав Perl был добавлен модуль B::Bytecode, который позволяет сохранить байтовый код в отдельном файле и выполнить его позже, возможно, даже на другой машине. В Perl 6 модель подготовки программ должна коренным образом измениться: предполагается разделить процесс компиляции и интерпретации – компилятор будет генерировать байтовый код на специальном языке под названием Parrot, а затем исполнять его на соответствующей виртуальной машине.

Чем же плоха виртуальная машина PVM (Perl Virtual Machine), применяемая в настоящее время? На самом деле претензий к ней немало. Во-первых, спецификация PVM как таковая фактически отсутствует. Тем, кто хочет разобраться в деталях ее функционирования, приходится обращаться к исходному коду, благо он доступен всем желающим. Во-вторых, в PVM слишком много операций. Практически для каждого выражения Perl существует своя инструкция в байтовом коде. Если учесть встроенные функции Perl, то мы насчитаем 346 операций – невероятно много для виртуальной машины. В-третьих, типы данных в PVM неоправданно сложны. Все эти особенности вместе открывают простор для деятельности хакеров, ведь чем сложнее код, тем больше вероятность найти в нем «брешь», которую можно использовать для организации атаки. Дело зашло настолько далеко, что разработчики языка приняли решение: чем устранять недостатки существующего представления байтового кода, проще создать совершенно новое, и основным претендентом на его роль был выбран упомянутый выше Parrot.

От уровня к уровню

Может показаться странным, но многих разработчиков почему-то привлекают низкоуровневые языки. Кое-кто даже пишет на ассемблере те программы, которые гораздо быстрее создать на C или другом подобном языке. Неудивительно, что и желающих освоить Parrot оказалось немало. А его многоуровневая структура как будто специально задумана так, чтобы стимулировать желание к различным экспериментам.

На нижнем уровне находится собственно байтовый код (PBC – Parrot Byteсode), предназначенный для интерпретации. Выше расположен язык ассемблера PASM – его команды непосредственно преобразуются в инструкции байтового кода. На этом уровне программисту предоставляются операции (в основном элементарные) и четыре вида регистров, служащие для хранения целых чисел (I0, I1, ...), чисел с плавающей точкой (N0, N1, ...), строк (S0, S1, ...), и так называемые PMC-регистры (P0, P1, ...). В ранних версиях Parrot каждых было доступно только по 32, но затем это ограничение сняли. Если назначение первых трех разновидностей интуитивно понятно, то регистры PMC (Parrot Magic Cookie) несколько необычны. Это специальные хранилища данных, ориентированные на работу с массивами и другими структурами, типичными для языков высокого уровня. В частности, в дескрипторе регистра PMC предусмотрено поле obj, посредством которого можно ссылаться на любой объект. Как это ни удивительно, но исходный текст Perl, языка без поддержки типов, преобразуется в код, где типы худо-бедно, но присутствуют.

Байтового кода и PASM вполне хватило бы для успешного написания программ, но разработчики Parrot пошли дальше. Заботясь о программистах (скорее о тех, кто создает компиляторы с языков высокого уровня, а не непосредственно использует Parrot), они реализовали над PASM еще один уровень – PIR (Parrot Intermediate Representation). Данный язык предоставляет конструкции, ускоряющие программирование ряда операций, кроме того, помимо четырех типов регистров, в нем можно применять именованные переменные. Простые программы на PIR чем-то напоминают фрагменты Perl-кода. Такое сходство вполне объяснимо, если учесть, что работы над Parrot ведутся в рамках проекта Perl 6. Для компиляции PIR-файлов создан инструмент IMCC (Intermediate Code Compiler), который интегрирован в исполняемый файл Parrot. Туда же включен транслятор с языка PASM и интерпретатор байтового кода. Таким образом, с помощью одного инструмента можно скомпилировать PIR-файл по выбору в PASM или в байтовый код и запустить полученную программу. И, конечно же, не забыты средства, повышающие эффективность выполнения программ, например JIT-компилятор.

«Песочные часы» интерпретируемых языков

Рис.1

Попробуем условно изобразить на бумаге текущее положение дел с интерпретируемыми языками. Нарисуем вверху отрезок, соответствующий высокоуровневым языкам (Perl, Python, Tcl, Java, C#, J# и т. д.), а внизу – представляющий аппаратные платформы (не будем перечислять их). Тогда виртуальные машины (JVM, CLR, Parrot) естественным образом займут промежуточное положение (рис. 1, а). Нельзя не заметить, что число виртуальных машин значительно меньше, чем количество языков высокого уровня или аппаратных платформ. Замкнем контур и получим фигуру, напоминающую песочные часы, причем чем меньше языков представления промежуточного кода будет использовано, тем yóже будет «горловина» (рис. 1, б).

Преимущества от подобного сужения несомненны. Ведь мастерство программиста – это не столько владение синтаксисом (изучить его несложно), сколько знание библиотек. А имея универсальный язык промежуточного представления для нескольких языков высокого уровня, можно обойтись всего одним объединенным набором библиотек. Допустим, если программы на Perl и Python будут транслироваться в Parrot, то к Perl-библиотекам можно будет обращаться из программы, написанной на Python, и наоборот. Таким образом, «горловина» непременно сузится. Но какой язык промежуточного представления станет тем самым единственным? Первые шаги по завоеванию права контролировать эти своеобразные «Фермопилы» сделала компания Microsoft, приняв концепцию единого байтового кода для всех языков .NET. Однако не исключено, что Parrot окажется достойным конкурентом, и именно он займет ключевую позицию, в которой встречаются высокоуровневые языки и аппаратные платформы. По крайней мере, перевод на Parrot таких языков, как Perl, Python и Ruby – дело в принципе решенное.

Несколько в стороне стоит Java. Компания Sun Microsystems, с одной стороны, не предпринимает открытых попыток «переманить» на свой байтовый код иные языки, а с другой – не собирается отказываться от JVM (Java Virtual Machine). Специалисты единодушны в одном: переход с виртуальной машины Java на Parrot оказался бы чрезвычайно трудной задачей, ведь Parrot имеет регистровую структуру, а байтовый код Java на данный момент организуется по стековому принципу. Но трудно – не значит невозможно. Ведь виртуальная машина, используемая в пятой версии Perl, тоже стековая, а переход на Parrot – почти свершившийся факт.

Если же какой-то язык (и почему бы не Parrot) все-таки будет принят в качестве единственного универсального для представления промежуточного кода, то кто знает, а вдруг кто-то задумается и о его аппаратной реализации? Но это дело будущего...

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365