ДЛЯ КОМПЕТЕНТНЫХ В ОБЛАСТИ IT ЛЮДЕЙ НЕ СЕКРЕТ, ЧТО ТЕХНОЛОГИИ, НА КОТОРЫХ БАЗИРУЮТСЯ ТАК НАЗЫВАЕМЫЕ СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ (В ПЕРВУЮ ОЧЕРЕДЬ LINUX И WINDOWS), ОТЖИЛИ СВОЕ ЕЩЕ В ВОСЬМИДЕСЯТЫХ ГОДАХ. МОНОЛИТНАЯ МОДЕЛЬ ЯДРА, НЕПЕРЕНОСИМЫЙ ПРОЦЕССОРНО-ЗАВИСИМЫЙ КОД, УЩЕРБНЫЙ В ОБЛАСТИ БЕЗОПАСНОСТИ ЯЗЫК (С/С++) — ВСЕ ЭТО СОЗДАЕТ СУЩЕСТВЕННЫЕ ПРОБЛЕМЫ КАК ПРИ РАЗРАБОТКЕ ОС, ТАК И ПРИ ЕЕ СОПРОВОЖДЕНИИ.

Основная проблема заключается в невозможности без перекомпиляции (а зачастую и без модификации) перенести существующее программное обеспечение в другую среду исполнения. К примеру, мы не можем запустить программу, написанную для Windows, в Linux. Или без пересборки запустить программу, написанную для работающего на процессоре PowerPC Linux, на обычном домашнем ПК с i386-совместимым процессором. В век повсеместной компьютеризации эта проблема стоит особенно остро, ввиду наличия на рынке множества аппаратных платформ.
Необходима некая универсальная платформа, среда исполнения, которая позволит программному обеспечения одинаково комфортно себя чувствовать как на мейнфремах, так и в недрах смартфона, лежащего в кармане банковского служащего.

p-код как решение проблемы переносимости

Технология, позволяющая проделать подобное, известна еще с 70-х годов и носит имя p-код (pseudo-code) или байткод. Идея достаточно проста и в некотором смысле очевидна. Вместо того чтобы транслировать код, написанный на высокоуровневом языке, в машинный код конкретной модели процессора, привязывая таким образом программу к аппаратной платформе, автор p-кода предложил транслировать высокоуровневый код в специальный, независимый от модели процессора байткод, который во время исполнения будет транслироваться в аналогичный машинный код целевого процессора. Таким образом, достигается необходимый уровень переносимости программного обеспечения. Теперь, для того чтобы перенести существующее ПО на новую аппаратную платформу, достаточно создать лишь среду исполнения для p-кода, которая обеспечит уровень совместимости со средами исполнения, реализованными на другой аппаратной платформе.

Под средой исполнения в данном случае понимается не только интерпретатор p-кода, транслирующий его в машинный код процессора, но и унифицированный API, позволяющий программам общаться с «внешним миром». При этом сама среда исполнения может быть реализована как программа, работающая в существующей операционной системе (например, Windows).

Причин, по которым p-код не получил признания в 70-х и 80-х годах, несколько, но все они сводятся к одному, вполне обоснованному выводу — p-код слишком медлителен. Действительно, в те годы процессоры были не достаточно мощны и слишком дороги, для того чтобы тратить время еще и на трансляцию p-кода в процессорные команды. Сегодня же, в век, когда портативный компьютер лежит в кармане чуть ли не каждого школьника, а вычислительные мощности стали значительно дешевле, затраты на трансляцию p-кода кажутся просто смешными.

Казалось бы, никаких ограничений к внедрению переносимых программ, которые смогут работать где угодно и когда угодно, в повседневную реальность нет. Но загвоздка в том, что, двигаясь по этой дороге, рано или поздно мы натолкнемся на большой грузовик с надписью «Существующее программное обеспечение» и путь вновь окажется перекрытым. Огромная инертность, созданная гигантским количеством программного обеспечения, привязанного к конкретным средам, которые, в свою очередь, привязаны к аппаратуре (POSIX API и WinAPI), существенно, если не сказать катастрофически, снижает скорость внедрения переносимого ПО в жизнь.

