Common LISP Porting Initiative

Состояние проекта

Собран свежий CLISP, но без некоторых библиотек. Им скомпилирована свежая версия Maxima. Далее стоит задача бутстрапа SBCL.

Механизм портирования

Наиболее популярными и функциональными интерпретаторами и компиляторами Common LISP являются реализации SBCL и CMUCL. К сожалению, они сами написаны на Common LISP и их портирование на новые архитектуры затруднено. Наиболее частым способом бутстрапа данных интерпретаторов является бутстрап через сборку интерпретатора CLISP, написанного на C.

CLISP

•   пакет в sisyphus_e2k

Сборка производится из актуального репозитория: https://gitlab.com/gnu-clisp/clisp . Несмотря на отсутствие официальных релизов интерпретатора после 2010-го года, разработка продукта всё ещё продолжается.

Для сборки требуются зависимости:

• libreadline-devel — для REPL;
• libsigsegv2 и libsigsegv-devel — для сборки мусора и обнаружения переполнений стека в интерпретируемом коде;
• libffcall — для обеспечения поддержки FFI.

Первоначальный список проблем:

• Во время конфигурирования не удаётся найти пакеты libsigsegv2 и libreadline. Данная проблема актуальна не только для e2k, но также обнаружена при бутстрапе CLISP на архитектуре MIPS. Проблема вызвана отсутствием в пакетах необходимых для libtool/pkg-config файлов.
• В репозиториях отсутствует библиотека libffcall.
  • make[1]: *** No rule to make target 'avcall-e2k.lo', needed by 'avcall.lo'. Stop.
  • Отправлен запрос на портирование №4210.

Первичная сборка произведена успешно согласно инструкциям:

./configure --ignore-absence-of-libsigsegv
make

SBCL

В работе: nir@

SBCL является сложным продуктом и его бутстрап требует комплексной работы. В процессе общения в списке рассылки sbcl-devel@lists.sourceforge.net была получена информация касательно нюансов бутстрапа SBCL на новых архитектурах. Из списка рассылки была получена информация о том, что для бутстрапа SBCL не требуется cross-toolchain. Достаточно инструментария в виде линкера, ассемблера и компилятора C для целевой платформы.

Также, с первого августа 2018 года велось портирование SBCL на Linux@RISC-V. Из перечисленного был совет посмотреть на коммиты по ключевым словам RISCV, risc, и rv32. Грубо, процесс портирования выглядит как копирование директории src/compiler и допиливании под нужную архитектуру. Как только этот кусок будет переписан — можно будет переписать определения vops (virtual operations) соответственно. Наиболее полная пошаговая инструкция по портированию SBCL написана Alastair Bridgewater касательно архитектуры ARM.

Также существует разрабатываемая сообществом документация по внутренностям SBCL: https://github.com/guicho271828/sbcl-wiki/wiki и http://www.sbcl.org/sbcl-internals/

Из существующих проблем:

• Необходимо самостоятельно реализовать для кодогенератора SBCL поддержку e2k

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

• make-config.sh — добавляется определение архитектуры (соответствующее 'uname -a');
• build-order.lisp-expr — добавляется указатель на реализацию виртуальной машины: src/code/e2k-vm;
• src/runtime/Config.e2k-linux — добавляется makefile, указывающий на необходимые платформо-зависимые функции;
• src/runtime/e2k-arch.c
• src/runtime/e2k-arch.h
• src/runtime/e2k-assem.S — релизация функций call_into_lisp, call_into_c. Из того, что удалось выяснить на Freenode — данные функции выполняют задачу переключения между C ABI и SBCL ABI и не могут быть написаны ни на чём другом кроме Assembler.
• src/runtime/e2k-linux-os.c
• src/runtime/e2k-linux-os.h
• src/runtime/e2k-lispregs.h — определения регистров. Надо знать platform ABI;
• src/compiler/e2k/* — определение механизма работы компилятора Python с vops (virtual operations);
• src/code/e2k-vm.lisp — маппинг физических регистров на регистры SB-VM;
• assembly/e2k/*

Одна из заметок касалась бутстрапа SBCL на OpenBSD@PPC:

В случае с использованием NFS на хосте и целевой машине:

Cross-compiling SBCL is easy; especially so if you arrange matters (e.g. using NFS)
so that host and target systems can see the same build directory. make.sh doesn't
cater for it directly, so you run each of the five scripts by hand. For example,
cross-compiling to PPC is something like

host$ export SBCL_ARCH=ppc
or

host$ export SBCL_ARCH=x86
ppc$ export SBCL_ARCH=x86

host$ export SBCL_XC_HOST=sbcl
ppc$ . ./find-gnumake.sh
ppc$ find_gnumake
ppc$ sh make-config.sh
host$ sh make-host-1.sh
ppc$ sh make-target-1.sh
host$ sh make-host-2.sh
ppc$ sh make-target-2.sh
ppc$ sh make-target-contrib.sh

Или без NFS:

target$ GNUMAKE=make sh ./make-config.sh
host$ GNUMAKE=gmake SBCL_ARCH='arch' sh ./make-config.sh
host$ scp target:sbcl-directory/local-target-features.lisp-expr .
host$ scp target:sbcl-directory/output/build-id.tmp output/
host$ SBCL_XC_HOST='lisp -batch' sh ./make-host-1.sh
host$ scp -r src/runtime/genesis src/runtime/ldso-stubs.S target:sbcl-directory/src/runtime/
target$ GNUMAKE=make sh ./make-target-1.sh
target$ scp src/runtime/sbcl.nm host:sbcl-directory/src/runtime/
target$ scp output/stuff-groveled-from-headers.lisp host:sbcl-directory/output/
host$ SBCL_XC_HOST='lisp -batch' sh ./make-host-2.sh
host$ scp output/cold-sbcl.core target:sbcl-directory/output/
target$ sh ./make-target-2.sh
target$ sh ./make-target-contrib.sh

Сборка новых версий SBCL более старыми

В процессе обновления SBCL 1.4.12 на архитектуре MIPS32 LE методом сборки с помощью SBCL 1.0.28 было выяснено, что SBCL 1.0.28 не способен собрать версию 1.4.12. Данная проблема вызвана коммитом https://sourceforge.net/p/sbcl/sbcl/ci/04139ea0e0f83a13b7a6fd2df0d797921f9e593b/ использующим BIGVEC в версии SBCL 1.4.8[[1]]. В результате сборку удалось осуществить методом 1.0.28 -> 1.4.6 -> 1.4.12 [[2]]

Клиенты

После сборки sbcl стоит удалить "пустышку" dummy-sbcl; настоящий пакет понадобится как минимум для fricas.