nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 14 Nov 2018 11:43



Reply to topic  [ 254 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 17  Next
4-bit Processor 
Author Message
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Итак - первая версия проекта 4_Bit_CPU, с которой можно начать корректно воплощать все наши планы.

Image

Избавился от всех атавизмов и связанных с ними иголок и сбоев.
Переписал ПЗУ микропрограмм, и теперь с ним работать будет легче.
Что написано в ПЗУ - то и будет напрямую управляющими сигналами.

Теперь - самое интересное: вписать под 16 управляющих сигналов всех
планов громадьё... :wink:
Это как бутылочное горлышко... Но надо будет избавиться от такого барства:
для каждого элемента свой строб. Дешифраторы добавлю - место как раз освободилось...

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


23 Mar 2012 07:03
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Вычистил найденные баги, в том числе и Протезные. :wink:
Внёс изменения, связанные с реализацие вызовов-возвратов (с этой целью
в РС поставил счётчики 155ИЕ7 - они проще для параллельной загрузки,
на мой взгляд, и их достаточно у меня.)
Задействовал дешифратор 155ИД4 (их у меня тоже достаточно),
чтобы освободить часть выводов ПЗУ микрокоманд на управление нашим АЛУ.

Image
УВЕЛИЧИТЬ

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

Далее собираюсь высвободить часть выводов верхнего по схеме ПЗУ микрокоманд
для управления АЛУ и механизмом вызовов-возвратов.
Естественно, в оригинальную систему команд внесу изменения: префикс и др.
Понемногу продумываю систему команд на основе существующей схемотехники.


PS. Дополнительный софт для редактирования микрокоманд пока писать не стал.
С неудобствами, но обхожусь редактором из Folder Manager (он умеет переставлять
блоки столбцов), ну и WinHEX зело помогает...


28 Mar 2012 13:15
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
АЛУ в 4-битном процессоре

Я сделал прикидку привязки нашего 4-битного АЛУ к схеме разрабатываемого 4-битного процессора.



При этом я пытался по возможности вносить минимальные изменения в нашу рабочую модель процессора, а также старался выдержать концепцию RISC, которой мы решили придерживаться в нашей конструкции, хотя это и накладывает определённые особенности как на схемотехнику ЦПУ, так и на характер системы команд.

Типичная диаграмма двух циклов, характерных для схемотехники нашего ЦПУ, приведена на следующей осциллограмме:



Диаграмма характерна для выполнения следующих команд:

MVI A,LIT
SEL R,NUM

Где LIT и NUM - аргументы команд (4-битные величины), которые в ходе и выполнения выводятся на магистраль данных.

Подробно выполнение происходит так:

FETCH:
Такт 0: нет операций.
Такт 1: значение PC выдаётся на адресные линии ОЗУ программ (Stb Addr).
Такт 2: программный счётчик PC увеличивается на единицу (Inc PC).
Такт 3: нет операций.
MVI A,LIT (В этот момент код операции поступает на ПЗУ микрокоманд.)
Такт 4: значение LIT поступает на магистраль данных (/Enable DATA).
Такт 5: значение LIT с магистрали данных записывается в аккумулятор (/LD Accum).
Такт 6: значение LIT удерживается на магистрали данных (/Enable DATA).
Такт 7: магистраль данных переходит в высокоимпедансное состояние.

FETCH:
Такт 0: нет операций.
Такт 1: значение PC выдаётся на адресные линии ОЗУ программ (Stb Addr).
Такт 2: программный счётчик PC увеличивается на единицу (Inc PC).
Такт 3: нет операций.
SEL R,NUM (В этот момент код операции поступает на ПЗУ микрокоманд.)
Такт 4: значение NUM поступает на магистраль данных (/Enable DATA).
Такт 5: значение NUM с магистрали данных записывается в селектор (STB REG).
Такт 6: значение NUM удерживается на магистрали данных (/Enable DATA).
Такт 7: магистраль данных переходит в высокоимпедансное состояние.

Видно, что запас на один такт в диаграмме существует, но выполнить команду, к примеру, MOV A,R за один цикл при существующей схемотехнике проблематично. Поэтому присутствует несколько необычная команда предварительного выбора рабочего регистра: SEL R,NUM.

Если попробовать выполнить за один цикл, или за 4 такта, команду MOV A,R, то это, как мне кажется, вызовет конфликт на магистрали данных.



Напомню, что в нашей конструкции любая команда выполняется за 8 тактов (0-7), фактически образующих два цикла: цикл выборки инструкции (FETCH, такты 0-3) и, собственно, цикл выполнения (такты 4-7).
То есть, уникальных тактов для выполнения самой инструкции в нашем распоряжении всего четыре, но я предполагаю, что и инструкции переходов мы сможем выполнить за один цикл, что, собственно, и характерно для RISC-концепции.
Но такая концепция приводит к несколько необычной системе команд, если придерживаться также требования простоты конструкции.

FETCH:
Такт 0: нет операций.
Такт 1: значение PC выдаётся на адресные линии ОЗУ программ (Stb Addr).
Такт 2: программный счётчик PC увеличивается на единицу (Inc PC).
Такт 3: нет операций.
SEL R,NUM (В этот момент код операции поступает на ПЗУ микрокоманд.)
Такт 4: значение R поступает на магистраль данных (/Enable DATA).
Такт 5: значение R с магистрали данных записывается в селектор рабочего регистра
по фронту сигнала (STB REG).
магистраль данных переходит в высокоимпедансное состояние - сигнал
(/Enable DATA) становится неактивным.
Такт 6: содержимое регистра R выводится на магистраль данных из блока регистров
Общего назначения (/WR).
содержимое регистра R с магистрали данных записывается в аккумулятор
(/LD Accum).
Такт 7: магистраль данных переходит в высокоимпедансное состояние - сигнал
(/WR) становится неактивным.

По завершению такта 5 значение R снимается с магистрали данных, но на начале такта 6 содержимое регистра R выводится на магистраль данных из блока регистров общего назначения: в этот момент, на мой взгляд, и возможен конфликт. Между этими событиями нужен хотя бы один такт, когда магистраль данных находится в высокоимпедансном состоянии (но, возможно, это следует позже проверить).


Last edited by Lavr on 31 Mar 2012 12:14, edited 2 times in total.



31 Mar 2012 08:48
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Я решил не вводить Буферный регистр Т, как это сделано, к примеру, у Интел в i8080.



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

MVI T,LIT
MOV T,R
MOV R,T


Но поскольку перед выполнением операции АЛУ оба аргумента должны быть зафиксированы на его входах, я решил блок регистров общего назначения (РОН) подключить к АЛУ в качестве второго операнда, благо микросхема К155ИР26 - двухпортовая. Пусть любой из РОН будет способен выполнить роль буфера Т . Но в этом случае операции АЛУ выполняются только между аккумулятором и регистром, что, впрочем, не противоречит RISC-концепции.

Модели в Протезусеприобретённая мною в качестве блока регистров общего назначения микросхема К155РУ2 не имеет, и временно я её использовать не буду. Работу с АЛУ обкатаем с блоком РОН на К155ИР26.
Выбранный способ включения требует изменений в структуре разработанного нами ранее 4-битного АЛУ. Необходимы две дополнительные команды, делающие АЛУ прозрачным для каждого из аргументов. Поскольку пересылка между аккумулятором и регистрами общего назначения будет проводиться сквозь АЛУ. Подобный трюк мы здесь рассматривали.
С другой стороны такое включение может позволить реализовать особенность микроконтроллеров PIC - результат можно сохранять не только в аккумулятор, но и в нужный регистр.
Входы S0-S3 выбора функции АЛУ подключены к линиям шины инструкций постоянно. Это упрощение возможно, поскольку АЛУ выполняет операцию и выводит результат на магистраль данных только по активному сигналу /OE, в противном случае состояние входов S0-S3 выбора функции безразлично.

Специфика включения АЛУ в состав нашего ЦПУ определяет следующий набор команд:
Code:
MVI A,LIT;
MVI R,LIT;
MOV R,A;
MOV A,R;
SEL R,NUM;
INR A;
DCR A;
ADD;
ADC;
SUB;
SBB;
CMP;
ORA;
XRA;
ANA;
RAL;
RAR;
RLC; *
RRC; *

Две последние операции, возможно, придётся упразднить на служебные операции прозрачности АЛУ (F = A и F = R) для содержимого аккумулятора и выбранного регистра соответственно.

Операции между аккумулятором и константой недоступны.
Code:
ADI LIT;
ACI LIT;
SUI LIT;
SBC LIT;
CPI LIT;
ORI LIT;
XRI LIT;
ANI LIT;

и т.п.


В качестве примера посмотрим, как сложить число 5 в аккумуляторе с числом 7.

MVI A,5; загрузим первый операнд АЛУ в аккумулятор
SEL R,0; выберем регистр общего назначения R0 на ввод и вывод
MVI R,7; загрузим второй операнд АЛУ в регистр R0
ADD; сложить содержимое аккумулятора и R0 (результат - в аккумулятор)

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


Last edited by Lavr on 07 Apr 2012 14:38, edited 3 times in total.



31 Mar 2012 08:58
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Я сделал оценку, так сказать по месту, какая система команд получается
у нас в итоге с введением АЛУ и обсужденных ранее схемотехнических
решений, а также с учетом одного префикса.

Image

Зелёным выделены команды АЛУ.
Стек на один адрес возврата (поэтому вызов-возврат цветом выделены). :wink:

Чего у нас в системе команд нет:

1. Нет операции записи в память программ (аппаратно сильно усложняет).
2. Нет инструкций RLC и RRC , как я и предполагал, они не влезли. Их можно реализовать так:
Code:
   RAL; 1<-1010.1010 = 1_0101.0101
   SKIPNC; Переноса нет, пропустим след. команду -> M1
   ORI  1; 1000 =Учтём перенос
M1:

   RAR; 1->1010.1010= 1101.0101_0
   SKIPNC; Переноса нет, пропустим след. команду -> M2
   ORI  1; Учтём перенос
M2:

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

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


PS. Коды команд не обязательно такие, я просто пока уложил все команды в 31 возможную позицию.

_________________
iLavr


07 Apr 2012 13:24
Profile
God
User avatar

Joined: 13 Nov 2010 05:06
Posts: 1292
Reply with quote
Lavr wrote:
я просто пока уложил все команды в 31 возможную позицию.[/i]

Что-то я вижу в таблице 33 возможных команды...


29 May 2012 09:11
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
VituZz wrote:
Lavr wrote:
я просто пока уложил все команды в 31 возможную позицию.[/i]

Что-то я вижу в таблице 33 возможных команды...

FETCH - выборка кода - не команда и PREFIX - не команда, а префикс.

_________________
iLavr


29 May 2012 12:10
Profile
God
User avatar

Joined: 13 Nov 2010 05:06
Posts: 1292
Reply with quote
Post 
Всё равно непонятно. По кодам операций:

0h - SEL R, NUM
...
Eh - OUT NIB
Fh 0h - NOP
...
Fh Fh - RAL
??? - RAR


29 May 2012 20:34
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
VituZz wrote:
Всё равно непонятно. По кодам операций:

0h - SEL R, NUM
...
Eh - OUT NIB
Fh 0h - NOP
...
Fh Fh - RAL
??? - RAR

Значит придётся в чем-то ужаться и чем-то ещё пожертвовать, RRC, RLC уже уволил... :(
В частности, FETCH можно вынести за таблицу, к примеру, на адреса выше таблицы.
Аппаратно это не трудно, но я еще не попробовал окончательно этот вариант.

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

Хотя бы RET с возвращаемым параметром нужен и JMP по содержимому регистра что ли...


PS. Собственно поэтому я и написал, что комманд 31 - так оно и есть.
Первый '0' в таблице сбил подсчёт, похоже...
:wink:

PPS. Вот чем и полезно обсуждение! Свой взгляд привычно замыливается
и ошибки видеть перестаёт! А со стороны несоответствие - явно в глаза бросается!
:kruto:

_________________
iLavr


Last edited by Lavr on 02 Sep 2012 04:37, edited 1 time in total.



30 May 2012 05:36
Profile
God
User avatar

Joined: 13 Nov 2010 05:06
Posts: 1292
Reply with quote
Post 
Ну раз уж от префикса мы никуда не ушли, то возможно, есть смысл ввести ещё один? Или даже, если это упростит устройство управления, все команды сделать двухниббловыми? Возможно, при сохранении 4-битных регистров обращение к памяти сделать байтовым?


30 May 2012 09:17
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Возможно ты прав. Тут вот какая трудность: 4-битный проц на 256 байт памяти
логичен и прост.
Собственно, ты правильно в этом топике ранее это отметил.
Но 256 байт не позволяют сделать что-то путное - даже калькулятор.

Те же решения но в 8-битном проце тоже логичны и просты и дают без проблем 64 КБайт памяти.
Только это фактически удваивает число корпусов. И практически, мы согласились, что это
неприемлемо для любительской конструкции.

Компромисс - 4-битный проц с 12-битной шиной, что даёт 4КБайт памяти - и можно на что-то
серьёзное рассчитываить.
Но вот этот третий ниббл в шине очень затрудняет всю схемотехнику...
Ибо он как бы "ни в 3.14...у ни в красную армию" внутри проца. :(
Потому что 256 байт - это как бы дважды по 4 по шине, 64 КБайт - дважды по 8, если
обращаться по шине то есть в 1-м случае - 4 битный регистр в железе,
а во 2-м восьмибитный тоже один.

Чтобы не сломать логику проекта - мне приходится ввести либо сразу 12-битный регистр
(3 х 4 рег.), либо трижды обращаться через
шину, что мне катастрофически не нравится т.к. портит всю RISC-конструкцию.

Но вот сейчас в APOLLO181 я подсмотрел фишку очень интересную!
Gianluca.G. wrote:
Старшие 4-битные данные на входе счетчиков представляют собой 4-бита непосредственного операнда команды перехода; младшие 4-битные данные на входе счетчиков являются 4-битовым значением на выходе аккумулятора: так программа перейдёт на адрес ячейки ОЗУ вычисляемый как (16 * непосредственный операнд + значение на выходе аккумулятора) в десятичном виде.
Использование как непосредственного операнда, так и аккумулятора для формирования 8-битного слова, позволяет единственной команде перехода иметь доступ ко всем 256 позициям ОЗУ.

Похоже - такое решение может помочь мне с неудобным 3-м нибблом.
Хотя использование аккумулятора в формировании адреса перехода мне кажется непривычным...
Но идея интересная и необычная. Хочу её проработать подробнее...


PS. Поэтому мне и понравился проект APOLLO181! Не сочтите за рекламу - но для меня -
есть интересная изюминка!
:kruto:

PPS. И ещё одно интересное наблюдение из APOLLO181: все команды АЛУ можно выполнить
одной - MOV S,R. Где S - регистр на входах выбора функции АЛУ.


PPPS. И начал я склоняться к выводу, что много команд и не надо. Даже опыт провёл:
из 33-команд PIC я выкинул все специфичные для PIC. Их осталось ОЧЕНЬ МАЛО! :o
А на PIC нужная мне задача решается - я уже пробовал!

_________________
iLavr


30 May 2012 11:39
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Я решил внести и обсудить некоторые модификации в схемотехнику 4-bit CPU, которые должны позволить ввести довольно оригинальный механизм возврата из подпрограмм без значительного усложнения схемотехники.

Для реализации безусловного перехода JMP ADDR используем в конструкции в качестве программного 12-разрядного счётчика PC, позволяющего адресовать 2^12 = 4096 слов памяти программ, три 4–битных счётчика типа К155ИЕ7 с опцией параллельной загрузки. Выходы счётчиков через регистры с тристабильным выходом подключены к адресным линиям ОЗУ программ. Входы же счётчиков поразрядно подключены к 12 выходным тристабильным линиям данных микросхем ОЗУ программ. Четыре оставшиеся линии данных микросхем ОЗУ выводят код команды на входы ПЗУ микропрограмм.

В свете такого аппаратного решения безусловный переход JMP ADDR в разрабатываемом ЦПУ реализуется параллельной загрузкой в программный счётчик PC 12–ти бит адреса перехода по стробу параллельной загрузки /STB ADDR.

Поскольку реализация аппаратного стека в такой простой конструкции, конструируемой по RISC–концепции, вызывает неоправданное усложнение, первоначально было решено реализовать стек хотя бы с одним адресом возврата. С этой целью в конструкцию вводились три 4–битных регистра с тристабильными выходными линиями, входы которых подключались к выходам 12–ти битного программного счётчика PC, а выходы — к его входам. При вызове подпрограммы CALL ADDR, адрес возврата фиксировался в трёх 4–битных регистрах по стробу /STB RETADDR, а в 12–ти битный программный счётчик записывался адрес перехода с линий данных микросхем ОЗУ программ по сигналу /STB ADDR. При выполнении команды возврата RET выходы трёх 4–битных регистров по сигналу /E RETADDR подают адрес возврата на входы 12–ти битного программного счётчика, куда он и записывается по стробу /STB ADDR.

Image

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

Известно также решение по реализации механизма возврата из подпрограмм без использования стека адресов возврата. Оно заключается в записи адреса возврата в первую ячейку подпрограммы (JMS SUBR). При этом сама подпрограмма заканчивается оператором косвенного перехода по значению, записанному в первой ячейке подпрограммы. У решения имеются и недостатки: невозможно прервать и повторно вызвать ту же самую подпрограмму (невозможность рекурсии), а, кроме того, подпрограммы должны находиться в оперативной памяти.

С аппаратной точки зрения метод хотя и проще механизма стека адресов возврата, но всё же достаточно сложен для схемотехники простого ЦПУ.

На мой взгляд, наиболее простой в существующих условиях является модификация этого метода, которая заключается в том, что в первую ячейку подпрограммы будем записывать не адрес возврата, а команду безусловного перехода на адрес возврата JMP RETADDR целиком, вместе с кодом операции. При этом для формирования кода команды JMP в схему добавим всего один дополнительный 4–битный регистр с тристабильными выходными линиями, на входе которого значение кода команды JMP будет формироваться подключением их соответственно к сигналам логических уровней нуля и единиц. Подпрограмма в таком случае заканчивается безусловным переходом JMP ADDR на адрес её первой ячейки, где, собственно, предварительно и была записана команда безусловного перехода JMP RETADDR на адрес возврата.

Рассмотрим весь механизм несколько подробнее.
1. В цикле выполнения команды вызова подпрограммы JMS SUBR ЦПУ вначале выполняет инструкцию выборки кода команды FETCH, которая заключается в фиксации текущего значения программного счётчика PC в регистре адреса сигналом STB INSTR, и в инкременте значения PC на единицу сигналом INC PC.
2. В этот момент счётчик PC содержит значение адреса возврата, которое фиксируется тремя 4–битными регистрами по сигналу /STB RETADDR. В четвёртый регистр по этому же сигналу записывается значение кода JMP. Таким образом, во всех четырёх регистрах записана комбинация бит JMP RETADDR. Сигнал /STB RETADDR блокирует следующую инструкцию FETCH, (либо на ПЗУ, либо переключив строб чтения ОЗУ).
3. По сигналу /E INSTR DATA на входы программного счётчика PC выдаётся адрес подпрограммы SUBR, который и записывается в PC по сигналу /STB ADDR. Эти операции выполняются за 4 такта цикла выполнения команды.

Image

4. После этого должен выполниться следующий цикл выборки кода команды FETCH, но ранее сигналом она была заблокирована, поскольку вместо выборки кода команды нам необходимо выполнить запись по адресу, содержащемуся в программном счётчике PC. Для этого значение PC выводим в регистр адреса сигналом STB INSTR, и увеличиваем значения PC на единицу сигналом INC PC. Адрес начала подпрограммы зафиксирован на линиях адреса ОЗУ программ, в то же время PC содержит адрес следующей ячейки. Эта часть цикла аналогична выполнению команды FETCH, но во второй части цикла сигналом /E RETADDR подадим код комбинации JMP RETADDR с выходов четырёх регистров на входы данных микросхем ОЗУ программ. После чего запишем этот код в ОЗУ программ стробом /PRG WRITE. Сигнал /E RETADDR должен разблокировать выполнение команды FETCH на следующем цикле. Поэтому следующей будет выполняться первая инструкция подпрограммы, по начальному же адресу вызова подпрограммы нами записана инструкция JMP RETADDR.
5. Возврат из подпрограммы осуществляется в её конце безусловным переходом JMP ADDR на адрес начала подпрограммы, где хранится записанный ранее код безусловного перехода JMP RETADDR на адрес возврата из подпрограммы. Механизмы работы безусловных переходов вместе с действующими управляющими сигналами подробно описаны выше.

Замечания: в схеме, которая существует на данный момент, выходы ОЗУ инструкций подключены на входы ПЗУ микрокоманд через вентили постоянно, поскольку активный сигнал /RUN MODE постоянно подаёт сигналы на входы выборки /CS ОЗУ инструкций. Чтобы иметь возможность реализовать изложенный выше механизм возврата из подпрограмм схемотехнику следует изменить, введя регистр инструкций (команд, кодов операций) и фиксируя в нём инструкцию, а выходы ОЗУ инструкций выключать после фиксации инструкции.

Возможно, ширину инструкции следует увеличить до 8 бит, что позволит более просто схемотехнически ввести либо 2 префикса (Eh, Fh), либо расширить систему команд до 2^8 = 256 инструкций. С двумя префиксами получим 16+16+14=36 команд.

Инструкция, ВЫБОРКА (FETCH код 00H), всегда используется логикой микрокоманд в тактах 1 – 3 и никогда не должна использоваться программой. Лучше вынести код FETCH за 15H, подав вывод 8 счетчика импульсов 74LS93(ИЕ5) на один из старших адресов ПЗУ микрокоманд (573РФ2,5) через инвертор. В этом случае код 00H может быть назначен операции NOP, что удобно для замещения отдельных кодов даже в ПЗУ. Это даст возможность заблокировать инструкцию FETCH в цикле записи адреса возврата.


PS. Единственное чего не хватает, это косвенной адресации... не вижу как массив обработать...
Хотя бы PIC-овский RETLW пригодился... надо обдумать...

_________________
iLavr


01 Sep 2012 01:30
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
КОСВЕННАЯ АДРЕСАЦИЯ

Для косвенной (indirect) адресации в конструкцию ЦПУ приходится ввести специальный регистр (обычно его называют MEM), по содержимому которого происходит обращение к необходимой ячейки памяти. Также бы в этом случае неплохо иметь возможность чтения программного счётчика PC.
Схемотехнически это реализовать не трудно, но, поскольку во главу угла поставлен схемотехнический минимализм, эти решения не оптимальны. Так специальный регистр MEM аппаратно выльется в 3 корпуса защелок с тристабильным выходом, а чтение программного счётчика PC - в 2 дополнительных двунаправленных формирователя также с тристабильным выходом.

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

В основе этого механизма лежит аппаратная возможность записать 4 бита с внутренней шины данных в младший разряд программного счетчика PC (PC LOW).
По аналогии с PCHL от i8080 можно временно ввести свою такую команду - PCDB, причем источником ниббла на внутренней шине данных может быть как аккумулятор, так и один из регистров общего назначения.
Такая возможность позволяет нам передать управление посредством загрузки нибблом младшего разряда программного счетчика PC LOW в пределах 16 шагов программы.

С учетом предложенного выше механизма возвратов индексированный доступ можно осуществить следующим образом.
Code:
0050:    ANI 0H;      чистим А и флаг переноса С.
0051:    MVI A,4H;      укажем в А - индекс массива
0052:    RAL;         удвоим индекс массива А, т.к.
0053:.   CALL ADRET      в массиве - два шага на бит
0054:CALLRET:         адрес возврата из подпрограммы
   ...
0100:      MVI A,0H;       <- сюда PCDB,A, если индекс = 0
0101:      JMP ADRET
0102:      MVI A,1H;       <- сюда PCDB,A, если индекс = 1
0103:      JMP ADRET
0104:      MVI A,2H;       <- сюда PCDB,A, если индекс = 2
0105:      JMP ADRET
0106:      MVI A,3H;       <- сюда PCDB,A, если индекс = 3
0107:      JMP ADRET
0108:      MVI A,4H;       <- сюда PCDB,A, если индекс = 4
0109:      JMP ADRET
010A:      MVI A,5H;       <- сюда PCDB,A, если индекс = 5
010B:      JMP ADRET
010C:      MVI A,6H;       <- сюда PCDB,A, если индекс = 6
010D:      JMP ADRET
     ORG 10EH;         выровнять на параграф придётся вручную
010E:ADRET:JMP CALLRET; <-- вписывает механизм возврата
010F:      PCDB,A;       в PC (2 х индекс из А - аккумулятора)

Если механизм непонятен, то это аналогия с программированием PIC, где используется инструкция RETLW - возврат из подпрограммы с заполнением аккумулятора (W) константой.

Code:
  movlw   tune0; Get address of table
  movwf   PCL  ; Jump off to the table entry
  ...

tune0:
  retlw 0x17  ;B
  retlw 0x78  ;240
  retlw 0x1A  ;D
  retlw 0x3C  ;120
  retlw 0x17  ;B
  retlw 0x3C  ;120
  retlw 0x12  ;F#
  retlw 0x78  ;240

Переходы по таблице получаются также относительно просто:

Code:
0050:    ANI 0H;      чистим А и флаг переноса С.
0051:    MVI A,4H;      укажем в А - индекс массива подпрограмм
0052:    RAL;         удвоим индекс массива А, т.к.
0053:.   CALL ADRET      в массиве - два шага на бит
0054:CALLRET:         адрес возврата из подпрограммы
   ...
0100:      CALL SUB0;       <- сюда PCDB,A, если индекс = 0
0101:      JMP ADRET
0102:      CALL SUB1;       <- сюда PCDB,A, если индекс = 1
0103:      JMP ADRET
0104:      CALL SUB2;       <- сюда PCDB,A, если индекс = 2
0105:      JMP ADRET
0106:      CALL SUB3;       <- сюда PCDB,A, если индекс = 3
0107:      JMP ADRET
0108:      CALL SUB4;       <- сюда PCDB,A, если индекс = 4
0109:      JMP ADRET
010A:      CALL SUB5;       <- сюда PCDB,A, если индекс = 5
010B:      JMP ADRET
010C:      CALL SUB6;       <- сюда PCDB,A, если индекс = 6
010D:      JMP ADRET
     ORG 10EH;         выровнять на параграф придётся вручную
010E:ADRET:   JMP CALLRET;  <-- вписывает механизм возврата
010F:      PCDB,A;       в PC (2 х индекс из А - аккумулятора)

Это также аналогия с программированием PIC (переходы по таблице):

Code:
  MOVFW  PARAM    ;get code byte
  ANDLW  0FH      ;W = instruction code offset
  ADDWF  PC,1     ;jump to handler table
  ...
  GOTO  HND0;  <-- PC
  GOTO  HND1
  GOTO  HND2
  GOTO  HND3
  GOTO  HND4
  GOTO  HND5
  GOTO  HND6
  GOTO  HND7
  GOTO  HND8
...

HND0:
...

Механизм несколько неудобный, тем, что выравнивать таблицу на параграф приходится вручную, но такая ситуация и при программировании PIC иногда возникает.
Второе неудобство - короткий размер таблицы - ну с этим придётся примириться, не усложняя проект аппаратно.
К примеру - обрабатывать крупный массив в несколько вызовов.

Аппаратно можно упростить процедуру, введя возможность записи в счетчика PC HI но мне пока это представляется усложнением излишним.

Я ещё не подсчитал общее число корпусов, но по соотношению затраты/возможности пока всё неплохо выглядит. Вот для сравнения - EDUC-8 - 100 корпусов, 256 байт памяти, и не сказать, что шибко круче! :wink:

_________________
iLavr


02 Sep 2012 04:23
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Ну, вот этот мужик меня на принятие решений сподвиг своим процессором! :lol:

Я мучаюсь тут, голову ломаю, как-бы всё сделать, да ещё и 1 корпус ОЗУ программ
сэкономить и исключить, раз уж проц 4-битный... :-?

А тут - АЛУ 8-битное и - на тебе - бабах! - 32 бита по шине!!! :o

Image

А тут уже есть - 2 копуса на 16 бит - а я себя мучаю, панемаишь! :wink:
Пожалуй, кое-что и упростить ещё получится...

Ещё в документации на 4-bit Wang 2200 читал, что широкая команда зело всё упрощает!
Но очень уж поджаться схемно хотелось... :-?

_________________
iLavr


02 Sep 2012 07:19
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Я тут ставил на работе "Протезус", - он глюкал своими лицензиями,
упирался, вредил, не хотел "играть" свои собственные проекты...
Но в итоге я его "усовестил" и для теста решил прогнать большой
проект, для чего и взял его отсюда...

Ну так всё хорошо работает на шустрой машине! :o Ну просто -
как часы! Прямо как и было задумано всё... :kruto:
И что удивительно, для такой сравнительно большой схемы, загрузка
процессора составляет 4-6%! :o Что значит - все элементы цифровые!

Прямо ломать не хочется... :wink:

Но раз уж мы созрели до серьёзных "Протезус"-ных DLL, я думаю,
что АЛУ в качестве разминки я попробую написать сюда в форме
DLL-цифровой модели...

_________________
iLavr


26 Nov 2012 11:24
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 254 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 17  Next

Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.