llvm исторически это виртуальная машина (сейчас llvm никак не расшифровывается, раньше это была виртуальная машина). Возможно, тот виртуальный risc-процессор, который используется в llvm, слишком сильно отличается от vliw, поэтому использование llvm нерационально, слишком много переделывать.

но я так, мимо проходил.

Немного похоже на брехню, потому что поддержка ia64 в llvm таки есть, а значит vliw запилить вполне можно. Плюс, в llvm можно плагинами добавлять свои трансформации кода.

Я считаю, что они не стали использовать llvm потому что в нём сообщения об ошибках не на русском и не в koi8r, как в их компиляторе. saahriktu подтвердит что это самое важное.

Они же вроде делали, или уже отказались?

В этой презентации мцст есть упоминания об LLVM бэкэнде(7, 20 и 25 страница): http://www.mcst.ru/files/5a71da/3c0cd8/506512/000000/analiz_pokazateley_platformy_elbrus_s_uchetom_perenosa_prilozheniy_i_ispolzovaniya_dostupnogo_periferiynogo_oborudovaniya.pdf

В этой презентации альт линуксовцев тоже есть упоминия(11 страница): https://osday.ru/presentations/savchenko.pdf

Ну вообще они и GCC адаптировать пытаются, и LLVM. Но эти компиляторы (части компиляторов в случае с LLVM) плохо заточены под архитектуру Эльбрусов. alexanius об этом писал вот например GCC для «Эльбруса» (комментарий) Представлены ПК на базе Эльбрус-8С (комментарий)

Опять же, заточить gcc или llvm под VLIW невозможно - они будут генерировать тормозной код, и есть опасения что обвинять в этом будут не компилятор, а процессор.

Действительно llvm так не подходит для vliw что даже амд написала там свой бекенд для своих vliw карт

Спасибо за ссылки!

В общем основная проблема кмк это секретность и вытекающее отсутствие открытой документации.

LLVM уже много лет прекрасно работает для Hexagon DSP компании Qualcomm (которые тоже VLIW). Вот древнее видео с LLVM-кона: https://www.youtube.com/watch?v=MefebRh34cI , а от сам бэкэнд: https://github.com/llvm-mirror/llvm/tree/master/lib/Target/Hexagon

Также разработан как минимум один бэкэнд для Xtensa (DSP фирмы Tensillica): http://lists.llvm.org/pipermail/llvm-dev/2019-March/130796.html

потому что поддержка ia64 в llvm таки есть

А в каком оно состоянии? Потому как в основном дереве его нет.

Tilera для своего TileGX пилила llvm.

Грохнули за смертью ia64 как архитектуры)

Сорри, поддержка была. Её выпили потому что ia64 немного сдох.

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

У нас нет срочной необходимости делать бэкенд, т.к. с точки зрения трудозатрат/производительности итогового кода оно нам поможет примерно ничем. Но взаимодействие с llvm нас интересует. Поэтому разрабатывается конвертер из llvm ir в представление нашего компилятора. сейчас он уже стабильно работает для языка C, остальные в процессе разработки/толадки.

Сделать полноценный бэкенд для llvm было бы интересно, но даже минимальная его реализация оценивается (мной) в 0.5 человеко-лет. Это оптимистичная оценка. У нас таких ресурсов нет, хотя мне бы очень хотелось получить такое задание.

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

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

Возможно у них просто не было собственного отлаженного компилятора

Звучит так, будто тот проприетарный хлам, которым сейчас вы собираете софт под Эльбрус, хоть чем-то лучше окромя закрытости (чтоб никто не украл секреты Родины).

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

Ахахаха,но ты можешь и лучше набросить, а то как аноним какой-то. Попытайся, я верю в тебя

УМЦСТ компилятор часть системы. Потому что никто больше не осилил такую архитектуру процессора. Есть подобия vliw. Когда нужные части компилятора перепишут на ассемблере производительность подскачет в разы. Потому что архитектура состоит не из 500 мелких слабых ядер, а из крупных, выполняющих несколько инструкций за такт. Это почти как avx, только на всю систему, а не отдельно 32-битные ядра, отдельно sse для 64-битной деятельности и отдельно avx-avx512 для больших вычислений, которые еще надо специально реализовать в коде.

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

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

Возможно ещё тысяча причин, гадать о которых нет смысла.

