OberonCore

Еще в предыдущей 0.9 версии можно было код на Обероне скомпилировать для 32/64 бит с опциями оптимизации и получить исполняемые файлы. Чего же не хватало? Не хватало модульной загрузки. Оберон - модульный язык программирования, и каждый модуль компилируется в бинарное представление, которое подключается в исполняемую программу либо статически, либо динамически.

Выходными данными компилятора Omf являются сгенеренные тестовые файлы .c .h, из которых затем C-компилятором с опциями оптимизации можно получить объектные файлы .o . Выходными данными компилятора Oml являются текстовое .ll и бинарное .bc представление LLVM, из которых затем посредством утилиты llc с опциями оптимизации можно также получить объектные файлы .o .

В версии 0.95 реализован базовый модуль загрузчика OmcLoader и реализации для динамической загрузки разных типом файлов:

OmcObjLoader_Coff для загрузки объектных файлов Windows в формате COFF

OmcObjLoader_Elf для загрузки объектных файлов Unix в формате ELF

OmlBcLoader для загрузки файлов бинарного кода LLVM с выполнением с помощью JIT-компилятора

OmcOcfLoader адаптированный к новым интерфейсам штатный загрузчик .ocf файлов BlackBox

В настоящей версии модульная загрузка работает в виде:

Oml LLVM - .o COFF Windows/ELF Unix 32/64 bit быстрая загрузка объектных файлов

Oml LLVM - .bc LLVM binary code Windows/Unix 32/64 bit медленная загрузка файлов JIT-компилятором

Omf OFront - на данный момент не реализована

Omb BlackBox - загрузка .ocf файлов

С точки зрения ядра - это обычные динамически загружаемые посредством Kernel.ThisMod модули с установленными флагом dyn=17 в поле opts.

Простой пример с HelloWorld
1. Скомпилировали в бинарный код

2. Получили объектный код с оптимизацией O3

3. Выполнили динамическую загрузку и запуск бинарного файла

4. Выполнили динамическую загрузку и запуск объектного файла


Разница между 3 и 4 появится, если задать опции трассировки -tl 1.

При наличии нескольких и больших по объему модулей скорость их загрузки в случае LLVM JIT существенно уменьшается.
Например, прогон набора семи тестов вида

будет загружаться как объектники за 0.1 сек (на моем компьютере)

а как бинарный LLVM-код за 29 сек


Разница существенная. К тому же, загрузка LLVM bc требует LLVMT.so библиотеки размером 54 мегабайта.

При реализации загрузчика использовалась информация по COFF и ELF.

Кроме непосредственно загрузки выполняется операция линковки вновь подключаемого модуля к адресам процесса. Это реализуется через подстановки адресов в структурах, именуемых Relocations (в штатном загрузчике ocf это обозначается как Fixup). Механизм подстановки сильно зависит от типа платформы. Приведенные загрузчики реализовывались на платформах X86, X64 за отсутствием иных. Для них реализованы расширенные типы X86Relocator, X64Relocator. Для портирования на другие платформы требуется реализация соответствующих платформо-зависимых Relocator-ов.

По результатам разговора с Евгением Эдуардовичем и темы https://forum.oberoncore.ru/viewtopic.php?f=134&p=113411#p113411 пару слов о платформо-зависимых модулях.

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

Omc/ObjLoader_Coff – для Windows формата COFF

Omc/ObjLoader_Elf – для Unix формата ELF

Тогда как обычный, платформо-независимый модуль имеет имя без подчеркивания, например, Omc/OcfLoader. Платформо-зависимые модули могут зависеть от версий ПО, например Files_16 для версии 1.6 (заметьте, не я предложил менять интерфейс в Files).

2. При компиляции и загрузке для Windows кодовые и символьные файлы платформо-зависимых модулей для Omb хранятся в каталогах Cbwe и Sbwe соответственно. Тогда как платформо-независимые для Omb хранятся в каталогах Code и Sym.

3. Для подготовки разных версий делаются команды платформо-зависимой компиляции, например, для Omb Windows

Для Omb Unix


4. Таким образом, имеем 1 модуль, с параметризацией сборки по: ОС, 32/64, Бэкенд, 1.7/1.6 .

А если у кого-то были имена с _? Это ведь язык разрешал.

Имена процедур могут иметь _, имена модулей - нет.

У нас - и у некоторых коллег - традиционно парные подсистемы с тестовыми и разраб. модулями имели постфикс _dev.
Myapp, Myapp_dev.

А запрет принципиален для МультиОберона?

Имена процедур преобразуются в Ofront, Oml и даже в XDS в вид ModuleName_ProcName, или ModuleName_TypeName_ProcName. Динамический загрузчик ищет имя модуля по имени функции в объектнике. А если Myapp_dev, то непонятно, в каком модуле искать, может, функцию dev из Myapp.

Можно думать о том, чтобы сделать двух-символьный сепаратор __:
ModuleName__TypeName__ProcName

