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

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 я вряд ли когда увижу.

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Uzix

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

---

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

Цитата:

---

Сообщение от Uzix

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

---

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

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

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

Цитата:

---

Сообщение от Uzix

Всё так, но ещё стоит упомянуть, что некоторые старые клоны и на обычной (не турбо) частоте могли иметь слишком длинный сигнал 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

---

[свернуть]

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

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Barmaley_m

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

---

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

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Uzix

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

---

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

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

Цитата:

---

Сообщение от Bedazzle

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

---

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