Первой компанией, попытавшейся внедрить p-код в мэйнстрим, стала компания SUN, программисты которой создали среду исполнения и безопасный высокоуровневый язык Java. Но несмотря на то, что платформе уже более десяти лет, должного признания она не получила до сих пор. Для Java создана достаточно большая база ПО, но большинство из программ являются узкоспециализированными, и настоящей среды, обеспечивающей полное рабочее окружение пользователя, до сих пор не существует.

Microsoft, не желающая остаться за бортом, разработала собственную реализацию безопасного языка, виртуальной машины и среды исполнения, которая в последствии была названа «платформа .NET». Она очень схожа как по замыслу, так и по реализации с платформой Java, но несколько отличается целевой нишей. В то время как Sun стремится переманить программистов с других языков программирования на Java, которая может работать практически на любой более-менее популярной ОС, Microsoft старается предоставить разработчиками весь спектр языков и парадигм программирования в одной единственной ОС — Windows. То есть Microsoft делает то, чем занималась последние двадцать лет — переманиванием пользователей и программистов на свою сторону, что не очень соотносится с идей портируемого кода.

p-код и будущее операционных систем

Другим проектом, занимающим почетное место среди пропагандистов переносимого ПО, является Inferno. В отличие от Java, которая представляет собой специальный набор программ, различные версии которого предназначены для использования в разных ОС, Inferno сама по себе является операционной системой, построенной на основе ядра Plan9, на самом высоком уровне которого находится виртуальная машина dis. Как и Plan9, Inferno преследует одну цель — создать некую среду, которая облегчит перенос ПО на множество аппаратных платформ и унифицирует процесс их коммуникации. Достигается это классическим способом. Ядро ОС, которое написано с использованием традиционных методов программирования, реализуется для как можно большего количества аппаратных платформ, а виртуальная машина dis и среда исполнения остаются совместимыми между всеми реализациями. Необходимость перекомпиляции, а уж тем более модификации ПО для того чтобы оно могло работать на другой архитектуре, попросту отпадает. Кроме того, виртуальная машина может быть установлена на другую ОС (Linux или Windows) или подключена как плагин к web-браузеру.

Inferno ставит, может быть, и не очевидный, но весьма насущный вопрос. А почему бы всю ОС не транслировать в p-код? Действительно, в этом случае отпала бы необходимость не только переноса ПО между различными ОС, но и сама ОС стала бы переносимой между процессорными архитектурами.

Проекты переносимых ОС, основанных на идее p-кода существуют - это jnode (Java), bluebottle (Oberon) и singularity (.NET). Все они базируются на одном и том же архитектурном решении. На самый нижний уровень ОС ложится виртуальная машина, которая работает напрямую с аппаратными ресурсами и выполняет одновременно роль интерпретатора p-кода и экзоядра, обеспечивающего доступ к аппаратной начинке ПК. Сама же ОС пишется на высокоуровневом языке, который затем транслируется в p-код. Таким образом, для того, чтобы перенести ОС на иную аппаратную платформу, достаточно адаптировать лишь виртуальную машину, которая зачастую имеет очень малый размер, без необходимости переносить всю ОС.

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

Защитники канонического подхода к разработке ОС могут возразить, что классические технологии обеспечивают не меньший уровень переносимости, приведя в пример Linux или NetBSD, которые работают на десятках различных архитектур и при этом написаны на привычном и весьма распространенном языке С. С этим можно согласиться только отчасти. Если провести исследование кода этих ОС, то мы увидим множество хитрых приемов, к которым прибегли разработчики, чтобы добиться одинакового поведения ОС на разных архитектурах. Код буквально пестрит множеством директив препроцессора, используемых для выбора того или иного варианта кода, специфичного для конкретной модели процессора. Разработчикам приходится учитывать порядки следования байт, разрядность процессоров, методы адресации и многое другое. Факт того, что операционная система, написанная на языке С, может исполняться на множестве процессорных архитектур - не само собой разумеющееся явление, а результат кропотливой работы многих программистов.

Рассмотрим пример с гипотетической ОС, созданной с использованием технологии виртуальных машин. Такая ОС состоит условно из нескольких уровней:

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

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

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

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

