Прошу прощения - не успеваю все ссылки править, постараюсь обеспечить актуальность пока (надо проекты куда-то нормально выложить, в githab или на OpenCores) в первом посте, ссылки на актуальные архивы добавил. В 037 есть файл va_037.v - это переписанный "по-человечески" код.Сообщение от Saar
Или на оба.
На OpenCores проект точно не потеряется среди тонны других. Зато на github классный контроль версий. Не чета ублюдочной SVN.
На github можно микро-коммиты делать, а на OpenCores выкладывать уже с большими обновлениями.
Добрый день.
Просветите, пожалуйста, по процессору ВМ2 в применении к УКНЦ.
1.1. Шина адреса при нечётном адресе
а) Как будет выглядеть шинный цикл MOV (R0), R1 если R0 нечётное? (если я правильно понимаю AD[0] в этом случае равен 0, то есть чтение выравнено по чётному адресу, прерывания типа "unaligned access" нет)
б) Как будет выглядить шинный цикл MOVB (R0), R1 и MOVB R1, (R0) если R0 нечётное? В частности интересует нога WTBT и AD[0] отражают ли они байтовую адресацию при записи? А при чтении?
1.2. Правильно ли я понимаю, что при байтовых операциях типа CLRB (R0) или MOVB rN, (R0) цикл выглядит как READ-MODIFY-WRITE?
При этом в цикле READ считывается выравненное слово без выставления WTBT, MODIFY нужная часть слова (верхний или нижний байт) и, затем, WRITE по пункту 1.1б.
Интересно почему было принято такое решение, поскольку AD[0] и WTBT (если я правильно понимаю их назначение) позволяют обойтись без цикла READ-MODIFY.
1.3. Используется ли вообще ноги WTBT и AD[0] в дешифраторах УКНЦ (я смотрел схему, но не понял). Поскольку для байтовых команд процессор использует RMW это позволяет обойтись без WTBT и AD[0].
2. Зависание при приёме адреса вектора прерывания.
Квитируется ли цикл обработки VIRQ сигналом RPLY? Я помню, что при отладке встречал такой тип зависания (*** ЗАВИСАНИЕ ПРИ ПРИЁМЕ А.В.П. ***).
Когда определяется этот тип зависания: а) нет RPLY в момент получения адреса вектора в цикле VIRQ-IAK0 или б) нет RPLY когда фетчится память по адресу полученному в цикле VIRQ-IAK0? (Я склоняюсь к варианту а), поскольку это бы точно отражало назначение этого зависания).
4. Квитируется ли цикл чтения SEL сигналом RPLY? То есть возможно ли зависание при "чтении регистра SEL" (и какой вектор в этом случае)? Или он всегда завершается успешно?
И сразу ещё вопрос, относительно эмуляторписательства: как обычно реализуется дешифрация команд для "ортогональных" процессоров типа DEC PDP-11? Быстрее будет таблица вызовов или развесистое дерево if/switch? Я, конечно, померяю при возможности, но в плане реализации табличный метод, конечно проще и менее подвержен ошибкам при модификации. Вопрос в быстродействии.
Если интересно: пишу эмулятор УКНЦ (синдром NIH) и есть идеи как получить достаточно точное соответствие времянок учитывая асинхронщину на шине. Взять за основу ukncbtl не получится в придуманной мной концепции, проще переписать. Хотя многие идеи ворую почти без изменений.
Последний раз редактировалось ilynxy; 07.01.2016 в 14:12.
Хотя бы частичное таблицезирование завсегда будет быстрее. Можно сделать иерархию таблиц.
Замечу, что развесистый switch компилятор так же может превратить в таблицу.
- - - Добавлено - - -
Потактово точный, ипи так, побаловаться?)
Последний раз редактировалось Titus; 07.01.2016 в 14:19.
Понимаю Ваш сарказм. Насколько получится точный. Я прочёл тему про измерение быстродействия разных команд (спасибо, очень помогло). Проблема с "потактовым" соответствием комплексная и сложная, у меня есть некотрые идеи как приблизиться к идеалу. Я изложу здесь кратко свое видение этой проблемы (осторожно, поток сознания):
Проблема №1. Смоделировать потактово процессор вполне возможно при доступной информации (забив на несущественные моменты типа POWER ON STARTUP timing и т.п.).
При этом шинные обмены должны эмулироваться с учётом Проблемы №2 (циклы READ/WRITE/VIRQ и т.п.)
Проблема №2. Смоделировать шинные обмены с учётом разных частот и их синхронизации. Здесь куча неясных для меня моментов. Но есть и некоторые светлые.
Известны обеих частоты процессоров. Известна частота видеоформирователя и общий принцип работы арбитра шины. При учёте времянок этих четырёх сущностей у меня в голове вырисовывается стройная картина "вполне потактового соответствия". В данный момент я описываю шинные обмены практически машинами состояний и переходами сигналов (чёрт подери, это реализация части функциональности HDL-симулятора), что позволит в теории написать "приближенный к реальности арбитр".
Неясные моменты: времянки при обращении к IO-MAPPED регистрам -- тут может быть разброд и шатание и можно провести много времени с осциллографом измеряя шинные циклы разной перефирии. Но этот момент я пока даже не рассматриваю как реалистичный (у меня нет "железной" УКНЦ).
Как-то так. Собственно из-за реализации "шины позволяющей эмулировать сигналы RPLY, VIRQ и т.п." у меня и возникли вопросы из предыдущего сообщения, а так же это причина по которой модификация ukncbtl в эту сторону слишком затратна, ввиду другой идеологии.
А вот я, написав уже один эмулятор, менее оптимистичен на счет осциллографа и концепции 'примерно понимаю времянки'.
Теперь сижу жду реверса ВМ2 и других времязадающих чипов УКНЦ (в особенности таймера, реверсом которого я по чайной ложки занимаюсь). До этого времени чего-то писать или переделывать в эмуле считаю бесполезным.
Я не спорю, что на данный момент нет полной информации по поводу времянок УКНЦ (даже процессора ВМ2). Я не видел других эмуляторов, кроме ukncbtl (если где-то есть -- дайте, пожалуйста, ссылки). Но даже владея полной информацией по времянкам её нельзя будет использовать в ukncbtl (по-крайней мере сейчас), поскольку решение задачи разночастотных шин процессора, арбитра и видеоформирователя приведёт к сильной переделке кода (чем я и занимаюсь). А когда появится детальная информация -- тогда её можно будет быстро применить, поскольку модель эмулятора будет готова к таким изменениям.
Время выполнения команд в тактах для ВМ2 измерялось множеством способов. То есть растактовка команд не представляет проблемы. Растактовка методов адресации должна решится при решении задачи асинхронной шины (ну то есть фиксированное количество тактов должно дополнятся, если требуется синхронизация в текущий момент и т.п.). Время реакции на прерывания -- это вопрос, хотя диаграммы есть, можно покурить. Таким образом, как только будет решена проблема эмуляции асинхронной шины решение остальных вопросов будет сводится к подстановке конкретных цифровых параметров. Это будет большим шагом к "потактовому соответствию".
EmuStudio
Что то не найду исходники. Быстрое гугление приводит к эмуляторам чего угодно, но только не того что надо. )
Первоначально в UKNCBTL были чистые switch, с переходом к конкретной процедуре обработки команды.
Сейчас уже просто плоская таблица с переходом к таким же процедурам обработки команд -- т.е. расходуем больше памяти ради производительности.
Когда занимался оптимизацией, ещё разделил универсальные обработчики на отдельные для байтовых команд и словных команд.
Когда окончательно вскроют и опишут ВМ2 -- лучше всё же будет переписать весь код дешифрации и исполнения команд, с тем чтобы он работал через матрицы, полностью аналогичные тем что зашиты в самом процессоре.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием