Самомодифицирующиеся вектора прерываний

Микропроцессорные устройства

Модератор: Модераторы

Максим В
Пользователь
Сообщения: 72
Зарегистрирован: 11 май 2020, 00:44

Самомодифицирующиеся вектора прерываний

Сообщение Максим В » 28 май 2020, 02:27

В моей прошивке, векторы-редиректоры обработчиков прерываний собираются в ОЗУ, и все статические векторы прерываний 8085 из ПЗУ указывают на статически распределённые области в ОЗУ (насколько это помню). Т.е. у меня применён самомодифицирующийся код (для того, чтобы SWITCH-CASE или IF-THEN-ESLE структуры длиной в километр не писать). Это позволило обрабатывать прерывания с минимальными накладными расходами (поэтому можно приём-передачу одновременно по MIDI)

Аватара пользователя
Dmitry Dubrovenko
Администратор
Сообщения: 1724
Зарегистрирован: 12 окт 2014, 20:20
Местоположение: Санкт-Ленинград
Контактная информация:

Re: Самомодифицирующиеся вектора прерываний

Сообщение Dmitry Dubrovenko » 28 май 2020, 11:54

Максим В писал(а):применён самомодифицирующийся код

Тут не совсем понял, почему обработчик прерывания должен каждый раз модифицироваться?
Подпись

Максим В
Пользователь
Сообщения: 72
Зарегистрирован: 11 май 2020, 00:44

Re: Самомодифицирующиеся вектора прерываний

Сообщение Максим В » 28 май 2020, 13:26

Dmitry Dubrovenko писал(а):Тут не совсем понял, почему обработчик прерывания должен каждый раз модифицироваться

Тут всё очень просто. Представьте себе, что когда работаете по MIDI, Вы получаете несколько байт. Вместо того, чтобы дожидаться всей посылки переменной длины, начинаем декодировать на ходу. Если первый байт - KEYON, то тогда следующий - известен. Т.е. вместо SWITCH-CASE, можно модифицировать вектор прерывания, т.е. при следующем вызове на приём байта, сразу попадаем без всякого ветвления на необходимую обработку. И так везде. В результате - код модифицируется, а задержка и контекст для сохранения в стэк оптимизируется и снижается до минимума. Этот метод я использую уже 30 лет, хотя сейчас машины стали быстрее раз в 100!

Аватара пользователя
Dmitry Dubrovenko
Администратор
Сообщения: 1724
Зарегистрирован: 12 окт 2014, 20:20
Местоположение: Санкт-Ленинград
Контактная информация:

Re: Самомодифицирующиеся вектора прерываний

Сообщение Dmitry Dubrovenko » 28 май 2020, 16:26

Максим В писал(а):можно модифицировать вектор прерывания

И всё-таки не совсем пойму, в чём преимущество?
Что бы модифицировать вектор, необходимо выполнить несколько команд, т.е. всё-равно потеря процессорного времени.
И почему должен измениться контент сохраняемый в стеке?
Подпись

Максим В
Пользователь
Сообщения: 72
Зарегистрирован: 11 май 2020, 00:44

Re: Самомодифицирующиеся вектора прерываний

Сообщение Максим В » 28 май 2020, 19:20

Dmitry Dubrovenko писал(а):И всё-таки не совсем пойму, в чём преимущество?

Детерминизмом обработки событий называется время от прихождения события до его физической обработки. Чем менее детерминированная задержка, тем меньше фазовый шум событий обработки. Другими словами, нужно сократить по максимуму время от приёма байта и выставления прерывания ЦПУ до физического события NOTE ON. Всё остальное время не принимаем во внимание. При перепрограммировании вектора прерывания, вся подготовительная работа случается заранее. Т.е. в момент получения последнего байта (velocity) в последовательности NOTE ON нет никакого программного сравнения (всё уже подготовлено). Прерывание -> ЦПУ выходит на вектор -> сохранет только нужные регистры в стэк (не весь контекст прерывания) -> считывает VELOCITY с UART -> загружает в кольцевой буфер ромплера последний элемент на KEY ON -> активирует нить ромплера -> всё! Нота начинает проигрываться. Детерминизм менее 100мкс! Это очень важно для того, чтобы не было "плавания" момента проигрывания событий.
При программировании в современном понимании, особенно микроконтроллеров, а не микропроцессоров, не все компиляторы С/C++ понимают концепцию КОНТЕКСТА П-П обработчика прерываний. Некоторые приёмы, обычные для 80х, совершенно неизвестны современному поколению. В наше время микроконтроллеры имели очень ограниченные возможности. Так, например, в программе DR8 очень часто применяются методы быстрого умножения (как в демках). При программировании у меня были великолепные средства пошаговой отладки на MSX, поэтому мне не нужно было осторожничать в выборе стиля и метода написания того или иного модуля. Т.е. готовые модули, "отшагавшие" в отладчике Леонида Бараза (MSX) переносились в код DR8. Всё работало просто замечательно.

Аватара пользователя
Dmitry Dubrovenko
Администратор
Сообщения: 1724
Зарегистрирован: 12 окт 2014, 20:20
Местоположение: Санкт-Ленинград
Контактная информация:

Re: Самомодифицирующиеся вектора прерываний

Сообщение Dmitry Dubrovenko » 28 май 2020, 20:59

Максим В писал(а):Детерминизмом обработки событий

А, вот Вы о чём.
Хотя, мне кажется, в данном случае Вы слишком преувеличиваете его значение. :-)
Подпись

Максим В
Пользователь
Сообщения: 72
Зарегистрирован: 11 май 2020, 00:44

Re: Самомодифицирующиеся вектора прерываний

Сообщение Максим В » 29 май 2020, 01:26

