АЛУ на NAND

[Lavr]

Я понимаю, что при переходе от вышеприведенной схемы АЛУ на NANDы это не имеет значения, но всё же почему для формирования флага Z выбрана ЛИ6, а не более распространённая ЛА1 со входами, подключенными к прямым выходам КП7? Это и по скорости должно быть быстрее, если верить справочнику Шило.

Это потому, что при переходе на NAND-ы ни КП7, ни ЛИ6 не будет,
то я и заюзал инверсные выходы КП7 так, поскольку меня поджимал
размер картинки в 640 точек, характерный для нашего форума.
Мне это показалось и схемотехнически более элегантным, раз уж я не
ограничен в выборе микросхем, - с пользой заюзать инверсные выходы.
Но заодно у меня есть прицел и на вторую половинку ЛИ6.
Правда, в плане обсуждения - не знаю, - воплотится ли он.

А скорость здесь по-любому ограничит сумматор со своими последовательными
переносами флагов С.

[MC68k]

Вопрос на засыпку: если убрать команды сложения с учетом флага переноса и вычитания с заёмом - то как реализовать многобайтную арифметику?
Типа - если С=1, то сделаем дополнительно А+1?
Мне кажется это накладно... но вернуться к этому можно. Такой вариант я тоже рассматривал:

убрать команды без переноса

[Shaos]

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

[jdigreze]

Вопрос на засыпку: если убрать команды сложения с учетом флага переноса и вычитания с заёмом - то как реализовать многобайтную арифметику?
Типа - если С=1, то сделаем дополнительно А+1?
Мне кажется это накладно... но вернуться к этому можно. Такой вариант я тоже рассматривал:

убрать команды без переноса

И ввести команду пропуска следующей команды по флагу переноса.

[MC68k]

BTFSC/BTFSS

[Lavr]

арифметика и с переносом нужна, и без

Я привёл пример PIC-а. У него нет арифметических команд с переносом и заёмом.
Но математику сделать можно. По принципу как я выше сказал:
Скажем, есть сложение двух многословных аргументов (слово у нас 4-битное)

Code: Select all

ADD  R0
ADC  R1; Учтём перенос

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

Code: Select all

   ADD  R0
   JNC  M1; Переноса нет
   ADI  1; Учтём перенос
M1:
   ADD R1

Программа сложнее - но схема АЛУ аппаратно проще (см. рис. 5)

Кстати говоря, в контроллерах Интел типа ВЕ35, ВЕ48 не было операций вычитания как факЪт.
Там всё делалось программно: инверсия аргумента, инкремент его и сложение с первым аргументом.
Жутко неудобно, но аппаратно АЛУ ещё проще.

а вот дублировать флаги из битов аккумулятора - занятие бесполезное
уж лучше сделать переход по произвольному биту (типа как в пике)

Битов у нас всего 4.
Флаг знака S - даёт контроль самого старшего бита (MSB)
Флаг чётности результата P - даст контроль самого младшего бита (LSB) безо всяких аппаратных затрат.
То есть, мы имеем контроль 50% всех бит без схемотехнических затрат.
Мне такое решение не кажется бесполезным, а наоборот - весьма удачным.

Флаг P как чётность количества единичных битов вводить не буду.
Пользы и правда нет в маштабе 4 бит, а аппаратных затрат на NAND требует сравнительно больших.

О командах переходов я ничего говорить не буду, поскольку
АЛУ только выставляет флаги и ввести в него такие команды нет возможности.

Я пока предлагаю всё же оставить набор как есть. Он близок к привычному. И честно говоря, если вводить
экономию на корпуса, то легче выкинуть из набора команды INR RX, DCR RX - это резко сэкономит
4 мультилексора или 2 корпуса.

Но программно усложнит значительно, к примеру, INR R5:

Code: Select all

   MOV  R_temp,A; или PUSH
   MOV  A,R5
   ADD  1
   MOV  R5,A
   MOV  A,R_temp; или POP

[Lavr]

Кстати говоря, а каково ваше мнение о необходимости команд вот этой группы:



DAA - ясное дело, нам здесь в 4 битах никчему.

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

Если CMA мы выполняем как A XOR 0Fh, то понятно, что CMA вроде и не нужно.

Но можно реализовать:

STC - как C=1
CMC - как C=NOT C

И дополнительно ввести:

CLC - как C=0

С учетом того, что в данный момент реализовано 12 команд АЛУ, их в совокупности станет 15.

Останется код 0Fh, который удобно оставить как префикс для перехода к остальным операциям,
если процессор делать-таки 4 битным.

Но можно зацепить на код 0Fh какую-либо другую полезную операцию.
Я всё-таки склоняюсь к 12-битному коду операции и 4-битным данным.
Это удобно ложится в 16 байт выходов двух ОЗУ программ.

Аппаратно манипуляции с флагом C не сильно усложнят АЛУ, но вот есть ли в них необходимость?

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

[MC68k]

если есть сброс и установка, то инверсия не нужна

[jdigreze]

С учетом того, что в данный момент реализовано 12 команд АЛУ, их в совокупности станет 15.

Зачем их в АЛУ запихивать? Они ж вроде непосредственного отношения не имеют к нему.

