Пятница, 15.12.2017, 09:07
БК-0010.01. Повесть о настоящем компьютере
Главная Регистрация Вход
Приветствую Вас, Гость · RSS
Меню сайта
Категории каталога
Введение в руководство [2]
Введение [0]
Организация БК-0010 [1]
Раздел 1. Организация БК-0010
Работа с МСД [1]
Раздел 2. Работа с МСД
Системные регистры [1]
Раздел 3. Системные регистры
Системное ПО [1]
Раздел 4. Системное программное обеспечение БК-0010
Прерывания. Приоритет ЦП [1]
Раздел 5. Система прерываний БК-0010. Приоритет процессора
Командные прерывания [1]
Раздел 6. Командные прерывания
ЕМТ БК-0010 [1]
Раздел 7. командные прерывания ЕМТ БК-0010
Коды и ассемблер. Мнемокод. [1]
Раздел 8. Коды и ассемблер. Мнемокод. Формат команды
Способы адресации [1]
Раздел 9. Способы адресации
Команды процессора БК-0010 [1]
Раздел 10. Система команд процессора БК-0010
Псевдокоманды. Метки. Комментарии [1]
Раздел 11. Псевдокоманды ассемблера. Метки. Комментарии
Программирование на ассемблере [1]
Раздел 12. Программирование на ассемблере. Начало. Трансляция программ. Ошибки
Отладка программ [1]
Раздел 13. Отладка программ. Позиционно-независимое программирование. Компановка
Подпрограммы ПЗУ БК-0010 [1]
Раздел 14. Подпрограммы ПЗУ БК-0010
Системная область ОЗУ БК-0010 [1]
Раздел 15. Системная область ОЗУ БК-0010. Некоторые секретные сведения об авторе и МП-клубе
Повышение быстродействия БК-0010 [1]
Раздел 16. Вопросы повышения быстродействия БК-0010
Об использовании ПЗУ [1]
Раздел 17. Полезная подпрограмма. Об использовании ПЗУ
Загадочные регистры [1]
Раздел 18. Загадочные регистры
Штурм системной области [1]
Раздел 19. Продолжаем штурм системной области
Об автозапуске программ [1]
Раздел 20. Об автозапуске программ
Коварные программы [1]
Раздел 21. Коварные программы
Еще о системной области [1]
Раздел 22. О пользе плагиата, или еще о системной области
О псевдокомандах и компановке [1]
Раздел 23. Еще раз о псевдокомандах, метках и компановке
Тук-тук, кто в стеке живет? [1]
Раздел 24. Тук-тук, кто в стеке живет?
Фокал с позиций ассемблера [1]
Раздел 25. Взгляд на фокал с позиций ассемблера
Наш опрос
Оцените мой сайт
Всего ответов: 47
 Каталог статей
Главная » Статьи » Прерывания. Приоритет ЦП

Прерывания БК

Центральный процессор (ЦП) в ЭВМ ведет обработку поступающей информации. Для того, чтобы ввести эту информацию, есть 2 пути:
- процессор может сам время от времени опрашивать все каналы;
- канал может сам передавать процессору запрос на ввод информации.

Первый путь совершенно неэкономичен: действительно, клавиша ЭВМ, например, может быть нажата не более 10 раз в секунду. Но чтобы не возникло задержки, процессор должен опрашивать все клавиши по крайней мере 100 раз в секунду. В этом случае обработка поступающей информации будет сильно замедленна. То же относится к обслуживанию любых внешних устройств (ВУ).

В БК-0010 принят 2-й путь: ЦП ведет обработку информации непрерывно, а внешние по отношению к нему устройства выдают запросы на прерывание. Если процессор занят "важным делом", запрос игнорируется. Если же есть возможность обслужить ВУ, он прерывает обработку информации, обеспечивает запоминание промежуточных данных расчетов, адреса следующей команды программы и своего состояния (обычно, засылая всю эту информацию в стек), и переходит к обработке прерывания, т.е. начинает выполнять специальную программу, входящую в СПО. Такая программа обязательно должна заканчиваться командой выхода из прерывания, по которой процессор восстанавливает все данные и продолжает работу с программой, если таковая имеется, либо переходит в режим ожидания.

