Двоичный рекомпилятор — это компилятор , который принимает исполняемые двоичные файлы в качестве входных данных, анализирует их структуру, применяет преобразования и оптимизации и выводит новые оптимизированные исполняемые двоичные файлы. [1]
Основы концепций двоичной перекомпиляции были заложены Гэри Килдаллом [2] [3] [4] [5] [6] [7] [8] при разработке оптимизирующего транслятора ассемблерного кода XLT86 в 1981 году. [4] [9] [10] [11]
[…] "Если у вас нет схемы перевода, которая учитывает особые особенности целевого микропроцессора, автоматический переводчик не сможет работать", - объясняет Дэниел Дэвис, программист из
Digital Research
. "Вы получите прямую
транслитерацию
". […] Несмотря на все эти ограничения, в последнее время в разработке переводчиков был достигнут прогресс. В частности, Digital Research представила свой восьми- и 16-битный транслятор ассемблерного кода. На основе исследования, проведенного президентом Digital Research
Гэри Килдаллом
,
XLT86
, по-видимому, предлагает преимущества по сравнению с ранее доступной технологией программного транслятора. Подобно
Trans
от
Sorcim
и
Convert 86
от
Intel
, пакет Килдалла транслирует код на языке ассемблера с микропроцессора
8080
на
8086.
Однако Килдалл применил
глобальную технику анализа потока
, которая учитывает некоторые из основных недостатков других трансляторов. Процедура анализирует использование регистров и флагов в разделах кода 8080, чтобы исключить
несущественный код
. По словам программиста Digital Research Дэвиса, алгоритм, используемый Килдаллом, позволяет переводчику учитывать контекст при переводе программы. До сих пор одной из основных проблем любой программы-транслятора была неспособность программного обеспечения делать что-то большее, чем транслитерация. Если новый транслятор Digital Research действительно улучшит технологию до такой степени, что контекст можно будет учитывать, то на рынке микрокомпьютеров может появиться больше программных трансляторов.
В марте 1995 года
Ассоциация издателей программного обеспечения
посмертно почтила
Гэри
за его вклад в компьютерную индустрию. Они перечислили некоторые из его достижений: […] В 1980-х годах через
DRI
он представил двоичный рекомпилятор. […]
[…]
Роландер
: Я уже упоминал, что
Гэри
любил подходить к решению проблемы как архитектор. […] И он рисовал самые красивые изображения своих структур данных. […] И когда он закончил это […] и убедился, что структуры данных теперь верны, он входил в невероятный маниакальный режим кодирования. Он мог работать по 20 часов в день […] он просто исчезал в эти периоды времени. В паре таких случаев, когда он что-то запускал в первый раз, что могло происходить среди ночи. И все вы, кто писал программное обеспечение, видели, например, что когда оно впервые появлялось на экране, вы должны были кому-то об этом рассказать. Моя жена Лори скажет вам, что у меня было несколько таких звонков среди ночи,
LOGO
был одним из примеров,
XLT 86
был другим, когда он запустил его в первый раз, и ему нужно было, чтобы кто-то это увидел. Поэтому неважно, который был час, он звонил мне, я должен был прийти и посмотреть, как оно работает. […][2][3] (33 страницы)
[…]
XLT-86
— это аналитическая программа-транслятор, написанная на языке
PL/I-80
. Она считывает всю исходную программу
8080
, собирает ее в
машинный код
, анализирует использование регистров, памяти и флагов и выдает оптимизированную программу на языке ассемблера
8086.
[…] Трансляция программы выполняется в пять этапов. Сначала программа сканируется и собирается для получения значений и местоположений символов. Затем структура программы анализируется и разлагается на
базовые блоки
. В-третьих, основные блоки анализируются для определения
потока программы
и использования ресурсов. В-четвертых, данные
о структуре блока
и
распределении регистров
собираются в листинг для пользователя. В-пятых, информация о потоке и исходная программа используются для создания исходной программы 8086. […]
[…] Килдалл: […] Полтора года назад я, вероятно, тратил 75% своего времени на бизнес и 25% на программирование.
XLT-86
был продуктом, над которым я работал в то время, и мне потребовалось девять месяцев, чтобы сделать его. Это был бы трехмесячный проект, если бы я мог сосредоточиться на нем. […]
…] ПК: Каковы некоторые сложности, связанные с переводом программы из
формы 8080
в
форму
8086 ?
Килдалл
: Прямые
переводы на уровне исходной программы
можно выполнять практически механически. Например, инструкция 8080 «Добавить немедленно 5» превращается в «Добавить AL 5» на 8086 — очень простая трансляция самих кодов операций. Сложность
механической трансляции
возникает из-за таких ситуаций: инструкция 8080 DAD H берет регистр HL и добавляет к нему DE. Для 8086 эквивалентной инструкцией будет что-то вроде ADD DX BX, что нормально, никаких особых проблем. Вы просто говорите, что регистр DX такой же, как HL, а BX такой же, как DE. Проблема в том, что инструкция 8086 имеет побочный эффект установки флага нуля, а инструкция 8080 — нет. При механической трансляции вы в конечном итоге делаете что-то вроде сохранения флагов, восстановления флагов, выполнения некоторых сдвигов и поворотов и так далее. Это добавляет около пяти или шести дополнительных инструкций, чтобы получить тот же семантический эффект. В коде 8080 есть много последовательностей, которые производят очень странные последовательности в коде 8086; они просто не очень хорошо отображаются из-за регистров флагов и тому подобного. Способ, которым мы передаем программное обеспечение, называется
XLT-86
. Он вышел около шести месяцев назад. ПК: Под «лучшим» кодом вы подразумеваете меньший размер? Килдалл: На двадцать процентов меньше, чем если бы вы просто взяли каждый код операции и сделали прямую трансляцию, сохранив регистры для сохранения семантики. ПК: Каков размер транслируемой программы по сравнению с версией 8080? Килдалл: Если вы возьмете программу 8080, перенесете ее на 86-битную платформу и сделаете трансляцию XLT-86, вы обнаружите, что она примерно на 10–20 процентов больше. С 16-битными машинами сложнее решать все проблемы; вы получаете коды операций, которые в среднем немного больше. Интересное явление заключается в том, что одна из причин, по которой вы не получаете огромного увеличения скорости в 16-битном мире, заключается в том, что вы запускаете больше кодов операций по шине данных. […]