«О ЭВМ 2-е издание, переработанное и дополненное Рекомендовано Учебно-методическим объединением высших учебных заведений Российской Федерации по образованию в области прикладных математики и физики в качестве учебного ...»

М Р Ф

М -

( )

О

ЭВМ

2-е издание, переработанное и дополненное

Рекомендовано

Учебно-методическим объединением

высших учебных заведений Российской Федерации

по образованию в области прикладных математики и физики

в качестве учебного пособия для студентов вузов

по направлению подготовки «Прикладная математика и физика»

М МФТИ 2013 УДК 004.42(075) ББК 32.973я73 075 А в т о р ы: Г. С. Речистов, Е. А. Юлюгин, А. А. Иванов, П. Л. Шишпор, Н. Н. Щелкунов, Д. А. Гаврилов Рецензенты:

Кафедра информационных систем управления и информационных технологий Московского государственного университета приборостроения и информатики Доктор технических наук, профессор Т. Ю. Морозова Кадидат технических наук Н. Б. Преображенский Основы программного моделирования ЭВМ: учеб. пособие / 075 Г. С. Речистов, Е. А. Юлюгин, А. А. Иванов и др. — 2-е изд., испр. и доп. — М. :

МФТИ, 2013. — 222 с.

ISBN 978-5-7417-0444- Рассмотрены вопросы моделирования аппаратных средств однопроцессорных и многопроцессорных вычислительных систем. Основное внимание уделено технологиям построения программных симуляторов, в том числе на основе интерпретации, двоичной трансляции, аппаратной виртуализации, многопоточного исполнения и моделирования с использованием трасс.

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

УДК 004.358 (075) ББК 32.973я © Речистов Г. С., Юлюгин Е. А., ISBN 978-5-7417-0444- Иванов А. А., Шишпор П. Л., Щелкунов Н. Н., Гаврилов Д. А., © Федеральное государственное автономное образовательное учреждение высшего профессионального образования «Московский физико-технический институт (государственный университет)», Об этой книге Главы данной книги соответствуют основным лекциям курса «Основы программного моделирования ЭВМ», читающихся в Московском физикотехническом институте.

Нам очень важно мнение читателя. Если вы обнаружили опечатку, стилистическую, фактическую ошибку, которые, более чем вероятно, встречаются в тексте, или имеете замечания по содержанию и предложения по тому, как можно улучшить данный материал, то просим сообщить об этом по e-mail [email protected] Авторы Данную книгу подготовил следующий коллектив лаборатории суперкомпьютерных технологий для биомедицины, фармакологии и малоразмерных структур им. В. М. Пентковского МФТИ: Г. С. Речистов, Е. А. Юлюгин, А. А. Иванов, П. Л. Шишпор, Н. Н. Щелкунов, Д. А. Гаврилов.

Благодарности Авторы выражают также благодарность всем слушателям курса и следующим людям, сообщившим свои замечания и исправления к тексту книги:

Илье Куприку, Денису Шиляеву, Денису Лытову, Анатолию Костину, Виталию Антонову, Даниилу Альфонсо, Дмитрию Бородий, Ивану Андрееву, Наталье Иванчиковой, Марине Шимченко, Максиму Кузнецову, Святославу Кузьмичу.

Предисловие Мы легко принимаем действительность, может быть, потому, что интуитивно чувствуем: ничто реально не существует.

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

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

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

Для максимально эффективного усвоения материала книги читателю рекомендуется иметь начальные знания по архитектуре ЭВМ; рекомендуется обратиться к великолепной книге [91]. Желательно понимание читателем общих принципов работы операционных систем, а также знакомство как Рис. 1. Основная идея симуляции. Модель некоторой вычислительной системы в виде программы исполняется на ЭВМ другой архитектуры минимум с одним языком программирования.

Нельзя не упомянуть книгу о виртуальных машинах, которая вдохновила авторов на написание этой работы [71]. Знакомство с ней также настоятельно рекомендуется всем читателям, желающим глубже разобраться в вопросе виртуализации.

Необходимо понимать, что методика моделирования применима не только к изучению вычислительных или цифровых, но и практически к любых технических, социальных или каких-либо иных систем. Читателю, желающему расширить своё понимание метода, рекомендуется книга [89].

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

В главе 2 приводится пример построения простого симулятора процессора, основанного на интерпретации инструкций.

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

В главе 4 рассматривается исследование вычислительных систем с помощью трасс исполнения — записи истории внешних событий.

Глава 5 знакомит с альтернативными подходами изучения ЭВМ с помощью различных методик: теории сетей центров обслуживания; сбора и проигрывания трасс событий; вероятностного моделирования.

Глава 6 описывает подходы к симуляции системы с множеством устройств, включая многопроцессорные системы.

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

В главе 8 описан подход к потактовой симуляции, обусловленный иным характером обработки событий в системе и потому отличный от ранее рассмотренных.

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

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

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

Глава 12 знакомит с особенностями обеспечения взаимодействия симуляции с внешним физическим миром.

В главе 13 даётся теоретический критерий возможности эффективной виртуализации вычислительных систем; затем проверяется соответствие ряда современных архитектур процессоров этому условию.

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

• Обычный текст используется для основного материала.

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

• Наклонный текст служит для выделения новых понятий.

• Числа в шестнадцатеричной системе счисления имеют префикс 0x (например, 0x12345abcd), в двоичной системе счисления — суффикс b (например, 10010011b).

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

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

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

• Большое число составляющих систему устройств со сложными взаимосвязями, как явными, так и скрытыми или даже паразитными.

• Необходимость сохранения обратной совместимости с уже существующим оборудованием, дополнительно усложняющая дизайн.

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

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

• Важность выявления ошибок проектирования на ранних стадиях.

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

10 $ исправления ошибки Рис. 1.1. Рост стоимости исправления ошибки с фазой проектирования устройства По этим причинам широко используется подход, когда разработка нового устройства сопровождается созданием его компьютерных моделей, способных с некоторой точностью проявлять себя так, как работает реальное устройство. Это становится возможным благодаря применению общесистемной методики борьбы со сложностью — модульностью подсистем и их абстракцией от остального мира. Устройства, входящие в состав ЭВМ, соединяются между собой через строго определённые интерфейсы, специфицирующие лишь то, что будет передаваться через них, но не определяющие, что будет с противоположной стороны от них. Свойство это очень полезно.

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

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

1.2. Применения моделей ЭВМ Перечислим лишь некоторые практические способы применения программных моделей.

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

Написание сопутствующего аппаратуре ПО. Ранняя доступность модели устройства позволяет использовать её для разработки драйверов, прошивок (таких как BIOS и UEFI [19]) и даже операционных систем и компиляторов параллельно с разработкой самого устройства. В наше время нередка ситуация, что драйвера для нового оборудования готовы и отлажены ещё до официальной доступности предназначенного для них оборудования.

