Цифровая археология: 1801 и все-все-все

[gid]

То есть, часть исключений сохраняет адрес следующей инструкции, а часть - адрес текущей, откатывая его назад на слово.

Из БКшного опыта известно, что IRQ1 не стремится сохранить адрес следующей инструкции.
Блокировку клавиши СТОП на БК10 делали так:

V4: SUB (PC),(SP)
    RTI

Т.е. возврат из прерывания по вектору 4 при нажатии на кнопу СТОП приходил на начало той же инструкции, во время исполнения которой и произошло прерывание.
Для двухсловных и трёхсловных команд адрес возврата из IRQ1 приходился на второе слово поэтому и вычитали 2 из адреса возврата, но для трёхсловных в очень редких случаях адрес возврата приходился и на третье слово. Так что если достаточно упорно и быстро долбить по клавише СТОП - то БК10 рано или поздно зависала при такой блокировке клавиши СТОП.
А какие ещё исключения сохраняли адрес текущей инструкции? Обращение по несуществующему адресу?

[Advertiser]

[Vslav]

Из БКшного опыта известно, что IRQ1 не стремится сохранить адрес следующей инструкции.

Видимо контроллер прерываний по IRQ1 подсовывает блоку микропрограммного управления PLI=011, и для БМУ прерывание IRQ1 выглядит как будто он выбрал код HALT, увеличил PC++ и выполнил HALT. С его точки зрения законно не откатывать PC и сохранить адрес следующей инструкции после HALT. Табличка PLI (там всего 3 бита) у меня еще не закончена, будет уточняться, пока только ясность:
000 - ожидание снятия ACLO после сброса
001 - нет прерываний
011 - HALT (и возможно IRQ1)
100 - векторное прерывание (и возможно IRQ2/IRQ3)
101 - программное исключение IOT/TRP/EMT/BPT
111 - выполнить начальную последовательность старта

Блокировку клавиши СТОП на БК10 делали так:

V4: SUB (PC),(SP)
    RTI

Сначала впал в ступор, потом вспомнил что опкод RTI равен двум, недавно смотрел

но для трёхсловных в очень редких случаях адрес возврата приходился и на третье слово.

А это может быть очень интересный косяк микропрограммы, очень странно - прерывание обработано на середине команды. Двухадресных команд немного, поэтому можно проанализировать. А может и какой чисто аппаратный глюк процессора, все-таки у нас только логическая модель. Да и HALT/IRQ1 в БК "неродные", потому что падают по тайм-ауту записи в 177676.

А какие ещё исключения сохраняли адрес текущей инструкции? Обращение по несуществующему адресу?

Это надо прогнать все ситуации и задокументировать, буду писать раздел "Прерывания и исключения" - сделаю.

[gid]

А это может быть очень интересный косяк микропрограммы

Это скорее всего не косяк. В различных описаниях 1801ВМ1 писалось, что IRQ1 - безусловное не маскируемое прерывание (что как выяснилось, не совсем правда, таки маскируемое). Если оно происходит, то процессор бросает всё и начинает исполнять его. Т.е. по этой логике IRQ1 может прерывать исполнение инструкции как после чтения опкода, так и после чтения аргумента источника в трёхсловной команде, смотря на какой фазе произойдёт. А соображения здравого смысла (по крайней мере моего) говорят, что в пульт лучше переходить не с середины команды, а после её выполнения.

Просто как раз этот механизм мне не совсем понятен и я эмулирую его крайне упрощенно, в силу своего понимания происходящего.
Нажали СТОП -> приходит IRQ1 -> попытка вывалиться в пульт -> зависание по тайм-ауту записи в 177676 -> прерывание по вектору 4. И вот адрес выхода из прерывания по вектору 4 статистически в большинстве случаев указывает на слово, следующее за опкодом. Для однословных команд - это адрес следующей команды, для многословных - адрес аргумента источника. Вот как раз такую штуку моя текущая модель процессора делать не умеет.

[Vslav]

писалось, что IRQ1 - безусловное не маскируемое прерывание (что как выяснилось, не совсем правда, таки маскируемое). Если оно происходит, то процессор бросает всё и начинает исполнять его

Теперь мы знаем о внутренностях процессора немножко больше
Структурно IRQ1 приходит снаружи ТОЛЬКО на матрицу шифратора прерываний. А выход шифратора осуществляется в:
- трехбитный регистр PLI (он же P1X)
- четырехбитный регистр выбора вектора из таблицы констант
- четырехбитный номер подтверждения прерывания (чтобы сбросить входные защелки и детекторы фронта запросов)

На поток исполнения влияет только PLI. Это такой 3-х битный регистр, выход его подается прямо на основную матрицу ПЛМ и влияет на адрес и исполнение следдующей микрокоманды. Этот же PLI может записываться как с выхода шифратора приоритетов прерываний, так и с части выходов ПЛМ по специальному стробу (тогда я его называю P1X, физически это тот же самый регистр, надо будет переобозвать в PLI). То что это PLI может записываться также из основной матрицы матрицы позволяет эмулировать прерывание по командам HALT/IOT итд. Эти команды перегружают PLI своим значением (там ранее находилось записанное ранее шифратором 001 - нет прерываний) и повторяют цикл 7Е.

Т.е. по этой логике IRQ1 может прерывать исполнение инструкции как после чтения опкода

Вот это понятно и наблюдается, IRQ1 тождественнен выбору опкода HALТ.

, так и после чтения аргумента источника в трёхсловной команде, смотря на какой фазе произойдёт

