Особенности процессоров и устройств архитектуры PDP-11. Тесты. Диагностика.

[form]

Подозреваю, что достаточно хороший пример всевозможных гадостей с прерываниями - контроллер WD который свои прерывания запускает играясь с сигналами питания CPU

---------- Post added at 02:56 ---------- Previous post was at 02:55 ----------

Правда там скорее всего кроме потерь ничего не грозит.

[Advertiser]

[Alex_K]

Подозреваю, что достаточно хороший пример всевозможных гадостей с прерываниями - контроллер WD который свои прерывания запускает играясь с сигналами питания CPU

Правда там скорее всего кроме потерь ничего не грозит.

Потери АВП при приеме бывают только при векторном прерывании по сигналу VIRQ. Прерывание по аварии источника питания (вектор 24) для процессора внутреннее, вектор он получает из блока констант. К тому же сбросить это прерывание можно только двумя способами - удовлетворить его или сбросить процессор по сигналу DCLO. По команде RESET этот запрос не сбрасывается.

[form]

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

[Patron]

Titus, как я понял, имел ввиду другое - если прерывания разрешили (по MTPS #0, или после RTI), а во время исполнения этой команды устройство сняло запрос на прерывание.

Мы это всё (и даже гораздо больше) тестировали начиная с середины 5-й страницы этой темы и дальше. Общий вывод такой - если запрос IRQ был выставлен не во время предыдущей команды - проблем быть не может. Разрешение/запрет прерываний никак на выставление запросов IRQ не влияет.

Совершенно всё равно, какая команда была исполнена перед BIC #100, @#TPS. Если запрос IRQ был выставлен именно тогда и прерывания сейчас разрешены - будет потеря вектора.

[form]

BIC #100, @#TPS[

Завтра попробую с ВМ3 кого-нибудь попросить проверить...

[Alex_K]

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

Нет не вызывает. Прерывание по сбою питания высокоприоритетное и в режиме USER немаскируемое. Ведь все остальные устройства также будут требовать прерывания по линии VIRQ. По приоритету сначала исполнится сбой питания, а уж затем дойдет дело до VIRQ.

[Patron]

Вот ещё результаты тестов на эту тему:

BIS #100,@#TTPS
MTPS #340
NOP
MTPS #0
>>> Interrupt <<<
NOP

BIS #100,@#TTPS
MTPS #340
BIC #100,@#TTPS
MTPS #0
NOP

BIS #100,@#TTPS
MTPS #340
MTPS #0
>>> Interrupt <<<
BIC #100,@#TTPS

[Alex_K]

Вот ещё результаты тестов на эту тему:

BIS #100,@#TTPS
MTPS #340
NOP
MTPS #0
>>> Interrupt <<<
NOP

BIS #100,@#TTPS
MTPS #340
BIC #100,@#TTPS
MTPS #0
NOP

BIS #100,@#TTPS
MTPS #340
MTPS #0
>>> Interrupt <<<
BIC #100,@#TTPS

Ну в данных примерах и не должна возникнуть ошибка приема АВП.

[Patron]

Или Titus имел в виду такие "коварные" устройства, которые сами снимают IRQ без "внешней" причины в виде команды процессора ( типа RESET или BIC #100,@#TPS ). Но я про такие устройства ничего не знаю. Бывает такое у реальных устройств ?

[form]

Или Titus имел в виду такие "коварные" устройства, которые сами снимают IRQ без "внешней" причины в виде команды процессора ( типа RESET или BIC #100,@#TPS ). Но я про такие устройства ничего не знаю. Бывает такое у реальных устройств ?

UNIBUSные возможно есть - встречал в описаниях что-то про такое.

---------- Post added at 03:18 ---------- Previous post was at 03:15 ----------

Вот кстати что в доке по KDJ11 написано (может я уже приводил):

1.3.5 Interrupt Vector Timeouts
An interrupt vector timeout occurs if the BRPLY L bus signal is not asserted within 10 μseconds after the KDJ11-B acknowledges an interrupt by asserting the BIAK L bus signal. The timeout is ignored by the KDJ11-B and it continues as if the interrupt request did not occur. In a Unibus system, the KDJ11-B does not time out, but relies on the Unibus adapter module to assert the PMI timeout signal.