4-bit Processor

[Lavr]

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

Хардыч - как ты говоришь:"Похоже, меня никто не читает!"
Для записи у меня только 16 4-битных регистров из К155РУ2. А поскольку записи в "ОЗУ программ" пока нет - то это мешает сохранять этот регистр где-нибудь еще, - фактически негде.
Регистры нужны для текущих задач. Так что - неправда...

Сохранить этот регистр нужны сразу 3 4-битных ячейки из 16, и как правильно заметил b2m - этого не сделать за 1 цикл...

Прошу не пинать, если я невпопад... Но почему мы не можем просто поставить ОЗУ нужной разрядности шины данных и к нему реверсивный счётчик? PUSH записывает в ОЗУ и добавляет к счётчику единицу, POP - обратные действия. Чем это решение не подходит? Вложенность стека определится только объёмом ОЗУ.

Мочь-то мы всё можем... но "нищебродская" религия не пускает...
Волков сделал "Специалист" с 2-мя линейками ОЗУ и одной ПЗУ.
А тут - убогая 4-битка и 2 ПЗУ и 2 статических ОЗУ!
Пока ситуация не выглядит безвыходной, пока "искусство схемотехники" не сдалось - я предпочитаю не добавлять БИС в конструкцию.

PS. Убрал баян про Эмулятор i8080 в железе

[VituZz]

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

[Lavr]

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

Ну вот я и пытаюсь сделать прикидку - как задействовать то ОЗУ, что уже есть.
Либо под стек, либо без него - под адреса возврата.

Иначе 4-битная поделка становится слишком расточительной!
Вон DEC PDP-8 и то была более скромной...

[VituZz]

Обычно блок-схемы в той или иной степени упрощены. Столь детальные вопросы они решать не призваны. Дешифратор команд, возможно, имеет регистры не только для КОП, но и для адресов в командах. Но это не более, чем догадка. На блок-схемах я таких подробностей не встречал.

[Lavr]

Ну вот я и пытаюсь сделать прикидку - как задействовать то ОЗУ, что уже есть.
Либо под стек, либо без него - под адреса возврата.

Довольно экономное решение стека можнo слямзить у 6502 в принципе.
Стек фиксированный и расположен в нулевом 256-байтном сегменте.
Для этого ввести придётся 8-битный указатель стека. Без указателя сегмента.
Ещё мультиплексор понадобится РС и SP коммутировать на адреса памяти.
Мультиплексор на ОК - вполне прост.

Вот только память пока - Read Only...

[shoorick]

можно стек держать в отдельной памяти у 8080 для этого была возможность - сигнал в слове состояния

[MC68k]

а сегментные регистры будут?

[Lavr]

а сегментные регистры будут?

Не будут. Уже есть. Схема кусками в топике. Но не окончательная.

PS. Основную идею повторю ибо бывает людям лень полистать:

...я собираюсь танцевать вот от этого образца как от прототипа.

Источник

Я его смоделировал, он успешно работает,
viewtopic.php?t=9213
далее - расширю его до 8 бит и вделаю здешнее АЛУ.

Мы оттолкнулись от этой схемы, как простой, РАБОТОСПОСОБНОЙ!, местами оригинальной.
Сделали для неё своё АЛУ - можно выбрать подходящий вариант, ибо всё обсудили здесь.
Теперь модернизируем сам процессор, обсуждая его систему команд и их реализацию
по ходу этого топика.

Схемы в топике приводятся.

Но тормозит всё и ступор сейчас на

CALL ... RET

будет стек или нет.

Пока количество разных книг и др.источников склоняет меня к НЕТ именно из-за
большей простоты схемотехники.

Мы всё же пришли к выводу, что без нормальных CALL ... RET очень кисло.
Хотя и кривые CALL ... RET там реализованы...
Но слишком уж кривые: RET - только на фиксированный адрес, а CALL - только на начало
любого параграфа.

И ещё неприятный тормоз - внутренняя магистраль 4-битная, а шина адреса для
памяти программ - уже 12 битная (для 4096 байт вместо 256).
Варианты переходов не получаются RISC-типа (за 2 цикла).
Всёж мы заложились - все команды за 1 машинный цикл, и лишь дальние переходы -
за 2 цикла.
Может быть это очень жесткие требования к нашей поделке.

[Lavr]

Я просмотрел очень много схем "самогонных" процессоров из Интернета,
большинство ссылок на них приведены в этом топике 4-BIT.