А гадать не нужно, в видео по ссылке объяснены причины перехода на LLVM: гибкость, простота разработки и хорошая поддержка коммуны. Я бы добавил ещё две, о которых в презентациях не говорят: простота покупки новых рабов^W разработчиков и corporate-friendly лицензия.

Возможно у них просто не было собственного отлаженного компилятора

У них долгие годы до этого был обычный GCC-тулчейн.

Это их утверждение, так что думаю они справятся с увеличением производительности кода. И математические методы применят тоже.

Тем не менее я не знаю почему и зачем они сделали именно так, а не иначе.

Бегло пройдя по треду от xtensa легко заметить что потребители заинтересован во фрондендах нацеленных на llvm (обозначены tiny-go и swift)

легко заметить что потребители заинтересован во фрондендах нацеленных на llvm

Не слушай хипстеров, нормальные DSP-инженеры до сих пор норовят на асме пописАть и нос воротят даже от Си.

Одно другого не исключает

Это их утверждение, так что думаю они справятся с увеличением производительности кода. И математические методы применят тоже.

Ссылочку можно?

Кто ж ее так вспомнит? Только если шерстить по поводу эльбрусов и ассемблера в одной статье.

Да врут он всё. Просто хотят как можно больше запроприетарить платформу.

Наес манявры фантазёра.

Да. Соглашусь.

Не подскачет. А вот просядет - наверняка.

И

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

Всё верно. Если особо много, долго и ненужно извращаться с ассемблерными вставками в том же Си, то можно на фиг убить всю оптимизацию в части global register allocation. И связанные с нею.

Так что, применение без мозгов всякого рода «оптимизаций» на уровне исходного кода, вопрос спорный. Как и всё, что делается именно без мозгов.

По теме. Об элбрусовцах ничего не скажу, но со своей колокольни откровенно не понимаю чего все так с этим llvm носятся. Он что, в отличие от gcc, код за программиста пишет? Сам? С чего такая паника-то?

но со своей колокольни откровенно не понимаю чего все так с этим llvm носятся.

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

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

Не скажу от кого инсайд, но LLVM на Эльбрусах будет, хоть в полуживом виде, но будет. Пусть не максимально эффективным, но растишка и сисярп, goвняшка - просто будет собираться и работать код, эффективность видимо пока в расчет не будет браться

Это-то понятно...

Если про поддержку энного числа ЯП в llvm. Тут, правда, несколько иной вопрос возникает – а нужны ли там они, эти новые веяния? Тут, по-моему, сам вычислительный комплекс как минимум «слегка не для этого».

Если на каком-нибудь «комплексе ПВО» сишный код понятен и смотрится как родной, то вот код на растишке, сисярпе или гошечке вызывает дикие сомнения. Вместо «комплекса ПВО» можно подставить любой вычислительный комплекс аналогичного (оборонного, например) назначения.

Так ли нужно следовать всем без исключения новомодным веяниям? А то веяния они веяния и есть – сегодня дует туда, завтра сюда, послезавтра ещё куда, а задачи как не были решены, так и не решаются.

Боюсь, что вот этот тезис:

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

И тезис ниже:

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

Как минимум, спорны. Учитывая изначальное назначение данного комплекса, согласно моего глубочайшего IMHO (IMHO здесь ни что иное как «имею мнение, хрен оспоришь») не нужно подпускать толпы «разработчиков» к такого рода комплексам. Достаточно декларируемой POSIX совместимости на уровне исходных кодов, т.е., есть сырцы, скомпильнулись, запустились, работает. А специфичными вещами пусть занимаются специально обученные, просветлённые люди. Иначе это всё опять рискует выродится в колхоз «70 лет без урожая», он же «месть Ильича».

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

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

Ну полгода это не такие уж большие ресурсы. А уж в рамках нашего «доблестного» ВПК это вообще ни о чем. Там десятки человеко-лет выкидываются на ветер. Это, конечно, не упрек какой-то, тем более вам. За оценку затрат - спасибо.

Сделать такой бекенд на мой взгляд очень будет полезно с точки зрения сообщества, которое может появится вокруг Эльбруса. Это трудно переоценить, на мой взгляд.

Правильно я понимаю, что конвертер llvm.ir to Elbrus.ir будет работать только в рамках какого-то набора языков? И взять llvm.ir для произвольного языка не получится?

