Расчёт точного времени выполнения команд различными процессорами архитектуры PDP-11.

[Alex_K]

Вполне возможно, что команда BR поможет радикально. Но диагноз это не опровергнет - алгоритмические ошибки микрокода процессора должны давать одинаковый эффект при каждом исполнении "целевого" кода на всех машинах с таким процессором.

Когда же разные прогоны теста дают разные глюки, когда холодная машина глючит меньше, а горячая больше, когда у разных машин на одном и том же коде глюки отличаются - это невозможно объяснить чисто цифровыми причинами.

Терпение, еще раз терпение. Могу сразу сказать, что перед тем как лечь спать, прогнал новый тест, все в полном порядке. А ошибки есть в микрокоде, да еще какие. А результаты разные потому, что еще работают прерывания по таймеру, и судя по всему они на условно работающей машине попадали куда надо. Т.к. вроде и УКНЦ с виду одинаковые и источник питания один, и грузится одна система, но быстродействие чуть-чуть может плавать, т.к. ЦП и сетевой таймер питаются от разных кварцев.

---------- Post added at 11:31 ---------- Previous post was at 11:25 ----------

Т.к. на сейчас на работе и УКНЦ нету тута, то привожу небольшой кусочек кода, хочется услышать ваше мнение о результатах исполнения.
Итак, начальные аргументы - R0 = R1 = R2 = R3 = R4 = 0. PSW = 0200. Ячейка 02000 = 0 (команда HALT).
А вот и код:

1000:011700   MOV     @PC,R0
1002:005201   INC     R1
1004:005202   INC     R2
1006:005203   INC     R3
1010:005204   INC     R4
1012:000137   JMP     @#1000
1014:001000   .WORD   2000
1016:002000

Ваши прогнозы, что получим на выходе?

[Patron]

что получим на выходе?

В свете открывшихся перспектив - боюсь даже подумать.

Но и у меня есть любопытное "кодовое предложение":

	Clr	R1
	Clr	R2
	Mov	(PC)+, R0
	Inc	R2
	Mov	R0, (PC)
	Inc	R1

что будет в R1 и R2 после выполнения..

...

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

В циклическом тесте ( в отличие от линейного ) прерывания ключевой роли не играют. Можно сделать вариант с запрещёнными прерываниями и результат будет тем же ( в смысле глюков, а не в смысле подсчитанного числа тиков ).

[Alex_K]

В свете открывшихся перспектив - боюсь даже подумать.

Ладно, скажу. R0=005201, R1=2, R2=1, R3=1, R4=1, останов будет на адресе 2000.

[Titus]

Ладно, скажу. R0=005201, R1=2, R2=1, R3=1, R4=1, останов будет на адресе 2000.

Ну и как это получилось?

[Alex_K]

Но и у меня есть любопытное "кодовое предложение":

	Clr	R1
	Clr	R2
	Mov	(PC)+, R0
	Inc	R2
	Mov	R0, (PC)
	Inc	R1

что будет в R1 и R2 после выполнения..

Обязательно попробую вечером. Но предсказываю: R0=005202, R1=0, R2=1. Но в свете открывшихся обстоятельств с адресацией 17, результаты могут отличаться от предполагаемых.

Есть другой тест:

        MOV     #LBL,R0
        INC     R0
        MOV     (PC)+,R3
        INC     R2
        CLR     R1
        CLR     R2
        MOV     R3,@R0
LBL:    INC     R1
        HALT

Ваши предположения?

---------- Post added at 12:37 ---------- Previous post was at 12:36 ----------

Ну и как это получилось?

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

[Titus]

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

Мне не ясно, расшифруйте)

[Patron]

Ваши предположения

Это для меня слишком сложно.
Что при правильной работе должно произойти..

Типа, в момент выполнения команды MOV R3,(R0) - на её место должна записаться команда INC R2.

А зачем нечётный R0 - с чётным R0 результат будет другой ?

[Alex_K]

Мне не ясно, расшифруйте)

Начнем по порядку. Команда MOV @PC,R0 как и надо, ложит в R0 значение 005201. А вот далее самое интересное: использовался тип адресации 17, выборка значения происходит по адресу предвыборки, но предвыборка не нарушается, и в итоге следующая команда INC R1 исполняется два раза. Судя по всему происходит какой-то глюк с тремя счетчиками команд, т.к. следующие команды исполняются нормально, а вот JMP выборку значения по адресации 37 производит не за следующим словом после команды, а еще дальше, т.е. выбирается не 1000, а 2000.
Надо этот код прогнать в режиме HALT, там счетчик копии заморожен при запрещенных прерываниях, может там и конвеер не работает.

[Titus]

Начнем по порядку. Команда MOV @PC,R0 как и надо, ложит в R0 значение 005201. А вот далее самое интересное: использовался тип адресации 17, выборка значения происходит по адресу предвыборки, но предвыборка не нарушается, и в итоге следующая команда INC R1 исполняется два раза. Судя по всему происходит какой-то глюк с тремя счетчиками команд, т.к. следующие команды исполняются нормально, а вот JMP выборку значения по адресации 37 производит не за следующим словом после команды, а еще дальше, т.е. выбирается не 1000, а 2000.
Надо этот код прогнать в режиме HALT, там счетчик копии заморожен при запрещенных прерываниях, может там и конвеер не работает.

Т.е. после такой адресации все счетчики сбиваются, и потом идет выполнение всех последующих команд с неправильными счетчиками?

[Alex_K]

Это для меня слишком сложно.
Что при правильной работе должно произойти..

Типа, в момент выполнения команды MOV R3,(R0) - на её место должна записаться команда INC R2.

А зачем нечётный R0 - с чётным R0 результат будет другой ?

Подредактировал код, поставил неверно метку LBL. Теперь можно глянуть, но эффект связан с предвыборкой и записью нового слова по адресу предвыборки. Но процессор адрес сравнивает абсолютно по всем 16 разрядам, поэтому успеет считаться и выполниться именно INC R1, хотя по этому адресу после исполнения MOV R3,@R0 будет уже INC R2.