Сообщество

В LLVM используется SSA представление, которое должно очень сильно повысить скорость оптимизации и следовательно компиляции.
Я так понял, что у разработчиков компилятора для Мультиклета с данным форматом представления возникли трудности. Я пока не понял какие.
Наверно это касается PHI-функций, о которых проскальзывали комментарии в других ветках.
Я тогда точно не знал, что это за функции такие и решил разобраться, сейчас вроде понял и не вижу никаких проблем с ними.

Поэтому, если проблемы с ними ещё есть, то хотелось бы попробовать помочь советом.
Вообщем приведите короткий пример кода на LLVM ассемблере с указанием проблемных мест, и если я буду знать, как избавится от проблем, то дам совет.
Конечно я пока не знаю, как работать с генераторами LLVM и речь будет идти о непосредственной компиляции байткода LLVM.

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

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

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

Я просто хотел помочь советом по PHI-функциям в байт-коде LLVM, так как не увидел там совсем ничего сложного для вашей архитектуры.
Точно также не увидел никаких проблем с SSA представлением -- по-моему в таком виде только одни преимущества.
И так же в байт-коде LLVM я не заметил никаких привязок ни к регистрам, ни к флагам процессора, т.е. его легко можно скомпилировать под ваши буферы тегов.
Конечно я могу ошибаться и поэтому попросил пример и тогда бы стало видно, смог бы я вам помочь или нет. Может вы и сами уже разобрались.

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

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

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

Стоп, так Вы же свою систему суперкомпиляции. А теперь перешли на LLVM? Я правильно понял?

Произошла смена акцентов. Если раньше на первом плане была работа по своему компилятору, то сейчас она ушла на второй план, а поставлена задача достаточно оперативно (до конца октября т.г.) сделать gcc/llvm-mc и посмотреть, что можно получить на Multiclet R1 с оптимизациями. Смена направления связана с тем, что пробные оптимизации имеющегося компилятора lcc-mc не дали нужного результата по coremark, поэтому принято решение заниматься оптимизацией по более перспективному (в смысле общепринятости) направлению gcc/llvm-mc.

overclocker wrote:

Стоп, так Вы же свою систему суперкомпиляции. А теперь перешли на LLVM? Я правильно понял?

Да, мы перешли к LLVM. Сейчас есть работающий компилятор на LCC. И мы пишем компилятор на LLVM.

Наткнулся на статью: http://www.dataved.ru/2011/06/llvm-autoparallelizer.html
В ней написано про проект, который применяет дополнительные оптимизации к биткоду LLVM и производит автоматическое распараллеливание кода, т.е. в результате должно получаться примерно тоже самое, что будет при использовании OpenMP.
Ссылка на сам проект: http://polly.llvm.org/
Не знаю, какого качества получается оптимизация, но в будущем можете поэкспериментировать с этим на многоклеточных процессорах, когда LLVM портируете.
Вообщем может пригодиться.

Спасибо, обязательно посмотрим.

Я не понял, вы делает обоих ЛЛВМ и ГЦЦ? Или делаете ЛЛВМ заднюю част для железо а преднюю част ГЦЦ для язик Си? Что-то как драгон ег? Кланг не у дел?

gnufreex wrote:

Я не понял, вы делает обоих ЛЛВМ и ГЦЦ? Или делаете ЛЛВМ заднюю част для железо а преднюю част ГЦЦ для язик Си? Что-то как драгон ег? Кланг не у дел?

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

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

GCC они не делают и нет смысла одновременно заниматься и GCC, и LLVM. Надо выбирать что-то одно из этого.

Yaisis wrote:

GCC они не делают и нет смысла одновременно заниматься и GCC, и LLVM. Надо выбирать что-то одно из этого.

выбрали правильно.

(потирает руки в ожидании FreeBSD 10 на Мультиклете)

Нам сначала MMU и т.п. плюшки нужно заиметь.

Через 3 дня ровно месяц как пропал Крафтер, нас даже с НГ не поздравили, а других активных у вас вроде как и нет. Сколько у вас человек в компании трудится?

Да, что-то как-то всё затихло...

Господа, у нас нет пока соответствующей замены Крафтеру по работе с форумом, все погружены в текущие проекты. LLVM в стадии близящегося самого, самого первого теста по кормарк, прочие успехи появляются на сайте в Технической документации и ПО. Форум, конечно, читаем, но дискуссии пока не удается поддержать... Особо интересуемся заказчиками на Multiclet R1 в малом корпусе bga 17x17, причем хотим сделать сразу СвК с флешкой на 2 мб.

micron_multiclet wrote:

Особо интересуемся заказчиками на Multiclet R1 в малом корпусе bga 17x17, причем хотим сделать сразу СвК с флешкой на 2 мб.

С флешкой было бы здорово. А ещё какие-то корпуса планируются?

Еще будет CQFP 256, видимо, к лету

micron_multiclet wrote:

Господа, у нас нет пока соответствующей замены Крафтеру по работе с форумом

А где он сам ?
Или он тоже занят чем-то другим ?

Написали бы на форум, что обновилось сегодня в инструментальных средствах и как там ЛЛВМ?

VaalKIA wrote:

Написали бы на форум, что обновилось сегодня в инструментальных средствах и как там ЛЛВМ?

Разработка LLVM backend'а продолжается, хотя и не так быстро как хотелось (или планировалось).
Сейчас стоит задача написать Register Allocator для Мультиклета, так как кроме предоставляемого LLVM Fast Allocator'а никакой другой нам не подходит.
Не подходят из-за коммутатора и параграфов, так как ячейки коммутатора, в которых хранятся результаты инструкций, не являются обычными регистрами.
Предоставляемый LLVM Fast Allocator производит избыточный и неоптимальный код.
Хотя с его использованием мы и получили coremark (в качестве frontend'а использовался clang для i386), который по сравнению с текущим компилятором C89 (lcc) получился лучше.

Что касается обновлений в инструментальных средствах, то там были доработаны ассемблер и компилятор C89 (незначительно) для обхода найденных некоторых аппаратных ошибок процессора R1, а также исправлены ошибки в ассемблере, редакторе связей, функциональной модели, которые были выявлены при компиляции coremark с использованием LLVM.

Прекрасно, что дело движется, кстати, обратите внимание вот на этот комментарий: https://habrahabr.ru/post/271905/#comment_8672683
Думаю, что ему был бы интересен Мультиклет даже просто в контексте общения и из этого бы вышло что-нибудь полезное.

Судя по последней публикации человек приходит постепенно к идее Мультиклета https://habrahabr.ru/post/278575/. Эх, плохо, что когда работал в Мультиклете не успел сделать анимацию с простой демонстрацией как всё работает, но зато есть много статей на Хабре, которые можно показать этому человеку и он быстро разберется в теме, может чем-то и поможет. Хотя если текущему разработчику компилятора дать еще немного времени, то он его доведет до логического конца, учитывая, что он написал ассемблер, линкер, редактор связей, конвертер, ПО для Key_P1, загрузчик и много другого софта, который работает как и планировалось.

про Coremark можно поподробнее? каков результат?

На данный момент достигнутый на llvm coremark = 49, работа продолжается, хотелось бы довести до 100, после чего выложить в открытый доступ.