Судя по сообщению osnews.com/story.php/18771/More-on-OpenBSDs-New-Compiler Несколько недель назад проект OpenBSD объявил, что Portable C Compiler был добавлен в дерево исходного кода OpenBSD. И разработчики постараются сделать его полноценной заменой GCC. Почему? По словам Марка Эспи undeadly.org/cgiЭaction=article&sid=20070915195203&pid=52 причина в том, что у разработчиков GCC другие цели, чем у разработчиков OpenBSD. Он показывает разницу в следующих моментах.
(1) GCC сейчас является почти коммерческой разработкой.
Им занимаются дистрибьюторы коммерческих дистрибутивов Linux и Apple. Компилятор ориентирован только на быстрые процессоры i386 и PowerPC. При этом оно заточено на достижение высоких баллов в SPEC. (От меня) Как известно, адаптация компиляторов под конкретные программы делается по старинке - просто наращивание базы шаблонов, которые должен распознать компилятор, и выдавать для них заранее написанный человеком код. Вот почему.
(От Марка) Но компилятор становится все больше и больше, все медленнее и медленнее, и при этом намного медленнее.
(От меня) Что, к сожалению, узнал любой пользователь Gentoo за последние несколько лет .
(2) Предупреждения в GCC бесполезны.
Компиляция с помощью -Wall сообщает о многом верном и кое-что неверном.
(3) Вся конструкция GCC настолько извращена, что никто даже не может различить фронтенд и бэкенд компилятора (от меня: настоящая правда, я помню, как мы занимались любовью с gcc в попытках научить нас понимать его безрегистровую архитектуру) .
Топорно, начиная с дизайна (сломанного по дизайну), так как GPL люди боятся, что коммерческие организации смогут украсть бэкенд или фронтенд и привязать их к закрытым языкам или генераторам кода.
(от меня: странный вывод, однако) .
Возможно, это правда.
Но это мешает созданию интересных инструментов типа промежуточных анализаторов кода.
А это также не позволяет использовать бэкенды для старых архитектур с новыми компиляторами.
(4) В результате вы не сможете получить новые интересные возможности новой версии GCC, не потеряв при этом старые интересные возможности (от меня: да, для компиляции QEMU все равно придется носить с собой GCC 3.).
Каждое обновление GCC — это инженерный кошмар, потому что здесь нет простого выбора: вы получаете возможности, но теряете важные функции.
(От меня) Ну на самом деле оно редко появляется, но если и появляется, то это действительно геморрой .
(5) Также очень сложно развивать GCC. Их система ветвления делает очень вероятным, что важная работа исчезнет между трещинами (и это происходит постоянно).
Если вы разрабатываете код для GCC, вам нужно делать это в последней ветке, что довольно сложно, если ваша платформа в данный момент не работает (такое случается).
постоянно если у вас не Linux/i386) (от меня: возможно это означает, что новая версия gcc-i686-pc-bsd не работает) .
Даже когда адаптируешься, сложно писать код в соответствии со стандартами кодирования GNU, которые, пожалуй, наиболее сложны для чтения на C. Очевидно, их придумал лисп-программист. В результате я (Марк) даже потерял интерес к переписыванию и отправке нескольких кусков кода в репозиторий GCC. (6) Некоторые недавние улучшения не имеют шансов работать в OpenBSD, например, подготовленные включения, которые полагаются на mmap() по фиксированному адресу.
(от меня: странное решение разработчиков GCC. Гораздо сложнее было использовать адрес, который возвращает mmap()?) (7) В GCC и G++ есть несколько мест, где вы не можете получить полную функциональность без эквивалента glibc. (от меня: а у параноидальных OpenBSD людей, естественно, нет полного аналога этой, потому что в ней много ошибок) .
(8) Некоторые методы оптимизации определенно опасны и неправильны для нас (например, выбрасывание заполнения памяти во время оптимизации, даже если они имеют дело с криптоключами) (от меня: ну да, будет плохо, когда компилятор выкинет ваш memset(0, 256, &rsakey) из кода, потому что вызовов rsakey больше не будет. Будет плохо, потому что другой процесс может получить то же место физической памяти) (9) И не забывайте кошмар autoconf/libtool/automake (от меня: о да, детка).
Черт, даже самим людям из Персидского залива потребовалось несколько лет, чтобы обновить свою инфраструктуру, чтобы она была совместима с новейшими автопроизводителями.
И в то же время GCC - единственная программа из дерева портов который фактически использует внутреннюю реализацию libtool. Его настройка и реконфигурация полностью терпят неудачу при попытке использовать системный libtool. Я (Марк) мог бы продолжить еще несколько страниц.
Я был специалистом по сопровождению GCC на OpenBSD в течение нескольких лет и был бы рад переключиться на другой компилятор, путешествие с GCC было очень разочаровывающим.
(От меня) Вот что это такое, GCC. У меня был некоторый опыт работы с GCC на уровне исходного кода, и это действительно тихий ужас.
Хоть и в последних версиях код становится все более структурированным, но бардака все равно много.
И вряд ли станет меньше, потому что в конкретные программы постоянно вносятся коррективы.
GCC можно сравнить с другими компиляторами, и вы увидите, насколько он на самом деле сложен и насколько он перегружен анализом шаблонов, а не интеллектуальной оптимизацией.
Взять тот же ТСС, или PCC. А еще лучше посмотрите на реактивные компиляторы в Plan9. Итак, Linux еще есть куда развиваться и стремиться.
Теги: #OpenBSD #GCC #Программное обеспечение
-
Полезные Идеи Для Успешного Дизайна Сайта
19 Oct, 24 -
Какой Фреймворк Вы Используете И Почему?
19 Oct, 24 -
Карты, Счета, 2 Баланса
19 Oct, 24 -
Ежедневный Отчет Менеджера
19 Oct, 24 -
Webkit Стал №1 В Рейтинге Браузерных Движков
19 Oct, 24