Спорно сие...

Ну растишку-то как раз продвигают как «сверхнадёжную замену Си», так что в этом пункте смысл может быть.

Пусть тогда ядро (общеупотребительное, как в Linux) на нём запилят, тогда и поговорим. Пока же оно… Ну так, «продвигают». Завтра надоест «двигать», забросят и схватятся за что-то очередное, новое и блестящее… Сколько этих языков было? То одно, то другое провозглашается an mass нашим очередным всем.

Есть только одна проблема. Пока народ «борется за чистоту рядов» и «провозглашает», сишники как сидели-пилили код, так и сидят-пилят. Да, я сишник, я знаю о чём говорю. ;)

Плюс решение задачи портирования какой-то нужной прикладнухи (современный фаерфокс, про что уже писали).

А тут вообще не соглашусь. Если взять ту же GTK+ (почему я сам на GTK и GNOMEчике и сижу), то там внутри ни что иное как сишечка. Всё остальное – это биндинги к современным и не очень языкам. Правда, в gtkmm (биндинг к С++) я где-то встречал комментарий типа «если ни фига не выходит, то забейте на gtkmm и юзайте стандартную сишную либу для этого», но это уже мелочи…

Браузер вполне себе поднимается на WebKitGTK том же, там ещё и его свойствами рулить можно довольно серьёзно. Огнелис тут вообще не нужен, если честно. Хотя, симитировать его поведение в сети можно, чтобы не шокировать сервера своим кастомным юзер агентом и не возиться с отрисовкой.

В общем, работает.

Сделать такой бекенд на мой взгляд очень будет полезно с точки зрения сообщества, которое может появится вокруг Эльбруса.

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

Об элбрусовцах ничего не скажу, но со своей колокольни откровенно не понимаю чего все так с этим llvm носятся. Он что, в отличие от gcc, код за программиста пишет? Сам? С чего такая паника-то?

Паники то нет никакой, с чего бы это? Просто llvm/gcc это две хорошо развитые и более-менее документированные инфраструктуры для разработки инструментов для новых языков. А Эльбрус пилит во многом свое. Это уменьшает вероятность адаптации Эльбрусовской экосистемы сообществом. А роль сообщества в наше время переоценить трудно. Вот и есть вопрос, не хотят ли в МЦСТ отойти от порочной практики засекречивания всего и вся к нормальной практике, отвечающей современной реальности.

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

This

А будет ли возможность добавить туда другие языки? Пусть тоже не в максимально эффективном виде. Что инсайдер скажет по этому поводу?

Если на каком-нибудь «комплексе ПВО» сишный код понятен и смотрится как родной, то вот код на растишке, сисярпе или гошечке вызывает дикие сомнения.

А чем «комплекс ПВО» особенный, что для него только сишечка подходит? Нормально там и Раст, и шарп, и Go будут смотреться.

Так ли нужно следовать всем без исключения новомодным веяниям?

Нет, за веяниями следовать не нужно это точно. Использовать Раст, Шарп, Гоу и прочее нужно только если это оправдано.

А специфичными вещами пусть занимаются специально обученные, просветлённые люди.

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

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

Согласен, но с чего то же надо начинать.

Мой коммент выше.

А роль сообщества в наше время переоценить трудно.

Дополню только. Про «роль сообщества». Не сильно я в неё верю, если честно. Даже уже пример где-то в форуме приводил. Насчёт «роли». Помните такой INOI R7? Да, мобильник на Sailfish OS RUS. Так вот. Есть он у меня, я даже себе набор софта частоупотребительного под него сгондобил на Qt + C++. Только вот штука в чём. Казалось бы, Linux, Qt, QML/C++, ну всё же как мы любим! А в Jolla-магазине всего пара наших российских контор представлена и то не дофига софта от них. А так-то в основоном, кто угодно, но не наши.

Ну там ещё в последнее время добавились какие-то клоуны с каким-то софтом под «Приват-Банк». Да, крайне распространён в России, там (не смотрел, если честно) какой-то калькулятор типа или конвертер чего-то куда-то.

Ну так-то и всё… Вот и вся «роль сообщества», которая по-моему, весьма серьёзно переоценивается. Да, считается что оно как бы есть, но… толку почти ноль.

Просто llvm/gcc это две хорошо развитые и более-менее документированные инфраструктуры для разработки инструментов для новых языков.

