DSL, GIMPLE и всякое-такое

Только один вопрос - нафига? Что тебе дасть GIMPLE, но не даст Си?

Насколько я понимаю, полученный AST намного проще преобразовывать в GIMPLE, чем в C.

Хотя, лично я такой подход рассматриваю как альтернативу LLVM: дебаггер, рантайм, очень нетривиальные оптимизации, плюс полная интеграция практически с любой библиотекой.

Вы уверены что так хотите отладчик и компиляцию в нативный код? Если нет (и даже если да, для кругозора) советую глянуть на Jetbrains MPS.

Комментарий таков: см. правило Гринспуна.

Можно просто заюзать Common Lisp с нормальной системой макросов, которые обеспечат какой угодно DSL с отладчиком, компиляцией в нативный код и рантаймом.

> Комментарий таков: см. правило Гринспуна.

Ты сам-то его смотрел? Оно начинается со слов "любая достаточно большая программа".

> Насколько я понимаю, полученный AST намного проще преобразовывать в GIMPLE, чем в C.

Я ничего такого не понимаю (GIMPLE - довольно низкоуровневое представление). Это единственный профит? Откуда возьмутся рантайм и отладчик?

>Вы уверены что так хотите отладчик и компиляцию в нативный код

Без разницы.

Я рассматриваю такой подход пока чисто с теоретической точки зрения. На эту идею я наткнулся, когда пытался разобраться с LLVM. Кстати, если GCC - то совершенно необязательно в нативный код.

Почему бы не использовать ту его часть, которая преобразовыват в SSA-форму и проводит различные оптимизации?

За ссылку - огромное спасибо. Может быть Вы еще чего-нибудь интересное знаете про метапрограммирование и domain engineering?

>Это единственный профит?

Нет. Главный профит в достаточно сложных процессах приведения в SSA-форму, осуществление различных оптимизаций, которые, например, LLVM не делает и делать не будет.

>Откуда возьмутся рантайм и отладчик?

Насколько я понимаю, GCC без каких-то проблем может добавить отладочную информацию, которую поймет gdb. А рантайм - выбрать один из уже существующих.

> Главный профит в достаточно сложных процессах приведения в SSA-форму, осуществление различных оптимизаций

При выводе Си всё это будет.

>>Откуда возьмутся рантайм и отладчик?

>Насколько я понимаю, GCC без каких-то проблем может добавить отладочную информацию

Нагенерить DWARF вручную? Ничего себе "без какиих-то проблем". И эта отладочная инфрмация должна быть съедобна для gdb, что ограничивает структуры данных уровнем Си, по существу.

>При выводе Си всё это будет.

Будет-то оно будет, но здесь проблемы с чисто эстетической точки зрения. Вот я отпарсил свой DSL, получил AST, и теперь мне нужно по этим AST сделать вывод в текстовом представлении, чтобы GCC в свою очередь его отпарсил и т.д.

Или например, захотел я сварганить генератор недетерминированных конечных автоматов. На C это будет абсолютно нечитабелтный винегрет из goto. Может имеет смысл использовать что-то более подходящее? Какое-то другое промежуточное представление?

>Нагенерить DWARF вручную?

Тут я не могу ничего сказать, т.к. не заню на каком конкретно уровне компиляции она генерится... Но что-то мне подсказывает, что какая-то ее часть генерится на уровне GIMPLE представления.

Вроде как в gdb мы можем смотреть GIMPLE? Разве нет?

>Ты сам-то его смотрел? Оно начинается со слов "любая достаточно большая программа".

А вы не считаете реализацию такого DSLя "достаточно большой программой на C"?

>Какое-то другое промежуточное представление?

Это представление называется s-expression. Очень простое и, в то же время, очень мощное.

>Или например, захотел я сварганить генератор недетерминированных конечных автоматов. На C это будет абсолютно нечитабелтный винегрет из goto. Может имеет смысл использовать что-то более подходящее?

Что-то подходящее — это макры (для справки: макр — это произвольное преобразование из AST в AST, работающее во время компиляции программы).

Вроде бы, в некоторых других языках, кроме лиспа, есть системы макросов (template haskell, nemerle).

>Это представление называется s-expression.

Не надо про лисп. О нем я имею достаточно хорошее представление. S-выражения - это те же AST-деревья, не более, но и не менее.

Вообще классная идея программировать в терминах DSL/AST, но для меня она почему-то не сработала.

> Что тебе дасть GIMPLE, но не даст Си?

Ты прежде чем спросить... ну в общем оно дает еще и все что есть в аде, то есть целые типы с границами например.

Хотя, конечно, не факт, что это позарез надо.

Кроме того, С весьма плох как низкоуровневый ассемблер, так как у него нет полноценной передачи по ссылке (что затрудняет оптимизацию). Не знаю, может это частично в С99 пофиксили?

> вы не считаете реализацию такого DSLя "достаточно большой программой

Какого "такого"? Не говоря уже о том. что сам Гринспан не приводит критериев "достаточно большой программы".

А если подумать о том, что для получения человеческого (== привычного по школной математике) синтаксиса в Лиспе придется прибегать к трюкам, то выгода еще менее очевидна.

> на C"?

