Доброго времени суток.

Сегодня мы будем смотреть дизассемблированный код инструкций if, for, while, swich, которые написаны на языке Си.

Инcтрукция if

Данную инструкцию довольно просто отличить в дизассемблированном виде от других инструкций. Её отличительное свойство - одиночные инструкции условного перехода je, jne и другие команды jump.

Напишем небольшую программу на языке Си и дизассемблируем её с помощью radare2. Разницы между IDA PRO и radare2 при дизассемблировании этих программ не было обнаружено, поэтому я воспользуюсь radare2. Вы можете использовать IDA PRO.

IDA PRO

radare2

Код на Си

#include <stdio.h>void main() {    int x = 1;    int y = 2;    if(x == y) {        printf("x = y\n");    }    else{        printf("x != y\n");    }}

Компилируем при помощи gcc. Команда gcc -m32 prog_if.c -o prog_if. -m32 озночает, что компилироваться код будет под архитектуру x86.

Чтобы посмотреть на код в radare2, напишем команду r2 prog_if. Далее прописываем aaa для анализа кода и переходим к функции main s main. Посмотрим на код с помощью команды pdf.

Дизассемблированный вариант в radare2

Первым делом в программе происходит объявление переменных ( int x; int y ), а затем значение 1 перемещается в varch (это переменная x) и значение 2 в var10h (это переменная y). Далее идёт сравнение (cmp) 1 и 2 (cmp edx, dword [var_10h]). Эти значения не равны. Значит jne ( jump if noe equal) перейдёт по адресу 0x000011e1. Проще всего инструкцию if запомнить и опрелелить в режиме графов (команда VV для для radare2 или клавиша пробел для IDA).

Режим графов

Немного усложним задачу. Добавим вложенные инструкции. Попробуйте проанализировать этот код.

Код на Си

#include <stdio.h>void main() {    int x = 0;    int y = 1;    int z = 2;    if(x == y) {        if(z == 0) {        printf("z = 0; x = y\n");        }        else{            printf("z = 0; x != y\n");        }    }    else {        if(z == 0) {            printf("z = zero and x != y.\n");        } else {            printf("z non-zero and x != y.\n");        }    }}

Дизассемблированный вариант в radare2

Режим графов

В режиме графов это воспринимать намного проще.

Инструкция for

Циклы for всегда состоят из четырех этапов: инициализации, сравнения, выполнения инструкций и инкремента/декремента. По этим четырём этапом мы будем распозновать for в ассемблерном коде.

Код на Си

#include <stdio.h>void main() {    int x;    for(x = 0; x < 100; x++) {        printf("x = %d", x);    }}

Дизассемблированный вариант в radare2

1 - инициализации переменной var_ch (x = 0)
2 - сравнение, а затем jle. ( пока x не будет меньше или равен 2, выполнять цикл.)
3 - выполнения инструкций (printf)
4 - инкрмент переменной var_ch (++x)

Режим графов

Инструкция while

Цикл while часто используется при ожидании, пока не будет выполнено какое-то условие, например получение команды или пакета. В ассемблере циклы while похожи на for, но их легче понять. В ассемблере это выражение похоже на цикл for, но инкремента может и не быть.

Код на Си

#include <stdio.h>int func_1(int x);int change_status();int main() {    int status = 0;    while(status == 0) {        printf("int e = %d", func_1(5) );        status = change_status();    }    return 0;}int change_status() {    return 1;}int func_1(int x) {    int c;    int e;    int l;    c = 1 + 2;    e = x / 5;    l = 4 - 2;    return e;}

Дизассемблированный вариант в radare2

1 - инициализации переменной var_4h (status = 0)
2 - сравнение, а затем je. ( пока x равен 0, выполнять цикл.)
3 - выполнения инструкций (func1, printf, change_status)

Режим графов

Инструкция switch

Конструкция switch обычно компилируется двумя способами: по примеру условного выражения или как таблица переходов.

Компиляция по примеру условного выражения

Код на Си

#include <stdio.h>int main() {    int i = 3;    switch(i) {        case 1:            printf("CASE_1 i = %d", i+4);            break;        case 2:            printf("CASE_2 i = %d", i+9);            break;        case 3:            printf("CASE_3 i = %d", i+14);            break;    }    return 0;}

Дизассемблированный вариант в radare2

1 - инициализации переменной var_4h (i = 3)
2 - выполнения инструкций (add, printf)

Чтобы понять какой "case" выбран, происходит сравниение (cmp, а затем je, jne) переменной i с значением case.

Режим графов

Глядя на этот код, сложно (если вообще возможно) сказать, что представлял собой оригинальный исходный текст конструкцию switch или последовательность выражений if . В обоих случаях код выглядит одинаково, поскольку оба выражения используют множество инструкций cmp и je или jne.

Таблица переходов

Следующий пример ассемблерного кода часто можно встретить в больших смежных выражениях switch. Мы добавим case 4 и инструкцию по умолчанию.

Код на Си

#include <stdio.h>int main() {    int i = 3;    switch(i) {        case 1:            printf("CASE_1 i = %d", i+4);            break;        case 2:            printf("CASE_2 i = %d", i+9);            break;        case 3:            printf("CASE_3 i = %d", i+14);            break;        case 4:            printf("CASE_3 i = %d", i+19);            break;        default:            break;    }    return 0;}

Дизассемблированный вариант в radare2

1 - инициализации переменной var_4h (i = 3)
2 - выполнения инструкций (add, printf)

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

Режим графов

Режим графов - ваш друг в дизасcемблировании :)

На этом всё. Рекомендую попробовать самому написать программы на Си, скомпилировать и изучить дизасcемблированный код. Практика и ещё раз практика!

Спасибо за внимание. Не болейте.

Вы когда-нибудь задумывались, как много вокруг умной электроники? Куда ни глянь, натыкаешься на устройство, в котором есть микроконтроллер с собственной прошивкой. Фотоаппарат, микроволновка, фонарик... Да даже некоторые USB Type C кабели имеют прошивку! И всё это в теории можно перепрограммировать, переделать, доработать. Вот только как это сделать без документации и исходников? Конечно же реверс-инжинирингом! А давайте-ка очень подробно разберём этот самый процесс реверса, от самой идеи до конечного результата, на каком-нибудь небольшом, но интересном примере!

Идея

Меня давно манила шина PCI Express. Сами посудите - высокие скорости, DMA доступ к памяти компьютера, множество разнообразных устройств и производителей, тонна стандартов и реализаций. Что, если взять некоторое PCI-E устройство и переделать прошивку так, чтобы в процессе работы параллельно ещё и читать/писать ОЗУ компьютера по своему желанию?

Вы скажете - но есть же готовые решения, например, PCI Leech и Thunderclap. Но PCI Leech не умеет работать как "обычное" устройство, а Thunderclap, хоть и имитирует сетевую карту, но базируется на громоздкой и дорогущей FPGA девборде. По моей же задумке, устройство должно корректно определяться драйверами в любой системе и при этом недорого стоить.

Такое устройство можно использовать, к примеру, в качестве аппаратного отладчика x86 - имея возможность чтения и записи ОЗУ, разрабатывать драйвера для BIOS "на коленке" гораздо проще.

Выбираем подопытного

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

Либо выглядели настолько сложно, что перспектива реверса такого монстра просто пугала:

Мне же требовалось устройство, которое имеет:

• встроенный мощный микроконтроллер

• легко перепрограммируемое ПЗУ

• отладочные интерфейсы (UART, JTAG)

• встроенную прошивку (а не загружаемую драйвером)

Ну и в добавок, это должно быть широко поддерживаемым всеми системами устройством, например, SATA или USB контроллером. И, как вы уже догадались из названия статьи, недавно я наткнулся на вот такой SATA контроллер:

А именно, меня привлекла крайняя простота контроллера (только проц, да ПЗУ) и радиатор на нём (а значит внутри мощный CPU!). Быстрый поиск по названию чипа ещё больше подогрел к нему интерес. Найденная прошивка для него весила аж 500 КБ, имела признаки ARM кода, не была пожата, и имела достаточно текстовых отладочных строк:

И на него была некоторая документация, в которой очень много выводов было не подписано, что давало шанс на наличие отладочных интерфейсов:

В скором времени контроллер был куплен, и я взглянул на него повнимательнее:

Контроллер действительно выглядел очень просто и перспективно. Но более подробное изучение даташитов показало, что NC пины - на самом деле NC, и отладки на нём ждать не стоит. Более продвинутый контроллер с поддержкой как SATA, так и IDE, ровно в таком же корпусе имел на этих выводах дополнительные сигналы:

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

То, что производитель просит не подключать TST2-TST6 ну очень намекает на наличие JTAG, а прямое указание UART на TST0 и TST1 (в другом даташите) это уже джекпот. Засим было решено купить 88SE9215 как самый недорогой из доступных, и издеваться уже над ним:

Проверяем работоспособность

И вот объект изучения у нас в руках, первым делом проверяем, что он работает. Это важный момент, именно тут мы устраняем возможные будущие вопросы "Это я сломал или оно и было нерабочим??"

Для этого мне пришлось купить M2 райзер, поскольку единственный PCI Express слот моего ПК занят видеокартой:

В общем, тест прошёл успешно, я даже установил систему на HDD, подключенный к этому контроллеру, всё подцепилось стандартными драйверами:

При запуске ПК мелькает информация о состоянии контроллера, это PCI Option ROM и по идее из этого меню можно что-то настраивать, но мне никак не удалось зайти в настройки:

Анализируем компоненты

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

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

Что-то первое попавшееся из гугла для примера

Точное назначение и тип компонентов узнаём по маркировке и даташитам. В нашем случае список компонентов довольно небольшой:

Получаем прошивку

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

Обычно прошивку можно получить тремя способами, это:

• обновления от производителя

• программатором из ПЗУ / контроллера

• по отладочным интерфейсам из устройства

В сети прошивка для моего контроллера нашлась на сайте station-drivers, впрочем, оттуда же я брал прошивку и для предыдущего купленного контроллера. Несмотря на то, что это .exe файл, 7-zip его прожевал, и внутри обнаружились .bin файлы самой прошивки:

Я скачал все прошивки, что только смог найти в сети, в том числе и для похожих контроллеров, и это тоже дало результаты - в одном из архивов обнаружился Readme с описанием чтения ПЗУ:

Но для этого нужно было готовить загрузочную DOS флешку, поэтому я просто считал ПЗУ программатором, благо здесь стоит типичная SPI Flash. Самый простой способ - клипсой. Цепляемся к ПЗУ и пытаемся читать:

И в два клика ПЗУ определилось и прочиталось программатором:

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

Анализируем прошивку

В качестве объекта для анализа я взял скачанную с сайта прошивку (чтобы начать исследование ещё до того, как купленный контроллер приедет ко мне). Первым делом нужно определить структуру образа прошивки. При беглом просмотре сразу видно, что большую часть образа занимает пустое место, а полезные данные начинаются на некоторых адресах, кратных 0x1000. И по адресу 0x2000 видим достаточно интересный набор данных:

Ну вот, за нас даже структуру прошивки расписали! Итак, согласно описанию, в образе мы имеем:

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

Также полезно разбить прошивку на части и прогнать их через cpu_rec, чтобы знать, с какой программной архитектурой имеем дело. Ещё в начале статьи я предположил, что контроллер должен иметь архитектуру ARM, ну а Option ROM должен быть архитектуры x86, поскольку исполняется он на хосте. Проверим это:

А вот теперь возьмёмся за реверс. Начнем с Loader - он ARM архитектуры и имеет небольшой размер. Скорее всего с него контроллер начинает загрузку. Попробуем его загрузить в дизассемблер:

И видим, что первые инструкции выполняют прыжки на адреса 0xFFFF00**, а это значит, что либо контроллер первым делом при старте прыгает в Mask ROM по адресу 0xFFFF0000 (что сомнительно), либо код Loader сам грузится в этот адрес. Перезагружаем код в дизассемблер по 0xFFFF0000 и действительно, всё корректно парсится:

Функций здесь очень немного (целых четыре), и выяснить что делает код не представляет труда:

• По адресу 0xF8064000 код обращается к содержимому ПЗУ

• В ПЗУ происходит поиск сигнатуры "MAGIIMGF"

• Блок данных с этой сигнатурой парсится и раскидывается по ОЗУ

• Происходит запуск основной системы прыжком по адресу 0

И да, именно с сигнатуры "MAGIIMGF" начинается Firmware, который мы вырезали ранее! Немного проанализировав загрузчик, получаем вот такой формат блока прошивки:

И теперь мы можем распарсить Firmware и правильно прогрузить его в дизассемблер! Ожидаемо всё идеально прогружается и можно начать анализ основной системы:

Основная задача реверс-инжиниринга - дать имена функциям и понять, что происходит в коде. В этом нам помогут:

• часто вызываемые стандартные функции (malloc, memset, memcpy)

• текстовая отладочная информация из прошивки

• различные уникальные константы

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

А здесь явно происходит инициализация последовательного порта:

Кстати, немного проанализировав задачи инициализации системы, можно наткнуться на функцию, которая принимает указатель на другую функцию и некоторое имя. Очень похоже на запуск новой задачи! Так и назовём:

В процессе изучения кода задач натыкаемся на интересную функцию, которой часто передаются красивые десятичные значения (100, 1000)... И это очень похоже на функцию задержки исполнения, sleep:

Судя по числам, наш процессор работает на частоте 300 MHz - неплохо так. А ещё из этой функции получаем очень важную информацию - по адресу 0xD0020314 расположен системный таймер. Попытки поискать этот адрес в сети привели к очередному успеху - PDF с детальным описанием другого процессора Marvell:

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

Этой функцией контроллер взаимодействует с ПК, к которому он подключен. Достаточно задать нужный адрес в аппаратных регистрах транслятора, и чтение/запись в пределах заданного "окна" по адресу 0x40000000 автоматически приведут к чтению/записи физической памяти ПК!

Теперь осталось найти, как взаимодействовать с прошивкой и подавать команды извне, внедрить в прошивку свой код, который будет лезть в ОЗУ компьютера и ... готово?

Ищем отладочные интерфейсы

Надоело смотреть на скриншоты ассемблерного кода? Возвращаемся к железякам! У нас есть набор тестовых контактов, но мы не знаем, где на них какие отладочные интерфейсы (и есть ли они там вообще). Сначала нужно что? Правильно, подпаяться к ним и вывести на гребёнку:

Производитель совсем не заботится о глазах реверс-инженеров, нет бы хоть пятаки сделать!

А дальше - подключаем прибор для поиска JTAG, подрубаем питание и вперед!

Ииии ничего не нашлось:

Ожидаемо, подумал я, и вспомнил про пин "TESTMODE" из даташита. Вероятно, его нужно задействовать и тогда.... Что-ж, паяем ещё проводков, ставим подтяжку на TESTMODE:

Иии снова ничего не нашлось, правда, картина немного иная, почему-то всё стало Input:

Да что ж такое, ну ладно JTAG, хотя бы UART найду, подумал я. Подключаем логический анализатор...

И не видим признаков UART ни на одном выводе...

А с поднятым TESTMODE, тест выводы и вовсе колбасит по-черному, и это точно не UART:

Ну, думаю, он просто выключен в прошивке. Нужно его включить! Вношу небольшие изменения и сталкиваюсь с тем, что через клипсу прошивка не хочет записываться. Контроллер питается от программатора и мешает записи. Да что за день-то такой?! Психанул, сделал ПЗУ съёмной:

Но никакие мои попытки включить UART не привели к результатам. Вообще никак, хоть убей. И тут я вспомнил один факт, на который я поначалу не обратил внимания. В прошивке с сайта ARM код был, а в прошивке, что я считал программатором - был только код BIOS. Я посчитал, что добавления ARM кода хватит для того, чтобы контроллер его подхватил и запустился. В общем, возник вопрос, а грузится ли прошивка вообще??

Для этого я подключил логический анализатор прямо к SPI микросхеме:

И проанализировал чтение флешки по SPI:

И да, читался только неведомый Autoload (причём трижды) и BIOS! Загрузчик и прошивка и не думали грузиться! Я наконец понял, что мой контроллер имеет только функциональность SATA, а прошивка нужна для RAID, который у меня не поддерживается..

В отчаянии, используя SPI логи, я разреверсил формат Autoload, он оказался очень простой:

Сначала сигнатура (0xA5A5A5A5), дальше пары адрес/значение, в конце сигнатура окончания (0xFFFFFFFF). Я подумал, а вдруг эти данные загружаются встроенным микроконтроллером. Тогда, испортив ему стек и адрес возврата из функции, мы перехватим управление и прыгнем на внешний загрузчик. И как только процессор прыгнет на адрес ПЗУ - мы это увидим в логе SPI, произойдёт чтение!

Я собрал Autoload, в котором во все возможные адреса стека записывался адрес ПЗУ (0xF8064000), запихнул на флешку и... Эта зараза прожевала все 128 КБ и не подавилась, дважды!! (первый раз подавилась, похоже, по таймауту)

Короче, я сдался. Похоже, нет внутри 88se9215 чипа ARM контроллера, и мне нужен 88se9230 чип. Нет слов. Купил 9230 и ... поехали всё заново, что поделать!

В общем, да. На 9230 JTAG нашёлся с пол-пинка и даже без TESTMODE пина:

Кстати, в этом самом TESTMODE неслабо колбасит вообще все пины (как TST, так и GPIO), чип выводит на каждый из них некоторую частоту:

Ладно, у нас теперь хотя бы JTAG есть. Продолжаем эпопею!

Играемся с JTAG

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

Подключаем JTAG программатор к только что найденным пинам...

Пишем небольшой скрипт для OpenOCD с одним ARM ядром

interface usb-sreset_config trst_pulls_srst trst_push_pulladapter_khz 2000telnet_port 4444gdb_port 3333jtag newtap marvell cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x140003d3target create core feroceon -chain-position marvell.cpu 

И подключаемся к контроллеру:

Наконец можно проверить, работает ли маппинг памяти! Запускаем UEFI Shell с флешки, читаем адрес 0x100000000:

Теперь по JTAG из контроллера мапим этот же адрес и перезаписываем содержимое:

И проверяем из UEFI Shell:

Оно работает! Мы действительно можем перезаписывать оперативную память ПК из SATA контроллера! Теперь нужно включить UART, чтобы потом по нему принимать управляющие команды. Из реверса я нашёл, что чтобы вывести символ в UART, нужно записать в регистр 0xD0072000. Но как я ни записывал в него, на анализаторе ничего не происходило.

С помощью отладки по JTAG выяснилось, что до инициализации UART дело не доходит:

