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

[acidrain]

Потому как, если нет указателя на функцию или ее адреса (разные вещи), то функцию вызвать невозможно!

Нет, ты упорно не хочешь слышать, что тебе говорят! Нету никаких указателей на функции! Есть только хендл либлы и все! Ведь прежде чем вызвать ф-цию ты ведь должен знать, что она делает? Значит ты знаешь, в какой либле ее искать? То тогда ЗАЧЕМ тебе адрес или указатель на ф-цию?

[acidrain]

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

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

[Shaos]

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

Только функции - доступ к данным через функции. Каждый экземпляр библиотеки будет иметь свои данные и свой код. Никаких внешних точек. Релоцируемая либа компилируется так - компилим с адреса #0000, потом компилим с адреса #0100 и побайтно сравниваем что получилось - если соответствующие байты в двух результатах компиляции отличаются, то пишем в соответствующий бит 1, иначе 0. Подобный фокус с релокацией прокатывает только если адреса указываются прымым текстом и не вычисляются хитрыми формулами. И соответсвенно не может быть никакой самомодификации кода либы с исправлениями адресов переходов.

[elf/2]

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

по крайней мере более гибкий если либа обязательная, то пусть система сама все делает, если не обязательная - то пользуемся загрузкой через LoadLibrary

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

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

видимо я не совсем понял Ваш исходный комментарий, мне показалось что Вы интересовались необходимостью всей конструкции (load, получить адрес, высвать, close). действительно необходимо получить адрес каждой используемой функции. или воспользоваться выше описанным подходом (используется например в Mirande)

Ну на мой скромный взгляд, оригинальности тут на грош

имел в виду: оригинальный = предложенный в первом посте темы

Нет, ты упорно не хочешь слышать, что тебе говорят! Нету никаких указателей на функции! Есть только хендл либлы и все! Ведь прежде чем вызвать ф-цию ты ведь должен знать, что она делает? Значит ты знаешь, в какой либле ее искать? То тогда ЗАЧЕМ тебе адрес или указатель на ф-цию?

ну что вы опять? вы оба правы:
1. не зная адреса - нельзя вызвать функцию напрямую
2. на амми ее напрямую никто и не зовет

[captain cobalt]

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

Взять статически скомпонованные программы.
В каждой программе может быть свой экземпляр библиотеки.

Сжать эти программы.
Непрерывное сжатие сожмёт дубликаты библиотек внутри программ.

+1

-1

оси нет, значить компоновщик придется добавлять СТАТИЧЕСКИ в каждую программу

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

ООП позволяет разбивать систему на подсистемы по абстракциям, а не по функциональности.

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

Загрузить хэндл в регистр - машинная команда и расход ресурсов.

таблица релокации занимает 1/8 размера кода

Много.

Вызов функций библиотеки производится с помощью подпрограммы L_CALL.
Эта подпрограмма самостоятельно подключает необходимый код в нужное
окно (программист должен корректно указать его при загрузке
библиотеки, чтобы не закрыть открываемой страницей кода
менеджера, данных, стека), передает управление на код
соответствующей функции библиотеки, а затем возвращает обратно ту
страницу, которая была там до вызова функции библиотеки.
Перед вызовом в HL устанавливается идентификатор библиотеки, а в
регистре B - функция библиотеки, которую нужно вызвать. Регистр C
- зарезервирован на будущее:

ld hl,(handle)
ld b,function
call l_call
jp c,error

Об ошибке свидетельствует взведеный флаг переноса. Данные можно
передавать и получать в регистрах A,DE,IX,IY, а также через
второй набор регистров.

Другими словами, четыре регистра недоступны для передачи аргументов.
Каждый вызов - потенциальная махинация со страницами.

Довольно прямолинейная реализация подхода Амиги.
А практичность результата?

[elf/2]

оси нет, значить компоновщик придется добавлять СТАТИЧЕСКИ в каждую программу

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

ООП позволяет разбивать систему на подсистемы по абстракциям, а не по функциональности.

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

[Advertiser]

[elf/2]

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

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

кстати примерно так сделано на винде когда либа подгружается системой

только в качестве списка jmp'ов используется таблица импорта программы и ее заполняет система на основании списка экспортируемых функций либы

[Shaos]

Много.

Плюс RLE сжатие файла либы, которое съест все нули, если в коде небыло переходов. На самом деле 1/8 от объема кода это вовсе немного, если учесть что в замен мы получаем настоящую перемещаемость с шагом 256 байт.

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

Ну да - переключить страницу памяти это копейки времени. И всё работает. И пока никто не предложил что-то лучше

P.S. Кроме того этот формат либ поддержан в компиляторе языка Форт и в компиляторе языка Си (оба на Спринтере)

[captain cobalt]

не понял что ты имел в виду

Плохо.
Надо разбираться в ООП. Рекомендую книгу.

1. причем здесь ООП?

Попробуем разобраться.
Есть "процедурное программирование" и есть ООП.
В чём отличие?
Процедурное программирование - это явное использование функциональности процедур. Например, для вывода спрайта используется процедура вычисления адреса в видеопамяти. При этом точно известно, что от неё ожидать, у программиста имеется реализация этой процедуры.

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

Рассмотрим на примере виндовых DLL.

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

Теперь посмотрим на FAR с плагинами. FAR, очевидно, явно загружает их с помощью LoadLibrary. При этом разработчики FAR не знают, что реализовано в плагине. Они лишь надеются что это нечто полезное. Это неявное использование функциональности.

(забавное сочетание: явное использование функциональности - неявная загрузка DLL; неявное использование - явная загрузка)

При чём здесь всё это?

ИМХО о пяти пунктах насквозь пропитано духом процедурного программирования. "Чтобы был динамический компоновщик, нужно чтобы сначала была ось". Это не так. ООП даёт механизм преодоления. FAR запросто может использовать плагины, которых не существовало во время его написания.

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

2. какой еще вариант кроме добавления компоновщика в каждую программу возможен если у нас нет ОСи?

Пусть у нас нет ни оси, ни программ, ни библиотек, есть только динамический компоновщик. Теперь, подсовывая этому компоновщику модули, можно построить хоть ось, хоть программу. Всё что угодно.

[yoko_ono]

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

Господин Vitamin, по-моему, вы скатились в абсурд. Что-то мешает вам адекватно воспринимать написанное?

Мадам!

Ну уж простите, это просто грубо! Я вам никакая не 'мадам'! Обращайтесь так к французским потаскушкам!!!

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

А вы слышали про это на СПЕКТРУМЕ?

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

Вы не знакомы со всеми возможностями alasm? Сочувствую...

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

Ничто не мешает, но почему-то не пишут. Задумайтесь, почему.

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

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