После трёх с половиной лет разработки доступен (http://pcc.ludd.ltu.se/news/) второй стабильный релиз компилятора PCC 1.1.0 (http://pcc.ludd.ltu.se/) (Portable C Compiler), развиваемого с целью создания альтернативы Си-компилятора из состава GCC, распространяемой под лицензией BSD. Версия 1.1 полноценно поддерживает архитектуры amd64 и i386. Частично обеспечена поддержка архитектур arm, hppa, mips, powerpc, sparc64, m68k и vax. Компилятор полностью поддерживает стандарт C99 и пригоден для пересборки FreeBSD, NetBSD и OpenBSD.
PCC является в значительной степени переработанным вариантом компилятора Portable C Compiler, разработанного Стивом С. Джонсоном (S. C. Johnson) в конце 70-х годов прошлого века в качестве замены компилятору DMR (оригинальный компилятор, созданный Дэнисом Ритчи) в выпусках System V и BSD 4.x. В современной версии PCC более 50% кода фронтэнда и 80% кода бэкенда переписано. Основным разработчиком проекта является Андрес Магнуссон (Anders Magnusson) из команды NetBSD. Размер архива (ftp://pcc.ludd.ltu.se/pub/pcc-releases/) с исходными текстами PCC занимает менее мегабайта. Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом качестве коде на выходе.
В новом выпуске (http://pcc.ludd.ltu.se/fisheye/changelog/pcc):
- Реализованы бэкенды для архитектур m68k и vax.
- Расширена поддержка платформ mips и arm.
- Улучшена работа препроцессора (cpp).
- Добавлена поддержка профилирования кода.
- Проведена работа по обеспечению совместимости на уровне опций с GCC, в том числе добавлена поддержка опций "-print-file-name", "-print-prog-name" и "-print-libgcc-file-name".
- В компилятор добавлены новые опции "-O0", "-O", "-O1", "-O2", "-xtemps", "-xdeljumps, "-xinline",
"-xassembler", "-d" для передачи отладочных флагов и "-E" для изменения кода возврата в случае наличия предупреждений на этапе компиляции.
- Внесены оптимизации производительности и решены многие проблемы, проявляющиеся при сборке существующих проектов.
- Добавлена поддержка сборки фреймворков и простых приложений для OS X.
- Обеспечена возможности сборки всех компонентов директории /bin из базовой системы NetBSD.
Что касается будущих выпусков, в настоящее время в списке рассылки разработчиками PСС рассматривается предложение (http://marc.info/?t=141884960400002&r=1&w=2) по добавлению начальной поддержки разбора синтаксиса языка C++.URL: http://pcc.ludd.ltu.se/news/
Новость: http://www.opennet.me/opennews/art.shtml?num=41353
Но зачем, когда есть GCC и Clang?
А Clang был зачем, когда был уже GCC?
Затем, что в BSD-системах не могли использовать GCC из лицензионных соображений.
Могли. Стрекоза же использует и не мается дурью. Просто не хотели.
Потому-что в стрекозе другие цели и задачи.
А какие цели и задачи во FreeBSD ?
Надо же местным что-то ненавидеть и находить "пятые колонны"?
Не виндой же единой.
> Потому-что в стрекозе другие цели и задачи."другие цели и задачи у спонсоров", Вы хотели сказать?
расскажите - как можно использовать компилятор без linking exceptions ? напомню что 1-2 релиза gcc были именно таковые.
> без linking exceptions ?Это те, которые "Мы выпускаем новую версию l.e. из gplv3 для gcc runtime. Отличий почти никаких, ну, разве что, vm, собранные с нашим рантаймом, теперь точно смогут исполнять проприертарный байт-код" ? Да-да, "без".
> напомню что 1-2 релиза gcc были именно таковые.
Учись, как надо:
""The bad thing about GPLv3 is that if anyone commits any code under this
license into the tree vendors that use our code base for making their
own OSes will ditch FreeBSD as they can be sued by FSF. Juniper for
example. It would be wise to listen to their point of view on GPLv3.""
> 1-2 релиза gcc были именно таковые.1-2 == -1
>> 1-2 релиза gcc были именно таковые.
> 1-2 == -1Ледок ты - ге[ни]й. :)
Лицензия GCC не запрещает компилировать на нем программы под BSD, ровно как и проприетарные программы.
GCC старше 4.2.1 перешёл на GPL v3. И соответственно вызывает попоболь у тех кто хочет "ныкать" и "тырить" код. В BSD это называется "посягательством на свободу", соответственно они не могут пользоваться GCC старше 4.2.1.
> GCC старше 4.2.1 перешёл на GPL v3. И соответственно вызывает попоболь у
> тех кто хочет "ныкать" и "тырить" код. В BSD это называется
> "посягательством на свободу", соответственно они не могут пользоваться GCC старше 4.2.1.Когда решался вопрос об импорте нового компилятора, FSF ещё не поправил лицензионный глюк в runtime libraries exception, который позволял двуякое толкование с неприятными для интеграторов FreeBSD последствиями. FSF упущение исправил, но к тому времени ыо FreeBSD уже приняли решение двигаться к отдельным компиляторам для ядра/world и для портов. Для портов предполагалось использовать GCC, а для world - сlang или старый GCC 4.2.x, в зависимости от платформы. До сегодня, понятно, и это решение не дожило - никто не ожидал, что clang окажется таким живчиком и таки подомнёт под себя обе роли.
>> GCC старше 4.2.1 перешёл на GPL v3. И соответственно вызывает попоболь у
>> тех кто хочет "ныкать" и "тырить" код. В BSD это называется
>> "посягательством на свободу", соответственно они не могут пользоваться GCC старше 4.2.1.
> Когда решался вопрос об импорте нового компилятора, FSF ещё не поправил лицензионный
> глюк в runtime libraries exception, который позволял двуякое толкование с неприятными
> для интеграторов FreeBSD последствиями.боюсь что не глюк - а проверка - а вдруг пиплы схавают.. Учитывая как они клева бабло стригли за busybox.
>В BSD <...> не могут пользоваться GCC старше 4.2.1.В DFBSD 4.7 искаропки. И git. Не надо на все BSD скопом гнать.
Потому что диллон - лох. Увы, но фагд.
Он ни разу не был в мягких но липких лапках адвокатов, а фряшники обожглись так что до конца жизни на воду будут дуть! :) И это правильно.
Теперь у них есть шланг ... и он оказался хорош для всего.
Кстати - то что GPLv3 не запрещает собирать хоть хрена лысого - это правда. И поэтому самый наисвежайший GCC во фряхе _ЕСТЬ_. Но - в портах :)
Что, FSF им иски вчиняло?
> Затем, что в BSD-системах не могли использовать GCC из лицензионных соображений.Я только одну такую современную бздю знаю: http://rutracker.org/forum/viewtopic.php?t=4511449
Ну в Bitrig, по их заверениям, на данный момент только один GNU компонент, но они сами говорят, что еще добавят.
Вопрос остаётся резонным, т.к. GCC был/есть под GPL, а clang уже под BSD (собственно, его затем и делали, чтобы был под BSD). Этот PCC тоже делают, "чтобы был под BSD". И возникает вопрос: зачем, если clang под BSD?Хотя, clang/llvm не совсем под BSD, но под очень близкими лицензиями... кому то нужно, чтобы был именно BSD? возможно.
> собственно, его затем и делали, чтобы был под BSDНет. Его затем делали, что нормальная архитектура в отличие от гнилого 20летнего легаси.
> Нет. Его затем делали, что нормальная архитектура в отличие от гнилого 20летнего легаси.При том столь крутая архитектура что амдшники более 2 лет пытались выжать технически корректный код для VLIW. Про оптимизации речь не шла даже.
> При том столь крутая архитектура что амдшники более 2 лет пытались выжать
> технически корректный код для VLIW. Про оптимизации речь не шла даже.А VLIW это вообще вынос мозга. Вон - целая Англия^W HP - сдалась :)
Да-да-да, именно об Архитектуре Apple и думала, нанимая основного разработчика на работу и, практически, спонсируя llvm и clang: проприетари-клозедсоурс очень не любит компилиться на не правильных Архитектурах! Прямо таки, собираться не хочет! И пофиг, что правильная Архитектура,на момент сбегания на нее с неправильной, выдавала заметно более медленные бинари, - зато Архитектура правильная!Или может быть всё-таки Лицензия?
Apple жила раньше и на gcc и ничего. Все-таки архитектура. А исходники в обоих случаях открыты (и gcc и clang).
> Да-да-да, именно об Архитектуре Apple и думала, нанимая основного разработчика на работу и, практически, спонсируя llvm и clang: проприетари-клозедсоурс очень не любит компилиться на не правильных Архитектурах! Прямо таки, собираться не хочет! И пофиг, что правильная Архитектура,на момент сбегания на нее с неправильной, выдавала заметно более медленные бинари, - зато Архитектура правильная!
> Или может быть всё-таки Лицензия?Господа, переведите, plz, этот поток сознания на русский. Я, чессногря, нифига не понял!
Тоже на фиг не нужен
> The project goal is to write a C99 compiler while still keeping it small, simple, fast and understandable. PCC is not affiliated with any other project, but the compiler has been imported into the OpenBSD and NetBSD base systems. The project is maintained by me (ragge).Разработчики clang, gcc и glibc разработкой библиотеки и компилятора для С не интересуются, они пилят "улучшенный C" - С++.
> Разработчики clang, gcc и glibc разработкой библиотеки и компилятора для С не
> интересуются, они пилят "улучшенный C" - С++.Реализация си в gcc и даже шланге - получше чем в сабже.
> Реализация си в gcc и даже шланге - получше чем в сабжеЧто здначит "даже"? clang как раз в поддержке новых стандартов обгонял и обгоняет gcc.
> обгоняет gcc.Видел я как он обгоняет, на примере AMDшных GPU. Набор костылей и глюков.
> Видел я как он обгоняет, на примере AMDшных GPU. Набор костылей и глюков.Как все предсказуемо... User294 стареет, а набор страшилок не меняется.
>> обгоняет gcc.
> Видел я как он обгоняет, на примере AMDшных GPU. Набор костылей и глюков.AMD-шнегам хоть XYZ хрустальный дай - превратят в полимеры, а потом ... :)
Обычный код (зчетай для Ынтел-64) - у ллвм не хуже гысися. Точга.
Это продолжение жизни древнего компилятора (более древнего, чем GCC). Встречный вопрос: почему бы и нет?
>Это продолжение жизни древнего компилятора (более древнего, чем GCC). Встречный вопрос: почему бы и нет?А нахрена? Совершенно необоснованный расход ресурсов. Если нужен дополнительный функционал, необходимо "особое" поведение компилятора, имплементация под другие платформы - это просто делается опцией. Нужно что-то еще - форкай. Я к тому что нет смысла поддерживать старое решение только потому что оно когда-то существовало. Есть же более совершенное решение.
Если софтину кто-то пишет — значит это кому-то нужно. /тхреад
> А нахрена?Термин JFF тебе знаком? Или JBWC?
> Совершенно необоснованный расход ресурсов.А - так ты [д]еффективный мЫнэджер? :) Ну можешь фвтору заплатить сколько он попросит, и __потом__ указать чем ему заниматься :) А ты как думал? Yea - it is a cruel world! :-E
> Это продолжение жизни древнего компилятора (более древнего, чем GCC).Ходили слухи, что GCC - форк PCC
> Ходили слухи, что GCC - форк PCCТут бы не помешала ссылка.
> Тут бы не помешала ссылка.Сталин.jpg
>> Это продолжение жизни древнего компилятора (более древнего, чем GCC).
> Ходили слухи, что GCC - форк PCCСам RMS утверждает что это совсем не так. Дословно "I concluded I would have to write a new compiler from scratch. That new compiler is now known as GCC".
> Hoping to avoid the need to write the whole compiler myself, I obtained the
source code for the Pastel compiler, which was a multi-platform compiler
developed at Lawrence Livermore Lab. It supported, and was written in,
an extended version of Pascal, designed to be a system-programming
language. I added a C front end, and began porting it to the Motorola
68000 computer. But I had to give that up when I discovered that the
compiler needed many megabytes of stack space, and the available 68000
Unix system would only allow 64k.> I then realized that the Pastel compiler functioned by parsing the entire
input file into a syntax tree, converting the whole syntax tree into a chain
of "instructions", and then generating the whole output file, without ever
freeing any storage. At this point, I concluded I would have to write a new
compiler from scratch. That new compiler is now known as GCC; none of the
Pastel compiler is used in it, but I managed to adapt and use the C front
end that I had written.Процитировано с википедии
Для не понимающих по аглиццкой мове переведу: "have to write a new compiler from scratch" означает "пришлось написать свой компилятор со своим блекджеком и шлюхами"
Чтобы избавиться от бесплатного и хорошего продукта с неподходящей лицензией, надо спонсировать разработку нового бесплатного продукта с подходящей.Всё-таки интересная существует тенденция в последнее время: разрабатывать аналоги GPL-лицензированных программ.
Да это без толку. Сообщество всё равно будет поддерживать то, что привычнее ему, а одна компания не в силах содержать проект мирового масштаба.
Пример тому винда и убунта.
Винде сколько лет. Держится на мировом рынке только благодаря политике мокросовта - рэкета и отжима денег у других компаний, а так же навязывания своего продукта и зомбирование населения. И сколько я помню, всегда была глючной и не удобной в использовании (дальше ХР не скажу, там я уже не пользователь винды).
Убунта тоже взялась делать всё в одиночку.
Unity, upstart, softwarecenter, mir. - ни один из этих проектов не используется где либо ещё кроме убунты, а в одиночку канноникалу видать сложно пилить, от сюда общий дистрибутив Убунта тоже стала глючной. Недавно пробовал настроить самбу на бунте 13.10"без ковыряния конфигов в консоле" - фиг там.
Как то видел одно время softwarecenter в репозиториях дебиана. Но потом он пропал.
Эмм.. хотя-я upstart есть в репозитории дебиана, и мало того используется у меня в n900.Ну в общем, нельзя идти против сообщества. Эти спонсорства переписывание аналогов ни к чему не приведут.
>Ну в общем, нельзя идти против сообщества. Эти спонсорства переписывание аналогов ни к чему не приведут."В общем, нельзя идти против общества. Эти переделывания машин подделка крыльев божьих созданий ни к чему не приведут."
=)
Есть только LTS Ubuntu
Да и у меня xubuntu
Ну, в оправдание Canonical могу сказать, что разрабатывают они всё под GPL, в отличие от тех кто просто играет в прятки с опенсорсом. Почему они хотят держать разработки под своим контролем? Это же очевидно! Так при выходе разработчика из игры не появится проблем с лицензией (были уже случаи, не на пустом месте появилась эта идея). В данном случае Canonical выступает, скорее гарантом, а не узурпатором. Не будет проблем, когда одна свора разработчиков грызётся с другой, в вечном перерождении идей, под твёрдым руководством даже опенсорс разрабатывать легче :) Все просто работают над одним продуктом, постепенно избавляясь от сторонних, разработку которых не могут контролировать (что рождает ещё одну кучу проблем), всё логично.Ведь посмотреть ретроспективно, Космонавт хотел иметь определённые фичи для Gnome2, и из-за опенсорсного "ты нам не указывай, как хотим, так и разрабатываем" он и пришёл к идее создания своего Unity, в котором будет иметь то, что ему нужно (я сам терпеть не могу Unity, но тем не менее). Из-за проблем с системой инициализации была начата разработка Upstart (как логичное развитие, а не революция, заметьте) и это Редхаты захотели иметь своё, впердепланетное (не слежу за этим, может кто знает истинные причины). Начали вводить Pulseaudio, опять дураки. А с Wayland вообще, обвинения в адрес Canonical не уместны. Они заинтересовались разработкой и планировали переход на него уже давно (из-за чего, опять же, получали только лучи ненависти от местной шантрапы). И только "неторопливость" разработчиков "вяленного", сорвавшая все сроки и планы, привели к созданию своего Mir'а. И опять потоки поноса в адрес Canonical от бандерлогов...
За что я так люблю Canonical? Да мне просто обидно, почему в опенсорсе идёт постоянная грызня? Кто голову высунул - говном закидают, палками побьют - "сиди не выпендривайся". Я люблю Canonical, я люблю ROSA, я люблю AltLinux, Calculate и прочих, которые что-то делают. (терпеть не могу Реактивную Ось, но это личное :) )
Вот в такой странной вселенной я живу.
> играет в прятки с опенсорсом[записывает что-то в блокнотик]
Оперу пишете? :)
Опер одобрил :)
Хороший пойнт. Единственное вот -- есть омрачающие обстоятельства.
* apt-cache show zeitgeist
* истории с (не анонимной) рекламой при использовании Dash в Unity. Такую сырую хрень нельзя было всё-таки выпускать. Как говорил Столлман, сообщество всё-таки должно учить их никогда так не делать.
> одна компания не в силах содержать проект мирового масштаба.Угу.
> "без ковыряния конфигов в консоле" - фиг там.Это хорошо. Нежелательно, чтобы Вы ковыряли конфиги в консоле.
>Сообщество всё равно будет поддерживать то, что привычнее емуСообщество (если это действительно сообщество, а не свора бродяжек) будет поддерживать то что выгоднее ему, а вовсе не то что привычнее. А выгоднее Linux сообществу разумеется GPL, а не BSD или Apache.
> Сообщество (если это действительно сообщество, а не свора бродяжек) будет поддерживать
> то что выгоднее ему, а вовсе не то что привычнее. А
> выгоднее Linux сообществу разумеется GPL, а не BSD или Apache.А тебе разумеется виднее что сообществу выгоднее? :)
Ты же не свора бродяжек какая, ты то что звучит гордо - батхерт саунд.flac
Чем бы ни маялись, лишь бы Ди не поддерживать! Их бы неуёмную энергию, да на написание библиотек!
Ди опоздал. Вовсю пилится го и ди вряд ли уже будет.
Ди если и опоздал, то не из-за Go. Абсолютно разные языки, с абсолютно разными масштабами и возможностями. "Что лучше - метапрограммирование или короутины" - идиотский же вопрос, не находите?
Во-первых, языки в масштабах ИТ не так скоротечны как кажется - ну умирает пара выкидышей, но достойные языки продолжают пилиться. Ди существует уже несколько лет и на сегодня практически готов для мэйнстрима (опустим пока вопрос библиотек).
Язык Го - не более языковат, чем другие поделия - ничто не мешает ему завтра сдохнуть и Гугл тут не поможет - банально потому, что руководится жлобами и держится на студентах. Сравни это с Ди, который создал весьма взрослый человек, написавший предварительно компилятор С++ - догадываешься, какой это титанический труд? Так что я бы поставил на Ди как прекрасную замену всем этим академическим сипипям - не так много в ОС кода, которому нужна ассемблерная скорость, зато куда важнее надёжность среды и утилит.
> Язык Го - не более языковат, чем другие поделия - ничто не мешает ему завтра сдохнуть и Гугл тут не поможет - банально потому, что руководится жлобами и держится на студентах.Вот как? А Роб Пайк и Кен Томпсон кто — жлобы или студенты?
> Сравни это с Ди, который создал весьма взрослый человек, написавший предварительно компилятор С++ - догадываешься, какой это титанический труд?
Хорошо. Сравнил. Людей, показавших свою способность принятия грамотных решений через создание юникса, с человеком, показавшим неспособность к оному через написание реализации этого титана на глиняных ногах. Ну и что? Всё равно разумные пользователи Го и Ди будут определять компетентность авторов по качеству соответствующего языка, а не наоборот.
А можно примеров хороших проектов на D? Не троллинга ради, просто интересно.
www.vibed.org
> ...академическим сипипям...Смеялся.
> на написание библиотекВы хотели сказать никому не сдавшихся D-обёрток над C/C++ библиотеками?
Вполне дельный проект, clang есть GCC есть, будет еще PCC. Стандартные библиотеки libc тоже не одна версия несмотря на то что есть GLIBC. Так что каждому свое, тем более автор не говорит что это будет супер-пупер новый навороченный компилятор. Современные компиляторы огромны, кодовая база тоже, рано или поздно надо все начинать с самого начала чтобы удалить лишнее м добавить актуальное
>чтобы удалить лишнееТ.е. функционал
>м добавить актуальное
Глюки, свистелки, интеграцию с СимстемД...
И не поспоришь, главное. Движуха - всё, цель - ничто. NextGen во всей красе.
Хорошо, когда есть выбор. Плодитесь и размножайтесь...
> Сообщество всё равно будет поддерживать то, что привычнее ему, а одна компания не в силах содержать проект мирового масштаба.смотря на Леню и его systemd я бы так однозначно и голословно не утверждал
>> Сообщество всё равно будет поддерживать то, что привычнее ему, а одна компания не в силах содержать проект мирового масштаба.
> смотря на Леню и его systemd я бы так однозначно и голословно
> не утверждалЛомать ― не строить.
> смотря на Леню и его systemd я бы так однозначно и голословно
> не утверждалКоллективный маразм. То что systemd везде это еще не повод для того чтобы говорить о его популярности. Большинство умов он захватил только потому что загружается быстрее стандартного sysV и все. По мне так это не основная задача программы, я не против новизны но не в таком виде как это сделано в systemd.
> Большинство умов он захватил только потому что загружается быстрее стандартного sysV и всеЛучше бы параллельный configure родили, в самом деле.
>> Сообщество всё равно будет поддерживать то, что привычнее ему, а одна компания не в силах содержать проект мирового масштаба.
> смотря на Леню и его systemd я бы так однозначно и голословно не утверждалВи же таки не понимаете! Ленарт не поддерживает "мировой масштаб", в мироваом масштабе он исключительно дисруптив-инновейтит. Ну, чтоб не было _других дистрибутивов, он же писал -- Уан РэдХейт Уэй.
Жаль только у них сплошной беспорядок в инфраструктуре. Не могут ребята воспользоваться GitHUB и CI для организации нужно им обязательно CVS использовать. Впрочем даже релиз они не выпустили в файла с нормальным именем. Короче говоря напомниает какое-то хоббийное написание компилятора уходящего в небытие языка (я лично про синтаксис и недостаток различного рода хитростей вроде deffer вызовов - вызовов при выходе из области видимости).
Жаль только у них сплошной беспорядок в инфраструктуре. Не могут ребята воспользоваться GitHUB и CI для организации нужно им обязательно CVS использовать. Впрочем даже релиз они не выпустили в файла с нормальным именем. Короче говоря напомниает какое-то хоббийное написание компилятора уходящего в небытие языка (я лично про синтаксис и недостаток различного рода хитростей вроде deffer вызовов - вызовов при выходе из области видимости).
И это хорошо.
Итак, удалось мне собрать PCC для Win32. К сожалению, вынужден отметить,
что несмотря на свой возраст компилятор пригоден скорее как исследовательский проект, так как мне не удалось начать использовать __stdcall вызовы.По этому поводу удалось обнаружить проблему http://pcc.ludd.ltu.se/jira/browse/PCC-511 и я так понимаю, что ближайшее время ситуация не измениться.
Таким образом для платформы Windows придется сделать обертки или как-то писать свои патчи.
Если кому-то станет интересно, то можете попробовать связаться со мной и я могу предоставить наработки по сборке для Windows и вам потребуются следующие инструменты SCons, MinGW, FLex, Bison.
Кого интересует твой вендузячий мазохизм?
> По этому поводу удалось обнаружить проблему http://pcc.ludd.ltu.se/jira/browse/PCC-511
> и я так понимаю, что ближайшее время ситуация не измениться.Ситуация изменилась на следующий же день -- разработчик исправил баг и, по его утверждению, теперь __stdcall работает правильно.