В подавляющем большинстве их делают именно так как советует VituZz:
"если нам необходимо ОЗУ - давайте вставим микросхему ОЗУ".
Я не могу сказать, что это неверно - но схему распирает не по децки...
Тут уж и желание "поиграцца" исчезает напроч.

Поэтому я стараюсь найти здесь оригинальные компактные решения, чтобы
и процессор получился не игрушкой, но и схема не вылезла за габариты
большой макетки.
И первый компромисс был - ограничение в 4 бита.
Иначе только АЛУ занимало практически всю большую макетку.

[Lavr]

В проекте Titan - The 8 bit TTL Processor стек, похоже, выполнен отдельно, в одном корпусе ОЗУ.



Это несколько странно, поскольку, как видно из блок-схемы, памяти у него хватает...
В отсутствие схем (уже долгое время) трудно сказать, был ли какой схемотехнический
выигрыш у автора, или просто "рука так легла"...

[Lavr]

Читал статеечку Микропроцессор своими руками-5 - некоторые положения меня просто в осадок выбросили...
Ну не стремятся люди к простоте!

- Гарвардский процессор сделаем?
- Гарвардский... Он понадёжнее будет...
- А как мы будем грузить память команд и как будем отлаживать программу? Как было сказано выше, процессор не имеет доступа по записи в собственную память команд.
- Но ведь должны же быть и нетривиальные решения. Да, конечно. И одно из таких решений — это внешний загрузчик. Представим себе, что память программ выполнена как двухпортовая память. Один ее порт используется основным процессором, тем, который мы разрабатываем, а второй порт этой памяти подключен к загрузчику. В качестве загрузчика мы можем использовать как простенький статический автомат, так и внешний, по отношению к микросхеме, процессор.

Честно говоря, я об такую ерунду уже спотыкнулся и сам...
Когда думал, как аппаратно загружать память программ - легкомысленно сказал себе - да PIC можно поставить...
Сам же и одумался: 4-битную поделку и PIC-ом загружать? Да она портов его не стОит...

[Lavr]

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

Что-то похожее реализовано в "Машине Мано"

Если посмотреть её систему команд, то есть команда довольно небычная:

Code: Select all

BSA ad	d101 aaaaaaaaaaaa	(ad) <== PC	запоминание счетчика команд

То есть как таковые вызов и возврат можно и не делать.
Запомнили счетчик команд, перешли на подпрограмму, а при возврате просто загрузили счетчик команд значением возврата.
Только в отличие от стека, за адресами возвратов придётся вручную следить.
Но я так представляю, что это не столь трагично. В PDP-8 без рекурсии справлялись.

Хардыч, а поплотнее у МИПС где взглянуть этот момент?

[Lavr]

Возможно, твой вариант может быть аппаратно "снизу вверх" совместим с моим?

Я выложил рабочий прототип 4-битного ЦПУ, и всяк может теперь в модели пробовать
свои и чужие замыслы.

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

[Lavr]

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

И мне кажется, одно оригинальное аппаратное решение по реализации вызова подпрограммы и возврата у меня в процессе завершения работы над моделью прототипа Stupid PIC всё-таки вырисовалось...

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

Если встречается CALL, основной счётчик делает выборку кода операции и
увеличивается на 1 (РС=РС+1). Это и будет адрес возврата.
После этого адрес подпрограммы заносится в дополнительный программный
счётчик, и подпрограмма выполняется на нём.
Когда встретится команда RET - надо будет лишь переключиться
обратно на основной РС.

Хуже чем у МИПСов точно не будет! Но экономим на выполнении операций:
1. считать значение РС.
2. сохранить значение РС.
3. снова считать сохранённое значение РС.
4. загрузить РС.
аппаратно эти цепи будут не нужны. Функциональность как с одним регистром
адреса возврата, куда сохраняется адрес при вызове подпрограммы.
Но аппаратно - компактно и очень неплохо вписывается в нашу схему.

В принципе и третий РС так можно ввести. Чтобы хотя бы два уровня вложения
подпрограмм было.

К ОЗУ программ РС всё равно подключается через тристабильный регистр.
Так что оба дополнительных РС мешать не будут.

И по этой же схеме, похоже, надо ввести в схему регистры для записи в память.
Хотя бы парочку: индекс источника и индекс приёмника.

[VituZz]

Интересное решение!

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