Построение и исследование экспериментальных решений.

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

Однако моделирование даёт наибольшую гибкость.

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

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

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

Эмулятор (англ. emulator) — программа, моделирующая некоторую физическую систему путём имитации внутренней структуры и процессов, происходящих внутри подсистем аппаратуры.

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

работающая как «чёрный ящик»).

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

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

Гость (англ. guest) — система, поведение которой призван отражать симулятор и внутри которой исполняются гостевые приложения. Синонимичным является понятие целевая система (англ. target system).

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

Гипервизоры первого типа (автономные гипервизоры) работают прямо на хозяйской аппаратуре, т.е. не требуют для своей работы операционной системы, они берут её функции на себя и являются привилегированными приложениями. Данное обстоятельство позволяет минимизировать накладные расходы от виртуализации. Вместе с тем при разработке таких систем приходится тратить много усилий на поддержку функций операционной системы. Рис. 1.2 иллюстрирует устройство и работу гипервизоров первого типа.

Рис. 1.2. Структура симуляции при использовании гипервизора первого типа Примеры существующих мониторов виртуальных машин первого типа: VMware ESX(i) Server [81], Xen [60].

Гипервизоры второго типа не заменяют операционную систему, но работают поверх неё как обычное пользовательское приложение (иногда требуя установки драйверов или модулей ядра, работающих с повышенным приоритетом), см. рис. 1.3. Примеры таких программных продуктов: VirtualBox [80], KVM [43] (англ. Kernel-based Virtual Machine).

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

Рис. 1.3. Структура симуляции при использовании гипервизора второго типа Симулятор режима приложения (англ. application mode simulator) — программа, предназначенная для запуска «обычных» прикладных приложений (т.е. не операционных систем, BIOS или другого системного ПО). Целевые программы при этом ожидают активное присутствие определённой операционной системы, и потому симулятор обязан в том числе эмулировать необходимые системные вызовы для того, чтобы создать окружение, неотличимое от предоставляемого операционной системой. При этом модель получается жёстко привязанной к конкретному варианту системного ПО, так как список и формат системных вызовов и прочих интерфейсов приложений может заметно меняться между ОС (например, Windows, Linux и Mac OS имеют разные механизмы вызова операций в контексте ОС) и даже внутри одной ОС между её версиями (например, Linux 2.4 и Linux 2.6). Как правило, количество моделируемого при этом аппаратного обеспечения минимально.

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

Потактовая модель (англ. cycle precise model, performance model) — симулятор, корректно высчитывающий ход времени внутри моделируемой системы. Он моделирует её внутреннее устройство более детальНазначение и сценарии применения моделирования ЭВМ но, чем это делается в функциональных моделях. Потактовые модели обычно во много раз медленнее функциональных.

Гибридная модель (англ. hybrid model) — система, частично реализованная в программе для обычной ЭВМ (например, для персонального компьютера), а частично — на специализированном оборудовании (например, на ПЛИС). Применяется в тех случаях, когда чисто программное моделирующее решение недостаточно быстро.

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

Рис. 1.4. Место различных типов симуляции в стеке существующих интерфейсов вычислительных систем На самом верхнем уровне находятся её алгоритмы, в общем случае не привязанные к аппаратуре. Поскольку почти любой вычислительный процесс человек может провести с использованием ручки и бумаги (оставим в стороне вопрос, сколько времени у него это займёт), то «имитация» компьютера на этом уровне представляет собой анализ её работы. При этом такая аналитическая модель может быть неполной, упрощённой для того, чтобы передать лишь существенные для конкретного исследования аспекты работы, например, только её энергопотребление или только детали взаимодейПрограммируемая логическая интегральная схема.

ствия с внешними агентами. В этом случае «хозяйской» системой является сам человек.

Реальные программы редко бывают написаны полностью с нуля, чаще всего они используют в своей работе сторонние библиотеки, подпрограммы, процедуры, функции и т.п., в том числе сюда относятся сервисы операционной системы — системные вызовы. Для возможности эффективного взаимодействия кода библиотек и программ вводятся соглашения, такие как интерфейс пользовательских приложений (англ. application program interface, API) и интерфейс двоичных приложений (англ. application binary interface, ABI), определяющие форматы передачи входных данных и результатов, а также ожидаемую от подпрограмм функциональность. Симулятор заменяет алгоритм каждого вызова API/ABI другим, с достаточной точностью передающим работу оригинальной подпрограммы и имеющим совместимый формат данных. При этом хозяйские и гостевые системы не обязаны использовать одни и те же соглашения. Таким образом работают модели уровня приложений — они заменяют операционную систему, ожидаемую пользовательским кодом, набором собственных реализаций API. Примеры описаний программных интерфейсов приложений — стандарт MPI [53] и стандарт OpenMP [56]. Пример документа, описывающего двоичный интерфейс AMD64 ABI, [74].

Если посмотреть в работу приложений ещё глубже, то любой вычислительный процесс состоит из последовательного и параллельного исполнения инструкций одного или более процессоров. Формат и ожидаемая функция каждой из них описаны в специальных документах — руководствах для разработки программ (англ. soware development manual, SDM). Примеры таких документов для ISA (англ. instruction set architecture, архитектура набора инструкций): [39, 7, 83, 70, 6]. Функциональный симулятор заменяет алгоритм каждой гостевой инструкции на эквивалентный, но представленный в терминах хозяйской системы.

Исполнение каждой машинной инструкции может быть разделено на несколько стадий, имеющих различную длительность, величина которой может зависеть от ряда факторов. Кроме того, в работе вычислительной системы могут присутствовать процессы, не отражённые на уровне ISA, но тем не менее влияющие на её функционирование, например, работа кэшей или изменение частоты процессора. Для их учёта симулятор должен абстрагировать процессы на ещё более низком, микроархитектурном уровне. При этом становится возможным более точно моделировать времена работы приложений как сумму длительностей микроопераций. Отметим, что документация на данный уровень представления процессоров чаще всего является внутренним секретом компаний, недоступна для независимых разработчиков приложений и может быть получена только при подписании ряда соглаНазначение и сценарии применения моделирования ЭВМ шений о неразглашении (англ. non disclosure agreement, NDA).

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

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

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

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

1.5. История использования симуляции В различных формах компьютерные симуляторы используются с момента создания вычислительной техники. Так, IBM System/360 Model 67 выпуска 1967 года поддерживала виртуальные машины на аппаратном уровне [13], а саму System/360 эмулировали многие последующие ЭВМ, такие как RCA Spectra/70.

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

