Флейм
GameDev.ru / Флейм / Форум / Меряемся придуманными машинными архитектурами

Меряемся придуманными машинными архитектурами

Страницы: 1 2 3 4 5 6 7 Следующая »
=A=L=X=Постоялецwww23 ноя. 201710:43#0
Собственно сабж.
Придумываем собственные архитектуры процессоров с некими блекджеками и плюшками - и предлагаем их тут на так сказать растерзание толпы.
Можно и какие то общие идейки - но более всего приветствуется грамотный и продуманный концепт, вплоть до законченной системы команд расписанной побайтно.
Естественно тему создаю потому что у самого нечто эдакое крутится в голове, но попытки конкретизировать пока всё время обламываются об недостаток бит в байте. Смысл был в том что 8 бит, при этом RISC и преимущественно 1 байт на команду. Ну да ладно, подумаю еще.
А вот темку на всякий создам заранее.

Правка: 23 ноя. 2017 10:44

0iStalkerМодераторwww23 ноя. 201710:51#1
Все они вариации об одном и том же, о реализации одной и той же вычислительной архитектуры. Чтобы получить что-то экзотическое в плане систем команд, нужно сначала что-нибудь не фон-Неймановское в вычислениях придумать.
=A=L=X=Постоялецwww23 ноя. 201711:06#2
0iStalker
> что-нибудь не фон-Неймановское в вычислениях придумать

Так я ж не против. Поправил название темы, чтобы "вообще архитектур".

Правка: 23 ноя. 2017 11:08

The PlayerУчастникwww23 ноя. 201714:24#3
Го в архитектуры с не 8-битным байтом.
=A=L=X=Постоялецwww23 ноя. 201714:33#4
Итак, чисто в порядке развлекухи родилась у меня архитектура 8/16-битного проца с объединенными чертами CISC+RISC и попыткой уместить систему команд в однобайтовом седле.
Чтобы обеспечить последнее пришлось активно пользоваться префиксным подходом, но об этом позже.
Итак, в составе процессора 16 16-битных регистров общего назначения R0-R15 + регистр флагов. Регистр R14 - Link Register (LR). Регистр R15 по совместительству - счетчик команд. Перед исполнением текущей команды он указывает уже на следующую команду в памяти и его изменение текущей командой приведет к переходу на новый адрес. R0 выступает в роли аккумулятора с псевдонимом ACC.
Команды все имеют 8-битный формат следующего формата в битовом представлении:
CCCC:XXXX
где CCCC - код команды и XXXX - её аргумент.
таким образом возможно всего 16 команд, при этом в большей части команд аргумент XXXX это номер регистра.

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

0. ACC = RX
1. RX = ACC
копирование данных между регистрами, где ACC - аккумулятор, а RX - один из 16 регистров общего назначения (включая аккумулятор). копируются между регистрами всегда полные слова.
в лучших традициях RISC загрузка в регистра R15 и является операцией перехода - в данном случае получается что indirect.

2. RX = data8
3. RX = data16
загрузка регистра непосредственными данными, располагаемыми сразу после команды. технически эквивалентно RX=[R15++] с выбором на байт или на два происходит инкремент.
По умолчанию ассемблер сам подбирает нужный код инструкции, но можно форсировать их выбор суффиксами B или W у регистра: R5B=0 - однобайтное данное или R7W=12 для двухбайтного данного.
При загрузке одного байта он загружается в нижнюю половину регистра, верхняя при этом дополняется его верхним битом (расширение со знаком).
загрузка R15 осуществит прямой переход по заданному адресу.

4. ACCB = [RX]
5. ACC = [RX]
6. [RX] = ACCB
7. [RX] = ACC

Загрузка и сохранение данных в память. Байты и слова приходится разводить на разные опкоды.
При загрузке одного байта он загружается в нижнюю половину регистра, верхняя при этом дополняется его верхним битом (расширение со знаком).
Здесь замечу, что если префикс битности регистра B/W не пишется, то выбирается 16-битный размер операндов.

8. ACCB += RXB
9. ACC += RX
10. ACCB -= RXB
11. ACC -= RX
Сложение и вычитание, тоже опкоды разведены по битности операндов - для 8-битных команд

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

