Определение частоты/скорости процессора

[Chwe]

TL;DR: как считать количество тактов между двумя прерываниями, чтобы определить скорость процессора?

Захотелось мне в программе определять скорость процессора, так, каприз, не критично, просто чуть удобнее было бы. Добрые люди подсказали, коллега @Uzix пример кода показал. Но, я же самый умный, я пример толком смотреть не стал, начал сразу сам что-то накручивать. Пример, конечно, понадобился позже, не такой я гений, чтобы сразу всё написать сходу, но, к моему удивлению, скорее, для проверки и сверки данных. Теория там понятна, заводим IM 2 и считаем количество тактов, которое успеваем сделать между двумя прерываниями. Эксперименты у меня с Sizif-512, ничего другого в наличии нет.

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

Итак, вид на проблему с моей колокольни. Когда мы увеличиваем частоту процессора и делаем свой обработчик прерываний самое главное не сделать его слишком коротким/быстрым. «ULA» или кто-там-вместо держит /INT 32 «настоящих» такта, согласно ТОЙ САМОЙ КНИГЕ. Получается, когда процессор начинает работать быстрее, его 32 такта в какой-то момент оказываются быстрее 32-х тактов ULA. И тут мы входим в ту же реку дважды. В смысле, обработчик вызывается ещё раз для того же самого прерывания. Понятно, проблема тоже не проблема, делаем обработчик прерывания достаточно долгим и… Всё работает. Важный момент: IM 2 у меня нигде больше не используется и, практически, после одного прерывания отключается. Ну, такая особенность у меня, не нужно мне это, кроме как для измерения скорости, поэтому неразумно длинный обработчик меня не смущает.

Вопрос №0: я правильно понял проблему? А то, может я вообще не то решал и ловил тёмную кошку прямо под фонарём, так сказать

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

Вопрос №1: теоретически рассчитанные задержки на практике можно сократить раза в четыре (подтверждено экспериментально. на Sizif). Раза в два, я бы ещё понял, но в четыре? Есть где-то авторитетный источник, где описано ожидаемое общепринятое поведение «ULA» и Z80 при повышении частоты? Я явно где-то ошибся в расчётах.

Вопрос №2: в примере Евгения и некоторых других, которые я видел, авторы предпочитают добавлять задержку NOP’ами или какими другими «прямолинейными» инструкциями. Я не долго думая сделал цикл и разницы не заметил. Там могут быть какие-то, мне не важные, побочные эффекты и отсутствие цикла принципиально или нет? И итеративно длина обработчика у Евгения подбирается, чтобы остановиться на наименьшем замедлении, которое достаточно, так? Но, всё же, почему не сделать через цикл с параметром…

P.S. как я понял, на Next таких проблем нет, там эмулируемая ULA подстраивает длительность импульса /INT под частоту. Пример, который я сделал и который на Sizif на 14МГц ухитряется вызвать обработчик несколько раз за прерывание, на Next всегда и на любой частоте вызывает обработчик только один раз. Ну, эта информация практически нам тут бесполезна, там на Next и API есть для получения текущей частоты, да и «живого» Next я вряд ли когда увижу.

[Advertiser]

[Uzix]

Вопрос №0: я правильно понял проблему?

Всё так, но ещё стоит упомянуть, что некоторые старые клоны и на обычной (не турбо) частоте могли иметь слишком длинный сигнал INT.

Есть где-то авторитетный источник, где описано ожидаемое общепринятое поведение «ULA» и Z80 при повышении частоты?

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

Вопрос №2: в примере Евгения и некоторых других, которые я видел, авторы предпочитают добавлять задержку NOP’ами или какими другими «прямолинейными» инструкциями. Я не долго думая сделал цикл и разницы не заметил. Там могут быть какие-то, мне не важные, побочные эффекты и отсутствие цикла принципиально или нет? И итеративно длина обработчика у Евгения подбирается, чтобы остановиться на наименьшем замедлении, которое достаточно, так? Но, всё же, почему не сделать через цикл с параметром…

Да без разницы, важно только добить длительность обработчика до длины сигнала INT, делать это можно как вам удобно. В случае NOP'ов надо иметь некоторый запас памяти после обработчика (чтобы NOP'ы не переписали ваш последующий код).

P.S. как я понял, на Next таких проблем нет, там эмулируемая ULA подстраивает длительность импульса /INT под частоту. Пример, который я сделал и который на Sizif на 14МГц ухитряется вызвать обработчик несколько раз за прерывание, на Next всегда и на любой частоте вызывает обработчик только один раз

