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

[Sinus]

Мужики, может подведем некую черту по теме?
Напоминаю, она звучала как "Вызов функций через RST".
Желательно "разложить" по полочкам все предложенные варианты. Ели этого никто не сделает, я попытаюсь это сделать сам, но, к сожалению, не скоро.

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

[Advertiser]

[axor]

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

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

[fk0]

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

Для ПЗУ -- да, согласен. Но я считаю, смысла ориентироваться
на ПЗУ как на что-то большее, чем тест системы и начальный
загрузчик -- НЕТ. Ибо места мало и немодифицируемо. Если
нужна именно твердотельная память: загрузчик в ПЗУ, остальное
на compact flash. А тут уже другие методы могут быть. Но я
опять же считаю, CALL через массив JP xxx -- наиболее оптимально
по памяти и скорости. Прямой CALL выигрывает всего 10
тактов но неудобен жутко как для загрузки, так и для создания
загрузочного файла вообще (как в ALASM список адресов для
патча составить?) Речь про загрузку по абсолютному адресу
в т.ч. Через RST никакого смысла кроме тормозов нет вообще.
То есть смысл может быть и есть, но только там где нужен
ИМЕННО МАШИННЫЙ КОД, ни в коем случае не интерпретатор,
и нужна жуткая экономия памяти. Таких случаев, с ходу и не
назову. Там где нужно сэкономить память больше толку будет
от интерпретируемого языка (хоть бы и бейсика), от FORTH может
быть.

[Vitamin]

Мужики, может подведем некую черту по теме?
Напоминаю, она звучала как "Вызов функций через RST".
Желательно "разложить" по полочкам все предложенные варианты. Ели этого никто не сделает, я попытаюсь это сделать сам, но, к сожалению, не скоро.

Ну раз требують %)
В виде своих десяти копеек предлагаю прямые call на адреса функций системы, патчуемые (во словечко!) при загрузке программы.
Отличия от кернельного метода (набор jp по фиксированным адресам)
- 2 байта на адрес точки входа (которые меняются от версии к версии) против 3 байтов
- 2 байта на каждый call в настраиваемой программе. для последующей настройки. в дальнейшем эта память может использоваться под свои нужды (можно не считать)
- несколько сотен(?) байт на настройщик (проигрыш)
Выигрываем 10 тактов на выполнение каждого вызова и проигрываем несколько сотен(?) тактов на настройщик (один раз за всю работу программы)

[axor]

(как в ALASM список адресов для
патча составить?)

Это сделать можно, Alco где-то об этом писал и пример был. А может и не Alco это вовсе был. Тема была про релоцируемость.

[jtn]

В виде своих десяти копеек предлагаю прямые call на адреса функций системы, патчуемые (во словечко!) при загрузке программы.

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

[Vitamin]

как в ALASM список адресов для
патча составить?

макросы для адресозависимых команд и все...

[Vitamin]

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

ага. и на всякий случай еще сделать поддержку rst %)

[fk0]

Это сделать можно, Alco где-то об этом писал и пример был. А может и не Alco это вовсе был. Тема была про релоцируемость.

Компиляция в два адреса и сравнение. Здесь грабели подложены:

  типичный код:

    LD E, char
    LD D, FONT / 256
    ...

Всё релоцируемое -- обязательно двухбайтовое. Да и вопрос в
том, как потом отличить CALL xxx на библиотеку от адресов,
сменившихся в результате сдвига начального адреса? Одни
вопросы.

Но дело ведь в том, что есть программы с абсолютным адресом
загрузки без всяких релоцируемостей. Им это всё -- лишь ненужное
усложнение. При вызове через JP xxxx никакой релоцируемости
изобретать не нужно вовсе. Просто берётся и "в лоб" ассемблируется.
После загрузки, адреса списка JP xxxx изначально были известны,
остаётся заменить номера функций на действительные адреса. Местоположение действительных адресов тоже известно, в случае
ПЗУ они (адреса) сами расположены по предопределённым заранее
абсолютным адресам. Тривиальный код получается.

[fk0]

макросы для адресозависимых команд и все...

Для ALASM -- да. Мне не нравится. Сильно список адресов для
патча большой получается. И потом в таком варианте не реализуется
функция-фильтр (когда в JP xxxx подсовывается её адрес вместо
действительного).