Процессоры. Система команд ЭВМ. Устройства управления. Организация внутрипроцессорных систем ввода-вывода информации, страница 16

Приемное устройство может «отвлекаться», т.е. быть не всегда готовым к приему информации.

Период передачи  является переменным, т.к. зависит от конкретной линии связи и характеристики устройств-участников передачи.

Рис. 3.3.3.3. Схематичное изображение и временная диаграмма асинхронного обмена (с квитированием).

,

где t – время передачи очередного нового состояния данных (величина переменная для разных систем).

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

<143>

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

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

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

<144>

3.3.3.2. Последовательность событий при прерываниях.

Каждое ПерУ, подключенное к процессору через систему прерывания, может посылать в процессор сигнал запроса прерывания (ЗПр). Это просьба об обслуживании, требование реакции процессора, иногда – немедленной.

Сигнал ЗПр появляется асинхронно к действиям процессора, управлять фактом его появления программа, выполняемая процессором не может. Выхода только два:

1)  игнорировать ЗПр;

2)  временно приостановить текущую программу, перейти к другой программе (подпрограмме) обслуживания ЗПр, обслужить и вновь вернуться к выполнению прерванной программы.

Остановимся пока на втором варианте действий.

Итак, запрос принят не проигнорирован. Программе обслуживания ПерУ почти наверняка потребуются внутренние регистры АУ, СОЗУ, а значит их содержимое будет изменено. (Конечно, возможна ситуация, когда обмен с ПерУ не задевает ход текущего процесса в АУ, а касается только некоторой зоны памяти. Здесь не совсем прерывание, а кроме того, возможен непрограммный путь!). Итак, «..изменено…»  Но прерываемая программа ничем не провинилась и должна по окончании обслуживания ПерУ выполняться так, будто никакого прерывания ее не было. Она уже пострадала тем, что мы удлинили время ее выполнения. Следовательно, перед обслуживанием прерывания содержимое всех регистров, которые потребуются ему, надо временно запомнить, например -  в ОЗУ, а еще удобнее в стековой памяти, с последующим возвратом.

 Теперь о возможном игнорировании ЗПр.  ЗПр только и означает, что процессор должен делать нечто иное, очень важное. Но ведь и выполняемая программа полностью или в какой-либо своей части может быть очень важна, не допускает промедления. Выход, возможно, – на время исключить ЗПр из рассмотрения, игнорировать.

<145>

Строго рассуждая, в момент «рассмотрения заявления» на прерывание может возникнуть ещё одна проблема: а если периферийных устройств несколько и все они способны послать свой ЗПр? Надо выяснить, кто обращается и по ходу работы установить, насколько это срочно.

Вырисовывается такая картина:

Рис. 3.3.3.4.

Существуют нюансы:

а) все операции по организации прерываний могут быть реализованы только командами, в том числе возможны и команды запрета/разрешения прерывания;