Сообщество

В следующей версии чипа мы уже много чего переделали. От пузырей мы практически избавились.
Поставить один общий декодер мы не можем. Мы сейчас идем в концепции, которая позволит перейти от "статического" ядра к "динамическому". Кратко об этом я писал в ответе на вопрос в теме "Программное обеспечение-Редактор связей". В "динамическом" ядре все-равно всплывут персональные декодеры для групп клеток.
Мы весьма скептически относимся к применению КЭШ, хотя бы в рамках ниши, в которую сейчас попадают наши МП.
В новой версии МП память уже построена по-другому. Там нет деления на ПП и ПД, все будет в одном адресном пространстве. Часть адресов - для памяти на кристалле, она быстрая. Выгребать из нее декодером смысла нет, она работает на системной частоте. Остальные адреса отданы под внешнюю память и небольшой кусок под адреса периферийных устройств.
Дополнительно память на кристалле разбита на несколько физических блоков.
Идея такая, что хотите быстро - расположите код в быстрой области памяти, без разницы - тихо ползите с внешней.
Предусмотрены каналы ПДП, что бы пока делаете одну задачу, можно загрузить другую и т.п.

Дмитрий, тогда такой вопрос. Можно ли получить какую-то документацию по новой версии чипа ? Дело в том, что летом, когда я узнал о мультиклете, у меня возникло масса замечаний и предложений. Причем не только на словах, но и с кое-какими параметрическими (по числу ядер) моделями на верилоге, синтезом на FPGA и рисованием графиков стоимости и быстродействия от числа ядер. Я написал по этому поводу сюда небольшое письмо, но ответа так и не получил. То ли в спам попало, то ли просто затерялось. Сейчас первый раз с сентября сюда зашел и был обрадован тем, что организовалось комьюнити и есть куда писать, чтобы на это обратили внимание. Хотелось бы еще раз проделать эту работу, но уже с учетом того, что и так будет обновляться. Наверняка и сейчас можно предложить кучу полезностей.
С уважением
Евгений

Про существование письма я что-то не помню, может, действительно, упало в спам и сгинуло.
Вы на какой ящик посылали?

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

Если у вас есть предложение пошлите на почту rau@multiclet.com с пометкой "для Дмитрия".

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

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

К сожалению, недопонимание еще часто рождается из-за отсутствия информации. Мы попытаемся исправить ситуацию с помощью данного инструмента. Должна появиться вкладка Wiki, где мы будем выкладывать материалы и статьи по архитектуре с поясненинями и пр.

Здравствуйте.

Планируется ли вводить программно-ориентированные ускорители (набор команд) типа:

• POPCNT - Подсчёт популяции единичных бит (SSE 4.2)
• CRC32 - Подсчёт CRC32 (SSE 4.2)

ещё не помешает:

• PTEST - Проверки бит (SSE 4.1)

SSE4 - Википедия
Benchmarking CRC32 and PopCnt instructions

В новом процессоре появится сканирование битов вперёд, назад, а также вычисление числа битов равных единице.
CRC скорее всего появится после новой версии процессора.

• будут ли реализованы команды целочисленного деления (div) и остатка от деления (mod)?
• addq, subq и аналогичные (которые работают с 8 байтами)
• почему нет модификатора команд на 2 байта?
• почему у команды типа "getq @S" модификация только "q"?
• некоторые задачи используют данные типа 1 байт и 2 байта. В текущей реализации ассемблера приходится добавлять кучу лишних команд чтобы до них добраться и обработать. Хотелось бы напрямую указывать нужную позицию (в данных 8 байт из коммутатора) размером 1 байт, 2 байта или 4 байта. Планируется ли вводить дополнительные модификаторы?

  Пример:¶

  Show Hide

  
  

  ...
  d1 := rdq #32
  d2 := rdq #32,8
  d3 := rdq #32,16
  ...
  ; Хотелось бы указывать напрямую нужный 1 байт, 2 байта или 4 байта из коммутатора:
  addb @d1[0], @d3[7] ;Первый и восьмой байт
  subb @d2[3], @d1[6] ;Четвёртый и седьмой байт
  ...
  addw @d1[0], @d3[6] ;1-2 и 7-8 байт
  subw @d2[2], @d1[5] ;3-4 и 6-7 байт
  ...
  getb @d2[5] ; Взять 6`ой байт, сохранить значение в коммутаторе
  getw @d2[6] ; Взять 7`ой и 8`ой байт, сохранить значение в коммутаторе
  getl @d2[4] ; Взять 5-8`ой байты, сохранить значение в коммутаторе
  ...
  

В следующих версиях процессора постепенно будут внедряться.
addq, subq появятся после полноценной поддержки 64 разрядных операций(но придётся уйти на меньшие техпроцессы, сейчас 180нм). Кроме getq в новом процессоре для регистров будут

Для коммутатора появится getl в новой версии и скорее всего она будет полноценной, т.е. будет gets, getb из коммутатора. Появится также тип short.

А мне вот интересно: вы проводили аудит системы комманд процессора?
Ведь существуют типовые ошибки при разработке системы комманд, которые разобраны по косточкам на разных архитектурах (тот же VLIW, думаю родился именно из таких аналитических выкладок). Тот же пресловутый BigEndian/LittleEndian или "недокументированные" комманды (посмотрите на примере z80 фирмы Zilog).
Как только накопится достаточное количество ПО, менять что-либо будет очень больно, во всех смыслах.
Поэтому, хотелось бы услышать,что вы добавляете комманды не наобум, а есть стройная система того, какой должа быть архитектура комманд и аудит сторонним специалистам (пусть даже они любители) всё-таки заказывался.

Да, мы добавляем команды не наобум. Система команд для процессора R1 определялась при взаимодействии с людьми, которые занимаются различными вычислениями и проектами. Т.е. система команд строилась не только по желанию аппаратчиков. Под некоторые специфические задачи можем добавлять или убирать какие-то команды в процессорах по требованию заказчика.

Здравствуйте.

Я так понимаю, что вас можно поздравить с полностью функционирующим R1? Поздравляю.

По поводу программирования на ASM (для будущих реализаций multiclet`a).

Так-как пока(?) или никогда(?) не будет возможности учитывать результаты работы из предыдущего параграфа в следующем параграфе через коммутатор, то ...

как насчёт ввести структуру напоминающую массив (8 байт на 32-64 строки (как коммутатор)), сделать его доступным для записи по индексу строки.
Т.е. программист сам будет решать, что ему надо записать в этот "массив" и в какую его часть.

• например, если команда пишет результат в коммутатор, то она его пишет, но если указан модификатор, то она дублирует результат ещё и в этот новый "массив" по указанному индексу.
• + надо добавить модификаторы для использования данных для аргументов команд не только из коммутатора, а так же и из этого "массива" (например просто указывая индекс массива откуда взять данные для аргумента команды)

Что это даст: каждый раз при смене параграфа не придётся заново "инициализировать" нужные данные. Для расчётных задач отпадёт необходимости писать отдельно в память результат, если код встретит ветвление (переход на другой параграф)

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

Будет профит или есть что-то, что я не учёл?

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

krufter_multiclet wrote:

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

Вот, тут, к сожалению, и получается что будут большие ограничения по использованию данных результатов из других параграфов. Конечно можно попытаться сделать ссылку с указанием параграфа например: "команда @параграф.х". Но как это будет разгребать тот же компилятор на этапе компиляции?

К тому же у вас в коммутаторе постоянно добавляются результаты от выполнения команд, так что точно указать какой результат мы хотим использовать из коммутатора в новом параграфе от предыдущего (или пред предыдущего или ..., ну вы поняли) проблемно (если вообще такое возможно указать при достаточно разветвленном коде).

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

В принципе сделать можно, когда будет делать новую версию процессора, этот вопрос ещё раз обсудим.

Предложения по новому процессору:
1. MMU для перемещаемости программ.
2. Система виртуальной адресации для подгрузки страниц из внешней SDRAM во внутреннее ОЗУ.
3. DMA для пересылки массивов устройство-память, память-устройство, память-внешняя память, внешняя память-память с арбитражом не более половины процессорного времени. После пересылки массива DMA должен вызвать прерывание.
4. Объём поддерживаемой SDRAM минимум половину адресного пространства, а лучше ужать периферию в 1/16 адресного пространства и даже меньше.
5. Аппаратный контроллер 8(16) битной NAND FLASH на одну, а лучше две микросхемы.
6. Внешняя шина для подключения LCD.
7. Внешняя 8 (16) битная шина для внешних устройств.
8. Если делать ЦАП-АЦП для звука, то не менее 4 каналов 96кГц 24-битных ЦАП и АЦП. Тогда процессор можно использовать как основу высококачественного проигрывателя музыки на уровне винила.
9. Работа DMA с устройствами пунктов 4-8
10. Возможность независимой работы целочисленным и вещественным операционным блоками одной клетки. При этом одна физическая клетка делится на две виртуальные и параллелится выполнение команд с целочисленными и вещественными операндами.
11. Запись в регистры и память по мере готовности результатов, а не после выполнения параграфа.
12. Команды целочисленного деления, извлечения остатка деления и целочисленного квадратного корня.
13. Поддержка интерпретации произвольного набора макрокоманд согласно таблице. Макрокоманда состоит из одного или нескольких параграфов, в зависимости от сложности. При обработке макрокоманды по таблице находится и выполняется нужный параграф, далее выбирается следующая макрокоманда. Так можно сделать интерпретацию произвольного набора команд.
14. Возможность усыплять неиспользуемые клетки для уменьшения потребления, а также пропускать такты синхронизации для простаивающих клеток.
15. Обработка массивов данных?
16. Вызов подпрограмм или вызова программных прерываний, но это хорошенько взвесить нужно.
Всё это исходя из возможного применения процессора в основе высококачественного бытового стационарного цифрового музыкального проигрывателя с поддержкой систем пространственного звучания. Чтоб было что через ламповый усилитель послушать :)
Ну или в будущем криптосмартфоне, но тогда нужно повысить экономичность. Например, ёмкость аккумулятора 1,3 А*ч, это порядка 4Вт*ч. Время работы не менее суток. Значит, средняя потребляемая мощность процессора не должна превышать 150мВт.

Здравствуйте.

Вот инфа, возможно пригодится:

МОДУЛЯРНО-ЛОГАРИФМИЧЕСКИЙ СОПРОЦЕССОР ДЛЯ МАССОВЫХ АРИФМЕТИЧЕСКИХ ВЫЧИСЛЕНИЙ
© 2017 г. И.П. Осинин
Саровская лаборатория имитационного моделирования
(607190 Саров, ул. Маяковского, д. 42)
E-mail: iposinin@mail.ru
Поступила в редакцию: 01.05.2017

Предлагаемый сопроцессор представляет собой самостоятельный сложнофункциональный (intellectual
property — IP) блок системы-на-кристалле, позволяющий проводить математические вычисления над веще-
ственными числами в уникальной модулярно-логарифмической системе счисления. Обеспечены два уровня
преобразования исходных чисел: в модулярную систему счисления вместо традиционной позиционной и в
логарифмическую систему счисления вместо плавающей точки. Благодаря этому сопроцессор обладает бо-
лее высоким быстродействием, точностью и надежностью вычислений по сравнению с известными аналога-
ми. Он состоит из набора одинаковых вычислительных ядер, каждое из которых выполняет однотактовые
скалярные или векторные операции. В результате проведенных исследований и разработок предложены
новые научные и технические решения, реализующие предложенные способы вычислений и кодирования
данных. При этом преобразование кодов в модулярно-логарифмическую систему счисления и обратно не
вносит значительных временных задержек при большом потоке входных данных за счет предложенных
аппаратных решений, конвейеризирующих процесс интерполяции функции логарифма и преобразования
кодов системы остаточных классов. Реализован прототип устройства на базе программируемой логической
интегральной схемы в виде IP-блока. Целевой рынок решения — компании разработчики универсальных
процессоров.

*********

Важной особенностью ЛСС является упрощение выполнения следующих операций:
‒ умножение заменяется сложением;
‒ деление заменяется вычитанием;
‒ возведение в степень заменяется умножением;
‒ извлечение корня заменяется делением.
Данное преимущество, продиктованное свойствами логарифмов, позволит повысить
быстродействие предложенного сопроцессора на классе задач, где преобладают упомя-
нутые операции. Однако за это приходится расплачиваться более сложным выполнени-
ем операций сложение и вычитание.

*********

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

‒ отсутствие переносов между модулями одного числа;
‒ замена умножение/деление на сложение/вычитание;
‒ замена возведение в степень/извлечение корня на умножение/деление.

Например, вычисление произвольного полинома восьмой степени в прототипе сопро-
цессора на ПЛИС выполнено втрое быстрее (90 нс против 267 нс) по сравнению с сер-
верным процессором Intel Xeon 2697 v3 при разнице тактовой частоты в 26 раз в пользу
Intel (0,1 ГГц против 2,6 ГГц).

Более высокая точность вычислений по сравнению с использованием плавающей
точки достигается благодаря следующим факторам:
‒ отсутствие округления результата при выполнении операций умножение, деление,
возведение в степень;
‒ отсутствие выравнивания порядков, в результате чего происходит потеря значащих
разрядов.
Это позволяет верно решать ряд задач, критичных к ошибкам округления в пере-
численных операциях и содержащих разномасштабные данные, в отличие от универ-
сальных процессоров.
В отличие от известных вычислительных устройств, высокая надежность обеспечена
на аппаратном уровне за счет следующих механизмов:
‒ выявление одиночных и двойных ошибок в вычислительном устройстве;
‒ реконфигурация ядер сопроцессора при отказе одного или нескольких из них с про-
должением процесса счета.
Стоит отметить, что преобразование кодов в МЛСС и обратно не вносит значитель-
ных временных задержек при большом потоке входных данных за счет предложенных
аппаратных решений, конвейеризирующих процесс интерполяции функции логарифма и
преобразования кодов системы остаточных классов.
Одним из перспективных направлений внедрения разработки являются отечествен-
ные процессоры, например, Эльбрус-8С, Байкал-M, KOMDIV-64. Применение сопроцес-
сора в этих системах-на-кристалле позволило бы дополнить их конкурентные преимуще-
ства рассмотренными, что, в конечном счете, сыграло бы важную роль в импортозаме-
щении вычислительных компонент.

https://vestnik.susu.ru/cmi/article/download/5989/5368

Брал отсюда: http://forum.ixbt.com/topic.cgi?id=8:25255:4567#4567

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