Реверс-инжиниринг УКНЦ (1515ХМ1&2, 1801ВП1, 1801ВМ2)

[Titus]

Первый график короток по времени, чтобы понять, сколько раз.
И да, еще раз повторюсь, счетчики после неправильной команды не сбиты.

[Advertiser]

[Alex_K]

И да, еще раз повторюсь, счетчики после неправильной команды не сбиты.

Плохо смотрите. Во время исполнения INC R0 все счетчики команд увеличиваются два раза и команда INC R0 исполняется два раза.

[Titus]

Плохо смотрите. Во время исполнения INC R0 все счетчики команд увеличиваются два раза и команда INC R0 исполняется два раза.

Примерно глянул на графики. Заодно нашел у себя в описаниях ошибку связанную с IO_CMD. Если бы знал ее раньше, то может быть и без графиков догадался, где собака порылась)

Я думаю, что проблема в том, что блок ввода-вывода, работающий асинхронно, в конце команды MOV @PC,Rn выдает результат кеширования следующей инструкции в регистр BIR (по сигналу BIR_STB) прям в тот момент, когда этот регистр уже используется. Т.е. если память быстрая, то BIR (кэш инструкции) успевает обновиться до того, как будет использован для декодирования следующей инструкции INC R0. А если память медленная, то инструкция уже декодируется, и в этот момент прилетает новое значение BIR, накладываясь на старое. Подробно изучать сейчас не будут, ибо поздно, но сто процентов, что собака порылась именно здесь. Но думаю, что возможных накладок после подобной команды может быть больше и интереснее.

- - - Добавлено - - -

Да, так и поехало.
В нормальном режиме сперва прилетает новое значение в BIR (кэш), и после этого оно защелкивается и декодируется по IR_STB.
А в ненормальном все меняется местами. В BIR уже есть значение, оно защелкивается по IR_STB, и тут сразу же прилетает новое значение BIR с опозданием. В результате попадаем в порочный круг, когда значение в кэше всегда отстает на одно значение от реально ожидаемого, т.к. прилетает после IR_STB. А так как сбившийся кэш сбросить некому, все так и идет по кругу. И, естественно, INC R0 выполняется два раза. При этом счетчики PC1 и PC2 не портятся и никуда не отстают. Это ложная теория. Сбросить неправильный кэш помогут две команды, которые делают это принудительно посредством IO_CMD. Это команда STEP. И любая команда начинающаяся с перекеширования инструкции (адрес микрокоманды 0x21).

[hobot]

Да, так и поехало.

я хочу уточнить - надо ли подобные ошибки переносить\копировать в модель процессора (эмулятор) или можно\нужно поправлять? Как же система и программы работают? У родных процессоров вряд ли такой же момент ?
В общем это очень интересно и главное как с этим быть?

[Titus]

я хочу уточнить - надо ли подобные ошибки переносить\копировать в модель процессора (эмулятор) или можно\нужно поправлять?

Я думаю, что все надо переносить, если нужна 100% совместимость с реальной УКНЦ.

[Alex]

Лучше в эмуляторе, в настройках, галочку поставить... По умолчанию, ошибка включена, но если кому надо - галочку снять можно

[Vslav]

я хочу уточнить - надо ли подобные ошибки переносить\копировать в модель процессора (эмулятор) или можно\нужно поправлять? Как же система и программы работают? У родных процессоров вряд ли такой же момент ?

У меня для ВМ2 сделано исправление этого бага по флагу компиляции. Каждый сам может решить и выбрать нужен ли ему это баг в системе или нет.

- - - Добавлено - - -

При этом счетчики PC1 и PC2 не портятся и никуда не отстают. Это ложная теория.

Здрасьте, приехали. Там именно теряется одно обновление PC2+2 из-за перезаписи PC2 при выдаче адреса в фазе @PC и предвыборка делается по адресу на 2 меньшему чем должно быть. В итоге поток инструкций отстает на 1 слово в отличие от нормального исполнения. Если поставить два графика рядом, то это не очень хорошо видно из-за разного быстродействия памяти, но если сравнить по циклам микроинструкций, то видна вставка исполнения inc R0 вместо исполнения следующей inc R1. Схема полагает что прочитано 2(PC2), то есть следующая inc R1, а реально читается @PC2, то есть inc R0. Я сделал фикс в виде блокировки перезаписи PC2 и он прекрасно работает.

[Titus]

Там именно теряется одно обновление PC2+2 из-за перезаписи PC2 при выдаче адреса в фазе @PC и предвыборка делается по адресу на 2 меньшему чем должно быть.

Сравни сам два графика. На обоих к моменту исполнения INC R0 значения счетчиков PC2 и PC1 правильные.

[Vslav]

Сравни сам два графика. На обоих к моменту исполнения INC R0 значения счетчиков PC2 и PC1 правильные.

Ну, сравнил:

Скрытый текст

[свернуть]

Верхний график в вдвое меньшем масштабе, поэтому вот то PC2=460 длится ВДВОЕ дольше чем на нижнем графике. Там-то и выполняется лишнее присваивание PC2=460 и выполняется лишний INC R0. Ты видишь тут только последовательность: 460, 462, 460, 462, 464. Это ситуация верная, если нет ошибки. А реально, в случае глюка, это: 460, 462, 460, 460, 462, 464.

- - - Добавлено - - -

Я вечером сделаю диаграмму с PC2 привязанным к шине и микрокоду, там будет виднее.

[Titus]

Верхний график в вдвое меньшем масштабе, поэтому вот то PC2=460 длится ВДВОЕ дольше чем на нижнем графике.

Это не то место. Смотри далее на значения счетчиков в момент выполнения первого INC R0.
А оно одинаковое для обоих случаев.