Для переноса такой операционной системы на иную аппаратную платформу потребуется адаптировать компоненты первого уровня и дополнить второй необходимым набором драйверов. Код всех остальных уровней останется неизменным и не потребует модификации и перекомпиляции.

Нет гарантии, что процесс портирования подобной ОС превратится в более простую задачу в сравнении, например, с NetBSD (хотя в том случае, если дизайн ОС хорошо проработан и на первый уровень вынесена лишь минимально необходимая часть ОС, то так оно и будет). Вся соль подобной архитектуры в том, что теперь разработчикам драйверов и компонентов всех вышележащих уровней не придется обременять себя заботой о совместимости своего кода с различиями в аппаратном обеспечении. Идеализированная модель ПК, предоставляемая экзоядром, останется абсолютно идентичной на любой аппаратной платформе.

Дополнительным плюсом такой ОС является еще и то, что она способна работать в реальном режиме процессора, не прибегая к помощи аппаратного блока MMU (Memory Management Unit). Защиту адресов в такой ОС выполняет виртуальная машина, что не только существенно снижает потребление ресурсов, требуемых для выполнения переключения контекста и упрощает архитектуру ядра, но и позволяет портировать операционную систему на процессоры, лишенные поддержки аппаратной защиты памяти.

Достоинства переносимого кода

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

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

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

Правда, переносимый код обладает одним выраженным недостатком. В отличие от машинного кода, p-код требует постоянного присутствия виртуальной машины в оперативной памяти, поэтому затраты на исполнение p-кода несколько выше. Тот факт, что исполняемый модуль, транслированный в переносимый код, имеет меньший размер, мог бы компенсировать описанный недостаток. Но есть одно но. JIT-компилятор, используемый в современных виртуальных машинах для перевода p-кода в машинный код «на лету», также использует некоторый объем памяти для хранения уже транслированных машинных инструкций. То есть в памяти одновременно присутствуют как процессорно-независимый p-код, так и его аналог, представленный машинными инструкциями.

Переносимый код и стандарты

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

Глоссарий

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

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

Виртуальная машина — программная среда, исполняющая некоторый код.

Среда исполнения — совокупность программного обеспечения, предоставляющего унифицированный ABI (Application Binary Interface), который могут использовать другие программы для доступа к ресурсам операционной системы.

История p-кода

Идея p-кода принадлежит Арсу Эмману (Urs Ammann), студенту Никлауса Вирта. В своем документе «On Code Generation in a Pascal», опубликованном в 1977 году, Эмман описал метод трансляции исходного кода программы в промежуточный код и то, как эта идея может быть использована для создания переносимых программ. Год спустя Кэн Боулс (Ken Bowles), профессор Калифорнийского университета в Сан Диего, разработал операционную систему UCSD p-System, в основе которой лежала виртуальная машина, исполняющая p-код, который, в свою очередь, создавался специальным компилятором с языка Pascal.

Идеей p-кода также заинтересовался и сам Никлаус Вирт. В 1985 году он начал работу над операционной системой Oberon, которая базировалась на интерпретаторе p-кода и высокоуровневом языке Oberon. Позднее на ее основе была создана ОС BlueBottle, развитие которой продолжается по сей день.

Эффективность p-кода

Среди программистов и пользователей распространено мнение, что весь переносимый код (и в частности Java) очень медлителен и непригоден для применения в сферах, требующих максимально возможной производительности от программ. К счастью, эти слухи преувеличены. В дни, когда идея переносимого кода была еще молода, а такие платформы как Java и Oberon только начинали набирать обороты, скорость исполнения p-кода действительно очень уступала (порой в десятки раз) скорости исполнения машинного кода.

С тех пор прошло много времени, и разработчики виртуальных машин нашли эффективные методы решения проблем производительности. Современные интерпретаторы p-кода используют JIT-компилятор для генерации процессорных команд «на лету» и различные методики оптимизации для генерации более эффективного в плане производительности кода. Сегодня p-код способен конкурировать в скорости исполнения с программами, написанными на С, а иной раз и опережает их.