Почему llvm не подходит для Эльбруса?

Просто более-менее серьёзное манипулирование классическими сишными char* в прикладных программах — это страх и ненависть и даже не в Лас-Вегасе.

Там всё просто, всего две функции.

Первая: g_locale_to_utf8

char* utf8_str = g_locale_to_utf8 (str, (gssize) -1, NULL, NULL, NULL);

Считал scanf или fgets строку, которая не UTF-8, сделай её UTF-8, в программе всегда UTF-8. Константные строки тоже utf-8

Вторая: g_convert, если нужно нашу строку вывести в консоль или сохранить файл не в UTF-8.

char* locale_str = g_convert (str, (gssize)strlen(str), encoding_str/*"CP1251"*/, "UTF-8",  NULL, NULL, &_inner_error0_);

Вот всего две функции чтобы не страдать, ничего сложного.

А вообще вот документация: https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion

Отвечу всем сразу (если что забыл - пишите, дополню)

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

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

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

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

5. Про конвертер. Для каждого языка используется своё подмножество конструкций и шаблонов llvm ir. Даже между C и C++ с точки зрения представления компилятора лежит огромная пропасть (те кто пытался реализовать исключения отлично понимают о чём я). Соответственно, в процессе конвертации представления отлаживается именно тачасть, которая применяется по факту. Фронтенды других языков может будут работать, а может и нет - как повезёт.

6. Я с ВПК, конечно, не работал, но что-то сомневаюсь что там смогут выделить пол года на непонятную несрочную работу с непонятным результатом. Мы не сверхкорпорация чтобы так разбрасываться людьми, поэтому этих пол года у нас просто нет.

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

Ух ты… а в Intel-то и не знают, что в их icc «проприетарный хлам» используется.

Мда… вот у тебя брехня от первого до последнего слова.

Эльбрус - не только и не столько ВПК, хотя это важная часть.

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

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

Это верно. Именно по причине поддержки других языков нужно развивать инфраструктуру. Возможность писать на удобном для разработчика языке это важно. Иначе нужно будет компенсировать это другими моментами. А с деньгами для линейных сотрудников в ВПК все печально. Так что это достаточно серьезный момент. Но это, так сказать, с государственной точки зрения. С точки зрения МЦСТ это уже не так важно, согласен.

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

Не уточните что за точка?

Фронтенды других языков может будут работать, а может и нет - как повезёт.

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

По п.6 можно многое написать, но это уже будет не по теме.

Отдельно хочу сказать вам большое спасибо, что делитесь с нами хоть какой-то информацией!

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

Вот с этого места поподробнее.

Рабочие станции - а в чем конкретно Эльбрус лучше каких-нибудь дешевых компов на атоме? А Raspberry Pi?

Суперькомпьютеры - опять таки, чем это лучше процессоров от Intel и AMD?

Встраиваемые системы - понятие растяжимое. Есть встраиваемые системы уровня ардуины c 8-битной атмегой, есть встраиваемые системы уровня STM32F0, есть что-то более серьезное, типа той же Raspberry Pi с MMU, 4 гигами ОЗУ и полноценным Linux. Раз в эльбрусах есть какое-то MMU и работает полноценное ядро Linux, тут явно уровень Raspberry Pi. Материнку с Эльбрусом можно сделать в форм-факторе Raspberry Pi 4 с сопоставимым энергопотреблением и характеристиками?

Есть кстати какие-то DSP ядра ElCore - про них есть какая-то инфа? Или тоже все инструкции засекречены?

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

Буду. МЦСТ - АО. Если Вы посмотрите на ОКРы и контракты последних лет, то там не так много ВПКшных.

Не уточните что за точка?

Нет, не хочу сильно обнадёживать.

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

Не исключаю такой вариант.

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

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

Знают, потому свинтили на clang

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

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

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

P.S. Я один из разработчиков Stellarium’а и с удивлением обнаружил, что всё портирование его на Эльбрус заключалось в однострочнике, который просто выносил BOM из исходников - больше ничего править не пришлось. Сделали этот порт ребята из Альта.

Нет, не хочу сильно обнадёживать.

Предположу что вроде ptx?

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

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

Рабочие станции - а в чем конкретно Эльбрус лучше каких-нибудь дешевых компов на атоме? А Raspberry Pi?

Суперькомпьютеры - опять таки, чем это лучше процессоров от Intel и AMD?

Тем что не intel, не amd, не малина. Это отечественный производитель, санкционные риски меньше, архитектурно более защищены.

тут явно уровень Raspberry Pi. Материнку с Эльбрусом можно сделать в форм-факторе Raspberry Pi 4 с сопоставимым энергопотреблением и характеристиками?