Под "работой с программой" не следует понимать обязательно какие-либо расчеты. Когда вы просто нажимаете одну клавишу БК, процессор выполняет при этом программу из многих сотен команд. Если в этот момент поступит запрос на прерывание (нажата еще одна клавиша!), Процессор "заметит" его только обслужив предыдущее нажатие и выдав на экран символ. Мы не замечаем задержки только потому, что ЦП БК выполняет до 300000 команд в сек, фактически же она есть. Например, выполнение команды при нажатии клавиш НР+РП, требует времени, заметного человеку. Если вы успеете в это время нажать клавишу с символом, то заметите, что символ на экране и звуковой сигнал последуют с задержкой: во время выполнения таких "элементарных" команд прерывания запрещены.

Откуда же ЦП "знает", что нужно сделать для обслуживания данного прерывания? Эти сведения содержат так называемые вектора прерываний.
Вектор прерывания - это записанные в системной области 2 слова: первое содержит адресс, по которому должно быть передано управление, а второй - слово состояния процессора, установленное для обработки данного прерывания.
Слово состояния, в частности, определяет, разрешаются ли при обработке данного прерывания еще прерывания, и каков на это время приоритет ЦП.
С первым случаем все ясно: если характер работы по обслуживанию ВУ таков, что процессору нельзя оторваться от него (например, при работе с магнитофоном, ведь лента движется, и часть информации будет потеряна), то прерывания должны быть запрещены.
Но что означает второе? Приоритет процессора означает, что разрешены не все прерывания, а только от устройств, обладающих большим приоритетом, чем установленный в данный момент для процессора. У ЦП БК-0010 предусмотрено 8 уровней приоритета, а за каждым из стандартных ВУ БК закреплен свой определенный приоритет. Мы не можем более подробно остановиться на этом вопросе, и отсылаем желающих к специальной литературе.

Откуда берутся в системной области вектора прерываний? Они заранее записаны в ПЗУ и переносятся в ОЗУ вместе с другой информацией при запуске системы. Каждое внешнее устройство имеет свой вектор, и при получении запроса на прерывание ЦП определяет, от какого устройства последовал запрос, и уже "знает" адрес, по которому записан данный вектор прерывания.

В БК-0010 под вектора прерываний отведена зона адресов в системной области, адреса 0...276. Как видим, в этой зоне можно разместить до 48д векторов прерываний, считая по 2 слова на вектор. Но столько векторов в БК-0010 не нужно, т.к. каждый из них должен быть поддержан соответствующей аппаратурой (например, специальным контроллером прерываний), которой у БК просто нет. Поэтому использованы только некоторые ячейки выделенной под вектора зоны ОЗУ, а другие в этой зоне или не используются, или используются для других целей.

Вектора прерываний БК-0010.
1. Адрес: 000004. Зависание при передаче данных по каналу или при нажатии клавиши стоп.
2. Адрес: 000010. Резервный код.
3. Адрес: 000014. Прерывание по Т-разряду (пошаговый режим).
4. Адрес: 000020. Прерывание по команде IOT (только в ОС).
5. Адрес: 000024. Прерывание по аварии сетевого питания.
6. Адрес: 000030. Прерывание по команде ЕМТ.
7. Адрес: 000034. Прерывание по команде TRAP.
8. Адрес: 000060. Прерывание от клавиатуры.
9. Адрес: 000100. Прерывание IRQ2 (по таймеру).
10. Адрес: 000274. Прерывание от клавиатуры, нижний регистр.

Даже этот ограниченный список не весь нам нужен.
Например, прерывания по вектору 14 (принято обозначать вектора адресом, по которому записано 1-е слово вектора) используются только в отладчиках, а по вектору 20 - только в операционных системах.
Автор далек от мысли, что его читатели сразу же возьмутся за разработку программ отладки или ОС, таким не нужно данное руководство!
Вектор 24 в БК поддержан программно (т.е. есть программа ого обработки, и даже сообщение "сбой питания"), но аппаратной поддержки не имеет (т.е. нет электронного устройства, подающего сигнал прерывания при падении питающего напряжения меньше допустимого).
Равным образом не интересуют нас вектора 60 и 274 - прерывания от клавиатуры, нужные только самой БК - ведь мы не собираемся пока менять знакогенератор для введения на БК-0010 китайского шрифта! Впрочем, не исключено их использование для других целей, например, можно ввести по нижнему регистру спецсимволы, но это отдельная задача.
Вектор 100 программно поддержан только в фокале, ему отвечает функция таймера FCLK(), почему-то не описанная в руководстве по фокалу. В МСД вектор не имеет СПО, но тем не менее он нам очень интересен, так как позволяет, путем составления несложных программ, получить счетчик внешних событий - таймер, счетчик магнитофона, измерительный прибор, и т.п. Словом, это канал связи БК с внешним миром, правда, уступающий по возможностям порту ввода-вывода, но зато доступный по прерываниям.
Вектор 4 используется программистами очень широко для изменения действия клавиши стоп, особенно в системных программах - языках программирования, отладчиках и т.п., а также в играх, с целью защиты от несанкционированного останова.
Но особенно нас интересуют вектора 30 и 34 - ЕМТ и TRAP. Это командные прерывания, т.е. Возможность прервать работу процессора из программы. Их мы и рассмотрим далее более подробно. Но перед тем разберем общую задачу изменения любого вектора прерывания для своих целей.

