PSW я давно разобрал на составные части, теперь под раздачу попал FPS :) Запускаю сборку всего, что попало под первичное тестирование, завтр (сегодня, сегодня :) ) очередной день тестирования :)
Вид для печати
PSW я давно разобрал на составные части, теперь под раздачу попал FPS :) Запускаю сборку всего, что попало под первичное тестирование, завтр (сегодня, сегодня :) ) очередной день тестирования :)
Всё с предыдущими изменениями более-менее, сегодня - очередной день выправления поведения процессоров на основе тестов.
маленький вопросик (не по теме) - какой ключ у PIP в RSX вместе с копированием файлов создает справочник куда копировать ?
спасибо, а то забыл
Очередной, но не совсем полный распил монолитного процесса в процессоре, скорей - подготовка. И сильное изменение декодера команд. Раньше это был большой if - elsif - elsif - else - end if (на выходе - цепочка мультиплексоров), теперь это отдельные небольшие и относительно небольшие блоки if - end if. На выходе всё равно некоторая цепочка мультиплексоров (предположительно - поменьше), но такое будет легче распилить на отдельные процессы :) Ну и длительная борьба с ошибкой. Сначала вообще не понятно было, что творится (некоторые процы взлтелали, некоторые нет), но постепенно дошло - где, а потом - почему.
Ну а началось всё с того, что некоторые процессоры реагируют на запрос прерывания перед выполнением команды (точнее - большинство), а некоторые - после выполнения (на вскидку, так как с него и началось - PDP-11/35). Ловится в тестах последовательностью типа
Для первых первым отработает запрос на прерывание от консоли, для вторых - выполнится TRAP 0 и потом уже проц посмотрит на запрос прерывания от консолиКод:10$:
TSTB @#177564
BPL 10$
CLR @#177776
BIS #100, @#177564
TRAP 0
Эта цель пока ещё не достигнута, но шаг к ней сделан :)
Уф.... Подобрал такую работу с сигналами, что
а) rt-11 грузится и работает (SJ-XM мониторы)
б) тесты проходят до некоего известного неправильного сбоя в одном из них - не связанного с обработкой запроса на прерывание.
в пункет б - сбой, если я правильно понимаю, связан с прерыванием работы со стеком - предположительно - жёлтая граница. Но это место ещё надо разобрать - правильно ли я понимаю - чего он хочет.
- - - Добавлено - - -
Да, это сбой по жёлтой, а следующий подтест - по красной границе стека в MFPI. Желтую поправил (и тест пошёл дальше), а про красную как-то забыл... :) Через минут 10 можно будет глянуть, что дальше :)
- - - Добавлено - - -
Посмотрел (пока синтезируется), что в тесте дальше (FullODT в этом плане - крайне удобная вестчь на предмет отладки процессора в тестах :) ) - вроде как на достаточно большой кусок никакого криминала быть не должно. Ню будем посмотреть :)
- - - Добавлено - - -
Ну да, ну да - копипаст и ошибки приНём - это наше всё :) Жду нового синтеза :)
- - - Добавлено - - -
Ндя... случай посложней. MFPI извлекает слово по адресу из предыдущего режима, устанавливает флаги и только потом трапается по красной границе стека... А у автора PDP-2011 установка флагов делает по результату выполнения операции - всё гонится, даже простые операции типа пересылки слов, через АЛУ, котороё и выдаёт флажки..
- - - Добавлено - - -
Где то, ЕМНИП память, в PDP-11/70, я уже налетал на похожее отличие в поведении реального проца и подхода в PDP-2011...
- - - Добавлено - - -
Надо подумать...
Решил, что пока сделаю по принципу хака. Но потом надо подумать над тем подходом, который сделал автор - и поменять его. Но это, кстати, занимательный вопрос - что будет с флагами процессора, если команда (по каким то причинам) хряпнулась в середине :) Вот как в этот раз :)
В целом же это поднимает вопрос о том, что существующие команды описаны в доках половинчато. Полное описание должно включать - что будет, если команда не завершила свое выполнение.
Из похожих сценариев - если во время обработки прерывания первый push прошёл, а второй нет, что будет на стеке? И что будет в PSW :)
- - - Добавлено - - -
аХРИНЕТЬ :) я таки добил этот тест :)
- - - Добавлено - - -Код:.R BKTDC0
BKTDC0.BIC
PDP11/40 PROCESSOR STATES TEST, DBKTD-C
#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*
#*#*#*#*#*#*#*#*#*#
BKTF KT11-D abort test - останов по ошибке. Пока не понял, в чём проблема, разбираюсь...
Ну-с, понятно чего тесту не нравится. Опять граничный случай. RTS R5, а при попытке взять слово со стека - трапсссс :)
Бум смотреть - а что думает PDP-2011 по этому поводу :)
- - - Добавлено - - -
Вот даже не понятно, я накосячил или автор такой случай не учёл.. Я склоняюсь к тому, что я некосячил, но..
У автора есть сигнал-параметр have_mmuimmediateabort - когда произойдет отказ в выполнении инструкции - перед микрооперацией или после. И самое интересное, что вариант - ДО - относится только к моделям на основе J11, но этот вариант - ЗАКОММЕНТИРОВАН, то ест этот параметр ВСЕГДА - ПОСЛЕ. Но при этом, насколько я въехал в логику в этом случае - регистр БУДЕТ затронут, но вот что туда запишется - совсем не понятно. И я даже не уверен - а правильно ли я понял, как отработает микрооперации проц..
- - - Добавлено - - -
Вопчем, сделал для RTS вариант - отклонить микрооперацию восстановления регистра из стека, если что то пойдёт не так при попытке снять со стека слово. Посмотрим, что скажут другие тесты и для других моделей процов...
- - - Добавлено - - -
Вдогонку. Есть операции (в основном автодекремент, насколько мне не изменяет память), которые ИЗМЕНЯЮТ значение в регистре, если что то пойдёт не так - но этот сценарий автор принимает во внимение - пусть и не полностью и не для всех процов. На основе тестов я дополнил это поведение, но - это не данный случай - он не про RTS
- - - Добавлено - - -
Тест прошёл дальше :) И опять споткнулся :) Посмотрим на новый кейс :)
- - - Добавлено - - -
Новый кейс - это предыдущий, но вид сверху :) Не RTS с регистром-не-PC, а JSR с регистром-не-PC. Вроде по аналогии должно пройти :)
- - - Добавлено - - -
Кейс прошёл :) Очередной вылез :) Теперь тот же сценарий - но с IOT :)
- - - Добавлено - - -
Не, ошибся. Сценарий другой, но известный - что будет сохранено в стек как PSW, если при попытке прерывания что то пойдёт не так с положением PC и PSW на стек :) То есть что будет в принципе - понятно - новое прерывания а ля red stack (если грохнулись в kernel mode) или прерывания по V4 (если грохнулись НЕ в kernel mode) :)
Вроде поправил.
И очередной выверт. Причём такое, что проц улетает куда то вообще не пойми куда.... Придётся двигаться по шага... Тьфу, по подтестам :)
- - - Добавлено - - -
Ну, место вычислено, где проц дурит :) Теперь посмотрим - что делается - и какой вариант поведения, с точки зрения теста - правильный :)
Кстати :) Технически, я как бы знаю, откуда родилась идея FullODT, но вот то, насколько он окажется СУПЕР ПОЛЕЗНЫМ при отладке процессора - не думал, не догадывался и даже не снилось :) Да, листини тестов - весьма полезная вестчь, особенно из за комментов, но не для всех тестов они есть и самое главное - учитывая возможности того ПЗУ, которое сделал автор - тяжело было бы останавливать тесты в определённых местах, а уж о пошаговом режиме - даже не мечтай.
А с FullODT, несмотря на не весь реализованный функционал (писать он так и не умеет, скажем :) ), несмотря на некоторые огрехи в определённых сценриях.. Отладка процессора ускорилась даже не на порядок :) Да и хрен с ним, что на текущий тест листинга нет :)
- - - Добавлено - - -
Хм.. Странно.. Случай достаточно простой - превышение длины страницы при выборке очередной команды, а проц так клинит... Придётся в очередной раз по микрокомандам посмотреть :)
- - - Добавлено - - -
Вот чего стало сильно не хватать - не выход в FullODT при попытке выполнить команду по заданному адресу, а переход в slow режим при выборке команды по указанному адресу :) Надо будет попробовать сделать :)
- - - Добавлено - - -
Если вкратце, то опять эта хрень с have_mmuimmediateabort. К сожалению, я так и не понимаю - какого автор ввёл этот параметр, учитывая, что (видимо, начиная с какой то версии PDP-2011) он жёстко в одном значении.
Поправил, как мне кажется. И пока синтезируется, попробую посмотреть по другим версиям - чего там с ним и как было
- - - Добавлено - - -
Прошёл дальше :) И очередной затык :) Но хоть не с таким спецэффектами, как прошлый :) Традиционный HALT :)
- - - Добавлено - - -
Они, блин, издеваются :) Что будет в сохранённом в стеке PSW, при попытки записи результата командой ADC в ячейку, доступную только на чтение, когда в PSW в момент выполнения команды были флаги 0001 (то есть установленный бит С) :):) . Правильный ответ - 0001 :)
- - - Добавлено - - -
Повторюсь - Если вкратце, то опять эта хрень с have_mmuimmediateabort :)
- - - Добавлено - - -
Асссссаа :):):)
Из известных мне на текущий момент тестов остались - BKEA (он тестирует FIS, которого, на текущий момент, в составе PDP-2011 нет) и BKTG - KT11-D exerciser - судя по выводу на экран - есть как минимум одна ошибка, но поскольку он тестирует не только процессор - я не знаю, к чему относится ошибка и поэтому пока не будут его гонять... :)Код:PDP-11/35 (124KW) (PDP-2011 based) FullODT for halt mode (in development :))
>>>B HX0
HX 2.2 XXDP Cold boot..
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R BKDMD0
BKDMD0.BIC
***********************
R0=014110 R1=177777 R2=171317 R3=110436 R4=000001 R5=012144
SP=014224 PC=013624 PS=000010
>>>165020G
014110 000001 014224 012144
@L 177544 ; Эмулируемый регистр переключателей - ячейка доступна на запись для задания положения переключателей
@D 10000 ; 12-ый бит - печтать '*' на экран при прохождении теста до конца
@
R0=010000 R1=165202 R2=000100 R3=165212 R4=042040 R5=177544
SP=165212 PC=165354 PS=000004
>>>B HX0
HX 2.2 XXDP Cold boot..
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R BKTAD1
BKTAD1.BIC
######################
KT11-D LOGIC TEST MAINDEC-11-DBKTA-D
******
R0=000000 R1=006006 R2=006006 R3=034100 R4=014100 R5=100157
SP=000774 PC=013220 PS=000000
>>>165020G
000000 014100 000774 100157
@L 177544
@D 0
@
R0=000000 R1=165202 R2=000100 R3=165212 R4=042040 R5=177544
SP=165212 PC=165350 PS=000004
>>>B HX0
HX 2.2 XXDP Cold boot..
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R BKTBB0
BKTBB0.BIC
KT11-D ACCESS KEYS TEST, MD-11-DBKTB-B
*
*
*
*
R0=000000 R1=022152 R2=000017 R3=022150 R4=022151 R5=077400
SP=000776 PC=006702 PS=000004
>>>B HX0
HX 2.2 XXDP Cold boot..
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.BOOTSM
BOOTING UP XXDP-SM SMALL MONITOR
XXDP-SM SMALL MONITOR - XXDP V2.6
REVISION: E0
BOOTED FROM HX0
28KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152010
TYPE "H" FOR HELP
.R BKTCB0
BKTCB0.BIC
MTPI/MFPI WITH MEM MAN, DBKTC-B
* * * * * * * * * * *
R0=001004 R1=004254 R2=001006 R3=030005 R4=120000 R5=155662
SP=001062 PC=004304 PS=030004
>>>B HX0
HX 2.2 XXDP Cold boot..
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R BKTDC0
BKTDC0.BIC
PDP11/40 PROCESSOR STATES TEST, DBKTD-C
* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
R0=040000 R1=006054 R2=000000 R3=030010 R4=177776 R5=170001
SP=000502 PC=006114 PS=000000
>>>B HX0
HX 2.2 XXDP Cold boot..
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.BOOTSM
BOOTING UP XXDP-SM SMALL MONITOR
XXDP-SM SMALL MONITOR - XXDP V2.6
REVISION: E0
BOOTED FROM HX0
28KW OF MEMORY
UNIBUS SYSTEM
RESTART ADDRESS: 152010
TYPE "H" FOR HELP
.R BKTFD0
BKTFD0.BIC
###################
MEMORY MANAGEMENT ABORT TESTS, DBKTF-D
*******
R0=000205 R1=004760 R2=060002 R3=140102 R4=100100 R5=003116
SP=001100 PC=005006 PS=030010
>>>
- - - Добавлено - - -
Теперь синтез всех тестируемых на текущий момент процов - и прогон, что бы понять, не сломал ли чего то, что работало :):)