[Lavr]

если есть сброс и установка, то инверсия не нужна

Очень безответственное заявление. Как правильно говорит Хардыч:"моцк то иногда фключай"!
Если есть установка и инверсия - то сброс не обязателен, как в i8080 было сделано.
Но в i8080 сброс C предлагалось делать как ORA A = CLC.
Сброс и установка не могут обеспечить инверсию, это очевидно.

Но я хочу сделать CLC как отдельную команду, поскольку предполагаю далее, что команды ORA A,
возможно, не будет, в плане упрощения схемотехники регистровых передач.
А будут только ORA RX, ORI N.

С учетом того, что в данный момент реализовано 12 команд АЛУ, их в совокупности станет 15.

Зачем их в АЛУ запихивать? Они ж вроде непосредственного отношения не имеют к нему.

Команды манипуляции с флагом переноса (STC, CLC, CMC) - команды относящиеся к работе АЛУ,
на мой взгляд: так как флаги формируются в АЛУ и "защелкиваются" из него в регистр флагов.
Если у тебя другая точка зрения - приведи схему или ссылку на известные решения.
Я таких вариантов ни в литературе ни в сети не встречал до сих пор.

А на популярность применения команд STC, CLC, CMC у тебя какая точка зрения?

[HardWareMan]

Я использовал STC/CMC для индикации ошибок в подпрограммах. Т.е., делаешь сначала CALL а следом JC/JNC в зависимости от значения флага С (обычно, С=1 было ошибкой). Очень удобно.

[MC68k]

Если есть установка и инверсия - то сброс не обязателен, как в i8080 было сделано.
Но в i8080 сброс C предлагалось делать как ORA A = CLC.
Сброс и установка не могут обеспечить инверсию, это очевидно.

эпично. теперь я понимаю, почему на постсоветском пространстве PIC не прижился.

[Lavr]

Если есть установка и инверсия - то сброс не обязателен, как в i8080 было сделано.
Но в i8080 сброс C предлагалось делать как ORA A = CLC.
Сброс и установка не могут обеспечить инверсию, это очевидно.

эпично. теперь я понимаю, почему на постсоветском пространстве PIC не прижился.

"Я Вам не скажу за всю Одессу..." Но я сам очень люблю как раз PIC.
И нравится он мне (конкретно PIC12 и PIC16) за минимализм системы команд
и минимализм размеров.
Так на взгляд - почти 155ЛА3 по размерам корпуса... А возможности просто великолепны!

К сожалению, как мне видится, PIC у меня, похоже, не получается...

[Lavr]

АЛУ исключительно на NAND

Я считаю, что настал момент завершить "спортивную" часть топика.
А именно - представить-таки почтенной публике АЛУ, выполненное исключительно на вентилях NAND.

Поскольку система команд, реализованная в прототипе АЛУ, представленном на рисунке 2, серьёзных замечаний не вызвала, эта схема и была реализована на вентилях NAND.

Поскольку схемотехнически вентили с открытым коллектором позволяют реализовать "проводное ИЛИ", я решил использовать в схемотехнике АЛУ вентили И-НЕ К155ЛА8 (7401) наряду с распространённымми микросхемами NAND К155ЛА3 (7400). Это позволило упростить схемы аналогов мультиплексоров. Вентили с открытым коллектором могут также позволить избежать применения тристабильных шинных формирователей.

Принципиальная электрическая схема АЛУ на NAND приведена на рисунке.


_______________ Рис. 6. _______________

Согласно приведённой принципиальной электрической схеме 4-битного АЛУ на вентилях NAND, назначение управляющих сигналов следующее.
Сигналы S0–S7 осуществляют выбор операции над двумя операндами, поступающими на входы операционного устройства АЛУ.
Сигналы C1-C4 коммутируют значение на входе линии флага переноса C0 операционного устройства АЛУ, и позволяют выбрать соответственно следующие значения: "0", C, "1", /C для выполнения определённых операций в АЛУ.
Сигналы K1-K3 позволяют подавать на входы первого операнда операционного устройства АЛУ полубайты собственно аргумента A, значения 0h и 0Fh соответственно.
Сигнал BN (B Negative) позволяет инвертировать значение второго операнда операционного устройства АЛУ во всех операциях вычитания.

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

Флаг Р реализован как признак чётности результата (бит 0).

В АЛУ реализуется следующая система команд, приведённая в таблице:



4-битное АЛУ содержит <U>44 14-выводных корпуса</U> ТТЛ микросхем, и оценить его размеры позволяет следующая картинка:



Я специально привожу её, чтобы можно было прикинуть размеры 8-битного АЛУ, если кто-либо захочет воплотить его сугубо на вентилях NAND.


PS. Ауууу!!! b2m!!?

Тагда давай уж и мультиплексоры с сумматором на NAND делай!

Ну вот тебе, b2m, "и мультиплексоры с сумматором на NAND" и "блэкджэк прибамбасами на NAND"...
Не слышу восторгов и апплодисьментов А как не по делу трындеть - так тут как тут...

[jdigreze]

А на популярность применения команд STC, CLC, CMC у тебя какая точка зрения?

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