У малины хуже с производительностью, но лучше с тепловыделением. Но да, по формату - ближе к ней. Например, я недавно вертел планшет на Эльбрус-1С+.

Есть кстати какие-то DSP ядра ElCore - про них есть какая-то инфа? Или тоже все инструкции засекречены?

От них уже давно как отказались, на сколько я знаю

Например, я недавно вертел планшет на Эльбрус-1С+

Я тоже его видел на одной конфе, видел и ноутбуки на Эльбрус-1С+. Э-1С+ это SoC, его планируют 4-ядерным сделать следующим шагом. В общем, всё хорошо у Эльбруса будет, я почему-то в этом уверен

Суперькомпьютеры - опять таки, чем это лучше процессоров от Intel и AMD?

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

Ядро-то есть, гугли Redox OS.

Тем что не intel, не amd, не малина. Это отечественный производитель, санкционные риски меньше, архитектурно более защищены.

Скажем так, если санкциями запретят поставку процессоров Intel и AMD, никакие Эльбрусы не спасут. Причины надеюсь очевидны - например на них не пойдет с адекватной скоростью x86-64-скомпилированный софт без исходников, не весь софт в исходниках под них можно будет собрать, операционные системы от MS актуальных версий там наверняка будут тормозить, если вообще запустятся (а пользователям они нужны), ну т.е. в условиях подобных санкций будет выгодней сидеть на старых процессорах, купленных в досанкционный период, пока они не сломаются.

Про архитектурную защищенность - спорный вопрос. Что касается раздельного стека для адресов возврата и для локальных переменных - это можно и на x86-64 организовать, придумав альтернативное ABI и пересобрав под него софт (ценой потери производительности). Про безопасный режим исполнения программ в Эльбрусах, когда например указателем на int нельзя прочитать указатель для double - тут много ньюансов: чтобы этот механизм использовался, надо переписывать софт, например заменять обычные malloc() некими malloc_float_only() и тогда если на память выделенную таким malloc попробовать читать/писать не через float* то должна происходить ошибка. Но помимо базовых типов char, float, int ... есть еще структуры - тут опять вопрос, работает ли этот механизм тегированной памяти со структурами, что вот только указателем на такую-то структуру можно такую-то область памяти читать/писать? Или там идет привязка указателя к диапазону адресов, скажем:

  const int *a_mem = malloc(sizeof(int)*100);
  if (a_mem = NULL)
    return ERROR;
  int *a_ptr {set_allowed_ptr_range (a_mem ... a_mem+sizeof(int)*100 )} = a_mem;

Кстати такие вещи можно тоже сделать программными костылями, для примера можно почитать про сандбокс в NaCl - https://sudonull.com/post/13359

Или безопасность достигается закрытостью системы команд т.е. попросту security through obscurity?

У малины хуже с производительностью, но лучше с тепловыделением. Но да, по формату - ближе к ней. Например, я недавно вертел планшет на Эльбрус-1С+.

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

ну вообще-то llvm компилирует vliw для r600

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

http://shop.irsural.ru/comp/catalog/computers/3079/product-285792.html?ymclid=15716604150606253855500002

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

актуальных

Ю а крэйзи, Данила!

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

Скажем так, если санкциями запретят поставку процессоров Intel и AMD, никакие Эльбрусы не спасут. Причины надеюсь очевидны - например на них не пойдет с адекватной скоростью x86-64-скомпилированный софт без исходников, не весь софт в исходниках под них можно будет собрать, операционные системы от MS актуальных версий там наверняка будут тормозить, если вообще запустятся (а пользователям они нужны), ну т.е. в условиях подобных санкций будет выгодней сидеть на старых процессорах, купленных в досанкционный период, пока они не сломаются.

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

Про архитектурную защищенность - спорный вопрос. Что касается раздельного стека для адресов возврата и для локальных переменных - это можно и на x86-64 организовать, придумав альтернативное ABI и пересобрав под него софт (ценой потери производительности).

А тут это по дефолту. Про всякие спектры и различные Intel ME я даже не говорю.

Про безопасный режим исполнения программ в Эльбрусах, когда например указателем на int нельзя прочитать указатель для double - тут много ньюансов: чтобы этот механизм использовался, надо переписывать софт

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

Ну... при таком соотношении цена/производительность их никто в здравом уме не купит при наличии альтернатив

Только то, что железа на котором можно порт запустить нет практически ни у кого.

