PDPT3A на УКНЦ.
PDPT3A на УКНЦ.
Если ты имеешь в виду, что RTT (которая устанавливает T-бит) передает управление на RTI/RTT которая его очищает, то да. Аналогично - если это RTI/RTT прерывания которое произошло перед T-бит трапом. Если же речь про сам хандлер Т-бита то нет - если он очистит, то это насовсем.
Цитата:
Сообщение от form
У 11/80 Т-трап после второго RTT не возникает.Код:102 000350 012746 000000 Mov #0, -(SP)
103 000354 012746 000374' Mov #LLL2a,-(SP)
104
105 000360 012746 000020 Mov #20, -(SP)
106 000364 012746 000372' Mov #LLL2, -(SP)
107 000370 000006 RTT
108 000372 LLL2:
109 000372 000006 RTT
110 000374 LLL2a:
111 000374 Nop
112 000376 Nop
Здесь ВМ1 и ВМ2 ведут себя принципиально иначе.
Все-таки предлагаю тестировать вчистую без системы. А также не надеяться, что вывод в буфер быстрый. DEC советует не больше 10 чтоли инструкций выполнять на интеррупт лежеле, а дальше - форк :)
Из системных вызовов я выполняю только EMT 350.Цитата:
Сообщение от form
Обработчики всех прерываний в начале программы переключаются на внутренние.
...
Тест PDP-11 Interrupts Test #4 ищет ответ на вопрос, что случится, если выполнить подряд следующие команды:
На ДВК-1 результат такой:Код:BiS #100, @#TTPS
BiC #100, @#TTPS
Для продолжения работы программы после вылета в пульт - на ДВК нужно нажать <P>.Код:.RU PDPT4
PDP-11 Interrupts Test #4
BIS #100,@#TTPS
BIC #100,@#TTPS
001130
@M000011
@P
Program completed.
Команда пульта <M> докладывает, что произошло прерывание зависания при приёме вектора прерывания.
Системные вызовы непричем.Цитата:
Сообщение от Patron
Что никак не мешает прерываниям незапланированным возникать :)Цитата:
Сообщение от Patron
В любом случае чем меньше неизвестных тем лучше.
Собственно этого и следовало ожидать. Реальная УКНЦ.Цитата:
Сообщение от Patron
Код:.RU PDPT4
PDP-11 Interrupts Test #4
BIS #100,@#TTPS
BIC #100,@#TTPS
Program completed.
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #4
BIS #100,@#TTPS
BIC #100,@#TTPS
Program completed.
.
В E11 для разнообразия.
Это только первый этап - дальше интереснее.Цитата:
Сообщение от Alex_K
Например, мало кто знает, что если при обработке прерывания происходит TrapTo4 из-за плохого стека, то до запроса вектора прерывания дело не доходит, а значит и реакция процессора будет другой.
Если же стек при этом указывает на что-то типа 0160004, то программа даже в пульт не вылетит.
Нас же в первую очередь интересует, как такая последовательность команд дружит с битом Т и командой RTT :)
Это проверяет следующая модификация теста: PDP-11 Interrupts Test #4a.
Похоже, что процессор 11/80 не испытывает проблем при снятии IRQ до приёма вектора.Цитата:
Сообщение от form
Или оно еще не успевает выставиться.Цитата:
Сообщение от Patron
Есть еще такое понятие - passive release.
---------- Post added at 21:55 ---------- Previous post was at 21:55 ----------
Сейчас в описании посмотрим есть ли что-нибудь на эту тему.
Хитрость тут (насколько понимаю) в том, что когда у устройства обнуляют бит РП - оно сразу теряет способность ответить на запрос передачи вектора, тогда как на то, чтобы снять IRQ, и чтобы этот обратный фронт успел дойти по шине до процессора - требуется время, поэтому при последовательном выполнении команд установки и сброса бита РП - процессор успевает запросить у устройства вектор, но устройство к тому моменту уже "забывает о чём речь".Цитата:
Сообщение от form
Отход с IRQ без прерывания - стандартная фича.Цитата:
Сообщение от Patron
Но не факт, что в данном случае оно вообще выставлялось.
Тут вариантов много может быть - без нормальной лаборатории на дому трудно :)
PDPT4A на УКНЦ.
Вот еще пример где УКНЦа наверное свалится, а KDJ11 нет.
Код:.E 0-2
040000 104350
.RU RED
?MON-F-Trap to 4 001004
.E 0-2
001004 000004
.TY RED.MAC
START: CLR SP
WAIT
.END START
.
---------- Post added at 22:33 ---------- Previous post was at 22:28 ----------
Кстати по этой причине мой любимый способ зачистки нижней памяти с чистым остановом не работает - останутся недочистки в 0-2 :)
А как это так? Каким образом стек так перемещается? Или это особенность KDJ-11?
А УКНЦ будет так.
На KDJ11 двойная защита стека. Первый уровень - yellow trap - если SP упал ниже 400 происходит прерывание по 4 (причина берется из cpuerr регистра). Второй уровень red stack abort - когда вызов прерывыния не позволяет в кернелный стек записать - тогда KSP принудительно ставится на 4 и делается трап по 4.Цитата:
Сообщение от Alex_K
Это только с включенным менеджером памяти, или даже с выключенным так работает (в незащищенном режиме)?Цитата:
Сообщение от form
У ВМ1 точно так же.Цитата:
Сообщение от Alex_K
Есть ещё один момент, про который не мешает знать - как поведёт себя пара BIS-BIC, если BIC идёт сразу после BIS, но не по ходу программы, а как первая команда обработчика прерывания, выполняющегося с разрешёнными прерываниями.
Ответ даёт следующий тест: PDP-11 Interrupts Test #4b.
В любом варианте.Цитата:
Сообщение от Alex_K
При включенном MMU только для kernel mode, при выключенном - оно и есть kernel mode.
---------- Post added at 22:44 ---------- Previous post was at 22:41 ----------
Код:.RU PDPT4B
PDP-11 Interrupts Test #4b
060 Handler:
001364: BIC #100,@#TTPS
001372: NOP
...Press Key...
BIS #100,@#TTKS
BIS #100,@#TTPS
060 Handler:
>>> Interrupt <<< 064 ; 001364
NOP
NOP
Program completed.
.D 10000=5037,177546,137,1000
.ST 10000
PDP-11 Interrupts Test #4b
060 Handler:
001364: BIC #100,@#TTPS
001372: NOP
...Press Key...
BIS #100,@#TTKS
BIS #100,@#TTPS
060 Handler:
>>> Interrupt <<< 064 ; 001364
NOP
NOP
Program completed.
.
PDPT4B на УКНЦ.
В этом вопросе у ВМ1, ВМ2 и 11/80 разногласий нет :)Цитата:
Сообщение от Alex_K
Перечень причин входа в ступор...
А вот и случай с невыставлением вектора описан.
Значит просто игнорирует. А я вот слышал, что некоторые процессоры PDP-11 при неполучении вектора трапались по нулевому вектору.Цитата:
Сообщение от form
Надо младшие модели посмотреть - те же 11/03 к примеру.Цитата:
Сообщение от Alex_K
Мы забыли проверить, как процессоры ВМ1 и ВМ2 осуществляют байтовую запись в стек при нечётных значениях SP.
Чтобы закрыть этот пробел - здесь три новых теста. Все тесты используют команду MOVB #xx, (SP)+, но в одном случае SP дополнительно декрементируется, а в другом - инкрементируется.
Запись осуществляется в массив по адресу 03700, заполненный 0177777
Вот содержательные части тестов и результаты прогонов на моей модели ВМ1:
PDPT5.SAV
Код:Mov #FTst1, SP
MovB #60001, (SP)+
MovB #50002, (SP)+
Nop
Mov SP, R1
MovB #6003, (SP)+
MovB #7004, (SP)+
Mov SP, R2
Nop
Mov SP, R3
MovB #20005, (SP)+
MovB #10006, (SP)+
Mov SP, R4
...Код:.RU PDPT5
PDP-11 Interrupts Test #5
R1/003704
R2/003710
R3/003710
R4/003714
003700/177401
003702/177402
003704/177403
003706/177404
003710/177405
003712/177406
003714/177777
003716/177777
Program completed.
PDPT5A.SAV
Код:Mov #FTst1, SP
MovB #60001, (SP)+
MovB #50002, (SP)+
Dec SP
Mov SP, R1
MovB #6003, (SP)+
MovB #7004, (SP)+
Mov SP, R2
Dec SP
Mov SP, R3
MovB #20005, (SP)+
MovB #10006, (SP)+
Mov SP, R4
...Код:.RU PDPT5A
PDP-11 Interrupts Test #5a
R1/003703
R2/003707
R3/003706
R4/003712
003700/177401
003702/001402
003704/002377
003706/177405
003710/177406
003712/177777
003714/177777
003716/177777
Program completed.
PDPT5B.SAV
Код:Mov #FTst1, SP
MovB #60001, (SP)+
MovB #50002, (SP)+
Inc SP
Mov SP, R1
MovB #6003, (SP)+
MovB #7004, (SP)+
Mov SP, R2
Inc SP
Mov SP, R3
MovB #20005, (SP)+
MovB #10006, (SP)+
Mov SP, R4
А как поведут себя в этих тестах реальные процессоры ?Код:.RU PDPT5B
PDP-11 Interrupts Test #5b
R1/003705
R2/003711
R3/003712
R4/003716
003700/177401
003702/177402
003704/001777
003706/002377
003710/177777
003712/177405
003714/177406
003716/177777
Program completed.
Сейчас проверим.Цитата:
Сообщение от Patron
Выполняется надеюсь на SLP7? :)
А то
Может дать вообще левый результат :)Код:MovB #60001, (SP)+
MovB #50002, (SP)+
---------- Post added at 16:52 ---------- Previous post was at 16:50 ----------
Код:.RU PDPT5
PDP-11 Interrupts Test #5
R1/003704
R2/003710
R3/003710
R4/003714
003700/177401
003702/177402
003704/177403
003706/177404
003710/177405
003712/177406
003714/177777
003716/177777
Program completed.
.RU PDPT5A
PDP-11 Interrupts Test #5a
R1/003703
R2/003707
R3/003706
R4/003712
003700/177401
003702/001402
003704/002377
003706/177405
003710/177406
003712/177777
003714/177777
003716/177777
Program completed.
.RU PDPT5B
PDP-11 Interrupts Test #5b
R1/003705
R2/003711
R3/003712
R4/003716
003700/177401
003702/177402
003704/001777
003706/002377
003710/177777
003712/177405
003714/177406
003716/177777
Program completed.
.
YES!
Даже удивительно, что моя модель ВМ1 ведёт себя в этом случае правильно..
У меня на ВМ2 в EmuStudio такие же результаты.
Ещё удивительнее то, что написав правильную модель - я сам был уверен, будто при MOVB #1,-(SP) не только записывается 1 в младший байт слова-приёмника, но и что старший байт очищается.
Думая так, я сплошь и рядом пытался избавиться от расширения знака в старший байт регистра-приёмника следующим образом:
И только сейчас понял, почему те мои программы так дико глючили :)Код:MovB @#TKB, R0
MovB R0, -(SP)
Add (SP)+, CheckSumm
Скрытый текст
Да, в этом аспекте наши процессоры "в точности как PDP-11/83" :)Цитата:
Сообщение от hobot
Особенно с учетом того, что такой модели нет :)Цитата:
Сообщение от Patron
В UKNCBTL аналогичные результаты.
А тесты на Double Bus error будут?
Какого примерно содержания?Цитата:
Сообщение от Alex_K
1. Указатель стека указывает на несуществующую память.Цитата:
Сообщение от Patron
2. Программа обработки TRAP4 начинается в несуществующей памяти, а указатель стека нормальный
При этом сама программа обработки TRAP4 начинается с разрешенными прерываниями, а обработка таймера также начинается в несуществующей памяти.
Первое у меня вполне обрабатываемая ситуация.Цитата:
Сообщение от Alex_K
Второе в разных вариантах будет sunset loop который остановить можно только через BHALT. На ВМ2 реакция вроде одинаковая на все это - прерывание в HALT mode.
Есть еще много вариантов пакостей. Для ВМ проца можно попробовать такое: в @#16 записать 20 :)
Правильнее, наверно говорить: "вектор 04 и вектор 0100 содержат несуществующие адреса"..Цитата:
Сообщение от Alex_K
Вряд ли реально написать программу, которая такое тестирует и нормально завершает работу выходом в KMON (кроме первого пункта в случае, когда SP == 0160002 или SP == 0160004 - тогда ничего страшного не происходит - обычный "TrapTo_04"), поэтому тесты осуществляются в "ручном режиме".
Если SP > 0160004, то происходит двойная ошибка шины.
Если стек нормальный, а вектор 04 "указывает в пустоту", то при возникновении TrapTo_04 по любой причине ( не обязательно ждать таймера - можно просто выполнить TST @#160000 ) - у ВМ1 происходит зацикливание входа в прерывание до выхода указателя стека за пределы памяти, после чего следует двойная ошибка шины.
На ВМ2 все эти события - обычные прерывания в режиме HALT. Если есть доступ к памяти режима HALT и она записываемая - вполне решаемо.Цитата:
Сообщение от Patron
Но об универсальности тут уже речь не идет...
---------- Post added at 00:26 ---------- Previous post was at 00:24 ----------
Вообще подобные тесты лучше делать не с выходом в KMON, а с проверкой можно ли его вообще делать (foreground loaded?) и если можно - снять загрузчик с SY:, переключиться на кернел с ресетом и там уже воротить что угодно, после чего - перезагрузка. Если еще есть из чего :)
---------- Post added at 00:29 ---------- Previous post was at 00:26 ----------
Ну а если все-таки пытаться вернуться в RT-11, то опять таки сначала надо переключиться на кернел, а там уже воротить что угодно.