Вызов функций через RST

[fk0]

Это полный отстой и mustdie.
Только по одной этой причине такой способ - "ф топку".
А ещё при перекомпиляции библиотеки понадобиться перекомпилировать все зависимые программы.
make world
Тьфу.

Ты это, текст не по-диагонали читай, да? Я же ясно сказал --
таблиц несколько и адрес у каждой свой, произвольный.
Он настраивается перед пуском.

Лишь ПЗУ это не касается. ПЗУ всегда по одному адресу. И таблицу ему можно сделать по фиксированному адресу.

Можно. Вопрос какую: собственную таблицу ПЗУшных программ -- да. Таблицу, используемыю загружаемыми программами -- тоже можно, но тогда возникает описываемая тобой проблема, именно поэтому так делать и нежелательно, и можно не делать, а пользоваться своей таблицей размещённой в ОЗУ. Которая по сути
дела является полной копией ПЗУшной с той лишь разницей,
что её адрес (той которая в ОЗУ) -- известен. НО ОН НЕ ФИКСИРОВАННЫЙ. Верней, не обязательно фиксированный,
если программа релоцируемая. Что тут непонятного?

Ну конечно.
Каждый раз, прежде чем делать CALL нужно вычислять адрес, по которому делать этот CALL.

Чушь. Для программ с абсолютным адресом загрузки просто
LDIR делается или иным способом копируется таблица из ПЗУ.
Адрес которой (ПЗУшной) тоже может быть не фиксированный.
Для релоцируемых программ, при их настройке на адрес запуска,
адрес собственной таблицы настраивается АВТОМАГИЧЕСКИ!
А адреса в этой таблице опять же копируются из ПЗУ.

Каковы накладные расходы на время выполнения этих вычислений и на память для хранения их кода?

Времени -- 10 тактов. Памяти 3*N, где Ni -- число "внешних" по отношению к загруженнной программе функций.

Не превышают ли они расходов на единовременное пропатчивание?

За бесконечный период времени -- превышают (oo*10 == oo).

[Advertiser]

[captain cobalt]

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

Ну хорошо.
Действительно, динамический компоновщик может это делать.

НЕ ФИКСИРОВАННЫЙ. Верней, не обязательно фиксированный, если программа релоцируемая. Что тут непонятного?

Понятие "программа релоцируемая" подразумевает пропатчивание адресов в CALL на локальную перемещаемую таблицу?

Времени -- 10 тактов. Памяти 3*N

А во время загрузки кроме LDIR?

[fk0]

Ну хорошо.
Понятие "программа релоцируемая" подразумевает пропатчивание адресов в CALL на локальную перемещаемую таблицу?

Да. И не только их. А любых ссылок к локальным меткам по
абсолютному адресу (в машинном коде). Потому и говорю --
получается автомагически, в том смысле что выделять CALL
функций конкретной библиотеки от CALL на любой другой
локальный адрес специальным образом не надо. Достаточно
сравнить две версии программы откомпилированные по
разным адресам.

А во время загрузки кроме LDIR?

Если в локальных таблицах ссылки на все функции -- достаточно
и LDIR. Если только ссылки на используемые -- ну тут несколько
по-сложней будет, но смысл такой-же, просто копироваться будут
конкретные кусочки таблицы.

[captain cobalt]

Теперь замечаем что:

1. Релоцируемость - это пропатчивание CALL относительно базы своего модуля
2. Динамическая компоновка - это пропатчивание CALL относительно базы другого модуля

Таким образом, если есть релоцируемость, то тем самым есть почти всё необходимое для нормальной динамической компоновки.
Не так ли?

[fk0]

Теперь замечаем что:

1. Релоцируемость - это пропатчивание CALL относительно базы своего модуля

Не только CALL, а абсолютны всех адресов.

2. Динамическая компоновка - это пропатчивание CALL относительно базы другого модуля

Любых адресов относящихся к импортируемому модулю.

Таким образом, если есть релоцируемость, то тем самым есть почти всё необходимое для нормальной динамической компоновки.
Не так ли?

Не так. Ибо [база своего модуля] != [база чужого модуля].
И чтобы знать чего патчить нужно к каждому адресу приделать
ярлык с указанием модуля к которому он относится. В настояшее
время ни один ассемблер такого не поддерживает.

[captain cobalt]

И чтобы знать чего патчить нужно к каждому адресу приделать ярлык с указанием модуля к которому он относится.

Осталось лишь преодолеть это затруднение для полного счастья.

В настояшее время ни один ассемблер такого не поддерживает.

Это действительно серьёзная проблема.
Решение только для одного ассемблера понравится далеко не всем.
Вероятно, проблему следует решать разработкой ассемблера, который сможет заменить все другие ассемблеры.

[fk0]

Осталось лишь преодолеть это затруднение для полного счастья.

Вот как его преодолеть, например, для ZXASM 3.00 ?

