Представлена (http://marc.info/?l=pcc-list&m=129831652629682&w=2) бета версия будущего первого стабильного релиза (http://pcc.ludd.ltu.se/1.0_release/) компилятора PCC (http://pcc.ludd.ltu.se/) (Portable C Compiler), развиваемого с целью создания распространяемой под лицензий BSD альтернативы Си-компилятора из состава GCC. По заявлению разработчиков в представленном
бета-выпуске (ftp://pcc.ludd.ltu.se/pub/pcc-beta/) устранены все серьезные ошибки, которые ранее мешали подготовке первого релиза. Версия PCC 1.0 будет полноценно поддерживать архитектуры i386 и amd64, для остальных архитектур функциональность пока ограничена. Компилятор уже можно использовать для переборки FreeBSD, NetBSD и OpenBSD.
PCC распространяется в рамках лицензии BSD и нацелен на создание полноценного компилятора для языка Си, полностью совместимого со стандартом C99 и частично совместимого с GCC. PCC является в значительной степени переработанным вариантом компилятора Portable C Compiler, разработанного S....URL: http://marc.info/?l=pcc-list&m=129831652629682&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=29701
какой смысл сравнивать с gcc 4.1.3?
следующие релизы gcc перешли на GPLv3.
> следующие релизы gcc перешли на GPLv3.Не угадал, вторая попытка.
"GCC 4.2.1 will be the last release of GCC covered by version 2 of the GNU General Public License. All future releases will be released under GPL version 3."
он идёт по умолчанию в последнем релизе netbsd?
> какой смысл сравнивать с gcc 4.1.3?а вдруг при сравнении с gcc поновей всё будет не так радужно, как получилось? они бы и второй gcc взяли, думаю, но это совсем палевно будет.
Дайте угадаю, финансируют этот проект несколько крупных проприетарных вендоров, которым невыгодно развитие gcc?
И в чём же профит? Назло маме отморожу уши, что-ли?
А теперь внимание вопрос: как появление нового компилятора помешает развиваться GCC?
Надеюсь, они напишут ещё и для C++ компилятор.
а что в операционных систамах *bsd написано на c++?
А что, этот компилятор предназначен для компилирования исключительно дистрибутивов BSD-систем?
Qt, GTK+, KDE, GNOME, в общем, в основном, то же, что и в Linux
GTK+ на цпп? O_O
> GTK+ на цпп? O_Oслучайно зацепил
> Надеюсь, они напишут ещё и для C++ компилятор.зачем? O_O
Так а в чем профит в PCC для *BSD, если есть clang?
как и во всем остальном опенсорсе - изобрести свой велосипед.
(зеваю) Не совсем точно. Точнее - изобрести свой собственный способ, один из тысячи - дрочить вприсядку.
Ребятки, ну не нравится вам этот опенсорс, пользуйтесь вендой и пирацким софтом, ё-моё. И go to на соответствующие форумы.
портабельность и поддерживаемые архитектуры
> полноценно поддерживать архитектуры i386 и amd64, для остальных архитектур функциональность пока ограниченаПока что Portable только в названии.
> Пока что Portable только в названии.хм. нет. portable — в архитектуре. в простоте портирования. ты когда-нибудь в кишки gcc лазил? если нет — сходи. а потом сходи в кишки pcc. я даже ничего резюмировать не буду, сам всё увидишь.
для непонятливых: я не к тому, что gcc непортабельный. я про порог вхождения и про архитектурную основу pcc.
Хм, да я не сомневаюсь, что PCC портируют на большинство платформ, поддерживаемых NetBSD, как только разработчики получат полноценный доступ к аппаратуре. Но пока что эта возможность потенциальная.Кстати, не исключено, что при портировании на какие-то очень экзотические архитектуры (типа Креев) PCC столкнётся с необходимостью переписать все кишки и приблизиться по сложности к gcc. Но до этого вряд ли дойдёт.
> Кстати, не исключено, что при портировании на какие-то очень экзотические архитектуры (типа
> Креев) PCC столкнётся с необходимостью переписать все кишки и приблизиться по
> сложности к gcc. Но до этого вряд ли дойдёт.думаю, вряд ли. пцц же не точат на супероптимальный код. так что какие-то там спецоптимизации под конкретные процы просто пошлют лесом, и всё.
Портабельны все свободные компиляторы. А поддержка архитектур у PCC нулевая. Плюс отсутствие C++. Не знаю зачем это поделие может понадобится.
> Портабельны все свободные компиляторы.у меня есть компилятор MyKoolLanguage. он свободный. вот только все внутренности заточены на i386. хорошо заточены. «портирование» его будет равносильно переписыванию почти с нуля. итого: твоё утверждение — ложь. зачем ты прилюдно лжёшь?
> Плюс отсутствие C++. Не знаю зачем это поделие может понадобится.согласен: тоже никак не могу понять, на кой этот цпп нужен.
Главный профит в том, что это заставит и clang, и gcc шевелиться ещё быстрее.Ну и на какую-нибудь экзотическую архитектуру возможно успеют спортировать раньше.
> Так а в чем профит в PCC для *BSD, если есть clang?Наверное фокус в том что шланг развивается эпплом. И разработчики все в эппле. А эппл как-то так хотел на проблемы бздунов и всех остальных вместе взятых класть с прибором. Если посмотреть на направление развития - видно что первым делом шланг пилится под макось. Что как бы чертовски логично, но совершенно бесполезно всем кто не эппл...
Clang уже может откомпилировать WebKit?
Ну здасте, как раз для сборки FreeBSD его пилили очень активно. А gcc-шники как раз ложили с прибором, начиная с перехода на GPL3.
более того: гццшникам вообще пробор — затачивать компилятор для сборки конкретной системы. а то, что бздоиды не в состоянии использовать софт под GPLv3 — это интимные проблемы бздоидов. гпльщики BSDL-софт отлично используют, если надо, и не напрягаются.
PCC маленький. Поддерживать легче.
>PCC маленький. Поддерживать легче.Поддерживать легче то, в чем хорошо разбирается большее количество людей. По соотношению ("размер community" / "размер компилятора") gcc пока "зарулит" кого угодно.
>>PCC маленький. Поддерживать легче.
> Поддерживать легче то, в чем хорошо разбирается большее количество людей. По соотношению
> ("размер community" / "размер компилятора") gcc пока "зарулит" кого угодно.А в кишки gcc посмотреть, ы? У gcc большой размер community _пользователей_, но не разработчиков.
>У gcc большой размер community _пользователей_, но не разработчиков.Этот тезис особенно ярко "подтверждает" перечень поддерживаемых платформ и ОС (и это еще не считая поддержку различных языков программирования и кучи вариантов стандартов на них). Конечно для таких тривиальных вещей вовсе не надо чтобы туева хуча людей хорошо разбиралась "в потрохах".
Явное нарушение элементарной логики получается. С одной стороны (слова разных людей): "gcc спроектирован и написан самым ужасным образом", "GPL самая хреновая в мире лицензия", "У gcc большой размер community _пользователей_, но не разработчиков" и т. п. С другой строны (факты): самый большой перечень поддерживаемых платформ и ОС, самый большой перечень поддерживаемых языков и их стандартов/диалектов, быстрей чем у всех появляется поддержка новой платформы (кроме, может, компилера производителя самой платформы), и т. п. Что в итоге? Переть против фактов? Нет. По ходу, слова не совсем соответствуют действительности! А почему? Потому что больше половины говорящих такое, просто повторяют чужие слова (не думаю, что больше 20% людей говорящих про кошмарный дизайн и реализацию gcc реально смотрели/разбирались в его внутренностях).
>>У gcc большой размер community _пользователей_, но не разработчиков.
> Этот тезис особенно ярко "подтверждает" перечень поддерживаемых платформ и ОС (и это
> еще не считая поддержку различных языков программирования и кучи вариантов стандартов
> на них). Конечно для таких тривиальных вещей вовсе не надо чтобы
> туева хуча людей хорошо разбиралась "в потрохах".Конечно не надо, за 20 лет истории-то. Да и за эти годы, что имеем?
freebsd72:/usr/src/contrib$ du -hd 1 gcc*
52M gcc
5,7M gcclibsПри этом полное дерево /usr/src весит 500 метров, а /usr/ports более 600, и со всем этим хозяйством управляются
$ fetch -o - http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contribu... | grep -i @freebsd.org | sort -u | wc -l
446человек. У поддерживающей кучу платформ NetBSD - и того меньше. Вы правда думаете, что несколько десятков активных разработчиков и сотня-другая контрибуторов - это "большой размер community" ?
> Явное нарушение элементарной логики получается.
Говоря о нарушении логики, следует приводить логические цепочки/выражения, которые неверны.
> С одной стороны (слова разных людей): "gcc
> спроектирован и написан самым ужасным образом", "GPL самая хреновая в мире
> лицензия", "У gcc большой размер community _пользователей_, но не разработчиков" и
> т. п. С другой строны (факты): самый большой перечень поддерживаемых платформ
> и ОС,
> быстрей чем у всех появляется поддержка новой платформы (кроме,
> может, компилера производителя самой платформы), и т. п.Вы поройтесь на форуме, ембедщики жаловались на то, какой скверный код делает gcc для ряда архитектур. Из чего можно сделать вывод, что нормально майнтейнятся только некоторые из платформ.
> самый большой перечень поддерживаемых языков и их стандартов/диалектов,
Лолшто? Среди кого? Поддерживаемые gcc языки - капля в море.
> Что в итоге? Переть против фактов?
> Нет. По ходу, слова не совсем соответствуют действительности! А почему?Да, приведенные Вами слова не совсем соответствуют действительности. А почему? Потому что очень выборочно из неё выбирают факты. Особенно насмешило "и куча вариантов стандартов на них" - будто бы там неиллюзорно большие отличия.
>Вы поройтесь на форуме, ембедщики жаловались на то, какой скверный код делает gcc для ряда архитектур. Из чего можно сделать вывод, что нормально майнтейнятся только некоторые из платформ.Мне для этого не надо рыться на форумах. Вполне естественно, что одни платформы майнтейнятся лучше чем другие, на это очень много очевидных причин. Вы лучше поспрашивайте ембедщиков, пишуших для платформ, не поддерживаемых gcc совсем. Ключевые моменты: "сколько стоит копать такую платформу (после истечения trial-версий средств разработки)", "насколько портабельным получается код (точнее, сколько дополнительных усилий надо затратить чтоб код был хоть сколько-нибудь портабельным)" и следствие "как много информации можно найти в интернете о всяких тонкостях и особенностях платформы и разработки под нее".
>> самый большой перечень поддерживаемых языков и их стандартов/диалектов,
>Лолшто? Среди кого? Поддерживаемые gcc языки - капля в море.Из существующих в мире языков - конечно. Но! Прямо здесь и сейчас покажите продукт поддерживающий большее их количество.
>Особенно насмешило "и куча вариантов стандартов на них" - будто бы там неиллюзорно большие отличия.
Какие бы они ни были "иллюзорные", но факт в том, что gcc их поддерживает, а другие, чаще всего, нет.
>>Вы поройтесь на форуме, ембедщики жаловались на то, какой скверный код делает gcc для ряда архитектур. Из чего можно сделать вывод, что нормально майнтейнятся только некоторые из платформ.
> Мне для этого не надо рыться на форумах. Вполне естественно, что одни
> платформы майнтейнятся лучше чем другие, на это очень много очевидных причин.
> Вы лучше поспрашивайте ембедщиков, пишуших для платформ, не поддерживаемых gcc совсем.
> Ключевые моменты: "сколько стоит копать такую платформу (после истечения trial-версийКопать от нефиг делать или работу работать? Во втором случае зарабатываются деньги, и такой вопрос не стоит, если платформа показала свои преимущества.
> средств разработки)", "насколько портабельным получается код (точнее, сколько дополнительных
> усилий надо затратить чтоб код был хоть сколько-нибудь портабельным)" иЧего-чего? Портабельность в емебдщине? Кода , принципиально точимого под определенную платформу? Бред какой.
>>> самый большой перечень поддерживаемых языков и их стандартов/диалектов,
>>Лолшто? Среди кого? Поддерживаемые gcc языки - капля в море.
> Из существующих в мире языков - конечно. Но! Прямо здесь и сейчас
> покажите продукт поддерживающий большее их количество.А зачем? Чтоб каждый из компонентов поддерживался так же хреново, как и те платформы? Вот буквально сегодня притащили задачу, которую не осиливал gfortran. Пришлось интеловский компилятор фортрана использовать. И это при том, что язык один из основных и старейших в gcc.
>>Особенно насмешило "и куча вариантов стандартов на них" - будто бы там неиллюзорно большие отличия.
> Какие бы они ни были "иллюзорные", но факт в том, что gcc
> их поддерживает, а другие, чаще всего, нет....особенно Fortran 2003 и 2008, ну-ну. А если брать, скажем, C89 vs C99 - отличия невелики, чего их особенно там имплементить.
В общем, детектирую очень избирательное отношение к фактам и их интерпретации, а также некомпетентность в соответствующих темах. Настоятельно рекомендую не заикаться при этом о логике.
>Копать от нефиг делать или работу работать? Во втором случае зарабатываются деньги, и такой вопрос не стоит, если платформа показала свои преимущества.Если под "от нефиг делать" подразумевается "безо всякой цели", то вы видимо не очень представляете себе что такое "раскопать" новую платформу.
Чтоб узнать преимущества (а что гораздо важнее - недостатки) платформы недостаточно прочитать пресс-релиз. Или вы собрались сразу "работу работать" на ни разу не пробованной платформе? А пока платформа не исследована и/или на ней ничего не сделано, то деньги еще не зарабатываются и вопросов море. Попробуйте, смеху ради, объяснить своему начальнику, что надо срочно начинать юзать платформу Y вместо используемой платформы X только потому, что вы прочитали что она чем-то лучше.[начал что-то подозревать]
>Чего-чего? Портабельность в емебдщине? Кода , принципиально точимого под определенную платформу? Бред какой.
Все. После этого заканчиваем разговор. Вы говорите о вещах, о которых не имеете представления. Удачи.
>>Копать от нефиг делать или работу работать? Во втором случае зарабатываются деньги, и такой вопрос не стоит, если платформа показала свои преимущества.
> Если под "от нефиг делать" подразумевается "безо всякой цели", то вы видимо
> не очень представляете себе что такое "раскопать" новую платформу.
> Чтоб узнать преимущества (а что гораздо важнее - недостатки) платформы недостаточно прочитать
> пресс-релиз. Или вы собрались сразу "работу работать" на ни разу не
> пробованной платформе? А пока платформа не исследована и/или на ней ничегоА подумать над тем, что я написал? "Если показала" - т.е. период опробования пройден. Тот самый trial, например.
> не сделано, то деньги еще не зарабатываются и вопросов море. Попробуйте,
> смеху ради, объяснить своему начальнику, что надо срочно начинать юзать платформу
> Y вместо используемой платформы X только потому, что вы прочитали что
> она чем-то лучше.
> [начал что-то подозревать]Пора начать подозревать что-нибудь в себе, прежде чем начинать объяснять не просто давно известные собеседнику вещи, но те, на которые он в предыдущем сообщении явно сослался.
>>Чего-чего? Портабельность в емебдщине? Кода , принципиально точимого под определенную платформу? Бред какой.
> Все. После этого заканчиваем разговор. Вы говорите о вещах, о которых не
> имеете представления. Удачи.Я уже видел, что у Вас проблемы с интерпретацией не только общеизвестных фактов, но и игнорирование "неудобных" вопросов - достаточно посмотреть выше по треду, сколько цитат Вами пропущено. При такой страусиной политике я уже не удивлюсь, если мои слова опять были поняты как нечто несусветное. Действительно, продолжать разговор при таких проблемах с восприятием нет смысла.
>Я уже видел, что у Вас проблемы с интерпретацией не только общеизвестных фактов, но и игнорирование "неудобных" вопросов - достаточно посмотреть выше по треду, сколько цитат Вами пропущено.Я не настолько хорошо владею вопросами, например, относительно NetBSD и фортрана, поэтому вполне допускаю что вы в этом разбираетесь лучше меня, а, значит, если начну оспаривать ваши слова то это будут не аргументы, а лишь пустое "брызганье слюной". Зачем?
А вот по вашим словам ясно, что с embedded вы знакомы на уровне "общеизвестных фактов", ну и, собственно, о чем может быть спор?
Мы, похоже, в разных областях "обитаем". Сильно разных. То что важно для вас мне либо непонятно либо совершенно не важно и точно также наоборот. Отсюда и слова насчет заканчивать разговор. С вашей стороны, мне почему-то кажется, что разговор приблизился к личным оскорблениям, а у меня нет желания продолжать в таком духе.
>[оверквотинг удален]
> вполне допускаю что вы в этом разбираетесь лучше меня, а, значит,
> если начну оспаривать ваши слова то это будут не аргументы, а
> лишь пустое "брызганье слюной". Зачем?
> А вот по вашим словам ясно, что с embedded вы знакомы на
> уровне "общеизвестных фактов", ну и, собственно, о чем может быть спор?
> Мы, похоже, в разных областях "обитаем". Сильно разных. То что важно для
> вас мне либо непонятно либо совершенно не важно и точно также
> наоборот. Отсюда и слова насчет заканчивать разговор. С вашей стороны, мне
> почему-то кажется, что разговор приблизился к личным оскорблениям, а у меня
> нет желания продолжать в таком духе.Видите ли, вопросы лицензий и затрат на освоение/обучение - они общие, не зависят от области. Более того, они общие для самых разных профессий, не только IT. Это типичная организационно-управленческая задача - как выяснить, какое средство для решения задачи лучше, при том, что само выяснение требует усилий. Т.е. средств, которые должны окупиться в будущем. И их давно научились решать, в сугубо материальных сферах (подумайте, например, о летчиках). В IT ничего принципиально нового не появилось.
Подчеркиваю, именно какое _для решения задачи_ *лучше*. А не то, какие религиозные предпочтения в выборе средств у исполнителя. Подбирается то, что при заданных условиях будет решать задачу заказчика при устраивающих его затратах (если что, корректируется).
Вы же пользуетесь первой же возможностью свернуть с общей/обсуждаемой темы, прикрываясь слабой осведомленностью собеседника в не особенно-то релевантной частной области. Это, мягко говоря, некорректно. Да и в той - не особенно-то потрудились уточнить. что имелось в виду. Портабельность _чего_? Какая? Между архитектурами? Между компиляторами? etc.
Очевидно же, что код, предназначенный для управления конкретной внешней железкой и использования её уникальных фич, не может быть никуда портирован - аналогов не существует, это бессмысленно.
>Видите ли, вопросы лицензий и затрат на освоение/обучение - они общие, не зависят от области. Более того, они общие для самых разных профессий, не только IT. Это типичная организационно-управленческая задача - как выяснить, какое средство для решения задачи лучше, при том, что само выяснение требует усилий. Т.е. средств, которые должны окупиться в будущем. И их давно научились решать, в сугубо материальных сферах (подумайте, например, о летчиках). В IT ничего принципиально нового не появилось.На это можно очень много чего сказать. Много общих (и в основном правильных) слов. Рассмотрим маленький, чуть более узкий пример из жизни (моей в данном случае). Извиняйте, но конкретных названий не будет в силу NDA, да и ситуация повторялась уже не раз. Есть руководители "верхнего звена" (извините за избитый термин). Они принимают решение о вложении средств (денег, людей, времени) в новую платформу, включая и затраты на освоение и т. п. Но, во-первых, кто-то должен внести предложение начать использовать эту новую платформу, причем не просто сказать, а расписать все плюсы и минусы, оценку затрат, примерный расклад по времени и людям, показать прототипы и т. д. Кто это должен сделать? Правильно, технический специалист, например, я. И вот я, зная текущие задачи, оцениваю возможности используемой сейчас платформы применительно к задачам будущим (как к вполне реальным ближайшим, так и к прогнозируемым в дальнейшем) и прихожу к выводу, что текущая платформа не подходит. Сейчас-то она, вроде как, устраивает, и даже, поднапрягшись, ближайшие тоже можно сделать, но на большее она уже не тянет (А еще бывает, что просто микросхемы снимают с производства). Для "верхнего" руководства еще нет оснований что-то куда-то вкладывать (текущие задачи решаются, ближайшие тоже "закрыты"), а мои выкладки про проблемы в будущем это, конечно, серьезно, но от меня ждут не просто "обозначить проблему", а предложить конкретные решения (которые мне же и реализовывать и за которые мне же и отвечать). И вот я прикидываю будущую платформу (а это как бы не только тип процессора), а дальше? Дальше мне надо с ней разобраться и создать заготовки и черновики того, что станет потом "фреймворком" на котором мы будем делать новые разработки (ОС, библиотеки, загрузчики, утилиты и т. п.), причем, пока прототип этого "фреймворка" не будет реальным, а не умозрительным (а это значит, что все это надо реально написать/портировать/попробовать) ни о каком выходе с предложением новой платформы речи быть не может. На данном этапе я могу "выбить" денег, максимум, на покупку пары evaluation-kit'ов и на изготовление нескольких макетов. Второй момент в том, что текущие задачи никто не отменял, а, значит, времени на все это у меня особо нет. Я могу поручить разбираться кому-нибудь из студентов или молодых специалистов, но это как послать паренька из дворовой команды играть в высшей лиге. Выводы очень простые: на этот первый (и самый ответственный) этап мне нужны средства разработки, во-первых, максимально малобюджетные (потом, когда будет о чем говорить, можно будет и средства разработки за несколько десятков килобаксов поиметь и все остальное), а, во-вторых, максимально знакомые мне и, возможно, моей команде (минимизация затрачиваемого, неоплачиваемого по сути, времени). Этим условиям обычно удовлетворяет gcc. И на этом этапе это задачи уровня ведущего, а не "организационно-управленческие". Я могу, конечно, выбить денег и на "крутой компилятор" (по сути, под мой опыт), но дать 100% гарантию, что то, что я хочу поисследовать всех устроит (и за это время никто из моих коллег не предложит ничего еще лучшего) я не могу. Еще очень важный момент - с учетом моей текущей загрузки и неизвестных "граблях" в будущем я не могу точно прогнозировать сроки, через которые будет результат (опыт говорит о том, что даже опыт может не помочь), а, если "вложены деньги", то и спрос уже совершенно другой. А еще, в процессе исследований я же сам могу рассматриваемое и "закопать" по разным причинам (и так уже бывало), а "отсутствие результата - тоже результат" не совсем то, что ждут люди вложившие деньги. Чем кончаются многократно повторяющиеся ситуации типа "Акелла промахнулся" у классика расписаны довольно наглядно (а с gcc или чем-то еще, что не требует 20000$ чтоб только начать, я могу "промахиваться" сколько угодно, об этом и узнают-то только самые близкие).
>Подчеркиваю, именно какое _для решения задачи_ *лучше*. А не то, какие религиозные предпочтения в выборе средств у исполнителя. Подбирается то, что при заданных условиях будет решать задачу заказчика при устраивающих его затратах (если что, корректируется).
Надеюсь, с учетом вышесказанного, видно, что пока речь ни про какие "религиозные" предпочтения не идет. До решения конкретных задач заказчика также еще очень далеко (идет "раскапывание" платформы, при помощи которой ПОТОМ эти задачи будут решаться). Заказчику, чаще всего, вообще глубоко пофиг какая у тебя там платформа и сколько денег/времени/сил тебе надо на ее освоение/внедрение/доведение по ума. Затраты здесь напрямую никаким заказчиком не оплачиваются, это вложения, которые позволят в будущем решать задачи заказчиков при минимуме затрат исполнителей.
На возможные возражения по поводу "я ему про решение задач, а он мне про платформу" замечу, что в embedded особенно остро стоят задачи унификации, повторного использования и т. п., поэтому разработка новой платформы, это, по сути, разработка средства для решения многих задач (включая гипотетические будущие). Мало кто пойдет на разработку "с нуля" каждой новой задачи - слишком дорого. И тут мы плавно подходим к вопросам портабельности. Очевидно, что чем больше прошлых наработок можно использовать в следующих - тем лучше (и по затратам и по стабильности и по... да по всему лучше). Надеюсь, очевидно, что при использовании одного и того же компилятора под разные платформы, проблем с портабельностью кода будет существенно меньше?А теперь развенчаю главный миф:
>Очевидно же, что код, предназначенный для управления конкретной внешней железкой и использования её уникальных фич, не может быть никуда портирован - аналогов не существует, это бессмысленно.Ответ здесь - нет! Ни разу не очевидно! Если я меняю, к примеру, тип процессора, то это вовсе не значит, что я не могу подключить ту же самую "конкретную внешнюю железку" по максимально похожей схеме и продолжать использовать ее "уникальный фичи" под управлением уже новой системы. При этом интерфейс с ней (логический, а зачастую и физический) остаются тем же, решаемые задачи такие же или сходные. Так по какой причине я должен заново писать весь код для работы с ней (если, конечно он не был на 100% написан на асме)? Аналогов в мире, может и не существовать, но для меня-то эта задача - та же самая и периферийное железо тоже самое! Более того, именно такая ситуация наиболее распространена! Если разработана новая платформа, то новые варианты исполнения СТАРОГО железа стараются сделать уже на ней (чтоб меньше тратить на поддержку старой платформы), по максимуму используя уже отработанную схемотехнику и математику от старого. И это охрененный минус новой платформы (и новых средств разработки, даже если они сами по себе прям "конфетка") если там нужно много усилий для портирования/переписывания старого.
Кстати, некоторые производители процессоров и средств разработки под них прекрасно знают про возможности gcc (и насколько он распространен и известен) и делают в своих компиляторах опции и расширения максимально совместимые с gcc (причем даже делают целые разделы в описаниях про схожести и отличия с gcc). Приятно, когда производители думают о разработчиках (это экономит довольно много времени при освоении).
P.S.:
>Вы же пользуетесь первой же возможностью свернуть с общей/обсуждаемой темы, прикрываясь слабой осведомленностью собеседника в не особенно-то релевантной частной области. Это, мягко говоря, некорректно.Если эта область не релевантна (по вашему мнению) и вы в ней некомпетентны, то некорректно как раз пытаться упорствовать именно в этой области.
P.P.S:
> И их давно научились решать, в сугубо материальных сферах (подумайте, например, о летчиках).Про летчиков - не понял.
P.P.P.S: Если вы дочитали досюда (многа букаф все-таки получилось) и считаете что я опять "ушел от темы", что все это не имеет никакого отношения к вашему тексту и обсуждаемому вопросу, пожалуйста, не надо мне об этом писать. Сэкономим время друг друга.
>>Видите ли, вопросы лицензий и затрат на освоение/обучение - они общие, не зависят от области. Более того, они общие для самых разных профессий, не только IT. Это типичная организационно-управленческая задача - как выяснить, какое средство для решения задачи лучше, при том, что само выяснение требует усилий. Т.е. средств, которые должны окупиться в будущем. И их давно научились решать, в сугубо материальных сферах (подумайте, например, о летчиках). В IT ничего принципиально нового не появилось.[...]
> и т. п. Но, во-первых, кто-то должен внести предложение начать использовать
> эту новую платформу, причем не просто сказать, а расписать все плюсы
> и минусы, оценку затрат, примерный расклад по времени и людям, показать
> прототипы и т. д. Кто это должен сделать? Правильно, технический специалист,
> например, я. И вот я, зная текущие задачи, оцениваю возможности[...]
> конечно, серьезно, но от меня ждут не просто "обозначить проблему", а
> предложить конкретные решения (которые мне же и реализовывать и за которые
> мне же и отвечать).[...]
> Второй момент в том, что текущие задачи никто не отменял, а,
> значит, времени на все это у меня особо нет. Я могу[...]
> (по сути, под мой опыт), но дать 100% гарантию, что то,
> что я хочу поисследовать всех устроит (и за это время никто
> из моих коллег не предложит ничего еще лучшего) я не могу.[...]
> и "закопать" по разным причинам (и так уже бывало), а "отсутствие
> результата - тоже результат" не совсем то, что ждут люди вложившие
> деньги. Чем кончаются многократно повторяющиеся ситуации типа "Акелла промахнулся" у классика
> расписаны довольно наглядно (а с gcc или чем-то еще, что не
> требует 20000$ чтоб только начать, я могу "промахиваться" сколько угодно, об
> этом и узнают-то только самые близкие)."Возражение" ясное, но, на самом деле, так _не должно быть_. В нормальных конторах на Западе для этого существует отдел R&D. В советское время с такими целями проводились НИОКР. И только в современной России забивают на науку и делают вот так вот через жопу, возлагая исследовательские задачи на инженеров-эксплуатационщиков. Нет, именно что "отсутствие результата - тоже опыт", и нормальный руководитель верхнего звена прекрасно это понимает, вовсе не относя это к "Акелла промахнулся" (а почему, собсно, не Эдисон, у которого была куча неудачных проб?..)
>>Подчеркиваю, именно какое _для решения задачи_ *лучше*. А не то, какие религиозные предпочтения в выборе средств у исполнителя. Подбирается то, что при заданных условиях будет решать задачу заказчика при устраивающих его затратах (если что, корректируется).
> Надеюсь, с учетом вышесказанного, видно, что пока речь ни про какие "религиозные"
> предпочтения не идет.Ну да, речь идет о нищете, вынуждающей искать халявные решения. Вот только следует иметь честность сказать, что это от нищеты и неверной организации труда в масштабе конторы, а не что gcc и его лицензия такие все из себя замечательные.
> До решения конкретных задач заказчика также еще очень
> далеко (идет "раскапывание" платформы, при помощи которой ПОТОМ эти задачи будут
> решаться). Заказчику, чаще всего, вообще глубоко пофиг какая у тебя там
> платформа и сколько денег/времени/сил тебе надо на ее освоение/внедрение/доведение по
> ума. Затраты здесь напрямую никаким заказчиком не оплачиваются, это вложения, которые
> позволят в будущем решать задачи заказчиков при минимуме затрат исполнителей.Это всё общее место.
> На возможные возражения по поводу "я ему про решение задач, а он
> мне про платформу" замечу, что в embedded особенно остро стоят задачи
> унификации, повторного использования и т. п., поэтому разработка новой платформы, это,
> по сути, разработка средства для решения многих задач (включая гипотетические будущие).
> Мало кто пойдет на разработку "с нуля" каждой новой задачи -
> слишком дорого. И тут мы плавно подходим к вопросам портабельности. Очевидно,
> что чем больше прошлых наработок можно использовать в следующих - тем
> лучше (и по затратам и по стабильности и по... да по
> всему лучше). Надеюсь, очевидно, что при использовании одного и того же
> компилятора под разные платформы, проблем с портабельностью кода будет существенно меньше?Процент code reuse в целом по индустрии не так уж и велик, на самом деле. Серебряной пули нет.
>[оверквотинг удален]
> примеру, тип процессора, то это вовсе не значит, что я не
> могу подключить ту же самую "конкретную внешнюю железку" по максимально похожей
> схеме и продолжать использовать ее "уникальный фичи" под управлением уже новой
> системы. При этом интерфейс с ней (логический, а зачастую и физический)
> остаются тем же, решаемые задачи такие же или сходные. Так по
> какой причине я должен заново писать весь код для работы с
> ней (если, конечно он не был на 100% написан на асме)?
> Аналогов в мире, может и не существовать, но для меня-то эта
> задача - та же самая и периферийное железо тоже самое! Более
> того, именно такая ситуация наиболее распространена!Ну, если именно такая ситуация сейчас стала наиболее распространена, тогда да.
> Если разработана новая платформа,
> то новые варианты исполнения СТАРОГО железа стараются сделать уже на ней
> (чтоб меньше тратить на поддержку старой платформы), по максимуму используя уже
> отработанную схемотехнику и математику от старого. И это охрененный минус новой
> платформы (и новых средств разработки, даже если они сами по себе
> прям "конфетка") если там нужно много усилий для портирования/переписывания старого.Это тоже общее место (хотя, правда, уже для меньшего количества народу).
> Кстати, некоторые производители процессоров и средств разработки под них прекрасно знают
> про возможности gcc (и насколько он распространен и известен) и делают
> в своих компиляторах опции и расширения максимально совместимые с gcc (причем
> даже делают целые разделы в описаниях про схожести и отличия с
> gcc). Приятно, когда производители думают о разработчиках (это экономит довольно много
> времени при освоении).Это тот же самый вопрос портирования/переписывания, только на этот раз - головы/опыта разработчика. Вот только компилятор при этом всё же другой, а не gcc :)
> P.S.:
>>Вы же пользуетесь первой же возможностью свернуть с общей/обсуждаемой темы, прикрываясь слабой осведомленностью собеседника в не особенно-то релевантной частной области. Это, мягко говоря, некорректно.
> Если эта область не релевантна (по вашему мнению) и вы в ней
> некомпетентны, то некорректно как раз пытаться упорствовать именно в этой области.Это не "я упорствую", а Вы из всех цитат оставили только одну подобласть, вот и создается такое впечатление.
> P.P.S:
>> И их давно научились решать, в сугубо материальных сферах (подумайте, например, о летчиках).
> Про летчиков - не понял.Ну, понадобилось, чтоб летал на другом типе самолета - надо отправить на курсы переподготовки, аттестовать и т.д. затраты вложить. Даже если самолеты похожи. Можно было бы и из других областей примеры взять, такое ведь много где, просто первое что пришло в голову.
О сравнении с gcc писать, мягко говоря, преждевременно. Во-первых, использовано всего 7 микротестов из ByteBench, а не полный комплект (и в 2 из 7 gcc уделывает pcc в 1.5-2 раза). Во-вторых, тесты проведены всего для одной архитектуры (не указано на какой, но судя по всему, это i386). В-третьих, по времени сборки gcc отстаёт менее, чем вдвое (судя по следующей серии тестов), "в несколько раз" -- выражение, вводящее в заблуждение.Вот когда будет проведены полные серии нескольких специализированных тестов, а также сборка больших реальных приложений (от числодробилок и компиляторов до серверов и драйверов) для всех поддерживаемых архитектур, вот тогда можно будет смотреть и сравнивать. Для gcc следует также сравнить с флагом -O1 (ради скорости сборки) и с заточкой под более современные процессоры, чем Intel 80386.
Очень хорошо, больше компиляторов, хороших и разных. Глядишь, все и начнут писать по стандарту, без костылей под конкретный компилятор.
Лучше уж доработать стандарт. В С99 фигни какой-то надобавляли, неслучайно его не очень рвутся реализовывать, M$ & IBM вообще, по-моему, проигнорировали... Я когда глянул GNU-расширения C, так и разинул варежку - их-то мне и не хватало всю жизнь
потому что стандарты пишут сферические комитеты в вакууме. а gcc пилят люди, которым потом на нём софт писать. и поэтому люди добавляют то, что просто напрашивается, но сквозь сферический комитет не проходит.конечно, vendor lock-in, но мой софт не под gcc, например, не соберётся. именно потому, что ради абстрактной «переносимости между компиляторами» я не собираюсь отказываться от вкусных расширений gcc или пересыпать код уродливыми ифдефами.
Для GNU-расширений (хотя и не для всех) можно реализовать препроцессор, выплевывающий абсолютно удовлетворяющий стандарту сорц. Проблема тут как бы вообще отпадает )
а можно и сразу нативный код, да. но, например, для nested functions или compounds результирующий код будет ужосом. а для typeof так и вообще придётся полный фронтэнд делать, и все исходники проекта препроцессить.по количеству требуемых усилий это сопоставимо с написанием нового компилятора, тащемта (не уровня gcc, но уровня lcc3 вполне, например).
это если ещё не учитывать, что результирующий выхлоп будет очень больно совать в отладчик.
то есть, проблема, конечно, решается анусными методами, но лучше не мучаться и взять непосредственно gcc, где всё давно уже сделано.
Ну, фигни в gcc всё же тоже добавили. Потом пришлось депрекатить и откатывать.
> Ну, фигни в gcc всё же тоже добавили. Потом пришлось депрекатить и
> откатывать.так никто и не говорит, что там всё идеально. а депрекатили в основном те фичи, которые у gcc были до стандарта, а потом в стандарт их тоже добавили, но чуть-чуть не так (или они пошли вразрез со стандартом).
ну, и малоизвестные штуки типа int x = x; использовать не рекомендуют (к счастью, о них вообще мало кто знает).