Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019)

Материал из 0x1.tv

(перенаправлено с «20190827C»)
Короткая ссылка: 20190827C
Докладчик
Игорь Чудов.jpg
Игорь Чудов

В докладе рассмотрена «проблема бутстрапа» реализации компилятора языка программирования Common LISP — SBCL (Steel Bank Common LISP) в приложении к архитектуре e2k. Рассмотрены составные элементы данного ПО, этапы бутстрапа, а также некоторые подробности низкоуровневого устройства. Данная работа призвана объединить разрозенные знания об устройстве проекта.

Видео

on youtube

Презентация

Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf

Thesis

Проблематика

В целях портирования компилятора SBCL на архитектуру e2k было начато исследование проекта.

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

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

Устройство и этапы сборки

Бутстрап SBCL невозможен без существования интерпретатора Common LISP, но на начальном этапе достаточно иметь таковой на хостовой платформе. Для собственно инициализации сборки в таком случае необходим компилятор C, ассемблер и линкер для целевой платформы.

Простейший процесс сборки для новой платформы выглядит так:

  1. Создание файлов конфигурации для сборки (make-config.sh);
  2. Сборка кросс-компилятора Common LISP. Данная часть называется GENESIS 1;
  3. Сборка компонентов целевого компилятора: эта часть собирается после GENESIS 1, чтобы получить файл sbcl.h для сборки части, написанной на С, и до сборки GENESIS 2, чтобы получить таблицу символов.
  4. Запускается кросс-компилятор для получения объектных файлов для целевой операционной платформы.
  5. Запускается GENESIS 2, чтобы получить cold-sbcl.core. Создаётся с помощью src/compiler/generic/genesis.lisp, который преобразует FASL файлы в образ LISP-системы на хосте.
  6. Производится warm init — загрузка и сборка CLOS (Common LISP Object System), а также компонентов, от неё зависящих.

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

Части системы

SBCL технически является компилятором — каждое поступающее на вход выражение сначала проходит этап компиляции в двоичный код, и только потом исполняется. Соответственно, для выполнения этой задачи в SBCL существует платформо-зависимая часть.

Платформо-зависимая часть состоит из определения регистров в файле src/runtime/platformname-lispregs.h, где platformname — название целевой архитектуры. Этот элемент необходим для описания доступных для работы регистров.

Также существует ассемблерная часть в файле src/runtime/platformname-assem.S, где определены всего две функции — call_into_c и call_into_lisp, которые выполняют переключение между C и SBCL ABI. Одна из задач этой части — переключение на C runtime, который отвечает за обработку сигналов, полученныx от операционной системы. Для реализации таковых функций необходимо хорошее знание platform ABI целевой архитектуры, а также особенностей целевой операционной системы.

Самая объёмная и сложная платформо-зависимая часть системы находится в директориях src/assembly/platformname и src/compiler/platformname и содержит определения виртуальных операций (VOP) которые необходимы, чтобы преобразовать код на LISP в ассемблерный код, и используются в виртуальной машине SBCL в качестве низкоуровневых операций для в стандартных функциях ANSI Common LISP.

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

Проблемы при портировании на архитектуру e2k

В ситуации с портированием SBCL на архитектуру e2k в ОС ALT Linux были обнаружены следующие проблемы:

  • Отсутствие кросс-компилятора C. Многие компиляторы, как SBCL, GHC и другие, не рассчитаны на сборку только на целевой платформе;
  • Отсутствие детальной документации на C ABI для e2k. Данное знание необходимо для реализации функции переключения между SBCL ABI и C ABI, а также для эффективной реализации VOPs. Некоторые вещи приходится изучать методом исследования ассемблерных листингов;
  • Частично утеряна документация по SBCL internals. К сожалению, лучшее средство изучения проекта — чтение кода и общение в списках рассылки;
  • Сложность ручного просчёта блоков инструкций для широких слов. Ассемблер e2k плохо подходит для написания кода вручную;
Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019)!.jpg

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

Plays:104   Comments:0

Источник — «https://0x1.tv./index.php?title=Проблемы_портирования_SBCL_на_новые_аппаратные_платформы_(Игорь_Чудов,_OSSDEVCONF-2019)&oldid=187203»