В случае с Sizif-512 отсутствие подстройки вызвано ошибкой в версии 20230820 (и только в ней) прошивки CPLD - это уже скорректировано и исправление войдёт в следующую версию.

[Barmaley_m]

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

Даже и в пределах 32 тактов можно поймать повторное прерывание. На мой взгляд, более правильным решением является снятие запроса прерывания по сигналу процессора подтверждения прерывания (/M1 or /IORQ). С одной стороны это исключает повторное прерывание в пределах одного кадра; с другой стороны импульс запроса может быть достаточно длительным, чтобы прервать процессор даже при исполнении им "долгих" команд. Это реализовано в некоторых клонах, напр. "Орель БК-08".

Да без разницы, важно только добить длительность обработчика до длины сигнала INT, делать это можно как вам удобно.

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

Также представляет интерес измерение периода прерываний с точностью до одного такта. Ведь nop исполняется за 4 такта, и на их основе время между прерываниями будет измерено с точностью до 4 тактов. Чтобы измерить с точностью до 1 такта, нужно процедуру обработки прерываний добивать другими командами, которые исполняются за 7 или другое кол-во тактов, и измерять несколько раз с разными процедурами. И смотреть точнее, где пролегает граница, когда срабатывает следующее прерывание.

Еще можно измерять, с точностью до такта, длительность сигнала INT. Там тоже надо шаманить с разными командами и делать несколько измерений. Длительность импульса INT можно измерить даже в случае, если запрос снимается по подтверждению (как в "Орель БК-08"). Для этого нужно в разное время разрешать прерывания и смотреть, сработает или нет.

[Chwe]

Всё так, но ещё стоит упомянуть, что некоторые старые клоны и на обычной (не турбо) частоте могли иметь слишком длинный сигнал INT.

Спасибо! В общем, запускаем.

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

IRQ interval

        ld c, delay     ; delay = 18, pause for 268 
        xor a   
        ld hl, 0 
        ei
        halt    ; handler increases A, now we have 1
_measure:
        inc hl
        cp 1    ; if we still have 1, wait and count
        jp z, _measure
        [...]

irq_handler:
        inc a           ; 4
        ld b, c         ; 4
_delay:
        djnz _delay     ; 13/8
        ei              ; 4
        reti            ; 14

[свернуть]

Конечный результат получился примерно вот такой.

[reddie]

TL;DR: как считать количество тактов между двумя прерываниями, чтобы определить скорость процессора?

Фишка еще в чем: у разных моделей спека разное количество тактов между прерываниями, поскольку разная длина строки в тактах, плюс разное количество строк (312/320 как самое известное, но могут быть м другие варианты). По итогу частота прерываний не ровно 50гц, а главное - программно это никак не отловить (пресловутый порт FF тут не панацея). Плюс вейтовые и безвейтовые модели. Вот и получается, что "частота проца" будет правильной для какой-то конкретной схемы, но ошибочно вычисляться на другой модели.
Поведение Z80 при повышении частоты, или иначе, сколько вэйтов он будет получать в турборежиме и постоянно ли "будет в турбе", напрямую зависит от реализации турборежима: древний вариант турбирования Скорпиона давал лишь 40% прироста, там очень кривая схема (турбо включалось только на бордюре)

[Uzix]

Даже и в пределах 32 тактов можно поймать повторное прерывание. На мой взгляд, более правильным решением является снятие запроса прерывания по сигналу процессора подтверждения прерывания (/M1 or /IORQ). С одной стороны это исключает повторное прерывание в пределах одного кадра; с другой стороны импульс запроса может быть достаточно длительным, чтобы прервать процессор даже при исполнении им "долгих" команд.

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

[Bedazzle]

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

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

[Barmaley_m]

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

Этого можно избежать, если ограничить максимальную длительность INT в случае отсутствия подтверждения (напр. в "Орель БК-08" это было 28 тактов, что гарантирует срабатывание разрешенного прерывания, т.к. самая медленная команда Z80 исполняется за 23 такта).

Но я бы так не делал, а позволил бы импульсу прерывания растянуться, если прерывания запрещены. Не обязательно до следующего кадра, но все же. На каких-нибудь 200-1000 тактов хотя бы. Ведь часто в программах бывает такое, что прерывания запрещаются на короткое время (для обеспечения синхронной передачи данных между фоновой программой и процедурой обработки прерывания). И обидно, если прерывания были запрещены на каких-нибудь 40 тактов, а за это время как раз пришел импульс, и мы его "проспали".

[Chwe]

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

Да, кстати, для Next, подумав, решили задирать частоту по максимуму, по умолчанию, и сделать параметр для указания потребной, буде возникнет такая фантазия