> если сравнивать, скажем, как реализована поддержка некоего языка, или насколько хорош кодогенератор
> — вполне. а вот если сравнивать архитектуру — то сначала надо
> доказать, что архитектура gcc (ну да, мягко говоря, не образец красоты)
> стала такой только и исключительно потому, что хреново спланирована.Кому надо? Условному контрибьютору это не надо. Условный контрибьютор пойдёт контрибьютить в clang с хорошей архитектурой, документацией и C++ везде, а не последний год, или сколько там.
Только тут и сравнивать не нужно, доказали — всё, чего тут ещё обсуждать.
Интересно, почему в ИСП РАН мой бывший сокурсник занимается всякими клёвыми ништяками над компиляторами на примере clang/llvm, а не gcc? Наверное, потому что первый лучше [для этой задачи]?
> а чтобы
> это доказать, надо реализовать в другом проекте всё то же самое,
> что умеет gcc, и как минимум на том же уровне (в
> том числе и кодогенератор, который должен быть по всем параметрам как
> минимум не хуже, чем у gcc)
Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой архитектуры, но тогда, правда, и реализовывать ничего больше не придётся. Доказывать forall-утверждения позитивным примером вообще очень неблагодарное дело.
Прошу прощенья, если я «доказать» слишком серьёзно воспринимаю.
> так вопрос же не в том, кто победит, вопрос в том, что
> иначе сравнение не имеет смысла: нечто с обрезаным фичсетом почти всегда
> можно сделать лучше и понятней, чем с необрезаным.
Максимум обрезанный там список платформ, а влияние его длины (при его нетривиальности) на архитектуру сильно неочевидно, мягко скажем.
>> Для ответа на вопрос выше о том, лучше
>> ли архитектура потому, что руки и мозги у разработчиков прямее, этого
>> хватит, потому что 5 или 50 платформ поддерживает компилятор, уже не
>> столь принципиально, если он вообще способен генерировать код под более чем
>> одну платформу.
> принципиально. тут пример с VLIW уже приводили.
Вот, разве что, VLIW, о котором я и думал, но их разных видов на рынке сейчас вроде не особо много. Могу ошибаться тут, впрочем.
> штука в том, что разные
> архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот
> так использовать можно, а так нельзя — и опа! в регистровом
> аллокаторе появляется костыль для этой архитектуры.
А не должно быть никаких костылей для этого при нормальном планировании.
> у кого-то вот такая последовательность
> команд работает медленней, чем вот нетакая — и опа! в кодогенераторе
> появляется костыль со специальным случаем. и так далее.
И тут.
>> А вот что новые фичи в плане стандарта запиливаются систематически быстрее, чем
>> в случае gcc, это вот хороший и позитивный знак, например. И
>> в ряде приложений это куда важнее.
> и это никак не отвечает на вопрос «лучше и проще ли было
> переделать gcc с нуля». потому что, например, запиливаться быстрее они могут
> именно потому, что у llvm местами обрезаный (по сравнению с gcc)
> фичсет. см. выше про всякие костыли.
Если от фронтенда зависит кодогенератор, то я даже не знаю, что тут сказать. Как capture-init из C++14, или там, не знаю, расширенный noexcept оттуда же вообще относится к кодогенерации? Первая вещь разворачивается на этапе компиляции в обычную структурку, вторая вообще по определению компил-тайм.
>[оверквотинг удален]
>> Это, если что, ирония над тем, что твои слова звучат как «если
>> вещи разные, то их сравнивать нельзя». А нахрена сравнивать одинаковые вещи?
> см. выше. одинаковые по выхлопу вещи можно делать разными путями. вот пути
> и есть смысл сравнивать. но чтобы эти пути сравнивать — сначала
> выхлоп должен быть одинаковый. в данном случае «одинаковый» — это все
> архитектуры, и на каждой у нового проекта код должен быть как
> минимум не хуже, чем у старого проекта. потому что если код
> хуже — опять не ясно: может, он хуже как раз потому,
> что в старом проекте всунули мегакостыль в оптимизатор, который уродливый, но
> зато делает код чуть лучше?
Локальные мегакостыли в оптимизаторе глобальную архитектуру трогать не должны, а в гцц, поговаривают, системные проблемы.