• Интересным примером использования симуляции для обеспечения обратной совместимости является продукция компании Apple. Первые компьютеры Macintosh (1980-е гг.) были построены на процессорах Motorola 68x0 (общее название для серии чипов). В 1994 году новые компьютеры Apple стали использовать процессоры PowerPC. Для обеспечения работы приложений, написанных для старого оборудования, с ними поставлялся эмулятор [1], работа которого была максимально прозрачна для пользователя и приложений. В 2006 году произошёл ещё один переход — на архитектуру Intel®IA-32. И снова для совместимости новые Макинтоши имели встроенный эмулятор с именем Rosetta [63, 69].

• В 2001 году для новой архитектуры Intel® Itanium™ был использован симулятор Gambit [23].

• В 2001 году для портирования операционной системы NetBSD на тогда ещё официально не выпущенную архитектуру AMD64 был использован симулятор Simics [54].

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

• Во всех 32-битных ОС Microso Windows серии NT существует система NTVDM [64] — эмулятор 16-битного режима MS-DOS. Отметим, что в 64-битных редакциях Windows по ряду причин технического характера подобного слоя совместимости нет.

• В некоторых версиях Microso Windows 7 (Professional, Ultimate и Enterprise) доступен режим совместимости с Microso Windows 1. Назначение и сценарии применения моделирования ЭВМ XP [95], выполненный в виде предустановленной в Virtual PC операционной системы, взаимодействие с которой производится по протоколу RDP.

• Для архитектуры Intel® Itanium™ существует система совместимости для запуска кода архитектуры IA-32 [34], активно задействующая технологии статической и динамической двоичной трансляции (см. главу 3).

• В 2012 году компания ARM объявила о введении нового 64-битного расширения своей архитектуры ARMv8. Первые образцы реальных процессоров ожидаются в 2013 году, до этого момента разработка и адаптация существующего кода может вестись сейчас на симуляторе [72].

1.6. Обзор существующих симуляторов и виртуальных машин VMware ESX(i) Server [81]. Коммерческий продукт, являющийся монитором первого типа. Предназначен для виртуализации крупных систем уровня предприятия. VMware ESXi Server доступен бесплатно, тогда как VMware ESX Server требует коммерческой лицензии, но и предоставляет расширенные возможности.

VMware Workstation Проприетарный продукт, являющийся монитором виртуальных машин второго типа. Работает на операционных системах Windows и Linux. Бесплатный вариант для некоммерческого использования называется VMware Player.

Xen Открытый монитор виртуальных машин первого типа, развиваемый компанией Citrix [60]. Работает на большом числе хозяйских архитектур, включая ARM и IA-32. Применяется для крупномасштабной виртуализации (используется, например, компанией Amazon в облачном сервисе Amazon Elastic Compute Cloud).

Qemu Открытый симулятор различных систем [11]. Портирован для большого числа операционных систем. В качестве гостевых архитектур поддерживает системы IA-32, IA-32 EMT64, IA-64, PowerPC, Alpha, SPARC 32/64, ARM…; в качестве хозяйских систем могут использоваться IA-32, IA-32 EMT64, ARM, CRIS, LM32, MicroBlaze, MIPS, SPARC 32/64, PowerPC.

KVM (англ. Kernel-based Virtual Machine). Открытый монитор виртуальных машин второго типа, основанный на технологиях Qemu и встроенный в ядро операционной системы Linux [43]. Популярен для задач виртуализации Linux и развивается фирмой Red Hat.

VirtualBox Открытый монитор виртуальных машин второго типа [80] для гостевых и хозяйских архитектур IA-32 и портирован для работы внутри Windows, Linux, Mac OS X и других операционных системах.

Является весьма популярным решением для «домашней» пользовательской виртуализации. Разрабатывается компанией Oracle.

Bochs Открытый монитор виртуальных машин второго типа [50]. Работает на Windows, Linux, Mac OS X и других операционных системах. Является популярным решением для поддержки выполнения программ, скомпилированных для IA-32, на архитектурах, отличных от IA-32.

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

Первой из метрик, учитывающей все три фактора, является демонстрируемая гостевым программным обеспечением скорость работы. Единицей измерения выступает IPS (англ. instructions per second). Однако важно при этом понимать, что для учёта влияния симуляции на скорость эта величина равна среднему числу гостевых инструкций, исполняемых за одну хозяйскую секунду. Чаще всего используют более крупные единицы, например, миллионы инструкций в секунду — MIPS.

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

Для приложений, производящих большое количество вычислений (например, задачи математического моделирования, решение задач уравнений математической физики и т.п.), применяется также другая метрика — FLOPS (англ. oating point operations per second), определяющая коНазначение и сценарии применения моделирования ЭВМ личество операций над числами с плавающей запятой (англ. oating point number), совершаемых за одну секунду. Допустимые форматы таких чисел (т.н. одинарная, двойная точность и т.п.) определяются стандартом IEEE 754-2008 [35].

1.8. Вопросы к главе Вариант 1. Определите понятие «функциональный симулятор».

2. Определите понятие «полноплатформенный симулятор».

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

a) Необходимость знать характеристики новой технологии как b) Необходимость выявления ошибок проектирования на ранних c) Большое энергопотребление реальных образцов.

4. Критерий изоляции исполнения гостевого приложения.

5. Как расшифровывается обозначение «RTL-модель» в контексте разработки аппаратуры?

b) Register transfer level.

c) Register-transistor logic.

6. Определение гипервизора первого типа.

7. Определение величины MIPS, используемой для измерения скорости 8. Какой из указанных ниже бенчмарков используется для оценки и сравнения эффективности работы систем виртуализации:

Вариант 1. Определение потактового симулятора.

2. Определение симулятора уровня приложений.

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

a) Большое число составляющих систему устройств со сложными b) Сложность получения лицензий на новое оборудование.

c) Обеспечение поддержки аппаратуры программными средствами 4. Перечислите стадии создания нового устройства с задействованием моделирования в правильном порядке.

a) Функциональная модель.

b) Разработка концепции устройства.

d) Потактовая модель.

e) Выпуск продукции на рынок.

f ) Экспериментальные образцы.

5. Определение гибридного симулятора.

6. Определение гипервизора второго типа.

7. Определение понятия FLOPS.

8. Определение понятия oating point number.

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

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

В любом классическом процессорном устройстве всегда присутствует регистр, хранящий адрес текущей исполняемой инструкции. Например, в архитектуре IA-32 [38] для этого используется семейство xIP: IP, EIP, RIP, в архитектуре ARM [70] он имеет название pc, в других системах он может называться по-другому, например, IC (англ. instruction counter). В дальнейшем для единообразия мы будем использовать обозначение PC (англ. program counter).

Кроме указателя инструкций, процессоры содержат множество других регистров, типы, назначение и параметры которых зависят от модели. В большинстве случаев присутствуют регистры общего назначения (англ. general Более детально об архитектурном состоянии рассказывается в главе 9; о создании потактовых моделей — в главе 8.

purpose registers, GPR), используемые в арифметических операциях и при адресации памяти.