С чего бы? Основной фичей их компиляторов как раз таки является вывод ошибок на русском языке в KOI8-R. Иначе я не понимаю, зачем они купили фронтенд от каких-то чуваков и делают всё сами вместо того чтобы взять LLVM.

санкционные риски меньше

С чего бы? Эльбрусы уже перестали в Тайване печатать?

Ну так тебе закуп интелов и амудей перекрыли. А альтернатив толком и нет. Китайцы до сих пор своего высокопроизводительного не делают, лонгсуны это мипсовое уныние.

на данный момент проблем с поддержкой стандартов особо нет

c++17 уже поддерживает?

Через год выйдет Qt 6, которая будет его требовать.

Военным на 90нм на ангстреме пекут/пекли. Дорого и медленно, зато целиком своё.

Ангстрем кстати обанкротился

Те Эльбрусы на 90нм для военных и эти, которые тут обсуждаются, это вроде как разные Эльбрусы, не?

Или микрон, не помню, не суть. Тех кто военным Эльбрусы печёт в любом случае «спасут», сам понимаешь

Примерно как Prescott и haswell Это разные интелы

У них один набор команд, в отличие от Эльбрусов. Я к тому, что есть Elbrus-90micro, который у военных и у которого SPARC вместо ISA. И есть Эльбрусы на E2K.

Не путай комплекс эльбрус-90микро и архитектуру. Хотя это сложно, да. Тем не менее, по слухам пекли именно старые Эльбрусы которые чипы.

alexanius возможно может этот вопрос чуть подробнее рассказать. Или не сможет, кто ж его знает что он может рассказать.

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

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

А вы попробуйте и удивитесь! Я попробовал, удивился.

Избранные теги: common lisp, haskell, rust

А вы попробуйте и удивитесь! Я попробовал, удивился.

После Хаскеля с Лиспом ты, может, и удивился, но только вот на фоне C раст в плане производительности ничем не может удивить, рассмешить только если.

Дурной какой! Не надо проецировать собственные комплексы на других.

Дурной какой! Не надо проецировать собственные комплексы на других.

Основной фичей их компиляторов как раз таки является вывод ошибок на русском языке в KOI8-R.

Пробовал их SDK и KOI8-R я там не увидел. Плохо смотрел?

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

Круто. Делать много лет проект, довести его до более-менее нормального рабочего состояния, а потом просто выкинуть на помойку все наработки только потому, что какой-то балбес со стороны ляпнул «это не модно, надо на LLVM»? Ну если ты такой спец и времени у тебя дохрена, то попробуй какой-нибудь PCC на LLVM перетащить.

Только то, что железа на котором можно порт запустить нет практически ни у кого.

Железо в продаже есть. Есть также удаленный доступ до машинок на Эльбрусах - это если действительно портированием заниматься, а не тыкать пальцем с брезгливым фиииии….

Появление сообщества - очень хорошо, и я надеюсь, оно когда-нибудь появится.

Какой сценарий появления сообщества? Пользователи ваших систем вряд ли являются энтузиастами-компьютерщиками.

Да и смысла нет. Если бы системы были массово доступны, или хотя бы легко доступны, можно было бы завлечь исследователей уязвимостей. Ну, тех, кто мечтает написать статью «We found vulnerabilities in Russian military CPUs!»

Пробовал их SDK и KOI8-R я там не увидел. Плохо смотрел?

Ага. У меня тут lcc-1.21.07.e2k-v3.3.14, в нём сообщения на русском 100% в KOI8-R. Могу выложить куда-нибудь, если ты мне настолько не веришь.

Делать много лет проект, довести его до более-менее нормального рабочего состояния, а потом просто выкинуть на помойку все наработки только потому, что какой-то балбес со стороны ляпнул «это не модно, надо на LLVM»?

https://en.wikipedia.org/wiki/Sunk_cost

Ух ты… а в Intel-то и не знают, что в их icc «проприетарный хлам» используется.

Мне просто интересно, как связаны icc от штеуда и lcc от MCST? Ты из-за корявых шревтов i и l не различаешь?

Мне просто интересно, как связаны icc от штеуда и lcc от MCST? Ты из-за корявых шревтов i и l не различаешь?

Фронтенд от Edison Design Group.

Да забей, чувак чрезмерно толст и не в теме совсем

Упс.. я думал, чуваки из штеуда свой родили таки.

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

P.S. Сейчас специально посмотрел твой профиль и всё сразу стало понятно. Поэтому… можешь считать эти вопросы риторическими….

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

Можно я тоже пару вопросов задам?

1. Какая последняя версия lcc на данный момент?
2. C++14, 17 есть?
3. Сообщения компилятора все так же koi8?