опрос мнения

[GriV]

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

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

[James DiGreze]

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

[fk0]

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

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

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

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

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

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

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

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

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

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

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

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