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

[Vslav]

Возможно, все зависит от того, какой итервал ты считаешь за время исполнения одной микрокоманды.

М-м-м... Чего?
У нас есть регистр адреса микрокоманды - na. Вот он определяет (среди прочего) что будет выдавать матрица, в том числе адрес следующей микроинструкции.
Так вот, в тот момент когда na == 0x01 (0x76 в моем инвертированном представлении) и происходит анализ IX[1] на предмет перезагрузить инструкцию или нет. IR_STB никогда не возникает при na == 0x01 - это подтверждается моделью и заводской документацией. И это просто противоречит логике работы - по IR_STB будут загружены результаты предекодера, а если инструкции нет (не успела загрузиться, тайм-аут на предвыборке и прочее) или неверная (изменили PC, переход и прочее) то и результаты грузить нельзя. Иначе говоря, нельзя выдавать IR_STB ДО анализа наличия загруженной достоверной следующей инструкции и результатов ее декодирования.

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

Как-то так:

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

[свернуть]

[Titus]

Так вот, в тот момент когда na == 0x01 (0x76 в моем инвертированном представлении) и происходит анализ IX[1] на предмет перезагрузить инструкцию или нет. IR_STB никогда не возникает при na == 0x01 - это подтверждается моделью и заводской документацией.

Ты все правильно говоришь, только ты считаешь началом микрокоманды момент изменения NA. Т.е. как NA стал равен 0x01, ты считаешь это началом микрокоманды.
А я считаю началом микрокоманды изменение PLM (фронт MC_STB). Или, иными словами, одна микрокоманда - это от MC_STB до следующего MC_STB.

[Vslav]

А я считаю началом микрокоманды изменение PLM (фронт MC_STB). Или, иными словами, одна микрокоманда - это от MC_STB до следующего MC_STB.

Это очень узкое понимание. Там конвейер, для исполнительных механизмов есть два строба для фаз чтения и записи - MC_STB и MW_STB, которые фиксируют задание от матрицы и сохраняют результаты в сторадж. А основная матрица рулится другими стробами - SA1 и SA2. И работу IR_STB надо рассматривать в привязке к ним, потому что анализ производится и решение принимается именно в матрице.

[Titus]

Там конвейер, для исполнительных механизмов есть два строба для фаз чтения и записи - MC_STB и MW_STB, которые фиксируют задание от матрицы и сохраняют результаты в сторадж. А основная матрица рулится другими стробами - SA1 и SA2. И работу IR_STB надо рассматривать в привязке к ним, потому что анализ производится и решение принимается именно в матрице.

Я все это знаю. Если ты посмотришь мои графики, то у меня все это расписано.

[Alex_K]

Посмотрел по остальным командам EIS, данный глюк есть во всех. Для DIV в качестве аргумента использовал 077777, а для ASH и ASHC - 1.

[Titus]

Посмотрел по остальным командам EIS, данный глюк есть во всех. Для DIV в качестве аргумента использовал 077777, а для ASH и ASHC - 1.

Логично, ибо стандартная проверка Rd на принадлежность R7 не работает, из-за перепутанности ss и dd в этих командах.
А специальную проверку, судя по всему, во всех EIS-командах не сделали.

[Advertiser]

[Alex_K]

Логично, ибо стандартная проверка Rd на принадлежность R7 не работает, из-за перепутанности ss и dd в этих командах.
А специальную проверку, судя по всему, во всех EIS-командах не сделали.

Но это не страшно. Никакой нормальный программист не будет использовать SP и PC, будут использовать с R0 по R5. А благодаря этому глюку можно сделать защиту от пошаговой отладки, главное правильные команды применить и рассчитать все аргументы.

[Titus]

А благодаря этому глюку можно сделать защиту от пошаговой отладки, главное правильные команды применить и рассчитать все аргументы.

Зачем защищать от нее? )

[Alex_K]

Зачем защищать от нее? )

Программу можно упаковать, а распаковщик защитить. Такое практиковалось на PC в MS-DOS. На УКНЦ смысла нет. Я просто про возможность применения.

[Titus]

Программу можно упаковать, а распаковщик защитить. Такое практиковалось на PC в MS-DOS. На УКНЦ смысла нет. Я просто про возможность применения.

Так можно защитить и от эмуляторов)