В языке Си (и С++) описание состояния может быть представлено структурой state_t, содержащей поля для всех регистров, а также ссылки на внешние устройства:

typedef uint32_t register_t ; // ширина гостевых регистров const int n_regs = 16; // число регистров typedef struct { register_t pc; // счётчик инструкций register_t gpr[ n_regs ]; // регистры общего назначения uint8_t * memory ; // указатель на ОЗУ } state_t ;

Заметим, что данное описание очень далеко от того, чтобы быть полным, однако оно даёт базовое представление того, с чем приходится иметь дело в начале разработки новой модели.

2.2. Стадии работы Алгоритм работы в общих чертах напоминает стадии конвейера исполнения команд в настоящем процессоре (рис. 2.1).

Отметим, что число стадий может быть различно у разных моделей и варьируется от трёх до двадцати.

2. Модели процессора на основе интерпретации 1. Извлечение (англ. fetch) кода инструкции из памяти по адресу, вычисляемому из значения PC.

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

2. Задача декодирования (англ. decode) состоит в том, чтобы по числу, полученному в предыдущей фазе, определить, какую операцию следует выполнить и какие аргументы в ней будут участвовать. Например, число 0x706a в архитектуре IA-32 обозначает команду PUSH 0x70 — поместить в стек число 0x70.

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

Теория вопроса разбора выражений (англ. parsing) довольно детально разработана для языков высокого уровня и является «классикой»

computer science. Cм. также «Книгу дракона» [96].

3. Исполнение (англ. execute) состоит из непосредственной симуляции функции только что декодированной инструкции. Как правило, это вычисление результата арифметической или логической операции, изменение режима модели процессора или передача контроля управления в другую секцию алгоритма.

В модели каждому коду машинной операции (опкоду) должна соответствовать моделирующая процедура. Выбор нужной процедуры производится по опкоду:

4. Запись результата (англ. write back) операции в архитектурные регистры. Часть результатов также может быть расположена в оперативной памяти. Как и при её чтении (на этапе извлечения кода инструкции или получения входных операндов), при записи модель должна симуВ зависимости от того, используется ли гарвардская архитектура процессора или же архитектура фон Неймана, задействована или отдельная память инструкций, или общая память данных.

Конкретная формула зависит от деталей архитектуры и текущего режима устройства.

лировать все побочные эффекты.

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

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

const int instr_size = 2; // 16 bit CPU const int addr_mask = 0xffff; // mask overflowed bits state_t processor ; // our CPU processor.pc = ( processor.pc + instr_size ) & addr_mask ;

2.3. Простой пример Приведем пример интерпретационной модели простого процессора со следующей архитектурой.

