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

[Titus]

Посмотрите повнимательней результаты новых тестов относительно тестов Patron-а. Кое-где расхождение в два раза.

Если с тем, что был зависающим - то с ним я не сравниваю, он вообще глючный.

---------- Post added at 00:04 ---------- Previous post was at 00:02 ----------

Что же до команд

Mov     (PC),R0
MovB    (PC),R0

весьма похоже, что в отличие от всех остальных команд - скорость у них и в словном, и байтовом вариантах одинаковая.

Однако относительно их скорости трудно дать однозначное заключение - ведь в результате глюков часть из них могут выполняться с инкрементной адресацией.

Никаких глюков нет, все стабильно, как часы.

[Patron]

Если пишется слово по адресу предвыборки, то процессор заново перечитывает его после исполнения текущей команды. У Titus-а в тестах в таких случаях получалось различие в 52 такта.

:::::: SP = PC ::::::

Mov    R0, (PC)       47
Mov    R0, (PC)+      47
Mov    R0, (SP)+      85

MovB   R0, (PC)       57
MovB   R0, (PC)+      57
MovB   R0, (SP)+      94

Mov   (PC),(PC)       82
Mov   (SP),(SP)+     102

MovB  (PC),(PC)       84
MovB  (SP),(SP)+     113

При выполнении указанных команд SP и PC всегда имеют одинаковые значения.

Т.е. команды

MovB  (PC),(PC)       84
MovB  (SP),(SP)+     113

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

[Alex_K]

Что же до команд

Mov     (PC),R0
MovB    (PC),R0

весьма похоже, что в отличие от всех остальных команд - скорость у них и в словном, и байтовом вариантах одинаковая.

Однако относительно их скорости трудно дать однозначное заключение - ведь в результате глюков часть из них могут выполняться с инкрементной адресацией.

Что до этих команд, то при исполнении есть глюки, если следующая команда после них не нарушает предвыборку. Patron, измените тесты, вместо трех NOP-ов вставьте три команды BR .+2 (код 0400), хотя достаточно одной, и все изменится.
Я тут проводил тесты в пультовом отладчике, заполнял память с 01000 по 157764 командой MOV @PC,R0, оставшиеся ячейки - три NOP и JMP @#1000. В этом варианте получал TRAP4. Вместо NOP-ов пробовал другие команды, если вместо трех NOP ставил MOV @PC,R0, то все нормально, если команды, которые не нарушают предвыборку, например MOV R0,R0, то получал TRAP4.
Вот такие вот дела. Что-то не учли разработчики в реализации предвыборки, потому такой глюк и происходит.

[Patron]

Никаких глюков нет, все стабильно, как часы.

Стабильность и отсутствие глюков - не одно и то же.

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

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

---------- Post added at 23:21 ---------- Previous post was at 23:15 ----------

Что-то не учли разработчики в реализации предвыборки, потому такой глюк и происходит.

Если бы вылет происходил каждый раз - это одно дело. Но когда вылетает только один раз из нескольких ( а зачастую - из нескольких тысяч, т.к. если при вылете теста MOVPC.SAV в R5 находится 0 - значит было выполнено больше тысячи "проходов через NOP" ) - тогда это больше похоже на резкий скачок потребления тока, приводящий к сбою.

[Alex_K]

Если бы вылет происходил каждый раз - это одно дело. Но когда вылетает только один раз из нескольких ( а зачастую - из нескольких тысяч, т.к. если при вылете теста MOVPC.SAV в R5 находится 0 - значит было выполнено больше тысячи "проходов через NOP" ) - тогда это больше похоже на резкий скачок потребления тока, приводящий к сбою.

Да, здесь Вас не убедить, что если бы проблемы были в источнике, то УКНЦ все время глючила бы, но глюк происходит только при определенных обстоятельствах. Да и о каком резком скачке потребления может идти речь, вроде ничего энергосберегающего в УКНЦ нет, да и жрет он мало.

Собственно тесты на других УКНЦ и с другими источниками питания могут дать ответ, но вот только никто кроме меня их запускать не хочет.

[Patron]

вместо трех NOP-ов вставьте три команды BR .+2 (код 0400), хотя достаточно одной, и все изменится.

В приложении - изменённый вариант теста MovPC v1.1.

Foot0:
	Br	.+2.

	Dec	R5
	BEQ	1$

	Jmp	@#LoopStart
1$:
	Mov	#R.T.I, @#100
	Return
Foot1:

Протестировать в цикле команду MovB (PC)+,(PC) без трёх NOPов невозможно, но зато без теста этой команды количество заглушек удалось сократить до одной.

Мой прогноз - вылетать будет немного меньше, но глючить не перестанет.

...

[Advertiser]

[Patron]

Да, здесь Вас не убедить, что если бы проблемы были в источнике, то УКНЦ все время глючила бы, но глюк происходит только при определенных обстоятельствах. Да и о каком резком скачке потребления может идти речь, вроде ничего энергосберегающего в УКНЦ нет, да и жрет он мало.

Вылет по Trap_To_4 ещё можно кое-как объяснить сбоем предвыборки. Но выполнение MOV как MOVB, уменьшение 1600. в R5 до нуля за пару сотен декрементов - это ничем кроме просадки питания объяснить нельзя.

Собственно тесты на других УКНЦ и с другими источниками питания могут дать ответ, но вот только никто кроме меня их запускать не хочет.

hobot хочет ( он сам говорил ).
Видно - он просто ещё не понял, насколько СИЛЬНО этого хочет :)

[Alex_K]

Мой прогноз - вылетать будет немного меньше, но глючить не перестанет.

Вылет по Trap_To_4 ещё можно кое-как объяснить сбоем предвыборки. Но выполнение MOV как MOVB, уменьшение 1600. в R5 до нуля за пару сотен декрементов - это ничем кроме просадки питания объяснить нельзя.

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

[hobot]

hobot хочет ( он сам говорил ).
Видно - он просто ещё не понял, насколько СИЛЬНО этого хочет

Всё верно, просто есть причины по которым откладываю, сейчас уже потерял всякую надежду актуальные версии собственно ручно собрать - хотя вроде - бы все архивы
Patrona и Titusa вижу у себя, всё равно я бы очень попросил образ дискеты с актуальными версиями чтобы просто гнать и скрины делать прилепить,
Alex_K, наверняка самый актуальный сборник у вас ?
Запуск и прогон на живых машинках планирую на конец этой недели, так что образ то же не к спеху - идеально к выходным? (вдруг ещё какие то тесты или вариации появятся за это время). Я на форуме постоянно, как только начну сразу начну и результаты выкладывать. Тему читаю и слежу.

[Patron]

Я думаю прогноз неверный

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

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