Не вполне. У ВМ2 в принципе невозможна предвыборка данных, а команды предзагружаются только при выполнении команд EIS. При выполнении обычных команд предвыборка у ВМ2 ( насколько я понял ) такая же, как и у ВМ1 ( весьма похоже, что у ВМ1 предвыборка тоже есть, только без дополнительного буфера - сразу в основной ).

---------- Post added at 10:26 ---------- Previous post was at 10:19 ----------

Кстати, вполне возможно, что и у ВМ2 нет специального буфера предвыборки, а предвыборка осуществляется, как и у ВМ1 - в основной буфер, но по более продвинутому алгоритму.

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

Учитывая, что команды EIS были в военных версиях ВМ1 - весьма похоже, что и предвыборка у ВМ1 мало чем отличается от предвыборки ВМ2.

А чем вообще предвыборка у ВМ2 может отличаться от предвыборки у ВМ1 ?

Вот кстати пишут на http://en.wikipedia.org/wiki/PDP-11_architecture#Speed про PDP-11/70
То есть кэш всё-таки встречался.

Это 10 тактов шины 10 МГц.
Т.е. при полном попадании в кеш - командаиспользующая 8 обращений к памяти - выполнится на таком процессоре на 80 тактов быстрее, чем на 1801ВМ2.

Не знаю, какая предвыборка у ВМ1, но явно иная. А у ВМ2 действительно есть предвыборка слова команд. И я это даже реализовывал в своем эмуляторе.
Подробно об этом можно почитать в доках на ВМ2, которые я выкладывал.

Подробного описания алгоритма предвыборки в доках ВМ2 мне найти не удалось. То, что там написано о предвыборке - довольно малоинформативно.

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

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

Процессор ВМ1 выполняет две последовательных команды TST R0 быстрее, чем одну команду TST (R0). Такое возможно только при наличии предвыборки регистровых команд.

Ну нифига себе) Там несколько листов на эту тему, причем как в томе-1, так и в том-2. Когда я писал эмулятор, у меня был только первый том. Да еще и в схемах все это есть.

Еще раз повторюсь, ничего не знаю о предвыборке на ВМ1, но она явно должна отличаться. Иначе вообще какой смысл было городить ВМ2) Только из-за нескольких расширенных команд?

Значит я плохо смотрел и Вы меня где надо поправите.

И ВМ1 и ВМ2 выполняют регистровые команды ( например, команды TST R0 ) фактически со скоростью чтения памяти - это достигается за счёт того, что пока арифметический блок "переваривает" текущую команду - управляющий блок уже заказывает у интерфейсного блока чтение кода следующей команды. При этом циклы чтения идут на шине непрерывно.

Если же команде нужно прочитать операнд ( как, например - в команде TST (R0) ) - то между циклом чтения кода команды и циклом чтения операнда у ВМ1 появляется "просвет" в 1 дополнительный такт. Поэтому, процессор 1801ВМ1 выполняет две команды TST R0 быстрее, чем одну команду TST (R0).

Вряд ли у ВМ2 может быть как-то иначе.

Возьмём для примера другую команду: MOV (R0),(R1)
Где там "внутри команды" ВМ2 может успеть выполнить предвыборку, если во время выполнения этой команды шинные циклы идут почти "без зазора", а после выполнения последнего из них ( запись результата по адресу, находящемуся в R1 ) - команда уже завершена ?

Получается, что и в процессе выполнения этой команды механизм предвыборки ВМ1 и ВМ2 работает одинаково.

А когда они работают по-разному? Когда процессор ВМ2 может успеть "впихнуть" цикл чтения предвыборки "внутрь" выполнения любой команды, кроме команды EIS.. Не вижу таких вариантов.

А если один из операндов - это непосредственные данные, следующие за кодом команды? ВМ1 - будет их читать все равно из памяти или же возьмет из прекешированного слова? У ВМ2 - второй вариант, на сколько я помню.

Такой вариант исключён и для ВМ1 и для ВМ2. Они хранят только одно прочитанное слово и это слово всегда команда.

Дело в том, что предвыборка у ВМ1 и ВМ2 начинается только тогда, когда точно известно, что больше обращений к шине у текущей команды не будет. Такое бывает лишь в 2х случаях:

1. Операция начата, а приёмник результата операции - регистр.
2. Запись результата операции в память уже выполнена.

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

Мощь!

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

В таком случае ВМ2 будет сильно проигрывать в эффективности ВМ1, потому что ВМ1 не осуществляет предвыборку в начале команд, изменяющих счётчик команд, не осуществляет предвыборку в начале команд, изменяющих следующее слово и т.д., и т.п. ( т.к. ВМ1 вообще не осуществляет предвыборку в начале команд ).

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

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

