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

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

Страницы: 1 2 3 4 5 6 7 Следующая »
clcПостоялецwww23 ноя. 201722:35#15
лёгкий доступ к гпсч\гсч - это круто

=A=L=X=
> действительно вопрос с плотностью команд спорный, было бы интересно оценить.

ты забыл x86? он давил этим

введение в роны регистров стека и счётчика - плохая идея, лучше выделять отдельные команды. Ты ж вроде работал с ассемблером...

122 - parallella, cell

122Постоялецwww23 ноя. 201723:00#16
clc
> parallella, cell
Неа, даже близко не попал. Ничего из этого не сопроцессор\карта для компа, не имеет сравнимых с видеокартой мощностей и объемов памяти. Ничего из этого нельзя юзать как помощник реалтайм вычислений процессора к примеру для обсчета реалтайм освещения в игре или физики в ней же.
desssПостоялецwww23 ноя. 201723:02#17
122
Intel xeon phi
122Постоялецwww23 ноя. 201723:18#18
desss
> Intel xeon phi
А вот это похоже то. Значит, уже придумали.
Но с ценой у них замах не на обычных юзеров а на всякие рендерфермы и прочие суперкомпьютеры. Так то по моей идее этот вычислительный блок должен покупаться как видюха, стоить как видюха и давать схожие мощности. А у них там 2к, 3к баксов.
desssПостоялецwww23 ноя. 201723:42#19
122
> Так то по моей идее этот вычислительный блок должен покупаться как видюха, стоить как видюха и давать схожие мощности.
У intel тоже идея такая была изначально:
https://ru.wikipedia.org/wiki/Larrabee
Но не взлетело. Куча x86 при той же себестоимости видимо не может конкурировать с видеокартам по производительности.
> А у них там 2к, 3к баксов.
Ну это по-божески, если очень надо, даже купить можно.
122Постоялецwww24 ноя. 20170:52#20
desss
> Куча x86 при той же себестоимости видимо не может конкурировать с видеокартам
> по производительности.
Так (по моей задумке) там и не должна быть куча x86-х, там должна быть куча узкоспециализированных счетных модулей типа тех что в GPU.
А интел да, сделали слишком дорогой вариант на тяжелых х86-х ядрах.
=A=L=X=Постоялецwww24 ноя. 20172:33#21
clc
> ты забыл x86? он давил этим

Ну 8086 это гимн CISC, с очень сложной и емкой системой команд. Тем не менее почти все команды с двумя регистрами были минимум двухбайтные с  байтом ModR/RM даже в MOV с аккумулятором. Не сомневаюсь, что у него плотность команд лучше, но у меня самые ходовые операции с аккумулятором могут быть однобайтными, плюс очень простая система команд с множеством неиспользованных комбинаций кодов.

=A=L=X=Постоялецwww24 ноя. 20174:59#22
Немного еще поанализировал получающуюся у меня систему команд и дополнил еще одним правилом префикс расширения опкода (13):
...
в) Если следующая команда - загрузка непосредственного данного (коды 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 можно считать настоящими двухбайтовыми командами. Но это даёт хорошую поддержку стека и копирования блоков, что не могу сопротивляться необходимости чуток поломать симметричность декодера. Зато становится видно, что нижний бит опкода почти всегда обозначает 8 или 16-битная команда имеет место быть, кроме как раз непрефиксированных команд 0 и 1.
Кроме того некоторые команды: сложения, вычитания и сдвигов могут при расширенном опкоде воспринимать XXXX не как номер регистра-источника, а как целочисленное immediate данное от 1 до 16.

Таким образом, если подбить всю систему команд в одну таблицу, то получается вот так:

+--------+----------------+-----------------------+
+  Опкод |   Инструкция   | При расш. опкоде      |
+--------+----------------+-----------------------+
|      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

Sbtrn. DevilПостоялецwww24 ноя. 201715:23#23
Когда я толкал тему на предмет "а слабО оценить вероятность самозарождения самовоспроизводящейся программы в компе?", я, в принципе, даже был готов сделать шаг и придумать атеистишкам орхетектуру для эксперимента. Предполагались следующие основные принципы:
1) чтоб можно было без особого труда эмулировать на современном компе,
2) в интересах максимально честного распределения шансов - чтобы все операции по возможности имели одинаковую длину, чтобы их функциональное распределение по пространству опкодов было максимально равномерно (т. е., чтобы в опкоде разбиение битов на смысловые группы было фиксированным для всех операций), чтобы операции были примерно функционально равноценны, чтобы не было привилегированных адресов (типа таблиц прерываний и т. п.), незначащих бит и, по возможности, вырожденных команд
(это трудно описать парой слов, но, например: значение такого-то бита 1 означает "что-то сделать", а 0 - "не делать ничего" - вот чтобы такого избегать, и что-то бы делалось в обоих ветках)

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

