Пока в состоянии "микросхемы куплены и лежат на складе".Цитата:
Сообщение от Titus
Разобраться проще, но объем требуемой работы от этого никуда не исчезает.Цитата:
Сообщение от Titus
Вид для печати
Пока в состоянии "микросхемы куплены и лежат на складе".Цитата:
Сообщение от Titus
Разобраться проще, но объем требуемой работы от этого никуда не исчезает.Цитата:
Сообщение от Titus
Немножко непонятно что должен выполнять Тест 56 из 791404:
Насколько я понял - rtt выполнит возврат на 2$, выполнится inc R1, произойдет отложенное исключение по T-биту на 3$, там будет dec R1 и завершение теста переходом к tst57. Зачем все остальные инструкции?Код:tst56: inc @#$testn ; тест 56, rtt - прослеживаемая
cmp #56, @#$testn ; команда
bne 4$ ;
mov #-1, R5 ;
;
1$: mov #buff, SP ;
mov #20, -(SP) ;
mov #2$, -(SP) ;
mov #3$, rtrap4 ;
clr R1 ;
rtt ;
;
2$: inc R1 ;
inc R5 ;
beq 1$ ;
mov #216, @#$fatal ;
inc @R2 ;
halt ; нет прерывания
;
3$: dec R1 ; непонятно, сразу выход
beq tst57 ;
inc R5 ;
beq 1$ ;
;
4$: mov #217, @#$fatal ;
inc @R2 ;
halt ; ошибка rtt или НПТ
;
tst57:
Похоже, что авторы теста хотели проверить возникновение прерывания не только после установки T-бита командой RTT, но и после снятия, но так до конца и не поняли, как лучше это закодировать. В итоге ( насколько я понял ) - возникновение ровно одного прерывания после снятия T-бита командами RTI / RTT нигде в тесте не проверяется, хотя по идее - обязательно должно проверяться.Цитата:
Сообщение от Vslav
---------- Post added at 16:30 ---------- Previous post was at 16:26 ----------
Кстати, когда команда RTT снимает бит T и затем происходит "финальное" прерывание по вектору 014, то в какой момент должно происходить это прерывание - до выполнения следующей за RTT команды или после ?
---------- Post added at 17:13 ---------- Previous post was at 16:30 ----------
Ответ даёт TTST6.SAV
Результаты запуска в эмуляторе следующие :
Код:.RU TTST6
LSI-11 Traps Test #6
Mov #00,-(SP)
Mov #L2,-(SP)
Mov #20,-(SP)
Mov #L1,-(SP)
RTT
L1: RTI
L2:
>>> Trap to 014 <<<
NOP
Mov #00,-(SP)
Mov #L4,-(SP)
Mov #20,-(SP)
Mov #L3,-(SP)
RTT
L3: RTT
L4:
>>> Trap to 014 <<<
NOP
.
В тесте 791404 вообще хватает ошибок и опечаток, поэтому ничего удивительного.
Насчет инструкции RTT - похоже она блокирует распознавание бита Т в первой микрокоманде следующей инструкции, в которой происходит первичное декодирование и опрос контроллера прерываний. Как дойдут руки потестировать - отпишусь о подробностях.
В том и фокус, что в обсуждаемом случае T-Trap происходит при снятом бите T, поэтому блокировка распознавания бита T может в данном случае и не влиять.Цитата:
Сообщение от Vslav
По идее если при возврате по RTT устанавливается бит T, то обработка всех прерываний не запускается, аналогично команде STEP. А вот если бит T сбрасывается, то обработка прерываний должна происходить.Цитата:
Сообщение от Vslav
Пока сложно сказать как оно точно происходит. Т-бит заходит (является аргументом) в матрицу контроллера прерываний, где может маскироваться битом 2 регистра 177700, пока это предположительно режим ожидания (по команде WAIT). Также T-бит заходит и в основную матрицу, поэтому может напрямую влиять на исполнение микрокода.Цитата:
Сообщение от Alex_K
В этом случае он выступает в качестве источника прерываний, в соответствии с приоритетом.Цитата:
Сообщение от Vslav
Я пока склоняюсь к мнению что в матрице контроллера он маскирует менее приоритетные прерывания. Ну, скоро увидим.Цитата:
Сообщение от Alex_K
Ну более приоритетное всегда маскирует менее приоритетное.Цитата:
Сообщение от Vslav
А вот ещё вопрос - при исполнении программных прерываний (BPT, IOT, EMT, TRAP) как реализуется прерывание? Устанавливаются ли какие либо признаки в регистре прерываний? И какой микрокод реализует саму команду?