Используются при работе процессора в HALT-режиме, индикатором которого служит активный низкий уровень на выводе HLTM.
А как эти регистры PAR/PDR (и вообще все регистры MMU) у DEC правильно называются, чтобы я сразу определения забил?
А что такое режим MMU16?
- - - Добавлено - - -
Установка 200 в UPAR1/KPAR1 проигнорирована, 20006 оттранслировался в 00006, то есть - таки PARH0 используется. Итого - адрес VA13 в режиме пульта игнорируется, нечетные 8К совпадают с четными 8К, и PARH0 фиксирован на 0.
В режиме пульта:
000000..017777 -> 000000..017777
020000..037777 -> 000000..017777
- - - Добавлено - - -
157560 отобразилось в 177560, PARH3 со значением 170000? в работе?
Так и называются :
Код:Kernel Active Page Registers User Active Page Registers
No. PAR PDR No. PAR PDR
0 172340 172300 0 177640 177600
1 172342 172302 1 177642 177602
2 172344 172304 2 177644 177604
3 172346 172306 3 177646 177606
4 172350 172310 4 177650 177610
5 172352 172312 5 177652 177612
6 172354 172314 6 177654 177614
7 172356 172316 7 177656 177616
Это режим мапинга при "выключенном" MMU.
- - - Добавлено - - -
Со значением 177600 - ничего другого там быть и не могло.
Меня тоже интересовало, но во всей документации DEC упоминаются только PAR и PDR. По аналогии с PARH мне приходится использовать обозначения PARU/PARK.
Во всей известной мне дековской документации поле ACF содержит 2 бита.
- - - Добавлено - - -
Не используемый в PDR бит 0 формально не входит в ACF, но для простоты иногда при проверке просто берут младшие 3 бита PDR без сдвига вправо.
- - - Добавлено - - -
Используют, но ( скорее всего ) "в стиле MMU16", т.е. только при непосредственной адресации к SP.
.
Следующий тест проверяет работу команды MFPD SP и выход из HALT-моды ВМ3 по команде RTI :
- - - Добавлено - - -Код:.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #140340, @#177776 // Установить USER-моду
Mov #Stop, SP // Стек USER-моды
Mov #340, @#177776 // Установить KERNEL-моду
Mov #2222, SP // Стек KERNEL-моды
HALT // Установить HALT-моду
Wait
Next:
MFPI (PC)+ // Запись следующего слова в стек
.Word 340
MFPD SP // Запись USP в стек
RTI // Выход из HALT-моды на метку Stop
Nop
Stop:
Wait
Также не мешает проверить, откуда прочитаются данные в командах TST @#40000 и TST @#60000.
MFPD SP выполнил KSP->@HSP (а не USP как ожидалось) и возврат произошел на 22228
В тесте занес в KSP нормальный адрес возврата (не 2222): [http://s017.radikal.ru/i402/1601/20/d658b247d229t.jpg]
TST @# 40000/60000 отобразились на адрес 000000
- - - Добавлено - - -
Странно, я смотрел Handbook от 1979 года, там юнибасные машины оказались. А в F-11 и 11/34, да, два бита ACF, так их усерс мануалы говорят. В-общем, к ним ВМ3 ближе всего выглядит.
А как RSХ-11 обходит единичные значения в младших битах SR3? Не пытается режим супервизора включать? Там патчить нужно было?
- - - Добавлено - - -
Я в барахолке сделал запрос на старый ВМ3, 1988 года, посмотрим, может быть у кого найдется такой, интересно будет потестить.
Это означает, что в режиме HALT предыдущая мода вообще не используется командами MFPI ; MFPD ; MTPI ; MTPD - позже проверим это и для режима MMU16.
Команды RTI и RTT принудительно завершают режим HALT в любом случае - как и предполагалось.
Значит, PARH1 тоже содержит 000000.
Прочитал про 1801ВМ4 такое - "содержит 50 тысяч транзисторов, из которых только 3500 не входят в регулярные структуры и не получены путем мультиплицирования. Это дает надежду на осиливаемый реверс 1801ВМ4 ))
.
Тест разрядности HSP ( куда пойдёт пуш при HSP = 000000 ) и тест MFPI SP в режиме MMU16 :
Код:.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 24
.Word Start // Адрес старта.
.Word 340
. = 112
Trap:
Jmp R0 // Записать код 114 [ Jmp (R4) ] по адресу 000000
Start:
Mov #2222, SP
MFPI SP // Какой SP запишется при MMU16 ?
HALT // Установить HALT-моду
Wait
Next:
Mov #Next1, R4
Br Trap
Next1:
MFPI SP // Куда запишется KSP при HSP = 000000 ?
Wait
HSP переставился на 177776 и обратилось к PSW (на шине не видно транзакции) [http://s020.radikal.ru/i723/1601/c3/c763cae7adc4t.jpg]
Значит - HSP реализован, как стандартный 16-битный регистр.
Команда MFPI SP в режиме MMU16 записала 002222 по адресу 002220.
- - - Добавлено - - -
Следующий тест проверяет, происходит ли запись до прерывания при словном обращении по нечётному адресу в режимах MMU16 и HALT :
Код:.ASect
. = 0
Jmp @#Next // Точка входа пульта.
. = 4
.Word L1
.Word 0
. = 24
.Word Start // Адрес старта.
.Word 340
Start:
Mov #177777, R0
Mov #6, R4
Mov #7, R5
Mov #2222, SP
Mov R0, (R5)
L1:
Tst (R4) // Что по адресу 000006 ?
HALT // Установить HALT-моду
Wait
Next:
Mov #Next1, @#4
Clr (R4) // Очистить ячейку 000006
Mov R0, (R5)
Nop
Next1:
Tst (R4) // Что по адресу 000006 ?
RTT
Разобрал в профильной теме по пунктам почему с RSX-11 проблем на ВМ3 нет.
Перенесем сюда результаты, касающиеся данной темы.
Программа MTPS.SAV включает MMU, сохранив до-MMUшный маппинг страниц с полным доступом для user и kernel mode и проверяет что будет если из пользовательского режима выполнить MTPS #347 при разрешенном и запрещенном доступе к I/O page. Большинству процессоров (по идее все кроме 11/34) пофигу отображен ли PSW на странице ввода-вывода, а MTPS из пользовательского режима может менять только CVZN. В 11/34 и на СМ1420 ситуация другая:Чисто формально можно проверить ВМ3 (раз уж RESORC его тоже обзывает 11/34, хотя общего у него с ним мало) :)Код:.MTPS
UISDR7=077406, PSW=170000, MTPS #347, PSW=170347
UISDR7=077400, PSW=170000, MTPS #347, PSW=170000, MMU FAULT
На ВМ3.
Код:UISDR7=077506, PSW=170000, MTPS #347, PSW=170347
UISDR7=077400, PSW=170000, MTPS #347, PSW=170011, MMU FAULT
Анализатор всю диаграмму за один проход не захватывает, разбил на две (синхро по фронту ACLO и срезу HLTM):
Часть1: [http://s013.radikal.ru/i323/1601/de/5d314a7f0d97t.jpg]
Часть2: [http://s018.radikal.ru/i502/1601/1b/938e421517b7t.jpg]
Пожалуй надо кое-что добавить в тест для разрешения неясности.
- - - Добавлено - - -
Обновил прогу, хотя неоднозначности похоже не было. Но так хуже не будет.
- - - Добавлено - - -
На 1/83 привычный результат...
Код:.RU MTPS
UISDR7=077406, PSW=170000, MTPS #357, PSW=170017
UISDR7=077400, PSW=170000, MTPS #357, PSW=170017
.
В исходниках RT-11 так:
Выдернуто из текста VM.MAC, такой же таблицы в RMONFB.MAC и в XMSUBS.MAC я наскоком не нашел, но имена KISARn, KISDRn и остальные встречаются в них повсеместно.Код:MMSR0 = 177572
MMSR1 = 177574
MMSR2 = 177576
MMSR3 = 172516
UISDR0 = 177600
UISDR7 = 177616
UISAR0 = 177640
UISAR7 = 177656
KISDR0 = 172300
KISDR7 = 172316
KISAR0 = 172340
KISAR1 = 172342
KISAR7 = 172356
Похоже выявлен ище один косяк ВМ3. Не страшный, но тем не менее :)
- - - Добавлено - - -
Выложил там же.
- - - Добавлено - - -
Так никто не называет. KPAR/KISAR, KPDR/KISDR. KPAR/KPDR - старый вариант когда не было разделения I&D и режима супервизора. Для ВМ3 впрочем это в силе.Цитата:
Сообщение от Vslav
- - - Добавлено - - -
Подозреваю, что совсем в подробностях не будет - обращения к PSW как я понимаю идут внутри проца и внаружу не светятся.
Интересно еще раз проверить обновленный тест, в частности PSW после команды которая вызывает сбой.
2 вариант MTPS на ВМ3.
Код:UISDR7=077506, PSW=170000, MTPS #357, PSW=170357
UISDR7=077400, PSW=170000, MTPS #357, PSW=170011, MMU FAULT
Получается интересная картина: команда вызывает прерывание MMU, попутно меняя биты C и N в PSW.
Также судя по первой операции, MTPS отмечается в MMU как запись в 7 страницу. На СМ1420 такого не наблюдалось.
- - - Добавлено - - -
Еще интересен такой тест (последней прогой):Если используется советский SL, его нужно предварительно отключить - не дружит он с SIPP и некоторыми другии прогами :)Код:.SIPP MTPS.SAV/A
Base?
Offset? 1316
Base Offset Old New?
000000 001316 000357 17
000000 001320 104400 ^Y
.RU MTPS
form, Что за SIPP? С ним прога не идет.
В чем проявляется что она не идет? SIPP редактирует файлы. Циферки совпадают с теми что в сообщении?
- - - Добавлено - - -
Можно и без SIPP чтобы не ломать оригинал:Код:.GE MTPS
.E 1316 ! ПРОВЕРЯЕМ, ЧТО ПИШЕМ ТУДА
000357
.D 1316=17
.ST
UISDR7=077406, PSW=170000, MTPS #357, PSW=170017
UISDR7=077400, PSW=170000, MTPS #357, PSW=170017
.
?UCL-F-Command does not exist
Удивительное дело - в режиме MMU16 при словной записи по нечётному адресу - процессор не произвёл запись, но до входа в прерывание успел выполнить следующую команду. В режиме HALT такого не случилось и всё отработало как надо.
- - - Добавлено - - -
На системном диске отсутствует файл SIPP.SAV