Есть еще 1 вариант. Не делать никуда jump, а сразу выполнять операцию по таблице. См. мой Z (правда, он для PC, но важна идея).
Как это не делать джамп?Сообщение от Vladimir Kladov
Приведи пример
Все в исходниках Z. Адрес дать? Вот: http://bonanzas.rinet.ru/zx/z.zip
;-----------------------------------------;Сообщение от Vladimir Kladov
; call certain instruction procedure ;
;-----------------------------------------;
call word ptr seg_Op:[JumpTable+bx]
извиняюсь великодушно, а калл это уже не джамп???
ещё один интересный момент на сайте есть скрин из игрушки Sentinel,
надпись и карта выводятся не полностью - точно такая же ситуация в амиговском эмуле ZxAm
call это хуже. Но дело не в этом. Я же в Z стремился к меньшему размеру. Но если стремиться только к скорости, то можно по таблицам:
1 - увеличивать t тактов,
2 - дальше выполнять операцию
3 - и на финише операции формировать флажки. Примерно это и сделано. Но я стремился к минимальному размеру при соблюдении максимальной корректности, так что основную идею пришлось эксплуатировать совсем не в плане быстродействия. Потому и CALL а не JUMP - чтобы вернуться в то (общее) место, где по таблицам все завершающие части делаются.
А вообще jump'а можно избежать в большом количестве команд (если jump или call тормозит больше чем самомодификация кода эмулятора). Т.е. по таблице выбирается байт, который самомодифицирует следующую команду, и она становится или jump'ом, или начинает ту операцию, которая без jump'а начинает делать что-нибудь (опять по таблицам). Например: LD r1,r2 - их аж 64 команды, и видимо, это одна из частых разновидностей команд. Самомодификация еще пары кодов команд в самом эмуляторе (например, смещения в структуре подправляются), или если хорошая регистровая адресация есть - по 2 регистрам - то в 2 регистра выбираются номера регистров по коду операции, и дальше выполняется - опять без jump'ов выборка из одного "регистра" Z80, и засовывание в другой "регистр" Z80. Остается только 1 jump - на место, где следующая команда выбирается.
Может быть пример и не очень хороший, может быть, имеет смысл ускорять совсем не эти 64 команды (тем более там голову сломишь, что делать с HALT и (HL)), может быть имеет смысл ускорять как раз jump'ы и call'ы, но идея именно такая.
(Вот в PC я точно знаю, что jump, что самомодификация - все равно конвейер останавливается. А на других платформах - вдруг самомодификация дешевле).
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Не знаю тонкостей кэша PC, но, ни на одном из виданых мною процессоров самомодификация в цикле эмуляции не быстрее банального джампа. Мало того, она заведомо медленнее, поскольку программа исполняется из кеша команд, тогда как модификация памяти затрагивает кеш данных, что влечет за собой либо burst-цикл записи кеша данных в память с последующим обновлением кеша команд; либо медленный цикл копирования линейки кеша данных в кеш команд (это лучший вариан, хотя никогда такого не встречал); либо банальную невосприимчивость конвейера к изменившемуся коду.Сообщение от Vladimir Kladov
Что же касается процессоров без кеша (например 68000), то на них почти ВСЕГДА предпочтительней делать джамп по любому поводу и без повода, сколько позволяет свободная память, поскольку отсутствует главный тормозящий фактор кэшевых систем - загрузка линейки кеша команд.
Возможно это связано вот с чем:Сообщение от goodboy
"Well, I am using the same technique used by Peter McGavin in his Spectrum emulator for the Amiga, doing interrupts after 2500 Z80 branch instructions, but I am refreshing the complete screen in every interruption, this way the screen will be refreshed too often some times, I will try to control this with a timer."
С уважением, Станислав.
скорее всего ошибка не в обновлении экрана, а в установке флагов какой нибудь командой
Да нет, не в обновлении дело. Просто при эмуляции НИКАК не учитывается время исполнения инструкций процессора, а прерывание случается после каждых 2500 инструкций перехода. Я так понимаю, что это сделано во имя скорости эмуляции. Скорее всего дело именно в таком подходе к прерываниям.
С уважением, Станислав.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)