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

[elf/2]

А, простите меня, грешного, на амиге - не надо получать указатели на ф-ции! вот в чем финт.

зато прямой вызов по известному адресу быстрее

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

ось должна облегчать жизнь пользователя в первую очередь и программиста во вторую. что винда/линукс и делают. в результате уменьшается размер кода и число ошибок (нельзя забыть проинициализировать либу, ошибки линковки обрабатываются системой, нет никакой разницы для программиста между статической/динамической линковкой)
а механизм там простой до безобразия: у либы есть список экспортируемых функций а у проги - список jump'ов на импортируемые. при загрузке винда список jmp'ов корректирует

[Advertiser]

[icebear]

Что значит имена не известны? А как кодер их должен юзать, если он не знает их имена? По функциям запрос делать, что ли?

Почитай про COM, там по дефолту вообще только три функции декларированы. Вот где башка кипеть начнёт.

[elf/2]

Что значит имена не известны? А как кодер их должен юзать, если он не знает их имена? По функциям запрос делать, что ли?

очень просто. есть API - некий набор функций. некие библиотеки этот API поддерживают

при загрузке приложения ищем файлы по маске (например 'plugins/*.dll'). каждый файл по очереди грузим через LoadLibrary, и получаем из каждой библиотеки нужные функции.
если файло загрузилось и нужные функции нашлись то спокойно используем (кстати в ruby для этого (ну почти для этого даже спецтермин придумали - duck typing)

[Vitamin]

Не путайся и не путай народ - цитата: то получаем плагинную систему
опять ты пишешь менеджеры с собой (один менеджер загрузчик для всех! типа boot). Никаких плагинов (можно, но не к теме) - тут именно набор стандартных ф-ций, которые юзают любые проги (одназадачная оська с выходом в ось 8) а не в васик/тырдос.

Ща поясню. Плагинная система- сиречь ОС и приложения (только в другом масштабе). Одна большая хост-программа с навороченным менеджером и простенькие плагины. А если у нас нет хост-программы/ОСи, то лепить навороченный менеджер (заметь, в КАЖДУЮ программу) нет абсолютно никакого смысла.

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

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

2Shaos: можно получить документацию по формату библиотек, возможностям и т.п. Потому как функциональности может быть недостаточно и придется "изобретать велосипед"...

[acidrain]

(заметь, в КАЖДУЮ программу)

Нет же, не в каждую!!!

[yoko_ono]

Смотрим внимательнее на тот исходник. Вызов функции (многократный) там занимает одну строчку. Все остальное- подготовка библиотеки и ее освобождение. Это однократно выполняемая последовательность.

Для КАЖДОЙ функции!

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

Ну вот, вы сами и написали, что в любом случае дело сводится к выковыриванию абсолютных адресов КАЖДОЙ функции, либо руками, либо стартап-кодом!

[yoko_ono]

конечно нет:
1. открываем библиотеку
2. получаем указатель на fn1
3. получаем указатель на fn2
...

n. пользуем функции
n+1. закрываем библиотеку

Получаем указатель для КАЖДОЙ используемой функции, как же 'конечно нет'?

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

Оптимально ли? С каждым ехешником путешествуют лишние ссылки релокации, а если какой-нибудь, даже мелкой, либы нету - то ехешник осью в принципе не загрузится. Хотя программист мог бы решить по ходу дела, что если либы нету, то и каких-то функций нет.

[yoko_ono]

2. даже если мы используем только одну функу из библиотеки в памяти будет висеть вся либа

Именно! В то время как компиляция либ из исходника позволяет компилировать только РЕАЛЬНО требуемые функции, а ведь именно от сборки либ из исходников Vitamin и хочет уйти!

оригинальное предложение Витамина т.е. сборка из объектников (на мой взгляд опять же) имеет больше перспектив

Ну на мой скромный взгляд, оригинальности тут на грош - идея 'цельнотянутая' с пц-винды-линуха.

Прежде всего его идея подразумевает релоцируемость. Коя реалтизуется на этапе компиляции в любом ассемблере или генераторе кода и поддерживается осью на пц/амиге/и т.д. На Спектруме же - ни того, ни другого. Существующие ассемблеры все как один не поддерживают релоцируемость (хитрости с макросами не в счёт). Да и вообще, парадигма программирования на Спектруме чужда релоцируемости - если, конечно же, не писать все программы в 'академическом' стиле программирования Z80.

Если уж так хочется либ, то можно предложить следующий механизм, свободный от релоцируемости как минимум user-программы (то бишь той, которая пользуется либами и грузит их с диска).

Юзер-прога грузит либу в статически определённое место в памяти. Та сама себя релоцирует каким-либо методом (пусть автор либы поупражняется, раз уж ему нечего делать, кроме как либы писать). И например в начале указанного user-программой места строит таблицу вызовов своих функций, состоящей из JP func1:JP func2:JP func3 и т.д. После чего user-программа, зная начало этой таблицы (раз уж она его и указала), делает туда CALL'ы. Можно отделить собственно тело библиотеки от таблицы вызовов. Можно тело библиотеки класть в страницу, перед вызовом включая её (нету оси - нету менеджера страниц, доступного библиотеке).

[Shaos]

2Shaos: можно получить документацию по формату библиотек, возможностям и т.п. Потому как функциональности может быть недостаточно и придется "изобретать велосипед"...

Дык вот же всё: http://www.nedopc.org/nedopc/shaos/libman_r.shtml

Поясню в двух словах - либы релоцируемы с шагом 256 байт (таблица релокации занимает 1/8 размера кода) во время загрузки. Либы при открывании накидываются друг за другом в страницу 16К пока не займут её полностью, потом ново-открываемые либы накидываются в другую страницу 16К и т.д. Страницы подключаются в нужные окна в момент вызова функций из соответствующей либы. Возможность задавать окно где либа будет вызываться нужна не только ради удобства программиста, но и например ради вызывания либы из другой либы (для этого они должны сидеть в разных окнах).

[Vitamin]

Получаем указатель для КАЖДОЙ используемой функции, как же 'конечно нет'?

Ржунимагу. А на амиге по индексу функции случайно не указатель на нее ищется (косвенный) для последующего перехода? Потому как, если нет указателя на функцию или ее адреса (разные вещи), то функцию вызвать невозможно!

Именно! В то время как компиляция либ из исходника позволяет компилировать только РЕАЛЬНО требуемые функции, а ведь именно от сборки либ из исходников Vitamin и хочет уйти!

Мадам! А вы про оптимизацию слышали? Когда из объектого кода (библиотек то есть) удаляются неиспользуемые функции? Конечно, данная операция применима только при сборке готовой программы, а не runtime-сборке, но тем не менее :lol
Да, кстати, как на этапе компиляции определить нужность-ненужность функций с учетом "парадигмы программирования на спектруме" и без "извратов с макросами"? Я, если честно, даже с извратами не смогу однозначно это определить.

Ну на мой скромный взгляд, оригинальности тут на грош - идея 'цельнотянутая' с пц-винды-линуха.

А глаза разуть и посмотреть, что идея динамической линковки одинакова и на амиге и на линухе и на винде (что неоднократно показывалось в этой ветке)? Разница только в технических тонкостях организации вызова.
ЗЫ. Если б идея была "цельнотянута" с амиги, тут бы наверное кипятком пИсали....

Прежде всего его идея подразумевает релоцируемость. Коя реалтизуется на этапе компиляции в любом ассемблере или генераторе кода и поддерживается осью на пц/амиге/и т.д. На Спектруме же - ни того, ни другого. Существующие ассемблеры все как один не поддерживают релоцируемость (хитрости с макросами не в счёт).

И почему же не в счет? И что мешает написать новый компилятор?

Если уж так хочется либ, то можно предложить следующий механизм, свободный от релоцируемости как минимум user-программы (то бишь той, которая пользуется либами и грузит их с диска).

user-программа свободно может быть и нерелоцируемой, ей это не нужно. Читаем внимательнее.

Shaos: выравнивание это хорошо. Но не всегда. Я у себя это опционально делаю. Еще вопросы
-из либы экспортируются только функции или могут экспортироваться данные?
-возможно ли при компиляции либы задать ссылки на внешние, неизвестные на этапе компиляции точки?
-если да, то как это описывается форматом
-каким образом компилируется релоцируемая либа? (особый компилятор, еще какие "извраты" ))