DRAKON.SU

Любопытно целесообразно ли ввести обозначение прерываний?
Например как на рисунке.
Переход по красной стрелке означает, что пока не выполнится следующий после нее оператор все другие процессы алгоритма останавливаются.

Почему не использовать просто комментарий...

Мне кажется, что приведенный пример неудачен, т.к. он немного нереален.
Прерывания реализуются аппаратно... приведен какой то особый случай?

Хотелось найти способ графического выделения прерываний ( в отличие от параллельных процессов р.в. выполняющихся не зависимо друг от друга).
Дракон алгоритм должен описывать и логику аппаратного вызова прерываний.

Блин, да сколько ж можно опять! Снова вокруг прерываний...

ЗАЧЕМ?! ВАМ?! ИХ?! РИСОВАТЬ НА ДРАКОНЕ?!

Обработчик АППАРАТНЫХ прерываний интересен постольку, поскольку он изменяет глобальные даннные (взводит флаги, кладёт принятый байт в буфер и т.п.). К основному алгоритму он не имеет никакого отношения (то есть его там как-либо изображать бессмысленно)!

Аппаратное прерывание может возникнуть после любой ПРОЦЕССОРНОЙ ИНСТРУКЦИИ, что опять-таки не имеет никакого отношения к Дракон-схеме основного алгоритма!

...Первая картинка кое-как может изображать функционирование ОС в целом или встроенного приложения, если под "Включить прерывания" скрывается а)power-on self-test, б)установка векторов прерываний, в)настройка периферии, г)инициализация данных приложения (буферы, очереди и т.п.).

...Вторая картинка не имеет отношения к реальности...

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

Например, у нас есть микроконтроллер с 6 аппаратными прерываниями. 1) Переполнение таймера 2) Изменение состояния любого вывода 3) Конец измерения АЦП и т.д.
Тогда если на второй картинке изобразить условия прерываний сверху вниз на шампуре, то получим точное графическое описание действий микроконтроллера при вызове нескольких прерываний в соответствии с их приоритетом

Ну так Ваши картинки ничего из перечисленного не показывают!

Что значит "изобразить условия прерываний"? Что за условия такие вообще?

Максимум, что можно сделать полезного, это разрисовать временную диаграмму (показав на ней один из бесконечного количества вариантов). Безусловно, временные диаграммы - наиполезнейшая штука. Но пользоваться ими надо также грамотно. И для этого Дракон не очень удобен, имхо. Это просто совсем другой тип диаграммы, с другими свойствами и областью применения.

Естественно. Межпроцессные события - это ввод-вывод с точки зрения каждого алгоритма. Неких сообщений. Условно говоря, сообщений. Значки "ввод" и "вывод" удобны для отображения любого типа событий, принимаемых снаружи процессом и инициируемых им наружу.

Вот примерно такая была задумка

Никак не пойму, это алгоритм работы процессора, что ли? Алгоритмически расписанный аппаратный полинг? Смысл? Или это какой хитрющий контроллер, где Вы всё по опросу делаете?

Да алгоритмически расписанный аппаратный... Ну не надо так надо

Честно говоря пункт "опрос вектора прерываний" не ясен с позиции русского языка В других пунктах тоже есть вопросы именно к языковой части.
Для меня остается загадкой пункт "Другое прерывание"...
Скажу честно из приведенной Дракон-схемы ничего, абсолютно ничего не ясно!
Еще раз подумайте, что Вы хотите описать!

Вопрос №2 Зачем новый элемент для прерывания? Он будет нужен только в том случае, если вы будете делать транслятор с Дракона в машинный язык. Иначе достаточно комментария.

А по большому, то что Вы привели, лучше всего описывается в логических схемах. Гляньте доки по однокристалкам или другим электронным компонентам, там все прекрасно и наглядно описано.

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

Ну что же,предложение снимается как не удачное, поскольку вызывает больше вопросов чем ответов

Надо, надо. Я, например, с Вами согласен.
+1.

Зачем?!

Чем не устраивают адекватные описания процессоров?

Или Вы собираетесь делать свой процессор и писать микрокод к нему на Драконе?

на защите диссертации как раз критиковали одного парня за то что на блок-схеме не изображены прерывания, а прога у него для микроконтроллера

Ну блин. профессура требует - надо выполнять. Но к сожалению еще и вдобавок не на драконе а на убогих гостовских блок-схемах, для рисования которых нет нормального софта, и приходится использовать MS Visio или autocad и т.п.

Крайне неудачный пример. Прерывания возникают в произвольный момент времени. Как это отображается на рисунке?
Предложения со смыслом проверки на наличие прерывания - бред. В каком месте проверка происходит? На каком уровне представления алгоритм(а,ов)?

Почитайте книжки по организации ядер ОС-ей. Практически во всех из них, контексты обслуживания прерываний ОТДЕЛЕНЫ от контекстов ядра и пользовательских процессов. Это ж - неспроста!
Практически прерывание (по смыслу) - зацикленный отдельный процесс, очередная итерация выполнения которого активизируется с некоторой фиксированной точки внешним событием.
Это как-то имеет отражение в Драконе? И Вообще - многозадачность? многопотоковость?

ЗЫ Практически и в микроконтроллерах - тот же подход. Хотя, там и нет явной "зацикленности" непосредственных обработчиков прерываний.
Очень интересно были сделаны обработчики прерываний в Модуле-2.

Ну, вариантов не очень много:

1. Использовать классический Дракон. Проект с прерываниями. Параллельные процессы.

2. Попытаться расширить Дракон некоторыми возможностями, не вызывающими в языке внутренних противоречий и сильного размножения правил работы с языком. Обработка ситуаций. Параллельные процессы.

Чего это он вдруг зацикленный?
Вообще-то, по определению он разовый, имеет начало и конец.

Некоторые микроконтроллеры позволяют сохранять контекст, тогда да, процесс МОЖНО представлять как зацикленный. Но не факт, что это целесообразно.