Да, двухуровневый был бы выходом.

Иначе, получается, урезаемся относительно стандарта языка.

Дмитрий, а почему генерируете не разделяемые библиотеки (.so/.dll)? Или это они и есть? Какие-то слова незнакомые.

Модуль имеет внешние ссылки, которые надо разрешать, и даже список импорта из модулей, которые имеют внешние ссылки ...
А dll/so это уже скомпонованное и очень избыточное.

Есть реализация лиспа (GCL/ECL), в которой горячая замена кода реализована именно через разделяемые библиотеки, а значит, разрешение внешних ссылок должно быть возможно и в этом случае. Значит, если я правильно домысливаю, то Вы так не делаете только из-за неоптимальности данного решения?

1. Я правильно понимаю, что формат COFF - это внутренности DLL; Формат ELF - это внутренности файла .so?

2. А почему не использовать дополнительное расширение вместо дополнения собсно имени файла?

ObjLoader.coff Вместо ObjLoader_Coff
ObjLoader.elf вместо ObjLoader_Elf

Тогда коллеги, любящие _, смогут продолжать это использовать в именах модулей, как позволяет язык.

3. А что такое платформо-зависимый модуль? Или платформо-зависимая реализация модуля? Кажется, это нигде точно не оговаривалось. Вот, например,

Files -> System/Mod/Files.odc + Code/Files.ocf + Sym/Files.osf
HostFiles -> Host/Mod/Files.odc + Host/Code/Files.ocf + Host/Sym/Files.osf

Ничто внутри каркаса ББ не "знает" о том, что существует модуль HostFiles (исходный текст и артефакты компиляции) для платформ: Windows, Linux, FreeBSD, OpenBsd. Для всех процедур внутри каркаса - существует только один модуль HostFiles, расположенный в Host/Mod Host/Code Host/Sym.

При этом, все HostFiles - совершенно независимые (друг от друга) модули. Нельзя говорить о "реализации модуля HostFiles для платформы Windows" и "реализации HostFiles для платформы FreeBSD". Они друг другу ничего не обязаны.

Больше того, вполне можно сделать сборку ББ, в которой не будет модуля HostFiles. А реализации Files.File и Files.Directory будут где-то в другом модуле (или модулях).

О "зоопарке" платформенных модулей HostFiles знает только скрипт, сделанный А.Ширяевым на баше и живущий в гит-репозитории. И он же этим зоопарком управляет: следит за тем, где какая реализация хранится, и когда куда нужно "подложить" нужную реализацию.
************************
А что вы подразумеваете под платформо-зависимой реализацией или платформо-зависимым модулем? (в ваших постах упоминается и то, и другое)

1. Берем модуль Оберона Omtest/HelloWorld.odc, получаем (например, Omf) OmtestHelloWorld.c
2. Компилируем OmtestHelloWorld.c, получаем OmtestHelloWorld.о. Объектник однозначно соответствует модулю.
3. Получить OmtestHelloWorld.dll (80К) из OmtestHelloWorld.о(3К) - нужно сильно умудриться, ибо получите неразрешенные ссылки.
4. Если ссылки разрешите при создании dll, то 1 загруженная dll не будет соответствовать 1 модулю.

Не совсем, COFF - формат объектного, загрузочного файла и разделяемой библиотеки, обычно используемый в Windows,
ELF - формат объектного, загрузочного файла и разделяемой библиотеки, обычно используемый в Unix.
Легко, это не является проблемой, вот в А2 эти интересные соглашения развили до имен модулей.

Как я уже говорил, проблемой является вездесущее наличие имен вида ModuleName_ProcName. Нужно разделять имена Модуля от имен процедуры.
Аргументацию Ермакова и Вашу считаю убедительной, и в следующей версии МультиОберона имена будут вида:
ModuleName__ProcName / ModuleName__TypeName__ProcName
А платформо-зависимые модули:
ObjLoader.elf.odc / ObjLoader.coff.odc


Я не ограничиваюсь BlackBox. Но даже если ограничиваться только BlackBox, то там HostFiles не отделаться. Там Kernel - платформо-зависимый.
А у меня этих Kernel'ов 15 уже сейчас. Для 64 там сборщик мусора другой. И для Omf, Oml, и для 1.6, и проч, и проч.

А начнете делать что-то кроссплатформенное (с импортом из новых сишных хедеров), то HostFiles Вам будет мало. Как сказал один человек, "помидорами не отделаетесь".

P.S. Правда, Kernel к модульной загрузке не относится, но OmcObjLoader.coff - точно

Тем не менее, в лиспе это как-то работает.

80К много, там порядка 1K должно добавиться. Хотя, конечно, гнусный тулчейн запускать - то ещё удовольствие.
Но смысла особого делать модули в виде dll вроде нет.

Но ведь язык не запрещает назвать модуль «Mymodule__dev» (с двумя подчёркиваниями).