Регистры • R0 — регистр общего назначения • R1 — регистр общего назначения • R2 — регистр общего назначения • IP — указатель команд Команды • ADD — сложение, можно прибавлять к регистру регистр или число • SUB — вычитание, можно вычитать из регистра число • LOAD — загрузка ячейки памяти в регистр • STORE — сохранение регистра в памяти Описание модели в псевдокоде struct DecodedInstr { enum Operation Op;

enum Argument Arg1;

enum Argument Arg2;

2. Модели процессора на основе интерпретации int R0, R1, R2, IP; // Модель регистров class Memory Mem; // Модель внешней памяти for (;;) { // бесконечный цикл int Instr = FetchInstr ();

struct DecodedInstr DecInstr = Decode (Instr );

Execute ( DecInstr );

int FetchInstr () { return Mem. Load32Bits (IP); // Загружаем 4 байта из памяти по адресу PC struct DecodedInstr Decode (int Instr) { switch (Instr) { // Перебираем все реализованные инструкции return {.Op = OP_ADD,.Arg1 = ARG_R0,.Arg2 = ARG_R0 };

case 1: // ADD R0,R return {.Op = OP_ADD,.Arg1 = ARG_R0,.Arg2 = ARG_R1 };

void Execute ( struct DecodedInstr DecInstr ) { int *Arg1, *Arg2; // Указатели на аргументы операции // Какой первый аргумент операции?

switch ( DecInstr.Arg1) { case ARG_R0 : Arg1 = &R0; break;

case ARG_R1 : Arg1 = &R1; break;

case ARG_R2 : Arg1 = &R2; break;

// Какой второй аргумент операции?

switch ( DecInstr.Arg2) { case ARG_R0 : Arg2 = &R0; break;

case ARG_R1 : Arg2 = &R1; break;

case ARG_R2 : Arg2 = &R2; break;

// Выполнить операцию switch ( DecInstr.Op) { case OP_ADD :

IP += 4; // Продвинуть указатель команд на следующую инструкцию case OP_SUB :

case OP_LOAD :

*Arg1= Mem. Load32Bits (* Arg2);

2.4. Исключения и прерывания Часто при обработке текущей инструкции возникает ситуация, когда нормальное её выполнение не может быть завершено, потому что были обнаружены недопустимые условия на входные операнды (например, целочисленное деление на ноль или недоступность памяти), или возникло какоето внешнее условие, требующее немедленной обработки. При этом архитектурное состояние процессора изменяется определённым способом (как правило, управление передаётся на обработчик возникшей ситуации), в том числе регистр PC начинает указывать на новый участок кода. Необходимость учитывать это оказывает соответствующее влияние на дизайн и реализацию модели.

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

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

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

2. Модели процессора на основе интерпретации Рис. 2.2. Рабочий цикл интерпретатора. Показана возможность возникновения исключительной ситуации на любой стадии симуляции • Синхронные с повторением текущей инструкции (промах, англ. fault) — событие, связанное причинно-следственно с выполнением текущей инструкции и обусловленное «неготовностью» среды исполнения к её успешному завершению. Примеры таких ситуаций: отсутствие физической страницы памяти с необходимыми данными; неготовность сопроцессора выполнять работу, т.к. он требует дополнительной инициализации. В этих случаях обработчик ситуации, находящийся в операционной системе, может модифицировать среду исполнения так, что завершение инструкции станет возможным, например, загрузить нужную страницу или включить сопроцессор. Дальнейшее возвращение на тот же PC с перезапуском инструкции позволит устранить проблему прозрачно для пользовательского приложения.

• Синхронные без повторения текущей инструкции (исключения, англ.

exception). Как и в предыдущем случае, событие порождено текущей инструкцией. Однако его обработка не подразумевает её повтора, так как причина события неустранима и не связана со средой исполнения, но связана только с самой операцией и операндами. Примеры: инструкция целочисленного деления на регистр, содержащий ноль, всегда будет давать ошибку; инструкция, запрещённая к выполнению в теИсключения и прерывания кущем уровне привилегий, не может быть на нём исполнена никогда.

Чаще всего (но не всегда!) исключения обозначают ошибку в программе. Управление после возврата из обработчика будет передано в место, не связанное с PC того кода, где произошло событие.

• Ловушки (англ. trap) также синхронны. При этом они обозначают явное «желание» программы быть прерванной и передать управление в определённую область кода — обработчик вызова. Примером является инструкция SYSCALL, вызывающая системные функции операционной системы, такие как работа с файлами, создание новых процессов и т.п. Другой пример — команда, предназначенная устройствусопроцессору, физически отсутствующему в системе, однако ОС умеет её эмулировать и таким образом способна вернуть правильный результат прозрачно для пользовательской задачи. С точки зрения прикладного ПО ловушка — это инструкция, семантика которой определяется не спецификацией ЦПУ, а используемой операционной системой и средой исполнения.

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

• Асинхронные прерывания (англ. interrupt). В отличие от всех ранее рассмотренных событий, они вызваны причинами, внешними по отношению к текущему контексту исполнения, и означают некоторое состояние внешней среды, требующее внеочередной обработки. Примеры:

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

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

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

2. Модели процессора на основе интерпретации Следует также отметить следующие особенности существующих систем.

1. Программное прерывание (англ. soware interrupt) — событие, вызываемое специальной инструкцией (например, в IA-32 это INT), обработка которого напоминает вызов процедуры. Т.е., несмотря на название, оно соответствует ловушке, а не прерыванию.

2. В некоторых архитектурах, например SPARC [83], подпрограммаобработчик синхронного события может сама выбрать, следует ли перезапускать текущую инструкцию. Для возвращения из подпрограммы-обработчика могут использоваться две различные инструкции — RETRY для перезапуска (в случае обработки промаха) и DONE для исполнения следующей команды за текущей (для выхода из обработки ловушек). Для поддержки такой возможности в архитектуру введён регистр nPC, в любой момент указывающий на следующую за текущей инструкцию.

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

Непредсказуемость их возникновения создаёт множество веток исполнения в структурированном коде, усложняя его структуру, а также негативно влияя на скорость исполнения.

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

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

Естественным способом передачи управления в такой ситуации является нелокальный «прыжок» — переход, использующий пару функций setjmp() и longjump(), описанных в стандарте библиотеки Си.

Функция setjmp сохраняет контекст в переменной env и возвращает 0, если выход из неё был после её прямого вызова. Если произошёл возврат из longjmp, то функция возвращает ненулевое значение.

Функция longjmp возвращает выполнение в точку вызова setjmp со значением val. При этом все объекты с неавтоматическим выделением памяти сохраняют своё значение.

Пример кода, использующего описанную функциональность:

# include # include static jmp_buf buf;

void second (void) { printf (” second \n”) ;/* печать на экран */ longjmp (buf,1); /* переходит по метке setjmp и возвращает код 1*/ void first(void) { second ();

printf (” first\n”) ;/* этой печати не произойдёт*/ int main () { if ( ! setjmp (buf) ) { first (); /* при исполнении вернёт код 0*/ } else { /* по возвращении из longjmp вернёт 1*/ printf (” main\n”) ;/* печать на экран*/ return 0;

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

Пример взят из Википедии: http://en.wikipedia.org/wiki/Setjmp.h.

Т.е. пересекающих границу отдельной процедуры.

Внутри одной процедуры.

2. Модели процессора на основе интерпретации 2.5. Преимущества и недостатки модели-интерпретатора Главным преимуществом рассмотренной схемы является её простота в реализации, модификации и отладке. Практически всегда в проектах по созданию программной модели нового процессора первым этапом является разработка интерпретационной модели, которая затем используется как эталон для тестирования последующих улучшений модели, оптимизирующих эффективность исполнения.

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

Однако не всегда транслятор быстрее интерпретатора. Как можно видеть из общего алгоритма работы (рис. 2.3), если приложение, которое исполняется на моделируемом ЦПУ, не содержит (или содержит мало) постоянных циклов, то транслятор будет все время обнаруживать «новый» код, что приведет к постоянным тратам времени на кодогенерацию.

По этой причине часто применяются гибридные модели ЦПУ, в которых присутствуют как интерпретатор, так и транслятор. Когда модель исполняет «незацикленный» код, работает интерпретатор. Как только обнаруживается «горячий», т.е. часто исполняемый, цикл, моделирование его выполняется транслятором [77].

2.6. Увеличение скорости работы Были разработаны многочисленные приёмы увеличения скорости интерпретации. Рассмотрим базовые идеи, используемые при этом.

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

2.6.1. Сцепленная интерпретация Одной из причин низкой скорости работы является неэффективное использование различных аппаратных ресурсов хозяйской системы, призванных уменьшить влияние явлений, разрушительных для конвейерной обработки. Так, из-за использования единого switch в теле цикла, из которого передача управления может быть осуществлена во множество мест, предсказатель переходов процессора не может каждый раз правильно предугадать адрес инструкции перехода, что вызывает сброс конвейера и задержку в несколько тактов. Этот негативный эффект проявляется в начале обработки каждой новой гостевой инструкции. Вместо концентрации условного перехода в одном месте желательно «размазать» его по многим местам в коде, уменьшив в каждом из них число вариантов адреса (в идеале — до одного). Этого можно достичь, если вызывать обработчик следующей инструкции сразу после конца работы текущей инструкции, без возвращения в общий цикл. Такой алгоритм интерпретации называется сцепленным (англ. threaded). Пример реализации в псевдокоде дан ниже. Предполагается, что этап декодирования уже проведён, и в памяти содержится информация о том, какой будет следующая инструкция.

// Массив labels содержит адреса переходов для всех обработчиков.

labels = [INSTR_A, INSTRb,... INSTR_X,... INSTR_Y...];

INSTR_X : // Текущая инструкция X X_handler (operands, PC); // обработчик инструкции goto label[PC]; // Сразу к обработчику новой инструкции 2.6.2. Интерпретация с кэшированием Промежуточным звеном между интерпретатором и транслятором является кэширующий интерпретатор. В нём вместо достаточно медленной отдельной фазы генерации кода используется только кэш (промежуточное хранилище с быстрым доступом) декодированных инструкций (рис. 2.4). Если он реализован эффективно, то решение будет сбалансировано: при исполнении зацикленного кода модель ЦПУ будет достаточно быстрой, а при исполнении линейного кода будет незначительно проигрывать простому интерпретатору, рассмотренному ранее.

2. Модели процессора на основе интерпретации 2.7. Модификация интерпретатора добавление новых инструкций Часто возникает задача расширения функциональности некоторой модели для представления функциональности нового процессора, отличающегося от старого наличием новых инструкций и дополнительных регистров процессора. Например, начиная с Intel Pentium IV в 2001 году были введены команды семейства SSE2, работающие с регистрами XMM0–XMM7.

Для того чтобы минимально модифицировать старый, хорошо отлаженный код модели, но при этом и поддержать новые системы, можно воспользоваться тем обстоятельством, что оригинальная модель не распознаёт новые инструкции как допустимые и должна вызвать обработку исключения #UD (англ. undened opcode). Однако, мы даём модели «второй шанс», вызывая второй декодер новых инструкций. Если он подтверждает, что может декодировать переданный ему машинный код, вызывается новая часть интерпретатора, ответственная за новый набор инструкций (рис. 2.5).

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

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

2.8. Заключительные замечания Проект Bochs [50] является хорошим примером зрелого интерпретатора, содержащего сложную модель процессора для существующей архитектуры IA-32. В технических заметках к программе [66] её авторы описывают множество полезных приёмов, применимых как к организации моделиинтерпретатора для процессора любой архитектуры, так и специфичных для архитектуры IA-32, являющейся одной из сложнейших в реализации.

Сгенерировать управляющий код Управление хранилищем кода Рис. 2.3. Алгоритм работы транслятора 2. Модели процессора на основе интерпретации Рис. 2.4. Схема работы кэширующего интерпретатора Рис. 2.5. Ступенчатая схема вызова декодеров при обнаружении инструкции, не поддерживаемой оригинальной моделью. При обнаружении в потоке инструкций машинного кода, не распознаваемого D1, управление передаётся на D 2. Модели процессора на основе интерпретации 2.9. Вопросы к главе Вариант 1. Какие из указанных ниже компонентов обязательны для реализации интерпретатора:

d) блоки реализации семантики отдельных инструкций, e) кэш декодированных инструкций.

2. Опишите, что происходит на стадии Fetch работы процессора.

3. Опишите, что происходит на стадии Writeback работы процессора.

Для каких инструкций эта стадия будет опущена?

4. Какой вид программ обычно исполняется в привилегированном режиме процессора?

5. Какие эффекты могут наблюдаться при невыровненном (unaligned) чтении из памяти в существующих архитектурах:

a) возникновение исключения, b) замедление операции по сравнению с аналогичной выровненной, c) данные будут считаны лишь частично, d) данные будут считаны по ближайшему выравненному адресу, e) возможны все перечисленные выше ситуации?

6. Какая из следующих типов ситуаций при исполнении процессора является асинхронной по отношению к работе текущей инструкции?

a) прерывание (interrupt), c) исключение (exception), 7. Выберите правильный вариант окончания фразы: Сцепленный интерпретатор работает быстрее переключаемого (switched), так как a) удачно использует предсказатель переходов хозяйского процессора, b) кэширует недавно исполненные инструкции, c) транслирует код в промежуточное представление, d) не требует обработки исключений.

