4-bit Processor

[Lavr]

4-bit Processor

Смотрел вот тут ещё одну 4-битную конструкцию... Может быть мы её
где-либо и упоминали: Viktor's Amazing 4-bit Processor
http://www.vttoth.com/vicproc.htm



Она не то чтобы шибко новая, но вызывает у меня вот какой вопрос:
А на что в принципе способы 4-битные процессоры? Каковы их возможности?

Я откуда-то, возможно из ВУЗа, помню такой постулат: 4-битные данные
позволяют описать 2^4=16 независимых символов, что позволяет соорудить
максимум - калькулятор.
8-битные данные - это уже 2^8=256 независимых символов, что даёт нам
уже компьютер...

Но вот этот автор - Viktor - он, по его признанию, чистый программёр, и
смотрю я, там сложные вещи он делает на своей 4-битной поделке, вплоть до
вычислений с плавающей точкой.

Да тут ещё Shaos и Mac Buster меня смущать начали. Первый - тем что Z80
по сути - четырёхразрядный процессор (viewtopic.php?t=9215)
второй - тем, что многие микропроцессоры - как раз 4-разрядные.
(viewtopic.php?t=9459)

Ну если всё действительно так, может быть есть типичный пример 4-битного
компьютера и 4-разрядный софт где-то должен заваляться в пыли?
Или я неправ и утрирую?

[Shaos]

Угу - твоими руками и упоминали:

viewtopic.php?t=9467

А процессор можно хоть однобитным сделать, но это не помешает ему складывать 32-битные данные и работать с плавающей точкой, только ооооочень медленно

[Lavr]

А процессор можно хоть однобитным сделать, но это не помешает ему складывать 32-битные данные и работать с плавающей точкой, только ооооочень медленно

Чем-то напоминает песню В.Цоя:"Все говорят, что мы в месте, все говорят,
но не многие знают в каком..."

И ты мне уже здась говорил об однобитном процессоре,
viewtopic.php?t=9213
но только в данный момент я интересуюсь конкретным вопросом с конкретной
целью.
Если есть развитое 4-битное ПО, может расточить под него свой проц?
Примеры конкретные есть?

[Shaos]

Придумать 4-битную архитектуру, чтобы с большой памятью работала - это нам раз плюнуть
Компилятор Си - запросто

вот какие варианты мне видятся на получение более адекватной 4-битной архитектуры:

вариант 1: иметь в шине адреса много больше битов, чем в шине данных - таким образом удастся адресовать больше памяти, но при этом придётся налегать на косвенную адресацию и/или иметь многониббльные команды

вариант 2: иметь отдельно память данных (4-битную) и память программ (чуть более чем 4-битную) - в этом случае команды могут быть в одно слово, а память теоретически можно организовать страничную

по поводу Си-подобного для 4-битной платформы:
- можно добавить нативный целочисленный тип nibble (unsigned nibble 0...15, signed nibble -8...+7)
- т.к. у нас появляется "лёгкое" BCD представление, то можно ввести тип digit (0...9)
- если у нас есть digit, то надо ввести и number - массив digit-ов со знаком
- для плавающей точки можно завести real - тип состоящий из мантиссы и экспоненты произвольной точности (два number)
- int видимо надо считать 16-битным, но иметь возможность собирать программы, предполагающие, что int - это 32-битное число (состоящее из 8 нибблов) - с другой стороны есть техническая возможность иметь динамически "настраиваемый" тип int (4,8,12,16,20,24,28,32 бита)

[VituZz]

вариант 1: иметь в шине адреса много больше битов, чем в шине данных - таким образом удастся адресовать больше памяти, но при этом придётся налегать на косвенную адресацию и/или иметь многониббльные команды

Вариант одинаково 4-битных шин адреса и данных представляется мне крайне неэффективным. Ну что такое 16 нибблов программы? А какие-то расширения памяти в пределах такой архитектуры будут выглядеть огромными костылями для комара. Мне кажется, шина адреса должна быть минимум 16 бит.

вариант 2: иметь отдельно память данных (4-битную) и память программ (чуть более чем 4-битную)

Предлагаю отдельные память программ, память данных, стек.

[b2m]

int видимо надо считать 16-битным, но иметь возможность собирать программы, предполагающие, что int - это 32-битное число (состоящее из 8 нибблов) - с другой стороны есть техническая возможность иметь динамически "настраиваемый" тип int (4,8,12,16,20,24,28,32 бита)

Как бы, размер int всегда был равен размеру указателя. Так что, если шина адреса, к примеру, 12-битная, то и размер int должен быть тоже 12-битный Но, в принципе, это всё условности. И никто не запрещает иметь аналогично "настраиваемый" размер указателя.

[Shaos]

int видимо надо считать 16-битным, но иметь возможность собирать программы, предполагающие, что int - это 32-битное число (состоящее из 8 нибблов) - с другой стороны есть техническая возможность иметь динамически "настраиваемый" тип int (4,8,12,16,20,24,28,32 бита)

