И спасает только BR, т.к. не используя счётчики - обнуляет их.Цитата:
Сообщение от Titus
И спасает только BR, т.к. не используя счётчики - обнуляет их.Цитата:
Сообщение от Titus
Что-то типа того. Но после этого исполняется два раза INC R1, вот это номер. Тут еще эффект связан если последующие команды не нарушают предвыборки, т.е. состоят из одного слова.Цитата:
Сообщение от Titus
---------- Post added at 13:00 ---------- Previous post was at 12:59 ----------
Любая команда, нарушающая принцип предвыборки.Цитата:
Сообщение от Patron
Гениально!Цитата:
Сообщение от Alex_K
Вот любопытная модификация проведённого теста:
MovB перед записью ещё раз читает ячейку, не добавит ли это дополнительных глюков..Код:Clr R1
Clr R2
Clr R3
MovB (PC),(PC)
Inc R1
Inc R2
Inc R3
Jmp @#1000
.Word 2000
.Word 3000
---------- Post added at 12:06 ---------- Previous post was at 12:04 ----------
Но если эта команда сама использует сбитый счётчик - она скорее вынесет в Trap_To_4, чем спасёт. А из всех команд, нарушающих предвыборку - только BR не использует ни одного счётчика ( или ошибаюсь? ).Цитата:
Сообщение от Alex_K
---------- Post added at 12:21 ---------- Previous post was at 12:06 ----------
Ещё один вариант:
Код:Clr R1
Clr R2
Clr R3
Mov (PC),R0
Mov (PC),R0
Inc R1
Inc R2
Inc R3
Jmp @#1000
.Word 2000
.Word 3000
Цитата:
Сообщение от Patron
Ну вот собственно и ответ:Цитата:
Сообщение от Alex_K
Скрытый текст
---------- Post added at 19:15 ---------- Previous post was at 18:52 ----------
Глюков здесь нет, все в пределах нормы. Т.к. эта команда делает запись по адресу предвыборки, то все сбрасывается и начинается сначала.Цитата:
Сообщение от Patron
Скрытый текст
---------- Post added at 19:26 ---------- Previous post was at 19:15 ----------
Это тот вариант, что я описывал. Количество команд MOV @PC,R0 роли не играет.Цитата:
Сообщение от Patron
Скрытый текст
Получается, что запись следующей ячейки после команды занимает весьма разное время при адресации относительно PC и относительно любого другого регистра:
Код::::::: SP = PC ::::::
Mov R0, (PC) 47
Mov R0, (SP)+ 85
---------- Post added at 18:34 ---------- Previous post was at 18:32 ----------
На первый взгляд могло показаться, что в первом случае запись не происходит, однако последние тесты показали, что команда Mov R0, (PC) честно пишет в следующую ячейку, но просто делает это гораздо быстрее.
Два кода для анализа с результатами:
Скрытый текст
---------- Post added at 20:16 ---------- Previous post was at 19:56 ----------
Еще интересный случай.
Скрытый текст
Супер!
Ну так если подытожить?
А вот теперь надо думать, что к чему и от чего. Но чтение с методом адресации 17 дает очень интересные результаты. Кстати, попробовал запускать эти тесты в режиме HALT, все тоже самое.Цитата:
Сообщение от Titus
Там в двух позициях есть сомнительные результаты:Цитата:
Сообщение от Titus
http://emulator.pdp-11.org.ru/misc/Test1.png
http://emulator.pdp-11.org.ru/misc/Test2.png
Во втором случае точно должно быть в 2 раза больше, а в первом - надо ещё проверить.
...
Специально для проверки первого пункта - более точный вариант линейного теста: MovPC2_v1.2
При первом запуске теста нужно ввести правильное значение частоты тестируемого процессора в килогерцах.
Результат запуска в эмуляторе ДВК выглядит так:
Где:Код:.RU MOVPC2
MovPC2 - v1.2
Memory Top: 137554
BUF words: 22867
CPU KHz: 5300 >
1: Nop Evt: 14 ; Run: 7557 ; Res: 7571 ; CLC: 14.0
1: Mov R0, R0 Evt: 14 ; Run: 7557 ; Res: 7571 ; CLC: 14.0
1: Mov R0, (PC) Evt: 5 ; Run: 2861 ; Res: 2866 ; CLC: 37.0
1: MovB R0, (PC) Evt: 5 ; Run: 2861 ; Res: 2866 ; CLC: 37.0
1: Mov (PC), R0 Evt: 6 ; Run: 3528 ; Res: 3534 ; CLC: 30.0
1: MovB (PC), R0 Evt: 6 ; Run: 3528 ; Res: 3534 ; CLC: 30.0
::: SP = PC :::
1: Mov R0, (SP)+ Evt: 4 ; Run: 2582 ; Res: 2586 ; CLC: 41.0
1: MovB R0, (SP)+ Evt: 4 ; Run: 2582 ; Res: 2586 ; CLC: 41.0
1: Mov (SP),(SP)+ Evt: 4 ; Run: 2161 ; Res: 2165 ; CLC: 49.0
1: MovB (SP),(SP)+ Evt: 4 ; Run: 2161 ; Res: 2165 ; CLC: 49.0
Program completed.
.
Evt - Число тестируемых команд, выполнившихся за промежуток времени между началом и концом первого прерывания таймера.
Run - Число тестируемых команд, выполнившихся за промежуток времени между концом первого и началом второго прерывания таймера.
Res - Общее число тестируемых команд, выполнившихся между началом первого и началом второго прерывания таймера.
CLC - Подсчитанное число тактов.
...
В приложении два варианта теста - MovPC2_v1.1 выходит из первого прерывания таймера по RTI, а MovPC2_v1.2 - по BR.
...
Если на этих командах процессор не перпрыгивает через команду вперед, то результаты должны быть корректны.Цитата:
Сообщение от Patron
Играет роль какая команда после блока этих команд.Цитата:
Сообщение от Titus
Во втором случае очевидно, что команда MOV (PC),(PC)+ именно перепрыгивает следующую и поэтому число "пройденных" слов нужно делить на 2.Цитата:
Сообщение от Titus
...
А в первом случае - просто интересно, как получается такая большая разница в результатах тестов.
Ведь линейный движок тестирования продолжительности команд элементарно прост - после первого прерывания начинает выполняться последовательность тестируемых команд, а после второго прерывания - вычисляется разница адреса старта последовательности и адреса входа во второе прерывание.
Цитата:
Сообщение от Patron
Скрытый текст
Увы, циклический тест с командами MOV (PC), R0 и MOVB (PC), R0 не дружит.Цитата:
Сообщение от Titus
Весьма похоже, что тест TSSPD даёт ошибочные результаты в обоих обсуждаемых случаях.Код:OpBuf:
.BLKW 2048 ;Буфер для тестируемых команд
OpBufEnd:
INC R4 ;Увеличиваем счетчик циклов
JMP (R5) ;Бесконечный цикл --> OpBufLoop
MovPC2_v1.1:Цитата:
Сообщение от Patron
Скрытый текст
MovPC2_v1.2:Скрытый текст
---------- Post added at 20:41 ---------- Previous post was at 20:38 ----------
В этом случае, после MOV @PC,R0, INC R4 выполниться два раза.Цитата:
Сообщение от Patron
Для комплексной проверки глюков команды MOV (PC), R0, наблюдавшихся в тесте MOVPC.SAV - готова специальная версия этого теста: MovPCx, перехватывающая Trap_To_4, ведущая два счётчика циклов ( в начале и конце тестовой последовательности ) и перехватывающая плохие переходы:
При первом запуске теста можно ввести значение тактовой частоты тестируемого процессора в килогерцах, а также задать значение PSW при котором будет выполняться тест ( допустимы значения 0 и 340, любое другое значение превратится в 340 ).Код:Foot0:
Nop
Nop
Nop
Dec R5
BEq 1$
Jmp @#LoopStart
.Word Bad.Jmp
1$:
Mov #R.T.I, @#100
Inc R4
MTPS #0
Return
Foot1:
...
С PSW=0:Цитата:
Сообщение от Patron
Скрытый текст
С PSW=340:
Скрытый текст
---------- Post added at 22:11 ---------- Previous post was at 22:09 ----------
По поводу TRAP4, адрес прерывания в стеке может быть неверный, обычно в таких случаях он увеличен на 2.
Код в том месте такой:
Код:011220 [000000]: MOV (PC), R0 ; 011222:011700 -> R0
011222 [000000]: MOV (PC), R0 ; 011224:011700 -> R0
011224 [000000]: MOV (PC), R0 ; 011226:011700 -> R0
011226 [000000]: MOV (PC), R0 ; 011230:000240 -> R0
011230 [000000]: NOP
011232 [000000]: NOP
011234 [000000]: NOP
011236 [000000]: DEC R5 ;
011240 [000000]: BEQ 011250
011242 [000000]: JMP @#005306
Код:Foot0:
Nop
Nop
Nop
Dec R5
BEq 1$
Jmp @#LoopStart
.Word Bad.Jmp
1$:
Mov #R.T.I, @#100
Inc R4
MTPS #0
Return
Foot1:
---------- Post added at 21:31 ---------- Previous post was at 21:24 ----------
А на другой машине, помнится, пока та была холодная - тест один раз не просто без вылета, а даже и почти без глюков прошёл..
---------- Post added at 21:33 ---------- Previous post was at 21:31 ----------
По счётчикам команда BEQ вылететь в Trap_To_4 вряд ли может - слишком далеко до ближайшей незанятой памяти.
Другая УКНЦ.Цитата:
Сообщение от Patron
PSW=0:
Скрытый текст
PSW=340:
Вы нам так и не раскрыли свое видение этого процесса.Цитата:
Сообщение от Alex_K
Так вроде уже писал ранее и тестовые коды показывал.Цитата:
Сообщение от Titus
А глюк проявляется, если в качестве источника двухоперандных команд используется адресация 17.
---------- Post added at 23:27 ---------- Previous post was at 23:24 ----------
А на самом деле до понимания всего процесса надо проделать много опытов по влиянию разных команд на значения счетчиков СК1 и СК2.
Но сначала надо бы придумать алгоритм точного определения значений этих счётчиков ( вроде перехода по специальной таблице относительно какого-то регистра или типа того ).Цитата:
Сообщение от Alex_K
...
И кроме того - что же всё-таки вызывает Trap_To_4 в "глючном" тесте. Ведь раньше он вылетал и после первой команды NOP, потом начал вылетать после BEQ. Но даже при запрещённых прерываниях вылетает не всегда сразу.
А что тогда влияет - вылетит или не вылетит тест на очередной итерации цикла. Ведь все ячейки памяти имеют на каждом проходе одинаковые значения.
Bad JMP - понятное дело - следствие сбоя счётчика. И если при запрещённых прерываниях Bad JMP всегда будет происходить в первом же цикле - тут всё ясно.
Но если на одной УКНЦ при запрещённых прерываниях вылетает по Trap_To_4, а на другой - по Bad JMP, то как это можно было бы объяснить, не допустив "глюкогенного" влияния аналоговых процессов ???
По поводу источника питания я уже высказывался, еще раз повторюсь - если бы дело было в источнике, то тогда бы барахлило все - и процессор и память, УКНЦ просто напросто не запустилась бы. Здесь влияние других факторов, первое - ошибки в микропрограмме, ну и второе - разное тактирование процессора и памяти. В этом случае легко может оказаться, что из-за ошибок в микропрограмме неправильно поставлена совместная работа блоков микропроцессора и при запросе на чтение легко может быть так, что операционный блок выдаст ошибку чтения с шины. На одной УКНЦ может так совпасть, что память относительно быстро успевает прочесться, на другой требуются дополнительные такты, приводящие к TRAP4.Цитата:
Сообщение от Patron
Так что тут надо исследовать.
При небольшой последовательности команд MOV @PC,R0 поведение обычно предсказуемо. При длинной последовательности начинают возникать глюки, уже более необъяснимые.
По сути - это единственная оставшаяся несинхронность, из-за которой дискретная ситуация в разных циклах теста может отличаться.Цитата:
Сообщение от Alex_K
Чтобы исключить её возможне влияние - нужно сделать тестовую УКНЦ с одинаковым тактированием ЦП и памяти.
Надо основательно погонять MovPCx на той УКНЦ, где вместо Trap_To_4 происходил BAD Jmp.Цитата:
При длинной последовательности начинают возникать глюки, уже более необъяснимые.
Если ни одного Trap_To_4 так и не случится - это будет очень серьёзный довод в пользу аналоговой теории происхождения трапов. Ведь разница в тактировании ЦП и памяти у всех тестируемых УКНЦ одинаковая.
Кто ее будет делать?Цитата:
Сообщение от Patron
А если надо, то ПП к вашим услугам, там память и процессор тактируются одной частотой, только там память сидит на 8-ми битах, поэтому слово читаться будет за два приема.
А при чем тут аналоговая версия? Сигнал для TRAP4 идет с операционного блока. А разница у разных УКНЦ в тактировании будет, хоть и кварцы стоят, но тоже чуть-чуть могут отличаться.Цитата:
Сообщение от Patron
Разница разная, т.к. тактируются от разных кварцев. А, как известно, у всех кварцев есть погрешность, и биение частот на всех машинах будет разное. Однако, здесь дело скорее всего не в этом.Цитата:
Сообщение от Patron
Цитата:
Сообщение от Alex_K
Чтобы сигнал RPLY на полном серьёзе не выставлялся ( или выставлялся, но не обнаруживался ) в течение интервала ожидания Q-Bus всего лишь из-за ничтожной разницы ( в разных экземплярах УКНЦ ) в тактировании процессора и памяти..Цитата:
Сообщение от Titus
Какой тогда вообще смысл в использовании асинхронной шины между памятью и процессором..
---------- Post added at 12:48 ---------- Previous post was at 12:19 ----------
Аналоговая версия при том, что (на мой взгляд) только из-за проблем с питанием операционный блок может или обнаружить, или не обнаружить на шине RPLY после выполнения одной и той же последовательности команд в одних и тех же ячейках памяти ( ведь даже на одной и той же УКНЦ и при запрещённых прерываниях - Trap_To_4 в конце каждого цикла теста - может произойти, а может и не произойти ).Цитата:
Сообщение от Alex_K
Весьма похоже, что мы имеем динамический глюк микропрограммы, обусловленный не только "статическими" ошибками в микрокоде, но и различным исполнением одних и тех же микропрограмм при одних и тех же исходных данных.
Т.е. в какие-то моменты происходит сбой в работе "интерпретатора микрокода" - и тогда (при полностью корректной работе шины) происходит "трап на ровном месте" ( такой, как при исполнении команды JMP R0 ).
Есть такой глюк, в зависимости от ситуации после MOV @PC,R0 следующая за ней команда, не нарушающая предвыборки, либо может исполнится два раза, либо вообще пропуститься. А вот с адресацией по счетчику команд обычно всегда получался адрес увеличенный на два, на четыре не удалось.Цитата:
Сообщение от Patron
оффтоп по теме
Скрытый текст
Я всегда подозревал, что роботы живые и рано или поздно они восстанут против человеков ) Что косвенно подтверждается даже примитивных недокомпьютеров типа УК-НЦ ). А если у монстра на ровном месте случится трап? ) Страшно подумать что может случится тогда ! И ещё момент платки как ни крути старые,Цитата:
Сообщение от Patron
даже новенькие УК-НЦ никогда не работали как часики. Хотя я свою помнится сутками не выключал - но перезагрузка занимала значительный % времени от общего. Почти не зависала если простой был, но зависания в процессе отладки программ вполне норм. вещь же ) Трапы - я сейчас лучше конечно понимаю это,
но и тогда Panic Dump мог случится во время операции которая 99 раз работает.
[свернуть]
Новый тест MovPCy должен помочь лучше протестировать "стрёмные" команды.
При запуске теста можно задать следующие параметры:
Код:.RU MOVPCY
MovPCy - v1.0
CPU KHz: 5300 >
MTPS : 0 >
Command: 011700 >
Row Len: 1000 >
Word W1: 000240 >
Word W2: 000240 >
Word W3: 000240 >
Loops : 106 >
Command: 011700 Loops: 106 ; Ticks: 30
R0: 000240 ; R1: 000000 ; R2: 000000 ; R3: 000000
R0: 160 ; R1: 0 ; R2: 0 ; R3: 0
Program completed.
.
Тестовая последовательность завершается следующим кодом:Код:CPU KHz - Тактовая частота тестируемого процессора в килогерцах (десятичное).
MTPS - Значение PSW во время тестирования (восьмеричное).
Command - Тестируемая команда (восьмеричное).
Row Len - Число экземпляров (1..10000) тестируемой команды в тестовом буфере.
Word W1 - Первое слово после тестируемой последовательности (восьмеричное).
Word W2 - Второе слово после тестируемой последовательности (восьмеричное).
Word W3 - Третье слово после тестируемой последовательности (восьмеричное).
Loops - Число циклов ( лучше не трогать ).
Разрешается изменять значения регистров R0, R1, R2, R3.Код:Foot0:
W1: Nop
W2: Nop
W3: Nop
Dec R5
BEq 1$
Jmp @#LoopStart
.Word Bad.Jmp
1$:
Mov #R.T.I, @#100
Inc R4
MTPS #0
Return
Foot1:
Перед началом теста эти регистры обнуляются.
...
Еще раз БОЛЬШОЕ СПАСИБО Patron-у за этот тест. В результате тестирования выяснилось, что разные команды работают по разному после MOV @PC,R0. Поведение более-менее поддается анализу за исключением команд установки/снятия признаков. В этом случае раз на раз не приходится, потому при употреблении трех NOP и получались такие разные результаты.Цитата:
Сообщение от Patron
Потестировал на УКНЦ литеры 3. Ее поведение практически ничем не отличается от УКНЦ литеры 7 с 1515ХМ1-031. Но рассмотрим наиболее интересные случаи.
1. Сперва употребляется пара NOP, потом INC R3:
Скрытый текст
При этом выборе иногда, часто, получается TRAP10. Сразу видно, что в R0 содержится 0137, а не 0240. Само значение 0137 содержится по адресу 055724, а 0240 по адресу 055712, разница составляет 012. Сразу же за ячейкой 055724 со значением 0137 расположена ячейка 055726 со значением 06650, при исполнении этой команды и возникает TRAP10. Также видно, что INC R3 и DEC R5 ни разу не сработали, хотя висел этот тест продолжительное время, получается довольно часто попадало на JMP @#6650.
2. Либо все три NOP, или сперва INC R1, потом два NOP:
Скрытый текст
В этих вариантах часто срабатывает TRAP4, а INC R1 исполняется два раза. По аналогии с первым результатом в качестве TRAP4 может служить исполнение кода 0100 по адресу 055736. И еще - в R0 ложится младший байт, а не слово.
3. Два INC и один NOP. Без комментариев, ибо не объяснимо.
Скрытый текст
4. Один NOP между двумя INC.
Скрытый текст
Видно, что INC R1 всегда исполняется два раза, а вот INC R3 после NOP не всегда исполняется.
Вот такие вот дела. Остальные команды предсказуемы, но разная реакция на них. Потестирую, опишу.
Ну так что, есть предварительное описание глюка?
После двухадресной команды, если в качестве источника используется @PC, и если команда не нарушает предвыборку (из одного слова и не записывает по адресу PC), то следующая за ней команда, не нарушающая предвыборку, исполняется два раза. Затем все адресации по счетчику команд смещаются на 2, это касается и команд коротких переходов и прерываний (в стек ложится PC+2). Хотя адресации по PC и смещаются, но команды выполняются. А вот тут зависит уже от типа команд. После некоторых следующая за ними команда может не исполнится.Цитата:
Сообщение от Titus
Но все это надо дополнительно тестировать в пультовом отладчике, т.к. тест Patron-а дает задать только три команды. В пультовом отладчике может и медленней, но гибче.
А вот поведение команд установки/снятия признаков (0240-0277) вообще не поддается никакому логическому анализу. Видно сказывается разное тактирование процессора и памяти, видно зависит от разницы в выборке слова из памяти.
Эх, протестировать бы на МС1201.02, там память не надо разделять с видеоадаптером, там уже время выборки должно быть стабильным.
Думаю, что этот глюк произошел из-за того, что адресация в адресации по (PC) не предполагалось использования регистра без автоинкремента. Т.е. по умолчанию считалось, что если адресация по (PC), то это именно (PC)+, использующееся как обращение к непосредственным данным внутри команды, и все компенсации кеша были заточены под нее.
Здесь я абсолютно согласен, не только 27( (PC)+ ), но и 37( @(PC)+ ), 6х и 7х. В этом случае нужный аргумент уже извлекался в результате предвыборки и микрокод это учитывал, чтобы два раза не читать. Но после этих адресаций счетчик команд увеличивался на два, а в случае с @PC оставался тем же. Глюк может быть связан еще с тем, что есть два счетчика команд СК1 и СК2. СК2 вроде всегда больше СК1 на два, но в этом глюке между ними получается рассинхронизация. И кстати по описанию на процессор команды установки/снятия признаков используют внутренний сигнал признака байта, чтобы записывать только в младший байт PSW, может уже начинается дешифрация NOP, потому в R0 и оказывается только младший байт. Но все это предположения, надо знать микрокод, хотя кое-что в ТО описано, надо посмотреть по блок-схемам.Цитата:
Сообщение от Titus
Мне, как верному адепту "питательной" теории было особенно интересно увидеть:
Какой блок УКНЦ вырабатывает это прерывание?Код:?MON-F-Power fail halt
Типа, процессор как-то анализирует входное напряжение?
В ЦП вход ACLO управляется из магистрали ПП через регистр 177716 (также как и входы DCLO и HALT). Так что питательная теория в отношении ЦП отпадает. А вот на ПП ACLO и DCLO поступают со схемы запуска, которая формирует необходимые задержки этих сигналов. В этой же схеме и находится кнопка сброса для перезапуска УКНЦ. А уже программа в ПЗУ ПП через регистр 177716 запускает ЦП.Цитата:
Сообщение от Patron
А сколько хотелось бы ?Цитата:
Сообщение от Alex_K
Много. Да и длину допкоманд также задавать. Но как быть, если захочешь протестировать команды с автоинкрементным способом адресации, которые записывают значения в какой-нибудь буфер?Цитата:
Сообщение от Patron
---------- Post added at 23:56 ---------- Previous post was at 23:54 ----------
Так же задавать предварительные значения в регистрах.