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

короче поехали. отвечаю всем подряд.

axor
я так понял ты новое ПЗУ собираешься делать, причём такое, что б всё было круто независимо от версии прошивки.

наиболее компромиссный вариант- создать в ПЗУ табличку переходов вида

func1 jp real-func-1
func2 jp real-func-2
....

на самом деле нужно думать, что важнее, память (когда используем код вида

....
RST #10
DB func_number
....

) или быстродействие (табличка переходов). я, так же как и Vladimir Kladov считаю что jp-табличка лучше.

fk0
в современных осях на современных пэцэтах есть современный protected mode, в котором можно переопределить адреса переходов комманд int 0x00 ... int 0xFF.

чтобы код программы мог быть запущен, необязательно передавать параметры через стек, патчить прогу или использовать конструкции вида RST XX: DB YY

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


с адреса #0000 находится 256 jp XXXX. это системные вызовы. параметры передаются в регистрах. если нужно передать адрес, то он всегда в HL, если нужно передать один байт, то он всегда в A.

ну и т.д.

далее всё зашибенно работает.

Цитата:

---

Сообщение от fk0

Код:

---

        call function
        .....

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

---

---

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

Цитата:

---

Сообщение от axor

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

---

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

Цитата:

---

Сообщение от fk0

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

---

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

Цитата:

---

Сообщение от fk0

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

---

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

Зачем все усложнять?
Есть 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

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

---

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

Цитата:

---

Сообщение от acidrain

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

---

Секрет...

Цитата:

---

Сообщение от Vitamin

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

---

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

Привет тебе, _/Alexandr/_!

17 ноября 2005 22:58, Alexandr Sinyakov писал(а) All:

Цитата:

---

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

---

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

;Вариант с номером после команды вызова и с порчей А
ex (sp), hl ;19
ld a, (hl) ;7
inc hl ;6
ex (sp), hl ;19
push hl ;11
ld h, rsttab/256;7
ld l, a ;4
ld a, (hl) ;7
inc h ;4
ld h, (hl) ;7
ld l, a ;4
ex (sp), hl ;19
ret ;10
итого 124 такта

;Вариант с передачей номера в А
push hl ;11
ld h, rsttab/256;7
ld l, a ;4
ld a, (hl) ;7
inc h ;4
ld h, (hl) ;7
ld l, a ;4
ex (sp), hl ;19
ret ;10
;Итого 73 такта

Более того, можно использовать оба варианта на одном и том же коде! Второй вариант, это ведь просто другая точка входа от первого варианта. :)
А разбор подфункции логичнее сделать прямо в тех функциях, где это надо. Hо не выносить в общий механизм вызова.

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

До новых встреч! С уважением, Тхэнн.
... Nereal was created for us

то указанные способы подразумевают "взаимодействие" программы загруженной и парсера, работающего в ПЗУ. посмотрите на http://zxdocs.fatal.ru/coding/module.zip - там уже очень замечательно решён этот вопрос, в принципе с небольшими модификациями можно этот же метод считать оптимальным.

Вообще, моё глубокое убеждение состоит в том, что глупо реализовывать парсинг вызова в ходе работы самой программы - при загрузке программы всё равно тратится ОЧЕНЬ много процессорного времени и препроцессинг тела программы незначительно увеличит это время (загрузка одного сектора в 256 байт длится около 20-30 тысяч тактов, а среднестатистическая программа-утилита занимает секторов 5-6, игрушки и демки в разы больше; процесс настройки прямых вызовов рутин из ПЗУ жрёт качественно меньше тактов - скорей всего уложится в одно прерывание), однако отсутствие парсера в процессе ВЫПОЛНЕНИЯ программы приведёт просто к качественному ускорению РАБОТЫ кода.

Например, взять программы умножения двух однобайтовых чисел. Сама программа занимает около 500 тактов. А парсер 200. Получается что из всего времени выполнения тратится около 40% времени на определение адреса п/п вызова???? И это каждый вызов!!! Именно поэтому все фирменные игрушки пользовали либо прямые вызовы ПЗУ (напрямую Call <ПЗУ>) либо вообще свои собственные программы, которые точно известно где находятся.

эффективно (в смысле затрат памяти) - использовать символьные имена для работы с п/п ПЗУ :D (я бы даже более сказал :D) однако имеет право на жизнь хотя бы потому, что такие функции никогда не перекроют друг друга.
Например:

call PrintChar

А если взять безликий

RST 16
defb 81
defb 12

то тому, кто будет писать такую п/п будет необходимо будет держать в руках справочник чтобы смотреть соответствие между вызываемой функцией и её байтами описателями (те самые defb) - такую работу должен выполнять не программист, а машина.
Да и запомнить символьное имя PrintChar в любом случае проще.
Кроме того, символьные имена хорошо жмутся (5 бит используют из 8, если даже взять спецсимволы то 6 бит из 8, или скажем обработать хаффманом), так что трёхсимвольное имя будет кушать практически столько же места сколько вызов через DefB.

P.S. Под перекрытием я подразумеваю возможность вызова разных функций при том же синтаксисе - PrintChar либо не оттранслируется вообще, потому что нет такой функции, либо будет транслироваться замечательно. Rst Defb Defb при смене набора функций придётся отслеживать. Первый Defb отвечает за группу функций - если после обновления версии случилось так что группа расширилась за 256 значений функций, то придётся ещё один номер группы резервировать и это в свою очередь головняк и головняк

Есть такая штука называется макрокоманда. Определяется макрокоманда

PrintChar MACRO char
RST 16:DEFB char
ENDM

И дальше в коде пишется

PrintChar 'a'

Глазами по таблицам лазить не нужно. Для того и сущствуют компиляторы.