alone, вот и сделай простую виртуальную машину
4 24битных регистра
стек, флаги, PC
минимальный набор команд и вперед
Вид для печати
alone, вот и сделай простую виртуальную машину
4 24битных регистра
стек, флаги, PC
минимальный набор команд и вперед
Сомневаюсь, что это даст какой-то выигрыш по сравнению с критическими секциями или разбиением по 256 байт. По скорости уж точно.
alone, ну зато на спеке будет своя виртуальная машина :)
можно с наворотами :)
Я че-то никак не пойму сути разбиения на 256 байтные куски, можешь детально обьяснить как это должно сработать?
По поводу виртуальной машины, софт эмулятор раз в 5...10 медленее реального процессора, т.е. для той скорости которая была на реальном компе с 7mhz 68000 потребуется z80 со скоростью примерно 50...70mhz и с такой же быстрой памятью, да?
Дима, а чем не подходит принцип, реализованный в iS-DOS (для остальных - обсуждаем сам принцип, а не систему) для резидентов. В тамошнем асме, если компилировать не запускаемый COM-модуль, а резидент (копиляция по ключу /r создает перемещаемый RES-файл), в конце создаваемого после компиляции файла после метки конца "пришивается" табличка с казателями на все критические COM/JP и иже с ними, значение в которых надо менять, добавляя или отнимая смещение при смене стартовых" координат. Эта схема в iS-DOS работает, когда надо добавить или удалить драйвер. Например при удалении драйвера из ряда подключенных, остальные смещаются вверх, занимая освободившееся место, и все переходы в них пересчитываются по табличке.
Ясно, но если код и данные перемещаемы то можно их просто уплотнять (два эти подхода смахивают на свои эквиваленты - форматы дисков TRDOS и FAT12).
Вообще думаю данная тема должна рассматриваться в более широком смысле - runtime для z80 позволяющий под него компилить более менее современные исходники. А основные задачи мне видятся такими:
1. изза ограниченного адресного пространства у z80 нужно иметь механизм для эфективной трансляции 24bit\32bit адресов в спековский <номер страницы + смещение внутри страницы>;
2. нужно иметь код который не привязан к конкретным адресам и в идеале перемещаемый на лету;
Вероятно решить эти задачи можно но скорее с серьезной потерей скорости.
Сам по себе Z80 проблем не испытывает - можно прикрутить к нему 4 окна памяти или даже сегментную адресацию. Проблема на архитектуре 128К, которая в общем-то мертва, но если под неё есть адекватное решение, то почему бы не обсудить :)
Разумеется, перемещаемость лучше, потому что даже одна программа может иметь больше 24К кода, например, Pro Tracker, BGE, Melon, Lara Croft.
Чето я опять не до конца понял о чем это? Как окна решают озвученные проблемы? "Прикрутить сегментную адресацию" - что тут подразумевалось, разделить память инструкций и данных? Это уже есть например в PDP-11 но толку мало, обьем всеравно смешной на данный момент. В моем понимании именно Z80 испытывает основные проблеммы с его 16bit адресами + отсутствием команд адресации относительно PC.
У каждой программы своя страница(ы) кода и своя страница переменных и стека. Их не придётся релоцировать.
Да. Проверяя коды команд внешней логикой. Можно даже сделать сегменты совершенно аналогично IBM PC, т.е. перекрывающиеся. И опять не придётся релоцировать.