Баг формата SZX

[Lethargeek]

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

Еще раз: главная причина МНИМОЙ "невозможности" - твоя ЛЕНЬ. Никакой непреодолимой технической проблемы здесь НЕТ. Если у тебя процедура-монолит производит выполнение вместе с выборкой - РАЗДЕЛИ. Или напиши отдельную для сейва, с КОПИЕЙ ЧАСТИ (связанного только с выборкой, "полностью" НЕ нужно) аппаратного контекста, в конце концов. ВСЁ РЕШАЕМО.

Ваше утверждение о полной детерминированности эмуляции некорректно. Даже в эмуляторе есть недетерминированные факторы, такие как пользовательский ввод, время прихода внешних сигналов (например, от дисплея, звуковой карты, системного таймера), а также поведение схемы при загрузке снэпшота. (...)

Моё утверждение абсолютно корректно. Детерминированность - это когда для одних и тех же исходных данных получаем одинаковый результат. Отличающийся пользовательский ввод (который, кстати, сохраняется в szx, да и в типичном эмуле скорей всего сканируется и фиксируется перед прогонкой кадра) или "малейшие" (на практике многие проходят незамеченными) несовпадения чего-то для rzx, или недостаток апппаратных данных в снапшоте - это нарушение условия по исходным данным. Но мы здесь говорим пока что ТОЛЬКО о ВЫБОРКЕ. Для неё условие одинаковых исходных обеспечить технически возможно и не так уж сложно. Тем более, что возможность форка состояний вообще полезна.

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

Если в снапе чего-то не хватает, восстановить недостающий контекст - на совести пользователя. Но уж для ДОСТАТОЧНО корректно восстановленного пользователем, будь так добр обеспечить правильные результаты после загрузки. Это на твоей совести. А в идеале - даже для недостаточного восстановления максимально снизить вероятность проблем.

[Reobne]

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

[ZXMAK]

[QUOTE=Titus;1206650]Как зачем?
Допустим, выполняется RET.
QUOTE]

вопрос довольно простой - можно ли отличить эмулятор эмулирующий конвеер или нет. Для Z80 ответ - нет, никак не отличить. Поэтому и смысла его эмулировать нет - только лишний код.

[Titus]

вопрос довольно простой - можно ли отличить эмулятор эмулирующий конвеер или нет. Для Z80 ответ - нет, никак не отличить. Поэтому и смысла его эмулировать нет - только лишний код.

Как нельзя? Я только что написал, как отличить. По таймингам.

[ZXMAK]

Еще раз: главная причина МНИМОЙ "невозможности" - твоя ЛЕНЬ. Никакой непреодолимой технической проблемы здесь НЕТ. Если у тебя процедура-монолит производит выполнение вместе с выборкой - РАЗДЕЛИ. Или напиши отдельную для сейва, с КОПИЕЙ ЧАСТИ (связанного только с выборкой, "полностью" НЕ нужно) аппаратного контекста, в конце концов. ВСЁ РЕШАЕМО.

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

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

Если у вас есть конкретные предложения по архитектуре или способам реализации, которые могут учесть эту динамичность, их стоит обсудить. Однако текущие ограничения связаны не с "ленью", а с объективной неопределенностью исходных данных на этапе компиляции эмулятора.

Моё утверждение абсолютно корректно. Детерминированность - это когда для одних и тех же исходных данных получаем одинаковый результат

Ваше определение детерминированности верно в контексте строго определённых входных данных и предсказуемого поведения системы. Однако в случае с эмулятором, который взаимодействует с реальным оборудованием и внешними модулями, ситуация значительно сложнее.

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

Подобно тому как невозможно предсказать, выпадет ли орел или решка при подбрасывании монеты, так и в эмуляторе невозможно точно предсказать, когда пользователь нажмет кнопку, когда произойдёт событие обратного хода луча на дисплее, когда будет обработан сигнал от звуковой карты или другие подобные события, зависящие от взаимодействия с внешней средой.

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

Если в снапе чего-то не хватает, восстановить недостающий контекст - на совести пользователя. Но уж для ДОСТАТОЧНО корректно восстановленного пользователем, будь так добр обеспечить правильные результаты после загрузки. Это на твоей совести. А в идеале - даже для недостаточного восстановления максимально снизить вероятность проблем.

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

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

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

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

Как нельзя? Я только что написал, как отличить. По таймингам.

и как по таймингам отличить. Вот синхронизировали эмулятор с конвеером и без конвеера по событию чтения инструкции из памяти, условно приняли это за нулевую точку отсчета - нулевой такт. Разве будет отличие в таймингах следующей выборки и т.д.? Нет, они покажут абсолютно одинаковые тайминги. Отличие будет только в том, как они внутри реализованы. Но на таймингах это не сказывается.

[Titus]

и как по таймингам отличить. Вот синхронизировали эмулятор с конвеером и без конвеера по событию чтения инструкции из памяти, условно приняли это за нулевую точку отсчета - нулевой такт. Разве будет отличие в таймингах следующей выборки и т.д.? Нет, они покажут абсолютно одинаковые тайминги. Отличие будет только в том, как они внутри реализованы. Но на таймингах это не сказывается.

Я же написал выше, как отличить.
Если у тебя крутится цикл, каждая итерация которого заканчивается RET (для примера), и этот RET находится в последнем байте медленной памяти, а следующий байт будет уже быстрая память. Или наоборот.
То такой цикл будет давать другие тайминги на честном Z80 с конвейером, т.к. после RET всегда будет читаться байт из памяти с другими таймингами.

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

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

[ZXMAK]

Если у тебя крутится цикл, каждая итерация которого заканчивается RET (для примера), и этот RET находится в последнем байте медленной памяти, а следующий байт будет уже быстрая память. Или наоборот.
То такой цикл будет давать другие тайминги на честном Z80 с конвейером, т.к. после RET всегда будет читаться байт из памяти с другими таймингами.

нет, оба эмулятора будут давать идентичные тайминги. Отличие будет условным - в названии.
У обоих эмуляторов число тактов между выборками будет одинаковым. Просто в том что без конвеера все такты будут условно сдвинуты на фиксированную величину. Но выборки из памяти будут одинаково работать и все тайминги будут идентичными.

[Titus]

нет, оба эмулятора будут давать идентичные тайминги. Отличие будет условным - в названии.

Мне кажется, кто-то из нас кого-то не понимает)

[ZXMAK]

Мне кажется, кто-то из нас кого-то не понимает)

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

[Lethargeek]

Подобно тому как невозможно предсказать, выпадет ли орел или решка при подбрасывании монеты, так и в эмуляторе невозможно точно предсказать, когда пользователь нажмет кнопку, когда произойдёт событие обратного хода луча на дисплее, когда будет обработан сигнал от звуковой карты или другие подобные события, зависящие от взаимодействия с внешней средой.

да блин горелый же, все эти "предсказания" НЕ НУЖНЫ! ну какая тебе разница, что за кнопка будет нажата юзверем ЗА ПЕРВЫЕ ДВА ТАКТА любой инструкции?

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

ПРИМЕР в студию! ну хотя бы чисто теоретический, что такого ужасного и вселомающего может произойти конкретно ЗА ВРЕМЯ ВЫБОРКИ?

Подобно тому как в SNA невозможно восстановить текущий такт кадра, в SZX также не предусмотрено сохранение состояния префиксов, что делает их восстановление невозможным.

еще раз: значит, сохраняй в тот момент, КОГДА состояние префиксов НЕВАЖНО (это даже и для примитивного sna несложно)