вперед! я буду токо рад. место попистополить ничего более. пеши! детсадейбогу. семеро на одного накинулись...Цитата:
Сообщение от GriV
Вид для печати
вперед! я буду токо рад. место попистополить ничего более. пеши! детсадейбогу. семеро на одного накинулись...Цитата:
Сообщение от GriV
как прикажете на него отвечать? в чем вопрос?Цитата:
Сообщение от GriV
Команда прямого вызова подпрограммы быстрее косвенного с расходом регистров.Цитата:
Сообщение от acidrain
согласен. а сколько операций до этого прямого вызова? на спеке я имею ввиду?Цитата:
Сообщение от captain cobalt
Здравый смысл подсказывает, что если в двух модулях есть функции с одинаковыми сигнатурами, то эти модули склеить нельзя. В случае двух разных версий с 50% (если не больше) вероятностью так и будет. Если мы имеем возможность выдерать отдельные процедуры, то мы возьмем целиком более новую версию библиотеки и добавим туда используемые неконфликтующие процедуры из более старой версии.Цитата:
Сообщение от captain cobalt
Как это я видел бы на спеке я расписал в самом первом посте, а GriV описал еще раз по рабоче-крестьянски в середине ветки. А на свои _конкретные_ вопросы, сугубо технические и направленные на раскрытие мне глаз на все прелести амижного подхода, я ответа так и не получил. Вместо этого получил "а давайте забудем обо всем и представим, что пц не существует". Его ж тоже не дураки придумывали и под досом были объектные файлы и релокация.Цитата:
Сообщение от acidrain
Проще, насколько я понимаю- это грузить готовые кодовые скомпилированные блоки, прибитые гвоздями под конкретный адрес, зато в керналем в начале?Цитата:
Сообщение от acidrain
Каких именно операций? Операций динамического компоновщика или операций скомпонованной программы?Цитата:
Сообщение от acidrain
Для любого конкретного модуля время компоновки ограничено константой.
Сэкономленные же такты стремяться к бесконечности, если время работы скомпонованного кода стремиться к бесконечности.
За конечное время сэкономленные такты могут полностью покрыть первоначальные расходы.
1. Если один модуль хочет использовать функции другого, он обязан его подключить через функцию загрузки и юзать дальше через хендл?Цитата:
Сообщение от acidrain
2. Не сигналы (они же функции, по большому счету), а именно данные. Спрайты там, шрифты, тексты.
3. Не, я не про то. Внутри бинарного файла каким-то образам хранятся символические имена экспортируемых функций или голый код?
Журнал читаю. Интересно, красиво. Ты страницы указал пдфные или журнальные?
ЗЫ. Язвительно замечу, что интерфейс слизан с Mac'a ;) Так что не надо наезжать по поводу подражательства. Я еще про бинарники макинтоша поищу что есть и посмотрю еще там! :))))
1. даЦитата:
Сообщение от Vitamin
2. не могу представить как дос либрари потребуется графикс либрари. дело в том, что это не модули, а либрари, но называй их как угодно. как и прога, обмен через messages, signals, stack. только зачем?
3. бинарник - код.
ПДФные страницы.
Просто потому что ты мыслишь другими категориями. Что мы имеем в случае многозадачной ОС?Цитата:
Сообщение от acidrain
-разделяемые библиотеки
-реентерабельные функции внутри
-поскольку экземпляры кода библиотек формально принадлежат разным процессам, для общения используются спецметоды типа тех же сигналов и сообщений (которые, кстати скопированы из UNIX разных реинкарнаций, правда в упрощенном виде)
Что же мы имеем на спеке? Отсутствие ОС! А это дает некоторые преимущества (недостатки относятся к другой категории, указывать их не буду):
-библиотеку использует только один процесс
-функциям не обязательно быть реентерабельными
-общение между секциями программ осуществляется прямыми вызовами с передачей параметров.
Так что, например, берем мы гипотетический модуль под амигу и пытаемся его перетащить на спек в качестве некоего универсального формата хранения бинарных данных.
Перво-наперво отрезаем нахрен керналь- ну зачем внутри сплошного куска кода нужны лишние переходы? Ладно, данный подход еще оправдан для реализации плагинов, да и то, это еще поспорить можно.
Далее. На амиге совсем не требуется релоцирумый код. Флаг ей в руки, спектрум этим похвастать не может, поэтому придется как-то хранить информацию для настройки кода под конкретные адреса. Методов- куча.
Далее. Расширение функциональности осуществляется не только за счет экспорта/импорта функций, но и данных. Инкапсуляция это конечно хорошо, но надо чтоб и без нее можно было обойтись. Итого добавляем поддержку экспорта/импорта переменных и массивов.
И что мы в итоге получаем от исходного амижного модуля? Ни-че-го! Получается обычный объектный файл, поддерживающий релоцируемость, аналоги которого существуют на всех практически платформах.
маленький такой комментарий, объектные файлы с платформой вообще не связаны, это "фича" среды разработки (компилятор+линкер)Цитата:
Сообщение от Vitamin