Цитата Сообщение от jdigreze
Согласен, это хороший пример, но он затрагивает лишь частный случай использования той части ПЗУ, которая относится к 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... Но, перед тем, как запустить процедуру, нужно выставить конфигурацию машины, банки там, и прочее...
Он не должен, а может быть и прямым, и косвенным, я уже писал...