Библиотеки-модули-программы...

[captain cobalt]

Фишка в том, что уже "вставленные" в программу модули не получится отделить от программы - это такое свойство модульной структуры.

Модули не "вставляются" в программу.
Программа загружается поверх библиотечных модулей.
Когда программа завершается, модули остаются и не трогаются.
Теперь поверх них можно загрузить другую программу.

Заменим слово "модули" на слово "ОС".
ОС "вставляется" в программу? Нет.
ОС можно отделить от программы? Можно.
Тогда зачем нужно "свойство модульной структуры"?

Чтобы чего-нибудь там расширить придётся грузить ассемблер (или ЯВУ если угодно) править программу и включать в неё указание на эти модули. Технология динамической подгрузки здесь не канает, потому что уже запущенное приложение не должно нуждаться ни в одной библиотеке и работать самостоятельно.

Это опять "дух процедурного программирования".

Функциональностью не обязательно пользоваться явно.

Если некий модуль загружен в память, а программа умеет использовать абстрактную функциональность, конкретной реализацией является этот модуль, то программа должна использовать этот модуль. А конкретный набор модулей будет конфигурируемым.

[captain cobalt]

Что есть токенизация?

Перевод из plain text в "формат ассемблера".

Ни один из широко используемых спековых ассемблеров не использует plain text для исходников.

Дополнительный проход некой утилитой? А ее нету.

Такая утилита есть.
Для каждого ассемблера своя.

Смотри на вещи шире. Предполагаемый подход твоей хотелки не отрицает.

Вижу, что не отрицает.

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

Это опять "дух процедурного программирования".

Рассмотрим на примере Linux.
У него есть загружаемые модули ядра.
Загрузим такой модуль. Смонтируем.
Всё. Теперь любая программа может пользовать функциональность модуля через стандартный файловый ввод-вывод, хотя о самом модуле "ни сном ни духом".

Теперь обобщим на произвольный программный интерфейс (не только файловый).
Понятно?

[Vitamin]

Перевод из plain text в "формат ассемблера".
Ни один из широко используемых спековых ассемблеров не использует plain text для исходников.

Зато как минимум один ассемблер использует существующие наработки. Лучше синица в руке, чем утка под кроватью %)

Такая утилита есть.
Для каждого ассемблера своя.

Уж тогда возложить на эту утилиту генерацию таблиц для создания релоцируемого кода. Иначе никак.

Это опять "дух процедурного программирования".

Рассмотрим на примере Linux.
У него есть загружаемые модули ядра.
Загрузим такой модуль. Смонтируем.
Всё. Теперь любая программа может пользовать функциональность модуля через стандартный файловый ввод-вывод, хотя о самом модуле "ни сном ни духом".
Теперь обобщим на произвольный программный интерфейс (не только файловый).
Понятно?

Ну вот... Попался... Я если честно, чтото не припомню полиморфизма в ядре линукса. Для того чтобы удостовериться, даже спросил у человека, который разрабатывал эти модули- нету там неявного вызова!!! Нечто похожее есть только при регистрации файлового интерфейса спецустройств, да и то, ядро о твоем модулей и знать не знает пока ты явно не постучишься к обслуживаемому им устройству. Я уже не говорю про простые модули, которые в ядре просто висят и обращение к ним идет по конкретным именам функций, которые должны быть уникальны во всем адресном пространстве!

[captain cobalt]

"Монтирование" с точки зрения ядра Linux это что?

[Vitamin]

"Монтирование" с точки зрения ядра Linux это что?

Вызов функций специфичного модуля, название которого указывается при выполнении операции. И вообще, монтирование тут не при чем по большому счету.

Давай вернемся к простому примеру- та абстрактная библиотека GUI, поддерживающая расширение за счет единого интерфейса разных виджетов. Ты можешь прилинковать кучу модулей со своими виджетами, но библиотека их не будет использовать, потому что ничего не знает про них. Про них должен знать клиент этой библиотеки, который создает объекты, интерфейс которых реализован в тех модулях. Т.е. он должен знать о них. А если программа не знает, она не будет их использовать. Иными словами, расширение функционала программ за счет загрузки дополнительных модулей невозможна, если не предусмотрены специальные возможности для этого (типа загрузка длл и проч).

