После шести месяцев разработки представлен релиз проекта LLVM 15.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57739
Отличная новость! Крутой прогресс за полгода.
> Отличная новость! Крутой прогресс за полгода.Плюсую. За LLVM будущее, и скоро, надеюсь, выкинут наконец-то этот GCC на свалку истории
Чем он вам так насолил?
Да она и про LLVM-то только название и слышала.
Да куча недостатков:
- GNU C Language Extensions - здоровенный костыль поддержанный (изначально) только в одном компиляторе и как следствие невозможность сборки ядра другими. Прямо extend в стиле microsoft'а.
- здоровенный монолит - максимальная связность и сложность расширения
- отстойная огороженная лицензия
FSF при помощи прежде всего GCC начал менять мир годах в 80ых и продолжает менять до сих пор и результатами этого пользуются все без исключения люди, даже если они не догадываются об этом.У шланга кол-во поддерживаемых архитектур примерно на порядок (десятичный) меньше чем у GCC.
Лицензия GPL -- лучшая лицензия для открытого софта, а ненавидят её только проприерасты, которые только и мечтают о том, чтобы безнаказанно *красть* (брать и закрывать) чужой открытый код.
> У шланга кол-во поддерживаемых архитектурА знаешь почему? Потому что они на момент создания llvm никому нафиг не вс@лись!
Это куча всякого хлама который можно найти только в музеях, а выпилить из gcc не решаются, потому что "а вдруг что-то сломаем по дороге".
Хотя все даже круче - gcc поддерживает бекенды для архитектур, которые никогда не были реализованы в железе - секция M в https://gcc.gnu.org/backends.html.
Зачем ты рассказываешь о том, в чём ничего не понимаешь? Как же так - гцц подлый монолит не расширяемый, а он поддерживает множество архитектур?>выпилить из gcc не решаются, потому что "а вдруг что-то сломаем по дороге".
Зачем домохозяйка пытается рассуждать о коде? Как раз таки всё наоборот.
>бекенды для архитектур, которые никогда не были реализованы в железе
wasm в желе покажешь?
> Лицензия GPL -- лучшая лицензия для открытого софта, а ненавидят её только проприерастыПросто не все живут на мамкиной шее. И идеалами сыт не будешь.
Одни лозунги. А по факту — единоличное создание своего диалекта си (в стиле майкрософта). И ни один поборник стандартов не вякнет: ведь этим свои занимаются. Вот если бы майки это сделали, то вони бы стояло на сотню комментов.
Смотри, жертва пропаганды.- Кроме gnuc другого си нет. Никто не будет ничего писать на этом днище. И да - шланг это именно что gnuc/cpp компилятор. Как и сам драйвер там 1в1 повторяет гцц. И да, свободный код не может быть вендорлоком.
- Пустые сказки от домохозяек. Мне даже лень спорить на эту тему - пруфы ты всё равно не покажешь.
- Лицензия наиболее свободная. Единственное что у гцц есть из проблем - это во многом столман-шиза древняя о том, что cpp-фронт будут воровать.
Гнус это всего лишь жалкая надстройка над си, которую добавили ядрописатели - просто не шмогли в стандарт (ну или вынуждены были добавить, потому что стандарт отстой). Такая же огороженная надстройка как "Microsoft extensions to C", которую добавили майки MSVC. И такой же вендорлок.> Лицензия наиболее свободная
Ну да, ну да, "свобода это рабство".
Свободные лицензии - это MIT, BSD, MPL, CCA и аналогичные. А ваша GPL - открытая, но не свободная.
GPL - не свободный, потому что ограничивает твою "свободу воровать"?
Свобода зарабатывать - это свобода воровать ?! Чтобы заработать, предлагаете с нуля всё лично самому писать, начиная с драйверов и биос с операционкой. Хорощо рассуждать о светлых идеалах, сидя на шее у родителей, ничего сам не зарабатывая.
Хорошо сидеть на шее у сообщества, используя его инструменты, изображать из себя у мамы большого айтишнега-заработника.
Как можно украсть то, что принадлежит всему миру и отдано в безвозмездное пользование с единственной оговоркой: не требовать гарантий?!
Это Вам расхищение гуманитарки мерещится.
БСД - истинная свобода!
>Гнус это всего лишь жалкая надстройка над сиДа ты чё? Зачем ты, домохозяйка, о чём-то пытаешься рассуждать? gnuc это и есть си. Это даже деюро закреплено тем, что стандарты после gnuc просто копипастили в себя куски gnuc.
>которую добавили ядрописатели
Опять же опозорился. Ядрописатели это лишь одни из.
>просто не шмогли в стандарт
Как в бездарный мусор можно не мочь? Скорее они не хотели жрать дерьмо и "писать" на то на чём только лабу можно написать. Но ты даже и лабу не писал.
>(ну или вынуждены были добавить, потому что стандарт отстой).
Им ненужно ничего добавлять - это стандарт вынужден быть у них всё тащить, чтобы хотя бы быть похожим на си. А gnuc как был так и остался си, а стандарт лишь жалкая пародия.
>Такая же огороженная надстройка как "Microsoft extensions to C", которую добавили майки MSVC. И такой же вендорлок.
Жертва пропаганды - никаких расширений от маздайсофта не существует. Ты опять опозорился. То, что ты где-то там слышал - это вообще не про си.
И уж тем более, жертва пропаганды, gnuc не может являться вердорлоком.
>Ну да, ну да, "свобода это рабство".
Для тебя да.
>А ваша GPL - открытая, но не свободная.
Нет, гпл это именно что свободная лицензия. Просто она тебе не позволяет воровать чужой код от того у тебя жопа болит. Вернее даже не у тебя - ты просто раб хозяина и ретранслируешь его волю.
С другой стороны нужно быть благодарным им за это все - иначе какой смысл было бы создавать llvm.
Не очень понятно, зачем нужно фиксировать промежуточный результат в виде объектного модуля для абстрактной архитектуры. Ведь все равно для отладки загрузочного модуля нужен код для целевой архитектуры. Это же и для этапа компоновки.
Единственное объяснение -- метод предназначен, чтобы воспрепятствовать использованию хороших библиотек, что идут в составе проприетарного софта, в неконтролируемых этими проприетарщиками программах. Да и зачем каждый раз при загрузке программы ее компилировать в код для целевой архитектуры, если можно это сделать один раз и просто его использовать в готовом виде. Да и оптимизация этого промежуточного кода бесполезна, поскольку процесс этот конкретен для конкретной архитектуры. Получается, что вместо оптимизатора в составе компилятора, генерирующего объектный код, нужно иметь два -- оптимизатор в промежуточную архитектуру и оптимизатор в целевую. Но это и так есть в любом компиляторе, просто промежуточный код не выводится, а второй оптимизатор работает один раз, в отличие от, который должен работать при каждой загрузке.
NIH-синдром на Java JIT: нужно реализовать то, что было реализовано 20 лет назад, но на новом технологическом уровне, с задействованием в 100 раз большей процессорной мощности и в 1000 раз большей потребной памяти.
>Добавлена экспериментальная поддержка Си-подобного языка HLSL (High-Level Shader Language), применяемого в DirectX для написания шейдеров.Вайн задействует?
https://github.com/microsoft/DirectXShaderCompiler - просто аттракцион невиданной щедрости какой-то
Видимо на DX все забили при наличии вулкана, вот и раздобрились...
Ждём обновления ldc для dlang.
А про ассемблер llvm-mc ничего не слышно? Он совместим с gas, но весьма ограниченно. .S файлы сформированные с помощью llvm с помощью gas собираются на ура, а вот файлы созданные для gas не в 100% случаев собираются llvm-mc, что навевает на мысль, что ассемблер из проекта llvm не на 100% совместим с gas. Хотя, если писать на ассемблере с учётом небольших нюансов, можно использовать одни и те же файлы и под gas, и под llvm-mc.
Мне вот надо чтобы clang на инлайн асме, с интел синтаксисом на использовании offset не крашился.
Интел-стайл контр-интуитивен. Особенно при косвенной адресации. Закопать.
AT&T-синтаксис просто ужасен и для набор и для чтения. Его вообще не должно быть нигде от слова ВАЩЕСОВСЕМ.
У тебя синдром утёнка.
У тебя Даннинг-Крюгер.
> AT&T-синтаксис просто ужасен и для набор и для чтения. Его вообще не
> должно быть нигде от слова ВАЩЕСОВСЕМ.Не, норм. Не привычно после TASM/MASM/Fasm/Nasm/RosAsm и что там ещё юзал в молодости, уже не вспомню... Но, когда углубляешься в вопрос, и узнаешь что изначатльно синтаксис gas пилили не для Intel, а для других, более старых и экзотических, архитектур, и что в AT&T синтаксисе gas красиво унифицировали приёмы написания программ для разных машинных архитектур(отсюда и странный для Intel порядок аргументов при присваивани, так как у разных ассемблеров он разный был, делали так, как было бы удобно программисту более высокоуровневого ЯП, вроде C), коих у gas кроме x86/x86_64 хватает, и что изучив один раз хорошо gas именно с AT&T, а потом при освоении новых чипов изучая только набор их инструкций и опкодов и небольшие нюансы, вы примерно в одном и том же стиле с одним инструментом сможете писать на asm под кучу архитектур. Не меняя свои привычки :) И вот ради этого стоит, ломая себя через колено, приучать свой ленивый мозг к AT&T, и не зариться на архитектуро-специфичные ассемблеры, созданные только под одну архитектуру. Да, нож или ложка по отдельности могут быть удобней мультитула в чём-то. И весить меньше, и более эргономическую ручку иметь, и т.п. Но, у мультитула есть свой козырь в рукаве: универсальность. Вам она не нужна, поэтому вам и AT&T синтаксис не зашёл. А была бы нужна, оценили бы единный подход к организации написания кода под разные платформы с помощью одного инструмента, а не россыпи разных, специфичных только для своей архитектуры.
>так, как было бы удобно программисту более высокоуровневого ЯП, вроде CПравда? Как там в AT&T записывается eax = ecx ? В Intel mov eax, ecx.
>а потом при освоении новых чипов изучая только набор их инструкций и
>опкодов и небольшие нюансы, вы примерно в одном и том же стиле с одним
>инструментом сможете писать на asm под кучу архитектурИ поэтому в gcc есть куча костылей, чтобы ассемблер не использовать никогда. Даже если пишешь архитектурно-зависимые вещи. Похоже даже разработчики gcc ненавидят GAS.
>Но, у мультитула есть свой козырь в рукаве: универсальность
Что может быть универсальнее fasm ? Это зло вообще всё с помощью макросов делает. Другой вопрос, что он появился поздно, когда даже микроконтроллеры перестали программировать на Ассемблере. Но на нём хотя бы пишут энтузиасты, а кто и что пишет на GAS ? Даже OpenSSL злоупотребляющий Ассемблером не пишут на GAS, а на своём универсальном perl-Ассемблере, который можно транслировать хоть в MASM, хоть в GAS... и да, у них интеловский порядок регистров.
> Правда? Как там в AT&T записывается eax = ecx ? В Intel
> mov eax, ecx.Когда вы чему-то присваиваете какое-то значение с помощью команды mov(move по сути), логично было бы указать что вы перемещаете, и куда. А не наоборот. Но, это чистой воды вкусовщина. Если к вам придёт грузчик, и вам нужно будет сказать чтобы он отнёс коробку в машину, вы можете ему велеть отнести коробку в машину, или в машину коробку — он вам поймёт в любом случае. Так и тут, когда известно, в каком порядке конкретный синтаксис велит указать что и куда двигать, какая разница какой это порядок, когда главное — результат? Но, для меня лично порядок что двигать, а потом куда — более интуитивно понятный.
> И поэтому в gcc есть куча костылей, чтобы ассемблер не использовать никогда.
> Даже если пишешь архитектурно-зависимые вещи. Похоже даже разработчики gcc ненавидят GAS.GAS есть в ядре Linux, в коде syscall trap от Линуса, к примеру. Что-то видел в glibc(там хватает ассемблерного кода и вставками, и в отдельных файлах). И да, там GAS именно с AT&T синтаксисом(а то он и Intel умеет, и даже кое-какие MASM-специфичные вещи в него запихнули, видел поддержку стандартных для MASM макросов в одном проекте на GAS). А ещё в некоторых мультемедийных либах видел его же(знаю, что в этой сфере много любителей Nasm, но бывают исключения).
> Что может быть универсальнее fasm ? Это зло вообще всё с помощью
> макросов делает. Другой вопрос, что он появился поздно, когда даже микроконтроллеры
> перестали программировать на Ассемблере. Но на нём хотя бы пишут энтузиасты,
> а кто и что пишет на GAS ? Даже OpenSSL злоупотребляющий
> Ассемблером не пишут на GAS, а на своём универсальном perl-Ассемблере, который
> можно транслировать хоть в MASM, хоть в GAS... и да, у
> них интеловский порядок регистров.О да, помню я макросы для удобного вызова функций WinAPI на Fasm. Макросы у него хороши. Но, у GAS, внезапно, макросы тоже очень неплохи. Мало кто их расковырял и юзает, но они есть. А насчёт универсальности: fasm — это только x86 и x86_64, о какой универсальности идёт речь у него? А GAS - это ARM, RISCV, x86 и x86_64, MIPS и куча других архитектур(включая разные чипы motorolla полувековой давности и прочие довольно редкие игрушки для любителей низкого уровня). Fasm точно не позволит вам примерно в одном стиле писать и под Intel, и под ARM с RISCV. А GAS на такое способен.
Да пофиг на синтаксис. Ассемблер очень мало, когда реально нужен, если только вы не занимаетесь дизассемблированием))
Чувство прекрасного против.
> AT&T-синтаксис просто ужасен и для набор и для чтения. Его вообще не
> должно быть нигде от слова ВАЩЕСОВСЕМ.Уж точно лучше, чем интелловский. Если этот не должен существовать, тогда всех интелловцев вообще надо сжечь (не призывы к терроризму, не разжигание социальной ненависти).
> Интел-стайл контр-интуитивен. Особенно при косвенной адресации. Закопать.Интел не регламентирует синтаксис. offset - это Microsoft. Есть синтаксисы (Borland ideal, fasm), где приняты [] как и в Си.
Ага, а когда присваеваемое слева, а куда присваивают справа - нонсенс же.
А на неинтел синтаксисе всё норм?
> А на неинтел синтаксисе всё норм?Не всё. Но интел существенно хуже.
mov eax, ebx -- попробуйте здесь догадаться откуда куда тут передаётся содержимое? Вы книгу также зигзагом читаете? Это я ещё режимов адресации не касался.
Смесь английского с ивритом???
Народ, подскажите, пожалуйста, хороший транслятор из одного синтаксиса Ассемблера в другой.
GAS это умеет?
>>обнуление всех использованных в функции регистров CPU перед возвращением управленияИ снижение производительности в несколько раз
>>рандомизация размещения в памяти структурчтобы поломать всю арифметику указателей
Арифметика указателей для перехода между глобальными структурами - UB. Если в вашем коде есть такая работа с указателями, то вы ССЗБ
Нельзя быть не толерантным к злобным буратинам.
Надо быть толерантными ко всем буратинам, но злобных сажать в тюрьму, но делать это толерантно.
>чтобы поломать всю арифметику указателейполомается так называемая динамическая арифметика, компиляторная будет работать, а всякие роп пейлоады как раз на эту динамику и расчитаны.
Несколько команд снизят производительность в несколько раз ?
Не несколько команд. Регистров не несколько. Но в 2 раза вполне может. С учётом относительно медленной оперативной памяти не так страшно, но размер программ вырастает, кеш используется менее эффективно.
Даже будучи смузихлёбом смутно припоминаю, что были команды для сохранения всех регистров в стеке-восстановления всех регистров из стека
Вроде popad-pushad. Что-то подобное, вроде бы, даже под 64 бита было( pushfq ? )
PUSHF (опкод 9D) сохраняет регистр флагов (F). В 64-х разрядном режиме тот же опкод называется PUSHFQ и сохраняет расширенный регистр флагов RFLAGS. POPA довольно медленная, вместо неё рекомендовалось использовать серию POP или MOV. В 64-х разрядном режиме её убрали. Но сохранять-восстанавливать регистры как раз не надо (это упростило бы создание ROP-цепочек), обнулять быстрее (нет работы с памятью).
> Даже будучи смузихлёбом смутно припоминаю, что были команды для сохранения всех регистров
> в стеке-восстановления всех регистров из стека
> Вроде popad-pushad. Что-то подобное, вроде бы, даже под 64 бита было( pushfq
> ? )Вы новость читали? При чём тут сохранение на стеке, если речь в статье шла про возможность утечки данных по остаточным данным в регистрах?
>Вроде popad-pushadЭти команды чудовищно медленные и в тактах выигрыша не будет, только в объёме кода, плюс нужно завершить все спекулятивные операции. Там ещё есть команды для сохранения FPU/SSE и это уже настолько большая боль, что ОС старается по возможности его не сохранять даже при переключении процессов/потоков.
>pushfqЭто инструкция сохранения 64-битного регистра флагов. Инструкций сохранения всех регистров на архитектуре x86-64 совсем нет. Даже тех, что были на x86-32 вроде pusha, pushad, опкод 0x60 просто пуст.
> Не несколько команд. Регистров не несколько. Но в 2 раза вполне может.Медленный Silvermont исполняет 2 (две) XOR за такт. CALL - 1-2 такта. RET - 1 такт. Так что прежде чем писать что-то с аватаркой Ленина, хорошо бы последовать его примеру и три раза поучиться арифметике.
>> Не несколько команд. Регистров не несколько. Но в 2 раза вполне может.
> Медленный Silvermont исполняет 2 (две) XOR за такт. CALL - 1-2 такта.
> RET - 1 такт. Так что прежде чем писать что-то с
> аватаркой Ленина, хорошо бы последовать его примеру и три раза поучиться
> арифметике.Это же две команды? И сколько их нужно всего? И на сколько при этом упадёт эффективность кеша?
>>> Не несколько команд. Регистров не несколько. Но в 2 раза вполне может.
>> Медленный Silvermont исполняет 2 (две) XOR за такт. CALL - 1-2 такта.
>> RET - 1 такт. Так что прежде чем писать что-то с
>> аватаркой Ленина, хорошо бы последовать его примеру и три раза поучиться
>> арифметике.
> Это же две команды? И сколько их нужно всего?Что тут нужно, так это доказать утверждение «снижение производительности в несколько раз». Доказывает его заявитель. Я понимаю, что доказательство невозможно даже для вырожденного частного случая, потому вместо него будет всевозможная чушь и плюсики самому себе.
> И на сколько при этом упадёт эффективность кеша?
Кеш данных не имеет отношения к вопросу. Вообще. Но человеку, кто видел асм лишь на картинках, я объяснять не берусь. Да, начиная демагогию, будь готов к зеркальному ответу.
> Несколько команд снизят производительность в несколько раз ?Там типичный эксперт. А вот талмуд:
Table 2-3. Skylake Microarchitecture Execution Units and Representative Instructions
Execution # of Instructions
Unit UnitALU 4 add, and, cmp, or, test, xor, movzx, movsx, mov, (v)movdqu, (v)movdqa, (v)movap*, (v)movup*
Для обнуления используется XOR, в наличии 4 исполнительных устройства (то есть могут исполняться параллельно).
А вот красавец который кроме wintel себе ничего представить не может и потому считает что талмуд на скайлэйк это универсальный ответ на все вопросы вселенной.
А ещё я имею представление, сколько примерно команд находится в теле средней подпрограммы и прикинуть отношение их количества к количеству команд обнуления. Но при этом догадываюсь, что это слишком сложная для некоторых Анонимов арифметика, потому ограничиваюсь наглядным частным случаем.
А что такое средняя подпрограмма? Это типа средней температуры по больнице? :)
Это та цифра, которую эксперты подставят в известную им формулу и наконец-то докажут тезис «снижение производительности в несколько раз». ;)
Вы все тут эксперды. По факту нормальный OoO процессор, видя XOR reg,reg -- ничего не выполняет вообще и такая команда пропадает на этапе шедулинга, в конвееры АЛУ не идёт. Вместо этого, этот регистр просто размапливается в таблице соответствия между архитектурными и физическими регистрами.
Молодец, единственный кто осилил прочитать мануал. Это удивительно - особенно на фоне всех клоунов выше. Правда всё остальное, кроме самого факта существования мапинга - чушь. На "алу" шедулит шедулер, который работает уже с физическими регистрами. Но то ладно.Важно то, что никому нахрен не упёрся факт исполнения. Если говорить про такое днище как х86, то уже тысячи лет оно упирается во фронтенд. А что-то исполняется/нет это не влияет на производительность - если только на энергопотребление.
> Если говорить про
> такое днище как х86, то уже тысячи лет оно упирается во
> фронтенд.По факту CodeAnalyst закопали всего лет десять назад, а без симуляции конвейера кто ̶п̶е̶р̶в̶ы̶й̶ ̶н̶а̶д̶е̶л̶ ̶х̶а̶л̶а̶т̶ ̶т̶о̶т̶ ̶и̶ ̶п̶с̶и̶х̶и̶а̶т̶р̶ громче всех крикнет «клоуны» то и прав. Так что знайте на будущее: х86 это 16-ти разрядная архитектура, кто скажет иначе - тот не видел у мануала даже название.
Ты выше опозорился и пришёл сюда плакаться? Какая архитектура, какой CodeAnalyst, какой "16-ти разрядная"? Ты от позора решил просто рандомные базворды из гугла пастить?
Это что, выпуск экстерном нового актива «центра псих операций»? Мануал, который вышеописавшийся друг мракобесия ни разу в глаза не видел, называется 64-ia-32-architectures-optimization-manual.pdf Соответственно и архитектура - IA32, а не как пытается внушить вон тот член секты Cвидетелей i8086.
Вы слишком рано ответили. Такие умозаключения разбиваются железным аргументом «А вот красавец который кроме wintel себе ничего представить не может». Потому про вещи типа сброса зависимостей по данным (xor влияет на флаги) и гипотетическую возможность получить выигрыш по скорости за счёт отброса ненужной ветки (которая без xor бы спекулятивно исполнилась) я даже заикаться не стал.Если же возьмём общий случай и придумаем фантастическую архитектуру, то можно накидать вот такой минимальный пример:
R1 <- arg1
R2 <- arg2
R3 <- R1 + R2
R1 <- 0
R2 <- 05 команд из которых 2 «тормозят в несколько раз» (ц) 3 оставшиеся. Это без учёта вызова и возврата. Я не знаю, как и что тут надо поделить, что бы получить что-то заметно больше чем 1,5. Но точно знаю, что вон тот крендель в кепочке должен одурачить пролетариат, иначе ему не получить власть. Ну, например, он может дописать R3 <- 0 (используется же регистр!) и я сяду в лужу. ;) А вон тот Ванёк ничего не сможет дописать - он уже признался, что эксгибиционист.
Если небольшая функция, и она активно используется, и компилятор её не встроил (inline), то может и в несколько раз...
Готовы показать пример такой функции?
>>>рандомизация размещения в памяти структур
> чтобы поломать всю арифметику указателейЕсли кто-то ходит по структуре по хардкоженым оффсетам, то где-то ошибка на этапе дизайна. Если это действительно нужно (какой-то бинарный протокол), то этому атрибуту явно там не место
А так фича уже старая, просто в кланге поддержка появилась только сейчас. Ваши эти линуксы давно используют этот атрибут для важных структур, если сборка идёт с гцц
> Если кто-то ходит по структуре по хардкоженым оффсетам, то где-то ошибка на этапе дизайна.Есть вполне себе легальный offsetof.
> установки затравкиWhat is it, затравка?
Начальное значение?
А как быть с повторяемостью сборки?
Как быть если эту "затравку" узнает тот, кому бы знать ее не надо?
Нашел:
The support can be enabled via the "-frandomize-layout-seed=" or "-frandomize-layout-seed-file=" options for providing the deterministic random seed for allowing reproducible builds.
> C++23. реализованы ключевые слова false и trueГрандиозно отметили 50-тилетие языка
Ну и в чём прикол ? Наезжали всегда на паскалистов за их begin end. Ну были 0 и 1. Эстеты их превращали дефайном в false и true.
В привидении типов. Нельзя понять 1 это bool или int.
пример?
Дефайн видите ли не меняет определенную математику. Bool does, там есть определенные гарантии поведения. Даже в случаях когда integer'у под ним присваивают (по крайней мере, пытаются) иные значения.
Давно уже пора довести до нормального состояния, чтобы всякие студенты не писали пародии на С++
Вы пишите:
>>> C++23. реализованы ключевые слова false и true <<<В тексте написано:
>>> Для языка Си реализованы: ... ключевые слова false и true ... <<<При чем тут C++23?🤦
Да, писал конечно про C2X, при форматировании не ту часть удалил
Единственная функция LLVM — чтобы GCC не спал, но это тоже полезно.
Ты не в теме, Ллвм используется примерно во всех проприетарных компиляторах всего последние лет 15 уже так точно. Шейдеры, куда, жит, фортран. Гцц вечно в догоняющих. Но, что касается си и частично плюсов, у гцц до сих пор получается ощутимо более эффективный код (особенно, при задействовании пго). Не понимаю этого нездорового вендузячьего желания собирать всё шлангом, из того что я видел, майкрософтовский компилятор хоть и отставал по возможностям на десятилетия, но генерировал код не хуже шланга. Реальная его проблема это совершенно неосмысленные сообщения об ошибках.
>Ллвм используется примерно во всех проприетарных компиляторах всего последние лет 15 уже так точноНу и кто теперь и дальше будет утверждать, что LLVM не проприетарщина?
>Не понимаю этого нездорового вендузячьего желания собирать всё шлангомА я вот понимаю.
ein сompiler - не нужно держать ворох повторяющихся компиляторов. Ставим один компилятор из официальных деб-репозиториев и собираем подо все платформы, под какие пожелаем. И имеем на всех платформах последние фичи языка C++. Флаги компиляции тоже почти одинаковы. Очень удобно.
ein bytecode - все инструменты используют одно и то же представление. Благодаря тому, что создатели LLVM не копирастничают, сторонние инструменты вообще могут существовать, потому что если бы обязали всех использовать GPL, то многие бы просто сказали "ну тогда мы наш инструмент не опубликуем вообще". И позволяет сторонним инструментам быть отдельными программами, работающими с IR по-своему. Создатели gcc же решили усложнить, чтобы все статически линковались с GCC. Недружественный жест, создающий кучу практических проблем. "Ну ОК, значит не будем использовать GCC", решили адекваты, и теперь у нас есть Clang.
Ну и существенно проще добавлять поддержку новых архитектур или языков по сравнению с гэцц.
Дописал бек или фронт, в зависимости от того что добавляешь, и у тебя готовый инструмент со всем фишками и оптимизациями.
В GCC как-то иначе?
Принципиально - нет. Но если начать разбираться, то нюансов море.
GCC намного более монолитен. Это влияет на легкость добавления поддержки языков.
Можно просто сравнить что поддерживает GCC:
C, C++, Objective-C, Objective-C++, Fortran, Ada, D, and Go (https://gcc.gnu.org/onlinedocs/gcc/G_002b_002b-and-GCC.html)и что поддерживает LLVM:
ActionScript, Ada, C#, Common Lisp, PicoLisp, Crystal, CUDA, D, Delphi, Dylan, Forth, Fortran, Free Basic, Free Pascal, Graphical G, Halide, Haskell, Java bytecode, Julia, Kotlin, Lua, Objective-C, OpenCL, PostgreSQL's SQL and PLpgSQL, Ruby, Rust, Scala, Swift, XC, Xojo, Zig (https://en.wikipedia.org/wiki/LLVM, https://llvm.org/ProjectsWithLLVM/)Нужность или "нинужность" этих всех языков выходит за рамки вопроса, но показывает насколько чаще выбирают LLVM вместо GCC.
Ты ничего о них не знаешь - жертва пропаганды. Зачем ты позоришься?Монолитная помойка - это именно что ллвм. Другое дело, что ллвм использует c++/си с классами, кодогенерацию. Он тупо проще нежели гцц.
Но основная причина это шха-лицензия и то, что в лввм - это туллинг для создания компиляторов. Гцц таким не является. Это именно компилятор, а не тулинг.
>и что поддерживает LLVM:Жертва пропаганды, насколько же ты нелепая. Ничего из этого ллвм не поддерживает. Это всё внешний мусор. А то, что ты линкуешь для гцц - это его части. Частью llvm по-сути является только шланг.
Поэтому именно в гцц фронтов больше. А всё эти сказки, которую ты пастишь - это не фронты. Это просто "где используется ллвм".И даже здесь ты не смог опозориться. Ты не смог даже отфильтровать список. Допустим на ту же cuda.
llvm и подхватил эпл для того, чтобы делать проприетарщину. Ты и сам подтвердил почему. гцц нельзя украсть, хотя эпл/нвидия и прочие вендоры ранее воровали. До того как им это запретили.Поэтому смысл ллвм только в одном - воровать. Будь можно воровать гцц - никому ллвм не был нужен. На самом деле там причин вторичных выбора в пользу ллвм больше в шланге.
>Шейдеры, куда, жит, фортран.
Какой жит - в гцц тыщу лет был жит. Какие шейдеры/какая куда - о чём ты, домохозяйка. Куда всегда была на гцц и та куда так и осталась. Фортран вообще какой-то мусор.
Нвидия же не реализовывала куду/прочее в ллвм - он мусор. Она создала ptx и теперь llvm лишь генерирует ir для нвидия-блобов. И да - гцц умеет в ptx.
>Гцц вечно в догоняющих.
Да ты чё. Догоняющих кого, жертва пропаганды?
>Но, что касается си и частично плюсов, у гцц до сих пор получается ощутимо более эффективный код (особенно, при задействовании пго).
Я тебе открою тайну, жертва пропаганды, но гцц совершеннее во всём. Он и код собирает быстрее и конфигурируется лучше и архитектурно более совершенен и поддержка языков лучше и код получается быстрее и анализатор/сообщения об ошибках там куда лучше.
>Не понимаю этого нездорового вендузячьего желания собирать всё шлангом, из того что я видел, майкрософтовский компилятор хоть и отставал по возможностям на десятилетия, но генерировал код не хуже шланга. Реальная его проблема это совершенно неосмысленные сообщения об ошибках.Да тут у нас маздайчонок нарисовался. Жертва пропаганды - маздайский мусор сливает шлангу во всём. Поэтому маздай пытается воровать edg/llvm/clang, чтобы на них заменять свой бездарный мусор.
Это как была история с ослом. Уже практически полностью маздайский мусор переделан на edg/clang/llvm, как уже было выше сказано. Скоро там останется одно название.
llvm эплу нужен чтобы мигрировать с x86 на arm и дальше по списку.
Не уверен, о чём ты тут затираешь и зачем, но cuda compiler от nvidia это именно что форк llvm7. Сам clang поддерживает генерацию ptx с 3 версии примерно, при этом, я вообще не видел, что бы кто-нибудь применял gcc с этими целями (ни одного проекта, все требуют nvcc или хотя бы clang для результатов похуже), и nvcc -- не gcc (и, вроде, никогда не был? лет 15 точно). Видимо, остальная твоя информация имеет примерно тот же уровень достоверности -- ты никогда ни с чем не работал, а обзываешь других домохозяйками. А фортран широко используется в математических вычислениях и сегодня, очень актуально для распараллеливания на кучи больших жирных нод суперкомпьютеров (там часто как раз nvidia есть).>сливает
Не, я лично билдил бинари для маздайки и сравнивал производительность и оптимизации, поэтому, не соглашусь. Ллвм там прижился, поскольку что у него не было проблем с раскруткой исключений (они были у гцц), ну, и по мелочи.
> Не понимаю этого нездорового вендузячьего желания собирать всё шлангомС вероятностью 99% получится более эффективный машинный код, да и при разработке кросс-платформенного софта использование одного компилятора на всех платформах даёт некоторые плюсы (меньше компиляторо-специфичных нюансов типа проивозительности сгенерированного кода, багов самого компилятора и т.п.).
> майкрософтовский компилятор хоть и отставал по возможностям на десятилетия, но генерировал код не хуже шланга
Если майкрософтовский компилятор сгенерировал код не хуже шланга, то вам просто повезло. Примеров наподобие https://godbolt.org/z/orMv61YjE можно найти/придумать немало.
уже 2022, а они только с++20 допиливают. хаха
Уже время вам присоединится и показать миру как надо "пилить"
К какому "миру"?
А теперь представьте, что надо написать свой собственный компилятор языка с++ (с++23) вообще с нуля!:)
Значит, что то давно не так в С++ королевстве. И развитие его идет в какую то не ту сторону.
Да, у С++, впрочем как и у любого другого языка есть проблемы, но утверждать, что его развитие идет не в ту сторону, - я бы точно не стал!
Как оно по производительности генерируемого кода по сравнению с GCC, ICC, MSVC, в том числе с использованием PGO? Кто-нибудь знает?
Без оптимизаций - влёт,а так жсс рулит,но это было с год назад,а то и больше.
Про PGO не скажу, но на обычной компиляции clang и gcc где-то рядом - в одних случаях один лучше, в других - другой. icc сдох (Intel перешел на clang со своим бекендом, называется icx), и и clang, и gcc его уже давно обставили. Единственная его "киллер-фича" - это автоматический runtime dispatch в зависимости от наборов инструкций, поддерживаемых CPU. А MSVC - это хрень, а не компилятор. На типовом коде еще куда ни шло, и то - иногда умудряется генерировать некорректный код. Но как только начинаешь использовать векторные расширения - это дно.
clang в хламину сливает gcc. Обычно однорукие бандиты даже замерить нормально код не могут(допустим не знают про libcxx и llvm-рантайм для цпп). Так же шланг имеет более агрессивные умолчания нежели гцц, а так же там много всяких подложных фейковых оптимизаций.>Единственная его "киллер-фича" - это автоматический runtime dispatch в зависимости от наборов инструкций, поддерживаемых CPU.
Это базовая фича gcc/gnuc ну и шланга как альтернативной реализации gcc/gnuc. Фича у интел-компилятора в другом. Она такая же как и в случае с шлангом и его фейковыми оптимизациями. Он создан специально чтобы заменять код вчерашнего мойщика полов на нормальный. Если же код пишет не мойщик полов все эти кулл-оптимизации нахрен ненужны.
Из таких примеров простых. Боты-поломои в основном пастят шаблоннный мусор. Всякие for i j и прочий мусор. Вот icc умел детектировать этот мусор и заменять его на нормальные реализации. Допустим какое-нибудь умножение матриц и прочее.Точно так же как gcc/clang умеют детектировать memcpy.
>> Единственная его "киллер-фича" - это автоматический runtime dispatch в зависимости от наборов инструкций, поддерживаемых CPU.
>
> Это базовая фича gcc/gnuc ну и шланга как альтернативной реализации gcc/gnuc.Нет в gcc такой фичи. Есть ручное клонирование и маркировка функций для разных наборов инструкций.
https://gcc.gnu.org/wiki/FunctionMultiVersioning
А icc мог сам сгенерировать клоны (или даже вынести часть функции в клоны) и dispatch из простого кода.
То же самое можно сделать в любом компиляторе с помощью #ifdef __инструкции__ (__SSE2__,__AVX2__ и т.п.)
Вопрос на засыпку: в чем разница между директивами препроцессора и runtime dispatch?
Если прямо действительно необходимо runtime dispatch, то помимо директив препроцессора есть cpuid. Комбинация cpuid и директив - более гибко, контролируемо и более-менее универсально для любого компилятора.
Не используйте LLVM, он нужен пермиссивщикам и проприетарщикам.
Не используйте GNU/GPL, он нужен пермиссивщикам и проприетарщикам.
Пофиксил, не благодари.
Кстати, а почему оракул не хочет гест аддишанс шайтан коробки в бсди положить, а вон мс скуль в пингвине крутится? Какая-то несвободная свобода. Не?
> В Libc++ продолжена реализация новых возможностей стандартов C++20 и C++2b, в том числе завершена реализация библиотеки "format" и предложен экспериментальный вариант библиотеки "ranges".Джва года ждал.