LINUX.ORG.RU

Ещё парочка компиляторов C

 , ,


1

4

Обнаружил в Alpine/edge.

https://github.com/fuhsnn/slimcc:

This is a fork of Rui Ueyama’s chibicc with fixes and improvements, including:

  • C99 features: VLA parameters, VLA de-allocation, K&R old-style functions.
  • C11 features: _Static_assert(), over-aligned locals, _Generic with qualifiers.
  • C23 features: constexpr, enum:T{}, #embed, auto type-inference, etc.
  • C2y features: labeled loop/switch, if/switch declaration
  • TS features: defer(enable with -fdefer-ts), VA_TAIL
  • GNU features: inline assembly, symbol attributes, cleanup, cons/destructor
  • Basic codegen optimizations: const folding, reg-alloc for temporaries, instruction selection.

https://kefir.protopopov.lv

This web page is dedicated to Kefir C compiler project, developed by Jevgenij Protopopov.

Work on the project has been going on and off since November 2020, and the main goal of this project is producing a reasonably standard-compliant, independent compiler for modern C language (currently targeting C17 standard) for x86_64-based systems following System-V AMD64 ABI. The project is is licensed under GNU GPLv3 terms for the compiler and 3-Clause BSD for compiler-specific include files (see below). More detailed description is available in the README, whereas this page focuses on providing a high-level overview of the project and its purpose.

Disclaimer: Kefir is experimental hobby project which is not meant for production purposes. No guarantees are being made for correctness, completeness, stability and fitness for any particular purpose.

★★★★★

Нужно больше компиляторов С!
Нужно больше колхозов! Чтобы в каждом дворе был свой колхоз!

vel ★★★★★
()
Ответ на: комментарий от vel

LLVM-free колхозы нужны. В Alpine плохого не затащат. :)

dataman ★★★★★
() автор топика
Ответ на: комментарий от j_protopopov

евгений, а почему вы занялись компилятором си, а не другого языка, с меньшим числом уже существующих компиляторов?

alysnix ★★★
()
Ответ на: комментарий от j_protopopov

Если вдруг у кого-то есть вопросы по компилятору, задавайте

Главный вопрос: зачем нужен еще один C компилятор? В README написано:

The main motivation of the project is deeper understanding of C programming language

Ну ок, рад за автора, саморазвитие – штука нужная и полезная. Но какой юзкейс этого компилятора? Что в нем есть такого, из-за чего есть смысл исспользовать его вместо clang или gcc?

iron ★★★★★
()
Ответ на: комментарий от alysnix

В первую очередь, потому что язык Си это мой любимый язык программирования. Во вторых, в своей категории по соотношению «количество активных проектов/сложность реализации компилятора», Си находится в лидерах. Реализовать компилятор плюсов или раста я бы не смог полноценно, а что-то более нишевое или высокоуровневое меня не привлекало

j_protopopov
()
Ответ на: комментарий от dataman

В очень отдаленной перспективе пока что. На данный момент я в основном занимаюсь улучшением и чисткой intermediate representation и оптимизациями на этом уровне, потом планирую чистить транслятор. Всё это чтобы доделать поддержку C23. Потом скорее всего сконцентрируюсь на добавлении новых архитектур + поддержка MS ABI.

j_protopopov
()
Ответ на: комментарий от iron

Юзкейса нет. Я пишу это в свободное время и лично для себя, публикую постольку поскольку. Добалением этого в репозитории занимаются третьи лица, я с ними не связан никак. Из потенциальных юзкейсов на данный момент:

  1. Бутстрап тулчейна и системы в целом. Кефир уже может нормально собирать coreutils + binutils + musl, и при этом в отличие от gcc или clang не зависит от C++. Если я добавлю ограниченный ассемблер и линкер, можно было бы использовать кефир в рамках GNU Mes или чего-то подобного. Кефир также может бутстрапить старый GCC 4.0.4.
  2. Кефир умеет из коробки генерировать JSON стримы с токенизацией и AST. Если нужно анализировать сишные файлы из какого-нибудь питона, кефир довольно просто к этому приспособить
  3. У меня не доходят руки, но также планировались эксперименты с мета-программированием для языка Си. Что-то типа интегрированного лиспа, который обрабатывает сишные файлы в процессе компиляции на всех стадиях. Фронтэнд кефира написан с учетом этого кейса, но конкретной реализации пока нет
j_protopopov
()
Ответ на: комментарий от iron

Дополню ещё по юзкейсам. Мне известно, что есть некоторые проекты, которые используют максимально возможное количество компиляторов (в т.ч. кефир) для сборки своего кода. Вероятнее всего, в целях повышения и проверки совместимости со стандартом Си как таковым. В таком случае кефир вкупе с другими малыми компиляторами можно расценивать как некое «мерило» соответствия стандарту. Примеры таких проектов: libsir и oksh

j_protopopov
()
Ответ на: комментарий от j_protopopov

Почему компилятор называется Кефир?

Edit: я понимаю, что это отсылка к молочному продукту, а не чему-нибудь ещё. Вопрос в том, почему был выбран именно кефир.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)
Ответ на: комментарий от kaldeon

Какого-то особого смысла или подтекста название не несёт. На момент открытия исходников у проекта постоянного названия не было, и я решил выбрать что-нибудь неожиданное и спонтанное.