Вариант 1. Какой из типов регистров всегда присутствует во всех классических архитектурах:

a) указатель стека, b) аккумулятор, c) указатель текущей инструкции, d) регистр флагов, e) индексный регистр.

2. Опишите, что происходит на стадии Decode работы процессора.

3. Опишите, что происходит на стадии Advance PC работы процессора.

Для каких инструкций эта стадия будет опущена?

4. Какой вид программ обычно исполняется в непривилегированном режиме процессора?

5. Почему самый простой вид декодера машинных инструкций — однотабличный — не пользуется большой популярностью?

6. Выберите правильные варианты окончания фразы: Наличие единственного switch для всех гостевых инструкций в коде интерпретатора a) увеличивает его скорость по сравнению со схемой сцепленной b) упрощает его алгоритмическую структуру по сравнению со схемой сцепленной интерпретации, c) уменьшает его скорость по сравнению со схемой сцепленной интерпретации, d) не влияет на скорость работы интерпретатора.

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

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

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

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

Подобный процесс получил собственное название двоичная трансляция (ДТ, также бинарная трансляция, БТ, англ. binary translation, BT) [12].

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

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

Практически все ЭВМ имеют команды для арифметических, логических и сдвиговых операций над целыми числами, и их эффективное моделирование в составе ДТ, как правило, тривиально.

Наборы инструкций над числами с плавающей запятой существенно различаются: они могут оперировать числами одинарной (32 бита) или двойной (64 бита) точности, могут быть в «экзотическом» формате, могут за одну инструкцию выполнять несколько операций (Intel® SSE, IBM AltiVec [65]); как другой вариант, они могут отсутствовать вовсе. Реализация математических операций над ними различается деталями алгоритма округления результатов, способами индикации ошибочных ситуаций, поведением для т.н. денормализованных (denormalized) чисел.

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

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

Сходства и различия в архитектурных состояниях Хранение состояния целевой системы в выделенном буфере памяти обладает недостатком — необходимостью часто обращаться к медленному ОЗУ Например, FPU-сопроцессор x87 архитектуры Intel использует внутреннее представление чисел, имеющее ширину 80 бит.

3. Улучшенные техники моделирования процессора и испытывать большие задержки при промахах кэша. Поэтому создатели систем ДТ стараются разместить максимально возможное число целевых регистров на хозяйских, чтобы при обращении к ним требовалось минимальное время. Это легко осуществить, если в архитектуре хозяина предусмотрено большее число регистров, чем необходимо гостю, например, в случае, когда гость — это IA-32 c 8 регистрами общего назначения, а хозяин — MIPS с регистром. В обратной ситуации приходится прибегать к различным ухищрениям, когда только часть регистров отдана под нужды симуляции (см. также главу 9).

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

Так, в архитектуре IA-32 полный адрес ячейки памяти может определяться 4 регистрами, описывающими сегмент, базу, индекс и масштабный коэффициент, и одним непосредственным операндом-константой, определяющей смещение. В системах с ЦПУ MIPS адресация использует один регистр и одну константу.

В противоположном случае память может адресоваться нулём операндов, т.е. неявно, например, располагаться на вершине стека.

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

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

Наличие и отсутствие различных режимов работы процессора В большинстве архитектур некоторая часть команд исполняется, только если процессор находится в одном из специальных, привилегированных режимов; как правило, в этом режиме работает операционная система. В архитектуре хозяина может просто не оказаться аналогичных инструкций ввиБлок памяти длиной w является выровненным по адресу A, если A = 0 mod w, т.е. A нацело делится на w.

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

Пример преобразования На рис. 3.1 приведён пример соответствия гостевой 64-битной инструкции процессора архитектуры Intel®EM64T и блока хозяйского кода (капсулы) хозяйского процессора, поддерживающего только 32-битные инструкции Intel®IA-32. Исполнение инструкции подразумевает чтение операнда из памяти с сопутствующей этому процедуре операции преобразования адресов. Затем с помощью двух 32-битных команд выполняется 64-битное сложение. Результат помещается в области памяти, хранящей архитектурное состояние моделируемого устройства; в данном случае на начало её указывает хозяйский регистр EBP, а смещения полей задаются константами времени компиляции RAX_OFF, RBX_OFF и т.п.

