>[оверквотинг удален]
> Просто мне порой смешно смотреть, когда начинаются «войны» компилятора gcc с
> llvm.
> Это вообще разное ПО.
> зыж
> И вообще, не вижу причин, почему бы в gcc не сделать какой-нибудь
> бэкэнд для компиляции в бит-код llvm. :D
> По всем остальным моментам мне проходить по второму кругу уже не интересно,
> сори.
> Итак чуть ли не в каждой теме ссылки на RTL вставляю —
> народ вообще не понимает о чём пытается спорить."GCC поддерживает множество систем предварительной обработки кода и разрабатывается активным и многочисленным сообществом. В течение длительного промежутка времени GCC был компилятором языка C с поддержкой различных целевых архитектур и с наличием поддержки нескольких дополнительных языков программирования, реализованной с использованием сложных приемов. По прошествии лет сообщество разработчиков GCC медленно реализовывало более совершенную архитектуру. В версии GCC 4.4 используется отдельное представление кода оптимизатором (известное как "Кортежи GIMPLE" - "GIMPLE Tuples"), которое в большей степени отделено от представления системы предварительной обработки кода, чем использующееся ранее. Также существуют системы предварительной обработки кода для языков Fortran и Ada, использующие необработанные деревья стандартного синтаксического анализа (AST).
Хотя эти продукты и были успешны, возможности их использования жестко ограничены, так как они проектировались как монолитные приложения. В качестве примера можно упомянуть о том, что компилятор GCC невозможно встроить в другие приложения, его невозможно использовать в качестве JIT-компилятора или интрепретатора, а также невозможно выделить и повторно использовать отдельные части GCC без задействования всего компилятора. Разработчикам, желающим использовать систему предварительной обработки кода для языка C++ из GCC в качестве инструмента для генерации документации, индексации кода, рефакторинга и статического анализа приходилось использовать GCC как монолитное приложение, выводящее интересующую их информацию в формате XML или разрабатывать расширения для использования стороннего кода в GCC.
Существует множество причин по которым отдельные части GCC не могут использоваться повторно в качестве библиотек, включающее в себя такие причины, как чрезмерное использование глобальных переменных, недостаточное использование инвариантов, некачественно проработанные структуры данных, распределенная кодовая база и использование макросов, которые затрудняют компиляцию кода для поддержки более чем одной комбинации из системы предварительной обработки кода и системы генерации кода. Наиболее сложные для исправления проблемы являются следствием недоработок в первоначальной архитектуре и возраста компилятора. В особенности GCC страдает от недоработок в распределении уровней и создании абстракций: система генерации кода получает доступ к дереву стандартного синтаксического анализа системы предварительной обработки кода для генерации отладочной информации, система предварительной обработки кода генерирует структуры данных для системы генерации кода и весь компилятор зависит от глобальных структур данных, изменяемых с помощью интерфейса командной строки."
Полный текст тут: http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Ap...
Не знаю, как в новых версиях GCC, может что-то и изменилось. Но представьте сколько им надо внести изменений, не легче ли разработать архитектуру с нуля ?
Вот LLVM это как раз и есть то, что пишется с нуля.
И я не спорю о том, что круче LLVM или GCC. Компиляторы GCC считаю одними из лучших. Но если они справятся со всеми проблемами, что написаны выше, то будет хорошо. И не только в байткоде дело, там и других проблем хватает(хватало?).
