OberonCore

МультиОберон для LLVM содержит в себе полностью новый бэкенд LLVM версии 5.0.

Oml предназначен для работы:
- из командной строки,
- в среде BlackBox.

Oml работает как с '.odc' файлами, так и с текстовыми файлами '.mod' из среды BlackBox и только с текстовыми файлами '.mod' из командной строки.

Oml работает в качестве оболочки OmlSh.exe командной строки, что позволяет делать скрипты на Обероне.

В комплект входят модули системы выполнения (Kernel, ..), позволяющие запускаться как на 32-бит, так и на 64-бит.

Ссылка на МультиОберон на гитхабе здесь

Если совсем просто, то после установки можно запустить команду 32-битного приложения:
Команда осуществляет компиляцию Omtest/Mod/HelloWorld.mod и выполнение Omtest/Clwe/HelloWorld.ocf как динамически загруженного модуля оболочкой OmlSh.exe.

Либо можно запустить команду 64-битного приложения:
Команда осуществляет компиляцию Omtest/Mod/HelloWorld.mod и выполнение Omtest/Clwr/HelloWorld.ocf как динамически загруженного модуля оболочкой OmlSh.exe.

Если интересует, как сделан интерфейс к LLVM, то используется LLVM-C: C interface to LLVM. В коде это реализовано в модуле LlvmC, сгенеренного по хедерам LLVM версии 5.0.

Мета-информация та же самая, что и у остальных, одинаковы структуры (Kernel.Module, Kernel.Type и проч) и реализация близка к CPFront. Например, для модуля HostTimes заполнение поля Kernel.Module в случае Omf, файл HostTimes.c, будет таким
а заполнение поля в случае Oml, файл HostTimes.ll, будем аналогичным
Таким образом, получив указатель на Kernel.Module, мы будем иметь одинаковые структуры (с точностью до размерности указателя) с одинаковыми данными для всех 3 бэкендов.

Проверками работы оптимизации в LLVM для МультиОберона я не занимался пока еще. В принципе, кому интересно, может попробовать скомпилировать в '.ll', а потом запустить llc с опциями (например, -O=1, -O=2, -O=3) для получения объектника. Более поздняя версия llc описана здесь.

До сборки с оптимизацией я не дошёл, но и без этого интересно

Меняем Go

А вообще, планируется ли сделать все арифметические переполнения ошибками времени исполнения и компиляции?

Хороший вопрос ... Не уложилось пока, что с этим делать. Но Ваши примеры красноречивы.

Во время сборки и/или установки LLVMT.so на Linux сталкивался с проблемами старых glibc-ов. То, что меньше 2.15 (посмотреть ldd --version) вызывало проблемы. Сначала формат ABI поменялся (ELF file OS ABI invalid). Поменял формат с помощью brandelf - пошло требовать GLIBX_2.15 и прочая, и прочая. А также пришлось пакет tinfo доставлять и для 64, и для 32-битной поддержки.

Про долгую загрузки bitcode - https://youtu.be/EQjS-6DtPls?t=1673
Если по каким-либо причинам всё же хочется использовать JIT вместо AOT, то можно попробовать Sulong из Graalvm. Не знаю, как в сравнении с MCJIT, но граалевский lli запускает в 100 раз быстрей, чем lli от llvm

Действительно в 100 раз? Есть какие-то бенчмарки?

На бенчмарк это не тянет. Я просто собрал транслятор Восток в единый файл с биткодом размером ~1.5 Мб, и пробовал его запускать разными способами.
В режиме по умолчанию(-O2) LLVM lli запускал транслятор 20 секунд, с флагом -O0 - 8 сек, в режиме интерпретатора я не смог его запустить из-за ошибок поиска функций стандартной библиотеки Си. Через Sulong lli транслятор запустился за 0.08 сек, с флагом --jvm - за 0.8 сек.
Странность заключается в том, что сбор транслятора с помощью clang из Си занимает 3.5 секунды. Это заставило меня всё перепроверить - выяснилось, что в дело вмешалась устаревшая версия lii-5.0, собранная в отладочном режиме. Боевой lli-6.0 запустил программу за 1.8 сек. в режиме по умолчанию, и за 0.8 сек с опцией -O0, в режиме интерпретатора(--force-interpreter) - за 0.08 сек.
Итого, в режиме JIT разрыв всего лишь 10 кратный. Время работы самой прогаммы пока не удалось нормально замерить

Дошли руки потестировать выполнение объёмного кода. С производительностью у Sulong из GraalVM Community Edition 19.3.0 всё плохо.
То, что заранее собранный через clang исполнимый файл делает за 0.1 сек, то Sulong lli делает за 13 сек, загружая при этом 2-а ядра. LLVM lli с опцией -force-interpreter делает то же самое за 39 сек., но загружая 1-о ядро. Это касается выполнения оптимизированного биткода.

После разархивирования надо запускать скрипт инсталляции, который делает chmod и все прочее.
в QuickStart написано:

Например, я инсталлирую в /home/ddag/mobdev/Mob. А BlackBox уже установлен в /home/ddag/mobdev/bb. Мне нужно сделать:

После этого должны установиться все chmod, правильные версии Runner, Kernel и т.д.

Что означает путь к BlackBox в случае GNU/Linux? Вторичный каталог для пользовательских файлов?
Создав пустой каталог Mob-BlackBox, получаю такое

Есть ли какая причина для того, чтобы не размещать файлы сразу с установленным атрибутом исполнимости?

Необходимым условием установки является предустановленный BlackBox.

От него используется Kernel, Files, и т.д.

Насчет того, чтобы сделать в будущем возможность установки без предустановки BlackBox можно подумать (это разумно) ...

Вот меня и интересует, что означает предустановленный BlackBox в случае с GNU/Linux. Deb - пакет копирует файлы по предопределённому пути. Его и надо указывать?

Кажется, понял. Нужно использовать архив, а не репозиторий. Тогда это тоже нужно указать в описании. Но лучше для распространения в GNU/Linux сделать deb-пакет. Там можно прописать и завимость от установленного BlackBox

Нужно указать путь, где искать System и прочие подсистемы. Насчёт пакета - есть плюсы и минусы. Из минусов - необходимость каких-то прав для инсталляции. Инсталлятор в данной пре-версии пока временный, утрясаются окончательные варианты.

Дмитрий Викторович, спасибо за ваш труд!

Важный момент! С сегодняшнего дня завершена регистрация домена obertone.ru.

Везде указывайте в документации, где это необходимо, домен: https://blackbox.oberon.org/download