Рис. 3.1. Пример соответствия гостевой инструкции и хозяйской капсулы, эмулирующей её семантику и написанной на языке Ассемблера Для «идеального» ДТ для некоторой пары архитектур желательно выдерживать соответствие «одна хозяйская инструкция эмулирует одну гостевую» для каждой капсулы, однако по причинам, означенным выше, чаще встречаются две следующие ситуации.

1. На одну гостевую приходится несколько хозяйских инструкций, компенсирующих различия между их архитектурами.

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

3. Улучшенные техники моделирования процессора 3.1.2. Динамическая двоичная трансляция Какой должна быть единица ДТ? Другими словами, чем определяется количество и расположение целевых инструкций, обрабатываемых за один проход транслятора?

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

Первые сложности в случае с ДТ возникают из-за того, что входной текст — «монолитный» машинный код, не имеющий меток начала отдельных субъединиц, зачастую с перемешанными секциями кода и данными, неопределёнными адресами переходов и т.п. Возникает предварительная задача обнаружения кода (англ. code discovery).

Хотя аналогичная компиляции техника трансляции гостевого приложения целиком в образ хозяйского кода (статическая ДТ) иногда применялась [17], она не получила широкого распространения по ряду причин.

Будучи применимым для трансляции отдельных пользовательских приложений, статическая ДТ становится невозможной в случае полноплатформенной симуляции, при которой пришлось бы транслировать всю память гостевой ЭВМ. Во-первых, объём входного текста может быть огромен, и время трансляции, и размер результирующего файла будут непозволительно большими. Во-вторых, её содержимое часто меняется (см. также дальше параграф «Проблема самомодифицирующегося кода»), что делает статическую ДТ бессмысленной — результирующий код в силу своей статичности не будет отражать правильное состояние изменяемой памяти.

Более популярным, гибким и распространённым в настоящее время является другой подход — динамическая ДТ, при которой моделирование гостевой системы (то есть исполнение оттранслированного кода) перемежается с запусками механизма двоичной трансляции для новых блоков кода, которые будут вскоре исполненны, а также с обновлениями трансляций для блоков, изменивших своё содержимое. При этом в памяти симулятора хранятся ранее оттранслированные секции для их переиспользования в случае, если управление вновь перейдёт на них (рис. 3.2).

Память хозяйской системы ограничена, что возвращает нас к исходному вопросу — как выделять и организовывать блоки трансляций, чтобы получить приемлемую скорость симуляции, при этом не исчерпав ёмкость хозяйского ОЗУ? Кроме того, необходимо определиться, какие блоки хранить, а какие выбрасывать, какую длину в байтах они должны иметь. Рассмотрим два возможных решения этих задач, которые основываются на принципе локальности исполнения и ограниченности рабочего набора [71].

Рис. 3.2. Динамическая ДТ. Фаза симуляции, использующая сгенерированный код, хранящийся для некоторого числа гостевых страниц, периодически сменяется фазой трансляции, создающей код для отстутствующих секций гостевых программ 1. Трасса исполнения — это запись истории того, в каком порядке инструкции когда-то были исполнены. Из общих свойств алгоритмов следует высокая вероятность того, что впоследствии эти инструкции будут исполнены снова в том же порядке. При этом если они формируют базовый блок (т.е. среди них не встречается команд условного или непрямого перехода), то порядок их исполнения будет в точности такой же, как и в первый раз. Следует отметить, что первоначальное создание трасс, когда никакой истории исполнения ещё нет, приходится организовывать с помощью альтернативного механизма симуляции, например, интерпретацией (рис. 3.3). Прерывать создание трассы нужно по ряду условий в гостевом коде, после которых направление исполнения неизвестно или существенно отличается, например, на исключениях, прерываниях, командах смены режима процессора и т.п. Типичная трасса содержит до десяти инструкций.

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

Рис. 3.3. Двоичная трансляция целых страниц. Для ранее исполненных блоков переиспользуются оттранслированные секции хозяйского кода. Для новых процесс симуляции прерывается для ДТ новой страницы Хорошее описание приёмов ДТ, в ряде источников называемой JITкомпиляцией (англ. just in time), дано в [77].

3.2. Проблема самомодифицирующегося кода Большая доля современных архитектур процессоров для ЭВМ построена согласно принципам фон Неймана. Один из них состоит в том, что исполняемый код и обрабатываемые им данные располагаются в одной физической памяти. Следствие этого — возможность создания программ, которые в процессе работы изменяют код других программ и, в частности, свой собственный. Затем этот новый код может быть исполнен. Мы будем обобщёнПроблема самомодифицирующегося кода но обозначать такое явление, как самомодифицирующийся код (англ. selfmodifying code, SMC). Для программ с SMC не все инструкции приложения известны до момента их генерации во время работы уже запущенного приложения. Это обстоятельство фактически делает системы статической ДТ, не имеющие слой симуляции времени выполнения, функционально несостоятельными — они не могут корректно транслировать такой код.

Замечание. Симулятор, задействующий динамическую двоичную трансляцию, сам по себе является программой с самомодифицирующимся кодом, так как на фазе симуляции управление передаётся на код, отсутствующий в исходном файле приложения, — он был создан «на лету» на фазе трансляции.

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

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

Следует иметь в виду, что детали поведения процессора при SMC могут 3. Улучшенные техники моделирования процессора отличаться на разных архитектурах. Обусловлено это тем, что в реальности инструкции также берутся не непосредственно из памяти, а из более быстрых буферов, куда они были помещены специальными механизмами предварительной загрузки, и состояние памяти может не соответствовать их содержимому. Так, для систем с раздельными кэшами инструкций и данных (ARM, MIPS) результат модификации кода проявится только после выполнения специальных инструкций сброса кэшей. В архитектуре Intel®IA-32 гарантируется, что результат SMC будет виден для исполняющего устройства немедленно. Исключением является изменение инструкции непосредственно под указателем инструкций — оно не будет видно программе, пока текущая инструкция не закончится.

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

Ситуация усложняется, когда в моделируемой системе есть несколько агентов, умеющих модифицировать память, например, в многопроцессорных системах или в платформах, где устройства могут писать в память напрямую (direct memory access, DMA).

В таких случаях модель должна отслеживать все такие доступы и отбрасывать устаревшие блоки.

3.3. Прямое исполнение Интересным и важным на практике случаем ДТ является ситуация, когда архитектуры гостя и хозяина совпадают (или почти совпадают). При этом возникает возможность значительно упростить трансляцию — в некоторых случаях она сводится к копированию гостевого кода как хозяйского или даже исполнению его «на месте», без дублирования. Подобные режимы симулирования имеют общее название прямое исполнение (англ. direct execution, DEX).

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

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

