Какой бекэнд выбрать для компилятора?

Question

[NewHabraUser]

Год назад мы с однокурсниками попытались сделать свой игрушечный скриптовый язык программирования. Написали лексер, парсер, обработку AST-дерева. Для того, чтобы можно было "пощупать" получившийся язык, сделали преобразование AST в C++ код. Даже простенькую IDE с подсветкой синтаксиса и ошибок набросали. Теперь хочется как-то этот проектик доделать и разместить на просторах интернета, НО
1) Публиковать транслятор на c++ как-то несолидно
2) Думали сделать фронтенд для gcc, но этот самый gcc опубликован под GPLv3, т.е. придется нам раскрыть исходный код IDE и самого языка, чего делать не хочется.
3) Попытались разобраться с LLVM IR - не получилось, не нашли ни SDK, ни нормальной документации
4) Задумываемся над написание виртуальной машины/интерпретатора для языка, но боимся огромной потери производительности.
5) Преобразование AST в ассемблер не рассматриваем - такое нам не под силу.
Хотелось бы обратиться к хабрасообществу за советом: как лучше всего реализовать бекенд? Мб у кого-то есть аналогичный опыт? Хорошая документация/книга по LLVM?
Любой наводке будет благодарны.

Comments

[Anonymous]

нам раскрыть исходный код IDE и самого языка, чего делать не хочется.

Тогда никто даже не заинтересуется что за там такой ЯП у вас.

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента.

Answer 1

[Василий Банников]

Это не смотрели? https://llvm.org/docs/Reference.html#llvm-ir

придется нам раскрыть исходный код IDE

Нет, не придётся.

и самого языка

Как правило в этом ничего плохого нет. Почему вы боитесь публиковать исходники языка?

скриптовый язык программирования.

Если скриптовый, то обычно пофиг на производительность. Очень много чисто скриптовых языков даже без JIT-компиляции живёт, исключительно в режиме интерпретатора.

Answer 2

[mayton2019]

игрушечный скриптовый язык программирования.

Какой бекэнд выбрать для компилятора?

В самом вопросе обычно лежит половина ответа.
Если вы дадите определение back-end - то правильно облегчите себе решение задачи.
Вот выше вы писал про скриптовый язык. Тогда почему вдруг стали дальше писать про
back-end и native-компилляторы?

Есть целый пласт языков или виртуальных машин которые живут и работают не доходя
всегда до LLVM. И нужен ли вам LLVM - большой вопрос. Что вы хотите от LLVM? HiLoad?
Это не задача скриптинга.

Вобщем поставте какое-то внятное целеполагание. Вы создаете скриптовый язык чтобы ЧТО?

Answer 3

[Griboks]

Просто используйте gcc как внешний компонент, тогда не придётся наследовать лицензию.

Answer 4

[jcmvbkbc]

Думали сделать фронтенд для gcc

Можно прицепиться к libgccjit.

хочется как-то этот проектик доделать и разместить на просторах интернета…
Думали сделать фронтенд для gcc, но этот самый gcc опубликован под GPLv3, т.е. придется нам раскрыть исходный код IDE и самого языка, чего делать не хочется.

Исходный код требуется раскрывать только обладателям бинарников. Если размещение на просторах интернета -- это онлайн IDE, то бинарника ни у кого нет, следовательно код раскрывать не нужно.

Однако, предоставление исходников, особенно под свободной лицензией обычно выгодно самим проектам, которые это делают.