forum.opennet.ru - "Релиз набора компиляторов LLVM 15.0" (111)

"Релиз набора компиляторов LLVM 15.0"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Релиз набора компиляторов LLVM 15.0"	+/–
Сообщение от opennews (?), 06-Сен-22, 23:34
После шести месяцев разработки представлен релиз проекта LLVM 15.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57739
Ответить \| Правка \| Cообщить модератору

Оглавление

Отличная новость Крутой прогресс за полгода , Анонн (?), 23:34 , 06-Сен-22, (1) +5

Плюсую За LLVM будущее, и скоро, надеюсь, выкинут наконец-то этот GCC на свалку, Xenia Joness (ok), 12:05 , 07-Сен-22, (34) –16

Чем он вам так насолил , Аноним (42), 12:39 , 07-Сен-22, (42)

Да она и про LLVM-то только название и слышала , Аноним (44), 12:42 , 07-Сен-22, (44) +3
Да куча недостатков - GNU C Language Extensions - здоровенный костыль поддержанн, Анонн (?), 15:51 , 07-Сен-22, (55) –3

FSF при помощи прежде всего GCC начал менять мир годах в 80ых и продолжает менят, аНОНИМ (?), 18:24 , 07-Сен-22, (65) +4

А знаешь почему Потому что они на момент создания llvm никому нафиг не вс лись , Аноним (66), 18:41 , 07-Сен-22, (66)

Зачем ты рассказываешь о том, в чём ничего не понимаешь Как же так - гцц подлый, срыватель_покровов (?), 00:22 , 08-Сен-22, (71) +2

Просто не все живут на мамкиной шее И идеалами сыт не будешь , Neon (??), 17:24 , 09-Сен-22, (102) +1
Одни лозунги А по факту 8212 единоличное создание своего диалекта си в стил, Тот_Самый_Анонимус (?), 06:16 , 14-Сен-22, (120)

Смотри, жертва пропаганды - Кроме gnuc другого си нет Никто не будет ничего пис, срыватель_покровов (?), 00:15 , 08-Сен-22, (70) –1

Гнус это всего лишь жалкая надстройка над си, которую добавили ядрописатели - пр, Аноним (66), 12:04 , 08-Сен-22, (80) –1

GPL - не свободный, потому что ограничивает твою свободу воровать , Аноним (91), 00:03 , 09-Сен-22, (91)

Свобода зарабатывать - это свобода воровать Чтобы заработать, предлагаете с н, Neon (??), 17:31 , 09-Сен-22, (103) +1

Хорошо сидеть на шее у сообщества, используя его инструменты, изображать из себя, Аноним (109), 09:38 , 10-Сен-22, (109)

Как можно украсть то, что принадлежит всему миру и отдано в безвозмездное пользо, Аноним (-), 01:11 , 11-Сен-22, (115)

Да ты чё Зачем ты, домохозяйка, о чём-то пытаешься рассуждать gnuc это и есть , срыватель_покровов (?), 02:03 , 09-Сен-22, (94) –1

С другой стороны нужно быть благодарным им за это все - иначе какой смысл было б, Анонн (?), 15:54 , 07-Сен-22, (56) +1

Не очень понятно, зачем нужно фиксировать промежуточный результат в виде объектн, adolfus (ok), 20:51 , 09-Сен-22, (107) +1

NIH-синдром на Java JIT нужно реализовать то, что было реализовано 20 лет назад, iZEN (ok), 14:46 , 10-Сен-22, (113)

Вайн задействует , Аноним (2), 23:39 , 06-Сен-22, (2)

https github com microsoft DirectXShaderCompiler - просто аттракцион невиданно, Аноним (2), 23:45 , 06-Сен-22, (5)

Видимо на DX все забили при наличии вулкана, вот и раздобрились , Аноним (-), 12:05 , 07-Сен-22, (35) +1

Ждём обновления ldc для dlang , Аноним (3), 23:39 , 06-Сен-22, (3) –1
А про ассемблер llvm-mc ничего не слышно Он совместим с gas, но весьма ограниче, lucentcode (ok), 23:39 , 06-Сен-22, (4) +1

Мне вот надо чтобы clang на инлайн асме, с интел синтаксисом на использовании of, Аноним (6), 04:16 , 07-Сен-22, (6) +2

Интел-стайл контр-интуитивен Особенно при косвенной адресации Закопать , Брат Анон (ok), 09:01 , 07-Сен-22, (17) +2

AT T-синтаксис просто ужасен и для набор и для чтения Его вообще не должно быть, Аноним (19), 09:30 , 07-Сен-22, (19) –2

У тебя синдром утёнка , Аноним (26), 10:29 , 07-Сен-22, (26) +1

У тебя Даннинг-Крюгер , Аноним (30), 11:09 , 07-Сен-22, (30) +8

Не, норм Не привычно после TASM MASM Fasm Nasm RosAsm и что там ещё юзал в моло, lucentcode (ok), 21:01 , 07-Сен-22, (68) +3

Правда Как там в AT T записывается eax ecx В Intel mov eax, ecx И поэтому в, Аноним (83), 13:27 , 08-Сен-22, (83) –1

Когда вы чему-то присваиваете какое-то значение с помощью команды mov move по су, lucentcode (ok), 13:13 , 10-Сен-22, (112)

Да пофиг на синтаксис Ассемблер очень мало, когда реально нужен, если только вы, Ванёк (?), 21:54 , 07-Сен-22, (69)

Чувство прекрасного против , Аноним (76), 10:53 , 08-Сен-22, (76)

Уж точно лучше, чем интелловский Если этот не должен существовать, тогда всех и, Брат Анон (ok), 13:45 , 08-Сен-22, (86) +1

Интел не регламентирует синтаксис offset - это Microsoft Есть синтаксисы Borl, n00by (ok), 10:10 , 07-Сен-22, (25)
Ага, а когда присваеваемое слева, а куда присваивают справа - нонсенс же , Аноним (44), 12:51 , 07-Сен-22, (47) +1

А на неинтел синтаксисе всё норм , Ванёк (?), 17:19 , 07-Сен-22, (59) –2

Не всё Но интел существенно хуже mov eax, ebx -- попробуйте здесь догадаться от, Брат Анон (ok), 13:48 , 08-Сен-22, (87) +2

Смесь английского с ивритом , Ванёк (?), 18:33 , 08-Сен-22, (90) –1

Народ, подскажите, пожалуйста, хороший транслятор из одного синтаксиса Ассемблер, Ванёк (?), 13:25 , 09-Сен-22, (100)

GAS это умеет , Ванёк (?), 13:29 , 09-Сен-22, (101)

И снижение производительности в несколько разчтобы поломать всю арифметику указа, ИмяХ (?), 07:39 , 07-Сен-22, (7) –2

Арифметика указателей для перехода между глобальными структурами - UB Если в ва, Аноним (8), 08:01 , 07-Сен-22, (8) +5

Нельзя быть не толерантным к злобным буратинам , EULA (?), 10:05 , 07-Сен-22, (24)

Надо быть толерантными ко всем буратинам, но злобных сажать в тюрьму, но делать , Аноним (30), 11:13 , 07-Сен-22, (31) +1

поломается так называемая динамическая арифметика, компиляторная будет работать,, Sw00p aka Jerom (?), 08:22 , 07-Сен-22, (9)
Несколько команд снизят производительность в несколько раз , Бывалый смузихлёб (?), 08:56 , 07-Сен-22, (16) +1

Не несколько команд Регистров не несколько Но в 2 раза вполне может С учётом , Брат Анон (ok), 09:03 , 07-Сен-22, (18)

Даже будучи смузихлёбом смутно припоминаю, что были команды для сохранения всех , Бывалый смузихлёб (?), 09:57 , 07-Сен-22, (23) –1

PUSHF опкод 9D сохраняет регистр флагов F В 64-х разрядном режиме тот же оп, n00by (ok), 10:51 , 07-Сен-22, (29) –2
Вы новость читали При чём тут сохранение на стеке, если речь в статье шла про в, Брат Анон (ok), 13:43 , 08-Сен-22, (85)
Эти команды чудовищно медленные и в тактах выигрыша не будет, только в объёме ко, Аноним (83), 13:57 , 08-Сен-22, (88)

Медленный Silvermont исполняет 2 две XOR за такт CALL - 1-2 такта RET - 1 та, n00by (ok), 10:37 , 07-Сен-22, (28) –3

Это же две команды И сколько их нужно всего И на сколько при этом упадёт эффек, Брат Анон (ok), 13:42 , 08-Сен-22, (84) +1