Тут недавно обсуждали где-то llvm vs. gcc в части отладчиков. Инфрастуктура-то да, но вот техническая зрелость llvm вызывает вопросы. Равно как и то, что это спонсируется коммерсантами. Что будет, если перестанут, не ясно. Я бы не стал вкладывать деньги в llvm.

А Эльбрус пилит во многом свое.

Если на базе GCC, то молодцы. Там им надо было бы RTL расширять плагинами. Если всё совсем-совсем своё, то… Ну, в общем, посмотрим.

Про INOI R7 это вы хороший пример привели - что будет с Эльбрусом, если вокруг не будет сообщества.

Про llvm vs gcc - это отдельная тема. На мой взгляд, у llvm меньше порог входа чем у gcc. По остальному своего мнения не имею.

Что, простите?!? =)))

А чем «комплекс ПВО» особенный, что для него только сишечка подходит? Нормально там и Раст, и шарп, и Go будут смотреться.

Т.е., Вы решили сравнить производительность и подходы в программировании «портируемого ассемблера», имеющего чёткие и однозначные стандарты и рекомендации по безопасности, от того же SERT (чисто примера ради) и… И непонятно что? «Какие-то» языки программирования? Скажите, а вот на той же Cisco ASA в некоторых моделях, использованы Целероны от 1600 и выше, там тоже нормальненько будет смотреться растишечка или сисярпик? Интересно – чего же в цисках эти идиоты не пишут свою iOS на растишечке? Вот дебилы, и не говорите! =)))

Иначе эти люди выродятся в то, что мы сейчас имеем во многих предприятиях ВПК.

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

Это (по моему опыту) ребятки, закончившие соотв. ВУЗ и имеющие (как правило) определённый срок службы в «войсках». Там норммально и С и С++ и даже, о ужас! bash’ик. Учить думать правильно ненужно.

Остальные? Остальные в раст, го, питон, … да куда угодно (ну, думаю, Вы меня поняли).

Ну да...

Про INOI R7 это вы хороший пример привели - что будет с Эльбрусом, если вокруг не будет сообщества.

А откуда ему взяться-то? Там же в качестве среды разработки – QtCreator (совсекретно?), там же в качестве среды для сборки и эмулятора совсекретный же Mer… Там даже всё не собрано в одну кучу и нет (даже!) инсталлера на великом и могучем… Это же всё жутко секретно и непознаваемо?

Да нет. Это просто «сообщество» такое. Уточнять какое не будем, но я скажу что на букву «х» и не подумайте что «хорошее». И это реалии. К сожалению.

эффективность видимо пока в расчет не будет браться

Пакетировать инструкции будете?

Равно как и то, что это спонсируется коммерсантами.

Все мантанеры GCC работают в корпорациях.

Задачи разные бывают, и железо тоже. А вы пытаетесь под одну конкретную дудку все заставить плясать, что говорит о вашей предвзятости. Раст по производительности не хуже сишечки будет. Сишарп да, уступает тут, но есть еще и информационно-расчетные задачи где сишарп вполне может использоваться. Не целероном одним все ограничивается.

Ребята же, закончившие соотв. ВУЗ и имеющие необходимые навыки скорее уйдут на более хлебные месте, где и задачи поинтереснее. За 90ые годы наш ВПК деградировал очень даже сильно. И самое главное, что нарушилась система преемственности. Я видел какой отстой наш ВПК поставляет в войска и продолжает это делать (исключения есть, конечно). Единственно, что меня успокаивает в этом области, так это то, что у американцев - точно такие же процессы. Все передовые технологии давным давно уже на гражданке.

Ну так и вокруг Эльбруса вообще тогда ничего не появится, если нет даже того, что есть для INNO R7

У Go свой кодогенератор жи вроде?

Не в курсе про Go, но может это просто один из кодогенераторов использует LLVM?

У C#, который здесь тоже упоминался, например, только Mono использует LLVM, .NET Core не использует LLVM…

Если взять ту же GTK+ (почему я сам на GTK и GNOMEчике и сижу), то там внутри ни что иное как сишечка. Всё остальное – это биндинги к современным и не очень языкам.

Спрошу тогда, хоть это уже ещё один шаг в сторону офтопа. А со строками как работаешь? GString? А если нужно перекодировкой заниматься? iconv?

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