Действительно - в описании ВМ2 указано, что изменение следующего слова в команде требует его повторной выборки, т.е. тем самым подразумевается, что это слово было прочитано после кода команды и до выполнения операции.

Но какой от этого выигрыш, кроме неизбежного проигрыша в быстродействии - совершенно не понятно.

Обьясни по шагам методику предвыборки на ВМ1?

У ВМ2 примерно так:

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

Предвыборка у ВМ1 - для большинства команд ( кроме команд EIS в военных версиях ) - это начало чтения следующей команды в тот момент, когда арифметический блок ещё устанавливает биты PSW в ходе текущей команды. Так ВМ1 экономит по 1 такту на каждой регистровой команде ( или полный цикл чтения на каждой команде EIS { это в теории - для практической проверки нужен ВМ1 с EIS } ). Но на каждой не-регистровой команде ВМ1 теряет по 2 такта ( возможно, по 1 такту - это надо уточнить ) из-за штрафа отмены предвыборки ( опять же в теории - на практике это может быть просто задержка получения исполнительного адреса ).

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

---------- Post added at 23:13 ---------- Previous post was at 23:05 ----------

Кстати, если ВМ2 теряет по циклу чтения на каждой итерации цикла SOB - быстродействие цикла SOB у 5 МГц ВМ1 и 10 МГц ВМ2 должно совпадать. Это, типа - получается этакая супер-совместимость по программным задержкам у ВМ1 и ВМ2 !!!

Что такое EIS команды, и почему в военной версии?

ВМ1 (насколько я понял) был разработан с поддержкой команд Mul и Div. Те кристаллы, у которых эти блоки работали без проблем - шли на спецприменения, а у остальных эти команды отключались.

типа отбраковка была?

В названии после ВМ1 шла буква, в зависимости от которой возможности процессоров сильно различались.

Это я помню, уже было где-то на форуме обсуждение процов ВМ1 расшренных. И даже до чего-то там договорились, но не помню уже до чего.
Странно, что какой-то блок мог не получаться. Топология-то везде одинаковая, на всем кристалле.

Значит просто секретили, по принципу "русский, когда хитрит - притворяется дураком".

Кстати, насчёт потери полного цикла чтения на каждом переходе - я погорячился. Например, прочитав код команды JMP (R0) процессор ВМ1 впадает в ступор на добрых 12 тактов ( как будто "прокручивает в уме" тот самый "потерянный цикл DATI" процессора ВМ2 ). Если же переход происходит по абсолютному адресу или смещению - то именно это слово и будет прочитано процессором ВМ2 в ходе предвыборки.

роботландия )
 

Дискета РОБОТЛАНДИЯ восьмая в этом списке добытых Арсением Дискет,
на некоторых обнаружились "математические" обучалки - написанные явно с использованием модуля Graph на FastPascal'e - весят очень много, но и написаны очень грамотно. А вот на одной из дискет несколько графических игр [B](дискета номер 8 из списка - отчего-то не запускаются корректно в UKNCBTL)

Некорректно - это как?

Пока не определено ( Надо ещё пробовать, но часть SAV тупо виснут и всё - жди сколько хочешь. Есть и обратная вещь - уроки построения графиков написанные на фаст-паскале (часть из них) не работает в EmuStudio, но прекрасно работает в UKNCBTL - штука в том, что копаться с этими прогр. и там и там проверять на запуск сильно лень. От скуки (зима только началась) возможно займусь.
Во первых - на живой машине скорее всего будут работать.
Во вторых - не особо ценно в плане эмулятора.
В третьих - я залез в очередной раз в эту коллекцию в поисках конкретной
позиции и как это часто бывает не найдя её застрял на другом )))

Мне показалось или консоль стала более информативной в плане АССЕМБЛЕРА?
Оформление сообщений?
Снова наткнулся на странное расположение кнопок + и ) в варианте когда в эмуляторе включен РУС (или вообще всегда). Если вот грядёт всё таки новая раскладка надо очень подробно один раз её написать и может даже к эмулю прилепить. РОБОТЛАНДИЮ я помню как она приехала в школу, красивые такие дискеты с жёлтыми наклейками - мы все думали, что это супер игры (ну по принципу ИГРОПАКЕТОВ ИТОшных) - слегка разочаровались тогда конечно.

Все неработающие, или неправильно работающие программы ОСОБО ЦЕННЫЕ, т.к. показывают эмуляторные глюки.
И это все надо описывать и выкладывать со скриншотами.

