Оптимизация архитектуры

Added by krufter_multiclet about 4 years ago

Предложения по оптимизации мультиклеточной архитектуры для следующих ревизий процессоров можно размещать в данной теме.
Текущий список запланированных оптимизаций:
Общее:
1) GPIO с несколькими альтернативными функциями
2) Блок семафоров аппаратный
3) Присваивание процессору индивидуального номера прямо в кристалле
4) Доработка системы сброса (некоторая избирательность по системным настройкам, дебагеру)
5) Отдельное тактирование разных веток периферийной шины
6) Домены по питанию
7) Вывод тактовой частоты процессора с делителем
8) Одно напряжение питания
9) Аппаратный делитель
10) Обмен результатами между параграфами без памяти
11) Возможность использовать в качестве первого аргумента команды регистры, косвенную адресацию
12) Отправка результата команды сразу в регистр
13) Развязка записи в РОН от complete
14) Рассмотреть вопрос зависимости не только по данным, но и по факту выполнения команд
15) Доступ к флагам, например @1.z - получение Zero flag

Периферия:
1)Ethernet 10/100 MAC+PHY (2 канала)
2)Доработка RTC, ШИМ
3)Аппаратный блок CRC (Blake2, ГОСТ Р 34.11-2012)
4)USB PHY (Device + Host) 2.0, 480 Мбит/с
5)Температурный датчик
6)Загрузчик по UART + защищенные режимы
7)Шифрование по ГОСТ89 или ГОСТ-2015
8)Доработать SPI для повышения частоты работы процессора


Replies (134)

RE: Оптимизация архитектуры - Added by micron_multiclet almost 2 years ago

Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность. При сравнении эти расходы никак не учитывались, хотя для эффективности конвейерной организации процесса преобразования, очень важна непрерывность его загрузки. Подобные алгоритмы единичны.
2. В этой последовательности преимущественно должны быть операции умножения, деления и т.п. (а не сложения и вычитания). В реальности же, доля сложений и вычитаний составляет более 50% от общего количества операций.
3. В современных процессорах и сложение и умножение, в потоке, выполняется за один такт. Заменяя в модулярно-логарифмическом сопроцессоре умножение сложением, мы вряд ли сократим длительность такта, так как она зависит не только от АЛУ, но и от технологии, схемотехники и общей организации вычислительного процесса.

RE: Оптимизация архитектуры - Added by VaalKIA almost 2 years ago

micron_multiclet wrote:

Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность.

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

P.S. Вернее даже не сомнительное, а заблудительное. Сказано так, что не может перемежаться другими коммандами, которых полно в любой программе. А на деле, я пояснил точку зрения.

RE: Оптимизация архитектуры - Added by micron_multiclet almost 2 years ago

И физические модели и генерация реалистичного изображения в играх связаны с "длинными непрерывными последовательностями арифметических операций". А вот задачи управления, как правило другие. Сняли с датчика значение (в нормальном виде) сделали несколько операций с ним и выдали результат на какое-либо исполнительное устройство (также в нормальном виде). Здесь нет длинных последовательностей, а есть большой объем вычислений состоящий из массы коротких цепочек.
P.S. Речь идет о характерных чертах "арифметики", а не о том, какие еще команды есть в программе. Это "не от той стенки гвоздь"!

RE: Оптимизация архитектуры - Added by Yaisis almost 2 years ago

micron_multiclet wrote:

Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность. При сравнении эти расходы никак не учитывались, хотя для эффективности конвейерной организации процесса преобразования, очень важна непрерывность его загрузки. Подобные алгоритмы единичны.
2. В этой последовательности преимущественно должны быть операции умножения, деления и т.п. (а не сложения и вычитания). В реальности же, доля сложений и вычитаний составляет более 50% от общего количества операций.
3. В современных процессорах и сложение и умножение, в потоке, выполняется за один такт. Заменяя в модулярно-логарифмическом сопроцессоре умножение сложением, мы вряд ли сократим длительность такта, так как она зависит не только от АЛУ, но и от технологии, схемотехники и общей организации вычислительного процесса.

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

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

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

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

RE: Оптимизация архитектуры - Added by VaalKIA almost 2 years ago

Yaisis wrote:

Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?

