Уважаемые участники! Как я понимаю, икону Вставка можно привлечь также для визуализации прерываний т.е. вызова другого визуала (обработчика) не тогда, когда это задано маршрутом сочиняемого визуала (назовём его целевым), а тогда, когда происходит обрабатываемое событие. В программировании я понимаю мало, но имхо, для решения этой задачи нужно привлечь какое-то представление об исполнителе алгоритма. Вот как можно, мне кажется, рассудить. Формальный исполнитель (машина) работает по командному циклу, который также есть алгоритм, только "зашитый" в логику процессора (схемы устройства управления, т.е. обычно - вентили комбинационной части + кодировка взаимосвязанной памяти микропрограмм). Типичный алгоритм командного цикла изображался как блок-схема, например, в учебнике: Каган Б.М. ЭВМ и системы. - М.:Энергоатомиздат, 1991 (см. вложение). Если выделить то, что нам нужно, то получим тело командного цикла как блок, где целевому оператору (в данном случае - микрооперациям, реализующим назначение машинной команды) предшествует ветвление по вопросу "есть ли (необработанные) сигналы прерываний ?". На вопрос отвечает система прерываний исполнителя (проверяя, есть ли несброшенные/незамаскированные сигналы о событиях). Если нет, то выходим на ненагруженную вертикаль; если да - в другой вертикали вызываем алгоритм-обработчик (головной) как вставку. При его визуализации для исполнителя-машины нужно учесть все особенности её системы прерываний: как обрабатываются вложенные прерывания, как кодируются и хранятся сигналы прерываний и т.п. Конечный итог - вызов алгоритма реакции на конкретное прерывание, т.е. множественное ветвление по коду прерывания, где нагрузка каждой ветви - икона Вставка с именем алгоритма реакции (его машинный эквивалент - подпрограмма обработки прерывания). Полученная схема обработчика будет доступна из каждого целевого алгоритма, сочиняемого для данного исполнителя; при этом некоторые реакции сочинитель может визуализировать заново (для подмены стандартных на время выполнения целевого алгоритма). Временной аспект обработки также зависит от архитектуры машины: есть техническая возможность запустить обработчик отдельно - показываем его как процесс, параллельный исполнению целевого алгоритма; можно запустить отдельно только некоторые реакции (скажем, как программы каналов) - показываем только их как параллельные; и т.д. (хотя здесь детали я, возможно, трактую приблизительно). Затем выполняем оператор, предписанный целевой дракон-схемой. Для немашинного исполнителя (обычно человека) прерывание также возможно; тогда "систему прерываний" описываем неформально. Получается просто, что на каждом операторе возможен контроль наступления внешних событий: разбили один оператор на несколько - стало столько же контрольных точек; в пределе какие-то части этого алгоритма поручаются машине, детализируются до уровня "одна икона - одна машинная команда" и приходим к тому, с чего начали эти рассуждения - реакции на прерывания в каждом командном цикле процессора (разумеется, если он имеет систему прерываний).
Что получается применительно к стандарту ДРАКОНа? Идя "в лоб", нужно иметь версию каждой иконы (кроме, конечно, Заголовок, Конец, Имя ветки и модификаторов) под прерывание (можно, как предлагалось, добавить параллельные линии контура по бокам); если мы допускаем возможность прерываний - все прерываемые иконы в целевой схеме должны показываться в такой версии, детально (для подразумеваемого исполнителя) каждая такая икона представляется визуалом своего командного цикла и должен существовать (быть сочинён для подразумеваемого исполнителя) головной обработчик и вставки-реакции для него (инвариантные к иконе), если не учитываем прерываний - схема рисуется как обычно. В некотором смысле это обсуждавшаяся в данной теме комбинация вставки с другими иконами (упоминалась Развилка), только понимаемая иначе - как сокрытие за иконой (прерываемой) алгоритма её выполнения в зависимости от внешнего события (а м.б. и невыполнение иногда надо реализовать?; хотя обычно прерывание всё-таки подразумевает, что прерванный процесс когда-то продолжится с точки прерывания; или какая-то вставка-реакция в каком-то из своих маршрутов командует перезагрузку системы, и тогда просто всё сначала, включая отслеживание событий прерывания). Кроме того, если целевой оператор - это нешампур-икона (развилка, шапка переключателя), то и тело командного цикла - это нешампур-блок (ведущий к разным операторам целевой дракон-схемы). Чтобы это отразить без нарушения дракон-синтаксиса, придётся показать командное представление прерывания прямо на целевой схеме (вместо командного цикла добавив перед каждым оператором вышеописанное ветвление) , или на этот случай доопределить синтаксис для отражения в схеме командного цикла возврата на разные операторы (м.б. на каждый выход икона Конец, по которой надо читателю/исполнителю вернуться на нужный маршрут целевой схемы?); или рассматривать в командном цикле целевую икону как вершину-переменную, но всё это чересчур головоломно, по-моему... проще в алфавит целевой схемы ввести модификатор прерываемой иконы (рисуемой тогда уже без всяких версий), скажем, присоединяемую слева икону Вставка с именем, допустим, "Обработать прерывание", а её содержание и будет составлять развилка по упомянутому вопросу.
Пожалуй, в "сухом остатке" от рассмотренного будет два приемлемых способа визуализации прерываний: 1. В целевую схему перед каждой прерываемой иконой добавлять вставку-вызов визуала прерывания. 2. Добавлять к каждой прерываемой иконе модификатор-указатель на визуал прерывания (допустим, ту же икону Вставка, присоединённую справа - т.к. слева присоединяется икона Синхронизатор). В обоих случаях под телом визуала прерывания мы понимаем предшествующую прерываемой иконе развилку, проверяющую прерывания и в случае их наличия - вызывающую визуал-обработчик, который в свою очередь запускает визуал реакции на наличествующее прерывание. Прерывание можно отразить на любом этапе визуализации; при этом имеем в виду «иконный цикл» как расширение командного цикла на визуальный оператор, произвольно укрупнённый по сравнению с машинной командой и допускающий реакцию исполнителя (в т.ч. человека; возможно, на этом уровне рассмотрения неформально описанную) на события из определённого круга, принятого во внимание сочинителем целевого визуала. Предшествующие рассуждения не сокращаю. Прошу прощения за отсутствие рисунков. Есть здесь рациональное зерно?
Вложения: |
Kagan - EVM - ComCycle.png [ 41.93 КБ | Просмотров: 12840 ]
|
|