Вы нам так и не раскрыли свое видение этого процесса.Сообщение от Alex_K
Вы нам так и не раскрыли свое видение этого процесса.
Так вроде уже писал ранее и тестовые коды показывал.
А глюк проявляется, если в качестве источника двухоперандных команд используется адресация 17.
---------- Post added at 23:27 ---------- Previous post was at 23:24 ----------
А на самом деле до понимания всего процесса надо проделать много опытов по влиянию разных команд на значения счетчиков СК1 и СК2.
Но сначала надо бы придумать алгоритм точного определения значений этих счётчиков ( вроде перехода по специальной таблице относительно какого-то регистра или типа того ).
...
И кроме того - что же всё-таки вызывает Trap_To_4 в "глючном" тесте. Ведь раньше он вылетал и после первой команды NOP, потом начал вылетать после BEQ. Но даже при запрещённых прерываниях вылетает не всегда сразу.
А что тогда влияет - вылетит или не вылетит тест на очередной итерации цикла. Ведь все ячейки памяти имеют на каждом проходе одинаковые значения.
Bad JMP - понятное дело - следствие сбоя счётчика. И если при запрещённых прерываниях Bad JMP всегда будет происходить в первом же цикле - тут всё ясно.
Но если на одной УКНЦ при запрещённых прерываниях вылетает по Trap_To_4, а на другой - по Bad JMP, то как это можно было бы объяснить, не допустив "глюкогенного" влияния аналоговых процессов ???
Последний раз редактировалось Patron; 28.02.2013 в 01:30.
По поводу источника питания я уже высказывался, еще раз повторюсь - если бы дело было в источнике, то тогда бы барахлило все - и процессор и память, УКНЦ просто напросто не запустилась бы. Здесь влияние других факторов, первое - ошибки в микропрограмме, ну и второе - разное тактирование процессора и памяти. В этом случае легко может оказаться, что из-за ошибок в микропрограмме неправильно поставлена совместная работа блоков микропроцессора и при запросе на чтение легко может быть так, что операционный блок выдаст ошибку чтения с шины. На одной УКНЦ может так совпасть, что память относительно быстро успевает прочесться, на другой требуются дополнительные такты, приводящие к TRAP4.
Так что тут надо исследовать.
При небольшой последовательности команд MOV @PC,R0 поведение обычно предсказуемо. При длинной последовательности начинают возникать глюки, уже более необъяснимые.
По сути - это единственная оставшаяся несинхронность, из-за которой дискретная ситуация в разных циклах теста может отличаться.
Чтобы исключить её возможне влияние - нужно сделать тестовую УКНЦ с одинаковым тактированием ЦП и памяти.
Надо основательно погонять MovPCx на той УКНЦ, где вместо Trap_To_4 происходил BAD Jmp.При длинной последовательности начинают возникать глюки, уже более необъяснимые.
Если ни одного Trap_To_4 так и не случится - это будет очень серьёзный довод в пользу аналоговой теории происхождения трапов. Ведь разница в тактировании ЦП и памяти у всех тестируемых УКНЦ одинаковая.
Кто ее будет делать?
А если надо, то ПП к вашим услугам, там память и процессор тактируются одной частотой, только там память сидит на 8-ми битах, поэтому слово читаться будет за два приема.
А при чем тут аналоговая версия? Сигнал для TRAP4 идет с операционного блока. А разница у разных УКНЦ в тактировании будет, хоть и кварцы стоят, но тоже чуть-чуть могут отличаться.
Разница разная, т.к. тактируются от разных кварцев. А, как известно, у всех кварцев есть погрешность, и биение частот на всех машинах будет разное. Однако, здесь дело скорее всего не в этом.
Чтобы сигнал RPLY на полном серьёзе не выставлялся ( или выставлялся, но не обнаруживался ) в течение интервала ожидания Q-Bus всего лишь из-за ничтожной разницы ( в разных экземплярах УКНЦ ) в тактировании процессора и памяти..
Какой тогда вообще смысл в использовании асинхронной шины между памятью и процессором..
---------- Post added at 12:48 ---------- Previous post was at 12:19 ----------
Аналоговая версия при том, что (на мой взгляд) только из-за проблем с питанием операционный блок может или обнаружить, или не обнаружить на шине RPLY после выполнения одной и той же последовательности команд в одних и тех же ячейках памяти ( ведь даже на одной и той же УКНЦ и при запрещённых прерываниях - Trap_To_4 в конце каждого цикла теста - может произойти, а может и не произойти ).
Весьма похоже, что мы имеем динамический глюк микропрограммы, обусловленный не только "статическими" ошибками в микрокоде, но и различным исполнением одних и тех же микропрограмм при одних и тех же исходных данных.
Т.е. в какие-то моменты происходит сбой в работе "интерпретатора микрокода" - и тогда (при полностью корректной работе шины) происходит "трап на ровном месте" ( такой, как при исполнении команды JMP R0 ).
Есть такой глюк, в зависимости от ситуации после MOV @PC,R0 следующая за ней команда, не нарушающая предвыборки, либо может исполнится два раза, либо вообще пропуститься. А вот с адресацией по счетчику команд обычно всегда получался адрес увеличенный на два, на четыре не удалось.
оффтоп по теме
Скрытый текст
Я всегда подозревал, что роботы живые и рано или поздно они восстанут против человеков ) Что косвенно подтверждается даже примитивных недокомпьютеров типа УК-НЦ ). А если у монстра на ровном месте случится трап? ) Страшно подумать что может случится тогда ! И ещё момент платки как ни крути старые,
даже новенькие УК-НЦ никогда не работали как часики. Хотя я свою помнится сутками не выключал - но перезагрузка занимала значительный % времени от общего. Почти не зависала если простой был, но зависания в процессе отладки программ вполне норм. вещь же ) Трапы - я сейчас лучше конечно понимаю это,
но и тогда Panic Dump мог случится во время операции которая 99 раз работает.
[свернуть]
Последний раз редактировалось hobot; 28.02.2013 в 17:33.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)
Ваши права
Ответить с цитированием