Что тут нужно, так это доказать утверждение 171 снижение производительности в , n00by (ok), 14:49 , 08-Сен-22, (89) –1

Там типичный эксперт А вот талмуд code Table 2-3 Skylake Microarchitecture Ex, n00by (ok), 10:33 , 07-Сен-22, (27) –1

А вот красавец который кроме wintel себе ничего представить не может и потому сч, Аноним (-), 12:08 , 07-Сен-22, (37) +2

А ещё я имею представление, сколько примерно команд находится в теле средней под, n00by (ok), 12:39 , 07-Сен-22, (43)

А что такое средняя подпрограмма Это типа средней температуры по больнице , Аноним (49), 12:53 , 07-Сен-22, (49)

Это та цифра, которую эксперты подставят в известную им формулу и наконец-то док, n00by (ok), 13:03 , 07-Сен-22, (51)

Вы все тут эксперды По факту нормальный OoO процессор, видя XOR reg,reg -- ниче, аНОНИМ (?), 18:20 , 07-Сен-22, (63) +1

Молодец, единственный кто осилил прочитать мануал Это удивительно - особенно на, срыватель_покровов (?), 00:29 , 08-Сен-22, (72)

По факту CodeAnalyst закопали всего лет десять назад, а без симуляции конвейера , n00by (ok), 13:13 , 08-Сен-22, (82)

Ты выше опозорился и пришёл сюда плакаться Какая архитектура, какой CodeAnalyst, срыватель_покровов (?), 02:05 , 09-Сен-22, (95)

Это что, выпуск экстерном нового актива 171 центра псих операций 187 Мануал, n00by (ok), 11:01 , 09-Сен-22, (97)

Вы слишком рано ответили Такие умозаключения разбиваются железным аргументом , n00by (ok), 13:04 , 08-Сен-22, (81)

Если небольшая функция, и она активно используется, и компилятор её не встроил , Ванёк (?), 12:37 , 07-Сен-22, (41) +2

Готовы показать пример такой функции , n00by (ok), 12:44 , 07-Сен-22, (45) –2

Если кто-то ходит по структуре по хардкоженым оффсетам, то где-то ошибка на этап, Аноним (21), 09:35 , 07-Сен-22, (21)

Есть вполне себе легальный offsetof , Аноним (92), 01:18 , 09-Сен-22, (92)

What is it, затравка Начальное значение А как быть с повторяемостью сборки Как б, Аноним (10), 08:25 , 07-Сен-22, (10)

Нашел The support can be enabled via the -frandomize-layout-seed or -frandom, Аноним (10), 08:36 , 07-Сен-22, (11) +2

Грандиозно отметили 50-тилетие языка, mumu (ok), 08:44 , 07-Сен-22, (14) +6

Ну и в чём прикол Наезжали всегда на паскалистов за их begin end Ну были 0 и , 1 (??), 09:31 , 07-Сен-22, (20)

В привидении типов Нельзя понять 1 это bool или int , mumu (ok), 12:02 , 07-Сен-22, (33)

пример , Sw00p aka Jerom (?), 07:46 , 08-Сен-22, (75) –1

Дефайн видите ли не меняет определенную математику Bool does, там есть определе, Аноним (49), 12:52 , 07-Сен-22, (48)

Давно уже пора довести до нормального состояния, чтобы всякие студенты не писали, Аноним (19), 09:36 , 07-Сен-22, (22)
Вы пишите В тексте написано При чем тут C 23 129318 , Аноним (36), 12:07 , 07-Сен-22, (36) +2

Да, писал конечно про C2X, при форматировании не ту часть удалил, mumu (ok), 12:10 , 07-Сен-22, (38)

Единственная функция LLVM 8212 чтобы GCC не спал, но это тоже полезно , Аноним (32), 11:58 , 07-Сен-22, (32) +3

Ты не в теме, Ллвм используется примерно во всех проприетарных компиляторах всег, Аноним (26), 12:14 , 07-Сен-22, (39) +2

Ну и кто теперь и дальше будет утверждать, что LLVM не проприетарщина , Аноним (44), 12:47 , 07-Сен-22, (46) +1
А я вот понимаю ein сompiler - не нужно держать ворох повторяющихся компиляторов, Аноним (52), 13:09 , 07-Сен-22, (52) –1
Ну и существенно проще добавлять поддержку новых архитектур или языков по сравне, Анонн (?), 15:44 , 07-Сен-22, (54)

В GCC как-то иначе , Ванёк (?), 17:06 , 07-Сен-22, (57) +1

Принципиально - нет Но если начать разбираться, то нюансов море GCC намного бол, Аноним (66), 18:22 , 07-Сен-22, (64) +1

Скрыто модератором, срыватель_покровов (?), 00:44 , 08-Сен-22, (74) –3

Скрыто модератором, срыватель_покровов (?), 00:38 , 08-Сен-22, (73)

Скрыто модератором, Аноним (76), 10:55 , 08-Сен-22, (77)
Скрыто модератором, Аноним (26), 11:04 , 08-Сен-22, (78)

С вероятностью 99 получится более эффективный машинный код, да и при разработке, Аноним (105), 20:09 , 09-Сен-22, (105) +1

уже 2022, а они только с 20 допиливают хаха, Аноним (40), 12:19 , 07-Сен-22, (40) +1

Уже время вам присоединится и показать миру как надо пилить , Roman (??), 12:54 , 07-Сен-22, (50)

К какому миру , Аноним (99), 12:59 , 09-Сен-22, (99)

А теперь представьте, что надо написать свой собственный компилятор языка с с, Аноним (36), 13:42 , 07-Сен-22, (53)

Значит, что то давно не так в С королевстве И развитие его идет в какую то не, Neon (??), 17:47 , 09-Сен-22, (104)

Да, у С , впрочем как и у любого другого языка есть проблемы, но утверждать, чт, Аноним (36), 10:30 , 10-Сен-22, (110)

Как оно по производительности генерируемого кода по сравнению с GCC, ICC, MSVC, , Ванёк (?), 17:10 , 07-Сен-22, (58)

Без оптимизаций - влёт,а так жсс рулит,но это было с год назад,а то и больше , Аноним (79), 11:22 , 08-Сен-22, (79)
Про PGO не скажу, но на обычной компиляции clang и gcc где-то рядом - в одних сл, Аноним (92), 01:29 , 09-Сен-22, (93) +1

clang в хламину сливает gcc Обычно однорукие бандиты даже замерить нормально ко, срыватель_покровов (?), 02:15 , 09-Сен-22, (96) +1

Нет в gcc такой фичи Есть ручное клонирование и маркировка функций для разных н, Аноним (108), 03:14 , 10-Сен-22, (108) +1

То же самое можно сделать в любом компиляторе с помощью ifdef __инструкции__ _, Ванёк (?), 13:13 , 10-Сен-22, (111)

Вопрос на засыпку в чем разница между директивами препроцессора и runtime dispa, Аноним (118), 02:13 , 12-Сен-22, (118)

Если прямо действительно необходимо runtime dispatch, то помимо директив препроц, Ванёк (?), 14:35 , 12-Сен-22, (119)

Не используйте LLVM, он нужен пермиссивщикам и проприетарщикам , Аноним (-), 19:11 , 10-Сен-22, (114) +1

Не используйте GNU GPL, он нужен пермиссивщикам и проприетарщикам Пофиксил, не , Аноним (-), 01:16 , 11-Сен-22, (116) –1

Джва года ждал , anonima (?), 10:59 , 11-Сен-22, (117)

Сообщения [Сортировка по времени | RSS]

1. "Релиз набора компиляторов LLVM 15.0" +5 +/–

Сообщение от Анонн (?), 06-Сен-22, 23:34

Отличная новость! Крутой прогресс за полгода.

Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз набора компиляторов LLVM 15.0" –16 +/–

Сообщение от Xenia Joness (ok), 07-Сен-22, 12:05

> Отличная новость! Крутой прогресс за полгода.
Плюсую. За LLVM будущее, и скоро, надеюсь, выкинут наконец-то этот GCC на свалку истории

Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (42), 07-Сен-22, 12:39

Чем он вам так насолил?

Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз набора компиляторов LLVM 15.0" +3 +/–

Сообщение от Аноним (44), 07-Сен-22, 12:42

Да она и про LLVM-то только название и слышала.

Ответить | Правка | Наверх | Cообщить модератору

55. "Релиз набора компиляторов LLVM 15.0" –3 +/–

Сообщение от Анонн (?), 07-Сен-22, 15:51

