Поддержка системы команд THUMB в двоичной трансляции (1187412)
Текст из файла
Министерство образования и науки Российской ФедерацииМОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ(государственный университет)ФАКУЛЬТЕТ УПРАВЛЕНИЯ И ПРИКЛАДНОЙ МАТЕМАТИКИКАФЕДРА ТЕОРЕТИЧЕСКОЙ И ПРИКЛАДНОЙ ИНФОРМАТИКИ"03.04.01 Прикладные математика и физика"Поддержка системы команд THUMB в двоичнойтрансляцииМагистерская диссертациястудента 176 группыЗанегина Александра ГеннадьевичаНаучный руководительТормасов А.Г., д.ф.-м.н.г.
Долгопрудный2017СодержаниеСодержание2Введение31. Обзор существующих решений61.1 QEMU61.2 Houdini72. Архитектура системы команд Thumb3. Транслятор9183.1 Теоретическое основание183.2 Общая схема работы253.3 Особенности реализации поддержки Thumb374. Анализатор потока исполнения394.1 Описание анализатора394.2 Выбор структуры данных415. Измерение производительности43Заключение47Список литературы49ВведениеДанная работа посвящена увеличению производительности программнойвиртуальной машины Parallels ARM Emulator, разрабатываемой на кафедре.Основной задачей этого программного комплекса является предоставлениевозможности запуска и отладки программ, предназначенных для выполнения напроцессорах семейства архитектур ARM, на машинах с поддержкой архитектурсемейства x86. В рамках работы рассматривается поиск самых актуальныхнаправлений оптимизации, имплементация двоичной трансляции, а также ряднебольших улучшений, связанных с выбором структур данных и алгоритмов.Семейство процессорных архитектур ARM прочно занимает огромную долюрынка микропроцессоров для пользовательских устройств в течении уженескольких лет, в то время как x86 не теряет своих позиций.
[13] Производителиоперационных систем и конечных устройств поддерживают оба семействаархитектур, в том числе и в одних продуктах сразу. [14] Для того, чтобы успешноподдерживать свои продукты в условиях раздробленности парка устройств уконечных пользователей, разработчикам приложений приходится тратить кратнобольше ресурсов и времени на отладку. Программная виртуальная машинапозволяет сократить траты ресурсов в обмен на уменьшение скорости отладки,объем которого обратно зависит от качества виртуальной машины. Всовокупности, это показывает актуальность данной работы.Целью работы является улучшение скоростных характеристиквышеупомянутого программного комплекса виртуализации. Основной ориентиридет на скорость исполнения программ, собранных для работы под управлениемоперационной системы Android и среды выполнения Android NDK, однако это неявляется ограничением для рассматриваемой виртуальной машины илиприменяемых методик.Современные варианты ARM включают в себя поддержку двух архитектурсистемы команд: одноименной arm, с фиксированным размером инструкции 32бита, и Thumb, инструкции которой могут занимать либо 16, либо 32 бита.
Перваяимеет большую регулярность и выразительную способность инструкций, втораяжертвует этим в пользу высокой плотности кода. На аппаратном обеспечении, armпозволяет достичь большей производительности, однако высокие требования попамяти вынуждают разработчиков использовать Thumb вне критических участков.Так, Android NDK приложения и библиотеки по-умолчанию компилируются вThumb. Все это привело к выбору имплементации двоичной трансляции даннойсистемы команд как очевидного пути оптимизации.Под двоичной (бинарной) трансляцией машинного кода обычно понимаетсятехника виртуализации, включающая в себя модификацию машинного кода,исполняемого эмулируемой (гостевой) системой, заранее (Ahead-of-time, AOT) илиже непосредственно во время исполнения (Just-in-time, JIT, “на лету”).
Изначальноданная техника виртуализации была рассчитана на виртуальные машины, укоторых целевая (хост, реальная) архитектура системы команд совпадает сэмулируемой (гость, виртуальной), и была направлена на компенсацию некоторыхнедостатков классического trap-and-emulate метода. В таком варианте,модификации подвергались в основном операнды инструкций, такие как адреса впамяти или регистры. Главный недостаток классической виртуализации, который ипривел к созданию метода бинарной трансляции, это невозможность (либоабсурдные накладные расходы времени) аппаратного перехвата некоторых классовинструкций, например, требующих привилегированных режимов выполнения. Этолибо делает невозможным работу самого программного комплекса виртуальноймашины вне привилегированного режима, либо вынуждает использоватьмедленные и не всегда безопасные обходные пути.
Для виртуальных машин сразличающимися целевыми и эмулируемыми архитектурами систем команд этипроблемы тоже актуальны, так как различные процессорные архитектуры могутиметь неэквивалентные режимы привилегий. [2]Очевидно, что помимо трансляции адресов, сами инструкции тоже должныбыть модифицированы.
Алгоритмическая возможность отражения набораинструкций одной микропроцессорной архитектуры на другую в случае ARM и x86естественно вытекает из тезиса Чёрча и Тьюринг-полноты этих систем. Говоря отехнической возможности и эффективности данного подхода, необходимо помнитьо различающемся процессорном контексте. Отличия регистровых файлов, размеровслов, состояний контекста и механизмов адресации и исключений, создаютосновные сложности для трансляции.Главные накладные расходы по времени исполнения для механизма бинарнойтрансляции, это переключение между исполнением гостевого кода втрансляционном режиме и в режимом обычной эмуляции.
Необходимость такихпереключений возникает в нескольких случаях. Самый частый вариант, этовозникновение инструкции, для которой трансляция не определена, например,инструкции переключения режимов процессора. Однако важнейшим источникомпереключений для транслятора являются переходы между блоками транслируемогокода. [3]1. Обзор существующих решенийНа момент выполнения работы, автору известно о двух возможныхальтернативах разработанному программному комплексу. Первый и самыйважный, это проект с открытым исходным кодом Quick Emulation (QEMU).
[1]1.1 QEMUQEMU предлагает пользователям полную независимость от архитектуры, засчет системы промежуточного представления кода. Проект разделен на две части,фронт-энд - занимается обработкой эмулируемого кода и представлением его ввиде промежуточного кода, и бэк-энд, который компилирует промежуточный код,применяет оптимизации и отдает объектные куски на исполнение реальноймашины в её командах.Все это работает во время исполнения. В качестве бэк-энда QEMU используетне общедоступные наборы компиляторов, а специализированный: tiny codegenerator, что позволяет контролировать выходной поток инструкций в обмен наархитектурно-специфические оптимизации.Иллюстрация 1. Схема работы транслятора QEMUФронт-энд QEMU для трансляции инструкций гостевой архитектурыиспользует представление в виде микроопераций.
Микрооперации представляютсобой специфический вариант низкоуровневого языка с простой трехоперанднойадресацией и огромным набором временных регистров.Помимо микроопераций, разработчики QEMU используют специальныевспомогательные прекомпилированные функции для обработки “сложных”инструкций.Проект предлагает как полную эмуляцию всей системы, так и эмулированиеисключительно пространства пользователя. Для обоих вариантов эмуляции, QEMUпредлагает отладочные инструменты в виде интерфейса для отладчика GNUDebugger (GDB).Как будет видно позднее, несмотря на большие возможности и поддержкуоткрытого сообщества, для заявленных целей Quick Emulation обладает слишкомнизкой производительностью.1.2 HoudiniВторой альтернативой является проприетарная библиотека Houdini,предоставляемая Intel производителям устройств на операционной системе Androidи микропроцессорах архитектуры x86 для установки в качестве слоясовместимости между Android NDK и пользовательскими приложениями, которыене имеют собранных под архитектуру x86 исполняемых файлов и библиотек впакете приложения.Документация для libhoudini практически отсутствует в открытом доступе.Известно, что libhoudini используется нативной Java виртуальной машинойAndroid в качестве бэкэнда при невозможности разрешить пути до библиотек x86 вфайле приложения.Модули libhoudini для сравнения производительности были получены изпроекта Android x86.Различные эксперименты, в том числе проведенные внутри компании ARM,так и независимой группой специалистов из Китая, показывают потерюпроизводительности от 40% до 90% между использованием libhoudini длятрансляции и использованием библиотек специально собранных под архитектуруx86.
[14]2. Архитектура системы команд ThumbARM (v7) является архитектурой с сокращенным набором команд (ReducedInstruction Set Computer, RISC). Размер машинного слова составляет 32 бита,размер команды фиксирован и вмещается в слово или половину слова. Обычныеинструкции принимают в качестве операндов только регистры и непосредственночисла.
Работа с памятью осуществляется при помощи специализированныхинструкций. [12]Важным аспектом данного набора команд является возможность условноговыполнения практически любой инструкции. Первые четыре бита кодируютусловие относительно флагов состояния процессора, которое декодер сверяет длякаждой загруженной команды.Все это позволяет набору команд arm достигать высокой производительностии относительной простоты реализации в аппаратном виде.
В качестве стороннегоэффекта это значительно облегчает эмуляцию по сравнению с x86 архитектурой.Однако, огромные затраты вторичной памяти на приложения вынудилиинженеров создать альтернативу в виде архитектуры системы команд Thumb, и вдальнейшем, расширение Thumb-2.Все инструкции первой версии этого набора команд имели размер в половинумашинного слова (за исключением инструкции условного перехода, котораявыполняется в два такта). По сути они являлись сокращениями наиболее частоиспользуемых инструкций оригинального набора.Возможность условного исполнения каждой инструкции также отключенадля Thumb.
Начиная со второй версии расширений, она заменена специальнойинструкцией IT (If-Then), которая использует контекст процессора для условноговыполнения до четырех последующих за ней инструкций.if ConditionPassed() thend = UInt(Rdn);n = UInt(Rdn);m = UInt(Rm);(shift_t, shift_n) = (SRType_LSL, 0);setflags = !InITBlock();shifted = Shift(R[m], shift_t, shift_n, APSR.C);(result, carry, overflow) = AddWithCarry(R[n], shifted, APSR.C);if d == 15 then// Can only occur for ARM encodingALUWritePC(result); // setflags is always FALSE hereelseR[d] = result;if setflags thenAPSR.N = result<31>;APSR.Z = IsZeroBit(result);APSR.C = carry;APSR.V = overflow;Листинг 1.
Характеристики
Тип файла PDF
PDF-формат наиболее широко используется для просмотра любого типа файлов на любом устройстве. В него можно сохранить документ, таблицы, презентацию, текст, чертежи, вычисления, графики и всё остальное, что можно показать на экране любого устройства. Именно его лучше всего использовать для печати.
Например, если Вам нужно распечатать чертёж из автокада, Вы сохраните чертёж на флешку, но будет ли автокад в пункте печати? А если будет, то нужная версия с нужными библиотеками? Именно для этого и нужен формат PDF - в нём точно будет показано верно вне зависимости от того, в какой программе создали PDF-файл и есть ли нужная программа для его просмотра.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