Регистр 0xD0071054 имеет значение 0x3F, а для инициализации UART нужно значение 0x2F:

Банальное повторение всего того, что делает процедура serial_init, не помогло, UART не завёлся. Пришлось исследовать более детально. На тот же самый регистр 0xD0071054, по которому код решал, включать UART или нет, ссылалась и другая процедура, i2c_init, только она уже реагировала на значение 1:

Но подождите-ка, на нашей плате пины TST0 и TST1 идут как раз к посадочному месту будто бы под i2c флешку:

А значит, должен быть способ переключить регистр 0xD0071000 (точнее его биты 4-5, которые проверяются в этих функциях) хотя бы в положение "1". И на плате, похоже, для этого предусмотрительно оставлены места под резисторы "на землю" возле некоторых GPIO. А ну-ка подтянем GPIO4 на землю (чтобы в 0x3F обнулить бит 4), не зря же мы все GPIO распаяли:

Читаем снова по JTAG и видим, что изменился регистр, правда не тот, но обнулился нужный бит!

Уже хоть что-то! Попадание совсем рядом. Значит это действительно GPIO. А что если включить контроллер с уже замкнутым GPIO? Может, регистр 0x54 показывает состояние GPIO на момент начального включения? Перезагружаем контроллер:

И да, так и оказалось, эти регистры отвечают за конфигурацию и состояние GPIO. Теперь у нас должен быть инициализирован UART, записываем в 0xD0072000 значение 0x30 иии:

Есть UART! RxD на TST0 и TxD на TST1

Более того, подключаем USB-UART адаптер и видим:

FW version 2.3.0.1041 Built: 18:55:01 Jul  4 2012Interrupt initialization.PUNIT initialization.Scratchpad RAM initialization.SPD RAM @ 0x30060280 with 130432 bytes.Entering dma_init.Leaving dma_init.ide_fifo_init_moduleMagni device id: 9230, rev: 60ide_host_init.IDE host allocates 16896.ahci_host_init.Gigabyte early post spd: 20Console initialization.CORE initialization.Backend CCCS  not supported.Core allocated 26624 bytes.No supported I2C(2).spi_init.SPI device: mxic 25l4005 detected.SPI size:80000SPI block size:1000mv_init_phy_tuning.No phy_tuning this page. Using default value.mv_init_modifing_vdname.No modifying_vdname this page.mv_init_aes_page.raid_inithd_info.flag = 0init req_ct_pool_buf(dtcm), size : 1280init req_ext_ct_pool_buf(sram), size : 5376Free 2080 size, initialization done!Front thread started.Backend thread started.Starting AHCI controller.AHCI controller started.Set BGA Buffer to SRAM memory, 0x1000 bytesraid_init_work_queue, raid_bga_next_handlerport 7 Auto-fetch enableconsole device: 12 mapping to vportid: 7

Теперь осталось запрограммировать команды и реакцию на них

Расширяем функциональность прошивки

Для начала, напишем довольно простой код, который выдаёт обратно всё, что мы ввели в терминал. В качестве буфера используем верхнюю половину буфера, что прошивка использует под sprintf.

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

asm("B mainCycle");asm(  "get_char:\n\t"  "LDR R12, =0x30042695\n\t"  "BX R12\n\t"  );asm(  "put_s:\n\t"  "LDR R12, =0x300426A9\n\t"  "BX R12\n\t"  );  void mainCycle (){char c;char * in_buffer = (char *)0x30059CB8;int in_max_size = 0x80;int buf_ptr = 0;while(1){c = get_char();if (c == 0x0A || c == 0x00)continue;if (c != 0x0D && buf_ptr >= in_max_size)continue;in_buffer[buf_ptr++] = c;if (c == 0x0D){put_s(in_buffer);buf_ptr = 0;}}}

Чтобы скомпилировать код под ARM, нам понадобится GCC. Возьмём его из ARM GNU Toolchain

Поскольку нужно скомпилировать совсем сырой бинарь, добавляем опцию -nostdlib, а после сборки преобразуем полученный файл в binary формат:

arm-none-eabi-gcc.exe echo.c -nostdlib -O2 -o echo.out

arm-none-eabi-objcopy.exe -O binary echo.out echo.bin

К счастью, ARM код (по большей части) использует относительные адреса, поэтому с линковкой по нужному адресу не заморачиваемся. По-хорошему нужно явно указать компилятору, по какому адресу будет расположен код директивой -Wl,--section-start=.text=0x30400000 (последнее - требуемый адрес)

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

Нам пока хватит, если что, поищем другое место. Вставляем код по адресу 0x30054EB0 и меняем адрес Idle задачи на этот:

А вот чтобы перешивать контроллер программатором (не делать же снова "внешнее ПЗУ") делаем аппаратную хитрость - "изолируем" питание ПЗУ диодами так, чтобы при подключении клипсы питание не уходило на контроллер:

Проверяем и вроде бы работает, после ввода строки и нажатия Enter, в терминал выводится наша введенная строка:

Наконец, запрограммируем чтение ОЗУ компьютера! Заодно поправим недостатки, а именно, будем выводить символы, что получили, а ещё избавимся от ассемблерных вставок:

asm("B mainCycle");typedef unsigned int uint32;typedef int (*get_char_func)();typedef void (*put_char_func)(char symbol); typedef void (*hex_dump_func)(char * bufptr, uint32 size); typedef void (*hex_to_int_func)(char * bufptr, uint32 * out_val); typedef char * (*dma_map_func)(uint32 low, uint32 hi, int size, int map_id); typedef void (*dma_unmap_func)(int map_id); void mainCycle (){get_char_func get_char = (get_char_func)0x30042695;put_char_func put_char = (put_char_func)0x30042671;hex_to_int_func hextoint = (hex_to_int_func)0x3007EECD;hex_dump_func hexdump = (hex_dump_func)0x30041FFC;dma_map_func mapdma = (dma_map_func)0x1830;dma_unmap_func unmapdma = (dma_unmap_func)0x18DC;char c;char * in_buffer = (char *)0x30059CB8;int in_max_size = 0x80;int buf_ptr = 0;unsigned int low_addr = 0;unsigned int hi_addr = 0;while(1){c = get_char();if (c == 0x00)continue;if (c != 0x0D && buf_ptr >= in_max_size)continue;in_buffer[buf_ptr++] = c;if (c == 0x0D)c = 0x0A;put_char(c);if (c == 0x0A && buf_ptr == 18){hextoint(in_buffer, &hi_addr);hextoint(in_buffer+9, &low_addr);hexdump(mapdma(low_addr, hi_addr, 0x40, 1), 0x40);unmapdma(1);}if (c == 0x0A)buf_ptr = 0;}}

Теперь при вводе в терминал адреса, контроллер считает нам физическую память ПК:

И это полный успех, можно наконец-то передохнуть!

Заключение

Итак, цель достигнута, мы модифицировали прошивку и можем командами по UART читать физическую память ПК. Конечно, этот пример крайне простой, но при желании можно реализовать абсолютно любую функциональность, ведь внутри стоит мощный и энергоэффективный ARM контроллер на 300 MHz. Например, никто не мешает написать код, который за несколько секунд сдампит всю ОЗУ компьютера на подключенный к контроллеру SSD диск (да да, там есть функции читать/писать диск). Или добавить на плату WiFi модуль, чтобы подавать команды удалённо - на что хватит фантазии!

Привет, Хабр.

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

В те годы компьютеры использовались лишь учеными и инженерами на больших предприятиях. И тут появляется компьютер, купить который может любой желающий. Altair 8800 содержал процессор 8080, 256 байт памяти в первой версии, и имел цену ниже 1000$ - это был первый успешно продаваемый персональный компьютер. Это был тот самый компьютер, для которого Билл Гейтс и Пол Аллен разрабатывали язык BASIC, компьютер благодаря которому сотни и тысячи увлеченных студентов и школьников пришли в мир программирования.

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

Код

Первым доступным языком был лишь Ассемблер. ALTAIR мог иметь до 64 КБайт памяти, и процессор 8080, работающий с тактовой частотой 2 МГц.

Чтобы лучше понять как это работает, я написал несложную программу, вычисляющую сумму чисел от 1 до 5:

; Code segment:        ORG    0o       ; Set Program Counter to address 0START:  LDA    I        MOV    B,A      ; RegB => I (1..N)        LDA    STEP        MOV    C,A      ; RegC => STEP (always 1)        LDA    SUM        MOV    D,A      ; RegD => SUM (result)LOOP:     MOV    A,D      ; Move value to Accumulator from Register D (SUM)          ADD    B        ; Add value in Register B to value in Accumulator          MOV    D,A      ; Save result back to D     I          MOV    A,B      ; Mov B to A and decrement it          SUB    C          JZ     PEND     ; If A is zero, the calculation is complete          MOV    B,A      ; If not, continue          JMP    LOOP     PEND:   MOV A,D         ; Save result in SUM value        STA SUMPWAIT:  JMP PWAIT       ; Nothing to do, infinite loop; Data segment:        ORG    200o     ; Set Program Counter to address 200I:      DB     5o       ; Data Byte at address 200 = 5STEP:   DB     1o       ; Data Byte at address 201 = 8 (10 octal)SUM:    DB     0o       ; Data Byte at address 202 = 0        END             ; End

Как можно видеть, я создал в памяти 3 переменные, I, STEP и SUM, которые используются для организации цикла от 1 до 5 с шагом 1. Далее эти значения загружаются в регистры B, C и D, с которыми и производятся арифметические операции. Команда JZ (Jump if Zero) завершает цикл, когда значение регистра А становится равным нулю. Последним шагом мы записываем результат обратно в ячейку памяти с именем SUM. Кстати, для ячеек памяти (data segment) мы указываем адрес первой ячейки, который в нашем случае равен 200o ("o" здесь это octet, 8-ричная система счисления).

В общем, вышенаписанный код делает то же, что в Python можно записать одной строкой:

s = sum(range(6))

Кстати забавно, что на Хабре нет подсветки синтаксиса для ассемблера, видимо было решено что вряд ли это кому-нибудь еще пригодится. Но пойдем дальше.

Компиляция

Строго говоря, никакого компилятора по условию задачи у нас нет, перевести команды в машинные коды придется вручную. К примеру, можно найти описание команды LDA:

Команда "LDA I", где I это ячейка памяти 200о = 80h, будет записана как 3A 80 00.

Следующая команда MOV B,A описывается так:

Получаем код команды 01000111b = 47h

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

3a 80 00 47 3a 81 00 4f 3a 82 00 57 7a 80 57 78 91 ca 18 00 47 c3 0c 00 7a 32 82 00 c3 1c 00

Размер программы - 38 байт. Никаких префиксов MZ, переключения страниц памяти и прочего - программа просто выполняется с адреса 0. До того времени, когда чтобы запустить программу на устройстве, нужно подписать её платным серфтификатом, было еще лет 40...

Загрузка и запуск

Для тестирования программы я воспользовался бесплатным симулятором ALTAIR 8800, скачать который можно с github. Его можно запустить прямо в браузере:

Еще раз повторюсь, в первой версии ALTAIR не было ни экрана ни клавиатуры. Все что доступно пользователю - это фактически панель прямого доступа к ячейкам памяти. Например, чтобы загрузить в ячейку памяти с адресом 1 значение 10001000b, нужно выставить соответствующие тумблеры и нажать тумблер DEPOSIT, чтобы ввести следующий код, нужно снова переключить тумблеры и нажать DEPOSIT NEXT. Чтобы прочитать значение ячейки памяти, есть соответствующий тумблер EXAMINE/EXAMINE NEXT. Запустить программу можно нажатием тумблера RUN или SINGLE STEP.

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

Результат выполнения показан на скриншоте. Запускаем программу, затем выбираем тумблерами ячейку памяти 202о = 10000010b, нажимаем тумблер EXAMINE. В ячейках D7..D0 получаем значение 00001111b = 15, что соответствует искомой сумме чисел от 1 до 5:

Заключение

Знакомство с подобными технологиями оказалось довольно любопытно. Также, посмотреть как работает ALTAIR, было интересно и с профессиональной точки зрения - понять, насколько может современный программист писать код под систему почти 50 летней давности. И надо сказать, что это оказалось ничуть не проще. Даже просто умножить 2 числа, если у процессора нет готовой команды для этого, будет поинтереснее любой задачи про гномиков, не говоря уже про написание кода "на бумажке". И чтобы написать интерпретатор BASIC в таких условиях, нужно быть весьма незаурядным программистом.

Интересно, что ALTAIR не забыт и до сих пор. Кроме онлайн-симулятора, можно собрать и "железный", на базе Ардуино:

И наконец, симулятор ALTAIR входит в пакет simh, доступный для Linux, с помощью которого может быть удобно запускать программу по шагам в консоли и просматривать содержимое ячеек памяти:

В общем, желающие могут поэкспериментировать самостоятельно.

Как обычно, всем удачных экспериментов.

Более двух десятков лет назад мы разрабатывали устройство, передающее и принимающее данные, используя телевизионный сигнал. Это сейчас все избалованы гигагерцами и гигабайтами, а тогда, имея компьютер типа IBM/PC-AT, на таких скоростях можно было работать только с помощью встроенного контроллера прямого доступа к памяти (ПДП), реализованного в виде микросхем 8237А-5. Это устройство позволяло писать или читать данные, не привлекая центральный процессор.

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

И вот, при заключительном просмотре текста, я вдруг увидел глупую описку в программировании ПДП. Адрес в 16-разрядной 8237А-5 приходилось задавать по частям и при задании номера станицы (т.е. номера куска памяти в 128 Кбайт) вместо команды

OUT DX,AL

было написано

OUT DX,AX

что совершенно бессмысленно, поскольку все используемые в ПДП порты 8-разрядные.
Исправил ляпсус, перетранслировал НЕ работает! Вернул опять бессмысленный AX вместо AL работает. Не может быть!

Начинаю рассуждать. Команда OUT выполняется ведь подобно обычной записи в память, только специальный сигнал INOUT на шине выставляется. Следовательно, если вместо AL я выдаю AX, то это равнозначно тому, что я в один порт (в данном случае 83H) выдаю значение из AL, а в соседний, т.е. получается в 84H значение из AH, а там в этот момент просто ноль.
А что это за порт такой? Вот же таблица всех портов из тогда единственной имевшейся у нас книги Фроловых Аппаратное обеспечение IBM PC:

Назначение и адреса регистров страниц контроллера для IBM AT:
81h Регистр страниц канала 2
82h Регистр страниц канала 3
83h Регистр страниц канала 1
87h Регистр страниц канала 0
89h Регистр страниц канала 6
8Bh Регистр страниц канала 5
8Ah Регистр страниц канала 7
8Fh Регенерация динамической памяти

Нет вообще здесь никакого порта 84H!

Честно говоря, я и сейчас не знаю, что это такое. Может быть, разрешение на работу данного ПДП из всего каскада, а может какая-то особенность конкретной материнской платы или еще одна часть адреса, позволяющая задать его больше чем 16 Мбайт.
Теперь, в эпоху Интернета, доступа к электронным библиотекам и компьютерным форумам, наверное, несложно докопаться, что именно делала запись нуля в неведомый мне порт 84Н. Но это уже неинтересно, поскольку все эти ПДП (DMA) давно ушли в прошлое вместе с шиной ISA и другими древними интерфейсами.

Однако речь о другом. Какое невероятное, прямо волшебное везение для программиста! Кто толкнул меня под руку написать AX вместо AL и именно в этом месте? Ведь ни в одном примере этого не было. Напиши я как положено AL, и мы провозились бы месяцы, подозревая, конечно, неправильную работу нового устройства, а не настройку ПДП. Да и как догадаться, что нужно обратиться к порту, которого даже нет в документации! А сроки были жесткие и не уложись мы в них, проект вообще был бы закрыт с наклеиванием на нас ярлыка неумех и неудачников.

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

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

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

• компиляция программ,

• своеобразный реверс-инжиниринг и портирование runtime-библиотек,

• устройство исполняемых файлов Windows и Linux,

• сборка и редактирование таких файлов вручную

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

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

В ходе работы нам понадобятся:

• компилятор gcc, линкер ld, отладчик gdb

• утилиты из binutils (readelf, strip, hexdump)

• базовое понимание устройства PE (Portable executable) и ELF

• знакомство с Pascal и ассемблером

Компилятор

Компилятор, который мы хотим портировать называется Bero TinyPascal Compiler (далее, BTPC) был написан в 2016 году немецким программистом-музыкантом и энтузиастом Pascal, Бенжамином Россо (Benjamin Rosseaux). Он компилирует подмножество Pascal'я (Delphi 7-XE7 и FreePascal >= 3) в бинарный код Windows x32. К тому же, компилятор самоприменимый.

Проект доступен на github и сейчас репозиторий содержит почти все необходимые для работы над ним инструменты. Однако, на момент выполнения работы, репозиторий выглядел примерно так:

Компилятор BTPC (и собранный из него btpc.exe) выполнен в self-contained виде - на все про все - один файл на ~3 тыс. строк паскаля. В нем представлен конвейер со всеми основными шагами компиляции - чтением входного потока, лексическим и синтаксическим анализом, генерацией промежуточного представления, генерацией кода. Поскольку, это не промышленный продукт, то никаких оптимизаций нет.

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

Фаза синтеза или умышленное падение с Seg fault

Итог работы компилятора BTPC - исполняемый файл формата PE (Portable Executable, подробнее на Википедии или Mircosoft), т.е. "ELF для Windows". В нем так же, как и в ELF, содержится все необходимое для отображения файла в память и запуска процесса, но организовано это все несколько иначе - отличия в основном касаются размещения в памяти.

Начнем рассмотрение фазы синтеза с момента, когда фронтенд уже выполнил свою часть, разобрав Pascal, и, когда у нас уже есть промежуточный код программы, байт-код:

• каждой инструкции байт-кода компилятор ставит в соответствие набор ассемблерных инструкций

• этот набор ассемблерных инструкций - по сути представление "бизнес-логики" программы в ассемблере

• бизнес-логика "подкладывается" в некоторый существующий PE-файл

• PE-файл редактируется, чтобы эта логика не "отвалилась" в процессе.

Концептуально это напоминает работу какого-нибудь фреймворка. Хотя фактически, это классическая библиотека времени выполнения (Runtime Library, RTL).

Наш PE-файл содержит библиотеку RTL с реализацией 9 простых функций:

• RTLHalt остановка программы

• RTLWriteChar запись charа в stdout

• RTLWriteInteger запись integer'а в stdout

• RTLWriteLn вывод linebreak'а в stdout

• RTLReadChar сохранение в EAX символа из STDIN