Да куча недостатков:
- GNU C Language Extensions - здоровенный костыль поддержанный (изначально) только в одном компиляторе и как следствие невозможность сборки ядра другими. Прямо extend в стиле microsoft'а.
- здоровенный монолит - максимальная связность и сложность расширения
- отстойная огороженная лицензия

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

65. "Релиз набора компиляторов LLVM 15.0" +4 +/–

Сообщение от аНОНИМ (?), 07-Сен-22, 18:24

FSF при помощи прежде всего GCC начал менять мир годах в 80ых и продолжает менять до сих пор и результатами этого пользуются все без исключения люди, даже если они не догадываются об этом.
У шланга кол-во поддерживаемых архитектур примерно на порядок (десятичный) меньше чем у GCC.
Лицензия GPL -- лучшая лицензия для открытого софта, а ненавидят её только проприерасты, которые только и мечтают о том, чтобы безнаказанно *красть* (брать и закрывать) чужой открытый код.

Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (66), 07-Сен-22, 18:41

> У шланга кол-во поддерживаемых архитектур
А знаешь почему? Потому что они на момент создания llvm никому нафиг не вс@лись!
Это куча всякого хлама который можно найти только в музеях, а выпилить из gcc не решаются, потому что "а вдруг что-то сломаем по дороге".
Хотя все даже круче - gcc поддерживает бекенды для архитектур, которые никогда не были реализованы в железе - секция M в https://gcc.gnu.org/backends.html.

Ответить | Правка | Наверх | Cообщить модератору

71. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от срыватель_покровов (?), 08-Сен-22, 00:22

Зачем ты рассказываешь о том, в чём ничего не понимаешь? Как же так - гцц подлый монолит не расширяемый, а он поддерживает множество архитектур?
>выпилить из gcc не решаются, потому что "а вдруг что-то сломаем по дороге".
Зачем домохозяйка пытается рассуждать о коде? Как раз таки всё наоборот.
>бекенды для архитектур, которые никогда не были реализованы в железе
wasm в желе покажешь?

Ответить | Правка | Наверх | Cообщить модератору

102. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Neon (??), 09-Сен-22, 17:24

> Лицензия GPL -- лучшая лицензия для открытого софта, а ненавидят её только проприерасты
Просто не все живут на мамкиной шее. И идеалами сыт не будешь.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

120. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Тот_Самый_Анонимус (?), 14-Сен-22, 06:16

Одни лозунги. А по факту — единоличное создание своего диалекта си (в стиле майкрософта). И ни один поборник стандартов не вякнет: ведь этим свои занимаются. Вот если бы майки это сделали, то вони бы стояло на сотню комментов.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

70. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от срыватель_покровов (?), 08-Сен-22, 00:15

Смотри, жертва пропаганды.
- Кроме gnuc другого си нет. Никто не будет ничего писать на этом днище. И да - шланг это именно что gnuc/cpp компилятор. Как и сам драйвер там 1в1 повторяет гцц. И да, свободный код не может быть вендорлоком.
- Пустые сказки от домохозяек. Мне даже лень спорить на эту тему - пруфы ты всё равно не покажешь.
- Лицензия наиболее свободная. Единственное что у гцц есть из проблем - это во многом столман-шиза древняя о том, что cpp-фронт будут воровать.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

80. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Аноним (66), 08-Сен-22, 12:04

Гнус это всего лишь жалкая надстройка над си, которую добавили ядрописатели - просто не шмогли в стандарт (ну или вынуждены были добавить, потому что стандарт отстой). Такая же огороженная надстройка как "Microsoft extensions to C", которую добавили майки MSVC. И такой же вендорлок.
> Лицензия наиболее свободная
Ну да, ну да, "свобода это рабство".
Свободные лицензии - это MIT, BSD, MPL, CCA и аналогичные. А ваша GPL - открытая, но не свободная.

Ответить | Правка | Наверх | Cообщить модератору

91. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (91), 09-Сен-22, 00:03

GPL - не свободный, потому что ограничивает твою "свободу воровать"?

Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Neon (??), 09-Сен-22, 17:31

Свобода зарабатывать - это свобода воровать ?! Чтобы заработать, предлагаете с нуля всё лично самому писать, начиная с драйверов и биос с операционкой. Хорощо рассуждать о светлых идеалах, сидя на шее у родителей, ничего сам не зарабатывая.

Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (109), 10-Сен-22, 09:38

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

Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (-), 11-Сен-22, 01:11

Как можно украсть то, что принадлежит всему миру и отдано в безвозмездное пользование с единственной оговоркой: не требовать гарантий?!
Это Вам расхищение гуманитарки мерещится.
БСД - истинная свобода!

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

94. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от срыватель_покровов (?), 09-Сен-22, 02:03

>Гнус это всего лишь жалкая надстройка над си
Да ты чё? Зачем ты, домохозяйка, о чём-то пытаешься рассуждать? gnuc это и есть си. Это даже деюро закреплено тем, что стандарты после gnuc просто копипастили в себя куски gnuc.
>которую добавили ядрописатели
Опять же опозорился. Ядрописатели это лишь одни из.
>просто не шмогли в стандарт
Как в бездарный мусор можно не мочь? Скорее они не хотели жрать дерьмо и "писать" на то на чём только лабу можно написать. Но ты даже и лабу не писал.
>(ну или вынуждены были добавить, потому что стандарт отстой).
Им ненужно ничего добавлять - это стандарт вынужден быть у них всё тащить, чтобы хотя бы быть похожим на си. А gnuc как был так и остался си, а стандарт лишь жалкая пародия.
>Такая же огороженная надстройка как "Microsoft extensions to C", которую добавили майки MSVC. И такой же вендорлок.
Жертва пропаганды - никаких расширений от маздайсофта не существует. Ты опять опозорился. То, что ты где-то там слышал - это вообще не про си.
И уж тем более, жертва пропаганды, gnuc не может являться вердорлоком.
>Ну да, ну да, "свобода это рабство".
Для тебя да.
>А ваша GPL - открытая, но не свободная.
Нет, гпл это именно что свободная лицензия. Просто она тебе не позволяет воровать чужой код от того у тебя жопа болит. Вернее даже не у тебя - ты просто раб хозяина и ретранслируешь его волю.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

56. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Анонн (?), 07-Сен-22, 15:54

С другой стороны нужно быть благодарным им за это все - иначе какой смысл было бы создавать llvm.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

107. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от adolfus (ok), 09-Сен-22, 20:51

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

113. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от iZEN (ok), 10-Сен-22, 14:46

NIH-синдром на Java JIT: нужно реализовать то, что было реализовано 20 лет назад, но на новом технологическом уровне, с задействованием в 100 раз большей процессорной мощности и  в 1000 раз большей потребной памяти.

Ответить | Правка | Наверх | Cообщить модератору

2. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (2), 06-Сен-22, 23:39

>Добавлена экспериментальная поддержка Си-подобного языка HLSL (High-Level Shader Language), применяемого в DirectX для написания шейдеров.
Вайн задействует?

Ответить | Правка | Наверх | Cообщить модератору

5. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (2), 06-Сен-22, 23:45

https://github.com/microsoft/DirectXShaderCompiler - просто аттракцион невиданной щедрости какой-то

Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (-), 07-Сен-22, 12:05

Видимо на DX все забили при наличии вулкана, вот и раздобрились...

Ответить | Правка | Наверх | Cообщить модератору

3. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Аноним (3), 06-Сен-22, 23:39

Ждём обновления ldc для dlang.

Ответить | Правка | Наверх | Cообщить модератору

4. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от lucentcode (ok), 06-Сен-22, 23:39

А про ассемблер llvm-mc ничего не слышно? Он совместим с gas, но весьма ограниченно. .S файлы сформированные с помощью llvm с помощью gas собираются на ура, а вот файлы созданные для gas не в 100% случаев собираются llvm-mc, что навевает на мысль, что ассемблер из проекта llvm не на 100% совместим с gas. Хотя, если писать на ассемблере с учётом небольших нюансов, можно использовать одни и те же файлы и под gas, и под llvm-mc.

Ответить | Правка | Наверх | Cообщить модератору

6. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Аноним (6), 07-Сен-22, 04:16

Мне вот надо чтобы clang на инлайн асме, с интел синтаксисом на использовании offset не крашился.

Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Брат Анон (ok), 07-Сен-22, 09:01

Интел-стайл контр-интуитивен. Особенно при косвенной адресации. Закопать.

Ответить | Правка | Наверх | Cообщить модератору