Адресное пространство - 64к 16-битных слов. Имеют место 3 (16-битных же) регистра: PC (адрес команды) и ещё один два, назовём их A и B (регистры общего назначения). Значение PC, A и B, а также ячеек памяти на момент старта, можно считать условно произвольным.
Все команды работают по унифицированной схеме:
- взять 2 операнда,
- произвести над ними операцию,
- поместить результат куда-нибудь,
- в зависимости от характеристик результата, перейти или к следующей команде (PC++), или к какому-то иному адресу (PC=?).
Структура команды такова:

2 бита = операнд 1:
- 00: регистр A,
- 01: регистр B,
- 10: регистр PC (указывает на следующую команду, без учёта возможного перехода в результате текущей),
- 11: непосредственный операнд команды.

1 бит = косвенность адресации операнда 1:
- 0: значение находится непосредственно в операнде 1,
- 1: значение находится в памяти по адресу, который находится в операнде 1.

2+1 бит = операнд 2, с тем же смыслом.
Заметим, что "непосредственный операнд команды", в случае его наличия, всегда только один, и тот же самый и для операнда 1, и для операнда 2. Т. е., если они оба на 11, то для 2-го операнда не выбирается дополнительный непосредственный операнд, а используется тот же, что для 1-го.

4 бит = операция:
0000: result = op1,
0001: result = op2,
0010: result = op1+op2,
0011: result = op1-op2,
0100: result = op1 xor op2,
0101: result = op1 or op2,
0110: result = op1 nor op2,
0111: result = op1 and op2.
Операции со старшим битом 1 - сдвиги. Значения остальных битов при этом приобретают следующий смысл: 1 бит = сдвиг влево (0) или вправо (1), 1 бит = ротация (0) или сдвиг с замещением битами из op2 (1), 1 бит = на 1 бит (0) или на 8 бит (1).

1 бит = целевой операнд для размещения результата:
- 0: в операнде 1,
- 1: в операнде 2,

2 бит = что именно делать с результатом и с прежним значением, хранившемся в операнде 1/2 (в зависимости от предыдущего бита):
- 00: затереть прежнее значение целевого операнда результатом,
- 01: поместить его прежнее значение в другой операнд,
- 10: затереть прежнее значение целевого операнда результатом, а другой операнд, в зависимости от того, было или не было переполнение старшего бита при операции (аналог флага C в 808x), выставить в 0 или 0xFFFF,
- 11: то же, что 10, но выставить в 0 или 0xFFFF целевой операнд, второй операнд не трогать, а результат выкинуть.

Результат операции может быть проверен на некоторые признаки, и при их соблюдении будет предпринят относительный переход (PC, возможно изменённый в результате команды, будет дополнительно инкрементирован).
2 бита = вид проверки:
- 00: без проверок и без условных переходов, продолжаем работать.
- 01: ноль,
- 10: не ноль,
- 11: относительный переход в любом случае.
Во всех случаях, кроме 00, в качестве добавляемого к PC значения используется непосредственный операнд команды (да, всё тот же один-единственный).

Небольшое пояснение на предмет непосредственного операнда. Как уже говорилось, он всегда только один, и размещается следом за опкодом команды. В зависимости от надобности в нём, PC при выборке команды или дополнительно инкрементируется (перед началом её выполнения), или же нет.
А надобность в непосредственном операнде определяется вовсе не так, как вы подумали. Она обозначается оставшимся битом команды: 1 = есть непосредственный операнд, 0 = его нет. Этот бит влияет только на инкремент PC, но не на логику выборки непоср. операнда. Если по команде он нужен, а по биту его нет, в его качестве выступает опкод следующей команды.
Это странное решение, но так надо.

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

Правка: 23 мая 2018 3:20

=A=L=X=Постоялецwww24 ноя. 201716:58#24
Sbtrn. Devil

Что-то по моему сложновато для поставленных целей. Одни биты говорят где находится операнд чтобы другие тут же говорили что их можно поменять местами.
То есть для полноценного проца, имхо, тут всего мало, а для random code generation - много.