Я бы расширил целые числа до дробей, это принципиально расширяет поле деятельности до рациональных чисел, вместо ЛСС и FP, если уж вопрос так стоит.

RE: Оптимизация архитектуры - Added by Yaisis almost 2 years ago

VaalKIA wrote:

Yaisis wrote:

Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?

Я бы расширил целые числа до дробей, это принципиально расширяет поле деятельности до рациональных чисел, вместо ЛСС и FP, если уж вопрос так стоит.

Я так понял, ЛСС -- это и есть дробное число.
Оно внутри состоит из целой части и дробной, плюс бит знака числа.

RE: Оптимизация архитектуры - Added by VaalKIA almost 2 years ago

Yaisis wrote:

VaalKIA wrote:

Yaisis wrote:

Я так понял, ЛСС -- это и есть дробное число.

Расшифровывается как Логарифмическая Система Счисления (это термин авторов ЛСС сопроцессора), честно гвооря, не вдавался в подробности, плавающая там точка (FP - Floating Point) или фиксированная(что программисты как раз и ассоциируют с дробным числом). И вы не путаете дроби и дробные числа?
Под дробными числами, понимают, обычно, числа, где есть знаки после запятой, не важно в какой системе исчисления.
Под дробями понимают два целых числа: числитель и знаменатель.
В какой бы системе вы не взяли дробное число, это будет дробь с зафиксированным знаменателем, что сильно скажется на точности и не позволит точно записывать многие значения. Например
1/3 = 0.3333(3) = 0.0101(01)
1/5 = 0.2 = 0.001100110011(0011)

Ну и эффекты для дробных/FP чисел, (1/3)*3=0.9; 0.2 = 0.1999969482421875, даже без всяких операций, на заметку тем, кто делает калькуляторы и работает с финансами, где надо применять двоично-десятичное кодирование (есть в z80), то есть рабтать с десятичными числами в битовом представлении (четыре бита на знак), иначе результаты будут расходиться с тем, что может посчитать человек на бумажке.

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

При этом понятно, почему дроби не использовали раньше: диапазон был маловат и память дорога, либо скорость маленькая (то есть они проигрывали или FP или FixP), но сейчас если 64+64бита дробь сделать, то получим много бонусов и по сложности это проще FP (АЛУ для целых чисел почти в тупую используется, за исключением округления) и по диапазону очень неплохо будет, можно и научные расчёты делать.

RE: Оптимизация архитектуры - Added by Yaisis almost 2 years ago

VaalKIA wrote:

Расшифровывается как Логарифмическая Система Счисления (это термин авторов ЛСС сопроцессора), честно гвооря, не вдавался в подробности, плавающая там точка (FP - Floating Point) или фиксированная(что программисты как раз и ассоциируют с дробным числом). И вы не путаете дроби и дробные числа?

Я вначале подумал, что там дробь, но похоже, что там фиксированная точка.

RE: Оптимизация архитектуры - Added by Yaisis about 1 month ago

Давно я тут не был и что-то тихо тут у вас стало.

Зашёл сюда чтобы написать следующее:
У вас пока процессор слабо развитый и поэтому я подумал, что может вам создать конкурента Arduino и всяким микроконтроллерам.

Я не знаю, как там устроено, но в их процессорах наверняка нет суперскалярности, а ваш четырёхклеточный будет работать, как суперскалярный по производительности и при этом мало потреблять энергии.
Поэтому вы можете все микроконтроллеры уделать.
Они не будут там встраивать суперскалярность, так как это повысит энергопотребление и сложность чипа.
И таким образом ваша архитектура идеально туда ложиться.
Тем более с 4-мя клетками у вас нет проблем, а там этого хватит.
Если что, то вы и 8 можете сделать. Может даже и 16.
Плюс там не нужна ОС, надо будет только прошивки с кодом загружать и всё.
Т.е. как раз подходит для вашего текущего развития.
Нужен будет компилятор и набор библиотек.

Техпроцесс там тоже наверно не такой уж современный.
И частоты наверно небольшие.

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

Только вам надо будет ещё соответствовать по цене китайским аналогам, иначе все будут покупать и дальше китайские модули.
(возможно с ценой у вас возникнут проблемы)

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

1 ... 4 5 6 (126-134/134)