Решение только для одного ассемблера понравится далеко не всем.

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

Это сильно сказано. "РЕШЕНИЕ ТОЛЬКО ДЛЯ ОДНОГО АССЕМБЛЕРА..." -- следовательно разработка ОДНОГО АССЕМБЛЕРА
ничего не даст, это очевидно.

Я смотрю с другой стороны. За базовый метод можно взять вариант с JP xxx. Ибо из этой структуры легко извлекается информация
потребная для функционирования любого другого метода. Кому надо позарез как прямой вызов -- пусть как хочеть патчит свои вызовы любым методом, а адреса из таблички JP xxx может извлекать сразу.
Кому нужно именно RST #10 -- аналогично. Пиши свой код, адреса
бери из той же таблички. Патчить все программы по методу прямого
вызова -- невозможно. Использовать абсолютно везде RST -- тоже
невозможно. По чисто-программным ограничениям.

[GriV]

2fk0> на самом деле тут есть несколько подводных камней.

Я согласен, любое ускорение (в том числе и использование текущих средств разработки как ускорение процесса) несёт в себе отдачу по другим ресурсам - своего рода "плата" за скорость.
А теперь конкретней:

1. Внешняя память - её есть практически (!) сколько угодно
Пример: гибкие диски, жёсткий диск, компакт диск
1.а. Использование в методе модульных структур система использует эту память
1.б. Использование кернального метода не подразумевает перенос своего рода "нагрузки" на эту часть компьютера

2. Внутренняя память
Пример: ОЗУ
Спецификой является невозможность прямой адресации произвольной точки, только через страничный механизм доступа. Размер страницы - 16кб.
2.а. Модульная структура - программа занимает ровно столько сколько есть, и на строчкой больше
2.б. Каждый вызов в ОЗУ дополняется строчкой перехода по длинному адресу.

3. Релоцируемость
Понимается перенос программы уже скомпилированной в любой произвольный адрес
Пример: внутри программу переход во внутреннюю часть:
Сall Internal_label1
...
Internal_label1 ld a,1
...
Модификация метки внутри программы
ld a,5
ld (mem_label1+1)
...
mem_label ld h,0
...
3.а. Модульная система - как угодно и куда угодно - это её главный бонус
3.б. Кернальная система - не понял я как релокации настраиваются (если вообще есть такая возможность), точнее говоря я понял что это делается непросто

4. Вызов внешних п/п и модулей
Понимается организация таким образом чтобы загруженная п/п могла взаимодействовать с другими п/п, уже имеющимися в ПЗУ и ОЗУ.
Здесь принципиально нет разницы между 4.а. и 4.б. так что расписывать их не буду.


А теперь самое главное (своего рода закусь):

Те, кто писал ОСи под спекк сталкивались с проблемой нехватки ОЗУ - программа, написанная и откомпилированная не хотела занимать меньше 1ой страницы - т.е. сколько есть страница памяти - столько максимально (ну или почти столько) можно было загрузить приложений.
Это связано с тем, что трудно предсказать где должна закончиться одна программа (её код + служебные данные) и соответственно оттуда же начаться другая. Потому как правило обходились компиляцией под адрес #C000.
Т.е. если есть уже загруженная программа с адреса #c000 и длиной скажем #1AF0 то нужно чтобы следующая загружаемая п/а имела адрес компиляции #DAF0 - и никак не меньше, хотя больше адрес можно. А если в следующий раз программа будет иметь тот же стартовый адрес а длину уже #2AF0 - как быть?
В этом и кроется одна из причин возникновения т.н. динамической компиляции - неизвестно заранее куда должна быть загружена программа (базовый адрес).
Касательно систем записи программ.
Модульная система - теперь программ можно загрузить именно столько, сколько есть памяти, привязываясь к страничному принципу лишь ЧАСТИЧНО. Я думаю из указанного выше примера будет ясно почему.
Кернальный принцип - ровно там где были там и остались - т.е. на каждый процесс будет уходить по 1 странице памяти.

Теперь касательно экономии памяти - есть прямые выгоды и косвенные. Прямые я расписал в п.1., а косвенные вот они - в память можно будет запихать теперь исключительное количество процессов.

Сама ОСь может быть даже потимизирована (читай - обрезана) под 48 к машины и худо бедно на ней приложения в модульной структуре но будут запускаться. Касательно кернальной системы - больше 1го приложения загрузить не сможем (точней загрузим но не запустим, нет релокации).

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

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

[GriV]

2fk0> вообще говоря этот способ вызова п/п из других п/п сильно пересекается с другими элементами - ну я думаю понятно с какими конкретно - и является своего рода оптимумом для ОС на ZX.

Внутри п/п интерфейс передачи данных может использоваться любой - хоть Hitech-C хоть разработанный неизвестным негром из бобруйска - считаю что вопрос не принципиальный.