Sbtrn. DevilПостоялецwww24 ноя. 201717:40#25
=A=L=X=
Замысел в том, чтобы команды были равномерно распределены по пространству опкодов, и чтобы команд, выполняющих аналогичные функции, для каждой функции их было примерно равное количество. И тем самым уравновесить вероятности, чтобы команды для этих функций попались в случайно нагенерированных коды команд.
Например, в классических архитектурах команд условного перехода - что-то около 3%, что снижает вероятность сгенерировать некое подобие цикла. В нашем случае их 50%. И т. п.
Вариант, который получился, наверняка не идеален, но всё ж таки попытка к нему приблизиться.
kiparУчастникwww24 ноя. 201720:41#26
Sbtrn. Devil
неудобно что относительной адресации нет. Которая [RX + RY] у Алекса.
И так с двумя регистрами единственный способ работать с переменными это привязывать их к текущему значению PC, а без адресации для этого еще и приходится лишние операции делать. Хотя конечно некритично.
Dmitry_MilkПостоялецwww24 ноя. 201721:23#27
Sbtrn. Devil
> "а слабО оценить вероятность самозарождения самовоспроизводящейся программы в
> компе?", я, в принципе, даже был готов сделать шаг и придумать атеистишкам
> орхетектуру для эксперимента. Предполагались следующие основные принципы:

Если вычислительную архитектуру рассматривать не в столь узком смысле (фон Неймановская или в чем-то родстевнные ей), то это было сделано еще в 70-х годах, на вычислительной архитектуре типа "клеточный автомат", реализующей правила перехода, которые нам известны под названием "Конвеевская Жизнь". В ней возникновение самореплицирующихся структур вполне наблюдаемо за весьма малое количество шагов, "глайдеры"("планеры") и " однопалубные космические корабли" (терминология игры Жизнь) САМОПРОИЗВОЛЬНО возникают и продолжают реплицироваться практически из любого "мусора" (их никто не программирует, их именно обнаружили практически в самых первых же запусках эволюций "мусора").

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

Во-первых, клеточные автоматы с немного более сложной функцией переходов вполне могут служить основой дял построения именно  произвольно сложных вычислительных структур всего лишь путем задания исходных конфигураций состояний элементов. Причем не надо путать это с ПЛИС/FPGA, ПЛИС/FPGA состоят из более высокоуровневых элементов, чем элементы клеточных автоматов, о которых я веду речь. (Я лет 12-13 назад интересовался подобными клеточными атоматами, и даже появилась мысль выложить в этой теме те наработки как экстравагантный вариант вычислительной архитектуры, но здесь топикстартер повел более прямолинейный вариант, с процессором и памятью).

А во-вторых, чуть более 10 лет назад были сконструированы Метапиксели(http://www.conwaylife.com/w/index.php?title=OTCA_metapixel), позволяющие на метауровне строить двухстейтовые клеточные автоматы с произвольной функцией переходов, несмотря на то, что на микроуровне лежит все тот же простейший конвеевский автомат (а блоки из метапикселей могут служить основой и для многостейтовых). Но тут да, этим пунктом возразить сложно, т.к. вероятность самопроизвольного возникновения именно такого метапикселя практически нулевая. Но с другой стороны не обязательно требовать именно конвеевскй автомат.

Ну и еще одна поправка: требовать именно "осмысленных вычислений" от самозародившейся программы или конфигурации - это избыточное требование. Существующая налюдаемая нами жизнь не несет никакого смысла. Единственный "смысл"(именно в кавычках) в ней у ДНК - реплицировать свою структуру как можно больше, пока позволяют ресурсы. А все наблюдаемые нами биологические виды и их разнообразие - это только очередной сложности "инструмент" на службе у ДНК для более эффективной репликации (менее сложные когда-то были просто клетки-бактерии, возможно были и "доклеточные" инструменты репликации, которых мы сейчас не наблюдаем в силу их низкой эффективности, это направление для исследований). И вот структуры типа "глайдеров" и "космических кораблей" вполне себе обладают этим смыслом "саморепликации". Теоретически можно оценить и вероятность самопроизвольного возникновения "глайдерных ружей" или "паровозов" (да, их вероятности будут исчисляться 2 в степени нескольких сотен, но это все же не столь большое число, чтоб не быть реализованым во Вселенной).

=A=L=X=Постоялецwww24 ноя. 201721:31#28
Dmitry_Milk
> и даже появилась мысль выложить в этой теме те наработки как экстравагантный
> вариант вычислительной архитектуры, но здесь топикстартер повел более
> прямолинейный вариант, с процессором и памятью
То что я выложил не отменяет написанного в первых трех сообщениях. У меня просто вокруг того что я выложил давно крутились мысли, но тема про любую экзотику тоже.
daveПостоялецwww25 ноя. 201714:48#29
Matrix CPU, mxmxn.
Страницы: 1 2 3 4 5 6 7 Следующая »

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

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