• Доступы к памяти и периферии. Адресное пространство гостя занимает часть памяти симулятора и не обязательно размещено по тем же самым абсолютным адресам, где гостевое приложение ожидает его увидеть. ДТ поэтому должен перехватывать все доступы в память и «переписывать» их так, чтобы они всегда указывали на корректные данные и не могли повредить память самой модели. Аналогично, гостевое приложение не должно иметь прямого доступа к периферийным устройствам хозяина.

• Архитектурное состояние. Регистровый файл гостя и хозяина совпадает, поэтому невозможно полностью разместить гостевые регистры на одноимённых хозяйских — некоторое их количество зарезервировано для нужд самого симулятора. Опять же, гость не должен получать доступ к состоянию регистров, задействованных моделью, — необходимо перехватывать обращения к ним и подставлять правильные значения. Как правило, регистровый файл используется в двух переключаемых режимах: во время исполнения транслированного кода большая его часть заполнена состоянием гостя, а при выходе в симулятор оно сбрасывается в память, и регистры используются для нужд симулятора. По возвращении в транслированный код состояние восстанавливается.

• Привилегированные инструкции [59]. Будучи пользовательским приложением, симулятор работает в непривилегированном режиме, тогда как гостевое приложение может исполнять инструкции системных режимов. Без явного контроля со стороны ДТ это, скорее всего, приведёт к аварийному завершению процессов. Поэтому симулятор должен заранее находить в потоке команд гостя «опасные» инструкции и заменять собственными обработчиками. Альтернативно, иногда имеется аппаратно поддерживаемая возможность перехватить исключение от попытки исполнения привилегированной инструкции, промоделировать её в обработчике исключения и вернуться к исполнению.

Интересные особенности при этом существуют в архитектуре IA- — семантика некоторых инструкций меняется в зависимости от того, в каком режиме процессора они исполняются. Пример — POPF (англ.

pop ag register), которая модифицирует флаг Interrupt Enable, будучи исполнена в привилегированном режиме; в пользовательском режиме она может изменить все флаги, кроме вышеуказанного.

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

ЭВМ IBM System/370 была спроектирована таким образом, что позволяла исполнять напрямую приложения в изолированных контейнерах. В случае, когда встречалась привилегированная инструкция, она обрабатывалась симулятором (в терминологии System/370 — Control Program, CP) прозрачно для приложения.

Архитектура IA-32 довольно долгое время не имела эффективных механизмов поддержки изолированного исполнения приложений. Оно было реализовано (расширение Intel®VTx добавлено в 2005 г.; в настоящее время существует несколько версий этого расширения) в виде дополнительных режимов процессора и нескольких команд, позволяющих переходить между ними и стандартными, не виртуализационными режимами.

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

Введение аппаратно поддерживаемого прямого исполнения позволило ускорить обработку таких дорогих с точки зрения потребляемого на их симуляцию времени операций гостевых систем, как преобразование виртуальных адресов в физические преобразования TLB [21]. Такие операции могут производиться аппаратурой, а не программой хозяина, что также упрощает (и делает более надёжной) его реализацию.

Рис. 3.5. Аппаратная поддержка переключения контекста между монитором виртуальных машин и гостевой системой. При входе в режим виртуальной машины с помощью системной инструкции контекст хозяина сохраняется в выделенной области памяти и заменяется контекстом гостя. При любой причине обратного перехода в режим монитора (например, при попытке выполнить зарезервированную операцию) этот контекст обменивается с гостевым 3.5. Гиперсимуляция Как было показано выше, выигрыш в скорости от использования технологий ДТ обусловлен переиспользованием однажды сгенерированного хозяйского кода для многих последующих циклов симуляции; этот выигрыш теряется при несоблюдении условий постоянства машинного кода, как было показано в секции про SMC.

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

Рассмотрим такие случаи, когда архитектурное состояние при всех входах в некоторый блок кода остаётся неизменным. Исходя из свойства детерминистичности вычислительных систем, можно утверждать, что по выходу из такого блока состояние системы каждый раз будет одно и то же. Очевидно, что для таких участков кода нет нужды каждый раз их симулировать — достаточно один раз запомнить результат вычисления и просто изменять состояние системы после входа в блок на конечное, таким образом полностью 3. Улучшенные техники моделирования процессора избегая вычислений и достигая «бесконечно высокой» скорости симуляции (рис. 3.6).

Рис. 3.6. Гиперсимуляция. При обнаружении возможности симулируемое время проматывается вперёд до следующего события, состояние процессора при Описанные выше условия, налагаемые на код, очень жестки и на практике выполняются для очень небольших блоков. Пример — циклические блокировки в примитивах синхронизации, называемые «спинлупы» (англ. spin loop), встречающиеся в многопроцессорных системах. Алгоритм выглядит следующим образом:

while (* flag != 0) { ; // do nothing Здесь процессор непрерывно читает переменную flag до тех пор, пока она не перестанет быть равной нулю. Изменить её может второй процессор, разделяющий память с первым (о симуляции многопроцессорных систем см. главу 6).

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

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

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

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

Рассмотрим пример: моделирование загрузки операционной системы на архитектуре IA-32 с последующим запуском пользовательского приложения. На нём разберём, какие из изученных подходов оптимальны.

• В первые секунды работы, когда активна программа BIOS, процессор IA-32 находится в т.н. реальном режиме, исторически реализованным первым. При этом используется двоичная трансляция.

• Затем начинает загружаться операционная система. Режим процессора меняется на защищённый, и аппаратная поддержка прямого исполнения, недоступная для реального режима, может быть задействована. Используется прямое исполнение. На участках синхронизации с внешними устройствами может быть задействована гиперсимуляция.

• Запускается пользовательское приложение, активно использующее SMC. В таких условиях все «оптимизирующие» режимы теряют свои преимущества, и потому исполнение происходит с помощью интерпретации.

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

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

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

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

3.7. Пример практической двоичной трансляции Для иллюстрации того, насколько видоизменяется машинный код при трансляции, рассмотрим реальный пример работы Simics. Компилятор JIT в этом симуляторе производит несколько стадий преобразования промежуточного представления в конечный код, включая стадии распределения регистров и оптимизации полученного кода. Для ускорения симуляции эти шаги производятся статически, на этапе компиляции. Ниже приведены исходных гостевых инструкций процессора IA-32, а также результат их преобразования — 532 хозяйские инструкции для той же самой архитектуры.

3.7.1. Исходный блок инструкций simics > viper.mb.cpu0.core [0][0]. disassembleblock %rip Block 0 x111cb.. 0 x111fd matched. Compiled at 5176663075. Use count 532 host instructions / 16 target instructions (= 33.3).