Среди разработчиков набора компиляторов GCC (http://gcc.gnu.org/) развернулась обширная дискуссия (http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html) о планах и задачах для будущей ветки GCC 5.0. При этом основной темой размышлений о возможных путях развития GCC, стало его обсуждение в контексте стремительно набирающего популярность проекта LLVM (http://llvm.org/) (Low Level Virtual Machine).Так активный разработчик GCC Дэвид Малкольм (http://dmalcolm.livejournal.com/) (David Malcolm) из компании Red Hat подробно изложил (http://gcc.gnu.org/ml/gcc/2012-03/msg00256.html) своё видение будущего проекта, которое сводится к предложению переписать GCC с Си на Си++, разработать полноценный API для подключения плагинов, а также в движении GCC в сторону более модульной структуры – реализации базовой части в виде набора самодостаточных библиотек.
Идея заключается в том, что подобные библиотеки, из которых будет состоять GCC 5, смогут очень легко внедряться в приложения, также легко, как это делается в LLVM. Дэвид в частности заявляет: "На что я очень надеюсь, что GCC будет двигаться в сторону коллекции библиотек, которые могут быть свободно внедрены в любые лицензионно-совместимые приложения. LLVM завоевала популярность для случаев, где нужна JIT-компиляция. Я понимаю, что JIT-компиляция имеет совсем разные характеристики по сравнению с классическим предварительным компилированием (ahead-of-time compiler). В идеале, GCC превратится в набор разделяемых библиотек, которые могут быть слинкованы как статически, так и динамически. Запускаемые файлы превращаются в тонкую обертку, которая лишь вызывает нужные библиотеки".Приведение GCC к модульной структуре - это очень сложное предприятие. Поэтому Дэвид добавляет: "Подобная переработка архитектуры сегодняшнего GCC очень сложна (быть может, даже и невозможна), хотя бы потому, что мы не можем однозначно решить к какому отдельному модулю, какой код компилятора должен принадлежать. И важный момент, который мы должны сначала предпринять, это принять некую карту развития, при этом вероятно нужно сразу смириться с тем фактом, что модульный GCC 5 по сравнению с текущим GCC, - будет обладать меньшей функциональностью, будет также менее оптимизированным и менее мощным, чем сегодняшний GCC. Я не знаю, возможно ли это осуществить вообще (поэтому я иногда очень пессимистичен к этому проекту), в том числе потому, что многие платные разработчики GCC работают на компании, которые не допустят столь масштабных изменений".
Кроме того, препятствием для потенциального сближения GCC и LLVM является то, что компиляторы LLVM поставляются под более либеральной лицензией BSD, которая более любима компаниями и более совместима со сторонним программным обеспечением, тогда как GCC распространяется под лицензией GPLv3, вносящей ряд ограничений при связывании библиотек. Даже если разработчики и согласятся в будущем сфокусироваться на модульности будущего GCC, это потребует ни мало времени, пока это станет всё-таки возможным.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA3MzE
Новость: http://www.opennet.me/opennews/art.shtml?num=33396
А стоит ли оно того?
Поживем увидем, сейчас нельзя так просто ответь на этот вопрос
Как нам пояснили это того стоит ибо переписанный на Си++ "модульный GCC 5 по сравнению с текущим GCC, - будет обладать меньшей функциональностью, будет также менее оптимизированным и менее мощным, чем сегодняшний GCC". Возможно я не прав, но когда коту делать нечего он...
Вы опустили весьма важную часть: "библиотеки, из которых будет состоять GCC 5, смогут очень легко внедряться в приложения", а это существенно для многих других сопутствующих тул (IDE, статические анализаторы, документаторы, ...). Одного компилятора нынче маловато. Посмотрите как сделана интеграция Java в Eclipse - для С++ ничего похожего нет. В частности из-за сложности языка, в частности, из-за разрозненности тул, которые плохо совместимы друг с другом и усложняют организацию взаимодействия.Ну и имхо, конечно, gcc уже опоздал. Имхо, сейчас он все еще стабильнее llvm и чаще всего генерирует более быстрый код, но думаю это продлится недолго (судя по темпам развития llvm).
И еще по поводу "модульный GCC 5 по сравнению с текущим GCC, - будет обладать меньшей функциональностью, будет также менее оптимизированным и менее мощным, чем сегодняшний GCC" - насколько я знаю, на и текущий gcc не является компилятором, генерирующим наиболее оптимальный код, куда ж еще...
А что генерирует наиболее оптимальный?
Intel, PathScale, NAG
Сильно зависит от написания. Многие тесты синтетические, а для реальных проектов быстродействие гуляет в обе стороны. Опять же опенсёрс, а значит все проблемы известны и их можно избегать и исправлять.
Path64, GPL v3
> Path64, GPL v3Но очень уж на AMD ориентирован. Это конечно лучше чем блоб от интеля, но получается что если не хочется париться по поводу того интел у клиента или амд - проще всего gcc использовать. Генерящий довольно приличный код для обоих.
У AMD Open64, а это Pathscale Path64, более ранний форк того же SGI компилятора.
> Intel, PathScale, NAGIntel нынче довольно активно коммитит в gcc. Может они уже осознали что их кривульку никто массово юзать не собирается :).Во всяком случае на новых процах гнутый си довольно хорошо генерит код под их процы, весьма оперативно поддерживая наборы команд внедряемые интелом.
для Win - MS VC
Спорно, бывает и наоборот.
Это шутка юмора?
Правильной дорогой идете ребята. Вообщем ждем новостей, а еще лучше релизов GCC
А где обсуждение-то читать? В гиперссылке "обсуждение" дано как раз небольшое сообщение этого самого работника Red Hat, которое полностью переведено. Про модульность и наступающий LLVM. И всё. Где узнать что возможно появится в GCC 5.0?
Расслку никогда не читал? Тыкаешь там "Thread Index" и читаешь сообщения по интересующей теме.
> Кроме того, препятствием для потенциального сближения GCC и LLVM является то, что компиляторы LLVM поставляются под более либеральной лицензией BSD, которая более любима компаниями и более совместима со сторонним программным обеспечением, тогда как GCC распространяется под лицензией GPLv3,И тут GPL v3 мешает...
> И тут GPL v3 мешает...Они продавят и все стандарты(особенно юридические) будут считаться с v3. Надеюсь, что это не затянется и будет реализовано после пересмотра патентования ПО.
Не мешает, а помогает.
Не в последнюю очередь благодаря этой лицензии появился LLVM.
> Не в последнюю очередь благодаря этой лицензии появился LLVM.Ну так любители тивоизировать девайсы и вообще ставить юзеров раком - всегда лазейку найдут.
> Ну так любители тивоизировать девайсы и вообще ставить юзеров раком - всегда лазейку найдут.Так пусть ищут ее своим ходом :)
Тонко )
> И тут GPL v3 мешает...Да, ужасная лицензия. Не дает хапугам код зажимать. Вы только подумайте, какие негодяи!
> рано ещё при текущих трендах шланг заборет гцц, однако есть вероятность что
> к тому времени на плюсах будут писать 2 дедаПри текущих трендах, шланг может кого-то побороть только по части продайкт-плейсмента.
Технические достоинства и недостатки - ничто, авторитет яббла - все.
Ужастная лицензия - позволяет стороннему дяде присвоить мой код - если я хочу просто пользоваться его библиотекой - не изменяя ее.
Так же как ужастная для компилятора - что не компилируй - на выходе получаем GPL v3 и можно смело присваивать себе код.
>позволяет стороннему дяде присвоить мой код - если я хочу просто пользоваться его библиотекой - не изменяя еене согласен - пиши свою либу. или ищи под лгпл или иной
>что не компилируй - на выходе получаем GPL v3 и можно смело присваивать себе код
у гцц есть оговорка насчёт выхлопа, так что не надо тут
> у гцц есть оговорка насчёт выхлопа, так что не надо тутНету. почитай лицензию на gcc. Любой проект использующий внутренне состояние gcc - обязан быть под gpl.
и linking expection - добавили только после воплей, а не просто так.
внутренности — естественно.а исключение давно было, просто потерялось при переводе на GPLv3. ты знаешь, что такое «ошибка», нет? никто не идеален, все ошибаются. недосмотрели. починили. в чём проблема-то?
Не понимаю, как переход на С++ сможет решить проблемы?
Просто они незнают что в С++ делается больше
ошибок чем в С.
Может они хотят учиться на своих ошибках ?..
Разрабы GCC дураки, а ты умный - понятно.
Да, вам можно говорить об ошибках, вы в курсе.
Пять ошибок в двух предложениях - это твердый профессиональный уровень!
Комментарии к статье доставляют :)
> Не понимаю, как переход на С++ сможет решить проблемы?это ж redhat, там поттеринг скоро всех перекусает.
если бы gcc 1.4 был написан на C++ имхо лиукса бы небыло
а если бы Кениган & Ричи писали компилятор C++, то и С бы не было. вместе с UNIX TM.
Ну вообще-то Страуструп изначально только прикрутил классы к вполне себе нормальному С. Банально расширил функционал.
тыц ура к 5 версии и гцц будет фрэймворком
Вообще-то речь шла о библиотеке, что не совсем тоже самое, что и фреймворк. Надеюсь, все же, что фреймворком он не будет...
> Так, активный разработчик GCC Дэвид Малкольм (David Malcolm) из компании Red Hat подробно изложил своё видение будущего проекта, которое сводится к предложению переписать GCC с Си на Си++Забавный он человек. Шансов на это 0. Максимум, они будут использовать строго определенные фичи (о чем разработчики когда-то говорили).
Имхо, сильно громкое заявление, переписать такой величины проэкт, практически на другой язык - весьма трудоёмкая задача. Оно-то конечно правильно, С++ и удобней для таких задач и гибче, но... Мало верится что-то :)
насчет удобней - крайне спорный вопрос ибо ясно, что удобнее CL и ML пока еще ничего не придумано, однако ж никто не переписывает тонны кода на них только потому, что они "удобнее" (кому конкретно? для чего конкретно?)
да ну. ассемблер всё равно лучше всех.
>Важно в первую очередь принять некую карту развития - при этом, вероятно, придётся смириться с тем, что модульный GCC 5 будет обладать меньшей функциональностью, чем текущий GCC, будет менее оптимизированным и менее мощным.Мне кажется это будет капец. Если он будет менее мощным и оптимизированным, то пока они его доведут до удовлетворительного состояния, Clang + llvm обойдут на повороте и уйдут в отрыв.
На мой взляд главные плюсы GCC:
* Поддержка огромного числа архитектур, быстрое включение этой поддержки после анонса.
* Очень качественная, фактически, эталонная поддержка основных ЯП и их стандартов: С, С++, Fortran.
* Генерирует оптимальный код, мощная оптимизация.Вот в улучшениее всего этого и нужно двигаться. Но никак не за счет ухудшения существующих позиций.
> На мой взляд главные плюсы GCC:
> * Поддержка огромного числа архитектур, быстрое включение этой поддержки после анонса.
> * Очень качественная, фактически, эталонная поддержка основных ЯП и их стандартов: С,
> С++, Fortran.Это стеб тонкий? тогда почитай-те что такое GCC-измы и что такое GNU-89 который реализует gcc.
Нефига не эталонная поддержка это C.
ну с эталонной, пожалуй это немного перебор. Но все же с ней считаются (например, есть всякие воркэраунды вокруг багов компайлера для Boost, STLPorts и других библиотек). Что касается llvm, например, то пока он вынужден все корректно поддерживать (что, впрочем, может и к лучшему).
> Это стеб тонкий? тогда почитай-те что такое GCC-измы и что такое GNU-89
> который реализует gcc.
> Нефига не эталонная поддержка это C.В чем-то согласен. С другой стороны, не используй GCC-измы. GCC же не виноват, что в стандарте много чего нехватает. А стандарт он поддерживает нормально. Ну и самое главное, может только дя меня, почему я его назвал эталонным - это поддержка множества архитектур. Для половины поддерживаемых архитектур ты вообще не найдешь компилятора С который бы не забивал болт на стандарты. Поэтому GCC для меня это пока единственная возможность получить одинаковый Си, с GCC-измами или без, на разных процах и под разными ОС.
Ну и вообще ты знаешь компилятор лучше?
И ещё по-поводу стандарта. На мой взгляд сообществу GCC, равно как и Clang/llvm, давно пора лобировать прохождение своих расширений в стандарт. Я лучше буду видеть в с тандарте __attribute__((packed)) - единственное расширение, что приходится часто использовать, чем всякие _Noreturn и нити (если было и добавлять нити, то уж на базе pthreads).
> Ну и вообще ты знаешь компилятор лучше?тот же intel, тот же openwatcom.
> И ещё по-поводу стандарта. На мой взгляд сообществу GCC, равно как и
> Clang/llvm, давно пора лобировать прохождение своих расширений в стандарт. Я лучше
> буду видеть в с тандарте __attribute__((packed)) - единственное расширение, что приходится
> часто использовать, чем всякие _Noreturn и нити (если было и добавлять
> нити, то уж на базе pthreads).за attribute((packed) и пересылку по сети и диск я бы голову отбивал.
non aligned access получить как 2 байта по сети переслать. и всякие _Noreturn - это хня.
даже от likely/unlikely в kernel стали избавляться ибо выигрыш там мизерный - если есть.
>тот же intel, тот же openwatcom.Т.е лучше копилятора чем GCC ты не знаешь, по крайней мере в плане поддержки различных архитектур и стандарта С.
http://www.openwatcom.org/index.php/C99_Compliance
>C99 compatibility is an undocumented feature, since the implementation is not complete.Ты им вообще пользовался? Чем он вообще лучше?
>за attribute((packed) и пересылку по сети и диск я бы голову отбивал.
Лучше не пробуй, а то свою отобьешь, или уже?
>non aligned access получить как 2 байта по сети переслать
Настолько геморно?! Или есть способ попроще, просвети.
>и всякие _Noreturn - это хня.
Хня, не хня - в стандарт вошло. Меня лично заглавная "N" раздражает.
>>тот же intel, тот же openwatcom.
> Т.е лучше копилятора чем GCC ты не знаешь, по крайней мере в
> плане поддержки различных архитектур и стандарта С.Хуже не знаю. Ты посмотри какой код он генерит для IA-64, а потом сравни с Intel.
Разница видна на лицо.
Глюки с structure aliasing и левым доступом в соседние элементы структуры - для gcc это норма, другие компиляторы этим не страдают.
Код который компилируется 3.2 не будет компилироваться 3.5 и тп. Таких приколов ну просто дофига.и тп. Список багов gcc можно продолва
> http://www.openwatcom.org/index.php/C99_Compliance
>>C99 compatibility is an undocumented feature, since the implementation is not complete.
> Ты им вообще пользовался? Чем он вообще лучше?Видимо ты других вообще не знаешь. Советовал бы просветиться.
gcc приличный код генерит только для x86 - остальное.. лучше бы его не было.>>за attribute((packed) и пересылку по сети и диск я бы голову отбивал.
> Лучше не пробуй, а то свою отобьешь, или уже?
>>non aligned access получить как 2 байта по сети переслать
> Настолько геморно?! Или есть способ попроще, просвети.Дядя ты вообще код для архитектур со strict aligment писал ?
Если не писал - попродуй попиши.. очень интересные вещи для себя узнаешь.
>>и всякие _Noreturn - это хня.
> Хня, не хня - в стандарт вошло. Меня лично заглавная "N" раздражает.в C-98 нету, C-1x круто, но еще нигде нету правильной поддержки.
> non aligned access получить как 2 байта по сети переслатьnobody cares. кажется, разработчики железа забыли, что это железо для людей, а не наоборот. если какая-то архитектура умывается слезами от невыравненого доступа — это её личные проблемы. а я, например, не буду заниматься ерундой, доставая из int'а два char'а руками. и не собираюсь тратить — тоже например — четыре байта там, где хватает двух.
Железо скорее для компиляторов, а компиляторы уже для людей. Если попросить проц не умничать и дать компилятору решать, что, куда и в каком порядке (а это у него может получиться значительно лучше, т.к. можно неспеша разглядывать большую кучу кода), может получиться интересно по быстродействию и энергопотреблению. Вроде что-то подобное и сделали в IA-64
> Железо скорее для компиляторов, а компиляторы уже для людей.в данном случае это частности. я говорил про то, что за исключением случаев, когда это дикая эмбедовка с драконовскими ограничениями и большими требованиями, я вообще не желаю ничего про железо знать. и тем более не желаю «делать железу хорошо».
> Вроде что-то подобное и сделали в IA-64
если мне не изменяет память (а в данном случае очень может), там прежде всего была марсианская система кодирования команд, которую без компилятора задолбаешься рулить.
>> non aligned access получить как 2 байта по сети переслать
> nobody cares. кажется, разработчики железа забыли, что это железо для людей, а
> не наоборот. если какая-то архитектура умывается слезами от невыравненого доступа —
> это её личные проблемы. а я, например, не буду заниматься ерундой,
> доставая из int'а два char'а руками. и не собираюсь тратить —
> тоже например — четыре байта там, где хватает двух.Да да да. Не стоит прикрывать свою не проф пригодность красивыми словами - ламер.
Покачай еще свои права в конторе которая пишет мультиплатформеный код - скажи начальнику - это неправильная архитектура - я ее поддерживать не хочу. И вылетай оттуда пинком под зад - с заслуженным диагнозом "не проф пригоден".
благодарю, я уж лучше продолжу работать в своей конторе. и пинками вышибать тех, кто считает, что задача человека — делать работу за компилятор.
> Нефига не эталонная поддержка это C.Он поддерживает кучу архитектур, при том все это доступно в сырцах и я могу себе накрайняк сам сбилдить бинарь генерящий код под экзотичную архитектуру. А вот у других поддерживается 1-2 архитектуры, а в половине случаев еще и сорц "забывают" выдать. Так что жрите бинарь под неудобные вам операционки или GTFO. Я предпочитаю второе т.к. есть gcc.
как твой топик связан с тем что у GCC не эталонная поддержка C ?
у того же CLANG и то лучше поддержка стандартов C.
Речь о том, что GCC можно использовать как стандарт де-факто - он есть практически везде.
везде есть свои компиляторы. И если не писать код под GCC - то код получится переносим между компиляторами - чего не может себе позволить gcc.
Особенно интересный вариант когда код перестает собираться разными версиями компилятора.
>везде есть свои компиляторы.Но для многих embedded-платформ GCC - единственный компилятор, поддерживаемый вендором.
Например? Для каких это embedded платформ gcc единстсвенный компилятор?
Можно взять LLVM и дописать модулями недостающий до gcc функционал под GPL лицензией. Это будет проще, чем переписывать всё на крестах и лучше, чем "будет обладать меньшей функциональностью, чем текущий GCC, будет менее оптимизированным и менее мощным".
> Можно взять LLVM и дописать модулями недостающий до gcc функционал под GPL
> лицензией.А лучше под BSD, чтобы не плодить форки.
Дядя бредит похоже. Никто не будет переписывать настолько большой проект, может сделают бранч и там будут эксперименты ставить, сомневаюсь что это будет GCC 5, скорее какой-нибудь GCC-alternative 5.По поводу лицензий - всем корпорациям GNU GPL как бельмо на глазу, ведь не дает закрывать и продавать чужой труд, ай ай ай, какие плохие свободные разработчики, не дают свой труд закрывать и продавать. Поэтому они так и радеют за BSDL, бздунишки уже привыкли к рабству.
> По поводу лицензий - всем корпорациям GNU GPL как бельмо на глазу,
> ведь не дает закрывать и продавать чужой труд, ай ай ай,
> какие плохие свободные разработчики, не дают свой труд закрывать и продавать.
> Поэтому они так и радеют за BSDL, бздунишки уже привыкли к
> рабству.Не всем корпорациям, а малой части делающей профит именно на закрытости сырцов.
Большей части корпораций ЖоПЛь это защита инвестиций и очень полезная лицензия.
А для тех, кому нет денег и времени на патентные войны, вообще манна небесная.
С таким объёмом изменений лучше новый проект начинать, по крайней мере, не будет той стадии, что старое уже сломали, а новое ещё не сделали.
По ходу проект в тупик зашел, #gccкапец видимо не за горами.
ЗЫ
Надо было лицензию на LGPL менять! Компилятор слишком нужная вещь, чтобы для него GPLv3 юзать.
срочно нужен аналог LLVM под GPLv3 и выше. сделать и потом перетягивать туда парсер из gcc, оптимизатор, кодогенратор и тд. а не ломать все и хоронить
В который раз говорю - поздно пить боржоми. Такая недальновидность - вообще характерная черта GPL щиков.
> В который раз говорю -Да, мы поняли: ты тоже _только разговариваешь.
Боюсь до тебя мне далеко по части разговоров.
> "Подобная переработка архитектуры сегодняшнего GCC очень сложна (быть может, даже и невозможна)Поэтому нет смысла тыкать труп ГЦЦ - нужно все силы бросить на LLVM.
Причём никто не просит "убивать" ГЦЦ - пусть и дальше "компилирует под 100 архитектур", но развивать нужно правильную кодовую базу! А у ГЦЦ она - такое же фуфло, как ядро линукса - монолитное гуано.> хотя бы потому, что мы не можем однозначно решить к какому отдельному модулю, какой код компилятора должен принадлежать.
:) Вот это удивляет... понятно, что не всё так просто, но разве компилятор настолько неразрывен, что невозможно провести декомпозицию? Нужно решить, в какой мере будут юзабельны отдельные модули и для каких задач смогут применяться.
А вообще, надо D развивать, а не эти тухлые концепции! :)
> понятно, что не всё так просто, но разве компилятор настолько неразрывен, что невозможно провести декомпозицию?Гцц значительно старше LLVM, ему не один десяток лет. Изначально хорошая архитектура со временем часто обрастает костылями, а переписывать с нуля это добро охотников мало
> Гцц значительно старше LLVM, ему не один десяток лет.""GCC celebrates 25 years with the 4.7.0 release
http://lwn.net/Articles/487956/rss> Изначально хорошая архитектура со временем часто обрастает костылями,
Вам, безусловно, виднее.
BTW, GNU screen-у тоже стукнуло 25 http://noone.org/blog/English/Computer/Shell/Happy%2520...
а у тебя, конечно, есть компилятор и ядро с идеальными архитектурами. не покажешь ли?
у LLVM своя делянка, у гцц своя. не понимаю, зачем лезть в чужую делянку ? своя что ль мала ? Надеюсь завернут они все эти чудо изменения и будет все по прежнему - поддержка тонны платформ и нормальный с.