Отвечу подробнее по всем пунктам:
1) Железо.
Отладочный комплект если смотреть на сами платы состоит из двух частей: базовая плата и процессорная с R1. Так вот процессорная плата уже сейчас является самодостаточной за исключением того, что к ней еще нужен программатор.
LDM-Systems к сентябрю обещали выпустить более дешевую версия программатора, а также появится возможность заказать минимальную комплектацию процессорной платы. Т.е. вы купили процессорную плату запитали, например от ПК через USB, используете программатор и получаете результат. В итоге все выйдет раз в 5 дешевле, чем полный комплект. В сентябре по этому вопросу у нас будет отдельная статья на Хабре.
2) Софт.
У нас есть функциональная модель и эмулятор UART. Скачиваем IDE Geany с нашего сайта, открываем руководство по быстрому запуску. Максимум за полчаса все настраиваем и запускаем. Документация сейчас активно редактируется. Примеры программ также в большом количестве сейчас на стадии оформления. На следующей неделе я надеюсь выложим больше материала на сайт.
3) Позиционирование.
В последнее время мы практически не занимаемся пиаром. Мне самому режет слух, когда говорят «инновационная» технология.
У нас просто процессор на новой архитектуре, разработанный в Екатеринбурге и ориентированный на максимальное быстродействие в распараллеливаемых вычислениях с распределением вычислительных ресурсов.
4) Open Source.
Постараемся приложить максимум усилий для развития данной тематики.
Посылку отправили сразу же как у нас появилась отладочная плата. Первая отладочная плата потребовала коррекций для удобства пользователей. Я лично просил LDM-Systems внести правки, чтобы пользователям было удобно работать с платой. Те, кто занимаются у нас продажей выставляют счета заранее и указывают срок с расчетом, что плата придет и сразу заработает.
По компилятору особого желания что-то попробовать сделать (на сколько мне известно) никто не проявлял.
Понятно, что мы должны выделить конкретные блоки, которые необходимо закончить, написать статью на Хабре о том как у нас все устроено. Также нам необходимо подумать о поощрении разработчиков. Да, у нас нет опыта работы в концепции «Open Source». Поделитесь вашим видением того, что мы должны сделать, чтобы достичь успеха.
Первое, что хочется сказать — большое спасибо представителям Embox за статью!
Вы проделали действительно большой объем работы и получили результат.
Очень хотелось бы список всего, что необходимо в первую очередь от нас.
Когда я первый раз пришел в компанию Мультиклет существовала только версия в FPGA прообраза P1.
В это же время начинали писать компилятор. Мы и тогда понимали как вести разработку:
1) Сначала делаем и корректируем программную модель
2) Далее пишем компилятор, сталкиваемся с трудностями, понимаем как их преодолеть
3) Вносим коррективы в архитектуру и систему команд и возвращаемся к пунктам 1 и 2 пока не получим выйгрыша на большинстве тестов
Некорректно нас сравнивать с Эльбрусом, т.к. у нас нет финансовой поддержки со стороны государства.
Действительность такова, что нам приходится жить по средствам!
В архитектуре мы видим потенциал, понимаем где и как мы можем быть быстрее. Сейчас выпущено 2 реализации
мультиклеточной архитектуры (P1 и R1). Мы уже знаем как в несколько раз ускориться по архитектуре на нераспараллеливаемом коде, но перед выпуском R2 в идеале надо пройти этапы по пунктам 1,2,3 и получить компилятор, который нас устраивает.
Нет проблемы в создании компилятора для нашей архитектуры. Надо просто направить усилия и средства на это и пройти весь путь до конца. В идеале нам нужен человек, который бы уже написал компилятор и смог сразу учесть все тонкости и нигде не забуксовать и пройти такой путь с нами.
Использовать готовый компилятор не так просто. Мы взяли компилятор lcc (могли взять и gnu) за основу за несколько месяцев собрали под нас Си89 в итоге получили избыточный код, который и выполняется дольше и занимает больше места, чем нужно. Сейчас ведутся работы по оптимизации этого компилятора
и рассматривается возможность его развития до уровня Си99.
По llvm процитирую ответы mikhanoid в комментариях к нашей публикации на Хабре:
1) LLVM заточен на регистровые машины, то есть на те, в которых обмен данными между инструкциями осуществляется через регистры.
Регистр, как абстракция, это такая именованная ячейка памяти. LLVM ожидает, что если в регистр с именем X записано некоторое значение, то потом оно и будет всегда читаться по этому имени X до следующей записи.
Объяснить LLVM, что такое «ссылка на результат одной из предыдущих инструкций», и то, что одно и то же имя, например, "@1" может означать разные значения, не понятно как. Мы не разобрались сами.
Но если кто-то нам подскажет, мы будем весьма рады и благодарны этому хорошему человеку.
2) Наша первая попытка была: взять стандартный интерфейс для описания целевой машины LLVM и реализовать его. На этом уровне не получилось.
Проблема не в количестве, а в том, что эти vreg-и являются именно регистрами, то есть, они хранят связанные с ними значения постоянно. LLVM считает, что vreg переживает ветвления. А у нас совсем не так.
То есть, ссылка на коммутатор, в общем случае, не переживает линейный блок. И нужно делать анализ, каково время жизни текущего vreg-а. Много проблем в этот анализ добавляет наличие phi-узлов с их хитрыми множественными входами.
И это половина беды. LLVM к тому же считает, что все операции с памятью и регистрами осуществляются последовательно. То есть, он пишет в свой этот vreg и считает, что все следующие чтения из него будут давать последнюю версию данных. Это же считается справедливым и для записей в память.
А у нас они осуществляются параллельно, с контролем порядка только по границам параграфа. И вот тут для получения хорошего кода нужен некий адский анализ, до которого мы так и не додумались.
По идее, нам бы хорошо иметь в самом начале оптимизации замкнутые по чтениям/записям линейные участки, а потом их уже объединять, анализируя ссылки на память или регистры, куда осуществляются доступы. А LLVM выдаёт совсем не такой код.
Надо мне оформить раздел «Часто задаваемые вопросы» по архитектуре, чтобы освоение проходило быстрее.
1. Результат большинства команд помещается в коммутатор, за исключением команд setl, wrl.
Чтобы записать значение в регистр или РОН, существует команда setl.
Например setl #0, 0x12345.
Никто не запрещает написать так:
Т.к. запись в РОН в текущей реализации мультиклеточной архитектуры проходит по концу параграфа (complete), то мы не гарантируем, что в это случае окажется в РОН 0.
В следующем процессоре мы планируем уйти от такого контроля РОНов.
2. Просто подставится 0.
3. Команды условных и безусловного переходов указывают на метку параграфа на который по complete произойдет переход(в качестве аргумента может быть и метка текущего параграфа).
4. Смотря откуда грузить и в какой буфер, вообще у нас доступ к внутренней оперативной памяти процессора (в R1 512 Кбайт) за 1 такт.
5. Оператор @ у нас означает ссылку на результат только предыдущей команды.
@8 означает, что в качестве аргумента для текущей команды будет взят результат из коммутатора для команды стоящей на 8 строчек выше. Окно видимости означает, что мы можем обратится максимум по @63, т.е. к результату 63-й команды, которая была записана 63 строчки назад.
Хотя в параграфе может быть неограниченно количество команд, например можно прокинуть результать дальше с помощью команды getl. Когда мы раскручиваем код на ассемблере, то у нас иногда бывают параграфы на 200 команд, но так в основном по методу «копировать» — «вставить» + корректировка ссылок. Хотя в ассемблере программно наверно можно сделать более удобной эту развертку.
В текущей реализации архитектуры команды уходят в клетки от начала параграфа, начиная с 0-й клетки и так далее последовательно. В общем да, буфер составит 256 команд.
Пока еще асинхронный механизм не реализовывали. Пример из п.2 для обычной демонстрации, написан вручную, цели по оптимизации не ставилось.На высоких частотах и при большем количестве клеток идею можно будет рассматривать. Но сейчас мы пока локальные изменения выписываем в рамках оптимизации текущей концепции.
Нет, на диаграмме все верно. У нас с начала параграфа команды уходят по порядку в клетки, начиная с 0-й.
Т.е. если у нас есть параграф:
paragraph:
get a
get b
get c
addl @2, @3
get e
complete
То команда get a уйдет на исполнение в 0-ю клетку, команда get b в 1-ю клетку, команда get c во 2-ю клетку, addl @2, @3 попадет в 3-ю клетку, get e попадет в 0-ю клетку и так далее.
Чуть больше подробностей можно посмотреть тут Вики с кратким обзором архитектуры
Обратился по факту этого вопроса к руководству, комментарий Стрельцова:
Эта команда была сделана в проекте Синпьютер, но была выполота, т.к. не дала такого эффекта. Говорит, что это не первый случай когда такое предлагают, но смысла добавления данной команды, кроме экономии памяти программ особого нет. У нас выборка за такт, чтение внутренней памяти за такт.
Не факт, что в результате получится такой большой выйгрыш, но теоретически Ваша мультикоманда может ускорить вычисления. Но вопрос еще в записи и указании, что ссылка должна меняться соответствующим образом, но это все решаемо. Если будете продумывать логику, то может Вам пригодиться система команд побитовая multiclet.com/community/projects/examples/wiki/R1_ISA
1. Клетка в R1 не ждет готовности приемника данных и может выполнить команду, которая есть в буфере команд этой клетки, т.е. допустим для группы из 4-х клеток будет следующее:
getl 1; эта команда уйдет в 0-ю клетку
getl 2; в 1-ю клетку
addl @1, @2; во 2-ю клетку
addl @1, 19052015; в 3-ю клетку
setl #0, @1; в 0-ю клетку и так далее
2. После выполнения команды её результат за 1 такт рассылается во все коммутационные устройства клеток.
Клетка исполняет только команды для которых готовы данные. Клетки могут выполнять даже команды следующих параграфов, если нет зависимости по данным, но порядок распределения команд см пункт 1.
У нас одно ALU_FLOAT каждый так выполняет одно комплексное умножение, а это 6 операций.
Проведем краткий экскурс в математику(раскроем скобки):
(a+bi)*(c+di) = (a*c — b*d) + i*(a*d+b*c)
Теперь считаем операции:
(для реальной части): умножение, вычитание, умножение — 3 операции
(для комплексной части): умножение, сложение, умножение — 3 операции
Итого в потоке пиковая производительность составит 6 операций за такт.
Потенциально преимущества: уменьшение занимаемой памяти программ и ускорение загрузки команд.
Только вопрос в какую логику это выливается в ядре, получится ли это реализовать просто.
Сейчас у нас есть .rept .endr в ассемблере для простого повторения команды.
Но иногда, бывает нужно не просто повторять команду, а повторять с измененной ссылкой на аргументы.
Но, чтобы разработчики ядра это сделали аппаратно необходимо доказать ощутимую пользу от этого усложнения ядра.
Буфер у нас в каждой клетке на 64 команды.
P.S. пишете на verilog, vhdl; svn, git для вас знакомые слова, умеете пользоваться потактовыми симуляторами, есть опыт разработки устройств на fpga, отдельных блоков, отправляйте своё резюме генеральному директору(почта есть в контактах на сайте мультиклет). Мы находимся в г, Екатеринбург.
Внутренние вычислялки в современных процессорах бывает даже меньше чем за один такт вычисляют. Впихнут ALU работающий на удвоеной частоте, а то и два. Но вот чтобы получить описаные 2.4ГФлопа на 100 мегагерц и четыре ядра(клетки), нужно обеспечить уж шибко большое количество float-умножалок, которые нигде в описаниях у них не отсвечивают. Вполе может это число взято из таблички о 64клеточном варианте и «случайно» тиражируется от поста к посту. Или флопы тут посчитаны относительно 16битных float. Или ещё какой казус. Но в 2.4ГФлопа верится с трудом.
Не нужно большое количество float умножалок, у нас есть блок ALU_FLOAT в каждой клетке.
Как получаются 2.4 ГФлопса в статье расписано очень подробно на мой взгляд. Состав блоков процессора также показан в предыдущей статье, на которую приводится ссылка. Случайно у нас ничего не тиражируется в статьях.
Это бесспорно так. Речь идёт о том что копирование — это логичная мера для импортозамещения. Напомню, что во многих изделиях есть платформозависимый код, который нужно либо запустить на аналоге, либо переписывать под что-то другое.
Некоторые руководители компаний, хотя таких очень мало так и понимают, что импортозамещение процессора равно выкинули Texas и поставили Мультиклет, загрузили прошивку и все работает сразу на плате.
Систему команд тайгера придумывали крупные специалисты ЦОС-а. Не ставя изначально себе цель побить ЦОС-гиганта, этого не сделать. Поэтому хочу вас предостеречь от ставок на этот счёт.
Но есть тот факт, что некоторым разработчикам хочется дополнительных аппаратных возможностей и блоков. Мы можем тут сыграть.
Для меня это лишь слова. Никакие процессы в концепции структурного программирования хорошо не распараллеливаются, если они не разнородные по своей природе. А разнородные — это есть потоки/процессы, которые успешно раздаются разным клеткам ядрам процессора.
Когда я пришел в Мультиклет, также заблуждался насчет распараллеливания. У нас не надо как-то сильно заморачиваться с распараллеливанием. На самом деле все просто, многое сводится к Ctrl+C и Ctrl+V(мы также думаем над дополнительными инструкциями чисто на программном уровне на ассемблере, чтобы и это упростить+в числе оптимизаций компилятора это будет). На самом деле этот вопрос очень интересный, написаны даже книги по этой области. И мы тоже сделаем статью по части примеров распараллеливания задачи и получения выйгрыша(сразу скажу, что распараллелить можно почти все в больших вычислениях). Но сначала на Хабре мы хотим сделать статьи простые, для того чтобы люди начали работать на Мультиклете и все моменты им были понятны и чтобы первый старт не занимал больше одного дня.
У меня бывают такие же мечты: сделать не так как все, предложить альтернативное и непохожее решение, чем добиться невиданных свойств изящества и производительности. Но полезно признать, что окружающие не так уж глупы, а современные решения — во многом рациональны и сбалансированы. Поэтому искренне желаю вам трезвомыслия и, конечно, удачи в поиске!
Мы пытаемся реализовать то, что планируем. Как у нас говорят: «Дорогу осилит идущий». Что касается архитектур типа АРМ и х86, тут надо понимать такой момент, что они являются заложниками своих предыдущих разработок, им нельзя просто взять все выкинуть и начать делать что-то новое, т.к. написано больше количество программного обеспечения и выбран путь разработки, на котором необходимо обходить все преграды. Система команд и концепция у многих архитектур разработаны достаточно давно и сложно сейчас что-то менять координально. Поэтому нельзя исключать возможности создания чего-то нового, что даст выйгрыш. Это как решение задач в школе, можно решить задачу строго по теме, которую ты проходишь, на основании того мат аппарата, который заложен как базовый. А можно применить ещё и логику и сделать решение задачи проще и быстрее, при этом конечно же потратить меньше мыслительных потугов и энергопотребления. Мы пытаемся мыслить трезво и идем к результату, на каких позициях мы окажемся покажет время.
P.S. В R1 можно управлять частотой, напряжением питания пока нет, но все лучшее впереди)
Разработчики Миландр, разумеется, стараются и исправляют свои ошибки(никто не оспаривает их профессионализм), но часть ошибок связана и с покупным ядром, которые должны править разработчики ядра. Я хотел показать, что копирование — это не всегда признак стабильной работы и надо развиваться дальше, не только подражая тому, что есть.
Разработчики полюбят и Мультиклет, только нам для этого нужно показать, что программировать под него, как и создавать новые устройства очень просто. Разработчики одной из компаний, которые выжимали максимум на процессорах фирмы TI, сказали нам, что наш ассемблер им очень понравился. В следующих статьях на Хабре я и мои коллеги постараемся показать, что программировать как на Си, так и на ассемблере, а также работать с отладочной платой легко и приятно. Как переносить свои текущие наработки без большого труда с STM32 на Мультиклет мы тоже покажем.
Что касается области применения:
1) В области радиолокации и обработки сигналов 2 процессора не занимают всю нишу. В каких-то проектах разработчики могут попробовать применить Мультиклет и мы вполне сможем соседствовать с Миландром.
TigerShark в дальнейшем сможем подвинуть, это вопрос времени. Мы прислушиваемся к пожеланиям разработчиков и просто неравнодушных людей и рассматриваем их.
2) В области под названием микроконтроллеры, а также отказоустойчивые системы сейчас сложно сказать, что ниша занята. Самое сложное — это сделать первый шаг и попробовать что-то написать на новом процессоре.
Многое в том, какой процессор применить, будет зависеть от разработчиков и людей принимающих решения.
3) Мы можем не конкурировать в дальнейшем с Эльбрусом, а наоборот сделать видеокарту или ускоритель для их компьютера. Но сначала надо привести в оптимальное состояние мультиклеточные процессоры текущего формата. Хотя сейчас как раз решается направление в которое мы идем дальше. Все зависит в большей степени от того, на что будут выделены средства.
Я уже писал в каких областях наши процессоры можно применить наилучшим образом: задачи, которые распараллеливаются, задачи управления, проекты с низким энергопотреблением, задачи с несколькими независимыми потоками, для построения надежных и устойчивых систем, задачи требующие высокой производительности и широкий набор периферии, обработка сигналов, задачи по работе с аудио информацией, устройства, работающие в агрессивных условиях среды при низких температурах от -60 до +125.
Процессоры P1 и R1 — это первые представители мультиклеточной архитектуры. Нельзя сказать, что это демонстрация идеальной реализации разработанной концепции (у нас имеется огромный простор для роста в снижении энергопотребления, увеличении производительности и дополнении архитектуры), но это процессоры с которыми можно работать и получать на их основе готовые устройства в различных областях применения.
Очень сложно догнать кого-то и перегнать, если ты идешь по тому же пути и встречаешь те же преграды, которые необходимо преодолевать, изобретая сложные конструкции и в которые приходится упираться. Можно попытаться найти другой путь, зная опыт преград и историю трудностей с которыми столкнулись другие.
И кто сказал, что архитектура ядра ARM — это идеал?
Даже если копировать, то получается не всё так радужно. Мультиклет — это и есть прогресс, а не попытка продолжить копирование.
Сразу замечу, что ошибки имеются и в наших процессорах и мы их исправляем, делаем пути обхода.Наши ошибки мы обычно указываем сразу в документации на процессор. Но я думаю в дальнейшем будет тоже отдельный документ(сейчас документацию приводим в полноценный вид по R1).
Так вот приведу первые попавшиеся примеры errata на Миландр, чтобы не было ощущения, что скопировав Вы получите идеал: milandr.ru/uploads/doc_img/production/spec_seriya_1986BE9x_errata.pdf milandr.ru/uploads/doc_img/production/spec_1986BE3_errata.pdf
Судя по первым ошибкам в этих документах Ваш танк может начать сначала стрелять дальше, чем планировалось, а потом и из всех орудий(врагу мало не покажется, главное чтобы не прилетело по своим).
P.S. Для того, чтобы начать работать с процессором R1 не нужно много всего изучать. Скоро будет процесс обучения нового поколения начиная со школы и продолжая Вузом. К Вам на предприятие придут специалисты уже обученные работать на отечественном процессоре.
А я предлагаю это делать на деньги заинтересованного заказчика, а не явно и неявно спонсировать из моего кармана.
Если заинтересованных заказчиков не достаточно для развития этой технологии — вероятно люди страдают ерундой, а не эффективным решением задач.
Мы именно так сейчас и развиваемся только на средства заинтересованных заказчиков. Госзаказов у нас пока тоже нет, у нас инициативная разработка.
Если бы у нас еще были государственные средства, то мы бы сейчас делали ускоритель с большим количеством клеток, сделали бы надежный радстойкий процессор и компилятор был бы готов.
1) Железо.
Отладочный комплект если смотреть на сами платы состоит из двух частей: базовая плата и процессорная с R1. Так вот процессорная плата уже сейчас является самодостаточной за исключением того, что к ней еще нужен программатор.
LDM-Systems к сентябрю обещали выпустить более дешевую версия программатора, а также появится возможность заказать минимальную комплектацию процессорной платы. Т.е. вы купили процессорную плату запитали, например от ПК через USB, используете программатор и получаете результат. В итоге все выйдет раз в 5 дешевле, чем полный комплект. В сентябре по этому вопросу у нас будет отдельная статья на Хабре.
2) Софт.
У нас есть функциональная модель и эмулятор UART. Скачиваем IDE Geany с нашего сайта, открываем руководство по быстрому запуску. Максимум за полчаса все настраиваем и запускаем. Документация сейчас активно редактируется. Примеры программ также в большом количестве сейчас на стадии оформления. На следующей неделе я надеюсь выложим больше материала на сайт.
3) Позиционирование.
В последнее время мы практически не занимаемся пиаром. Мне самому режет слух, когда говорят «инновационная» технология.
У нас просто процессор на новой архитектуре, разработанный в Екатеринбурге и ориентированный на максимальное быстродействие в распараллеливаемых вычислениях с распределением вычислительных ресурсов.
4) Open Source.
Постараемся приложить максимум усилий для развития данной тематики.
Понятно, что мы должны выделить конкретные блоки, которые необходимо закончить, написать статью на Хабре о том как у нас все устроено. Также нам необходимо подумать о поощрении разработчиков. Да, у нас нет опыта работы в концепции «Open Source». Поделитесь вашим видением того, что мы должны сделать, чтобы достичь успеха.
По ядру есть система команд открытая: multiclet.com/community/projects/examples/wiki/R1_ISA
По компилятору Си89: multiclet.com/community/projects/mcc-lcc
По собственным наработкам: multiclet.com/community/projects/mcc-lime
По примерам программ: multiclet.com/community/projects/examples/wiki
Вы проделали действительно большой объем работы и получили результат.
Очень хотелось бы список всего, что необходимо в первую очередь от нас.
Когда я первый раз пришел в компанию Мультиклет существовала только версия в FPGA прообраза P1.
В это же время начинали писать компилятор. Мы и тогда понимали как вести разработку:
1) Сначала делаем и корректируем программную модель
2) Далее пишем компилятор, сталкиваемся с трудностями, понимаем как их преодолеть
3) Вносим коррективы в архитектуру и систему команд и возвращаемся к пунктам 1 и 2 пока не получим выйгрыша на большинстве тестов
Некорректно нас сравнивать с Эльбрусом, т.к. у нас нет финансовой поддержки со стороны государства.
Действительность такова, что нам приходится жить по средствам!
В архитектуре мы видим потенциал, понимаем где и как мы можем быть быстрее. Сейчас выпущено 2 реализации
мультиклеточной архитектуры (P1 и R1). Мы уже знаем как в несколько раз ускориться по архитектуре на нераспараллеливаемом коде, но перед выпуском R2 в идеале надо пройти этапы по пунктам 1,2,3 и получить компилятор, который нас устраивает.
Нет проблемы в создании компилятора для нашей архитектуры. Надо просто направить усилия и средства на это и пройти весь путь до конца. В идеале нам нужен человек, который бы уже написал компилятор и смог сразу учесть все тонкости и нигде не забуксовать и пройти такой путь с нами.
Использовать готовый компилятор не так просто. Мы взяли компилятор lcc (могли взять и gnu) за основу за несколько месяцев собрали под нас Си89 в итоге получили избыточный код, который и выполняется дольше и занимает больше места, чем нужно. Сейчас ведутся работы по оптимизации этого компилятора
и рассматривается возможность его развития до уровня Си99.
По llvm процитирую ответы mikhanoid в комментариях к нашей публикации на Хабре:
1) LLVM заточен на регистровые машины, то есть на те, в которых обмен данными между инструкциями осуществляется через регистры.
Регистр, как абстракция, это такая именованная ячейка памяти. LLVM ожидает, что если в регистр с именем X записано некоторое значение, то потом оно и будет всегда читаться по этому имени X до следующей записи.
Объяснить LLVM, что такое «ссылка на результат одной из предыдущих инструкций», и то, что одно и то же имя, например, "@1" может означать разные значения, не понятно как. Мы не разобрались сами.
Но если кто-то нам подскажет, мы будем весьма рады и благодарны этому хорошему человеку.
2) Наша первая попытка была: взять стандартный интерфейс для описания целевой машины LLVM и реализовать его. На этом уровне не получилось.
Проблема не в количестве, а в том, что эти vreg-и являются именно регистрами, то есть, они хранят связанные с ними значения постоянно. LLVM считает, что vreg переживает ветвления. А у нас совсем не так.
То есть, ссылка на коммутатор, в общем случае, не переживает линейный блок. И нужно делать анализ, каково время жизни текущего vreg-а. Много проблем в этот анализ добавляет наличие phi-узлов с их хитрыми множественными входами.
И это половина беды. LLVM к тому же считает, что все операции с памятью и регистрами осуществляются последовательно. То есть, он пишет в свой этот vreg и считает, что все следующие чтения из него будут давать последнюю версию данных. Это же считается справедливым и для записей в память.
А у нас они осуществляются параллельно, с контролем порядка только по границам параграфа. И вот тут для получения хорошего кода нужен некий адский анализ, до которого мы так и не додумались.
По идее, нам бы хорошо иметь в самом начале оптимизации замкнутые по чтениям/записям линейные участки, а потом их уже объединять, анализируя ссылки на память или регистры, куда осуществляются доступы. А LLVM выдаёт совсем не такой код.
1. Результат большинства команд помещается в коммутатор, за исключением команд setl, wrl.
Чтобы записать значение в регистр или РОН, существует команда setl.
Например setl #0, 0x12345.
Никто не запрещает написать так:
paragraph:
setl #0, #0+12345
setl #1, #1+54321
addl @1, @2
jmp letsgo
complete
В этом случае в один такт произойдет запись в РОН 0 и РОН 1 в клетках 0 и 1.
Но вот так писать нельзя:
paragraph:
setl #0, #0 + 12345
setl #0, #0 + 54321
addl @1, @2
jmp letsgo
complete
Т.к. запись в РОН в текущей реализации мультиклеточной архитектуры проходит по концу параграфа (complete), то мы не гарантируем, что в это случае окажется в РОН 0.
В следующем процессоре мы планируем уйти от такого контроля РОНов.
2. Просто подставится 0.
3. Команды условных и безусловного переходов указывают на метку параграфа на который по complete произойдет переход(в качестве аргумента может быть и метка текущего параграфа).
4. Смотря откуда грузить и в какой буфер, вообще у нас доступ к внутренней оперативной памяти процессора (в R1 512 Кбайт) за 1 такт.
5. Оператор @ у нас означает ссылку на результат только предыдущей команды.
@8 означает, что в качестве аргумента для текущей команды будет взят результат из коммутатора для команды стоящей на 8 строчек выше. Окно видимости означает, что мы можем обратится максимум по @63, т.е. к результату 63-й команды, которая была записана 63 строчки назад.
Хотя в параграфе может быть неограниченно количество команд, например можно прокинуть результать дальше с помощью команды getl. Когда мы раскручиваем код на ассемблере, то у нас иногда бывают параграфы на 200 команд, но так в основном по методу «копировать» — «вставить» + корректировка ссылок. Хотя в ассемблере программно наверно можно сделать более удобной эту развертку.
Пока еще асинхронный механизм не реализовывали. Пример из п.2 для обычной демонстрации, написан вручную, цели по оптимизации не ставилось.На высоких частотах и при большем количестве клеток идею можно будет рассматривать. Но сейчас мы пока локальные изменения выписываем в рамках оптимизации текущей концепции.
Т.е. если у нас есть параграф:
paragraph: get a get b get c addl @2, @3 get e completeТо команда get a уйдет на исполнение в 0-ю клетку, команда get b в 1-ю клетку, команда get c во 2-ю клетку, addl @2, @3 попадет в 3-ю клетку, get e попадет в 0-ю клетку и так далее.
Чуть больше подробностей можно посмотреть тут Вики с кратким обзором архитектуры
Эта команда была сделана в проекте Синпьютер, но была выполота, т.к. не дала такого эффекта. Говорит, что это не первый случай когда такое предлагают, но смысла добавления данной команды, кроме экономии памяти программ особого нет. У нас выборка за такт, чтение внутренней памяти за такт.
getl 1; эта команда уйдет в 0-ю клетку
getl 2; в 1-ю клетку
addl @1, @2; во 2-ю клетку
addl @1, 19052015; в 3-ю клетку
setl #0, @1; в 0-ю клетку и так далее
2. После выполнения команды её результат за 1 такт рассылается во все коммутационные устройства клеток.
Клетка исполняет только команды для которых готовы данные. Клетки могут выполнять даже команды следующих параграфов, если нет зависимости по данным, но порядок распределения команд см пункт 1.
Проведем краткий экскурс в математику(раскроем скобки):
(a+bi)*(c+di) = (a*c — b*d) + i*(a*d+b*c)
Теперь считаем операции:
(для реальной части): умножение, вычитание, умножение — 3 операции
(для комплексной части): умножение, сложение, умножение — 3 операции
Итого в потоке пиковая производительность составит 6 операций за такт.
Только вопрос в какую логику это выливается в ядре, получится ли это реализовать просто.
Сейчас у нас есть .rept .endr в ассемблере для простого повторения команды.
Но иногда, бывает нужно не просто повторять команду, а повторять с измененной ссылкой на аргументы.
Но, чтобы разработчики ядра это сделали аппаратно необходимо доказать ощутимую пользу от этого усложнения ядра.
Буфер у нас в каждой клетке на 64 команды.
P.S. пишете на verilog, vhdl; svn, git для вас знакомые слова, умеете пользоваться потактовыми симуляторами, есть опыт разработки устройств на fpga, отдельных блоков, отправляйте своё резюме генеральному директору(почта есть в контактах на сайте мультиклет). Мы находимся в г, Екатеринбург.
Не нужно большое количество float умножалок, у нас есть блок ALU_FLOAT в каждой клетке.
Как получаются 2.4 ГФлопса в статье расписано очень подробно на мой взгляд. Состав блоков процессора также показан в предыдущей статье, на которую приводится ссылка. Случайно у нас ничего не тиражируется в статьях.
Некоторые руководители компаний, хотя таких очень мало так и понимают, что импортозамещение процессора равно выкинули Texas и поставили Мультиклет, загрузили прошивку и все работает сразу на плате.
Но есть тот факт, что некоторым разработчикам хочется дополнительных аппаратных возможностей и блоков. Мы можем тут сыграть.
Когда я пришел в Мультиклет, также заблуждался насчет распараллеливания. У нас не надо как-то сильно заморачиваться с распараллеливанием. На самом деле все просто, многое сводится к Ctrl+C и Ctrl+V(мы также думаем над дополнительными инструкциями чисто на программном уровне на ассемблере, чтобы и это упростить+в числе оптимизаций компилятора это будет). На самом деле этот вопрос очень интересный, написаны даже книги по этой области. И мы тоже сделаем статью по части примеров распараллеливания задачи и получения выйгрыша(сразу скажу, что распараллелить можно почти все в больших вычислениях). Но сначала на Хабре мы хотим сделать статьи простые, для того чтобы люди начали работать на Мультиклете и все моменты им были понятны и чтобы первый старт не занимал больше одного дня.
Мы пытаемся реализовать то, что планируем. Как у нас говорят: «Дорогу осилит идущий». Что касается архитектур типа АРМ и х86, тут надо понимать такой момент, что они являются заложниками своих предыдущих разработок, им нельзя просто взять все выкинуть и начать делать что-то новое, т.к. написано больше количество программного обеспечения и выбран путь разработки, на котором необходимо обходить все преграды. Система команд и концепция у многих архитектур разработаны достаточно давно и сложно сейчас что-то менять координально. Поэтому нельзя исключать возможности создания чего-то нового, что даст выйгрыш. Это как решение задач в школе, можно решить задачу строго по теме, которую ты проходишь, на основании того мат аппарата, который заложен как базовый. А можно применить ещё и логику и сделать решение задачи проще и быстрее, при этом конечно же потратить меньше мыслительных потугов и энергопотребления. Мы пытаемся мыслить трезво и идем к результату, на каких позициях мы окажемся покажет время.
P.S. В R1 можно управлять частотой, напряжением питания пока нет, но все лучшее впереди)
Разработчики полюбят и Мультиклет, только нам для этого нужно показать, что программировать под него, как и создавать новые устройства очень просто. Разработчики одной из компаний, которые выжимали максимум на процессорах фирмы TI, сказали нам, что наш ассемблер им очень понравился. В следующих статьях на Хабре я и мои коллеги постараемся показать, что программировать как на Си, так и на ассемблере, а также работать с отладочной платой легко и приятно. Как переносить свои текущие наработки без большого труда с STM32 на Мультиклет мы тоже покажем.
Что касается области применения:
1) В области радиолокации и обработки сигналов 2 процессора не занимают всю нишу. В каких-то проектах разработчики могут попробовать применить Мультиклет и мы вполне сможем соседствовать с Миландром.
TigerShark в дальнейшем сможем подвинуть, это вопрос времени. Мы прислушиваемся к пожеланиям разработчиков и просто неравнодушных людей и рассматриваем их.
2) В области под названием микроконтроллеры, а также отказоустойчивые системы сейчас сложно сказать, что ниша занята. Самое сложное — это сделать первый шаг и попробовать что-то написать на новом процессоре.
Многое в том, какой процессор применить, будет зависеть от разработчиков и людей принимающих решения.
3) Мы можем не конкурировать в дальнейшем с Эльбрусом, а наоборот сделать видеокарту или ускоритель для их компьютера. Но сначала надо привести в оптимальное состояние мультиклеточные процессоры текущего формата. Хотя сейчас как раз решается направление в которое мы идем дальше. Все зависит в большей степени от того, на что будут выделены средства.
Я уже писал в каких областях наши процессоры можно применить наилучшим образом: задачи, которые распараллеливаются, задачи управления, проекты с низким энергопотреблением, задачи с несколькими независимыми потоками, для построения надежных и устойчивых систем, задачи требующие высокой производительности и широкий набор периферии, обработка сигналов, задачи по работе с аудио информацией, устройства, работающие в агрессивных условиях среды при низких температурах от -60 до +125.
Процессоры P1 и R1 — это первые представители мультиклеточной архитектуры. Нельзя сказать, что это демонстрация идеальной реализации разработанной концепции (у нас имеется огромный простор для роста в снижении энергопотребления, увеличении производительности и дополнении архитектуры), но это процессоры с которыми можно работать и получать на их основе готовые устройства в различных областях применения.
Очень сложно догнать кого-то и перегнать, если ты идешь по тому же пути и встречаешь те же преграды, которые необходимо преодолевать, изобретая сложные конструкции и в которые приходится упираться. Можно попытаться найти другой путь, зная опыт преград и историю трудностей с которыми столкнулись другие.
И кто сказал, что архитектура ядра ARM — это идеал?
Сразу замечу, что ошибки имеются и в наших процессорах и мы их исправляем, делаем пути обхода.Наши ошибки мы обычно указываем сразу в документации на процессор. Но я думаю в дальнейшем будет тоже отдельный документ(сейчас документацию приводим в полноценный вид по R1).
Так вот приведу первые попавшиеся примеры errata на Миландр, чтобы не было ощущения, что скопировав Вы получите идеал:
milandr.ru/uploads/doc_img/production/spec_seriya_1986BE9x_errata.pdf
milandr.ru/uploads/doc_img/production/spec_1986BE3_errata.pdf
Судя по первым ошибкам в этих документах Ваш танк может начать сначала стрелять дальше, чем планировалось, а потом и из всех орудий(врагу мало не покажется, главное чтобы не прилетело по своим).
P.S. Для того, чтобы начать работать с процессором R1 не нужно много всего изучать. Скоро будет процесс обучения нового поколения начиная со школы и продолжая Вузом. К Вам на предприятие придут специалисты уже обученные работать на отечественном процессоре.
Мы именно так сейчас и развиваемся только на средства заинтересованных заказчиков. Госзаказов у нас пока тоже нет, у нас инициативная разработка.
Если бы у нас еще были государственные средства, то мы бы сейчас делали ускоритель с большим количеством клеток, сделали бы надежный радстойкий процессор и компилятор был бы готов.