• RTLReadInteger сохранение в EAX integer'а из STDOUT

• RTLReadLn пропуск STDIN до EOF (конец файла) или ближайшего перевода строки

• RTLEOF возвращает в EAX положительное число в случае EOF. 0 в противном случае.

• RTLEOLN устанавливает 1 в DL, если следующий символ - \n, 0 в противном случае

Технически - это ассемблерный файл с одной лишь секцией кода на пару сотен строк, со следующей структурой:

.ENTRYPOINT  JMP StubEntryPoint# точка входа тут же отправляет нас в конец файлаRTLHalt:  ...                                 # определение фукнции RTLHaltRTLWriteChar:  ...                                 ...                                   # опеределения остальных функций RTLRTLFunctionTable:                     # таблица указателей на функции  DD OFFSET RTLHalt  DD OFFSET RTLWriteChar  DD OFFSET RTLWriteInteger  ...StubEntryPoint:  INVOKE HeapAlloc ...                # резервирование памяти  MOV ESI, OFFSET RTLFunctionTable    # сохранение таблицы функцийProgramEntryPoint:

Теперь, если скомпилировать и запустить приведенный выше RTL, происходит следующее:

• входная точка программы отправляет нас на метку StubEntryPoint

• резервируется память для будущей программы

• таблица функций сохраняется в неизменяемый в процессе работы регистр ESI

• управление передается программе

И программа падает, ведь метка ProgramEntryPoint указывает в никуда!

Но, можно предположить, что BTPC умеет дописывать код компилируемой программы следом за меткой ProgramEntryPoint.

