Сообщество

m.vlasov_multiclet wrote:

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

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

• запуск бекенда для получения ассемблерного файла, на входе файл с промежуточным представлением LLVM IR в текстовом виде
  [...]

• запуск бекенда для получения ассемблерного файла, на входе файл с промежуточным представлением LLVM IR в виде двоичного биткода
  [...]

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

m.vlasov_multiclet wrote:

Добрый день, всем неравнодушным к проектам отечественной микроэлектроники в целом и к мультиклеточным процессорам в частности.

...

компилятор не учитывает всех возможных аппаратных ошибок процессора Multiclet R1 (вообще учёт и обход таких ошибок хочется сделать на стороне ассемблера,

Судя по тому, как вы лихо слили три ветки в одну, работа с сайтом у вас - это раздел провинившихся или излишне активных. Я просто оставлю это здесь (особенно для тех, кто бьёт себя в грудь, что без ответа ничего тут не остаётся):
http://multiclet.com/community/boards/3/topics/1633

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

VaalKIA wrote:

Судя по тому, как вы лихо слили три ветки в одну, работа с сайтом у вас - это раздел провинившихся или излишне активных.

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

28.06.2016 исправлены ошибки в ассемблере, редакторе связей, а также расширен функционал компилятора на базе LLVM.

По новой традиции, уже готова статья на Хабре, или запал прошёл и "это место заколдованно и получаются только жигули"?

"по новой традиции"))) хотелось бы, но все не так быстро делается... однако, тема и примерное содержание ближайшей новой статьи понятны, осталось только наработать материал

Я её ещё не пропустил?

Нет, нет, готовим материал

Статья на habrahabr.ru Компилятор LLVM для MultiClet: бенчмарк WhetStone

По результатам статьи, напрашивается очень интересный вопрос: насколько можно поднять частоту мультиклета, на техпроцессе в 180нм?
цитирую:

0,18 микрон, которым располагает Intel, не в состоянии работать на частотах, существенно превышающих 1 гигагерц. Предел данного технологического процесса находится где-то в районе 1,1–1,2 ГГц — именно поэтому, из-за недостаточной стабильности работы в предельных режимах, и был отозван опрометчиво выброшенный на рынок Pentium III Coppermine 1,13 ГГц.

Допустимая тактовая частота процессора, при заданной топонорме, определяется количеством блоков логических элементов на линии. Число блоков может быть уменьшено:
1) Конвееризацией вычислений.
2) Оптимизациями на этапе синтеза.
3) Применением специальных «быстрых» библиотек при синтезе.

Поскольку первые два пункта требуют больших трудозатрат, при разработке процессора R1 вопросы оптимизаций на этапе синтеза не поднимались (все было синтезировано стандартным САПРовским синтезатором, что не очень эффективно), а оптимизировались и конвееризировались только те линии, длинна которых не позволяла выйти на частоту 100 МГц.

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

По распоряжению руководства компании ОАО "Мултиклет" доводим до сведения всех заинтересованных в разработке компилятора на базе фреймворка LLVM об исправлении ошибки в LibCallSimplifier разработчиками llvm, которая была найдена разработчиками ОАО "Мултиклет". Подробности по ссылке.

m.vlasov_multiclet wrote:

Доводим до сведения всех заинтересованных в разработке компилятора на базе фреймворка LLVM об оперативном исправлении в LibCallSimplifier разработчиками llvm ошибки, найденной разработчиками ОАО "Мультиклет". Подробности по ссылке. Продвижение разработки компилятора llvm для Multiclet R1 по направлению к бэта версии успешно продолжается.

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

1. фреймворк LLVM обновлён до версии 3.9;
2. исправлены найденные ошибки;
3. реализована обработка инструкций промежуточного представления LLVM JumpTable и BlockAddress;
4. реализована неполная поддержка позиционно-независимого кода;
5. реализована поддержка инструкций преобразования:
• double -> float,
• float -> double,
• float -> int32_t,
• float -> uint32_t,
• float -> int64_t,
• float -> uint32_t,
• double -> int32_t,
• double -> uint32_t,
• double -> int64_t,
• double -> uint32_t,
• int32_t -> float,
• int32_t -> double,
• uint32_t -> float,
• uint32_t -> double,
• int64_t -> float,
• int64_t -> double,
• uint64_t -> float,
• uint64_t -> double.

