В приложении тест приоритета Т-трапа для PDP-11

На процессоре 1801ВМ1 результаты такие:

Легко заметить, что обработчики внешних прерываний после команды WAIT запускаются один за другим, а ведь уже после возврата из обработчика первого внешнего прерывания - команда WAIT осталась "давно в прошлом". Следовательно у 1801ВМ1 приоритет Т-трапа ниже приоритета внешних прерываний.

Теста самого не видно. Без кода - не имеет смысла. Я вон показал разные варианты одним и тем же тестом с разными командами возврата.

---------- Post added at 01:18 ---------- Previous post was at 01:17 ----------

Обратим также внимание, что после возврата командой RTT никакой WAIT не выполнится пока не отработает IRQ.

---------- Post added at 01:19 ---------- Previous post was at 01:18 ----------

А, прогу не сразу заметил. Посмотрю.

---------- Post added at 01:23 ---------- Previous post was at 01:19 ----------

Не, не стану смотреть - там целая операционная система. Просто лень такую портянку читать. Сделай тест попроще где ничего лишнего :)

---------- Post added at 01:25 ---------- Previous post was at 01:23 ----------

Хотя по выводу который ты нарисовал 1:1 результат моих тестов - то есть T-бит синхронен и ни о каком другом прерывании перед ним речи не идет, а если до WAIT дело дошло - он блокирует T-бит.

Читать и понимать - не обязательно.

Нужно запустить и доложить результаты.

С этим проблемы есть ?

:)

Могу и запустить, только я как бы уже показал свой тест, а из результатов твоего видно 1:1 то же самое :)

Patron, результаты работы Вашего теста в эмуляторе UKNCBTL полностью совпадают с тем, что Вы привели (ну это Вы можете и сами попробовать). Но я писал выше, что приоритет T-разряда выше, чем приоритет VIRQ, так что может что-то в тесте не так.
Да, тест сложно написан, надо вникнуть, что бы разобраться, как он работает.

На самом деле там всё просто - чуть позже подробно объясню что там к чему.

Гдавный же вопрос в другом - как могут обработчики прерываний один за другим запускаться перед Т-трапом, если установлен бит Т ( а с момента выполнения команды WAIT прошло уже несколько десятков команд предыдущих обработчиков прерываний ) если приоритет обслуживаемых прерываний ниже приоритета Т-трапа..

---------- Post added at 21:38 ---------- Previous post was at 21:34 ----------

А вот в этом случае - похоже, что RTT действительно "даёт прерываниям шанс". Причём, если перед Т-Трапом "успело пролезть" хотя бы одно прерывание - они Т-трап уже вперёд не пропускают ( похоже что как раз по причине своего более высокого приоритета ).

Оно не может успеть или не успеть. Оно или есть в очереди и тогда возникнет или его нет в очереди и тогда не возникнет :)

А вот и нет..

Во всех трёх "заходах" тест начинается с того, что выполняет
И требует нажать клавишу (что одновременно гарантирует "накопление" запроса IRQ от таймера).

Таким образом, после выдачи команды RTI/RTT ( очищающей запрет прерываний в PSW ) - у нас каждый раз на шине сидят три запроса IRQ одновременно.

Но в первом случае, когда запрет прерываний в PSW очищается командой RTI - первым происходит Т-трап, а не какое-нибудь из внешних прерываний.

А уже обработчик Т-трапа завершается во всех трёх случаях командой RTT.

Да, тест немного кривой. А кривизна его в том, что при прерывании по вектору 100 (таймер), после обработки в программе не осуществляется выход по RTI, а передается управление операционной системе командой JMP @V100. Если уж ОС разрешит прерывания, то там и 60 и 64 вектора проскочат. У меня RT-11 с поддержкой таймера, т.е. поддержка запросов .CMKT и .MRKT. А вот если тест запустить в системе без поддержки (где две команды ADC на обработке прерывания таймера), то и результат может быть другой.