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

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

Цитата:

---

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

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

---

Может быть это как-то связано с обработкой прерываний по ЕМТ, TRAP, BPT или ложной инструкции?

Цитата:

---

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

Может быть это как-то связано с обработкой прерываний по ЕМТ, TRAP, BPT или ложной инструкции?

---

Для EMT, TRAP, BPT, IOT своя отдельная микропрограмма, вероятно она не запускает чтение следующей инструкции потому что известно что она в данный момент выполняться не будет. Речь идет об асинхронных прерываниях (IRQ1-3, VIRQ) и исключениях (тайм-аут ответа, нечетный адрес (нереализована)). В-общем, реалтайм в виде времени реакции на прерывание принесли в жертву скорости потокового исполнения. Прерывания в те времена были явлениями нечастыми - 50/100 Гц системного таймера, или ~960 от системного терминала, поэтому со временем реакции никто не парился.

Цитата:

---

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

реалтайм в виде времени реакции на прерывание принесли в жертву скорости потокового исполнения

---

Если бы все команды ВМ1 выполнялись за одно обращение к шине - это была бы жертва. Но у ВМ1 есть команды, которые откладывают обработку прерывания на 7 циклов шины ( например - ADD @TAB1(R0),@TAB2(R1) ), поэтому плюс-минус один цикл - не так уж и принципиально.

Цитата:

---

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

Если бы все команды ВМ1 выполнялись за одно обращение к шине - это была бы жертва. Но у ВМ1 есть команды, которые откладывают обработку прерывания на 7 циклов шины ( например - ADD @TAB1(R0),@TAB2(R1) ), поэтому плюс-минус один цикл - не так уж и принципиально.

---

Угу, это ужас-ужас как долго, но терять целый цикл в случае возникновения прерывания все равно жалко.

Нарисовал диаграммку первичного декодирования инструкции - состояние 7E - это самая начальная фаза выполнения всех команд, на входе имеет уже опрошенный контроллер прерываний и полученную от него 3-х битную маску PLI/P1X, а в некоторых случаях и загруженный регистр кода инструкции. Эта маска хитрая - она может получаться как от контроллера прерываний, так и в результате декодирования команды. В итоге программные исключения типа IOT/BPT/TRAP/EMT искусственно ставят эту маску и перезапускают декодирование, получается типа прерывание.

Исключение по недопустимой команде или таймауту шины безусловно приводит к сбросу микроавтомата и принудительному переходу на состояние 7E с активным запросом на исключением с последующей его обработкой.

На флаги TNZVC при первичном декодировании никто не смотрит, не влияют на работу в этой фазе.

Интересно что начальное декодирование достаточно сложное, но оно пропускает некоторые MUL на следующий адрес и только там уже умирает по исключению недопустимой инструкции.

Диаграмма в приложении, полную для всех состояний будет сложно и долго нарисовать, поэтому ограничусь самыми интересными кусками - вход в прерывание, возврат RTI/RTT, MARK.

Цитата:

---

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

терять целый цикл в случае возникновения прерывания все равно жалко

---

Тест VM1C8 проверяет, сколько тактов занимает приём вектора прерывания.

На тестировавшейся ДВК-1 результат был такой:

Код:

---

.ru my1:vm1c8

1801VM1 Timings Test #8a

Scale: 1024
Retry: 100

Return                :  35:100
RtI                  :  46:100
IOT + RtI            : 126:100
Handler cycles : 1024
Handler clocks        : 405:100
IOT + Handler        : 483:10  484:90
Interrupts    : 1024
Interrupt + Handler  : 501:100

---

Если вычислить разницу между [IOT + Handler] и [Interrupt + Handler], а потом добавить время выборки кода команды IOT ( 12 тактов ), то получается, что адрес вектора прерывания принимался за 30 тактов, а сохранение РС и PSW с последующей загрузкой новых значений из вектора - занимало у IOT и Interrupt по 68 тактов.

По сравнению с такими расходами, один цикл шины длиной 12 тактов ( при задержке RPLY = 6 тактов ) - не очень шокирует.

Цитата:

---

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

Если вычислить разницу между [IOT + Handler] и [Interrupt + Handler], а потом добавить время выборки кода команды IOT ( 12 тактов ), то получается, что адрес вектора прерывания принимался за 30 тактов

---

30 тактов это очень большая разница, я думаю что 12 тактов как раз уже не надо добавлять, потому что они и тратятся на выборку выбрасываемой при прерывании инструкции.

Ну понятно что погоды это выбрасывание не делает, но оно везде все такое же медленное в первом поколении этих процессоров - что LSI-11, что ВМ1. Посмотрел бенчмарки, так уже F11, который незначительно сложнее и тактовая у него почти такая же, уже дал прирост в 4 раза по скорости.

Цитата:

---

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

По сравнению с такими расходами, один цикл шины длиной 12 тактов ( при задержке RPLY = 6 тактов ) - не очень шокирует.

---

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

Помоделировал аппаратные прерывания, при этом матрица шифратора выдает PLI=100b, и, внезапно (sic!), в состоянии 68 перед сохранением в стеке значение PC откатывается назад на 2. То есть, часть исключений сохраняет адрес следующей инструкции, а часть - адрес текущей, откатывая его назад на слово.

Цитата:

---

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

ВМ2 в такой же коробочке с бантиком хачу)

---

ВМ2 у меня есть, и солнечногорский и ангстремовский, я даже его открыл уже. Но пока не фотографировал и руки реверсить его не скоро дойдут. Но могу сфотографировать и отдать желающим на векторизацию :)
http://s012.radikal.ru/i320/1503/20/9ad9e5b2baa7t.jpg

Цитата:

---

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

ВМ2 у меня есть, и солнечногорский и ангстремовский, я даже его открыл уже.

---

ого! вот это качество снимка! это 4 мкм?

Цитата:

---

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

ого! вот это качество снимка! это 4 мкм?

---

Ниже снимок микрометра на этом же объективе.
http://s020.radikal.ru/i712/1407/cd/695dde782258t.jpg
Цена самого мелкого деления 10 микрон, ширина всего поля снимка примерно 100 делений, всего 1мм. Также ширина всего снимка 3488 пикселей, ширина дорожки на снимке 14 пикселей, получается что ширина дорожки примерно 14/3488 * 1мм = ~0.004 мм. Итого - 4 микрона, бинго! :)

Вопрос знатокам истории. Фото фрагмента 1801ВМ2 двумя постами выше сделано с процессора с маркировкой Ангстрема (серпасто-молоткастый) 91.05. На фотографии хорошо видно сигнатуру ТР4. С другой стороны, на форуме радиокартинки такой же кристалл с сигнатурой ТР4 находится в корпусе с маркировкой СЭМЗ, дата 93.05. Уже понятно, что были разные наборы фотошаблонов, поскольку существуют фотографии кристаллов 1801ВМ2 с незначительно отличающейся топологией. Но, получается, что оба завода работали с разными наборами фотошаблонов в разное время, то есть, "старая" и "свежая" топологии могли выпускаться на обоих заводах?
Хотелось бы, конечно, быть уверенным, что кристаллы у меня ангстремовские. В-общем-то, у меня этих А91.05 четыре штуки из одной партии, поэтому фотографировать придется именно их, остальные мои ВМ2 - разнобой, а нужно минимум два одинаковых процессора для снимков металла (остается целым как эталон для непоняток) и диффузии (этот шлифуется).