19. "Релиз набора компиляторов LLVM 15.0" –2 +/–

Сообщение от Аноним (19), 07-Сен-22, 09:30

AT&T-синтаксис просто ужасен и для набор и для чтения. Его вообще не должно быть нигде от слова ВАЩЕСОВСЕМ.

Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (26), 07-Сен-22, 10:29

У тебя синдром утёнка.

Ответить | Правка | Наверх | Cообщить модератору

30. "Релиз набора компиляторов LLVM 15.0" +8 +/–

Сообщение от Аноним (30), 07-Сен-22, 11:09

У тебя Даннинг-Крюгер.

Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз набора компиляторов LLVM 15.0" +3 +/–

Сообщение от lucentcode (ok), 07-Сен-22, 21:01

> 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 синтаксис не зашёл. А была бы нужна, оценили бы единный подход к организации написания кода под разные платформы с помощью одного инструмента, а не россыпи разных, специфичных только для своей архитектуры.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

83. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Аноним (83), 08-Сен-22, 13:27

>так, как было бы удобно программисту более высокоуровневого ЯП, вроде C
Правда? Как там в AT&T записывается eax = ecx ? В Intel mov eax, ecx.
>а потом при освоении новых чипов изучая только набор их инструкций и
>опкодов и небольшие нюансы, вы примерно в одном и том же стиле с одним
>инструментом сможете писать на asm под кучу архитектур
И поэтому в gcc есть куча костылей, чтобы ассемблер не использовать никогда. Даже если пишешь архитектурно-зависимые вещи. Похоже даже разработчики gcc ненавидят GAS.
>Но, у мультитула есть свой козырь в рукаве: универсальность
Что может быть универсальнее fasm ? Это зло вообще всё с помощью макросов делает. Другой вопрос, что он появился поздно, когда даже микроконтроллеры перестали программировать на Ассемблере. Но на нём хотя бы пишут энтузиасты, а кто и что пишет на GAS ? Даже OpenSSL злоупотребляющий Ассемблером не пишут на GAS, а на своём универсальном perl-Ассемблере, который можно транслировать хоть в MASM, хоть в GAS... и да, у них интеловский порядок регистров.

Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от lucentcode (ok), 10-Сен-22, 13:13

> Правда? Как там в 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 на такое способен.

Ответить | Правка | Наверх | Cообщить модератору

69. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Ванёк (?), 07-Сен-22, 21:54

Да пофиг на синтаксис. Ассемблер очень мало, когда реально нужен, если только вы не занимаетесь дизассемблированием))

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

76. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (76), 08-Сен-22, 10:53

Чувство прекрасного против.

Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Брат Анон (ok), 08-Сен-22, 13:45

> AT&T-синтаксис просто ужасен и для набор и для чтения. Его вообще не
> должно быть нигде от слова ВАЩЕСОВСЕМ.
Уж точно лучше, чем интелловский. Если этот не должен существовать, тогда всех интелловцев вообще надо сжечь (не призывы к терроризму, не разжигание социальной ненависти).

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

25. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от n00by (ok), 07-Сен-22, 10:10

> Интел-стайл контр-интуитивен. Особенно при косвенной адресации. Закопать.
Интел не регламентирует синтаксис. offset - это Microsoft. Есть синтаксисы (Borland ideal, fasm), где приняты [] как и в Си.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

47. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (44), 07-Сен-22, 12:51

Ага, а когда присваеваемое слева, а куда присваивают справа - нонсенс же.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

59. "Релиз набора компиляторов LLVM 15.0" –2 +/–

Сообщение от Ванёк (?), 07-Сен-22, 17:19

А на неинтел синтаксисе всё норм?

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

87. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Брат Анон (ok), 08-Сен-22, 13:48

> А на неинтел синтаксисе всё норм?
Не всё. Но интел существенно хуже.
mov eax, ebx -- попробуйте здесь догадаться откуда куда тут передаётся содержимое? Вы книгу также зигзагом читаете? Это я ещё режимов адресации не касался.

Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Ванёк (?), 08-Сен-22, 18:33

Смесь английского с ивритом???

Ответить | Правка | Наверх | Cообщить модератору

100. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Ванёк (?), 09-Сен-22, 13:25

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

101. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Ванёк (?), 09-Сен-22, 13:29

GAS это умеет?

Ответить | Правка | Наверх | Cообщить модератору

7. "Релиз набора компиляторов LLVM 15.0" –2 +/–

Сообщение от ИмяХ (?), 07-Сен-22, 07:39

>>обнуление всех использованных в функции регистров CPU перед возвращением управления
И снижение производительности в несколько раз
>>рандомизация размещения в памяти структур
чтобы поломать всю арифметику указателей

Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз набора компиляторов LLVM 15.0" +5 +/–

Сообщение от Аноним (8), 07-Сен-22, 08:01

Арифметика указателей для перехода между глобальными структурами - UB. Если в вашем коде есть такая работа с указателями, то вы ССЗБ

Ответить | Правка | Наверх | Cообщить модератору

24. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от EULA (?), 07-Сен-22, 10:05

Нельзя быть не толерантным к злобным буратинам.

Ответить | Правка | Наверх | Cообщить модератору

31. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (30), 07-Сен-22, 11:13

Надо быть толерантными ко всем буратинам, но злобных сажать в тюрьму, но делать это толерантно.

Ответить | Правка | Наверх | Cообщить модератору

9. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Sw00p aka Jerom (?), 07-Сен-22, 08:22

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

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

16. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Бывалый смузихлёб (?), 07-Сен-22, 08:56

Несколько команд снизят производительность в несколько раз ?

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

18. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Брат Анон (ok), 07-Сен-22, 09:03

Не несколько команд. Регистров не несколько. Но в 2 раза вполне может. С учётом относительно медленной оперативной памяти не так страшно, но размер программ вырастает, кеш используется менее эффективно.

Ответить | Правка | Наверх | Cообщить модератору

23. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Бывалый смузихлёб (?), 07-Сен-22, 09:57

Даже будучи смузихлёбом смутно припоминаю, что были команды для сохранения всех регистров в стеке-восстановления всех регистров из стека
Вроде popad-pushad. Что-то подобное, вроде бы, даже под 64 бита было( pushfq ? )

Ответить | Правка | Наверх | Cообщить модератору

29. "Релиз набора компиляторов LLVM 15.0" –2 +/–

Сообщение от n00by (ok), 07-Сен-22, 10:51

PUSHF (опкод 9D) сохраняет регистр флагов (F). В 64-х разрядном режиме тот же опкод называется PUSHFQ и сохраняет расширенный регистр флагов RFLAGS. POPA довольно медленная, вместо неё рекомендовалось использовать серию POP или MOV. В 64-х разрядном режиме её убрали. Но сохранять-восстанавливать регистры как раз не надо (это упростило бы создание ROP-цепочек), обнулять быстрее (нет работы с памятью).

Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Брат Анон (ok), 08-Сен-22, 13:43

> Даже будучи смузихлёбом смутно припоминаю, что были команды для сохранения всех регистров
> в стеке-восстановления всех регистров из стека
> Вроде popad-pushad. Что-то подобное, вроде бы, даже под 64 бита было( pushfq
> ? )
Вы новость читали? При чём тут сохранение на стеке, если речь в статье шла про возможность утечки данных по остаточным данным в регистрах?

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

88. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (83), 08-Сен-22, 13:57

>Вроде popad-pushad
Эти команды чудовищно медленные и в тактах выигрыша не будет, только в объёме кода, плюс нужно завершить все спекулятивные операции. Там ещё есть команды для сохранения FPU/SSE и это уже настолько большая боль, что ОС старается по возможности его не сохранять даже при переключении процессов/потоков.
>pushfq
Это инструкция сохранения 64-битного регистра флагов. Инструкций сохранения всех регистров на архитектуре  x86-64 совсем нет. Даже тех, что были на x86-32 вроде pusha, pushad, опкод 0x60 просто пуст.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

28. "Релиз набора компиляторов LLVM 15.0" –3 +/–

Сообщение от n00by (ok), 07-Сен-22, 10:37

> Не несколько команд. Регистров не несколько. Но в 2 раза вполне может.
Медленный Silvermont исполняет 2 (две) XOR за такт. CALL - 1-2 такта. RET - 1 такт. Так что прежде чем писать что-то с аватаркой Ленина, хорошо бы последовать его примеру и три раза поучиться арифметике.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

84. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Брат Анон (ok), 08-Сен-22, 13:42