12. Префикс выбора аккумулятора
Битовое поле XXXX трактуется как номер регистра, который выступит в роли аккумулятора для следующей команды.
Таким образом для перегонки данных из регистра в регистр на самом деле не обязательно "марать" аккумулятор в двухбайтной цепочке команд, можно обойтись одной двухбайтовой (из-за префикса) командой копирующей всё сразу в нужное место.

13. Префикс расширения опкода
а) Если следующая команда - арифметическая (с кодом от 8 до 11), то битовое поле XXXX опкода становится полем выбора арифметико-логической команды, которым могут предварятся команды 8-11. При этом при встрече сложения 16 вариантов XXXX трактуются одним образом, а при встрече вычитания - другим.
Таким образом у нас образуется до 32 дополнительных арифметико-логических команды вида ACC op = RX или ACC op = RX. Все их подробно я расписывать не буду - они очевидны, арифметика, биты, прокрутки.
Таким образом весь спектр арифметико-логических команд требует как правило 2 байт на команду.
Замечу так же, что однооперандных инструкций нет - например битовое NOT работает здесь как, например, ACC ~= R7, то есть в ACC пишется инверсия регистра R7.
Присутствуют такие команды как ACC=RX+C и ACC=RX-C, где C = 1 или 2.
б) Если следующая команда - косвенного доступа к памяти (с кодом от 4 до 7), то битовое поле XXXX опкода становится номером регистра который надо сложить с RX чтобы получить адрес по которому происходит сохранение/загрузка, то есть операции превращаются в:
+4. ACCB = [RX+RY]
+5. [RX+RY] = ACCB
+6. ACC = [RX+RY]
+7. [RX+RY] = ACC
в) Если следующая команда - загрузка непосредственного данного (коды 2-3), то битовое поле XXXX опкода становится выбором регистра, который фигурирает как база адреса и автоинкремента.
Как говорилось в описании команд они эквивалентны RX=[R15++], то с этим префиксом они превращаются в:
+2. RXB=[RY++]
+3. RX=[RY++]
чтобы добавить им симметрии команды 0 и 1, выполняющие пересылку между регистрами, после этого префикса модифицируются до команд выгрузки в память с пред-декрементом:
+0. [--RY]=RXB
+1. [--RY]=RX
Таким образом эти 2 команды после префиксирования опкодом 13 не просто некоторым образом дополняют своё поведение, но сильно его меняют - поэтому две цепочки инструкций: 13:x 0:y и 13:x 1:y можно считать настоящими двухбайтовыми командами.

Кроме того некоторые команды: сложения, вычитания и сдвигов могут при расширенном опкоде воспринимать XXXX не как номер регистра-источника, а как целочисленное immediate данное от 1 до 16.

14. IF - Условие
Битовое поле XXXX трактуется как код условия по регистру флагов для следующей команды - по умолчанию после выполнения каждой непрефиксной команды оно взводится в "выполнять всегда", но этот префикс позволяет его менять. Так можно реализовать как условные переходы так и conditional move и т.п.

15. $ - Расширение
Битовое поле XXXX трактуется как особый модификатор команды, возможно полностью перепрограммирующий опкод - это задел на будущее и всякие входы/выходы из прерываний.
Сейчас определено только одно его осмысленное значение - если оно равно 0000, то в следующей за префиксом команде значение регистра в который происходит запись будет запомнено в начале команды, а в конце команды записано в LR - Link Register. Это позволяет реализовать CALL в стиле типичном для RISC-процессоров.
Например CALL по фиксированному адресу в памяти будет представлен 4 байтами в памяти:
$R15=ADDR // опкод 15:0, 3:15, A, B, где AB - адрес по которому переходить.
А вот CALL с передачей управления по смещению (относительный переход) выражается так:
R14 = OFFSET // опкод 3:14, A, B
$R15 += R14 // опкод 14:0 12:15 10:14
То есть грузим в LR смещение (3 байта), делаем R15 временным аккумулятором, запоминаем его старое значение и складываем его со смещением, LR (еще 3 байта).

Краткая таблица опкодов:

