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

;{{SpeakerInfo}}: {{Speaker|Игорь Чудов}}
<blockquote>
  В докладе рассмотрена «проблема бутстрапа» реализации компилятора
  языка программирования Common LISP — SBCL (Steel Bank Common LISP)
  в приложении к архитектуре e2k. Рассмотрены составные элементы данного
  ПО, этапы бутстрапа, а также некоторые подробности низкоуровневого
  устройства. Данная работа призвана объединить разрозенные знания об
  устройстве проекта.
</blockquote>

{{VideoSection}}

{{vimeoembed|366009144|800|450}}
<!-- 
{{youtubelink|}} -->
|h4OPD4v9YY8}}
{{SlidesSection}}
[[File:Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019).pdf|left|page=-|300px]]

{{----}}

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

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

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

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

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

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

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

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

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

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

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

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

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

Самая объёмная и сложная платформо-зависимая часть системы находится в директориях <code>src/assembly/platformname</code> и <code>src/compiler/platformname</code> и содержит определения виртуальных операций (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 плохо подходит для написания кода вручную;

{{----}}
[[File:{{#setmainimage:Проблемы портирования SBCL на новые аппаратные платформы (Игорь Чудов, OSSDEVCONF-2019)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->

* SBCL Internals CLiki site. https://web.archive.org/web/20120814000933/http://sbcl-internals.cliki.net/index
{{fblink|2541153349471004}}                                          
{{vklink|1641}}                                          
<references/>

[[Категория:OSSDEVCONF-2019]]
[[Категория:Draft]]
[[Категория:Open-source]]ALTLinux на Эльбрусе]]
{{stats|disqus_comments=0|refresh_time=2021-08-31T18:03:32.958317|vimeo_plays=28|youtube_comments=0|youtube_plays=76}}