Текущий план проекта мэсм-6

[vak]

По хардверу

(*) Добавить регистры-модификаторы режима прерываний: так называемые К[] регистры.
(*) Сделать экстракоды
(*) Сделать команду IJ - выход из прерывания.
(*) Реализовать внешние прерывания.
(*) FPGA: соорудить систему-на-кристалле для Altera Max 10. Для начала процессор, память данных, память команд.
(*) FPGA: система-на-кристалле для Xilinx Spartan-7.
(*) Контроллер внешних прерываний.
(*) Последовательный асинхронный порт UART.
(*) Таймер.
(*) Порты GPIO.
(*) Порты SPI.
(*) Порты I2C.
(*) Схема платы МЭСМ-6.
(*) Разводка платы.
(*) Изготовление платы.

По софту

(*) Собрать Паскаль-Монитор компилятором FreePascal. Добиться, чтобы он выдавал ровно тот же объектный код.
(*) Документировать объектный код, выдаваемый компилятором (так называемый "стандартный массив").
(*) Дизассемблер для этого объектного код, на основе имеющегося DTRAN.
(*) Линкер для этого объектного кода.
(*) Ассемблер, принимающий на вход упрощённый БЕМШ/Madlen, и выдающий совместимый объектный код.
(*) Переписать рантайм библиотеку Паскаля на этот ассемблер. Адаптировать к нуждам приложений Arduino.
(*) Библиотеки обслуживания прерываний, таймера, портов UART, GPIO, SPI, I2C. Всё в стиле Ардуино, но на Паскале и ассемблере.
(*) Набор примеров простых ардуинных приложений на Паскале.
(*) Руководство по компилятору на основе имеющейся документации Паскаль-Монитор.
(*) Пакет plug-in для стандартной среды Arduino, добавляющий компилятор Паскаль, библиотеки и примеры для платы МЭСМ-6.

Планы наполеоновские, но есть шанс постепенно осилить. Кто за что готов из этого списка взяться - объявляйтесь. Тут работы на роту хватит.

План не высечен в граните: будем менять по мере продвижения и изменения концепции.

Comments

[spamsink]

Предлагаю сначала сделать экстракоды и прерывания с сохранением регистров, а потом посмотреть, стоит ли выделки овчинка с дополнительным набором. Как быть с внешними прерываниями в режиме экстракода? Всё равно тогда сохранять придется. Или экстракоды должны выполняться в закрытых прерываниях?

На Altera теперь синтезируется? У меня были еще идеи по оптимизации, но, похоже, мы уже достигли diminishing returns, сильно больше частоту не поднять. Но 120-130 МГц и так должно быть достаточно для экспериментов.

Первым делом, конечно, нужно портировать Паскаль-компилятор (возможно, в какой-то момент окажется, что проще было бы его сразу на C++ передрать).

dtran.cc уже умеет дизассемблировать достаточно для повседневных нужд. Из него, наверное, не слишком сложно будет сделать ассемблер. А вот линкер, особенно для раздельных кода/данных, если в объектном файле нет такого строгого разделения - нетривиальный проект.

[vak]

Регистры ведь надо куда-то сохранять, и не хочется делать это в памяти. Во-первых это медленнее, во-вторых вызывает проблемы. если SP указывает на отсутствующую область памяти. То есть надо вводить дополнительные регистры, а тогда уж сразу полный набор K[1]-K[15].

Для экстракодов идея следующая. Режим прерывания и режим экстракодов не отличаются. Для обоих взводится отдельный бит в регистре состояния, он же R. Точнее, младшие 6 битов регистра состояния образуют нынешний регистр R.

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

Я тоже думаю, что с частотой уже неплохо. Теперь альтеровский синтезатор ругается на массивы микрокода и jumptab. Не может преобразовать их в память. Думаю переделать их в большой case.

Переписать Паскаль компилятор на Си задача благородная, конечно. Но почти девять тысяч строчек местами не совсем понятного кода это дофига. Может быть легче сначала заставить работать, а потом уже переписывать.

dtran.cc отличная отправная точка. Линкер я готов соорудить, с секциями. Я не смотрел, как компилятор генерит данные - надо, чтобы как отдельную секцию.

[spamsink]

это медленнее

Куда спешить, на 120-то МГц? И откуда возьмется отсутствующая область памяти?

Переменные компилятор кладет в common-block P/1D, а вот константы - в конец кода.

В том-то и идея, что переписывать надо не на С, а на С++. Тогда при правильной огранизации битовых полей и 064 в старших разрядах можно магическим образом получать, и множества из [....] превращаются просто в BESM6Set("[....]"), и вложенные функции становятся методами классов, и т.п. В итоге а) затраты труда будут сравнимы с переносом под FreePascal, если не меньше, и б) потенциальный круг читателей/понимателей/участников сильно возрастает.

[vak]

Не все 32 страницы памяти данных могут физически присутствовать. Зависит от ресурсов конкретного чипа FPGA.

Лучше сохранять PC и состояние в регистрах. Дальше пусть софт решает, как их запихивать в стек, если надо.