{ фронтенд компилятора }procedure EmitStubCode;begin  OutputCodeDataSize := 0;  OutputCodeString(#77#90#82#195#66#101#82#111#94#102#114#0#80#69#0#0#76#1#1#0#0#0#0#0#...  OutputCodeString(#0#0#0#0#0#0#0#0#0#0#0#0#0#0#16#0#0#0#16#0#0#143##16#0#0#0#0...  OutputCodeString(#0#0#0#0#0#0#0#0#0#0#255#255#255#255#40#16#0#0#53#0#0#0...  OutputCodeString(#101#110#106#97#109#105#110#32#39#66#101#82#111#...  OutputCodeDataSize := 1423;end;{ бэкенд компилятора }

И кажется, теперь стала понятна и архитектура компилятора:

• Библиотека RTL (с реализациями базовых функций) компилируется и дает нам исходный, готовый к работе PE-файл (хоть он и падает, но он чисто технически - рабочий)

• Этот PE-файл сериализуется в паскаль-строки (те самые, с ограничением в 255 символов в длину)

  • Если кода меньше, то окончание добивается инструкциями-заглушками NOP

• Эти паскаль-строки помещаются в качестве шаблона (набора констант) непосредственно в компилятор

Компилятор BTPC работает следующим образом:

• Считывает программу из stdin

• В процессе анализа генерирует промежуточный код программы, байт-код

• В процессе синтеза, инструкциям байт-кода ставит в соответствие ассемблерные инструкции

• Дописывает получающиеся инструкции в конец шаблона (сериализованного в паскаль-строки PE-файла)

• Редактирует шаблон таким образом, чтобы загрузчик "увидел" новый, дописанный в конец, код компилируемой программы

• Десериализует результат в исполняемый файл

Редактирование PE32

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

Пример правильного патчевания: размер секции кода занимает 4 байта, начиная со 156 байта. При этом во время компиляции было сгенерировано 100 байтов кода. Тогда, необходимо извлечь значение из этих 4х байтов, прибавить к нему 100 и записать обратно.

Стоит отметить, что изначально для компиляции RTL, Бенджамин использовал свой собственный тулчейн Excagena, который во-первых собирает крайне минималистичный выходной PE-файл. Обычно компиляторы/линкеры добавляют отладочную информацию в выходной файл, но Excagena вырезает все, что не влияет напрямую на работу.

Во-вторых, секция кода находится в самом конце полученного PE. То есть, буквально, метка ProgramEntryPoint - последнее, что в нем есть.

Цель всего этого - облегчить последний этап - редактирование PE-файла. И Бенджамину это вполне удалось - от него требуется лишь обновить пару значений в общей структуре:

• размер кода (OptionalHeader.SizeOfCode)

• размер секций (SectionTable.VirtualSize)

• размер образа (OptionalHeader.SizeOfImage), загруженного в память

Так что вся его хирургия выглядит вполне компактно - он считывает предыдущее значение поля, корректирует его с учетом добавленного фрагмента и выравнивания, и записывает обратно по прежнему адресу:

{ Вычисление размера кода } CodeSize := OutputCodeGetInt32($29) + (OutputCodeDataSize - CodeStart);OutputCodePutInt32($29, CodeSize);{ Определение текущего значения выравнивания } SectionAlignment := OutputCodeGetInt32($45);{ Вычисление и редактирование виртуального размера секции с учетом выравнивания }SectionVirtualSize := CodeSize;Value := CodeSize mod SectionAlignment;SectionVirtualSize := SectionVirtualSize + (SectionAlignment - Value);OutputCodePutInt32($10d, SectionVirtualSize);{ Редактирование размера образа при загрузке в память }OutputCodePutInt32($5d, SectionVirtualSize + OutputCodeGetInt32($39));

Хотя общая идея сейчас ясна, магическим $29, $45, $115 в оригинальном коде не помешали бы имена

Портирование компилятора

Мы разобрались с устройством компилятора, но наша конечная цель - получить работающий под Linux x64 компилятор. Чтобы ее достичь, понадобится выполнить следующее:

• переписать RTL библиотеку с использованием системных вызовов Linux x64

• собрать из нее исходный ELF-файл

• научиться динамически редактировать ELF-файл, дополненный кодом

Всего-то 3 шага

Первый эта достаточно простой - нужно "лишь" заменить системные вызовы к WinApi на линуксовые.

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

ReadCharBuffer: DB 0x90ReadCharBytesRead: DB 0x90,0x8D,0x40,0x00ReadCharEx:  PUSHAD  INVOKE  ReadFile, DWORD PTR StdHandleInput, OFFSET ReadCharBuffer, 1, OFFSET ReadCharBytesRead, BYTE 0  TEST    EAX, EAX  SETZ    AL  OR      BYTE PTR IsEOF, AL  CMP     DWORD PTR [ReadCharBytesRead], 0  SETZ    AL  OR      BYTE PTR IsEOF, AL  POPAD  RET

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

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

Напомню, что в 64-битных системах системные вызовы совершаются инструкцией syscall (хотя это и не единственный способ). Аргументы передаются через регистры по порядку, RDI, RSI, RDX и так далее. Результат возвращается через RAX.

В x64 исчезли аналоги pusha, pushad, popa, popad. В качестве замены введем свои макросы pushall, popall, работающие аналогично. Поместим эти макросы в секцию неинициализированных данных - bss.

В свою очередь, буферы уходят в секцию данных - data.

В итоге описанная выше функция принимает вид:

.section .data# буфер чтения - в секции данных ReadCharBuffer:    .byte 0x3c.section .text# код - в секции кодаReadCharEx:    PUSHALL# макрос - в секции bss    XORQ    %RAX, %RAX              # syscall #0: read(int fd, void *buf, size_t count)    XORQ    %RDI, %RDI              # fd        : 0 == stdin    MOVQ    $ReadCharBuffer, %RSI   # buf       : ReadCharBuffer    MOVQ    $1, %RDX                # count     : 1 byte    SYSCALL    CMPQ    $0, %RAX    SETZ    %BL                         ORB     %BL, (IsEOF)    POPALL    RET

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

Однако, выяснилось, что Linux для каждого запущенного процесса запоминает список регионов виртуальной памяти и, в случае ошибки обращения, проверяет, не произошел ли Segmentation fault. Если не произошел, значит было обращение к неинициализированной странице, а значит необходимо лишь выделить еще одну страницу виртуальной памяти и добавить к региону. Получатся, резервировать память заранее не требуется. В вот столкнуться с Guard Page в принципе непростая задача. Значит, необходимость в подготовке стека в новой библиотеке отпала, что для нас, конечно же, плюс.

Осталось скомпилировать и слинковать библиотеку:

$ gcc -c rtl64.s$ ld rtl64.o -g --output rtl64

Полученный ELF сериализуем в паскаль-строки и помещаем в BTPC вместо прежнего шаблона. На этом библиотеку можно считать портированной.

Кодогенерация

Как мы уже видели, BTPC в процессе компиляции переводит байт-код в ассемблерные инструкции и конкатенирует их с шаблоном процедурами EmitByte:

procedure OCPopESI;begin  EmitByte($5e);  LastOutputCodeValue := locPopESI;end;procedure OCMovzxEAXAL;begin  EmitByte($0f);   EmitByte($b6);   EmitByte($c0);  LastOutputCodeValue := locMovzxEAXAL;end;

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

Переведем вручную инструкцию MOV R10, [R12 + R13], (напомню, квадратные скобки обозначают взятие значения по адресу) воспользовавшись материалами методички "Intel 64 and IA-32 Architectures Developers Manual"

1. Переводим номера операндов в двоичный вид. Регистр-приемник R10 подходит под формат "R?".

2. Находим инструкцию MOV в таблице кодов инструкций i8086+. Нужен формат "r/m R?". Итого, получаем 0x8B.

3. Операнд R10 в двоичном представлении имеет длину 4 бита, а значит не входит в отведенные 3 бита Rn байта ModR/M.

4. Для представления подобных "больших" регистров понадобится байт "Префикс REX".

5. Старший бит R10 уходит в бит R префикса REX и расширяет Rn в байте ModR/M.

6. Согласно таблице ModR/M для 32-разрядных инструкций, биты R/M байта ModR/M = 100, а биты Mod = 00. Это дает дополнительный байт SIB.

7. Старший бит регистра R12, равный 1, взводит бит X в префиксе REX и расширяет номер индекса в SIB.

8. Байт SIB выглядит, как [#Base + #Index2^(Scale)]. Базу Base образует регистр R12. 3 младших его бита = 100 и устанавливаются на место 3х битов Base в SIB.

9. Индекс(Index) в SIB составляют 3 младших бита регистра R13 = 101.

10. Так как в инструкции лишь сложение (1 регистр + 1 регистр), биты Scale в байте SIB = 00 и дают 2^(Scale) = 2^0 = 1.

11. Старший бит регистра R13 уходит в бит B префикса REX. Это расширяет набор базового регистра в байте SIB.

12. Конкатенируем байт префикса REX: "0100" + "W:1" + "R:1" + "X:1" + "B:1" = 01001111, что в hex записи дает 0x4F. Префикс REX найден.

13. Конкатенируем байт ModR/M: "Mod:00" + "Rn:010" + "R/M:100" = 00010100, что дает байт 0x14.

14. Конкатенируем наконец байт SIB: "Scale:00" + "Index:101" + "Base:100" = 00101100, что дает байт 0x2C.

Путем конкатенации полученных байтов имеем инструкцию MOV R10, (R12 + R13) в виде 0x4F 0x8B 0x14 0x2C .

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

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

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

Хирургическая операция над ELF'ом

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

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

Но для начала оценим, насколько все плохо. Опасение вызывают 2 факта:

• ELF64 отличается от PE32

• PE32 был собран вручную, с некоторыми хаками

Воспользуемся readelf'ом и прочтем собранный ранее rtl64:

$ readelf --section-headers rtl64Section Headers:  [Nr] Name              Type             Address           Offset       Size              EntSize          Flags  Link  Info  Align  [ 0]                   NULL             0000000000000000  00000000       0000000000000000  0000000000000000           0     0     0  [ 1] .text             PROGBITS         00000000004000b0  000000b0       0000000000000317  0000000000000000  AX       0     0     1  [ 2] .data             PROGBITS         00000000006003c7  000003c7       00000000000000bf  0000000000000000  WA       0     0     1  [ 3] .symtab           SYMTAB           0000000000000000  00000488       0000000000000408  0000000000000018           4    39     8  [ 4] .strtab           STRTAB           0000000000000000  00000890       0000000000000248  0000000000000000           0     0     1  [ 5] .shstrtab         STRTAB           0000000000000000  00000ad8       0000000000000027  0000000000000000           0     0     1

Чуда не случилось - в нашем ELF'е аж 6 секций!:

• нулевая пустая секция (согласно стандарту)

• секция кода text

• секция данных data

• секция имен секций shstrtab (Section header string table)

• таблица символов в symtab

• метки из ассемблерного ассемблерного кода в strtab

Чем ближе секция кода к концу файла, тем лучше для нас. Нам не повезло от слова совсем - секция кода плотно зажата данными и метаданными. Если мы сейчас найдем метку ProgramEntryPoint и пойдем записывать код после нее, мы с большой вероятностью "потеряем пациента".

Откуда столько секций? Мы ведь компилировали лишь код и данные. Получается, они подтянулись на стадии линковки и наш файл стал весить почти 4 Кб, а там ведь всего пара сотен строк кода, не считая внутренностей самого ELF'а.

Попросим ld не включать ничего лишнего (--nostdlib, --strip-all):

$ ld rtl64.o -g --output rtl64-min -nostdlib --strip-all

ELF сжался в 2 раза - теперь весит всего 1.4 Кб. Взглянем еще раз на секции:

$ readelf --section-headers rtl64-minSection Headers:  [Nr] Name              Type             Address           Offset       Size              EntSize          Flags  Link  Info  Align  [ 0]                   NULL             0000000000000000  00000000       0000000000000000  0000000000000000           0     0     0  [ 1] .text             PROGBITS         00000000004000b0  000000b0       0000000000000317  0000000000000000  AX       0     0     1  [ 2] .data             PROGBITS         00000000006003c7  000003c7       00000000000000bf  0000000000000000  WA       0     0     1  [ 3] .shstrtab         STRTAB           0000000000000000  00000486       0000000000000017  0000000000000000           0     0     1

Минус 2 секции. Уже лучше, хотя shstrtab все еще на месте. Вспоминаем, что в комплекте binutils есть утилита strip, которая умеет редактировать исполняемые файлы. Пробуем вырезать shstrtab из нашего файла и снова прочесть оставшиеся секции:

$ strip -R shstrtab rtl64-min$ readelf --section-headers rtl64-minSection Headers:  [Nr] Name              Type             Address           Offset       Size              EntSize          Flags  Link  Info  Align  [ 0]                   NULL             0000000000000000  00000000       0000000000000000  0000000000000000           0     0     0  [ 1] .text             PROGBITS         00000000004000b0  000000b0       0000000000000317  0000000000000000  AX       0     0     1  [ 2] .data             PROGBITS         00000000006003c7  000003c7       00000000000000bf  0000000000000000  WA       0     0     1  [ 3] .shstrtab         STRTAB           0000000000000000  00000486       0000000000000017  0000000000000000           0     0     1

Shstrtab и ныне там. Посмотрим, что же внутри:

$ hexdump -C rtl64-min00000480  40 00 00 00 00 00 00 2e  73 68 73 74 72 74 61 62  |@.......shstrtab|00000490  00 2e 74 65 78 74 00 2e  64 61 74 61 00 00 00 00  |..text..data....|000004a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

В секции с именами секций лежат имена секций! Хотя бы здесь все предсказуемо. Оказывается, что секция .shstrtab всегда генерируется при линковке. Хотя, согласно спецификации, для исполнения она не нужна - то есть, теоретически избавиться от нее возможно.

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

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

ENTRY(_start)                           /* точка входа */SECTIONS{    . = 0x4000b0;                       /* адрес размещения секции данных */    .data : { *(.data) }    .bss :  { *(.bss)  *(COMMON) }    . = 0x6000d3;                       /* адрес размещения секции кода */    .text : { *(.text) }                /* секция кода идет последней в файле */}

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

Теперь у нас имеется специальный скрипт линковки. Воспользуемся им и вновь прочтем секции:

$ ld rtl64.o -g --output rtl64-custom-ld -T linkerScript.ld -nostdlib --strip-all$ readelf --section-headers rtl64-custom-ldSection Headers:  [Nr] Name              Type             Address           Offset       Size              EntSize          Flags  Link  Info  Align  [ 0]                   NULL             0000000000000000  00000000       0000000000000000  0000000000000000           0     0     0  [ 1] .data             PROGBITS         00000000006000b0  000000b0       00000000000000bf  0000000000000000  WA       0     0     1  [ 2] .text             PROGBITS         0000000000a00170  00000170       0000000000000317  0000000000000000  AX       0     0     1  [ 3] .shstrtab         STRTAB           0000000000000000  00000487       0000000000000017  0000000000000000           0     0     1

Бинго, скрипт сработал! Секция text, действительно, поменялась местами с секцией data.

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

Хотя ранее по соседству содержались и код и данные, так что некоторые команды из-за этого неверно отображались в gdb и запутаться было крайне легко. Как с этим всем справился Бенджамин, история умалчивает

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

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

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

Приведенные выше значения надо увеличить на размер сгенерированного кода: sizeof(injection). Значения учитывают порядок размещения секций в файле.

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

И, поскольку теперь мы знаем, где "резать", где "пришивать" и куда "колоть", реализовать эти функции в компиляторе не составит труда.

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

Через несколько итераций получаем работоспособный компилятор.

# Получаем кросскомпилятор$ btpc.exe < btpc64.pas > btpcCrossWin.exe# Еще шаг и получаем его Linuxверсию$ btpcCrossWin.exe < btpc64.pas > btpc64Linux# Еще один, контрольный шаг, уже на Linux$ btpc64Linux < btpc64.pas > btpc64Check

И в конце концов получаем самоприменимый компилятор подмножества Pascal, работающий под Linux x64, как и было запланировано.

Заключение

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

• разобрались с архитектурой компилятора BTPC

• Выяснили, как устроен процесс от исходного кода на Pascal до исполняемого файла Windows

• Пересобрали библиотеку времени выполнения (RTL)

• Собрали из RTL файл ELF и разобрались в его внутреннем устройстве и научились динамически его редактировать

• Исправили процесс кодогенерации

• Собрали полученное в рабочий компилятор

Результаты работы доступны в репозитории на github.

Если Вы дочитали до этого момента, то, надеюсь, не жалеете о потраченном времени. Надесюь, что Вы открыли для себя что-то новое. Но, даже если Вас ничего не удивило, возможно вы освежили знания

P.S.

Наверняка, многие уже догадались, что задача походит на учебный проект. Это, действительно, курсовая работа по компиляторам на кафедре ИУ9 в МГТУ им. Баумана, которую я выполнил несколько лет назад. Предстоящий объем работы казался тогда невыполнимым. И чем больше работы было проделано, тем, казалось, больше работы предстоит впереди. Но процесс и достигнутый результат оказались более занимательным, чем шаги в неизвестность (и возгласы "а так можно было?") на каждом этапе работы. И вот, спустя несколько лет, у меня дошли руки написать краткую статью о проделанной тогда работе, попытавшись сохранить интересные и важные "открытия", сделанные в ходе нее, и опустив лишние технические детали ("невошедшее" можно найти в отчете в репозитории выше).

Также, не могу не поблагодарить своего научного руководителя, Александра Коновалова.

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

Ссылки

• Спецификация ELF

• Исходный компилятор BTPC

• Портированная версия BTPC64

Введение

Много лет назад американским специалистом Гарри Килдэллом (Gary Kildall) в рамках создания системы программирования для персональных компьютеров был разработан транслятор с языка ассемблера для процессора Intel 8086, который он назвал RASM-86 (Relocating ASseMbler). Этот во многом типичный для своего времени продукт имел особенность: он позволял, не меняя транслятора, добавлять описания новых команд процессора с помощью специальных макросредств.

Автор статьи, используя и развивая этот транслятор, успешно применял данные средства по мере появления новых поколений процессоров. Конечно, иногда и сам транслятор требовал ряда доработок, например, при переходе на архитектуру IA-32, а затем и на x86-64 (IA-32e). Тем не менее, изначально заложенная идея позволила легко продолжать эволюцию транслятора до настоящего времени. Некоторые итоги этой работы рассматриваются далее.

Организация генерации команд в трансляторе с ассемблера

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

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

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

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

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

Макросредства описания команд

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

CodeMacro AAA  DB 37HEndMCodeMacro DIV divisor:EbSEGFIX divisor  DB 6FHEndMCodeMacro OR dst:Re, src:Ee  SEGFIX src  DB 0BH  MODRM dst,srcEndM

Описание формальных параметров

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

Типы формальных параметров:

A  сумматор EAX/AX/ALC  выражение типа метка D  непосредственный операндE  адресное выражение, записанное в регистре или памятиM  адресное выражение, может иметь базовые и индексные регистрыR  один из общих регистровS  сегментный регистрX  прямое обращение к памяти при обмене с сумматором

Размеры формальных параметров

n - длина неопределеннаb  байтw  словоe  двойное словоd  длина при использовании адреса смещение+сегментsb  знаковый байт, расширяемый до словаse  знаковый байт, расширяемый до двойного слова

Примеры описания формальных параметров:

CodeMacro IN dst:Aw, port:Rw (DX)CodeMacro ROR dst:Ee, count:Rb (CL)

Директивы макроопределений

Первоначально все описания команд х86 свелись к нескольким директивам, часть из которых используются редко. Перевод транслятора на архитектуру IA-32 потребовал добавления лишь одной новой директивы управления префиксами размера/адреса 66H/67H, причем, чтобы не вводить новых ключевых слов используется уже имевшаяся директива, но с другой формой параметра.

Директивы DB, DW и DD

Данные директивы в макро почти эквиваленты обычным операторам ассемблера и используются для задания констант и адресов. Эти директивы характерны и для любых других (не специальных) макросредств.

Директива DW используется для задания адреса (4 байта в 32-х разрядном режиме), а директива DD для задания адреса в виде смещение+сегмент. Примеры использования DB, DW и DD:

CodeMacro CLC  DB 0F8HEndMCodeMacro XOR dst:Ee,src:De  SEGFIX dst  DB 81H  MODRM 6,dst  DW srcEndMCodeMacro CALLF label:Cd  DB 9AH  DD labelEndM

Директива адресации MODRM

Это главная из специальных директив, определяющая адресацию архитектуры IA-32. Она определяет и основное отличие данных макросредств от обычных. Именно микрокод, порождаемый этой директивой, указывает транслятору генерировать адресную часть команды, включая и байт режимов адресации и смещение и SIB-байт, если операнды подразумевают это. Директива имеет два параметра. Это или два имени формальных параметров макро или константа-число и имя. Например:

CodeMacro RCR dst:Ee, count:Rb(CL)  SEGFIX dst  DB 0D3H  MODRM 3,dstEndMCodeMacro XOR dst:Re,src:Ee  SEGFIX src  DB 33H  MODRM dst,srcEndM

Директивы определения относительного адреса RELB, RELW

Эти директивы используются для описания команд передачи управления по относительному адресу, занимающему или байт или 4 байта для IA-32. Пример:

CodeMacro LOOP place:Cb  DB 0E2H  RELB placeEndM

Директива задания кодов DBIT

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

CodeMacro DEC dst:Re  DBIT 5(9), 3(dst(0))EndM

Директива формирования префикса сегмента SEGFIX

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

Директива контроля сегментов NOSEGFIX

Директива имеет параметры в виде имени сегментного регистра и имени формального параметра. Она не генерирует кода, а проверяет, что обращение к данному параметру идет с использованием указанного сегментного регистра, иначе сообщает об ошибке. Эта директива требуется лишь в общих формах команд CMPS и MOVS, где один из операндов может адресоваться только через ES.

Данная директива была расширена для управления префиксами размера и адреса 66H/67H. В этом случае в директиве указывается параметр-число: 0 нет префиксов, 1- может быть префикс 66H, 2 может быть префикс 67H, 3 могут быть оба префикса, 4 всегда есть оба, 5 никогда нет 66H, 6 никогда нет 67H и т.п.

Такими простыми средствами удается описать все множество команд IA-32, например:

CodeMacro FLDCW src:Mw  SEGFIX src  DB 0D9H  MODRM 5, srcEndMCodeMacro CMOVAE dst:Re, src:Ee  SEGFIX src  DB 0FH  DB 43H  MODRM dst,srcEndM

Некоторое исключение из стройной системы описаний составляют команды FPU, имеющие операнд в памяти. Для простоты в RASM разрядность таких команд указывается прямо в мнемонике, а не определяется по размеру операнда в памяти. Поэтому в RASM есть, например, команды FIST16, FIST32 и FIST64. Однако на практике, с точки зрения ясности текста, указание разрядности операнда прямо в имени команды FPU оказалось вполне приемлемым.

Создание псевдокоманд с помощью макросредств

Используя возможность добавления новых комбинаций операндов можно конструировать новые команды процессора. Например, команду MOV ECX,10 часто целесообразно заменять двумя командами с более коротким кодом PUSH 10 и POP ECX. А эти две команды можно описать в виде одного макроопределения:

CodeMacro MOVSX dst:Re, src:Dse  NOSEGFIX 6  DB 6AH  DB src  DBIT 5(0BH),3(dst(0))EndM

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

За время использования транслятора RASM накопился ряд таких полезных псевдокоманд, например:

MOV X,Y, где X,Y переменные в памяти;

MOV DS,0 или MOV DS,ES;

Команды PUSH и POP для нескольких регистров сразу, т.е. PUSH EAX,EBX,ECX;

Обращение к портам без указания регистра DX и т.п.

Добавление новых типов команд

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

При этом в транслятор иногда приходится добавлять и новую группу имен специальных регистров этих команд (внутри транслятора имена это просто переименованные числа). Так, коды имен регистров CR0-CR7 являются внутри транслятора RASM числами 10H-17H, коды имен регистров MM0-MM7 числами 40H-47H, коды имен регистров XMM0-XMM7 числами 50H-57H, и т.д. Младшая цифра чисел (всегда 0-7) участвует в генерации кода через директиву MODRM, а собственно значения чисел используются для задания допустимого диапазона в формальных параметрах новых макро.

При поиске подходящих операндов транслятор проверит, что указанный в команде регистр входит в допустимый диапазон и поэтому, например, в командах MMX вместо MM0 нельзя указать чужой регистр CR0 или XMM0.

Часто в новых множествах команд требуется применить директиву NOSEGFIX 5, выключающую обычные правила использования префикса 66H (в зависимости от размера операндов), поскольку в описываемых командах этот префикс используется по-своему.

Тогда, например, для команд из множества MMX описания выглядят так:

CodeMacro MOVQ dst:Rn(40H,47H),src:Mn  NOSEGFIX 5  SEGFIX src  DB 0FH  DB 6FH  MODRM dst,srcEndM

Для команд из множества XMM:

CodeMacro ADDPS dst:Rn(50H,57H),src:Mn  NOSEGFIX 5  SEGFIX src  DB 0FH  DB 58H  MODRM dst,srcEndM

Для команд из множества SSE2:

CodeMacro ADDPD dst:Rn(50H,57H),src:Mn  NOSEGFIX 5  DB 66H  SEGFIX src  DB 0FH  DB 58H  MODRM dst,srcEndM

Для команд из множества 3DNow!:

CodeMacro PFACC dst:Rn(40H,47H),src:Mn  NOSEGFIX 5  SEGFIX src  DB 0FH   DB 0FH  MODRM dst,src  DB 0AEHEndM

Расширение макросредств для x86-64 (IA-32e), AVX-команд и т.д.

Разумеется, расширение транслятора для генерации 64-х разрядных команд потребовало очередных доработок макросредств в виде добавления новой длины операнда Q (64-битный операнд/регистр) и новой директивы REX, формирующей REX-префикс команд. Потребовалось также ввести новые диапазоны регистров, ну и конечно дополнить таблицу служебных слов названиями требуемых регистров, вроде SPL или R14D или YMM15.

Однако все эти доработки потребовали именно расширения, но не кардинальной переделки транслятора.

Использование макросредств для генерации команд процессоров другой архитектуры

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

Анализ показал, что имеется лишь три препятствия такого использования RASM для генерирования команд RISK-архитектуры: конфликт мнемоники команды ST с названием регистра FPU, форма записи инкремента указателя типа X+ и другой способ вычисления относительного адреса, делающий директиву RELW неподходящей.

Первые два препятствия были обойдены с помощью введения новых директив в RASM, позволяющих исключать из лексического анализа заданную лексему (в данном случае ST) и разрешать синтаксические конструкции инкремента типа X+.

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

Такие несложные доработки транслятора повысили универсальность макросредств. Все RISK-команды были легко описаны с их помощью, например:

CODEMACRO RJMP  k:Cw  RELW 2,12,k  DBIT 8('S'(1))  DBIT 4(0CH),4('S'(9))ENDMCODEMACRO LDI   R_d:Db(16,31),K:Dn  DBIT 4(R_d(0)),4(K(0))  DBIT 4(0EH),4(K(4))ENDMCODEMACRO OUT   P:Dn(0,63),R1_r:Db(0,31)  DBIT 4(R1_r(0)),4(P(0))  DBIT 5(17H),2(P(4)),1(R1_r(4))ENDMи т.д.

И наконец стало можно программировать микроконтроллер AT90S2313 на RASM:

                 ;---- ПЕРЕХОД ПО RESET (0) ----0000 02C0  0006  rjmp РЕСТАРТ                 ;---- ПЕРЕХОД ПО INT 0 (1) ----0002 CBC0  019A  rjmp ПРЕРВАНИЕ_ОТ_ГПРРЕСТАРТ:                 ;---- ИНИЦИАЛИЗАЦИЯ СТЕКА ---- 0006 BFED       ldi  СЧ_ТМ,СТЕК   ;КОНЕЦ РАБОЧЕЙ ПАМЯТИ 0008 BDBF       out  SPL,СЧ_ТМ    ;УСТАНОВИЛИ СТЕК                 ;---- ИНИЦИАЦИЯ ВХОДОВ ПОРТА "B" ---- 000A 2FE5       ldi  tmp,РАЗР_B 000C 27BB       out  DDRB,tmp                 ;---- ИНИЦИАЦИЯ ВХОДОВ ПОРТА "D" ---- 000E 22E0       ldi  tmp,РАЗР_D 0010 21BB       out  DDRD,tmp                 ;---- ИНИЦИАЦИЯ RS-232 ---- 0012 24E0       ldi  tmp,4           ;115200 БОД 0014 29B9       out  UBRR,tmp 0016 28E1       ldi  tmp,(1 SHL RXEN) OR (1 SHL TXEN) 0018 2AB9       out  UCR,tmp

Заключение

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

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

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

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

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

Литература

1. RASM-86 Programmers Guide Digital Research, Сalifornia

http://bitsavers.org/pdf/digitalResearch/pl1/

2. М.Гук, В. Юров Процессоры Pentium 4, Athlon и Duron. СПб.: Из-во Питер, 2001

Введение

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

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

Постановка задачи

Формализуем задачу. Необходимо перевести восьмибайтовое число из формата IEEE-754 в текстовую строку, где указан знак числа, мантисса заданной длины и десятичный порядок с признаком E и своим знаком.

Так, если задано число 1234.567890, то строка с мантиссой, например, в 16 знаков должна выглядеть как 1.23456788999999E+003. Вместо плюса у мантиссы нужно писать пробел, а сама мантисса должна быть не меньше единицы. Кстати, данный пример иллюстрирует дискретность и приближенность представления чисел в формате IEEE-754: приведенное исходное число не может быть точно представлено как 1.23456789000000E+003, что, может быть, интуитивно ожидалось.

Использование команд FPU для преобразования

На первый взгляд, решение выглядит простым. В устройстве FPU (Floating Point Unit) процессора даже имеются команды, явно предназначенные и для перевода чисел из формата IEEE-754 в текст. Это, во-первых, команда EXTRACT разделения числа на мантиссу и порядок, а во-вторых, команда FBSTP выдающая мантиссу сразу в виде двоично-десятичного значения. Однако при ближайшем рассмотрении эти команды не дают нужного результата.

Например, если применить команду FBSTP к указанному выше числу, то получится 10 байт со значением 35 12 00 00 00 00 00 00 00 00, поскольку нецелочисленные значения сначала округляются согласно полю RC управляющего слова FPU. Это двухбитовое поле RC может принимать 4 значения, но среди них нет режима отключить округление. Поэтому часть мантиссы просто теряется, единственное чего можно добиться режимами округления это еще получить значение 34 12 при округлении к меньшему.

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

Итак, при использовании возможностей FPU придется решать две задачи.

Во-первых, умножением (или делением) исходного числа на десять нужно перегнать всю мантиссу в целочисленную часть числа, тогда команда FBSTP выдаст, наконец, в двоично-десятичном виде все цифры мантиссы.

Во-вторых, нужно определить такой десятичный порядок (опять-таки умножением или делением на десять), при котором результат попадет в диапазон между 1 и 10. Это нужно для представления числа в виде мантиссы с одной цифрой перед точкой и найденным порядком. Увы, совместить эти две задачи в едином цикле умножения/деления невозможно.

Причем есть и подводный камень в виде значения числа, максимально приближенного к единице, но не равного единице. Циклом деления или умножения легко можно ошибиться в показателе степени и вместо требуемого в данном случае 9.999E-001 получить неправильное значение типа 9.999E+000. К сожалению, при всем богатстве команд FPU обойтись без циклов деления и умножения на десять не удается.

Алгоритм преобразования

При формировании мантиссы для числа типа double умножение или деление на 10 продолжаются до тех пор, пока двоичный порядок числа не достигнет (или не станет больше/меньше) 53, поскольку под мантиссу выделено именно 53 двоичных разряда.

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

Пример реализации преобразования

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

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

В частности здесь используются временные метки в виде символа @. Алгоритм их реализации следующий: транслятор имеет внутренний счетчик меток. Когда метка @ встречается в команде перехода, к ней автоматически дописывается значение этого счетчика (т.е. реально создаются метки @0000, @0001 и т.д.). Когда встречается символ @ с двоеточием, к нему также автоматически приписывается значение счетчика и после этого счетчик увеличивается на 1.

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

Кроме этого, для команд FPU в RASM не анализируется размер операнда, он имеется прямо в названиях команд в виде значений 16, 32, 64 или 80.

Но вернемся к задаче. Подпрограмме по адресу в EBX передается исходное восьмибайтовое число в формате IEEE-754 и требуемая длина текстовой строки-результата в AL.

В результате работы число записывается в стек в виде текста в научной нотации и в AL сохраняется длина этой строки. Другие регистры не сохраняются.

С целью разгрузить конвейеры процессора некоторые команды рассыпаны по тексту и не образуют непрерывных логических цепочек, что несколько затрудняет чтение текста. Но таких мест немного. Программа реентерабельна и может быть использована в параллельных вычислениях. При начале работы программы управляющее слово FPU CW=0360.

1. Сначала в стеке выделяется место для ответа и заполняется нулевым шаблоном, т.е. значением 0.000 E+000.

2. Затем проверяется знак числа и в зависимости от него формируется мантисса умножением или делением числа на десять.

3. Командой FBSTP мантисса переписывается в память из FPU в двоично-десятичном виде и ее часть (заданной длины) переносится в ответ.

4. После этого исходное число опять-таки умножением или делением на десять как можно ближе подгоняется к 1, что позволяет вычислить требуемый десятичный порядок, который и записывается на заранее подготовленное в ответе место.

      CSEGPUBLIC ?QFCMW:;---- ПОДГОТОВКА МЕСТА В СТЕКЕ ----      MOVZX     ECX,AL          ;ЗАДАННАЯ ДЛИНА СТРОКИ      POP       EAX             ;ДОСТАЛИ АДРЕС ВОЗВРАТА      SUB       ESP,ECX         ;ВДЕЛИЛИ МЕСТО В СТЕКЕ      MOV       EDI,ESP         ;ОНО ЖЕ НАЧАЛО СТРОКИ-РЕЗУЛЬТАТА      MOV       ESI,ESP         ;ЗАПОМНИЛИ НАЧАЛО      PUSH      EAX             ;АДРЕС ВОЗВРАТА ВЕРНУЛИ НА МЕСТО      PUSH      ECX             ;ЗАПОМНИЛИ ЗАДАННУЮ ДЛИНУ ОТВЕТА;---- СНАЧАЛА ЗАПОЛНЕНИЕ СТРОКИ-РЕЗУЛЬТАТА НУЛЕВМ ШАБЛОНОМ ----      MOV       EAX,'0.0 '      ;ЗНАК И ПЕРВОЕ ЧИСЛО С ТОЧКОЙ      STOSD      DEC       EDI             ;ОСТАВЛЯЕМ ПЕРВЕ ТРИ СИМВОЛА ШАБЛОНА      SUB       CL,8            ;ВЧЛИ СЛУЖЕБНЕ ЗНАКИ И ПОРЯДОК      MOV       AL,'0'      JBE       @               ;ОШИБКА, НЕТ МЕСТА ПОД МАНТИССУ      REP       STOSB           ;ЗАПОЛНИЛИ МАНТИССУ НУЛЯМИ@:    MOV       EAX,'00+E'      ;ПОКА ДВА НУЛЯ ПОРЯДКА      STOSD                     ;ЗАПИСАЛИ НУЛЕВОЙ ПОРЯДОК      LEA       EBP,[EDI]-2     ;ЗАПОМНИЛИ АДРЕС ПОРЯДКА      FLD64     [EBX]           ;ЗАГРУЗИЛИ ЗАДАННОЕ ЧИСЛО      MOV       B PTR [EDI],'0' ;ПОКА ТРЕТИЙ НУЛЬ ПОРЯДКА;---- ПРОВЕРКА ЗАДАННОГО ЧИСЛА НА ПЛЮС/МИНУС/НОЛЬ ----      FTST                      ;СРАВНИЛИ С НУЛЕМ      FNSTSW    AX      SAHF      JNZ       @               ;ЗАДАННОЕ ЧИСЛО НЕ НОЛЬ;---- СРАЗУ ВХОД С ЧИСТМ НУЛЕМ ----      POP       EAX             ;ВХОД С ЗАДАННОЙ ДЛИНОЙ И НУЛЕМ      FSTP      ST              ;ОЧИСТИЛИ FPU ОТ ИСХОДНОГО ЧИСЛА      RET;---- ОБРАБОТКА ЗНАКА ЗАДАННОГО ЧИСЛА ----@:    JNB       @               ;ЕСЛИ ЧИСЛО ПОЛОЖИТЕЛЬНО      MOV       B PTR [ESI],'-' ;ОТМЕТИЛИ ЗНАК ОТРИЦАТЕЛЬНОГО      FABS                      ;УБРАЛИ ЗНАК В САМОМ ЧИСЛЕ@:    MOV       EDX,OFFSET ДЕСЯТЬ ;ДЕСЯТИЧНАЯ СИСТЕМА;---- ПРОВЕРКА ВЕЛИЧИН ПОРЯДКА ИСХОДНОГО ЧИСЛА ----      FLD       ST              ;РАЗМНОЖИЛИ ПОЛОЖИТЕЛЬНОЕ ЧИСЛО      POP       ECX             ;ОПЯТЬ ДОСТАЛИ ДЛИНУ СТРОКИ      FXTRACT                   ;РАЗДЕЛИЛИ МАНТИССУ И ПОРЯДОК      PUSH      ECX             ;ОПЯТЬ СОХРАНИЛИ ДЛИНУ СТРОКИ      FSTP      ST              ;ВКИНУЛИ МАНТИССУ      SUB       ESP,11          ;ВДЕЛИЛИ МЕСТО ПОД МАНТИССУ КАК BCD      FIST32P   [ESP]           ;ЗАПИСАЛИ ПОРЯДОК      CMP       D PTR [ESP],53  ;ОН УЖЕ 53 РАЗРЯДА ?      JE        M0003           ;ТОГДА МАНТИССА УЖЕ ГОТОВА      JL        M0002           ;ИНАЧЕ ЧИСЛО ОЧЕНЬ МАЛО;---- УМЕНЬШЕНИЕ ПОРЯДКА ЧИСЛА ОТ ОЧЕНЬ БОЛЬШОГО ----M0001:FLD       ST              ;РАЗМНОЖИЛИ ЧИСЛО      FXTRACT                   ;РАЗДЕЛИЛИ МАНТИССУ И ПОРЯДОК      FSTP      ST              ;ВКИНУЛИ МАНТИССУ      FIST32P   [ESP]           ;ДОСТАЛИ ПОРЯДОК      CMP       D PTR [ESP],53  ;УЖЕ 53 РАЗРЯДА ?      JLE       M0003           ;ТОГДА МАНТИССА УЖЕ ГОТОВА      FIDIV16   [EDX]           ;РАЗДЕЛИЛИ ЧИСЛО НА ДЕСЯТЬ      JMPS      M0001           ;ПРОВЕРЯЕМ НОВЙ ПОРЯДОК;---- УВЕЛИЧЕНИЕ ПОРЯДКА ЧИСЛА ОТ ОЧЕНЬ МАЛОГО ----M0002:FLD       ST              ;РАЗМНОЖИЛИ ЧИСЛО      FXTRACT                   ;РАЗДЕЛИЛИ МАНТИССУ И ПОРЯДОК      FSTP      ST              ;ВКИНУЛИ МАНТИССУ      FIST32P   [ESP]           ;ДОСТАЛИ ПОРЯДОК      CMP       D PTR [ESP],53  ;УЖЕ 53 РАЗРЯДА ?      JGE       M0003           ;ТОГДА МАНТИССА УЖЕ ГОТОВА      FIMUL16   [EDX]           ;УМНОЖИЛИ ЧИСЛО НА 10      JMPS      M0002           ;ПРОВЕРЯЕМ НОВЙ ПОРЯДОК;---- ВДАЧА МАНТИСС В ДВОИЧНО-ДЕСЯТИЧНОМ ВИДЕ ----M0003:FBSTP     [ESP]+1         ;ЗАПОМНИЛИ МАНТИССУ КАК BCD-ФОРМАТ;---- ФОРМИРОВАНИЕ ТЕКСТА ИЗ BCD-МАНТИСС ----      LEA       EDI,[ESI]+1     ;АДРЕС ОТВЕТА ПОСЛЕ ЗНАКА      FLD1                      ;ЗАГРУЗИЛИ КОНСТАНТУ 1E0      SUB       CL,7            ;ЗАДАННАЯ ДЛИНА МАНТИСС В ОТВЕТЕ      FLD64     [EBX]           ;ОПЯТЬ ЗАГРУЗИЛИ ИСХОДНОЕ ЧИСЛО      LEA       ESI,[ESP]+10    ;АДРЕС ПЕРВХ ЦИФР МАНТИСС      STD      MOV       DH,0            ;ПОКА НУЛИ НЕ ПИШЕМ      FABS                      ;ЗНАК ИСХОДНОГО ЧИСЛА БОЛЬШЕ НЕ НУЖЕН      MOV       AH,0            ;НАЧИНАЕМ С ЧЕТНОЙ ТЕТРАД      FCOM                      ;ЗАРАНЕЕ СРАВНИВАЕМ ЧИСЛО С 1E0      MOV       BL,1            ;ПОКА ОНО МОЖЕТ БТЬ ВБЛИЗИ +1/-1;---- ЦИКЛ ПЕРЕПИСИ ПО ВСЕМ ТЕТРАДАМ BCD-МАНТИСС ----M0004:XOR       AH,1            ;ОЧЕРЕДНАЯ ТЕТРАДА      JZ        @               ;ЕСЛИ НЕЧЕТНАЯ ТЕТРАДА      LODSB                     ;ДОСТАЛИ БАЙТ МАНТИСС      CMP       ESI,ESP         ;ЗА ПРЕДЕЛАМИ МАНТИСС ?      MOV       DL,AL           ;ДВЕ ТЕТРАД МАНТИСС      JB        M0007           ;ЗАКОНЧИЛИ ВВОД;---- ЧЕТНАЯ ТЕТРАДА ----      SHR       AL,4            ;ЧЕТНАЯ ТЕТРАДА BCD      JMPS      M0005;---- НЕЧЕТНАЯ ТЕТРАДА ----@:    MOV       AL,DL      AND       AL,0FH          ;НЕЧЕТНАЯ ТЕТРАДА BCD;---- ПРОПУСК ЛИДИРУЮЩИХ НУЛЕЙ МАНТИСС ----M0005:OR        DH,AL           ;ЕЩЕ ИДУТ НУЛИ МАНТИСС ?      JNZ       @               ;УЖЕ ИДУТ ЦИФР МАНТИСС      INC       ECX             ;НЕ УЧИТВАЕМ ЭТОТ НОЛЬ В МАНТИССЕ      JMPS      M0006           ;ПРОПУСКАЕМ НЕЗНАЧАЩИЙ НОЛЬ;---- ПРОВЕРКА НА ВСЕ ДЕВЯТКИ (Т.Е. НА ЧИСЛО ВБЛИЗИ +1/-1) ----@:    CMP       AL,9            ;ИДУТ СПЛОШНЕ ДЕВЯТКИ ?      JZ        @               ;ДА, ПРОДОЛЖАЮТСЯ ДЕВЯТКИ      MOV       BL,0            ;УЖЕ НЕ ВБЛИЗИ +1/-1 (НЕ ДЕВЯТКА);---- ПРОПУСК ТОЧКИ, ЗАРАНЕЕ ЗАПИСАННОЙ В ОТВЕТ ----@:    CMP       B PTR [EDI],'.' ;ЗДЕСЬ В ШАБЛОНЕ ТОЧКА ?      JNZ       @      INC       EDI             ;ПРОПУСКАЕМ ТОЧКУ;---- ЗАПИСЬ ОЧЕРЕДНОЙ ЦИФР МАНТИСС КАК ТЕКСТА ----@:    ADD       [EDI],AL        ;ПИШЕМ ОЧЕРЕДНУЮ ЦИФРУ В ОТВЕТ      INC       EDI             ;СЛЕДУЮЩИЙ АДРЕСM0006:LOOP     M0004            ;ЗА СЛЕДУЮЩЕЙ ТЕТРАДОЙM0007:CLD;---- ФОРМИРОВАНИЕ ВЕЛИЧИН ПОРЯДКА ----      MOV       ESI,OFFSET ДЕСЯТЬ      FNSTSW    AX      XOR       EDX,EDX         ;ПОКА ПОРЯДОК НОЛЬ      SAHF      JZ        M0011           ;ЧИСЛО СТРОГО РАВНО 1 - ПОРЯДОК НОЛЬ      JA        M0009           ;ЧИСЛО БОЛЬШЕ 1 - ПОРЯДОК ПОЛОЖИТЕЛЕН      MOV       B PTR [EBP]-1,'-' ;ОТМЕТИЛИ ОТРИЦАТЕЛЬНЙ ПОРЯДОК;---- УВЕЛИЧЕНИЕ ПОРЯДКА ДО ЧИСЛА БОЛЬШЕ 1 ----M0008:FIMUL16   [ESI]           ;УВЕЛИЧИЛИ ЧИСЛО В 10 РАЗ      INC       EDX             ;УВЕЛИЧИЛИ ПОРЯДОК      FCOM                      ;СРАВНИВАЕМ С 1      FNSTSW    AX              ;ЗАПОМНИЛИ РЕЗУЛЬТАТ СРАВНЕНИЯ      SAHF      JZ        M0011           ;СТРОГО РАВНО 1 - НАШЛИ ПОРЯДОК      FLD       ST              ;РАЗМНОЖИЛИ ЧИСЛО      FSUB      ST,ST2          ;РАЗНИЦА С 1      FXTRACT                   ;ДОСТАЛИ МАНТИССУ И ПОРЯДОК      FSTP      ST              ;ВБРОСИЛИ МАНТИССУ      FIST32P   [ESP]           ;ПОРЯДОК РАЗНИЦ      CMP       D PTR [ESP],-53 ;УЖЕ ВПЛОТНУЮ К 1 ?      JLE       M0010           ;ДА, ВПЛОТНУЮ, БЛИЖЕ НЕ БУДЕТ      SAHF                      ;ОПЯТЬ ДОСТАЛИ ФЛАГИ СРАВНЕНИЯ С 1      JA        M0011           ;УЖЕ БОЛЬШЕ - НАШЛИ ПОРЯДОК      JMPS      M0008           ;ПРОДОЛЖАЕМ УМНОЖАТЬ НА 10;---- УМЕНЬШЕНИЕ ПОРЯДКА ДО ЧИСЛА МЕНЬШЕ 1 ----M0009:FIDIV16   [ESI]           ;УМЕНЬШИЛИ ЧИСЛО В 10 РАЗ      INC       EDX             ;УМЕНЬШИЛИ ПОРЯДОК      FCOM                      ;СРАВНИВАЕМ С 1      FNSTSW    AX              ;ЗАПОМНИЛИ РЕЗУЛЬТАТ СРАВНЕНИЯ      SAHF      JZ        M0011           ;СТРОГО РАВНО 1 - НАШЛИ ПОРЯДОК      FLD       ST              ;РАЗМНОЖИЛИ ЧИСЛО      FSUB      ST,ST2          ;РАЗНИЦА С 1      FXTRACT                   ;ДОСТАЛИ МАНТИССУ И ПОРЯДОК      FSTP      ST              ;ВБРОСИЛИ МАНТИССУ      FIST32P   [ESP]           ;ПОРЯДОК РАЗНИЦ      CMP       D PTR [ESP],-53 ;УЖЕ ВПЛОТНУЮ К 1 ?      JG        @               ;ЕЩЕ НЕ ВПЛОТНУЮM0010:INC       EBX             ;ПРИЗНАК НАХОЖДЕНИЯ ВБЛИЗИ 1      JMPS      M0011           ;ПЕРЕСТАЕМ ИСКАТЬ ПОРЯДОК@:    SAHF                      ;ОПЯТЬ ЗАГРУЗИЛИ ФЛАГИ СРАВНЕНИЯ С 1      JNB       M0009           ;ПРОДОЛЖАЕМ ДЕЛИТЬ НА 10      DEC       EDX             ;ЧИСЛО В ОТВЕТЕ ДОЛЖНО БТЬ БОЛЬШЕ 1M0011:ADD       ESP,11          ;ОСВОБОДИЛИ СТЕК ОТ BCD-МАНТИСС;---- КОРРЕКТИРОВКА ПОРЯДКА ВБЛИЗИ +/-1 ----      CMP       BL,2            ;БЛИ ВСЕ ДЕВЯТКИ И ПОЧТИ 1 ?      XCHG      EAX,EDX         ;ДОСТАЛИ ЗНАЧЕНИЕ ПОРЯДКА      JNZ       @               ;НЕТ, ЧИСЛО НЕ ВБЛИЗИ 1      DEC       EAX             ;ВБЛИЗИ 1 СВЕРХУ, ДЕЛАЕМ 0.999...E+000      CMP       B PTR [EBP]-1,'-' ;ЧИСЛО МЕНЬШЕ 1E0 ?      JNZ       @               ;НЕТ, БОЛЬШЕ      INC       EAX             ;ВЕРНУЛИ ПОРЯДОК      INC       EAX             ;ВБЛИЗИ 1 СНИЗУ,  ДЕЛАЕМ 9.999...E-001;---- ЗАПИСЬ СТАРШЕЙ ЦИФР ПОРЯДКА ----@:    PUSH      100      XOR       EDX,EDX      POP       EBX             ;ДЕЛИМ НА КОНСТАНТУ 100      FSTP      ST              ;ОЧИЩАЕМ FPU ОТ ПОИСКА ПОРЯДКА      DIV       EBX             ;ПОЛУЧАЕМ ЧАСТНОЕ - ПЕРВУЮ ЦИФРУ      ADD       [EBP],AL        ;СТАРШАЯ ЦИФРА ПОРЯДКА;---- ЗАПИСЬ ДВУХ МЛАДШИХ ЦИФР ПОРЯДКА ----      MOV       BL,10           ;ДЕЛИМ НА КОНСТАНТУ 10      XCHG      EAX,EDX         ;ОСТАТОК ОТ ДЕЛЕНИЯ НА 100      DIV       BL              ;ЧАСТНОЕ И ОСТАТОК - ДВЕ ЦИФР ПОРЯДКА      FSTP      ST              ;ВБРОСИЛИ КОНСТАНТУ 1 ИЗ FPU      ADD       [EBP]+1,AX      ;ДВЕ ОСТАЛЬНЕ ЦИФР ПОРЯДКА;---- ВХОД С ОТВЕТОМ В СТЕКЕ И ДЛИНОЙ СТРОКИ В AL ----      POP       EAX             ;ДЛИНА СТРОКИ ОТВЕТА В СТЕКЕ      RET      DSEGДЕСЯТЬ DW 10                    ;БАЗА ДЛЯ ПЕРЕВОДА В ДЕСЯТИЧНУЮ СИСТЕМУ

Заключение

Использование команд FPU сделало данную реализацию довольно компактной (326 байт команд) и удовлетворительной по скорости. Например, на компьютере с процессором Intel Core Solo 1.33 GHz сто миллионов преобразований числа 1234.567890 в текст заняли 89 секунд.

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

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

Введение

Впервые термин экстракод я услышал еще применительно к командам БЭСМ-6. Сейчас это слово практически не используется, наиболее близкое понятие - системный вызов. Из-за особенностей системы команд БЭСМ-6, те экстракоды действительно больше напоминали дополнительные встроенные инструкции, чем, например, вызов функции в MS-DOS с помощью INT 21H.

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

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

Пример использования экстракода при компиляции

Я утверждаю, что понятия языка PL/1 лучше, чем у многих других языков отражены в командах архитектуры IA-32, поскольку в момент разработки процессора 8086 (вторая половина 70-х годов) требования поддержки языков высокого уровня ориентировались на основные языки того времени, среди которых заметное место занимал и PL/1.

Рассмотрим на простом примере, как понятия языка высокого уровня преобразуются в команды IA-32. Например, в PL/1 есть такие объекты, как строки постоянной длины.

В рассматриваемом подмножестве языка длина такой строки не должна превышать число, занимающее байт. Со строками можно работать различным образом, например, сравнивать на равенство или даже на больше-меньше. А в архитектуре IA-32 есть команда CMPSB, которая как раз и сравнивает две цепочки байт в памяти. Казалось бы, и компилятор должен реализовать сравнение строк постоянной длины с помощью одной этой команды (с повторением) REPE CMPSB. Однако на самом деле сравнение реализовано так:

declares1 char(10),s2 char(15);if s1>s2 then BF0A000000          mov    edi,offset S2B00F                mov    al,15BE00000000          mov    esi,offset S1B10A                mov    cl,10E800000000          call   ?SCCCM7505                jbe    @1

Почему же даже для такой простой операции потребовался системный вызов? Дело в том, что команда CMPSB близка к понятию сравнения строк в PL/1, но не полностью совпадает. В языке, если сравниваются две строки разной длины, то сначала более короткая из них дополняется пробелами, а уже после идет само сравнение.

Команда же CMPSB по определению не сравнивает строки разной длины. Зачем же потребовалось вводить в язык такое странное требование, как продолжать сравнивать одну строку, когда другая уже закончилась? Как раз в понятиях языка все логично. Короткая строка дополняется пробелами не только при сравнении, но и при присваивании в более длинную строку. Тогда после такого присваивания и сравнения, получится правильный результат строки равны, хотя они и продолжают иметь разную длину. Если же заканчивать сравнение по исчерпанию одной из строк, можно получить неверный результат сравнения, например, для строк 12345 и 123456, которые, очевидно, не равны.

Вот если бы в процессоре была команда сравнения PL1_CMPSB, которая не только бы выполняла действия, аналогичные CMPSB, но и по значению, скажем, в регистре AL определяла бы, сколько еще байт осталось в более длинной строке и сравнивала бы этот остаток с пробелами, вот тогда компилятор мог бы генерировать сравнение строк в смысле языка PL/1 одной этой командой.

А ведь в примере компилятор как раз это и делает. Только несуществующую команду PL1_CMPSB он заменяет вызовом системной подпрограммы, которую я называю экстракодом. Этот конкретный экстракод имеет странное имя-аббревиатуру ?SCCCM, буквы которой систематизированы и в данном случае показывают, что идет работа со строками (String) и сравниваются (Compare) две строки постоянной длины (Сhar и Char), находящиеся не в стеке, а в статической памяти (Memory). Система при составлении названий экстракодов нужна, поскольку их разновидностей достаточно много.

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

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

Первое отличие экстракодов от обычных вызовов подпрограмм это отсутствие общих правил передачи параметров. В этом они больше похожи на команды IA-32, где тоже нет общих правил, а в каждом случае могут быть свои. Например, просто из вида команды REPE CMPSB, не имеющей параметров, невозможно догадаться, что она одновременно использует и меняет регистры ESI, EDI и ECX.

Конечно, и передача параметров в обычные подпрограммы может быть организована через регистры, а не, например, через стек. Собственно так и сделано в 64-разрядных Windows API, где используются регистры RCX, RDX, R8 и R9. Но там всегда используются эти регистры, в то время как в каждом конкретном экстракоде (как и в каждой конкретной команде) могут быть разные. Поэтому в приведенном выше примере загрузка адресов и длин строк идет в конкретные регистры, сразу, так сказать, на свои места и дополнительных пересылок внутри экстракода уже не требуется.

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

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

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

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

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

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

Да и слово интринсик очень неудобопроизносимое по-русски.

Типы экстракодов при компиляции выражений

Несмотря на то, что входные и выходные параметры экстракодов могут быть организованы совершенно по-разному, при компиляции выражений над объектами, которые не помещаются в обычные регистры (например, строки или даже 8-байтные числа в формате IEEE-754), получается 4 группы схожих экстракодов, в зависимости от операндов или как просто переменных, или как результатов предыдущих вычислений. Например, вот 4 разновидности экстракода операции деления :

declare(x,y,z) float(53);z=x/y;          оба операнда в переменных, экстракод деления ?FDF_Mz=(x+1)/y;      левый операнд в стеке,     экстракод деления ?FDF_Lz=x/(y+1);      правый операнд в стеке,    экстракод деления ?FDF_Rz=(x+1)/(y+1);  оба операнда в стеке,      экстракод деления ?FDF_S

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

В случае работы с FPU процессора в большинстве случаев используется стек FPU, а не стек самого процессора. Только в этом случае последний из типов экстракода, например, деления ?FDF_S может быть сведен к генерации единственной команды FDIV.

Наибольшее число разновидностей экстракодов получается при работе с комплексными числами, поскольку в этом случае каждая из 4 групп экстракодов делится еще на 3 подгруппы, в зависимости оба ли операнда комплексные или один операнд комплексный, а другой действительный.

Пример оптимизации при использовании экстракодов

Рассмотрим еще один простой пример, часто встречающийся в программах на PL/1:

s=substr(s,2); 

Здесь из строки s выбрасывается первый символ, что обычно используется в цикле обработки символов, пока строка s не станет пустой. В данном случае обрабатывается объект строка переменной длины (ее текущая длина записана первым байтом по адресу строки).

declares char(*) varying;s=substr(s,2);B202                mov    dl,2BE00000000          mov    esi,offset S8BFE                mov    edi,esiE800000000          call   ?VS2ADE800000000          call   ?SMCVF

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

Причина, по которой нельзя выполнить это прямо двумя командами типа LEA ESI,[ESI+EDX]-1 и REP MOVSB по сути та же самая, что и в предыдущем примере: эти команды близки, но не тождественны командам PL/1-машины выделение подстроки и присвоение строке.

Поэтому хотя команды LEA и MOVSB и являются основами соответствующих экстракодов, требуется выполнить еще ряд действий. Например, при выделении подстроки в смысле PL/1 нужно еще убедиться, что строка не пустая и заданное начало подстроки не выходит за ее границу. А при присваивании строки в общем случае может еще потребоваться дописывание пробелами, как и в разобранном выше сравнении строк.

В данном примере видно, как информация о работе экстракодов используется для сокращения команд подготовки параметров. Компилятор знает, что экстракод выделения подстроки ?VS2AD не использует EDI и поэтому сразу загружает его значением, нужным для последующей пересылки. А поскольку это значение сначала совпадает с загрузкой ESI, вместо команды mov edi,offset s используется более короткая команда mov edi,esi.

Экстракод ?VS2AD возвращает результат через регистр ESI (начало подстроки) и AL (длина подстроки), причем всегда еще и CL=AL. Для работы второго экстракода пересылки ?SMCVF нужно установить значения в регистры ESI, EDI и CL, поскольку внутри все сведется, в конце концов, к выполнению команды REP MOVSB.

Но регистр EDI уже установлен, нужное значение в регистре ESI загружено после работы первого экстракода и в CL уже находится длина переписываемой подстроки. Поэтому компилятору можно сразу генерировать вызов второго экстракода без дополнительных загрузок регистров. Получается, что на выполнение оператора отбрасывания первого символа строки в программе потребовалось всего 19 байт кодов.

При этом выполнение требуемых действий осуществляется внутри экстракодов максимально эффективно для архитектуры IA-32, а именно командами загрузки адреса LEA и цепочечной пересылкой MOVS. Кроме этого внутри экстракодов выполняются дополнительные проверки и действия, необходимые для соблюдения требований языка PL/1. Компилятору не нужно каждый раз генерировать эти действия, он имеет дело только с экстракодами, по существу со своей специальной системой команд.

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

Отличие компилятора от транслятора

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

В определении отличия компилятора от транслятора, на мой взгляд, существует некоторая путаница. Например, в Википедии прямо написано, что компиляция это трансляция программ. Получается, что компилятор и транслятор это одно и то же.

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

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

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

Случай совпадения команд виртуальной и реальной машины

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

declare(x,y,z) fixed(31);x=y*10-z/4;6B05040000000A      imul   eax,Y,108B1D08000000        mov    ebx,ZC1FB02              sar    ebx,22BC3                sub    eax,ebxA300000000          mov    X,eax

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

Экстракоды и CISC-команды

Анализ применения экстракодов заставил даже по-новому взглянуть на RISC- и CISC-процессоры (т.е. на процессоры с сокращенным и обычным набором команд).

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

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

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

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

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

Заключение

Технология генерации программ с помощью экстракодов, как и любая другая, имеет и достоинства и недостатки.

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

Использование экстракодов с одной стороны несколько усложняет компилятор, поскольку появляется большое число разновидностей передачи параметров и возврата результатов, что отражает архитектуру процессора, в данном случае команды IA-32. Зато, с другой стороны, весь процесс компиляции упрощается и сводится к единообразным вызовам экстракодов даже в случае достаточно сложных действий, над сложными объектами, описанными в программе.

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

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

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

Введение

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

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

Подготовка

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

Почему мне понадобился именно металлургический микроскоп, а не стереомикроскоп или не составной микроскоп? Потому что у большинства микроскопов подсветка снизу, и свет отражается от двухкоординатной пластины, а с ИС так работать нельзя, поскольку они не двусторонние. Рассматриваемые слои кристалла нужно правильно освещать, чтобы свет как следует отражался в направлении сверху вниз. В металлургических микроскопах используется так называемое наблюдение в отраженном свете (EPI illumination), уникальный тип освещения, также именуемого эпифлуоресцентным. Решение позволяет не только освещать объект ИС/образец; более того, объектив микроскопа собирает свет, отражающийся от поверхности образца.

Остальное вполне понятно без объяснения. Чтобы как следует извлечь ИС из ее эпоксидной упаковки, мало обработать упаковку кислотой при комнатной температуре так всю смолу удалить не удастся. Некоторые другие закупленные мной материалы, перечисленные в списке это вполне стандартные лабораторные исходники, которые понадобятся вам для работы с химикатами. Что касается химикатов как таковых, я расскажу обо всех используемых кислотах, основаниях и окислителях, по мере того, как буду описывать ход экспериментов.

Выбор лабораторного образца

Забавно, что когда я впервые вскрыл CH340Gиз платы Arduino Nano v3, я даже не подозревал, что наткнусь на целую секцию ПЗУ, прежде, чем приступлю к послойному препарированию. Как правило, берясь за проект с ПЗУ, нужно весьма хорошо понимать выбранный образец, в частности, познакомиться с его архитектурой и процессором, почитав даташиты. К счастью, у меня все вышло иначе, почему к счастью расскажу дальше, читайте.

Я взялся за распайку интегральных схем с платы Arduino прежде всего потому, что это была первая разработочная плата, которую я освоил в ходе моих упражнений по части безопасности встраиваемых систем. Следовательно, заключил я, можно будет знатно поностальгировать, бросив пару столь любимых мною чипов в жаркую дымящую серную кислоту. Честно говоря, я очень надеялся, что в ATmega328P, с которой я проводил мои первые эксперименты, найдется какое-нибудь ПЗУ, но, после многократных попыток разобрать ее по слоям при помощи плавиковой кислоты, я нашел только ЭСППЗУ, статическую память с произвольным доступом и флэш-память.

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

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

Сравнение флэш-памяти и ПЗУ. Как они выглядят под микроскопом

Возможно, вас интересует, а почему нельзя попросту считывать данные из сегментов флэш-памяти при помощи металлургического микроскопа, как это делалось бы с ПЗУ? Для начала давайте обсудим разницу. Масочное ПЗУ (MROM) содержит код прошивки, записываемый в кремниевую основу чипа на этапе конструирования в процессе производства полупроводника. МПЗУ производится путем расстановки транзисторов еще до начала процесса фотолитографии. Под микроскопом они могут весьма отличаться друг от друга:

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

С другой стороны, флэш-память устроена сложнее. 1 транзистор != 1 бит. Причина, по которой сканирующий электронный микроскоп требуется для вытягивания бит из памяти типа ЭСППЗУ в том, что во флэш-памяти используется система карманов, в которых можно запасать остаточные электроны от пропускаемого тока, независимо от того, идет ли ток через схему в настоящий момент. Соответственно, такая память считается энергонезависимой. Во флэш-транзисторе четыре основные части: источник, сток и два затвора, которые называются плавающим и управляющим[1][2], а также изолирующий материал, отделяющий три остальные части друг от друга. По форме вся структура напоминает перевернутую букву Т, причем, в нижней части транзистора располагаются источник и сток, а в верхней части затворы, причем, управляющий затвор находится выше плавающего. Затворы заключены в оксидные слои, через которые ток, как правило, не проникает.

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

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

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

Как считываются биты

Причина, по которой под металлургическим микроскопом различимы отдельные биты (единицы и нули) в том, что биты физически закодированы в кристалле. Как показано в статье Кена ШириффаExtracting ROM Constants, биты программируются в МПЗУ путем изменения паттерна допирования кремния, создания транзисторов или оставления изолирующих участков. В примере Кена, если в строке присутствует транзистор, то можно предположить, что это транзистор в 1 бит. Как правило, строка в МПЗУ NOR (чтение быстрее, запись медленнее) будет содержать два транзистора, уложенных друг на друга, верхний и нижний, как показано на следующем рисунке.

В ПЗУ обычно используются мультиплексоры для выбора бит по столбцу и по строке. При использовании 16-битного MUX будет 4 линии выбора, которые можно активировать. Для ПЗУ, которое я собираюсь показать, каждая линия выбора может перевести транзисторы в состояние напряжения HIGH, если будет активирована. Если в заданной позиции (столбец и строка) транзистор отсутствует, то выходная линия окажется в состоянии напряжения LOW.

Примечание:В нашем случае с CH340G МПЗУ будет выглядеть совершенно иначе, нежели на картинках, показанных выше.

Подготовка образца

В случае Arduino Nano, CH340G всегда находится снизу печатной платы. Я вооружился тепловым пистолетом для отпайки и под температурой около 200C обработал пины интересовавшего меня чипа микросхемы. Таким образом припой снимается с узлов и расплавляется, что позволяет безопасно снять чип с платы.

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

Химические реакции при вскрытии

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

Рекомендую температуру не менее 170C, а не 150C, как показано выше, поскольку плитка никогда не показывает температуру абсолютно точно. Такой сильный жар нужен, поскольку при комнатной температуре HSOокисляет эпоксидную смолу очень медленно. Нагревая образец, можно ускорить эту реакцию. На крайней справа картинке видно, как жидкость начинает приобретать желтоватый цвет, и это просто отлично. Это означает, что реакция пошла, и эпоксидная смола начинает плавиться.

Если вам интересно, зачем стакан прикрыт стеклянной крышкой объясню, на то есть две причины:

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

2. Потенциально крышка может поспособствовать частичной рециркуляции паров диоксида серы (SO), что, в свою очередь, будет поддерживать высокую концентрацию кислоты. Если концентрация кислоты чрезмерно снизится, то возрастет вероятность коррозии. Я не вполне в этом уверен, поэтому смело пингуйте меня, если я не прав. Знаю, что такой подход хорош при работе с азотной кислотой (HNO), поскольку пары диоксида азота (NO) при рециркуляции могут превращаться обратно вHNOв присутствии воды.

Большой вопрос как долго это должно продолжаться? Зависит от толщины чипа; в данном конкретном случае, согласно даташиту, мы имеем дело с корпусом кристалла SOP-16, толщина которого составляет около 1,50 мм. При приблизительно такой толщине и температуре весь процесс должен занять около часа.

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

Примечание: как только вы снимете крышку со стакана, оттуда сильно попрут парыSO, поэтому убедитесь, что дымовые заслонки как следует закрыты, надежно удалите все эти токсичные пары через вакуумный отсос. Хороший пример, позволяющий оценить, как идет эта реакция повторить подобный опыт с полиэтиленом ((CH)), который обычно входит в состав эпоксидного пластика. По мере того, как серная кислота разогревает эпоксидную смолу, HSOразлагается наSO,CO иHO. Вот химическое уравнение с коэффициентами:6HSO + (CH) 6SO +2CO +8HO. Точка кипения такой кислоты составляет около 337C, именно в таких условиях обычно и получают азеотропную серную кислоту. Если взять серу (S), кислород (O) и воду (HO), а затем сжечь серу для получения диоксида серы (SO);S + O SO, то в дальнейшем диоксид серы можно окислить до триоксида серы (SO), воспользовавшись кислородом и взяв в качестве катализатора оксид ванадия (VO), имеем2SO + O + VO 2SO. Вода служит для гидратации триоксида серы в серную кислоты,SO + HO HSO. Могут использоваться и иные методы, например, с добавлением электролизованных растворов, таких, как раствор сульфата меди (II) (CuSO) или бромводородной кислоты (HBr) для реакции с серой.

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

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

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

Исследуем первый образец

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

Впервые взглянув на этот чип, я не нашел ничего, что напоминало бы ПЗУ; учитывая, что я знаю сейчас, я кажусь себе в тот момент довольно глупым. Еще немного разобравшись, я смог предположить, что в левой части содержится какая-то ЭСППЗУ или ОЗУ, либо это просто какая-то емкость для энергозависимой памяти. Область сверху справа, казалось, отведена под МПЗУ. Итак, разбираемся дальше.

Присмотревшись к логическим вентилям через объектив с 50-кратным увеличением, постепенно начинаем понимать, что здесь происходит. Первым делом интересно отметить, что на этом ПЗУ 14 мультиплексоров, то есть, 14 групп столбцов. Каждый мультиплексор имеет разрядность 16:1. Таким образом, он позволяет проложить 16 различных путей данных на месте единственного.

14 групп столбцов значит, мы имеем дело с 14-битной архитектурой, и это странно. Как правило, встречаются микропроцессоры в диапазоне 4 бит, 8 бит, 16 бит или даже 32 бит. Ситуация значительно усложнится позже, после извлечения бит из этих изображений, так как мы, вероятно, имеем дело с нетипичной архитектурой.

Также нужно отметить следующие наблюдения. Во-первых, верхние слои в этом чипе представляют собой адресные строки. В вертикальном столбце видим 10 металлических линий, которые в итоге транслируются в 6 адресных разрядов, а 6 металлических линий по горизонтали транслируются в 4 адресных разряда. Суть этого будет объяснена ниже, когда мы займемся послойным препарированием чипа, 4 адресных разряда дадут нам 2 = 16для мультиплексоров, описанных выше. Теперь 6 адресных строк будут использоваться, чтобы выбрать одну из 64 строк в пространстве ПЗУ, что даст 16 бит x 14 столбцов по горизонтали. Вот почему нам требуется суммарно 10 адресных разрядов по вертикали.

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

Реакции послойного препарирования

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

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

Итак, как же определить, какую кислоту использовать? Как правило, в процессе производства полупроводников используется два типа металлов: алюминиевый (Al) сплав 6061 и/или медь (Cu). В чипах, подобным рассматриваемому, обычно встречается Al, но изредка может бытьCu. Дело в том, что у меди ниже сопротивление, и это положительно сказывается на включаемости металлов.

Если работать сCu, то приходится использовать HCl, посколькуHFне вытравливаетCu и, фактически, спровоцирует сильную коррозию, вызываемую атмосферным кислородом. Любой окислительный агент плохо подойдет вам для послойного препарирования Cuс использованиемHF. Помните, чтоHClсама по себе также не будет вытравливатьCu, к ней нужен окислительный агент, например, пероксид водорода (HO), который позволит кислоте съесть всю Cu(восстановительный агент), поднимая pKa (константу диссоциации) кислотного раствора. Значение pkA характеризует силу кислоты. Две эти реакции вместе в соотношении 1:1 позволяют получить хлорноватистую кислоту (HOCl) и воду (HO). Как только в реакцию входит Cuиз кристалла, медь прореагирует сHOCl, и получится хлорид меди (II), который и станет нашим травящим агентом. Таким образом, мы послойно препарируем медную область кристалла при комнатной температуре до получения зеленоватого раствора хлорида меди (CuCl).

HO (aq.) + HCl (aq.) HO + HOCl (aq.)
2HOCl + Cu Cu(HOCl)

Примечание:Будьте крайне осторожны, поскольку при комнатной температуре растворHCl, в отличие от большинства кислот, быстро разогревается и, скорее всего, будет выделять газообразный хлороводород. Это нужно делать[1][2] в вытяжном шкафу.

В нашем случае, при работе с CH340, нам придется протравить лишь очень тонкий слой Al, а диоксида кремния (SiO) там почти нет. Вот почему при послойном препарировании мы будем использовать HF. Влажная HFочень быстро накидывается на алюминиевые связи и контактные площадки при температуре выше 40C, но также можно вытравливать при комнатной температуре и очень низкой концентрации, используя Whink. Этот удалитель ржавчины содержит плавиковую кислоту в концентрации 3%, но не обманывайтесь, поскольку и это может быть более чем фатально. Рекомендую класть чип в тефлоновый химический стакан и держать его там при комнатной температуре с интервалами примерно в 15 минут, в зависимости от того, какой именно чип мы тестируем. Так будет вытравливаться не только Al, но иSiO.

SiO + 4HF SiF + 2HO

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

Итак, мы успешно протравили себе путь до самой подложки или уровня транзисторов в чипе. Изображение в более высоком разрешении предлагается наsiliconpr0n. Присмотревшись к правому верхнему углу, найдем наше драгоценное МПЗУ.

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

Автоматическое извлечение битов ПЗУ

Знакомьтесь сrompar, интерактивным инструментом для извлечения двоичных данных из изображений МПЗУ при помощи методов компьютерного зрения. На первых порах может быть немного страшновато, так как кривая обучения у него крутая, но после нескольких прогонов все будет уже не так плохо. Первым делом давайте подготовим наше изображение, либо в Gimp, либо в вашем любимом редакторе фотографий. Суть в следующем: нам нужно выделить и расширить область с МПЗУ на изображении, обрезать ее и увеличить ее резкость.

Перед запуском инструмента нужно узнать, с каким объемом ПЗУ нам придется работать. Смотрим на картинку и видим 14 групп столбцов, в каждом по 16 бит в строку, то есть, мы имеем дело с 224 бит в каждой строке. Строки следующая важная тема, которую мы обсудим, по-видимому, тут просматривается 64 строки. Таким образом, размер ПЗУ, с которым нам предстоит работать, составляет 1,7 Кб.

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

python3 rompar.py image1-50x-ROM.jpg 16 1
Changing edit mode to GRID
Changing edit mode to GRID
Image is 11694x4318; 3 channels
process_image time 0.18801593780517578
read_data: computing
grid line redraw time: 6.4373016357421875e-06
grid circle redraw time: 1.1920928955078125e-05
render_image time: 0.22574210166931152

А почему тут конфигурация 16x1? могли бы спросить вы. Потому, что, если взглянуть на картинку, заметен большой промежуток между 14 группами столбцов, поэтому мы и делим их на две части. То же касается и строк, по-видимому, между ними есть какой-то разделитель, поэтому мы не можем жестко закодировать строки.

Первый экран графического интерфейса (GUI), который мы рассмотрим, дан в инфракрасном спектре, чтобы по ярким и темным пятнам мы уяснили, чем допированный транзистор отличается от пустого места. Можно скорректировать порог, перейдя в CV Options -> Pixel Threshold. Корректируем, пока у нас не получится нечто подобное:

Нужно, чтобы программа поняла, что первая строка будет возвращать0000001, а второй01110101. Помните, что более яркие области принято обозначать через1, а более темные через0. При постобработке это правило по необходимости может инвертироваться, если нужно получить на выходе готовый двоичный файл. Теперь давайте перейдем к Display -> Base Image -> Original. Далее мы хотим сделать сетку из столбцов и строк, поэтому щелкнем ctrl+clickпо столбцу 1, перейдем к столбцу 16 и сделаем то же самое. Продолжаем, пока не обработаем все столбцы. В конечном итоге у нас должна получиться примерно такая сетка:

Голубые линии немного бледные, но при увеличении видны гораздо лучше. Теперь давайте подсветим отдельные биты. Нажимаем cmd+click в каждой строке, получаем следующее:

Как видите, тут есть несколько ошибок, но мы можем откорректировать отдельные разряды, перейдя в Edit -> Mode -> Data Edit Mode. Далее щелкнемctrl+clickпо каждому отдельному биту, чтобы превратить голубые кружочки в зеленые или наоборот. Программа трактует зеленые маркеры как 1, а голубые как0. К сожалению, с этим изображением ПЗУ мне пришлось многое редактировать вручную, но, как только результат нас устроит, можно экспортировать его в матрицу двоичных разрядов, перейдя в Data -> Export Data as Text. В итоге у вас получится файл со всеми вашими двоичными данными, такой, как выложен у меня на Github.

Декодируем биты

Теперь, когда у нас готовфайл битовой матрицы, время превратить его в удобочитаемый и дизассемблированный файл прошивки. Этого можно добиться при помощи одного из двух инструментов,zorromилиbitviewer. В принципе, если уже знаем архитектуру, то используем zorrom, утилиту, преобразующую данные из физического представления в логическое и обратно при работе с топологией памяти чипа. Как написано в README от Zorrom, например, фотография загрузочного ПЗУ, преобразованная в двумерный битовый массив (.txt) может быть преобразована в машинно-читаемый двоичный формат. Затем этот .bin можно эмулировать, дизассемблировать и т.д., делать с ним все, что вы бы делали с обычным файлом прошивки . У программы есть отличный API, чтобы писать и настраивать, как именно должно считываться ПЗУ; то есть, здесь указывается топология, порядок следования байтов, требуется или нет инвертирование битов, а также порядки битов на выходе.

Причина, по которой мы не можем сразу начать работать с zorrom в том, что мы не знаем тип процессора. Потратив дни и недели на изыскания в головной корпорации, WCH, я не нашел ничего и близко напоминающего 14-битную архитектуру. Размышляя, с чем же мы имеем дело, мы, возможно, найдем ответ только тупо присмотревшись, а для этого нужен такой инструмент как bitviewer. С этим инструментом единственная корректировка, которая нам потребуется подогнать файл двоичной матрицы под 16-битную архитектуру. По-видимому, эта программа не слишком хороша для работы с 14-столбцовыми группами, но это как раз нормально, поскольку, когда мы извлечем bin-файл, эти заполняющие байты не повлияют на информативные байты прошивки.

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

Вот что мы можем узнать из этой картинки. В ПЗУ 64 бит по вертикали и 16 x 14 по горизонтали; как я уже говорил, объем этого ПЗУ почти 2k. Выяснил, что для него нужно всего 10 адресных разрядов. В первом столбце транзисторов в вертикальных адресных разрядов за адресным битом 0 идет неадресный бит 0. В следующем столбце переключение происходит каждые два бита, и так далее. Я считаю, что здесь видно 4 бита по горизонтали и 6 битов по вертикали. У каждой строки должна быть дополнительная, чтобы по возможности упростить декодирование мультиплексорами 16:1. Если сделать очень сильное увеличение, то видно, что, благодаря мультиплексору экономится место, в которое можно добавить 14 инверторов, а не прокладывать дополнительную сигнальную строку по горизонтали.

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

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

Далее по списку нам нужно взглянуть на шестнадцатеричный дамп и посмотреть, есть ли там какие-то признаки, что мы правильно задали порядок. Для этого щелкнем по кнопке Byte view (hex). Прокручивая биты, ничего узнаваемого мы не увидим, так как 1) мы не знаем, как должны выглядеть коды операций, поскольку не знаем архитектуру и 2) мы пока не видим ни одной жестко закодированной последовательности символов. Так что мы полагаемся на то, что все-таки увидим здесь некие последовательности символов, по которым сможем судить, правильно ли выполнили декодирование.

