Цитата:
Сообщение от Vitamin
есть все. и функциональность и проблемы.
Я уже писал: невозможно динамическое создание функции-фильтра, что убивает на корню идею трассировки
вызовов. STS не показывает метки. Вообще ничего
на ходу менять нельзя. Загрузить другую библиотеку (драйвер) --
нельзя. Там если глубже копнуть, чего только не вылезет.
Да, как замена CALL-у -- оно хорошо. Но речь не про CALL, речь
про механизм вызова библиотечных функций. И о том,
какими свойствами данный механизм (не) обладает.
Цитата:
хе. а то что компилятор генерит код под жестко зашитый адрес есть зер гут? или там тоже релоцируемая структура?
Есть компиляторы не умеющие генерировать позиционно-независимый (перемещаемый, настраиваемый при загрузке) код. Есть компиляторы не умеющие такой код генерировать.
Есть ассемблеры не поддерживающие возможность создания информации необходимой для перенастройки кода на адрес. Наконец ест просто программы подразумевающие абсолютный адрес загрузки
(99.9% на спектруме).
Цитата:
тогда в чем проблема? это просто одна из реализаций, демонстрирующая применение идеи, формат достаточно сырой, но работающий.
В том, что оно теоретически может работать никто не сомневается.
Никто даже не говорит, что это плохо по каким-то причинам связанным с практической реализацей. Никто не говорит даже, что
это плохая замена для CALL -- может и хорошая. Я говорю, это
плохой интерфейс. Потому, что это всего-лишь настраиваемый
CALL. С ним неудобно работать в динамике. Его неудобно отлаживать. Его, наконец, нельзя запускать непосредственно из ПЗУ -- просто потому, что настройки потребует весь код, а не малая
интерфейсная часть, которая может быть размещена в ОЗУ, в малом его объёме (речь пока не идёт про практическое использование тех или иных решений).
Цитата:
если бы его не было, все бы говорили "харэ трепаться, давай код работающий!". даешь код- идет кривление лицевого интерфейса %)))
Увы, это так. Тут нужна большая и серьёзная "теоретическая" работа. Код писать дело нехитрое, обезьянья работа в сущности.
Других дел в жизни хватает. И писать код в мусорную корзину
тем более мало кому захочется.
Цитата:
с существующим в смысле в исходниках или в бинарниках? в первом случае проблема решается контекстным поиском и заменой по тексту или написанием спецверсии компилятора (на крайняк). а второй случай- клиника... там даже таблица jp xx не поможет...
(речь про интеграцию существующего кода в систему)
На счёт поиска и замены я не уверен. Я даже считаю, невозможно абсолютно любой код под твои макросы адаптировать. "Релокатор"
наверняка не все выражения ассемблера поддерживает. В противном
случае мы придём к компиляции перед выполнением.
Я конечно же имел ввиду двоичный код. JP xxxx только и остаётся,
если обернуть его в этот интерфейс.
Цитата:
при компиляции... например юзаем старую версию системы, а программу компилируем с использованием новых заголовочных файлов. вариант с jp выдает красочный глюк на весь экран, а
А мы возьмём и на шнуре от модема повесимся. И от этого умрём. Поэтому модемы -- абсолютное зло. Аргументация того же уровня.
Для невнимательных: ИНТЕРФЕЙС НЕ МЕНЯЕТСЯ, ТОЛЬКО НАСЛЕДУЕТСЯ. Или, как вариант, имеется обязательный базовый
интерфейс позволяющий на ходу получать информацию об используемом интерфейсе и, как вариант, переключать разные
версии интерфейсов. В целом верно одно: всегда доступен
базовый интерфейс. Через который можно выявить используемый
интерфейс и возможную несовместимость. Это возможно на этапе
"настройки" программы.
Цитата:
настройщик просто грязно матерится на несуществующие функции и нифига не запускает
Вариант с JP xxxx тоже, как ни странно, требует настройки.
Ещё раз: массив JP xxxx таскается по раздельности В КАЖДОЙ
ЗАГРУЖАЕМОЙ ПРОГРАММЕ. При загрузке обновляется из массива
JP xxxx доступного в библиотеке. Почему так: потому, что адреса
в конкретных командах CALL и JP адресуют именно свой "локальный"
массив, потому что именно его адрес известн в момент компиляции,
а адрес загрузки библиотеки -- неизвестен. В качестве оптимизации,
при размещении библиотеки по фиксированному адресу в ПЗУ предлагается прямая адресация массива JP xxxx размещённого по
известному адресу в ПЗУ. Но такой способ адресации является
НЕЖЕЛАТЕЛЬНЫМ, потому, что ограничивает возможности использования интерфейса в части фильтрации, трассировки и т.п.
И в таком случае, поскольку настройка становится "ненужной" дейстивтельно есть возможность напороться на проблему. Но против этого, как и при действительной настройке, достаточно лишь вызвав соответствующую функцию БАЗОВОГО ИНТЕРФЕЙСА, ГАРАНТИРОВАННО ИМЕЮЩУЮСЯ В ИНТЕРФЕЙСЕ, можно выяснить насколько имеющаяся библиотека совместима с требуемой.
Цитата:
смешанная система. символьные имена применяются для компиляции и статической линковки. в итоговом модуле не должно быть символных имен вообще (хотя GriV ратует за них, грит это того стоит.... а мне памяти жалко для такого безобразия %)))
Мне тоже было бы жалко. Потому как практического смысла не
имеет. Лучше решить проблему идентификации интерфейсов. И кроме того, символьные имена уровня ассемблера -- как их сделать доступными на уровне кода? Опять же серьёзные ограничения технического плана. ALASM может и умеет, а GENS опять нет. Или ZASM скажем -- не умеет.
Цитата:
енто просто не самый лучший пример имхо, так конечно никто делать не будет. имеются ввиду вообще процедуры из пзу. там довольно много фрагментов разных можно использовать.
Речь про библиотеку функций с ЧЁТКО ОПРЕДЕЛЁННЫМ ИНТЕРФЕЙСОМ, или про несвязный набор фрагментов кода?
Цитата:
имеются в виду накладные расходы на вызов процедуры. умноженные на количество фактических вызовов...
Вот имеется функция ожидания нажатия на кнопку. Хрен ли толку, если ты на ней 10 тактов сэкономишь? Если для тебя действительно
критична скорость: импортируй тескст (ассемблерный) функций и
откажись от библитечных. Ибо 27 тактов на CALL и RET сверх того --
тоже не мало. Экономить 10 тактов, чтоб тут же отдать 27 (на итерацию) -- вот этого я не понимаю. И не хочу понимать. Это бред.
Кроме того, итеративные функции стоило бы переписать, чтоб цикл
перенести в библиотеку. Условие окончания цикла можно определить функцией, указатель на которую передаётся аргументом при вызове библиотечной функции -- вот где экономия.
Цитата:
Воистину!!! Знать три варианта расписали (GriV сие сделал вполне квалифицированно). Каждый может выбирать что ему выгодно. если точек входа не так много, то и таблица jp xxx сойдет, а если там развесистая клюква на 1000 с хреном вызовов, то можно и потратить сотню байт на настройщик, сэкономив килобайт на таблице
Если там клюква на 1000 вызовов, по 50 байт на вызов -- займёт
всю память и ничего не останется... Для клюквы нужны свои, специфические решения.
Речь про что-то более общее. Где вызов занимает сотни-тысячи, реже десятки тысяч тактов и десятки, реже сотни байт. Где общее число вызовов на модуль -- порядка единиц-десятков. Пример?
"Драйвер" модема, CMOS, HDD, CDROM... Модуль арифметики с
плавающей запятой (откуда там сотни вызовов? Столько функций
не наберётся). Библиотека строковых функций. Библиотека
поточного (побайтового) ввода-вывода для TR-DOS. Упаковщих
HRUST. Текстовая консоль, драйвер "мыши" со стрелочкой, примитивный (максимум уровня ZXASM) "GUI" интерфейс. Может быть в последнем случае можно превысить предел в 100 вызовов. В таком случае, интерфейс можно разбить на 2-3 части (предел -- 85 виртуальных функций на объект).
