Архитектура виртуальных машин

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

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

Абстракция и виртуализация

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

Рис. 1. Абстракция и виртуализация в применении к дисковой памяти: (а) абстракция поддерживает упрощенный интерфейс к базовым ресурсам; (б) на данном уровне абстракции виртуализация обеспечивает альтернативный интерфейс к ресурсам и организацию их разделения

На рис. 1 (а) приведен пример абстракции в применении к дисковой памяти. Операционная система абстрагируется от тонкостей адресации на жестком диске, от его секторов и дорожек, чтобы для прикладной программы диск выглядел как набор файлов переменного размера. Опираясь на эту абстракцию, «прикладные» программисты могут создавать файлы, записывать и читать данные, не зная устройства и физической организации жесткого диска.

Концепция архитектуры системы команд компьютера (instruction set architecture, ISA) наглядно иллюстрирует преимущества хорошо определенных интерфейсов. Они позволяют разрабатывать взаимодействующие компьютерные подсистемы не только в разных организациях, но и в разные периоды, иногда разделенные годами. Например, Intel и AMD создают микропроцессоры с системой команд IA-32 (x86), в то время как разработчики Microsoft пишут программное обеспечение, которое компилируется в эту систему команд. Поскольку обе стороны соблюдают спецификацию ISA, можно ожидать, что программное обеспечение будет правильно выполняться любым ПК на базе микропроцессора с архитектурой IA-32.

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

Виртуализация позволяет обойти эту несовместимость. Виртуализация системы или компонента (например, процессора, памяти или устройства ввода/вывода) на конкретном уровне абстракции отображает его интерфейс и видимые ресурсы на интерфейс и ресурсы реальной системы. Следовательно, реальная система выступает в роли другой, виртуальной системы или даже нескольких виртуальных систем.

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

Виртуальные машины

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

Встроенные системные интерфейсы

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

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

Рис. 2. Архитектура компьютерной системы. Вертикальные связи между ключевыми уровнями реализации обеспечиваются архитектурой системы команд (ISA), двоичным интерфейсом приложений (ABI) и интерфейсом прикладного программирования (API)

На рис. 2 показаны некоторые важные интерфейсы и уровни реализации в типичной компьютерной системе. Три таких интерфейса (расположенных на границе между оборудованием и программным обеспечением) являются особенно важными для построения ВМ: это архитектура системы команд (ISA), двоичный интерфейс приложений (application binary interface, ABI) и интерфейс прикладного программирования (application programming interface, API).

Архитектура системы команд. ISA определяет границу между оборудованием и программным обеспечением и состоит из двух интерфейсов, обозначенных на рис. 2 цифрами 3 и 4. Интерфейс 4 представляет собой пользовательскую часть ISA и содержит функции, доступные прикладной программе. Интерфейс 3 (системная часть ISA) кроме пользовательских команд содержит функции, доступные только компонентам операционной системы, которые отвечают за управление оборудованием.

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

Интерфейс прикладного программирования. API предоставляет программе аппаратные ресурсы и услуги через пользовательскую часть ISA (интерфейс 4), дополненную обращениями к библиотекам на языке высокого уровня (интерфейс 1). Все вызовы системных процедур обычно выполняются через библиотеки. Использование API позволяет путем перекомпиляции легко переносить прикладные программы на другие системы, поддерживающие тот же интерфейс прикладного программирования.

Процессные и системные виртуальные машины

Чтобы понять сущность виртуальной машины, необходимо рассмотреть значение слова «машина» с точки зрения системы и процесса.

С точки зрения процесса, обеспечивающего выполнение пользовательской программы, машина состоит из выделенного процессу логического адресного пространства, команд пользовательского уровня и регистров, которые позволяют выполнять код этого процесса. Устройства ввода/вывода доступны лишь через операционную систему, и для процесса есть только один способ взаимодействия с системой ввода/вывода — вызовы системных процедур. Таким образом, применительно к процессу машину определяет интерфейс ABI. А интерфейс API определяет характеристики машины с точки зрения прикладной программы, написанной на высокоуровневом языке.

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

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

Процесс или система, выполняемая на ВМ, называется гостем, а базовая платформа, поддерживающая ВМ, — хостом. Программное обеспечение виртуализации, реализующее процессную ВМ, часто для краткости именуют рабочей средой. Программное обеспечение виртуализации системной ВМ обычно называют монитором виртуальных машин (virtual machine monitor, VMM).

Рис. 3. Процессные и системные виртуальные машины: (а) программное обеспечение виртуализации процессной ВМ преобразует системные вызовы и машинные команды пользовательского уровня в соответствующие вызовы и команды другой программно-аппаратной платформы; (б) в системной ВМ программное обеспечение виртуализации преобразует машинные команды одной аппаратной платформы в команды для другой

