Критика и предложение усовершенствования архитектуры процессора Мультиклет

Added by futurama about 6 years ago

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

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

Предложение об усовершенствовании:

1. Сделать один общий асинхронный декодер команд.

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

3. Это позволит избавится от "пузырей" в памяти.

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

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

6. Декодер работает только один раз при декодировании всех команд параграфа, а в остальное время отключается в целях экономии электроэнергии.

7. При исчерпании всех команд из кэша, декодер загружает очередной параграф и декодирует его.

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

9. Общий асинхронный декодер позволит исполнять программы сразу из внешней памяти, например из памяти типа DDR3. В которой команды программы
располагаются последовательно одна за другой без "пузырей". А вместо Памяти Программ (ПП) в составе чипа кэш-память декодированных команд,
которая как и ПП делится на банки, в которых располагаются команды для своих клеток.

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

С уважением, Алексей.


Replies (18)

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by DmitryK_multiclet about 6 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by eugenk about 6 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by DmitryK_multiclet about 6 years ago

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

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

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by eugenk about 6 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by DmitryK_multiclet about 6 years ago

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

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by sprin almost 6 years ago

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

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

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

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

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

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by krufter_multiclet almost 6 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by sprin over 5 years ago

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

    Пример:

    Show

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by krufter_multiclet over 5 years ago

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

Варианты GET:

Show

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by VaalKIA over 4 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by krufter_multiclet over 4 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by sprin about 4 years ago

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

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

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

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

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

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

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

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

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by krufter_multiclet about 4 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by sprin about 4 years ago

krufter_multiclet wrote:

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

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

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

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by krufter_multiclet about 4 years ago

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

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by Servis-engineer over 2 years ago

Предложения по новому процессору:
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мВт.

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by sprin almost 2 years ago

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

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

МОДУЛЯРНО-ЛОГАРИФМИЧЕСКИЙ СОПРОЦЕССОР ДЛЯ МАССОВЫХ АРИФМЕТИЧЕСКИХ ВЫЧИСЛЕНИЙ

Show

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

5989-14302-1-PB.pdf - МОДУЛЯРНО-ЛОГАРИФМИЧЕСКИЙ СОПРОЦЕССОР ДЛЯ МАССОВЫХ АРИФМЕТИЧЕСКИХ ВЫЧИСЛЕНИЙ (362 KB)

RE: Критика и предложение усовершенствования архитектуры процессора Мультиклет - Added by VaalKIA almost 2 years ago

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

(1-18/18)