Как бы, размер int всегда был равен размеру указателя. Так что, если шина адреса, к примеру, 12-битная, то и размер int должен быть тоже 12-битный Но, в принципе, это всё условности. И никто не запрещает иметь аналогично "настраиваемый" размер указателя.

неа - по стандарту размер int - это вроде как размер нативного слова

[Lavr]

Мужики - вы извините, что я вас всех не цитирую, но главные вопросы,
как мне кажется, для начала не эти. А вот какие:

1. Архитектура гарвардская или принстонская или смешанная (гарвардская,
но можно дать возможность, хотя бы окольную, писать в память программ...
Но это приводит к неким сложностям, т.к. там КОПы и данные.

2. Вопрос очень связан с первым: это будет контроллер типа PIC, или же
это компьютер общего назначения. В первом случае - мы всё пишем и компилируем
на АйБиЭм ПиСи и только заливаем скомпилированный код. Во втором, а я хочу
второй случай, у нас есть ЛСД и клавиатура и ОС или Монитор и всё пишем
и делаем в 4-битном ассемблере на самом 4-битном устройстве, тогда Гарвард
не очень подходит - нужно ОЗУ для массивов данных. Вот такие программы я
и пытаюсь найти и посмотреть как образец.

3. Это схемотехника. Она очень мечтать отучит. Для этого я и просмотрел
множество схем 4-битных самоделок. И я вам скажу, я не увидел логики в
составлении их авторами системы команд, а это очень связано с железом.

Я предполагаю выложить здесь характерные наборы команд и обсудить их,
т.к. это во многом определит сложность железки.

Скажу своё предпочтение - команд должно быть не более 32-35 как в PIC,
в этом случае железка ещё получится не слишком громоздкой.
Вот такую монструозность я конструировать не хочу, да и не буду.



Собственно почему 4 бита меня как-то захватили - так это возможность сделать
аппаратную часть более скромной.

[VituZz]

Моё мнение:

1. Смешанная архитектура. Память программ, память данных и стек с R/W доступом. Это не обязательно сильно осложнит схему, на первоначальном этапе можно просто иметь в виду такую возможность, чтобы в последствии можно было безболезненно её реализовать. Первоначальная система команд может поддерживать только один вид памяти.

2. Общего назначения. Другое менее интересно.

3. По системе команд за образец можно взять по приведенной в первом посте ссылке: http://www.vttoth.com/vicproc_seq.htm, только, я думаю, его нужно несколько видоизменить.

[Lavr]

3. По системе команд за образец можно взять по приведенной в первом посте ссылке: http://www.vttoth.com/vicproc_seq.htm, только, я думаю, его нужно несколько видоизменить.

Вот я и хотел бы варианты обсудить...
К примеру - зачем ему HLT если прерываний нет, я бы лучше ввёл NOP...
и т.д.
я уж спрашивал один раз тут про PUSH и POP - все промолчали...
Опять же - стек как лучше организовать - есть что обсудить.

А в принципе - сильно и обсуждать нечего. Можно брать Протезус - сбирать
в нём эти несложные процессоры (если взять не самый сложный) и "поощущать"
систему команд - сразу появляется опыт - чего в системе не хватает...
Мне не хватало PUSH и POP...

[Shaos]

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

Я посмотрел систему команд японской поделки - разумно: 15 4-битных команд плюс ещё 16 возможных после "префикса" E - всего выходит 29. Если завести второй префикс, то команд уже будет 14+16+16=46. Можно память данных и программ сделать 8-битной - команды оттуда будут поступать по 2 (или по одной, но с префиксом). Адрес видимо лучше считать 16-битным (или 12-битным - для круглого счёта?) и стек иметь в общей памяти. И кстати без прерываний скушно - пусть будут прерывания

P.S. Почему 12-битный адрес логичнее? Потому что можно сделать 4-битные команды JMP и CALL за которыми идёт 12 бит адреса - как раз умещается в 2 байта. Команда NOP тоже должна быть, чтобы выравнивать длинные команды на границу байта...

[VituZz]

Ещё слегка поразмышлял над этой конструкцией. Возможно, имеет смысл проявить минимализм, ибо всяких усложнений типа префиксов команд гораздо проще избежать, просто перейдя к 8-ми битам. Одно адресное пространство для RAM, ROM и ввода-вывода. К примеру, 2Кх8 ROM, 2Кх8 RAM, половины ШД которых включить через мультиплексор и получить по 4Кх4.

По системе команд (если ограничиться 16-ю командами):
0 - MOV A, M - скопировать аккумулятор в память
1 - MOV M, A - скопировать в аккумулятор из памяти
2 - ADD A, M - сложить аккумулятор с памятью
3 - SUB A, M - вычесть из аккумулятора память
5 - OR A, M - A=A И M
4 - AND A, M - A=A ИЛИ M
6 - JNZ M - перейти, если не равно 0
7 - JNC M - перейти, если нет переноса
8 - JMP M - перейти
9 - RLC - сдвинуть влево по кольцу, C в кольце
A - RAL - сдвинуть влево по кольцу, C не в кольце
B - CALL M - вызвать ПП
C - RET - вернуться
D - PUSH A - A в стек
E - POP A - из стека в A
F - NOP - Нет операции
M здесь может быть как абсолютный адрес, так и относительный; второе мне кажется предпочтительней.

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

ПС. Что-то мне ещё вспомнились Форт-машины, у которых все операнды находятся в стеке. Надо подумать эту мысль...

[Lavr]

Ещё слегка поразмышлял над этой конструкцией. Возможно, имеет смысл проявить минимализм, ибо всяких усложнений типа префиксов команд гораздо проще избежать, просто перейдя к 8-ми битам. Одно адресное пространство для RAM, ROM и ввода-вывода. К примеру, 2Кх8 ROM, 2Кх8 RAM, половины ШД которых включить через мультиплексор и получить по 4Кх4.

По системе команд (если ограничиться 16-ю командами):
0 - MOV A, M - скопировать аккумулятор в память
1 - MOV M, A - скопировать в аккумулятор из памяти
2 - ADD A, M - сложить аккумулятор с памятью
3 - SUB A, M - вычесть из аккумулятора память
5 - OR A, M - A=A И M
4 - AND A, M - A=A ИЛИ M
6 - JNZ M - перейти, если не равно 0
7 - JNC M - перейти, если нет переноса
8 - JMP M - перейти
9 - RLC - сдвинуть влево по кольцу, C в кольце
A - RAL - сдвинуть влево по кольцу, C не в кольце
B - CALL M - вызвать ПП
C - RET - вернуться
D - PUSH A - A в стек
E - POP A - из стека в A
F - NOP - Нет операции
M здесь может быть как абсолютный адрес, так и относительный; второе мне кажется предпочтительней.

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

ПС. Что-то мне ещё вспомнились Форт-машины, у которых все операнды находятся в стеке. Надо подумать эту мысль...

С Форт-машиной я почему-то по жизни не лажу... Возможно, память о калькуляторах типа МК-61.
Но всё время возвращаюсь к ней - пробую... нет не то... склад характера, может, не под неё...

Обсуждать УЖЕ есть чего. Ну априори я уже заложил в АЛУ :
ADC A, M
SUB A, M
NOT A (CMA)
XOR
RRC
RAL
причём сдвиги нам достаются совершенно "бесплатно".

Пробуя эти 4-битки в эмуляторе остро чувствовал необходимость в
CPI или CMP (если хочешь - TEST)
Префикс, на мой взгляд, не усложняет конструкцию, а вот PUSH, POP - зело.

[Lavr]

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

Мне лично - тоже... Но Гарвардская здорово упрощает конструцию и если
оставить Гарвардскую но с возможностью записи в "память программ" можно
и самомодифицирующиеся программы реализовать (а я их люблю ) и использовать
"память программ" под массивы - скажем буфер редактора - в ней.

3. Каждый изгаляется как может

Полностью согласен. Но предпочитаю эту истину в весёлом виде:
"Каждый "точит" как он хочет".

Я посмотрел систему команд японской поделки - разумно: 15 4-битных команд плюс ещё 16 возможных после "префикса" E - всего выходит 29. Если завести второй префикс, то команд уже будет 14+16+16=46.

Мне тоже японский трюк с префиксом понравился - не придётся ужиматься
в 16 команд. Причём под префикс они разумно вынесли все вызовы и переходы.

Можно память данных и программ сделать 8-битной - команды оттуда будут поступать по 2 (или по одной, но с префиксом). Адрес видимо лучше считать 16-битным (или 12-битным - для круглого счёта?) и стек иметь в общей памяти. И кстати без прерываний скушно - пусть будут прерывания

Адрес лучше 16-битный я прикидывал - это аппаратно удобнее.
Но и 12 не хуже - 8 бит смещение, 4 бит - банки по 256 байт.

Стек в общей памяти ОООЧЕНЬ неприятно семотехнически, если по пути я
не увижу более красивого решения в прототипах.

А потом - вроде ж я предлагал сделать минимальный, но удобный и шустрый
ЦПУ - а пусть он потом интерпретирует i8080 - там тебе все прелести CISC
будут доступны.

Я это попробовал на PIC и пришел к выводу, что ЗДОРОВО!!! Причем не
обязательно чтобы так уж всегда был интерпретатор. Написать макросы
ассемблера, выражающие основные команды i8080, а затем программить
вызовами макросов - это ОООЧЕНЬ здорово, на мой взгляд, убыстряет!
На досуге планирую написать себе такие макросы.
Ёмкость информационой единицы i8080 местами зело больше, чем у PIC.
Кстати, при этом сильно ощущаешь отличия RISC и CISC. RISC - да он
шибче, но мыслить приятнее в единицах CISC.


Вот с прерываниями - я в раздумьях... "Специалист" обходился без них,
но плохой машиной не был. С другой стороны - неплохо хотя бы прерывание
таймера с вектором типа RST N. Но хитроглазые япошки тоже обошлись без
прерываний. Аппаратно сделать прерывания - проще стека в ОЗУ.

[VituZz]

Что значит

сдвиги нам достаются совершенно "бесплатно".

? Раз есть такие команды, значит, они чем-то реализовываются?

Есть уже какие-то схемотехнические наброски?