Баг формата SZX

[Lethargeek]

Опкоды читаются в цикле M1. Он только для этого и предназначен.

а в M4 для "DD CB +d xx" тогда что читается, и почему точно такое же для "CB xx" читается в M1?

[Titus]

а в M4 для "DD CB +d xx" тогда что читается, и почему точно такое же для "CB xx" читается в M1?

Не понял твой вопрос)

DD и CB, и любые префексы и опкоды читаются в M1
M2 - это чтение смещения
M3 - это вычисление смещения
M4 - это чтение непосредственных данных

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

Циклы конечно многофункциональны, но в общих чертах так

[ZXMAK]

оба ответа неверные
ответ верный только частично - дело вовсе не в "префиксном режиме"

Не совсем ясно, почему вы берёте на себя роль судьи, оценивая, что "верно", а что "неверно". Думаю, было бы более корректно выразить своё несогласие, аргументировав его, например: "Я с вами не согласен, потому что...".

Во-первых, ваше заявление о "неверности" ответа в данном случае ошибочно. То, что вы упоминаете, не противоречит сказанному, а лишь дополняет его.

Во-вторых, ваш аргумент относительно второго пункта не точен. Инструкция NOP не переводит процессор в состояние, которое не может быть сохранено в формате SZX. Префиксы, напротив, действительно могут перевести процессор в такое состояние, так как SZX не сохраняет информацию о текущих префиксных режимах. Именно в этом состоит принципиальная разница между инструкцией NOP и префиксами в данном контексте.

[Lethargeek]

Не понял твой вопрос)

DD и CB, и любые префексы и опкоды читаются в M1
M2 - это чтение смещения
M3 - это вычисление смещения
M4 - это чтение непосредственных данных

ладно, зайдём с другой стороны

каждый M1 увеличивает значение в R на единицу, так?
один префикс - это один цикл M1, так?

теперь два вопроса:
1) на сколько увеличится R после выполнения "CB xx"?
2) на сколько увеличится R после выполнения "DD CB +d xx"?

[Titus]

каждый M1 увеличивает значение в R на единицу, так?
один префикс - это один цикл M1, так?

теперь два вопроса:
1) на сколько увеличится R после выполнения "CB xx"?
2) на сколько увеличится R после выполнения "FD CB +d xx"?

Так.

R увеличивается только в цикле M1.

Ты сам себе ответил в вопросе) Сколько префиксов или опкодов на столько и увеличится)

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

Мне кажется, мы куда-то в сторону ушли)

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

Да, есть исключение именно в FD CB.
Тут код команды читается не в цикле M1, а в цикле M3.
Так что ты прав, это особый случай.

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

Я думаю, это было сделано для ускорения выполнения таких команд, чтобы не повторять заново цикл M1, который более длинный из-за регенерации памяти.

[Lethargeek]

Тут код команды читается не в цикле M1, а в цикле M3.

в M4 (в M3 адрес операнда вычисляется)

Я думаю, это было сделано для ускорения выполнения таких команд, чтобы не повторять заново цикл M1, который более длинный из-за регенерации памяти.

M4 - тоже четырёхтактовый, так что не поэтому

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

подозреваю, там вообще другая схема работает по сравнению с "нормальным" CB префиксом
но хотелось бы чётких подтверждений/опровержений и грязных подробностей от тебя))

[Titus]

в M4 (в M3 адрес операнда вычисляется)

Инициируется M3, заканчивается в M4.



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

вподозреваю, там вообще другая схема работает по сравнению с "нормальным" CB префиксом
но хотелось бы чётких подтверждений/опровержений и грязных подробностей от тебя))

Да, там другая схема.
И на реверсе все это видно)

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

M4 - тоже четырёхтактовый, так что не поэтому

Дело не в четырехтактовости.
А в том, что в М1 много делается разного лишнего для регенерации памяти. В том числе блокируется использование блока 16-битного автоинкремента/копирования для основного набора регистров.
Т.е. в M1 этим блоком пользуются только PC и IR.
А тут нужна переброска WZ (со сформировавшимся адресом данных).
Думаю, что именно для этого и сделан такой дополнительный костыль.

[ZXMAK]

а в M4 для "DD CB +d xx" тогда что читается, и почему точно такое же для "CB xx" читается в M1?

в префиксном режиме CB уже не префикс, а инструкция, хоть и сложная

[Lethargeek]

Не совсем ясно, почему вы берёте на себя роль судьи, оценивая, что "верно", а что "неверно". Думаю, было бы более корректно выразить своё несогласие, аргументировав его, например: "Я с вами не согласен, потому что...

я всего лишь хочу устранить неоднозначности в определении ЗНАЧИМОСТИ префикса
для меня вот "значимый" - это который что-то ЗНАЧИТ для выполнения фрагмента
то есть от его присутствия или отсутствия (замены на ноп, например) может измениться результат
если результат в принципе НЕ может измениться - префикс НЕзначимый
(для упрощения пока считаем, что прерываний не случится за это время)

Во-первых, ваше заявление о "неверности" ответа в данном случае ошибочно. То, что вы упоминаете, не противоречит сказанному, а лишь дополняет его.

именно противоречит! было заявлено:

в контексте SZX (ЗНАЧИМЫЙ префикс) - это последний префикс в серии префиксов.

заявленный признак не является, ни необходимым, ни достаточным, так как найдутся контрпримеры в любую сторону
если префикс последний, он необязательно значимый; если значимый, то необязательно последний (...DD CB)

в контексте SZX (НЕзначимый префикс) - это НЕ последний префикс в серии префиксов.

то же самое

Во-вторых, ваш аргумент относительно второго пункта не точен. Инструкция NOP не переводит процессор в состояние, которое не может быть сохранено в формате SZX. Префиксы, напротив, действительно могут перевести процессор в такое состояние, так как SZX не сохраняет информацию о текущих префиксных режимах. Именно в этом состоит принципиальная разница между инструкцией NOP и префиксами в данном контексте.

еще раз: а для предваряемой команды - какая разница?
и зачем нужно сохранять состояние, которое далее заведомо не используется?

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

в префиксном режиме CB уже не префикс, а инструкция, хоть и сложна

любой префикс был и остаётся инструкцией

[ZXMAK]

еще раз: а для предваряемой команды - какая разница?
и зачем нужно сохранять состояние, которое далее заведомо не используется?

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

Обдумав варианты, решил остановиться на компромисном варианте. При остановке эмулятор пытается завершить префиксную инструкцию, если это не получается в течении большого количества тактов, то останавливает как есть. Таким образом минимизируется вероятность префиксного состояния, которое невозможно корректно сохранить SZX, в то-же время во время загрузки при наличии взведенного флага LAST_EI (который по документации взводится также и для префиксов), производится проверка предыдущего опкода в памяти, если это префикс, то восстанавливается префиксное состояние. Таким образом эмулятор по возможности сохраняет снэпшоты, которые однозначно будут загружены другими эмуляторами, но также при необходимости позволяет сохранить/восстановить и префиксное состояние. Правда такие снэпшоты не будут корректно работать на эмуляторах которые не поддерживают остановку в префиксном состоянии.

Хотя может кому-то ситуация со всей памятью забитой префиксом покажется нереальной, но вот например тест, который переводит ZX Spectrum +2/3 в такой режим: