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

[acidrain]

Если вы будете продолжать таким образом, я пожалуюсь модераторам

вперед! я буду токо рад. место попистополить ничего более. пеши! детсадейбогу. семеро на одного накинулись...

[acidrain]

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

как прикажете на него отвечать? в чем вопрос?

[captain cobalt]

Досей чтоли? Небыло доказательств - только голословные.

Команда прямого вызова подпрограммы быстрее косвенного с расходом регистров.

[acidrain]

Команда прямого вызова подпрограммы быстрее косвенного с расходом регистров.

согласен. а сколько операций до этого прямого вызова? на спеке я имею ввиду?

[Vitamin]

А когда одна версия C, можно ли если граф импорта имеет склеенные ветки, собрать результат с одним экземпляром C?
А, Vitamin?

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

Вопросы от витамина - он не читает, что ему пишут. упорно продолжает твердить. а в посте http://zx.pk.ru/showpost.php?p=61553&postcount=229 я написал, что отойдем от пц и амиги. вынес предположение о том, как я понял витамина и как хотел бы это видеть на спеке.

Как это я видел бы на спеке я расписал в самом первом посте, а GriV описал еще раз по рабоче-крестьянски в середине ветки. А на свои _конкретные_ вопросы, сугубо технические и направленные на раскрытие мне глаз на все прелести амижного подхода, я ответа так и не получил. Вместо этого получил "а давайте забудем обо всем и представим, что пц не существует". Его ж тоже не дураки придумывали и под досом были объектные файлы и релокация.

Там сказанно, что зачем динамические компоновщики, когда можно проще.

Проще, насколько я понимаю- это грузить готовые кодовые скомпилированные блоки, прибитые гвоздями под конкретный адрес, зато в керналем в начале?

[captain cobalt]

согласен. а сколько операций до этого прямого вызова? на спеке я имею ввиду?

Каких именно операций? Операций динамического компоновщика или операций скомпонованной программы?

Для любого конкретного модуля время компоновки ограничено константой.

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

За конечное время сэкономленные такты могут полностью покрыть первоначальные расходы.

[Advertiser]

[Vitamin]

1 - модуль? какой экспорт? куда?
2 - куда? если ты про сигналы и сообщения то запросто. http://www.totalamiga.org/pdf/totalamiga_18.pdf страницы 24-26 немного затрагивают сей вопрос.
3 - только супер прошаренные программеры типа Stingray могут помнить все входы либл по смещениям. А все остальные (я в т.ч.) пользуются инклудами, хеадерами. См. также архив. он не полный. думаю больше не надо. разумный человек поймет что к чему. Это инклуды для асма. для си не шлю - не особо разнятся.

1. Если один модуль хочет использовать функции другого, он обязан его подключить через функцию загрузки и юзать дальше через хендл?
2. Не сигналы (они же функции, по большому счету), а именно данные. Спрайты там, шрифты, тексты.
3. Не, я не про то. Внутри бинарного файла каким-то образам хранятся символические имена экспортируемых функций или голый код?
Журнал читаю. Интересно, красиво. Ты страницы указал пдфные или журнальные?

ЗЫ. Язвительно замечу, что интерфейс слизан с Mac'a Так что не надо наезжать по поводу подражательства. Я еще про бинарники макинтоша поищу что есть и посмотрю еще там! )))

[acidrain]

1. Если один модуль хочет использовать функции другого, он обязан его подключить через функцию загрузки и юзать дальше через хендл?
2. Не сигналы (они же функции, по большому счету), а именно данные. Спрайты там, шрифты, тексты.
3. Не, я не про то. Внутри бинарного файла каким-то образам хранятся символические имена экспортируемых функций или голый код?
Журнал читаю. Интересно, красиво. Ты страницы указал пдфные или журнальные?

1. да
2. не могу представить как дос либрари потребуется графикс либрари. дело в том, что это не модули, а либрари, но называй их как угодно. как и прога, обмен через messages, signals, stack. только зачем?
3. бинарник - код.
ПДФные страницы.

[Vitamin]

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

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

Что же мы имеем на спеке? Отсутствие ОС! А это дает некоторые преимущества (недостатки относятся к другой категории, указывать их не буду):
-библиотеку использует только один процесс
-функциям не обязательно быть реентерабельными
-общение между секциями программ осуществляется прямыми вызовами с передачей параметров.

Так что, например, берем мы гипотетический модуль под амигу и пытаемся его перетащить на спек в качестве некоего универсального формата хранения бинарных данных.
Перво-наперво отрезаем нахрен керналь- ну зачем внутри сплошного куска кода нужны лишние переходы? Ладно, данный подход еще оправдан для реализации плагинов, да и то, это еще поспорить можно.
Далее. На амиге совсем не требуется релоцирумый код. Флаг ей в руки, спектрум этим похвастать не может, поэтому придется как-то хранить информацию для настройки кода под конкретные адреса. Методов- куча.
Далее. Расширение функциональности осуществляется не только за счет экспорта/импорта функций, но и данных. Инкапсуляция это конечно хорошо, но надо чтоб и без нее можно было обойтись. Итого добавляем поддержку экспорта/импорта переменных и массивов.

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

[elf/2]

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

маленький такой комментарий, объектные файлы с платформой вообще не связаны, это "фича" среды разработки (компилятор+линкер)