Вот это непонятно. Напишу утилитку для анализа микроадресов и выясню кто еще из них может реагировать на PLI. Потому что переход на микропрограмму HALT (микроадрес 62) происходит ТОЛЬКО из основной точки старта 7Е - начало разбора инструкции в IR, PC указывает на следующее за опкодом слово, PLI актуальное. Другое дело что на 7Е много кто еще неизученный ходит, а вдруг кто на 7Е ошибочно переходит после выборки поля источника при наличии IRQ1?

....
- адрес аргумента источника. Вот как раз такую штуку моя текущая модель процессора делать не умеет.

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

[gid]

Желание есть, моральных сил взяться за дело недостаточно. К тому же китайские иероглифы мне кажутся более понятными, чем модель в верилоге. Вроде бы и конструкции структур, и синтаксис выглядят знакомо и узнаваемо, но не складывается в голове образ, как оно всё работает, а без этого, каким бы ни было желание, всё равно ничего не напишется. Может на самом деле всё гораздо проще, чем мне кажется, но у меня сейчас полностью отсутствует представление, какая программная модель должна получиться в результате, а это тоже серьёзный довод против.
На освоение верилога и ModelSim'а по моим сейчашним прикидками уйдёт столько времени, что Patron успеет написать аутентичные модели всего семейства 1801ВМх

[Vslav]

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

А если я перепишу Верилог на Си, сил хватит? Переписывание не должно занять много времени, если не заниматься оптимизацией - паковать биты и прочее. Можно даже поискать автоматический транслятор Верилог->Cи, тут Patron упоминал про такой - преобразует Верилог в объект C++.

какая программная модель должна получиться в результате

Основа, грубо говоря, один объект с методами - вызываются при изменении входных сигналов процессора. Потом основной метод - обработка двух событий - возрастающего и ниспадающего фронта клока. Можно оставить только эти два метода, а остальные сигналы подавать как аргументы этих двух методов - все равно состояние объекта меняется только по клокам. Ну и красиво показывать внутреннее состояние - для отладки.

Сам я писать эмулятор не буду - без готовых наработок займет много времени, а тут у нас на форуме есть продвинутые эмуляторщики PDP - как минимум Вы, Patron, Titus (извините если кого забыл).

[gid]

А если я перепишу Верилог на Си, сил хватит?

Это смотря как переписать.

Можно даже поискать автоматический транслятор Верилог->Cи, тут Patron упоминал про такой

Попробовал я поконвертировать этим Verilator'ом. Модель VM1 из архива vm1_rev12j из директории Async он переварить не смог, пишет такую вещь:

%Error-MODDUP: vm1_plm.v:1492: Duplicate declaration of module: vm1_pli
%Error-MODDUP: vm1_qbus.v:856: ... Location of original declaration

Впрочем и на модели из более ранних архивов так же ругается, только номера строк другие.
Хотя вроде бы всё не так, в строке 1492 vm1_plm.v - объявление модуля, а в строке 856 vm1_qbus.v - его использование, и никакого объявления. Да ещё и Multiple top level modules ему не нравятся. В общем, всё равно, не понимая, что там к чему в верилог файле, сконвертировать как надо вряд ли получится.
Зато второй подопытный - vp_037.v сконвертировался с кучей варнингов об неоптимизабельных сигналах. На выходе получились те же яйца, только в профиль - ничего не понятно, но теперь на с++, к тому же сильно разбухшая каша из кода, в которой от строгости и лаконичности верилога не осталось и следа.

Переписывание не должно занять много времени, если не заниматься оптимизацией

А и не надо никаких оптимизаций, их всегда можно сделать потом. Я более чем уверен, что у Вас переписание верилога на Си, не важно ++ или просто С, получится эффективнее, чем у автоматического транслятора. К тому же, как мне кажется, сопоставление одного и того же, описанного на Си и Верилоге, поможет в будущем лучше понимать Верилог.

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

[Vslav]

Попробовал я поконвертировать этим Verilator'ом

Спасибо за попытку, в общем ясно что быстро и гладко не получится.

А я, если честно, ожидал окончания реверсинга и написания документации,

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

[ram_scan]

А какие ещё исключения сохраняли адрес текущей инструкции? Обращение по несуществующему адресу?

Я сейчас возможно скажу по дилетснтски офигенную глупость, но опыт ковыряния и чтения доки на 386+ процессоры подсказывает, что сохранять адрес текущей инструкции есть смысл только тогда, когда какие-то телодвижения в обработчике исключения делают разумным ее повторное исполнение без дополнительных танцев с саблями на тему "куда вернуться" уже без возникновения исключения.

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

От этого наверное и надо отталкиваться.

[gid]

Спасибо за попытку

Но пытаться я не перестану.
Для начала я тут попробовал переписать на Си ВЕ таймер из файла vm1_tve.v, т.к. он выглядит самым простым.
Получилось такое vm1tve_c.rar
На ошибки и компилируемость не проверял, т.к. это просто первичный набросок, с целью выяснения, на правильном ли я пути. Приняты упрощения:
1) логика только булева, состояний x и z нет.
2) wire и однобитовые reg приняты как тип BOOL, многобитовые reg - BYTE и WORD в зависимости от битности.
3) собственно таймер - несамостоятельная штука, вызываемая извне, имеет одну функцию с кучей аргументов - входными и выходными параметрами.
4) оптимизаций с целью получить правильный, с точки зрения традиций, код Си не проводилось, пока в этом нет необходимости.
Соответствует ли то, что получилось у меня оригиналу? Особенно интересуют логические операции, и порядок выполнения.