Давайте кое-что откорректируем, нажав кнопку Export Options. Как видите, здесь мы можем откорректировать топологию ПЗУ, порядок следования байтов, а также внести еще некоторые изменения, например, инвертировать порядок бит. Большинство опций мы оставим без изменения, в том числе, порядок следования битов, который будет иметь вид:0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15. Иногда приходится немного поэкспериментировать, чтобы получить правильный порядок на выходе, но я после нескольких попыток обнаружил, что полезно расставить галочки вот здесь:Reverse output bit order иAddress run right-to-left. Теперь можем снова прокрутить шестнадцатеричное представление.

05C0: FE 73 FF DB EF ... .s...t...t.b.|.j
05D0: FE 50 C6 5F D6 ... .P._._.Q...P....
05E0: DD 74 DF F8 ED ... .t...&.m...S.p..
05F0: FF 6D ED 00 FF ... .m...y...|.....>
0600: FF 7A FF 6A ED ... .z.j.<.g.Z.X.s..
0610: D9 74 CE 65 ED ... .t.e...W.p...[..
0620: E6 F0 F5 5B F0 ... ...[.W.W.W.W....

По-прежнему никаких подвижек. Есть еще один вариант, который мы не проверили возможно, наши биты нужно инвертировать/перевернуть. То есть, единицы должны стать нулями и наоборот. К счастью, в bitviewer это сделать можно; щелкаем кнопкуSelect all, и программа подсветит все биты во всех строках и столбцах. Когда они будут подсвечены, нажмите Invert Sel.

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

0770: 10 03 10 09 ... .............U..
0780: 10 53 10 00 ... .S...B...2......
0790: 10 30 10 00 ... .0...-..3...3...
07A0: 33 F3 10 00 ... 3...3...3...3...
07B0: 2F A4 10 00 ... /.....(.....+...
07C0: 10 23 29 08 ... .#)...../.. .'/.
07D0: 10 02 10 03 ... ..../.....+..P.S
07E0: 2F A4 10 72 ... /..r.e/..i.r/..n
07F0: 10 6D 2F A4 ... .i/..t.a+.. .l..

Я этого на первый взгляд не заметил, но теперь же у нас есть полноценный файл прошивки, и мы можем его изучить! Посмотрев на отступы0x0770и0x0780, можно выделить последовательность символов USB 2.0. Что еще? Следующую последовательность заметить не так легко, поскольку между первой и второй большой скачок. Последовательности символовPrintиSerialнаходятся на отступах0x07D00x07F0. Другие интересующие нас подсказки будут в верхней части файла прошивки, например, та или иная таблица переходов и /или таблица векторов исполнения. Из этого сделаем вывод о наличии повторяющихся инструкций или, в нашем случае, байт.

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

Примечание:Возвращаясь к использованию zorrom, теперь мы знаем, какие опции нужны, чтобы получился правильный файл прошивки. Значит, мы можем автоматизировать этот процесс, написав подходящий алгоритм. Воспользовавшись API zorrom, пользователю всего-то останется скормить программе двоичный текстовый файл, а в ответ она выдаст файл прошивки. Здесь можете посмотреть код, который я написал для CH340. Этот инструмент можно запустить вот так:

python3 txt2bin.py --arch ch340t ch340_binary.txt ch340_fw.bin

Также отметим, что при работе сzorrom не приходится заботиться о заполнении разрядов в двоичном текстовом файле, чтобы получилось 16 групп столбцов, нам вполне хватит наших исходных 14. Не забывайте, что иногда можно получить неверную ориентацию, извлекая биты с изображений. Расположение может случайно получиться зеркальным, либо придется определить, как правильно повернуть чип. Если дампировать двоичный текстовый файл, подобный тому, ссылка на который дана выше, то можно воспользоваться инструментом вроде rotate, чтобы просто перевернуть текст в файле вверх тормашками.

Дизассемблирование неизвестного

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

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

Итак, в данном случае мы рассматриваем весь чип, а не только ПЗУ:

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

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

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

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

Убираем за собой. Кислотно-основная нейтрализация

Серную кислоту (HSO) можно нейтрализовать при помощи исключительно сильной щелочи, гидроксида натрия (NaOH). Эта кислота реагирует сNaOH, продуктами реакции являются сульфат натрия (NaSO) и вода. Это реакция кислотно-основной нейтрализации. После расстановки коэффициентов в уравнении видим, что нужное нам соотношение между щелочным раствором и кислотой 2:1.

2NaOH (aq) + HSO (aq) 2HO (l) + NaSO (aq)

В нашем случае мы воспользуемся гораздо более высоким соотношением, поскольку, как помните, мы задействовали всего 20 мл HSOдля декапсуляции чипа.NaOH существует в форме кристаллов, напоминающих соль, и всего 15 граммNaOHна 150 мл воды (раствор 10%) хватит для приготовления раствора. NaOH+HOдадут раствор с катионамиNa+и анионами OH-, дополнительно выделится некоторое количество тепла. Уравнение реакции выглядит так:

NaOH +2HO Na+ + OH- + HO (delta H < 0)

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

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

Спасибо, что дочитали! Надеюсь, вам понравилось не меньше, чем мне. Если у вас остались вопросы по этой статье, пишите мне пожалуйста в Instagram:@hackersclubили в Twitter:@ringoware

Доброй охоты :)

Ссылки и благодарности

Ken Shirriffhttp://www.righto.com/2020/05/extracting-rom-constants-from-8087-math.html, за то, что лично уделил время и рассказал мне, как биты считываются из ПЗУ.

John McMasterhttps://siliconpr0n.org/archive/doku.phpза то, что провел со мной многие часы и, в частности, рассказал, как автоматизировать извлечение ПЗУ, как делается декапсуляция и послойное препарирование.

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

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

О нейтрализации https://chem.libretexts.org/Bookshelves/Physical_and_Theoretical_Chemistry_Textbook_Maps/Supplemental_Modules_(Physical_and_Theoretical_Chemistry)/Acids_and_Bases/Acid_Base_Reactions/Neutralization

Получение серной кислоты https://www.cs.mcgill.ca/~rwest/wikispeedia/wpcd/wp/s/Sulfuric_acid.htm

Конструирование сверхбольших интегральных схем (VLSI) https://www.tutorialspoint.com/vlsi_design/vlsi_design_digital_system.htm

Понятие о NAND Flash https://www.simms.co.uk/nand-flash-basics/understanding-nand

Сравнение векторного расширения RISC-V (RVV) и масштабируемого векторного расширения ARM (SVE/SVE2).

Микропроцессоры с векторными командами ожидает большое будущее. Почему? Беспилотные автомобили, распознавание речи, распознавание образов, всё это основано на машинном обучении, а машинное обучение на матрицах и векторах.

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

Сейчас мы придумали тысячи умных способов получить большую производительность, будь то создание многоядерных процессоров, внеочередное (out-of-order) исполнение, более совершенное предсказание переходов и SIMD-команды.

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

SIMD-команды, такие, как Neon, MMX, SSE2 и AVX замечательно сработали в мультимедийных приложениях, в таких вещах, как кодирование видео и т.п. Но нам нужно получить большую производительность во многих областях. Векторные команды предлагают большую гибкость в превращении почти любого цикла в векторные команды. Однако есть много различных способов это сделать.

Я описал векторные команды RISC-V здесь:RISC-V Vector Instructions vs ARM and x86 SIMD.

Позже я описал векторные команды ARM:ARMv9: What is the Big Deal?.

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

Это заставило меня обнаружить, что ARM и RISC-V следуют принципиально разным стратегиям. Стоит написать об этом, потому что это одна из моих любимых тем. Я люблю простые, элегантные и эффективные технологии:The Value of Simplicity.

Векторное расширение RISC-V по сравнению с ARM SVE это элемент элегантности и простоты.

Проблема с масштабируемыми векторными командами ARM (Scalable Vector Instructions, SVE)

В процессе изучения SVE, было неочевидно, почему это так трудно для понимания, но когда я взял книгу по RISC-V и перечитал главу по векторному расширению, это стало ясно.

Честно говоря, ARM является большим шагом вперёд по сравнению с большим сложным и беспорядочным ассемблером Intel x86. Давайте не будем про это забывать. Также мы не можем пройти мимо того факта, что ARM не молодая платформа, и содержит много легаси. Когда мы имеем дело с ARM, у нас есть три различных набора команд: ARM Thumb2, ARM32 и ARM64. Когда вы гуглите руководства и пытаетесь их читать, возникает ряд проблем. Люди не всегда понимают, какой набор команд изучать.

Инструкции Neon SIMD имеют две разновидности: 32- и 64-битные. Проблема, конечно, не в ширине слова, а в том, что для 64-битной архитектуры ARM перепроектировал весь набор команд и изменил многие вещи, даже соглашение об именовании регистров.

Вторая проблема в том, что ARM большой. Система команд содержит свыше 1000 команд. Сравните с базовым набором RISC-V, в котором всего лишь 48 команд. Это означает, что читать ассемблер ARM не так просто. Посмотрим на команду SVE:

LD1D z1.D, p0/Z, [x1, x3, LSL #3]

Здесь делается много. Если у вас есть опыт в ассемблере, вы можете догадаться, что префиксLDозначаетLoaD. Но что означает1D? Вы должны это выяснять. Дальше вы должны выяснить, что означают странные суффиксы имён регистров, такие как .Dand/Z. Дальше вы видите скобки[]. Вы можете догадаться, что они составляют адрес, зачем там странная запись LSL #3, что означает логический сдвиг влево (Logic Shift Left)три раза. Что сдвигается? Все данные? Или только содержимое регистраx3? Это снова нужно смотреть в справочнике.

Команды ARM SVE содержат множество концепций, не являющихся очевидными, от которых голова идёт кругом. Мы сделаем глубокое сравнение, но сначала скажем несколько слов о RISC-V.

Красота векторного набора команд RISC-V

Обзор всех команд векторных расширений RISC-V (RVV) помещается на одной странице. Команд немного, и, в отличие от ARM SVE, они имеют очень простой синтаксис. Вот команда загрузки вектора в RISC-V:

VLD v0, x10

Команда загружает векторный регистрvданными, находящимися по адресу, который хранится в обычном целочисленном регистреx10. Но сколько данных загружается? В наборе команд SIMD, таком, как ARM Neon это определяется именем векторного регистра.

LD1 v0.16b, [x10]  # Load 16 byte values at address in x10

Есть другой способ сделать это. Такой же результат достигается таким образом:

LDR d0, [x10]    # Load 64-bit value from address in x10

Эта команда загружает младшую 64-битную часть 128-битного регистраv0. Для SVE2 у нас есть другой вариант:

LD1D z0.b, p0/z, [x10] # Load ? number of byte elementsLD1D z0.d, p0/z, [x10] # Load double word (64-bit) elements

В этом случае регистр предикатаp0определяет в точности, сколько элементов мы загружаем. Еслиp0 = 1110000, мы загружаем три элемента.v0 это 128-битная младшая частьz0.

Регистры имеют одинаковые имена?

Причина этому в том, что регистры d,vиz находятся в одной ячейке. Давайте поясним. У вас есть блок памяти, называемый регистровый файл в каждом CPU. Или, если быть более точным, в CPU расположено много регистровых файлов. Регистровый файл, это память, в которой расположены регистры. Вы не можете получить доступ к ячейкам памяти в регистровом файле, так же как в обычной памяти, вместо этого вы обращаетесь к области памяти, используя имя регистра.

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

• z3 регистр SVE2 переменной длины.

• v3 младшие 128 бит z3. Регистр Neon.

• d3 младшие 64 битаv3.

• s3 младшие 32 битd3

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

• x0-x31 скалярные целочисленные регистры.

• f0-f31 скалярные регистры с плавающей точкой.

• v0-v31 векторные регистры. Длина не зависит от ISA.

Сложность векторных команд ARM

Я только поцарапал поверхность векторных команд ARM, потому что их очень много. Просто найти, что делает команда загрузки Neon и SVE2, занимает много времени. Я просмотрел много документации ARM и записей в блогах. Сделать то же самое для RISC-V очень просто. Практически все команды RISC-V можно разместить на двойном листе бумаги. У него есть только три команды загрузки вектораVLD,VLDSиVLDX.

Я не могу сказать, сколько этих команд у ARM. Их очень много, и я не собираюсь становиться профессионалом по программированию ARM. на ассемблере.

Как ARM и RISC-V обрабатывают вектора переменной длины

Это довольно интересный вопрос, так как ARM и RISC-V используют существенно различные подходы и я считаю, что простота и гибкость решения RISC-V просто блестящая.

Вектора переменной длины в RISC-V

Чтобы начать обработку векторов, вы делаете две вещи:

• VSETDCFG Vector SET Data ConFiGuration. Устанавливает битовый размер каждого элемента, тип, который может быть вещественным, знаковым целым или беззнаковым целым. Также конфигурация определяет, сколько векторных регистров используется.

• SETVL SET Vector Length. Устанавливает, сколько элементов содержит вектор. Максимальное количество элементов, которое вы не можете превысить MVL(max vector length).

И здесь всё становится интереснее. В отличие от ARM SVE, я могу разделить файл векторных регистров именно так, как я хочу. Пусть регистровый файл имеет размер 512 байт. Я могу теперь объявить, что я хочу иметь два векторных регистра, по 256 байт каждый. Далее я могу сказать, что я хочу использовать 32-битные элементы, другими словами, элементы по 4 байта. Получаем следующее:

Два регистра: 512 байт / 2 = 256 байт на регистр256 байт / 4 байта на элемент = 128 элементов

Это означает, что я могу складывать или умножать 128 элементов просто одной командой. В ARM SVE вы этого сделать не можете. Количество регистров фиксировано, и память аллоцирована для каждого регистра. И RISC-V, и ARM позволяют вам использовать максимум 32 векторных регистра, но RISC-V позволяет вам отключать регистры и отдавать используемую ими память оставшимся регистрам, увеличивая их размер.

Вычисление максимальной длины вектора (Max Vector Length, MVL)

Давайте посмотрим, как это работает на практике. Процессор, конечно, знает размер регистрового файла. Программист этого не знает, и не предполагается, что знает.

Когда программист использует VSETDCFG, чтобы установить типы элементов и количество используемых регистров, процессор использует эту информацию, чтобы вычислить максимальную длину вектора Max Vector Length (MVL).

LI        x5, 2<<25  # Load register x5 with 2<<25VSETDCFG  x5         # Set data configuration to x5

В примере выше происходят две вещи:

• Включаем два регистра:v0иv1.

• Устанавливаем тип элементов в 64-битные вещественные числа. Давайте сравним это с ARM Neon, в котором каждый регистр имеет длину 128 бит. Это означает, что Neon может обрабатывать два таких числа параллельно. Но в RISC-V 16 таких регистров можно объединить в один. Это позволяет обрабатывать 32 значения параллельно.

На самом деле это не буквально так. За сценой у нас есть конечное число вещественных умножителей, блоков АЛУ и т.п., что ограничивает число параллельных операций. Однако всё это уже детали реализации.

Итак, мы получили значениеMVL, равное 32. Разработчик не должен напрямую знать это число. Команда SETVLработает так:

SETVL rd, sr  ; rd  min(MVL, sr), VL  rd

Если вы попытаетесь установить Vector Length (VL)в значение 5, это сработает. Однако, если вы попытаетесь установить значение 60, вы получите вместо этого значение 32. Итак, величина Max Vector Length (MVL) важна, она не фиксирована конкретным значением при изготовлении процессора. Она может быть вычислена исходя из конфигурации (типа элементов и количества включенных регистров).

Вектора переменной длины в ARM

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

Чтобы получить эквивалентSETVLна ARM , используйте командуWHILELT, что является сокращением отWhile Less Than:

WHILELT p3.d, x1, x4

Довольно сложно объяснить словами, что делает эта команда, и я использую псевдокод, чтобы объяснить её работу.

i = 0while i < M   if x1 < x4      p3[i] = 1   else      p3[i] = 0  end  i += 1  x1 += 1end

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

1110000

То есть вектор переменной длины реализуется за счёт того, что все операции используют предикат. Рассмотрим эту операцию сложения. Представьте, чтоv0[p0]извлекает из v0только те элементы, для которыхp0истинно.

ADD v4.D, p0/M, v0.D, v1.D ; v4[p0]  v0[p0] + v1[p0]

Итак, мы сделали некоторое вступление. Сейчас рассмотрим более полный пример кода, чтобы увидеть, как эти наборы команд работают на практике.

Пример кода DAXPY

Рассмотрим сейчас, как функции C могут быть реализованы различными векторными командами:

void daxpy(size_t n, double a, double x[], double y[]) {        for (int64_t i = 0; i < n; ++i) {                y[i] = x[i] * a + y[i];        }}

Почему такое странное имя daxpy? Это простая функция в библиотеке линейной алгебры BLAS, популярной в научной работе. В BLAS эта функция называется daxpyи она очень популярна для демонстрации примеров работы разнообразных SIMD и векторных команд. Она реализует такую формулу:

aX + Y

гдеa скаляр, а XиY вектора. Без векторных команд нужно было бы обрабатывать все элементы в цикле. Но с умным компилятором, эти команды могут быть векторизованы в код, который выглядит на RISC-V так, как показано ниже. Комментарии показывают, какой регистр какой переменной соответствует:

daxpy(size_t n, double a, double x[], double y[]) n - a0  int   register (alias for x10) a - fa0 float register (alias for f10)  x - a1  (alias for x11)  y - a2  (alias for x12

Код:

LI       t0, 2<<25    VSETDCFG t0             # enable two 64-bit float regsloop:    SETVL  t0, a0           # t0  min(mvl, a0), vl  t0    VLD    v0, a1           # load vector x    SLLI   t1, t0, 3        # t1  vl * 2 (in bytes)    VLD    v1, a2           # load vector y    ADD    a1, a1, t1       # increment pointer to x by vl*8    VFMADD v1, v0, fa0, v1  # v1 += v0 * fa0 (y = a * x + y)    SUB    a0, a0, t0       # n -= vl (t0)    VST    v1, a2           # store Y    ADD    a2, a2, t1       # increment pointer to y by vl*8    BNEZ   a0, loop         # repeat if n != 0    RET    

Это код, скопированный из примера. Отметим, что мы не используем именаf иxдля целочисленных и вещественных регистров. Чтобы помочь разработчикам лучше помнить соглашения, ассемблер RISC-V определяет ряд псевдонимов. Например, аргументы функции передаются в регистрахx10-x17. Но нет необходимости запоминать эти номера, для аргументов предусмотрены псевдонимыa0-a7.

t0-t6 псевдонимы регистров временных переменных. Они не сохраняются между вызовами.

Для сравнения мы приведём ниже код ARM SVE. Пометим, какой регистр какую переменную содержит.

daxpy(size_t n, double a, double x[], double y[]) n - x0  register a - d0  float register x - x1  register  y - x2  register i - x3  register for the loop counter

Код:

daxpy:        MOV z2.d, d0            // a        MOV x3, #0              // i        WHILELT p0.d, x3, x0    // i, nloop:        LD1D z1.d, p0/z, [x1, x3, LSL #3] // load x        LD1D z0.d, p0/z, [x2, x3, LSL #3] // load y        FMLA z0.d, p0/m, z1.d, z2.d        ST1D z0.d, p0, [x2, x3, LSL #3]        INCD x3                 // i        WHILELT p0.d, x3, x0    // i, n        B.ANY loop        RET

Код ARM немного короче, так как команды ARM делают больше, чем одно действие. Это является причиной того, что код RISC-V гораздо проще читать. Команды в RISC-V делают что-то одно, и не требуют специального сложного синтаксиса. Такая простая вещь, как загрузка векторного регистра в ARM выглядит сложно:

LD1D z1.d, p0/z, [x1, x3, LSL #3]

Часть в квадратных скобках вычисляет адрес, из которого происходит загрузка:

[x1, x3, LSL #3] = x1 + x3*2 = x[i * 8]

Итак, здесь видно, чтоx1представляет базовый адрес переменнойx.x3 счётчикi. Сдвигом влево на три бита мы умножаем на 8, то есть на количество байт в 64-битном вещественно числе.

Заключение

Как начинающий в векторном кодинге, я должен сказать, что ARM переусложнён. Это не значит, что ARM плохой. Я также изучал систему команд Intel AVX, и она в 10 раз хуже. Я совершенно определённо не хочу тратить время на изучение AVX, принимая во внимание, сколько усилий отняли SVE и Neon.

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

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

Если для вас, как и для меня, это хобби, и вы просто хотите понимать, как развивается технология, и как работают вещи, такие, как векторная обработка, сберегите свои усилия и просто прочитайте книгу по RISC-V.

Люди могут поспорить, что ARM или Intel или что-то ещё проще, потому что по ним больше книг и больше ресурсов. Ничего подобного! Я могу сказать вам на своём собственном опыте, что документация часто представляет собой препятствие, а не помощь. Это означает, что вам нужно раскопать больше материала. Вы найдёте много противоречий, корни которых лежат в устаревших принципах работы.

Если вы хотите погрузиться в ассемблер, вы можете прочитать некоторые из моих статей и руководств:

• RISC-V Assembly for Beginners

• RISC-V Assembly Code Examples

• ARM, x86 and RISC-V Microprocessors Compared.

Введение

В предыдущей заметке Планировщик Windows? Это очень просто было рассказано о технологии получения дизассемблированного текста ядра операционной системы Windows XP образца 2013 года. Такой текст потребовался для анализа и корректировки кода ядра, что позволило изменить политику планирования потоков в Windows и выполнить одну конкретную задачу с уменьшением времени отклика операционной системы.

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

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

Хотя Windows XP и Windows 7 уже, так сказать, сняты с вооружения, на мой взгляд, изучение даже неподдерживаемых программ имеет смысл. Ядро Windows XP сопровождалось и развивалось около 10 лет. Поэтому на основании анализа кода можно, например, даже прогнозировать пути дальнейшего развития системы. Замечу также, что различия в коде ядер различных версий Windows не так велики как различия некоторых других компонентов.

Оптимизация команд

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

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

40AD14 0FB74018             MOVZX  EAX,W PTR [EAX]+1840AD18 8B4904               MOV    ECX,[ECX]+440AD1B C1E005               SHL    EAX,5

Широко используется загрузка константы в регистр через пару команд обращения к стеку:

40AD5B 6A0A                 PUSH   0A40AD5D 59                   POP    ECX

Я считаю такую пару командой MOVSX ECX,0AH (которая на самом деле не существует, но если бы была, то эффект она давала бы такой же).

Остроумно реализовано громоздкое вычисление адресации, например, вот быстрое умножение индекса на 12:

4038E8 8D0C76               LEA    ECX,[ESI+ESI*2]4038EB 837C8F0400           CMP    D PTR [EDI+ECX*4]+4,0

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

4050F8 F7410406000000       TEST   D PTR [ECX]+4,64050FF B801000000           MOV    EAX,1405104 7512                 JNZ    405118

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

Недостатки кода

Однако наряду с эффективно сформированными командами встречаются вещи, которые, мягко говоря, далеко не оптимальны.

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

Но посмотрите, например, на один из бесчисленных фрагментов ядра:

4025AA 90                   NOP4025AB 90                   NOP4025AC 90                   NOP4025AD 90                   NOP4025AE 90                   NOP4025AF 8BFF                 MOV    EDI,EDI4025B1 55                   PUSH   EBP

Здесь, как и в сотнях других подобных мест, выравнивание превратилось в свою противоположность, и подпрограмма начинается из-за команд NOP как раз НЕ с адреса, кратного 16 или хотя бы 4, а сами команды NOP стали просто бессмысленным раздуванием кода. Такое впечатление, что где-то в одном месте в ядре выравнивание съехало и далее везде дает противоположный эффект.

Причем, чтобы увидеть это, вовсе не требуется дизассемблировать код, достаточно любой подходящей утилитой посмотреть таблицу экспорта ядра NTOSKRNL.EXE. Там полно, например, нечетных (т.е. явно никак не выровненных) адресов входов.

Вообще код во многих местах напоминает заячьи петли. Например, после проверки управление вдруг передается в другое далеко отстоящее место ядра:

40A661 8B4D0C               MOV    ECX,[EBP]+0C40A664 85C9                 TEST   ECX,ECX40A666 0F840989FFFF         JJE    402F75

Однако в том месте выполняется всего пара команд, и управление возвращается, так сказать, обратно:

402F75 8BCE                 MOV    ECX,ESI402F77 E8EB260000           CALL   405667402F7C E9FB760000           JMP    40A67C

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

Встречаются и такие конструкции:

IoFreeIrp:414012 8BFF                 MOV    EDI,EDI414014 55                   PUSH   EBP414015 8BEC                 MOV    EBP,ESP414017 5D                   POP    EBP414018 FF258C474800         JMP    D PTR [0048478C]IoAllocateIrp:41406D 8BFF                 MOV    EDI,EDI41406F 55                   PUSH   EBP414070 8BEC                 MOV    EBP,ESP414072 5D                   POP    EBP414073 FF2588474800         JMP    D PTR [00484788]

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

Возможно, в исходном тексте находится какой-то закомментированный фрагмент и это дает такой эффект. Возможно, это было сделано для каких-то отладочных остановок. Но как бы то не было, каждый раз, когда происходит обращение к подпрограммам IoAllocateIrp и IoFreeIrp, сначала выполняются бессмысленные команды.

Во многих местах ядра происходит обращение к двухбайтовым объектам, например:

409378 668B4564             MOV    AX,[EBP]+6440937C 6683E0FC             AND    AX,FFFC409380 668B4A04             MOV    CX,[EDX]+4409384 6683E1FC             AND    CX,FFFC409388 663BC8               CMP    CX,AX40938B 7547                 JNZ    4093D4

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

409378 8B4564               MOV    EAX,[EBP]+6440937B 83E0FC               AND    AX,FFFC40937F 8B4A04               MOV    ECX,[EDX]+4409382 6683E1FC             AND    CX,FFFC409386 663BC8               CMP    CX,AX409389 7545                 JNZ    4093D4

Это тем более удивительно, что иногда обработка двухбайтового объекта идет без префикса 66, например:

407F3D 668B442424           MOV    AX,[ESP]+24407F42 C1E004               SHL    EAX,4

Чтение всех двухбайтовых объектов как четырехбайтовых позволяет существенно сократить код.

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

Еще один существенный недостаток кода большое число пересылок регистров. Например, типичный фрагмент:

40FAE0 64A120000000         MOV    EAX,FS:[00000020]40FAE6 8BF8                 MOV    EDI,EAX40FAE8 8BB748050000         MOV    ESI,[EDI]+54840FAEE FF460C               INC    D PTR [ESI]+0C40FAF1 8BCE                 MOV    ECX,ESI40FAF3 E87FA7FFFF           CALL   40A277 ;ExInterlockedPopEntrySList40FAF8 85C0                 TEST   EAX,EAX40FAFA 0F84843A0000         JJE    413584

Его можно было бы короче записать так:

40FAE0 648B3D20000000       MOV    EDI,FS:[00000020]40FAE7 8B8F48050000         MOV    ECX,[EDI]+54840FAED FF410C               INC    D PTR [ECX]+0C40FAF0 E87DA7FFFF           CALL   40A277 ;ExInterlockedPopEntrySList40FAF5 85C0                 TEST   EAX,EAX40FAF7 0F84823A0000         JJE    413584

Не пересылая каждый раз данные сначала в регистры EAX и ESI.

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

Для большинства программ практически значимый результат от совершенствования кода бывает редко. Допустим, имеется программа, которая проводит расчет за минуту. Допустим, потратив час, ее ускорили на 10%. Тогда только примерно через 600 прогонов общий выигрыш от работы улучшенной версии достигнет того же часа и компенсирует затраченное время. Если и не требуется запускать программу более 600 раз, улучшение не оправдает затраты.

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

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

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

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

Возникает впечатление, что вообще никто из разработчиков Windows никогда и не анализировал конечный код. Иначе обратили бы внимание, что, например, выравнивание подпрограмм не получилось.

Технология улучшения кода

Какова может быть технология улучшения кода? С моей точки зрения менять технологию разработки и компилирования Windows уже поздно слишком много усилий потрачено на отработку и тестирование.

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

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

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

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

Например, в фрагменте:

411AC8 64A120000000         MOV    EAX,FS:[00000020]411ACE 8BF8                 MOV    EDI,EAX411AD0 64A124010000         MOV    EAX,FS:[00000124]411AD6 33C9                 XOR    ECX,ECX

можно гарантированно без последствий заменить первую команду MOV EAX, на MOV EDI, и исключить лишнюю пересылку MOV EDI,EAX, поскольку уже в следующей команде EAX принимает новое значение и его старое значение никак не может быть использовано далее. При этом в ядре нет команд перехода на адрес 411ACE (что также легко проверить), а, значит, никакой ошибки от прямой пересылки в другой регистр не может быть в принципе.

Другое дело, вот такой фрагмент:

412D09 8B06                 MOV    EAX,[ESI]412D0B 57                   PUSH   EDI412D0C 8BF8                 MOV    EDI,EAX412D0E C1EF0C               SHR    EDI,0C412D11 BBFF0F0000           MOV    EBX,00000FFF412D16 0F8423010000         JJE    412E3F

Здесь менять пересылку регистров опасно, поскольку управление куда-то передается (по адресу 412E3F) и транслятор далее может использовать имеющееся значение в EAX. Анализ так ли это или нет, уже достаточно сложен и не может быть выполнен формально и простыми средствами как в предыдущем случае.

Заключение

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

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

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

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

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