+--------+----------------+-----------------------+
+  Опкод |   Инструкция   | При расш. опкоде      |
+--------+----------------+-----------------------+
|      0 | ACC  = RX      | [--RY]    = RXB       |
|      1 | RX   = ACC     | [--RY]    = RX        |
|      2 | RXB  = data8   | RXB       = [RY++]    |
|      3 | RX   = data16  | RX        = [RY++]    |
|      4 | ACCB = [RX]    | ACCB      = [RX + RY] | 
|      5 | ACC  = [RX]    | ACC       = [RX + RY] |
|      6 | [RX] = ACCB    | [RX + RY] = ACCB      |
|      7 | [RX] = ACC     | [RX + RY] = ACC       |
|      8 | ACCB += RXB    | ACCB     @= RXB       |
|      9 | ACC  += RX     | ACC      @= RX        |
|      A | ACCB -= RXB    | ACCB     @= RXB       |
|      B | ACC  -= RX     | ACC      @= RX        |
+--------+----------------+-----------------------+
|      C | смена аккум.   |                       |
|      D | расш. опкод    |                       |
|      E | условие        |                       |
|      F | доп.           |                       |
+--------+----------------+-----------------------+

@ может быть:
При расширении команды сложения:
0. += сложение (операция по умолчанию)
1. += data4 сложение с константой - поле аргумента XXXX исходной 
команды воспринимается не как номер регистра, а как число от 1 до 16
2. +c= сложение с переносом
3. *=  умножение (байты расширяются до слов)
4. *=s  умножение со знаком
5. &=  битовое AND
6. |=  битовое OR
7. ^=  битовое XOR
8. = ~ (битовое NOT в виде ACC = ~RX)
9. ?= сравнение (вычитание без изменения регистров, только флагов)
A. = - изменение знака числа (ACC = -RX)
B. u= копировать байт без знака (ACC u= RXB, верхняя половина ACC=0)

При расширении команды вычитания:
0. -= вычитание (операция по умолчанию)
1. -= data4 вычитание константы - поле аргумента XXXX исходной 
команды воспринимается не как номер регистра, а как число от 1 до 16
2. -c= вычитание с переносом
3. /=  деление
4. /=s  деление со знаком
5. <<= сдвиг влево
6. >>= сдвиг вправо
7. >>>= сдвиг вправо арифметический
8. <<= data4 сдвиг влево на константу бит
9. >>= data4 сдвиг вправо на константу бит
A. >>>= data4 сдвиг вправо на константу бит арифметический
B. s= копировать байт расширяя знак (ACC s= RXB)

Правка: 24 ноя. 2017 5:43

Dmitry_MilkПостоялецwww23 ноя. 201715:53#5
А зачем это? С какой целью? смоделировать "игрушечный" проц в каком-нибудь симуляторе? или ради какой-либо эффективности? Если эффективность - то в ядрах современных процов эффективность достигается за счет суперскалярности и неупорядоченного выполнения (и выбор RISC-ориентированной кодировки тут почти как мертвому припарка, разве что попроще с очередью микроопераций), либо за счет VLIW (тогда управление суперскалярностью ложится на плечи компилятора).

Правка: 23 ноя. 2017 15:54

=A=L=X=Постоялецwww23 ноя. 201716:14#6
Dmitry_Milk

> А зачем это? С какой целью?

В посте #4 в самом начале предложения.
Вообще конечно сейчас можно микроконтроллер с 64Кб ОЗУ реализовать полностью на статической памяти в самом же кристалле и потому наплевать на кеши-меши и прочие конвееры, скорости микрику хватит за глаза.
Соревновательный элемент на самом деле чисто ради фана.

Я вот смотрю и мне не нравится во что выливается доступ к переменным на стеке.
Надо расширить чтобы префикс 13 действовал иначе перед командами косвенной загрузки регистров - это команды от 4 по 7, чтобы XXXX тогда значило регистр содержимое которого складывается с указанным в команде RX и уже полученный адрес использовался при доступе к памяти. Тогда чтобы достать переменную из стека нужно будет затратить в лучшем случае:

// вершина стека хранится по ABI в R13
// нужно загрузить в регистр R7 слово находящееся по адресу R13+80
R7=80 // опкод (2:7, 80)
R7=[R13+R7] // опкод (13:7, 12:7, 6:13)
итого - 5 байт когда смещение умещается в 1 байт и 6 байт для любых смещений. ну в принципе жить можно, у Z80 с его адресацией индексных регистров 2-байтная загрузка занимала 6 байт. зато вот 1-байтная - уже только 3. так что что еще поэффективнее с точки зрения битоедства еще большой вопрос...

Правка: 23 ноя. 2017 16:21

Dmitry_MilkПостоялецwww23 ноя. 201716:51#7
=A=L=X=
> В посте #4 в самом начале предложения.

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