>> Не несколько команд. Регистров не несколько. Но в 2 раза вполне может.
> Медленный Silvermont исполняет 2 (две) XOR за такт. CALL - 1-2 такта.
> RET - 1 такт. Так что прежде чем писать что-то с
> аватаркой Ленина, хорошо бы последовать его примеру и три раза поучиться
> арифметике.
Это же две команды? И сколько их нужно всего? И на сколько при этом упадёт эффективность кеша?

Ответить | Правка | Наверх | Cообщить модератору

89. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от n00by (ok), 08-Сен-22, 14:49

>>> Не несколько команд. Регистров не несколько. Но в 2 раза вполне может.
>> Медленный Silvermont исполняет 2 (две) XOR за такт. CALL - 1-2 такта.
>> RET - 1 такт. Так что прежде чем писать что-то с
>> аватаркой Ленина, хорошо бы последовать его примеру и три раза поучиться
>> арифметике.
> Это же две команды? И сколько их нужно всего?
Что тут нужно, так это доказать утверждение «снижение производительности в несколько раз». Доказывает его заявитель. Я понимаю, что доказательство невозможно даже для вырожденного частного случая, потому вместо него будет всевозможная чушь и плюсики самому себе.
> И на сколько при этом упадёт эффективность кеша?
Кеш данных не имеет отношения к вопросу. Вообще. Но человеку, кто видел асм лишь на картинках, я объяснять не берусь. Да, начиная демагогию, будь готов к зеркальному ответу.

Ответить | Правка | Наверх | Cообщить модератору

27. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от n00by (ok), 07-Сен-22, 10:33

> Несколько команд снизят производительность в несколько раз ?
Там типичный эксперт. А вот талмуд:

Table 2-3. Skylake Microarchitecture Execution Units and Representative Instructions
Execution  # of   Instructions
Unit        Unit
ALU         4     add, and, cmp, or, test, xor, movzx, movsx, mov, (v)movdqu, (v)movdqa, (v)movap*, (v)movup*

Для обнуления используется XOR, в наличии 4 исполнительных устройства (то есть могут исполняться параллельно).

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

37. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Аноним (-), 07-Сен-22, 12:08

А вот красавец который кроме wintel себе ничего представить не может и потому считает что талмуд на скайлэйк это универсальный ответ на все вопросы вселенной.

Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от n00by (ok), 07-Сен-22, 12:39

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

Ответить | Правка | Наверх | Cообщить модератору

49. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (49), 07-Сен-22, 12:53

А что такое средняя подпрограмма? Это типа средней температуры по больнице? :)

Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от n00by (ok), 07-Сен-22, 13:03

Это та цифра, которую эксперты подставят в известную им формулу и наконец-то докажут тезис «снижение производительности в несколько раз». ;)

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от аНОНИМ (?), 07-Сен-22, 18:20

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

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

72. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от срыватель_покровов (?), 08-Сен-22, 00:29

Молодец, единственный кто осилил прочитать мануал. Это удивительно - особенно на фоне всех клоунов выше. Правда всё остальное, кроме самого факта существования мапинга - чушь. На "алу" шедулит шедулер, который работает уже с физическими регистрами. Но то ладно.
Важно то, что никому нахрен не упёрся факт исполнения. Если говорить про такое днище как х86, то уже тысячи лет оно упирается во фронтенд. А что-то исполняется/нет это не влияет на производительность - если только на энергопотребление.

Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от n00by (ok), 08-Сен-22, 13:13

> Если говорить про
> такое днище как х86, то уже тысячи лет оно упирается во
> фронтенд.
По факту CodeAnalyst закопали всего лет десять назад, а без симуляции конвейера кто  ̶п̶е̶р̶в̶ы̶й̶ ̶н̶а̶д̶е̶л̶ ̶х̶а̶л̶а̶т̶ ̶т̶о̶т̶ ̶и̶ ̶п̶с̶и̶х̶и̶а̶т̶р̶  громче всех крикнет «клоуны» то и прав. Так что знайте на будущее: х86 это 16-ти разрядная архитектура, кто скажет иначе - тот не видел у мануала даже название.

Ответить | Правка | Наверх | Cообщить модератору

95. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от срыватель_покровов (?), 09-Сен-22, 02:05

Ты выше опозорился и пришёл сюда плакаться? Какая архитектура, какой CodeAnalyst, какой "16-ти разрядная"? Ты от позора решил просто рандомные базворды из гугла пастить?

Ответить | Правка | Наверх | Cообщить модератору

97. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от n00by (ok), 09-Сен-22, 11:01

Это что, выпуск экстерном нового актива «центра псих операций»? Мануал, который вышеописавшийся друг мракобесия ни разу в глаза не видел, называется 64-ia-32-architectures-optimization-manual.pdf  Соответственно и архитектура - IA32, а не как пытается внушить вон тот член секты Cвидетелей i8086.

Ответить | Правка | Наверх | Cообщить модератору

81. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от n00by (ok), 08-Сен-22, 13:04

Вы слишком рано ответили. Такие умозаключения разбиваются железным аргументом «А вот красавец который кроме wintel себе ничего представить не может». Потому про вещи типа сброса зависимостей по данным (xor влияет на флаги) и гипотетическую возможность получить выигрыш по скорости за счёт отброса ненужной ветки (которая без xor бы спекулятивно исполнилась) я даже заикаться не стал.
Если же возьмём общий случай и придумаем фантастическую архитектуру, то можно накидать вот такой минимальный пример:
R1 <- arg1
R2 <- arg2
R3 <- R1 + R2
R1 <- 0
R2 <- 0
5 команд из которых 2 «тормозят в несколько раз» (ц) 3 оставшиеся. Это без учёта вызова и возврата. Я не знаю, как и что тут надо поделить, что бы получить что-то заметно больше чем 1,5. Но точно знаю, что вон тот крендель в кепочке должен одурачить пролетариат, иначе ему не получить власть. Ну, например, он может дописать R3 <- 0 (используется же регистр!) и я сяду в лужу. ;) А вон тот Ванёк ничего не сможет дописать - он уже признался, что эксгибиционист.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

41. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Ванёк (?), 07-Сен-22, 12:37

Если небольшая функция, и она активно используется, и компилятор её не встроил (inline), то может и в несколько раз...

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

45. "Релиз набора компиляторов LLVM 15.0" –2 +/–

Сообщение от n00by (ok), 07-Сен-22, 12:44

Готовы показать пример такой функции?

Ответить | Правка | Наверх | Cообщить модератору

21. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (21), 07-Сен-22, 09:35

>>>рандомизация размещения в памяти структур
> чтобы поломать всю арифметику указателей
Если кто-то ходит по структуре по хардкоженым оффсетам, то где-то ошибка на этапе дизайна. Если это действительно нужно (какой-то бинарный протокол), то этому атрибуту явно там не место
А так фича уже старая, просто в кланге поддержка появилась только сейчас. Ваши эти линуксы давно используют этот атрибут для важных структур, если сборка идёт с гцц

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

92. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (92), 09-Сен-22, 01:18

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

Ответить | Правка | Наверх | Cообщить модератору

10. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (10), 07-Сен-22, 08:25

> установки затравки
What is it, затравка?
Начальное значение?
А как быть с повторяемостью сборки?
Как быть если эту "затравку" узнает тот, кому бы знать ее не надо?

Ответить | Правка | Наверх | Cообщить модератору

11. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Аноним (10), 07-Сен-22, 08:36

Нашел:
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ообщить модератору

14. "Релиз набора компиляторов LLVM 15.0" +6 +/–

Сообщение от mumu (ok), 07-Сен-22, 08:44

> C++23. реализованы ключевые слова false и true
Грандиозно отметили 50-тилетие языка

Ответить | Правка | Наверх | Cообщить модератору

20. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от 1 (??), 07-Сен-22, 09:31

Ну и в чём прикол ? Наезжали всегда на паскалистов за их begin end. Ну были 0 и 1. Эстеты их превращали дефайном в false и true.

Ответить | Правка | Наверх | Cообщить модератору

33. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от mumu (ok), 07-Сен-22, 12:02

В привидении типов. Нельзя понять 1 это bool или int.

Ответить | Правка | Наверх | Cообщить модератору

75. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Sw00p aka Jerom (?), 08-Сен-22, 07:46

пример?

Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (49), 07-Сен-22, 12:52

Дефайн видите ли не меняет определенную математику. Bool does, там есть определенные гарантии поведения. Даже в случаях когда integer'у под ним присваивают (по крайней мере, пытаются) иные значения.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

22. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (19), 07-Сен-22, 09:36

Давно уже пора довести до нормального состояния, чтобы всякие студенты не писали пародии на С++

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

36. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Аноним (36), 07-Сен-22, 12:07

Вы пишите:
>>> C++23. реализованы ключевые слова false и true <<<
В тексте написано:
>>> Для языка Си реализованы: ... ключевые слова false и true ... <<<
При чем тут C++23?🤦

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

38. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от mumu (ok), 07-Сен-22, 12:10

Да, писал конечно про C2X, при форматировании не ту часть удалил

Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз набора компиляторов LLVM 15.0" +3 +/–

Сообщение от Аноним (32), 07-Сен-22, 11:58

Единственная функция LLVM — чтобы GCC не спал, но это тоже полезно.

Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз набора компиляторов LLVM 15.0" +2 +/–

Сообщение от Аноним (26), 07-Сен-22, 12:14

Ты не в теме, Ллвм используется примерно во всех проприетарных компиляторах всего последние лет 15 уже так точно. Шейдеры, куда, жит, фортран. Гцц вечно в догоняющих. Но, что касается си и частично плюсов, у гцц до сих пор получается ощутимо более эффективный код (особенно, при задействовании пго). Не понимаю этого нездорового вендузячьего желания собирать всё шлангом, из того что я видел, майкрософтовский компилятор хоть и отставал по возможностям на десятилетия, но генерировал код не хуже шланга. Реальная его проблема это совершенно неосмысленные сообщения об ошибках.

Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (44), 07-Сен-22, 12:47

>Ллвм используется примерно во всех проприетарных компиляторах всего последние лет 15 уже так точно
Ну и кто теперь и дальше будет утверждать, что LLVM не проприетарщина?

Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Аноним (52), 07-Сен-22, 13:09

>Не понимаю этого нездорового вендузячьего желания собирать всё шлангом
А я вот понимаю.
ein сompiler - не нужно держать ворох повторяющихся компиляторов. Ставим один компилятор из официальных деб-репозиториев и собираем подо все платформы, под какие пожелаем. И имеем на всех платформах последние фичи языка C++. Флаги компиляции тоже почти одинаковы. Очень удобно.
ein bytecode - все инструменты используют одно и то же представление. Благодаря тому, что создатели LLVM не копирастничают, сторонние инструменты вообще могут существовать, потому что если бы обязали всех использовать GPL, то многие бы просто сказали "ну тогда мы наш инструмент не опубликуем вообще". И позволяет сторонним инструментам быть отдельными программами, работающими с IR по-своему. Создатели gcc же решили усложнить, чтобы все статически линковались с GCC. Недружественный жест, создающий кучу практических проблем. "Ну ОК, значит не будем использовать GCC", решили адекваты, и теперь у нас есть Clang.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

54. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Анонн (?), 07-Сен-22, 15:44

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

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

57. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Ванёк (?), 07-Сен-22, 17:06

В GCC как-то иначе?

Ответить | Правка | Наверх | Cообщить модератору

64. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (66), 07-Сен-22, 18:22

Принципиально - нет. Но если начать разбираться, то нюансов море.
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ообщить модератору

74. Скрыто модератором –3 +/–

Сообщение от срыватель_покровов (?), 08-Сен-22, 00:44

Ты ничего о них не знаешь - жертва пропаганды. Зачем ты позоришься?
Монолитная помойка - это именно что ллвм. Другое дело, что ллвм использует c++/си с классами, кодогенерацию. Он тупо проще нежели гцц.
Но основная причина это шха-лицензия и то, что в лввм - это туллинг для создания компиляторов. Гцц таким не является. Это именно компилятор, а не тулинг.

>и что поддерживает LLVM:
Жертва пропаганды, насколько же ты нелепая. Ничего из этого ллвм не поддерживает. Это всё внешний мусор. А то, что ты линкуешь для гцц - это его части. Частью llvm по-сути является только шланг.

Поэтому именно в гцц фронтов больше. А всё эти сказки, которую ты пастишь - это не фронты. Это просто "где используется ллвм".
И даже здесь ты не смог опозориться. Ты не смог даже отфильтровать список. Допустим на ту же cuda.

Ответить | Правка | Наверх | Cообщить модератору

73. Скрыто модератором +/–

Сообщение от срыватель_покровов (?), 08-Сен-22, 00:38

llvm и подхватил эпл для того, чтобы делать проприетарщину. Ты и сам подтвердил почему. гцц нельзя украсть, хотя эпл/нвидия и прочие вендоры ранее воровали. До того как им это запретили.
Поэтому смысл ллвм только в одном - воровать. Будь можно воровать гцц - никому ллвм не был нужен. На самом деле там причин вторичных выбора в пользу ллвм больше в шланге.
>Шейдеры, куда, жит, фортран.
Какой жит - в гцц тыщу лет был жит. Какие шейдеры/какая куда - о чём ты, домохозяйка. Куда всегда была на гцц и та куда так и осталась. Фортран вообще какой-то мусор.
Нвидия же не реализовывала куду/прочее в ллвм - он мусор. Она создала ptx и теперь llvm лишь генерирует ir для нвидия-блобов. И да - гцц умеет в ptx.
>Гцц вечно в догоняющих.
Да ты чё. Догоняющих кого, жертва пропаганды?
>Но, что касается си и частично плюсов, у гцц до сих пор получается ощутимо более эффективный код (особенно, при задействовании пго).
Я тебе открою тайну, жертва пропаганды, но гцц совершеннее во всём. Он и код собирает быстрее и конфигурируется лучше и архитектурно более совершенен и поддержка языков лучше и код получается быстрее и анализатор/сообщения об ошибках там куда лучше.

>Не понимаю этого нездорового вендузячьего желания собирать всё шлангом, из того что я видел, майкрософтовский компилятор хоть и отставал по возможностям на десятилетия, но генерировал код не хуже шланга. Реальная его проблема это совершенно неосмысленные сообщения об ошибках.
Да тут у нас маздайчонок нарисовался. Жертва пропаганды - маздайский мусор сливает шлангу во всём. Поэтому маздай пытается воровать edg/llvm/clang, чтобы на них заменять свой бездарный мусор.
Это как была история с ослом. Уже практически полностью маздайский мусор переделан на edg/clang/llvm, как уже было выше сказано. Скоро там останется одно название.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

77. Скрыто модератором +/–

Сообщение от Аноним (76), 08-Сен-22, 10:55

llvm эплу нужен чтобы мигрировать с x86 на arm и дальше по списку.

Ответить | Правка | Наверх | Cообщить модератору

78. Скрыто модератором +/–

Сообщение от Аноним (26), 08-Сен-22, 11:04

Не уверен, о чём ты тут затираешь и зачем, но cuda compiler от nvidia это именно что форк llvm7. Сам clang поддерживает генерацию ptx с 3 версии примерно, при этом, я вообще не видел, что бы кто-нибудь применял gcc с этими целями (ни одного проекта, все требуют nvcc или хотя бы clang для результатов похуже), и nvcc -- не gcc (и, вроде, никогда не был? лет 15 точно). Видимо, остальная твоя информация имеет примерно тот же уровень достоверности -- ты никогда ни с чем не работал, а обзываешь других домохозяйками. А фортран широко используется в математических вычислениях и сегодня, очень актуально для распараллеливания на кучи больших жирных нод суперкомпьютеров (там часто как раз nvidia есть).
>сливает
Не, я лично билдил бинари для маздайки и сравнивал производительность и оптимизации, поэтому, не соглашусь. Ллвм там прижился, поскольку что у него не было проблем с раскруткой исключений (они были у гцц), ну, и по мелочи.

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

105. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (105), 09-Сен-22, 20:09

> Не понимаю этого нездорового вендузячьего желания собирать всё шлангом
С вероятностью 99% получится более эффективный машинный код, да и при разработке кросс-платформенного софта использование одного компилятора на всех платформах даёт некоторые плюсы (меньше компиляторо-специфичных нюансов типа проивозительности сгенерированного кода, багов самого компилятора и т.п.).
> майкрософтовский компилятор хоть и отставал по возможностям на десятилетия, но генерировал код не хуже шланга
Если майкрософтовский компилятор сгенерировал код не хуже шланга, то вам просто повезло. Примеров наподобие https://godbolt.org/z/orMv61YjE можно найти/придумать немало.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

40. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (40), 07-Сен-22, 12:19

уже 2022, а они только с++20 допиливают. хаха

Ответить | Правка | Наверх | Cообщить модератору

50. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Roman (??), 07-Сен-22, 12:54

Уже время вам присоединится и показать миру как надо "пилить"

Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (99), 09-Сен-22, 12:59

