Собственно Portable C Compiler - это то, чем OpenBSD и NetBSD хотят заменить GCC (в FreeBSD для этого используются эппловские наработки).

Мне, как дилетанту, только одно непонятно: этот PCC будет только C компилировать? То есть уже для С++ (для остальных-то языков, поддерживаемых GCC обычно есть и другие компиляторы, зачастую BSD-licensed) нужно будет что-то другое?

вроде он только С

причем без оптимизации

>в FreeBSD для этого используются эппловские наработки
это вы на clang/llvm намекаете?

этот PCC будет только C компилировать?

да только C

Ну и зачем этот велосипед? Только ради лицензий?

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

Он скорее всего не генерит ошибки в коде

Скорее всего он просто типа под православной лицензией, хотя и не скажешь, что это велосипед, писать его кажется ещё в 70ых начали

Не, ну велосипед в том смысле, что уже есть готовое и общепризнанное решение - GCC

это вы на clang/llvm намекаете?

Ну да.

> clang/llvm

это разумное современое решение

а pcc это говно мамонта

Ну и с лицензией тоже вопрос достаточно важный с точки зрения BSD-философии. Какой смысл делать полностью свободную ОС, если ее главный компонент - несвободен? В любом случае, следуя логике BSD-проектов, им банально удобнее работать с собственным решением, которым они полностью управляют (в смысле, определяют его развитие и т.д.).

Ну а так, по логике вещей: раз только один язык (без Java, Ada, Pascal и т.д. и т.п., что как бы нужно далеко не всем), то меньше кода, более стройная организация, работает быстрее и удобнее разбираться в нем. Алсо, где-то читал, что собирает он все-таки быстрее (но неизвестно что со скоростью собранного кода). Ну и портабельность, что важно для NetBSD/OpenBSD с их кучами архитектур.

Ну а кстати, так ли много есть популярного С++ кода (кроме KDE/Qt?)

C++ популярного много. OpenOffice, Firefox, WebKit

скорость сборки выше за счет отсутвия оптимизации. По моему оно даже inline автодетектить не может

А у тогоже llvm лицензия кошерная

Утро

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

отвечая на некоторые реплики. дело тут даже не столько в лицензии (хотя разумеется никто не в восторге от нее в бсдшной среде), а вот очень низкой maintainability gcc.

clang/llvm

это разумное современое решение

а pcc это говно мамонта

http://www.nycbsdcon.org/2008/files/magnusson_pcc.pdf

Я так понимаю, что нужно еще учитывать разницу между приоритетами OpenBSD/NetBSD и FreeBSD. Из презентации следует два основных пункта: маленький объем кода и легкая переносимость. Соответственно, маленький объем кода удобен в первую очередь опенку (легче проводить аудит и т.д.), переносимость - сетевой бзде. А на высокой производительности обычно специализировался FreeBSD, потому они идут другим путем.

Ну это я так понимаю.

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

Только ради того, чтобы выкинуть монстроидальное быдлоподелие под названием gcc.

Зачем? Так вот же они ругаются [ http://habrahabr.ru/blogs/os/31277/ ] Как эти претензии оценивать пусть каждый сам думает.

общепризнанный

Всегда ли это хорошо? Просто другого решения нет

Ну это полный отказ от оптимизации

Для Ъ:

По словам Марка Эспи (Mark Espie) причина в том, что разработчики GCC приследуют иные цели, чем разработчики OpenBSD. Разницу он показывает следующими пунктами.

(1) GCC сейчас - это почти коммерческая разработка. Ей занимаются дистрибьюторы коммерческих дистрибутивов Linux и Apple. Компилятор нацелен на быстрые i386 и PowerPC процессоры только. При этом, его затачивают под набор высоких баллов в SPEC. (От меня) Как известно, заточка компиляторв под определённые программы осуществляется дедовским способом - просто увеличивается база шаблонов, которые компилятор должен узнавать и выдавать для них заранее написанный человеком код. Поэтому... (От Марка) Но компилятор становится всё больше и больше, всё медленней и медленней, при этом намного. (От меня) В чём с сожалением убеждается любой пользователь Gentoo в последние несколько лет.

(2) Предупреждения в GCC бесполезные. Компиляция с -Wall сообщает о множестве верных вещей, и о небольшом количестве неверных.

(3) Весь дизайн GCC извращён настолько, что никто не может даже выделить front-end и back-end компилятора (от меня: истинная правда, помниться, как мы занимались с gcc любовью в попытках научить понимать его нерегистровые архитектуры). Он корявый, начиная с дизайна (broken by design), так как GPL'ный народ боится, что коммерческие организации смогут украсть backend или frontend и прицепить их к закрытым языкам или кодогенераторам (от меня: странный вывод, однако). Возможно, это правда. Но это не позволяет создавать интересные инструменты, такие как анализаторы промежуточного кода. И это так же не позволяет использовать backend'ы для старых архитектур c новыми компиляторами.

(4) В результате, нельзя поиметь новые интересные фишки новой версии GCC, не потеряв старые интересные фишки (от меня: угу, чтобы скомпилировать QEMU до сих пор приходиться таскать с собой GCC 3.)... Каждое обновление GCC - это инженерный кошмар, потому что здесь нет простого выбора: получаете возможности, но теряете важные особенности. (От меня) Ну, на самом деле, это проявляется редко, но если проявляется, то действительно геморрой.

(5) Так же очень сложно заниматься разработкой GCC. Их система ветвления делает весьма вероятным то, что важная работа пропадёт между разломами (cracks) (и это случается постоянно). Если вы разрабатываете код для GCC, это нужно делать на самой свежей ветке, что довольно сложно, если ваша платформа в настоящее время неработоспособна (случается постоянно если вы не под linux/i386) (от меня: вероятно, имеется в виду то, что gcc-i686-pc-bsd новой версии не работает). Даже тогда, когда вы приспосабливаетесь, тяжело писать код в согласии со стандартами кодирования GNU, которые, возможно, самые трудные для чтения для Си. Очевидно, что они были придуманы lisp-программистом. В результате я (Марк) даже потерял интерес к переписыванию и отправке в репозиторий GCC нескольких кусков кода.

(6) Некоторые последние усовершенствования не имеют шансов работать в OpenBSD, например, преразобранные include'ы, которые опираются на mmap() по фиксированному адресу (от меня: странное решение разработчиков GCC. Намного ли сложнее было воспользоваться тем адресом, который возвращает mmap()?)

(7) Существует несколько мест в GCC и G++, где вы не можете получить полную функциональность, не имея аналога glibc (от меня: а параноидальные OpenBSD'шники, естественно, полного такого аналога не имеют, потому что в нём много багов).

(8) Некоторые методы оптимизации определённо опасны, и неправильны для нас (например, выбрасывание во время оптимизации заполнений памяти, даже если они имеют дело с криптоключами) (от меня: ну да, плохо будет, когда ваш memset(0, 256, &rsakey) компилятор выкинет из кода, потому что больше обращений к rsakey не будет. Плохо, потому, что ту же физическую старницу памяти может получить другой процесс)

(9) И не забывайте кошмар, связанный с autoconf/libtool/automake (от меня: о да, детка). Чёрт, даже у самих GCC'шников обновление инфраструктуры для совместимости с последними automake'ами заняло несколько лет. И при этом, GCC - единственная програма из дерева переносимых (ports tree) которая на самом деле использует внутреннюю реализацию libtool. Её конфигурация и реконфигурация полностью заваливается, когда вы пытаетесь использовать libtool системы.

Я (Марк) на самом деле мог бы продолжать ещё на нескольких страницах. Я был мэйнтейнером GCC на OpenBSD в течении нескольких лет и буду счастлив преключиться на другой компилятор, настолько разочаровывающей был путь с GCC.

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

> Ну это полный отказ от оптимизации

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

>(1) GCC сейчас - это почти коммерческая разработка. Ей занимаются дистрибьюторы коммерческих дистрибутивов Linux и Apple. Компилятор нацелен на быстрые i386 и PowerPC процессоры только.

Бред сивой кобылы, особенно второе предложение, если конечно изначальный смысл не измен и имелось ввиду что на этих архитектурах код затачивается под новые процессоры.

> а вот тонны шаблонов как в гцц точно не будет. также, в планах оптимизирующий анализ промежуточного кода.

Полностью согласен

просто по моему что разархивация старого pcc, что написание нового - задача одного уровня

GCC is mostly a commercial compiler, these days. Most GCC development is done by commercial linux distributors, and also Apple. They mostly target *fast* i386 architectures and PowerPC

в оригинале
- GCC is mostly a commercial compiler, these days. Cygnus software has been bought by redhat. Most GCC development is done by commercial linux distributors, and also Apple. They mostly target *fast* i386 architectures and PowerPC. A lot of work has been done on specmarks, *but* the compiler is getting bigger and bigger, and slower and slower (very much so).

> (от меня: угу, чтобы скомпилировать QEMU до сих пор приходиться таскать с собой GCC 3

(от меня: странное решение разработчиков GCC. Намного ли сложнее было воспользоваться тем адресом, который возвращает mmap()?)

Что за специалист писал ремарки «от меня»?

Налицо подмена понятий - то что открытый проект спонсируется идет только на пользу. И да - в поддержке своих процессоров заинтересованы в первую очередь производители процессоров а не дистрибутеры коммерческих линуксов.

>Что за специалист писал ремарки «от меня»?

Не знаю, какое-то существо с хабра. Я просто опубликовал для Ъ. Поэтому за качество перевода не отвечаю.

> просто по моему что разархивация старого pcc, что написание нового - задача одного уровня

Ну да, все они дураки, один ты умный. Самому не смешно?

> это разумное современое решение

а pcc это говно мамонта

Стереотипное мышление, старое = плохое, дорогое/новое = хорошее?

>Стереотипное мышление, старое = плохое, дорогое/новое = хорошее?

Кстати да, новый софт — говно полное.
И с каждым разом все хуже и хуже.

А тем временем gcc к 4.4, по сравнению с третьей веткой, просто эпично улучшили и собирать он, кстати, стал быстрее, чем 4.2 или 4.1.

> Стереотипное мышление, старое = плохое, дорогое/новое = хорошее?

Это не тот случай. Если не ошибаюсь, то pcc уже более 20 лет.

достаточно почитать даже тот же dragon book, чтоб понять, как быстро развивается наука о компиляторах.

просто объем научных данных, доступных тогда, был меньше

а компилятор С щас напишет чуть ли не школьник

4.4 уже стал лучше чем 4.3? Раньше вроде была инфа, что в 4.3 генерируемый код быстрее.

> Это не тот случай. Если не ошибаюсь, то pcc уже более 20 лет.

Ошибаешься. Он был разработан в семидесятые года. Кстати, а ведь язык Си то же старый. Ему то же много лет. И что, на свалку?

достаточно почитать даже тот же dragon book, чтоб понять, как быстро развивается наука о компиляторах.

просто объем научных данных, доступных тогда, был меньше

Задача иметь простой и рабочий компилятор. А для этих целей pcc отлично подходит. Зачем писать что-то ещё раз? Об оптимизации речь никто не ведёт. А разбор/семантический анализ/примитивная оптимизация/кодогенерация - так тут и не требуются знания за 20 лет.

а компилятор С щас напишет чуть ли не школьник

Ага, как же. Не каждый студент напишет.

Ну теперь уж *BSD точно капец!

> Ага, как же. Не каждый студент напишет.

Да ладно. ТРЯП понятен развитому школьнику. Хотя конечно у него сил не хватит. Я имел в виду что ничего сложно.

Задача иметь простой и рабочий компилятор.

Да с этим я уже давно согласился.

А разбор/семантический анализ/примитивная оптимизация/кодогенерация - так тут и не требуются знания за 20 лет.

А кто помнит, когда матеамтика граматик была доведена до практического применения? Просто интересно. Наврено как раз 70-80 года.

> Я имел в виду что ничего сложно.

Ты видел код студентов? Ну, лабы по ЧМ разные, или ещё какие? 95% - полный #$%@#$%! Ни форматирования, ни даже единого стиля.

>> А разбор/семантический анализ/примитивная оптимизация/кодогенерация - так тут и не требуются знания за 20 лет.

А кто помнит, когда матеамтика граматик была доведена до практического применения?

Что такое «математика грамматик»? Работы по формальным грамматикам - начало 60-х, первые инструменты вроде yacc - конец 60-х.

А что еще нужно допилить в PCC, чтобы им начали заменять GCC в OpenBSD/NetBSD?

архитектуры. пока что нормальный кодогенератор только для х86

> Ну а так, по логике вещей: раз только один язык (без Java, Ada, Pascal и т.д. и т.п., что как бы нужно далеко не всем), то меньше кода, более стройная организация, работает быстрее и удобнее разбираться в нем.

Читал, что PCC был классикой, на которую все равнялись, и GCC повторяет его структуру: вначале фронт-энд транслирует язык высокого уровня в промежуточный код, затем этот код транслируется под конкретную архитектуру. Сложно, зато портативно. И так же как для GCC существуют фронт-энды для других языков помимо C. Недавно мелькала ссылка на воспоминания людей, писавших под него компилятор C++.

Интересно, что там с правами SCO на части кода этого компилятора? Молчат?

«maintainability» это хорошо. Но кроме удобства девелопера, ведь есть еще производительность. А тут, я думаю, сравнивать pcc и gcc смысла нет. Итого получаем, что openbsd сделал еще один шаг назад в области производительности.

Но тем не менее, было бы интересно посмотреть сравнительную статистику.

мало того, теперь для компиляции портов, все равно придется тянуть в систему доп. компилятор.

а кто компилирует порты? почти всегда все ставится из пакетов. да и компиляторов все равно обычно 3, если уж хочется покомпилировать.

Теперь *BSD еще больше RIP, потому что это тормозное pcc никому нафиг не нужно.

ага, все остальное описаное было культурно опущено :)

что все остальное, плевок в сторону производительности?
для меня лично профит от нормального удобного компилятора, который _пока_ генерирует не самый быстрый код, перевешивает факт неоптимального кода. и я думаю я не один такой. особенно для тех задач, где применяется Опен (это же не вычислительные кластеры).

<fat>

зато PCC перестал собирать собственные pcc-libs под тем же линуксом с glibc, пришлось gcc брать )

> «maintainability» это хорошо. Но кроме удобства девелопера, ведь есть еще производительность. А тут, я думаю, сравнивать pcc и gcc смысла нет.

Лучше пусть всё работает медленно. Чем быстро, но неправильно.

Да, а ты читал про OpenBSD и их цели? Судя по заявлению о производительности - нет =)