Дополнительные идеи:
1. Добавить в модуль директивы выравнивания, чтобы он загружался например по адресу кратному 256.
2. Пропатчивать не только непосредственными значениями, но и значениями, преобразованными по формуле. Формулы записывать в объектный файл модуля в обратной польской записи.
2fk0. не буду тянуть баян с цитатами-ответами, влом. GriV можно сказать выразил витавшие в моем котелки мысли.
ишшо одна мысля возникла. значица стоит у нас такая глобальная цель- сляпать модульную структуру, каждый модуль внутри имеет таблицу, которая заменяет/пришпиливается к основной таблице точек входа.
вопрос нумбер адын: модуль релоцируемый? если нет, то идея не стоит ломаного яйца или выеденного гроша (кому как нравится %)) если релоцируемый, то см. выше.
вопрос нумбер два: а в какоме именно место будем пришпиливать/заменять таблицу виртуальных функций данного конкретного модуля?
может я чтото недопонял, но...
угу. п1. имхо можно решить, пожертвовав несколькими битами в конфигурационном байте (абсолютно без проблем). насчет п2. идея стоящая, но дело имхо немного упирается в сложность создания польской записи. если не ошибаюсь, в модулях для is-dos такое практиковалось. мож просветит кто, насколько успешно?Сообщение от captain cobalt
Проблема в том, что ты эту альтернативу выбираешь за других. В частности, за меня.
Я указал, где считаю место альтернативным методам -- что-то
очень специфическое по памяти (RST) или по-скорости (прямой CALL). Ибо и там и там имеет место экстремальная экономия
какого-либо одного ресурса в ущерб всем остальным. Я не считаю
такое решение приемлимым в общем случае. Вот и всё что я хочу
сказать. Я не отвергаю такие решения для тех самых экстремальных
случаев, я даже говорю, они могут существовать параллельно в рамках одного интерфейса, представимого тремя ортогональными
понятиями: собственно интерфейс, метод доступа к функциям интерфейса, и соглашения о совместом использовании аппаратных
ресурсов, передаче аргументов и т.п. Это просто разные вещи.
Один и тот же интерфейс может иметь совершенно разные свойства
по двум другим направлениям и это будет тот же самый интерфейс
в плане функциональности, но другой интерфейс в том смысле, что
может быть недоступен в какой-то программной среде. Впрочем
об этом нужно писать отдельно, для чего лучше вынести в отдельную тему: http://zx.pk.ru/showthread.php?t=1950
Объективной точки зрения не существует.таким образом и выстрадал все плюсы и минусы системы, потому считаю что имею достаточно объективную точку зрения.
Таблица JP работает неплохо, если речь идёт о прошивке ПЗУ.
Теперь предположим, что мы хотим использовать таблицы JP и для вновь разрабатываемых модулей, предназначенных для работы в ОЗУ. Тогда каждому модулю понадобится таблица JP на его процедуры. Мы не можем каждому модулю для его таблицы JP назначить адрес, который не будет менятся всю оставшуюся жизнь. Значит таблицы JP должны быть перемещаемыми. А если они должны быть перемещаемыми, то потребуется пропатчивать все CALL-ы в эти таблицы. А если понадобится пропатчивать CALL-ы, то зачем нужны эти таблицы?
Это всё ровно наоборот. В ПЗУ как раз плохо по ряду других
причин...
Ужас. Патчатся не CALL, а JP в самой таблицы. Суть в том, чтоТеперь предположим, что мы хотим использовать таблицы JP и для вновь разрабатываемых модулей, предназначенных для работы в ОЗУ. Тогда каждому модулю понадобится таблица JP на его процедуры. Мы не можем каждому модулю для его таблицы JP назначить адрес, который не будет менятся всю оставшуюся жизнь. Значит таблицы JP должны быть перемещаемыми. А если они должны быть перемещаемыми, то потребуется пропатчивать все CALL-ы в эти таблицы. А если понадобится пропатчивать CALL-ы, то зачем нужны эти таблицы?
сама программа статически скомпонована с этой таблицей,
на этапе компиляции. Её адрес известен точно также, как адрес
локально определённых, для данной программы, функций.
А пропатчить одну таблицу всяко проще, чем все CALL, тем более
что делается это одной инструкцией LDIR -- путём копирования
точно такой же ещё одной таблицы, но статически скомпонованной
с другой программой-библиотекой. Нужно лишь единожды перед
запуском знать адрес где таблица в библиотеке и скопировать её
поверх своей таблицы. Ну тут конечно возможны вариации, когда
например, локальная таблица меньше библиотечной (включены
только используемые функции) и копируются только адреса нужных
функций.
Вот именно. Адрес таблицы должен быть фиксированным.
Это не особо мешает, если таблица одна единственная.
Но что если таблиц две или больше?
Кто выбирает адреса для таблиц?
Что если независимые разработчики выберут пересекающиеся адреса?
Распределять адреса централизованно? Но это получится make world.
На оффтопиках действительно применяется этот способ. Таблица вместе с кодом лепится в одно целое. Но там команды CALL относительные, поэтому всегда показывают в таблицу независимо от того по какому адресу загрузили модуль. Но на Z80 нет относительных CALL, только короткие JR.
"Относительно меня или вас?" (Ц)
Он прекрасно фиксированный относительно каждой программы
с которой КОПИЯ данной таблицы скомпонована. Понимаешь,
КОПИЯ. Много их. Таблиц этих. Каждой программе -- своя. И ещё
одна на библиотеку, СВОЯ КОПИЯ. Поэтому её адрес известен,
как известен адрес любой процедуры в своей программе.
Ассемблер. При компиляции.Это не особо мешает, если таблица одна единственная.
Но что если таблиц две или больше?
Кто выбирает адреса для таблиц?
Тогда две программы не загрузить одновременно. Или двеЧто если независимые разработчики выберут пересекающиеся адреса?
библиотеки. Потому пишите релоцируемый код. И таблица
сама релоцируемой получится. КОПИЯ таблицы то-есть,
локальная. А потом, когда всё будет загружено, информация
из ГЛАВНОЙ ТАБЛИЦЫ, которая связана с программой функции
которой вызываются через эту таблицы, должна быть скорпирована
во ВТОРИЧНЫЕ ТАБЛИЦЫ, которые используются сторонними
программами для вызова функций из библиотеки или программы
с которой связана ГЛАВНАЯ ТАБЛИЦА. Что тут непонятного?
Я только что описал, как работает заменитель "относительных CALL". Именно это он и позволяет. Вызов по адресу известномуНа оффтопиках действительно применяется этот способ. Таблица вместе с кодом лепится в одно целое. Но там команды CALL относительные, поэтому всегда показывают в таблицу независимо от того по какому адресу загрузили модуль. Но на Z80 нет относительных CALL, только короткие JR.
относительно собственного программного модуля.
Это полный отстой и mustdie.
Только по одной этой причине такой способ - "ф топку".
А ещё при перекомпиляции библиотеки понадобиться перекомпилировать все зависимые программы.
make world
Тьфу.
Лишь ПЗУ это не касается. ПЗУ всегда по одному адресу. И таблицу ему можно сделать по фиксированному адресу.
Ну конечно.
Каждый раз, прежде чем делать CALL нужно вычислять адрес, по которому делать этот CALL.
Каковы накладные расходы на время выполнения этих вычислений и на память для хранения их кода?
Не превышают ли они расходов на единовременное пропатчивание?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием