СогласенЦитата:
Сообщение от Alex_K
Но по любому
не понятноЦитата:
Сообщение от Titus
Вид для печати
СогласенЦитата:
Сообщение от Alex_K
Но по любому
не понятноЦитата:
Сообщение от Titus
Я исходил из того, что поле 00R00 - это всегда источник, а поле 000NN - это приемник, поэтому так и назвал.Цитата:
Сообщение от Alex_K
Хотя, в командах расширенной арифметики получается, что наоборот.
Можно переименовать в микрокоде, если смущает.
- - - Добавлено - - -
Проверка 'if (Rd=R7) GOTO 0x21' на шаге 0x0C - это универсальный рудимент от других команд, использующих же этот шаг.
Для MUL он бессмысленный.
Код команды 070RSS, так что SS - это источник, а регистр R - приёмник.Цитата:
Сообщение от Titus
Это я вижу, но декодируется все универсально и одними и теми же методами. Правое поле универсализировано, как источник.Цитата:
Сообщение от Alex_K
Поэтому и проверка в конце команды Rd=R7, предполагая, что Rd закодирован правым полем.
Перепишу микрокод для MUL, чтобы не путать общественность)
- - - Добавлено - - -
Поменял поля местами в описании
Так всё-таки проверяет Rs?Цитата:
Сообщение от Titus
Он проверяет тот регистр, который закодирован правым полем.Цитата:
Сообщение от Alex_K
Во всех командах там Rd, а в MUL - Rs. Поэтому проверяет он Rs, т.е. то, чего проверять не надо.
Забавный глюк должен получиться, если в качестве R будет R6 или R7. Надо попробовать на реале.Цитата:
Сообщение от Titus
Ну, как я уже говорил выше, в процессоре есть схема, которая отслеживает запись в R7 независимо от того, чего понаписано в микрокоманде.Цитата:
Сообщение от Alex_K
Я не разбирался в деталях еще, но судя по всему, она сбрасывает кеширование, так что все будет разрулено.
А зачем тогда проверка в микрокомандах идёт, и переход или на 0x01 или на 0x21?Цитата:
Сообщение от Titus
Я думаю, что это сделано для ускорения.Цитата:
Сообщение от Alex_K
Если отдать все на откуп стандартной микропрограмме извлечения следующей инструкции, то будет:
0x01 - попытка выборки кэшированного слова, но его нет. Тогда перейдем на 0x21
0x21 - кэшировать слово
0x01 - попытка номер два. Бинго!
А если проверка будет в самом обработчике конкретной инструкции, то сразу пойдем на шаг 0x21, не делая лишних телодвижений через недействительный шаг 0x01.
Таким образом, проверка в конце команды ускоряет выполнение на 4 такта, в случае, если кэш недействительный из-за записи результата в R7.
И всё-таки глюк есть. Короткая программа:
При умножении происходит переход на адрес 02020, останов на 02022, но перед этим исполняется INC R0, которая читается по предвыборке.Код:1000 CLR R0
1002 MOV #2,R3
1006 MUL R3,R7
1010 INC R0
- - - Добавлено - - -
Ещё интереснее, если вместо INC R0 поставить команду перехода BR, код 0410. Тогда адрес останова становится равным 02042. Во как.
- - - Добавлено - - -
А если поставить команду CLR PC (код 005007), то переход на адрес 0, останов на 2.
- - - Добавлено - - -
А если в ячейку 01010 занести код 0137 (JMP @#....), а в ячейку 02020 значение 05000, то произойдёт переход на адрес 05000.
Надо запросить у @Vslav'а модель для данных случаев.Цитата:
Сообщение от Alex_K
Возможно тесты Patron'а пригодятся, ПКМ ссылка в данной теме лишней не будет?
http://archive.pdp-11.org.ru/ukdwk_a...t/TESTY_FORUM/
На J-11 ошибки нет :)
Не удивительно, ведь ВМ2 не является ни чьей копией, а свой собственный)Цитата:
Сообщение от Hunta
- - - Добавлено - - -
Проанализируем ситуацию.Цитата:
Сообщение от Alex_K
Микропрограмма выборки кэшированной инструкции (адрес 0x01) принимает решение о перекешировании, если IX1=1.
IX1=1, если совпало одно из условий:
1. Совпало условие блока условий (BRA=1). В нашем случае неактуально, т.к. проверка условий не запрашивалась.
2. Был активен RCMD_SET. Не разбирался, но это что-то из блока таймаута и блока модификации кэша, когда записали новое значение по адресу, на который указывал R7.
3. Предыдущая инструкция была двухоперандная (в битах 14,13,12 был не 000), при этом в поле приемника (биты 8,6,7) был закодирован R7. Условие двухоперандности совпадает, но вот в поле приемника у нас не R7, а R6.
Итого, условие перекеширования невыполнено. А значит используем кэш (BIR), а там у нас предыбранная команда по старому адресу.
Поэтому и получается, что первое слово выбирается по адресу следующему за MUL, а следующее по адресу перехода.
Причем, именно по адресу перехода, а не по адресу перехода + 2, как можно было бы предположить.
А все потому, что был пропущен шаг 0x21, который занимается перекешированием инструкции по адресу PC2, затем делает PC2=PC2+2.
Поэтому при отработке шага 0x01 у нас в PC2 все еще адрес перехода, а не адрес перехода+2.
- - - Добавлено - - -
Я думаю, что если задать регистр приемник R7, а не R6, то глюка не будет.
Вечером прогоню.Цитата:
Сообщение от Titus
Цитата:
Сообщение от Titus
Titus, а где это вы видел в моём тест использование R6? В качестве приёмника я использовал именно R7, чтобы не портить указатель стека, и чтобы использовался только один регистр, а не два.Цитата:
Сообщение от Titus
Действительно)Цитата:
Сообщение от Alex_K
Значит нужен тест с R6)
- - - Добавлено - - -
Тогда нужен тест на модели, и чтобы обязательно был видны поля NA и IX и RI.
Все подтверждается:
Код:148 001000 . = 1000 ;
149 001000 005000 tst0: clr R0
150 001002 012703 000002 mov #2, R3
151 001006 070703 mul R3, PC
152 001010 005200 inc R0
153
154 001012 .blkw 2000
Скрытый текст
Вариант с br (410)
Код:148 001000 . = 1000 ;
149 001000 005000 tst0: clr R0
150 001002 012703 000002 mov #2, R3
151 001006 070703 mul R3, PC
152 001010 000410 .word 410
153 001012 005200 inc R0
154
155 001014 .blkw 2000
Скрытый текст
Вариант mul R3,SP
Скрытый текст
Как я понимаю, пока читается ячейка с адресом 02020 (считается по предвыборке), исполняется команда из ячейки 01010, потому и BR переходит на адрес 02020+010*2.Цитата:
Сообщение от Vslav
А какое было значение SP?Цитата:
Сообщение от Vslav
Кажется, я вижу, откуда ножки растут.
Попробуйте сделать тест, в котором команда, предшествующая делению, с простой адресацией типа MOV Rx,Rx:
- - - Добавлено - - -Код:0776 CLR R0
1000 MOV #2,R3
1004 MOV R3,R3
1006 MUL R3,R7
1010 INC R0
Хотя, нет, не надо делать.
- - - Добавлено - - -
В общем, нашел ошибку.
Блок, который призван идентифицировать двухадресную команду ((код & 0x7FFF)> 0x0FFF), у которой в качестве Rd указан R7, имеет ошибку или особенность следующего плана.
Триггер U577, запоминающий состояние IX1 обновляется при выборке каждой микрокоманды.
А IR_STB выдается только при выборке первой микрокоманды инструкции.
Поэтому в во время первой микрокоманды в инструкции флаг IX1 устанавливается правильно, а уже следующая микрокоманда этот флаг обнуляет.
Таким образом, принять решение о том, что инструкция двухоперандная влияющая на R7 можно только в первой микрокоманде инструкции. Возможно, это где-то задействовано (в двухоперандных командах, до которых я не дошел), но в случае с MUL не работает.
https://pic.maxiol.com/images2/16069...1951043.01.png
- - - Добавлено - - -
https://pic.maxiol.com/images2/16069...1951043.01.png
400Цитата:
Сообщение от Alex_K
- - - Добавлено - - -Код:140 000200 . = 200 ; начальная точка входа в тест
141 000200 .blkw 100 ;
142 000400 stack: ;
143 000400 tebuf: .blkw 8. ;
144 000420 012706 000400 entry: mov #stack, SP ;
145 000424 106427 000340 mtps #340 ; запретили прерывания
146 000430 000167 000344 jmp tst0 ; выбираем нужный тест
147 ;
148 001000 . = 1000 ;
149 001000 005000 tst0: clr R0
150 001002 012703 000002 mov #2, R3
151 001006 070603 mul R3, SP
152 001010 005200 inc R0
153
154 001012 .blkw 2000
А у команд EIS разве ss и d (вместо dd) не поменяны местами? "ss == R7" идет лесом ?Цитата:
Сообщение от Titus
Если в dst используется R7, то это можно решить на уровне микрокода, а вот использование R7 в src надо где-то запомнить. Кстати в src R7 изменяется и при использовании адресаций 6 и 7.Цитата:
Сообщение от Titus
Поменяны. Поэтому для этих команд будет dd=R7, а не ss=R7.Цитата:
Сообщение от Vslav
ix - это РДУ - Регистр Дополнительных условий, он многофункциональный, U643 на твоей схеме это просто OR в роли мультиплексора, сигналы на входах всегда в разных фазах. Это же и в документации написано. Так что признаки там хранится все время исполнения инструкции просто не могут.
Документацию не читал, но и так понятно, как он работает. И я уже описывал его многофункциональность.Цитата:
Сообщение от Vslav
- - - Добавлено - - -
А признаки там могут хранится, и хранятся. Например, в IX2 хранится признак в течение всей инструкции.
Это да, а вот следующее не работает:Цитата:
Сообщение от Titus
Потому что когда исполняется 0x01, IR_STB нет.Цитата:
Сообщение от Titus
Как это нет? IR_STB именно во время 0x01 и есть, т.к. IR_STB инициируется SET_CEND, а SET_CEND устанавливает единственная команда - 0x01.Цитата:
Сообщение от Vslav
Да, 2-ой разряд тактируется от IR_STB и хранит признак двух-адресной инструкции. Но для IX[0..1] это не так, они мультиплексируются, регистр обновляется каждый микроцикл и содержимое интерпретируются каждой микрокомандой по-своему.Цитата:
Сообщение от Titus
- - - Добавлено - - -
- модель с тобой не согласна, специально сейчас проверилЦитата:
Сообщение от Titus
- заводская документация с тобой тоже не согласна
Все так.Цитата:
Сообщение от Vslav
- - - Добавлено - - -
Возможно, все зависит от того, какой итервал ты считаешь за время исполнения одной микрокоманды.Цитата:
Сообщение от Vslav
Я считаю то время, когда PLM неизменно:
https://pic.maxiol.com/images2/16069...1951043.01.png
М-м-м... Чего?Цитата:
Сообщение от Titus
У нас есть регистр адреса микрокоманды - na. Вот он определяет (среди прочего) что будет выдавать матрица, в том числе адрес следующей микроинструкции.
Так вот, в тот момент когда na == 0x01 (0x76 в моем инвертированном представлении) и происходит анализ IX[1] на предмет перезагрузить инструкцию или нет. IR_STB никогда не возникает при na == 0x01 - это подтверждается моделью и заводской документацией. И это просто противоречит логике работы - по IR_STB будут загружены результаты предекодера, а если инструкции нет (не успела загрузиться, тайм-аут на предвыборке и прочее) или неверная (изменили PC, переход и прочее) то и результаты грузить нельзя. Иначе говоря, нельзя выдавать IR_STB ДО анализа наличия загруженной достоверной следующей инструкции и результатов ее декодирования.
- - - Добавлено - - -
Как-то так:
Скрытый текст
Ты все правильно говоришь, только ты считаешь началом микрокоманды момент изменения NA. Т.е. как NA стал равен 0x01, ты считаешь это началом микрокоманды.Цитата:
Сообщение от Vslav
А я считаю началом микрокоманды изменение PLM (фронт MC_STB). Или, иными словами, одна микрокоманда - это от MC_STB до следующего MC_STB.
Это очень узкое понимание. Там конвейер, для исполнительных механизмов есть два строба для фаз чтения и записи - MC_STB и MW_STB, которые фиксируют задание от матрицы и сохраняют результаты в сторадж. А основная матрица рулится другими стробами - SA1 и SA2. И работу IR_STB надо рассматривать в привязке к ним, потому что анализ производится и решение принимается именно в матрице.Цитата:
Сообщение от Titus
Я все это знаю. Если ты посмотришь мои графики, то у меня все это расписано.Цитата:
Сообщение от Vslav
Посмотрел по остальным командам EIS, данный глюк есть во всех. Для DIV в качестве аргумента использовал 077777, а для ASH и ASHC - 1.
Логично, ибо стандартная проверка Rd на принадлежность R7 не работает, из-за перепутанности ss и dd в этих командах.Цитата:
Сообщение от Alex_K
А специальную проверку, судя по всему, во всех EIS-командах не сделали.
Но это не страшно. Никакой нормальный программист не будет использовать SP и PC, будут использовать с R0 по R5. А благодаря этому глюку можно сделать защиту от пошаговой отладки, главное правильные команды применить и рассчитать все аргументы.Цитата:
Сообщение от Titus
Зачем защищать от нее? )Цитата:
Сообщение от Alex_K
Программу можно упаковать, а распаковщик защитить. Такое практиковалось на PC в MS-DOS. На УКНЦ смысла нет. Я просто про возможность применения.Цитата:
Сообщение от Titus
Так можно защитить и от эмуляторов)Цитата:
Сообщение от Alex_K