После шести месяцев разработки представлен релиз проекта LLVM 10.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52611
Фрактал, ты снова тут набрасываешь? У каждого своё понятие свободы :) Зато благодаря наличию разных лицнзий есть выбор. Это плохо?
>У каждого своё понятие свободы :)Работники министерств правды и любви с вами не согласны.
Это не тот фрактал, который некоторое время назад на лоре чудил?
А разве есть другой? Его оттуда выгнали, теперь тут чудит.
Не знаю выгнали его с ЛОРа или нет, но того лысого из ПиВас-Студио точно выгнали, за спам. Теперь он умные статьи на Хабре пишет.
Не выгнали, а сам ушёл. Причину так и не узнали.
Я начинаю подозревать, что ты и есть тот самый школотрон на каникулах ;)
А, не всё ли равно - если дело говорит.
> Годная единая компилирующая платформа под истинно свободной лицензией, не то что застарелый GCC от бородатых свободофашистов.В ч.н.:
* Исходники GCC - когда смотрел: срыто-криптографически кал, для блобов.
И по отзывам - писать туда могут только избранные, этакие Нео, от всяких Intel'ов и прч.корпораций [скрыто] очевидно.
Тоже 1в1 кстати и у Торвальса, тут же были даже статьи что даже некоторые единичные Нео из не корпораций - "вешались" из-за чхания на их патчи разного недостающего. Просто показательно.* GPL - вообще какой то жуткий скрыто проприетарный троян, котрый даже в РФ не иммеет полноценну силу,
т.к.даже просто неимеет официально признанного перевода (прочие соотв-нно - в_топку в глазах наших законов), а там/на инглише вдобавок к тому - всё на юридическо-патентно-мыльном инглише... Т.е.он так витиевато многосмысленно составлен что это просто ...какой то жуткий троян уже юридически.
Будь это вменяемо составленная лицензия в стиле BSD-10-100-пуктов, но
человеческим языком и однозначно - я бы ничего не возмущался.
Например, если сравнть GPL с скажем проприетарной OpenWatcom такой же жутко мутной и тоже якобы (уже даже в названии комплекса ПО) свободной (и даже со слов wikipedia - ага как же! туда явно незаглядывавших) то, понятно: что то, что то - свободная/Open только на словах, т.е.раз OpenWatcom косплекс никакой не Open а всё тот же прежний Watcom, то с какого ~такой же GCC - считается свободный, и т.б.Linux Kernel - подвещивающий все *Линукс в возду же юридически только из-за одной его лицензии, даже не говоря про типичныое наличие у вас в линухах блобов начиная от микропрошивок и заканчивая ATI/nVidia драйверов.
Или вот пример, хотел было пропатчить и улучшить движок одной игры
- а, так оказывается скрыто наличествует отавторский же блоб - всеглишь код ИИ..
о чём даже нигде ни слова при скачке (как же это напоминает 99% линухов с их блобами)
и вообще ставит легальность всей GPL делая пираткой.
Т.е. пока не выпилить даже тот шаблонный недо-ИИ из движка - сам автор нарушает GPL,
а это же даже если переписать её с нуля:
1) часть самая сложная
2) что жутко обидно ибо нафиг тогда вообще праивть проект, остальная часть там настолько забагованная и недоделанная что их править смысл тогда - с нуля только её сделать скорей будет проще, но тогда спрашивается - нафига этот проект вообще! (а, если с нуля делать затратно же по времни годами пилить - какие там ещё улучшения, ради которых и хотелось изначально)
3) и даже с учётом её жуткой недоделонности ещё сложней вопрос - как сделать повторив основную механику оттуда так чтобы она не была не была похожа на его (С)-код или скорей на производный из него?...
что тут ещё скажешь - с_ка ты Афлетдинов!* бородатых свободофашистов - ну толерантными лицензии их уж точно не назвать... таки конечно фашисты,
и без ук.выше GPL: "вообще какой то скрыто проприетарный жуткий троян"
- и никто же из этих бородатых - слова против этого ни пикнул,
а ну да они сами же и создали GNU-фонд $собирательный(но, незаметно чтобы затем распределявший авторам) и его очень мутную лицензию...
(А, ещё очень интересно что будет если они отменят GPL, или закроют свой фонд, или продадут).
> котрый даже в РФ не иммеет полноценну силуНу дык это же РФ, ггг! Тут ни-че-го не имеет "полноценной силы".
> Т.е.он так витиевато многосмысленно составлен что это просто
что ты просто не въехал, ну да не переживай, тебе скорее всего и не нужно.
По поводу остальной простыни.. на каком-то "жутко-мыльно-русском" написано))
GPL-фанатик? Бывает...> > котрый даже в РФ не иммеет полноценну силу
> Ну дык это же РФ, ггг!«ггг»-идиотам сообщаю:
- Так я тоже не с РФ, как бы. Такие проблемы везде у нас.
(Уверен и в НАТО, если не сейчас - то скоро будут; максимум - как введут закономерно ожидаемую сертификацию - всего выпускаемого ПО; и вообще удивляюсь что там до сих пор не прикрыли это - налоги не платят же в общак/казну... и даже конкурентам мешают платить полностью! не говоря уже про упущенную прибыль компаниями - т.к.те сами засадить выписав многомилилардный штраф Столману прям стесняются, будучи такими как вы «ггг»-шникам в обществе просто затерроризированны).
Выдыхай!
Сам выдыхни, раз нечего возразить.
То есть для того, чтобы запустить некую программу, скомпилированную с помощью llvm, мне надо на целевой хост поставить, мнэ, интерпретатор llvm, выполняющий "скомпилированный" код.Наверное в этом есть какой-то смысл, но я не понимаю.
LLVM вроде умеет не только JIT, но и AOT :) а насчёт «какой-то смысл» — он как у Явы: один раз собрал и везде запускаешь (: но я тоже считаю что это не так-то уж и круто, как некоторые думают: собрать четыре релизных билда (линь/винда/мак на х86 и линь на арм) не так уж и сложно, в отличии от создания/развития «универсальной» среды, которая везде должна предоставлять одинаковый функционал ИМХО
Только вот в случае с llvm не работает "один раз собрал" их "язык ассемблера" не такой уж и универсальный (иначе в противном случае любой компилятор на llvm работал бы на всех архитектурах, которые поддерживает llvm, а этого не происходит).
Я понимаю, что это такая ява с преферансом и куртизанками.Я о другом. Конпелятор делает исполняемый файл под целевую платформу, и (1) на этой платформе не нужно никаких прослоек, всё собрано, (2) конпелятор оптимизирует, чтобы получить максимально быстрый и эффективный код.
Так вот, в чём смысл механизма llvm с этой точки зрения? Эффективности не получается, дополнительный слой какой-то... Но как бы конпелятор.
Нет это такой P-код. :)
Промежуточное представление между тем, упрощает написание компилятора под платформы.
Упрощает написание под платформы, значительно усложняя оптимизацию вообще и т.б.под конкретную.
(Неявно это NIX-way, типично-лаговый:( Пока невыпилят такое поведение компилятора [и мультиплатформенность] - Линуксы всегда будут позади всех в тестах производительноти,
только из-за этого одного. Хоть мультиплатформенная поддержка - сама по себе требует затрат времни программистов - нелинено, даже просто на поддержание её при каждом чихе в другой платформе, т.о. нелинено уменьшая число даже просто общих оптимизаций и аналогично нужных нововведений синтаксиса, как и аналогично в полноценном документировании).
забавно. "позади всех в тестах производительность", но при этом 100% суперкомпьютеров бегают на этой жутко тормозной фигне.мне кажется, кто то тут врет. и это точно не суперкомпьютеры.
вариант: кто то тут врет - и это не я...
толи аноним толи чукча
Нет, для пользователя это просто компилятор с/с++ (или другого языка). Особенность проекта в том, что он двуслойный, т.е. он переводит язык в универсальный байт-код low-level virtual machine, а затем этот байт-код переводит в инструкции конкретной платформы (например, amd64).
Идея в том, что можно сделать универсальные оптимизаторы байт-кода и оптимизаторы перевода байт-кода в код платформы. Поскольку они работают с байт-кодом, то им всё равно откуда этот байт-код взялся. Поэтому, вместо того чтобы мучить полный компилятор для нового языка, достаточно написать frontend, переводящий в байт-код.
JIT здесь притом, что можно не делать последний шаг при компиляции - перевод в код платформы, а оставить его на потом.
Этой "особенности" сто лет в обед))
> Этой "особенности" сто лет в обед))Вы путаете объектный код с LLVM IR
"Поэтому, вместо того чтобы мучить полный компилятор для нового языка, достаточно написать
frontend, переводящий в байт-код."Вот этой "особенности" сто лет. IR есть у (практически) любого компилятора.
Это ты анон путаешь.
Такой подход был реализован в Обороне -- Ява к этому моменту ещё не существовала.
Нет, это ты путаешь объектный код с IR. IR есть и в gcc тоже, это естественный ход для компилятора, который под несколько платформ компилирует: это позволяет некоторые оптимизации кода проводить кроссплатформенно.
Это не особенность, а обыденность.
Да, только фронтенд прийдется писать на богопротивном с++ вместо богоугодного чистого как слеза девственницы анси с.
Сейчас и GCC постепенно переходит на написание самого себя на C++.
Пруфы в студию, тоесть часть компилера с написана на плюсах?
> Пруфы в студию, тоесть часть компилера с написана на плюсах?https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-loo...
loop_cand::loop_cand (class loop *loop, class loop *outer)
: m_loop (loop), m_outer (outer), m_exit (single_exit (loop)),
m_bbs (get_loop_body (loop)), m_num_stmts (0), m_const_init_reduc (0)
{
m_inductions.create (3);
m_reductions.create (3);
m_lcssa_nodes.create (3);
}
С++ если без его извратских и лагонутых С++ классов - это как раз нормально, даже идеально,
ибо писать ООП на Си... - и есть настоящий изврат.А, сам ООП это по сути продвинутая объектная модель, без которой - никуда, в сколько то большом коде.
Проекты делающие таки оставшимися на Си новичками ниосилившими С++ синтаксис, хоть вроде Торвальдса, - не всчёт. Т.к.он всю жизнь мучает одно и тоже, и уже давно даже просто перевести на С++ - очень время-затратная затея.. не говоря уже наверняка приведующая к новым сотням багам в ядре... Ему таки проще (а может и разумней, думает доживу своё - а, вы там после меня мучайтесь переводя) уже просто посылать всех с идеей перевода ядра кода на С++. Хоть не удивлюсь если он больше боится всех этих мерзких таки, т.б.в ядре ОС, шаблонных классов алгоритмов примазавшихся к понятию и даже стандарту С++; впрочем, они ещё хорошо мозг отбивают( если начинали уже с них, да и у иных - привычкой, тоже) - этого/таких-программистов он может боится даже больше, сразу отсеивая.
(и кстати, недостаток не в самой ООП, а в том как её иногда предлагали использовать
- как средство уменьшить copy-paste для уменьшения повторябельности блоков кода,
что реально даже просто анти-оптимизационно и из-за универсализации и надобности вмещания в неё неуниверсального - порой приводит к проблемам раздувания - ненужной иначе, и т.б.очередному снижению производительности, но это конечно опционально и проектно зависимо, и скорей притензия у желанию сделать всё универсально)
К тому же у С++ есть существенный плюс - более чистый синтаксис и куда лучшая проверка его,
У С++ и его анализатора за счёт улучшеного синтаксиса - на порядок меньше подводных камней, самая же часто поминаемая препроцессор или шабоны - сугубо ниасиляторство, не более. В своих же проектах - их никто не обязывает использовать, а в чужих - и правила уже чужие, вообще.
> Хоть не удивлюсь если он больше боится всех этих мерзких...Как я понимаю, C лучше тем, что он даёт больше контроля за происходящим. Если ты пишешь модуль к ядру, то этот модуль подгружается и представляется объектом в ядре, и vtable к этому объекту ты пишешь ручками.
Плюс есть ещё одна проблема: грамотного разработчика на C несложно найти или взрастить, а вот грамотного разработчика на C++ найти сложно, взрастить невозможно. По-крайней мере в модели разработки linux нет места инкубатору для зелёных C++-птенчиков.
>> Хоть не удивлюсь если он больше боится всех этих мерзких...
>Как я понимаю, C лучше тем, что он даёт больше контроля за происходящим. Если ты пишешь модуль к ядру, то этот модуль подгружается и представляется объектом в ядре, и vtable к этому объекту ты пишешь ручками.Неверно. На С++ можно делать тоже самое 1в1. Зато у него строже синтакисис у типов и их контроль.
> Плюс есть ещё одна проблема: грамотного разработчика на C несложно найти или взрастить,
В теории. (я про грамотного, да и вообще это понятие очень субъективно).
> а вот грамотного разработчика на C++ найти сложно, взрастить невозможно.
Смотря что понимать под грамотностью уже тут, С++ именно как компилятор(а не мега-фреймворк, в добавок компилятор симулирующий своими т.н.алгоритмами), довольно быстро изучается а библиотечные функции так и вовсе из Сей же тогда, или ОС API/вообще свои.
> По-крайней мере в модели разработки linux нет места инкубатору для зелёных C++-птенчиков.
Да, только голубым пингвинчикам.
https://gcc.gnu.org/wiki/cxx-conversion
Тут всё написано.
КО: Склонируй исходники, да посмотри.
Тоестб тменно часть что отвеечает за С компилятор написана на С++? Можно мне ссылку.
> То есть для того, чтобы запустить некую программу, скомпилированную с помощью llvm,
> мне надо на целевой хост поставить, мнэ, интерпретатор llvm, выполняющий "скомпилированный"
> код.
> Наверное в этом есть какой-то смысл, но я не понимаю.Смысл в простом детекторе всех тех, кто толком не разобрался, но имеет "ценнейшее мнение":
> The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines. The name "LLVM" itself is not an acronym; it is the full name of the project.
> Code Generation and Optimization
> This stage translates an AST into low-level intermediate code
> (known as "LLVM IR") and ultimately to machine code. This phase
> is responsible for optimizing the generated code and handling
> target-specific code generation. The output of this stage is
> typically called a ".s" file or "assembly" file
>
плюсую))
Я умею читать и даже осмыслить прочитанное.Вопрос - накой прослойка? Конпелятор нужен для максимальной производительности. А если дополнительно вкрячивается интерпретация байт-кода в платформу, то это не конпелятор.
> Я умею читать и даже осмыслить прочитанное.Угу-угу. Цитата из man clang
>This stage translates an AST into low-level intermediate code
>(known as "LLVM IR") and ultimately to machine code.для кого была?
> Вопрос - накой прослойка? Конпелятор нужен для максимальной производительности.
Ответ: за надом в виде оптимизации. Потому что далеко не все можно оптимизировать на уровне AST (например: лучше подходит (разновидность) той же абстрактой интерпретации). А без "прослойки" -- придется копипастить-писать часть низкоуровневой платфоромнезависимой оптимизации для каждой целевой платформы (краткая лекция введения в компиляторостроение или хотя бы https://en.wikipedia.org/wiki/LLVM#Intermediate_representation и https://en.wikipedia.org/wiki/Intermediate_representation находятся в шаговой доступности от анонима).
> А если дополнительно вкрячивается интерпретация байт-кода в платформу, то это не конпелятор.
Ну если аноним так говорит, то наверное так оно и есть. Правда, пацаны из GCC об этом почему-то не слышали:
https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA
>GCC uses three main intermediate languages to represent the program during compilation: GENERIC, GIMPLE and RTL. GENERIC is a language-independent representation generated by each front end. It is used to serve as an interface between the parser and optimizer. GENERIC is a common representation that is able to represent programs written in all the languages supported by GCC.
>
Явно нет. Хочешь сорву покровы и скажу что gcc, в принципе, так же нынче работает?
Конпелятор от слова conpile?
> Вопрос - накой прослойка?Ответ - в другом ответе выше:
https://www.opennet.ru/opennews/art.shtml?num=52611#63
Компилятор должен быть один, куда все контрибутят для всех платформ.
И это не сабж. Сабж очередной выкидышЪ яббловой проприетарности.
Good-но сказал, плюсую. Ещё на ранних стадиях, разработчики LLVM сперва тупо копировали фрагменты исходных кодов GCC в свой проект, и только потом его переписывали.
разработчики 90% opensource проектов когда имея проприетарный аналог/конкурента сперва тупо копировали фрагменты исходных дизассемблированных кодов в свой проект, и только потом его переписывали. Ибо так не толко быстрей, а и почти ~100%-ая совместимость сохраняется.Так что фиктивный аргумент.
> Компилятор должен быть один, куда все контрибутят для всех платформ.LLVM как раз претендует на эту роль
претендует... но сделали, как обычно.
Сначала во фрибсд, далее - везде! Пора таки уже и линуксе начать выкидывать гцц на мороз!
ни бзди!
Тебя спросить забыли
- Где-где?
- В ...
- О, и я о том же.
> По умолчанию прекращён запуск отдельного процесса ("clang -cc1"),Объясните, пожалуйста, зачем и чем это будет лучше?
По идее для ускорения процесса сборки
что, запуск процесса идёт полчаса, что ли?!
На винде - примерно столько и идет, даже в два раза больше.
Пруфы будут, г-н эксперт, или как всегда?
Пруфы чего? Что если создавать процесс, то это займёт время t = N, а не создавать t = 0?
LLVM - это проект 21го века, начат учёными, написан на современном языке, был рано замечен Apple и получил огромные инвестиции как раз когда Столлман решил скатить хорошую лицензию в новую версию, которая добавила только лишние проблемы всему рынку. Кроме FSF и GNU никто почти и не перешёл на неё. Сейчас многие крупные игроки уже осознанно выбирают между двумя проектами. И это прекрасно! Конкуренция заставляет оба проекта развиваться. Но пока из преимуществ GCC осталось только то, что на него завязана вся инфраструктура FLOSS, только из-за этого он и держится на плаву. Но и это преимущество не вечно, OpenMandriva уже полностью перешла. В Debian постоянно растёт доля пакетов, успешно собираемых Clang/LLVM. А производительность уже давно сравнялась, есть некоторые флуктуации в разные стороны.