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

Я где-то утверждал о бинарной совместимости пакетов Mac OS X и FreeBSD? Может хорош уже ахинею нести? Ну или по крайней мере приплетать её ко мне.

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

Да ну, вот так прямо и плетутся? Если пойти дальше твоей логикой, то Mac OS X можно посчитать как один из клонов BSD и тогда вообще дико смотреть на заявителя поклонника операционной системы, которая имеет 1% распространения, об плохости другой операционки, которая имеет 10% долю и внутри которой работает BSDL софт. И вообще линукс плетется в глубокой жопы винды.

можно подумать FreeBSD сходу собралось,

Нет, конечно, но BSD'шники работают над этим.

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

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

BSD'шники работают над этим.

молодцы

Ну да, переведут они... со временем... возможно

если у вас есть конкретные аргументы и факты - напишите уже, а то пока слышно только - ядро Linux большое и сложное, мы себе не представляем объем работ, наверняка все очень сложно и у них ничего не получится

Тем дерьмо, а не userland, простите. Он абсолютно неюзабеленен.

Смотря что делать и смотря к чему привык

я ответил на пост alex-w. 1 абзац - ответ на 1 абзац. 2 абзац - ответ на 2 абзац. всегда ваш кэп

Да нет, ты отвечал на что-то другое, а не на мой пост. Я просил привести примеры получения денег С пользователей для BSDL проектов. Ну ты и привёл пример техподдержки. Который явно не в тему, ибо тогда RedHat и Canonical С этих самых пользователей как бабло стригут как с липки. А ведь вроде GPL и деньги должны получаться не С пользователей. Это про первый абзац. А на мой второй абзац - про развитие linux'а на деньги корпораций, ты вообще ничего не сказал, зато начал пространные объяснения про анальные зависимости.

если у вас есть конкретные аргументы и факты - напишите уже, а то пока слышно только - ядро Linux большое и сложное, мы себе не представляем объем работ, наверняка все очень сложно и у них ничего не получится

Так новость по этому поводу на ЛОРе была - там как раз и описывалось с какими модулями опа вышла. Но вообще можно и к первоисточнику обратиться - http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html Гораздо интереснее в этом плане попытка Debian'овцев собрать всю пакетную базу Debian'а Clang'ом - http://clang.debian.net/ Последний собирается на 91%, что весьма хорошо - будет конкуренция GCC и есть чем собрать систему, если по какой-то причине последний не хотят или не могут использовать. Однако местных троллей прямо за живое берет, когда не GNU'тые операционки от чего-то GNU'того избавляются.

clang, icc - не интересно. Вот где хардкор: http://bellard.org/tcc/tccboot.html

LLVM - это однозначно шаг вперёд. Сегодня некоторые узколобые пингвиноиды ноют «а нафик оно нужно!», но надо уметь смотреть ещё и в будущее - вот его-то они и не видят! Модульность LLVM - это не просто базворд для ченджлога, а целый громадный спектр возможностей (о которых, понятно, студота даже не догоняет). Просто подумайте, откуда в вашем редакторе может быть правильная подсветка синтаксиса? (не дебильная подсветка ключевых слов, а полноценная, правильная подсветка всех элементов языка) А интеллисенс? (причём на лету, только что введённое проперти отображается в списке) Монолитный кусог Г, в смысле ГЦЦ, это не позволяет просто в принципе.

К сожалению позволяет. Но и тут RMS со своим GPL маразмом пошел далеко. «Любой код который использует внутреннее состояние gcc обязан быть GPL». То есть все BSDL, MIT, Apache (привет эклипс!!!) лицензии не могут использовать результат работы gcc-xml.

Вы можете делать что угодно при условии что это GPL. вот такая она свобода по GPL :-) ограниченная до рамок и концлагеря.

Вы можете делать что угодно при условии что это GPL. вот такая она свобода по GPL :-) ограниченная до рамок и концлагеря.

«Свобода - это рабство.» - суть подобных идеологий.

Алгоритмы могут перетечь, если они впишутся в архитектуру gcc.

И какие же непреодолимы архитектурные особенности GCC помешают им вписаться?

