Запуск VM2T18:
Запуск VM2T18:
Запуск VM2T19 (думаю, что везде возможен и результат 10000):
Похоже, удалось найти ошибку в тесте VM2T20.SAV из-за которой он не выдерживал встречи с МЕГА-глюком.
Теперь в указанном архиве уже новая исправленная версия теста.
Результат запуска в эмуляторе такой:
Код:.RU VM2T20
1801VM2 MegaBUG test #20 v1.1
01044 BiS #100, @#TTPS
01046 Mov (PC), R0
01050 >>> Interrupt <<< 064
01050 Mov (PC), R0
01052 Tst R0
01054 BiC #100, @#TTPS
01102 BiS #100, @#TTPS
01104 Mov (PC), R0
01106 >>> Interrupt <<< 064
01106 Mov (PC), R0
01110 BiC #100, @#TTPS
Program completed.
.
Прохождение теста такое же.
Аналогично и на УКНЦ, запускал много раз, результат такой же.Цитата:
Сообщение от Patron
В смысле - прерывания проходят штатно и глючные команды их вовсе не запрещают.Цитата:
Сообщение от Alex_K
Ну как видите, ничто не препятствует. Ведь блок обработки прерываний всё-таки поприоритетнее будет, в этом случае очищается предвыборка, ну и глюка не будет.Цитата:
Сообщение от Patron
Мы помним прерывания по вектору 024 после глючного выполнения NOP и вряд ли такие прерывания могут возникнуть в глючном коде при запрещённых прерываниях. Значит - глюк вполне может заменять принимаемый процессором адрес вектора.Цитата:
Сообщение от Alex_K
Но если глюкогенные команды не запрещают прерывания - не понятно, как длина последовательности таких команд может влиять на вероятность возникновения Trap_to_04 в момент выполнения команды NOP ( при том, что адрес в стеке после прерывания указывает на следующую за NOP команду ).
Прогнал тест на плате М6Цитата:
Сообщение от Titus
Всё ОК кроме операций DIV
Откровенно говоря, думал что будет как в Эл.85 но оказывается есть различия.Код:Команда деления (частичный тест):
DIV (even) - ERROR: 0x9E4А / 0x9Е46
DIV (odd) - ERROR: 0x43D5 / 0xBAA7
Различия ( по крайней мере в части эталонной контрольной суммы ) похоже вызваны различным алгоритмом тестирования в применявшихся тестах.Цитата:
Сообщение от MiX
Возможно что в тот раз была версия теста 0.2, но вроде др. Титус в 0.3 добавил только MARK тест.
Да.Цитата:
Сообщение от MiX
Ну и как тогда у двух тестов могут различаться ВСЕ контрольные суммы - и измеренные, и эталонные ..
---------- Post added at 16:02 ---------- Previous post was at 15:56 ----------
Получается, что на тестируемом процессоре подпрограмма печати 16-ричного значения выводит на экран неизвестно что.
Значит тот тест был версии 0.1.
Прогнал тест 0.3а на Эл.85
результат не отличается от теста 0.3а на плате М6.
Лучше ответить в этой теме, более соответствует. На УКНЦ с процессором 1801ВМ2 результаты аналогичные, потому скриншот и не выкладываю.Цитата:
Сообщение от Patron
---------- Post added at 18:44 ---------- Previous post was at 18:37 ----------
Из описания исполнения RTI на 1801ВМ2:
"...Если при загрузке нового PSW устанавливается бит T в PSW, то отладочное прерывание будет вызвано до исполнения первой команды нового процесса. Если перед исполнением RTI был установлен T-бит, а при загрузке нового PSW он очищается, то в этом случае всё равно будет вызвано отладочное прерывание, но в стеке сохранится уже новое PSW без установленного бита T. ..."
Особенности RTT:
"... Единственным отличием является то, что если при загрузке нового PSW устанавливается бит T, то после исполнения RTT не запускается блок обработки прерываний, и соответственно выполняется команда нового процесса. ..."
Из этой особенности следует, что если при возврате по RTT бит T не был установлен, то блок обработки прерываний не пропускается.
На 11/83:Код:.BO RT11SB
Foreground loaded; Are you sure? Y
RT-11SB (S) V05.07
.SET TT QUIET
?ETM-I-Date & time - 11-FEB-2015 19:22:55
?ETM-I-Time server - 70-71-BC-50-EB-D0, OpenBSD 5.5 amd64
.R DATE
.AS D10 DK
.RU TTST6
LSI-11 Traps Test #6
Mov #00,-(SP)
Mov #L2,-(SP)
Mov #20,-(SP)
Mov #L1,-(SP)
RTT
L1: RTI
L2:
NOP
Mov #00,-(SP)
Mov #L4,-(SP)
Mov #20,-(SP)
Mov #L3,-(SP)
RTT
L3: RTT
L4:
NOP
.
---------- Post added at 20:43 ---------- Previous post was at 19:24 ----------
А вот интересно, как ВМx ведут себя если в @#16 записать 20 и сделать BPT?
На *J11 процессорах это один из 4 случаев когда придется останавливать проц сигналом BHALT.
У ВМ1 и ВМ2 после выхода указателя стека за пределы памяти возникает двойная ошибка шины.Цитата:
Сообщение от form
Ну вобщем-то так и предполагал.Цитата:
Сообщение от Patron
На 11/83 все зависает, если остановить вручную - SP будет равен 0 и тот факт, что SP в кернел моде не может безнаказанно пересечь зловещие 400 не спасает :)
---------- Post added at 23:24 ---------- Previous post was at 21:24 ----------
Попутно для общего развития тест прерывания по небольшому переполнению стека.
Выполняет последовательно команды (при SP=400):Первая из них ждет пока таймер вызовет прерывание и тем самым опустит SP ниже 400, остальные команды сами действуют на SP.Код:BR .
EMT 350
TST -(SP)
CALL @#EXSUB
Программа теста
Код:.TITLE YELL -- ТЕСТ YELLOW STACK TRAP
.MCALL .EXIT,.PRINT
;+
;ТЕСТ ПОСЛЕДОВАТЕЛЬНО ВЫПОЛНЯЕТ ПРИ SP=400 КОМАНДЫ:
; BR .
; EMT 350
; TST -(SP)
; CALL @#EXSUB
;-
START:: MOV #CODES,R3 ;R3=ТАБЛИЦА КОМАНД
MOV @#4,SAVE ;СОХРАНЯЕМ ВЕКТОР
MOV @#6,SAVE+2 ; 4
MOV #ODINT,@#4 ;УСТАНАВЛИВАЕМ ОБРАБОТЧИК
MOV #340,@#6 ; ПРЕРЫВАНИЯ
DOTST:: MOV #ARGS,R2 ;R2=БЛОК АРГУМЕНТОВ $EDMSG
MOV #INSTR,(R2)+ ;АДРЕС ТЕСТИРУЕМОЙ КОМАНДЫ
ASR SP ;SP=400
INSTR:: BR . ;ТЕСТИРУЕМАЯ КОМАНДА
.WORD EXSUB ;ВТОРАЯ ЧАСТЬ ОТ КОМАНДЫ CALL
PRINT:: MOV #BUFF,R0 ;R0=БУФЕР
MOV #DUMP,R1 ;R1=ФОРМАТНАЯ СТРОКА
MOV #ARGS,R2 ;R2=БЛОК АРГУМЕНТОВ
CALL $EDMSG ;ФОРМАТИРУЕМ СООБЩЕНИЕ
.PRINT #BUFF ;ПЕЧАТАЕМ
MOV (R3)+,INSTR ;СЛЕДУЮЩАЯ ИНСТРУКЦИЯ
BNE DOTST ;ЕСЛИ 0 - ВСЕ
MOV SAVE,@#4 ;ВОССТАНАВЛИВАЕМ ВЕКТОР
MOV SAVE+2,@#6 ;
EXSUB:: .EXIT ;ВЫХОД
ODINT:: MOV SP,R0 ;СОХРАНЯЕМ SP
MOV #START,SP ;ВОССТАНАВЛИВАЕМ
MOV R0,(R2)+ ;SP
MOV (R0)+,(R2)+ ;@SP
MOV @R0,(R2)+ ;2(SP)
CLR -(SP) ;ВОЗВРАТ
MOV #PRINT,-(SP) ; НА
RTI ; ПП ПЕЧАТИ
CODES:: .EXIT ;EMT 350
TST -(SP) ;TST -(SP)
CALL @#0 ;CALL @#EXSUB
SAVE: .BLKW 2
ARGS: .BLKW 4
BUFF: .BLKB 64.
DUMP: .ASCIZ /%P: SP=%P, @SP=%P, 2(SP)=%P/
.END START
[свернуть]
Результаты показывают, что в случае возникновения прерывания или вызова подпрограммы, сначала проходит сохранение в стек, потом устанавливается PC/PS, а потом происходит прерывание по 4, что позволяет обработчику прерываний просто вернуться назад по RTI (предварительно проверив в регистре CPUERR, что это yellow stack trap) и тем самым продолжить выполнение в надежде что остатков стека хватит :)
Код:.EX YELL/LINK:SY:RSXLIB
001046: SP=000370, @SP=133014, 2(SP)=000341
001046: SP=000370, @SP=120760, 2(SP)=000000
001046: SP=000372, @SP=001050, 2(SP)=000004
001046: SP=000372, @SP=001122, 2(SP)=000000
.E 30
120760
.E 100
133014
.
Цитата:
Сообщение от form
Что скрыто за этими вызовами?Цитата:
Сообщение от form
Можно ли (имеет ли смысл) например этот тест запустить на УК-НЦ под RT-11?
Каким образом и можно ли RSXLIB использовать? - я наверное пропустил если
есть эта OBJ для RT-11? Есть ли в этой библиотеке (если её можно использовать
под RT-11), что нибудь супер крутое и полезное, описание аналогичное SYSMAC.HLP существует?
RSXLIB я описывал в теме софта, на сайте у меня вроде тоже с описанием лежит, также HELP на CTAKAHе поможет :)Цитата:
Сообщение от hobot
На УКНЦ смысла запускать нет - там нет защиты от переполнения стека и тест просто зависнет на первой же команде.
Цитата:
Сообщение от form
вне темы
Я у себя нашёл папку в хламнике form_rsxlib
там вот такое вот содержание
Я так понимаю это вариант для RT-11?Код:Image : rsxlib.dsk
Format : DSK
Size : 400 Kb
Volume ID: ON (OBJECT C
Owner : OUNT)=P/
File Blocks Date Bytes
---------- ------ ----------- ----------
ARITH .MAC 6 14-Mar-2013 3'072
C5TA .MAC 4 14-Mar-2013 2'048
DARITH.MAC 6 14-Mar-2013 3'072
OD2CT .MAC 10 14-Mar-2013 5'120
SAVAL .MAC 4 14-Mar-2013 2'048
SAVRG .MAC 3 14-Mar-2013 1'536
SAVR1 .MAC 2 14-Mar-2013 1'024
SAVVR .MAC 3 14-Mar-2013 1'536
MKLIB .COM 1 14-Mar-2013 512
CBTA .MAC 13 14-Mar-2013 6'656
CDDMG .MAC 4 14-Mar-2013 2'048
CVTUC .MAC 4 14-Mar-2013 2'048
EDDAT .MAC 8 14-Mar-2013 4'096
GTTIM .MAC 4 14-Mar-2013 2'048
CATB .MAC 10 14-Mar-2013 5'120
CAT5 .MAC 6 14-Mar-2013 3'072
CAT5B .MAC 6 14-Mar-2013 3'072
EDTMG .MAC 37 14-Mar-2013 18'944
RSXLIB.OBJ 11 14-Mar-2013 5'632
< UNUSED > 644 329'728
---------- ------ ----------- ----------
19 Files, 142 Blocks
644 Free blocks
Надо бы описание к ней найти и в архив, я похоже начал и отвлёкся.
Поэтому и уточняю.[свернуть]
Обнаружил интересную вещь:Тест с помощью команды RTI устанавливает бит дополнительного набора регистров R0'-R5' и снова сбрасывает его, возвращаясь к R0-R5. И в E11 и в SimH бит успешно устанавливается, но сбросить его назад таким способом можно только в режиме ядра (тест под RT-11SB). Если процессор находится в пользовательском режиме (тест под RT-11XM), то бит устанавливается, но не сбрасывается.Код:.TITLE TEST
.MCALL .EXIT,.PRINT ;МАКРОКОМАНДЫ
PSW =: 177776 ;PSW
START:: MOV #PVAL,R0 ;XXX: АДРЕС ДЛЯ .PRINT
MOV #4000,-(SP) ;PS
MOV #10$,-(SP) ;PC
RTI ;КУ!
10$: CLR -(SP) ;PS
MOV #20$,-(SP) ;PC
RTI ;КЮ!
20$: MOV @#PSW,R1 ;КОНВЕРТИМ
MOV #RVAL,R0 ; ЗНАЧЕНИЕ
MOV PC,R2 ; PSW
CALL $CBOMG ; В ASCII
.PRINT #PVAL ;ПЕЧАТАЕМ
.EXIT ;ВЫХОД
PVAL: .ASCII /PS=/
RVAL: .ASCIZ /XXXXXX/
.END START
Пока не знаю правильное это поведение или нет - дома проверю вечером (эх, пора управляемый дистанционный выключатель приделывать к 11/83 :)). Интересно было бы проверить это на ментековских платах.Код:.BO RT11SB
RT-11SB V05.07
.RU TEST
PS=000000
.BO RT11XM
RT-11XM V05.07
.RU TEST
PS=144000
.
Вычитал описании KDJ11-B (про усер моду ничего не написано): When executing in kernel mode, either a 1 or a 0 can be stored in PSW bit 11. When executing in supervisor mode, a stored 0 can be changed to a 1, but a stored 1 cannot be changed to a 0.
PS. Для hobot: $CBOMG - в оригинале из RSX, но в RT-11V5 это стандартная подпрограмма SYSLIB (хотя в доках по RT-11 она и не упоминается) ;)
Собираюсь в ближайшее время очередную порцию предложений писать по E11. В связи с этим, может ли кто сформулировать особенности выполнения некоторых команд (ASR/ASH/MUL/DIV итд) которые тут тестировались давеча (чтобы не копаться в истории), попробую кое-какие предложения протолкнуть (интересует ВМ3) :)
Проверил на живом 11/83 - все также как в эмуляторе. Просто в документации не упомянуто, что в усер моде также.Цитата:
Сообщение от form
---------- Post added at 18:24 ---------- Previous post was at 17:49 ----------
А вот это совсем не как на живом железе - так и не поправилось, надо снова пнуть :)Должно быть:Код:.TY RED.MAC
START:: MOV #160004,SP
BR .
.END START
.RU RED
%HALT
?Bad kernel stack
R0/001004 R1/000104 R2/001000 R3/105000 CM=K PM=K PRIO=7
R4/074004 R5/136316 SP/160000 PC/140602 N=0 Z=0 V=0 C=0
140602 rol @#000052
E11>
Код:.RU RED
?MON-F-Trap to 4 001004
.E 0-2
001004 000010
.
Ой! Мне казалось, что это появилось где-нибудь на 73-й. Тогда, должен заметить, со стороны инженеров DEC это глубокий прокол.Цитата:
Сообщение от form
Вместе с какими системами? Которые управлялись посредством этой PDP-11? Неудивительно, ибо "работает - не трожь!" Intel 80386, вроде-бы, и до сих пор выпускают, примерно из тех же соображений.Цитата:
Сообщение от form
RT, RSX, RSTS...Цитата:
Сообщение от AFZ
К сожалению у нас в стране не так :)Цитата:
Сообщение от AFZ
form, Кстати, а как пользоваться командой WAIT ? В русской литературе я так и не нашел внятного объяснения. Вот я при закрытых прерываниях проверил все флажки, все пусто, надо ждать. Я разрешаю прерывания, висящее необслуженным прерывание срабатывает. его программа взводит флаг, делает RTI, а у меня тут подоспеет команда WAIT, и все...
Классических решений этого два: либо состояние ожидания вводится одновременно с разрешением прерываний (например, у системы-360 бит ожидания входит в состав PSW и загружается одной командой LPSW вместе с битами разрешения прерываний), чего у нас нет, или команда разрешения прерываний срабатывает отложенно, после выполнения следующей за ней команды, о чем я, как раз, не нашел никаких внятных сведений. Особенно учитывая, что прерывания можно разрешить не одной командой, а несколькими (RTI, MTPS, прямой записью в регистр PS, если он есть на шине...) Так как?
Однозначного ответа на вопрос нету. В общем случае, WAIT не предназначен для ожидания конкретного прерывания, а нужен чтобы приостановить выполнение когда делать вообще нечего до любого асинхронного прерывания. В родном софте от DEC есть немало закладок на предположения как что должно работать, что может вызвать много проблем с эмуляторами (в том числе вроде был пример на тему WAIT который никогда не выйдет). В документации по E11 целая глава посвящена этому. Примечательно, что на VAX вроде подобной команды просто нету.Цитата:
Сообщение от AFZ
То есть, похоже на еще один прокол инженеров DEC.Цитата:
Сообщение от form
Естественно. Вот мой диспетчер задач проверяет все TCB (Task Control Block), все чего-то ждут, делать нечего. Логично уйти на ожидание, то есть разрешить прерывания и сделать WAIT. Однако, пока я проверял свои TCB, пришел запрос на прерывание и ждет, когда их разрешат. Я, не зная об этом, разрешаю прерывания, допустим, делаю MTPS #0, ожидающий запрос сработает, программа отметит в одном из моих TCB, что появилась работа и выйдет по RTI, а у меня следующая команда WAIT. Приплыли. В общем, не зря я ее не использовал в своих многозадачках...Цитата:
Сообщение от form
Нет. Читаем внимательно: WAIT предназначен для выполнения когда вообще нечего делать. То есть если мы выполняем команду WAIT, значит мы и должны на ней висеть до упора пока не возникнет прерывание которое должно снять с нее. Если же таковое возникло - оно и снимет с WAIT. Все просто. Главное - не изобретать умных конструкций. Типичная работа с командой WAIT - это WAIT, BR .-2. Все.Цитата:
Сообщение от AFZ
---------- Post added at 20:31 ---------- Previous post was at 20:29 ----------
Или если так проще будет: есть процесс который ничего не делает кроме WAIT, BR .-2 который стоит в общем планировании в самом низу. Когда больше нечего делать - он и "выполняется", когда есть чего - он и не получает управления...
Что-то в этом есть. То есть добавить в список задач задачу NHD (нечего делать), которая всегда активна, но с минимальным приоритетом, с учетом этого всегда найдется готовая к исполнению задача. Что же, тоже вариант...Цитата:
Сообщение от form
Такая задача в классических вытесняющих ОС реального времени всегда есть, называется idle.Цитата:
Сообщение от AFZ
Естественно. Я тут размышляю как бы это дело прикрутить к неклассической самоделке с корпоративной (скорее, кооперативной) многозадачностью. Платформа у меня, конечно, поновее, но красивые идеи не стареют, многое, подсмотренное в недрах ОС тех времен (начиная с ДОС-360/370) легко и удобно применяется и сейчас.Цитата:
Сообщение от Vslav
Угу. Во "взрослой" вытесняющей многозадачке, там. где диспетчер задач сам отбирает управление у любой задачи, если появилась более приоритетная. А вот в корпоративной - изба фигвам, там любая задача сама должна вернуть управление диспетчеру в тот момент, когда она считает это возможным. И с применением команды WAIT задача idle в такой системе не получается, не зря я на Э-60 делал бОльшую часть диспетчера задач при открытых прерываниях, а вместо ожидания просто зацикливал эту часть.Цитата:
Сообщение от form
Если задача idle может получить управление только при отсутствии других активных задач, то вполне очевидно, что любая другая задача может активироваться только в результате прерывания.Цитата:
Сообщение от AFZ
А есть идея как придумать какую-либо причину для активации без появления какого-либо прерывания? :)Цитата:
Сообщение от Patron
---------- Post added at 16:11 ---------- Previous post was at 16:10 ----------
А кто мешает именно вернуть ему? :)Цитата:
Сообщение от AFZ
А уж диспетчер если надо активирует нуль-задачу которая будет на особых правах - ее сам диспетчер может снять, получив сигнал в виде прерывания (или ему сигнал передадут из хандлеров прерывания).
---------- Post added at 16:14 ---------- Previous post was at 16:11 ----------
На тему активации интересно почитать описание директивы WSIG$ - это директива в RSX-11 системах, ожидающая любого важного события (которое заставит диспетчер задач пересмотреть очередь), обычно используется в случае если не хватает ресурсов на что-нибудь, а отделаться сообщением об ошибке будет неправильно.
Об том и речь - если активной осталась только задача idle, то эта ситуация в принципе не может измениться без прерывания, а значит вполне уместно использовать WAIT.Цитата:
Сообщение от form
Ага, а Солнце восходит на востоке.Цитата:
Сообщение от Patron
Как кто? Команда WAIT, вестимо.Цитата:
Сообщение от form
Люди, вы себе плохо представляете, что такое корпоративная многозадачка. Это же просто банальный перебор таблицы задач и прямой вызов CALL'ом подпрограммы, исполняющей ту или иную задачу. Адрес которой, обычно, задан в той же таблице. Только в системах с детерминированным поведением команды ожидания, обычно, эта часть исполняется при закрытых прерываниях, прерывания разрешаются только перед CALL'ом, а если делать нечего, то вводится состояние ожидания.
На любимой PDP-11, с ее индетерминированным поведением команды WAIT, приходится перебор задач делать при открытых прерываниях, закрываются они только непосредственно перед CALL'ом для пометки "взято на исполнение" в таблице задач, каковую пометку я, обычно, делал командой TRAP.
А программы обслуживания прерываний просто отмечаются в той самой таблице задач, и все.
Если в такой системе есть синхронные системные вызовы, то это Вы не вполне представляете, что такое корпоративная многозадачка. Потому что смысл синхронности системного вызова как раз в том, что управление не может быть возвращено в сделавшую вызов задачу до завершения обработки вызова в ядре. В результате рано или поздно складывается ситуация, когда все задачи ждут завершения системных вызовов и не могут быть вызваны. В такой ситуации вызывается задача idle.Цитата:
Сообщение от AFZ
В какой бы момент не произошло прерывание - выход из прерывания не может произойти в задачу idle, поэтому использование там команды WAIT совершенно безопасно. Если выход из прерывания может сразу попасть в задачу idle - значит система содержит ошибки. В нормально работающей системе возврат из прерывания сразу в задачу idle без "захода в ядро" абсолютно невозможен при любых раскладах.