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

[Sinus]

SAM style: у тебя регистру A сипец наступает (внимательно не смотрел, но по ходу и HL тоже) ^_~

axor: если тебе не только теоретически интересно как сделать короче и быстрее, то вариант предложенный fk0 самый найлучший. разделение функции на две (функция / подфункция) это неправильный подход принесённый со времён DOS на PC.

[SAM style]

SAM style: у тебя регистру A сипец наступает (внимательно не смотрел, но по ходу и HL тоже) ^_~

HL в неприкосновенности. Насчет A - можно окаймить прогу этим:

      LD (a_reg+1),a
      ...
a_reg LD a,0
      RET

+17 тактов и 5 байт (все равно быстрее). Убьется тоько A'
От подфункций действительно надо избавиться - 256 штук одних функций это не так уж и мало, и то вряд ли фантазии хватит их все забить.

[jtn]

HL в неприкосновенности. Насчет A - можно окаймить прогу этим:

ага. в ПЗУ-то..

[SAM style]

ага. в ПЗУ-то..

Мдя... Не учел.
Тогды A приносим в жертву. На крайний случай для передачи параметров у нас есть еще 6 альтернативных регистров, IX и IY. Можно даже R задействовать, но это уже изврат...
Можно еще PUSH-ей и POP-ов напихать, но выигрыша или не будет, или он будет мизерным.

[axor]

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

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

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

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

[fk0]

SAM style: у тебя регистру A сипец наступает (внимательно не смотрел, но по ходу и HL тоже) ^_~

У меня тоже наступает. HL и A. Просто нужно иметь соглашение,
что через эти регистры ничего не передаётся при вызове нелокальных
функций. Через HL может только адрес объекта и/или таблицы
виртуальных функций передаваться. Через A -- номер функции.

axor: если тебе не только теоретически интересно как сделать короче и быстрее, то вариант предложенный fk0 самый найлучший. разделение функции на две (функция / подфункция) это неправильный подход принесённый со времён DOS на PC.

Насколько я знаю, это подход принесённый (и в дос в т.ч.)
ещё из CP/M. (ld c, функция; call #0005). Почему -- понятно.
Загруженный код программы может без всяких хитростей
быть сразу запущен.

В современных операционных системах тоже так. Встроенные функции ОС (например linux или bsd -- как там в windows NT понять сложно, но вроде как тоже примерно так) вызываются аналогичным образом. Например, функции open или read (к языку C прилагаются функии-обёртки распределяющие аргументы по разным регистрам процессора и вызывающие программное прерывание).

Встроенных функций ОС очень мало. У того же линуха порядка
200-300 штук. Другое дело -- библиотечные функции. Их много. Они могут быть загружены или могут не быть загружены. В современных ОС используется подход близкий к указанному мною. Любая функция доступна по её адресу. Но перед тем как какая функция может быть
использована требуется загрузка библиотеки и настройка программы и библиотеки на совместное использование.

[Advertiser]

[fk0]

Мдя... Не учел.
Тогды A приносим в жертву. На крайний случай для передачи параметров у нас есть еще 6 альтернативных регистров, IX и IY. Можно даже R задействовать, но это уже изврат...
Можно еще PUSH-ей и POP-ов напихать, но выигрыша или не будет, или он будет мизерным.

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

[SAM style]

У меня тоже наступает. HL и A

ex (sp),hl на стеке - парам.HL, в HL - адрес следующий за call
... берем A и A' - номер функции, подфункции
ex (sp),hl на стеке - адрес возврата (+2), парам.HL - в HL
push hl стек: парам.HL, адрес возврата
... в HL вычисляем адрес процедурины
ex (sp),hl стек: адрес процедуры, адрес возврата, парам.HL - в HL
ret переход на адрес процедуры.

Где порча HL? Убей, не вижу.

[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 -- число вызываемых функций (используемых
загруженной программой).

[Vladimir Kladov]

Обсуждался уже очень простой способ, как раз с номерами. Время тратится только во время первого вызова на патч, при следующих вызовах происходит call. Дополнительное примущество: можно использовать call cond. JP использовать нельзя, код в ПЗУ пропатчит не то.
Например, в ПЗУ по адресам 100Н...1FFH находится переходник следующего вида.
ORG 100H
DEFB (E8H)18H,(18H)0

(как вариант, может быть 255 раз RST n на нужный адрес, только тогда надо из стека вытолкнуть один лишний адрес возврата в коде патчилки).

После чего с адреса 200H в ПЗУ пишется примерно такой код:
ORG 200H
EX (SP),IX:PUSH HL,DE,AF
LD E,(IX-2):LD D,0:LD HL,TableJumps:ADD HL,DE:ADD HL,DE
LD (IX-2),L:LD (IX-1),H
;здесь можно приготовить код для Jumper'а:
LD A,C3h:LD (Jumper),A ; а можно и не готовить, если он 1 раз готовится, и есть уверенность, что его никто не будет портить
;а эту часть Jumper'а надо установить сейчас в адрес перехода:
LD (Jumper+1),HL
POP AF:POP DE:POP HL
EX (SP),IX:JP Jumper

Место для Jumper должно быть выделено где-то в ОЗУ, 3 байта, например:
ORG FFF0h
Jumper: JP 0

Да, номера здесь должны быть в диапазоне 100H..1FFH, чтобы 0-е адреса не занимать, как раз для RST и прочего.

В ассемблере пишется
Fun0 EQU 100H
Fun1 EQU 101H
...

От версии прошивки ПЗУ ничего не зависит, программа всегда попадает куда надо. Только первый вызов длинный, прочие всегда прямой call.

Другой (лучший!) вариант, самый распространенный для микрокомпьютеров - это выделить в ПЗУ таблицу переходов, по 3 байта каждый, с заданного адреса, например, опять со 100H:
ORG 100H
Fun0: JP Fun0_implement
Fun1: JP Fun1_implement
...
В асме использовать таблицу EQU:
Fun0 EQU 100H
Fun1 EQU 103H
...
Никаких извратов, вместо номеров 0..FF используются адреса 100H..3FDH с шагом 3. Все быстро, можно использовать JP. Расходы в ПЗУ еще меньше чем в случае 1 выше. Я бы выбрал именно вариант 2.