ну например: в GCC тоже есть SSA, но это представление возникает после предыдущих GENERIC, GIMPLE — и не сохраняет некоторых деталей AST. Поэтому AST llvm в этом смысле удобнее — более подробный, и нет конвертации между этими 3 разными IR.

проходы оптимизации: например, для llvm есть в papers публикация на тему того, как можно определять оптимизации, от которых есть толк, чем-то вроде генетического программирования. То есть, есть оптимизации, которые composable, есть задача оптимизации — определение такого набора проходов оптимизации, который даст наибольший толк в каждом конкретном случае. Её можно решать автоматизированно (см. ту публикацию). А в случае gcc — нельзя, потому что IR сильно разные на разных этапах, и таких подробностей в AST не оставляют.

О, еще один считает, что llvm - не комилятор.

llvm — не компилятор, а тулкит для написания компиляторов :-) компиляторы это clang++, dragonegg, llc, наконец :) также, как gcc — это не компилятор, а драйвер для запуска компилятора (препроцессора cpp и собсно компилятора cc1) тулкит в виде библиотеки, в том числе, а не только отдельных утилит тулчейна, как gcc. кстати, watcom c++ тоже похоже сделан — компилятор в виде библиотеки. но поскольку API этой библиотеки внешний не очень широко разрекламирован (хотя IDE на базе Vi его например, использует), да и тулчейн свой NIH — он таки более компилятор, чем библиотека, а llvm — наоборот.

GCC тоже есть SSA, но это представление возникает после предыдущих GENERIC, GIMPLE — и не сохраняет некоторых деталей AST. Поэтому AST llvm в этом смысле удобнее

Я сказал, что прямого заимствования кода не будет; а насчет «более удобного» - это не архитектурное ограничение GCC, нужно будет - переделают (когда-то в GCC и SSA не было).

llvm — не компилятор, а тулкит для написания компиляторов :-)

Ну блин, что за буквоедство. Вот цитата с http://clang.llvm.org:

«The goal of the Clang project is to create a new C, C++, Objective C and Objective C++ front-end for the LLVM compiler»

Clang - фронтенд, LLVM - компилятор.

# /usr/lib/gcc-snapshot/bin/gcc --version

gcc (Debian 20120501-1) 4.8.0 20120501 (experimental) [trunk revision 187013]

Только что обновилось:

===>   Registering installation for gcc-4.8.0.20120513
===> SECURITY REPORT: 
      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/lib/gcc48/libmudflapth.so.0
/usr/local/lib/gcc48/libmudflap.so.0

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage: 
http://gcc.gnu.org/

Это рабство рабовладельцев, да. GPL обеспечивает свободу всего, кроме попыток эту свободу отнять. Учите мат часть.

А вот всякие проприетарные реализации Davlik'а не согласны.

А вот всякие проприетарные реализации Davlik'а не согласны.

С чем несогласны?

Это рабство рабовладельцев, да.

У Штольмана своё, особое рабство?

GPL обеспечивает свободу всего, кроме попыток эту свободу отнять. Учите мат часть.

Свобода неделима. Учите мат часть.

а насчет «более удобного» - это не архитектурное ограничение GCC,

таки ограничение, архитектурное.

1. Зачем в GCC столько самых разных IR : GENERIC, GIMPLE, вот ещё SSA, вместо одного единого на все, достаточно универсального? с достаточно богатыми метаданными на все случаи жызни и внятным API?

2. Модель компиляторного тулчейна как такового: драйвер:=(препроцессор, фронт-енд:{парсер,анализ семантики на корректность}, миддл-енд:{оптимизатор},бэк-енд:{кодогенератор, линкер в смысле LTO,ld-binutils:{linker scripts,..., collect2},ld.so в ядре для загрузки во время exec)

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

Что означает минусы:

1а)процессы порождать дорого. Хорошо если у нас есть fork() с COW, а если голимый CreateProcess()? да там порождение процесса дольше займёт времени чем сама работа, в большинстве случаев.

1б)представления у всех разные, и чтобы была какая-то согласованность, эту кашу представлений менять более трудоёмко.

1в)повторная используемость AST собираемого проекта между тулзами тулчейна — хреновая. Её нет на уровне AST, есть на уровне уже собранного IR (типа ccache)

1г)повторная используемость AST компилятора между тулзами тулчейна, то есть усложнённый кросскомпилятор. Вместо одного компилятора, разных линкеров (как в план9 8c,8l) или разных компиляторов, одной библиотеки (как в watcom c++) — имеем разные кросстулчейны целиком или велосипед с канадским крестом. Почему этот кросстулчейн собирается целиком под платформу, зачем мне копия фронт и миддленда в кросстулчейне, когда мне было бы достаточно только бекенда?

1д) время на парсинг текстовых конфигов (linker scripts, machine description, RTL desc и т.п.) всяко больше будет чем вменяемый бинарный API. Но текст — расширяемей. С другой стороны проблема не в парсинге как таковом, а в велосипедности и недостаточной унифицированности этих форматов друг с другом, когда нарушается DRY-принцип и изменения вносить во все эти места становится сложнее.

Отсюда необходимость всяких костылей вроде GCC MELT, или GCC-guile, т.е. GCC с вкоряченным лиспом (сборщик мусора в GCC и так уже есть свой) или схемой: с разноформатными данными работать более неудобно, чем с нормальным расширяемым API.

1ё) хреновая модульность, несмотря на наличие плагин-апи. потому что нужную функциональность ещё надо в этот плагин выделить, т.е. переписать свой конпелятор вроде mingw,gdc,gccgo, gccpy, gcalc ( http://gcc.gnu.org/wiki/WritingANewFrontEnd?action=AttachFile&do=get&... ) и прочая в виде плагина. То, что писатели означенных конпеляторов этого по дефолту не делают, а хренячат сборку целиком (по аналогии с кросстулчейном целиком) означает, что делать им это сложно, ибо ниасилили. хотя вот в dragonegg — осилили, может проблема с руками и nobody cares (и теперь при пересборке llvm новой версии плагин отваливается и требует пересборки заново gcc и самого плагина, что означает что всё-таки можно модульность и улучшить)

правда есть и плюсы:

2а) в тулчейн посредине можно вкорячить какую-то свою тулзу, которую писать просто (за исключением 1б, когда это представление нужно как-то расширять)

2б) компоненты тулчейна лучше изолированы друг от друга (хм, а в чём профит-то?)

Versus что?

компиляторный тулчейн как набор библиотек с достаточно универсальным форматом данных и внятным API.

нужно будет - переделают (когда-то в GCC и SSA не было)

ну да, если осилят в очередной раз переделывать заодно и все эти промежуточные представления, чтобы усё в целом не сломалось в очередной раз. сколько там времени реализация LTO заняла? по сравнению с например, Open64 — чудесатый такой дендромутант с фронтендом от gcc, и бекендом от sgicc (и работающим LTO, IPO «из коробки» и т.п.)

Зачем в GCC столько самых разных IR : GENERIC, GIMPLE, вот ещё SSA

Ты же и сам понимаешь, что по историческим причинам.

Остально квотить не буду. Скажу коротко: ничего из перечисленного не помешает реализации интересных _алгоритмов_ из Clang.

Versus что?

компиляторный тулчейн как набор библиотек с достаточно универсальным форматом данных и внятным API.

GCC движется к этому. LLVM и Clang тоже не за неделю сделали.

P.S. что такое «конпелятор»?

P.S. что такое «конпелятор»?

Это то, ради чего нужно «вступать и конпелировать». В отличие от «компилятора», который просто работает :-)

GCC движется к этому.

пока только высказываются намерения, причем с пессимистичными нотами, ну и кто будет пользоваться библиотеками на GPLv3?

пока только высказываются намерения

Я уже давал ссылку как минимум на один проект (работающий) статического анализатора кода, выполненного в виде плагина: https://fedorahosted.org/gcc-python-plugin/

ну и кто будет пользоваться библиотеками на GPLv3?

Время покажет. Может быть, и никто.

Давно пора.

LLVM/Clang 3.1 портирован в ветку FreeBSD 9-STABLE

Сегодня LLVM/Clang 3.1 портирован в ветку FreeBSD 9-STABLE.

Сегодня LLVM/Clang 3.1 портирован в ветку FreeBSD 9-STABLE.

В смысле там ИМ компилять будут или его туда просто засунули?

(Ссылка есть?)

В смысле там ИМ компилять будут или его туда просто засунули?

Оба случая.

Ссылка есть?

Сейчас система пересоберётся — будет.

Блин, ничего существенного, оказывается...

http://svnweb.freebsd.org/base?view=revision&revision=234353

Пара ссылок

http://www.phoronix.com/scan.php?page=news_item&px=MTA5NzU

http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23

Не, это понятно. Я просто думал им систему наконец собирать начали по умолчанию и в 9-ке.

Я начал систему и ядро им собирать с выхода FreeBSD 9.0-BETA2. А по умолчанию сейчас собирается, только в /etc/src.conf прописать опции нужно:

WITHOUT_GCC=true
WITH_CLANG=true 
WITH_CLANG_IS_CC=true

В сравнении с предыдущей оценкой скорости компиляции новый компилятор показывает:

% cd /usr/src/ && time make buildkernel
...
...
--------------------------------------------------------------
>>> Kernel build for ROXY completed on Sat May 19 11:43:50 VOLT 2012
--------------------------------------------------------------
649.982u 115.373s 13:13.01 96.5%	23798+853k 9375+1731989io 34419pf+0w

% uname -a
FreeBSD roxy.fire 9.0-STABLE FreeBSD 9.0-STABLE #0: Sat May 19 11:04:24 VOLT 2012     root@roxy.fire:/usr/obj/usr/src/sys/ROXY  amd64

% cc --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix

Clang - фронтенд, LLVM - компилятор.

facepalm.jpg.tar.bz

И вообще линукс плетется в глубокой жопы винды.

чьорд, я так и знал что он плетёный

что такое «конпелятор»?

это что-то вроде шланга с 5 зелёными звёздами

Clang - фронтенд, LLVM - компилятор.

facepalm.jpg.tar.bz

Пошли его Латтнеру.

это же facepalm, он имеет нулевой размер и битую контрольную сумму

и да, раз уж зашла речь clang - frontend, llvm - backend, и всё вместе - копилятор

Процесс компиляции состоит из следующих этапов:

1. Лексический анализ. На этом этапе последовательность символов исходного файла преобразуется в последовательность лексем.
2. Синтаксический (грамматический) анализ. Последовательность лексем преобразуется в дерево разбора.
3. Семантический анализ. Дерево разбора обрабатывается с целью установления его семантики (смысла) — например, привязка идентификаторов к их декларациям, типам, проверка совместимости, определение типов выражений и т. д. Результат обычно называется «промежуточным представлением/кодом», и может быть дополненным деревом разбора, новым деревом, абстрактным набором команд или чем-то ещё, удобным для дальнейшей обработки.
4. Оптимизация. Выполняется удаление излишних конструкций и упрощение кода с сохранением его смысла. Оптимизация может быть на разных уровнях и этапах — например, над промежуточным кодом или над конечным машинным кодом.
5. Генерация кода. Из промежуточного представления порождается код на целевом языке.

за 1-4 отвечает frontend, за 4-5 - backend

Да скажи уже прямо - что в связке LLVM + Clang ты считаешь компилятором? %)

Clang - фронтенд, LLVM - миддленд и бэкенд.

А то, что делает майкрософт - это просто сляпаное на отъебись левой пяткой задней ноги недоразумение,

ну-ну :)

разработчики которого о Стандарте не слыхали.

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

мелкомягкие им платят деньгами

BSDшники мелкомягким платят кодом, который на халяву запроприетарчивается мелкоямягкими

на халяву

Ну вот зачем быть таким бараном?

Ты баран — тебе и виднее.

кто будет пользоваться библиотеками на GPLv3?

учим матчасть, http://gcc.gnu.org/onlinedocs/libstdc /manual/license.html

учим матчасть

там английским по белому написано - " The source code is distributed under the GNU General Public License version 3", если ты умничал по поводу исключения - о нем все знают