PC - CNT vs REG+ALU?

[HardWareMan]

Чето всех прибивает на "чемоданный" дизайн.

[vinxru]

Начал отрисовывать Программный Счетчик (РС) и последовательный Сумматор -
EDUC-8_PC_ADDER_logic и был удивлён неимоверно!

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

А я как-то привык, что Программный Счетчик - это двоичный СЧЁТЧИК, как ни крути...
И РС = РС + 1 - это один управляющий импульс на вход инкремента +1 !

Я то же когда рисовал процессор инкрементировал PC с помощью АЛУ.

[Lavr]

На мой взгляд - приём довольно нерациональный для любительской конструкции ЦП,
как с точки зрения быстродействия, так и по количеству компонентов, участвующих в
организации связей РС и АЛУ.

Кстати говоря, а где бы посмотреть схемотехнику твоего процессора?
Интересуюсь такими схемами...

[vinxru]

Наоборот, схема упрощается. Больше не нужен счетчик, меньше мультиплексоров.

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

http://s52.radikal.ru/i135/1201/7b/848f9fc70473.png

4 регистра. IP, A, ADDR, DATA. Регистр ADDR подключен к шине адреса памяти, DATA к шине данных. Две операции NAND и ADD. Запись - это сложение с нулем.

Проверялся на программе:
0 A = 0
1 ADDR = A
2 DATA = A
3 A += 1
4 JNC 1
5 JMP 5

Я составил таблицу, где указаны аналогии команд процессора 6502 и этого чудо процессора. Например одна из самых сложных команд процессора 6502 AND IND, X реализуется последовательностью команд

ADDR = IND
A = DATA
ADDR = REG_X (костанта, т.е. адрес в памяти)
A += DATA
ADDR = A
A = DATA
ADDR = REG_A (костанта, т.е. адрес в памяти)
A = ~(DATA & A)
DATA = ~A

Или команда CALL ADDR

ADDR = REG_SP (костанта, т.е. адрес в памяти)
A = DATA+1
DATA = A
ADDR = A
DATA = IP+2
JMP ADDR

Соответственно при той же тактовой частоте это всё работает медленее, чем на процессоре 6502. Но зато мой процессор в 10 раз меньше.

А это предыдущая схема на кремнии, там у IP отдельный сумматор.
http://s017.radikal.ru/i400/1201/c7/b22c1c808621.png



Lavr: перенес продолжение темы сюда:---------------------------------------

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

Но как реализовать сохранение IP в память (для подпрограмм)? Надо коммутировать его на шину данных памяти. А дальше развиваем эту мысль, и засовываем его до АЛУ. Получаем некоторые плюсы бесплатно.

В два раза медленне, это да.

[Lavr]

Наоборот, схема упрощается. Больше не нужен счетчик, меньше мультиплексоров.

Не хочу спорить, но нисколько не упрощается. Мультиплексоров - как раз больше,
в тактах - всё становится длиннее.
Если не использовать фичу 6502 с относительной адресацией, то мультиплекоры
и просто не нужны.

Сравниваю свой проект 4-бит ЦПУ и этот ЕДУК-8, у меня при более скромной
схемотехнике уже получается более выразительная система команд...

Единственное, что я хочу уяснить, не поможет ли мне последовательное АЛУ
еще подсократить число корпусов.


PS. А схемы, похожие на твои, или даже - твои, сдается мне, я видел уже!

[Lavr]

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

Но как реализовать сохранение IP в память (для подпрограмм)? Надо коммутировать его на шину данных памяти. А дальше развиваем эту мысль, и засовываем его до АЛУ. Получаем некоторые плюсы бесплатно.

В два раза медленне, это да.

Ну с реле - тут я пас.

А сохранение IP в память (для подпрограмм) - я выполнил по типу PDP-8.

[vinxru]

Что то сообщения летают по темам

[Lavr]

Что то сообщения летают по темам

Отделил от ЕДУК-8 в отдельную тему, чтобы побеседовать по вопросам схемотехники
самодельных ЦПУ здесь.


PS. Весьма многопараметровая схемотехника - почти как шахматная партия!
Любое решение приводит к неоднозначным результатам: в чем-то выигрываешь,
а что-то неизбежно ухудшается...
Нет казалось бы неоднозначных решений. И все проанализированные мной схемы
от оптимума весьма далеки, хотя ивесьма разнообразны по схемотехническим решениям.

[Lavr]

Для инкремента 8-битного Программный Счетчика, выполненного почему-то на
сдвиговых регистрах (
содержимое Программного Счетчика прогоняют через сумматор для операции
его инкремента!

Может быть как-то иначе схемотехнически - это и меет смысл.
Пока вижу лишь один плюс в таком решении - можно организовать относительные переходы,
раз уж РС прогоняют через сумматор...
Но в ЕДУК-8 - это не реализовано.

А то что РС прогоняют через сумматор фактически в каждой команде, а бывает и два раза -
ну просто навевает уныние!

24 такта на команду! Это ж афегеть можно! Я "упихивался" в 8 тактов - 4 - FETCH +
4 - ИСПОЛНЕНИЕ, и то мне казалось, если сделать разное число тактов на команду -
схемотехника упростится...
А тут - 24 такта , и не скажу, что схемотехника проста...