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

[axor]

Вот в инструкции JP xxxx номер вместо xxxx и записывается. Это когда
на диске. А когда в памяти номер меняется на адрес. Отдельно имеется
массив адресов -- индекс в массиве этот самый номер.

А почему нельзя сделать JP xxxx уже в ПЗУ, чтобы не патчить программу? Ведь если сделать их в самой программе, которая вызывает эти функции, то для этого нужно будет опять же создавать и хранить таблицы этих JP xxxx, а потом патчить. А если сразу разместить JP xxxx в ПЗУ, то для этого понадобится на байт больше, чем обычно.

Хотя кто его знает, какую память нужно сразу экономить ПЗУ или ОЗУ...

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

[Advertiser]

[fk0]

А почему нельзя сделать JP xxxx уже в ПЗУ, чтобы не патчить программу?

В том-то и суть, что этот код обязан быть в программе. Именно для
того чтобы патчить. Именно в расчёте на то, что изначально программа не знает адресов функций которые собирается вызывать.

Ведь если сделать их в самой программе, которая вызывает эти функции, то для этого нужно будет опять же создавать и хранить таблицы этих JP xxxx,

Таблицы этих JP создаются очень просто и один раз в текстовом редакторе. Каждой "внешней" функции присваивается номер. Делает это автор тоже "внешней" библиотеки, программы или прошивки ПЗУ.
Для использования другими людьми он выпускает специальный файлик для включения в ассемблер:

имя_функции_1:
        jp номер_функции_1
имя_функции_2:
        jp номер_функции_2
        ...
имя_функции_N:
        jp номер_функции_N

Таким образом, на уровне исходного текста программист использующий библиотеку (прошивку) работает с именами функций.
На уровне машинного кода -- с обёрткой содержащей действительный адрес и создаваемой в ходе загрузки программы. А на уровне интерфейса -- это самое важное -- с номерами функций.

Что важно: если действительные адреса функций меняются в библиотеке (прошивке) -- это ни на что не влияет, так как
номер функции не изменяется. Вот его уже менять нельзя.

а потом патчить. А если сразу разместить JP xxxx в ПЗУ, то для этого понадобится на байт больше, чем обычно.

Размещать JP xxx в ПЗУ смысл есть. По фиксированному адресу,
разумеется. Тогда мы тоже дело имеем с номерами и одновременно
с адресами функций. Для ПЗУ такой метод годится. Для ОЗУ, где
библиотека каждый раз, в зависимости от наличия свободной памяти,
может загружаться в разные адреса -- нет, такой метод не приходен.

Надо сказать, размещение массива JP xxxx в ОЗУ имеет ещё одно преимущество. Возможность включения функций-фильтров на входе и выходе системных (библиотечных) функций (путём замены xxxx на собственную функцию-обёртку) Для отладки и т.п. может быть полезно. Например, можно запротоколировать вызовы всех системных функций.

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

И ещё одно. Если массив JP xxxx размещается в ОЗУ это даёт
то преимущество, что размер массива определяется только
количеством вызываемых функций, а не количеством
функций всего:

        ifused function
function:
        jp function_number
        endif
        ...

С другой стороны, в ПЗУ в любом случае должны
размещаться адреса всех функций. То-есть в варианте
массив адресов функций (2*N) плюс массив JP xxx в ОЗУ (3*m)
против массива JP xxxx в ПЗУ (3*N) выигрывает размещение
массива JP xxxx в ПЗУ (3*N) при m>N/3 , где N -- общее число функций, а m -- число вызываемых функций (используемых
загруженной программой).

[acidrain]

Для любой прошивки ПЗУ, функциями которой можно будет пользоваться не меняя номеров устоявшихся функций от версии к версии.

Эт я понял, а прошивка какая? 48бейсик? =) Или что свое?

[axor]

Эт я понял, а прошивка какая? 48бейсик? =) Или что свое?

Секрет...

[fk0]

Посмотрите нижепредложенный вариант вызова каких-либо функций через RST без использования регистров.
Задачи две.
1. Как можно уменьшить длину?
2. Как можно сделать быстрее?

        ld de, args
        ld bc, args
        call function
        .....

function:
        JP xxxx   ; где xxxx патчится на нужный адрес
                      ; при загрузке программы в память.

[captain cobalt]

        call function
        .....

function:
        JP xxxx   ; где xxxx патчится на нужный адрес
                      ; при загрузке программы в память.

Предлагается патчить адрес в команде CALL.
Тогда вызов будет совершаться напрямую, а JP не нужен.

для этого нужно будет опять же создавать и хранить таблицы этих JP xxxx, а потом патчить.

Когда пропатчивание завершено, таблицы больше не нужны. Память можно использовать для других целей.

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

Ничто не мешает сделать его частью ПЗУ. Тогда он будет существовать в единственном экземпляре и патчить все другие программы.

номер функции не изменяется. Вот его уже менять нельзя.

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

[Vitamin]

Зачем все усложнять?
Есть 8 рестартов, из них можно использовать 5-6 для своих нужд- разделение по функциональности. И 256 функций для каждого рестарта. Итого код:

ld hl,...
ld de,...
ld bc,...
ld a,...
rst N
db func

N: ex (sp),hl ;(sp) - param, hl- retaddr-1
exa
ld a,(hl)
inc hl
ex (sp),hl ;(sp) - retaddr hl- param
push hl
ld l,a
ld h,'table
ld a,(hl)
inc h
ld h,(hl)
ld l,a
exa
ex (sp),hl ;(sp)- jump hl- param
ret

ЗЫ: комбинацию
add a,l
ld l,a
ld a,h
adc a,0
ld h,a

можно заменить на
add a,l
ld l,a
adc a,h
sub l
ld h,a

[axor]

Есть 8 рестартов, из них можно использовать 5-6 для своих нужд- разделение по функциональности. И 256 функций для каждого рестарта.

Тогда получается, что для каждого рестарта нужна своя таблица адресов функций, а это, как мне кажется, расточительно.

[Vitamin]

Тогда получается, что для каждого рестарта нужна своя таблица адресов функций, а это, как мне кажется, расточительно.

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

[axor]

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

Длина таблиц подфункций ограничена количеством этих самых подфункций. Количество же функций должно быть максимально возможным. Это по моему вразумению. Но, как водится, у каждого оно свое.