Файл: Оперативные графические системы в автоматизации проектирования..pdf

Ниже рассматриваются принципы построения н алго­ ритмы работы некоторых частей программного обеспе­ чения ОГС.

Важной задачей управления при работе в режиме диалога является согласование двух асинхронных про­ цессов: вычислений и обслуживания запросов пользова­ теля: Возможны два состояния ОГС: счет по программе, ожидание ввода с пульта.

Ожидание может возникнуть после завершения сче­ та по одной из программ до поступления команды поль­ зователя на выполнение очередной программы, а также если необходим ввод фактических параметров выпол­ няемой программы с пульта пользователя.

Синхронизацию процессов обеспечивает программный блок связи ОГС с пользователем — монитор и ряд ап­ паратурных блоков. Основными сигналами для управле­ ния и обмена являются требование ввода от программы; запрос ввода пульта, указывающий на готовность информации к вводу; команда ввода, вызывающая пере­ дачу информации от пульта. Рассмотрим некоторые способы синхронизации.

Рис. 5.2. Синхронное обслуживание запросов. Однопрограммпын процессор

138

Синхронное обслуживание запросов. При использова­ нии простого однолрограммного процессора монитор «встраивают» в вычислительную программу. По требо­ ванию ввода команда анализа монитора проверяет нали­ чие запроса (рис. 5.2). При этом возможны такие ситуа­ ции: запрос поступил раньше команды анализа; запрос поступил позже команды анализа; запрос и команда поступили одновременно.

В первом случае (ранний запрос) сигнал запроса ус­ танавливает указатель запроса У3: = 1, т. е. запоминает­ ся до момента анализа указателя программой. По уста­ новленному в 1 указателю производится обмен с пуль­ том, и указатель гасится. Во втором случае (поздний запрос) отсутствие запроса вызывает останов процессора

Рис. 5.3. Синхронное обслуживание запросов. Многопрограммный процессор

139

ii ожидание. Сигнал запроса инициирует продолжение программы с команды ввода. В момент анализа указа­ теля должен быть аппаратурпо задержан сигнал запро­ са, чтобы избежать «зависания». Таким образом, случаи одновременного поступления запроса сводится к случаю

позднего запроса.

Во время ожидания процессор не используется диало­ говой программой, и его целесообразно загрузить другп-

Рис'. 5.4. Асинхронное облуживамне запросов

мп вычислениями. В мультипрограммной системе — это фоновые задачнББлок-обмена монитора в такой системе может выполняться на прерывающей ветви программы как часть супервизора (рис. 5.3). При выполнении блока обмена анализируется, был ли запрос. При его отсутст­ вии (Пр3 = 0) происходит обращение к супервизору си­ стемы с макрокомандой «Ждать». После этого пронсхо-

140

днт прерывание диалоговой программы и запускается фоновая задача. Поздний запрос вызывает возврат управления монитору, который обменивается с пультом и гаопт признак запроса (Пр3: = 0), после чего продолжа­ ется выполнение диалоговой пропраммы. Ранний запрос с помощью супервизора устанавливает признак (ПрЗ: = —1). Об,мен производится в момент, определяемый диа­ логовой программой. Запрос, поступивший во время работы супервизора или монитора, задерживается аппа­ ратурою (запоминается) или игнорируется и не вызывает их прерывания.

Асинхронное обслуживание запросов. Наличие аппа­ ратурно-программной системы прерываний позволяет вводить с пульта информацию непосредственно по запро­ су пользователя, асинхронно по отношению к выполняе­ мой программе. При этом представляются дополнитель­ ные по сравнению с синхронным -обслуживанием возмож­ ности оперативного изменения пользователем значений переменных в программе непосредственно в процессе счета по ней; изменения точки возврата в прерванную программу по результатам анализа введенной информа­ ции на прерывающей ветви. Асинхронное обслуживание запросов осуществляет специальный блок обмена мони­ тора, получающий управление в результате прерывания по запросу пульта (рис. 5.4).

5.3. ПРОГРАММИРОВАНИЕ АЛГОРИТМОВ УПРАВЛЕНИЯ

граммы. Она может содержать тип запроса, идентифи­ катор устройства ввода, слово состояния прерванной пропраммы и т. п. Эту информацию операционная система передает программе обработки запросов. Основные раз­ личия в схемах обработки запросов определяются мето­ дами описания и средствами вызова процедур обработки.

141-

Эти процедуры могут вызываться двумя способами: син­ хронно или асинхронно по отношению к текущей про­ грамме, как это было описано выше.

Рассмотрим способы описания процедур обработки запросов с помощью процедурно-ориентированных язы­ ков высокого уровня.

Использование оператора условного перехода IF в языках FORTRAN, ALGOL, PL/1. При получении запроса от пульта система должна ввести и записать некоторую информацию (тип вводного устройства, инициировавше­ го запрос; идентификатор элемента изображения для светового пера или код нажатой клавиши для функцио­ нальной клавиатуры и т. п.). При этом система присваи­ вает значение TRUE (истина) булевской переменной типа устройства LIGHTPEN, K.EY и т. п. и значение соответ­

GOTO LABEL2 пли IF KEY THEN CALL ROUTINE уп­ равление передается на блок с указанной меткой LABEL или к соответствующей процедуре ROUTINE, которые выполняют действия по обслуживанию запроса. Это при­ мер синхронной обработки.

