Comments 45
Может быть немного не в тему вопрос, можно ли всё это (программирование итд.) делать под линуксом, как-то я не всречал точного мнения. И это касается именно Xilinx.
А какая эффективная частота работы? (эффективная в данном случае эквивалентна частоты на которой работало бы БК)
На процессорный модуль подаётся ровно та же частота, что и в оригинальном БК — 3 MHz. Производительность при этом получается такая же с точностью до погрешности измерений, что говорит о том, что производительность на такт примерно одинакова.
Конечно используя современные технологии можно добиться гораздо лучшей производительности на такт, сделать конвейер и т.п., но мне было интересно вписаться примерно в тот же транзисторный бюджет. По модулю CPU у меня получилось — LUT — 2398, FF — 557. Это на мой взгляд сопоставимо с КР1801ВМ1 — около 18000 транзисторов.
Конечно используя современные технологии можно добиться гораздо лучшей производительности на такт, сделать конвейер и т.п., но мне было интересно вписаться примерно в тот же транзисторный бюджет. По модулю CPU у меня получилось — LUT — 2398, FF — 557. Это на мой взгляд сопоставимо с КР1801ВМ1 — около 18000 транзисторов.
Гмм. Там тот же монитор (биос по-современному), EMT, машинные коды PDP-11 и организация памяти с точки зрения программ, что и в оригинальной БК-0010?
Да, разумеется. Образы оригинальных ПЗУ монитора, блока тестов, языков Фокала и Бейсика доступны в Интернете. Организация памяти, система команд, контроллер клавиатуры, таймер и прочее полностью эмулируется.
Поскольку это не реализация «вентиль в вентиль» (были и такие попытки на FPGA), аппаратные баги 1801ВМ1 я эмулировать не стал.
Поскольку это не реализация «вентиль в вентиль» (были и такие попытки на FPGA), аппаратные баги 1801ВМ1 я эмулировать не стал.
На всякий случай. Реализация БК-шки на Altera DE1.
https://code.google.com/archive/p/bk0010/
https://github.com/andykarpov/bk0010-wxeda
https://code.google.com/archive/p/bk0010/
https://github.com/andykarpov/bk0010-wxeda
Тот, что на Google code видел, тот, что на GitGub нет, спасибо за ссылку.
Пробежался по коду, во всяком случае видно, что некоторые неудобные особенности системы команд PDP-11 там обрабатываются корректно. Авторы молодцы.
Пробежался по коду, во всяком случае видно, что некоторые неудобные особенности системы команд PDP-11 там обрабатываются корректно. Авторы молодцы.
Какие такие неудобные особенности системы команд :)? По сравнению с Intel, система команд PDP-11 была изящна как лань. Мне ассемблер БК до сих пор снится. Да мы, вообще, могли писать в машинных кодах, благодаря хорошей систематизации битовых полей в кодах инструкций. Это я вам как заядлый БКашник говорю.
О, для программиста система команд просто идеальна, я в своё время довольно много писал на ассемблере для разных архитектур. Но когда начинаешь реализовывать это в железе, натыкаешься на всякие неочевидности.
Например, команда ADD #1, R0 может вызвать переполнение (что отражается в бите C), команда INC R0, которая по сути тоже прибавляет 1 к R0, на содержимое бита C влияния не оказывает. Какова была логика у фирмы DEC сделать своё ALU в 70-х именно так, мне не известно, не исключаю, что у них просто так получилось.
Например, команда ADD #1, R0 может вызвать переполнение (что отражается в бите C), команда INC R0, которая по сути тоже прибавляет 1 к R0, на содержимое бита C влияния не оказывает. Какова была логика у фирмы DEC сделать своё ALU в 70-х именно так, мне не известно, не исключаю, что у них просто так получилось.
Да, интересно, хотя V (Overflow) ставится. А можно еще вопрос: на сколько подробно вы собираетесь эмулировать все эти особенности архитектуры. Возьмем, для примера, тайминги:
например «очистка» памяти нулями CLR (R0)++, в силу какой-то экономии и реализации адресации в железе, делалась, фактически, в три операции — загрузка из памяти старого значения, обнуления, записи нового значения. Из-за этого быстрее было так: CLR R0, MOV R0,(R1)++. Такие вещи будут учитываться? Я просто, в свое время, написал эмулятор и там такие вещи работали не так как на реальной БК.
например «очистка» памяти нулями CLR (R0)++, в силу какой-то экономии и реализации адресации в железе, делалась, фактически, в три операции — загрузка из памяти старого значения, обнуления, записи нового значения. Из-за этого быстрее было так: CLR R0, MOV R0,(R1)++. Такие вещи будут учитываться? Я просто, в свое время, написал эмулятор и там такие вещи работали не так как на реальной БК.
Это действительно очень тонкий момент. Если посмотреть на оригинальные тайминги PDP-11, то там видно, что например команда MOV R0, @#1000 выполняется за меньшее время и требует на одно обращение к памяти меньше, чем ADD R0, @#1000 именно за счёт того, что нам не нужно старое значение по адресу 1000. У меня сделано так же.
CLR в моей текущей реализации старое значение не читает. Тут дело не только в таймингах, а ещё и в том, что на этапе чтения из памяти может случиться ошибка шины.
Так же требуется специальная обработка для команд CLR, TST, CMP, BIT, JMP, JSR — где-то нам не нужно старое значение, где-то новое, где-то косвенность адресации уменьшается на один уровень.
CLR в моей текущей реализации старое значение не читает. Тут дело не только в таймингах, а ещё и в том, что на этапе чтения из памяти может случиться ошибка шины.
Так же требуется специальная обработка для команд CLR, TST, CMP, BIT, JMP, JSR — где-то нам не нужно старое значение, где-то новое, где-то косвенность адресации уменьшается на один уровень.
Кстати у меня есть версия почему это реализовано именно так. Возможно в те времена экономили везде и на всем и делали только то, что требовалось от команды. У команды ADD была расширенная версия ADC в которой и использовался флаг C (Carry) в случае расширенной беззнаковой арифметики,. т.е. пара команд:
ADD R0, R2
ADC R1, R3
позволяла уже складывать 32-битные числа в регистрах (R0,R1)+(R2,R3). А для INC, DEC такой необходимости уже не было.
ADD R0, R2
ADC R1, R3
позволяла уже складывать 32-битные числа в регистрах (R0,R1)+(R2,R3). А для INC, DEC такой необходимости уже не было.
Где то попадалась в своё время таблица за сколько тактов выполняется на БК та или иная команда в зависимости от метода адресации.
Именно за БК не скажу, а по оригинальной PDP-11 эта информация есть в PDP-11 processor handbook, в самом конце.
Именно по БК, тайминги присутствуют в различных журналах в статьях Ю. Зальцмана
Нет нет нет, это было сделано специально, «так получилось» было не для DEC!
Простите за эмоцию, я просто очень любил PDP в их реинкарнации ДВК а первая любовь не ржавеет.
DEC специально так сделала для облегчения работы с длинными данными, чтобы команды смещения индексного регистра либо изменения счетчика не трогали бита переполнения для следующих разрядов, и в библиотеках это красиво использовалось.
Простите за эмоцию, я просто очень любил PDP в их реинкарнации ДВК а первая любовь не ржавеет.
DEC специально так сделала для облегчения работы с длинными данными, чтобы команды смещения индексного регистра либо изменения счетчика не трогали бита переполнения для следующих разрядов, и в библиотеках это красиво использовалось.
Кстати, круто!!! Тоже вполне логично. Но это только подтверждает, что все не случайно, что все команды были продуманы, да еще и спроектированы для каскадной работы в связках. Обожаю PDP-11! Не перестаю восхищаться.
Логика в этом есть. Ну что же, респект тем, кто об этом подумал.
Инженерная мысль DEC и программная реализация многих модулей RT-11 с кучей гениальных хинтов в реализации на ассемблере, многому меня научившие в своё время, до сих пор впечатляет.
Ну тут надо понимать, что уродливость системы команд Intel в сравнении с DEC была обусловлена архитектурой: когда у Intel использовалась раздельные шины данных и адреса, у DEC она была общей. Отсюда и растут эти приятности в виде адресации ячейки памяти как регистра или косвенные адресации.
Честно говоря, не вижу связи между косвенной адресацией и раздельностью шин адреса и данных. DEC использовал архитектуру с равноправными регистрами общего назначения, Intel со специализированными (аккумулятор, индексные, счётчик и так далее). Вот отсюда и разница.
А вы не могли бы более развернуто объяснить какая связь между шинами и адресацией, тем более, что, насколько мне известно, шина у них стала раздельная начиная с 286-го процессора, а архитектура закладывалась гораздо раньше. А z80, по вашему, по той же причине имеет схожую архитектуру?
Всегда считал, что планировалось, что отдельные команды для доступа к портам, будут экономить адресное пространство, так как имеют, по сути, своё отдельное. Но время все расставило на свои места, и сейчас, масса устройств проецируют себя в адресное пространство ядра напрямую, причем большими диапазонами. Т.е. подход DEC победил.
Всегда считал, что планировалось, что отдельные команды для доступа к портам, будут экономить адресное пространство, так как имеют, по сути, своё отдельное. Но время все расставило на свои места, и сейчас, масса устройств проецируют себя в адресное пространство ядра напрямую, причем большими диапазонами. Т.е. подход DEC победил.
У Intel начиная с 8086 раздельные шины данных и адреса. Другое дело что до, как раз, если я точно помню, 286 использовались общие контакты на корпусе для передачи и данных и адресов.
Я пришёл к этому выводу лет 25 назад когда активно программировал ДВК и БК-0010 на Ассемблере и в машинных кодах. Там неплохо видна эта идея, если машинный код представить в двоичном виде, а затем сэмулировать его обработку на АЛУ и шине. Даже писал что-то вроде реферата для себя на сей счёт. Но вот сходу так тезисно сейчас не изложу.
Я пришёл к этому выводу лет 25 назад когда активно программировал ДВК и БК-0010 на Ассемблере и в машинных кодах. Там неплохо видна эта идея, если машинный код представить в двоичном виде, а затем сэмулировать его обработку на АЛУ и шине. Даже писал что-то вроде реферата для себя на сей счёт. Но вот сходу так тезисно сейчас не изложу.
Не совсем так. У DEC была и шина с раздельными данными и адресом при той же системе команд и даже чуть расширенной.
Дело в другом — ортогональная система команд — то есть все регистры равноправны и к ним применимы все способы адресации, то есть получается полная таблица — отсюда название — требует бОльшего количества железа, нежели специализированные регистры и имеет меньшее быстродействие при прочих равных условиях — вот почему 8080 встала на этот скользкий путь.
«За все в этом мире надо платить».
Дело в другом — ортогональная система команд — то есть все регистры равноправны и к ним применимы все способы адресации, то есть получается полная таблица — отсюда название — требует бОльшего количества железа, нежели специализированные регистры и имеет меньшее быстродействие при прочих равных условиях — вот почему 8080 встала на этот скользкий путь.
«За все в этом мире надо платить».
Хоть это и некропостинг, на всякий случай отмечу, что изначально, в PDP-11 (первая модель -- PDP-11/20, если память не изменяет, -- появилась в 1969-м), шины адреса и данных были тоже раздельными -- интерфейс Unibus, содранный в СССР под названием "Общая шина". Совмещение линий адреса и данных -- это уже LSI-11, появившиеся лет на 5 позже и выпускавшиеся параллельно с PDP-11: последние были мощнее, но и стоили дороже (и по-прежнему использовали Unibus, чтобы без геморроя можно было подключать имеющуюся периферию).
UFO just landed and posted this here
Есть промежуточный продукт между Vivado и ISE: PlanAhead. Поддерживает и старые камни (3, 6) и седьмое поколение (но не самые последние).
Меня как любителя это никак не задело, всё же 7-е поколение FPGA появилось аж в 2010 году, Artix-7 в 2011, Zynq-7000 если не ошибаюсь в 2012. Предполагаю, что это важно для тех, кто занимается коммерческой разработкой под FPGA и поддерживает старые проекты на Spartan.
И ещё жаль CPLD. Новых нет, а старые поддерживаются только в ISE.
И ещё жаль CPLD. Новых нет, а старые поддерживаются только в ISE.
Спасибо за статью!
Под собственным Вы подразумеваете использовать soft-процессор, реализованный на HDL? Если да, то это и вправду интереснее чем Microblaze, но в этой области есть интересная возможность работать с MIPS'ом на FPGA, что подробно рассказано и в Харрисах и в статьях Юрия Панчула.
Сделать с нуля собственный процессор с контроллером шины и обработкой прерыванийК сожалению, этот пункт почти никак не отображен в статье.
Под собственным Вы подразумеваете использовать soft-процессор, реализованный на HDL? Если да, то это и вправду интереснее чем Microblaze, но в этой области есть интересная возможность работать с MIPS'ом на FPGA, что подробно рассказано и в Харрисах и в статьях Юрия Панчула.
Да, естественно, для того чтобы сделать БК-0010, нам надо сделать soft-процессор на HDL с системой команд PDP-11. Microblaze нам тут не подойдёт, MIPS тоже, к тому же я не думаю, что про MIPS кто-то расскажет лучше, чем YuriPanchul
За одну статью обо всём проекте БК-0010 рассказать просто невозможно, про процессор будет отдельная статья, я думаю четвёртая по счёту. Постараюсь всё написать быстро!
За одну статью обо всём проекте БК-0010 рассказать просто невозможно, про процессор будет отдельная статья, я думаю четвёртая по счёту. Постараюсь всё написать быстро!
А нам говорили, что язык БК-0010Ш определяется воткнутой микросхемой. У нас был ФОКАЛ и не было Бейсика. Но в том возрасте я, во-1, не знал какие языки могут быть, во-2, не осознал зачем нужен компьютер вообще. Зачем писать «Привет, человек!», зачем расставлять астериски в виде ёлочки… Я только на первом курсе прозрел, что философское место компьютера быть инфо-хабом для широких масс населения, но это меня зажгло на очень много лет — до сих пор тлеет ;-)
Так и было. Язык был прошит в ПЗУ по адресам — первые 8KБ занимал «монитор», а дальше 24KБ сам язык. Не помню как в БК-0010Ш (вариант для школ), а в БК-0010-01 там лежал обалденный Вильнюс-86 Бейсик (по моему клон GW-Basic). При подключении блока МСТД со своим ПЗУ, оригинальные ПЗУ отключалось, а по этим адресам проецировался Фокал. Но он занимал 8KБ и был намного примитивней по возможностям. Также он был намного медленнее бейсика, т.к. полностью интерпретировался, в отличие от первого, который сначала компилировал программу в промежуточный код (это была интересная смесь машинных команд и данных), а потом уже быстро выполнялся.
Да, так и было. В 8 килобайт сумели засунуть полноценный интерпретатор с поддержкой арифметики с плавающей точкой (пусть числа были пятибайтовые, но всё же). Ассемблерный код интерпретатора просто чудовищный — использовались все возможности процессора и самые тяжелые режимы адресации.
Вильнюс-Бейсик — это не клон, это с нуля написанный язык, сразу для нескольких советских pdp11-like машин: ДВК, БК, УКНЦ. Исходный код можно найти, много где лежит.
Но авторы были под сильным впечатлением от Yamaha MSX, поэтому по ряду вещей этот язык похож на Basic MSX.
https://ru.wikipedia.org/wiki/%D0%91%D0%B5%D0%B9%D1%81%D0%B8%D0%BA_%D0%92%D0%B8%D0%BB%D1%8C%D0%BD%D1%8E%D1%81
Но авторы были под сильным впечатлением от Yamaha MSX, поэтому по ряду вещей этот язык похож на Basic MSX.
https://ru.wikipedia.org/wiki/%D0%91%D0%B5%D0%B9%D1%81%D0%B8%D0%BA_%D0%92%D0%B8%D0%BB%D1%8C%D0%BD%D1%8E%D1%81
Из обсуждений у меня сложилось впечатление что вы реализуете процессор с нуля, используя описание системы команд.
Между тем, уже существует Verilog реализация реального 1801ВМ1 — полученная в результате реинжиниринга реального процессора. Все подробности вот в этой теме:
http://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html
Между тем, уже существует Verilog реализация реального 1801ВМ1 — полученная в результате реинжиниринга реального процессора. Все подробности вот в этой теме:
http://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html
У Вас сложилось совершенно верное впечатление.
Проект, на который Вы ссылаетесь очень интересен прежде всего тем, что люди проделали огромную работу и нашли много плохо документированных особенностей 1801ВМ1 в том числе аппаратные баги (действительно баги, например там в каком-то месте просто не хватает транзистора). Целью того проекта было именно сделать аналог 1801ВМ1 на современной элементной базе, то есть сделать некое изделие, которое можно впаять вместо ВМ1 в БК-0010. Этой цели, насколько я понимаю, добились.
Взять тот проект и переделать его в soft core не получится. Во-первых, в 1801ВМ1 использовались двунаправленные и мультиплексированные шины, в качестве внутренних шин в FPGA такие использовать нельзя. Во-вторых, если посмотреть на Verilog-исходники того проекта, то там практически gate-level дизайн. То есть описано, что сигнал на выводе таком-то представляет собой функцию в нормально дизъюнктивной форме от сигналов таких-то. Понятно, что это следствие обратного инжиниринга, но сюда невозможно ни добавить новую команду, ни сделать процессор с таким же набором команд, но с отдельными шинами для адреса и данных.
Наконец основная задача у меня — показать, что можно сделать с помощью Vivado. Проект БК-0010 — лишь средство сделать это интересным.
Проект, на который Вы ссылаетесь очень интересен прежде всего тем, что люди проделали огромную работу и нашли много плохо документированных особенностей 1801ВМ1 в том числе аппаратные баги (действительно баги, например там в каком-то месте просто не хватает транзистора). Целью того проекта было именно сделать аналог 1801ВМ1 на современной элементной базе, то есть сделать некое изделие, которое можно впаять вместо ВМ1 в БК-0010. Этой цели, насколько я понимаю, добились.
Взять тот проект и переделать его в soft core не получится. Во-первых, в 1801ВМ1 использовались двунаправленные и мультиплексированные шины, в качестве внутренних шин в FPGA такие использовать нельзя. Во-вторых, если посмотреть на Verilog-исходники того проекта, то там практически gate-level дизайн. То есть описано, что сигнал на выводе таком-то представляет собой функцию в нормально дизъюнктивной форме от сигналов таких-то. Понятно, что это следствие обратного инжиниринга, но сюда невозможно ни добавить новую команду, ни сделать процессор с таким же набором команд, но с отдельными шинами для адреса и данных.
Наконец основная задача у меня — показать, что можно сделать с помощью Vivado. Проект БК-0010 — лишь средство сделать это интересным.
Кстати, обратите внимание на Электронику 100/25 в которой была совместимая система команд, но чуть расширенная и другая внешняя шина.
Просто в ней процессор был сделан на чистой логике и она была микропрограммная, причем тексты всех микропрограмм были приведены в руководстве и я своими руками чинил процессор при помощи блока микропрограммной отладки.
И схемы всех плат были и даже с таблицами прошивок ПЗУ.
Это я к тому, что можно поискать чистый микрокод, а не реверсить его из описания команд.
Просто в ней процессор был сделан на чистой логике и она была микропрограммная, причем тексты всех микропрограмм были приведены в руководстве и я своими руками чинил процессор при помощи блока микропрограммной отладки.
И схемы всех плат были и даже с таблицами прошивок ПЗУ.
Это я к тому, что можно поискать чистый микрокод, а не реверсить его из описания команд.
Спасибо.
Да я собственно процессор и всё остальное уже сделал, у меня есть работающий вариант эмулятора. Мне осталось сделать описание наиболее интересных моментов и выложить здесь (и оставшуюся часть исходников на GitHub).
На БК-0010 (1801ВМ1) были базовые команды PDP-11 плюс некоторые из расширенного набора (XOR, SOB).
Да я собственно процессор и всё остальное уже сделал, у меня есть работающий вариант эмулятора. Мне осталось сделать описание наиболее интересных моментов и выложить здесь (и оставшуюся часть исходников на GitHub).
На БК-0010 (1801ВМ1) были базовые команды PDP-11 плюс некоторые из расширенного набора (XOR, SOB).
Вот кстати, если что, эмулятор который вырос из моего: Эмулятор БК-шек с исходниками. Я его года 2 делал, поддержку дисков, ленты, нескольких аппаратных конфигураций. Дальше навалилась работа, семья и я не смог продолжать. Но бросать дело, совсем, было очень жалко, поэтому я выложил исходники в сеть на сайте своего эмулятора. Потом, вот, человек, взял их и за основу и продолжил дело. Он очень сильно развил эмулятор, исправил ошибки, поддержал современное железо. В общем, я очень благодарен ему и слежу за сайтом. Свое имя он почему-то скромно умалчивает на сайте. Я с ним связывался, но дано, и забыл как его зовут. Может быть он и появится тут и присоединится.
Никогда бы не подумал что был БК с механической клавиатурой.
В моём детстве он был таким:
Принимайте в клуб написавших эмулятор БК0010-01.) Кстати, тут есть авторы известных игр? Напишите названия своих игр и как подписывали игры.)
Sign up to leave a comment.
Эмулятор БК-0010 на FPGA