Dmitry Dubrovenko писал(а):вот Вы о чём

Если продолжать на примере ДР8, то там 3 источника прерываний. Таймер опроса индикации - кнопок, таймер темпа, UART MIDI. Так вот, прерывание UART выполняется как критическая секция. Если выполнение обработчика UART долгое (а опрос клавиш работает очень быстро - килогерцы - для снятия дребезга контактов), то при этом, может произойти инверсия приоритетов (и, как следствие, изменение последовательности обработки событий). Поэтому, критическая секция UART минимизирована по времени выполнения.
Также, необходимо было гарантировать максимальную длину времени обработки UART (т.е. при любом раскладе время меньше либо равное этому максимальному значению), в противном случае, стэк обработчика прерываний кнопок-индикации (как наиболее частый, но с наименьшем приоритетом) столкнулся бы с рабочей областью.
Такой метод распределения прерываний называется RATE MONOTONIC.
https://en.wikipedia.org/wiki/Rate-monotonic_scheduling
Там много преимуществ, но также есть и ограничения. В основном на использование динамически рапределённой памяти, например. В DR8 стэк занимает меньше 128 байт. Отсутствие сторожевого таймера усложняет ситуацию, т.к. если что-то виснет, то "подхватить" машину уже нельзя.
Вот поэтому столько мучений и писанины про детерминизм :yes:

Аватара пользователя
Dmitry Dubrovenko
Администратор
Сообщения: 1724
Зарегистрирован: 12 окт 2014, 20:20
Местоположение: Санкт-Ленинград
Контактная информация:

Re: Самомодифицирующиеся вектора прерываний

Сообщение Dmitry Dubrovenko » 29 май 2020, 12:18

Максим В писал(а):столько мучений и писанины про детерминизм

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

Максим В
Пользователь
Сообщения: 72
Зарегистрирован: 11 май 2020, 00:44

Re: Самомодифицирующиеся вектора прерываний

Сообщение Максим В » 29 май 2020, 13:41

Dmitry Dubrovenko писал(а):Что произойдёт если вместо ожидаемого байта придёт совершенно другой?

Рассмотрим этот случай. Если у Вас есть конечный автомат обработки сообщений по MIDI, предположим, что он, например, принимает пакет NOTE ON, состоящий из нескольких байт. Первый байт - всегда байт статуса (MSB установлен в 1). После приёма и декодирования байта статуса, мы точно можем сказать, сколько байтов последует за ним, так как формат пакета известен. Т.е. после первого байта 9x (NOTE ON), всегда за ним последует байт данных с высотой тона, затем байт данных со скоростью нажатия. Если это не байт данных - достаточно проверить если бит 7 сброшен. Т.е. всегда апостериори после пересылки байта можно выбрать обработчик для следующего байта. Вот и получается, что следующее состояние конечного автомата разбора хранится не в переменной, а напрямую программируется в вектор прерывания, что значительно сокращает время реакции на прерывание.
Кст,в качестве метода по снижению цены, предлагал выкинуть 580ВВ51 из схемы. Т.к. на такой скорости он не нужен, процессор и сам справится. У 8085 в ДР8 битовый порт не используется (а жаль). У меня во всех изделиях (что в модемах, что в компьютерах) в 90х не было ни разу внешнего асинхронного адаптера до скоростей в 38Кбод, кроме ДР8 :-) Вот такая странная история... А метод перепрограммирования вектора значительно снижает накладные расходы ОС при интенсивном темпе прерываний (ATARI 2600 тому в пример, и как его кодируют)

Аватара пользователя
Dmitry Dubrovenko
Администратор
Сообщения: 1724
Зарегистрирован: 12 окт 2014, 20:20
Местоположение: Санкт-Ленинград
Контактная информация:

Re: Самомодифицирующиеся вектора прерываний

Сообщение Dmitry Dubrovenko » 29 май 2020, 14:38

Максим В писал(а):Первый байт - всегда байт статуса

Вообще-то не всегда, но сейчас это опустим.

Максим В писал(а):всегда апостериори после пересылки байта можно выбрать обработчик для следующего байта
Так вопрос-то в том, что будет, если этот "следующий байт" будет не тот, который ожидается (например, вместо Велосити придёт Статус)?
Подпись

Максим В
Пользователь
Сообщения: 72
Зарегистрирован: 11 май 2020, 00:44

Re: Самомодифицирующиеся вектора прерываний

Сообщение Максим В » 29 май 2020, 20:40

Dmitry Dubrovenko писал(а):что будет, если этот "следующий байт" будет не тот, который ожидается

Как уже отмечалось ранее, тест на 7ой бит никто не отменял (статус или данные), всегда можно добавить (проверка на 8085 или Z80 будет выглядить так:

Код: Выделить всё

; Аккумулятор содержит байт от UART
            and a  ; Проверяем на старший бит, а точнее на отрицательное число
            jp   m, Status_received     ; Переход если это статус (число отрицательное)
;.... продолжаем если это байт данных

Накладные расходы - 4 выборки команды или 2мкс

Хотя в DR8 MIDI Traffic Thinning (running status technique) не используется, поэтому реализовано напрямую - без проверок (как и в Yamaha DX7).

Аватара пользователя
Dmitry Dubrovenko
Администратор
Сообщения: 1724
Зарегистрирован: 12 окт 2014, 20:20
Местоположение: Санкт-Ленинград
Контактная информация:

Re: Самомодифицирующиеся вектора прерываний

Сообщение Dmitry Dubrovenko » 29 май 2020, 22:41

Максим В писал(а):Накладные расходы

Я собственно к этому всё и вёл. :yes:
Подпись


Вернуться в «Микропроцессоры и микроконтроллеры»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость

cron