Табличный метод определяет переходы в программе, соответствующие каждому типу запроса. Таблица пере­ ходов реализуется с помощью специальной программы либо путем расширения языка за счет введения соответ­ ствующих операторов. При использовании подпрограммы она содержит в качестве параметров список пар, связы­ вающих тип запроса (atlnlype) с соответствующей про­ цедурой (routine). Обращение к такой подпрограмме имеет вид: CALL TABLE (attntype 1, routine 1; ...; attntype n, routine п). Обычно используется характерный для FORTRAN-систем метод синхронного обслуживания. Запрос запоминается операционной системой. В дальней­ шем программа в ходе выполнения проверяет наличие запроса. Если был запрос, то с помощью подпрограммы TABLE генерируется вызов процедуры, соответствующей типу запроса. При отсутствии запроса выполнение про­ граммы может быть задержано до его получения. Таб­ личный метод применим и для асинхронного обслужива­ ния, если система обеспечивает асинхронный вызов под­

142

программ. Тогда переход к соответствующей процедуре произойдет немедленно при получении запроса.

Использование оператора ON. Оператор ON в PL/1 предназначен для определения операций, которые долж­ ны быть выполнены при возникновении сбойных ситуа­ ций, вызывающих прерывание: переполнение, нулевой делитель и т. п. [6]. Язык может быть расширен вклю­ чением в список этих ситуаций прерываний от графиче­ ского пульта [7]. Тогда процедура обработки запроса светового пера будет иметь вид:

ON LIGHTPEN BEGIN

оператор 1

оператор

END.

Метод В. Р. Сазерленда и В. М. Ньюмена. Приведен­ ные выше методы требуют описания всех возможных в данном состоянии программы типов запросов и процедур их обслуживания (так, если разрешен только один тип запроса, то необходимо, кроме его описания, привести

«тип запроса — переход» только для разрешенных типов запросов. Таблица состояний и причин переходов пред­ ставляется операторами вида: ОПЕРАТОР ((тип запроса 1, метка состояния 1), ... (тип запроса п, метка состояния п), ОЖИДАНИЕ/ЦИКЛ)) для каждого состояния.

При использовании ЦИКЛа циклически выполняются операторы последующей процедуры до получения запро­ са. Если в ОПЕРАТОРе задан режим ОЖИДАНИЕ, вы­ полнение программы блокируется до получения запроса, после чего программа переходит в соответствующее со­ стояние. Такое описание может использоваться как для синхронной, так и для асинхронной обработки.

В качестве примера реализации программного управ­ ления диалогом в ОГС рассмотрим алгоритмы работы блоков монитора, обеспечивающих синхронизацию про­ цессов ввода и вычислений в ОГС на базе мультипро­ граммной ЭВМ «Мпнск-32» [9].

143

Для ввода информации используется электромехани­ ческий планшет (УВГИ), устройство управления свето­ вым маркером (М), алфавитно-цифровая клавиатура (АЦК) и программируемая функциональная клавиатура (ПФК.) с подсветами. Вместе с оперативным устройст­ вом отображения перечисленные устройства составляют пульт, который рассматривается как одно активное внеш­ нее устройство по отношению к ЭВМ «Мипск-32». Подго-

Рис. 5.5. Структурная схема вводной части пульта

товленная к вводу информация хранится на буферных регистрах вводных устройств. Требование ввода иниции­ руется устройствами при нажатии пользователем на одну из клавиш или сигналом совпадения в режиме указания элемента световым маркером. При этом в ЭВМ поступает сигнал «запрос прерывания», служащий причиной пре­ рывания на 3-й уровень программы «Диспетчер». Одно­ временно в специальный регистр символа состояния (РгСС) пульта заносится код, идентифицирующий источник вводимой информации (рис 5.5). «Диспетчер»

144

передает управление на прерывающую ветвь и затем на блок обмена монитора. В блоке обмена введенный сим­ вол состояния (запросы пульта на ввод) сравнивается с таблицей требований ввода от расчетных программ, и при необходимости вводится, перекодируется и корректирует­ ся необходимая информация с пульта (рис. 5.6). Затем

спомощью «Диспетчера» управление возвращается в прерванную программу. Источники информации и соот­ ветствующие нм коды РгСС и определители команд вво­ да приведены в табл. 3. При реализации программ актив­ ного ввода существенными оказались вопросы согласова­ ния во времени моментов возможного получения запросов

спроцессом их обработки. В частности, необходимо из­ бежать преждевременного повторного входа в прерываю­ щую ветвь и в блок обмена.

Процесс проектирования в режиме диалога состоит из последовательности выполняемых процедур и выборов пользователем очередной процедуры. Команды пользова­ теля на выполнение определенных действий принимает и расшифровывает блок монитора — интерпретатор ко­ мандного языка. Он запускает программы расчетов и обслуживание процедуры, а также выдает сообщения о состоянии вычислительного процесса на пульт пользова­ теля. Выполнение программ заканчивается выводом ре­ зультатов на пульт и передачей управления монитору. Асинхронное обслуживание запросов позволяет по ко­ манде пульта прервать выполнение расчетов и перейти в состояние ожидания команды интерпретатора. При реа­ лизации интерпретатора командного языка необходимо стремиться к созданию процедур, упрощающих описание

запроса