Особенности портирования СПО на Эльбрус (Андрей Савченко, OSSDEVCONF-2019)

Ссылки сюда (2) →

Короткая ссылка: 20190827B

Докладчик

Андрей Савченко

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

Видео

on youtube

Презентация

Thesis

В отличие от большинства других архитектур Эльбрус (e2k) использует набор инструкций с широким командным словом (VLIW) и позволяет выполнять 25 инструкций общего назначения за такт (для 4-го поколения). Это свойство накладывает на компилятор существенно более серьёзные требования по оптимизации кода. Более того, с целью оптимизации использования площади кристалла все высокоуровневые функции, которые было возможно вынести из железа в компилятор, были перенесены туда. Грубо говоря, у Эльбрусов нет микрокода и все операции уровня микрокода выполняются на этапе компиляции, а не во время исполнения, как на семействе x86. Такой подход обеспечивает лучшую энергоэффективность и производительность на число транзисторов, но обратной стороной является то, что системный компилятор LCC является закрытым и, вероятно, останется таковым.

LCC старается соответствовать GCC по пользовательскому интерфейсу и поведению, но на этом общие черты заканчиваются. LCC основан на фронтенде EDG и разработанном МЦСТ многоуровневом бэкенде.

Однако, свободное программное обеспечение также используется в тулчейне: libstdc++, libatomic, libgcc_s, C runtime и т.п. Было выполнено выделение свободных компонент и сборка их из исходных кодов, а также пакетирование в соответствии со стандартами Alt. На Эльбрусе реализован режим JIT компиляции x86/amd64 ассемблера, но мы его не используем по соображениям как производительности, так и безопасности.

Большинство проблем портирования кода на уровне дистрибутива возникает из-за неполной совместимости LCC с GCC. Основной проблемой является фронтенд EDG, отвечающий за синтаксический анализ кода: используемые версии отстают от GCC по полноте поддержки стандартов и диалектов языков; применяемый ныне lcc-1.23 примерно соответствует лишь gcc-5.5. Особо ярко эта проблема проявляется на C++.

Однако, есть и иные проблемы:

• Иногда LCC замечает проблемы, пропускаемые GCC, например, неинициализированные переменные, что является особо надоедливой проблемой в комбинации с -Werror.
• lcc-1.23 реализует не все расширенные типы данных, что и gcc-5.5, например, нет __uint128_t и _Decimal64. Часто эти проблемы решаются с помощью макросов.
• Не все встроенные функции GCC поддерживаются, некоторые и не будут.
• Препроцессор LCC предполагает, что входные данные—это код C/C++ и заменяет табуляции выравнивания пробелами. Это ломает приложения, использующие препроцессор для обработки Makefile и иного чувствительного к табуляции кода.
• Ряд ПО использует недокументированные или сомнительные особенности компилятора: массивы переменной длины в структурах(VLAIS), вложенные функции, C++ без runtime. Они перестают работать как ожидается или вовсе не реализованы.

LCC поддерживает только C, C++ и Fortran, поэтому на данный момент на Эльбрусе нет поддержки языков, которым нужен собственный полноценный кодогенератор, например, Go, Rust, Haskell. В будущем эта проблема должна быть решена реализацией бэкенда LLVM.

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

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

Внесение в апстримы патчей для e2k имеет свои ограничения, но всё же возможно. Основной проблемой является NDA с МЦСТ, не позволяющее публиковать патчи, полученные от МЦСТ. Тем не менее, собственные разработки публиковать можно без ограничений. Нами и иными разработчиками уже внесён вклад в ряд проектов (gimagereader, imake, lxc, ruby и др.), ознакомиться с которыми можно на нашей вики. Апстримы, как и люди, все разные: кто-то с радостью принимает патчи, кто-то игнорирует, кто-то принципиально отказывается принимать, но продвижение кода всё же возможно. Есть надежда, что в будущем все патчи будут открыты и архитектура получит второе дыхание.

Примечания и ссылки

• Discuss on Facebook
• Discuss on VK

Plays:305   Comments:5