Впрочем, название могло оказаться слишком неожиданным для некоторых, так как в какой-то момент были претензии насчёт созвучности слову «кафир».

j_protopopov
()
Ответ на: комментарий от j_protopopov

Возможно, «кефир» от «кафира» и происходит (испорченное молоко), но смысл тут конечно совсем другой

mittorn ★★★★★
()
Ответ на: комментарий от j_protopopov

Если бы мне захотелось по-котовски почесать яйца, я бы реализовал компилятор Ады95. Только не самой Ады95, а её аналога с более компактным синтаксисом (скобочки вместо begin/end, fun вместо function и т.д.), но с полностью идентичной семантикой. Ну и плюс трансляторы из моего кода в стандартный адовый, и обратный транслятор.

seiken ★★★★★
()
Ответ на: комментарий от seiken

Если бы мне захотелось по-котовски почесать яйца, я бы реализовал компилятор Ады95

можно совершенно спокойно и чесать и писать эти ваши компиляторы ада.

да собственно так все компиляторы и пишут.

alysnix ★★★
()
Ответ на: комментарий от j_protopopov

Если вдруг у кого-то есть вопросы по компилятору, задавайте

Хотел задать вопрос о поддерживаемых стандартах, но потом сходил по ссылке, увидел упоминание про C17, вопрос отпал. :)

Планируется ли поддержка Haiku, например?

hobbit ★★★★★
()
Ответ на: комментарий от hateyoufeel

Для такой формулировки есть несколько причин. Во-первых, официальный текст стандарта стоит денег, и при написании компилятора я руководствовался финальным драфтом. Во-вторых, кефир не предоставляет стандартную библиотеку, и вместо этого паразитирует на имеющихся в системе. Это может создать проблемы в некоторых случаях, так как почти все реализации libc, кроме musl, кишат нестандартными расширениями в заголовочных файлах (часть из них реализована в кефире, но о 100% соместимости речи не идёт). В третьих, я просто не хочу делать громкие заявления, за истинность которых не ручаюсь по вышеозначенным приминам.

С практической точки зрения кефир фактически реализует стандарт языка C17 и может собирать крупные сишные проекты без каких-либо существенных изменений в них.

j_protopopov
()
Ответ на: комментарий от hobbit

Около двух лет назад я тестировал кефир на haiku. Если мне не изменяет память, то единственная проблема была в инклудах системной библиотеки. Собственно генерация кода работала, если подсунуть патченные инклуды. С тех пор компилятор был в достаточной степени улучшен, поэтому есть вероятность, что всё заработает и так, но я пока не пробовал.

j_protopopov
()
Ответ на: комментарий от goingUp

В первую очередь, это хобби, где мне нравится и процесс, и результат. С точки зрения мотивации, наиболее сложной была изначальная реализация, когда еще не было понятно, получится ли что-нибудь в принципе – это заняло около 10-11 месяцев до момента, когда стал возможен bootstrap компилятора. Но это было в ковид, и свободного времени было больше. После этого, при аккуратном подходе к разработке компилятор становится только лучше, и этот прогресс сам по себе мотивирует.

Внешняя мотивация ключевой роли не играет, но с недавних пор компилятор стал привлекать всё больше внимания, что тоже немного мотивирует.

j_protopopov
()
Ответ на: комментарий от j_protopopov

Во-вторых, кефир не предоставляет стандартную библиотеку, и вместо этого паразитирует на имеющихся в системе.

Это норм.

Это может создать проблемы в некоторых случаях, так как почти все реализации libc, кроме musl, кишат нестандартными расширениями в заголовочных файлах (часть из них реализована в кефире, но о 100% соместимости речи не идёт).

Это может создать проблемы, потому что стандартные библиотеки кишат UB, необходимым для реализации некоторых вещей. Сишечка в этом плане – достаточно шизофреничный язык.

Главный вопрос: ты касательно оптимизаций вокруг UB пытается копировать другие компиляторы или просто делаешь что-то адекватное? Будет ли у тебя UB sanitiser какой-нибудь?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

У меня очень скудный набор оптимизаций в общем-то. На данный момент это mem2reg для локальных переменных, constant folding, dead code elimination, какие-то базовые упрощения графа инструкций, function inlining и tail calls (последние две пока только в develop ветке). Качество генерируемого кода довольно поганое в принципе (в develop ветке чуть лучше), так как в основном я занимался расширением совместимости по языку и builtin’ам из gcc, чтобы реальные проекты собирать. Первоначально компилятор вообще генерировал шитый код для стековой машины, что ускорило изначальную реализацию, но я до сих пор от этого дизайна страдаю. С точки зрения UB, я никаких оптимизаций на предположении его отсуствия не строю. Все сайд-эффекты в том порядке, в каком они в оригинальной программе, вычисления в том виде, что и в оригинальном коде (кроме случаев, когда упрощение возможно безотносительно UB).

j_protopopov
()
Ответ на: комментарий от hateyoufeel

Относительно UB sanitizer. Я чуть выше упоминал, что у меня были идеи насчет добавления расширений к языку Си, и при проектировании фронтэнда я в некоторой степени это предусмотрел, поэтому возможность написания плагинов к компилятору есть как минимум в теории. У меня был план расширить интерфейс плагинов и сделать санитайзеры внешними библиотеками наравне с другими возможными расширениями компилятора, но я пока до этого не дошел

j_protopopov
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.