[captain cobalt]

Уж тогда возложить на эту утилиту генерацию таблиц для создания релоцируемого кода.

Это тоже идея.

Отдельно компилировать любым ассемблером в "плоский код".

Отдельно утилитой - собирать "символьный файл".

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

При таком способе сигнатура прописывается в комментарии.

[elf/2]

Я тут наброски делал по поводу организации сигнатуры. Часть подсмотрел, часть придумал сам. Вот что получилось.

проверка сигнатур нормально работает только на этапе компиляции.

Чего???? Как раз только на этапе линковки. Чтобы знать что и с чем склеивать.

ребятушки это уже не смешно... мангленые имена функций с сигнатуруй появились в компиляторах C++ как workaround: необходимо было как-то разрешать перегруженные функции, а формат obj файлов не содержал типов аргументов. пришлось делать уникальные имена для перегруженных функций. соответсвенно в момент компиляции когда компилятор знает типы всех аргументов при вызове функции он создает это хитрое имя а линкер просто сравнивает две строчки... вы хотите делать перегруженные функции на асме? это не возможно, поскольку синтаксис ассемблера не содержит комманды вызова функции с агрументами.

В клиентском коде используется только memcpy. VI#43543 просто копируется в клиентский модуль с объектным кодом во время компиляции. Во время динамической компоновки они просто проверяются на равенство.

вот именно, попробуйте написать функцию которая имея в регистре A номер экранной линии возвращает адрес в HL и ее вызов в терминах вашего мифического компилятора. и объясните кто и как будет формировать мангленое имя _при вызове_

а возвращаемое значение вообще не кодируется в сигнатуре, потому что перегрузка функции на основании возвращаемого типа не поддерживается поскольку его не всегда можно определить.


ну и главное: всемогуторы не летают!

[elf/2]

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

ну сколько можно, Лена... я уже два раза написал, что на Windows/Linux при загрузке никто абсолютных адресов не правит. делается именно то, что вы предлагали. изменяются адреса только в таблице jump'ов. единственное отличие в том что это делает система а не библиотека.

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

с тем что Витамин и captain cobalt "увлеклись" и пытаются придумать очередной всемогутор, который во-первых сделать не реально, а во-вторых никто использовать не будет согласен

[Vitamin]

elf/2: ты прав насчет проблем и всего-всего. Но есть одна маленькая хитрость. По крайней мере у меня. Все дело в том, что символическое имя и внутреннее имя в исходнике могут различаться!!! И все прекрасно ложится тогда!
Например, импортируем две перегруженные функции с разной сигнатурой.

__EXTERN "onefunc@B(DD)",func_ver_1
__EXTERN "onefunc@B(WW)",func_ver_2
...
;гдето в коде
CALL_ func_ver_1 ;зовем первую функцию
...
CALL_ func_ver_2 ;зовем вторую функцию

равнозначно экспортирование
__PUBLIC "myfunc@W(BB)",FUNCTION
myfunc1
....

__PUBLIC "myfunc@W(WW)",FUNCTION
myfunc2
...

Вот и все! И нет никакого конфликта!

Это тоже идея.
Отдельно компилировать любым ассемблером в "плоский код".
Отдельно утилитой - собирать "символьный файл".
Динамический компоновщик будет брать для каждого модуля эти два файла. Когда компоновка завершена, таблицы символов можно выбросить из памяти.
При таком способе сигнатура прописывается в комментарии.

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

[Vitamin]

с тем что Витамин и captain cobalt "увлеклись" и пытаются придумать очередной всемогутор, который во-первых сделать не реально, а во-вторых никто использовать не будет согласен

Я уже давно все придумал и написал. Теперь вот пытаюсь с помощью присутствующих улучшить и применить несколько шире, чем только в моих проектах. А то за%%%ло что на каждую идею начинаются крики "да это уже есть на платформе ..., нефиг выдумывать, и вообще ты писюканец". И сидят такие пальцы гнутые, сами нихера не сделали...
Не спорю, сам такой иногда бываю, но хоть пытаюсь с грехом пополам разобраться в предложении и идеях.