Почему на Си? Транслятор можно написать на Ocaml. Python, да хоть том же Лиспе. Рантайм - по обстоятельствам.

>> Что тебе дасть GIMPLE, но не даст Си?

> Ты прежде чем спросить...

Ну а ты просвети меня.

> С весьма плох как низкоуровневый ассемблер, так как у него нет полноценной передачи по ссылке

Ахренеть.

> Вроде как в gdb мы можем смотреть GIMPLE? Разве нет?

Эээ... где? Вроде как только номера строк.

> Ахренеть.

Я сходу ссылку не кину, но кажется на http://mozart-dev.sourceforge.net чувак мерил пример на своем языке с С, и получил на 50% быстрее из-за того, что жцц не имеет полной свободы оптимизировать ссылки.

> кажется на http://mozart-dev.sourceforge.net чувак мерил пример на своем языке с С, и получил на 50% быстрее из-за того, что жцц не имеет полной свободы оптимизировать ссылки.

Это проблема gcc, или кодогенератора Моцарта, или мерявшего чувака. Для оптимизаций давно придуманы const, __restrict и -fno-strict-aliasing.

>>Нагенерить DWARF вручную?

> Тут я не могу ничего сказать, т.к. не заню на каком конкретно уровне компиляции она генерится...

Фронтендом языка, ЕМНИП.

> Вроде как в gdb мы можем смотреть GIMPLE? Разве нет?

O_O Каким образом? Он что, ВНЕЗАПНО включается в бинарь?

> Это проблема gcc, или кодогенератора Моцарта, или мерявшего чувака. Для оптимизаций давно придуманы const, __restrict и -fno-strict-aliasing.

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

З.Ы. Вообще я не рассматривал варианты генерить иначе как в С/LLVM -- делать еще и свой кроссплатформенный ассемблер это уже слишком. Потому, погневавшись немного на С, я успокоился и забыл.

З.Ы.Ы. Macil-у я бы тоже не советовал генерить GIMPLE. Уж лучше С.

> Это проблема gcc, или кодогенератора Моцарта, или мерявшего чувака.

Возможно, что у меня 2 вещи наложились -- замеры были на тему complex-ных чисел (70% speed boost relative to C++), а на тему С -- просто нытье, хотя ИМХО обоснованное (32 против 64 бит и регистры) -- http://xlr.sourceforge.net/concept/perf.html

Еще надо поискать... как найду -- напишу.

> Вообще классная идея программировать в терминах DSL/AST, но для меня она почему-то не сработала.

Вот давай это и обсудим.

> Только один вопрос - нафига? Что тебе дасть GIMPLE, но не даст Си?

Вообще-то мой ответ был скорее не про GIMPLE, а про GENERIC -- и надо было конечно уточнить у Macil-а что он на самом деле имел в виду.

>Вот давай это и обсудим.

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

> Да тут и обсуждать нечего. Программировать нужно в терминах предметной области, а не парадигмы, языка или чего-то еще.

Что не сработало интересно.

>и надо было конечно уточнить у Macil-а что он на самом деле имел в виду.

Есть такая штука LLVM. Мы преобразовываем наш DSL в LLVL IL, сразу в SSA форме, затем пользуемся либо штатным кодогенератором, либо делаем что-то свое. (Динамические характеристики, JIT, легковесность и применимость пока оставим)

Собственно стал я в этом разбираться, статейки искать и нашел следущее. В GCC дела обстоят примерно также:

1. Есть фронтенд, который из целевого языка делает GENERIC форму и пропускает ее через GIMPLIFIER.
2. Есть мидл-енд, который GIMPLE преобразовывает в GIMPLE SSA и проводит различные оптимизации (их много, и они очень нетривиальные, в том плане что выкладки я осилить не смог), после чего полученный результат пропускает через deGIMPLIFIER и получает RTL.
3. Есть бэк-енд, который производит RTL-специфичные оптимизации и генерит объектный код.

Это все я к чему? Зачем пользоваться LLVM, которая явно пытается заниматься не своим делом в виде написания фронт-енда для С/C++ (как будто нам глючных компиляторов С++ не хватает!), когда буквально под боком есть ТАКОЕ? Я понимаю, что разработчики GCC не очень в плане открытости, в том плане что маловато конкретной документации, практически отсутствует соответствующая инфраструктура (правда и LLVM этим не блещет). Зато - тем ценнее приз :)

>Что не сработало интересно.

В CL существует принцип "все для лиспа". Если раньше он очень хорошо работал, то теперь CL отстал по реализации на нем разных нужных вещей. Это первое.

В CL мне не удалось "разложить все по полочкам". Слишком запутанным в конечном итоге получался код. И либо он должен целиком состоять из макросов разной степени вложенности, или быть трудноуправляемым. Это второе.

а причем тут Front End для С++? это они тестируют свой backend. а backend в LLVM это основное. в LLVM документация получше, точнее у GCC ее практически нет, а у LLVM на сайте даже онлайн генератор IR-кода есть. пацаны для людей делают.

> Может быть Вы еще чего-нибудь интересное знаете про метапрограммирование и domain engineering?

Может быть. Но вы как то задайте тему. А то больно широко. есть Eclipse xtext, есть Microsoft Oslo. Вас что именно интересует?