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

[icebear]

Есть вопросы? исправления? дополнения?

По объектным файлам: разве это не те файлы, которые содержат исполняемый код, но не имеют "обёртки" (сиречь заголовка)? Потому как exe от dll по идее не сильно отличаестя, точнее отличается тем, что exe функций не экспортирует.

[acidrain]

(это я о просьбе показать пример подключения библиотеки и вызова функции).
2Shaos: информацию по libman я прочитал сразу, как только acidrain выложил ссылку. И задал несколько вопросов, получив ответы только на половину. Так что согласен, что интереса- 0...

Хмм я ж выложил. ты не читаешь, да?
Кому вопросы задавал?
Я за 2й пункт. Наконец то конструктивный разговор прорисовывается.
Но никто не мешает Си написать для пункта 1.
Конструктивно ты не хотел разговаривать - я выкладывал, искал, пытался услышать вопросы. Ничего не было. Есть вопросы - задавай. Могу скинуть на мыло 10мб исходников святая-святых exec.library (единственная либла написаная в асме, а не в си). Также около 30 мб rom kernel manuals - будет желание проштудировать и понять всю систему из нутри? =)

[yoko_ono]

HMODULE h = LoadLibrary(pluginName);
FOO fn = (FOO)GetProcAddress(h,"foo");
(*fn)();
CloseHandle(h);

или линуксового:

m = dlopen("libsample.so", RTLD_LAZY);
fn = (FOO)dlsym(m, "foo");
(*fn)();
dlclose(m);

И такой ужас ДЛЯ КАЖДОЙ функции?..

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

[yoko_ono]

Из чего это следует? Может ноаборот... уменьшаются?

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

А что гадать то? Не надо гадать. В самом примитивном случае, строится табличка распределения памяти между библиотеками...

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

[Vitamin]

По объектным файлам: разве это не те файлы, которые содержат исполняемый код, но не имеют "обёртки" (сиречь заголовка)? Потому как exe от dll по идее не сильно отличаестя, точнее отличается тем, что exe функций не экспортирует.

По идее да, например на линухе результат сборки (объектный файл или разделяемая библиотека) зависит от ключей компилятора (если не собирается программа с main(int argc, char const * argv[])) В винде же надо еще прописывать дополнительные спецификаторы в заголовках, в зависимости от того импортируется или экспортируется функция.

Я за 2й пункт.

В смысле за динамическую компоновку? При условии отсутствия ОС применимо только в плагинной системе...

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

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

(единственная либла написаная в асме, а не в си)

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

И такой ужас ДЛЯ КАЖДОЙ функции?..
На амиге сделано оптимальным образом - для вызова функции достаточно знать, в какой из jmp в таблице вызовов надо попасть (а не извлекать смещение для каждой функции отдельно), и вдобавок базовый адрес (где эта таблица вызовов, то есть). Как я думаю, проблема с пц в том, что целый регистр отдать под базовый при вызове через таблицу jmp - непозволительная роскошь для убогой х86 архитектуры.

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

[acidrain]

2acidrain: давай начнем с терминологии (надо было с этого и начинать...). итак, имеем 3 вида управления кодом программы
1) Статическая линковка. Объектные файлы, созданные заранее, подключаются к бинарнику на этапе компиляции и присутствуют в исполнимом файле. Во время работы не требуется никаких дополнительных движений со стороны программы чтобы подключить эти объектные файлы, просто прямые вызовы на функции. В простейшем случае, объектные файлы, скомпилированные из разных исходных текстов собираются в итоговый бинарник. При подключении одной и той же библиотеки в две разные программы данные физически дублируются. Примеры- a,obj,lib файлы (первое что на ум пришло)
2) Динамическая линковка. Объектные файлы подключаются во время работы программы путем открытия библиотеки (неважно, кто это делает, ОС или само приложение). Дальнейший вызов функций осуществляется на основе имеющегося описателя подключенной библиотеки. При подключении одной и той же библиотеки в две разные программы (для многозадачных ОС), код не дублируется. Примеры- so,dll.
3) Прочее. В частности, отсутствие линковки на уровне бинарных файлов, только на уровне исходных текстов на этапе компиляции. Использование только внутренних функций или функций ОС (в общем случае, если таковая имеется).

