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

[captain cobalt]

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

Ещё уточнения:

Смещения (в таблице адресов) вкомпилируются в бинарник и вообще недоступны загрузчику.

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

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

Это поддерживаю на 100%
______________________

А вот ещё одна идея.

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

[captain cobalt]

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

Как называется корректировка секций по таблицам релокаций?

[Vitamin]

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

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

Заархивировать программы в непрерывный RAR архив.
Непрерывная архивация сожмёт одинаковый код в разных программах.

Про это я говорил уже, можно даже не сжимать, а просто в один файл сложить все либы дабы не шариться по диску при сборке.

Это поддерживаю на 100%

Ну вот. Лишний раз убеждаюсь, что в споре часто рождается истина (по крайней мере, для меня). Сколько мы с тобой дискутировали на тему ОС? Я много чего почерпнул для себя. Здесь несколько похуже, но думаю ситуация исправится.

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

[elf/2]

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

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

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

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

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

[elf/2]

вообще еще раз мое imho. динамическая компоновка (т.е. dll/so/exec.library) на текущем этапе на спекке на нужна, потому что:
1. оси нет, значить компоновщик придется добавлять СТАТИЧЕСКИ в каждую программу
2. даже если мы используем только одну функу из библиотеки в памяти будет висеть вся либа
!!! а памяти у нас не густо
3. поскольку библиотеки фактически ищутся по имени файла, загрузка всего приложения будет идти очень долго (придется каждый раз мотаться в каталог и обратно). если каталог кешировать для ускорения, то опять упираемся в память...
4. как правильно подметил psndcj реально нужны 2-3 библиотеки, стоит ли из-за этого огород городить?
5. у нас нет многозадачности, соответсвенно использования одной библиотеки несколькими приложениями не будет, следовательно экономии памяти от использования одного кода несколько раз тоже не будет

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

[ng_dead]

мое imho

+1

[acidrain]

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

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

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

Ну, я тебе вчера о том же намылил - загрузчик открывает и закрывает либлы.

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

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

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

Все верно! Я поражен Вами, жаль женат и две дочки, а тоб ))
но Витамин спрашивал о libman либах а не об амиге!
2Витамин:Предполагаю, что все в либмане с релокацией просто, как то изучал исходники на Срр (они там в архивах, есть даже .ехе для авто реклокации или что то типа того - не помню 4 года прошло)
И еще, все вопросы по либману - к автору: Shaos, пиши на мыло, в его форум, аську - не спрашивай меня об этом, ок?
И не выдумывай, повторюсь, велосипед - либман - готовый, проработанный формат и легко автором портируется на спек - пользуйся тем, что уже готово! А так, если жаждишь славы - то дерзай.
Могу выслать мою первую либлу (если найду - на листочках хранил), которую я писал для спека и системы, как я описал выше. Тама мышко-драйвер типа

[acidrain]

Даже на Мотороле, где косвеный вызов по таблице адресов делается одной командой, необходим регистр (весьма ценный ресурс)

Можешь регистром пользоваться, как заблагорасудится! =) Никто не запрещает его юзать - он не постоянно нужен, только при обращении к либле. Остальное время можешь про него забыть и юзать постоянно, до следующегно вызова. Система такова, что берешь хендл либлы в регистр, а по возвращению - он опять твой. Как и любой другой регистр, необходимый для передачи данных в либлу.
Надеюсь понятно изъяснил. Такчто не ресурсоемкий метод!

[acidrain]

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

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

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

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

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

[acidrain]

4. как правильно подметил psndcj реально нужны 2-3 библиотеки, стоит ли из-за этого огород городить?

Стоит - это начало из начал ... для оси