да? )))

да.

Вот примерно, что я имел в виду, когда писал выше про возможные глюки
после "reset" не сбросом питания, а кнопкой на плате. Не помню к чему там пришли,
но ты вроде переделал как-то "reset" уже даже в последней сборке?
Я уточняю как-бы )

На мой взгляд - это полная ерунда.

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

Если же это обычная прорамма, для которой содержимое ячеек 500-777 совершенно не интересно - то и нет разницы, какие там значения.

Кстати, начиная с монитора RT-11 v5.2 - при зпуске программы - в ячейки 512-777 копируются аргументы команды запуска в том виде, в котором их ввёл пользователь. В ячейку 510 пишется длина строки аргументов с учётом завершающего нулевого байта.

Итак, очередная версия эмулятора.

На этот раз изменения следующие.

1. Сделана проверка на потерю рисовательной поверхности, когда система засыпает или же (у Хобота) нажимаешь Alt+Ctrl+Del. Теперь, если поверхность потерялась, мы ее обратно находим. Замечу, что если изменилось разрешение экрана, то тогда уже рисоваться ничего не будет, т.к. пока что такое не предусмотрено.

2. За счет выкидывания всяких ненужных тестов, размер эмулятора уменьшился почти ВДВОЕ(!).

3. Благодаря помощи Patron'а, разобрался с хуками клавиатуры, и полностью переделал клавиатурное взаимодействие с системой. Теперь этим занимается не DirectInput, как раньше, а специальный глобальный хук клавиатуры, который помимо раскодирования и трансляции кодов клавиш в формате DirectInput'а (а что делать, если уже все заточено под этот формат), делает много чего интересненького. Во-первых - отменена индикация лампочек на нажатия таких клавиш, как CapsLock, NumLock и ScrollLock. И самое главное, этими лампочками можно пользоваться, как душе угодно. А пока что угодно вывести на первые две из них состояния дисководов 0 и 1. Мне нравится. Если кому не нравится, пишите. Причем, собственное управление лампочками происходит только, когда активно окно эмулятора. Если же переключиться на другое окно, то восстановится системное состояние лампочек клавиатуры. Ну и при закрытии эмулятора тоже все восстановится.
Проверяйте. Переделка хитрая, и в какой-то степени даже экпериментальная.
:v2_dizzy_christmas2

Здесь есть небольшая засада, заключающаяся в том, что некоторые клавиатуры ( или это Windows так прикалывается ) не могут отрабатывать код переключения лампочек слишком часто (у меня - не чаще одного раза в 90 мс). Чтобы промежуток между последовательными переключениями лампочек соблюдался - функции переключения лампочек (в модульном API) только ставят их флаги, а специальная функция, вызываемая 60 раз в секунду - приводит лампочки в соответствие с флагами, учитывая время последнего переключения последней лампочки.

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

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

Т.к. Windows при этом относительно состояния лампочек не ошибается - то скорее просто в Windows для этих кодов действует общая "защита от автоповтора".

Ведь NumLock, например - генерит автоповтор точно так же, как и любая другая клавиша, но если в Windows зажать NumLock - он не начнёт переключаться 30 раз в секунду.

Tы запусти и проверь у себя)

Сперва я сделал переключения лампочек, ориентируясь на их текущее состояние (по биту 0 во flags), но после того, как это стало зависать при быстром переключении (т.е. даешь быстро смену 0->1->0, и получается обраная связь, когда не успело устаканиться предыдущее состояние, а ты уже меняешь, и входило в режим генерации постоянной). Тогда я переделал на другой метод, и стало все стабильно и хорошо)

Верю.

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

проверь мой эмуль.

hobot проверит :)

А у него любое виртуальное нажатие на NumLock приводит к глюкам из-за того, что в его ноуте NumLock - чуть ли не главная кнопка, от которой зависит ВСЁ !!!

Поэтому - советую заранее озаботиться возможностью "отключения моргания" ( а значит - и отключения восстановления состояния лампочек ).

Ну пускай проверит, но я сомневаюсь, что приведет к глюкам. В WinUAE тоже сделано лампочками отображение, и ничего не глючитр.

Если управлять двумя правыми лампочками - у него всё О.К.
Но стоит послать виртуальное нажатие на NumLock - и его ноут становится ОЧЕНЬ недоволен.
Мне из-за этого пришлось вводить в модульный API специальную настройку, отключающую виртуальные нажатия на NumLock.

Какое безобразие. Ну пусть он сам ругнется сперва, а мы рассмотрим.