На рис. 3 представлены процессная и системная ВМ. Волнистыми линиями обозначены совместимые интерфейсы. В процессной виртуальной машине программное обеспечение виртуализации находится на уровне интерфейсов ABI или API, над границей между операционной системой и оборудованием. Среда исполнения (runtime) эмулирует как команды пользовательского уровня, так и вызовы системных процедур и обращения к библиотекам. В системной виртуальной машине программное обеспечение виртуализации находится между аппаратными средствами хост-машины и гостевым программным обеспечением. Монитор VMM может эмулировать аппаратную архитектуру ISA, отличную от ISA хоста, чтобы гостевое программное обеспечение могло выполнять другую систему команд. Однако во многих реализациях системных ВМ монитор VMM не занимается эмуляцией команд; его основная роль состоит скорее в виртуализации аппаратных средств.

Процессные виртуальные машины

Процессные ВМ создают виртуальные среды ABI или API для пользовательских приложений. Различные их разновидности позволяют в многозадачном режиме осуществлять репликацию операционной среды, эмулировать систему команд, оптимизировать код или выполнять программы на языках высокого уровня.

Многозадачные системы

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

Интерпретаторы и динамические трансляторы двоичного кода

Более сложной проблемой для процессных ВМ является поддержка программ в двоичном коде, которые скомпилированы для системы команд, отличающейся от системы команд хоста. Свежий пример процессной ВМ — программный пакет Intel IA32-EL [1], позволяющий на платформе Itanium выполнять приложения, рассчитанные на IA-32.

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

Оптимизаторы двоичного кода

Для повышения производительности динамические трансляторы иногда оптимизируют двоичный код. Эта возможность приводит к идее создания виртуальной машины, в которой гость и хост используют одну и ту же систему команд. Единственным назначением такой ВМ становится оптимизация двоичного кода. Оптимизаторы используют информацию из профиля, собранную при интерпретации или трансляции, чтобы оптимизировать двоичный код «на лету». Примером такого оптимизатора является система Dynamo — один из результатов реализации научно-исследовательского проекта компании Hewlett-Packard [2].

Виртуальные машины для языков высокого уровня

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

Рис. 4. Среды языка высокого уровня: (а) в традиционной среде распространяется зависимый от платформы объектный код; (б) в среде ВМ языка высокого уровня зависимая от платформы виртуальная машина выполняет переносимый промежуточный код

Рис. 4 показывает различия между обычной средой компиляции, зависящей от платформы, и средой ВМ языка высокого уровня. В обычной среде (рис. 4(а)) препроцессор транслятора генерирует промежуточный код, подобный машинному, но более абстрактный. Затем генератор кода на его основе создает двоичный файл с машинным кодом для конкретной операционной системы и архитектуры ISA. Этот файл может выполняться на платформах, поддерживающих данную комбинацию ISA/операционная система.

В ВМ языка высокого уровня (рис. 4(б)) транслятор генерирует абстрактный машинный код для виртуальной ISA, которая определяет интерфейс ВМ. Этот виртуальный код вместе с сопутствующими метаданными (информацией о структурах данных) распространяется для выполнения на различных платформах. На каждой из них установлена ВМ, способная загрузить и выполнить команды виртуальной ISA, а также имеется набор библиотечных подпрограмм, предписанный стандартизированным API. Простейший вариант такой ВМ представляет собой интерпретатор. Более сложные высокопроизводительные ВМ транслируют абстрактный код в машинный для непосредственного выполнения на базовой платформе.

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

Известными примерами ВМ языка высокого уровня являются архитектура виртуальной машины Java компании Sun Microsystems [3] и среда Microsoft Common Language Infrastructure, на которой основана платформа .NET Framework [4]. В обеих системах применяются стековые архитектуры ISA, что позволяет устранить необходимость в регистрах, использовать абстрактную спецификацию данных и модель памяти, поддерживающие безопасное объектно-ориентированное программирование.

Системные виртуальные машины

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

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

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

В системной ВМ монитор VMM обеспечивает репликацию платформы. Основной проблемой является распределение аппаратных ресурсов между несколькими гостевыми операционными системами (примером служит виртуализация диска, показанная на рис. 1). VMM управляет всеми аппаратными ресурсами. Гостевая операционная система и ее прикладные процессы работают под скрытым контролем VMM. Когда гостевая ОС пытается выполнить привилегированную команду или операцию, непосредственно затрагивающую общие аппаратные ресурсы, VMM ее перехватывает, проверяет правильность и исполняет от имени гостя. Гостевое ПО «не знает» об этой негласной работе.

Классические системные ВМ

Большинство системных ВМ обеспечивают примерно одинаковые функциональные возможности, но различаются деталями реализации. При классическом подходе [6] монитор VMM устанавливается на «голом железе», а ВМ располагается поверх него. VMM выполняется в привилегированном режиме, в то время как гостевые операционные системы лишены почти всех привилегий. Это необходимо, чтобы VMM мог перехватывать и эмулировать те их действия, которые в обычных условиях связаны с управлением жизненно важными аппаратными ресурсами.

Вложенные ВМ