К какому "миру"?

Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (36), 07-Сен-22, 13:42

А теперь представьте, что надо написать свой собственный компилятор языка с++ (с++23) вообще с нуля!:)

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

104. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Neon (??), 09-Сен-22, 17:47

Значит, что то давно не так в С++ королевстве. И развитие его идет в какую то не ту сторону.

Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (36), 10-Сен-22, 10:30

Да, у С++, впрочем как и у любого другого языка есть проблемы, но утверждать, что его развитие идет не в ту сторону, - я бы точно не стал!

Ответить | Правка | Наверх | Cообщить модератору

58. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Ванёк (?), 07-Сен-22, 17:10

Как оно по производительности генерируемого кода по сравнению с GCC, ICC, MSVC, в том числе с использованием PGO? Кто-нибудь знает?

Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (79), 08-Сен-22, 11:22

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

Ответить | Правка | Наверх | Cообщить модератору

93. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (92), 09-Сен-22, 01:29

Про PGO не скажу, но на обычной компиляции clang и gcc где-то рядом - в одних случаях один лучше, в других - другой. icc сдох (Intel перешел на clang со своим бекендом, называется icx), и и clang, и gcc его уже давно обставили. Единственная его "киллер-фича" - это автоматический runtime dispatch в зависимости от наборов инструкций, поддерживаемых CPU. А MSVC - это хрень, а не компилятор. На типовом коде еще куда ни шло, и то - иногда умудряется генерировать некорректный код. Но как только начинаешь использовать векторные расширения - это дно.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

96. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от срыватель_покровов (?), 09-Сен-22, 02:15

clang в хламину сливает gcc. Обычно однорукие бандиты даже замерить нормально код не могут(допустим не знают про libcxx и llvm-рантайм для цпп). Так же шланг имеет более агрессивные умолчания нежели гцц, а так же там много всяких подложных фейковых оптимизаций.
>Единственная его "киллер-фича" - это автоматический runtime dispatch в зависимости от наборов инструкций, поддерживаемых CPU.
Это базовая фича gcc/gnuc ну и шланга как альтернативной реализации gcc/gnuc. Фича у интел-компилятора в другом. Она такая же как и в случае с шлангом и его фейковыми оптимизациями. Он создан специально чтобы заменять код вчерашнего мойщика полов на нормальный. Если же код пишет не мойщик полов все эти кулл-оптимизации нахрен ненужны.

Из таких примеров простых. Боты-поломои в основном пастят шаблоннный мусор. Всякие for i j и прочий мусор. Вот icc умел детектировать этот мусор и заменять его на нормальные реализации. Допустим какое-нибудь умножение матриц и прочее.
Точно так же как gcc/clang умеют детектировать memcpy.

Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (108), 10-Сен-22, 03:14

>> Единственная его "киллер-фича" - это автоматический runtime dispatch в зависимости от наборов инструкций, поддерживаемых CPU.
>
> Это базовая фича gcc/gnuc ну и шланга как альтернативной реализации gcc/gnuc.
Нет в gcc такой фичи. Есть ручное клонирование и маркировка функций для разных наборов инструкций.
https://gcc.gnu.org/wiki/FunctionMultiVersioning
А icc мог сам сгенерировать клоны (или даже вынести часть функции в клоны) и dispatch из простого кода.

Ответить | Правка | Наверх | Cообщить модератору

111. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Ванёк (?), 10-Сен-22, 13:13

То же самое можно сделать в любом компиляторе с помощью #ifdef __инструкции__ (__SSE2__,__AVX2__ и т.п.)

Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Аноним (118), 12-Сен-22, 02:13

Вопрос на засыпку: в чем разница между директивами препроцессора и runtime dispatch?

Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от Ванёк (?), 12-Сен-22, 14:35

Если прямо действительно необходимо runtime dispatch, то помимо директив препроцессора есть cpuid. Комбинация cpuid и директив - более гибко, контролируемо и более-менее универсально для любого компилятора.

Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз набора компиляторов LLVM 15.0" +1 +/–

Сообщение от Аноним (-), 10-Сен-22, 19:11

Не используйте LLVM, он нужен пермиссивщикам и проприетарщикам.

Ответить | Правка | Наверх | Cообщить модератору

116. "Релиз набора компиляторов LLVM 15.0" –1 +/–

Сообщение от Аноним (-), 11-Сен-22, 01:16

Не используйте GNU/GPL, он нужен пермиссивщикам и проприетарщикам.
Пофиксил, не благодари.
Кстати, а почему оракул не хочет гест аддишанс шайтан коробки в бсди положить, а вон мс скуль в пингвине крутится? Какая-то несвободная свобода. Не?

Ответить | Правка | Наверх | Cообщить модератору

117. "Релиз набора компиляторов LLVM 15.0" +/–

Сообщение от anonima (?), 11-Сен-22, 10:59