Можно и на Си++. На усмотрение разработчика. Но мне кажется, там немного осталось допиливать под FreePascal.

[x86128]

Мне кажется, нам нужно там где возможно стремиться к self-hosted чтобы потом можно было собрать компилятор паскаля прям на МЭСМ6. Если есть какие-то сложности, может стоит его на Си переписать, который где-то был в toolchain и уже на этом Си собрать компилятор для паскаля нативно.

Или как-то разработать некий аналог ДИСПАК (чего-то подобного на уровне команд пользователя) чтобы помимо пакетного режима был многопользовательский режим. Вход в многопользовательский режим через некий ардуиновский шилд, на котором будет работать эмулятор текстовых терминалов и телнет сервер.

Может стоит retrobsd портировать когда будет Си :)

[vak]

На FPGA self-hosted не поместится без внешней SRAM и виртуальной памяти. Но суть даже не в этом, а просто не найдется желающих делать Си-компилятор для БЭСМ-6 и тащить туда Юникс. Слишком масштабная по объёму работа. Многопользовательский режим нынче сам по себе уже не увлекает.

Зато для обучения низкоуровневому программированию МЭСМ-6 очень даже подойдёт. Уровень Ардуино: Паскаль и ассемблер.

[x86128]

Теперь альтеровский синтезатор ругается на массивы микрокода и jumptab. Не может преобразовать их в память.

Это вот это:

Info (276014): Found 3 instances of uninferred RAM logic
	Info (276013): RAM logic "uop_rom" is uninferred because MIF is not supported for the selected family
	Info (276013): RAM logic "entry64" is uninferred because MIF is not supported for the selected family
	Info (276013): RAM logic "entry16" is uninferred because MIF is not supported for the selected family

Посмотрел в technology map:


И вот тут показывает:


Я правильно понимаю, что версия 18.1 тоже по какой-то причине не может синтезировать блоки памяти в чипе MAX10M50?

А если сможет, это будет быстрее?

[vak]

Да, это оно самое. Альтера хочет синхронную память. Из документации: "Altera recommends using synchronous memory blocks for Altera designs. Because the TriMatrix memory blocks in the newest devices from Altera are synchronous, RAM designs that are targeted towards architectures that contain these dedicated memory blocks must be synchronous to be mapped directly into the device architecture. For these devices, asynchronous memory logic is implemented in regular logic cells".

Я переделал микрокод вместо массива в конструкцию case. Добавилось 10 LUTов, но вышло даже чуть быстрее.

Было: 52.88 MHz - 57.42 MHz
Total combinational functions: 4,625
Dedicated logic registers: 678

Стало: 55.39 MHz - 59.94 MHz
Total combinational functions: 4,635
Dedicated logic registers: 678

[x86128]

Словил любопытный баг:

# Limit: 12000000
# Load 2399 words from alu.oct
# (4430141) Unknown microinstruction address: upc=0101100xx
#
# ----- Fatal Error! -----
# Elapsed time: 117 seconds


Он вылазит в тесте АЛУ.

Кусок трассировки:

(4430140) 36262: 06606264 uza 6264(1)
(4430141) 176: 0000200000000000262 imm=178 cond_a_zero
(4430141) Unknown microinstruction address: upc=0101100xx


То есть все нормально, команда uza до этого выполнялась:

(4429942) 36236: 06606240 uza 6240(1)
(4429942) R = 04 (log)
(4429943) 176: 0000200000000000262 imm=178 cond_a_zero
(4429943) Y = 0000 0000 0000 0000
(4429944) 178: 0010000000000000000 pc=UA w_pc
(4429945) 179: 0000001100000000023 imm=19 cond_op_not_cached decode
(4429946) 19: 0000000600000000000 fetch w_opcode (busy)
(4429946) Fetch [36240] = 0010 6777 0013 6777
(4429947) 19: 0000000600000000000 fetch w_opcode
(4429948) 20: 0000001000000000000 decode
(4429948) 36240: 00106777 xta 6777


Почему вдруг испортилось содержимое case загадка. Видимо какие-то особенности работы modelsim на ubuntu 18.04 x64
Сделал дамп для gtkwave где показан момент


Файлы трейсов слишком жирные получаются.

На какой версии линукса и modelsim у вас проходит этот тест АЛУ ?

С другими маленькими тестами всё в порядке.

Test uj - PASS
Test vtm_vzm_v1m - PASS
Test j+m_utm - PASS
Test vlm - PASS
Test utc_wtc - PASS
Test vjm - PASS
Test mtj - PASS
Test xta_uza_u1a - PASS
Test atx - PASS
Test ati_ita - PASS
Test addr0 - PASS
Test aax_aox_aex - PASS
Test arx - PASS
Test its - PASS
Test sti - PASS
Test xts - PASS
Test stx - PASS
Test asn_asx - PASS
Test acx_anx - PASS
Test apx_aux - PASS
Test stack - PASS
Test ntr_rte - PASS
Test yta - PASS
Test e+n_e-n_e+x_e-x - PASS
Test a+x_a-x_x-a - PASS
Test amx - PASS
Test avx - PASS
Test multiply - PASS
Test divide - PASS
Test hello - PASS
---
Tests total: 30, passed: 30, failed: 0


