Pull to refresh

новый компилятор в OpenBSD

Reading time 4 min
Views 2.1K
Original author: Mark Espie
По мотивам сообщения osnews.com/story.php/18771/More-on-OpenBSDs-New-Compiler

Несколько недель назад проект OpenBSD объявил о том, что Portable C Compiler был добавлен в дерево исходников OpenBSD. И разработчики будут стараться сделать его полноценной заменой GCC. Почему?

По словам Марка Эспи (Mark Espie) undeadly.org/cgi?action=article&sid=20070915195203&pid=52 причина в том, что разработчики 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.

(От меня) Вот такой вот он, GCC. У меня был некоторый опыт общения с GCC на уровне исходников, это действительно тихий ужас. Хотя, в последних версиях код становиться всё более структурированным, но каши по-прежнему очень много. И вряд ли станет меньше, потому что постоянно идёт подгонка под конкретные программы. GCC можно сравнить с другими компиляторами и увидеть, насколько он действительно сложен, и насколько перегружен анализом шаблонов, а не интеллектуальной оптимизацией. Взять хотябы тот же TCC, или PCC. А ещё лучше посмотреть на реактивные компиляторы в Plan9.

Так что, Linux'у ещё есть куда развиваться и стремиться.
Tags:
Hubs:
+17
Comments 45
Comments Comments 45

Articles