> В Libc++ продолжена реализация новых возможностей стандартов C++20 и C++2b, в том числе завершена реализация библиотеки "format" и предложен экспериментальный вариант библиотеки "ranges".
Джва года ждал.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Релиз набора компиляторов LLVM 15.0"	+5 +/–
Сообщение от Анонн (?), 06-Сен-22, 23:34
Отличная новость! Крутой прогресс за полгода.
Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Релиз набора компиляторов LLVM 15.0"	–16 +/–
	Сообщение от Xenia Joness (ok), 07-Сен-22, 12:05
	> Отличная новость! Крутой прогресс за полгода. Плюсую. За LLVM будущее, и скоро, надеюсь, выкинут наконец-то этот GCC на свалку истории
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Аноним (42), 07-Сен-22, 12:39
	Чем он вам так насолил?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Релиз набора компиляторов LLVM 15.0"	+3 +/–
	Сообщение от Аноним (44), 07-Сен-22, 12:42
	Да она и про LLVM-то только название и слышала.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Релиз набора компиляторов LLVM 15.0"	–3 +/–
	Сообщение от Анонн (?), 07-Сен-22, 15:51
	Да куча недостатков: - GNU C Language Extensions - здоровенный костыль поддержанный (изначально) только в одном компиляторе и как следствие невозможность сборки ядра другими. Прямо extend в стиле microsoft'а. - здоровенный монолит - максимальная связность и сложность расширения - отстойная огороженная лицензия
	Ответить \| Правка \| К родителю #42 \| Наверх \| Cообщить модератору


	65. "Релиз набора компиляторов LLVM 15.0"	+4 +/–
	Сообщение от аНОНИМ (?), 07-Сен-22, 18:24
	FSF при помощи прежде всего GCC начал менять мир годах в 80ых и продолжает менять до сих пор и результатами этого пользуются все без исключения люди, даже если они не догадываются об этом. У шланга кол-во поддерживаемых архитектур примерно на порядок (десятичный) меньше чем у GCC. Лицензия GPL -- лучшая лицензия для открытого софта, а ненавидят её только проприерасты, которые только и мечтают о том, чтобы безнаказанно красть (брать и закрывать) чужой открытый код.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Аноним (66), 07-Сен-22, 18:41
	> У шланга кол-во поддерживаемых архитектур А знаешь почему? Потому что они на момент создания llvm никому нафиг не вс@лись! Это куча всякого хлама который можно найти только в музеях, а выпилить из gcc не решаются, потому что "а вдруг что-то сломаем по дороге". Хотя все даже круче - gcc поддерживает бекенды для архитектур, которые никогда не были реализованы в железе - секция M в https://gcc.gnu.org/backends.html.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Релиз набора компиляторов LLVM 15.0"	+2 +/–
	Сообщение от срыватель_покровов (?), 08-Сен-22, 00:22
	Зачем ты рассказываешь о том, в чём ничего не понимаешь? Как же так - гцц подлый монолит не расширяемый, а он поддерживает множество архитектур? >выпилить из gcc не решаются, потому что "а вдруг что-то сломаем по дороге". Зачем домохозяйка пытается рассуждать о коде? Как раз таки всё наоборот. >бекенды для архитектур, которые никогда не были реализованы в железе wasm в желе покажешь?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	102. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
	Сообщение от Neon (??), 09-Сен-22, 17:24
	> Лицензия GPL -- лучшая лицензия для открытого софта, а ненавидят её только проприерасты Просто не все живут на мамкиной шее. И идеалами сыт не будешь.
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	120. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Тот_Самый_Анонимус (?), 14-Сен-22, 06:16
	Одни лозунги. А по факту — единоличное создание своего диалекта си (в стиле майкрософта). И ни один поборник стандартов не вякнет: ведь этим свои занимаются. Вот если бы майки это сделали, то вони бы стояло на сотню комментов.
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	70. "Релиз набора компиляторов LLVM 15.0"	–1 +/–
	Сообщение от срыватель_покровов (?), 08-Сен-22, 00:15
	Смотри, жертва пропаганды. - Кроме gnuc другого си нет. Никто не будет ничего писать на этом днище. И да - шланг это именно что gnuc/cpp компилятор. Как и сам драйвер там 1в1 повторяет гцц. И да, свободный код не может быть вендорлоком. - Пустые сказки от домохозяек. Мне даже лень спорить на эту тему - пруфы ты всё равно не покажешь. - Лицензия наиболее свободная. Единственное что у гцц есть из проблем - это во многом столман-шиза древняя о том, что cpp-фронт будут воровать.
	Ответить \| Правка \| К родителю #55 \| Наверх \| Cообщить модератору


	80. "Релиз набора компиляторов LLVM 15.0"	–1 +/–
	Сообщение от Аноним (66), 08-Сен-22, 12:04
	Гнус это всего лишь жалкая надстройка над си, которую добавили ядрописатели - просто не шмогли в стандарт (ну или вынуждены были добавить, потому что стандарт отстой). Такая же огороженная надстройка как "Microsoft extensions to C", которую добавили майки MSVC. И такой же вендорлок. > Лицензия наиболее свободная Ну да, ну да, "свобода это рабство". Свободные лицензии - это MIT, BSD, MPL, CCA и аналогичные. А ваша GPL - открытая, но не свободная.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Аноним (91), 09-Сен-22, 00:03
	GPL - не свободный, потому что ограничивает твою "свободу воровать"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
	Сообщение от Neon (??), 09-Сен-22, 17:31
	Свобода зарабатывать - это свобода воровать ?! Чтобы заработать, предлагаете с нуля всё лично самому писать, начиная с драйверов и биос с операционкой. Хорощо рассуждать о светлых идеалах, сидя на шее у родителей, ничего сам не зарабатывая.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Аноним (109), 10-Сен-22, 09:38
	Хорошо сидеть на шее у сообщества, используя его инструменты, изображать из себя у мамы большого айтишнега-заработника.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	115. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Аноним (-), 11-Сен-22, 01:11
	Как можно украсть то, что принадлежит всему миру и отдано в безвозмездное пользование с единственной оговоркой: не требовать гарантий?! Это Вам расхищение гуманитарки мерещится. БСД - истинная свобода!
	Ответить \| Правка \| К родителю #91 \| Наверх \| Cообщить модератору


	94. "Релиз набора компиляторов LLVM 15.0"	–1 +/–
	Сообщение от срыватель_покровов (?), 09-Сен-22, 02:03
	>Гнус это всего лишь жалкая надстройка над си Да ты чё? Зачем ты, домохозяйка, о чём-то пытаешься рассуждать? gnuc это и есть си. Это даже деюро закреплено тем, что стандарты после gnuc просто копипастили в себя куски gnuc. >которую добавили ядрописатели Опять же опозорился. Ядрописатели это лишь одни из. >просто не шмогли в стандарт Как в бездарный мусор можно не мочь? Скорее они не хотели жрать дерьмо и "писать" на то на чём только лабу можно написать. Но ты даже и лабу не писал. >(ну или вынуждены были добавить, потому что стандарт отстой). Им ненужно ничего добавлять - это стандарт вынужден быть у них всё тащить, чтобы хотя бы быть похожим на си. А gnuc как был так и остался си, а стандарт лишь жалкая пародия. >Такая же огороженная надстройка как "Microsoft extensions to C", которую добавили майки MSVC. И такой же вендорлок. Жертва пропаганды - никаких расширений от маздайсофта не существует. Ты опять опозорился. То, что ты где-то там слышал - это вообще не про си. И уж тем более, жертва пропаганды, gnuc не может являться вердорлоком. >Ну да, ну да, "свобода это рабство". Для тебя да. >А ваша GPL - открытая, но не свободная. Нет, гпл это именно что свободная лицензия. Просто она тебе не позволяет воровать чужой код от того у тебя жопа болит. Вернее даже не у тебя - ты просто раб хозяина и ретранслируешь его волю.
	Ответить \| Правка \| К родителю #80 \| Наверх \| Cообщить модератору


	56. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
	Сообщение от Анонн (?), 07-Сен-22, 15:54
	С другой стороны нужно быть благодарным им за это все - иначе какой смысл было бы создавать llvm.
	Ответить \| Правка \| К родителю #42 \| Наверх \| Cообщить модератору


	107. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
	Сообщение от adolfus (ok), 09-Сен-22, 20:51
	Не очень понятно, зачем нужно фиксировать промежуточный результат в виде объектного модуля для абстрактной архитектуры. Ведь все равно для отладки загрузочного модуля нужен код для целевой архитектуры. Это же и для этапа компоновки. Единственное объяснение -- метод предназначен, чтобы воспрепятствовать использованию хороших библиотек, что идут в составе проприетарного софта, в неконтролируемых этими проприетарщиками программах. Да и зачем каждый раз при загрузке программы ее компилировать в код для целевой архитектуры, если можно это сделать один раз и просто его использовать в готовом виде. Да и оптимизация этого промежуточного кода бесполезна, поскольку процесс этот конкретен для конкретной архитектуры. Получается, что вместо оптимизатора в составе компилятора, генерирующего объектный код, нужно иметь два -- оптимизатор в промежуточную архитектуру и оптимизатор в целевую. Но это и так есть в любом компиляторе, просто промежуточный код не выводится, а второй оптимизатор работает один раз, в отличие от, который должен работать при каждой загрузке.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	113. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от iZEN (ok), 10-Сен-22, 14:46
	NIH-синдром на Java JIT: нужно реализовать то, что было реализовано 20 лет назад, но на новом технологическом уровне, с задействованием в 100 раз большей процессорной мощности и в 1000 раз большей потребной памяти.
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Релиз набора компиляторов LLVM 15.0"	+/–
Сообщение от Аноним (2), 06-Сен-22, 23:39
>Добавлена экспериментальная поддержка Си-подобного языка HLSL (High-Level Shader Language), применяемого в DirectX для написания шейдеров. Вайн задействует?
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Релиз набора компиляторов LLVM 15.0"	+/–
	Сообщение от Аноним (2), 06-Сен-22, 23:45
	https://github.com/microsoft/DirectXShaderCompiler - просто аттракцион невиданной щедрости какой-то
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
	Сообщение от Аноним (-), 07-Сен-22, 12:05
	Видимо на DX все забили при наличии вулкана, вот и раздобрились...
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Релиз набора компиляторов LLVM 15.0"	–1 +/–
Сообщение от Аноним (3), 06-Сен-22, 23:39
Ждём обновления ldc для dlang.
Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
Сообщение от lucentcode (ok), 06-Сен-22, 23:39
А про ассемблер llvm-mc ничего не слышно? Он совместим с gas, но весьма ограниченно. .S файлы сформированные с помощью llvm с помощью gas собираются на ура, а вот файлы созданные для gas не в 100% случаев собираются llvm-mc, что навевает на мысль, что ассемблер из проекта llvm не на 100% совместим с gas. Хотя, если писать на ассемблере с учётом небольших нюансов, можно использовать одни и те же файлы и под gas, и под llvm-mc.
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Релиз набора компиляторов LLVM 15.0"	+2 +/–
	Сообщение от Аноним (6), 07-Сен-22, 04:16
	Мне вот надо чтобы clang на инлайн асме, с интел синтаксисом на использовании offset не крашился.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Релиз набора компиляторов LLVM 15.0"	+2 +/–
	Сообщение от Брат Анон (ok), 07-Сен-22, 09:01
	Интел-стайл контр-интуитивен. Особенно при косвенной адресации. Закопать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Релиз набора компиляторов LLVM 15.0"	–2 +/–
	Сообщение от Аноним (19), 07-Сен-22, 09:30
	AT&T-синтаксис просто ужасен и для набор и для чтения. Его вообще не должно быть нигде от слова ВАЩЕСОВСЕМ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Релиз набора компиляторов LLVM 15.0"	+1 +/–
	Сообщение от Аноним (26), 07-Сен-22, 10:29
	У тебя синдром утёнка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Релиз набора компиляторов LLVM 15.0"	+8 +/–
	Сообщение от Аноним (30), 07-Сен-22, 11:09
	У тебя Даннинг-Крюгер.
	Ответить \| Правка \| Наверх \| Cообщить модератору