Есть вопросы? исправления? дополнения?

Чего ты сразу с терминологии не начал? без моей помощи не мог разобраться что как называется? темболее ниже пишешь, что твое творение ни под один пункт не подходит, тогда что ты придумал?
Ты опубликовал свою идею для получения одобрения или посоветоваться - вот мой совет: не пытайтесь усложнить ищите более простые пути решения. ИМХО АОС для этих целей (подражание) подходит куда лучше, чем винда или линух.
Есть вообще готовое - Шаос либман. Бери, юзай! Развивай! Не изобретай велик!

[Advertiser]

[acidrain]

не на все из них получил ответы

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

При условии отсутствия ОС применимо только в плагинной системе...

аргументируй !

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

А если несколько ф-ций из одной либлы вызвать, при чем один вызов в либле 1, другой в либле2, затем 4, затем 1 - как быть в таком случае?

А тут налетел народ и давай расхваливать амигу (притом чисто на словах, безо всякой полезной для меня информации)

До этого ты писал, что спасибо за инфу, она так полезна. Теперь ты пишешь, что я ничче и не писал вовсе? И народу то сколько налетело амижного? Я и неизвестно откуда прошаренная йака_ини. А теперь посчитай скоко народу пцшного напало на меня?

[Vitamin]

но тут простите - цитату в студию! что ты спрашивал?

По поводу таблиц релокации. Мне интересно знать их устройство. Есть доки? В исходниках ковыряться ресурсоемко

аргументируй !

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

А если несколько ф-ций из одной либлы вызвать, при чем один вызов в либле 1, другой в либле2, затем 4, затем 1 - как быть в таком случае?

Если имена либ неизвестны на этапе компиляции, то открываем необходимое число библиотек, достаем из них указатели на функции и вызываем по этим указателям нужное число раз. Если имена известны, то этими всеми операциями (открытие-получение адреса-закрытие) обычно заведует ОС

[captain cobalt]

Итак, попробуем сформулировать основные принципы амижной реализации:

1. Импорт по номеру (ординалу) функции.
2. Использование dynamic binding вместо dynamic linking.

Недостаток первого пункта - отсутствие возможности контроля целостности во время загрузки.

Второй пункт означает что библиотеку можно рассматривать как ООП класс (и объект singleton) и функции вызываются как "виртуальные функции". Недостаток - перерасход ресурсов во время выполнения. Даже на Мотороле, где косвеный вызов по таблице адресов делается одной командой, необходим регистр (весьма ценный ресурс). А если надо будет вперемешку вызывать функции из разных библиотек? На Z80 понадобится гораздо больше машинных команд только для того, чтобы передать управление в библиотеку, и, в зависимости от реализации, некоторые регистры могут оказаться недоступными для передачи аргументов. При таком раскладе, считаю, рассказы о "каматозе динамической компоновки" мoжно отбросить.

Ах вот оно что! Винда наоборот

В этом аспекте считаю подход Амиги (и Линукса) более правильным.
Так называемые "thread-safe libraries".

а теперь IMHO: динамические библиотеки нужны в основном для системных программ, на спекки ими пользоваться будет не сильно удобно поскольку мы завязаны на floppy-ки.

Именно потому, что завязаны на floppy, динамическая компоновка может помочь.
Чем больше времени мы сможем хранить библиотеки в памяти и прикомпоновывать их к разным программам, тем больше ресурсов floppy может быть сэкономлено.

[yoko_ono]

По поводу таблиц релокации. Мне интересно знать их устройство. Есть доки? В исходниках ковыряться ресурсоемко

Cовершенно примитивное. Каждый 'exe' - после загрузки в память представляет из себя некоторое кол-во секций, с кодами, с данными и т.д. Если в секции есть абсолютные адреса со ссылками на к.-л. секцию - то в самом файле ставится относительное смещение от начала этой секции, а в таблице релокации для данной секции - смещение до адреса, который надо подкорректировать и номер секции, в которую он должен указывать. Плюс вариации с 16-32 битными смещениями. Вот и всё.