опрос мнения

[fk0]

Имеет ли по вашему мнению смысл динамическая компоновка кода
в рамках платформу ZX-Spectrum:

1) очень важна и нужна в любом месте

2) имеет небольшой смысл в специфических задачах

3) может использоваться наравне со статической компоновкой

4) да этим вообще никто в трезвом уме не пользуется

[Advertiser]

[jtn]

4й вариант. кто там про вотку говорил?

[Sinus]

имеет смысл только в специфических случаях
ибо иногда без этого действительно туго.
однако во всех остальных 90% случаев нафиг не нужно.

[Vitamin]

3 пункт. обычно юзается подгрузка драйверов и плугинов - чем не динамическая ликовка?

[James DiGreze]

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

[fk0]

4й вариант. кто там про вотку говорил?

Программы для ZX-Spectrum в большинстве случаев используют статическую
компоновку программного кода. В большинстве случаев, но не всегда.
Рассмотрим варианты, когда статическая компоновка не применима:

* использование функций размещённых в ПЗУ -- это, фактически
динамическое объединение, компоновка, кода программы
с библиотекой, размещённой в ПЗУ;

* использование программ-драйверов, например драйвера НЖМД;

* использование программ-"плагинов", расширяющих
функциональность
основной программы;

* связь прикладной программы с функциями ОС.

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

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

В целом можно сказать, и тот и другой метод компоновки в настоящее
время используется и имеет важность. Отмести какой-либо один метод
в пользу другого невозможно.

[James DiGreze]

fk0, у Вас некорректное понимание динамической компоновки...
Само понятие "Динамическая компоновка" или "Dynamic Linking" подразумевает сборку библиотеки или программы после загрузки в память, перед исполнением. При этом перестраиваются все указатели на процедуры, в этом и заключается ДИНАМИКА. А использование функций ПЗУ как раз статическая компоновка, так как ПЗУ не линкуется в принципе И все его процедуры находятся всегда ПО СТАТИЧЕСКИМ адресам.

А трудность реализации настоящей динамической компоновки связана с ограниченными ресурсами спека, так как сборку должен производить некий менеджер загрузки, после чего, по требованию программы пользователя, ПО ИМЕНИ, вызвать нужную процедуру, независимо от того, куда он эту процедуру отлинковал...

Ну и ОСь нужна, которая будет рулить ресурсами... Без ОСи эта задачка не решаема...

[fk0]

fk0, у Вас некорректное понимание динамической компоновки...
Само понятие "Динамическая компоновка" или "Dynamic Linking" подразумевает сборку библиотеки или программы после загрузки в память, перед исполнением. При этом перестраиваются все указатели на процедуры, в этом и заключается ДИНАМИКА. А использование функций ПЗУ как раз статическая компоновка, так как ПЗУ не линкуется в принципе И все его процедуры находятся всегда ПО СТАТИЧЕСКИМ адресам.

А вот и нет. Все процедуры КОНКРЕТНОЙ ВЕРСИИ программ ПЗУ
накодятся по конкретным статическим адресам. А адреса процедур
каких-либо программ, размещённых в ПЗУ, в общем случае НЕИЗВЕСТНЫ, ибо склонны меняються от раза к разу.

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

И кроме того, процесс установки новой микросхемы ПЗУ в панельку,
с новой версией программ -- это тоже, в какой-то мере, "загрузка".

А трудность реализации настоящей динамической компоновки связана с ограниченными ресурсами спека, так как сборку должен
производить некий менеджер загрузки, после чего, по требованию программы пользователя, ПО ИМЕНИ, вызвать нужную процедуру, независимо от того, куда он эту процедуру отлинковал...

Во-первых связи логической не вижу. Как наличие менеджера
связано с ограниченными ресурсами спека.

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

Ну и ОСь нужна, которая будет рулить ресурсами... Без ОСи эта задачка не решаема...

Ну да конечно. И к ней мышку с окошками. И чтоб Open-GL обязательно. А то без Tuxrace и Quake-III ничего и никуда не пойдёт...

[James DiGreze]

А адреса процедур каких-либо программ, размещённых в ПЗУ, в общем случае НЕИЗВЕСТНЫ, ибо склонны меняються от раза к разу.

Согласен, это хороший пример, но он затрагивает лишь частный случай использования той части ПЗУ, которая относится к TR-DOS, и я бы не брал его за правило...

Во-первых связи логической не вижу. Как наличие менеджера связано с ограниченными ресурсами спека.

Из личной практики реализации менеджеров... Там не все так просто. Даже можно сказать, что очень не просто...
Немного отвлекусь, чтобы было понятнее. Вы, лично, видели на Спектруме линковщик? Я видел... В IS-DOS... Более ни где А знаете почему их нет, как таковых? Потому, как ВСЕГДА используется модель памяти "FLAT". Для которой, использование линковщика - лишняя трата ресурсов машины.
Но вернемся к менеджеру. Динамическое выделение памяти, в частности для загрузки библа, должно выглядеть примерно так:
1) прог (менеджер динамической компоновки) обращается к менеджеру памяти: "Браток, нужно бы памяти кусочек в 123 байта!"
2) менеджер памяти должен определиться, а есть ли столько ресурсов??
3а) если ресурсов нету, то ответ будет примерно: "Иди-ка ты на... маршрут по-умолчанию"...
3б) если 123 байта имеется, он должен их "откусить" от свободного пространства, выделить этому куску уникальный ID, прописать в своих табличках, что для этого ID зарезервирован кусочек в 123 байта, в такой-то банке, по такому-то адресу, и выдать ID на выходе...
Потом, линковщик, чтобы обратиться к этому участку, обязан обратиться к менеджеру оперативки, типа "дай-ка я с этим кусочком поработаю...".
А таких вызовов, при линковке будет... ну, достаточно много...

Я может быть и усложняю... Но ТАК ПРАВИЛЬНО! в общем случае... все остальное будет частным случаем общего.

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

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

Ну да конечно. И к ней мышку с окошками. И чтоб Open-GL обязательно. А то без Tuxrace и Quake-III ничего и никуда не пойдёт...

Этого добра навалом...

P.S. Не нужно пытаться создать аналог большого брата! Спектрум жив до сих пор только благодаря тому, что каждый может писать "что хочет", и самое главное - "КАК ХОЧЕТ". Попытки загнать всех под IS-DOS еще в 95-м ни к чему хорошему не привели... Ибо это общий случай, а под частные, ресурсов не хватило... А еще Спек - машина для хобби. И должна приносить радость, а не страдание.

[GriV]

Вообще то я ответил что динамическая компоновка всегда нужна и вот почему.

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

Без динамической компоновки и настройки по адресам в ОС будет очень сложно работать с ресурсами памяти - её просто будет постоянно не хватать (как впрочем и всех остальных ресурсов).