OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 05 Август, 2021 17:10

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Модульная загрузка
СообщениеДобавлено: Понедельник, 29 Июнь, 2020 09:18 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
Еще в предыдущей 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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 29 Июнь, 2020 09:30 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
В настоящей версии модульная загрузка работает в виде:
    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.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 29 Июнь, 2020 09:43 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
Простой пример с HelloWorld
1. Скомпилировали в бинарный код
Код:
[ddag@suok3vm Mob]$ Blue/omlsh co :OmtestHelloWorld
oml:compiling ./Omtest/Mod/HelloWorld.mod  >./Omtest/Clue/OmtestHelloWorld .ll=9561 .bc=3412

2. Получили объектный код с оптимизацией O3
Код:
[ddag@suok3vm Mob]$ Blue/omlsh build -pl 2 -h -opt "-O3" OmtestHelloWorld
Omtest/Clue>/home/ddag/mobdev/Mob/Blue/llc -filetype=obj -march=x86 -O3 OmtestHelloWorld.ll -o OmtestHelloWorld.o

3. Выполнили динамическую загрузку и запуск бинарного файла
Код:
[ddag@suok3vm Mob]$ Blue/omlsh run -ext bc OmtestHelloWorld
Hellow, World

4. Выполнили динамическую загрузку и запуск объектного файла
Код:
[ddag@suok3vm Mob]$ Blue/omlsh run -ext o OmtestHelloWorld
Hellow, World


Разница между 3 и 4 появится, если задать опции трассировки -tl 1.
Код:
[ddag@suok3vm Mob]$ Blue/omlsh run -ext o -tl 1 OmtestHelloWorld
?Unmapped external #27 main= 0
?Unmapped local #0 = 0
?Unmapped local #1 OmtestHelloWorld= 0
Hellow, World


Код:
[ddag@suok3vm Mob]$ Blue/omlsh run -ext bc -tl 1 OmtestHelloWorld
InitializeLoader
end-of-InitializeLoader
NewModSpec OmtestHelloWorld
---------- ReadHeader OmtestHelloWorld
LoadLlvmModule ./Omtest/Clue/OmtestHelloWorld.bc
end-of-LoadLlvmModule ./Omtest/Clue/OmtestHelloWorld.bc
AppendImp Runner
NewModSpec Runner
AppendImp Kernel
NewModSpec Kernel
AppendImp OLog
NewModSpec OLog
AppendImp2 HostConLog
NewModSpec HostConLog
---------- end-of-ReadHeader OmtestHelloWorld
++++++++++ ReadModule OmtestHelloWorld
Create_EngineLlvmModule OmtestHelloWorld
end-of-Create_EngineLlvmModule OmtestHelloWorld
MapStaticModules OmtestHelloWorld
end-of-MapStaticModules OmtestHelloWorld
MapDllModules
end-of-MapDllModules
RunStaticConstructors OmtestHelloWorld
end-of-RunStaticConstructors OmtestHelloWorld
RunProcOfPtr OmtestHelloWorld__reg
end-of-RunProcOfPtr OmtestHelloWorld__reg
RunProcOfPtr OmtestHelloWorld__body
Hellow, World
end-of-RunProcOfPtr OmtestHelloWorld__body
RunFunctionAsMain main
end-of-RunFunctionAsMain main
++++++++++ end-of-ReadModule OmtestHelloWorld


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 29 Июнь, 2020 09:57 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
При наличии нескольких и больших по объему модулей скорость их загрузки в случае LLVM JIT существенно уменьшается.
Например, прогон набора семи тестов вида
Код:
Blue/omlsh test -pl 2 -ext bc OmtestOmcSimpleTest OmtestOmcStringsTest OmtestOmcSystemTest OmtestOmcImportsTest OmtestOmcExtensionsTest OmtestOmcBoundTest OmtestOmcAdvancedTest

будет загружаться как объектники за 0.1 сек (на моем компьютере)
Код:
% time {lue_tests_run.sh > a.log} 1
105275 microseconds per iteration