Остановимся в качестве примера на векторе 4, как наиболее простом.
В исходном состоянии вектор прерывания по клавише стоп - вектор 4 - имеет вид: 160722; 000000.
Это значит, что при нажатии на клавишу стоп управление передается на программу обслуживания прерывания, записанную в Т-ПЗУ по адресу 160722. Приоритет процессора при этом устанавливается нулевой, т.е. будет обслужено любое прерывание. Желающие с помощью диассемблера могут просмотреть эту программу и разобраться в том, что при этом делается.
Для нас же важно лишь то, что при этом программа пользователя прерывается в произвольный момент, возможно тогда, когда это делать нельзя. Как избежать этой неприятности? Прежде всего, мы должны ясно представить, что запретить прерывание по клавише стоп вообще мы не можем: при нажатии на клавишу стоп все равно будет аппаратно выработан сигнал, заставляющий процессор перейти по адресу, заданному в ячейке 000004.
Значит, придется изменить этот адрес. Но задать его любым тоже нельзя. Нужно вначале записать по этому адресу нашу программу обработки прерывания.

Что она будет делать?
Прежде всего, она должна восстановить прежний вектор 4, если мы не хотим оказаться в ситуации, когда из нашей игры, например, нет иного выхода, кроме системного сброса. Значит, одной из команд будет запись числа 160722 по адресу 000004 (заметим, что это не обязательно, если из программы предусмотрен иной выход, но это сложнее).
Затем, видимо, нужна задержка до нажатия любой клавиши, чтобы, нажав в это время стоп, выйти из программы, если это нужно.
Наконец, если нажата иная клавиша, а не стоп, нужно передать управление на нужный участок программы, предварительно записав вновь наш вектор 4. Но мы забыли очень существенный момент: мы должны когда-нибудь закончить обработку прерывания, иначе при каждом следующем прерывании по стоп стек будет все более заполняться, и рано или поздно переполнится, и это - катастрофа, т.к. БК перестанет работать, нужен системный сброс!
Куда поместить эту команду возврата из прерывания? Конечно, в нашу специальную программу обработки прерывания, до команды передачи управления по адресу. Но тогда передача управления никогда не осуществится, ибо после возврата из прерывания до передачи управления дело не дойдет.
Тут что-то не так! Как же быть на практике?
Возможны разные решения:

  • либо поместить вместо команды возврата команду стоп (тогда программа всегда будет останавливаться по клавише стоп, как обычно. Но перед тем мы можем "навести порядок", чтобы избежать неприятностей),
  • либо принудительно восстановить стек, т.е. Записать в R6 то число, которое там было перед пуском программы,
  • либо примириться с возможностью отказа программы после многократных прерываний,
  • либо, учитывая, что по команде возврата ЦП извлекает адрес возврата из стека, заменить этот адрес так, чтобы переход произошел в нужное место программы.
Читатели должны учесть, что этот пример рассмотрен лишь в самых общих чертах, вариантов же возможно множество. Кроме того, только знание языка ассемблера поможет перевести эти общие рассуждения в конкретные команды.

Категория: Прерывания. Приоритет ЦП | Автор: ЗАЛЬЦМАН Ю.А., МП-КЛУБ, г.АЛМА-АТА
Просмотров: 693 | Рейтинг: 0.0/0 |

Всего комментариев: 0
Имя *:
Email *:
Код *:
Используются технологии uCoz
Форма входа

Поиск
Друзья сайта
Статистика