А так, описанное сильно смахивает на систему команд PDP-11. Там правда команды не 8, а 16 битные, и регистров только 8, но зато "ортогональность" системы команд была удивительная, типа как у тебя написано, когда всякие immediate load получаются как частный случай регистра-указателя команд в режиме автоинкрементной адресации.

=A=L=X=Постоялецwww23 ноя. 201717:00#8
Dmitry_Milk
> Потому что непонятно, в чем тут может быть "соревновательный элемент".

Ну если совсем чётко выражать это, то "чтоб душа пела".

ZegalurУчастникwww23 ноя. 201717:09#9
=A=L=X=
> Меряемся придуманными машинными архитектурами
процессор, где в одном спец рид-онли регистре всегда сидит случайное число (равномерно распределенное)
каждый раз когда считываешь оттуда значение - получаешь труЪ рандомное значение
Dmitry_MilkПостоялецwww23 ноя. 201717:15#10
Тогда подумай над вариантом на основе PDP-11. Несмотря на 16-битную команду, он может оказаться "компактнее" твоего за счет двухоперандности. Количество регистров можно увеличить до 16, сократив количество вариантов адресации с 8 до 4 (непосредственное значение, косвенная адресацяи, косвенная с постинкрементом, косвенная с предекрементом). Тогда на операнд будет уходить также 6 бит, итого 2 операнда и 4 бита на операцию в 16-битной команде. R15 - указатель команд, и за счет него же в режиме постинкрементной адресации - получение immediate значений.
=A=L=X=Постоялецwww23 ноя. 201717:16#11
Zegalur
> процессор, где в одном спец рид-онли регистре всегда сидит случайное число
> (равномерно распределенное)
> каждый раз когда считываешь оттуда значение - получаешь труЪ рандомное значение

А вот по моему в современных компах аналогичное уже ввели, то есть там в SSE или AVX, для всякой "даз риал" криптографии такое есть.

=A=L=X=Постоялецwww23 ноя. 201717:25#12
Dmitry_Milk

16-битные команды это уже весьма другой коленкор, это да. Я действительно хотел остаться в рамках 1-байт = 1-задача для фетчера инструкций, чтобы компьютер оставался 8-битным по шине данных, типа совсем уж дешевенький микропроцессор.
Если присмотреться, то префиксы - это на самом деле просто особый формат команд, который взводит в процессоре ряд специальных регистров, которые зануляются или приводятся к другим значениям-по-умолчанию после выполнения обычных команд.
То есть их на самом деле можно вполне рассматривать как 1-байтные команды, если менять точку зрения на то, что происходит с точки зрения фетчера.
Та же команда 13 - расширение опкода, на самом деле может быть реализована как загрузка аргумента X параллельно в 2 места:
а) регистр RX копируется в слагаемое для адреса, незримо всегда участвующее во всех косвенных адресациях (команды 4-7), но выставляемое в 0 по дефолту
б) селектор арифметической команды меняется со слота Plus/Minus на слот с номером X
Таким образом следующая "непрефиксная" команда просто может воспользоваться этими предустановками (или нет) и сбрасывает их в дефолты после выполнения.

В общем да, система строго однобайтная, но с перфиксными расширениями-модификаторами, так что с логической точки зрения многие команды становятся многобайтовыми.

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

Правка: 23 ноя. 2017 17:27

ZegalurУчастникwww23 ноя. 201717:27#13
=A=L=X=
угу. таки ввели
круто, однако
122Постоялецwww23 ноя. 201720:47#14
=A=L=X=
> на так сказать растерзание толпы.
> Можно и какие то общие идейки
Общая идейка: счетный со-процессор для CPU архитектурно близкий шейдерным сегодняшним блокам GPU.

Цели:
- Строгая стандартизация, этим исключаем случаи когда общие вычисления на GPU сегодня работают как придется и сильно зависят от производителя видяхи и драйверов.
- Лучшая приспособленность для общих вычислений. Ведь общие вычисления на GPU всё-таки приходится проводить на железе которое заточено на вычисления узкоспециальные и связанные с графикой.
- Так как развитие ядер самих CPU очевидно и давно замедляется, такое решение потенциально выглядит путем заметно поднять вычислительную мощность.

Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Флейм / Железо

2001—2018 © GameDev.ru — Разработка игр