Ядро с 32 битами и виртуализацией

Вот смотрю я на дату последнего сообщения в теме и думаю - что я делал эти 5 месяцев?!

Возможно что-то более необходимое для себя.

Да вот именно, что всё такое нужное, а по итогу спроси что делал - и ответить нечего. Надоела уже эта чехарда приоритетов, "камень-ножницы-бумага".

Жизнь многозадачна, главное стек и память вовремя сохранять.

Я скоро в BSoD выпаду с такой многозадачностью.

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

Задам вопрос пока в этой теме.
Кто-нибудь занимался двоичной трансляцией с Z80, и трансляцией вообще? Вот так чтобы код на лету транслировать и оно выполнялось на другом процессоре.

Это уж скорее конвертация. И в чем отличие от минималистического эмулятора, который только конвертит машинный код эмулируемого проца в последовательность кода исполнителя?

Так я такой эмулятор и имею в виду. Надо же как-то эмулировать Z80.

Добавлять инструкции к Z80 - нет.
Эмулятор-интерпретатор - медленно.
Добавить аппаратный декодер старых инструкций - можно (см. ниже)

Пока думаю о двух вариантах:
Первый - трансляция в "нативные" инструкции и последующее выполнение, но тут много пока непонятных для меня вещей, типа самомодифицирующегося кода.
Второй по-моему вообще наркоманский - инструкция "выполнить содержимое регистра как инструкцию Z80". Если сделать неполный декодер, то он получится очень маленький и простой, остальное выполнять "эмулятором-интерпретатором". Основной цикл при этом будет "loop: ld A,(PC) ; exec A ; jp loop"

- - - Добавлено - - -

Или декодер не аппаратный, а программный, а из аккумулятора выполнять что-то типа микрокода.
Почему именно так - чтобы эмулятор в кэш поместился, иначе всё замедлится в разы. И в то же время не всё аппаратно, чтобы поместилось в мелкую ПЛИС. Сейчас то что есть занимает 2194 LE, но надо экономить, там ещё графика впереди.

- - - Добавлено - - -

А кроме графики - MMU и кэш.

Наверное согласишься, что новый проект должен давать что-то отличное от существующих и желательно конечно в лучшую сторону. А там как хочешь разбить задачу. Если делаешь более совершенный проц чем ASICи z80 это одно, а если сразу систему из которой выйдут более совершенные Спектрумы это другое. Я уже не ориентируюсь насколько далеко ушли замыслы от первоначального сделать проц, на котором без проблем работает код Паскаля.

"Эта ваша музыка. Даёт она что-то? Нет, не даёт. А надо, чтобы давала." :)

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

Вопрос по адресации.

Регистры 32 бита, в адресе учитываются только 24.

(AA,BC,DE,HL,IX,IY,IZ + offset) - это понятно.

(AA,IX,IY,IZ + AA,BC,DE,HL) - нужен ли тут ещё и offset, или можно обойтись без него?

Что бы ещё придумать? Или этого достаточно?

- - - Добавлено - - -

И ещё: нужны ли альтернативные пары регистрам IX/IY/IZ? Которые "exx".

Есть проблема с флагами.

Некоторые инструкции выбиваются по флагам из общей квадратно-гнездовой картины, например:
rlca, rrca, rla, rra (H,N,C)
cpl (H,N)
add HL,reg16 (H,N,C, причём H берётся из старшего байта)
inc/dec 8/16 бит

С inc/dec вообще интересно. 8-битные меняют все флаги кроме переноса, 16-битные флаги не меняют. Я понимаю почему так, но с этим надо что-то делать.

Пока мысль такая: они устанавливают флаги по-своему, но у ассемблера будет режим, в котором он после этих инструкций будет добавлять инструкцию, устанавливающую флаги как в Z80, для совместимости со старым исходным кодом.

Что-то топик заглох...
Куда пропали Bolt, Ynicky, Vlad?
С Владом история вообще интересная. У него был четырехядерный процессор собственной разработки, на котором Влад сделал суперспектрум с уникальным видеорежимом высокого разрешения. Влад продемонстрировал возможности своего видеорежима в одном из топиков, где были скриншоты варика с разрешением и графикой писи.
Владу нужно поделиться деталями своего суперпроцессора с другими. Вот мне, например, интересно, расширял ли он адресацию до 24 бит?