В альтернативной реализации системной ВМ программное обеспечение виртуализации располагается поверх существующей хост-системы. Такая ВМ называется вложенной. Преимущество вложенных ВМ состоит в том, что пользователь устанавливает их точно так же, как любую прикладную программу. Чтобы получить доступ к драйверам устройств и другим низкоуровневым услугам, программное обеспечение виртуализации обращается к хост-системе, а не к VMM. Примером вложенной ВМ может служить сервер VMware GSX Server [7], который выполняется на аппаратной платформе IA-32.

Интегральные ВМ

В обычных системных ВМ хост-система, все гостевые операционные системы и прикладные программы используют архитектуру ISA базового оборудования. Однако в некоторых ситуациях гость и хост не имеют общей ISA. Например, две самые популярные настольные системы, Windows PC и Apple PowerPC, используют различные ISA и разные операционные системы.

Интегральные ВМ справляются с такой ситуацией, виртуализируя все программное обеспечение, в том числе операционную систему и приложения. Из-за различий в системах команд ВМ должна эмулировать и код приложений, и код операционной системы. Примером ВМ такого типа служит эмулятор Virtual PC [8], в котором система Windows работает на платформе Macintosh. Программное обеспечение ВМ выполняется на хосте как обычная прикладная программа и не использует системных операций ISA.

Многопроцессорная виртуализация

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

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

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

Встроенные ВМ

Функциональность и мобильность — вот цели большинства системных ВМ, реализованных на уже имеющихся аппаратных средствах со стандартной архитектурой ISA. В отличие от них, встроенные ВМ реализуют новые частные архитектуры, нацеленные на повышение производительности и эффективности работы. ISA хост-машины может быть полностью новой или расширять возможности существующей.

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

Наиболее известный пример встроенной ВМ — процессор Transmeta Crusoe [11]. Его базовые аппаратные средства используют архитектуру команд со сверхдлинным командным словом (very long instruction word, VLIW), а гостевая ISA — это Intel IA-32. Благодаря простоте аппаратной части, предназначенной для выполнения команд VLIW, разработчикам Transmeta удалось существенно снизить энергопотребление процессора.

В системе IBM AS/400 (сегодня известна как iSeries) также используется технология встроенных ВМ [12]. В отличие от других встроенных ВМ, основное назначение AS/400 — поддержка объектно-ориентированной системы команд, позволяющей по-новому взглянуть на интерфейс между оборудованием и программным обеспечением. Сегодняшние реализации AS/400 основаны на расширенной архитектуре PowerPC, тогда как ранние версии использовали существенно отличавшуюся от нее частную архитектуру ISA.

Систематика виртуальных машин

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

Рис. 5. Классификация виртуальных машин. В категориях процессных и системных ВМ основным дифференцирующим признаком является эмуляция ISA

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

В категорию процессных ВМ с разными гостевой и базовой ISA входят динамические трансляторы, у которых интерфейс с оборудованием обычно определяется на уровне ABI, а также ВМ языка высокого уровня на разделы с интерфейсом на уровне API.

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

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

***

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

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

Литература

L. Baraz et al, IA-32 Execution Layer: A Two-Phase Dynamic Translator Designed to Support IA-32 Applications on Itanium-Based Systems. Proc. 36th Ann. IEEE/ACM Intl Symp. Microarchitecture, IEEE CS Press, 2003.
V. Bala, E. Duesterwald, S. Banerjia, Dynamo: A Transparent Dynamic Optimization System. Proc. ACM SIGPLAN 2000 Conf. Programming Language Design and Implementation, ACM Press, 2000.
T. Lindholm, F. Yellin, The Java Virtual Machine Specification, 2nd ed. Addison-Wesley, 1999.
D. Box, Essential .NET, Volume 1: The Common Language Runtime. Addison-Wesley, 2002.
R.J. Creasy, The Origin of the VM/370 Time-Sharing System. IBM Journal Research and Development, Sept. 1981.
R.P. Goldberg, Survey of Virtual Machine Research. Computer, June 1974.
J. Sugerman, G. Venkitachalam, B-H. Lim, Virtualizing I/O Devices on VMware Workstations Hosted Virtual Machine Monitor. Proc. General Track: 2001 Usenix Ann. Technical Conf., Usenix Assoc., 2001.
E. Traut, Building the Virtual PC. Byte, Nov. 1997.
Sun Enterprise 10000 Server: Dynamic System Domains. Sun Microsystems, Tech. white paper, 1999.
T.L. Borden, J.P. Hennessy, J.W. Rymarczyk, Multiple Operating Systems on One Processor Complex. IBM Systems Journal, Jan. 1989.
A. Klaiber, The Technology Behind Crusoe Processors: Low-Power x86-Compatible Processors Implemented with Code Morphing Software. Tech. brief, Transmeta, 2000.
E. Soltis, Inside the AS/400. Duke Press, 1996.

Джеймс Смит (atjes@ece.tvisc.edu) — профессор факультета электротехники и вычислительной техники в университете Висконсина. Рави Наир (nair@us.ibm.com) — научный сотрудник исследовательского центра IBM Watson Research Center.