а как бинарный LLVM-код за 29 сек
Код:
% time {lue_tests_jit_run.sh > a.log} 1
29228720 microseconds per iteration


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 29 Июнь, 2020 10:34 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
При реализации загрузчика использовалась информация по COFF и ELF.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 10:17 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
По результатам разговора с Евгением Эдуардовичем и темы 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
Код:
Binwe\ombc co -h -odc -wsd -ne Api_bwe OStrings_bw OLog_bw Runner_bwe17 Times Testing Baseloader_17 HostApi_bwe HostConLog_bw HostTimes_bwe

Для Omb Unix
Код:
Binue/ombc co -h -odc -wsd -ne Api_bue OStrings_bu OLog_bu Runner_bue17 Times Testing Baseloader_17 HostApi_bue HostConLog_bu HostTimes_bue


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 11:54 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9428
Откуда: Россия, Орёл
А если у кого-то были имена с _? Это ведь язык разрешал.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 13:03 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
Илья Ермаков писал(а):
А если у кого-то были имена с _? Это ведь язык разрешал.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 15:40 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9428
Откуда: Россия, Орёл
У нас - и у некоторых коллег - традиционно парные подсистемы с тестовыми и разраб. модулями имели постфикс _dev.
Myapp, Myapp_dev.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 16:25 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
Илья Ермаков писал(а):
А запрет принципиален для МультиОберона?

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 16:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9428
Откуда: Россия, Орёл
Да, двухуровневый был бы выходом.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 20:09 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1291
Дмитрий, а почему генерируете не разделяемые библиотеки (.so/.dll)? Или это они и есть? Какие-то слова незнакомые.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 20:36 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
budden писал(а):
Дмитрий, а почему генерируете не разделяемые библиотеки (.so/.dll)? Или это они и есть? Какие-то слова незнакомые.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Понедельник, 21 Декабрь, 2020 23:06 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Вторник, 22 Декабрь, 2020 00:20 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 495
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 знает только скрипт, сделанный А.Ширяевым на баше и живущий в гит-репозитории. И он же этим зоопарком управляет: следит за тем, где какая реализация хранится, и когда куда нужно "подложить" нужную реализацию.
************************
А что вы подразумеваете под платформо-зависимой реализацией или платформо-зависимым модулем? (в ваших постах упоминается и то, и другое)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Вторник, 22 Декабрь, 2020 09:59 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
budden писал(а):
Есть реализация лиспа (GCL/ECL), в которой горячая замена кода реализована именно через разделяемые библиотеки, а значит, разрешение внешних ссылок должно быть возможно и в этом случае. Значит, если я правильно домысливаю, то Вы так не делаете только из-за неоптимальности данного решения?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Вторник, 22 Декабрь, 2020 10:22 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 561
Откуда: Москва
adimetrius писал(а):
1. Я правильно понимаю, что формат COFF - это внутренности DLL; Формат ELF - это внутренности файла .so?

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

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

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Вторник, 22 Декабрь, 2020 16:36 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1291
Дмитрий Дагаев писал(а):
budden писал(а):
Есть реализация лиспа (GCL/ECL), в которой горячая замена кода реализована именно через разделяемые библиотеки, а значит, разрешение внешних ссылок должно быть возможно и в этом случае. Значит, если я правильно домысливаю, то Вы так не делаете только из-за неоптимальности данного решения?

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Вторник, 22 Декабрь, 2020 21:34 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1384
Дмитрий Дагаев писал(а):
3. Получить OmtestHelloWorld.dll (80К) из OmtestHelloWorld.о(3К) - нужно сильно умудриться, ибо получите неразрешенные ссылки.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модульная загрузка
СообщениеДобавлено: Вторник, 13 Апрель, 2021 19:11 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 233
Откуда: г. Рига, Латвийская ССР
Илья Ермаков писал(а):
Да, двухуровневый был бы выходом.

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2021, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB