Разработчики OpenBSD сообщили (http://undeadly.org/cgi?action=article&sid=20091228231142) о продолжении разработки компилятора PCC (http://pcc.ludd.ltu.se/) (Portable C Compiler), последние улучшения в котором позволили осуществить полный цикл сборки загрузочного ядра OpenBSD для архитектуры x86, а также большинства утилит и библиотек базового окружения. Поддержка сборки для платформы AMD64 в настоящий момент находится в состоянии активной разработки и будет доведена до рабочего состояния в ближайшее время.
PCC распространяется в рамках лицензии BSD и развивается в качестве полноценного компилятора для языка Си, полностью совместимого со стандартом C99 и частично совместимого с GCC. PCC является в значительной степени переработанным вариантом компилятора Portable C Compiler, разработанного S. C. Johnson в конце 70-х годов прошлого века. В настоящее время проектом занимается Anders Magnusson из команды разработчиков NetBSD. В настоящий момент размер архива последней сборки (ftp://...URL: http://undeadly.org/cgi?action=article&sid=20091228231142
Новость: http://www.opennet.me/opennews/art.shtml?num=24853
а что толку? все одно нужно gcc ставить что бы дополнительный софт собрать где большая часть на c++ написана
Ну здрасьте"
apache, sendmail, postfix, exim, postgresql, mysql и т.д. все на ANSI C написаны, очень редко когда что-то на С++
qt,kde... )))
Мсье знает толк в извращениях.
Еще бы его собрать под Win32! Да и еще бы кросс-компиляцию освоить!
А потом если он и правду не так сильно велик, то появиться AVR-PCC,
PIC-PCC и т.п. А потом уже глядишь и на каком-нить наладоннике ядро
можно будет писать программки...
может лучше юзать его в качестве front-end llvm? он уже доведён до ума
И что, генерит код под AVRовское ядро? И даже не сильно похабный? Пруфлинк?
> Еще бы его собрать под Win32! Да и еще бы кросс-компиляцию освоить!По-моему, в список еще губозакатывательную машинку надо включить.
> А потом если он и правду не так сильно велик, то появиться AVR-PCC,
Долго ждать придется. Посмотрите через сколько лет существования gcc появился avr-gcc. В итоге пока оно станет юзабельно (если вообще станет) т.е. будет генерить более-менее непохабный код без кучи глюков - наверное пора будет на пенсию собираться, а AVRки останутся только в музее политехники как ископаемые.
И чем плох avr-gcc? Тем что под GPL? А, гм, мне это никаким боком не мешает, его лицензия позволяет собирать им все что угодно, вплоть до защищенной от копирования фирмвари. И он уже есть. Ну и логично что народ его и допиливает. Да и еще под кучу архитектур есть. А прогресс не стоит на месте - появляются новые процессорные ядра и архитектуры, etc. И хорошо бы чтобы современное ядро поддерживалось сейчас. А не через 10 лет, когда оно уже никому не надо. GCC уже стал стандартным тулкитом который уже считается хорошим тоном предоставить к своим процессорам/uC в комплект. Ну и чудненько, нафиг нужно изучать зоопарки компилеров.Проще изучить GCC и юзать его везде.Благо програмера он никак не ограничивает.
зачем нужен РСС ? чтоб с его помощью собрать из исходников новейшую версию GCC и юзать уже её.
Учитывая, что не так давно в gcc такого наворотили, что Линус долго плевался, а разработчики компилятора исправлять отказались, PCC нужен.
имхо давно просился компилер на замену gcc. В крайнем релизе огромные косяки с многопоточностью.
>имхо давно просился компилер на замену gcc. В крайнем релизе огромные косяки
>с многопоточностью.Возможно и нужен, ещё конечно вопрос нужен ли, потому что всегда можно взять и исправить косяки, любые. Но даже если представить что нужен, то надо чтобы набор компиляторов поддерживал такое же количество архитектур, языков и имел более высокое качество. Пока таких нет, и даже не намечается.
Единственный претендент - это clang с llvm, но до поддержки языков уровня gcc ему очень далеко. А сабжу и вообще как до луны.
>... В крайнем релизе огромные косяки с многопоточностью.Ммм, поясните, плз, что вы имеете в виду?
Ой ой выравнивание стека сделали как всем нужно, а не только писателям ядра. Страшное чудовищное преступление.
Давайте конкретнее уже. Если говорить серьзно, то слушать можно не Линуса, а сообщество debian. Вот когда в нём станут использовать что-то другое. Или когда это будут делать в gentoo, тогда можно рассматривать подобные сабжи по ближе.
Полудохлые проекты с со слабыми результатами никому и никогда не были нужны. Хорошие замены или альтернативы - нужны, но не полудохлые, лишь оттягивающие на себя незаслуженное внимание.
> Давайте конкретнее уже. Если говорить серьзно, то слушать можно не Линуса, а сообщество
> debian. Вот когда в нём станут использовать что-то другое. Или когда это будут делать в
> gentoo, тогда можно рассматривать подобные сабжи по ближе.
> Полудохлые проекты с со слабыми результатами никому и никогда не были нужны. Хорошие
> замены или альтернативы - нужны, но не полудохлые, лишь оттягивающие на себя
> незаслуженное внимание.Нужен нормальный (людский) компилятор с минимально программируемыми стадиями, чтобы sparse-подобные (или просто свой простейший ворнинг добавить) вещи надо быль не с нуля писать. В этом смысле gcc ужасен.
ТОчно. И компиляция в 2-3 раза медленнее gcc. Или вам и скорость и гибкость и губозакатывательную машину одновременно?
Когда Debian перейдет на использование другого это уже все, продукт практически умер.
Использование PCC в Gentoo это будет весьма серьезный аргумент в пользу оного. Но боюсь, что зависимость gentoo от gcc такова, что он умрет вместе с gcc.
Компиляция с помощью pcc это тема отдельного форка. Будет какой-нибудь Pentoo.
Уже есть такой :)
Зависимость Gentoo от gcc? Это шутка или как? Б'ольшинство системных пакетов дженту не компилируются gcc, потому что написаны сами знаете на чём. А если вы про компиляцию софта, так это в той же степени касается и debian, и freebsd и всех прочих свободных юниксподобных систем, на которых софт собирается с помощью gcc.
Включение альтернативного компилятора возможно в gentoo уже сейчас, и уже давно зависимость от gcc снижена, прежде всего из-за проблем со сборкой софта одной новыми версиями gcc, чтобы держать в системе сразу несколько версий.
В общем то всё уже давно готово, чтобы заюзать новый и крутой компилятор в gentoo, debian и freebsd. Да только где он, этот рыцарь на белом коне.
Кстати по поводу PCC, был ведь супертурбированный и очень простой tinycc, которым можно было легко собрать большинство программ на С, заточенных под gcc. Ну и что от этого изменилось? Да ничего. Потому что для большинства случаев простой компилятор С никому не нужен, разве что разработчикам openbsd, у которых свой, особенный взгляд на мир.
Все познается в сравнении. При любом раскладе дистр с бинарной пакетной системой проще будет перевести на другой компилятор в силу принципиально иной степени зависимости от компилятора.
При том, что отвязывание от конкретной версии компилятора gcc не означает полную независимость. Увы...
А наличие выбора нужно всем. Было время когда об альтернативе gcc никто и подумать не мог. А теперь gcc не кажется безальтернативным. Все в этом мире появляется растет и умирает. Придет время и GCC. Причем, есть основания полагать, что еще при нашей жизни...
>Все познается в сравнении. При любом раскладе дистр с бинарной пакетной системой
>проще будет перевести на другой компилятор в силу принципиально иной степени
>зависимости от компилятора.
>При том, что отвязывание от конкретной версии компилятора gcc не означает полную
>независимость. Увы...Мне правда сложно понять в чём разница.И в том и в том случае нужно иметь универсальную архитектуру сборки, работающую на разных компиляторах. Разница лишь в том, что в случае gentoo её нужно иметь локально. Если бы бинарные пакеты брались откуда-нибудь с луны, тогда да. Но они тоже собираются. и тоже их желательно собирать автоматически, иначе поддержка пакетов будет адским делом.
>А наличие выбора нужно всем. Было время когда об альтернативе gcc никто
>и подумать не мог. А теперь gcc не кажется безальтернативным. Все
>в этом мире появляется растет и умирает. Придет время и GCC.
>Причем, есть основания полагать, что еще при нашей жизни...Удивляют меня мысли о том, что что-то обязательно должно умереть, вот прямо обязательно. Даже у ms есть шанс полностью перестроить свой бизнес и продолжать здравствовать как крупная организация.
А у gcc этих шансов намного больше. Ничто принципиально не мешает перекроить архитектуру компилятора версии этак в 5й или в 6й. Вопрос только в том кто и зачем это делать будет, и на какие шиши. В случае допустим llvm, всё тот же вопрос. Кто и на какие шиши запилит там поддержку всех архитектур и языков. Если с clang, и даже с поддержкой c++, архитектурами arm, intel ещё понятно - ибо apple в этом заинтересована кровно. То со всем остальным не совсем понятно, будет ли на таком же уровне.
Все эти разговоры примерно также забавны, как разговоры о смерти linux в связи прихода микроядер и других, подобных тем. Они не учитывают возможности измениться, а это просто недальновидно. Вон Евросоюз живёт и здравствует, кто бы мог подумать это лет этак 90 назад.
>
>Мне правда сложно понять в чём разница.И в том и в том
>случае нужно иметь универсальную архитектуру сборки, работающую на разных компиляторах. Разница
>лишь в том, что в случае gentoo её нужно иметь локально.
>Если бы бинарные пакеты брались откуда-нибудь с луны, тогда да. Но
>они тоже собираются. и тоже их желательно собирать автоматически, иначе поддержка
>пакетов будет адским делом.Это зависит от организации процесса сборки дистра.
Бинарный пакет может быть собран мантейнером с использованием любого компилятора, лишь бы с abi разделяемых библиотек дистра совмещалось. Зачастую в бинарных дистрах gcc может вообще не устанавливаться.
>
>Удивляют меня мысли о том, что что-то обязательно должно умереть, вот прямо
>обязательно. Даже у ms есть шанс полностью перестроить свой бизнес и
>продолжать здравствовать как крупная организация.Непутайте организации и лейблы, или как их любят называть, торговые марки. От того что кто-то через 50 лет выкупит торговую марку MS, ничего не значит.
>Вон Евросоюз живёт и здравствует, кто бы мог подумать это лет этак 90 назад.Евросоюз, как политически и экономически значимая организация существует всего 2 десятка лет по моему... 90 лет назад (это по сути до второй мировой войны) это считалось в принципе не возможным.
>А у gcc этих шансов намного больше. Ничто принципиально не мешает перекроить
>архитектуру компилятора версии этак в 5й или в 6й. Вопрос только
>в том кто и зачем это делать будет, и на какие
>шиши. В случае допустим llvm, всё тот же вопрос. Кто и
>на какие шиши запилит там поддержку всех архитектур и языков. Если
>с clang, и даже с поддержкой c++, архитектурами arm, intel ещё
>понятно - ибо apple в этом заинтересована кровно. То со всем
>остальным не совсем понятно, будет ли на таком же уровне.А для всего остального деньги будут вкладывать разработчики платформ. Вопрос только в затратах. Как только окажется, что реализация поддержки новых платформ в llvm окажется дешевле чем в gcc, так gcc сразу же начнет терять свои позиции. И похоже все дело к тому и идет. Потому, как в случае LLVM достаточно реализовать лишь виртуальную машину и весь ворох компиляторов и интерпретаторов будет тут же доступен на новой платформе. В случае gcc все это сложнее. Да и лицензия тут может сыграть не последнюю роль.
>Все эти разговоры примерно также забавны, как разговоры о смерти linux в
>связи прихода микроядер и других, подобных тем. Они не учитывают возможности
>измениться, а это просто недальновидно. Вон Евросоюз живёт и здравствует, кто
>бы мог подумать это лет этак 90 назад.Думаю тут будет правильней обратиться к истории. Самая долгоиграющая ОС на сегодняшний день это Unix (не важно в какой инкарнации SVR или BSD).
Что мы имеем по итогу? BSD разделилась на несколько ветвей, которые становятся все менее и менее совместимы с друг другом. Но принципиального преимущества ни одна ветвь не получила. Linux, на этапе становления то же принял идеологию Unix-way, но тут же, в основном тренде стал уходить в сторону от этого самого Unix-way. Все коммерческие Unix практически почили в бозе.
И что самое интересное Unix системы даже на пике своей популярности никогда даже близко не приближалась к пиковой популярности (читай количеству инсталляций) того же Linux или Windows систем. Они всегда занимали маргинальные ниши научных исследований и инженерных систем, реже когда корпоративных вычислений.
Причины долголетия и живучести Unix уже давно разобраны и проанализированы. Стоит признать тот же Linux не соответствует этим критериям. Впрочем не факт, что на нынешнем этапе эти критерии гарантируют долголетие системы.
В общем однозначного ответа не дашь. Общая практика показывает, что все рано или поздно сходит на нет.
>Причины долголетия и живучести Unix уже давно разобраны и проанализированы. Стоит признать тот же Linux не соответствует этим критериям.можно ссылку на причины и разбор или кодовое слово для поиска ? желательно на русском бы..
Думаю это проще начать с wikipedia. Там по слову Unix, вполне вменяемая статья. А вообще была поздняя серия статей от разработчиков Томпсона и/или Ричи на эту тему. Видел в частности и переведенные на русский.
>Кстати по поводу PCC, был ведь супертурбированный и очень простой tinycc, которым
>можно было легко собрать большинство программ на С, заточенных под gcc.
>Ну и что от этого изменилось? Да ничего. Потому что для
>большинства случаев простой компилятор С никому не нужен, разве что разработчикам
>openbsd, у которых свой, особенный взгляд на мир.Для подавляющего большинства случаев именно сложный компилятор С никому не нужен.
Проблема tcc как я понимаю, в том, что он изначально ориентирован на x86 платформу. Для разработчиков ядра, это плохая идея. А разработчики приложений совершенно резонно выбрали gcc. Ведь приложения тоже должны нормально работать на всех тех платформах, которые поддерживаются ядром.
tcc поддерживает не только x86, но и x86_64, arm, CIL, и даже TMS320C67xx.
Конечно поддержка там в разной степени завершённости, но завершить её не так уж и сложно.
Да, есть один существенный косяк - полное отсутсвие глобальной оптимизации, как следствие однопроходной архитектуры tcc. Но как простой и быстрый компилятор - он таки почти эталон.
>tcc поддерживает не только x86, но и x86_64, arm, CIL, и даже
>TMS320C67xx.Но это и близко не дотягивает до набора платформ поддерживаемых gcc и которые поддерживаются ядром linux или хотя бы NetBSD.
Вот для OpenBSD, который поддерживает в основном только x86 платформы, pcc оказывается вполне себе хорош.>Конечно поддержка там в разной степени завершённости, но завершить её не так
>уж и сложно.Глобальная оптимизация при нынешних вычислительных ресурсах уже не так важна, на мой взгляд.
Основной темой на сегодняшний день являются переносимость и способность с минимальными затратами реализовать поддержку новых вычислительных платформ.Этого требует рынок и в это вкладываются деньги. Неспроста тема разного рода Virtual Machine довольно активно развивается. Идея LLVM выглядит довольно свежо в этом смысле, в сравнении с GCC.
>Неспроста тема разного рода
>Virtual Machine довольно активно развивается. Идея LLVM выглядит довольно свежо в
>этом смысле, в сравнении с GCC.gcc же умеет компилить в код для LLVM ?? http://ru.wikipedia.org/wiki/LLVM
Я имел ввиду не саму виртуальную машину, а LLVM как набор компиляторов.
Дак ведь в статье речь вроде как о языке Си идет и о том, что команда OpenBSD хотела бы иметь маленький лаконичный компилятор языке Си и ничего более, а не комбайн типа GCC. Так что пусть "ему как до Луны", ему это впринципе то и не нужно поддерживать столько языков... Типа, unix-way (Write programs that do one thing and do it well)И да, LLVM тож очень хороший кандидат, имхо конечно
Тока вот казус, сам LLVM исполюзует C++ внутри.
И чтобы в этом случае запустить PCC с бэкендом на LLVM придется установить GCC.
зачем?
Все идет к миграции от С в строну С++. Думаю, что последний аплот С скоро будет только ядро и старые утилиты. PCC с поддержкой плюсов они точно не осилят. т.ч. либо PCC делать на уровне линковки совместимым с GCC, либо в категорию народных подделок.
>Все идет к миграции от С в строну С++.О, как, а ты не мог бы уточнить, что означает "ВСЁ" в твоём посте? А то пока во многих областях даже и не пахнет миграцией с С на С++.
Все идет к миграции от C++ к связке одного из мультипарадигменных языков (Python/Ruby/Perl) и C (для критичных к скорости выполнения частях). А C++ со своим дурным синтаксисом и убогой реализацией метапрограммирования идет туда же, куда и COBOL.
С++ в том или ином виде существует уже более 20 лет. Если кто-то и хотел мигрировать, то уже давно это сделал. Есть, правда, вещи, которые с С на С++ в его полном варианте не переведешь, это касается в основном кода ядра. А вообще, что касается перспектив языка С++, то они, мягко говоря, туманны. Я зарабатываю себе на жизнь программированием на С++ более 6 лет, и мне совершенно непонятно, куда он движется.Даже в объеме стандарта 98 года он невероятно сложен и для изучения, и - что главное - для использования. Грамматика языка раздута, неоднозначна, семантика же сведет любого с ума. Нет и не предвидится единого ABI, отчего нет никакой совместимости между компиляторами на уровне скомпилированных файлов. Никаких встроенных средств поддержки параллелизма/многопоточности. Масса рудиментов, оставшихся со времен С, при этом совместимость с ним умудрились поломать. Никакой поддержки модулей/пакетов. Плохо развитый препроцессор; при этом в языке присутствуют средства метапрограммирования, которые, по идее, вкупе с поддержкой модулей могли бы свести на нет необходимость в препроцессоре, однако, они для этого слишком убогие, и препроцессор тоже убогий, но выкинуть ни то, ни другое нельзя. Недостаточно продуманная поддержка объектно-ориентированной парадигмы - например, нет явной поддержки интерфейсов, зато есть множественное наследование и, как следствие, diamond problem с костылем в виде виртуального наследования. Шаблоны реализованы криво и не имеют семантики самого языка; частично решить проблему с ними пытались через введение в стандарт C++0x концептов (concepts), но в конечном итоге их отклонили. Сам стандарт, кстати, та еще хреновина - когда он наконец выйдет со всеми своими нововведениями типа лямбда-функций и Rvalue-ссылок, то мало не покажется никому. С++ станет ( если еще не стал ) настолько сложным, что perl покажется просто образцом языка, побуждающего к лаконичности и ясности. Да что тут говорить, большинству людей понадобится не один и не два года кропотливого изучения языка, штудирования Страуструпа, Мейерса, Саттера, Александреску, стандартов, чтобы начать писать на нем что-либо дельное. В современных условиях при нынешней динамике развития ИТ это очень большой срок. Проводить столько времени, изучая далеко не идеальный инструмент для решения проблем, вместо того, чтобы собственно решать сами проблемы, не всякий себе может позволить.
Ну что вы. Зачем это. Скоро же всё, стараниями Мигеля, будет на Mono.
>C Compiler), последние улучшения в котором позволили осуществить полный цикл сборки
>загрузочного ядра OpenBSD для архитектуры x86, а также большинства утилит и
>библиотек базового окружения. Поддержка сборки для платформы AMD64 в настоящий момент
>находится в состоянии активной разработки и будет доведена до рабочего состояния
>в ближайшее время.
>Задача: Нуно легковесный, компактный с-компилятор для сборки *BSD-системы, которая написана на с. В системный комплект. И все.
Дебиан-шнобиан, генту-швенту - это сбоку припека.
Развели базар, целую философию мирообразования... :)
Ну довели и довели! Толку-то... Си умер лет 15 назад, но "никто не заметил запаха и праздник продолжался". Сборщик мусора, развитая рантайм-инфа, обобщённое программирование, ООП, приколы из ФЯ - всё это громадой навалилось на современных прогеров и писать на атавизме типа Си - это заранее хоронить проект.
Было бы здорово, если бы учёные мужи уделили внимания языку D. Он внешне похож на Си, чем вызывает зевоту у ламеров, типа "ещё один клон". Однако, даже беглый взгляд по фичам Ди вызывает удивление (или того хуже: "А что это за фича?") у бывалых прогеров.
Конечно, переписать позорное поделие Торвальдса вряд ли смогут даже тысячи опенсорсников, но заменять прикладные свистелки уже вполне можно - пусть не используя всей мощности Ди, но хотя бы портируя в компилябельный вариант. Это даст и практику, и улетучатся такие раздражающие приколы Сей а-ля "null pointer" или "stack execution".
>Ну довели и довели! Толку-то... Си умер лет 15 назадРазработчикам ядер ОС, драйверов и т.п. расскажи, а то пишут бедняги на нем
Все эти ООП, сборщик мусора и т.д. миф, созданный компилятором. Можно написать класс с наследованием, получающий доступ к закрытым членам-методам другого класса на Си, просто писать это дольше, чем на С++
> Это даст и практику, и улетучатся такие раздражающие приколы Сей а-ля "null pointer" или "stack execution".
Дак писать надо грамотно, а не надеяться на то, что часть работы за тебя язык сделает
> Дак писать надо грамотно, а не надеяться на то, что часть работы за тебя язык сделаетВы конечно правы, но боюсь упускаете что нет еще ни одного человека который бы писал без ашипак
потому и стремятся создавать инструменты, работая с которыми, минимизировать возможность их(ошибок) возникновения.