1. добавлена обработка llvm инструкций cttz, ctlz и ctpop;
2. добавлена обработка llvm инструкций smin, umin, smax, umax для типа i32, а также fminnan, fminnum, fmaxnan, fmaxnum для типов f32 и f64;
3. небольшие оптимизации, приводящие к генерации более компактного выходного ассемблерного кода при использовании 64-х разрядной арифметики;
4. добавлены новые функции в библиотеку librt.a.

Версия компилятора изменена с альфа версии до бета.

m.vlasov_multiclet wrote:

Версия компилятора изменена с альфа версии до бета.

Конечно, пока нет MMU очень много проектов отсекается вместе с ОС. Но у меня вопрос по ПО, какие распространённые библиотеки или проекты получается компилировать, то есть хватает реализованных возможностей компилятора?
Фактически сфера применения процессора очень тесно коррелирует с ПО, которое под этот процессор используется, так можно выбирать векторы развития усиливая в первую очередь те или иные возможности процессора. То есть вы должны вести каталог любого ПО, которое удалось скомпилировать и использовать. Конечно, сами вы объять необъятное не сможете, зато можно сделать каталог библиотек, вроде zlib и тестов и активно работать с сообществом собирая и пополняя информацию. Попутно выясните попали ли вы в ту нишу, которую планировали.

Под елочку):
В рамках работ по компилятору LLVM для нового микропроцессора MultiClet S1 (майнинговый проект RMC) перевели существующий компилятор для Multiclet R1 в версию LLVM 5.0 (ранее была реализована версия 3.8). Без каких-либо дополнительных оптимизаций тест кормарк улучшился на 20%))) это самый "тяжелый" тест для компиляторов мультиклеточной архитектуры, поскольку на последовательных вычислениях никак не используется преимущество мультиклетов в естественном распараллеливании вычислений.

))) даже 28%

Starting coremark on MultiСlet (200 iterations).
4.2.1 Compatible Clang 5.0.0 (tags/RELEASE_500/final)
Optimization flags: -O3
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 33859324
Total time (secs): 42
Iterations/Sec : 4
Iterations : 200
Compiler version : 4.2.1 Compatible Clang 5.0.0 (tags/RELEASE_500/final)
Compiler flags : -O3
Memory location : INNER
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x382f
Correct operation validated. See readme.txt for run and reporting rules.
DONE

Starting coremark on MultiСlet (200 iterations).
4.2.1 Compatible Clang 3.9.0 (tags/RELEASE_390/final)
Optimization flags: -O3
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 43663218
Total time (secs): 54
Iterations/Sec : 3
Iterations : 200
Compiler version : 4.2.1 Compatible Clang 3.9.0 (tags/RELEASE_390/final)
Compiler flags : -O3
Memory location : INNER
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x382f
Correct operation validated. See readme.txt for run and reporting rules.
DONE

да, шланг ожидаемо оказался очень хорошим выбором.

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

ну и да, не наступайте на грабельки типа meltdown/spectre :)

tyrannozaur wrote:

ну и да, не наступайте на грабельки типа meltdown/spectre :)

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

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

я в более общем смысле. если сразу не думать за безопасность вообще никак, это бывает больно потом...

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

Процессор это всего лишь числодробилка

не совсем.

безопасность обеспечивается на уровне операционной системы

безопасность начинается на уровне архитектуры проца.

tyrannozaur wrote:

безопасность обеспечивается на уровне операционной системы

безопасность начинается на уровне архитектуры проца.

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

VaalKIA wrote:

tyrannozaur wrote:

безопасность обеспечивается на уровне операционной системы

безопасность начинается на уровне архитектуры проца.

Безпопасность начинается на уровне ОС.

На уровне архитектуры она начинается.
И на уровне ОС тоже должна быть.

Насколько эффективно можно её реализовать, зависит от проца и точка.

И этим вы сами сказали, что "безопасность начинается на уровне архитектуры проца."

Если архитектура позволяет, то никакая ОС не спасёт.