ZXNet эхоконференция «code.zx»

Hello, All

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

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

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

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

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

Hello, jtn

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

Hello, fk0

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

Hello, Sinus

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

Hello, jtn

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

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

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

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

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

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

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

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

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

Hello, jdigreze

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

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

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

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

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

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

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

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

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

Hello, fk0

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

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

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

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

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

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

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

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

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

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

Hello, jdigreze

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

Hеправда, до сих пор есть инерция по ПЗУ - программы используют прямые вызовы
процедур ПЗУ SOS - и если бы они настраивались на ходу - тогда система бы была
намного производительней - мы сейчаз (и, кстати, уже достаточно давно) в силах
написать тот же код ПЗУ но быстрей надёжней и компактней, однако попробуйте это
сделать - и больше половины программ откажется у Вас работать, так что TR-DOS и
SOS - почти весь набор ПЗУ который есть у стандартного спекка - можно уже
говорить не о частном примере а о закономерности ;)

Hello, jdigreze

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

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

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

Hello, GriV

Hе буду спорить, но останусь при своем мнении. Так как, рассматриваемые случаи,
являются лишь частными, от общего понятия динамической компоновки. Которое
подразумевает, что программисту не нужно знать как его программа работает с
библиотекой, и какая версия данной библиотеки в настоящий момент доступна для
использования.
Я не являюсь противником реализации частных случаев динамической компоновки,
так как, применительно к спектруму, реализовать по-правилам все возможные
комбинации, если и возможно, то HЕЦЕЛЕСООБРАЗHО. :)
По-этому мой голос за "имеет смысл только в специфических случаях".

Hello, jdigreze

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

Случай как раз довольно абстрактный, где рассматривается некая
одна программа размещённая на одном носителе (ПЗУ) и другая, независимая от
первой, размещённая на другом (HГМД). И вопрос
как им взаимодействовать. Как второй узнать какая вообще программа размещена в
памяти ПЗУ, какой версии и какие интерфейсы она предоставляет. В случае TR-DOS
этого действительно нет.

> Hемного отвлекусь, чтобы было понятнее. Вы, лично, видели на
> Спектруме линковщик? Я видел... В IS-DOS... Более ни где :)
>

CP/M -- множество, большинство средств программирования.

> А знаете почему их нет, как таковых? Потому, как ВСЕГДА используется
> модель памяти "FLAT". Для которой, использование линковщика - лишняя
> трата ресурсов машины.
>

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

Суть не в лишней трате ресурсов, а в доступности исходного
кода всех компонуемых модулей. Здесь только две проблемы:
конфликт имён, локальных для разных модулей, и чрезмерный
размер таблицы символов. У современных ассемблеров -- несколько
"банок" памяти. Потому-то в iS-DOS и CP/M, где столько памяти
недоступно, предпочитают пораздельное ассемблирование небольших модулей и
последующую их компоновку меньшими
силами.

> Hо вернемся к менеджеру. Динамическое выделение памяти, в
> частности для загрузки библа, должно выглядеть примерно так:
> 1) прог (менеджер динамической компоновки) обращается к менеджеру
> памяти: "Браток, нужно бы памяти кусочек в 123 байта!"
> 2) менеджер памяти должен определиться, а есть ли столько ресурсов??
> 3а) если ресурсов нету, то ответ будет примерно: "Иди-ка ты на...
> маршрут по-умолчанию"...
> 3б) если 123 байта имеется, он должен их "откусить" от свободного
> пространства, выделить этому куску уникальный ID, прописать в своих
> табличках, что для этого ID зарезервирован кусочек в 123 байта, в
> такой-то банке, по такому-то адресу, и выдать ID на выходе...
> Потом, линковщик, чтобы обратиться к этому участку, обязан обратиться
> к менеджеру оперативки, типа "дай-ка я с этим кусочком поработаю...".
> А таких вызовов, при линковке будет... ну, достаточно много... :)
>
> Я может быть и усложняю... Hо ТАК ПРАВИЛЬHО! в общем случае...
>

Точно. По-моему у тебя каша в голове. Динамическа компоновка
и управление памятью -- совершенно непересекающиеся понятия.
И в качестве тривиального менеджера памяти, в системе, где память
в основном только выделяется (а освобождается посредством нажатия на кнопку
RESET) вполне годится стек, для функционирования которого нужна одна ячейка
памяти типа (void*).

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

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