PDP-11 на FPGA

Цитата:

---

Сообщение от Vslav

По ветвлению интересно можно сделать, на каждое ветвление порождать свою ветку виртуального состояния процессора - конвейеров у нас много, можно тащить сразу две ветки, для выполненного и пропущенного условия перехода. Если дальше опять ветвления - новые ветки породить. По коммиту инструкции ветвления - ложные ветки убивать, верные коммитить в реальность. Такой себе мета-квантовый подход :)

---

Весь out-of-order прекрасен, пока не изменяется внешнее состояние (например запись/чтение периферийных адресов нельзя ни переупорядочивать, ни откатывать), однако если принять, что страница ввода/вывода находится всегда по фиксированным адресам (как в большинстве реализаций), то можно считать что запись/чтение RAM не имеет побочных эффектов — вот уж правда безграничный простор для оптимизаций. Оно и так порвёт FPGA без вопросов, а если сделать что RAM не имеет побочных эффектов то отрыв будет космическим.

Про "out-of-order" и тд ещё на лекциях/учебниках 80 годов слушал/читал. и про sisd и simd итд и про кеш инструкций во времена ферритовой памяти. Достаточно взять "правильный учебник" и не изобретать "велосипед".

Дальнейшее обсуждение PDP-11 не на FPGA - не здесь. Создавайте тему и хоть заобсуждайтесь. Эта тема - напомню - PDP-11 на FPGA.

Пришла в голову мысль :)
Результат :)

Код:

---

.COP HX7:SPEED3.SAV SY:
 Files copied:
HX7:SPEED3.SAV to SY:SPEED3.SAV

.RUN SPEED3

Тест быстродействия

R1+R0 classic                    831 186 оп./сек
R1(23456.)+R0(12345.) empty    5 468 713 оп./сек
R1(23456.)+R0(12345.)          3 943 726 оп./сек ->  14 142 484 оп./сек
R1+@R0 classic                10 875 844 оп./сек
R1(23456.)+@R0(M-12345.) empty  5 468 713 оп./сек
R1(23456.)+@R0(M-12345.)        3 652 703 оп./сек ->  10 999 710 оп./сек
R0*R0 classic                  8 179 911 оп./сек
empty 11.*12.                  5 468 713 оп./сек
11.*12.                        3 288 676 оп./сек ->  8 249 779 оп./сек
R2/R0 classic                  3 522 725 оп./сек
R2-R3(34567.)/R1(321.) empty    4 107 349 оп./сек
R2-R3(34567.)/R1(321.)          1 900 050 оп./сек ->  3 535 619 оп./сек
34567.89022+32109.754321 empty  1 829 811 оп./сек
34567.89022+32109.754321        1 412 180 оп./сек ->  6 187 334 оп./сек
34567.89022*32109.754321 empty  1 829 811 оп./сек
34567.89022*32109.754321          797 706 оп./сек ->  1 414 246 оп./сек
34567.89022/32109.754321 empty  1 829 811 оп./сек
34567.89022/32109.754321          785 055 оп./сек ->  1 374 964 оп./сек
MOV 8 word 1 empty              3 689 599 оп./сек
MOV 8 word 1                      552 741 оп./сек ->    650 138 оп./сек
MOV 8 word 2 empty              3 652 703 оп./сек
MOV 8 word 2                      622 224 оп./сек ->    749 980 оп./сек
.

---

запуска Speed3 на моём PDP-2011 :)
Строки с CIS удалил (нету его в PDP-2011 ни в каком виде).
Интересен результат

Код:

---

R1+R0 classic                    831 186 оп./сек

---

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

Нетронутый SPEED

Код:

---

.RUN SPEED

ТЕСТ БЫСТРОДЕЙСТВИЯ

КОМАНДА СЛОЖЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК)    14216

КОМАНДА СЛОЖЕНИЯ РЕГИСТР-ПАМЯТЬ
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК)    11064

КОМАНДА УМНОЖЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК)    8288

КОМАНДА ДЕЛЕНИЯ РЕГИСТР-РЕГИСТР
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК)    3560

---

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

Щас ещё прогоню генерацию всех шести мониторов RT в варианте - для теста быстродействия.

После долгого перерыва (запуск программ SPEED3 и аналогов не в счёт) вернулся к PDP-2011. Ну как вернулся. Пока период вспоминания - чего я там творил и делал, так что внесённых изменений мало, в основном попричёсывал код в авторском MMU под моё видение. Пока ещё не пробовал подключать - процесс причёсывания не закончен.

Из интересного, найденного в коде.

MMU у автора работает так, что если идёт обращение процессора в область 17xxxxxx и в моделе есть модуль UMAP, то MMU прогоняет отображение адреса (точнее, его нижних 18 бит) через UMAP, то есть - по аналогии с обращением Unibus устройств к 22-битной памяти.

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

Так же развернул Quartus в виртуалке, которая работает на более быстром сервера, чем мой рабочий комп. Синтез ускорился примерно в полтора раза :) Мои действия остались почти те же самые, только настроил на рабочей машине бластер-сервер и надо перед первой прошивкой не забыть его запустить :)

Правда, когда удастся хорошо посидеть за кодом - пока не знаю - на работе небольшой армаггедец, домашние дела тоже никто не отменял, плюс пытаюсь ещё и одну прогу для xolod добить :)

Решил проверить одну хрень. Переделал код, запустил синтез, а в это время смотрю, как щёлкает проц в DE10 на тактовой 1 Гц - хорошо видно, как бежит внутренний state machine. И в очередной раз задумался - как ввод-вывод делать за один тик, а не за два.. Ибо на этом много теряется.. Но пока в голову ничего не приходит :)

А куда в наше время можно применить сверхбыстрый PDP11? Есть ли практическая от этого польза?

Кстати - стейт машина в PDP2011 сильно напоминает микропрограммное управление :) Сейчас - на 276(8) микроопераций, правда многие из них - дублируются. Не совсем правильно, конечно, но пока пусть будет так :)

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

Цитата:

---

Сообщение от Titus

А куда в наше время можно применить сверхбыстрый PDP11? Есть ли практическая от этого польза?

---

Ответ уже был

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

От ступил так ступил :):):) Правил код, который связан в поддержкой разделения код-данные, а модель процессора (PDP-11/34), которая её не поддерживает :D Вот удивился, когда результат тот же получился :D

Программист. Повторное использование кода :)

Поскольку в PDP-2011 несколько DMA устройств, что бы не писать код несколько раз (в будущем) - вырезал модуль общения по DMA из RK2011 (единственный пока переделанный и работающий, в том числе - через DMA контроллер дисков) для повторного использования.

Ну и предварительно переделал код в RK2011, что бы его было проще вырезать :)

Работа отнимает много времени (конец года), но стараюсь вечерами повозиться с моим вариантом PDP-2011.

Ещё шаг к стандартизации векторных прерываний. Надеюсь, как и с DMA, выделить в отдельный модуль для повторного использования. Частично уже можно выделить сейчас, но мешает RK11 - у него несколько причин для прерываний. Потихоньку причёсываю код для (возможного) достижения цели.

Так же пытаюсь реализовать возможность модулям (ака платам в корзине) работать на разных тактовых частотах (в QBus/МПИ нет же единого тактового генератора :) ). Что то уже получается :)

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

Надо возвращать MMU. Без него сложно гонять тесты, рассчитанные на PDP-11/34. Так что на очереди он :)