[x86128]

Интересно вот это:
(*) Реализовать внешние прерывания.
(*) FPGA: соорудить систему-на-кристалле для Altera Max 10. Для начала процессор, память данных, память команд.
(*) Контроллер внешних прерываний.
(*) Таймер.
(*) Порты GPIO.

Примерно придумал как - напишу позже по подробней в отдельный пост по этим пунктам.
Кратко: внешние прерывания через контроллер прерываний, который планирую вынести в файл mesm6_pic.sv. Один общий регистр с флагами прерываний и маской (пока без разделения как в БЭСМ). Использовать как модуль в файле top.sv в папке с платой от альтеры.
Система на кристалле: надеюсь, что ко мне доедет de10-lite примерно в конце апреля, там буду заниматься практикой уже.
Таймер: счетчик тактов с делителем, доступ по команде УВВ(033).
GPIO: На плате de10-lite повешу на запись по УВВ светодиоды, на чтение из GPIO - SWитчи тоже по команде УВВ.

Также хочу сделать очень lite-версию mesm6_mmu.sv. Дополнительный сигнал у CPU - io_req. io_req будут выставлять команды РЕГ и УВВ при обращении к регистрам прерываний, регистру маски прерываний и внешний устройствам.
В mesm6_mmu на первом этапе не будет никаких приписок, защит и т.д. он по сути будет мультиплексором для шины данных с выбором что подключать к шине данных процессора (аккумулятору) - память данных или регистры УВВ.

Можно ввести регистры УВВ как memory-mapped но хочется чтобы было как в БЭСМ с отдельными командами.

Как быть с прерыванием от АЛУ пока не решил.

[vak]

Контроллер прерываний лучше не скрещивать с УУ. По опыту, архитектура контроллера прерываний имеет тенденцию жить своей жизнью и усложняться со временем. Лучше реализовать его отдельным модулем, независимым от процессора. Считать его одним из периферийных блоков, наряду с таймером, GPIO, UART и другими.

Регистры всех периферийных блоков я бы предложил отобразить в память. Занять под них диапазон 77000-77777. Так к ним удобнее будет обращаться из языков высокого уровня. Команды РЕГ и УВВ не особо нужны. Совместимость с БЭСМ-6 нам тут никак не помогает.

Модуль MMU это правильно. Он должен ловить обращения к окну периферийных регистров и переадресовывать в конкретный модуль. И еще собирать прерывания от периферийных модулей в контроллер прерываний. К процессору идёт только один общий сигнал запроса прерывания.

Карту адресов для периферийных модулей можем обсудить отдельно.

Реализацию периферийных блоков можно заимствовать из других opensource проектов. Упрощать и адаптировать к нашей ситуации.

[x86128]

Реализацию периферийных блоков можно заимствовать из других opensource проектов. Упрощать и адаптировать к нашей ситуации.

Видимо надо брать AHB-Lite или Simple Bus Architecture
Они достаточно простые, причем из AHB можно убрать поддержку транзакций на первом этапе.
То есть это у нас будет аналог медленных каналов БЭСМ-6.

Но я в перспективе хочу чтобы были DMA контроллеры для framebuffer и SD-card, то есть какую-то быстру шину предусмотреть. Но это потом конечно. (именно поэтому как-то не очень хочется от архитекуры БЭСМ отходить)

[vak]

Пожалуй AHB-Lite будет оптимальным выбором. Можно заимствовать код из MIPSfpga и других opensource проектов. Лучше брать с лицензией MIT, Apache или BSD, и воздерживаться от GPL во избежание конфликтов.

DMA-контроллеры позже можно добавить.

[x86128]

Для нашей системы вот этот мультиплексор будет просто космических масштабов.

Или это принято нормальным считать? Мне кажется там длина пути сигнала в этой цепочке будет очень большая.

Или не заморачиваться с третьим состоянием?

[vak]

Не надо третьих состояний, просто мультиплексор.
Вот как здесь:

https://github.com/MIPSfpga/mipsfpga-plus/blob/master/system_rtl/mfp_ahb_lite_matrix.v#L422

И декодер адресов:

https://github.com/MIPSfpga/mipsfpga-plus/blob/master/system_rtl/mfp_ahb_lite_matrix.v#L372

[vak]

Прерывание от АЛУ не особо актуально. Можно оставить на потом.

Его не стоит рассматривать как прерывание, в частности заводить в контроллер прерываний. Это на самом исключение, и его в частности не надо маскировать. Аналогично деление на ноль. Обрабатывается оно скорее как экстракод.

[x86128]

Создал внутри besm6/mesm6 проект MESM-6 SoC и перенес туда часть этих задач над которыми думаю/работаю.

Там получается типа доски с липкими бумажками. Каждую бумажку можно сделать issue и обсудить в слуае необходимости, так же и наоборот можно issue превратить в такой TODO.

[vak]

Тикеты это удобно.
Я по работе использую нечто подобное.

Насчёт архитектуры контроллера прерываний у меня были несколько другие мысли. Давай я отдельный пост про это напишу.