По видимому придётся это делать тебе.Цитата:
Сообщение от axor
А я повторюсь- табличка JP в начале ПЗУ - наиболее оптимальный вариант как по размеру пямяти, так и по скорости.
Вид для печати
По видимому придётся это делать тебе.Цитата:
Сообщение от axor
А я повторюсь- табличка JP в начале ПЗУ - наиболее оптимальный вариант как по размеру пямяти, так и по скорости.
Видимо так и будет, ежели никто не опередит или каждый из предлагавших не сформулирует свою мысль четко и внятно.Цитата:
Сообщение от Sinus
Для ПЗУ -- да, согласен. Но я считаю, смысла ориентироватьсяЦитата:
Сообщение от Sinus
на ПЗУ как на что-то большее, чем тест системы и начальный
загрузчик -- НЕТ. Ибо места мало и немодифицируемо. Если
нужна именно твердотельная память: загрузчик в ПЗУ, остальное
на compact flash. А тут уже другие методы могут быть. Но я
опять же считаю, CALL через массив JP xxx -- наиболее оптимально
по памяти и скорости. Прямой CALL выигрывает всего 10
тактов но неудобен жутко как для загрузки, так и для создания
загрузочного файла вообще (как в ALASM список адресов для
патча составить?) Речь про загрузку по абсолютному адресу
в т.ч. Через RST никакого смысла кроме тормозов нет вообще.
То есть смысл может быть и есть, но только там где нужен
ИМЕННО МАШИННЫЙ КОД, ни в коем случае не интерпретатор,
и нужна жуткая экономия памяти. Таких случаев, с ходу и не
назову. Там где нужно сэкономить память больше толку будет
от интерпретируемого языка (хоть бы и бейсика), от FORTH может
быть.
Ну раз требують %)Цитата:
Сообщение от axor
В виде своих десяти копеек предлагаю прямые call на адреса функций системы, патчуемые (во словечко!) при загрузке программы.
Отличия от кернельного метода (набор jp по фиксированным адресам)
- 2 байта на адрес точки входа (которые меняются от версии к версии) против 3 байтов
- 2 байта на каждый call в настраиваемой программе. для последующей настройки. в дальнейшем эта память может использоваться под свои нужды (можно не считать)
- несколько сотен(?) байт на настройщик (проигрыш)
Выигрываем 10 тактов на выполнение каждого вызова и проигрываем несколько сотен(?) тактов на настройщик (один раз за всю работу программы)
Это сделать можно, Alco где-то об этом писал и пример был. А может и не Alco это вовсе был. Тема была про релоцируемость.Цитата:
Сообщение от fk0
это может делать сама прога в случае с джампами. т.е. патчить себя взяв значения оттуда.Цитата:
Сообщение от Vitamin
т.е. метод со списком джампов универсальней
макросы для адресозависимых команд и все...Цитата:
Сообщение от fk0
ага. и на всякий случай еще сделать поддержку rst %)Цитата:
Сообщение от jtn
Компиляция в два адреса и сравнение. Здесь грабели подложены:Цитата:
Сообщение от axor
Всё релоцируемое -- обязательно двухбайтовое. Да и вопрос вКод:типичный код:
LD E, char
LD D, FONT / 256
...
том, как потом отличить CALL xxx на библиотеку от адресов,
сменившихся в результате сдвига начального адреса? Одни
вопросы.
Но дело ведь в том, что есть программы с абсолютным адресом
загрузки без всяких релоцируемостей. Им это всё -- лишь ненужное
усложнение. При вызове через JP xxxx никакой релоцируемости
изобретать не нужно вовсе. Просто берётся и "в лоб" ассемблируется.
После загрузки, адреса списка JP xxxx изначально были известны,
остаётся заменить номера функций на действительные адреса. Местоположение действительных адресов тоже известно, в случае
ПЗУ они (адреса) сами расположены по предопределённым заранее
абсолютным адресам. Тривиальный код получается.
Для ALASM -- да. Мне не нравится. Сильно список адресов дляЦитата:
Сообщение от Vitamin
патча большой получается. И потом в таком варианте не реализуется
функция-фильтр (когда в JP xxxx подсовывается её адрес вместо
действительного).