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

[Patron]

Может быть интересно уделить внимание вопросу, как чётность адреса байта влияет на тайминги работающих с памятью байтовых команд.

Из-за особенностей протокола Q-Bus нечётные байты передаются по шине в старшем байте, поэтому перед использованием нечётного байта содержимое шины должно пройти через SWAB-регистр. Также и при записи байта по нечётному адресу его нельзя просто выставить на шину - надо сначала сделать SWAB.

[Advertiser]

[Vslav]

Из-за особенностей протокола Q-Bus нечётные байты передаются по шине в старшем байте, поэтому перед использованием нечётного байта содержимое шины должно пройти через SWAB-регистр. Также и при записи байта по нечётному адресу его нельзя просто выставить на шину - надо сначала сделать SWAB.

В аппаратуре перестановка делается очень просто и транзисторный бюджет на это дело небольшой. Поэтому инструкция SWAB выполняется на своей отдельной схеме - перестановка происходит при загрузке в регистр-аргумент X АЛУ.
А с шиной Q-bus имеется специальный регистр (я условно назвал его Q), который может принимать данные с шины X (и АЛУ, которое тоже работает на шину Х) и шины Q-bus и выдавать от себя данные на шину X или Q-bus. При этом при работе с Q-bus он может переставлять байты как на входе, так и на выходе, с опциональным независимым обнулением каждого байта. Причем остальная часть процессора даже не знает по какому адресу байт, по четному или нечетному, этот регистр смотрит на защелку младшего бита адреса и сам все разруливает.

В итоге после разбора и редукции схемы, работа регистра Q описывается очень просто. Ввод данных с шины Q-bus (для упрощения я убрал запись с внутренней шины X):

always @(posedge pin_clk_n)
begin
    if (au_qstbd)
         qreg[7:0] <= (au_ta0 ? wb_cpu_dat_i[15:8] : wb_cpu_dat_i[7:0]);

    if (au_qstbd)
         qreg[15:8] <= wb_cpu_dat_i[15:8];
end

То есть - младший байт Q-регистра (в коде это переменная qreg[7:0]) может защелкивать или старший или младший байт шины данных Q-bus. А старший байт Q-регистра (переменная qreg[15:8]) всегда защелкивает старший байт. Но он дальше не всегда используется в последующих операциях - маскируется в АЛУ флагом байтовой операции.

Вывод данных на Q-bus:

assign   qrd      = au_ta0 ? {qreg[7:0], 'o000} :  (plrt[6] ? {8'o000, qreg[7:0]} : qreg);

То есть, на шину данных Q-bus будет выводится или полные 16 бит данных, или младшие 8 бит, дополненные сверху или снизу нулями, взависимости от адреса (au_ta0 - защелка младшего бита адреса транзакции, plrt[6] - флаг байтовой операции, поступает из декодера)

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

[Patron]

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

Значит, с этим мне повезло, т.к. тайминги доступа к чётным/нечётным байтам отдельно никогда не тестировались.

...

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

Но на самом деле измеренные тайминги ( при задержке RPLY в 6 тактов ) были не так однозначны:

MOV  (R1), R0		30
MOV  (R1)+,R0		30
MOV -(R1), R0		30

MOV  (R1), (R0)		45
MOV  (R1)+,(R0)		46
MOV -(R1), (R0)		47
MOV  (R1), (R0)+		49

ADD  (R1), (R0)		55
ADD  (R1)+,(R0)		55
ADD -(R1), (R0)		56
ADD  (R1)+,(R0)+		55
ADD -(R1), (R0)+		56
ADD -(R1),-(R0)		56

ADD  @(R1)+,@(R0)+	82
ADD  @-(R1),@(R0)+	82
ADD  @-(R1),@-(R0)	83

BIT  @(R1)+,@(R0)+	70
BIT  @-(R1),@(R0)+	71
BIT  @-(R1),@-(R0)	72

Общая идея вполне понятна, но простой логической связи не просматривается - в команде MOV даже инкремент иногда добавляет такт, а декремент нет.
Выделенное синим - вообще за гранью понимания.

---------- Post added at 16:41 ---------- Previous post was at 16:36 ----------

Ещё прикол:

MOV  (R1), R0		30
MOV  (R1)+,R0		30
MOV -(R1), R0		30

ADD  (R1), R0		30
ADD  (R1)+,R0		30
ADD -(R1), R0		30

BIT  (R1), R0		30
BIT  (R1)+,R0		30
BIT -(R1), R0		31

[Vslav]

У процессора блок обмена с Qbus может работать параллельно и независимо от АЛУ, более того, есть отдельный буфер адреса и может быть запрошена новая операция немедленно после его освобождения. То есть, выдали адрес из АЛУ в буфер, выполнили захват шины, выдали адрес, ниспадающий фронт SYNC, и в этот момент внутренний буфер адреса освобождается - он больше не нужен для текущей транзакции, и микрокод может туда закинуть новую операцию по новому адресу, хотя и текущая транзакция еще не закончена.

Вот та строчка что в табличке синим отмечена, там по факту будет две транзакции - сначала будут прочитаны данные источника, потом будет диспетчеризован (отдан исполнительному блоку Q-bus) адрес получателя, а дальше надо смотреть и трассировать микрокод, возможны варианты - или будет вычислен инкремент и сохранен регистр (кстати это возможно одновременно с диспетчирезацией адреса), или будут диспетчеризованы записываемые данные для получателя. В зависимости от очередности этих операций будет разный момент старта операции собственно записи. Буду заниматься проектом - посмотрю как оно там.

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

Да, при вычислении адреса микрооперация занимает 3 такта. Адрес может быть диспетчеризован с шины X во втором или третьем такте (смотреть строб au_qstbx). Во втором такте это всегда исходный аргмент, то есть до модификации, в третьем - уже результат из АЛУ. Можно было бы и пре-декремент в одну операцию вписать, почему не сделали и как оно практически работает - тоже надо смотреть.