• 0. Предисловие.
• 1. E2K или архитектура Эльбруса 2000.
  • 1.1. Краткий экскурс и базис архитектуры.
  • 1.2. Как исполняется код на Эльбрусе.
  • 1.3. Есть ли в Эльбрусе те же бэкдоры, что и в Intel и AMD?
  • 1.4. Компилятор. Инструмент по оптимизации ПО.
  • 1.5. Intel Intrinsics на Эльбрусе? Чего, мать?
  • 1.6. Как оптимизировать софт специально под Эльбрус?
  • 1.7. Программа Начального Старта (ПНС).
• 2. Двоичная трансляция x86 в E2K.
  • 2.1. RTC. Транслятор уровня приложений.
  • 2.2. Lintel. Транслятор уровня системы.
  • 2.3. SSE инструкции в трансляции на Эльбрус 8С.
  • 2.4. Общая структура системы двоичной трансляции.
• 3. Перед началом тестов.
  • 3.1. Версии ОС и ПО. Дистрибутивы Linux под E2K для теста.
  • 3.2. С чем будем сравнивать Эльбрус 8С?
• 4. Тесты в тяжёлых задачах на C, C++ и Ассемблере.
  • 4.1. Перекодирование видео с ffmpeg.
  • 4.2. Рендеринг сцен в Blender.
  • 4.3. Декодирование AV1 видео на процессоре с dav1d.
  • 4.4. Какое ПО на C/C++ круто оптимизировано под Эльбрус?
• 5. Тесты с C#, Java, JavaScript, PHP, Lua и Python.
  • 5.1. Тесты с Java, C# (.Net Core), PHP, Python и Lua.
  • 5.2. Браузерные тесты.
• 6. Игры на Эльбрусе.
  • 6.1. GTA3 (re3).
  • 6.2. Xash3D (Half-Life 1 и CS 1.6).
  • 6.3. Tomb Raider (2013).
  • 6.4. Rocket League.
  • 6.5. Genshin Impact.
• 7. А если x86 процессор будет имитировать Эльбрус?
• 8. Критика ПК с Эльбрус 8С.
  • 8.1. Система набора команд.
  • 8.2. Отсутствие реализации многопоточности в рамках 1 ядра.
  • 8.3. Компилятор ещё есть куда дорабатывать.
  • 8.4. Загрузка системы с RAID-массивов.
  • 8.5. USB-порты на Эльбрус 8С.
  • 8.6. Корпус. Задняя крышка, закрывающая порты.
• 9. Почему Эльбрус важен? Вопрос выживания страны.
  • 9.1. Что сейчас с производством и поставками в России и мире.
  • 9.2. Почему нам не подходят архитектуры ARM и RISC V?
• 10. Субъективные впечатления и выводы.

2.4. Общая структура системы двоичной трансляции.

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

При подготовке материала для этой подглавы я полагался на документ с сайта МЦСТ. На данный момент на сайте МЦСТ поменяли дизайн и многиестраницы изменили свой адрес, но старая страница с этим документом влюбом случае доступна в web archive. В документе описана общая схемаработы динамической двоичной трансляции (x86 -> E2K), различные уровниоптимизаций, реализованных в системе и методы уменьшения накладныхрасходов на трансляцию. Там в целом всё довольно хорошо расписано, но,правда, неподготовленному читателю там будет тяжело разобраться.Попробуем более доступным языком описать то, что там написано.

Скриншот 32. Общая схема работы системы двоичной трансляции.

Итак, ноги растут у Топлеса с чего всё стартует? Исполнение x86 кода начинается в интерпретаторе. Он собирает профильную информацию об x86 инструкциях, которые необходимо исполнить. Как только собрано достаточно сведений, запускается трансляция этих инструкций в аналогичные у E2K архитектуры. Транслированный код сохраняется в кэше трансляций (внизу).

Далее процитирую часть из статьи:

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

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

В узле профильного графа хранятся: количество исполнений соответствующего линейного участка, статистика по переходам (счётчики дуг), информация о специфике инструкций, включенных в данный узел (наличие fp, mmx, sse операций и т.д.).

В общем, то, что я и описал выше: собирается полная информация о специфике исполняемого кода. На базе неё уже транслятор «обучается».

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

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

Для осуществления переходов по x86-адресам между трансляциями используется таблица перекодировки адресов, которая хранит соответствие x86-адрес начала линейного участка → e2k-адрес транслированного кода.

Что здесь описано? У x86 машин и E2K машин адреса в памяти различаются. Когда в коде прописан вызов одного адреса памяти для x86, он автоматом по таблице перекодировки адресов (считайте, словарь для адресов памяти x86 -> E2K) переводится в аналогичный адрес для E2K. Короче говоря, при трансляции работа ведётся далеко не только с инструкциями, но и с памятью.

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

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

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

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

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

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